Utilisation d' InfoSphere CDC dans des environnements résilients

Accessibilité d' InfoSphere CDC (IP virtuelle)

Dans un cluster à haute disponibilité, l'adresse IP virtuelle est une ressource partagée. Une adresse IP virtuelle (VIP) est une adresse qui n'est pas associée à un ordinateur spécifique ou à une carte d'interface réseau sur un ordinateur. Les paquets entrants sont transmis à l'adresse VIP, mais sont ensuite acheminés vers les interfaces réseau réelles.

InfoSphere CDC est généralement déployé de manière active ou passive, la réplication n'étant active que sur un seul nœud à la fois. L'adresse IP virtuelle est attribuée au nœud InfoSphere CDC et est ensuite utilisée dans d'autres instances et dans la console de gestion. Lorsque InfoSphere CDC bascule sur un autre nœud, les utilisateurs externes ne doivent voir aucun changement et toutes les connexions peuvent être rétablies sur la même IP et le même port virtuels.

La partie gauche de la figure 1 montre la console de gestion se connectant au magasin de données par l'intermédiaire de l'adresse IP (virtuelle) 192.168.21.68, qui est acheminée vers l'adresse physique 192.168.21.45 (nœud A). En outre, les paquets de données provenant d'abonnements ciblant ce stockage de données sont transmis à l'adresse IP physique. Lorsque le nœud A tombe en panne, le trafic vers l'adresse IP virtuelle est transféré vers l'adresse IP réelle du nœud B, 192.168.21.56 (partie droite de la figure 1).

Fichiers binaires et métadonnées InfoSphere CDC pour le moteur Linux, UNIX et Windows

La signature relie les métadonnées de configuration et les informations opérationnelles, qui ne peuvent être séparées. Lorsque l'instance est formée, sa signature est établie. Vous ne pouvez pas créer une nouvelle instance avec le même emplacement d'informations opérationnelles sans invalider l'instance précédente.

InfoSphere CDC sur un volume partagé

Pour mettre en œuvre cette topologie pour les moteurs Linux, UNIX et Windows, tous les nœuds de la grappe doivent avoir accès au même volume. En général, le volume partagé est fourni par un réseau de stockage (SAN) ou un système de stockage en réseau. Dans certaines configurations, le volume de disque n'est monté et accessible que par le nœud actif. La topologie la plus simple pour la mise en œuvre et la maintenance consiste à utiliser un lecteur partagé pour stocker l'installation du CDC.

Le volume partagé stocke les fichiers binaires InfoSphere CDC, les métadonnées de configuration, les métadonnées de sécurité et les métadonnées opérationnelles (le cas échéant), et toutes les modifications de configuration ou de sécurité effectuées sur le nœud actif sont enregistrées de manière centralisée et disponibles au moment du basculement. Les informations d'exploitation d' InfoSphere CDC sont stockées de manière centralisée dans la base de données, pour laquelle un clustering doit être mis en place, ou dans un volume partagé et mis à disposition lors d'un basculement. Tous les fichiers de la structure du répertoire CDC doivent appartenir au même identifiant d'utilisateur sur tous les nœuds du cluster et au même identifiant de groupe s'ils sont installés sur UNIX ou Linux. Comme il n'existe qu'une seule copie des métadonnées de configuration, tous les nœuds exécutant cette instance d' InfoSphere CDC doivent partager la base de données, les services, les paramètres de connexion à la base de données et les emplacements des journaux de la base de données. La topologie d'une installation avec point de montage partagé est illustrée à la figure 2.

* Le diagramme montre un déploiement de CDC avec les informations opérationnelles stockées dans la base de données. D'autres types de déploiement peuvent avoir des métadonnées opérationnelles CDC qui sont stockées sur le volume partagé.

Installation et configuration

1. Installez InfoSphere CDC sur le nœud actif. Le répertoire d'accueil du produit ( $CDC_HOME ) doit se trouver sur un volume partagé.
2. Créez une instance InfoSphere CDC sur le nœud actif. Les métadonnées de configuration sont créées dans le système de fichiers sous le répertoire d'origine du produit et les métadonnées opérationnelles dans la base de données ou dans le même système de fichiers, le cas échéant. Les métadonnées de sécurité sont stockées dans le même système de fichiers.
3. Démarrer une instance InfoSphere CDC sur le nœud actif.
4. Configurer les abonnements et les tables de correspondance.

Reprise en ligne

Si un basculement est prévu, suivez les étapes suivantes :

1. Exécutez la commande suivante pour arrêter la réplication pour tous les abonnés :

   dmendreplication

   Si cette instance InfoSphere CDC est définie comme cible, la réplication à partir de la source doit être arrêtée.
2. Exécutez la commande suivante pour arrêter l'instance InfoSphere CDC :

   dmshutdown

Une fois que le volume partagé est disponible sur le nœud de basculement :

• Exécutez la commande suivante pour démarrer l'instance CDC :

  dmts64

• Exécutez la commande suivante pour effacer le staging store de l'instance :

  dmclearstagingstore

• Exécutez la commande suivante pour redémarrer les abonnements :

  dmstartmirror

  Si cette instance InfoSphere CDC est une cible, la réplication doit être lancée à partir de la source.

InfoSphere CDC sur des nœuds séparés avec une base de données partagée

Dans cette topologie pour le moteur Linux, UNIX et Windows (voir figure 3), InfoSphere CDC est installé sur chaque nœud du cluster et il n'y a pas de volume partagé disponible pour contenir l'installation CDC. La base de données attachée est mise en cluster en utilisant un volume partagé. Bien qu'elle soit simple à mettre en œuvre, elle nécessite des étapes supplémentaires de maintenance et de basculement.

* Le diagramme montre un déploiement de CDC avec les informations opérationnelles stockées dans la base de données. D'autres types de déploiement peuvent avoir des métadonnées opérationnelles CDC qui sont stockées sur le volume partagé.

Les fichiers binaires et les métadonnées d' InfoSphere CDC sont stockés séparément sur les deux nœuds, de sorte que toute modification apportée à la configuration doit être synchronisée entre le nœud principal et le nœud de secours. Lors de l'installation sous UNIX et Linux, tous les fichiers du répertoire d'accueil du CDC et de son arborescence doivent avoir le même identifiant d'utilisateur et le même identifiant de groupe. Ce paramètre garantit qu'en cas de défaillance du nœud de secours, l'utilisateur qui exécute l'instance peut lire et mettre à jour la configuration.

En raison de la signature entre les informations opérationnelles et la configuration, il n'est pas possible de démarrer une instance CDC sur le nœud de secours et d'annuler les modifications. Par conséquent, les métadonnées de configuration du nœud principal doivent être sauvegardées régulièrement et restaurées sur le nœud de secours. Les métadonnées de configuration peuvent être synchronisées aussi souvent que nécessaire. Au minimum, vous devez effectuer cette activité après les modifications de configuration (tables mappées, abonnements et paramètres système) et après l'actualisation initiale des tables mappées et l'activation de l'état de la table. Il est conseillé de copier régulièrement les métadonnées de configuration et de sécurité. Lorsque les métadonnées opérationnelles sont stockées sur un système de fichiers, il est important de synchroniser aussi souvent que possible les données primaires et les données de sauvegarde.

Comme les métadonnées de configuration sont répliquées et que les métadonnées opérationnelles sont les mêmes que dans la topologie précédente, tous les nœuds exécutant cette instance d' InfoSphere CDC doivent partager la base de données, les services, les paramètres de connexion à la base de données et les emplacements des journaux de la base de données.

Installation et configuration

1. Installez InfoSphere CDC sur tous les nœuds. Conservez la même adresse $CDC_HOME sur tous les serveurs.
2. Sur le nœud actif, créez une instance InfoSphere CDC. Selon le moteur CDC, les métadonnées du produit sont créées dans le répertoire d'origine du produit et dans la base de données ou le système de fichiers.
3. Copiez le répertoire $CDC_HOME/instance sur le serveur de sauvegarde. Ne créez pas d'instance sur le nœud passif car cela invalide l'instance sur le nœud actif.
4. Copiez le répertoire complet de $CDC_HOME/keystore sur le serveur de sauvegarde.
5. Démarrer l'instance InfoSphere CDC du nœud actif.
6. Configurer les abonnements et les tables de correspondance.
7. Copier périodiquement les métadonnées du système de fichiers et les journaux d'événements du nœud actif vers le nœud passif. Les métadonnées sont stockées dans le fichier $CDC_HOME/instance//conf/md*. Utilisez la commande dmbackupmd pour sauvegarder des fichiers dans le répertoire $CDC_HOME/instance//backup/bnn. Pour conserver l'historique des journaux lorsque l'instance devient active sur le deuxième nœud, la base de données des événements doit également être répliquée. Les événements sont enregistrés dans le fichier $CDC_HOME/instance//events/*. Copier les informations de sécurité de la version principale vers la version de sauvegarde en copiant les fichiers sous $CDC_HOME/keystore.

Reprise en ligne

Si un basculement est prévu, suivez les étapes suivantes :

1. Exécutez la commande suivante pour arrêter la réplication pour tous les abonnés :

   dmendreplication

   Si cette instance InfoSphere CDC est définie comme cible, la réplication à partir de la source doit être arrêtée.
2. Exécutez la commande suivante pour arrêter l'instance InfoSphere CDC :

   dmshutdown

Après l'arrêt ou l'échec de l'instance InfoSphere CDC sur le nœud actif et la disponibilité de l'IP virtuelle sur le nœud passif :

• Restaurer les métadonnées et les événements récents du système de fichiers.
• Exécutez la commande suivante pour démarrer l'instance :

  dmts64

• Exécutez la commande suivante pour effacer le staging store de l'instance :

  dmclearstagingstore

• Exécutez la commande suivante pour redémarrer les abonnements :

  dmstartmirror

  Si cette instance InfoSphere CDC est une cible, la réplication doit être lancée à partir de la source.

InfoSphere CDC sur des serveurs séparés avec des bases de données séparées

Dans cette topologie pour les moteurs Linux, UNIX et Windows, il y a deux instances de base de données distinctes. Qui utilise une technologie telle que Db2 High Availability Disaster Recovery (HADR) ou Oracle Data Guard pour maintenir une base de données de sauvegarde (standby) synchronisée avec la base de données principale.

Lorsque la solution de haute disponibilité est mise en œuvre sur la source CDC, les numéros de séquence des entrées de journal (LSN pour Db2 et SCN pour Oracle ) sont les mêmes sur la base de données primaire et la base de données de sauvegarde. La base de données de sauvegarde est généralement en mode veille ou n'est ouverte qu'en lecture (reporting).

Si la cible du CDC est une base de données qui utilise une solution de haute disponibilité, la synchronisation des numéros de séquence des entrées de journal n'est pas pertinente. Toutefois, dans ce cas, la joignabilité du serveur est essentielle. Une adresse IP virtuelle n'est pas attribuée puisque les bases de données primaire et de secours sont séparées par des segments de réseau.

En raison de leurs signatures, les métadonnées de configuration et d'exploitation d' InfoSphere CDC sont stockées séparément et par paires. Cette architecture doit être utilisée si une adresse IP virtuelle ne peut pas être attribuée.

Les fichiers binaires InfoSphere CDC et les métadonnées de configuration sont stockés séparément sur les deux serveurs, de sorte que toute modification de la configuration doit être synchronisée entre le serveur principal et le serveur de secours. Lors d'une installation sous UNIX ou Linux, tous les fichiers du répertoire d'accueil d' InfoSphere CDC et de son arborescence doivent avoir le même identifiant d'utilisateur et de groupe. Cette disposition garantit que la personne qui exploite l'instance sur le nœud de secours peut lire et mettre à jour la configuration lors du basculement. La topologie du CDC sur des serveurs séparés avec des bases de données séparées est présentée dans la figure 4.

* Le diagramme montre un déploiement de CDC avec les informations opérationnelles stockées dans la base de données. D'autres types de déploiement peuvent avoir des métadonnées opérationnelles CDC qui sont stockées sur le volume partagé.

Sauvegarder et restaurer régulièrement les métadonnées de configuration du nœud principal vers le nœud de secours. Les métadonnées de configuration peuvent être synchronisées fréquemment. Cependant, vous devez effectuer cette procédure au moins une fois après les changements de configuration tels que les tables mappées, les abonnements et les paramètres du système. De même, après avoir exécuté le rafraîchissement initial des tables mappées et changé le statut de la table en actif.

Installation et configuration

1. Installez InfoSphere CDC sur tous les nœuds. Conservez la même adresse $CDC_HOME sur tous les serveurs.
2. Sur le nœud actif, créez une instance InfoSphere CDC. Les métadonnées du produit sont créées à la fois dans le répertoire d'origine du produit et dans la base de données.
3. Copiez le répertoire $CDC_HOME/instance sur le serveur de sauvegarde.
4. Copiez le répertoire complet de $CDC_HOME/keystore sur le serveur de sauvegarde.
5. Démarrez l'instance InfoSphere CDC sur le serveur actif.
6. Configurer les abonnements et les tables de correspondance.
7. Copier périodiquement les métadonnées du système de fichiers et les journaux d'événements du nœud actif vers le nœud passif. Les métadonnées sont stockées dans le fichier $CDC_HOME/instance//conf/md*. Utilisez la commande dmbackupmd pour sauvegarder des fichiers dans le répertoire $CDC_HOME/instance//backup/bnn. Pour conserver l'historique des journaux lorsque l'instance devient active sur le deuxième nœud, la base de données des événements doit également être répliquée. Les événements sont enregistrés dans le fichier $CDC_HOME/instance//events/*. Copier les informations de sécurité de la version principale vers la version de sauvegarde en copiant les fichiers sous $CDC_HOME/keystore.

Basculement lorsque le serveur est la source d' InfoSphere CDC

Si un basculement est prévu, suivez les étapes suivantes :

1. Exécutez la commande suivante pour arrêter la réplication pour tous les abonnés :

   dmendreplication

   Si cette instance InfoSphere CDC est définie comme cible, la réplication à partir de la source doit être arrêtée.
2. Exécutez la commande suivante pour arrêter l'instance InfoSphere CDC :

   dmshutdown

3. Effectuez les étapes suivantes sur le serveur de sauvegarde après que l'instance InfoSphere CDC du serveur primaire a été arrêtée ou a échoué et que la base de données du serveur de sauvegarde est active :
   1. Restaurer les métadonnées et les événements récents du système de fichiers.
   2. Exécutez la commande suivante pour démarrer l'instance :

      dmts64

   3. Exécutez la commande suivante pour effacer le staging store de l'instance :

      dmclearstagingstore

   4. Exécutez la commande suivante pour redémarrer les abonnements :

      dmstartmirror

Basculement lorsque le serveur est la cible du CDC

Si un basculement est prévu, suivez les étapes suivantes :

1. Exécutez la commande suivante pour arrêter la réplication pour tous les abonnés sur le serveur source :

   dmendreplication

2. Exécutez la commande suivante pour arrêter l'instance InfoSphere CDC :

   dmshutdown

3. Effectuez les étapes suivantes sur le serveur de sauvegarde après que l'instance InfoSphere CDC du serveur primaire a été arrêtée ou a échoué et que la base de données du serveur de sauvegarde est active :
   1. Restaurer les métadonnées et les événements récents du système de fichiers.
   2. Exécutez la commande suivante pour démarrer l'instance :

      dmts64

      Pour rediriger les abonnements vers le serveur de sauvegarde, procédez comme suit :

      1. Modifier l'adresse IP ou le nom d'hôte du magasin de données cible à partir du gestionnaire d'accès.
      2. Connectez-vous au magasin de données cible via la vue de configuration de la console de gestion.
      3. Pour accéder à l'onglet Alias, cliquez avec le bouton droit de la souris sur le magasin de données connecté et sélectionnez Propriétés dans le menu contextuel.
      4. Ajoutez l'adresse IP ou le nom d'hôte du serveur de sauvegarde aux alias.
      5. Accédez aux propriétés de chaque abonnement et sélectionnez le bouton Détails en regard du magasin de données cible. Vous pouvez sélectionner l'adresse IP ou le nom d'hôte du serveur de sauvegarde comme nouvelle destination de l'abonnement.

Basculement d' InfoSphere CDC après le DR de la base de données via l'exportation/importation d'abonnements

Système i environnements résilients

Il existe plusieurs possibilités de résilience pour InfoSphere CDC lorsqu'un serveur IBM System i (anciennement connu sous le nom d' AS/400 et IBM eServer™ iSeries® ) est inclus dans le paysage de réplication. Il existe deux méthodes pour assurer la résilience dans un environnement System i : l'une est similaire aux solutions de regroupement disponibles sur d'autres plateformes, l'autre utilise des solutions de haute disponibilité basées sur des logiciels. Cette section explique comment les deux méthodes s'appliquent au basculement de la configuration d' InfoSphere CDC.

Résilience grâce à des pools de stockage auxiliaires indépendants

Les pools de stockage auxiliaires indépendants (IASP) sont une méthode prise en charge par le système i pour stocker les données et les applications d'entreprise en dehors du stockage principal du serveur. Les IASP sont adaptés à l'utilisation de SAN et de systèmes de réplication sur disque pour assurer la résilience des données et des applications. Les IASP peuvent être déconnectés d'un serveur et attachés à un serveur de secours, ce qui permet au serveur de secours d'assumer les tâches de production. La figure 5 présente un exemple d'IASP pouvant se connecter à des serveurs locaux.

Lorsqu'il utilise une solution de mise en miroir sur disque, un IASP peut disposer d'une sauvegarde physique distincte du site de production principal. En cas de défaillance du serveur principal ou de sinistre sur le site, le serveur de secours peut reprendre les tâches de production. Une IASP en miroir est illustrée à la figure 6.

Un IASP ne peut se connecter qu'à un seul serveur système i à la fois. En outre, lorsque la mise en miroir des disques est utilisée pour la synchronisation avec un site de sauvegarde, l'IASP de sauvegarde ne peut pas être connectée au serveur de sauvegarde tant que la synchronisation n'est pas arrêtée.

Utilisation d' InfoSphere CDC dans un environnement IASP

InfoSphere CDC peut être installé dans des environnements compatibles IASP. Le produit contient plusieurs éléments qui doivent être conservés en mémoire interne ( *SYSBAS ASP ), notamment un profil d'utilisateur ( D_MIRROR ), la description du sous-système et une file d'attente.

Lors de l'installation d' InfoSphere CDC dans un environnement résilient, l'installation doit être effectuée sur le serveur actif qui est connecté à l'IASP. Lors de l'installation, vous devez indiquer le nom de l'IASP et de la bibliothèque du produit ; cette bibliothèque contient l'ensemble du produit, y compris les tables de configuration, et est stockée sur l'IASP. La procédure d'installation génère automatiquement une autre bibliothèque sur *SYSBAS ASP appelée bibliothèque de travail (le nom est constitué des huit premières lettres du nom de la bibliothèque du produit, qui est combiné avec 01). La bibliothèque de travail stocke tous les objets qui ne peuvent pas être stockés sur l'IASP.

Après avoir installé InfoSphere CDC sur le système actif, vous devez installer la bibliothèque de travail sur le système inactif. L'installation de la bibliothèque de travail crée la bibliothèque et les objets qui ne peuvent pas être stockés sur l'IASP et qui sont utilisés lorsque le CDC est nécessaire sur le serveur de sauvegarde.

Si vous modifiez le profil utilisateur D_MIRROR ou les éléments de la bibliothèque de travail InfoSphere CDC, vous devez également mettre à jour le serveur inactif. L'ASP du système stocke les entrées de la table de service qui spécifient le port sur lequel le produit écoute. L'entrée de la table de service doit être disponible sur le serveur de secours, sinon l'auditeur ne démarre pas correctement lorsque le sous-système est démarré. Les configurations, telles que les tables mappées et les abonnements, sont stockées dans l'ensemble de la bibliothèque de produits sur l'IASP et partagées (ou mises en miroir) entre le serveur principal et le serveur de secours.

Si InfoSphere CDC tombe en panne ou bascule dans un environnement IASP, vous devez arrêter la réplication de l'abonnement depuis ou vers le serveur principal System i avant de redémarrer le sous-système dans la bibliothèque de travail CDC. Cette étape active le programme d'écoute TCP /IP. Une fois activée, la réplication peut se poursuivre sans perte ni duplication de données.

Outre la bibliothèque InfoSphere CDC, l'IASP doit contenir les tables à partir desquelles ou vers lesquelles la copie est effectuée. De plus, si vous répliquez à partir de tables basées sur l'IASP, le journal et les récepteurs de journal doivent se trouver sur le même support de stockage. Cette action doit faire partie de votre démarche de rétablissement.

Utilisation d' InfoSphere CDC avec des solutions de haute disponibilité basées sur des logiciels

Les utilisateurs qui utilisent les serveurs du système i ont recours à des solutions logicielles de haute disponibilité pour assurer la reprise après sinistre. IBM iCluster® for i est un exemple de solution de haute disponibilité basée sur un logiciel.

Les solutions HA basées sur des logiciels fonctionnent en lisant les écritures de journal générées par l'application de production et en les appliquant aux tables cibles. Ces tables cibles (de sauvegarde) sont également journalisées et génèrent donc des écritures comparables à celles du côté production. La journalisation sur le serveur de secours peut être différente de celle du serveur principal (mais ce n'est généralement pas le cas). Les récepteurs de journaux qui contiennent les entrées du journal de table du serveur de secours peuvent (et c'est très probable) être nommés différemment des récepteurs de journaux du serveur principal. La journalisation sur le serveur de sauvegarde peut être désactivée alors qu'aucune activité de production n'a lieu.

Si InfoSphere CDC utilise le serveur de production System i comme source, les processus de maintenance et de basculement des journaux deviennent plus difficiles. Cette section explique les facteurs à prendre en compte lors de la mise en œuvre d' InfoSphere CDC dans un tel environnement.

Dans le cadre d'une mise en œuvre logicielle de l'AH, deux éléments principaux doivent être pris en compte :

• Commutation et basculement d' InfoSphere CDC
• Gestion du journal (purge des récepteurs de journaux obsolètes)

Ces considérations ne s'appliquent que lorsque le serveur du système i sert de source pour InfoSphere CDC. En optant pour cette plate-forme de serveur, il est plus facile de passer d'une plate-forme à l'autre et les problèmes de gestion du journal sont éliminés.

Commutation et basculement

En termes de haute disponibilité, le basculement se produit lorsque le contrôle est transféré à un serveur de secours dans le cadre d'une opération planifiée. Avant de relancer l'activité de production, vous pouvez arrêter les applications sur le serveur principal et entreprendre des actions préparatoires sur le serveur de secours, par exemple lors d'une migration vers un nouveau serveur. Un basculement se produit lorsque le serveur primaire devient inaccessible en raison d'un événement imprévu, tel qu'une panne de courant ou une tragédie sur le site.

En cas de basculement, les étapes préliminaires suivantes doivent être effectuées sur le serveur primaire :

1. Arrêter toutes les activités de l'application métier afin que les écritures ne soient plus générées.
2. Arrêtez les abonnements à InfoSphere CDC.
3. Redémarrer les abonnements avec une fin programmée (net change mirroring) pour s'assurer que toutes les transactions sont dupliquées sur le serveur cible.
4. Optionnellement, arrêter le sous-système.

Une fois ces processus terminés, vous devez prendre des mesures préparatoires sur le système de sauvegarde avant de reprendre l'activité de l'application métier :

1. Démarrez le sous-système InfoSphere CDC mais ne créez pas d'abonnements.
2. Utilisez SETJRNPOS pour ajouter un signet à n'importe quelle entrée du récepteur de journal actuel.
3. Marquer les points de capture des tables pour toutes les tables dans les abonnements ; cette action marque le point auquel les modifications sont répliquées à nouveau.
4. Les applications professionnelles peuvent être redémarrées.
5. Les abonnements peuvent être créés à tout moment. Les transactions générées après le marquage des points de capture de la table sont répliquées sur le serveur cible.

Lors d'un basculement, il se peut que vous ne puissiez pas déterminer exactement quand les transactions des journaux du serveur primaire ont été répliquées sur le serveur cible. Les sections suivantes examinent les problèmes rencontrés lors d'un basculement et la manière de les résoudre afin que la réplication puisse redémarrer sans perte de données.

Revues et récepteurs de revues

Sur les serveurs System i, les signets d'abonnement d' InfoSphere CDC sont identifiés par :

• Le nom de la revue et la bibliothèque
• Le récepteur de revues et la bibliothèque
• Le numéro de séquence de l'écriture au journal dans le récepteur

Les tables (fichiers physiques) du serveur primaire (de production) sont journalisées et chaque journal est associé à un ou plusieurs récepteurs, qui enregistrent les transactions de la base de données dans le récepteur actuellement connecté. Si les tables sont également journalisées sur le serveur de secours (ce qui est facultatif mais recommandé pour faciliter le basculement), le journal associé doit porter le même nom et se trouver dans la même bibliothèque que celui du serveur de production.

Les récepteurs de journaux suivants peuvent être associés au journal de production :

• RCV0578
• RCV0579
• RCV0580

Sur le serveur de sauvegarde, le journal équivalent est probablement associé à d'autres récepteurs de journaux, tels que RCV1593 et RCV1594. Les récepteurs de journaux du serveur de secours sont nommés et commutés indépendamment de ceux du serveur principal. La probabilité que les destinataires d'un journal partagent leur nom est faible et ne peut être imposée.

La figure 7 présente un exemple de scénario de mise en œuvre d' InfoSphere CDC coexistant avec une solution HA logicielle.

Signet et basculement

Dans la figure 7, une entrée de journal 110 dans le récepteur RCV0580 peut correspondre à un élément de journal 81524 dans le récepteur RCV1594 sur le serveur de secours. Lorsque InfoSphere CDC applique l'écriture du journal du serveur primaire à la base de données cible, le signet créé est RCV0580-110.

Si la production est transférée du serveur principal au serveur de secours et que l'abonnement est relancé à partir du serveur de secours, les informations du signet ne sont plus valables. Il est très probable que l'entrée de journal identifiée par le signet n'existe pas dans le journal du serveur de sauvegarde. Par conséquent, l'abonnement ne démarre pas.

Avant de lancer les abonnements sur le serveur de sauvegarde, le signet (position du journal) doit être réinitialisé. En effet, le serveur source peut ne plus être disponible et les informations relatives aux signets stockées dans la base de données ciblée par l'abonnement ne peuvent pas être précisément liées à une entrée de journal sur le serveur de secours. Utiliser une approche qui reproduit toutes les entrées. Il est impossible d'empêcher que certaines opérations sur les tables soient répliquées plusieurs fois, et des violations de clés primaires sont possibles lors de l'application d'entrées aux tables cibles. Si la réplication vise des tables sans clé unique, telles que des tables d'audit ou des applications, DataStage ou un fournisseur JMS, plusieurs entrées sont envoyées. Qui doit être résolu plus tard.

Une stratégie courante pour définir la position du journal après un basculement consiste à conserver un horodatage pour chaque abonnement dans la base de données ou l'application ciblée. Une table technique est établie sur le serveur System i source, avec une clé (fictive) et une colonne d'horodatage. Chaque abonnement comprend la table technique, qui renvoie à une table cible contenant la dernière modification apportée à la table source. Sur le serveur source, une application simple est programmée pour s'exécuter et mettre à jour la ligne de la table source avec la date et l'heure actuelles du système.

Cette stratégie crée une table dans la base de données cible contenant la date et l'heure de la dernière entrée appliquée. Cette date et cette heure peuvent ensuite être utilisées pour localiser l'élément de journal dans le journal du serveur de sauvegarde et créer un signet à l'aide de la commande SETJRNPOS.

Supposons que la solution de haute disponibilité soit à jour et qu'elle ait transféré toutes les modifications des serveurs primaires vers les serveurs de secours. Pour vérifier si aucune modification n'est ignorée pour la réplication, placez le signet sur une entrée de journal qui se situe quelques minutes avant l'heure enregistrée. Ce paramètre s'applique lorsque les horaires du système des serveurs primaire et de secours ne sont pas synchronisés. Les éléments du serveur de sauvegarde ont un horodatage antérieur à celui des entrées équivalentes sur le serveur principal.

Si les tables cibles ont des clés primaires, vous pouvez éviter que l'abonnement ne s'arrête avec une erreur de clé dupliquée ou d'enregistrement manquant en sélectionnant l'une des options suivantes :

• Activez la détection de conflit pour les tables répliquées et spécifiez source wins. Si une insertion ne peut pas être appliquée à la cible, elle est transformée en mise à jour. Lorsqu'une ligne inexistante est mise à jour, elle est insérée. Lorsqu'une ligne inexistante est supprimée, elle est ignorée. En outre, les conflits sont enregistrés dans un tableau d'audit des conflits en vue d'un examen ultérieur.
• Utilisez le type de mappage Adaptive Apply pour remapper les tables. Cette action produit le même résultat que l'activation de la détection de conflit, mais elle n'enregistre pas les conflits.
• Indiquer au moteur cible InfoSphere CDC de continuer en mode erreur pendant la mise en miroir. Cette fonction peut être configurée par le biais d'un paramètre du système. Le nom des paramètres du système varie selon le type de moteur ; pour les moteurs Linux, UNIX et Windows. Définissez mirror_end_on_error=false.

Les modifications de configuration ne peuvent être utilisées que pour prolonger l'abonnement au-delà du moment où la source et la cible sont à nouveau synchronisées. Si l'une des trois alternatives a un impact négatif sur le débit de l'application, il est important de revenir aux paramètres d'origine dès que possible.

Gestion du journal

En cas de basculement, le journal du serveur de secours doit inclure toutes les entrées qui n'ont pas été répliquées sur le serveur cible de l'abonnement. Les récepteurs de journaux ne doivent être supprimés du serveur de sauvegarde que s'ils ne contiennent pas de données devant être répliquées dans un commutateur.

Mettez en œuvre une stratégie de nettoyage simple qui conserve plusieurs récepteurs de journaux sur le serveur de secours pendant une journée, afin de vous assurer que les entrées de journaux sont disponibles au moment du basculement.

Si l'espace disponible sur le serveur de secours est insuffisant, vous devez associer les positions de journaux (signets) des abonnements à un récepteur de journaux de secours. RTVDMJENT récupère le plus ancien récepteur de journal encore requis par l'un des abonnements ; il doit être exécuté sur le serveur principal. Vous pouvez obtenir l'horodatage de la première entrée du journal en utilisant le récepteur de journal renvoyé. L'horodatage peut être utilisé pour localiser le plus ancien récepteur de journal encore nécessaire sur le serveur de sauvegarde. Si cette méthode est répétée lors de la création du signet après le basculement, il faut déduire quelques minutes de l'horodatage.

Portée de la mise en miroir pour une solution de haute disponibilité

Outre la gestion des récepteurs de journaux et des signets, il faut envisager de configurer la solution de haute disponibilité. Une copie entièrement fonctionnelle de l'installation d' InfoSphere CDC doit être disponible sur le serveur de sauvegarde pour être utilisée lorsque le contrôle lui est donné. En même temps, les verrous d'objets peuvent empêcher la mise en miroir (sauvegarde ou restauration) de tous les objets de la bibliothèque de produits.

Tableau 1. Mise en miroir des objets de l'étendue

Bibliothèque	Objet	Type d'objet	Inclusion ou exclusion	Commentaires
Bibliothèque de produits InfoSphere CDC	*ALL	*ALL	Inclure	Non disponible
Bibliothèque de produits InfoSphere CDC	*ALL	*USRQ	Exclure	Ces objets sont exclusivement verrouillés lorsque des abonnements sont en cours.
QSYS	D_MIRROR	*USRPRF	Inclure	InfoSphere CDC Profil de l'utilisateur.

Les objets spécifiés dans le tableau 1 doivent être inclus dans l'étendue de la mise en miroir de la solution de haute disponibilité.

Initialement, tous les éléments de la bibliothèque de produits InfoSphere CDC doivent être sauvegardés sur le serveur principal et restaurés sur le serveur de sauvegarde. Certains éléments, tels que les espaces utilisateurs de communication, doivent exister sur la cible. Arrêtez tous les abonnements et sous-systèmes avant de synchroniser la bibliothèque de produits InfoSphere CDC avec le serveur de sauvegarde.

z/OS Sysplex et InfoSphere CDC dans des environnements résilients

La résilience est définie comme la capacité à récupérer et à redémarrer la réplication en cas de défaillance de l'un des principaux composants de la source ou de la cible.

La figure 8 présente l'architecture complète. Les composants figurant dans les cases pleines sont en cours d'utilisation, tandis que les composants figurant dans les cases en pointillés deviennent actifs en cas de défaillance des composants actuels. En général, chaque composant peut résider sur une machine différente. Tout composant actif peut tomber en panne, ce qui nécessite le basculement d'une machine de secours.

Un basculement nécessite les actions suivantes :

• Assurez-vous que les métadonnées de configuration et d'exploitation de la machine en panne correspondent aux métadonnées requises pour poursuivre la réplication. Cette action consiste notamment à s'assurer que les positions de redémarrage du journal de la base de données sont correctement définies.
• Rétablir la communication.
• Assurez-vous que le logiciel fonctionne sur la machine de basculement.
• Redémarrer la réplication dans le nouvel environnement de basculement.

Travailler dans un environnement de partage de données DB2 z/OS peut contribuer à améliorer la résilience d' InfoSphere CDC z/OS. L'espace d'adressage InfoSphere CDC z/OS doit être exécuté sur une instance z/OS correspondant à un membre du groupe de partage des données. Si cette instance z/OS tombe en panne ou si le membre DB2 n'est pas opérationnel, InfoSphere CDC z/OS peut être redémarré sur une autre instance z/OS qui contient un membre du groupe de partage des données. Comme les données sont partagées, l'instance de basculement d' InfoSphere CDC z/OS utilise les mêmes métadonnées (y compris les métadonnées opérationnelles) que l'instance défaillante, de sorte que la principale considération en matière de basculement est la connectivité.

Pour préparer InfoSphere CDC z/OS au redémarrage sur un autre membre, effectuez les tâches suivantes :

• Le paramètre SSID du sous-système DB2 dans le membre de configuration CHCDBMxx doit être le nom d'attachement du groupe et non l'ID du sous-système d'un seul membre.
• Le magasin de données Nom d'hôte, tel que spécifié dans la console de gestion, doit être résolu en une adresse IP virtuelle avant de définir des abonnements.
• La configuration IP/ TCP /IP de la machine source /IP de l' InfoSphere CDC z/OS doit être définie pour utiliser la même adresse IP virtuelle que la cible InfoSphere CDC spécifiée dans la console de gestion.
• Lors du basculement, l'adresse IP virtuelle de la console de gestion utilisée pour se connecter au moteur source ou cible doit pointer vers les nouvelles instances z/OS utilisant l'espace d'adressage InfoSphere CDC z/OS. Avant de créer des abonnements, le magasin de données doit être configuré dans la console de gestion pour utiliser des adresses IP virtuelles.
• Pour rendre un abonnement persistant, cliquez dessus avec le bouton droit de la souris et sélectionnez Properties. Sélectionnez ensuite Advanced Settings et cliquez sur Mark subscription as persistent.

Les quatre principaux scénarios de résilience sont les suivants

• Défaillance du système de gestion de la base de données source (SGBD)
• Échec de la source InfoSphere CDC
• Échec de la cible InfoSphere CDC
• Défaillance du SGBD cible

Les scénarios de défaillance de la source InfoSphere CDC et de la cible InfoSphere CDC couvrent également les défaillances globales du système d'exploitation ou du matériel sur l'instance z/OS.

Si le SGBD source est désactivé, le produit annule instantanément tous les abonnements. Dans le cas des abonnements permanents, le logiciel détecte la disponibilité du SGBD et redémarre automatiquement les abonnements terminés. Si une défaillance grave du SGBD se produit et que le membre du SGBD devient inutilisable, la source InfoSphere CDC doit être basculée sur un autre membre.

Le basculement de la source InfoSphere CDC z/OS nécessite la fin de l'espace d'adressage InfoSphere CDC z/OS s'il est toujours actif et son redémarrage avec le même ID utilisateur sur un autre membre du groupe de partage de données. Si l'espace d'adressage s'est terminé alors que les abonnements étaient actifs, les abonnements marqués comme persistants sont immédiatement relancés lorsque l'espace d'adressage est redémarré. Dans le cas contraire, les abonnements doivent être redémarrés manuellement.

Comme l'adresse IP de la cible reste inchangée et correctement spécifiée dans les métadonnées partagées, la console de gestion ne peut contacter la source InfoSphere CDC que par l'intermédiaire de l'adresse IP virtuelle qui est acheminée vers le membre de basculement.

La résilience d'une cible InfoSphere CDC z/OS indisponible peut consister à survivre aux perturbations du réseau ou, si la cible devient inutilisable, à en transférer le contrôle à un autre membre. En cas d'interruption du réseau, les fonctions d'abonnement permanent d' InfoSphere CDC z/OS permettent de se reconnecter automatiquement. Si la cible InfoSphere CDC devient indisponible via les canaux de communication, la source InfoSphere CDC z/OS tente de se connecter à la cible aux intervalles spécifiés par le paramètre de configuration AUTORESTARTINTERVAL. Lorsque la cible InfoSphere CDC devient disponible, les abonnements marqués comme persistants sont automatiquement redémarrés.

L'abonnement permanent tente de simplifier les procédures de basculement lorsqu'un basculement cible est nécessaire. Si l'espace d'adressage cible d' InfoSphere CDC z/OS est toujours en cours d'exécution, il doit être arrêté puis repris sur un autre membre du groupe de partage des données en utilisant le même ID utilisateur. Pour résoudre le problème du membre de basculement, l'adresse IP virtuelle que la source et la console de gestion utilisent pour atteindre la cible doit être modifiée. L'abonnement permanent se reconnecte immédiatement à la nouvelle cible une fois que l'instance cible fonctionne et que l'adresse IP virtuelle de la cible est redirigée. Lors d'un basculement de cible, la source InfoSphere CDC z/OS peut continuer à fonctionner. Les abonnements doivent être redémarrés manuellement pour les sources InfoSphere CDC qui ne prennent pas en charge la fonction d'abonnement permanent. En outre, si le basculement est exécuté de manière contrôlée, par exemple en mettant fin spécifiquement aux abonnements, ces derniers doivent être redémarrés manuellement. La capacité de redémarrage automatique est conçue pour redémarrer les abonnements qui se sont arrêtés en raison d'une perte de connectivité, plutôt que les abonnements qui se sont arrêtés naturellement ou en raison d'une erreur du SGBD sur la cible.

Si le SGBD cible est indisponible, la cible InfoSphere CDC z/OS reste fonctionnelle et suspend les opérations. Le cache de répétition doit être spécifié à l'aide des paramètres de configuration RECOVERYRETRYLIMIT et RETRYCACHESIZE afin de garantir un comportement de suspension fiable. La suspension entraîne la sauvegarde des données, ce qui finit par bloquer le produit. Il s'agit d'une situation normale de récupération jusqu'à ce que le SGBD cible soit à nouveau actif. Lorsque le produit détecte que le SGBD est opérationnel, il reprend instantanément la mise en miroir et traite son carnet de commandes.