Início/ Trilha 5/ Conteúdo/ Tópico 4
4

Arquitetura MAA - Maximum Availability Architecture

Best practices, combinando RAC + Data Guard + ASM

📖

Definição

O que é MAA?

Maximum Availability Architecture (MAA) é o framework de best practices da Oracle para design, implementação e operação de arquiteturas altamente disponíveis. Combina tecnologias Oracle (RAC, Data Guard, ASM, Flashback, GoldenGate) com processos operacionais para eliminar downtime e minimizar perda de dados.

Objetivos MAA:

  • RTO (Recovery Time Objective): Tempo máximo de downtime aceitável (meta: minutos)
  • RPO (Recovery Point Objective): Perda de dados aceitável (meta: zero)
  • Disponibilidade 99.99%+: Menos de 1 hora de downtime por ano
  • Proteção contra falhas: Hardware, software, site, humanas
  • Manutenção online: Patches, upgrades sem parar aplicação
  • Continuidade de negócio: Disaster recovery geográfico

Arquitetura MAA Típica

┌─────────────────────────────────────────────────────────────┐
│                   DATACENTER PRIMÁRIO                       │
│                                                             │
│   ┌─────────────────────────────────────┐                  │
│   │     Oracle RAC (2+ nós)             │                  │
│   │  ┌─────────┐      ┌─────────┐      │                  │
│   │  │ Nó 1    │      │ Nó 2    │      │                  │
│   │  │ Inst 1  │◄────►│ Inst 2  │      │  Interconnect   │
│   │  └────┬────┘      └────┬────┘      │  (Cache Fusion) │
│   └───────┼────────────────┼───────────┘                  │
│           │                │                               │
│           └────────┬───────┘                               │
│                    │                                        │
│           ┌────────▼────────┐                              │
│           │  ASM Storage    │                              │
│           │  (Redundância)  │                              │
│           └────────┬────────┘                              │
│                    │ Redo Transport (SYNC/ASYNC)           │
└────────────────────┼─────────────────────────────────────────┘
                     │
                     ▼ Network (Dedicated/WAN)
┌─────────────────────────────────────────────────────────────┐
│                 DATACENTER STANDBY (DR)                     │
│                                                             │
│   ┌─────────────────────────────────────┐                  │
│   │  Data Guard Standby (Physical)      │                  │
│   │  Opcional: RAC Standby (2+ nós)     │                  │
│   │  ┌─────────┐      ┌─────────┐      │                  │
│   │  │ Nó 1    │      │ Nó 2    │      │                  │
│   │  │ Inst 1  │◄────►│ Inst 2  │      │  Active Data    │
│   │  └────┬────┘      └────┬────┘      │  Guard (leitura)│
│   └───────┼────────────────┼───────────┘                  │
│           │                │                               │
│           └────────┬───────┘                               │
│                    │                                        │
│           ┌────────▼────────┐                              │
│           │  ASM Storage    │                              │
│           │  (Redundância)  │                              │
│           └─────────────────┘                              │
└─────────────────────────────────────────────────────────────┘
          

Camadas de Proteção

  • Local HA: RAC protege contra falha de servidor
  • Storage: ASM redundância + storage RAID
  • DR Remoto: Data Guard em site separado
  • Backup: RMAN para FRA e storage secundário

Tecnologias Chave

  • RAC: Escala e HA local
  • ASM: Storage resiliente e simplificado
  • Data Guard: Proteção contra desastres
  • Flashback: Recuperação de erros lógicos

Níveis de Disponibilidade MAA

Bronze (99.9%)

~9h downtime/ano

Single instance + RMAN backup. Sem redundância. RTO: horas, RPO: minutos-horas. Adequado para ambientes não-críticos.

Silver (99.95%)

~4h downtime/ano

Data Guard physical standby + RMAN. RTO: 1-2 horas, RPO: < 1 hora. Proteção DR básica, boa para maioria dos ambientes.

Gold (99.99%)

~1h downtime/ano

RAC primário + Data Guard standby + ASM. RTO: 5-30 minutos, RPO: zero (SYNC). Recomendado para ambientes críticos de produção.

Platinum (99.995%)

< 30min downtime/ano

RAC primário + RAC standby + ASM + Active Data Guard + Fast-Start Failover + GoldenGate. RTO: < 5 minutos, RPO: zero. Para aplicações mission-critical (bancos, bolsas).

🛠️

Aplicação Prática

Best Practices MAA

1. Redundância em Todas as Camadas

  • Múltiplos servidores (RAC), múltiplos disks (ASM), múltiplos sites (DG)
  • Redes redundantes: interconnect, public network, redo transport
  • Power supplies, switches, storage controllers duplicados
  • Sem pontos únicos de falha (SPOF) em toda stack

2. Automação e Orquestração

  • Fast-Start Failover automático com Data Guard Observer
  • Application Continuity para replay de transações após failover
  • Connection pooling com detecção rápida de falhas (FAN events)
  • Scripts de recovery e runbooks documentados e testados

3. Monitoramento Proativo

  • Enterprise Manager (OEM) para monitoramento centralizado
  • Alertas automáticos para degradação antes de falhas
  • Dashboards de RTO/RPO, lag de replicação, performance
  • Health checks regulares e predição de falhas

4. Testes Regulares

  • Switchover planejado trimestral para validar DR
  • Testes de failover não-planejado (chaos engineering)
  • Validação de backups com restore completo
  • Simulações de desastres e war games com equipe

Configuração MAA Gold (Exemplo)

-- Arquitetura Gold: 2-node RAC Primary + 1-node Standby

-- PRIMARY SITE (RAC 2 nós)
-- Disk Groups ASM:
--   DATA (NORMAL redundancy): datafiles, control files
--   FRA (NORMAL redundancy): archive logs, backups
--   REDO (EXTERNAL redundancy): redo logs em storage de alta performance

-- Parâmetros críticos no PRIMARY:
ALTER SYSTEM SET cluster_database=TRUE SCOPE=SPFILE;
ALTER SYSTEM SET log_archive_dest_1='LOCATION=+FRA VALID_FOR=(ALL_LOGFILES,ALL_ROLES)';
ALTER SYSTEM SET log_archive_dest_2='SERVICE=standbydb SYNC AFFIRM VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=standbydb';
ALTER SYSTEM SET log_archive_dest_state_2=ENABLE;
ALTER SYSTEM SET log_archive_max_processes=8;
ALTER SYSTEM SET db_flashback_retention_target=4320; -- 3 dias
ALTER DATABASE FLASHBACK ON;

-- STANDBY SITE (single instance ou RAC)
-- Configuração Data Guard Broker
CREATE CONFIGURATION maa_dg AS PRIMARY DATABASE IS proddb CONNECT IDENTIFIER IS proddb_scan;
ADD DATABASE standbydb AS CONNECT IDENTIFIER IS standbydb MAINTAINED AS PHYSICAL;
ENABLE CONFIGURATION;

-- Habilitar Fast-Start Failover
ENABLE FAST_START FAILOVER CONDITION "Corrupted Controlfile";
ENABLE FAST_START FAILOVER CONDITION "Corrupted Dictionary";
ENABLE FAST_START FAILOVER CONDITION "Datafile Offline";
SET FAST_START FAILOVER THRESHOLD TO 30; -- segundos

-- Configurar Active Data Guard (read-only queries no standby)
-- Requer licença Active Data Guard
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
ALTER DATABASE OPEN READ ONLY;
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT;

-- Criar service para queries no standby
BEGIN
  DBMS_SERVICE.CREATE_SERVICE(
    service_name => 'REPORT_SERVICE',
    network_name => 'REPORT_SERVICE'
  );
  DBMS_SERVICE.START_SERVICE(service_name => 'REPORT_SERVICE');
END;
/

Checklist de Implementação MAA

Definir requisitos RTO/RPO com stakeholders de negócio
Escolher tier MAA apropriado (Bronze/Silver/Gold/Platinum)
Implementar RAC primário com mínimo 2 nós
Configurar ASM com redundância apropriada
Criar Data Guard standby em datacenter remoto
Configurar Fast-Start Failover com Observer
Implementar monitoramento com OEM ou similar
Habilitar Flashback Database para recovery rápido
Configurar backups RMAN incrementais para FRA
Documentar runbooks de switchover e failover
Executar testes de DR trimestrais
Treinar equipe em procedimentos de recovery

Resultado Esperado

O que você deve dominar:

Projetar arquiteturas MAA

Combinar RAC, DG, ASM apropriadamente

Calcular RTO/RPO

Alinhar tecnologia com requisitos de negócio

Eliminar SPOFs

Identificar e mitigar pontos únicos de falha

Implementar automação

Fast-Start Failover, Application Continuity

Executar DR tests

Validar procedimentos regularmente

Atingir 99.99%+ uptime

Entregar disponibilidade tier Gold/Platinum

Parabéns! Você completou a Trilha 5

Você agora domina as tecnologias de alta disponibilidade Oracle e está preparado para projetar, implementar e operar ambientes mission-critical com disponibilidade 24/7.

Anterior: Data Guard Voltar ao Índice