Conocimiento de las métricas de rendimiento de ADC

Los servicios de entrega de aplicação son fundamentales para el éxito de las aplicações. Ya sea que estos servicios agreguen escalabilidad, confiabilidad o seguridad, la mayoría de las aplicações dependen de uno o más de ellos. Por lo tanto, los controladores de entrega de aplicação (ADC) ocupan un lugar crítico en la mayoría de los diseños de aplicação, nubes y centros de datos.

Para muchos entornos, incluidas las instalaciones de nube privada, el hardware ADC dedicado sigue siendo la plataforma preferida para brindar servicios de entrega de aplicação . Esto se debe a que una plataforma dedicada incorpora recursos controlados, estables y consistentes. Un dispositivo dedicado y diseñado específicamente puede brindar de manera consistente el rendimiento y la confiabilidad que requieren incluso las cargas de trabajo de aplicação más exigentes, porque no tiene variaciones en el hipervisor, el software o la plataforma de cómputo subyacente; además, tiene las ventajas de los componentes de hardware especializados para descargar 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 hojas de datos completas que enumeran estas y otras características de la plataforma, incluidas tablas de rendimiento, números de transacciones SSL o conexiones simultáneas. Interpretar estos números y su relevancia para la carga de trabajo de una aplicação , y comprender los posibles límites y cuellos de botella de un sistema, son esenciales para seleccionar la plataforma correcta. Aprender a interpretar las hojas de datos de los proveedores y comprender las métricas relevantes para sus aplicações puede ayudarlo a tener más éxito al seleccionar las plataformas adecuadas para su negocio.

Un controlador de entrega de aplicação es un componente de infraestructura que actúa como un proxy de aplicação y proporciona servicios de entrega de aplicação como gestión de tráfico, equilibrio de carga, descifrado SSL, seguridad de la capa de aplicação y control de acceso para aplicações. Los dispositivos y servicios del cliente se conectan al ADC, y el ADC crea una conexión separada (o reutiliza una existente) con la aplicação. En este vacío lógico, el ADC inserta servicios de entrega de aplicação .

Para comprender la carga de trabajo de un ADC, es útil observar una conexión TCP y una solicitud de capa de aplicación. El ADC debe realizar tareas en múltiples capas de la pila TCP y realizar una serie de actividades para brindar servicios de aplicação al tráfico de la aplicação . (Véase la Figura 1.) Esto puede dificultar la interpretación de las métricas de rendimiento de los proveedores de ADC. Un requisito previo clave para comprender qué métricas son relevantes es identificar el tipo de carga de trabajo.

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

A continuación se presentan las cargas de trabajo más comunes, junto con las métricas clave que las respaldan:

• Actualmente, la carga de trabajo más común, utilizada por sitios web y muchas aplicações móviles, son las aplicações web transaccionales HTTP, que a menudo utilizan SSL y TLS. Las métricas más importantes para esta carga de trabajo son todas las métricas SSL: RPS, TPS y rendimiento, así como RPS y CPS de capa 7.
• DNS es otra carga de trabajo común utilizada en casi todos los intercambios de Internet. El DNS se utiliza con frecuencia, el volumen de tráfico es bajo y normalmente se implementa utilizando UDP en lugar de TCP. Como resultado, las métricas más importantes son el rendimiento de la capa 3 y la capa 4.
• La API REST está creciendo rápidamente en uso y se refiere a un transporte de API común para servicios. Como resultado, la API REST se utiliza a menudo en la comunicación de máquina a máquina. Dado que la API REST se basa en HTTP, las métricas clave son las mismas que para HTTP (todas las métricas SSL): RPS, TPS y rendimiento, así como RPS y CPS de capa 7.
• MQTT es un protocolo de mensajería emergente que tiene muchos usos y está creciendo rápidamente en la comunicación de Internet de las cosas (IoT). Al igual que la API REST, MQTT se encuentra principalmente en aplicações de máquina a máquina. Las métricas clave para MQTT son los CPS de capa 4 y el rendimiento.
• Diameter es un reemplazo del protocolo de autenticación RADIUS que opera en la capa 4 y mantiene las conexiones TCP abiertas durante largos períodos de tiempo. Sus métricas clave son los CPS de capa 4 y la robustez de la tabla de conexión de capa 4.
• Los protocolos de comercio financiero como FIX, SAIL y OUCH son sensibles a la latencia tanto en el nivel de capa 4 como en el de capa 7. Esto hace que sus métricas clave sean CPS de capa 4, además de RPS y CPS de capa 7.
• La tecnología WebSockets es una incorporación relativamente reciente a los tipos de carga de trabajo, mediante la cual el servidor puede 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 CPS de capa 4, RPS y CPS de capa 7, y la solidez de las tablas de conexión de capa 4 y capa 7.
• Todas las cargas de trabajo de registro y alerta funcionan en la capa 4 y algunas se basan en la API REST, que funciona en la capa 7. Como resultado, una métrica clave es CPS de capa 4 y, para aquellos basados en la API REST, RPS y CPS de capa 7.

Las combinaciones de cargas de trabajo continúan evolucionando y constantemente se introducen nuevas cargas de trabajo, cada una con sus propias métricas de ADC críticas basadas en las operaciones principales de la carga de trabajo.

El rendimiento de cualquier dispositivo de red es una función de la latencia, el retraso introducido por el procesamiento del tráfico de red. Como mínimo, la velocidad de la luz impone una latencia mínima para las señales eléctricas que viajan a través de cables de cobre o las señales ópticas que atraviesan fibra óptica. Sin embargo, además de simplemente mover datos a través de cables o fibra, un ADC realiza varias operaciones en el tráfico de la red. Las capacidades máximas de un ADC son la suma de las latencias de operaciones en serie, es decir, operaciones que no se realizan en paralelo. Afortunadamente, muchas operaciones se realizan en paralelo, pero el tiempo necesario para realizarlas sigue siendo una limitación para el rendimiento total. Uno de los propósitos de los diseñadores de ADC es minimizar esas latencias para maximizar el rendimiento.

Evaluar el rendimiento de un ADC en particular e intentar adaptarlo a una implementación particular puede resultar abrumador. Los proveedores de redes publican métricas basadas en pruebas destinadas a maximizar una métrica particular a expensas de otras. La razón de este enfoque es publicar un número utilizable que pueda guiar la arquitectura y las decisiones, pero los proveedores entienden que no todos los números publicados serán verdaderos simultáneamente. Usando una analogía con un automóvil: Toyota publicita su modelo base Camry 2017 como un modelo que produce 178 caballos de fuerza y alcanza 33 millas por galón en carretera, pero sería irrazonable esperar que el auto produzca los 178 caballos de fuerza completos (presionando el acelerador a fondo a 6,000 RPM) mientras que simultáneamente proporciona 33 millas por galón. De manera similar, los proveedores de redes muestran métricas de rendimiento individuales utilizando el mejor escenario posible para cada una. Como regla general, muchas de las métricas de rendimiento publicadas no se pueden reproducir simultáneamente.

Algunas de las métricas publicadas se pueden aplicar a diferentes niveles de procesamiento. Por ejemplo, las solicitudes por segundo podrían representar valores para el procesamiento de la capa 2 de OSI (L2) o de la capa 7 de OSI (L7). Por otro lado, TPS a menudo se refiere únicamente a la negociación de claves SSL, mientras que las solicitudes de capa 7 por segundo se refieren a solicitudes criptográficas posteriores que utilizan una sesión SSL establecida. Una carga de trabajo particular ejercitará los distintos componentes de procesamiento del ADC de manera diferente a otra carga de trabajo. Otra conclusión clave con respecto a las métricas publicadas de ADC es que diferentes cargas de trabajo encontrarán diferentes límites de rendimiento.

Cada capa de red OSI tiene varias métricas que se publican más comúnmente para esas capas. Por ejemplo, es común ver métricas de capa 4 citadas en conexiones por segundo y otras métricas para el rendimiento de la capa 4. Las capas 5 y 6 de OSI no se asignan fácilmente a la pila IP, pero servicios como SSL/TLS y la compresión pueden considerarse como capas 5 y 6. Como se señaló anteriormente, las pruebas para cada una de estas métricas a menudo se realizan con tráfico diseñado para estresar esa métrica en particular y no representan cargas de tráfico del mundo real. Por ejemplo, el TPS SSL máximo resultará de una prueba con una carga útil SSL de longitud cero, de modo que no se gaste tiempo de procesamiento de ADC descifrando datos SSL. Si bien es razonable determinar solo el rendimiento del hardware SSL, ninguna aplicação de producción enviará cargas útiles de longitud cero. De manera similar, se probará el rendimiento de la capa 2 sin SSL habilitado y sin procesamiento de capa 7, ya que esto ralentizará el ADC, aunque muchas implementaciones de producción utilizarán esas funciones. La mayoría de las métricas de ADC se prueban de forma aislada, pero la mayoría de los entornos de producción utilizan una combinación de características de ADC, y cada métrica enfatiza diferentes componentes o combinaciones de componentes. Los componentes involucrados pueden incluir la CPU, la tarjeta de interfaz de red (NIC), circuitos integrados específicos de la aplicación (ASIC) y matrices de puertas programables en campo (FPGA), entre otros. Cuando a un ADC le falta un componente particular, se utiliza la CPU en su lugar.

La métrica del paquete indica cuántos paquetes por segundo puede procesar el ADC, y los componentes más estresados por este procesamiento varían según la capa. Por ejemplo, el procesamiento de paquetes de capa 2 pone énfasis principalmente en la tarjeta de interfaz de red (NIC), mientras que el procesamiento de paquetes de capa 4 pone énfasis principalmente en el FPGA. La métrica de rendimiento en todas las capas se refiere al rendimiento total disponible en gigabits por segundo, mientras que la métrica de conexiones mide cuántas conexiones por segundo se pueden realizar en esa capa en particular. Por ejemplo, la métrica de conexión de capa 4 mide cuántas conexiones TCP se pueden establecer por segundo.

El procesamiento SSL es único porque las sesiones se establecen y gestionan a través de conexiones. Una conexión puede establecer una sesión SSL (lo que se denomina transacción), mientras que las conexiones posteriores pueden reutilizar una sesión SSL (lo que se denomina solicitud). Por lo tanto, las métricas de transacciones y solicitudes se enumeran por separado. Con diferencia, las transacciones SSL tardan más que las solicitudes SSL posteriores, por lo que el número limitante en el rendimiento del procesamiento suele ser la métrica de las transacciones. Una vez que se establece una sesión SSL y se realiza una solicitud posterior, la carga de datos debe cifrarse o descifrarse. El ASIC criptográfico maneja el cifrado y descifrado; el rendimiento se mide en la métrica de rendimiento.

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

Finalmente, la capa 7 es única porque, dadas las complejas y variadas opciones de gestión de tráfico disponibles, todo el procesamiento de la capa 7 se realiza a través de la CPU. La persistencia de las cookies es una capacidad común de capa 7 que vincula cada sesión de usuario a un servidor particular en el grupo y es realizada por la CPU. La métrica de solicitudes de capa 7 se refiere a la cantidad de solicitudes de capa 7 por segundo que el ADC puede realizar. De manera similar, la métrica de rendimiento de la capa 7 se refiere al rendimiento total posible en la capa 7.

Finalmente, cualquier capa que necesite preservar el estado de la conexión requerirá que el ADC mantenga una tabla de conexión. Las tablas de conexión son comunes para conexiones TCP de capa 4, sesiones SSL y sesiones HTTP de capa 7. Los protocolos con conexiones de larga duración pueden agotar o estresar una tabla de conexión ADC.

Cada métrica puede ayudar a determinar un aspecto específico del rendimiento. Comprender las diferentes operaciones que se realizan en cada capa, junto con qué componentes se ven afectados por esas operaciones, ayuda a evaluar las métricas de rendimiento del ADC para una implementación particular.

Cada aspecto de la funcionalidad del ADC puede ser proporcionado por una CPU. De hecho, muchos proveedores de hardware ADC ofrecen solo una versión de software. Esto es posible porque una CPU es el tipo de hardware más flexible disponible, capaz de realizar casi cualquier tarea centrada en datos.

Sin embargo, confiar todos los aspectos de la funcionalidad del ADC a una CPU tiene sus límites. 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 soporte de la memoria y los controladores de memoria. Los otros dos tipos de hardware para procesar el tráfico de red son el ASIC y el FPGA. Un ASIC está diseñado para realizar una tarea específica, de ahí el nombre. Ningún otro tipo de hardware es más rápido que un ASIC para realizar una tarea, pero sus capacidades están limitadas a lo que está diseñado en el chip. Si una aplicação necesita capacidades que no están disponibles en el ASIC, la aplicação debe utilizar una CPU y realizar las tareas en el software.

Si una CPU es flexible y lenta, y un ASIC es inflexible y rápido, una tercera tecnología opera en el medio: el FPGA. Un FPGA es más lento que un ASIC pero mucho más rápido que una CPU y puede programarse para realizar tareas no previstas por los diseñadores de FPGA.

Un ADC bien diseñado utilizará las capacidades de cada tipo de hardware al máximo: relegando las tareas comunes y simples a los componentes ASIC, realizando tareas más complejas en los componentes FPGA y manejando las tareas más complejas y menos comunes en la CPU. Gran parte de la magia de la ingeniería en un ADC es el resultado de coordinar los diferentes tipos de componentes para manejar de manera más eficiente las distintas cargas de trabajo.

La tarea más frecuente, con diferencia, realizada en un ADC es el procesamiento de paquetes en las interfaces de red. Una NIC estándar lista para usar está diseñada para tráfico entrante de gran volumen (por ejemplo, en una computadora de escritorio u otro dispositivo de usuario) o para tráfico saliente de gran volumen (por ejemplo, en un servidor). Un ADC es único porque requiere una NIC optimizada para lograr el máximo rendimiento en ambas direcciones. Ninguna NIC estándar ha sido diseñada para alcanzar el máximo rendimiento en ambas direcciones. Dado que el procesamiento de paquetes ADC es frecuente y relativamente sencillo, es ideal para un ASIC. En entornos ADC en clúster, un ASIC desagregador (DAG) actúa como un balanceador de carga front-end, garantizando que las mismas sesiones de cliente y servidor siempre fluyan a través del mismo nodo del clúster. El uso de un DAG en un entorno agrupado facilita el escalamiento 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 se pueden realizar en hardware ASIC especializado.

Las tareas de procesamiento de capas 3 y 4 son más complejas, lo que las hace adecuadas para un FPGA. Un FPGA puede proporcionar capacidades de enrutamiento, así como también protección contra firewall y denegación de servicio distribuido (DDoS), incluidas cookies TCP SYN. El uso de un FPGA en este nivel permite el procesamiento y las protecciones de capa 4, garantizando que el tráfico considerado para un procesamiento posterior se haya ensamblado y filtrado correctamente.

El procesamiento de cifrado y compresión, como SSL o TLS, y las nuevas capacidades introducidas por HTTP/2, son otro uso del hardware dedicado. A menudo se utiliza un ASIC especializado para el procesamiento criptográfico, incluida la negociación de claves SSL computacionalmente intensiva de cifrados modernos como el cifrado Diffie-Hellman de curva elíptica (ECDHE). Una vez realizada la negociación de la clave SSL, el hardware ASIC también puede gestionar el cifrado y descifrado masivo de solicitudes posteriores. De manera similar, el hardware ASIC puede realizar compresión y descompresión mediante algoritmos comunes. El uso de componentes ASIC dedicados permite un procesamiento rápido del cifrado y la compresión.

Cualquier procesamiento restante del tráfico de red no manejado por ASIC y FPGA debe ser procesado por la CPU. Aunque es más lenta que los ASIC y los FPGA, la CPU es el componente más flexible del ADC. También se encarga de tareas no relacionadas con el procesamiento de red, como la interfaz gráfica de usuario (GUI) y otras tareas de configuración, la gestión de interrupciones de E/S o incluso el procesamiento de solicitudes de disco. Debido a que las demandas en la CPU pueden variar con la latencia y la CPU es el último tipo de hardware en procesar el tráfico de red, los ADC están diseñados intencionalmente para dirigir la menor cantidad posible de procesamiento de tráfico a la CPU, procesando en cambio la mayor cantidad posible en ASIC y FPGA más rápidos.

Puede resultar difícil traducir las métricas publicadas por los proveedores en un rendimiento en el mundo real. Comprender la interacción entre los diferentes tipos de cargas de trabajo, los recursos que consumen y las capacidades de una plataforma de hardware, aunque complejo, puede ayudarlo a tomar la mejor decisión de compra para su organización.

Las hojas de datos publicadas y otros recursos ayudan a que sea más fácil especificar la plataforma correcta, pero también es importante confiar directamente en la experiencia y los conocimientos del proveedor siempre que sea posible. Los proveedores líderes tendrán una profunda experiencia en la adaptación de las cargas de trabajo a las plataformas, una experiencia que debería estar fácilmente disponible para los clientes.

La combinación de un buen conocimiento de las características del tráfico de su aplicação y de las capacidades de la plataforma con la experiencia de su proveedor reducirá el riesgo y el gasto potencial de aprovisionar en exceso o en defecto su plataforma.