Alta Disponibilidade e Recuperação de Desastres – Combinando ambas para continuação do negócio

Olá pessoal,

 

Hoje gostaria de discutir com vocês um plano de HADR (alta disponibilidade + Recuperação de desastres).

 

Garantir a continuidade dos negócios em caso de falta de energia, desastres naturais ou equipamentos falha, é importante considerar sua estratégia de alta disponibilidade (HA) e recuperação de desastre (DR). O HA minimiza as chances de uma interrupção do equipamento com defeito ou falha no serviço, enquanto o DR é o seu plano para se levantar e correr após um desastre.

 

Desenvolver uma estratégia de HA e DR pode ser um desafio. O SQL Server da Microsoft, como a maioria dos principais bancos de dados, oferece várias opções possíveis de HA / DR, mas você escolherá os requisitos de recuperação da sua empresa e os detalhes da sua infraestrutura de TI, bem como a edição do SQL Server. A Microsoft fornece um gráfico de comparação abrangente dos recursos de alta disponibilidade das edições do SQL Server aqui.

Lembrando que em caso de dúvida, problemas, suporte, consultoria acesse:  SRTech Soluções

Este será uma combinação de cluster + Always ON com 2 secundários.

 

Benefícios da configuração de cluster

  • N nodos configurados e prontos para executarem/rodarem sua app. Possui um Nome e IP que irá direcionar para o nodo ativo.
  • Redundância de hardware – em nível de servidor
  • Storage possui suas redundâncias de hardware e raid, além de possuir maior performance de I/O se comparada com discos locais.
  • Maior poder de processamento
  • Maior poder de escalabilidade
  • Gerenciamento de equipes e bancos, podendo haver bancos diferentes ativos em cada nodo, afim de dissipar o processamento entre os nodos

 

Link para criar/configurar um cluster no windows

 

Benefícios do Always On

  • Mesmos benefícios do Mirror
  • + poder de leitura do banco espelhado (recebendo modificados/secundário)
  • + pode-se executar backups no nodo secundário
  • + pode-se espelhar os dados para mais servidores/locais

 

link para criar/configurar Always On

 

Para este cenário teremos no DC local um cluster de N nodos conectados a uma storage provendo toda disponibilidade e performance do BD necessário. No mesmo DC, porém em outra storage teremos um outro servidor (de performance similar/igual/melhor a um nodo do cluster) sendo uma réplica (secundária ‘secondary’) síncrona da primária (bases principais rodando no cluster). Por ser síncrona, toda alteração executada no primário é replicado para este secundário e apenas após a alteração/informação estar salva em ambos locais é que o usuário recebe o OK da transação ter finalizado com sucesso ou não.

Obs. Necessita de ótima comunicação entre ambientes (primário e secundário – recomendo fibra ou rede 1gb exclusiva para sincronização)

 

Agora em outro DC ou até em ambientes cloud, pode-se configurar uma segunda réplica (secundária/secondary) com sincronização assíncrona, a qual nos serve como DR em caso de qualquer pane/problema no DC principal.

 

Com uma solução dessas podemos garantir 100% de disponibilidade do negócio.

 

Em breve, teremos mais post’s!!

Abraço,

Henrique Ribeiro

 

Anúncios

Deixe uma Resposta

Preencha os seus detalhes abaixo ou clique num ícone para iniciar sessão:

Logótipo da WordPress.com

Está a comentar usando a sua conta WordPress.com Terminar Sessão /  Alterar )

Google photo

Está a comentar usando a sua conta Google Terminar Sessão /  Alterar )

Imagem do Twitter

Está a comentar usando a sua conta Twitter Terminar Sessão /  Alterar )

Facebook photo

Está a comentar usando a sua conta Facebook Terminar Sessão /  Alterar )

Connecting to %s