Implémenter la réplication de niveau intermédiaire dans une architecture de récupération après sinistre OCI

Implémentez la réplication en cours pour votre niveau middleware dans un système de récupération après sinistre symétrique dans Oracle Cloud Infrastructure (OCI), en répliquant les serveurs d'applications et leurs configurations entre les régions principale et secondaire, ce qui garantit un temps d'arrêt minimal et une perte de données lors d'un basculement ou d'une permutation.

Ce guide stratégique fournit une présentation de la réplication de niveau intermédiaire tout au long du cycle de vie du système. Il présente diverses technologies de réplication et fournit des détails pour les implémenter dans un scénario réel. Il applique des scénarios de récupération après sinistre de niveau intermédiaire actif-passif dans lesquels les systèmes principal et de secours se trouvent dans OCI.

Ce contenu est destiné aux administrateurs de niveau intermédiaire qui connaissent les topologies de récupération après sinistre pour le middleware et OCI. Les exemples et la terminologie font référence à Oracle WebLogic Server et aux services PaaS qui utilisent WebLogic. Toutefois, les technologies et implémentations de réplication décrites s'appliquent à tout système de niveau intermédiaire.

Remarques :

Ce document ne décrit pas la configuration de la récupération après sinistre.

Architecture

Cette architecture présente une vue d'ensemble de la topologie de reprise après sinistre active-passive du middleware. Ce livre de jeux suppose que les systèmes primaire et secondaire sont déjà créés.

Toute solution de récupération après sinistre active-passive pour un système de niveau intermédiaire doit implémenter les fonctionnalités essentielles suivantes :

• Séparation géographique

  Les systèmes primaire et secondaire sont géographiquement séparés, suffisamment loin pour ne pas être affectés par le même événement de catastrophe.

• Symétrie

  Les systèmes primaire et secondaire sont symétriques. Le système secondaire a le même nombre de noeuds dans le niveau intermédiaire et le niveau de base de données, avec une capacité de CPU et de mémoire similaire.

• Nom unique du front-end

  Noms frontaux uniques pour le primaire et le secondaire. L'accès des clients au système doit être indépendant du site utilisé comme site principal. Pour ce faire, les noms d'adresse front-end doivent être uniques et toujours mappés avec l'adresse IP du système qui est la principale à ce moment-là. Ce nom est généralement appelé front-end virtuel ou URL virtuelle.

• Adresses d'écoute

  Les adresses d'écoute des processus de niveau intermédiaire doivent être des noms d'hôte pouvant être résolus dans les deux systèmes et mappés sur les adresses IP des hôtes du site local.

• Réplication de bases de données

  Les données de la base de données principale doivent être répliquées vers la base de données de secours à l'aide d'Oracle Data Guard.

• Réplication de niveau intermédiaire

  Les niveaux intermédiaires principal et secondaire doivent être synchronisés. Ils doivent avoir la même configuration, la même version de produit et le même niveau de patch. Il existe différentes approches pour y parvenir. Vous pouvez gérer les systèmes principal et secondaire séparément : si une modification est effectuée dans le système principal, la même modification est répétée dans le système secondaire, si un patch est installé dans le système principal, le même patch est installé dans le système de secours. Cependant, cela duplique le travail et est sujet à des erreurs. Oracle Maximum Availability Architecture (Oracle MAA) recommande d'implémenter une réplication automatique pour copier les artefacts de système de fichiers de niveau intermédiaire. Ainsi, les systèmes principal et de secours sont toujours synchronisés.

• Gestion des informations propres à chaque site

  La configuration du secondaire est une copie exacte du principal, mais il peut y avoir des artefacts de fichier qui contiennent des informations spécifiques à chaque site, qui doivent être différentes dans le principal et le secondaire. La topologie DR doit la prendre en charge et permettre la personnalisation des informations propres au site.

  Conseil :

  Exemple Oracle WebLogic Server

  Dans un système Oracle WebLogic, le niveau intermédiaire principal se connecte à la base de données de la région principale et le niveau intermédiaire secondaire se connecte à la base de données de la région secondaire. Les systèmes de niveau intermédiaire principal et secondaire ont la même configuration, il doit donc y avoir un mécanisme pour s'assurer que chaque système utilise la chaîne de connexion appropriée qui pointe vers sa base de données locale. Oracle Maximum Availability Architecture (Oracle MAA) recommande d'utiliser des alias TNS pour les sources de données, avec des fichiers tnsnames.ora différents dans chaque site. Les méthodes de réplication de niveau intermédiaire doivent en tenir compte, en ignorant le fichier contenant la chaîne de connexion à la base de données (tnsnames.ora) ou en remplaçant la chaîne de connexion à la base de données dans les fichiers pour pointer vers la base de données locale.

L'image suivante est un exemple de solution de récupération après sinistre active-passive pour un système de niveau intermédiaire.

Description de l'illustration active-passive-dr-mid-tier.png

active-passive-dr-mid-tier-oracle.zip

Terminologie

Vous devez vous familiariser avec les concepts et la terminologie suivants :

• Niveau intermédiaire (également niveau intermédiaire ou middleware)

  Le niveau intermédiaire fait référence à la couche au sein d'une architecture d'application à plusieurs niveaux qui se situe entre l'interface utilisateur (front-end) et le stockage de données (back-end). Il gère la logique métier, le traitement des données et la sécurité, et sert de pont entre l'utilisateur et la base de données.

• Catastrophe

  Un événement catastrophique soudain et imprévu qui cause des dommages ou des pertes inacceptables dans un site ou une zone géographique. Un sinistre est un événement qui compromet la capacité d'une organisation à fournir des fonctions, des processus ou des services essentiels pendant une période inacceptable et qui amène l'organisation à appeler ses plans de récupération.

• Récupération après sinistre

  Possibilité d'assurer la protection contre les interruptions naturelles ou non planifiées au niveau d'un site d'exploitation, au moyen d'une stratégie d'extraction des applications et des données vers un site secondaire géographiquement distinct.

• Topologie de récupération après sinistre

  Le site de production et les composants matériels et logiciels du site secondaire qui constituent une solution Oracle Fusion Middleware Disaster Recovery.

• Architecture de disponibilité maximale d'Oracle

  Oracle Maximum Availability Architecture (Oracle MAA) est le modèle de bonnes pratiques pour la protection et la disponibilité des données des produits Oracle (Database, Fusion Middleware, Applications). L'implémentation des bonnes pratiques Oracle MAA est l'une des principales exigences de tout déploiement Oracle. Il fournit des recommandations pour la configuration et la gestion d'un système Oracle. Oracle MAA inclut les recommandations du Guide de déploiement Oracle Fusion Middleware Enterprise et ajoute les meilleures pratiques de protection contre les sinistres afin de minimiser les temps d'arrêt planifiés et non planifiés pour les pannes affectant l'ensemble d'un centre de données ou d'une région.

• Système

  Un système est un ensemble de cibles (hôtes, bases de données, serveurs d'applications, etc.) qui fonctionnent ensemble pour héberger vos applications. Par exemple, pour surveiller une application dans Oracle Enterprise Manager, vous devez d'abord créer un système composé des cibles de base de données, de processus d'écoute, de serveur d'applications et d'hôtes sur lesquelles l'application s'exécute.

• Site

  Un site est l'ensemble des différents composants d'un centre de données nécessaires à l'exécution d'un groupe d'applications. Par exemple, un site peut être constitué d'instances Oracle Fusion Middleware, de bases de données, de stockage, etc.

• Production ou site principal

  Site qui transporte la charge de travail du système à un moment précis. Il s'agit d'un groupe de ressources matérielles, réseau et de stockage, et de processus activement utilisés pour transmettre la logique métier et traiter les demandes à un moment précis.

• Site secondaire (ou de secours ou DR)

  Un site secondaire est un emplacement de sauvegarde qui peut prendre le relais de la logique métier et des demandes qu'un site principal traitait. En règle générale, les sites secondaires sont également appelés "De secours" car ils restent en "mode veille ou inactif". Cela signifie qu'ils ne traitent pas la charge de travail de production pendant les opérations normales. Cependant, cela ne signifie pas que le site secondaire ne peut pas être utilisé à d'autres fins. Ceci est particulièrement vrai dans les modèles plus modernes où le site secondaire est utilisé pour signaler les opérations et, plus important encore, pour valider les modifications avant de les appliquer sur le site principal.

• Objectif de point de récupération

  L'objectif de point de récupération est la quantité de perte de données qu'un système peut tolérer du point de vue de l'entreprise. Par exemple, la quantité de perte de données acceptable lorsqu'une panne survient.

• Objectif de délai de récupération (RTO)

  L'objectif de temps de récupération est la durée d'inactivité qu'un système peut tolérer ou la durée acceptable pendant laquelle une application ou un service peut rester indisponible en cas de panne, d'un point de vue commercial.

• Oracle Cloud Infrastructure (OCI)

  OCI est un ensemble de services cloud complémentaires qui vous permettent d'élaborer et d'exécuter un éventail d'applications et de services dans un environnement hébergé hautement disponible. OCI offre des fonctionnalités de calcul (comme des instances matérielles physiques) et de stockage hautes performances dans un réseau virtuel superposé flexible accessible de manière sécurisée à partir de votre réseau sur site.

• Région OCI

  Une région OCI est une zone géographique localisée composée d'un ou plusieurs 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). Une région est un site en termes de récupération après sinistre.

• Volumes de blocs OCI

  Les volumes de blocs OCI fournissent un stockage de blocs fiable, hautes performances et à faible coût qui persiste au-delà de la durée de vie d'une machine virtuelle, avec une redondance intégrée et la possibilité de s'adapter.

• OCI File Storage

  OCI File Storage est un service de stockage entièrement géré, élastique et adapté à l'entreprise qui permet aux serveurs et aux applications d'accéder aux données via des systèmes de fichiers partagés.

• DBFS

  Un système de fichiers de base de données (DBFS) est une interface de système de fichiers standard dans Oracle Database. DBFS est similaire à NFS en ce sens qu'il fournit un système de fichiers réseau partagé qui ressemble à un système de fichiers local et dispose à la fois d'un composant serveur et d'un composant client.

• Structure WLS-HYDR

  La structure WLS-HYDR fait référence à une structure permettant de créer et de configurer un système de récupération après sinistre symétrique pour les environnements Oracle WebLogic Server (WLS), en particulier au sein d'Oracle Cloud Infrastructure. Cette structure automatise les processus manuels impliqués dans la configuration d'un environnement de récupération après sinistre pour les domaines WLS ou Fusion Middleware (FMW).

• Pile Oracle WebLogic Server for Oracle Cloud Infrastructure

  La pile Oracle WebLogic Server for OCI fait référence à un environnement préconfiguré créé à l'aide d'Oracle Resource Manager dans OCI Marketplace, qui provisionne et gère les déploiements Oracle WebLogic Server sur OCI. Il automatise la création et la configuration de différentes ressources OCI telles que des instances de calcul, des réseaux et des équilibreurs de charge, ainsi que d'un domaine WebLogic.

• Pile Oracle SOA Suite on Marketplace

  La pile Oracle SOA Suite on Marketplace est un environnement préconfiguré construit à l'aide d'Oracle Resource Manager dans OCI Marketplace, pour le déploiement et la gestion des applications Oracle SOA Suite sur OCI. Il automatise la création et la configuration de différentes ressources OCI telles que des instances de calcul, des réseaux et des équilibreurs de charge, ainsi que d'un domaine SOA WebLogic.

• Alias TNS

  Dans Oracle, un alias TNS, également appelé nom de service réseau, est un identificateur convivial qui simplifie les connexions de base de données. Il sert de raccourci et met en correspondance un nom lisible par l'utilisateur avec les détails de connexion plus complexes requis pour atteindre une instance de base de données Oracle spécifique. Ces détails, notamment le protocole, l'hôte, le port et le nom de service, sont stockés dans un fichier de configuration, généralement nommé tnsnames.ora.

• Dossier d'administration TNS

  Le dossier Admin Oracle TNS, indiqué par la variable d'environnement TNS_ADMIN, est le répertoire dans lequel se trouvent les fichiers de configuration Oracle Net Services, tels que tnsnames.ora. Un système de niveau intermédiaire peut utiliser un dossier d'administration TNS avec tnsnames.ora et d'autres artefacts nécessaires pour se connecter à la base de données.

A propos des procédures de configuration de la récupération après sinistre active-passive dans OCI

Dans une topologie de récupération après sinistre active-passive pour middleware, le système secondaire est un miroir du système principal. Lorsque les systèmes principal et secondaire se trouvent tous deux dans OCI, il existe différentes façons de configurer le système secondaire :

• Manuelle

  Créez chaque ressource individuellement via la console ou l'interface de ligne de commande OCI en tant que miroir du système principal.

• Structure WLS-HYDR

  Utilisez la structure WLS-HYDR pour vos systèmes de niveau intermédiaire basés sur Oracle WebLogic. Cette structure utilise le kit SDK OCI pour Python pour créer toutes les ressources du secondaire en tant que miroir du système principal. Reportez-vous à la section Explorer plus de ce guide pour obtenir un lien vers la structure wls-hydr dans GitHub.

• Provisionner à l'aide de la même pile Marketplace

  Si le système principal est une pile Marketplace, telle qu'Oracle WebLogic Server for OCI ou SOA Marketplace, vous pouvez effectuer le provisionnement en utilisant la même pile Marketplace que celle utilisée dans la base principale, la base de données de secours étant en mode de secours cliché.

Ce guide stratégique de solution s'applique à tous ces cas tant qu'ils répondent aux caractéristiques d'une topologie de récupération après sinistre active-passive décrite au point précédent. Elle suppose que les systèmes principal et secondaire ont déjà été créés.

Remarques :

Ce document ne décrit pas la configuration de la récupération après sinistre.