Migration uMap

[yohanboniface]

On veut migrer uMap sur les nouvelles machines, et en profiter pour passer sur python 3.
Un fabfile existe pour le déploiement, mais il faudra sûrement un peu de boulot manuel pour la migration des fichiers d'une part, et la mise en place d'un backup d'autre part.

• installer la VM
• faire pointer un domaine provisoire dessus
• installer la 1.0.0-rc.x
• rsync les fichiers de /data/work/umap/var/uploads (machine actuelle) vers /srv/umap/media_root (nouvelle machine); il faut migrer seulement les .geojson, pas les fichiers de cache .geojson.gz
• dumper la DB et la restorer sur la nouvelle machine (warning, on va passer de 9.6 à 10, j'ai souvenir que les dump/restore avec un upgrade de majeure PLUS PostGIS au milieu, c'était galère)
• mettre en place un rsync hourly des fichiers (/etc/cron.hourly/umap-sync)
• tester tester tester
• mettre en place un backup des données sur la nouvelle machine (DB et FS)
• mettre l'ancien uMap en mode readonly
• migrer la DB for real

sudo -u postgres -i
dropdb umap
createdb umap -O umap
psql umap < /srv/umap/dump.sql
# En user umap
sudo -u umap -i
psql umap
# appliquer la migration SQL cf https://github.com/umap-project/umap/blob/master/docs/changelog.md
source venv/bin/activate
umap migrate --fake-initial
# En user sudoer
sudo systemctl restart uwsgi nginx

• supprimer le rsync hourly

• lancer un dernier rsync des fichiers

  $ /etc/cron.hourly/umap-sync
  

• changer le SITE_URL dans la config (/etc/umap/umap.conf)

• basculer le DNS

@jocelynj @cquest quelqu'un peut me rappeler l'IP de la VM de destination? :)

[jocelynj]

@yohanboniface La VM disponible est sur osm144.openstreetmap.fr, accessible via un proxy sur dev.umap.openstreetmap.fr.

[yohanboniface]

@jocelynj c'est possible d'avoir une Ubuntu Server LTS plutôt qu'une Debian Jessie?
Mon fabfile s'appuie sur systemd, python3…
Merci :)

[jocelynj]

Pas de souci. ubuntu-17.04 te conviendrait ?

Et je recrée la VM de zero ?

[yohanboniface]

Oui, et oui. Merci :)

[jocelynj]

Voilà, la VM est recrée, et tu as un accès root dessus.

[Marc-marc-marc]

Suite à la discussion sur irc avec @yohanboniface
@jocelynj pourrais-tu réinstaller la vm en Ubuntu 18.04 et m'ajouter les droits root ?

[yohanboniface]

@jocelynj dispo pour relancer le sujet avec une 18.04 maintenant que proxmox a été migré :)

[jocelynj]

J'ai réinstall osm144 avec Ubuntu 18.04.

[yohanboniface]

Serveur déployé et version 1.0.0-rc.1 installée: http://osm144.openstreetmap.fr/en/

La base est vierge. Next step: dump/restore de la prod, et migration des fichiers.

Pour les fichiers, il faut exclure les .geojson.gz.
Une suggestion pour la migration (sachant qu'on va la faire en deux temps): plutôt compresser, rsync, décompresser ? Ou plutôt rsync récursif ?

[yohanboniface]

du -sch /data/work/umap/var/uploads/datalayer
257G	total

[yohanboniface]

du -sch /data/work/umap/var/uploads/datalayer --exclude '*.gz'
201G	total

[jocelynj]

Je crois qu'il y a plein de petits fichiers, et que faire un tar.gz pour copier les fichiers irait bien plus vite qu'un rsync;

[yohanboniface]

Mon hésitation c'est notamment parce qu'on va devoir le faire deux fois, et qu'avec rsync la deuxième fois ira potentiellement plus vite en mode incrémental?

[yohanboniface]

dumper la DB et la restorer sur la nouvelle machine (warning, on va passer de 9.6 à 10, j'ai souvenir que les dump/restore avec un upgrade de majeure PLUS PostGIS au milieu, c'était galère)

Pas de galère:

• Sur la machine actuelle: dump SQL, sans format custom: pg_dump umap > dump.sql
• Sur la nouvelle machine: psql umap < path/vers/dump.sql à jouer en user postgres sur une base vierge.

[yohanboniface]

$ ll uploads.tgz
145097282  52G -rw-r--r--  1 umap umap  52G Jul 15 11:33 uploads.tgz

$ time tar -czvf uploads.tgz uploads/ --exclude '*.gz'
real    663m7.901s
user    149m20.644s
sys     8m18.555s

Ça fait 11 heures si je dis pas de bêtises.
Ça veut dire 11 heures entre le moment où on met uMap en readonly et le moment où on bascule le DNS sur la nouvelle machine, ça me semble trop long.

[jocelynj]

Ce que je pensais, c'est de:

• copier le tar.gz que tu as créé et démarrer la nouvelle instance avec ces fichiers
• faire un rsync incrémental
• couper les mises à jour sur l'ancienne instance et la nouvelle
• refaire le rsync incrémental
• switcher le DNS une fois que c'est fini

[yohanboniface]

OK, donc on combine les deux.
Je vais tester ça :)

[yohanboniface]

humm, j'ai l'impression que juste le transfert du gros .tgz met le serveur (actuel) dans les choux…

[yohanboniface]

Avec ça ça tient le coup:

$ rsync --partial --progress --bwlimit=5000 osm102.openstreetmap.fr:/data/work/umap/var/uploads.tgz uploads.tgz 

[yohanboniface]

$ time tar -xzvf uploads.tgz
real    74m25.156s
user    26m47.508s
sys     7m38.584s

[yohanboniface]

Mise à jour incrémentale après une nuit:

time rsync --archive --update --verbose --exclude='*.gz' --bwlimit=5000 osm102.openstreetmap.fr:/data/work/umap/var/uploads/ /srv/umap/media_root/

real    34m52.929s
user    0m10.885s
sys     0m23.419s

Je vais mettre un cron pour lancer une fois par jour je pense en attendant la bascule.

[yohanboniface]

Pour le backup: @jocelynj propose qu'on ait une deuxième instance en parallèle, sur laquelle on rsync les données et la DB.
Ça me va bien aussi.
Par contre, @jocelynj: en backloguant IRC, je crois comprendre que tu voudrais attendre qu'osm11 soit remis au propre pour y mettre la VM de backup. Mais du coup j'ai l'impression qu'on va avoir un problème d'œuf et de poule: pour remettre osm11 au propre, il faut avoir migré uMap sur osm144, mais pour basculer uMap complètement il faut un backup, mais pour avoir un backup il faut avoir remis osm11 au propre… ;)

[Marc-marc-marc]

a-t-on besoin d'avoir un backup "live" pour migrer ? ce serrait un + mais on n'en a pas pour le moment, donc je pense pas que cela doive être un prérequis pour migrer.

pour le design, en cas de backup "live", je pense que cela aurait du sens de diviser fichier<>db
Avoir 2 frontend "app+fichier"est facile et redondant (j'imagine que la taille de modif de fichier n'est pas grande)
2 backend "bdd" séparé est bien comode pour l'admin

[yohanboniface]

a-t-on besoin d'avoir un backup "live" pour migrer ? ce serrait un + mais on n'en a pas pour le moment, donc je pense pas que cela doive être un prérequis pour migrer.

Live, non, mais un backup, je dirais oui :)

pour le design, en cas de backup "live", je pense que cela aurait du sens de diviser fichier<>db
Avoir 2 frontend "app+fichier"est facile et redondant (j'imagine que la taille de modif de fichier n'est pas grande)
2 backend "bdd" séparé est bien comode pour l'admin

Honnêtement, je pense qu'on peut aller très loin avec un seul serveur comme aujourd'hui (avec un backup, quel qu'il soit, bien sûr). Le serveur est loin d'être utilisé à plein, et garder une architecture simple est de mon point de vue gage de solidité, de faible coût de maintenance, et donc de bonnes et douces nuits pour ceux qui sont réveillés quand ça plante ;)

[jocelynj]

Concernant le backup:

• actuellement, on n'a pas vraiment de backup, du coup, ça ne me choquait pas d'attendre que osm11 soit à niveau pour y re-installer une instance umap.
• je pensais à un backup lancé une fois par jour plutôt que live, mais sur un instance umap qui marche. L'idée serait de pouvoir juste changer le DNS en cas de souci hardware, comme pour les deux instance d'overpass. De plus, ça peut permettre des tests de mise à jour de umap.

On peut sinon installer une autre instance umap sur osm12 (où on avait prévu à l'origine d'y migrer la VM directement), ou alors sur une autre machine du cluster OVH.

[yohanboniface]

actuellement, on n'a pas vraiment de backup,

Tu me fais peur! On est pas censé sauvegarder les fichiers et la DB chaque nuit?

je pensais à un backup lancé une fois par jour plutôt que live

Oui, ça me va aussi.

On peut sinon installer une autre instance umap sur osm12

Si y a la place, ce serait cool. Comme ça on peut basculer l'esprit tranquille, et puis on pourra toujours redéplacer la VM de backup sur osm11 quand il sera tout beau tout propre :)

[jocelynj]

Tu me fais peur! On est pas censé sauvegarder les fichiers et la DB chaque nuit?

La BDD est sauvegardé par backuppc, via des fichiers dans /data/project/pgdump/

Pour les fichiers, je ne vois pas de cron sur osm102, et je ne sais pas sur quelle machine ça serait sauvegardé. Il me semble qu'on en avait déjà discuté, mais sans mettre de plan en route :(

Au sujet d'osm12, le disque a l'air rempli par les images aériennes - il ne reste de 500G de libre, Je vois avec @cquest ce qu'on peut virer.

[jocelynj]

J'ai copié manuellement le script pour backupper la base de donnée, dans /data/project/pgdump.

[yohanboniface]

Au sujet d'osm12, le disque a l'air rempli par les images aériennes - il ne reste de 500G de libre, Je vois avec @cquest ce qu'on peut virer.

Des news sur ce point? :)

[yohanboniface]

J'ai copié manuellement le script pour backupper la base de donnée, dans /data/project/pgdump.

C'est actif ou il faut faire quelque chose?

[jocelynj]

Concernant le backup de la bdd, c'est actif - peut-être qu'il faudrait que tu rajoutes le script dans ta config umap ?

Pour osm12, je n'ai pas avancé :(

[yohanboniface]

Pour mémoire, j'ai fait un rsync sur osm159 (backup temporaire) depuis osm144:

sent 33,084,992 bytes  received 229,050,882,457 bytes  4,857,332.00 bytes/sec
total size is 228,865,903,590  speedup is 1.00

real    786m3.354s
user    26m14.133s
sys     18m5.371s

[yohanboniface]

Je programmerais bien la bascule un de ces samedis d'août (pour être vraiment au bas de la fréquentation en édition et avoir le week-end devant nous pour traiter les rapports de bugs éventuels). Et comme ça on peut prévenir un peu à l'avance sur la ML.
@jocelynj y a un week-end pendant lequel tu serais dispo?

[jocelynj]

La migration a été faite ce week-end vers osm144. J'ai aussi modifié la configuration de la VM pour aligner avec osm102 - 8 cpus et 8 Go de ram.