Alfresco : Test d'upgrade avec une grosse volumétrie - 1
Alfresco : Test d'upgrade avec une grosse volumétrie - 1
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 œuvre 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.
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 œuvre 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.
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/