Uma ferramenta simples de replicação de volume para um grande conjunto de dados?

Question

Estou procurando uma solução para o seguinte:

Servidor A (Site A)  - Win 2008 R2  - aproximadamente 10TB (15TB máx.) de dados  - bem mais de 8 milhões de arquivos

Servidor B (Site B)  - Win 2008 R2

Eu quero replicar de forma assíncrona o volume do Servidor A para um volume no Servidor B para redundância de dados. Algo que eu posso dizer aos meus usuários, "vá aqui para os dados" quando / se o servidor A for interrompido devido a problemas com a máquina, desastre, etc.

O Windows 2008 R2 tem DFS, mas a Microsoft aparentemente não suporta este grande conjunto de dados (ou, mais precisamente, mais de 8 milhões de arquivos - de acordo com os documentos que eu encontrei).

Também consultei o Veritas Volume Replication, mas isso parece quase demais, pois eu também precisaria do Veritas Volume Manager.

Existem vários softwares de backup que fazem um backup de 1 a 1, o que seria ok, mas como ele será transferido pela Internet, eu gostaria de algo que tenha compactação durante a transferência, como o DFS.

Alguém tem alguma sugestão sobre isso?

    

Answer 1

Eu usei o Doubletake Move para mover grandes conjuntos de dados pela Internet. Eles usam a replicação em nível de byte e acompanham as alterações nos arquivos. Há também um bom agendador de otimização de largura de banda para usar menos durante o dia e ativá-lo durante a noite e no fim de semana. Ele também se recupera muito bem em caso de quebra de conexão de algum tipo.

Agora, estou supondo que isso seja algum tipo de MSA anexado a uma máquina física, mas caso você esteja usando uma SAN, verifique com seu fornecedor de SAN as opções de replicação assíncrona.

Qualquer que seja a replicação usada, há algumas coisas que você quer pensar:

1. Largura de banda no lado de origem e de destino
2. Taxa de alteração do arquivo

Se a sua taxa de alteração for muito alta no lado da origem e você não tiver largura de banda suficiente para superá-la, nunca obterá uma boa replicação.

Voltar a indexar bancos de dados, defrags e lances / exclusões / exclusões de arquivos em massa causou dores de cabeça no passado.

Espero que minha dor passada ajude alguém que leia isso! : D

    

Answer 2

DFSR em 2003 R2 (2008 e 2008 R2 são muito mais escaláveis, exp de ser x64) funcionou tão maravilhosamente para nós com 75 servidores com todos os links de WAN diferentes (1-10MB) sincronizando arquivos totalizando pelo menos 500GB (por vezes de servidor 75) em links WAN ruins, lentos ou saturados que eu recomendaria apenas fazer o que for possível para que o DFSR funcione. Achamos mais fácil administrar a organização de maneira abrangente do que a Veritas, mas isso foi em 2006-7 após o lançamento do R2 em 2003. A largura de banda do BITS de controle do GPO é sua amiga.

Uma das coisas com o DFSR é que ele mantém uma pasta com cópias de todos os blocos que foram alterados e que precisam ser enviados, então o armazenamento é algo com o qual você quer ser liberal. Estou curioso sobre os limites que você cita, pois eu acho que os arquivos 8M ficariam bem no contexto de muitos recursos (RAM, CPU, disco). Eu não sei a nossa contagem de arquivos.

Além disso, no passado, o DFSR era incompatível com backup, A / V e outros softwares. Em 2008-2009, descobrimos que a Netbackup não gostava de DFSR e estava relatando sucesso com nossos backups de servidores de arquivos, mas estava realmente fazendo o backup de NADA. Apenas em testes de restauração descobrimos essa falha horrível e horrível no Netbackup. Se há uma coisa que você nunca quer que os sistemas de backup façam, relata um backup bem-sucedido, mas realmente tem uma fita vazia.

De qualquer forma, dou um voto de confiança ao DFSR, especialmente em sua terceira versão com o 2008 R2 como algo que você deve tentar se não encontrar o produto de um fornecedor que diga especificamente que testou seu cenário. Frequentemente, o que a Microsoft apóia oficialmente é muito mais conservador em relação ao que eles sabem que funcionará. Obviamente, sua milhagem pode variar e você precisa determinar o seu próprio nível de risco que deseja assumir.

    

Answer 3

A chave para observar a replicação é procurar por um "conjunto consistente" de dados replicados. Por exemplo: Db & Os arquivos de log correspondentes devem ser replicados de maneira "consistente", de modo que os dados possam ser usados no outro site replicado.

A segunda característica importante é o tempo necessário para a recuperação, caso haja uma queda na conexão. A replicação começa de onde saiu? Ele reinicia a replicação?

O terceiro - quão bem (ou pior) eles realizam em diferentes condições de rede e qual é a utilização da largura de banda.

As outras coisas importantes são: as permissões de arquivo são mantidas? Os outros atributos do arquivo são mantidos, por exemplo. o que acontece com pastas compactadas? O que acontece com arquivos criptografados? Os arquivos abertos são replicados? etc etc.

Dar a todas as soluções de replicação baseadas em blocos acima são muito melhores que a replicação baseada em arquivos. A replicação baseada em block do host seria mais barata que a replicação baseada em block "off-host".

    

Answer 4

Eu tenho um cliente usando o produto SureSync para replicar dados para um servidor de arquivos de "hot standby". Eles estão replicando pouco menos de 2 TB e funcionou muito bem. Ele usa o diário de alterações do NTFS para rastrear atualizações de arquivos e executa a replicação delta.

Não estou encontrando limitações de produtos publicados, então é melhor você verificar o "fabricante" para ver.

    

Answer 5

Embora o Veritas Volume Manager com a opção Veritas Volume Replicator não seja barato, ele pode oferecer algumas vantagens, como:

• Funciona no nível de bloco, por isso não é necessário replicar arquivos inteiros ou esperar que os arquivos sejam fechados antes que as salvações possam ser replicadas.
• A fidelidade de ordem de gravação é mantida, portanto, a ordem em que os dados são alterados no primário é que os dados do pedido são alterados no secundário - bom para bancos de dados e afins.
• Se você tiver que fazer o failover para o secundário, suas modificações no secundário serão facilmente sincronizadas com o principal.
• Compressão e afunilamento da transferência.

Existe uma ferramenta (VRAdvisor) disponível que você pode usar para monitorar sua taxa de alteração de dados, que então informará quanto de largura de banda você precisa para manter o secundário dentro de uma determinada quantidade de alteração de dados do primário.