Cloud Privé : Déroulement des migrations obligatoires
Découvrez notre offre de Cloud Public
L'hébergement mutualisé pour tou·te·s, imaginé par des développeur·euse·s, pour des développeur·euse·s.
Découvrir le Cloud PublicCes migrations sont effectuées à quatre mains avec le support.
Recommandé
Étape 1 - Faire les changements nécessaires
L’utilisateur prépare l’ensemble des comptes du serveur en suivant les recommandations de la page de documentation (comme sur le Cloud Public). Il est possible de revenir en arrière pour corriger des comportements problématiques.
Cette étape sert à tester le déplacement des bases de données, vérifier les paramètres de connexion de ses logiciels…
Des serveurs de tests sont disponibles pour les bases de données.
Une fois la migration d’un compte vers le serveur de transit effectuée il sera aussi possible de faire un retour en arrière et de le repasser sur l’ancienne infrastructure temporairement en cas de souci.
Obligatoire
Étape 2 - Demande du serveur de transit
Tous les comptes sont prêts. L’utilisateur doit contacter le support pour qu’il prépare un serveur de transit.
Étape 3 - Installation du serveur de transit
Le support prépare le serveur de transit d’une configuration équivalente au serveur client. L’installation peut durer plusieurs heures et précopie les fichiers et mails sur le serveur de transit.
Cette étape dépend de la disponibilité de serveurs de transit correspondant à la configuration du serveur client le jour de la demande. Il peut y avoir de l’attente.
Étape 4 - Migration des comptes sur la nouvelle infrastructure
Le serveur de transit est prêt. L’utilisateur peut migrer ses comptes - un par un - sur le serveur de transit, via le menu Migrations de l’interface serveur ou le menu Avancé > Migrations de l’interface compte.
L’utilisateur est autonome lors de cette étape. Il peut effectuer ses migrations quand il le souhaite.
La migration des comptes entraîne une coupure par compte de quelques secondes à quelques heures ; selon la taille de chaque compte (particulièrement des bases de données). On compte en général une minute d’indisponibilité par giga de bases de données.
Pour les domaines n’utilisant pas les DNS d’alwaysdata, pas besoin de faire le changement d’IP - enregistrements A et AAAA. Le serveur client fera la redirection de manière transparente.
Étape 5 - Vérification après migration
L’utilisateur peut faire des modifications applicatives une fois un compte migré si besoin.
Il lui est aussi possible de faire un retour en arrière et repasser temporairement sur l’ancienne infrastructure en cas de souci.
Une fois l’ensemble des comptes migrés il contacte le support pour que celui procède à la réinstallation de son serveur.
Étape 6 - Réinstallation du serveur client
Tous les comptes sont migrés sur la nouvelle infrastructure logicielle et sont sur le serveur de transit.
Le support réinstalle le serveur client pour qu’il tourne sur la nouvelle infrastructure. Cela peut durer plusieures heures et précopie à les fichiers et mails.
Le retour en arrière temporaire n’est alors plus possible.
Durant cette opération, les adresses IP du serveur client sont reroutées vers le serveur de transit pour que les services restent accessibles normalement. Une courte période d’indisponibilité de ces IP (autour d’une minute) est toutefois à prévoir. Dans le cas où l’utilisateur utilise les serveurs DNS d’alwaysdata, le trafic aura été redirigé vers les IP du serveur de transit dès la migration des comptes - il n’y a alors aucune période d’indisponibilité à prévoir.
Étape 7 - Redéplacement des comptes sur le serveur client
Le serveur client est réinstallé. Le support contacte l’utilisateur pour procéder au redéplacement des comptes de manière transparente. Ce déplacement peut avoir lieu en heures et jours ouvrés.
Ce redéplacement final des comptes entraîne une coupure par compte équivalente à l’indisponibilité lors de la première migration.
Étape 8 - Migration officiellement finie
Tous les comptes ont été redéplacés sur le serveur client réinstallé.
Le serveur de transit est mis à disposition sans surcoût pour une période de deux semaines maximum. Si l’utilisateur n’a pas terminé la migration de l’ensemble de ses comptes au terme de cette période, le serveur de transit sera facturé au même coût que le serveur client (au prorata, jour par jour) — en plus du serveur d’origine qui reste facturé normalement.
Icônes : The Noun Project