Bonjour à tous,
je dois mettre en place une solution de failover sur une application critique composée d'un serveur web/applicatif (debian/appli java) et un serveur de base de données (debian/mysql).
Le système doit pouvoir palier tout type de panne :
- en cas de coupure réseau (au niveau du des élements actifs du réseau local, du datacenter lui-même)
- en cas de panne système/hardware
- plantage de l'applicatif - point le plus probable :(
- attaque nucléaire, extraterrestre ou autre - mais je pense pouvoir gérer ce dernier point... :D
Pour cela je dispose d'une unique machine hébergé dans un autre data-center (donc dans un réseau différent).
1- ma première problématique : Faire du failover sur des réseaux différents uniquement via ethernet...
2- Le deuxième problème est que le système à rendre résistant aux pannes est déjà en prod...
3- Qu'à terme il est possible que je doive également implémenter du load balancing sur l'applicatif...
ça fait 2 jours que je suis dessus... la tête dans le guidon je surchauffe et me perds un peu... :(
et je ne vois toujours pas de solution...
si vous pouviez me faire partager votre expérience ou me donner quelques pistes (ou solutions :D, je suis pas contre !)
d'avance merci de votre soutien...
Forum Linux.debian/ubuntu failover services entre sites distants sous debian
12
juin
2009
# drdb / heartbeat / ...
Posté par nono14 (site web personnel) . Évalué à 2.
Système - Réseau - Sécurité Open Source - Ouvert à de nouvelles opportunités
[^] # Re: drdb / heartbeat / ...
Posté par minimalteck . Évalué à 1.
cependant, ôtes moi ces doutes qui me tiraillent....
- heartbeat ne nécéssite-t-il pas une liaison série ? dans mon cas, ce n'est pas envisageable...
- le channel bonding assure une redondance d'interface réseau sur même machine non ?
peut-être je me trompais-je, et dans ce cas je ne suis pas contre quelques ressources webesque qui rectifient mon ignorance en la matière... ;)
[^] # Re: drdb / heartbeat / ...
Posté par nono14 (site web personnel) . Évalué à 1.
-oui ( http://linux.developpez.com/bonding/ )
Système - Réseau - Sécurité Open Source - Ouvert à de nouvelles opportunités
[^] # Re: drdb / heartbeat / ...
Posté par minimalteck . Évalué à 1.
[^] # Re: drdb / heartbeat / ...
Posté par minimalteck . Évalué à 1.
par contre - je suis un boulet... je l'avoue -
le channel bonding entre "interfaces de réseaux distants"
ben je comprends toujours pas comment on fait.... 8(
si t'as 2 minutes pour m'expliquer ou un lien magique à destination des neuneus... :D
[^] # Re: drdb / heartbeat / ...
Posté par nono14 (site web personnel) . Évalué à 1.
Ensuite c'est ip qui prend le relais.C'est le rôle des routeurs ( bgp/ospf) d'assurer
que tout va bien.
La magie en informatique ça n'existe pas. :-;
Système - Réseau - Sécurité Open Source - Ouvert à de nouvelles opportunités
# 2 datacenter separés = 2 plan IP separé
Posté par NeoX . Évalué à 2.
en tout cas pas en temps reel
deja regarde pour monter ta nouvelle machine avec l'appli et la base de données
faire en sorte que ca marche bien
ensuite reflechis à la synchro entre la machine de prod et le backup (failover)
ensuite tu pourras essayé de faire une bascule en automatique (peut-etre au niveau des DNS) le jour ou cela tombe en panne
[^] # Re: 2 datacenter separés = 2 plan IP separé
Posté par minimalteck . Évalué à 1.
une nouvelle install de l'appli/donnée ne devrait (je préfère au conditionnel) pas poser de pb
pour la synchro, je pensais à du simple rsync ou de l'unison et de la replication mysql pour les bases...
qt à la solution dns failover, le pb, c'est la latence de propagation de la mise à jour...
même avec un ttl faible... on ne peut pas espérer des résultats fantastiques...
l'interruption si il y en a une... doit être minimale... et sachant que c'est une appli qui concernent des clients des 4 coins de la planète... j'ai du écarter cette solution... :(
[^] # Re: 2 datacenter separés = 2 plan IP separé
Posté par NeoX . Évalué à 2.
il faut alors que tu regardes les solutions à base d'IP virtuelle
ta machine en prod dispose d'une IP "vraie"
et d'une ip virtuelle
la machine backup interroge le service afin de savoir si la prod est en route
sinon, elle reprend cette ip virtuelle
cette solution fonctionne tres bien dans un meme datacenter car le routage vers cette ip virtuelle ne change pas (ma machine ici par exemple parlera touours au meme routeur pour acceder à ton datacenter, donc la bascule est transparente)
par contre entre 2 datacenters ?
je crains qu'il faille jouer avec les routeurs pour dire que finalement cette ip virtuelle ne se trouve plus dans ce datacenter...
et si tu joue avec les tables de routages, tu auras aussi un temps de propagation
enfin, je dis ca dans le cas ou les 2 datacenters sont dissocié l'un de l'autre
si tu as un lien permanent et "interne" à ton reseau entre les 2 datacenters
la problematique ne se pose presque plus
[^] # Re: 2 datacenter separés = 2 plan IP separé
Posté par minimalteck . Évalué à 1.
et il n'y a pas à priori possibilité d'avoir de liaison privée entre les 2...
[^] # Re: 2 datacenter separés = 2 plan IP separé
Posté par Frederic Bourgeois (site web personnel) . Évalué à 1.
C'est valable pour Ucarp ou keepalived par exemple
[^] # Re: 2 datacenter separés = 2 plan IP separé
Posté par palm123 (site web personnel) . Évalué à 5.
>>>en tout cas pas en temps reel
C'est là qu'on se dit que certaines technos propriétaires sont bien foutues, je pense au Cluster VMS
Après le 11 Septembre, aux US, ils envisageaient des Clusters VMS sur 800 Kms de distance (le max vu la latence maximum du protocole Cluster (60-07 sous Ethernet) justement en cas d'attaque nucléaire sur New York par exemple, avoir de la redondance immédiate (juste une Cluster transition, de l'ordre de 1 minute, c'est paramétrable)
>>>ensuite reflechis à la synchro entre la machine de prod et le backup (failover)
Dans un Cluster à la VMS, toutes les machines (prod et backup) ont les mêmes données, il n'y a rien à faire.
C'est un sacré avantage par rapport à tous les plans de reprise/de continuité d'activité, dans lesquels on se rend compte un peu tard qu'on a oublié un truc ou un autre.
Dans l'incendie du Crédit Lyonnais, il y avait des machines(3 de mémoire) boulevard des Italiens (Paris 2 ème) et les machines de secours chez GSI à Suresnes.
L'incendie a eu lieu le week-end, et ca a coûté très cher à certains traders qui avaient parié que le Crédit Lyonnais ne pourrait pas honorer ses positions le lundi matin. Pas de souci, toutes les données étaient là.
Le 11 septembre, le seul Cluster Vms qui n'a pas survécu avait ses machines dans les 2 tours (boulette)...tous les autres ont repris sans perte de données.
Le libre propose des choses proches, je ne sais pas où en sont les projets OpenSSI, OpenMosix ou Kerrighed.
ウィズコロナ
# voir avec ton fai ?
Posté par masterfrog . Évalué à 2.
Comme dit dans un poste précédent , la modif du dns va prendre du temp a se propager. Il reste donc le déplacement de l'ip entre tes deux machines. Pour que le routage fonctionne il faut que le routage de ton ip publique soit modifié ...
Entre solution : un reverse proxy/faillover (clusterisé) de préference chez un opérateur ...
A mon avis pas de solution miracle à bas cout...
[^] # Re: voir avec ton fai ?
Posté par minimalteck . Évalué à 1.
je sais pas dans quelle mesure c'est possible de négocier....
un reverse proxy... effectivement, c'est une piste à laquelle je n'avais pas songée...
merci, je sors ma pelle et je creuse la question ;)
[^] # Re: voir avec ton fai ?
Posté par masterfrog . Évalué à 1.
# Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Architecture possible
Posté par -=[ silmaril ]=- (site web personnel) . Évalué à 2.
>fois sur 2 car 2 ip's retournées par le DNS) cela donne un uptime, à la louche, de 99,94%.
>As-tu vraiment besoin de mieux que ça ?
>Si c'est le cas, je te souhaite bon courage...
C'est le problème courant: combien est-tu prêt à mettre pour ton PRA/HA
sachant que rien n'est magique et que la solution "ultime" est souvent a base
de BGP et d'un lien privé d'interconnection entre tes deux sites pour la synchro.
Et que tu ne bascule pas ce genre d'archi avant moins de 20min d'interruption.
Si tu a besoin de plus et si ton problème est lié à l'application il est beaucoup plus
efficace et moins cher de disposer d'une archi HA sur le même datacenter (et garder
une archi "PRA" sur un autre datacenter si besoin).
Le HA en local se fait très bien, a base de VRRP/Keepalive souvent il permet des reprises
de services <1s (+délai de détection, et attention au flapping).
Le PRA en distant permet de se prémunir des derniers "risques"
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.