Arquitetura HADR para plataformas de banco de dados: RTO, RPO, SQL Server, PaaS e soluções híbridas
Converta objetivos de recuperação do negócio em designs de alta disponibilidade e recuperação de desastre para SQL Server em Máquinas Virtuais do Azure, serviços SQL do Azure e ambientes híbridos.
Tempo de estudo sugerido: 82 minutos • Nível intermediário • Reescrita autoral completa com resumo conciso de cada tópico
Por João Ricardo Dutra••Conteúdo autoral completo
1. HADR começa pelos requisitos, não por um produto
Alta disponibilidade e recuperação de desastre (HADR) para uma plataforma de banco de dados formam uma estratégia arquitetônica, não uma opção isolada. Antes de escolher recursos do SQL Server ou do , determine o tempo de interrupção tolerado, os dados que podem ser perdidos, a abrangência da falha que deve ser suportada e quem operará a resposta.
Um recurso pode ser tecnicamente válido e ainda assim descumprir o objetivo do negócio. O design precisa conectar metas de recuperação, dependências do aplicativo, proteção de dados, comportamento do , rede e validação periódica.
Resumo do tópico
Comece pelos requisitos de recuperação e pelo escopo da falha; escolha a tecnologia somente depois de tornar o estado desejado mensurável.
2. O RTO limita a duração aceitável da indisponibilidade
O objetivo de tempo de recuperação (RTO) é o prazo máximo para recolocar um recurso ou a solução em operação após uma interrupção. Ultrapassá-lo pode impedir o trabalho, violar um compromisso de serviço, gerar prejuízo ou multas.
Registre RTOs por componente e para o fluxo completo. Se o SQL Server voltar em cinco minutos, mas os servidores do aplicativo levarem 20 minutos, o usuário espera 20 minutos; a dependência crítica mais lenta determina o tempo efetivo.
Resumo do tópico
O RTO responde por quanto tempo o serviço pode permanecer indisponível e deve considerar toda a cadeia de dependências.
3. O RPO limita a perda de dados aceitável
O objetivo de ponto de recuperação (RPO) define o ponto mais recente aceitável para a recuperação e, portanto, a idade máxima dos dados que podem ser perdidos. Se a falha ocorrer às 10h e o RPO for 15 minutos, a recuperação precisa alcançar 9h45 ou um momento posterior.
RPO é uma meta de dados, não uma promessa implícita no nome do produto. Atraso de replicação, frequência do backup do de transações, tempo de cópia, comportamento da restauração, intensidade da carga e consistência do ponto de recuperação determinam se a meta é viável.
O RPO olha para trás, até o ponto de dados aceitável; o RTO olha para frente, até o prazo para restaurar o serviço.
Resumo do tópico
O RPO responde até que ponto os dados podem retroceder; todos os intervalos de proteção e transferência precisam caber nesse orçamento de perda.
4. Defina as metas por negociação entre negócio e tecnologia
Tempo de inatividade zero e perda de dados zero são desejáveis, mas com frequência são caros ou inviáveis. Responsáveis pelo negócio, aplicativo, banco de dados, infraestrutura, segurança e finanças devem concordar com as metas usando os mesmos fatos.
Quantifique o custo da inatividade e o impacto de transações perdidas.
Dimensione o investimento em HADR de acordo com a perda evitada.
Inclua habilidade operacional, automação, cobertura de suporte e tempo das dependências.
Documente as metas de cada componente crítico e da solução inteira.
Revise-as periodicamente conforme a carga e o impacto do negócio mudarem.
Resumo do tópico
RTO e RPO são requisitos de serviço negociados e sustentados por custo, risco, capacidade operacional e evidências das dependências.
5. Agendamentos de proteção e testes precisam sustentar as metas
Uma política pode contradizer seu objetivo. Backup do a cada 30 minutos não atende de forma confiável a um RPO de 15 minutos, e um backup que leva três horas para ser copiado não cabe em um caminho de recuperação de duas horas. Frequência, largura de banda, automação e capacidade devem ser suficientes.
Backups e réplicas só têm valor quando podem ser recuperados. Ensaie planejado e não planejado, restauração, , reconexão do cliente e recuperação das dependências; registre os RTOs e RPOs observados.
Resumo do tópico
Alinhe os intervalos e tempos de transferência às metas e depois comprove o resultado em exercícios recorrentes.
6. Alta disponibilidade e recuperação de desastre exigem metas distintas
Escopos de disponibilidade e resposta esperada.
Dimensão
Alta disponibilidade
Recuperação de desastre
Falha típica
Evento localizado de nó, processo, host, rack ou zona
Perda de região, , site ou dependência ampla
Recuperação
rápido para réplica ou nó local já ativo
Ativação de outro local e recuperação de todas as dependências
Escala de tempo
Segundos ou minutos
Minutos, horas ou mais
Objetivo
Manter continuidade local
Restabelecer o serviço após evento amplo
Um design pode contribuir para os dois escopos, mas HA local não equivale a DR regional. Documente RTO e RPO independentes.
Resumo do tópico
HA trata interrupções localizadas; DR restaura o serviço após falhas mais amplas, portanto cada um precisa de metas e testes próprios.
7. e dividem controle e responsabilidade de formas diferentes
do é : sistema operacional e instância ficam expostos, permitindo combinar recursos do mecanismo, , armazenamento, rede e plataforma. A flexibilidade aumenta a responsabilidade operacional.
e são . A Microsoft opera os nós e oferece um conjunto menor de controles de disponibilidade e recuperação. O design enfatiza configuração do serviço, resiliência do cliente e topologia regional.
Resumo do tópico
oferece controle máximo com mais responsabilidade; incorpora a recuperação da infraestrutura e expõe opções gerenciadas.
8. Proteções no nível da instância e do banco abrangem objetos diferentes
Escopo de proteção do SQL Server.
Recurso
Unidade protegida
Consequência
Instância de de (FCI)
Instância inteira do SQL Server
Bancos e objetos da instância movem juntos, mas exigem armazenamento compartilhado
Grupo de disponibilidade (AG)
Bancos de dados selecionados
Cada réplica guarda uma cópia; objetos da instância exigem sincronização separada
Envio de
Bancos de dados selecionados
Backup, cópia e restauração protegem dados; abstração do servidor e objetos externos são manuais
Logons, trabalhos do SQL Server Agent, servidores vinculados e outros objetos externos ao banco protegido não acompanham automaticamente uma proteção no nível do banco. Inclua-os nos runbooks de implantação e .
Resumo do tópico
Conheça a unidade protegida: tecnologias no nível do banco não reproduzem automaticamente tudo o que a instância precisa.
9. Grupos de disponibilidade e FCIs dependem de um
No Windows Server, AGs e FCIs usam o WSFC ( de do Windows Server); no Linux, o gerenciador comum é o Pacemaker. Quorum e posicionamento da testemunha fazem parte do design, sobretudo entre locais.
Os Serviços de Domínio Active Directory e o precisam estar acessíveis onde identidades e resolução de nomes do Windows dependerem deles. Uma topologia regional ou híbrida exige mais do que réplicas SQL.
Resumo do tópico
Saúde do , quorum, testemunhas, diretório e são dependências de primeira classe em HADR.
10. Uma FCI protege toda a instalação
A FCI é criada na instalação do SQL Server; uma instância autônoma existente não pode ser simplesmente convertida. Ela recebe nome e endereço de rede diferentes dos nós e do . Os clientes usam essa identidade estável. Em um design tradicional de sub-rede única no , um balanceador de carga interno ajuda a encaminhar conexões ao nó ativo.
No , toda a instância para e inicia em outro nó. As sessões caem, os bancos executam recuperação, transações incompletas sofrem e clientes resilientes reconectam. Como a cópia do banco é compartilhada, os dados confirmados permanecem consistentes.
Resumo do tópico
O de FCI reinicia a instância completa em outro nó por trás de uma identidade estável e protege o estado da instância.
11. O armazenamento compartilhado da FCI habilita e concentra risco
Todos os nós precisam acessar o mesmo armazenamento. Opções arquitetônicas podem incluir compartilhamentos de arquivos Premium do , iSCSI, Shared Disk, Spaces Direct ou uma solução compatível como SIOS DataKeeper. A escolha altera latência, quorum, suporte, custo e comportamento de falha.
Uma cópia reduz multiplicação de armazenamento, mas cria uma dependência. A Standard Edition aceita no máximo dois nós em FCI. A Réplica de do Windows Server pode estender alguns designs para DR; envio de ou AG também pode proteger a FCI em outro local.
Resumo do tópico
FCIs simplificam a proteção da instância, mas exigem arquitetura de e armazenamento compartilhado cuidadosamente compatível.
12. Grupos de disponibilidade protegem cópias independentes
Um AG possui réplica primária de leitura/gravação e réplicas secundárias que recebem alterações do . A movimentação pode ser síncrona, para perda mínima, ou assíncrona, quando distância e latência tornam o modo síncrono inadequado. Um ouvinte oferece destino estável ao aplicativo.
A Standard Edition oferece AG básico de um banco e até duas réplicas. A Enterprise Edition permite vários bancos e até nove réplicas, inclusive secundárias legíveis para relatórios, backups e verificações. A inicialização usa backup ou propagação automática.
Resumo do tópico
AGs replicam bancos selecionados em cópias independentes e usam um ouvinte para desacoplar o cliente da réplica primária atual.
13. AGs trocam custo de armazenamento por flexibilidade
Cada réplica guarda sua cópia, portanto AGs dispensam armazenamento compartilhado e costumam efetuar mais rápido que FCIs, mas o consumo cresce. Cinco réplicas de um banco de 1 TB demandam aproximadamente 5 TB, sem contar sobrecargas.
A nova réplica primária ainda precisa de logons, trabalhos, servidores vinculados e credenciais sincronizados. Autenticação do Windows, bancos independentes, infraestrutura como código e sincronização controlada reduzem a lacuna.
Resumo do tópico
AGs removem o armazenamento compartilhado e adicionam réplicas úteis, mas multiplicam o espaço e exigem tratar dependências da instância.
14. O envio de é um padrão simples de espera passiva
O envio de começa com backup completo restaurado na secundária em STANDBY ou NORECOVERY. Trabalhos agendados fazem backup do da primária, copiam o arquivo e o restauram na secundária. A sequência é simples e tolera redes menos estáveis.
Geralmente atende DR, não HA instantânea. Uma ativação não planejada pode perder transações posteriores ao último aplicado, e não há ouvinte nativo. Alias ou outra técnica de rede pode reduzir a mudança de nome.
Resumo do tópico
O envio de oferece DR econômico no nível do banco por backup, cópia e restauração, com intervalo de perda mensurável e ativação manual.
15. Conjuntos de disponibilidade reduzem falhas correlacionadas de host
Um conjunto de disponibilidade aplica antiafinidade e distribui VMs por domínios de falha e de atualização. Domínios de falha separam limites de energia e rede; domínios de atualização separam grupos que o pode reiniciar juntos em manutenção. O módulo representa até três domínios de falha em um .
Conjuntos de disponibilidade separam VMs por domínios de falha e atualização em um .
Resumo do tópico
Conjuntos de disponibilidade protegem réplicas de VM contra eventos correlacionados de hardware e manutenção em um .
16. O posicionamento da plataforma não corrige falhas dentro do convidado
Conjuntos e zonas de disponibilidade não entendem transações do SQL Server nem recuperam falha do sistema operacional ou do mecanismo. Combine o posicionamento com AG, FCI, envio de , backup ou outra proteção consciente da carga.
Em aplicativo multicamada, isole cada camada apropriadamente: web, banco e VMs de , por exemplo. Uma VM não pode pertencer simultaneamente a conjunto e zona de disponibilidade.
Resumo do tópico
O posicionamento limita o raio de impacto da infraestrutura; falhas do convidado e dos dados ainda exigem proteção consciente da carga.
17. Zonas de disponibilidade protegem contra falha do
Uma zona é um local físico separado dentro de uma região compatível. Distribuir réplicas pelas zonas 1, 2 e 3 pode suportar a perda de um . Os números são lógicos por assinatura; “zona 1” de dois clientes não prova colocalização.
A distância pode adicionar latência. Teste a carga antes de assumir que a confirmação síncrona atenderá ao desempenho; a latência de ida e volta costuma ficar abaixo de um milissegundo, mas o caminho real decide. O também pode usar redundância de zona.
Resumo do tópico
Zonas ampliam o isolamento para o , mas a latência deve ser validada contra a replicação síncrona e o desempenho.
18. replica a VM, não o protocolo do banco
replica continuamente uma VM entre regiões e orquestra e . Ele protege várias cargas e é útil quando uma recuperação centrada na VM atende às metas.
O serviço não interpreta limites transacionais do SQL Server. A VM pode cumprir o RTO enquanto o ponto dos dados descumpre o RPO. O material fornecido citava RTO mensal de duas horas; a documentação atual do informa de RTO de uma hora para o de VM. Trate números publicados como dados sujeitos a atualização e valide o caminho completo.
Resumo do tópico
Site Recovery fornece recuperação regional da VM; consistência do banco e RPO ainda exigem validação consciente da carga.
19. O inclui alta disponibilidade local
O oferece de 99,99% em configurações compatíveis e de nó incorporado. Transações confirmadas são persistidas de modo síncrono. Se um nó falhar, o serviço cria ou ativa outro nó de computação e conecta o armazenamento.
Conexões e transações em andamento podem ser interrompidas. Aplicativos de nuvem precisam de novas tentativas limitadas, operações idempotentes quando cabível e tratamento de para falhas transitórias.
Resumo do tópico
O oculta a substituição do nó, mas o aplicativo ainda precisa tolerar conexões interrompidas e falhas transitórias.
20. Replicação geográfica e grupos de tratam o DR regional em
O aceita replicação geográfica ativa, enquanto grupos de coordenam bancos no ou na . Réplicas legíveis podem descarregar relatórios e manter uma cópia regional.
O ouvinte do grupo de preserva de leitura/gravação e somente leitura durante a troca. Região, atraso, política de , dependências do aplicativo e ainda fazem parte do design.
Resumo do tópico
Use replicação geográfica ativa ou grupos de para estender a recuperação do entre regiões com gerenciável.
21. A Recuperação Acelerada de Banco de Dados reduz o tempo do mecanismo
e não expõem estados como OFFLINE ou EMERGENCY do mesmo modo que o SQL Server autogerenciado. O opera o serviço; RESTRICTED_USER e conexão de administrador dedicada permanecem onde compatíveis.
A ADR (Recuperação Acelerada de Banco de Dados) usa repositório persistente de versões e truncamento agressivo do para tornar de transações longas e recuperação mais previsíveis. Ela fica habilitada por padrão nesses serviços.
Resumo do tópico
A ADR reduz a penalidade de recuperação de transações longas e reforça o modelo de disponibilidade do serviço gerenciado.
22. Controles gerenciados de consistência complementam a redundância
O mantém cópias e backups locais e regionais, valida a integridade de backup e restauração e detecta leituras obsoletas ou gravações perdidas. CHECKSUM fica habilitado, DBCC CHECKDB pode rodar sem reparo e o reparo automático de página é tentado quando possível.
A plataforma pode corrigir sem notificação quando não há impacto e notificar proativamente quando existe impacto. Isso reduz risco, mas não elimina validação do aplicativo e exercícios de recuperação.
Resumo do tópico
Redundância, integridade, reparo de páginas e alertas trabalham juntos para proteger a consistência nos serviços SQL gerenciados.
23. Um AG de região única é um design comum de HA
VMs SQL Server primária e secundária podem ocupar limites de falha separados, participar do WSFC e ser expostas por um ouvinte de AG. Cópias independentes protegem os dados e permitem manutenção planejada com troca controlada.
Um AG regional combina posicionamento de VM com replicação no nível do banco.
Várias cópias reduzem a falha de um único armazenamento.
Confirmação síncrona pode oferecer perda mínima ou nula de dados confirmados.
O ouvinte padroniza o acesso.
Não há armazenamento de banco compartilhado.
Resumo do tópico
AG regional é um padrão forte quando o banco exige cópias independentes, rápido e ouvinte estável.
24. Uma FCI regional favorece a integridade da instância
Uma FCI em duas VMs pode usar Spaces Direct ou outra opção compatível, WSFC, rede virtual e infraestrutura de roteamento. Ela continua útil quando proteção da instância inteira é mais importante que cópias independentes.
A FCI mantém uma cópia compartilhada e move a instância inteira entre nós.
Aplicativos usam uma identidade de instância em .
Manutenção pode mover o serviço entre nós.
Muitas metas de HA são atendidas, mas não há DR regional isoladamente.
compartilhado e suporte são pontos críticos.
Resumo do tópico
Escolha FCI quando continuidade da instância e uma cópia compartilhada servirem à carga e adicione mecanismo separado de DR.
25. Um AG multirregional ou híbrido pode fornecer HA e DR
Um AG tradicional pode abranger regiões ou conectar ambiente local ao enquanto todas as réplicas permanecem em um WSFC. O padrão se assemelha a um AG entre dois datacenters e funciona nas edições Standard e Enterprise dentro de seus limites.
O AG estendido usa um e um grupo de disponibilidade entre regiões ou ambientes híbridos.
Conectividade, quorum, testemunha, e em todos os locais são essenciais. Uma partição de rede pode transformar o estendido no principal ponto de risco.
Resumo do tópico
AG estendido pode cobrir HA e DR com um recurso, mas o e suas dependências entre locais precisam permanecer saudáveis.
26. Um AG distribuído separa domínios de falha do
Um grupo de disponibilidade distribuído, introduzido no SQL Server 2016 Enterprise Edition, une dois AGs independentes. A primária global envia alterações ao encaminhador, que também é primário do segundo AG e sincroniza sua secundária local.
Um AG distribuído é um AG de AGs e separa quorum e testemunha por local.
Cada mantém quorum e testemunha. A sincronização é distribuída, o design funciona somente no ou de modo híbrido e o pode ser planejado sem um WSFC único entre sites.
Resumo do tópico
AGs distribuídos isolam os domínios de e quorum e estendem a replicação da Enterprise Edition entre locais.
27. O envio de continua sendo uma arquitetura prática de DR
O servidor primário cria backups de , um trabalho os transfere por um compartilhamento e trabalhos de restauração os aplicam a uma ou mais esperas passivas. Um servidor monitor acompanha estado e histórico.
O envio de é um padrão de DR desacoplado baseado em backup e restauração nativos.
Possui longa história operacional e administração simples.
Tolera redes inadequadas à replicação síncrona.
Frequência e atraso de restauração tornam o RPO explícito.
Pode proteger uma FCI em outro local.
Resumo do tópico
Envio de é adequado quando simplicidade, tolerância de rede e RPO diferente de zero são aceitáveis.
28. Site Recovery é uma alternativa ampla de DR no nível da VM
Para equipes que não desejam topologia específica do SQL Server, Site Recovery pode orquestrar a VM inteira e outras cargas compatíveis. Ele integra a plataforma e pode atender quando RTO e RPO medidos se ajustam ao seu comportamento.
Site Recovery protege a camada de máquina virtual entre regiões e complementa o planejamento da carga.
Especialistas de dados costumam preferir replicação centrada no banco para RPO menor e mais explícito. Decida pelos objetivos testados.
Resumo do tópico
Site Recovery é atraente para recuperação ampla da VM; designs centrados no banco podem oferecer ponto transacional mais preciso.
29. HADR híbrido ultrapassa o limite de uma nuvem
Solução híbrida distribui recursos entre e ambiente local ou outra nuvem pública. HADR híbrido tradicional é principalmente porque recursos do SQL Server podem abranger esses locais. normalmente expõe padrões gerenciados dentro do .
Uma exceção é replicação transacional de um publicador local ou externo para uma assinante, mas não no sentido inverso. O híbrido pode apoiar migração, porém é usado sobretudo para ter o como destino de DR.
Resumo do tópico
HADR híbrido geralmente usa o como local de recuperação para um ambiente existente, com exceções limitadas de integração .
30. A rede determina se as metas híbridas são críveis
Uma réplica de AG no também depende de diretório, , roteamento, segurança e acesso operacional. Banda insuficiente ou latência instável amplia o atraso e inviabiliza RTO e RPO.
oferece conectividade privada e previsível quando justificado. Caso contrário, use site a site protegida pelo para estender a rede privada. Não exponha VMs de banco diretamente à internet pública.
O do também pode receber backups como destino de recuperação ou arquivo frio, mesmo sem outra topologia híbrida ativa.
Resumo do tópico
Modele banda, latência, roteamento, identidade e segurança no caminho de recuperação; a réplica híbrida depende de sua conectividade.
31. Verificação de conhecimento
Teste seu entendimento antes das respostas.
Pergunta
Opções
O que o RPO descreve?
A. Número de nós · B. Ponto até o qual os dados devem ser recuperados · C. Restauração parcial
O que torna uma solução híbrida?
A. mais ambiente local ou outra nuvem · B. Dois mecanismos de banco · C. Duas versões do SQL Server
O que está disponível após no nível do banco?
A. Todos os objetos da instância · B. Bancos e trabalhos · C. Conteúdo protegido dos bancos; objetos externos exigem tratamento
Respostas e justificativas
1 — B. RPO é o ponto aceitável e a janela de perda.
2 — A. Híbrido descreve limites de localização, não mistura de software.
3 — C. Recursos de banco protegem seu conteúdo e alterações registradas; objetos da instância exigem outro processo.
Resumo do tópico
Guarde as distinções: RPO trata dados, híbrido trata locais e proteção do banco exclui objetos externos.
32. Construa uma decisão HADR defensável
Documente RTO/RPO independentes de HA e DR para o aplicativo e suas dependências.
Escolha ou entendendo controle e responsabilidade compartilhada.
Associe proteção de instância ou banco aos objetos que precisam sobreviver.
Combine proteção SQL consciente da carga e isolamento de falhas do .
Escolha escopo local, zonal, regional ou híbrido conforme os cenários de falha.
Projete , novas tentativas, quorum, testemunhas, identidade, , roteamento e capacidade.
Automatize e ensaie , restauração e , comparando resultados às metas.
Reavalie custo, risco e metas quando a carga ou impacto mudar.
Resumo do tópico
Uma arquitetura HADR sólida relaciona cada produto a um cenário de falha, meta mensurável, mapa completo de dependências e evidência testada.
