VMware View 5: Implementando escritorios virtuales

Hola a todos!
En el ultimo VMworld efectuado en Las Vegas, se realizó el lanzamiento oficial de VMware View 5.  A continuación hablaremos un poco más de esta nueva versión y del proceso de instalación y configuración.

Anteriormente publiqué un post con las mejoras de View 5 respecto a sus antecesores, donde destacan mejoras en el protocolo PCoIP, uso de aplicaciones en 3D, y View Persona Management, que permite el uso y administración de perfiles moviles sobre escritorios virtuales.  Sobre este ultimo punto entraremos más en detalle en esta serie de articulos.

Introducción
VMware View es la solución de virtualización de escritorios de VMware, que nos permite simplificar la gestión de los escritorios, mientras se aumenta la seguridad y control sobre la plataforma.

VMware View permite entregar una experiencia personalizada y de calidad a los usuarios finales, permitiendo una mayor disponibilidad y agilidad en los servicios de escritorio, respecto a los PCs tradicionales, reduciendo ademas el TCO en hasta un 50%.

Experiencia de usuario final
A diferencia de los PCs tradicionales, los escritorios View no están atados a los computadores fisicos, sino que residen en una nube y los usuarios finales pueden acceder a sus escritorios virtuales cuando lo necesiten, y desde cualquier ubicación.  Gracias al protocolo PCoIP, VMware View entrega una experiencia de usuario final mas rica, flexible y adaptable, en diferentes condiciones de conectividad.

Control y gestión
VMware View permite aumentar el control sobre los escritorios, aplicaciones y datos, entregandolos y gestionandolos como servicios centralizados.
A traves de una unica consola administrativa, se puede contar con visibilidad sobre todos los servicios de escritorio, mientras se facilitan las tareas al area TI de provisionar escritorios, asi como la gestión de parches y actualizaciones.

Características de VMware View
Entre las caracteristicas de VMware View podemos nombrar:

• Uso de múltiples monitores
• Imprimir desde un escritorio virtual a cualquier impresora local o en red que se encuentre definida en el dispositivo cliente.
• Acceso a dispositivos USB y otros perifericos que se encuentren conectado en el dispositivo Thin Client.
• Uso de VMware HA para entregar alta disponibilidad a los escritorios virtuales.
• Integración con Active Directory para administrar los escritorios virtuales y politicas
• Uso de template o imagen maestra para crear y provisionar grupos de escritorios virtuales rapidamente (View Composer)
• Administración de perfiles móviles utilizando View Persona Management
• Acceso desde distintas ubicaciones, incluyendo conexiones a través de la WAN sin necesidad de VPN.

Componentes de VMware View

Los componentes de la arquitectura de VMware View los he detallado anteriormente al hablar de View 4.5, y en esta nueva versión los componentes son basicamente los mismos.

• Dispositivos Cliente
• View Connection Server
• View Client
• View Agent
• View Administrator
• View Composer
• View Transfer Server
• View Securitu Server

Protocolos de conexión remota


VMware View con PCoIP
PCoIP provee una experiencia optimizada para la implementación de un ambiente de escritorio completo, incluyendo aplicaciones, imagenes, audio y video para un amplio rango de usuarios en la LAN o a traves de la WAN. PCoIP puede compensar un aumento en la latencia o en la reducción del ancho de banda para asegurar que los usuarios finales pueden permanecer productivos sin importar de las conficiones de red.

Microsoft RDP
Microsoft Remote Desktop Connection (RDC) utiliza RDP para transmitir datos. RDP es un protocolo multicanal que permite a los usuarios conectarse remotamente a un computador.

Software HP RGS
En View 5.0 el soporte para HP RGS ha sido removido


Requisitos
View Connection Server
Para la instalación de View Connection Server se debe contar con un servidor de 32 o 64 bits dedicado, ya sea fisico o virtual que cumpla los siguientes requerimientos (estos aplican también para las instancias de replica o servidores de seguridad):

• Procesador Pentium IV o superior. Se recomienda un servidor con 4 CPUs.
• Conexión a red 10/100Mbps. Se recomienda 1Gbps.
• 2GB de memoria RAM o superior (4GB para Windows 2008). Se debe contar con al menos 10GB de RAM en implementaciones de 50 o más escritorios virtuales.
• Windows Server 2003 R2 32-bits y 2008 R2 64-bits
• VMware vSphere 4.0 U3 o superior
• VMware vSphere 4.1 U1 o superior
• VMware vSphere 5.0 o superior

Nota: No usar redes WAN para conectar instancias replicadas de View Connection Server

View Composer
View Composer 2.7 se instala solo sobre sistemas operativos de 64 bits. View Composer debe ser instalado en el mismo servidor (fisico o virtual) donde se encuentre instalado vCenter Server.

• VMware vSphere 4.0 U3 o superior
• VMware vSphere 4.1 U1 o superior
• VMware vSphere 5.0 o superior
• Windows Server 2008 R2 
• Una instancia de SQL Server u Oracle para los datos de Composer. De ser posible utilizar el mismo servidor de base de datos utilizado por vCenter.

View Agent
A continuación un detalle de los sistemas operativos soportados para View Agent:

• Windows 7 32 y 64 bits
• Windows Vista SP1/SP2 32-bits
• Windows XP SP3 32-bits
• Windows Server 2008 Terminal Server 64-bits
• Windows Server 2008 R2 Terminal Server 64-bits
• Windows Server 2003 Terminal Server 32-bits
• Windows Server 2003 R2 Terminal Server 32-bits
• Nota: Si se utilizará Windows 7 como escritorio virtual, el host que lo hospede debe ser ESX 4.0 U2 o superior o ESXi 4.1 o superior.

View Client
A continuación un detalle de los sistemas operativos soportados para View Client:

• Windows 7 32 y 64 bits
• Windows Vista SP1/SP2 32-bits
• Windows XP SP3 32-bits

Instalación y Configuración de VMware View

Habiendonos introducido a VMware View 5.0 y conociendo sus requerimientos, a continuación detallaremos el proceso de Instalación y Configuración de VMware View:

• Preparación de Active Directory
• Instalación de VMware View Connection Server 5.0
• Instalación de VMware View Composer 2.7
• Configuración Inicial
• Creando y Optimizando los Escritorios Virtuales
• Creación de un Pool Manual de escritorios virtuales.
• Creación de un Pool automatico de escritorios virtuales.
• View Persona Management

Para una documentación más detallada del proceso y que cubra todos los escenarios, pueden revisar la documentación oficial de VMware:

• Instalación de VMware View 5.0
• Administración de VMware View 5.0
• Arquitectura de VMware View 5.0

Read More

vSphere: Qué es y cómo funciona Beacon Probing

Hola a todos!

En esta ocasión hablaremos sobre los mecanimos de detección de fallas en la red, en una plataforma VMware, especificamente de Beacon Probing.

Beacon Probing es un mecanismo de deteccion de fallas en la red que envia y escucha Sondas o paquetes Beacon (Beacon Probes) en todas las NICs configuradas en Team (NIC Teaming), y utiliza esta información junto con el estado del link para identificar fallas en algún enlace uplink.  Beacon Probing detecta fallas como desconexión de cables y fallas de energia de los switches fisicos contiguos, asi como tambien en los switches downstream (switches que no estan conectados directamente al host).

Como funciona Beacon Probing?

Periodicamene un host ESX/ESXi envia broadcast de paquetes beacon desde todos los uplinks en un team.  La idea es que el Switch fisico reenvie todos los paquees a los otros puertos en el mismo dominio broadcast.  Debido a lo anterior, se espera que los miembros de un Team vean los paquetes Beacon enviados por otros miembros del Team.  Si un uplink no recibe correctamente 3 paquetes beacon consecutivos, dicho uplink es marcado como fallido.  Esta falla puede encontrarse en el link al Switch fisico al que se conecta el host, o en un link downstream.

El uso de Beacon Probing es util en Teams con 3 o más uplinks.  Cuando hay solo 2 NICs en un team configurado con Beacon Probing y uno de ellos pierde conectividad, no queda claro cual NIC debe ser sacada de servicio, debido a que ninguna de ellas recibe los paquetes beacon generados por los uplinks del Team.

Usando al menos 3 NICs en un Team es posible detectar hasta N-2 fallas, donde N es el numero de NICs en el Team antes de alcanzar una situación de deteccion ambigua de fallas.  Por ejemplo:

• Si un Team cuenta con 4 NICs, utilizando la formula de N-2, es posible detectar fallas de hasta 2 NICs en el Team, antes de que Beacon Probin deje de ser efectivo y entregue resultados ambiguos.

Se recomienda habilitar Beacon Probing en los siguientes casos:

• El Team cuenta con 3 o más NICs.
• Cuando las fallas de link downstream (links que no se conectan directamente al host) pueden impactar la disponibilidad.
• Cuando Link State Tracking no se encuentra disponible en el Switch Fisico.

Espero que les sea de utilidad

Read More

vSphere 5: Soporte Virtual Numa (vNUMA)

En un post anterior describimos la arquitectura NUMA y como esta se integraba con los mecanismos de administración de recursos en vSphere 4.x.

En vSphere 5, si bien la arquitectura base no sufrió cambios, se introduce el soporte para exponer la topologia NUMA virtual a los sistemas operativos de las máquinas virtuales, lo cual permite mejorar la performance facilitando el uso de las optimizaciones NUMA tanto por el sistema operativo, como por las aplicaciones "NUMA-aware" en las MVs.

La topologia NUMA virtual o vNUMA se encuentra disponible en MVs que utilizan hardware virtual version 8, y está habilitado por defecto cuando el numero de vCPU es mayor a 8.  Esto ultimo es posible de cambiar modificando el parametro avanzado "numa.vcpu.min".

vNUMA permite que los sistemas operativos y aplicaciones dentro de una MV puedan tomar decisiones NUMA-aware más inteligentes respecto a la asignación de memoria fisica y procesos/threads.

El soporte vNUMA es de mucha utlidad en grandes MVs, las cuales necesariamente utilizan más de un nodo NUMA en un host.
Esto permite un aumento significativo en la performance para aplicaciones intensivas en el uso de memoria, permitiendo alcanzar una performance muy cercana a la performance nativa en el mundo fisico.

Mayor información la pueden obtener en los siguientes links:

VSP2884 - What's New in Performance for VMware vSphere 5.0 (VMworld)
vSphere Resource Management Guide

Read More

vSphere 5: Cambios en el calculo de Slot Size.

En un post anterior detallamos como se realiza el calculo del Slot Size, y su relación con el funcionamiento de HA en vSphere 4.1, cuando esté ultimo se encuentra configurado con el Control de Admision habilitado, utilizando la politica de tolerancia a fallas de 1 o más hosts.

Con el lanzamiento de vSphere 5, el calculo de Slot Size sufrió un pequeño pero importante cambio, lo cual permite un radio de consolidación aun mayor.

En esta ocasión no explicaremos todo el proceso de calculo del Slot Size, y los Slots disponibles en un cluster HA, ya que lo explicamos previamente en el post ya mencionado y el proceso es basicamente el mismo.  A continuación detallaremos el cambio realizado en vSphere 5, y en como afecta al funcionamiento de HA.

Slot Size

Para calcular el Slot Size, VMware realiza los siguientes cálculos:

• HA calcula el Slot Size de la CPU, según la mayor reserva de CPU entre todas las máquinas virtuales del Cluster.  Si no hay reservas, el valor por defecto para el Slot Size es de 32Mhz.
• HA calcula el Slot Size de la Memoria con la mayor reserva de memoria entre todas las maquinas virtuales del Cluster ,más el valor de "Memory Overhead".  Si no hay reservas, se utiliza el valor de "Memory Overhead".

He aquí donde observamos el cambio, pequeño pero muy importante, que se ha introducido para HA en vSphere 5, ya que ahora el Slot Size por defecto para la CPU, es ahora de solo 32 Mhz, mientras que en vSphere 4.1 era de 256 Mhz.  Esto quiere decir que si no se utilizan reservas de CPU en un clúster dado, el Slot Size será solo de 32 Mhz, permitiendo el encendido de más Máquinas Virtuales en un clúster HA, mientras se respeta la política de Control de Admision.

El resto del proceso del calculo de Slots disponibles en Cluster HA es el mismo utilizado en vSphere 4.1 y que detallamos en el siguiente post:

http://www.patriciocerda.com/2011/04/vmware-ha-y-slot-size.html

Para mayores detalles sobre como funciona HA en vSphere 5, pueden leer el siguiente post publicado recientemente en este blog:

http://www.patriciocerda.com/2011/09/vsphere-5-como-funciona-ha-y.html

La guia oficial de Disponibilidad en vSphere 5 la pueden encontrar en el siguiente link:

http://pubs.vmware.com/vsphere-50/topic/com.vmware.ICbase/PDF/vsphere-esxi-vcenter-server-50-availability-guide.pdf

Espero les sea de utilidad.

Read More

vSphere 5: Eliminar warning en ESXi por Shell y SSH habilitado

Hola a todos!

Solo un pequeño tip sobre como eliminar el warning que se genera en los hosts ESXi al momento de habilitar SSH remoto, o la Shell local en dichos hosts.  Este warning es mostrado como una medida de seguridad proactiva para asegurar que los administradores de la plataforma virtual son conscientes de que el acceso remoto ha sido habilitado para dicho host.


Importante: Se debe destacar que como buena practica de seguridad, tanto SSH como la Shell local NO debieran estar habilitados en los hosts ESXi.

Al momento de habilitar SSH en un host ESXi, se muestra el siguiente warning a traves de vSphere Client:

Para poder eliminar este warning, debemos seleccionar el host ESXi en el inventario, dirigirnos a la sección "Configuration" y seleccionar "Advanced Settings" en el menú "Software"

En la ventana que se abre a continuación, seleccionar en el panel izquierdo la opción UserVars.  Una vez seleccionado, buscar el parametro UserVars.SupressShellWarning, el cual por defecto se encuentra con el valor 0.  Para eliminar el warning, el parametro debe ser modificado dejandolo con el valor 1.

Presionamos OK para guardar los cambios, con lo cual el warning desaparece de forma inmediata, sin necesidad de reiniciar el host ESXi.

Nota: Estas instrucciones aplican solo en vSphere 5.  En vSphere 4.x, la unica manera de quitar este warning es deshabilitando SSH.

Espero les haya sido de utilidad.  Saludos a todos!!!

Read More

Nuevo sponsor del Blog - Veeam!

Hola a todos!

Solo una pequeña nota para contarles de que a partir de esta semana, Veeam Software se ha transformado en el primer sponsor de este humilde Blog.

Ya he publicado algunos artículos sobre los productos de Veeam, y espero seguirles informando de las novedades que vayan apareciendo acerca de sus soluciones.

Gracias a todos por seguir este Blog, y a Veeam por el apoyo.

Read More

Como customizar mensajes en vCenter 4.1

1.- Los mensajes de eventos que maneja vCenter, se encuentran ubicados en el servidor de vCenter dentro de "Program Files\VMware\Infrastructure\VirtualCenter Server\locale".

2.- Dentro de esa carpeta encontraremos varias subcarpetas con nombres como de, en, fr, ja, etc… que hacen referencia al idioma. Por defecto la instalación en inglés utilizará los mensajes contenidos en “en_US”, carpeta que no siempre existe, por lo tanto sacamos una copia a la carpeta en para pegarla en la misma ubicación bajo el nombre “en_US”.

3.- Abrimos la carpeta en_US (o la correspondiente al idioma que ha sido instalado vCenter) y abrimos los archivos con Notepad o nuestro editor de texto preferido.

4.- Modificamos el mensaje del evento, guardamos, reiniciamos el servicio de vCenter y listo..!! nuestro mensaje ha quedado customizado según nuestra necesidad.

Read More

vSphere: Importancia de la alineación de particiones.

El alineamiento de las particiones es un problema conocido en los sistemas de archivos, tanto en servidores fisicos como virtuales. El correcto alineamiento de las particiones en las MVs y de los datastores VMFS, evita la degradación en la performance de I/O, por lo que se considera una buena practica.

Muchos creen que este problema se limita solo al mundo físico, debido a que las VMs no utilizan arreglos RAID sino uno o más discos VMDK, por lo que no requieren de alineamiento de particiones. GRAN ERROR!  A pesar de que las MV no utilicen RAID dentro de su sistema operativo, los archivos VMDK utilizados por las MVs se encuentran montados en LUNs, las cuales SI utilizan RAID.  Recordar que las LUNs en una SAN están formadas por arreglos de discos en RAID.

Importancia del alineamiento de discos en VMware.
Muchos analisis de performance han destacado el hecho de que el apropiado alineamiento de discos para particiones VMFS y sistemas de archivos NTFS mejoran la performance de I/O, asi como reduce la latencia y aumenta el throughput.

VMware reporta que el throughput puede aumentar hasta un 62% (con un promedio de 12%), mientras que la latencia se reduce hasta un 33% (con un promedio de 10%), al contar con un apropiado alineamiento e discos.

En un ambiente SAN, la unidad de hardware más pequeña usada por un Storage SAN para construir una LUN a partir de multiples discos fisicos, es llamado chunk o stripe.  Para optimizar el I/O, los chunks son usualmente mucho más grande que los sectores.  De este modo, una petición de I/O SCSI que intenta leer un sector, en realidad lee un chunk.

Como segunda capa se encuentra el sistema de archivos para máquinas virtuales, o VMFS, el cual está formado de bloques.

Finalmente, la tercera capa es el archivo de discos de la MV (VMDK), y está formado de clusters, debido a que se encuentra formateado con el sistema de archivos NTFS (para el caso de SO Microsoft).

La siguiente figura que tomo prestada desde un articulo de VMware, muestra que una estructura de almacenamiento desalineada puede causar muchas operaciones de I/O adicionales, cuando solo un cluster es leido por el sistema operativo de la MV.

Como la figura muestra, al intentar leer un cluster de disco se podría provocar lecturas en hasta 3 chunks en la LUN de la SAN.

Del mismo modo, la siguiente figura muestra las mejoras en un volumen NTFS alineado apropiadamente con el volumen VMFS y la LUN de la SAN.

Como la figura muestra, al intentar leer un cluster de disco se realizan lecturas en solo 1 chunk en la LUN de la SAN.

Alineamiento de VMFS
Los datastores VMFS estarán siempre alineados si ellos son creados utilizando el vSphere Client.  Por lo anterior, se recomienda evitar el uso del comando vmkfstools para crear un Datastore.

Una partición VMFS alineada utiliza un offset de 128 (64KB) como punto de inicio.  Si se utiliza vmkfstools, la partición utiliza un offset de 63 (por defecto) como punto de inicio, por lo que queda desalineada.

Para verificar la alineación de VMFS, utilizar el comando "fdisk -lu" y asegurar de que el offset efectivamente es 128.

Si desean crear una particion alineada utilizando vmkfstools, o se desea alinear una partición VMFS desalineada, utilizar los pasos detallados en el siguiente LINK, en la sección "Align VMFS to LUN".


Alineamiento de MV
En el sistema de archivos NTFS, la unidad de datos más pequeña es una unidad de asignación o clúster.  Para los discos de datos es posible cambiar el tamaño del clúster, sin embargo, para el volumen de sistema el tamaño del cluster debe ser de 4KB para que el sistema bootee apropiadamente.

Sistemas operativos en arquitecturas x86 crean particiones con un MBR (master boot record) que consume 63 sectores de offset.  Esto se debe al antiguo codigo de las BIOS de los PCs que usaban cilindros, cabezales y sectores para el direccionamiento, en vez de utilizar LBA (logical block addressing).

Como saber si lo discos de la MV están desalineados?  
Recordar en primer lugar que los sistemas x86 utilizan los primeros 63 sectores para el MBR.  Usualmente hay 512 bytes por sector, por lo que 63 sectores corresponde a 32.256 bytes.

Si consideramos que el volumen de sistema en Windows está formateado con un tamaño de cluster de 4KB (4096 bytes) podemos determinar que la partición no se encuentra correctamente alineada, dividiendo los 32.236 bytes contenidos en los 63 sectores, por los 4096 bytes del tamaño del cluster, lo cual NO nos entrega un valor entero (7,875).  La partición no se encontrará alineada con el limite de 4KB a menos que el punto de inicio sea divisible en forma exacta por 4096.

Para alinear la partición, se debiera utilizar un offset de 64KB (65.536 bytes) como punto de inicio, lo cual al dividirlo por el tamaño del cluster (4096 bytes), nos da un valor entero indicando que la partición se encuentra alineada.  Este offset de 64KB coincide además con el offset utilizado en las particiones VMFS al crearlas utilizando el cliente vSphere.

A pesar de que  Windows escribe datos en el disco en clusters de 4KB, Windows XP, 2000 y 2003, en forma incorrecta, comienzan a escribir datos a partir del sector 63 debido a la arquitectura de la MBR (Master Boot Record).  Esto significa, que al momento de escribir datos, parte de estos son escritos en un bloque del datastore VMFS, y los restantes  son escritos en el siguiente bloque.  Esto implica que en cada operación de lectura y escritura, se deben acceder a dos bloques en vez de solo uno, afectando fuertemente la performance.  Esto afecta a cualquier volumen creado en dichos sistemas operativos, a menos que se configure adecuadamente con diskpart.

Se debe destacar que en sistemas operativos Windows Server 2008 y superior, las particiones se encuentran alineadas correctamente por defecto, lo cual no ocurre en versiones anteriores como Windows Server 2003.

En Windows 2008 se utiliza un offset de 1024KB como punto de inicio de una partición de 4GB a 2TB.  Para discos más pequeños, el offset utilizado es de 64KB.  Con esto podemos estar seguros que una partición en Windows 2008 siempre estará alineada. (LINK)

Antes de Windows 2008, las particiones NTFS necesitaban ser alineadas manualmente utilizando la utilidad diskpart.  Aunque el procedimiento es simple, el alineamiento debe ser hecho al momento de crear la partición, antes de que esta sea formateada.  Al intentar ajustar la alineación de particiones posteriormente, toda la data existente en el disco será destruida.

Para sistemas operativos que no se encuentran alineados por defecto, se recomienda trabajar con un Template de una MV cuyas particiones hayan sido alineadas previamente, lo cual permite ahorrar tiempo de implementación de nuevas MVs.

Se debe destacar que alinear el volumen de booteo dentro de una MV, no es recomendado ni requerido.  Esto se debe a que en general, las aplicaciones que tienen un uso de I/O intensivo, son ubicadas en un disco dedicado para esos datos, y no en el disco de booteo, por lo que solo se requiere alinear los discos de datos.

Recomendaciones
Se recomienda alinear los discos de las MVs en las siguientes circunstancias:

• Al usar Templates de MVs.  Las particiones de Datos debieran estar siempre alineadas
• Particiones de MVs que tengan un uso intensivo de I/O como FileServers, Bases de Datos, o almacenes de Exchange.

Del mismo modo, no se recomienda alinear los discos en las siguientes circunstancias:

• Discos de sistema (boot) de una MV, a menos que haya una buena razón para hacerlo.
• Alinear todas las MV solo por hacerlo.  Se recomienda analizar si existirá una real mejora en la performance luego de alinear los discos, de lo contrario, puede que el esfuerzo involucrado en el proceso no valga la pena.

Links de interes

• Un interesante articulo sobre una herramienta para detectar MV desalineadas: http://blog.e2h.net/2011/05/31/alineacion-vmfs-y-maquina-virtual/
• Whitepaper de alineación de particiones en ESX 3 (aun muy util): http://www.vmware.com/pdf/esx3_partition_align.pdf
• Explicación del alineamiento en Windows 2008: http://frankdenneman.nl/2009/05/windows-2008-disk-alignment/
• Interesante articulo de Duncan Epping para alinear los discos virtuales de una VM: http://www.yellow-bricks.com/2010/04/08/aligning-your-vms-virtual-harddisks/
• Best Practices de performance en vSphere 4: http://www.vmware.com/pdf/Perf_Best_Practices_vSphere4.1.pdf
• Articulo de Alineación de Storage en sitio VMware: http://communities.vmware.com/docs/DOC-11458

Read More