La haute dispo, ou comment dormir la nuit

A force de créer des machines virtuelles pour offrir du service, il fallait penser aussi à offrir de la qualité de service. rapide calcul, 40 VM stocké sur un serveur NFS, il est peut etre temps d'avoir un peu plus qu'un PRA depuis des backups.

Et puis le serveur NFS, il a besoin de place, ces VM, ca a un appetit sans fin!

Au debut ca marche, et plus le temps passe, plus la co**le va finir par arriver. C'est comme pour les backups, sauf que la, je vais pas attendre.

Les promesses

  • NFS4 ca permet la replication des données. directement configuré coté client.

/data -vers=4,replicas=/data@account1:/backup/data@inreserve

Sauf que le replicat, il est en lecture seule, donc a part pour des cas particuliers comme ces gens qui serveur des pages ouaib, ca va pas me servir des masses.

  • GFS2, OCFS2, MOOSEFS : Leurs avantages, c'est qu'on peut les monter en actif/actif sur deux serveurs en meme temps, et donc y ecrire en meme temps (ceux qui pensent que NFS ca fait pareil, ils vont devoir prendre quelques cours). "Distributed Parallele Fault Tolerent Filesystem", c'est super bien, mais ca demande au moins autant de serveurs differents qu'il y a de mots.

K.I.S.S.: Keep it simple, stupid: DRBD

J'ai pas besoin d'une arme de guerre. j'aimerais avoir un mirroir de mes données en temps reel sur un autre serveur. Pas besoin de 36000 Trasnsactions par seconde sur le serveur. un bon vien RAID1 ca sera suffisant. Ca tombe bien DRBD ca sert à ca. Fallait juste trouver 12h dans une journée.

Plus simple tu meurs

Pour les ceuces qui découvrent l'informatique, drdb, c'est un device, ca s'utilise comme un disque. Et en dessous, on designe les deux serveurs qui vont stocker les données (le local et un distant). Pour la conf , on rajoute une fichier de meme nom que sa ressource dans /etc/drbd.d/.

 resource VMS {
 on serv1 {
   device    /dev/drbd1;
   address   192.168.1.1:7789;
   disk      /dev/sdb1;
   meta-disk internal;
 }
 on serv2 {
   device    /dev/drbd1;
   address   192.168.1.2:7789;
   disk      /dev/sdb1;
   meta-disk internal;
 }
 }

les deux IP sont celles des deux serveurs, sur un lien dédié, mais on peut aussi utiliser les interfaces standard.

C'est a faire sur les deux serveurs Ensuite, on initialise le device: drbdadm create-md VMS et on lance la connexion et synchro avec drbdadm up VMS. Il reste a decider qui sera le serveur primaire: drbdadm primary --force VMS à faire sur le serveur désigné.

Et voila vos pouvez faire un cat /proc/drbd pour voir le status de vos disques.

Passer primaire ou secondaire, synchroniser

L'etat normal est d'avoir un

 cs:Connected ro:Primary/Secondary ds:UpToDate/UpToDate

Pour changer de l'un a l'autre, passer les deux en Secondaire, puis passer le Secondaire en Primaire.

 drbdadm primary  VMS

Pour lancer une synchro:

 drbdadm syncer  VMS

Pour connecter le disque:

 drbdadm connect  VMS

A l'utilisation

Sur le primaire, on met son FS comme un disque classique:

 mkfs.ext3 /dev/drbd1

et roule ma poule

Sur le secondaire, vous ne pouvez rien faire. Meme pas monter le device en lecture seule.

Si votre primaire A tombe, c'est le moment de savoir quoi faire sur le secondaire B:

  • aller sur le secondaire B
  • le passer en Primaire
  • Monter sa partoche

Et quand le A reviendra

  • forcer le A en secondaire
  • synchroniser les données

Et se demander si on reechange A et B