Velocidade de transferência ruim da WAN (Windows Server 2008 R2)

Question

Temos dois servidores em data centers diferentes, separados geograficamente por várias centenas de quilômetros. O RTT (round trip time) para um ping entre eles é de 61ms sobre a nossa VPN. Ambos os servidores estão em um link WAN gigabit.

Qualquer tipo de cópia de arquivo, seja SMB (arrastar e soltar), FTP (FileZilla experimentado, TFTP, etc.) é terrivelmente lento, em torno de 1 Mbps. Eu tentei habilitar e desabilitar o Nível de Auto-ajuste da Janela de Recebimento, a cópia multithread e assim por diante. Nossos firewalls têm muito espaço na CPU, então a criptografia VPN não é um fator importante.

Pensei em definir manualmente o tamanho da janela TCP porque parece um candidato óbvio aqui, mas, no meu entender, o Windows Server 2008 R2 ignora qualquer configuração personalizada do TcpWindowSize no registro.

Atualização: os tamanhos da janela TCP parecem estar bem. O Wireshark mostra o Window Size 513 com um fator de escala de tamanho de janela de 256 para um tamanho de janela calculado de 131328. Isso soa certo? Bytes em vôo ficam em torno de 9000 bytes durante uma transferência FTP em andamento.

    

Answer 1

1. Bata com uma execução simples de netcat - um fluxo de dados aleatórios que é descartado na outra extremidade. Eu sei que há uma versão do Windows em algum lugar. Use isso como uma linha de base.

2. Se isso não for executado em velocidade máxima, cheque sua conexão e faça novamente. Procure por perda de pacotes, recebimentos fora de ordem, checksums ruins, etc.

3. Isole o problema. Execute netcat internamente para ambas as redes. Execute-o a partir da sua borda, substituindo o roteador. Continue até você saber onde está o problema ou você pode dizer ao seu ISP que o problema está em algum lugar no link entre o site com detalhes sobre como o problema se apresenta.

Answer 2

Uma coisa a considerar é que muitas dessas transferências são muito faladas. Isso significa que há muita conversa para trás e para frente em uma transferência de arquivos. Nós tivemos este mesmo problema e descobrimos que o tubo maior não ajudou, pois havia muita sobrecarga.

Não há como fazer com que toda a comunicação seja mais rápida do que a luz e, como há tantas viagens para a frente e para trás, o tubo maior muitas vezes não ajuda. Você pode querer olhar para um acelerador de WAN.  Para nossos problemas com o SharePoint e um CRM em sites em várias cidades, a diferença foi surpreendente.

Não estou sugerindo um produto específico, mas simplesmente um local para procurar informações técnicas. Analisamos muitos produtos diferentes e finalmente decidimos por equipamentos Steelhead da Riverbed. Instalamos as unidades de teste em três sites e as chamadas ao suporte técnico pararam quase imediatamente. Você pode ver facilmente a diferença usando a GUI baseada na Web e um o tráfego da Web para o SharePoint que estava reduzindo o tráfego em até 90%, então melhoramos a velocidade e reduzimos o tráfego, o que reduziu os custos. Como não conseguimos conexões mais rápidas em vários sites, essa foi uma ótima solução.

Riverbed sugere uma aceleração de 5-50 vezes e excedemos em alguns casos. Eles têm uma grande quantidade de informações técnicas sobre o problema que você encontrou que eu acho que vai ajudar mais do que eu posso colocar aqui Riverbed Steelhead

    

Answer 3

É o registro. Desligue todos os registros no servidor. Todos os pacotes são gravados na unidade, o que reduz a velocidade de transmissão.