Tutorial: Migración de WebSphere Liberty/Open Liberty a Azure Kubernetes Service (AKS) con alta disponibilidad y recuperación ante desastres

Artículo
05/17/2024

En este tutorial se muestra una manera sencilla y eficaz de implementar alta disponibilidad y recuperación ante desastres para Java mediante WebSphere Liberty/Open Liberty en Azure Kubernetes Service (AKS). La solución muestra cómo lograr un objetivo de tiempo de recuperación (RTO) y un objetivo de punto de recuperación (RPO) bajos mediante una sencilla aplicación de Jakarta EE controlada por base de datos que se ejecuta en WebSphere Liberty/Open Liberty.

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.
Configurar el clúster principal de WebSphere Liberty/Open Liberty en AKS.
Configurar la recuperación ante desastres para el clúster mediante Azure Backup.
Configurar el clúster de AKS secundario.
Configure una instancia de Azure Traffic Manager.
Prueba de una conmutación por error de principal a secundaria.

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

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 y secundaria tienen una implementación completa del clúster de Liberty. Sin embargo, la región primaria es la única que atiende 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 Azure Application Gateway para implementar este enrutamiento condicional. El clúster principal 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 para iniciar máquinas virtuales (VM) y ejecutar el clúster 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 punto de conexión del agente de escucha de lectura y escritura siempre apunta al servidor principal y está conectado a un clúster de WebSphere Liberty/Open Liberty en cada región. 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 Información general sobre la continuidad empresarial con Azure SQL Database.

Este tutorial se redactó con Azure Backup y los servicios Azure SQL Database porque el tutorial se basa en las características de alta disponibilidad de estos servicios. 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.

Requisitos previos

Suscripción a Azure. Si no tiene una suscripción a Azure, cree una cuenta gratuita antes de empezar.
Asegúrese de que se le haya asignado el rol Owner o los roles Contributor 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.
Instalación y configuración de 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 WebSphere Liberty/Open Liberty. En una sección posterior, configurará WebSphere Liberty/Open Liberty para almacenar sus datos de sesión en esta base de datos. En esta práctica se hace referencia a Creación de una tabla para la persistencia de la sesión.

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.

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

En el paso 4 para crear un nuevo grupo de recursos, guarde el valor de Nombre del grupo de recursos; por ejemplo, myResourceGroup.
En el paso 5 para el nombre de la base de datos, guarde el valor Nombre de la base de datos; por ejemplo, mySampleDatabase.
En el paso 6 para crear el servidor, siga estos pasos:
1. Rellene un nombre de servidor único; por ejemplo, sqlserverprimary-mjg032524.
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.
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.
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.
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í.

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.

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, escriba y guarde el nombre del grupo de conmutación por error único; por ejemplo, failovergroup-mjg032524.
2. En el paso 5 para configurar el servidor, seleccione la opción para crear un nuevo servidor secundario y, a continuación, siga estos pasos:
  1. Especifique un nombre único para el servidor, por ejemplo, sqlserversecondary-mjg032524.
  2. Escriba el mismo administrador del servidor y la misma contraseña que el servidor principal.
  3. En Ubicación, seleccione (US) Oeste de EE. UU.
  4. Asegúrese de que la opción Permitir que los servicios de Azure accedan al servidor esté seleccionada.
3. 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 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 WebSphere Liberty/Open Liberty más adelante.

Configuración del clúster principal de WebSphere Liberty/Open Liberty en AKS

En esta sección, creará el clúster principal de WebSphere Liberty/Open Liberty en AKS mediante la oferta IBM WebSphere Liberty y Open Liberty en Azure Kubernetes Service. El clúster secundario se restaura desde el clúster principal durante la conmutación por error mediante Azure Backup más adelante.

Implementación del clúster principal de WebSphere Liberty/Open Liberty

Para implementar el clúster principal, siga estos pasos:

Abra la oferta IBM WebSphere Liberty y Open Liberty en Azure Kubernetes Service 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:
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 para el grupo de recursos, por ejemplo, liberty-aks-eastus-mjg032524.
3. En Detalles de la instancia, en Región, seleccione Este de EE. UU.
4. Seleccione Siguiente para ir al panel AKS.
Espere un rato. Debería ver todos los campos rellenados previamente con los valores predeterminados en el panel AKS. Seleccione Siguiente para ir al panel Equilibrio de carga.
Siga estos pasos para rellenar el panel Equilibrio de carga:
1. En Conectar a Azure Application Gateway, seleccione Sí.
2. Deje los valores predeterminados para los demás campos.
3. Seleccione Siguiente para ir al panel Operador y aplicación.
Siga estos pasos para rellenar el panel Operador y aplicación:
1. Deje los valores predeterminados para los demás campos.
  
  Nota:
  
  En este tutorial se implementa Open Liberty Operator mediante los valores predeterminados. Opcionalmente, puede implementar WebSphere Liberty Operator seleccionando Sí en ¿IBM compatible?.
2. Seleccione Revisar + crear.
3. 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 unos 30 minutos en completarse. Después, debería ver el texto Su implementación se ha completado en la página de implementación.

Comprobación de la implementación del clúster

Ha implementado un clúster de AKS, una instancia de Azure Container Registry (ACR) y una instancia de Azure Application Gateway en la región primaria. El clúster de AKS es la plataforma informática de destino donde se implementa y ejecuta la aplicación. La instancia de ACR almacena la imagen de aplicación que AKS extrae durante la implementación de la aplicación. La instancia de Azure Application Gateway actúa como equilibrador de carga para la aplicación implementada en el clúster de AKS.

Siga estos pasos para comprobar estos componentes clave antes de pasar al paso siguiente:

Vuelva a la página Implementación y seleccione Salidas.
Copie el valor de la propiedad cmdToConnectToCluster. Abra un terminal, pegue el comando copiado y pulse Entrar para ejecutar. Debería ver en la salida un mensaje similar al siguiente ejemplo:
```
Merged "cluster3984d1-admin" as current context in <your-user>\.kube\config
```
Guarde el comando para poder usarlo para conectarse al clúster más adelante.

Ejecute kubectl get pod --all-namespaces en el terminal para enumerar todos los pods que se ejecutan en el clúster de AKS. Debería ver una salida similar al ejemplo siguiente:

NAMESPACE      NAME                                        READY   STATUS    RESTARTS      AGE
cert-manager   cert-manager-66bc9756fd-255pk               1/1     Running   0             8m55s
cert-manager   cert-manager-cainjector-669c9fb694-k4q88    1/1     Running   0             8m55s
cert-manager   cert-manager-webhook-84967d556d-vj4lp       1/1     Running   0             8m55s
kube-system    azure-ip-masq-agent-dgzkt                   1/1     Running   0             29m
kube-system    cloud-node-manager-6x7bp                    1/1     Running   0             29m
kube-system    coredns-789789675-6b7dh                     1/1     Running   0             28m
kube-system    coredns-789789675-n68wt                     1/1     Running   0             29m
kube-system    coredns-autoscaler-649b947bbd-zhdbn         1/1     Running   0             29m
kube-system    csi-azuredisk-node-h9p7m                    3/3     Running   0             29m
kube-system    csi-azurefile-node-jnllw                    3/3     Running   0             29m
kube-system    ingress-appgw-deployment-69944d8fb9-v9btr   1/1     Running   5 (12m ago)   17m
kube-system    konnectivity-agent-94878f88c-hfqng          1/1     Running   0             29m
kube-system    konnectivity-agent-94878f88c-ln2vp          1/1     Running   0             29m
kube-system    kube-proxy-28lkg                            1/1     Running   0             29m
kube-system    metrics-server-5fffcb8954-549xl             2/2     Running   0             28m
kube-system    metrics-server-5fffcb8954-fn56g             2/2     Running   0             28m
open-liberty   olo-controller-manager-7954d76cf8-qhmxw     1/1     Running   0             8m40s

Ejecute kubectl get secret en el terminal para enumerar todos los secretos instalados en el clúster de AKS. Debería ver un secreto en la salida, como se muestra en el ejemplo siguiente:
```
NAME           TYPE                DATA   AGE
secret3984d1   kubernetes.io/tls   2      24m
```
Este secreto es un secreto TLS que incluye datos de certificado y clave para el tráfico TLS. Copie y guarde el nombre del secreto; por ejemplo, secret3984d1, lo usará en la implementación de la aplicación más adelante.
Vuelva a la página Salidas. Copie el valor de la propiedad cmdToLoginInRegistry. Pegue el comando copiado en el terminal y pulse Entrar para ejecutar. Debería ver Inicio de sesión correcto en la salida. Mantenga abierto el terminal y úselo para una mayor configuración del clúster de WebSphere Liberty/Open Liberty más adelante.

Siga estos pasos para obtener el nombre y el nombre DNS de la dirección IP pública de Azure Application Gateway. Los usará para la implementación de aplicaciones y la configuración de Azure Traffic Manager más adelante.

En Azure Portal, en el cuadro de búsqueda, escriba Grupos de recursos y, a continuación, seleccione Grupos de recursos en los resultados de la búsqueda.
Seleccione el nombre del grupo de recursos para la región primaria, por ejemplo, liberty-aks-eastus-mjg032524.
Busque el recurso Dirección IP pública con el prefijo gwip y, a continuación, copie y guarde el nombre.
Seleccione el recurso Dirección IP pública y, a continuación, copie y guarde el Nombre DNS; por ejemplo, olgw3984d1.eastus.cloudapp.azure.com.

Habilitación de replicaciones geográficas para la instancia de ACR

La instancia de ACR está diseñada para almacenar imágenes de aplicación para clústeres primarios y secundarios. Siga estos pasos para habilitar las replicaciones geográficas para la instancia de ACR:

En Azure Portal, en el cuadro de búsqueda, escriba Grupos de recursos y, a continuación, seleccione Grupos de recursos en los resultados de la búsqueda.
Seleccione el nombre del grupo de recursos para la región primaria, por ejemplo, liberty-aks-eastus-mjg032524.
Busque el recurso de Container Registry con el prefijo acr y, a continuación, selecciónelo para abrirlo.
Selecciona Propiedades. En Plan de precios, seleccione Premium y, a continuación, seleccione Guardar. Espere hasta la finalización.
Seleccione Replicaciones geográficas y, a continuación, seleccione Agregar. En Ubicación, seleccione Oeste de EE. UU. y, a continuación, seleccione Crear. Espere hasta la finalización.
Espere un rato y seleccione Actualizar. Repita la operación hasta que vea que se muestran dos ubicaciones y el Estado sea Listo.

Utilice los pasos siguientes para obtener las credenciales de inicio de sesión en ACR. Las usará para la implementación de aplicaciones más adelante.

Seleccione Claves de acceso.
Copie y guarde el valor de Servidor de inicio de sesión, Nombre de usuario y contraseña.

Implementación de una aplicación de ejemplo

Siga estos pasos para implementar y ejecutar una aplicación Java/Jakarta EE de CRUD de ejemplo en el clúster de WebSphere Liberty/Open Liberty para la prueba de conmutación por error de recuperación ante desastres que realizará más adelante:

Descargue el ejemplo con los siguientes comandos:
```
git clone https://github.com/Azure-Samples/open-liberty-on-aks.git
cd open-liberty-on-aks
export BASE_DIR=$PWD
git checkout 20240325
```
La aplicación configura un origen de datos jdbc/JavaEECafeDB que se conecta a la instancia de Azure SQL Database que implementó anteriormente. El origen de datos se usa para almacenar datos de sesión HTTP, lo que permite la conmutación por error y el equilibrio de carga en un clúster de servidores webSphere Liberty/Open Liberty. La aplicación de ejemplo también configura un esquema de persistencia para conservar los datos de la aplicación coffee en el mismo origen de datos . Observe que la raíz de contexto del ejemplo está configurada como / en el archivo server.xml.

Use los siguientes comandos para definir variables de entorno con los valores que guardó anteriormente:

export DB_SERVER_NAME=<failover-group-name>.database.windows.net
export DB_NAME=mySampleDatabase
export DB_USER=azureuser@<failover-group-name>
export DB_PASSWORD='<SQL-Server-admin-login-password>'
export LOGIN_SERVER=<ACR-login-server>
export USER_NAME=<ACR-username>
export PASSWORD='<ACR-password>'
export INGRESS_TLS_SECRET=<TLS-secret-name>

Use los siguientes comandos para empaquetar la aplicación, compilar la imagen de Docker, insertar la imagen en la instancia de ACR e implementar el ejemplo en el clúster de AKS:

cd $BASE_DIR/java-app
mvn clean install

cd $BASE_DIR/java-app/target

# If you deployed WebSphere Liberty Operator previously, use "Dockerfile-wlp" instead of "Dockerfile"
docker buildx build --platform linux/amd64 -t javaee-cafe:v1 --pull --file=Dockerfile .
docker tag javaee-cafe:v1 ${LOGIN_SERVER}/javaee-cafe:v1
docker login -u ${USER_NAME} -p ${PASSWORD} ${LOGIN_SERVER}
docker push ${LOGIN_SERVER}/javaee-cafe:v1

cd $BASE_DIR/java-app/target
kubectl apply -f db-secret.yaml

# If you deployed WebSphere Liberty Operator previously, use "webspherelibertyapplication-agic.yaml" instead of "openlibertyapplication-agic.yaml"
kubectl apply -f openlibertyapplication-agic.yaml

Ejecute el siguiente comando para obtener la aplicación de ejemplo que implementó:

# If you deployed WebSphere Liberty Operator previously, use "WebSphereLibertyApplication" instead of "OpenLibertyApplication"
kubectl get OpenLibertyApplication

Debería ver una aplicación READY en la salida:

NAME                       IMAGE                                 EXPOSED   RECONCILED   RESOURCESREADY   READY   AGE
javaee-cafe-cluster-agic   acr3984d1.azurecr.io/javaee-cafe:v1             True         True             True    45s

Ejecute el comando siguiente para obtener el estado de los pods creados durante la implementación:

kubectl get pods

El ejemplo siguiente indica que todos los pods se están ejecutando: Si no ve una salida similar, espere un rato y repita la operación.

NAME                                        READY   STATUS    RESTARTS   AGE
javaee-cafe-cluster-agic-6bbb8d6f5c-2xjc4   1/1     Running   0          1m
javaee-cafe-cluster-agic-6bbb8d6f5c-4f449   1/1     Running   0          1m
javaee-cafe-cluster-agic-6bbb8d6f5c-m2wg6   1/1     Running   0          1m

Siga estos pasos para comprobar que la aplicación se está ejecutando según lo previsto:
1. En una nueva pestaña del explorador, abra el nombre DNS de la dirección IP pública de la instancia de Azure Application Gateway que guardó anteriormente. Use el protocolo https, por ejemplo, https://olgw3984d1.eastus.cloudapp.azure.com. Debería ver la página de bienvenida de la aplicación de ejemplo.
2. Cree un nuevo café con un nombre y un precio, por ejemplo, Café 1 con el precio 10, que 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:
Si la IU no se parece, solucione el problema antes de continuar.

Configuración de la recuperación ante desastres para el clúster mediante Azure Backup

En esta sección, configurará la recuperación ante desastres para el clúster de AKS en la región primaria mediante Azure Backup.

Crear una cuenta de almacenamiento

La copia de seguridad de AKS usa un contenedor de blobs para contener los recursos del clúster de AKS. Puede crear otro contenedor de blobs como una ubicación de almacenamiento provisional para su uso durante la restauración entre regiones.

Siga estos pasos para crear una cuenta de almacenamiento y dos contenedores: Algunos de estos pasos le dirigen a otras guías.

Inicie sesión en Azure Portal.
Cree una cuenta de almacenamiento siguiendo los pasos descritos en Crear una cuenta de almacenamiento. No es necesario que realice todos los pasos del artículo. Rellene los campos como se muestra en el panel Aspectos básicos mediante los pasos siguientes:
1. En Grupo de recursos, seleccione el grupo de recursos existente donde se implementa el clúster principal; por ejemplo, liberty-aks-eastus-mjg032524.
2. En Nombre de la cuenta de almacenamiento, escriba un nombre único, por ejemplo, storageeastusmjg032524.
3. En Región, seleccione Este de EE. UU. .
4. Seleccione Revisar y crear para aceptar las opciones predeterminadas.
5. Continúe con la validación y creación de la cuenta, y vuelva a este artículo.
Cree un contenedor de almacenamiento para la extensión de copia de seguridad de AKS siguiendo los pasos descritos en Creación de un contenedor de almacenamiento. Esta guía se utiliza aks-backup-ext como el nombre del contenedor.
Cree otro contenedor de almacenamiento como ubicación de almacenamiento provisional para su uso durante la restauración. Esta guía se utiliza staging como el nombre del contenedor.

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 primaria:

Habilite los controladores e instantáneas de CSI para el clúster. Para el comando az aks update siguiente, actualice el valor de la variable RG_NAME de Bash al nombre del grupo de recursos (por ejemplo, liberty-aks-eastus-mjg032524 y ejecútelo en el terminal local de Bash.
```
export RG_NAME=<your-aks-cluster-resource-group>
export AKS_NAME=$(az aks list \
    --resource-group ${RG_NAME} \
    --query "[0].name" \
    --output tsv | tr -d '\r')

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.
Abra el grupo de recursos que tiene AKS implementado; por ejemplo, liberty-aks-eastus-mjg032524. Seleccione el clúster de AKS en la lista de recursos.
En Configuración de la página de aterrizaje de AKS, seleccione Copia de seguridad y, a continuación, seleccione Instalar extensión.
En la página Instalar la extensión de copia de seguridad de AKS, seleccione Siguiente. Seleccione la cuenta de almacenamiento storageeastusmjg032524 y el contenedor de blobs aks-backup-ext que creó en el mismo grupo de recursos. Seleccione Siguiente y, a continuación, seleccione Crear. En completar este paso se tardan unos cinco minutos.

Copia de seguridad del clúster de AKS

Para realizar una copia de seguridad del clúster de AKS, siga estos pasos:

En Azure Portal, en el cuadro de búsqueda, busque Almacenes de copia de seguridad. Lo puede ver en Servicios. Selecciónelo.
Siga los pasos descritos en Copia de seguridad de Azure Kubernetes Service mediante Azure Backup para habilitar la copia de seguridad de AKS para el clúster principal. Ejecute los pasos hasta la sección Usar enlaces durante la copia de seguridad de AKS y use el resto de los pasos de esta sección para realizar ajustes a medida que vaya avanzando.
Cuando llegue a la sección Creación de un almacén de copia de seguridad, siga los pasos que se indican a continuación:
1. Para el paso 1, en Grupo de recursos, seleccione el grupo de recursos existente donde se implementa el clúster principal; por ejemplo, liberty-aks-eastus-mjg032524.
2. En Nombre del almacén de copia de seguridad, escriba un valor único; por ejemplo, aks-backup-vault-eastus-mjg032524.
3. En Región, seleccione Este de EE. UU. .
4. En Redundancia de almacenamiento de copia de seguridad, seleccione Redundancia global.
5. En el paso 2, en Restauración entre regiones, seleccione Habilitar.
Cuando llegue a la sección Creación de una directiva de copia de seguridad, siga los pasos que se indican a continuación:
1. Para el paso 3, escriba un nombre para la directiva de copia de seguridad, por ejemplo, aksbackuppolicy.
2. Seleccione el almacén de copia de seguridad que creó en el mismo grupo de recursos; por ejemplo, aks-backup-vault-eastus-mjg032524.
3. En el paso 4, agregue una regla de retención en la que se seleccione Vault-standard.
4. Seleccione Agregar.
En la sección Configurar copias de seguridad, siga estos pasos:
1. Omita el paso 1-5, que son para la instalación de la extensión de AKS. Comience desde el paso 6 para el clúster de AKS en la región primaria.
2. En el paso 7, en Almacén, seleccione el almacén de copia de seguridad que creó en el mismo grupo de recursos; por ejemplo, aks-backup-vault-eastus-mjg032524. Cuando se produzcan errores de permisos, seleccione Conceder permisos 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.
3. Para el paso 10, busque Seleccionar recursos para realizar la copia de seguridad. En Nombre de instancia de copia de seguridad, rellene un nombre único, por ejemplo, akseastusmjg032524. En Otras opciones, seleccione todas las opciones. Asegúrese de que Incluir secretos está seleccionado.
4. En el paso 11, se produce un error de asignación de roles. Siga los pasos 12-14 para mitigar el error.
5. Después de seleccionar Configurar copia de seguridad en el paso 15, volverá a la página Copia de seguridad. Espere un rato y, a continuación, seleccione Actualizar. Repita la operación hasta que vea que aparece la instancia de copia de seguridad y el Estado de protección es Protección configurada.

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 como máximo 24 horas después de completar el paso anterior antes de restaurar.

Siga estos pasos para comprobar que hay disponible una copia de seguridad estándar del almacén:

En la página Copia de seguridad del clúster de AKS principal, seleccione la instancia de copia de seguridad.
Espere un rato y seleccione Actualizar. Repita la operación hasta que vea que al menos un punto de restauración operativo y estándar del almacén aparece en la sección PUNTOS DE RESTAURACIÓN.

Configuración del clúster de AKS secundario

Mientras espera a que se realice una copia de seguridad estándar del almacén para el clúster de AKS principal, configure el clúster de AKS secundario para restaurarlo más adelante.

Siga los mismos pasos de la sección Implementación del clúster principal de WebSphere Liberty/Open Liberty para configurar el clúster de AKS secundario en la región secundaria, excepto por 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, liberty-aks-westus-mjg032524.
2. En Detalles de la instancia, en Región, seleccione Oeste de EE. UU.
En el panel AKS, siga estos pasos:
1. En Azure Container Registry (ACR), en Seleccionar instancia de ACR, seleccione No.
2. Seleccione la instancia de ACR existente en la región primaria que se ha habilitado con replicaciones geográficas.

Siga los mismos pasos de la sección Comprobación de la implementación del clúster para comprobar la implementación en la región secundaria, excepto las siguientes diferencias:

No es necesario copiar y guardar el nombre del secreto de TLS. El secreto de TLS se restaura a partir de la copia de seguridad del clúster de AKS principal.
Use el grupo de recursos del clúster secundario, por ejemplo, liberty-aks-westus-mjg032524, cuando busque el nombre y el nombre DNS de la dirección IP pública de la instancia de Azure Application Gateway implementada en la región secundaria.

Siga los mismos pasos de la sección Creación de una cuenta de almacenamiento para crear una cuenta de almacenamiento en la región secundaria, excepto las siguientes diferencias:

En el campo Grupo de recursos, seleccione el grupo de recursos existente donde se implementa el clúster secundario; por ejemplo, liberty-aks-westus-mjg032524.
En Nombre de la cuenta de almacenamiento, escriba un nombre único, por ejemplo, storagewestusmjg032524.
En Región, seleccione Oeste de EE. UU.

Siga los mismos pasos de la sección Habilitación de la extensión de copia de seguridad de AKS para instalar la extensión de copia de seguridad de AKS para el clúster en la región secundaria, excepto las siguientes diferencias:

En el paso 1 para habilitar los controladores e instantáneas de CSI para el clúster secundario, actualice el valor de la variable RG_NAME de Bash al grupo de recursos de la región secundaria, por ejemplo, liberty-aks-westus-mjg032524.
En el paso 2, seleccione el clúster de AKS del grupo de recursos de la región secundaria, por ejemplo, liberty-aks-westus-mjg032524.
En el paso 4 para instalar la extensión de copia de seguridad de AKS para el clúster secundario, seleccione la cuenta de almacenamiento que creó en el mismo grupo de recursos de la región secundaria, por ejemplo, storagewestusmjg032524.

Para ahorrar costes, detenga 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). Debe iniciarlo antes de restaurar el clúster más adelante.

Configuración de una instancia de Azure Traffic Manager

La copia de seguridad estándar del almacén se mencionó en la sección Espere a que se produzca una copia de seguridad estándar del almacén. Después de ver que hay disponible una copia de seguridad estándar del almacén, puede crear una instancia de Azure Traffic Manager 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 dirección IP pública de la instancia de Azure Application Gateway en la región primaria. El punto de conexión secundario apunta a la dirección IP pública de la instancia de Azure Application Gateway en la región secundaria.

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. Solo necesita las secciones siguientes: Crear un perfil de Traffic Manager y Agregar puntos de conexión 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:

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. En Nombre, escriba un nombre de perfil de Traffic Manager único, por ejemplo, tmprofile-mjg032524.
2. Para Método de enrutamiento, seleccione Prioridad.
3. En Grupo de recursos, escriba y guarde el nuevo nombre del grupo de recursos, por ejemplo, myResourceGroupTM1.
Cuando llegue a la sección Agregar puntos de conexión de Traffic Manager, siga estos pasos:
1. Después de abrir el perfil de Traffic Manager en el paso 2, en la página Configuración, siga estos pasos:
  1. En Período de vida (TTL) de DNS, escriba 10.
  2. En Configuración de supervisión de punto de conexión, para Protocolo, seleccione https y, para Puerto, escriba 443.
  3. En Configuración de conmutación por error de punto de conexión rápido, use los siguientes valores:
    - En Sondeo interno, seleccione 10.
    - En Número tolerado de errores, escriba 3.
    - En Tiempo de espera de sondeo, escriba 5.
  4. 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 el nombre de la dirección IP pública de la instancia de Azure Application Gateway en la región 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 el nombre de la dirección IP pública de la instancia de Azure Application Gateway en la región 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 estado Estado de supervisión del punto de conexión myPrimaryEndpoint sea En línea y el Estado de supervisión del punto de conexión myFailoverEndpoint sea Degradado.

A continuación, siga estos pasos para comprobar que se puede acceder a la aplicación de ejemplo implementada en el clúster principal desde el perfil de Traffic Manager:

Seleccione Información general para el perfil de Traffic Manager que creó.
Compruebe y copie el nombre de DNS del perfil de Traffic Manager y reemplace el protocolo http por https. Por ejemplo, https://tmprofile-mjg032524.trafficmanager.net.
Abra la dirección URL en una nueva pestaña del explorador. Debería ver que el café que creó anteriormente aparece en la página.
Cree otro café con un nombre y un precio diferentes, por ejemplo, Café 2 con el precio 20, que 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:

Si la IU no se parece, solucione el problema antes de continuar. Mantenga abierta la consola y úsela para la prueba de conmutación por error más adelante.

Ha completado la configuración del perfil de Traffic Manager. Mantenga abierta la página y úsela para supervisar el cambio de estado del punto de conexión en un evento de conmutación por error más adelante.

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

En esta sección, para probar la conmutación por error, conmute por error manualmente el servidor de Azure SQL Database, restaure la copia de seguridad del clúster de AKS y, a continuación, conmute por recuperación mediante Azure Portal.

Conmutación por error en un sitio secundario

Para simular una interrupción de la región primaria, detenga el clúster de AKS principal siguiendo los pasos descritos en Detención e inicio de un clúster de Azure Kubernetes Service (AKS).

A continuación, inicie el clúster de AKS secundario para que se pueda restaurar a partir de la copia de seguridad del clúster principal.

Nota:

Si tiene aplicaciones de WebSphere Liberty/Open Liberty que se ejecutan en el clúster de destino de restauración, para evitar conflictos, siga estos pasos para limpiar las aplicaciones de WebSphere Liberty/Open Liberty:

Conéctese al clúster de destino ejecutando el comando para cmdToConnectToCluster que guardó anteriormente.
Para las aplicaciones de Open Liberty, ejecute el siguiente comando:
```
kubectl delete OpenLibertyApplication --all --all-namespaces
```
Para las aplicaciones de WebSphere Open Liberty, ejecute el siguiente comando:
```
kubectl delete WebSphereLibertyApplication --all --all-namespaces
```

A continuación, cambie a la pestaña del explorador del perfil de Traffic Manager y compruebe que el Estado de supervisión de ambos puntos de conexión myPrimaryEndpoint y myFailoverEndpoint es Degradado.

Ahora, 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, por ejemplo, failovergroup-mjg032524.
Seleccione Conmutación por error y, después, Sí.
Espere hasta que se complete.

A continuación, siga estos pasos para restaurar la copia de seguridad del clúster de AKS principal en el clúster de AKS secundario:

En Azure Portal, en el cuadro de búsqueda, escriba Centro de copia de seguridad y seleccione Centro de copia de seguridad en los resultados de la búsqueda.
En Administrar, seleccione Instancias de copia de seguridad. Filtre por el tipo de origen de datos Kubernetes Services. Busque la instancia de copia de seguridad que creó en la sección anterior, por ejemplo, <aks-cluster-name>\akseastusmjg032524.
Seleccione la instancia de copia de seguridad.
Seleccione Restaurar.
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.
En el panel Punto de restauración, se selecciona el punto de restauración operativo y estándar de almacén más reciente. Mantenga los valores predeterminados y seleccione Siguiente: Parámetros de restauración.
En el panel Parámetros de restauración , siga estos pasos:
1. En Seleccionar clúster de destino, seleccione el clúster de AKS secundario 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 la región 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.
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: Validation completed successfully. Si no es así, solucione el problema antes de continuar.
Seleccione Siguiente: revisar y restaurar. Después, seleccione Restaurar. La restauración del clúster tarda aproximadamente 10 minutos.
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:
Espere un rato y seleccione Actualizar. Repita la operación hasta que vea que el Estado es Completado.

A continuación, siga estos pasos para comprobar que la restauración funciona según lo previsto:

Cambie al terminal en el que se ha conectado al clúster de AKS secundario.

Ejecute el siguiente comando para restaurar la aplicación de ejemplo a partir de la copia de seguridad:

kubectl get OpenLibertyApplication

Debería ver una aplicación READY en la salida:

NAME                       IMAGE                                 EXPOSED   RECONCILED   RESOURCESREADY   READY   AGE
javaee-cafe-cluster-agic   acr3984d1.azurecr.io/javaee-cafe:v1             True         True             True    3m

Ejecute el comando siguiente para obtener el estado de los pods creados durante la implementación:

kubectl get pods

Debería ver tres pods en ejecución en la salida:

NAME                                        READY   STATUS    RESTARTS   AGE
javaee-cafe-cluster-agic-7bb57dd945-6ljll   1/1     Running   0          3m
javaee-cafe-cluster-agic-7bb57dd945-h2xdf   1/1     Running   0          3m
javaee-cafe-cluster-agic-7bb57dd945-k744w   1/1     Running   0          3m

Cambie a la pestaña del explorador del perfil de Traffic Manager y, a continuación, actualice la página hasta que vea que el Estado de supervisión del punto de conexión myFailoverEndpoint es En línea y que el Estado de supervisión del punto de conexión myPrimaryEndpoint es Degradado.
Cambie a la pestaña del explorador con el nombre DNS del perfil de Traffic Manager; por ejemplo, https://tmprofile-mjg032524.trafficmanager.net. Actualice la página y debería ver los mismos datos almacenados en la tabla de datos de la aplicación y la tabla de sesión mostrada. La UI que ve debería ser similar a la que aparece en la siguiente captura de pantalla:

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:

La aplicación configura el tiempo de espera de la sesión como 1 hora. Dependiendo del tiempo necesario para la conmutación por error, es posible que no vea los datos de sesión mostrados en la sección Nuevo café de la interfaz de usuario de la aplicación de ejemplo si expiró más de una hora antes.

Reprotección del sitio de conmutación por error

Ahora que la región secundaria es el sitio de conmutación por error y está activa, debe volver a protegerla con Azure Backup.

En primer lugar, siga los mismos pasos de la sección Copia de seguridad del clúster de AKS para realizar una copia de seguridad del clúster de AKS secundario, excepto las siguientes diferencias:

Para Crear un almacén de copia de seguridad, siga estos pasos:
1. En Grupo de recursos, seleccione el grupo de recursos existente implementado en la región secundaria, por ejemplo, liberty-aks-westus-mjg032524.
2. En Nombre del almacén de copia de seguridad, escriba un valor único; por ejemplo, aks-backup-vault-westus-mjg032524.
3. En Región, seleccione Oeste de EE. UU.
Para Crear una directiva de copia de seguridad, siga estos pasos:
1. Seleccione el almacén de copia de seguridad que creó en la región secundaria, por ejemplo, aks-backup-vault-westus-mjg032524.
En Configurar copias de seguridad, siga estos pasos:
1. Seleccione el almacén de copia de seguridad que creó en la región secundaria, por ejemplo, aks-backup-vault-westus-mjg032524.
2. En el nombre de la Instancia de copia de seguridad, rellene un nombre único, por ejemplo, akswestusmjg032524.

A continuación, siga los mismos pasos de la sección Espere a que se realice una copia de seguridad estándar del almacén hasta que haya disponible una copia de seguridad estándar del almacén del clúster de AKS secundario, pero seleccione la instancia de copia de seguridad en la página Copia de seguridad del clúster de AKS secundario.

Conmutación por recuperación al sitio principal

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

Al preparar la conmutación por recuperación, siga estos pasos:
1. Detenga el clúster de AKS secundario para simular una interrupción de la región secundaria.
2. Inicie el clúster de AKS principal.
3. Conéctese al clúster de AKS principal y limpie las aplicaciones de WebSphere Liberty/Open Liberty.
Cuando haya restaurado la copia de seguridad del clúster de AKS secundario al clúster de AKS principal, siga estos pasos:
1. Seleccione la instancia de copia de seguridad en la región secundaria, por ejemplo, <aks-cluster-name>\akswestusmjg032524.
2. En el panel Parámetros de restauración , siga estos pasos:
  1. En Seleccionar clúster de destino, seleccione el clúster de AKS principal que creó en la región Este de EE. UU.
  2. En Ubicación de almacenamiento provisional de copia de seguridad, seleccione la cuenta de almacenamiento que creó en la región Este de EE. UU.
Cuando haya comprobado que la restauración funciona según lo previsto, siga estos pasos:
1. Cambie al terminal donde se ha conectado al clúster de AKS principal y compruebe que la aplicación se restaura correctamente.
2. Cambie a la pestaña del explorador del perfil de Traffic Manager y, a continuación, actualice la página hasta que vea que el Estado de supervisión del punto de conexión myPrimaryEndpoint es En línea y que el Estado de supervisión del punto de conexión myFailoverEndpoint es Degradado.

Limpieza de recursos

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

En Azure Portal, en el cuadro de búsqueda, escriba el nombre del grupo de recursos de los servidores de Azure SQL Database, por ejemplo, myResourceGroup, 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 de Traffic Manager; por ejemplo, myResourceGroupTM1.
En Azure Portal, en el cuadro de búsqueda, escriba Almacenes de copia de seguridad y seleccione Almacenes de copia de seguridad en los resultados de la búsqueda. Debería ver dos almacenes de copia de seguridad en la lista, por ejemplo, aks-backup-vault-eastus-mjg032524 y aks-backup-vault-westus-mjg032524. Para cada uno de ellos, siga estos pasos:
1. Seleccione esta opción para abrir el almacén de copia de seguridad.
2. Seleccione Administrar>Propiedades>Eliminación temporal>Actualizar. Junto a Habilitar eliminación temporal, desmarque la casilla y, a continuación, seleccione Actualizar.
3. Seleccione Administrar>Instancias de copia de seguridad. Filtre por el tipo de origen de datos Kubernetes Services. Seleccione la instancia que creó y elimínela.
Espere hasta que se eliminen las dos instancias de Copia de seguridad.
Repita los pasos del 1 al 4 para el grupo de recursos del clúster principal; por ejemplo, liberty-aks-eastus-mjg032524.
Repita los pasos del 1 al 4 para el grupo de recursos del clúster secundario; por ejemplo, liberty-aks-westus-mjg032524.

Pasos siguientes

En este tutorial, ha configurado una solución de alta disponibilidad y recuperación ante desastres de WebSphere Liberty/Open Liberty 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, el dominio secundario se restaura con el servicio Azure Backup 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 WebSphere en Azure:

Documentación sobre confiabilidad de Azure

Compilación de soluciones para alta disponibilidad

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

Más información sobre WebSphere en Azure

Compartir vía