La meilleure option de migration dépend de plusieurs facteurs, notamment de l'étendue de l'environnement à migrer, de la nécessité d'éviter les temps d'indisponibilité et des efforts globaux requis pour effectuer la migration. Les bases de données volumineuses nécessitent évidemment plus de temps et d'efforts pour la migration, mais la complexité de cette migration est minimale. Les petites bases de données peuvent être migrées rapidement. Toutefois, si des milliers d'entre elles doivent être migrées, l'ampleur des efforts peut engendrer des complications. Enfin, plus la base de données est volumineuse, plus elle est susceptible d'être stratégique, ce qui entraîne la nécessité de minimiser les temps d'indisponibilité tout en préservant un chemin « back-out ».

Voici quelques-uns des éléments à prendre en compte lors de la planification d'une stratégie de migration.

La taille des bases de données à migrer a de toute évidence un impact sur la planification de la migration, bien que la taille n'ait pas nécessairement un impact sur le délai de mise en service. Lorsqu'une grande quantité de données doit être migrée, la principale considération est la bande passante. Les opérations de copie s'effectuent généralement via des E/S séquentielles efficaces En guise d'estimation prudente, on suppose une utilisation de 50 % de la bande passante réseau disponible pour les opérations de copie. Par exemple, un port FC de 8 Go peut en théorie transférer environ 800 Mbit/s. Si l'on suppose une utilisation de 50 %, une base de données peut être copiée à un taux d'environ 400 Mbit/s. Ainsi, une base de données de 10 To peut être copiée en sept heures environ à ce rythme.

La migration sur de longues distances nécessite généralement une approche plus créative, comme le processus d'expédition des journaux expliqué dans "Déplacement du fichier de données en ligne". Les réseaux IP longue distance disposent rarement d'une bande passante proche des vitesses LAN ou SAN. Dans un cas, NetApp a participé à la migration à distance d'une base de données de 220 To avec des taux de génération de journaux d'archivage très élevés. L'approche choisie pour le transfert de données a été l'expédition quotidienne de bandes, parce que cette méthode offrait la bande passante maximale possible.

Dans de nombreux cas, le problème du déplacement d'une grande quantité de données n'est pas la taille des données, mais plutôt la complexité de la configuration qui prend en charge la base de données. Savoir qu'il faut migrer 50 To de bases de données n'est pas suffisant. Il peut s'agir d'une seule base de données stratégique de 50 To, d'un ensemble de 4 000 bases de données héritées ou d'un mélange de données de production et de données hors production. Dans certains cas, une grande partie des données est constituée de clones d'une base de données source. Il n'est pas nécessaire de migrer ces clones car ils peuvent être recréés facilement, notamment lorsque la nouvelle architecture est conçue pour exploiter les volumes NetApp FlexClone.

Pour la planification de la migration, vous devez connaître le nombre de bases de données concernées et leur priorité. À mesure que le nombre de bases de données augmente, l'option de migration privilégiée tend à être plus faible et plus faible dans la pile. Par exemple, la copie d'une seule base de données peut s'effectuer facilement avec RMAN et en cas de courte panne. Il s'agit de la réplication au niveau de l'hôte.

S'il existe 50 bases de données, il peut être plus facile d'éviter de configurer une nouvelle structure de système de fichiers pour recevoir une copie RMAN et de déplacer les données à la place. Ce processus peut être effectué en tirant parti de la migration LVM basée sur l'hôte pour déplacer les données des anciennes LUN vers les nouvelles LUN. L'équipe chargée de l'administration de la base de données (DBA) est alors détransférée vers l'équipe chargée du système d'exploitation pour que les données soient migrées de manière transparente par rapport à la base de données. La configuration du système de fichiers n'est pas modifiée.

Enfin, si 500 bases de données réparties sur 200 serveurs doivent être migrées, des options basées sur le stockage, telles que la fonctionnalité ONTAP Foreign LUN Import (FLI), peuvent être utilisées pour effectuer une migration directe des LUN.

En général, l'organisation d'un fichier de base de données doit être modifiée pour exploiter les fonctionnalités de la nouvelle baie de stockage. Toutefois, ce n'est pas toujours le cas. Par exemple, les fonctionnalités des baies 100 % Flash EF-Series se concentrent sur les performances SAN et la fiabilité SAN. Dans la plupart des cas, les bases de données peuvent être migrées vers une baie EF-Series sans tenir compte particulière de la disposition des données. Les seules exigences sont un nombre élevé d'IOPS, une faible latence et une fiabilité robuste. Bien que certaines pratiques d'excellence soient liées à des facteurs tels que la configuration RAID ou les pools de disques dynamiques, les projets EF-Series nécessitent rarement des modifications importantes de l'architecture de stockage globale pour exploiter ces fonctionnalités.

En revanche, la migration vers ONTAP nécessite généralement une plus grande considération de la disposition de la base de données pour s'assurer que la configuration finale offre une valeur maximale. À elle seule, ONTAP offre de nombreuses fonctionnalités pour un environnement de base de données, même sans effort d'architecture spécifique. Plus important encore, il permet de migrer vers un nouveau matériel sans interruption lorsque le matériel actuel arrive en fin de vie. De manière générale, une migration vers ONTAP est la dernière migration que vous auriez à effectuer. Ensuite, le matériel est mis à niveau et les données sont migrées sans interruption vers de nouveaux supports.

Avec une certaine planification, davantage d'avantages sont disponibles. Les considérations les plus importantes concernent l'utilisation des snapshots. Les copies Snapshot sont la base des sauvegardes, des restaurations et des opérations de clonage quasi-instantanées. Comme exemple de la puissance des snapshots, l'utilisation la plus répandue concerne une base de données unique de 996 To qui s'exécute sur environ 250 LUN sur 6 contrôleurs. Cette base de données peut être sauvegardée en 2 minutes, restaurée en 2 minutes et clonée en 15 minutes. Les autres avantages sont la capacité à déplacer les données au sein du cluster en réponse aux modifications des charges de travail et les contrôles de qualité de service (QoS) appliqués pour fournir de bonnes performances cohérentes dans un environnement à plusieurs bases de données.

Les technologies comme les contrôles de qualité de service, la relocalisation des données, la copie Snapshot et le clonage fonctionnent dans presque toutes les configurations. Cependant, certains pensent généralement être nécessaires pour maximiser les avantages. Dans certains cas, les dispositions du stockage de la base de données peuvent nécessiter des modifications de conception afin d'optimiser l'investissement dans la nouvelle baie de stockage. De telles modifications de conception peuvent avoir un impact sur la stratégie de migration, car les migrations basées sur les hôtes ou sur le stockage répliquent la disposition des données d'origine. Des étapes supplémentaires peuvent être nécessaires pour mener à bien la migration et assurer une disposition des données optimisée pour ONTAP. Les procédures indiquées à la "Présentation des procédures de migration Oracle" vous pouvez par la suite présenter certaines méthodes qui vous permettent non seulement de migrer une base de données, mais aussi de la migrer vers la configuration finale optimale en un minimum d'efforts.

Vous devez déterminer la durée maximale autorisée de l'interruption de service pendant la mise en service. C'est une erreur courante de supposer que l'ensemble du processus de migration provoque des perturbations. De nombreuses tâches peuvent être effectuées avant le début d'une interruption de service, et de nombreuses options permettent d'effectuer la migration sans interruption ni panne. Même si une interruption est inévitable, vous devez toujours définir le temps d'interruption de service maximal autorisé, car la durée de la mise en service varie d'une procédure à l'autre.

Par exemple, la copie d'une base de données de 10 To prend généralement environ sept heures. Si l'entreprise a besoin d'une interruption de service de sept heures, la copie de fichiers est une option simple et sûre pour la migration. Si cinq heures sont inacceptables, un simple processus d'envoi de journaux (voir "Envoi de journaux Oracle") peut être configuré en déployant un minimum d'efforts afin de réduire le délai de mise en service à environ 15 minutes. Pendant ce temps, un administrateur de base de données peut terminer le processus. Si 15 ce n'est pas le cas, le processus de mise en service final peut être automatisé par script afin de réduire le délai de mise en service à quelques minutes seulement. Vous pouvez toujours accélérer une migration, mais cette opération a un coût en temps et en efforts. Les délais de mise en service doivent être déterminés en fonction des objectifs acceptables pour l'entreprise.

Aucune migration n'est totalement sans risque. Même si la technologie fonctionne parfaitement, il y a toujours une possibilité d'erreur de l'utilisateur. Le risque associé au chemin de migration choisi doit être pris en compte parallèlement aux conséquences d'un échec de la migration. Par exemple, la fonctionnalité de migration transparente du stockage en ligne d'Oracle ASM est l'une de ses principales fonctionnalités, et cette méthode est l'une des plus fiables connues. Cependant, les données sont copiées de manière irréversible avec cette méthode. Dans le cas peu probable où un problème se produit avec ASM, il n'y a pas de chemin de sortie simple. La seule option consiste à restaurer l'environnement d'origine ou à utiliser ASM pour restaurer la migration vers les LUN d'origine. Le risque peut être réduit, mais pas éliminé, en effectuant une sauvegarde de type Snapshot sur le système de stockage d'origine, à condition que le système soit capable d'effectuer une telle opération.

Certaines procédures de migration doivent être entièrement vérifiées avant leur exécution. La nécessité d'une migration et d'une répétition du processus de mise en service est courante dans les bases de données stratégiques pour lesquelles la migration doit réussir et où les temps d'indisponibilité doivent être minimisés. En outre, les tests d'acceptation par l'utilisateur sont fréquemment inclus dans le travail de post-migration et le système global ne peut être remis en production qu'une fois ces tests terminés.

S'il est nécessaire de répéter, plusieurs fonctionnalités ONTAP peuvent faciliter le processus. En particulier, les snapshots peuvent réinitialiser un environnement de test et créer rapidement plusieurs copies compactes d'un environnement de base de données.