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

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

RE:05	Adicione redundância em diferentes níveis, especialmente para fluxos críticos. Aplique redundância às camadas de computação, dados, rede e outras camadas de infraestrutura de acordo com as metas de confiabilidade identificadas.

Guias relacionados: Redundância de design | multirregional altamente disponível

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

Ao projetar uma solução para o Azure, você precisa decidir se implantará em várias zonas de disponibilidade em uma região ou se implantará em várias regiões. Essa decisão afeta a confiabilidade, o custo e o desempenho da solução e a capacidade da equipe de operá-la. Este guia fornece informações sobre os principais requisitos de negócios que influenciam sua decisão, as abordagens que você pode considerar, as compensações envolvidas em cada abordagem e o efeito de cada abordagem nos pilares principais da Estrutura de Bem-Arquitetura do Azure.

A decisão sobre as melhores regiões do Azure a serem usadas para 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. Sua escolha de como usar regiões e zonas de disponibilidade em sua solução também afeta vários dos pilares do Well-Architected Framework:

• Confiabilidade: sua escolha de abordagem de implantação pode ajudá-lo a mitigar vários tipos de riscos. Em geral, ao distribuir sua carga de trabalho por uma área mais distribuída geograficamente, você pode obter maior resiliência.
• Otimização de custos: algumas abordagens arquitetônicas exigem a implantação de mais recursos do que outras, o que pode aumentar seus custos de recursos. Outras abordagens envolvem o envio de dados entre zonas ou regiões de disponibilidade geograficamente separadas, o que pode incorrer em taxas de tráfego de rede. Também é importante considerar o custo contínuo do gerenciamento de seus recursos, que geralmente é maior quando você tem requisitos de negócios abrangentes.
• Eficiência de desempenho: as zonas de disponibilidade são conectadas entre si por meio de um link de rede de alta largura de banda e baixa latência, o que é suficiente para a maioria das cargas de trabalho permitir a replicação síncrona e a comunicação entre as zonas. No entanto, se sua carga de trabalho tiver sido testada e for sensível à latência de rede entre zonas, talvez seja necessário considerar a localização física dos componentes da carga de trabalho próximos uns dos outros para minimizar a latência quando eles se comunicam.
• Excelência operacional: uma arquitetura complexa exige mais esforço para implantar, configurar e gerenciar. Além disso, para uma solução altamente disponível, talvez seja necessário planejar como fazer failover para um conjunto secundário de recursos. Failover, failback e redirecionamento transparente do tráfego podem ser complexos, especialmente quando etapas manuais são necessárias. É uma boa prática automatizar seus processos de implantação e gerenciamento. Para obter mais informações, consulte os guias do pilar Excelência Operacional, incluindo OE:05 Infrastructure as code, OE:09 Task automation, OE:10 Automation design e OE:11 Deployment practices.

Seja qual for o design da sua solução, o pilar Segurança se aplica. Normalmente, as decisões sobre se e como você usa zonas e regiões de disponibilidade não alteram sua postura de segurança. O Azure aplica o mesmo rigor de segurança a todas as regiões e zonas de disponibilidade.

Definições

Termo	Definição
Ativo-ativo	Uma arquitetura na qual várias instâncias de uma solução processam ativamente solicitações ao mesmo tempo.
Ativo-passivo	Uma arquitetura na qual uma instância de uma solução é designada como o tráfego primário e processa e uma ou mais instâncias secundárias são implantadas para servir o tráfego se o primário não estiver disponível.
Replicação assíncrona	Uma abordagem de replicação de dados na qual os dados são gravados e confirmados em um local. Posteriormente, as alterações são replicadas para outro local.
Zona de disponibilidade	Um grupo separado de datacenters dentro de uma região. Cada zona de disponibilidade é independente das outras, com sua própria infraestrutura de energia, resfriamento e rede. Muitas regiões oferecem suporte a zonas de disponibilidade.
Datacenter	Um recurso que contém servidores, equipamentos de rede e outro hardware para dar suporte a recursos e cargas de trabalho do Azure.
Implantação localmente redundante	Um modelo de implantação no qual um recurso é implantado em uma única região sem referência a uma zona de disponibilidade. Em uma região que ofereça suporte a zonas de disponibilidade, o recurso pode ser implantado em qualquer uma das zonas de disponibilidade da região.
Implantação em várias regiões	Um modelo de implantação no qual os recursos são implantados 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 conectadas a outra região definida para habilitar tipos específicos de soluções de várias regiões. As regiões mais recentes do Azure não sã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 gravados e confirmados em vários locais. Cada local deve confirmar a conclusão da operação de gravação antes que a operação de gravação geral seja considerada concluída.
Implantação zonal (fixada)	Um modelo de implantação no qual um recurso é implantado em uma zona de disponibilidade específica.
Implantação com redundância de zona	Um modelo de implantação no qual um recurso é implantado em várias zonas de disponibilidade. A Microsoft gerencia a sincronização de dados, a distribuição de tráfego e o failover se uma zona sofrer uma interrupção.

Principais estratégias de design

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

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

Muitas regiões do Azure fornecem zonas de disponibilidade, que são grupos separados de datacenters. Nas regiões, as zonas de disponibilidade são próximas o suficiente para conexões de baixa latência com outras zonas de disponibilidade, mas distantes o suficiente para reduzir a probabilidade de que mais de uma delas seja afetada por interrupções locais ou clima. As zonas de disponibilidade têm infraestruturas independentes de energia, resfriamento e rede. Elas são projetadas para que, se uma zona sofrer uma interrupção, os serviços regionais, a capacidade e a alta disponibilidade sejam suportados pelas zonas restantes.

O diagrama a seguir mostra vários exemplos de regiões do Azure. As regiões 1 e 2 dão suporte às zonas de disponibilidade.

Se você implantar em uma região do Azure que contém zonas de disponibilidade, poderá usar várias zonas de disponibilidade juntas. Usando várias zonas de disponibilidade, você pode manter cópias separadas do seu aplicativo e dados em datacenters físicos distintos em uma área metropolitana grande.

Há duas maneiras de usar zonas de disponibilidade em uma solução:

• Os recursos zonais são fixados em uma zona de disponibilidade específica. Você pode combinar várias implantações zonais em diferentes zonas para atender aos requisitos de alta confiabilidade. Você é responsável por gerenciar a replicação de dados e distribuir as solicitações entre zonas. Se ocorrer uma interrupção em uma única zona de disponibilidade, você será responsável pelo failover para outra zona de disponibilidade.
• Os recursos com redundância de zona estão espalhados por várias zonas de disponibilidade. A Microsoft gerencia a distribuição de solicitações entre zonas e a replicação de dados entre zonas. Se ocorrer uma interrupção em uma única zona de disponibilidade, a Microsoft gerenciará o failover automaticamente.

Os serviços do Azure dão suporte a uma ou ambas as abordagens. Os serviços de PaaS (plataforma como serviço) normalmente dão suporte a implantações com redundância de zona. Os serviços de IaaS (infraestrutura como serviço) costumam dar suporte a implantações de zona. Para obter mais informações sobre como os serviços do Azure funcionam com zonas de disponibilidade, consulte Serviços do Azure com suporte a zonas de disponibilidade.

Quando a Microsoft implanta atualizações em serviços, tentamos usar abordagens que sejam as menos perturbadoras para você. Por exemplo, nosso objetivo é implantar atualizações em uma única zona de disponibilidade de cada vez. Essa abordagem pode reduzir o impacto que as atualizações podem ter em uma carga de trabalho ativa, porque a carga de trabalho pode continuar a ser executada em outras zonas enquanto a atualização está em processo. No entanto, em última análise, é responsabilidade da equipe de carga de trabalho garantir que sua carga de trabalho continue a funcionar durante as atualizações da plataforma. Por exemplo, quando você usa conjuntos de dimensionamento de máquina virtual com o modo de orquestração flexível ou a maioria dos serviços de PaaS do Azure, o Azure coloca seus recursos de forma inteligente para reduzir o impacto das atualizações de plataforma. Além disso, você pode considerar o provisionamento excessivo - implantando 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 implanta as atualizações, confira Como promover práticas de implantação segura.

Muitas regiões também têm uma região emparelhada. As regiões emparelhadas dão suporte a determinados tipos de abordagens de implantação de várias regiões. Algumas regiões mais recentes têm várias zonas de disponibilidade e não têm uma região emparelhada. Você ainda pode implantar soluções de várias regiões nessas regiões, mas as abordagens usadas podem ser diferentes.

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

Compreender as responsabilidades compartilhadas

O princípio de responsabilidade compartilhada descreve como as responsabilidades são divididas entre o provedor de nuvem (Microsoft) e você. Dependendo do tipo de serviço utilizado, você pode assumir mais ou menos responsabilidade pela operação do serviço.

A Microsoft fornece zonas de disponibilidade e regiões para oferecer flexibilidade na forma como você projeta sua solução para atender aos seus requisitos. Quando você usa os serviços gerenciados, a Microsoft assume mais responsabilidades de gerenciamento pelos seus recursos, que podem até incluir replicação de dados, failover, failback e outras tarefas relacionadas à operação de um sistema distribuído.

Seu próprio código precisa de práticas recomendadas e padrões de design para lidar com falhas normalmente. Essas práticas são ainda mais importantes durante operações de failover, como as que acontecem quando ocorre um failover de zona de disponibilidade ou região, porque o failover entre zonas ou regiões geralmente exige que seu aplicativo repita as conexões com serviços.

Identificar os principais requisitos de negócios e carga de trabalho

Para tomar uma decisão informada sobre como usar zonas e regiões de disponibilidade em sua solução, você precisa entender seus requisitos. Esses requisitos devem ser conduzidos por discussões entre designers de soluções e partes interessadas de negócios.

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 geralmente é diferente para cada carga de trabalho. A maioria das cargas de trabalho não precisa de disponibilidade extremamente alta. No entanto, algumas cargas de trabalho são tão importantes que vale até a pena mitigar riscos que são improváveis de ocorrer, como grandes desastres naturais que afetam uma ampla área geográfica.

Esta tabela lista alguns dos riscos comuns que você deve considerar em um ambiente de nuvem:

Risco	Exemplos	Probabilidade
Interrupção de hardware	Problema com o disco rígido ou equipamento de rede. Reinicializações do host.	Alto. Qualquer estratégia de resiliência deve levar em conta esses riscos.
Paralisação do datacenter	Falha de energia, resfriamento ou rede em um datacenter inteiro. Desastre natural em uma parte de uma área metropolitana.	Médio
Interrupção da região	Grande desastre natural que afeta uma ampla área geográfica. Problema de rede ou serviço que torna um ou mais serviços do Azure indisponíveis em uma região inteira.	Baixo

O ideal seria mitigar todos os riscos possíveis para cada carga de trabalho, mas não é prático ou econômico fazê-lo. É importante ter uma discussão aberta com as partes interessadas do negócio para que você possa tomar decisões informadas sobre os riscos que você deve mitigar.

Requisitos de resiliência

É importante entender os requisitos de resiliência para sua carga de trabalho, incluindo o RTO (Recovery Time Objective, objetivo de tempo de recuperação) e o RPO (Recovery Point Objective, objetivo de ponto de recuperação). Esses objetivos ajudam você a decidir quais abordagens descartar. Se você não tem requisitos claros, não pode tomar uma decisão informada sobre qual abordagem seguir. Para obter mais informações, consulte Requisitos funcionais e não funcionais de destino.

Objetivos em nível de serviço

Você deve entender o SLO (objetivo de nível de serviço) de tempo de atividade esperado da sua solução. Por exemplo, você pode ter um requisito de negócios que sua solução precisa para atender a 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 você deve esperar do serviço e as condições que você precisa atender para atingir o SLA esperado. No entanto, lembre-se de que a maneira como um SLA do Azure indica a disponibilidade do serviço nem sempre corresponde à maneira como você considera a integridade da sua carga de trabalho.

Suas decisões de arquitetura afetam o SLO composto da solução. Em geral, quanto mais redundância você criar em sua solução, maior será o SLO. Muitos serviços do Azure fornecem SLAs mais altos quando você implanta serviços em uma configuração de zona redundante ou de várias regiões. Analise os SLAs de cada um dos serviços do Azure que você usa para garantir que você entenda como maximizar a resiliência e o SLA do serviço.

Residência de dadosResidência de dados

Algumas organizações impõem restrições aos locais físicos nos quais seus dados podem ser armazenados e processados. Às vezes, esses requisitos são baseados em normas legais ou regulamentares. Em outras situações, uma organização pode decidir adotar uma política de residência de dados para evitar preocupações com os clientes. Se você tiver requisitos rígidos de residência de dados, talvez seja necessário usar uma implantação de região única ou usar um subconjunto de regiões e serviços do Azure.

Localização do usuário

Ao entender onde seus usuários estão localizados, você pode tomar uma decisão informada sobre como otimizar a latência e a confiabilidade para suas necessidades. O Azure fornece muitas opções para dar suporte a uma base de usuários geograficamente dispersa.

Se os usuários estiverem concentrados em uma área, uma implantação de região única poderá simplificar seus requisitos operacionais e reduzir seus custos. No entanto, você precisa considerar se uma implantação de região única atende aos seus requisitos de confiabilidade. Para aplicativos de missão crítica, você ainda deve usar uma implantação de várias regiões, mesmo que os usuários estejam co-localizados.

Se os usuários estiverem geograficamente dispersos, talvez faça sentido implantar sua carga de trabalho em várias regiões. Os serviços do Azure fornecem recursos diferentes para dar suporte a uma implantação de várias regiões, e você pode usar a área de cobertura global do Azure para melhorar sua experiência de usuário e aproximar seus aplicativos de sua base de usuários. Você pode usar o padrão Carimbos de Implantação ou o padrão Geodes ou replicar seus recursos em várias regiões.

Mesmo que seus usuários estejam em áreas geográficas diferentes, considere se você precisa de uma implantação de várias regiões. Considere se você pode atender aos seus requisitos em uma única região usando a aceleração de tráfego global, como a aceleração fornecida pelo Azure Front Door.

Orçamento

Se você opera com um orçamento restrito, é importante considerar os custos envolvidos na implantação de componentes de carga de trabalho redundantes. Esses custos podem incluir encargos adicionais de recursos, custos de rede e os custos operacionais de gerenciamento de mais recursos e um ambiente mais complexo.

Complexidade

É uma boa prática evitar complexidade desnecessária na arquitetura da solução. Quanto mais complexidade você introduz, mais difícil se torna tomar decisões sobre sua arquitetura. Arquiteturas complexas são mais difíceis de operar, mais difíceis de proteger e, muitas vezes, de menor desempenho. Siga o princípio da simplicidade.

Azure facilitation

Ao fornecer regiões e zonas de disponibilidade, o Azure permite que você selecione uma abordagem de implantação que atenda às suas necessidades. Existem muitas abordagens que você pode escolher, cada uma das quais oferece benefícios e incorre em custos.

Para ilustrar as abordagens de implantação que você pode usar, considere um cenário de exemplo. Suponha que você esteja pensando em implantar uma nova solução que inclua um aplicativo que grava dados em algum tipo de armazenamento:

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

Há várias maneiras de implantar essa solução. Cada abordagem oferece um conjunto diferente de benefícios e incorre em custos diferentes. Em um nível alto, você pode considerar uma implantação localmente redundante, zonal (fixada), redundante de zona ou multirregião. Este quadro resume algumas das preocupações do pilar:

Pilar	Localmente redundante	Zonal (fixado)	Com redundância de zona	Multi-região
Confiabilidade	Baixa confiabilidade	Depende da abordagem	Confiabilidade alta ou muito alta	Confiabilidade alta ou muito alta
Otimização de custos	Baixo custo	Depende da abordagem	Custo moderado	Alto custo
Eficiência de desempenho	Desempenho aceitável (para a maioria das cargas de trabalho)	Alto desempenho	Desempenho aceitável (para a maioria das cargas de trabalho)	Depende da abordagem
Excelência operacional	Baixos requisitos operacionais	Altos requisitos operacionais	Baixos requisitos operacionais	Altos requisitos operacionais

Esta tabela resume algumas das abordagens que você pode usar e como elas afetam sua arquitetura:

Preocupação arquitetônica	Localmente redundante	Zonal (fixado)	Com redundância de zona	Multi-região
Conformidade com a residência de 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 restante deste artigo descreve cada uma das abordagens listadas na tabela anterior. A lista de abordagens não é exaustiva. Você pode decidir combinar várias abordagens ou usar abordagens diferentes em diferentes partes da sua solução.

Abordagem de implantação 1: implantações localmente redundantes

Se você não especificar várias zonas ou regiões de disponibilidade ao implantar seus recursos, o Azure não dará garantias sobre se os recursos serão implantados em um único datacenter ou divididos em vários datacenters na região. Em algumas situações, o Azure também pode mover seu recurso entre zonas de disponibilidade.

A maioria dos recursos do Azure é altamente disponível por padrão, com altos SLAs e redundância interna em um datacenter gerenciado pela plataforma. No entanto, de uma perspectiva de confiabilidade, se qualquer parte da região sofrer uma interrupção, há uma chance de que sua carga de trabalho possa ser afetada. Se estiver, sua solução pode estar indisponível ou seus dados podem ser perdidos.

Para cargas de trabalho altamente sensíveis à latência, essa abordagem também pode resultar em desempenho inferior. Seus componentes de carga de trabalho podem não estar colocalizados no mesmo datacenter, portanto, você pode observar alguma latência para o tráfego intrarregional. O Azure também pode mover de forma transparente suas instâncias de serviço entre zonas de disponibilidade, o que pode afetar ligeiramente o desempenho. No entanto, essa não é uma preocupação para a maioria das cargas de trabalho.

Este quadro resume algumas das preocupações do pilar:

Pilar	Impacto
Confiabilidade	Baixa confiabilidade. Os serviços estão sujeitos a interrupções se um datacenter falhar. No entanto, você pode criar um aplicativo para ser resiliente a outros tipos de falhas.
Otimização de custos	Menor custo. Você só precisa ter uma única instância de cada recurso e não incorre em custos de largura de banda 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, portanto, você pode ver um desempenho inferior para componentes altamente sensíveis à latência.
Excelência operacional	Alta eficiência operacional. Você só precisa implantar e gerenciar uma única instância de cada recurso.

Esta tabela resume algumas das preocupações de uma perspectiva arquitetônica:

Preocupação arquitetônica	Impacto
Conformidade com a residência de dados	Alto. Quando você implanta uma solução que usa essa abordagem, os dados são armazenados na região do Azure selecionada.
Disponibilidade regional	Alto. Essa abordagem pode ser usada em qualquer região do Azure.

Implantações localmente redundantes com backup entre regiões

Você pode estender uma implantação localmente redundante executando backups regulares de sua infraestrutura e dados para uma região secundária. Essa abordagem adiciona uma camada extra de proteção para mitigar uma interrupção em sua região principal. Esta é a aparência dele:

Ao implementar essa abordagem, você precisa considerar cuidadosamente seu RTO e RPO:

• Tempo de recuperação: se ocorrer uma interrupção regional, talvez seja necessário recriar sua solução em outra região do Azure, o que afeta o tempo de recuperação. Considere criar sua solução usando uma abordagem de infraestrutura como código (IaC) para que você possa reimplantar rapidamente em outra região se ocorrer um grande desastre. Certifique-se de que suas ferramentas e processos de implantação sejam tão resilientes quanto seus aplicativos para que você possa usá-los para reimplantar sua solução mesmo se houver uma interrupção. Planeje e ensaie as etapas necessárias para restaurar sua solução de volta a um estado de funcionamento.
• Ponto de recuperação: a frequência de backup determina a quantidade de perda de dados que você pode enfrentar (seu ponto de recuperação). Normalmente, você pode controlar a frequência dos backups para que possa atender ao RPO.

Este quadro resume algumas das preocupações do pilar:

Pilar	Impacto
Confiabilidade	Confiabilidade moderada. Os serviços estão sujeitos a interrupções se um datacenter falhar. O backup dos dados é feito de forma assíncrona em uma região separada geograficamente, o que reduz o efeito de uma interrupção completa da região, minimizando a perda de dados. Em uma interrupção de região completa, você pode restaurar manualmente as operações em outra região. No entanto, os processos de recuperação podem ser complexos e pode levar tempo para restaurar manualmente na outra região.
Otimização de custos	Baixo custo. Normalmente, adicionar um backup a outra região custa apenas um pouco mais do que implantar 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, portanto, você pode ver um desempenho inferior para componentes altamente sensíveis à latência.
Excelência operacional	Durante qualquer interrupção dentro de uma região: Baixa eficiência operacional. O failover é de sua responsabilidade e pode exigir operações manuais e reimplantações.

Esta tabela resume algumas das preocupações de uma perspectiva arquitetônica:

Preocupação arquitetônica	Impacto
Conformidade com a residência de dados	Depende da seleção da região. Os dados são armazenados principalmente na região do Azure que você especificar. No entanto, você precisa selecionar outra região para armazenar seus backups, portanto, é importante que você selecione uma região que seja compatível com seus requisitos de residência de dados.
Disponibilidade regional	Alto. Você pode usar essa abordagem em qualquer região do Azure.

Abordagem de implantação 2: implantações zonais (fixadas)

Em uma implantação zonal , você especifica que seus recursos devem ser implantados em uma zona de disponibilidade específica. Essa abordagem às vezes é chamada de implantação fixada por 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 sua resiliência, você precisa implantar várias instâncias de seus componentes em várias zonas de disponibilidade e decidir como rotear o tráfego entre cada instância. Este exemplo mostra uma abordagem de roteamento de tráfego ativo-passivo :

No exemplo anterior, um balanceador de carga é implantado em várias zonas de disponibilidade. É importante considerar como rotear o tráfego entre instâncias em zonas de disponibilidade diferentes, pois uma interrupção de zona também pode afetar os recursos de rede implantados nessa zona. Você também pode considerar o uso de um balanceador de carga global, como o Azure Front Door ou o Gerenciador de Tráfego do Azure, que não é implantado em uma região.

Ao usar um modelo de implantação zonal, você assume muitas responsabilidades:

• Você precisa implantar recursos em cada zona de disponibilidade e configurar e gerenciar esses recursos individualmente.
• Você precisa decidir como e quando replicar dados entre as zonas de disponibilidade e, em seguida, configurar e gerenciar a replicação.
• Você é responsável por distribuir as solicitações para os recursos corretos, usando, por exemplo, um balanceador de carga. Você precisa garantir que o balanceador de carga atenda aos seus requisitos de resiliência. Você também precisa decidir se deseja usar um modelo de distribuição de solicitação ativo-passivo ou ativo-ativo.
• Se uma zona de disponibilidade sofrer uma interrupção, você precisará lidar com o failover para enviar tráfego para recursos em outra zona de disponibilidade.

Uma implantação ativa-passiva em várias zonas de disponibilidade às vezes é chamada de DR na região ou DR de metro.

Este quadro resume algumas das preocupações do pilar:

Pilar	Impacto
Confiabilidade	Quando implantado em uma única zona de disponibilidade: baixa confiabilidade. Uma implantação zonal não fornece resiliência a uma interrupção em um datacenter ou zona de disponibilidade. Você deve implantar recursos redundantes em várias zonas de disponibilidade para obter alta resiliência. Quando implantado em várias zonas de disponibilidade: alta confiabilidade. Os serviços podem ser resilientes a uma interrupção do datacenter ou da zona de disponibilidade.
Otimização de custos	Quando implantado em uma única zona de disponibilidade: baixo custo. Uma implantação de zona única requer apenas uma única instância de cada recurso. Quando implantado em várias zonas de disponibilidade: Alto custo. Você implanta várias instâncias dos recursos, cada uma das quais é cobrada separadamente.
Eficiência de desempenho	Alto desempenho. A latência pode ser muito baixa quando os componentes que atendem a uma solicitação estão localizados na mesma zona de disponibilidade.
Excelência operacional	Baixa eficiência operacional. Você precisa configurar e gerenciar várias instâncias do seu serviço. Você precisa replicar dados entre zonas de disponibilidade. Durante uma interrupção da zona de disponibilidade, o failover é de sua responsabilidade.

Esta tabela resume algumas das preocupações de uma perspectiva arquitetônica:

Preocupação arquitetônica	Impacto
Conformidade com a residência de dados	Alto. Quando você implanta uma solução que usa essa abordagem, os dados são armazenados na região do Azure selecionada.
Disponibilidade regional	Regiões com zonas de disponibilidade. Essa abordagem está disponível em qualquer região que ofereça suporte a zonas de disponibilidade.

Essa abordagem geralmente é usada para cargas de trabalho baseadas em máquinas virtuais. Para obter uma lista completa de serviços que oferecem suporte a implantações zonais, consulte Serviço de zona de disponibilidade e suporte regional.

Ao planejar uma implantação zonal, verifique se os serviços do Azure que você usa têm suporte nas zonas de disponibilidade que você planeja usar. Por exemplo, para listar quais SKUs de máquina virtual estão disponíveis em cada zona de disponibilidade, consulte Verificar a disponibilidade de SKUs de VM.

Abordagem de implantação 3: implantações com redundância de zona

Quando você usa essa abordagem, sua camada de aplicativo é espalhada por várias zonas de disponibilidade. Quando as solicitações chegam, um balanceador de carga integrado ao serviço (que por sua vez abrange zonas de disponibilidade) dispersa as solicitações entre as instâncias em cada zona de disponibilidade. Se uma zona de disponibilidade sofrer uma interrupção, o balanceador de carga direcionará o tráfego para instâncias nas zonas de disponibilidade íntegras.

Seu nível de armazenamento também está espalhado por várias zonas de disponibilidade. As cópias dos dados do aplicativo são distribuídas em várias zonas de disponibilidade por meio da replicação síncrona. Quando o aplicativo faz uma alteração nos dados, o serviço de armazenamento grava a alteração em várias zonas de disponibilidade e a transação é considerada concluída somente quando todas essas alterações são concluídas. Esse processo garante que cada zona de disponibilidade sempre tenha uma cópia atualizada dos dados. Se uma zona de disponibilidade sofrer uma interrupção, outra zona de disponibilidade poderá ser usada para acessar os mesmos dados.

Uma abordagem com redundância de zona aumenta a resiliência da solução a problemas como paralisações do datacenter. Como os dados são replicados de forma síncrona, no entanto, seu aplicativo precisa aguardar que os dados sejam gravados em vários locais separados que podem estar em diferentes partes de uma área metropolitana. Para a maioria dos aplicativos, 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 do aplicativo.

Este quadro resume algumas das preocupações do pilar:

Pilar	Impacto
Confiabilidade	Alta confiabilidade. Os serviços são resilientes a uma interrupção de um datacenter ou zona de disponibilidade. Os dados são replicados de forma síncrona em zonas de disponibilidade e sem atrasos.
Otimização de custos	Custo moderado. Dependendo dos serviços que você usa, você pode incorrer em alguns custos para camadas de serviço mais altas para habilitar a redundância de zona.
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 tráfego entre zonas ou ao tempo de replicação de dados.
Excelência operacional	Alta eficiência operacional. Normalmente, você precisa gerenciar apenas uma única instância lógica de cada recurso. Para a maioria dos serviços, durante uma interrupção da zona de disponibilidade, o failover é de responsabilidade da Microsoft e acontece automaticamente.

Esta tabela resume algumas das preocupações de uma perspectiva arquitetônica:

Preocupação arquitetônica	Impacto
Conformidade com a residência de dados	Alto. Quando você implanta uma solução que usa essa abordagem, os dados são armazenados na região do Azure selecionada.
Disponibilidade regional	Regiões com zonas de disponibilidade. Essa abordagem está disponível em qualquer região que ofereça suporte a zonas de disponibilidade.

Essa abordagem é possível com muitos serviços do Azure, incluindo Conjuntos de Dimensionamento de Máquina Virtual do Azure, Serviço de Aplicativo do Azure, Azure Functions, Serviço de Kubernetes do Azure, Armazenamento do Azure, SQL do Azure, Barramento de Serviço do Azure e muitos outros. Para obter uma lista completa de serviços que oferecem suporte à redundância de zona, consulte Serviço de zona de disponibilidade e suporte regional.

Implantações com redundância de zona com backup entre regiões

Você pode estender uma implantação com redundância de zona executando backups regulares de sua infraestrutura e dados para uma região secundária. Essa abordagem oferece os benefícios de uma abordagem com redundância de zona e adiciona uma camada de proteção para mitigar o evento extremamente improvável de uma interrupção completa da região.

Ao implementar essa abordagem, você precisa considerar cuidadosamente seu RTO e RPO:

• Tempo de recuperação: se ocorrer uma interrupção regional, talvez seja necessário recriar sua solução em outra região do Azure, o que afeta o tempo de recuperação. Considere criar sua solução usando uma abordagem IaC para que você possa reimplantar rapidamente em outra região durante um grande desastre. Certifique-se de que suas ferramentas e processos de implantação sejam tão resilientes quanto seus aplicativos para que você possa usá-los para reimplantar sua solução mesmo se ocorrer uma paralisação. Planeje e ensaie as etapas necessárias para restaurar sua solução de volta a um estado de funcionamento.

• Ponto de recuperação: a frequência de backup determina a quantidade de perda de dados que você pode enfrentar (seu ponto de recuperação). Normalmente, você pode controlar a frequência dos backups para atender ao RPO.

Este quadro resume algumas das preocupações do pilar:

Pilar	Impacto
Confiabilidade	Confiabilidade muito alta. Os serviços são resilientes a uma interrupção de um datacenter ou zona de disponibilidade. Para a maioria dos serviços, os dados são replicados entre zonas automaticamente e sem atrasos. O backup dos dados é feito de forma assíncrona em uma região separada geograficamente. Esse backup reduz o efeito de uma paralisação de região completa, minimizando a perda de dados. Após uma interrupção completa da região, você pode restaurar manualmente as operações em outra região. No entanto, os processos de recuperação podem ser complexos e pode levar tempo para restaurar manualmente na outra região.
Otimização de custos	Custo moderado. Normalmente, adicionar um backup a outra região custa apenas um pouco mais do que implementar redundância de zona.
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 tráfego entre zonas ou ao tempo de replicação de dados.
Excelência operacional	Durante uma interrupção de zona de disponibilidade: Alta eficiência operacional. O failover é de responsabilidade da Microsoft e acontece automaticamente. Durante uma paralisação regional: Baixa eficiência operacional. O failover é de sua responsabilidade e pode exigir operações manuais e reimplantações.

Esta tabela resume algumas das preocupações de uma perspectiva arquitetônica:

Preocupação arquitetônica	Impacto
Conformidade com a residência de dados	Depende da seleção da região. Os dados são armazenados principalmente na região do Azure especificada, mas você precisa selecionar outra região para armazenar seus backups. Selecione uma região compatível com seus requisitos de residência de dados.
Disponibilidade regional	Regiões com zonas de disponibilidade. Essa abordagem está disponível em qualquer região que ofereça suporte a zonas de disponibilidade.

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

Você pode usar várias regiões do Azure juntas para distribuir sua solução em uma ampla área geográfica. Você pode usar essa abordagem de várias regiões para melhorar a confiabilidade da sua solução ou para oferecer suporte a usuários distribuídos geograficamente. Ao implantar em várias regiões, você também reduz o risco de encontrar uma restrição temporária de capacidade de recursos em uma única região. Se a residência de dados for uma preocupação importante para sua solução, considere cuidadosamente quais regiões você usa para garantir que seus dados sejam armazenados apenas em locais que atendam às suas necessidades.

Regiões ativas e passivas

As arquiteturas de várias regiões são complexas e há muitas maneiras de projetar uma solução de várias regiões. Para algumas cargas de trabalho, faz sentido ter várias regiões processando ativamente solicitações simultaneamente (implantações ativo-ativo). Para outras cargas de trabalho, é melhor designar uma região primária e usar uma ou mais regiões secundárias para failover (implantações ativo-passivo). Esta seção se concentra no segundo cenário, no qual uma região está ativa e outra é passiva. Para obter informações sobre soluções multirregiões ativo-ativo, consulte Padrão de carimbos de implantação e Padrão de geode.

Replicação de dados

A comunicação entre regiões é muito mais lenta do que a comunicação dentro de uma região. Em geral, uma distância geográfica maior entre duas regiões incorre em mais latência de rede devido à maior distância física que os dados precisam percorrer. Consulte Estatísticas de latência de ida e volta de rede do Azure para obter a latência de rede esperada quando você se conecta entre duas regiões.

A latência de rede entre regiões pode afetar significativamente o design da solução, pois você precisa considerar cuidadosamente como a latência extra 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íncrona

Quando você implementa a replicação assíncrona entre regiões, seu aplicativo não espera que todas as regiões reconheçam uma alteração. Depois que a alteração é confirmada na região primária, a transação é considerada concluída. A alteração é replicada para as regiões secundárias posteriormente. Essa abordagem garante que a latência de conexão entre regiões não afete diretamente o desempenho do aplicativo. No entanto, devido ao atraso na replicação, uma interrupção em toda a região pode resultar em alguma perda de dados. Essa perda de dados pode ocorrer porque uma região pode enfrentar uma interrupção depois que uma gravação é concluída na região primária, mas antes que a alteração possa ser replicada para outra região.

Este quadro resume algumas das preocupações do pilar:

Pilar	Impacto
Confiabilidade	Alta confiabilidade. A solução é resiliente a uma interrupção de um datacenter, de uma zona de disponibilidade ou de uma região inteira. Os dados são replicados, mas podem não ser síncronos, portanto, alguma perda de dados é possível em um cenário de failover.
Otimização de custos	Alto custo. Você precisa implantar recursos separados em cada região, e cada recurso incorre em custos de implantação e manutenção. A replicação de dados entre regiões também pode incorrer em custos significativos.
Eficiência de desempenho	Alto desempenho. As solicitações de aplicativo não exigem tráfego entre regiões, portanto, o tráfego geralmente é de baixa latência.
Excelência operacional	Baixa eficiência operacional. Você precisa implantar e gerenciar recursos em várias regiões. Você também é responsável pelo failover entre regiões durante uma interrupção regional.

Esta tabela resume algumas das preocupações de uma perspectiva arquitetônica:

Preocupação arquitetônica	Impacto
Conformidade com a residência de dados	Depende da seleção da região. Essa abordagem requer que você selecione várias regiões para sua carga de trabalho ser executada. Escolha regiões compatíveis com seus requisitos de residência de dados.
Disponibilidade regional	Muitas regiões do Azure são emparelhadas. Alguns serviços do Azure usam regiões emparelhadas para replicar dados automaticamente. Se você executar sua carga de trabalho em uma região que não tenha um par, talvez seja necessário usar uma abordagem diferente para replicar seus dados.

Replicação de dados síncrona

Se você implementar uma solução síncrona de várias regiões, seu aplicativo precisará aguardar a conclusão das operações de gravação em cada região do Azure antes que a transação seja considerada concluída. A latência incorrida pela espera por operações de gravação 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 muito lenta para ser útil.

Este quadro resume algumas das preocupações do pilar:

Pilar	Impacto
Confiabilidade	Confiabilidade muito alta. A solução é resiliente a uma interrupção de um datacenter, de uma zona de disponibilidade ou de uma região inteira. Os dados estão sempre sincronizados entre regiões, portanto, mesmo que ocorra uma perda completa de região, seus dados estarão disponíveis e completos em outra região.
Otimização de custos	Alto custo. Você precisa implantar recursos separados em cada região, e cada recurso incorre em custos de implantaçã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. As solicitações de aplicativo exigem tráfego entre regiões. Dependendo da distância entre as regiões, a replicação síncrona pode adicionar latência significativa às solicitações.
Excelência operacional	Baixa eficiência operacional. Você precisa implantar e gerenciar recursos em várias regiões. Você também é responsável pelo failover entre regiões durante uma interrupção regional.

Esta tabela resume algumas das preocupações de uma perspectiva arquitetônica:

Preocupação arquitetônica	Impacto
Conformidade com a residência de dados	Depende da seleção da região. Essa abordagem requer que você selecione várias regiões para sua carga de trabalho ser executada. Selecione regiões compatíveis com seus requisitos de residência de dados.
Disponibilidade regional	Muitas regiões do Azure são emparelhadas. Alguns serviços do Azure usam regiões emparelhadas para replicar dados automaticamente. Se você executar sua carga de trabalho em uma região que não tenha um par, talvez seja necessário usar uma abordagem diferente para replicar seus dados.

Arquiteturas de região

Ao criar uma solução de várias regiões, considere se as regiões do Azure que você planeja usar estão emparelhadas.

Você 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 você usa para implementar uma arquitetura de várias regiões podem ser diferentes. Por exemplo, no Armazenamento do Azure, você pode usar o armazenamento com redundância geográfica (GRS) com regiões emparelhadas. Se o GRS não estiver disponível, considere usar recursos como a replicação de objeto do Armazenamento do Azure ou projetar seu aplicativo para gravar em várias regiões.

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

Você deve combinar instruções de várias zonas e várias regiões se seus requisitos de negócios exigirem essa solução. Por exemplo, você pode implantar componentes com redundância de zona em cada região e também configurar a replicação entre as regiões. Para algumas soluções, essa abordagem fornece um alto grau de confiabilidade. No entanto, configurar esse tipo de abordagem pode ser complicado, e essa abordagem pode ser cara.

Como os serviços do Azure dão suporte a abordagens de implantação

É importante entender os detalhes específicos dos serviços do Azure que você usa. Por exemplo, alguns serviços do Azure exigem que você configure sua configuração de zona de disponibilidade ao implantar o recurso pela primeira vez, enquanto outros oferecem suporte à alteração da abordagem de implantação posteriormente. Da mesma forma, alguns recursos de serviço podem não estar disponíveis com todas as abordagens de implantação.

Para saber mais sobre as opções e abordagens de implantação específicas a serem consideradas para cada serviço do Azure, visite o hub de confiabilidade.

Exemplos

Esta seção descreve alguns casos de uso comuns e os principais requisitos que você normalmente precisa considerar para cada carga de trabalho. Para cada carga de trabalho, uma ou mais abordagens de implantação sugeridas são fornecidas, com base nos requisitos e abordagens descritos neste artigo.

Aplicativo de linha de negócios para uma empresa

A Contoso, Ltd., é uma grande empresa de manufatura. A empresa está implementando um aplicativo de linha de negócios para gerenciar alguns componentes de seus processos financeiros.

Requisitos de negócios: as informações que o sistema gerencia são difíceis de substituir, portanto, os dados precisam ser mantidos de forma confiável. Os arquitetos dizem que o sistema precisa incorrer em o menor tempo de inatividade e a menor perda de dados possível. Os funcionários da Contoso usam o sistema durante todo o dia de trabalho, portanto, o alto desempenho é importante para evitar manter os membros da equipe esperando. O custo também é uma preocupação, pois a equipe financeira tem que pagar pela solução.

Abordagem sugerida: a implantação com redundância de zona com backup entre regiões fornece várias camadas de resiliência com alto desempenho.

Aplicação interna

A Fourth Coffee é um pequeno negócio. A empresa está desenvolvendo um novo aplicativo interno que os funcionários podem usar para enviar quadros de horários.

Requisitos de negócios: para essa carga de trabalho, a eficiência de custos é uma preocupação principal. A Fourth Coffee avaliou o impacto do tempo de inatividade nos negócios e decidiu que o aplicativo não precisa priorizar a resiliência ou o desempenho. A empresa aceita o risco de que uma interrupção em uma zona ou região de disponibilidade do Azure possa tornar o aplicativo temporariamente indisponível.

Abordagens sugeridas:

• A implantação localmente redundante com backups entre regiões tem o menor custo, mas também tem riscos significativos.
• A implantação com redundância de zona com backup entre regiões oferece melhor resiliência, mas a um custo um pouco mais alto.

Migração de aplicativos herdados

A Fabrikam, Inc., está migrando um aplicativo herdado de um datacenter local para o Azure. A implementação usará uma abordagem IaaS baseada em máquinas virtuais. O aplicativo não foi projetado para um ambiente de nuvem, e a comunicação entre a camada do aplicativo e o banco de dados é muito tagarela.

Requisitos de negócios: o desempenho é uma prioridade para este aplicativo. A resiliência também é importante, e o aplicativo deve continuar a funcionar mesmo se um datacenter do Azure enfrentar uma interrupção.

Abordagem sugerida:

• A Fabrikan deve primeiro tentar uma implantação com redundância de zona. Eles devem verificar se o desempenho atende aos seus requisitos.
• Se o desempenho da solução com redundância de zona não for aceitável, considere uma implantação zonal (fixa), com implantações passivas em várias zonas de disponibilidade (DR na região).

Aplicação de cuidados de saúde

A Lamna Healthcare Company está implementando um novo sistema de registro eletrônico de saúde no Azure.

Requisitos de negócios: devido à natureza dos dados que essa solução armazena, a residência de dados é extremamente importante. A Lamna opera sob uma estrutura regulatória rigorosa que determina que os dados devem permanecer em um local específico.

Abordagens sugeridas:

• Implantação multirregião em várias zonas, se houver várias regiões que atendam aos requisitos de residência de dados do Lamna.
• Se houver apenas uma única região que atenda às suas necessidades, considere uma implantação com redundância de zona ou uma implantação com redundância de zona com backup entre regiões fornece uma solução de região única

Sistema bancário

O Woodgrove Bank executa suas principais operações bancárias a partir de uma grande solução implantada no Azure.

Requisitos de negócios: Este é um sistema de missão crítica. Qualquer interrupção pode causar grande impacto financeiro para os clientes. Como resultado, o Woodgrove Bank tem tolerância ao risco muito baixa. O sistema precisa do mais alto nível de confiabilidade possível, e a arquitetura precisa mitigar o risco de quaisquer falhas que possam ser mitigadas.

Abordagem sugerida: para um sistema de missão crítica, use uma implantação multirregião de várias zonas. Garantir que as regiões atendam aos requisitos de residência de dados da empresa.

Software como serviço (aplicativo SaaS)

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

Requisitos de negócios: a Proseware precisa permitir que cada um de seus clientes escolha uma região de implantação próxima ao cliente. Habilitar essa opção é importante para a latência e para os requisitos de residência de dados dos clientes.

Abordagens sugeridas:

• Uma implantação multirregião de várias zonas geralmente é uma boa opção para um provedor de SaaS, especialmente quando é usada dentro do padrão Carimbos de Implantação.
• Uma implantação redundante de região única em conjunto com uma solução de aceleração de tráfego global, como o Azure Front Door.

Links relacionados

A seguir estão algumas arquiteturas de referência e cenários de exemplo para soluções de várias zonas e várias regiões:

• Aplicativo Web com redundância de zona altamente disponível na linha de base
• Aplicativo Web de várias regiões altamente disponível
• Aplicativo de n camadas de várias regiões
• Aplicativo Web de várias camadas criado para HA/DR

Muitos serviços do Azure fornecem orientação sobre como usar várias zonas de disponibilidade, incluindo os seguintes exemplos:

• Azure Site Recovery: Habilitar a recuperação de desastres da VM do Azure entre zonas de disponibilidade
• Arquivos do Azure NetApp: Entenda a replicação entre zonas dos Arquivos do Azure NetApp
• Redundância do Armazenamento do Azure

Lista de verificação de confiabilidade

Consulte o conjunto completo de recomendações.