Optimización Citrix CloudBridge en Citrix XenApp y XenDesktop (1 de 2)

Hola a todos, soy José María Sastre, Ingeniero preventa de Citrix, y en estos meses estamos publicando sobre las soluciones Citrix NetScaler y CloudBridge en cuanto a disponibilidad, seguridad, optimización y visibilidad, especialmente en entornos Citrix XenApp y XenDesktop.

En este doble post vamos a ver cómo se puede optimizar la experiencia del usuario en entornos WAN mediante la solución Citrix CloudBridge. Primero nos centraremos en los conceptos básicos y la optimización en general, para seguidamente ver cómo aplica a entornos Citrix XenApp y XenDesktop.

Citrix CloudBridge es una solución de optimización WAN, destinada a mejorar el acceso a aplicaciones y datos en entornos eminentemente WAN, con latencias altas, generalmente poco ancho de banda, y a veces pérdida de paquetes reseñable; pero que además tiene algunas optimizaciones específicas para entornos Citrix que lo distinguen del resto de soluciones similares.

El problema de la WAN

Como decíamos arriba, las condiciones que hacen que el uso de aplicativos y acceso a datos por WAN tenga un rendimiento habitualmente muy inferior a un acceso LAN son principalmente la latencia, el ancho de banda y la pérdida de paquetes. No obstante puede haber otros condicionantes como el jitter (variación de la latencia), el re-enrutado de paquetes ante condiciones de error en algún paso intermedio o pequeños cortes debidos a problemas con el equipamiento por el que pasan los paquetes, que son muchos más y más complejos que en una LAN (hay cambios de protocolos, cambio en tamaño de tramas, fragmentación, capa de enrutado en lugar de solo switching, etc.).

• Latencia: es el retardo entre los dos puntos de una comunicación y se debe a la distancia física entre ellos, más los retardos que introducen los equipos intermedios. En una LAN suele ser inferior a un milisegundo, mientras que en WAN hablamos del orden de unos pocos milisegundos hasta 120 milisegundos (líneas entre España y Latinoamérica), más de 300 (líneas con China), o más de 500 (enlaces satelitales). La latencia es con diferencia el principal problema en una WAN, y habitualmente, por error, minusvalorado en comparación con la limitación de ancho de banda.

• Ancho de banda: es la capacidad de la línea entre dos puntos. En LAN hoy día ya hablamos de conexiones a 1 y 10 Gbps de forma habitual, mientras que en WAN, y dependiendo de la distancia y tecnología usada suele estar entre 1 Mbps y 100 Mbps (este último habitualmente para ubicaciones relativamente cercanas).

• Pérdida de paquetes: mide el porcentaje de paquetes que por alguna razón no llegan a su destino, no importa la causa. En LAN suele ser prácticamente cero, mientras que en WAN, nuevamente según distancia, tecnología y calidad del enlace, suele estar entre un 0,01% y un 0,3%, este último en líneas de calidad con Latinoamérica.

Impacto de la WAN en el acceso a aplicaciones y datos

Desde un punto de vista técnico, ¿en qué afectan estas diferencias respecto a la LAN en términos de rendimiento de aplicaciones?

• Ineficiencias a nivel TCP: la mayoría de sistemas (clientes y servidores) utilizan aún hoy versiones obsoletas de TCP, creadas para redes con la tecnología de hace muchos años. Factores como el tamaño de ventana o los algoritmos de control de flujo y control de congestión penalizan sobremanera las transferencias. A modo de ejemplo, un protocolo “limpio” como FTP, en una red de 120 milisegundos de latencia, no puede pasar datos a más de unos 4 a 5 Mbps, aunque el enlace sea grande. Si hay la más mínima pérdida de paquetes, puede reducirse fácilmente a menos de 1 Mbps.

• Ineficiencias a nivel aplicativo: aplicaciones que generan muchos mensajes/peticiones reducen netamente su velocidad. Microsoft CIFS, MAPI, HTTP son las tres más usadas y notables por su pérdida de rendimiento. Mapear una carpeta Microsoft con unos pocos archivos puede generar hasta 100 mensajes, cada uno con su respuesta, lo que implica multiplicar 100 por la latencia: con 120 milisegundos, solo mapear la carpeta puede llevar casi 12 segundos, lo que impide trabajar en tiempo real con ficheros.

• Limitación de la velocidad: la velocidad del cliente y el servidor serán entre 100 Mbps y 10 Gbps típicamente; pero esa velocidad intentada por ellos queda constreñida al caudal de la línea WAN, muy inferior. Esto ralentiza aún más la transferencia de datos.

• Saturación del enlace: añadido a lo anterior, en muchas ocasiones, demasiados datos en LAN intentarán pasar al otro lado por la WAN generando embotellamientos y saturación del enlace. Esto provoca jitter, que penaliza a las aplicaciones interactivas como la VoIP o sesiones de terminal.

Beneficios de Citrix CloudBridge

CloudBridge, como solución de optimización WAN, consiste en una pareja de equipos uno a cada extremo de la WAN (típicamente uno en la salida de la central o datacenter y uno en cada ubicación remota), de forma que el tráfico entre equipos de una ubicación y otra se modificará en su paso por la WAN para que fluya más eficientemente. Este funcionamiento es transparente tanto a clientes como servidores, que siguen funcionando como siempre.

CloudBridge actúa a varios niveles para contrarrestar estas limitaciones WAN y conseguir que los usuarios lejanos trabajen en WAN casi como si estuvieran en LAN. Los principales son:

• Optimizaciones TCP: utilizando variantes de TCP más eficientes en WAN y con líneas de hoy día, y con parámetros distintos a los que usan clientes y servidores. Por ejemplo, por defecto el tamaño de ventana permite enviar hasta 8 MB de datos sin necesitar un ACK (un “OK”) del otro extremo, cuando por defecto en TCP estándar son 64 KB.

• Optimización de aplicativos: esos mensajes y peticiones excesivas que antes mencionábamos en aplicaciones como MSExchange MAPI, MS CIFS o HTTP, se mitigan de diversas formas, haciendo que se acelere de forma notable el uso de las mismas. En el caso de CIFS, el CloudBridge que recibe una petición de un cliente actúa como proxy transparente CIFS para ese cliente, respondiendo en local a buena parte de los mensajes de aplicación, que por tanto no tienen que sufrir la demora de la WAN.

• Compresión/deduplicación: mediante distintos algoritmos de compresión pero sobre todo deduplicación se consigue que pase por la WAN una cantidad de datos habitualmente mucho menor que la real. En el caso de la deduplicación, lo que se hace es buscar patrones de tráfico (independientemente de en qué conexión de qué cliente o servidor, o protocolo) que se prevé se repetirán, de modo que se envían solo tokens que representen a patrones grandes; de esta forma podemos tener ratios sostenidos de entre 2:1 y 10:1 en los enlaces, pero con picos para CIFS, FTP y otros de hasta 1000:1 o más. La reducción de ancho usado es enorme liberando espacio para el resto de tráfico, y a la vez la velocidad en llegar los datos disminuye sensiblemente. Como beneficio añadido, es posible en ocasiones contratar una línea de menor caudal, con un ahorro desproporcionado si se trata de líneas con Latinoamérica, Asia y otras ubicaciones relativamente alejadas y mal comunicadas. El ROI de la solución llega a lograrse a veces en los primeros 6 meses.

• Calidad de Servicio (QoS): para evitar que la saturación perjudique a las aplicaciones interactivas, mediante QoS asignaremos prioridades de forma que siempre haya espacio suficiente para las aplicaciones sensibles a retardos o que consideremos más importantes.

Otros beneficios adicionales son:

• Visibilidad adicional: por su posición privilegiada viendo todo el tráfico WAN, se pueden generar informes ricos en datos útiles para tomar decisiones sobre los aplicativos y líneas. CloudBridge extraerá esos datos que reportará en una consola NetScaler Insight que generará los informes deseados.

• Multipath: hoy día las empresas tienden a buscar varias líneas de bajo coste en lugar de una línea más fiable pero cara, de forma que pueda sumarse la capacidad de las mismas. Los productos que balancean líneas, incluidos la competencia de CloudBridge, lo hacen en función de conexiones (una sesión de voz iría por UNA línea concreta a menos que falle y se reconecte), con retardos en cambiar de línea entre 2 y 6 segundos. CloudBridge es capaz de conmutar CADA PAQUETE, y en milisegundos, lo que le permite incluso elegir que parte de los paquetes de una conexión van por un canal diferente si en ese momento el retardo de esa línea fuera mejor. Esto abre la puerta a empresas que quieran deshacerse de líneas caras para pasar a agregar varias líneas baratas, con mayor ancho de banda y tolerancia a fallos, pero además consiguiendo la optimización de las mismas.

• Conectividad en capa 2 entre ubicaciones remotas: CloudBridge permite conectar dos ubicaciones como si hubiese una extensión de LAN entre ellas. En ubicaciones donde sea necesario pero la distancia imposibilita o eleva el coste de esta conectividad mediante una línea dedicada, es la forma más eficiente de emular esa conectividad sobre una línea de datos cualquiera de bajo coste.

• Versión sobre Windows: existe una versión de CloudBridge que funciona sobre hipervisor, en paralelo a una máquina Windows Server, de forma que el mismo equipo que optimiza la línea puede actuar como servidor de ficheros, impresión, DNS, DHCP, Doomain Controller o Read Only Domain Controller, de forma que consolide todas estas tareas en una oficina remota que requiriese esos servicios en local.

• Cliente software: existe también una versión de cliente software de optimización que, instalado en un PC, optimiza su tráfico al datacenter simulando el tener delante de sí un equipo físico; esto permite optimizar el tráfico de usuarios en movilidad.

• Optimizaciones Citrix XenApp y XenDesktop, de las cuales hablaremos en la segunda parte de este post.

Un ejemplo de la potencia de CloudBridge: simulando una línea entre Barcelona y Nueva York con 3 Mbps, 120 milisegundos sin pérdida de paquetes, dos ficheros que suman 90 MBytes se copian en 270 segundos. Si la línea se sube a 10 Mbps (con un coste notable mensual), se copian en 90 segundos.

La misma línea inicial de 3 Mbps con CloudBridge permite copiar los ficheros en 9 (NUEVE) segundos, lo que permite trabajar en tiempo real y da una experiencia de usuario similar a la de los usuarios locales al datacenter.

En un entorno más real, con 0,1% de pérdida de paquetes, la línea de 10 Mbps sin optimizar tardaría 195 segundos, mientras que la de 3 Mbps con CloudBridge solo 11 (ONCE!). Cuando menos, llamativo, ¿verdad?

Gracias por leer nuestro blog, participar y compartir.