This is my first english video tutorial (excuse me by the pronunciation) where we will learn how to run Citrix XenServer 5.6 on VMware vSphere 5 with support to run Windows virtual machines into XenServer.

vSphere 5 has a new feature that allows virtualize ESXi 4 and 5 itself. We will use this feature to virtualize XenServer into vSphere 5, because with Intel VT supported we can run Windows virtual machines in our XenServer virtualized.

httpvh://www.youtube.com/watch?v=qovROJNscUo

Este artículo abre una serie de ellos que descubrirá la Arquitectura de XenDesktop 5 (en adelante, XD5) de un modo detallado. Si habéis llegado a este artículo, es que con casi total certeza ya conocéis qué es XD5. Si no es así, decirte que XD5 es el producto de Citrix orientado a VDI, que busca una experiencia de usuario próxima a la de un PC dedicado.

Hoy vamos a conocer los elementos esenciales que necesita XD5 para su funcionamiento. A continuación un detalle de todos ellos:

• Un servidor para alojar:
  • El controlador. Este componente del core de XD5 se encarga de los servicios de autenticación de usuarios, gestionar el conjunto de entornos de escritorios virtuales de usuarios, y gestor de conexiones entre usuarios y sus escritorios virtuales. Este controla el estado de los escritorios, arranque/parada y configuración administrativa.
  • La interfaz Web. Permite el acceso seguro a los escritorios virtuales proporcionados por XD5 mediante cualquier dispositivo con explorador Web.
  • El servidor de licencias. Por defecto, este es instalado cuando instalas XD5, pero puedes elegir usar un servidor independiente.
  • La base de datos. Por defecto, este es instalado cuando instalas XD5, pero puedes elegir usar un servidor independiente. El motor de base de datos instalado es Microsoft SQL Express 2008.
  • Desktop Studio. Permite configurar y gestionar tu despliegue XD5. Este proporciona varios asistentes que te guiarán a través del proceso de configuración del entorno, crear tus escritorios y asignarlos a los usuarios.
  • Desktop Director. Permite al equipo de soporte de nivel 1 y 2 monitorizar tu despliegue XD5 y realizar las tareas diarias de mantenimiento. También permite interactuar con la sesión del usuario, usar asistencia remota de Microsoft y resolución de problemas.
• Un controlador de dominio ejecutando Active Directory. Este componente es requerido por XD5. Como buena práctica no se recomienda instalar XD5 o el servidor SQL en un controlador de dominio.
• Máquinas virtuales o PCs físicos que contengan los escritorios a proporcionar para los usuarios. Instalarás el agente de escritorio virtual en estas máquinas para gestionar las comunicaciones y las conexiones.
• Los dispositivos que accedan ejecutarán el cliente apropiado para que permita a los usuarios acceder a sus escritorios.

Bueno amigos, hasta aquí por hoy. Espero que esta primera entrega haya resultado de interés, ayudándonos a todos a establecer una base de partida para conocer mejor la arquitectura de XD5.

El artículo de hoy no va a ser un paso a paso que explique cómo realizar una tarea concreta. En esta ocasión intentaré que reflexionéis si las decisiones que tomáis para diseñar vuestro almacenamiento son las adecuadas.

A día de hoy aún resulta difícil hacerle ver a la compañía que va a explotar su infraestructura virtual la importancia del almacenamiento. En gran medida la culpa es de la persona que diseña (el comercial NO diseña) la solución a implantar. ¿Por qué digo esto?

Vendemos el almacenamiento como si de un contenedor de GRAN tamaño se tratase: cuánto más PETABYTES le venda más contento estará, ya que más máquinas virtuales puede alojar.

El primer paso que demos ha de ser el de transmitir a la compañía la importancia que ha adquirido el almacenamiento en una infraestructura virtual, ya que todas sus máquinas virtuales se alojarán ahí. En una infraestructura descentralizada de servidores físicos en la cual cada uno tiene su propio almacenamiento un fallo SÓLO afecta a ese servidor, pero en el caso de una infraestructura virtual si el almacenamiento falla la compañía se queda PARADA.

Ahora que todas las partes son conscientes de la criticidad de este componente, nuestro diseño debe cumplir con los requisitos de disponibilidad que la compañía nos marque. De todos modos debemos evitar los puntos únicos de fallo, de nada sirve vender HA si luego tenemos una sola fuente de alimentación. En estos requisitos de disponibilidad podemos contemplar las siguientes técnicas:

• Redundar las SPs (controladoras de almacenamiento) y las fuentes de alimentación.
• Usar RAIDs que proporcionen redundancia: RAID 1/10/5/6.
• Usar discos Hot Spare (discos de reserva) para tener una mayor ventana de reemplazo.
• Usar sitios secundarios para replicación (si el presupuesto lo permite).

Teniendo en mente las opciones anteriores, el siguiente paso es calcular el RENDIMIENTO que ha de cumplir nuestro almacenamiento para soportar las IOPs de las máquinas virtuales. En servidores de bases de datos SQL, Oracle y de correo Exchange 2003/2007 así como entornos VDIs este aspecto es fundamental para contar con el éxito asegurado en el diseño.

En la misma infraestructura descentralizada de la cual hablábamos anteriormente cada servidor podía tener como mínimo un RAID1, el cual proporciona unas 270 IOPs. Cuando se necesitaba más rendimiento se montaba otro servidor y esta era la forma de escalar. Las IOPs no van en concordancia con la capacidad del disco, sino con la latencia media de rotación y el tiempo medio de búsqueda tanto para lectura como escritura. Para entender mejor que rendimiento y capacidad no van de la mano vamos a poner un ejemplo.

Imaginad que tenéis 3 servidores físicos y que cada uno cuenta con 150GB en RAID1. Queremos convertir la infraestructura física a virtual y la cuenta más rápida sería: 3 SERVIDORES   x   150GB CADA UNO = 450GB EN TOTAL. Por lo que pensaríamos que con 2 HDs de 600GB en RAID1 ya tenemos almacenamiento suficiente para alojar los 3 servidores.

Como habréis observado hemos obviado por completo las IOPs en nuestros cálculos. Tal vez pueda parecer absurdo el que se nos olvide o no las tengamos en cuenta, pero ... ¿cuántos habéis hecho el mismo cálculo que acabamos de hacer? Es importante que siempre tengáis ese valor en cuenta. Para conseguir el mismo número de IOPs que el entorno físico (810 IOPs) necesitaríamos 6 HDs y para igualar el almacenamiento que fueran de 173GB.

A continuación se muestra una tabla con las IOPs de disco aproximadas, así como las penalizaciones de los diferentes RAIDs y cómo calcularlos:

Para calcular la penalización del RAID hay que sumar la capacidad RAW IOPs de todos los discos y dividirla por la suma de la penalización por el porcentaje de escritura con el porcentaje de lectura.

RAW IOPs / [(PENALIZACIÓN x (%ESCRITURA/100)) + (%LECTURA/100)]

Por ejemplo un RAID1 de 2 HDs 15K a 70% lectura y 30% escritura sería:

180+180 / [(2 x (30/100)) + (70/100)] = 360 / (0,6 + 0,7) = 277

En resumen, como habréis podido comprobar el cálculo de las IOPs es un factor muy importante a la hora de diseñar nuestra red SAN para nuestra infraestructura virtual. Se puede conseguir un mayor número de IOPs con menos discos o viceversa, por lo que siempre es importante realizar estos cálculos para asegurar el rendimiento y escalabilidad de la solución sobre todo en diseños de VDI.

Con este tipo de configuración podremos disponer de las características avanzadas de los entornos de virtualización, permitiéndonos la migración en caliente de máquinas virtuales entre hosts y otras tecnologías de alta disponibilidad y tolerancia a fallos.

Para poder llevar a cabo este laboratorio es necesario tener algún disco activado en nuestro servidor NAS QNAP para poder asociarlo a volúmenes iSCSI. Los pasos que vamos a seguir durante el artículo son los siguientes:

1. Activar iSCSI.
2. Crear volumen iSCSI.
3. Configurar iSCSI en Citrix XenServer.
4. Configurar iSCSI en VMware vSphere.

Activar iSCSI

El primer paso es acceder a la administración de nuestro dispositivo y dirigirnos al apartado Disk Management y elegir la opción iSCSI.

En la nueva pantalla activamos en la pestaña Portal Management la casilla Enable iSCSI Target Service y hacemos clic en APPLY para activar el servicio iSCSI.

Nos aparece un mensaje de recomendación, donde nos dice que si usamos iSCSI para un entorno de virtualización no se active la escritura en cache y nos indica donde desactivarla. De forma predeterminada viene desactivada, de todos modos no está mal comprobarlo.

Crear volumen iSCSI

Ahora hacemos clic en la pestaña Target Management y se nos abre un asistente, donde hacemos clic en OK.

De las tres opciones disponibles elegimos la primera opción iSCSI Target with a mapped LUN, la cual nos permite crear la conexión iSCSI donde conectará nuestro entorno de virtualización y posteriormente el volumen iSCSI. Hacemos clic en Next para continuar.

En la siguiente pantalla hacemos clic en Next, ya que nos indica las opciones que vamos a realizar en los pasos posteriores.

En el siguiente paso tenemos que asignar un nombre en nuestro Target Name el cual es obligatorio, además una descripción en el campo Target Alias el cual es opcional. Una vez hecho hacemos clic en Next.

Nosotros no vamos a usar autenticación para las conexiones iSCSI entre el almacenamiento y el entorno de virtualización, aunque es aconsejable si compartimos la red SAN con la red de usuarios. Hacemos clic en el botón Next para continuar.

En los siguientes pasos vamos a configurar el volumen iSCSI que vamos a crear. La primera opción a elegir es el modo en que reservamos el espacio en disco, el cual puede ser Thin-Provisioning o Instant Allocation.

Thin-Provisioning no reserva el espacio desde el primer momento, sino que va creaciendo conforme va aumentando su información almacenada, es interesante su uso ya que muchas veces reservamos un espacio que nunca llegamos a usar en su totalidad y desperdiciamos espacio posible para otras tareas.

Instant Allocation reserva el espacio desde el primer momento, por lo que la posibilidad de tener almacenamiento sin usar es mayor, ya que solemos sobredimensionar dicho almacenamiento y finalmente no se hace uso de él y no podemos reasignarlo para otras tareas.

Nosotros vamos a usar la opción Thin-Provisioning, ya que podemos asignar también más espacio del existente y en un futuro si nos aproximamos al límite de capacidad de discos podemos ampliarlo añadiendo nuevos discos. Le asignamos un nombre en el cuadro de texto LUN Name y elegimos su localización en la opción LUN Location. Sólo falta asignar el espacio, una vez hecho hacemos clic en Next.

A continuación nos aparece un resumen con las opciones seleccionadas, hacemos clic en Next una vez revisadas.

Comenzará la creación del volumen, una vez terminado podemos hacer clic en el botón Finish.

El siguiente paso se puede omitir, pero vamos a explicar como asignar un volúmen a un Target ya creado, para nosotros es necesario ya que en este artículo se muestra como conectar Citrix XenServer y VMware vSphere. Por lo tanto necesitamos dos volúmenes.

Para ello hacemos clic en Quick Configuration Wizard. Nos aparece nuevamente las tres opciones a elegir, esta vez como vamos a crear únicamente un volumen elegimos la opción iSCSI LUN only y hacemos clic en Next.

Elegimos nuevamente Thin-Provisioning, le asignamos un nombre, elegimos los discos, su almacenamiento y hacemos clic en Next.

Ahora vamos a asociar el volumen al Target, seleccionamos el que creamos anteriormente y hacemos clic en Next.

Repasamos el resumen de opciones seleccionadas y hacemos clic en Next si todo está correcto.

Una vez confirmada su creación correctamente hacemos clic en Finish.

Podemos comprobar que los dos volúmenes se han creado correctamente y que se encuentran asociados al Target correspondiente.

Configurar iSCSI en Citrix XenServer

Ahora vamos a crear un almacenamiento en nuestro XenServer del tipo iSCSI, es aconsejable para un buen rendimiento dejar una interfaz de red dedicada para la conexión iSCSI y que esta sea gigabit. Accedemos a nuestro entorno y hacemos clic en New Storage. Una vez iniciado el asistente elegimos el tipo Software iSCSI y hacemos clic en Next.

Asignamos un nombre a nuestro almacenamiento e introducimos la dirección IP de nuestro QNAP. Una vez hecho hacemos clic en Discover IQNs y seleccionamos el Target que creamos en el desplegable. Luego hacemos clic en Discover LUNs y elegimos el volumen que creamos para XenServer. Una vez elegidas todas las opciones hacemos clic en Finish para que comience la creación del almacenamiento.

Nos avisa que es necesario formatear el volumen y que los datos existentes se perderán, hacemos clic en Sí y comenzará el proceso.

Una vez terminado el formateo del almacenamiento ya lo tenemos disponible para comenzar a almacenar nuestras máquinas virtuales.

Configurar iSCSI en VMware vSphere

Igual que hicimos en XenServer, lo primero es acceder a nuestro vSphere a través del cliente. Una vez iniciada sesión en nuestro entorno de virtualización nos dirigimos a la pestaña Configuration del host y posteriormente elegimos el apartado Networking.

Como se decía antes, se recomienda una interfaz de red dedicada para el almacenamiento iSCSI. Nosotros vamos a usar una interfaz dedicada, para configurar esta interfaz hacemos clic en Add Networking.

Elegimos la opción VMkernel ya que es el tipo de opción a elegir para iSCSI. Una vez seleccionado hacemos clic en Next.

Seleccionamos la interfaz de red que no está en uso y hacemos clic en Next.

Le asignamos un nombre a la red que se va a crear y hacemos clic en Next, ya que no vamos a usar ningunas de las opciones disponibles.

Asignamos un direccionamiento de la red de almacenamiento y hacemos clic en Next.

Comprobamos el resumen, si todo es correcto hacemos clic en Finish.

Una vez creada la red de almacenamiento en nuestro vSphere, nos dirigimos al apartado Storage Adapters. En él vamos a configurar el acceso a nuestro QNAP.

Seleccionamos el adaptador iSCSI y hacemos clic en Properties.

En la ventana que nos aparece accedemos a la pestaña Dynamic Discovery y hacemos clic en Add.

Introducimos la dirección IP de nuestro servidor QNAP y hacemos clic en OK. Posteriormente hacemos clic en Close para cerrar la ventana.

Al cerrar la ventana nos aparece un mensaje si deseamos escanear el adaptador en busca de volúmenes, hacemos clic en Sí.

Después de hacer finalizado el escaneo de luns podemos observar que ha encontrando dos volúmenes, el de XenServer que ya lo tenemos asignado y el que asignaremos a nuestro vSphere.

Ahora nos dirigimos al apartado Storage y hacemos clic en la opción Add Storage.

Dejamos seleccionada la opción Disk/LUN ya que es el tipo usado por iSCSI y hacemos clic en Next.

Ahora vamos a elegir el volumen correspondiente, debemos tener cuidado de no elegir un volumen en uso. Podemos identificar el volumen que deseamos comparando el número de LUN mostrada en nuestro vSphere con el número de LUN asignada en nuestro QNAP. Seleccionamos la correspondiente LUN y hacemos clic en Next.

Nos muestra un resumen con los datos de la LUN, hacemos clic en Next.

Le asignamos un nombre y hacemos clic en Next.

Ahora elegimos el tamaño de bloque, es importante ver que valor elegimos, ya que determina el tamaño máximo que podrá ocupar un fichero vmdk. En nuestro caso como el volumen es de 120 GB y vamos a usar toda su capacidad y no podemos crear ficheros superiores a 256 GB, dejamos el que aparece de forma predeterminada. Una vez elegidas todas las opciones hacemos clic en Next.

Revisamos el resumen de opciones elegidas y si todo es correcto hacemos clic en el botón Finish.

Ya disponemos de nuestro almacenamiento VMFS para poder crear máquinas virtuales.

Cuando usamos almacenamiento iSCSI es recomendable cumplir algunas características como son:

• Interfaz de red dedicada para el almacenamiento ya sea 1Gbps ó 10Gbps.
• Redundancia en las interfaces de red.
• Activar Jumbo Frames en el almacenamiento, interfaces de red y en todos los switches por los que fluya el tráfico.

A continuación vamos a enumerar la infraestructura del laboratorio y posteriormente su arquitectura. La infraestructura necesaria es:

• Host Citrix XenServer 5.5 o superior con al menos 4 GB RAM y 150 GB de disco (no es necesario Intel-VT o AMD-v).
• PC para ser usado con un cliente FTP para las pruebas de rendimiento.
• 2 x VM con Citrix Branch Repeater VPX instalado (1 vCPU, 1 GB RAM, 60 GB de disco y 2 vNIC; cada VM).
• 1 VM con WANem ejecutandose (1 vCPU, 512 MB RAM, sin disco y 2 vNIC).
• 1 VM con un servidor FTP (1 vCPU, 256 MB RAM, 8 GB de disco y 1 vNIC; nosotros usamos Debian Lenny).

La arquitectura del laboratorio se basa en un entorno de virtualización Citrix XenServer 5.5 ya que es imprescindible para poder ejecutar Citrix Branch Repeater VPX. En nuestro host vamos a ejecutar un total de 4 máquinas virtuales, 2 Citrix Branch Repeater VPX, 1 WANem y 1 Debian Lenny con servicio FTP.

La conexión de red entre máquinas virtuales se va a realizar con 4 redes, una de ella es Network0 que es creada de forma predeterminada con la instalación de Citrix XenServer y es asignada a la interfaz física NIC0; las 3 redes restantes se van a crear como red interna, por lo que no estará asociada a ninguna interfaz de red física. Las redes internas recibirán el nombre de Internal1, Internal2 e Internal3. La distribución de redes para las máquinas virtuales es la siguiente:

• Citrix Branch Repeater VPX (Central): Dispondrá de 2 vNIC pertenecientes a Network0 e Internal1. IP 192.168.1.13.
• WANem: Dispondrá de 2 vNIC pertenecientes a Internal1 e Internal2. IPs 192.168.1.14 (Internal1) y 192.168.2.14 (Internal2).
• Citrix Branch Repeater VPX (Oficina): Dispondrá de 2 vNIC pertenecientes a Internal2 e Internal3. IP 192.168.2.13.
• Debian Lenny con servicio FTP: Dispondrá de 1 vNIC perteneciente a Internal3. IP 192.168.2.1.

Una vez conocida la infraestructura y su arquitectura cabe decir que configuraremos WANem con enlaces simétricos de 512 Kbps, ya que como sabemos Citrix Branch Repeater VPX en su versión Express está limitada a dicho ancho de banda en subida.

Las etapas a seguir durante el artículo son las siguientes:

1. Crear redes en Citrix XenServer.
2. Ejecutar y configurar WANem.
3. Instalar y configurar Citrix Branch Repeater VPX.
4. Pruebas.

Crear redes en Citrix XenServer

Accedemos a nuestro host Citrix XenServer con XenCenter y nos dirigimos a la pestaña Network.

Ahora hacemos clic en Add Network y en el asistente elegimos la opción Internal Network y pulsamos en Next.

Le asignamos el nombre Internal1 y hacemos clic en Next.

Para terminar dejamos sin marcar la opción de que se añada automáticamente a las nuevas máquinas virtuales que creemos y hacemos clic en Finish.

Repetimos los mismos pasos para crear las redes Internal2 e Internal3.

Ejecutar y configurar WANem

Para realizar la emulación WAN vamos a usar el appliance WANem, podemos seguir su instalación en el artículo Emulación WAN en Citrix XenServer con WANem en este blog. El interface 0 lo asignamos a la red Internal1 y el interface 1 lo asignamos a la red Internal2. A eth0 le asignamos la dirección IP 192.168.1.14 y a eth1 le asignamos la dirección IP 192.168.2.14. Recordamos que tenemos que configurar nuestro WANem con enlaces a 512 Kbps con 70 ms de latencia para emular líneas ADSL.

Instalar y configurar Citrix Branch Repeater VPX

Ahora creamos los dos Citrix Branch Repeater VPX necesarios, podemos seguir el artículo Instalando Citrix Branch Repeater VPX en este blog. Sólo tenemos que tener cuidado a la hora de asignar las redes a las dos tarjetas de red. En el Citrix Branch Repeater VPX de la CENTRAL asignamos el interface 0 a la red Network 0 y el interface 1 a la red Internal1. Además durante la configuración inicial le asignamos la dirección IP 192.168.1.13 y como puerta de enlace 192.168.1.14.

En el Citrix Branch Repeater VPX de la OFICINA configuramos el interface 0 en la red Internal2 y el interface 1 en la red Internal3. Además durante la configuración inicial le asignamos la dirección IP 192.168.2.13 y como puerta de enlace 192.168.2.14.

Cuando tengamos que configurar los parámetros DNS de los Citrix Branch Repeater VPX podemos configurar también el hostname, asignando BR-CENTRAL y BR-OFICINA. Podemos comprobar si existe conectividad desde el PC que vamos a usar como cliente, haciendo un ping a las direcciones de nuestros Citrix Branch Repeater VPX. Decir que en el PC tenemos que configurar como puerto de enlace la IP 192.168.1.14 del WANem. Recordar también que el ancho de banda en Citrix Branch Repeater VPX ha de ser como máximo el 90% de la conexión WAN, en nuestro caso 461 Kbps para una conexión WAN de 512 Kbps.

Pruebas

Con nuestro servidor FTP arrancado y con conectividad a él vamos a realizar la primera prueba. Consistirá en subir un fichero de gran tamaño con la optimización WAN deshabilitada. Para deshabilitarla accedemos al BR-CENTRAL y en el apartado Monitoring en la opción System Status hacemos clic en Disable.

Si todo ha ido bien veremos que el estado ha pasado de ser NORMAL a DISABLED. Ahora podemos ejecutar nuestro cliente FTP como Filezilla y subir un fichero de al menos 5 MB. Nosotros estamos subiendo 8,5 MB y estima que tardará 2 minutos 15 segundos.

Mientras lo dejamos subiendo podemos ver en la opción Usage Graph del apartado Monitoring de nuestro Citrix Branch Repeater VPX la optimización del tráfico que está pasando por él. Comprobaremos que no realizando ninguna optimización.

Ahora vamos a realizar la prueba con la optimización habilitada. Solo tenemos que volver a System Status y hacer clic en Enable.

Eliminamos el fichero del servidor FTP y volvemos a subirlo. Podemos comprobar que el tiempo de transferencia al principio será algo superior así como la tasa más baja, pero conforme se aproxima el final del fichero la velocidad se ve aumentada. La optimización no se hace visible hasta que no se sube el fichero por segunda vez, por lo que sólo notaremos una breve mejoría esta vez.

Si deseamos podemos ver nuevamente las gráficas, ahora si podremos ver que el tráfico se está optimizando "ALGO". Si queremos que se vaya refrescando automáticamente hacemos clic en Toggle en la opción Auto-Refresh.

Ahora volvemos nuevamente a eliminar el fichero del servidor FTP y volvemos a subirlo, será cuando comprobaremos que la tasa de transferencia es bastante más rápida y en la gráfica el tráfico esta más optimizado.

]]> http://blog.e2h.net/2010/06/03/laboratorio-citrix-branch-repeater-vpx-wanem/feed/ 0