Editar

Cenários de alta disponibilidade e recuperação de desastre para aplicativos IaaS

Azure Site Recovery
Máquinas Virtuais do Azure
Armazenamento em Disco do Azure

Este artigo apresenta uma árvore de decisão e exemplos de opções de HA (alta disponibilidade) e DR (recuperação de desastre) ao implantar aplicativos de IaaS (infraestrutura como serviço) de várias camadas no Azure.

Arquitetura

This diagram illustrates the high availability decision tree.

Workflow

Os ASs (conjuntos de disponibilidade) fornecem redundância e disponibilidade da VM em um datacenter distribuindo as VMs entre vários nós de hardware isolados. Um subconjunto de VMs continua em execução durante o tempo de inatividade planejado ou não planejado, ou seja, todo o aplicativo permanece disponível e operacional.

As AZs (zonas de disponibilidade) são localizações físicas exclusivas que abrangem datacenters em uma região do Azure. Cada AZ acessa um ou mais datacenters que têm energia, resfriamento e rede independentes, e cada região do Azure habilitada para AZ tem, no mínimo, três AZs separadas. A separação física das AZs em uma região protege as VMs implantadas contra uma falha do datacenter.

O fluxograma de decisão reflete o princípio de que os aplicativos de HA devem usar AZs, se possível. Entre zonas e, portanto, entre datacenters, a HA fornece um SLA de > 99,99% devido à resiliência a falhas do datacenter.

Não há garantia de que os ASs e as AZs para diferentes camadas de aplicativo estejam nos mesmos datacenters. Se a latência do aplicativo for uma preocupação principal, você deverá colocar os serviços em um só datacenter usando PPGs (grupos de posicionamento por proximidade) com AZs e ASs.

Componentes

Alternativas

  • Como alternativa à DR regional com o Azure Site Recovery, se o aplicativo puder replicar os dados nativamente, você poderá implementar a DR de várias regiões usando servidores em espera ativa/passiva, como um cluster ampliado somente para DR. Essa alternativa não é especificamente detalhada nos exemplos, mas pode ser adicionada a uma das soluções. Observe que a replicação entre regiões é assíncrona e uma perda de dados é esperada.

    Como alternativa, se você tiver uma tecnologia própria de replicação de dados, use-a para criar uma zona secundária na região para DR. Dependendo da região das suas cargas de trabalho, também pode ser possível usar o Azure Site Recovery para replicar os itens em uma zona alternativa, você pode verificar a disponibilidade regional e ler mais sobre esse recurso em Habilitar a recuperação de desastre entre zonas para máquinas virtuais do Azure.

  • A HA de várias regiões é possível, mas exige um balanceador de carga global, como o Front Door ou o Gerenciador de Tráfego. Para obter mais informações, confira Executar um aplicativo de N camadas em várias regiões do Azure para alta disponibilidade.

Detalhes do cenário

As arquiteturas de várias camadas ou de N camadas são comuns em aplicativos locais tradicionais, ou seja, são uma opção natural para migrar aplicativos locais para a nuvem ou ao desenvolver aplicativos para o local e para a nuvem. As arquiteturas de N camadas normalmente são implementadas como aplicativos de IaaS divididos em camadas lógicas e camadas físicas, com uma camada superior da Web ou de apresentação, uma camada de negócios intermediária e uma camada de dados.

Em um aplicativo de IaaS de N camadas, cada camada é executada em um conjunto separado de VMs. As camadas da Web e de negócios são sem estado, o que significa que qualquer VM na camada pode processar qualquer solicitação para essa camada. A camada de dados é um armazenamento de arquivos, um armazenamento de objetos ou um banco de dados replicado. Várias VMs em cada camada fornecem resiliência em caso de falha de uma VM, e os balanceadores de carga distribuem as solicitações entre as VMs.

Você pode escalar horizontalmente as camadas adicionando mais VMs aos pools e usar conjuntos de dimensionamento de máquinas virtuais para escalar horizontalmente de modo automático as VMs idênticas. Como você usa balanceadores de carga, as camadas podem ser escaladas horizontalmente sem afetar o tempo de atividade do aplicativo.

Se o SLA (contrato de nível de serviço) de um aplicativo de IaaS exigir > 99% de disponibilidade, você poderá colocar as VMs em conjuntos de disponibilidade, zonas de disponibilidade e grupos de posicionamento por proximidade para configurar a alta disponibilidade para o aplicativo. As soluções de HA e DR escolhidas dependem do SLA, das considerações sobre latência e dos requisitos de DR regional necessários.

Possíveis casos de uso

  • Migrar um aplicativo de N camadas do local para a nuvem.
  • Implantar um aplicativo de N camadas no local e na nuvem.
  • Configurar a alta disponibilidade e a recuperação de desastre para um aplicativo de IaaS.

Essa solução pode ser usada para qualquer setor, incluindo os seguintes cenários:

  • Aplicações do setor público
  • Banca (setor financeiro)
  • Serviços de saúde

Considerações

  • As AZs não estão disponíveis em todas as regiões do Azure.

  • Decida qual opção de implantação você deseja usar antes de criar a solução. Embora seja possível, não é fácil passar de uma opção para outra após a implantação. Você precisará excluir as VMs e recriá-las com base nos discos gerenciados subjacentes, o que é um processo complexo.

  • Verifique se você pode mapear seu aplicativo na solução selecionada. Muitos padrões e designs de resiliência de camada de aplicativo estão fora do escopo desta árvore de decisão.

  • Três cenários podem levar a reinicializações de VM do Azure: manutenção não planejada de hardware, tempo de inatividade inesperado e manutenção planejada. Para obter mais informações sobre esses eventos e as melhores práticas de HA para reduzir o impacto, confira Noções básicas sobre reinicializações de VM, manutenção e tempo de inatividade.

VMs individuais

Se um aplicativo não exigir > 99,9% de disponibilidade, você não precisará configurá-lo para HA e poderá implantar VMs individuais. Você pode usar conjuntos de dimensionamento de máquinas virtuais para escalar horizontalmente de modo automático as VMs idênticas. Implante VMs individuais sem especificar uma zona, de modo que elas sejam distribuídas em toda uma região. Esses aplicativos terão um SLA de 99,9% se você usar os discos SSD Premium do Azure.

As VMs individuais usam a funcionalidade de recuperação de serviço padrão interna em todos os datacenters do Azure. Para falhas previsíveis, essa funcionalidade normalmente usa a migração dinâmica, mas, durante eventos imprevisíveis, as VMs podem ser reinicializadas ou ficar indisponíveis.

Alta disponibilidade

Se o aplicativo exigir um SLA de > 99,9%, crie o aplicativo para HA. Use AZs se possível, pois elas fornecem tolerância a falhas do datacenter. Você pode usar ASs em vez de AZs, mas o uso de ASs reduz a disponibilidade de 99,99% para 99,95%, porque os ASs não podem tolerar falhas do datacenter.

Os AZs são adequados para muitos cenários de aplicativos clusterizados, incluindo clusters de SQL do Always On, com o uso de ativo-ativo, ativo-passivo ou uma combinação dos dois níveis de HA em cada camada com failover rápido. A replicação síncrona é possível entre qualquer nó do DBMS (sistema de gerenciamento de banco de dados), devido à baixa latência da rede de zonas cruzadas. Você também pode executar uma configuração de cluster ampliado entre zonas, que tem maior latência e dá suporte à replicação assíncrona.

Se quiser usar um arbitrador de cluster baseado em VM, por exemplo, uma testemunha de compartilhamento de arquivo, coloque-o na terceira AZ, para garantir que o quorum não seja perdido se uma zona falhar. Como alternativa, talvez você possa usar uma testemunha baseada em nuvem em outra região.

Todas as VMs de uma AZ estão em um FD (domínio de falha) e um UD (domínio de atualização) único, o que significa que elas compartilham uma fonte de energia e um comutador de rede e podem ser reinicializadas ao mesmo tempo. Se você criar VMs em diferentes AZs, as VMs serão efetivamente distribuídas entre diferentes FDs e UDs, ou seja, elas não falharão nem serão reinicializadas ao mesmo tempo. Caso deseje ter VMs redundantes na zona, bem como VMs entre zonas, posicione as VMs na zona em ASs nos PPGs para garantir que elas não sejam reinicializadas ao mesmo tempo. Mesmo para cargas de trabalho de VM de instância única que não são redundantes hoje, você ainda pode usar ASs nos PPGs para permitir a flexibilidade e o crescimento futuros.

Para implantar conjuntos de dimensionamento de máquinas virtuais em AZs, considere o uso do Modo de orquestração, atualmente em versão prévia pública, que permite combinar FDs e AZs.

As AZs com PPGs na zona permitem uma das mais baixas latências de rede no Azure e um SLA de, pelo menos, 99,99% devido à resiliência de vários datacenters. Use a rede acelerada nas VMs sempre que possível.

Essa solução pode apresentar um cenário no qual um serviço em execução em uma VM de uma zona precisa interagir com um serviço de outra zona. Por exemplo, pode haver uma camada da Web ativo-ativo e uma camada de banco de dados ativo-passivo entre zonas. Algumas solicitações cruzarão as zonas, o que introduz uma latência. Embora a latência entre zonas ainda seja muito baixa, se você precisar garantir a menor latência possível, mantenha todas as comunicações de rede entre as camadas de aplicativo em uma zona.

Considerações sobre latência

A latência de rede depende, entre outras coisas, da distância física entre as VMs implantadas. Se um aplicativo exigir latência muito baixa entre camadas, você poderá implantá-lo em um só datacenter usando um PPG com ASs para cada camada. Se possível, use a rede acelerada nas VMs. Esse cenário permite uma das mais baixas latências de rede no Azure e um SLA de 99,95%.

Use as seguintes ferramentas para obter um melhor insight das condições de latência de uma variedade de cenários:

  • Para testar a latência entre VMs, confira Testar latência de rede de VMs.
  • Para testar a latência entre zonas, use o AvZone-Latency-Test. Esse teste pode ajudar você a determinar quais zonas lógicas têm a menor latência para sua assinatura.
  • Para testar a latência entre regiões do Azure, use http://www.azurespeed.com/. Essa ferramenta atualizada regularmente pode ser útil ao considerar a replicação assíncrona entre regiões.

Recuperação de desastre

As considerações sobre DR incluem a disponibilidade, a capacidade do aplicativo de continuar em execução em um estado íntegro e a durabilidade de dados, a preservação dos dados em caso de desastre.

O failover de HA deve ser rápido, sem perda de dados e ter um efeito muito limitado no serviço. Por outro lado, um failover de DR tradicional pode ter um RTO (objetivo de tempo de recuperação) e um RPO (objetivo de ponto de recuperação) mais longos associados e é assíncrono, com potencial perda de dados.

Aproveite as AZs para HA e DR usando uma AZ diferente para sua solução de DR. No entanto, o uso de uma AZ diferente não garante que os datacenters de cada AZ estarão localizados distantes fisicamente.

O Azure Site Recovery permite replicar as VMs em outra região do Azure para recuperação de desastre regional e continuidade dos negócios. Use o Azure Site Recovery para recuperar seus aplicativos em caso de interrupções da região de origem ou para realizar simulações periódicas de recuperação de desastre a fim de garantir que os requisitos de conformidade sejam atendidos.

Se o seu aplicativo der suporte ao Azure Site Recovery, você poderá fornecer uma solução de DR regional para maior proteção, caso a criticalidade do aplicativo exija isso. No entanto, a HA entre zonas e entre datacenters pode ser suficiente, pois se um aplicativo for totalmente resiliente a falhas do datacenter, não deverá haver nenhum tempo de inatividade nem perda de dados.

Otimização de custo

Não há nenhum custo adicional para as VMs implantadas em AZs. Pode haver custos adicionais de transferência de dados de VM para VM entre AZs. Para obter mais informações, confira a página de preços da largura de banda.

Colaboradores

Esse artigo é mantido pela Microsoft. Ele foi originalmente escrito pelos colaboradores a seguir.

Autor principal:

Próximas etapas