vSphere 5: What's New!

Hola a todos!

Con el reciente lanzamiento de vSphere 5.0, se han hecho publicas las principales novedades que vienen incluidas en el nuevo Hypervisor de VMware

vSphere 5 es considerado ahora como una parte integral de la Infrastructure Cloud, la cual cuenta con los siguientes componentes:

• vSphere 5: Infraestructura Base
• SRM 5: Continuidad de negocios
• vCenter Operations: Monitoreo y Administración
• vShield 5: Seguridad
• vCloud Director 1.5: Auto servicio 

A continuación un detalle de lo nuevo que viene en vSphere 5.0

MEJORAS EN LA PLATAFORMA

Convergencia
Como ya se habia mencionado anteriormente de manera oficial, esta nueva versión solo incluye a ESXi como unico hypervisor coporativo de VMware.
Del mismo modo se señala que vCenter Server 5.0 será capaz de administrar hosts ESXi 5.0, asi como ESX/ESXi 3.5 y ESX/ESXi 4.x

vSphere Auto Deploy
Combinando funcionalidades de Host Profiles, Image Builder y PXE, vSphere Auto Deploy simplifica las tareas de instalación y actualización de cientos de hosts ESXi. De esta manera, los nuevos hosts son automaticamente instalados basados en reglas definidas por el usuario. Del mismo modo, reconstruir un host a un estado "limpio" es tán simple como un Reboot.

Framework CLI unificado
vSphre 5 ofrece un framwork expandido y mejorado que incluye un basto conjunto de comandos (esxcli) consistentes y extensibles, incluyendo nuevos comandos para facilitar el troubleshooting y mantenimiento de los hosts. Este framework permite consistencia en la autenticación, roles y auditoria, usando los mismos metodos de otros frameworks de administración, tal como vCenter Server y PowerCLI. Este framework es posible utilizarlo remotamente como parte de vSphere CLI, asi como tambien de forma local en la shell de ESXi (hasta ahora conocida como Tech Support Mode).

Nuevas capacidades de las Virtual Machines:
vSphere 5.0 introduce una nueva generación de hardware virtual con su versión 8, la cual incluye las siguientes características:

• Hasta 32 vCPU por VM
• Hasta 1TB de memoria RAM por VM
• Soporte para graficos 3D para ejecutar Windows Aero y aplicaciones basicas 3D en las VMs.
• Soporte de dispositivos USB 3.0. Se soportan dispositivos USB 3.0 atachados al equipo que ejecuta vSphere Web Client o vSphere Client, para que esto puedas ser conectados a una MV. Por ahora no está soportado la conexión de dispositivos USB 3.0 directamente en los hosts ESXi.

Interfaz grafica para configurar vCPU multicores
Ahora se puede configurar el numero de cores por vCPU en las propiedades de las máquinas virtuales, utilizando vSphere Web Client y vSphere Client. En vSphere 4.x esta caracteristica era posible configurarla solo a traves de las configuraciones avanzadas.

Soporte de lector de Smart-Card para maquinas virtuales.
Permite conectar SmartCard readers al computador que está ejecutando vSphere Web Client y vSphere Client, las que son conectadas a una o más máquinas virtuales.

Soporte de VMware Tools expandido
Donde las VMware Tools de vSphere 4.x son soportadas en MV que se ejecutan en hosts ESXi 5.0. Del mismo modo, la versión de VMware Tools provistas con vSphere 5.0 son también compatibles con ESX/ESXi 4.x.

Soporte para Apple Mac OS X Server:
vSphere 5.0 agrega soporte para Apple Mac OS X Server 10.6 (Snow Leopard), como sistema operativo de maquina virtual.

Soporte de hasta 512 MV por host.


Soporte de hasta 160 Cores y 2TB de RAM por host.


STORAGE

Storage DRS:
Como ya se habia anunciado previamente en el VMware Partner Exchange 2011, vSphere 5.0 incluye una caracteristica llamada Storage DRS.

Esta nueva funcionalidad permite automatizar la ubicación inicial de una MV y evita los cuellos de botella en el Storage.

Es posible agrupar y administrar datastores similares como un unico recurso balanceado llamado Datastore Cluster. Storage DRS realiza la ubicación inicial de los archivos VMDK y recomendaciones de migraciones para evitar cuellos de botella de I/O y utilización de espacio.

Asignación de almacenamiento por Politicas
Esta solución permite un mayor control y mayor visibilidad de las caracteristicas de los recursos de almacenamiento. Tambien permite que la provisión de almacenamiento de las máquinas virtuales llegue a ser independiente del Storage especifico disponible en el ambiente. Se pueden definir reglas de ubicación inicial de máquinas virtuales en terminos de caracteristicas de almacenamiento.

Nueva version de VMFS:
VMFS5, una nueva versión del sistema de archivos para maquinas virtuales, que ofrece escalabilidad y performance mejorada.

Virtual Storage Apliance 
Appliance virtual para almacenamiento de bajo costo en Clusters VMware, sin el costo y complejidad de una almacenamiento compartido tradicional.

Soporte iSCSI utilizando la interfaz de usuario.
Mejoras en la usabilidad que incluye la posibilidad de configurar los adaptadores iSCSI, junto con la configuración de red y Port Binging utilizando el vSphere Client. Hasta ahora algunas de las configuraciones debian realizarse utilizando la interfaz de linea de comandos (CLI).

Soporte de Storage I/O Control para NFS.
vSphere 5.0 extiende Storage I/O Control (SIOC) para proveer de shares y limites de I/O para datastores NFS.

vSphere 5.0 provee soporte para datastores VMFS de un tamaño mayor a los 2TB.

Storage vMotion con soporte de Snapshots
Permite realizar Storage vMotion de máquinas virtuales que tengan Snapshots.


NETWORKING
Firewall de ESXi
ESXi cuenta ahora con un Firewall orientado al servicio, el cual puede ser configurado utilizando vSphere Client o CLI.  Este nuevo motor de Firewall elimina el uso de IPTables.

Mejoras en vSwitches Distribuidos.
vSphere 5.0 provee mayor visibilidad en el trafico de las máquinas virtuales a través de NetFlow, y mejora las capacidades de monitoreo y troubleshooting a traves de SPAN y LLDP.

Control de I/O de red.
Control más granular, a nivel de máquina virtual, y aplicable según SLAs.


vCENTER SERVER
vSphere Web Client
Se cuenta ahora con un vSphere Client basado en Adobe Flex, independiente de la plataforma y basado en web, con una porción de las funcionalidades disponibles en el cliente vSphere Client. vSphere 5.0 incluirá tanto el vSphere Client usual como vSphere Web Client. Las funcionalidades incluidas en el vSphere Web Client incluyen la visibilidad del inventario de vCenter, asi como la implementación y configuración de máquinas virtuales.

vCenter Server Appliance
Se contará ahora con una implementación de vCenter Server en un Virtual Appliance pre-configurado basado en Linux. Esto reduce el tiempo requerido para implementar vCenter Server y los servicios asociados y provee una alternativa de bajo costo para la implementación tradicional de vCenter Server.

Extensiones al inventario
Los clientes y Partners de VMware pueden extender vCenter Server en multiples maneras, incluyendo el inventario, la interfaz de usuario y los agentes. Se incluye un administrador para monitorear las extensiones.

vCenter Solution Manager
Provee de una interfaz para configurar y Monitorear soluciones integradas con vCenter, desarrolladas por VMware y por terceros.


DISPONIBILIDAD

vSphere High Availabilty
Se introducen Fault Domain Manager, el cual incluye mejoras en la funcionalidad HA de VMware, haciendolo más confiable y escalable, ademas de proveer un mejor Uptime. Todos los hosts en el cluster puede ser ahora nodos Primarios mientras el Cluster tambien utiliza el almacenamiento compartido como un canal para la detección de Heartbeat entre los hosts.

vSphere vMotion
Se soporta ahora la migración de virtual machines sobre enlaces de red con mayores latencias, utilizando vMotion.


Un mayor detalle de todas estas nuevas funcionalidades las pueden encontrar en el siguiente sitio:

http://www.vmware.com/products/vsphere/upgrade-center/overview.html

Pronto más detalles respecto a Site Recovery Manager 5 y vCloud Director 1.5

Read More

VMware vSphere: Recomendaciones de Configuración de HA

Hola a todos, en este articulo hablaremos acerca de configuraciones avanzadas de HA y algunas recomendaciones y buenas practicas.

En primer lugar debemos destacar que el factor más importante para que HA funcione correctamente es la comunicacion de lo que se conoce como HeartBeat.  El HeartBeat es básicamente un ping que cada host realiza contra el Default Gateway (o la IP definida en el parámetro das.isolationaddress) y contra los demás hosts en el cluster.

Respecto al diseño de red definido en nuestra plataforma VMware, hay dos aspectos fundamentales relacionados con HA, que son la redundancia de red y la resolución de nombres.

Redundancia de red

El riesgo más comun en un cluster HA es que un host sea decladado como "Aislado" o "Isolated", lo cual por defecto provoca que las MV de dicho host sean apagadas.  Este comportamiento permite que HA pueda reiniciar las MV's en otro host que se encuente funcionando correctamente.  Escenarios con puntos unicos de falla (unico switch fisico, o unica NIC fisica para administración, etc.), pueden provocar situaciones en que un host sea declarado como aislado.

Debemos esforzarnos para que nuestro diseño de red evite situaciones en que nuestros hosts puedan ser declarados como Aislados en la red.  Para esto, debemos asegurarnos de que existe una completa redundancia de la conexión a la Management Network (ESXi) o Service Console (ESX) de cada host en nuestra plataforma VMware.  Esto lo podemos lograr de 2 formas:

• Configurar más de una VMNIC (Nic Virtual) en el vSwitch que contiene la Management Network o Service Console  Este metodo utiliza NICs redudantes en una unica red.  Es significativamente más simple al momento de configurar, pero es necesario asegurar de que hay redundancia en la red física (cada NIC del Teaming está conectada a un Switch fisico distinto), con el fin de evitar un evento de aislamiento en el caso de la caída, por ejemplo, de un Switch físico.

• Agregar una segunda Management Network o Service Console en un vSwitch separado, en una subred separada.  Esta opción tiene una configuración más compleja, pero puede ofrecer mayores niveles de disponibilidad si cada vSwitch que contenga una Management Network o Service Console cuenta con al menos dos NICs en Teaming.

La Management Network o Service Console debe tener un Default Gateway que todos los hosts puedan alcanzar.  Los Hosts utilizaran este Default Gateway para decidir si se encuentra o no aislado en la red.  En caso de que la subred donde se encuentra la Management Network o Service Console no posee un Gateway, se deberia configurar el parametro avanzado de HA, das.isolationaddress (dirección de aislamiento), especificando una dirección IP que pueda ser alcanzada utilizando Ping.

Si se utiliza una segunda Management Network o Service Console en una subred separada, entonces se debe especificar una segunda dirección para aislamiento para la segunda subred con el parametro avanzado de HA, das.isolationaddress2 (Se pueden definir múltiples direcciones de aislamiento).

Si la red sufre de problemas de intermitencia, entonces se recomienda aumentar el tiempo de reacción ante falla, configurado por defecto en 15 segundos, aumentandolo con el parametro avanzado de HA das.failuredetectiontime.  Este parametro se debe manejar con precaución, ya que al extender el tiempo por defecto, cuando un host falle, habrá que esperar mucho más tiempo para que el resto de los hosts restauren las MVs.  Adicionalmente, VMware recomienda que este parametro sea configurado en 60 segundos (60000 ms) para una unica Management Network o Service Console con dos VMNICs, y al menos 20 segundos (20000 ms) si se usan dos Management Networks o Service Consoles separadas.

Por otro lado, se debe minimizar el numero de dispositivos de red entre los hosts, debido a que cada "salto" provoca pequeñas demoras o latencias en el trafico de HeartBeat.

Resolución de nombres

HA confia fuertamente en la resolución de nombres, por lo que cada host debe tener acceso a servidores DNS correctamente configurados, donde todos los hosts tengan registros hosts (A) que puedan ser resueltos por cada host.  Se recomienda evitar el uso del archivo host local para la resolución de nombres, debido a que estos son propensos a errores, y su administración en Cluster cada vez más grandes se vuelve inmanejable con el tiempo.

Se recomienda fuertemente que el servicio de DNS sea redundante, para evitar falsos positivos en HA que puedan provocar un failover.

Recomendaciones adicionales

Adicionalmente a lo ya expuesto, se especifican las siguientes recomendaciones:

• Si se realizará alguna tarea de mantención en los dispositivos de red utilizados por los hosts ESX/ESXi en un cluster HA, o se realizará algun trabajo sobre la configuración de red de los hosts, se debiera deshabilitar temporalmente el monitoreo de los hosts en la configuración del Cluster, con el fin de evitar falsos positivos y posibles operaciones de failover.

• Personalizar la política de reinicio de las máquinas virtuales según las necesidades existentes.  Esto mejora las opciones de que los servidores más críticos sean reiniciados exitosamente si el control de admisión no se encuentra habilitado, o si los recursos restantes luego de un evento de HA no son suficientes para encender todas las máquinas virtuales.
• Configurar alarmas en vCenter, con una advertencia por e-mail, que alerte cuando se ha producido un evento de HA.
• Respecto a puertos utilizados por HA, los siguientes puertos deben estar abiertos entre todos los hosts del mismo cluster.  Cuando HA es habilitado en el cluster, estos puertos son abiertos automáticamente en el firewall de cada host, sin embargo, si existe algun dispositivo firewall (ya sea físico o virtual) entre los hosts, entonces estos deben ser configurados para que permitan el trafico por estos puertos:
• Puertos entrantes: TCP/UDP 8042-8045
• Puertos salientes: TCP/UDP 2050-2250
• Si el cluster está configurado con DRS, entonces hay que asegurarse que que todos los hosts utilicen exactamente los mismos nombres para los Port Groups utilizados por las máquinas virtuales.  Si esto no se cumple, las operaciones de vMotion fallarán.

Para más información sobre recomendaciones VMware pueden revisar el KB1006421.

Espero que esta información les haya sido de utilidad.  Saludos a todos!

Read More

VMware: Registrate para el evento "Raising the Bar, Part V"

El próximo  martes 12 de Julio se realizará un gran evento online de VMware, donde Paul Maritz y Steve Herrod, CEO y CTO de VMware respectivamente, estarán presentando la nueva generacion de la infraestructura Cloud.

El evento es totalmente gratuito y te puedes registrar en el siguiente link:
http://ow.ly/5xiiS

Adicionalmente, algunos vExperts estarán presentes cubriendo el evento en vivo.  Despues del evento habrá una sección en vivo donde será posible realizar preguntas a los expertos de VMware.

Mayor detalle en el siguiente link:
http://blogs.vmware.com/vmtn/2011/07/register-now-for-this-vmware-online-event-july-12-raising-the-bar-part-v.html

No puedes faltar a este evento!!!

Read More

VMware vSphere: Queue Depth y Latencia de Storage

Cuando uno trabaja con almacenamiento compartido, en ciertas circunstancias nos veremos en situaciones en que se presentará cierto grado de latencia en el acceso al Storage.

Esta latencia puede deberse a diversos factores.  Uno de estos factores, y sobre el cual hablaremos hoy, es del encolamiento (queuing) en los hosts ESX/ESXi y en el arreglo de Storage.

En general hay 2 tipos de encolamiento que determinan como las máquinas virtuales debieran ser distribuidas entre los hosts y datastores, asi como tambien cuantas LUNs (o volumenes VMFS) son necesarios para obtener una performance aceptable

• Encolamiento de comandos (command queueing) en el host
• Encolamiento de comandos (command queueing) en el arreglo de Storage.

Ambos tipos de encolamiento generan un aumento en la latencia

Encolamiento de comandos en el Host
Los drivers de los dispositivos SCSI (como una tarjeta HBA) tienen un parametro configurable llamado LUN Queue Depth (profundidad de cola de LUN).  Este parametro determina cuantos comandos pueden estar activos al mismo tiempo en una LUN determinada.  El valor por defecto en vSphere 4.x es de 32.

El encolamiento en los hosts ESX/ESXi ocurre primero en la cola de la LUN asociada con el dispositivo SCSI. Uno o más MV en el mismo host, generando I/O a la misma LUN, deben compartir la cola de la LUN o LUN queue.

Si un host ESX/ESXi genera más comandos a una LUN que el valor configurado en el parametro LUN queue depth, los comandos que exceden este paramentro son encolados en el VMkernel, lo cual aumenta la latencia en el acceso al Storage.  Si monitoreamos la performance de nuestro host a traves de los graficos de performance, o utilizando ESXTOP/RESXTOP, veremos que aumenta la latencia del VMKernel (Kernel Latency).

Encolamiento de comandos en el Arreglo de Storage
Si multiples hosts ESX/ESXi comparten la misma LUN, los comandos SCSI a esa LUN desde todos los hosts son procesados por el mismo Storage Processor en un arreglo Activo-Pasivo, o por un grupo de Storage Processors en un arreglo Activo-Activo

Dependiendo del fabricante y del modelo del Arreglo de Storage, los Storage Processors pueden estár configuradas con una cola por LUN, o podria haber una cola por cada disco.

Si el arreglo de Storage tiene una cola por LUN, exceder este valor resultará en latencias más altas.  Si un Storage Processor no tiene una cola por LUN, envia los comandos directamente a los discos.

Sin importar de que forma esten configuradas las colas en el arreglo, un numero de hosts ESX/ESXi enviando comandos a la misma LUN compartiran la misma cola o colas en el arreglo.  Si el numero de los comandos activos a la LUN es muy alto, los comandos comienzan a ser encolados resultando en latencias más altas.  Si monitoreamos la performance de nuestro host a traves de los graficos de performance, o utilizando ESXTOP/RESXTOP, veremos que aumenta la latencia del dispositivo fisico (Physical Device Latency).

Reduciendo la latencia
Para reducir la latencia en los hosts, asegurate de que la suma de comandos activos de todas las MV, en su conjunto no excedan el valor configurado como LUN Queue Depth.  Este escenario puede evitarse de dos formas:

• Aumentando el valor de LUN Queue Depth, o mover las MV a otra LUN
• Trabajar con el administrador del Storage para asegurarse de que cada LUN está compuesta de multiples discos fisicos

Para reducir la latencia en el Arreglo de Storage, reducir el numero maximo de comandos I/O dirigidos a la LUN compartida.

• Mover las MV a otra LUN
• El numero maximo de comandos I/O que el arreglo es capaz de manejar varia de la configuración del arreglo.

Aumentar el valor de LUN Queue Depth
El parametro LUN Queue Depth determina cuantos comandos serán aceptados por la HBA y procesará por LUN.

Cuando se habla de mejorar la performance de I/O en una infraestructura virtual, una de las recomendaciones más comunes es cambiar el valor del parametro LUN Queue Depth.  No obstante, no se debe olvidar que este parametro es solo una parte del path I/O.  Cada uno de los componentes de Software y Hardware que forman los paths de I/O pueden tener un gran impacto en la performance de I/O.  Es imprescindible que se analice la infraestructura de almacenamiento como un todo, y no solo en forma individual a nivel de host ESX/ESXi.

En la mayoria de los casos, los ambientes virtuales se verán más beneficiados con un diseño balanceado de almacenamiento, en vez de cambiar los valores por defecto de las colas.   De todas maneras, habrá casos en que aun sea necesario modificar estos parametros, en casos en que un diseño adecuado no sea suficiente para obtener una buena performance de I/O.

En caso de decidir aumentar el valor del parametro LUN Queue Depth, esto puede ser de poca o ninguna utilidad si uno no configura además el parametro "Disk.SchedNumReqOutstanding".  Este parametro debiera estar alineado con el parametro Queue Depth, debido a que si el parametro "Disk.SchedNumReqOutstanding" cuenta con un valor más bajo que el parametro Queue Depth, el primer valor será el numero maximo de comandos que son emitidos simultaneamente desde el kernel de ESX/ESXi a la LUN.  Por ejemplo, si se configura el parametro Queue Depth en 64, y el parametro "Disk.SchedNumReqOutstanding" en 32, solo 32 comandos I/O serán emitidos en forma simultanea a la LUN, en vez de los 64 configurados en el parametro Queue Depth.  Se considera una buena practica mantener ambos parametros con el mismo valor.

Si se desea cambiar estos parametros, pueden revisar el KB 1267 desde el sitio de VMware, el cual contiene las instrucciones para cambiar estos parametros en HBA's QLogic y Emulex.

Read More

VMware vExpert 2011

Hoy recibi un email que sinceramente no esperaba.  Fui notificado por Jhon Troyer de VMware de mi designación como VMware vExpert 2011.

Los vExpert son personas quienes han ido más alla en sus contribuciones a la virtualizacion y a las comunidades de usuarios VMware.  Los vExperts son bloggers, autores de libros, lideres de VMUG, desarrolladores de herramientas, etc.


Un vExpert debiera demostrar conocimiento sobre soluciones VMware y sus beneficios.  Una designación vExpert no es una certificación tecnica de ningun tipo, aunque los vExperts frecuentemente tienen un gran conocimiento y experiencia, tecnica y no tecnica, acerca de la virtualización y otras areas de TI.  No se debe confundir con la certificación VCDX.


Una designación vExpert es:

• Un agradecimiento de VMware por las contribuciones a la comunidad y su ayuda a las personas en su viaje a la nube.
• Una manera en que VMware te ayuda en la evangelización y en tu carrera, con acceso a programas beta privados, licencias de productos, y reuniones exclusivas de VMware y sus Partners.
• Una manera en que VMware se comunica con su comunidad de usuarios inteligentes e innovadores.

Esta es una excelente noticia, tanto personal como profesionalmente.  Durante el año pasado participé activamente en las comunidades VMware, asi como también a traves de éste Blog, en el cual he podido compartir buena parte de lo que he ido aprendiendo durante mi experiencia en el mundo VMware.

Esta designación es una razon más para seguir aportando en la difusión de las soluciones y tecnologias VMware, tanto en las comunidades, foros y aqui en este mismo blog.  Será un esfuerzo aun mayor para merecer esta designación el proximo año...

Nuevamente muchas gracias a Jhon Troyer y a todo el equipo de VMware, pero principalmente a todos ustedes quienes visitan este Blog!

Read More

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

El pasado viernes 27 de Junio, unos dias despues de aprobar el examen VCAP-DCD, rendí el examen de certificación VMware Certified Professional - Desktop (VCP-DT).

Este es el segundo 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 bastante más complejo y desafiante que el VCA-DT, pudiendo compararse en complejidad al examen VCP.  El examen cubre aspectos de Instalación, Configuración, Administración y Troubleshooting de una plataforma VMware View 4.5 y 4.6.  Debido a esto, les puedo recomendar que se concentren especialmente en las guía de Instalación y en la guia de Administración de VMware View, que incluyen además el material necesario sobre ThinApp que requerirán durante el examen.

Como ya dije antes, el examen es bastante desafiante y definitivamente no 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).  En mi caso demore cerca de 90 minutos en terminar el examen, lo cual me dejó cerca de 30 minutos para realizar revisiones en las preguntas que haya tenido dudas.

Mi puntaje no fue tan bueno como esperaba, pero aun así fue bastante aceptable considerando que practicamente no le dediqué horas de estudio, al estar preparando el examen VCAP-DCD, 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:

VMware View: Install, Configure, Manage [V4.5]
VMware View: Desktop Fast Track [V4.5]
Application Virtualization with VMware ThinApp

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.

A pesar de que no es requisito tomar un curso previo a dar el examen, si se requiere haber aprobado satisfactoriamente las certificaciones VCP4 y VCA4-DT.

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$ 175

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

Read More

VMware VCAP4-DCD: Mi experiencia en el examen... APROBADO!

El pasado 24 de Junio, a las 12:30 horas tomé el examen VMware VCAP-DCD, en Buenos Aires, Argentina (ICANA).  En Chile aun no es posible tomar este examen, así que nuevamente me traslade a este país para dar este examen.

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 dar este examen.

A diferencia del examen VCAP-DCA, el cual era un laboratorio en vivo, el examen VCAP-DCD es un examen mayormente teorico, formado por una serie de escenarios en los cuales deberemos tomar diferentes decisiones de diseño.

En total son 113 preguntas.  Hay preguntas de selección multiple (alternativas) y preguntas drag & drop.  Adicionalmente, se presentaran ciertos escenarios, en los cuales se deberá contruir un diseño utilizando una herramienta similar a Visio, considerando una serie de requerimientos que serán dados.

Respecto a los diseños, la herramienta utilizada es bastante facil de utilizar, y el Mock-Exam disponible desde el sitio de VMware es bastante util para familiarizarte con ella.  Personalmente me preocupaba el uso de esta herramienta, y en particular los escenarios en que tuviera que utilizarla, pero en general no tuve mayores problemas para completar estos ejercicios.  Tener en consideración que cada uno de estos ejerciciós tomara de 10 a 20 minutos.

Del resto de las preguntas, la mayoria son situacionales, con una descripción bastante extensa, donde se deberán tomar diversas decisiones de diseño.  Estas descripciones muchas veces entregan más información de la que realmente se requiere.  Tener especial consideración con las preguntas drag & drop, ya que si bien no requieren tanto tiempo como la construcción de diseños con la herramienta ya mencionada, toman más tiempo que las preguntas regulares de selección multiple.

Son 225 minutos los que uno tiene para completar el examen (30 minutos extra para paises cuya lengua nativa no sea el ingles), los cuales pueden llegar a ser insuficientes para completar todas las preguntas y diseños incluidos, especialmente si uno no tiene suficiente experiencia, o no estudio lo suficiente.  

Aqui la administración del tiempo es escencial.  Uno debe evitar detenerse demasiado en una pregunta, ya que de lo contrario se perderá valioso tiempo, lo que a la larga puede provocar que no podamos responder todas las preguntas.  Yo logré terminar el examen dentro del tiempo disponible, quedandome solo 10 minutos para revisar alguna pregunta donde hayamos tenido alguna duda.  Como ya les comenté, la administración del tiempo es escencial en este examen.

A diferencia del examen VCAP-DCA, donde los resultados son enviados alrededor de 3 semanas despues, los resultados del examen VCAP-DCD son inmediatos, por lo que te ahorras la incertidumbre que produce la espera de los resultados.

Como preparación para el examen, es recomendable revisar completamente el Blueprint publicado en el sitio de VMware, el cual además entrega una serie de enlaces a distintos Withepapers y otros recursos que serán de utilidad durante el estudio.

Adicionalmente, es absolutamente recomendable asistir al curso vSphere Design Workshop.  Yo no tuve oportunidad de asistir a este curso, pero me fue posible contar con el material oficial del curso, el cual fue invaluable a la hora de estudiar para el examen.

Finalmente, un libro muy recomendado como recurso adicional de estudio, es el libro VMware vSphere Design de Scott Lowe.  Este contiene mucha información de utilidad para este examen.

Como resumen, el examen me pareció bastante desafiante y definitivamente no hay que tomárselo a la ligera.  Es util estudiar de diversos libros y cursos presenciales, pero es necesario también contar con una buena experiencia tomando decisiones basadas en requerimientos de diseño.   Es útil además tener conocimiento en Storage y Networking, lo cual puede ser de mucha ayuda en algunas preguntas del examen.

Ahora ya cuento con la certificación VCAP-DCA y VCAP-DCD.  Quizas pronto sea tiempo de intentar ir por el VCDX no?

Un saludo a todos!!!

Read More

VMware Converter: Como agregar drivers adicionales para Cold Cloning?

Hola a todos,

Aqui un pequeño tip para aquellos quienes necesiten realizar una conversión P2V utilizando Cold Cloning con el CD de Converter.

Recordar que Converter viene en dos versiones, la versión Enterprise incluida con vCenter Server, y en su versión Standalone.

Converter Enterprise permite realizar conversiones P2V tanto en caliente (Hot Cloning), como en frio (Cold Cloning), de un servidor fisico.  La conversión en frio se realiza utilizando un CD booteable que cuenta con una versión Windows PE, la cual nos permite ejecutar Converter.

Para todos los efectos, Converter deberá poder acceder a los discos del equipo fisico, asi como también a los dispositivos de red (NIC), para poder tomar una imagen de los discos y transferirla al servidor de destino.

Para esto, el CD de Converter incluye una serie de drivers, los cuales varian dependiendo de la versión de Converter que estemos utilizando.  Debido a la rapidez con la que van apareciendo nuevos servidores, con nuevos dispositivos, nos podemos encontrar con el escenario en que Converter no sea capaz de "ver" los discos y/o las interfaces de red.

Para ambos casos, VMware incluye una herramienta llamada petool.exe, la cual viene incluida en la descarga del ISO de Converter.  Esta herramienta nos permite agregar los drivers adicionales que podamos requerir para que Converter pueda reconocer los discos y las interfaces de red.

Para agregar drivers adicionales para los dispositivos de almacenamiento, se debe ejecutar el siguiente comando:

• petool.exe -i coldclone.iso -d "C:\Path_drivers\"

Para agregar drivers adicionales para las interfaces de red, se debe ejecutar el siguiente comando:

• petool.exe -i coldclone.iso -n "C:\Path_drivers\"

Por ejemplo, en mi caso tuve que agregar drivers adicionales para las interfaces de red de un servidor HP Proliant DL380 G6 al CD de Converter 3.0.3.

En primer lugar descargamos los drivers requeridos, y los descomprimimos en una carpeta.

A continuación, ingresamos por linea de comando a la carpeta donde tenemos la ISO de Converter, y la herramienta petool.exe

Finalmente, ejecutamos el comando mencionado anteriormente, con lo cual se agregarán los drivers a la ISO de converter. Para efectos de respaldo, la herramienta deja una copia de la ISO original con el nombre "coldclone.iso.bak"

Finalmente quemamos la imagen ISO en un CD, y la utilizamos para realizar la conversión P2V de nuestro servidor.

Para más información, pueden revisar el KB 1012947 desde el sitio de VMware.

Espero que les sea de utilidad, saludos a todos!

Read More