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.
Répliquez des bases de données mainframe sur AWS à l'aide de Precisely Connect
Créée par Lucio Pereira (AWS), Balaji Mohan (AWS) et Sayantan Giri (AWS)
Récapitulatif
Ce modèle décrit les étapes à suivre pour répliquer les données des bases de données mainframe vers les magasins de données Amazon en temps quasi réel à l'aide de Precisely Connect. Il met en œuvre une architecture basée sur les événements avec Amazon Managed Streaming for Apache Kafka (Amazon MSK) et des connecteurs de base de données personnalisés dans le cloud afin d'améliorer l'évolutivité, la résilience et les performances.
Precisely Connect est un outil de réplication qui capture les données des systèmes mainframe existants et les intègre dans des environnements cloud. Les données sont répliquées des mainframes vers AWS par le biais de la capture des données de modification (CDC) en utilisant des flux de messages en temps quasi réel avec des pipelines de données hétérogènes à faible latence et à haut débit.
Ce modèle couvre également une stratégie de reprise après sinistre pour des pipelines de données résilients avec réplication des données multirégions et routage sur incident.
Conditions préalables et limitations
Prérequis
Une base de données mainframe existante, par exemple IBM DB2, IBM Information Management System (IMS) ou Virtual Storage Access Method (VSAM), que vous souhaitez répliquer dans le cloud AWS
Un compte AWS
actif AWS Direct Connect
ou réseau privé virtuel AWS (AWS VPN ) entre votre environnement d'entreprise et AWS Un cloud privé virtuel
doté d'un sous-réseau accessible par votre ancienne plateforme
Architecture
Pile technologique source
Un environnement mainframe qui inclut au moins l'une des bases de données suivantes :
Base de données IBM IMS
Base de DB2 données IBM
fichiers VSAM
Pile technologique cible
Amazon MSK
Amazon Elastic Kubernetes Service (Amazon EKS) et Amazon EKS Anywhere
Docker
Une base de données relationnelle ou NoSQL AWS telle que la suivante :
Amazon DynamoDB
Amazon Relational Database Service (Amazon RDS) pour Oracle, Amazon RDS pour PostgreSQL ou Amazon Aurora
Amazon ElastiCache pour Redis
Amazon Keyspaces (pour Apache Cassandra)
Architecture cible
Réplication des données du mainframe vers des bases de données AWS
Le schéma suivant illustre la réplication des données du mainframe vers une base de données AWS telle que DynamoDB, Amazon RDS, Amazon ou Amazon Keyspaces ElastiCache. La réplication s'effectue en temps quasi réel à l'aide de Precisely Capture et Publisher dans votre environnement mainframe sur site, de Precisely Dispatcher sur Amazon EKS Anywhere dans votre environnement distribué sur site, et de Precisely Apply Engine et des connecteurs de base de données dans le cloud AWS.

Le schéma suivant illustre le flux de travail suivant :
Precisely Capture extrait les données du mainframe à partir des journaux du CDC et les conserve dans un stockage transitoire interne.
Precisely Publisher écoute les modifications apportées au stockage interne des données et envoie les enregistrements CDC à Precisely Dispatcher via une connexion TCP/IP.
Precisely Dispatcher reçoit les enregistrements CDC de Publisher et les envoie à Amazon MSK. Dispatcher crée des clés Kafka en fonction de la configuration utilisateur et de plusieurs tâches de travail pour envoyer des données en parallèle. Dispatcher envoie un accusé de réception à Publisher lorsque les enregistrements ont été stockés dans Amazon MSK.
Amazon MSK détient les dossiers du CDC dans l'environnement cloud. La taille de partition des sujets dépend des exigences de débit de votre système de traitement des transactions (TPS). La clé Kafka est obligatoire pour toute transformation ultérieure et pour la commande de transactions.
Le moteur Precisely Apply écoute les enregistrements CDC d'Amazon MSK et transforme les données (par exemple, par filtrage ou mappage) en fonction des exigences de la base de données cible. Vous pouvez ajouter une logique personnalisée aux scripts Precisely SQD. (SQD est le langage propriétaire de Precisely.) Le moteur Precisely Apply transforme chaque enregistrement CDC au format Apache Avro ou JSON et le distribue à différents sujets en fonction de vos besoins.
Les rubriques Kafka cibles contiennent des enregistrements CDC dans plusieurs rubriques en fonction de la base de données cible, et Kafka facilite l'ordre des transactions en fonction de la clé Kafka définie. Les clés de partition s'alignent sur les partitions correspondantes pour permettre un processus séquentiel.
Les connecteurs de base de données (applications Java personnalisées) écoutent les enregistrements CDC d'Amazon MSK et les stockent dans la base de données cible.
Vous pouvez sélectionner une base de données cible en fonction de vos besoins. Ce modèle prend en charge à la fois les bases de données NoSQL et relationnelles.
Reprise après sinistre
La continuité des activités est essentielle au succès de votre entreprise. Le cloud AWS fournit des fonctionnalités de haute disponibilité (HA) et de reprise après sinistre (DR), et prend en charge les plans de reprise et de secours de votre organisation. Ce modèle suit une stratégie de reprise après sinistre active/passive et fournit des conseils de haut niveau pour la mise en œuvre d'une stratégie de reprise après sinistre qui répond à vos exigences en matière de RTO et de RPO.
Le schéma suivant illustre le flux de travail DR.

Le diagramme décrit les éléments suivants :
Un basculement semi-automatique est nécessaire en cas de panne dans la région 1 d'AWS. En cas de panne dans la région 1, le système doit initier les modifications de routage pour connecter Precisely Dispatcher à la région 2.
Amazon MSK réplique les données par le biais de la mise en miroir entre les régions. C'est pourquoi, lors du basculement, le cluster Amazon MSK de la région 2 doit être promu en tant que principal leader.
Le moteur Precisely Apply et les connecteurs de base de données sont des applications sans état qui peuvent fonctionner dans n'importe quelle région.
La synchronisation des bases de données dépend de la base de données cible. Par exemple, DynamoDB peut utiliser des tables globales ElastiCache et des banques de données globales.
Traitement à faible latence et haut débit via des connecteurs de base de données
Les connecteurs de base de données sont des composants essentiels de ce modèle. Les connecteurs suivent une approche basée sur les écouteurs pour collecter les données d'Amazon MSK et envoyer des transactions à la base de données via un traitement à haut débit et à faible latence pour les applications critiques (niveaux 0 et 1). Le schéma suivant illustre ce processus.

Ce modèle permet le développement d'une application personnalisée consommant un seul thread grâce à un moteur de traitement multithread.
Le thread principal du connecteur consomme les enregistrements CDC d'Amazon MSK et les envoie au pool de threads pour traitement.
Les threads du pool de threads traitent les enregistrements CDC et les envoient à la base de données cible.
Si tous les threads sont occupés, les enregistrements CDC sont conservés par la file d'attente des threads.
Le thread principal attend que tous les enregistrements soient effacés de la file d'attente des threads et valide les offsets dans Amazon MSK.
Les threads enfants gèrent les défaillances. En cas d'échec pendant le traitement, les messages d'échec sont envoyés à la rubrique DLQ (file d'attente de lettres mortes).
Les threads enfants initient les mises à jour conditionnelles (voir Expressions de condition dans la documentation DynamoDB), en fonction de l'horodatage du mainframe, afin d'éviter toute duplication ou mise à jour dans la base de données. out-of-order
Pour plus d'informations sur la mise en œuvre d'une application client Kafka dotée de fonctionnalités multithreading, consultez le billet de blog intitulé Multi-Threaded Message Consumption with the Apache Kafka Consumer sur le
Outils
Services AWS
Amazon Managed Streaming for Apache Kafka (Amazon MSK) est un service entièrement géré qui vous permet de créer et d'exécuter des applications utilisant Apache Kafka pour traiter les données de streaming.
Amazon Elastic Kubernetes Service (Amazon EKS) vous aide à exécuter Kubernetes sur AWS sans avoir à installer ou à gérer votre propre plan de contrôle ou vos propres nœuds Kubernetes.
Amazon EKS Anywhere
vous aide à déployer, utiliser et gérer des clusters Kubernetes exécutés dans vos propres centres de données. Amazon DynamoDB est un service de base de données NoSQL entièrement géré, offrant des performances rapides, prévisibles et évolutives.
Amazon Relational Database Service (Amazon RDS) vous aide à configurer, exploiter et dimensionner une base de données relationnelle dans le cloud AWS.
Amazon vous ElastiCache aide à configurer, à gérer et à faire évoluer des environnements de cache en mémoire distribués dans le cloud AWS.
Amazon Keyspaces (pour Apache Cassandra) est un service de base de données géré qui vous aide à migrer, exécuter et dimensionner vos charges de travail Cassandra dans le cloud AWS.
Autres outils
Precisely Connect
intègre les données des systèmes mainframe existants tels que les ensembles de données VSAM ou les bases de données mainframe IBM dans des plateformes cloud et de données de nouvelle génération.
Bonnes pratiques
Trouvez la meilleure combinaison de partitions Kafka et de connecteurs multithread pour trouver le meilleur équilibre entre performances et coûts. Plusieurs instances de Precisely Capture et Dispatcher peuvent augmenter les coûts en raison de la consommation plus élevée de MIPS (millions d'instructions par seconde).
Évitez d'ajouter une logique de manipulation et de transformation des données aux connecteurs de base de données. Pour ce faire, utilisez le moteur Precisely Apply, qui fournit les temps de traitement en microsecondes.
Créez des appels périodiques de demande ou de vérification de l'état de la base de données (pulsations cardiaques) dans les connecteurs de base de données afin de réchauffer fréquemment la connexion et de réduire le temps de latence.
Implémentez une logique de validation du pool de threads pour comprendre les tâches en attente dans la file d'attente des threads et attendez que tous les threads soient terminés avant le prochain sondage Kafka. Cela permet d'éviter la perte de données en cas de panne d'un nœud, d'un conteneur ou d'un processus.
Exposez les mesures de latence via les points de terminaison de santé afin d'améliorer les capacités d'observabilité grâce à des tableaux de bord et à des mécanismes de suivi.
Épopées
Tâche | Description | Compétences requises |
---|---|---|
Configurez le processus du mainframe (batch ou utilitaire en ligne) pour démarrer le processus CDC à partir des bases de données du mainframe. |
| Ingénieur mainframe |
Activez les flux de journaux de la base de données mainframe. |
| Spécialiste des bases de données mainframe |
Utilisez le composant Capture pour capturer les enregistrements CDC. |
| Ingénieur mainframe, Precisely Connect SME |
Configurez le composant Publisher pour écouter le composant Capture. |
| Ingénieur mainframe, Precisely Connect SME |
Provisionnez Amazon EKS Anywhere dans l'environnement distribué sur site. |
| DevOps ingénieur |
Déployez et configurez le composant Dispatcher dans l'environnement distribué pour publier les rubriques dans le cloud AWS. |
| DevOps ingénieur, Precisely Connect PME |
Tâche | Description | Compétences requises |
---|---|---|
Provisionnez un cluster Amazon EKS dans la région AWS désignée. |
| DevOps ingénieur, administrateur réseau |
Provisionnez un cluster MSK et configurez les rubriques Kafka applicables. |
| DevOps ingénieur, administrateur réseau |
Configurez le composant Apply Engine pour écouter les sujets Kafka répliqués. |
| Precisely Connect PME |
Provisionnez des instances de base de données dans le cloud AWS. |
| Ingénieur de données, DevOps ingénieur |
Configurez et déployez des connecteurs de base de données pour écouter les rubriques publiées par le moteur Apply. |
| Développeur d'applications, Architecte cloud, Ingénieur de données |
Tâche | Description | Compétences requises |
---|---|---|
Définissez des objectifs de reprise après sinistre pour vos applications professionnelles. |
| Architecte cloud, ingénieur des données, propriétaire de l'application |
Concevez des stratégies de reprise après sinistre basées sur un RTO/RPO défini. |
| Architecte cloud, ingénieur de données |
Provisionnez des clusters et des configurations de reprise après sinistre. |
| DevOps ingénieur, administrateur réseau, architecte cloud |
Testez le pipeline du CDC pour la reprise après sinistre. |
| Propriétaire de l'application, ingénieur de données, architecte cloud |
Ressources connexes
Ressources AWS
Ressources Precisely Connect
Ressources de Confluent