Configurer une solution de récupération après sinistre hybride pour Oracle SOA Suite

Avant de commencer

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

Le système Oracle WebLogic Server utilisé dans ce document est un environnement haute disponibilité configuré conformément aux meilleures pratiques MAA standard décrites dans le Guide de déploiement Enterprise pour Oracle SOA Suite (EDG) pour les systèmes Fusion Middleware. Bien que tous les scénarios ne suivent pas exactement cette topologie, elle couvre de nombreux composants et combinaisons, elle est fréquemment utilisée dans les déploiements de grande envergure et implémente des recommandations de haute disponibilité qui doivent être appliquées avant le déploiement d'un système de récupération après sinistre. Il est donc 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. Sur cette base, il est fortement recommandé de se familiariser avec les meilleures pratiques de déploiement d'entreprise et de haute disponibilité d'Oracle WebLogic Server pour la configuration du réseau, du stockage et de l'hôte avant de déployer un système hybride.

Pour plus de détails, reportez-vous aux sections suivantes :

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

Veillez également à vous familiariser avec les concepts et l'administration d'Oracle Cloud Infrastructure.

Architecture

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

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

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

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'image maa-soa-hybrid-dr.png

maa-soa-hybrid-dr-oracle.zip

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

Réseau sur site
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 du back-end.
Oracle SOA Suite
L'environnement SOA est configuré conformément au Guide de déploiement d'entreprise standard pour Oracle SOA Suite (EDG). Cette topologie couvre de nombreux composants différents qui sont souvent utilisés dans des déploiements de grande envergure et implémente des recommandations de haute disponibilité qui doivent être appliquées avant de déployer un système de récupération après sinistre.
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 de permettre une évolutivité horizontale, tout en accédant au stockage partagé. Les sessions utilisateur se connectant à des instances Oracle RAC peuvent basculer et réexécuter les modifications en toute sécurité pendant les pannes, sans aucune modification des applications utilisateur final, ce qui masque l'impact des pannes des utilisateurs finaux.

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

Région
Une région Oracle Cloud Infrastructure est une zone géographique précise, incluant 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 (entre les pays ou même les continents).
Réseau cloud virtuel (VCN) et sous-réseau
Un VCN est un réseau personnalisable défini par logiciel que vous configurez dans une région Oracle Cloud Infrastructure. Comme les réseaux de centre de données traditionnels, les réseaux cloud virtuels vous donnent un contrôle total sur l'environnement réseau. Un réseau cloud virtuel peut comporter plusieurs blocs CIDR qui ne se chevauchent pas et que vous pouvez modifier après l'avoir créé. Vous pouvez segmenter un réseau cloud virtuel en plusieurs sous-réseaux ciblant une région ou un domaine de disponibilité. Chaque sous-réseau est composé d'une plage contiguë d'adresses qui ne chevauchent pas celles des autres sous-réseaux du réseau cloud 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é, à moins que la ressource ne soit accessible à partir du réseau Internet public (si un équilibreur de charge est accessible à partir du réseau Internet public, il doit se trouver dans un sous-réseau public).
Passerelle de routage dynamique
Le DRG est un routeur virtuel qui fournit un chemin pour le trafic de réseau privé entre les réseaux cloud 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 site ou un réseau dans un autre fournisseur cloud.
FastConnect
Oracle Cloud Infrastructure FastConnect permet de créer facilement une connexion privée dédiée entre le centre de données et Oracle Cloud Infrastructure. FastConnect offre des options de bande passante plus élevée et une expérience de réseau plus fiable par rapport aux connexions Internet.
Liste de sécurité
Pour chaque sous-réseau, vous pouvez créer des règles de sécurité qui indiquent 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 via des passerelles.
Equilibreur de charge
Le service Oracle Cloud Infrastructure Load Balancing fournit une distribution automatisée du trafic à partir d'un point d'entrée unique vers plusieurs serveurs dans le back-end.
Cloud Guard
Vous pouvez utiliser Oracle Cloud Guard pour surveiller et maintenir la sécurité de vos ressources dans Oracle Cloud Infrastructure. Cloud Guard utilise des recettes de détecteur que vous pouvez définir pour examiner les faiblesses de sécurité de vos ressources et pour surveiller les opérateurs et les utilisateurs afin de détecter certaines activités à risque. Lorsqu'une erreur de configuration ou une activité non sécurisée est détectée, Cloud Guard recommande des actions correctives et vous aide à effectuer ces actions, en fonction des recettes de répondeur que vous pouvez définir.
Système de base de données
Oracle Database System est un service de base de données Oracle Cloud Infrastructure (OCI) qui vous permet de créer, de redimensionner et de gérer des bases de données Oracle complètes. Le système de base de données utilise le stockage OCI Block Volumes 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 Oracle Cloud Infrastructure File Storage offre un système de fichiers réseau durable, évolutif, sécurisé et adapté à l'entreprise. Vous pouvez vous connecter à un système de fichiers de service File Storage à partir de n'importe quelle instance Bare Metal, de machine virtuelle ou de conteneur dans votre réseau cloud virtuel (VCN). Le service File Storage prend en charge le protocole 3.0 (NFSv3). Le service prend en charge le protocole NLM (Network Lock Manager) pour la fonctionnalité de verrouillage de fichier.

Oracle Cloud Infrastructure File Storage utilise un stockage répliqué dans 5 directions, dans différents domaines de pannes, afin de fournir une redondance pour une protection résiliente des données. Les données sont protégées par un encodage d'effacement. Le service File Storage est conçu pour répondre aux besoins des applications et utilisateurs qui nécessitent un système de fichiers d'entreprise pour de nombreux cas d'emploi.
Oracle Cloud Infrastructure Block Volumes
Le service Oracle Cloud Infrastructure Block Volumes permet de provisionner et de gérer les volumes de stockage de blocs de façon dynamique. Vous pouvez créer, attacher, connecter et déplacer des volumes, ainsi que modifier leurs performances, si nécessaire, afin de répondre à vos exigences en matière de stockage, de performances et d'application. 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 afin d'optimiser la disponibilité et de permettre une évolutivité horizontale, tout en accédant au stockage partagé. Les sessions utilisateur se connectant à des instances Oracle RAC peuvent basculer et réexécuter les modifications en toute sécurité pendant les pannes, sans aucune modification des applications utilisateur final, ce qui masque l'impact des pannes des utilisateurs finaux. La structure haute disponibilité d'Oracle RAC assure 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 permettant de créer, de maintenir, de gérer et de surveiller des bases de données de secours afin que les bases de données Oracle de production restent disponibles sans interruption. Oracle Data Guard gère 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 panne planifiée ou non, Oracle Data Guard peut basculer n'importe quelle base de données de secours vers le rôle de production, ce qui réduit le temps d'inactivité associé à la panne.

Description de la topologie

La topologie de récupération après sinistre hybride Oracle SOA Suite utilise un modèle actif-passif. Le système principal se trouve dans un centre de données sur site et le système secondaire se trouve sur Oracle Cloud Infrastructure (OCI). Les réseaux sur site et OCI sont interconnectés avec Oracle Cloud Infrastructure FastConnect (préféré) ou un VPN 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 des machines virtuelles OCI. Les fichiers binaires Oracle Fusion Middleware et le domaine SOA sont une réplique des fichiers binaires du principal et du domaine SOA, utilisant le service Oracle Cloud Infrastructure File Storage en tant que solution de système de fichiers réseau et Oracle Cloud Infrastructure Block Volumes en tant que solution de système de fichiers d'accès privé au noeud. Les alias de nom d'hôte du serveur principal sont également utilisés comme adresses de processus 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 dans le 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 implémenter la couche Web avec uniquement un équilibreur de charge OCI, qui fournit la plupart des fonctionnalités requises par la topologie de déploiement d'entreprise. Les deux options, uniquement OCI Load Balancer ou OCI Load Balancer et les hôtes Oracle HTTP Server, sont incluses dans ce document.

Une adresse frontale unique est configurée pour accéder aux applications en cours d'exécution 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.

Pendant le fonctionnement normal de l'entreprise, la base de données de secours est une base de données 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 à partir 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 (Server Oriented Architecture), les informations Oracle Platform Security Services, les schémas personnalisés, les journaux de transactions (TLOG), les emplacements de stockage persistants JDBC (Java Database Connectivity), etc.

Au cours des étapes de configuration de la récupération 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 données de secours physique en base de données de secours instantanée pour valider le site secondaire sans effectuer de permutation complète. Une base de données en mode de secours instantanée est une base de données entièrement actualisable. Une base de données de secours cliché 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 données de secours instantanée sont ignorées lorsqu'elles sont converties en base de données 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 initiale de la récupération après sinistre, et est également nécessaire pendant le cycle de vie continu 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 données de secours est arrêtée pendant le fonctionnement normal de l'entreprise, elle ne reçoit pas les mises à jour de la base de données principale et risque de ne plus être 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 données 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 répliquées à partir du site principal ne sont pas propagées vers le domaine secondaire. Dans ce cas, lorsqu'une permutation se produit, l'objectif de délai de récupération (RTO) 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.

Remarques concernant 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 site existant
L'environnement inclut 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 site n'est pas traitée dans ce document.
Le système secondaire est sur Oracle Cloud Infrastructure (OCI)
Le système secondaire est créé de toutes pièces sur OCI et fournit une version Oracle Cloud de votre système sur site. Il s'agit d'un système Oracle Cloud entièrement standard avec la possibilité de 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 capacité de prise en charge de ces composants sont exclues de cet exercice.
Les systèmes primaire et secondaire sont symétriques
Le système secondaire a le même nombre de nœuds 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 dans l'UC et la 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 à celle du système principal. Sinon, des problèmes de performances et des pannes en cascade peuvent survenir lorsque la charge globale est basculée vers le système OCI.

Remarques concernant le réseau

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

Connectivité entre le réseau sur site et Oracle Cloud Infrastructure (OCI)
Les bases de données sur site et OCI doivent communiquer entre elles via le processus d'écoute Oracle SQL*Net (port 1521) pour le transport Oracle Data Guard redo. Les hôtes sur site et de niveau intermédiaire 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 site et la région OCI. Oracle Cloud Infrastructure FastConnect offre une connectivité et une bande passante sécurisées dédiées, avec une latence, une gigue et un coût prévisibles. Vous pouvez également utiliser un VPN site à site, qui fournit également une connectivité sécurisée entre OCI et sur site. Cependant, cela fournit une bande passante plus faible, ainsi qu'une latence variable, une gigue et un coût.
Désactiver la connectivité entre les hôtes de niveau intermédiaire et la base de données distante
Les hôtes de niveau intermédiaire ne se connecteront jamais à la base de données distante lors de l'exécution. La latence entre OCI et sur site décourage généralement cette connectivité croisée. Pour éviter les connexions accidentelles et les problèmes de charge globale, excluez la connectivité entre les hôtes de niveau intermédiaire et la base de données distante.
Noms d'hôte virtuel
Il est recommandé de considérer que le système sur site principal utilise des noms d'hôte virtuels, au lieu du nom d'hôte de noeud physique, comme adresses d'écoute pour les serveurs 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 de configurations vers différents hôtes. Cependant, cela n'est pas obligatoire. La configuration de ce document fonctionne tant que les serveurs secondaires dans OCI peuvent utiliser les noms d'hôte utilisés comme adresses d'écoute dans le noeud principal en tant qu'alias dans chaque noeud (tel que résolu dans DNS ou /etc/hosts local).
Une adresse IP virtuelle est uniquement requise pour l'adresse d'écoute du serveur d'administration.
La migration automatique des 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. Il est recommandé de considérer que le serveur d'administration du système sur site principal écoute une adresse IP virtuelle. Ce document fournit des instructions pour la configuration d'une adresse IP virtuelle pour le serveur d'administration dans OCI. Cependant, cette adresse IP virtuelle n'est pas obligatoire pour configurer Disaster Recovery sur OCI avec ce document. Si votre serveur d'administration principal n'écoute pas dans une adresse IP virtuelle, vous pouvez ignorer ce point.
Equilibreur de charge
Un équilibreur de charge frontal (LBR) est utilisé dans l'environnement sur site principal et un équilibreur de charge OCI est utilisé dans l'environnement de secours.
Adresse front-end virtuelle
Le système principal doit utiliser un nom frontal virtuel (URL personnalisée, telle que mysoa.example.com) comme point d'entrée pour les clients. Ce nom frontal est résolu dans 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 site 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 Oracle WebLogic Server ou de la console Fusion Middleware Control.

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

Remarques concernant le stockage

Tenez compte des points suivants lors de la configuration du stockage :

Structure de répertoires basée sur EDG
Ce document utilise une structure de répertoires EDG (Enterprise Deployment Guide) pour la configuration de domaine Oracle WebLogic Server du système principal. Le modèle EDG utilise des répertoires de domaine distincts pour l'administration d'Oracle WebLogic Server et pour chaque instance Oracle WebLogic Server gérée, comme décrit dans Préparation du système de fichiers pour un déploiement Enterprise. La structure de répertoires EDG est utilisée comme référence dans les exemples. Il utilise une combinaison de dossiers partagés et privés, ce qui couvre davantage de cas d'utilisation. Si votre système n'utilise pas la structure de répertoires EDG, adaptez les exemples en fonction des spécificités de votre environnement.
Remarques concernant le stockage en mode principal (sur site)
Il est recommandé de stocker non seulement les dossiers partagés (répertoire de domaine du serveur d'administration Oracle WebLogic Server, répertoire de base des plans de déploiement, exécution partagée, etc.), mais également les fichiers binaires du répertoire de base Oracle Fusion Middleware et les configurations locales (répertoires de domaine du 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 données de secours. Bien que chaque hôte utilise ses propres fichiers binaires et sa propre configuration locale de manière privée (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 un 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 vers les noeuds distants en une seule opération. Sans cette approche, la copie doit avoir lieu individuellement, à partir de chacun des noeuds principaux qui stockent les données en privé.

Remarques :
Les scripts fournis pour la copie rsync de ceux-ci sont suffisamment flexibles pour être adaptés à tous les cas.
Remarques concernant les dossiers partagés dans le secondaire (OCI)
Les dossiers qui doivent être partagés entre les hôtes de niveau intermédiaire (par exemple, le répertoire de domaine du serveur d'administration 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 Oracle Cloud Infrastructure File Storage 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 stockage partagé séparé, en fonction de leur utilisation. Exemple :
- La configuration partagée (par exemple, le répertoire de domaine du serveur d'administration WebLogic Server et le répertoire de base des plans de déploiement) est principalement accessible par l'hôte du serveur d'administration. Il est accessible de manière résiduelle par le reste des hôtes (pour les plans de déploiement, les fichiers de clés partagés, etc.). Elle doit être placée dans un système de fichiers Oracle Cloud Infrastructure File Storage.
- 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 Oracle Cloud Infrastructure File Storage ou dans un montage de système de fichiers de base de données (DBFS).
Remarques concernant le stockage de dossiers privés dans l'instance secondaire (OCI)
Les fichiers binaires FMW et les configurations locales sont utilisés par chaque hôte individuellement. Il est recommandé de les stocker sur un stockage externe plutôt que dans le volume d'initialisation 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 existe plus de deux hôtes de niveau intermédiaire, il est recommandé d'utiliser des répertoires de base binaires partagés redondants (reportez-vous au guide de haute disponibilité). Pour ce faire, utilisez Oracle Cloud Infrastructure File Storage pour stocker les fichiers binaires FMW.
- Vous pouvez stocker la configuration locale (par exemple, les répertoires de domaine de serveur géré WebLogic et le dossier de 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 des systèmes de fichiers Oracle Cloud Infrastructure File Storage 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 de blocs, un autre hôte peut monter les fichiers en mode lecture seule). Sinon, la copie peut être effectuée individuellement, à partir de chacun des noeuds qui stockent les données en privé.

Remarques :
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'existe pas de réplication directe au niveau du stockage entre OCI et sur site. La copie des fichiers binaires et de la configuration de la base de données principale vers la base de données de secours est effectuée avec rsync via SSH (Secure Shell) via une connexion privée sur Oracle Cloud Infrastructure FastConnect ou un VPN site à site (n'utilisez jamais le réseau Internet public). La copie des artefacts de configuration et d'exécution peut également être basée sur DBFS, en fonction des besoins du client. Plus de détails à ce sujet sont fournis ultérieurement.
WebLogic espaces de stockage persistants
Il est supposé que les emplacements de stockage persistants WebLogic utilisés pour les messages TLOGS et JMS sont des emplacements de stockage persistants JDBC et sont stockés dans des tables de base de données. De cette façon, les emplacements de stockage persistants sont accessibles à partir de n'importe quel membre du cluster (pour fournir une haute disponibilité locale avec Service Migration). Cela tire également parti d'Oracle Data Guard sous-jacent, qui réplique automatiquement les fichiers TLOGS et JMS sur le site secondaire.

Remarques concernant la base de données

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

Architecture colocative
La base principale doit être une base de données colocative (CDB/PDB). Cette opération est requise pour configurer une instance Oracle Data Guard hybride dans Oracle Cloud Infrastructure.
Niveaux de patch
Le répertoire de base Oracle de la base de données sur site doit être au même niveau de patch que la base de données de secours.
Cryptage transparent des données
Utilisez le cryptage transparent des données pour les bases de données principale et de secours afin de vous assurer que toutes les données sont cryptées. Si la base de données sur site 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 centrée sur Oracle RAC, cette procédure s'applique à une seule base de données. Toutefois, la pratique recommandée consiste à 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 sur site principal doit utiliser un service de base de données d'application pour se connecter à la base de données principale.
Système de base de données Oracle Cloud Infrastructure (OCI)
Utilisez un système de base de données OCI (bare Metal, machine virtuelle ou Oracle Exadata Database Service) en tant que base de données de secours. Une instance Oracle Autonomous Database, partagée ou dédiée, n'est pas couverte par ce document. Il ne fournit pas un certain nombre de fonctionnalités requises pour la configuration de la récupération après sinistre hybride, telles que la possibilité de configurer Oracle Data Guard avec une base de données sur site et la conversion de la base de données de secours instantanée.
Alias TNS dans les chaînes de connexion de 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. Etant donné que le même nom d'alias est utilisé dans la configuration principale et la configuration secondaire, vous n'avez pas besoin de modifier la configuration WebLogic après la réplication de la configuration principale vers la configuration secondaire.

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

Remarques concernant la gestion des identités

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

Lightweight Directory Access Protocol (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 couverte par ce 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 en cas de permutation dans le système LDAP.

Récapitulatif des remarques

Vous trouverez ci-dessous un récapitulatif des éléments à prendre en compte lors de la planification d'une solution de récupération après sinistre.

Remarques concernant	Résumé	Obligatoire ou fortement recommandé
Topologie	Le système principal est un environnement sur site existant.	Hautement recommandé
Topologie	Le système secondaire se trouve sur Oracle Cloud Infrastructure (OCI) et est créé de toutes pièces sur OCI.	Obligatoire
Topologie	Les systèmes principal et secondaire sont symétriques et ont le même nombre de nœuds dans les niveaux de base de données, intermédiaire et Web.	Obligatoire
Topologie	Le niveau Web principal se compose 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 OCI et sur site, ou VPN 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 répliquer 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 pour le serveur d'administration.	Hautement recommandé
Réseau	Adresse front-end virtuelle.	Obligatoire
Stockage	Structure de répertoires basée sur EDG.	Hautement recommandé
Stockage	Les dossiers privés et partagés sur site dans le stockage externe peuvent être montés à partir d'un noeud unique pour centraliser les opérations de synchronisation.	Hautement recommandé
Stockage	Configuration partagée OCI dans Oracle Cloud Infrastructure File Storage.	Obligatoire
Stockage	Exécution partagée OCI dans OCI File Storage ou le système de fichiers Oracle Database (DBFS).	Obligatoire
Stockage	Les dossiers binaires OCI FMW dans OCI File Storage sont montés de manière privée.	Hautement recommandé
Stockage	Configurations locales OCI dans Oracle Cloud Infrastructure Block Volumes (alternativement OCI File Storage monté de manière privée).	Hautement recommandé
Stockage	Montage DBFS intermédiaire (uniquement lorsque la réplique basée sur DBFS pour la configuration est utilisée).	Hautement recommandé
Stockage	Réplication du stockage basée sur `rsync` (ou DBFS pour certains artefacts spécifiques tels que la configuration).	Hautement recommandé
Stockage	WebLogic les emplacements de stockage persistants (TLOGS, JMS) dans les emplacements de stockage persistants JDBC.	Obligatoire (*si les informations JMS sont pertinentes)
Base de données	Niveau de patch de la base de données sur site identique à celui de la base de données de secours.	Obligatoire
Base de données	Cryptage transparent des données (TDE) pour les bases de données principale et de secours. Si la base de données sur site n'est pas déjà activée avec TDE, nous vous recommandons fortement de la convertir en TDE avant de configurer Oracle Data Guard.	Obligatoire
Base de données	Base de données Oracle RAC pour la haute disponibilité locale.	Hautement recommandé
Base de données	Base de données colocative 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 le système de base de données (BM, machine virtuelle ou Oracle Exadata Database Service), et non Oracle Autonomous Database.	Obligatoire
Base de données	Alias TNS dans les chaînes de connexion de 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 de LDAP externe n'est PAS obligatoire, mais si elle est utilisée, elle 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 couverte par ce 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 en cas de permutation dans le système LDAP.	Obligatoire (l'utilisation de LDAP externe n'est PAS obligatoire, mais si elle est utilisée et protégée par la récupération après sinistre, elle doit fournir une adresse d'accès virtuelle qui reste la même lorsqu'une permutation/basculement se produit pour le moyen LDAP d'y accéder)

A propos des services et rôles requis

Cette solution requiert les services et rôles suivants :

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

Nom du service : Rôle	Requis 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 réseau requises à la fois sur site et dans OCI : connexion rapide, réseaux cloud virtuels et sous-réseaux dans OCI, règles de sécurité réseau et règles de routage.
Oracle Data Guard : `root`, `oracle` et `sysdba`	Configurez Oracle Data Guard entre OCI principal sur site et OCI de secours et effectuez des conversions de rôles.
Oracle Database : `sysdba`	Gestion des bases de données.
Oracle WebLogic Server : `root`, `oracle`	Configurez les hôtes de niveau intermédiaire comme requis : effectuez la configuration au niveau du système d'exploitation, ajoutez des alias d'hôte, gérez les adresses IP virtuelles et montez des systèmes de fichiers.
Oracle WebLogic Server : `Weblogic Administrator`	Gérer Oracle WebLogic Server : arrêtez, démarrez et appliquez les modifications de configuration WebLogic.

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