Tutorial: Migración de Oracle WebLogic Server a Azure Virtual Machines con alta disponibilidad y recuperación ante desastres

Artículo
01/11/2024

En este tutorial se muestra una manera sencilla y eficaz de implementar alta disponibilidad y recuperación ante desastres (HA/DR) para Java mediante Oracle WebLogic Server (WLS) en Azure Virtual Machines (VM). La solución muestra cómo lograr un objetivo de tiempo de recuperación (RTO) bajo y un objetivo de punto de recuperación (RPO) mediante una sencilla aplicación de Jakarta EE controlada por base de datos que se ejecuta en WLS. La alta disponibilidad y recuperación ante desastres es un tema complejo, con muchas soluciones posibles. La mejor solución depende de sus requisitos únicos. Para ver otras formas de implementar alta disponibilidad y recuperación ante desastres, consulte los recursos al final de este artículo.

En este tutorial, aprenderá a:

Use los procedimientos recomendados optimizados para Azure para lograr alta disponibilidad y recuperación ante desastres.
Configure un grupo de conmutación por error de Microsoft Azure SQL Database en regiones emparejadas.
Configure clústeres WLS emparejados en máquinas virtuales de Azure.
Configure una instancia de Azure Traffic Manager.
Configure clústeres de WLS para alta disponibilidad y recuperación ante desastres.
Pruebe la conmutación por error de principal a secundaria.

En el diagrama siguiente se muestra la arquitectura que se compila:

Azure Traffic Manager comprueba el estado de las regiones y enruta el tráfico en consecuencia al nivel de aplicación. Tanto la región primaria como la secundaria tienen una implementación completa del clúster de WLS. Sin embargo, solo la región primaria está atendiendo activamente las solicitudes de red de los usuarios. La región secundaria es pasiva y se activa para recibir tráfico solo cuando la región primaria experimenta una interrupción del servicio. Azure Traffic Manager usa la característica de comprobación de estado de la puerta de enlace de App de Azure lication para implementar este enrutamiento condicional. El clúster principal de WLS se está ejecutando y se cierra el clúster secundario. El RTO de conmutación por error geográfica del nivel de aplicación depende del tiempo de inicio de las máquinas virtuales y de la ejecución del clúster WLS secundario. El RPO depende de Azure SQL Database porque los datos se conservan y replican en el grupo de conmutación por error de Azure SQL Database.

El nivel de base de datos consta de un grupo de conmutación por error de Azure SQL Database con un servidor principal y un servidor secundario. El servidor principal está en modo de lectura y escritura activo y está conectado al clúster de WLS principal. El servidor secundario está en modo de solo preparación pasiva y está conectado al clúster de WLS secundario. Una conmutación por error geográfica cambia todas las bases de datos secundarias del grupo al rol principal. Para el RPO de conmutación por error geográfica y el RTO de Azure SQL Database, consulte Introducción a la continuidad empresarial.

Este artículo se escribió con el servicio Azure SQL Database porque el artículo se basa en las características de alta disponibilidad (HA) de ese servicio. Otras opciones de base de datos son posibles, pero debe tener en cuenta las características de alta disponibilidad de la base de datos que elija. Para obtener más información, incluida la información sobre cómo optimizar la configuración de orígenes de datos para la replicación, consulte Configuración de orígenes de datos para la implementación activa-pasiva de middleware de Oracle Fusion.

Requisitos previos

Si no tiene una suscripción a Azure, cree una cuenta gratuita antes de empezar.
Asegúrese de que tiene el Owner rol o los Contributor roles y User Access Administrator en la suscripción. Para comprobar la asignación, siga los pasos descritos en Enumeración de asignaciones de roles de Azure mediante Azure Portal.
Prepare una máquina local con Windows, Linux o macOS instalado.
Instale y configure Git.
Instale una implementación de Java SE, versión 17 o posterior (por ejemplo, la compilación de Microsoft de OpenJDK).
Instale Maven, versión 3.9.3 o posterior.

Configuración de un grupo de conmutación por error de Azure SQL Database en regiones emparejadas

En esta sección, creará un grupo de conmutación por error de Azure SQL Database en regiones emparejadas para su uso con los clústeres y la aplicación de WLS. En una sección posterior, configurará WLS para almacenar sus datos de sesión y los datos del registro de transacciones (TLOG) en esta base de datos. Esta práctica es coherente con la arquitectura de disponibilidad máxima (MAA) de Oracle. Esta guía proporciona una adaptación de Azure para MAA. Para más información sobre MAA, consulte Arquitectura de máxima disponibilidad de Oracle.

En primer lugar, cree la instancia principal de Azure SQL Database siguiendo los pasos de Azure Portal en Inicio rápido: Creación de una base de datos única: Azure SQL Database. Siga los pasos necesarios, pero no incluidos, en la sección "Limpiar recursos". Use las instrucciones siguientes a medida que recorra el artículo y vuelva a este artículo después de crear y configurar Azure SQL Database:

Cuando llegue a la sección Creación de una base de datos única, siga estos pasos:
1. En el paso 4 para crear un nuevo grupo de recursos, anote el valor nombre del grupo de recursos; por ejemplo, myResourceGroup.
2. En el paso 5 del nombre de la base de datos, anote el valor nombre de la base de datos; por ejemplo, mySampleDatabase.
3. En el paso 6 para crear el servidor, siga estos pasos:
  1. Anote el nombre de servidor único; por ejemplo, sqlserverprimary-ejb120623.
  2. En Ubicación, seleccione (EE. UU.) Este de EE. UU.
  3. En Método de autenticación, seleccione Usar autenticación de SQL.
  4. Anote el valor de inicio de sesión de administrador del servidor, por ejemplo, azureuser.
  5. Anote el valor de Contraseña .
4. En el paso 8, en Entorno de carga de trabajo, seleccione Desarrollo. Examine la descripción y tenga en cuenta otras opciones para la carga de trabajo.
5. En el paso 11, en Redundancia de almacenamiento de copia de seguridad, seleccione Almacenamiento de copia de seguridad con redundancia local. Considere otras opciones para las copias de seguridad. Para más información, consulte la sección Redundancia de almacenamiento de copia de seguridad de copias de seguridad automatizadas en Azure SQL Database.
6. En el paso 14, en la configuración de reglas de firewall, en Permitir que los servicios y recursos de Azure accedan a este servidor, seleccione Sí.
Cuando llegue a la sección Consulta de la base de datos, siga estos pasos:
1. En el paso 3, escriba la información de inicio de sesión del administrador del servidor de autenticación de SQL para iniciar sesión.
  
  Nota:
  
  Si se produce un error de inicio de sesión con un mensaje de error similar al cliente con la dirección IP 'xx.xx.xx.xx' no puede acceder al servidor, seleccione Allowlist IP xx.xx.xx.xx.xx en el servidor <your-sqlserver-name> al final del mensaje de error. Espere hasta que las reglas de firewall del servidor completen la actualización y, a continuación, seleccione Aceptar de nuevo.
2. Después de ejecutar la consulta de ejemplo en el paso 5, borre el editor y cree tablas.

Escriba la siguiente consulta para crear el esquema para 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));

Después de una ejecución correcta, debería ver el mensaje Consulta correcta: Filas afectadas: 0.

Estas tablas de base de datos se usan para almacenar datos de sesión y registro de transacciones (TLOG) para los clústeres y aplicaciones de WLS. Para obtener más información, consulte Uso de un almacén de TLOG de JDBC y Uso de una base de datos para el almacenamiento persistente (persistencia de JDBC).

A continuación, cree un grupo de conmutación por error de Azure SQL Database siguiendo los pasos de Azure Portal en Configuración de un grupo de conmutación por error para Azure SQL Database. Solo necesita las secciones siguientes: Crear grupo de conmutación por error y Probar conmutación por error planeada. Siga estos pasos a medida que recorra el artículo y vuelva a este artículo después de crear y configurar el grupo de conmutación por error de Azure SQL Database:

Cuando llegue a la sección Crear grupo de conmutación por error, siga estos pasos:
1. En el paso 5 para crear el grupo de conmutación por error, seleccione la opción para crear un nuevo servidor secundario y, a continuación, siga estos pasos:
  1. Escriba y anote el nombre del grupo de conmutación por error; por ejemplo, failovergroupname-ejb120623.
  2. Escriba y anote el nombre de servidor único; por ejemplo, sqlserversecondary-ejb120623.
  3. Escriba el mismo administrador del servidor y la misma contraseña que el servidor principal.
  4. En Ubicación, seleccione una región diferente a la que usó para la base de datos principal.
  5. Asegúrese de que la opción Permitir que los servicios de Azure accedan al servidor esté seleccionada.
2. En el paso 5 para configurar las bases de datos del grupo, seleccione la base de datos que creó en el servidor principal; por ejemplo, mySampleDatabase.
Después de completar todos los pasos de la sección Prueba conmutación por error planeada, mantenga abierta la página del grupo de conmutación por error y úsela para la prueba de conmutación por error de los clústeres de WLS más adelante.

Configuración de clústeres WLS emparejados en máquinas virtuales de Azure

En esta sección, creará dos clústeres de WLS en máquinas virtuales de Azure mediante el clúster de Oracle WebLogic Server en máquinas virtuales de Azure. El clúster del Este de EE. UU. es principal y se configura como el clúster activo más adelante. El clúster en Oeste de EE. UU. es secundario y se configura como el clúster pasivo más adelante.

Configuración del clúster de WLS principal

En primer lugar, abra el clúster de Oracle WebLogic Server en máquinas virtuales de Azure en el explorador y seleccione Crear. Debería ver el panel Aspectos básicos de la oferta.

Siga estos pasos para rellenar el panel Aspectos básicos :

Asegúrese de que el valor que se muestra para Suscripción es el mismo que tiene los roles enumerados en la sección de requisitos previos.
Debe implementar la oferta en un grupo de recursos vacío. En el campo Grupo de recursos, seleccione Crear nuevo y rellene un valor único para el grupo de recursos; por ejemplo, wls-cluster-eastus-ejb120623.
En Detalles de la instancia, en Región, seleccione Este de EE. UU.
En Credenciales para máquinas virtuales y WebLogic, proporcione una contraseña para la cuenta de administrador de la máquina virtual y webLogic Administración istrator, respectivamente. Anote el nombre de usuario y la contraseña de WebLogic Administración istrator.
Deje los valores predeterminados para otros campos.
Seleccione Siguiente para ir al panel Configuración de TLS/SSL.

Deje los valores predeterminados en el panel Configuración de TLS/SSL, seleccione Siguiente para ir al panel puerta de enlace de App de Azure lication y, a continuación, siga estos pasos.

Para Conectar a App de Azure lication Gateway?, seleccione Sí.
Para seleccionar la opción Seleccionar certificado TLS/SSL deseado, seleccione Generar un certificado autofirmado.
Seleccione Siguiente para ir al panel Redes .

Debería ver todos los campos rellenados previamente con los valores predeterminados en el panel Redes . Siga estos pasos para guardar la configuración de red:

Seleccione Editar red virtual. Anote el espacio de direcciones de la red virtual; por ejemplo, 10.1.4.0/23.
Seleccione wls-subnet esta opción para editar la subred. En Detalles de subred, anote la dirección inicial y el tamaño de la subred; por ejemplo, 10.1.5.0 y /28.
Si realiza alguna modificación, guarde los cambios.
Vuelva al panel Redes .
Seleccione Siguiente para ir al panel Base de datos .

Los pasos siguientes muestran cómo rellenar el panel Base de datos :

Para Conectar a la base de datos, seleccione Sí.
En Elegir tipo de base de datos, seleccione Microsoft SQL Server (compatibilidad con conexión sin contraseña) .
En Nombre JNDI, escriba jdbc/WebLogicCafeDB.
Para DataSource Conectar ion String, reemplace los marcadores de posición por los valores que anotó en la sección anterior de la base de datos SQL principal; por ejemplo, jdbc:sqlserver://sqlserverprimary-ejb120623.database.windows.net:1433; database=mySampleDatabase.
En Protocolo de transacción global, seleccione Ninguno.
En Nombre de usuario de base de datos, reemplace los marcadores de posición por los valores que anotó en la sección anterior para la base de datos SQL principal; por ejemplo, azureuser@sqlserverprimary-ejb120623.
Escriba la contraseña de inicio de sesión del administrador del servidor que escribió antes de contraseña de base de datos. Escriba el mismo valor para Confirmar contraseña.
Deje los valores predeterminados para los demás campos.
Seleccione Revisar + crear.
Espere hasta que se complete correctamente la validación final en ejecución... y, a continuación, seleccione Crear.

Después de un tiempo, debería ver la página Implementación donde se muestra la implementación en curso .

Nota:

Si ve algún problema durante la ejecución de la validación final..., corrijalos e inténtelo de nuevo.

En función de las condiciones de red y de otra actividad de la región seleccionada, la implementación puede tardar hasta 50 minutos en completarse. Después de eso, debería ver el texto Su implementación se ha completado en la página de implementación.

Mientras tanto, puede configurar el clúster WLS secundario en paralelo.

Configuración del clúster de WLS secundario

Siga los mismos pasos descritos en la sección Configuración del clúster WLS principal para configurar el clúster WLS secundario en la región Oeste de EE. UU., excepto las siguientes diferencias:

En el panel Aspectos básicos , siga estos pasos:
1. En el campo Grupo de recursos, seleccione Crear nuevo y rellene un valor único diferente para el grupo de recursos; por ejemplo, wls-cluster-westtus-ejb120623.
2. En Detalles de la instancia, en Región, seleccione Oeste de EE. UU.
En el panel Redes , siga estos pasos:
1. En Editar red virtual, escriba el mismo espacio de direcciones de la red virtual que el clúster WLS principal; por ejemplo, 10.1.4.0/23.
  
  Nota:
  
  Debería ver un mensaje de advertencia similar al siguiente: Superposiciones del espacio de direcciones '10.1.4.0/23 (10.1.4.0 - 10.1.5.255)' con el espacio de direcciones '10.1.4.0/23 (10.1.4.0 - 10.1.5.255)' de la red virtual 'wls-vnet'. Las redes virtuales con espacio de direcciones superpuesto no se pueden emparejar. Si piensa emparejar estas redes virtuales, cambie el espacio de direcciones "10.1.4.0/23 (10.1.4.0 - 10.1.5.255)". Puede omitir este mensaje porque necesita dos clústeres de WLS con la misma configuración de red.
2. En wls-subnet, escriba el mismo tamaño de dirección inicial y subred que el clúster principal de WLS; por ejemplo, 10.1.5.0 y /28.
En el panel Base de datos , siga estos pasos:
1. Para DataSource Conectar ion String, reemplace los marcadores de posición por los valores que escribió en la sección anterior para la base de datos SQL secundaria; por ejemplo, jdbc:sqlserver://sqlserversecondary-ejb120623.database.windows.net:1433; database=mySampleDatabase.
2. En Nombre de usuario de base de datos, reemplace los marcadores de posición por los valores que anotó en la sección anterior para la base de datos SQL secundaria; por ejemplo, azureuser@sqlserversecondary-ejb120623.

Creación de reflejo de la configuración de red para los dos clústeres

Durante la fase de reanudación de transacciones pendientes en el clúster WLS secundario después de una conmutación por error, WLS comprueba la propiedad del almacén de TLOG. Para pasar correctamente la comprobación, todos los servidores administrados del clúster secundario deben tener la misma dirección IP privada que el clúster principal.

En esta sección se muestra cómo reflejar la configuración de red del clúster principal en el clúster secundario.

En primer lugar, siga estos pasos para configurar las opciones de red para el clúster principal una vez completada la implementación:

En el panel Información general de la página Implementación , seleccione Ir al grupo de recursos.
Seleccione la interfaz adminVM_NIC_with_pub_ipde red .
1. En Configuración, seleccione Configuraciones IP.
2. Seleccione ipconfig1.
3. En Configuración de la dirección IP privada, seleccione Estática para asignación. Anote la dirección IP privada.
4. Seleccione Guardar.
Vuelva al grupo de recursos del clúster WLS principal y repita el paso 3 para las interfaces mspVM1_NIC_with_pub_ipde red , mspVM2_NIC_with_pub_ipy mspVM3_NIC_with_pub_ip.
Espere hasta que se completen todas las actualizaciones. Puede seleccionar el icono de notificaciones en Azure Portal para abrir el panel Notificaciones para la supervisión del estado.
Vuelva al grupo de recursos del clúster principal de WLS y copie el nombre del recurso con el tipo Punto de conexión privado( por ejemplo, 7e8c8bsaep). Use ese nombre para buscar la interfaz de red restante; por ejemplo, 7e8c8bsaep.nic.c0438c1a-1936-4b62-864c-6792eec3741a. Selecciónelo y siga los pasos anteriores para anotar su dirección IP privada.

A continuación, siga estos pasos para configurar las opciones de red del clúster secundario una vez completada la implementación:

En el panel Información general de la página Implementación , seleccione Ir al grupo de recursos.
Para las interfaces adminVM_NIC_with_pub_ipde red , mspVM1_NIC_with_pub_ip, mspVM2_NIC_with_pub_ipy mspVM3_NIC_with_pub_ip, siga los pasos anteriores para actualizar la asignación de direcciones IP privadas a Static.
Espere hasta que se completen todas las actualizaciones.
Para las interfaces mspVM1_NIC_with_pub_ipde red , mspVM2_NIC_with_pub_ipy mspVM3_NIC_with_pub_ip, siga los pasos anteriores, pero actualice la dirección IP privada al mismo valor usado con el clúster principal. Espere hasta que se complete la actualización actual de la interfaz de red antes de continuar con la siguiente.

Nota:

No se puede cambiar la dirección IP privada de la interfaz de red que forma parte de un punto de conexión privado. Para reflejar fácilmente las direcciones IP privadas de las interfaces de red para los servidores administrados, considere la posibilidad de actualizar la dirección IP privada para adminVM_NIC_with_pub_ip a una dirección IP que no se usa. En función de la asignación de direcciones IP privadas en los dos clústeres, es posible que tenga que actualizar también la dirección IP privada en el clúster principal.

En la tabla siguiente se muestra un ejemplo de creación de reflejo de la configuración de red para dos clústeres:

Clúster	Interfaz de red	Dirección IP privada (antes)	Dirección IP privada (después)	Secuencia de actualización
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`
Secundario	`1696b0saep.nic.2e19bf46-9799-4acc-b64b-a2cd2f7a4ee1`	`10.1.5.8`	`10.1.5.8`
Secundario	`adminVM_NIC_with_pub_ip`	`10.1.5.5`	`10.1.5.4`	4
Secundario	`mspVM1_NIC_with_pub_ip`	`10.1.5.7`	`10.1.5.5`	5
Secundario	`mspVM2_NIC_with_pub_ip`	`10.1.5.6`	`10.1.5.9`	2
Secundario	`mspVM3_NIC_with_pub_ip`	`10.1.5.4`	`10.1.5.6`	3

Compruebe el conjunto de direcciones IP privadas de todos los servidores administrados, que consta del grupo de back-end de la puerta de enlace de App de Azure lication que implementó en cada clúster. Si se actualiza, siga estos pasos para actualizar el grupo de back-end de puerta de enlace de App de Azure lication en consecuencia:

Abra el grupo de recursos del clúster.
Busque el recurso myAppGateway con el tipo Application Gateway. Selecciónela para abrirla.
En la sección Configuración, seleccione Grupos de back-end y, a continuación, seleccione myGatewayBackendPool.
Cambie los valores de destinos de back-end con la dirección IP privada actualizada o las direcciones y, a continuación, seleccione Guardar. Espere hasta que finalice.
En la sección Configuración, seleccione Sondeos de estado y, a continuación, seleccione HTTPhealthProbe.
Asegúrese de que deseo probar el estado de back-end antes de agregar el sondeo de estado seleccionado y, a continuación, seleccione Probar. Debería ver que el valor De estado del grupo myGatewayBackendPool de back-end está marcado como correcto. Si no es así, compruebe si las direcciones IP privadas se actualizan según lo previsto y las máquinas virtuales se están ejecutando, vuelva a probar el sondeo de estado. Debe solucionar y resolver el problema antes de continuar.

En el ejemplo siguiente, se actualiza el grupo de back-end de puerta de enlace de App de Azure lication para cada clúster:

Clúster	grupo de back-end de puerta de enlace de App de Azure lication	Destinos de back-end (antes)	Destinos de back-end (despué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`)
Secundario	`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`)

Para automatizar la creación de reflejo de la configuración de red, considere la posibilidad de usar la CLI de Azure. Para más información, consulte Introducción a la CLI de Azure.

Comprobación de las implementaciones de los clústeres

Ha implementado una puerta de enlace de App de Azure lication y un servidor de administración de WLS en cada clúster. La puerta de enlace de App de Azure lication actúa como equilibrador de carga para todos los servidores administrados del clúster. El servidor de administración de WLS proporciona una consola web para la configuración del clúster.

Siga estos pasos para comprobar si la puerta de enlace de App de Azure lication y la consola de administración de WLS de cada clúster funcionan antes de pasar al paso siguiente:

Vuelva a la página Implementación y seleccione Salidas.
Copie el valor de la propiedad appGatewayURL. Anexe la cadena weblogic/ready y, a continuación, abra esa dirección URL en una nueva pestaña del explorador. Debería ver una página vacía sin ningún mensaje de error. Si no lo hace, debe solucionar y resolver el problema antes de continuar.
Copie y anote el valor de la propiedad adminConsole. Ábralo en una nueva pestaña del explorador. Debería ver la página de inicio de sesión de webLogic Server Administración istration Console. Inicie sesión en la consola con el nombre de usuario y la contraseña del administrador de WebLogic que anotó antes. Si no puede iniciar sesión, debe solucionar el problema antes de continuar.

Siga estos pasos para anotar la dirección IP de la puerta de enlace de App de Azure lication para cada clúster. Estos valores se usan al configurar Azure Traffic Manager más adelante.

Abra el grupo de recursos donde se implementa el clúster; por ejemplo, seleccione Información general para volver al panel Información general de la página de implementación. A continuación, seleccione Ir al grupo de recursos.
Busque el recurso gwip con el tipo Dirección IP pública y selecciónelo para abrirlo. Busque el campo dirección IP y anote su valor.

Configuración de Azure Traffic Manager

En esta sección, creará un Administrador de tráfico de Azure para distribuir el tráfico a las aplicaciones orientadas al público en las regiones globales de Azure. El punto de conexión principal apunta a la puerta de enlace de App de Azure lication en el clúster de WLS principal y el punto de conexión secundario apunta a la puerta de enlace de App de Azure lication en el clúster de WLS secundario.

Cree un perfil de Azure Traffic Manager siguiendo el inicio rápido: Creación de un perfil de Traffic Manager mediante Azure Portal. Omita la sección Requisitos previos . Solo necesita las secciones siguientes: Crear un perfil de Traffic Manager, Agregar puntos de conexión de Traffic Manager y Probar perfil de Traffic Manager. Siga estos pasos a medida que recorra estas secciones y vuelva a este artículo después de crear y configurar Azure Traffic Manager.

Cuando llegue a la sección Creación de un perfil de Traffic Manager, siga estos pasos:
1. En el paso 2 Crear perfil de Traffic Manager, siga estos pasos:
  1. Anote el nombre de perfil de Traffic Manager único para Name (por ejemplo, tmprofile-ejb120623).
  2. Anote el nuevo nombre del grupo de recursos para Grupo de recursos; por ejemplo, myResourceGroupTM1.
Cuando llegue a la sección Agregar puntos de conexión de Traffic Manager, siga estos pasos:
1. Realice esta acción adicional después del paso Seleccione el perfil en los resultados de la búsqueda.
  1. En Configuración, seleccione Configuración.
  2. Para el período de vida de DNS (TTL), escriba 10.
  3. En Configuración del monitor de punto de conexión, en Ruta de acceso, escriba /weblogic/ready.
  4. En Configuración de conmutación por error de punto de conexión rápido, use los siguientes valores:
    - En Sondeo interno, escriba 10.
    - En Número tolerado de errores, escriba 3.
    - En Tiempo de espera de sondeo, 5.
  5. Seleccione Guardar. Espere hasta que finalice.
2. En el paso 4 para agregar el punto de conexión myPrimaryEndpointprincipal, siga estos pasos:
  1. En Tipo de recurso de destino, seleccione Dirección IP pública.
  2. Seleccione la lista desplegable Elegir dirección IP pública y escriba la dirección IP de Application Gateway implementada en el clúster este de EE. UU . WLS que anotó antes. Debería ver una entrada coincidente. Selecciónelo para Dirección IP pública.
3. En el paso 6 para agregar una conmutación por error o un punto de conexión secundario myFailoverEndpoint, siga estos pasos:
  1. En Tipo de recurso de destino, seleccione Dirección IP pública.
  2. Seleccione la lista desplegable Elegir dirección IP pública y escriba la dirección IP de Application Gateway implementada en el clúster oeste de EE. UU . WLS que anotó antes. Debería ver una entrada coincidente. Selecciónelo para Dirección IP pública.
4. Espere un rato. Seleccione Actualizar hasta que el valor de estado Supervisión de ambos puntos de conexión sea En línea.
Cuando llegue a la sección Test Traffic Manager profile (Probar perfil de Traffic Manager), siga estos pasos:
1. En la subsección Compruebe el nombre DNS, use el paso siguiente:
  1. En el paso 3, anote el nombre DNS del perfil de Traffic Manager; por ejemplo, http://tmprofile-ejb120623.trafficmanager.net.
2. En la subsección Ver Traffic Manager en acción, siga estos pasos:
  1. En el paso 1 y 3, anexe /weblogic/ready al nombre DNS del perfil de Traffic Manager en el explorador web, por ejemplo, http://tmprofile-ejb120623.trafficmanager.net/weblogic/ready. Debería ver una página vacía sin ningún mensaje de error.
  2. Después de completar todos los pasos, asegúrese de habilitar el punto de conexión principal haciendo referencia al paso 2, pero reemplace Deshabilitado por Habilitado. A continuación, vuelva a la página Puntos de conexión .

Ahora tiene los puntos de conexión habilitados y en línea en el perfil de Traffic Manager. Mantenga abierta la página y úsela para supervisar el estado del punto de conexión más adelante.

Configuración de los clústeres de WLS para alta disponibilidad y recuperación ante desastres

En esta sección, configurará clústeres de WLS para alta disponibilidad y recuperación ante desastres.

Preparación de la aplicación de ejemplo

En esta sección, compilará y empaquetará una aplicación CRUD java/JakartaEE de ejemplo que más adelante implementará y ejecutará en clústeres de WLS para realizar pruebas de conmutación por error.

La aplicación usa la persistencia de sesión JDBC de WebLogic Server para almacenar datos de sesión HTTP. El origen de jdbc/WebLogicCafeDB datos almacena los datos de sesión para habilitar la conmutación por error y el equilibrio de carga en un clúster de servidores WebLogic. Configura un esquema de persistencia para conservar los datos coffee de la aplicación en el mismo origen de jdbc/WebLogicCafeDBdatos .

Siga estos pasos para compilar y empaquetar el ejemplo:

Use los siguientes comandos para clonar el repositorio de ejemplo y desactive la etiqueta correspondiente a este artículo:
```
git clone https://github.com/Azure-Samples/azure-cafe.git
cd azure-cafe
git checkout 20231206
```
Si ve un mensaje sobre Detached HEAD, es seguro omitirlo.
Use los siguientes comandos para navegar al directorio de ejemplo y, a continuación, compile y empaquete el ejemplo:
```
cd weblogic-cafe
mvn clean package
```

Cuando el paquete se genera correctamente, puede encontrarlo en parent-path-to-your-local-clone>/azure-café/weblogic-café/target/weblogic-café.war.< Si no ve el paquete, debe solucionar el problema antes de continuar.

Implementación de la aplicación de ejemplo

Ahora siga estos pasos para implementar la aplicación de ejemplo en los clústeres, empezando por el clúster principal:

Abra adminConsole del clúster en una nueva pestaña del explorador web. Inicie sesión en webLogic Server Administración istration Console con el nombre de usuario y la contraseña de WebLogic Administración istrator que anotó antes.
Busque Implementaciones de estructura>de dominio wlsd>en el panel de navegación. Seleccione Implementaciones.
Seleccione Bloquear y editar>instalar>Cargar los archivos.Elija> Archivo. Seleccione el archivo weblogic-café.war que preparó anteriormente.
Seleccione Siguiente>Siguiente>Siguiente. Seleccione cluster1 con la opción Todos los servidores del clúster para los destinos de implementación. Seleccione Siguiente>Finalizar. Seleccione Activar cambios.
Cambie a la pestaña Control y seleccione weblogic-cafe en la tabla de implementaciones. Seleccione Iniciar con la opción Mantenimiento de todas las solicitudes>Sí. Espere un tiempo y actualice la página hasta que vea que el estado de la implementación weblogic-cafe es Activo. Cambie a la pestaña Supervisión y compruebe que la raíz del contexto de la aplicación implementada es /weblogic-café. Mantenga abierta la consola de administración de WLS para que pueda usarla más adelante para su posterior configuración.

Repita los mismos pasos en WebLogic Server Administración istration Console, pero para el clúster secundario en la región Oeste de EE. UU.

Actualización del host de front-end

Siga estos pasos para que los clústeres de WLS sean conscientes de Azure Traffic Manager. Dado que Azure Traffic Manager es el punto de entrada para las solicitudes de usuario, actualice el host front del clúster de WebLogic Server al nombre DNS del perfil de Traffic Manager, empezando por el clúster principal.

Asegúrese de que ha iniciado sesión en WebLogic Server Administración istration Console.
Vaya a Estructura de dominio>clústeres de entorno>wlsd>en el panel de navegación. Seleccione Clústeres.
Seleccione cluster1 en la tabla de clústeres.
Seleccione Bloquear y editar>HTTP. Quite el valor actual del host de front-end y escriba el nombre DNS del perfil de Traffic Manager que anotó antes, sin el inicial http:// , por ejemplo, tmprofile-ejb120623.trafficmanager.net. Seleccione Guardar>activar cambios.

Repita los mismos pasos en la consola de Administración istration de WebLogic Server, pero para el clúster secundario en la región Oeste de EE. UU.

Configuración del almacén de registros de transacciones

A continuación, configure el almacén de registros de transacciones de JDBC para todos los servidores administrados de clústeres, empezando por el clúster principal. Esta práctica se describe en Uso de archivos de registro de transacciones para recuperar transacciones.

Siga estos pasos en el clúster principal de WLS en la región Este de EE. UU.

Asegúrese de que ha iniciado sesión en la consola de Administración istration de WebLogic Server.
Vaya a La estructura>de dominio wlsd Environment Servers (Servidores de entorno de wlsd>)>en el panel de navegación. Seleccione Servidores.
Debería ver los servidores msp1, msp2y msp3 que aparecen en la tabla servers.
Seleccione msp1>Services Lock &Edit (Bloquear y editar servicios).> En Almacén de registros de transacciones, seleccione JDBC.
En Type Data Source (Tipo>de origen de datos), seleccione .jdbc/WebLogicCafeDB
Confirme que el valor de Prefix Name es TLOG_msp1_, que es el valor predeterminado. Si el valor es diferente, cámbielo a TLOG_msp1_.
Seleccione Guardar.
Seleccione Servidores>msp2 y repita los mismos pasos, excepto que el valor predeterminado de Nombre de prefijo es TLOG_msp2_.
Seleccione Servidores>msp3 y repita los mismos pasos, excepto que el valor predeterminado de Nombre de prefijo es TLOG_msp3_.
Seleccione Activar cambios.

Repita los mismos pasos en WebLogic Server Administración istration Console, pero para el clúster secundario en la región Oeste de EE. UU.

Reinicio de los servidores administrados del clúster principal

A continuación, siga estos pasos para reiniciar todos los servidores administrados del clúster principal para que los cambios surtan efecto:

Asegúrese de que ha iniciado sesión en WebLogic Server Administración istration Console.
Vaya a La estructura>de dominio wlsd Environment Servers (Servidores de entorno de wlsd>)>en el panel de navegación. Seleccione Servidores.
Seleccione la pestaña Control . Seleccione msp1, msp2y msp3. Seleccione Apagar con la opción Cuando finalice el>trabajo Sí. Seleccione el icono de actualización. Espere hasta que el valor Estado de la última acción sea TASK COMPLETED. Debería ver que el valor de Estado de los servidores seleccionados es SHUTDOWN. Vuelva a seleccionar el icono de actualización para detener la supervisión del estado.
Seleccione msp1, msp2y msp3 de nuevo. Seleccione Iniciar>sí. Seleccione el icono de actualización. Espere hasta que el valor Estado de la última acción sea TASK COMPLETED. Debería ver que el valor de Estado de los servidores seleccionados es RUNNING. Vuelva a seleccionar el icono de actualización para detener la supervisión del estado.

Detención de las máquinas virtuales en el clúster secundario

Ahora, siga estos pasos para detener todas las máquinas virtuales del clúster secundario para que sea pasiva:

Abra la página principal de Azure Portal en una nueva pestaña del explorador y, a continuación, seleccione Todos los recursos. En el cuadro Filtrar para cualquier campo... , escriba el nombre del grupo de recursos donde se implementa el clúster secundario; por ejemplo, wls-cluster-westus-ejb120623.
Seleccione Tipo igual a todo para abrir el filtro Tipo . En Valor, escriba Máquina virtual. Debería ver una entrada coincidente. Selecciónelo para Valor. Seleccione Aplicar. Debería ver 4 máquinas virtuales en la lista, incluidas adminVM, mspVM1, mspVM2y mspVM3.
Seleccione esta opción para abrir cada una de las máquinas virtuales. Seleccione Detener y confirme para cada máquina virtual.
Seleccione el icono de notificaciones en Azure Portal para abrir el panel Notificaciones .
Supervise el evento Detener máquina virtual para cada máquina virtual hasta que el valor se detenga correctamente. Mantenga abierta la página para poder usarla para la prueba de conmutación por error más adelante.

Ahora, cambie a la pestaña del explorador donde se supervisa el estado de los puntos de conexión del Administrador de tráfico. Actualice la página hasta que vea que el punto de conexión myFailoverEndpoint está degradado y el punto de conexión myPrimaryEndpoint está en línea.

Nota:

Es probable que una solución de alta disponibilidad y recuperación ante desastres preparada para producción quiera lograr un RTO menor, dejando las máquinas virtuales en ejecución, pero solo deteniendo el software WLS que se ejecuta en las máquinas virtuales. A continuación, en caso de conmutación por error, las máquinas virtuales ya se estarían ejecutando y el software WLS tardaría menos tiempo en iniciarse. En este artículo se decidió detener las máquinas virtuales porque el software implementado por el clúster de Oracle WebLogic Server en máquinas virtuales de Azure inicia automáticamente el software WLS cuando se inician las máquinas virtuales.

Comprobación de la aplicación

Dado que el clúster principal está en funcionamiento, actúa como el clúster activo y controla todas las solicitudes de usuario enrutadas por el perfil de Traffic Manager.

Abra el nombre DNS del perfil de Azure Traffic Manager en una nueva pestaña del explorador, anexando la raíz de contexto /weblogic-café de la aplicación implementada, por ejemplo, http://tmprofile-ejb120623.trafficmanager.net/weblogic-cafe. Cree un café con nombre y precio, por ejemplo, Café 1 con el precio 10. Esta entrada se conserva en la tabla de datos de la aplicación y en la tabla de sesión de la base de datos. La interfaz de usuario que ve debe ser similar a la siguiente captura de pantalla:

Si la interfaz de usuario no tiene un aspecto similar, solucione y resuelva el problema antes de continuar.

Mantenga abierta la página para poder usarla para las pruebas de conmutación por error más adelante.

Conmutación por error de prueba de principal a secundaria

Para probar la conmutación por error, debe conmutar manualmente el servidor de base de datos principal y el clúster al servidor de base de datos secundario y al clúster y, a continuación, conmutar por recuperación mediante Azure Portal en esta sección.

Conmutación por error al sitio secundario

En primer lugar, siga estos pasos para apagar las máquinas virtuales del clúster principal:

Busque el nombre del grupo de recursos donde se implementa el clúster WLS principal; por ejemplo, wls-cluster-eastus-ejb120623. A continuación, siga los pasos descritos en la sección Detener máquinas virtuales del clúster secundario, pero cambie el grupo de recursos de destino al clúster de WLS principal para detener todas las máquinas virtuales de ese clúster.
Cambie a la pestaña del explorador de Traffic Manager, actualice la página hasta que vea que el valor de estado monitor del punto de conexión myPrimaryEndpoint se vuelve Degradado.
Cambie a la pestaña del explorador de la aplicación de ejemplo y actualice la página. Debería ver un tiempo de espera de puerta de enlace 504 o 502 Puerta de enlace incorrecta porque no se puede acceder a ninguno de los puntos de conexión.

A continuación, siga estos pasos para conmutar por error la instancia de Azure SQL Database desde el servidor principal al servidor secundario:

Cambie a la pestaña del explorador del grupo de conmutación por error de Azure SQL Database.
Seleccione Conmutación por error>Sí.
Espere hasta que finalice.

A continuación, siga estos pasos para iniciar todos los servidores del clúster secundario:

Cambie a la pestaña del explorador donde detuvo todas las máquinas virtuales del clúster secundario.
Seleccione la máquina virtual adminVM. Seleccione Iniciar.
Supervise el evento Iniciando máquina virtual en adminVM el panel Notificaciones y espere hasta que el valor se convierta en Máquina virtual iniciada.
Cambie a la pestaña del explorador de webLogic Server Administración istration Console para el clúster secundario y, a continuación, actualice la página hasta que vea la página principal para iniciar sesión.
Vuelva a la pestaña del explorador donde se muestran todas las máquinas virtuales del clúster secundario. Para las máquinas virtuales mspVM1, mspVM2y mspVM3, seleccione cada una para abrirla y, a continuación, seleccione Iniciar.
En el caso de las máquinas virtuales , y , supervise el evento Iniciando máquina virtual en el panel Notificaciones y espere hasta que los valores se conviertan en Máquina virtual iniciada.mspVM3mspVM2mspVM1

Por último, siga estos pasos para comprobar la aplicación de ejemplo después de que el punto de conexión myFailoverEndpoint esté en estado En línea :

Cambie a la pestaña del explorador de Traffic Manager y, a continuación, actualice la página hasta que vea que el valor de estado Supervisar del punto de conexión myFailoverEndpoint entra en estado En línea .
Cambie a la pestaña del explorador de la aplicación de ejemplo y actualice la página. Debería ver los mismos datos almacenados en la tabla de datos de la aplicación y la tabla de sesión mostrada en la interfaz de usuario, como se muestra en la captura de pantalla siguiente:

Si no observa este comportamiento, puede deberse a que Traffic Manager tarda tiempo en actualizar DNS para que apunte al sitio de conmutación por error. El problema también podría ser que el explorador almacenara en caché el resultado de la resolución de nombres DNS que apunta al sitio con errores. Espere un rato y vuelva a actualizar la página.

Nota:

Una solución de alta disponibilidad y recuperación ante desastres preparada para producción tendría en cuenta la copia continua de la configuración de WLS de la base de datos principal a los clústeres secundarios según una programación periódica. Para obtener información sobre cómo hacerlo, consulte las referencias a la documentación de Oracle al final de este artículo.

Para automatizar la conmutación por error, considere la posibilidad de usar alertas sobre las métricas de Traffic Manager y Azure Automation. Para más información, consulte la sección Alertas sobre métricas de Traffic Manager de métricas y alertas de Traffic Manager y Uso de una alerta para desencadenar un runbook de Azure Automation.

Conmutación por recuperación al sitio primario

Siga los mismos pasos de la sección Conmutación por error al sitio secundario para conmutar por recuperación al sitio primario, incluido el servidor de base de datos y el clúster, excepto las siguientes diferencias:

En primer lugar, apague las máquinas virtuales en el clúster secundario. Debería ver que el punto de conexión myFailoverEndpoint se degrada.
A continuación, conmute por error azure SQL Database desde el servidor secundario al servidor principal.
A continuación, inicie todos los servidores del clúster principal.
Por último, compruebe la aplicación de ejemplo después de que el punto de conexión myPrimaryEndpoint esté en línea.

Limpieza de recursos

Si no va a seguir usando los clústeres de WLS y otros componentes, siga estos pasos para eliminar los grupos de recursos para limpiar los recursos usados en este tutorial:

Escriba el nombre del grupo de recursos de los servidores de Azure SQL Database (por ejemplo, myResourceGroup) en el cuadro de búsqueda situado en la parte superior de Azure Portal y seleccione el grupo de recursos coincidente en los resultados de búsqueda.
Seleccione Eliminar grupo de recursos.
En Escriba el nombre del grupo de recursos para confirmar la eliminación, escriba el nombre del grupo de recursos.
Seleccione Eliminar.
Repita los pasos del 1 al 4 para el grupo de recursos del Administrador de tráfico; por ejemplo, myResourceGroupTM1.
Repita los pasos del 1 al 4 para el grupo de recursos del clúster principal de WLS; por ejemplo, wls-cluster-eastus-ejb120623.
Repita los pasos del 1 al 4 para el grupo de recursos del clúster WLS secundario; por ejemplo, wls-cluster-westus-ejb120623.

Pasos siguientes

En este tutorial, configurará una solución de alta disponibilidad y recuperación ante desastres que consta de un nivel de infraestructura de aplicación activo-pasivo con un nivel de base de datos activo-pasivo y en el que ambos niveles abarcan dos sitios geográficamente diferentes. En el primer sitio, tanto el nivel de infraestructura de la aplicación como el nivel de base de datos están activos. En el segundo sitio, se cierra el dominio secundario y la base de datos secundaria está en espera.

Continúe explorando las siguientes referencias para más opciones para compilar soluciones de alta disponibilidad y recuperación ante desastres y ejecutar WLS en Azure:

Soluciones de recuperación ante desastres para productos de middleware de Oracle Fusion

Documentación de confiabilidad de Azure

Compilación de soluciones para alta disponibilidad

Conmutación automática por error mediante Azure Traffic Manager

Más información sobre Oracle WebLogic en máquinas virtuales de Azure

Más información sobre Oracle WebLogic en AKS