Os erros e conceitos errados mais comuns ao configurar o DFSR

[Nota tradutor. O artigo é para Windows Server 2003 / 2003R2 / 2008 / 2008R2, mas a maioria dos itens acima se aplica a versões posteriores do sistema operacional]

Olá pessoal! Warren está aqui novamente, e esta postagem no blog é uma compilação dos problemas mais comuns do DFSR que encontrei nos últimos anos. O objetivo desta postagem é listar erros comuns na configuração do DFSR que causam esses problemas e impedir que você cometa erros semelhantes. Saber o que não deve ser feito é tão importante quanto saber o que fazer. Muitos dos itens descritos estão relacionados a outros tópicos; portanto, são fornecidos links correspondentes para um estudo aprofundado da questão.

Tamanho da cota muito pequeno para a pasta temporária

Você viu muitos eventos na revista com os códigos 4202 e 4204? Nesse caso, o tamanho da pasta temporária está definido incorretamente. Uma conseqüência desagradável do tamanho definido incorretamente da pasta temporária é a redução no desempenho da replicação, porque, em vez de replicar arquivos, o serviço gastará tempo limpando a pasta temporária.
Os servidores DFSR configurados com um tamanho de pasta temporário suficiente são mais eficientes por pelo menos dois motivos:

1. É muito mais eficiente colocar o arquivo em uma pasta intermediária uma vez e enviá-lo a todos os parceiros de replicação do host, do que criar o arquivo, replicá-lo e excluir uma cópia para cada parceiro do host.
2. Se a edição Enterprise do sistema operacional estiver instalada em pelo menos um membro, os servidores poderão usar a tecnologia RDC entre arquivos [aprox. tradutor: a partir do Windows Server 2012, essa tecnologia também está disponível na edição padrão]

Um tamanho configurado incorretamente para a pasta temporária também pode causar loops de replicação. Isso acontece se o arquivo replicado já tiver sido copiado para a pasta temporária no servidor de recebimento, mas o mecanismo de limpeza da pasta temporária excluirá esse arquivo antes que ele possa passar para a pasta de destino. O arquivo excluído será replicado para o servidor novamente e será excluído por este servidor da pasta temporária novamente, como resultado do qual o servidor nunca poderá receber o arquivo. Este processo será repetido até o servidor aceitar o arquivo.

Não ignore os eventos de log da pasta temporária.

Confira este post que descreve como usar o método para determinar o tamanho mínimo de uma pasta intermediária.

Consulte a seção “Aumentando a cota provisória” aqui .

Para obter informações sobre RDC entre arquivos, você pode ler o artigo "Informações sobre compactação diferencial remota", publicado aqui .

Procedimento de pré-configuração incorreto ou não testado

Um procedimento de pré-configuração está copiando os dados que serão replicados para um novo servidor membro de replicação antes de serem adicionados à pasta de destino deste servidor, para reduzir o tempo necessário para concluir a replicação primária. A maioria das falhas do procedimento de pré-configuração que encontrei foram causadas por três razões.

1. Incompatibilidade da ACL na origem e destino.
2. Após copiar para um novo membro de replicação, foram feitas alterações nos arquivos.
3. Nenhum pré-teste foi realizado para verificar se o procedimento de pré-configuração utilizado estava funcionando conforme o esperado.

Em resumo, os arquivos devem ser copiados de uma certa maneira e não podem ser alterados após terem sido copiados para a pasta intermediária, e todo o processo deve ser pré-testado por você.

Clique aqui para ler o blog do Sr. Pile sobre como organizar adequadamente o procedimento de pré-configuração para seus servidores DFSR.

Grande tamanho da fila de cópias ao longo do tempo

Além do fato de uma longa fila de cópias existir por um longo período, significa que seus dados não estão sincronizados, isso pode levar a uma resolução indesejável de conflitos quando um arquivo com conteúdo antigo vence em um script de resolução de conflitos. O cenário mais comum em que me deparei com esse comportamento é a adição maciça de novas pastas de replicação. Em vez de fazer uma implantação em fases, alguns administradores adicionaram 20 novas pastas para replicação de 20 ramificações diferentes, sobrecarregando o servidor host. Implante em estágios para que a replicação primária seja concluída em um período de tempo razoável.

DFSR usado como solução de backup

Acredite ou não, alguns administradores implantam o DFSR sem backups offline de dados replicados. O DFSR não foi projetado como uma solução de backup. Um dos objetivos do desenvolvimento do DFSR é fazer parte de uma estratégia de backup corporativo, porque o DFSR permite coletar dados geograficamente distribuídos em um site centralizado para posterior backup, recuperação e arquivamento. Vários membros de replicação fornecem proteção contra falhas no servidor, mas isso não protege contra exclusões acidentais. Para estar totalmente protegido, você precisa fazer backup de seus dados.

Replicação unidirecional: seu uso e métodos de reparo incorretos

Em uma tentativa de impedir que atualizações indesejadas apareçam em servidores onde os dados nunca serão alterados (ou se eles quiserem impedir alterações neles), muitos clientes configuram a replicação unidirecional removendo as conexões de saída dos membros da replicação. A replicação unidirecional não é suportada em nenhuma versão do DFSR anterior ao Windows Server 2008 R2. O Windows 2008 R2 oferece suporte à replicação unidirecional, que permite configurar pastas somente leitura para pastas replicadas.

O uso de membros de replicação somente leitura pode atingir o objetivo de replicação unidirecional, o que impede alterações indesejadas nos dados que estão sendo replicados. Se você deseja usar a replicação unidirecional usando o DFSR, use o Windows 2008 R2 e, para os membros que não devem ser alterados, selecione o modo somente leitura.

Clique aqui e aqui para aprender sobre a replicação somente leitura do DFSR.

Outro problema comum ocorre quando o administrador descobre que a replicação unidirecional não é suportada e tenta corrigir a situação, mas faz isso da maneira errada. A simples ativação da replicação bidirecional de volta pode ter resultados indesejáveis.

Clique aqui para saber como corrigir a replicação unidirecional.

Servidor de nó como um único ponto de falha e servidores de nó sobrecarregados

Eu já vi muitas implantações com um servidor de nó único. Se este servidor do nó falhar, toda a implementação estará em risco. Se você estiver usando o Windows Server 2003 ou 2008, deverá ter pelo menos dois servidores host e, se um deles travar, o outro deverá lidar com a carga no tempo de recuperação do primeiro, com impacto mínimo nos usuários finais. A partir do Windows Server 2008 R2, o DFSR pode ser implantado em um cluster de failover do Windows, fornecendo alta disponibilidade e reduzindo os requisitos de armazenamento pela metade.

Mais cedo ou mais tarde, os administradores têm uma situação em que há muitos servidores nas filiais configurados para replicar com um servidor de nó único. Isso pode levar a atrasos na replicação. Para entender quantos servidores de escritório em servidor um servidor de nó único pode atender, você pode usar o rastreamento da fila de cópias. Não existe uma fórmula mágica, pois cada ambiente é único e há muitas dependências.

Leia a seção "Configuração da topologia" aqui para aprender sobre a implantação de servidores host.
Clique aqui para saber como configurar o DFSR em um cluster de failover do Windows Server 2008.

Muitas pastas para replicar em um único banco de dados Jet

O DFSR usa um banco de dados Jet no volume. Como resultado, colocar todas as pastas replicadas no mesmo volume faz com que todas elas estejam no mesmo banco de dados Jet. Se surgir um problema nesse banco de dados que precise ser reparado ou restaurado, o banco de dados afetará todas as pastas replicadas neste disco. [Nota tradutor. obviamente, este não é um disco, mas um volume.] Seria mais correto usar o maior número possível de discos e distribuir as pastas replicadas entre eles, garantindo assim o tempo máximo de disponibilidade de dados.

Implantação baseada em soluções iSCSI de orçamento

Eu sempre vi implantações DFSR usando o hardware iSCSI mais barato. Geralmente, se você usa o DFSR, faz isso para atingir objetivos críticos, como redundância de dados, consolidação de backup, entrega agendada de aplicativos e atualizações do sistema operacional. Tornar-se dependente de equipamentos de baixa qualidade que não têm suporte normal do fornecedor não é uma boa ideia. Se os dados são importantes para os seus negócios, o equipamento no qual o SO e o mecanismo de replicação funcionam será importante para eles.

O serviço DFSR não instala patches atuais

O DFSR é suportado ativamente pela Microsoft e é atualizado conforme necessário. Atualize o DFSR se houver uma nova versão no momento do seu próximo ciclo de instalação da atualização. Verifique se seus servidores estão atualizados de acordo com os artigos da base de conhecimento listados abaixo.

Hotfixes DFSR para Windows 2003 R2
Hotfixes DFSR para Windows 2008 e Windows 2008 R2

Observe que, além de DFSR.EXE / DFSRS.EXE, as atualizações listadas também são para NTFS.SYS e outros arquivos. Para que a replicação funcione corretamente, sempre verifique se os patches mais recentes estão instalados pelo menos para DFSR e NTFS. Outras correções da lista referem-se principalmente a problemas na interface do usuário e você precisará instalá-las pelo menos nos sistemas em que as tarefas de configuração do DFSR são executadas.

É recomendável que as correções sejam instaladas no servidor DFSR com antecedência, mesmo que tudo funcione bem, pois mais tarde isso ajudará a evitar o aparecimento de problemas já conhecidos.

Os drivers do adaptador de rede não são suportados atualizados

O DFSR só poderá funcionar normalmente se a rede fornecida também funcionar sem problemas. O uso de drivers há 5 anos não é a solução mais inteligente. Tive experiência em me comunicar com vários clientes para os quais os problemas de replicação do DFSR foram resolvidos com a atualização de um driver desatualizado da NIC.

Monitoramento DFSR ausente

Apesar do DFSR ser usado para mover dados críticos, muitos administradores não têm idéia do que o DFSR está fazendo até encontrar um problema. Aqueles que têm mais recursos criam seus próprios scripts para monitorar as filas de cópias em seus servidores, mas a maioria simplesmente depende disso. O pacote de gerenciamento do DFSR foi lançado quase um ano atrás (e outras versões apareceram anteriormente). Instale-o e use-o - e então você poderá detectar problemas e responder a eles antes que eles se transformem em um pesadelo. Se você não conseguir usar o Operations Management Management Pack para DFSR, pelo menos escreva um script para monitorar a fila de cópias diariamente, a fim de entender se os arquivos DFSR estão ou não sendo replicados.

Clique aqui para obter informações sobre o Operations Management Management Pack for DFSR.

Atualizado 19 de janeiro de 2011:

Fazendo alterações no armazenamento em disco sem primeiro arquivar dados

Se o servidor DFSR precisar substituir o disco rígido ou adicionar um novo para aumentar o espaço de armazenamento, é extremamente importante ter um backup de dados atualizado, caso algo dê errado. Tudo pode dar errado, na maioria dos casos os eventos de conflito ocorrem devido a alterações inesperadas na pasta pai ou exclusão acidental da pasta pai, que é replicada para todos os parceiros. Você deve fazer backup de seus dados antes de fazer alterações e mantê-los até que o projeto seja concluído.

Parando o serviço DFSR para parar temporariamente a replicação

Às vezes, você precisa parar temporariamente a replicação. A maneira correta de fazer isso é desabilitar a replicação para o grupo desejado usando um agendamento. O serviço DFSR deve estar em execução para poder ler as atualizações no log da USN. Não pare o serviço DFSR por um longo período (dias, semanas), pois isso pode causar um estouro de log (se muitos arquivos foram alterados, adicionados ou excluídos durante esse período). O DFSR se recuperará dos estouros de log, mas em implantações grandes, demorará muito tempo e a replicação não funcionará ou será muito lenta durante a recuperação do log. Além disso, é provável que você observe filas de cópias muito grandes até a recuperação do log ser concluída.

Espero que esta lista o ajude. Boa replicação!

Warren Williams

[Nota tradutor. Se houver interesse dos leitores, tentarei posteriormente traduzir os artigos publicados nos links indicados no texto, bem como outros artigos do autor original]