Replicação entre regiões no Azure: Continuidade do negócio e recuperação após desastre
Muitas organizações requerem elevada disponibilidade fornecida por zonas de disponibilidade que também são suportadas com proteção contra fenómenos em larga escala e desastres regionais. As regiões do Azure foram concebidas para oferecer proteção contra desastres locais com zonas de disponibilidade. Mas também podem fornecer proteção contra desastres geográficos regionais ou de grandes dimensões com recuperação após desastre ao utilizar outra região que utiliza a replicação entre regiões.
Replicação entre regiões
Para garantir que os clientes são suportados em todo o mundo, o Azure mantém várias geografias. Estas demarcações discretas definem um limite de residência de dados e recuperação após desastre 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ócio e recuperação após desastre do Azure. A replicação entre regiões baseia-se na replicação síncrona das suas aplicações e dados que existem através da utilização de zonas de disponibilidade na região principal do Azure para elevada disponibilidade. A replicação entre regiões replica de forma assíncrona as mesmas aplicações e dados noutras regiões do Azure para proteção contra recuperação após desastre.
Alguns serviços do Azure tiram partido da replicação entre regiões para garantir a continuidade do negócio e proteger contra a 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 georredundante (GRS) do Azure replica automaticamente os dados para uma região secundária. Esta abordagem garante que os dados são duráveis mesmo que a região primária não seja recuperável.
Nem todos os serviços do Azure replicam automaticamente os dados ou revertem automaticamente de uma região com falha para a replicação cruzada para outra região ativada. Nestes cenários, a recuperação e a replicação têm de ser configuradas pelo cliente. Estes exemplos são ilustrações do modelo de responsabilidade partilhada. É um pilar fundamental na sua estratégia de recuperação após desastre. Para obter mais informações sobre o modelo de responsabilidade partilhada e para saber mais sobre a continuidade do negócio e a recuperação após desastre no Azure, veja Gestão da continuidade de negócio no Azure.
A responsabilidade partilhada torna-se o cerne da sua tomada de decisão estratégica no que diz respeito à recuperação após desastre. O Azure não requer que utilize a replicação entre regiões e pode utilizar serviços para criar resiliência sem efetuar a replicação cruzada para outra região ativada. Mas recomendamos vivamente que configure os seus serviços essenciais entre regiões para beneficiar do isolamento e melhorar a disponibilidade.
Para aplicações que suportam várias regiões ativas, recomendamos que utilize várias regiões ativadas disponíveis. Esta prática garante a disponibilidade ideal para as aplicações e o tempo de recuperação minimizado se um evento afetar a disponibilidade. Sempre que possível, crie a sua aplicação para obter a máxima resiliência e facilidade de recuperação após desastre.
Benefícios da replicação entre regiões
A arquitetura da replicação entre regiões para os seus serviços e dados pode ser decidida por serviço. Terá necessariamente uma abordagem de análise custo-benefício com base nos requisitos estratégicos e empresariais da sua organização. Os benefícios primários e ondulados da replicação entre regiões são complexos, extensos e merecem elaboração. As vantagens incluem:
- Sequência de recuperação de regiões: se ocorrer uma falha em toda a geografia, a recuperação de uma região é priorizada a partir de cada conjunto de regiões ativado. É garantido que as aplicações implementadas em conjuntos de regiões ativadas têm uma das regiões priorizadas para a recuperação. Se uma aplicação for implementada entre regiões, qualquer uma das quais não está ativada para replicação entre regiões, a recuperação pode ser adiada.
- Atualização sequencial: as atualizações planeadas do sistema do Azure para as regiões ativadas são escalonadas cronologicamente para minimizar o tempo de inatividade, o impacto de erros e quaisquer falhas lógicas em caso raro de uma atualização com falhas.
- Isolamento físico: o Azure esforça-se por garantir uma distância mínima de 483 quilómetros entre datacenters em regiões ativadas, embora não seja possível em todas as geografias. A separação do datacenter reduz a probabilidade de desastres naturais, agitação civil, falhas de energia ou falhas de rede física poderem afetar várias regiões. O isolamento está sujeito às restrições numa geografia, como o tamanho geográfico, a disponibilidade da infraestrutura de energia ou de rede e os regulamentos.
- Residência dos dados: as regiões residem na mesma geografia que o conjunto ativado (exceto o Sul do Brasil e Singapura) para cumprir os requisitos de residência dos dados para efeitos de jurisdição fiscal e de aplicação da lei.
Apesar de não ser possível criar os seus próprios emparelhamentos regionais, pode, no entanto, criar a sua própria solução de recuperação após desastre ao criar os seus serviços em várias regiões e, em seguida, utilizar os serviços do Azure para os emparelhar. Por exemplo, pode utilizar serviços do Azure, como o AzCopy , para agendar cópias de segurança de dados para uma conta de Armazenamento do Azure numa região diferente. Com o DNS do Azure e o Gestor de Tráfego do Azure, pode conceber uma arquitetura resiliente para as suas aplicações que sobreviverá à perda da região primária.
O Azure controla a atribuição de prioridades de manutenção e recuperação planeada para pares regionais. Alguns serviços do Azure dependem de pares regionais por predefinição, como o armazenamento redundante do Azure.
Não está limitado à utilização de serviços nos pares regionais. Embora um serviço do Azure possa depender de um par regional específico, pode alojar os seus outros serviços em qualquer região que satisfaça as suas necessidades empresariais. Por exemplo, uma solução de armazenamento GRS do Azure pode emparelhar dados no Canadá Central com um elemento da rede no Leste do Canadá ao utilizar recursos de Computação do Azure localizados nos E.U.A. Leste.
Emparelhamentos de replicação entre regiões do Azure para todas as geografias
As regiões são emparelhadas para replicação entre regiões com base na proximidade e noutros fatores.
Pares regionais do Azure
| Geografia | Par regional A | Par regional B |
|---|---|---|
| Asia-Pacific | Ásia Oriental (Hong Kong) | Sudeste Asiático (Singapura) |
| Austrália | Leste da Austrália | Austrália Sudeste |
| Austrália | Austrália Central | Austrália Central 2* |
| Brasil | Sul do Brasil | E.U.A. Centro-Sul |
| Brasil | Brasil Sudeste* | Sul do Brasil |
| Canadá | Canadá Central | Leste do Canadá |
| China | Norte da China | Leste da China |
| China | Norte da China 2 | Leste da China 2 |
| China | Norte da China 3 | Leste da China 3* |
| Europa | Europa do Norte (Irlanda) | Europa Ocidental (Países Baixos) |
| França | França Central | Sul da França* |
| Alemanha | Alemanha Centro-Oeste | Norte da Alemanha* |
| Índia | Índia Central | Sul da Índia |
| Índia | Oeste da Índia | Sul da Índia |
| Japão | Leste do Japão | Oeste do Japão |
| Coreia | Coreia do Sul Central | Coreia do Sul* |
| América do Norte | E.U.A. Leste | E.U.A. Oeste |
| América do Norte | E.U.A. Leste 2 | E.U.A. Central |
| América do Norte | E.U.A. Centro-Norte | E.U.A. Centro-Sul |
| América do Norte | E.U.A. Oeste 2 | E.U.A. Centro-Oeste |
| América do Norte | EUA Oeste 3 | E.U.A. Leste |
| 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 | Suécia Sul* |
| Suíça | Norte da Suíça | Oeste da Suíça* |
| REINO UNIDO | Oeste do Reino Unido | Sul do Reino Unido |
| Emirados Árabes Unidos | Norte dos E.A.U. | UAE Central* |
| Departamento de Defesa dos EUA | E.U.A. Leste* | US DoD Central* |
| Governo dos Estados Unidos | US Gov Arizona* | US Gov Texas* |
| Governo dos Estados Unidos | US Gov Iowa* | US Gov Virginia* |
| Governo dos Estados Unidos | US Gov Virginia* | US Gov Texas* |
(*) Determinadas regiões têm acesso restrito para suportar cenários específicos de clientes, como a recuperação após desastre no país. Estas regiões só estão disponíveis mediante pedido através da criação de um novo pedido de suporte.
Importante
- A Índia Ocidental está emparelhada apenas numa direcção. A região secundária da Índia Ocidental é a Índia do Sul, mas a região secundária da Índia do Sul é a Índia Central.
- O Sul do Brasil é exclusivo porque está emparelhado com uma região fora da sua geografia. A região secundária do Sul do Brasil é e.U.A. Centro-Sul. A região secundária dos E.U.A. Centro-Sul 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 com o Qatar como a primeira região sem par regional e obtém elevada disponibilidade ao tirar partido das zonas de disponibilidade e do armazenamento localmente redundante ou com redundância entre zonas (LRS/ZRS). As regiões sem par não terão armazenamento georredundante (GRS). Estas regiões seguem as diretrizes de residência dos dados , permitindo 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 nas necessidades de Objetivo de Ponto de Recuperação ou Objetivo de Tempo de Recuperação (RTO/RPO) e podem mover, copiar ou aceder aos respetivos dados a partir de qualquer localização globalmente. No caso raro de toda uma região do Azure estar indisponível, os clientes terão de planear a recuperação após desastre entre regiões por orientação dos serviços do Azure que suportam elevada disponibilidade e Resiliência do Azure – Continuidade de Negócio e Recuperação Após Desastre