Parlons de la réplication du système de fichiers réseau.
La réplication de système de fichiers réseau est souvent utilisée aujourd'hui dans de nombreux scénarios :
- Réplication d'un système de fichiers pour des raisons de sécurité :si un nœud tombe en panne, l'autre nœud est accessible.
- Pour répliquer un système de fichiers vers le siège d'une autre entreprise, afin que chaque employé ait accès à ses données localement et non via un réseau public. Mais s'il se rend à l'autre siège social, il a toutes ses données, et là encore il peut y accéder localement.
Comme vous pouvez l'imaginer, ce type de système est souvent utilisé pour créer des systèmes de fichiers pour un environnement de cluster.
Nous avons choisi d'implémenter la solution avec DRDB. Son principal objectif est (comme d'autres systèmes comme celui-ci) la haute disponibilité et la reprise après sinistre pour les systèmes de fichiers.
Nous implémentons la solution avec Debian 8, mais cela devrait également fonctionner sur Ubuntu.
Prérequis
Avant de commencer, voici les prérequis :
- Au moins 2 serveurs Debian.
- Debian est installé en tant qu'installation minimale (pas du tout nécessaire si vous savez ce que vous faites sur les systèmes de production) guide recommandé https://www.howtoforge.com/tutorial/debian-8-jessie-minimal-server/
- Au moins 2 disques Linux sur chaque serveur :/dev/sda pour l'installation Linux, /dev/sdb pour l'installation DRDB.
ATTENTION !!! :lors de l'installation, toutes les données sur le disque /dev/sdb seront détruites, ne travaillez donc pas sur un disque contenant des données.
Installation DRBD
Dans notre exemple, je vais utiliser deux nœuds, qui sont :
- 192.168.152.100 mysql1.local.vm
- 192.168.152.110 mysql2.local.vm
Sur tous les nœuds, modifiez le fichier /etc/hosts comme suit :
127.0.0.1 localhost
192.168.152.100 mysql1.local.vm mysql1
192.168.152.110 mysql2.local.vm mysql2
# Les lignes suivantes sont souhaitables pour la capacité IPv6 hôtes
::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
Exécutez ensuite les commandes suivantes pour installer DRDB :
apt-get update
apt-get -y upgrade
apt-get install drbd-utils
Configuration Primaire/Secondaire - Reprise après sinistre
Le fichier de configuration principal est /etc/drbd.conf qui ressemble à ceci :
inclure "drbd.d/global_common.conf" ;
inclure "drbd.d/*.res" ;
Par convention, /etc/drbd.d/global_common.conf contient les sections globales et communes de la configuration DRBD, tandis que le .res les fichiers contiennent une ressource dans chaque section.
Dans notre exemple, nous effectuons une configuration minimale qui réplique les données sur les deux nœuds. Sur chaque nœud faites la modification suivante :
Nous allons commencer à éditer le fichier /etc/drbd.d/global_common.conf modify the default line from
global {
usage-count yes ;
# minor-count dialog-refresh disable-ip-verification
}
...
net {
protocole C ;
# délai d'expiration du protocole max-epoch-size max-buffers unplug-watermark
# connect-int ping-int sndbuf-size rcvbuf-size ko-count
# allow- two-primaries cram-hmac-alg shared-secret after-sb-0pri
# after-sb-1pri after-sb-2pri always-asbp rr-conflict
# ping-timeout data-integrity-alg tcp-cork on-congestion
# congestion-fill congestion-extents csums-alg verify-alg
# use-rle
}
Nous allons maintenant créer le fichier de configuration /etc/drbd.d/r0.res pour notre ressource. Créez le fichier sur tous les nœuds et ajoutez ceci à l'intérieur :
ressource r0 { sur mysql1.local.vm { périphérique /dev/drbd1 ; disque /dev/sdb ; adresse 192.168.152.100:7789 ; méta-disque interne ; } sur mysql2.local.vm { périphérique /dev/drbd1 ; disque /dev/sdb ; adresse 192.168.152.110:7789 ; méta-disque interne ; }}
Ce que nous avons fait jusqu'à présent est le suivant :
- Vous "acceptez" d'être inclus dans les statistiques d'utilisation de DRBD avec le paramètre de nombre d'utilisations.
- Les ressources sont configurées pour utiliser une réplication entièrement synchrone avec Protocol Cunless sauf indication contraire explicite.
- Notre cluster se compose de deux nœuds : mysql1 et mysql2.
- Nous avons une ressource nommée arbitrairement
r0qui utilise/dev/sdben tant qu'appareil de niveau inférieur et est configuré avec des métadonnées internes. - La ressource utilise le port TCP 7789 pour ses connexions réseau et se lie aux adresses IP 192.168.152.100 et 192.168.152.110 respectivement.
Sur tous les nœuds, initialisez les métadonnées avec la commande suivante :
drbdadm create-md r0
Vous devriez voir quelque chose comme ceci :
--==Merci d'avoir participé à l'enquête mondiale sur l'utilisation ==--
La réponse du serveur est :
vous êtes le 2963e utilisateur à installer cette version
initialisation du journal d'activité
PAS d'initialisation du bitmap
Écriture des métadonnées...
Nouveau bloc de métadonnées drbd créé avec succès.
succès
Ensuite, nous activons la ressource et initialisons la première exécution de réplication, uniquement sur le premier nœud, elle devrait commencer à se répliquer :
drbdadm jusqu'à r0
drbdadm primary --force r0
Pour vérifier si tout fonctionne bien, vous pouvez vérifier le fichier /proc/drbd sur les deux nœuds et vous verrez quelque chose comme ceci :
Mysql1
[email protected] :# cat /proc/drbd
version : 8.4.3 (api:1/proto:86-101)
srcversion :1A9F77B1CA5FF92235C2213
1 :cs:SyncSource ro:Primary/Secondary ds:UpToDate/Incohérent C r-----
ns:54624 nr:0 dw:0 dr:55536 al:0 bm:3 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:5188060
[>..................] synchronisé :1,1 % (5064/5116)Mfinition :Vitesse 0:17:21 :4 964 (4 964) K/s
Mysql2
[email protected] :# cat /proc/drbd
version : 8.4.3 (api:1/proto:86-101)
srcversion :1A9F77B1CA5FF92235C2213
1 :cs:SyncTarget ro:Secondary/Primary ds:Inconsistent/UpToDate C r-----
ns:0 nr:17496 dw:17496 dr:0 al:0 bm:1 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:5225188
[>..................] synchronisé :0,4 % (5100/5116)Mfinition :0:29:41 vitesse :2 916 (2 916) souhaitée :5 160 K/s
Pendant la phase de construction, vous pouvez remarquer UpToDate/Incohérent , c'est correct car il s'agit de la première synchronisation des données.
Une fois le système de fichiers synchronisé, ce shloud passe à UpToDate/UpToDate comme dans le journal suivant :
[email protected] :/home/sysop# cat /proc/drbd
version : 8.4.3 (api:1/proto:86-101)
srcversion :1A9F77B1CA5FF92235C2213
1 :cs:Connecté ro:Primaire/Secondaire ds:UpToDate/UpToDate C r-----
ns:5242684 nr:0 dw:0 dr:5243596 al:0 bm:320 lo:0 pe:0 ua :0 ap:0 ep:1 wo:f oos:0
Nous avons maintenant un nouveau périphérique de bloc, appelé /dev/drbd1 que nous pouvons formater avec notre type de système de fichiers préféré. Par exemple, si nous voulons le formater en ext4 et le monter sur /var/www, nous pouvons simplement faire :
[email protected] :/home/sysop# mkfs.ext4 /dev/drbd1
mke2fs 1.42.12 (29-Aug-2014)
Création du système de fichiers avec 1310671 4k blocchi et 327680 inode
Etiquette du file system=ab3e18c9-e8cb-42c8-977a-ab79bdb18aea
Sauvegarde du superbloc sauvegardé nei blocchi :
32768, 98304, 163840, 229376, 294912, 819200, 884736
Affectation des tables de groupe :fatto
Écriture du tableau de bord de l'inode :fatto
Création d'un journal (32 768 blocs) :fatto
Écriture des informations sur les super-blocs et le système de fichiers comptable :fattoEnsuite, nous pouvons monter notre système de fichiers :
mkdir /var/www
mount /dev/drbd1 /var/wwwLe répertoire /var/www est maintenant monté via le système drbd.
Dans ce scénario, avec une configuration primaire/secondaire, nous avons mis en place un système de reprise après sinistre.
Dans ce cas, si vous essayez de monter le système de fichiers sur le deuxième nœud, vous obtiendrez une erreur :
[email protected] :~# mount /dev/drbd1 /var/www/
mount :/dev/drbd1 est protégé en écriture, montage en lecture seule
mount :mount /dev/drbd1 sur /var/www a échoué :Type de support erratoCeci est normal et attendu en raison de notre configuration.
Nous pouvons maintenant simuler un échec sur mysql1, donc éteignez-le avec la commande poweroff.
Sur mysql2, nous pouvons voir ce qui se passe :
5 octobre 13:52:14 noyau mysql2 :[13458.629215] drbd r0 :PingAck n'est pas arrivé à temps.
5 octobre 13:52:14 noyau mysql2 :[13458.629587] drbd r0 :peer( Primary> Inconnu ) conn( Connected -> NetworkFailure ) pdsk( UpToDate -> DUnknown )
5 octobre 13:52:14 noyau mysql2 :[13458.629919] drbd r0 :asender terminé
5 octobre 13:52:14 Noyau mysql2 :[13458.629921] drbd r0 :Arrêt de drbd_a_r0
5 oct. 13:52:14 Noyau mysql2 :[13458.630028] drbd r0 :Connexion fermée
5 oct. 13:52:14 Noyau mysql2 :[13458.630035] drbd r0 :conn( NetworkFailure -> Unconnected )
5 oct. 13:52:14 noyau mysql2 :[13458.630035] drbd r0 :récepteur terminé
5 oct. 13:52:14 noyau mysql2 :[13458.630036] drbd r0 :Redémarrage du thread du récepteur
5 oct. 13:52:14 noyau mysql2 :[13458.630037] drbd r0 :récepteur (re)démarré
5 oct. 13:52:14 noyau mysql2 :[13458.630041] drbd r0 :conn( Non connecté -> WFConnection )Le noeud mysql2 détecte que mysql1 est mort, et si on vérifie le /proc/drbd :
[email protected] :~# cat /proc/drbd
version : 8.4.3 (api:1/proto:86-101)
srcversion :1A9F77B1CA5FF92235C2213
1 :cs :WFConnection ro:Secondary/Inconnu ds:UpToDate/DUnknown C r-----
ns:0 nr:5457236 dw:5457236 dr:0 al:0 bm:320 lo:0 pe:0 ua:0 ap :0 ep:1 wo:f oos:0nous pouvons voir le statut changé de Secondaire/primaire à Secondaire/inconnu. Alors maintenant, nous faisons le tour, en promouvant mysql2 comme primaire. Sur mysql2 lancez simplement :
drbdadm primaire r0vérifions à nouveau /proc/drbd et voyons la magie...
[email protected] :~# cat /proc/drbd
version : 8.4.3 (api:1/proto:86-101)
srcversion :1A9F77B1CA5FF92235C2213
1 :cs :WFConnection ro:Primaire/Inconnu ds:UpToDate/DUnknown C r-----
ns:0 nr:5457236 dw:5457236 dr:912 al:0 bm:320 lo:0 pe:0 ua:0 ap :0 ep:1 wo:f oos:0Comme vous pouvez le voir, notre nœud est maintenant principal et peut être monté régulièrement.
[email protected] :~# mount /dev/drbd1 /var/www/
[email protected] :~# df -h
Système de fichiers Dim. Usati Dispon. Uso% Montato su
/dev/sda1 9,3G 1,4G 7,5G 16% /
udev 10M 0 10M 0% /dev
tmpfs 97M 4,6M 92M 5% /run
tmpfs 241M 0 241M 0% /dev/shm
tmpfs 5,0M 4,0K 5,0M 1% /run/lock
tmpfs 241M 0 241M 0% /sys/fs/cgroup
/dev/drbd1 4,8G 10M 4,6G 1% /var/wwwMaintenant, nous supposons que nous voulons reprendre mysql1, si nous commençons maintenant, nous en viendrons à diviser le cerveau, en fait, vous pouvez vérifier le journal et voir ces erreurs :
5 octobre 14:26:04 noyau mysql1 :[ 7.760588] drbd r0 :conn( StandAlone -> Unconnected )
5 octobre 14:26:04 noyau mysql1 :[ 7.760599] drbd r0 :démarrage du thread récepteur ( de drbd_w_r0 [458])
5 oct. 14:26:04 mysql1 drbdadm[435] :ajustement net :r0
5 oct. 14:26:04 mysql1 drbdadm[435] :]
oct. 5 14:26:04 noyau mysql1 :[ 7.769318] drbd r0 :récepteur (re)démarré
5 octobre 14:26:04 noyau mysql1 :[ 7.769327] drbd r0 :conn( Unconnected -> WFConnection )
5 octobre 14:26:04 mysql1 /etc/init.d/mysql[485] :PID MySQL introuvable, pid_file détecté/deviné :/var/run/mysqld/mysqld.pid
5 octobre 14:26 :04 mysql1 acpid :démarrage avec netlink et la couche d'entrée
5 oct 14:26:04 mysql1 acpid :1 règle chargée
5 oct 14:26:04 mysql1 acpid :attente d'événements :journalisation des événements est désactivé
5 oct. 14:26:05 noyau mysql1 :[ 8.270578] drbd r0 :prise de contact réussie :version 101 du protocole réseau convenu
5 oct. 14:26:05 noyau mysql1 :[ 8.270581] drbd r0 :Accepté de prendre en charge TRIM au niveau du protocole
5 octobre 14:26:05 noyau mysql1 :[ 8.270770] drbd r0 :conn( WFConnection -> WFReportParams )
5 octobre 14:26:05 noyau mysql1 :[ 8.270771] drbd r0 :démarrage d'un thread émetteur (de drbd_r_r0 [461])
5 oct. 14:26:05 noyau mysql1 :[ 8.272594] block drbd1 :drbd_sync_handshake :
5 oct. 14:26:05 noyau mysql1 :[ 8.272597] block drbd1 : self 242B364F4A5B9C68:525CC995A3CFBA2B:44A1DE193A6C6701:0000000000000004 bits de drapeaux:64463:0
5 octobre 14:26:05 mysql1 noyau:[8,272598] bloc drbd1:pairs 6903F6042F95F5FF:525CC995A3CFBA2A:44A1DE193A6C6700:0000000000000004 bits de drapeaux:4:0
5 octobre 14:26:05 noyau mysql1 :[ 8.272599] bloquer drbd1 :uuid_compare()=100 par la règle 90
5 octobre 14:26:05 noyau mysql1 :[ 8.272601] bloquer drbd1 :commande d'assistance :/sbin /drbdadm initial-split-brain minor-1
5 octobre 14:26:05 noyau mysql1 :[ 8.272692] drbd r0 :méta-connexion arrêtée par un pair.
5 octobre 14:26:05 noyau mysql1 :[ 8.272720] drbd r0 :conn( WFReportParams -> NetworkFailure )
Oct 5 14:26:05 mysq noyau l1 :[ 8.272722] drbd r0 :asender terminé
5 oct. 14:26:05 noyau mysql1 :[ 8.272722] drbd r0 :fin de drbd_a_r0
5 oct. 14:26:05 noyau mysql1 :[ 8.279158] bloc drbd1 :commande d'assistance :/sbin/drbdadm initial-split-brain minor-1 code de sortie 0 (0x0)
5 oct. 14:26:05 noyau mysql1 :[ 8.279173] bloc drbd1 :Split-Brain détecté mais non résolu , connexion interrompue !
5 oct. 14:26:05 noyau mysql1 :[ 8.279197] block drbd1 :commande d'assistance :/sbin/drbdadm split-brain minor-1
5 oct. 14:26:05 noyau mysql1 :[ 8.286125] block drbd1 :commande d'assistance :/sbin/drbdadm split-brain minor-1 code de sortie 0 (0x0)
5 oct. 14:26:05 noyau mysql1 :[ 8.286144] drbd r0 :conn( NetworkFailure -> Déconnexion )
5 oct 14:26:05 noyau mysql1 :[ 8.286146] drbd r0 :erreur lors de la réception de ReportState, e :-5 l :0 !
5 oct 14:26:05 noyau mysql1 :[ 8.287009] drbd r0 :connexion fermée
5 oct. 14:26:05 noyau mysql1 :[ 8.287017] drbd r0 :conn( Disconnecting -> StandAlone )
5 oct. 14:26:05 Noyau mysql1 :[ 8.287018] drbd r0 :récepteur terminé
5 octobre 14:26:05 Noyau mysql1 :[ 8.287019] drbd r0 :Terminaison drbd_r_r0En effet, nous avons maintenant deux nœuds principaux, ce qui n'est pas possible dans une configuration primaire/secondaire. Donc, en supposant un nouvel identifiant de données sur mysql2, nous devons rétrograder mysql1 en secondaire.
Donc, sur mysql1, lancez :
[email protected] :~# drbdadm secondaire r0
[email protected] :~# drbdadm connect --discard-my-data r0Sur mysql2 à la place, qui est le survivant du cerveau divisé , nous devons exécuter :
[email protected] :~# drbdadm connect r0maintenant vous pouvez vérifier et voir que tout se reconstruit correctement, mais maintenant mysql1 est secondaire et mysql2 est primaire.
[email protected] :~# cat /proc/drbd
version : 8.4.3 (api:1/proto:86-101)
srcversion :1A9F77B1CA5FF92235C2213
1 :cs :SyncTarget ro:Secondary/Primary ds:Inconsistent/UpToDate C r-----
ns:0 nr:28224 dw:28224 dr:0 al:0 bm:1 lo:0 pe:0 ua:0 ap :0 ep:1 wo:f oos:229628
[=>..................] synchronisé :11,2 % (229628/257852)K
fin :0:01:04 vitesse :3 528 (3 528) vouloir :6 600 K/sec