Tengo un problema al sincronizar una gran cantidad de datos entre dos centros de datos. Ambas máquinas tienen una conexión gigabit y no están completamente ocupadas, pero lo más rápido que puedo conseguir es entre 6 y 10 Mbit => ¡no es aceptable!
Ayer hice un traceroute que indica una carga enorme en un enrutador LEVEL3, pero el problema existe desde hace semanas y el alto tiempo de respuesta desapareció (20 ms en lugar de 300 ms).
¿Cómo puedo rastrear esto para encontrar el nodo lento real? Pensé en un traceroute con paquetes más grandes, pero ¿funcionará?
Además, es posible que este problema no esté relacionado con uno de nuestros servidores, ya que existen velocidades de transmisión mucho más altas hacia otros servidores o clientes. De hechooficina => servidores más rápido queservidor <=> servidor!
Cualquier idea se agradece ;)
Actualizar
De hecho, usamos rsync sobre ssh para copiar los archivos. Como el cifrado tiende a tener más cuellos de botella, probé una solicitud HTTP pero desafortunadamente es igual de lenta.
Tenemos un SLA con uno de los centros de datos. Dijeron que ya intentaron cambiar la ruta porque dicen que está relacionado con una red barata por donde se enruta el tráfico. Es cierto que pasará por una "red barata", pero sólo al revés. Nuestra dirección pasa por LEVEL3 y la otra vía pasa por lambdanet (que dijeron que no es una buena red). Si lo hice bien (soy un intermediario de la red), simularon una ruta más larga para forzar el enrutamiento a través de LEVEL3 y anuncian LEVEL3 en la ruta AS.
Básicamente quiero saber si tienen razón o simplemente están tratando de abdicar de su responsabilidad. La cuestión es que el problema existe en ambas direcciones (aunque en rutas diferentes), así que creo que es responsabilidad de nuestro proveedor de alojamiento. Y, sinceramente, no creo que exista una conexión DC2DC que sólo pueda manejar 600 kb/s - 1,5 MB/s durante semanas. La pregunta es cómo detectar DÓNDE está este cuello de botella.
Respuesta1
Si lo están enrutando a través de un enlace lento en la Internet pública, prácticamente sus únicas opciones son rodearlo por la fuerza. La forma más sencilla de hacer esto es intentar una transferencia de archivos entre dos puntos finales, siendo uno de ellos el "punto A" (el origen de los datos) y otrositio intermedioque no esté ubicado geográficamente junto a su destino, "punto B".
Una vez que encuentre un "punto C", que es un servidor que nonoSi desea enrutarse a través del lento enrutador de Internet al que se enfrenta, puede configurar una VPN entre el punto A y el punto C, de modo que el tráfico se "enrute alrededor" del nodo lento.
Si tiene un alto valor comercial ($$$$$$) o influencia con el ISP, también puede abordar el problema directamente con el Nivel 3. Sin embargo, L3 es un ISP de Nivel 1 y es posible que no sea particularmente receptivo a las quejas sobre el servicio. calidad o saturación de la red, ya que es muy poco lo que pueden hacer al respecto si no pueden, no quieren o no pueden ampliar sus acuerdos de peering con los proveedores de nivel 1 o descendentes que están creando la contención en su nodo.
Como dijo que el enlace "oficina a servidor" es más rápido, puede intentar configurar la VPN en el sitio de la "oficina" con una computadora moderadamente potente (un sistema de servidor de doble núcleo debería estar bien).
¡Ah, también!Si la latencia (de un extremo a otro) entre el "punto A" y el "punto B" es muy alta (más de 100 ms es alta en el mundo del servidor), debe asegurarse de queno estás utilizando un protocolo de red hablador. Samba (también conocido como SMB o Windows File Sharing) esextremadamentehablador; Otros protocolos de "sincronización" también pueden ser conversadores.
Los protocolos conversadores son aquellos que requieren muchos viajes de ida y vuelta sincrónicos para poder transferir datos. Si su protocolo es demasiado hablador, entonces la latencia por sí sola puede obstaculizar su transferencia, independientemente de qué tan rápido sea capaz el enlace.
Una cosa que puedes hacer para determinar si la conversación realmente está afectando tu rendimiento es utilizar un conocidopoco habladorprotocolo, como HTTP, para una transferencia de prueba. Por lo tanto, pruebe el antiguo HTTP normal desde el "punto A" al "punto B" a través del enrutador "lento" de Nivel 3, y si la latencia es alta pero el rendimiento sigue siendo bueno, entoncessaberque la razón por la que su transferencia es lenta es que su protocolo es demasiado hablador, por lo que necesita cambiar el protocolo.
Así que permítanme completar la discusión definiendo y explicando brevementeLas tres deficiencias de la red.y por quéalguiende ellos pueden ser responsables de este problema:
Latencia-- Cuánto tiempo tarda un datagrama en llegar desde su extremo al otro extremo. No puede mejorar directamente la latencia en la mayoría de los casos, a menos que una de sus computadoras esté tan sobrecargada que su pila de red, kernel o aplicaciones generen una latencia adicional significativa. La mayor parte de la latencia en la Internet pública se origina en los enrutadores de Internet, no en su computadora o terminal.
Banda ancha-- El ancho de banda es el rendimiento máximo del enlace más lento entre su computadora y el punto final. En la mayoría de las redes modernas, el ancho de banda no es una restricción real, porque otras deficiencias de la red aparecen y ralentizan la red mucho antes de que el ancho de banda sea un problema real.
Paquete perdido-- La pérdida de paquetes puede aumentarpercibidolatencia para datagramas confiables (como TCP) y, a menudo, es el resultado de enlaces muy saturados que tienen que descartar su paquete del búfer de transmisión o recepción de TCP debido a que el búfer ya está demasiado lleno. Además, la pérdida de paquetes puede ocurrir con paquetes "sensibles al tiempo", como es el caso de casi todos los paquetes TCP, porque si el paquete llega después de la fecha límite, se descarta. Esto ocurre si un paquete TCP más grande se fragmenta en múltiples datagramas IP y el protocolo TCP en el lado receptor solo puede esperar un período de tiempo fijo para que lleguen todos los fragmentos, antes de decidir abortar la recepción del paquete. Entonces, la pérdida de paquetes se deriva indirectamente de problemas de saturación (queesun problema de ancho de banda), o también por problemas o fallos de hardware.
Derivados de los deterioros fundamentales de la red, hay mitigaciones que puede tomar para mejorar la confiabilidad de sus programas sin cambiar los deterioros fundamentales, porque la mayoría de las veces, hay poco o nada que pueda hacer para controlarlos:
La primera mitigación es hacer que su protocolo sea menos hablador (o, desde una perspectiva de integración de sistemas,usarun protocolo existente que es menos hablador que su solución actual). Cuantos menos "viajes de ida y vuelta" se requieran para sincronizar datos entre los puntos finales, mejor estará, punto. Algunos protocolos pueden diseñarse para requerir una frecuencia de sincronización variable; si este es el caso, debe reducir dinámicamente la frecuencia de sincronización tanto como sea posible si detecta una latencia alta o pérdida de paquetes. Reducir la conversación ayuda a mitigar la latencia y la pérdida de paquetes, pero no los problemas del límite del ancho de banda.
La segunda mitigación es configurar todos los saltos (los que controla directamente a nivel administrativo/de hardware) para utilizar el mejor algoritmo de gestión activa de colas (AQM) disponible, que actualmente es Fair Queue Controlled Delay AQM. Esto está disponible en el kernel de Linux 3.5 o posterior como fq_codelimplementación de qdisc, y lo que hace es dinámicamente.reduceel tamaño de los buffers de transmisión y recepción, para reducir la latencia que estos buffers producen invariablemente. Esto puede reducir la pérdida de paquetes y ayudar a lidiar con la latencia utilizando el protocolo TCP, porque es menos probable que sus paquetes fragmentados caduquen si minimiza la cantidad de espera que debe pasar el paquete antes de enviarse a través del enlace. Tenga en cuenta que esta mitigación sólo hace alguna diferencia si el nodo está "saturado" (es decir, si el búfer TCP está vacío, no tiene ningún efecto). Un nodo se satura cada vez que la velocidad de escritura de datos en el socket de la red excede la velocidad de transmisión del enlace ascendente. La respuesta típica de la pila TCP a esta situación es agrandar el búfer, lo que en realidad tiene un efecto negativo, porque aumenta la latencia y eso causa todo tipo de problemas, por lo que fq_codel ayuda a mitigar eso.
Ambas mitigaciones ayudan con los tres deterioros fundamentales de la red,sinenrutamiento alrededor del nodo defectuoso, ysincambiar cualquier hardware o ponerse en contacto con el ISP.