Configuration d'une solution de récupération après sinistre hybride pour Oracle WebLogic Server

Avant de commencer

Avant de commencer à déployer une solution de récupération après sinistre hybride pour le système Oracle WebLogic Server, 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 WebLogic Server sur site.

Le système principal est un système Oracle WebLogic Server 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 provisionnant des images Oracle WebLogic Server for OCI et non une pile Oracle WebLogic Server for OCI (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 les piles Oracle WebLogic Server for OCI de fonctionner correctement en tant que piles 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'image maa-wls-hybrid-dr.png

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

maa-wls-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.
Equilibrage de charge
Fournit une distribution automatisée du trafic à partir d'un point d'entrée unique vers plusieurs serveurs dans le back-end.
Oracle WebLogic Server
Le domaine Oracle WebLogic Server est un environnement haute disponibilité qui a été configuré conformément aux meilleures pratiques MAA standard en matière de haute disponibilité.
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 qui se connectent aux instances Oracle RAC peuvent effectuer un basculement en cas d'incident 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 aux utilisateurs finals.

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 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 centres de données traditionnels, les réseaux cloud virtuels vous permettent de contrôler entièrement votre environnement réseau. Un VCN peut avoir plusieurs blocs CIDR qui ne se chevauchent pas 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 contiguë d'adresses 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 (DRG)
Le DRG est un routeur virtuel qui fournit un chemin pour le trafic de réseau privé entre des réseaux cloud virtuels de la même région, entre un VCN et un réseau extérieur à la région, tel qu'un VCN dans une autre région Oracle Cloud Infrastructure, un réseau sur site ou un réseau d'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 une expérience 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 à autoriser vers et depuis le sous-réseau.
Table de routage
Les tables de routage virtuelles contiennent des règles permettant d'acheminer le trafic de sous-réseaux vers des destinations situées en dehors d'un VCN, généralement via des passerelles.
équilibrage de charge
Le service Oracle Cloud Infrastructure Load Balancing fournit une répartition de trafic automatisée à partir d'un seul point d'entrée 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 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 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 qui se connectent aux instances Oracle RAC peuvent effectuer un basculement en cas d'incident 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 aux 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 gère ces bases de secours comme des copies de la base de données de production. Par la suite, si la base de données de production devient indisponible en raison d'une coupure 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 base de données de production, ce qui réduit le temps d'inactivité associé à la coupure.

Description de la topologie

La topologie de récupération après sinistre hybride d'Oracle WebLogic Server 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 instances OCI Compute, qui peuvent être des images Oracle WebLogic Server for Oracle Cloud Infrastructure pour tirer parti de la licence d'habilitation WebLogic incluse dans ces images. Les fichiers binaires Oracle Fusion Middleware et le domaine Oracle WebLogic sont une réplique des fichiers binaires et du domaine de l'instance principale, utilisant les services 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 Oracle 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 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 DR. 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 données de secours est arrêtée dans le cadre d'un fonctionnement normal, elle ne reçoit pas les mises à jour en provenance de la base 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. 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 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.
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.

Considérations relatives au 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 se connecteront jamais à la base de données distante lors de l'exécution. La latence entre l'environnement sur site et OCI décourage généralement cette interconnexion. 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é 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.
équilibrage 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 wlsfrontend.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.

Considérations relatives au 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 les systèmes d'exploitation

Les images Oracle WebLogic Server for Oracle Cloud Infrastructure prennent en charge les systèmes d'exploitation Oracle Linux 7.9 et Oracle Linux 8.5.

Les instances de calcul de niveau intermédiaire et Web doivent utiliser l'image de système d'exploitation et la forme de calcul qui sont les plus similaires à l'image et à la forme utilisées par les hôtes sur site. Lors de l'utilisation du serveur WebLogic pour les images OCI, la solution est limitée à la version de système d'exploitation qu'ils utilisent (actuellement Oracle Linux 7.X ou 8.X).

Versions du système d'exploitation pour les hôtes de niveau intermédiaire
Un serveur Oracle WebLogic Server exécuté sur Oracle Cloud Infrastructure (OCI) doit être couvert par un contrat de licence et de support valide en plus du contrat de licence et de support utilisé pour couvrir le serveur Oracle WebLogic Server exécuté sur site. Dans Oracle Cloud, les instances de calcul peuvent être créées avec les images Oracle WebLogic Server for OCI. Les instances de calcul créées avec ces images incluent l'habilitation à exécuter Oracle WebLogic Server et sont facturées par OCPU/heure lorsqu'elles sont en cours d'exécution. Ces images sont disponibles pour les systèmes d'exploitation Oracle Linux 7.9 et Oracle Linux 8.5.
Versions du système d'exploitation des hôtes de niveau Web
Un Oracle HTTP Server exécuté dans OCI doit être couvert par un contrat de licence et de support valide en plus du contrat de licence et de support utilisé pour couvrir l'Oracle HTTP Server exécuté sur site. Dans Oracle Cloud, les instances de calcul peuvent être créées avec les images Oracle WebLogic Server for OCI. Les instances de calcul créées avec ces images incluent l'habilitation à exécuter Oracle HTTP Server et sont facturées par OCPU/heure pour que l'habilitation exécute le logiciel WebLogic lorsqu'elles sont en cours d'exécution. Ces images sont disponibles pour les systèmes d'exploitation Oracle Linux 7.9 et Oracle Linux 8.5.

Remarques concernant Oracle WebLogic Server

Lors de l'implémentation de cette solution, tenez compte des points suivants :

Produits sur Oracle WebLogic Server
Les environnements avec des produits supplémentaires installés sur Oracle WebLogic Server peuvent bénéficier des procédures décrites dans ce livre de jeux, mais les spécificités d'autres produits ne sont pas couvertes par ce document.
Edition Oracle WebLogic Server
Ce document peut s'appliquer à Oracle WebLogic Suite Edition et à Oracle WebLogic Server Enterprise Edition. Toutefois, lorsque la base de données est une base de données Oracle Real Application Clusters (Oracle RAC) (ce qui est recommandé pour obtenir une haute disponibilité locale), ce document suppose que Oracle WebLogic Suite Edition est utilisé car Oracle WebLogic Server Enterprise Edition n'inclut pas l'autorisation d'utiliser des sources de données Active GridLink.
Domaines WebLogic compatibles JRF
Ce document s'applique aux domaines pour lesquels les composants JRF (Java Required Files) sont activés et aux domaines de base.

Les domaines compatibles JRF ont plus de dépendances à la base de données que les domaines de base. De ce fait, un modèle de récupération après sinistre conçu pour un domaine compatible JRF présente davantage de contraintes. Les domaines de base offrent davantage de flexibilité pour la récupération après sinistre, mais un modèle de récupération après sinistre valide pour un domaine de base peut ne pas s'appliquer à un domaine compatible JRF car il ne prend pas en compte les dépendances de base de données JRF WebLogic. Un modèle de récupération après sinistre valide pour un domaine compatible JRF est également valide pour un domaine de base. Le modèle décrit dans ce document est basé sur des domaines JRF. Il s'applique donc aux deux types de domaine Oracle WebLogic.

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 de données 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 d'origine Oracle Home 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 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 principal sur site 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 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.

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)

Le tableau suivant récapitule les considérations relatives au système d'exploitation et à Oracle WebLogic en plus des considérations présentées dans le tableau précédent.

Remarques concernant	Synthèse	Obligatoire ou fortement recommandé
Système d'exploitation	Versions du système d'exploitation de niveau intermédiaire sur site : Oracle Linux 7 ou 8	Hautement recommandé (pour tirer parti des images Oracle WebLogic Server for OCI)
Système d'exploitation	Versions du système d'exploitation de niveau Web sur site : Oracle Linux 7 ou 8	Hautement recommandé (pour tirer parti des images Oracle WebLogic Server for OCI)
Oracle WebLogic Server	Logiciel WebLogic uniquement. Autres produits hors de portée du document	N/A
Oracle WebLogic Server	Edition Oracle WebLogic Suite lorsqu'Oracle RAC est utilisé, pour utiliser les sources de données GridLink	Obligatoire
Oracle WebLogic Server	WebLogic Domaines compatibles JRF et non compatibles JRF	N/A (les deux sont valides)

A propos des services et des rôles requis

Cette solution requiert les services et rôles suivants :

Il s'agit des rôles requis 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`	Configurez les ressources réseau requises 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`	Configurer Oracle Data Guard entre l'OCI principal sur site et l'OCI de secours et effectuer des conversions de rôles.
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.

Pour obtenir les services cloud dont vous avez besoin, reportez-vous à Obtention de services Oracle Cloud pour les solutions Oracle.