Re: [FRnOG] [MISC] Remplacement solution IOS SLB
Bonjour, Merci pour ces infos utiles Je ferai un retour sur nos tests d'ici quelques temps. Cdt, Le 02/03/2015 18:35, Romain SIBILLE a écrit : Une idée me vient à l'esprit: keepalived (ou ldirectord mais je ne sais pas comment il fonctionne) pourrait placer la VIP sur une interface type loopback, ce qui aurait pour effet d'ajouter une route dans la table de routage de ton loadbalancer (route de type connected, sans next-hop). Ensuite, il suffirait de bien configurer les redistribute de ton daemon de routage, et ton LB serait vu par tes routeurs de coeur comme next-hop pour joindre la VIP. Du coup, le service tombe, keepalived retire la VIP de la loopback, la route connected disparait, et n'est donc plus annoncée par ton IGP à tes routeurs. A tester... et ne pas hésiter à me corriger si je raconte des bêtises... Cordialement, Romain Le 02/03/2015 18:16, Jérôme BERTHIER a écrit : Bonjour, Je vais creuser keepalived. Après un peu de lecture rapide, je vois effectivement qu'on peut déclencher des scripts selon les changements d'état donc influer sur un démon tiers. L'idéal serait de rendre keepalived directement acteur du routage mais ça peut faire l'affaire. Merci pour l'info Le 02/03/2015 17:45, Romain SIBILLE a écrit : Bonjour Jérôme, Je ne sais pas si ça répond exactement à ton besoin, mais keepalived permet plein de choses, comme par exemple lancer des scripts en cas de détection de changement d'état d'un service. As tu exploré cette piste en remplacement de ldirectord? Cordialement Romain Le 02/03/2015 17:18, Jérôme BERTHIER a écrit : Bonjour à tous, Je cherche une solution pour remplacer un service Cisco IOS SLB (test de vie + LB + injection de route). Deux raisons : 1) la feature n'est plus supportée par Cisco depuis longtemps sauf à conserver un IOS très ancien 2) les plateformes matérielles qui traitent le service sont vraiment en fin de vie et non maintenues Actuellement, nous utilisons ce service comme suit : - deux VIP sont dual homées en BGP sur deux sites distants (une VIP prioritaire / site) - sur chaque site : - le service est testé par des probes SLB TCP - les deux VIP sont mappées en priorité sur le serveur réel local puis en backup sur le serveur réel de l'autre site - les deux VIP sont annoncées dans l'aire ospf du site. Ces annonces alimentent les routeurs WAN pour déclencher l'annonce eBGP. - en cas de plantage du service, la VIP tombe, l'annonce ospf disparait, la route disparait sur les routeurs WAN et ça coupe l'annonce eBGP du site concerné. En jouant avec ip sla + nat, on arrive à approcher un fonctionnement similaire mais avec une limite côté NAT statique : impossible de mapper deux VIP (adresse globale) sur une même adresse réelle (adresse locale). Pour l'instant, on met de côté cette solution. En parallèle, on utilise du load balancing Linux LVS. Pour l'instant, on n'a pas trouvé comment attacher l'état ldirectord à un démon ospf. Ce serait pourtant peut être la piste la plus prometteuse. Au final, on a surtout besoin des fonctionnalités test de vie + injection de route. La partie LB est facultative puisque on a déjà un RR DNS. Je précise que, pour l'instant, pas de budget à engager pour cela donc on écarte les produits dédiés type F5, A10... Auriez-vous des pistes à me conseiller d'explorer ? Merci d'avance -- Jérôme BERTHIER --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Remplacement solution IOS SLB
Bonjour, De notre côté, nous utilisons un setup IPVS/LVS-TUN en conjonction avec Keepalived, Quagga, et un peu de scripting en Bash. Cela permet d'envisager en effet une infrastructure de services multihomés, scalable, résiliente aux différents cas de panne/maintenances (realserver, LVS, site entier). Il faut y ajouter un petit outillage d'annonce/suppression de VIP. https://github.com/sfr-network-service-platforms/multihoming-quagga-bgp-mgt A adapter en fonction du contexte (IGP/EGP, logique de poids, techno d'accès choisie en amont - DNS/anycast/whatever, etc.). Au besoin pousser vers des choses un peu plus future-proof avec ExaBGP et une logique applicative solide autour. A la fin ça s'appellera un micro-SDN, mais bon on a déjà dépassé le besoin. -- Pierre Le 3 mars 2015 16:40, Jérôme BERTHIER j...@laposte.net a écrit : Bonjour, En combinant les annonces iBGP conditionnées aux tests de vie avec du NAT pour mapper les VIP vers le serveur réel du site, il me semble que ça répond au besoin. Je vais regarder ça. Merci pour les infos Cdt, -- Jérôme BERTHIER --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Remplacement solution IOS SLB
Bonjour Jérôme, Je ne sais pas si ça répond exactement à ton besoin, mais keepalived permet plein de choses, comme par exemple lancer des scripts en cas de détection de changement d'état d'un service. As tu exploré cette piste en remplacement de ldirectord? Cordialement Romain Le 02/03/2015 17:18, Jérôme BERTHIER a écrit : Bonjour à tous, Je cherche une solution pour remplacer un service Cisco IOS SLB (test de vie + LB + injection de route). Deux raisons : 1) la feature n'est plus supportée par Cisco depuis longtemps sauf à conserver un IOS très ancien 2) les plateformes matérielles qui traitent le service sont vraiment en fin de vie et non maintenues Actuellement, nous utilisons ce service comme suit : - deux VIP sont dual homées en BGP sur deux sites distants (une VIP prioritaire / site) - sur chaque site : - le service est testé par des probes SLB TCP - les deux VIP sont mappées en priorité sur le serveur réel local puis en backup sur le serveur réel de l'autre site - les deux VIP sont annoncées dans l'aire ospf du site. Ces annonces alimentent les routeurs WAN pour déclencher l'annonce eBGP. - en cas de plantage du service, la VIP tombe, l'annonce ospf disparait, la route disparait sur les routeurs WAN et ça coupe l'annonce eBGP du site concerné. En jouant avec ip sla + nat, on arrive à approcher un fonctionnement similaire mais avec une limite côté NAT statique : impossible de mapper deux VIP (adresse globale) sur une même adresse réelle (adresse locale). Pour l'instant, on met de côté cette solution. En parallèle, on utilise du load balancing Linux LVS. Pour l'instant, on n'a pas trouvé comment attacher l'état ldirectord à un démon ospf. Ce serait pourtant peut être la piste la plus prometteuse. Au final, on a surtout besoin des fonctionnalités test de vie + injection de route. La partie LB est facultative puisque on a déjà un RR DNS. Je précise que, pour l'instant, pas de budget à engager pour cela donc on écarte les produits dédiés type F5, A10... Auriez-vous des pistes à me conseiller d'explorer ? Merci d'avance --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Remplacement solution IOS SLB
Une idée me vient à l'esprit: keepalived (ou ldirectord mais je ne sais pas comment il fonctionne) pourrait placer la VIP sur une interface type loopback, ce qui aurait pour effet d'ajouter une route dans la table de routage de ton loadbalancer (route de type connected, sans next-hop). Ensuite, il suffirait de bien configurer les redistribute de ton daemon de routage, et ton LB serait vu par tes routeurs de coeur comme next-hop pour joindre la VIP. Du coup, le service tombe, keepalived retire la VIP de la loopback, la route connected disparait, et n'est donc plus annoncée par ton IGP à tes routeurs. A tester... et ne pas hésiter à me corriger si je raconte des bêtises... Cordialement, Romain Le 02/03/2015 18:16, Jérôme BERTHIER a écrit : Bonjour, Je vais creuser keepalived. Après un peu de lecture rapide, je vois effectivement qu'on peut déclencher des scripts selon les changements d'état donc influer sur un démon tiers. L'idéal serait de rendre keepalived directement acteur du routage mais ça peut faire l'affaire. Merci pour l'info Le 02/03/2015 17:45, Romain SIBILLE a écrit : Bonjour Jérôme, Je ne sais pas si ça répond exactement à ton besoin, mais keepalived permet plein de choses, comme par exemple lancer des scripts en cas de détection de changement d'état d'un service. As tu exploré cette piste en remplacement de ldirectord? Cordialement Romain Le 02/03/2015 17:18, Jérôme BERTHIER a écrit : Bonjour à tous, Je cherche une solution pour remplacer un service Cisco IOS SLB (test de vie + LB + injection de route). Deux raisons : 1) la feature n'est plus supportée par Cisco depuis longtemps sauf à conserver un IOS très ancien 2) les plateformes matérielles qui traitent le service sont vraiment en fin de vie et non maintenues Actuellement, nous utilisons ce service comme suit : - deux VIP sont dual homées en BGP sur deux sites distants (une VIP prioritaire / site) - sur chaque site : - le service est testé par des probes SLB TCP - les deux VIP sont mappées en priorité sur le serveur réel local puis en backup sur le serveur réel de l'autre site - les deux VIP sont annoncées dans l'aire ospf du site. Ces annonces alimentent les routeurs WAN pour déclencher l'annonce eBGP. - en cas de plantage du service, la VIP tombe, l'annonce ospf disparait, la route disparait sur les routeurs WAN et ça coupe l'annonce eBGP du site concerné. En jouant avec ip sla + nat, on arrive à approcher un fonctionnement similaire mais avec une limite côté NAT statique : impossible de mapper deux VIP (adresse globale) sur une même adresse réelle (adresse locale). Pour l'instant, on met de côté cette solution. En parallèle, on utilise du load balancing Linux LVS. Pour l'instant, on n'a pas trouvé comment attacher l'état ldirectord à un démon ospf. Ce serait pourtant peut être la piste la plus prometteuse. Au final, on a surtout besoin des fonctionnalités test de vie + injection de route. La partie LB est facultative puisque on a déjà un RR DNS. Je précise que, pour l'instant, pas de budget à engager pour cela donc on écarte les produits dédiés type F5, A10... Auriez-vous des pistes à me conseiller d'explorer ? Merci d'avance --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Remplacement solution IOS SLB
Le 02/03/15 17:18, Jérôme BERTHIER a écrit : Au final, on a surtout besoin des fonctionnalités test de vie + injection de route. La partie LB est facultative puisque on a déjà un RR DNS. Généralement je fais ça avec exabgp, avec un heathcheck custom. Ça ne fait pas LB, encore que tu puisse activer le mutlipath bgp sur tes routeurs (bon en revanche pas de poids). -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
