Provisioning Server es un software basado en tecnología de Streaming. Usando PVS los administradores pueden preparar un dispositivo (Master Target Device) dónde se instalará un SO y software necesario en el mismo. Un disco virtual (vDisk) será creado a partir de este Master Target Device y almacenado en la red.

Con la imagen accesible desde un lugar de la red, un dispositivo puede arrancar utilizando esta imagen sin necesidad de disponer de un disco asignado. PVS realiza un streaming del SO contenido en el vDisk al dispositivo bajo demanda y en tiempo real. A diferencia de la tecnología Thin-client, todo el procesamiento tiene lugar en el propio dispositivo destino.

Debemos tener varios componentes presentes:

Provisioning Server: Es cualquier servidor que puede proporcionar el servicio de Streaming del vDisk. Es utilizado para proporcionar al dispositivo, vía streaming, el vDisk generado. En algunas implementaciones el vDisk reside en el propio vDisk. En grandes implementaciones, PVS obtiene el vDisk de un recurso compartido en la red. PVS además proporciona opciones de Alta  Disponibilidad y de balanceo de carga entre conexiones.
vDisk Image: vDisk son imágenes de disco que PVS utilizar para enviar via Streaming a dispositivos finales.

Este puede ser configurado en dos modos:

• Privado: dónde los cambios que realice el usuario son mantenidos y actualizados en el vDisk.    
• Standard: (Solo-Lectura) el cual descarta todos los cambios realizados por el usuario después de un reinicio.

Target Devices: El TD es un dispositivo, PC o Servidor, que arranca su sistema operativo desde un vDisk. Este es considerado Target Device.

Network Storage: vDisk generalmente suelen almacenarse en un dispositivo de red (SAN,NAS, Windows File Server, etc.). Ello proporciona redundancia y alta disponibilidad en las imágenes de vDisk. En entornos pequeños el NS puede ser local en el propio PVS.

Write Cache Files: Cuando se utiliza una imagen Standard en el vDisk se utiliza el disco en modo Solo-Lectura. Cada dispositivo necesita un cache dónde almacena cualquier escritura del Sistema. Este es un punto muy importante del despliegue a controlar durante las primeras fases.
Separemos la implementación de PVS en varios puntos:

• Red
• Almacenamiento
• XenDesktop DDC
• Hypervisor
• PVS for Desktops
• VDisk/Target Devices
• Escalabilidad

RED

Domain Name System: Un  componente clave en un entorno de PVS. DDC es utilizado para el registro de Target Devices en el actual entorno DNS.

PVS: Para proveer de un Troughtput óptimo , se recomienda el uso de multiples NICs en los servidores de PVS.

Siempre que sea posible separaremos el Stream de vDisk del resto de servicios de la red de producción dedicando VLANs.

ALMACENAMIENTO

Los requerimientos de almacenamiento necesarios para el uso de PVS dependen del número de imágenes  vDisk creada y mantenidas, el tipo utilizado (standard/privado), el Sistema operativo instalado, los componentes adicionales o aplicaciones instalados en cada imagen, planes futuros para la instalación de nuevos componentes o aplicaciones y la localización del fichero de cache de cada máquina aprovisionada.

Tipo de Discos: Cuando se utiliza un disco en modo Standard, múltiples dispositivos pueden arrancar desde el mismo vDisk. Si embargo solo es necesario disponer una única copia del disco. Puede ser utilizada una segunda copia para realizar los Updates de la imagen.

Cuando se utiliza una imagen en modo Privado, cada dispositivo debe disponer de su copia de vDisk asignada a su Target Device.

Espacio Estimado vDisk : El tamaño del vDisk depende en gran parte del sistema operativo y el número de aplicaciones instaladas en el sistema. Cuantas más aplicaciones, mayor será el tamaño del vDisk. Por ello, se recomienda crear un vDisk con un tamaño mayor al espacio necesario, ya que puede ser necesario instalar algún aplicativo a posterior así como actualizar el sistema. El siguiente cuadro muestra una estimación dónde se han instalado unas pocas aplicaciones tales como el paquete Office.

Sistema Operativo	Espacio Estimado vDisk
Windows XP	15 GB
Windows Vista	25 GB

Para estimar el espacio necesario, podemos seguir los pasos indicados a continuación:

•    Target Device Space: Identificar el espacio utilizado en el Master Target Device. Se puede ver dicho tamaño viendo las propiedades del disco.
•    Tamaño de aplicaciones: A medida que se instalan aplicaciones el disco ira creciendo. Si tenemos planeado instalar aplicaciones en los vDisk

creados, deberemos proveer de espacio adicional para poder albergar los aplicativos a instalar. Citrix recomienda añadir un 25% más de espacio adicional permitiendo el instalado de cualquier aplicación adicional necesaria.

Para minimizar el espacio necesario de almacenamiento:

• Minimizar las aplicaciones instaladas en cada vDisk. Minimizar el número de aplicaciones instaladas en cada disco ayuda a reducir el espacio necesario por cada vDisk. Además ayuda en la optimización del disco, manteniendo además las imágenes lo más genéricas  posible. Utilizando XenApp para el suministro de aplicativos conseguiremos minimizar aún mas el espacio necesario.
• Minimizar el número de vDisk. Cada vdisk requiere espacio físico de almacenamiento. Consecuentemente, cuantos menos vDisk tengamos, menos espacio de almacenamiento será necesario. Citrix recomienda disponer de un Backup por vDisk, que será utilizado para realizar los Updates cuando sea necesario, con lo que podemos multiplicar x2 el espacio requerido por lo vDisk para saber el espacio necesario de los mismos.

Write Cache File: Cada máquina (Target Device) necesita de un fichero volátil para la escritura de la cache, la cual es borrada tras el reinicio de máquina. El tamaño del cache depende de muchos factores, incluido los tipos de aplicaciones utilizadas, las tareas ejecutadas y la frequencia de reinicio. Un espacio estimado para un disco aprovisionado que corre únicamente aplicaciones de ofimática Word y Outlook que es  reiniciado diariamente, puede necesitar alrededor de 200-500MB.  Equipos dónde es necesario aplicaciones que utilizan gráficos intensivamente (como PowerPoint, VisualStudio, CAD, etc) el espacio necesario será mucho mayor.

• Se recomienda un análisis detallado para determinar el espacio necesario de los ficheros de cache en el entorno actual.
  Cache File Location: Disponemos de varias opciones dónde alojar el fichero CACHE. Cada una con sus ventajas e inconvenientes, las cuales deben ser analizadas anteriormente antes de proceder a determinar el lugar dónde poner el “cache file location”

Almacenamiento Físico Local:  Si estamos utilizando Equipos de escritorio o servidores Balde, Citrix recomienda aprovechar la RAM o el disco local del dispositivo para el almacenaje del cache. Cuando ello sea llevado a cabo debemos considerar:

• Dado que el acceso a memoria RAM es mas rápido que la lectura/Escritura en un disco, si obtamos por poner el fichero de cache en la RAM del dispositivo dispondremos de un mejor rendimiento en comparación en acceso a disco. Si tenemos un entorno de aplicación única, sin duda es la mejor opción.
• Cuando se utiliza el fichero cache en RAM, este está limitado en tamaño a la RAM disponible del dispositivo utilizado. Si el fichero cache sobrepasa esta memoria, deberá utilizarse el disco local para el almacenaje del fichero de cache. Si se utiliza la RAM y esta se llena, pueden ocurrir errores no esperados , puesto que al intentar escribir, no sería posible al no disponer de memoria suficiente.
• Siempre dispondremos de mas espacio para el fichero de cache en disco que no en RAM. Si no disponemos de disco ni RAm suficiente (como Thinclients por ejemplo) entonces deberá ubicarse el cache file en un lugar de la red desde el cual accederemos desde PVS.

Disco Cliente (Virtual Machine vDisk): Es posible utilizar la RAm de una máquina virtual o su disco virtual para el almacenado del fichero de cache de usuario. Cuando esto sea considerado, tenga en cuenta:

• Almacenar el fichero de cache como parte de la RAM de la VM, requiere RAM adicional, o disco físico adicional igual al espacio necesario para albergar ese fichero de cache. Si este se almacena en el propio servidor de PVS, no se dispondrá de HA. Para  disponer de HA, deberemos utilizar el modelo PVS Proxy Mode.
• Este modelo da un buen rendimiento en general. Citrix recomienda que el PVS disponga de varias tarjetas de red, una dedicada para la transmissión, un par dedicado para el acceso al almacenamiento empresarial (iSCSI,sAN,NAs,Cifs) y una tarjeta para el tráfico PXE.
• Esta opción permite añadir capacidades de recuperación en caso de falla, ya que solo la máquina afectada se verá afectada en caso de no disponer de espacio cache.
• Cada máquina virtual debe ser capaz de ver el disco adicional asociado.
• Utilizar el disco cliente para el caché, reducirá el tráfico de la red global .

Enterprise Based Server (PVS Proxy Mode): El fichero de cache es almacenado en un recurso compartido sobre una solución de almacenamiento (SAN/NAS) accesible desde PVS. En este caso, PVS realiza de proxy entre la máquina virtual y la solución de almacenamiento. Ello provee de HA, siempre y cuando dispongamos de dos pvs.

• Esta solución permite utilizar configuraciones de HA.
• Utilizando PVS como proxy para el tráfico, supone un impacto I/O en la red y reduce la escalabilidad de cada servidor PVS. Este puede impactar directamente sobre el número de clientes activos que son soportados por un servidor PVS.
• Definir el espacio necesario para almacenar el cache de todos los desktops aprovisionados es crítico para no quedarnos sin espacio y que ocurran problemas inesperados.
• No se recomienda colocar el fichero de cache en el servidor de PVS en entornos dónde el HA este habilitado. Si ello se configura así, cada PVS se convierte en punto único de fallida, y la HA no se puede habilitar.

 

Cada organización debe definir y determinar su SLA para así ver qual es el método requerido para la configuración del despliegue de Desktops.

Determinar el espacio Cache necesario:  Se recomienda utilizar un entorno piloto/POC, para determinar el espacio necesario en el fichero de Cache.  Para ello, en el entorno piloto, configuraremos el file cache location en el propio servidor de PVS y deberemos habilitar el acceso para que trabajen varios perfiles de usuarios. Durante unos días deveremos  dejar trabajar a dichos usuarios podremos determinar el tamaño del fichero de cache necesario para dichos usuarios. En el entorno productivo, reiniciar la máquina diariamente, ayuda a reducir el tamaño del fichero, ya que los ficheros son purgados durante cada reinicio.

Reiniciar los Desktops aprovisionados frequentemente:  Un fichero de cache crece, y continua creciendo mientras las máquina en cuestión no sea reiniciada. Dependiendo del número de aplicaciones y el uso del mismo, los tiempo de reinició deberían ser menores o mayores.  Citrix recomienda el reinicio de dichas máquinas diariamente siempre que sea posible. Si ello no es posible, se recomienda mínimo un reinicio semanal para minizar el impacto que ello pueda tener en nuestro almacenamiento. Con XenDesktop podemos utilizar las opciones de “logof behaivor” para habilitar el reinicio o apagado automático para automatizar este proceso.

XENDESKTOP DDC

No instalar WI e IIS:  XD  instala automáticamente IIS y WI. Muchas organizaciones ya disponen de un servidor web el cual puede ser aprovechado para instalar WI. No instalar estos componentes en dicho servidor, ayudan a incrementar el rendimiento y la escalabilidad de los DDCs en un entorno productivo. Las organizaciones con un IIS pueden tomar los siguientes caminos:

• Durante la instalación, utilizar: Setup.exe –nosites para que no sea instalado WI durante la instalación.
• Si la instalación fue realizada, debería considerarse la desinstalación del componente o deshabilitar los servicios asociados.

Separar el Farm Master del Controlador: Por defecto, en una granja de XenDesktop el DDC inicial instalado es el Master  Farm que dispone de obligaciones especificas como  el Datacollector, ajustar la resolución del Escritorio durante su lanzamiento, y administrar la infraestructura host. En un servidor único, estos roles són llevados por el mismo servidor. En un entorno donde tenemos varios servidores en la granja, seria conveniente separar el rol de DDC del DataCollector delegando dichas funciones a otro servidor, dejando el servidor Master dedicarse a las obligaciones especificas de su rol.

Cada DDC es un servidor Master potencial. Durante la elección del mismo pueden establecerse varios niveles de prioridad a fin de que en caso de un problema con el servidor Master, otro servidor de la granja retome el rol de Master Server. La configuración del mismo se realiza utilizando el registro, modificándolo en cada uno de los servidores miembros para establecer las prioridades. Cada servidor puede ser uno de los siguientes roles:    

• Master: Este servidor es el Master Server elegido.
• Backup: Esta configuración habilita al servidor a tomar el rol en caso de que el Master no esté disponible.
• Member: Los servidores con esta configuración no són nunca normalmente servidores master, pero pueden asumir el rol, si ni el servidor Master ni los servidores Backup están disponibles.

Durante el arranque del Desktop, el DDC Master es el encargado de controlar y manejar las conexiones. Cuando se configura WI para el acceso a un DDC miembro, WI envía una petición al servidor Master. Si el DDC Master no esta disponible, otro miembro de la granja asume el rol según las preferencias establecidas. Una vez el DDC establece la conexión con el desktop virtual, ICA establece la conexión directa entre el Desktop Virtual y el cliente (EndPoint). El DDC ya no realiza nada mas.

Cuando se utilizan varios servidores DDC Citrix recomienda establecer un servidor Master dedicado y el resto de servidores como miembros de la granja. WI se configura para que apunte a un servidor miembro para minimizar la carga de CPU en momentos dónde puede haber una alta tasa de logon. Para configurar el servidor como Master, Backup o Member, realizaremos:

1.    Abrimos el editor de Registro:
2.    HKLM/Software/Citrix/IMA/RUNTIME/UseRegistrySetting

DWORD=UserRegistrySetting
Value=1

3.    HKLM/Software/Citrix/IMA/RUNTIME/MasterRanking

DWORD=Value
Dondé value =     1 para el Master
        2 para el Backup
        3 para el miembro

Para mas información: CTX117477

Acelerar los comandos de la Virtual Machine Hosting: Cuando se envía un gran número de acciones de apagado/encendido para una máquina virtual alojada (Virtual Machine Hosting Infraestructure), la infraestructura host puede verse sobrepasado en recursos y no responder correctamente durante un breve periodo de tiempo, poniendo todas las peticiones en cola. Por defecto las comunicaciones entre el DDC y la infraestructura de virtualización habilitan el uso de un 10% del total del pool. Es decir, que si tenemos 500VM en un Desktop Group,  solo 50VM podrán realizar operaciones de arranque al mismo tiempo.
Para modificar el número de peticiones que pueden ser enviadas a una virtual machine realizaremos lo siguiente:

• Abrir el directorio c:\Archivos de programa\Citrix\VMManagement\CDsPoolMgr.exe.conig
• Editar el fichero de configuración y añadir la siguiente línea: <add key=”MaximumTransitionRate” Value=”20”/>

Ello habilita el poder llevar a cabo 20 comandos concurrentes sobre las operaciones de una VM.

HYPERVISOR

Asignación de CPUs:   Durante la creación de VM muchas veces se asignan varias CPUs para dotar a las VM de mayor rendimiento. Ello es un practica incorrecta, puesto que:

• La mayoría de las aplicaciones basadas en usuario, solo disponen de un subproceso y no se beneficiarán de una configuración multi-cpu.
• Muchas aplicaciones de usuario no requieren cantidades importantes de procesamiento, con lo cual no es necesario disponer de varias CPUs.

Reducir Comandos del DDC – Hypervisor: El controlador DDC envía comandos de bajo nivel a la capa del hypervisor para realizar las tareas básicas de (parar, detener, reiniciar, etc). Si se envían demasiados comandos para la ejecución de tareas de forma simultáne, puede ocasionar problemas con el hypervisor, ya que estas tareas tienen un gran impacto en los recursos del servidor y afecta directamente al rendimiento de los usuarios.

Uso del Memory Page Sharing:  Memory Page Sharing permite en vSphere compartir porciones de memoria que són idénticas en diferentes VMs. Eso proporciona la capacidad de mejorar el rendimiento de los escritorios virtuales al tener un impacto positivo en los recursos de memoria del servidor. Sin embargo esta característica solo proporciona valor a los sistemas operativos más antiguos (XP, 2003) que disponen de ficheros de memoria de 4KB. Los sistemas operativos mas nuevos, Windows 7 y 2008 disponen de archivos de paginación mayores (2MB) por defecto, haciendo mas difícil la probabilidad de encontrar duplicados en memoria.

Memory Balloning y memory overcommit: MB permite desplazar dinámicamente la RAM de las VMs inactivas a cargas de trabajo activas. Esta función induce presión de memoria en las VM inactivas para obligarlas a utilizar su archivo de paginación y liberar memoria para las VMs activas. Con MO, podemos asignar más RAM de la que disponemos en nuestro hypervisor actualmente.  

En la práctica, en un entorno VDI ello puede suponer un problema, reduciendo la experiencia del usuario. Obligar a los Desktop Virtuales a liberar memoria es solo una solución temporal. Si un gran número de escritorios pasan de la inactividad a la actividad y reclaman memoria, si no existe memoria suficiente el hypervisor se verá obligado a usar su archivo de paginación lo que relentizará su uso. Un desktop ejecuta aplicaciones de escritorio que a menudo tienen más pérdidas de memoria  y disponen de una limpieza deficiente en cuanto a procesos en relación a un servidor. La mayoría de máquinas consumen más memoria a medida que el día avanza, lo que influiría directamente en la sobreasignación de la misma. Se recomienda deshabilitar dichas funciones en entornos VDI.

PROVISIONING SERVER

Deshabilitar el CheckSum offloading en el adaptador de red:  Esta opción no es comptaible con PVS, pudiendo causar un rendimiento lento cuando esta habilitado sobre un adaptador de red físico. Los síntomas de esta capacidad pueden ser:

• Exesivo número de “retries”
• Lentitud en el rendimiento de ICA con máquinas virtuales
• Cuelgue o congelación de sistemas Windows XP SP2
• Lentitud con el uso de aplicaciones publicadas en PS4.5 sobre entornos XenDesktop

Se recomienda deshabilitar esta funcionalidad, tanto en el servidor PVS como en los Target Devices.  En muchas tarjetas de red, es posible deshabilitar esta opción en las propiedades -> Configuración avazada.

Muchas Nics no permiten configurar esta opción mediante las propiedades de la tarjeta con lo cual será necesario editar el fichero de registro para deshabilitar esta opción. Abrir el editor de registro y añadir la siguiente clave:

HKEY Local Machine\System\CurrentControlSet\Services\TCPip\Parameters
DWORD: DisableTaskoffload
Value=1

Deshabilitar el “TCP Large Send offload”: Esta opción permite a la capa TCP construir mensajes TCP de mas de 64KB de longitud y habilita su envio via IP a través de los dispositivos Ethernet.  Esta funcionalidad causa un aumento de la latencia y de timeouts en PVS, y se recomienda deshabilitar esta opción en todos los servidores de PVS y los target Devices.

Para deshabilitar esta opción, deberemos situarnos en las opciones avanzadas de las propiedades de la NIC en cuestión. Algunas pueden no ser modificables con lo que deberemos modificar el registro añadiendo la siguiente clave:

HKEY Local Machine\System\CurrentControlSet\Services\BNNS\Parameters
DWORD: EnableOffload
Value=0

Auto Negociación:  Esta opción puede causar largos tiempos de boot y timeous en PXE, especialmente cuando se arrancan varios Target Devices. Citrix recomienda reconfigurar todos los puertos de PVS en la NIC y en el Switch para deshabilitar la autonegociación en la configuración de velocidad de conexión.

Deshabilitar el “Spanning Tree” o habilitar “PortFast”:   Esta funcionalidad gestiona la presencia de bucles en topologías de red debido a la existencia de enlaces redundantes .  El protocolo permite a los dispositivos de interconexión activar o desactivar automáticamente los enlaces de conexión, de forma que se garantice que la topología está libre de bucles. El tiempo que tarda en llevar a cabo este proceso depende del tamaño del tamaño de la red, pudiendo llegar a causar problemas de timeout en el PXE y hacer que las vM queden paralizadas o en estado de reinicio. Para solucionar esto, es necesario deshabilitar STP o habilitar PortFast o FastLink.

Maximizar la cache del sistema:  Todo el tráfico entre el vDisk y el target Device pasa a través de PVS, independientemente  de dónde resida ell vDisk. El uso del caché de 2003 Server puede mejorar la implementación y la eficiencia del vDisk. El sistema operativo cachea los ficheros leidos y las operaciones de escritura a nivel de bloques. Cuando un dispositivo arranca desde un vDisk compartido, los clientes posteriores no necesitarán realizar operaciones de E/S en disco mientras realizan operaciones similares.  Para aumentar la velocidad en la que el vDisk se transmite se recomienda optimizar el cache del servidor siguiendo estos pasos:

1.    Botón derecho en “My PC” y seleccionar la pestaña “Avanzada”.
2.    Seleccionar  “Configuración” y posicionarse en la opción “Rendimiento” en la sección “Avanzada”
3.    Seleccionar la opción “System Cache” en la sección de “uso de memoria”.

Esta opción puede ser configurada alternativamente modificando una clave del sistema. Para ello modificar:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\MemoryManagement
DWORD: LargeSystemCache
Value=1

Uso del Team en NICs incrementa el Troughput: El I/O de red en PVS puede limitar el factor de escalabilidad en el servidor. Realizando el Teaming de dos NICs para ganar Troughtput  permite a un servidor con un máximo de 2GB de I/O de red incrementar el rendimiento de la red. Además elimina el único punto de fallida de red cuando utilizamos una única NIC en el entorno.

Aislar el tráfico de Streaming: cuando sea posible se recomienda aislar el tráfico creado al realizar el stream del vdisk del entorno de producción.
Realizar una copia de cada vDisk:  A fin de poder modificar las imágenes creadas para PVS, se recomienda disponer de una copia de cada uno de los vDisk posicionadas en modo “private”. Este modo permite al administrador realizar aquellos cambios que requiera cada imagen (update, hotfixes, nuevo software, etc) y de este modo disponer de una imagen actualizada. Disponer de una copia de cada vDisk es también una recomendación para planes de DR y de BCP.

VDISK/TARGET DEVICES

Una imagen virtual del disco limpia es crítica para un correcto deploy del vDisk hacia el dispositivo final mientras se utiliza PVS. Cuando se crea una imagen vDisk es importante asegurarse que el Master target disk no contiene información innecesaria, tales como pueden ser aplicaciones que no se utilizan o perfiles de usuarios. Algunos puntos recomendables:

Incrementar los Timeouts de Servicio: Cuando se reinicia un gran número de VMs en un corto periodo de tiempo, puede ser necesario incrementar el tiempo de timeout del Service Control Manager, habilitando más tiempo para que puedan ser iniciados los servicios y llevar a cabo el registro del Desktop en el DDC. Para habilitar o incrementar esta opción, se recomienda la modificación de la siguiente clave de registro en la imagen vDisk:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control
Dword: ServicesPipeTimeout
Decimal Value= 180000 (3 minutos)
Mas información en: Kb839803

Optimizando el vDisk: Optimizar el Master target disk es sin duda un punto muy importante en el deploy del mismo. Para ello aconsejamos la lectura del siguiente artículo:

http://www.ctxdom.com/index.php?option=com_content&view=article&id=414:como-optimizar-winxp-con-provissioning-services&catid=31:general&Itemid=72

Borrado de ficheros Zero Out: SDelete es una herramienta de borrado de ficheros sergura que puede ser utilizada para la limpieza de los sectores del disco no utilizados. Ello ayuda al SO a funcionar mas rápido. Para descargar la herramienta y encontrar mas información al respecto:

http://technet.microsoft.com/enus/sysinternals/bb897443.aspx

Citrix recomienda realizar una limpieza y un “Zeroing”  del espacio libre del disco para optimizar el rendimiento del SO utilizando el comando: sdelte  -c  -z

Preparando el vDisk: Citrix recomienda seguir el siguiente CheckList para  la creación del vdisk. Excepto en momentos puntuales, se recomienda realizar los cambios con una cuenta de administrador local (no de dominio).
1.    Preparar el Hardware:

a.    Actualizar la Bios del master target Device
b.    Abrir el Device Manager y solucionar el problema con drivers desconocidos
c.    Asegurarse de que no hay errores de disco ni con los dispositivos de red
d.    Incluir la máquina en el dominio e identificar y corregir problemas de red que puedan aparecer.
e.    Verificar que el disco esta limpio y funciona correctamente. Realizar un CHKDSK /F para verificar la integridad del mismo.

2.    Eliminar características y ficheros que no se utilicen:

a.    Borrar cualquier fichero temporal que no sea necesario. Utilizar herramientas de limpieza si es necesario.
b.    Verificar el contenido de /TEMP y de /Windows/Temp
c.    Borrar cualquier perfil de usuario que no sea necesario
d.    Eliminar desde el panel de control todas aquellas aplicaciones no necesarias.
e.    Comprobar en ProgramFiles que los directorios de las aplicaciones borradas han sido eliminados.
f.    Eliminar funciones y aplicaciones Windows adicionales que no sean necesarias
g.    Eliminar datos y ficheros de usuarios así como configuraciones que no sean necesarias.
h.    Eliminar cualquier directiva no utilizable
i.    Comprobar la configuración local y las directivas en busca de directivas que puedan ser eliminadas.

3.    Optimización del Desktop.

a.    Configurar el fichero de paginación. Este generalmente esta en 300-500MB. El tamaño inicial y final del fichero de paginación debe ser el mismo.
b.    Revisar el registro de Windows e identificar configuraciones que no sean necesarias.
c.    En Windows XP

i.    Instalar las herramientas de Paravirtualización y reiniciar la máquina.
ii.    Instalar el software necesario en la máquina. Citrix recomienda minimizar al máximo el número de aplicaciones instaladas en la imagen base, reduciendo la complejidad de administración de la misma y simplificando el número de imágenes que deben ser mantenidas.
iii.    Realizar el Log in con un administrador del dominio con derechos administrativos y realizar las instalaciones necesarias.

d.    En Windows Vista

i.    Log in con un administrador del dominio e instalar el VDA – reiniciar la máquina.
ii.    Instalar las herramientas de Paravirtualización y reiniciar nuevamente.
iii.    Instalar cualquier software necesario que sea necesario incluir en el disco. Citrix recomienda minimizar al máximo el número de aplicaciones instaladas en la imagen base, reduciendo la complejidad de administración de la misma y simplificando el número de imágenes que deben ser mantenidas.

4.    Test de Conectividad

a.    Testear la conexión VDA utilizando Web Interface y verificar que se puede acceder al desktop
b.    Deshabilitar el firewall de Windows es necesario para la correcta comunicación con el DDC. Si el firewall no puede ser desactivado por razones de seguridad, asegurarse de añadir las excepeciones necesarias para una correcta comunicación entre el DDC y las VMs
c.    Verificar la conectividad a través de conexiones Proxy. Si disponemos de un servidor proxy, este debe ser configurado para permitir el tráfico entre la máquina cliente con el VDA.

5.    Instalar los clientes ICA

a.    Cuando es necesario tener acceso a Xenapp desde el Desktop, instalar el Citrix XenApp Pluggin (Program Neighborhood Agent) y configurar para que comunique con los servicios de XenApp.
b.    Si se utiliza el stream de aplicaciones, instalar el XenApp Plugin for Streamed Apps y reiniciar el Workstation. Configurar todas las aplicaciones para pre-cachear y ejecutar.

6.    Optimizar PVS

a.    Deshabilitar TCP Checksum y los Large Send Offload como se indica en el punto de Provisioning Services.
b.    Re-testear la conexión VDA.

ESCALABILIDAD

Cuando consideramos la escalabilidad para un entorno de XenDesktop, cabe tener en cuenta la escalabilidad de cada uno de sus componentes, en lugar de ver únicamente la escalabilidad del entorno globalmente.  Será necesario tener presente la escalabilidad del DDC, de PVS y del hypervisor utilizado. Este punto explica el impacto que puede tener en los dos puntos iniciales DDC y PVS.

Desktop Delivery Controller Impact

El punto más crítico en el DDC ocurre durante los tiempos de conexión al entorno, cuando los usuarios realizan conexiones simultaneas durante primera hora de la mañana o después de comer. Estos dos, son las franjas a tener más controladas ya que es cuando se inician mayor número de inicios de sesión concurrentes.  La mayor parte de carga del servidor es debida al servicio IMA, el DDC y el Pool Management Services.  Al finalizar la conexión Ica se conecta con el Escritorio Virtual y el DDC únicamente se dedica a recibir las notificaciones de estado de los desktops virtuales. Estas són ridículas comparadas con la carga durante el inicio de sesión.

Al considerar grandes entornos de despliegue, es importante tener en cuenta que hay varios servicios que solo se ejecutan en el DDC y que todas las solicitudes de conexión de usuarios pasan por el Master. Como resultado, el Master no es escalable por adicción de servidores y solo es ampliable mediante la actualización del servidor a uno más potente.  Sin embargo, una granja de XenDesktop es escalable para Failover añadiendo más DCs dónde se controla el XDA de conexiones-activas y se inscriben o registran las VMs. El Zone Master puede convertirse en un cuello de botella cuando los grupos de escritorios crecen, por lo que se recomienda limitar el número de escritorios por grupo a 3000.

El factor mas común que limita la escalabilidad de un servidor simple DDC es el poder de procesamiento. Para maximizar el número de conexiones simultaneas en un DDC, citrix recomienda dedicar servidores con el máximo poder de procesamiento (sockets Duales o procesadores Quad Cores) para que sirvan como Zone Masters en un entorno XenDesktop.

Provisioning Servers Impact

 El número de Target Devices que puede soportar un servidor de PVS depende del tamaño del vDisk, de a solución dónde es almacenado el vDisk, de la localización del fichero de cache y de la carga de trabajo que generan los usuarios.

El cuello de botella mas común que afecta a la escalabilidad un servidor de PVS es la I/O de red del servidor de PVS, el I/O del almacenamiento del vDisk y la ubicación del archivo cache.

El servicio de Streaming del servidor de PVS administra el tráfico. Si el vDisk está alojado en un recurso compartido de red, entonces PVS recupera la imagen y la aprovisiona a los dispositivos finales (Target Devices). Mientras el número de dispositivos finales crece, las NICs del Servidor de PVS incrementan su carga y se saturan con picos a intervalos. Configurar las tarjetas para que trabajen en equipo o Teaming ayuda y aumenta el número de dispositivos finales utilizables antes de producirse un cuello de botella.

El I/O de la solución de almacenamiento puede convertirse también en un cuello de botella. Cuanto mas rápida sea la solución de almacenamiento mejor será el rendimiento del servidor de PVS, y así se  podrá aumentar el número de dispositivos que un servidor puede soportar sin reducir el rendimiento.

Además la escalabilidad y el rendimiento puede verse alterada también por la ubicación del fichero de cache y del vDisk dentro del sistema de almacenamiento . Si se utiliza el mismo sistema de almacenamiento, citrix recomienda colocar vDisk y escribir los archivos Cache en Luns independientes  dedicados a disminuir y distribuir las cargas para aumentar la velocidad de acceso al vdisk y al cache.

Como se comento, colocar el fichero de Cache en el servidor de PVS reduce la escalabilidad de cada servidor e incrementa los requerimientos por  el uso del procesador, el  I/O de red, y el I/O de disco en el servidor de PVS.

Citrix recomienda a cada organización realizar pruebas específicas de escalabilidad del entorno basada en la infraestructura existente y utilizar casos de éxito para determinar el número de dispositivos finales que pueden ser soportados por un servidor de PVS. Servidores adicionales pueden ser añadidos para distribuir la carga así como proveer de redundancia y alta disponibilidad.

El siguiente documento es una adaptación y traducción, enriquecida con algunos puntos adicionales de las “Best Practices for Citrix XenDesktop with Provisioning Services”.  Todos los puntos tratados son importantes y a tener en cuenta en un despliegue de XenDesktop con PVS.