Ce document décrit les bonnes pratiques à adopter pour une migration homogène de Db2 vers Compute Engine. Il est destiné aux administrateurs de base de données, aux administrateurs système et aux ingénieurs logiciels, bases de données et opérations, chargés de la migration des environnements Db2 vers Google Cloud. Les migrations de Db2 vers d'autres types de bases de données sortent du cadre de ce document.
Terminologie
- IBM Db2
- Système de gestion de base de données relationnelle (SGBDR) pour entreprises, doté de fonctionnalités de réplication et de basculement.
- Haute disponibilité et reprise après sinistre (HADR, High Availability Disaster Recovery)
- Fonction de Db2 qui exploite les activités journalisées de la base de données pour répliquer les données de la base de données principale vers la base de données de secours. Cette fonctionnalité permet un basculement manuel de la base de données principale vers la base de données de secours.
- Machine principale
- Machine hébergeant Db2 qui accepte les requêtes d'écriture et de lecture. Cette machine est la source de la réplication sur les machines de secours.
- Machine principale de secours
- Machine de secours qui n'accepte que les requêtes de lecture. Cette machine est compatible avec tous les modes de synchronisation autorisés par Db2 et sert d'instance de restauration automatique pour la fonction HADR. IBM Db2 n'autorise qu'une seule de ces machines dans un cluster.
- Machine de secours auxiliaire
- Machine de secours qui n'accepte que les requêtes de lecture. Cette machine n'est compatible qu'avec le mode de synchronisation SUPERASYNC. Elle réside dans un centre de données différent de celui de la machine principale en cas de basculement manuel à la suite d'une défaillance du centre de données principal.
- TSAMP (Tivoli System Automation for Multiplatforms)
- Logiciel de gestion de cluster qui facilite le basculement automatique des ressources de la base de données principale vers la machine de secours principale. Ce logiciel inclut des ressources réseau, de stockage et de calcul définies dans le cadre du cluster. L'édition Db2 Enterprise est fournie avec les droits TSAMP pour HADR.
- Réacheminement automatique du client (ACR, Automatic Client Reroute)
- Fonctionnalité de Db2 qui redirige les applications clientes d'un serveur défaillant vers un autre serveur afin que les applications puissent continuer à fonctionner avec une interruption minimale.
- Capture de données modifiées (CDC, Change Data Capture)
- Ensemble de techniques ou d'outils permettant de détecter les modifications effectuées dans une base de données, telles que la synchronisation avec une autre base de données ou la création d'une piste d'audit.
Architecture
Un cluster Db2 se compose généralement d'au moins un nœud principal et d'un nœud principal de secours, séparés par une configuration HADR. Dans les versions plus récentes de Db2, vous pouvez également ajouter des nœuds de secours auxiliaires à des fins de reprise après sinistre.
Le diagramme suivant illustre un environnement source.
Dans cet environnement, les machines principales et les machines de secours principales se trouvent dans un centre de données, et les machines de secours auxiliaires dans des centres de données différents.
Un objectif de migration consiste à recréer cet environnement sur Google Cloud, comme indiqué dans le diagramme suivant.
Vous trouverez un comparatif des aspects de chaque type de migration dans le tableau ci-dessous.
| Migrate to Virtual Machines | Réplication Q | Réplication SQL | HADR | |
|---|---|---|---|---|
| Sources | VMware, VM AWS (Amazon Web Services) | Tout environnement Db2, basée sur les licences | Tout environnement Db2 | Tout environnement Db2 |
| Quels sont les éléments répliqués ? | Réplication de disques au niveau du bloc | Tables de la base de données | Tables de la base de données | Base de données complète |
| Basculement | Quelques minutes peuvent être nécessaires pour qu'une VM se lance dans Google Cloud | Faire pointer les applications et le DNS vers les instances Compute Engine | Faire pointer les applications et le DNS vers les instances cloud | Faire pointer les applications et le DNS vers les instances cloud |
| Réplication de modification LDD | Oui (écritures sur disque en cours de réplication) | Oui | Oui | Oui |
| Réplication synchrone des données | N/A | Non | Oui | Oui |
| Réplication asynchrone des données | N/A | Oui | Oui | Oui |
| Réplication des données à un moment précis | Non | Oui | Oui | Non |
Le tableau ci-dessus vous aide à définir les exigences en matière de disponibilité et de ressources nécessaires pour configurer le système cible et la réplication, ainsi que gérer et tester la réplication au fil du temps. Le tableau montre que Migrate to VMs est l'approche la plus simple à mettre en œuvre, mais la moins flexible en termes de disponibilité du système. À l'inverse, l'option HADR, la réplication Q et la réplication SQL ont moins d'impact sur la disponibilité du système, mais demandent des efforts supplémentaires pour configurer et gérer la réplication dans un modèle parallèle.
Types de migration
Il existe deux manières de migrer Db2 vers Compute Engine :
- À l'aide de migrations impliquant de modifier une topologie ou une configuration de cluster existante
- À l'aide de migrations répliquant les données dans de nouveaux clusters
La modification d'un cluster existant ne nécessite pas de lancer un tout nouveau cluster dans le cloud. Ainsi, cette méthode peut se révéler plus rapide. L'autre méthode de migration nécessite de déployer un nouveau cluster sur Google Cloud. L'impact sur le cluster existant est moindre, car la réplication est hors bande. Cette méthode est également utile si vous souhaitez ne répliquer qu'une partie de la base de données ou effectuer des modifications sur les données avant qu'elles ne se retrouvent dans la cible.
Les sections suivantes décrivent les éléments à prendre en compte avant de migrer vos instances Db2 vers Google Cloud. Certaines fonctionnalités couramment utilisées peuvent ne pas fonctionner telles quelles sur Google Cloud ou nécessiter des modifications de configuration.
Adresses IP flottantes (virtuelles)
Dans un cluster Db2 hautement disponible, TSAMP peut attribuer une adresse IP virtuelle au nœud principal. Également appelée adresse IP flottante, cette adresse signifie que le trafic est toujours acheminé vers le nœud principal, et non vers la machine de secours.
Compute Engine utilise une pile réseau virtualisée dans un réseau VPC (Virtual Private Cloud). Par conséquent, il y a un risque que les mécanismes de mise en œuvre classiques ne fonctionnent pas. Par exemple, le réseau VPC traite les requêtes ARP (Address Resolution Protocol) en fonction de la topologie de routage configurée et ignore les trames ARP gratuites. De plus, il est impossible de modifier directement la table de routage réseau VPC avec des protocoles de routage standards tels qu'OSPF (Open Shortest Path First Protocol) ou BGP (Border Gateway Protocol). Par conséquent, vous devez mettre en œuvre une alternative aux adresses IP flottantes ou utiliser ACR.
Si vous migrez tout ou partie des nœuds d'un cluster Db2, veillez à désactiver les adresses IP flottantes avant d'effectuer cette opération.
ACR
Si votre environnement Db2 utilise ACR, vous devrez peut-être modifier le catalogue de vos clients si les noms DNS changent ou si vos clients se connectent à l'aide d'adresses IP.
Conditions de départage
TSAMP exige que la majorité des nœuds du cluster soient en ligne pour lancer des actions d'automatisation. Si le cluster est composé d'un nombre pair de nœuds, il est possible que la moitié des nœuds du cluster soient en ligne et qu'il existe un scénario split-brain. Dans ce cas, TSAMP utilise une condition de départage pour décider de l'état du quorum (groupe majoritaire), qui détermine si les actions d'automatisation peuvent être démarrées.
Voici les conditions de départage compatibles avec votre environnement Db2 :
- Condition de départage réseau ou sur disque. IBM Db2 utilise des réservations de disque afin d'effectuer le départage. Comme les réservations ne sont pas disponibles sur Google Cloud, vous devez choisir un autre type de condition de départage.
- Condition de départage réseau. Utilise une adresse IP externe (au cluster) pour résoudre une situation d'égalité. Dans un déploiement hybride, la condition de départage réseau n'aura peut-être pas besoin d'être initialement déployée vers Google Cloud tant qu'elle restera accessible depuis les nœuds du cluster. Une fois votre cluster exécuté sur Google Cloud, il est toutefois conseillé de créer la condition de départage dans une zone différente ou d'utiliser le serveur de métadonnées Google Cloud en tant que condition de départage.
- Condition de départage NFS. La condition de départage NFS résout les situations d'égalité basées sur des fichiers réservés, stockés sur un serveur NFS v4. Comme avec la condition de départage réseau, la condition de départage NFS et le serveur NFS v4 peuvent également rester à leur emplacement d'origine dans un déploiement hybride. Ultérieurement, il sera préférable de déployer votre propre serveur NFS ou de faire appel à des partenaires tels qu'Elastifile en tant que cibles de départage NFS sur Google Cloud.
Migrer à l'aide de Migrate to VMs
Si les deux conditions suivantes s'appliquent à votre environnement, nous vous recommandons d'utiliser Migrate to VMs :
Vous disposez d'un environnement VMware vCenter ou de machines virtuelles sur Amazon Elastic Compute Cloud (Amazon EC2).
Vous disposez d'une connexion privée entre Google Cloud et votre environnement telle que Cloud VPN ou Cloud Interconnect.
Migrate to VMs permet de migrer des machines virtuelles depuis des environnements sur site et cloud vers Google Cloud. Cette solution vous permet de migrer une machine virtuelle vers Google Cloud en quelques minutes. Les données sont copiées en arrière-plan, mais les machines virtuelles sont complètement opérationnelles. Vous devez disposer d'une connexion privée entre votre environnement source et votre projet Google Cloud, telle que Cloud VPN, Cloud Interconnect ou une interconnexion partenaire.
Avec Migrate to VMs, vous devez réévaluer la configuration de la base de données sur les VM cloud. Certaines configurations peuvent ne pas être optimisées pour Google Cloud, comme les variables de registre, les pools de mise en mémoire tampon, la configuration du gestionnaire de bases de données ou la configuration de bases de données.
Vous pouvez faire appel à l'utilitaire AUTOCONFIGURE pour commencer avec une configuration de référence.
La méthodologie opérationnelle de migration vers VM est décrite dans le cycle de vie de migration des VM.
Les sections suivantes décrivent comment appliquer cette méthodologie à un environnement Db2.
Clones de test
Les clones de test ne sont disponibles que sur les environnements vCenter.
Migrate to VMs peut prendre un instantané de votre VM et créer en conséquence une instance de calcul prête à l'emploi sur Google Cloud. Vous pouvez recréer votre environnement Db2 sur Google Cloud, essayer des modifications de configuration, et tester et évaluer le déploiement, sans aucune conséquence pour votre environnement source.
Le diagramme suivant illustre votre environnement Db2 sur Google Cloud avec l'environnement côte à côte sur Google Cloud après un clonage de test Migrate to VMs.
Après avoir comparé et testé les clones de test sur Google Cloud, vous pouvez les supprimer.
Run-in-cloud
Lorsque vous démarrez une opération run-in-cloud, Migrate pour to VMs arrête votre cluster source et démarre les VM sur Google Cloud, tout en n'extrayant que les données nécessaires et en ne diffusant pas l'intégralité de l'espace de stockage dans Google Cloud. L'opération run-in-cloud est compatible avec l'écriture différée et il est activé par défaut. La migration to VMs vous permet de tester votre environnement avant de diffuser activement le stockage. Vous pouvez également replacer la VM dans votre environnement source à l'aide de la fonctionnalité de retour. Lors de la migration d'une solution cloud à une autre, vous ne pouvez pas répliquer de nouveau les écritures vers la source.
Le diagramme suivant illustre la phase run-in-cloud, si vous configurez tous vos nœuds pour qu'ils s'exécutent dans le cloud. Vous pouvez également migrer progressivement les nœuds du cluster au lieu du cluster tout entier.
Migration
La phase de migration est semblable à la phase run-in-cloud, mais la Migrate to VMs diffuse également de manière active l'espace de stockage dans Google Cloud. Pendant la phase run-in-cloud, la Migrate to VMs ne génère des données à la demande que dans le but d'économiser de la bande passante, car vous n'avez pas indiqué être prêt à migrer entièrement la VM.
Dissocier
Durant cette phase, Migrate for VMs synchronise les données de son cache et de son magasin d'objets avec les disques de données natifs sur Google Cloud, puis associe les disques à la VM. Cette phase nécessite d'arrêter la VM sur Google Cloud. Pour Db2, nous vous recommandons de dissocier un nœud du cluster à la fois.
Utiliser la réplication
Pour l'environnement Db2, la réplication consiste à détecter les modifications à partir du journal des transactions à l'aide d'un programme dit de capture ("Capture"), puis à les appliquer à un autre cluster à l'aide du programme dit d'application ("Apply"). La manière dont le programme de capture détecte les modifications et le type de canal de communication utilisé pour transmettre les modifications au programme d'application diffèrent selon les types de réplication.
Le diagramme suivant illustre le flux logique d'informations dans la réplication Db2.
Le programme de capture détecte les modifications de la base de données et les envoie au programme d'application. Celui-ci écrit ces modifications dans la base de données cible. Les programmes peuvent eux-mêmes effectuer certaines transformations sur les données. Ils ne doivent pas nécessairement s'exécuter sur le serveur de base de données lui-même.
Réplication SQL
Une réplication SQL détecte les modifications apportées aux tables et vues sources, et stocke les données transactionnelles validées dans des tables de transfert. Les modifications sont ensuite lues dans les tables de transfert et répliquées dans les tables cibles correspondantes. Au moment où nous rédigeons ce document, lorsque vous installez Db2, la réplication SQL est disponible.
Un processus de migration à l'aide de la réplication SQL se présenterait sous la forme suivante :
- Déployez Db2 sur Google Cloud.
- Configurez la réplication SQL.
- Démarrez la réplication SQL.
- Vérifiez que les déploiements sont synchronisés.
- Faites pointer vos applications vers l'instance Google Cloud. Arrêtez la réplication.
Le diagramme suivant montre un exemple de réplication SQL.
Votre environnement de production fonctionne normalement lors de la réplication des commandes SQL sur le nouveau cluster que vous créez sur Google Cloud. Dans le diagramme précédent, le processus de réplication s'exécute sur l'instance principale. Toutefois, il existe différentes manières de le déployer qui ne sont pas couvertes dans ce document.
Réplication Q
La réplication Q est une méthode plus récente et plus efficace que la réplication SQL pour répliquer les données d'une instance Db2 vers une autre. Cette méthode utilise IBM MQ pour fournir les entrées de modifications de données, ce qui signifie que vous devez déployer une instance d'IBM MQ dans l'environnement source et l'environnement cible. Cette méthode de réplication est plus rapide que la réplication SQL, car elle est en mémoire. La réplication SQL est plus lente, mais la réplication Q est généralement plus difficile à mettre en œuvre, car vous devez également configurer IBM MQ. En fonction de votre licence Db2, vous devrez peut-être acquérir une licence pour la réplication Q.
Lorsque vous démarrez la réplication Q de Db2, vous avez le choix entre les deux méthodes suivantes :
Chargement automatique. Les processus de réplication Q effectuent le chargement initial, ce qui signifie qu'ils effectuent la restauration de la base de données cible à partir d'une sauvegarde de la source.
Chargement manuel. Vous effectuez le chargement initial, puis démarrez la réplication à partir d'un certain point dans le journal.
Le processus de migration peut se présenter comme suit :
- Déployez IBM MQ sur Google Cloud et dans votre environnement source.
- Déployez Db2 sur Google Cloud.
- Configurez la réplication Q.
- Démarrez la réplication Q (chargement manuel ou chargement automatique).
- Vérifiez que les deux déploiements sont synchronisés.
- Faites pointer vos applications vers l'instance Google Cloud. Arrêtez la réplication.
Le diagramme suivant montre une solution de réplication Q possible.
L'environnement source utilise la réplication Q IBM pour envoyer les modifications de la base de données à IBM MQ et à l'environnement cible, ce qui étend le cluster Db2 vers Compute Engine.
Dans cette approche, vous migrez progressivement votre cluster Db2 existant vers Compute Engine et utilisez HADR pour le transfert de données entre les nœuds.
Suivez cette approche lorsque les conditions suivantes s'appliquent :
- Vous ne souhaitez pas déployer de nouveau cluster sur Compute Engine.
- Vous ne pouvez pas exploiter Migrate to VMs.
- Vous ne pouvez pas utiliser l'une des options de réplication.
- Vous n'utilisez pas ou ne pouvez pas utiliser de produit partenaire (licences, coûts ou conformité, pour ne citer que quelques raisons).
Si votre version de Db2 n'est pas compatible avec l'instance de secours auxiliaire
Vous pouvez procéder comme suit :
- Déployez une instance Db2 sur Compute Engine.
- Effectuez une sauvegarde de votre instance principale.
- Restaurez l'instance Db2 sur Compute Engine à partir de la sauvegarde.
- Supprimez l'instance de secours de la configuration HADR.
- Associez l'instance Db2 Compute Engine en tant qu'instance de secours. Vous pouvez choisir le mode de synchronisation. Toutefois, en raison d'une latence plus élevée, il est recommandé d'utiliser
ASYNCouNEARASYNC. - Basculez sur l'instance Db2 Compute Engine et faites-en l'instance principale HADR.
- Créez une autre instance Db2 Compute Engine, restaurez-la à partir d'une sauvegarde et configurez-la en tant qu'instance de secours HADR.
La première étape du diagramme suivant montre l'instance Db2 récemment créée sur Google Cloud, configurée en tant qu'instance de secours principale de l'instance source principale Db2.
Dans le diagramme précédent, l'instance Google Cloud devient l'instance principale HADR. Vous supprimez ensuite l'instance de secours principale source et vous associez une autre instance Db2 à Compute Engine en tant qu'instance de secours principale.
Si votre version de Db2 est compatible avec l'instance de secours auxiliaire
Une option consiste à suivre la même procédure que lorsque la version 2 de DB2 n'est pas compatible avec l'instance de secours auxiliaire sauf qu'à la fin, vous migrez également les instances de secours auxiliaires.
Une autre option consiste à utiliser les instances dupliquées auxiliaires pour une migration vers Google Cloud plus tolérante aux pannes, car vous ne disposez pas de l'instance principale ni de l'instance de secours principale dans votre environnement source, ni de l'autre instance sur Google Cloud. La liste suivante décrit les étapes associées à cette seconde option :
- Déployez des instances Db2 sur Compute Engine (instance principale ou instances auxiliaires, si nécessaire) vers leurs emplacements.
- Supprimez les nœuds de secours auxiliaires du cluster source.
- Configurez les nœuds qui deviendront les nœuds principaux des instances de secours auxiliaires du cluster source.
- Effectuez une opération de reprise de l'une des instances Compute Engine. Cette instance devient l'instance principale. Configurez l'une des autres instances Compute Engine comme instance de secours principale de l'instance principale.
La première étape décrite dans le diagramme suivant montre deux des instances Db2 récemment créées sur Compute Engine.
Les instances sont configurées en tant qu'instances de secours auxiliaires de l'instance principale source Db2 à la place des instances auxiliaires de l'environnement source. Ensuite, après avoir appelé la reprise pour l'une des instances de Compute Engine, cette instance devient l'instance principale HADR, et une autre instance est configurée en tant qu'instance de secours principale. Lors de la dernière étape, deux autres instances sont configurées en tant qu'instances de secours auxiliaires.
Produits partenaires
Google est associé à plusieurs partenaires qui offrent des produits facilitant une telle migration. La plupart de ces produits s'appuient sur un flux CDC pour répliquer les données entre la source Db2 et la cible. Il ne s'agit pas de produits Google Cloud. Vous devez vérifier les licences et les prix de chaque produit ou service. En règle générale, ce service réplique les données d'un cluster existant vers un autre cluster que vous créez sur Google Cloud. L'approche globale est semblable aux scénarios de réplication décrits dans ce document.
Voici quelques produits partenaires :
Étapes suivantes
- Consultez le guide de planification IBM Db2 pour SAP.
- Découvrez le centre de migration de bases de données Google Cloud.
- Découvrez des architectures de référence, des schémas et des bonnes pratiques concernant Google Cloud. Consultez notre Centre d'architecture cloud.