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

Pour assurer la continuité de l'activité en cas de sinistre, vous devez implémenter une stratégie de récupération après sinistre pour votre instance Oracle SOA Suite on-premise qui offre une protection des données et vous permet de basculer rapidement sur le système de secours en réduisant au minimum les données et la productivité. Cette solution explique comment configurer une stratégie de récupération après sinistre hybride pour un système SOA existant on-premise et le système de secours sur Oracle Cloud Infrastructure (OCI). Avec l'aide d'Oracle Data Guard, cette solution de récupération après sinistre fournit une infrastructure et des services hautement disponibles, sécurisés et évolutifs , qui permettent une récupération après sinistre de manière fiable et sécurisée.

Avant de commencer

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

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 en détail, elle couvre de nombreux composants et combinaisons différents, 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. 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. Sur cette base, il est vivement recommandé de se familiariser avec les meilleures pratiques de déploiement d'entreprise et de haute disponibilité d'Oracle WebLogic Server pour le réseau, le stockage et l'hôte avant de déployer un système hybride.

Pour plus d'informations, voir :

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

Vous serez également familiarisé 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 un 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 (VM) 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 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 site).

Le niveau 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 ci-après

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.

• Equilibreur de charge

  Fournit une répartition automatisée du trafic 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 pour Oracle SOA Suite (EDG) standard. 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 d'activer l'évolutivité horizontale, tout en accédant au stockage partagé. Les sessions utilisateur se connectant aux instances Oracle RAC peuvent basculer et réexécuter en toute sécurité les modifications pendant les interruptions de service, sans aucune modification des applications utilisateur, en masquant l'impact des pannes sur les utilisateurs finals.

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 des 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 (elles peuvent se trouver dans des pays voire des continents différents).

• 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 votre environnement réseau. Un VCN peut contenir plusieurs blocs CIDR qui ne se chevauchent pas et que vous pouvez modifier après avoir créé le VCN. Vous pouvez segmenter un VCN en sous-réseaux, qui peuvent être ciblés sur une région ou sur un domaine de disponibilité. Chaque sous-réseau se compose d'une plage d'adresses contiguës qui ne chevauchent pas les autres sous-réseaux du VCN. 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 recommandés de façon générique 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 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 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 votre centre de données et Oracle Cloud Infrastructure. FastConnect offre des options de bande passante plus élevée et des fonctions de réseau plus fiables 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 vers et depuis le 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.

• équilibreur de charge

  Le service Oracle Cloud Infrastructure Load Balancing fournit une répartition de trafic automatisée à partir d'un point d'entrée unique vers plusieurs serveurs du 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 vos ressources à la recherche de failles de sécurité et pour surveiller les opérateurs et les utilisateurs pour certaines activités à risque. En cas de détection d'une mauvaise configuration ou d'une activité non sécurisée, Cloud Guard recommande des actions correctives et 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 d'entreprise durable, évolutif et sécurisé. 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 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.

  Oracle Cloud Infrastructure File Storage utilise un stockage répliqué dans 5 directions, dans différents domaines de pannes, pour assurer la redondance synonyme de résilience 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.

• Volumes de blocs Oracle Cloud Infrastructure Block Volumes

  Le service Oracle Cloud Infrastructure Block Volumes permet de provisionner et de gérer dynamiquement les volumes de stockage de blocs. 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 base de données Oracle Database unique sur plusieurs serveurs afin d'optimiser la disponibilité et d'activer l'évolutivité horizontale, tout en accédant au stockage partagé. Les sessions utilisateur se connectant aux instances Oracle RAC peuvent basculer et réexécuter en toute sécurité les modifications pendant les interruptions de service, sans aucune modification des applications utilisateur, en masquant l'impact des pannes sur les utilisateurs finals. La structure Oracle Real Application Clusters High Availability gère la disponibilité des services en stockant les informations de configuration de chacun 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, maintiennent, gèrent et surveillent des 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 conserve 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 planifiée, 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 db-tier, 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 (VM) OCI. Les fichiers binaires Oracle Fusion Middleware et le domaine SOA sont une réplique des fichiers binaires et du domaine SOA principaux, utilisant le service Oracle Cloud Infrastructure File Storage comme solution de système de fichiers réseau et Oracle Cloud Infrastructure Block Volumes comme 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 Server dans l'environnement secondaire. Dans l'emplacement secondaire, les alias de nom d'hôte sont résolus à l'aide des adresses IP des hôtes secondaires.

Le niveau Web dans le centre de données principal suit le modèle Guide de déploiement d'entreprise (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 les instances de calcul OCI. Dans le système secondaire, vous pouvez également implémenter la couche Web avec un équilibreur de charge OCI uniquement, qui fournit la plupart des fonctionnalités requises par la topologie de déploiement d'entreprise. Les deux options, uniquement 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 en cours d'exécution sur 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 le 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.

Dans le cadre d'un fonctionnement normal, la base de secours est une base de secours physique. Il est en é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, y compris les schémas SOA (Server Oriented Architecture), les informations Oracle Platform Security Services, les schémas personnalisés, les journaux de transactions (TLOG), les espaces de stockage persistants JDBC (Java Database Connectivity), etc.

Au cours des étapes de configuration et de validation du cycle de vie de la récupération après sinistre 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 afin de valider le site secondaire sans effectuer de permutation complète. Une base de données en mode de secours instantané peut faire l'objet d'une mise à jour complète. Une base 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 supprimées lors de sa conversion 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 initiale de la reconfiguration dynamique, 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 un fonctionnement normal, elle ne reçoit pas de mises à jour de la base principale et peut être désynchronisée. Comme 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 temps 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.

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 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 se trouve 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 qui peut devenir le système principal.

• Oracle SOA Suite et composants

  Ce document se concentre 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 les 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 détails et la prise en charge de ces composants sont exclus 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 exactement aux mêmes valeurs d'UC et de mémoire que 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 performances et des erreurs de cascade peuvent survenir lorsque la charge globale est permuté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 redo d'Oracle Data Guard. Les hôtes de niveau intermédiaire sur site 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 site 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 un coût prévisibles. Vous pouvez également utiliser un VPN site à site, qui fournit également une connectivité sécurisée entre l'environnement sur site et OCI. Toutefois, cela permet de réduire la bande passante et de réduire la latence, la gigue et le 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 doivent jamais se connecter à la base de données distante pendant l'exécution. La latence entre le site et OCI décourage généralement cette connectivité croisée. Pour éviter les connexions accidentelles et les problèmes de charge globale, empêchez la connectivité des hôtes de niveau intermédiaire à la base de données distante.

• Noms d'hôte virtuel

  Il est recommandé que le système sur site principal utilise des noms d'hôte virtuel, et non le 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ôtes virtuels facilite le déplacement des configurations vers des hôtes différents ; toutefois, il ne s'agit pas d'une exigence 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 serveur principal en tant qu'alias dans chaque noeud (comme résolu dans DNS ou /etc/hosts local).

• Une adresse IP virtuelle n'est requise que 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 penser que le serveur d'administration du système sur site principal écoute une adresse IP virtuelle. Ce document fournit des instructions pour configurer une adresse IP virtuelle pour le serveur d'administration dans OCI. Cependant, cette adresse IP virtuelle n'est pas une exigence stricte pour la configuration de 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 site principal et un équilibreur de charge OCI dans l'environnement de secours.

• Adresse frontale virtuelle

  Le système principal doit utiliser un nom frontal virtuel (une URL personnalisée, telle que 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 DR, 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 tous les noms frontaux virtuels utilisés 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 Oracle WebLogic Server géré, comme décrit dans la section 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, qui couvre plus 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 dans le serveur 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 aussi les fichiers binaires du répertoire de base Oracle Fusion Middleware et les configurations locales (répertoires de domaine 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 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 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 stocke les données en privé.

  Remarque :

  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 comme 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, le répertoire de domaine du serveur d'administration WebLogic Server, le répertoire de base des plans de déploiement) est principalement accessible par l'hôte du serveur d'administration. Les autres hôtes y accèdent en permanence (pour les plans de déploiement, les fichiers de clés partagés, etc.). Il doit être placé dans un seul 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 DBFS (Database File System).
• Remarques concernant le stockage des dossiers privés dans l'OCI secondaire

  Les fichiers 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 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 en privé 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 Block Volumes, un autre hôte peut monter les fichiers en mode lecture seule). La copie peut également être effectuée individuellement, à partir de chacun des noeuds qui stocke les données en privé.

  Remarque :

  Les scripts fournis pour la copie rsync de ceux-ci sont suffisamment flexibles pour être adaptés à tous les cas.
• Réplication de stockage

  Il n'existe aucune réplication directe au niveau du stockage entre l'environnement sur site et OCI. 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'utilisant 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. Vous trouverez plus de détails ultérieurement.

• WebLogic emplacements de stockage persistants

  Il est supposé que les espaces de stockage persistants WebLogic utilisés pour les messages TLOGS et JMS sont des espaces de stockage persistants JDBC et sont stockés dans des tables de base de données. De cette façon, les espaces 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 de l'instance Oracle Data Guard sous-jacente, qui réplique automatiquement les TLOGS et JMS vers le site secondaire.

Remarques concernant Database

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

• Architecture multiple

  La base de données principale doit être une base de données colocative (CDB/PDB). Cette opération est nécessaire 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 se trouver au même niveau de patch que la base de données de secours.

• Cryptage transparent des données

  Utilisez Transparent Data Encryption (TDE) pour les bases de données principale et de secours afin d'assurer le cryptage de toutes les donné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 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 Database

  Le niveau intermédiaire (middle tier) 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 traitée dans 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 base de données 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 base de données principale et la base de données secondaire, vous n'avez pas besoin de modifier la configuration WebLogic après l'avoir répliqué de la base de données principale vers la base de données secondaire.

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

Remarques concernant la gestion des identités

Lorsque vous configurez la gestion des identités, tenez compte des points suivants :

• 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 n'importe quel service LDAP externe est hors du champ d'application de 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 considérations

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	Synthèse	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 noeuds 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 (CPU, mémoire, etc.).	Obligatoire
Réseau	Utilisez OCI FastConnect pour la connectivité entre les environnements sur site et OCI, ou un 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 Oracle Database File System (DBFS) est utilisé pour la réplication de la configuration.	Hautement recommandé
Réseau	Utilisez les 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 frontale virtuelle.	Obligatoire
Stockage	Structure de répertoires EDG.	Hautement recommandé
Stockage	Les dossiers privés et partagés sur site dans le stockage externe afin qu'ils puissent être montés à partir d'un noeud unique pour centraliser les opérations rsync.	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 Oracle Database File System (DBFS).	Obligatoire
Stockage	Les dossiers binaires FMW OCI dans OCI File Storage sont montés de manière privée.	Hautement recommandé
Stockage	Configurations locales OCI dans Oracle Cloud Infrastructure Block Volumes (également montées en privé sur le stockage de fichiers OCI).	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 comme la configuration).	Hautement recommandé
Stockage	WebLogic 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 base de données sur site identique à celui de la base de données de secours.	Obligatoire
Base de données	Transparent Data Encryption (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, 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 la haute disponibilité locale.	Hautement recommandé
Base de données	Base de données multi-location 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, 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 à 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'entre pas dans le champ d'application de 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 d'un serveur LDAP externe n'est PAS obligatoire, mais s'il est utilisé et protégé par la récupération après sinistre, il doit fournir une adresse d'accès virtuel qui reste la même lorsqu'une permutation/basculement se produit pour la méthode d'accès LDAP à ce serveur)

A propos des services et des rôles requis

Cette solution requiert les services et rôles suivants :

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

Nom de 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	Configurer les ressources réseau requises sur site et sur OCI : Fast Connect, 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	Configurer Oracle Data Guard entre l'OCI principal on-premise et l'OCI de secours, et effectuer 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 vos 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.

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.