DRBD est-il la seule solution de réplication de blocs viable pour Linux?

12

Je me suis retrouvé à avoir besoin d'un stockage redondant au niveau d'un bloc. La réplication au niveau des fichiers (Gluster, GFS, etc.) ne fonctionne pas pour mon cas d'utilisation.

Il semble que DRBD soit la solution idéale pour la réplication de blocs. Il ne semble pas y avoir trop d'autres options sensées. Ai-je échoué dans mes recherches ou DRBD est-il le seul jeu en ville?

linux replication block-device Charles
la source
Bonjour Charles, pourquoi ne pouvez-vous pas utiliser la réplication au niveau des fichiers? \
nsn
Le cas d'utilisation était la réplication de périphériques de disque VM sur plusieurs machines, où les périphériques étaient soutenus par des volumes LVM et servis via iSCSI - des périphériques de bloc, pas des fichiers. L'objectif final, comme indiqué dans les commentaires ci-dessous, était essentiellement un basculement iSCSI bricolage.
Charles

Réponses:

7

Oui, DRBD est le seul périphérique de bloc répliqué qui peut gérer les écritures simultanées. Si vous prévoyez de mettre un système de fichiers sur le dessus, il doit évidemment gérer plusieurs écrivains également, comme le font GFS (2) et OCFS (2).

Veuillez noter que si vous pouvez vous permettre des niveaux d'abstraction plus élevés pour la redondance, vous serez probablement beaucoup, beaucoup plus heureux avec la sémantique au niveau du fichier, donc vous devriez vraiment réfléchir à deux fois avant de passer à la sémantique au niveau du bloc. Si vous ne pouvez pas utiliser des niveaux d'abstraction plus élevés, mais que vous avez de l'argent à consacrer au problème, vous pouvez obtenir des performances nettement meilleures avec un bon SAN.

Mais vous le savez probablement déjà.

Pierre Carrier
la source
Dans ce cas, ce que j'essaie réellement de réaliser est une variété de basculement à chaud pour les cibles iSCSI pour créer un SAN simpliste. Il s'agit principalement d'un exercice d'apprentissage. Ma distribution de choix ne vient pas avec le support natif de DRBD en raison de décisions politiques stupides et de l'exécution d'un noyau un peu trop vieux.
Charles
DRBD vous permettra d'effectuer une mise en miroir active / veille et plus récemment active / active. Si vous choisissez actif / actif, vous devez vous assurer que le système de fichiers le prend en charge (d'où GFS, etc. ci-dessus). Vous voudrez probablement utiliser quelque chose comme Heartbeat pour déclencher un basculement (ou simplement compter sur un administrateur qui fait «drbdadm $ resource up | down» si nécessaire).
David Goodwin
4

Eh bien, il y a aussi MARS (Light) . Selon la documentation, cela est largement utilisé chez le fournisseur allemand 1 & 1

uli42
la source
N'est-ce pas asynchrone seulement? "Des modes de fonctionnement synchrones ou quasi synchrones sont prévus pour l'avenir, mais ne devraient fonctionner de manière fiable que sur de courtes distances (moins de 50 km), en raison des propriétés fondamentales des systèmes distribués." <- de MARS docs
BaronSamedi1958
2

Vous pouvez configurer un ensemble RAID à l'aide de périphériques iSCSI, mais je me méfierais de le faire avec des périphériques de stockage asymétriques (qui, dans le cas du stockage à distance comprend le réseau) - OTOH DRBD est explicitement conçu pour prendre en charge une telle utilisation.

Y a-t-il une raison pour laquelle vous n'aimez pas DRBD?

Ai-je échoué dans mes recherches

Si vous pensez que GFS est un système de fichiers de cluster de réplication, alors j'en ai bien peur.

symcbean
la source
Non ? Bon, oui, je suppose que sur son propre ce n'est pas.
Charles
1

J'ai entendu parler d'une variante du périphérique de blocage de réseau (NBD) qui prend en charge la réplication: ENBD . Cependant, je ne connais pas l'état d'avancement de ce projet. Cependant, le site Web ne semble pas encore être pris en charge.

Oliver
la source
Oui, aucune mise à jour depuis les noyaux 2.4? Pourtant, bonne trouvaille.
Charles
1
Une autre solution aurait été d'exporter un fichier qui est répliqué à l'aide d'un système de fichiers en cluster avec NBD, mais je ne pense pas que vous souhaitiez le faire. Non, DRBD est vraiment le chemin à parcourir! En l'utilisant depuis quelques années, je n'ai jamais perdu de données.
Oliver
0

Il existe une alternative: vous pouvez utiliser des périphériques SAN avec une réplication native où les contrôleurs des baies de disques effectuent eux-mêmes tout le travail de réplication. C'est assez cher, mais n'a pas besoin de configuration sur les hôtes.

Sven
la source
Il arrive que j'essaie essentiellement de construire un simple SAN.
Charles
@Charles: Je devinai quelque chose comme ça, mais il est une alternative :)
Sven
-1

La question est fausse:

DRBD est-il la seule solution de réplication de blocs viable pour Linux? Je me suis retrouvé à avoir besoin d'un stockage redondant au niveau d'un bloc.

Non, ça ne l'est pas. Vous avez par exemple Linux MD (RAID logiciel), LVM RAID. Ils fournissent une redondance pour les périphériques blocs.

Vous vouliez donc probablement demander:

DRBD est-il la seule solution de réplication de blocs NETWORK viable pour Linux?

Et là encore, vous avez d'autres options.

Si le client est un seul nœud, vous pouvez créer un RAID logiciel sur le client qui se réplique sur plusieurs stockages réseau.

Si vous avez plusieurs clients, vous pouvez utiliser des périphériques de bloc LVM en cluster.

La réplication au niveau des fichiers (Gluster, GFS, etc.) ne fonctionne pas pour mon cas d'utilisation.

GFS (GFS2 de Redhat) est un système de fichiers de cluster de périphériques partagés. Il ne fournit pas de redondance. D'autres systèmes de fichiers locaux comme BTRFS et ZFS peuvent le faire. Ainsi que d'autres systèmes de fichiers distribués.

Delian Krustev
la source