Nous avons mis en œuvre une soultion de basculement sur Linux en utilisant DRBD et Heartbeat et cela fonctionne très bien. Maintenant, nous avons un changement d'exigence qui stipule que les nœuds de réplication sont dans différents sous-réseaux, nous n'aurons pas une IP virtuelle commune que nous utilisons lorsque les machines sont sur le même sous-réseau.
Lorsque des nœuds se trouvent dans des sous-réseaux différents, quelle est la meilleure façon de procéder au basculement ?
Il existe plusieurs approches pour mettre en œuvre le basculement entre sous-réseaux ; mais il y a beaucoup de variantes en fonction des exigences exactes. Indépendamment des spécificités, ce que vous semblez essayer d'obtenir est le suivant route santé injection c'est-à-dire l'annonce d'une route vers un service spécifique (généralement par le biais d'un site web). VIP ) en fonction de la santé/disponibilité de ce service.
Voici quelques exemples de mise en œuvre :
par exemple Citrix Netscaler o F5 BIGIP . Ces appliances offrent généralement des ensembles de fonctionnalités très riches. En plus de répondre à vos besoins en matière de haute disponibilité, elles assurent également l'équilibrage des charges entre plusieurs serveurs, ainsi que des fonctions avancées de contrôle de l'état des protocoles d'application bien connus (par exemple HTTP, HTTPS, DNS, etc.). Ils sont toutefois très coûteux.
par exemple Quagga o XORP . Avec un peu de script, ces démons peuvent fournir un sous-ensemble de la fonctionnalité des appareils ci-dessus, sans les coûts associés. Si vous configurez votre réseau pour accepter les mises à jour de routage dynamique de vos hôtes, et mettez quelques scripts qui vérifient périodiquement la santé de vos services, cela vous permettra d'annoncer conditionnellement une route vers un VIP depuis chacun de vos serveurs réels. Quelques considérations ici :
Une clarification des exigences/contraintes dans votre situation pourrait être utile. Quelques questions :
Cette page de liste de diffusion traite de l'utilisation des annonces de routage RIP pour permettre aux serveurs de répondre à une adresse IP commune même s'ils se trouvent sur des sous-réseaux différents. Vous aurez besoin d'un peu de magie de routeur pour que cela fonctionne.
http://www.gossamer-threads.com/lists/linuxha/users/31977#31977
Si vous n'avez pas peur d'un petit temps d'arrêt, vous pouvez utiliser des entrées DNS avec des TTL courts. Il suffit de mettre à jour l'enregistrement DNS pour changer de serveur.
Nous y sommes parvenus en faisant en sorte que nos serveurs linux agissent comme un routeur (en utilisant zebra + ospf).
Voici quelques détails si cela intéresse quelqu'un
Réplication DRBD utilisant un sous-réseau différent annoncé sur l'interface lo:1 des deux machines.
-J'ai une IP virtuelle configurée sur lo:2 qui bascule sur le réseau.
- Pour le battement de cœur, utilisez l'unicast pour parler à l'autre nœud.
La dernière fois que j'ai eu cette exigence, j'ai utilisé une IP par machine, liée à la machine et une "IP de service" (c'est l'IP que les clients ont configurée comme l'IP du serveur). J'ai utilisé ultramonkey pour surveiller le service et gérer le basculement, Zebra pour interagir avec le protocole de routage (en injectant des routes /32 pour toutes les IP de service ; nous avions plusieurs services qui devaient être déplacés, l'hôte primaire pour chaque service était basé sur la proximité physique des clients).
Les serveurs étaient situés à Londres, au Royaume-Uni, et quelque part en Californie, aux États-Unis (non, je ne me souviens pas exactement où, je n'ai jamais posé les yeux dessus), avec des tunnels GRE assurant la connectivité inter-réseau (les deux sites avaient un accès indépendant à Internet).
Nous n'avons cependant pas utilisé la réplication continue des données, car le service fonctionnerait très bien avec une réplication des données toutes les heures environ (il s'agit principalement de lecture, et peu d'écriture). La réplication se faisait de "IP physique" à "IP physique".
SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.
