Evento
Construír aplicacións e axentes de IA
Mar 17, 9 PM - Mar 21, 10 AM
Únete á serie de encontros para construír solucións de IA escalables baseadas en casos de uso do mundo real con compañeiros desenvolvedores e expertos.
Rexistrar agoraEste explorador xa non é compatible.
Actualice a Microsoft Edge para dispoñer das funcionalidades máis recentes, as actualizacións de seguranza e a asistencia técnica.
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:
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.
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.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:
myResourceGroup
.mySampleDatabase
.sqlserverprimary-mjg032524
.azureuser
.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:
failovergroup-mjg032524
.sqlserversecondary-mjg032524
.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.
Nota
Este artículo le guía para crear una base de datos única en Azure SQL Database con autenticación de SQL para simplificar, esto se debe a que la configuración de alta disponibilidad y recuperación ante desastres de la que trata este artículo ya resulta muy compleja. Una práctica más segura consiste en usar la Autenticación de Microsoft Entra para Azure SQL para autenticar la conexión del servidor de bases de datos. Para obtener información sobre cómo configurar la conexión a la base de datos con autenticación Microsoft Entra, consulte Implementar una aplicación Java con Open Liberty o WebSphere Liberty en un clúster de Azure Kubernetes Service (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.
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:
liberty-aks-eastus-mjg032524
.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:
Siga estos pasos para rellenar el panel Operador y aplicación:
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?.
Seleccione Revisar + crear.
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.
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.
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 de la región primaria( por ejemplo, liberty-aks-eastus-mjg032524.
Busque el recurso del registro de contenedores con el prefijo acry, 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 los valores de Nombre de registro y Servidor de inicio de sesión.
Nota
En este artículo se usa el comando az acr build
para compilar e insertar la imagen de Docker en Container Registry, sin usar username
y password
de Container Registry. Todavía es posible usar el nombre de usuario y la contraseña con docker login
y docker push
. El uso de nombre de usuario y contraseña es menos seguro que la autenticación sin contraseña.
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 REGISTRY_NAME=<ACR-registry-name>
export LOGIN_SERVER=<ACR-login-server>
export INGRESS_TLS_SECRET=<TLS-secret-name>
Use el comando az acr build
para compilar e insertar la imagen de Docker en Container Registry, como se muestra en el ejemplo siguiente:
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"
az acr build \
--registry ${REGISTRY_NAME} \
--image javaee-cafe:v1 \
--file Dockerfile \
.
Utilice los siguientes comandos para implementar la aplicación de ejemplo en el clúster AKS:
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:
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.
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.
En esta sección, configurará la recuperación ante desastres para el clúster de AKS en la región primaria mediante Azure Backup.
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.
liberty-aks-eastus-mjg032524
.storageeastusmjg032524
.aks-backup-ext
como el nombre del contenedor.staging
como el nombre del contenedor.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.
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:
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
.
En Nombre del almacén de copia de seguridad, escriba un valor único; por ejemplo, aks-backup-vault-eastus-mjg032524
.
En Región, seleccione Este de EE. UU. .
En Redundancia de almacenamiento de copia de seguridad, seleccione Redundancia global.
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:
Para el paso 3, escriba un nombre para la directiva de copia de seguridad, por ejemplo, aksbackuppolicy
.
Seleccione el almacén de copia de seguridad que creó en el mismo grupo de recursos; por ejemplo, aks-backup-vault-eastus-mjg032524
.
En el paso 4, agregue una regla de retención en la que se seleccione Vault-standard.
Seleccione Agregar.
En la sección Configurar copias de seguridad, siga estos pasos:
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.
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.
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.
En el paso 11, se produce un error de asignación de roles. Siga los pasos 12-14 para mitigar el error.
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.
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.
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:
liberty-aks-westus-mjg032524
.En el panel AKS, siga estos pasos:
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:
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:
liberty-aks-westus-mjg032524
.storagewestusmjg032524
.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:
RG_NAME
de Bash al grupo de recursos de la región secundaria, por ejemplo, liberty-aks-westus-mjg032524
.liberty-aks-westus-mjg032524
.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.
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:
tmprofile-mjg032524
.myResourceGroupTM1
.Cuando llegue a la sección Agregar puntos de conexión de Traffic Manager, siga estos pasos:
myFailoverEndpoint
, siga estos pasos: 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.
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.
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:
failovergroup-mjg032524
.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:
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.
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.
Si los errores siguen sucediendo después de que finalicen las asignaciones de roles, seleccione Volver a validar para actualizar los permisos.
Al conceder los permisos que faltan, si se le pide que especifique un ámbito, acepte el valor predeterminado.
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.
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:
liberty-aks-westus-mjg032524
.aks-backup-vault-westus-mjg032524
.aks-backup-vault-westus-mjg032524
.aks-backup-vault-westus-mjg032524
.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.
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:
Cuando haya restaurado la copia de seguridad del clúster de AKS secundario al clúster de AKS principal, siga estos pasos:
<aks-cluster-name>\akswestusmjg032524
.Cuando haya comprobado que la restauración funciona según lo previsto, siga estos pasos:
myPrimaryEndpoint
es En línea y que el Estado de supervisión del punto de conexión myFailoverEndpoint
es Degradado.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:
myResourceGroup
, y seleccione el grupo de recursos coincidente en los resultados de búsqueda.myResourceGroupTM1
.liberty-aks-eastus-mjg032524
.liberty-aks-westus-mjg032524
.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:
Evento
Construír aplicacións e axentes de IA
Mar 17, 9 PM - Mar 21, 10 AM
Únete á serie de encontros para construír solucións de IA escalables baseadas en casos de uso do mundo real con compañeiros desenvolvedores e expertos.
Rexistrar agoraFormación
Módulo
Proyecto guiado: implementación de aplicaciones en Azure Kubernetes Service - Training
Le damos la bienvenida a esta experiencia interactiva de validación de aptitudes. Completar este módulo le ayuda a prepararse para la evaluación de Implementación y administración de contenedores con Azure Kubernetes Service.
Certificación
Microsoft Certified: Azure Database Administrator Associate - Certifications
Administre una infraestructura de base de datos de SQL Server para bases de datos relacionales locales e híbridas en la nube mediante las ofertas de bases de datos relacionales PaaS de Microsoft.