Upgrade a vCenter Server 5.0

Una serie de articulos detallando el proceso de Upgrade a vCenter Server 5.0

Upgrade a ESXi 5.0

Una serie de articulos detallando el proceso de Upgrade a ESXi 5.0

Instalación de ESXi 5.0

Una serie de articulos detallando el proceso de Instalación de ESXi 5.0

Configuración iSCSI en vSphere 5.0

Una serie de articulos dedicados a la configuración de iSCSI en vSphere 5.0

Reconocido como vExpert 2011

Reconocido como vExpert 2011

VMware View 4.5

Una serie de articulos dedicados a View 4.5 y todas sus nuevas funcionalidades.

VMware View Transfer Server 4.5

Una serie de articulos dedicados a View Transfer Server y sus caracteristicas.

VMware View Composer 2.5

Una serie de articulos dedicados a View Composer y sus caracteristicas.

Cluster MSCS Across Boxes en vSphere 4.1

Serie de articulos detallando el proceso de creación y configuración de un cluster MSCS en configuración Across Boxes en vSphere 4.1

sábado, 28 de mayo de 2011

Vmware vSphere: Optimización de uso de memoria

Hola a todos,

En este articulo profundizaremos en las distintas tecnicas que utiliza VMware para optimizar el uso de memoria.

VMware tiene funcionalidades que permiten sobreaprovisionar los recursos de memoria, o sea asignar más memoria de la que realmente existe en nuestros hosts ESX/ESXi.

La administración de memoria es uno de los puntos más destacados en VMware, y donde se diferencia fuertemente de su competencia. Al mismo tiempo, el sobreaprovisionamiento de recursos es una de las razones de que la virtualizacion pueda utilizar el hardware de manera más eficiente que los servidores fisicos.
Esta administración de memoria esta basada en el hecho de que no todas las máquinas virtuales utilizan completamente su memoria RAM asignada en todo momento.

Al estar libre la memoria, el hypervisor podria hacer uso de esta memoria para distribuirla entre las máquinas virtuales que más lo necesitan.

Administración de Memoria

VMware utiliza una serie de metodos para administrar la memoria, los cuales detallaremos a continuación, en el orden en que estos son aplicados:

Transparent Page Sharing


Transparent Page Sharing, o TPS, es el proceso de eliminar los bloques de memoria identicos, remplazandolos con apuntadores logicos a una unica copia. El proceso es similar a como los productos de almacenamiento utilizan la deduplicación para disminuir los costos de almacenamiento.

El uso de TPS permite reducir el uso de la memoria en los hosts, y por lo tanto nos da la posibilidad de consolidar más maquinas virtuales en un host. TPS no compara cada byte, sino que usa un hash de cada pagina de 4KB para identificar paginas que necesiten una revisión más precisa. Estas ultimas son finalmente comparadas para confirmar si son identicas, luego de lo cual se eliminan todas las paginas duplicadas, dejando solo uno en memoria, creando los apuntadores logicos respectivos.

Todo este proceso es totalmente transparente para las máquinas virtuales, las cuales no son concientes de que esta compartiendo paginas de memoria.

Finalmente, TPS solo considera las paginas de memoria de 4KB, ya que es muy poco probable encontrar paginas de memoria de 2MB que sean identicas, sumado al hecho de que su escaneo es más costoso en termino de uso de recursos.

Ballooning



Cuando las VMware Tools están instaladas en una máquina virtual, junto con estas se instalan un driver de un dispositivo "falso" llamado "Ballon Driver", el cual es utilizado para "inflar" la memoria utilizada. El nombre preciso para este dispositivo es "vmmemctl".

Normalmente, el hypervisor no es consciente de cuales sectores de la memoria son más importantes para la máquina virtual, y la máquina virtual no sabe si el host está sufriendo escazes de memoria.

El "Balloon Driver" es un mecanismo que el hypervisor puede utilizar para pedirle al sistema operativo de la máquina virtual, que elija que paginas de memoria pueden ser liberadas. El sistema operativo entiende cuales paginas estan siendo usadas, y para que propositos, y puede tomar la mejor decision acerca de liberar cierta cantidad de memoria, impactando lo menos posible a la performance de la máquina virtual.

Cuando el VMKernel necesita que la MV libere memoria, "infla" el "Globo" o Balloon diciendole al "Balloon Driver" que intente consumir más memoria como un proceso en el sistema operativo de la máquina virtual. El Sistema Operativo decide entonces que paginas de memoria puede liberar para asignarselas a este "proceso". Si la MV tiene mucha memoria libre, esta es entregada al "Balloon Driver", y el Driver puede decirle al hypervisor que paginas de memoria liberar. Si la MV no tiene memoria libre, el Sistema Operativo elige que paginas de memoria pasarlas a la memoria Swap usando su propio archivo de paginación (Windows) o particion Swap (Linux). Luego de esto, el hypervisor puede hacer uso completo de la memoria recolectada con el Balloon Driver, pudiendo esta ser traspasada a otra máquina virtual que requiera más memoria.

El proceso de Ballooning traspasa las restricciones de memoria del host al sistema operativo de la MV, la cual puede tomar mejores decisiones acerca de que paginas debieran ser mantenidas en la RAM, y cuales en disco (Swap).

Por defecto el Balloon Driver solo trata de liberar un maximo de 65% de la memoria asignada a la MV. El sistema operativo debe tener un archivo de paginación o particion Swap al menos del mismo tamaño de la memoria RAM asignada.

Compresion


vSphere 4.1 incluye un algoritmo de compresion de memoria, que analiza cada pagina de 4KB y determina si puede ser comprimida al menos a un tamaño de 2KB. Si la pagina no puede ser comprimida a dicho tamaño, la pagina queda marcada para ser pasada al archivo Swap de la MV (a nivel de VMware), si es que asi se requiere.

Cuando la MV necesita acceso a la pagina nuevamente, la pagina es descomprimida nuevamente y entregada a la memoria de la MV. A pesar de la latencia, y la sobrecarga de CPU inherente al proceso de comprimir y descomprimir las paginas de memoria, es una tecnica considerablemente más eficiente que el Swapping de la memoria en disco.

Por defecto el caché de compresion de memoria esta limitado al 10% de la memoria de la MV. Cuando el caché esta lleno, reemplaza las paginas comprimidas en orden de antiguedad, las paginas más antiguas son descomprimidas y enviadas a la memoria Swap, dejando espacio libre en el Caché para paginas más nuevas y utilizadas más frecuentemente.

Swapping


Cuando una MV es encendida, el hypervisor crea un archivo de Swap en el directorio de la MV, con la extension .vswp. Este es utilizado como un ultimo recurso para que el hypervisor libere memoria RAM adicional, cuando el host esta bajo un uso intenso de los recursos de memoria.

El VMkernel obliga a que ciertas paginas de memoria sean movidas desde la memoria RAM al disco, pero a diferencia del Balloon Driver, no puede apoyarse en la administración de memoria del sistema operativo de la MV, y envia paginas de memoria al archivo Swap en forma aleatoria.

El Swapping de memoria produce una degradación importante en la performance, debido a que el proceso no es selectivo, y sin lugar a dudas moverá paginas activas de memoria al archivo Swap. Adicionalmente, el procesos de Swapping impacta a la performance del host, ya que aumenta el uso de CPU para procesar el swapping de memoria.

Cuando es reclamada la memoria?

La memoria es reclamada solamente desde la memoria No Reservada.

Cada MV espa configurada con una cantidad de memoria. Si no hay ninguna reservacion de memoria configurada, entonces cuando la MV se encuentre encendida, el archivo .vswp es creado del mismo tamaño que la memoria asignada a la MV. Por ejemplo, si una MV tiene asignada 4GB de memoria, y no tiene reservaciones configuradas, el archivo .vswp de la MV es creado con un tamaño de 4GB.

Cualquier reservacion de memoria reduce el tamaño del archivo de Swap, ya que la memoria reservada esta siempre asegurada por la memoria fisica del host, y nunca será reclamada ante escazes de memoria. Esta es memoria garantizada y por lo tanto nunca será enviada a Swap por el host.

Por ejemplo, en una MV con 4GB de memoria asignada, con una reserva de 2GB, el archivo .vswp de la MV es creado con un tamaño de 2GB, que corresponde a la diferencia entre la memoria asignada y la reservada.

Los Shares de las MV solo aplican a la memoria asignada que no se encuentre reservada. La memoria fisica que recibe la MV, depende de su reservación de memoria, de cuanta memoria libre tenga el host, y la asignación de Shares entre todas las MVs.

Orden de aplicación de las tecnicas de administración de memoria.

El uso de las tecnicas de reclamacion de memoria detalladas anteriormente depende de la cantidad de memoria libre que tenga el host en determinado momento.

Algunos procesos se ejecutan en forma permanente, mientras que otros son activades cuando se alcanzan ciertos umbrales de memoria disponible.

Transparent Page Sharing se ejecuta constantemente, incluso cuando no existe contención de memoria en el host. Por defecto el host escanea cada 60 minutos para encontrar paginas redundantes. Una excepción es cuando se enciende una MV Windows, debido a que el Sistema Operativo chequea toda su memoria durante el encendido, por lo que TPS se ejecuta inmediatamente sobre esa MV, y no espera hasta el proximo ciclo.
  • Al llegar a un uso de memoria de un 94% (Estado High), el Hypervisor ejecuta el proceso de TPS inmediatamente. Idealmente esto logra que el uso de memoria del host baje de este umbral.
  • Al llegar a un uso de memoria de un 96% (Estado Soft), se activa el Ballooning, tratando de obtener memoria desde las máquinas virtuales, intentando que el uso de memoria del host baje del umbral del Estado High (94%).
  • Al llegar a un uso de memoria de un 98% (Estado Hard), el host comienza a forzar a que ciertas paginas de memoria sean enviadas desde la RAM al archivo de Swap. A la vez, el proceso de compresión de memoria comienza a trabajar, intentando reducir la cantidad de memoria que está siendo enviada al archivo Swap. Adicionalmente, las paginas largas de memoria (de 2MB), son divididas en paginas regulares de 4KB, para que ellas puedan ser compartidas utilizando TPS, evitando en lo posible que estas sean enviadas al archivo Swap.
  • Al llegar a un uso de memoria de un 99% (Estado Low), el host deja de crear nuevas paginas de memoria para las MVs y continua comprimiendo y haciendo Swapping de memoria, hasta que la memoria sea liberada y el host se recupere.


Espero que este articulo les haya sido de utilidad, y les haya ayudado a entender mejor las tecnicas de administración de memoria en vSphere.

miércoles, 25 de mayo de 2011

VCP-DT: Abiertas las inscripciones para el Examen





Finalmente se encuentran abiertas las inscripciones para el examen VMware Certified Professional 4 - Desktop (VCP-DT).

Los curso recomendados, pero NO obligatorios, para este examen son los siguientes:



Pueden descargar el Blueprint desde el siguiente link:
http://mylearn.vmware.com/register.cfm?course=93653&ui=www_cert


Pueden encontrar tambien un examen Mock para ir viendo el tipo de preguntas con las que nos encontraremos en el examen.

Mayor información en el sitio  VMware Education.  Antes de realizar la inscripción del examen, se debe requerir una autorización de VMware, la cual se obtiene desde el siguiente link:
http://mylearn.vmware.com/feedback.cfm?survey=24312


Una vez obtenida la autorización, se puede realizar la inscripción correspondiente a través de Pearson Vue.



lunes, 23 de mayo de 2011

VMware vSphere 4.1: Soporte NUMA

Hola que tal,

En este articulo hablaremos un poco acerca de lo que es el soporte NUMA (non-uniform memory access) en vSphere 4.1. En arquitecturas de servidores que soporten NUMA, vSphere 4.1 soporta la optimización de acceso a memoria para procesadores Intel Nehalem y AMD Opteron.

Cuando logramos entender como se realiza la programacion NUMA en vSphere, y como funciona el algoritmo NUMA de VMware, es posible utilizar este conocimiento para optimizar la performance de las maquinas virtuales.

Que es NUMA?

Los sistemas NUMA son plataformas avanzadas de servidores con más de un bus de sistema, que permite un mejor aprovechamiento de un gran numero de procesadores en un unico servidor.



Antes de existir los nodos NUMA, una CPU de gran capacidad necesitaba ser provista de un gran ancho de banda de memoria, para poder usar su poder de procesamiento de forma efectiva. Esto era aplicable tanto en equipos con un solo procesador, como en equipos con multiples procesadores. De hecho en sistemas con múltiples procesadores este problema tenia un impacto potencialmente mayor, ya que muchos procesadores debían competir por el ancho de banda en el mismo bus de sistema.

NUMA apareció como un enfoque alternativo que conecta varios nodos pequeños, utilizando conexiones de alta performance. Cada nodo contiene procesadores y memoria (formando un nodo NUMA), como un pequeño sistema multiprocesador (SMP). Adicionalmente, un controlador avanzado de memoria permite a un nodo usar memoria de todos los otros nodos, creando una unica imagen de sistema.

Cuando un procesador accede a memoria que no se encuentra en su mismo nodo (memoria remota), la data debe ser transferida sobre la conexión NUMA, lo cual es más lento que acceder a la memoria del mismo nodo (memoria local), ya que las instrucciones tienen que atravezar el link de interconexion, lo cual introduce un salto adicional en la conexion, introduciendo una mayor latencia en la comunicacion. El tiempo de acceso a la memoria no es uniforme y depende de la ubicación de la memoria, y del nodo desde el cual se accede.



Como funciona NUMA en ESX/ESXi

vSphere utiliza un programador NUMA sofisticado para balancear dinamicamente la carga del procesador y la asignacion de memoria:
  • Cada MV administrada por el programador NUMA es asignada a un "Nodo Home". El Nodo Home es uno de los nodos NUMA, conteniendo procesadores y memoria local.
  • Cuando la memoria es asignada a una MV, el host ESX/ESXi preferentemente la asigna dentro del "Nodo Home".
  • El programador NUMA puede cambiar dinamicamente el "Nodo Home" de una VM para responder a cambios en la carga del sistema. El programador podria migrar una MV a un nuevo "Nodo Home" para reducir la carga de un procesador que no esté balanceado. Adicionalmente, el programador muede migrar dinamicamente la memoria de la MV a su nuevo "Nodo Home" para proveer de memoria local.


Algunas MV no son administradas por el programador NUMA, por ejemplo cuando se configura manualmente la afinidad de CPU en una MV. Las MV que no son gestionadas por el programador NUMA, aun puedes ejecutarse correctamente, sin embargo no se benefician de la optimizacion NUMA.
La optimizacion NUMA funciona sin problemas, sin importar el tipo de sistema operativo que utilice la MV. De hecho, vSphere provee de soporte NUMA incluso para MV que no soporten hardware NUMA, como Windows NT 4.0. Esto permite aprovechar las funcionalidades del nuevo hardware, incluso con sistemas operativos legacy.

Una MV que tiene mas vCPU que el numero de cores fisicos disponibles en un unico nodo NUMA, tambien puede ser gestionada automaticamente. El programador NUMA acomoda dicha MV utilizando nodos NUMA expandidos. La MV es dividida en multiples clientes NUMA, cada uno de los cuales es asignado a un nodo NUMA y administrados por el programador NUMA en forma normal.




Esto puede mejorar la performance de ciertas MV con cargas de trabajo intensivas en el uso de memoria, manteniendo la asignación de memoria local en lo posible. En vez de asignar paginas de memoria aleatoreas, la memoria es asignada desde los nodos NUMA en que la MV se está ejecutando.


Asignación Inicial de Nodo Home

Cuando una MV es encendida, el host le asigna un Nodo Home. Una MV corre solo sobre procesadores dentro de su Nodo Home, y la memoria asignada tambien viene de dicho Nodo Home.

Adicionalmente, y en caso de que la MV utilice más vCPU que los cores existentes en un nodo NUMA, el programador NUMA determina el numero de clientes NUMA que necesitan ser creados para que cada uno de estos resida dentro de un nodo NUMA.

Las MV nuevas son inicialmente asignadas a un Nodo Home de una forma similar a Round Robin, donde la primera MV va al primer nodo, la segunda MV va al segundo nodo, etc. Esto asegura que la capacidad de procesamiento es siempre utilizada en todos los nodos del sistema.

De todas maneras, la asignacion inicial no es suficiente para garantizar una buena performance y un buen balanceo de carga en el tiempo. Por ejemplo, el uso de recursos de una MV en un nodo, con el tiempo puede aumentar llegando ser muy superior al uso de recursos de las MV en otro nodo NUMA. Esto no es balanceado con la asignacion inicial del Nodo Home.


Balanceo de Carga Dinamico

ESX/ESXi combina la asignacion inicial del Nodo Home con un algoritmo de rebalanceo dinamico. Periodicamente (por defecto cada dos segundos), el sistema examina las cargas de los distintos nodos NUMA y determina si debiera rebalancear la carga moviendo una MV de un nodo a otro. Este calculo siempre toma en cuenta la configuracion de recursos de una MV y Resource Pools para mejorar la performance respetando los recursos asignados.

El algoritmo selecciona una MV apropiada y cambia su Nodo Home, al nodo menos utilizado. Adicionalmente, el algoritmo mueve la memoria asignada a la MV al nodo de destino. De aqui en adelante, la MV asigna memoria de su nuevo Nodo Home y se ejecuta solo en procesadores dentro de su nuevo Nodo home.

El rebalanceo es una solucion efectiva para asegurarse de que todos los nodos estan siendo utilizados de manera equitativa y eficiente.

Adicionalmente, el algoritmo de migracion de memoria tambien se asegura que el host ESX/ESXi no mueva memoria que no sea necesaria si una MV es movida a un nuevo nodo solo por un periodo corto de tiempo.

Con la asignación inicial, el balanceo dinamico, y la migración inteligente de memoria trabajando en conjunto, es posible asegurar una buena performance en sistemas NUMA, incluso cuando existen cambios en la carga de trabajo. Cuando se produce un cambio de carga de trabajo mayor, como cuando nuevas MV son encendidas, el sistema se toma un tiempo para reajustar la carga, migrando MV y memoria a nuevos nodos. Despues de algunos segundos o minutos, el sistema completa el rebalanceo.

Transparente Page Sharing optimizado para NUMA.

Muchas cargas de trabajo de ESX/ESXi presentan oportunidades para compartir memoria entre MV. Por ejemplo, si varias MV están ejecutando una instancia del mismo sistema operativo, tienen las mismas aplicaciones o componentes cargados, o contienen datos en comun. En tales casos vSphere utiliza una tecnica de TPS propietaria, que elimina las copias redundantes de paginas de memoria.



Con la memoria compartida, una MV frecuentemente utiliza menos memoria de la que utilizaría cuando se ejecuta en un equipo fisico. Por lo anterior, vSphere puede soportar en forma eficiente altos niveles de sobre-aprovisionamiento (overcommintment).

TPS para ESX/ESXi tambien ha sido optimizado para su uso en sistemas NUMA. En sistemas NUMA, las paginas son compartidas por nodo NUMA, por lo que cada nodo tiene sus propias copias locales de paginas compartidas.

Paginas compartidas entre nodos NUMA

La opcion VMkernel.Boot.sharePerNode controla si las paginas de memoria pueden ser compartidas solo dentro de un unico nodo NUMA, o a traves de multiples nodos NUMA.

Por defecto, esta opcion está activada, por lo que las paginas identicas son solo compartidas dentro del mismo nodo NUMA. Esto mejora la asignacion de memoria local, debido a que todas las MV que utilizan paginas compartidas utilizan solo memoria local.

Si se desactiva esta opcion, las paginas identicas pueden ser compartidas entre diferentes nodos NUMA. Esto aumenta la cantidad de paginas compartidas, lo cual reduce el consumo de memoria global, pero no se beneficia de forma eficiente del uso de memoria local. Esta opción puede ser de utilidad en ambientes con limitaciones de memoria.

NUMA y Hyper-Threading

El programador de CPU en un sistema NUMA ignora Hyper-Threading, contando solamente el numero de cores disponibles por nodo NUMA. En una CPU Nehalem Quadcore con HT habilitado, se pueden contar 8 Threads y 4 Cores, sin embargo el programador NUMA contará solamente 4 cores.


Espero que les sea de utilidad.  Cualquier duda me pueden realizar todas las consultas que estimen.

lunes, 9 de mayo de 2011

VMware vSphere: Que tipo de disco utilizar en nuestra VM?



Antes de crear una máquina virtual debemos decidir el tipo de discos que utilizaremos, y esta decición dependerá de los requerimientos especificos de cada máquina virtual.

Disco RDM o VMDK?
Para la mayoría de los casos se recomienda utilizar discos virtuales VMDK, a menos que exista una necesidad especifica, como crear un Cluster MSCS, que requiera el uso de discos RDM.

  • Los discos VMDK son más portables
  • Los discos VMDK son más faciles de redimensionar.
  • Hay menos complejidad administrativa con discos VMDK.
  • Los discos VMDK son más faciles de respaldar y recuperar.
  • Es más sencillo clonar MV con discos VMDK.
  • Facilidad para el uso de Snapshots.


Tanto los discos VMDK como los discos RDM tienen caracteristicas similares de performance, por lo que esto no debiera ser un factor relevante a la hora de definir el tipo de discos a utilizar.  Para una comparación de performance pueden revisar el withepaper "Performance Characterization of VMFS and RDM Using a SAN".

En que casos podemos necesitar utilizar discos RDM?

  • Para configurar un Cluster MSCS en una configuración Cluster Across Boxes.
  • Para configurar una MV para usar NPort ID Virtualization (NPIV)
  • Para utilizar herramientas de administración nativas de un Storage SAN.  Por ejemplo, realizar Snapshots a nivel de Storage, Replicación  a nivel de Storage, etc.
  • Si requerimos adjuntar una LUN existente a una MV, sin que esta sea formateada como un Datastore VMFS.  Por ejemplo, adjuntar la LUN de un FileServer.  Esto puede ser de utilidad con el fin de evitar además la migración de grandes volumenes de datos a un disco VMDK durante una conversión P2V.
  • Para eliminar potenciales problemas de compatibilidad o permitir que las aplicaciones se ejecuten en un ambiente virtualizado sin perder ninguna funcionalidad.
  • Para ejecutar Software de administración de SAN desde la MV, y este tiene impacto directo en la LUN.


RDM en Compatibilidad Virtual o Fisica?


En caso de decidir utilizar discos RDM, se debe decidir además si utilizar el modo de Compatibilidad Virtual o el modo de Compatibilidad Física.


  • Modo de Compatibilidad Virtual: Este modo virtualiza completamente el dispositivo adjunto, el cual aparece en  la máquina virtual como un disco virtual de un volumen VMFS.  Este modo provee de los beneficios de VMFS, como la protección de datos y el uso de Snapshots.
  • Modo de Compatibilidad Física: Este modo provee de acceso a la mayoria de las caracteristicas de hardware del dispositivo adjunto.  VMKernel pasa todos los comandos SCSI al dispositivo, exponiendo de este modo todas las características fisicas del hardware subyacente.


El modo de Compatibilidad virtual es el recomendado para la mayoría de los casos, a menos que se requiera explícitamente el uso de la compatibilidad fisica.  Por ejemplo, en un Failover Cluster Microsoft sobre Windows Server 2008, se requiere Persistent Group Reservation (PGR) SCSI-3, la cual es solo disponible utilizando RDM en modo de compatibilidad física.

Al utilizar discos RDM en modo de compatibilidad fisica debemos considerar que habrá una serie de funcionalidades que ya no se encontrarán disponibles:

  • Snapshots.  Esto en particular puede ser muy critico, considerando que muchas soluciones de respaldo, como vDR requieren del uso de Snapshots.
  • vMotion; No es posible mover con vMotion una MV con RDM en Compatibilidad Física.
  • Clonado de MV con RDM en compatibilidad fisica.
  • No es posible convertir una MV con discos RDM en un Template.


Al utilizar discos RDM en modo de compatibilidad virtual se pueden superar casi todas estas limitaciones, permitiendo el uso de vMotion, Snapshots y Clonado de VM.

Disco Virtual con Thin o Thick Provisioning?



Cuando se crea un disco virtual en VMware, por defecto el tipo a utilizar es Thick.  Un disco Thick reserva todo el espacio especificado durante la creación del disco, utilizandolo efectivamente en el Datastore.

Un disco Thin no realiza una reserva previa de todo el espacio asignado durante la creación del disco.  Los bloques en el archivo VMDK no son reservados en el Storage fisico hasta que ellos son escritos durante el curso normal de su operación.

Un detalle completo de los discos Thin y Thick, con sus diferencias lo pueden encontrar en el KB 1005418.

Cada tipo de disco tiene claras ventajas y desventajas, y la decisión dependerá del uso que le daremos al disco.  Por ejemplo, si el disco será utilizado por una base de datos con muchas transacciones, se recomienda el uso de discos en formato Thick, ya que en formato Thin el disco crecería muy rapidamente, haciendo injustificado el uso de este tipo de discos.

Ventajas y Desventajas de Thick Provisioning:

  • Configuración y Monitoreo de almacenamiento más simple
  • Soporte para Fault Tolerance en VMware
  • Menos eficiente en el uso de espacio
  • Mayores costos de almacenamiento


Ventajas y Desventajas de Thin provisioning

  • Reduce el costo de almacenamiento
  • Elimina la necesidad de dedicar desde un comienzo, toda la capacidad requerida por una aplicación.
  • La fragmentación de los discos tiene efectos insignificantes en la performance del disco.
  • Thin Provisioning podria no ser lo más adecuado en ambientes donde el tamaño de los discos virtuales tendrá una rapida tasa de crecimiento.
  • Thin Provisioning aumenta el riesgo de quedarse sin espacio en un Datastore.  Este riesgo puede ser mitigado usando alarmas y reportes de Storage.
  • Se deben monitorear y crear alarmas apropiadas.



Nota: El uso combinado de Thin Provisioning basado en Storage y en el VMkernel esta bien, mientras se administre correctamente para evitar quedarse sin espacio en disco.

Espero les haya sido de utilidad!

miércoles, 4 de mayo de 2011

Herramientas Healt Check para VMware

Hola a todos,

En este articulo mostraremos algunas herramientas que nos pueden ser útiles a la hora de realizar un Health Check en nuestra plataforma VMware, o en la de algún cliente.

VMware Compliance Checker
Esta es una nueva herramienta de VMware, totalmente gratuita, que nos permite realizar un assessment o evaluación de nuestra plataforma VMware vSphere, utilizando como base las mejores practicas existentes.

Esta es una herramienta instalable basada en Windows que genera reportes en formato HTML.  La limitación de este informe es que solo puede generar reportes de 5 hosts a la vez.   De las herramientas que veremos en este post, es la más limitada de todas.



Un reporte más completo de esta herramienta lo pueden encontrar en el siguiente link:
http://www.patriciocerda.com/2011/04/best-practices-con-vmware-compliance.html

RVTools

RVTools es una aplicación basada en .Net que muestra información acerca de los hosts ESX/ESXi y Maquinas Virtuales.
Es compatible con VI 3.x y vSphere 4.x, asi como con VirtualCenter 2.5 y vCenter 4.x.

Esta herramienta es de muy facil uso, solo siendo necesario ingresar la dirección de nuestro vCenter o host ESX/ESXi, y las credenciales respectivas.

Esta herramienta muestra un completo inventario de las vCPU, Memoria, Discos, Snaptshots, VMware Tools, Datastores, entre otra información que puede ser de utilidad.



Adicionalmente, esta herramienta incluye una sección que realiza un Health Check de la plataforma, indicando los puntos en que se debe revisar, como archivos huerfanos, VMware tools sin actualizar, o MV sin VMware Tools, etc.



Los resultados de esta herramienta pueden ser exportados en formato Excel.  Para descargar esta herramienta, solo deben ingresar al sitio http://www.robware.net/.  Esta es una excelente herramienta, muy fácil de utilizar y que entrega mucha información de utilidad.


VMware vSphere Health Check Report

Por ultimo contamos con VMware vSphere Health Check Report, que permite realizar un completo levantamiento y Health Check de nuestra plataforma.

Esta herramienta es basicamente un Script que requiere vSphere SDK for Perl o la vMA 4.x, para poder ejecutarla.

La ejecución es bastante sencilla, y es posible personalizarla de acuerdo a nuestros requerimientos.



El script nos entrega un reporte muy completo en formato HTML, que nos permite ver completa información de nuestra plataforma VMware vSphere, separando la información en Cluster, Host y Virtual Machines.

  

  



Esta herramienta la pueden descargar desde el siguiente link, donde encontrarán además información detallada para su uso.
http://communities.vmware.com/docs/DOC-9842

Conclusión
De las tres herramientas, por facilidad de uso e información entregada, recomiendo RVTools.  Sin embargo, si se animan con "VMware vSphere Health Check Report", pueden obtener un reporte aún más completo, dependiendo de sus necesidades.

lunes, 2 de mayo de 2011

VMware VCA4-DT: Mi experiencia en el examen... APROBADO!



El pasado viernes 29 de Abril, y a poco más de 1 semana de que se abrieron las inscripciones, rendí el examen de certificación VMware Certified Associate - Desktop (VCA-DT).

Este es el primero de 3 exámenes que VMware ha diseñado para certificar a los profesionales con conocimiento y experiencia en soluciones de virtualizacion de escritorio VMware.

Debido al acuerdo NDA que uno acepta antes de tomar el examen, no hay mucho que yo pueda detallar respecto al contenido del examen, pero intentaré detallar mis impresiones respecto a este examen, y recomendaciones a quienes quieren darlo.

Este examen en particular es el más "básico" de los tres que ha diseñado VMware, donde el examen se centra principalmente en la Administración y Troubleshooting de una plataforma VMware View, dejando de lado la Instalación y Configuración.  Debido a esto, les puedo recomendar que se concentren especialmente en la guía de Administración de VMware View, que incluye además el material necesario sobre ThinApp que requerirán durante el examen.

Si bien el examen no es tan duro en comparación a los otros examenes VMware que he dado, definitivamente no es facil ni hay que tomarselo a la ligera.  Son 70 preguntas y 2 horas para completarlas (al menos para quienes estamos en un país de habla hispana), mientras yo utilicé poco más de 1 hora para terminar y revisar aquellas preguntas en las que tuve ciertas dudas.

Mi puntaje fue bastante aceptable considerando que solo tuve una semana de preparación, por lo que principalmente me apoye en mi experiencia previa para superar el examen con éxito.



Para quienes quieran ir por esta certificación, no se requiere obligatoriamente asistir a un curso, pero VMware recomienda asistir a uno de los siguientes:



Yo asistí al curso VMware View Install, Configure, Manage, y se los recomiendo completamente, ya que cubre todos los objetivos incluidos en el Blueprint del examen.

Para quienes quieran probar sus conocimientos antes de ir al examen, VMware ha publicado un Mock Exam que nos permite ver en que nivel estamos.

Para registrar el examen, deben realizarlo a través de Pearson Vue, y el examen tiene un valor de US$ 125

Espero que se animen a dar este examen, yo por mi parte estoy esperando que se abran los registros para el examen VCP-DT!