Implémenter la réplication DBFS (Oracle Database File System)

Cette implémentation consiste à copier le contenu de niveau intermédiaire vers 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 sur 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 de transfert 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 de données principale au montage DBFS intermédiaire, puis, sur 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. Etant donné qu'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.

Remarques :

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

Description de l'image replica-mid-tier-dbfs.png
Description de l'illustration replica-mi-niveau-dbfs.png

réplique-niveau intermédiaire-dbfs-oracle.zip

Les avantages de l'implémentation de la réplique de niveau intermédiaire 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é dans les noeuds secondaires. Il n'y a pas d'étapes supplémentaires pour attacher ou monter le stockage dans le secondaire lors de chaque opération de permutation ou de basculement.

Voici quelques remarques concernant l'implémentation de la réplique de niveau intermédiaire avec DBFS :

  • Cette méthode nécessite une instance Oracle Database avec Oracle Data Guard.
  • Les hôtes de niveau intermédiaire (middle tier) ont besoin du client Oracle Database pour monter 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. Elle nécessite une installation du client Oracle Database dans 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 peuvent être montés uniquement si la base de données est ouverte. Lorsque Oracle Data Guard n'est pas un Active Data Guard, la base de données de secours est à l'état de montage. Par conséquent, pour accéder au montage DBFS sur le 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 données de secours. L'utilisation de DBFS pour répliquer les fichiers binaires est excessive. Toutefois, cette approche permet de 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 incombe à l'utilisateur d'implémenter un moyen d'inverser la direction de la réplique.

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

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 éléments suivants sont requis pour implémenter une réplique de niveau intermédiaire avec DBFS :

  • Installation d'un client Oracle Database sur les hôtes de niveau intermédiaire qui effectuent la copie, à la fois dans l'hôte principal et l'hôte secondaire.
  • Système de fichiers DBFS créé dans la base de données.
  • Montage DBFS dans les hôtes de niveau intermédiaire qui effectuent les copies, à la fois en primaire et 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 vers le montage DBFS sur le site principal.
  • Scripts qui copient les artefacts de fichier de niveau intermédiaire du montage DBFS vers les dossiers du site secondaire. Selon l'implémentation, cette méthode peut nécessiter une connectivité SQL*net entre les hôtes de niveau intermédiaire et la base de données distante pour les opérations de base de données telles que les conversions de rôles.
  • 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 continue de ces scripts.
  • Mécanisme permettant de changer la direction de la réplique après une permutation ou un basculement.
Exemple 1 : utiliser DBFS pour répliquer le domaine Oracle WebLogic

Remarques :

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 via DBFS, mais cet exemple particulier utilise un script qui réplique le dossier de domaine de l'administrateur WebLogic vers le dossier secondaire via DBFS.

Cet exemple montre comment répliquer le dossier de domaine de l'hôte d'administration WebLogic via 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 être exécutées périodiquement sur les sites principal et de secours. Ce script copie le dossier de 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, il copie le dossier de domaine WebLogic dans le dossier DBFS.
  • Les fichiers copiés dans 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 via 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 cliché.
    • 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 désormais disponible dans ce dossier DBFS. Le script le copie du montage DBFS vers le dossier de domaine réel.
    • Enfin, le script convertit à nouveau la base de données de secours en base de données de secours physique.
  • En cas de changement 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 sous le 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 Télécharger vos fichiers vers le serveur dans la console d'administration WebLogic. De cette façon, les fichiers déployés sont placés sous le répertoire de télé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. L'image est un exemple de système Oracle WebLogic Server for OCI avec réplication DBFS.


Image cldbfs-replication.png
description de l'illustration wls-dbfs-replication.png,

wls-dbfs-replication-oracle.zip

Pour utiliser la méthode DBFS afin de répliquer le domaine WebLogic, procédez comme suit :

  1. Autoriser la connectivité SQL*net entre les hôtes d'administration et les bases de données distantes.
    Oracle recommande d'utiliser l'appairage à distance 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ôles. 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 permettant de configurer le montage DBFS et d'automatiser la réplication.
    1. Accédez au référentiel Oracle MAA dans GitHub. Reportez-vous à la section En savoir plus de ce guide stratégique.
    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 dans les hôtes d'administration principal et secondaire, à un emplacement qui n'est pas répliqué.
    5. Les scripts se font des appels. Copiez les scripts des deux répertoires et placez-les dans le même dossier. Assurez-vous que l'utilisateur oracle dispose des droits d'exécution.
  3. Configurez le montage DBFS dans les hôtes d'administration principal et secondaire.

    Remarques :

    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 principal et secondaire. Il requiert le client de base de données et certains packages du système d'exploitation sur l'hôte d'administration WebLogic. Pour chaque hôte d'administration, procédez comme suit :
    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 (middle tier) (ne l'installez pas encore). Recherchez 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 gold).

      Remarques :

      Assurez-vous de télécharger la version du programme d'installation, et non l'installation basée sur l'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, puis téléchargez-le vers /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 permettant de préparer le montage DBFS dans l'hôte. Il installe le client de base de données et les packages 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 une valeur cron, de sorte que le système de fichiers DBFS est monté lors de l'initialisation 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 de la base de données pluggable principale lorsque vous l'exécutez dans l'hôte d'administration du site principal, et fournissez les données de connexion de la base de données pluggable secondaire lorsque vous l'exécutez dans l'hôte d'administration secondaire.

      Remarques :

      La base de données de secours doit être en mode de secours cliché 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 de niveau intermédiaire principal. Il doit s'agir d'une seule ligne et vous devez fournir les valeurs de base de données pluggable 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 comme hôte d'administration de niveau intermédiaire secondaire. Il doit s'agir d'une seule ligne et vous devez fournir les valeurs de base de données pluggable 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 Value Description
      Répertoire de base de Database Client /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 packages requis.
      Utilisateur de base de données

      Nom : dbfsuser

      Mot de passe : identique à sys

      		Utilisateur de la base de données pluggable pour DBFS.
      Tablespace DBFS tbsdbfs Tablespace dans la base de données pluggable pour le montage DBFS.
      Dossier DBFS dbfsdir Dossier DBFS dans le tablespace.
      Un dossier dans l'hôte de niveau intermédiaire 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 DBFS dans l'hôte.
      Script dans l'hôte de niveau intermédiaire DOMAIN_HOME/dbfs/dbfsMount.sh Script permettant de monter le système de fichiers DBFS dans l'hôte. Ce script est ajouté à cron lors de la réinitialisation. Il est donc exécuté lorsque la machine est réinitialisée.
      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 certains éléments ont déjà été créés (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.
      [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 implémentation, le script config_replica.sh.
    1. Dans l'hôte d'administration Oracle WebLogic primary, ouvrez le script config_replica.sh. Modifiez les sections des paramètres personnalisables.
      Veillez à fournir les variables appropriées pour la variable principale. Dans la propriété DR_METHOD, utilisez DBFS.
    2. Effectuez la même opération dans l'hôte d'administration Oracle WebLogic secondaire. Veillez à 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 en cours et copie la configuration de domaine du domaine Oracle WebLogic Server principal vers le montage DBFS.
    2. Surveillez l'exécution et surveillez les éventuelles erreurs.
    3. Une fois l'opération terminée, exécutez le script config_replica.sh dans l'hôte Oracle WebLogic Administration Server du site secondaire.
      Veillez à utiliser les valeurs appropriées dans les paramètres personnalisés. Le script vérifie le rôle de base de données. Etant donné qu'il s'agit de la base de données de secours, il copie la configuration du domaine du système de fichiers intermédiaire secondaire vers le domaine Oracle WebLogic Server secondaire.

    Remarques :

    Ce script doit toujours être exécuté à la fois dans la base de données principale et dans la base de données de secours pour effectuer une réplication complète : d'abord sur la base de données principale pour copier le domaine dans le dossier DBFS, puis sur la base de données de secours pour copier le domaine de la base de données DBFS dans le dossier de 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 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.

Pour utiliser le contenu répliqué en standby, procédez comme suit :

  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ésactivez les réplications programmées.
    Une fois la dernière réplique terminée, désactivez tout script de réplique. Sinon, elle 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 régulièrement le script de réplication 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 crontab de l'O/S ou un autre outil de planification pour planifier la réplication. Il doit permettre aux scripts de terminer la réplication. Sinon, les travaux suivants peuvent se chevaucher.
  • Maintenez 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 lors de la validation du site de secours ou lors de la procédure de permutation ou de basculement.
  • Tenir à jour les informations propres à chaque site et les tenir à jour. Par exemple, ignorez l'élément tnsnames.ora de la copie afin que chaque système ait ses détails de connectivité. Si vous effectuez une modification dans tnsnames.ora dans le fichier principal (par exemple, l'ajout d'un nouvel alias), mettez à jour manuellement le fichier tnsnames.ora dans le fichier secondaire en conséquence.
  • Après une permutation ou un basculement, inversez le sens de la réplique. Cela dépend de l'implémentation spécifique. Les scripts peuvent utiliser une vérification dynamique pour identifier le site actif ou vous pouvez effectuer une modification manuelle après une permutation ou un basculement (par exemple, la désactivation et l'activation des 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.