miércoles, 28 de septiembre de 2011

Dimensionamiento de dispositivos Big-IP de F5

Algunos de los puntos más importantes a tener en cuenta en el dimensionameinto de una solución con los dispositivos BIG-IP de F5

Normalmente los dispositivos se dimensionan por un número determinado de parámetros determinados de forma fija por el hardware, pero en el caso de las plataformas BIG-IP, al ser a su vez un cúmulo de módulos que realizan diferentes funciones (hay que recordad que el BIG-IP no solo aporta el servicio de balanceo de su módulo LTM), hay que tener en cuenta los aspectos que se exponen a continuación:

Funcionalidades requeridas

La plataforma Big-IP incluye diferentes funcionalidades que se pueden licenciar, por lo que el primer paso será definir cuáles de estos módulos mejor se adaptan a la solución global que se busca.

1.     BIG-IP Local Traffic Manager (LTM)

Este es el componente básico y más conocido de la solución. Su cometido es realizar las tareas de balanceo de carga convirtiéndose en un full-proxy TCP entre los clientes y servidores.

El balanceo se puede realizar a nivel de aplicación, aunque existe la posibilidad de adquisición de un LTM básico en el cual solo se realiza a nivel TCP.


2.     Edge Gateway

Proporciona accesos remotos mediante la creación de VPNs SSL de usuario, de forma similar a otras soluciones como pueden ser el SSL Secure Access de Juniper.


3.     BIG-IP WAN Optimization Manager (WOM)

Proporciona optimización de WAN de un modo similar a los productos SteelHead de Riverbed, enviado patrones entre los dispositivos y reduciendo las necesidades de interacciones entre los extremos (chatty protrocols) aportando, por ejemplo, grandes mejoras en los tiempos de transmisión en protocolos como CIFS.


4.     BIG-IP Access Policy Manager (APM)

Realiza las tareas de un servidor RADIUS que integre los Servicios AAA (Autenticación, Autorización y Contabilidad) muy utilizadas por despliegues Wireless y otros como puedan ser proyectos de escritorios virtuales.


5.     BIG-IP Application Security Manager (ASM)

Es el firewall de aplicación integrado en el BIG-IP. Aunque aporta una securización muy fuerte contra todo tipo de ataques que los firewall tradicionales no son capaces de interceptar, su configuración y gestión puede llegar a ser bastante costoso si los servicios protegidos son bastante dinámicos, como puedan ser páginas web en continuo desarrollo.


6.     BIG-IP WebAccelerator (WBA)

Gracias al Offload de las tareas de encriptación, el caché, o la compresión de paquetes, se consigue la aceleración de prestación de páginas WEB y un consumo menor de ancho de banda.


7.     BIG-IP Link Controller (LC)

Este módulo, que también puede conseguirse como un producto a parte, controla los flujos de tráfico hacia las diferentes líneas externas de los proveedores ISP contratados dependiendo de diversos parámetros, como puedan ser errores o velocidad de acceso.

También tiene la capacidad de realizar compresión de la transmisión para minimizar el consumo de ancho de banda.


8.     BIG-IP Global Traffic Manager (GTM)

Realiza un balanceo selectivo entre Data Centers, lo que permite disminuir las interrupciones de servicio y mejora los tiempos de respuesta del servicio.

Este balanceo es posible gracias a la gestión de las entradas DNS asociadas a los diferentes servicios alojados simultáneamente en los diversos Data Centers.
           

Virtualización

Pueden surgir dos tipos de necesidades de virtualización de la plataforma que también influirán en los modelos finalmente adoptados:

1.     Conversión del BIG-IP en una máquina virtual.

Se puede disponer del BIG-IP en forma de Virtual Appliance, bajo el nombre de Virtual Edition. Hay que tener en cuenta que la elección de este despliegue condiciona mucho tanto las funcionalidades posibles como el rendimiento que se conseguirá con él.

2.     Virtualización del hardware BIG-IP, posibilitando varias instancias en un mismo dispositivo.

Existen ocasiones e las que es necesario virtualiza un hardware y correr sobre él varias instancias del Sistema Operativo, como por ejemplo hacen los Firewalls ASA de Cisco con los denominados “Contextos”. Esa necesidad viene dada principalmente por el requisito de una división lógica de la gestión y de recursos hardware (Multitenance).

La única gama de BIG-IP que permite esto son los productos Viprion. Los Viprion permiten dos grados de virtualización:

·         Particiones: En las que se separa la gestión pero no se puede hacer reserva de recursos.

·         Instancias: También llamadas vCMP. Permiten restringir la utilización de RAM y CPU a la vez que proporcionan el aislamiento de gestión.

Compatibilidad entre módulos

Una vez determinados los módulos requeridos, es necesario comprobar que pueden integrarse todos bajo un mismo BIG-IP, ya que cada hardware soporta un número concreto de módulos y, a parte, existen incompatibilidades que hacen que no puedan coexistir ciertos módulos a la vez bajo el mismo BIG-IP

Para aclarar lo anterior se puede consultar el siguiente recurso:


En dicha tabla aparecen las compatibilidades de los módulos con las versiones de firmware y los modelos de hardware, así como la posibilidad de ejecutar varios de ellos a la vez.

Mediante esta tabla se puede comprobar las restricciones de funcionalidades existentes en la edición virtual comentadas en el apartado anterior.

Throughput

Siguiendo las consideraciones de los apartados anteriores se reduce a unos cuantos posibles hardware BIG-IP que cumplen los objetivos marcados. Una vez que se dispone de esa lista de candidatos se ha de comprobar cuales no cumplen los requisitos de throughput.

Los documentos en los que se pueden encontrar los límites de throughput de cada uno de los hardware son los siguientes:



En estos documentos se exponen diversos elementos para el dimensionamiento del hardware. Para saber cuál aplicar hay que conocer las peculiaridades de los servicios que se encontrarán detrás de la plataforma BIG-IP.

Puede darse el caso que sea necesario balancear una base de datos sea más restrictivo el componente de transacciones SSL por segundo que los requisitos de ancho de banda que ese servicio necesita.

Para cualquier tipo de servicio se ha de tomar como referencia el  “Throughput de tráfico”, mientras que si se requiere realizar Offload de SSL también entrará en consideración las  “Transacciones SSL por segundo (TPS)”. Por último, en el caso de que también se requiera compresión de tráfico, se ha de cumplir el mínimo de “Throughput de tráfico comprimido”


Es necesario tener en cuenta que los documentos señalados antes muestran las especificaciones generales de la gama, pero hay casos en los que dentro de una misma gama existe un producto para soportar servicios específicos que supera alguno de esos límites, como por ejemplo el dispositivo 8600S que dispone de más throughput SSL (pero menos capacidad de compresión) que el indicado en la tabla para la gama 8600.
             
Por último es de utilidad señalar que en ciertos casos en los que es necesario ajustar mucho el hardware a los requisitos marcados,  hay que tener en cuenta que ciertos módulos consumen más recursos que otros y puede que el throughput real logrado sea inferior al mostrado en las tablas. Este punto es muy difícil de definir y no puede ser consultado a título personal en ninguna documentación de F5, por lo que, en caso de duda, hay que contactar con el fabricante para aclarar este punto.

Interfaces físicas

El último punto importante que puede hacer desestimar el modelo elegido es la carencia del número o de los tipos de  interfaces físicas (velocidad, conectores, etc) necesarios para poder integrar el producto en la arquitectura de red existente. Estos datos aparecen también en las tablas que se encuentran en los enlaces del apartado anterior.


No hay comentarios:

Publicar un comentario