Replicação entre regiões do Azure
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 infraestrutura independente de energia, refrigeração e rede. Eles são projetados para que, se uma zona sofrer uma interrupção, os serviços regionais, a capacidade e a alta disponibilidade sejam suportados pelas zonas restantes.
Embora as regiões do Azure sejam projetadas para oferecer proteção contra desastres locais com zonas de disponibilidade, elas também podem fornecer proteção contra desastres regionais ou de grande porte geográfico com recuperação de desastres, fazendo uso de outra região secundária que usa replicação entre regiões. As regiões primária e secundária juntas formam um par de regiões.
Replicação entre regiões
Para garantir que os clientes tenham suporte em todo o mundo, o Azure mantém várias geografias. Essas demarcações discretas definem um limite de recuperação de desastres e residência de dados em uma ou várias regiões do Azure.
A replicação entre regiões é um dos vários pilares importantes na estratégia de continuidade de negócios e recuperação de desastres do Azure. A replicação entre regiões baseia-se na replicação síncrona de seus aplicativos e dados que existe usando zonas de disponibilidade em sua região principal do Azure para alta disponibilidade. A replicação entre regiões replica de forma assíncrona os mesmos aplicativos e dados em outras regiões do Azure para proteção de recuperação de desastres.
Alguns serviços do Azure aproveitam a replicação entre regiões para garantir a continuidade dos negócios e proteger contra perda de dados. O Azure fornece várias soluções de armazenamento que utilizam a replicação entre regiões para garantir a disponibilidade dos dados. Por exemplo, o armazenamento com redundância geográfica (GRS) do Azure replica dados para uma região secundária automaticamente. Essa abordagem garante que os dados sejam duráveis mesmo que a região primária não seja recuperável.
Nem todos os serviços do Azure replicam dados automaticamente ou retornam automaticamente de uma região com falha para replicação cruzada para outra região habilitada. Nesses cenários, a recuperação e a replicação devem ser configuradas pelo cliente. Estes exemplos ilustram o modelo de responsabilidade partilhada. É um pilar fundamental na sua estratégia de recuperação de desastres. Para obter mais informações sobre o modelo de responsabilidade compartilhada e saber mais sobre continuidade de negócios e recuperação de desastres no Azure, consulte Gerenciamento de continuidade de negócios no Azure.
A responsabilidade compartilhada torna-se o ponto crucial da sua tomada de decisões estratégicas quando se trata de recuperação de desastres. O Azure não exige que você use a replicação entre regiões e você pode usar serviços para criar resiliência sem replicação cruzada para outra região habilitada. Mas é altamente recomendável que você configure seus serviços essenciais em todas as regiões para se beneficiar do isolamento e melhorar a disponibilidade.
Para aplicativos que oferecem suporte a várias regiões ativas, recomendamos que você use várias regiões habilitadas disponíveis. Essa prática garante disponibilidade ideal para aplicativos e tempo de recuperação minimizado se um evento afetar a disponibilidade. Sempre que possível, projete seu aplicativo para obter o máximo de resiliência e facilidade de recuperação de desastres.
Benefícios da replicação entre regiões
A arquitetura da replicação interregional de serviços e dos dados pode ser decidida por serviço. Você precisará adotar uma abordagem de análise de custo-benefício com base nos requisitos estratégicos e de negócios da sua organização. Os benefícios primários e em cascata da replicação entre regiões são complexos, extensos e merecem elaboração. As vantagens incluem:
- Sequência de recuperação de região: se ocorrer uma interrupção em toda a geografia, a recuperação de uma região será priorizada em cada conjunto de regiões habilitado. Os aplicativos implantados em conjuntos de regiões habilitados têm a garantia de ter uma das regiões priorizadas para recuperação. Se um aplicativo for implantado entre regiões, qualquer uma das quais não estiver habilitada para replicação entre regiões, a recuperação poderá ser atrasada.
- Atualização sequencial: as atualizações planejadas do sistema do Azure para suas regiões habilitadas são escalonadas cronologicamente para minimizar o tempo de inatividade, o impacto de bugs e quaisquer falhas lógicas no caso raro de uma atualização defeituosa.
- Isolamento físico: o Azure se esforça para garantir uma distância mínima de 300 milhas (483 quilômetros) entre datacenters em regiões habilitadas, embora isso não seja possível em todas as geografias. A separação do datacenter reduz a probabilidade de que desastres naturais, distúrbios civis, quedas de energia ou interrupções de rede física possam afetar várias regiões. O isolamento está sujeito às restrições dentro de uma geografia, como tamanho geográfico, disponibilidade de energia ou infraestrutura de rede e regulamentos.
- Residência de dados: as regiões residem na mesma geografia que seu conjunto habilitado (exceto para o Sul do Brasil e Cingapura) para atender aos requisitos de residência de dados para fins de jurisdição fiscal e de aplicação da lei.
Embora não seja possível criar seus próprios emparelhamentos regionais, você pode, no entanto, criar sua própria solução de recuperação de desastres criando seus serviços em qualquer número de regiões e, em seguida, usando os serviços do Azure para emparelhá-los. Por exemplo, você pode usar serviços do Azure, como AzCopy , para agendar backups de dados para uma conta de Armazenamento do Azure em uma região diferente. Usando o DNS do Azure e o Gerenciador de Tráfego do Azure, você pode projetar uma arquitetura resiliente para seus aplicativos que sobreviverão à perda da região primária.
O Azure controla a manutenção planejada e a priorização de recuperação para pares regionais. Alguns serviços do Azure dependem de pares regionais por padrão, como o armazenamento redundante do Azure.
Você não está limitado a usar serviços dentro de seus pares regionais. Embora um serviço do Azure possa depender de um par regional específico, você pode hospedar seus outros serviços em qualquer região que satisfaça suas necessidades de negócios. Por exemplo, uma solução de armazenamento do Azure GRS pode emparelhar dados no Canadá Central com um par no Leste do Canadá enquanto usa recursos de computação do Azure localizados no Leste dos EUA.
Regiões emparelhadas do Azure
Muitas regiões também têm uma região emparelhada para oferecer suporte à replicação entre regiões com base na proximidade e em outros fatores.
Importante
Para saber mais sobre a arquitetura da sua região e os emparelhamentos disponíveis, entre em contato com o representante de vendas ou cliente da Microsoft.
Pares regionais do Azure
| Geografia | Par regional A | Par regional B |
|---|---|---|
| Ásia-Pacífico | Ásia Oriental (Região Administrativa Especial de Hong Kong) | Sudeste Asiático (Singapura) |
| Austrália | Leste da Austrália | Austrália Sudeste |
| Austrália Central | Austrália Central 2* | |
| Brasil | Sul do Brasil | E.U.A. Centro-Sul |
| Sudeste do Brasil* | Sul do Brasil | |
| Canadá | Canadá Central | Leste do Canadá |
| China | Norte da China | Norte da China |
| Norte da China 2 | China Leste 2 | |
| Norte da China 3 | Leste da China 3* | |
| Europa | Europa do Norte (Irlanda) | Europa Ocidental (Países Baixos) |
| França | França Central | França Sul* |
| Alemanha | Alemanha Centro-Oeste | Alemanha Norte* |
| Índia | Índia Central | Sul da Índia |
| Índia Central | Oeste da Índia | |
| Oeste da Índia | Sul da Índia | |
| Japão | Leste do Japão | Oeste do Japão |
| Coreia do Sul | Coreia do Sul Central | Coreia do Sul* |
| Noruega | Leste da Noruega | Noruega Oeste* |
| África do Sul | Norte da África do Sul | África do Sul Ocidental* |
| Suécia | Suécia Central | Suécia Sul* |
| Suíça | Norte da Suíça | Suíça Oeste* |
| Reino Unido | Oeste do Reino Unido | Sul do Reino Unido |
| Estados Unidos | E.U.A. Leste | E.U.A. Oeste |
| E.U.A. Leste 2 | E.U.A. Central | |
| E.U.A. Centro-Norte | E.U.A. Centro-Sul | |
| E.U.A. Oeste 2 | E.U.A. Centro-Oeste | |
| EUA Oeste 3 | E.U.A. Leste | |
| Emirados Árabes Unidos | Norte dos E.A.U. | Centro dos Emirados Árabes Unidos* |
| Departamento de Defesa dos E.U.A. | DoD Leste dos EUA* | Centro de DoD dos EUA* |
| US Gov da América | Governador dos EUA Arizona* | Governador dos EUA Texas* |
| Gov dos EUA Virgínia* | Governador dos EUA Texas* |
(*) Certas regiões têm acesso restrito para oferecer suporte a cenários específicos de clientes, como recuperação de desastres no país/região. Essas regiões estão disponíveis somente mediante solicitação, criando uma nova solicitação de suporte.
Importante
- A Índia Ocidental está emparelhada em apenas uma direção. A região secundária da Índia Ocidental é o Sul da Índia, mas a região secundária do Sul da Índia é a Índia Central.
- O Oeste dos EUA3 está emparelhado em uma direção com o Leste dos EUA. Além disso, o Leste dos EUA é emparelhado bidirecionalmente com o Oeste dos EUA.
- O Sul do Brasil é único porque está emparelhado com uma região fora de sua geografia. A região secundária do Brasil Sul é o Centro-Sul dos EUA. A região secundária do Centro-Sul dos EUA não é o Sul do Brasil.
Regiões com zonas de disponibilidade e sem par de regiões
O Azure continua a expandir-se globalmente em regiões sem um par regional e alcança alta disponibilidade aproveitando as zonas de disponibilidade e o armazenamento localmente redundante ou com redundância de zona (LRS/ZRS). As regiões sem um par não terão armazenamento com redundância geográfica (GRS). Essas regiões seguem as diretrizes de residência de dados para permitir a opção de manter os dados residentes dentro da mesma região. Os clientes são responsáveis pela resiliência de dados com base em suas necessidades de Objetivo de Ponto de Recuperação ou Objetivo de Tempo de Recuperação (RTO/RPO) e podem mover, copiar ou acessar seus dados de qualquer local globalmente. No caso raro de uma região inteira do Azure não estar disponível, os clientes precisarão planejar a Recuperação de Desastres entre Regiões de acordo com as orientações dos serviços do Azure que oferecem suporte à alta disponibilidade e à Resiliência do Azure – Continuidade de Negócios e Recuperação de Desastres.
A tabela abaixo lista as regiões do Azure sem um par de regiões:
| Geografia | Região |
|---|---|
| Catar | Catar Central |
| Polónia | Polónia Central |
| Israel | Israel Central |
| Itália | Norte da Itália |
| Áustria | Áustria Leste (Em breve) |
| Espanha | Espanha Central (Em breve) |