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

El pasado 12 de julio VMware anunció su nuevo licenciamiento para su producto estrella vSphere 5. En este cambiaban totalmente el concepto anterior donde "podíamos" poner toda la RAM que quisiéramos en nuestro host físico pero con la limitación en cores por CPU.

Con la llegada del Cloud Computing se han dado cuenta que lo que prima es la RAM y no los core por CPU, por lo que cambiaron el licenciamiento limitando la RAM y permitiendo tantos cores por CPU como queramos. Esta limitación por RAM la han llamado vRAM, la cual es la cantidad total disponible en los hosts administrados por vCenter.

El licenciamiento sigue siendo por socket, pero como se ha indicado, ahora se limita en RAM soportada por cada socket licenciado. A continuación se muestra una tabla con las limitaciones que existían en vSphere 4, donde se aplicaba a los cores por CPU:

Y a continuación se muestra el primer licenciamiento propuesto por VMware para vSphere 5:

Comparando las dos tablas se puede observar lo que suponía migrar a vSphere 5, en ocasiones más del doble de lo que costaría con vSphere 4. Esto provocó grandes quejas en la comunidad VMware, partners y clientes, lo que ha hecho que VMware rectifique en algo su licenciamiento aproximándose más a las cantidades económicas de vSphere 4.

Pues bien, ayer 3 de agosto VMware lanzo el nuevo licenciamiento para vSphere 5. En este aumentan hasta el doble la cantidad de RAM en las licencias Enterprise y Enterprise+; y en 8GB más las licencias Essentials, Essentials+ y Standard (la edición Advanced se pierde, pasando a Enterprise).  Se muestra a continuación:

Para más información podéis visitar el siguiente enlace http://blogs.vmware.com/partner/2011/08/vmware-vsphere-5-licensing-and-pricing-update.html Esperemos a hacer de nuevo los cálculos y ver que esta nueva jugada beneficie a todos. Si deseas hacer también esos cálculos puedes usar la siguiente herramienta http://blogs.vmware.com/kbtv/2011/08/more-on-vsphere-5-licensing.html

]]> http://blog.e2h.net/2011/08/04/licenciamiento-definitivo-vmware-vsphere-5/feed/ 2 http://blog.e2h.net/2011/06/28/el-almacenamiento-en-entornos-virtuales-la-capacidad-no-es-la-clave/ http://blog.e2h.net/2011/06/28/el-almacenamiento-en-entornos-virtuales-la-capacidad-no-es-la-clave/#comments Tue, 28 Jun 2011 06:30:04 +0000 José Luis Gómez Ferrer de Couto http://blog.e2h.net/?p=2508 Hola amig@s:

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.

En este nuevo artículo dedicado a VMware y su almacenamiento vamos a conocer una herramienta gratuita de diagnóstico que nos ayudará a detectar: el almacenamiento desaprovechado en una VM y si está desalineada.

Esta herramienta gratuita ha sido creada por el vExpert Ricky El-Qasem, la cual podemos descargarla desde el siguiente enlace http://read.virtualizeplanet.com/?p=366.

Una vez la tengamos descargada su instalación es trivial, con el típico siguiente, siguiente y finalizar. Dejamos pues a un lado su instalación y vamos a ver como utilizarla.

Ejecutamos la aplicación y lo primero que tenemos que hacer es clic sobre VMware Tree e introducir los datos de nuestro host ESX(i) o vCenter.

El siguiente paso es configurar los parámetros de análisis. Hacemos clic en Scan Options y en la ventana que nos aparece tenemos las siguientes opciones:

• vDisk Waste Options. Indicamos a partir de que porcentaje de espacio desaprovechado en disco queremos que nos avise. De forma predeterminada está seleccionado que nos informe si está desaprovechado más del 50% del disco.
• vDisk Alignment Options. Aquí tenemos dos valores, 32K ó 64K. La elección de uno u otro depende de nuestro fabricante de almacenamiento.
• Dentro del apartado anterior disponemos de unos campos para introducir las credenciales. Si lo estamos haciendo contra VMs que pertenecen a un dominio, la mejor opción es usar las credenciales de un usuario del dominio con permisos de administrador.

Una vez completados los datos anteriores hacemos clic en Confirm. Decir que esta herramienta funciona exclusivamente con sistema operativo Windows. Muy importante tener el firewall de Windows deshabilitado, ya que de no ser así la opción de alineación no podrá consultar a través de WMI.

Ahora desplegamos el árbol y podemos seleccionar a nivel de datacenter, host o VM. Una vez elegida la opción deseada podemos hacer clic en las siguientes opciones:

• vDisk Waste. Si superamos el throughput que pusimos de más del 50% libre nos aparecerá un aviso circular rojo con un signo de admiración blanco. En aquellos discos que no esté más del 50% libre no nos aparecerá tal signo.

• vDisk Alignment. A través de WMI va a consultar la configuración de nuestros discos en las VMs Windows (igual que ejecutar msinfo32.exe y ver los datos de storage) y nos mostrará los que se encuentra desalineados y alineados.

Con estos simples pasos hemos visto como utilizar la herramienta. Es importante mantener alineados nuestros volúmenes VMFS y los almacenamientos de las VMs para tener un óptimo rendimiento I/O y así conseguir un buen throughput.

Para conocer más sobre la importancia de la alineación podéis consultar los siguientes documentos y Blogs, que servirán de ayuda para conocer más al respecto y ver como alinear nuestros almacenamientos.

http://www.vmware.com/pdf/esx3_partition_align.pdf - VMware

http://clariionblogs.blogspot.com/2008/03/setting-alignment-offset-on-esx-server.html - Clariion blogs

http://www.yellow-bricks.com/2010/04/08/aligning-your-vms-virtual-harddisks/ - Yellow Bricks

http://blogs.netapp.com/virtualstorageguy/2010/04/raising-awareness-around-the-misalignment-of-data.html - NetApp Virtual Storage Guy

Como nota decir que de forma predeterminada a partir de vCenter 2.0 los datastores formateados desde el cliente de gestión ya están alineado a nivel VMFS. A nivel de sistema operativo a partir de Windows Vista/7/2008 el sistema operativo también se encuentra alineado, pero no en versiones anteriores como NT/2000/XP/2003.

Hoy vamos a ver unos sencillos pasos para migrar una plataforma en 32 bits de VMware ESX(i) 3.x a un nuevo hardware 64 bits con VMware vSphere 4.x.

Vamos a ver diferentes escenarios, pero existen dos aspectos fundamentales que diferencian claramente los métodos a seguir para una migración satisfactoria. Estos dos aspectos a tener en cuenta son: ¿almacenamiento LOCAL o COMPARTIDO?

Antes de ver los posibles escenarios partimos de que VMFS 3.x utilizado por VMware ESX(i) 3.x y VMware vSphere 4.x es accesible en lectura/escritura por ambas versiones. Es decir, VMFS 3.21 y VMFS 3.31 de VMware ESX(i) 3.0 y ESX(i) 3.5 respectivamente es accesible por VMware vSphere 4.x en lectura/escritura; y que de forma viceversa VMFS 3.33 y VMFS 3.46 de VMware vSphere 4.0 y vSphere 4.1 respectivamente es accesible por VMware ESX(i) 3.x en lectura/escritura. Para más información consultar en VMware el KB1005325.

IMPORTANTE: Antes de realizar cualquier tarea de migración resulta vital realizar COPIAS DE SEGURIDAD.

Almacenamiento LOCAL

Se pueden dar dos casos: pasar de un servidor con almacenamiento local a otro (64 bits) también con almacenamiento local, o de un servidor con almacenamiento local a otro con almacenamiento compartido.

• Local a Local: Si no vamos a hacer uso de vCenter podemos realizar la migración fuera de línea usando la opción de exportar VM y posteriormente en el nuevo entorno actualizar primero las VMware Tools y luego el Upgrade Hardware. Por lo contrario, si la migración la queremos hacer en línea hay que usar la herramienta vCenter Converter.Si estamos haciendo uso de vCenter hay que tener en cuenta que la nueva versión tiene como requisito un sistema operativo 64 bits, por lo que habría que realizar una instalación desde cero de vCenter. Si queremos mantener los datos de la infraestructura anterior habrá que hacer un backup de la base de datos e importarla en el nuevo vCenter (si no resulta crítico la pérdida de las gráficas de rendimiento, mejor no realizar exportar/importar). Los pasos posteriores para migrar las VMs son los mismos descritos anteriormente.
• Local a Compartido: aquí se aplican los mismos métodos descritos anteriormente, pero existen otros pasos posibles a realizar. Con almacenamiento compartido iSCSI y usando vCenter 4 se puede realizar con Storage VMotion una migración en línea desde un almacenamiento a otro sin la interrupción del servicio. Si no disponemos de licencias para Storage VMotion es aconsejable realizar estas operaciones con la evaluación de 60 días, la cual permite utilizar todas las características del producto. Esta migración se tiene que realizar desde el host ESX(i) 3.x, ya que es quien ve ambos almacenamientos.El método mostrado no resulta viable para almacenamiento FC, ya que dotar de una HBA al servidor ESX(i) 3.x resulta costoso. Por contra, con iSCSI sólo necesitamos conectividad de red.

Almacenamiento COMPARTIDO

Este es el escenario más rápido y fiable, ya que jugamos con la ventaja de tener almacenamiento compartido que puede ser visto tanto por la infraestructura 3.x como por la 4.x.

Para realizar este tipo de migración es necesario que el almacenamiento compartido sea visible por ambas infraestructuras y además disponer de espacio libre para alojar las VMs migradas.

Lo pasos a realizar son los siguientes:

1. Instalar vCenter 4 en la nueva infraestructura 64 bits.
2. Agregar los hosts ESX(i) 3.x y vSphere 4.x a vCenter. Si tenemos los hosts ESX(i) 3.x registrados en un vCenter 2.x habrá que desregistrarlos previamente.
3. Formatear el almacenamiento libre desde vSphere 4.x.
4. Con Storage VMotion migrar las VMs desde el almacenamiento antiguo al nuevo.
5. Una vez migradas de almacenamiento, con vMotion migrar la ejecución desde ESX(i) 3.x a vSphere 4.x
6. Actualizar las VMware Tools de las VMs (cuando pida reiniciar decir NO y apagar la VM).
7. Actualizar el hardware de la VM y arrancar.
8. Desregistrar los hosts ESX(i) 3.x

Con los pasos descritos no deberían presentarse inconveniente alguno durante la migración, pero como hemos advertido anteriormente, importante antes de la migración realizar COPIAS DE SEGURIDAD.