Implémenter la réplication rsync de pair à pair

Cette implémentation 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 homologues de niveau intermédiaire. Chaque noeud dispose d'une connectivité SSH à son homologue et utilise les commandes rsync via SSH pour répliquer les artefacts de fichier de niveau intermédiaire principal.

Les avantages de l'implémentation de la réplication pair-à-pair rsync 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.
• 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, 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.

Les éléments à prendre en compte pour l'implémentation du pair à pair rsync sont les suivants :

• 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.
• Elle nécessite une maintenance sur de nombreux nœuds car les scripts ne sont pas centralisés. La solution est donc plus complexe dans les clusters volumineux.

Les scripts rsync peer-to-peer 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 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 secours, ils exécutent une opération d'extraction pour extraire le contenu de la base de données principale. Lorsque les scripts rsync sont exécutés sur les noeuds dotés du rôle principal, ils exécutent une opération Push pour copier le contenu vers les noeuds secondaires. Oracle recommande le modèle d'extraction pour les pairs. Ainsi, 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) sont exécutées dans les noeuds secondaires.

Configuration de la réplication pour rsync pair à pair

Les éléments suivants sont requis pour implémenter le modèle peer-to-peer rsync :

• Autoriser la connectivité SSH entre les hôtes et leurs hôtes homologues.
• Créez des scripts qui utilisent rsync pour copier les artefacts de fichier de niveau intermédiaire entre les hôtes principaux et secondaires. Les scripts rsync peuvent ignorer certains dossiers de la copie (tels que les fichiers de verrouillage, les journaux, les fichiers temporaires, etc.)
• Implémentez 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 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).

Exemple 1 : utilisation des scripts rsync du manuel Oracle Fusion Middleware Disaster Recovery Guide pour la réplication entre homologues

Remarques :

Cet exemple s'applique à tout système de niveau intermédiaire. Il utilise les scripts fournis par le Guide de récupération après sinistre Oracle Fusion Middleware pour exécuter la réplique de niveau intermédiaire pour un système de récupération après sinistre 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 tous les artefacts de fichier de niveau intermédiaire dans OCI. Reportez-vous à la section Explorer plus 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 homologue et effectue une extraction du contenu. 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 Peer-to-Peer en particulier.

description de l'illustration dr-scripts-peer-peer.png,

dr-scripts-peer-peer-oracle.zip

Validation de la réplication pour rsync pair à pair

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 dans la base de données de secours. Vous n'avez pas besoin d'attacher ou de monter un volume. La seule action dont vous avez besoin est de vous assurer qu'il 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é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.
3. 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 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.

Exécution de la réplication continue pour rsync pair à pair

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 lorsque vous utilisez rsync à partir des hôtes de niveau intermédiaire :

• 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 Oracle Fusion Middleware, suivez les étapes décrites dans la section Planification de la réplication en cours avec des scripts Rsync. 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 à niveau intermédiaire au début 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.
• Tenez à 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. Par exemple, avec les scripts rsync fournis par le Guide de récupération après sinistre Oracle Fusion Middleware, veillez à créer les scripts équivalents pour exécuter 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.