Configurer une solution de reprise après sinistre hybride pour Oracle SOA Suite

Étapes préliminaires

Avant de commencer à déployer une solution de récupération après sinistre hybride pour le système Oracle SOA Suite, assurez-vous de bien connaître les meilleures pratiques de haute disponibilité en matière de réseau, de stockage et d'hôte configurées pour les systèmes Oracle WebLogic Server sur place.

Le système Oracle WebLogic Server utilisé dans ce document est un environnement haute disponibilité qui a été configuré conformément aux meilleures pratiques standard MAA décrites dans le Guide de déploiement d'entreprise pour Oracle SOA Suite (EDG) pour les systèmes Fusion Middleware. Bien que tous les scénarios ne suivent pas cette topologie exacte dans les détails, cela couvre de nombreux composants et combinaisons différents, il est utilisé fréquemment dans les déploiements volumineux et met en œuvre des recommandations de haute disponibilité qui doivent être appliquées avant le déploiement d'un système de reprise après sinistre. Par conséquent, il est considéré comme le meilleur exemple de référence d'un système principal pour une solution de récupération après sinistre hybride pour Oracle WebLogic Server. Il est donc fortement recommandé de se familiariser avec les meilleures pratiques en matière de haute disponibilité et de déploiement d'entreprise pour Oracle WebLogic Server pour le réseau, le stockage et la configuration d'hôte avant de déployer un système hybride.

Pour plus de détails, reportez-vous à ce qui suit :

Guide sur la haute disponibilité d'Oracle Fusion Middleware
Guide de déploiement d'Oracle Fusion Middleware Enterprise pour Oracle SOA Suite
Guides de déploiement d'entreprise d'Oracle Fusion Middleware dans Meilleures pratiques MAA - Oracle Fusion Middleware

Familiarisez-vous avec les concepts et l'administration d'Oracle Cloud Infrastructure.

Architecture

Cette architecture présente l'environnement du centre de données principal sur place avec un système de secours sur Oracle Cloud Infrastructure (OCI). Utilisez cette architecture pour une solution hybride de récupération après sinistre pour votre environnement Oracle SOA Suite sur place.

Le système principal est un système Oracle SOA Suite situé sur place. Le système de secours est créé de A à Z dans une location OCI qui utilise Oracle Cloud Infrastructure FastConnect (ou RPV site à site) pour se connecter à l'environnement sur place.

Le niveau intermédiaire sur OCI est créé en installant SOA sur des machines virtuelles OCI et non sur une instance Oracle SOA Cloud Service ou Oracle SOA Suite on Marketplace (il existe des restrictions dans les versions du système d'exploitation, les utilisateurs du système d'exploitation et la structure de répertoires qui empêchent l'instance Oracle SOA Cloud Service ou Oracle SOA Suite on Marketplace de fonctionner correctement en tant que base de secours pour un système sur place).

Le niveau de base de données sur le site OCI est un système de base de données Oracle Real Application Clusters (Oracle RAC).

Description de l'illustration maa-soa-hybrid-dr.png

maa-soa-hybride-dr-oracle.zip

Cette architecture prend en charge les composants suivants dans le centre de données principal sur place :

Réseau sur place
Ce réseau est le réseau local utilisé par votre organisation. C'est l'un des rayons de la topologie.
Équilibreur de charge
Fournit une répartition automatisée du trafic à partir d'un point d'entrée unique vers plusieurs serveurs dorsaux.
Oracle SOA Suite
L'environnement SOA est configuré conformément au Guide de déploiement d'entreprise pour Oracle SOA Suite (EDG). Cette topologie couvre de nombreux composants différents qui sont souvent utilisés dans les déploiements volumineux et met en oeuvre des recommandations de haute disponibilité qui doivent être appliquées avant le déploiement d'un système RS.
Oracle Real Application Clusters (Oracle RAC)
Oracle RAC vous permet d'exécuter une seule base de données Oracle Database sur plusieurs serveurs afin d'optimiser la disponibilité et d'assurer l'extensibilité horizontale, tout en accédant au stockage partagé. Les sessions utilisateur qui se connectent aux instances Oracle RAC peuvent effectuer un basculement et réexécuter les modifications en toute sécurité pendant les pannes, sans apporter de modifications aux applications de l'utilisateur final, en masquant l'impact des pannes pour les utilisateurs finaux.

Cette architecture prend en charge les composants suivants dans l'environnement secondaire de secours sur OCI :

Région
Une région Oracle Cloud Infrastructure est une zone géographique localisée qui contient un ou plusieurs centres de données, appelés domaines de disponibilité. Les régions sont indépendantes les unes des autres, et de grandes distances peuvent les séparer (dans différents pays ou continents).
Réseau en nuage virtuel (VCN) et sous-réseau
Un VCN est un réseau défini par logiciel personnalisable, configuré dans une région Oracle Cloud Infrastructure. Comme les réseaux de centre de données traditionnels, les réseaux en nuage virtuels vous offrent un contrôle complet sur votre environnement de réseau. Un VCN peut disposer de plusieurs blocs CIDR sans chevauchement que vous pouvez modifier après avoir créé le VCN. Vous pouvez segmenter un VCN en sous-réseaux, dont la portée peut concerner une région ou un domaine de disponibilité. Un sous-réseau est constitué d'un intervalle contigu d'adresses qui ne chevauchent pas les autres sous-réseaux dans le réseau en nuage virtuel. Vous pouvez modifier la taille d'un sous-réseau après sa création. Un sous-réseau peut être public ou privé.

Les sous-réseaux privés sont généralement recommandés pour des raisons de sécurité, sauf si la ressource doit être accessible à partir du réseau Internet public (si un équilibreur de charge est accessible à partir du réseau Internet public, il doit être dans un sous-réseau public).
Passerelle de routage dynamique (DRG)
La passerelle DRG est un routeur virtuel qui fournit un chemin pour le trafic réseau privé entre les réseaux en nuage virtuels de la même région, entre un VCN et un réseau en dehors de la région, tel qu'un VCN dans une autre région Oracle Cloud Infrastructure, un réseau sur place ou un réseau d'un autre fournisseur de nuage.
FastConnect
Oracle Cloud Infrastructure FastConnect offre un moyen facile de créer une connexion privée dédiée entre votre centre de données et Oracle Cloud Infrastructure. FastConnect fournit des options de bande passante supérieure et permet une utilisation du réseau plus fiable que les connexions basées sur Internet.
Liste de sécurité
Pour chaque sous-réseau, vous pouvez créer des règles de sécurité qui spécifient la source, la destination et le type de trafic qui doivent être autorisés à entrer et à sortir du sous-réseau.
Table de routage
Les tables de routage virtuelles contiennent des règles pour acheminer le trafic des sous-réseaux vers des destinations en dehors d'un VCN, généralement au moyen de passerelles.
Équilibreur de charge
Le service Oracle Cloud Infrastructure Load Balancing permet une répartition automatisée du trafic à partir d'un point d'entrée unique vers plusieurs serveurs dorsaux.
Protection d'infrastructure en nuage
Vous pouvez utiliser Oracle Cloud Guard pour surveiller et maintenir la sécurité de vos ressources dans Oracle Cloud Infrastructure. Le service de protection d'infrastructure en nuage utilise des recettes de détecteur que vous pouvez définir pour examiner vos ressources afin de détecter les faiblesses en matière de sécurité et pour surveiller les opérateurs et les utilisateurs pour certaines activités risquées. Lorsqu'une mauvaise configuration ou une activité non sécurisée est détectée, le service de protection d'infrastructure en nuage recommande des actions correctives et aide à effectuer ces actions, en fonction des recettes de répondant que vous pouvez définir.
Système de BD
Le système Oracle Database est un service de base de données Oracle Cloud Infrastructure (OCI) qui vous permet de créer, d'adapter et de gérer des bases de données Oracle dotées de fonctions complètes. Le système de base de données utilise le stockage du service de volumes par blocs OCI au lieu du stockage local et peut exécuter Oracle Real Application Clusters (Oracle RAC) pour améliorer la disponibilité.
Service Oracle Cloud Infrastructure File Storage
Le service de stockage de fichiers pour Oracle Cloud Infrastructure fournit un système de fichiers de réseau durable, évolutif, sécurisé et de niveau entreprise. Vous pouvez vous connecter à un système de fichiers du service de stockage de fichiers à partir de toute instance sans système d'exploitation, sur machine virtuelle ou en conteneur de votre réseau en nuage virtuel (VCN). Le service File Storage prend en charge le protocole Network File System version 3.0 (NFSv3). Le service prend en charge le protocole Network Lock Manager (NLM) pour la fonctionnalité de verrouillage de fichier.

Le service de stockage de fichiers d'Oracle Cloud Infrastructure utilise un stockage répliqué à 5 niveaux, situé dans différents domaines d'erreur, pour fournir la redondance et offrir une protection résiliente des données. Les données sont protégées au moyen d'un codage d'élimination. Le service File Storage est conçu pour répondre aux besoins des applications et des utilisateurs qui ont besoin d'un système de fichiers d'entreprise pour un large éventail de cas d'utilisation.
Oracle Cloud Infrastructure Block Volumes
Le service Oracle Cloud Infrastructure Block Volumes vous permet de provisionner et de gérer les volumes de stockage par blocs de façon dynamique. Vous pouvez créer, attacher, connecter, déplacer des volumes et modifier leur performance selon vos besoins en matière de stockage, de performance et d'applications. Une fois un volume attaché et connecté à une instance, vous pouvez l'utiliser comme un disque dur classique.
Système de base de données Oracle RAC
Oracle Real Application Clusters (Oracle RAC) permet aux clients d'exécuter une seule base de données Oracle Database sur plusieurs serveurs pour maximiser la disponibilité et permettre une évolutivité horizontale, tout en accédant au stockage partagé. Les sessions utilisateur qui se connectent aux instances Oracle RAC peuvent effectuer un basculement et réexécuter les modifications en toute sécurité pendant les pannes, sans apporter de modifications aux applications de l'utilisateur final, en masquant l'impact des pannes pour les utilisateurs finaux. L'environnement de haute disponibilité d'Oracle RAC maintient la disponibilité des services en stockant les informations de configuration de chaque service dans Oracle Cluster Registry (OCR).

Le système de base de données Oracle RAC se trouve au niveau de la base de données.
Data Guard
Oracle Data Guard fournit un ensemble complet de services qui créent, tiennent à jour, gèrent et surveillent une ou plusieurs bases de données de secours afin de permettre aux bases de données Oracle de production de rester disponibles sans interruption. Oracle Data Guard tient à jour ces bases de données de secours en tant que copies de la base de données de production. Ensuite, si la base de données de production devient indisponible en raison d'une interruption planifiée ou non planifiée, Oracle Data Guard peut remplacer n'importe quelle base de données de secours par le rôle de production, réduisant ainsi le temps d'arrêt associé à la panne.

Description de la topologie

La topologie de récupération après sinistre hybride d'Oracle SOA Suite utilise un modèle actif-passif. Le système principal se trouve dans un centre de données sur place et le système secondaire se trouve sur Oracle Cloud Infrastructure (OCI). Les réseaux sur place et OCI sont interconnectés avec Oracle Cloud Infrastructure FastConnect (préféré) ou un RPV site à site.

Dans le niveau de base de données, les bases de données principale et secondaire sont configurées avec Oracle Data Guard. Avec Oracle Data Guard, toutes les modifications appliquées à la base de données principale sont répliquées sur la base de données secondaire (de secours).

Le niveau intermédiaire secondaire est installé sur les machines virtuelles OCI. Les fichiers binaires Oracle Fusion Middleware et le domaine SOA sont une réplique des fichiers binaires et du domaine SOA de l'instance principale, à l'aide du service Stockage de fichiers pour Oracle Cloud Infrastructure en tant que solution de système de fichiers réseau, et d'Oracle Cloud Infrastructure Block Volumes en tant que solution de système de fichiers à accès privé au noeud. Les alias de nom d'hôte de l'instance principale sont également utilisés en tant qu'adresses de module d'écoute des serveurs WebLogic dans l'environnement secondaire. Dans l'emplacement secondaire, les alias de nom d'hôte sont résolus avec les adresses IP des hôtes secondaires.

Le niveau Web du centre de données principal suit le modèle Enterprise Deployment Guide (EDG) avec deux hôtes Oracle HTTP Server et un équilibreur de charge (LBR). La même topologie est déployée dans le système secondaire à l'aide d'un équilibreur de charge OCI et d'hôtes Oracle HTTP Server installés sur des instances de calcul OCI. Dans le système secondaire, vous pouvez également mettre en oeuvre la couche Web avec uniquement un équilibreur de charge OCI, qui fournit la plupart des fonctions requises par la topologie de déploiement d'entreprise. Les deux options, seulement l'équilibreur de charge OCI ou l'équilibreur de charge OCI et les hôtes Oracle HTTP Server, sont incluses dans ce document.

Une adresse frontale unique est configurée pour accéder aux applications exécutées dans le système. Le nom frontal virtuel pointe vers l'adresse IP de l'équilibreur de charge sur le site principal. Lors d'une permutation, le nom frontal est mis à jour dans DNS pour pointer vers l'adresse IP de l'équilibreur de charge OCI sur le site secondaire. Il doit toujours pointer vers l'adresse IP de l'équilibreur de charge du site qui a le rôle principal.

Au cours d'un fonctionnement normal, la base de données de secours est une base de secours physique. Il est à l'état de montage ou ouvert en mode lecture seule lorsque Active Data Guard est utilisé. La base de données de secours reçoit et applique redo de la base de données principale, mais ne peut pas être ouverte en mode lecture-écriture. Oracle Data Guard réplique automatiquement les informations qui résident dans la base de données vers le site secondaire, notamment les schémas SOA (architecture orientée serveur), les informations d'Oracle Platform Security Services, les schémas personnalisés, les journaux de transactions (TLOG), les magasins persistants JDBC (connectivité de base de données Java), etc.

Au cours des étapes de configuration de reprise après sinistre et de validation du cycle de vie décrites dans ce document, vous pouvez convertir la base de données de secours d'une base de secours physique en base de secours instantanée pour valider le site secondaire sans effectuer une permutation complète. Une base de données en mode de secours instantané est une base de données entièrement actualisable. Une base de données de secours instantanée reçoit et archive, mais ne s'applique pas, les données redo reçues d'une base de données principale. Toutes les modifications appliquées à une base de secours instantanée sont abandonnées lorsqu'elle est convertie en base de secours physique.

La configuration de domaine WebLogic doit être répliquée du site principal vers le site secondaire. Cette réplication est requise et effectuée lors de la configuration de reprise après sinistre initiale, et elle est également nécessaire pendant le cycle de vie en cours du système. Lorsque des modifications de configuration sont effectuées dans le domaine principal, elles doivent être répliquées vers l'emplacement secondaire.

Lorsqu'une base de secours est arrêtée au cours d'un fonctionnement normal, elle ne reçoit pas de mises à jour de la base principale et peut devenir désynchronisée. Etant donné que cela peut entraîner une perte de données dans un scénario de permutation, il n'est pas recommandé d'arrêter la base de secours pendant le fonctionnement normal de l'entreprise. Les hôtes de niveau intermédiaire de secours peuvent être arrêtés. Toutefois, lorsque les hôtes de secours sont arrêtés, les modifications de configuration qui sont répliquées à partir du site principal ne sont pas poussées vers le domaine secondaire. Dans ce cas, lors d'une permutation, l'objectif de délai de récupération (ODR) est augmenté car les hôtes de niveau intermédiaire de secours doivent être démarrés et le domaine synchronisé avec les modifications principales.

Considérations relatives à la topologie

Voici les hypothèses de topologie les plus pertinentes prises en compte dans cette configuration :

Le système principal est un environnement sur place existant
L'environnement comprend une base de données Oracle Real Application Clusters (Oracle RAC), des hôtes de niveau intermédiaire et un équilibreur de charge. La configuration du système sur place ne fait pas partie de la portée de ce document.
Le système secondaire se trouve sur Oracle Cloud Infrastructure (OCI)
Le système secondaire est créé à partir de zéro sur OCI et fournit une version Oracle Cloud de votre système sur place. Il s'agit d'un système Oracle Cloud entièrement standard pouvant devenir le système principal.
Oracle SOA Suite et composants
Ce document est axé sur le système Oracle SOA Suite, y compris ses composants. Par exemple, Oracle Service Bus, Oracle Business Process Management, Oracle Enterprise Scheduler Service, etc. Bien que les procédures et recommandations de ce document puissent s'appliquer à d'autres composants Oracle Fusion Middleware qui ne font pas partie d'Oracle SOA Suite (tels que Web Center et Business Intelligence), les spécificités et la prise en charge de ces composants sont exclues de cet exercice.
Les systèmes principal et secondaire sont symétriques
Le système secondaire a le même nombre de noeuds dans le niveau intermédiaire, le niveau Web et le niveau de base de données. Il peut y avoir des différences dans la couche de niveau Web lorsque l'équilibreur de charge OCI est utilisé seul dans OCI (sans Oracle HTTP Server).
Les systèmes principal et secondaire utilisent des ressources similaires
Bien que les formes OCI disponibles ne correspondent peut-être pas aux mêmes valeurs exactes d'UC et de mémoire de la configuration principale existante, vous devez utiliser les formes les plus similaires. Oracle recommande d'utiliser des bases de secours symétriques qui fournissent une puissance de traitement similaire au système principal. Sinon, des problèmes de performance et des erreurs en cascade pourraient survenir lorsque la charge de travail est transférée au système OCI.

Points à considérer pour le réseau

Tenez compte des éléments suivants lors de la configuration du réseau :

Connectivité entre le réseau sur place et Oracle Cloud Infrastructure (OCI)
Les bases de données sur place et OCI doivent communiquer entre elles au moyen du module d'écoute Oracle SQL*Net (port 1521) pour le transport redo d'Oracle Data Guard. Les hôtes de niveau intermédiaire sur place et OCI doivent communiquer entre eux à l'aide du port SSH (pour les copies rsync). Oracle recommande d'utiliser la communication Oracle Cloud Infrastructure FastConnect entre le centre de données sur place et la région OCI. Oracle Cloud Infrastructure FastConnect fournit une connectivité et une bande passante sécurisées dédiées, avec une latence, une gigue et des coûts prévisibles. Vous pouvez également utiliser un RPV site à site, qui fournit également une connectivité sécurisée entre un réseau sur place et OCI. Cependant, cela fournit une bande passante plus faible, ainsi qu'une latence, une gigue et un coût variables.
Désactiver la connectivité entre les hôtes de niveau intermédiaire et la base de données distante
Il est prévu que les hôtes de niveau intermédiaire ne se connectent jamais à la base de données distante lors de l'exécution. La latence entre les applications sur place et OCI décourage généralement cette interconnexion. Pour éviter les connexions accidentelles et les problèmes de charge de travail, excluez la connectivité des hôtes de niveau intermédiaire à la base de données distante.
Noms d'hôte virtuel
À titre de meilleure pratique, il est supposé que le système sur place principal utilise des noms d'hôte virtuel, au lieu du nom d'hôte du noeud physique, comme adresses d'écoute pour les Oracle WebLogic Server. Les noms d'hôte virtuel sont normalement des alias du nom d'hôte du noeud physique. L'utilisation de noms d'hôte virtuel facilite le déplacement des configurations vers différents hôtes, mais ce n'est pas une exigence obligatoire. La configuration dans ce document fonctionne tant que les serveurs secondaires dans OCI peuvent utiliser les noms d'hôte utilisés comme adresses d'écoute dans l'instance principale en tant qu'alias dans chaque noeud (comme résolu dans DNS ou /etc/hosts local).
Une adresse IP virtuelle est requise uniquement pour l'adresse d'écoute du serveur d'administration
La migration automatique de services est prise en charge et recommandée pour la haute disponibilité locale, ce qui signifie que les serveurs gérés ne sont pas tenus d'utiliser des adresses IP virtuelles. Seul le serveur d'administration a besoin d'une adresse IP virtuelle pour le basculement local. À titre de meilleure pratique, il est supposé que le serveur d'administration du système sur place principal écoute une adresse IP virtuelle. Ce document fournit des instructions pour configurer une adresse IP virtuelle pour le serveur d'administration dans OCI. Toutefois, cette adresse IP virtuelle n'est pas une exigence difficile pour configurer la récupération après sinistre sur OCI avec ce document. Si votre serveur d'administration principal n'écoute pas dans une adresse IP virtuelle, vous pouvez ignorer ce point.
Équilibreur de charge
Un équilibreur de charge frontal est utilisé dans l'environnement sur place principal et un équilibreur de charge OCI est utilisé dans l'environnement de secours.
Adresse virtuelle frontale
Le système principal doit utiliser un nom frontal virtuel (URL personnalisée, par exemple mysoa.example.com) comme point d'entrée pour les clients. Ce nom frontal est résolu dans le DNS avec l'adresse IP de l'équilibreur de charge principal. Dans une topologie de récupération après sinistre, le système secondaire est configuré pour utiliser le même nom frontal virtuel. Lorsqu'une permutation ou un basculement vers le système secondaire se produit, le nom frontal virtuel est modifié dans le DNS pour pointer vers l'adresse IP de l'équilibreur de charge secondaire. De cette façon, l'accès des clients au système est indépendant du site utilisé comme principal. Il en va de même pour tout nom frontal virtuel utilisé dans le système. Par exemple, vous pouvez utiliser un nom frontal supplémentaire, tel que admin.example.com, pour accéder aux fonctions d'administration de la console d'administration d'Oracle WebLogic Server ou de la console Fusion Middleware Control.

Vous pouvez utiliser un nom frontal séparé, par exemple osb.example.com, pour accéder aux services Oracle Service Bus. Ce document utilise un nom d'hôte frontal pour simplifier.

Considérations relatives au stockage

Tenez compte des éléments suivants lors de la configuration du stockage :

Structure de répertoires basée sur EDG
Ce document utilise une structure de répertoires Enterprise Deployment Guide (EDG) pour la configuration du domaine Oracle WebLogic Server du système principal. Le modèle EDG utilise des répertoires de domaine distincts pour l'administration Oracle WebLogic Server et pour chaque Oracle WebLogic Server géré, comme décrit dans Préparation du système de fichiers pour un déploiement d'entreprise. La structure du répertoire EDG est utilisée comme référence dans les exemples. Il utilise une combinaison de dossiers partagés et privés, qui couvre plus de cas d'utilisation. Si votre système n'utilise pas la structure de répertoires EDG, adaptez les exemples pour répondre aux spécificités de votre environnement.
Considérations sur le stockage dans l'instance principale (sur place)
Il est recommandé de stocker non seulement les dossiers partagés (répertoire du domaine du serveur d'administration Oracle WebLogic Server, répertoire de base des plans de déploiement, environnement d'exécution partagé, etc.), mais aussi les fichiers binaires du répertoire de base d'Oracle Fusion Middleware et les configurations locales (répertoires de domaines de serveur géré, dossier du gestionnaire de noeuds) sur le stockage NFS à l'emplacement principal. Cela facilite la copie de la base principale vers la base de secours. Bien que chaque hôte utilise ses propres fichiers binaires et sa propre configuration locale en privé (volumes NFS séparés pour chaque serveur), la copie de la configuration entre les sites est plus facile si ceux-ci résident sur le stockage partagé. En utilisant cette approche, il est possible de les monter tous à partir d'un noeud unique et d'exécuter la copie rsync sur les noeuds distants en une seule opération. Sans cette approche, la copie doit être effectuée individuellement, à partir de chacun des noeuds principaux qui stockent les données en privé.

Note :
Les scripts fournis pour la copie rsync de ceux-ci sont suffisamment flexibles pour être adaptés à tous les cas.
Considérations relatives aux dossiers partagés dans l'OCI secondaire
Les dossiers qui doivent être partagés entre les hôtes de niveau intermédiaire (par exemple, le répertoire du domaine du serveur d'administration d'Oracle WebLogic Server, le répertoire de base des plans de déploiement, l'exécution partagée, etc.) doivent être stockés dans le stockage partagé. OCI fournit le service Stockage de fichiers pour Oracle Cloud Infrastructure en tant que solution de système de fichiers réseau.
Les différents artefacts sont des dossiers partagés, et leur utilisation et leur cycle de vie sont différents. Ils doivent être placés dans un espace de stockage partagé séparé, en fonction de leur utilisation. Par exemple :
- La configuration partagée (par exemple, répertoire du domaine du serveur d'administration WebLogic Server et répertoire de base des plans de déploiement) est principalement accessible par l'hôte du serveur d'administration. Le reste des hôtes y accède (pour les plans de déploiement, les magasins de clés partagés, etc.). Cela doit être placé dans un système de fichiers du service de stockage de fichiers pour Oracle Cloud Infrastructure.
- Si le système utilise un dossier partagé pour les artefacts d'exécution (par exemple, les fichiers créés et lus par l'application), il est normalement utilisé simultanément par tous les hôtes de niveau intermédiaire. Vous devez placer les artefacts d'exécution dans un autre système de fichiers du service de stockage de fichiers pour Oracle Cloud Infrastructure ou dans un montage de système de fichiers de base de données (DBFS).
Considérations relatives au stockage des dossiers privés dans le serveur secondaire (OCI)
Les binaires FMW et les configurations locales sont utilisés individuellement par chaque hôte. Il est recommandé de les stocker sur un stockage externe plutôt que dans le volume de démarrage par défaut des hôtes.
- Dans OCI, vous pouvez stocker les binaires FMW dans Oracle Cloud Infrastructure Block Volumes pour chaque hôte. Lorsqu'il y a plus de deux hôtes de niveau intermédiaire, il est recommandé d'utiliser des répertoires de base binaires partagés redondants (voir le guide sur la haute disponibilité). Pour ce faire, utilisez le service Stockage de fichiers pour Oracle Cloud Infrastructure pour stocker les fichiers binaires FMW.
- Vous pouvez stocker la configuration locale (par exemple, les répertoires de domaines de serveur géré WebLogic et le dossier du gestionnaire de noeuds) dans Oracle Cloud Infrastructure Block Volumes, car ils doivent être utilisés de manière privée par chaque hôte. Vous pouvez également utiliser les systèmes de fichiers du service Stockage de fichiers pour Oracle Cloud Infrastructure montés de manière privée par chaque noeud.
Pour faciliter la copie du site principal vers le site distant, il est possible de monter les fichiers de stockage à partir d'un noeud unique et d'exécuter la copie rsync en une seule opération (pour les volumes par blocs, un autre hôte peut monter les fichiers en mode lecture seule). Alternativement, la copie peut être effectuée individuellement, à partir de chacun des noeuds qui stockent les données en privé.

Note :
Les scripts fournis pour la copie rsync de ceux-ci sont suffisamment flexibles pour être adaptés à tous les cas.
Réplication du stockage
Il n'y a pas de réplication directe au niveau du stockage entre les systèmes sur place et OCI. La copie des fichiers binaires et de la configuration de la base principale à la base de secours est effectuée avec rsync au moyen de SSH (Secure Shell) au moyen d'une connexion privée sur Oracle Cloud Infrastructure FastConnect ou d'un RPV site à site (n'utilisez jamais l'Internet public). La copie des artefacts de configuration et d'exécution peut également être basée sur DBFS, selon les besoins du client. Plus de détails à ce sujet seront fournis ultérieurement.
WebLogic magasins persistants
Il est supposé que les magasins persistants WebLogic utilisés pour les messages TLOGS et JMS sont des magasins persistants JDBC et sont stockés dans des tables de base de données. De cette façon, les magasins persistants sont accessibles à partir de n'importe quel membre de la grappe (pour fournir une haute disponibilité locale avec la migration de service). Cela tire également parti d'Oracle Data Guard sous-jacent, qui réplique automatiquement les journaux TLOGS et JMS vers le site secondaire.

Points à considérer pour la base de données

Tenez compte des points suivants lors de la configuration des bases de données :

Multilocation
La base de données principale doit être une base de données colocative (base de données conteneur/base de données enfichable). Cela est nécessaire pour configurer un service Oracle Data Guard hybride dans Oracle Cloud Infrastructure.
Niveaux de correctif
Le répertoire de base Oracle pour la base de données sur place doit être au même niveau de correctif que la base de données de secours.
Chiffrement transparent des données
Utilisez le chiffrement transparent des données (TDE) pour les bases de données principale et de secours afin de vous assurer que toutes les données sont chiffrées. Si la base de données sur place n'est pas déjà activée avec TDE, il est fortement recommandé de la convertir en TDE avant de configurer Oracle Data Guard pour fournir l'environnement le plus sécurisé.
Haute disponibilité
Pour obtenir la haute disponibilité locale au niveau de la base de données et suivre la topologie EDG, utilisez Oracle Real Application Clusters (Oracle RAC) pour les bases de données principale et de secours. Bien que axée sur Oracle RAC, cette procédure s'applique à une seule base de données. Toutefois, il est recommandé d'utiliser Oracle RAC pour obtenir la haute disponibilité locale dans le niveau de base de données.
Service de base de données
Le niveau intermédiaire (middle tier) sur place principal doit utiliser un service de base de données d'application pour se connecter à la base principale.
Système de base de données Oracle Cloud Infrastructure (OCI)
Utilisez un système de base de données OCI (sans système d'exploitation, sur machine virtuelle ou Oracle Exadata Database Service) comme base de données de secours. Une base de données Oracle Autonomous Database, partagée ou dédiée, ne fait pas partie de la portée de ce document. Il ne fournit pas un certain nombre de fonctions requises pour la configuration de récupération après sinistre hybride, telles que la possibilité de configurer Oracle Data Guard avec une base de données sur place et la conversion de base de secours instantanée.
Alias TNS dans les chaînes de connexion à la base de données WebLogic
Ce document utilise un alias TNS pour définir la chaîne de connexion à la base de données dans la configuration Oracle WebLogic. L'alias TNS est résolu avec un fichier tnsnames.ora, qui est différent dans chaque site et pointe vers la base de données locale. Comme le même nom d'alias est utilisé dans la configuration principale et secondaire, vous n'avez pas besoin de modifier la configuration WebLogic après l'avoir répliquée de la configuration principale vers la configuration secondaire.

Si la principale n'utilise pas déjà cette approche, une configuration unique initiale est requise. Les détails à ce sujet sont décrits plus loin dans ce document.

Considérations relatives à la gestion des identités

Tenez compte des éléments suivants lors de la configuration de la gestion des identités :

Protocole LDAP
Le système peut utiliser un LDAP externe pour l'authentification (par exemple, Oracle Unified Directory), à condition que le LDAP externe soit accessible à partir des systèmes principal et de secours.
Solution de récupération après sinistre pour LDAP
La solution de récupération après sinistre pour tout service LDAP externe n'est pas incluse dans le présent document et doit être fournie par le produit LDAP spécifique. La solution de récupération après sinistre pour LDAP doit fournir un moyen unique d'y accéder (généralement un nom d'hôte virtuel), qui ne change pas lors d'une permutation dans le système LDAP.

Sommaire des considérations

Ce qui suit fournit un résumé de ce que vous devez considérer lors de la planification d'une solution de reprise après sinistre.

Points à considérer pour	Sommaire	Obligatoire ou hautement recommandé
Topologie	Le système principal est un environnement sur place existant.	Hautement recommandé
Topologie	Le système secondaire se trouve sur Oracle Cloud Infrastructure (OCI) est créé à partir de zéro sur OCI.	obligatoire;
Topologie	Les systèmes principal et secondaire sont symétriques et ont le même nombre de noeuds dans le niveau de base de données, le niveau intermédiaire et le niveau Web.	obligatoire;
Topologie	Le niveau Web principal est constitué d'un équilibreur de charge devant Oracle HTTP Server.	Hautement recommandé
Topologie	Les systèmes principal et secondaire utilisent des ressources similaires (UC, mémoire, etc.).	obligatoire;
Réseau	Utilisez OCI FastConnect pour la connectivité entre les services sur place et OCI, ou RPV site à site. Jamais internet public.	obligatoire;
Réseau	Désactivez la connectivité entre les hôtes de niveau intermédiaire et la base de données distante. Nécessaire uniquement si le système de fichiers Oracle Database (DBFS) est utilisé pour la réplication de la configuration.	Hautement recommandé
Réseau	Utilisez des noms d'hôte virtuel pour les adresses d'écoute du serveur WebLogic.	Hautement recommandé
Réseau	Adresse IP virtuelle du serveur d'administration.	Hautement recommandé
Réseau	Adresse virtuelle frontale.	obligatoire;
Stockage de stockage	structure de répertoires fondée sur le groupe de données informatisées;	Hautement recommandé
Stockage de stockage	Dossiers privés et partagés sur place dans un stockage externe afin qu'ils puissent être montés à partir d'un noeud unique pour centraliser les opérations rsync.	Hautement recommandé
Stockage de stockage	Configuration partagée OCI dans le service de stockage de fichiers pour Oracle Cloud Infrastructure.	obligatoire;
Stockage de stockage	Environnement d'exécution partagé OCI dans le service de stockage de fichiers OCI ou le système de fichiers Oracle Database (DBFS).	obligatoire;
Stockage de stockage	Les dossiers binaires FMW OCI dans le service de stockage de fichiers OCI sont montés de manière privée.	Hautement recommandé
Stockage de stockage	Configurations locales OCI dans Oracle Cloud Infrastructure Block Volumes (autrement dit, le service de stockage de fichiers OCI est monté privé).	Hautement recommandé
Stockage de stockage	Montage DBFS intermédiaire (uniquement lorsque la réplique basée sur DBFS pour la configuration est utilisée).	Hautement recommandé
Stockage de stockage	Réplication du stockage basée sur `rsync` (ou DBFS pour certains artefacts spécifiques tels que la configuration).	Hautement recommandé
Stockage de stockage	WebLogic magasins persistants (TLOGS, JMS) dans les magasins persistants JDBC.	Obligatoire (*si les informations JMS sont pertinentes)
Base de données	Le niveau de correctif de la base de données sur place est identique à celui de la base de données de secours.	obligatoire;
Base de données	Chiffrement transparent des données (TDE) pour les bases de données principale et de secours. Si la base de données sur place n'est pas déjà activée avec TDE, il est fortement recommandé de la convertir en TDE avant de configurer Oracle Data Guard.	obligatoire;
Base de données	Base de données Oracle RAC pour haute disponibilité locale.	Hautement recommandé
Base de données	Base de données multilocataire principale.	obligatoire;
Base de données	Utilisez un service de base de données d'application, et non le service d'administration par défaut, pour vous connecter à la base de données.	obligatoire;
Base de données	Dans OCI, utilisez un système de base de données (BM, VM ou Oracle Exadata Database Service), et non Oracle Autonomous Database.	obligatoire;
Base de données	Alias TNS dans les chaînes de connexion à la base de données WebLogic.	Hautement recommandé
Gestion des identités	Le système peut utiliser un LDAP externe pour l'authentification (par exemple, Oracle Unified Directory), à condition que le LDAP externe soit accessible à partir des systèmes principal et de secours.	Obligatoire (l'utilisation d'un LDAP externe n'est PAS obligatoire, mais s'il est utilisé, il doit être accessible à partir des deux sites)
Gestion des identités	La solution de récupération après sinistre pour tout service LDAP externe n'est pas incluse dans le présent document et doit être fournie par le produit LDAP spécifique. La solution de récupération après sinistre pour LDAP doit fournir un moyen unique d'y accéder (généralement un nom d'hôte virtuel), qui ne change pas lors d'une permutation dans le système LDAP.	Obligatoire (l'utilisation d'un LDAP externe n'est PAS obligatoire, mais s'il est utilisé et protégé contre la reprise après sinistre, il doit fournir une adresse d'accès virtuel qui reste la même lorsqu'une permutation ou un basculement se produit pour la façon LDAP d'y accéder)

À propos des rôles et services requis

Cette solution nécessite les services et les rôles suivants :

Il s'agit des rôles nécessaires pour chaque service.

Nom du service : Rôle	Obligatoire pour...
Oracle Cloud Infrastructure : `administrator`	Créez les ressources requises dans la location OCI : compartiment, système de base de données, instances de calcul, ressources FSS et équilibreur de charge.
Réseau : `administrator`	Configurez les ressources de réseau requises à la fois sur place et dans OCI : Connexion rapide, réseaux en nuage virtuels et sous-réseaux dans OCI, règles de sécurité de réseau et règles de routage.
Oracle Data Guard : `root`, `oracle` et `sysdba`	Configurez Oracle Data Guard entre OCI principal sur place et de secours et effectuez des conversions de rôle.
Oracle Database : `sysdba`	Gérez les bases de données.
Oracle WebLogic Server : `root`, `oracle`	Configurez les hôtes de niveau intermédiaire selon les besoins : effectuez la configuration au niveau du système d'exploitation, ajoutez des alias d'hôte, gérez les adresses IP virtuelles et montez les systèmes de fichiers.
Oracle WebLogic Server : `Weblogic Administrator`	Gérer Oracle WebLogic Server : Arrêter, démarrer et appliquer les modifications de configuration WebLogic.

Voir https://docs.oracle.com/pls/topic/lookup?ctx=en/solutions/soa-dr-on-cloud&id=GCSSL pour obtenir les services en nuage dont vous avez besoin.