Artisan du Numérique

Cette page est en lecture seule. Vous pouvez afficher le texte source, mais ne pourrez pas le modifier. Contactez votre administrateur si vous pensez qu'il s'agit d'une erreur.
====== 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'' :

<file>
10.0.0.10     s0
10.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 =====

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''.

<code>
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;
  }
}
</code>

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 
 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
</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 
 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
</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 =====

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) :

<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>
172.20.1.20/16 eth1
172.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>
10.0.0.10
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

Outils de la page
