Compartir vía


Tutorial: Migración de Oracle WebLogic Server a Azure Kubernetes Service (AKS) con redundancia geográfica

En este tutorial se muestra una manera sencilla y eficaz de implementar una estrategia de continuidad empresarial y recuperación ante desastres (DR) para Java mediante Oracle WebLogic Server (WLS) en Azure Kubernetes Service (AKS). La solución muestra cómo realizar copias de seguridad y restaurar una carga de trabajo de WLS mediante una sencilla aplicación de Jakarta EE controlada por base de datos que se ejecuta en AKS. La redundancia geográfica es un tema complejo, con muchas soluciones posibles. La mejor solución depende de sus requisitos únicos. Para ver otras formas de implementar la redundancia geográfica, 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.
  • Establecer y configurar los clústeres principales de WLS en AKS.
  • Configurar la redundancia geográfica mediante Azure Backup.
  • Restaurar un clúster de WLS en una región secundaria.
  • Configure una instancia de Azure Traffic Manager.
  • Probar la conmutación por error.

En el diagrama siguiente se muestra la arquitectura que ha creado:

Diagrama de la arquitectura de la solución de WLS en máquinas virtuales de Azure con alta disponibilidad y recuperación ante desastres.

Azure Traffic Manager comprueba el estado de las regiones y enruta el tráfico en consecuencia al nivel de aplicación. La región primaria tiene una implementación completa del clúster de WLS. Solo la región primaria está atendiendo activamente las solicitudes de red de los usuarios. La región secundaria restaura el clúster de WLS a partir de copias de seguridad de la región primaria si hay un desastre o un evento de recuperación ante desastres declarado. La región secundaria 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 Azure Application Gateway y el operador de Kubernetes WebLogic (WKO) para implementar este enrutamiento condicional. WKO se integra profundamente con las comprobaciones de estado de AKS, lo que permite a Azure Traffic Manager tener un alto nivel de conocimiento del estado de la carga de trabajo de Java. El clúster principal de WLS se está ejecutando y se cierra el clúster secundario.

El objetivo de tiempo de recuperación de conmutación por error geográfica (RTO) del nivel de aplicación depende del tiempo para iniciar AKS y ejecutar el clúster de WLS secundario, que suele ser inferior a una hora. Los datos de la aplicación se conservan y replican en el grupo de conmutación por error de Azure SQL Database, con un RTO de minutos u horas y un objetivo de punto de recuperación (RPO) de minutos u horas. En esta arquitectura, Azure Backup solo tiene una copia de seguridad estándar del almacén para la configuración de WLS todos los días. Para obtener más información, consulte ¿Qué es la copia de seguridad de Azure Kubernetes Services (AKS)?.

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 lectura 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 obtener información sobre el RPO y el RTO de la conmutación por error geográfica de Azure SQL Database, consulte Información general sobre la continuidad empresarial.

Este artículo se redactó 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 Oracle Fusion Middleware.

En este artículo se usa Azure Backup para proteger AKS. Para obtener información sobre la disponibilidad regional, los escenarios admitidos y las limitaciones, consulte Matriz de compatibilidad con la copia de seguridad de Azure Kubernetes Service. Actualmente, Azure Backup admite copias de seguridad de nivel de almacén y restauración entre regiones, que están disponibles en versión preliminar pública. Para obtener más información, consulte Habilitación de copias de seguridad de nivel de almacén para AKS y restauración entre regiones mediante Azure Backup.

Nota:

En este artículo, con frecuencia debe crear identificadores únicos para varios recursos. En este artículo se usa la convención de <initials><sequence-number> como prefijo. Por ejemplo, si su nombre es Emily Juanita Bernal, un identificador único sería ejb01. Para la desambiguación adicional, podría anexar la fecha de hoy en formato MMDD, como ejb010307.

Requisitos previos

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 descritos en Inicio rápido: Creación de una base de datos única - Azure SQL Database. Siga los pasos hasta la sección "Limpiar recursos", pero sin incluirla. Siga las instrucciones a medida que avanza por el artículo y vuelva a este artículo después de crear y configurar la instancia de Azure SQL Database.

  1. Cuando llegue a la sección Creación de una base de datos única, siga los pasos que se indican a continuación:

    1. En el paso 4 para crear un nuevo grupo de recursos, guarde el valor de Nombre del grupo de recursos; por ejemplo, myResourceGroup.
    2. En el paso 5 para el nombre de la base de datos, guarde el valor Nombre de la base de datos; por ejemplo, mySampleDatabase.
    3. En el paso 6 para crear el servidor, siga estos pasos:
      1. Guarde 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. Guarde el valor de Inicio de sesión de administrador del servidor; por ejemplo, azureuser.
      5. Guarde 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, para 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 obtener 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 .
  2. 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 a El cliente con la dirección IP 'xx.xx.xx.xx' no puede acceder al servidor, seleccione Allowlist IP 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.

  1. Para crear el esquema, escriba las siguientes consultas:

    1. 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 TLOG_msp4_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_msp5_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 Query succeeded: Affected rows: 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).

    2. Para crear el esquema de la aplicación de ejemplo, escriba la siguiente consulta:

      CREATE TABLE COFFEE (ID NUMERIC(19) NOT NULL, NAME VARCHAR(255) NULL, PRICE FLOAT(32) NULL, PRIMARY KEY (ID));
      CREATE TABLE SEQUENCE (SEQ_NAME VARCHAR(50) NOT NULL, SEQ_COUNT NUMERIC(28) NULL, PRIMARY KEY (SEQ_NAME));
      

      Después de una ejecución correcta, debería ver el mensaje Query succeeded: Affected rows: 0.

Ya ha terminado con el artículo "Inicio rápido: Creación de una base de datos única - Azure SQL Database".

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 avanza por 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.

  1. 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 guarde el nombre del grupo de conmutación por error; por ejemplo, failovergroupname-ejb120623.
      2. Escriba y guarde 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.
  2. Después de completar todos los pasos de la sección Probar 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.

Obtención del nombre de usuario del administrador de la base de datos y la cadena de conexión JDBC para el grupo de conmutación por error

Los pasos siguientes le dirigen para obtener el nombre de usuario de la base de datos y el cadena de conexión de JDBC para la base de datos dentro del grupo de conmutación por error. Estos valores son diferentes de los valores correspondientes para la base de datos principal.

  1. En Azure Portal, busque el grupo de recursos en el que implementó la base de datos principal.

  2. En la lista de recursos, seleccione la base de datos principal con el tipo Base de datos SQL.

  3. En Configuración, seleccione Cadenas de conexión.

  4. Seleccione JDBC.

  5. En el área de texto de JDBC (autenticación de SQL), seleccione el icono de copia para colocar el valor del cadena de conexión JDBC en el portapapeles.

  6. Pegue el valor en un editor de texto. Lo editará en otro paso.

  7. Vuelva al grupo de recursos.

  8. Seleccione el recurso de tipo SQL Server que contiene la base de datos que acaba de examinar en los pasos anteriores.

  9. En seleccione Administración de datos, seleccione Grupos de conmutación por error.

  10. En la tabla del centro de la página, seleccione el grupo de conmutación por error.

  11. En el área de texto en Punto de conexión del agente de escucha de lectura y escritura, seleccione el icono de copia para colocar el valor del cadena de conexión JDBC en el portapapeles.

  12. Pegue el valor en una nueva línea en el editor de texto. El editor de texto debe tener ahora líneas similares al ejemplo siguiente:

    jdbc:sqlserver://ejb010307db.database.windows.net:1433;database=ejb010307db;user=azureuser@ejb010307db;password={your_password_here};encrypt=true;trustServerCertificate=false;hostNameInCertificate=*.database.windows.net;loginTimeout=30;
    ejb010307failover.database.windows.net
    
  13. Cree una nueva línea con las siguientes modificaciones:

    1. Copie toda la primera línea.

    2. Cambie la parte de nombre de host de la dirección URL para usar el nombre de host desde la línea Punto de conexión del agente de escucha de lectura y escritura.

    3. Quite todo después del par name=value para database. En otras palabras, quite todo lo que incluya y siga a ; inmediatamente después de database=ejb010307db.

      Cuando haya terminado, la cadena debería tener una apariencia similar a la del siguiente ejemplo:

      jdbc:sqlserver://ejb010307failover.database.windows.net:1433;database=ejb010307db
      

      Este valor es la cadena de conexión de JDBC.

  14. En el mismo editor de texto, obtenga el nombre de usuario de la base de datos obteniendo el valor del parámetro user de la cadena de conexión JDBC original y reemplazando el nombre de la base de datos por la primera parte de la línea de Punto de conexión del agente de escucha de lectura y escritura. Siguiendo con el ejemplo anterior, el valor sería azureuser@ejb010307failover. Este valor es el nombre de usuario del administrador de la base de datos.

Establecimiento y configuración de los clústeres principales de WLS en AKS

En esta sección, creará un clúster de WLS en AKS mediante la oferta Oracle WebLogic Server en AKS. El clúster del Este de EE. UU. es el principal y se configura como el clúster activo.

Preparación de una 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 datos jdbc/WebLogicCafeDB 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 de la aplicación coffee en el mismo origen de datos jdbc/WebLogicCafeDB.

Siga estos pasos para compilar y empaquetar el ejemplo:

  1. 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, lo puede ignorar.

  2. 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-cafe/weblogic-cafe/target/weblogic-cafe.war. Si no ve el paquete, debe solucionar el problema antes de continuar.

Creación de una cuenta de almacenamiento y un contenedor de almacenamiento para contener la aplicación de ejemplo

Siga estos pasos para crear una cuenta de almacenamiento y un contenedor. Algunos de estos pasos le dirigen a otras guías. Después de completar los pasos, puede cargar una aplicación de ejemplo para implementarla en WLS.

  1. Inicie sesión en Azure Portal.

  2. Cree una cuenta de almacenamiento siguiendo los pasos descritos en Crear una cuenta de almacenamiento. Use las especializaciones siguientes para los valores del artículo:

    • Cree un nuevo grupo de recursos para la cuenta de almacenamiento.
    • En Región, seleccione Este de EE. UU. .
    • En Nombre de cuenta de almacenamiento, use el mismo valor que el nombre del grupo de recursos.
    • En Rendimiento, seleccione Estándar.
    • En Redundancia, seleccione Almacenamiento con redundancia local (LRS).
    • Las pestañas restantes no necesitan especializaciones.
  3. Continúe con la validación y creación de la cuenta, y vuelva a este artículo.

  4. Cree un contenedor de almacenamiento dentro de la cuenta siguiendo los pasos descritos en la sección Creación de un contenedor de Inicio rápido: Carga, descarga y enumeración de blobs con Azure Portal.

  5. Con el mismo artículo, cargue el paquete azure-cafe/weblogic-cafe/target/weblogic-cafe.war que creó anteriormente siguiendo los pasos descritos en la sección Carga de un blob en bloques. Después, regrese a este artículo.

Implementación de WLS en AKS

Siga estos pasos para implementar WLS en AKS:

  1. Abra la oferta Oracle WebLogic Server en AKS en el explorador y seleccione Crear. Debería ver el panel Aspectos básicos de la oferta.

    Captura de pantalla de Azure Portal que muestra el panel Aspectos básicos de Oracle WebLogic Server en AKS.

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

    1. 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.

    2. 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 diferente para el grupo de recursos, por ejemplo, wlsaks-eastus-20240109.

    3. En Detalles de la instancia, en Región, seleccione Este de EE. UU.

    4. En Credenciales WebLogic, indique una contraseña para el administrador de WebLogic y el cifrado del modelo de WebLogic, respectivamente. Guarde el nombre de usuario y la contraseña del administrador de WebLogic.

    5. En Configuración básica opcional, en ¿Aceptar valores predeterminados para la configuración opcional?, seleccione No. Se muestra la configuración opcional.

      Captura de pantalla de Azure Portal que muestra el panel Aspectos básicos de Oracle WebLogic Server en AKS con la configuración básica opcional.

    6. En Prefijo de nombre para servidor administrado, rellene msp. Configurará la tabla TLOG de WLS con el prefijo TLOG_${serverName}_ más adelante. En este artículo se crea una tabla TLOG con el nombre TLOG_msp${index}_WLStore. Si desea usar un prefijo de nombre de servidor administrado diferente, asegúrese de que el valor coincide con las convenciones de nomenclatura de las tablas de Microsoft SQL Server y los nombres de tabla reales.

    7. Deje los valores predeterminados para los demás campos.

  3. Seleccione Siguiente para ir al panel AKS.

  4. En Selección de imagen, proporcione la siguiente información:

    • En Nombre de usuario para la autenticación de inicio de sesión único de Oracle, rellene el nombre de usuario de SSO de Oracle a partir de las condiciones previas.
    • En Contraseña para la autenticación de inicio de sesión único de Oracle, rellene las credenciales de SSO de Oracle a partir de las condiciones previas.

    Captura de pantalla de Azure Portal que muestra el panel Oracle WebLogic Server en AKS - Selección de imagen.

  5. En Aplicación, siga estos pasos:

    1. En la sección Aplicación , junto a ¿Implementar una aplicación?, seleccione .
    2. Junto a Paquete de aplicación (.war, .ear, .jar), seleccione Examinar.
    3. Empiece a escribir el nombre de la cuenta de almacenamiento de la sección anterior. Cuando aparezca la cuenta de almacenamiento deseada, selecciónela.
    4. Seleccione el contenedor de almacenamiento de la sección anterior.
    5. Active la casilla situada junto a weblogic-cafe.war, que cargó en la sección anterior. Elija Seleccionar.
    6. Deje los valores predeterminados para los demás campos.

    Captura de pantalla de Azure Portal que muestra el panel Oracle WebLogic Server en AKS - Selección de aplicación.

  6. Seleccione Siguiente.

  7. Deje los valores predeterminados en el panel Configuración de TLS/SSL y, a continuación, seleccione Siguiente para ir al panel Equilibrio de carga.

    Captura de pantalla de Azure Portal que muestra el clúster de Oracle WebLogic Server en AKS, panel Equilibrio de carga.

  8. En el panel Equilibrio de carga, junto a Crear entrada para la consola de administración. Asegúrese de que ninguna aplicación con la ruta de acceso /console* provocará conflictos con la ruta de acceso de la consola de administración, seleccione .

  9. Deje los valores predeterminados en los restantes campos y seleccione Siguiente.

  10. Deje los valores predeterminados en el panel DNS y seleccione Siguiente para ir al panel Base de datos.

    Captura de pantalla de Azure Portal que muestra el clúster de Oracle WebLogic Server en AKS, panel Base de datos.

  11. Introduzca los valores siguientes en el panel Base de datos:

  12. Seleccione Revisar + crear.

  13. Espere hasta que se complete correctamente el proceso Ejecutando validación final... y, a continuación, seleccione Crear. Después de un tiempo, debería ver la página Implementación donde se muestra Implementación en curso.

Nota:

Si ve algún problema durante el proceso Ejecutando validación final..., corríjalo e inténtelo de nuevo.

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

Configuración del almacenamiento de datos de TLOG

En esta sección, configurará el almacenamiento de datos de TLOG reemplazando el modelo de imagen de WLS con ConfigMap. Para obtener más información sobre ConfigMap, consulte ConfigMap de modelo de WebLogic Deploy Tooling.

Esta sección requiere un terminal Bash con la CLI de Azure y kubectl instalados. Siga estos pasos para obtener el YAML necesario y configurar el almacenamiento de datos de TLOG:

  1. Siga los pasos que se indican a continuación para conectarse al clúster de AKS:

    1. Abra Azure Portal y vaya al grupo de recursos que aprovisionó en la sección Implementación de WLS en AKS.
    2. Seleccione el clúster de AKS en la lista de recursos y, a continuación, seleccione Conectar para conectarse al clúster de AKS.
    3. Seleccione la CLI de Azure y siga los pasos para conectarse al clúster de AKS en el terminal local.
  2. Siga estos pasos para obtener la entrada topology: del YAML del modelo de imagen de WLS:

    1. Abra Azure Portal y vaya al grupo de recursos que aprovisionó en la sección Implementación de WLS en AKS.
    2. Seleccione Configuración>Implementaciones. Seleccione la primera implementación cuyo nombre comienza con oracle.20210620-wls-on-aks.
    3. Seleccione Salidas. Copie el valor de shellCmdtoOutputWlsImageModelYaml en el portapapeles. El valor es un comando de shell que descodifica la cadena base64 del archivo de modelo y guarda el contenido en un archivo denominado model.yaml.
    4. Pegue el valor en el terminal de Bash y ejecute el comando para generar el archivo model.yaml.
    5. Edite el archivo para quitar todo el contenido, excepto para la entrada de nivel superior topology:. No debe haber entradas de nivel superior en el archivo, excepto para topology:.
    6. Guarde el archivo.
  3. Siga estos pasos para obtener el nombre y el nombre del espacio de nombres de ConfigMap del YAML del modelo de dominio de WLS:

    1. Abra Azure Portal y vaya al grupo de recursos que se aprovisionó en la sección Implementación de WLS en AKS.

    2. Seleccione Configuración>Implementaciones. Seleccione la primera implementación cuyo nombre comienza con oracle.20210620-wls-on-aks.

    3. Seleccione Salidas. Copie el valor de shellCmdtoOutputWlsDomainYaml en el portapapeles. El valor es un comando de shell para descodificar la cadena base64 del archivo de modelo y guardar contenido en model.yaml.

    4. Pegue el valor en el terminal y obtenga un archivo denominado domain.yaml.

    5. Busque en el domain.yaml para obtener los siguientes valores.

      • spec.configuration.model.configMap. Si aceptó los valores predeterminados, este valor es sample-domain1-wdt-config-map.
      • metadata.namespace. Si aceptó los valores predeterminados, este valor es sample-domain1-ns.

      Para mayor comodidad, puede usar el siguiente comando para guardar estos valores como variables de shell:

      export CONFIG_MAP_NAME=sample-domain1-wdt-config-map
      export WLS_NS=sample-domain1-ns
      
  4. Utilice el siguiente comando para obtener el YAML ConfigMap.

    kubectl get configmap ${CONFIG_MAP_NAME} -n ${WLS_NS} -o yaml > configMap.yaml
    
  5. Siga estos pasos para crear el archivo tlog-db-model.yaml:

    1. En un editor de texto, cree un archivo vacío denominado tlog-db-model.yaml.

    2. Inserte el contenido del archivo model.yaml, agregue una línea en blanco y, a continuación, inserte el contenido del archivo configMap.yaml.

  6. En el archivo tlog-db-model.yaml, busque la línea que termina con ListenPort: 8001. Añada este texto en la línea siguiente, teniendo sumo cuidado de que TransactionLogJDBCStore quede exactamente debajo de ListenPort y que el resto de líneas del siguiente fragmento tengan una sangría de dos, como se muestra en el siguiente ejemplo:

    TransactionLogJDBCStore:
      Enabled: true
      DataSource: jdbc/WebLogicCafeDB
      PrefixName: TLOG_${serverName}_
    

    El tlog-db-model.yaml completado debe tener un aspecto muy parecido al ejemplo siguiente:

    topology:
      Name: "@@ENV:CUSTOM_DOMAIN_NAME@@"
      ProductionModeEnabled: true
      AdminServerName: "admin-server"
      Cluster:
        "cluster-1":
          DynamicServers:
            ServerTemplate: "cluster-1-template"
            ServerNamePrefix: "@@ENV:MANAGED_SERVER_PREFIX@@"
            DynamicClusterSize: "@@PROP:CLUSTER_SIZE@@"
            MaxDynamicClusterSize: "@@PROP:CLUSTER_SIZE@@"
            MinDynamicClusterSize: "0"
            CalculatedListenPorts: false
      Server:
        "admin-server":
          ListenPort: 7001
      ServerTemplate:
        "cluster-1-template":
          Cluster: "cluster-1"
          ListenPort: 8001
          TransactionLogJDBCStore:
            Enabled: true
            DataSource: jdbc/WebLogicCafeDB
            PrefixName: TLOG_${serverName}_
      SecurityConfiguration:
        NodeManagerUsername: "@@SECRET:__weblogic-credentials__:username@@"
        NodeManagerPasswordEncrypted: "@@SECRET:__weblogic-credentials__:password@@"
    
    resources:
      JDBCSystemResource:
        jdbc/WebLogicCafeDB:
          Target: 'cluster-1'
          JdbcResource:
            JDBCDataSourceParams:
              JNDIName: [
                jdbc/WebLogicCafeDB
              ]
              GlobalTransactionsProtocol: None
            JDBCDriverParams:
              DriverName: com.microsoft.sqlserver.jdbc.SQLServerDriver
              URL: '@@SECRET:ds-secret-sqlserver-1709938597:url@@'
              PasswordEncrypted: '@@SECRET:ds-secret-sqlserver-1709938597:password@@'
              Properties:
                user:
                  Value: '@@SECRET:ds-secret-sqlserver-1709938597:user@@'
            JDBCConnectionPoolParams:
                TestTableName: SQL SELECT 1
                TestConnectionsOnReserve: true
    
  7. Invalide el modelo de WLS con ConfigMap. Para invalidar el modelo de WLS, reemplace el ConfigMap existente por el nuevo modelo. Para obtener más información, consulte Actualización de un modelo existente en la documentación de Oracle. Ejecute los siguientes comandos para volver a crear el ConfigMap:

    export CM_NAME_FOR_MODEL=sample-domain1-wdt-config-map
    kubectl -n sample-domain1-ns delete configmap ${CM_NAME_FOR_MODEL}
    
    # replace path of tlog-db-model.yaml
    kubectl -n sample-domain1-ns create configmap ${CM_NAME_FOR_MODEL} \
      --from-file=tlog-db-model.yaml
    kubectl -n sample-domain1-ns label configmap ${CM_NAME_FOR_MODEL} \
      weblogic.domainUID=sample-domain1
    
  8. Reinicie el clúster de WLS mediante los siguientes comandos. Necesita una actualización gradual para que el nuevo modelo funcione.

    export RESTART_VERSION=$(kubectl -n sample-domain1-ns get domain sample-domain1 '-o=jsonpath={.spec.restartVersion}')
    # increase restart version
    export RESTART_VERSION=$((RESTART_VERSION + 1))
    
    kubectl -n sample-domain1-ns patch domain sample-domain1 \
        --type=json \
        '-p=[{"op": "replace", "path": "/spec/restartVersion", "value": "'${RESTART_VERSION}'" }]'
    

Asegúrese de que los pods de WLS se están ejecutando antes de continuar. Puede utilizar el siguiente comando para observar el estado de los pods:

kubectl get pod -n sample-domain1-ns -w

Nota:

En este artículo, los modelos de WLS se incluyen en la imagen de contenedor de la aplicación, que creó WLS en la oferta de AKS. TLOG se configura invalidando el modelo existente con el WDT ConfigMap que contiene el archivo de modelo y usa el campo configuration.model.configMap de CRD de dominio para hacer referencia al mapa. En escenarios de producción, las imágenes auxiliares son el mejor enfoque recomendado para incluir el modelo en archivos de modelo de imagen, archivos de archivado de aplicaciones y la instalación de WebLogic Deploy Tooling, en sus pods. Esta característica elimina la necesidad de proporcionar estos archivos en la imagen especificada en domain.spec.image.

Configuración de la redundancia geográfica mediante Azure Backup

En esta sección, usará Azure Backup para realizar copias de seguridad de clústeres de AKS mediante la extensión Backup, que se debe instalar en el clúster.

Siga estos pasos para configurar la redundancia geográfica:

  1. Cree un nuevo contenedor de almacenamiento para la extensión de copia de seguridad de AKS en la cuenta de almacenamiento que creó en la sección Creación de una cuenta de almacenamiento y un contenedor de almacenamiento para contener la aplicación de ejemplo.

  2. Use los siguientes comandos para instalar la extensión de copia de seguridad de AKS y habilitar los controladores e instantáneas CSI para el clúster:

    #replace with your resource group name.
    export RG_NAME=wlsaks-eastus-20240109
    export AKS_NAME=$(az aks list \
        --resource-group ${RG_NAME} \
        --query "[0].name" \
        --output tsv)
    
    az aks update \
        --resource-group ${RG_NAME} \
        --name ${AKS_NAME} \
        --enable-disk-driver \
        --enable-file-driver \
        --enable-blob-driver \
        --enable-snapshot-controller --yes
    

    Los controladores tardan unos 5 minutos en habilitarse. Asegúrese de que los comandos se completen sin errores antes de continuar.

  1. Abra el grupo de recursos que tiene AKS implementado. Seleccione el clúster de AKS en la lista de recursos.

  2. En la página de aterrizaje de AKS, seleccione Configuración>Copia de seguridad>Instalar extensión.

  3. En la página Instalar la extensión de copia de seguridad de AKS, seleccione Siguiente. Seleccione la cuenta de almacenamiento y el contenedor de blobs que creó en los pasos anteriores. Seleccione Siguiente y, después, Crear. En completar este paso se tardan unos cinco minutos.

  1. Abra Azure Portal, en la barra de búsqueda de la parte superior, busque Almacenes de Backup. Debería verlo en Servicios. Selecciónelo.

  2. Para habilitar la copia de seguridad de AKS, siga los pasos descritos en Copia de seguridad de Azure Kubernetes Service mediante Azure Backup hasta la sección "Uso de enlaces durante la copia de seguridad de AKS". Realice los ajustes indicados en los pasos siguientes.

  3. Cuando llegue a la sección "Crear un almacén de Backup", realice los siguientes ajustes:

    • En el paso 1, en Regiones, seleccione Este de EE. UU. En Redundancia de almacenamiento de copia de seguridad, use Redundancia global.

      Captura de pantalla de Azure Portal que muestra el panel Aspectos básicos del almacén de Backup.

    • Para el paso 2, habilite Restauración entre regiones.

  4. Cuando llegue a la sección "Crear una directiva de copia de seguridad", realice los siguientes ajustes cuando se le pida que cree una directiva de retención:

    1. Agregue una regla de retención en la que se seleccione Vault-standard.

      Captura de pantalla de Azure Portal que muestra la selección de la opción Vault-standard.

    2. Seleccione Agregar.

  5. Cuando llegue a la sección "Configurar copias de seguridad", realice los siguientes ajustes. El paso 1-5 es la instalación de la extensión de AKS. Omita el paso 1-5 y comience en el paso 6.

    • En el paso 7, se encuentra con errores de permiso. Seleccione Conceder permiso para continuar. Una vez completada la implementación de permisos, si el error sigue apareciendo, seleccione Volver a validar para actualizar las asignaciones de roles.

      Captura de pantalla de Azure Portal que muestra la opción de conceder permiso en la configuración de copia de seguridad de AKS.

    • Para el paso 10, busque Seleccionar recursos para la copia de seguridad y realice los siguientes ajustes:

      • En Nombre de instancia de copia de seguridad, rellene un nombre único.
      • En Espacios de nombres, seleccione espacios de nombres para WebLogic Operator y WebLogic Server. En este artículo, seleccione weblogic-operator-ns y sample-domain1-ns.
      • En Otras opciones, seleccione todas las opciones. Asegúrese de que Incluir secretos está seleccionado.

      Captura de pantalla de Azure Portal que muestra la opción Configurar copia de seguridad de AKS, Seleccionar recursos.

    • En el paso 11, se produce un error de asignación de roles. Seleccione el origen de datos de la lista y seleccione Asignar roles que faltan para mitigar el error.

      Captura de pantalla de Azure Portal que muestra la validación de copia de seguridad de configuración de AKS.

Preparación para restaurar el clúster de WLS en una región secundaria

En esta sección, se preparará para restaurar el clúster de WLS en la región secundaria. Aquí, la región secundaria es Oeste de EE. UU. Antes de restaurarlo, debe tener un clúster de AKS con la extensión de copia de seguridad de AKS instalada en la región Oeste de EE. UU.

Configuración de Azure Container Registry para la replicación geográfica

Siga estos pasos para configurar Azure Container Registry (ACR) para la replicación geográfica, que contiene la imagen de WLS que creó en la sección Implementación de WLS en AKS. Para habilitar la replicación de ACR, debe actualizarla al plan de precios Premium. Para más información, consulte Replicación geográfica en Azure Container Registry.

  1. Abra el grupo de recursos que aprovisionó en la sección Implementación de WLS en AKS. En la lista de recursos, seleccione el ACR cuyo nombre comienza con wlsaksacr.
  2. En la página de aterrizaje de ACR, seleccione Configuración>Propiedades. En Plan de precios, seleccione Premium y, a continuación, seleccione Guardar.
  3. En el panel de navegación, seleccione Servicios>Replicaciones geográficas. Seleccione Agregar para agregar la región de replicación en la página.
  4. En la página Crear replicación, en Ubicación, seleccione Oeste de EE. UU. y, a continuación, seleccione Crear.

Una vez finalizada la implementación, ACR está habilitado para la replicación geográfica.

Creación de una cuenta de almacenamiento en una región secundaria

Para habilitar la extensión de copia de seguridad de AKS, debe proporcionar una cuenta de almacenamiento con un contenedor vacío en la misma región.

Para restaurar la copia de seguridad entre regiones, debe proporcionar una ubicación de almacenamiento provisional en la que se hidraten los datos de la copia de seguridad. Esta ubicación de almacenamiento provisional incluye un grupo de recursos y una cuenta de almacenamiento dentro de la misma región y suscripción que el clúster de destino para la restauración.

Siga estos pasos para crear una cuenta de almacenamiento y un contenedor. Algunos de estos pasos le dirigen a otras guías.

  1. Inicie sesión en Azure Portal.
  2. Cree una cuenta de almacenamiento siguiendo los pasos descritos en Crear una cuenta de almacenamiento. No es necesario realizar todos los pasos del artículo. Rellene los campos que se muestran en el panel Aspectos básicos. En Región, seleccione Oeste de EE. UU. y, a continuación, seleccione Revisar y crear para aceptar las opciones predeterminadas. Continúe con la validación y creación de la cuenta, y vuelva a este artículo.
  3. Cree un contenedor de almacenamiento para la extensión de copia de seguridad de AKS siguiendo los pasos descritos en la sección Creación de un contenedor de Inicio rápido: Carga, descarga y enumeración de blobs con Azure Portal.
  4. Cree un contenedor de almacenamiento como ubicación de almacenamiento provisional para su uso durante la restauración.

Preparación de un clúster de AKS en una región secundaria

En las secciones siguientes se muestra cómo crear un clúster de AKS en una región secundaria.

Creación de un clúster de AKS

En este artículo se expone una aplicación de WLS mediante el controlador de entrada de Application Gateway. En esta sección, creará un nuevo clúster de AKS en la región Oeste de EE. UU. A continuación, habilitará el complemento del controlador de entrada con una nueva instancia de Application Gateway. Para obtener más información, consulte Habilitación del complemento de controlador de entrada para un nuevo clúster de AKS con una nueva instancia de Application Gateway.

Para crear el clúster de AKS, siga estos pasos:

  1. Use los siguientes comandos para crear un grupo de recursos en la región secundaria:

    export RG_NAME_WESTUS=wlsaks-westus-20240109
    
    az group create --name ${RG_NAME_WESTUS} --location westus
    
  2. Use los siguientes comandos para implementar un clúster de AKS con el complemento habilitado:

    export AKS_NAME_WESTUS=${RG_NAME_WESTUS}aks
    export GATEWAY_NAME_WESTUS=${RG_NAME_WESTUS}gw
    
    az aks create \
        --resource-group ${RG_NAME_WESTUS} \
        --name ${AKS_NAME_WESTUS} \
        --network-plugin azure \
        --enable-managed-identity \
        --enable-addons ingress-appgw \
        --appgw-name ${GATEWAY_NAME_WESTUS} \
        --appgw-subnet-cidr "10.225.0.0/16" \
        --generate-ssh-keys
    

    Este comando crea automáticamente una instancia de Application Gateway de Standard_v2 SKU con el nombre ${RG_NAME_WESTUS}gw en el grupo de recursos del nodo de AKS. El grupo de recursos del nodo se llama MC_resource-group-name_cluster-name_location de forma predeterminada.

    Nota:

    El clúster de AKS que aprovisionó en la sección Implementación de WLS en AKS se ejecuta en tres zonas de disponibilidad en la región Este de EE. UU. Las zonas de disponibilidad no se admiten en la región Oeste de EE. UU. El clúster de AKS en Oeste de EE. UU. no tiene redundancia de zona. Si el entorno de producción requiere redundancia de zona, asegúrese de que la región emparejada admite zonas de disponibilidad. Para obtener más información, consulte la sección Información general sobre las zonas de disponibilidad para clústeres de AKS de Creación de un clúster de Azure Kubernetes Service (AKS) que usa zonas de disponibilidad.

  3. Use los comandos siguientes para obtener la dirección IP pública de la instancia de Application Gateway. Guarde la dirección IP, que usará más adelante en este artículo.

    export APPGW_ID=$(az aks show \
        --resource-group ${RG_NAME_WESTUS} \
        --name ${AKS_NAME_WESTUS} \
        --query 'addonProfiles.ingressApplicationGateway.config.effectiveApplicationGatewayId' \
        --output tsv)
    echo ${APPGW_ID}
    export APPGW_IP_ID=$(az network application-gateway show \
        --id ${APPGW_ID} \
        --query frontendIPConfigurations\[0\].publicIPAddress.id \
        --output tsv)
    echo ${APPGW_IP_ID}
    export APPGW_IP_ADDRESS=$(az network public-ip show \
        --id ${APPGW_IP_ID} \
        --query ipAddress \
        --output tsv)
    echo "App Gateway pubilc IP address: ${APPGW_IP_ADDRESS}"
    
  4. Use el siguiente comando para adjuntar una etiqueta de nombre de servicio de nombres de dominio (DNS) al recurso de dirección IP pública. Reemplace <your-chosen-DNS-name> por un valor apropiado, por ejemplo, ejb010316.

    az network public-ip update --ids ${APPGW_IP_ID} --dns-name <your-chosen-DNS-name>
    
  5. Puede comprobar el nombre de dominio completo (FQDN) de la IP pública con az network public-ip show. En el ejemplo siguiente se muestra un FQDN con la etiqueta de DNS ejb010316:

    az network public-ip show \
        --id ${APPGW_IP_ID} \
        --query dnsSettings.fqdn \
        --output tsv
    

    Esto genera una salida similar a la del siguiente ejemplo:

    ejb010316.westus.cloudapp.azure.com
    

Nota:

Si trabaja con un clúster de AKS existente, complete las dos acciones siguientes antes de continuar:

  • Habilite el complemento del controlador de entrada siguiendo los pasos descritos en Habilitación del complemento del controlador de entrada de Application Gateway para un clúster de AKS existente.
  • Si tiene WLS en ejecución en el espacio de nombres de destino, para evitar conflictos, limpie los recursos de WLS en el espacio de nombres del operador WebLogic y el espacio de nombres de WebLogic Server. En este artículo, la oferta de WLS en AKS aprovisionó el WebLogic Operator en el espacio de nombres weblogic-operator-ns y WebLogic Server en el espacio de nombres sample-domain1-ns. Ejecute kubectl delete namespace weblogic-operator-ns sample-domain1-ns para eliminar los dos espacios de nombres.

Habilitación de la extensión de copia de seguridad de AKS

Antes de continuar, siga estos pasos para instalar la extensión de copia de seguridad de AKS en el clúster de la región secundaria:

  1. Use el siguiente comando para conectarse al clúster de AKS en la región Oeste de EE. UU.:

    az aks get-credentials \
        --resource-group ${RG_NAME_WESTUS} \
        --name ${AKS_NAME_WESTUS}
    
  2. Use el siguiente comando para habilitar los controladores e instantáneas de CSI para el clúster:

    az aks update \
        --resource-group ${RG_NAME_WESTUS} \
        --name ${AKS_NAME_WESTUS} \
        --enable-disk-driver \
        --enable-file-driver \
        --enable-blob-driver \
        --enable-snapshot-controller --yes
    
  1. Abra el grupo de recursos que tiene AKS implementado. Seleccione el clúster de AKS en la lista de recursos.

  2. En la página de aterrizaje de AKS, seleccione Configuración>Copia de seguridad>Instalar extensión.

  3. En la página Instalar la extensión de copia de seguridad de AKS, seleccione Siguiente. Seleccione la cuenta de almacenamiento y el contenedor de blobs que creó en los pasos anteriores. Seleccione Siguiente y, después, Crear. En completar este paso se tardan unos cinco minutos.

Nota:

Para ahorrar costes, puede detener el clúster de AKS en la región secundaria siguiendo los pasos descritos en Detención e inicio de un clúster de Azure Kubernetes Service (AKS). Inícielo antes de restaurar el clúster de WLS.

Espere a que se produzca una copia de seguridad estándar del almacén

En AKS, el nivel estándar de almacén es el único nivel que admite la redundancia geográfica y la restauración entre regiones. Como se indica en ¿Qué nivel de almacenamiento de copia de seguridad admite la copia de seguridad de AKS?, "Solo se mueve un punto de recuperación programado al día al nivel de almacén". Debe esperar a que se produzca una copia de seguridad estándar del almacén. Un buen límite inferior es esperar 24 horas después de completar el paso anterior antes de continuar.

Detención del clúster principal

El clúster de WLS principal y el clúster de WLS secundario están configurados con la misma base de datos TLOG. Solo un clúster puede poseer la base de datos al mismo tiempo. Para asegurarse de que el clúster secundario funciona correctamente, detenga el clúster principal de WLS. En este artículo, detenga el clúster de AKS para deshabilitar el clúster de WLS mediante los pasos siguientes:

  1. Abra Azure Portal y vaya al grupo de recursos que aprovisionó en la sección Implementación de WLS en AKS.
  2. Abra el clúster de AKS enumerado en el grupo de recursos.
  3. Seleccione Detener para detener el clúster de AKS. Asegúrese de que la implementación finaliza antes de continuar.

Restauración del clúster de WLS

La copia de seguridad de AKS admite copias de seguridad de nivel operativo y de nivel de almacén. Solo se pueden usar copias de seguridad almacenadas en el nivel de almacén para realizar una restauración en un clúster de una región diferente (región emparejada de Azure). De acuerdo con las reglas de retención establecidas en la directiva de copia de seguridad, la primera copia de seguridad correcta de un día se mueve a la región entre contenedores de blobs. Para obtener más información, consulte la sección ¿Qué nivel de almacenamiento de copia de seguridad admite la copia de seguridad de AKS? de ¿Qué es la copia de seguridad de Azure Kubernetes Service?

Después de configurar la redundancia geográfica en la sección Configuración de la redundancia geográfica mediante Azure Backup, las copias de seguridad de nivel de almacén tardan al menos un día en estar disponibles para la restauración.

Para restaurar el clúster de WLS, siga estos pasos:

  1. Abra Azure Portal y busque Centro de copia de seguridad. Seleccione Centro de copia de seguridad en Servicios.

  2. En Administrar, seleccione Instancias de copia de seguridad. Filtre por el tipo de origen de datos Servicios de Kubernetes para buscar la instancia de copia de seguridad que creó en la sección anterior.

  3. Seleccione la instancia de copia de seguridad para ver la lista de puntos de restauración. En este artículo, el nombre de instancia es una cadena similar a wlsonaks*\wlsaksinstance20240109.

    Captura de pantalla de Azure Portal que muestra los puntos de restauración de la instancia de Copia de seguridad.

  4. Seleccione la copia de seguridad operativa y estándar de almacén más reciente y, a continuación, seleccione Más opciones. Seleccione Restaurar para iniciar el proceso de restauración.

  5. En la página Restaurar, el panel predeterminado es Punto de restauración. Seleccione Anterior para cambiar al panel Aspectos básicos. En Región de restauración, seleccione Región secundaria y, a continuación, seleccione Siguiente: Punto de restauración.

    Captura de pantalla de Azure Portal que muestra el panel Aspectos básicos de restauración.

  6. En el panel Punto de restauración, en Seleccionar nivel para restaurar, seleccione Almacén de almacenes y, a continuación, seleccione Siguiente:Restaurar parámetros.

    Captura de pantalla de Azure Portal que muestra el panel Punto de restauración.

  7. En el panel Parámetros de restauración , siga estos pasos:

    1. En Seleccionar clúster de destino, seleccione el clúster de AKS que creó en la región Oeste de EE. UU. Se produce un problema de permisos como se muestra en la captura de pantalla siguiente. Seleccione Conceder permiso para mitigar los errores.

    2. En Ubicación de almacenamiento provisional de copia de seguridad, seleccione la cuenta de almacenamiento que creó en Oeste de EE. UU. Se produce un problema de permisos como se muestra en la captura de pantalla siguiente. Seleccione Asignar roles que faltan para mitigar los errores.

    3. Si los errores siguen sucediendo después de que finalicen las asignaciones de roles, seleccione Volver a validar para actualizar los permisos.

      Captura de pantalla de Azure Portal que muestra el panel Parámetro de restauración.

    4. Al conceder los permisos que faltan, si se le pide que especifique un ámbito, acepte el valor predeterminado.

    5. Seleccione Validar. Debería ver el mensaje Validación completada correctamente. Si no es así, solucione el problema antes de continuar.

  8. Seleccione Siguiente:Revisar y restaurar y, a continuación, seleccione Restaurar. La restauración del clúster de WLS tarda aproximadamente 10 minutos.

  9. Puede supervisar el proceso de restauración desde Centro de copia de seguridad>Supervisión e informes>Trabsjos de copia de seguridad, como se muestra en la captura de pantalla siguiente:

    Captura de pantalla de Azure Portal que muestra una restauración entre regiones en curso.

  10. Seleccione Actualizar para ver el progreso más reciente.

  11. Una vez completado el proceso sin error, detenga el clúster de AKS de copia de seguridad. Si no lo hace, se producen conflictos de propiedad al acceder a la base de datos de TLOG en pasos posteriores.

  12. Inicie el clúster principal.

Configuración de una instancia de Azure Traffic Manager

En esta sección, creará una instancia de Azure Traffic Manager para distribuir el tráfico a las aplicaciones públicas en las regiones globales de Azure. El punto de conexión principal apunta a la instancia de Azure Application Gateway en el clúster de WLS principal y el punto de conexión secundario apunta a la instancia de Azure Application Gateway en el clúster de WLS secundario.

Para crear un perfil de Azure Traffic Manager, siga los pasos de 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 avanza por estas secciones y vuelva a este artículo después de crear y configurar Azure Traffic Manager:

  1. Cuando llegue a la sección Crear un perfil de Traffic Manager, en el paso 2, para Crear perfil de Traffic Manager, siga estos pasos:

    1. Guarde el nombre de perfil de Traffic Manager único para Nombre (por ejemplo, tmprofile-ejb120623).
    2. Guarde el nuevo nombre del grupo de recursos para Grupo de recursos; por ejemplo, myResourceGroupTM1.
  2. Cuando llegue a la sección Agregar puntos de conexión de Traffic Manager, siga estos pasos:

    1. Después del paso Seleccione el perfil de los resultados de la búsqueda, siga estos pasos:
      1. En Configuración, seleccione Configuración.
      2. En Período de vida (TTL) de DNS, 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 se complete.
    2. En el paso 4 para agregar el punto de conexión myPrimaryEndpoint principal, 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 de WLS Este de EE. UU. que guardó anteriormente. Debería ver una entrada coincidente. Selecciónela para Dirección IP pública.
    3. En el paso 6 para agregar un punto de conmutación por error/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 de WLS Oeste de EE. UU. que guardó anteriormente. Debería ver una entrada coincidente. Selecciónela para Dirección IP pública.
    4. Espere un rato. Seleccione Actualizar hasta que el valor de Estado de supervisión sea uno de los siguientes:
      • El punto de conexión principal sea En línea.
      • El punto de conexión de conmutación por error sea Degradado.
  3. Cuando llegue a la sección Prueba de un perfil de Traffic Manager, siga estos pasos:

    1. En la subsección Compruebe el nombre DNS, en el paso 3, guarde el nombre de 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. En el paso 4, no puede acceder a /weblogic/ready, que se espera porque se detiene el clúster secundario.
      3. Vuelva a habilitar el punto de conexión principal.

Ahora, el punto de conexión principal tiene los estados Habilitado y En línea y el punto de conexión de conmutación por error tiene los estados Habilitado y Degradado en el perfil de Traffic Manager. Mantenga abierta la página para supervisar el estado del punto de conexión más adelante.

Prueba de una conmutación por error de principal a secundaria

Para probar la conmutación por error, en esta sección se conmuta por error manualmente el servidor de base de datos principal y el clúster de WLS al servidor de base de datos secundario y al clúster de WLS.

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-cafe de la aplicación implementada, por ejemplo, http://tmprofile-ejb120623.trafficmanager.net/weblogic-cafe. Cree un nuevo 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 UI que ve debería ser similar a la que aparece en la siguiente captura de pantalla:

Captura de pantalla de la IU de la aplicación de ejemplo.

Si la IU no se parece, solucione el problema antes de continuar.

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

Conmutación por error en un sitio secundario

Siga estos pasos para conmutar por error de principal a secundario.

En primer lugar, siga estos pasos para detener el clúster de AKS principal:

  1. Abra Azure Portal y vaya al grupo de recursos que se aprovisionó en la sección Implementación de WLS en AKS.
  2. Abra el clúster de AKS enumerado en el grupo de recursos.
  3. Seleccione Detener para detener el clúster de AKS. Asegúrese de que la implementación finaliza antes de continuar.

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

  1. Cambie a la pestaña del explorador del grupo de conmutación por error de Azure SQL Database.
  2. Seleccione Conmutación por error>.
  3. Espere hasta que se complete.

A continuación, siga estos pasos para iniciar el clúster secundario.

  1. Abra Azure Portal y vaya al grupo de recursos que tiene el clúster de AKS en la región secundaria.
  2. Abra el clúster de AKS enumerado en el grupo de recursos.
  3. Seleccione Iniciar para iniciar el clúster de AKS. Asegúrese de que la implementación finaliza antes de continuar.

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:

  1. 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 de supervisión del punto de conexión myFailoverEndpoint es En línea.

  2. 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:

    Captura de pantalla de la interfaz de usuario de la aplicación de ejemplo después de la conmutación por error.

    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 principal

Para conmutar por recuperación al sitio primario, debe asegurarse de que los dos clústeres tienen una configuración de copia de seguridad reflejada. Para llegar a este estado, siga los pasos que se indican a continuación:

  1. Habilite las copias de seguridad del clúster de AKS en la región Oeste de EE. UU. siguiendo los pasos descritos en la sección Configuración de la redundancia geográfica mediante Azure Backup, a partir del paso 4.
  2. Restaure la copia de seguridad del nivel de almacén más reciente en el clúster de la región Este de EE. UU. siguiendo los pasos descritos en la sección Preparación para restaurar el clúster de WLS en una región secundaria. Omita los pasos que ya ha completado.
  3. Siga los pasos similares 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.

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:

  1. En el cuadro de búsqueda de la parte superior de Azure Portal, escriba Almacenes de Backup y seleccione los almacenes de copia de seguridad en los resultados de búsqueda.
  2. Seleccione Administrar>Propiedades>Eliminación temporal>Actualizar. Junto a Permitir eliminación temporal, desactive la casilla.
  3. Seleccione Administrar>Instancias de copia de seguridad. Seleccione la instancia que creó y elimínela.
  4. 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.
  5. Seleccione Eliminar grupo de recursos.
  6. En Escriba el nombre del grupo de recursos para confirmar la eliminación, escriba el nombre del grupo de recursos.
  7. Seleccione Eliminar.
  8. Repita los pasos del 4 al 7 para el grupo de recursos de Traffic Manager; por ejemplo, myResourceGroupTM1.
  9. Repita los pasos del 4 al 7 para el grupo de recursos del clúster principal de WLS; por ejemplo, wls-aks-eastus-20240109.
  10. Repita los pasos del 4 al 7 para el grupo de recursos del clúster secundario de WLS; por ejemplo, wls-aks-westus-20240109.

Pasos siguientes

En este tutorial, ha configurado 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 conocer más opciones para compilar soluciones de alta disponibilidad y recuperación ante desastres y ejecutar WLS en Azure: