+1 ;-)
mh
Le 7 mars 2020 à 21:03, à 21:03, Raphael Mazelier a écrit:
>
>>
>> Tout dépend du point de vu :) A une époque pas si lointaine quand le
>> devops n'existait que dans nos cauchemars (pardon rêves ;)) les plus
>fous,
>> c'est l'infrastructure seule qui portait cette responsabilité. Ce
Tout dépend du point de vu :) A une époque pas si lointaine quand le
devops n'existait que dans nos cauchemars (pardon rêves ;)) les plus fous,
c'est l'infrastructure seule qui portait cette responsabilité. Ce paradigme
a quelque peu évolué depuis et on retrouve cette notion des deux côtés
GSLB c'est top pour répartir entre plusieurs DC, selon le status des
ressources, géolocalisées pour renvoyer au plus proche.
Il y a plein d'offres SaaS pour ce type de service.
Le 03/03/2020 à 13:21, Raphael Mazelier a écrit :
Résultat gslb avec gdnsd me semble une bonne solution. Les ttls
On 05/03/2020 21:54, Philippe Bourcier wrote:
Ca n'aurait pratiquement aucun intérêt... puisque c'est déjà ce que ferait un
OS/browser.
Je ferais plutôt :
1. le client JS fait sa requête DoH
2. il voit N CNAMEs : srv[1,2,3...].frnog.org
3. il lance 2 threads de connexion (get d'une page de
On Thu, Mar 5, 2020 at 11:02 AM Raphael Mazelier wrote:
> Je crois que l'on a mélangé un peu plusieurs discussions mais au final
> on en revient toujours au même débat : ou placer la redondance ? coté
> infra ou coté applicatif ?
>
> La redondance infrastructure est d'une certaine manière plus
Re,
> 1. le client JS fait sa requête DoH
> 2. il voit 3 CNAMEs : srv[1,2,3].frnog.org
> 3. il fait son LB façon RR-DNS et chosit srv2.frnog.org
Ca n'aurait pratiquement aucun intérêt... puisque c'est déjà ce que ferait un
OS/browser.
Je ferais plutôt :
1. le client JS fait sa requête DoH
2.
Oui, voilà !
Donc en résumé, pour accéder à http[s]://www.frnog.org/...
1. le client JS fait sa requête DoH
2. il voit 3 CNAMEs : srv[1,2,3].frnog.org
3. il fait son LB façon RR-DNS et chosit srv2.frnog.org
4. il poursuit en accédant à http:[s]://srv2.frnog.org/...
Problèmes à résoudre :
Re,
> Ou alors tu te comportes comme une adulte et tu utilises des noms DNS
> statiques, un par machine.
>
> Franchement, arretez avec l'utilisation des IP dans les applis. Ce n'est pas
> comme ca que les
> choses sont supposes marcher.
Mais ouai en fait... tu peux très bien faire une requête
> Testé à l'instant sous Windows 10, le timeout est de l'ordre de 20
> secondes. Que ce soit sur Chrome, Firefox ou Edgium.
> Donc ça reste acceptable...
>
Oui. Précisément : 21 s de timeout minimum dans cette config.
Mais ça dépend de la machine, de l'OS, des patches et du "sysconfig"
local.
Le 05/03/2020 à 00:50, Jonathan Leroy - Inikup via frnog a écrit :
> Donc oui, les cookies sont nécessaires en 2020. :)
+1.
Ne pas confondre cookies permanents (le MAL) et cookies de session (une
nécessité en 2020 et pour longtemps encore).
D'ailleurs, le fait qu'un contenu en http://IP/... ne
Yes le fameux compute@edge. Très pratique mais pas très donné pour le
moment.
--
Raphael Mazelier
On 05/03/2020 12:43, Théophile Helleboid wrote:
Avec les "Workers" qu'on peut exécuter directement chez le CDN, on
peut faire un mix.
Par exemple :
- Un worker qui vérifie chaque upstream…
- et
Avec les "Workers" qu'on peut exécuter directement chez le CDN, on
peut faire un mix.
Par exemple :
- Un worker qui vérifie chaque upstream…
- et qui génère un fichier de configuration avec au moins un upstream
qui fonctionne : { api_host: "https://api1.example.com; }.
L'application Javascript
Je crois que l'on a mélangé un peu plusieurs discussions mais au final
on en revient toujours au même débat : ou placer la redondance ? coté
infra ou coté applicatif ?
La redondance infrastructure est d'une certaine manière plus facile à
réaliser mais moins efficace ou plus dure à mettre au
On 05-Mar-2020 10:41 CET, wrote:
> * Renaud RAKOTOMALALA, 2020-03-03 :
>
> >- t'appuyer sur un service tier pour le DNS qui en conscience adaptera
> >la réponse sur le ou les IP publiques de tes HAProxy
>
> Ça peut être une solution assez simple à mettre en œuvre avec AWS
> Route53,
Ca règle le problème de cache local des DNS résolveurs pendant X min ?
> Le 5 mars 2020 à 10:44, Raphael Mazelier a écrit :
>
> Oui si on accepte d'utiliser un service tiers, un dns global type route53 est
> simple (peu cher) et efficace pour ce genre de redondance.
>
> On 05/03/2020 10:41,
Oui si on accepte d'utiliser un service tiers, un dns global type
route53 est simple (peu cher) et efficace pour ce genre de redondance.
On 05/03/2020 10:41, Thomas Quinot wrote:
* Renaud RAKOTOMALALA, 2020-03-03 :
- t'appuyer sur un service tier pour le DNS qui en conscience adaptera
Nous avons plusieurs services derrières ces Haproxy, certes du web, qui ne
m'inquiète pas vraiment, un downtime d'1h est acceptable...
Notre coeur de business c'est la reco vocale, donc le point critique c'est
notre API de reco (en websocket).
Des choix stratégiques ont été fait chez un hébergeur
* Renaud RAKOTOMALALA, 2020-03-03 :
>- t'appuyer sur un service tier pour le DNS qui en conscience adaptera
>la réponse sur le ou les IP publiques de tes HAProxy
Ça peut être une solution assez simple à mettre en œuvre avec AWS
Route53, qui permet d'associer les RR retournés à des
Hello,
Je pensais la solution HS mais comme on propose cloudflare...
Tu mets un 3ème HAProxy en frontal pour distribuer vers tes 2x autres LB
HAP sait facilement tester tout les serveurs fils pour les éjecter du RRB
Si tout est en panne tu peux même servir une page d’excuse.
La charge ?
On Wed, Mar 4, 2020, at 18:30, Christophe Desnoyer wrote:
> Ça veut dire que tu fais la résolution toi-même et appelle ensuite des
> URLs en http[s]://*IP*/URL et pas https[s]://*FQDN*/URL, ce qui a de
> sévères impacts sur HTTPS, les cookies, le same-origin, etc.
Ou alors tu te comportes comme
Le mer. 4 mars 2020 à 23:04, Philippe Bourcier a écrit :
> Utiliser des cookies, en 2020 ? ... :)
> Web Storage, JWT, sessionless... ?
Web Storage n'est pas fait pour stocker des infos de session
(n'importe quel script tiers sur la page peut accéder à son contenu).
JWT est une horreur à éviter à
On 04/03/2020 23:04, Philippe Bourcier wrote:
> Bof, il y a des certifs sur IP chez Let's Encrypt...
Pas encore :
https://letsencrypt.org/upcoming-features/
Last updated: Feb 20, 2020
IP Addresses in Certificates
We are planning to add support for validating and including IP addresses in
Le mer. 4 mars 2020 à 18:31, Christophe Desnoyer a
écrit :
> Concernant la solution d'Hervé Bry où le browser teste lui-même les IPs
> à la suite en cas de round-robin DNS, attention au timeout avant qu'il
> essaye l'IP suivante. C'est mieux que 20 minutes, mais ça peut quand
> même faire
Re,
> Ça veut dire que tu fais la résolution toi-même et appelle ensuite des
> URLs en http[s]://*IP*/URL et pas https[s]://*FQDN*/URL, ce qui a de
> sévères impacts sur HTTPS
Bof, il y a des certifs sur IP chez Let's Encrypt...
>, les cookies,
Utiliser des cookies, en 2020 ? ... :)
Web
Oui, piste intéressante que je ne connaissais pas.
Ça veut dire que tu fais la résolution toi-même et appelle ensuite des
URLs en http[s]://*IP*/URL et pas https[s]://*FQDN*/URL, ce qui a de
sévères impacts sur HTTPS, les cookies, le same-origin, etc.
Ou ai-je loupé qqchose ?
Concernant la
Re,
> Forcément ça ralentit un peu la navigation (il faut attendre quelques
> secondes le timeout), mais comme la connexion est souvent gardée ouverte
> pour plusieurs requêtes successives, ça reste utilisable, jusqu'à la mise à
> jour des DNS pour retirer l'enregistrement pointant vers le
Le mer. 4 mars 2020 à 14:56, Christophe Desnoyer a
écrit :
> Par TTL court il faut entendre TTL de 20 minutes, car même si on publie
> un TTL de 30s, beaucoup de resolvers d'ISP cachent pendant 20 minutes
> mini. Donc pour ce qui est de la haute dispo
S'il s'agit d'accès HTTP, et que le
Par TTL court il faut entendre TTL de 20 minutes, car même si on publie
un TTL de 30s, beaucoup de resolvers d'ISP cachent pendant 20 minutes
mini. Donc pour ce qui est de la haute dispo
Le 03/03/2020 à 13:21, Raphael Mazelier a écrit :
> Résultat gslb avec gdnsd me semble une bonne solution.
Bonjour,
Dans ce cas si L2 privé entre les 2 DC, peut-etre regarder pour coupler
le cluster HAproxy avec une solution Keepalived juste en utilisant les
fonctionnalités :
- keepalive pur pour l'aspect "état du cluster"
- healthcheck Haproxy pour chaque noeud (local et éventuellement
Résultat gslb avec gdnsd me semble une bonne solution. Les ttls court
c'est moche mais tout le monde le fait alors bon.
--
Raphael Mazelier
On 03/03/2020 13:15, Mickael Hubert wrote:
Un grand merci à tous pour vos retours !
BGP pas possible coté hébergeur, ses IP arrivent de façon
Un grand merci à tous pour vos retours !
BGP pas possible coté hébergeur, ses IP arrivent de façon indépendantes sur
ses 2 DC, pas possible d'annoncer le subnet du DC A sur le DC B en cas de
perte du DC A.
J'ai bien un L2 entre les 2 DC, mais il ne me servirait que pour le côté
privé. Et
Hello,
> On 3 Mar 2020, at 11:15, Mickael Hubert wrote:
>
> Bonjour à tous,
> nous devons réaliser du HA (et si possible du loadbalancing) entre 2
> instances HAProxy, ces 2 Haproxy doivent-être hébergés dans 2 DC différents.
> Pas possible de réaliser du VRRP car nous ne pouvons pas switcher
Coucou Mickael,
Sur la partie multi-cloud/multi-isp effectivement ton choix est limité. En
fonction des contraintes tu peux:
- t'appuyer sur un service tier pour le DNS qui en conscience adaptera
la réponse sur le ou les IP publiques de tes HAProxy
- le faire toi même, avec un test sur
Yep globalement deux options : GSLB (du pauvre ou pas, mais j'aime bien
l'approche) ou anycast BGP.
--
Raphael Mazelier
On 03/03/2020 11:37, Thomas Pedoussaut wrote:
Tu as la version DNSLB du pauvre, j'en ai fait depuis 2007.
Ca utilise le fait que naturellement, la chaine de resolution DNS
J’ai envie de dire: s’il fait l’effort de déployer une archi pareille, pour
avoir les 2 sites dépendant du même transit…..
> Le 3 mars 2020 à 11:29, Jugurta Yennek a écrit :
>
> Bonjour Mickael,
> As tu la possibilité de mettre en place deux sessions BGP entre tes
> HAProxy et les routeurs de
Tu as la version DNSLB du pauvre, j'en ai fait depuis 2007.
Ca utilise le fait que naturellement, la chaine de resolution DNS va
chercher à trouver un NS up pour une zone.
Soit ton site www.example.com
Soit ta Machine A comme ip 1.2.3.4
Soit ta Machine B comme ip 5.6.7.8
Tu cree une sous
Bonjour Mickael,
As tu la possibilité de mettre en place deux sessions BGP entre tes
HAProxy et les routeurs de ton opérateur/hébergeur et d'annoncer la même
IP (flotante) des deux cotés qui servira à ta prod ?
Avec cette solution tu peux même monitorer ton process HAPROXY et de
shut/no shut
Ca doit pas être impossible de détecter qu’un HA est mort et de mettre à jour
la zone DNS automatiquement (elle devra avoir un TTL faible bien sûr, je sais
c’est mal) ?
Ca me semble KISS non ?
> Le 3 mars 2020 à 11:15, Mickael Hubert a écrit :
>
> Bonjour à tous,
> nous devons réaliser du HA
Bonjour à tous,
nous devons réaliser du HA (et si possible du loadbalancing) entre 2
instances HAProxy, ces 2 Haproxy doivent-être hébergés dans 2 DC différents.
Pas possible de réaliser du VRRP car nous ne pouvons pas switcher l'IP
publique de l'un à l'autre des DC.
La solution la plus simple
39 matches
Mail list logo
