Alta Disponibilidade e Recuperação de Desastres
  • 7 minutos de leitura
  • Tema escuro
    Tema claro
  • Pdf

Alta Disponibilidade e Recuperação de Desastres

  • Tema escuro
    Tema claro
  • Pdf

Article Summary

A arquitetura do senhasegura é projetada para garantir Alta Disponibilidade (HA) e Recuperação de Desastres (DR) eficazes, em caso de falhas.

Info

Você pode implementar o senhasegura das seguintes formas:

Princípios da Alta Disponibilidade

  • Eliminação de Pontos Únicos de Falha (SPOF): redundâncias são incorporadas para manter a operação contínua mesmo em caso de falha de um componente.
  • Cruzamento confiável: sistemas redundantes devem ser capazes de mudar entre componentes sem perda de dados ou impacto no desempenho.
  • Detecção de falha em tempo real: mesmo com redundâncias, é essencial detectar falhas assim que ocorrerem.

Tecnologias de replicação

CamadaDescrição
Replicação nativa do banco de dadosO senhasegura usa o MariaDB Galera Cluster para replicar bancos de dados e oferecer suporte a redes de alta latência (até 30ms de latência).
Replicação de arquivos do sistema utilizando RsyncTodas as instâncias do senhasegura sincronizam seus arquivos com os demais membros do cluster.
Replicação da camada do kernel*O modelo de implantação PAM Crypto Appliance também inclui um DRBD.

*Somente disponível para o PAM Crypto Appliance

Arquiteturas

Existem quatro cenários para a arquitetura de Recuperação de Desastres. Você pode ter dois Virtual Appliances, dois PAM Crypto Appliances (com DRBD), uma arquitetura híbrida ou on-premise. Você encontra mais informações sobre esses cenários na tabela abaixo.

CenárioDescrição
Dois Virtual AppliancesO Failover é executado manualmente, com replicação síncrona automática. Em caso de falha, o ambiente de backup fornece acesso somente de leitura até a conclusão do failover.
Dois PAM Crypto Appliances (com uso de DRBD)Os dispositivos se conectam via cabos de sincronização e usam uma conexão heartbeat para detectar falhas. Quando necessário, o dispositivo em espera assume a função principal automaticamente em até 120 segundos. Se o PAM Crypto Appliance foi desligado devido a uma falha temporária, ele restaurará a função de dispositivo primário. Se, em vez disso, o problema foi causado por hardware com defeito, você terá que reatribuir o dispositivo principal manualmente.
Híbrido: PAM Crypto Appliance e Virtual Appliance combinadosO Failover é executado manualmente, com replicação síncrona automática. Em caso de falha, o ambiente de backup fornece acesso somente de leitura até a conclusão do failover.
Instâncias on-premise e em nuvem combinadasO Failover é executado manualmente, com replicação síncrona automática. Em caso de falha, o ambiente de backup fornece acesso somente de leitura até a conclusão do failover.

Cenários

Info

Na descrição dos cenários, cada membro representa uma instância no senhasegura.

Dois membros sem um árbitro

CenárioTipoStatus da aplicaçãoFailoverRessincronização automática
1Membro 2 falha.Disponível (Membro 1).Automático.Disponível.
2Membro 1 falha.Disponível (Membro 2).Manual.Disponível.
3Falha de conexão (entre sites).Disponível (Membro 1).Automático.Disponível
4Membros 1 e 2 falham.Não disponível.Não disponível.Não disponível.

Exemplos

Cenário 1: Membro 2 falha

  • Status da aplicação: a aplicação continua a ser executada no primeiro membro.
  • Failover: automático.
  • Recuperação de membros indisponíveis: realizada de forma automática quando a instância é reinicializada ou a conectividade é recuperada.

Cenário 2: Membro 1 falha

  • Status da aplicação: a aplicação continua a ser executada no segundo membro.
  • Failover: manual.
  • Recuperação de membros indisponíveis: realizada de forma automática quando a instância é reinicializada ou a conectividade é recuperada.

Cenário 3: Falha de conexão (entre sites)

  • Status da aplicação: a aplicação continua a ser executada no primeiro membro.
  • Failover: automático.
  • Recuperação de membros indisponíveis: realizada de forma automática quando a instância recupera a conectividade.

Cenário 4: Falha nos membros 1 e 2

  • Status da aplicação: aplicação indisponível.
  • Failover: não disponível.
  • Recuperação de falha de membro: entre em contato com a equipe de suporte do senhasegura para restaurar os membros.
  • Se todos os membros falharem simultaneamente, use a chave mestra e faça o procedimento de backup de credenciais.

Dois membros com um árbitro

CenárioTipoStatus da aplicaçãoFailoverRessincronização automática
1Membro 2 falha.Disponível (membro 1).Automático.Disponível.
2Membro 1 falha.Disponível (membro 2).Automático.Disponível.
3Falha de conexão entre sites com membros.Disponível no membro com conectividade com o árbitro.Automático.Disponível.
4Os membros 1 e 2 falham.Não disponível.Não disponível.Não disponível.
5Falha no árbitro.Disponível (ambos membros).Automático.Disponível.
6Falha no árbitro e em qualquer outro membro.Disponível no membro funcional.Manual.Disponível no membro funcional.

Exemplos

Cenário 1: Membro 2 falha

  • Status da aplicação: a aplicação continua a ser executada no primeiro membro.
  • Failover: automático.
  • Recuperação de falha de membro: realizada de forma automática quando a instância é reinicializada ou a conectividade é recuperada.

Cenário 2: Membro 1 falha

  • Status da aplicação: a aplicação continua a ser executada no segundo membro.
  • Failover: automático.
  • Recuperação de falha de membro: realizada de forma automática quando a instância é reinicializada ou a conectividade é recuperada.

Cenário 3: Falha de conexão (entre sites que tem os membros)

  • Status da aplicação: a aplicação continua a ser executada no membro que tem conectividade com o árbitro.
  • Failover: automático.
  • Recuperação de falha de membro: realizada de forma automática quando a instância é reinicializada ou a conectividade é recuperada.

Cenário 4: Membros 1 e 2 falham

  • Status da aplicação: aplicação indisponível.
  • Failover: não disponível.
  • Recuperação de falha de membro: entre em contato com a equipe de suporte do senhasegura para restaurar os membros.
  • Se todos os membros falharem simultaneamente, use a chave mestra e o procedimento de backup de credencial.

Cenário 5: Falha no árbitro

  • Status da aplicação: a aplicação fica disponível para ambos os membros do senhasegura.
  • Failover: automático.
  • Recuperação de falha de membro: realizada de forma automática quando a instância é reinicializada ou a conectividade é recuperada.

Cenário 6 - Falha no árbitro e em qualquer outro membro

  • Status da aplicação: a aplicação continua a ser executada no membro funcional.
  • Failover: manual.
  • Recuperação de falha de membro: realizada de forma automática quando a instância é reinicializada ou a conectividade é recuperada.
  • Se todos os membros falharem simultaneamente, use a chave mestra e o procedimento de backup de credencial.

Três membros

CenárioTipoStatus da aplicaçãoFailoverRessincronização automática
1Membro 2 falhaDisponível (Membros 1 e 3)AutomáticoDisponível
2Membro 1 falhaDisponível (Membros 2 e 3)AutomáticoDisponível
3Membro 3 falhaDisponível (Membros 1 e 2)AutomáticoDisponível
4Falha de conexão com um membroDisponível (todos os outros membros)AutomáticoDisponível
5Falha de conexão (entre todos os membros)Disponível (membro 1)ManualNão disponível
6Todos os membros falhamNão disponívelNão disponívelNão disponível

Exemplos

Cenário 1 - Membro 2 falha

  • Status da aplicação: a aplicação continua a ser executada nos membros 1 e 3.
  • Failover: automático
  • Recuperação de falha de membro: realizada de forma automática quando a instância é reinicializada ou a conectividade é recuperada.

Cenário 2 - Membro 1 falha

  • Status da aplicação: a aplicação continua a ser executada nos membros 2 e 3.
  • Failover: automático
  • Recuperação de falha de membro: realizada de forma automática quando a instância é reinicializada ou a conectividade é recuperada.

Cenário 3 - Membro 3 falha

  • Status da aplicação: a aplicação continua a ser executada nos membros 1 e 2
  • Failover: automático
  • Recuperação de falha de membro: realizada de forma automática quando a instância é reinicializada ou a conectividade é recuperada.

Cenário 4 - Falha de conexão com um membro

  • Status da aplicação: a aplicação continua a ser executada nos membros ainda conectados ao cluster.
  • Failover: automático.
  • Recuperação de falha de membro: realizada de forma automática quando a instância é reinicializada ou a conectividade é recuperada.

Cenário 5 - Falha na conexão (entre todos os membros)

  • Status da aplicação: a aplicação continua a ser executada no primeiro membro.
  • Failover: manual
  • Recuperação de falha de membro: realizada de forma automática quando a instância é reinicializada ou a conectividade é recuperada.

Cenário 6 - Falha de todos os membros

  • Status da aplicação: aplicação indisponível.
  • Failover: não disponível.
  • Recuperação de falha de membro: não disponível. Entre em contato com a equipe de suporte do senhasegura para restaurar esses membros.
  • Se todos os membros falharem simultaneamente, use a chave mestra e o procedimento de backup de credencial.

Recuperação de Desastres

A Recuperação de Desastres (DR) é um conjunto estruturado de políticas e procedimentos para recuperar dados ou restaurar a infraestrutura do senhasegura em situações de desastres naturais ou lógicos. A DR oferece aos clientes a capacidade de reconfigurar os recursos do senhasegura utilizando um ambiente alternativo quando a recuperação do ambiente primário for impraticável.

A integridade dos dados durante uma DR é diretamente impactada pela qualidade e velocidade da conexão, bem como pela quantidade de dados presente no cluster. Se qualquer uma dessas variáveis não atender aos requisitos específicos, pode resultar em perda de dados, desativação do ambiente de produção e ativação do ambiente de DR.

Importante

Em casos de falhas causadas por problemas de hardware, é necessária uma intervenção manual para reiniciar e recuperar o sistema.

Recursos de hot-spare

As instâncias do senhasegura são equipadas com recursos de hot-spare para manter a alta disponibilidade do sistema. Estes recursos incluem monitoramento contínuo e URLs administrativas para supervisionar o status operacional de cada instância.

O uso desses recursos de hot-spare proporciona uma capacidade automática de alternância entre instâncias, garantindo que, em caso de falha, as cargas de trabalho sejam redirecionadas eficientemente para instâncias operacionais

Balanceador de carga interno

Ao implementar o senhasegura, você tem a flexibilidade de escolher entre o uso de um software do tipo balanceador de carga proprietário ou integrar o balanceador de carga nativo do senhasegura ao seu ambiente em cluster.


Este artigo foi útil?