====== Simple cluster samba ======
Deux serveurs en réplication (grâce à DRBD). Matériellement nous utilisons une machine avec deux cartes réseaux différentes. Les deux serveurs sont connectés l'un à l'autre par un câble réseau servant de lien de réplication (carte eth0 sur les serveurs) quant à l'autre lien réseau est utilisé pour l'accès au service (carte eth1 sur les serveurs). Nous nommons les serveurs **S0** et **S1**.
La partition répliquée par DRBD est /dev/sys/data.
Les deux serveurs sont équipés d'une IP fixe sur le réseau et d'une IP publique qui pourra passer d'un serveur à l'autre en fonction du fonctionnement des services.
Nous avons donc
- S0 avec l'adresse 10.0.0.10/24 sur le lien de réplication et 172.20.0.20/16 côté LAN.
- S1 avec l'adresse 10.0.0.11/24 sur le lien de réplication et 172.20.0.21/16 côté LAN.
Nous gardons 172.20.1.20/16 et 172.20.1.21/16 comme adresses de service annoncée au client. Celles-ci sont gérées, nous le verrons ensuite, par CTDB.
===== Préparation =====
Il est utile, une fois la configuration réseau créée, de créer des enregistrements pour les IP du lien de réplication dans le fichier ''/etc/hosts'' :
10.0.0.10 s0
10.0.0.11 s1
Il est utile de créer des clés SSH pour l'utilisateur ''root'' afin de copier les données entre les serveurs (les fichiers sont souvent identiques et ne sont donc que copier). Pour ce faire, sur chaque serveur :
Sur S0
# ssh-keygen
# scp /root/.ssh/id_rsa.pub s1:/root/.ssh/authorized_keys
Sur S1
# ssh-keygen
# scp /root/.ssh/id_rsa.pub s0:/root/.ssh/authorized_keys
Pour que cela fonctionne, il faut temporairement mettre le ''PermitRootLogin yes'' dans ''/etc/sshd_config'' et redémarrer le serveur ssh ''systemctl restart ssh''. Dès que les clés sont en place, la directive doit être supprimée. De manière générale, désactiver l'authentification par mot de passe est une bonne chose.
Finalement régler les droits du fichier ''authorized_keys'' à ''root:root'', ''0600'' est éventuellement nécessaire.
===== Ressources DRBD =====
Afin de configurer notre ressource DRBD, nous utilisons le fichier de configuration adéquat (vérifier selon la distribution, sur Debian nous pouvons créer un fichier ''/etc/drbd.d/sstorage.res''.
resource sstorage {
startup {
become-primary-on both; # les deux serveurs démarrent comme primaire
}
net {
allow-two-primaries; # deux serveurs primaires sont autorisés
}
on s0 {
device /dev/drbd0;
disk /dev/sys/data;
address 10.0.0.10:7789;
meta-disk internal;
}
on s1 {
device /dev/drbd0
disk /dev/sys/data;
address 10.0.0.11:7789;
meta-disk internal;
}
}
Il est important, là, de mettre en place des solutions d'isolation des serveurs en cas de perte de connexions, le sujet sera étendu plus tard.
Un fois la configuration effectuée, sur chaque serveur créer le disque :
# drbdadm create-md sstorage
# drbdadm up sstorage
À ce stade les disques ne contiennent rien et DRBD ne le sait pas encore, les deux serveurs sont donc en mode "secondaire" avec des données inconsistantes :
# cat /proc/drbd
version: 8.4.10 (api:1/proto:86-101)
srcversion: 15055BDD6F0D23278182874
0: cs:Connected ro:Secondary/Secondary ds:Inconsistent/Inconsistent C r-----
ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:4194140
Il devient donc nécessaire de faire passer un serveur en primaire et d'invalider les données de l'autres :
Sur un seul serveur (S0 par exemple)
# drbdadm invalidate-remote sstorage
# drbdadm primary sstorage
# cat /proc/drbd
version: 8.4.10 (api:1/proto:86-101)
srcversion: 15055BDD6F0D23278182874
0: cs:SyncSource ro:Primary/Secondary ds:UpToDate/Inconsistent C r-----
ns:510724 nr:0 dw:0 dr:510912 al:0 bm:0 lo:0 pe:1 ua:1 ap:0 ep:1 wo:f oos:3684188
[=>..................] sync'ed: 12.3% (3684188/4194140)K
finish: 0:03:00 speed: 20,336 (13,780) K/sec
On peut donc faire passer l'autre en primaire aussi (sur S1 donc) :
# drbdadm primary sstorage
Finalement il faut s'assurer que DRBD soit charger au démarrage, sur les deux serveurs :
# systemctl enable drbd
===== OCFS2 =====
Le système de fichier OCFS2 est un système de fichier fonctionnant en cluster. Simple et complet, il suffit à bien des situations. Il vient avec un gestionnaire de verrou fonctionnel nous évitant de devoir déployer des outils comme ''Pacemaker''.
Un fois installé, il faut le configurer, sur Debian cela se fait avec ''dpkg-reconfigure ocfs2-tools'' :
- Would you like to start an OCFS2 cluster (O2CB) at boot time? ''Yes''
- Name of the cluster to start at boot time: ''sstorage''
Et pour les autres questions, les valeurs par défaut sont corrects. Il est nécessaire, maintenant, d'indiquer au que le service ''o2cb'' dépendant maintenant de ''drbd'' en modifiant le fichier de démarrage de systemd (''/lib/systemd/system/o2cb.service'') en ajoutant à ''Requires'' et ''After'' la valeur : ''drbd.service'' (sur chaque serveur) :
Requires=network-online.target drbd.service
After=network-online.target drbd.service
Suivi de ''systemctl daemon-reload''
La configuration du cluster est relativement simple, dans le fichier ''/etc/ocfs2/cluster.conf'', indiquez simplement vos deux machines :
cluster:
heartbeat_mode = local
node_count = 2
name = scluster
node:
number = 0
cluster = scluster
ip_port = 7777
ip_address = 10.0.0.10
name = s0
node:
number = 1
cluster = scluster
ip_port = 7777
ip_address = 10.0.0.11
name = s1
heartbeat:
cluster = scluster
region = local
Le mode "heartbeat" mis à local indique que chaque point de montage à son propre système de gestion de la synchronisation. Si vous avez des dizaines de système ocfs2 sur un serveur alors vous devriez vous intéresser au système global. Dans ce cas, nous avons qu'un système ocfs2 donc local est largement suffisant.
Un fois le fichier sur les deux serveurs, il est temps de créer notre système de fichier. Lancer les services ''o2cb'' et ''ocfs2'' sur les deux serveurs:
# systemctl restart o2cb
# systemctl restart ocfs2
À ce stade vous pouvez vérifier le fonctionnement avec ''o2cluster -r'' sur chaque serveur. Cette commande indique le système de cluster en fonction sur votre serveur et vous devriez avoir quelque chose comme ''o2cb,scluster,local''.
Et création du système de fichier (sur un serveur) :
# mkfs.ocfs2 --cluster-stack=o2cb --fs-feature-level=max-features -L sdata --cluster-name=scluster /dev/drbd0
Finalement, si tout ce passe bien, vous pouvez monter votre système de fichier sur chaque serveur :
# mount -t ocfs2 /dev/drbd0 /srv/scluster
Dès lors vous pouvez vous amuser à créer un fichier sur un serveur et le supprimer sur l'autre.
L'inscription dans le fichier ''/etc/fstab'' peut être faite, en indiquant bien à ''systemd'' que ''ocfs2'' doit fonctionner pour le montage :
/dev/drbd0 /srv/scluster ocfs2 defaults,_netdev,x-systemd.requires=ocfs2.service 0 0
Dès lors, si vous redémarrez le système, il reviendra avec votre système de fichier ''ocfs2'' monté et fonctionnel.
===== CTDB =====
Après l'installation de CTDB (via le système de paquet de votre distribution), nous pouvons le configurer pour gérer nos adresses. Nous avions décidé 172.20.1.[20|21]/16 comme adresses de services. La première chose à faire est donc l'inscrire dans le fichier ''/etc/ctdb/public_addresses'' en indiquant sur quelle carte réseau les mettre sur les deux serveurs :
172.20.1.20/16 eth1
172.20.1.21/16 eth1
Ensuite il faut indiquer tous les nœuds de notre cluster dans le fichier ''/etc/ctdb/nodes'' :
10.0.0.10
10.0.0.11
Il est nécessaire de créer quelques répertoires aussi (du moins sur Debian) :
# mkdir -p /var/lib/ctdb/volatile
# mkdir -p /var/lib/ctdb/persistent
# mkdir -p /var/lib/ctdb/state
# mkdir /var/run/ctdb
Le problème de ''ctdb'' est son usage des verrous "bsd" via ''fcntl'' alors que le pile ocfs2/o2cb ne supporte que les verroux posix ''flock''. Se faisant nous ne pouvons pas utiliser le système de détection d'erreurs de ctdb ... cette partie est donc laissée à futures investigations. Actuellement nous ajoutons juste l'addresse de chaque serveur dans le fichier de ''/etc/ctdb/ctdb.conf''
Sur S0 :
node address = 10.0.0.10
Sur S1:
node address = 10.0.0.11
Il est aussi nécessaire, sur chaque serveur, de modifier le fichier de démarrage systemd. En effet, le chemin du fichier contenant le ''PID'' est erroné. Pour ce faire, assurez-vous que le fichier ''/lib/systemd/system/ctdb.service'' contienne :
ExecStartPre=-/bin/mkdir /var/run/ctdb
PIDFile=/var/run/ctdb/ctdbd.pid
Il faut indiquer, aussi, de démarrer ctdb après ocfs2. Dans le même fichier :
After=network-online.target time-sync.target ocfs2.service
Et recharger systemd avec ''systemctl daemon-reload''.
Dès lors, lorsqu'on redémarre le système, ctdb va s'occuper de répartir nos adresses sur nos serveurs. On peut vérifier le bon fonctionnement avec la command adéquate :
# ctdb status
Number of nodes:2
pnn:0 10.0.0.10 OK
pnn:1 10.0.0.11 OK (THIS NODE)
Generation:252638876
Size:2
hash:0 lmaster:0
hash:1 lmaster:1
Recovery mode:NORMAL (0)
Recovery master:1