Déplacer un serveur en production sans le casser
La plupart des migrations échouent à la bascule plutôt qu'à la copie. Copier des octets est un problème résolu. Voici comment le reste est fait, ce qui ne coûte rien, et où nous nous arrêtons.
La fenêtre de migration gratuite
Une migration par instance durant les 14 premiers jours. Ensuite, c'est du temps ingénieur facturé, devisé avant que quoi que ce soit ne commence.
Chaque nouveau compte reçoit une aide à la migration gratuite pendant 14 jours à partir de la première facture payée. Cela couvre autant d'instances que vous avez commandées, jusqu'à 2 heures de temps ingénieur chacune, ce qui en pratique est bien plus que ce que presque tout le monde utilise.
La fenêtre existe parce que l'alternative est que vous y perdiez un week-end et concluiez que changer d'hébergeur n'en vaut pas la peine. Le faire correctement nous coûte moins cher que de perdre le compte au deuxième mois.
Les grandes flottes reçoivent un plan plutôt qu'un chronomètre. Dites-nous combien d'instances, ce qu'elles exécutent et où elles sont actuellement, et une séquence écrite revient avec un point de rollback à chaque étape.
Le remboursement de 7 jours fonctionne en parallèle. Migrez le jour un, décidez le jour six que la latence ne vous convient pas, et la pièce revient dans l'actif avec lequel vous avez payé.
Ce que nous ferons, et ce que nous ne ferons pas
L'accès fonctionne dans un seul sens. Vous ajoutez une clé que nous générons pour l'opération sur la machine source, nous l'utilisons, puis vous la supprimez une fois la bascule terminée. La clé est propre à chaque migration et ne quitte jamais le poste de travail de l'opérateur. Si votre hébergeur actuel ne le permet pas, une copie au niveau bloc poussée depuis votre côté vers une cible en attente est la solution de repli.
Nous n'avons pas besoin du mot de passe de votre panneau de contrôle chez l'ancien fournisseur et nous le refuserons s'il est proposé. Personne ici ne veut la capacité d'agir à votre place ailleurs, et un ingénieur détenant un identifiant client est une responsabilité sans aucun intérêt.
Nous ferons
Copier les systèmes de fichiers ou des blocs entiers, préparer l'instance cible, ajuster le noyau et les disques récepteurs, exécuter les synchronisations delta, rester avec vous pendant la bascule, et rester sur le ticket jusqu'à ce que le DNS se soit stabilisé.
Nous ne ferons pas
Déboguer votre application, réécrire votre configuration pour une distribution plus récente, déplacer une licence liée au matériel de quelqu'un d'autre, ou prendre un mot de passe. L'accès se fait via une clé temporaire que vous révoquez ensuite.
Nous préférons ne pas
Déplacer une base de données en copiant ses fichiers pendant qu'elle tourne. Cela fonctionne jusqu'à ce que cela ne fonctionne plus, et l'échec se manifeste des semaines plus tard comme une corruption silencieuse. Utilisez plutôt une réplique et une promotion.
Au niveau fichier ou au niveau bloc
Deux façons de déplacer les octets. Le choix dépend principalement de savoir si vous voulez retrouver le même système d'exploitation de l'autre côté.
| Critère | Au niveau fichier, rsync | Au niveau bloc, dd over SSH |
|---|---|---|
| Ce qui est déplacé | Fichiers, permissions, attributs étendus | Tout le dispositif, octet par octet |
| Temps d'arrêt | Minutes, une dernière synchronisation delta | Heures, ou une fenêtre réservée |
| Ce que vous démarrez | Une image actuelle que vous avez choisie | Exactement ce que vous aviez, y compris les résidus |
| Changement de distribution | Possible, c'est même le but | Impossible |
| Risque de bootloader | Aucun, la cible démarre déjà | Réel, et la console est la façon de le résoudre |
| Disques fragmentés importants | Bien gérés | Copie l'espace vide sauf si vous le planifiez |
| Quand choisir | Presque toujours | Machines héritées que personne n'ose reconstruire |
Une troisième option existe et est souvent la plus rapide : ne pas migrer du tout. Remontez le service proprement à partir de votre gestion de configuration, restaurez un dump de base de données, et jetez l'ancienne machine. Si votre infrastructure est reproductible, c'est un travail de deux heures sans étape de copie.
La séquence
Sept étapes, dans cet ordre. Sauter la cinquième est ainsi que les gens se retrouvent à servir depuis deux machines à la fois et ne s'en aperçoivent que le lundi.
- 01
Commandez la cible et laissez-la se stabiliser
De même taille ou plus grande, dans la ville que vous voulez réellement. Faites tourner votre supervision contre elle pendant qu'elle est vide pendant une journée et confirmez que la latence et les chiffres de disque correspondent à ce que la page de plan annonçait.
- 02
Baissez le TTL d'abord
Passez l'enregistrement à 300 secondes au moins 48 heures avant la bascule, afin que l'ancienne valeur ait expiré partout au moment où vous devez la changer. Cette étape ne sert à rien si elle arrive tard.
- 03
Faites la copie à froid
L'essentiel des données, déplacé pendant que tout est encore en production sur l'ancienne machine. Cela prend le temps que cela prend et rien ne l'attend.
- 04
Mettez les services en marche sur la cible
Mêmes versions, même configuration, ne recevant toujours aucun trafic. Les bases de données se restaurent ici, à partir d'un dump plutôt que d'une copie de fichiers.
- 05
Testez la cible par adresse
Faites un override du nom d'hôte localement avec une entrée hosts et utilisez le site correctement pendant une heure. Connectez-vous, écrivez quelque chose, téléversez quelque chose, envoyez un courriel si le site envoie des courriels.
- 06
Gelez, synchronisation finale, bascule
Arrêtez les écritures sur la source, effectuez la dernière synchronisation, vérifiez une somme de contrôle sur quelque chose d'important, puis changez l'enregistrement. La période de gel est généralement inférieure à cinq minutes.
- 07
Gardez la source pendant une semaine
Allumé, ne servant rien, toujours payé. C'est l'assurance la moins chère que vous achèterez jamais, et la seule chose que vous avez oublié de copier refait toujours surface au quatrième jour.
DNS, et tests avant de vous engager
Une bascule est un changement de DNS, et un changement de DNS n'est jamais instantané quel que soit le TTL. Certains résolveurs arrondissent, certains réseaux d'entreprise mettent en cache pendant une journée, et un petit nombre de clients épingle une adresse pour la durée de vie d'un processus. Prévoyez de servir depuis les deux machines pendant 24 heures.
Faire tourner les deux est plus facile qu'il n'y paraît lorsque l'application est sans état. Lorsqu'elle ne l'est pas, mettez l'ancienne machine en lecture seule au moment de la bascule plutôt que de l'éteindre, afin qu'un client obsolète obtienne une erreur évidente au lieu d'écrire dans une base de données que personne ne relira jamais.
Avant de toucher au DNS
Une entrée hosts pointant vers la nouvelle adresse est le seul test honnête qui existe. Les certificats, redirections, URL absolues et adresses codées en dur se brisent ici, devant vous, plutôt que devant vos utilisateurs.
Les certificats d'abord
Émettez sur la cible avant la bascule en utilisant un défi DNS, afin que quelque chose de valide soit déjà en place lorsque la première requête arrive. Un défi HTTP ne peut pas fonctionner avant que le trafic ait déjà été déplacé, ce qui est trop tard.
Le courrier est l'exception
La réputation ne voyage pas avec les données. Une nouvelle adresse envoie depuis zéro historique, alors chauffez-la pendant une quinzaine, conservez SPF, DKIM et DMARC valides sur les deux machines pendant le chevauchement, et attendez-vous à ce que la première semaine soit lente.
Le rollback est un TTL, pas une reconstruction
Tant que la source est vivante et que le TTL est encore bas, annuler la bascule prend un changement d'enregistrement. C'est toute la raison pour laquelle les étapes deux et sept ne sont pas facultatives.
Questions sur la migration
Oui, devis écrit avant que quoi que ce soit ne commence, et généralement un montant modeste. Rien ne commence tant que vous n'avez pas accepté le chiffre.
Oui, au niveau du bloc, dans une image sous licence à 22 € par mois. La réactivation se fait contre le nouveau matériel et nécessite occasionnellement un redémarrage pour se stabiliser.
Alors nous ne pouvons pas aider directement, et vous non plus. Exportez ce que le panneau peut vous donner, reconstruisez sur une image propre, et traitez tout l'épisode comme une leçon sur les panneaux qui possèdent la machine.
Généralement moins de deux heures sur un port 10 Gbit/s, souvent beaucoup moins. La contrainte est presque toujours le débit de l'ancien fournisseur plutôt que notre téléchargement.
Oui, et c'est plus facile car les deux extrémités sont chez nous. Snapshot, restauration dans la nouvelle ville, test, bascule. Déplacer une instance entre nos propres localisations n'entraîne aucun frais.
Vous remettez l'enregistrement, car la source tourne toujours et le TTL est toujours de 300 secondes. C'est le plan plutôt qu'une éventualité, et c'est pourquoi la dernière étape existe.
Dites-nous ce que vous déplacez
Nombre d'instances, vitesse du port de l'ancien fournisseur, données totales, et si quelque chose est une base de données. Un plan écrit revient le même jour ouvrable, et si la réponse honnête est de reconstruire plutôt que de copier, c'est ce que le plan dira.