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

lunes, 25 de julio de 2011

VMware vSphere 5 /iSCSI: Upgrade de datastore a VMFS-5


Finalizando con la configuración iSCSI en vSphere 5, a continuación revisaremos los pasos para realizar el upgrade de un Datastores VMFS-3 a VMFS-5

Introducción

vSphere 5 incluye VMFS-5, una nueva versión del sistema de archivos VMware para los Datastores, que provee mejoras en la performance y escalabilidad. Entre estas mejoras podemos mencionar:
  • Soporte para LUNs de más de 2TB
  • Mejoras en la escalabilidad usandi VAAI
  • Estandarización del Block Size en 1MB para los Datastores VMFS formateados en VMFS-5
  • Sencillo proceso de Upgrade desde VMFS-3
  • Posibilidad de Montar y Desmontar Datastores a traves del vSphere Client.
Los dispositivos de almacenamiento soportados por los hosts, pueden utilizar particiones con formato MBR (Master Boot Record), o GPT ( GUID Particion Table).

Cuando se crea un nuevo datastore VMFS-5 en un dispositivo de almacenamiento en blanco, o se sobrescribe un datastore VMFS-3 existente, el dispositivo es formateado con GPT, el cual soporta tamaños mayores a 2TB, llegando incluso a los 64TB.

Los Datastores VMFS-3 continuan usando el formato MBR, por lo que estos Datastore están limitados a 2TB de capacidad, incluso si el volumen donde se está creando el Datastore, tenga una capacidad superior. Para superar esta restriccion, se debe actualizar el Datastore VMFS-3 a VMFS-5.

Antes de realizar el Upgrade, hay que asegurarse de remover cualquier particion que no sea reconocida por ESXi, como por ejemplo las particiones que utilicen el formato EXT2 o EXT3. De lo contrario, el host no podrá formatear el volumen con GPT y el Upgrade fallará.

Cuando se realiza el Upgrade de VMFS-3 a VMFS-5, el mecanismo de file-locking de ESXi se asegura que ningun proceso este accediendo al datastore VMFS que está siendo convertido. El host preserva todos los archivos del Datastore, quedando estos intactos luego del Upgrade.

El Upgrade de VMFS-3 a VMFS-5 es un proceso que no puede ser deshecho, por lo que luego que el datastore VMFS ha sido convertido a VMFS-5, este no puede ser revertido nuevamente a VMFS-3.
Pre-requisitos.
  • Para realizar un Upgrade desde VMFS-2, primero este Datastore debe ser convertido a VMFS-3, y luego a VMFS-5. Los datastores VMFS-2 no pueden ser convertidos directamente a VMFS-5
  • Si el Datastore ha sido convertido previamente de VMFS-2 a VMFS-3, se debe asegurar de que el Block Size no exceda los 8MB, de lo contrario el proceso de Upgrade a VMFS-5 no podrá llevarse a cabo.
  • Todos los hosts que tengan acceso a este datastore, deben soportar el formato VMFS-5. Esto quiere decir que los hosts deben encontrarse al menos en la versión ESXi 5.0.
  • Respaldar el volumen VMFS-3 antes de realizar el Upgrade. Como el proceso de Upgrade no puede ser revertido, este respaldo nos da un mecanismo de "vuelta atras".
  • Verificar que no hayan hosts adicionales accediendo al volumen VMFS.

Upgrade de Datastore

A continuación se detalla el proceso de Upgrade de VMFS-3 a VMFS-5.



Con esto finalizamos la serie de articulos dedicados a la configuración de almacenamiento iSCSI en vSphere 5.

viernes, 22 de julio de 2011

VMware VCP5 Beta: Mi experiencia en el examen


Hoy por primera vez tuve la oportunidad de tomar un examen Beta de VMware.  En esta ocasión pude participar de la Beta del examen VCP5, la cual me dejó bastante satisfecho.

El examen Beta (VCP511) cuenta con 180 preguntas, ademas de la traficional encuesta previa al examen.

La invitacion al examen la recibí recien el pasado 19 de Julio, dejandome solo unos dias para prepararme, considerando que el periodo para tomar este examen finalizará este 24 de Julio.  Desconozco el porque el periodo de examen Beta termina un dia domingo, ya que no conozco un centro de Pearson Vue que se encuentre abierto un fin de semana =)

Además tuve que levantarme más temprano de lo usual, ya que los unicos horarios disponibles en el sitio de Pearson para dar el examen eran a las 02hrs (dificilmente el centro de examen este abierto a dicha hora), y las 08:30.  Asi que tuve que luchar un poco para no quedarme dormido en el examen, considerando lo extenso que éste era =D

Quienes quieran dar el examen final, esté ya se encuentra disponible en el sitio de Pearson, para poder agendarlo a partir de la ultima semana de Agosto, fecha en que el examen estará disponible para todos.

Desde el sitio de VMware pueden encontrar el Blueprint para el examen.  Este Blueprint tambien se encuentra en Beta y debiera ser actualizado en las proximas semanas.

Como recurso adicional, VMware pone un Mock Exam para el VCP5, el cual nos da una pequeña muestra de este nuevo examen.  Como es costumbre, este Mock Exam es considerablemente más sencillo que el examen real, por lo que no deben confiarse con esto!

El examen tiene una duración de 225 minutos.  Imagino que el examen final considerará una reducción de este tiempo, considerando que el numero final de preguntas en el VCP5, debiera disminuir considerablemente de las 180 preguntas que figuran en el examen Beta.

Adicionalmente se consideran 15 minutos para la encuesta previa al examen, y un adicional de 30 minutos para quienes se encuentran en paises donde el Ingles no es la lengua oficial.

A pesar de la cantidad de preguntas, el tiempo disponible es más que suficiente.  Completé las 180 preguntas en poco más de 3 horas, quedandome cerca de 1 hora para revisar aquellas preguntas que me dejaron alguna duda, y para incluir ademas algun feedback en algunas preguntas, con el fin de aportar un granito de arena para mejorar el examen final.  Finalmente ese es el objetivo de dar un examen beta.

Respecto al contenido del examen no es mucho lo que puedo decir, pero si afirmar que el Blueprint cubre todos los objetivos incluidos en el examen.  Destacar además que el Blueprint es bastante extenso, por lo que no hay que tomarselo a la ligera.

Desde mi punto de vista, el VCP5 tiene un nivel de complejidad mayor al que tenia el VCP4, dejando un poco de lado (afortunadamente) las tipicas preguntas de maximos y minimos que se incluian con frecuencia en los examenes anteriores, y que en esta ocasión tiene escasa consideracion. Las preguntas no son tan sencillas de responder, y en algunos casos las preguntas y las posibles respuestas son muy ambiguas, y cuesta encontral cual sería la mejor respuesta.  Espero que esto sea mejorado al lanzarse el examen final.

En este examen se incluyen además varias preguntas sobre casos de uso, asi como escenarios en que se requieren ciertos conocimientos minimos de diseño, o al menos de buenas practicas de diseño/administración de una plataforma VMware.

Hay bastante enfasis en las mejoras incluidas en vSphere 5, pero también hay muchas preguntas más genericas que con el conocimiento previo de vSphere 4 debieran poder responder.

Es de esperar que pronto publiquen la documentación oficial de vSphere 5, la cual aun no es de acceso publico, ya que este es un recurso escencial para la preparación del examen.  Por el momento pueden acceder al documento "What's New in vSphere 5.0", disponible en el sitio de VMware

Respecto a otros recursos de preparación, ya está publicado un libro sobre vSphere 5: "VMware vSphere 5 Clustering Technical Deepdive", y se espera el lanzamiento de al menos 3 libros más sobre vSphere 5 en lo que queda del 2011.

Finalmente, respecto a los resultados... como es usual en los examenes Beta, habrá que esperar para conocer los resultados finales.  De hecho es probable que los resultados se entreguen con posterioridad a que el examen oficial se encuentre disponible =(

Tengo confianza en que haya podido obtener un puntaje aceptable, a pesar de la casi nula preparacion para el examen =)

Saludos a todos!

lunes, 18 de julio de 2011

vSphere 5: Upgrade Interactivo de ESXi 5.0


Ya hemos visto los requerimientos para realizar un Upgrade de ESXi 5.0 en el post anterior. En este post detallaremos el proceso de Upgrade interactivo de ESXi.

Introducción

Es posible ejecutar el instalador de ESXi 5.0 desde un CD/DVD o dispositivo USB para realizar un Upgrade o Migración interactiva. Este metodo es apropiado para pequeñas implementaciónes de menos de 5 hosts.
El instalado trabaja de la misma forma que una instalación nueva, pero si el disco seleccionado para la instalación ya contiene una instancia de ESX/ESXi 4.x, el instalador realiza el upgrade a ESXi 5.0, y cuando es posible da la opción para migrar algunas configuraciones existentes en el host, y preservar los Datastores VMFS existentes.

Particionamiento en un Upgrade a ESXi 5.0

Un host ESXi al que se le realice un Upgrade a la versión 5.0 no utiliza la Tabla de Particiones GUID, sino que retiene las antiguas particiones basadas en MSDOS.
Para hosts ESX, la estructura de particiones cambia para ser compatible con un host ESXi. La particion VMFS3 es mantenida y una nueva tabla de particiones basada en MSDOS sobrescribe la tabla de particiones existente. Cualquier dato almacenado en una particion dentro de la Service Console no es preservado en una migración a ESXi 5.0
Para todos los efectos, en un Upgrade a ESXi 5.0, las particiones VMFS no son actualizadas desde VMFS3 a VMFS5. El Upgrade de VMFS puede ser realizado posteriormente, despues que los hosts se encuentran ya en la versión ESXi 5.0. De todas maneras, ESXi 5.0 mantiene la compatibilidad con VMFS3.

Upgrade Interactivo de ESXi

Para realizar un upgrade de ESXi en forma interactiva se utiliza un CD/DVD o una unidad flash USB con el instalador de ESXi 5.0
Importante: Despues de un Upgrade o Migracion a ESXi 5.0, no se puede realizar un Rollback a la version anterior de ESX/ESXi. Se debe realizar un respaldo de de la configuracion del host antes de realizar el Upgrade o Migración.

Recomendaciones

Considera desconectar el almacenamiento en red (SAN/NAS). Esto es recomendado para evitar instalar ESXi sobre una LUN que contenga un datastore VMFS, lo cual inevitablemente nos borrará el contenido de este Datastore, o sea, nuestras máquinas virtuales.
No desconectar una LUN que contenga una instalación existente de ESX/ESXi, no tampoco un datastore VMFS que contenga la Service Console de una instalación ESX existente. ESto puede afectar el proceso de Upgrade.

Proceso de Upgrade Interactivo(Pagina 30 manual VMware)

A continuación un videotutorial con el proceso de Upgrade interactivo para ESXi 5.0.

vSphere 5: Instalacion Interactiva de ESXi 5.0


Ya hemos visto los requerimientos de instalación de ESXi 5.0 en el post anterior. En este post detallaremos el proceso de instalación interactiva de ESXi.

Introducción

Utilizar la opcion de instalación interactiva para pequeñas instalaciónes de menos de 5 hosts. En una instalación interactiva tipica uno bootea el servidor con el instalador de ESXi (el cual puede estar en un CD/DVD, o en un dispositivo USB), y va siguiendo las intrucciones que nos entrega el asistente de instalacion para instalar ESXi en el disco local del host.

El instalador realizar el particionamiento y formateo del disco donde se instalará ESXi, e instala la imagen de booteo de ESXi.

Si no existe una version de ESXi instalada previamente en el disco, toda la data ubicada en el disco es sobrescrita, incluyendo las particiones que puedan venir predefinidas por el fabricante del servidor, particiones de sistemas operativos y otros datos asociados

Si se está instalando ESXi 5.0 en un disco que contiene una version anterior de ESXi o ESX, o un datastore VMFS, el instalador provee de la opción de realizar un Upgrade. Este proceso lo veremos en un post posterior en este blog.

Instalación Interactiva de ESXi

Para instalar ESXi en forma interactiva se utiliza un CD/DVD o una unidad flash USB para instalar ESXi 5.0 en un disco duro SAS, SATA o SCSI, o en un disco USB.


NOTA: Es posible tambien bootear el instalador de ESXi desde PXE para realizar una instalación interactiva o por script.

Recomendaciones

Verificar que el reloj del servidor está configurado con la hora UTC. Esta configuración se encuentra en la BIOS del sistema.

Considera desconectar el almacenamiento en red (SAN/NAS). Esta accion reduce el tiempo necesario para que el instalador busque discos disponibles para la instalacion. Esto tambien es recomendado para evitar instalar ESXi sobre una LUN que contenga un datastore VMFS, lo cual inevitablemente nos borrará el contenido de este Datastore, o sea, nuestras máquinas virtuales.

Proceso de Instalación

A continuación un videotutorial con el proceso de instalación interactiva para ESXi 5.0.


vSphere 5: Upgrade de ESXi 5.0


Hace algunos dias se realizó el lanzamiento de la nueva plataforma de virtualizacion en VMware, vSphere 5.0, la cual trae una serie de mejoras en aspectos de Almacenamiento, Networking, Alta Disponibilidad, etc.
En esta serie de articulos detallaremos el proceso de Upgrade de ESXi 4.l a ESXi 5.0.

ESXi 5.0 utiliza el mismo instalador para nuevas instalaciones y para upgrades o migraciones. Si el instalador encuentra una instalación existente de ESX/ESXi 4.x, proveera la opcion de hacer un upgrade o realizar una nueva instalacion. La instancia existente de ESXi debe cumplir ciertos requisitos de hardware para realizar el upgrade a la versión 5.0.

Dependiendo del disk layout del servidor, el instalador permitirá elegir entre preservar o sobrescribir el datastore VMFS durante la instalación.

Opciones de Upgrade de ESXi

Es posible realizar el Upgrade o Migración de un host ESXi en varias formas, las cuales debemos comprender para asegurar la mejor transición a vSphere 5.

Upgrade o Migración Interactiva

Es posible ejecutar el instalador de ESXi 5.0 desde un CD/DVD o dispositivo USB para realizar un Upgrade o Migración interactiva. Este metodo es apropiado para pequeñas implementaciónes de menos de 5 hosts.
El instalado trabaja de la misma forma que una instalación nueva, pero si el disco seleccionado para la instalación ya contiene una instancia de ESX/ESXi 4.x, el instalador realiza el upgrade a ESXi 5.0, y cuando es posible da la opción para migrar algunas configuraciones existentes en el host, y preservar los Datastores VMFS existentes.

Upgrade o Migración por Script

Es posible realizar el Upgrade o Migración de hosts desde la versión ESX/ESXi 4.x a la versión ESXi 5.0 utilizando un script de Update para realizar un upgrade eficiente y desatendido. Esta modalidad de Upgrade provee una manera eficiente para actualizar multiples hosts.

Es posible utilizar ur script para realizar un Upgrade desde un CD, DVD, dispositivo USB o booteando el instalador desde PXE. Es posible además especificar un script desde una instalación interactiva.

Upgrade o Migración con vSphere Auto Deploy

Auto Deploy es una nueva funcionalidad de vSphere 5.0. Trabajando en conjunto con hosts administrados por vCenter Server, Auto Deploy carga la imagen de ESXi directamente en la memoria del host en vez de instalarla en el disco duro del host.

No es posible utilizar Auto Deploy para realizar un Upgrade o Migración de ESX/ESXi 4.x a ESXi 5.0 debido a que los hosts ESX/ESXi 4.x son instalados mediante el metodo tradicional de instalar el hypervisor en el disco duro del host. Despues que el host es implementado con Auto Deploy, es posible utilizar Auto Deploy para realizar un Upgrade o parchado de un host. Esto se realiza re-aprovisionando el host reiniciandolo con un nuevo perfil de imagen que contencta el Upgrade o Parche de ESXi, un perfil de configuración de host (Host Profile), y opcionalmente drivers y agentes de administración de terceros. Las imagenes personalizadas son construidas con ESXi Image Builder CLI el cual detallaremos en otro articulo.

Upgrade o Migración con Update Manager

Update Manager es una solución robusta para realizar el Upgrade, Migración, Update y Parchado de hosts y virtual machines, orquestando todo el proceso de manera automatica. Si la plataforma VMware utiliza vCenter Server, VMware recomienda utilizar Update Manager.

Upgrades soportados

En la mayoria de los casos, es posible migrar un host ESX 4.x, o realizar un Upgrade de un host ESXi 4.x, directamente a ESXi 5.0.
Hosts ESX/ESXi 3.x No soportado para un upgrade directo. Se debe realizar primero un Upgrade a la versión 4.x
Upgrade de ESX/ESXi 4.x con Update Manager Soportado
Upgrade de ESX/ESXi 4.x en modo Interactivo Soportado
Upgrade de ESX/ESXi 4.x con Script Soportado

Para una lista completa de upgrades soportados, revisar la Guia de Upgrade de vSphere 5.0.

Cambios en el Particionamiento en ESXi 5.0

El esquema de particiones utilizado en ESXi 5.0 difiere significativamente desde las versiones anteriores de ESX y ESXi. Adicionalmente ESXi 5.0 no incluye una particion de Service Console incluida previamente en ESX.

Como afectarán estos cambios al host dependerá se si realizará un Upgrade a ESXi 5.0, o se realizará una instalación limpia.

Particionamiento en una Instalación Limpia de ESXi 5.0

En instalaciones limpias, varias nuevas particiones son creadas (Ej. Boot, Scratch). Una nueva instalación de ESXi utiliza una tabla de particiones GUID (GPT) en vez de un particionamiento basado en MSDOS.

La tabla de particiones es fijada como parte de una imagen binaria, y es escrita en el disco al momento en que ESXi es instalado. El instalador de ESXi deja las particiones VMFS y Scratch en blanco, y ESXi las crea cuando el host es reiniciado por primera vez luego de la instalación o Upgrade. La particion Scratch es de 4GB dejando el resto del disco formateado como una particion VMFS5.

Particionamiento en un Upgrade a ESXi 5.0

Un host ESXi al que se le realizó un Upgrade a la versión 5.0 no utiliza la Tabla de Particiones GUID, sino que retiene las antiguas particiones basadas en MSDOS.

Para la mayoria de los hosts ESXi 4.x la tabla de particiones no es reescrita en un upgrade a ESXi 5.0. En algunos casos la tabla de particiones puede ser rescrita, como en hosts actualizados desde ESXi 3.5 a ESXi 4.x y luego a ESXi 5.0.

Para hosts ESX, la estructura de particiones cambia para ser compatible con un host ESXi. La particion VMFS3 es mantenida y una nueva tabla de particiones basada en MSDOS sobrescribe la tabla de particiones existente.

Para hosts ESX, cualquier dato almacenado en una particion dentro de la Service Console no es preservado en una migración a ESXi 5.0

Para todos los efectos, en un Upgrade a ESXi 5.0, las particiones VMFS no son actualizadas desde VMFS3 a VMFS5. El Upgrade de VMFS puede ser realizado posteriormente, despues que los hosts se encuentran ya en la versión ESXi 5.0. De todas maneras, ESXi 5.0 mantiene la compatibilidad con VMFS3.

Requerimiento de Upgrade de ESXi

Los servidores que ejecutarán instancias de ESXi deben cumplir requerimientos especificos.

Hardware minimo para ESXi

Se debe cumplir una configuración minima de hardware soportada.
  • Servidores con CPU x86 de 64-bit
    • Todos los procesadores AMD Opteron
    • Todos los procesadores Intel Xeon 3000/3200, 3100/3300, 5100/5300, 5200/5400, 5500/5600, 7100/7300, 7200/7400, y 7500
  • ESXi 5.0 solo soporta instrucciones de CPU LAHF y SAHF
  • Minimo 2098MB de memoria RAM.
  • 1 o más NICs Gigabit o 10GbE.
  • Cualquier combinación de una o más de las siguientes controladoras
    • Controladoras SCSI Basicas: Adaptec Ultra-160 o Ultra-320, LSI Logic Fusion-MPT, etc.
    • Controladoras RAID: Dell PERC (Adaptec RAID o LSI MegaRAID), HP Smart Array RAID, o controladoras IBM (Adaptec) ServeRAID.
  • Disco SCSI o una LUN RAID local con espacio no particionado
  • Para Serial ATA (SATA), un disco conectado en una controladora SAS soportada será considerado como remoto, no local. Estos discos no serán usados como una partición Scratch por defecto, debido a que son vistos como remotos.
Para una lista de hardware soportado, revisar la Hardware Compatibility Guide en el sitio de VMware. http://www.vmware.com/resources/compatibility

Almacenamiento soportado para Instalación y Booteo

  • Discos SATA conectados en una controladora SAS soportada
  • Discos SAS (Serial Attached SCSI). Soportados para instalar ESXi 5.0 y para almacenar máquinas virtuales en particiones VMFS.
  • Discos SAN dedicados a través de Fibre Channel o iSCSI.
  • Dispositivos USB soportados para instalar ESXi 5.0
ESXi puede bootear desde discos mayores de 2TB siempre que el firmware los soporte. Para soportar discos o LUNs de más de 2TB, la instancia ESXi 5.0 no debe haber sido actualizada desde una version anterior de ESX/ESXi, sino que debe corresponder a una instalación limpia.

vSphere 5.0 soporta el Booteo de hosts ESXi desde UEFI (Unified Extensible Firmware Interface). Con UEFI se puede bootear desde discos duros, CD-ROM o USB. Booteo desde la red, o provisionamiento con VMware Auto Deploy, requiere de firmware lagacy de BIOS y no está disponible con UEFI.

Chambiar el tipo de booteo desde BIOS legacy a UEFI despues de instalar ESXi 5.0 podria causar una falla en el booteo del host. En estos casos, el host muestra un mensaje de error similar a "Not a VMware boot bank". Cambiar el tipo de booteo no está soportado despues de instalar ESXi 5.0

Proceso de Upgrade de ESXi

Preparación para el Upgrade

ESXi 5.0 es un upgrade mayor, por lo que para completar el proceso exitosamente es necesario entender y preparar la infraestructura para los cambios involucrados.
  • Si el host vSphere incluye soluciones o plug-ins VMware, asegurate de que sean compatibles con ESXi 5.0. Para comprobar, se debe revisar la Matriz de Interoperatibilidad de Productos VMware.
  • Se debe entender los cambios en la configuración y particionamiento entre ESXi 4.x y ESXi 5.0, los escenarios de Upgrade y Migración que estan soportados, y las opciones y herramientas disponibles para realizar el Upgrade o Migración.
  • Respaldar la configuración del host antes de realizar el Upgrade o Migración. Si el upgrade falla, se puede reinstalar la versión anterior de ESX o ESXi y restaurar la configuración del host. Se debe destacar que una vez que el host haya sido Migrado o Upgredeado a la versión 5.0, el proceso no se puede deshacer.
  • Asegurate de que la versión actual de ESX/ESXi está soportada para Migración o Upgrade.
  • Asegurate de que el host cumple con todos los requerimientos de hardware listados anteriormente.
  • Asegurate de que hay suficiente espacio disponible en disco para realizar el Upgrade.
  • Si el host está conectado a una SAN, se recomienda desconectar los cables de fibra o las conexiones iSCSI antes de realizar el Upgrade o Migración. Esto no aplica para host con boot desde la SAN, en cuyo caso se deben desconectar solo las LUNs que contengan un Datastore VMFS.
  • Despues que el proceso de Upgrade o Migración se complete, realizar pruebas al sistema para asegurar de que el proceso se realizó satisfactoriamente.

Instrucciones de Upgrade

Una vez que ya hemos descrito a grandes rasgos los mecanismos de upgrade de ESXi 5.0, junto con sus requerimientos, a continuación detallaremos el proceso de upgrade para cada una de las opciones mencionadas:

vSphere 5: Instalando ESXi 5.0


Hace algunos dias se realizó el lanzamiento de la nueva plataforma de virtualizacion en VMware, vSphere 5.0, la cual trae una serie de mejoras en aspectos de Almacenamiento, Networking, Alta Disponibilidad, etc.

En esta serie de articulos detallaremos el proceso de instalación de ESXi 5.0.  En vSphere 5.0, hay varias opciones para instalar y configurar ESXi. ESXi 5.0 utiliza el mismo instalador para nuevas instalaciones y para upgrades o migraciones. Si el instalador encuentra una instalación existente de ESX/ESXi 4.x, proveera la opción de hacer un upgrade o realizar una nueva instalación.

Dependiendo del disk layout del servidor, el instalador permitirá elegir entre preservar o sobrescribir el datastore VMFS durante la instalación.

Opciones de instalación de ESXi

ESXi puede ser instalado en varias formas las cuales debemos comprender para asegurar la mejor implementación de vSphere.

Las instalaciones de ESXi están diseñadas para adaptarse a implementaciones de diferentes tamaños. Dependiendo del metodo de instalación que se elija, habrán diferentes opciones disponibles para acceder a los medios de instalación y bootear el instalador.

Instalación Interactiva

Es el metodo de instalación recomendada para pequeñas implementaciones de menos de 5 hosts. En este metodo se bootea el instalador desde un CD o DVD, desde un dispositivo USB booteable, o booteando desde la red utilizando PXE.

El proceso de instalación se realiza siguiendo un asistente de instalación interactivo, con el cual podremos completar la instalación de ESXi en un host.

Instalación por Script

Este metodo es una manera eficiente de implementar multiples hosts ESXi con una instalación desatendida. El script de instalacion contiene los parametros de configuración del host. Se puede utilizar el script para configurar multiples hosts con la misma configuración.

El script de instalación debe ser almacenado en una ubicacion que el host pueda aceder por HTTP, HTTPS, FTP, NFS, CDROM o USB. El instalador puede ser iniciado desde PXE, booteando desde un CD/DVD o desde un dispositivo USB.


Instalación con vSphere Auto Deploy

Este metodo permite provisionar y re-provisionar un gran numero de hosts ESXi de forma eficiente con vCenter Server.

Usando Auto Deploy, vCenter Server carga la imagen de ESXi directamente en la memoria del host. Auto Deploy no almacena el estado de ESXi en el disco del host. vCenter Server almacena y gestiona los updates y parches de ESXi a traves de una imagen de perfil, y opcionalmente la configuración del host a través de Host Profile.

Las imagenes de perfil pueden ser creadas con ESXi Image Builder CLI, y los Host Profiles pueden ser creados usando vSphere Cliente.

La primera vez que se instala un host con Auto Deploy, el host bootea con PXE y establece contacto con el servidor de Auto Deploy, el cual envia la imagen de perfil y cualquier Host Profile al host. El host parte utilizando la imagen de perfil, y Auto Deploy asigna el host al servidor apropiado de vCenter Server.

Cuando el host es reiniciado, vCenter Server utiliza Auto Deploy para provisionar el host con la Imagen y Host Profile apropiado. Si la imagen de perfil cambia, por ejemplo por un Update o parche, el administrador puede propagar el cambio a todos los hosts que son provisionados con Auto Deploy y gestionados por vCenter Server.

Requerimiento de Instalación de ESXi
Los servidores que ejecutarán instancias de ESXi deben cumplir requerimientos especificos.

Hardware minimo para ESXi

Se debe cumplir una configuración minima de hardware soportada.
  • Servidores con CPU x86 de 64-bit
    • Todos los procesadores AMD Opteron
    • Todos los procesadores Intel Xeon 3000/3200, 3100/3300, 5100/5300, 5200/5400, 5500/5600, 7100/7300, 7200/7400, y 7500
  • ESXi 5.0 solo soporta instrucciones de CPU LAHF y SAHF
  • Minimo 2098MB de memoria RAM.
  • 1 o más NICs Gigabit o 10GbE.
  • Cualquier combinación de una o más de las siguientes controladoras
    • Controladoras SCSI Basicas: Adaptec Ultra-160 o Ultra-320, LSI Logic Fusion-MPT, etc.
    • Controladoras RAID: Dell PERC (Adaptec RAID o LSI MegaRAID), HP Smart Array RAID, o controladoras IBM (Adaptec) ServeRAID.
  • Disco SCSI o una LUN RAID local con espacio no particionado
  • Para Serial ATA (SATA), un disco conectado en una controladora SAS soportada será considerado como remoto, no local. Estos discos no serán usados como una partición Scratch por defecto, debido a que son vistos como remotos.
Para una lista de hardware soportado, revisar la Hardware Compatibility Guide en el sitio de VMware. http://www.vmware.com/resources/compatibility

Almacenamiento soportado para Instalación y Booteo

  • Discos SATA conectados en una controladora SAS soportada
  • Discos SAS (Serial Attached SCSI). Soportados para instalar ESXi 5.0 y para almacenar máquinas virtuales en particiones VMFS.
  • Discos SAN dedicados a través de Fibre Channel o iSCSI.
  • Dispositivos USB soportados para instalar ESXi 5.0
ESXi puede bootear desde discos mayores de 2TB siempre que el firmware los soporte.
vSphere 5.0 soporta el Booteo de hosts ESXi desde UEFI (Unified Extensible Firmware Interface). Con UEFI se puede bootear desde discos duros, CD-ROM o USB. Booteo desde la red, o provisionamiento con VMware Auto Deploy, requiere de firmware lagacy de BIOS y no está disponible con UEFI.

Importante: Cambiar el tipo de booteo desde BIOS legacy a UEFI despues de instalar ESXi 5.0 podria causar una falla en el booteo del host. En estos casos, el host muestra un mensaje de error similar a "Not a VMware boot bank". Cambiar el tipo de booteo no está soportado despues de instalar ESXi 5.0

Requerimiento de Instalación de ESXi

Una vez que ya hemos descrito a grandes rasgos los tipos de instalación de ESXi 5.0, junto con sus requerimientos, a continuación detallaremos el proceso de instalación para cada una de las opciones mencionadas:

domingo, 17 de julio de 2011

VMware vSphere 5 /iSCSI: Agregar un Datastore y Configurar Multipathing


Siguiendo con la configuración iSCSI en vSphere 5, a continuación revisaremos los pasos para agregar Datastores a un host ESXi. Dentro del mismo procedimiento se detallarán los pasos para configurar la politica de Multipath en cada Datastore.

Para mantener una conexión constante entre un host ESX/ESXi y su storage, VMware soporta funcionalidades de multipathing. Multipathing es una tecnica que permite utilizar más de una ruta fisica(path) para transferir datos entre el host y un dispositivo de almacenamiento externo.

En caso de una falla de cualquier elemento en una red SAN, ya sea un adaptador de red, un switch o un cable, el host puede cambiar a otra ruta fisica (path), la cual no utiliza ninguno de los componentes con problemas. Este proceso de cambio de ruta es conocido como Path Failover.

Adicionalmente al Path Failover, Mutipathing provee balanceo de carga, distribuyendo la carga de I/O entre multiples rutas fisicas. El balanceo de carga reduce o remueve potenciales cuellos de botella.

El I/O de una VM puede ser retrasado por hasta 60 segundos mientras se realiza el proceso de Path Failover. Estas demoras le permiten a la SAN estabilizar estabilizar su configuracion despues de los cambios en la topologia. Generalmente estas demoras en el I/O pueden ser más extensas en arreglos activo-pasivos que en arreglos activo-activos. En algunos casos puede ser necesario realizar configuraciones adicionales en las maquinas virtuales para evitar problemas en los servicios producto de estas demoras en el I/O.

Para administrar Multipathing, VMware utiliza una capa especial de VMkernel, la PSA (Pluggable Storage Architecture), que es un framework abierto y modular, que permite coordinar las operaciones simultaneas de multiples plug-ins de multipathing (MPP).

El plug-in de multipathing que ESX/ESXi provee por defecto es el "VMware Native Multipathing Plug-in" o NMP, el cual es un modulo extensible que administra sub-plugins. Hay dos tipo de sub-plugins de NMP:
  • Storage Array Type Plug-Ins (SATPs). SATP se preocupa de manejar los Path Failovers para un arreglo de Storage.
  • Path Selection Plug-Ins (PSPs). PSP se preocupa de determinar cual ruta fisica es usada para emitir un requerimiento I/O a un dispositivo de Storage.
Los plug-ins SATP y PSP pueden ser provistos por VMware o por software de terceros. Si se requieren funcionalidades adicionales de Multipathing, un software de terceros puede proveer un MPP para ejecutarse como complemento o reemplazo de NMP (Plug-in por defecto de VMware).

NMP asigna un PSP por defecto para cada dispositivo logico basado en el SATP asociado con la ruta fisica para ese dispositivo, sin embargo esta asignacion puede ser sobrescrita. Por defecto VMware NMP soporta los siguientes PSP:
  • MRU (Most Recently Used): Selecciona la ruta que el host uso más recientemente para acceder a un dispositivo de storage. Si esta ruta llega a encontrarse no disponible, el host cambia a una ruta alternativa y la continua utilizando mientras ésta se encuentre disponible. MRU es la politica de multipathing por defecto para arreglos activo-pasivo.
  • Fija o Fixed: Utiliza la ruta designada como preferida si esta ha sido configurada. De lo contrario utiliza la primera ruta descubierta que se encuentre funcionando correctamente. Si el host no puede usar la ruta preferida, selecciona una ruta alternativa disponible en forma aleatoria. El host vuelve a utilizar la ruta preferida tan pronto como dicha ruta vuelva a encontrarse disponible. Esta politica es la politica por defecto para arreglos activo-activo.
  • Round Robin: Utiliza un algoritmo de seleccion de rutas que va rotando a través de todas las rutas activas disponibles, permitiendo balanceo de carga a traves de las rutas. Este algoritmo es recomendado para arreglos activo-activo, o sistemas ALUA.

 Agregar Datastores y Configurar una politica de Multipathing


Al completar estos pasos ya tenemos habilitada nuestra red iSCSI, incluyendo la configuración inicial del iniciador iSCSI por Software, y hemos agregado un Datastore VMFS-3 y VMFS-5. En los siguientes artículos detallaremos los pasos para la migración de datastores VMFS-3 a VMFS-5.

viernes, 15 de julio de 2011

VMware vSphere 5 /iSCSI: Habilitación del Iniciador iSCSI



Siguiendo con la configuración iSCSI en vSphere 5, a continuación revisaremos los pasos para habilitar el iniciador iSCSI por software. Dentro del mismo procedimiento se detallarán los pasos para realizar el Port Binding, y se explicará como agregar un target iSCSI en la configuración del iniciador.

Para acceder a un Target iSCSI, los hosts utilizan Iniciadores iSCSI. Este iniciador transporta los requerimientos y respuestas SCSI, encapsulandolos en el protocolo iSCSI, entre el host y el Target iSCSI.
Los hosts en vSphere 5 soportan diferentes tipos de iniciadores:
  • Adaptador iSCSI por Software: Es un adaptador incluido en el VMkernel, que permite al host conectarse a un Storage iSCSI a través de adaptadores de red standard. Esta opción permite utilizar la tecnologia iSCSI sin comprar hardware especializado.
  • Adaptador iSCSI por Hardware: Es un adaptador de teceros que libera al host del procesamiento de red y iSCSI. Estos se dividen en dos categorias:
    • Dependientes: Dependen de la red de VMware, y de la configuración iSCSI y las interfaces de administración provistas por VMware. Puede ser una tarjeta que incluye un adaptador de red standard y funcionalidades de iSCSI offload por el mismo puerto. Estas funcionalidades de offload dependen de la configuración de red del host para obtener la IP, MAC, y otros parametros usados por las sesiones iSCSI
    • Independientes: Implementan su propia configuración de red y iSCSI, asi como sus propias interfaces de administración. Puede ser una tarjeta que presenta solo funcionalidades de iSCSI offload. Estas funcionalidades de offload tienen configuraciones independientes que asignan IP, MAC y otros parametros usados por las sesiones iSCSI.
Una SAN iSCSI utiliza una arquitectura cliente servidor, donde el cliente llamado iniciador iSCSI opera en el host. Este cliente inicia las sesiones iSCSI emitiendo comandos SCSI y trasmitiendolos, encapsulados en el protocolo iSCSI, a un servidor conocido como iSCSI target. El iSCSI target representa un sistema de almacenamiento fisico en la red y responde a los comandos del iniciador transmitiendo los datos iSCSI requeridos.

VMware utiliza puertos VMkernel como los iniciadores de sesiones, por lo que debemos configurar cada puerto que queramos utilizar como un camino (path) para el Storage. Esto es independiente del numero de NICs o HBAs iSCSI, pero en la mayoria de los casos será una relación uno a uno entre los puertos VMkernel y las interfaces disponibles. Una vez que las sesiones a la SAN son iniciadas, VMware NMP se encargará de balancear la carga y distribuir el trafico I/O entre todos los caminos disponibles.

Los volumenes en una SAN iSCSI pueden ser utilizados por ESX/ESXi como un Datastore VMFS o un Raw Device Map (RDM). El iniciador iSCSI por software utiliza los puertos VMkernel que fueron creados y establece una sesion a la SAN y a los volumenes. A partir de vSphere 4 se pueden utilizar multiples caminos (multipathing) a la SAN para un mayor ancho de banda y performance.

Cada puerto VMkernel se encuentra asignado a un adaptador fisico. Dependiendo de la plataforma se pueden crear hasta 8 sesiones simultaneas a un volumen. Para una implementación estandar se recomienda el uso de una relación uno a uno (1:1) entre los puertos VMkernels y las interfaces fisicas, o sea si existen 4 interfaces fisicas, se crearía 4 puertos VMkernel, y se asociaria cada uno de estos puertos a una NIC separada. Este esquema puede ser expandido dependiendo del numero de NICs que se tengan disponibles.
A medida que la infraestructura va creciendo se pueden establecer multiples sesiones a la SAN suscribiendo más puertos VMkernel a las interfaces fisicas existentes. Esto establece multiples sesiones a un volumen, pero aun utiliza las mismas interfaces fisicas para acceder a dicho volumen.

Habilitación de Iniciador iSCSI

 

Al completar estos pasos ya tenemos habilitada nuestra red iSCSI, incluyendo la configuración inicial del iniciador iSCSI por Software. En los siguientes articulos detallaremos los pasos para la creación de los datastores VMFS creados sobre LUNs iSCSI, y como migrar datastores VMFS-3 a VMFS-5.

VMware vSphere 5 /iSCSI: Configuración de la red para iSCSI



Siguiendo con la configuración iSCSI en vSphere 5, a continuación revisaremos la configuración de red requerida para iSCSI.

Si se usa un adaptador iSCSI por Software o por Hardware, se debe configurar la red para iSCSI antes de poder habilitar y configurar los adaptadores iSCSI. La configuración de red para iSCSI incluye abrir los puertos VMkernel para el trafico entre el adaptador iSCSI y la interfaz fisica.

Dependiendo del numero de interfaces fisicas que se utilicen para el trafico iSCSI, la configuración de la red puede variar:
  • Si se tiene una unica NIC fisica, se crea un puerto iSCSI sobre un vSwitch conectado a dicha NIC. VMware recomienda que se designe un adaptador de red separado para iSCSI. Este adaptador debe ser de 1Gbit o superior.
  • Si se tiene dos o más NIC fisicas, se deben crear puertos iSCSI por cada NIC fisica y usar dichas NICs para el multipathing iSCSI.
Las NIC fisicas deben estar en la misma subred que el Storage iSCSI para que el host pueda conectarse a este.

El adaptador iSCSI y las NICs fisicas se conectan a traves de un adaptador VMkernel virtual, tambien conocido como adaptador de red virtual o puerto VMkernel. Se crea un adaptador VMkernel (vmk) en un vSwitch utilizando una relacion 1:1 entre cada adaptador de red fisico y virtual.



Para lograr esta relacion 1:1 cuando se tienen multiples NICs, se designa un vSwitch separado por cada par adaptador fisico-virtual.



En forma alternativa, se pueden agregar todas las NICs y puertos VMkernel en un unico vSwitch Standard. En este ultimo caso, se debe sobrescribir la configuración de red por defecto, para asegurarse de que cada adaptador VMkernel esta asociado solo a una NIC fisica.


Configuración de red iSCSI

A continuación realizamos la creación del vSwitch para iSCSI, asi como los puertos VMkernel para cada una de las interfaces fisicas existentes.

Si se tiene una unica interfaz de red fisica para el trafico iSCSI, los puertos VMkernel que se creen deberan asignarse a esa unica interfaz de red.

Creación del vSwitch para iSCSI



Al completar estos pasos ya tenemos la primera parte de la configuración requerida para habilitar una red iSCSI. En los siguientes articulos detallaremos como habilitar el iniciador iSCSI por software, y como asignar los puertos VMkernel a dicho iniciador (Port Binding).

VMware vSphere 5.0: Conexión a una SAN iSCSI


Hace algunos dias se realizó el lanzamiento de la nueva plataforma de virtualizacion en VMware, vSphere 5.0, con importantes mejoras en lo que a almacenamiento se refiere. Una de estas mejoras, es la facilidad de realizar la configuración iSCSI completamente a traves del vSphere Client, sin la necesidad de utilizar la linea de comandos como era requerido en vSphere 4.

En los siguientes articulos detallaremos el proceso de configuración de vSphere 5, de manera de poder utilizar una SAN iSCSI como repositorio para los Datastores VMFS. Incluiremos la configuración requerida a nivel de red, iSCSI y multipathing, entre otras.

Si quieren conocer el proceso de configuración de iSCSI en vSphere 4, lo pueden ver en el siguiente link:
http://www.patriciocerda.com/2010/10/vmware-vsphere-41-conexion-una-san.html

Introducción

Es posible utilizar ESX/ESXi en conjunto con una SAN, que es basicamente una red especializada que conecta sistemas computacionales con subsistemas de almacenamiento de alta performance. El uso de una SAN, ya sea iSCSI o de Fiber Channel, provee una consolidacion del almacenamiento, al mismo tiempo que mejora la disponibilidad y facilita la recuperacion ante desastres. Por otro lado, el uso de una SAN como almacenamiento compartido es un requerimiento para poder crear un Cluster HA/DRS en VMware (aunque como alternativa se puede utilizar una NAS, o el nuevo vStorage Appliance).

Una SAN iSCSI utiliza una conexión Ethernet entre servidores y un sistema de almacenamiento de alta performance. Los componentes de una SAN incluyen HBAs (host bus adapters) iSCSI o interfaces de red (NICs) en el servidor, switches y routers que transportan el trafico del storage, Storage Processors (SP o controladoras) y sistemas de discos.

Iniciadores iSCSI

Para acceder a un Target iSCSI, los hosts utilizan Iniciadores iSCSI. Este iniciador transporta los requerimientos y respuestas SCSI, encapsulandolos en el protocolo iSCSI, entre el host y el Target iSCSI.
Los hosts en vSphere 5 soportan diferentes tipos de iniciadores:
  • Adaptador iSCSI por Software: Es un adaptador incluido en el VMkernel, que permite al host conectarse a un Storage iSCSI a través de adaptadores de red standard. Esta opción permite utilizar la tecnologia iSCSI sin comprar hardware especializado.
  • Adaptador iSCSI por Hardware: Es un adaptador de teceros que libera al host del procesamiento de red y iSCSI. Estos se dividen en dos categorias:
    • Dependientes: Dependen de la red de VMware, y de la configuración iSCSI y las interfaces de administración provistas por VMware. Puede ser una tarjeta que incluye un adaptador de red standard y funcionalidades de iSCSI offload por el mismo puerto. Estas funcionalidades de offload dependen de la configuración de red del host para obtener la IP, MAC, y otros parametros usados por las sesiones iSCSI
    • Independientes: Implementan su propia configuración de red y iSCSI, asi como sus propias interfaces de administración. Puede ser una tarjeta que presenta solo funcionalidades de iSCSI offload. Estas funcionalidades de offload tienen configuraciones independientes que asignan IP, MAC y otros parametros usados por las sesiones iSCSI.
.

Como funcion el iniciador iSCSI por software?

Una SAN iSCSI utiliza una arquitectura cliente servidor, donde el cliente llamado iniciador iSCSI opera en el host. Este cliente inicia las sesiones iSCSI emitiendo comandos SCSI y trasmitiendolos, encapsulados en el protocolo iSCSI, a un servidor conocido como iSCSI target. El iSCSI target representa un sistema de almacenamiento fisico en la red y responde a los comandos del iniciador transmitiendo los datos iSCSI requeridos.

VMware utiliza puertos VMkernel como los iniciadores de sesiones, por lo que debemos configurar cada puerto que queramos utilizar como un camino (path) para el Storage. Esto es independiente del numero de NICs o HBAs iSCSI, pero en la mayoria de los casos será una relación uno a uno entre los puertos VMkernel y las interfaces disponibles. Una vez que las sesiones a la SAN son iniciadas, VMware NMP se encargará de balancear la carga y distribuir el trafico I/O entre todos los caminos disponibles.

Los volumenes en una SAN iSCSI pueden ser utilizados por ESX/ESXi como un Datastore VMFS o un Raw Device Map (RDM). El iniciador iSCSI por software utiliza los puertos VMkernel que fueron creados y establece una sesion a la SAN y a los volumenes. A partir de vSphere 4 se pueden utilizar multiples caminos (multipathing) a la SAN para un mayor ancho de banda y performance.

Cada puerto VMkernel se encuentra asignado a un adaptador fisico. Dependiendo de la plataforma se pueden crear hasta 8 sesiones simultaneas a un volumen. Para una implementación estandar se recomienda el uso de una relación uno a uno (1:1) entre los puertos VMkernels y las interfaces fisicas, o sea si existen 4 interfaces fisicas, se crearía 4 puertos VMkernel, y se asociaria cada uno de estos puertos a una NIC separada. Este esquema puede ser expandido dependiendo del numero de NICs que se tengan disponibles.

A medida que la infraestructura va creciendo se pueden establecer multiples sesiones a la SAN suscribiendo más puertos VMkernel a las interfaces fisicas existentes. Esto establece multiples sesiones a un volumen, pero aun utiliza las mismas interfaces fisicas para acceder a dicho volumen.

Tipos de Storage iSCSI

ESXi soporta diferentes tipos de arreglos de Storage:
  • Storage Activo-Activo: Permite acceso a las LUNs en forma simultanea a traves de todos los Puertos de Storage disponibles, sin una degradación de performance significativa. Todos los paths son activos todo el tiempo, a menos que un path falle.
  • Storage Activo-Pasivo: Corresponde a un storage en la cual un Storage Procesos provee acceso en forma activa a una LUN determinada. El otro SP actua como un respaldo para la LUN, y puede proveer acceso activo a otra LUN. Si el acceso a traves de un SP falla, uno de los SP pasivos puede ser activado.
  • Storage Asimetrico: Soporta Asymmetric Logical Unit Access (ALUA). Los Storage con soporte ALUA proveen diferentes niveles de acceso por puerto. ALUA le permite a los hosts determinar el estado de los puertos del Target y priorizar los paths. El host utiliza algunos de los paths activos como Primarios, mientras que trata al resto como Secundarios.
  • Storage de Puerto Virtual: Permite acceso a todas las LUNs disponibles a través de un unico puerto virtual. Estos son basicamente Storages activo-activo, pero esconden sus multiples conexiones a traves de un unico puerto virtual. Los mecanismos de Multipathing no pueden detectar las conexiones multiples al Storage. Estos tipos de Storage manejan el Port Failover y el balanceo de conexiones en forma transparente, lo cual es conocido frecuentemente como Transparent Failover.

Nuevas caracteristicas del iniciador iSCSI en vSphere 5

VMware vSphere 5 ofrece mejoras sobre el iniciador iSCSI por Software, junto con la conectividad para SAN iSCSI.
  • Iniciador iSCSI por Software: Este iniciador debe ser agregado entre los Storage Adapters, ya que no viene incluido por defecto.
  • Port Binding: Ahora es posible realizar las operaciones de Port Binding completamente a traves del vSphere Client, sin la necesidad del uso de la linea de comandos como se estilaba en vSphere 4.
  • Jumbo Frames: Ahora es posible habilitar Jumbo Frame, tanto en los Virtual Switch como en los puertos VMkernel, completamente a traves de vSphere Client.



Buenas Practicas

  • Se recomienda el uso de un Switch de red Gigabit Ethernet o 10GE separado para el manejo del trafico iSCSI. Se recuerda que el trafico en una red iSCSI no se encuentra encriptado.
  • Se recomienda conectar cada host ESXi a 2 Switches iSCSI, cada uno de estos conectados a todas las controladoras disponibles en el Storage.  Esto permite contar con alta disponibilidad y balanceo de carga en las conexiones iSCSI.
  • Los servidores, Switches y puertos de las controladoras del Storage deben estar en el mismo segmento de red
  • Se recomienda tener más de una HBA iSCSI o NIC dedicada para el trafico iSCSI.
  • Se recomienda habilitar Jumbo Frame para mejorar la performance en la comunicación iSCSI. Se recuerda que la habilitación de Jumbo Frame debe realizarse end-to-end.

Requisitos

Para la configuración de iSCSI en vSphere existen algunos requisitos que se detallan a continuación:
  • Al menos una HBA iSCSI o NIC para el trafico iSCSI. En nuestro ambiente utilizaremos 2 NICs para la configuración iSCSI.
  • Un segmento de IP dedicado para el trafico iSCSI. En nuestro caso utilizaremos el segmento no ruteable 10.10.10.x
  • Verificar que el Storage está soportado por ESXi.
  • Se debe utilizar solo un datastore VMFS por LUN.
  • ESXi no soporta multipathin cuando se combinan adaptadores por Hardware independientes, con adaptadores por Hardware dependientes, o adaptadores por Software.

Configuración de iSCSI en vSphere

Habiendo entendido la arquitectura de una SAN iSCSI y sus requerimientos y buenas practicas, a continuación detallaremos el proceso de configuración de iSCSI en VMware vSphere 5.0:
Para una documentación más detallada del proceso y que cubra todos los escenarios, pueden revisar la documentación oficial de VMware.

jueves, 14 de julio de 2011

vSphere 5: What's New - Storage


Hace solo un par de dias se lanzó vSphere 5, y en este blog publiqué un resumen de lo nuevo que viene en vSphere 5.

En esta ocasión, veremos más en profundidad las mejoras que incluye vSphere 5 desde el punto de vista del Almacenamiento.

VMFS-5
vSphere 5 trae una nueva versión de su sistema de archivos VMFS, el cual contiene importantes cambios y mejoras en su arquitectura, mejorando la escalabilidad y performance respecto a la versión anterior, VMFS-3.

vSphere incluye mecanismos para la migración de VMFS-3 a VMFS-5 en un proceso consistente sin interrupciones.  Durante el proceso de Upgrade, los volumenes migrados a VMFS-5 mantendrán el Block Size configurado, debido a que modificar este parametro requeriría formatear el volumen.

VMFS incluye las siguientes mejoras:

  • Soporte de dispositivos de hasta 64TB. Una gran mejora considerando el limite de 2TB impuesto en VMFS-3 (sin considerar los extents)
  • Block Size unificado de 1MB, que reduce la complejidad desde el punto de vista de la arquitectura y la operacion, mientras aun se mantienen la escalabilidad y flexibilidad que existia previamente con Block Sizes más grandes.
  • Mecanismo mejorado de Sub-bloques.  Permite una mayor escalabilidad, reduciendo el overhead asociado con los archivos pequeños.  VMFS-5 es capaz de asignar hasta 30.000 sub-bloques de 8KB para archivos como archivos de Logs y metadata (Ej. archivos .vmx).


A continuación una cuadro que nos permite comparar los cambios en la arquitectura entre VMFS-3 y VMFS-5



Todo esto permite soportar volumenes más grandes, de hasta 64TB, y una mayor densidad de máquinas virtuales.

Storage DRS

Un desafio permamente en una infraestructura virtual, es el monitoreo de la capacidad de los datastores, y de la carga de I/O.

Durante la creación de MV y Virtual Disks, es frecuente ver que la selección de cual Datastore utilizar está dado por una selección aleatora, lo cual puede llevar a una sobreutilización de algunos datastores, mientras otros practicamente no son utilizados.

Para enfrentar estos desafios, vSphere 5 incluye una caracteristica llamada Storage DRS, la cual provee de una asignación inteligente de datastore para las máquinas virtuales, y mecanismos de balanceo de carga entre los datastores, basados en espacio disponible y en capacidad de I/O.

Se crea un nuevo objeto de inventario en vCenter, llamado Datastore Cluster, el cual es la base de Storage DRS.  Un Datastore Cluster es un conjunto de datastores agrupados en una unica unidad.
Cuando se crea un Datastore Cluster, sDRS puede gestionar los recursos de almacenamiento en forma similar a como DRS gestiona los recursos de CPU y Memoria en un cluster.



Respecto a las recomendaciones de ubicación inicial para las MV provistas por Storage DRS, al momento de crear una MV, se puede seleccionar un Datastore Cluster como la ubicación para la MV y/o Virtual Disks, en vez de la seleccion de Datastore individual que se realizaba tradicionalmente.  Storage DRS se asegura además que la ubicación inicial de las MV esté acorde con la utilización actual de los Datastores, y la carga de I/O en cada uno de estos, reduciendo el riesgo de cuellos de botella en las operaciones de I/O, y el consiguiente impacto en la performance de las máquinas virtuales.

Respecto a las recomendaciones de balanceo de carga, estas son hechas cuando uno o más datastores en un Datastore Cluster, exceden los umbrales previamente definidos en la utilización de espacio, o en la latencia de las operaciones de I/O (15ms por defecto).  Estos Umbrales son definidos durante la creación del Datastore Cluster, y pueden ser modificados en el tiempo.



Para realizar recomendaciones, sDRS aplica los mecanismos de reporte de utilización de Datastores provistos por vCenter Server (y que ya estaba disponible en vSphere 4), a la vez que la carga de I/O es evaluada, por defecto, cada 8 horas.  Cuando uno de los umbrales es superado, sDRS calcula todos los movimientos posibles para balancear la carga, considerando ademas el costo y beneficio de dichas migraciones.

Storage DRS incluye además, asi como el DRS tradicional, reglas de afinidad y anti-afinidad, asi como el uso del Modo de Mantenimiento.  Esto permite controlar cuales virtual disks debieran o no ser ubicados en el mismo datastore en un Datastore Cluster.  Por defecto, los virtual disks de una VM son mantenidos juntos en el mismo Datastore.  Storage DRS ofrece 3 tipos de reglas de afinidad.


  • Anti-Afinidad de VMDK, donde una los Virtual Disks de una MV son ubicados en diferentes datastores.
  • Afinidad de VMDK, donde los virtual disks de una MV son mantenidos juntos en un mismo datastore
  • Anti-afinidad de VM, donde 2 MV especificas, incluyendo sus Virtual Disks, son ubicadas en diferentes datastores.



Adicionalmente, Storage DRS ofrece el Modo de Mantenimiento de un Datastore, el cual permite liberar un Datastore especificado, de todas las MV y Virtual Disks que este contenga, a los datastores restantes en el Datastore Cluster.

Storage DRS funciona con Datastores VMFS y NFS, pero estos no pueden ser mezclados en un unico Datastore Cluster.

vSphere Storage APIs - Storage Awareness

Es un nuevo conjunto de APIs que le permite a vCenter Server detectar las capacidades de los datastores/LUNs del arreglo de Storage, haciendo mucho más facil seleccionar el datastore para la ubicación inicialde una MV, o incluso facilitando el proceso de creación de un Datastore Cluster.

Las capacidades del Storage, como el nivel de RAID, Thin o Thick Provisioning, Replicación, etc., es visible dentro de vCenter Server utilizand estas APIS.

Profile-Driven Storage
Permite una ubicación rapida e inteligente de una MV en un Datastore, basado en SLAs, Disponibilidad, Performance u algún otro requisito.

Usando Profile-Driven Storage, diferentes capas, o Tiers, pueden ser requeridos por un perfil de storage de una MV.  Estos perfiles son usados durante la provisión de una MV, durante el clonado, y durante las operaciones de Storage vMotion, asegurandose que solo aquellos Datastores o Datastores Clusters que cumplen con el perfil de storage de la VM, se encuentran disponibles para dicha VM.



Con esto, uno puede definir una serie de perfiles (tiers) de MV, cada uno con ciertas caracteristicas de Disponibilidad, Performance, Capacidad, Costo, etc., y aplicarlos a diferentes MV automatizando la selección del Datastore a utilizar, y asegurando que dichas MV solo utilicen Datastores o Datastore Clusters que cumplan con dicho perfil.

Profile-Driven Storage se integra completamente con "vSphere Storage APIs - Storage Awareness", e incluye soporte para Storage NFS, iSCSI y FC que se encuentren en la HCL.

vCenter Server permite además un chequeo sencillo del estado de cumplimiento de las máquinas virtuales y sus virtual disks asociados.

Como resultado, la gestion de capas (tiers) de storage, el provisionamiento, migración, clonación y ubicación inicial de MV en vSphere, se ha vuelto más eficiente y más amigable.

Iniciador por software para Fibre Channel over Ethernet (FCoE)
Si bien vSphere 4 ya soportaba FCoE, vSphere 5 da un paso más allá introduciendo un adaptador FCoE por software, equivalente al iniciador iSCSI por Software.



El adaptador FCoE por software requiere de un adaptador de red que soporte capacidades parciales de FCoE offload.

Mejoras en el iniciador iSCSI
Si bien con vSphere 4, el iniciador iSCSi por software fue completamente rescrito y optimizado por performance, la configuración solo era posible a traves de la linea de comandos, y era considerada una tarea "dificil" =D



Para enfrentar esto, vSphere 5 incluye la posibilidad de configurar iSCSI completamente a través de vSphere Client. Incluso la habilitación de Jumbo Frames es ahora posible de realizar utilizando vSphere Client.

vSphere Storage I/O Control
En vSphere 4 se introdujo inicialmente esta funcionalidad para proveer de priorización de I/O de MV corriendo en un cluster VMware, que tenia acceso a almacenamiento compartido iSCSI o FC.  Este tipo de control estaba basado en Shares y limites, muy similar a lo que existe para el control de los recursos de CPU y Memoria.

vSphere 5 extiende esta funcionalidad para proveer de Shares y limites de I/O para datastores VMFS.  Con esto podriamos lograr que ninguna MV sea capaz de crear un cuello de botella en un ambiente VMware, sin importar el tipo de almacenamiento utilizado.

vSphere Storage APIs – Array Integration

VAAI fue incluido ya en vSphere 4.1 permitiendo liberar al hypervisor de operaciones como:

  • Full Copy, permitiendo que el Storage haga las copias completas dentro del arreglo.
  • Block Zeroing, permitiendo al arreglo ejecutar operaciones de Zeroing en un gran numero de bloques
  • Locking asistido por hardware, lo que provee de un mecanismo alternativo para proteger la metadata de VMFS.

En vSphere 5.0, el soporte VAAI ha sido mejorado adicionado nuevas capacidades:

  • vSphere Thin Provisioning, permitiendo la reclamación del espacio no utilizado cuando un archivo es borrado o removido del datastore con Storage vMotion, y el monitoreo del espacio usado por LUNs con Thin Provisioning, evitando situaciones en que una LUN se pueda quedar sin espacio debido a la sobresuscripción de Storage.

  • Aceleracion de hardware para NAS, lo cual permitirá un provisionamiento más rapido, y el uso de Virtual Disks en formato Thick (en vSphere 4 un Virtual Disk en un Storage NAS era creado con Thin Provisioning por defecto, no permitiendo el uso de discos Thick) utilizando dos nuevas funcionalidades VAAI:
    • Full File Clone, similar a Full Copy, que permite que los virtual disks sean clonados en un dispositivo NAS.
    • Espacio Reservado, que permite la creación de virtual disks en formato Thick en una NAS.

  • Estandarizacion SCSI para cumplimiento de T10 para Full Copy, Block Zeroing y Locking asistido por Hardware.


vSphere Storage vMotion

Incluido inicialmente en vSphere 4, permite la migración en caliente de los discos virtuales de una MV desde un datastore a otro, sin downtime o perdida de servicio.

vSphere 5 ha incluido una serie de mejoras para que el proceso de Storage vMotion sea mas eficiente, permitiendo ademas la migración de MV que contengan Snapshots, y la migración de Linked Clones (View, Lab Manager).



Storage vMotion en vSphere 5 incluye un nuevo proceso de migración a traves del uso de una caracteristica llamada Mirror Mode, la cual permite una copia de bloques desde el disco de origen al disco de destino, espejando los I/Os de bloques copiados.  Esto mejora la eficiencia de Storage vMotion, logrando además que los tiempos de migración sean predecibles, facilitando la planificación de las migraciones.

El mirror driver se habilita por MV y reside dentro del VMKernel  Cuando el sistema operativo en la máquina virtual que está siendo migrada con Storage vMotion, inicia una operacion de escritura a un bloque ya copiado, el Mirror Driver espejara en forma sincrona esta operacion de escritura.

Espero que les haya sido de utilidad, y les haya aclarado un poco sobre las nuevas funcionalidades de vSphere 5 enfocadas al Almacenamiento.

martes, 12 de julio de 2011

vSphere 5: Nuevo modelo de licenciamiento.


Como ya muchos saben, hoy se lanzó oficialmente la nueva infraestructura de Cloud de VMware, incluyendo vSphere 5, la nueva versión del hypervisor de VMware.

Además de las novedades tecnicas, vSphere 5 trae un nuevo modelo de licenciamiento que ha dado mucho que hablar, y que a muchos parece no haberles agradado.  Veamos a continuación en que consiste este nuevo modelo de licenciamiento:

Para VMware, el modelo de licenciamiento de vSphere 5 ha evolucionado para darle a los clientes la posibilidad de utilizar un enfoque mas similar al enfoque Cloud, o sea "Pague por lo que consume".   Basicamente, lo que se intenta es maximizar la utilización y eficiencia de hardware, utilizando pools de recursos.  Al mismo tiempo, el modelo de licenciamiento de vSphere 4.x dificultaba la transicion a un modelo de costo y chargeback basado en uso, y que caracteriza al Cloud Computing y a IT As a Servide.

Siendo especificos, vSphere 5 elimina el modelo de licenciamiento por CPU (Socket) utilizada por vSphere 4, la cual limitaba el numero de Cores fisicos por CPU, asi como el maximo de memoria RAM por servidor fisico.  Este modelo se reemplaza por un modelo de asignación de memoria desde un pool de memoria virtual (vRAM), el cual detallaremos a continuación.

O sea, las licencias seguirán siendo por CPU (socket), sin embargo estás licencias no tendrán un limite en el numero de Cores por CPU, y cada host puede tener una cantidad ilimitada de memoria RAM.  No obstante, cada licencia estará limitada, según la edición, a una cantidad X de vRAM que es posible asignar a las máquinas virtuales.  Es en este punto donde se ha abierto una fuerte discusión, ya que la cantidad de vRAM incluida en cada licencia parece ser muy limitada, considerando la capacidad actual que tienen los servidores para incluir grandes cantidades de memoria RAM.


De acuerdo al documento de licenciamiento publicado por VMware, este nuevo modelo de licenciamiento cumple dos objetivos principales:

  • Libera a los clientes de la asignación restrictiva de licencias basada en hardware
  • Alinea el modelo de licenciamiento de vSphere con el concepto "IT as a Service"


Esto es empujado por las sucesivas innovaciones en el diseño de hardware, como el aumento en el numero de Cores por CPU, la alta densidad en los modulos de memoria, etc, lo cual ha empujado los limites del modelo de licenciamiento que existia en vSphere 4.  Claramente era necesario un cambio en el modelo de licenciamiento, no obstante el nuevo modelo no ha sido recibido del todo bien.

Como respuesta, VMware creó un nuevo modelo de licenciamiento para vSphere 5, basado en CPU y con una asignación de vRAM dependiendo del tipo de licencia adquirida.
Cada licencia de CPU para vSphere 5 tendrá asignada una cantidad especifica de vRAM, o memoria configurada en las Virtual Machines.
La vRAM asignada puede ser agregada en un Pool, o fondo comun, en una plataforma VMware, el cual permite que esta vRAM sea usada con mucha flexibilidad en un cluster VMware.

La vRAM es una asignación de memoria transferible, que permite una gran flexibilidad en la configuración y el uso.  vRAM es la memoria virtual configurada en las máquinas virtuales.  Cuando una Máquina virtual es creada, se configura con una cierta cantidad de memoria virtual (vRAM).  Dependiendo del tipo de licencia, cada licencia vSphere 5 provee una cierta capacidad de vRAM para ser usada por las máquinas virtuales ENCENDIDAS.  Solo cuando una MV es encendida, la vRAM configurada en esa VM se descuenta del total de vRAM asignada en la licencia.
La vRAM puede ser utilizada como el cliente quiera, o sea puede usarse en multiples VM con una pequeña asignación de vRAM, o puede usarse en una unica VM que requiera toda la vRAM.

Un concepto importante aqui, es el uso de Pool de vRAM, que es la posibilidad de sumar la vRAM de todos los procesadores licenciados.  Es decir, la vRAM incluida en cada CPU licenciada es sumada en un Pool que está disponible para todas las CPU's licenciadas administradas por una instancia de vCenter (o multiples instancas en Linked Mode).  O sea, si la carga de un host no esta usando completamente su vRAM licenciada, la capacidad restante puede ser usada por otras máquinas virtuales, dentro de otros hosts en la misma instancia de vCenter Server.



Del mismo modo, una MV activa puede tener asignada una cantidad de vRAM que supere la vRAM licenciada en una CPU dada, siempre que haya suficiente vRAM disponible en el pool de vRAM.
En su conjunto, la vRAM consumida por todas las MV encendidas dentro de un pool de vRAM, no debe superar la capacidad licenciada de vRAM entre todas las CPU's.

Como aumentar la capacidad de vRAM en el pool?  VMware da dos opciones:

  • Agregar más licencias de CPU de la misma edicion de vSphere.
  • Actualizar todas las licencias de CPU a una edicion superior de vSphere, la cual cuenta con una mayor asignación de vRAM por CPU.


VMware tambien incluyó un modulo de gestión de licencias en vCenter Server, el cual permite monitorear y gestionar la capacidad disponible y consumida de vRAM.

A continuación una comparación de los tipos de licenciamiento en vSphere 5.0 y las versiones anteriores.


Despues de toda esta explicación, este modelo de licenciamiento puede ser util para algunos, asi como puede afectar negativamente a otros, y es por esto que ha recibido diversas criticas desde su lanzamiento.

Desde mi punto de vista, por un lado se está tratando de hacer un uso más eficiente y flexible de los recursos, sin embargo a la vez nos limita en el uso de overcommit de memoria, el cual ya no se consideraría un ahorro en recursos como tal, ya que ahora el costo del licenciamiento estará dado por el uso de la vRAM por las MV activas.  Transparent Page Sharing, Ballooning y otras tecnicas de administración de memoria no serán una ayuda tan considerable para reducir costos, al menos desde el punto de vista del licenciamiento, en este nuevo modelo de licenciamiento,

Al mismo tiempo, se estaría privilegiando un modelo de escalamiento Scale-Out, por sobre un modelo Scale-Up.  Porque?
Actualmente es comun ver servidores VMware con 2 o más CPUs multi-core, con 128GB o más de memoria RAM, los cuales eran posible licenciar solo considerando una licencias por CPU.  En este nuevo modelo de licenciamiento, deberemos considerar además la memoria utilizada o vRAM.

Por ejemplo, un Cluster con 8 hosts con las siguientes características:


  • 4 CPUs de 6 Cores por host  (32 CPUs en el Cluster)
  • 128GB RAM por host (1TB RAM en el Cluster)
  • Licencias Enterprise para 32 CPUs
  • 70% de uso de memoria (vRAM) en el cluster (alrededor de 720GB)


Con el modelo de licenciamiento de vSphere 5, el mismo cluster necesitará:


  • 32 Licencias Enterprise para 32 CPUs.
  • 1TB de vRAM (32GB de vRAM por cada licencia Enterprise)
Osea, en este caso, el modelo de licenciamiento de vSphere 5 no afecta en nada los costos de licenciamientos de este cluster, por el contrario, funciona bastante bien... pero!!!  ¿Que pasa si el cliente quiere aumentar la capacidad de los hosts, en una estrategia Scale-Up, dejando cada host con 256GB de RAM, para asi soportar un aumento del 100% en el consumo de memoria?  Este escenario es bastante realista considerando el poder de computo que entregan las CPUs de 6-cores, y al hecho de que no es nada raro en la actualidad tener servidores en formato rack con 256GB de RAM, o incluso más.  Entonces, analicemos nuevamente el escenario.
  • 4 CPUs de 6 Cores por host  (32 CPUs en el Cluster)
  • 256GB RAM por host (2TB RAM en el Cluster)
  • Licencias Enterprise para 32 CPUs
  • 70% de uso de memoria (vRAM) en el cluster (alrededor de 1.4GB)


Con el modelo de licenciamiento de vSphere 5, el mismo cluster necesitará:
  • 45 Licencias Enterprise para 32 CPUs.
  • ~1.4TB de vRAM (32GB de vRAM por cada licencia Enterprise)
En este caso, en vSphere 5 el cliente obligatoriamente tendría que adquirir 13 licencias adicionales para poder soportar toda la vRAM requerida en el Cluster.  En vSphere 4 no sería necesario una inversión de este tipo, ya que hasta hace poco, la limitación estaba dada por el numero de cores en la CPU, y no por la cantidad de RAM utilizada en el host.

Este ejemplo ilustra el porqué, segun mi opinion, se estaría privilegiando un modelo Scale-Out, por sobre un modelo Scale-Up.  No obstante, la linea entre uno y otro modelo no es del todo clara, considerando que si hace un par de años, un host con 64GB de RAM era considerado un host de grandes recursos, hoy no es raro ver hosts con 128GB de RAM, y que perfectamente podrian ser considerados servidores de medianos recursos, si consideramos que podemos contar con hosts con muchos más recursos en la actualidad.



Es de esperar que la discusión sobre el nuevo modelo de licenciamiento se mantenga con el pasar de las semanas.  Solo el tiempo dirá si VMware dió en el clavo con este nuevo modelo de licenciamiento, o si tendrá que realizarle algunas mejoras.

Un detalle más profundo del nuevo modelo de licenciamiento lo pueden encontrar en el siguiente link:
http://www.vmware.com/files/pdf/vsphere_pricing.pdf