Como o algoritmo de compactação DFS-R se compara ao 7-zip?

Question

Precisamos transferir regularmente imagens de máquinas virtuais Hyper-V de grande porte (60 GB) em torno de nossa linha WAN (Reino Unido para EUA) sobre linhas alugadas de 50 Mbps. Nós também usamos o DFS-R entre os sites. Historicamente, usei o 7-zip para compactar a máquina virtual (em pedaços menores de 100 MB) e depois coloquei os arquivos em uma pasta de transferência do DFS-R. Quando a lista de pendências desaparecer, descompacte na outra extremidade.

Eu me pergunto se estou perdendo meu tempo e também posso deixar a VM inteira (arquivos VMDX principalmente) na pasta de transferência e deixar o DFS-R compactá-la durante a transferência.

Portanto, a questão é: qual é o algoritmo de compressão do DFS-R em comparação com o formato 7z nativo do 7-zip? O 7-zip embala a imagem em cerca de 20GB, para uma economia de 70%.

Tenho a sensação de que o tempo extra para compactar e descompactar supera qualquer taxa de compactação maior possível no algoritmo 7-zip. Dito isto, transferir pedaços de 100MB parece "melhor" do que um arquivo VMDX de 50 GB.

    

Answer 1

O DFS-R usa algo chamado Compressão Diferencial Remota.

Em vez de comparar e transferir um arquivo inteiro, o algoritmo comparará a assinatura de trechos sequenciais de dados entre a origem e a réplica de destino. Dessa forma, apenas diferentes partes de dados precisam ser transferidas pela rede, a fim de "reconstruir" o arquivo no local de destino.

Como tal, o RDC não é realmente comparável aos algoritmos de compressão usados no 7-zip. Embora usem técnicas semelhantes (criando dicionários de assinaturas em intervalos de dados), o algoritmo 7-zip foi projetado para reorganizar bytes em um formato de contêiner sem perdas em que todos os dados são "compactados" juntos, onde o objetivo do RDC é identificar diferenças entre arquivos semelhantes ou versões de arquivos, a fim de minimizar o volume de dados transferidos, a fim de manter as réplicas em sincronia

Se você já tiver arquivos VMDX semelhantes no local de destino, não será necessário dividir o arquivo em partes de 100 MB. Apenas certifique-se de sempre usar o (s) mesmo (s) algoritmo (s) de compactação ao compactar as imagens

Esse comportamento (comparar arquivos semelhantes , não versões distintas do mesmo arquivo e extrair partes) é conhecido como "RDC de arquivo cruzado" e a documentação disponível publicamente é bastante esparsa, mas a AskDS A equipe do blog tem um breve, mas muito bom, esclarecimento neste Q & Um post

    

Answer 2

Como Mathias já observou, o DFS-R emprega o algoritmo de "compressão diferencial remota" similar a rsync's para transmitir somente as partes alteradas / anexadas de um arquivo já presente no lado remoto. Além disso, os dados são compactados antes da transferência usando o Algoritmo de compressão XPRESS (Referência: Technet blog ) desde o início primeira aparição do DFS-R no Server 2003 R2. Eu não encontrei nenhum detalhe sobre a variante atual do XPRESS usado, mas como a compressão tem que acontecer on-the-fly, ele pode estar usando LZNT1 (basicamente LZ77 com complexidade reduzida), pois é o que é usado no NTFS para o mesmo propósito.

Se você deseja monitorar as taxas de compactação, considere ativar DFS-R depuração de log e avaliar os arquivos de log.

A taxa de compressão para qualquer um dos algoritmos EXPRESS é provavelmente menor (provavelmente por um fator tão grande quanto 2) do que a obtida com o 7zip, que possui algoritmos otimizados para redução do tamanho do arquivo e não redução do uso da CPU. Mas, novamente, usando o RDC, que permite a transmissão apenas de partes alteradas do arquivo, é provável que você receba significativamente menos dados do que o seu arquivo de 20 GB.

A pré-criação de um arquivo 7zip a ser transferido com o RDC pode parecer uma boa ideia para obter o melhor dos dois mundos - apenas transmitir alterações, mas com uma taxa de compactação maior para as partes alteradas - mas não é. A compactação iria mangle o arquivo inteiro e até mesmo um único byte alterado no início do fluxo de dados faria com que a aparência do arquivo compactado fosse totalmente diferente de antes. Existem modificações do algoritmo de compressão para atenuar este problema , mas o 7zip não parece implementá-las assim agora.

Em suma, é provável que você economize significativamente em bytes transmitidos por fio ao usar o DFS-R para transferir modificações de arquivos. Mas é bastante improvável que você obtenha economia de tempo e esteja induzindo uma carga significativa de I / O e CPU no destino, bem como na origem, já que ambos os arquivos (origem e destino) precisam ser lidos e verificados antes transmissão pode começar.

Edit: se você tiver novos arquivos, o RDC de fato seria de pouca ajuda - não há contrapartida para o parâmetro --fuzzy do rsync, que procuraria arquivos semelhantes no destino e os tomaria como uma linha de base para transferências diferenciais. Se você sabe que tem um arquivo semelhante (por exemplo, uma imagem de linha de base da VM HD transferida), é possível pré-semear o diretório de destino com este.