Problemas de rendimiento para la resolución de problemas de sitios de socket

Visión general

Los clientes pueden experimentar problemas de rendimiento con sus aplicaciones mientras están conectados a Cato. Los problemas de rendimiento son un tema amplio, y pueden ocurrir en diferentes capas OSI, desde la capa física hasta la capa de aplicación. Este manual se centrará principalmente en problemas de rendimiento hasta la capa TCP. Los problemas de rendimiento relacionados con capas aplicativas se discutirán en otros manuales:

Síntomas

  • Transferencia de archivos lenta, reducción de rendimiento
    • Cuando están conectados a Cato Cloud, los clientes pueden experimentar velocidades de descarga y carga lentas.
  • Tiempos de respuesta retrasados en aplicaciones
    • Esto podría ser más evidente en aplicaciones interactivas como escritorios remotos. 

Causas Posibles

  • Mala configuración (QoS, Licencia, Aceleración TCP, Escalado de Ventana)
  • Congestión de Red
  • Pérdida de Paquetes (ISP, última milla)
  • PoP No Óptimo 
  • CPU de Socket Alta 
  • Latencia Aumentada de la Nube
  • Limitaciones de Hardware

Resolviendo el Problema

Antes de entrar en más resolución de problemas, es esencial aislar si esto está relacionado con Cato Cloud. Para hacer eso, podemos pasar por alto la conexión a Cato y verificar si el problema persiste. Pasar por alto Cato Cloud proporciona pasos detallados sobre cómo lograrlo.

Si el problema persiste a pesar de pasar por alto la conexión, indica que Cato no causa el problema. Sin embargo, si el problema se resuelve después de pasar por alto la conexión a Cato Cloud, entonces siga los siguientes pasos para más resolución de problemas y aislamiento.

Configuración de Licencias y Ancho de Banda

Nota: La asignación de ancho de banda WAN se basa en la licencia del sitio y la configuración de ancho de banda de la interfaz. Si ambos tienen valores diferentes, se aplicará el más bajo al enlace WAN.

  • Valide que la licencia asignada para el sitio es correcta. Vaya a Network > Sites > Site Configurations > General 
  • Valide que el Ancho de Banda configurado de la interfaz WAN es correcto. Vaya a Network > Sites > Site Configurations > Socket > Edit la interfaz WAN. 
  • Para sitios en China y Vietnam, la licencia es diferente. La licencia se dividirá en licencias Globales y Regionales. La licencia Global es para conexiones a sitios globales mientras que la licencia regional es para conexiones dentro del País. 
  • Para más información sobre cómo gestionar licencias de sitio, consulte Gestión de Licencias de Ancho de Banda de Sitio

Pérdida de Paquetes

La pérdida de paquetes puede ocurrir dentro de la infraestructura de Cato o con el Proveedor de Servicios de Internet (ISP). Los siguientes pasos están destinados a aislar la fuente de la pérdida de paquetes.

  • Verifique la pérdida de paquetes (ascendente/descendente) en Network Analytics.

  • Si esto coincide con pérdidas de paquetes en la última milla, indica un problema potencial de hardware con el cable que conecta al puerto WAN del Socket o un problema con el Proveedor de Servicios de Internet (ISP).

  • Consulte la sección Resolviendo la Pérdida de Paquetes para sugerencias sobre cómo abordar problemas de pérdida de paquetes.

Descartes de Paquetes (Gestión de Ancho de Banda)

Si ve muchos descartes de paquetes en la página de Network Analytics, los paquetes se están descartando debido a la gestión de ancho de banda (QoS). Para determinar si su aplicación se ve afectada por esto:

  • Navegue a Network > Priority Analyzer para validar qué clase está descartando paquetes y si su aplicación está asignada a la misma clase.
  • Si este es el caso, considere asignar más ancho de banda para esta clase.
  • Alternativamente, si la aplicación afectada es crítica, muévala a una clase de prioridad más alta para mejorar el rendimiento. Consulte Resolviendo Descartes de Paquetes (QoS) para instrucciones sobre cómo configurar clases.
  • Otra razón para el descarte de paquetes es el micro-burst. Consulte verificación de micro-bursts sobre lo que significa, cómo identificar uno, y finalmente, qué pasos tomar para resolverlo.

Limitaciones de Recursos de Socket

La degradación del rendimiento puede ocurrir cuando el Socket alcanza su limitación de recursos.

1. Máximo Rendimiento Soportado

  • Navegue a Network > Site > Network Analytics y verifique si el rendimiento del sitio está dentro del límite soportado.
  • A continuación se muestran los Máximos de Rendimiento en Túnel Soportados de nuestros modelos de Socket:
    Modelo de Socket Máximo de Rendimiento en Túnel
    X1500 500Mbps
    X1600 1Gbps
    X1600 LTE 1Gbps
    X1700 3Gbps
    X1700B 10Gbps
  • Consulte Guías de Implementación de Cato Socket en la hoja de datos respectiva para más detalles. 
  • Si excede las limitaciones enumeradas, consulte Resolviendo Exceder el Rendimiento Soportado.

2. Alta Utilización de CPU de Socket

  • La sobresaturación de los recursos del Socket también resultará en una degradación del rendimiento.  
  • Desde la webUI del Socket, seleccione la pestaña de HW Status. Esto mostrará el uso actual del % de CPU para cada núcleo. Una utilización consistentemente alta de la CPU impactará directamente el rendimiento del Socket y causará pérdida de paquetes. 
  • Si nota un uso consistentemente alto de la CPU concurrente con la pérdida de paquetes de red, por favor contacte a Soporte para asistencia.
  • Iniciando con Sockets físicos versión 21.1 y Sockets virtuales versión 22, las métricas de Uso de CPU para el Socket ahora son visibles en CMA. Ir a Analíticas de Red en CMA y seleccionar pestaña de Hardware.

  • Además, las métricas de Uso de CPU también están disponibles desde la interfaz de usuario del Socket, en la pestaña Estado de HW.

Consideración de Rendimiento: Rendimiento Activo/Activo de WAN

En entornos WAN Activo/Activo, el rendimiento de las Aplicaciones puede estar limitado cuando todos los flujos de Datos se agregan temporalmente en un solo Enlace WAN en lugar de distribuirse equitativamente a través de Todos los Enlaces disponibles. Cuando esto ocurre, el Rendimiento Total está limitado por el Ancho de Banda de un Enlace, en lugar de utilizar el Ancho de Banda combinado de varios Enlaces.

Este comportamiento puede afectar las expectativas de rendimiento, especialmente para Protocolos como SMB que dependen de múltiples Flujos Concurrentes. La distribución de Flujos está influenciada por Condiciones de red dinámicas y algoritmos Internos, que no siempre pueden garantizar un uso equilibrado a través de los Enlaces.

Nota: Si observa un rendimiento que no se alinea con el rendimiento esperado a través de múltiples Enlaces WAN, por favor Contactar al Soporte de Cato para una mayor Investigación y asistencia.

PoP Sub-Óptimo

Al usar la nube Cato, los clientes pueden notar un rendimiento de aplicación más lento o una reducción en las velocidades de descarga/carga.

  • Para validar, realice una prueba PING en el servicio afectado.
  • Si el RTT devuelto es mayor de lo esperado, valide que el sitio esté conectado a un PoP óptimo navegando a Monitoring > Topology y haciendo clic en el sitio.
  • Aparecerá un panel de ventana a la derecha. Haga clic en "Ver Log" en la parte inferior del panel de la ventana
  • Aparecerá otra ventana. Valide que el ISP esté cerca del PoP conectado.
  • Para resolver esto, consulte Resolviendo PoP Óptimo.

Validación de Reglas de Red

  • Verifique que la conexión afectada cumpla con la regla de red correcta. 
  • Si la aplicación afectada es una aplicación de intercambio de archivos o web, cree una regla de red con aceleración TCP habilitada y coloque la regla en la parte superior de la lista para aislamiento. Consulte Mejores Prácticas para la Aceleración TCP para más detalles.

Latencia Aumentada de la Nube

  • Las aplicaciones, como los servicios SQL, que son sensibles a cambios en la latencia pueden experimentar un tiempo mayor para completar tareas cuando se migran sobre Cato Cloud.
  • La latencia adicional introducida al realizar esas consultas sobre la WAN, incluso si solo son unos pocos milisegundos, realmente se acumula cuando se considera la cantidad de consultas.
  • Para reducir la latencia entre Sitios, se recomienda que considere implementar soluciones de Cato como Aceleración TCPOff-Cloud. o Alt-WAN.
  • Los servicios alojados en entornos de nube pública, como Azure o AWS, pueden aprovechar Cloud Interconnect para reducir significativamente la latencia entre Sitios.
  • Alternativamente, las consultas SQL pueden ser modificadas para un mejor rendimiento sobre Cato Cloud.

Escalado de Ventana para Dispositivos Windows

  • El escalado de ventana en TCP/IP permite que se negocie un tamaño de ventana mayor, permitiendo enviar más datos en cada paquete y mejorando el rendimiento.
  • Debería estar habilitado por defecto. Para validar esto, abra el Símbolo del sistema en el dispositivo Windows y ejecute el comando netsh interface tcp show global.
  • Busque la configuración "Nivel de Afinación Automática de la Ventana de Recepción", que debería estar configurada como "normal".
  • Consulte Habilitación de la Opción de Escalado de Ventana TCP para más detalles.

Opción de Marca de Tiempo TCP para Dispositivos Windows

  • La configuración por defecto para sistemas operativos Windows no soporta la opción de marca de tiempo TCP. Habilite la opción de marca de tiempo TCP para mejorar las mediciones de RTT de paquetes, lo que puede ayudar a identificar mejor la pérdida de paquetes.
  • Esta opción también asiste a la pila TCP en ajustar el temporizador de retransmisión en caso de pérdida de paquetes.
  • Recomendamos habilitar la marca de tiempo TCP en sus computadoras Windows siguiendo estos pasos:
    • Abra el editor del registro en Windows.
    • Navegue a la siguiente clave HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
    • Busque una clave llamada Tcp1323Opts. Si no existe, necesitará crearla como un valor DWORD (32-bit), y nombrarla Tcp1323Opts. Establezca el valor en 2.
    • Reinicie su sistema.
  • Para verificar el estado de las marcas de tiempo TCP ejecute netsh int tcp show global desde el símbolo del sistema. Las marcas de tiempo RFC1323 deberían estar habilitadas.

Pruebas iPerf

  • Otra herramienta de resolución de problemas que ayuda a aislar el problema sería iPerf. Las pruebas iPerf se pueden usar para medir el rendimiento máximo alcanzable en la red. Esto está incluido en el UI web del Socket como parte de pruebas de red y conectividad y es accesible bajo la pestaña de Herramientas.
  • Consulte Probar el enlace con iPerf para obtener más información sobre la realización de pruebas de iPerf en la interfaz de usuario web de Socket.
    Nota: Para obtener resultados más precisos, se recomienda utilizar UDP como protocolo de prueba porque no considera el control de congestión. Tenga en cuenta que esta prueba tiene como objetivo determinar el rendimiento máximo alcanzable del enlace.

(Opcional) Experiencia en la Supervisión del Último Tramo

  • Los clientes con licencia de Experiencia en la Supervisión pueden comprobar las pestañas de Último Tramo y Rendimiento de la Aplicación para posibles pérdidas y descartes de paquetes. los datos pueden correlacionarse con los hallazgos en la pestaña de análisis de red del sitio para comprender mejor de dónde se origina el problema.

Fuera de la Nube

  • Para fines de prueba, considere configurar una instalación fuera de la nube entre los dos sitios. Este enfoque nos permitirá comparar el rendimiento entre en la nube y fuera de la nube.
  • Si el rendimiento es mejor fuera de la nube, esta podría ser la solución permanente al problema de rendimiento.
  • Sin embargo, una cosa a tener en cuenta es que los motores de Protección contra Amenazas de Cato no inspeccionan el tráfico fuera de la nube.
  • Para obtener detalles sobre la configuración, consulte Enrutamiento del Tráfico a un Enlace Fuera de la Nube

Resolviendo Problemas Descubiertos

Resolviendo Mala Configuración

Resolviendo Pérdida de Paquetes

  • Si hay Pérdida de Paquetes en el Último Tramo, reemplace el cable conectado al puerto WAN del Socket.
  • Si es factible, conéctese a un puerto WAN diferente en el Socket y el dispositivo aguas arriba. Si eso no mejoró el problema de pérdida de paquetes en el último tramo, póngase en contacto con su Proveedor de Internet para aislar el problema más a fondo. 
  • Si se observa una alta pérdida de paquetes, considere habilitar la Mitigación de Pérdida de Paquetes para el tráfico VoIP. Consulte Optimización del Tráfico para los detalles.
  • Consulte Cómo Solucionar Pérdida de Paquetes en el Sitio Socket para solucionar problemas detallados sobre la pérdida de paquetes.

Resolviendo Descartes de Paquetes (QoS)

  • Para asignar más ancho de banda a la clase, navegue a Red > Gestión de Ancho de Banda, seleccione la clase afectada y cambie los límites según corresponda.
  • Para mover la aplicación afectada a una clase de mayor prioridad, edite la Regla de Red existente de la aplicación afectada y cambie la prioridad de BW a un valor más bajo (cuanto menor sea el valor, mayor será la prioridad). Alternativamente, cree una nueva Regla de Red y asigne a la prioridad de BW un valor más bajo.
  • Para una guía detallada sobre la Gestión de Ancho de Banda, consulte Configuración de Perfiles de Gestión de Ancho de Banda.

Resolviendo Conexiones a PoP Subóptimos

  • Si el dispositivo no está conectado a un PoP óptimo, verifique si la configuración de "Ubicaciones POP preferidas" está configurada. Para hacer esto, navegue a Red > Sitio > Configuraciones del Sitio > General > Ubicaciones POP preferidas. Si la configuración fue incorrecta, seleccione la ubicación óptima.
  • El Socket se reconectará automáticamente al nuevo PoP preferido definido según configuraciones en Red > Sitios > SLA de conexión. Sin embargo, la reconexión también se puede activar manualmente mediante la acción Reconectar a PoP Preferido, como se explica en Reconectar Manualmente a una Ubicación PoP Preferida.

Resolviendo Exceder el Rendimiento Soportado

  • Comuníquese con su Gerente de Cuenta correspondiente o Gerente de Servicio al Cliente para actualizar a un Socket más grande. Si no está seguro de quiénes son, comuníquese con Soporte.

Presentar casos a Soporte de Cato

Si los pasos anteriores no ayudaron a aislar y resolver el problema, por favor abra un caso con Soporte de Cato. Al abrir un caso, considere las siguientes preguntas y proporcione las respuestas correspondientes: 

  1. ¿El problema afecta a todas las aplicaciones o aplicaciones específicas? 
  2. Si afecta a aplicación(es) específica(s), ¿son nueva(s) aplicación(es)? 
  3. Para nueva(s) aplicación(es), por favor proporcione los detalles, incluyendo nombre de la aplicación, versión, etc.
  4. ¿Qué ha cambiado en aplicación(es) existente(s), que ha llevado al problema?
  5. ¿Este problema afecta a todo(s) los sitio(s) o sitio(s) específico(s)? Si son sitio(s) específico(s), por favor enumere los sitios afectados
  6. ¿dónde está ubicado el servidor si esto afecta a todos los sitios? 

Recolección de Datos

Por favor recopile el autoservicio de Soporte (SSS) mientras replica el problema. Además, instale Wireshark en el dispositivo y capture dos conjuntos de datos de paquetes:

  • El primer conjunto de capturas de paquetes (PCAP) debe capturar el problema de rendimiento. Esto se puede hacer simultáneamente mientras se recopila el SSS.
  • El segundo conjunto de PCAP debe ser recopilado cuando la conexión omite la nube de Cato, es decir, cuando el problema de rendimiento no está presente. Este conjunto de datos servirá como referencia para el Soporte al revisar los registros recopilados y el SSS.
  •  

¿Fue útil este artículo?

Usuarios a los que les pareció útil: 0 de 0

0 comentarios