Como determinar o tamanho mínimo necessário para uma pasta temporária de replicaçã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]

Warren está aqui novamente. Este artigo é um guia de referência rápida sobre como calcular corretamente o tamanho mínimo da pasta temporária necessária para o DFSR funcionar corretamente. Definir valores mais baixos pode retardar a replicação ou até pará-la. Lembre-se de que esses são apenas os valores mínimos . Ao decidir o tamanho de uma pasta intermediária, lembre-se do seguinte: quanto maior o tamanho da pasta intermediária, melhor, até o tamanho da própria pasta replicada. Para obter mais informações sobre a importância de usar o tamanho correto da pasta temporária, consulte a seção "Como determinar se você tem algum problema com a pasta temporária" e as postagens do blog vinculadas no final deste artigo.

Atualização: Warren realmente sabe como convencer! Agora há uma correção com a qual você pode calcular o tamanho da pasta de teste.
https://support.microsoft.com/kb/2607047

Regras básicas

Windows Server 2003 R2 - A cota da pasta de teste deve ser igual ao tamanho total dos 9 maiores arquivos da pasta replicada.

Windows Server 2008 e 2008 R2 - A cota da pasta de teste deve ser igual ao tamanho total dos 32 maiores arquivos da pasta replicada [Observação tradutor. Esse número também é válido para o Windows Server 2012 / 2012R2]

A replicação primária usa muito mais espaço na pasta temporária do que a replicação diária normal. Se o tamanho do espaço em disco permitir, antes de iniciar a replicação primária, é altamente recomendável definir o tamanho acima do mínimo necessário.

Onde obter o PowerShell?

O PowerShell está incluído no Windows 2008 e superior. Ele precisará ser instalado no Windows Server 2003. Baixe o PowerShell para Windows 2003 aqui .

Como encontrar esses arquivos maiores?

Use o script do PowerShell para encontrar os 32 ou 9 arquivos maiores e determinar quantos gigabytes eles ocupam (graças a Ned Pyle pelos comandos do PowerShell). Quero apresentar três scripts do PowerShell. Cada um deles é útil à sua maneira, no entanto, o terceiro é o mais útil.

1. Execute:
   

   Get-ChildItem c:\temp -recurse | Sort-Object length -descending | select-object -first 32 | ft name,length -wrap -auto 

   
   Este comando retorna nomes de arquivos e seu tamanho em bytes. É útil descobrir quais 32 arquivos são os maiores da pasta replicada e visitar seus proprietários.
   
2. Execute:
   

    Get-ChildItem c:\temp -recurse | Sort-Object length -descending | select-object -first 32 | measure-object -property length –sum 

   
   Este comando retorna o número total de bytes para os 32 maiores arquivos de uma pasta sem especificar seus nomes.
   
3. Execute:
   
   

    $big32 = Get-ChildItem c:\temp -recurse | Sort-Object length -descending | select-object -first 32 | measure-object -property length –sum $big32.sum /1gb 

   
   Este comando obtém o número total de bytes dos 32 maiores arquivos de uma pasta e, usando cálculos matemáticos, os converte em gigabytes. Este comando consiste em duas linhas separadas. Você pode colá-los imediatamente no shell de comando do PowerShell ou executá-los por vez.
   

Análise manual

Para demonstrar o processo e, se possível, aprofundar nossa compreensão do que estamos fazendo, passaremos por cada operação e a executaremos manualmente.

O primeiro comando em execução retornará resultados semelhantes aos mostrados abaixo. Por uma questão de brevidade, este exemplo leva apenas 16 arquivos. Sempre considere 32 arquivos para sistemas operacionais Windows 2008 e posteriores e 9 para Windows 2003 R2.

Dados de amostra retornados pelo PowerShell:

Nome	Comprimento
Arquivo5.zip	10286089216
archive.zip	6029853696
BACKUP.zip	5751522304
file9.zip	5472683008
MENTOS.zip	5241586688
Arquivo7.zip	4321264640
file2.zip	4176765952
frd2.zip	4176765952
BACKUP.zip	4078994432
Arquivo44.zip	4058424320
file11.zip	3858056192
Backup2.zip	3815138304
BACKUP3.zip	3815138304
Current.zip	3576931328
Backup8.zip	3307488256
Arquivo999.zip	3274982400

Como usar esses dados para determinar o tamanho mínimo da pasta temporária:

• Nome = nome do arquivo
• Comprimento = tamanho em bytes
• Um gigabyte = 1073741824 bytes

Primeiro você precisa calcular o número total de bytes. Em seguida, divida o número resultante por 1073741824. Eu recomendo usar o Excel ou outro editor de planilha usado para esses cálculos.

Cálculos baseados em exemplos

No exemplo acima, o número total de bytes é 75241684992. Para obter o tamanho mínimo necessário da cota intermediária, você precisa dividir 75241684992 por 1073741824.

75241684992/1073741824 = 70,07 (GB)

Com base nos dados, eu definiria o tamanho da pasta de teste como 71 GB, arredondando para um número inteiro.

Aplicação prática

Apesar de a análise manual ser interessante, não é a melhor coisa para gastar seu tempo. Para automatizar o processo, use o terceiro comando dos exemplos acima. Os resultados serão algo assim:



Usando o comando do terceiro exemplo, é possível, sem cálculos (sem contar o arredondamento), determinar se a pasta d: \ docs requer uma cota intermediária de 6 GB.

Preciso reiniciar o servidor ou reiniciar o serviço para aplicar as alterações?

Para que as alterações feitas na cota da pasta temporária entrem em vigor, não é necessário reiniciar o servidor ou reiniciar o serviço. Para aplicar as alterações, será necessário aguardar a conclusão da replicação do AD e do ciclo de pesquisa dos objetos DFSR no AD.

Como identificar problemas com a pasta temporária

Problemas intermediários de pasta são detectados rastreando códigos de eventos específicos nos logs do servidor DFSR. Aqui está uma lista desses eventos: 4202, 4204, 4206, 4208 e 4212. As descrições para eles são apresentadas abaixo. É importante entender a diferença entre os eventos 4202 e 4204, bem como outros eventos. Os eventos 4202 e 4204 podem ser registrados em grandes números e durante a operação normal. Pense nos eventos 4202 e 4204 como algo como um pulso, enquanto 4206, 4208 e 4212 serão semelhantes a dores no peito. Abaixo, explicarei como interpretar os eventos 4202 e 4204.

Eventos relacionados à pasta de teste

[Nota tradutor. Os eventos do diário descritos abaixo são apresentados na forma em que estão presentes na localização russa do Windows Server 2012 R2.]

Código: 4202
Nível: Aviso
A Replicação DFS descobriu que o espaço de armazenamento temporário usado pela pasta replicada com o caminho local <caminho> excedeu seu limite superior. O serviço tentará excluir os arquivos intermediários mais antigos. Isso pode afetar o desempenho.

Código: 4204
Nível: Informações
O Serviço de Replicação DFS excluiu com êxito os arquivos intermediários antigos da pasta replicada com o caminho local <caminho>. O espaço intermediário está agora abaixo do limite superior.

Código: 4206
Nível: Aviso
O serviço Replicação DFS não pôde limpar os arquivos intermediários antigos da pasta replicada no caminho local <caminho>. O serviço pode não conseguir replicar alguns arquivos grandes e a pasta replicada pode ficar fora de sincronia. O serviço tentará limpar novamente a área de preparação dentro de <X> min. Um serviço pode iniciar a limpeza mais cedo se detectar que alguns arquivos intermediários foram desbloqueados.

Código: 4208
Nível: Aviso
A Replicação DFS constatou que o espaço de armazenamento temporário excedeu a cota de armazenamento temporário da pasta replicada no caminho local <caminho>. replicar alguns arquivos grandes e a pasta replicada pode ficar fora de sincronia. O serviço tentará limpar novamente a área de preparação.

Código: 4212
Nível: Erro
O serviço Replicação DFS não pôde replicar a pasta replicada com o caminho local <caminho> porque o caminho intermediário é inválido ou indisponível.

Qual é a diferença entre os eventos 4202 e 4208?

Os eventos 4202 e 4208 têm uma descrição semelhante, isto é, O DFSR detecta que o tamanho ocupado pela pasta temporária excede o limite. A diferença é que o evento 4202 é registrado imediatamente após o início do processo de limpeza de pastas intermediárias, enquanto a cota intermediária ainda é excedida. O evento 4202 é um sinal de operação normal normal, enquanto 4208 indica um desvio da norma e requer intervenção.

Quantos eventos 4202 e 4204 são considerados muito grandes?

Não existe uma resposta única para esta pergunta. Ao contrário dos eventos 4206, 4208 e 4212, que sempre dizem coisas ruins e indicam a necessidade de ação, os eventos 4202 e 4204 também ocorrem durante a operação normal. Eventos frequentes 4202 e 4204 podem indicar um problema. Fatos a considerar:

1. Os eventos 4202 são registrados para uma pasta replicada (RF) durante sua replicação primária? Nesse caso, os eventos 4202 e 4204 são normais. Se durante a sincronização inicial você desejar reduzir o número desses eventos ao mínimo, isso poderá ser alcançado aumentando o tamanho da pasta intermediária.
2. Apenas contar o número total de 4202 eventos não é suficiente. Você precisa saber quantos deles se aplicam a um RF específico. Se em 24 horas houve vinte e 4202 eventos no diário relacionados a uma pasta, isso é muito. Mas se você tiver 20 pastas replicadas e um evento para cada uma delas, tudo estará em ordem.
3. Para identificar tendências, você precisa analisar as informações coletadas durante vários dias.

Normalmente, aconselho os clientes a não permitir mais que um evento 4202 por pasta replicada durante o dia durante a operação normal. "Normal" significa que a replicação primária não ocorre. Eu justifico isso com o seguinte raciocínio:

1. O tempo necessário para limpar a pasta de teste é o tempo gasto na replicação de arquivos. A replicação é suspensa enquanto a pasta temporária está sendo limpa.
2. O DFSR funciona com mais eficiência se houver espaço suficiente alocado para o intermediário, usando-o para o RDC e o RDC de arquivos cruzados , bem como para replicar arquivos idênticos para outros membros da replicação.
3. Quanto mais eventos 4202 e 4204 forem registrados, maior a probabilidade de você encontrar uma situação em que o DFSR não pode limpar a pasta temporária ou forçado a excluir prematuramente os arquivos dela.
4. Na minha experiência, os eventos 4206, 4208 e 4212 sempre foram antecipados e acompanhados por um grande número de eventos 4202 e 4204.

Seguir a regra de "não mais do que um evento 4202 por dia para cada RF" reduzirá significativamente a probabilidade de problemas com a pasta de teste e ajudará o servidor DFSR a usar com mais eficiência os recursos para a replicação de arquivo de finalidade.

Informações Adicionais

https://blogs.technet.com/b/askds/archive/2010/03/31/tuning-replication-performance-in-dfsr-especially-on-win2008-r2.aspx
https://blogs.technet.com/b/askds/archive/2007/10/05/top-10-common-causes-of-slow-replication-with-dfsr.aspx

Warren "ultrapassa minha cota de Oud" Williams