Confiabilidade nos Aplicativos Spring do Azure
Este artigo contém informações detalhadas sobre resiliência regional com zonas de disponibilidade e suporte à recuperação de desastre entre regiões e continuidade de negócios aos Aplicativos Spring do Azure.
Suporte à zona de disponibilidade
As zonas de disponibilidade são grupos de datacenters fisicamente separados em cada região do Azure. Quando uma zona falha, os serviços podem fazer failover para uma das zonas restantes.
Para obter mais informações sobre zonas de disponibilidade no Azure, consulte O que são zonas de disponibilidade?.
Os Aplicativos Spring do Azure dão suporte à redundância de zona. Quando uma instância de serviço dos Aplicativos Spring do Azure for criada com a redundância de zona habilitada, o serviço dos Aplicativos Spring do Azure distribuirá automaticamente os recursos fundamentais entre as 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 os dados entre as zonas de disponibilidade para mantê-los disponíveis mesmo que haja falhas de datacenter. Essa distribuição fornece um nível de disponibilidade superior e proteção contra uma falha de hardware ou eventos de manutenção planejada.
Pré-requisitos
A redundância de zona não está disponível no plano Básico.
Os Aplicativos Spring do Azure dão suporte às zonas de disponibilidade nas seguintes regiões:
- Leste da Austrália
- Brazil South
- Canadá Central
- Centro dos EUA
- Leste da Ásia
- Leste dos EUA
- Leste dos EUA 2
- França Central
- Centro-Oeste da Alemanha
- Norte da Europa
- Leste do Japão
- Coreia Central
- Norte da África do Sul
- Centro-Sul dos Estados Unidos
- Sudeste Asiático
- Sul do Reino Unido
- Europa Ocidental
- Oeste dos EUA 2
- Oeste dos EUA 3
Criar uma instância dos Aplicativos Spring do Azure com as zonas de disponibilidade habilitadas
Observação
Você só pode habilitar a redundância de zona ao criar uma instância de serviço dos Aplicativos Spring do Azure. Não é possível alterar a propriedade de redundância de zona após a criação.
Habilite a redundância de zona nos Aplicativos Spring do Azure usando a CLI do Azure ou o portal do Azure.
Para criar um serviço nos Aplicativos Spring do Azure com a redundância de zona habilitada usando a CLI do Azure, inclua o parâmetro --zone-redundant ao criar o serviço, como no seguinte exemplo:
az spring create \
--resource-group <your-resource-group-name> \
--name <your-Azure-Spring-Apps-instance-name> \
--location <location> \
--zone-redundant true
Habilitar seu próprio recurso com as zonas de disponibilidade habilitadas
Habilitar seu próprio recurso nos Aplicativos Spring do Azure, como seu próprio armazenamento persistente. No entanto, você deve habilitar a redundância de zona para o recurso. Para obter mais informações, configura Como habilitar seu armazenamento persistente nos Aplicativos Spring do Azure.
Experiência de zona inoperante
Quando uma instância de aplicativo falha porque está localizada em um nó de VM em uma zona com falha, os Aplicativos Spring do Azure criam uma nova instância de aplicativo para o aplicativo com falha em outro nó de VM em outra zona de disponibilidade. Os usuários poderão observar uma breve interrupção durante esse tempo. Nenhuma ação do usuário é necessária e a instância afetada dos Aplicativos Spring do Azure será restaurada pelo serviço.
Preços
Não há custos adicionais associados à habilitaçã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 desastre entre regiões e continuidade dos negócios
A DR (recuperação de desastre) trata da recuperação após eventos de alto impacto, como desastres naturais ou implantações com falha, que resultam em tempo de inatividade e perda de dados. Seja qual for a causa, a melhor solução para um desastre é um plano de DR bem definido e testado e um design de aplicativo que dê suporte ativo à DR. Antes de começar a pensar em criar seu plano de recuperação de desastre, confira Recomendações para criar uma estratégia de recuperação de desastre.
Quando o assunto é 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 de plataforma estejam disponíveis. Ao mesmo tempo, muitos serviços do Azure não replicam dados automaticamente nem retornam de uma região com falha para a replicação cruzada em 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 PaaS (plataforma como serviço) do Azure fornece recursos e diretrizes para dar suporte à DR. Além disso, você pode usar recursos específicos do serviço para dar suporte a uma recuperação rápida, a fim de ajudar a desenvolver seu plano de DR.
O serviço Aplicativos Spring do Azure não fornece recuperação de desastre geográfico, mas um planejamento cuidadoso pode ajudar você a se proteger contra o tempo de inatividade.
Para garantir alta disponibilidade e proteção contra desastres, implante seus aplicativos hospedados nos Aplicativos Spring do Azure em várias regiões. O Azure oferece uma lista de regiões emparelhadas para que você possa planejar as implantações de aplicativos corretamente.
Considere os três fatores principais ao projetar a arquitetura:
- Disponibilidade de região. Para minimizar o retardo e o tempo de transmissão da rede, escolha uma região que dê suporte à redundância de zona dos Aplicativos Spring do Azure ou uma área geográfica próxima aos usuários.
- Regiões emparelhadas do Azure. Escolha regiões emparelhadas dentro na área geográfica escolhida para garantir atualizações de plataforma coordenadas e prioridade nos esforços de recuperação, se necessário.
- Disponibilidade do serviço. Decida se suas regiões emparelhadas devem ser executadas em hot/hot, hot/warm ou hot/cold.
Usar o Gerenciador de Tráfego do Azure para rotear o tráfego
O Gerenciador de Tráfego do Azure oferece balanceamento de carga de tráfego baseado em DNS, e pode distribuir tráfego de rede em várias regiões. Use o Gerenciador de Tráfego do Azure para direcionar os clientes à instância de serviço dos Aplicativos Spring do Azure mais próxima. Para obter os melhores desempenho e redundância possíveis, direcione todo o tráfego do aplicativo por meio do Gerenciador de Tráfego do Azure antes de enviá-lo à instância de serviço dos Aplicativos Spring do Azure. Para obter mais informações, confira O que é o Gerenciador de Tráfego?
Se você tiver aplicativos nos Aplicativos Spring do Azure em execução em várias regiões, use o Gerenciador de Tráfego do Azure para controlar o fluxo de tráfego para os aplicativos em cada região. Defina um ponto de extremidade do Gerenciador de Tráfego do Azure para cada instância de serviço usando o IP do serviço. Você deve se conectar a um nome DNS do Gerenciador de Tráfego do Azure que aponte para a instância de serviço dos Aplicativos Spring do Azure. O Gerenciador de Tráfego do Azure equilibra o tráfego entre os pontos de extremidade definidos. Se um desastre ocorrer um data center, o Gerenciador de Tráfego do Azure vai direcionar o tráfego dessa região para seu par, o que garantirá a continuidade do serviço.
Use as seguintes etapas para criar uma instância do Gerenciador de Tráfego do Azure para instâncias dos Aplicativos Spring do Azure:
Crie as instâncias dos Aplicativos Spring do Azure em duas regiões diferentes. Por exemplo, crie instâncias de serviço no Leste dos EUA e na Europa Ocidental, como é mostrado na tabela a seguir. Cada instância funciona como um ponto de extremidade primário e de failover para tráfego.
Nome do serviço Location Aplicativo service-sample-a Leste dos EUA gateway / auth-service / account-service service-sample-b Europa Ocidental gateway / auth-service / account-service Configure um domínio personalizado para as instâncias de serviço. Para obter mais informações, confira Tutorial: Mapear um domínio personalizado existente para o Azure Spring Apps. Após a conclusão bem-sucedida da configuração, as duas instâncias de serviço estarão associadas ao mesmo domínio personalizado, como
bcdr-test.contoso.com.Crie um gerenciador de tráfego e dois pontos de extremidade. Para obter instruções, confira 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 do DNS do Gerenciador de Tráfego:
http://asa-bcdr.trafficmanager.net - Perfis de ponto de extremidade:
Profile Tipo Destino Prioridade Configurações personalizadas do cabeçalho Perfil do ponto de extremidade A Ponto de extremidade externo service-sample-a.azuremicroservices.io1 host: bcdr-test.contoso.comPerfil do ponto de extremidade B Ponto de extremidade externo service-sample-b.azuremicroservices.io2 host: bcdr-test.contoso.com- Nome do DNS do Gerenciador de Tráfego:
Crie um registro CNAME em uma zona DNS semelhante ao seguinte exemplo:
bcdr-test.contoso.com CNAME asa-bcdr.trafficmanager.net.
O ambiente agora está configurado. Se você usou os valores de exemplo nos artigos vinculados, poderá acessar o aplicativo usando https://bcdr-test.contoso.com.
Usar o Azure Front Door e Gateway de Aplicativo do Azure para rotear o tráfego
O Azure Front Door é um ponto de entrada global e escalonável que usa a rede de borda global da Microsoft para criar aplicativos Web rápidos, seguros e amplamente escalonáveis. O Azure Front Door fornece a mesma redundância e roteamento multigeográficos 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 de protocolo TLS, processamento de camada de aplicativo e WAF (Firewall de Aplicativo Web). Para obter mais informações, confira O que é o Azure Front Door?
O diagrama a seguir mostra a arquitetura de uma redundância de várias regiões, instância de serviço do Azure Spring Apps integrada à rede virtual. O diagrama mostra a configuração de proxy reverso correta para o Gateway de Aplicativo e o Front Door com um domínio personalizado. Essa arquitetura se baseia 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 Gateway de Aplicativo em uma instância com redundância geográfica.
