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 a 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 | multi-regional altamente disponível

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

Ao criar uma solução para o Azure, você precisa decidir se implantará em várias zonas de disponibilidade em uma região ou implantará em várias regiões. Essa decisão afeta a confiabilidade, o custo e o desempenho da sua solução e a capacidade da sua equipe de operar a solução. 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 sobre os principais pilares do Azure Well-Architected Framework.

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 você usa 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 atenuar vários tipos de riscos. Em geral, ao espalhar 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 os custos de recursos. Outras abordagens envolvem o envio de dados entre zonas ou regiões de disponibilidade separadas geograficamente, o que pode incorrer em encargos de tráfego de rede. Também é importante considerar o custo contínuo de 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 juntas 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 habilitar a replicação e a 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, talvez seja necessário considerar a localização física dos componentes da carga de trabalho para minimizar a latência quando elas se comunicarem.
• 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. O failover, o failback e o redirecionamento transparente do tráfego podem ser complexos, especialmente quando são necessárias etapas manuais. É uma boa prática automatizar seus processos de implantação e gerenciamento. Para obter mais informações, consulte os guias dos pilares de Excelência Operacional, incluindo infraestrutura OE:05 como código, automação de tarefas OE:09, design de Automação OE:10 e práticas de implantação do OE:11.

No entanto, você projeta 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 mudam sua postura de segurança. O Azure aplica o mesmo rigor de segurança a cada região e zona de disponibilidade.

Dica

Para muitas cargas de trabalho de produção, uma implantação com redundância de zona fornece a melhor balança de compensações. Você pode estender essa abordagem com backup de dados assíncrono para outra região. Se você não tiver certeza de qual abordagem selecionar, comece com esse tipo de implantação.

Considere outras abordagens de carga de trabalho quando você precisar dos benefícios específicos que essas abordagens fornecem, mas esteja ciente das compensações envolvidas.

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 principal e processa o tráfego e uma ou mais instâncias secundárias são implantadas para atender ao 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 energia, resfriamento e infraestrutura de rede. Muitas regiões dão suporte a zonas de disponibilidade.
Datacenter	Uma instalação que contém servidores, equipamentos de rede e outros hardwares para dar suporte a recursos e cargas de trabalho do Azure.
Implantação com redundância local	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 dá 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.
Região	Um perímetro geográfico que contém um conjunto de datacenters.
Arquitetura de 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 reconhecer 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 pegada 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 do Azure e das zonas de disponibilidade.

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. Dentro de uma região, as zonas de disponibilidade são próximas o suficiente para ter conexões de baixa latência com outras zonas de disponibilidade, mas estão distantes o suficiente para reduzir a probabilidade de que mais de uma seja afetada por interrupções locais ou clima. As zonas de disponibilidade têm energia, resfriamento e infraestrutura de rede independentes. Eles foram projetados para que, se uma zona sofrer uma interrupção, os serviços regionais, a capacidade e a alta disponibilidade sejam compatíveis com as zonas restantes.

O diagrama a seguir mostra várias regiões do Azure de exemplo. As regiões 1 e 2 dão suporte a 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 de seu aplicativo e dados em datacenters físicos separados em uma grande área metropolitana.

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 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 são distribuídos entre 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 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) normalmente dão suporte a implantações zonais. Para obter mais informações sobre como os serviços do Azure funcionam com zonas de disponibilidade, consulte Serviços do Azure com suporte à zona de disponibilidade.

Quando a Microsoft implanta atualizações em serviços, tentamos usar abordagens que são as menos disruptivas para você. Por exemplo, pretendemos implantar atualizações em uma única zona de disponibilidade por vez. Essa abordagem pode reduzir o impacto que as atualizações podem ter em uma carga de trabalho ativa, pois a carga de trabalho pode continuar a ser executada em outras zonas enquanto a atualização está em processo. No entanto, é responsabilidade da equipe de carga de trabalho garantir que sua carga de trabalho continue funcionando durante as atualizações da plataforma. Por exemplo, quando você usa conjuntos de dimensionamento de máquinas virtuais 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 excesso de provisionamento – implantar 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 atualizações, consulte Avançar 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 do Azure e zonas de disponibilidade?

Entender 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 que você usa, você pode assumir mais ou menos responsabilidade por operar o serviço.

A Microsoft fornece zonas e regiões de disponibilidade para oferecer flexibilidade na forma como você projeta sua solução para atender aos seus requisitos. Quando você usa serviços gerenciados, a Microsoft assume mais responsabilidades de gerenciamento para 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 recomendar práticas e padrões de design para lidar com falhas normalmente. Essas práticas são ainda mais importantes durante operações de failover, como aquelas que ocorrem quando ocorre uma zona de disponibilidade ou failover de região, pois o failover entre zonas ou regiões geralmente exige que o aplicativo repita as conexões com os serviços.

Identificar os principais requisitos de negócios e cargas 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 orientados por discussões entre designers de soluções e stakeholders de negócios.

Tolerância a riscos

Diferentes organizações têm diferentes graus de tolerância a riscos. Mesmo dentro de uma organização, a tolerância a riscos geralmente é diferente para cada carga de trabalho. A maioria das cargas de trabalho não precisa de alta disponibilidade. No entanto, algumas cargas de trabalho são tão importantes que vale até mesmo a pena atenuar 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 disco rígido ou equipamento de rede. Reinicializações de host.	Alta: Qualquer estratégia de resiliência deve levar em conta esses riscos.
Interrupçã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 de 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

Seria ideal atenuar 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 os stakeholders de negócios para que você possa tomar decisões informadas sobre os riscos que devem ser mitigados.

Dica

Independentemente das metas de confiabilidade, todas as cargas de trabalho devem ter alguma mitigação para recuperação de desastre. Se sua carga de trabalho exigir metas de alta confiabilidade, suas estratégias de mitigação deverão ser abrangentes e você deverá reduzir o risco de eventos de baixa probabilidade. Para outras cargas de trabalho, tome uma decisão informada sobre quais riscos você está preparado para aceitar e quais você precisa mitigar.

Requisitos de resiliência

É importante entender os requisitos de resiliência para sua carga de trabalho, incluindo o RTO (objetivo de tempo de recuperação) e o RPO (objetivo do ponto de recuperação). Esses objetivos ajudam você a decidir quais abordagens descartar. Se você não tiver requisitos claros, não poderá 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 ao tempo de atividade de 99,9%.

O Azure fornece SLAs (contratos de nível de serviço) 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 alcançar esse SLA esperado. No entanto, lembre-se de que a maneira como um SLA do Azure indica que a disponibilidade do serviço nem sempre corresponde à maneira como você considera a integridade da carga de trabalho.

Suas decisões de arquitetura afetam o SLO composto da sua solução. Em geral, quanto mais redundância você criar em sua solução, maior será seu SLO. Muitos serviços do Azure fornecem SLAs mais altos quando você implanta serviços em uma configuração de várias regiões ou com redundância de zona. Examine 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 padrões legais ou regulatórios. Em outras situações, uma organização pode decidir adotar uma política de residência de dados para evitar preocupações do cliente. Se você tiver requisitos estritos 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.

Observação

Evite fazer suposições infundadas sobre seus requisitos de residência de dados. Se você precisar estar em conformidade com padrões regulatórios específicos, verifique o que esses padrões realmente especificam.

Local 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 críticos, você ainda deve usar uma implantação de várias regiões mesmo se os usuários estiverem colocalizados.

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 o volume global do Azure para melhorar sua experiência de usuário e aproximar seus aplicativos da base de usuários. Você pode usar o padrão Selos de Implantação ou o padrão Geodes ou replicar seus recursos em várias regiões.

Mesmo que os usuários estejam em diferentes áreas geográficas, considere se você precisa de uma implantação de várias regiões. Considere se você pode atingir 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 sob um orçamento restrito, é importante considerar os custos envolvidos na implantação de componentes de carga de trabalho redundantes. Esses custos podem incluir encargos de recursos adicionais, 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 em sua arquitetura de solução. Quanto mais complexidade você introduzir, mais difícil fica tomar decisões sobre sua arquitetura. Arquiteturas complexas são mais difíceis de operar, mais difíceis de proteger e, muitas vezes, menos eficazes. Siga o princípio da simplicidade.

Facilitação do Azure

Ao fornecer regiões e zonas de disponibilidade, o Azure permite que você selecione uma abordagem de implantação que atenda às suas necessidades. Há muitas abordagens que você pode escolher, cada uma delas fornece benefícios e 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. A intenção é fornecer um exemplo simples para ilustrar conceitos fundamentais.

Há várias maneiras de implantar essa solução. Cada abordagem fornece um conjunto diferente de benefícios e gera custos diferentes. Em um alto nível, você pode considerar uma implantação localmente redundante, zonal (fixada),com redundância de zona ou de várias regiões . Esta tabela resume algumas das preocupações do pilar:

Pilar	Redundância local	Zonal (fixado)	Com redundância de zona	Várias regiões
Confiabilidade	Baixa confiabilidade	Depende da abordagem	Alta ou muito alta confiabilidade	Alta ou muito alta confiabilidade
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	Requisitos operacionais baixos	Altos requisitos operacionais	Requisitos operacionais baixos	Altos requisitos operacionais

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

Preocupação arquitetônica	Redundância local	Zonal (fixado)	Com redundância de zona	Várias regiões
Conformidade com 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 solução.

Abordagem de implantação 1: implantações com redundância local

Se você não especificar várias zonas ou regiões de disponibilidade ao implantar seus recursos, o Azure não garante se os recursos sã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 está altamente disponível por padrão, com altos SLAs e redundância interna em um datacenter gerenciado pela plataforma. No entanto, do ponto de vista da confiabilidade, se qualquer parte da região sofrer uma interrupção, haverá 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 um desempenho menor. Seus componentes de carga de trabalho podem não ser colocados no mesmo datacenter, portanto, você pode observar alguma latência para o tráfego intra-região. 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, isso não é uma preocupação para a maioria das cargas de trabalho.

Esta tabela resume algumas das preocupações do pilar:

Pilar	Impacto
Confiabilidade	Baixa confiabilidade. Os serviços estarã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	Custo mais baixo. Você só precisa ter uma única instância de cada recurso e não incorre em nenhum custo de largura de banda entre zonas ou entre regiões.
Eficiência de desempenho	Para a maioria das cargas de trabalho:desempenho aceitável. Essa abordagem provavelmente fornecerá um desempenho satisfatório. Para cargas de trabalho altamente sensíveis à latência:baixo desempenho. Não há garantia de que os componentes estejam localizados na mesma zona de disponibilidade, portanto, você pode ver um desempenho menor 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 residência de dados	Alta: Quando você implanta uma solução que usa essa abordagem, os dados são armazenados na região do Azure selecionada.
Disponibilidade regional	Alta: Essa abordagem pode ser usada em qualquer região do Azure.

Implantações com redundância local com backup entre regiões

Você pode estender uma implantação com redundância local executando backups regulares de sua infraestrutura e dados para uma região secundária. Essa abordagem adiciona uma camada extra de proteção para atenuar uma interrupção em sua região primária. Esta é a aparência dele:

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

• Tempo de recuperação: se ocorrer uma interrupção regional, talvez seja necessário recompilar 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 IaC (infraestrutura como código) para que você possa reimplantar rapidamente em outra região se ocorrer um grande desastre. Verifique se suas ferramentas e processos de implantação são tão resilientes quanto seus aplicativos para que você possa usá-los para reimplantar sua solução, mesmo que haja uma interrupção. Planeje e ensaie as etapas necessárias para restaurar sua solução de volta para um estado de trabalho.
• Ponto de recuperação: sua 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 de backups para que possa atender ao RPO.

Esta tabela resume algumas das preocupações do pilar:

Pilar	Impacto
Confiabilidade	Confiabilidade moderada. Os serviços estarão sujeitos a interrupções se um datacenter falhar. O backup de dados é feito de forma assíncrona em uma região geograficamente separada, 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 serem restaurados manualmente na outra região.
Otimização de custos	Custo baixo. Normalmente, adicionar um backup a outra região custa apenas um pouco mais do que implantar um recurso com redundância local.
Eficiência de desempenho	Para a maioria das cargas de trabalho:Desempenho aceitável. Essa abordagem provavelmente fornecerá um desempenho satisfatório. Para cargas de trabalho altamente sensíveis à latência:baixo desempenho. Não há garantia de que os componentes estejam localizados na mesma zona de disponibilidade, portanto, você poderá ver um desempenho menor para componentes altamente sensíveis à latência.
Excelência operacional	Durante qualquer interrupção em uma região:Baixa eficiência operacional. O failover é 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 de região. Os dados são armazenados principalmente na região do Azure especificada. No entanto, você precisa selecionar outra região para armazenar seus backups, portanto, é importante que você selecione uma região compatível com seus requisitos de residência de dados.
Disponibilidade regional	Alta: 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. Às vezes, essa abordagem é chamada de implantação fixada por zona .

Uma abordagem zonal reduz a latência entre seus componentes. No entanto, por si só, isso 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 diferentes zonas de disponibilidade, 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 várias 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 apresentar 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 do Metrô.

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

Pilar	Impacto
Confiabilidade	Quando implantado em uma única zona de disponibilidade:Baixa confiabilidade. Uma implantação zonal não fornece nenhuma 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 um datacenter ou interrupção de 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 delas cobradas separadamente. Você também precisa pagar pelo tráfego entre zonas para replicação de dados.
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 serviço. Você precisa replicar dados entre zonas de disponibilidade. Durante uma interrupção de zona de disponibilidade, o failover é 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	Alta: 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 dê suporte a zonas de disponibilidade.

Normalmente, essa abordagem é usada para cargas de trabalho baseadas em máquinas virtuais. Para obter uma lista completa de serviços que dão 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 usados 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 do SKU da VM.

Dica

Ao implantar um recurso em uma zona de disponibilidade específica, você seleciona o número da zona. A sequência de números de zona é diferente para cada assinatura do Azure. Se você implantar recursos em várias assinaturas do Azure, verifique os números de zona que você deve usar em cada assinatura. Para obter mais informações, consulte Zonas de disponibilidade físicas e lógicas.

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

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

Sua camada de armazenamento também é distribuída entre várias zonas de disponibilidade. Cópias dos dados do aplicativo são distribuídas entre várias zonas de disponibilidade por meio de 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 apresentar 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 para problemas como interrupções de 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 possam 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.

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

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 entre zonas de disponibilidade e sem atraso.
Otimização de custos	Custo moderado. Dependendo dos serviços usados, você pode incorrer em alguns custos para camadas de serviço mais altas para habilitar a redundância de zona ou alguns custos de rede entre zonas.
Eficiência de desempenho	Para a maioria das cargas de trabalho:desempenho aceitável. Essa abordagem provavelmente fornecerá 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 de zona de disponibilidade, o failover é responsabilidade da Microsoft e ocorre automaticamente.

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

Preocupação arquitetônica	Impacto
Conformidade com residência de dados	Alta: 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 dê suporte a zonas de disponibilidade.

Essa abordagem é possível com muitos serviços do Azure, incluindo Conjuntos de Dimensionamento de Máquinas Virtuais 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 dos serviços que dão 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 atenuar o evento extremamente improvável de uma interrupção completa da região.

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

• Tempo de recuperação: se ocorrer uma interrupção regional, talvez seja necessário recompilar 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 IaC para que você possa reimplantar rapidamente em outra região durante um grande desastre. Verifique se as ferramentas e os processos de implantação são tão resilientes quanto seus aplicativos para que você possa usá-los para reimplantar sua solução, mesmo que ocorra uma interrupção. Planeje e ensaie as etapas necessárias para restaurar sua solução de volta para um estado de trabalho.

• Ponto de recuperação: sua 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 de backups para atender ao RPO.

Dica

Essa abordagem geralmente fornece um bom equilíbrio para todas as preocupações de arquitetura. Se você não tiver certeza de qual abordagem usar, comece com esse tipo de implantação.

Esta tabela 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 atraso. O backup de dados é feito de forma assíncrona em uma região separada geograficamente. Esse backup reduz o efeito de uma interrupção de região completa minimizando a perda de dados. Após 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 serem restaurados 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 a redundância de zona.
Eficiência de desempenho	Para a maioria das cargas de trabalho:desempenho aceitável. Essa abordagem provavelmente fornecerá 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 é responsabilidade da Microsoft e ocorre automaticamente. Durante uma interrupção regional:baixa eficiência operacional. O failover é 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 residência de dados	Depende da seleção de 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 dê suporte a zonas de disponibilidade.

Abordagem de implantação 4: implantações de 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 solução ou para dar 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 de capacidade de recurso temporária 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 aos seus requisitos.

Regiões ativas e passivas

As arquiteturas de várias regiões são complexas e há muitas maneiras de criar 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 ativas-ativas). 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 ativas-passivas). 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 de várias regiões ativas e ativas, consulte Padrão de Selos de Implantação e Padrão 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 à distância física mais longa que os dados precisam percorrer. Confira Estatísticas de latência de ida e volta da rede do Azure para obter a latência de rede esperada ao se conectar entre duas regiões.

A latência de rede entre regiões pode afetar significativamente o design da solução porque 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 aguarda que todas as regiões reconheçam uma alteração. Depois que a alteração for confirmada na região primária, a transação será 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 sofrer 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.

Esta tabela resume algumas das preocupações do pilar:

Pilar	Impacto
Confiabilidade	Alta confiabilidade. A solução é resiliente a uma interrupção de um datacenter, uma zona de disponibilidade ou 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 normalmente é 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 de região. Essa abordagem exige 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 tem 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 de várias regiões síncrona, 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 aguardando 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.

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

Pilar	Impacto
Confiabilidade	Confiabilidade muito alta. A solução é resiliente a uma interrupção de um datacenter, uma zona de disponibilidade ou uma região inteira. Os dados estão sempre sincronizados entre regiões, portanto, mesmo que ocorra uma perda de região completa, seus dados estão disponíveis e concluídos 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 de região. Essa abordagem exige 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 tem 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 GRS (armazenamento com redundância geográfica) com regiões emparelhadas. Se o GRS não estiver disponível, considere usar recursos como replicação de objeto do Armazenamento do Azure ou projete seu aplicativo para gravar em várias regiões.

Combinar 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 grau muito alto de confiabilidade. No entanto, configurar esse tipo de abordagem pode ser complicado e essa abordagem pode ser cara.

Importante

Cargas de trabalho críticas devem usar várias zonas de disponibilidade e várias regiões. Para obter mais informações sobre as considerações que você deve dar ao projetar cargas de trabalho críticas, consulte Documentação de carga de trabalho crítica.

Como os serviços do Azure dão suporte à implantação se aproxima

É 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 a configuração da zona de disponibilidade ao implantar o recurso pela primeira vez, enquanto outros dão suporte à alteração da abordagem de implantação mais tarde. Da mesma forma, alguns recursos de serviço podem não estar disponíveis em 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 fabricação. 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 persistidos de forma confiável. Os arquitetos dizem que o sistema precisa incorrer no menor tempo de inatividade e o mínimo possível de perda de dados. Os funcionários da Contoso usam o sistema durante todo o dia útil, portanto, o alto desempenho é importante para evitar manter os membros da equipe aguardando. O custo também é uma preocupação, porque 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.

Aplicativo interno

A Fourth Coffee é uma pequena empresa. 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 custo é uma preocupação principal. A Fourth Coffee avaliou o impacto nos negócios do tempo de inatividade 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 com redundância local 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 fornece melhor resiliência, mas a um custo ligeiramente maior.

Migração de aplicativo herdado

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 de 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 funcionando mesmo que um datacenter do Azure tenha uma interrupção.

Abordagem sugerida:

• 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 (fixada), com implantações passivas em várias zonas de disponibilidade (DR na região).

Aplicativo de serviços de saúde

A Lamna Healthcare Company está implementando um novo sistema eletrônico de registro de integridade 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 estrita que determina que os dados devem permanecer em um local específico.

Abordagens sugeridas:

• Implantação de várias regiões de várias zonas, se houver várias regiões que atendem aos requisitos de residência de dados da 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 de uma grande solução implantada no Azure.

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

Abordagem sugerida: para um sistema crítico, use uma implantação de várias regiões de várias zonas. Verifique se as regiões se ajustam aos requisitos de residência de dados da empresa.

SaaS (software como serviço)

Proseware, Inc., cria software 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 latência e para os requisitos de residência de dados dos clientes.

Abordagens sugeridas:

• Uma implantação de várias regiões de várias zonas normalmente é uma boa opção para um provedor de SaaS, especialmente quando é usada dentro do padrão Selos de Implantação.
• Uma implantação com redundância de zona 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 diretrizes sobre como usar várias zonas de disponibilidade, incluindo os seguintes exemplos:

• Site Recovery do Azure: habilitar a recuperação de desastre de VM do Azure entre zonas de disponibilidade
• Azure NetApp Files: entender a replicação entre zonas de Azure NetApp Files
• Redundância do Armazenamento do Azure

Lista de verificação de confiabilidade

Consulte o conjunto completo de recomendações.

Lista de verificação de confiabilidade