Tenho um problema ao sincronizar uma grande quantidade de dados entre dois data centers. Ambas as máquinas têm conexão gigabit e não estão totalmente ocupadas, mas o mais rápido que consigo é algo entre 6 e 10 Mbit => não aceitável!
Ontem fiz um traceroute que indica uma carga enorme em um roteador LEVEL3, mas o problema existe há semanas e o alto tempo de resposta acabou (20ms em vez de 300ms).
Como posso rastrear isso para encontrar o nó lento real? Pensou em um traceroute com pacotes maiores, mas isso funcionará?
Além disso, este problema pode não estar relacionado a um dos nossos servidores, pois há taxas de transmissão muito mais altas para outros servidores ou clientes. Na verdadeescritório => servidoré mais rápido queservidor <=> servidor!
Qualquer ideia é apreciada ;)
Atualizar
Na verdade, usamos rsync sobre ssh para copiar os arquivos. Como a criptografia tende a ter mais gargalos, tentei uma solicitação HTTP, mas infelizmente é igualmente lenta.
Temos um SLA com um dos data centers. Eles disseram que já tentaram mudar o roteamento porque dizem que isso está relacionado a uma rede barata por onde o tráfego é roteado. É verdade que ele passará por uma "rede barata", mas apenas o contrário. Nossa direção passa pelo LEVEL3 e o outro caminho passa pela lambdanet (que disseram não ser uma boa rede). Se acertei (sou intermediário de rede), eles simularam um caminho mais longo para forçar o roteamento através do LEVEL3 e anunciam o LEVEL3 no caminho AS.
Basicamente, quero saber se eles estão certos ou se estão apenas tentando abdicar de sua responsabilidade. Acontece que o problema existe nas duas direções (embora em rotas diferentes), então acho que é responsabilidade do nosso hoster. E honestamente, não acredito que exista uma conexão DC2DC que possa suportar apenas 600kb/s - 1,5 MB/s por semanas! A questão é como detectar ONDE está esse gargalo
Responder1
Se você estiver sendo roteado por meio de um link lento na Internet pública, praticamente suas únicas opções serão rotear-se à força. A maneira mais simples de fazer isso é tentar uma transferência de arquivo entre dois pontos finais, sendo um deles o "ponto A" (a origem dos dados) e umlocal intermediárioque não esteja geograficamente co-localizado com o seu destino, "ponto B".
Depois de encontrar um "ponto C", que é um servidor que nãonãoSe você for roteado pelo roteador de Internet lento que está enfrentando, poderá configurar uma VPN entre o ponto A e o ponto C, para que o tráfego seja "roteado em torno" do nó lento.
Se você tiver alto valor comercial ($$$$$$) ou influência com o ISP, também poderá resolver o problema diretamente com o Nível 3. No entanto, L3 é um ISP de nível 1 e pode não ser particularmente receptivo a reclamações sobre o serviço. qualidade ou saturação da rede, uma vez que há muito pouco que eles possam fazer sobre isso se não puderem, não quiserem ou não puderem expandir seus acordos de peering com o downstream ou outros provedores de Nível 1 que estão criando a contenção em seu nó.
Como você disse que o link "escritório para servidor" é mais rápido, você pode tentar configurar a VPN no site "escritório" com um computador moderadamente potente (um sistema dual core de nível de servidor deve servir).
Ah, também!Se a latência (ponta a ponta) entre o "ponto A" e o "ponto B" for muito alta (maior que 100 ms é alta no mundo do servidor), você deve certificar-se de quevocê não está usando um protocolo de rede tagarela. Samba (também conhecido como SMB ou Windows File Sharing) éextremamentetagarela; outros protocolos de "sincronização" também podem ser tagarelas.
Protocolos chatty são aqueles que exigem muitas viagens de ida e volta síncronas para transferir dados. Se o seu protocolo for muito falador, a latência por si só poderá atrapalhar sua transferência, independentemente da velocidade do link.
Uma coisa que você pode fazer para determinar se a tagarelice está realmente afetando seu rendimento é usar um método conhecido.pouco conversadorprotocolo, como HTTP, para uma transferência de teste. Portanto, tente o HTTP antigo normal do "ponto A" ao "ponto B" no roteador "lento" de nível 3 e, se a latência for alta, mas a taxa de transferência ainda for boa, então vocêsaberque o motivo de sua transferência ser lenta é que seu protocolo é muito falador, então você precisa alterar o protocolo.
Então deixe-me completar a discussão definindo e explicando brevementeas três deficiências de redee porquequalquer umdeles podem ser responsáveis por este problema:
Latência-- Quanto tempo um datagrama leva para ir de uma ponta a outra. Na maioria dos casos, você não pode melhorar diretamente a latência, a menos que um de seus computadores esteja tão sobrecarregado que sua pilha de rede, kernel ou aplicativos gerem latência adicional significativa. A maior parte da latência na Internet pública se origina dos roteadores da Internet, e não do seu computador ou do endpoint.
Largura de banda-- Largura de banda é o rendimento máximo do link mais lento entre o seu computador e o endpoint. Na maioria das redes modernas, a largura de banda não é uma restrição real, porque outras deficiências de rede se instalam e tornam a rede mais lenta muito antes de a largura de banda se tornar um problema real.
Perda de pacotes- A perda de pacotes pode aumentarpercebidolatência para datagramas confiáveis (como TCP) e geralmente é o resultado de links altamente saturados que tiveram que retirar seu pacote do buffer de transmissão ou recebimento do TCP devido ao buffer já estar muito cheio. Além disso, a perda de pacotes pode ocorrer com pacotes “sensíveis ao tempo”, como é o caso de quase todos os pacotes TCP, porque se o pacote chegar após o prazo, ele será descartado. Isso ocorre se um pacote TCP maior for fragmentado em vários datagramas IP, e o protocolo TCP no lado receptor só puder esperar um período fixo de tempo para que todos os fragmentos cheguem, antes de decidir abortar o recebimento do pacote. Portanto, a perda de pacotes é indiretamente derivada de questões de saturação (queéum problema de largura de banda), ou também de problemas ou falhas de hardware.
Derivadas das deficiências fundamentais da rede, existem mitigações que você pode adotar para melhorar a confiabilidade dos seus programas sem alterar as deficiências fundamentais, porque na maioria das vezes, há pouco ou nada que você possa fazer para controlá-las:
A primeira mitigação é tornar seu protocolo menos tagarela (ou, de uma perspectiva de integração de sistemas,usarum protocolo existente que seja menos tagarela do que sua solução atual). Quanto menos "viagens de ida e volta" forem necessárias para sincronizar dados entre os endpoints, melhor será para você - ponto final. Alguns protocolos podem ser projetados para exigir uma frequência variável de sincronização – se for esse o caso, você deve diminuir dinamicamente a frequência de sincronização tanto quanto possível se detectar alta latência ou perda de pacotes. Reduzir a conversação ajuda a mitigar a latência e a perda de pacotes, mas não os problemas de limite de largura de banda.
A segunda mitigação é configurar todos os seus saltos (aqueles que você controla diretamente em nível administrativo/hardware) para usar o melhor algoritmo disponível de Active Queue Management (AQM), que atualmente é Fair Queue Controlled Delay AQM. Isto está disponível no kernel Linux 3.5 ou posterior como a fq_codelimplementação qdisc, e o que ele faz é dinamicamentereduzo tamanho dos buffers de transmissão e recepção, a fim de reduzir a latência que esses buffers invariavelmente produzem. Isso pode reduzir a perda de pacotes e ajudar a lidar com a latência usando o protocolo TCP, porque é menos provável que seus pacotes fragmentados expirem se você minimizar a quantidade de espera que o pacote precisa passar antes de ser enviado pelo link. Observe que esta mitigação só faz diferença se o nó estiver "saturado" (ou seja, se o buffer TCP estiver vazio, não terá efeito). Um nó fica saturado sempre que a taxa de gravação de dados no soquete da rede excede a taxa de transmissão do uplink. A resposta típica da pilha TCP para esta situação é aumentar o buffer, o que na verdade tem um efeito negativo, porque aumenta a latência, e isso causa todos os tipos de problemas - então fq_codel ajuda a mitigar isso.
Ambas as mitigações ajudam com todos os três comprometimentos fundamentais da rede,semroteamento em torno do nó defeituoso, esemalterar qualquer hardware ou entrar em contato com o ISP.