Nota
O acesso a esta página requer autorização. Podes tentar iniciar sessão ou mudar de diretório.
O acesso a esta página requer autorização. Podes tentar mudar de diretório.
Muitas regiões do Azure fornecem zonas de disponibilidade, que são grupos separados de datacenters dentro de uma região. Cada zona de disponibilidade tem infraestrutura independente de energia, resfriamento e rede, de modo que, se uma zona sofrer uma interrupção, os serviços regionais, a capacidade e a alta disponibilidade serão suportados pelas zonas restantes.
As zonas de disponibilidade são normalmente separadas por vários quilômetros, e geralmente estão dentro de 100 quilômetros. Essa distância significa que eles estão próximos o suficiente para ter conexões de baixa latência para outras zonas de disponibilidade por meio de uma rede de alto desempenho. No entanto, eles estão distantes o suficiente para reduzir a probabilidade de que mais de um seja afetado por interrupções locais ou pelo clima.
Os locais dos datacenters são selecionados usando critérios rigorosos de avaliação de risco de vulnerabilidade. Esse processo identifica todos os riscos significativos específicos do datacenter e considera os riscos compartilhados entre as zonas de disponibilidade.
O Azure não cobra pela transferência de dados entre zonas de disponibilidade na mesma região, quer utilize endereçamento IP privado ou público.
O diagrama a seguir mostra vários exemplos de regiões do Azure. As regiões 1 e 2 suportam zonas de disponibilidade e as regiões 3 e 4 não têm zonas de disponibilidade.
Sugestão
Para ver quais regiões oferecem suporte a zonas de disponibilidade, consulte Lista de regiões do Azure.
Centros de dados e zonas de disponibilidade
Uma zona de disponibilidade é um agrupamento lógico de um ou mais centros de dados fisicamente separados dentro de uma região. Cada zona de disponibilidade é construída de forma que, se algo der errado em uma (como uma queda de energia ou problema de rede), as outras continuarão funcionando. Um único datacenter não oferece esse nível de proteção por si só.
Tipos de suporte à zona de disponibilidade
Os serviços Azure podem fornecer três tipos de suporte de zonas de disponibilidade para os seus recursos: redundantes por zona e zonais. Cada serviço pode suportar um ou mais destes tipos. Ao desenhar a sua estratégia de fiabilidade, certifique-se de que compreende como cada serviço da sua carga de trabalho suporta as zonas de disponibilidade, consultando o guia de fiabilidade de cada serviço.
Cada serviço pode implementar suporte de zonas de disponibilidade de formas diferentes. As secções seguintes descrevem os dois tipos de zonas de disponibilidade que os serviços podem fornecer:
Recursos redundantes por zona: Recursos redundantes por zona são replicados ou distribuídos por múltiplas zonas de disponibilidade pelo serviço. Por exemplo, os serviços de dados com redundância de zona replicam os dados em várias zonas para que uma falha em uma zona não afete a disponibilidade dos dados. Alguns serviços são automaticamente redundantes por zona nas regiões suportadas, enquanto outros exigem que configure o seu recurso para ser redundante por zona. Para a maioria dos serviços, a Microsoft seleciona as zonas que os seus recursos utilizam. Por vezes podes selecionar o conjunto de zonas.
Com implantações com redundância de zona, 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 zona de disponibilidade, a Microsoft gerenciará o failover para outra zona automaticamente.
Recursos zonais: Um recurso zonal é destacado para uma única zona de disponibilidade auto-selecionada.
As implantações zonais não fornecem automaticamente resiliência às interrupções da zona de disponibilidade. No entanto, os recursos zonais estão isolados das falhas noutras zonas. Também podem ajudar a alcançar requisitos de latência ou desempenho invulgarmente rigorosos. Por exemplo, para uma carga de trabalho intensa criada usando máquinas virtuais, pode optar por implantar várias máquinas virtuais na mesma zona para reduzir a latência entre elas.
Para tornar os recursos zonais resilientes a interrupções na zona de disponibilidade, você precisa projetar uma arquitetura com recursos separados em várias zonas de disponibilidade dentro da região. A Microsoft não gerencia o processo para você. Se ocorrer uma interrupção em uma zona de disponibilidade, você será responsável pelo failover para outra zona.
Alguns serviços podem ter requisitos adicionais a serem atendidos para suporte à zona de disponibilidade. Por exemplo, alguns só podem dar suporte a zonas de disponibilidade para determinadas camadas ou SKUs, ou em um subconjunto de regiões do Azure. Os guias de fiabilidade contêm detalhes de quaisquer requisitos que precise de cumprir para permitir zonas de disponibilidade nos seus serviços.
Quando configura um recurso para ser redundante em zonas, ou se utiliza várias instâncias de um recurso zonal em diferentes zonas de disponibilidade, o seu recurso é considerado resiliente a zonas: ou seja, é resiliente à falha de uma única zona de disponibilidade.
Para saber mais sobre como utilizar implantações zonais e manter a resiliência das zonas, consulte Recursos zonais e resiliência das zonas.
Se um recurso não estiver configurado para usar zonas de disponibilidade, seja porque a região que usa não suporta zonas ou devido às suas escolhas de configuração, chama-se uma implementação não zonal ou regional . A Azure pode colocar recursos não zonais em qualquer zona da região. Não escolhes que recursos vão para que zonas. Se alguma zona de disponibilidade na região sofrer uma interrupção, recursos não zonais podem estar na zona afetada e sofrer períodos de inatividade.
Configurando recursos para suporte à zona de disponibilidade
Cada serviço tem seu próprio método para configurar o suporte à zona de disponibilidade. Para saber como cada serviço dá suporte a zonas de disponibilidade e como configurar esse suporte, consulte Guias de confiabilidade do Azure por serviço.
Zonas de disponibilidade física e lógica
Cada datacenter é atribuído a uma zona física. As zonas físicas são mapeadas para zonas lógicas na sua subscrição do Azure e subscrições diferentes podem ter uma ordem de mapeamento diferente. As assinaturas do Azure recebem automaticamente seu mapeamento no momento em que a assinatura é criada. Por isso, o mapeamento de zona para uma assinatura pode ser diferente para outras assinaturas.
Por exemplo, a subscrição A pode ter a zona física 1 mapeada para a zona lógica 2, enquanto a subscrição B tem a zona física 1 mapeada para a zona lógica 3:
Para compreender o mapeamento entre zonas lógicas e físicas da sua subscrição, utilize a API do Azure Resource Manager (ARM) List Locations. Você pode usar a CLI do Azure ou o Azure PowerShell para recuperar as informações da API.
Para comparar o mapeamento de zonas para soluções resilientes que abrangem várias assinaturas, use a API ARM dedicada, checkZonePeers. Para usar a checkZonePeers API, o recurso "Microsoft.Resources/AvailabilityZonePeering" precisa ser habilitado. Para obter mais informações sobre como habilitar recursos, consulte Registrar recursos na assinatura do Azure.
az rest --method get \
--uri '/subscriptions/{subscriptionId}/locations?api-version=2022-12-01' \
--query 'value[?availabilityZoneMappings != `null`].{displayName: displayName, name: name, availabilityZoneMappings: availabilityZoneMappings}'
Zonas de disponibilidade e atualizações do Azure
Para cada região, a Microsoft pretende implantar atualizações para os serviços do Azure em uma única zona de disponibilidade de cada vez. Essa abordagem reduz o impacto que as atualizações podem ter em uma carga de trabalho ativa, permitindo que a carga de trabalho continue a ser executada em outras zonas enquanto a atualização está em processo. Para aproveitar as atualizações de zona seqüenciadas, sua carga de trabalho já deve estar configurada para ser executada em várias zonas. Para obter mais informações sobre como o Azure implanta atualizações, consulte Avançando práticas de implantação seguras.
Latência entre zonas
Dentro de cada região, as zonas de disponibilidade são conectadas através de uma rede de alto desempenho. A Microsoft se esforça para obter uma comunicação entre zonas com latência de ida e volta inferior a aproximadamente 2 milissegundos. A baixa latência permite a comunicação de alto desempenho dentro de uma região e a replicação síncrona de dados em várias zonas de disponibilidade.
Nota
A latência de destino refere-se à latência dos links de rede. Dependendo do protocolo de comunicação usado e dos saltos de rede necessários para qualquer fluxo de rede específico, a latência observada pode ser diferente.
Na maioria das cargas de trabalho, você pode distribuir componentes de sua solução entre zonas de disponibilidade sem um efeito percetível no desempenho. Se você tiver uma carga de trabalho com um alto grau de sensibilidade à latência entre zonas, é importante testar a latência entre as zonas de disponibilidade selecionadas com seus protocolos e configuração reais. Para reduzir o tráfego interzonal, é possível usar implantações zonais, mas, idealmente, deve usar múltiplas zonas de disponibilidade no seu plano de estratégia de fiabilidade. Para saber mais sobre como utilizar implantações zonais e manter a resiliência das zonas, consulte Recursos zonais e resiliência das zonas.
Orientação arquitetônica da zona de disponibilidade
Para obter cargas de trabalho confiáveis:
- As cargas de trabalho de produção devem ser configuradas para usar várias zonas de disponibilidade se a região em que estão oferecer suporte a zonas de disponibilidade.
- Para cargas de trabalho de missão crítica, você deve considerar uma solução que seja multirregião e multizona.
Para obter informações mais detalhadas sobre como usar regiões e zonas de disponibilidade em uma arquitetura de solução, consulte Recomendações para usar zonas e regiões de disponibilidade.