lunes, 23 de junio de 2008

Virtualización, Return Of Investment(ROI) y SAN

El hecho de que la Virtualización es una tecnología que tiene un ROI (Retorno de Inversión) alto es algo que generalmente no es muy dificil de hacer ver a los gerentes y directores. En cuanto se ven los ahorros en espacio, consumo, administracion etc, genralmente no es muy dificil tenerlos a favor. ("La virtualizacion es un virus, si inoculas una pequeña porción en una empresa, se expandirá hasta llenarlo todo").

Algo más dificultad nos plantea convencer a quienes tienen "los dineros" de que una SAN es algo por lo que merece la pena pagar, que es algo que nos va a dar a la larga una flexibilidad muy importante y que nos ahorrará disgustos y aumentará nuestro rendimiento.

Brad Krick, (manager of technical support configurations en GreenPages), nos provee de ciertos datos muy interesantes que nos permiten comparar las diferentes soluciones que tenemos a la hora de, por ejemplo, reemplazar 10 servidores viejos por nuevos.
Krick asume que "una compañía debe reemplazar 10 servidores viejos y su almacenamiento asociado". El estudio lo lleva a cabo usando unos servidores de ejemplo que son de HP y usando VMware ESX. (No tiene en cuenta el paso a cinta de la informacion , licencias de instalacion o instalacion).
En cuanto a los requeriemientos de almacenamiento supone unos 500 GB de datos de primera linea y otros 500GB de segunda linea(backup en disco).

Estos son los escenarios y su coste:
1.- Reemplazar los 10 servidores fisicos por otros 10 HP ML350, con discos de arranque en mirror(RAID1) y almacenemiento en RAID5.
Coste : 62.100$

2.- Consolidar con VMware los 10 servidores fisicos en 3 servidores con almacenamiento local: Tres HP ML350 (con mas memoria que los anteriores y almacenemiento en local RAID5) con VMware ESX (licencias incluidas).
Coste: 49,300$

3.- Los mismos servidores de Virtualizacion en un Cluster que usa una SAN de 1 TB: Tres HP ML350, con mas memoria que los primeros, discos de arranque, VMware ESX Enterprise y una SAN Hitachi de 1TB.
Coste: 52.730$

A la vista del experimenteo que ha llevado a cabo Krick, vemos que, nos ahorraríamos 12.000$, si usamos la virtualizacion y que, además por unos 3.400$ más que la opcion más barata(la 2), tendremos una SAN.

Es verdad que incrementa costes respecto a la opcion 2, pero (por unos 3.400$) nos deja opciones como redundancia, snapshots, thin provisioning y mejor rendimiento, además de que nos permita operaciones tan utiles como Vmotion, DRS, HA, etc, etc...

Realmente, si hacemos un ejercicio similar(ojo, comparando cosas similares), veremos que es algo que realmente merece la pena.

jueves, 19 de junio de 2008

Slow performance of VMs that use vSMP on ESX using certain hardware

Como reza el título del post VMware ha publicado el dia 11 de Junio un articulo en la Knowledge Base que detalla un problema de rendimiento en VMs que se ejecutan en servidores ESX (3.0.x y 3.5) y que utilizan más de una vSMP y todo ello bajo determinados tipos de hardware (que no concretan por cierto). Todo el articulo es un poco difuminado (Puede ser leído aqui: http://kb.vmware.com/kb/1004901) y nos viene a decir que se puede apreciar un rendimiento pobre (no lo contabilizan) cuando usamos VMs con mas de una vSMP, además este rendimiento pobre también se puede manifestar en el Reinicio de la VM: "Síntoma: Reinicar una VM que tiene mas de un vSMP lleva significativamente más tiempo que si solo tuviera una vSMP, bajo ESX y bajo determinados HW...".

Como veis la explicacion no es muy detallada y para mi bastante confusa. En la explicacion nos comentan que parece que está relacionado con el COW (Copy-On-Write) de las VMs que tiene mas de una vSMP y nos proponen Apagar la maquina y Encenderla en lugar de Reinicarla pues esto hace que la memoria de COW se vacie y se llene.

Nos comentan también que para resolver el problema definitivamente se puede desactivar el Page Sharing (Transparen Page Sharing, TPS) de nuestro servidor ESX(Confguration-Advanced Settings- Set Mem-Mem.ShareScanGHz = 0, Reinica ESX).
El TPS nos proporciona la posibilidad de que se compartan paginas de memoria entre VMs resultando en grandes beneficios sobretodo si solemos tener sistemas operativos iguales en nuestro ESX. El resultado es muy visible cuando se inica una VM o varias a la vez. Por defecto VMware lo activa en nuestros servidores y parece que es el camino que van a seguir en el futuro.
Nos avisan que desactivarlo en todo el servidor puede producir mayor swapping si se hace Overcommitting de la memoria del ESX.
(Un post cojonudo sobre Gestion y Sobresuscripcion de Memoria de J.L. Medina).

Como ya he comentado antes la descripcion del problema es bastante disfusa y confusa (en mi opinión). Si por ejemplo, creo que estoy experimentando problemas de rendimiento en mi entorno de ESX(VI3) ¿Como sé yo si es este tipo de issue o no? Digo, antes de volverme loco intentando ver donde está el problema o cuello de botella, que, por cierto, no es de las cosas más faciles de pillar en VI3. (Espero escribir un post sobre ello...). Supongo que no será facil pero, creo que deberían describir mejor en que condiciones se produce, cuanto merma el rendimiento (%), etc, etc, para ver si nuestros sintomas coinciden con el KB.

Por otra parte el tema de desactivar el TPS para que la cosa vaya mejor me ha recordado a la directiva sched.mem.pshare.enable que es capaz de desctivar el TPS a nivel de VM y no a nivel de ESX como nos recomiendan en el KB. Es muy posible que esto también funcione, en lugar de tener que reinicar todo el ESX despues de cambiar la opcion en Advanced Settings como comentaba más arriba.

Este es uno de los parametros que mi colega Josep Ros comenta en su gran blog como polvos magicos para VMware.

En concreto los parametros que se comentan para aumentar el rendimiento de una VM (en lo que a gestion de memoria se refiere) son:

mainMem.useNamedFile = "FALSE"
Cuando está puesta a TRUE, se crea un fichero de tamaño de la RAM en el propio directorio con un nombre aleatorio.
Cuand se pone a FALSE, en Windows causa que la memoria la lleve el espacio de swap del host y en Linux causa que se cree un fichero en un directorio temporal (el fichero es borrado cuando se apaga la VM).
Se suele poner a FALSE cuando ejecutamos una VM desde un USB o un disco que tenga escrituras lentas.

MemAllowAutoScaleDown = "FALSE"
Permite ajustar automaticamente el tamaño de la memoria. Si esta puesto a TRUE, cuando encendemos una VM automaticamente se ajustará el tamaño de la memoria si el tamaño especificado no está disponible (en caso de sobresuscripcion)

MemTrimRate = "0"
El ESX chequea regularmente memoria virtual no usada y la recupera para sí(para correr mśa VMs o lo que sea). Cuando la VM que ha sido robada pide más memoria, el ESX se la da, epro esto tiene un precio en rendimiento. Si lo ponemos a "0" evitamos que nos coja memoria de dicha VM.

sched.mem.pshare.enable = "FALSE"
Como hemos comentado antes, VMware usa TPS para permitir almacenar como una sola pagina Copy-On-Write las paginas de memoria de las VM que contengan identico contenido. Esto hace que las VMs usen menos memoria pero consume mayores recursos, sobre todo CPU, pero también potencialmente ancho de banda de I/O.
Desactivarlo puede ser interesante en Hosts en los que tengamos memoria de sobra y nos interese que la VM tenga poca latencia de I/O.
(Mas info: http://communities.vmware.com/message/251822)

Conjuntado estas opciones tendremos una VM que escibe su memoria en la swap del propio ESX o en el temp, pero nunca un fichero de X gigas (tanta como RAM tenga la VM) en el propio directorio, además la VM será capaz de adecuar su memoria y no dejará que el ESX le reclame memoria cuando no la use.
Por último, la opcion más importante, no usara TPS, lo cual le dejará sus paginas de memoria dedicadas para sí misma, sin compartir. (Ojo, estas opciones no son recomendadas cuando usamos overcommittement, vamos sobresuscripcion).
Todo esto resultará en un incremento de rendimiento siempre que viene muy bien siempre y cuando sepamos que hemos tocado esto y que no deberemos pasarnos con la sobresuscripcion.

miércoles, 18 de junio de 2008

¿Sustituirá VMware su VMFS?

El CEO(Chief Executive Officer) John Thompson de Symantec ha levantado recientemente durante una entrevista el rumor de que VMware podria estar pensando en sustituir su famoso VMFS.

Si esto se produjese la estrategia de VMware y su relación con los proveedores de storage cambiaría.

Ciertamente que no se si es un bulo. Todo puede ser, quien sabe. Es probable que VMware esté viendo que algo tan antiguo(y a la vez flexible) como es el NFS esté sirviendo mejor para albergar sus VMs que el propio VMFS (con todo lo que les habra costado).

Por otra parte Microsoft apunta a que sus VMs podran ser albergadas en LUNs formateadas con Melio FS, dejando asi la puerta abierta otros Cluster File System. Su razón: que ellos piensan que es mejor que otros se dediquen a diseñar Cluster File Systems y ellos a la Virtualización.
Veremos que ocurre en los proximos tiempos.

VMware-liveCD

Vaya por delante decir que todavía no lo he probado pero este CD tiene muy buena pinta: VMware-liveCD
Ulli Hankeln ha creado una nueva version, que contiene entre otras cosas:
  • Workstation 6.0.2 ripped
  • Converter 3.0.3 cold clone mode
  • ViClient for ESX 3.5.0 u1
  • RemoteCli
  • Virtual Disk Developement Kit
  • ViToolkit for Powershell
Ocupa unos 450 MB y la ultima version MOA 2.3.-011 permite correr ESX 35i en WS 6.5. beta 91182. (Como ya comenté)
Se pueden montar VMFs locales y asignarselos a el ESX35i, puede incluso, una vez iniciado, ejecutar el SO que tengas instalado en el disco duro como una VM!!!

martes, 17 de junio de 2008

Top 10: Herramientas gratuitas para la adminsitración de VMware

Eric Siebert nos muestra esta relación de 10 herramientas gratuitas para la administración de VMware y VI3, la mayoria de ellas son geniales:

1) Putty - http://www.chiark.greenend.org.uk/~sgtatham/putty/
Telnet and SSH client for remotely connecting to the ESX service console.
2) WinSCP - http://winscp.net/eng/download.php and Veeam FastSCP - http://www.veeam.com/vmware-esx-fastscp.html
SCP clients for browsing ESX server file systems and transferring files to/from ESX hosts.
3) VI3 SnapHunter - http://www.xtravirt.com/index.php?option=com_remository&Itemid=75&func=fileinfo&id=19 and SnapAlert - http://vmprofessional.com/index.php?content=snapalert
Utilities that can report all running snapshots on ESX hosts including name, size and date. Can also automatically email reports and optionally commit snapshots.
4) VI Scripted Backup Utility - http://www.xtravirt.com/index.php?option=com_remository&Itemid=75&func=fileinfo&id=7
A backup utility that is run from the Service Console that provides VMDK level backups of any VM on storage accessible by the host. The script can be targeted at any ESX server or VC server, and if pointed at a VC server is DRS aware.
5) MCS StorageView - http://www.mightycare.de/downloads/task,cat_view/gid,16/
A utility that displays all the logical partitions, operating system, capacity, free space and percent free of all virtual machines on ESX 3.x or Virtual Center 2.x . It can also display how many gigabytes you can save by decreasing the logical partition to a size the VM really needs.
6) SSH Plug-in - http://akutz.googlecode.com/files/ConsoleClientSetup-0.1.5.msi
A VI client plug-in that integrates an SSH console directly into the client.
7) Storage vMotion Plug-in - http://sourceforge.net/projects/vip-svmotion/
A VI client plug-in that extends the client’s functionality by providing an integrated, graphical tool that can be used to invoke storage VMotion (SVMotion) operations.
8) Vmotion Info - http://www.run-virtual.com/?page_id=155
A program that will collect Vendor, Model, CPU Types and the CPU feature bits from all hosts to check for vMotion compatibility.
9) VMCdConnected - http://www.ntpro.nl/blog/archives/172-Software.html
Scans all Virtual Machines and shows if they have a CD connected to it. After scanning the VM’s you can disconnect all the CD’s with a click of a button.
10) VMware Converter http://www.vmware.com/download/converter/
Performs hot and cold conversions of physical and virtual servers to virtual machines. Also converts image formats.

lunes, 16 de junio de 2008

VMware Virtual Desktop Manager 2.1 Reviewers Guide

Simplemente enlazar este magnifico documento que facilita la comprension de VMware Virtual Desktop Manager 2.1. Es una guia detallada paso a paso de la installation y configuration de VMware VDM 2.1 consolidando la informacion en un unico documento. Lo cual facilita el aprendizaje.

Indice:
  • VMware VDM 2.1 Overview
  • VMware VDM 2.1 Key Features and Components
  • VMware VDM 2.1 Requirements & Prerequisites
  • VMware VDM Agent, Client and Web Access Prerequisites
  • Firewall Modifications
  • How to Create VMware VDM Specific User Groups
  • How to Install the VDM Connection Server Standard Role
  • How to Install the VDM Replica Server Role
  • How to Load Balance VDM Connection Servers
  • How to Install the VDM Security Server Role
  • How to Login to the VDM Administrator Web Site
  • How To License VMware VDM 2.1
  • How to Configure VDM to Communicate with VMware VirtualCenter
  • How To Add a VDM Administrator
  • How To Edit the VDM Global Settings
  • How to Generate a Certificate Signing Request (CSR) Key
  • How to Submit CSR to your Certificate Authority
  • How to Add the New SSL Certificate to VMware VDM
  • How to Create the Base Virtual Machine
  • How To Install Windows XP on a VMware ESX Host
  • How to Install Applications
  • How to Apply Windows XP Patches and Security Updates
  • How to Add Group Policy Loopback Setting to VDM Managed Desktops
  • How to Install the VDM Agent
  • How to Create and Configure Virtual Machine Templates
  • How to Convert the Base Virtual Machine to Template
  • How to Configure VirtualCenter to Deploy Unique Virtual Machines from Templates
  • How to Create a Guest Customization Specification
  • How to Perform Maintenance to Existing Virtual Machine Templates
  • How to Implement VDM Specific Windows Group Policies
  • How to Prepare the Active Directory Environment for VMware Group Policies
  • How to Add the VDM Group Policy ADM Template
  • How to Add a New Individual Desktop
  • How to Assign (Entitle) Users / Groups to a Individual Virtual Desktop
  • How to Create a Persistent Desktop Pool
  • How To Assign (Entitle) Users / Groups to a Persistent Desktop Pool
  • How to Create a Non-Persistent Desktop Pool
  • How To Assign (Entitle) Users / Groups to a Non-Persistent Desktop Pool
  • How to Install the VDM Client on a Windows Client
  • How to Login to VDM 2.1 through the VDM Windows Client
  • How to Login to VDM 2.1 through the Web Access Client

SCSI Reservations y VMware

Cuando nos ponemos a trabajar con almacenamiento compartido mas tarde o mas temprano sale el termino SCSI reservations: Estas reservas sirven para asegurar el acceso exclusivo a recursos de disco cuando éstos recursos son accedidos por multiples hosts. Es algo que suele salir a la luz con VMware VMFS, Microsoft Cluster Server, etc...

Las SCSI Reservations son solamente usadas para operaciones específicas en las cuales se realizan cambios en los metadatos y son necesarias para prevenir que varios hosts puedan escribir concurrentemente evitando de esta manera la corrupción de datos.

Una vez que la operación es completada, la reserva es desbloqueada y las demás operaciones pueden continuar. Es obvio que es importante minimizar el numero concurrente y la duración de las operaciones que necesiten SCSI Reservations debido a que usan un lock exclusivo que al final lo que hace es serializar las operaciones. Cuando se realizan demasiadas reservations a la vez, tendremos errores de I/O porque el host que estaba intentando bloquear el recurso (la LUN, el fichero...) no puede puesto que otro host la habra bloquedao previamente. Cuando un host no puede realizar uns reservation porque hay otro host escribiendo, el primero continuará reintentandolo en intervalos de tiempo aleatorios hasta que lo logre, sin embargo, si se realizan demasidos intentos sin exito, la operacion fallará.

En el entorno de VI3, se vuelve importante el tema de las SCSI Reservations y es un factor a considerar a la hora de hacer el diseño de una arquitectura.
Algunos ejemplos de opreaciones asociadas a VI3 que requieran escrituras en los metadatos son:
  • Crear o borrar un volumen VMFS
  • Expandir un volumen VMFS(para mi usar extents esta prohibido)
  • Encender o Apagar una VM
  • Bloquear o liberar el lock de un archivo
  • Crear o borrar un fichero
  • Crear una plantilla
  • Desplegar una VM de una plantilla
  • Crear una nueva VM
  • Realizar un VMotion
  • Crecimiento de un archivo (Snapshot o un Virtual Disk Thin Provisioned)
  • Hacer Rescans de VMFS, hacer vdf en console...

Lo normal en una infraestructura VI3 es que haya un numero residual de conflictos de SCSI Reservations.(Se ve en /var/log/vmkernel). Esto no nos debe preocupar porque tiene poca influencia en el rendimiento. Lo que si hay que evitar es tener demasiados problemas de SCSI Reservations porque además de afectar el rendimiento, puede hacer que algunas VMs se paren: En el caso de Linux, en muchos kernels, hace que la VM se ponga en Read Only (se soluciona cambiando un valor de timeout de mptisci.h: un RPM) y en el caso de Windows puede parar completamente la maquina.(Se soluciona cambiando un valor de timeout del disco del Registry: HKEY_LOCAL_MACHINE\System\CurrentCOntrolSet\Services\Disk\TimeOutValue)

Para mimimizar estos problemas deberemos intentar que se produzcan las menos operaciones posibles y si es posible que no ocurran simultaneamente en la medida de lo posible, es decir, una best practice seria Verificar que ninguna otra operacion de Reserva de SCSI esta ocurriendo a nivel de archivo, LUN o grupo de LUNs antes de proceder.
Algunas acciones para reducirlas son:
  • Usar un punto central de administracion (Virtual Center) para ver qué operaciones se estan realizando y serializarlas en la medida de lo posible. (También las que se hacen por console)
  • Mirar el estado de los Backups puesto que estos hacen uso de las SCSI Reservations.
  • Limitar el numero de Snapshots activos.(Los snapshots crecen de 16MB en 16MB y cada vez que crecen usan SCSI Reservations)
  • Intentar que las VMs no tengan los discos en más de dos LUNs puesto que una VMotion (operacion de VM) de una VM que tenga un disco en una LUN y otro en otra se dividira en cuatro operaciones a nivel de LUN.
  • Intentar no realizar VMotion simultaneamente de dos VMs que residen en la misma LUN.
  • Intentar solo realizar una migracion cold(VM apagada) por cada LUN en cada momento.
  • Intantar no apagar o encender muchas VMs a la vez.(Esto es más por rendimiento que por SCSI reservatiosn pues solo dura 7 microsegundos el lock de reinicio)
  • Limitar las creaciones y desplieges a una VM por LUN en cada momento.
  • Usar un host en concreto para realizar despliegues siempre. De esta forma es facil limitar la creacion de templates, importaciones, despliegues...
  • Usar un tamaño de LUN adecuado (<600gb)
  • Usar solo un FileSystem en cada LUN
  • No correr scripts que afecten a las LUNs (Backup, permisos) desde varior ESX a la vez y sobre las mismas LUNs.
Estas son algunas acciones para limitar dichas operaciones. Lo primero de todo es ver en nuestros logs si hay una buena cantidad de SCSI Reservations y ver si tenemos problemas de rendimiento. Posteriormente podemos aplicar alguna o todas de las recomendaciones anteriores.

Adjunto una Tabla en la que se ve el numero de operaciones por LUN que se podrian realizar corriendo un determinado riesgo:

jueves, 12 de junio de 2008

Pensamiento: Virtualizacion del I/O. InfiniBand y 10Gbit Ethernet

La Virtualizacion del I/O es una de las nuevas formas de virtualización, junto con la Virtualizacion de Aplicaciones o la Virtualizacion de Servicios, que están emergiendo de la meteorica expansion que vive la Virtualización de Servidores.

Por el momento es un mercado muy nuevo en el que hay muy pocas experiencias en escenarios del mundo real. A día de hoy, hay unas pocas compañías que comercialicen una solución verdadera de Virtualización del I/O proporcionando servicios completos de virtualizacion del IO, a saber: 3Leaf Systems, Xsigo Systems (dos compañias muy jovenes), Cisco Systems y Brocade (con sus standards).
(Alguna más habra salido que no conozca)

¿Que es exactamente la Virtualización del I/O? ¿En que nos puede beneficiar?
La Virtualización del I/O se entinde como una abstraccion de los protocolos de tranporte para realizar conexiones del nivel fisico. En palabras claras, es usar una tecnologia que agrupe todos los canutos infrautilizados (ya sea FC o Ethernet) en menos canutos más utilizados, mezclando los protocolos más tipicos.

Por el momento hay dos tendencias tecnologicas para llevar a cabo esta mision:
Algunos vendedores utilizan la tecnologia de interconexion InfiniBand como la capa de transporte fisico: esto les permite usar la extremadamente baja latencia de InfiniBand para transportar TCP/IP, FC y otros protocolos tradicionales. Como desventaja, hay que mencionar que está tecnología requiere nuevo cableado y algun switch(Aunque puede hacerse brige como luego comentaré). Esto puede ser un impedimento en entornos que han invertido dinero y know-how de arquitecturas Ethernet y FC.

Por el otro lado, otros vendedores como, apuestan por futuros standards como 10Gb Ethernet o extensiones a la 10Gb Ethernet como puede ser Data Center Ethernet (DCE), que es un standard IEEE en progreso que nos proveerá de una gran eficiencia, menor latencia y un comportamiento sin pérdidas y sin errores en una red Ethernet. En el proximo post espero colgar unos resultados sobre 10Gbit Ethernet com VMware.


Como todas las soluciones que existen, nacen para hacer frente a un problema:
Con la llegada de la Virtualización de los Servidores en nuestros CPDs han crecido el numero de puertos usados y la infrastructura de red (ya sea de datos o almacenemiento) se ha complicado.
Hoy en día, cada servidor destinado a la virtualizacion de servidores ocupa como poco 6-8 tomas. Por ejemplo 6 tarjetas ethernet: 2 para Service Console, 2 para VMotion y 2 para trafico de VMs y a las que hay que sumar 2 para iSCSI o 2 para Fiber Channel (o ambas).
En algunas empresas se puede llegar hasta 20 interfaces fisicas ocupadas por servidor, curiosamente estas empresas son las más grandes, donde las politicas son más estrictas respecto a la segmentación de las redes.
Hay que tener en cuenta que, en mi opinión, llegar a un numero mayor de 10 en las interfaces que necesita cada servidor de virtualización no es debido a una limitacion tecnica puesto que existen tecnologías (como las VLAN y VMware Port Groups) que permiten segmentar logicamente las redes mencionadas arriba, realmente se trata de un tema de segmentación mas que de un tema de rendimiento de I/O.

Como beneficios de esta virtualización del IO están mayormente la flexibilidad, la utilización y el aprovisionamiento más rapido. Por ejemplo, el numero de conexiones requeridas por servidor bajarían de 6-8 a 2 si usasemos conectores InfiniBand reduciendo el coste y la complejidad. Simplemente tendremos que fijar un nivel de virtualización (como en los servidores) que hará que nuestros canutos de InfiniBand o 10GbEthernet estén más o menos sobreutilizados.

La mayoría de los defensores de la tecnología 10Gb Ethernet se basan en que es 10 veces más rapida y eso la hace más potente y menos compleja. Como ya he dicho, en mi opinion, no es un tema de rendimiento ni de ancho de banda (que es importante, claro), si no que es un tema de segmentación fisica en la mayoria de los casos. Si lo que nos ofrece esta tecnologia (10Gbit Eth) es simplemente mayor ancho de banda, me veo con el mismo problema en dos años: 6-8 interfaces fisicas de 10Gbps por cada servidor de virtualizacion.
Veremos pues a ver que nos trae el standard Data Center Ethernet (DCE)

InfiniBand, por su parte, me parece que tiene un mayor atractivo para proporcionar un valor añadido que la propia fuerza bruta de 10Gb Ethernet. En primer lugar, está el hecho positivo de que VMware soporta InfiniBand en VI3.5 y el segundo aspecto a tener en cuenta es que InfiniBand se puede ser "bridged" en la arquitectura de I/O del DataCenter existente (Ethernet , FC), proporcionando una solución intermedia que permita usar esta tecnología en el Datacenter sin tener que desmantelar toda nuestra arquitectura.

Este escenario es posible gracias a la existencia de los bridges InfiniBand que conectan la red InfiniBand(IB) con la red normal:


Basicamente, instalando una HBA de InfiniBand en cada servidor podemos crear un numero de "puertos virtuales" que serán mapeados en los switches IB y en los bridges IB para conectarlos a la infrastructura ethernet existente. Este tipo de tecnología también permite usar una mezcla de virtual IB Ethernet adapters y VMware port Groups.

De esta forma se nos proporciona lo que queremos:
  • Algo tranparente y que cumpla con los requerimientos de nuestras politicas internas de segmentacion.
  • Continuar usando los hosts VI3 como si tuvieran sus 6 u 8 interfaces fisicas.
  • Rebajar dichas 6 u 8 interfaces por servidor de virtualización.

Desde un punto de vista puramente teorico, me parace que InfiniBand tiene más que decir que 10Gbit Ethernet, sobre todo en entornos granades de servidores VI3. Habiendo dicho esto, todos sabemos y el tiempo nos ha enseñado que no son siempre las mejores soluciones y las mejores tecnologías las que se imponen en el mercado. asi, pues puede que en unos años haya mayoritariamente InfiniBand, 10Gbit ethernet o una mezcla de ambas. Como ocurre con iSCSI y FC.

miércoles, 11 de junio de 2008

Interesante estudio sobre el aislamiento del rendimiento entre VMs en Xen, VMware y Solaris

En estos días de competencia, se habla mucho de la diferencia de rendimiento entre Hyper-V, Xen y VMware, de hecho la red se ha plagado de documentos ( o docu cuentos) dicendo que el mío es más rapido que el tuyo por esto y por esto etc, etc... Todas estas comparaciones y marketing se han centrado en el overhead que introduce la existencia de un hypervisor comparado con un OS nativo.

Este trabajo, compara la degradación del rendimiento de una VM cuando coexiste con otra VM que tiene un comportamiento errático absorbiendo todos los recursos (CPU, Disco, Memoria...).
En mi opinión este es un dato muy interesante porque cada vez más usamos las VMs en producción y cada vez más se usa en hostings comerciales donde el proveedor deja que varios clientes administren sus servidores en el mismo host fisico y, como es natural, un cliente quiere un determinado nivel de rendimiento independientemente de lo que ocurra con otra VM alojada en dicho host fisico.

Por ello se realizaron la pregunta:
¿Cómo afecta a una VM que otra VM ahogue los recursos cuando ambas comparten el host en las diferentes plataformas de virtualización?
Las platafomas elegidas han sido : VMware Workstation(full virtualization), Xen 3.0(paravirtualization) y Solaris containers(OS virtualization) a dichas plataformas les sometieron a seis tests de estrés: fork bomb, test consume memoria, test CPU intensive, test con 10 threads de IOzone y dos tests que envían y reciben mucho I/O de red.

Las conclusiones generales son que VMware protege la VM que está actuando correctamente (la VM buena) y que a veces muestra una degradacion mayor que otras plataformas sobre la VM mala. Cosa que no es un comportamiento malo para una infraestructura en producción.
Xen, por su parte, protege la VM buena en todos los tests, excepto en el de I/O intensivo de disco en el que penaliza un poco a la VM buena.
En cuanto a Solaris, la VM buena sufre la misma degradación que la mala proporcionado una mala actuación del hypervisor.

Es una pena que no hayan hecho el experimento con VMware ESX y la linea de producto similar en Xen y Solaris, pero viene a demostrar que la "full vrtualization" tiene el comportamiento correcto y provee del mejor aislamiento de las cargas de trabajo normales(VM buena) sobre las cargas de trabajo erráticas.

Herramientas para VMware ESX y Virtual Center

Aqui os dejo tres herramientas para vuestra infraestructura virtual que pueden resultar muy útiles.
Las herramietas son de Mightycare Solutions GmbH y ya fueron sacadas hace tiempo pero creo que merece la pena tenerlas las tres agrupadas y comentadas:

Snapshots Version 1.5
Es un pequeño script con el que eres capaz de chequear si las VMs de un ESX tienen snapshots o no. Se ejecuta con el cron de linux y puede ser corrido diariamente, semanalmente, etc... el script nos devuelve una información detallada de las Vms con snapshots y su almacenamiento.

VMStatus:

VMStatus se conecta a un Virtual Center 2.5 y muestra una lista de las VMs con la siguente información:
  • Virtual Machine Operating System
  • VM Status
  • VM Tools
  • Time Synchronization
Con un doble click en una VM se puede cambiar la configuracón de "time synchronization".

Storageview 1.0.5:
MCS Storageview 1.0.5 muestra las particiones logicas de todas las VMs en un servidor ESX 3.x o Virtual Center 2.x. Nos muestra cuantos GB podemos ahorrarnos decrementando las particiones etc, etc...

viernes, 6 de junio de 2008

Parte III: ¿Como funciona DRS de VMware?

Tips:
  • Primero vigilar el DRS y ver como funciona. Cuando uno se siente seguro y pasado un periodo de aprendizaje, usar Fully Automated para la politica general y para las VMs criticas configurar a nivel de VM la politica de Manual o Partilly Automated.(Vmware DRS, Virtual Machine Options).
  • Usar DRS y Pools de Recursos para un numero de hosts ESX, NO en CADA host ESX.
  • DRS es proactivo, actúa para balancear y no provoca down time. No confundir con VMware HA que es reactivo: actúa cuando se ha caido un host y si tiene down time de las VMs.
  • El maximo numero de hosts en Virtual Center 2.0 es de 16 para DRS y HA
  • Se puede usar Resource Pools anidados y Fixed Reservations para el parent resource pool. Aunque mejor usar shares: se adaptan dinamicamente y los limites estáticos pueden volverse inmanejables.
  • Cuando DRS hace recomendaciones con muchas estrellas: Hadle caso
  • Pon las maquinas que se "hablan" mucho juntas (mismo Host, vSwitch y Portgroup) y usa reglas de afinidad para ello: conseguirar que su red vaya a velocidad de RAM.

Monitorizacion:
La monitorizacion del Cluster se puede realizar a traves del propio Virtual Center.

Un cluster sin ningun color en particular nos indica que todo esta correctamente.
Un cluster de color amarillo(Overcommited or Host down) indica que algun requerimiento de recursos no esta siendo satisfecho por el cluster.(Solucion: aumentar recursos o decrementar reservations)
Un cluster de color rojo nos indica que el cluster esta inconsistente o es invalido
(Cambios en resource pools a traves del VIC directo contra un host en lugar de hacerlo por el VCenter, o capacity failover)


Fallos Comunes:
En general DRS funciona bastante bien sin que nos dé sobresaltos.

Errores de DRS

  • No se puede encender una VM aunque tenga de reservation menos que la capacidad sin reservar del resource pool.
Causa: El host tiene que tener suficiente Aggregate unreserved capacity y Per-core capacity.
Solucion: Establecer en los hosts esta opcion de configuracion Cpu/VMAdmitCheckPerVcpuMin to 0 (OJO: not recommended)


Errores de VMotion:
  • Relacion de cluster entre VMs (MSCS)
  • La VM tiene afinidad a una CPU fisica:
Solución: Quitar la VM del cluster, quitar la afinidad y volver a meter al cluster DRS.
  • La VM tiene conectado el CD-ROM / floppy

Alertas de VMotion:
  • La VM esta configurada a un virtual switch interno pero no esta conectada a él.
  • La VM está configurada para acceder al CD-ROM/floppy pero NO está conectada a él.

Link Parte I:
Parte I: ¿Como funciona DRS de VMware?

Link Parte II:
Parte II: ¿Como funciona DRS de VMware?

Dell: ESXi y Citrix XenServer por 99€

Bueno, esta es una de las noticias que tenia en el tintero:
Dell anunció el 7 de Mayo sus nuevos servidores para la virtualización: PowerEdge R805 (dos zocalos) y R905 (cuatro zócalos). Posteriromente comentan que lo extenderá a otrs servidores, incluso de pedestal.

Los servidores viene con la configuración: AMD Quad-Core, 16 ranuras DIMM, NIC integrada de puertos cuádruple con TOE, hasta 292GB de almacenamiento local y la opción de pre-instalación en una SD de hypervisors por 99€: VMware ESXi y Citrix XenServer Embedded Express (XenServer Dell Express Edition).

Ver dibujo:



Más interesante que la noticia en sí, me parece la ayuda que nos brinda Dell para la compra. En ella se puede ver qué es lo que opina (oficialmente) Dell sobre el estado actual del mundillo de la virtualización:




A ver cuando IBM, HP y SUN se lanzan a ello.

jueves, 5 de junio de 2008

Parte II: ¿Como funciona DRS de VMware?

Arquitectura:

DRS tiene dos niveles de planficador (Scheduling levels):
  • Local: En el host ESX. Determina que procesador ejecutará la VM.
  • Global: En el Cluster. Determina que host ejecutara la VM.

El modulo de DRS se ejecuta en cada host ESX y es evocado por el VCenter Server (vpxd), su evocacion puede ser periodica (cada 5 minutos) o por evento (añadir un host, retirada de uno...)

Como hemos comentado el output del algoritmo de DRS son las recomendaciones. Dichas recomendaciones pueden tener más o menos impacto en la reduccion del desequilibrio en el cluster, por ello a cada recomendacion se le da un rating: Las estrellas. Segun dicho rating el sistema determinara si usar o no Vmotion para mover la VM en cuestion. El hecho de que se aplique o no directamente determinada recomendacion dependerá del numero de estrellas y el modo de Umbral de Migracion(Migration Threshold) en el que estemos. Dicho umbral establece qué migraciones se llevaran a cabo automaticamente, desde el Mode Conservative (que solo aplica las que tiene 5 estrellas), al Agressive, que aplica todo lo que tenga una o mas estrellas.

Los requerimientos para formar un Cluster DRS son como los de Vmotion, requiriendo storage compartido y las etiquetas de las redes consistentes en todos los hosts (son case sentitive!!!!).



¿Que ocurre si quitamos un host del Cluster?
Si tenemos Manual o Partially Automated nos mostrará sus recomendaciones, si tenemos configurado Fully Automated las VMs seran migradas a otros hosts.

¿Que ocurre si ponemos un host en Maintenance Mode?
Las operaciones en dicho host se restringen automaticamente: No se pueden encender nuevas VMs dicho host y no se pueden migrar VMs a dicho host.
El administrador debera apagar las VMs o migrarlas a otras (se recomendara) y posteriormente apagar el host.
(El host marcado como en mantenimiento no sera tenido en cuenta para HA)

¿Qué ocurre si se cae el Virtual Center Server?
Los hosts seguiran corriendo usando los recursos disponibles pero no habra recomendaciones para optimización de recursos.

Link a la Parte I:
Parte I: ¿Como funciona DRS de VMware?

Link a la Parte III:
Parte III: ¿Como funciona DRS de VMware?

martes, 3 de junio de 2008

Soporte para productos Microsoft en maquinas virtuales de VMware

Esta pagina de VMware describe el soporte para productos Microsoft que corren en VMs:
http://www.vmware.com/support/policies/ms_support_statement.html
Es una información útil para tener a mano, especialmente si necesitas asegurar a algún cliente sus opciones de soporte.
Personalmente, me da un poco pena que Microsoft(y Oracle dicho sea de paso) haga negocio de esta forma: poniendolo difícil a los usuarios para obtener su soporte mientras ellos desarrollan su producto de Virtualización. Está claro que cuando peguen fuerte con Hyper-V, Microsoft ofrecerá soporte total a las instancias virtuales de sus productos (que corran en Hyper-V, claro...). Que forma más triste de dar un servicio a la gente que les paga.

In Virtualization we trust.

lunes, 2 de junio de 2008

Como crear un Disco Duro para acceso compartido en el mismo Host ESX

En muchas ocasiones nos puede venir muy bien que dos VMs compartan el acceso a un disco duro simultaneamente. Esta es la forma tipica de crear un cluster MSCS o un cluster GFS u OCFS o Linux HA, etc, etc.

Lo que se busca es que dichas VMs puedan acceder al mismo tiempo al disco, poniendo una capa por encima que arbitre (generalmente mediante locks) el acceso en lectura/escritura. Lo normal, es que usemos Raw Device Mapping y que dichas VM estén en diferentes Hosts ESX pero hay muchas veces que por diversas razones (no tenemos una SAN, estamos haciendo una maqueta de pruebas, etc,etc) necesitamos poner las VMs que conforman dicho cluster en el mismo Host ESX.

En estos casos, para que sea posible compartir un disco duro (un "virtual disk"), es necesario especificar en el driver SCSI de las máquinas virtuales en las cuales el disco va a ser compartido que su Bus SCSI va a ser compartido:





Una vez hecho esto, tendremos que crear el disco que va a ser compartido como "thick".

El comando para hacerlo es:

vmkfstools -c 10g ruta_del_disco_duro_a_crear -d thick

Una vez creado el disco, lo añadimos a las máquinas virtuales que lo tengan que utilizar a través de "Add Hard Drive", "Use an existing virtual disk". Lo normal es crear con el comando anteriror el vmdk que va a ser compartido en el primer nodo del cluster (es decir en el mismo direcorio que el vmx del primer nodo) y en los nodos simplemente añadir el disco usando Use an existing virtual disk y seleccionando el directorio donde esta el vmdk a compartir.

¿Porqué debemos crear el Virtual Disk como thick?
Esto ocurre porque, al tratarse de un disco que va a ser compartido, los nodos pueden estar escribiendo simultáneamente en posiciones del disco muy diferentes, por ejemplo uno podria escribir al principio mientras que otro podria escribir al final, por ello es necesario reservar y ocupar todo el espacio que ocupa el disco ya desde su creación.

Parte I: ¿Como funciona DRS de VMware?

Despues de completar el post de ¿Cómo funciona VMware HA?, me permito continuar con la saga. La documentacion técnica de VMware sobre estos dos temas que se usan ampliamante en produccion me parece muy limitada, por eso veo necesario hacer este pequeño compendio de información para tener a mano.

DRS quiere decir Distributed Resource Scheduler y es quien se ocupa de balancear la carga que tienen los Host ESX de un cluster, mejorando el uso de los recursos y pools de recursos en un cluster. Cuando decimos carga nos referimos a los parametros de CPU y memoria, no tiene en cuenta el uso de I/O ni de disco ni de red, ni otros overheads que también influyen en la capacidad de nuestros host. El algoritmo de DRS tiene como entrada la informacion de uso de los recursos tanto de las VMs como de los Hosts y como salida las recomendaciones de movimientos de las VMs de un host origen a otro destino, es decir el emplazamiento de las VMs.
DRS acepta tres modos de funcionamiento: Manual, Partial o Full Automated Control y dependiendo del modo elegido el emplazamiento de las VMs se hará de forma más o menos automatica.

Las recomendaciones (output del algoritmo DRS) se basan principalmente en :
  • Asegurar las politicas de recursos de forma ajustada:
    • Reservation: Garantia de recursos (al menos X)
    • Limits: Limite superiror(No mas de X)
    • Shares: Prioridad relativa (si el sistema esta overcommited)
  • Balancear carga de las VMs:
    • Balanceo de la media de CPU y memoria
  • Host en maintenance mode.

Restricciones de emplazamiento:
  • Affinity/Anti-affinity rules (x ej Controladores de dominio en diferentes hosts o servidor de aplicaciones y base de datos juntos para aumentar el rendimiento(al no ir por red fisica...))
  • Vmotion Compatibility (Tipo de CPU, LAN, conectividad SAN)

Etapas en DRS:

Emplazamiento Inicial:
Cuando encendemos por primera vez una VM en un cluster DRS aporta una lista priorizada de los host que pueden ejecutarla. En el modo Manual, DRS nos muestra su recomendacion y el administrador elige, en cambio en los modos Partially y Full Automated el administrador no elige, simplemente la emplaza en el primer host de su lista.

Operaciones en ejecucion:
Durante la operativa normal las VMs estan corrindo cada una en su host. Las variaciones de CPU, memoria (factores como se ha comentado arriba), hacen que DRS nos haga sus recomendaciones.
En el modo Manual y el Partailly Automated, el DRS nos hace recomendaciones y administrador las acepta o no. En Full Automated DRS decide él solito.


Link Parte II:
Parte II: ¿Como funciona DRS de VMware?

Link a la Parte III:
Parte III: ¿Como funciona DRS de VMware?