Vmware vSphere

Capítulo 1: Primeros pasos en la certificación VMware vSphere™ VCP550™ ¿Por qué la virtualización es tan importante? En 1998, VMware descubrió una tecnología que fue considerada hasta entonces algo imposible de lograr, virtualizar la plataforma x86. Esta solución fue una combinación de traducción binaria (binary translation) y ejecución directa (direct execution) directamente en el procesador, lo que permitió que múltiples sistemas operativos “Guest” se pudiesen ejecutar a la vez en el mismo hardware físico, totalmente aislados unos de otros y con una "sobrecarga" en la capa virtualización relativamente pequeña. El ahorro que decenas de miles de empresas han obtenido con el despliegue de esta tecnología, está impulsando, de una forma pronunciada y rápida, la adopción de la tecnología de virtualización desde el centro de datos hasta el escritorio. Resolver el problema de la proliferación de servidores, la falta de espacio, el consumo de energía y la refrigeración en las salas de servidores mediante la sustitución de servidores de aplicaciones individuales por máquinas virtuales consolidadas en un número mucho menor de equipos físicos, son sólo algunos de los principales beneficios de la virtualización de servidores. Otros de los beneficios de la virtualización son: 

Mejor uso del hardware del servidor mediante el despliegue de nuevos servidores en máquinas virtuales, evitando añadir más servidores físicos infrautilizados al centro de datos.



Reducir drásticamente el tiempo de aprovisionamiento de nuevos servidores en máquinas virtuales, pasando a minutos en lugar de días o semanas necesarias para aprovisionar un servidor físico. Asimismo, como la capacidad de procesamiento en los servidores ha aumentado de manera constante en los últimos años, y no cabe duda que seguirá aumentando, la virtualización ha demostrado ser una tecnología muy potente para simplificar el despliegue de software y servicios, dotando al Centro de Datos de mucha más agilidad, flexibilidad y, lo que quizás haya pasado desapercibido pero no por ello es menos importante, la reducción significativa de los costes energéticos y el impacto medio ambiental. Este libro pretende descubrirte todos los secretos en la instalación, configuración y gestión de VMware vSphere™ 5 y, de paso, prepararte para la certificación de VMware VCP510.

¿Cómo conseguir la certificación VCP™ 510? Para obtener la titulación VMware Certified Professional debes seguir tres pasos muy sencillos: 1. Participar en un curso autorizado y oficial VMware para adquirir experiencia. Este curso es impartido por un instructor oficial VMware, el cual te enseñara las mejores prácticas en la instalación, configuración y gestión de VMware vSphere™ 5.x Los cursos aceptados son: VMware vSphere 5.x: Install, Configure and Manage v5.x VMware vSphere 5: What´s New (Este curso es necesario solo para los candidatos que ya han pasado la certificación VCP4) 2. Adquirir experiencia con los productos VMware. Aquellos profesionales que no han tenido experiencia previa con los productos VMware, les resultará más difícil pasar el examen VCP™ 510.

3. Inscribirse y aprobar el examen oficial. Para inscribirse en el examen VCP™ 5 (VMware Certified Professional), has de darte de alta en VMware en la siguiente dirección: http://mylearn.vmware.com/mgrReg/plan.cfm?plan=45082&ui=www_cert Para ver los cursos autorizados oficiales por VMware, donde se imparten los cursos oficiales, puedes visitar la siguiente dirección web: http://www.jmgvirtualconsulting.com/formacion

Algunas preguntas frecuentes sobre VMware™ VCP™ ¿Cuál es la “Hoja de Ruta” para obtener la certificación VCP™ en vSphere™?

Hay cuatro caminos posibles para lograr la certificación VCP5™ en vSphere™ 5. 1. Si eres nuevo en el mundo VMware: 

Asiste al curso oficial VMware vSphere™ 5: Install, Configure and Manage.



Aprueba el examen VCP510 en vSphere™ 5. 2. Si eres actualmente un VCP3 en VMware Infrastructure 3:



Asiste al curso oficial VMware vSphere™ 5: Install, Configure and Manage o al curso oficial What´s New 5.



Aprueba el examen VCP510 en vSphere™ 5. Esta opción, solo estará disponible hasta el 29 de Febrero del 2012. 3. Si eres actualmente un VCP4 en VMware ESX/ESXI 4.x:



Aunque no hay ninguna limitación imporante, es importante destacar que si estará limitado en cuanto al tiempo transcurrido desde que hiciste el curso de formación hasta cuando quieras presentarte al examen VCP510™ en vSphere™ 5. La ultima fecha que me ha dado VMware es febrero del año 2012.



Asiste al curso oficial VMware vSphere™ 5: What´s New 5. 4. Si no eres VCP pero has asistido a uno de los cursos requeridos para la certificación oficial VCP4™ (VMware Install, Configure and Manage):



Asiste al curso VMware vSphere™ 5: What´s New 5.



Aprueba el examen VCP™ en vSphere™ 4.x.



Aprueba el examen VCP™ en vSphere™ 5. Puedes ver los plazos y el “Last minute” en la siguiente URL: http://www.jmgvirtualconsulting.com/formacion ¿Cómo puedo saber si el curso es oficial VMware? Los cursos que no estén autorizados por VMware, no cumplen los requisitos para la certificación VCP5 en vSphere™ 5. Asegúrate de asistir a un curso oficial VMware confirmando que dicho curso aparece en la página web de VMware: http://mylearn.vmware.com/mgrreg/index.cfm ¿Realmente necesito asistir al curso oficial para poder obtener la certificación VCP5™ en vSphere 5™? El curso oficial VMware es un requisito obligatorio para la certificación. VMware no hace ninguna excepción en este requisito. ¿Cómo me registro para el examen de certificación VCP510™ en vSphere 5™?

El examen VMware Certified Professional es administrado por Pearson VUE, un centro autorizado externo. Pearson VUE tiene más de 3.500 centros de exámenes autorizados en todo el mundo. ¿Cuántas preguntas hay en el examen VCP510™ de vSphere™ 5? En el examen hay 85 preguntas tipo test. Tienes 90 minutos para responder a todas las preguntas. En países donde el inglés no es el primer idioma, los candidatos recibirán automáticamente 30 minutos adicionales. Necesitas una puntuación de 300 o más para poder aprobar el examen, siendo 500 la puntuación máxima. ¿Qué ocurre si suspendo el examen? Podrás intentarlo de nuevo siempre que quieras, pero tendrás que esperar 7 días antes de intentarlo otra vez. Cada intento exige un nuevo pago para cubrir el coste del examen. ¿Cómo puedo saber lo que abarca el examen VCP™510? En la dirección web adjunta, podrás encontrar una guía oficial VMware (VCP5 Exam Blueprint) sobre la materia que se cubre en el examen. Usa esta guía como referencia para preparar el examen: http://mylearn.vmware.com/portals/certification/ ¿Hay alguna forma de practicar el examen antes de presentarse al examen oficial? VMware ha puesto a disposición del público en general, una dirección web donde puedes practicar antes de presentarte al examen oficial: http://mylearn.vmware.com/mgrSurvey/assessLogin.cfm

Recuerda que las preguntas mostradas en este simulacro, solo son meramente orientativas. No obstante, te servirán para saber si estás preparado para presentarte al examen o, por el contrario, si necesitas estudiar un poco más y retrasar la fecha del examen.

Capítulo 2: Instalación vSphere™ 5.x En esta primera sección verás una introducción a la virtualización y la instalación de VMware vSphere™ ESXi 5.x, los mínimos y máximos tanto soportados como certificados por VMware vSphere™ ESXi 5/ vCenter Server™ 5.x, la nueva versión de vCenter Server Appliance™ para entornos Linux, así como los mínimos y máximos para las máquinas virtuales en vSphere™ 5.x ¿Cómo es la virtualización con VMware vSphere™ 5.x?

Los servidores y los desktops cada día son más potentes y el software de virtualización de servidores ha demostrado, una vez más, ser una tecnología indispensable para simplificar el centro de datos y dotarlo de inteligencia propia. En un entorno físico tradicional, el sistema operativo y el software asociado se están ejecutando en un único servidor físico. Este modelo de una aplicación por servidor puede

llegar a ser, y de hecho lo es en muchos casos, inflexible e ineficiente. Esta relación 1:1 precisamente es la que hace que servidores de muchos centros de datos que estén infrautilizados, alcanzado tan solo el uso de entre un 5 y un 10% de los recursos físicos de dichos servidores. Asimismo, el aprovisionamiento de servidores físicos en un centro de datos es un proceso costoso en cuanto al tiempo necesario que se dedica a aprovisionar un servidor físico. En un entorno no virtualizado has de dedicar tiempo a comprar nuevo hardware, enrackar los servidores, instalar el sistema operativo y las aplicaciones. Con el software de virtualización de servidores podemos transformar hardware en software. De esta forma, podemos ejecutar diferentes sistemas operativos, como por ejemplo Windows, Linux, Solaris, incluso MS-DOS, simultáneamente y en el mismo servidor físico. Así, cada contenedor, dotado de su sistema operativo “Guest” o invitado, es llamado virtual machine (máquina virtual en inglés) o VM como acrónimo. Pero la virtualización de servidores, no es un software de simulación o emulación, como el software de training de Cisco que simula un router de Cisco para poder hacer prácticas, es un software de ejecución. Veamos ya algunas de las diferencias importantes de esta nueva versión de VMware vSphere con las versiones anteriores. Primero, y quizás uno de los cambios más importantes en vSphere™ 5 es que la versión vSphere™ ESX ya no está disponible. También, ahora con la nueva versión de ESXi™ 5, es posible instalar la imagen de un ESXi 5 directamente en la memoria del host físico usando una nueva funcionalidad llamada vSphere™ Auto Deploy ESXi, de la cual hablaremos más adelante en este libro. VMware vSphere™ 5 incluye una nueva versión para su sistema de archivos llamada VMFS-5 el cual, y a diferencia de las versiones anteriores, solo incluye un block size de 1MB a la hora de formatear el datastore. VMware vSphere™ Storage Appliance - de las siglas en inglés VSA - es otra de las nuevas funcionalidades incluidas en la esta versión. Aunque hablaremos de esta nueva funcionalidad más adelante, recordarte que el VSA Manager ha de ser instalado en tu servidor de vCenter para que puedas configurar esta nueva herramienta. VMware vSphere™ ESXi Dump Collector te permitirá recoger todos los log score dumps de tus servidores ESXi. Otra nueva funcionalidad en VMware vSphere™ 5.

Para poder ver el video tutorial de instalación de un servidor ESXi 5 y muchos más videos tutoriales, entra en nuestra página web dedicada en exclusiva al contenido multimedia extra de este libro en http://www.josemariagonzalez.es/video-tutoriales/formacion-vsphere-5 Alternativamente, también puedes ver videos tutoriales de instalación y configuración de VMware vSphere ESXi 5, así como manuales, artículos y posts interesantes para preparar el examen de certificación oficial VCP™510 en la página oficial del blog de virtualización y cloud computing en español en http://www.josemariagonzalez.es/ ¿Cómo es una máquina virtual en vSphere™ 5?

Una máquina virtual en VMware vSphere™ 5, es básicamente un conjunto de ficheros planos y binarios los cuales conforman la máquina virtual (MV) completa con su sistema operativo y aplicaciones incluidas. Los ficheros más importantes que componen una máquina virtual son: el fichero de configuración (.vmx), el fichero de disco virtual (.vmdk), el fichero BIOS de la máquina virtual (.nvram) y el fichero de log (.log). El tamaño del fichero swap de la máquina virtual (.vswp) es igual a la cantidad de memoria RAM configurada en dicha máquina virtual. Recuerda que este fichero se genera cuando la máquina virtual se arranca y se borra cuando se apaga. Con la nueva versión vSphere™ ESXi 5, el máximo número de discos virtuales por host se ha aumentado a 2048 discos virtuales. El tamaño máximo de un disco virtual que puedes configurar en una máquina virtual es de 2TB menos 512Bytes (espacio necesario del overhead del disco virtual).! En cuanto a la memoria RAM asignada a las máquinas virtuales, ahora es posible asignar hasta un 1TB de memoria RAM física de tu host, el cual es el tamaño máximo que un host ESXi físico puede tener configurado.

Asimismo, es posible tener hasta un máximo de 512 máquinas virtuales por servidor ESXi. El número máximo de adaptadores SCSI para una máquina virtual es de cuatro por máquina virtual. A cada máquina virtual le puedes conectar un controlador IDE máximo al cual puedes conectar hasta 4 dispositivos IDE. En cuanto a dispositivos xHCI USB se refiere, es posible conectar hasta 20 controladores USB por máquina virtual. Sin embargo, solo es posible conectar un dispositivo USB 3.0 por máquina virtual. A fecha de publicación de este libro, VMware vSphere™ ESXi 5 aun no soporta dispositivos USB 3.0 conectados directamente en el servidor. Por último, puedes configurar hasta 128MB de memoria RAM destinada a la memoria de video por máquina virtual. Asimismo, el máximo número de vCPUs (virtual CPUs) por host ESXi es de 2048, siendo 25 el número máximo de vCPUs por core. El número máximo de vCPUs que podrás asignar a tus máquinas virtuales es de 32 vCPUs. Nota que para llegar a este número de vCPUs también el sistema operativo tiene que soportarlo. Si estas usando este libro para prepararte el examen oficial de certificación VCP™510, asegúrate bien que conoces los mínimos y máximos de una máquina virtual y prepárate para poder responder preguntas tipo como: ¿Cuántos puertos serie, paralelo, CDROMs, floppies, NICs, puede llegar a tener una máquina virtual? Asimismo, recuerda que aunque una máquina virtual puede tener como número máximo 10 tarjetas virtuales, solo podrás conectar cuatro tarjetas máximo durante la creación de tus máquinas virtuales con el wizard de creación de máquinas virtuales de vCenter Server 5. VMware vSphere™ 5 permite crear máquinas virtuales usando dos wizards: Typical yCustom. Si seleccionas el método Typical, el wizard solo te pedirá el nombre, DataStore para la máquina virtual, sistema operativo y el tamaño del disco virtual, sin embargo no tendrás la opción de configurar otras opciones como el número de vCPUs, la versión del hardware virtual, la cantidad de memoria y un largo etcétera. Por consiguiente, es una mejor práctica seleccionar la opción Custom para poder personalizar de una forma más profunda la configuración hardware de tus máquinas virtuales.

Aviso: Recuerda que una máquina virtual en vSphere™ 5 soporta hardware virtual versión 8 y que este hardware virtual no es compatible con versiones anteriores a vSphere™ 5. Por consiguiente, si quieres tener un entorno mixto, ESX/ESXi 4.x y vSphere™ ESXi 5, has de dejar el hardware virtual de tus máquinas virtuales con la versión 7 correspondiente a la versión 4 de VMware vSphere™ ESX/ESXi 4. Para terminar con un dato más sobre las máquinas virtuales y su configuración, el número máximo de virtual SCSI targets por máquina virtual es de 60. Para poder ver el video tutorial de instalación de una máquina virtual en un servidor ESXi 5, entra en nuestra página web dedicada en exclusiva a los videos tutoriales de contenido multimedia de este libro en http://www.josemariagonzalez.es/video-tutoriales/formacion-vsphere-5 Alternativamente, también puedes ver los videos tutoriales de instalación y configuración de VMware vSphere ESXi 5 para preparar el examen de certificación oficial VCP™510 en la página web oficial de YouTube en: http://www.youtube.com/blogvirtualizacion ¿Cuál es la diferencia entre un software de virtualización basado en un hipervisor y la virtualización basada en host?

La virtualización basada en hipervisor (también denominada Bare-Metal), como por ejemplo vSphere™ ESXi, Microsoft HyperV o Citrix XenServer, está instalada en un servidor físico sin la necesidad de que exista un sistema operativo (Windows o Linux) instalado previamente. No obstante, la virtualización basada en host, como por ejemplo VMware Server, VMware Workstation o VMware Fusion, necesita previamente un sistema operativo instalado, ya sea Microsoft Windows, Mac OS o Linux. Hay varias razones por las que un cliente elegiría el software de virtualización basado en hipervisor, como por ejemplo vSphere™ ESXi, en lugar de un software de virtualización basado en host, como por ejemplo VMware Server. Primero, con el software de virtualización basado en hipervisor, es posible actualizar las máquinas virtuales que se albergan en los servidores físicos sin ningún tipo de downtime. Segundo, es muy probable que la empresa ya esté virtualizando varios servidores físicos y quiera tener la opción de tener una gestión centralizada. Por último, un hipervisor baremetal siempre ofrece una mayor confiabilidad y rendimiento al no precisar de un sistema operativo Host lo cual se elimina un posible punto de fallo a nivel de hardware.

Aunque la virtualización basada en hipervisor ofrece un mayor rendimiento, es la virtualización basada en host la que ofrece una compatibilidad con el hardware mucho más amplia, es decir, si puedes instalar Windows o Linux en tu servidor físico entonces podrás instalar la solución de virtualización basada en host. Por consiguiente, una de las mayores diferencias de la solución de virtualización basada en hipervisor y la solución de virtualización basada en host - aparte de las obvias ya mencionadas - , es que esta última tiende a tener una lista de hardware certificado mucha más amplia. Sin embargo, la virtualización basada en hipervisor tiene un mayor rendimiento, mayor fiabilidad y estabilidad, mayor escalabilidad y mucha más funcionalidad. Para ver más información sobre los tres factores más importantes a la hora de elegir un hipervisor para el software de virtualización entra en este enlace:http://www.jmgvirtualconsulting.com/ A diferencia de las versiones anteriores a VMware vSphere™ ESXi, solo las variables, memoria reservada y memoria configurada (Reserved Memory y Configured Memory) afectan ahora al incremento o reducción del memory overhead, el cual es una “penalización” a nivel de la capa de memoria que todos tenemos que pagar por el simple hecho de virtualizar nuestro servidor físico. Esta penalización se mide en megas de memoria RAM y son megas de memoria que dejamos de ver y de usar en nuestro servidor físico. Como consecuencia de este “impuesto revolucionario” que existía por el simple hecho de virtualizar nuestro servidor, VMware vSphere™ ESXi 5 usa una nueva funcionalidad llamada VMX swap con la que es posible reducir el memory overhead de tus máquinas virtuales. Básicamente, con una nueva tecnología llamada VMX swap, el tamaño del memory overhead se crea en un fichero swap con lo que este espacio de memoria puede llegar a ser re-utilizado por el hipervisor. Esta técnica posibilita un aumento en el ratio de consolidación de VMware vSphere™ 5 con respecto a versiones anteriores de VMware. ¿Cuáles son los nuevos prerrequisitos hardware en VMware vSphere™ ESXi 5? A día de hoy, es posible instalar VMware vSphere™ ESXi 5 en cualquier tipo de servidor de nueva generación. Asimismo, la lista de compatibilidad de hardware para VMware vSphere™ ESXi 5 ha aumentado considerablemente en esta última versión, debido principalmente, a que ESXI es la única versión disponible en vSphere™ 5. Estos son los requerimientos de hardware mínimos para poder instalar VMware vSphere™ ESXi 5:

Procesador: Solo CPUs de 64-bit x86, Intel o AMD, máximo 160 CPUs (cores o hyperthreads). Memoria: 2GB de RAM mínimo, 1TB máximo. Red: Una o más tarjetas Gigabit Ethernet. Las tarjetas Ethernet de 10Gb también están soportadas. El número máximo de tarjetas de 1Gb Ethernet (tg3 de Broadcom) por servidor es de 32. Controladora de disco: Controladora SCSI, controladora FC (Fibre Channel), controladora iSCSI, controladora RAID interna, SAS y SATA. Almacenamiento: disco SCSI, LUN (Logical Unit Number) FC, disco iSCSI o RAID LUN con espacio disponible sin particionar. Es posible instalar VMware vSphere™ ESXi 5 en una LUN de la SAN, método conocido con el nombre de Boot from SAN (BFS). BFS está soportado en Fibre Channel SAN, en iSCSI (iniciadores de software iSCSI y dependent hardware iSCSI) y en FCoE - de las siglas en inglés Fibre Channel over Ethernet - para aquellas cabinas de almacenamiento que estén incluidas en la matriz de compatibilidad. VMware vSphere™ ESXi 5 puede configurarse con un máximo de 256 LUNs de FC (Fibre Channel). Recuerda que los dos requerimientos necesarios para poder hacer boot from SAN son: 1. La BIOS de la HBA (Host Bus Adapter) debe estar habilitada. 2. Debes seleccionar la HBA con el número de slot PCI menor. Aviso: Recuerda que si haces una actualización de ESX/ESXi 4.1 a VMware vSphere™ ESXi 5, aquellos puertos no conocidos - no listados en la pestaña security profile - que se hayan abierto con el comando de consola esxcfg-firewall en tu servidor ESX/ESXi 4.x, no permanecerán abiertos después del upgrade. Asimismo, VMware vSphere™ ESXi 5 soporta un máximo de 8 dispositivos PCI/PCIe en modo VMDirectPath passtrough. Sin embargo, una máquina virtual no puede tener configurados más de dos dispositivos PCIx/PCIe configurados como VMDirectPath. Si usas iniciadores de software iSCSI para hacer BFS y tu administrador deshabilita este iniciador de software iSCSI, el servidor ESXi 5 volverá habilitar dicho iniciador la próxima vez que se reinicie el servidor para poder hacer BFS.

Algunos aspectos importantes que deberías saber sobre la diferencias y similitudes entre VMware vSphere™ ESX y ESXi 5 En VMware ESX y ESXi hay más similitudes que diferencias, aunque quizá, el beneficio más importante de ESXi sobre ESX es que ESXi aumenta la seguridad y la fiabilidad de nuestro hipervisor. VMware ESXi 5 tiene mucho menos código (76MB de footprint) que parchear y, por lo tanto, tiene una superficie de ataque mucho menor. La versión ESX ha desaparecido como tal con el lanzamiento de la versión de VMware vSphere 5. La versión VMware vSphere™ ESXi 5 como la versión ESX comparten el mismo VMkernel y VMM - de las siglas en ingles Virtual Machine Manager -, aunque hay algunas connotaciones muy importantes a destacar: 1. Extensiones VMkernel: Mientras que en la versión clásica de VMware ESX podías instalar agentes y drivers de empresas de terceras partes, en ESXi solo se permite instalar extensiones en el VMkernel que hayan sido previamente firmados digitalmente por VMware. Esta restricción ayuda mucho a asegurar el entorno y mantener el código seguro en el VMkernel. 2. Muchos de los agentes y deamons que se ejecutaban en el Service Console (COS) en la versión clásica del ESX, han sido convertidos y embebidos para que se ejecuten directamente en el VMkernel del ESXi. 3. La imagen del sistema en ESXi - system image - es una imagen bootable que es cargada directamente en memoria física. El propio “installer” usa esa misma imagen de sistema para copiar los ficheros en un disco local para futuros arranques. Debido a que la imagen del sistema es cargada en memoria, la versión ESXi no necesita obligatoriamente de un disco local cuando este se está ejecutando. Esto significa que el disco local podría fallar pero, sin embargo, nuestro VMkernel continuaría ejecutándose. 4. La partición scratch. Es una partición de 4GB virtual y de tipo FAT (VFAT) la cual es creada por defecto en el primer disco local del servidor ESXi, si tu servidor tiene discos locales, claro. Si el servidor no tiene ningún disco local, esta partición no existirá pero se “rediccionara” el directorio scratch a una partición de tipo ramdisk llamada /tmp. Esto significa que el contenido de esta partición scratch no “sobrevivirá” a un reinicio del servidor ESXi. Por consiguiente, el servidor ESXi puede necesitar hasta 4GB de memoria RAM para almacenar esta partición scratch.

5. Y por último, pero no por ello menos importante, tenemos la partición bootbank. Esta partición contiene la imagen del sistema sobre un sistema de archivos. Si hay un disco local al cual ESXi pueda escribir, este almacena dos copias del bootbank. Pero ojo, solo una es montada en la estructura del sistema de archivos del ESXi en el directorio /bootbank. La segunda copia se usa únicamente durante actualizaciones para mantener una segunda copia como backup en caso de problemas durante actualizaciones del sistema. Por otro lado, en VMware vSphere™ ESXi 5 es posible hacer una instalación de la imagen directamente en la memoria del servidor físico usando una nueva funcionalidad llamada vSphere™ Auto Deploy ESXi Installation Option. Con VMware vSphere™ Auto Deploy podrás acceder al fichero de instalación desatendido (answer file) via CIFS, SFTP o HTTP. VMware vSphere™ ESXi 5 soporta la designación de capacidad de disco dinámicamente mediante una funcionalidad llamada vStorage Thin Provisioning. Ahora, con VMware vSphere™ ESXi 5 es posible hacer una migración en caliente con Storage vMotion de una máquina virtual que tiene snapshots. VMFS-5 soporta un máximo de 9.000 discos virtuales por datastore. Solo existe una única opción de tamaño de bloque para un datastore formateado con la versión 5 de VMFS. Este block size es únicamente de 1MB y te permite crear discos virtuales con un tamaño de hasta 2Gb. Ahora en VMware vSphere™ ESXi 5 y VMFS-5 es posible tener hasta un máximo de 4 ficheros swap por máquina virtual. También ahora es posible con VMware vSphere™ ESXi 5 hacer un “unmount” del datastore siempre y cuando se cumplan los tres requisitos siguientes: 1. El datastore no puede contener ninguna máquina virtual. 2. El datastore no puede ser usado por vSphere™ HA heartbeat. 3. El datatore no puede pertenecer a un datastore clúster. VMware vSphere™ ESXi 5 soporta ahora hasta 3.000 máquinas virtuales por clúster HA/DRS con independencia del número de servidores ESXi que hayas configurado en tu clúster. Por último, recuerda que VMFS-5 “solo” soporta 256 volúmenes o datastores VMFS por servidor ESXi. Aviso: Cuando actualizas VMFS-3 a la versión VMFS-5, la configuración del block size de tu datastore VMFS-3 es heredara, es decir, si tu datastore VMFS-3 fue configurado con un block

size de 4MB, al actualizar a la versión VMFS-5 el block size seguirá siendo de 4MB. Nota que el block size de un datastore VMFS-5 no actualizado no puede ser distinto de 1MB. Diferentes tipos de instalación en vSphere ESXi 5

VMware vSphere™ ESXi 5 solo es posible instalarlo en modo texto, a diferencia de VMware ESX donde era posible instalarlo también en modo gráfico. Una nueva funcionalidad en VMware vSphere™ ESXi 5 llamada Image Builder te permitirá hacer instalaciones personalizadas de tu ESXi así como asociar actualizaciones del binario del ESXi a dicha personalización. Hablaremos del Image Builder más adelante en este libro. Solo apuntar que el formato de los paquetes que usa VMware vSphere™ ESXi Image Builder se llaman VIB - de las siglas en inglés vSphere™ Installation Bundle. Si usas la nueva funcionalidad llamada VMware Auto Deploy, recuerda que los logs de tu servidor ESXi serán almacenados en memoria con lo que al reinicializar tu servidor perderás estos logs por defecto. Para definir profiles de imágenes para tus servidores ESXi con Auto Deploy tendrás que usar cmdlet incluidos en el vSphere™ Power CLI image builder. Es posible también actualizar servidores ESXi con la utilidad Enterprise llamada VMware Update Manager (VUM), de la que hablaremos también en este libro. Una mejora practica antes de actualizar un servidor ESXi, es guardar la configuración del servidor que vas actualizar con el siguiente comando de vCLI: vicfg-cfgbackup -s Aviso: Con VMware vSphere™ ESXi 5, el número total de caminos de FC (Fiber Channel) por servidor se han aumentado hasta los 1.204. En VMware vSphere™ ESXi 5 el máximo número de servidores conectados a volúmenes VMFS es de 64 hosts por volumen VMFS. Asimismo, el número máximo de datastores conectados a un Cluster HA/DRS es de 32. Tampoco es posible actualizar varios servidores ESXi en un clúster simultáneamente, es decir, solo está permitido actualizar un servidor ESXi a la vez dentro de tu clúster.

Datos importantes sobre el nuevo installer en vSphere™ 5

Durante la instalación de vSphere™ ESXi 5, el installer de VMware, escanea no solo los discos locales conectados al servidor físico ESXi, sino que también hará un escaneo de los discos de tu SAN de FC y los mostrara si este tiene acceso a ellos. Por consiguiente, y para evitar la instalación del binario de ESXi en una de tus LUNs de la SAN FC, recuerda esta “Best Practices” de VMware para evitar la sobre escritura de una LUN: Establece o solicita al administrador SAN de tu empresa un “LUN Masking” o mejor aún, si vas a instalar el binario en discos locales, desconecta los cables de la SAN de tu servidor ESXi. Además, está mejor práctica reduce el tiempo que necesita elinstaller de VMware en buscar discos conectados al sistema. Si estas instalando un servidor ESXi en un disco que ya contiene una versión previa a la versión vSphere™ 5, el installer te da la opción de actualizar esa versión. Cuando configuras una cabina SAN de FC con vSphere™, asegúrate de seguir las mejores recomendaciones: 1. Cada LUN debería contener solo un DataStore VMFS. 2. Cada LUN debería ser presentada a todos los servidores ESXi con el mismo LUN ID. Hay cuatro opciones o métodos para instalar la nueva versión de VMware vSphere™ ESXi 5: 

Usando vSphere Auto Deploy



Mediante una instalación via script



Actualizando un servidor ya existente con VUM



Haciendo una instalación interactiva como se muestra en la imagen anterior.

Esta última opción es el método de instalación recomendado cuando has de instalar un número pequeño de servidores VMware vSphere™ ESXi 5. VMware vSphere™ 5 ha dejado de soportar máquinas virtuales de 32bit y por consiguiente VMM de 32bits. Solo Virtual Machine Monitors de 64 bits pueden ejecutar sistemas operativos de 32bits. Por consiguiente, el uso exclusivo de un VMM de 64bits en vSphere™ 5 requiere instrucciones específicas a nivel de CPU llamadas LAHF y SAHF las cuales no se encuentran en arquitecturas de 32bit más antiguas. LAHF y SAHF solo están soportados en vSphere™ 5. Aviso: Una vez instalado, un servidor VMware vSphere™ ESXi 5 puede tener hasta256 LUNs FC (Fiber Channel) por servidor. Asimismo, el número máximo del ID en FC es de 255 pues los IDs de FC empiezan por el número 0 y no por el número 1. Sin embargo, el número máximo de caminos iSCSI que un servidor ESXi pues ver es de 1.024. Una instalación inicial de vSphere™ ESXi usa el formato GPT - de las siglas en inglésGUID Particion Table en lugar del formato MBR - de las siglas en ingles Master BootRecord - lo cual permite instalar ESXi 5 en discos con un tamaño superior a 2TB. No obstante, si actualizas de versión VMware ESX/ESXi 4.x a ESXi 5 no se usara el formato GPT, sino que se mantendrá el formato MBR. Aspectos importantes sobre la configuración y la seguridad de vSphere ESXi™ 5

Ahora VMware vSphere™ ESXi 5 incluye dos nuevas funcionalidades para aumentar la seguridad del VMkernel: 1. Memory Hardening: El kernel del ESXi, aplicaciones user-mode y ejecutables como drivers y librerías están localizadas en zonas de memoria aleatorias para evitar que

software del tipo troyanos averigüen de una forma sencilla la localización de estas zonas de memoria. 2. Kernel Module Integrity: Los módulos, drives y aplicaciones de ESXi son “firmados” digitalmente para asegurar la integridad de estos una vez que el VMkernel los carga en memoria. Asimismo, a diferencia de las versiones VMware ESX 4.x, en VMware vSphere™ ESXi 5 es posible hacer boot de tu servidor ESXi desde un disco USB externo. También, ahora es posible instalar tus servidores ESXi con la opción de VMware Auto Deploy, sobre todo cuando tienes un número de host importante que instalar. De esta forma, acelerarás la fase de instalación del binario de ESXi y el despliegue de tus máquinas virtuales. Si haces una actualización de la versión ESX 4.x a la versión ESXi 5 el portgroup tipoService Console (solo disponible en versiones ESX) será borrado ya que en los servidores ESXi no existe un Service Console. Asimismo, el portgroup de gestión en ESXi es llamado Management Port. Recuerda antes de actualizar un servidor ESXi hacer una copia de seguridad de su configuración con el comando vicfg-cfgbackup desde el vCli. Desde el punto de vista de almacenamiento compartido SAN iSCSC, el número máximo de LUNs iSCSI que puedes conectar a un servidor ESXi es de 256. Otro de los límites que han cambiado en esta nueva versión de VMware vSphere™ ESXi 5 con respecto a las versiones anteriores, es que ahora es posible tener arrancadas hasta 2.048 máquinas virtuales por volumen VMFS. También, ahora es posible activar - y está soportado - el modo soporte (TSM - de las siglas en inglés Tech Support Mode) de modo que podrás entrar vía SSH a tu servidor ESXi. Puedes activar el modo TSM desde la DCUI (de las siglas en inglés Direct Console User Interface) o con el vSphere Client a través del panel Security Profilelocalizado dentro de la pestaña de Configuration. Una vez entres en la consola de tu servidor ESXi, via comando podrás ver los logs de tu sistema, configurar las propiedades de los servicios de DNS, NTP, arrancar máquinas virtuales, apagar servidores ESXi y un largo etcétera. Sin embargo, una de las pocas tareas que no podrás hacer desde consola es la de poner tu host ESXi en modo mantenimiento. Para poder ver una guía de referencia de todos los comandos disponibles por consola en la versión ESXi 5.0, te recomiendo que veas el episodio número 31 de nuestro canal de televisión web sobre la virtualización y el cloud computing en español en la siguiente dirección: http://www.virtualizacion.tv

Asimismo, con el fin de mejorar la seguridad del servidor ESXi, VMware ha añadido un firewall embebido en el VMkernel. A diferencia de las versiones anteriores, este firewall no está basado en IPtables de Linux. Aviso: El máximo número de tarjetas HBA de FC soportadas por un servidor ESXi es de ocho. También, el número máximo de CPUs lógicas por servidor ESXi 5 ha aumentado a las 160 por host. Si aún tienes servidores ESX en tu entorno virtual y necesitas aplicar parches en el Service Console del ESX, debes de asegúrate de aplicar dichos parches solo y únicamente cuando VMware haya hecho público las actualizaciones y siempre que sea sugerido por personal autorizado de VMware o por el equipo experto de VMware llamado VMware Security Advisories. Para poder recibir alertas de seguridad sobre vulnerabilidades del software de VMware, puedes suscribirte en esta dirección: http://www.vmware.com/security. Tipos de almacenamiento soportados en VMware vSphere™ ESXi versus funcionalidad

En la tabla adjunta, se muestran los cinco tipos de almacenamiento soportados en VMware vSphere™ ESXi 5, así como las diferentes funcionalidades soportadas por cada tipo de almacenamiento. Con relación a la conectividad iSCSI y su iniciador de software iSCSI, el máximo número de iSCSI targets es de 265. Asimismo, no es posible crear más de un NIC Teaming con el iniciador de software iSCSI con más de 8 vmnics (uplinks o tarjetas de red físicas disponibles en el servidor ESXi). Solo es posible tener un número máximo de ocho caminos por LUN para los volúmenes VMFS conectados via software o hardware iSCSI. En cuanto al tamaño máximo de un volumen VMFS para la versión 3 (VMFS-3) es de 2TB menos 512Bytes de espacio con un block size de 8MB. Sin embargo, en VMFS versión 5 (VMFS-5) el tamaño del block size es de tan solo 1MB, aunque es posible crear ficheros .vmdk con un tamaño máximo de 2TB. Recuerda que en VMFS versión 3 y con un block size de

1MB, el tamaño de disco de la máquina virtual (.vmdk) no podrá superar los 256GB de espacio en disco. Asimismo, el tamaño máximo para un volumen RDM (de las siglas en inglés Raw Device Mapping) en VMFS-5 es de 64TB, siempre y cuando uses la funcionalidad de extenders a nivel VMFS, de la cual hablaremos más adelante en este libro, y el modo de compatibilidad de este RDM sea físico. Sin embargo, para un volumen RDM VFMS-5 en modo de compatibilidad virtual, el tamaño máximo es de 2TB menos 512 bytes. VMware vSphere™ ESXi 5 usa el protocolo NFS versión 3 para comunicarse con cabinas de tipo NAS. Nota que aunque NFS también puede usar la versión 4, esta no está soportada por VMware. En la versión VMware vSphere™ ESXi 5, ahora es posible montar hasta 256 volúmenes NFS por host. Con relación a los ficheros swaps de las máquinas virtuales, el tamaño máximo que puede alcanzar este tipo de ficheros es de 1TB por máquina virtual, siempre y cuando, configures tu máquina virtual con 1TB de memoria RAM. Puedes ver más información sobre la configuración del block size en VMFS-5 en nuestro canal oficial de YouTube: VMware vSphere 5.0 en entornos SAN iSCS En cuanto al número máximo de targets que un servidor host puede ver con un adaptador Broadcom 10GB iSCSI es de 128 targets. El número máximo de tarjetas 1GB Ethernet Broadcom (bnx2) que un servidor host ESXi puede tener es de 16. Aviso: El número máximo de caminos por LUN de FC es de 32. Y si te pica la curiosidad por saber cuál es el número máximo de ficheros que puedes tener en un volumen VMFS-5, es de 130.690 ficheros, aunque me temo que muy probablemente no alcances nunca ese límiteJ. En VMFS-3 el máximo número de ficheros era de 30.720 ficheros. Diagnosticando un problema en vSphere 5 Para poder diagnosticar un problema con vSphere ESXi 5, necesitas exportar los logs. Desde el vSphere Client, selecciona File > Export > Export System Logs.

Ten en cuenta el tamaño requerido para almacenar estos logs, sobre todo si cambias el nivel de lo que quieres que se logee en tu sistemas. Para ponértelo en contexto, los logs pueden llegar a crecer hasta 9GB en una instalación de 10 ESXi y aproximadamente 100 máquinas virtuales con respecto al nivel estándar de logeo. También, y si no tienes configurado un servidor de vCenter, puedes conectarte directamente a tu host ESXi y exportar los logs seleccionado la opción, File > Export.

Ayer aprendimos lo básico de la certificación oficial VMware y vimos los dos primeros capítulos. Hoy veremos los dos próximos capítulos, la red y el almacenamiento: Hasta mañana, Jose Maria Gonzalez CEO and Founder de www.jmgvirtualconsulting.com

Capítulo 3: Red en vSphere™ 5. La funcionalidad de red en una infraestructura virtual es de suma importancia. Permite que las máquinas virtuales en un servidor VMware vSphere™ ESXi 5 puedan comunicarse con otras máquinas físicas o máquinas virtuales en otros servidores VMware vSphere™, mediante la configuración de los virtual switches. También te permite comunicarte con el Management Network de los servidores VMware vSphere™ 5 para poder gestionarlos y con el VMkernel para poder configurar vMotion y cabinas de almacenamiento basadas en protocolos NFS o iSCSI.

En este capítulo te enseñaré a entender el propósito general de un virtual switch y undistributed virtual switch, cómo configurarlos y conectar uplink ports, así como a entender las diferentes configuraciones y políticas de seguridad que se pueden definir a nivel de virtual switch, port group o ambas. Diferentes tipos de port groups en vSphere™ ESXi 5

Un virtual switch estándar (VSS) tiene tres funciones principales: 1. Comunicar con máquinas virtuales dentro de un mismo servidor VMware ESXi o con otras máquinas físicas o máquinas virtuales en otro servidor VMware ESXi, para lo que utilizamos un Virtual Machine Port Group. 2. Comunicar con nuestro servidor ESXi via SSH (puerto 22) o vSphere Client, para lo que utilizamos un Management Network Port. 3. Comunicar con el VMkernel y puertos IP de tipo VMotion, NFS e iSCSI, para lo que utilizamos un VMkernel Port. A diferencia de los switches físicos, no es posible conectar dos virtual switch juntos mediante un ISL (InterSwitch Link Protocol), ni puedes mapear la misma tarjeta de red a más de un virtual switch a la vez. Recuerda que sí es posible configurar un virtual switch sin ninguna tarjeta de red, lo que es denominado como internal switch only. Cuando creas un NIC teaming (una o más tarjetas de red mapeadas a un virtual switch para incrementar el ancho de banda o dotar de alta disponibilidad a la capa de red), todas las tarjetas de red dentro del teaming pasan a ser activas por defecto. Para crear virtual switches puedes usar el vSphere Client o, desde la consola del servidor ESXi, puedes usar el comando: esxcfg-vswitch -a "nombre vswitch".

Si hay dos máquinas virtuales conectadas a dos virtual switches diferentes, el tráfico entre dichas máquinas fluirá a través de las tarjetas físicas mapeadas a los switches virtuales y entre servidores ESXi. Por el contrario, si varias máquinas virtuales están conectadas al mismo VSS del mismo servidor ESXi, los paquetes no salen por la red, sino que son transmitidos internamente en el servidor ESXi por el VMkernel. Para mejorar el rendimiento de red de las máquinas virtuales es posible mapear más de una tarjeta física (uplink) al VSS. Aviso: También es posible configurar switches distribuidos virtuales (Virtual Distributed Switch). La configuración de los switches distribuidos (VDS) es almacenada en el servidor vCenter a diferencia de los switches estándar, los cuales almacenan la configuración en los servidores ESXi. Un Virtual Distributed Switch no es más que un VSS que es compartido entre múltiples servidores VMware vSphere™ ESXi. Los VDS solo están incluidos en la versión Enterprise Plus. Port groups y el virtual switch estándar

En vSphere™ ESXi 5, el número máximo de puertos soportados para un VSS es de4088. A este vSwitch, puedes conectar ninguno, uno o más de un uplink. Recuerda que es posible cambiar el número de puertos en los VSS siempre que sea necesario. Sin embargo, dicho cambio requiere un “reboot” del servidor ESXi para que los cambios tengan efecto. Los port groups de tipo Management Network, Virtual Machine y VMkernel pueden todos ser configurados en un único VSS. Asimismo, sólo un VLAN ID puede ser especificado por port group pero múltiples port groups pueden especificar el mismo VLAN ID.

Es posible también garantizar un mínimo de servido o ancho de banda a todas y cada una de tus máquinas virtuales. Para ello, puedes usar una técnica de gestión de recursos llamada Traffic shapping, a nivel de port group, donde está incluida la máquina virtual para aliviar problemas de congestión de red o garantizar un ancho de banda determinado. Esta funcionalidad para los VSS te permite limitar el ancho de banda desde la máquina virtual hacia afuera (outbound) pero no desde fuera hacia la máquina virtual (inbound). Si precisas tener que limitar el ancho de banda desde fuera hacia dentro y desde dentro hacia afuera (outbound y inbound) tendrás que usar los switches distribuidos (VDS). Recuerda que este switch distribuido se crea en el vCenter Server, con lo que para usar VDS, aparte, debes de contar con una licencia de vCenter. Por defecto, y para los VSS, cuando creas un virtual switch por defecto es creado con 120 puertos. Sin embargo, si utilizas la línea de comando y ejecutas el comando“esxcfg-vswitch – l” verás que en realidad son 128 puertos. Estos ocho puertos son puertos extra que usa el VMkernel internamente y que no podemos usar desde la GUI. Estos ocho puertos extras solo pueden verse desde la línea de comando en ESXi 5:

Aviso: Es posible que tengas la necesidad de limitar el ancho de banda en los diferentes tipos de conexiones descritas anteriormente, y sobre todo, que tengas que aliviar problemas de cuellos de botella en la capa de red. En capítulos posteriores cubriremos algunas técnicas para aliviar cuellos de botella en los diferentes componentes de vSphere 5. Diferentes tipos de virtual switch en vSphere™ 5

Cada virtual switch, es una representación lógica vía software de un switch físico de capa dos. Los tres tipos de virtual switch que puedes crear en un servidor ESXi 5 son los siguientes: 1. Internal switch only. Este switch es usado únicamente para conectar, vía red, las máquinas virtuales instaladas en el mismo servidor VMware ESXi, las cuales no necesitan conexión con el mundo exterior. 2. Virtual switch con un adaptador de red. Este switch es usado para conectar, vía red, máquinas virtuales, Management Network (gestión) y puertos VMkernel con el mundo exterior, o dicho de otro modo, con otros servidores y máquinas virtuales de nuestro entorno virtual. 3. Virtual switch con más de un adaptador de red. Este switch es usado para conectar, vía red, máquinas virtuales, Management Network y puertos VMkernel con el mundo exterior con una funcionalidad adicional, como es el balanceo de carga y redundancia a fallos en los componentes de red. Las políticas de seguridad y de traffic shaping son configuradas a nivel de port groupy vSwitch. Una configuración incorrecta del traffic shaping afectaría no sólo al tráfico de las máquinas virtuales sino también al tráfico en general. En vSphere™ ESXi 5, una tarjeta mapeada a un switch virtual puede ser configurada para trasmitir y recibir tramas “Jumbo Frame”. El MTU (Maximum Transmision Unit) de un ”Jumbo Frame” es de 9000. VMware ESXi 5 también soporta “Jumbo Frames”, tanto en los VSS como en los VDS. Ahora, también es posible activar desde la GUI de los VSS el uso de los mismos. La configuración de Jumbo Frames es considerada una mejor práctica para las redes de tipo iSCSI, vMotion y Fault Tolerance.

Aviso: Los tres tipos de virtual switch pueden soportar hasta un total de 4088 puertos por switch virtual estándar. Para los tres tipos de virtual switch, no existen colisiones de red en el tráfico interno. Asimismo la dirección MAC de los adaptadores de red conectados a los virtual switchesno será usada en ningún momento de forma interna. Las políticas de balanceo de carga en un VSS en vSphere™ 5

En VMware vSphere™ 5, el adaptador NIC físico conectado al primer puerto deManagement Network es denominado vmk0. El primer puerto de gestión definido en nuestro servidor VMware ESXi 5 es denominado "Management Network". La configuración de las políticas de balanceo de carga en un NIC teaming y para un VSS son tres: 

Route based on the originating virtual port ID



Route based on source destination MAC hash



Y Route based on IP hash Sin embargo, las políticas de balanceo de carga para un NIC teaming en un VDS incluye otra política adicional llamada Route Based on physical NIC load como veremos más adelante.

Aviso: En una configuración de NIC teaming a nivel de VSS, es muy importante activar la opción Notify Switches. Cuando configuras una política de NIC teaming en un VSS y seleccionas la opción Notify Switches, el switch físico será alertado cuando la localización de una tarjeta virtual cambia de puerto. Esto ocurre, por ejemplo, cuando se hace una migración de una máquina virtual en caliente con vMotion. Propiedades de los adaptadores de red en VMware ESXi 5

Para ver las propiedades de tus tarjetas de red, selecciona el servidor ESXi en el panel inventario, luego en la pestaña Configuration, selecciona el enlace Networking en la parte Hardware y luego Properties en el switch virtual que tiene conectado el adaptador de red que quieres modificar. Existe nueva tecnología en vSphere™ ESXi 5 que puedes usar para incrementar el throughput de tus máquinas virtuales es el Split RX como veremos más adelante. Si estas usando adaptadores de red Gigabit Ethernet, es considerada una mejor práctica dejar la velocidad y la configuración de dúplex en auto negotiate ya que el auto negotiate es parte del estándar en redes Gigabit Ethernet.

Aviso: Para configurar NetQueue, y mejorar así el rendimiento de red de las máquinas virtuales en un servidor ESXi, es necesario habilitarlo en el driver de la tarjeta física y en las opciones avanzadas del VMkernel. Si el rendimiento de la consola remota para una máquina virtual es lento, verifica la configuración (speed, duplex) de la tarjeta física asignada al port group del switch virtual. Los diferentes tipos de políticas de seguridad en vSphere

En los VSS, hay tres tipos diferentes de políticas de seguridad: Traffic shaping Policy, NIC Teaming Policy y Security Policy. En un Virtual Distributed Switch, aparte de estas tres políticas de seguridad, existe otra nueva, Port Blocking Policy. Las políticas pueden ser definidas a nivel de virtual switch, las cuales se convertirían también en las políticas por defecto para todos los port groups creados en dicho virtual switch, o a nivel de port group. Las políticas definidas a nivel de port group, siempre sobrescriben las políticas definidas a nivel de virtual switch. Un vSwitch o vSwitch port group en "Promiscuous Mode" permitirá que una máquina virtual pueda "escuchar" todo el tráfico contenido en ese VSS y no solo el tráfico destinado para esta máquina virtual en concreto. Una mejor practica en la capa de red con vSphere™ 5 es que antes de crear los diferentes tipos de switches virtuales, protocolos de balanceo de carga, VLANs, port groups y NIC teaming, hables con el administrador de tu red física sobre lo que necesitas a nivel de red virtual. Es muy corriente implementar IP hash a nivel de red virtual en entonos de producción relativamente importantes para luego darse cuenta que no está funcionando correctamente porque no se ha activado en el switch físico. La configuración predeterminada en vSphere™ 5, dentro de la política de seguridad Security

La configuración predeterminada para la política de seguridad Security y para todos los VSS es la siguiente: Promiscuous Mode: Reject - Significa que el virtual switch no redireccionará ninguna trama a otros puertos del switch (modo switch). Si Promiscuous Mode es cambiado aAccept, el switch se comportaría como un HUB y redireccionará todas las tramas entrantes y salientes a todos los puertos del virtual switch. Esta configuración suele ser útil cuando "pinchamos" un sistema IDS (Intrusion Detection System) o sniffer en un virtual switch para analizar todas las tramas de dicho switch. MAC Address Changes: Accept - Significa que el virtual switch no haría un drop de la trama entrante si la dirección MAC de ésta no coincide con la dirección MAC de la máquina virtual conectada en ese port group. Por defecto, esta opción se suele cambiar a Reject para evitar ataques tipo MAC spoofing. Forged Transmit: Accept - Significa que el virtual switch no haría un drop de la tramasaliente si la dirección MAC de ésta no coincide con la dirección MAC de la máquina virtual guardada en el fichero de configuración (.vmx) de dicha máquina virtual. Por defecto, esta opción se suele cambiar a Reject para evitar ataques tipo MAC flooding y MAC spoofing. En resumen, Forged Transmit permite a una máquina virtual transmitir paquetes (outbound) que contienen una dirección MAC diferente a la que se ha definido en esa máquina virtual. Recuerda que las políticas de seguridad de red a nivel de VSS y port group sonReject (Promiscuous Mode), Accept (MAC address Changes) y Accept (Forget Transmit).

Aviso: No cambies la configuración por defecto de MAC Address Changes ni Forged Transmits si tienes configurado en el virtual switch un clúster Microsoft NLB (Network Load Balancing) en modo unicast. Para ver más información sobre la configuración determinada con Microsoft NLB, ver elKB número 1556 en la página de VMware: http://kb.vmware.com Asimismo, cuando tengas que hacer una conversión P2V - de las siglas en inglés Physical to Virtual - con el software de conversiones de VMware llamado vConverter, asegúrate de configurar Allow Mac Adress Changes en Accept, si el servidor físico que estas intentando convertir tiene software instalado que fue licenciado usando la dirección MAC de su tarjeta física. La configuración predeterminada, dentro de la política de seguridad de Traffic Shaping

Esta política de seguridad de traffic shaping, para el vswitch y port group, está desactivada por defecto. Con la opción network traffic shaping puedes limitar eloutbound peak bandwidth y el outbound average bandwidth. Esta política de traffic shaping solo se aplica a las conexiones de dentro hacia fuera (outbound), es decir, desde dentro del virtual switch hacia fuera del virtual switch. No es posible definir una política de traffic shaping desde fuera del virtual switch hacia dentro (inbound) en un VSS. Una primera alternativa para limitar el tráfico de tipo inbound es la de usar algún sistema externo de balanceo de carga o activar la opción de rate-limiting en tu router físico.

La segunda alternativa la encontramos en los VDS. En los Virtual Distributed Switches es posible definir el Traffic Shaping en ambas direcciones (Ingress - inbound y Egress outbound).

En vSphere™ 5 hay dos formas de migrar una máquina virtual desde un vSwitch estándar a un Virtual Distributed Switch. La primera opción es seleccionando un dvPort group desde las propiedades de la configuración de red de la máquina virtual, y la segunda, seleccionando la máquina virtual desde la lista de máquinas virtuales cuando usas la opción "Migrate Virtual Machine Networking".

Una nueva funcionalidad en los VDS de la versión ESXi 5 es la de habilitar la opción deNetFlow. Esta opción te permitirá mandar tráfico de red desde un VDS a una máquina virtual, la cual si tiene un software de análisis de red podrás hacer un estudio muy exhaustivo de tu red de datos y del tipo de tráfico enviado por tu red.

Para terminar con las diferencias entre un VSS y un VDS, estas son las tres funcionalidades más importantes que están disponibles en los VDS y no en VSS: 

NetFlow Monitoring



Network I/O Control



Egress Traffic Shapping Cuando creas un dvPort group, el port binding dinámico (Dynamic Binding) se asegura de asignar un puerto a la máquina virtual la primera vez que es encendida.

Recuerda que si usas un uplink que ya está previamente en uso en un VSS para crear un VDS, las máquinas virtuales que estuvieran usando ese uplink perderán la conectividad. Aviso: Ten en cuenta que el Average Bandwidth y Peak Bandwidth son medidos enKbps, mientras que el Burst Size es medido en KB. De la misma manera se mide en los Virtual Distributed Switch. Asimismo, recuerda que el máximo número de VDS por servidor de vCenter es de 32. Arquitectura de un Virtual Distributed Switch

Como he mencionado anteriormente, el VDS se crea en el servidor de vCenter y se gestiona desde ese mismo servidor de vCenter. Existen tres métodos a la hora de crear un port groups en un Virtual Distributed Switch: 1. El adaptador de red con la configuración del port group puede ser asociado con unport group existente en un Virtual Distributed Switch. 2. El port group también puede ser migrado desde un virtual switch estándar a un VDS y viceversa. 3. Un adaptador de red con la configuración de un port group puede ser creado durante la instalación de un Virtual Distributed Switch. Una mejor practica de VMware es la de usar VDS en lugar de VSS ya que los swithes distribuidos ofrecen algunas funcionalidades Enterprise que no están incluidas en los VSS. Naturalmente tendrás que evaluar el coste adicional asociado al uso de los VDS ya que solo es posible configurar VDS si tienes la licencia Enterprise plus. La configuración predeterminada en vSphere™ 5, dentro de la política de seguridad de NIC Teaming.

Para la política de seguridad de NIC Teaming, existen cuatro opciones en el algoritmo de load balancing a seleccionar: route based on the originating virtual port ID (por defecto), route based on ip hash (es necesario etherchannel), route based on sourceMAC hash y explicit failover order. Recuerda que las políticas de load balancingpara el Virtual Distributed Switch son las mismas, más una extra adicional. Para habilitar el NIC teaming es necesario conectar más de una tarjeta de red física a un único virtual switch o virtual distributed switch. Si la opción "explicit failover order" no es elegida como algoritmo de balanceo de carga en un virtual switch con múltiples uplinks (NIC teaming) y una de las tarjetas físicas del teaming “se cae", el VMkernel verifica el contador "reported uptime" de las otras NICs para asignar una NIC del teaming y proceder al failover. Beacon Probing se usa en vSphere™ para detectar e identificar fallos en el enlaceupstream. Es muy útil en entornos Blade y en donde tenemos Spaning Three Protocol activado en nuestra red física. De esta forma podremos detectar fallos de red en los caminos alternativos. En un VSS con un port group de tipo Management Netowrk y un port group tipoVMkernel, y mapeas dos uplinks al VSS, es posible separar el tráfico de gestión y del trafico VMkernel seleccionando la política de balanceo "Explict Failover order". Asimismo, es posible ver más información sobre la configuración actual de los VSS con el siguiente comando desde la consola de servidor ESXi:

Algunos máximos y mínimos importantes de red en VMware vSphere™ ESXi 5

Éstos son algunos de los máximos y mínimos en la capa de red para VMware vSphere™ ESXi 5: 

256 es el número máximo de port groups ephemeral por vCenter.



256 es el número máximo de port groups por switch virtual estándar (VSS de las siglas en ingles virtual switch standard).



5.000 es el número máximo de port groups estáticos por instancia de vCenter.



5.000 es el número máximo de puertos virtuales en switches distribuidos por vCenter.



4.088 es el número máximo de puertos de red en los VSS.



350 es el número máximo de servidores ESXi 5 que puedes conectar por VDS.



32 es el número máximo de VDS por instancia de vCenter.



4096 es el número máximo de puertos virtuales de red por host (VSS y VDS).



1.016 es el número máximo de puertos activos por host (VSS y VDS).



24 es el número máximo de tarjetas de 1GB Ethernet (e1000e Intel PCI-e) por host.



32 es el número máximo de tarjetas de 1GB Ethernet (e1000e Intel PCI-x) por host.



24 es el número máximo de tarjetas de 10GB Ethernet (NetXen) por host.



8 es el número máximo de tarjetas de 10GB (ixgbe) por host.



4 es el número máximo de iniciadores de hardware iSCSI Broadcom de 10Gb por host.



512 es el número máximo de máquinas virtuales por host. Aviso: En cuanto a las diferentes tarjeterías de red y sus combinaciones, VMware vSphere™ ESXi 5 soporta un máximo de seis tarjetas de 10GB y cuatro de 1GB en un mismo host. La importancia de VLANs en vSphere 5

La configuración de VLANs en un entorno virtual con vSphere mejora la seguridad de nuestra solución de virtualización. Para la implementación de VLANs, los servidores VMware ESXi usan una metodología llamada port group policies. Para conectar una máquina virtual en un virtual switchcon una VLAN, debes usar el vSphere Client. Como vemos en la imagen de arriba, la red VM Network es la que ha sido configurada con un VLAN ID. Si no configuras VLANs, las máquinas virtuales que estén mapeadas en cualquier port group del virtual switch podrán ver todo el tráfico.

Capítulo 4: Almacenamiento en vSphere™ 5. El almacenamiento es, sin duda, uno de los pilares más importantes de una solución de virtualización. Es un componente crítico para poder dotar a nuestro entorno de un plan de contingencia a fallos, alta disponibilidad y migración de máquinas virtuales entre servidores VMware vSphere™ESXi. Zoning, LUN Masking y el uso de VAAI en vSphere™ 5

La configuración de la zona a nivel del fabric de fibra es un mecanismo muy usando tanto para entornos físicos de SAN FC como para entornos virtualizados con una red de SAN FC. El Zoning se hace a nivel de switch de fibra para restringir las conexiones de los servidores ESXi o servidores físicos a la cabina de datos y prevenir que otros servidores destruyan los datos en los volúmenes. LUN Masking se puede hacer en dos niveles: a nivel de procesadores de datos (en Ingles SP - Storage Processors) y a nivel de servidor ESXi. Aunque, en la actualidad elLUN Masking se suele hacer más a nivel de SP, también es posible hacerlo a nivel de servidor ESXi sobre todo cuando usamos Boot From SAN(BFS). Asimismo en los switches de FC de nueva generación también es posible hacer LUN Masking. BFS puede llegar a ser útil para configuraciones diskless en servidores tipo Blade. Cuando estás haciendo BFS, la LUN FC desde donde arranque el servidor ESXi, deberá ser solo visible para ese servidor. Los otros DataStores VMFS, deberían ser visibles a todos los servidores ESXi. Asegúrate siempre de que cambies tu configuración de la zona del fabric de FC o las propiedades de las LUNs, hacer un rescan de tu fabric a nivel de centro de datos. De esta forma te aseguras que todos los servidores tienen la última configuración de tu SAN.

Desde VMware vSphere™ 4, aparecieron APIs por doquier, lo cual ha permitido evolucionar el producto a nivel de almacenamiento con características muy innovadoras. Una de las APIs más importantes, y que ya apareció en la versión 4.1, es la vSphere APIs for Array Integration, también conocida por el acrónimo VAAI. En consecuencia, una cabina con soporte VAAI para la nueva versión de VMware vSphere™ ESXi tendrá un mayor rendimiento en las siguientes operaciones: Write Same/Zero nos ayuda a eliminar I/O en tareas repetitivas y disminuir el consumo de CPU, por ejemplo, la clonación masiva o el aprovisionamiento de máquinas virtuales. Fast/Full Copy nos permite realizar Storage vMotion sin tráfico en la red o las HBAs, ya que lo realiza la cabina SAN. La duración de la migración disminuye en un 25%, según datos proporcionados por EMC. Hardware Offloaded Locking es una gran funcionalidad. Hasta ahora las reservas SCSI que se realizan sobre un datastore VMFS se realizan a nivel de LUN, por tanto, en un momento dado, solo una máquina virtual puede acceder a la LUN en algunas tareas, con Hardware Offloaded Locking el bloqueo se realiza a nivel de bloque no de LUN. Esto nos permitirá aumentar el número de máquinas virtuales por datastore en nuestros diseños y disminuirá el tiempo de creación de datastores VMFS y NFS. Thin Provisioning Stun evita que nos quedemos sin espacio en disco poniendo la máquina virtual en pausa hasta que consigamos disco. Esta situación, puede llegar a ocurrir si aprovisionamos en modo Thin y necesitamos más disco del que tenemos. VAAI está activado por defecto en vSphere™ ESXi 5 a partir de la licencia Enterprise. Por supuesto, ni que decir tiene, la cabina de datos también tiene que soportar VAAI.

Para terminar con VAAI, una cabina con soporte VAAI y con el uso de thin provisioning ofrece la posibilidad de “reclamar” espacio cuando una máquina virtual es migrada a un datastore diferente con Storage vMotion o cuando el disco virtual es borrado.

Con el vSphere Client y desde la pestaña Storage Views podrás ver información muy interesante relativa a tus datastores VMFS, como por ejemplo: 

El estado del algoritmo de multipathing para tus datastores



El espacio usado en tus datastores



Y un montón de otras cosas interesantes relativas a la configuración de tu datastore ¿Cómo mostrar más información de los volúmenes o datastores en vSphere™ 5?

Para obtener más información sobre los DataStores VMFS, como, por ejemplo, el estado del Multipathing actual y el espacio usado, selecciona la pestaña Storage Views. El Runtime Name, para un dispositivo de almacenamiento en FC, equivale al nombre de la ruta del dispositivo en formato vmhba:C:T:L, donde C es Controler, T es Target y L es LUN.

El seudo name vmhba32 es el nombre que el VMkernel utiliza para los iniciadores software iSCSI. Recuerda que tanto el adaptador de software iSCSI como el adaptador dependent hardware iSCSI necesitan un port group tipo VMkernel para ser configurados del todo. Si usas una adaptador de tipo dependent hardware iSCSI para tu conexión iSCSI, es posible que el rendimiento de las tarjetas de red asociadas con este adaptador muestren muy poca actividad, incluso cuando el trafico via iSCSI es muy alto. Esto es consecuencia directa de que el trafico iSCSI hace un bypass del trafico normal de red y no se verá reportado por las herramientas internas de monitorización de red del servidor ESXi (esxtop). Asimismo, para obtener un mejor rendimiento iSCSI con adaptadores de tipodependent hardware iSCSI es una mejor práctica habilitar la opción de flow control. Flow control está habilitado por defecto en todas las tarjetas de red en los servidores ESXi 5. Es posible deshabilitar flow control. Puedes ver el KB 1013413 en el siguiente enlace para deshabilitarlo: http://kb.vmware.com/kb/1013413 Presentando LUNs FC a los servidores vSphere 5™

La buena noticia es que el módulo para el adaptador de fibra es reconocido por elVMkernel durante la secuencia de arranque, con lo que si el Zoning está bien configurado, no deberías de tener mayor problema en ver tus LUNs de FC. Para acceder a las nuevas LUNs, no es necesario hacer un reboot del servidor ESXi. Las nuevas LUNs serán descubiertas por los servidores ESXi siempre que se realice un Rescan en cada servidor vSphere ESXi o desde el objeto de inventario DataCenter. Adicionalmente, cuando elimines un DataStore de un servidor ESXi, realiza un Rescanen todos los servidores ESXi para actualizar los cambios. Desde la versión vSphere™ 4.x, se incluye una opción de Rescan centralizado para buscar cambios en la granja de SAN de todos los servidores ESXi incluidos en el mismo objeto de inventario de tipo DataCenter. QLA es el nombre corto del módulo del driver Linux para una HBA del proveedorQlogic. LPFC es el nombre corto del módulo del driver Linux para una HBA del proveedorEmulex. Recuerda que las HBAs tiene un número identificativo único y global llamado World Wide Nane, también conocido con el acrónimo WWN.

Como en la parte de configuración de red, es una mejor práctica que antes de configurar la parte de SAN en tu entorno virtual, hables con tu administrador de SAN sobre tus necesidades en cuanto a la capa de almacenamiento se refiere. Algunos de los temas que deberías de tener claro y preguntar a tu administrador de SAN antes de implementar el almacenamiento en tu entorno virtual incluyen lo siguiente: El tamaño necesario de tus LUNs I/O bandwidth que requieren tus aplicaciones virtualizadas El tamaño de la cache, zoning y LUN masking de tu fabric de SAN La configuración del multipathing en ESXi, es decir, si es una cabina activa/activa, activa/pasiva o activa/activa con soporte ALUA. Aviso: El número máximo de HBAs soportadas en vSphere™ ESXi 5 ha aumentado de 8 tarjetas HBAs por host ESXi 5 a 16. Asimismo, el número máximo de targets por HBA de FC es de 256. ¿Cómo se configura el iniciador software iSCSI en vSphere™ 5?

Una SAN de tipo iSCSI consiste de una cabina de datos con conexiones tipo iSCSI (red de 1Gb o 10Gb Ethernet) la cual contiene una o más LUNs así como SPs. La comunicación entre el host ESXi y la cabina iSCSI se establece a través de una red Ethernet de datos. iSCSI usa el IQN (iSCSI Qualify Name), donde el primer número representa el año, mes y la organización que registró el dominio: iqn.2006-01.com.openfiler:volume.vmware. Este nombre IQN no puede superar los 255 caracteres.

Los servidores ESXi vienen configurados, por defecto, con un iniciador de software iSCSI. Este iniciador iSCSI transmite comandos SCSI por una red de datos. El target, es decir, la cabina de datos iSCSI, recibe estos comandos SCSI y el SP los procesa. Es posible tener múltiples iniciadores y targets en nuestra red iSCSI. Y a diferencia en las versiones anteriores, en vSphere™ 5, el iniciador de software no viene instalado por defecto. Puedes ver el video tutorial de la instalación del iniciador de software iSCSI en vSphere™ ESXi en un video tutorial de nuestro canal de YouTube llamado:VMware vSphere 5.0 en entornos SAN iSCSI VMware vSphere™ 5 utiliza CHAP (Challenge Handshake Authentication Protocol) para ofrecer lo que se denomina Initiator authentication. Es una buena práctica aislar la red de gestión, de la red iSCSI y de la red donde están conectadas todas las máquinas virtuales. Debido al hecho de que las redes IPs que usan la tecnología iSCSI no encriptan los datos trasmitidos, es aconsejable para configuraciones iSCSI, activar la funcionalidad de CHAP que se incluye tanto en la cabina (target) como en el iniciador de software iSCSI en el servidor ESXi. Si configuras el servidor ESXi con la opción de CHAP para acceder a una LUN iSCSI y después deshabilitas CHAP en el servidor, el acceso a las LUNs iSCSI no se verá afectado hasta que no se reinicie el servidor ESX/ESXi o la cabina iSCSI. Puedes activar el CHAP en la pestaña General después de seleccionar las propiedades del iniciador de software iSCSI.

Aviso: No olvides abrir el puerto 3260 en el firewall del servidor ESXi. El protocolo iSCSI utiliza este puerto para la comunicación entre la cabina iSCSI (Target) y el servidor ESX (iSCSI initiator). Descubriendo recursos NFS en servidores vSphere™ 5

Aparte de la conectividad de FC e iSCSI, es posible dotar de almacenamiento NAS, via NFS, a tus servidores ESXi. Estos servidores ESXi acceden al servidor NFS mediante un port group de tipo VMkernel el cual se define a nivel de switch virtual. Para crear un DataStore NFS en un servidor ESXi necesitas saber el nombre o IP del servidor NFS, el nombre de la carpeta compartida en el servidor NFS y el nombre del DataStore que quieres darle. ESXi solo soporta la versión 3 de NFS sobre el protocolo TCP. Los servidores ESXi ganan acceso exclusivo a las máquinas virtuales creadas sobre un DataStore NFS usando un fichero especial de bloqueo llamado .lck-xxx. También, es posible activar la opción CHAP para conexiones de tipo NFS. El protocoloCHAP bidireccional solo está soportado para los iniciadores software iSCSI. Con el CHAP bidireccional el target verifica el iniciador software y el servidor verifica el target. El iniciador hardware iSCSI solo soporta CHAP unidireccional, es decir, el target verifica al servidor host. Aviso: El uso de la funcionalidad de usuario delegado que permite acceso a un DataStore NFS no está soportado en ESX/ESXi 4.x. Las máquinas virtuales creadas sobre DataStores NFS tienen formato thin, a diferencia de las máquinas virtuales creadas sobre DataStores VMFS en FC, las cuales tienen un formato thick. Configurando multipathing con iniciadores software iSCSI en vSphere™ 5

En vSphere™ 5 es posible configurar el algoritmo de multipathing que viene embebido en el VMkernel del ESXi. La idea general de este algoritmo de multipathing es ofrecer a tus servidores ESXi caminos alternativos en caso de caída de un switch físico, una tarjeta de red o incluso un SP de tu cabina. Asimismo, es posible usar las opciones de multipathing para poder dotar de un mecanismo de balanceo de carga a nuestras LUNs de datos. Es posible cambiar el Multipathing Pluging (MPP) para uno o más datastores aunque es siempre una mejor práctica asegúrate que tipo de MPP soporta tu cabina confirmándolo primero en el HCL – de las siglas en ingles Hardware Compatibiliy List - de VMware. Puedes ver el HCL de todas las capas en una solución de virtualización en el siguiente enlace: http://www.vmware.com/go/HCL Cuando se usa el Multipathing Plugings (MPPs) en vSphere™ 5, el Pluggable Storage Architecture (PSA) ejecuta las siguientes tareas: 1.

Gestiona las colas de E/S de disco de la HBA (Host Bus Adapter).

2.

Descubre y elimina rutas físicas.

3.

Gestiona las colas de E/S de disco en el dispositivo lógico.

Cuando configuras multipathing con iniciadores software iSCSI, debes configurar dosport groups tipo VMkernel. Después, mapea cada port group a un uplink diferente sobre el mismo virtual switch y selecciona el algoritmo de multipathing Round Robin. La idea general es, después de seguir todos los pasos siguientes, tener al menos dos caminos por LUN activos para que de esta manera podamos aumentar, no solo

la disponibilidad con VMware multipathing sino también, el ancho de banda de E/S de nuestros datastores en vSphere™ ESXi 5. A continuación, te resumo los pasos a seguir para crear una configuración multipathing tanto para iSCSI como para conexiones NFS en tus servidores ESXi: Paso 1: Configura un vSwitch y habilita el Jumbo Frames Este paso (Jumbo Frames) tienes que hacerlo desde línea comando para la versión ESX/ESXi 4.x pues en los vswitch estándares de esta versión no tienes la opción de hacerlo desde la GUI (si está disponible en los vswitch distribuidos). Para la nueva versión de vSphere™ ESXi 5 ya es posible activar el Jumbo Frames también desde la GUI para los VSS. esxcfg-vswitch –a vSwitch1 (crea un vSwitch llamado vSwitch1) esxcfg-vswitch –m 9000 vSwitch2 (activa jumbo frame en el vSwitch1) Paso 2: Añade los VMkernel Ports iSCSI Aquí, dependerá de las tarjetas de red que tengas cableadas y de las controladoras de disco que tengas en tu cabina. Al menos, deberías de configurar dos VMkernel Ports con dos tarjetas de red para tener, tanto balanceo de carga con RR ( de las siglas en inglés Round Robin) como mecanismo de balanceo de carga. esxcfg-vswitch –A iSCSI1 vSwitch1 ( crea un VMkernel port llamado iSCSI1 ) esxcfg-vmknic –a –i 10.10.1.1 –n 255.255.255.0 –m 9000 iSCSI1 (asigna una ip, subnet mask y jumbo frames al VMkernel port iSCSI1) esxcfg-vswitch –A iSCSI2 vSwitch1 ( crea un VMkernel port llamado iSCSI2 ) esxcfg-vmknic –a –i 10.10.2.1 –n 255.255.255.0 –m 9000 iSCSI2 (asigna una ip, subnet mask y jumbo frames al VMkernel port iSCSI2) Paso 3: Asigna las tarjetas de red físicas al vSwitch1 Primero, asegúrate que tienes al menos dos tarjetas de red físicas sin asignar a otro vswitch. Lo puedes ver con este comando esxcfg-nics –l.

esxcfg-vswitch –L vmnic3 vSwitch1 (Conecta la tarjeta vmnic3 al vSwitch1) esxcfg-vswitch –L vmnic4 vSwitch1 (Conecta la tarjeta vmnic4 al vSwitch1) Aquí viene lo bueno. Por defecto, cuando creas un team en un vswitch las dos tarjetas en el team se convierten por defecto en activa/activa. Para que el multipathing ESXi funcione con el iniciador de software iSCSI debes cambiar las propiedades del multipathing. Lo explicaré en el siguiente paso. Paso 4: Asocia los VMkernel Ports a las tarjetas de red físicas Antes de seguir con este paso, teclea el siguiente comando: esxcfg-vswitch –l Deberías de ver algo así en tu vSwitch1: Switch Name Num Ports Used Ports Configured Ports MTU Uplinks vSwitch1 64 7 64 9000 vmnic3,vmnic4 PortGroup Name VLAN ID Used Ports Uplinks iSCSI2 0 1 vmnic3,vmnic4 iSCSI1 0 1 vmnic3,vmnic4 Aquí, puedes ver que las dos tarjetas están asociadas en los dos VMkernel Ports. Esto es lo que tienes que cambiar con el siguiente comando. esxcfg-vswitch –p iSCSI1 –N vmnic3 vSwitch1 (borra el vmnic3 del VMkernel port iSCSI1) esxcfg-vswitch –p iSCSI2 –N vmnic4 vSwitch1 (borra el vmnic2 del VMkernel port iSCSI2) Para verificar que has tecleado bien los comandos anteriores, vuelve a teclear este comando para ver la salida: esxcfg-vswitch –l Deberías de ver algo así: Switch Name Num Ports Used Ports Configured Ports MTU Uplinks vSwitch1 64 7 64 9000 vmnic4,vmnic3 PortGroup Name VLAN ID Used Ports Uplinks iSCSI2 0 1 vmnic4 iSCSI1 0 1 vmnic3

Paso 5: Habilita el iniciador de software iSCSI Con el comando esxcfg-swiscsi –e habilitas el iniciador de software iSCSI. Paso 6: Muy importante: Crear el Binding de los VMkernel Ports con el iniciador de software iSCSI Primero, confirma el seudo-name de tu iniciador de software iSCSI. Lo puedes ver con este comando. esxcfg-scsidevs –a Deberías de ver algo así: vmhba0 mptsas link-n/a sas.5001ec90e0ba7c00 (1:0.0) LSI Logic / Symbios Logic LSI1068E vmhba1 ata_piix link-n/a ide.vmhba1 (0:31.1) Intel Corporation 631xESB/632xESB IDE Controller vmhba32 ata_piix link-n/a ide.vmhba32(0:31.1) Intel Corporation 631xESB/632xESB IDE Controller vmhba33 iscsi_vmk link-n/a iscsi.vmhba33() Software iSCSI En mi caso como ves, el seudo-name de mi iniciador software iSCSI es vmhba33 Segundo, determina el nombre exacto de los VMkernel ports de tus iniciadores iSCSI. Lo puedes ver con este comando: esxcfg-vmknic –l Interface Port Group/DVPort IP Family IP Address Netmask Broadcast MAC Address MTU TSO MSS Enabled Type vmk3 iSCSI1 IPv4 10.10.1.1 255.255.255.0 10.10.5.255 00:50:56:7b:d8:21 9000 65535 true STATIC vmk4 iSCSI2 IPv4 10.10.2.1 255.255.255.0 10.10.5.255 00:50:56:7e:ae:81 9000 65535 true En mi caso, como ves en la salida anterior, es el vmk3 y el vmk4. Una vez que conozcas cuál es el nombre del iniciador de software iSCSI (vmhba32) y de los VMkernel ports (vmk3 y vmk4), ya puedes hacer el binding con el siguiente comando:

esxcli swiscsi nic add –n vmk3 –d vmhba33 (crea el binding para el vmk3 VMkernel port con el iniciador de software iSCSI vmhba33) esxcli swiscsi nic add –n vmk4 –d vmhba33 (crea el binding para el vmk4 VMkernel port con el iniciador de software iSCSI vmhba33) Para verificar que se han creado bien los binding con los VMkernel ports y el iniciador de software iSCSI, teclea el siguiente comando: esxcli swiscsi nic list –d vmhba33 Deberías de ver que los dos VMkernel ports están incluidos en el iniciador de software iSCSI. Paso 7: Conecta la cabina iSCSI a tu entorno vSphere™ ESXi 5 

Entra en la sección Configuration -> Storage Adapters.



Haz click en iSCSI Software Adapter and selecciona Properties.



Haz clic en la pestaña Dynamic Discovery.



Clic Add. En la sección iSCSI Server box, asegúrate de poner la IP del grupo o el IP de tu cabina iSCSI y selecciona Ok. Recibirás un mensaje que te pide hacer un Rescan de todas las HBAs. Dile que estás de acuerdo y en unos minutos deberías de ver tus LUNs si estas han sido configuradas correctamente en tu cabina y los servidores VMware vSphere™ 5ESXi tienen acceso a las LUNs. Aviso: Ahora para la versión vSphere™ ESXi 5 es posible hacer el mecanismo de port binding desde la GUI. Entendiendo el sistema de archivos VMFS en vSphere™ 5

vSphere™ 5 utiliza un sistema de archivos propietario de VMware llamado VMFS - de las siglas en ingles Virtual Machine File System- como sistema de archivos, el cual está optimizado para ejecutar múltiples máquinas virtuales como una carga de trabajo única (workload). Este sistema de archivos soporta journaling, está optimizado para albergar máquinas virtuales y soporta funciones de clustering a nivel de sistema de archivos. vSphere™ 5 ofrece asignación dinámica del almacenamiento mediante la funcionalidad vStorage Thin Provisioning. VMware soporta Thin Provisioning a nivel de sistema de archivos en VMFS pero, además, tu cabina de datos debe soportar Thin Provisioning. Se pueden acceder a los volúmenes VMFS a través del nombre del volumen, por el nombre del DataStore o la dirección física: vmhba0:0:1:1. Todas las particiones VMFS y NFS son montadas bajo el directorio /vmfs/volumes en tus servidores VMware vSphere™ ESXi. EL número máximo de extenders (número de LUNs que podemos unir como si de una sola LUN se tratara) para un DataStore VMFS es de 32. Por lo tanto, el tamaño máximo de un volumen VMFS es de 64TB menos 16K (metadata). Los volúmenes VMFS que pueden ser "desmontados" con el comando umount son los DataStores VMFS montados y todos los volúmenes NFS. Cuando se elimina un DataStore VMFS desde un servidor vSphere™ ESXi, este es eliminado en todos los servidores vSphere™ ESXi que tuvieran conectividad con el DataStore. Por eso es conveniente, siempre que se cambia o reconfigura el acceso a los discos, hacer un scan del fabric de fibra. Aviso: Las LUNs (FC e iSCSI) pueden ser formateadas en VMFS-3 con diferentes tamaños en el block size: 1MB - 256GB, 2MB - 512GB, 4MB - 1024GB y 8MB - 2048GB. Por tanto, si formateas un volumen VMFS con un block size de 4MB, el disco virtual no podrá superar el

tamaño de 1TB (menos 512Bytes). A continuación, te muestro la tabla de los block size y el tamaño de los ficheros en VMFS-3:

Nuevo iniciador FCoE en vSphere 5 Ahora, en la nueva versión de vSphere™ 5, es posible instalar un nuevo iniciador de software FCoE. En el año 2007, Intel anunció el proyecto Open FCoE, con el objetivo de dar soporte de FCoE sobre adaptadores Ethernet de 10Gb en el kernel de Linux, sin necesidad de tener que usar tarjetas específicas de FC como ocurre con las tarjetas CNAs - de las siglas en ingles Converged Network adapters -. Actualmente, esta iniciativa ha conseguido el respaldo de Microsoft, Red Hat, SuSe y ahora de VMware, además de estar soportada en los conmutadores Brocade y Cisco, así como en los sistemas de almacenamiento de EMC y NetApp. Open FCoE está soportado en vSphere™ 5 y solo hay que activarlo como si fuera un iniciador iSCSI, o sea activamos el “software FCoE Adapter” en la configuración de los Storage Adapters del host ESXi nos aparecerá un dispositivo vmhba (virtual) que encapsulará el tráfico FC en un puerto VMkernel, sin la necesidad de tener que comprar una tarjeta CNA. Con Open FCoE podremos, en un futuro, utilizar cualquier adaptador que soporte Open FCoE. Por ahora la lista está limitada a adaptadores Intel X520. Si esta iniciativa avanza y llega a consolidarse, tendremos más opciones a la hora de escoger tarjetas con soporte FCoE. Como siempre, si la tecnología FCoE se estandariza veremos también unos precios mucho más competitivos que los precios de hoy en día.

Entendiendo los diferentes algoritmos de failover en vSphere™ ESXi 5

Como he mencionado anteriormente, Multipathing es el proceso por el que el kernel de VMware ESXi permite el acceso continuo a una LUN en la SAN cuando se produce un fallo en algún componente hardware: SP, switch de fibra, HBA o un cable de fibra. Es lo que denominamos failover. En la actualidad, VMware ESXi 5 soporta failover a nivel de HBA, switch de fibra, cable o incluso a nivel de procesador de datos de la cabina. Existen en la actualidad tres algoritmos de failover en vSphere™ ESXi: MRU (Most Recently Used), Fixed (prefered path) y RR (Round Robin), siendo este último más bien un algoritmo de balanceo de carga que de failover. El algoritmo MRU, es seleccionado por defecto por vSphere™ para las cabinas de almacenamiento Activa/Pasiva mientras que Fixed es seleccionado para las cabinas de tipo Activa/Activa. La diferencia elemental de una cabina activa/activa versus una cabina activa/pasiva es que en las primeras los dos procesadores de datos pueden ejecutar un I/O de disco en la misma LUN.

Sin embargo, para las cabinas de tipo activa/pasiva solo un procesador de datos puede hacer un I/O de disco. Esto no significa que en esta configuración haya un procesador de datos en modo standby sin hacer ningún I/O de disco. Todo lo contrario, lo que para una LUN un SP puede estar configurado como pasivo, para otra LUN este mismo SP puede estar configurado como activo, con lo que los dos SP están procesando I/Os pero no a la misma LUN. Esto cambia con el uso de ALUA, que no es más que el proceso de convertir una cabina activa/pasiva en “activa/activa” mediante la activación, y valga la redundancia, de la interface de interconexión interna entre los dos SPs. Aviso: Para incrementar el rendimiento de una máquina virtual, es posible cambiar la política de multipathing de Fixed a Round Robin para cabinas de tipo activa/activa.. Hola, Ayer vimos la parte de red y de almacenamiento. Hoy vermos el servidor de vCenter y las máquinas virtuales Hasta mañana y espero que sigas disfrutando de este curso gratuito de VMware vSphere en cinco días! Jose Maria Gonzalez CEO y Fundador de www.jmgvirtualconsulting.com P.S. Si te gustaría aprender mucho mas sobre vmware en mucho menos tiempo, ahora tienes acceso a nuestro curso online VMware vSphere 5.5 Avanzado a un precio reducido!

Capítulo 5: VMware vCenter Server 5 https://www.youtube.com/watch?v=Dgz_G8wwqI4

Posiblemente vCenter Server sea considerado el componente más importante de una infraestructura virtual en VMware vSphere™ ESXi 5. Es, por tanto, el componente que permite gestionar, centralizadamente, múltiples servidores VMware vSphere ESXi y máquinas virtuales.

El vCenter Server añade funcionalidad en áreas tales como alta disponibilidad (VMware HA), balanceo de carga (VMware DRS), Fault Tolerance (FT), actualización de componentes (Update Manager) y conversiones de físico a virtual (VMware Converter). Asimismo, en esta nueva versión y, por primera vez, tenemos la posibilidad de desplegar el vCenter Server en formato appliance el cual está basado en un sistema operativo Linux. Esto te permitirá seleccionar el tipo de instalación del servidor de vCenter, ¿Servidor Linux o servidor Windows? ¿Qué es el VMware vCenter Server? El servidor de vCenter actúa como un único punto de administración central en nuestro entorno de vSphere™ 5. El software de vCenter Server consiste en multitudes de módulos y servicios y es instalado en un servidor (virtual o físico) con el sistema operativo soportado Windows. A diferencia de las versiones anteriores, vSphere™ 5 incluye una nueva versión de vCenter Server en modo appliance para entornos con Linux. vCenter Server ofrece las funcionalidades Enterprise, como por ejemplo, VMware Distributed Resource Scheduler (DRS), VMware High Availability (HA), VMware Fault Tolerance(FT), VMware vMotion y VMware Storage vMotion. Una sola instancia de vCenter Server soporta un máximo de 1.000 hosts ESXi y 15.000 máquinas virtuales registradas (10.000 máquinas virtuales encendidas). Sin embargo, en el hipotético caso que necesitaras gestionar más de 1.000 servidores ESXi o 10.000 máquinas virtuales, tendrías que comprar otra licencia de vCenter y conectar estos sistemas de vCenter en lo que se denomina un group en mode Linked. El número máximo de servidores de vCenter Server (versión Windows) que se pueden conectar juntos (modo Linked ) entre si es de diez. Sin embargo, la versión Linux de vCenter, vCenter Server Appliance, no soporta aun esta funcionalidad de modo Linked. vCenter Server también puede ser instalado en Linked Mode, en caso de querer ver el estado del servidor de vCenter para todos los servidores en el inventario. Asimismo para poder desplegar este appliance en tu entorno virtual tendrás que formatear el disco y asignar un mínimo de RAM requerida para que arranque el appliance - Ver tabla de memoria RAM para el appliance más abajo -. Recuerda que no es posible conectar via Linked mode dos vCenter Servers de versiones diferentes. Por ejemplo, vCenter 4.1 y vCenter 5.0 no se pueden conectar usando la funcionalidad de Linked mode.

Los requerimientos mínimos para vCenter Server 5 son 2CPUs de 2Ghz de 64bits, 4GB de memoria RAM mínimo y 4GB de espacio en disco duro mínimo. vCenter Server 5 ya no soporta las bases de datos Oracle 9i ni Microsoft SQL Server 2000. Asimismo, el número máximo de vCenter Server que se pueden conectar con el vCenter Orchestrator es de diez. También, el número máximo de hosts conectados a un vCenter Orchestrator es de 1.000. Aviso: El número máximo de máquinas virtuales que pueden conectarse al vCenter Orchestrator es de 15.000. Hay tres componentes adicionales al vCenter Server que pueden ser añadidos al servidor de vCenter cuando sean necesarios: 

VMware vCenter ESXi Dump Collector



VMware vSphere Web Client



VMware vSphere Update Manager vCenter Server 5 requiere que la conectividad ODBC que se crea antes de instalar el servidor de vCenter, sea de 64bits. Este ODBC para conectar la base de datos con el vCenter, no es el mismo que el que se usa para conectar tu vCenter con Update Manager. Además, la conectividad ODBC para el servicio de Update Manager ha de ser de 32bits. En VMware vSphere™ ESXi es posible usar VMware Update Manager 5 - hablaremos de este servicio más adelante en este libro - para hacer actualizaciones del nuevo servidor vCenter Server Appliance. Recuerda que para poder hacer estas actualizaciones, primero has de configurar el vCenter Server Appliance para permitir actualizaciones desde la pestaña de update en vCenter Server Appliance

Nuevas funcionalidades en vCenter Server 5.

Con independencia de la versión de vCenter que instales, Windows o el appliance Linux, vCenter Server 5 instala, por defecto, los siguientes plug-ins: VMware vCenter Storage Monitoring, VMware vCenter Service Status y VMware vCenter Hardware Status, y uno nuevo en la versión 5 llamado Auto Deploy. Otra de las nuevas funcionalidades añadidas tanto en la versión vCenter Server para Windows como para Linux, es el hecho de que no solo podemos integrar nuestro vCenter en un dominio de directorio activo de Windows, sino que también ahora esta soportado NIS. Se necesita usar un sistema operativo de 64Bits, ya sea virtual, físico,Windows o Linux, donde ejecutar vCenter Server 5. VMware recomienda no instalar el servidor vCenter Server en un controlador de dominio. En cuanto a la configuración IP, también recomienda asignarle una dirección IP estática, o en su defecto, registrar el servidor en un DNS si se usa DHCP. Con vCenter Server podemos gestionar los siguientes servicios de una forma centralizada: High Availability (HA), Distributed Resource Scheduler (DRS) y Data Recovery. VMware soporta vCenter Server en una máquina virtual. Los beneficios son los siguientes: vCenter puede ser migrado con vMotion, es posible hacer un backup usando vCenter Data Recovery y éste puede ser protegido con VMware High Availability. Los módulos VMware vCenter Update Manager, VMware vCenter Guided Consolidation, VMware vCenter Convert, VMware Data Recovery, VMware vCenter CapacityIQ, VMware AppSpeed Server y VMware Site Recovery Mananger no están preinstalados cuando instalamos vCenter Server y, por consiguiente, deben de ser instalados a posteriori.

A continuación vemos el plugin vCenter Service Status que verifica el estado del servicio de vCenter Server. Este aspecto es muy interesante en una configuración en modo Linked ya que es posible ver el estado de todos los servicios de vCenter de sus respectivas instancias desde una sola consola.

Aviso: vCenter Server incluye una consola KVM (de las siglas en ingles Keyboard, Video and Mouse) embebida en cada máquina virtual registrada en el vCenter. El número máximo de sesiones concurrentes a la consola de una máquina virtual es de 40. Prerrequisitos hardware/software de vCenter Server 5 Requerimientos Hardware (Versión Windows): 

Procesador: 2 CPUs 64-bit 2.0GHz Intel o AMD x86.



Memoria: 4GB RAM mínimo.



Disco: 4GB recomendado.



Red: Adaptador Ethernet (1 Gigabyte recomendado). Requerimientos Software:



Windows XP Pro 64-bit, SP2 y SP3



Windows Server 2003 64-bit Standard, Enterprise y DataCenter, SP1 y SP2



Windows Server 2008 64-bit Standard, Enterprise y DataCenter, SP2



Windows Server 2008 R2 64-bit Los requerimientos de procesador, memoria y disco serán más altos si la base de datos de vCenter y Update Manager están instaladas en el mismo sistema virtual o físico.

Recuerda que el modo Linked aún no está soportado en la versión Linux llamada vCenter Server Appliance. Aviso: El número máximo de datastore que un vCenter puede ver es de 256. Asimismo, el servicio de vCenter Server requiere un IP fijo y un nombre de dominio interno registrado en tu servidor de DNS. Quizás el componente más importante en vCenter es su base de datos. vCenter Server 5 almacena todos los datos del inventario, estado de cada máquina virtual y configuración de cada Servidor VMware vSphere™ ESXi, en una base de datos relacional. Las bases de datos soportadas por vCenter Server para Windows son las siguientes: v Oracle Ø Oracle 10g F2 Ø Oracle 11g v IBM DB2 9.5 y 9.7 v Microsoft SQL Ø SQL Server Server 2005 SP3 (recomendado SP4) Ø SQL Server 2008 R2 Express* Ø SQL Server 2008 *SQL Server 2008 R2 Express es solo recomendada en entornos pequeños de hasta 5 hosts ESXi y 50 máquinas virtuales. En cuanto a la versión Linux de vCenter Server se refiere, los requerimientos de software son diferentes. No obstante, el usuario o administrador del entorno virtual, no notará ninguna diferencia con el hecho de tener la versión Windows o Linux de vCenter instalado en tu entorno. El servicio de vCenter en modo appliance reduce el tiempo requerido para instalar y configurar la versión de vCenter en Windows, ya que la versión appliance para Linux viene pre-instalada. Sin embargo, a nivel de base de datos el appliance aún no soporta SQL. A día de publicación de este libro solo soporta Oracle y DB2 (express) como base de datos.

vCenter Server virtual Appliance usa un kernel versión 2.6.32.29-03 de SuSe Linux y estos son sus requerimientos: Requerimientos Hardware (Versión Linux): 

Procesador: 2 CPUs 64-bit 2.0GHz Intel o AMD x86.



Disco: 7GB RAM mínimo. Máximo 82GB



Red: Adaptador Ethernet (1 Gigabyte recomendado).



Memoria: 

De 1-10 hosts ESXi o 1-100 máquinas virtuales: 4GB mínimo recomendado



De 10-100 hosts ESXi o 100-1.000 máquinas virtuales: 8GB mínimo recomendado.



De 100-400 hosts ESXi o 1.000-4.000 máquinas virtules:13GB mínimo recomendado.



Para más de 400 hosts ESXi o 4.000 máquinas virtuales: 17GB mínimo recomendado

Puedes ver el video tutorial de instalación y configuración del vCenter Server Appliance en nuestro canal de YouTube dedicado en exclusiva a la virtualización de sistemas en español: El servicio vCenter Hardware Status Plug-in

Es posible monitorizar la "salud" del hardware del servidor físico ESXi. Si la pestaña "Hardware Status" no está habilitada, comprueba que el plugin "vCenter Hardware Status" esté habilitado. Para hacerlo, selecciona plug-ins, Plug-in Manager. Con el botón derecho del ratón selecciona enable.

Recuerda que para que la pestaña Hardware Status te dé más información relativa al estado del hardware físico del servidor ESXi, el servicio "VMware VirtualCenter Management Webservices" ha de estar arrancado.

vCenter Server y la configuración del directorio activo

Por defecto, si eliminas un usuario de tu directorio activo, el cual está actualmente conectado al servidor de vCenter, el usuario permanecerá conectado hasta 24 horas. Puedes cambiar esta configuración modificando el valor de la casilla Validation Period. VMware vSphere vCenter Converter

VMware vSphere vCenter Converter es una herramienta gratuita que te permitirá convertir tus máquinas físicas a máquinas virtuales e incluso sin pérdida de servicio con las conversiones en caliente. Es posible instalar este software en el mismo servidor de vCenter via plugin o en modo standalone. Personalmente, prefiero la versión standalone ya que para mi gusto ofrece una funcionalidad de logs mayor. Para ejecutar el Converter instalado en modo plugin, selecciona uno de los servidores ESXi donde quieras convertir una máquina física a virtual con el botón derecho y selecciona Import Machine. vCenter Converter, tanto la versión plugin como la versión standalone, soporta imágenes de Symantec Ghost (.gho), Acronis True Image (.tib) , StorageCraft y máquinas virtuales tanto Windows como Linux de otros productos de VMware, como por ejemplo VMware Workstation, VMware GSX Server, VMware Fusion, VMware ESX, así como de otros proveedores de software de virtualización, como por ejemplo, Microsoft HyperV, Microsoft Virtual PC, Microsoft Virtual Server y Parallels Desktop. vCenter Converter soporta conversiones de físico a virtual (P2V), de virtual a virtual (V2V) y de imagen a virtual (I2V), pero aun no soporta conversiones de virtual a físico (V2P). vConverter requiere tener los siguientes puertos TCP abiertos: 139, 443, 445 y 902. Aviso: Recuerda que vCenter Converter también se pude utilizar para convertir máquinas virtuales de otras soluciones de virtualización, como por ejemplo VMware Fusion, Microsoft Virtual Server, Microsoft Hyper-V y Virtual PC, a formato VMware ESX/ESXi. Es lo que se denomina una conversión de virtual a virtual o V2V.

vCenter Server en modo Linked Mode

Durante la instalación de vCenter Server, puedes elegir instalar vCenter en modo "standalone" o “linked mode”. La primera instancia del vCenter ha de ser instalada en modo standalone. Siempre que se requiera o sea necesario, podemos cambiar el modo ( “Linked Mode” o “standalone”) del vCenter Server. La opción del modo “Linked mode” te permite gestionar todo tu entorno desde un punto único central, con independencia a que vCenter server te conectes con tu vSphere client. No solamente este modo Linked te facilita la gestión desde una sola consola en entornos grandes. A veces, no hay más remedio que configurar nuestros servidores de vCenter en modo Linked. Por ejemplo, cuando tienes que registrar más de 1.000 servidores ESXi o más de 10.000 máquinas virtuales encendidas - este es el límite de una sola instancia de vCenter Server 5 (versión Windows) -, necesitas modificar la configuración de vCenter 5 y configurarlo en modo Linked Mode. Por supuesto, está claro que necesitarás otra licencia de vCenter Server y otra base de datos en el backend para poder emparejar las dos instancias, o más, y superar el límite mencionado. No es posible emparejar servidores de vCenter que no pertenezcan a un domino. Por consiguiente, si quiere emparejar servidores de vCenter en modo standalone, tendrás primero que incluirlos en un dominio. Los vCenters que vas a emparejar pueden estar en dos dominios diferentes, como por ejemplo, vmware.com y Microsoft.com. No obstante, asegúrate de configurar una relación de confianza bi-direccional en los directorios activos de los dos dominios para que puedan emparejarse.

Asimismo, el mode Linked se basa en gran medida en el servicio de DNS con lo que has de asegurarte, antes de empezar el wizard de emparejamiento, que tu servidor de DNS funciona correctamente. Por otro lado, si tienes problemas al intentar conectar con tu servidor de vCenter, verifica si el servicio de Windows de Virtual Center Server está arrancado en la máquina virtual o física donde lo has instalado. También, puede ocurrir en entornos con servidores ESX que si te quedas sin espacio en la partición / (root), pueda causar disrupciones en la conectividad de tu vCenter con el vSphere Client. Para lanzar el wizard de emparejado, dentro del servidor de vCenter en Windows, selecciona inicio > programas > vmware > vCenter Server Linked Mode Configuration. vCenter Server y las opciones de archivado desde la pestaña Maps

vCenter Server incluye una pestaña llamada Maps la cual puedes usar para ver una instantánea de cómo está configurado tu entorno virtual. Esta opción de Maps, te permite no solo exportar los mapas en diferentes formatos: JPG, BMP, PNP, GIF, TIFF y EMF sino que ahora, en la versión vCenter Server 5, podrás imprimirlos directamente a una impresora que tengas configurada en tu servidor de vCenter. Para exportar los mapas, selecciona File > Export > Export Maps. Después, selecciona la extensión del formato de la imagen a exportar. Desde el vCenter Maps, puedes ver otros recursos de tu entorno virtual como por ejemplo DataStore y Host resources.

Recuerda que los iconos en los mapas son interactivos y basta con hacer un clic con el botón derecho del ratón sobre el icono para ejecutar acciones. El uso de los mapas también es muy interesante para comprobar si tus máquinas virtuales son compatibles con vMotion. En la imagen anterior, observamos que la máquina virtual con nombre AD no puede ser migrada con vMotion al servidor ESXi2.demos.local porque no está conectada a la red de producción, entre otras cosas!. ¿Cómo añadir un servidor ESXi al inventario de vCenter Server 5? Una vez que hayas instalado el servidor de vCenter (Windows o Linux) ya podrás añadir tus servidores hosts ESXi al inventario para que estos puedan ser gestionados y configurados. Para añadirlos, previamente has de crear un objeto de inventario de tipo DataCenter. Simplemente, selecciona con el botón derecho del ratón el objeto inventario raíz - el objeto de inventario raíz del vCenter es el nombre de red que le hayas dado a tu servidor de vCenter - y selecciona create DataCenter. Después de que hayas creado el objeto de inventario DataCenter, selecciónalo este objeto con el botón derecho del ratón y elije Add Host

Luego, introduce los datos de tu servidor ESXi, nombre de host, usuario y contraseña y selecciona siguiente. Durante la inclusión de tu servidor ESXi al inventario de servidor de vCenter, este enviará un agente de gestión al servidor ESXi llamado vpxa. Desde ese momento, este agente será utilizado por el vCenter para gestionar tu servidor ESXi. Puede ser que no sea posible añadir un servidor ESXi al inventario y recibas este error:

Entre las posibles razones es que haya algún problema de comunicación entre el vCenter y el servidor ESXi o el agente de gestión del servidor ESXi (hostd) no está funcionando correctamente. Para asegúrate de que el agente ESXi está funcionando, entra en la consola y ejecuta el siguiente comando: ~ # ps | grep hostd 2847 2847 hostd-worker 2848 2847 hostd-poll

hostd hostd

2849 2847 hostd-worker

hostd

2850 2847 hostd-worker

hostd

2865 2865 nssquery

/usr/libexec/hostd/nssquery

2866 2847 hostd-worker

hostd

2873 2847 hostd-worker

hostd

3044 3044 nssquery 3070 2847 hostd-vix-high-

/usr/libexec/hostd/nssquery hostd

3071 2847 hostd-vix-poll

hostd

3359 2847 hostd-hbr

hostd

3360 2847 hostd-worker

hostd

3361 2847 hostd-worker

hostd

3362 2847 hostd-worker

hostd

3475 2847 hostd-worker

hostd

3476 2847 hostd-worker

hostd

~# Si este agente estuviera parado, puedes arrancarlo desde la consola DCUI de tu servidor ESXi seleccionado F2 > Restart Management Network.

El plugin de vCenter para hacer backups de las máquinas virtuales, VMware Data Recovery

VMware Data Recovery es un appliance basada en Linux la cual nos permite hacerbackup/restore de todas nuestras máquinas virtuales Linux o Windows, incluso con las máquinas virtuales encendidas. Te puedes descargar este appliance desde la página web de VMware, siempre y cuando te hayas registrado o tengas un usuario válido. Una vez descargado, la instalación en vCenter sigue el mismo proceso de instalación de cualquier otro appliance basado en OVF - de las siglas en inglés Open Virtualization Format -. Puedes ver un video tutorial de instalación de

este appliance en nuestro canal oficial de YouTube: ¿Cómo instalar VMware Data Recovery? Aparte de este appliance, la cual es la parte servidor, has de instalar el ejecutable VMwareDataRecoveryPlugin.msi en el sistema donde estas ejecutando vSphere Client, el cual es la parte cliente. Desde el menú Plugins, Manage Plugins puedes ver el Plugin Manager. Hay dos pestañas de configuración, la pestaña Available y la pestaña Installed. En la ventana Plugin Manager puedes hacer el "Download & install" de la parte cliente del plugin. Sin embargo, el plugin no estará definitivamente instalado y visible en vCenter hasta que éste no se habilite desde el Plugin Manager. Recuerda que para usar y licenciar VMware Data Recovery has de tener mínimo la licencia Essentials Plus. Aviso: Para habilitar un plugin es necesario descargar e instalar el plugin desde el servidor donde te estás conectando con el vSphere Client. Con el Plugin Managerpuedes habilitar un plugin y ver los plugins disponibles que no están instalados. Calculando el tamaño de la base de datos de vCenter

El tamaño de la base de datos de vCenter varía dependiendo del número de servidores ESXi y de las máquinas virtuales que tengas registradas, pero por cada 50 máquinas virtuales necesitarás, al menos, 700MB extra de espacio en disco.

Desde la opción vCenter Server Setting > Statistics > Database Size puedes crear simulacros cobre el tamaño necesario para la base de datos de tu vCenter. Recuerda que esta opción es solo un simulacro y no cambia nada de tu configuración. Aviso: En la imagen anterior, la cantidad de espacio estimado es para una base de datos SQL. Si vas a utilizar en tu entorno una base de datos con Oracle, asegúrate de dividir por dos el valor mostrado con esta utilidad.

Capítulo 6: Máquinas Virtuales en vSphere™ 5 Una de las formas más eficientes de desplegar máquinas virtuales es mediante el uso y creación de plantillas (templates). Una vez que la plantilla haya sido creada, podrás crear máquinas virtuales de una manera mucho más rápida, automatizada y sin errores. Otros métodos de creación de máquinas virtuales incluye la funcionalidad de cloning, la importación de plantillas o incluso la creación de máquinas virtuales desde una conversión de un servidor físico a virtual con el VMware vConverter. Los distintos ficheros que forman una máquina virtual

Una máquina virtual es un conjunto de ficheros en donde se ejecuta el sistema operativo y las aplicaciones. Los tres ficheros más importantes que forman una máquina virtual son: el fichero BIOS(.nvram), el fichero de configuración (.vmx) y el fichero del disco virtual (.vmdk). Para poder acceder a la BIOS de una máquina virtual, presiona F2 cuando la máquina virtual está arrancando o edita la configuración de la MV para forzar que entre en la BIOS cuando se encienda. Adicionalmente, los ficheros de snapshot de una máquina virtual son: 00000#-delta.vmdk, 00000#.vmdk y SnapshotNombre.vmsn. Los ficheros con extensión .vmem corresponden a la memoria de la máquina virtual mapeada a un fichero. Este fichero solo existe si la máquina virtual está encendida o tiene un snapshot.

Los ficheros con extensión .vmss corresponden al fichero de una máquina virtual en modo suspendida. El fichero VM_nombre-flat.vmdk es el que se tiene en cuenta a la hora de determinar el tamaño apropiado para calcular el fichero de paginación en Windows o la partición swap en sistemas Linux. Si conviertes la máquina virtual a una plantilla, el fichero de configuración de ésta (.vmx) es reemplazado por el fichero de configuración de una plantilla (.vmtx). Cuando una máquina virtual experimenta un fallo (BSOD o kernel panic en Linux), el servidor ESXi crea un fichero core dump en el mismo directorio donde reside el fichero de configuración de la máquina virtual. Asimismo, las máquinas virtuales incluyen otro fichero llamado CBT - de las siglas en ingles Change Block Tracking – el cual es usado por VMware Data Recovery para saber cuáles son los bloques que han cambiado a nivel de máquina virtual para solo hacer un backup de estos bloques modificados durante el último backup. Una mejor práctica en cuanto a la nomenclatura a usar en el nombre de las máquinas virtuales, es intentar evitar usar caracteres especiales, como por ejemplo, espacios. Aviso: En vSphere™ 5 verás un segundo fichero swap con el nombre vmx.vswp el cual contiene la cantidad de memoria overhead reclamada por la máquina virtual. Este mecanismo ayuda a incrementar el número del ratio de consolidación por servidor con respecto a versiones anteriores. Las VMware tools: ¿Qué son y cómo se instalan? Otra muy buena práctica en cuanto a las máquinas virtuales se refiere, es la instalación de las VMware Tools después de la instalación del sistema operativo.

Las VMware tools se instalan como una aplicación más dentro de la máquina virtual. Selecciona la máquina virtual desde el inventario, haz un clic derecho con el ratón y selecciona Install/Upgrade VMware Tools. Las VMware tools incluyen los siguientes drivers: SCSI, SVGA, ratón, VMXNET 3 adaptador de red, Memory Control (ballooning), Filesystem Sync y soporte para el servicio Windows: Volume Shadow Copy Services (VSS). El driver de ballooning es también conocido como vmmemctl driver y su principal misión es "reclamar" memoria no usada a las máquinas virtuales. La máxima cantidad de memoria que el driver vmmemctl puede reclamar a una MV es de un 65% de la memoria no reservada. En vSphere™ 5, VMXNET 3, es el nombre del adaptador de red "paravirtualizado" de alto rendimiento. Este adaptador solo está soportado en máquinas virtuales con hardware virtual versión 8 (Las máquinas virtuales en vSphere™ ESX/ESXi 4.x usan hardware virtual versión 7 y en vSphere™ ESXi 5 el hardware virtual es versión 8). Asimismo, las VMware Tools mejoran el movimiento del ratón, la gestión de la memoria y también permiten hacer shutdown de la máquina virtual desde el menú de inventario del vCenter. El máximo de memoria RAM que una máquina virtual puede tener configurado en vSphere™ 5 es de 1TB. Una máquina virtual puede fallar al encenderla, si la reserva de memoria asignada a esta máquina virtual no puede ser garantizada por el VMkernel con lo que cuidado con hacer reservas de memoria altas en tus máquinas virtuales!. Usa Ctrl + Alt + Ins en lugar de Ctrl + Alt + Del para entrar en la consola de una máquina virtual. ¿Qué es un vApps y cómo crearlo en vSphere™ 5?

Un vApp en VMware es la entidad lógica constituida por una o varias máquinas virtuales, que utilizan el formato OVF para especificar y encapsular todos los componentes de una aplicación multinivel, así como las políticas y niveles de servicio asociados a la misma. El número máximo de caracteres que puedes usar para crear el nombre de un vApp es de 80. Este tipo de contenedores es ideal para aplicaciones multitiered donde tenemos aplicaciones o máquinas virtuales en el backend, front-end y en el midle-tier. De esta forma, al agrupar las distintas máquinas virtuales en un solo vApp podemos encenderlas, apagarlas y clonarlas con un solo clic de ratón. Los objetos que pueden ser incluidos en un vApp son los siguientes: 

Resource Pools



Máquinas Virtuales



vApps, es decir, un vApp dentro de otro vApp. Para poder crear un vApp es necesario que se cumplan las siguientes condiciones: 1. Debes habilitar la opción de DRS en el clúster, aunque también es posible crear un vApp en un servidor ESXi en modo standalone 2. La versión del servidor debe ser ESX 3.x o superior. 3. Debes elegir una carpeta dentro de la vista "Virtual Machine and Templates". Una vez que hayas creado un vApp - usa el wizard de creación de vApps ( File > New > vApp) hay tres opciones en el IP Allocation Policy para un vApp: Fixed, Transient yDHCP. Esto indica el mecanismo que tienen las máquinas virtuales para ser configuradas con una IP de red.

Si las opciones de vApp están deshabilitadas en las propiedades de la máquina virtual que forma parte de un vApp, no podrás editar el IP Allocation Policy como vemos en la siguiente imagen.

Asimismo, dentro del vApp en la pestaña de configuración Start Order, puedes seleccionar que máquina virtual arranca antes, cual es la secuencia de arranque del vApp y el delay en segundos que quieres configurar entre el arranque de las máquinas virtuales. ¿Qué son los clones y plantillas y cómo crearlas en vSphere™ 5?

Un clone es una copia exacta de la máquina virtual (mismo SID, hostname, dirección IP, etc) y es posible hacer dicho clone mientras la máquina virtual está encendida. No obstante, la MAC virtual de la tarjeta virtual del clone es diferente para evitar tener más de una máquina virtual con la misma MAC virtual. La opción Clone to Template, crea una plantilla de una máquina virtual ya configurada. Esta máquina virtual es marcada como plantilla y no podrá ser encendida hasta que la plantilla sea convertida en máquina virtual (Convert to Virtual Machine). Si precisaras actualizar una

plantilla (service pack, etc), deberás convertir la plantilla a máquina virtual, actualizarla y posteriormente convertirla de nuevo en plantilla. Para poder cambiar la identidad de un clone o template desde vSphere Client, es necesario usar Sysprep, una herramienta de Microsoft incluida en el CD del sistema operativo (deploy.cab) No obstante, has de copiar a mano los archivos de Sysprep en el directorio "C:\Documents and Settings\All Users\Application Data\VMware\VMware VirtualCenter\sysprep" del servidor de vCenter. Ahí deberás ubicar los diferentes Sysprep según las versiones de Windows que indican los diferentes subdirectorios que existan. En caso de no copiar los ficheros de Sysprep, no podrás hacer ninguna parametrización de clones o plantillas.

Adicionalmente, si quieres personalizar una máquina virtual Linux, has de instalar Perl en el sistema operativo Guest. La opción, Convert to Template, convierte una máquina virtual en plantilla. La máquina virtual debe estar apagada. El uso de plantillas ofrece varios beneficios fundamentales: usan menos espacio en disco y éstas no pueden ser modificadas hasta que no se conviertan a máquinas virtuales. De igual forma, se asegura un despliegue rápido y sin esfuerzo de las máquinas virtuales a la vez que se estandarizan las mismas. Cuando creas un clone o template de una máquina virtual que tiene discos RDM en formato "Physical Compatibility Mode", la máquina virtual resultante crea el disco RDM pero cambia el formato a "Virtual Compatibility Mode". Recuerda que es posible hacer clones y templates de máquinas virtuales con discos RDM. La característica fundamental de un disco RAW en modo "Physical Compatibility mode" es que permite al sistema operativo "Guest" acceder al hardware directamente sin que el VMkernel haga ninguna traducción binaria de las instrucciones.

Dos de los grandes beneficios de un disco RDM en modo virtual es que podrás usar las funcionalidades de cloning y plantillas.

Aviso: Las máquinas virtuales que usan discos FC RDM te permitirán usar software de clustering, agentes de gestión SAN y software SCSI dentro de la misma máquina virtual. El tamaño máximo de un RDM soportado en VMware vSphere™ 5 y en modo físico es de 64TB. Las máquinas virtuales en un DataCenter pueden ser clonadas a otro diferente, pero no pueden ser migradas con vMotion. ¿Cómo habilito o deshabilito la opción de logging en la máquina virtual?

Es posible habilitar o deshabilitar la opción de logging para un número determinado de máquinas virtuales. Edita las propiedades de la máquina virtual desde el vSphere Client, bajo Options, selecciona Advance y después General.

Por defecto, la opción de logging para las máquinas virtuales está activada. Una de las posibles razones por la que quizás quieras desactivar esta opción, podría ser el poder maximizar el espacio disponible en los DataStores. No confundas la opción de login con la de logging. Hay seis archivos de log que siempre se mantienen archivados para todas y cada una de máquinas virtuales existentes en tu entorno. Por ejemplo, de -1.log a -6.log son los ficheros logs de las máquinas virtuales que se crearán por primera vez cuando se cree una máquina virtual. La próxima vez que un archivo de log sea creado, por ejemplo, cuando una máquina virtual es apagada o encendida, ocurre lo siguiente: 

Los ficheros de -2.log a -7.log son mantenidos y el fichero -1.log es borrado.



Después, los ficheros -3.log a -8.log son mantenidos y así sucesivamente. Mejoras en la funcionalidad de vMotion en vSphere™ 5

vSphere™ ESXi 5 permite desplegar máquinas virtuales entre diferente centros de datos. También te permite clonar una máquina virtual desde un centro de datos a otro. Asimismo, es posible desplegar una máquina virtual desde una plantilla localizada en un centro a otro centro de datos diferente. Por ejemplo, podrías clonar una máquina virtual Windows desde el centro de datos Data Center A al Data Center B. Sin embargo, no es posible migrar en caliente una máquina virtual con VMotion desde un centro de datos a otro. El error que se muestra en el vSphere Client es: "The input arguments had entities that did not belong to the same datacenter".

Una de las mejoras de vMotion en la nueva versión de vSphere™ ESXi 5 es el hecho de poder crear diferentes vmknics y agruparlas en un mismo VSS para poder incrementar la velocidad de las migraciones en caliente. Asimismo, VMware vSphere™ ESXi 5 incluye Metro vMotion. Ahora, con Metro vMotion, no sólo tendrás un mejor rendimiento de tus migraciones en redes con una latencia muy alta, sino que también, el RTT - de las siglas en ingles round trip time - ha aumentado de cinco a diez milisegundos. Antes de la versión vSphere™ 5.0, vMotion sólo soportaba redes con latencia de ida y vuelta de hasta cinco milisegundos. Con Metro vMotion y VMware vSphere 5.0, podrás migrar en caliente tus máquinas virtuales cuando el host de origen y el host destino tienen una latencia superior a 5 milisegundos. Por supuesto, la mala noticia es que para poder disfrutar de Metro vMotion necesitas, al menos, licencia Enterprise plus. Configurando el Power Management en las máquinas virtuales

Las opciones de Power Management te permiten especificar como responde una máquina virtual cuando el sistema operativo Guest es puesto en standby. Estas opciones están disponibles para todas las máquinas virtuales. No obstante, la opción de Wake on LAN (WOL) solo está soportado para sistemas operativos Windows y en alguno sistemas operativos Linux y no está disponible en las tarjetas virtuales que utilicen el driver Vlance, es decir, aquellas máquinas virtuales en las que las VMware tools no están instaladas en el SO Guest. Otra razón importante para instalar las VMware Tools!.

Migraciones vMotion con ¿High Priority o Low Priority?

Hay dos requerimientos fundamentales para poder hacer migraciones con VMware: 1. Los dos servidores vSphere™ ESXi 5 involucrados en la migración tienen que estar conectados via red Ethernet Gigabyte. 2. Las máquinas virtuales deben tener acceso a las mismas subredes en los host vSphere™ origen y destino. VMware vMotion permite mover una máquina virtual desde un servidor ESXi a otro. Una migración en frío (cold migration), mueve una máquina virtual apagada y permite reubicar su disco virtual en otro DataStore. La migración en frio (es decir con la máquina virtual apagada) pueden ejecutarse entre CPUs de distintos fabricantes, Intel y AMD. Para migraciones con VMware vMotion en caliente, las CPUs han de ser compatibles dentro de la misma familia de procesador y del mismo fabricante. Las migraciones en caliente (hot migration) pueden fallar cuando activamos el soporteVMI Paravirtualización en la máquina virtual del host ESXi origen y el host destino no tiene soporte para VMI Paravirtualizacion. Por cierto, no te cuento que es VMI paravirtualización pues VMware lo ha desactivado en esta nueva versión. Recuerda que la migración en caliente, mueve la máquina virtual de un servidor ESXi a otro pero no mueve su disco virtual. Una migración con High Priority (Reserve CPU for Optimal VMotion performance)reserva recursos en el host destino, por tanto, la migración puede que no se ejecute si el host destino no tiene recursos suficientes.

Una migración con Low Priority (Perform with available CPU resources) no reserva recursos en el host destino, por tanto, migraciones con low priority siempre se ejecutan con éxito, aunque es posible que el proceso de migración sea más largo. Recuerda que el número máximo de migraciones en caliente con vMotion, para una red de 1Gb/s, es de 4 migraciones simultáneas. Sin embargo, para una red de 10Gb/s, el número de migraciones simultáneas con vMotion sube hasta 8. Asimismo, el número máximo de migraciones simultáneas con vMotion por datastore es de 128. Una máquina virtual que esté usando VMDirectPatch I/O no puede ser migrada con vMotion. VMotion soporta máquinas virtuales con discos RDM (Raw Device Mapping) en compatibilidad física así como discos en modo thick o thin. Dicho sea de paso, el disco de una máquina virtual puede ser convertido de thick athin mientras que la máquina virtual está encendida y usando Storage vMotion. Asimismo, la misma máquina virtual puede ser "inflada" de thin a thick, pero solo mientras la máquina virtual está apagada usando la opción de inflate como muestro en la siguiente imagen:

Aumentando el rendimiento de las máquinas virtuales con Storage VMotion

Una manera de optimizar el Storage para aumentar el rendimiento de las máquinas virtuales es a través de Storage vMotion. En el ejemplo anterior, si la LUN de la izquierda se convierte en un cuello de botella, todo lo que tienes que hacer es crear una nueva LUN VMFS y mover las máquinas virtuales – en caliente - a la nueva LUN. La LUN origen y LUN destino pueden tener una configuración RAID diferente.