Mettre en oeuvre la réplication d'Oracle Database File System (DBFS)

Cette mise en oeuvre consiste à copier le contenu du niveau intermédiaire (middle tier) dans un dossier DBFS et à s'appuyer sur Oracle Data Guard pour le répliquer vers le site secondaire. Le contenu du niveau intermédiaire ne réside pas directement dans DBFS, car cela rendrait le niveau intermédiaire dépendant de l'infrastructure DBFS (base de données, bibliothèques FUSE, points de montage, etc.). Le montage DBFS n'est qu'un dossier intermédiaire intermédiaire pour stocker une copie du contenu.

Toute réplication vers la base de données de secours implique deux étapes dans ce modèle : du dossier d'origine de la base principale au montage DBFS intermédiaire, puis, dans le site secondaire, du montage DBFS au dossier de destination de la base de données de secours. Les copies intermédiaires sont effectuées à l'aide de rsync. Comme il s'agit d'une copie rsync locale à faible latence, certains des problèmes qui surviennent lors d'une opération de copie rsync distante sont évités avec ce modèle.

Note :

Cette méthode n'est pas prise en charge avec Oracle Autonomous Database, qui n'autorise pas les connexions DBFS.

Description de replica-mid-tier-dbfs.png :
Description de l'illustration replica-mid-tier-dbfs.png

replica-mid-tier-dbfs-oracle.zip

Les avantages de la mise en oeuvre de la réplique de niveau intermédiaire (middle tier) avec DBFS sont les suivants :

  • Cette méthode tire parti de la robustesse de la réplique Oracle Data Guard.
  • Le stockage de niveau intermédiaire réel peut rester monté sur les noeuds secondaires. Il n'y a aucune étape supplémentaire pour attacher ou monter le stockage dans le secondaire lors de chaque opération de permutation ou de basculement.

Voici les points à considérer pour implémenter la réplique de niveau intermédiaire (middle tier) avec DBFS :

  • Cette méthode nécessite Oracle Database avec Oracle Data Guard.
  • Les hôtes de niveau intermédiaire (middle tier) ont besoin du client Oracle Database pour monter le DBFS.
  • L'utilisation de DBFS pour la réplication a des implications du point de vue de la configuration, du stockage de base de données et du cycle de vie. Il nécessite une installation du client Oracle Database sur les hôtes de niveau intermédiaire (middle tier), une certaine maintenance de la base de données (pour nettoyer, compresser et réduire le stockage des tables) et une bonne compréhension du comportement des points de montage DBFS.
  • Les répertoires DBFS ne peuvent être montés que si la base de données est ouverte. Lorsque Oracle Data Guard n'est pas Active Data Guard, la base de données de secours est à l'état de montage. Par conséquent, pour accéder au montage DBFS du site secondaire, vous devez convertir la base de données en base de données de secours instantanée. Lorsque Active Data Guard est utilisé, le système de fichiers peut être monté pour les lectures et il n'est pas nécessaire de passer à un instantané.
  • Il n'est pas recommandé d'utiliser DBFS comme solution à usage général pour répliquer tous les artefacts (en particulier les fichiers d'exécution) vers la base de secours. L'utilisation de DBFS pour répliquer les fichiers binaires est une surcharge. Toutefois, cette approche convient pour répliquer quelques artefacts, tels que la configuration, lorsque d'autres méthodes telles que la réplication de stockage ou rsync ne répondent pas aux besoins du système.
  • 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.

Configurer la réplication pour le système de fichiers de base de données

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 éléments suivants sont requis pour mettre en oeuvre une réplique de niveau intermédiaire (middle tier) avec DBFS :

  • Installation du client Oracle Database sur les hôtes de niveau intermédiaire (middle tier) qui effectuent la copie, à la fois dans le primaire et le secondaire.
  • Système de fichiers DBFS créé dans la base de données.
  • Un montage DBFS sur les hôtes de niveau intermédiaire (middle tier) qui effectuent les copies, à la fois en primaire et en secondaire. Cela monte le système de fichiers DBFS de la base de données. Ce système de fichiers peut être monté sur plusieurs hôtes, car DBFS est un système de fichiers partageable.
  • Scripts qui copient les artefacts de fichier de niveau intermédiaire (middle tier) vers le montage DBFS du site principal.
  • Scripts qui copient les artefacts de fichier de niveau intermédiaire (middle tier) du montage DBFS dans les dossiers du site secondaire. Selon la mise en oeuvre, cette méthode peut nécessiter une connectivité SQL*net entre les hôtes de niveau intermédiaire (middle tier) et la base de données distante pour les opérations de base de données telles que les conversions de rôle.
  • 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.
  • Programmez l'exécution continue de ces scripts.
  • Mécanisme permettant de modifier la direction de la réplique après une permutation ou un basculement.
Exemple 1 : Utiliser DBFS pour répliquer un domaine Oracle WebLogic

Note :

L'exemple suivant s'applique aux systèmes Oracle WebLogic. Vous pouvez l'utiliser comme référence pour copier d'autres dossiers du système de niveau intermédiaire au moyen de DBFS, mais cet exemple particulier utilise un script qui réplique le dossier de domaine de l'administrateur WebLogic vers le dossier secondaire au moyen de DBFS.

Cet exemple montre comment répliquer le dossier de domaine de l'hôte d'administration WebLogic au moyen de DBFS. Le contenu situé en dehors du dossier de domaine, ainsi que le contenu sur d'autres hôtes, n'est pas inclus dans cet exemple. Le dossier de domaine ne réside pas directement sur DBFS; le montage DBFS n'est qu'un dossier intermédiaire pour stocker une copie du dossier de domaine.

Cet exemple fournit un script pour effectuer ces actions, qui doivent s'exécuter périodiquement sur les sites principal et de secours. Ce script copie le dossier du domaine d'administration WebLogic, en ignorant certains éléments tels que les fichiers tmp, .lck, .state et tnsnames.ora. La procédure se compose des éléments suivants :

  • Lorsque le script s'exécute sur l'hôte d'administration WebLogic du site principal, le script copie le dossier de domaine WebLogic dans le dossier DBFS.
  • Les fichiers copiés dans le DBFS, tels qu'ils sont stockés dans la base de données, sont automatiquement transférés vers la base de données de secours au moyen d'Oracle Data Guard.
  • Lorsque le script s'exécute sur l'hôte d'administration WebLogic du site secondaire :
    • Le script convertit la base de données de secours en base de données de secours instantanée.
    • Il monte ensuite le système de fichiers DBFS à partir de la base de données de secours.
    • Le dossier de domaine répliqué est maintenant disponible dans ce dossier DBFS. Le script le copie du montage DBFS vers le dossier du domaine réel.
    • Enfin, le script convertit de nouveau la base de données de secours en base de secours physique.
  • En cas de modification de rôle, le script adapte automatiquement l'exécution au nouveau rôle. Il rassemble le rôle réel du site en vérifiant le rôle de base de données.

Ce script reproduit uniquement le dossier de domaine de l'hôte d'administration WebLogic. Le contenu du dossier DOMAIN_HOME/config est automatiquement copié vers tous les autres noeuds qui font partie du domaine WebLogic au démarrage des serveurs gérés. Les fichiers situés en dehors de ce dossier et les fichiers situés sur d'autres hôtes ne sont pas répliqués et doivent être synchronisés séparément.

Pour les opérations de déploiement d'application, utilisez l'option de déploiement Charger vos fichiers dans la console d'administration WebLogic. De cette façon, les fichiers déployés sont placés sous le répertoire de chargement du serveur d'administration ($DOMAIN_HOME/servers/admin_server_name/upload), et le script de réplique de configuration les synchronise sur le site de secours.

Cet exemple fournit un autre script pour installer le client de base de données et configurer un montage DBFS dans les hôtes de niveau intermédiaire (middle tier). L'image est un exemple de système Oracle WebLogic Server pour OCI avec réplication DBFS.


Description de wls-dbfs-replication.png :
Description de l'illustration wls-dbfs-replication.png

wls-dbfs-replication-oracle.zip

Effectuez les opérations suivantes pour utiliser la méthode DBFS pour répliquer le domaine WebLogic :

  1. Autorisez la connectivité SQL*net entre les hôtes d'administration et les bases de données distantes.
    Oracle recommande d'utiliser l'appairage distant avec la passerelle de routage dynamique. Le script requiert cette connectivité pour effectuer des opérations de base de données telles que des conversions de rôle. Lorsque le script s'exécute sur le site avec le rôle de base de données de secours, il convertit la base de données de secours en base de données de secours instantanée pour monter le montage DBFS.
  2. Téléchargez les scripts.
    Ce document fournit des scripts pour configurer le montage DBFS et automatiser la réplication.
    1. Allez au référentiel Oracle MAA dans GitHub. Reportez-vous à la section Explorer plus dans ce livre de jeu.
    2. Téléchargez tous les scripts dans le répertoire app_dr_common.
    3. Téléchargez tous les scripts dans le répertoire wls_mp_dr.
    4. Copiez-les vers les hôtes d'administration principal et secondaire, vers un emplacement qui n'est pas répliqué.
    5. Les scripts font des appels les uns aux autres. Copiez les scripts des deux répertoires et placez-les dans le même dossier. Assurez-vous que l'utilisateur oracle dispose de l'autorisation d'exécution.
  3. Configurez le montage DBFS dans les hôtes d'administration principal et secondaire.

    Note :

    Si vous avez déjà un montage DBFS, vous pouvez ignorer cette étape. Par exemple, certaines piles SOA Marketplace sont fournies avec un montage DBFS prêt à l'emploi.
    Configurez le montage DBFS dans les hôtes d'administration WebLogic principaux et secondaires. Il nécessite le client de base de données et certains ensembles de système d'exploitation sur l'hôte d'administration WebLogic. Effectuez les étapes suivantes pour chaque hôte d'administration :
    1. Téléchargez le client de base de données à partir de la livraison électronique et chargez-le sur l'hôte de niveau intermédiaire (ne l'installez pas encore). Recherchez le client Oracle Database et sélectionnez le client de base de données uniquement. Cliquez sur Continuer, puis sélectionnez la version du programme d'installation (et non l'image de référence).

      Note :

      Assurez-vous de télécharger la version du programme d'installation et non l'installation basée sur une image. Il est recommandé d'utiliser la dernière version.
      Par exemple, téléchargez le fichier 982064-01.zip pour le client Oracle Database 19.3.0.0.0 pour Linux x86-64, 1,1 Go et chargez-le sur /u01/install/V982064-01.zip sur tous les hôtes de niveau intermédiaire.

      Ne l'installez pas encore.

    2. Localisez le script dbfs_dr_setup_root.sh sous le dossier app_dr_common.
      Ce script effectue les tâches pour préparer le montage DBFS dans l'hôte. Il installe le client de base de données et les ensembles de système d'exploitation requis, configure l'utilisateur et le schéma DBFS dans la base de données, monte le système de fichiers DBFS et crée un fichier cron, de sorte que le système de fichiers DBFS est monté au démarrage de l'hôte.
    3. Exécutez le script en tant qu'utilisateur root.
      La syntaxe est la suivante :
      ./dbfs_dr_setup_root.sh  local_db_scan_name db_port  local_PDB_service pdb_sys_password path_to_dbclient_installer
      En tant que paramètres d'entrée, fournissez les données de connexion utilisées pour la connexion à la base de données locale utilisée par WLS : fournissez les données de connexion à la base de données enfichable principale lorsque vous l'exécutez dans l'hôte d'administration du site principal et fournissez les données de connexion à la base de données enfichable secondaire lorsque vous l'exécutez dans l'hôte d'administration secondaire.

      Note :

      La base de données de secours doit être en mode de secours instantané pour exécuter ce script sur l'hôte d'administration secondaire.
      L'exemple suivant l'exécute en tant qu'hôte d'administration principal de niveau intermédiaire (middle tier). Il doit s'agir d'une seule ligne et vous devez fournir les valeurs de la base de données enfichable principale et votre mot de passe :
      ./dbfs_dr_setup_root.sh  drdba-scan.wlsdrvcnlon1ad2.wlsdrvcnlon1.oraclevcn.com 1521 mypdbservice.example.com  mypassword   /u01/install/V982064-01.zip
      L'exemple suivant l'exécute sur l'hôte d'administration secondaire de niveau intermédiaire (middle tier). Il doit s'agir d'une seule ligne et vous devez fournir les valeurs de la base de données enfichable principale et votre mot de passe :
      ./dbfs_dr_setup_root.sh  drdbb-scan.wlsdrvcnfra1ad2.wlsdrvcnfra1.oraclevcn.com 1521 mypdbservice.example.com  mypassword   /u01/install/V982064-01.zip
      Suite à l'exécution de ce script, vous obtenez les éléments suivants :
      Artefact Valeur Description
      Répertoire de base du client de base de données /u01/app/oracle/client Le script installe le logiciel client de base de données dans l'hôte. Il utilise également yum pour installer les ensembles requis.
      Utilisateur de base de données

      Nom : dbfsuser

      Mot de passe : identique à sys

      		Utilisateur de la base de données enfichable pour DBFS.
      Espace-table DBFS tbsdbfs Espace-table dans la base de données enfichable pour le montage DBFS.
      Dossier DBFS dbfsdir Dossier DBFS du tablespace.
      Dossier de l'hôte de niveau intermédiaire (middle tier) DOMAIN_HOME/dbfs Il contient le portefeuille qui stocke l'utilisateur, le mot de passe et les autres artefacts (tnsnames.ora, sqlnet.ora) requis par le client de base de données pour monter le fichier DBFS dans l'hôte.
      Script dans l'hôte de niveau intermédiaire DOMAIN_HOME/dbfs/dbfsMount.sh Script pour monter le système de fichiers DBFS dans l'hôte. Ce script est ajouté à cron lors du redémarrage. Il est donc exécuté lors du redémarrage de l'ordinateur.
      Point de montage dans l'hôte de niveau intermédiaire /u02/data/dbfs_root Le système de fichiers DBFS est monté dans le point de montage /u02/data/dbfs_root en tant que dossier dbfsdir.

      Vous pouvez réexécuter le script, mais vous recevrez des avertissements car certaines choses ont déjà été créées (utilisateur de base de données, tablespace, etc.). Vous pouvez ignorer ces messages.

    4. Vérifiez que le montage DBFS est présent dans l'hôte d'administration de niveau intermédiaire (middle tier).
      [root@ prefix-wls-1]# df -h | grep dbfs
dbfs-@PDB1:/     32G  248K   32G   1% /u02/data/dbfs_root
[root@ prefix-wls-1]# ls /u02/data/dbfs_root
dbfsdir
      Ce système de fichiers DBFS est utilisé en tant que système de fichiers d'assistance pour stocker une copie de la configuration de domaine du site principal.
  4. Préparez le script de réplique.
    Ce document fournit un script de référence pour cette mise en oeuvre, le script config_replica.sh.
    1. Dans l'hôte d'administration Oracle WebLogic principal, ouvrez le script config_replica.sh. Modifiez les sections de paramètres personnalisables.
      Assurez-vous de fournir les variables appropriées pour la variable principale. Dans la propriété DR_METHOD, utilisez DBFS.
    2. Faites de même sur l'hôte d'administration Oracle WebLogic secondaire. Assurez-vous de fournir les variables appropriées pour le secondaire.
  5. Exécutez le script de réplication.
    1. En tant qu'utilisateur oracle, exécutez le script config_replica.sh dans l'hôte d'administration Oracle WebLogic principal.
      Le script vérifie le rôle de site courant et copie la configuration du domaine du domaine Oracle WebLogic Server principal vers le montage DBFS.
    2. Surveiller l'exécution et détecter toute erreur.
    3. Une fois l'opération terminée, exécutez le script config_replica.sh sur l'hôte Oracle WebLogic Administration Server du site secondaire.
      Assurez-vous d'utiliser les valeurs appropriées dans les paramètres personnalisés. Le script vérifie le rôle de base de données. Comme il s'agit de la base de données de secours, elle copiera la configuration du domaine du système de fichiers intermédiaire secondaire vers le domaine Oracle WebLogic Server secondaire.

    Note :

    Ce script doit toujours être exécuté à la fois dans la base principale et dans la base de secours pour effectuer une réplication complète : d'abord sur la base principale pour copier le domaine dans le dossier DBFS, puis sur la base de secours pour copier le domaine du DBFS dans le dossier du domaine. La fréquence dépend de la fréquence à laquelle les modifications de configuration sont effectuées sur le domaine Oracle WebLogic Server.

Valider la réplication pour le système de fichiers de base de données

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.

Effectuez les opérations suivantes pour utiliser le contenu répliqué dans la base de secours :

  1. Exécutez une réplication.
    Exécutez les scripts de réplique pour rendre le contenu le plus récent disponible dans le système secondaire.
  2. Désactiver les réplications programmées.
    Une fois la dernière réplique terminée, désactivez tout script de réplique. Sinon, il peut interférer avec la procédure de permutation, de basculement ou de validation. Vous l'activerez à nouveau après l'opération, dans la direction appropriée.

Effectuer une réplication continue pour le système de fichiers de base de données

Exécutez le script 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 crontab du système d'exploitation ou un autre outil de programmation pour programmer la réplication. Il doit permettre aux scripts de terminer la réplication. Sinon, les tâches suivantes peuvent se chevaucher.
  • 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 pendant la réplication des modifications, celles-ci prendront effet lors du prochain démarrage. Démarrez-les uniquement lors de la validation du site de secours ou lors de la procédure de permutation ou de basculement.
  • Gérez les informations propres à chaque site et tenez-les à jour. Par exemple, ignorez tnsnames.ora de la copie afin que chaque système ait ses détails de connectivité. Si vous effectuez une modification dans tnsnames.ora en primaire (par exemple, en ajoutant un nouvel alias), mettez à jour manuellement tnsnames.ora en secondaire en conséquence.
  • Après une permutation ou un basculement, inversez la direction de la réplique. Cela dépend de la mise en œuvre spécifique. Les scripts peuvent utiliser une vérification dynamique pour identifier qui est le site actif, ou vous pouvez effectuer une modification manuelle après une permutation ou un basculement (par exemple, en désactivant et en activant les scripts appropriés). Dans l'exemple fourni, le script config_replica.sh adapte automatiquement l'exécution au rôle réel du site en vérifiant le rôle de base de données locale.