Je voudrais commencer mon reseau par un server de stockage digne de ce nom. J'ai bien pensé à un peu de RAID, mais j'ai remarqué que les pannes d'alim étaient presque aussi fréquentes que les pannes de disque dans les salles non climatisées. Donc, mon premier besoin pour mon chez moi est désormais: la redondance de machine NFS.
Je voudrais donc mettre en place un server NFS redondant. Les deux servers devront être synchronisés en permanence l'un sur l autre, de sorte que si une écriture est effectuée par un client, et qu'un server crashe immediatement, la donnee écrite soit valide sur l'autre server.
De mémoire, le load balancing classique consiste à avoir un service installe sur deux machines, souvent un httpd, et quand une machine tombe, l autre prend sa place. Mais la je parle de server de stokage pour un reseau! Et ce concepte ne me parait pas fiable en ce qui concerne un sever NFS.
Je me disais que peut être il faudrait que mes 2 ( ou 3) servers présentent leurs disques comme des volumes virtuels, qui soient ensuite assembles virtuellement en Raid1, avec chacun 2 cartes réseau: une chacun sur le reseau commun, avec la meme IP, leur seconde carte étant reliées avec un cable croise pour qu'ils puissent se parler entre eux, sans perturber le réseau ... ce qui authorise par devant un access 100mb, ou chaque server est attaquable sur la meme IP, donc mountable facilement, et par derriere, un lien 100mb pour les synchros entre eux.
NB: je suis pret a mettre 3 cables croises si il faut 3 machines ...
Mon but est d'essayer un sever NFS virtuellement infaillible et tolérant aux pannes matérielles.
Sinon j'ai pense à planquer les servers NFS sur un sous reseau à part, mais ça oblige que ce reseau ait un load balancer, et que tout tombe si l'alim du load balancer lache, à moins de mettre plusieur passerelles en parallele en relai, mais la ca devient un truc de malade ... et je n ai pas non plus 1000 machines a dispo chez moi: 2 severs NFS+2 passerelles locales+une passerelle de tete, rien que pour de la repartition de service de stockage ... je trouve ça beaucoup ... mais c'est peut être ce dont j ai besoin ? ou la seule solution à mon problème ?
Mais une fois que cette histoire de NFS sera classée, je pense que les autres services se metront en place tout seuls:
- tunnel v6
- MySQL
- apache
- LDAP
tout devant etre redondant évidement :)
mais je mettrai très probablement plusieur services par machine.
Le prolème éternel sera toujours la passerelle de tete sur la freebox: est-il possible d'avoir une redondance sur la passerelle ? (tj en cas de panne d'alim)
Au passage: y a t'il des solutions de réplication/balancing pour LDAP et MySQL multisites ?
genre deux sites proposent le meme service (MySQL+LDAP), et quand un site plante (souvent pour connection cassée), les clients sont redirigés DE MANIERE TRANSPARENTE vers l autre site ...
j imagine bien que si les 2 sites doivent etre synchro, cela va engendrer des lags enormes, mais dans mon cas, la perenite est plus importante que le temps de réponse.
Forum général.général Load Balancer ?
14
juin
2005
# coda ?
Posté par elephpant . Évalué à 3.
pour répondre partiellement à ton problème/projet, il y a un système de fichier qui fais de la réplication, c'est CODA
Il permet de faire de la réplication de données sur le réseau mais propose également un mode de reprise après incident (panne d'un des noeuds par exemple) et également une synchronisation des données offline (pour les clients mobiles parexemple)
http://www.coda.cs.cmu.edu/ljpaper/lj.html
il y a eu déjà 2 articles la dessus dans linux magazine (mais je ne me rappelle plus les numéros et comme je suis en plein déménagement ....)
# DRBD +HeartBeat
Posté par Xarli (site web personnel) . Évalué à 4.
Ce type de système couplé avec HeartBeat [2] te permet de partager des ressources, y compris le disque DRBD, avec en plus des adresses IP virtuelles sur lesquelles tu attaques ton service, et d'autres services qui servent les données redondantes (une base de données, un démon NFS ou Samba, un serveur Web, ...). Bref, c'est une solution de partage de ressource à coût réduit que j'ai mis en place plusieurs fois, et qui donne entière satisfaction.
Physiquement, tu as juste besoin d'une liaison directe (plus tu as de données susceptibles d'être modifiées, plus tu as logiquement besoin d'une bande passante en rapport, donc pour partager des données de cette manière sur le net, c'est pas terrible, toutefois j'ai pas essayé, si quelqu'un a une expérience là dessus...), et une bonne idée est de mettre en place un cable null-modem entre les machines pour le battement de coeur. Tu peux mettre plusieurs services par machine, y compris plusieurs disques virtuels DRBD
C'est assez efficace, pas trop compliqué à mettre en place je trouve, je n'ai pas eu de problème avec jusque là, par contre pour ta problématique sur le net, je ne suis pas trop sûr que cela convienne.
[1] : http://www.drbd.org/(...)
[2] : http://www.linux-ha.org/(...)
how-to (un peu vieux) : http://www.slackworks.com/~dkrovich/DRBD/(...)
[^] # Re: DRBD +HeartBeat
Posté par doublehp (site web personnel) . Évalué à 1.
cela veut il dire que tu est favorable pour mettre 2 ou 3 cartes reseau dans les dites machines de stokage ?
pour partager des données de cette manière sur le net, c'est pas terrible,
je separe deux choses:
- un stokage de gros volume (10 a 100G) sur un NFS local a mon reseau, mais tolerant aux problemes d alim
- un stokage de petit volume (principalement LDAP et 10 a 100Mo de donnees utilisateur) redondant entre plusieur connection internet, et c est pas grave si ca rame violent.
dans le premier cas, drbd est indispensable, dans le second, il est suffisant :)
[^] # Re: DRBD +HeartBeat
Posté par Xarli (site web personnel) . Évalué à 1.
Complètement, une liaison directe par cable croisé, avec comme bande passante au moins la bande passante maximale théorique de tes services (pour pouvoir synchroniser en quasi-temps réel les données qui seraient déposées sur le disque virtuel vers le second noeud).
Le plus gros volume DRBD de données que j'ai en production est de 60 gigas, je pense que cela devrait passer, en général sur ce type de service, les lectures sont plus courantes que les écritures (= le volume à maintenir synchrone sera nettement plus petit que le volume total de données).
principalement LDAP et 10 a 100Mo de donnees utilisateur
Pour le volume de 10 à 100 mégas, n'hésite pas à partager ton expérience, mais comme dit au dessus, s'il y a trop d'écritures sur le(s) volume(s) ou bien un temps de latence trop important ça parait compliqué à mettre en oeuvre...
Pour LDAP, tu as envisagé des solutions de réplications gérées par ton démon lui même? ( http://www.openldap.org/doc/admin22/replication.html(...) ). Pas essayé, mais ça parait plus adapté à une liaison avec une petite bande passante.
# load-balancing ou haute-disponibilité
Posté par xcave . Évalué à 3.
L'acronyme de base de la haute-disponibilité est no SPOF - no Single Point Of Failure - et pour l'atteindre on double les éléments (redondance). Pour de la redondance - et pour simplifier - dans un même serveur on parle en général de serveur à tolérance de panne, alors que lorsqu'on double les serveurs on parle de haute-disponibilité.
Donc, si j'identifie bien ton probléme, tu aurais besoin de haute-disponibilité. DRDB, plus que du RAID, répondra à ton besoin associé à heartbeat ( logiciel qui permet de détecter les pannes entre les serveurs et de réagir ). Jette un oeil sur http://linux-ha.org, le site référence de la haute-disponibilité OpenSource, le soucis que tu vas avoir avec leur solution se nomme STONITH qui nécessite d'avoir des power switch.
La solution qui consiste à avoir la même adresse IP sur deux serveurs distincts se nomme l'IP ALIAS. Très simple à mettre en oeuvre, plus d'infos disponible à partir du site précédent.
bon courage
[^] # Re: load-balancing ou haute-disponibilité
Posté par doublehp (site web personnel) . Évalué à 0.
pour l aliasing, je suis habitue a voler les IP des autres PC du reseau ... le probleme qui se posera pour moi est que si deux machines sur la meme IP proposent le meme service, il y aura une violente concurrence ... et quand un server tombe, les requettes en cours de traitement auront des identificateurs inconnus de l autre ... donc les clients qui etaient sur celui qui tombe vont souffrire ... c etait juste une idee, et franchement, je la pensais irrealisable en production. Suffit de penser a un NFS: si je mount server1, et qu il tombe, server2 ne conaitra pas le client, et pourtant le ping marchera ... je pense que le client sera grave perdu ... ou tout au moins aura 5 minutes de timeout avant de se remettre en forme.
[^] # Re: load-balancing ou haute-disponibilité
Posté par xcave . Évalué à 2.
Ton problème de panne de courant existe de toute façon avec ou sans 'power switch', et ne peux pas être résolu par logiciel. (utilisation de générateur , abonnement à deux fournisseurs de courant distinct ... ).
Les problèmes de reprises après crash sont gérés par les systèmes de fichiers journalisés. EXT3, ReiserFS, JFS, XFS ou bien d'autres encore. Il n'y pas de soucis majeur à avoir concernant ce point, quelque soit la solution que tu retiennes (serveurs NFS, DRDB , RAID ou autres) car à moins d'utiliser CODA ou OpenGFS, en local tu dois utiliser un systèmes de fichier journalisé.
L'adresse IP du service est active uniquement sur UN serveur à la fois et elle bascule en cas de crash sur le serveur survivant. Deux solutions utiliser un mechanisme pour mettre à jour les caches ARP qui permettent de diminuer les temps de reprises pour les clients connectés ou utiliser le MAC Address Takeover.
Quand aux transactions en cours sur un serveur elles sont soient dans le log du système de fichier journalisé et dans ce cas pas de probléme. Soient elles ne sont pas encore traitées et elles sont perdues, le client doit refaire sa requête. C'est la que la mise à jour des caches ARP ou le MAC Address Takeover entre en jeux, qui permet -pour simplifier -aux clients qui étaient connectés d'envoyer une requête qui aboutie sur le serveur qui dispose de la bonne adresse IP.
[^] # Re: load-balancing ou haute-disponibilité
Posté par doublehp (site web personnel) . Évalué à 1.
Mon frere travaille chez Louis Vuitton, siege social face a la Samaritaine (Paris, 1er) (LV possede la Samaritaine, mais leur siege est enface), et le service informatique a deux compteurs EDF: un Nord, un SUD. Ces compteurs EDF sont relies a deux centrales nucleaires differentes :), car cet immeuble se trouve sur la frontiere de separation nord/sud des secteurs EDF, et qu a une epoque, cet immeuble la a ete cable sur les deux zones.
Je pense que meme a Paris tres peu d immeubles ont ce privilege.
Mais je ne sais pas si le basculement entre les deux sources au possible rapidement.
Les problèmes de reprises après crash sont gérés par les systèmes de fichiers journalisés.
J utilise XFS depuis a peu pres 2001 ... mais aujourd hui, je me tape des crashes machines ... je ne travaille que la perenite de service ... apres si une machine met 10mn ou 1h a rebooter, je m en tape, tant qu une autre prend le relai.
L'adresse IP du service est active uniquement sur UN serveur à la fois et elle bascule en cas de crash sur le serveur survivant.
ca me plait pas du tout, parce que j imagine que quand une machine tombe, il y a un down time assez grand pour les clients (je pense dans les 10s ... )
Le mac takover me fait pas peur, je le pratique deja en Wifi .. ( ca aide pour causer aux DHCPs), mais il reste que les clients auront des requettes non satisfaites ... et devront redemander des tiquets ...
Quand aux transactions en cours sur un serveur elles sont soient dans le log du système de fichier journalisé et dans ce cas pas de probléme.
la ou la va coincer, c est si la requette a ete traitee, a ete logueee localement, mais que le log n a pas ete propage aux autres servers au moment du crashe: le server 2 va donc prendre le relai, le client aura ete satisfait, mais le client aura 'de l avance' sur le server nouvellement actif ...
si le dit client est un server MySQL, ou mail ... j ose pas imaginer les problemes de sync quand le server crashe va revenire ...
PS: je ne parle ici que du server de STOKAGE ... MySQL et apache sont pour moi des clients.
car apres tout, une fois qu on a un bon NFS, j imagine que du load balancing classique pour les autres services est suffisant ... voire du roudrobin ... mais le stokage me parait un probleme critique.
[^] # Re: load-balancing ou haute-disponibilité
Posté par xcave . Évalué à 1.
dans ca cas il faut t'orienter vers une solution de partage de disques entre les deux serveurs , mais à ma connaissance aucune solution pereine n'existe sous linux. Compaq a travailler dessus il y a quelques années mais a depuis abandonné cette solution.
[^] # Re: load-balancing ou haute-disponibilité
Posté par xcave . Évalué à 1.
dans ca cas il faut t'orienter vers une solution de partage de disques entre les deux serveurs , mais à ma connaissance aucune solution pereine n'existe sous linux. Compaq a travailler dessus il y a quelques années mais a depuis abandonné cette solution.
[^] # Re: load-balancing ou haute-disponibilité
Posté par doublehp (site web personnel) . Évalué à 0.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.