Quando começamos a estudar computação em nuvem, alguns conceitos parecem bastante simples: escolhemos uma região, criamos nossos recursos e começamos a trabalhar.
O problema aparece quando entramos em assuntos como alta disponibilidade, tolerância a falhas e Disaster Recovery.
Na Oracle Cloud Infrastructure (OCI) encontramos termos como Region, Availability Domain e Fault Domain. Na AWS aparecem Region e Availability Zone. O Microsoft Azure também trabalha com Regions e Availability Zones, enquanto no Google Cloud encontramos Regions e Zones.
À primeira vista, parece apenas uma diferença de nomenclatura.
Mas não é tão simples.
Entender essas estruturas significa entender uma questão fundamental:
Contra quais tipos de falha a sua arquitetura realmente está protegida?
E, para nós profissionais de banco de dados, esse assunto fica ainda mais interessante quando começamos a relacioná-lo com tecnologias como Oracle RAC e Oracle Data Guard.
Antes de comparar as Clouds, precisamos entender o conceito de domínio de falha
Imagine que você tenha duas máquinas virtuais executando uma aplicação crítica.
Você poderia pensar:
“Tenho dois servidores. Portanto, tenho alta disponibilidade.”
Mas e se os dois servidores estiverem no mesmo rack?
Uma falha de energia naquele rack pode derrubar os dois.
Então você os coloca em racks diferentes.
Melhoramos a arquitetura.
Mas e se os dois racks dependerem do mesmo conjunto de switches ou da mesma infraestrutura elétrica?
Ainda temos um ponto comum de falha.
Podemos continuar ampliando esse raciocínio:
Servidor → Rack → Infraestrutura → Datacenter → Zona → Região
Quanto maior o evento contra o qual queremos nos proteger, maior precisa ser a separação entre os componentes da nossa arquitetura.
É justamente aí que entram Regions, Availability Zones, Availability Domains e Fault Domains.
Oracle Cloud Infrastructure: Region, Availability Domain e Fault Domain
Na Oracle Cloud Infrastructure, uma Region é uma área geográfica localizada.
Dentro de uma região existem um ou mais Availability Domains, também conhecidos como ADs.
Um Availability Domain é composto por um ou mais data centers. Os ADs de uma mesma região são isolados entre si e não compartilham elementos críticos como energia, refrigeração ou a rede interna do próprio Availability Domain.
A hierarquia básica da OCI pode ser representada assim:
Region → Availability Domain → Fault Domain → Recursos
Existe ainda um nível particularmente interessante na OCI: o Fault Domain.
Um Fault Domain é um agrupamento de hardware e infraestrutura dentro de um Availability Domain.
Cada Availability Domain da OCI contém três Fault Domains.
A ideia é fornecer antiafinidade. Ao distribuir instâncias por Fault Domains diferentes, reduzimos a possibilidade de uma falha de hardware ou uma manutenção de infraestrutura afetar simultaneamente todos os componentes da aplicação.
E como isso funciona no Brasil?
Um detalhe importante para quem trabalha no Brasil é que a região Brazil East — São Paulo (sa-saopaulo-1) possui atualmente um Availability Domain.
Portanto, dentro dessa região, os Fault Domains assumem um papel particularmente importante na distribuição dos recursos.
Isso também demonstra por que não devemos imaginar que toda região OCI necessariamente possui três Availability Domains. Algumas regiões possuem múltiplos ADs, enquanto muitas regiões possuem apenas um.
AWS: Region e Availability Zone
Na Amazon Web Services (AWS) temos uma estrutura semelhante, mas não idêntica:
Region → Availability Zone → Recursos
Uma AWS Region é uma área geográfica separada das demais regiões.
Cada região possui múltiplas Availability Zones, conhecidas como AZs.
Uma Availability Zone consiste em um ou mais data centers distintos, com infraestrutura redundante de energia, rede e conectividade.
As Availability Zones dentro da mesma região são conectadas por redes de alta largura de banda e baixa latência, mas são fisicamente separadas para reduzir o risco de uma única falha afetar várias zonas.
AWS São Paulo
No Brasil temos a região:
sa-east-1
Ela possui atualmente três identificadores de Availability Zones:
sae1-az1
sae1-az2
sae1-az3
Portanto, uma aplicação distribuída entre várias AZs possui um nível de isolamento maior do que uma aplicação cujos componentes permanecem dentro de uma única Availability Zone.
Microsoft Azure: Region e Availability Zone
No Microsoft Azure também encontramos:
Region → Availability Zone → Recursos
Uma região Azure representa um perímetro geográfico contendo um conjunto de data centers.
Nas regiões que suportam Availability Zones, essas zonas representam grupos separados de data centers com infraestrutura independente de energia, refrigeração e rede.
O objetivo é permitir que uma falha em uma zona não necessariamente interrompa os serviços executados nas demais.
Entretanto, existe um detalhe importante:
nem todas as regiões e nem todos os serviços Azure suportam Availability Zones da mesma forma.
Isso significa que, ao desenhar uma arquitetura, não basta saber que o Azure possui zonas.
Precisamos verificar se o serviço que pretendemos utilizar suporta implantação zonal ou redundância entre zonas naquela região específica.
Azure no Brasil
No Brasil, a região Brazil South, localizada no estado de São Paulo, possui suporte a Availability Zones.
O Azure possui também o conceito de Region Pairs, ou regiões emparelhadas.
Entretanto, esse conceito merece cuidado: nem todas as regiões possuem necessariamente um par e arquiteturas resilientes podem envolver diferentes estratégias de distribuição regional.
Portanto:
Region Pair não deve ser tratado simplesmente como “mais uma Availability Zone”.
Estamos falando de outro nível de proteção.
Google Cloud: Region e Zone
No Google Cloud Platform (GCP) a estrutura básica é:
Region → Zone → Recursos
Uma Region é uma área geográfica independente composta por zonas.
Uma Zone é uma área de implantação dentro da região e deve ser considerada um domínio de falha independente.
Para aumentar a disponibilidade, aplicações podem ser distribuídas entre múltiplas zonas. Quando precisamos considerar também uma eventual indisponibilidade regional, a arquitetura pode envolver múltiplas regiões.
Google Cloud São Paulo
Na região de São Paulo temos:
southamerica-east1
e três zonas:
southamerica-east1-a
southamerica-east1-b
southamerica-east1-c
Novamente, o conceito é semelhante ao encontrado na AWS e no Azure: recursos distribuídos por zonas diferentes não compartilham exatamente o mesmo domínio de falha.
Availability Domain, Availability Zone e Zone são a mesma coisa?
Conceitualmente, esses recursos procuram resolver problemas semelhantes.
Mas afirmar simplesmente:
OCI Availability Domain = AWS Availability Zone = Azure Availability Zone = Google Cloud Zone
é uma simplificação perigosa.
Os provedores utilizam modelos físicos e lógicos diferentes, e determinados serviços podem implementar disponibilidade de maneiras específicas.
A comparação mais segura é pensar em camadas de isolamento de falhas, e não apenas traduzir nomes.
| Provedor | Região | Isolamento dentro da região | Subdivisão adicional exposta |
|---|---|---|---|
| Oracle OCI | Region | Availability Domain | Fault Domain |
| AWS | Region | Availability Zone | Não há equivalente direto ao Fault Domain da OCI |
| Microsoft Azure | Region | Availability Zone | Depende do serviço |
| Google Cloud | Region | Zone | Depende do serviço |
O ponto central não é decorar os nomes.
O ponto central é perguntar:
Se este componente falhar, os meus outros componentes dependem da mesma infraestrutura?
Alta disponibilidade não é a mesma coisa que Disaster Recovery
Aqui chegamos a uma distinção extremamente importante.
Imagine uma aplicação distribuída por três zonas dentro da mesma região.
Ela pode suportar uma falha de uma zona.
Excelente.
Mas todas as três continuam dentro da mesma região.
Se ocorrer um evento capaz de tornar toda aquela região indisponível, a arquitetura pode continuar vulnerável.
É por isso que precisamos separar dois conceitos.
Alta disponibilidade busca manter o serviço funcionando diante de falhas de componentes ou de parte da infraestrutura.
Disaster Recovery (DR) considera eventos de impacto maior e pode exigir recursos em outra região geográfica.
É justamente aqui que Oracle RAC e Oracle Data Guard ajudam a tornar essa discussão muito concreta para um DBA.
Onde entra o Oracle RAC?
O Oracle Real Application Clusters (Oracle RAC) permite que múltiplas instâncias executadas em diferentes nós acessem simultaneamente o mesmo banco de dados.
Se um servidor do cluster falhar, as instâncias sobreviventes podem continuar oferecendo acesso ao banco.
Além da disponibilidade, o RAC também oferece escalabilidade ao permitir que múltiplos servidores processem carga para o mesmo banco de dados.
Podemos representar conceitualmente:
Oracle Database
↳ RAC Instance 1 — Node 1
↳ RAC Instance 2 — Node 2
Ambas acessando o mesmo banco de dados em armazenamento compartilhado.
Do ponto de vista do nosso assunto, surge então uma pergunta muito importante:
Em quais domínios de falha esses nós estão implantados?
Se dois nós de um cluster estiverem sujeitos exatamente ao mesmo domínio físico de falha, parte do benefício arquitetural pode ser desperdiçada.
Por isso, quando implementamos Oracle RAC em uma infraestrutura Cloud, precisamos conhecer a topologia suportada pelo serviço e como os nós são distribuídos fisicamente.
RAC é extremamente eficiente para proteger o banco contra falhas de servidor, instância e componentes do cluster dentro da arquitetura suportada.
Mas existe outra pergunta:
E se perdermos o ambiente inteiro onde está o RAC?
É aí que entra o Oracle Data Guard.
Onde entra o Oracle Data Guard?
O Oracle Data Guard mantém uma ou mais bases standby sincronizadas com o banco primário por meio do transporte e aplicação de redo.
Uma configuração pode possuir um banco primário e um ou mais bancos standby.
Tanto o banco primário quanto os bancos standby podem utilizar single instance ou Oracle RAC.
Isso nos permite construir arquiteturas em outro nível de proteção.
Imagine:
REGIÃO A
Oracle RAC
Instance 1 + Instance 2
Banco de Dados Primário
↓
Oracle Data Guard
↓
REGIÃO B
Oracle Database Standby
ou outro Oracle RAC
Agora não estamos protegendo apenas contra a perda de um servidor.
Estamos criando uma arquitetura capaz de considerar a indisponibilidade de um ambiente muito maior.
O Data Guard foi desenvolvido justamente para alta disponibilidade, proteção de dados e Disaster Recovery.
Oracle RAC e Data Guard não competem — eles se complementam
Esse é um ponto que costuma gerar confusão.
Oracle RAC e Oracle Data Guard resolvem problemas diferentes.
Podemos imaginar a arquitetura em camadas:
Falha de servidor ou instância
→ Oracle RAC
Falha de componentes dentro da infraestrutura local
→ Distribuição adequada entre domínios de falha
Falha de zona ou domínio de disponibilidade
→ Arquitetura distribuída quando suportada
Falha regional ou desastre de maior alcance
→ Oracle Data Guard para outro local ou região
Isso é muito diferente de simplesmente afirmar:
“Minha aplicação está na Cloud, portanto ela é altamente disponível.”
Cloud não elimina a necessidade de arquitetura.
Ela nos oferece componentes para construí-la.
O caso brasileiro mostra bem essas diferenças
Quando observamos São Paulo nos quatro provedores, as diferenças ficam bastante visíveis.
Na OCI Brazil East, temos atualmente um Availability Domain e três Fault Domains dentro dele.
Na AWS São Paulo (sa-east-1), temos três Availability Zones.
No Azure Brazil South, existem Availability Zones e a região está localizada no estado de São Paulo.
No Google Cloud São Paulo (southamerica-east1), encontramos as zonas a, b e c.
Isso demonstra claramente por que simplesmente transportar uma arquitetura de um provedor para outro e trocar os nomes dos componentes pode gerar problemas.
Precisamos compreender o domínio de falha real que cada camada representa.
A pergunta que deve orientar sua arquitetura
Quando projetamos alta disponibilidade, talvez a pergunta mais importante não seja:
“Quantos servidores eu tenho?”
Nem:
“Estou usando duas zonas?”
A pergunta mais útil é:
Contra qual falha quero estar protegido?
Uma falha de VM?
Um host físico?
Um rack?
Uma infraestrutura compartilhada?
Uma zona?
Um Availability Domain?
Uma região inteira?
Uma corrupção de banco de dados?
Uma falha humana?
Um desastre geográfico?
Somente depois de responder essas perguntas é que podemos decidir quantas instâncias, zonas, regiões, clusters RAC, bancos standby ou outros componentes serão necessários.
Conclusão
OCI, AWS, Azure e Google Cloud utilizam terminologias diferentes, mas todas precisam resolver o mesmo problema fundamental:
Como distribuir infraestrutura para impedir que uma única falha derrube todo o ambiente?
Na OCI encontramos Regions, Availability Domains e Fault Domains.
Na AWS, Regions e Availability Zones.
No Azure, Regions e Availability Zones, além de conceitos como Region Pairs em determinados cenários.
No Google Cloud, Regions e Zones.
Porém, entender apenas os nomes é insuficiente.
Precisamos compreender os limites dos domínios de falha.
Para um DBA Oracle, isso se conecta diretamente ao desenho da camada de banco de dados.
O Oracle RAC pode eliminar o servidor ou a instância como ponto único de falha, além de fornecer escalabilidade.
O Oracle Data Guard pode levar a proteção para outro banco e outro ambiente, inclusive outro local ou região, fornecendo alta disponibilidade, proteção de dados e Disaster Recovery.
E é exatamente por isso que conhecer a infraestrutura da Cloud deixou de ser conhecimento exclusivo do administrador de infraestrutura.
Hoje, para desenhar bancos de dados realmente resilientes, o DBA também precisa saber onde seus servidores estão e quais falhas podem atingir todos eles ao mesmo tempo.
No final, tudo volta à mesma pergunta:
Contra qual tipo de falha a sua arquitetura realmente está protegida?
Referências oficiais
Oracle Cloud Infrastructure
- Oracle Cloud Infrastructure — Regions and Availability Domains
- Oracle Database — Introduction to Oracle RAC
- Oracle Database — Oracle Data Guard
Amazon Web Services
- AWS Global Infrastructure — Regions and Availability Zones
Microsoft Azure
- Azure Reliability — Regions and Availability Zones
- Azure Reliability — Paired and Unpaired Regions
Google Cloud
- Google Cloud — Regions and Zones
- Google Cloud — Geographic Distribution and Reliability