Déplacer une instance vers un autre site

Il n'y a pas de migration à chaud entre villes

Quiconque vous en propose copie des pages mémoire sur un chemin à cent millisecondes de latence, et ce qui arrive sera plus lent que ce qui est parti. Nous faisons la version honnête : arrêt, copie du disque, démarrage à l'autre bout. Entre deux sites européens, un disque de deux cents gigaoctets est généralement copié en dix minutes. À travers un océan, prévoyez le double.

Les copies passent par notre propre backbone et ne comptent pas dans votre volume d'usage raisonnable.

La procédure

1. Réduisez le TTL de tout enregistrement DNS pointant vers l'instance, au moins un jour à l'avance. Soixante secondes est le bon réglage pendant le déplacement.
2. Prenez un instantané. Il reste sur l'ancien site jusqu'à ce que vous le supprimiez, et c'est votre filet de sécurité.
3. Demandez le déplacement, en nommant le code du site de destination.
4. L'instance s'arrête, le disque est copié, et elle démarre sur le site de destination avec une nouvelle IPv4 et un nouveau /64.
5. Mettez à jour les enregistrements A et AAAA, configurez le DNS inverse sur les nouvelles adresses, et recherchez tout ce qui utilise une adresse en dur.
6. Réaugmentez le TTL une fois que tout est stable.

curl -s -X POST https://paragonvps.com/api/v1/instances/<instance-id>/migrate -H "Authorization: Bearer $Paragon_TOKEN" -H "Content-Type: application/json" -d '{"site":"FRA-01"}'

curl -s https://paragonvps.com/api/v1/jobs/<job-id> -H "Authorization: Bearer $Paragon_TOKEN" | jq -r .state

L'ancienne adresse

Conservée pendant soixante-douze heures après le déplacement, afin que vous puissiez y laisser une redirection et rattraper ce qui y pointe encore. Ensuite, elle retourne dans le pool. Prévenez-nous avant le déplacement si vous en avez besoin plus longtemps et nous la garderons.

L'alternative à quasi zéro temps d'arrêt

Lorsqu'un arrêt de dix minutes est inacceptable, construisez d'abord la destination et copiez pendant que l'original est encore en service :

rsync -aHAX --numeric-ids --info=progress2 --exclude=/proc --exclude=/sys --exclude=/dev --exclude=/run /srv/ deploy@<new-ipv4>:/srv/

Exécutez-la deux fois : une fois service actif, une fois après l'arrêt, afin que la seconde passe ne transporte que le delta. Basculez le DNS entre les deux passes. C'est plus de travail et plus de risque qu'une copie de disque, et c'est la bonne réponse pour une base de données avec une réplique et la mauvaise réponse pour un serveur web qui peut être indisponible le temps d'un café.

Choisir la destination

Les médianes de latence issues de nos propres sondes sont sur la page des emplacements. La juridiction est l'autre moitié de la décision et, pour une bonne part de nos clients, la plus importante — le site que vous choisissez détermine la loi sous laquelle se trouve votre disque, et aucun ticket de support ne changera cela ensuite.

Le stock compte aussi. Un site marqué faible prendra la commande puis prendra son temps pour la remplir, et un site en précommande n'est pas un endroit où déplacer un service en production.

Ce qui casse

• Les licences Windows s'activent en fonction du matériel et de l'adresse. Attendez-vous à devoir réactiver.
• Tout ce qui est épinglé par adresse sur le pare-feu de quelqu'un d'autre. Demandez-leur avant le déplacement, pas après que le téléphone sonne.
• Les adresses codées en dur dans votre propre configuration. grep -r le répertoire de configuration pendant que l'ancienne instance est encore en cours d'exécution, car c'est le moment où les réponses sont faciles à vérifier.