Re: [FRnOG] Anycast
Le Thu, 24 Jan 2008 10:29:42 +0100, Frédéric Gander [EMAIL PROTECTED] a écrit : en resumer pour moi le mieux c'est : - anycast = pour du multihoming a l'intérieur d'un réseau - load balancer = pour repartir la charge des serveurs d'une plateforme rataché à un même routeur apres tu peux apliquer ca a plein de truc, serveur de firmware, serveur dhcp, serveur de log, serveur web J'ai également des résultats assez probant avec du RR DNS et les SRV record avec un bind récent. Pas de gestion du failover par contre (sans scripter un poil) a +. -- Jérôme Benoit aka fraggle La Météo du Net - http://grenouille.com OpenPGP Key ID : 9FE9161D Key fingerprint : 9CA4 0249 AF57 A35B 34B3 AC15 FAA0 CB50 9FE9 161D pgprObcIqlq7l.pgp Description: PGP signature
Re: [FRnOG] Anycast
On Wed, Jan 23, 2008 at 06:06:56PM +0100, Benjamin BAYART wrote: Le Wed, Jan 23, 2008 at 05:37:12PM +0100, Frédéric Gander: On Wed, Jan 23, 2008 at 04:20:17PM +0100, Greg VILLAIN wrote: Salut, Je cherche des retours d'expérience sur AnyCast en cas concrêt, quelqu'un a ca ? ca marche tres bien pour du dns. par exemple ;) Avec quelques bémols cependant: - tant que le DNS reste en UDP, aucun soucis - quand le DNS voudra passer en TCP, on peut croiser des problèmes - la solution dépendra de ce que savent faire des routeurs. Quelques solutions simples: - ne jamais mettre plus d'un DNS par routeur, et du coup, sauf accident, un client DNS tapera toujours sur le même serveur, et donc le passage en TCP fonctionnera magiquement (sauf un cas précis: si le trafic DNS est rerouté suite à un crash pendant une requête en TCP, pas dramatique, en moyenne) - quand tu as plusieurs DNS sur le même routeur, veiller à ce que le routeur répartisse le trafic sur les deux serveurs, et que le trafic d'un client donné aille toujours sur le même serveur (pour se ramener au point précédent). si tu veux faire de l'anycast il ne faut pas trop faire de load balancing sur les routeurs. enfin tout depend de la methode de hashing que tu choisis. Si tu es dans un mode src-dst en theorie (pour les vrais routeurs) pour une src dst donnée tu prend tjs le meme chemin Pour load balancer apres sur plusieurs serveur le mieux est de faire du load balacing via des load balancer (ou lvs sous linux) qui font du tracking tcp. Je ne maitrise pas assez bien les finesses OSPF/BGP des différents équipementiers pour indiquer les règles exactes de config, mais en général ça marche assez facilement. Le point clef est d'avoir une IP, qui ne soit pas en anycast, pour le pilotage: forcement car sinon en fonction de la ou rerentre ta requette dns dans ton reseau tu ne retombes pas sur la bonne machine donc tu ne peux pas faire de requettes recursives - réplication du contenu (requêtes récursives dans le cas du DNS) - admin de la machine (oui, en anycast, c'est curieux sans ça) - supervision (comment tu test ton DNS sur l'IP anycast sinon?) - etc. Pour garantir l'intégrité du service, le plus simple est de monitorer en interne sur le serveur le service qu'il est censé rendre. Typiquement un truc comme si le DNS tombe, tuer le routage OSPF. prenons un exemple au pif: tu mets 2 3 plateformes dns repartie en france, en fonction des poids des liens tu tombes tjs sur la même plateforme la plus proche de toi (reduction de la latence des requettes dns, meilleur websurfing tout ca) l'ip est annoncée par un loadbalancer qui monitor une ferme de dns a qui il envoie les requettes des abonnées celui-ci arrete d'annoncer l'ip anycast dns si aucun serveur ne repond ou si il n'a plus de serveurs. ce qui entraine automatiquement un reroutage sur les autres plateformes en resumer pour moi le mieux c'est : - anycast = pour du multihoming a l'intérieur d'un réseau - load balancer = pour repartir la charge des serveurs d'une plateforme rataché à un même routeur apres tu peux apliquer ca a plein de truc, serveur de firmware, serveur dhcp, serveur de log, serveur web Benjamin. -- GANDER Frédéric [EMAIL PROTECTED] - http://www.free.fr --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Anycast
On 23/01/2008 16:20, Greg VILLAIN wrote: Je cherche des retours d'expérience sur AnyCast en cas concrêt, quelqu'un a ca ? C'est marrant que t'en parle maintenant parceque je me suis ammusé à faire ca sur une paire de dns récursif qui sont sur des subnet différents. L'idée étant dans mon cas de faire du failover. En mettant les metric égaux sur les deux on pourrait appeler ca de l'anycast si on veut :) Les deux machines sont sur des subnet différents x.x.126.0/25 et x.x.127.1/25 sur un réseau en OSPF. Le 1er linux que je nomme rdns1 : inet x.x.126.1/25 brd x.x.126.127 scope global eth0 inet x.x.126.254/32 scope global eth0 # 1e ip anycast inet x.x.127.254/32 scope global eth0 # 2e ip anycast Le 2nd linux que je nomme rdns2 : inet x.x.127.1/25 brd x.x.127.127 scope global eth0 inet x.x.126.254/32 scope global eth0 inet x.x.127.254/32 scope global eth0 La on remarque les /32 qui sont à la fois sur les deux linux. Je fais tourner un quagga dessus, qui annonce les IP des services à anycaster ... router ospf ospf router-id x.x.126.1 log-adjacency-changes redistribute connected metric 240 route-map OSPFCONNECTED network x.x.126.0/25 area 0.0.0.51 ! access-list RDNS1 permit x.x.126.254/32 access-list RDNS2 permit x.x.127.254/32 ! route-map OSPFCONNECTED permit 10 match ip address RDNS2 set metric 500 ! route-map OSPFCONNECTED permit 100 Il en ressort que rdns1 annonce x.x.126.254/32 avec un metric de 240 et x.x.127.254/32 avec un metric de 500. J'ai fait l'inverse sur rdns2. Ce que le cisco juste devant voit : #sh ip route ospf O E2x.x.127.254/32 [110/240] via x.x.127.1, 1w0d, GigabitEthernet1/0.127 O E2x.x.126.254/32 [110/240] via x.x.126.1, 1w0d, GigabitEthernet1/0.126 En cas de coupure d'un serveur l'ospf met un peu de temps a converger (le temps qu'il s'apercoive que le serveur a disparu) mais ca se tune. Ca marche plutot bien pour des services en UDP, par contre en TCP c'est à éviter si la machine qui recoit les réponses n'est pas la meme qui a envoyé la requete c'est moyen ! Il faut aussi que le dns récursif fasse ses propres requetes dns depuis l'IP réelle de la machine et non l'ip en anycast ! sinon c'est un autre qui risque de recevoir la réponse. a+ Cédric Tabary --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Anycast
On Wed, Jan 23, 2008 at 04:20:17PM +0100, Greg VILLAIN wrote: Salut, Je cherche des retours d'expérience sur AnyCast en cas concrêt, quelqu'un a ca ? ca marche tres bien pour du dns. par exemple ;) J'ai lu les prez du gars de PCH et quelques autres qui sont excellentes, mais je souhaite rentrer dans le détail, genre protocoles de routage entre les serveurs et les routeurs core pour annoncer leurs loopbacks, comment on synchronise le contenu sur les serveurs qui partagent la même loopback anycast. Bref, je prends tout ce que vous avez sur le sujet :) A vot' bon coeur Greg VILLAIN --- Liste de diffusion du FRnOG http://www.frnog.org/ -- GANDER Frédéric [EMAIL PROTECTED] - http://www.free.fr --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Anycast
On Jan 23, 2008, at 5:29 PM, Cedric Tabary wrote: On 23/01/2008 16:20, Greg VILLAIN wrote: Je cherche des retours d'expérience sur AnyCast en cas concrêt, quelqu'un a ca ? C'est marrant que t'en parle maintenant parceque je me suis ammusé à faire ca sur une paire de dns récursif qui sont sur des subnet différents. L'idée étant dans mon cas de faire du failover. En mettant les metric égaux sur les deux on pourrait appeler ca de l'anycast si on veut :) Les deux machines sont sur des subnet différents x.x.126.0/25 et x.x.127.1/25 sur un réseau en OSPF. Le 1er linux que je nomme rdns1 : inet x.x.126.1/25 brd x.x.126.127 scope global eth0 inet x.x.126.254/32 scope global eth0 # 1e ip anycast inet x.x.127.254/32 scope global eth0 # 2e ip anycast Le 2nd linux que je nomme rdns2 : inet x.x.127.1/25 brd x.x.127.127 scope global eth0 inet x.x.126.254/32 scope global eth0 inet x.x.127.254/32 scope global eth0 La on remarque les /32 qui sont à la fois sur les deux linux. Je fais tourner un quagga dessus, qui annonce les IP des services à anycaster ... router ospf ospf router-id x.x.126.1 log-adjacency-changes redistribute connected metric 240 route-map OSPFCONNECTED network x.x.126.0/25 area 0.0.0.51 ! access-list RDNS1 permit x.x.126.254/32 access-list RDNS2 permit x.x.127.254/32 ! route-map OSPFCONNECTED permit 10 match ip address RDNS2 set metric 500 ! route-map OSPFCONNECTED permit 100 Il en ressort que rdns1 annonce x.x.126.254/32 avec un metric de 240 et x.x.127.254/32 avec un metric de 500. J'ai fait l'inverse sur rdns2. Ce que le cisco juste devant voit : #sh ip route ospf O E2x.x.127.254/32 [110/240] via x.x.127.1, 1w0d, GigabitEthernet1/0.127 O E2x.x.126.254/32 [110/240] via x.x.126.1, 1w0d, GigabitEthernet1/0.126 En cas de coupure d'un serveur l'ospf met un peu de temps a converger (le temps qu'il s'apercoive que le serveur a disparu) mais ca se tune. Ca marche plutot bien pour des services en UDP, par contre en TCP c'est à éviter si la machine qui recoit les réponses n'est pas la meme qui a envoyé la requete c'est moyen ! Il faut aussi que le dns récursif fasse ses propres requetes dns depuis l'IP réelle de la machine et non l'ip en anycast ! sinon c'est un autre qui risque de recevoir la réponse. a+ Cédric Tabary Ah bin DNS c'est un bon exemple, les roote-servers I, J, K, L, M sont en anycast - me semble-t-il. Greg VILLAIN --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Anycast
Le Wed, Jan 23, 2008 at 05:36:06PM +0100, Greg VILLAIN [EMAIL PROTECTED] a écrit: [...] Ah bin DNS c'est un bon exemple, les roote-servers I, J, K, L, M sont en anycast - me semble-t-il. Et les récursifs chez certains FAI :-) Dom PS: t'abuses, t'aurais pu tailler dans la citation, pour ta réponse :) -- Dominique Rousseau Neuronnexion, Prestataire Internet Intranet 57, route de Paris 8 Amiens tel: 03 22 71 61 90 - fax: 03 22 71 61 99 - http://www.neuronnexion.fr --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Anycast
On Jan 23, 2008, at 5:29 PM, Cedric Tabary wrote: On 23/01/2008 16:20, Greg VILLAIN wrote: Je cherche des retours d'expérience sur AnyCast en cas concrêt, quelqu'un a ca ? C'est marrant que t'en parle maintenant parceque je me suis ammusé à faire ca sur une paire de dns récursif qui sont sur des subnet différents. L'idée étant dans mon cas de faire du failover. En mettant les metric égaux sur les deux on pourrait appeler ca de l'anycast si on veut :) Les deux machines sont sur des subnet différents x.x.126.0/25 et x.x.127.1/25 sur un réseau en OSPF. Le 1er linux que je nomme rdns1 : inet x.x.126.1/25 brd x.x.126.127 scope global eth0 inet x.x.126.254/32 scope global eth0 # 1e ip anycast inet x.x.127.254/32 scope global eth0 # 2e ip anycast Le 2nd linux que je nomme rdns2 : inet x.x.127.1/25 brd x.x.127.127 scope global eth0 inet x.x.126.254/32 scope global eth0 inet x.x.127.254/32 scope global eth0 La on remarque les /32 qui sont à la fois sur les deux linux. Je fais tourner un quagga dessus, qui annonce les IP des services à anycaster ... router ospf ospf router-id x.x.126.1 log-adjacency-changes redistribute connected metric 240 route-map OSPFCONNECTED network x.x.126.0/25 area 0.0.0.51 ! access-list RDNS1 permit x.x.126.254/32 access-list RDNS2 permit x.x.127.254/32 ! route-map OSPFCONNECTED permit 10 match ip address RDNS2 set metric 500 ! route-map OSPFCONNECTED permit 100 Il en ressort que rdns1 annonce x.x.126.254/32 avec un metric de 240 et x.x.127.254/32 avec un metric de 500. J'ai fait l'inverse sur rdns2. Ce que le cisco juste devant voit : #sh ip route ospf O E2x.x.127.254/32 [110/240] via x.x.127.1, 1w0d, GigabitEthernet1/0.127 O E2x.x.126.254/32 [110/240] via x.x.126.1, 1w0d, GigabitEthernet1/0.126 En cas de coupure d'un serveur l'ospf met un peu de temps a converger (le temps qu'il s'apercoive que le serveur a disparu) mais ca se tune. Ca marche plutot bien pour des services en UDP, par contre en TCP c'est à éviter si la machine qui recoit les réponses n'est pas la meme qui a envoyé la requete c'est moyen ! Il faut aussi que le dns récursif fasse ses propres requetes dns depuis l'IP réelle de la machine et non l'ip en anycast ! sinon c'est un autre qui risque de recevoir la réponse. Par contre, comment tu fais quand le service sur une bécane du cluster vautre et que la bécane est toujours UP ? Faut que t'enlèves la route à un moment non ? Y'a un moyen propre de le faire sans poller le service régulièrement pour descendre la LB et la remonter quand le service reprend ? Greg VILLAIN--- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Anycast
Le Wed, Jan 23, 2008 at 05:37:12PM +0100, Frédéric Gander: On Wed, Jan 23, 2008 at 04:20:17PM +0100, Greg VILLAIN wrote: Salut, Je cherche des retours d'expérience sur AnyCast en cas concrêt, quelqu'un a ca ? ca marche tres bien pour du dns. par exemple ;) Avec quelques bémols cependant: - tant que le DNS reste en UDP, aucun soucis - quand le DNS voudra passer en TCP, on peut croiser des problèmes - la solution dépendra de ce que savent faire des routeurs. Quelques solutions simples: - ne jamais mettre plus d'un DNS par routeur, et du coup, sauf accident, un client DNS tapera toujours sur le même serveur, et donc le passage en TCP fonctionnera magiquement (sauf un cas précis: si le trafic DNS est rerouté suite à un crash pendant une requête en TCP, pas dramatique, en moyenne) - quand tu as plusieurs DNS sur le même routeur, veiller à ce que le routeur répartisse le trafic sur les deux serveurs, et que le trafic d'un client donné aille toujours sur le même serveur (pour se ramener au point précédent). Je ne maitrise pas assez bien les finesses OSPF/BGP des différents équipementiers pour indiquer les règles exactes de config, mais en général ça marche assez facilement. Le point clef est d'avoir une IP, qui ne soit pas en anycast, pour le pilotage: - réplication du contenu (requêtes récursives dans le cas du DNS) - admin de la machine (oui, en anycast, c'est curieux sans ça) - supervision (comment tu test ton DNS sur l'IP anycast sinon?) - etc. Pour garantir l'intégrité du service, le plus simple est de monitorer en interne sur le serveur le service qu'il est censé rendre. Typiquement un truc comme si le DNS tombe, tuer le routage OSPF. Benjamin. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Anycast
On 23/01/2008 17:46, Greg VILLAIN wrote: Par contre, comment tu fais quand le service sur une bécane du cluster vautre et que la bécane est toujours UP ? Faut que t'enlèves la route à un moment non ? Y'a un moyen propre de le faire sans poller le service régulièrement pour descendre la LB et la remonter quand le service reprend ? Je pense à un petit script qui check si le service marche et fait un ip addr del x.x.x.x/32 dev eth0 zebra vire la route de l'ospf immédiatement (testé approuvé) Par contre si on relance le service et qu'il essaye de binder l'ip qu'on vient de virer c'est le serpent qui se mord la queue ! Maintenant un moyen propre ... si quelqu'un a une idée je suis preneur. -- Cédric Tabary --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Anycast
+-Le 23/01/08 22:50 +0100, Cedric Tabary a dit : | On 23/01/2008 17:46, Greg VILLAIN wrote: | Par contre, comment tu fais quand le service sur une bécane du cluster | vautre et que la bécane est toujours UP ? Faut que t'enlèves la route | à un moment non ? Y'a un moyen propre de le faire sans poller le | service régulièrement pour descendre la LB et la remonter quand le | service reprend ? | | Je pense à un petit script qui check si le service marche et fait un | ip addr del x.x.x.x/32 dev eth0 | zebra vire la route de l'ospf immédiatement (testé approuvé) | | Par contre si on relance le service et qu'il essaye de binder l'ip qu'on | vient de virer c'est le serpent qui se mord la queue ! | Maintenant un moyen propre ... si quelqu'un a une idée je suis preneur. Et bien, ça me paraît assez simple, dans ton zebra, au lieu de faire un redistribute connected, tu fait un redistribute connected route-map truc et dans ta route-map truc, tu autorise, ou pas, la redistribution du subnet. -- Mathieu Arnold --- Liste de diffusion du FRnOG http://www.frnog.org/
