Recomendações para o uso de zonas e regiões de disponibilidade
Aplica-se a esta recomendação da lista de verificação de Fiabilidade 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 implantará em várias regiões. Essa decisão afeta a confiabilidade, o custo e o desempenho da sua solução, bem como 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 nos pilares principais 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 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 através de 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 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 da 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 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. 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, aplica-se o pilar Segurança. 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 todas as regiões e zonas de disponibilidade.
Gorjeta
Para muitas cargas de trabalho de produção, uma implantação com redundância de zona fornece o melhor equilíbrio 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 precisar dos benefícios específicos que essas abordagens oferecem, mas esteja ciente das compensações envolvidas.
Definições
| Termo | Definição |
|---|---|
| Ativa-ativa | Uma arquitetura na qual várias instâncias de uma solução processam ativamente solicitações ao mesmo tempo. |
| Ativa-passiva | 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. Em um momento posterior, as alterações são replicadas para outro local. |
| Availability zone | 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 suportam 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. |
| Implementaçã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 estão emparelhadas. |
| País/Região | 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 geral de gravação 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. 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 pelo clima. As zonas de disponibilidade têm infraestruturas independentes de energia, refrigeração e rede. São concebidas para que, caso uma zona sofra 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 suportam 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:
- Recursos zonais estão afixados a uma zona de disponibilidade específica. Pode combinar várias implantações zonais em diferentes zonas para cumprir os requisitos de alta fiabilidade. É responsável por gerir a replicação de dados e por distribuir pedido entre zonas. Se ocorrer uma interrupção numa única zona de disponibilidade, será responsável pela ativação pós-falha para outra zona de disponibilidade.
- Recursos com redundância entre zonas estão distribuídos por várias zonas de disponibilidade. A Microsoft gere a distribuição de pedidos entre zonas e a replicação de dados entre zonas. Caso ocorra uma interrupção numa única zona de disponibilidade, a Microsoft gere a ativação pós-falha automaticamente.
Os serviços do Azure dão suporte a uma ou ambas as abordagens. Os serviços de plataforma como serviço (PaaS) normalmente oferecem suporte a implantações com redundância de zona. Os serviços de infraestrutura como serviço (IaaS) normalmente oferecem 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 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 PaaS do Azure, o Azure coloca seus recursos de forma inteligente para reduzir o impacto das atualizações da 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 atualizações, consulte Avançando práticas de implantação seguras.
Muitas regiões também têm uma região emparelhada. As regiões emparelhadas suportam certos tipos de abordagens de implantação multirregionais. 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 partilhadas
O princípio da responsabilidade compartilhada descreve como as responsabilidades são divididas entre o provedor de nuvem (Microsoft) e você. Dependendo do tipo de serviços que você usa, você pode assumir mais ou menos responsabilidade pela operação do serviço.
A Microsoft fornece zonas e regiões de disponibilidade para lhe dar flexibilidade na forma como concebe a sua solução para satisfazer os seus requisitos. Quando você usa serviços gerenciados, a Microsoft assume mais responsabilidades de gerenciamento de 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 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 tente novamente 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 impulsionados por discussões entre designers de soluções e partes interessadas do negócio.
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 a pena mitigar riscos 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 do host. |
Elevada. Qualquer estratégia de resiliência deve ter em conta estes riscos. |
| Interrupção do datacenter | Falha de alimentação, resfriamento ou rede em todo um datacenter. Desastre natural em uma parte de uma área metropolitana. |
Médio |
| Interrupção da região | Catástrofes naturais de grandes proporções que afetam uma vasta á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 mitigar todos os riscos possíveis para cada carga de trabalho, mas não é prático ou rentável fazê-lo. É importante ter uma discussão aberta com as partes interessadas do negócio para que você possa tomar decisões informadas sobre os riscos que você deve mitigar.
Gorjeta
Independentemente das metas de confiabilidade, todas as cargas de trabalho devem ter alguma atenuação para recuperação de desastres. Se sua carga de trabalho exige metas de alta confiabilidade, suas estratégias de mitigação devem ser abrangentes e você deve reduzir o risco de eventos até mesmo de baixa probabilidade. Para outras cargas de trabalho, tome uma decisão informada sobre quais riscos você está preparado para aceitar e quais precisa mitigar.
Requisitos de resiliência
É importante entender os requisitos de resiliência para sua carga de trabalho, incluindo o RTO (Recovery Time Objetive, objetivo de tempo de recuperação) e o RPO (Recovery Point Objetive, objetivo de ponto de recuperação). Esses objetivos ajudam você a decidir quais abordagens descartar. Se você não tem requisitos claros, você 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 de 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 de que sua solução precisa 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ê incorporar à sua solução, maior será a probabilidade de seu SLO. Muitos serviços do Azure fornecem SLAs mais altos quando você implanta serviços em uma configuração com redundância de zona 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 dados
Algumas organizações impõem restrições aos locais físicos nos quais seus dados podem ser armazenados e processados. Por vezes, estes requisitos baseiam-se 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 estritos de residência de dados, talvez seja necessário usar uma implantação de região única ou um subconjunto de regiões e serviços do Azure.
Nota
Evite fazer suposições infundadas sobre seus requisitos de residência de dados. Se você precisar estar em conformidade com normas regulatórias específicas, verifique o que essas normas realmente especificam.
Localização do utilizador
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 seus usuários estiverem concentrados em uma área, uma implantação de região única pode 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 seus usuários estejam 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 diferentes recursos para dar suporte a uma implantação em várias regiões, e você pode usar a pegada 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 Selos 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 em 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 com um orçamento restrito, é importante considerar os custos envolvidos na implantação de componentes de carga de trabalho redundantes. Esses custos podem incluir taxas de recursos adicionais, custos de rede e os custos operacionais de gerenciar mais recursos e um ambiente mais complexo.
Complexidade
É uma boa prática para evitar complexidade desnecessária na arquitetura da solução. Quanto mais complexidade você introduzir, 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, com menor desempenho. 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 das quais fornece 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 de 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 proporciona um conjunto diferente de benefícios e incorre em custos diferentes. Em um alto nível, você pode considerar uma implantação localmente redundante, zonal (fixada), redundante de zona ou multirregião. Este quadro resume algumas das preocupações dos pilares:
| Pilar | Localmente redundante | Zonal (fixado) | Zona redundante | Multi-região |
|---|---|---|---|---|
| Fiabilidade | Baixa fiabilidade | Depende da abordagem | Fiabilidade elevada ou muito elevada | Fiabilidade elevada ou muito elevada |
| Otimização de Custos | Baixo custo | Depende da abordagem | Custo moderado | Custo elevado |
| Eficiência de Desempenho | Desempenho aceitável (para a maioria das cargas de trabalho) | Elevado desempenho | Desempenho aceitável (para a maioria das cargas de trabalho) | Depende da abordagem |
| Excelência Operacional | 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) | Zona redundante | 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 está altamente disponível por padrão, com SLAs altos 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, 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. Os componentes da carga de trabalho podem não estar colocalizados no mesmo datacenter, portanto, você pode observar alguma latência para o tráfego intrarregiã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.
Este quadro resume algumas das preocupações dos pilares:
| Pilar | Impacto |
|---|---|
| Fiabilidade | Baixa fiabilidade. 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 perspetiva arquitetônica:
| Preocupação arquitetónica | Impacto |
|---|---|
| Conformidade com a residência de dados | Elevada. Quando você implanta uma solução que usa essa abordagem, os dados são armazenados na região do Azure selecionada. |
| Disponibilidade regional | Elevada. 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 na região principal. O aspeto é o seguinte:
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 reconstruir sua solução em outra região do Azure, o que afeta seu tempo de recuperação. Considere a criação de 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 desastre de grandes proporções. 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 trabalho.
- Ponto de recuperação: a frequência do 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 seu RPO.
Este quadro resume algumas das preocupações dos pilares:
| Pilar | Impacto |
|---|---|
| Fiabilidade | Fiabilidade 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 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 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 perspetiva 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, por isso é importante selecionar uma região compatível com seus requisitos de residência de dados. |
| Disponibilidade regional | Elevada. Você pode usar essa abordagem em qualquer região do Azure. |
Abordagem de implantação 2: implantações zonais (fixas)
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 você roteia o tráfego entre instâncias em diferentes zonas de disponibilidade, porque 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 Azure Traffic Manager, 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 ativo-passiva em várias zonas de disponibilidade às vezes é chamada de DR na região ou Metro DR.
Este quadro resume algumas das preocupações dos pilares:
| Pilar | Impacto |
|---|---|
| Fiabilidade | Quando implantado em uma única zona de disponibilidade: baixa confiabilidade. Uma implantação zonal não fornece qualquer 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 tornados 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 perspetiva arquitetônica:
| Preocupação arquitetónica | Impacto |
|---|---|
| Conformidade com a residência de dados | Elevada. 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 disponibilidade de SKU de VM.
Gorjeta
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ísica e lógica.
Abordagem de implantação 3: implantações com redundância de zona
Quando você usa essa abordagem, sua camada de aplicativo é distribuída em várias zonas de disponibilidade. Quando as solicitações chegam, um balanceador de carga integrado ao serviço (que abrange zonas de disponibilidade) dispersa as solicitações pelas 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á distribuído em várias zonas de disponibilidade. As cópias dos dados do seu 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 estiverem 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 sua solução a problemas como interrupçõ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 partes diferentes 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 em zonas de disponibilidade pode afetar o desempenho do aplicativo.
Este quadro resume algumas das preocupações dos pilares:
| Pilar | Impacto |
|---|---|
| Fiabilidade | Elevada fiabilidade. 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 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 perspetiva arquitetônica:
| Preocupação arquitetónica | Impacto |
|---|---|
| Conformidade com a residência de dados | Elevada. 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 Escala de Máquina Virtual do Azure, Serviço de Aplicativo do Azure, Azure Functions, Serviço Kubernetes do Azure, Armazenamento do Azure, Azure SQL, Barramento de Serviço do Azure e muitos outros. Para obter uma lista completa dos serviços que suportam 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 redundante 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 reconstruir sua solução em outra região do Azure, o que afeta seu 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 desastre de grandes proporções. 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 que ocorra uma interrupção. Planeje e ensaie as etapas necessárias para restaurar sua solução de volta a um estado de trabalho.
Ponto de recuperação: a frequência do 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 seu RPO.
Gorjeta
Essa abordagem geralmente fornece um bom equilíbrio para todas as preocupações arquitetônicas. Se você não tiver certeza de qual abordagem usar, comece com esse tipo de implantação.
Este quadro resume algumas das preocupações dos pilares:
| Pilar | Impacto |
|---|---|
| Fiabilidade | Fiabilidade muito elevada. 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 dos dados é feito de forma assíncrona em uma região separada geograficamente. Esse backup reduz o efeito de uma interrupção completa da região, 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 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 na zona de disponibilidade: Alta eficiência operacional. O failover é de responsabilidade da Microsoft e acontece automaticamente. Durante uma interrupçã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 perspetiva 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, 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 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 ativo-passivas). Esta seção se concentra no segundo cenário, no qual uma região é ativa e outra é passiva. Para obter informações sobre soluções multirregiões ativas, consulte Padrão de carimbos 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 à maior distância física que os dados precisam percorrer. Consulte as estatísticas de latência de ida e volta da rede do Azure para obter a latência de rede esperada quando você se conecta entre duas regiões.
A latência da 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 assíncrona de dados
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 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 da 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 após a conclusão de uma gravação 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 dos pilares:
| Pilar | Impacto |
|---|---|
| Fiabilidade | Elevada fiabilidade. 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 aplicativos 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 perspetiva arquitetônica:
| Preocupação arquitetónica | Impacto |
|---|---|
| Conformidade com a residência de dados | Depende da seleção da região. Essa abordagem exige que você selecione várias regiões para que sua carga de trabalho seja 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 síncrona de dados
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 ao aguardar 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 dos pilares:
| Pilar | Impacto |
|---|---|
| Fiabilidade | Fiabilidade muito elevada. 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 aplicativos 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 perspetiva arquitetônica:
| Preocupação arquitetónica | Impacto |
|---|---|
| Conformidade com a residência de dados | Depende da seleção da região. Essa abordagem exige que você selecione várias regiões para que sua carga de trabalho seja 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 projetar 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 objetos do Armazenamento do Azure ou projetar seu aplicativo para gravar em várias regiões.
Combine abordagens multi-zona e multi-região
Você deve combinar declarações multizona e multirregião se os requisitos do seu negócio exigirem tal solução. Por exemplo, você pode implantar componentes redundantes de zona em cada região e também configurar a replicação entre as regiões. Para algumas soluções, esta abordagem proporciona um grau muito elevado de fiabilidade. No entanto, configurar esse tipo de abordagem pode ser complicado, e essa abordagem pode ser cara.
Importante
As cargas de trabalho de missão crítica 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 de missão crítica, consulte Documentação de carga de trabalho de missão crítica.
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 a configuração da zona de disponibilidade quando você implanta 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á a implementar uma aplicação de linha de negócio para gerir alguns componentes dos seus processos financeiros.
Requisitos de negócios: as informações gerenciadas pelo sistema são difíceis de substituir, portanto, os dados precisam ser mantidos de forma confiável. Os arquitetos dizem que o sistema precisa incorrer no menor tempo de inatividade e na 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, 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.
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 resiliência ou 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 maior.
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 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 a funcionar mesmo se um datacenter do Azure sofrer uma interrupção.
Abordagem sugerida:
- A Fabrikan deve primeiro tentar uma implantação com redundância de zona. Devem verificar se o desempenho cumpre os 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).
Aplicação de cuidados de saúde
A Lamna Healthcare Company está implementando um novo sistema de registro de saúde eletrônico 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 rígida que determina que os dados devem permanecer em um local específico.
Abordagens sugeridas:
- Implantação multi-região multi-região, se houver várias regiões que se encaixam nos 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 que forneça uma solução de região única
Sistema da banca
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 um grande impacto financeiro para os clientes. Como resultado, o Woodgrove Bank tem uma 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 multizona multirregião. Certifique-se de que as regiões se encaixam nos requisitos de residência de dados da empresa.
Software como serviço (SaaS)
A 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: o Proseware precisa permitir que cada um de seus clientes escolha uma região de implantação próxima ao cliente. Habilitar essa escolha é importante para a latência e para os requisitos de residência de dados dos clientes.
Abordagens sugeridas:
- Uma implantação multizona em várias regiões normalmente é uma boa opção para um provedor de SaaS, especialmente quando é usada dentro do padrão de Selos de Implantação.
- Uma implantação redundante de zona única em conjunto com uma solução de aceleração de tráfego global, como o Azure Front Door.
Ligações relacionadas
A seguir estão algumas arquiteturas de referência e cenários de exemplo para soluções multizona e multirregião:
- Aplicativo Web com redundância de zona altamente disponível de linha de base
- Aplicação Web multi-região altamente disponível
- Aplicativo de N camadas de várias regiões
- Aplicação Web multicamadas criada 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 de VM do Azure entre zonas de disponibilidade
- Arquivos NetApp do Azure: entenda a replicação entre zonas dos Arquivos NetApp do Azure
- Redundância do Armazenamento do Azure
Lista de verificação de fiabilidade
Consulte o conjunto completo de recomendações.