3.4 KiB
email: courriel@victor-hery.com date: 2013-04-18T08:44+01:00 author: Victor website: http://blog.xn--hry-bma.com/ replyto: 17md
Hello,
C'est vrai que je n'ai pas précisé en détail le problème d'OpenVZ avec DRBD. En fait, le principal souci est que via DRBD, on gère un système de fichier, et que du côté d'OpenVZ, on gère une arborescence de fichier. Du coup, autant DRBD marche très bien avec KVM (qui est un disque virtuel, pour lesquels DRBD peut utiliser un système d'état de cohérence), autant il a du mal avec l'arborescence OpenVZ. De plus, OpenVZ utilise un dossier "private" où il stocke les fichiers de la VM, et un 2eme dossier "root" où il place les fichiers de la VM quand elle fonctionne, mais qui n'existe plus quand elle est arrêtée, etc.
Et ça, d'expérience DRBD n'aime pas du tout, car il se lance dans des réplications dans tous les sens quand une VM démarre, et ensuite a du mal à retrouver un état de cohérence de disque.
J'ai fait des tests en utilisant un système de fichier lvm fait exprès pour gérer ce genre de souci avec LVM (clvm), mais le problème est que clvm doit être lancé au démarrage de LVM, et comme Proxmox utilise LVM pour ses propres partitions, CLVM se lançait dès le démarrage, c'est à dire avant que DRBD n'ai pu établir sa connexion, ce qui crashait complètement le système (à éviter donc !) C'est une technique qui fonctionnerait sans doute sur une machine sans LVM pour ses partitions (peut être une debian classique avec Proxmox par dessus), mais je n'ai pas été plus loin, Proxmox étant à utiliser pour moi :)
Ce problème pourrait également être réglé avec le nouveau système de fichiers en projet d'OpenVZ, ploop, qui consisterait à utiliser comme KVM un genre de disque virtuel plutôt que directement l'arborescence de fichiers, mais ça pose d'autres soucis (notamment que c'est quand même super pratique pour les backups et les manip' cette arborescence ^^)
Plus précisément pour le tuto de NedProduction, il utilise DRBD uniquement dans un sens, c'est à dire plus à vue de backup. Son deuxième disque ne peut en aucun cas servir à faire redémarrer une machine en étant monté sur le système de secours. Dans un système HA, il faut que les deux côtés du disque puissent être utilisées en écriture par le système (mode "primary" dans DRBD), et donc il s'agit de faire très attention à ce que le PRA n'écrivent rien dessus tant que le serveur principal est encore là (sinon, fort risque de conflit, écriture sur les même secteurs disques, etc, et là, tout plante). NedProduction n'a pas cette problématique et donc ses machines OpenVZ se synchronisent tranquillement sur son deuxième serveur uniquement en lecture, fichier par fichier. Ceci dit, peut être que quelque chose m'a échappé, mais j'ai testé sa configuration, dans une problématique de HA ce n'est pas viable (l'option de synchronisation "C" de DRBD interdit que les deux côté du disque puissent être en écriture)
Pour ce qui est du 3eme article, je suis toujours sur le brouillon, mais ces derniers mois ont été chargés niveau boulot, je n'ai pas eu tout le temps que j'aurai voulu pour me remettre sur les configurations et les tests du tuto... Cependant je ne l'oublie pas !
Voila, j'espère que le problème est un peu plus clair après cette (longue :s) explication. Et merci pour votre lecture :)
A plush'