Questions concernant la migration vers le nouvel OpenStack

Dans cet article, vous trouverez les réponses aux questions les plus fréquentes sur la migration vers la nouvelle plateforme OpenStack.

Comment puis-je préparer mes instances pour cette migration ?

• Arrêtez votre instance puis démarrez-la à nouveau avant la migration pour vérifier qu’elle démarre correctement, sans interruption ni messages d’erreur (un simple redémarrage ne suffit pas).
• Assurez-vous que cloud-init / cloudbase-init est désactivé avant de lancer la migration.
• Effectuez un check du système de fichiers sur tous les systèmes de fichiers avant la migration.
• Vérifiez qu’il n’y a aucune mise à jour en attente sur votre système, afin d’éviter qu’une installation de correctifs ne vienne interrompre la migration.

Pouvez-vous me donner un bref résumé du processus ?

• Votre instance sera migrée vers une instance boot-from-volume.
• Si vous avez une IP flottante, nous la migrerons.
• Nous avons créé un nouveau projet pour vous sur la nouvelle plateforme.
• Si vous utilisez des images personnalisées ou un snapshot pour démarrer l’instance, nous migrerons aussi ces images Glance.
• Si votre instance est connectée à un réseau interne, nous étendrons ce réseau vers la nouvelle région.
• Si vous avez un routeur pour l’accès Internet, l’adresse IP publique changera.
• Si des volumes sont attachés à votre instance, nous les copierons vers la nouvelle plateforme.
• Les snapshots de ces volumes seront perdus.
• Si vous ne désactivez pas cloud-init, la clé d’hôte SSH changera lors de la migration vers la nouvelle région.
• Sur les invités Windows, le mot de passe administrateur sera modifié si cloudbase-init n’était pas désactivé.
• Nous utiliserons un ping ICMP pour vérifier que votre instance est en ligne ; merci de la préparer en conséquence.
• Nous vérifierons aussi les ports courants (22, 80, 443, etc.).
• Si vous avez une configuration HA, il y a quelques points d’attention particuliers.

Toutes mes instances n’ont pas de métadonnées de migration, pourquoi ?

Nous finalisons encore les dernières étapes pour permettre la migration de toutes les instances vers la nouvelle région.

• Si votre instance utilise des volumes ≥ 1024 Go, elle doit être migrée sur un créneau strict afin de limiter l’impact.
• Si votre instance utilise un load balancer, elle sera migrée plus tard.
• Les instances faisant partie d’un grand réseau interne seront migrées plus tard.
• Les configurations HA / VRRP seront migrées plus tard.
• Les réseaux internes avec routeurs personnalisés seront migrés plus tard.

Nos clés SSH seront-elles migrées ?

Oui. Vos clés SSH seront copiées vers la nouvelle région, mais uniquement pour l’instance (elles ne seront pas associées à votre utilisateur).

Mon instance ne fonctionne pas comme prévu après la migration, puis-je faire un rollback ?

Oui, une fois la migration terminée avec succès, vous pouvez effectuer un rollback en définissant la clé de métadonnée rollback-now sur votre instance dans l’ancien tableau de bord Horizon.

Si vous effectuez un rollback, merci de nous indiquer la raison. Nous souhaitons comprendre ce qui s’est passé afin d’améliorer le processus et d’éviter que cela ne se reproduise.

Remarque : Toute modification effectuée sur la nouvelle instance ne sera pas conservée et doit être considérée comme perdue. Un rollback n’est possible que durant les 5 premiers jours suivant la migration.

Si j’ai déjà des instances portant le même nom dans la nouvelle région, seront-elles écrasées ?

Non, rien ne sera écrasé dans la nouvelle région.

Quel sera le temps d’indisponibilité prévu pendant la migration ?

• Nous avons constaté des indisponibilités de moins d’une minute, mais par sécurité vous devez compter jusqu’à 15 minutes (la durée dépend du temps de démarrage de l’instance et des services).
• Nos tests montrent que, sous faible charge, la coupure peut être aussi courte que 40 secondes. Une extinction gracieuse sera lancée via les API OpenStack. Une nouvelle instance sera ensuite créée dans la nouvelle région, avec une copie du disque. Le processus surveille le démarrage et, si celui-ci dépasse 10 minutes, un rollback est déclenché automatiquement.
• Si l’instance est reliée à un réseau interne, cette connexion sera interrompue jusqu’à 10 minutes. Cette connexion est nécessaire pour synchroniser le réseau interne entre l’ancienne région et la nouvelle.
• Une fois la migration terminée et l’instance correctement démarrée dans la nouvelle région, prévoyez encore environ 10 minutes pour que le réseau interne soit pleinement opérationnel.
• Si le réseau interne ne répond toujours pas dans les 20 minutes suivant la fin de la migration, contactez le support et lancez un rollback de votre instance.

La migration d’une instance aura-t-elle un impact sur mes autres instances en production ?

Non, sauf si vous avez vous-même créé une dépendance vis-à-vis de cette instance. Dans le cas contraire, les autres instances ne seront pas impactées.

Comment puis-je lancer moi-même la migration ?

Lorsque votre instance est marquée pour la migration, une métadonnée supplémentaire est ajoutée, nommée o2o-scheduled-YYYY-MM-DDTHH:MM:SS. Vous pouvez planifier la migration en modifiant cette date/heure (fuseau Europe/Amsterdam) selon vos préférences. Une date/heure dans le passé lancera la migration dès qu’un créneau est disponible (généralement en moins d’une minute). Vous pouvez aussi définir la métadonnée o2o-migrate-now sur la clé migrate_flag pour lancer la migration immédiatement.

Pour définir ou modifier les métadonnées de votre instance, ouvrez Horizon : Project > Compute > Instances. Cliquez sur le triangle « more options » à côté de l’instance et choisissez Update Metadata.

Ouvrez Provider platform options > Migration et cliquez sur + à côté de Scheduling options. Modifiez la date et l’heure comme vous le souhaitez, puis cliquez sur Save.

Que se passe-t-il si je ne lance ni ne planifie moi-même la migration ?

Votre instance sera migrée pendant les heures de bureau (9h00–17h00, fuseau Europe/Amsterdam) à la date communiquée par e-mail et indiquée dans les métadonnées.

Puis-je migrer en dehors des heures de bureau ?

Oui, en planifiant la migration via les métadonnées fournies (voir ci-dessus : Comment puis-je lancer moi-même la migration ?).

Que se passe-t-il si la migration échoue ?

En cas d’échec, votre instance sera simplement redémarrée sur l’actuelle plateforme OpenStack.
Nous analyserons la cause du problème et vous informerons d’une nouvelle date de migration.

Comment puis-je vérifier si la migration a réussi ?

Si la migration est réussie, l’instance passera à l’état ‘SHUTOFF’.
Vous pouvez le vérifier via l’API OpenStack Legacy ou dans le tableau de bord Horizon. L’instance sera verrouillée.
La progression de la migration peut être suivie via la métadonnée _export_progress.

Où puis-je gérer mon instance migrée ?

Votre instance migrée se gère via le nouveau tableau de bord Horizon, accessible depuis le Control Panel.

Mon instance est connectée à d’autres via un réseau interne, cela fonctionnera-t-il encore après la migration ?

Oui, votre réseau interne sera étendu vers la nouvelle région.

Je n’ai aucun projet dans la nouvelle région, dois-je en créer un ?

Non. Si vous n’avez pas encore de projet dans la nouvelle région, nous en avons déjà créé un pour vous.

J’ai plusieurs projets dans la nouvelle région, pouvez-vous migrer mes ressources vers un projet existant ?

Oui. Contactez le support avec les correspondances de projets souhaitées, afin que nous puissions les configurer correctement.

Que se passe-t-il avec les snapshots attachés à mes volumes ?

Ils seront perdus, car nous ne pouvons pas dupliquer les snapshots de la plateforme legacy vers la nouvelle plateforme.

Si vous voulez conserver un snapshot, créez un nouveau volume à partir de ce snapshot comme source.
Dans Horizon : Volumes > New Volume > Clone an existing volume.
Vous sélectionnez le volume, puis le snapshot à cloner.

Les images Glance (snapshots / images personnalisées) sont-elles aussi importées dans la nouvelle région ?

Oui, mais uniquement si l’image est encore disponible (non supprimée).

Est-ce que je garde mes adresses IP actuelles ?

Oui, toutes vos adresses IP publiques (floating) et internes seront migrées.

Je souhaite migrer toutes mes ressources le plus vite possible, est-ce possible ?

Nous travaillons en continu à lever les blocages qui empêchent certaines migrations.
Vous pouvez contacter le support pour vérifier si vos instances peuvent déjà être migrées.

Vais-je encore être facturé pour mes ressources migrées sur l’ancienne plateforme ?

À partir du moment où la première migration est lancée, vos ressources actuelles restent facturées jusqu’à ce que toutes les ressources de votre projet soient migrées.
Une fois la migration complète, la facturation se fera depuis ams2 et sera arrêtée sur la plateforme legacy.

Ma clé d’hôte SSH va-t-elle changer si cloud-init est activé ?

Oui. La migration de la plateforme legacy vers la nouvelle région donne une nouvelle UUID et un nouveau nom à votre instance.
Par défaut, cloud-init considère cela comme une nouvelle instance et ré-initialise le système, ce qui renouvelle la clé d’hôte SSH.

Si vous ne voulez pas cela, désactivez cloud-init avant le début de la migration vers la nouvelle région.

Quel flavor aura ma nouvelle instance ?

Nous avons sélectionné avec soin des flavors cibles qui correspondent au mieux aux spécifications et au prix de votre flavor OpenStack Legacy.
Vous pouvez consulter le tableau de correspondance des flavors.
Si le flavor choisi ne vous suffit pas, vous pourrez redimensionner votre instance vers un autre flavor après la migration.

Openstack Legacy	destination
m1.tiny	Small HD 2GB
m1.small	Standard 4GB
m1.medium	Small HD 8GB
m1.xlarge	Small HD 32GB
m1.large	Small HD 16GB
m1.tiny.windows	Standard 1GB
m1.small.windows	Standard 4GB
m1.medium.windows	Small HD 8GB
m1.large.windows	Small HD 16GB
m1.xlarge.windows	Small HD 32GB
vps.1	Standard 1GB
vps.2	Standard 4GB
vps.3	Medium HD 8GB