WordPress cluster ACTIF/ACTIF

périmé
17 juin 2015

Cluster ACTIF/ACTIF avec mariadb/galera, glusterfs, keepalived et mon.######

Dans le cadre d’un projet wordpress, je devais mettre en place une réplication du site web et une procédure de Haute dispo.
Plutot que de rester sur du DRDB et mysql en master/slave, je me suis dis que c’était l’occasion de tester le couple mariadb/galera et glusterfs.

L’idée est de construire un cluster actif/actif avec 2 serveurs, dont
un serveur est actif par défaut (W1).

W1 est synchronisé avec W2 en temps réel via Galera pour mariadb et GlusterFS.

W2 est synchronisé avec W1 en temps réel via Galera pour mariadb et GlusterFS.

Keepalived pointe par défaut sur W1.

En cas de panne de W1, il y a une bascule sur W2. Le site est dispo et modifiable via W2. Lorsque l’erreur est corrigée sur W1, la bascule de la prod se fait sur W1, et toutes les modifications apportées sur W2, le temps de la panne, sont appliquées sur W1.

Les tests ont été éffectués sur DEBIAN 7, à l’heure actuelle je n’ai pas trouvé de paquet galera fonctionnant correctement sous DEBIAN 8.

Toutes les fichiers php de wordpress sont stockés dans /mnt/www/
URL du site : http://192.168.16.32/.

INSTALLATION DE GLUSTERFS######

Sur les 2 serveurs
apt-get install glusterfs-server

root@wordpress1:~# glusterfsd –version

glusterfs 3.2.7 built on Sep 28 2013 18:15:16
Repository revision: git://git.gluster.com/glusterfs.git
Copyright (c) 2006-2011 Gluster Inc. <http://www.gluster.com>
GlusterFS comes with ABSOLUTELY NO WARRANTY.
ou may redistribute copies of GlusterFS under the terms of the GNU      General Public License.

. Ajoute dans le status le serveur wordpress2 pour W1 et vice versa

root@wordpress1:~# gluster peer probe wordpress2

Probe successful

root@wordpress2:~# gluster peer probe wordpress1

Probe successful

. Création du répertoire source pour Glusterfs

root@wordpress1:~# mkdir /data

root@wordpress2:~# mkdir /data

. Création et démarrage du volume

root@wordpress1:~# gluster volume create mntwww replica 2 transport tcp wordpress1:/data wordpress2:/data

Creation of volume mntwww has been successful. Please start the volume to access data.

root@wordpress1:~# gluster volume start mntwww

Starting volume mntwww has been unsuccessful

root@wordpress1:~# gluster volume info

Volume Name: mntwww
Type: Replicate
Status: Started
Number of Bricks: 2
Transport-type: tcp
Bricks:
Brick1: wordpress1:/data
Brick2: wordpress2:/data

Le script /etc/init.d/glusterfs-server doit être activé au démarrage

. Ce volume sera monté via glusterfs client

apt-get install glusterfs-client

root@wordpress (1 et 2):~# mkdir /mnt/www

root@wordpress1:~# mount.glusterfs wordpress1:/mntwww /mnt/www
root@wordpress2:~# mount.glusterfs wordpress2:/mntwww /mnt/www

root@wordpress1:~# mount

wordpress1:/mntwww on /mnt/www type fuse.glusterfs   (rw,relatime,user_id=0,group_id=0,default_permissions,allow_other,max_read=131072)

root@wordpress1:~# more /etc/fstab

wordpress1:/mntwww /mnt/www/  glusterfs defaults,_netdev 0 0 

root@wordpress2:~# more /etc/fstab

wordpress2:/mntwww /mnt/www/  glusterfs defaults,_netdev 0 0 
INSTALLATION DE GALERA/MARIADB####

apt-get install python-software-properties
apt-key adv –recv-keys –keyserver keyserver.ubuntu.com 0xcbcb082a1bb943db
add-apt-repository ‘deb http://mirror3.layerjet.com/mariadb/repo/5.5/debian wheezy main’
apt-get update

apt-get install -y rsync galera mariadb-galera-server

Stopper mysql sur tous les noeuds

. Configuration

Editez le fichier /etc/mysql/conf.d/galera.cnf sur W1 et W2

[mysqld]
#mysql settings
binlog_format=ROW
default-storage-engine=innodb
innodb_autoinc_lock_mode=2
query_cache_size=0
query_cache_type=0
bind-address=0.0.0.0
#galera settings
wsrep_provider=/usr/lib/galera/libgalera_smm.so
wsrep_cluster_name="my_wsrep_cluster"
wsrep_cluster_address="gcomm://192.168.16.30,192.168.16.31"
wsrep_sst_method=rsync

. Création du cluster

root@wordpress1:~# service mysql start –wsrep-new-cluster

Pour valider :

root@wordpress1:~# mysql -u root -e ‘SELECT VARIABLE_VALUE as "cluster size" FROM INFORMATION_SCHEMA.GLOBAL_STATUS WHERE VARIABLE_NAME="wsrep_cluster_size"’

+--------------+
| cluster size |
+--------------+
| 1            |
+--------------+

root@wordpress2:~# service mysql start

Pour valider :

root@wordpress2:~# mysql -u root -e ‘SELECT VARIABLE_VALUE as "cluster size" FROM INFORMATION_SCHEMA.GLOBAL_STATUS WHERE VARIABLE_NAME="wsrep_cluster_size"’

+--------------+
| cluster size |
+--------------+
| 2            |
+--------------+           

.Correction

remplacer /etc/mysql/debian.cnf de W2 par celui de W1. Pour que le script mysql stop fonctionne

INSTALLATION DE KEEPALIVED et MON####

apt-get install keepalived mon

Installation classique de keepalived sur les 2 nœuds avec comme ip virtuelle : 192.168.16.32
Installation classique de mon avec comme monitoring glusterfs :

service glusterfs 
        description glusterfs service
        interval 5s
        monitor tcp.monitor -p 24007 127.0.0.1 
        period wd {Mon-Sun}
                alert keepalived.alert ghis@le5emeaxe.fr
        alertafter 3
        alertevery 1h
        upalert keepalived.alert ghis@le5emeaxe.fr  

La valeur d’interval est faible, c’est uniquement pour des tests, vous pouvez mettre a 60s pour de la prod.

Les autres services monitorés sont : apache, mysql et le ping

Le fichier keepalived.alert est dispo ici
à placer dans /usr/lib/mon/alert.d/.

Ne pas oublié d’ajouter l’user mon dans la ficher /etc/sudoers.d pour que mon puisse killer keepalived.

# Cmnd alias specification

Cmnd_Alias KEEP=/etc/init.d/keepalived

# User privilege specification
mon     ALL=NOPASSWD:KEEP
INSTALLATION DE WORDPRESS#######

Installation de wordpress classique. Juste déployer le répertoire de wordpress dans /mnt/www (point de mountage de glusterfs) et ne le faire que sur W1. La réplication étant en place, l’install se fera toute seul sur W2 (sauf pour la conf apache/php qui est a faire sur les 2 serveurs).

QUELQUES TESTS#######
  • Mode normal modif W1 => Synchro W2

    • Modif existant maj OK
    • Nouvel article maj OK
    • Nouvel upload pic maj OK
  • stop keepalived W1, => Bascule W2 (modif) et retour sur W1

    • Modif existant maj OK
    • Nouvel article maj OK
    • Nouvel upload pic maj OK
  • stop mariadb W1, => Bascule W2 (modif) et retour sur W1

    • Modif existant maj OK
    • Nouvel article maj OK
    • Nouvel upload pic maj OK
  • stop glusterfs W1 => Bascule W2 (modif) et retour sur W1

    • Modif existant maj OK
    • Nouvel article maj OK
    • Nouvel upload pic maj OK
  • stop mariadb W2, Test sur W1 et reactivation W2 puis stop keepalived W1

    • Modif existant maj OK
    • Nouvel article maj OK
    • Nouvel upload pic maj OK

stop glusterfs W2, Test sur W1 et reactivation W2 puis stop keepalived W1

- Modif existant     maj OK
- Nouvel article        maj OK
- Nouvel upload pic     maj OK
Quelques points pour l’installation dans un container OPENVZ#####

Après l’installation classique (suivant le compte rendu ci dessus), l’acces au montage via glusterfs-client etait vraiment top lent. Donc l’acces a glusterfs se fera par un mountage NFS.

Par défaut un CT dans proxmox ne supporte pas FUSE et NFS. Voici comment les activer, à entrer dans un shell sur l’hôte physique proxmox.

FUSE

CT Online

vzctl set $VEID --devices c:10:229:rw --save
vzctl exec $VEID mknod /dev/fuse c 10 229

CT Offline

vzctl set $VEID --capability sys_admin:on --save

NFS

vzctl set $VEID  --features "nfs:on" --save

un CT openvz ne tiens pas du compte du FSTAB au boot

more /etc/fstab

# UNCONFIGURED FSTAB FOR BASE SYSTEM
localhost:/mntwww   /mnt/www/   nfs defaults,_netdev,rsize=8192,wsize=8192,timeo=14,auto,intr  0 0

Une ligne a été ajouter dans /etc/rc.local

su root -c "/bin/mount -a > /tmp/mount"

STARTING

Dans la documentation, il faut démarrer le cluster mariadb par la commande –wsrep-new-cluster mais uniquement si aucun noeud n’est démarré, sinon la cluster tombe. Il faut donc modifier le script de démarrage de mysql pour que:

le noeud 1 démarre avec le mode wsrep-new-cluster et ensuite envoyer au noeud 2 la commande classique de démarrage.

'clusterstart')
      ...
   /usr/bin/mysqld_safe --wsrep-new-cluster "${@:2}" > /dev/null 2>&1 &
  ...
   ssh root@10.1.227.172 "/etc/init.d/mysql start"

Il ne faut pas placer le service mysql en autostart mais ajouter dans rc.local

/etc/init.d/mysql clusterstart