Tutorial: Migrar o WebSphere Liberty/Open Liberty para o AKS (Serviço de Kubernetes do Azure) com alta disponibilidade e recuperação de desastre

Este tutorial mostra um jeito simples e eficaz de implementar alta disponibilidade e recuperação de desastre (HA/DR) para Java usando o WebSphere Liberty/Open Liberty no AKS (Serviço de Kubernetes do Azure). A solução ilustra como alcançar um Objetivo de Tempo de Recuperação (RTO) e um Objetivo de Ponto de Recuperação (RPO) baixos usando um aplicativo Jakarta EE simples orientado a banco de dados em execução no WebSphere Liberty/Open Liberty.

HA/DR é um tópico complexo, com muitas soluções possíveis. A melhor solução dependerá das suas necessidades específicas. Para conhecer outras maneiras de implementar HA/DR, consulte os recursos ao final deste artigo.

Neste tutorial, você aprenderá a:

  • Use as práticas recomendadas otimizadas do Azure para entender a alta disponibilidade e recuperação de desastre.
  • Configure um grupo de failover do Banco de Dados SQL do Microsoft Azure em regiões associadas.
  • Configure o cluster primário do WebSphere Liberty/Open Liberty no AKS.
  • Configure a recuperação de desastre para o cluster usando o Backup do Azure.
  • Configure o cluster AKS secundário.
  • Configure um Gerenciador de Tráfego do Azure.
  • Teste o failover do primário para o secundário.

O diagrama a seguir ilustra a arquitetura que você cria:

Diagrama da arquitetura da solução do WebSphere Liberty/Open Liberty no AKS com alta disponibilidade e recuperação de desastre.

O Gerenciador de Tráfego do Azure verifica a integridade de suas regiões e roteia o tráfego de acordo com a camada de aplicativo. Tanto a região primária como a região secundária têm uma implantação completa do cluster do Liberty. No entanto, somente a região primária processa ativamente solicitações de rede dos usuários. A região secundária é passiva e se mantém ativada para receber tráfego apenas quando a região primária apresenta uma interrupção do serviço. O Gerenciador de Tráfego do Azure usa o recurso de verificação de integridade do Gateway de Aplicativo do Azure para implementar esse roteamento condicional. O cluster primário se mantém em execução e o cluster secundário é desligado. O RTO de failover geográfico da camada de aplicativo depende do tempo para iniciar VMs (máquinas virtuais) e executar o cluster secundário. O RPO depende do Banco de Dados SQL do Azure porque os dados persistem e replicam no grupo de failover do Banco de Dados SQL do Azure.

A camada do banco de dados consiste em um grupo de failover do Banco de Dados SQL do Azure com um servidor primário e um servidor secundário. O ponto de extremidade do ouvinte de leitura/gravação sempre aponta para o servidor primário e está conectado a um cluster do WebSphere Liberty/Open Liberty em cada região. Um failover geográfico alterna todos os bancos de dados secundários no grupo para a função primária. Para obter o RPO e o RTO de failover geográfico do Banco de Dados SQL do Azure, consulte Visão geral da continuidade dos negócios com o Banco de Dados SQL do Azure.

Este tutorial foi escrito com os serviços de Backup do Azure e o Banco de Dados SQL do Azure porque depende dos recursos de HA desses serviços. Há outras opções de banco de dados possíveis, mas você deve considerar os recursos de HA de qualquer banco de dados escolhido.

Pré-requisitos

Configurar um grupo de failover do Banco de Dados SQL do Azure em regiões associadas

Nesta seção, você cria um grupo de failover do Banco de Dados SQL do Azure em regiões associadas para uso com seus clusters e aplicativos do WebSphere Liberty/Open Liberty. Em uma seção posterior, você configura o WebSphere Liberty/Open Liberty para armazenar seus dados de sessão nesse banco de dados. Essa prática faz referência ao tópico Criar uma tabela para persistência de sessão.

Primeiro, crie o Banco de Dados primário do SQL do Azure seguindo as etapas do portal do Azure em Início Rápido: criar um banco de dados individual - Banco de Dados SQL do Azure. Siga as etapas até, mas não incluindo, a seção "Limpar recursos". Use as instruções a seguir ao ler o artigo e, em seguida, retorne a este artigo depois de criar e configurar o Banco de Dados SQL do Azure.

Quando você chegar à seção Criar um banco de dados individual, siga estas etapas:

  1. Na etapa 4 para criar um novo grupo de recursos, salve o valor Nome do grupo de recursos; por exemplo, myResourceGroup.
  2. Na etapa 5 para o nome do banco de dados, salve o valor Nome do banco de dados; por exemplo, mySampleDatabase.
  3. Na etapa 6 para criar o servidor, sigas estas etapas:
    1. Preencha um nome de servidor exclusivo; por exemplo, sqlserverprimary-mjg032524.
    2. Em Local, selecione (EUA) Leste dos EUA.
    3. Em Método de autenticação, selecione Usar autenticação do SQL.
    4. Salve o valor de Logon do administrador do servidor; por exemplo, azureuser.
    5. Salve o valor da Senha.
  4. Na etapa 8, em Ambiente de carga de trabalho, selecione Desenvolvimento. Leia a descrição e considere outras opções para sua carga de trabalho.
  5. Na etapa 11, em Redundância de armazenamento de backup, selecione Armazenamento de backup com redundância local. Considere outras opções para seus backups. Para obter mais informações, consulte a seção Redundância de armazenamento de backup de Backups automatizados no Banco de Dados SQL do Azure.
  6. Na etapa 14, na configuração de Regras de firewall, em Permitir que serviços e recursos do Azure acessem este servidor, selecione Sim.

Em seguida, crie um grupo de failover do Banco de Dados SQL do Azure seguindo as etapas do portal do Azure em Configurar um grupo de failover para o Banco de Dados SQL do Azure. Você só precisa das seguintes seções: Criar grupo de failover e Testar recuperação panejada. Use as etapas a seguir ao ler o artigo e, em seguida, retorne a este artigo depois de criar e configurar o grupo de failover do Banco de Dados SQL do Azure:

  1. Quando você chegar à seção Criar grupo de failover, use as seguintes etapas:

    1. Na etapa 5 para criar o grupo de failover, insira e salve o nome exclusivo do grupo de failover; por exemplo, failovergroup-mjg032524.
    2. Na etapa 5 para configurar o servidor, selecione a opção para criar um novo servidor secundário e siga estas etapas:
      1. Insira um nome de servidor exclusivo; por exemplo, sqlserversecondary-mjg032524.
      2. Digite o mesmo administrador e senha do servidor primário.
      3. Para Localização, selecione (EUA) Oeste dos EUA.
      4. Verifique se Permitir que os serviços do Azure acessem o servidor está selecionado.
    3. Na etapa 5 para configurar os Bancos de dados dentro do grupo, selecione o banco de dados que você criou no servidor primário; por exemplo, mySampleDatabase.
  2. Depois de concluir todas as etapas na seção Testar recuperação panejada, mantenha a página do grupo de failover aberta e use-a para o teste de failover dos clusters do WebSphere Liberty/Open Liberty mais adiante.

Configurar o cluster primário do WebSphere Liberty/Open Liberty no AKS

Nesta seção, você cria o cluster primário do WebSphere Liberty/Open Liberty no AKS usando a oferta do IBM WebSphere Liberty e do Open Liberty no Azure Kubernetes Service. O cluster secundário é restaurado do cluster primário durante o failover usando o Backup do Azure posteriormente.

Implementar o cluster primário do WebSphere Liberty/Open Liberty

Siga estas etapas para implantar o cluster primário:

  1. Abra a oferta IBM WebSphere Liberty e Open Liberty no Serviço de Kubernetes do Azure em seu navegador e selecione Criar. Você deve ver o painel Noções básicas da oferta.

  2. Siga estas etapas para preencher o painel Noções básicas:

    1. Certifique-se de que o valor mostrado em Assinatura seja o mesmo que tem as funções listadas na seção de pré-requisitos.
    2. Você deve implantar a oferta em um grupo de recursos vazio. No campo Grupo de recursos, selecione Criar novo e preencha um valor exclusivo para o grupo de recursos; por exemplo, liberty-aks-eastus-mjg032524.
    3. Em Detalhes da instância, em Região, selecione Leste dos EUA.
    4. Selecione Avançar para acessar o painel AKS.

    Captura de tela do portal do Azure que mostra o painel IBM WebSphere Liberty e Open Liberty no painel Noções Básicas do Serviço de Kubernetes do Azure.

  3. Aguarde. Você deve ver todos os campos pré-preenchidos com os padrões no painel do AKS. Selecione Avançar para acessar o painel Balanceamento de carga.

    Captura de tela do portal do Azure que mostra o painel IBM WebSphere Liberty e Open Liberty no painel AKS do Serviço de Kubernetes do Azure.

  4. Siga estas etapas para preencher o painel Balanceamento de carga:

    1. Em Conectar-se ao Gateway de Aplicativo do Azure?, selecione Sim.
    2. Deixe os padrões dos outros campos.
    3. Selecione Avançar para ir ao painel Operador e aplicativo.

    Captura de tela do portal do Azure que mostra o painel IBM WebSphere Liberty e Open Liberty no painel Balanceamento de carga do Serviço de Kubernetes do Azure.

  5. Siga estas etapas para preencher o painel Operador e aplicativo:

    1. Deixe os padrões de todos os campos.

      Observação

      Este tutorial implementa o Open Liberty Operator com o uso de padrões. Como opção, é possível implementar o WebSphere Liberty Operator selecionando Sim para Compatível com IBM?.

    2. Selecione Examinar + criar.

    3. Aguarde até que Execução da validação final... seja concluída com êxito e selecione Criar.

    Captura de tela do portal do Azure que mostra o painel IBM WebSphere Liberty e Open Liberty no painel Operador e aplicativo do Serviço de Kubernetes do Azure.

Depois de alguns instantes, você deverá ver a página Implantação, onde Implantação em andamento é exibido.

Observação

Se você encontrar problemas durante a Execução da validação final..., corrija-o e tente novamente.

Dependendo das condições da rede e de outras atividades na região selecionada, a implantação pode levar até 30 minutos para ser concluída. Depois disso, você deverá ver o texto Sua implantação está concluída exibido na página de implantação.

Verificar a implantação do cluster

Você implantou um cluster do AKS, uma instância do ACR (Registro de Contêiner do Azure) e um Gateway de Aplicativo do Azure na região primária. O cluster do AKS é a plataforma de computação de destino em que seu aplicativo está implantado e em execução. A instância do ACR armazena a imagem do aplicativo que o AKS extrai durante a implantação do aplicativo. O Gateway de Aplicativo do Azure atua como balanceador de carga para o aplicativo implantado no cluster do AKS.

Siga estas etapas para verificar esses componentes-chave antes de passar para a próxima etapa:

  1. Retorne à página Implantação e selecione Saídas.

  2. Copie o valor da propriedade cmdToConnectToCluster. Abra um terminal, cole o comando copiado e pressione Enter para executar. Você verá no resultado uma mensagem semelhante ao seguinte exemplo:

    Merged "cluster3984d1-admin" as current context in <your-user>\.kube\config
    
  3. Salve o comando para usá-lo para se conectar ao cluster mais tarde.

  4. Execute kubectl get pod --all-namespaces no terminal para listar todos os pods em execução no cluster do AKS. Você deverá ver uma saída semelhante ao seguinte exemplo:

    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
    
  5. Execute kubectl get secret no terminal para listar todos os segredos instalados no cluster do AKS. Você deve ver um segredo no resultado, conforme mostrado no exemplo abaixo:

    NAME           TYPE                DATA   AGE
    secret3984d1   kubernetes.io/tls   2      24m
    

    Esse é um segredo TLS que inclui certificado e dados de chave para tráfego TLS. Copie e salve o nome do segredo - por exemplo, secret3984d1, você o usará na implantação do aplicativo posteriormente.

  6. Volte para a página Saídas. Copie o valor da propriedade cmdToLoginInRegistry. No terminal, cole o comando copiado e pressione Enter para executar. Você deve ver Login bem-sucedido no resultado. Mantenha o terminal aberto e use-o para configuração adicional do cluster WebSphere Liberty/Open Liberty posteriormente.

Use as etapas a seguir para obter o nome e o nome DNS do endereço IP público do Gateway de Aplicativo do Azure. Você os utiliza para implantação de aplicativo e a configuração do Gerenciador de Tráfego do Azure posteriormente.

  1. No portal do Azure, na caixa de pesquisa, insira Grupos de recursos e selecione Grupos de recursos nos resultados da pesquisa.
  2. Selecione o nome do grupo de recursos para sua região primária; por exemplo, liberty-aks-eastus-mjg032524.
  3. Localize o recurso Endereço IP público com prefixo gwip, copie e salve seu nome.
  4. Selecione o recurso Endereço IP público e, em seguida, copie e salve o nome DNS; por exemplo, olgw3984d1.eastus.cloudapp.azure.com.

Habilitar replicações geográficas para a instância do ACR

A instância do ACR foi projetada para armazenar imagens de aplicativos para clusters primários e secundários. Siga estas etapas para habilitar replicações geográficas para a instância do ACR:

  1. No portal do Azure, na caixa de pesquisa, insira Grupos de recursos e selecione Grupos de recursos nos resultados da pesquisa.

  2. Selecione o nome do grupo de recursos para sua região primária; por exemplo, liberty-aks-eastus-mjg032524.

  3. Localize o recurso Registro de Contêiner com o prefixo acre selecione-o para abri-lo.

  4. Selecione Propriedades. Para Plano de preços, selecione Premium, depois, selecione Salvar. Aguarde a conclusão.

  5. Selecione Replicações geográficas e, em seguida, selecione Adicionar. Para Local, selecione Oeste dos EUA e, em seguida, selecione Criar. Aguarde a conclusão.

  6. Aguarde, depois selecione Atualizar. Repita a operação até ver dois locais listados e Status como Pronto.

    Captura de tela do portal do Azure que mostra a instância do ACR habilitada com replicações geográficas em regiões de pares.

Siga estas etapas para obter as credenciais de entrada do ACR. Você as usa para implantação de aplicativos posteriormente.

  1. Selecione Chaves de acesso.
  2. Copie e salve o valor de Servidor de logon, Nome de usuário e Senha.

Implantar um aplicativo de exemplo

Siga as próximas etapas para implementar e executar um aplicativo CRUD Java/Jakarta EE de amostra no cluster WebSphere Liberty/Open Liberty para teste de failover de recuperação de desastre posteriormente:

  1. Use os seguintes comandos para baixar a amostra:

    git clone https://github.com/Azure-Samples/open-liberty-on-aks.git
    cd open-liberty-on-aks
    export BASE_DIR=$PWD
    git checkout 20240325
    

    O aplicativo configura uma fonte de dados jdbc/JavaEECafeDB, que se conecta ao Banco de Dados SQL do Azure implantado anteriormente. A fonte de dados é usada para armazenar dados de sessão HTTP, o que permite failover e balanceamento de carga em um cluster de servidores WebSphere Liberty/Open Liberty. O aplicativo de exemplo também configura um esquema de persistência para persistir os dados coffee do aplicativo na mesma fonte de dados. Observe que a raiz contextual do exemplo está configurada como / no arquivo server.xml.

  2. Use os seguintes comandos para definir variáveis de ambiente com os valores que você salvou 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>
    
  3. Use os seguintes comandos para compactar o aplicativo, criar a imagem do Docker, enviar a imagem por push para a instância do ACR e implantar o exemplo no cluster do 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
    
  4. Execute o comando a seguir para obter o aplicativo de exemplo que você implantou:

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

    Você deve ver um aplicativo READY na saída:

    NAME                       IMAGE                                 EXPOSED   RECONCILED   RESOURCESREADY   READY   AGE
    javaee-cafe-cluster-agic   acr3984d1.azurecr.io/javaee-cafe:v1             True         True             True    45s
    
  5. Execute o seguinte comando para obter o status dos pods criados durante a implantação:

    kubectl get pods
    

    O exemplo a seguir indica que todos os pods estão em execução. Se você não vir uma saída semelhante, aguarde um pouco e repita a operação.

    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
    
  6. Siga estas etapas para verificar se o aplicativo está sendo executado conforme o esperado:

    1. Em uma nova guia do navegador, abra o nome DNS do endereço IP público do Gateway de Aplicativo do Azure que você salvou anteriormente. Use o protocolo https; por exemplo, https://olgw3984d1.eastus.cloudapp.azure.com. Você deve ver a página de boas-vindas do aplicativo de exemplo.

    2. Crie um novo café com nome e preço - por exemplo, Café 1 com preço 10 - que persiste na tabela de dados do aplicativo e na tabela de sessão do banco de dados. A UI que você verá deve ser semelhante à seguinte captura de tela:

      Captura de tela da UI do aplicativo de exemplo.

    Se sua interface do usuário não for semelhante, solucione e resolva o problema antes de continuar.

Configure a recuperação de desastre para o cluster usando o Backup do Azure

Nesta seção, você configura a recuperação de desastre para o cluster do AKS na região primária usando o Backup do Azure.

Criar uma conta de armazenamento

O backup do AKS usa um contêiner de blob para manter os recursos de cluster do AKS. Você cria outro contêiner de blob como um local de preparo para usar durante a restauração entre regiões.

Siga estas etapas para criar uma conta de armazenamento e dois contêineres. Algumas dessas etapas direcionam você para outros guias.

  1. Entre no portal do Azure.
  2. Crie uma conta de armazenamento seguindo as etapas em Criar uma conta de armazenamento. Você não precisa seguir todas as etapas do artigo. Preencha os campos conforme mostrado no painel Noções básicas, de acordo com as seguintes etapas:
    1. Em Grupo de recursos, selecione o grupo de recursos existente em que o cluster primário está implantado; por exemplo, liberty-aks-eastus-mjg032524.
    2. Em Nome da conta de armazenamento, insira um nome exclusivo; por exemplo, storageeastusmjg032524.
    3. Em Região, selecione Leste dos EUA.
    4. Selecione Revisar + criar para aceitar as opções padrão.
    5. Prossiga para validar e criar a conta e retorne a este artigo.
  3. Crie um contêiner de armazenamento para a Extensão de Backup do AKS seguindo as etapas em Criar um contêiner de armazenamento. Este guia usa aks-backup-ext como o nome do contêiner.
  4. Crie outro contêiner de armazenamento como um local de preparo para uso durante a restauração. Este guia usa staging como o nome do contêiner.

Habilitar a extensão de backup do AKS

Antes de continuar, siga estas etapas para instalar a Extensão de Backup do AKS no cluster na região primária:

  1. Habilite os drivers e instantâneos CSI para o cluster. No comando a seguir az aks update, atualize o valor da variável RG_NAME Bash para o nome do grupo de recursos; por exemplo, liberty-aks-eastus-mjg032524 e execute no terminal Bash local.

    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
    

    Leva cerca de 5 minutos para habilitar os drivers. Veja se os comandos foram concluídos sem erros antes de continuar.

  2. Abra o grupo de recursos que tem o AKS implantado; por exemplo, liberty-aks-eastus-mjg032524. Selecione o cluster do AKS na lista de recursos.

  3. Em Configurações da página de destino do AKS, selecione Fazer backup e, em seguida, selecione Instalar extensão.

  4. Na página Instalar extensão de Backup do AKS, selecione Avançar. Selecione a conta de armazenamento storageeastusmjg032524 e o contêiner de blob aks-backup-ext criados no mesmo grupo de recursos. Selecione Avançar e, em seguida, selecione Criar. Leva aproximadamente cinco minutos para concluir esta etapa.

Fazer backup do cluster do AKS

Siga estas etapas para fazer backup do cluster do AKS:

  1. No portal do Azure, na caixa de pesquisa, pesquise Cofres de backup. Você o verá listado em Serviços. Selecione-a.

  2. Siga as etapas em Fazer backup do Serviço de Kubernetes do Azure usando o Backup do Azure para habilitar o Backup do AKS para o cluster primário. Execute as etapas até, mas não incluindo, a seção Usar ganchos durante o backup do AKS e use o restante das etapas nesta seção para fazer ajustes à medida que você avança.

  3. Quando você chegar à seção Criar um cofre de backup, siga estas etapas:

    1. Na etapa 1, em Grupo de recursos, selecione o grupo de recursos existente em que o cluster primário está implantado; por exemplo, liberty-aks-eastus-mjg032524.

    2. Em Nome do cofre de backup, insira um valor exclusivo; por exemplo, aks-backup-vault-eastus-mjg032524.

    3. Em Região, selecione Leste dos EUA.

    4. Em Redundância de Armazenamento de Backup, selecione Redundância Global.

      Captura de tela do portal do Azure que mostra o painel Noções Básicas do Cofre de Backup.

    5. Na etapa 2, em Restauração Entre Regiões, selecione Habilitar.

  4. Quando você chegar à seção Criar uma política de backup, siga estas etapas:

    1. Na etapa 3, insira um nome para a política de backup; por exemplo, aksbackuppolicy.

    2. Selecione o cofre de backup que você criou no mesmo grupo de recursos; por exemplo, aks-backup-vault-eastus-mjg032524.

    3. Na etapa 4, adicione uma regra de retenção em que Vault-standard esteja selecionado.

      Captura de tela do portal do Azure que mostra a página Criar Política de Backup com o painel Adicionar retenção aberto e a opção Vault-standard realçada.

    4. Selecione Adicionar.

  5. Na seção Configurar backups, execute as seguintes etapas:

    1. Ignore as etapas 1 a 5, que são para a instalação da extensão do AKS. Comece pela etapa 6 para o cluster do AKS na região primária.

    2. Na etapa 7, para Vault, selecione o cofre de backup que você criou no mesmo grupo de recursos; por exemplo, aks-backup-vault-eastus-mjg032524. Quando você encontrar erros de permissão, selecione Conceder Permissões para continuar. Depois de implantar a permissão, se o erro ainda aparecer, selecione Revalidar para atualizar as atribuições de função.

      Captura de tela do portal do Azure que mostra o painel Noções Básicas de Configuração de Backup com erros de permissão e com o link Conceder Permissões realçado.

    3. Na etapa 10, localize Selecionar Recursos para Backup. Em Nome da instância de backup, preencha um nome exclusivo; por exemplo, akseastusmjg032524. Para Outras opções, selecione todas as opções. Verifique se a guia Incluir Segredos está selecionado.

      Captura de tela do portal do Azure que mostra o painel Selecionar Recursos para Backup com a opção Incluir Segredos realçada.

    4. Na etapa 11, você encontra um erro de atribuição de função. Siga as etapas 12 a 14 para atenuar o erro.

      Captura de tela do portal do Azure que mostra o painel Configurar Backup com a caixa de diálogo Conceder permissões ausentes aberta.

    5. Depois de selecionar Configurar backup na etapa 15, você retorna à página Backup. Aguarde e selecione Atualizar. Repita a operação até ver se a instância de backup está listada e seu Status de proteção é Proteção configurada.

      Captura de tela do portal do Azure que mostra que a proteção da instância de backup do AKS está configurada.

Aguarde até que um backup Vault-standard aconteça

No AKS, a camada standard do cofre é a única que permite Redundância geográfica e Restauração entre regiões. Conforme declarado em Qual camada de armazenamento de backup o AKS aceita?, "Apenas um ponto de recuperação agendado por dia é movido para a camada do cofre". Você deve aguardar até que um backup Vault-standard aconteça. Um bom limite inferior depois de concluir a etapa anterior é aguardar até 24 horas antes de restaurar.

Siga estas etapas para verificar se um backup Vault-standard está disponível:

  1. Na página Backup do cluster primário do AKS, selecione a instância de backup.

  2. Aguarde e selecione Atualizar. Repita a operação até que pelo menos um ponto de restauração Operacional e Vault-standard está listado na seção PONTOS DE RESTAURAÇÃO.

    Captura de tela do portal do Azure que mostra a seção Pontos de restauração com o ponto de restauração Operacional e Vault-standard realçado.

Configurar o cluster AKS secundário

Enquanto aguarda a realização de um backup Vault-standard para o cluster primário do AKS, configure o cluster secundário do AKS para restauração posterior.

Siga as mesmas etapas na seção Implementar o cluster primário do WebSphere Liberty/Open Liberty para configurar o cluster secundário do AKS na região secundária, exceto pelas seguintes diferenças:

  1. No painel Noções básicas, execute as seguintes etapas:

    1. No campo Grupo de recursos, selecione Criar novo e preencha um valor exclusivo diferente para o grupo de recursos; por exemplo, liberty-aks-westus-mjg032524.
    2. Em Detalhes da instância, em Região, selecione Oeste dos EUA.
  2. No painel do AKS, aplique as seguintes etapas:

    1. Em Registro de Contêiner do Azure ACR, para Selecionar instância do ACR, selecione Não.

    2. Selecione a instância do ACR existente na região primária habilitada com replicações geográficas.

      Captura de tela da página Criar IBM WebSphere Liberty e Open Liberty no Serviço de Kubernetes do Azure do portal do Azure com a instância do ACR realçada.

Siga as mesmas etapas na seção Verificar a implantação do cluster para verificar a implantação na região secundária, exceto pelas seguintes diferenças:

  1. Você não precisa copiar e salvar o nome do segredo TLS. O segredo TLS é restaurado do backup do cluster primário do AKS.
  2. Use o grupo de recursos do cluster secundário; por exemplo, liberty-aks-westus-mjg032524, ao pesquisar o nome e o nome DNS do endereço IP público do Gateway de Aplicativo do Azure implantado na região secundária.

Siga as mesmas etapas na seção Criar uma conta de armazenamento para criar uma conta de armazenamento na região secundária, exceto pelas seguintes diferenças:

  1. No campo Grupo de recursos, selecione o grupo de recursos existente em que o cluster secundário está implantado; por exemplo, liberty-aks-westus-mjg032524.
  2. Em Nome da conta de armazenamento, insira um nome exclusivo; por exemplo, storagewestusmjg032524.
  3. Para Região, selecione Oeste dos EUA.

Siga as mesmas etapas na seção Habilitar a Extensão de Backup do AKS para instalar a Extensão de Backup do AKS para o cluster na região secundária, exceto pelas seguintes diferenças:

  1. Na etapa 1 para habilitar os drivers CSI e snapshots do cluster secundário, atualize o valor da variável RG_NAME Bash para o grupo de recursos na região secundária; por exemplo, liberty-aks-westus-mjg032524.
  2. Na etapa 2, selecione o cluster do AKS no grupo de recursos na região secundária; por exemplo, liberty-aks-westus-mjg032524.
  3. Na etapa 4 para instalar a Extensão de Backup do AKS para o cluster secundário, selecione a conta de armazenamento que você criou no mesmo grupo de recursos da região secundária; por exemplo, storagewestusmjg032524.

Para fins de economia, interrompa o cluster do AKS na região secundária de acordo com as etapas em Parar e iniciar um cluster do AKS (Serviço de Kubernetes do Azure). Você precisa iniciá-lo antes de restaurar o cluster posteriormente.

Configurar um Gerenciador de Tráfego do Azure

O backup Vault-standard foi mencionado na seção Aguarde até que um backup Vault-standard aconteça. Depois de ver que um backup Vault-standard está disponível, você pode criar um Gerenciador de Tráfego do Azure para distribuir o tráfego para seus aplicativos voltados para o público nas regiões globais do Azure. O ponto de extremidade primário aponta para o endereço IP público do Gateway de Aplicativo do Azure na região primária. O ponto de extremidade secundário aponta para o endereço IP público do Gateway de Aplicativo do Azure na região secundária.

Crie um perfil do Gerenciador de Tráfego do Azure seguindo as etapas em Início Rápido: Criar um perfil do Gerenciador de Tráfego usando o portal do Azure. Você só precisa das seguintes seções: Criar um perfil do Gerenciador de Tráfego e Adicionar pontos de extremidade do Gerenciador de Tráfego. Siga estas etapas ao percorrer essas seções e, em seguida, retorne a este artigo depois de criar e configurar o Gerenciador de Tráfego do Azure:

  1. Quando você chegar à seção Criar um perfil do Gerenciador de Tráfego, na etapa 2, em Criar perfil do Gerenciador de Tráfego, siga estas etapas:

    1. Em Nome, insira um nome de perfil exclusivo do Gerenciador de Tráfego; por exemplo, tmprofile-mjg032524.
    2. Para método de roteamento, selecione prioridade.
    3. Em Grupo de recursos, insira e salve o novo nome do grupo de recursos; por exemplo, myResourceGroupTM1.
  2. Quando você chegar à seção Adicionar pontos de extremidade do Gerenciador de Tráfego, execute as seguintes etapas:

    1. Depois de abrir o perfil do Gerenciador de Tráfego na etapa 2, na página Configuração, execute as seguintes etapas:
      1. Em Vida útil (TTL) do DNS, digite 10.
      2. Em Configurações do monitor de ponto de extremidade, em Protocolo, selecione https e, em Porta, digite 443.
      3. Em Configurações de failover de ponto de extremidade rápido, use os seguintes valores:
        • Para Investigação interna, selecione 10.
        • Em Número tolerado de falhas, digite 3.
        • Em Tempo limite da investigação, digite 5.
      4. Selecione Salvar. Aguarde a conclusão.
    2. Na etapa 4 para adicionar o ponto de extremidade primário myPrimaryEndpoint, execute as seguintes etapas:
      1. Para Tipo de recurso de destino, selecione Endereço IP público.
      2. Selecione a lista suspensa Escolher endereço IP público e insira o nome do endereço IP público do Gateway de Aplicativo do Azure na região Leste dos EUA que você salvou anteriormente. Você deve ver uma correspondência de entrada. Selecione-a para Endereço IP público.
    3. Na etapa 6 para adicionar um failover/ponto de extremidade secundário myFailoverEndpoint, execute as seguintes etapas:
      1. Para Tipo de recurso de destino, selecione Endereço IP público.
      2. Selecione a lista suspensa Escolher endereço IP público e insira o nome do endereço IP público do Gateway de Aplicativo do Azure na região Oeste dos EUA que você salvou anteriormente. Você deve ver uma correspondência de entrada. Selecione-a para Endereço IP público.
    4. Aguarde. Selecione Atualizar até que o Status do Monitor do ponto de extremidade myPrimaryEndpoint seja Online e o Status do Monitor do ponto de extremidade myFailoverEndpoint seja Degradado.

Em seguida, use as seguintes etapas para verificar se o aplicativo de exemplo implantado no cluster primário pode ser acessado no perfil do Gerenciador de Tráfego:

  1. Selecione Visão geral do perfil do Gerenciador de Tráfego que você criou.

  2. Verifique e copie o nome DNS do perfil do Gerenciador de Tráfego, substituindo o protocolo http por https. Por exemplo, https://tmprofile-mjg032524.trafficmanager.net.

  3. Abra a URL em uma nova guia do navegador. Você deve ver que o café que você criou anteriormente está listado na página.

  4. Crie outro café com nome e preço diferentes; por exemplo, Café 2 com preço 20 - que persiste na tabela de dados do aplicativo e na tabela de sessão do banco de dados. A UI que você verá deve ser semelhante à seguinte captura de tela:

    Captura de tela da interface do usuário do aplicativo de exemplo com o segundo café.

Se sua interface do usuário não for semelhante, solucione e resolva o problema antes de continuar. Mantenha o console aberto e use-o para o teste de failover mais tarde.

Você concluiu a configuração do perfil do Gerenciador de Tráfego. Mantenha a página aberta e use-a para monitorar a alteração de status do ponto de extremidade em um evento de failover posteriormente.

Testar o failover do primário para o secundário

Nesta seção, para testar o failover, faça o failover manual do servidor do Banco de Dados SQL do Azure e restaure o backup do cluster do AKS. Em seguida, faça um failback usando o portal do Azure.

Failover para o site secundário

Para simular uma interrupção da região primária, pare o cluster primário do AKS seguindo as etapas em Parar e iniciar um cluster do AKS (Serviço de Kubernetes do Azure).

Em seguida, inicie o cluster secundário do AKS para que ele possa ser restaurado a partir do backup do cluster primário.

Observação

Se você tiver aplicativos WebSphere Liberty/Open Liberty em execução no cluster de destino de restauração, para evitar conflitos, use as etapas a seguir para limpar os aplicativos WebSphere Liberty/Open Liberty:

  • Conecte-se ao cluster de destino executando o comando para cmdToConnectToCluster que você salvou anteriormente.

  • Para aplicativos Open Liberty, execute o seguinte comando:

    kubectl delete OpenLibertyApplication --all --all-namespaces
    
  • Para aplicativos WebSphere Liberty, execute o seguinte comando:

    kubectl delete WebSphereLibertyApplication --all --all-namespaces
    

Em seguida, mude para a guia do navegador do perfil do Gerenciador de Tráfego e verifique se o Status do Monitor para os dois pontos de extremidade myPrimaryEndpoint e myFailoverEndpoint é Degradado.

Agora, siga as próximas etapas para fazer o failover do Banco de Dados SQL do Azure do servidor primário para o servidor secundário:

  1. Mude para a guia do navegador do grupo de failover do Banco de Dados SQL do Azure; por exemplo, failovergroup-mjg032524.
  2. Selecione Failover e, em seguida, selecione Sim.
  3. Aguarde a conclusão.

Em seguida, execute as seguintes etapas para restaurar o backup do cluster primário do AKS para o cluster secundário do AKS:

  1. No portal do Azure, na caixa de pesquisa, insira Centro de backup e selecione Centro de backup nos resultados da pesquisa.

  2. Em Gerenciar, selecione Instâncias de backup. Filtre o tipo de fonte de dados Serviços do Kubernetes. Localize a instância de backup que você criou na seção anterior; por exemplo, <aks-cluster-name>\akseastusmjg032524.

  3. Selecione a instância de backup.

  4. Selecione Restaurar.

  5. Na página Restaurar, o painel padrão é Ponto de restauração. Selecione Anterior para alterar para o painel Noções básicas. Para Região de Restauração, selecione Região Secundária e, em seguida, selecione Avançar: Ponto de restauração.

    Captura de tela do portal do Azure que mostra o painel de Noções Básicas da Restauração.

  6. No painel Ponto de restauração, o ponto de restauração mais recente Operacional e Vault-standard está selecionado. Mantenha os padrões e selecione Parâmetros Next: Restore.

    Captura de tela do portal do Azure que mostra o painel Ponto de restauração.

  7. No painel parâmetros Restore, siga estas etapas:

    1. Para Selecionar cluster de destino, selecione o cluster do AKS secundário que você criou na região Oeste dos EUA. Você encontra um problema de permissão, mostrado na captura de tela a seguir. Selecione Conceder Permissão para atenuar os erros.

    2. Em Local de Preparo de Backup, selecione a Conta de Armazenamento que você criou na região Oeste dos EUA. Você encontra um problema de permissão, mostrado na captura de tela a seguir. Selecione Atribuir funções ausentes para atenuar os erros.

      Captura de tela do portal do Azure que mostra o painel dos parâmetros Restore.

    3. Se os erros ainda ocorrerem após a conclusão das atribuições de função, selecione Revalidar para atualizar as permissões.

    4. Ao conceder permissões ausentes, quando for especificar um Escopo, aceite o valor padrão.

    5. Selecione Validar. Você deve ver a mensagem, Validation completed successfully. Caso contrário, solucione e resolva o problema antes de continuar.

  8. Selecione Próximo: Examinar + restaurar. Em seguida, selecione Restaurar. Demora cerca de 10 minutos para restaurar o cluster.

  9. Você pode monitorar o processo de restauração em Centro de backup>Monitoramento + relatórios>Trabalhos de backup, conforme mostrado na captura de tela a seguir:

    Captura de tela do portal do Azure que mostra o progresso de CrossRegionRestore.

  10. Aguarde e selecione Atualizar. Repita a operação até ver que Status aparece como Concluído.

Em seguida, execute as seguintes etapas para verificar se a restauração funciona conforme o esperado:

  1. Mude para o terminal em que você se conectou ao cluster secundário do AKS.

  2. Execute o seguinte comando para restaurar o aplicativo de exemplo do backup:

    kubectl get OpenLibertyApplication
    

    Você deve ver um aplicativo READY na saída:

    NAME                       IMAGE                                 EXPOSED   RECONCILED   RESOURCESREADY   READY   AGE
    javaee-cafe-cluster-agic   acr3984d1.azurecr.io/javaee-cafe:v1             True         True             True    3m
    
  3. Execute o seguinte comando para obter o status dos pods criados durante a implantação:

    kubectl get pods
    

    Você deve ver três pods Em execução na saída:

    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
    
  4. Mude para a guia do navegador do perfil do Gerenciador de Tráfego e atualize a página até ver que o Status do Monitor do ponto de extremidade myFailoverEndpoint é Online e o Status do Monitor do ponto de extremidade myPrimaryEndpoint é Degradado.

  5. Mude para a guia do navegador com o nome DNS do perfil do Gerenciador de Tráfego; por exemplo, https://tmprofile-mjg032524.trafficmanager.net. Atualize a página e você verá os mesmos dados persistidos na tabela de dados do aplicativo e na tabela de sessão exibida. A UI que você verá deve ser semelhante à seguinte captura de tela:

    Captura de tela da interface do usuário do aplicativo de exemplo após o failover.

    Se você não observar esse comportamento, pode ser porque o Gerenciador de Tráfego está demorando para atualizar o DNS até apontar para o site de failover. O problema também pode ser que seu navegador armazenou em cache o resultado da resolução de nomes DNS que aponta para o site com falha. Aguarde um pouco e atualize a página novamente.

    Observação

    O aplicativo configura o tempo limite da sessão como 1 hora. Dependendo de quanto tempo levou para o failover, talvez você não veja os dados da sessão exibidos na seção Novo café da interface do usuário do aplicativo de exemplo, caso ele tenha expirado mais de uma hora antes.

Proteger novamente o site de failover

Agora que a região secundária é o site de failover e está ativa, você deve protegê-la novamente com o Backup do Azure.

Primeiro, use as mesmas etapas na seção Fazer backup do cluster do AKS para fazer backup do cluster secundário do AKS, exceto pelas seguintes diferenças:

  1. Para Criar um cofre de backup, siga estas etapas:
    1. Em Grupo de recursos, selecione o grupo de recursos existente implantado na região secundária; por exemplo, liberty-aks-westus-mjg032524.
    2. Em Nome do cofre de backup, insira um valor exclusivo; por exemplo, aks-backup-vault-westus-mjg032524.
    3. Para Região, selecione Oeste dos EUA.
  2. Para Criar uma política de backup, siga estas etapas:
    1. Selecione o cofre de backup que você criou na região secundária; por exemplo, aks-backup-vault-westus-mjg032524.
  3. Siga estas etapas em Configurar backups:
    1. Selecione o cofre de backup que você criou na região secundária; por exemplo, aks-backup-vault-westus-mjg032524.
    2. Em Nome da instância de backup, preencha um nome exclusivo; por exemplo, akswestusmjg032524.

Em seguida, siga as mesmas etapas na seção Aguarde até que um backup Vault-standard aconteça para aguardar até que um backup Vault-standard do cluster secundário do AKS esteja disponível, exceto ao selecionar a instância de backup na página Backup do cluster secundário do AKS.

Fazer failback para o primário primário

Siga as mesmas etapas na seção Failover para o site secundário para fazer failback para o site primário, incluindo o servidor de banco de dados e o cluster do AKS, exceto pelas seguintes diferenças:

  1. Ao se preparar para o failback, siga estas etapas:

    1. Pare o cluster secundário do AKS para simular uma interrupção da região secundária.
    2. Inicie o cluster primário do AKS.
    3. Conecte-se ao cluster primário do AKS e limpe os aplicativos WebSphere Liberty/Open Liberty.
  2. Execute as seguintes etapas para restaurar o backup do cluster secundário do AKS para o cluster primário do AKS:

    1. Selecione a instância de backup na região secundária; por exemplo, <aks-cluster-name>\akswestusmjg032524.
    2. No painel parâmetros Restore, siga estas etapas:
      1. Em Selecionar cluster de destino, selecione o cluster do AKS primário que você criou na região Leste dos EUA.
      2. Em Local de Preparo de Backup, selecione a Conta de Armazenamento que você criou na região Leste dos EUA.
  3. Execute as seguintes etapas para verificar se a restauração funciona conforme o esperado:

    1. Mude para o terminal em que você se conectou ao cluster primário do AKS e verifique se o aplicativo foi restaurado com êxito.
    2. Mude para a guia do navegador do perfil do Gerenciador de Tráfego e atualize a página até ver que o Status do Monitor do ponto de extremidade myPrimaryEndpoint é Online e o Status do Monitor do ponto de extremidade myFailoverEndpoint é Degradado.

Limpar os recursos

Se você não for continuar usando os clusters do WebSphere Liberty/Open Liberty e outros componentes, siga estas etapas para excluir os grupos de recursos para limpar os recursos usados neste tutorial:

  1. No portal do Azure, na caixa de pesquisa, insira o nome do grupo de recursos dos servidores do Banco de Dados SQL do Azure, por exemplo, myResourceGroup, e selecione o grupo de recursos correspondente nos resultados da pesquisa.
  2. Selecione Excluir grupo de recursos.
  3. Em Inserir nome do grupo de recursos para confirmar a exclusão, insira o nome do grupo de recursos.
  4. Selecione Excluir.
  5. Repita as etapas 1 a 4 para o grupo de recursos do Gerenciador de Tráfego; por exemplo, myResourceGroupTM1.
  6. No portal do Azure, na caixa de pesquisa, insira Cofres de backup e selecione Cofres de backup nos resultados da pesquisa. Você deve ver dois cofres de backup listados; por exemplo, aks-backup-vault-eastus-mjg032524 e aks-backup-vault-westus-mjg032524. Para cada um deles, execute as seguintes etapas:
    1. Selecione para abrir o cofre de backup.
    2. Selecione Gerenciar>Propriedades>Exclusão reversível>Atualizar. Ao lado de Habilitar Exclusão Reversível, desmarque a caixa de seleção e selecione Atualizar.
    3. Selecione Gerenciar>Instâncias de backup. Filtre o tipo de fonte de dados Serviços do Kubernetes. Selecione a instância que você criou e exclua-a.
  7. Aguarde até que as duas instâncias de backup sejam excluídas.
  8. Repita as etapas 1 a 4 para o grupo de recursos do cluster primário; por exemplo, liberty-aks-eastus-mjg032524.
  9. Repita as etapas 1 a 4 para o grupo de recursos do cluster secundário; por exemplo, liberty-aks-westus-mjg032524.

Próximas etapas

Neste tutorial, você configura uma solução WebSphere Liberty/Open Liberty HA/DR que consiste em uma camada de infraestrutura de aplicativo ativa-passiva com uma camada de banco de dados ativa-passiva em que as duas camadas abrangem dois sites geograficamente diferentes. No primeiro site, a camada de infraestrutura de aplicativo e a camada de banco de dados estão ativas. No segundo site, o domínio secundário é restaurado com o Backup do Azure e o banco de dados secundário permanece em espera.

Continue a explorar as seguintes referências para ver outras opções para criar soluções de HA/DR e executar o WebSphere no Azure: