La base de la migration au niveau de la base de données est le journal d'archivage Oracle, qui contient un journal des modifications apportées à la base de données. La plupart du temps, un journal d'archivage fait partie d'une stratégie de sauvegarde et de restauration. Le processus de restauration commence par la restauration d'une base de données, puis la relecture d'un ou plusieurs journaux d'archivage pour ramener la base de données à l'état souhaité. Cette même technologie de base peut être utilisée pour effectuer une migration avec une interruption des opérations nulle ou minime. Plus important encore, cette technologie permet la migration tout en conservant la base de données d'origine intacte, ce qui permet de conserver un chemin de retour.

Le processus de migration commence par la restauration d'une sauvegarde de base de données sur un serveur secondaire. Vous pouvez le faire de différentes manières, mais la plupart des clients utilisent leur application de sauvegarde normale pour restaurer les fichiers de données. Une fois les fichiers de données restaurés, les utilisateurs établissent une méthode d'envoi des journaux. L'objectif est de créer un flux constant de journaux d'archivage générés par la base de données primaire et de les relire sur la base de données restaurée afin de les conserver dans un état similaire. Lorsque le délai de mise en service arrive, la base de données source est complètement arrêtée et les journaux d'archivage finaux, et dans certains cas les journaux de reprise, sont copiés et relus. Il est essentiel que les journaux de reprise soient également pris en compte, car ils peuvent contenir certaines des transactions finales validées.

Une fois ces journaux transférés et relus, les deux bases de données sont cohérentes l'une avec l'autre. À ce stade, la plupart des clients effectuent des tests de base. Si des erreurs sont commises pendant le processus de migration, la relecture du journal doit signaler les erreurs et échouer. Il est toujours conseillé d'effectuer des tests rapides basés sur des requêtes connues ou des activités applicatives pour vérifier que la configuration est optimale. Il est également courant de créer une table de test finale avant d'arrêter la base de données d'origine pour vérifier qu'elle est présente dans la base de données migrée. Cette étape permet de s'assurer qu'aucune erreur n'a été effectuée lors de la synchronisation finale du journal.

Une simple migration d'envoi de journaux peut être configurée hors bande par rapport à la base de données d'origine, ce qui la rend particulièrement utile pour les bases de données stratégiques. Il n'est pas nécessaire de modifier la configuration de la base de données source, car la restauration et la configuration initiale de l'environnement de migration n'affectent pas les opérations de production. Une fois l'envoi de journaux configuré, il impose des demandes d'E/S sur les serveurs de production. Cependant, l'envoi de journaux se compose de simples lectures séquentielles des journaux d'archivage, qui n'ont probablement aucun impact sur les performances des bases de données de production.

L'expédition de journaux s'est avérée particulièrement utile pour les projets de migration longue distance à taux de changement élevé. Dans un cas, une seule base de données de 220 To a été migrée vers un nouvel emplacement situé à environ 500 kilomètres. Le taux de modification était extrêmement élevé et les restrictions de sécurité empêchaient l'utilisation d'une connexion réseau. L'expédition des journaux a été effectuée à l'aide de bandes et de coursiers. Une copie de la base de données source a d'abord été restaurée à l'aide des procédures décrites ci-dessous. Les journaux ont ensuite été expédiés chaque semaine par messagerie jusqu'au moment de la mise en service, lorsque le jeu final de bandes a été livré et que les journaux ont été appliqués à la base de données de réplica.

Dans certains cas, un environnement DataGuard complet est garanti. Il est incorrect d'utiliser le terme DataGuard pour faire référence à toute configuration d'envoi de journaux ou de base de données de secours. Oracle DataGuard est un framework complet de gestion de la réplication de base de données, mais il ne s'agit pas d'une technologie de réplication. Le principal avantage d'un environnement DataGuard complet dans un effort de migration est le basculement transparent d'une base de données à une autre. DataGuard permet également un basculement transparent vers la base de données d'origine en cas de problème, tel qu'un problème de performances ou de connectivité réseau avec le nouvel environnement. Un environnement DataGuard entièrement configuré nécessite la configuration non seulement de la couche de base de données, mais aussi des applications pour que les applications puissent détecter un changement dans l'emplacement de la base de données primaire. En général, il n'est pas nécessaire d'utiliser DataGuard pour effectuer une migration, mais certains clients possèdent une expertise DataGuard étendue en interne et en dépendent déjà pour le travail de migration.

Comme évoqué précédemment, l'exploitation des fonctionnalités avancées des baies de stockage nécessite parfois de modifier l'organisation de la base de données. De plus, une modification du protocole de stockage, telle que le passage d'ASM à un système de fichiers NFS, modifie nécessairement la disposition du système de fichiers.

L'un des principaux avantages des méthodes d'envoi de journaux, y compris DataGuard, est que la destination de réplication ne doit pas correspondre à la source. Il n'y a pas de problème avec l'utilisation d'une approche d'envoi de journaux pour migrer d'ASM vers un système de fichiers standard, et inversement. La disposition précise des fichiers de données peut être modifiée à la destination pour optimiser l'utilisation de la technologie de base de données enfichable (PDB) ou pour définir des contrôles QoS de manière sélective sur certains fichiers. En d'autres termes, un processus de migration basé sur l'envoi de journaux vous permet d'optimiser facilement et en toute sécurité l'organisation du stockage de la base de données.

La migration au niveau de la base de données est limitée par le besoin d'un second serveur. Ce second serveur peut être utilisé de deux manières :

La première option est la plus simple, mais son utilisation peut ne pas être possible dans les environnements très vastes nécessitant des serveurs très puissants. La deuxième option nécessite un travail supplémentaire pour replacer les systèmes de fichiers à leur emplacement d'origine. Il peut s'agir d'une opération simple dans laquelle NFS est utilisé comme protocole de stockage car les systèmes de fichiers peuvent être démontés du serveur de transfert et remontés sur le serveur d'origine.

Les systèmes de fichiers basés sur les blocs nécessitent un travail supplémentaire pour mettre à jour le zoning FC ou les initiateurs iSCSI. Avec la plupart des gestionnaires de volumes logiques (y compris ASM), les LUN sont automatiquement détectées et mises en ligne après leur mise à disposition sur le serveur d'origine. Cependant, certaines implémentations de système de fichiers et de LVM peuvent nécessiter davantage de travail pour exporter et importer les données. La procédure précise peut varier, mais il est généralement facile d'établir une procédure simple et reproductible pour terminer la migration et réexécuter les données sur le serveur d'origine.

Bien qu'il soit possible de configurer l'envoi de journaux et de répliquer une base de données dans un environnement de serveur unique, la nouvelle instance doit avoir un SID de processus différent pour pouvoir relire les journaux. Il est possible d'afficher temporairement la base de données sous un autre ensemble d'ID de processus avec un SID différent et de la modifier ultérieurement. Toutefois, cela peut entraîner de nombreuses activités de gestion complexes et mettre l'environnement de base de données en danger d'erreur de la part des utilisateurs.

La valeur d'une opération de copie simple ne doit pas être sous-estimée. Les infrastructures réseau modernes peuvent déplacer des données à un taux de gigaoctets par seconde. Les opérations de copie de fichiers reposent sur des E/S efficaces en lecture et écriture séquentielles Si une opération de copie de l'hôte est plus perturbant que l'envoi de journaux, la migration ne se limite pas au déplacement des données. Elle inclut généralement les modifications apportées au réseau, au délai de redémarrage de la base de données et aux tests de post-migration.

Le temps réel nécessaire à la copie des données peut ne pas être important. En outre, une opération de copie préserve un chemin de retour garanti, car les données d'origine ne sont pas modifiées. En cas de problème pendant le processus de migration, les systèmes de fichiers d'origine avec les données d'origine peuvent être réactivés.

Le changement de plate-forme fait référence à un changement de type de CPU. Lorsqu'une base de données est migrée d'une plate-forme Solaris, AIX ou HP-UX traditionnelle vers Linux x86, les données doivent être reformatées en raison de modifications de l'architecture CPU. Les processeurs SPARC, IA64 et POWER sont connus sous le nom de processeurs big endian, tandis que les architectures x86 et x86_64 sont connues sous le nom de Little endian. Par conséquent, certaines données des fichiers de données Oracle sont triées différemment selon le processeur utilisé.

Jusqu'ici, les clients ont généralement utilisé DataPump pour répliquer des données sur plusieurs plateformes. DataPump est un utilitaire qui crée un type spécial d'exportation de données logiques qui peut être importé plus rapidement dans la base de données de destination. Comme il crée une copie logique des données, DataPump laisse derrière lui les dépendances de l'endianness du processeur. DataPump est encore utilisé par certains clients pour le changement de plateforme, mais une option plus rapide est désormais disponible avec Oracle 11g : les tablespaces interplateformes transportables. Cette avance permet de convertir un espace de table en un format endian différent. Il s'agit d'une transformation physique qui offre de meilleures performances qu'une exportation DataPump, qui doit convertir les octets physiques en données logiques, puis les convertir en octets physiques.

Une discussion complète sur DataPump et les tablespaces transportables va au-delà de la documentation NetApp portée, mais NetApp propose quelques recommandations basées sur notre expérience d'assistance aux clients lors de la migration vers une nouvelle baie de stockage dans le cadre d'une nouvelle architecture de processeur :

Les LVM fonctionnent en déregroupant un groupe d'une ou de plusieurs LUN en petites unités généralement appelées extensions. Le pool d'extensions est ensuite utilisé comme source pour créer des volumes logiques qui sont essentiellement virtualisés. Cette couche de virtualisation apporte de la valeur de plusieurs manières :

La migration à l'aide d'un LVM fonctionne de deux manières : déplacer une extension ou mettre en miroir/démirroring une extension. La migration des LVM utilise des E/S séquentielles de blocs de grande taille efficaces et pose rarement des problèmes de performances. Si ce problème survient, il existe généralement des options pour limiter le taux d'E/S. Cela augmente le temps nécessaire à la migration, tout en réduisant la charge d'E/S sur l'hôte et les systèmes de stockage.

Oracle ASM est un gestionnaire de volumes logiques et un système de fichiers combinés. À un niveau élevé, Oracle ASM prend un ensemble de LUN, les répartit en petites unités d'allocation et les présente comme un seul volume appelé groupe de disques ASM. ASM permet également de mettre en miroir le groupe de disques en définissant le niveau de redondance. Un volume peut être sans miroir (redondance externe), en miroir (redondance normale) ou en miroir tridirectionnel (redondance élevée). La configuration du niveau de redondance doit être effectuée avec précaution car il ne peut pas être modifié après sa création.

ASM fournit également des fonctionnalités de système de fichiers. Bien que le système de fichiers ne soit pas visible directement depuis l'hôte, la base de données Oracle peut créer, déplacer et supprimer des fichiers et des répertoires sur un groupe de disques ASM. Vous pouvez également naviguer dans la structure à l'aide de l'utilitaire asmcmd.

Comme pour les autres implémentations LVM, Oracle ASM optimise les performances d'E/S en segmentant et en équilibrant les E/S de chaque fichier sur l'ensemble des LUN disponibles. Deuxièmement, les extensions sous-jacentes peuvent être déplacées pour permettre le redimensionnement du groupe de disques ASM ainsi que la migration. Oracle ASM automatise le processus tout au long de l'opération de rééquilibrage. Les nouvelles LUN sont ajoutées à un groupe de disques ASM et les anciennes LUN sont abandonnées, ce qui déclenche le déplacement d'extension et le DROP suivant de la LUN évacuée du groupe de disques. Ce processus est l'une des méthodes de migration les plus éprouvées, et la fiabilité d'ASM pour assurer une migration transparente est probablement sa fonctionnalité la plus importante.

La migration de bases de données entre des systèmes NetApp est presque effectuée de manière universelle avec le logiciel de réplication des données NetApp SnapMirror. Ce processus implique la configuration d'une relation de miroir pour les volumes à migrer, leur permettant ainsi de se synchroniser, puis d'attendre la fenêtre de mise en service. Lorsqu'elle arrive, la base de données source est arrêtée, une dernière mise à jour miroir est effectuée et le miroir est cassé. Les volumes de réplica sont alors prêts à l'emploi, soit en montant un répertoire de système de fichiers NFS contenu, soit en découvrant les LUN contenues et en démarrant la base de données.

La relocalisation des volumes dans un seul cluster ONTAP n'est pas considérée comme une migration, mais plutôt comme une routine volume move fonctionnement. SnapMirror est utilisé en tant que moteur de réplication des données au sein du cluster. Ce processus est entièrement automatisé. Il n'y a pas d'étape de migration supplémentaire à effectuer lorsque les attributs du volume, tels que le mappage de LUN ou les autorisations d'exportation NFS, sont déplacés avec le volume lui-même. La relocalisation ne prend pas en charge l'hôte. Dans certains cas, il convient de mettre à jour l'accès au réseau pour s'assurer que les données nouvellement déplacées sont accessibles de la manière la plus efficace possible, mais sans interruption.

La FLI est une fonctionnalité qui permet à un système Data ONTAP exécutant la version 8.3 ou supérieure de migrer un LUN existant à partir d'une autre baie de stockage. La procédure est simple : le système ONTAP est zoné sur la baie de stockage existante comme s'il s'agissait d'un autre hôte SAN. Data ONTAP prend alors le contrôle des LUN héritées souhaitées et migre les données sous-jacentes. De plus, le processus d'importation utilise les paramètres d'efficacité du nouveau volume lors de la migration des données. Ainsi, les données peuvent être compressées et dédupliquées en ligne pendant le processus de migration.

La première implémentation de FLI dans Data ONTAP 8.3 a permis uniquement la migration hors ligne. Ce transfert était extrêmement rapide, mais cela signifiait que les données de LUN étaient indisponibles jusqu'à la fin de la migration. La migration en ligne a été introduite dans Data ONTAP 8.3.1. Ce type de migration minimise les interruptions en permettant à ONTAP de transmettre des données LUN lors du processus de transfert. Il y a une brève interruption lors de la remise en place de l'hôte pour l'utilisation des LUN via ONTAP. Cependant, dès que ces modifications sont apportées, les données sont de nouveau accessibles et restent accessibles tout au long du processus de migration.

Les E/S de lecture sont proxées via ONTAP jusqu'à la fin de l'opération de copie, tandis que les E/S d'écriture sont écrites de manière synchrone sur les LUN étrangères et ONTAP. Les deux copies LUN sont ainsi synchronisées jusqu'à ce que l'administrateur exécute une mise en service complète qui libère le LUN étranger et ne réplique plus les écritures.

FLI est conçu pour fonctionner avec FC. Toutefois, si vous souhaitez passer à iSCSI, le LUN migré peut facilement être remappé en tant que LUN iSCSI une fois la migration terminée.

Parmi les caractéristiques de FLI figurent la détection et le réglage automatiques de l'alignement. Dans ce contexte, le terme alignement fait référence à une partition sur un périphérique LUN. Pour des performances optimales, les E/S doivent être alignées sur des blocs de 4 Ko. Si une partition est placée à un décalage qui n'est pas un multiple de 4K, les performances en pâtissent.

Il existe un deuxième aspect de l'alignement qui ne peut pas être corrigé en réglant un décalage de partition, c'est-à-dire la taille du bloc du système de fichiers. Par exemple, un système de fichiers ZFS prend généralement par défaut une taille de bloc interne de 512 octets. D'autres clients utilisant AIX ont parfois créé des systèmes de fichiers jfs2 avec une taille de bloc de 512 ou 1, 024 octets. Bien que le système de fichiers puisse être aligné sur une limite de 4 Ko, les fichiers créés dans ce système de fichiers ne le sont pas et les performances en pâtissent.

FLI ne doit pas être utilisé dans ces circonstances. Bien que les données soient accessibles après la migration, vous obtenez des systèmes de fichiers avec de graves limitations de performances. En principe, tout système de fichiers prenant en charge une charge de travail de remplacement aléatoire sur ONTAP doit utiliser une taille de bloc de 4 Ko. Cela s'applique principalement aux charges de travail telles que les fichiers de données de base de données et les déploiements VDI. La taille de bloc peut être identifiée à l'aide des commandes appropriées du système d'exploitation hôte.

Par exemple, sous AIX, la taille de bloc peut être affichée avec lsfs -q. Avec Linux, xfs_info et tune2fs peut être utilisé pour xfs et ext3/ext4, respectivement. Avec zfs, la commande est zdb -C.

Le paramètre qui contrôle la taille du bloc est ashift et la valeur par défaut est généralement 9, soit 2^9, ou 512 octets. Pour des performances optimales, le ashift La valeur doit être 12 (2^12=4K). Cette valeur est définie au moment de la création du zpool et ne peut pas être modifiée, ce qui signifie que les zpools de données avec un ashift une migration autre que 12 doit être effectuée en copiant les données vers un nouveau zpool.

Oracle ASM n'a pas de taille de bloc fondamentale. La seule exigence est que la partition sur laquelle le disque ASM est construit doit être correctement alignée.

L'outil 7-mode transition Tool (7MTT) est un utilitaire d'automatisation utilisé pour migrer de grandes configurations 7-mode vers ONTAP. La plupart des clients de bases de données trouvent d'autres méthodes plus faciles, notamment parce qu'ils migrent généralement leurs environnements de bases de données par base de données plutôt que de déplacer l'intégralité de l'empreinte du stockage. De plus, les bases de données ne font souvent partie que d'un environnement de stockage plus important. Les bases de données sont donc souvent migrées individuellement, puis le reste de l'environnement peut être déplacé avec 7MTT.

Les clients sont de petite taille, mais nombreux. Ils disposent de systèmes de stockage dédiés à des environnements de base de données complexes. Ces environnements peuvent contenir de nombreux volumes, snapshots et de nombreuses informations de configuration telles que les autorisations d'exportation, les groupes initiateurs de LUN, les autorisations utilisateur et la configuration du protocole d'accès aux répertoires légers. Dans de tels cas, les fonctionnalités d'automatisation de l'outil 7MTT simplifient considérablement la migration.

7MTT peut fonctionner dans deux modes :

La différence principale entre ces deux options est que la transition sans copie constitue une approche globale où tous les tiroirs disques rattachés à la paire HA 7-mode d'origine doivent être transférés vers le nouvel environnement. Il n'existe aucune option pour déplacer un sous-ensemble de tiroirs. L'approche basée sur les copies permet de déplacer des volumes sélectionnés. Par ailleurs, une fenêtre de mise en service peut être plus longue et la transition sans copie est liée à l'alignement des tiroirs disques et à la conversion des métadonnées. En fonction de son expérience sur le terrain, NetApp recommande de consacrer 1 heure au déplacement et à la réinstallation des tiroirs disques, et entre 15 minutes et 2 heures à la conversion des métadonnées.