Tutoriel : Migrer Oracle WebLogic Server vers des machines virtuelles Azure avec haute disponibilité et récupération d’urgence

Article
09/04/2024

Ce tutoriel montre une méthode simple et efficace pour mettre en œuvre la haute disponibilité et la récupération d’urgence (HA/DR) pour Java en utilisant Oracle WebLogic Server (WLS) sur des machines virtuelles (VMs) Azure. La solution illustre comment atteindre un faible objectif de temps de récupération (RTO) et un faible objectif de point de récupération (RPO) en utilisant une simple application Jakarta EE pilotée par une base de données et exécutée sur WLS. La HA/DR est un sujet complexe, avec de nombreuses solutions possibles. La meilleure solution dépend de vos exigences spécifiques. Pour d’autres façons de mettre en œuvre la HA/DR, veuillez consulter les ressources à la fin de cet article.

Dans ce tutoriel, vous allez apprendre à :

Utilisez les bonnes pratiques optimisées pour Azure pour atteindre la haute disponibilité et la récupération d’urgence.
Configurez un groupe de basculement de base de données SQL Azure dans des régions appairées.
Configurez des clusters WLS jumelés sur des machines virtuelles Azure.
Configurez un Azure Traffic Manager
Configurez les clusters WLS pour la haute disponibilité et la récupération d’urgence.
Testez le basculement du principal au secondaire

Le schéma suivant illustre l’architecture que vous construisez :

Azure Traffic Manager vérifie la santé de vos régions et dirige le trafic en conséquence vers le niveau d’application. Les deux régions, primaire et secondaire, ont un déploiement complet du cluster WLS. Cependant, seule la région primaire gère activement les 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é de vérification d’intégrité de l’Azure Application Gateway pour mettre en œuvre ce routage conditionnel. Le cluster WLS principal est en cours d’exécution et le cluster secondaire est arrêté. Le RTO de basculement géographique 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 de l’Azure SQL Database, car les données sont persistantes et répliquées dans le groupe de basculement d’Azure SQL Database.

Le niveau de la base de données se compose d’un groupe de basculement de base de données SQL Azure 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 passif uniquement en lecture 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 le RPO et le RTO du basculement géographique de la base de données SQL Azure, veuillez consulter la section Vue d’ensemble de la continuité d’activité.

Cet article a été rédigé en utilisant le service Azure SQL Database car l’article s’appuie sur les fonctionnalités de haute disponibilité (HA) de ce service. D’autres choix de bases de données sont possibles, mais vous devez tenir compte des fonctionnalités de haute disponibilité de la base de données que vous choisissez. Pour plus d’informations, y compris sur la façon d’optimiser la configuration des sources de données pour la réplication, veuillez consulter la section Configuration des sources de données pour un déploiement Oracle Fusion Middleware Active-Passive.

Prérequis

Un abonnement Azure. Si vous n’avez pas d’abonnement Azure, créez un compte gratuit avant de commencer.
Assurez-vous d’avoir soit le rôle Owner, soit les rôles Contributor et User Access Administrator dans l’abonnement. Vous pouvez vérifier l’affectation en suivant les étapes de la section Liste des affectations de rôles Azure en utilisant le portail Azure.
Préparez une machine locale avec Windows, Linux ou macOS installé.
Installez et configurez Git.
Installez une implémentation de Java SE, version 17 ou ultérieure (par exemple, la build Microsoft d’OpenJDK).
Installez Maven, version 3.9.3 ou une version ultérieure.

Configurez un groupe de basculement de base de données SQL Azure dans des régions appairées

Dans cette section, vous créez un groupe de basculement de base de données SQL Azure dans des régions appairées pour une utilisation avec vos clusters WLS et votre application. Dans une section ultérieure, vous configurez WLS pour stocker ses données de session et ses données de journal de transactions (TLOG) dans cette base de données. Cette pratique est conforme à l’architecture de disponibilité maximale (MAA) d’Oracle. Ces conseils fournissent une adaptation pour Azure de la MAA. Pour plus d’informations sur la MAA, veuillez consulter la section Architecture de disponibilité maximale d’Oracle.

Tout d’abord, créez la base de données SQL Azure principale en suivant les étapes du portail Azure dans la section Prise en main rapide : Créer une base de données unique - Azure SQL Database. Suivez les étapes jusqu’à, mais sans inclure, la section « Nettoyer les ressources ». Suivez les instructions suivantes en parcourant 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, utilisez les étapes suivantes :
1. À l’étape 4 pour la création d’un nouveau groupe de ressources, mettez de côté la valeur Nom du groupe de ressources, par exemple myResourceGroup.
2. À l’étape 5 pour le nom de la base de données, mettez de côté la valeur Nom de la base de données, par exemple mySampleDatabase.
3. À l’étape 6 pour la création du serveur, utilisez les étapes suivantes :
  1. Mettez de côté le nom unique du serveur, 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. Mettez de côté la valeur Login de l’administrateur du serveur, par exemple azureuser.
  5. Mettez de côté la valeur Mot de passe.
4. À l’étape 8, pour l’Environnement de travail, sélectionnez Développement. Regardez 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, veuillez consulter la section Redondance du stockage de sauvegarde de la rubrique Sauvegardes automatisées dans Azure SQL Database.
6. À l’étape 14, dans la configuration des Règles du pare-feu, pour Permettre aux services et ressources Azure d’accéder à ce serveur, sélectionnez Oui.
Lorsque vous atteignez la section Interroger la base de données, utilisez les étapes suivantes :
1. À l’étape 3, entrez vos informations de connexion d’administrateur du serveur Authentification SQL pour vous connecter.
  
  Remarque
  
  Si la connexion échoue avec un message d’erreur similaire à Client avec l’adresse IP « xx.xx.xx.xx » n’est pas autorisé à accéder au serveur, sélectionnez Autoriser l’IP xx.xx.xx.xx sur le serveur <votre-nom-de-serveur-sql> à la fin du message d’erreur. Attendez que les règles du pare-feu du serveur soient mises à jour, puis sélectionnez de nouveau OK.
2. Après avoir exécuté la requête d’exemple à l’étape 5, effacez l’éditeur et créez des tables.

Entrez la requête suivante pour créer le 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 journaux de transactions (TLOG) et les données de session pour vos clusters WLS et votre application. Pour plus d’informations, veuillez consulter la section Utilisation d’un magasin JDBC TLOG et la rubrique Utilisation d’une base de données pour le stockage persistant (Persistance JDBC).

Ensuite, créez un groupe de basculement de base de données SQL Azure en suivant les étapes du portail Azure dans la section Configurer un groupe de basculement pour Azure SQL Database. Vous n’avez besoin que des sections suivantes : Créer un groupe de basculement et Tester le basculement planifié. Utilisez les étapes suivantes pendant que vous suivez l’article, puis revenez à cet article après avoir créé et configuré le groupe de basculement de la base de données SQL Azure :

Lorsque vous atteignez la section Créer un groupe de basculement, procédez comme suit :
1. À l’étape 5 pour la création du groupe de basculement, sélectionnez l’option pour créer un nouveau serveur secondaire, puis procédez comme suit :
  1. Entrez et sauvegardez le nom du groupe de basculement, par exemple failovergroupname-ejb120623.
  2. Entrez et sauvegardez le nom unique du serveur, par exemple sqlserversecondary-ejb120623.
  3. Entrez le même administrateur de serveur et mot de passe que pour 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 principale.
  5. Assurez-vous que Autoriser les services Azure à accéder au serveur est sélectionné.
2. À l’étape 5 pour la configuration des Bases de données au sein du groupe, sélectionnez la base de données que vous avez créée sur le serveur principal, par exemple mySampleDatabase.
Après avoir complété toutes les étapes de la section Tester le basculement planifié, laissez la page du groupe de basculement ouverte et utilisez-la pour le test de basculement des clusters WLS plus tard.

Configurez 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 en utilisant l’offre Oracle WebLogic Server Cluster on Azure VMs. Le cluster dans USA Est est le primaire et sera configuré comme le cluster actif plus tard. Le cluster dans USA Ouest est le secondaire et sera configuré comme le cluster passif plus tard.

Configurer le cluster WLS primaire

Tout d’abord, ouvrez l’offre Oracle WebLogic Server Cluster sur Azure VMs dans votre navigateur et sélectionnez Créer. Vous devriez voir le volet Informations de base de l’offre.

Utilisez les étapes suivantes pour remplir le volet Informations de base :

Assurez-vous que la valeur affichée pour Abonnement est la même que celle qui contient les rôles listés dans la section des prérequis.
Vous devez déployer l’offre dans un groupe de ressources vide. Dans le champ Groupe de ressources, sélectionnez Créer nouveau et remplissez 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 administrateur de la VM et l’administrateur WebLogic. Sauvegardez le nom d’utilisateur et le mot de passe pour WebLogic Administrator.
Laissez les paramètres par défaut pour les autres champs.
Sélectionnez Suivant pour accéder au volet Configuration TLS/SSL.

Laissez les paramètres 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 Se 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 Networking (Mise en réseau).

Vous devriez voir tous les champs pré-remplis avec les valeurs par défaut dans le volet Réseau. Procédez comme suit pour enregistrer la configuration réseau :

Sélectionnez Modifier le réseau virtuel. Mettez de côté l’espace d’adressage du réseau virtuel, par exemple 10.1.4.0/23.
Sélectionnez wls-subnet pour modifier le sous-réseau. Sous Détails du sous-réseau, mettez de côté l’adresse de départ et la taille du sous-réseau, par exemple 10.1.5.0 et /28.
Si vous effectuez des modifications, enregistrez les changements.
Revenez au volet Réseau.
Sélectionnez Suivant pour passer au volet Base de données.

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

Pour Se 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 JNDI Name, entrez jdbc/WebLogicCafeDB.
Pour Chaîne de connexion DataSource, remplacez les valeurs de substitution par les valeurs que vous avez enregistrées dans la section précédente pour la base de données SQL principale, par exemple jdbc:sqlserver://sqlserverprimary-ejb120623.database.windows.net:1433;database=mySampleDatabase.
Pour Protocole de transaction global, sélectionnez Aucun.
Pour Nom d’utilisateur de la base de données, remplacez les valeurs de substitution par les valeurs que vous avez enregistrées dans la section précédente pour la base de données SQL principale, par exemple azureuser@sqlserverprimary-ejb120623.
Entrez le mot de passe d’administrateur du serveur que vous avez précédemment enregistré pour Mot de passe de la base de données. Entrez la même valeur pour Confirmer le mot de passe.
Laissez les valeurs par défaut pour les autres champs.
Sélectionnez Revoir + créer.
Attendez que Exécution de la validation finale... soit terminée avec succès, puis sélectionnez Créer.

Après un moment, vous devriez voir la page Déploiement où Le déploiement est en cours est affiché.

Remarque

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

En fonction des conditions réseau et de l’activité dans votre région sélectionnée, le déploiement peut prendre jusqu’à 50 minutes pour se terminer. Après cela, le texte Votre déploiement a été effectué doit s’afficher dans la page de déploiement.

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

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 un nouveau et remplissez une valeur unique différente pour le groupe de ressources, par exemple wls-cluster-westus-ejb120623.
2. Sous Détails de l’instance, pour Région, sélectionnez USA Ouest.
Dans le volet Réseau, procédez comme suit :
1. Pour Modifier le réseau virtuel, saisissez le même espace d’adressage du réseau virtuel que votre cluster WLS principal, par exemple 10.1.4.0/23.
  
  Remarque
  
  Vous devriez voir un message d’avertissement similaire au suivant : L’espace d’adressage « 10.1.4.0/23 (10.1.4.0 - 10.1.5.255) » chevauche 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 des espaces d’adressage qui se chevauchent ne peuvent pas être appairés. Si vous avez l’intention de faire l’appairage de 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, saisissez 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 Chaîne de connexion DataSource, remplacez les valeurs de substitution par les valeurs que vous avez enregistrées dans la section précédente pour la base de données SQL secondaire, par exemple jdbc:sqlserver://sqlserversecondary-ejb120623.database.windows.net:1433;database=mySampleDatabase.
2. Pour Nom d’utilisateur de la base de données, remplacez les valeurs de substitution par les valeurs que vous avez enregistrées dans la section précédente pour la base de données SQL secondaire, par exemple azureuser@sqlserversecondary-ejb120623.

Refléter les paramètres réseau pour les deux clusters

Lors de la reprise des transactions en attente dans le cluster WLS secondaire après un basculement, WLS vérifie la propriété du magasin TLOG. Pour réussir cette vérification, tous les serveurs gérés dans le cluster secondaire doivent avoir la même adresse IP privée que le cluster principal.

Cette section vous montre comment refléter les paramètres réseau du cluster principal sur le 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 Aller au groupe de ressources.
Sélectionnez l’interface réseau adminVM_NIC_with_pub_ip.
1. Sous Paramètres, sélectionnez Configurations IP.
2. Sélectionnez ipconfig1.
3. Sous Paramètres de l’adresse IP privée, sélectionnez Statique pour Allocation. Mettez de côté l’adresse IP privée.
4. Cliquez sur Enregistrer.
Revenez au groupe de ressources du cluster WLS principal, puis répétez l’étape 3 pour les interfaces réseau mspVM1_NIC_with_pub_ip, mspVM2_NIC_with_pub_ip et mspVM3_NIC_with_pub_ip.
Attendez que toutes les mises à jour soient terminées. Vous pouvez sélectionner l’icône de notifications dans le portail Azure pour ouvrir le volet Notifications pour surveiller l’état.
Revenez au groupe de ressources du cluster WLS principal, puis copiez le nom de la ressource de type Point de terminaison privé, par exemple 7e8c8bsaep. Utilisez ce nom pour trouver l’interface réseau restante, par exemple 7e8c8bsaep.nic.c0438c1a-1936-4b62-864c-6792eec3741a. Sélectionnez-la et suivez les étapes précédentes pour obtenir 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 Aller au groupe de ressources.
Pour les interfaces réseau adminVM_NIC_with_pub_ip, mspVM1_NIC_with_pub_ip, mspVM2_NIC_with_pub_ip et mspVM3_NIC_with_pub_ip, suivez les étapes précédentes pour mettre à jour l’allocation de l’adresse IP privée en Statique.
Attendez que toutes les mises à jour soient terminées.
Pour les interfaces réseau mspVM1_NIC_with_pub_ip, mspVM2_NIC_with_pub_ip et mspVM3_NIC_with_pub_ip, suivez les étapes précédentes mais mettez à jour l’adresse IP privée avec la même valeur que celle utilisée pour le cluster principal. Attendez que la mise à jour actuelle de l’interface réseau soit terminée avant de passer à la suivante.

Remarque

Vous ne pouvez pas changer l’adresse IP privée de l’interface réseau qui fait partie d’un point de terminaison privé. Pour refléter 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 non utilisée. Selon l’allocation des 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 reflet des 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 des adresses IP privées pour tous les serveurs gérés, qui composent le pool backend de l’Azure Application Gateway que vous avez déployé dans chaque cluster. S’il est mis à jour, procédez comme suit pour mettre à jour le pool backend de l’Azure Application Gateway en conséquence :

Ouvrez le groupe de ressources du cluster.
Trouvez la ressource myAppGateway de type Passerelle d’application. Sélectionnez-le pour l’ouvrir.
Dans la section Paramètres, sélectionnez Pools backend, puis sélectionnez myGatewayBackendPool.
Changez les valeurs des Cibles backend avec l’adresse IP privée ou les adresses IP mises à jour, puis sélectionnez Enregistrer. Attendez que cela soit terminé.
Dans la section Paramètres, sélectionnez Sondes d’intégrité, puis sélectionnez HTTPhealthProbe.
Assurez-vous que Je veux tester l’intégrité du backend avant d’ajouter la sonde d’intégrité est sélectionné, puis sélectionnez Tester. Vous devriez voir que la valeur État du pool backend myGatewayBackendPool est marquée comme saine. Si ce n’est pas le cas, vérifiez si les adresses IP privées sont mises à jour comme prévu et si les machines virtuelles sont en cours d’exécution, puis testez à nouveau la sonde d’intégrité. Vous devez résoudre le problème avant de continuer.

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

Cluster	Azure Application Gateway pool backend	Cibles backend (avant)	Cibles backend (après)
Principal	`myGatewayBackendPool`	(`10.1.5.5`, `10.1.5.8`, `10.1.5.6`)	(`10.1.5.5`, `10.1.5.9`, `10.1.5.6`)
Secondary	`myGatewayBackendPool`	(`10.1.5.7`, `10.1.5.6`, `10.1.5.4`)	(`10.1.5.5`, `10.1.5.9`, `10.1.5.6`)

Pour automatiser le reflet des paramètres réseau, envisagez d’utiliser Azure CLI. Pour plus d’informations, consultez Prise en main d’Azure CLI.

Vérifiez les déploiements des clusters

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

Procédez comme suit pour vérifier si la passerelle d’application Azure et la console d’administration WLS dans chaque cluster fonctionnent 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 du navigateur. Vous devriez voir une page vide sans message d’erreur. Si vous ne le faites pas, vous devez diagnostiquer et résoudre le problème avant de continuer.
Copiez et sauvegardez la valeur de la propriété adminConsole. Ouvrez-la dans un nouvel onglet de votre navigateur. Vous devriez voir la page de connexion de la Console d’administration WebLogic Server. Connectez-vous à la console avec le nom d’utilisateur et le mot de passe de l’administrateur WebLogic que vous avez enregistrés précédemment. Si vous ne parvenez pas à vous connecter, vous devez diagnostiquer et résoudre le problème avant de continuer.

Procédez comme suit pour obtenir l’adresse IP de la passerelle d’application Azure pour chaque cluster. Vous utiliserez ces valeurs lors de la configuration ultérieure d’Azure Traffic Manager.

Ouvrez le groupe de ressources où 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 Aller au groupe de ressources.
Trouvez la ressource gwip avec le type Adresse IP publique, puis sélectionnez-la pour l’ouvrir. Recherchez le champ Adresse IP et sauvegardez sa valeur.

Configurez un Azure Traffic Manager

Dans cette section, vous créez un Azure Traffic Manager pour distribuer le trafic vers vos applications publiques à travers les régions Azure mondiales. Le point de terminaison principal pointe vers la passerelle d’application Azure dans le cluster WLS principal, et le point de terminaison secondaire pointe vers la passerelle d’application Azure dans le cluster WLS secondaire.

Créez un profil Azure Traffic Manager en suivant Prise en main rapide : Créer un profil Traffic Manager à l’aide du portail Azure. Ignorez la section Prérequis. Vous avez seulement besoin des sections suivantes : Créer un profil Traffic Manager, Ajouter des points de terminaison Traffic Manager, et Tester le profil Traffic Manager. Procédez comme suit pendant ces sections, puis revenez à cet article après avoir créé et configuré le Traffic Manager Azure.

Lorsque vous arrivez à la section Créer un profil Traffic Manager, procédez comme suit :
1. À l’étape 2 Créer un profil Traffic Manager, procédez comme suit :
  1. Enregistrez le nom unique du profil Traffic Manager pour Nom : par exemple, tmprofile-ejb120623.
  2. Enregistrez le nom du nouveau groupe de ressources pour 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 recherche.
  1. Sous Paramètres, sélectionnez Configuration.
  2. Pour Durée de vie du DNS (TTL), entrez 10.
  3. Sous Paramètres du moniteur de point de terminaison, pour Chemin, entrez /weblogic/ready.
  4. Sous Paramètres de basculement rapide du point de terminaison, utilisez les valeurs suivantes :
    - Pour Intervalle de sondage interne, entrez 10.
    - Pour Nombre toléré d’échecs, entrez 3.
    - Pour Délai d’expiration du sondage (probe), entrez 5.
  5. Cliquez sur Enregistrer. Attendez que cela soit terminé.
2. À l’étape 4 pour l’ajout du point de terminaison principal myPrimaryEndpoint, procédez comme suit :
  1. Pour 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 de la passerelle d’application déployée dans le cluster WLS de USA Est que vous avez sauvegardée précédemment. Vous devriez voir une entrée correspondante. Sélectionnez-la pour Adresse IP publique.
3. À l’étape 6 pour l’ajout d’un point de terminaison de basculement / secondaire myFailoverEndpoint, procédez comme suit :
  1. Pour 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 de la passerelle d’application déployée dans le cluster WLS de USA Ouest que vous avez sauvegardée précédemment. Vous devriez voir une entrée correspondante. Sélectionnez-la pour Adresse IP publique.
4. Patientez un moment. Sélectionnez Actualiser jusqu’à ce que la valeur État du moniteur pour les deux points de terminaison soit En ligne.
Lorsque vous atteignez la section Tester le profil Traffic Manager, procédez comme suit :
1. Dans la sous-section Vérifier le nom DNS, procédez comme suit :
  1. À l’étape 3, sauvegardez le nom DNS de votre profil Traffic Manager, par exemple http://tmprofile-ejb120623.trafficmanager.net.
2. Dans la sous-section Voir 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 devriez voir une page vide sans message d’erreur.
  2. Après avoir terminé toutes les étapes, assurez-vous d’activer votre point de terminaison principal en vous référant à l’étape 2, mais remplacez Désactivé par Activé. Ensuite, revenez à la page Points de terminaison.

Vous avez maintenant les deux points de terminaison Activé et En ligne dans le profil Traffic Manager. Gardez la page ouverte et utilisez-la pour surveiller ultérieurement l’état du point de terminaison.

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

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

Préparer l’application d’exemple

Dans cette section, vous construisez et packagez une application CRUD Java/JakartaEE d’exemple que vous déploierez et exécuterez plus tard sur les clusters WLS pour le test de basculement.

L’application utilise la persistance de session JDBC de WebLogic Server pour stocker les données de session HTTP. La source de données jdbc/WebLogicCafeDB stocke les données de session pour permettre le basculement et l’équilibrage de charge entre les clusters de serveurs WebLogic. Elle configure un schéma de persistance pour persister les données de l’application coffee dans la même source de données jdbc/WebLogicCafeDB.

Utilisez les étapes suivantes pour construire et package l’exemple :

Utilisez les commandes suivantes pour cloner le référentiel d’exemples et vérifier la balise correspondante à cet article :
```
git clone https://github.com/Azure-Samples/azure-cafe.git
cd azure-cafe
git checkout 20231206
```
Si vous voyez un message concernant Detached HEAD, il est sans danger de l’ignorer.
Utilisez les commandes suivantes pour naviguer jusqu’au répertoire d’exemples, puis compilez et packagez l’exemple :
```
cd weblogic-cafe
mvn clean package
```

Lorsque le package est généré avec succès, vous pouvez le trouver à l’emplacement <parent-path-to-your-local-clone>/azure-cafe/weblogic-cafe/target/weblogic-cafe.war. Si vous ne voyez pas le package, veuillez résoudre le problème avant de continuer.

Déployer l’exemple d’application

Procédez comme suit pour déployer l’application d’exemple sur les clusters, en commençant par le cluster principal :

Ouvrez la adminConsole du cluster dans un nouvel onglet de votre navigateur Web. Connectez-vous à la console d’administration WebLogic avec le nom d’utilisateur et le mot de passe de l’administrateur WebLogic que vous avez enregistrés précédemment.
Localisez Structure de domaine>wlsd>Déploiements dans le volet de navigation. Sélectionnez Déploiements.
Sélectionnez Verrouiller & Modifier>Installer>Télécharger votre ou vos fichiers>Choisir le fichier. Sélectionnez le fichier weblogic-cafe.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.
Passez à l’onglet Contrôle et sélectionnez weblogic-cafe dans le tableau des déploiements. Sélectionnez Démarrer avec l’option Servir toutes les demandes>Oui. Attendez un moment et actualisez la page jusqu’à ce que vous voyiez que l’état du déploiement weblogic-cafe est Actif. Passez à l’onglet Surveillance et vérifiez que le chemin racine du contexte de l’application déployée est /weblogic-cafe. Gardez la console d’administration WLS ouverte afin de pouvoir l’utiliser plus tard pour une configuration supplémentaire.

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

Mettre à jour l’hôte frontal

Procédez comme suit pour informer vos clusters WLS de l’existence du Traffic Manager Azure. Comme le Traffic Manager Azure est le point d’entrée des demandes des utilisateurs, mettez à jour l’Hôte frontal du cluster WebLogic Server avec le nom DNS du profil Traffic Manager, en commençant par le cluster principal.

Assurez-vous d’être connecté à la console d’administration WebLogic Server.
Naviguez vers Structure de domaine>wlsd>Environnement>Clusters dans le volet de navigation. Sélectionnez Clusters.
Sélectionnez cluster1 dans le tableau des clusters.
Sélectionnez Verrouiller & Modifier>HTTP. Supprimez la valeur actuelle pour Hôte frontal et entrez le nom DNS du profil Traffic Manager que vous avez sauvegardé précédemment, sans le http:// préfixe, par exemple tmprofile-ejb120623.trafficmanager.net. Sélectionnez Enregistrer>Activer les modifications.

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

Configurer le magasin des journaux de transactions

Ensuite, configurez le magasin de journaux JDBC pour toutes les transactions des serveurs gérés des clusters, en commençant par le cluster principal. Cette pratique est décrite dans Utilisation des fichiers journaux de transactions pour récupérer les transactions.

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

Assurez-vous d’être connecté à la console d’administration WebLogic Server.
Naviguez vers Structure de domaine>wlsd>Environnement>Serveurs dans le volet de navigation. Sélectionnez Serveurs.
Vous devriez voir les serveurs msp1, msp2 et msp3 répertoriés dans le tableau des serveurs.
Sélectionnez msp1>Services>Verrouiller & Modifier. Sous Magasin des journaux de transactions, sélectionnez JDBC.
Pour Type>Source de données, sélectionnez jdbc/WebLogicCafeDB.
Confirmez que la valeur pour Nom du préfixe est TLOG_msp1_, qui est la valeur par défaut. Si la valeur est différente, changez-la en TLOG_msp1_.
Cliquez sur Enregistrer.
Sélectionnez Serveurs>msp2, et répétez les mêmes étapes, sauf que la valeur par défaut pour Nom du préfixe est TLOG_msp2_.
Sélectionnez Serveurs>msp3, et répétez les mêmes étapes, sauf que la valeur par défaut pour Nom du préfixe est TLOG_msp3_.
Sélectionnez Activer les modifications.

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

Redémarrez les serveurs gérés du cluster principal

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

Assurez-vous d’être connecté à la console d’administration WebLogic Server.
Naviguez vers Structure de domaine>wlsd>Environnement>Serveurs dans le volet de navigation. Sélectionnez Serveurs.
Sélectionnez l’onglet Contrôle. Sélectionnez msp1, msp2 et msp3. Sélectionnez Arrêter avec l’option Lorsque le travail est terminé>Oui. Sélectionnez l’icône d’actualisation. Attendez que la valeur Statut de la dernière action soit TÂCHE TERMINÉE. Vous devriez voir que la valeur État pour les serveurs sélectionnés est ARRÊTÉ. Sélectionnez à nouveau l’icône d’actualisation pour arrêter la surveillance de l’état.
Sélectionnez à nouveau msp1, msp2 et msp3. Sélectionnez Démarrer>Oui. Sélectionnez l’icône d’actualisation. Attendez que la valeur Statut de la dernière action soit TÂCHE TERMINÉE. Vous devriez voir que la valeur É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êtez les machines virtuelles dans le cluster secondaire

Maintenant, procédez comme suit pour arrêter toutes les machines virtuelles du cluster secondaire afin de le rendre passif :

Ouvrez la page d’accueil du portail Azure dans un nouvel onglet de votre navigateur, puis sélectionnez Toutes les ressources. Dans la zone Filtrer par n’importe quel champ..., saisissez le nom du groupe de ressources où le cluster secondaire est déployé, par exemple wls-cluster-westus-ejb120623.
Sélectionnez Le type égale tout pour ouvrir le filtre Type. Pour Valeur, saisissez Machine virtuelle. Vous devriez voir une entrée correspondante. Sélectionnez-le pour Valeur. Sélectionnez Appliquer. Vous devriez voir 4 machines virtuelles répertoriées, y compris adminVM, mspVM1, mspVM2 et mspVM3.
Sélectionnez chaque machine virtuelle pour l’ouvrir. Sélectionnez Arrêter et confirmez pour chaque machine virtuelle.
Sélectionnez l’icône de notifications du portail Azure pour ouvrir le volet Notifications.
Surveillez l’événement Arrêt de la machine virtuelle pour chaque machine virtuelle jusqu’à ce que la valeur devienne Arrêt réussi de la machine virtuelle. Gardez la page ouverte afin de pouvoir l’utiliser pour le test de basculement plus tard.

Maintenant, passez à l’onglet de votre navigateur où 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égradé et que le point de terminaison myPrimaryEndpoint est En ligne.

Remarque

Une solution PRA/HA prête pour la production souhaiterait probablement atteindre un RTO plus bas en laissant les machines virtuelles allumées mais en arrêtant uniquement le logiciel WLS fonctionnant sur les machines virtuelles. Ensuite, en cas de basculement, les machines virtuelles seraient déjà en cours d’exécution et le logiciel WLS prendrait moins de temps à démarrer. Cet article a choisi d’arrêter les machines virtuelles parce que le logiciel déployé par Oracle WebLogic Server Cluster sur des machines virtuelles Azure démarre automatiquement le logiciel WLS lorsque les machines virtuelles démarrent.

Vérifier l’application

Comme le cluster principal est en ligne, il agit en tant que cluster actif et gère toutes les demandes des utilisateurs 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 du contexte /weblogic-cafe de l’application déployée, par exemple http://tmprofile-ejb120623.trafficmanager.net/weblogic-cafe. Créez un nouveau café avec un nom et un prix, par exemple Café 1 avec comme prix 10. Cette entrée est conservée à la fois dans la table des données de l’application et dans la table de session de la base de données. L’interface utilisateur que vous voyez devrait ressembler à la capture d’écran suivante :

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

Gardez la page ouverte afin de pouvoir l’utiliser pour tester le basculement plus tard.

Testez le basculement du principal au secondaire

Pour tester le basculement, vous basculez manuellement votre serveur de base de données principal et le cluster vers le serveur de base de données secondaire et le cluster, puis revenez en arrière en utilisant le portail Azure dans cette section.

Basculer vers le site secondaire

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

Trouvez le nom de votre groupe de ressources où le cluster WLS principal est déployé - par exemple, wls-cluster-eastus-ejb120623. Ensuite, suivez les étapes de la section Arrêter les machines virtuelles dans le cluster secondaire, mais changez le groupe de ressources cible pour votre cluster WLS principal, afin d’arrêter toutes les machines virtuelles de ce cluster.
Passez à l’onglet de votre navigateur du Traffic Manager, actualisez la page jusqu’à ce que vous voyiez que la valeur État du moniteur du point de terminaison myPrimaryEndpoint devienne Dégradé.
Passez à l’onglet du navigateur de l’application d’exemple et actualisez la page. Vous devriez voir 504 Gateway Time-out ou 502 Bad Gateway car aucun des points de terminaison n’est accessible.

Ensuite, procédez comme suit pour basculer la base de données SQL Azure du serveur principal vers le serveur secondaire :

Passez à l’onglet du navigateur de votre groupe de basculement Azure SQL Database.
Sélectionnez Basculement>Oui.
Attendez que cela soit terminé.

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

Passez à l’onglet de votre navigateur où vous avez arrêté toutes les machines virtuelles du cluster secondaire.
Sélectionnez la machine virtuelle adminVM. Sélectionnez Démarrer.
Surveillez l’événement Démarrage de la machine virtuelle pour adminVM dans le volet Notifications, et attendez que la valeur devienne Machine virtuelle démarrée.
Passez à l’onglet de votre navigateur de la console d’administration WebLogic Server pour le cluster secondaire, puis actualisez la page jusqu’à ce que vous voyiez la page d’accueil pour la connexion.
Revenez à l’onglet de votre navigateur où toutes les machines virtuelles du cluster secondaire sont répertoriées. Pour les machines virtuelles mspVM1, mspVM2 et mspVM3, sélectionnez chacune pour l’ouvrir, puis sélectionnez Démarrer.
Pour les machines virtuelles mspVM1, mspVM2 et mspVM3, surveillez l’événement Démarrage de la machine virtuelle dans le volet Notifications, et attendez que les valeurs deviennent Machine virtuelle démarrée.

Enfin, utilisez les étapes suivantes pour vérifier l’application d’exemple après que le point de terminaison myFailoverEndpoint soit dans l’état En ligne :

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

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

Remarque

Une solution HA/DR prête pour la production tiendrait compte de la copie continue de la configuration WLS du cluster principal vers les clusters secondaires selon un calendrier régulier. Pour savoir comment faire cela, 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 de Traffic Manager et Azure Automation. Pour plus d’informations, consultez la section Alertes sur les métriques de Traffic Manager de Métriques et alertes Traffic Manager et Utiliser une alerte pour déclencher un runbook Azure Automation.

Retour au site principal

Utilisez les mêmes étapes dans la section Basculement vers le site secondaire pour revenir au site principal, y compris le serveur de base de données et le cluster, sauf pour les différences suivantes :

Tout d’abord, éteignez les machines virtuelles dans le cluster secondaire. Vous devriez voir que le point de terminaison myFailoverEndpoint devient Dégradé.
Ensuite, basculez la base de données SQL Azure du serveur secondaire vers le serveur principal.
Ensuite, démarrez tous les serveurs du cluster principal.
Enfin, vérifiez l’application d’exemple après que le point de terminaison myPrimaryEndpoint soit En ligne.

Nettoyer les ressources

Si vous n’avez pas l’intention de continuer à utiliser les clusters WLS et d’autres composants, utilisez les étapes suivantes pour supprimer les groupes de ressources afin de nettoyer les ressources utilisées dans ce tutoriel :

Entrez le nom du groupe de ressources des serveurs Azure SQL Database (par exemple, myResourceGroup) dans la zone de recherche en haut du portail Azure, et sélectionnez le groupe de ressources correspondant dans les résultats de la recherche.
Sélectionnez Supprimer le groupe de ressources.
Dans Entrez 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 avez configuré une solution HA/DR composée d’une couche d’infrastructure applicative active-passive avec une couche de base de données active-passive, et dans laquelle les deux couches s’étendent sur deux sites géographiquement distincts. Sur le premier site, la couche d’infrastructure applicative et la couche de base de données sont toutes deux actives. Sur le deuxième site, le domaine secondaire est arrêté, et la base de données secondaire est en attente.

Continuez à explorer les références suivantes pour plus d’options pour créer des solutions HA/DR 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 une 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