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.
Vagues de migration, serveurs et bases de données
Les projets de migration commencent par la liste de questions ouvertes suivante, communes aux trois scénarios décrits dans la section précédente :
-
Comment créer des vagues de migration ?
-
Comment regrouper les serveurs au sein de chaque vague ?
-
Les serveurs de base de données doivent-ils être migrés avant ou avec les serveurs d'applications ?
-
Quel outil devons-nous utiliser pour les migrations de bases de données ?
Toutefois, pour répondre à ces questions, nous devons d'abord clarifier certaines définitions. Cette section du guide se concentre sur le terme « base de données » et sur ce qu'il signifie dans le contexte des vagues migratoires. Cette définition est importante, car la compréhension de ce terme pourrait modifier l'approche globale de la migration pour des vagues de migration particulières ou même modifier les vagues de migration en déplaçant les serveurs entre différentes vagues.
Le terme base de données décrit-il un serveur qui exécute le logiciel DBMS ou le point d'entrée de la base de données logique ? Fait-il référence à une base de données parmi plusieurs sur le même serveur ou à un cluster de serveurs ? Selon le contexte, une base de données peut faire référence à l'une ou l'autre option. Les administrateurs de base de données (DBAs) considèrent généralement les bases de données logiques et non les serveurs physiques. Toutefois, dans le contexte d'une migration, en particulier de lift-and-shift migrations à grande échelle, une base de données correspond généralement à un serveur physique ou à un cluster de serveurs.
La migration d'une base de données doit être alignée et associée à l'application avec laquelle elle fonctionne, car la base de données logique fait toujours partie de l'application et de ses dépendances. Toutefois, l'emplacement physique de cette base de données logique peut varier. Par exemple, elle peut se trouver à l'un des emplacements suivants :
-
Un serveur physique autonome, sans la présence d'autres bases de données.
-
Un serveur physique autonome colocalisé avec d'autres bases de données logiques.
-
Cluster de serveurs physiques, sous forme de base de données logique unique ou faisant partie d'un ensemble plus important de bases de données destinées à d'autres applications.
L'établissement du mappage des dépendances pour les vagues de migration est compliqué s'il n'existe pas de one-to-one dépendance claire entre l'application et les serveurs de base de données, en particulier lorsque plusieurs bases de données logiques provenant de différentes applications sont colocalisées sur le même serveur physique. De tels systèmes de bases de données nécessitent une approche de replate-forme impliquant une décomposition ou une consolidation des bases de données, ce qui complique les efforts de migration à grande échelle lift-and-shift.
C'est là que les outils de migration de base de données (tels que les outils natifs des fournisseurs du moteur de base de données ou de tiers) peuvent être utiles. Ces outils fonctionnent au niveau de la base de données logique plutôt que selon l'approche de réplication au niveau des blocs AWS Application Migration Service, et peuvent déplacer les données ou les bases de données au niveau logique entre des serveurs physiques et des sites. Ces outils de migration de base de données natifs peuvent vous aider à consolider les bases de données logiques sur un seul serveur physique. Ils peuvent également faire le contraire : ils peuvent décomposer des bases de données logiques entre différents serveurs de base de données physiques, afin de les aligner sur différentes applications et de les répartir sur différentes vagues de migration.
