Comment effectuer une recette exhaustive avec une très grosse volumétrie, sans dupliquer les très gros serveurs ?

C’est un problème récurrent avec Alfresco : un serveur de production contient plusieurs To de données sur le “Content Store”. Je souhaite effectuer un upgrade de mon serveur (vers Alfresco 4.2.1 par exemple) en effectuant un test grandeur nature au préalable. Cependant je n’ai pas un serveur de test avec plusieurs To d’espace libre…

Je vous propose une série d’articles sur ce thème détaillant 3 solutions mises en oeuvre chez des clients :

  • Solution 1 : montage NFS & UnionFS
  • Solution 2 : créer un “Content Store” fantôme
  • Solution 3 : créer un “Content Store” partiel

Solution 1 : Montage NFS & UnionFS

Principe

Cette première solution est idéale si vous pouvez faire communiquer votre serveur de production (ou la baie de stockage) avec votre serveur.

L’idée est simple : sur le serveur de test on charge un backup de la base de données et des indexes lucene. Ensuite on effectue un montage (en lecture seule) du Content Store de production sur le serveur de test, puis on définit un point de montage en écriture au dessus de ce premier montage.

Solution 1 : Montage NFS & UnionFS

Pour cela on a deux possibilités : soit faire un montage à la main, soit utiliser UnionFS.

Première solution : montage à la main

La première solution est très simple à mettre en oeuvre mais n’est pas très flexible.

Nous avons besoin d’un nouveau serveur alfresco. Vous pouvez utiliser une machine virtuelle préconfigurée pour gagner du temps.

Dans un premier temps on restaure un backup de la base de données de production sur notre serveur de test.

mysql -u alfresco -p alfresco < backup-alfresco-2014-04-01.sql

Considérons que nous souhaitons effectuer notre test le 01/04/2014. Un montage NFS du Content Store de production a été configuré sur notre serveur. Ce montage doit obligatoirement être en lecture seule pour protéger les données du serveur de production. Point de montage : /mnt/cs_prod/

On configure un point de montage en écriture pour le jour du test :

mkdir /tmp/cs_test_20140401
mount --bind /tmp/cs_test_20140401 /mnt/cs_prod/contentstore/2014/04/01/

Puis on définit le bon espace dans alfresco-global.properties

dir.root=/srv/alf_data
dir.contentstore=/mnt/cs_prod/contentstore/

Idéalement on utilise un backup des indexes lucene pour éviter une réindexation complète sur notre nouveau serveur.

Enfin on peut lancer Alfresco. Vous voila en présence d’une copie parfaite de votre serveur de production.

Si vous souhaitez travailler plusieurs jours avec ce serveur, il est nécessaire de monter un dossier par jours utiles : ./2014/04/02 ou plus simplement utiliser UnionFS.

Seconde solution : UnionFS

Lorsque les live-cd étaient à la mode (je pense en particulier à Knoppix), il a été mis au point un mécanisme de système de fichiers compressés - squashfs - qui était accessible en lecture seule (car sur un cd-rom).

Pour supporter la modification des fichiers, un système de fichiers - UnionFS - est configuré au dessus du premier. Plusieurs implémentations existent, la plus évoluée est aufs.

Solution 1 : UnionFS (ou AUFS)

C’est cette technologie que nous utilisons.

Comme dans la solution précédente, on réalise un backup de la base de données de production sur notre serveur de test puis montage NFS du Content Store de production (point de montage : /mnt/cs_prod/). Ensuite nous configurons aufs au dessus de notre point de montage NFS.

sudo apt-get install aufs-tools
mkdir /tmp/cs_test
sudo mount -t aufs -o br:/tmp/cs_test:/mnt/cs_prod none /srv/alf_data/contentstore/

Puis on définit le bon espace dans alfresco-global.properties

dir.root=/srv/alf_data
dir.contentstore=/srv/alf_data/contentstore/