Mise en place d'un cluster OpenFiler

: aux dernières nouvelles, ça ne fonctionne malheureusement pas. Il faudra probablement attendre OpenFiler 3.0

Le but de ce how-to est la mise en place d'un cluster haute disponibilité composé de deux machines sous OpenFiler, qui pourra être utilisé pour du NAS (nfs, smb, ftp, http), ou du NAS (iSCSI).

Ce how-to est largement basé sur celui-là: http://www.howtoforge.com/installing-and-configuring-openfiler-with-drbd-and-heartbeat

Deux machines (de préférences identiques, mais pas obligatoire), supportées par OpenFiler 2.3 Chaque machine doit disposer deux deux interfaces réseau au minimum (une carte pour l'accès au réseau classique, une carte pour dialoguer avec l'homologue du cluster Les volumes de stockages doivent être de taille identique pour éviter les erreurs de synchronisation.

Installer Openfiler 2.3 sur les deux machines en les partitionnant comme ceci:

• 3 GB root (“/”)
• 2 GB “swap”
• 512 MB “/meta” (utilisé pour DRBD0)
• Les partitions de données doivent être configuré comme un volume LVM non monté (utilisé pour DRBD1)

Chaque serveur OpenFiler aura deux interfaces réseau: une pour communiquer sur son réseau, l'autre pour communiquer avec le second membre du cluster, via un câble croisé. La première sera utilisé pour l'administration.

Une IP virtuelle sera également attribuée au cluster. C'est elle qui sera utilisé pour accéder au serveur, et pointera vers la machine active.

Below is what is used:

• ofha1
  • Interface LAN (eth0) 192.168.7.21
  • Interface de réplication (eth1) 192.168.101.11

• ofha2
  • Interface LAN (eth0) 192.168.7.22
  • Interface de réplication (eth1) 192.168.101.12

Adresse IP du cluster (eth0) 192.168.7.20

• Cette adresse est spécifiée dans cluster.xml (ne pas essayer de la configurer ailleurs)

Pour que chaque membre du cluster puisse contacter son homologue (via l'interface de réplication), il faut configurer un nom d'hôte en dur dans /etc/hosts

• sur ofha1:

192.168.101.12 ofha2

• sur ofha2:

192.168.101.11 ofha1

Pour permettre aux deux membres de se parler (via SSH) sans authentification interactive, il faut mettre en place une authentification par clefs SSH

• sur ofha1 et ofha2

ssh-keygen -t rsa -b 2048

Ne pas mettre de mot de passe sur la clef

Il faut maintenant copier la partie publique de la clef * sur ofha1:

cat .ssh/id_rsa.pub | ssh root@ofha2 "cat >> ~/.ssh/authorized_keys"
ssh root@ofha2 chmod 600 ~/.ssh/authorized_keys

• sur ofha2

cat .ssh/id_rsa.pub | ssh root@ofha1 "cat >> ~/.ssh/authorized_keys"
ssh root@ofha1 chmod 600 ~/.ssh/authorized_keys

DRBD est le composant qui permet de synchroniser les données sur les deux machines. Il fonctionne un peu comme du RAID1, mais sur TCP/IP, et permet donc de synchroniser des périphériques blocs à travers le réseau.

• sur ofha1 et ofha2 (a configuration drbd est identique sur les deux nœuds):
  • On sauvegarde d'abord le fichier d'origine:

mv /etc/drbd.conf /etc/drbd.conf.org
vim /etc/drbd.conf

Puis on met en place la nouvelle configuration:

global {
 # minor-count 64;
 # dialog-refresh 5; # 5 seconds
 # disable-ip-verification;
 usage-count ask;
}

common {
 syncer { rate 1000M; }
}

resource cluster_metadata {
 protocol C;
 handlers {
  pri-on-incon-degr "echo O > /proc/sysrq-trigger ; halt -f";
  pri-lost-after-sb "echo O > /proc/sysrq-trigger ; halt -f";
  local-io-error "echo O > /proc/sysrq-trigger ; halt -f";
  # outdate-peer "/usr/sbin/drbd-peer-outdater";
 }
 
 startup {
  # wfc-timeout 0;
  degr-wfc-timeout 120; # 2 minutes.
 }

 disk {
  on-io-error detach;
 }

 net {
  after-sb-0pri disconnect;
  after-sb-1pri disconnect;
  after-sb-2pri disconnect;
  rr-conflict disconnect;
 }

 syncer {
  # rate 10M;
  # after "r2";
  al-extents 257;
 }

 on ofha1 {
  device /dev/drbd0;
  disk /dev/hda2;
  address 192.168.101.11:7788;
  meta-disk internal;
 }

 on ofha2 {
  device /dev/drbd0;
  disk /dev/hda2;
  address 192.168.101.12:7788;
  meta-disk internal;
 }
}

resource vg0drbd {
 protocol C;
 startup {
  wfc-timeout 0; ## Infinite!
  degr-wfc-timeout 120; ## 2 minutes.
 }

 disk {
  on-io-error detach;
 }

 net {
  # timeout 60;
  # connect-int 10;
  # ping-int 10;
  # max-buffers 2048;
  # max-epoch-size 2048;
 }

 syncer {
  after "cluster_metadata";
 }

 on ofha1 {
  device /dev/drbd1;
  disk /dev/hdb;
  address 192.168.101.11:7789;
  meta-disk internal;
 }

 on ofha2 {
  device /dev/drbd1;
  disk /dev/hdb;
  address 192.168.101.12:7789;
  meta-disk internal;
 }
}

ATTENTION: il faut évidemment adapter /dev/hda2 et /dev/hdb respectivement à la partition créé lors de l'install /meta, et au volume de stockage.

Maintenant, sur les deux noeuds, on démonte /meta, on ré-initialise le début de la partition (pour détruire le FS ext3):

umount /meta
dd if=/dev/zero of=/dev/hda2 bs=1M count=1

On répète l'opération sur ofha2.

Puis on initialise les volumes DRBD

drbdadm create-md cluster_metadata
drbdadm create-md vg0drbd

Et on re-fait la même opération sur ofha2.

On en profite également pour supprimer la ligne concernant le système de fichier /meta de /etc/fstab

Il faut maintenant lancer le service drbd sur les deux noeuds:

/etc/init.d/drbd start

Puis on configure ofha1 comme étant le noeud primaire

drbdsetup /dev/drbd0 primary -o
drbdsetup /dev/drbd1 primary -o

On peut ensuite surveiller l'avancement de la synchronisation initiale avec:

/etc/init.d/drbd status

Si tout est OK jusque là, on peut maintenant activer le démarrage automatique de DRBD au démarrage des nœuds:

chkconfig --level 2345 drbd on

(à faire sur les deux nœuds)

Le volume metadata (/dev/drbd0) doit maintenant être formaté.

mkfs.ext3 /dev/drbd0

ATTENTION: il ne faut créer le système de fichier que sur le nœud maître (ofha1). DRBD s'occupera de répliquer tout ça sur le second nœud.

Le volume de donnée (/dev/drbd1) sera configuré pour être utilisé via LVM. La première chose à faire est de configurer LVM pour ignorer les périphériques réelles (/dev/hdb). Il ne devra travailler qu'avec les volumes au dessus de DRBD. Il faut donc éditer le fichier /etc/lvm/lvm.conf. Dans ce fichier, il faut changer la ligne:

filter = [ "a/.*/" ]

par

filter = [ "r|/dev/hdb|" ]

On peut maintenant créer le volume physique (sur ofha1):

pvcreate /dev/drbd1

: il semble y avoir un bug dans la version actuelle d'OpenFiler. Il faut peut-être faire un rollback (merci conary) pour que tout fonctionne:

conary rollback r.66

Heartbeat permettra à chacun des noeuds de vérifier que l'autre est toujours actif, et de lancer certaines action dans le cas contraire.

La première chose à faire et d'éditer le fichier /etc/ha.d/authkeys et de rajouter les lignes suivantes (à faire sur ofha1 et ofha2):

auth 2
2 sha1 mon_secret_hyper_prive

Puis restreindre les permissions sur ce fichier:

chmod 600 /etc/ha.d/authkeys

(à faire sur les deux nœuds)

Maintenant, il faut créer le ficheir de configuration principal de heartbeat:

vim /etc/ha.d/ha.cf

Puis y placer ces lignes:

debugfile /var/log/ha-debug
logfile /var/log/ha-log
logfacility local0
bcast eth1
keepalive 5
warntime 10
deadtime 120
initdead 120
udpport 694
auto_failback off
node ofha1
node ofha2

(à faire sur les deux nœuds, la configuration est identique, comme pour drbd)

On configure maintenant heartbeat pour démarrer automatiquement:

chkconfig --level 2345 heartbeat on

(à faire sur les deux nœuds)

Comme expliqué plus haut, un volume metadata à été créé. Il sera utilisé pour stocker la configuration de certains services qui a besoin d'être commun aux deux nœuds.

Sur ofha1:

mkdir /cluster_metadata
mount /dev/drbd0 /cluster_metadata
mv /opt/openfiler/ /opt/openfiler.local
mkdir /cluster_metadata/opt
cp -a /opt/openfiler.local /cluster_metadata/opt/openfiler
ln -s /cluster_metadata/opt/openfiler /opt/openfiler
rm -f /cluster_metadata/opt/openfiler/sbin/openfiler
ln -s /usr/sbin/httpd /cluster_metadata/opt/openfiler/sbin/openfiler
rm -f /cluster_metadata/opt/openfiler/etc/rsync.xml
ln -s /opt/openfiler.local/etc/rsync.xml /cluster_metadata/opt/openfiler/etc/

Puis on édite /opt/openfiler.local/etc/rsync.xml

<?xml version="1.0" ?>
<rsync>
<remote hostname="192.168.101.12"/> ## IP address of peer node.
<item path="/etc/ha.d/haresources"/>
<item path="/etc/ha.d/ha.cf"/>
<item path="/etc/ldap.conf"/>
<item path="/etc/openldap/ldap.conf"/>
<item path="/etc/ldap.secret"/>
<item path="/etc/nsswitch.conf"/>
<item path="/etc/krb5.conf"/>
</rsync>

Puis:

mkdir -p /cluster_metadata/etc/httpd/conf.d

Maintenant, sur ofha2:

mkdir /cluster_metadata
mv /opt/openfiler/ /opt/openfiler.local
ln -s /cluster_metadata/opt/openfiler /opt/openfiler

Puis on édite /opt/openfiler.local/etc/rsync.xml

<?xml version="1.0" ?>
<rsync>
<remote hostname="192.168.101.11"/> ## IP address of peer node.
<item path="/etc/ha.d/haresources"/>
<item path="/etc/ha.d/ha.cf"/>
<item path="/etc/ldap.conf"/>
<item path="/etc/openldap/ldap.conf"/>
<item path="/etc/ldap.secret"/>
<item path="/etc/nsswitch.conf"/>
<item path="/etc/krb5.conf"/>
</rsync>

Sur ofha1:

mkdir /cluster_metadata/etc
mv /etc/samba/ /cluster_metadata/etc/
ln -s /cluster_metadata/etc/samba/ /etc/samba
mkdir -p /cluster_metadata/var/spool
mv /var/spool/samba/ /cluster_metadata/var/spool/
ln -s /cluster_metadata/var/spool/samba/ /var/spool/samba
mkdir -p /cluster_metadata/var/lib
mv /var/lib/nfs/ /cluster_metadata/var/lib/
ln -s /cluster_metadata/var/lib/nfs/ /var/lib/nfs
mv /etc/exports /cluster_metadata/etc/
ln -s /cluster_metadata/etc/exports /etc/exports

Sur ofha2:

rm -rf /etc/samba/
ln -s /cluster_metadata/etc/samba/ /etc/samba
rm -rf /var/spool/samba/
ln -s /cluster_metadata/var/spool/samba/ /var/spool/samba
rm -rf /var/lib/nfs/
ln -s /cluster_metadata/var/lib/nfs/ /var/lib/nfs
rm -rf /etc/exports
ln -s /cluster_metadata/etc/exports /etc/exports

Sur ofha1:

mv /etc/ietd.conf /cluster_metadata/etc/
ln -s /cluster_metadata/etc/ietd.conf /etc/ietd.conf
mv /etc/initiators.allow /cluster_metadata/etc/
ln -s /cluster_metadata/etc/initiators.allow /etc/initiators.allow
mv /etc/initiators.deny /cluster_metadata/etc/
ln -s /cluster_metadata/etc/initiators.deny /etc/initiators.deny

Sur ofha2:

rm -f /etc/ietd.conf
ln -s /cluster_metadata/etc/ietd.conf /etc/ietd.conf
rm -f /etc/initiators.allow
ln -s /cluster_metadata/etc/initiators.allow /etc/initiators.allow
rm -f /etc/initiators.deny
ln -s /cluster_metadata/etc/initiators.deny /etc/initiators.deny

Sur ofha1:

mv /etc/proftpd /cluster_metadata/etc/
ln -s /cluster_metadata/etc/proftpd/ /etc/proftpd

Sur ofha2:

rm -rf /etc/proftpd
ln -s /cluster_metadata/etc/proftpd/ /etc/proftpd

Sur ofha1:

vgcreate monvg /dev/drbd1

sur ofha1:

rm -f /opt/openfiler/etc/httpd/modules
ln -s /usr/lib64/httpd/modules /opt/openfiler/etc/httpd/modules
/etc/init.d/openfiler restart

NOTE: remplacer /lib64 par /lib si vous utilisez un système 32bits

Puis aller sur https://ofha1:446/admin pour activer le service iSCSI

Le fichier /etc/ha.d/haresources devrait avoir été créé, il faut le copier sur ofha2:

scp /etc/ha.d/haresources root@ofha2:/etc/ha.d/haresources

Avant que heartbeat démarre, il faut qu'un volume logique existe (on pourra le supprimer ensuite)

lvcreate -L 400M -n filer monvg

On peut maintenant redémarrer les deux nœuds, et espérer que tout fonctionne ;)