Implémenter rsync avec un emplacement intermédiaire central

Implémenter `rsync` avec un emplacement intermédiaire central

Cette implémentation 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 de 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 l'implémentation de rsync avec un emplacement intermédiaire central sont les suivants :

Il s'agit d'une solution à usage général applicable à n'importe quel niveau intermédiaire. Par conséquent, si vous disposez de plusieurs systèmes, vous pouvez utiliser la même approche dans tous ces systèmes.
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 de blocs, dans NFS, etc.
Le stockage peut rester monté sur les noeuds secondaires. Par conséquent, il ne nécessite pas d'étapes supplémentaires pour attacher ou monter le stockage dans le secondaire à 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 noeud central pour l'exécution des scripts.

Les considérations relatives à l'implémentation de 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 incombe à l'utilisateur d'implémenter 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 peer-to-peer, les scripts rsync peuvent utiliser un modèle pull ou push. Dans le modèle "pull", le script copie les fichiers du noeud distant vers le noeud local. Dans le modèle "push", 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.

Configuration de la réplication pour `rsync` avec la préparation centrale

Les éléments suivants sont requis pour implémenter rsync avec un emplacement intermédiaire central :

Un bastion avec une connectivité SSH à tous les hôtes (principal et secondaire).
Dossier intermédiaire dans l'hôte du 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 (tels que les fichiers de verrouillage, les journaux, les fichiers temporaires, etc.).
Façon de gérer les informations propres au site, en excluant ces informations de la copie ou 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 changer 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 œuvre différents de ce modèle :

Exemple 1 : utilisation des scripts du Guide de récupération après sinistre Oracle Fusion Middleware
Exemple 2 : utilisation de la structure WLS-HYDR

Exemple 1 : utiliser les scripts du manuel Oracle Fusion Middleware Disaster Recovery Guide

Remarques :

Cet exemple s'applique à tout système de niveau intermédiaire. Pour référence, il utilise les scripts fournis par le Guide de récupération après sinistre Oracle Fusion Middleware afin d'exécuter la réplique de niveau intermédiaire pour un système de récupération après sinistre Oracle WebLogic : rsync_for_WLS.sh et rsync_copy_and_validate.sh. Toutefois, ces scripts sont généralement applicables et offrent suffisamment de flexibilité pour synchroniser les artefacts de système de fichiers de niveau intermédiaire dans OCI.

Le Guide de récupération après sinistre Oracle Fusion Middleware fournit des scripts rsync permettant d'effectuer des copies distantes dans un système de niveau intermédiaire. Ces scripts sont valides pour tout modèle rsync. Cet exemple montre comment les utiliser pour le modèle intermédiaire central. Cette implémentation utilise des opérations d'extraction en deux étapes :

Un bastion extrait le contenu de tous les hôtes principaux et les stocke dans le transfert central.
Ensuite, tous les noeuds secondaires effectuent une opération d'extraction pour collecter le contenu du transfert central.

Pour configurer la réplication de niveau intermédiaire à l'aide de ces scripts, reportez-vous à la section Replicating the Primary File Systems to the Secondary Site du Guide de récupération après sinistre Oracle Fusion Middleware, à la section Rsync Replication Approach et aux étapes Using a Staging Location en particulier.

Description de l'image replica-rsync-scripts.png

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

réplique-rsync-scripts-oracle.zip

Exemple 2 : utilisation de la structure WLS-HYDR

Remarques :

Cet exemple concerne un système Oracle WebLogic Server. Il utilise le module de réplication de la structure WLS-HYDR, mais il s'applique à tout environnement de récupération après sinistre 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 propagation. 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 de l'emplacement intermédiaire vers les hôtes de destination. Cette approche décharge les noeuds individuels de la surcharge des copies.

La structure WLS-HYDR utilise cette approche pour la copie initiale lors de la configuration de la récupération après sinistre. Vous pouvez ensuite réutiliser le module de réplication de la structure pour répéter l'extraction et la propagation régulièrement. Reportez-vous à Explorer plus dans ce guide pour obtenir des liens vers la structure WLS-HYDR et d'autres ressources.

Le noeud de bastion effectue la réplique en deux étapes :

Opération d'extraction, qui permet de se connecter aux hôtes principaux et de copier le contenu du système de fichiers dans un dossier intermédiaire de l'hôte de bastion.
Opération Push, qui copie le contenu du dossier intermédiaire du 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 que le modèle peer-to-peer ou l'exemple précédent.

Description de l'image replica-wls-hydr-framework.png

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

réplique-wls-hydr-framework-oracle.zip

Si vous avez utilisé la structure WLS-HYDR pour créer le système secondaire, l'hôte de 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 :

Préparer le bastion.

Si vous avez utilisé la structure WLS-HYDR pour créer le système secondaire, l'hôte de bastion est déjà prêt à effectuer la réplique. Dans le cas contraire, vérifiez le fichier README dans le référentiel GitHub de la structure WLS-HYDR pour préparer un bastion.
Consultez 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.
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 de la base principale et une opération de propagation, pour copier le contenu vers la base secondaire.

Remarques :
Exécutez toujours l'opération PULL avant PUSH. Sinon, vous ne propagerez pas la dernière version du contenu.
1. Pour synchroniser tout le contenu, procédez comme suit :
  - Pour extraire tout le contenu des hôtes principaux vers la zone intermédiaire de l'hôte du bastion :
```
WLS-HYDR_BASE/lib/DataReplication.py pull
```
  - Pour propager tout le contenu de la préparation de l'hôte du bastion vers les hôtes secondaires :
```
WLS-HYDR_BASE/lib/DataReplication.py push
```
2. Pour synchroniser les artefacts de produits uniquement, procédez comme suit :
  - Pour extraire les produits des hôtes principaux vers la zone intermédiaire de l'hôte du bastion :
```
WLS-HYDR_BASE/lib/DataReplication.py pull -d products
```
  - Pour propager les produits de la préparation de l'hôte du 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 la préparation de l'hôte du bastion, exécutez l'opération d'extraction suivante :
```
WLS-HYDR_BASE/lib/DataReplication.py pull -d private_config
```
  - Pour copier la configuration du transfert de l'hôte du bastion vers les hôtes secondaires, exécutez l'opération de propagation suivante :
```
WLS-HYDR_BASE/lib/DataReplication.py push -d private_config
```
4. Dans les cas où il existe un dossier de configuration partagée (domaine Oracle WebLogic partagé dans un système de fichiers OCI File Storage), procédez comme suit :
  - Pour extraire la configuration partagée des hôtes principaux vers la préparation de l'hôte du bastion, exécutez l'opération d'extraction suivante :
```
WLS-HYDR_BASE/lib/DataReplication.py pull -d shared_config
```
  - Pour copier la configuration partagée de la préparation de l'hôte du bastion vers les hôtes secondaires, exécutez l'opération de propagation suivante :
```
WLS-HYDR_BASE/lib/DataReplication.py push -d shared_config
```

Préparez-vous au remplacement des chaînes de connexion à la base de données.

Les opérations d'extraction et de propagation 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 dans chaque réplication suivante.

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

Le tableau suivant récapitule la façon dont vous pouvez 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 Utilisation

Type de base de données	Script de remplacement et étapes de téléchargement	Utilisation
Oracle Base Database Service ou Oracle Exadata Database Service	Le script de gestion de `tnsnames.ora` est inclus dans le module de réplication de structure WLS-HYDR.	Assurez-vous que la section JDBC du fichier `replication.properties` contient les données correctes. Cette opération s'exécute dans le bastion et effectue l'extraction, la mise à jour et la propagation pour le fichier `tnsnames.ora`. Pour effectuer l'opération complète, procédez comme suit : `WLS-HYDR/lib/DataReplication.py tnsnames` Aucune exécution n'est nécessaire, sauf si vous apportez des modifications à `tnsnames.ora` (par exemple, l'ajout d'un alias).
Autonomous Database	`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`. Copiez vers tous les hôtes de niveau intermédiaire. Les scripts se font des appels. 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 de secours. Il doit être exécuté 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 de mot de passe du portefeuille dans les sources de données. Syntaxe de l'exécution du script : `fmwadb_switch_db_conn.sh WALLET_DIR WALLET_PASSWORD` Où WALLET_DIR est un dossier qui contient les fichiers `tnsnames.ora`, keystore et truststore pour se connecter à la base de données locale. Assurez-vous que le dossier WALLET_DIR n'est pas remplacé dans la réplique.

Oracle Base Database Service ou Oracle Exadata Database Service

Le script de gestion de tnsnames.ora est inclus dans le module de réplication de structure WLS-HYDR.

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

Cette opération s'exécute dans le bastion et effectue l'extraction, la mise à jour et la propagation pour le fichier tnsnames.ora. Pour effectuer l'opération complète, procédez comme suit : WLS-HYDR/lib/DataReplication.py tnsnames

Aucune exécution n'est nécessaire, sauf si vous apportez des modifications à tnsnames.ora (par exemple, l'ajout d'un alias).

Autonomous Database

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.

Copiez vers tous les hôtes de niveau intermédiaire. Les scripts se font des appels. 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 de secours. Il doit être exécuté 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 de mot de passe du portefeuille dans les sources de données.

Syntaxe de l'exécution du script :

fmwadb_switch_db_conn.sh WALLET_DIR WALLET_PASSWORD

Où WALLET_DIR est un dossier qui contient les fichiers tnsnames.ora, keystore et truststore pour se connecter à 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 la préparation centrale

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 cliché).

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

Exécutez une réplication.
Exécutez les scripts pour répliquer la dernière version du contenu.
Désactivez les réplications programmées.
Une fois la dernière réplique terminée, désactivez tous les scripts de réplique. Sinon, elle 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.
Remplacez les informations propres au site dans les hôtes de niveau intermédiaire secondaires.
Si les artefacts de 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 Guide de récupération après sinistre Oracle Fusion Middleware et du module de réplication WLS-HYDR ignorent le fichier tnsnames.ora de la copie. Vous n'avez donc pas besoin de le modifier après chaque réplication.
Si le système utilise Oracle Autonomous Database, restaurez le dossier de portefeuille nécessaire 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. Elle requiert, 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.

Exécution d'une réplication continue pour `rsync` avec l'emplacement intermédiaire central

Exécutez les scripts de réplication régulièrement pour que le domaine secondaire reste synchronisé avec le domaine principal.

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

Utilisez le système d'exploitation crontab ou un autre outil de planification pour exécuter les scripts de réplication régulièrement. Par exemple, lorsque vous utilisez les scripts rsync fournis par le guide de récupération après sinistre, suivez les étapes de la section Planification de la réplication en cours avec des scripts Rsync du Guide de récupération après sinistre Oracle Fusion Middleware. Reportez-vous à Explorer plus dans ce guide pour obtenir des liens vers ces ressources et d'autres. Pour la fréquence de réplication, suivez les instructions décrites dans la section Artefacts de fichier de niveau intermédiaire de ce manuel.
Conservez les processus de niveau intermédiaire arrêtés sur le site de secours. Si les serveurs sont actifs sur le site de secours alors que les modifications sont répliquées, les modifications prendront effet lors du prochain démarrage. Démarrez-les uniquement lorsque vous validez le site de secours ou pendant les procédures de permutation ou de basculement.
Tenir à jour les informations propres à chaque site. Par exemple, si le système de fichiers contient un dossier contenant les artefacts permettant de se connecter à une instance Autonomous Database, tenez à jour une copie de sauvegarde de ce dossier. Veillez à 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 de la permutation et des basculements ultérieurs.
Après une permutation ou un basculement, inversez le sens de la réplique. Cela dépend de l'implémentation 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 de récupération après sinistre (exemple 1), veillez à créer les scripts équivalents pour exécuter 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.
- Lors de l'utilisation de WLS-HYDR (exemple 2), modifiez le rôle de la base principale dans la structure WLS-HYDR, de sorte que les prochaines réplications vont dans l'autre sens. Pour cela, modifiez WLS-HYRDR/lib/DataReplication.py et remplacez-les par :
```
if True:
       PRIMARY = PREM 
       STANDBY = OCI
      	 else:
	        PRIMARY = OCI
               STANDBY = PREM
```
  en l'instruction :
```
if False:
	        PRIMARY = PREM
                STANDBY = OCI
       	else:
                PRIMARY = OCI
                STANDBY = PREM
```