Tutoriel : Migrer Oracle WebLogic Server vers Azure Machines Virtuelles avec haute disponibilité et récupération d’urgence

Article
01/11/2024

Ce tutoriel vous montre un moyen simple et efficace d’implémenter la haute disponibilité et la récupération d’urgence (HA/DR) pour Java à l’aide d’Oracle WebLogic Server (WLS) sur Azure Machines Virtuelles (machines virtuelles). La solution montre comment atteindre un objectif de temps de récupération (RTO) faible et un objectif de point de récupération (RPO) à l’aide d’une application Jakarta EE basée sur une base de données simple s’exécutant sur WLS. La haute disponibilité/récupération d’urgence est une rubrique complexe, avec de nombreuses solutions possibles. La meilleure solution dépend de vos besoins uniques. Pour obtenir d’autres façons d’implémenter la haute disponibilité/récupération d’urgence, consultez les ressources à la fin de cet article.

Dans ce tutoriel, vous allez apprendre à :

Utilisez les meilleures pratiques optimisées Azure pour obtenir une haute disponibilité et une récupération d’urgence.
Configurez un groupe de basculement Microsoft Azure SQL Database dans des régions jumelées.
Configurez des clusters WLS jumelés sur des machines virtuelles Azure.
Configurez un Azure Traffic Manager.
Configurez des clusters WLS pour la haute disponibilité et la récupération d’urgence.
Testez le basculement du serveur principal vers le serveur secondaire.

Le diagramme suivant illustre l’architecture que vous générez :

Azure Traffic Manager case activée l’intégrité de vos régions et route le trafic en conséquence vers la couche Application. La région primaire et la région secondaire ont un déploiement complet du cluster WLS. Toutefois, seule la région primaire assure activement la maintenance des demandes réseau des utilisateurs. La région secondaire est passive et activée pour recevoir le trafic uniquement lorsque la région primaire subit une interruption de service. Azure Traffic Manager utilise la fonctionnalité d’intégrité case activée d’Azure Application Gateway pour implémenter ce routage conditionnel. Le cluster WLS principal est en cours d’exécution et le cluster secondaire est arrêté. Le RTO de géo-basculement de la couche Application dépend du temps de démarrage des machines virtuelles et de l’exécution du cluster WLS secondaire. Le RPO dépend d’Azure SQL Database, car les données sont conservées et répliquées dans le groupe de basculement Azure SQL Database.

Le niveau base de données se compose d’un groupe de basculement Azure SQL Database avec un serveur principal et un serveur secondaire. Le serveur principal est en mode lecture-écriture actif et connecté au cluster WLS principal. Le serveur secondaire est en mode prêt uniquement passif et connecté au cluster WLS secondaire. Un géobasculement bascule toutes les bases de données secondaires du groupe dans le rôle principal. Pour obtenir un RPO et un RTO de géo-basculement d’Azure SQL Database, consultez Vue d’ensemble de la continuité d’activité.

Cet article a été écrit avec le service Azure SQL Database, car l’article s’appuie sur les fonctionnalités haute disponibilité de ce service. D’autres choix de base de données sont possibles, mais vous devez prendre en compte les fonctionnalités de haute disponibilité de la base de données que vous choisissez. Pour plus d’informations, notamment sur la façon d’optimiser la configuration des sources de données pour la réplication, consultez Configuration des sources de données pour le déploiement actif-passif d’Oracle Fusion.

Prérequis

Si vous n’avez pas d’abonnement Azure, créez un compte gratuit avant de commencer.
Vérifiez que vous disposez du Owner rôle ou des User Access AdministratorContributor rôles dans l’abonnement. Vous pouvez vérifier l’attribution en suivant les étapes décrites dans Répertorier les attributions de rôles Azure à l’aide de la Portail Azure.
Préparez un ordinateur local avec Windows, Linux ou macOS installé.
Installez et configurez Git.
Installez une implémentation Java SE, version 17 ou ultérieure (par exemple, la build Microsoft d’OpenJDK).
Installez Maven, version 3.9.3 ou ultérieure.

Configurer un groupe de basculement Azure SQL Database dans des régions jumelées

Dans cette section, vous allez créer un groupe de basculement Azure SQL Database dans des régions jumelées à utiliser avec vos clusters WLS et votre application. Dans une section ultérieure, vous allez configurer WLS pour stocker ses données de session et les données du journal des transactions (TLOG) dans cette base de données. Cette pratique est cohérente avec l’architecture de disponibilité maximale (MAA) d’Oracle. Ce guide fournit une adaptation Azure pour LE MAA. Pour plus d’informations sur LE MAA, consultez Architecture de disponibilité maximale Oracle.

Tout d’abord, créez la base de données Azure SQL principale en suivant les étapes de Portail Azure de démarrage rapide : Créer une base de données unique - Azure SQL Database. Suivez les étapes jusqu’à la section « Nettoyer les ressources », mais pas l’inclusion. Utilisez les instructions suivantes lorsque vous parcourez l’article, puis revenez à cet article après avoir créé et configuré Azure SQL Database :

Lorsque vous atteignez la section Créer une base de données unique, procédez comme suit :
1. À l’étape 4 pour créer un groupe de ressources, notez la valeur du nom du groupe de ressources , par exemple myResourceGroup.
2. À l’étape 5 pour le nom de la base de données, notez la valeur du nom de la base de données , par exemple mySampleDatabase.
3. À l’étape 6 pour la création du serveur, procédez comme suit :
  1. Notez le nom du serveur unique ( par exemple, sqlserverprimary-ejb120623).
  2. Pour Emplacement, sélectionnez (États-Unis) USA Est.
  3. Pour la méthode d’authentification, sélectionnez Utiliser l’authentification SQL.
  4. Notez la valeur de connexion de l’administrateur du serveur ( par exemple, azureuser).
  5. Notez la valeur de mot de passe .
4. À l’étape 8, pour l’environnement de charge de travail, sélectionnez Développement. Examinez la description et envisagez d’autres options pour votre charge de travail.
5. À l’étape 11, pour la redondance du stockage de sauvegarde, sélectionnez Stockage de sauvegarde localement redondant. Envisagez d’autres options pour vos sauvegardes. Pour plus d’informations, consultez la section Redondance du stockage de sauvegarde des sauvegardes automatisées dans Azure SQL Database.
6. À l’étape 14, dans la configuration des règles de pare-feu, pour autoriser les services et les ressources Azure à accéder à ce serveur, sélectionnez Oui.
Lorsque vous atteignez la section Interroger la base de données, procédez comme suit :
1. À l’étape 3, entrez les informations de connexion de l’administrateur du serveur d’authentification SQL pour vous connecter.
  
  Remarque
  
  Si la connexion échoue avec un message d’erreur similaire au client avec l’adresse IP « xx.xx.xx.xx » n’est pas autorisée à accéder au serveur, sélectionnez Allowlist IP xx.xx.xx sur le serveur <votre nom-sqlserver> à la fin du message d’erreur. Attendez que les règles de pare-feu de serveur terminent la mise à jour, puis sélectionnez OK à nouveau.
2. Après avoir exécuté l’exemple de requête à l’étape 5, effacez l’éditeur et créez des tables.

Entrez la requête suivante pour créer un schéma pour TLOG.

create table TLOG_msp1_WLStore (ID DECIMAL(38) NOT NULL, TYPE DECIMAL(38) NOT NULL, HANDLE DECIMAL(38) NOT NULL, RECORD VARBINARY(MAX) NOT NULL, PRIMARY KEY (ID));
create table TLOG_msp2_WLStore (ID DECIMAL(38) NOT NULL, TYPE DECIMAL(38) NOT NULL, HANDLE DECIMAL(38) NOT NULL, RECORD VARBINARY(MAX) NOT NULL, PRIMARY KEY (ID));
create table TLOG_msp3_WLStore (ID DECIMAL(38) NOT NULL, TYPE DECIMAL(38) NOT NULL, HANDLE DECIMAL(38) NOT NULL, RECORD VARBINARY(MAX) NOT NULL, PRIMARY KEY (ID));
create table wl_servlet_sessions (wl_id VARCHAR(100) NOT NULL, wl_context_path VARCHAR(100) NOT NULL, wl_is_new CHAR(1), wl_create_time DECIMAL(20), wl_is_valid CHAR(1), wl_session_values VARBINARY(MAX), wl_access_time DECIMAL(20), wl_max_inactive_interval INTEGER, PRIMARY KEY (wl_id, wl_context_path));

Après une exécution réussie, vous verrez apparaître le message Requête réussie : lignes affectées : 0.

Ces tables de base de données sont utilisées pour stocker les données de journal des transactions (TLOG) et de session pour vos clusters et applications WLS. Pour plus d’informations, consultez Utilisation d’un magasin TLOG JDBC et utilisation d’une base de données pour les Stockage persistants (persistance JDBC).

Ensuite, créez un groupe de basculement Azure SQL Database en suivant les étapes de Portail Azure dans Configurer un groupe de basculement pour Azure SQL Database. Vous avez simplement besoin des sections suivantes : Créer un groupe de basculement et tester le basculement planifié. Procédez comme suit lorsque vous parcourez l’article, puis revenez à cet article après avoir créé et configuré le groupe de basculement Azure SQL Database :

Lorsque vous atteignez la section Créer un groupe de basculement, procédez comme suit :
1. À l’étape 5 pour créer le groupe de basculement, sélectionnez l’option permettant de créer un serveur secondaire, puis procédez comme suit :
  1. Entrez et notez le nom du groupe de basculement , par exemple, failovergroupname-ejb120623.
  2. Entrez et notez le nom du serveur unique ( par exemple, sqlserversecondary-ejb120623).
  3. Entrez le même administrateur de serveur et le même mot de passe que votre serveur principal.
  4. Pour Emplacement, sélectionnez une région différente de celle que vous avez utilisée pour la base de données primaire.
  5. Vérifiez que l’option Autoriser les services Azure à accéder au serveur est sélectionnée.
2. À l’étape 5 pour configurer les bases de données au sein du groupe, sélectionnez la base de données que vous avez créée dans le serveur principal, par exemple mySampleDatabase.
Une fois que vous avez effectué toutes les étapes de la section Tester le basculement planifié, conservez la page du groupe de basculement ouverte et utilisez-la pour le test de basculement des clusters WLS ultérieurement.

Configurer des clusters WLS jumelés sur des machines virtuelles Azure

Dans cette section, vous allez créer deux clusters WLS sur des machines virtuelles Azure à l’aide de l’offre Oracle WebLogic Server Cluster sur des machines virtuelles Azure. Le cluster usa Est est principal et est configuré comme cluster actif ultérieurement. Le cluster dans la région USA Ouest est secondaire et est configuré comme cluster passif ultérieurement.

Configurer le cluster WLS principal

Tout d’abord, ouvrez l’offre Oracle WebLogic Server Cluster sur les machines virtuelles Azure dans votre navigateur, puis sélectionnez Créer. Le volet Informations de base de l’offre doit s’afficher.

Pour remplir le volet De base , procédez comme suit :

Vérifiez que la valeur indiquée pour l’abonnement est la même que celle qui contient les rôles répertoriés dans la section conditions préalables.
Vous devez déployer l’offre dans un groupe de ressources vide. Dans le champ Groupe de ressources, sélectionnez Créer et renseignez une valeur unique pour le groupe de ressources, par exemple wls-cluster-eastus-ejb120623.
Sous Détails de l’instance, pour région, sélectionnez USA Est.
Sous Informations d’identification pour Machines Virtuelles et WebLogic, fournissez respectivement un mot de passe pour le compte d’administrateur de machine virtuelle et de WebLogic Administration istrator. Notez le nom d’utilisateur et le mot de passe pour WebLogic Administration istrator.
Conservez les valeurs par défaut pour les autres champs.
Sélectionnez Suivant pour accéder au volet Configuration TLS/SSL.

Conservez les valeurs par défaut dans le volet Configuration TLS/SSL, sélectionnez Suivant pour accéder au volet Azure Application Gateway , puis procédez comme suit.

Pour Connecter à Azure Application Gateway ?, sélectionnez Oui.
Pour sélectionner l’option de certificat TLS/SSL souhaitée, sélectionnez Générer un certificat auto-signé.
Sélectionnez Suivant pour accéder au volet Mise en réseau .

Vous devez voir tous les champs préremplis avec les valeurs par défaut dans le volet Mise en réseau . Pour enregistrer la configuration réseau, procédez comme suit :

Sélectionnez Modifier le réseau virtuel. Notez l’espace d’adressage du réseau virtuel ( par exemple, 10.1.4.0/23).
Sélectionnez cette option wls-subnet pour modifier le sous-réseau. Sous Les détails du sous-réseau, notez l’adresse de départ et la taille du sous-réseau , par exemple, 10.1.5.0 et /28.
Si vous apportez des modifications, enregistrez les modifications.
Revenez au volet Mise en réseau .
Sélectionnez Suivant pour accéder au volet Base de données .

Les étapes suivantes vous montrent comment remplir le volet Base de données :

Pour Connecter à la base de données ?, sélectionnez Oui.
Pour choisir le type de base de données, sélectionnez Microsoft SQL Server (Prise en charge de la connexion sans mot de passe) .
Pour le nom JNDI, entrez jdbc/WebLogicCafeDB.
Pour DataSource Connecter ion String, remplacez les espaces réservés par les valeurs que vous avez écrites dans la section précédente pour la base de données SQL primaire , par exemple jdbc :sqlserver ://sqlserverprimary-ejb120623.database.windows.net :1433 ; database=mySampleDatabase.
Pour le protocole de transaction global, sélectionnez Aucun.
Pour le nom d’utilisateur de la base de données, remplacez les espaces réservés par les valeurs que vous avez écrites dans la section précédente pour la base de données SQL primaire, par exemple, azureuser@sqlserverprimary-ejb120623.
Entrez le mot de passe de connexion de l’administrateur du serveur que vous avez écrit avant le mot de passe de base de données. Entrez la même valeur pour Confirmer le mot de passe.
Conservez les valeurs par défaut pour les autres champs.
Sélectionnez Revoir + créer.
Attendez que l’exécution de la validation finale soit terminée, puis sélectionnez Créer.

Après un certain temps, vous devez voir la page Déploiement dans laquelle le déploiement est en cours s’affiche.

Remarque

Si vous rencontrez des problèmes lors de l’exécution de la validation finale..., corrigez-les et réessayez.

Selon les conditions réseau et d’autres activités de votre région sélectionnée, le déploiement peut prendre jusqu’à 50 minutes. Après cela, le texte de votre déploiement doit s’afficher sur la page de déploiement.

En attendant, vous pouvez configurer le cluster WLS secondaire en parallèle.

Configurer le cluster WLS secondaire

Suivez les mêmes étapes que dans la section Configurer le cluster WLS principal pour configurer le cluster WLS secondaire dans la région USA Ouest, à l’exception des différences suivantes :

Dans le volet Informations de base , procédez comme suit :
1. Dans le champ Groupe de ressources, sélectionnez Créer et renseignez une valeur unique différente pour le groupe de ressources, par exemple wls-cluster-westtus-ejb120623.
2. Sous Détails de l’instance, pour région, sélectionnez USA Ouest.
Dans le volet Mise en réseau , procédez comme suit :
1. Pour modifier le réseau virtuel, entrez le même espace d’adressage que votre cluster WLS principal , par exemple, 10.1.4.0/23.
  
  Remarque
  
  Un message d’avertissement similaire à celui suivant doit s’afficher : l’espace d’adressage « 10.1.4.0/23 (10.1.4.0 - 10.1.5.255) » se chevauche avec l’espace d’adressage « 10.1.4.0/23 (10.1.4.0 - 10.1.5.255) » du réseau virtuel « wls-vnet ». Les réseaux virtuels avec un espace d’adressage qui se chevauchent ne peuvent pas être appairés. Si vous envisagez d’appairer ces réseaux virtuels, modifiez l’espace d’adressage « 10.1.4.0/23 (10.1.4.0 - 10.1.5.255) ». Vous pouvez ignorer ce message, car vous avez besoin de deux clusters WLS avec la même configuration réseau.
2. Pour wls-subnet, entrez la même adresse de départ et la même taille de sous-réseau que votre cluster WLS principal , par exemple, 10.1.5.0 et /28.
Dans le volet Base de données , procédez comme suit :
1. Pour DataSource Connecter ion String, remplacez les espaces réservés par les valeurs que vous avez écrites dans la section précédente de la base de données SQL secondaire ( par exemple, jdbc :sqlserver ://sqlserversecondary-ejb120623.database.windows.net :1433 ; database=mySampleDatabase.
2. Pour le nom d’utilisateur de la base de données, remplacez les espaces réservés par les valeurs que vous avez écrites dans la section précédente pour la base de données SQL secondaire, par exemple, azureuser@sqlserversecondary-ejb120623.

Mettre en miroir les paramètres réseau des deux clusters

Pendant la phase de reprise des transactions en attente dans le cluster WLS secondaire après un basculement, WLS case activée la propriété du magasin TLOG. Pour passer correctement le case activée, tous les serveurs gérés du cluster secondaire doivent avoir la même adresse IP privée que le cluster principal.

Cette section vous montre comment miroir les paramètres réseau du cluster principal au cluster secondaire.

Tout d’abord, procédez comme suit pour configurer les paramètres réseau du cluster principal une fois son déploiement terminé :

Dans le volet Vue d’ensemble de la page Déploiement , sélectionnez Accéder au groupe de ressources.
Sélectionnez l’interface adminVM_NIC_with_pub_ipréseau.
1. Sous Paramètres, sélectionnez Configurations IP.
2. Sélectionnez ipconfig1.
3. Sous Paramètres d’adresse IP privée, sélectionnez Statique pour l’allocation. Notez l’adresse IP privée.
4. Sélectionnez Enregistrer.
Revenez au groupe de ressources du cluster WLS principal, puis répétez l’étape 3 pour les interfaces mspVM1_NIC_with_pub_ipréseau, mspVM2_NIC_with_pub_ipet mspVM3_NIC_with_pub_ip.
Attendez que toutes les mises à jour se terminent. Vous pouvez sélectionner l’icône de notifications dans le Portail Azure pour ouvrir le volet Notifications pour la surveillance de l’état.
Revenez au groupe de ressources du cluster WLS principal, puis copiez le nom de la ressource avec le type de point de terminaison privé ( par exemple, 7e8c8bsaep). Utilisez ce nom pour rechercher l’interface réseau restante , par exemple, 7e8c8bsaep.nic.c0438c1a-1936-4b62-864c-6792eec3741a. Sélectionnez-le et suivez les étapes précédentes pour écrire son adresse IP privée.

Ensuite, procédez comme suit pour configurer les paramètres réseau du cluster secondaire une fois son déploiement terminé :

Dans le volet Vue d’ensemble de la page Déploiement , sélectionnez Accéder au groupe de ressources.
Pour les interfaces adminVM_NIC_with_pub_ipréseau, et mspVM2_NIC_with_pub_ipmspVM1_NIC_with_pub_ipmspVM3_NIC_with_pub_ipsuivez les étapes précédentes pour mettre à jour l’allocation d’adresses IP privées sur Static.
Attendez que toutes les mises à jour se terminent.
Pour les interfaces mspVM1_NIC_with_pub_ipréseau, mspVM2_NIC_with_pub_ipet mspVM3_NIC_with_pub_ipsuivez les étapes précédentes, mais mettez à jour l’adresse IP privée avec la même valeur utilisée avec le cluster principal. Attendez que la mise à jour actuelle de l’interface réseau se termine avant de passer à la suivante.

Remarque

Vous ne pouvez pas modifier l’adresse IP privée de l’interface réseau qui fait partie d’un point de terminaison privé. Pour miroir facilement les adresses IP privées des interfaces réseau pour les serveurs gérés, envisagez de mettre à jour l’adresse IP privée pour adminVM_NIC_with_pub_ip une adresse IP qui n’est pas utilisée. Selon l’allocation d’adresses IP privées dans vos deux clusters, vous devrez peut-être également mettre à jour l’adresse IP privée dans le cluster principal.

Le tableau suivant montre un exemple de miroir les paramètres réseau pour deux clusters :

Cluster	Interface réseau	Adresse IP privée (avant)	Adresse IP privée (après)	Ordre de mise à jour
Principal	`7e8c8bsaep.nic.c0438c1a-1936-4b62-864c-6792eec3741a`	`10.1.5.4`	`10.1.5.4`
Principal	`adminVM_NIC_with_pub_ip`	`10.1.5.7`	`10.1.5.7`
Principal	`mspVM1_NIC_with_pub_ip`	`10.1.5.5`	`10.1.5.5`
Principal	`mspVM2_NIC_with_pub_ip`	`10.1.5.8`	`10.1.5.9`	1
Principal	`mspVM3_NIC_with_pub_ip`	`10.1.5.6`	`10.1.5.6`
Secondary	`1696b0saep.nic.2e19bf46-9799-4acc-b64b-a2cd2f7a4ee1`	`10.1.5.8`	`10.1.5.8`
Secondary	`adminVM_NIC_with_pub_ip`	`10.1.5.5`	`10.1.5.4`	4
Secondary	`mspVM1_NIC_with_pub_ip`	`10.1.5.7`	`10.1.5.5`	5
Secondary	`mspVM2_NIC_with_pub_ip`	`10.1.5.6`	`10.1.5.9`	2
Secondary	`mspVM3_NIC_with_pub_ip`	`10.1.5.4`	`10.1.5.6`	3

Vérifiez l’ensemble d’adresses IP privées pour tous les serveurs managés, qui se compose du pool principal d’Azure Application Gateway que vous avez déployé dans chaque cluster. Si elle est mise à jour, procédez comme suit pour mettre à jour le pool principal Azure Application Gateway en conséquence :

Ouvrez le groupe de ressources du cluster.
Recherchez la ressource myAppGateway avec le type Application Gateway. Sélectionnez-le pour l’ouvrir.
Dans la section Paramètres, sélectionnez Pools principaux, puis sélectionnez myGatewayBackendPool.
Modifiez les valeurs des cibles back-end avec l’adresse IP privée ou les adresses privées mises à jour, puis sélectionnez Enregistrer. Attendez qu’elle se termine.
Dans la section Paramètres, sélectionnez Sondes d’intégrité, puis HTTPhealthProbe.
Veillez à tester l’intégrité du back-end avant d’ajouter la sonde d’intégrité sélectionnée, puis sélectionnez Test. Vous devez voir que la valeur d’état du pool myGatewayBackendPool principal est marquée comme saine. Si ce n’est pas le cas, case activée si les adresses IP privées sont mises à jour comme prévu et que les machines virtuelles sont en cours d’exécution, puis testez à nouveau la sonde d’intégrité. Vous devez résoudre et résoudre le problème avant de continuer.

Dans l’exemple suivant, le pool principal Azure Application Gateway pour chaque cluster est mis à jour :

Cluster	Pool principal Azure Application Gateway	Cibles principales (avant)	Cibles back-end (après)
Principal	`myGatewayBackendPool`	(`10.1.5.5`, , `10.1.5.610.1.5.8`)	(`10.1.5.5`, , `10.1.5.610.1.5.9`)
Secondary	`myGatewayBackendPool`	(`10.1.5.7`, , `10.1.5.410.1.5.6`)	(`10.1.5.5`, , `10.1.5.610.1.5.9`)

Pour automatiser les paramètres réseau miroir ing, envisagez d’utiliser Azure CLI. Pour plus d’informations, consultez Prise en main d’Azure CLI.

Vérifier les déploiements des clusters

Vous avez déployé une passerelle Azure Application Gateway et un serveur d’administration WLS dans chaque cluster. Azure Application Gateway agit comme équilibreur de charge pour tous les serveurs managés du cluster. Le serveur d’administration WLS fournit une console web pour la configuration du cluster.

Procédez comme suit pour vérifier si la console d’administration Azure Application Gateway et WLS dans chaque cluster fonctionne avant de passer à l’étape suivante :

Revenez à la page Déploiement , puis sélectionnez Sorties.
Copiez la valeur de la propriété appGatewayURL. Ajoutez la chaîne weblogic/ready , puis ouvrez cette URL dans un nouvel onglet de navigateur. Vous devez voir une page vide sans message d’erreur. Si ce n’est pas le cas, vous devez résoudre et résoudre le problème avant de continuer.
Copiez et notez la valeur de la propriété adminConsole. Ouvrez-le dans un nouvel onglet de navigateur. Vous devez voir la page de connexion de la console WebLogic Server Administration istration. Connectez-vous à la console avec le nom d’utilisateur et le mot de passe de l’administrateur WebLogic que vous avez écrits précédemment. Si vous n’êtes pas en mesure de vous connecter, vous devez résoudre et résoudre le problème avant de continuer.

Procédez comme suit pour écrire l’adresse IP d’Azure Application Gateway pour chaque cluster. Vous utilisez ces valeurs lorsque vous configurez Azure Traffic Manager ultérieurement.

Ouvrez le groupe de ressources dans lequel votre cluster est déployé , par exemple, sélectionnez Vue d’ensemble pour revenir au volet Vue d’ensemble de la page de déploiement. Ensuite, sélectionnez Accéder au groupe de ressources.
Recherchez la ressource gwip avec le type Adresse IP publique, puis sélectionnez-la pour l’ouvrir. Recherchez le champ d’adresse IP et notez sa valeur.

Configurer un Azure Traffic Manager

Dans cette section, vous allez créer un Gestionnaire de trafic Azure pour distribuer le trafic vers vos applications publiques dans les régions Azure globales. Le point de terminaison principal pointe vers Azure Application Gateway dans le cluster WLS principal, et le point de terminaison secondaire pointe vers Azure Application Gateway dans le cluster WLS secondaire.

Créez un profil Azure Traffic Manager en suivant le guide de démarrage rapide : Créez un profil Traffic Manager à l’aide de la Portail Azure. Ignorez la section Conditions préalables . Vous avez simplement besoin des sections suivantes : Créez un profil Traffic Manager, ajoutez des points de terminaison Traffic Manager et testez le profil Traffic Manager. Procédez comme suit lorsque vous parcourez ces sections, puis revenez à cet article après avoir créé et configuré Azure Traffic Manager.

Lorsque vous atteignez la section Créer un profil Traffic Manager, procédez comme suit :
1. À l’étape 2 , créez un profil Traffic Manager, procédez comme suit :
  1. Notez le nom unique du profil Traffic Manager pour name ( par exemple, tmprofile-ejb120623).
  2. Notez le nouveau nom du groupe de ressources pour le groupe de ressources , par exemple, myResourceGroupTM1.
Lorsque vous atteignez la section Ajouter des points de terminaison Traffic Manager, procédez comme suit :
1. Effectuez cette action supplémentaire après l’étape Sélectionner le profil dans les résultats de la recherche.
  1. Sous Paramètres, sélectionnez Configuration.
  2. Pour que le temps DNS soit en cours de vie (TTL), entrez 10.
  3. Sous Paramètres du moniteur de point de terminaison, pour Chemin d’accès, entrez /weblogic/ready.
  4. Sous Paramètres de basculement rapide du point de terminaison, utilisez les valeurs suivantes :
    - Pour la détection interne, entrez 10.
    - Pour le nombre toléré d’échecs, entrez 3.
    - Pour le délai d’expiration de la sonde, 5.
  5. Sélectionnez Enregistrer. Attendez qu’elle se termine.
2. À l’étape 4 pour ajouter le point de terminaison myPrimaryEndpointprincipal, procédez comme suit :
  1. Pour le type de ressource Cible, sélectionnez Adresse IP publique.
  2. Sélectionnez la liste déroulante Choisir une adresse IP publique et entrez l’adresse IP d’Application Gateway déployée dans le cluster WLS USA Est que vous avez écrit précédemment. Vous devriez voir une entrée mise en correspondance. Sélectionnez-la pour l’adresse IP publique.
3. À l’étape 6 pour ajouter un basculement / point de terminaison secondaire myFailoverEndpoint, procédez comme suit :
  1. Pour le type de ressource Cible, sélectionnez Adresse IP publique.
  2. Sélectionnez la liste déroulante Choisir une adresse IP publique et entrez l’adresse IP d’Application Gateway déployée dans le cluster WLS USA Ouest que vous avez écrit précédemment. Vous devriez voir une entrée mise en correspondance. Sélectionnez-la pour l’adresse IP publique.
4. Attendez un certain temps. Sélectionnez Actualiser jusqu’à ce que la valeur d’état du moniteur pour les deux points de terminaison soit en ligne.
Lorsque vous atteignez la section Test Traffic Manager, procédez comme suit :
1. Dans la sous-section Vérifier le nom DNS, utilisez l’étape suivante :
  1. À l’étape 3, notez le nom DNS de votre profil Traffic Manager , par exemple http://tmprofile-ejb120623.trafficmanager.net.
2. Dans la sous-section Afficher Traffic Manager en action, procédez comme suit :
  1. À l’étape 1 et 3, ajoutez /weblogic/ready au nom DNS de votre profil Traffic Manager dans votre navigateur web, par exemple http://tmprofile-ejb120623.trafficmanager.net/weblogic/ready. Vous devez voir une page vide sans message d’erreur.
  2. Après avoir effectué toutes les étapes, veillez à activer votre point de terminaison principal en référençant l’étape 2, mais remplacez Désactivé par Activé. Revenez ensuite à la page Points de terminaison .

Vous disposez maintenant des points de terminaison activés et en ligne dans le profil Traffic Manager. Conservez la page ouverte et vous l’utilisez pour surveiller l’état du point de terminaison ultérieurement.

Configurer les clusters WLS pour la haute disponibilité et la récupération d’urgence

Dans cette section, vous allez configurer des clusters WLS pour la haute disponibilité et la récupération d’urgence.

Préparer l’exemple d’application

Dans cette section, vous allez générer et empaqueter un exemple d’application CRUD Java/JakartaEE que vous déployez et exécutez ultérieurement sur des clusters WLS pour les tests de basculement.

L’application utilise la persistance de session JDBC webLogic Server pour stocker les données de session HTTP. La source jdbc/WebLogicCafeDB de données stocke les données de session pour permettre le basculement et l’équilibrage de charge sur un cluster de serveurs WebLogic. Il configure un schéma de persistance pour conserver les données coffee d’application dans la même source jdbc/WebLogicCafeDBde données.

Procédez comme suit pour générer et empaqueter l’exemple :

Utilisez les commandes suivantes pour cloner l’exemple de référentiel et case activée la balise correspondant à cet article :
```
git clone https://github.com/Azure-Samples/azure-cafe.git
cd azure-cafe
git checkout 20231206
```
Si vous voyez un message sur Detached HEAD, il est sûr d’ignorer.
Utilisez les commandes suivantes pour accéder à l’exemple de répertoire, puis compiler et empaqueter l’exemple :
```
cd weblogic-cafe
mvn clean package
```

Une fois le package généré, vous pouvez le trouver sur parent-path-to-your-local-clone>/azure-café/weblogic-café/target/weblogic-café.war.< Si vous ne voyez pas le package, veuillez résoudre le problème avant de continuer.

Déployer l’exemple d’application

Utilisez maintenant les étapes suivantes pour déployer l’exemple d’application sur les clusters, à partir du cluster principal :

Ouvrez l’adminConsole du cluster dans un nouvel onglet de votre navigateur web. Connectez-vous à la console webLogic Server Administration istration avec le nom d’utilisateur et le mot de passe du Administration istrator WebLogic que vous avez écrit précédemment.
Recherchez les déploiements wlsd>de structure>de domaine dans le volet de navigation. Sélectionnez Déploiements.
Sélectionnez Lock &Edit>Install>Upload your file(s)Choose File(s)Choose File(s).> Sélectionnez le fichier weblogic-café.war que vous avez préparé précédemment.
Sélectionnez Suivant>Suivant>Suivant. Sélectionnez cluster1 avec l’option Tous les serveurs du cluster pour les cibles de déploiement. Sélectionnez Suivant>Terminer. Sélectionnez Activer les modifications.
Basculez vers l’onglet Contrôle et sélectionnez-le weblogic-cafe dans la table des déploiements. Sélectionnez Démarrer avec l’option Maintenance de toutes les requêtes>Oui. Attendez un certain temps et actualisez la page jusqu’à ce que l’état du déploiement weblogic-cafe soit actif. Basculez vers l’onglet Surveillance et vérifiez que la racine de contexte de l’application déployée est /weblogic-café. Laissez la console d’administration WLS ouverte afin de pouvoir l’utiliser ultérieurement pour une configuration supplémentaire.

Répétez les mêmes étapes dans WebLogic Server Administration istration Console, mais pour le cluster secondaire dans la région USA Ouest.

Mettre à jour l’hôte frontal

Procédez comme suit pour faire en sorte que vos clusters WLS soient conscients d’Azure Traffic Manager. Étant donné que Azure Traffic Manager est le point d’entrée pour les demandes utilisateur, mettez à jour l’hôte frontal du cluster WebLogic Server sur le nom DNS du profil Traffic Manager, à partir du cluster principal.

Vérifiez que vous êtes connecté à WebLogic Server Administration istration Console.
Accédez à La structure>de domaine wlsd>Environment>Clusters dans le volet de navigation. Sélectionnez Clusters.
Sélectionnez-le cluster1 dans la table des clusters.
Sélectionnez Verrouiller et modifier>HTTP. Supprimez la valeur actuelle de l’hôte frontal et entrez le nom DNS du profil Traffic Manager que vous avez écrit précédemment, sans le début http:// , par exemple, tmprofile-ejb120623.trafficmanager.net. Sélectionnez Enregistrer les>modifications d’activation.

Répétez les mêmes étapes dans la console WebLogic Server Administration istration, mais pour le cluster secondaire dans la région USA Ouest.

Configurer le magasin des journaux des transactions

Ensuite, configurez le magasin des journaux des transactions JDBC pour tous les serveurs gérés de clusters, à partir du cluster principal. Cette pratique est décrite dans Utilisation des fichiers journaux des transactions pour récupérer des transactions.

Procédez comme suit sur le cluster WLS principal dans la région USA Est :

Vérifiez que vous êtes connecté à la console WebLogic Server Administration istration.
Accédez à La structure>de domaine wlsd>Environment>Servers dans le volet de navigation. Sélectionnez Serveurs.
Vous devez voir les serveurs msp1, msp2et msp3 répertoriés dans la table des serveurs.
Sélectionnez msp1>Verrou des services>& Modifier. Sous Magasin des journaux de transactions, sélectionnez JDBC.
Pour type>de source de données, sélectionnez .jdbc/WebLogicCafeDB
Vérifiez que la valeur du nom du préfixe est TLOG_msp1_, qui est la valeur par défaut. Si la valeur est différente, remplacez-la par TLOG_msp1_.
Sélectionnez Enregistrer.
Sélectionnez Serveursmsp2> et répétez les mêmes étapes, sauf que la valeur par défaut du nom de préfixe est TLOG_msp2_.
Sélectionnez Serveursmsp3> et répétez les mêmes étapes, sauf que la valeur par défaut du nom de préfixe est TLOG_msp3_.
Sélectionnez Activer les modifications.

Répétez les mêmes étapes dans WebLogic Server Administration istration Console, mais pour le cluster secondaire dans la région USA Ouest.

Redémarrez les serveurs managés du cluster principal

Ensuite, procédez comme suit pour redémarrer tous les serveurs managés du cluster principal pour que les modifications prennent effet :

Vérifiez que vous êtes connecté à WebLogic Server Administration istration Console.
Accédez à La structure>de domaine wlsd>Environment>Servers dans le volet de navigation. Sélectionnez Serveurs.
Sélectionnez l’onglet Contrôle . Sélectionnez msp1, msp2et msp3. Sélectionnez Arrêter avec l’option Lorsque le travail se termine>Oui. Sélectionnez l’icône d’actualisation. Attendez que l’état de la dernière valeur d’action soit TERMINÉ. Vous devez voir que la valeur d’état des serveurs sélectionnés est SHUTDOWN. Sélectionnez à nouveau l’icône d’actualisation pour arrêter la surveillance de l’état.
Sélectionnez msp1, msp2puis msp3 à nouveau. Sélectionnez Démarrer>oui. Sélectionnez l’icône d’actualisation. Attendez que l’état de la dernière valeur d’action soit TERMINÉ. Vous devez voir que la valeur d’état pour les serveurs sélectionnés est EN cours d’exécution. Sélectionnez à nouveau l’icône d’actualisation pour arrêter la surveillance de l’état.

Arrêter les machines virtuelles dans le cluster secondaire

À présent, procédez comme suit pour arrêter toutes les machines virtuelles du cluster secondaire pour le rendre passif :

Ouvrez la page d’accueil Portail Azure dans un nouvel onglet de votre navigateur, puis sélectionnez Toutes les ressources. Dans la zone Filtrer pour n’importe quel champ... entrez le nom du groupe de ressources où le cluster secondaire est déployé, par exemple wls-cluster-westus-ejb120623.
Sélectionnez Type égal à tous pour ouvrir le filtre Type . Pour Valeur, entrez la machine virtuelle. Vous devriez voir une entrée mise en correspondance. Sélectionnez-la pour valeur. Sélectionnez Appliquer. Vous devez voir 4 machines virtuelles répertoriées, notamment adminVM, , mspVM1mspVM2et mspVM3.
Sélectionnez cette option pour ouvrir chacune des machines virtuelles. Sélectionnez Arrêter et confirmer pour chaque machine virtuelle.
Sélectionnez l’icône de notifications dans le Portail Azure pour ouvrir le volet Notifications.
Surveillez l’événement s’arrêtant de la machine virtuelle pour chaque machine virtuelle jusqu’à ce que la valeur soit arrêtée avec succès. Conservez la page ouverte afin de pouvoir l’utiliser pour le test de basculement ultérieurement.

À présent, basculez vers l’onglet du navigateur dans lequel vous surveillez l’état des points de terminaison du Traffic Manager. Actualisez la page jusqu’à ce que vous voyiez que le point de terminaison myFailoverEndpoint est détérioré et que le point de terminaison myPrimaryEndpoint est en ligne.

Remarque

Une solution de haute disponibilité/récupération d’urgence prête pour la production souhaite probablement obtenir un RTO inférieur en laissant les machines virtuelles en cours d’exécution, mais en arrêtant uniquement le logiciel WLS s’exécutant sur les machines virtuelles. Ensuite, en cas de basculement, les machines virtuelles sont déjà en cours d’exécution et le logiciel WLS prend moins de temps pour démarrer. Cet article a choisi d’arrêter les machines virtuelles, car le logiciel déployé par le cluster Oracle WebLogic Server sur des machines virtuelles Azure démarre automatiquement le logiciel WLS au démarrage des machines virtuelles.

Vérifier l’application

Étant donné que le cluster principal est opérationnel, il agit en tant que cluster actif et gère toutes les demandes utilisateur routées par votre profil Traffic Manager.

Ouvrez le nom DNS de votre profil Azure Traffic Manager dans un nouvel onglet du navigateur, en ajoutant la racine de contexte /weblogic-café de l’application déployée, par exemple http://tmprofile-ejb120623.trafficmanager.net/weblogic-cafe. Créez un café avec le nom et le prix - par exemple, Café 1 avec le prix 10. Cette entrée est conservée dans la table de données de l’application et dans la table de session de la base de données. L’interface utilisateur que vous voyez doit ressembler à la capture d’écran suivante :

Si votre interface utilisateur ne ressemble pas, résolvez et résolvez le problème avant de continuer.

Conservez la page ouverte afin de pouvoir l’utiliser pour les tests de basculement ultérieurement.

Tester le basculement du serveur principal vers le serveur secondaire

Pour tester le basculement, vous basculez manuellement votre serveur de base de données principal et votre cluster vers le serveur de base de données secondaire et le cluster, puis effectuez une restauration automatique à l’aide du Portail Azure dans cette section.

Basculement vers le site secondaire

Tout d’abord, procédez comme suit pour arrêter les machines virtuelles dans le cluster principal :

Recherchez le nom de votre groupe de ressources dans lequel le cluster WLS principal est déployé, par exemple wls-cluster-eastus-ejb120623. Suivez ensuite les étapes décrites dans la section Arrêter les machines virtuelles du cluster secondaire, mais remplacez le groupe de ressources cible par votre cluster WLS principal pour arrêter toutes les machines virtuelles de ce cluster.
Basculez vers l’onglet navigateur de votre Traffic Manager, actualisez la page jusqu’à ce que la valeur d’état du moniteur du point de terminaison myPrimaryEndpoint devienne détériorée.
Basculez vers l’onglet du navigateur de l’exemple d’application et actualisez la page. Vous devriez voir le délai d’expiration de la passerelle 504 ou la passerelle incorrecte 502, car aucun point de terminaison n’est accessible.

Ensuite, procédez comme suit pour basculer Azure SQL Database du serveur principal vers le serveur secondaire :

Basculez vers l’onglet navigateur de votre groupe de basculement Azure SQL Database.
Sélectionnez Basculement>Oui.
Attendez qu’elle se termine.

Ensuite, procédez comme suit pour démarrer tous les serveurs du cluster secondaire :

Basculez vers l’onglet du navigateur dans lequel vous avez arrêté toutes les machines virtuelles du cluster secondaire.
Sélectionnez la machine virtuelle adminVM. Cliquez sur Démarrer.
Surveillez l’événement de démarrage de la machine virtuelle dans adminVM le volet Notifications et attendez que la valeur devienne démarrée.
Basculez vers l’onglet navigateur de la console WebLogic Server Administration istration pour le cluster secondaire, puis actualisez la page jusqu’à ce que vous voyiez la page d’accueil pour la connexion.
Revenez à l’onglet du navigateur dans lequel toutes les machines virtuelles du cluster secondaire sont répertoriées. Pour les machines virtuelles mspVM1, mspVM2puis mspVM3sélectionnez chacun d’eux pour l’ouvrir, puis sélectionnez Démarrer.
Pour les machines virtuelles mspVM1, mspVM2et mspVM3surveiller l’événement à partir de la machine virtuelle dans le volet Notifications , attendez que les valeurs soient démarrées.

Enfin, procédez comme suit pour vérifier l’exemple d’application une fois que le point de terminaison myFailoverEndpoint est dans l’état En ligne :

Basculez vers l’onglet navigateur de votre Traffic Manager, puis actualisez la page jusqu’à ce que la valeur d’état du moniteur du point de terminaison myFailoverEndpoint entre dans l’état En ligne.
Basculez vers l’onglet du navigateur de l’exemple d’application et actualisez la page. Vous devez voir les mêmes données conservées dans la table de données de l’application et la table de session affichée dans l’interface utilisateur, comme illustré dans la capture d’écran suivante :

Si vous n’observez pas ce comportement, cela peut être dû au fait que Traffic Manager prend le temps de mettre à jour DNS pour qu’il pointe vers le site de basculement. Le problème peut également être que votre navigateur a mis en cache le résultat de résolution de noms DNS qui pointe vers le site ayant échoué. Attendez un certain temps et actualisez à nouveau la page.

Remarque

Une solution de haute disponibilité/récupération d’urgence prête pour la production compte pour la copie continue de la configuration WLS du serveur principal vers les clusters secondaires selon une planification régulière. Pour plus d’informations sur la procédure à suivre, consultez les références à la documentation Oracle à la fin de cet article.

Pour automatiser le basculement, envisagez d’utiliser des alertes sur les métriques Traffic Manager et Azure Automation. Pour plus d’informations, consultez la section Alertes sur les métriques Traffic Manager des métriques et alertes Traffic Manager et Utiliser une alerte pour déclencher un runbook Azure Automation.

Restauration automatique vers le site principal

Utilisez les mêmes étapes dans la section Basculement vers le site secondaire pour effectuer une restauration automatique vers le site principal, y compris le serveur de base de données et le cluster, à l’exception des différences suivantes :

Tout d’abord, arrêtez les machines virtuelles dans le cluster secondaire. Vous devez voir que le point de terminaison myFailoverEndpoint devient détérioré.
Ensuite, basculez Azure SQL Database du serveur secondaire vers le serveur principal.
Ensuite, démarrez tous les serveurs dans le cluster principal.
Enfin, vérifiez l’exemple d’application une fois le point de terminaison myPrimaryEndpointen ligne.

Nettoyer les ressources

Si vous ne souhaitez pas continuer à utiliser les clusters WLS et d’autres composants, procédez comme suit pour supprimer les groupes de ressources pour propre les ressources utilisées dans ce tutoriel :

Entrez le nom du groupe de ressources des serveurs Azure SQL Database (par exemple) myResourceGroupdans la zone de recherche en haut de la Portail Azure, puis sélectionnez le groupe de ressources correspondant dans les résultats de la recherche.
Sélectionnez Supprimer le groupe de ressources.
Dans Entrer le nom du groupe de ressources pour confirmer la suppression, entrez le nom du groupe de ressources.
Sélectionnez Supprimer.
Répétez les étapes 1 à 4 pour le groupe de ressources du Traffic Manager , par exemple myResourceGroupTM1.
Répétez les étapes 1 à 4 pour le groupe de ressources du cluster WLS principal , par exemple wls-cluster-eastus-ejb120623.
Répétez les étapes 1 à 4 pour le groupe de ressources du cluster WLS secondaire, par exemple wls-cluster-westus-ejb120623.

Étapes suivantes

Dans ce tutoriel, vous allez configurer une solution haute disponibilité/récupération d’urgence composée d’un niveau d’infrastructure d’application actif-passif avec un niveau de base de données actif-passif, et dans laquelle les deux niveaux s’étendent sur deux sites géographiquement différents. Sur le premier site, la couche Infrastructure d’application et la couche Base de données sont actives. Sur le deuxième site, le domaine secondaire est arrêté et la base de données secondaire est en veille.

Poursuivez l’exploration des références suivantes pour obtenir d’autres options pour générer des solutions haute disponibilité/récupération d’urgence et exécuter WLS sur Azure :

Solutions de récupération d’urgence pour les produits Oracle Fusion Middleware

Documentation sur la fiabilité Azure

Créer des solutions pour la haute disponibilité

Basculement automatique à l’aide d’Azure Traffic Manager

En savoir plus sur Oracle WebLogic sur les machines virtuelles Azure

En savoir plus sur Oracle WebLogic sur AKS