Différences

Ci-dessous, les différences entre deux révisions de la page.

--- cluster:samba [2020/01/05 16:57]
etienne créée
+++ cluster:samba [2020/01/05 20:18] (Version actuelle)
etienne
@@ Ligne 13: / Ligne 13: @@
 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'' :
+<file>
+.0.0.10     s0
+.0.0.11     s1
+</file>
+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
+<code bash>
+# ssh-keygen
+# scp /root/.ssh/id_rsa.pub s1:/root/.ssh/authorized_keys
+</code>
+Sur S1
+<code bash>
+# ssh-keygen
+# scp /root/.ssh/id_rsa.pub s0:/root/.ssh/authorized_keys
+</code>
+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 =====
@@ Ligne 42: / Ligne 69: @@
 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 :
+<code bash>
+# drbdadm create-md sstorage
+# drbdadm up sstorage
+</code>
+À 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 :
+<code bash>
+# cat /proc/drbd
+version: 8.4.10 (api:1/proto:86-101)
+srcversion: 15055BDD6F0D23278182874
+: 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
+</code>
+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)
+<code bash>
+# drbdadm invalidate-remote sstorage
+# drbdadm primary sstorage
+# cat /proc/drbd
+version: 8.4.10 (api:1/proto:86-101)
+srcversion: 15055BDD6F0D23278182874
+: 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
+</code>
+On peut donc faire passer l'autre en primaire aussi (sur S1 donc) :
+<code bash>
+# drbdadm primary sstorage
+</code>
+Finalement il faut s'assurer que DRBD soit charger au démarrage, sur les deux serveurs :
+<code bash>
+# systemctl enable drbd
+</code>
 ===== OCFS2 =====
@@ Ligne 47: / Ligne 116: @@
 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''.
+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) :
+<code bash>
+Requires=network-online.target drbd.service
+After=network-online.target drbd.service
+</code>
+Suivi de ''systemctl daemon-reload''
+La configuration du cluster est relativement simple, dans le fichier ''/etc/ocfs2/cluster.conf'', indiquez simplement vos deux machines :
+<code bash>
+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
+</code>
+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:
+<code bash>
+# systemctl restart o2cb
+# systemctl restart ocfs2
+</code>
+À 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) :
+<code bash>
+# mkfs.ocfs2 --cluster-stack=o2cb --fs-feature-level=max-features  -L sdata --cluster-name=scluster /dev/drbd0
+</code>
+Finalement, si tout ce passe bien, vous pouvez monter votre système de fichier sur chaque serveur :
+<code bash>
+# mount -t ocfs2 /dev/drbd0 /srv/scluster
+</code>
+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 :
+<code bash>
+/dev/drbd0	/srv/scluster	ocfs2	defaults,_netdev,x-systemd.requires=ocfs2.service	0	0
+</code>
+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 :
+<code bash>
+.20.1.20/16 eth1
+.20.1.21/16 eth1
+<code>
+Ensuite il faut indiquer tous les nœuds de notre cluster dans le fichier ''/etc/ctdb/nodes'' :
+<code bash>
+.0.0.10
+.0.0.11
+</code>
+Il est nécessaire de créer quelques répertoires aussi (du moins sur Debian) :
+<code bash>
+# mkdir -p /var/lib/ctdb/volatile
+# mkdir -p /var/lib/ctdb/persistent
+# mkdir -p /var/lib/ctdb/state
+# mkdir /var/run/ctdb
+</code>
+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 :
+<code bash>
+node address = 10.0.0.10
+</code>
+Sur S1:
+<code bash>
+node address = 10.0.0.11
+</code>
+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 :
+<code bash>
+ExecStartPre=-/bin/mkdir /var/run/ctdb
+PIDFile=/var/run/ctdb/ctdbd.pid
+</code>
+Il faut indiquer, aussi, de démarrer ctdb après ocfs2. Dans le même fichier :
+<code bash>
+After=network-online.target time-sync.target ocfs2.service
+</code>
+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 :
+<code bash>
+# 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
+</code>

Artisan du Numérique

Outils pour utilisateurs

Outils du site

Différences

Outils de la page