Como você faz corretamente a recuperação de desastres para um servidor de arquivos?

4

No momento, estamos trabalhando na implementação de uma estratégia de DR para um servidor de arquivos do Windows. Excluímos a Replicação de Armazenamento porque é um recurso de visualização, e o Cluster de Failover é projetado para alta disponibilidade, não DR. O DFSR também tem deficiências na replicação de arquivos abertos / bloqueados, tornando-o útil para a tarefa.

A replicação de SAN para SAN da VM do servidor de arquivos parece ser o melhor método para mim, embora tenha sido alertada contra isso devido ao fato de que a replicação é uma cópia bruta que não é reunida em um nível mais alto, possivelmente causando inconsistências no sistema de arquivos ou arquivos corrompidos. No entanto, esse fato é verdadeiro para qualquer servidor replicado nesse método, e esse é o método que está sendo usado para outros servidores em nosso plano de DR. Versões VSS / anteriores sempre podem ser usadas para restaurar arquivos corrompidos.

Os benefícios de se fazer a replicação SAN superam o risco de os arquivos estarem corrompidos? Ou existe um método melhor de fazer DR para um servidor de arquivos? Talvez exista um produto que realize uma replicação / instantâneo de nível superior que minimize as inconsistências lógicas nos dados?

Nota: o cluster está executando o vSphere 5.5

    
por Bigbio2002 30.12.2014 / 18:32

5 respostas

7

A replicação de SAN para SAN é a sua melhor opção para colocar o servidor de arquivos on-line o mais rápido possível, com um pouco de perda após declarar um desastre. Observe que esse tipo de proteção contra DR não protege das mesmas coisas que os backups locais; você não pode usar um volume SAN replicado para, por exemplo, desfazer a exclusão de um arquivo do mês anterior.

Os arquivos corrompidos não são um perigo de replicação de SAN para SAN, a menos que seja o servidor de arquivos no site principal que os corrompe. Cada SAN que fornece replicação de armazenamento baseado em blocos (LUNs) tem algum mecanismo para impedir a corrupção e garantir a consistência. É um problema mais complicado do que a maioria das pessoas sabe, porque as gravações costumam ser aplicadas ao disco fora de ordem, mesmo sem replicação, por motivos de otimização. É por isso que o cache de gravação para a maioria dos armazenamentos possui algum tipo de rede de segurança contra falhas de energia (como uma bateria ou um no-break): sem as gravações salvas apenas no cache, o disco subjacente provavelmente está corrompido. Normalmente, tudo bem, no entanto, se você perder a energia, é necessário garantir que a última gravação reconhecida pelo armazenamento seja salva no disco para tornar o disco consistente quando for exibido.

A replicação trata isso de forma diferente, dependendo de como você está replicando:

  • A replicação síncrona garante a consistência porque não retornará uma confirmação de gravação para o servidor local até obter confirmação de que a gravação foi feita com segurança para o site secundário. Isso retarda as gravações consideravelmente, e nenhum fornecedor suporta fazer isso em nada menos que uma conexão estelar de distância relativamente baixa. Na verdade, a distância suportada é geralmente tão baixa que você fica vulnerável aos mesmos furacões. É raro ver e geralmente não é a única coisa no lugar.
  • Replicação de ponto de verificação assíncrona é de longe o algoritmo mais comumente visto, usado pela grande maioria do armazenamento de sistema aberto. Periodicamente, a caixa replicará um ponto de verificação consistente, o que significa que garantirá que a cópia recuperável encontrada no sistema remoto não tenha gravações ausentes. Se for interrompido no meio de um checkpoint, ele será descartado e irá para o último ponto consistente conhecido. Eu vi sistemas que, desde que sua WAN suporte, você pode ter um ponto de recuperação de 15 segundos usando este método.
  • A replicação de entrega assíncrona por ordem é mais rara e difícil de fazer do que o ponto de verificação, mas na minha opinião é o melhor em termos de algoritmos de assincronização. O que ele faz é enviar as gravações pela WAN na ordem em que são feitas. O problema é que, ao contrário da replicação de ponto de verificação, se isso ficar para trás, o armazenamento usado para manter as gravações não enviadas não pode ser liberado sem exigir uma ressincronização completa (reenviando todos os dados). Geralmente, se o link não conseguir acompanhar as gravações, ele voltará ao modo de ponto de verificação e começará a fazer a entrega por ordem novamente assim que tiver um ponto de verificação recente. O ponto de recuperação da EMC e o HUR da Hitachi fazem isso, no entanto, não vi outros fornecedores configurados dessa maneira.

Todos esses mecanismos fornecem "consistência de falhas". O disco está no mesmo estado em que ficaria se você desligasse o computador abruptamente. Demora um pouco de trabalho para obter sistemas de arquivos e bancos de dados em execução a partir de uma cópia consistente, mas é sempre factível. Se você quiser algo mais (que "nível mais alto" você menciona na pergunta), você precisa integrar sua replicação com seus aplicativos. Isso normalmente significa pausar gravações no aplicativo, aguardar até que tudo tenha sido destinado ao armazenamento e, em seguida, iniciar um ponto de consistência para replicação. Isso é chamado de "consistência de aplicativo". Ele geralmente fornecerá um ponto de recuperação um pouco mais antigo, mas um tempo de recuperação um pouco menor do que a consistência de falhas.

    
por 30.12.2014 / 20:33
1

Você precisa estar preparado para vários níveis e tipos de desastres, incluindo uma total invasão maliciosa (hackers) e uma perda total de todo o hardware (clima épico). Isso exigirá o descarregamento de alguns dados para os métodos de distribuição sneaker-net (leia isso, armazenamento externo como fitas / unidades de disco rígido), alguma forma de solução única de gravação ou um serviço de backup online (caro). p>

A recuperação de desastre é uma fera diferente da replicação simples. Você precisa determinar isso antes de decidir qualquer coisa: " Quantos dados eu posso perder? " Não pense em termos de Gigabytes, pense em termos de TIME . Posso perder 4 horas de dados, posso perder um dia? O método escolhido dependerá da sua resposta a essa pergunta. Todos nós queremos uma solução que tenha perda zero, mas que geralmente não é um investimento viável para o risco que está sendo mitigado. Você também precisará manter cópias de seus backups mensais / anuais por um bom tempo, pois você também pode ter desastres (os usuários excluem porcarias de que precisam) que você não conhece há muito tempo.

    
por 30.12.2014 / 18:50
1

A replicação de SAN para SAN é a maneira mais rápida de recuperar um desastre do site, mas vivi uma corrupção de SAN em minha vida de TI devido a um bug de firmware e ele pode ficar feio

Você se esquece de escrever o hipervisor que você usa. Mas sugiro com a replicação SAN o produto vReplicator se você usar o ESX. Isso é replicado a cada 15minutos por padrão e sua VM remota está pronta para se levantar. O vReplicator precisa de uma licença do vCenter e de um host físico para manter a VM replicada (pode custar menos do que outra SAN, mas, como a @IceMage disse, depende de quanto tempo você pode perder)

    
por 30.12.2014 / 20:58
0

Sugiro usar o Veeam para a baixa replicação de RPO das máquinas virtuais de servidores de arquivos. Ele é compatível com VSS e pode ser usado para replicar localmente e para destinos de WAN e de nuvem, com vários pontos de retenção.

Configure estalos de 15 minutos, navios por hora ou diários fora do local. É bastante robusto pelo custo.

Se você tiver um Hypervisor remoto, poderá configurar um run-book parcial que exibe uma VM replicada com as configurações apropriadas de rede e IP.

    
por 30.12.2014 / 21:04
0

A Veeam e outros produtos de backup que usam instantâneos vão contra as práticas recomendadas da VMware para não executá-los com frequência. Isso deixará os servidores de joelhos e quase não responderá. Imagine 50 servidores fazendo 15 minutos instantâneos, 1.200 instantâneos em um dia? Difícil de gerir, muito armazenamento. Uma tecnologia CDP como Zerto resolve isso para VMware e Hyper-V.

    
por 26.09.2018 / 18:46