Mettre en oeuvre la réplication de niveau intermédiaire dans une architecture de récupération après sinistre OCI

Mettez en oeuvre la réplication continue pour votre niveau d'intergiciel dans un système de reprise 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, afin de garantir un temps d'arrêt minimal et une perte de données lors d'un basculement ou d'une permutation.

Ce livre de jeu de solution offre un aperçu 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 où les systèmes principal et de secours sont dans OCI.

Le contenu est destiné aux administrateurs de niveau intermédiaire familiarisés avec les topologies de récupération après sinistre pour l'intergiciel et OCI. Les exemples et la terminologie font référence à Oracle WebLogic Server et aux services PaaS qui utilisent WebLogic; toutefois, les technologies de réplication et les mises en oeuvre décrites s'appliquent à tout système de niveau intermédiaire.

Note :

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

Architecture

Cette architecture présente un aperçu général de la topologie de récupération après sinistre active-passive d'un intergiciel. Ce livre de jeu suppose que les systèmes primaire et secondaire sont déjà créés.

Toute solution de reprise après sinistre active-passive pour un système de niveau intermédiaire doit mettre en oeuvre les fonctions essentielles suivantes :

• Séparation géographique

  Les systèmes primaire et secondaire sont géographiquement séparés, suffisamment loin pour qu'ils ne puissent 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 (middle tier) et le niveau db, avec des capacités de CPU et de mémoire similaires.

• Nom frontal unique

  Noms frontaux uniques pour le primaire et le secondaire. L'accès des clients au système doit être indépendant du site utilisé en tant que site principal. Pour ce faire, les noms d'adresses frontales doivent être uniques et toujours mappés à l'adresse IP du système qui est le principal à ce moment-là. Ce nom est généralement appelé frontal virtuel ou URL de vanité.

• 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 aux 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 correctif. 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 correctif est installé dans le système principal, le même correctif 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 de mettre en oeuvre une réplication automatique pour copier les artefacts du système de fichiers de niveau intermédiaire. Cela garantit que 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 primaire, mais il peut y avoir des artefacts de fichier qui contiennent des informations spécifiques à chaque site, qui doivent être différentes dans le primaire et le secondaire. La topologie de récupération après sinistre doit prendre en charge cette fonctionnalité et autoriser la personnalisation des informations propres au site.

  Conseil :

  Exemple pour 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 à 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 exister un mécanisme garantissant 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 qu'elle pointe vers la base de données locale.

L'illustration suivante présente un exemple de solution de reprise après sinistre active-passive pour un système de niveau intermédiaire (middle tier).

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

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

Terminologie

Vous devez connaître les concepts et la terminologie suivants :

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

  Le niveau intermédiaire (middle tier) fait référence à la couche d'une architecture d'application à plusieurs niveaux située 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é, servant de pont entre l'utilisateur et la base de données.

• Catastrophe

  Événement catastrophique soudain et non planifié qui cause des dommages ou des pertes inacceptables sur 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 critiques pendant une période inacceptable et qui amène l'organisation à invoquer ses plans de reprise.

• Reprise après sinistre

  Capacité de se protéger contre les pannes naturelles ou non planifiées sur un site de production en ayant un programme de récupération des applications et des données sur 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.

• Oracle Maximum Availability Architecture

  Oracle Maximum Availability Architecture (Oracle MAA) est le modèle des meilleures pratiques pour la protection et la disponibilité des données des produits Oracle (base de données, Fusion Middleware, applications). La mise en œuvre des meilleures pratiques Oracle MAA est l'une des exigences clés pour tout déploiement Oracle. Il fournit des recommandations pour la configuration et la gestion d'un système Oracle. Oracle MAA comprend les recommandations du Guide de déploiement d'Oracle Fusion Middleware Enterprise et ajoute les meilleures pratiques de protection en cas de sinistre 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é de la base de données, du module d'écoute, du serveur d'applications et des cibles hôtes sur lesquelles l'application s'exécute.

• Lieu

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

• Production ou site principal

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

• Site secondaire (ou de secours ou de reprise après sinistre)

  Un site secondaire est un emplacement de sauvegarde qui peut prendre en charge la logique métier et les demandes qu'un site principal était en train de traiter. En général, les sites secondaires sont également nommés "De secours", car ils restent en mode "de secours ou inactif". Cela signifie qu'ils ne traitent pas la charge de travail de production pendant les opérations normales. Toutefois, cela n'implique pas que le site secondaire ne puisse pas être utilisé à d'autres fins. Cela est particulièrement vrai dans les modèles plus modernes où le site secondaire est utilisé pour les opérations de reporting et, plus important encore, pour valider les modifications avant de les appliquer dans le site principal.

• Objectif de point de récupération

  L'objectif du point de récupération est la quantité de perte de données qu'un système peut tolérer d'un point de vue commercial. Par exemple, la quantité de perte de données acceptable en cas de panne.

• Objectif de délai de récupération

  L'objectif de délai de récupération est le temps d'arrêt qu'un système peut tolérer ou le temps acceptable pendant lequel une application ou un service peut rester indisponible lorsqu'une panne se produit, d'un point de vue commercial.

• Oracle Cloud Infrastructure (OCI)

  OCI est un ensemble de services en nuage complémentaires qui vous permettent de créer et d'exécuter une gamme d'applications et de services dans un environnement hébergé hautement disponible. OCI fournit des fonctions de calcul de haute performance (en tant qu'instances matérielles physiques) et une capacité de stockage dans un réseau virtuel flexible accessible de manière sécurisée à partir de votre réseau local.

• Région OCI

  Une région OCI est une zone géographique localisée, composée d'un ou de plusieurs domaines de disponibilité. Les régions sont indépendantes les unes des autres et peuvent être séparées par des distances importantes, dans différents pays ou continents. Une région est un site en termes de récupération après sinistre.

• Volumes par blocs OCI

  Le service Volumes par blocs d'OCI fournit un stockage par blocs fiable, à haute performance 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é d'évolutivité.

• Service de stockage de fichiers pour OCI

  Le service Stockage de fichiers OCI 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 au moyen de systèmes de fichiers partagés.

• Système de gestion des données

  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 comporte à la fois un composant serveur et un composant client.

• Cadre WLS-HYDR

  Le "cadre WLS-HYDR" fait référence à un cadre pour créer et configurer un système symétrique de récupération après sinistre (DR) pour les environnements Oracle WebLogic Server (WLS), plus précisément dans Oracle Cloud Infrastructure. Cette structure automatise les processus manuels impliqués dans la configuration d'un environnement de reprise après sinistre pour les domaines WLS ou Fusion Middleware (FMW).

• Pile Oracle WebLogic Server for Oracle Cloud Infrastructure

  La pile Oracle WebLogic Server pour OCI fait référence à un environnement préconfiguré créé à l'aide du gestionnaire de ressources Oracle 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 diverses ressources OCI telles que les instances de calcul, le réseau, les équilibreurs de charge, ainsi qu'un domaine WebLogic.

• Pile Oracle SOA Suite on Marketplace

  La pile d'Oracle SOA Suite on Marketplace est un environnement préconfiguré créé à l'aide du gestionnaire de ressources Oracle dans OCI Marketplace, pour déployer et gérer les applications Oracle SOA Suite sur OCI. Il automatise la création et la configuration de diverses ressources OCI telles que les instances de calcul, le réseau, les équilibreurs de charge, ainsi qu'un domaine SOA WebLogic.

• Alias TNS

  Dans Oracle, un alias TNS, également appelé Net Service Name, est un identificateur convivial qui simplifie les connexions à la base de données. Il agit comme un raccourci en mappant un nom lisible par l'homme aux 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 du service, sont stockés dans un fichier de configuration, généralement nommé tnsnames.ora.

• Dossier d'administration TNS

  Le dossier d'administration Oracle TNS, spécifié 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.

À propos des procédures de configuration de récupération après sinistre active et passive de l'intergiciel dans OCI

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

• Manuelle

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

• Cadre WLS-HYDR

  Utilisez la structure WLS-HYDR pour vos systèmes de niveau intermédiaire (middle tier) basés sur Oracle WebLogic. Ce cadre utilise la trousse SDK OCI pour Python pour créer toutes les ressources dans le secondaire en tant que miroir du système principal. Voir la section Explorer plus dans ce livre de jeu pour un lien vers le cadre 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 pour OCI ou SOA Marketplace, vous pouvez effectuer le provisionnement à l'aide de la même pile Marketplace que celle utilisée dans la base principale, avec la base de secours en mode de secours instantané.

Ce livre de jeu 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 et passive décrite au point précédent. Il suppose que les systèmes principal et secondaire ont déjà été créés.

Note :

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