Recomendações para utilizar zonas de disponibilidade e regiões

Aplica-se a esta recomendação de lista de verificação de Fiabilidade do Azure Well-Architected Framework:

RE:05	Adicione redundância a diferentes níveis, especialmente para fluxos críticos. Aplique redundância aos escalões de computação, dados, rede e outras infraestruturas de acordo com os destinos de fiabilidade identificados.

Guias relacionados:Redundânciade design | multiregional de elevada disponibilidade

Este guia descreve as recomendações para determinar quando implementar cargas de trabalho em zonas de disponibilidade ou regiões.

Quando cria uma solução para o Azure, tem de decidir se vai implementar em várias zonas de disponibilidade numa região ou implementar em várias regiões. Esta decisão afeta a fiabilidade, o custo e o desempenho da sua solução e a capacidade da sua equipa para operar a solução. Este guia fornece informações sobre os principais requisitos empresariais que influenciam a sua decisão, as abordagens que pode considerar, as desvantagens envolvidas em cada abordagem e o efeito de cada abordagem nos pilares fundamentais do Azure Well-Architected Framework.

A decisão sobre as melhores regiões do Azure a utilizar para a sua solução é uma escolha crítica. O guia Selecionar Regiões do Azure descreve como selecionar e operar em várias regiões geográficas. A sua escolha de como utiliza regiões e zonas de disponibilidade na sua solução também afeta vários dos pilares do Well-Architected Framework:

• Fiabilidade: a sua escolha de abordagem de implementação pode ajudá-lo a mitigar vários tipos de riscos. Em geral, ao distribuir a carga de trabalho por uma área mais distribuída geograficamente, pode obter uma maior resiliência.
• Otimização de Custos: algumas abordagens arquitetónicas requerem a implementação de mais recursos do que outras, o que pode aumentar os custos dos recursos. Outras abordagens envolvem o envio de dados entre zonas ou regiões de disponibilidade geograficamente separadas, o que pode incorrer em custos de tráfego de rede. Também é importante considerar o custo contínuo da gestão dos seus recursos, que normalmente é maior quando tem requisitos empresariais abrangentes.
• Eficiência de Desempenho: as zonas de disponibilidade são ligadas em conjunto através de uma ligação de rede de alta largura de banda e de baixa latência, o que é suficiente para a maioria das cargas de trabalho permitir a replicação e comunicação síncronas entre as zonas. No entanto, se a carga de trabalho tiver sido testada e for sensível à latência de rede entre zonas, poderá ter de considerar localizar fisicamente os componentes da carga de trabalho em conjunto para minimizar a latência quando comunicam.
• Excelência Operacional: uma arquitetura complexa requer mais esforços para implementar, configurar e gerir. Além disso, para uma solução de elevada disponibilidade, poderá ter de planear como efetuar a ativação pós-falha para um conjunto secundário de recursos. A ativação pós-falha, a reativação pós-falha e o redirecionamento transparente do tráfego podem ser complexos, especialmente quando são necessários passos manuais. É uma boa prática automatizar os seus processos de implementação e gestão. Para obter mais informações, veja os guias do pilar Excelência Operacional, incluindo a Infraestrutura OE:05 como código, automatização de tarefas OE:09, design de Automatização OE:10 e práticas de implementação do OE:11.

Seja como for que crie a sua solução, aplica-se o pilar Segurança. Normalmente, as decisões sobre se e como utiliza zonas de disponibilidade e regiões não alteram a sua postura de segurança. O Azure aplica o mesmo rigor de segurança a todas as regiões e zonas de disponibilidade.

Dica

Para muitas cargas de trabalho de produção, uma implementação com redundância entre zonas fornece a melhor balança de contrapartidas. Pode expandir esta abordagem com a cópia de segurança de dados assíncrona para outra região. Se não tiver a certeza de que abordagem selecionar, comece com este tipo de implementação.

Considere outras abordagens de cargas de trabalho quando precisar dos benefícios específicos que essas abordagens proporcionam, mas tenha em atenção as desvantagens envolvidas.

Definições

Termo	Definição
Ativa-ativa	Uma arquitetura na qual várias instâncias de uma solução processam ativamente pedidos ao mesmo tempo.
Ativa-passiva	Uma arquitetura na qual uma instância de uma solução é designada como principal e processa o tráfego e uma ou mais instâncias secundárias são implementadas para servir o tráfego se o principal estiver indisponível.
Replicação assíncrona	Uma abordagem de replicação de dados na qual os dados são escritos e consolidados numa localização. Posteriormente, as alterações são replicadas para outra localização.
Zona de disponibilidade	Um grupo separado de datacenters numa região. Cada zona de disponibilidade é independente das outras, com a sua própria potência, arrefecimento e infraestrutura de rede. Muitas regiões suportam zonas de disponibilidade.
Datacenter	Uma instalação que contém servidores, equipamentos de rede e outro hardware para suportar recursos e cargas de trabalho do Azure.
Implementação localmente redundante	Um modelo de implementação no qual um recurso é implementado numa única região sem referência a uma zona de disponibilidade. Numa região que suporte zonas de disponibilidade, o recurso pode ser implementado em qualquer uma das zonas de disponibilidade da região.
Implementação em várias regiões	Um modelo de implementação no qual os recursos são implementados em várias regiões do Azure.
Regiões emparelhadas	Uma relação entre duas regiões do Azure. Algumas regiões do Azure estão ligadas a outra região definida para permitir tipos específicos de soluções de várias regiões. As regiões mais recentes do Azure não estão emparelhadas.
Region	Um perímetro geográfico que contém um conjunto de datacenters.
Arquitetura da região	A configuração específica da região do Azure, incluindo o número de zonas de disponibilidade e se a região está emparelhada com outra região.
Replicação síncrona	Uma abordagem de replicação de dados na qual os dados são escritos e consolidados em várias localizações. Cada localização tem de reconhecer a conclusão da operação de escrita antes de a operação de escrita geral ser considerada concluída.
Implementação zonal (afixada)	Um modelo de implementação no qual um recurso é implementado numa zona de disponibilidade específica.
Implementação com redundância entre zonas	Um modelo de implementação no qual um recurso é implementado em várias zonas de disponibilidade. A Microsoft gere a sincronização de dados, a distribuição de tráfego e a ativação pós-falha se uma zona sofrer uma falha.

Principais estratégias de design

O Azure tem uma grande pegada global. Uma região do Azure é um perímetro geográfico que contém um conjunto de datacenters. Tem de ter uma compreensão completa das regiões do Azure e das zonas de disponibilidade.

As regiões do Azure têm uma variedade de configurações, que também são denominadas arquiteturas de região.

Muitas regiões do Azure fornecem zonas de disponibilidade, que são grupos separados de datacenters. Dentro de uma região, as zonas de disponibilidade estão suficientemente próximas para terem ligações de baixa latência a outras zonas de disponibilidade, mas estão suficientemente distantes para reduzir a probabilidade de mais do que uma delas ser afetada por indisponibilidades locais ou condições meteorológicas. As zonas de disponibilidade têm energia, arrefecimento e infraestrutura de rede independentes. Foram concebidos para que, se uma zona sofrer uma indisponibilidade, os serviços regionais, a capacidade e a elevada disponibilidade sejam suportados pelas restantes zonas.

O diagrama seguinte mostra várias regiões do Azure de exemplo. As regiões 1 e 2 suportam zonas de disponibilidade.

Se implementar numa região do Azure que contenha zonas de disponibilidade, pode utilizar várias zonas de disponibilidade em conjunto. Ao utilizar várias zonas de disponibilidade, pode manter cópias separadas da sua aplicação e dados em datacenters físicos separados numa área metropolitana grande.

Existem duas formas de utilizar zonas de disponibilidade numa solução:

• Os recursos zonais são afixados a uma zona de disponibilidade específica. Pode combinar várias implementações zonais em diferentes zonas para cumprir os requisitos de alta fiabilidade. É responsável pela gestão da replicação de dados e pela distribuição de pedidos entre zonas. Se ocorrer uma falha numa única zona de disponibilidade, é responsável pela ativação pós-falha para outra zona de disponibilidade.
• Os recursos com redundância entre zonas estão distribuídos por várias zonas de disponibilidade. A Microsoft gere a distribuição de pedidos entre zonas e a replicação de dados entre zonas. Se ocorrer uma falha numa única zona de disponibilidade, a Microsoft gere a ativação pós-falha automaticamente.

Os serviços do Azure suportam uma ou ambas as abordagens. Normalmente, os serviços PaaS (Plataforma como serviço) suportam implementações com redundância entre zonas. Normalmente, os serviços de Infraestrutura como serviço (IaaS) suportam implementações zonais. Para obter mais informações sobre como os serviços do Azure funcionam com zonas de disponibilidade, veja Serviços do Azure com suporte de zona de disponibilidade.

Quando a Microsoft implementa atualizações em serviços, tentamos utilizar abordagens menos disruptivas para si. Por exemplo, pretendemos implementar atualizações numa única zona de disponibilidade de cada vez. Esta abordagem pode reduzir o impacto que as atualizações podem ter numa carga de trabalho ativa, uma vez que a carga de trabalho pode continuar a ser executada noutras zonas enquanto a atualização está em processo. No entanto, é da responsabilidade da equipa de carga de trabalho garantir que a carga de trabalho continua a funcionar durante as atualizações da plataforma. Por exemplo, quando utiliza conjuntos de dimensionamento de máquinas virtuais com o modo de orquestração flexível ou a maioria dos serviços PaaS do Azure, o Azure coloca os seus recursos de forma inteligente para reduzir o impacto das atualizações da plataforma. Além disso, poderá considerar o sobreaprovisionamento - implementar mais instâncias de um recurso - para que algumas instâncias permaneçam disponíveis enquanto outras instâncias são atualizadas. Para obter mais informações sobre como o Azure implementa atualizações, veja Avançar práticas de implementação seguras.

Muitas regiões também têm uma região emparelhada. As regiões emparelhadas suportam determinados tipos de abordagens de implementação de várias regiões. Algumas regiões mais recentes têm múltiplas zonas de disponibilidade e não têm uma região emparelhada. Ainda pode implementar soluções de várias regiões nestas regiões, mas as abordagens que utiliza podem ser diferentes.

Para obter mais informações sobre como o Azure utiliza regiões e zonas de disponibilidade, veja O que são regiões do Azure e zonas de disponibilidade?

Compreender as responsabilidades partilhadas

O princípio de responsabilidade partilhada descreve como as responsabilidades são divididas entre o fornecedor de cloud (Microsoft) e o utilizador. Dependendo do tipo de serviços que utiliza, poderá assumir mais ou menos responsabilidade pela operação do serviço.

A Microsoft fornece zonas de disponibilidade e regiões para lhe dar flexibilidade na forma como estrutura a sua solução para satisfazer os seus requisitos. Quando utiliza serviços geridos, a Microsoft assume mais responsabilidades de gestão dos seus recursos, que podem até incluir replicação de dados, ativação pós-falha, reativação pós-falha e outras tarefas relacionadas com a operação de um sistema distribuído.

O seu próprio código tem de recomendar práticas e padrões de conceção para lidar com falhas corretamente. Estas práticas são ainda mais importantes durante as operações de ativação pós-falha, como as que ocorrem quando ocorre uma zona de disponibilidade ou ativação pós-falha de região, porque a ativação pós-falha entre zonas ou regiões normalmente requer que a sua aplicação repita as ligações aos serviços.

Identificar os principais requisitos empresariais e de carga de trabalho

Para tomar uma decisão informada sobre como utilizar zonas de disponibilidade e regiões na sua solução, tem de compreender os seus requisitos. Estes requisitos devem ser impulsionados por discussões entre designers de soluções e intervenientes empresariais.

Tolerância ao risco

Diferentes organizações têm diferentes graus de tolerância ao risco. Mesmo dentro de uma organização, a tolerância ao risco é muitas vezes diferente para cada carga de trabalho. A maioria das cargas de trabalho não precisa de uma disponibilidade extremamente elevada. No entanto, algumas cargas de trabalho são tão importantes que até vale a pena mitigar riscos que dificilmente ocorrerão, como grandes desastres naturais que afetam uma vasta área geográfica.

Esta tabela lista alguns dos riscos comuns que deve considerar num ambiente de cloud:

Risco	Exemplos	Probabilidade
Falha de hardware	Problema com o disco rígido ou o equipamento de rede. Reinícios do anfitrião.	Elevada. Qualquer estratégia de resiliência deve ter em conta estes riscos.
Indisponibilidade do datacenter	Falha de energia, arrefecimento ou rede em todo um datacenter. Desastre natural numa parte de uma área metropolitana.	Médio
Indisponibilidade da região	Grande desastre natural que afeta uma vasta área geográfica. Problema de rede ou serviço que torna um ou mais serviços do Azure indisponíveis em toda a região.	Baixo

Seria ideal mitigar todos os riscos possíveis para cada carga de trabalho, mas não é prático ou rentável fazê-lo. É importante ter uma discussão aberta com os intervenientes empresariais para que possa tomar decisões informadas sobre os riscos que deve mitigar.

Dica

Independentemente dos destinos de fiabilidade, todas as cargas de trabalho têm de ter alguma mitigação para a recuperação após desastre. Se a carga de trabalho exigir destinos de elevada fiabilidade, as estratégias de mitigação devem ser abrangentes e deve reduzir o risco de eventos de baixa probabilidade. Para outras cargas de trabalho, tome uma decisão informada sobre os riscos que está disposto a aceitar e quais os quais precisa de mitigar.

Requisitos de resiliência

É importante compreender os requisitos de resiliência da carga de trabalho, incluindo o objetivo de tempo de recuperação (RTO) e o objetivo de ponto de recuperação (RPO). Estes objetivos ajudam-no a decidir quais as abordagens a excluir. Se não tiver requisitos claros, não pode tomar uma decisão informada sobre a abordagem a seguir. Para obter mais informações, veja Requisitos funcionais e não funcionais de destino.

Objetivos ao nível do serviço

Deve compreender o objetivo de nível de serviço (SLO) esperado da solução. Por exemplo, poderá ter um requisito empresarial de que a sua solução precisa de cumprir 99,9% de tempo de atividade.

O Azure fornece contratos de nível de serviço (SLAs) para cada serviço. Um SLA indica o nível de tempo de atividade que deve esperar do serviço e as condições que precisa de cumprir para alcançar esse SLA esperado. No entanto, lembre-se de que a forma como um SLA do Azure indica que a disponibilidade do serviço nem sempre corresponde à forma como considera o estado de funcionamento da carga de trabalho.

As suas decisões de arquitetura afetam o SLO composto da sua solução. Em geral, quanto mais redundância criar na sua solução, maior será o seu SLO. Muitos serviços do Azure fornecem SLAs mais elevados quando implementa serviços numa configuração com redundância entre zonas ou várias regiões. Reveja os SLAs para cada um dos serviços do Azure que utiliza para garantir que compreende como maximizar a resiliência e o SLA do serviço.

Residência dos dados

Algumas organizações colocam restrições nas localizações físicas nas quais os respetivos dados podem ser armazenados e processados. Por vezes, estes requisitos baseiam-se em normas legais ou regulamentares. Noutras situações, uma organização pode decidir adotar uma política de residência de dados para evitar preocupações dos clientes. Se tiver requisitos de residência de dados rigorosos, poderá ter de utilizar uma implementação de região única ou utilizar um subconjunto de regiões e serviços do Azure.

Nota

Evite fazer suposições infundadas sobre os seus requisitos de residência de dados. Se precisar de cumprir normas regulamentares específicas, verifique o que essas normas especificam.

Localização do utilizador

Ao compreender onde os seus utilizadores estão localizados, pode tomar uma decisão informada sobre como otimizar a latência e a fiabilidade das suas necessidades. O Azure fornece várias opções para suportar uma base de utilizadores dispersa geograficamente.

Se os seus utilizadores estiverem concentrados numa área, uma implementação de região única pode simplificar os seus requisitos operacionais e reduzir os custos. No entanto, tem de considerar se uma implementação de região única cumpre os seus requisitos de fiabilidade. Para aplicações críticas para a missão, deve continuar a utilizar uma implementação de várias regiões, mesmo que os seus utilizadores estejam em colocação.

Se os seus utilizadores estiverem geograficamente dispersos, poderá fazer sentido implementar a carga de trabalho em várias regiões. Os serviços do Azure fornecem diferentes capacidades para suportar uma implementação de várias regiões e pode utilizar a pegada global do Azure para melhorar a sua experiência de utilizador e aproximar as suas aplicações da sua base de utilizadores. Pode utilizar o padrão Selos de Implementação ou o padrão Geodes ou replicar os seus recursos em várias regiões.

Mesmo que os seus utilizadores estejam em áreas geográficas diferentes, considere se precisa de uma implementação de várias regiões. Considere se consegue cumprir os seus requisitos numa única região através da aceleração de tráfego global, como a aceleração fornecida pelo Azure Front Door.

Orçamento

Se operar sob um orçamento restrito, é importante considerar os custos envolvidos na implementação de componentes de carga de trabalho redundantes. Estes custos podem incluir custos de recursos adicionais, custos de rede e os custos operacionais da gestão de mais recursos e de um ambiente mais complexo.

Complexidade

É uma boa prática evitar complexidades desnecessárias na arquitetura da sua solução. Quanto mais complexidade introduzir, mais difícil se torna tomar decisões sobre a sua arquitetura. As arquiteturas complexas são mais difíceis de operar, mais difíceis de proteger e, muitas vezes, menos performantes. Siga o princípio da simplicidade.

Facilitação do Azure

Ao fornecer regiões e zonas de disponibilidade, o Azure permite-lhe selecionar uma abordagem de implementação que se adeque às suas necessidades. Existem muitas abordagens que pode escolher, cada uma das quais proporciona benefícios e incorre em custos.

Para ilustrar as abordagens de implementação que pode utilizar, considere um cenário de exemplo. Suponha que está a pensar implementar uma nova solução que inclui uma aplicação que escreve dados para algum tipo de armazenamento:

Este exemplo não é específico de nenhum serviço específico do Azure. Destina-se a fornecer um exemplo simples para ilustrar conceitos fundamentais.

Existem várias formas de implementar esta solução. Cada abordagem proporciona um conjunto diferente de benefícios e implica custos diferentes. A um nível elevado, pode considerar uma implementação localmente redundante, zonal (afixada),com redundância entre zonas ou várias regiões . Esta tabela resume algumas das preocupações dos pilares:

Pilar	Localmente redundante	Zonal (afixado)	Com redundância entre zonas	Várias regiões
Fiabilidade	Baixa fiabilidade	Depende da abordagem	Fiabilidade elevada ou muito elevada	Fiabilidade elevada ou muito elevada
Otimização de Custos	Baixo custo	Depende da abordagem	Custo moderado	Custo elevado
Eficiência de Desempenho	Desempenho aceitável (para a maioria das cargas de trabalho)	Elevado desempenho	Desempenho aceitável (para a maioria das cargas de trabalho)	Depende da abordagem
Excelência Operacional	Requisitos operacionais baixos	Requisitos operacionais elevados	Requisitos operacionais baixos	Requisitos operacionais elevados

Esta tabela resume algumas das abordagens que pode utilizar e como afetam a sua arquitetura:

Preocupação com a arquitetura	Localmente redundante	Zonal (afixado)	Com redundância entre zonas	Várias regiões
Conformidade com a residência dos dados	Alto	Alto	Alto	Depende da região
Disponibilidade regional	Todas as regiões	Regiões com zonas de disponibilidade	Regiões com zonas de disponibilidade	Depende da região

O resto deste artigo descreve cada uma das abordagens listadas na tabela anterior. A lista de abordagens não é exaustiva. Pode optar por combinar várias abordagens ou utilizar abordagens diferentes em diferentes partes da sua solução.

Abordagem de implementação 1: Implementações localmente redundantes

Se não especificar várias zonas ou regiões de disponibilidade ao implementar os seus recursos, o Azure não garante se os recursos são implementados num único datacenter ou divididos por vários datacenters na região. Em algumas situações, o Azure também pode mover o recurso entre zonas de disponibilidade.

A maioria dos recursos do Azure está altamente disponível por predefinição, com SLAs elevados e redundância incorporada num datacenter gerido pela plataforma. No entanto, do ponto de vista da fiabilidade, se alguma parte da região sofrer uma indisponibilidade, existe a possibilidade de a carga de trabalho ser afetada. Se estiver, a sua solução poderá estar indisponível ou os seus dados podem ser perdidos.

Para cargas de trabalho altamente sensíveis à latência, esta abordagem também pode resultar num desempenho mais baixo. Os componentes da carga de trabalho podem não estar colocalizados no mesmo datacenter, pelo que poderá observar alguma latência no tráfego intra-região. O Azure também pode mover de forma transparente as instâncias de serviço entre zonas de disponibilidade, o que pode afetar ligeiramente o desempenho. No entanto, esta não é uma preocupação para a maioria das cargas de trabalho.

Esta tabela resume algumas das preocupações dos pilares:

Pilar	Impacto
Fiabilidade	Baixa fiabilidade. Os serviços estão sujeitos a indisponibilidades se um datacenter falhar. No entanto, pode criar uma aplicação para ser resiliente a outros tipos de falhas.
Otimização de Custos	Custo mais baixo. Só precisa de ter uma única instância de cada recurso e não incorrer em custos de largura de banda entre zonas ou entre regiões.
Eficiência de Desempenho	Para a maioria das cargas de trabalho:desempenho aceitável. É provável que esta abordagem proporcione um desempenho satisfatório. Para cargas de trabalho altamente sensíveis à latência:baixo desempenho. Não é garantido que os componentes estejam localizados na mesma zona de disponibilidade, pelo que poderá ver um desempenho mais baixo para componentes altamente sensíveis à latência.
Excelência Operacional	Elevada eficiência operacional. Só precisa de implementar e gerir uma única instância de cada recurso.

Esta tabela resume algumas das preocupações de uma perspetiva arquitetónica:

Preocupação com a arquitetura	Impacto
Conformidade com a residência dos dados	Elevada. Quando implementa uma solução que utiliza esta abordagem, os dados são armazenados na região do Azure que selecionar.
Disponibilidade regional	Elevada. Esta abordagem pode ser utilizada em qualquer região do Azure.

Implementações localmente redundantes com cópia de segurança entre regiões

Pode expandir uma implementação localmente redundante ao realizar cópias de segurança regulares da sua infraestrutura e dados para uma região secundária. Esta abordagem adiciona uma camada adicional de proteção para mitigar uma indisponibilidade na região primária. O aspeto é o seguinte:

Ao implementar esta abordagem, tem de considerar cuidadosamente o seu RTO e RPO:

• Tempo de recuperação: se ocorrer uma falha regional, poderá ter de reconstruir a solução noutra região do Azure, o que afeta o tempo de recuperação. Considere criar a sua solução através de uma abordagem iaC (infraestrutura como código) para que possa rapidamente reimplementar noutra região se ocorrer um desastre grave. Certifique-se de que as ferramentas de implementação e os processos são tão resilientes como as aplicações, para que possa utilizá-los para reimplementar a sua solução, mesmo que haja uma falha. Planeie e ensaie os passos necessários para restaurar a sua solução novamente para um estado de trabalho.
• Ponto de recuperação: a frequência de cópia de segurança determina a quantidade de perda de dados que poderá ocorrer (o ponto de recuperação). Normalmente, pode controlar a frequência das cópias de segurança para que possa cumprir o seu RPO.

Esta tabela resume algumas das preocupações dos pilares:

Pilar	Impacto
Fiabilidade	Fiabilidade moderada. Os serviços estão sujeitos a indisponibilidades se um datacenter falhar. Os dados são cópias de segurança assíncronas para uma região separada geograficamente, o que reduz o efeito de uma indisponibilidade total da região ao minimizar a perda de dados. Numa indisponibilidade de região completa, pode restaurar manualmente as operações para outra região. No entanto, os processos de recuperação podem ser complexos e pode demorar algum tempo a restaurar manualmente para a outra região.
Otimização de Custos	Baixo custo. Normalmente, adicionar uma cópia de segurança a outra região custa apenas um pouco mais do que implementar um recurso localmente redundante.
Eficiência de Desempenho	Para a maioria das cargas de trabalho:desempenho aceitável. É provável que esta abordagem proporcione um desempenho satisfatório. Para cargas de trabalho altamente sensíveis à latência:baixo desempenho. Não é garantido que os componentes estejam localizados na mesma zona de disponibilidade, pelo que poderá ver um desempenho mais baixo para componentes altamente sensíveis à latência.
Excelência Operacional	Durante qualquer indisponibilidade numa região:baixa eficiência operacional. A ativação pós-falha é da sua responsabilidade e pode exigir operações manuais e reimplementações.

Esta tabela resume algumas das preocupações de uma perspetiva arquitetónica:

Preocupação com a arquitetura	Impacto
Conformidade com a residência dos dados	Depende da seleção da região. Os dados são armazenados principalmente na região do Azure que especificar. No entanto, tem de selecionar outra região para armazenar as suas cópias de segurança, pelo que é importante que selecione uma região compatível com os seus requisitos de residência dos dados.
Disponibilidade regional	Elevada. Pode utilizar esta abordagem em qualquer região do Azure.

Abordagem de implementação 2: implementações zonais (afixadas)

Numa implementação zonal , especifique que os seus recursos devem ser implementados numa zona de disponibilidade específica. Por vezes, esta abordagem é denominada implementação com afixação de zona .

Uma abordagem zonal reduz a latência entre os componentes. No entanto, por si só, não aumenta a resiliência da sua solução. Para aumentar a resiliência, tem de implementar várias instâncias dos seus componentes em várias zonas de disponibilidade e decidir como encaminhar o tráfego entre cada instância. Este exemplo mostra uma abordagem de encaminhamento de tráfego ativo-passivo :

No exemplo anterior, é implementado um balanceador de carga em várias zonas de disponibilidade. É importante considerar a forma como encaminha o tráfego entre instâncias em diferentes zonas de disponibilidade, uma vez que uma falha de zona também pode afetar os recursos de rede implementados nessa zona. Também pode considerar a utilização de um balanceador de carga global, como o Azure Front Door ou o Gestor de Tráfego do Azure, que não está implementado numa região.

Quando utiliza um modelo de implementação zonal, assume muitas responsabilidades:

• Tem de implementar recursos em cada zona de disponibilidade e configurar e gerir esses recursos individualmente.
• Tem de decidir como e quando replicar dados entre as zonas de disponibilidade e, em seguida, configurar e gerir a replicação.
• É responsável por distribuir os pedidos pelos recursos corretos ao utilizar, por exemplo, um balanceador de carga. Tem de garantir que o balanceador de carga cumpre os seus requisitos de resiliência. Também tem de decidir se deve utilizar um modelo de distribuição de pedidos ativo-passivo ou ativo-ativo.
• Se uma zona de disponibilidade sofrer uma indisponibilidade, terá de processar a ativação pós-falha para enviar tráfego para recursos noutra zona de disponibilidade.

Uma implementação ativa-passiva em várias zonas de disponibilidade é, por vezes, denominada DR na região ou DR do Metro.

Esta tabela resume algumas das preocupações dos pilares:

Pilar	Impacto
Fiabilidade	Quando implementado numa única zona de disponibilidade:baixa fiabilidade. Uma implementação zonal não fornece resiliência a uma falha num datacenter ou zona de disponibilidade. Tem de implementar recursos redundantes em várias zonas de disponibilidade para alcançar uma resiliência elevada. Quando implementado em várias zonas de disponibilidade:Elevada fiabilidade. Os serviços podem ser resilientes a um datacenter ou a uma indisponibilidade da zona de disponibilidade.
Otimização de Custos	Quando implementado numa única zona de disponibilidade:Baixo custo. Uma implementação de zona única requer apenas uma única instância de cada recurso. Quando implementado em várias zonas de disponibilidade:Custo elevado. Implementa várias instâncias dos recursos, cada uma das quais é faturada separadamente. Também tem de pagar o tráfego entre zonas para a replicação de dados.
Eficiência de Desempenho	Elevado desempenho. A latência pode ser muito baixa quando os componentes que servem um pedido estão localizados na mesma zona de disponibilidade.
Excelência Operacional	Baixa eficiência operacional. Tem de configurar e gerir várias instâncias do seu serviço. Tem de replicar dados entre zonas de disponibilidade. Durante uma indisponibilidade da zona de disponibilidade, a ativação pós-falha é da sua responsabilidade.

Esta tabela resume algumas das preocupações de uma perspetiva arquitetónica:

Preocupação com a arquitetura	Impacto
Conformidade com a residência dos dados	Elevada. Quando implementa uma solução que utiliza esta abordagem, os dados são armazenados na região do Azure que selecionar.
Disponibilidade regional	Regiões com zonas de disponibilidade. Esta abordagem está disponível em qualquer região que suporte zonas de disponibilidade.

Normalmente, esta abordagem é utilizada para cargas de trabalho baseadas em máquinas virtuais. Para obter uma lista completa dos serviços que suportam implementações zonais, veja Serviço de zona de disponibilidade e suporte regional.

Quando planear uma implementação zonal, verifique se os serviços do Azure que utiliza são suportados nas zonas de disponibilidade que planeia utilizar. Por exemplo, para listar que SKUs de máquina virtual estão disponíveis em cada zona de disponibilidade, veja Verificar a disponibilidade do SKU da VM.

Dica

Quando implementa um recurso numa zona de disponibilidade específica, seleciona o número da zona. A sequência de números de zona é diferente para cada subscrição do Azure. Se implementar recursos em várias subscrições do Azure, verifique os números de zona que deve utilizar em cada subscrição. Para obter mais informações, veja Zonas de disponibilidade física e lógica.

Abordagem de implementação 3: Implementações com redundância entre zonas

Quando utiliza esta abordagem, a camada da aplicação é distribuída por várias zonas de disponibilidade. Quando os pedidos chegam, um balanceador de carga incorporado no serviço (que abrange as próprias zonas de disponibilidade) dispersa os pedidos pelas instâncias em cada zona de disponibilidade. Se uma zona de disponibilidade sofrer uma indisponibilidade, o balanceador de carga direciona o tráfego para as instâncias nas zonas de disponibilidade em bom estado de funcionamento.

A camada de armazenamento também está distribuída por várias zonas de disponibilidade. As cópias dos dados da sua aplicação são distribuídas por várias zonas de disponibilidade através da replicação síncrona. Quando a aplicação efetua uma alteração aos dados, o serviço de armazenamento escreve a alteração em várias zonas de disponibilidade e a transação é considerada concluída apenas quando todas estas alterações estiverem concluídas. Este processo garante que cada zona de disponibilidade tem sempre uma cópia atualizada dos dados. Se uma zona de disponibilidade sofrer uma indisponibilidade, pode ser utilizada outra zona de disponibilidade para aceder aos mesmos dados.

Uma abordagem com redundância entre zonas aumenta a resiliência da sua solução para problemas como falhas do datacenter. Uma vez que os dados são replicados de forma síncrona, no entanto, a sua aplicação tem de aguardar que os dados sejam escritos em várias localizações separadas que possam estar em diferentes partes de uma área metropolitana. Para a maioria das aplicações, a latência envolvida na comunicação entre zonas é insignificante. No entanto, para algumas cargas de trabalho altamente sensíveis à latência, a replicação síncrona entre zonas de disponibilidade pode afetar o desempenho da aplicação.

Esta tabela resume algumas das preocupações dos pilares:

Pilar	Impacto
Fiabilidade	Elevada fiabilidade. Os serviços são resilientes a uma indisponibilidade de um datacenter ou zona de disponibilidade. Os dados são replicados de forma síncrona entre zonas de disponibilidade e sem atrasos.
Otimização de Custos	Custo moderado. Consoante os serviços que utiliza, poderá incorrer em alguns custos para escalões de serviço mais elevados para ativar a redundância entre zonas ou alguns custos de rede entre zonas.
Eficiência de Desempenho	Para a maioria das cargas de trabalho:desempenho aceitável. É provável que esta abordagem proporcione um desempenho satisfatório. Para cargas de trabalho altamente sensíveis à latência:baixo desempenho. Alguns componentes podem ser sensíveis à latência devido ao tempo de replicação de dados ou tráfego entre zonas.
Excelência Operacional	Elevada eficiência operacional. Normalmente, só precisa de gerir uma única instância lógica de cada recurso. Para a maioria dos serviços, durante uma indisponibilidade da zona de disponibilidade, a ativação pós-falha é da responsabilidade da Microsoft e ocorre automaticamente.

Esta tabela resume algumas das preocupações de uma perspetiva arquitetónica:

Preocupação com a arquitetura	Impacto
Conformidade com a residência dos dados	Elevada. Quando implementa uma solução que utiliza esta abordagem, os dados são armazenados na região do Azure que selecionar.
Disponibilidade regional	Regiões com zonas de disponibilidade. Esta abordagem está disponível em qualquer região que suporte zonas de disponibilidade.

Esta abordagem é possível com muitos serviços do Azure, incluindo Conjuntos de Dimensionamento de Máquinas Virtuais do Azure, Serviço de Aplicações do Azure, Funções do Azure, Azure Kubernetes Service, Armazenamento do Azure, SQL do Azure, Azure Service Bus e muitos outros. Para obter uma lista completa dos serviços que suportam a redundância entre zonas, veja Serviço de zona de disponibilidade e suporte regional.

Implementações com redundância entre zonas com cópia de segurança entre regiões

Pode expandir uma implementação com redundância entre zonas ao realizar cópias de segurança regulares da sua infraestrutura e dados para uma região secundária. Esta abordagem dá-lhe os benefícios de uma abordagem com redundância entre zonas e adiciona uma camada de proteção para mitigar o evento extremamente improvável de uma indisponibilidade total da região.

Ao implementar esta abordagem, tem de considerar cuidadosamente o seu RTO e RPO:

• Tempo de recuperação: se ocorrer uma falha regional, poderá ter de reconstruir a solução noutra região do Azure, o que afeta o tempo de recuperação. Considere criar a sua solução através de uma abordagem IaC para que possa reimplementar rapidamente noutra região durante um grande desastre. Certifique-se de que as ferramentas de implementação e os processos são tão resilientes como as aplicações, para que possa utilizá-los para reimplementar a sua solução, mesmo que ocorra uma falha. Planeie e ensaie os passos necessários para restaurar a sua solução novamente para um estado de trabalho.

• Ponto de recuperação: a frequência de cópia de segurança determina a quantidade de perda de dados que poderá ocorrer (o ponto de recuperação). Normalmente, pode controlar a frequência das cópias de segurança para cumprir o seu RPO.

Dica

Esta abordagem fornece frequentemente um bom equilíbrio para todas as preocupações de arquitetura. Se não tiver a certeza de que abordagem utilizar, comece com este tipo de implementação.

Esta tabela resume algumas das preocupações dos pilares:

Pilar	Impacto
Fiabilidade	Fiabilidade muito elevada. Os serviços são resilientes a uma indisponibilidade de um datacenter ou zona de disponibilidade. Para a maioria dos serviços, os dados são replicados automaticamente entre zonas e sem atrasos. É efetuada uma cópia de segurança dos dados de forma assíncrona para uma região separada geograficamente. Esta cópia de segurança reduz o efeito de uma indisponibilidade total da região ao minimizar a perda de dados. Após uma indisponibilidade total da região, pode restaurar manualmente as operações para outra região. No entanto, os processos de recuperação podem ser complexos e pode demorar algum tempo a restaurar manualmente para a outra região.
Otimização de Custos	Custo moderado. Normalmente, adicionar uma cópia de segurança a outra região custa apenas um pouco mais do que implementar a redundância entre zonas.
Eficiência de Desempenho	Para a maioria das cargas de trabalho:desempenho aceitável. É provável que esta abordagem proporcione um desempenho satisfatório. Para cargas de trabalho altamente sensíveis à latência:baixo desempenho. Alguns componentes podem ser sensíveis à latência devido ao tempo de replicação de dados ou tráfego entre zonas.
Excelência Operacional	Durante uma indisponibilidade da zona de disponibilidade:elevada eficiência operacional. A ativação pós-falha é da responsabilidade da Microsoft e ocorre automaticamente. Durante uma indisponibilidade regional:baixa eficiência operacional. A ativação pós-falha é da sua responsabilidade e pode exigir operações manuais e reimplementações.

Esta tabela resume algumas das preocupações de uma perspetiva arquitetónica:

Preocupação com a arquitetura	Impacto
Conformidade com a residência dos dados	Depende da seleção da região. Os dados são armazenados principalmente na região do Azure que especificar, mas tem de selecionar outra região para armazenar as suas cópias de segurança. Selecione uma região compatível com os seus requisitos de residência dos dados.
Disponibilidade regional	Regiões com zonas de disponibilidade. Esta abordagem está disponível em qualquer região que suporte zonas de disponibilidade.

Abordagem de implementação 4: Implementações em várias regiões

Pode utilizar várias regiões do Azure em conjunto para distribuir a sua solução por uma vasta área geográfica. Pode utilizar esta abordagem de várias regiões para melhorar a fiabilidade da sua solução ou para suportar utilizadores distribuídos geograficamente. Ao implementar em várias regiões, também reduz o risco de encontrar uma restrição temporária de capacidade de recursos numa única região. Se a residência dos dados for uma preocupação importante para a sua solução, considere cuidadosamente as regiões que utiliza para garantir que os seus dados são armazenados apenas em localizações que cumpram os seus requisitos.

Regiões ativas e passivas

As arquiteturas de várias regiões são complexas e existem várias formas de criar uma solução de várias regiões. Para algumas cargas de trabalho, faz sentido ter várias regiões a processar ativamente pedidos em simultâneo (implementações ativas-ativas). Para outras cargas de trabalho, é melhor designar uma região primária e utilizar uma ou mais regiões secundárias para ativação pós-falha (implementações ativas-passivas). Esta secção centra-se no segundo cenário em que uma região está ativa e outra é passiva. Para obter informações sobre soluções de várias regiões ativas-ativas, veja Padrão de Selos de Implementação e Padrão de Geode.

Replicação de dados

Comunicar entre regiões é muito mais lento do que comunicar dentro de uma região. Em geral, uma distância geográfica maior entre duas regiões implica mais latência de rede devido à distância física mais longa que os dados precisam de percorrer. Veja Estatísticas de latência de ida e volta da rede do Azure para obter a latência de rede esperada quando se liga entre duas regiões.

A latência de rede entre regiões pode afetar significativamente a conceção da solução, uma vez que tem de considerar cuidadosamente como a latência adicional afeta a replicação de dados e outras transações. Para muitas soluções, uma arquitetura entre regiões requer replicação assíncrona para minimizar o efeito do tráfego entre regiões no desempenho.

Replicação de dados assíncronos

Quando implementa a replicação assíncrona entre regiões, a aplicação não aguarda que todas as regiões reconheçam uma alteração. Depois de a alteração ser consolidada na região primária, a transação é considerada concluída. A alteração é replicada para as regiões secundárias mais tarde. Esta abordagem garante que a latência de ligação entre regiões não afeta diretamente o desempenho da aplicação. No entanto, devido ao atraso na replicação, uma indisponibilidade em toda a região pode resultar em alguma perda de dados. Esta perda de dados pode ocorrer porque uma região pode sofrer uma falha após a conclusão de uma escrita na região primária, mas antes de a alteração poder ser replicada para outra região.

Esta tabela resume algumas das preocupações dos pilares:

Pilar	Impacto
Fiabilidade	Elevada fiabilidade. A solução é resiliente a uma indisponibilidade de um datacenter, uma zona de disponibilidade ou uma região inteira. Os dados são replicados, mas podem não ser síncronos, pelo que é possível perder alguns dados num cenário de ativação pós-falha.
Otimização de Custos	Custo elevado. Tem de implementar recursos separados em cada região e cada recurso implica custos de implementação e manutenção. A replicação de dados entre regiões também pode incorrer em custos significativos.
Eficiência de Desempenho	Elevado desempenho. Os pedidos de aplicação não necessitam de tráfego entre regiões, pelo que o tráfego é normalmente de baixa latência.
Excelência Operacional	Baixa eficiência operacional. Tem de implementar e gerir recursos em várias regiões. Também é responsável pela ativação pós-falha entre regiões durante uma indisponibilidade regional.

Esta tabela resume algumas das preocupações de uma perspetiva arquitetónica:

Preocupação com a arquitetura	Impacto
Conformidade com a residência dos dados	Depende da seleção da região. Esta abordagem requer que selecione várias regiões para a carga de trabalho ser executada. Escolha regiões compatíveis com os requisitos de residência dos seus dados.
Disponibilidade regional	Muitas regiões do Azure estão emparelhadas. Alguns serviços do Azure utilizam regiões emparelhadas para replicar dados automaticamente. Se executar a carga de trabalho numa região que não tem um par, poderá ter de utilizar uma abordagem diferente para replicar os seus dados.

Replicação de dados síncronos

Se implementar uma solução síncrona de várias regiões, a aplicação terá de aguardar que as operações de escrita sejam concluídas em cada região do Azure antes de a transação ser considerada concluída. A latência incorrida ao aguardar operações de escrita depende da distância entre as regiões. Para muitas cargas de trabalho, a latência entre regiões pode tornar a replicação síncrona demasiado lenta para ser útil.

Esta tabela resume algumas das preocupações dos pilares:

Pilar	Impacto
Fiabilidade	Fiabilidade muito elevada. A solução é resiliente a uma indisponibilidade de um datacenter, uma zona de disponibilidade ou uma região inteira. Os dados estão sempre sincronizados entre regiões, pelo que, mesmo que ocorra uma perda total da região, os dados estão disponíveis e completos noutra região.
Otimização de Custos	Custo elevado. Tem de implementar recursos separados em cada região e cada recurso implica custos de implementação e manutenção. A replicação de dados entre regiões também pode incorrer em custos significativos.
Eficiência de Desempenho	Baixo desempenho. Os pedidos de aplicação requerem tráfego entre regiões. Dependendo da distância entre as regiões, a replicação síncrona pode adicionar latência significativa aos pedidos.
Excelência Operacional	Baixa eficiência operacional. Tem de implementar e gerir recursos em várias regiões. Também é responsável pela ativação pós-falha entre regiões durante uma indisponibilidade regional.

Esta tabela resume algumas das preocupações de uma perspetiva arquitetónica:

Preocupação com a arquitetura	Impacto
Conformidade com a residência dos dados	Depende da seleção da região. Esta abordagem requer que selecione várias regiões para a carga de trabalho ser executada. Selecione regiões compatíveis com os seus requisitos de residência dos dados.
Disponibilidade regional	Muitas regiões do Azure estão emparelhadas. Alguns serviços do Azure utilizam regiões emparelhadas para replicar dados automaticamente. Se executar a carga de trabalho numa região que não tem um par, poderá ter de utilizar uma abordagem diferente para replicar os seus dados.

Arquiteturas de região

Quando criar uma solução de várias regiões, considere se as regiões do Azure que planeia utilizar estão emparelhadas.

Pode criar uma solução de várias regiões mesmo quando as regiões não estão emparelhadas. No entanto, as abordagens que utiliza para implementar uma arquitetura de várias regiões podem ser diferentes. Por exemplo, no Armazenamento do Azure, pode utilizar o armazenamento georredundante (GRS) com regiões emparelhadas. Se o GRS não estiver disponível, considere utilizar funcionalidades como a replicação de objetos do Armazenamento do Microsoft Azure ou crie a sua aplicação para escrever em várias regiões.

Combinar abordagens de várias zonas e várias regiões

Deve combinar declarações de várias zonas e de várias regiões se os seus requisitos empresariais exigirem essa solução. Por exemplo, pode implementar componentes com redundância entre zonas em cada região e também configurar a replicação entre as regiões. Para algumas soluções, esta abordagem proporciona um grau de fiabilidade muito elevado. No entanto, a configuração deste tipo de abordagem pode ser complicada e esta abordagem pode ser dispendiosa.

Importante

As cargas de trabalho fundamentais para a missão devem utilizar várias zonas de disponibilidade e várias regiões. Para obter mais informações sobre as considerações que deve ter ao conceber cargas de trabalho fundamentais para a missão, veja Documentação da carga de trabalho Crítica para a missão.

Como os serviços do Azure suportam abordagens de implementação

É importante compreender os detalhes específicos dos serviços do Azure que utiliza. Por exemplo, alguns serviços do Azure exigem que configure a configuração da zona de disponibilidade quando implementa o recurso pela primeira vez, enquanto outros suportam a alteração da abordagem de implementação mais tarde. Da mesma forma, algumas funcionalidades de serviço podem não estar disponíveis em todas as abordagens de implementação.

Para saber mais sobre as opções e abordagens de implementação específicas a considerar para cada serviço do Azure, visite o Hub de fiabilidade.

Exemplos

Esta secção descreve alguns casos de utilização comuns e os principais requisitos que normalmente tem de considerar para cada carga de trabalho. Para cada carga de trabalho, é fornecida uma ou mais abordagens de implementação sugeridas, com base nos requisitos e abordagens descritos neste artigo.

Aplicação de linha de negócio para uma empresa

A Contoso, Ltd., é uma grande empresa fabril. A empresa está a implementar uma aplicação de linha de negócio para gerir alguns componentes dos seus processos financeiros.

Requisitos comerciais: as informações que o sistema gere são difíceis de substituir, pelo que os dados têm de ser mantidos de forma fiável. Os arquitetos dizem que o sistema precisa de incorrer no mínimo tempo de inatividade e na menor perda de dados possível. Os colaboradores da Contoso utilizam o sistema ao longo do dia de trabalho, pelo que é importante um elevado desempenho para evitar manter os membros da equipa à espera. O custo também é uma preocupação, porque a equipa financeira tem de pagar a solução.

Abordagem sugerida: a implementação com redundância entre zonas com cópia de segurança entre regiões fornece várias camadas de resiliência com elevado desempenho.

Aplicação interna

O Quarto Café é um pequeno negócio. A empresa está a desenvolver uma nova aplicação interna que os funcionários podem utilizar para submeter folhas de horas.

Requisitos comerciais: para esta carga de trabalho, a eficiência dos custos é uma das principais preocupações. A Fourth Coffee avaliou o impacto comercial do tempo de inatividade e decidiu que a aplicação não precisa de atribuir prioridades à resiliência ou ao desempenho. A empresa aceita o risco de que uma falha numa zona ou região de disponibilidade do Azure possa tornar a aplicação temporariamente indisponível.

Abordagens sugeridas:

• A implementação localmente redundante com cópias de segurança entre regiões tem o custo mais baixo, mas também tem riscos significativos.
• A implementação com redundância entre zonas com cópia de segurança entre regiões proporciona uma melhor resiliência, mas com um custo ligeiramente mais elevado.

Migração de aplicações legadas

A Fabrikam, Inc., está a migrar uma aplicação legada de um datacenter no local para o Azure. A implementação utilizará uma abordagem IaaS baseada em máquinas virtuais. A aplicação não foi concebida para um ambiente na cloud e a comunicação entre a camada da aplicação e a base de dados é muito chata.

Requisitos comerciais: o desempenho é uma prioridade para esta aplicação. A resiliência também é importante e a aplicação tem de continuar a funcionar mesmo que um datacenter do Azure tenha uma falha.

Abordagem sugerida:

• Fabrikan deve primeiro tentar uma implementação com redundância entre zonas. Devem verificar se o desempenho cumpre os seus requisitos.
• Se o desempenho da solução com redundância entre zonas não for aceitável, considere uma implementação zonal (afixada), com implementações passivas em várias zonas de disponibilidade (DR na região).

Aplicação de cuidados de saúde

A Lamna Healthcare Company está a implementar um novo sistema de registos eletrónicos de saúde no Azure.

Requisitos comerciais: devido à natureza dos dados que esta solução armazena, a residência dos dados é extremamente importante. A Lamna opera sob um quadro regulamentar rigoroso que determina que os dados devem permanecer numa localização específica.

Abordagens sugeridas:

• Implementação de várias regiões de várias zonas, se existirem várias regiões que se ajustem aos requisitos de residência dos dados da Lamna.
• Se existir apenas uma única região que se adeque às suas necessidades, considere uma implementação com redundância entre zonas ou uma implementação com redundância entre zonas com cópia de segurança entre regiões fornece uma solução de região única

Sistema da banca

O Banco Woodgrove gere as suas principais operações bancárias a partir de uma grande solução implementada no Azure.

Requisitos comerciais: este é um sistema crítico para a missão. Quaisquer indisponibilidades podem causar um grande impacto financeiro para os clientes. Como resultado, o Woodgrove Bank tem uma tolerância de risco muito baixa. O sistema precisa do nível mais elevado de fiabilidade possível e a arquitetura precisa de mitigar o risco de falhas que possam ser mitigadas.

Abordagem sugerida: para um sistema crítico para a missão, utilize uma implementação de várias regiões de várias zonas. Certifique-se de que as regiões se adequam aos requisitos de residência dos dados da empresa.

Software como serviço (SaaS)

Proseware, Inc., constrói software que é utilizado por empresas em todo o mundo. A base de utilizadores da empresa é amplamente distribuída geograficamente.

Requisitos comerciais: o Proseware tem de permitir que cada um dos seus clientes escolha uma região de implementação próxima do cliente. Ativar esta opção é importante para a latência e para os requisitos de residência dos dados dos clientes.

Abordagens sugeridas:

• Normalmente, uma implementação de várias regiões de várias zonas é uma boa opção para um fornecedor SaaS, especialmente quando é utilizada no padrão Selos de Implementação.
• Uma implementação com redundância entre zonas de região única em conjunto com uma solução global de aceleração de tráfego, como o Azure Front Door.

Ligações relacionadas

Seguem-se algumas arquiteturas de referência e cenários de exemplo para soluções de várias zonas e várias regiões:

• Aplicação Web com redundância entre zonas de linha de base altamente disponível
• Aplicação Web em várias regiões de elevada disponibilidade
• Aplicação de n camadas em várias regiões
• Aplicação Web com várias camadas criada para HA/DR

Muitos serviços do Azure fornecem orientações sobre como utilizar várias zonas de disponibilidade, incluindo os seguintes exemplos:

• Azure Site Recovery: Ativar a recuperação após desastre da VM do Azure entre zonas de disponibilidade
• Azure NetApp Files: Compreender a replicação entre zonas do Azure NetApp Files
• Redundância do Armazenamento do Azure

Lista de verificação de fiabilidade

Veja o conjunto completo de recomendações.

Lista de verificação de fiabilidade