miércoles, 30 de abril de 2008

Networking Performance en ESX 3.02 y 3.5


Si teneis alguna duda sobre el rendimeinto de red del ESX podeis ver este documento. La ultima revision es de finales de Febrero.
Aunque es relativo, como todo lo que es comercial, lo destacable es la buena comunicacion en cuanto a latencia y throughput que se establece entre dos VMs que estan en el mismo vswitch (2,5Gbps) contra la que se establece cuando debe pasar por el cable (900Mbps), ademas del uso de TSO.

Estas son sus conclusiones:
"The results in this study clearly show that the virtualized applications running in virtual machines on ESX
Server 3.5.0 can achieve the same network throughput and latencies that are achieved by applications running
natively. In fact, virtual machines that are connected to the same virtual switch can communicate at rates that
are up to two-and-a-half times the rates supported by physical 1Gbps Ethernet networks."

Otra cosa seria una comparación en rendimiento de acceso a disco...... ;-)

Estado del Arte: Thin provisioning, Deduplication, SVI, NFS, FC

Uno se queda pensado cuando ve el pequeño boom que esta teniendo el viejo NFS con VMware y las soluciones tan vistosas que están saliendo al mercado para VDI..., para ahorrar espacio (duplicación, thin provisioning etc...). La confluencia de todas estas tecnologías está haciendo que a la mayoría de los usuarios se escape las implicaciones que tiene usarlas por lo poco que el mercado ayuda y lo mucho que nos confunden los comerciales:
¿Que hacer? Usar NFS? Usar VMFS? Usar deduplicación? Usar SVI?
Todo tiene sus pros y sus contras, pero al menos hay que saber lo que nos espera:

La historia suele comenzar con VDI o con las maquinas virtuales en VMFS y cuando nos damos cuenta de que no es tan barata la solución como la pintan, entonces vemos si hay algo en el mercado que nos pueda satisfacer y hacer que nos gastemos menos...

Bien, estos dos vídeos comerciales: Primero y Segundo nos pueden hacer pensar que todo es muy bonito y que la solución es trivial, barata y sencilla.

El primer vídeo nos muestra al campeón de la Fibra: EMC enseñándonos como de unos 10GB podemos realizar unos 1000 escritorios. Nos explica como metiendo una capa extra, con cinco "Fully realiced" copies (50GB) podemos escalar a 1000 escritorios usando snaps de la cabina "sin ocupar nada de espacio".
En fin, la única idea que me gusta del vídeo es que menciona que podemos dar servicio Silver, Gold etc, según de las copias full que realicemos y eso da la ligera impresión de que al menos suponen "cierta" pérdida de performance.
Al margen de que sea "solo pizarra" y de que no diga un solo detalle técnico, por lo que nos muestra, podemos pensar que se trata de LUNs de VMFS(en ningún momento lo dice y por lo que sabemos los snaps EMC basados en SAN son de tipo LUN), pero a nada que nos acordemos del limite (256 creo recordar) de LUNs que pueden ver nuestros ESX llegamos a la inevitable conclusión de que se trata de NFS, (a no ser que VMware, al ser muy amiguitos, les haya pasado las especificaciones de VMFS durante el café...).
Conclusión: Lo que nos propone EMC, gran defensor del FC, para VDI es claramente el uso de NFS: "Adiós FC, (o hasta luego)"
(Y eso que me encanta la fibra: Te hace ir al baño ;-) , No, en serio, vale que el inicio es complejo y que su precio, si te la puedes permitir, no es una ventaja, pero luego tiene una estabilidad muy buena, hay que decirlo).

El segundo vídeo, esta un poco más currado la verdad (faltaría mas, es NetApp!). Después de verlo te queda claro que no se pueden correr 1000 VMs con solo ese espacio de disco, pero ilustra bien la potencia que tiene NFS+NetApp y sus clones a nivel de fichero. Por algo su sistema de ficheros se llama WAFL ("Write Anywhere File Layout'") y nos permite ofrecer Thin Provisioning ("dedicate on write not on allocation") según instalamos la cabina.

Aquí llegamos al primer meollo de la cuestión:
Thin provisioning
y VMware, es decir, Thin Provisioning en dos niveles: nivel VMware y nivel NFS(cabina).


Puede parecer una buena idea tener ambas capas pero esto lleva a pesadillas serias en la administración (sobretodo el primer punto):
1.- El tener el thin provisioning y el thin disk nos produce issues con Storage VMotion, Cold Migration, deploy de template...

Cuando creamos una VM en VMware, por defecto dicha VM es creada en el volumen NFS como thin disk, de hecho esto no es algo que lo determine VMware sino el propio servidor de NFS. Segun "ESX Configuration Guide":
Y mas tarde, el mismo documento, añade: "The virtual disks that you create on NFS‐based datastores use a disk format dictated by the NFS server, typically a thin‐disk format that requires on‐demand space allocation. If the virtual machine runs out of space while writing to this disk, the VI Client notifies you that more space is needed."

Posteriormente, cuando realizamos alguna de las acciones antes mencionadas (Storage VMotion, Cold Migration, deploy de template) el disco se vuelve thick. Se puede, como hemos visto (autobombo, jeje), clonar el disco a thin y volver a unirlo a la VM. Incluso se puede scriptear, pero no deja de ser un arreglo.

2.- Consideremos también la visibilidad y la administración dependiendo de si el disco es thin o thick:
2.1.- Desde la perspectiva del VC, siempre veremos el tamaño del disco thin en el datastore y si, como suele ocurrir, tienes multiples usuarios finales haciendo deploys de VMs , éstos no tendrán la visibilidad de la ocupacion actual para realizar el provisionamiento y el hecho de que las VM tengan la posibilidad de llenar X espacio puede llegar a ser un problema serio: Estamos infraprovisionando el almacenamiento y sobreprovisionando las VMs: Algo puede ir mal.

2.2.- ¿Que ocurre con nuestra Console ? Haciendo un "ls" veremos el disco thin ocupando la maxima capacidad de la que es capaz, sin embargo un "du" nos devuelve el tamaño thin del disco. Amazing.

Veo que puede dar menos problemas que el Thin Provisioning esté controlado en el sistema de almacenamiento que tengamos. Esto es totalmente discutible pero intuyo que sería mucho mas simple para todos. (Creo que 3PAR actualmente puede manejar correctamente el formato de vmdk "zero'ed thick" asi que probablemente por ahi vayan los tiros en un futuro. ¿Alguien sabe cómo decirle a nuestro NFS que por defecto provisione de forma thick y no thin?).

El otro tema candente que nos venden como la panacea es la Dedupliacion(Single Instancing).
La deduplicacion consiste en que los bloques de datos iguales no se repiten, si no que en su lugar hay un puntero que los señala.
Explicacion somera (esto es cierto en un 90% para NetApp):
En algun lugar hay un directorio que dice que el fichero A esta almacenado en los bloques 123-345, 500-510 y 12999-14090. Por el momento esto es lo normal para todos los FS. La diferencia entre el FS deduplicado y el normal es que pueden usar el mismo bloque más de un fichero. Si edito el fichero A y añado 10KB al final y lo guardo como B en algun momento (dedupe en tiempo real o dedupe diferida) el proceso de deduplicacion reconocerá (via hashes o por comparacion de bytes) que ambos ficheros tienen los mismos datos y creará una entrada en el directorio que dice que B utiliza los bloques 123-345, 500-510, 12999-14090 y 66666-66669(Por ejemplo los bloques son de 1K), de forma que la creacion del fichero B solo ocupa 10K(del 66666 al 66669).

Como se puede intuir esto no puede ser manejado por la cabina que esta detrás sin algo intermedio, un S.O o un FS que escanean los bloques duplicados y los enlazan con lo que significan más alto en la cadena y deciden que hacer si algo desde arriba necesita escribir en un bloque previamente deduplicado etc, etc...
Lo que choca de todo esto es que lo que les pedimos idealmente a nuestros diseños de almacenamiento (al menos en teoria) es precisamente NO hacer nada de esto pues idealmente debe hacerse mas arriba (en el File System ).
Por el momento VMFS no es capaz de hacer resto pero SVI(Scalable Virtual Image) sí parece que lo va a hacer de alguna forma quitando (o compitiendo con) la necesidad de la deduplicacion a nivel de cabina.

¿Que es SVI?
Explicacion muy somera porque hay poca info: Es una tecnología que esta basada en "linked clone" (VMware Workstation 6) que, segun VMware, reducirá en un 90% los requerimientos de almacenamiento en entornos de escritorios virtuales. Segun ellos, repito, mejora la gestion de imagenes de escritorios y facilita el provisioning. La idea es tener un disco stateless(o unos pocos) que lleven el SO (disco maestro) que sea el mismo para todos y luego un disco de personalización para cada usuario de forma que los parches etc sólo haya que aplicarlos en los discos maestros.


Seria muy interesante una comparacion de NetApp sis-clone y SVI, incluso trabajando juntos...

¿Que concluir de todo esto?

NFS mola, tiene sus cosillas pero mola, el elegirlo o no depende del entorno, como siempre.

  • La primera conclusion de todo es que cada vez es menos cierto el paradigma de que la Fibra es la Reina. (Con lo que me gusta...jeje)
  • Lo segundo es que VMware deberia meter muchas mas horas en el VMFS y hacer que sea algo realmente competitivo. Seria genial que integrasen la "deduplicacion" de SVI en VMFS. Y tema Thin Provisioning... Tiempo al tiempo.
  • Lo tercero es que NFS te puede quitar bastantes dolores de cabeza si estas pensando en migrar en un futuro o tener un entorno heterogeneo (Citrix XenServer o Microsoft Hyper-V). Probablemente para ese momento los formatos de discos virtuales ya sean interoperables y cualquier cabina es capaz de presentar NFS y CIFs.
  • Lo cuarto es que si pones soluciones de VDI basado en cabina como muestran los videos o VDI+SVI mejor si tienes cache de sobra para parar un tren. Como idea: Puede servir para dar diferentes niveles de servicio en escritorios(¿esto es util realmente?): GOLD, SILVER, BRONZE dependiendo del ratio (Escritorios)/(Full VM Copy)...
  • Lo quinto es que la solucion de NetApp que incorpora un S.O y un File System precisamente para hacer cosas como la deduplicacion es muy buena aunque de forma "pura" la cabina no se debería de ocupar de la deduplicacion, es cosa del File System. Desde luego no hay que olvidar que la deduplicacion nos sirve también para todo lo demas que no sea vmdks(en una cabina no solo existe VMware...), por ello pienso que en global la solucion de NetApp es muy versatil y cómoda aunque también pienso que deberia ser el propio FS (VMFS en este caso) el que realizase la deduplicacion.

lunes, 21 de abril de 2008

Primer documento OFICIAL de VI Client Plug-in


Pues sí señor, los de VMware se han pueso las pilas y han sacado documentacion sobre el desarrollo de VI Client Plug-in(tanto servidor como cliente). Os recomiendo echarle un vistazo, esta muy bien: Lo teneis aqui

La idea de abrir el framework y dejar que terceros desarrollen plugins de sus productos para integrarlos en el virtual Center 2.5 hace que se puedan realizar soluciones como esta.

Por lo que he podido hojear, la documentacion es tan simple que incluso yo seria capaz de poner un botoncillo en el Virtual Center y hacer que haga algo.
Esperemos ver aparecer buenos y diversos plug-ins...

¿Que hace cada proceso de un ESX?

Siempre me he preguntado qué hace cada proceso en un servidor ESX de VMware. El saber a tan bajo nivel que es cada cosa:
- nos da cierta seguridad porque al fin y al cabo es un *nix (windows la verdad es que me manejo a nivel de servidor pero no tan agusto como en un linux...),
- nos puede venir bien para tener el concepto de qué hace funcionar esas maquinas virtuales y qué representan para el Red Hat 7.1 que en realidad lleva el servidor ESX.
- nos sirve también para cuando el VIC falla(lo hace de vez en cuando) y no nos da la informacion necesaria de lo que ha pasado o esta pasando(esto ultimo lo hace constantemente... aun asi es muy buen producto).


Al grano, ¿qué procesos podemos ver corriendo cuando realizamos un 'ps' en nuestros ESX?
(Bueno para verlo bien deberemos ejecutar "ps axfwwww", las w son de wide wide wide, porque si no los procesos de nombre largo apareceran cortados en nuestra consola).

[vmnixhbd]
Este proceso del kernel modificado de VMware(vmnix) controla las HBAs de nuestro sistema.
[vmkdevd]
Este proceso controla los dispositivos(devices o adapters) que pueden ser reconocidos por el vmkernel.

Estos dos ultimos procesos son consultados por el comando esxcfg-vmhbadevs que nos devuelve el mapping de nombres vmhbaX:X:X a nombres /dev/ de linux.

/usr/sbin/vmklogger
logger -t VMware[init] -p daemon.err
Estos procesos se encargan del log del vmk(vm kernel o vmnix).

/bin/sh /usr/bin/vmware-watchdog
Este proceso es un supervisor (como su nombre indica perro guardian), es decir, es un proceso(un script de shell) que tiene el cometido de lanzar otro proceso y supervisar si se cae o no para levantarlo.
Es algo que me suena, jeje, reconozco que quiza en algunos servidores tenga tareas cronificadas para este tipo de labores... como dice un amigo: "Ese script me ha salvado de venir muchos domingos...".
Realmente lo que hace el proceso es lanzar el proceso especificado y volver a levantarlo si se cae. Dejará de hacer esto(en consecuencia dejara caido el servicio al cual supervisa) si se producen un numero de caidas sucesivas del proceso("quick failures" definido como "caidas entre las que hay menos tiempo que min_uptime") o un numero absoluto de caidas totales.

Por ejemplo: /bin/sh /usr/bin/vmware-watchdog -s vpxa -u 30 -q 5 /usr/sbin/vpxa
Sintaxis: /usr/bin/vmware-watchdog -s tag [-u min_uptime] [-q max_quick_failures] [-t max_total_failures] command
-s
Nombre/Tag del servicio que debe correr (en este caso vpxa)
-u Maximo tiempo en segundos entre caidas para considerarlas "quick failures". O minimo tiempo que debe estar levantado para que
-q
Numero maximo de "quick failures"
-t Numero total de "failures"
command: Comando a ejecutar (por ejemplo /usr/sbin/vpxa).

/bin/sh /usr/bin/vmware-watchdog -s webAccess -u 30 -q 5 /usr/lib/vmware/webAccess/java/jre1.5.0_07/bin/webAccess -server -Xincgc -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Djava.endorsed.dirs=/usr/lib/vmware/webAccess/tomcat/apache-tomcat-5.5.17/common/endorsed -classpath /usr/lib/vmware/webAccess/tomcat/apache-tomcat-5.5.17/bin/bootstrap.jar:/usr/lib/vmware/webAccess/tomcat/apache-tomcat-5.5.17/bin/commons-logging-api.jar -Dcatalina.base=/usr/lib/vmware/webAccess/tomcat/apache-tomcat-5.5.17 -Dcatalina.home=/usr/lib/vmware/webAccess/tomcat/apache-tomcat-5.5.17 -Djava.io.tmpdir=/usr/lib/vmware/webAccess/tomcat/apache-tomcat-5.5.17/temp org.apache.catalina.startup.Bootstrap start
\_ /usr/lib/vmware/webAccess/java/jre1.5.0_07/bin/webAccess -server -Xincgc -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Djava.endorsed.dirs=/usr/lib/vmware/webAccess/tomcat/apache-tomcat-5.5.17/common/endorsed -classpath /usr/lib/vmware/webAccess/tomcat/apache-tomcat-5.5.17/bin/bootstrap.jar:/usr/lib/vmware/webAccess/tomcat/apache-tomcat-5.5.17/bin/commons-logging-api.jar -Dcatalina.base=/usr/lib/vmware/webAccess/tomcat/apache-tomcat-5.5.17 -Dcatalina.home=/usr/lib/vmware/webAccess/tomcat/apache-tomcat-5.5.17 -Djava.io.tmpdir=/usr/lib/vmware/webAccess/tomcat/apache-tomcat-5.5.17/temp org.apache.catalina.startup.Bootstrap start
Como vemos el proceso vmware-watchdog lanza y supervisa el proceso webAccess de forma que si en los ultimos 30 segundos se cae mas de 5 veces, simplemente dejará de levantarlo.
Pero, ¿qué es el proceso "/usr/lib/vmware/webAccess/java/jre1.5.0_07/bin/webAccess": Este proceso controla el servidor web del ESX(sí, ese que no tiene todas las funcionalidades y por eso no se usa mucho...).
Su reinicio se realiza de esta manera: service vmware-webAccess restart.
Su log esta en: /var/log/vmware/webAccess
Puertos en uso: 8080, 8009, 8005,

/bin/sh /usr/bin/vmware-watchdog -s vpxa -u 30 -q 5 /usr/sbin/vpxa
\_ /usr/lib/vmware/vpx/vpxa
El agente del Virtual Center(el encargado de cominicarse conel VC) es uno de los que mas CPU consume normalmente. Como en el caso anterior watchdog vigila que no se caiga muchas veces. Entres sus funciones estan las de: comunicarse con las VMs, comunicarse con el Virtual Center y mantener la informacion del estado de los hosts comunicandose con VMAP y poder asi decidir que hacer en caso de caida de otro hosts(HA).
Su reinicio se realiza de esta manera: service vmware-vpxa restart
Su log esta en: /var/log/vmware/vpx
Puertos en uso: 902, 903 (el xinetd usa el 902 de la interfaz local)

/bin/sh /usr/bin/vmware-watchdog -s hostd -u 60 -q 5 -c /usr/sbin/hostd-support /usr/sbin/vmware-hostd -u -a
\_ /usr/lib/vmware/hostd/vmware-hostd /etc/vmware/hostd/config.xml -u -a
Este proceso es, por lo general, el que más CPU consume del servidor. (Suele ser tres veces más que el segundo que mas consume, el vpxa). Este proceso se ocupa, entreo otras cosas, de que el Virtual Infraestructure Client se entere de los cambios que se producen en el ESX. Los cambios realizados por linea de comandos en el ESX no seran visibles al Virtual Center sin reiniciar este demonio y, por consiguiente, que vuelve a leer el fichero de configuracion del ESX(/etc/vmware/esx.conf)
Su reinicio se realiza de esta manera: service mgmt-vmware restart
Su log esta en: /var/log/vmware/hostd.log

/bin/sh /usr/bin/vmware-watchdog -s cimserver -u 60 -q 5 /var/pegasus/bin/cimserver daemon=false
\_ /var/pegasus/bin/cimserver daemon=false
\_ /var/pegasus/bin/cimservera
Estos procesos son ajenos a VMware(de hecho Xen también los usa: http://xen.org/files/xs0106_xen_managmnt_interf.pdf ).
Llevan el CIM(Common Information Model), un standard industrial desarrollado por el Distributed Management Task Force (DMTF), para describir datos acerca de aplicaciones y dispositivos de forma que los administradores y los programas de gestion de software puedan controlar de la misma manera las aplicaciones y dispositivos en diferentes plataformas, asegurando la interoperativilidad. Usa tecnicas de Programacion Orientada a Objetos para proveer de una definicion consistente y una estructura de los datos. Por ejemplo, si una empresa compra cuatro servidores de diferentes vendedores, con CIM el administrador puede ver la misma info de cada uno de ellos: fabricante, SN, numero de dispositivo, capacidad de almacenamiento, relacion con aplicaciones... (Otros protocolos mas simples son SNMP y DMI)
Mas info: http://www.openpegasus.org/

/usr/lib/vmware/bin/vmkload_app --setsid --sched.group=host/system/vmkauthd --sched.mem.min=4 --sched.mem.max=12 /usr/lib/vmware/bin/vmware-vmkauthd
Este proceso es el cargador de aplicaciones del espacio de usuario. La aplicacion es ejecutada con los parametros indicados y administrada por el VMkernel. El proceso vmkload_app espera a que la aplicacion termine y sustituye (hace de repetidor/proxy) la entrada y la salida standard de la aplicacion. Si le enviamos una señal nº7(SIGNAL 7) a vmkload_app la señal sera reenviada a la aplicacion que corre debajo.
Solo las aplicaciones compiladas para el VMkernel pueden ser ejecutadas por este proceso, además, sólo son permitidos los binarios listados explicitamente en /etc/vmware/UserWorldBinaries.txt.
Con la opcion -k se puede mandar una señal a la aplicacion que esta corriendo.
Con la opcion -b se puede forzar a la aplicacion que esta ejecutandose a pararse y esperar que se enganche un debugger.

En concreto el proceso anterior esta lanzando la aplicacion /usr/lib/vmware/bin/vmware-vmkauthd desde el espacio de usuario contra el VMkernel. Las opciones dicen que se ejecute en el schedules group host/system/vmkauthd, con un maximo de memoria de 12 y un minimo de 4 y que se cree una nueva sesion de terminal para el proceso vmkload_app.
/usr/lib/vmware/bin/vmware-vmkauthd se encarga de la autorizacion el vmkernel(en concreto de que podamos usar la console de las VMs, como su fuera un redirector del KVM).
Su fichero de configuracion es
/etc/vmware/config
Su reinicio se realiza de esta manera: service vmware-vmkauthd restart
Este proceso parece que no usa ningun puerto directamente pero el 902 es el puerto well-know de vmkauthd y es usado por vpxa.

/usr/lib/vmware/bin/vmkload_app /usr/lib/vmware/bin/vmware-vmx -ssched.group=host/user -@ pipe=/tmp/vmhsdaemon-0/vmx6c1dbb9c3b513d69;vm=6c1dbb9c3b513d69 /vmfs/volumes/4640826e-e0c6126a-e819-001a64088132/Virtual_Machine_RHELAS4U2/Virtual_Machine_RHELAS4U2.vmx
Estos procesos son la joya de la corona. Realmente son los procesos que representan las VMs, es decir, hay tantos procesos de este tipo como maquinas virtuales encendidas. Para el ESX cada VM es un unico proceso lanzado desde el espacio de usuario a través de vmkload_app. Como se ve, hace referencia al archivo de conf de la maquina virtual(vmx).

La forma de apagar forzosamente una maquina virtual (cuando no queda más remedio) es haciendo un kill -9 a ese PID, de esta forma el proceso muere y la maquina virtual será reportada en el VIC como apagada. Si alguien quiere tenfo desarrollado un rpc que se instala en el ESX y permite "apagar" una maquina virtual de forma instantanea. Lo use para un cluster GFS de maquinas virtuales y es el equivalente de un switch de corriente que le quita la corriente a un servidor para realizar el fencing.


Adjunto imagen con la configuracion de puertos de VI3. Espero que sirva para aclarar el tema de los puertos:


Como relfexion: Realmente en todos los ESX que he mirado, los procesos que más CPU gastan son vmware-hostd y vpxa que no se ocupan realmente de ejecutar las VMs sino que se ocupan de conectar la infraestructura virtual. Sin embargo los procesos de las maquinas (los procesos vmware-vmx) no consumen ni de lejos la misma CPU. ¿No deberia ser al revés si lo que estamos compartiendo con nuestros servidores virtuales es la CPU? Quiza sea un tema de cómo representa la CPU el Red Hat que lleva debajo..., quiza tengo algo mal en mis ESX...

sábado, 19 de abril de 2008

Oracle VM: LiveSync - High Availability, LiveMigration sin SAN


Los de Thinsy(EnSpeed) han anunciado que ya esta disponible para descarga las caracteristicas de Live Migration(Vmotion en terminos vmwaristicos) y VMFailover(HA en terminos vmwaristicos) para OracleVM. La noticia no sería tan importante si no hubiesen anunciado que esto se puede hacer sin una SAN, es decir que con Direct Attached Storage sería suficiente.
Como dice la nota de prensa:

Saratoga, California – April 17, 2008 – Thinsy Corporation today announced the immediate availability of a new version of their Peer to Peer SAN Replacement technology LiveSync, for Oracle VM Server 2.1.1. Once the LiveSync rpm is installed on the Direct Attached Storage equipped Oracle VM Servers, High Availability Failover and LiveMigration are enabled. Clone VM support, a new feature which enables the cloning of VMs in less than fifteen seconds was also unveiled by Thinsy Corporation.

Yo por el momento no lo he visto asi que permanezco incredulo pero podria ser un fuerte varapalo para VMware puesto que la compra de una SAN es una de las cosas que suele tirar para atrás a las empresas a la hora de comenzar con la virtualizacion. Proximo episodio en su casa...

viernes, 11 de abril de 2008

Thin Provisioned: Problemas con Storage VMotion, migraciones y clonaciones

Cada vez es más usual trabajar con VMware sobre NFS. La combinacion con una NetApp y sus FlexVolumes hace que sea algo muy flexible y facil de provisionar y administrar. Con la capacidad de las cabinas NetApp de realizar Thin Provisioning somos capaces de dar grandes volumenes de datos pero ocupar solo lo necesario. El concepto se ve facilmente de forma grafica. Por defecto, cuando provisionamos VMDKs por NFS las cabinas NetApp lo administran como thin provisioned. Hasta el momento esto no habia dado problemas de ningun tipo, es mas, es una gran ventaja.

Las pruebas muestran que, aunque los VMDKs son provisionados como thin en su creacion, luego se pueden convertir a thick a lo largo de su vida por una serie de operaciones como son (Quiza haya mas):
:( Migracion de los VMDKs de un datastore a otro (aunque el destino tambien sea NFS) convierte los VMDKs a thick.
:( Realizar clones de los VMDKs thin hace que los clones sean thick.
:( Realizar Storage VMotion tambien provoca que los discos se vuelvan thick.

¿Como solucionarlo?
Si tenemos una NetApp con single file SnapRestore estamos de suerte. Bueno, al menos las dos primeras operaciones antes descritas sí que podemos conseguir que nos mantengan los VMDKs de forma thin. (Para la tercera Storage VMotion no sirve).

Pasos:

  1. Una vez preparada la VM (sysprep si es windows), tomaremos un snapshot del volumen que la contiene [snap create vol-name snapshot-name ].
  2. Posteriormente creamos una VM en el Virtual Center pero sin disco. (Esto crea los ficheros de conf y el directorio)
  3. Ahora podemos correr un SnapRestore para recuperar el .vmdk y el -flat.vmdk. [snap restore -t file -s snapshot-name -r new filename and path original filename and path]
  4. Editaremos el .vmdk de la nueva VM para que apunte al nuevo -flat.vmdk. Y ya solo nos queda Edit Settings y añadir el disco.

lunes, 7 de abril de 2008

como funciona VMware HA

Bueno despues de varios posts cortos aqui va uno largo que llevo preparando tiempo.

La documentacion de VMware acerca de VMware HA deja bastante que desear y realmente es un producto que muchas veces necesitas conocer más a fondo para resolver problemas que te encuentras, por eso veo necesario tener una pequeña guía (técnica) de cómo funciona VMware HA:

VMware HA monitoriza constantemente todos los ESX de un cluster y detecta las caidas de estos. En cada host hay un agente corriendo que mantiene el heartbeat con los demas hosts del cluster. La perdida del heartbeat inicia el proceso de reiniciar las maquinas virtuales en los otros hosts proporcionando de esta forma un fail over de las maquinas virtuales con una parada minima(downtime = tiempo de reinicio) de servicio.

Es importante resaltar que HA es reactivo, es decir actua cuando ocurre algo y NO usa Vmotion y DRS es proactivo: usa vmotion y actua para que no ocurra nada o para que no se de la situacion en la que pueda ocurrir.

El hecho de que las VMs se inicien en un host o en otro cambió en el VC2 y el VC2.1: El primero lo hacia alfabeticamente, es decir la VM se iniciaba en el siguente host alfabeticamente que tuviese recursos, en cambio en el VC2.1 el host que iniciara la VM sera el host que tenga mayor capacidad(sin reservar) para levantarla. Una vez que HA ha realizado el paso de VMs, el DRS entra en juego y verá si es necesario mover las VMs.

VMware HA no controla la caida individual de una VM, ésto puede tratarse con una alarma, ya sea con el Virtual Center o con un software de monitorizacion externo.

Arquitectura:

La creacion y administracion de los clusters de HA se hace a traves del VC. El servidor de administracion del Virtual Center instala un agente en cada host del cluster de forma que cada host pueda comunicarse con los otros y mantener la informacion del estado de los hosts y poder asi decidir que hacer en caso de caida de otro hosts.
En cada cluster hay un host que es el primario(suele ser el primero) que actua como controlador y es el que inica las accciones de failover. De hecho, cuando se introduce un nuevo nodo al cluster, éste ultimo necesita comunicarse con el primario para completar la configuracion. Si el nodo primario cae, HA inmediatamente promociona uno de los nodos a primario.
Actualmente AAM no permite mas de 4 hosts y el parametro de max number of failures se refiere al maximo numero de primarios que podria haber en un cluster.

- Cuando queremos quitar un nodo del cluster lo podemos poner en Maintenance Mode y apagar las VMs o migrar (vmotion) sus VMs (si DRS esta activado, éste nos lo propondrá o lo hara directamente).
- Cuando se añade un nuevo nodo al cluster, todas las VMs se ponen a default: Restart Prioriy = Medium e Isolation Response = PowerOff

Nota: Para apagar temporalmente HA ponemos el ESX en maintenance mode y para apagar temporalmente DRS lo configuramos como partially automated.

El agenteVC (vpxa) se comunica con las VMs y VMAP (este ultimo contiene la lista de que hosts estan corriendo que VMs). El agente AAM (HA agent) monitoriza AAM en otros hosts (heartbeat via red SC), para evitar el split brain cuando los nodos se quedan aislados, cada nodo tiene una direccion a la que hace ping para ver si esta aislado (option das.isolationaddress ).
[Mas opciones avanzadas: http://pubs.vmware.com/vi35/resmgmt/wwhelp/wwhimpl/common/html/wwhelp.htm?context=resmgmt&file=vc_cluster_das.10.9.html]

Los requesitos para que funcione HA son:

  • Capacidad de encender la VM desde cualquier host
  • Acceso a recursos comunes(red, SAN)
  • Resolucion de DNs en el cluster(tiene muchisima dependencia /etc/hosts y /etc/resolv.conf)

Parametros a Configurar:

Orden de reinicio de las VMs: Establece que prioridad de reinicio tienen las VMs. Se debe establecer a Disabled si no queremos que se use HA en dicha VM.

Admision Control: Aqui se prioriza el uptime o que las maquinas tengan sus recursos siempre.

Isolation response: Que hacer si se queda aislado el host: el power off de las VM liberará el lock de los discos.

Nota: Cuando se añade un nuevo nodo al cluser, todas las VMs se ponen a default: Restart Prioriy = Medium e Isolation Response = PowerOff


¿Que ocurre si el VC Server se cae?

El Virtual Center Management Server(servidor del VC) no es un unico punto de fallo porque si cayera el VC Server los clusteres de HA siguen pudiendo reiniciar las maquinas virtuales en otro host en caso de caida de uno de los hosts de forma que el funcionamiento general sigue pero la informacion de que recursos estan disponibles será la del estado del cluster antes de caer el VC Server.

Si entramos con el VIC a un ESX y cambiamos algo mientra el VC esta caido entonces eso cambios si tienen efecto y cuando repongamos el VC los verá.(En cambio si el VC no esta caido y modificamos algo con el VIC a traves de un ESX , el VC no lo verá y tendrá desactualizado su VMap etc...)

VMware HA esta continuamente monitorizando qué recursos hay para ser capaz de reiniciar las maquinas en diferentes hosts en caso de caida de uno de ellos. El agente AAM se ejecuta en la service console de los hosts y mantiene una base de datos en memoria de los nodos del cluster usando los heartbeats para coordinar los nodos que estan activos y los que no (los que no son activos son los que estan sin red o en maintenance mode).

El hecho de que una maquina virtual pueda ser levantada en otro servidor ESX(host) es posible gracias a la tecnologia de locking de la pila de almacenamiento del ESX que les permite a varios ESX acceder a un mismo disco simultaneamente.


¿Que ocurre cuando un host se cae? (Cronologia del Fail-Over)

Todo el proceso dura 15 segundos despues de que el host se quede aislado y no mande mas heartbeats:

t=0s: Un host deja de tener conectividad(o se queda aislado en la red) y deja de mandar heartbearts. El nodo intanta hacer pings a la isolation address para ver si efectivamnete esta aislado.(la verification address es el default gw de la interfaz de la service console, para cambiarla hay que cambiar el parametro das.isolationaddress en advanced parameters). Si no puede hacer ping a su isolation address entonces el nodo sabe que esta aislado y no que los otros nodoas se han caido.

t menor que 12s: Si antes de 12 segundos vuelve la conectividad, todo vuelve a la normalidad. Los demas hosts marcaran al hosts con problemas de red como activo y no pasará nada. El host no se marcará a si mismo como aislado.

t entre 12s y 15s: El host se marca como aislado(isolated) y empieza a apagar sus maquinas para liberar locks(respuesta por defecto y configurable). Si justo la conectividad vuelve en este momento las maquinas virtuales se apagaran(si esta conf por defecto) pero no se levantarán(reiniciarán) en otros hosts porque los otros no le han marcado todavia al host como caido(failed). El apagado de las maquinas es hard.

t=15s: Los demas hosts declaran el host como caido(failed) y en consecuencia adquieren el lock de las maquinas virtuales y las levantan(si asi lo hemos configurado, si no la VM seguira corriendo en el host aislado y el mecanismo de locking prevendrá que no se inicie en otro sitio).

http://kb.vmware.com/selfservice/viewContent.do?language=en_US&externalId=2956923


¿Que ocurre si Current failover capacity != Configured failover capacity? (Red Cluster)

Esto ocurre cuando han fallado mas hosts que los previstos. Las VMs con mayor prioridad haran el fail over las primeras. Para la version 3.02 de ESX y anteriores, el valor de HA Failover Capacity se calcula así: El valor de Failover Capacity está determinado por el valor del slot que tiene el cluster. El slot es calculado con una combinacion de la CPU y Memoria total que hay en los hosts.

Ejemplo:
Tenemos 4 hosts y el valor CONFIGURADO de Failover Capacity es 1 Los hosts tienen esta memoria: ESX1 = 16 GB
ESX2 = 24 GB
ESX3 = 32 GB
ESX4 = 32 GB
En el cluster tenemos 24 VMs configuradas y funcionando. De las 24, hay que determinar cual es la que mas "configured memory" tiene. Por ejemplo pongamos 2GB. Las demas tienen menos o igual a 2GB de memoria configurada. Con esto ya podemos hacer el cálculo:
1. Escojemos el host ESX que tenga menor memoria RAM intalada. En este caso es ESX1 y tiene 16 GB

2. Dividimos este valor por el mayor valor de la memoria RAM de nuestras maquinas virtuales(2GB en el ejemplo). Nos sale 8 (16 / 2). Esto significa que tenemos 8 slots disponibles(como minimo) en cada ESX.

3. Como tenemos 4 hosts y la failover capacity configurada es de 1, nos podriamos quedar con 3 hosts en la peor situacion(que cayera uno). Por ello el numero total de VMs que podemos encender en esos 4 hosts es 24 VMs. ( 8 slots x 3 hosts en el caso peor = 24 VMs)

4. Si el numero total de VMs excede 24 entonces nos dará: "Insufficient resources to satisfy HA failover" y el el valor de "current failover capacity" será puesto a 0. Si el numero de VMs encendidas es menor que 24 no obtendriamos este mensaje.

Nota: Si se sigue viendo el mensaje despues de bajar el numero de maquinas encendidas, chequea las reservations de CPU y Memory en las VMs y en los resource pools porque esto puede modificar el calculo. Se debe evitar reservations de CPU y memoria innecesarias en las VMs porque esto puede causar que ocurran estos tipos de errores dado que tenemos que asegurar que el recurso esta disponible.



Para que el Virtual Center deje de estar en una situacion en la que los recursos son insuficientes para satisfacer VMware HA posdemos hacer lo siguente:

1.- Marcar "Allow Virtual Machines to be powered on even if they violate availability constraints" en la confiduracion del cluster. En este caso se ignoran los calculos anteriormente descritos y se intentará encender el maximo numero de VMs posibles en caso failover. Con esta opcion se puede establecer la restart priority (en "Virtual Machine Options") en la configuracion del cluster, de esta forma, las VM prioritarias seran encendidas antes y posteriormente las menos prioritarias hasta en punto en el que ya no se pueda encender ninguna VM más

2.- Si tenenmos una VM que tiene configuarada una gran cantidad de memoria, podemos o bien rebajar su memoria configurada o bien sacarla del cluster y ejecutarla en otro ESX standalone. Esto incrementará el numero de slots disponibles con el hardware que tenemos.

3.- Incrementar la cantidad de memoria en los servidores de forma que haya mas slots disponilbes con las reservatiosn de RAM actuales.

4.- Quitar las reservas de CPU en todas las VM que sean mayores que la velocidad maxima de los procesadores fisicos.

Nota:
El calculo descrito arriba es muy limitado como se puede ver y va a ser revisado en las siguentes versiones del Virtual Center.


Troubleshooting:

- Conectividad IP: pings desde todos a todos y con el nombre corto y el FQDN. Pings al VC server

- DNS!!!:
  • Se pueden resolver los nombres cortos(sin el dominio) en cada ESX de los otros ESX
  • El FQDN es menor de 29 caracteres?
  • Mirar el /etc/hosts y /etc/resolv.conf poner en esos ficheros el "hostname.FQDN" tambien.
  • Se puede editar el nsswitch.conf y cambiar: "hosts: dns files". Asi mira primero en dns y si estan caidos en local.
- Que la red y el almacenamiento sea visible por los nodos.
- Que no haya habido usuarios que hayan accedido con el VIC al host en concreto bypasseando al Virtual Center y hayan cambiado las reservations.
- Logs: /opt/LGTOaam512/log/* y /opt/LGTOaam512/vmsupport/* .
Principalmente aam_config_util_listprimaries.log (hosts primarios) y aam_config_util_listnodes.log


Errores y problemas tipicos:

"Could not find a primary host to configure DAS on"
A host that was removed from the VC inventory still appears on the internal list of hosts for this cluster.
Workaround: create a new cluster and add hosts to this new cluster.
Resolved in ESX Server 3.0.1 and VC 2.0.1.

"Configuring HA failed" or "while using HA, the vm did not failover".
Size of Fully Qualified Domain Name (FQDN) or short host name.
Workaround:
If the host short name is more than 29 characters, change the HOSTNAME entry in /etc/sysconfig/network to the shorter name.
If using an FQDN that is greater than 29 characters:
• Change the FQDN to less than or equal to 29 characters.
• Remove the existing cluster.
• Create a new cluster.
• Add all the hosts back to the cluster.

HA Configuration Fails
Check DNS, FQDN
You have just added a new host to the cluster
• Check /opt/LGTOaam512/log/aam_config_util_addnode.log
• /var/log/vmware/vpx/vpxa.log
• In VC, right click on the host that shows the HA problem and click reconfigure for HA.
• Were all the hosts responding?
• If not –new host cannot communicate with any of the primary hosts.
• Solution:
• Disconnect all the hosts that are not responding before you can add the new host.
• The new host becomes the first primary host.
• When the other hosts become available again, their HA service is reconfigured. ESX Server is running slowly.

Top command shows vmware-hostd using a lot of resources
vmware-hostd Uses a Lot of CPU or Has Generated a Core Dump Why DRS / HA cluster that contains VMs originally built on an ESX Server 2.x host.
Fix: To adjust resource allocation for vmware-hostd: For each VM, right click it and go to Edit Properties. Select Resources. Ensure you "touch" each CPU and memory resource:
• Restart hostd: type: service mgmt-vmware restart
• Set resources to the settings you want.

"HA service doesn't start up" or "HA error on the host, after booting successfully after host failure"
Due to problem rejoining the rest of the cluster
Fix: use the ReconfigureHA task on the host to correctly configure the HA service on the host.

Deploying a VM from a template into a cluster, the updated BIOS settings are lost.
Affects HA/DRS clusters but not DRS-only clusters.
Fix: Change the BIOS setting in the affected deployed VM.

jueves, 3 de abril de 2008

la funcion Shadow Copies de NetApp sobre CIFS

El otro dia en Madrid asistimos a una demostración de NetApp. Hacía tiempo que tenía ganas, la verdad es que es una pasada, lo que no creo que sea igual es el precio....

Algo que muchos conocerán pero que me llamó muchisimo la atencion es la utilidad de acceder a las shadow copies de volumenes compartidos. Me explico, estas cabinas son capaces de presentar al usuario de la NAS que se ha conectado por CIFS una especie de historial (o versiones) de los archivos que almacena en los volumenes compartidos, es decir la funcion de snapshots de NetApp se integra con VSS(Microsoft Volume Shadow Copy Service) de tal forma que los usuarios pueden ver los snapshots tomados en la cabina via el cliente de VSS.
Es tan facil como pinchar en el menu contextual de un archivo (boton derecho), ir a propiedades y pichar la pestaña Versiones. La verdad es que es asequible para cualquier usuario y quitaría mucho trabajo a los administradores de sistemas que tienen que tirar de backup.