Mettre en oeuvre rsync avec un emplacement intermédiaire central

Cette mise en oeuvre utilise la technologie rsync et suit le modèle basé sur un emplacement intermédiaire central. Dans ce modèle, il existe un noeud hôte bastion qui agit en tant que coordinateur. Il se connecte à chaque hôte qui doit être répliqué et copie le contenu vers un emplacement intermédiaire commun.

Les avantages de la mise en oeuvre de rsync avec un emplacement de stockage temporaire central sont les suivants :

  • Il s'agit d'une solution polyvalente applicable à n'importe quel milieu de gamme. Par conséquent, si vous disposez de plusieurs systèmes, vous pouvez utiliser la même approche dans chacun d'entre eux.
  • Il ne dépend pas du type de stockage sous-jacent; il est valide pour la réplication d'artefacts de fichier qui résident dans des volumes par blocs, dans NFS, etc.
  • Le stockage peut rester monté sur les noeuds secondaires. Par conséquent, aucune étape supplémentaire n'est requise pour attacher ou monter le stockage dans le secondaire lors de chaque opération de permutation ou de basculement.
  • Par rapport à l'implémentation peer-to-peer, la maintenance est plus simple, car il existe un nœud central pour exécuter les scripts.

Les considérations relatives à la mise en oeuvre du fichier rsync avec un emplacement intermédiaire central sont les suivantes :

  • Il incombe à l'utilisateur de créer les scripts personnalisés pour chaque environnement et de les exécuter périodiquement.
  • Il est de la responsabilité de l'utilisateur de mettre en œuvre un moyen d'inverser la direction de la réplique.
  • Ce modèle nécessite un hôte et un stockage supplémentaires pour l'emplacement intermédiaire central.

Comme pour le modèle pair-à-pair, les scripts rsync peuvent utiliser un modèle à flux tiré ou à flux poussé. Dans le modèle "pull", le script copie les fichiers du noeud distant vers le noeud local. Dans le modèle "pousser", le script copie le fichier du noeud local vers le noeud distant. Oracle recommande d'utiliser un modèle d'extraction pour extraire le contenu des hôtes principaux, car il décharge les noeuds principaux de la surcharge des copies.

Configurer la réplication pour rsync avec le stockage temporaire central

Les éléments suivants sont requis pour mettre en oeuvre rsync avec un emplacement temporaire central :

  • Hôte bastion avec connectivité SSH à tous les hôtes (principal et secondaire).
  • Dossier intermédiaire dans l'hôte bastion, avec suffisamment d'espace pour stocker le contenu du système de fichiers de niveau intermédiaire qui est répliqué.
  • Scripts qui utilisent rsync pour copier les artefacts de fichier de niveau intermédiaire depuis et vers ce dossier intermédiaire. Les scripts rsync peuvent ignorer certains dossiers de la copie (comme les fichiers de verrouillage, les journaux, les fichiers temporaires, etc.).
  • Un moyen de gérer les informations spécifiques au site, soit en excluant ces informations de la copie, soit en les mettant à jour avec les informations appropriées après la réplique.
  • Planifiez l'exécution périodique de ces scripts.
  • Mécanisme permettant de modifier la direction de la réplique après une permutation ou un basculement. Ce mécanisme peut être une vérification dynamique qui identifie le rôle du site, ou une modification manuelle après une permutation ou un basculement (par exemple, la désactivation et l'activation des scripts appropriés).
Ce document présente deux exemples de mise en oeuvre différents de ce modèle :
  • Exemple 1 : Utiliser les scripts du Oracle Fusion Middleware Disaster Recovery Guide
  • Exemple 2 : Utiliser la structure WLS-HYDR
Exemple 1 : Utiliser les scripts du manuel Oracle Fusion Middleware Disaster Recovery Guide

Note :

Cet exemple s'applique à tout système de niveau intermédiaire. À titre de référence, il utilise les scripts fournis par le Oracle Fusion Middleware Disaster Recovery Guide pour effectuer la réplique de niveau intermédiaire (middle tier) pour un système Oracle WebLogic DR : rsync_for_WLS.sh et rsync_copy_and_validate.sh. Toutefois, ces scripts sont généralement applicables et offrent une flexibilité suffisante pour synchroniser les artefacts de système de fichiers de niveau intermédiaire (middle tier) dans OCI.

Le Oracle Fusion Middleware Disaster Recovery Guide fournit des scripts rsync pour effectuer des copies distantes dans un système de niveau intermédiaire (middle tier). Ces scripts sont valides pour tout modèle rsync. Cet exemple particulier montre comment les utiliser pour le modèle intermédiaire central. Cette mise en oeuvre utilise des opérations d'extraction en deux étapes :

  • Un hôte bastion extrait le contenu de tous les hôtes principaux et les stocke dans la table intermédiaire centrale.
  • Ensuite, tous les noeuds secondaires effectuent une opération d'extraction pour collecter le contenu de la table intermédiaire centrale.

Pour configurer la réplication de niveau intermédiaire avec ces scripts, voir Réplication des systèmes de fichiers principaux vers le site secondaire dans le Oracle Fusion Middleware Disaster Recovery Guide et dans la section Rsync Replication Approach et Utilisation d'un emplacement de pré-production en particulier.


Description de replica-rsync-scripts.png :
Description de l'illustration replica-rsync-scripts.png

replica-rsync-scripts-oracle.zip

Exemple 2 : Utiliser la structure WLS-HYDR

Note :

Cet exemple s'applique à un système Oracle WebLogic Server. Il utilise le module de réplication de la structure WLS-HYDR, mais il s'applique à tout environnement DR Oracle WebLogic Server, qu'il ait été créé avec la structure WLS-HYDR ou non.

Dans ce modèle, un noeud hôte central agit en tant que coordinateur total, effectuant des opérations d'extraction et de poussée. Il se connecte à chaque hôte qui doit être répliqué et copie le contenu vers un emplacement intermédiaire commun. Ce noeud coordonne également la copie depuis l'emplacement intermédiaire vers les hôtes de destination. Cette approche décharge les noeuds individuels de la surcharge des copies.

Le cadre WLS-HYDR utilise cette approche pour la copie initiale lors de la configuration de récupération après sinistre. Vous pouvez ensuite réutiliser le module de réplication de l'environnement pour répéter l'extraction et la poussée périodiquement. Reportez-vous à Explorer plus dans ce livre de jeu pour obtenir des liens vers le cadre WLS-HYDR et d'autres ressources.

Le noeud d'hôte bastion effectue la réplique en deux étapes :

  • Opération d'extraction, dans laquelle elle se connecte aux hôtes principaux et copie le contenu du système de fichiers dans un dossier intermédiaire de l'hôte bastion.
  • Opération de poussée, qui copie le contenu du dossier intermédiaire de l'hôte bastion vers tous les hôtes secondaires.

Un nœud central effectue toutes les opérations, de sorte que la planification, les journaux, la maintenance, etc., sont centralisés sur ce nœud. Lorsque le système comporte de nombreux noeuds, cela est plus efficace par rapport au modèle peer-to-peer ou à l'exemple précédent.


Description de replica-wls-hydr-framework.png :
Description de l'illustration replica-wls-hydr-framework.png

replica-wls-hydr-framework-oracle.zip

Si vous avez utilisé le cadre WLS-HYDR pour créer le système secondaire, l'hôte bastion est déjà prêt à effectuer la réplique. Sinon, vous pouvez le configurer à ce stade. Pour configurer la réplique, procédez comme suit :

  1. Préparez l'hôte bastion.

    Si vous avez utilisé le cadre WLS-HYDR pour créer le système secondaire, l'hôte bastion est déjà prêt à effectuer la réplique. Sinon, vérifiez le fichier README dans le référentiel GitHub du cadre WLS-HYDR pour préparer un hôte bastion.

  2. Vérifiez les fichiers de configuration WLS-HYDR.
    Assurez-vous que les fichiers de configuration WLS-HYDR (replication.properties, oci.env et prem.env) contiennent les informations correctes pour votre système.
  3. Exécutez le module de réplication WLS-HYDR.
    Vous pouvez utiliser le module de réplication de la structure pour synchroniser tous les éléments (domaine et produits Oracle WebLogic Server), ou vous pouvez synchroniser ces éléments indépendamment. Dans tous les cas, la synchronisation complète se compose de deux opérations : une opération d'extraction, pour extraire le contenu du primaire, et une opération de poussée, pour copier le contenu dans le secondaire.

    Note :

    Exécutez toujours l'opération PULL avant PUSH. Sinon, vous ne pousserez pas la dernière version du contenu.
    1. Pour synchroniser tous les contenus :
      • Pour extraire tout le contenu des hôtes principaux vers l'emplacement temporaire de l'hôte bastion :
        WLS-HYDR_BASE/lib/DataReplication.py pull
      • Pour pousser tout le contenu de l'emplacement temporaire de l'hôte bastion vers les hôtes secondaires :
        WLS-HYDR_BASE/lib/DataReplication.py push
    2. Pour synchroniser les artefacts de produit uniquement :
      • Pour extraire les produits des hôtes principaux vers l'emplacement temporaire de l'hôte bastion : 
        WLS-HYDR_BASE/lib/DataReplication.py pull -d products
      • Pour pousser les produits de l'emplacement temporaire de l'hôte bastion vers les hôtes secondaires :
        WLS-HYDR_BASE/lib/DataReplication.py push -d products
    3. Pour synchroniser la configuration (domaine WebLogic) uniquement.
      • Pour extraire la configuration des hôtes principaux vers l'emplacement temporaire de l'hôte bastion, exécutez cette opération d'extraction :
        WLS-HYDR_BASE/lib/DataReplication.py pull -d private_config
      • Pour copier la configuration de l'emplacement temporaire de l'hôte bastion vers les hôtes secondaires, exécutez cette opération de poussée :
        WLS-HYDR_BASE/lib/DataReplication.py push -d private_config
    4. Pour les cas où il existe un dossier de configuration partagée (domaine Oracle WebLogic partagé dans un système de fichiers du service Stockage de fichiers OCI) :
      • Pour extraire la configuration partagée des hôtes principaux vers l'emplacement temporaire de l'hôte bastion, exécutez cette opération d'extraction :
        WLS-HYDR_BASE/lib/DataReplication.py pull -d shared_config
      • Pour copier la configuration partagée de l'emplacement temporaire de l'hôte bastion vers les hôtes secondaires, exécutez cette opération de poussée :
        WLS-HYDR_BASE/lib/DataReplication.py push -d shared_config
  4. Préparez les remplacements de chaîne de connexion à la base de données.
    Les opérations d'extraction et de poussée WLS-HYDR standard qui copient la configuration WebLogic ignorent le fichier tnsnames.ora des copies. Vous n'avez donc pas besoin de mettre à jour tnsnames.ora lors de chaque réplication suivante.

    Toutefois, l'approche est différente lorsque la base de données est une base de données Autonomous Database. Pour se connecter à une base de données autonome, le dossier d'administration TNS contient également un magasin de clés et des fichiers de magasin de certificats SSL, qui sont différents pour les bases de données principale et de secours.

    Le tableau suivant résume comment gérer les informations de connexion à la base de données dans chaque scénario :
    Type de base de données Script de remplacement et étapes de téléchargement Syntaxe
    Oracle Base Database Service ou Oracle Exadata Database Service Le script de gestion de tnsnames.ora est inclus dans le module de réplication du cadre WLS-HYDR.

    Assurez-vous que la section JDBC du fichier replication.properties contient les données correctes.

    Cette opération s'exécute dans l'hôte bastion et effectue l'extraction, la mise à jour et la poussée du fichier tnsnames.ora. Pour effectuer l'opération complète : WLS-HYDR/lib/DataReplication.py tnsnames

    Il n'est pas nécessaire de l'exécuter sauf si vous apportez des modifications à tnsnames.ora (par exemple, en ajoutant un alias).

    Base de données autonome

    fmwadb_switch_db_conn.sh

    Accédez au référentiel Oracle MAA dans GitHub https://github.com/oracle-samples/maa

    Téléchargez tous les scripts dans le répertoire app_dr_common.

    Téléchargez tous les scripts dans le répertoire fmw-wls-with-adb-dr.

    Copier vers tous les hôtes de niveau intermédiaire (middle tier). Les scripts font des appels les uns aux autres. Placez tous les scripts des deux répertoires dans le même dossier.

    Ce script doit être exécuté sur tous les hôtes de niveau intermédiaire (middle tier) de secours. Il doit s'exécuter avant de démarrer les serveurs WebLogic dans la base de données de secours pour une opération de validation, de permutation ou de basculement.

    Il remplace le dossier d'administration TNS utilisé par WebLogic par celui indiqué en entrée. Il met également à jour les propriétés du mot de passe du portefeuille dans les sources de données.

    Syntaxe pour exécuter le script : 
    fmwadb_switch_db_conn.sh WALLET_DIR WALLET_PASSWORD
    Où WALLET_DIR est un dossier qui contient les fichiers tnsnames.ora, de magasin de clés et de magasin de certificats SSL pour la connexion à la base de données locale. Assurez-vous que le dossier WALLET_DIR n'est pas remplacé dans la réplique.

Valider la réplication pour rsync avec le stockage temporaire central

Lors d'une opération de permutation ou de basculement, les informations répliquées doivent être disponibles et utilisables sur le site de secours avant le démarrage des processus. Cela est également nécessaire lorsque vous validez le système secondaire (en ouvrant la base de données de secours en mode instantané).

Dans cette mise en oeuvre, le stockage est toujours disponible dans le site secondaire, vous n'avez pas besoin d'attacher ou de monter de volume. La seule action que vous pouvez avoir besoin est de vous assurer qu'il contient la dernière version du contenu est la suivante.

  1. Exécutez une réplication.
    Exécutez les scripts pour répliquer la dernière version du contenu.
  2. Désactiver les réplications programmées.
    Une fois la dernière réplique terminée, désactivez tous les scripts de réplique. Sinon, il peut interférer avec la procédure de permutation, de basculement ou de validation. Vous activerez à nouveau les scripts après l'opération, dans la direction appropriée.
  3. Remplacez les informations propres au site dans les hôtes de niveau intermédiaire (middle tier) secondaires.
    Si les artefacts du système de fichiers que vous répliquez contiennent des informations propres au site, assurez-vous qu'ils ne sont pas remplacés par la copie ou qu'ils sont mis à jour après la réplique.

    Conseil :

    Par exemple, les scripts rsync du Oracle Fusion Middleware Disaster Recovery Guide et du module de réplication WLS-HYDR ignorent le fichier tnsnames.ora de la copie, de sorte que vous n'avez pas besoin de le modifier après chaque réplication.

    Si le système utilise Oracle Autonomous Database, restaurez le dossier de portefeuille requis dans le secondaire pour vous connecter à la base de données de la région secondaire. Vous pouvez utiliser le script de remplacement fmwadb_switch_db_conn.sh dans tous les hôtes de niveau intermédiaire de secours. Il nécessite, en tant qu'entrées, le chemin où se trouve le portefeuille d'origine secondaire et le mot de passe du portefeuille.

Vous pouvez ensuite effectuer les étapes supplémentaires requises pour valider le système.

Effectuer une réplication continue pour rsync avec l'emplacement intermédiaire central

Exécutez les scripts de réplication périodiquement pour garder le domaine secondaire synchronisé avec le domaine principal.

Suivez les recommandations suivantes pour la réplication en cours lors de l'utilisation de cette mise en oeuvre :

  • Utilisez le système d'exploitation crontab ou un autre outil de programmation pour exécuter périodiquement les scripts de réplication. Par exemple, lors de l'utilisation des scripts rsync fournis par le guide de récupération après sinistre, suivez les étapes de la section Programmation de la réplication continue à l'aide de scripts Rsync du guide de récupération après sinistre d'Oracle Fusion Middleware. Reportez-vous à Explorer plus dans ce livre de jeu pour obtenir des liens vers ces ressources et d'autres. Pour la fréquence de réplication, suivez les directives décrites dans Artefacts de fichier de niveau intermédiaire (Mid-tier) plus tôt dans ce livre de jeu.
  • Les processus de niveau intermédiaire (middle tier) arrêtés sur le site de secours. Si les serveurs sont actifs sur le site de secours pendant la réplication des modifications, celles-ci prendront effet lors du prochain démarrage. Démarrez-les uniquement lorsque vous validez le site de secours ou lors des procédures de permutation ou de basculement.
  • Mettez à jour les informations propres à chaque site. Par exemple, si le système de fichiers contient un dossier contenant les artefacts à connecter à une base de données Autonomous Database, tenez à jour une copie de sauvegarde de ce dossier. Assurez-vous de mettre à jour la sauvegarde du dossier de portefeuille lorsque vous effectuez une mise à jour dans le portefeuille. De cette façon, il sera correctement restauré lors des permutations et basculements suivants.
  • Après une permutation ou un basculement, inversez la direction de la réplique. Cela dépend de la mise en œuvre spécifique. Cela peut être fait à l'aide d'une vérification dynamique qui identifie qui est le site actif, ou avec une modification manuelle après une permutation ou un basculement, en désactivant et en activant les scripts appropriés.

    Conseil :

    • Lorsque vous utilisez les scripts rsync fournis par le guide DR (exemple 1), assurez-vous de créer les scripts équivalents pour effectuer la réplique dans l'autre sens. Dans le crontab ou l'outil planifié, activez uniquement les scripts appropriés pour le rôle réel.
    • Lorsque vous utilisez le WLS-HYDR (exemple 2), modifiez le rôle du primaire dans la structure WLS-HYDR, de sorte que les réplications suivantes vont dans l'autre sens. Pour cela, modifiez WLS-HYRDR/lib/DataReplication.py et remplacez les valeurs suivantes :
      if True:
       PRIMARY = PREM 
       STANDBY = OCI
      	 else:
	        PRIMARY = OCI
               STANDBY = PREM
      à ce qui suit :
      if False:
	        PRIMARY = PREM
                STANDBY = OCI
       	else:
                PRIMARY = OCI
                STANDBY = PREM