DRBD + RAID1 : faisable ?

Bonjour,

Voilà, je dispose d’un NAS Dlink avec 2 disques de 1To. Je fais déjà du RAID1 entre ces deux disques.
Ce NAS est fun-pluggé et possède Debian.

J’ai récemment testé DRBD entre 2 clés USB (avec des Raspberry), et ça marche pas mal, avec un seul ‘Primary’ bien entendu.
J’ai également entendu parler de GlusterFS, mais il va falloir que je me documente.

A voir quelle techno j’utiliserais, mais une question survient, est-ce que le schéma suivant vous semble plausible :
http://hpics.li/3cb85e8

L’idée serait donc qu’un disque du RAID (ou le périphérique RAID lui-même, je ne sais pas…) soit défini en tant que périphérique /dev/drbd0 et soit répliqué sur un autre serveur slave… J’ai un doute sur la faisabilité côté NAS en fait…

Merci :slightly_smiling:

Conceptuellement, aucune raison que ça ne marche pas (par contre il vaut mieux utiliser le périphérique RAID comme maître DRBD plutôt qu’un des disques physiques, car même si un disque pète tu as toujours DRBR fonctionnel comme ça).

Techniquement, vu que ta Debian est “par dessus” le système du NAS (chroot ou équivalent), ça veut dire que tu utilises le noyau du NAS et donc il te faut des modules DRBD compatibles avec ledit noyau… Ce qui n’est pas toujours évident car ces systèmes ont tendance à utiliser des noyaux un peu anciens.

Par contre je me pose la question : qu’est-ce que ça va t’apporter d’utiliser DRBD (à part le côté fun :mrgreen:) ? C’est fait pour faire de la réplication de disque en temps réel, dans l’optique d’avoir une machine fail-over prête à prendre le relais dans la seconde qui suit quand la première machine claque.
Pour faire de la “bête” sauvegarde c’est un peu lourd je pense, un bon vieux [mono]rsync[/mono] des familles serait probablement plus adapté. Enfin ce n’est que mon avis. :wink:

Merci beaucoup de ta réponse !

GlusterFS a l’air encore plus simple que Drbd , effectivement Drbd a quelques exigences sur le noyau et mon NAS n’est pas hyper récent, et de plus n’a que 64 Mo de RAM -_-’

Après, tu as un peu raison, as-t-on besoin d’un système comme ça pour les données de 4-5 personnes, je ne suis pas sur ^^.

C’est que je dispose aussi d’un serveur KVM, de machines virtuelles avec disques LVM, et comme je ne sais pas comment les sauvegarder facilement, j’avais dans l’idée d’utiliser un partage NFS sur le RAID1 où je crée mes volumes LVM (même pas sur que ca soit possible, ça lol). Du coup, avec un DRBD paramétré sur le RAID1, mes VMs n’auraient jamais eues de problèmes de disques… Mais peut-être cela va-t-il plus compliquer qu’autre chose, je ne sais pas trop…

Merci encore, en tout cas.

J’avais mis DRBD en place sur un système RAID pour mes études, et je m’était fait un pense bête. je te le laisse à disposition si cela peut t’aider, à adapter à ta configuration

Pré-requit :
‘PTI – HD_Master’ en réseau ‘extnet’ et une deuxième en réseau ‘HA’
‘PTI – HD_Slave’ en réseau ‘extnet’ et une deuxième en réseau ‘HA’
‘PTI – Fedora’ en réseau ‘extnet’

Procédure (à effectuer sur HD_Master et HD_Slave) :
Installation et configuration de mdadm
Lancer apt-get install mdadm --no-install-recommends
Lancer cfdisk /dev/sd*
Sélect. FD
Lancer mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/sdb1 /dev/sdc1
Vérifier cat /proc/mdstat

Installation et configuration de drbd

Lancer apt-get install drbd8-utils
Lancer modprobe drbd
Lancer drbd >> /etc/modules

Créer /etc/drbd.d/r0.res
Contenu :

resource r0 { on hdmaster { device /dev/drbd0; disk /dev/md0; address 10.0.0.1:7789; meta-disk internal; } on hdslave { device /dev/drbd0; disk /dev/md0; address 10.0.0.2:7789; meta-disk internal; } }

Uniquement en cas de problème
Lancer dd if=/dev/zero of=/dev/md0 bs=1M count=128

Lancer drbdadm create-md r0
Lancer drbdadm up r0

Uniquement en cas de problème
Lancer drbdadm disconnect r0
Lancer drbdadm detach r0

Modifier /etc/drbd.d/global_common.conf

Ajouter dans startup {

wfc-timeout 60; degr-wfc-timeout 120;

Ajouter dans syncer {

Lancer /etc/init.d/drbd reload

Uniquement sur le primaire
Lancer drbdadm – --overwrite-data-of-peer primary r0
Lancer drbdadm primary r0
Lancer mkfs.ext4 /dev/drbd0
Vérifier drbd-overview

Uniquement en cas de problème
Problème Standalone :
Lancer sur l’un
drbdadm – --discard-my-data connect all
Lancer sur l’autre
drbdadm connect all
Lancer sur le primaire
drbdadm primary r0

Installation et configuration de heartbeat
Lancer apt-get install heartbeat
Se rendre cd /usr/share/doc/heartbeat
Lancer gzip -d ha.cf.gz
Lancer gzip -d haresources.gz
Lancer cp ha.cf authkeys haresources /etc/ha.d/
Modifier /etc/ha.d/ha.cf

Décomm.

debugfile /var….. logfile /var... keepalive 2 deadtime 30 udpport 694 bcast eth0

Ajouter
node hdmaster hdslave

Modifier /etc/ha.d/haresources
Ajouter
hdmaster 192.168.0.247
hdmaster drbddisk::r0 Filesystem::/dev/drbd0::/var/www::ext4

Modifier /etc/ha.d/authkeys
Décomm.

Auth 1 1 crc 2 sha1 HI! 3 md5 Hello!

Lancer chmod 600 /etc/ha.d/authkeys

Adapter /etc/hosts

:exclamation: Notez bien que c’était un tuto a but personnel que je met à disposition, utilisé pour mes études comme pense bête

Merci Flamme2.

J’ai une question : Est-on obligé de disposer de 2 cartes réseaux sur chaque noeud DRBD ?
En mode Dual-Primary avec un filesystem GFS, je vois pourquoi, car les deux noeuds doivent se mettre d’accord sur quel périphérique est en écriture à un moment donné.

Mais, en mode Primary / Secondary je ne pense pas que cela soit obligatoire… ?

Merci.

C’est conseillé, mais pas obligatoire, effectivement :slightly_smiling:

[quote=“isador999”]Merci beaucoup de ta réponse !

GlusterFS a l’air encore plus simple que Drbd , effectivement Drbd a quelques exigences sur le noyau et mon NAS n’est pas hyper récent, et de plus n’a que 64 Mo de RAM -_-’

Après, tu as un peu raison, as-t-on besoin d’un système comme ça pour les données de 4-5 personnes, je ne suis pas sur ^^.

C’est que je dispose aussi d’un serveur KVM, de machines virtuelles avec disques LVM, et comme je ne sais pas comment les sauvegarder facilement, j’avais dans l’idée d’utiliser un partage NFS sur le RAID1 où je crée mes volumes LVM (même pas sur que ca soit possible, ça lol). Du coup, avec un DRBD paramétré sur le RAID1, mes VMs n’auraient jamais eues de problèmes de disques… Mais peut-être cela va-t-il plus compliquer qu’autre chose, je ne sais pas trop…

Merci encore, en tout cas.[/quote]

GlusterFS consomme pas mal de mémoire, DRDB à l’air (à mon travail tout du moins … faut voir les charges aussi :083) plus stable.

En gros tu cherche à te faire de la haute disponibilité sur tes VM :whistle:

Vue la mémoire disponible je pense que tu peu oublier à moins de gonfler un poil plus la RAM.

C’est quoi les serveurs virtuels que tu compte faire tourner ?

Sinon un système heartbeat avec une VIP monitorer et un mysql replicator avec du script rsync en tâche cron fera ça tout aussi bien (et la charge pourra être contenu à des heures spécifiques) :wink:

J’ai testé GlusterFS, ça marche très bien, mais en effet DRBD a l’air plus réputé en termes de performances.

Mes VM, j’ai 3-4 noeuds Openstack, 1 PfSense, 2 Debian pour qques petits sites Web et tests. (J’envisage de mettre un second PfSense pour tester CARP).
Et l’Openstack contient 2-3 VMs max (VMs Nested).

Oui, je reconnais que le besoin n’est pas très gros, mais c’est plus pour m’y intéresser et tester tout cela concrètement.

“vu la mémoire disponible tu peux oublier”
Si tu parles des 64Mo de mon NAS, oui ça va être plus que limite, je devrais vraiment le changer.

Je suis tout à fait d’accord avec un système Heartbeat + VIP, mais physiquement seul mon serveur KVM dispose de deux cartes réseaux… Ou alors je ne vois pas comment tu veux faire.
Je ne vois pas trop pourquoi une répli MySQL non plus…
Rsync est une solution décente oui :slightly_smiling:

J’avoue avoir pris la discussion en cours sans trop regarder l’existant.

Si tu utilise de l’openstack il serait sans doute plus intéressant de monter le DRDB sur les noeuds eux même ou effectivement du Glusterfs mais ça complique grandement le montage mais pour aller au plus simple Swift ferait tout aussi bien l’affaire pour gérer tes noeuds répliquer.
http://docs.openstack.org/developer/swift/

Merci pour le lien :wink: On m’en a parlé au boulot, mais pas pris le temps de trop chercher ca.
Cependant, je doute de l’intérêt pour le moment car je n’ai qu’un seul serveur KVM physique…
A moins qu’on puisse installer Swift sur des machines Debian non-KVM et non-Openstack ??

Première solution assez simple : Il faudrait que je mette DRBD sur mon Physical Volume LVM contenant toutes mes VMs (est-ce vraiment possible DRBD sur un PV ?), et que je mette le disque du serveur Cubieboard en mode DRBD slave. Là-dessus, un simple Rsync depuis Cubieboard sur le NAS suffira bien pour le moment.

Si je veux plus de flexibilité, il faudra juste que je crée plein de partitions / slaves sur le disque Cubieboard, et que je mette DRBD dans chaque VM où Openstack est installé.

Autre solution : Si je peux installer Swift sur une Cubieboard (ce dont je doute fort.), je fais des Object Storage Swift répliqués des deux côtés.

Et dès que j’ai un nouveau NAS plus performant et déjà basé sur une vraie Debian, un petit GlusterFS entre les deux ARM !