F5 y AWS: Servicios avanzados de entrega de aplicação en la nube

Amazon Web Services (AWS) se ha convertido en el proveedor más grande y predominante de infraestructura como servicio (IaaS) de nube pública. Las organizaciones ahora pueden construir, probar e implementar pilas de aplicação completas sin comprar ni reconfigurar la infraestructura local. Las aplicações de producción pueden beneficiarse de servicios avanzados de entrega de aplicação , como un firewall de aplicação web (WAF), aceleración SSL, enrutamiento basado en contenido, equilibrio de carga, mitigación de DDoS, gestión de acceso, y agilidad de protocolo, que hacen que estas aplicações clave sean más rápidas, más inteligentes y más seguras. Para las implementaciones nativas de la nube de AWS, las soluciones de F5 permiten la entrega simple y fácil de estos servicios de aplicação a los entornos de nube de AWS.

Como proveedor de IaaS, Amazon Web Services (AWS) ofrece una infraestructura informática alquilada suficiente para desarrollar aplicações. Sin gastar dinero en gastos de capital o mantenimiento, se puede desarrollar e implementar un paquete completo de aplicação . Además de proporcionar infraestructura computacional como la que se encuentra en las instalaciones, AWS brinda servicios de aplicação , escala automáticamente la infraestructura y aloja aplicações en muchas ubicaciones. Debido a estas capacidades adicionales, las mejores prácticas para AWS son diferentes a las mejores prácticas para un centro de datos tradicional. Para apreciar mejor las diferencias entre AWS y un centro de datos tradicional, es importante comprender cómo AWS ofrece sus servicios.

Para obtener los máximos beneficios de AWS, veamos varios atributos importantes de su oferta de IaaS, como distribución geográfica, instancias informáticas, redes y conceptos de almacenamiento.

Para comprender AWS es necesario comenzar con una descripción física de cómo se distribuyen los recursos. En el nivel más alto, AWS tiene varias regiones, cada una de las cuales cubre una gran área geográfica, como la parte este de los EE. UU. Cada región geográfica contiene varias zonas de disponibilidad, que se denominan así porque están diseñadas para estar aisladas de fallas entre sí. Una falla en una zona de disponibilidad (AZ) no se propagará a otra AZ dentro de una región. Si bien cada AZ está aislada, las AZ dentro de una región están conectadas a través de enlaces de red de baja latencia. Para fines de disponibilidad, existen patrones de diseño para capacidad redundante en múltiples AZ dentro de una región.

Las instancias de cómputo comienzan como una imagen de disco de software, conocida como Amazon Machine Image (AMI). Cada AMI es inmutable, lo que significa que solo puede ser leída por la computadora que la utiliza. Al iniciar una instancia de cómputo contra una AMI se crea una máquina virtual en ejecución en la nube. Las características del hardware virtual de la instancia de cómputo pueden variar, como la cantidad de CPU y RAM disponibles para la instancia.

Cada instancia de cómputo existe dentro de una nube privada virtual (VPC), que equivale aproximadamente a una LAN en el mundo físico. Cada VPC está separada lógicamente. Una VPC puede constar de varias subredes con enrutamiento implícito entre subredes. Las subredes públicas se pueden enrutar desde Internet, mientras que las subredes privadas solo están disponibles internamente. Para implementar una aplicação completa, se implementan una o más instancias de cómputo dentro de una VPC. La comunicación entre VPC puede ocurrir cuando una instancia de cómputo o un balanceador de carga tiene una entrada DNS asignada.

Como se señaló anteriormente, cada AMI es inmutable desde la instancia que la utiliza. Para el almacenamiento persistente, AWS ofrece muchas soluciones, principalmente Simple Storage Service (S3) y Elastic Block Storage (EBS). S3 es un servicio de almacenamiento de objetos donde se puede almacenar y acceder a un objeto por nombre. El objeto puede variar en tamaño desde cero bytes hasta 5 TB. De hecho, cada AMI es implícitamente un objeto S3. Los objetos no se pueden modificar, solo crear y eliminar, lo que los hace ideales para contenido relativamente estático, como fotografías o imágenes de máquina virtual .

EBS proporciona un almacenamiento más parecido al almacenamiento tradicional. Una instancia de cómputo conectada a EBS ve al EBS como un disco duro tradicional. Solo se puede conectar una instancia en ejecución a la vez a un volumen EBS, por lo que EBS no se puede usar para almacenamiento compartido.

Además de proporcionar componentes de infraestructura clave, AWS proporciona servicios adicionales que permiten escalar las aplicação . Debido a que AWS puede aprovisionar rápidamente recursos de infraestructura, Amazon ha desarrollado soluciones que permiten el escalado automático y el equilibrio de carga de esos recursos.

AWS proporciona un servicio de equilibrio de carga elástico (ELB). Inicialmente, ELB se refería a un balanceador de carga simple que operaba en la capa 4 y distribuía el tráfico entre múltiples nodos saludables en un grupo. El grupo podría abarcar múltiples zonas de disponibilidad, creando redundancia automática en caso de falla en una zona de disponibilidad. Si bien este equilibrador de carga proporciona algunas capacidades básicas de capa 7 de red, opera principalmente en la capa 4, simplemente enrutando el tráfico TCP de manera rotatoria hacia los nodos del grupo. Los controles de estado determinan qué nodos están disponibles y, por lo tanto, son candidatos para el tráfico. AWS ahora se refiere a este balanceador de carga inicial como el Balanceador de Carga Clásico para diferenciarlo del nuevo Balanceador de Carga de Aplicação (ALB).

Dado que AWS tiene capacidad de reserva disponible, puede brindar la opción de escalar nodos dentro de un grupo. El servicio AWS CloudWatch supervisa las métricas de rendimiento de cada nodo dentro de un grupo. Cuando se superan umbrales predefinidos (como una utilización de CPU que supera el 60 % durante 5 minutos), se aprovisiona otro nodo. A la inversa, cuando se supera un umbral inferior, se elimina un nodo. El diseñador puede determinar el número máximo y mínimo de nodos en un grupo y los umbrales que activan la creación de instancias o la eliminación de nodos. El uso de escalamiento automático detrás de un balanceador de carga permite que el grupo de nodos se expanda o se contraiga según sea necesario en función de la carga.

Si bien las aplicações manejan reglas y lógica de negocios, a menudo carecen del fortalecimiento necesario para la implementación, administración y operación de producción a gran escala. Las soluciones de F5 permiten que las aplicações sean más rápidas, inteligentes y seguras al proporcionar servicios avanzados de entrega de aplicação detallados en la siguiente tabla.

Servicios avanzados de entrega de aplicação de F5

Monitoreo a nivel de aplicación

• Comprobaciones avanzadas del estado de la aplicação (mediante un monitor de varios pasos)
• Comprobaciones de estado de varios niveles (como comprobar que tanto la base de datos como la aplicação estén disponibles)
• Comprobaciones de estado que no sean HTTP (como SIP, Microsoft Windows SQL Server y FTP)
• Algoritmos avanzados para distribuir mejor el tráfico a los servidores que funcionan mejor

Disponibilidad global

• Disponibilidad de aplicação en una combinación heterogénea de diferentes proveedores de nube o centros de datos
• Integración con monitores avanzados BIG-IP
• Compatibilidad con DNSSec

Los servicios avanzados de entrega de aplicação permiten que las aplicações funcionen a un nivel superior, a la vez que están disponibles y son más seguras. Estos servicios pueden existir en un punto estratégico de control independiente de cada aplicação. Al disociar los servicios de la lógica de negocios de las aplicação , las aplicações pueden satisfacer las necesidades del negocio sin sobrecargar a los equipos de desarrollo con preocupaciones de infraestructura, administración y rendimiento. Un punto de control estratégico también permite gestionar cuestiones de gobernanza de manera uniforme e independiente de cada aplicação.

Al proporcionar integración nativa de la nube con la infraestructura de AWS, F5 permite a las organizaciones aprovechar al máximo sus implementaciones de AWS, potenciando sus aplicações con mejor rendimiento, mayor disponibilidad y mayor seguridad. En la siguiente sección, examinaremos cómo funcionan juntos AWS y F5.

Cuando una instancia de servidor arranca desde una imagen genérica, a menudo tiene sentido cambiar parámetros o establecer configuraciones, como el nombre de host y la dirección IP. En las máquinas cliente, estos parámetros se configuran a través de DHCP, pero configurar los parámetros del servidor a través de DHCP a menudo puede causar problemas. Más allá de la configuración de red, a veces una instancia particular requiere paquetes de software específicos o ciertas configuraciones de software.

En el caso de una implementación de BIG-IP, un administrador podría querer automatizar la configuración de cada uno de los módulos, como los servidores virtuales y las configuraciones de grupo para BIG-IP Local Traffic Manager (LTM), configuraciones WAF específicas para BIG-IP Aplicação Security Manager o quizás configuraciones de firewall para BIG-IP Advanced Firewall Manager. Cualquiera que instale una instancia de servidor enfrenta los mismos problemas: la imagen base necesita una configuración adicional para funcionar correctamente.

AWS ofrece dos enfoques principales para configurar una instancia: crear una nueva AMI o usar cloud-init para modificar un servidor durante el proceso de arranque. La creación de una nueva AMI es más adecuada para cambios comunes entre múltiples instancias que tienen menos probabilidades de actualizarse con frecuencia. Por el contrario, cloud-init es más apropiado para cambios que afectan a menos instancias y tienen una expectativa de vida más corta.

Para los cambios que se espera que persistan durante un período de tiempo más largo (y para cambios comunes a múltiples instancias), un buen enfoque es crear una nueva AMI iniciando una máquina desde una AMI similar a la configuración deseada. Una vez que el administrador ha realizado los cambios necesarios en la instancia en ejecución, la instancia se detiene y se genera una nueva AMI y se registra en AWS. Todas las instancias futuras que arranquen desde esta AMI tendrán los cambios ya aplicados. Dado que este enfoque hace que los cambios sean efectivamente permanentes (y dado que generar la nueva AMI puede consumir tiempo), los cambios incorporados a la AMI son generalmente aquellos que durarán mucho tiempo y se pueden usar en múltiples instancias. Otra razón para usar AMI es que permite tiempos de arranque más rápidos, ya que algunos procesos de inicio en la nube pueden consumir mucho tiempo.

Los cambios necesarios que no son adecuados para incorporarlos a una nueva AMI son buenos candidatos para cloud-init, que esencialmente habilita un script de inicio cada vez que se inicia la instancia. El uso de cloud-init permite incorporar cambios simples y específicos de la instancia en la instancia.

Las desventajas de cloud-init incluyen que los cambios de configuración, como las instalaciones de paquetes, deben ejecutarse en el momento del arranque, lo que hace que el arranque tarde más. Un tiempo de arranque prolongado tiene un impacto real en escenarios de escalamiento automático donde un tiempo de arranque prolongado podría hacer que el escalamiento automático sea ineficaz. Por estos motivos, los cambios que toman mucho tiempo deberían incluirse en una nueva AMI en lugar de realizarlos mediante cloud-init.

Administrar la configuración también puede resultar complicado cuando un cambio se puede utilizar en varias instancias, pero no en todas. Por ejemplo, supongamos que se utiliza una implementación particular de BIG-IP en un grupo de escalamiento automático con una configuración de servidor virtual específica. Una única AMI podría servir para esas máquinas y una AMI diferente podría servir para otras máquinas BIG-IP en otro grupo de escalado automático. El uso de una única AMI para cada grupo de escalado automático garantiza que solo sean necesarios cambios específicos de cada host dentro del proceso cloud-init. Cualquier cambio común al grupo puede integrarse en la AMI. La desventaja de este enfoque es que requiere una actualización de la AMI para cada cambio común a todas las máquinas.

Las aplicações proporcionan una capacidad, generalmente a múltiples usuarios simultáneamente. A medida que la aplicação tiene más éxito, puede superar la capacidad de la computadora en la que se ejecuta. Una vez que las necesidades de la aplicação exceden las de su computadora, se deben evaluar opciones para aumentar la capacidad. Hay tres enfoques genéricos para escalar: escalar verticalmente, canalizar y escalar horizontalmente.

La ampliación es el enfoque más simple para aumentar la capacidad porque simplemente implica reemplazar la computadora existente por una más rápida. Al instalar una computadora más rápida, todos los aspectos de la aplicação y cualquier otro servicio en la computadora se vuelven más rápidos sin necesidad de realizar cambios en la aplicação o la infraestructura. La desventaja de ampliar la escala es que los costos tienden a aumentar exponencialmente con el aumento del rendimiento, lo que conduce a un punto de rendimientos decrecientes. Una vez que se cruza un umbral, ampliar la escala se vuelve prohibitivamente costoso.

La segmentación es el resultado de descomponer la carga de trabajo en pasos secuenciales, similar a una línea de montaje. Cuando diferentes computadoras pueden trabajar independientemente en cada paso, se puede aumentar el rendimiento general. Sin embargo, la canalización solo aumenta el rendimiento y a menudo lo hace a expensas de la latencia. Dicho de otra manera, la canalización puede aumentar el rendimiento general, pero puede disminuir el rendimiento de un solo usuario o de una sola solicitud. La otra desventaja de la canalización es que requiere una comprensión profunda del flujo de trabajo descomponible y de la infraestructura adecuada para adaptarse a esa comprensión. Vincula estrechamente las decisiones de infraestructura con la lógica del negocio, que es exactamente lo opuesto a lo que muchas organizaciones intentan hacer.

La ampliación horizontal implica dejar la aplicação y la computadora en paz y, en su lugar, optar por distribuir las solicitudes de manera uniforme entre un grupo de servidores. Dado que las aplicações generalmente procesan varias solicitudes independientes de forma simultánea, las solicitudes pueden distribuirse de forma segura entre un grupo de servidores de aplicação idénticos. El escalamiento horizontal tiene el beneficio adicional de la redundancia, ya que una falla de cualquier miembro del grupo no provocará una interrupción de toda la aplicação. La desventaja del escalamiento horizontal es que requiere una orquestación compleja externa a la aplicação para garantizar que las solicitudes se equilibren entre los nodos del grupo.

El escalado automático de AWS utiliza un enfoque de escalamiento horizontal para aumentar la capacidad de las aplicações que la necesitan. El servicio CloudWatch supervisa los nodos de un grupo. Cuando los nodos superan los umbrales predefinidos, CloudWatch iniciará automáticamente nuevos nodos o apagará los nodos del grupo según corresponda. Con la plataforma BIG-IP, este proceso puede llevarse a cabo de dos maneras: modificando la cantidad de instancias de BIG-IP o modificando la cantidad de nodos en un grupo detrás de una única instancia de BIG-IP. La diferencia entre los dos enfoques es una función de lo que se escala: la instancia de BIG-IP o un grupo.

En el primer escenario, un grupo BIG-IP se encuentra entre un par de dispositivos ELB. El primer dispositivo ELB controla la creación y finalización de instancias de miembros de BIG-IP, mientras que el segundo dispositivo ELB es la única entrada en un grupo de servidores para cada una de las instancias de BIG-IP. Este enfoque tiene sentido cuando la instancia BIG-IP proporciona servicios avanzados de entrega de aplicação , como terminación SSL o actúa como firewall de aplicação web. El primer dispositivo ELB realiza el equilibrio de carga al mismo tiempo que aumenta o reduce el grupo según corresponda.

En el segundo escenario, la cantidad de miembros del grupo back-end crece y disminuye a través de CloudWatch, pero la instancia BIG-IP realiza el equilibrio de carga. La instancia de BIG-IP se comunica con AWS para descubrir qué nodos se agregan o eliminan del grupo. Este enfoque tiene sentido cuando se utilizan funciones avanzadas de equilibrio de carga, como el lenguaje de scripting iRules, o cuando se dirigen solicitudes en función de URL o contenido. En estos casos, una sola instancia de BIG-IP es suficiente para administrar la carga de servidores en el pool back-end.

La instancia de BIG-IP debe interactuar con la infraestructura de AWS en al menos dos escenarios. En primer lugar, una implementación de AWS de múltiples zonas requiere alterar la dirección IP detrás de una IP elástica de AWS. En segundo lugar, una instancia de BIG-IP necesita visibilidad de los miembros del grupo agregados y eliminados por el servicio AWS CloudWatch, que escala los servidores hacia arriba y hacia abajo dentro de un grupo. Cada interacción con la infraestructura se realiza a través de llamadas API y, al igual que cualquier otro software que realiza llamadas API, la instancia de BIG-IP debe autenticarse en AWS. Generalmente, existen dos enfoques para autenticarse en AWS: mediante credenciales o roles de IAM.

El enfoque más simple para la autenticación es incluir las credenciales apropiadas con la llamada API. Las credenciales de AWS constan de una clave de acceso y una clave secreta, que corresponden aproximadamente a un nombre de usuario y una contraseña. El administrador genera las credenciales, que luego el desarrollador incorpora a la aplicação. Esto le da a la aplicação acceso a las llamadas API apropiadas.

Si bien es simple, incorporar credenciales en una aplicação conlleva riesgos de seguridad. A menos que el desarrollador proteja las credenciales en la aplicação, otras personas o software podrían recuperarlas y usarlas de manera maliciosa. Este enfoque también dificulta la alteración de las credenciales sin alterar también el software. Si bien el uso de credenciales es un enfoque razonable para realizar pruebas rápidas, una solución de producción debe utilizar otro enfoque para la autenticación. Es por esto que las mejores prácticas de AWS recomiendan no utilizar credenciales almacenadas en una aplicação.

Un enfoque más seguro para la autenticación de llamadas API es el uso de roles IAM. AWS Identity and Gestión De Acceso (IAM) permite a los usuarios administrar el acceso a la infraestructura de AWS. A cualquier instancia de cómputo, como una máquina BIG-IP, se le puede asignar un rol IAM que autorice un conjunto específico de capacidades. Cuando se inicia la instancia, IAM genera un conjunto temporal de credenciales para la instancia. Esas credenciales duran mientras la instancia está funcionando y habilitan solo las capacidades de API especificadas. Cuando se configura con una función IAM, la instancia de BIG-IP no almacena credenciales, sino que tiene acceso solo a las API de infraestructura necesarias, lo que proporciona más seguridad que la autenticación basada en credenciales.

Como se mencionó anteriormente, los centros de datos de AWS existen en regiones geográficas, cada una de las cuales puede existir en una zona de disponibilidad (AZ). Cada AZ dentro de una región no comparte nada con otras AZ: no comparte energía, redes ni edificios. De hecho, cada AZ está separada geográficamente de las demás dentro de una región. Debido a la separación entre zonas, los suscriptores de AWS pueden estar seguros de que un evento que afecte a una AZ no afectará a otra AZ. En otras palabras, como regla general, como máximo una AZ dentro de una región no debería estar disponible en cualquier momento. Esto significa que cualquier servicio implementado en dos o más zonas de disponibilidad debe estar disponible de forma continua.

La plataforma BIG-IP admite alta disponibilidad en todas las zonas de disponibilidad de AWS mediante una IP elástica de AWS, que es una dirección IP no asociada intrínsecamente con una instancia de cómputo. En lugar de ello, la dirección IP se puede reenviar dinámicamente a una dirección IP privada de una instancia de cómputo en ejecución. Para permitir una alta disponibilidad en múltiples zonas, conjuntos idénticos de instancias de BIG-IP y servidores de aplicação se ubican cada uno en su propia AZ. Inicialmente, la IP elástica se asigna a una de las instancias de BIG-IP. Se establecen conexiones desde cada cliente a la IP elástica que a su vez las reenvía a la dirección IP privada en una de las instancias de BIG-IP. Si ocurre una falla, la otra instancia de BIG-IP asumirá las responsabilidades realizando una llamada API a AWS y solicitando que se le reenvíe la dirección IP elástica.

Al integrarse con ELB, la plataforma BIG-IP puede proporcionar servicios de aplicação que se integran perfectamente con las capacidades de AWS, como múltiples AZ y nodos BIG-IP de escalamiento automático.

Colocar el ELB delante de una instancia de BIG-IP simplifica la implementación en múltiples AZ, porque el ELB puede equilibrar sin problemas el tráfico hacia las pilas de aplicação individuales dentro de cada AZ donde una instancia de BIG-IP proporciona servicios de aplicação . Este enfoque simplifica el equilibrio de carga entre múltiples zonas de disponibilidad (AZ).

Cuando se necesita la elasticidad de las instancias BIG-IP, un ELB con escala automática puede escalar automáticamente hacia arriba y hacia abajo un grupo de dispositivos virtuales BIG-IP, brindando servicios de aplicação como un firewall de aplicação web, administración de identidad o terminación SSL. Al utilizar un sándwich ELB, el tráfico se enruta al primer ELB que equilibra y escala automáticamente el tráfico a un grupo de instancias de BIG-IP. Para simplificar la configuración en el grupo BIG-IP, cada instancia de BIG-IP tiene una única dirección ELB en el grupo de servidores. Luego, el segundo ELB enruta el tráfico al grupo de servidores descendentes.

Varias combinaciones de topologías ELB y BIG-IP proporcionan escalamiento automático, disponibilidad y servicios de aplicação que no están disponibles para ninguna de ellas por separado. Al aprovechar las ventajas de ELB y de la plataforma BIG-IP, el arquitecto puede proporcionar el nivel de servicios necesario para una implementación particular.

Para permitir implementaciones repetibles y programadas, AWS proporciona plantillas de formación de nubes (CFT), que simplifican tanto la implementación como la gestión continua. Después de la creación de un CFT para la arquitectura de aplicação o servicio deseado, AWS puede usarlo para aprovisionar una aplicação de forma rápida y confiable. Las CFT son particularmente útiles en entornos DevOps, ya que permiten a los equipos crear fácilmente procesos repetibles para pruebas e implementación de producción.

F5 no solo admite el uso de CFT para implementar instancias de BIG-IP, sino que también proporciona varios archivos CFT de referencia para implementaciones típicas de BIG-IP .

El ajuste de los parámetros en los archivos CFT de referencia permite implementaciones programadas de soluciones BIG-IP para diferentes escenarios, incluido el escalado automático de instancias BIG-IP o servidores back-end detrás de instancias BIG-IP, así como escenarios más complicados. Al automatizar implementaciones repetibles dentro de AWS mediante CFT y soluciones F5, se pueden implementar entornos de aplicação complejos rápidamente y con poco trabajo.

Por supuesto, la tecnología es de poca utilidad si no se puede aprovechar al máximo. Para tal fin, F5 proporciona una amplia documentación. Hay documentación disponible para la plataforma BIG-IP en general y para los detalles específicos de una instancia de BIG-IP dentro de AWS. Un buen punto de partida para cualquier pregunta es Ask F5 .

La pestaña de documentación proporciona información sobre módulos específicos de BIG-IP, así como una sección completa sobre la integración de AWS. El portal de AWS proporciona una interfaz de búsqueda para documentación, artículos, comunidad y recursos que abarcan desde los primeros pasos hasta escenarios de implementación complejos.

Para aquellas preguntas que no encuentren respuesta en la documentación, la comunidad F5 DevCentral está lista para brindar respuestas y asistencia.

La marcha hacia la adopción de la nube pública ya no es una moda, sino una tendencia duradera en TI. Amazon Web Services, como el proveedor de servicios de nube pública más grande y completo del mundo, brinda a las organizaciones la capacidad de crear, probar e implementar aplicações sin ningún equipo local. F5 ha puesto a disposición sus servicios avanzados de entrega de aplicação como parte del ecosistema de AWS y los ha configurado para ayudar a que las aplicaciones sean más rápidas, inteligentes y seguras en los entornos de nube de AWS.