Estamos usando o DFS como "errado"?

Question

Somos uma empresa que possui filiais em todo o país. Temos um mínimo de 1 T1 para cada ramo e um máximo de 2 T1s. Temos um servidor DFS em cada filial e no nosso escritório principal. Na semana passada, um compartilhamento particularmente problemático que tem alguns de nossos arquivos de usuário nunca teve um backlog de 0 arquivos. Eu tenho ajustado o cronograma de replicação para tentar obtê-lo limpo e o menor que eu consegui é de 1500 arquivos para esse compartilhamento específico.

Então, minhas perguntas são:

• Está errado que tenhamos a configuração do DFS em uma WAN?
• Temos apenas pouca largura de banda para o número de arquivos e a quantidade de alterações que temos?
• Existe alguma configuração mágica que não foi feita?

Answer 1

Eu suportei sua configuração exata com 70 sites de WAN no Windows Server 2003 R2, principalmente com o T-1. Funcionou muito bem. O DFSR era o nosso método de backup do servidor de arquivos WAN. Você pode usar o MRTG para monitorar a largura de banda do seu roteador T-1 para verificar quaisquer problemas de largura de banda?

Usamos o MRTG para ver gráficos de uso de largura de banda e GPOs baseados em site para controlar a largura de banda usada para BITS no DFSR. Nós definimos os GPOs para usar ~ 700kb durante o dia e maximizar o T-1 à noite. Às vezes, tivemos casos em que os backlogs aumentavam e, se eles nunca se esvaziavam, sabíamos por meio do monitoramento do servidor e do MRTG que a única opção era obter mais largura de banda. O DFSR já está compactado e em nível de bloco, portanto, não sei se outras soluções de terceiros para replicar dados externos o tornarão melhor (se você puder realmente mostrar que ele é limitado à largura de banda).

DFSR em 2008 ou 2008 R2 pode ter otimizações adicionais, então pesquise essa opção de atualização também.

    

Answer 2

Você parece ter respondido a sua própria pergunta aqui. Dado o grande número de modificações que seus usuários estão fazendo nesse compartilhamento, nenhuma quantidade de ajustes na configuração do DFS resolverá isso. Seu backlog é dependente da largura de banda e nunca será zerado se os usuários fizerem modificações mais rapidamente, então a rotina de sincronização poderá sincronizá-los. Você pode querer reconsiderar a arquitetura do uso do DFS nessa configuração. Um sistema de gerenciamento de documentos / groupware colaborativo soa como se fosse um ajuste melhor aqui, em seguida, tentando executar tudo no nível do sistema de arquivos.

    

Answer 3

Com 2008, você pode usar o branchcache - ele não apenas replica cegamente tudo o que foi alterado, mas mantém os arquivos que foram abertos em um cache, que é atualizado se a cópia central for atualizada. Tanto quanto me lembro, em 2003, o DFS funciona como um replicador de arquivos alterado. Você muda 1 byte em um arquivo de 100mb e recopina 100mb. Em 2008, apenas copia o byte 1.

Estou surpreso que você não esteja vendo mais problemas. Eu usei DFS como este anos atrás, mas comecei a bater problemas replicando cerca de 70GB de arquivos. Após investigar, encontrei um MS doc que indicava que não era suportado pela marca mágica de 50GB. Os problemas incluíam a exclusão de arquivos não replicados ... e isso em um lan em vez de um wan.

O Linux tem alguns sistemas de arquivos distribuídos e ferramentas de replicação de arquivos, mas todos eles terão os mesmos problemas se você não tiver largura de banda.

Outra alternativa seria usar aceleradores cifs. Usamos o packeteer (agora parte do bluecoat) e é possível que as pessoas abram e editem diagramas CAD de 20mb em uma DSL comum. Os tempos de abertura e de salvamento são razoáveis.