Blue Mind Forum

Forum about Blue Mind Software

You are not logged in.

Announcement

Bonjour, avant de poster, merci de vérifier que vous avez respecté les pré-requis de l'installation et consultez notre documentation : https://forge.bluemind.net/confluence/display/BM35/ !
Vous pouvez en particulier trouver des réponses aux problèmes les plus courants dans notre FAQ ou encore la base de connaissance.

Hi, before posting on the forum, please check that you followed installation prerequisites and get a look to our documentation space : https://forge.bluemind.net/confluence/display/BM35/ !

#1 2020-07-26 12:17:16

syn
Member
Registered: 2016-02-14
Posts: 10

Migration BlueMind 3 vers 4

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 :

# 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

Ce que l'on peut corriger en rajoutant un espace swap:

# 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

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.

Offline

#2 2020-07-28 09:10:55

syn
Member
Registered: 2016-02-14
Posts: 10

Re: Migration BlueMind 3 vers 4

Pour suivi, j'ai finalement supprime le contenu de /var/spool/bm-cyrus-replication.

En commencant par deplacer le plus vieux ficher et le plus recent (ne sachant pas si c'est une FIFO ou LIFO). Redemarrage des services, aucun changement.
J'ai supprime une centaine de fichiers, nouveau redemarrage, toujours aucun vidage en vu.
J'ai enfin supprime/re-cree le dossier.


J'ai donc pu reprendre mes migrations, en gardant un oeil sur un watch ls /var/spool/bm-cyrus-replication.
De temps a autres, on voit un fichier ".eml" arriver, et disparaitre en suivant
Et parfois, plusieurs centaines de fichiers ".bin" sont ecrits. Mais eux, une fois ecrit : plus rien.

Apres le million de fichiers dont je parlais dans mon post initial, tous purges : je retrouve encore 24000 fichiers, pour ~200Mo, en fin d'imapsync.
Principalement des petits fichiers, 5 a 10 Ko. J'y retrouve des mails d'alerte fail2ban, des messages envoyes aux mailing-lists archlinux, debian ou freebsd. Rien de tres inhabituel, dans le contenu ou le format. Je me demande ce qui coince ...

En y regardant de plus pres, il semblerait que tous ces fichiers aient ete crees dans un court interval de temps, quelques minutes sur les dernieres 24h de migration :

# ls -ltr |head -2 ; echo == ; ls -ltr | tail -2 ; echo == ; ls -1 | wc -l
total 186656
-rw-r--r-- 1 root root  5409 Jul 26 19:58 t36686.bin
==
-rw-r--r-- 1 root root  4756 Jul 26 20:00 t60582.bin
-rw-r--r-- 1 root root  7713 Jul 26 20:00 t60581.bin
==
23709

Je vais les laisser trainer quelques jours, ca ne prend pas de place, ... voire s'il se passe quelque chose, eventuellement.
Mais quelque chose me dit que ces fichiers ne bougeront plus.

Sait-on expliquer ce comportement ?
Que se passe-t-il ? Est-ce normal ?


Cordialement.

Offline

Board footer

Powered by FluxBB