Descubriendo los Cisco CSS(Content Services Switches)

Estos días he estado desconectado del blog intentando cerrar proyectos y con algunas tareas diferentes. En concreto he iniciado una nueva etapa como "trainer" oficial. Después de unos cuantos meses sin hacer formación específica, he vuelto con un curso de los balanceadores de carga CSS. Así que os dejo aquí, el resumen de los conceptos interesantes, que fuera de la materia habitual no se tienen en cuenta en la implantación/mantenimiento de los mismos.

Los Cisco Content Services Switches (CSS) fueron renombrados tras la adquisición de Arrowpoint technologies por parte de la empresa de San FranCISCO.  Los CSS son balanceadores avanzados de carga externos a los servidores de contenidos, y no son simplemente unos substitutos de la clusterización de los servidores. A parte de recibir la petición de conexión por un puerto específico, tomar la decisión de a que servidor reenviar la petición y comprobar que ese mismo servidor este operativo como haría un cluster puedes "conducir" las sessiones como desees.

1. Ejemplo de  keepalive, La comprobación del servidor esta basado en recuperar un string de la cabecera web una vez te has validado en la conexión https. Por lo que aunque el servidor este funcionando, si el demonio web y el contenido de la web no, este servidor no recibirá tráfico. 
2. Ejemplo de persistencia de session(Stickiness) y servidor(Persistence). Puedes asegurar que un cliente cuando establece una sesión de ecomerce en la web, no se reenvíe a un nuevo servidor hasta que se finalice la compra(Stickiness). Si nos interesa, ese cliente, para cualquier tipo de protocolo o tráfico, ftp, http, ssh..etc, siempre consultará al mismo servidor(Persistence).  Y también se puede elegir la forma de comprobar que el mismo origen, algunos ejemplos serían por ip origen, id de la sessión de SSL, cookie de los servidores de contenidos, una cookie que inserta el propio CSS(Arrowpoint-cookie), identificador de un campo de la URL único...etc. Sin olvidar, que también se puede hacer que todas las peticiones de tráfico sean rebalanceadas, para los servicios numerosos y breves como DNS o NTP. Se puede configurar la acción a realizar en caso de fallo del servidor destino: enviar hacia un (Sorryserver) servidor con un mensaje genérico, rebalancear, descartar la petición...etc
3. Otro ejemplo, que no puedes hacer con un cluster, es tomar la decisición de balanceo en función del idioma del navegador o versión del mismo,  en función de la url, de si es contenido cacheable para enviarlo a caches o no.
4. Finalmente, comentar los diferentes algoritmos para repartir el volumen de conexiones se pueden basar desde Round Robin hasta el ACA propietario que mide los tiempos de respuesta, pasando por reparto asimétrico basado en pesos, o enviar las peticiones al más libre.
5. Los CSS pueden descargar a los servidores finales de la parte de cifrado SSL con los clientes, o reenviando las conexiones hacia appliance ex profeso.

Hasta aquí podemos decir que se pueden apreciar las diferencias con un cluster convencional a la hora de garantizar la disponibilidad del servicio. Y resumiendo su comportamiento, actuan como un router con gran capacidad de Policy Based Routing, con IP SLA de comprobación de los servidores. Pero los CSS también evitan los ataques de DDOS, los barridos de puertos, ataques basados en vulnerabilidades de los protocolos...etc. Y otra funcionalidades, supuestamente auxiliares pero que pueden facilitarnos la vida.

Los CSS pueden actuar como servidores DNS autoritativos para nuestros dominios. Los dominios los podemos mover entre diferentes grupos de CSS, siendo anunciados desde los contents su existencia(A parte de el root del dominio, evidentemente). Para aquellas peticiones de dominios que no conozcan hablan con otros servidores, para resolverlas, de forma que en nuestra red ellos son los DNS. Por otra parte, con la licencia adicional, se puede configurar el network proximity. Esta funcionalidad consiste en balancear las peticiones al dominio, entre los diferentes grupos de CSS repartidos por países. Por ejemplo, estamos albergando www.paloaltonetworks.com en Barcelona. Una petición hacia este servidor nos llega desde EEUU, y disponemos de una pareja de CSS en ese país; pues por defectonuestros CSS resuelven el dominio con la ip pública del "Content" de EEUU ya que se prioriza servir el contenido con los CSS locales. Para que esto funcione, se definen "zonas" geográficas. También se puede balancear a nivel de resolución DNS para nuestros dominios, en función de los CSS que tienen menor carga o aquellos que no nos tarifiquen por las líneas.

Trucos y consejos:

• Como herramientas útiles a la hora de utilizarlos, es recomendable simplificar la configuración utilizando los objetos y grupos de objetos. EQL(Extension Qualifier list), NQL(Network Qualifier list), DQL(Domain Qualifier list) y host(para definir una traducción nombre-IP).
• Ten en cuenta que los CSS son routers, y si no configuramos ACLS tendremos todos los servidores expuestos.
• Para modificar una ACLS, hay que desactivar su uso, desaplicarla de los circuits(Vlans) y volver a activarlo en los circuits y luego a nivel global.
• Solo se puede tener un Source Group(NAT origen de los servidores de contenidos) activo, y por lo tanto se recomienda utilizar una VIP que es con la que se traduce la conexión origen dedicada.
• El nat de los clientes, se considera premium y se tiene que pagar mediante correspondiente licencia.
• Todo el tráfico es procesado, estos equipos no tienen ASICS, por lo que el debug no afecta al rendimiento. Así que se habla de "flows" y no de conexiones...
• Estos equipos están pensados para www y DNS, y junto con el motivo previo, CISCO lo ha puesto están en vía muerta. Creo que la CSM, se continua vendiendo.
• Para activar el debug, hay que estar en modo configuración de terminal, escribir "llama" o combinación "ESC"+ "x". Cambiará el prompt a DEBUG y hay que jugar con los comandos flow trace-IP x.x.x.x para seleccionar el tráfico a debugar, luego cambiar el nivel de logs a debugging mediante flow option 0x00130(Si en hexa) y logging console o VTY X para que podamos ver los logs. Desactivar el debug es cambiar el flow option.
• Soporta hace de DHCP relay y activar un Port mirror o SPAN.
• El modo experto, solo sirve para evitar que nos pida confirmación cada vez que hacemos algo y para poder pegar con comodidad la config en modo texto, desde el CLI.

Robclav