Replicação entre regiões do Azure
Muitas regiões do Azure fornecem zonas de disponibilidade, que são grupos separados de datacenters. Nas regiões, as zonas de disponibilidade são próximas o suficiente para conexões de baixa latência com outras zonas de disponibilidade, mas distantes o suficiente para reduzir a probabilidade de que mais de uma delas seja afetada por interrupções locais ou clima. As zonas de disponibilidade têm infraestruturas independentes de energia, resfriamento e rede. Elas são projetadas para que, se uma zona sofrer uma interrupção, os serviços regionais, a capacidade e a alta disponibilidade sejam suportados pelas zonas restantes.
Embora as regiões do Azure sejam concebidas para oferecer proteção contra desastres locais com zonas de disponibilidade, também podem fornecer proteção contra desastres geográficos regionais ou de grande dimensão com recuperação de desastres, utilizando outra região secundária que utiliza replicação entre regiões. Ambas 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 regiões geográficas. Essas demarcações discretas definem o limite de recuperação de desastre e de residência de dados em uma ou em várias regiões do Azure.
A replicação entre regiões é um dos vários pilares importantes na estratégia de continuidade dos negócios e recuperação de desastres do Azure. A replicação entre regiões se baseia na replicação síncrona de seus aplicativos e dados que existem usando zonas de disponibilidade em sua região primária do Azure para alta disponibilidade. A replicação entre regiões replica de modo assíncrono os mesmos aplicativos e dados em outras regiões do Azure para proteção de recuperação de desastre.
Alguns serviços do Azure aproveitam a replicação entre regiões para garantir a continuidade dos negócios e a proteção contra perda de dados. O Azure fornece várias soluções de armazenamento que usam replicação entre regiões para garantir a disponibilidade de dados. Por exemplo, o GRS (armazenamento com redundância geográfica) do Azure replica os dados para uma região secundária automaticamente. Essa abordagem garante que os dados sejam duráveis, mesmo se a região primária não for 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. Esses exemplos são ilustrações do modelo de responsabilidade compartilhada. É um pilar fundamental em sua estratégia de recuperação de desastre. Para obter mais informações sobre o modelo de responsabilidade compartilhada e saber mais sobre continuidade dos negócios e recuperação de desastres no Azure, confira Gerenciamento de continuidade de negócios no Azure.
A responsabilidade compartilhada se torna o cerne de sua tomada de decisão estratégica 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 os serviços para criar resiliência sem replicação cruzada para outra região habilitada. Porém, é altamente recomendável que você configure seus serviços essenciais entre regiões para se beneficiar do isolamento e melhorar a disponibilidade.
Para aplicativos que dão suporte a várias regiões ativas, recomendamos usar várias regiões habilitadas disponíveis. Essa prática garante a 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 máxima resiliência e facilidade de recuperação de desastres.
Benefícios da replicação entre regiões
A arquitetura para replicação e dados entre regiões de serviço 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 principal e ripple da replicação entre regiões de custo são complexos, abrangentes e merecem detalhamento. Esses benefícios 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 de cada conjunto de regiões habilitado. Os aplicativos implantados em vários conjuntos de região habilitados com certeza terão uma das regiões priorizadas para recuperação. Se um aplicativo for implantado entre regiões e alguma delas 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 falhas lógicas no raro evento de uma falha de atualização.
- 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 regiões geográficas. A separação do datacenter reduz a probabilidade de que desastres naturais, levantes civis, interrupções de energia ou interrupções de rede física possam afetar várias regiões. Isolamento está sujeito às restrições dentro da região geográfica, como tamanho da região geográfica, disponibilidade da infraestrutura de rede/alimentação e normas.
- Residência de dados: as regiões residem na mesma geografia que seu conjunto habilitado (exceto pelo Sul do Brasil e Singapura) para cumprir os requisitos de residência de dados para fins de jurisdição de fiscalização de impostos e leis.
Embora não seja possível criar os seus próprios emparelhamentos regionais, pode, no entanto, criar a sua própria solução de recuperação de desastres construindo os seus serviços em qualquer número de regiões e, em seguida, utilizando os serviços do Azure para os emparelhar. Por exemplo, você pode usar serviços do Azure, como o 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, é possível criar uma arquitetura resiliente para seus aplicativos que sobreviverão à perda da região primária.
O Azure controla a priorização planejada de manutenção e 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 em seus pares regionais. Embora um determinado serviço do Azure possa depender de um par regional específico, você pode hospedar seus outros serviços em qualquer região que atenda às suas necessidades de negócios. Por exemplo, uma solução de armazenamento GRS do Azure pode emparelhar dados no Canadá Central com um par no Leste do Canadá ao usar 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 dar 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
| painel Geografia do app's selecionado | Par regional A | Par regional B |
|---|---|---|
| Ásia-Pacífico | Leste da Ásia (Região Administrativa Especial de Hong Kong) | Sudeste da Ásia (Singapura) |
| Austrália | Leste da Austrália | Australia Southeast |
| Austrália Central | Austrália Central 2* | |
| Brasil | Sul do Brasil | Centro-Sul dos Estados Unidos |
| Sudeste do Brasil* | Sul do Brasil | |
| Canadá | Canadá Central | Leste do Canadá |
| China | Norte da China | Leste da China |
| Norte da China 2 | Leste da China 2 | |
| Norte da China 3 | Leste da China 3* | |
| Europa | Norte da Europa (Irlanda) | Oeste da Europa (Países Baixos) |
| França | França Central | Sul da França* |
| Alemanha | Centro-Oeste da Alemanha | Norte da Alemanha* |
| Í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 Central | Sul da Coreia* |
| Noruega | Leste da Noruega | Oeste da Noruega* |
| África do Sul | Norte da África do Sul | Oeste da África do Sul* |
| Suécia | Suécia Central | Sul da Suécia* |
| Suíça | Norte da Suíça | Oeste da Suíça* |
| Reino Unido | Oeste do Reino Unido | Sul do Reino Unido |
| Estados Unidos | Leste dos EUA | Oeste dos EUA |
| Leste dos EUA 2 | Centro dos EUA | |
| Centro-Norte dos EUA | Centro-Sul dos Estados Unidos | |
| Oeste dos EUA 2 | Centro-Oeste dos EUA | |
| Oeste dos EUA 3 | Leste dos EUA | |
| Emirados Árabes Unidos | Norte dos EAU | EAU Central* |
| Departamento de Defesa dos EUA | DoD do Leste dos EUA* | DoD Central dos EUA* |
| Governo dos EUA | Governo dos EUA do Arizona* | Governo dos EUA do Texas* |
| Governo dos EUA de Virgínia* | Governo dos EUA do Texas* | |
| Governo dos EUA do Texas* | Governo dos EUA de Virgínia* |
(*) Certas regiões têm acesso restrito para dar 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
- Oeste da Índia está emparelhado em uma direção apenas. A região secundária do Oeste da Índia é 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 está emparelhado bidirecionalmente com o Oeste dos EUA.
- O Sul do Brasil é exclusivo porque ele está associado a uma região fora de sua região geográfica. A região secundária do Sul do Brasil é o Centro-Sul dos EUA. A região secundária do Centro-Sul dos EUA não é Sul do Brasil.
Regiões com zonas de disponibilidade e nenhum par de regiões
O Azure continua a expandir-se globalmente em regiões sem um par regional e alcança alta disponibilidade aproveitando zonas de disponibilidade e armazenamento localmente redundante ou com redundância de zona (LRS/ZRS). Regiões sem um par não terão GRS (armazenamento com redundância geográfica). Essas regiões seguem diretrizes de residência de dados para permitir a opção de manter os dados residentes na mesma região. Os clientes são responsáveis pela resiliência dos 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 do mundo. No caso raro de uma região inteira do Azure estar indisponível, os clientes terão de planear a sua recuperação de desastres entre regiões de acordo com as orientações dos serviços Azure que suportam alta disponibilidade e Resiliência 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 | Region |
|---|---|
| Qatar | Catar Central |
| Polônia | Polônia Central |
| Israel | Israel Central |
| Itália | Norte da Itália |
| Áustria | Leste da Áustria (em breve) |
| Espanha | Espanha Central (em breve) |