Mettre en oeuvre la réplication peer-to-peer rsync

Cette mise en oeuvre utilise la technologie rsync et suit le modèle peer-to-peer. Dans ce modèle, la copie est effectuée directement entre les hôtes pairs de niveau intermédiaire (middle tier). Chaque noeud a une connectivité SSH à son homologue et utilise des commandes rsync sur SSH pour répliquer les artefacts de fichier de niveau intermédiaire principaux.

Les avantages de la mise en oeuvre de la réplication pair à pair rsync 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.
• Il n'a pas besoin de matériel supplémentaire, comme un hôte central ou un stockage.
• 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.

Les considérations pour la mise en œuvre du rsync peer-to-peer 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.
• Il nécessite une maintenance sur de nombreux noeuds, car les scripts ne sont pas centralisés. La solution est donc plus complexe dans les grands clusters.

Les scripts peer-to-peer 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 "pousser", le script copie les fichiers du noeud local vers le noeud distant. Lorsque les scripts rsync sont exécutés sur les noeuds dotés du rôle de base de données de secours, ils exécutent une opération d'extraction pour extraire le contenu de la base principale. Lorsque les scripts rsync sont exécutés sur les noeuds ayant le rôle principal, ils exécutent une opération de poussée pour copier le contenu vers les noeuds secondaires. Oracle recommande le modèle d'extraction pour peer-to-peer. De cette façon, les scripts rsync utilisent moins de ressources des hôtes du système principal, car toutes les opérations de la copie (par exemple, la comparaison checksum de la copie) s'exécutent dans les noeuds secondaires.

Configurer la réplication pour rsync Peer-to-Peer

Les éléments suivants sont requis pour mettre en oeuvre le modèle pair-à-pair rsync :

• Autorisez la connectivité SSH entre les hôtes et leurs hôtes pairs.
• Créez des scripts qui utilisent rsync pour copier les artefacts de fichier de niveau intermédiaire des hôtes principaux vers les hôtes secondaires. Les scripts rsync peuvent ignorer certains dossiers de la copie (comme les fichiers de verrouillage, les journaux, les fichiers temporaires, etc.)
• Mettre en œuvre 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).

Exemple 1 : Utiliser les scripts rsync du manuel Oracle Fusion Middleware Disaster Recovery Guide pour la réplication peer-to-peer

Note :

Cet exemple s'applique à tout système de niveau intermédiaire. 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 RS WebLogic : 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 fichier de niveau intermédiaire (middle tier) dans OCI. Reportez-vous à Explorer davantage pour obtenir des liens vers ces ressources et d'autres.

Dans cet exemple, chaque hôte du site secondaire établit une connexion avec son noeud principal pair et effectue une extraction du contenu. 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 pair à pair en particulier.

Description de l'illustration dr-scripts-peer-peer.png

dr-scripts-peer-peer-oracle.zip

Valider la réplication pour rsync Peer-to-Peer

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 la base de données de secours; vous n'avez pas besoin d'attacher ou de monter de volume. La seule action dont vous avez besoin est de vous assurer qu'elle contient la dernière version du contenu.

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 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.

Effectuer une réplication continue pour rsync Peer-to-Peer

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

Suivez ces recommandations lors de l'utilisation de rsync à partir des hôtes de niveau intermédiaire :

• 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 Oracle Fusion Middleware Disaster Recovery Guide, suivez les étapes décrites dans la section Programmation de la réplication continue à l'aide de scripts Rsync. 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 à mi-niveau au début de 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. Par exemple, avec les scripts rsync fournis par le Oracle Fusion Middleware Disaster Recovery Guide, assurez-vous de créer les scripts équivalents pour effectuer la réplique dans l'autre sens. Dans crontab ou l'outil programmé, activez uniquement les scripts appropriés pour le rôle réel.