Différences
Ci-dessous, les différences entre deux révisions de la page.
Les deux révisions précédentes Révision précédente Prochaine révision | Révision précédente | ||
drbd [Le 06/08/2007, 15:01] 194.140.247.8 |
drbd [Le 11/09/2022, 11:46] (Version actuelle) moths-art Suppression des espaces en fin de ligne (détecté et corrigé via le bot wiki-corrector (https://forum.ubuntu-fr.org/viewtopic.php?id=2067892) |
||
---|---|---|---|
Ligne 1: | Ligne 1: | ||
- | {{tag>hoary breezy dapper edgy systeme securite serveur tutoriel haute-disponibilite}} | + | {{tag>trusty système sécurité serveur haute_disponibilité}} |
---- | ---- | ||
+ | ====== DRBD : Synchronisation de données via le réseau ====== | ||
+ | **DRBD** //(Distributed Replicated Block Device)// est un outil qui permet de synchroniser (par réplication) des périphériques de stockage (disque dur, partition, volume logique, etc.) entre deux nœuds via le réseau. Pour simplifier, il s'apparente à du RAID-1 sur IP. Quand une écriture a lieu sur le disque du serveur maître, l'écriture est simultanément réalisée sur le serveur esclave. La synchronisation est faite au niveau de la partition. Tout comme le RAID-1, DRBD assure une consistance des données au niveau du périphérique. C'est à charge du système de fichiers de s'assurer, conserver et retrouver l'intégrité des données au niveau des fichiers. De même, c'est à charge des applications de retrouver un état cohérent si un problème survient. Il est important de noter que DRBD n'assure aucune fonction relative à la sécurité. Il n'y a ainsi pas de mécanisme d'authentification, de contrôle d'accès, de confidentialité ou d'intégrité des données échangées sur le réseau. | ||
+ | <note tip> | ||
+ | La société [[http://www.linbit.com/en/|Linbit]] à l'origine de cette solution propose une interface java permettant de configurer ce service d'une manière graphique. Il est possible de la télécharger [[http://oss.linbit.com/drbd-mc/|ici]]. Si vous devez utiliser cette solution je vous conseille aussi de vous intéresser au logiciel [[:pacemaker]]. | ||
+ | </note> | ||
+ | <note tip>Drbd est intégré dans le noyau depuis la version 2.6.33 (février 2010)</note> | ||
- | ===== Introduction ===== | + | ===== Fonctionnalités ===== |
+ | * **Gestion de 2 noeuds maximum** (La gestion de n noeuds est prévu pour la version 9.x voir la [[http://www.drbd.org/home/roadmap/|roadmap]]). | ||
+ | * **Synchronisation en temps réel** : elle se fait à la volée, pendant que les données sont modifiées. | ||
+ | * **Utilisation transparente** : les applications, qui enregistrent leurs données sur le périphérique de stockage répliqué, le font sans même savoir qu'il s'agit d'une unité de stockage spéciale. | ||
- | A | + | ==== Plusieurs modes de synchronisation ==== |
- | Ensuite, il ne faut pas oublier de la démonter de la session en cours : | + | * Fonctionnement asynchrone (mode A), les opérations d'écriture en local sur le nœud principal sont considérées comme achevées dès que l'écriture sur le disque local a eu lieu, et le paquet de réplication a été placé dans le buffer TCP local. En cas de fail-over, une perte de données pourrait se produire. Les données sur le noeud de secours sont cohérentes après le basculement, cependant, les mises à jour plus récentes effectuées avant l'accident pourrait être perdues. |
+ | * Fonctionnement semi-synchrone (mode B) les opérations d'écriture en local sur le nœud principal sont considérées comme achevées dès que l'écriture sur le disque local a eu lieu, et le paquet de réplication a atteint les nœuds pairs. Normalement, aucune donnée n'est perdue en cas de fail-over. Toutefois, une panne de courant simultanée sur les deux nœuds peut provoquer la destruction irréversible des données stockées sur le primaire, les écrits les plus récents sur le primaire peuvent être perdus. | ||
+ | * En fonctionnement synchrone (mode C), les opérations d'écriture en local sur le nœud principal sont considérées comme achevées lorsque les écritures sur le disque local et le disque distant ont été confirmées. En conséquence, la perte d'un seul nœud garanti de ne pas conduire à une perte de données. La perte de données est, bien sûr, inévitable, même avec ce protocole de réplication si les deux nœuds (ou leurs sous-systèmes de stockage) sont irréversiblement détruits en même temps. | ||
- | <code> | + | <note tip>Le protocole C étant le mode conseillé par la documentation [[http://www.drbd.org/users-guide-emb/s-replication-protocols.html|officielle]]</note> |
- | sudo umount /dev/hda2 | + | |
- | </code> | + | |
- | Pour vérifier si la partition a bien été démontée, il suffit de taper la commande : | + | ===== Pré-requis ===== |
- | <code> | + | |
- | mount | + | |
- | </code> | + | |
- | La partition ''/dev/hda2'' ne doit plus s'y trouver. | + | Les noyaux « server » disposent du module DRBD au moins depuis [[:hardy|Ubuntu 8.04 LTS]]. Il est donc préférable d'utiliser cette version du noyau, disponible par défaut dans la version « server » de Ubuntu. |
- | Nous pouvons maintenant préparer le périphérique de mirroring via la commande suivante : | + | ===== Installation ===== |
+ | [[:tutoriel:comment_installer_un_paquet|Installez le paquet]] **[[apt://drbd8-utils|drbd8-utils]]**. | ||
- | <code> | + | [[https://www.system-linux.eu/index.php?post/2010/06/01/Installation-de-Drbd-pour-de-la-haute-disponibilit%C3%A9|Installation à la main et Administration]] |
- | sudo drbdsetup /dev/drbd0 disk /dev/hda2 internal -1 | + | |
- | </code> | + | |
- | Cette commande attache le périphérique de mirroring ''/dev/drbd0'' au disque physique ''/dev/hda2'' en gardant les informations concernant le mirroring en interne (''internal''). Le code ''-1'' est le code imposé quand on utilise ''internal''. | + | ===== Configuration et utilisation ===== |
- | Maintenant, nous devons indiquer à ''drbd'' l'hôte auquel il doit se connecter pour le mirroring. Pour ce faire, on entre la commande suivante : | + | Il est conseillé de lire et de suivre la documentation du site officiel : |
+ | * configuration : http://www.drbd.org/users-guide-emb/ch-configure.html | ||
+ | * utilisation : http://www.drbd.org/users-guide-emb/p-work.html | ||
+ | * documentation officielle de ubuntu : https://help.ubuntu.com/9.04/serverguide/C/drbd.html | ||
- | <code> | + | Un exemple de configuration est proposé dans ce [[:tutoriel:mirroring_sur_deux_serveurs#configuration_et_mise_en_place_de_drbd|tutoriel]].\\ |
- | sudo drbdsetup /dev/drbd0 net 192.168.252.201 192.168.252.200 B | + | Sinon, [[:tutoriel:comment_modifier_un_fichier|ouvrez le fichier]] **/etc/drbd.conf**, il est relativement bien auto-documenté. |
- | </code> | + | |
- | + | ||
- | Cette commande indique que l'on travaille sur le périphérique de mirroring ''/dev/drbd0'' et que l'on fait une connexion réseau entre ''192.168.252.201'' (l'esclave Twin 2) et ''192.168.252.200'' (le maître Twin 1). La lettre qui ponctue la commande de configuration indique le protocole. | + | |
- | + | ||
- | * **A** : signifie qu'une opération d'écriture est terminée lorsque les données sont inscrites sur le disque local et envoyées sur le réseau. | + | |
- | * **B** : signifie qu'une opération d'écriture est terminée lorsque les données sont inscrites sur le disque local et l'accusé de réception de l'hôte distant arrive. | + | |
- | * **C** : signifie qu'une opération d'écriture est terminée lorsque les données sont inscrites sur le disque local et la confirmation d'écriture sur le disque distant est réceptionnée. | + | |
- | + | ||
- | Théoriquement, les délais augmentent proportionellement au niveau de garantie du protocole utilisé. A titre d'exemple, j'ai fait des tests de transferts d'une masse importante de fichiers (+/- 800 Mo) à plusieurs reprises et avec des protocoles différents; voici les résultats obtenus sur les machines Twin 1 et Twin 2 (décrites dans le préambule de cet article) avec les pourcentages de délais supplémentaires : | + | |
- | + | ||
- | ^ Masse de données ^ Temps copie partition locale vers partition locale ^ Temps copie partition locale vers périphérique mirroré mode B ^ Temps copie partition locale vers périphérique mirroré mode C ^ Synchronisation via rsync ^ | + | |
- | | 795 Mo | 2m9,768s | 2m15,456s (**104.4%**) | 2m14,286s (**103.5%**) | 7m34,946s (**350.6%**) | | + | |
- | | 804 Mo | 2m13,832s | 2m18,433s (**103.4%**) | 2m18,654s (**103.6%**) | 7m36,047s (**340.8%**) | | + | |
- | + | ||
- | On remarque que quelque soit le protocole utilisé (B ou C), les délais supplémentaires introduits sont de maximum 5% par rapport à une copie d'une partition locale vers une autre partition locale non mirrorée. | + | |
- | + | ||
- | Pour information, la syntaxe de configuration du réseau pour ''drbd'' est la suivante : | + | |
- | + | ||
- | * ''sudo drbdsetup //peripherique_drbd// net //ip_local[:port_local]// //ip_distante[:port_distant]// protocole'' | + | |
- | + | ||
- | Par défaut, le port d'utilisation est le **7788**. | + | |
- | + | ||
- | === Etape 2 : Configuration du maître Twin 1 === | + | |
- | + | ||
- | Par précaution, nous allons démonter également la partition mirrorée avant de mettre les mains dans le cambouis. Sur Twin 1, la partition est également en ''/dev/hda2''. La procédure de démontage des partitions est identique au début de l'étape 1. | + | |
- | + | ||
- | Après cela, nous devons préparer le périphérique de mirroring en attachant ce périphérique à la partition physique ''/dev/hda2'' via la commande suivante : | + | |
+ | ==== État d'un volume drbd ==== | ||
<code> | <code> | ||
- | sudo drbdsetup /dev/drbd0 disk /dev/hda2 internal -1 | + | cat /proc/drbd |
+ | version: 8.0.11 (api:86/proto:86) | ||
+ | GIT-hash: b3fe2bdfd3b9f7c2f923186883eb9e2a0d3a5b1b build by phil@mescal, 2008-02-12 11:56:43 | ||
+ | 0: cs:Connected st:Primary/Secondary ds:UpToDate/UpToDate C r--- | ||
+ | ns:1274247468 nr:4652 dw:1033086960 dr:1709332874 al:325498845 bm:15409 lo:2 pe:2 ua:0 ap:2 | ||
+ | resync: used:0/31 hits:15058152 misses:14731 starving:0 dirty:0 changed:14731 | ||
+ | act_log: used:1/127 hits:969493732 misses:558931063 starving:402269 dirty:233241813 changed:325498845 | ||
</code> | </code> | ||
- | Ensuite, nous devons établir le lien réseau entre les deux serveurs : | + | ==== Activation primaire/secondaire ==== |
+ | <code>drbdadm primary notrevolume</code> | ||
+ | sinon | ||
+ | <code>drbdadm secondary notrevolume</code> | ||
- | <code> | + | ===== Désinstallation ===== |
- | sudo drbdsetup /dev/drbd0 net 192.168.252.200 192.168.252.201 B | + | |
- | </code> | + | |
- | Nous pouvons voir dans la log que la connexion est bien établie (ligne ''drbd : Connection established'') en faisant : | + | Pour supprimer cette application, il suffit de [[:tutoriel:comment_supprimer_un_paquet|supprimer son paquet]]. La configuration de l'application sera conservée ou supprimée selon la méthode de désinstallation que vous choisirez. |
- | <code> | + | |
- | tail /var/log/messages | grep drbd | + | |
- | </code> | + | |
- | + | ||
- | Il ne nous reste plus qu'à indiquer que Twin 1 est le maître : | + | |
- | + | ||
- | <code> | + | |
- | sudo drbdsetup /dev/drbd0 primary --do-what-I-say | + | |
- | </code> | + | |
- | + | ||
- | **Remarque importante : ** L'option ''--do-what-I-say'' force la commande. Cette sécurité est mise en place pour éviter que vous écrasiez les partitions des esclaves. Car une fois la commande entrée, le maître va mettre à jour les esclaves et les partitions locales des esclaves seront écrasées. **Cette option est à utiliser la première fois mais plus par la suite !!!** Pour les autres mises en place de cette manière, vous devrez utiliser une commande de ce type pour la déclaration du //primary// : ''sudo drbdsetup /dev/drbd0 primary''. | + | |
- | + | ||
- | Il ne nous reste plus qu'à créer un système de fichier sur ce nouveau périphérique mirroré : | + | |
- | + | ||
- | <code> | + | |
- | sudo mkfs.ext3 /dev/drbd0 | + | |
- | </code> | + | |
- | + | ||
- | Maintenant, les changements seront répercutés pendant un long (très long) moment. A titre d'information, la construction de la partition de 3Go sur les machines de tests a duré 3h30 (tablez donc sur 1Go / 1h). Cependant, cette durée de construction initiale est beaucoup plus rapide si on n'impose pas de limite de transfert. Par défaut, les transferts de ''drbd'' sont limités à 250K/s. Voyez la section //Configuration additionelle// pour savoir comment augmenter cette limite. | + | |
- | + | ||
- | Durant cette construction, vous pouvez voir que la construction se déroule en faisant ''cat /proc/drbd''. Sur Twin 1 (le maître), cela nous donne : | + | |
- | + | ||
- | <code> | + | |
- | version: 0.7.7 (api:77/proto:74) | + | |
- | SVN Revision: 1680 build by phil@wiesel, 2004-12-14 16:05:39 | + | |
- | 0: cs:SyncSource st:Primary/Secondary ld:Consistent | + | |
- | + | ||
- | ns:2081560 nr:0 dw:44172 dr:2037440 al:23 bm:296 lo:0 pe:0 ua:0 ap:0 | + | |
- | [==============>.....] sync'ed: 72.9% (764820/2802208)K | + | |
- | finish: 0:42:29 speed: 248 (236) K/sec | + | |
- | 1: cs:Unconfigured | + | |
- | </code> | + | |
- | + | ||
- | Sur Twin 2 (l'esclave) : | + | |
- | <code> | + | |
- | version: 0.7.7 (api:77/proto:74) | + | |
- | SVN Revision: 1680 build by phil@wiesel, 2004-12-14 16:05:39 | + | |
- | 0: cs:SyncSource st:Secondary/Primary ld:Inconsistent | + | |
- | ns:2081560 nr:0 dw:44172 dr:2037440 al:23 bm:296 lo:0 pe:0 ua:0 ap:0 | + | |
- | [==============>.....] sync'ed: 72.9% (764820/2802208)K | + | |
- | finish: 0:42:29 speed: 248 (236) K/sec | + | |
- | 1: cs:Unconfigured | + | |
- | </code> | + | |
- | + | ||
- | Remarquez que le maître est dans un état consistant et l'esclave en état inconsistant. C'est parfaitement normal. Une fois la construction terminée, les deux seront en état consistant et vous pourrez passer à l'étape suivante. | + | |
- | + | ||
- | === Etape 3 : Utilisation du périphérique mirroré === | + | |
- | + | ||
- | Pour utiliser le périphérique mirroré, il nous suffit de le monter sur le point de montage où était la partition avant l'installation des périphériques ''drbd'' : | + | |
- | + | ||
- | <code> | + | |
- | sudo mount /dev/drbd0 /srv/prod | + | |
- | </code> | + | |
- | + | ||
- | Maintenant, dès que l'on fait quelque chose dans le répertoire ''/srv/prod'', c'est répercuté en temps réel sur Twin 2 (l'esclave). | + | |
- | + | ||
- | === Procédure manuelle de basculement sur Twin 2 (l'esclave) === | + | |
- | + | ||
- | Comme je vous l'ai signalé en début d'article, on ne peut pas monter le périphérique directement sur l'esclave (Twin 2). Cependant, que faire en cas de panne de Twin 1 (vu que c'est ça le but de l'article). | + | |
- | + | ||
- | Nous devons tout d'abord couper la connexion du côté de Twin 1 afin d'éviter les conflits avec Twin 2. Si la machine Twin 1 est éteinte ou déconnectée physiquement du réseau, ces commandes ne sont pas nécessaires. Néanmoins, en cas de redémarrage de Twin 1, __il ne faut pas qu'il reprenne le contrôle !__ Si c'était le cas, le système de fichiers pourraient devenir inconsistant. Afin d'éviter ce désagrément, déconnectez physiquement Twin 1 du réseau et désactivez le lien ''drbd'' avant de la reconnecter. | + | |
- | + | ||
- | Pour couper la connexion miroir de Twin 1, nous entrons les commandes suivantes (sur **Twin 1** bien entendu) : | + | |
- | + | ||
- | <code> | + | |
- | sudo umount /srv/prod | + | |
- | sudo drbdsetup /dev/drbd0 secondary | + | |
- | </code> | + | |
- | + | ||
- | Nous pouvons alors déconnecter également la liaison miroir de Twin 2 et monter le système de fichier afin de pouvoir travailler sur ce dernier. Nous effectuons cela en introduisant les commandes suivantes (sur **Twin 2**) : | + | |
- | + | ||
- | <code> | + | |
- | sudo drbdsetup /dev/drbd0 primary | + | |
- | sudo mount /dev/drbd0 /srv/prod | + | |
- | </code> | + | |
- | + | ||
- | Nous avons donc basculé le système de fichiers sur Twin 2 et maintenant dès qu'un changement est appliqué sur Twin 2, il est répercuté sur Twin 1 (pour peu que celui-ci soit connecté). Si Twin 1 était déconnecté et qu'il y a eu des changements sur Twin 2, les changements seront répercutés par une reconstruction une fois que Twin 1 se reconnectera (en tant qu'esclave). | + | |
- | + | ||
- | Nous pouvons faire quelques essais avant d'appliquer la procédure de retour à la normale. Par exemple, copions quelques fichiers tests et supprimons un répertoire ou l'autre. | + | |
- | + | ||
- | === Procédure manuelle de retour à la normale (retour sur Twin 1, le maître) === | + | |
- | + | ||
- | Une fois le maître reconnecté (en tant qu'esclave dans un premier temps), Twin 2 va reconstruire le système de fichier de Twin 1. C'est ce qu'on appelle la synchronisation après panne. Cette synchronisation peut durer plus ou moins longtemps suivant la quantité de données modifiées durant la panne. | + | |
- | + | ||
- | Pour savoir où en est la synchronisation après panne, vous pouvez examiner ''/proc/drbd''. | + | |
- | + | ||
- | Une fois la synchronisation terminée, on peut retourner à la normale en basculant le système de fichier sur Twin 1. | + | |
- | + | ||
- | Nous commençons par remettre Twin 2 en tant qu'esclave en entrant les commandes suivantes (sur **Twin 2**) : | + | |
- | + | ||
- | <code> | + | |
- | sudo umount /srv/prod | + | |
- | sudo drbdsetup /dev/drbd0 secondary | + | |
- | </code> | + | |
- | + | ||
- | Et on rebascule avec Twin 1 comme maître en entrant les commandes suivantes (sur **Twin 1**) : | + | |
- | + | ||
- | <code> | + | |
- | sudo drbdsetup /dev/drbd0 primary | + | |
- | sudo mount /dev/drbd0 /srv/prod | + | |
- | </code> | + | |
- | + | ||
- | Tout est redevenu comme avant et on a perdu aucune données malgré la panne (simulée) de Twin 1. | + | |
+ | ===== Voir aussi ===== | ||
+ | * **(en)** [[http://www.drbd.org/|Site officiel de DRBD]] | ||
+ | * **(en)** [[http://www.drbd.org/docs/about/|Site officiel de DRBD, documentation]] | ||
+ | * **(fr)** [[:tutoriel:mirroring_sur_deux_serveurs|Tutoriel d'utilisation conjointe avec Heartbeat et Samba]] | ||
+ | ---- | ||
+ | //Contributeur principal : [[:utilisateurs:mrwaloo|MrWaloo]] / Contributeur : [[:utilisateurs:herrleiche|Herrleiche]].// |