Comprender las métricas de rendimiento de los ADC

Introducción

Los servicios de entrega de aplicaciones son fundamentales para el éxito de las aplicaciones. Ya sea porque aportan escalabilidad, fiabilidad o seguridad, la mayoría de las aplicaciones dependen de uno o varios de estos servicios. Por tanto, los controladores de entrega de aplicaciones (ADC) ocupan un lugar esencial en la mayoría de los diseños de aplicaciones, entornos en la nube y centros de datos.

Para muchos entornos, incluidas las instalaciones de nube privada, el hardware ADC dedicado sigue siendo la plataforma preferida para prestar servicios de entrega de aplicaciones. Esto se debe a que una plataforma dedicada incorpora recursos controlados, estables y uniformes. Un dispositivo dedicado y diseñado específicamente puede ofrecer de forma constante el rendimiento y la fiabilidad que requieren incluso las cargas de trabajo de aplicaciones más exigentes, ya que no presenta variaciones en el hipervisor, el software ni la plataforma informática subyacente; además, cuenta con las ventajas de componentes de hardware especializados que descargan tareas de la CPU.

Pero ¿qué significa realmente «rendimiento»? En general, los proveedores de ADC publican cuatro tipos principales de métricas para demostrar el rendimiento:

• Solicitudes por segundo (RPS)
• Conexiones por segundo (CPS)
• Transacciones por segundo (TPS)
• Rendimiento (a menudo medido en gigabits por segundo, Gbps)

Los fabricantes proporcionan fichas técnicas exhaustivas en las que se detallan estas y otras características de las plataformas, incluidas tablas de rendimiento, número de transacciones SSL o conexiones simultáneas. Interpretar estos datos y su relevancia para la carga de trabajo de una aplicación, así como comprender los posibles límites y cuellos de botella de un sistema, es fundamental para seleccionar la plataforma adecuada. Aprender a interpretar las fichas técnicas de los proveedores y a comprender las métricas relevantes para sus aplicaciones puede ayudarle a elegir con mayor acierto las plataformas adecuadas para su empresa.

¿Qué hace un ADC?

Un controlador de entrega de aplicaciones es un componente de infraestructura que actúa como proxy de aplicaciones y proporciona servicios de entrega de aplicaciones, como gestión del tráfico, equilibrio de carga, descifrado SSL, seguridad de la capa de aplicación y control de acceso a las aplicaciones. Los dispositivos y servicios cliente se conectan al ADC, y este crea una conexión independiente con la aplicación (o reutiliza una existente). En este espacio lógico, el ADC incorpora servicios de entrega de aplicaciones.

Para comprender la carga de trabajo de un ADC, resulta útil analizar una conexión TCP y una solicitud de la capa de aplicación. El ADC debe realizar tareas en varias capas de la pila TCP y llevar a cabo diversas actividades para prestar servicios de aplicación al tráfico de las aplicaciones. (Véase la Figura 1). Esto puede dificultar la interpretación de las métricas de rendimiento proporcionadas por los proveedores de ADC. Un requisito previo fundamental para determinar qué métricas son relevantes es identificar el tipo de carga de trabajo.

Figura 1: Procesamiento de paquetes

Existen muchos tipos de aplicaciones y, por tanto, muchas cargas de trabajo de ADC diferentes. Aunque la mayoría de las implementaciones en producción contienen una combinación de cargas de trabajo, el impacto y las necesidades de cada una influyen en qué componentes de un ADC se utilizarán más. Incluso dentro de cada componente, las necesidades varían según la carga de trabajo. Algunas cargas pueden ser más sensibles a la latencia y otras, a la fluctuación; algunas son sensibles a los límites de rendimiento, mientras que otras dependen más de la disponibilidad.

Estas son las cargas de trabajo más habituales, junto con las métricas clave que las sustentan:

• Actualmente, la carga de trabajo más habitual, utilizada por sitios web y muchas aplicaciones móviles, son las aplicaciones web HTTP transaccionales, que suelen utilizar SSL y TLS. Las métricas más importantes para esta carga de trabajo son todas las métricas de SSL: RPS, TPS y rendimiento, así como las RPS y CPS de la capa 7.
• DNS es otra carga de trabajo habitual que se utiliza en casi todos los intercambios de Internet. DNS se utiliza con frecuencia, genera un volumen de tráfico bajo y suele implementarse mediante UDP en lugar de TCP. Por tanto, las métricas más importantes son el rendimiento de las capas 3 y 4.
• El uso de la API REST está creciendo rápidamente y constituye un mecanismo habitual para transportar servicios mediante API. Por ello, la API REST se utiliza a menudo en la comunicación entre máquinas. Dado que se basa en HTTP, las métricas clave son las mismas que para HTTP (todas las métricas de SSL): RPS, TPS y rendimiento, además de RPS y CPS de capa 7.
• MQTT es un protocolo de mensajería emergente que tiene numerosas aplicaciones y cuyo uso está creciendo rápidamente en las comunicaciones del Internet de las cosas (IoT). Al igual que la API REST, MQTT se utiliza principalmente en aplicaciones de comunicación entre máquinas. Las métricas clave para MQTT son las CPS de capa 4 y el rendimiento.
• Diameter sustituye al protocolo de autenticación RADIUS, funciona en la capa 4 y mantiene abiertas las conexiones TCP durante largos periodos de tiempo. Sus métricas clave son las CPS de capa 4 y la solidez de la tabla de conexiones de capa 4.
• Los protocolos de negociación financiera, como FIX, SAIL y OUCH, son sensibles a la latencia tanto en la capa 4 como en la capa 7. Por ello, sus métricas clave son las CPS de la capa 4, además de las RPS y CPS de la capa 7.
• La tecnología WebSockets es una incorporación relativamente reciente a los tipos de carga de trabajo que permite al servidor iniciar la comunicación con el cliente a través de una conexión duradera de capa 4 y capa 7. Las métricas clave son las CPS de capa 4, las RPS y CPS de capa 7, y la solidez de las tablas de conexiones de capa 4 y capa 7.
• Todas las cargas de trabajo de registro y alertas operan en la capa 4, y algunas se basan en la API REST, que opera en la capa 7. Por tanto, una métrica clave es el número de conexiones por segundo (CPS) de la capa 4 y, para las que se basan en la API REST, las solicitudes por segundo (RPS) y las conexiones por segundo (CPS) de la capa 7.

Las combinaciones de cargas de trabajo siguen evolucionando y se introducen constantemente nuevas cargas, cada una con sus propias métricas críticas del ADC basadas en sus operaciones principales.

Métricas de rendimiento y cómo interpretarlas

El rendimiento de cualquier dispositivo de red depende de la latencia, es decir, del retardo introducido por el procesamiento del tráfico de red. Como mínimo, la velocidad de la luz impone una latencia mínima a las señales eléctricas que viajan por cables de cobre o a las señales ópticas que atraviesan fibra óptica. Sin embargo, además de limitarse a transmitir los datos por cable o fibra, un ADC realiza varias operaciones sobre el tráfico de red. La capacidad máxima de un ADC viene determinada por la suma de las latencias de las operaciones en serie, es decir, aquellas que no se realizan en paralelo. Afortunadamente, muchas operaciones se ejecutan en paralelo, pero el tiempo necesario para llevarlas a cabo sigue limitando el rendimiento total. Uno de los objetivos de los diseñadores de ADC es reducir al mínimo esas latencias para maximizar el rendimiento.

Evaluar el rendimiento de un ADC concreto e intentar determinar si es adecuado para una implementación específica puede resultar abrumador. Los proveedores de soluciones de red publican métricas basadas en pruebas diseñadas para maximizar una métrica determinada a costa de otras. El objetivo de este enfoque es publicar una cifra útil que sirva de guía para la arquitectura y la toma de decisiones, aunque los proveedores saben que no todas las cifras publicadas pueden cumplirse simultáneamente. Por poner un símil automovilístico: Toyota anuncia que el modelo básico del Camry de 2017 ofrece 178 caballos de potencia y un consumo en carretera de 33 millas por galón; sin embargo, no sería razonable esperar que el vehículo desarrollase los 178 caballos —pisando el acelerador a fondo a 6000 rpm— y, al mismo tiempo, mantuviese ese consumo. Del mismo modo, los proveedores de soluciones de red presentan cada métrica de rendimiento según el mejor escenario posible para ella. Por regla general, muchas de las métricas de rendimiento publicadas no pueden reproducirse simultáneamente.

Relaciones entre las métricas y las capas OSI

Algunas de las métricas publicadas pueden aplicarse a distintos niveles de procesamiento. Por ejemplo, las solicitudes por segundo podrían representar valores de procesamiento de la capa 2 (L2) o de la capa 7 (L7) del modelo OSI. Por otro lado, las TPS suelen referirse únicamente a la negociación de claves SSL, mientras que las solicitudes por segundo de la capa 7 hacen referencia a solicitudes criptográficas posteriores que utilizan una sesión SSL ya establecida. Una carga de trabajo determinada utilizará los distintos componentes de procesamiento del ADC de forma diferente a otra. Otra conclusión importante sobre las métricas publicadas de los ADC es que cada carga de trabajo se encontrará con límites de rendimiento distintos.

Cada capa de red del modelo OSI tiene varias métricas que suelen publicarse para dicha capa. Por ejemplo, es habitual que las métricas de la capa 4 se expresen en conexiones por segundo, además de utilizar otras métricas para medir su rendimiento. Las capas 5 y 6 del modelo OSI no se corresponden fácilmente con la pila IP, pero servicios como SSL/TLS y la compresión pueden considerarse propios de estas capas. Como se ha indicado anteriormente, las pruebas de cada una de estas métricas suelen realizarse con tráfico diseñado para llevar al límite esa métrica concreta, por lo que no representan cargas de tráfico reales. Por ejemplo, el valor máximo de TPS SSL se obtiene mediante una prueba con una carga útil SSL de longitud cero, de modo que el ADC no dedique tiempo de procesamiento a descifrar datos SSL. Aunque esto resulta razonable si solo se pretende determinar el rendimiento del hardware SSL, ninguna aplicación en producción enviará cargas útiles de longitud cero. Del mismo modo, el rendimiento de la capa 2 se probará sin SSL habilitado y sin procesamiento de capa 7, ya que estas funciones ralentizan el ADC, aunque muchas implementaciones en producción sí las utilizan. La mayoría de las métricas de los ADC se prueban de forma aislada, pero la mayoría de los entornos de producción utilizan una combinación de funciones del ADC, y cada métrica somete a esfuerzo distintos componentes o combinaciones de ellos. Entre los componentes implicados pueden encontrarse la CPU, la tarjeta de interfaz de red (NIC), los circuitos integrados de aplicación específica (ASIC) y las matrices de puertas programables en campo (FPGA), entre otros. Cuando un ADC carece de un componente concreto, se utiliza la CPU en su lugar.

La métrica de paquetes indica cuántos paquetes por segundo puede procesar el ADC, y los componentes sometidos a mayor carga durante este procesamiento varían según la capa. Por ejemplo, el procesamiento de paquetes de capa 2 afecta principalmente a la tarjeta de interfaz de red (NIC), mientras que el procesamiento de paquetes de capa 4 afecta principalmente a la FPGA. La métrica de rendimiento en todas las capas hace referencia al rendimiento total disponible en gigabits por segundo, mientras que la métrica de conexiones mide cuántas conexiones por segundo pueden establecerse en esa capa concreta. Por ejemplo, la métrica de conexiones de capa 4 mide cuántas conexiones TCP pueden establecerse por segundo.

Métricas de procesamiento SSL

El procesamiento SSL se caracteriza por el hecho de que las sesiones se establecen y gestionan entre distintas conexiones. Una conexión puede establecer una sesión SSL (lo que se denomina una transacción), mientras que las conexiones posteriores pueden reutilizarla (lo que se denomina una solicitud). Por tanto, las métricas de transacciones y solicitudes se muestran por separado. Las transacciones SSL tardan mucho más que las solicitudes SSL posteriores, por lo que la métrica de transacciones suele ser el factor limitante del rendimiento. Una vez establecida una sesión SSL y realizada una solicitud posterior, la carga útil de datos debe cifrarse o descifrarse. El ASIC criptográfico se encarga del cifrado y el descifrado; su rendimiento se mide mediante la métrica de capacidad de procesamiento.

A menudo resulta útil comprimir la carga útil de datos. La compresión la realiza el ASIC de compresión y su métrica también es el rendimiento.

Procesamiento de la capa de aplicación

Por último, la capa 7 se distingue porque, dada la complejidad y variedad de las opciones de gestión del tráfico disponibles, todo el procesamiento de esta capa se realiza mediante la CPU. La persistencia de cookies es una función habitual de la capa 7 que vincula cada sesión de usuario a un servidor concreto del grupo y que se ejecuta en la CPU. La métrica de solicitudes de capa 7 indica el número de solicitudes de capa 7 por segundo que puede procesar el ADC. Del mismo modo, la métrica de rendimiento de la capa 7 indica el rendimiento total que puede alcanzarse en esta capa.

Por último, cualquier capa que necesite conservar el estado de la conexión requerirá que el ADC mantenga una tabla de conexiones. Las tablas de conexiones son habituales para las conexiones TCP de capa 4, las sesiones SSL y las sesiones HTTP de capa 7. Los protocolos con conexiones de larga duración pueden agotar o sobrecargar la tabla de conexiones de un ADC.

Cada métrica puede ayudar a determinar un aspecto específico del rendimiento. Comprender las distintas operaciones realizadas en cada capa, así como los componentes afectados por dichas operaciones, facilita la evaluación de las métricas de rendimiento del ADC para una implementación concreta.

Hardware especializado y rendimiento

Una CPU puede proporcionar todos los aspectos de la funcionalidad de un ADC. De hecho, muchos proveedores de hardware ADC ofrecen una versión exclusivamente de software. Esto es posible porque una CPU es el tipo de hardware más flexible disponible, capaz de realizar prácticamente cualquier tarea centrada en los datos.

Sin embargo, confiar todos los aspectos de la funcionalidad de un ADC a una CPU tiene sus limitaciones. De los tres tipos principales de hardware para procesar el tráfico de red —CPU, ASIC y FPGA—, la CPU es el más lento y, posiblemente, el más caro, ya que necesita el apoyo de memoria y controladores de memoria. Los otros dos tipos de hardware para procesar el tráfico de red son el ASIC y la FPGA. Un ASIC está diseñado para realizar una tarea específica, de ahí su nombre. Ningún otro tipo de hardware es más rápido que un ASIC a la hora de realizar una tarea, pero sus capacidades se limitan a las incorporadas en el diseño del chip. Si una aplicación necesita funciones que el ASIC no ofrece, deberá utilizar una CPU y realizar las tareas mediante software.

Si una CPU es flexible pero lenta y un ASIC es inflexible pero rápido, existe una tercera tecnología que se sitúa en un punto intermedio: la FPGA. Una FPGA es más lenta que un ASIC, pero mucho más rápida que una CPU, y puede programarse para realizar tareas que sus diseñadores no habían previsto.

Figura 2: Ventajas de las CPU, los ASIC y las FPGA

Un ADC bien diseñado aprovechará al máximo las capacidades de cada tipo de hardware: delegará las tareas habituales y sencillas en componentes ASIC, realizará las tareas más complejas en componentes FPGA y gestionará las tareas de mayor complejidad y menos frecuentes en la CPU. Gran parte de la magia de ingeniería de un ADC reside en coordinar los distintos tipos de componentes para gestionar las diversas cargas de trabajo de la forma más eficiente posible.

Con diferencia, la tarea más frecuente que se realiza en un ADC es el procesamiento de paquetes en las interfaces de red. Una NIC estándar disponible en el mercado está optimizada para un gran volumen de tráfico entrante (por ejemplo, en un equipo de sobremesa u otro dispositivo de usuario) o para un gran volumen de tráfico saliente (por ejemplo, en un servidor). Un ADC presenta la particularidad de que necesita una NIC optimizada para ofrecer el máximo rendimiento en ambas direcciones. Ninguna NIC disponible en el mercado se ha diseñado para proporcionar el máximo rendimiento en ambas direcciones. Dado que el procesamiento de paquetes en un ADC es frecuente y constituye una tarea relativamente sencilla, resulta idóneo para un ASIC. En entornos de ADC en clúster, un ASIC desagregador (DAG) actúa como equilibrador de carga frontal, lo que garantiza que las sesiones de un mismo cliente y servidor siempre pasen por el mismo nodo del clúster. El uso de un DAG en un entorno en clúster facilita el escalado horizontal de los dispositivos ADC para satisfacer las demandas de tráfico. En un ADC correctamente diseñado, todo el procesamiento y la conmutación de paquetes de capa 2 pueden realizarse mediante hardware ASIC especializado.

Las tareas de procesamiento de las capas 3 y 4 son más complejas, por lo que resultan idóneas para una FPGA. Una FPGA puede proporcionar funciones de enrutamiento, así como protección mediante cortafuegos y contra ataques distribuidos de denegación de servicio (DDoS), incluidas las cookies SYN de TCP. El uso de una FPGA en este nivel permite aplicar procesamiento y medidas de protección en la capa 4, lo que garantiza que el tráfico que se someta a un procesamiento posterior se haya ensamblado y filtrado correctamente.

El procesamiento de cifrado y compresión, como SSL o TLS, así como las nuevas funcionalidades introducidas por HTTP/2, constituyen otro ámbito de aplicación del hardware dedicado. A menudo se utiliza un ASIC especializado para el procesamiento criptográfico, incluida la negociación de claves SSL, que requiere una gran capacidad de cálculo, en cifrados modernos como el intercambio de claves Diffie-Hellman sobre curvas elípticas (ECDHE). Una vez realizada la negociación de claves SSL, el cifrado y descifrado masivos de las solicitudes posteriores también pueden gestionarse mediante hardware ASIC. Del mismo modo, el hardware ASIC puede realizar la compresión y descompresión mediante algoritmos habituales. El uso de componentes ASIC dedicados permite procesar rápidamente el cifrado y la compresión.

Todo procesamiento restante del tráfico de red que no gestionen los ASIC y las FPGA debe ser procesado por la CPU. Aunque es más lenta que los ASIC y las FPGA, la CPU es el componente más flexible del ADC. La CPU también se encarga de tareas no relacionadas con el procesamiento de red, como la interfaz gráfica de usuario y otras funciones de configuración, la gestión de interrupciones de E/S o incluso el procesamiento de solicitudes de disco. Dado que las exigencias sobre la CPU pueden variar en función de la latencia y que esta es el último tipo de hardware que procesa el tráfico de red, los ADC se diseñan deliberadamente para derivar a la CPU la menor cantidad posible de procesamiento de tráfico y procesar tanto como sea posible en los ASIC y las FPGA, que son más rápidos.

Conclusión

Puede resultar difícil trasladar las métricas publicadas por los proveedores al rendimiento en condiciones reales. Aunque es complejo, comprender la interacción entre los distintos tipos de cargas de trabajo, los recursos que consumen y las capacidades de una plataforma de hardware puede ayudarle a tomar la mejor decisión de compra para su organización.

Las fichas técnicas publicadas y otros recursos facilitan la elección de la plataforma adecuada, pero también es importante recurrir directamente a la experiencia y los conocimientos especializados del proveedor siempre que sea posible. Los proveedores líderes contarán con amplios conocimientos para adaptar las cargas de trabajo a las plataformas, conocimientos que deberían estar fácilmente a disposición de los clientes.

Combinar un buen conocimiento de las características del tráfico de sus aplicaciones y de las capacidades de la plataforma con la experiencia de su proveedor reducirá el riesgo y el posible coste de dimensionar la plataforma por debajo o por encima de sus necesidades.

PUBLICADO EL 28 DE MARZO DE 2017