Fiabilidade nas Aplicações Azure Spring

Este artigo contém informações detalhadas sobre resiliência regional com zonas de disponibilidade e recuperação de desastres entre regiões e suporte de continuidade de negócios para o Azure Spring Apps.

Suporte à zona de disponibilidade

As zonas de disponibilidade do Azure são pelo menos três grupos fisicamente separados de datacenters em cada região do Azure. Os datacenters dentro de cada zona são equipados com infraestrutura independente de energia, resfriamento e rede. No caso de uma falha de zona local, as zonas de disponibilidade são projetadas de modo que, se uma zona for afetada, os serviços regionais, a capacidade e a alta disponibilidade sejam suportados pelas duas zonas restantes.

As falhas podem variar de falhas de software e hardware a eventos como terremotos, inundações e incêndios. A tolerância a falhas é alcançada com redundância e isolamento lógico dos serviços do Azure. Para obter informações mais detalhadas sobre zonas de disponibilidade no Azure, consulte Regiões e zonas de disponibilidade.

Os serviços habilitados para zonas de disponibilidade do Azure são projetados para fornecer o nível certo de confiabilidade e flexibilidade. Eles podem ser configurados de duas maneiras. Eles podem ser redundantes de zona, com replicação automática entre zonas, ou zonais, com instâncias fixadas a uma zona específica. Você também pode combinar essas abordagens. Para obter mais informações sobre arquitetura zonal versus arquitetura com redundância de zona, consulte Recomendações para usar zonas e regiões de disponibilidade.

O Azure Spring Apps dá suporte à redundância de zona. Quando você cria uma instância de serviço do Azure Spring Apps com redundância de zona habilitada, o Azure Spring Apps distribui automaticamente recursos fundamentais entre seções lógicas da infraestrutura subjacente do Azure. O recurso de computação subjacente distribui VMs em todas as zonas de disponibilidade para garantir a capacidade de computação. O recurso de armazenamento subjacente replica dados entre zonas de disponibilidade para mantê-los disponíveis mesmo se houver falhas no datacenter. Essa distribuição fornece um nível mais alto de disponibilidade e protege contra falhas de hardware ou eventos de manutenção planejada.

Pré-requisitos

• A redundância de zona não está disponível no plano Básico.

• O Azure Spring Apps dá suporte a zonas de disponibilidade nas seguintes regiões:

  • Leste da Austrália
  • Sul do Brasil
  • Canadá Central
  • E.U.A. Central
  • Ásia Leste
  • E.U.A. Leste
  • E.U.A. Leste 2
  • França Central
  • Alemanha Centro-Oeste
  • Europa do Norte
  • Leste do Japão
  • Coreia do Sul Central
  • Norte da África do Sul
  • E.U.A. Centro-Sul
  • Sudeste Asiático
  • Sul do Reino Unido
  • Europa Ocidental
  • E.U.A. Oeste 2
  • EUA Oeste 3

Criar uma instância do Azure Spring Apps com zonas de disponibilidade habilitadas

Você pode habilitar a redundância de zona no Azure Spring Apps usando a CLI do Azure ou o portal do Azure.

az spring create \
    --resource-group <your-resource-group-name> \
    --name <your-Azure-Spring-Apps-instance-name> \
    --location <location> \
    --zone-redundant true

Habilite seu próprio recurso com zonas de disponibilidade habilitadas

Você pode habilitar seu próprio recurso no Azure Spring Apps, como seu próprio armazenamento persistente. No entanto, você deve certificar-se de habilitar a redundância de zona para seu recurso. Para obter mais informações, consulte Como habilitar seu próprio armazenamento persistente no Azure Spring Apps.

Experiência de zoneamento

Quando uma instância de aplicativo falha porque está localizada em um nó de VM em uma zona com falha, o Azure Spring Apps cria uma nova instância de aplicativo para o aplicativo com falha em outro nó de VM em outra zona de disponibilidade. Os usuários podem experimentar uma breve interrupção durante este tempo. Nenhuma ação do usuário é necessária e a instância afetada do Azure Spring Apps será restaurada pelo serviço.

Preços

Não há nenhum custo extra associado à ativação da redundância de zona. Você só precisa pagar pelo plano Standard ou Enterprise, que é necessário para habilitar a redundância de zona.

Recuperação de desastres entre regiões e continuidade de negócios

A recuperação de desastres (DR) consiste na recuperação de eventos de alto impacto, como desastres naturais ou implantações com falha que resultam em tempo de inatividade e perda de dados. Independentemente da causa, a melhor solução para um desastre é um plano de DR bem definido e testado e um design de aplicativo que suporte ativamente a DR. Antes de começar a pensar em criar seu plano de recuperação de desastres, consulte Recomendações para projetar uma estratégia de recuperação de desastres.

Quando se trata de DR, a Microsoft usa o modelo de responsabilidade compartilhada. Em um modelo de responsabilidade compartilhada, a Microsoft garante que a infraestrutura de linha de base e os serviços da plataforma estejam disponíveis. Ao mesmo tempo, muitos serviços do Azure não replicam dados automaticamente ou recorrem de uma região com falha para replicação cruzada para outra região habilitada. Para esses serviços, você é responsável por configurar um plano de recuperação de desastres que funcione para sua carga de trabalho. A maioria dos serviços executados nas ofertas de plataforma como serviço (PaaS) do Azure fornecem recursos e orientação para dar suporte à DR e você pode usar recursos específicos do serviço para dar suporte à recuperação rápida para ajudar a desenvolver seu plano de DR.

O serviço Azure Spring Apps não fornece recuperação de desastres geográficos, mas um planejamento cuidadoso pode ajudar a protegê-lo contra períodos de inatividade.

Para garantir alta disponibilidade e proteção contra desastres, implante seus aplicativos hospedados no Azure Spring Apps em várias regiões. O Azure fornece uma lista de regiões emparelhadas para que você possa planejar suas implantações de aplicativo de acordo.

Considere os seguintes fatores-chave ao projetar sua arquitetura:

• Disponibilidade de região. Para minimizar o atraso da rede e o tempo de transmissão, escolha uma região que ofereça suporte à redundância de zona do Azure Spring Apps ou uma área geográfica próxima aos seus usuários.
• Regiões emparelhadas do Azure. Para garantir atualizações coordenadas da plataforma e esforços de recuperação priorizados, se necessário, escolha regiões emparelhadas dentro da área geográfica escolhida.
• Disponibilidade do serviço. Decida se as regiões emparelhadas devem ser quentes/quentes, quentes/quentes ou quentes/frias.

Usar o Gerenciador de Tráfego do Azure para rotear o tráfego

O Azure Traffic Manager fornece balanceamento de carga de tráfego baseado em DNS e pode distribuir o tráfego de rede entre várias regiões. Use o Gerenciador de Tráfego do Azure para direcionar os clientes para a instância de serviço do Azure Spring Apps mais próxima. Para obter o melhor desempenho e redundância, direcione todo o tráfego do aplicativo por meio do Gerenciador de Tráfego do Azure antes de enviá-lo para sua instância de serviço do Azure Spring Apps. Para obter mais informações, consulte O que é o Gerenciador de Tráfego?

Se você tiver aplicativos no Azure Spring Apps em execução em várias regiões, o Azure Traffic Manager poderá controlar o fluxo de tráfego para seus aplicativos em cada região. Defina um ponto de extremidade do Azure Traffic Manager para cada instância de serviço usando o IP da instância. Você deve se conectar a um nome DNS do Azure Traffic Manager apontando para a instância de serviço do Azure Spring Apps. O Azure Traffic Manager equilibra a carga do tráfego entre os pontos de extremidade definidos. Se um desastre atingir um data center, o Gerenciador de Tráfego do Azure direcionará o tráfego dessa região para seu par, garantindo a continuidade do serviço.

Use as seguintes etapas para criar uma instância do Azure Traffic Manager para instâncias do Azure Spring Apps:

1. Crie instâncias do Azure Spring Apps em duas regiões diferentes. Por exemplo, crie instâncias de serviço no Leste dos EUA e na Europa Ocidental, conforme mostrado na tabela a seguir. Cada instância serve como um ponto de extremidade principal e de failover para o tráfego.

   Nome do serviço	Localização	Aplicação
   serviço-amostra-a	E.U.A. Leste	gateway / auth-service / account-service
   serviço-amostra-b	Europa Ocidental	gateway / auth-service / account-service

2. Configure um domínio personalizado para as instâncias de serviço. Para obter mais informações, consulte Tutorial: Mapear um domínio personalizado existente para o Azure Spring Apps. Após a instalação bem-sucedida, ambas as instâncias de serviço serão vinculadas ao mesmo domínio personalizado, como bcdr-test.contoso.com.

3. Crie um gerenciador de tráfego e dois pontos de extremidade. Para obter instruções, consulte Guia de início rápido: criar um perfil do Gerenciador de Tráfego usando o portal do Azure, que produz o seguinte perfil do Gerenciador de Tráfego:

   • Nome DNS do Traffic Manager: http://asa-bcdr.trafficmanager.net
   • Perfis de endpoint:

   Profile	Type	Destino	Prioridade	Configurações de cabeçalho personalizadas
   Perfil do ponto de extremidade A	Ponto Final Externo	service-sample-a.azuremicroservices.io	5	host: bcdr-test.contoso.com
   Perfil do ponto final B	Ponto Final Externo	service-sample-b.azuremicroservices.io	2	host: bcdr-test.contoso.com

4. Crie um registro CNAME em uma zona DNS semelhante ao exemplo a seguir: bcdr-test.contoso.com CNAME asa-bcdr.trafficmanager.net.

O ambiente está agora criado. Se você usou os valores de exemplo nos artigos vinculados, deverá ser capaz de acessar o aplicativo usando https://bcdr-test.contoso.com.

Usar o Azure Front Door e o Azure Application Gateway para rotear o tráfego

O Azure Front Door é um ponto de entrada global e escalável que usa a rede de borda global da Microsoft para criar aplicativos Web rápidos, seguros e amplamente escaláveis. O Azure Front Door fornece a mesma redundância geográfica e roteamento para a região mais próxima que o Gerenciador de Tráfego do Azure. O Azure Front Door também fornece recursos avançados, como terminação do protocolo TLS, processamento da camada de aplicativo e Firewall de Aplicativo Web (WAF). Para obter mais informações, consulte O que é o Azure Front Door?

O diagrama a seguir mostra a arquitetura de uma instância de serviço do Azure Spring Apps integrada à rede virtual de redundância de várias regiões. O diagrama mostra a configuração correta de proxy reverso para Application Gateway e Front Door com um domínio personalizado. Essa arquitetura é baseada no cenário descrito em Expor aplicativos com TLS de ponta a ponta em uma rede virtual. Essa abordagem combina duas instâncias de injeção de rede virtual do Azure Spring Apps integradas ao Application-Gateway em uma instância com redundância geográfica.

Próximos passos

• Guia de início rápido: implantar seu primeiro aplicativo Spring Boot no Azure Spring Apps

• Fiabilidade no Azure