Cópia lenta de arquivo observada copiando arquivos de 40GB na rede para o dispositivo iSCSI

3

Aqui estão alguns curiosos para os gurus:

Configuração:

Máquina de origem: máquina Windows Server 2003 R2 com disco rígido local. Arquivo VHD de 40GB. 1 x placa de rede de 1 Gbps, cabo Cat6, interruptor.

Máquina de destino: máquina Windows Server 2008 R2 com conexão iSCSI para o destino iSCSI em uma máquina separada (1TB, RAID5). 1 placa de rede de 1 Gbps, cabo Cat6, conectado ao mesmo switch da Source Machine. Segunda placa de rede de 1 Gbps, cabo Cat6, conectado via comutador isolado ao alvo iSCSI.

Os switches são o modelo Netgear JGS524 (gerenciado pela web).

Se eu copiar da máquina Win2003R2 para a unidade local da máquina Win2008R2, recebo 40 GB em 45 minutos, 36 segundos.

Se eu copiar da máquina Win2008R2 para o destino iSCSI (unidade local para destino iSCSI), recebo 40 GB em 37 minutos e 56 segundos.

Se eu copiar da máquina Win2003R2 para o destino iSCSI através da máquina Win2008R2, recebo 40 GB em 3 horas, 50 minutos e 24 segundos.

Todas as cópias foram feitas através do seguinte comando emitido na caixa Win2008R2:

XCOPY < source > < alvo > / J

XCOPY / J - Copia usando E / S sem buffer. Recomendado para arquivos muito grandes.

Então, qual é o pouco que estou perdendo aqui? Por que uma cópia back-to-back leva no total 1 hora, 23 minutos, 32 segundos quando uma cópia "direta" leva quase 3 vezes mais tempo?

Comutadores não exibem erros, a rede fica em torno da marca de utilização de 3% pela duração da cópia (enquanto as cópias "back-to-back" estão em torno da marca de 25% de utilização).

O que eu perdi?

    
por Rick 01.02.2010 / 04:35

3 respostas

1

Poderia ser o 'unbuffered' copiar o problema? É possível que o Windows faça alguns truques que possam acelerar a cópia, pois a origem / destino é um disco local, mas ele reverte para um comportamento mais seguro se estiver usando dois dispositivos de rede.

Eu joguei com o teste de disco no Unix, e os sistemas operacionais podem executar muitos truques com o subsistema de disco. Boa sorte.

    
por 02.02.2010 / 11:00
0

E o Protocolo SMB? O Win2k8R2 usa o SMB 2.0, enquanto versões mais antigas do Win possuem apenas o SMB 1.0, que não é tão rápido E existe um antivírus ativo? Por outro lado, o acesso direto do dispositivo iSCSI usa um protocolo diferente com sobrecarga minimizada e nenhum scanner de vírus para o shure.

    
por 01.05.2010 / 18:10
0

Primeiramente, você está copiando de 2003R2 para 2008R2 em ambas as instâncias. Desde 2003, ele só pode usar o SMB1 e não faz muitas requisições simultâneas, e a informação estará percorrendo a rede em pedaços de 64kb e cada bloco de 64kb tem que ser reconhecido pelo servidor como sendo escrito antes do pedido. 2003R2 caixa envia o próximo.

Agora, se a caixa 2008R2 tiver que enviar a solicitação iSCSI e receber uma confirmação antes de retornar a resposta à caixa 2003R2, isso poderá atrasar o processo. Alguns cálculos na parte de trás do envelope sugerem que para blocos de 64kb você precisaria de 22ms entre o pedido de 2003R2 para escrever um pedaço e a resposta para dizer que ele foi escrito. Isso parece um pouco longo, mas não está fora do reino da possibilidade com todas as etapas envolvidas.

Não tenho certeza se esse é o seu problema, mas se estiver interessado, use o wireshark para verificar o tráfego da rede e verificar quais tamanhos e atrasos de bloco estão envolvidos.

Outra possibilidade menos interessante é que você tenha seu servidor configurado como Full Duplex e seu switch definido como negociação automática. Essa combinação não funciona e resulta no switch pensando que a conexão é half-duplex e faz com que ela caia ocasionalmente nos pacotes. Os pacotes descartados seriam muito piores quando o servidor envia e recebe grandes quantidades de dados ao mesmo tempo, como seria o caso do segundo processo de cópia.

    
por 26.11.2010 / 00:10