Problemas de conexión persistentes - Amazon ElastiCache
Grupos de seguridadRed ACLsTablas de enrutamientoDNSresoluciónIdentificación de los problemas con los diagnósticos del lado del servidorValidación de la conectividad de redLímites relacionados con la redCPUUsoConexiones que terminan desde el lado del servidorSolución de problemas del lado del cliente para instancias de Amazon EC2Análisis del tiempo que se tarda en completar una sola solicitud

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Problemas de conexión persistentes

Se deben verificar los siguientes elementos al solucionar los problemas de conectividad persistentes con ElastiCache:

Grupos de seguridad

Los grupos de seguridad son firewalls virtuales que protegen su ElastiCache cliente (EC2instancia, AWS Lambda función, ECS contenedor de Amazon, etc.) y la ElastiCache memoria caché. Además, son firewalls con estado, lo que significa que, después de permitir el tráfico entrante o saliente, las respuestas para ese tráfico se autorizarán automáticamente en el contexto de ese grupo de seguridad específico.

La característica con estado requiere que el grupo de seguridad realice un seguimiento de todas las conexiones autorizadas. Además, hay un límite para las conexiones monitoreadas. Si se alcanza ese límite, las conexiones nuevas producirán errores. Consulte la sección de solución de problemas para obtener ayuda sobre cómo identificar si los límites se han alcanzado por parte del cliente o del ElastiCache lado.

Puede tener un único grupo de seguridad asignado al mismo tiempo al cliente y al ElastiCache clúster, o grupos de seguridad individuales para cada uno.

En ambos casos, debe permitir el tráfico TCP saliente en el ElastiCache puerto de origen y el tráfico entrante en el mismo puerto hacia. ElastiCache El puerto predeterminado es 11211 para Memcached y 6379 para Valkey o Redis. OSS De forma predeterminada, los grupos de seguridad permiten el tráfico de salida. En este caso, solo se requiere la regla de entrada en el grupo de seguridad de destino.

Para obtener más información, consulta Patrones de acceso para acceder a un ElastiCache clúster en Amazon VPC.

Red ACLs

Las listas de control de acceso a la red (ACLs) son reglas sin estado. El tráfico debe estar permitido en ambas direcciones (tanto de entrada como de salida) para tener éxito. ACLsLas redes se asignan a subredes, no a recursos específicos. Es posible tener ACL asignado el mismo recurso al cliente ElastiCache y al mismo recurso, especialmente si están en la misma subred.

De forma predeterminada, la red ACLs permite todo el tráfico. Sin embargo, se pueden modificar para denegar o permitir el tráfico. Además, la evaluación de ACL las reglas es secuencial, lo que significa que la regla con el número más bajo que coincida con el tráfico lo permitirá o denegará. La configuración mínima para permitir el tráfico de Valkey o Redis esOSS:

Red del lado del cliente: ACL

  • Reglas de entrada:

  • Número de regla: preferiblemente inferior a cualquier regla de denegación

  • Tipo: TCP regla personalizada;

  • Protocolo: TCP

  • Intervalo de puertos: 1024-65535

  • Fuente: 0.0.0.0/0 (o cree reglas individuales para las subredes del clúster) ElastiCache

  • Permitir/Denegar: Permitir

  • Reglas salientes

  • Número de regla: preferiblemente inferior a cualquier regla de denegación

  • Tipo: TCP regla personalizada;

  • Protocolo: TCP

  • Intervalo de puertos: 6379

  • Fuente: 0.0.0.0/0 (o las subredes del clúster). ElastiCache Tenga en cuenta que el uso de dispositivos específicos IPs puede provocar problemas (en caso de conmutación por error o de escalado del clúster)

  • Permitir/Denegar: Permitir

ElastiCache RedACL:

  • Reglas de entrada:

  • Número de regla: preferiblemente inferior a cualquier regla de denegación

  • Tipo: TCP regla personalizada;

  • Protocolo: TCP

  • Intervalo de puertos: 6379

  • Fuente: 0.0.0.0/0 (o cree reglas individuales para las subredes del clúster) ElastiCache

  • Permitir/Denegar: Permitir

  • Reglas salientes

  • Número de regla: preferiblemente inferior a cualquier regla de denegación

  • Tipo: TCP regla personalizada;

  • Protocolo: TCP

  • Intervalo de puertos: 1024-65535

  • Fuente: 0.0.0.0/0 (o las subredes del clúster). ElastiCache Tenga en cuenta que el uso de dispositivos específicos IPs puede provocar problemas (en caso de conmutación por error o de escalado del clúster)

  • Permitir/Denegar: Permitir

Para obtener más información, consulte Red ACLs.

Tablas de enrutamiento

Al igual que en NetworkACLs, cada subred puede tener diferentes tablas de enrutamiento. Si los clientes y el ElastiCache clúster están en subredes diferentes, asegúrese de que sus tablas de enrutamiento les permitan comunicarse entre sí.

Los entornos más complejos, que implican múltiples VPCs enrutamientos dinámicos o firewalls de red, pueden resultar difíciles de solucionar. Consulte Validación de la conectividad de red para confirmar que la configuración de red es adecuada.

DNSresolución

ElastiCache proporciona los puntos finales del servicio en función de los DNS nombres. Los puntos de enlace disponibles son los puntos Configuration, Primary, Reader y Node. Para obtener más información, consulte Búsqueda de puntos de enlace de conexión.

En caso de conmutación por error o de modificación del clúster, la dirección asociada al nombre del punto de conexión puede cambiar y se actualizará de forma automática.

Es posible que la DNS configuración personalizada (es decir, no usar el VPC DNS servicio) no reconozca los nombres ElastiCache proporcionadosDNS. Asegúrese de que su sistema pueda resolver correctamente los ElastiCache puntos finales utilizando herramientas del sistema como dig (como se muestra a continuación) o. nslookup

$ dig +short example.xxxxxx.ng.0001.use1.cache.amazonaws.com
example-001.xxxxxx.0001.use1.cache.amazonaws.com.
1.2.3.4

También puede forzar la resolución del nombre a través del VPC DNS servicio:

$ dig +short example.xxxxxx.ng.0001.use1.cache.amazonaws.com @169.254.169.253
example-001.tihewd.0001.use1.cache.amazonaws.com.
1.2.3.4

Identificación de los problemas con los diagnósticos del lado del servidor

CloudWatch Las métricas y la información sobre el tiempo de ejecución ElastiCache del motor son fuentes o información comunes para identificar las posibles fuentes de problemas de conexión. En general, un buen análisis comienza con los siguientes elementos:

  • CPUUso: Valkey y Redis OSS son aplicaciones de subprocesos múltiples. Sin embargo, la ejecución de cada comando ocurre en un solo subproceso (principal). Por este motivo, ElastiCache proporciona las métricas y. CPUUtilization EngineCPUUtilization EngineCPUUtilizationproporciona la CPU utilización dedicada al OSS proceso de Valkey o Redis, y CPUUtilization el uso en todos ellos. vCPUs Los nodos con más de una v CPU suelen tener valores diferentes para CPUUtilization yEngineCPUUtilization, normalmente, el segundo es más alto. El valor alto EngineCPUUtilization puede deberse a un número elevado de solicitudes o a operaciones complejas que tardan mucho CPU tiempo en completarse. Ambos se pueden identificar por:

    • Un número elevado de solicitudes: verifique si hay aumentos en otras métricas que coincidan con el patrón de EngineCPUUtilization. Las métricas útiles son:

      • CacheHits y CacheMisses: el número de solicitudes correctas o solicitudes que no han encontrado un elemento válido en la caché Si la proporción de los errores en comparación con los aciertos es alta, la aplicación está perdiendo tiempo y consta de recursos con solicitudes poco útiles.

      • SetTypeCmds y GetTypeCmds: estas métricas, las cuales se encuentran correlacionadas con EngineCPUUtilization, pueden ayudar a entender si la carga es mucho más elevada para las solicitudes de escritura (medida por SetTypeCmds) o lecturas (medida por GetTypeCmds). Si la carga son lecturas en su gran mayoría, el uso de varias réplicas de lectura puede equilibrar las solicitudes en varios nodos y ahorrar las principales para las escrituras. En los clústeres con el modo de clúster desactivado, el uso de réplicas de lectura se puede realizar creando una configuración de conexión adicional en la aplicación mediante el punto final del lector. ElastiCache Para obtener más información, consulte Búsqueda de puntos de enlace de conexión. Las operaciones de lectura deben enviarse a esta conexión adicional. Las operaciones de escritura se realizarán a través del punto de conexión principal habitual. En el modo de clúster habilitado, se aconseja utilizar una biblioteca que admita réplicas de lectura por defecto. Con los indicadores correctos, la biblioteca podrá descubrir automáticamente la topología del clúster y los nodos de la réplica, habilitar las operaciones de lectura mediante el OSS comando READONLYValkey o Redis y enviar las solicitudes de lectura a las réplicas.

    • Número elevado de conexiones:

      • CurrConnections y NewConnections: CurrConnection muestra el número de conexiones establecidas en el momento de la recopilación de puntos de datos, mientras que NewConnections muestra cuántas conexiones se crearon en el periodo.

        Crear y gestionar las conexiones implica una sobrecarga considerable. CPU Además, el apretón de manos de TCP tres vías necesario para crear nuevas conexiones afectará negativamente a los tiempos de respuesta generales.

        Un ElastiCache nodo con miles de frecuencias NewConnections por minuto indica que la conexión se crea y se utiliza con solo unos pocos comandos, lo que no es óptimo. Una práctica recomendada es mantener las conexiones establecidas y reutilizarlas para operaciones nuevas. Esto es posible cuando la aplicación de cliente admite e implementa correctamente la agrupación de conexiones o conexiones persistentes. Con la agrupación de conexiones, el número de currConnections no tiene grandes variaciones y NewConnections debe ser lo más bajo posible. Valkey y Redis OSS ofrecen un rendimiento óptimo con un número reducido de. currConnections Si se mantienen currConnection en el orden de decenas o cientos, se minimiza el uso de recursos para admitir conexiones individuales, como los búferes de los clientes y los CPU ciclos de servicio de la conexión.

    • Rendimiento de la red:

      • Determine el ancho de banda: ElastiCache los nodos tienen un ancho de banda de red proporcional al tamaño del nodo. Dado que las aplicaciones tienen características diferentes, los resultados pueden variar según la carga de trabajo. Por ejemplo, las aplicaciones con una alta tasa de solicitudes pequeñas tienden a afectar más al CPU uso que al rendimiento de la red, mientras que las claves más grandes provocan una mayor utilización de la red. Por esta razón, se aconseja probar los nodos con la carga de trabajo real para una mejor comprensión de los límites.

        Simular la carga desde la aplicación proporcionaría resultados más precisos. Sin embargo, las herramientas de punto de referencia pueden transmitir una buena noción de los límites.

      • Para los casos en los que las solicitudes son principalmente lecturas, el uso de réplicas para operaciones de lectura aliviará la carga en el nodo primario. Si el caso de uso es predominantemente de escrituras, el uso de muchas réplicas amplificará el uso de la red. Por cada byte escrito en el nodo primario, se enviarán N bytes a las réplicas, siendo N el número de réplicas. La mejor práctica para las cargas de trabajo con un uso intensivo de escritura es utilizar ElastiCache (RedisOSS) con el modo de clúster activado, de modo que las escrituras se puedan equilibrar entre varios fragmentos, o ampliarlas a un tipo de nodo con más capacidades de red.

      • Los valores CloudWatchmetrics NetworkBytesIn y NetworkBytesOut proporcionan la cantidad de datos que entran o salen del nodo, respectivamente. ReplicationByteses el tráfico dedicado a la replicación de datos.

      Para obtener más información, consulte Límites relacionados con la red.

    • Comandos complejos: los comandos de Redis OSS se envían en un único subproceso, lo que significa que las solicitudes se atienden de forma secuencial. Un solo comando lento puede afectar a otras solicitudes y conexiones, lo que genera tiempos de espera. El uso de comandos que actúan sobre varios valores, claves o tipos de datos debe efectuarse con cuidado. Las conexiones pueden bloquearse o interrumpirse en función del número de parámetros o del tamaño de sus valores de entrada o de salida.

      Un ejemplo notorio es el comando KEYS. Analiza todo el espacio de claves en la búsqueda de un patrón dado y bloquea la puesta en marcha de otros comandos durante su ejecución. Redis OSS usa la notación «O grande» para describir la complejidad de sus comandos.

      El comando de claves tiene una complejidad de tiempo O(N), siendo N el número de claves en la base de datos. Por lo tanto, cuanto mayor sea el número de claves, más lento será el comando. Sin embargo, el comando KEYS puede causar problemas de diferentes maneras. Si no se utiliza un patrón de búsqueda, el comando devolverá todos los nombres de clave disponibles. En las bases de datos con miles o millones de elementos, se creará una enorme salida que saturará a los búferes de red.

      Si se utiliza un patrón de búsqueda, solo las claves que coincidan con el patrón volverán al cliente. No obstante, el motor todavía barrerá todo el espacio de claves en búsqueda de dicho patrón y el tiempo para completar el comando será el mismo.

      Una alternativa para KEYS es el comando SCAN. Vuelve a repetir el proceso sobre el espacio de claves y limita las iteraciones en un número específico de elementos, al evitar bloqueos prolongados en el motor.

      El escaneo tiene el parámetro COUNT, el cual se utiliza para establecer el tamaño de los bloques de iteración. El valor predeterminado es 10 (10 elementos por iteración).

      En función del número de elementos en la base de datos, los bloques de valores COUNT pequeños requerirán más iteraciones para completar un análisis completo, mientras que los valores más grandes mantendrán al motor ocupado durante más tiempo en cada iteración. Mientras que los valores de conteo pequeños harán SCAN más lento en las bases de datos de gran tamaño, los valores más elevados pueden causar los mismos problemas presentados para KEYS.

      Por ejemplo, ejecutar el comando SCAN con un valor de conteo en 10 requerirá 100 000 repeticiones en una base de datos con 1 millón de claves. Si el tiempo promedio de ida y vuelta de la red es de 0,5 milisegundos, cerca de 50 000 milisegundos (50 segundos) se utilizarán para transferir solicitudes.

      Por otro lado, si el valor de conteo fuera 100 000, se requerirá una sola iteración y solo se gastarían 0,5 ms para transferirla. Sin embargo, el motor se encontraría completamente bloqueado para otras operaciones hasta que el comando termine de analizar todo el espacio de claves.

      Además de KEYS, existen otros comandos que son potencialmente dañinos si no se utilizan correctamente. Para ver una lista de todos los comandos y su complejidad temporal respectiva, vaya a los comandos de Valkey y OSS Redis.

      Ejemplos de problemas posibles:

      • Secuencias de comandos de Lua: Valkey y Redis incluyen un intérprete OSS de Lua integrado, que permite la ejecución de secuencias de comandos en el servidor. Los scripts de Lua de Valkey y Redis OSS se ejecutan a nivel de motor y son atómicos por definición, lo que significa que no se permitirá ejecutar ningún otro comando o script mientras el script esté en ejecución. Los scripts de Lua ofrecen la posibilidad de ejecutar varios comandos, algoritmos de toma de decisiones, análisis de datos y otros directamente en el motor. Mientras que la atomicidad de los scripts y la posibilidad de descargar la aplicación son tentadoras, los scripts deben emplearse con cuidado y para pequeñas operaciones. Sí ElastiCache, el tiempo de ejecución de los scripts de Lua está limitado a 5 segundos. Los scripts que no se hayan escrito en el espacio de claves se interrumpirán de manera automática después del periodo de 5 segundos. Para evitar la corrupción de datos y las inconsistencias, el nodo realizará una conmutación por error si la ejecución del script no se ha completado en 5 segundos y ha tenido alguna escritura durante su ejecución. Las transacciones son la alternativa para garantizar la coherencia de las múltiples modificaciones clave relacionadas en OSS Redis. Una transacción permite la ejecución de un bloque de comandos al observar las claves existentes en busca de modificaciones. Si alguna de las claves observadas cambia antes de la finalización de la transacción, se descartan todas las modificaciones.

      • Eliminación masiva de elementos: el comando DEL acepta varios parámetros, los cuales son los nombres clave que se eliminarán. Las operaciones de borrado son sincrónicas y tardarán CPU bastante tiempo si la lista de parámetros es grande o contiene una lista grande, un conjunto, un conjunto ordenado o un hash (estructuras de datos que contienen varios subelementos). En otras palabras, incluso la eliminación de una sola clave puede tomar un tiempo considerable si tiene muchos elementos. La alternativa DEL esUNLINK, que es un comando asíncrono disponible desde Redis 4. OSS UNLINKdebe preferirse a él siempre que sea posible. DEL A partir de ElastiCache (RedisOSS) 6x, el lazyfree-lazy-user-del parámetro hace que el DEL comando se comporte igual que UNLINK cuando está activado. Para obtener más información, consulte Cambios de parámetros de Redis OSS 6.0.

      • Comandos que actúan sobre varias claves: se mencionó el comando DEL como un comando que acepta varios argumentos y su tiempo de ejecución será directamente proporcional a eso. Sin embargo, Redis OSS proporciona muchos más comandos que funcionan de forma similar. Por ejemplo, los comandos MSET y MGET permiten la inserción o recuperación de varias claves de cadena a la vez. Su uso puede resultar beneficioso para reducir la latencia de la red inherente a varios comandos SET o GET individuales. Sin embargo, una lista extensa de parámetros afectará al CPU uso.

        Si bien la CPU utilización por sí sola no es la causa de los problemas de conectividad, dedicar demasiado tiempo a procesar uno o varios comandos con varias teclas puede provocar el fallo de otras solicitudes y aumentar CPU la utilización general.

        El número y el tamaño de las claves afectarán a la complejidad del comando y, en consecuencia, al tiempo de finalización.

        Otros ejemplos de comandos que pueden actuar sobre varias claves son HMGET, HMSET, MSETNX, PFCOUNT, PFMERGE, SDIFF, SDIFFSTORE, SINTER, SINTERSTORE, SUNION, SUNIONSTORE, TOUCH, ZDIFF, ZDIFFSTORE, ZINTER y ZINTERSTORE.

      • Comandos que actúan sobre varios tipos de datos: Redis OSS también proporciona comandos que actúan sobre una o varias teclas, independientemente del tipo de datos. ElastiCache (RedisOSS) proporciona la métrica KeyBasedCmds para supervisar dichos comandos. Esta métrica suma la ejecución de los siguientes comandos en el periodo seleccionado:

        • Complejidad O(N):

          • KEYS

        • O(1)

          • EXISTS

          • OBJECT

          • PTTL

          • RANDOMKEY

          • TTL

          • TYPE

          • EXPIRE

          • EXPIREAT

          • MOVE

          • PERSIST

          • PEXPIRE

          • PEXPIREAT

          • UNLINK (O(N) para recuperar la memoria. No obstante, la tarea de recuperación de memoria ocurre en un subproceso aparte y no bloquea el motor.

        • Tiempos de complejidad diferentes según el tipo de datos:

          • DEL

          • DUMP

          • Se estima que el comando RENAME tiene una complejidad O(1), pero ejecuta DEL internamente. El tiempo de ejecución variará en función del tamaño de la clave que ha sido renombrada.

          • RENAMENX

          • RESTORE

          • SORT

        • Hash de gran tamaño: un hash es un tipo de datos que permite una sola clave con varios subelementos de valor de clave. Cada hash puede almacenar 4 294 967 295 elementos y las operaciones en hash grandes pueden volverse costosas. Del mismo modo que KEYS, los hashes tienen el comando HKEYS con una complejidad de tiempo O(N), siendo N el número de elementos en el hash. Se recomienda emplear HSCAN antes que HKEYS para evitar comandos de larga ejecución. Los comandos HDEL, HGETALL, HMGET, HMSET y HVALS se deben utilizar con precaución en hashes grandes.

      • Otras estructuras de macrodatos: además de los hashes, otras estructuras de datos pueden ser intensivas. CPU Los conjuntos, las listas, los conjuntos ordenados y los Hyperloglogs también pueden demorar en gestionarse en función del tamaño y de los comandos utilizados. Para obtener más información sobre estos comandos, consulte los comandos de Valkey y Redis. OSS

Validación de la conectividad de red

Tras revisar las configuraciones de red relacionadas con la DNS resolución, los grupos de seguridad, la red ACLs y las tablas de enrutamiento, la conectividad se puede validar con el VPC Reachability Analyzer y las herramientas del sistema.

Reachability Analyzer probará la conectividad de red y confirmará si se cumplen todos los requisitos y permisos. Para realizar las siguientes pruebas, necesitará el ENI ID (identificación de la interfaz de red elástica) de uno de los ElastiCache nodos disponibles en su ordenador. VPC Para ello, puede realizar lo siguiente:

  1. ¿Ir a la https://console.aws.amazon.com/ec2/v2/home? #: NIC

  2. Filtre la lista de interfaces por el nombre del ElastiCache clúster o la dirección IP obtenida de las DNS validaciones anteriores.

  3. Anote o guarde el ID de otro modo. ENI Si se muestran varias interfaces, revise la descripción para confirmar que pertenecen al ElastiCache clúster correcto y elija una de ellas.

  4. Continúe con el siguiente paso.

  5. ¿Crear una ruta de análisis en https://console.aws.amazon.com/vpc/casa? # ReachabilityAnalyzer y elige las siguientes opciones:

    • Tipo de fuente: elija instancia si su ElastiCache cliente se ejecuta en una EC2 instancia de Amazon o una interfaz de red (si usa otro servicio, como AWS Fargate Amazon ECS con una red awsvpc AWS Lambda, etc.) y el ID de recurso respectivo (EC2instancia o ENI ID);

    • Tipo de destino: elija la interfaz de red y seleccione Elasticache ENI de la lista.

    • Puerto de destino: especifique 6379 para ElastiCache (RedisOSS) o 11211 para (Memcached). ElastiCache Estos son los puertos definidos con la configuración predeterminada y en este ejemplo se supone que no se modifican.

    • Protocolo: TCP

Cree la ruta de análisis y espere unos momentos para obtener el resultado. Si no se puede acceder al estado, abra los detalles del análisis y revise el Explorador de análisis para conocer los detalles en los que se bloquearon las solicitudes.

Si se han superado las pruebas de accesibilidad, proceda a la verificación a nivel del sistema operativo.

Para validar la TCP conectividad en el puerto de ElastiCache servicio: en Amazon Linux, Nping está disponible en el paquete nmap y permite probar la TCP conectividad en el ElastiCache puerto, además de proporcionar a la red un tiempo de ida y vuelta para establecer la conexión. Úselo para validar la conectividad de la red y la latencia actual con el ElastiCache clúster, como se muestra a continuación: 

$ sudo nping --tcp -p 6379 example.xxxxxx.ng.0001.use1.cache.amazonaws.com

Starting Nping 0.6.40 ( http://nmap.org/nping ) at 2020-12-30 16:48 UTC
SENT (0.0495s) TCP ...
(Output suppressed )

Max rtt: 0.937ms | Min rtt: 0.318ms | Avg rtt: 0.449ms
Raw packets sent: 5 (200B) | Rcvd: 5 (220B) | Lost: 0 (0.00%)
Nping done: 1 IP address pinged in 4.08 seconds

De forma predeterminada, nping envía 5 sondas con un retraso de 1 segundo entre ellas. Puede utilizar la opción “-c” para aumentar el número de sondas y “-delay” a fin de cambiar el tiempo en que se envía una prueba nueva.

Si las pruebas nping fallan y las del VPCReachability Analyzer se superan, pídale al administrador del sistema que revise las posibles reglas de firewall basadas en el host, las reglas de enrutamiento asimétrico o cualquier otra posible restricción a nivel del sistema operativo.

En la ElastiCache consola, compruebe si el cifrado en tránsito está activado en los detalles de su clúster. ElastiCache Si el cifrado en tránsito está habilitado, confirme si la TLS sesión se puede establecer con el siguiente comando:

openssl s_client -connect example.xxxxxx.use1.cache.amazonaws.com:6379

Se espera obtener un resultado extenso si la conexión y la TLS negociación se realizan correctamente. Verifique el código de retorno que se encuentra disponible en la última línea, el valor debe ser 0 (ok). Si openssl devuelve algo diferente, comprueba el motivo del error en https://www.openssl.org/docs/man1.0.2/man1/verify.html #. DIAGNOSTICS

Si se han superado todas las pruebas de infraestructura y sistema operativo, pero la aplicación sigue sin poder conectarse a ellos ElastiCache, compruebe si las configuraciones de la aplicación cumplen con los ElastiCache parámetros. Los errores frecuentes son:

  • Su aplicación no admite el modo de ElastiCache clúster y ElastiCache tiene el modo de clúster activado;

  • Su aplicación no admiteTLS/y ElastiCache tiene activado SSL el cifrado en tránsito;

  • La aplicación es compatible conTLS/SSL, pero no tiene los indicadores de configuración correctos ni las autoridades de certificación de confianza;

Límites relacionados con la red

  • Número máximo de conexiones: hay límites estrictos para conexiones simultáneas. Cada ElastiCache nodo permite hasta 65 000 conexiones simultáneas en todos los clientes. Este límite se puede monitorizar a través de las CurrConnections métricas CloudWatch activadas. Sin embargo, los clientes también tienen sus límites para las conexiones de salida. En Linux, verifique el rango de puertos efímeros permitido con el comando:

    # sysctl net.ipv4.ip_local_port_range
net.ipv4.ip_local_port_range = 32768 60999

    En el ejemplo anterior, se permitirán 28231 conexiones desde el mismo origen, a la misma IP (ElastiCache nodo) y puerto de destino. El siguiente comando muestra cuántas conexiones existen para un ElastiCache nodo específico (IP 1.2.3.4):

    ss --numeric --tcp state connected "dst 1.2.3.4 and dport == 6379" | grep -vE '^State' | wc -l

    Si el número es demasiado alto, es posible que el sistema se sobrecargue al intentar procesar las solicitudes de conexión. Se recomienda considerar la implementación de técnicas tales como la agrupación de conexiones o conexiones persistentes para controlar las conexiones con mayor facilidad. Siempre que sea posible, configure el grupo de conexiones para limitar el número máximo de conexiones a unos pocos cientos. Además, se recomienda seguir la lógica del retardo para controlar los tiempos de espera u otras excepciones de conexión a fin de evitar la pérdida de conexión en caso de problemas.

  • Límites de tráfico de red: compruebe las siguientes CloudWatch métricas para que Redis identifique OSS los posibles límites de red que se estén alcanzando en el nodo: ElastiCache

    • NetworkBandwidthInAllowanceExceeded/NetworkBandwidthOutAllowanceExceeded: paquetes de red configurados porque el rendimiento superó el límite de banda ancha agregado.

      Es importante tener en cuenta que cada byte escrito en el nodo primario se replicará en N réplicas, siendo N el número de réplicas. Es posible que los clústeres con tipos de nodos pequeños, varias réplicas y solicitudes de escritura intensivas no puedan afrontar al retraso de la reproducción. En estos casos, es una práctica recomendada escalar verticalmente (cambiar el tipo de nodo), escalar horizontalmente (agregar particiones en clústeres en modo de clúster habilitado) y disminuir el número de réplicas o el de escrituras.

    • NetworkConntrackAllowanceExceeded: paquetes configurados porque se ha superado el número máximo de conexiones rastreadas en todos los grupos de seguridad asignados al nodo. Es probable que las conexiones nuevas fallen durante este periodo.

    • NetworkPackets PerSecondAllowanceExceeded: se ha superado el número máximo de paquetes por segundo. Las cargas de trabajo basadas en una alta tasa de solicitudes muy pequeñas pueden alcanzar este límite antes de la banda ancha máxima.

    Las métricas mencionadas son una manera ideal de confirmar que los nodos alcanzan sus límites de red. No obstante, los límites también son identificables por periodos de estancamiento en las métricas de la red.

    Si las mesetas se mantienen durante períodos prolongados, es probable que vayan seguidas de un retraso en la replicación, un aumento del número de bytes utilizados en la memoria caché, una disminución de la memoria liberable y un alto nivel de intercambio y uso. CPU EC2Las instancias de Amazon también tienen límites de red que se pueden rastrear a través de las métricas de los ENA conductores. Las instancias de Linux con soporte de red mejorado y ENA controladores de la versión 2.2.10 o posteriores pueden revisar los contadores de límites con el comando:

    # ethtool -S eth0 | grep "allowance_exceeded"

CPUUso

La métrica de CPU uso es el punto de partida de la investigación, y los siguientes elementos pueden ayudar a reducir los posibles problemas ElastiCache secundarios:

  • Redis OSS SlowLogs: La configuración ElastiCache predeterminada conserva los últimos 128 comandos que tardaron más de 10 milisegundos en completarse. El historial de comandos lentos se mantiene durante el tiempo de ejecución del motor y se perderá en caso de interrupción o de reinicio. Si la lista alcanza 128 entradas, los eventos antiguos se eliminarán para crear espacio para otros nuevos. El tamaño de la lista de eventos lentos y el tiempo de ejecución que se considera lento puede modificarse a través de los parámetros slowlog-max-len y slowlog-log-slower-than en un grupo de parámetros personalizados. La lista de registros lentos se puede recuperar al ejecutar SLOWLOG GET 128 en el motor, siendo 128 los últimos 128 comandos lentos informados. Cada entrada cuenta con los siguientes campos:

    1) 1) (integer) 1 -----------> Sequential ID
   2) (integer) 1609010767 --> Timestamp (Unix epoch time)of the Event
   3) (integer) 4823378 -----> Time in microseconds to complete the command.
   4) 1) "keys" -------------> Command
      2) "*" ----------------> Arguments 
   5) "1.2.3.4:57004"-> Source

    El evento anterior ocurrió el 26 de diciembre a las UTC 19:26:07, tardó 4,8 segundos (4,823 ms) en completarse y se debió al KEYS comando 1.2.3.4 solicitado al cliente.

    En Linux, la marca de tiempo puede convertirse con la fecha del comando:

    $ date --date='@1609010767'
Sat Dec 26 19:26:07 UTC 2020

    Con Python:

    >>> from datetime import datetime
>>> datetime.fromtimestamp(1609010767)
datetime.datetime(2020, 12, 26, 19, 26, 7)

    O PowerShell en Windows con:

    PS D:\Users\user> [datetimeoffset]::FromUnixTimeSeconds('1609010767')
DateTime      : 12/26/2020 7:26:07 PM
UtcDateTime  
                : 12/26/2020 7:26:07 PM
LocalDateTime : 12/26/2020 2:26:07 PM
Date          : 12/26/2020 12:00:00 AM
Day           : 26
DayOfWeek    
                : Saturday
DayOfYear     : 361
Hour          : 19
Millisecond   : 0
Minute        : 26
Month        
                : 12
Offset        : 00:00:00Ticks         : 637446075670000000
UtcTicks     
                : 637446075670000000
TimeOfDay     : 19:26:07
Year          : 2020

    Muchos comandos lentos en un corto periodo de tiempo (el mismo minuto o menos) son motivo de preocupación. Revise la naturaleza de los comandos y cómo se pueden optimizar (consulte los ejemplos anteriores). Si se informa con frecuencia de comandos con una complejidad temporal de O (1), compruebe los demás factores de CPU uso elevado mencionados anteriormente.

  • Métricas de latencia: ElastiCache (RedisOSS) proporciona CloudWatch métricas para monitorear la latencia promedio de diferentes clases de comandos. El punto de datos se calcula al dividir el número total de ejecuciones de comandos en la categoría por el tiempo total de ejecución en el periodo. Es importante entender que los resultados de la métrica de latencia son un agregado de varios comandos. Un solo comando puede provocar resultados inesperados, como tiempos de espera, sin un impacto significativo en las métricas. En tales casos, los eventos de registro lento serían una fuente de información más precisa. La siguiente lista contiene las métricas de latencia disponibles y los comandos respectivos que les afectan.

    • EvalBasedCmdsLatency: relacionado con los comandos de Lua Script,,; eval evalsha

    • GeoSpatialBasedCmdsLatency: geodist, geohash, geopos, georadius, georadiusbymember, geoadd;

    • GetTypeCmdsLatency: Lee los comandos, independientemente del tipo de datos;

    • HashBasedCmdsLatency: hexists, hget, hgetall, hkeys, hlen, hmget, hvals, hstrlen, hdel, hincrby, hincrbyfloat, hmset, hset, hsetnx;

    • HyperLogLogBasedCmdsLatency: pfselftest, pfcount, pfdebug, pfadd, pfmerge;

    • KeyBasedCmdsLatency: Comandos que pueden actuar sobre diferentes tipos de datos: dumpexists,keys,object,pttl,,randomkey,ttl,type,del,expire,expireat,move,persist,pexpire,pexpireat,,rename,renamenx,restoreK,sort,unlink;

    • ListBasedCmdsLatency: lindex, len, lrange, blop, broplpush, linsert, pop, push, pushx, lrem, let, ltrim, rpop, proplpush, rpushx;

    • PubSubBasedCmdsLatency: psubscribe, publish, pubsub, punsubscribe, subscribe, unsubscribe;

    • SetBasedCmdsLatency: scard, sdiff, sinter, sismember, smembers, srandmember, sunion, sadd, sdiffstore, sinterstore, smove, spop, srem, sunionstore;

    • SetTypeCmdsLatency: Escribe comandos, independientemente del tipo de datos;

    • SortedSetBasedCmdsLatency: zcard, zcount, zrange, zrangebyscore, zrank, zrevrange, zrevrangebyscore, zrevrank, zscore, zrangebylex, zrevrangebylex, zlexcount, zadd. zincrby, zinterstore, zrem, zremrangebyrank, zremrangebyscore, zunionstore, zremrangebylex, zpopmax, zpopmin, bzpopmin, bzpopmax;

    • StringBasedCmdsLatency: bitcount, get, getbit, getrange, mget, strlen, substr, bitpos, append, bitop, bitfield, decr, decrby, getset, incr, incrby, incrbyfloat, mset, msetnx, psetex, set, setbit, setex, setnx, setrange;

    • StreamBasedCmdsLatency: xrange, xrevrange, xlen, xread, xpending, xinfo, xadd, xgroup, readgroup, xack, xclaim, xdel, xtrim, xsetid;

  • Comandos de tiempo de OSS ejecución de Redis:

    • info commandstats: proporciona una lista de los comandos ejecutados desde que se inició el OSS motor Redis, su número acumulado de ejecuciones, el tiempo total de ejecución y el tiempo medio de ejecución por comando;

    • client list: proporciona una lista de clientes conectados actualmente e información relevante como el uso de los búferes, el último comando ejecutado, entre otros.

  • Backup y replicación: las versiones ElastiCache (RedisOSS) anteriores a la 2.8.22 utilizan un proceso bifurcado para crear copias de seguridad y procesar sincronizaciones completas con las réplicas. Este método puede incurrir en una sobrecarga significativa de la memoria para casos de uso intensivos de escritura.

    A partir de la versión OSS 2.8.22 de ElastiCache Redis, se introdujo un método de copia de seguridad y replicación sin bifurcaciones. AWS El método nuevo puede retrasar las escrituras a fin de evitar errores. Ambos métodos pueden provocar períodos de mayor CPU utilización, aumentar los tiempos de respuesta y, en consecuencia, provocar tiempos de espera de los clientes durante su ejecución. Siempre verifique si los errores del cliente se producen durante el periodo de copia de seguridad o si la métrica SaveInProgress fue 1 en el periodo. Se aconseja programar el periodo de copia de seguridad para periodos de baja utilización con el objetivo de minimizar los posibles problemas con los clientes o los errores de la copia de seguridad.

Conexiones que terminan desde el lado del servidor

La configuración predeterminada ElastiCache (RedisOSS) mantiene las conexiones de los clientes establecidas indefinidamente. Sin embargo, en algunos casos, la interrupción de la conexión puede ser deseable. Por ejemplo:

  • Los errores en la aplicación cliente pueden hacer que se olviden las conexiones y que se mantengan establecidas con un estado inactivo. Esto se denomina “fuga de conexión”. Su consecuencia es un aumento constante en el número de conexiones establecidas que se observaron en la métrica CurrConnections. Este comportamiento puede provocar una saturación en el cliente o ElastiCache en el lado. Cuando no es posible realizar una solución inmediata desde el lado del cliente, algunos administradores establecen un valor de «tiempo de espera» en su grupo de ElastiCache parámetros. El tiempo de espera es el tiempo permitido (medido en segundos) para que las conexiones inactivas persistan. Si el cliente no envía ninguna solicitud durante el período, el OSS motor Redis finalizará la conexión en cuanto la conexión alcance el valor de tiempo de espera. Los valores de tiempo de espera pequeños pueden dar lugar a desconexiones innecesarias de manera que los clientes necesitarán ocuparse correctamente de ellas y volver a conectarse, lo que genera retrasos.

  • La memoria empleada para almacenar claves se comparte con los búferes del cliente. Los clientes lentos con grandes solicitudes o respuestas pueden exigir una cantidad significativa de memoria para operar sus búferes. La configuración predeterminada ElastiCache (RedisOSS) no restringe el tamaño de los búferes de salida normales del cliente. Si se alcanza el límite de maxmemory, el motor intentará expulsar elementos para cumplir con el uso del búfer. En condiciones de muy poca memoria, ElastiCache (RedisOSS) puede optar por desconectar los clientes que consumen grandes búferes de salida de clientes para liberar memoria y conservar el estado del clúster.

    Se puede limitar el tamaño de los búferes de cliente mediante configuraciones personalizadas por lo que cuando un cliente alcance ese límite se desconectará. No obstante, los clientes deben ser capaces de resolver desconexiones inesperadas. Los parámetros para manejar el tamaño de los búferes para los clientes regulares son los siguientes:

    • client-query-buffer-limit: Tamaño máximo de una sola solicitud de entrada;

    • client-output-buffer-limit-normal-soft-limit: Límite flexible para las conexiones de los clientes. La conexión finalizará si se mantiene por encima del límite flexible durante más tiempo del tiempo en segundos definido normal-soft-seconds o si sobrepasa el límite estricto; client-output-buffer-limit

    • client-output-buffer-limit-normal-soft-seconds: Tiempo permitido para las conexiones que superen el client-output-buffer-limit -normal-soft-limit;

    • client-output-buffer-limit-normal-hard-limit: Una conexión que alcance este límite finalizará inmediatamente.

    Además de los búferes de los clientes frecuentes, las siguientes opciones controlan el búfer para los nodos de réplica y los clientes de publicación/suscripción:

    • client-output-buffer-limit-replica-hard-limit;

    • client-output-buffer-limit-replica-soft-seconds;

    • client-output-buffer-limit-replica-hard-limit;

    • client-output-buffer-limit-pubsub-soft-limit;

    • client-output-buffer-limit-pubsub-soft-seconds;

    • client-output-buffer-limit-pubsub-hard-limit;

Solución de problemas del lado del cliente para instancias de Amazon EC2

La carga y la capacidad de respuesta del lado del cliente también pueden afectar a las solicitudes. ElastiCache EC2Los límites de las instancias y del sistema operativo deben revisarse detenidamente a la hora de solucionar problemas de conectividad intermitente o de tiempo de espera. Algunos puntos clave a observar:

  • CPU:

    • EC2CPUuso de la instancia: asegúrate de que CPU no esté saturada o cerca del 100 por ciento. El análisis histórico se puede realizar mediante CloudWatch, sin embargo, tenga en cuenta que la granularidad de los puntos de datos es de 1 minuto (con la monitorización detallada habilitada) o 5 minutos;

    • Si utilizas EC2instancias rebasables, asegúrate de que su saldo CPU crediticio no se haya agotado. Esta información está disponible en la CPUCreditBalance CloudWatch métrica.

    • Los períodos cortos de CPU uso intensivo pueden provocar tiempos de espera sin que se refleje en una utilización del 100 por ciento. CloudWatch Estos casos requieren un monitoreo en tiempo real con herramientas de sistema operativo como top, ps y mpstat.

  • Network

    • Verifique si el rendimiento de la red se encuentra por debajo de los valores aceptables de acuerdo con las capacidades de la instancia. Para obtener más información, consulte Tipos de EC2 instancias de Amazon

    • En instancias que dispongan de un controlador de red mejorado ena, verifique las estadísticas de ENA para los tiempos de espera o los límites excedidos. Las siguientes estadísticas son útiles para confirmar la saturación de los límites de red:

      • bw_in_allowance_exceeded/bw_out_allowance_exceeded: número de paquetes moldeados debido a un rendimiento excesivo de entrada o de salida;

      • conntrack_allowance_exceeded: número de paquetes descartados debido a los límites de seguimiento de conexiones de los grupos de seguridad. Las conexiones nuevas fallarán cuando este límite se encuentre saturado.

      • linklocal_allowance_exceeded: número de paquetes descartados debido a un exceso de solicitudes de metadatos de la instancia, NTP a través de. VPC DNS El límite es de 1024 paquetes por segundo para todos los servicios.

      • pps_allowance_exceeded: número de paquetes descartados debido a una proporción excesiva de paquetes por segundo. El PPS límite puede alcanzarse cuando el tráfico de la red consiste en miles o millones de solicitudes muy pequeñas por segundo. ElastiCache el tráfico se puede optimizar para aprovechar mejor los paquetes de red mediante canalizaciones o comandos que realizan varias operaciones a la vez, por ejemplo, en MGET lugar de GET hacerlo.

Análisis del tiempo que se tarda en completar una sola solicitud

  • En la red: Tcpdump y Wireshark (tshark en la línea de comandos) son herramientas útiles para saber cuánto tiempo tardó la solicitud en recorrer la red, activarse ElastiCache y recibir respuesta. En el próximo ejemplo se resalta una sola solicitud que se creó con el siguiente comando: 

    $ echo ping | nc example.xxxxxx.ng.0001.use1.cache.amazonaws.com 6379
+PONG

    Del mismo modo que el comando anterior, tcpdump se encontraba en ejecución y volvió:

    $ sudo tcpdump -i any -nn port 6379 -tt
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
1609428918.917869 IP 172.31.11.142.40966
    > 172.31.11.247.6379: Flags [S], seq 177032944, win 26883, options [mss 8961,sackOK,TS val 27819440 ecr 0,nop,wscale 7], length 0
1609428918.918071 IP 172.31.11.247.6379 > 172.31.11.142.40966: Flags [S.], seq 53962565, ack 177032945, win
    28960, options [mss 1460,sackOK,TS val 3788576332 ecr 27819440,nop,wscale 7], length 0
1609428918.918091 IP 172.31.11.142.40966 > 172.31.11.247.6379: Flags [.], ack 1, win 211, options [nop,nop,TS val 27819440 ecr 3788576332], length 0
1609428918.918122
    IP 172.31.11.142.40966 > 172.31.11.247.6379: Flags [P.], seq 1:6, ack 1, win 211, options [nop,nop,TS val 27819440 ecr 3788576332], length 5: RESP "ping"
1609428918.918132 IP 172.31.11.142.40966 > 172.31.11.247.6379: Flags [F.], seq 6, ack
    1, win 211, options [nop,nop,TS val 27819440 ecr 3788576332], length 0
1609428918.918240 IP 172.31.11.247.6379 > 172.31.11.142.40966: Flags [.], ack 6, win 227, options [nop,nop,TS val 3788576332 ecr 27819440], length 0
1609428918.918295
    IP 172.31.11.247.6379 > 172.31.11.142.40966: Flags [P.], seq 1:8, ack 7, win 227, options [nop,nop,TS val 3788576332 ecr 27819440], length 7: RESP "PONG"
1609428918.918300 IP 172.31.11.142.40966 > 172.31.11.247.6379: Flags [.], ack 8, win
    211, options [nop,nop,TS val 27819441 ecr 3788576332], length 0
1609428918.918302 IP 172.31.11.247.6379 > 172.31.11.142.40966: Flags [F.], seq 8, ack 7, win 227, options [nop,nop,TS val 3788576332 ecr 27819440], length 0
1609428918.918307
    IP 172.31.11.142.40966 > 172.31.11.247.6379: Flags [.], ack 9, win 211, options [nop,nop,TS val 27819441 ecr 3788576332], length 0
^C
10 packets captured
10 packets received by filter
0 packets dropped by kernel

    A partir del resultado anterior, podemos confirmar que el apretón de manos a TCP tres bandas se completó en 222 microsegundos (918091 - 917869) y que el comando ping se envió y devolvió en 173 microsegundos (918295 - 918122).

    Desde la solicitud hasta la interrupción de la conexión pasaron 438 microsegundos (918307 - 917869). Esos resultados confirmarían que los tiempos de respuesta de la red y del motor son buenos por lo que la investigación puede centrarse en otros componentes.

  • En el sistema operativo: Strace puede ayudar a identificar brechas de tiempo a nivel de sistema operativo. El análisis de las aplicaciones reales sería mucho más extenso y se aconseja utilizar depuradores o perfiles de aplicaciones especializados. El siguiente ejemplo solo muestra si los componentes del sistema operativo base funcionan como se esperaba, de lo contrario, podría requerirse una investigación adicional. straceUsando el mismo comando de Redis que obtenemos: OSS PING

    $ echo ping | strace -f -tttt -r -e trace=execve,socket,open,recvfrom,sendto nc example.xxxxxx.ng.0001.use1.cache.amazonaws.com (http://example.xxxxxx.ng.0001.use1.cache.amazonaws.com/)
    6379
1609430221.697712 (+ 0.000000) execve("/usr/bin/nc", ["nc", "example.xxxxxx.ng.0001.use"..., "6379"], 0x7fffede7cc38 /* 22 vars */) = 0
1609430221.708955 (+ 0.011231) socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
1609430221.709084
    (+ 0.000124) socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
1609430221.709258 (+ 0.000173) open("/etc/nsswitch.conf", O_RDONLY|O_CLOEXEC) = 3
1609430221.709637 (+ 0.000378) open("/etc/host.conf", O_RDONLY|O_CLOEXEC) = 3
1609430221.709923
    (+ 0.000286) open("/etc/resolv.conf", O_RDONLY|O_CLOEXEC) = 3
1609430221.711365 (+ 0.001443) open("/etc/hosts", O_RDONLY|O_CLOEXEC) = 3
1609430221.713293 (+ 0.001928) socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 3
1609430221.717419
    (+ 0.004126) recvfrom(3, "\362|\201\200\0\1\0\2\0\0\0\0\rnotls20201224\6tihew"..., 2048, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("172.31.0.2")}, [28->16]) = 155
1609430221.717890 (+ 0.000469) recvfrom(3, "\204\207\201\200\0\1\0\1\0\0\0\0\rnotls20201224\6tihew"...,
    65536, 0, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("172.31.0.2")}, [28->16]) = 139
1609430221.745659 (+ 0.027772) socket(AF_INET, SOCK_STREAM, IPPROTO_TCP) = 3
1609430221.747548 (+ 0.001887) recvfrom(0, 0x7ffcf2f2ca50, 8192,
    0, 0x7ffcf2f2c9d0, [128]) = -1 ENOTSOCK (Socket operation on non-socket)
1609430221.747858 (+ 0.000308) sendto(3, "ping\n", 5, 0, NULL, 0) = 5
1609430221.748048 (+ 0.000188) recvfrom(0, 0x7ffcf2f2ca50, 8192, 0, 0x7ffcf2f2c9d0, [128]) = -1 ENOTSOCK
    (Socket operation on non-socket)
1609430221.748330 (+ 0.000282) recvfrom(3, "+PONG\r\n", 8192, 0, 0x7ffcf2f2c9d0, [128->0]) = 7
+PONG
1609430221.748543 (+ 0.000213) recvfrom(3, "", 8192, 0, 0x7ffcf2f2c9d0, [128->0]) = 0
1609430221.752110
    (+ 0.003569) +++ exited with 0 +++

    En el ejemplo anterior, el comando tardó un poco más de 54 milisegundos en completarse (752110 - 697712 = 54398 microsegundos).

    Se necesitó un tiempo considerable, aproximadamente 20 ms, para crear el socket (745659 a 747858) y realizar la resolución del nombre (del 697712 al 717890). Después, se necesitaron 2 ms para crear el TCP socket (745659 a 747858) y 0,4 ms (747858 a 748330) para enviar y recibir la respuesta a la solicitud.