A quoi dois-je faire attention lors de la migration d'AWS d'une région vers une autre (Singapour vers Mumbai)

Question

Nous sommes sur le point de migrer d'AWS Singapour à Mumbai. De quoi devrais-je être conscient pendant cette migration de région ou autre?

Answer 1

1. Certains services AWS ne sont pas pris en charge dans toutes les régions. Par exemple, Lambda n'est pas disponible à Mumbai. Assurez-vous que tous vos services requis sont disponibles dans vos régions de destination.

2. De nombreux types d'instances ne sont pas pris en charge dans des régions particulières. Par exemple, les instances m3 ne sont pas disponibles à Mumbai. C'est parce que maintenant nous devrions utiliser m4, mais il n'y a rien comme m4.medium. La classe m4 commence par grande. Donc, vous n'avez pas d'autre choix que d'aller au t2.medium. Assurez-vous que vos types d'instance requis sont disponibles dans votre région de destination.

3. Certaines versions de MySQL RDS ne sont pas disponibles à Mumbai; Par conséquent, vous ne pouvez pas les migrer directement. Vous devrez d'abord mettre à jour votre RDS vers la version MySQL la plus proche. La meilleure façon de migrer RDS est de créer une réplique en lecture dans la région de destination, puis de promouvoir la lecture-réplique sur le maître. Dans toutes les anciennes régions (par exemple Singapour), S3 prend en charge à la fois la version Signature 2 & 4 mais dans les régions plus récentes (par exemple, Mumbai), seule la version 4 de la signature est prise en charge. Cela a été un choc pour nous quand nous avons réalisé que tous nos AWS CLI, SDK pour Java commençaient à échouer lorsque les buckets migraient vers la région de Mumbai. La solution consiste à mettre à jour vos SDK, puis à spécifier la région lors de la demande S3.

Pour nous, ce fut un défi que nous avons dû migrer d'AWS SDK Java 01/08 au 01/11/11 et AWS avait cessé d'utiliser de nombreuses classes de base comme JSONObject, JSONArray etc. Nous utilisions ces classes pour les manipulations JSON dans notre base de code d'application. Par conséquent, beaucoup de réécriture de code a été nécessaire à la hâte.

5. Les compartiments S3 qui sont vraiment énormes et constamment mis à jour ne peuvent pas être simplement migrés vers une autre région. Vous ne pouvez pas simplement supprimer ce compartiment et en créer un nouveau dans la région de destination (après un certain temps) car la synchronisation peut prendre plusieurs jours. Nous pourrions être en accord avec des temps d'arrêt de quelques jours mais pas de 1-2 jours.

Maintenant deux options: d'abord si vous pouvez changer le nom du compartiment; alors vous pouvez avoir zéro temps d'arrêt: créez un nouveau nom de compartiment dans la région de destination et commencez la synchronisation. Assurez-vous que le seau d'origine a activé la "réplication de région croisée" qui s'assure d'ajouter n'importe quel nouvel élément au compartiment de destination. Si ce n'est pas activé aws sync pourrait ne jamais pouvoir rattraper. Une fois la synchronisation terminée vous pouvez changer votre base de code et déployer. Si vous utilisez CDN; N'oublie pas de changer d'origine là aussi.

Si vous ne pouvez pas changer le nom du compartiment; il y aura des temps d'arrêt (en fonction de la taille du seau). Répétez ici la procédure en première option; puis supprimez le bucket d'origine -> créez un autre bucket dans la région de destination avec le même nom après un certain temps -> synchronisez deux buckets dans la même région de destination .. cette synchronisation serait beaucoup plus rapide car elle est dans la même région.

Cette liste n'est pas exhaustive. juste quelques points de douleur que nous avons rencontrés.