Bonjour,
En cours de migration, BlueMind 3.5.2 vers 4.2.7, petit serveur, 10aine d’utilisateurs, un peu plus de 2 millions de messages (~ 30Gi dans le /var/spool/cyrus du serveur source).
Je rencontre plusieurs problemes.
1/ permissions telegraf/postfix. Post-install, telegraf crash des erreurs en boucle. Pour corriger :
chgrp -R telegraf /var/spool/postfix/{active,hold,incoming,deferred}
chmod -R g+rXs /var/spool/postfix/{active,hold,incoming,deferred}
if grep postdrop /etc/group | grep telegraf >/dev/null; then
usermod -a -G postdrop telegraf
fi
chmod g+r /var/spool/postfix/maildrop
if which setfacl >/dev/null 2>&1; then
setfacl -Rdm u:telegraf:rX /var/spool/postfix/{active,hold,incoming,deferred,maildrop}
fi
2/ telegraph cgroups : des erreurs en boucle, lorsque les cgroups ne sont pas actives :
Jul 26 12:21:50 xx telegraf[775]: 2020-07-26T10:21:50Z E! [inputs.exec]: Error in plugin: exec: exit status 1 for command 'cat /sys/fs/cgroup/cpu/system.slice/bm-cyrus-imapd.service/cpuacct.usage': cat: /sys/fs/cgroup/cpu/system.slice/bm-cyrus-imapd.service/cpuacct.usage: No such file or directory
Jul 26 12:21:50 xx telegraf[775]: 2020-07-26T10:21:50Z E! [inputs.exec]: Error in plugin: exec: exit status 1 for command 'cat /sys/fs/cgroup/cpu/system.slice/bm-php-fpm.service/cpuacct.usage': cat: /sys/fs/cgroup/cpu/system.slice/bm-php-fpm.service/cpuacct.usage: No such file or directory
...
3/ crashs elasticsearch. De maniere “aleatoire” (parfois quelques secondes apres le demarrage, d’autres plusieurs jours), elasticsearch s’arrete. Les journaux mentionnent un exit code 127. Mais aucun logs qui n’expliquent concretement ce qu’il se passe.
Pour l’instant, j’ai rajoute une crontab, toutes les 2 minutes, pour check/restart le service. Ce qui est sale / peu recommendable …
# tail -1 /etc/crontab
*/2 * * * * root /bin/systemctl status bm-elasticsearch >/dev/null 2>&1 || /bin/systemctl restart bm-elasticsearch >/dev/null 2>&1
En soi, le service ne semble pas indispensable a la “bonne marche” des operations – la console fonctionne bien, les imapsync continuent de tourner, … Ce n’est qu’en regardant mes logs, que je vois des traces “Permission denied” et “no nodes available”.
4/ saturations disque, /var/spool/bm-cyrus-replication.
J’ai commence ma migration il y a plus d’une semaine aujourd’hui. Dans les premieres 24h, apres la copie des premiers ~ 1 ou 2Gi de messages sur le nouveau serveur, mes imapsync se sont arretes, la partition /var/spool du serveur cible etant saturee.
Suite a la copie de quelques centaines de milliers de mails (RAF : plusieurs millions), je retrouve mon /var/spool plein. 70G, dont 64Gi dans le /var/spool/bm-cyrus-replication. Un ls dans le dossier demande plusieurs minutes, plusieurs dizaines de milliers de fichiers, sur un seul niveau d’arboresence, …
Ici, je ne sais pas trop quoi faire.
J’ai etendu ma partition, de 70 a 300Gi.
J’ai vu l’utilisation disque descendre de 70 a 20Gi.
Au passage, il faudra aussi re-passer les indexes elasticsearch en lecture/ecriture – la saturation disque a tout bascule en lecture seule :
$ curl -XPUT localhost:9200/_cluster/settings?pretty \
-H 'Content-Type: application/json' -d '{
"persistent" : {
"cluster" : {
"blocks" : {
"read_only" : "false"
}
}
}
},
{
"acknowledged" : true,
"persistent" : {
"cluster" : {
"blocks" : {
"read_only" : "false"
}
}
},
"transient" : { }
}'
$ curl -XPUT localhost:9200/_all/_settings?pretty \
-H 'Content-Type: application/json' \
-d '{ "index.blocks.read_only_allow_delete": null }'
Apres ajout de disque, la semaine derniere, j’ai pu reprendre ma migration, qui s’est de nouveau coupe hier soir.
A nouveau, je sature mon /var/spool, 300Gi – pour rappel, je migre 30Gi de mails, j’approche des 90% copies, …, je ne m’attendais pas a ce que la nouvelle VM demande plus de 10x la volumetrie originale, …
Que se passe-t-il ? Est-ce normal ?
Dispose-t-on d’un visuel sur l’etat du service / quels taches sont en cours, combien de messages en attentes, … ?
Puis-je vider /var/spool/bm-cyrus-replication ? Je ne suis pas bien sur de comprendre sa fonction, j’imagine qu’il est question d’extraire des metadata des messages recu, … est-ce indispensable / puis-je me passer de ces infos, au moins le temps de finaliser ma migration ?
J’ai du interrompre ma migration, et ne suis pas sur de pouvoir conclure.
Contrairement a ma derniere saturation, le contenu de /var/spool/bm-cyrus-replication ne semple plus depiler. De 300Gi, je suis descendu a 299, la situation n’evolue plus depuis quelques heures.
J’ai etendu le disque a 350Gi. ElasticSearch repartie, la situation est stable. Mais si je continue de rajouter du disque : c’est sur mon serveur de backups, que je n’aurai plus la place de copier mes snapshots.
Je ne compte pas relancer mes imapsync, tant que je n’aurai pas su faire de la place sur le serveur cible.
En dernier recours, je vais peut-etre devoir abandonner BlueMind 4 pour l’instant, et installer une 3.5 – le premier but de ma migration etant de remplacer ma derniere Debian Jessie, qui ne pourra bientot plus mettre a jour son certificat LetsEncrypt, …
J’hesite a stopper tous les services, rm -fr /var/spool/bm-cyrus-replication, re-creer le dossier, chown/chmod et bmctl start.
Sauriez-vous m’expliquer, quels seraient les consequences d’une telle action ? Avant que je ne casse tout, …
5/ les precos ressources sont peut-etre trop faibles (https://forge.bluemind.net/confluence/display/BM4/Prerequis+a+l’installation).
Pour BM 3.5, ou le 2.0 que j’avais avant : 2 CPU et 8Gi de RAM etaient en effet suffisant. Aujourd’hui, j’en suis moins sur.
Suite a mon dernier filesystem plein, le systeme ne redemarrait plus “completement” (postfix et bm-elasticsearch HS). Postfix demarre bien, avec un systemctl restart. Pour elasticsearch : on voit le load CPU passer a 100%, pendant une a deux minutes, et ca re-vautre.
Je suis passe de 9 a 10Gi de memoire, j’ai pu recuperer elasticsearch. Mais si le systeme semble stable, je sais encore provoquer un OOM :
[code]# ls /var/spool/bm-cyrus-replication/
ls: memory exhausted
free -m
total used free shared buff/cache available
Mem: 9898 7196 1598 108 1104 2291
Swap: 0 0 0[/code]
Ce que l’on peut corriger en rajoutant un espace swap:
[code]# dd if=/dev/zero bs=1M count=4096 of=/var/spool/swap
chmod 0600 /var/spool/swap
mkswap /var/spool/swap
echo /var/spool/swap swap swap defaults 0 0 >>/etc/fstab
swapon -a
free -m
total used free shared buff/cache available
Mem: 9898 7196 1598 108 1104 2291
Swap: 4095 0 4095
df -i /var/spool
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/vdb 109M 14M 95M 13% /var/spool
df -h /var/spool
Filesystem Size Used Avail Use% Mounted on
/dev/vdb 350G 303G 48G 87% /var/spool
ls bm-cyrus-replication/ | wc -l
12544473
ls -ltr bm-cyrus-replication/ | head -5
total 254593080
-rw-r–r-- 1 root root 4343 Jul 22 13:56 t28.bin
-rw-r–r-- 1 root root 27926 Jul 22 13:56 t40.bin
-rw-r–r-- 1 root root 8421 Jul 22 13:56 t39.bin
-rw-r–r-- 1 root root 9913 Jul 22 13:56 t38.bin
date
Sun 26 Jul 2020 12:50:42 PM CEST
free -m
total used free shared buff/cache available
Mem: 9898 5396 3010 52 1491 4151
Swap: 4095 2089 2006[/code]
Et je rebondis sur le point precedant : quelque chose semble “bloque”. Les plus vieux messages s’empilent depuis 5 jours.
Comment expliquer ce comportement ? Est-il possible de corriger proprement ?
Le rm me demange …
Sans doutes la situation va-t-elle s’ameliorer avec les prochaines mises a jour. Pour l’instant, BM 3.5 m’a l’air plus safe.
Dans un contexte sans clients Windows / outlook, au plus quelques telephones en activesync, clients Thunerbirds sans plugin, ou webmail : je ne suis pas convaincu que BM4 n’apporte grand chose. L’interface est tres similaire. Une 3.5 sera sans doutes plus mature ?
Que recommenderiez-vous ?
Merci,
Cordialement.