Migrer de l'architecture classique vers l'architecture de microservices à l'aide de l'utilitaire de migration

L'utilitaire de migration d'Oracle GoldenGate Classic vers les microservices permet de migrer d'une installation d'architecture Oracle GoldenGate Classic vers un déploiement de microservices. Cet utilitaire interactif migre les extractions et les réplications d'une installation d'architecture classique vers le déploiement de microservices et convertit les extractions de pompe en chemin de distribution. Il migre également les fichiers trace, les points de reprise et les autres artefacts associés.

L'utilitaire de migration est disponible sur le portail My Oracle Support (MOS) sous le nom de patch 37274898.

Les mises à jour du patch sont publiées si nécessaire. La description du patch inclut des détails avec le dernier numéro de build.

Prérequis pour l'utilisation de l'utilitaire de migration

Les prérequis pour utiliser l'utilitaire de migration sont les suivants :

Restrictions de l'utilitaire de migration

L'utilitaire de migration ne peut migrer aucun processus ayant les paramètres suivants :

Exécuter l'utilitaire de migration

Assurez-vous d'avoir terminé les étapes mentionnées dans Prérequis pour l'utilisation de l'utilitaire de migration avant de commencer les tâches de cette section.

Pour exécuter l'utilitaire de migration, procédez comme suit dans l'invite de commande :

  1. Exécutez la commande suivante pour démarrer l'utilitaire de migration :

    java -jar ogg-migration-package-23.4.0.0.0.jar -classicHome /scratch/ogg/home -dryrun
    java -jar ogg-migration-package-23.4.0.0.0.jar -debug
    java -jar ogg-migration-package-23.4.0.0.0.jar -help

    Les options disponibles avec cette commande sont les suivantes :

    • -classicHome path : (obligatoire) doit pointer vers l'emplacement du répertoire du logiciel Oracle GoldenGate Classic.

    • -dryrun : (facultatif) indique que la migration est simulée (exécution à sec) pour vérifier les éventuels problèmes.

    • -debug : facultatif, mais il est recommandé d'utiliser cette option avec l'utilitaire. Active la journalisation et les diagnostics au niveau du débogage. Il fournit des données de journal plus détaillées et génère un fichier zip avec des artefacts du classique et du MA en cas d'échec d'une migration.

    • -skipPumpURI : indique l'URI d'acceptation par défaut lors de la migration de la pompe.

    • -dbtype : indique le nom de la base de données. Les valeurs valides sont "ORACLE", "MYSQL", "MSSQL", "POSTGRESQL", "SYBASE", "DB2400", "DB2ZOS", "DB2LUW", "TERADATA", "TIMESTEN"

    • -help : affiche l'utilisation.

  2. L'utilitaire vous invite à saisir les informations d'identification de l'utilisateur pour le gestionnaire de services du déploiement MA :

    ***************************************************************************

**      Oracle GoldenGate Classic to Microservices Migration Utility              **

**        Version 23.4.0.0.0 Build 66 at Fri Jan 22 17:24:41 UTC 2024             **

**  Copyright (C) 1995, 2024, Oracle and/or its affiliates. All rights reserved.  **

**                                                                             **

**         Operating system character set identified as UTF-8.                    **

*******************************************************************************

Command Entered: -classicHome /ogg/payroll -debug
Log File for this session is /ogg/payroll/./Migration081321105419.log. Debug Mode is Enabled.
Enter Service Manager Credentials: User Id: dba
Password:

  3. L'utilitaire recherche un gestionnaire de services sur l'hôte et propose un choix de déploiements vers lesquels migrer s'il existe plusieurs déploiements, puis invite à continuer.

    Scanning for Microservices Deployments...
Using Deployment payroll [cf4c7c93-3a1c-4cbc-b1ab-bc942bab7645]
The following processes will be migrated to deployment payroll:
Extracts: EXTE
Replicats: REPW
Pumps: DPE
Do you wish to continue? (yes/no):>

    Saisissez yes pour continuer.

  4. L'utilitaire migre les informations d'identification de base de données du déploiement classique vers le déploiement de microservices cible, puis copie tous les fichiers trace du déploiement classique et migre tous les processus d'extraction et de réplication.

    Migrating Credentials from /ogg/payroll/./dircrd
Migrating Credentials for Domain Payroll with an alias of ogg.
Migrating Credentials for Domain Payroll with an alias of user.

Copying Trail Files from /ogg/payroll/dirdat to /ogg/Microservices/payroll/var/lib/data.
235 trail files copied.

Migrating EXTRACT EXTE to http://10.20.0.221:9901.
Checkpoint File(s) Copied and Converted Successfully.
Parameter File EXTE.prm Saved Successfully.
Migration of Extract EXTE Completed Successfully.

Migrating REPLICAT REPW to http://10.20.0.221:9901.
Parameter File REPW.prm Saved Successfully.
Checkpoint File(s) Copied and Converted Successfully.
Migration of Replicat REPW Completed Successfully.

  5. L'utilitaire migre ensuite tous les processus Extract Pump et invite à saisir l'URL du service destinataire cible pour chacun d'eux. Pour accepter la valeur par défaut, appuyez sur Entrée.

    Si vous utilisez une autre cible, entrez l'URL. Par défaut, l'utilitaire suppose que la pompe classique envoie un autre processus serveur de déploiement classique. L'URL par défaut permet au service de distribution d'établir un lien vers la cible classique. Si vous prévoyez également de migrer le déploiement Classic cible ultérieurement, vous devrez modifier le chemin de distribution nouvellement créé en même temps. Pour plus d'informations, reportez-vous à Différents cas d'utilisation pour la migration.

    Remarque : les pompes loopback sont courantes dans un environnement de test où une pompe classique envoie des données au même gestionnaire sur le même déploiement. Cette pompe loopback est automatiquement routée vers le service de destinataire sur le déploiement MA migré.

        Migrating PUMP PMPW2E to http://
10.20.0.221:9902.

    Use Default Pump Target URI of ogg://ushost1:9903/services/v2/targets?trail=./bb?
    Press Enter to Accept or type Alternate URI:>
    Creating Distribution Path for Pump PMPW2E.
    Distribution Path Created Successfully.
    Setting trail sequence to 235 with an RBA of 1319472691.

    Migration of Pump PMPW2E Completed Successfully.

    Migrating Manager tasks to http://10.20.0.221:9901.
    Creating Task for Parameter PurgeTrail-aa. Task Created Successfully.
    Creating Task for Parameter Purge-Extract. Task Created Successfully.
    2 Tasks were migrated, 2 Successfully, 0 with errors.

    Migrating Lag Report.
    Creating Task for Parameter LagReport. Task Created Successfully.
    Migration pf Manager Tasks Completed Successfully.

  6. Ensuite, l'utilitaire demande s'il doit migrer les paramètres dans le fichier de configuration GLOBALS et signaler tout problème rencontré.

    Do you wish to migrate your GLOBALS parameters? (yes/no):> y
GLOBAL parameters successfully migrated, 3 parameters merged.

  7. L'utilitaire vous invite à copier les entrées de portefeuille existantes si elles existent et émet un avertissement si des entrées existent sur le portefeuille cible. Ces entrées de portefeuille cible seront écrasées. Une fois cette tâche terminée, l'utilitaire s'interrompt.

    Your Classic Deployment has existing wallet entries.
Do you wish to copy them? (yes/no):> y

Copying Oracle Wallet Entries.

WARNING: Target deployment has existing wallet entries and will be overwritten!

Do you wish to continue? (yes/no):> y
Wallet entries successfully copied.

Migration Processing Complete, 3 processes were migrated successfully.

    Si la migration a réussi, elle renomme les fichiers de point de reprise dans le répertoire dirchk classique en ajoutant .migrated au nom. Les processus de déploiement Classic ne peuvent pas être démarrés par inadvertance.

    Si l'utilitaire rencontre un problème et ne parvient pas à terminer le processus de migration, il annule tout le travail qu'il a effectué et restaure le déploiement classique à son état d'origine. Il génère un fichier ZIP de diagnostic contenant le fichier journal classic configuration et target configuration pour faciliter le diagnostic du problème.

Différents cas d'utilisation pour la migration

Les déploiements de l'architecture Oracle GoldenGate Classic ne sont généralement pas autonomes. Les déploiements envoient généralement des données de trace à d'autres déploiements à l'aide du processus Pump qui ont des topologies interconnectées très complexes. Lorsqu'un déploiement est migré vers des microservices, il peut toujours envoyer des données de trace vers un autre déploiement classique ou de microservices. Une caractéristique majeure de l'architecture de microservices est la possibilité de sécuriser le déploiement à l'aide de protocoles de sécurité établis tels que TLS/SSL et de sockets Web sécurisés.

Lors de la migration des déploiements, une approche bien pensée doit être utilisée. En général, il est préférable que les déploiements source et cible soient migrés individuellement et pas tous en même temps. L'utilitaire de migration vous permet de migrer les déploiements un par un. Le déploiement source utilisant un protocole non sécurisé pour communiquer avec le serveur/collecteur classique ou le service de destinataire, le chemin de distribution migré utilisera le protocole ogg hérité dans le chemin. Bien que cela soit fonctionnel, il ne tire pas parti des capacités de sécurité de l'architecture de microservices pour créer un déploiement entièrement sécurisé.

Il est recommandé de remplacer le chemin de distribution généré par l'utilitaire de migration par un chemin utilisant les protocoles wss ou ws une fois que tous les déploiements ont été migrés vers l'architecture de microservices ou lorsque les déploiements source et cible ont été migrés.

Pour permettre la migration progressive des déploiements et des processus vers l'architecture de microservices, les déploiements d'architecture classique source et cible peuvent être migrés indépendamment.

La liste suivante répertorie différents cas d'utilisation et le protocole de distribution associé utilisés lors de la configuration du chemin de distribution.

Source Cible Protocole de distribution Description

Architecture du hub (pas de pistes de distribution)

Migrer la version classique vers les microservices

 Non applicable Non applicable Non applicable
Migrer la version classique vers les microservices Déploiement classique Protocole ogg pour cibler le déploiement classique -
Migrer la version classique vers les microservices Déploiement des microservices Protocole ogg Vous pouvez éventuellement supprimer et recréer DISTPATH pour utiliser le protocole ws ou wss (si la cible est sécurisée par un proxy inverse)
Déploiement classique Migrer la version classique vers les microservices Service destinataire de la pompe vers la cible

La pompe source doit être modifiée :

Port de service du récepteur et trace distante
Déploiement de microservices Migrer vers les microservices classiques Protocole ogg Supprimez et recréez DISTPATH et utilisez le protocole ws ou wss (si la cible est sécurisée par un proxy inverse)

Migration d'une source de la version classique vers des microservices avec Target en tant que microservices

Dans ce cas d'emploi, vous pouvez supprimer et recréer le chemin de distribution pour utiliser le protocole ws ou wss (si la cible est sécurisée par un proxy inverse) en indiquant le numéro de séquence (seqno) et les valeurs RBA. Cette option est facultative car le déploiement cible utilise l'architecture de microservices.

Exécutez le client Admin et connectez-vous au déploiement source pour obtenir les valeurs SEQNO et RBA :

OGG (http://north:9001)> INFO DISTPATH dpe, DETAIL
Path Name: dpe Status: running
Source: trail://north:9002/services/v2/sources?trail=ea
Target: ogg://south:9003/services/v2/targets?trail=ra
Authentication Method: USERIDALIAS ggsca domain OracleGoldenGate
[...]
Checkpoints:
Input Checkpoint:
  Current:
     Name: ea
     Sequence: 14
     Offset: 2579
     Path: /u01/ogg_deployments/depl_north/var/lib/data/
[...]

Convertissez le chemin de distribution en protocole ws ou wss en recréant et en repositionnant le chemin de distribution créé par l'utilitaire de migration :

OGG (http://south:9001)> DELETE DISTPATH dpe, DETAIL

## If using Secure Web Socket Protocol (wss)
OGG (http://south:9001)> ADD DISTPATH dpm
                         SOURCE trail://src_host:9002/services/v2/sources?trail=ea
                         TARGET wss://trg_host:9003/services/v2/targets?trail=ra
                         AUTHENTICATION CERTIFICATE default
## If using Web Socket Protocol (ws)
OGG (http://south:9001)> ADD DISTPATH dpm
                         SOURCE trail://src_host:9002/services/v2/sources?trail=ea
                         TARGET ws://trg_host:9003/services/v2/targets?trail=ra
                         AUTHENTICATION USERIDALIAS ggsca DOMAIN OracleGoldenGate
OGG (http://south:9001)> ALTER DISTPATH dpm, BEGIN SEQNO 14, RBA 2579
OGG (http://south:9001)> START DISTPATH dpm

Migrer la cible de l'environnement classique vers des microservices dont la source est Microservices

Dans ce cas d'emploi, il est obligatoire de supprimer et de recréer le chemin de distribution pour utiliser le protocole ws ou wss, si la cible est sécurisée par un proxy inverse. Suivez les étapes décrites dans Migration d'une source classique vers des microservices avec la cible en tant que microservices pour supprimer et recréer le chemin de distribution sur le déploiement cible.

Migration de la cible de l'environnement classique vers des microservices avec la source en tant qu'environnement classique

Lorsque vous migrez le déploiement cible vers l'architecture de microservices alors que le déploiement source est dans l'architecture classique, vous devez effectuer les étapes supplémentaires suivantes :

Comme indiqué dans l'exemple suivant, le numéro de port du gestionnaire cible a été remplacé par le numéro de port du service de destinataire 9903 et le chemin d'accès au fichier RMTTRAIL a été modifié dans le fichier de paramètres Extract Pump.

GGSCI> STOP EXTRACT PMPW2E
GGSCI> EDIT PARAMS PMPW2E

Le fichier de paramètres Extract Pump est le suivant :

EXTRACT PMPW2E
USERIDALIAS ggeast,
target uri: host1:9903/services/v2/targets?trail=./bb? ENCRYPT AES192,
RMTTRAIL ./rt SEQUENCE hr.employees_seq; TABLE hr.*;

Redémarrez Extract Pump après avoir terminé les modifications :

GGSCI> START EXTRACT PMPW2E

Remarque : aucun fichier trace n'est transmis à la cible.

Avant le début de la migration, arrêtez progressivement tous les processus à la source.