Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Matrice de décision
Bien que chaque migration soit unique et comporte ses propres défis, limites et ses multiples facteurs à prendre en compte, il existe des critères communs que vous pouvez utiliser pour identifier la stratégie et le service de migration les plus adaptés à votre cas d'utilisation. L'identification et la priorisation de ces facteurs vous aident à affiner le choix. Utilisez le tableau suivant comme arbre de décision : commencez par le facteur le plus important pour votre cas d'utilisation et choisissez le meilleur outil pour votre migration.
Note
Le tableau suivant fournit des facteurs directionnels de haut niveau à prendre en compte ; il n'inclut pas de liste exhaustive de critères pour un projet de migration. L'objectif est de fournir une comparaison généralisée de deux méthodes de migration de données très différentes : la réplication au niveau des blocs (fournie par Application Migration Service) et la réplication logique au niveau des données (fournie par une multitude d'outils de migration de base de données natifs). Ces deux méthodes sont applicables dans de nombreux scénarios de migration et peuvent parfois être utilisées ensemble, mais elles présentent également des avantages uniques que le tableau met en évidence.
Critères |
AWS Application Migration Service |
Outils de base de données (outils natifs ou AWS DMS) |
|---|---|---|
Architecture |
Physique (au niveau du bloc) |
Logique, au niveau du moteur de base de données |
Échelle |
Migration à grande échelle |
Granulaire ; limites d'échelle |
Rapidité ou complexité |
Scénario de sortie rapide ; complexité réduite |
Approche plus lente et plus complexe ; nécessite davantage de planification et de tests |
Chronologie |
Prise en charge d'une chronologie agressive |
Efforts et temps supplémentaires requis |
Type de migration |
Lift and shift tel quel (un-à-un uniquement) |
Replate-forme ou modernisation avec options de décomposition et de consolidation (un à plusieurs, plusieurs à un) |
Allocation préalable |
Non obligatoire ; migration automatique |
Allocation de base de données et d'infrastructure requise |
Temps d'arrêt |
Temps d'arrêt requis, avec un objectif de délai de reprise (RTO) de quelques minutes |
Interruptions de service quasi nulles possibles, mais très coûteuses (grâce à des clusters étendus synchrones/asynchrones, à la réplication CDC et à des méthodes similaires) |
Taux de modification des données |
Peut présenter des limites de mise en réseau ou de performances |
Plus d'options disponibles |
Limitations |
Ne prend pas en charge la plupart des systèmes en cluster ; * ne prend en charge que les plateformes x86** |
Les outils de base de données natifs prennent en charge les bases de données en cluster et les plateformes non x86 ; AWS DMS couvre la plupart des moteurs de base de données |
* La méthode de réplication au niveau des blocs ne prend pas en charge le stockage rattaché au réseau (NAS), les disques partagés tels que les partages NFS ou les partages. CIFS/SMB Il prend uniquement en charge le stockage au niveau des blocs directement connecté au système migré au moment de la migration. (Pour plus d'informations, consultez la FAQ du service de migration d'applications sur le support SAN/NAS.) Cela limite l'applicabilité de la réplication via le service de migration d'applications pour la plupart des systèmes en cluster, car la majorité des clusters reposent sur le stockage partagé de différentes implémentations. Pour plus d'informations, consultez la AWS Application Migration Service section Avantages et inconvénients de la migration avec plus haut dans ce guide.
** La méthode de réplication au niveau des blocs nécessite l'installation d'un agent de AWS réplication au niveau du système d'exploitation, et cet agent ne prend en charge que les plateformes x86 basées sur le système d'exploitation Windows ou Linux (voir Systèmes d'exploitation pris en charge par le service de migration d'applications). Les plateformes non x86 ne sont pas concernées par cette méthode de migration. Il s'agit notamment d'ARM, RISC/CISC des systèmes, des variantes PowerPC, des systèmes IBM tels que pSeries, iSeries, zSeries, et de leurs systèmes d'exploitation respectifs tels que AIX, HP-UX, Solaris, Linux pour PowerPC, ZLinux sur les mainframes et d'autres architectures non x86.
