Virtualización con VMware vSphere
eBook por José María González
José María González
[email protected] http://www.jmgvirtualconsulting.com @jmgconsulting
Capítulo 1. Primeros pasos en la certificación VMware vSphere™ VCP™ 3 Capítulo 2. Instalación vSphere™ ...................................................................... 7 Capítulo 3. Red en vSphere™ ............................................................................ 24 Capítulo 4. Almacenamiento en vSphere™ .................................................... 40 Capítulo 5. VMware vCenter Server ............................................................... 55 Capítulo 6. Máquinas Virtuales en vSphere™ ............................................... 70 Capítulo 7. Control de acceso en vSphere™ ................................................... 83 Capítulo 8. Gestión de recursos en vSphere™................................................ 92 Capítulo 9. Monitorización de recursos en vSphere™ ................................. 96 Capítulo 10. Funcionalidades Enterprise en vSphere™ ........................... 104 Gracias y Cierre .................................................................................................. 127
Capítulo 1. Primeros pasos en la certificación VMware vSphere™ VCP™
¿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.
¿Cómo conseguir la certificación VCP™ ? 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™ Los cursos aceptados son: VMware vSphere 6.x: Install, Configure and Manage v6 VMware vSphere 6: What´s New (Este curso es necesario solo para los candidatos que ya tengan la certificación oficial VCP5) 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 VCP6™. 3. Inscribirse y aprobar el examen oficial. Para inscribirse en el examen VCP™ 6 (VMware Certified Professional), has de darte de alta en VMware en la siguiente dirección: http://www.jmgvirtualconsulting.com/Formacion/VMware/VMwarevSphere-ICM-Install-Configure-and-Manage-6 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 VCP6™ en vSphere™ 6. 1. Si eres nuevo en el mundo VMware:
Asiste al curso oficial VMware vSphere™ 6: Install, Configure and Manage.
Aprueba el examen VCP6 en vSphere™ 6.
2. Si eres actualmente un VCP3 en VMware Infrastructure 3:
Asiste al curso oficial VMware vSphere™ 6: Install, Configure and Manage o al curso oficial What´s New 5 a 6.
3. Si eres actualmente un VCP4 en VMware ESX/ESXI 4.x:
Asiste al curso oficial VMware vSphere™ 6: Install, Configure and Manage
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™ 6. 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 VCP6™ en vSphere 6™? 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 VCP6™ en vSphere 6™? 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 VCP6™ de vSphere™ 6? En el examen hay 125 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™6? En la dirección web adjunta, podrás encontrar una guía oficial VMware (VCP6 Exam Blueprint) sobre la materia que se cubre en el examen. Usa esta guía como referencia para preparar el examen: (requiere login) 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™
En esta primera sección verás una introducción a la virtualización y la instalación de VMware vSphere™ ESXi, los mínimos y máximos tanto soportados como certificados por VMware vSphere™ ESXi / vCenter Server™, 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™ ¿Cómo es la virtualización con VMware vSphere™?
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™ es que la versión vSphere™ ESX ya no está disponible. También, ahora con la nueva versión de ESXi™, es posible instalar la imagen de un ESXi 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™ incluye una nueva versión para su sistema de archivos llamada VMFS-6 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™. Para poder ver el video tutorial de instalación de un servidor ESXi y muchos más videos tutoriales, entra en nuestra página web dedicada en exclusiva al contenido multimedia extra de este manual en http://www.josemariagonzalez.es/curso-online-gratuito - podrás ver más de 100 videos gratis sobre virtualización con VMware vSphere. Alternativamente, también puedes ver videos tutoriales de instalación y configuración de VMware vSphere ESXi, 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™?
Una máquina virtual en VMware vSphere™, 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, 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. ESXi 6 ya soporta USB versión 3.0 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 te estás preparando el examen oficial de certificación VCP™, 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. VMware vSphere™ permite crear máquinas virtuales usando dos wizards: Typical y Custom. 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. La versión del hardware virtual en la versión 6.0 es la 11!. Para poder ver el video tutorial de instalación de una máquina virtual en un servidor ESXi, entra en nuestra página web dedicada en exclusiva a los videos tutoriales gratuitos de contenido multimedia de en: http://www.josemariagonzalez.es/curso-online-gratuito ¿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. 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? A día de hoy, es posible instalar VMware vSphere™ ESXi en cualquier tipo de servidor de nueva generación. Asimismo, la lista de compatibilidad de hardware para VMware vSphere™ ESXi ha aumentado considerablemente en esta última versión, debido principalmente, a que ESXI es la única versión disponible en vSphere™. 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 esxcfgfirewall 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 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 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
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™
Durante la instalación de vSphere™ ESXi, 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 el installer 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. 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 hasta 256 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és GUID Particion Table en lugar del formato MBR - de las siglas en ingles Master Boot Record - lo cual permite instalar ESXi 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™
Ahora VMware vSphere™ ESXi 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 tipo Service 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 Profile localizado 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, te recomiendo que veas el episodio correspondiente de nuestro canal de televisión web sobre la virtualización y el cloud computing en español en la siguiente dirección: http://youtube.com/blogvirtualizacion 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: 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 (VMFS3) 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.
VMware vSphere™ ESXi 6, ahora soporte NFS versión 4.1!. 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 VMFS5 en nuestro curso online vmware gratutio: http://www.josemariagonzalez.es/curso-online-gratuito 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ímite. En VMFS-3 el máximo número de ficheros era de 30.720 ficheros. Diagnosticando un problema en vSphere Para poder diagnosticar un problema con vSphere ESXi, 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.
Capítulo 3. Red en vSphere™
La funcionalidad de red en una infraestructura virtual es de suma importancia. Permite que las máquinas virtuales en un servidor VMware vSphere™ ESXi 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™ 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 un distributed 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
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 de 4088. 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:
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™
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 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 group y 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, 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 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 switches no será usada en ningún momento de forma interna. Las políticas de balanceo de carga en un VSS en vSphere™
En VMware vSphere™, el adaptador NIC físico conectado al primer puerto de Management Network es denominado vmk0. El primer puerto de gestión definido en nuestro servidor VMware ESXi 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
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 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™ 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™, 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 a Accept, 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 trama saliente 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 son Reject (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 el KB 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 el outbound 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™ 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 de NetFlow. 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 en Kbps, 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 un port 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™, 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 source MAC hash y explicit failover order. Recuerda que las políticas de load balancing para 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 enlace upstream. 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 tipo VMkernel, 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
É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
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 switch con 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™
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™
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 el LUN 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™?
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 tipo dependent 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™
La buena noticia es que el módulo para el adaptador de fibra es reconocido por el VMkernel 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 Rescan en 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 proveedor Qlogic. LPFC es el nombre corto del módulo del driver Linux para una HBA del proveedor Emulex. 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™?
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.200601.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 nuestro curso online gratuito de VMware en: http://www.josemariagonzalez.es/curso-online-gratuito VMware vSphere™ 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™
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. En la versión 6 de VMware ESXi, ya es posible usar NFS versión 4.1! También, es posible activar la opción CHAP para conexiones de tipo NFS. El protocolo CHAP 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™
En vSphere™ 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™, 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 dos port 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. 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
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™ ESXi 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™
vSphere™ 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™ 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 Ahora, en la nueva versión de vSphere™, 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
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.
Capítulo 5. VMware vCenter Server
Posiblemente vCenter Server sea considerado el componente más importante de una infraestructura virtual en VMware vSphere™ ESXi. 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™. 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™ 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 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 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.
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á instalada 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: o De 1-10 hosts ESXi o 1-100 máquinas virtuales: 4GB mínimo recomendado o De 10-100 hosts ESXi o 100-1.000 máquinas virtuales: 8GB mínimo recomendado. o De 100-400 hosts ESXi o 1.000-4.000 máquinas virtules:13GB mínimo recomendado. o 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? 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
/usr/libexec/hostd/nssquery
3070 2847 hostd-vix-high3071 2847 hostd-vix-poll 3359 2847 hostd-hbr
hostd hostd 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 hacer backup/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 curso online gratuito en esta direccion: http://www.josemariagonzalez.es/curso-online-gratuito 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 Manager puedes 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™
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™?
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 y DHCP. 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™?
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™
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 soporte VMI 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 a thin 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.
Capítulo 7. Control de acceso en vSphere™
El control de acceso en vCenter Server y ESXi permite controlar el acceso a los recursos y máquinas virtuales en un entorno virtual con múltiples usuarios de una manera mucho más flexible y dinámica. ¿Cómo son los premisos en vSphere™?
El modelo de seguridad de vCenter (user/group, role y privilegios) y VMware vSphere ESXi difiere del modelo tradicional de otros sistemas operativos, como por ejemplo Windows o Linux. En VMware vSphere™, el sistema de control de acceso permite al administrador de vCenter definir accesos y privilegios a todos y cada uno de los objetos de inventario visibles en vCenter. Este sistema de control de acceso es definido de la siguiente manera: Privilegio: La posibilidad de ejecutar ciertas acciones en vCenter como por ejemplo, encender una máquina virtual, crear una alarma, crear un clúster y etcétera. Role: Es un conjunto de privilegios y una forma de agrupar todos los privilegios individuales en una sola entidad. Objeto: Se refiere al objeto de inventario, Resource Pool, máquina virtual, DataCenter, carpeta, en donde se aplican los permisos. Usuario o grupo: Se refiere al usuario o grupo que puede ejecutar una acción determinada.
La combinación de un role, un usuario o grupo más el objeto representan los permisos en VMware vSphere™. Los roles predefinidos en VMware vSphere ESXi son: No Access, Read-only y Administrator. Asimismo, si en tu entorno cuentas con VMware vCenter este tendrá los siguientes roles definidos por defecto: Virtual Machine Power User, Virtual Machine User, Resource Pool Administrator,VMware Consolidated Backup User, Datastore consumer, Network consumer. Es posible definir nuevos roles a nivel de host ESXi, aunque no es una mejor práctica ya que estos roles creados a nivel de host no se propagan al servidor vCenter Server por lo que es recomendable crear nuevos roles en el servidor de vCenter. El role del vCenter Server, Virtual Machine Administrator, tiene por defecto, privilegios de performance. Asimismo, el role predefinido a nivel de vCenter llamado administratror puede hacer cualquier tarea en cualquier objeto del inventario de los servidores ESXi. Orden de prioridad de los permisos en vSphere™
Los permisos son asignados a los objetos de inventario (DataCenter, clúster, Servidor ESX/ESXi, Resource Pool, Máquina Virtual) del vCenter, mediante la asociación de un usuario o grupo con un role. Si un usuario es miembro de múltiples grupos con diferentes permisos en diferentes objetos, los permisos se "suman". Recuerda que cuando asignes permisos directamente a un servidor vSphere ESXi, no podrás asignar permisos en carpetas y virtual machines. Los permisos definidos explícitamente a un usuario en un objeto, tienen preferencia sobre los permisos definidos a un grupo sobre el mismo objeto.
Un Resource Pool Administrator puede mover un Resource Pool y modificar permisos dentro de su Resource Pool. Un Datacenter Administrator puede crear Resources Pools y añadir hosts al inventario. El role No Access, permite a un administrador eliminar los permisos en un objeto que de otra forma se hubiesen propagado. El role Administrator, predefinido en vCenter Server, es el único que puede asignar permisos a los usuarios. Los dos únicos usuarios asignados a este role son el usuario root y el usuario vpxuser. Asimismo los permisos aplicados directamente a un objeto del inventario, sobrescriben los permisos heredados (Propagate to Child Objetcs). Si un usuario o grupo pertenece a un role en vCenter Server y el role es borrado, los usuarios o grupos asignados a ese role no tendrán permisos en vCenter. Aviso: Si quieres restringir la posibilidad que un administrador pueda instalar plugins con vSphere Client, debes modificar los permisos de dicho administrador y eliminar el permiso Register Extension privilege. Clonando roles en VMware vSphere™
En vSphere™, es posible clonar los roles preestablecidos. Pero, ¿cuál es el objetivo de clonar un role? Bien, los roles pre-establecidos cumplen su misión en el 99% de los entornos de los clientes. No obstante, hay veces en los que hay que crear un nivel de granularidad, a nivel de permisos, más concreto y preciso. Por consiguiente, una mejor practica es la de no cambiar los privilegios en los roles existentes, sino, crear un clone de ese role, renómbralo con el nombre que más se ajusta a nuestro entorno y después cambiar los privilegios que sean necesarios en este role clonado. Cuando clonas un role, el nuevo contendrá los mismos privilegios que el role original. Asimismo, el role clonado no incluirá ningún usuario o grupos del original.
Otra de las mejores prácticas, en cuanto al uso de roles y usuarios se refiere, es la de no usar el usuario de Windows Administrator para gestionar la infraestructura vSphere. Es conveniente crear un usuario y asignar este usuario el role Administrator. Si el servidor donde instalamos vCenter es parte de un dominio de Windows, el grupo del directorio activo Domain Admins es incluido en el role Administrator en el objeto raíz Host & Clusters. Es también una mejor práctica instalar el servidor de vCenter en un servidor que se parte de un dominio para poder hacer así uso de los usuarios y grupos de este dominio. Entendiendo el significado del usuario vpxuser
Los usuarios del servidor ESXi, root y vpxuser, son asignados al role Administrator a nivel del servidor ESXi. El usuario vpxuser es una copia exacta del usuario root y el motivo de la existencia de este usuario es permitirte cambiar la contraseña de root desde el vSphere Client sin perder la conexión con el vCenter. El usuario vpxuser no tiene ningún derecho (login, shell). Es muy buena práctica no modificar las propiedades de este usuario ya que podríamos, involuntariamente, alterar el buen funcionamiento del servicio de logon en el host ESXi. Este usuario vpxuser se crea al añadir el servidor ESX/ESXi al inventario del vCenter. Aviso: Si modificas las propiedades de este usuario, que dicho sea de paso no es una mejor práctica, es muy probable que no puedas gestionar tu servidor ESXi desde el vCenter. Para poder corregir esta situación, sigue los siguientes pasos. 1. Desregistra y borra tu servidor ESXi del inventario de vCenter
2. Conéctate directamente con el vSphere Client a tu servidor ESXi 3. Borra el usuario vpxuser 4. Vuelve a conectar y añadir tu servidor ESXi al inventario de vCenter Configurando el Firewall en vSphere™ ESXi
En la versión ESXi, la red de gestión (Management Network) está protegida por un firewall orientado a servicios el cual puede ser configurado usando vSphere Client o vía comando desde la consola del Shell de ESXi (esxcli network firewal). Con el comando esxcli network firewal podrás abrir desde consola uno o varios puertos del firewall de tu servidor vSphere ESXi 5. ~ # esxcli network firewall Usage: esxcli network firewall {cmd} [cmd options] Available Namespaces: ruleset
Commands to list and update firewall ruleset configuration
Available Commands: get
Get the firewall status.
load
Load firewall module and rulesets configuration.
refresh
Load ruleset configuration for firewall.
set
Set firewall enabled status and default action.
unload
Allow unload firewall module.
~ # esxcli network firewall get Default Action: DROP Enabled: true Loaded: true ~# Aviso: El firewall del servidor vSphere™ ESXi ya no está basado en Linux IP Tables. En su lugar, se han definido reglas y puertos por cada servicio. De esta forma , ahora es posible especificar el IP o el rango de IPs que quieres permitir o denegar un servicio en concreto. La pestaña de services dentro de las propiedades del firewall, te permitirán ver el nombre y el estado del servicio, es decir, si esta arrancado o parado.
Puedes configurar un servidor para que arranque con el host, para que arranque manualmente o que arranque automáticamente si otros puertos están abiertos o cerrados. El firewall en ESXi está configurado, por defecto, con seguridad alta, bloqueando todo el tráfico de entrada y salida que no es necesario para el correcto funcionamiento de vSphere y sus plugins. Habilitando y deshabilitando el Lockdown mode en vSphere™ Lockdown mode deshabilita todos los accesos directos a los hosts ESXi. De esta forma solo será posible acceder a tu servidor ESXi desde el vSphere Client conectándose al vCenter. Por defecto, no existe ningún usuario local en los hosts ESXi con lo que si quieres crear un usuario local en tu servidor ESXi asegúrate de hacerlo antes de activar el Lockdown mode ya que después de estar activado no podrás crear usuarios locales. ¿Cómo podemos activar Lockdown Mode? 1. Desde la DCUI
2. Al añadir el host para ser gestionado por vCenter Server
3. Desde vCenter Server haciendo clic sobre host > Configuration > Security Profile
Integrando ESXi con el directorio activo Aunque las tareas diarias de administración y gestión de un entorno virtual con vSphere™ se realizan generalmente desde el vSphere Client conectándose directamente al vCenter, en ciertas ocasiones puede que sea necesario acceder directamente a los servidores ESXi. Por ejemplo, cuando queremos acceder directamente a los logs locales de un servidor ESXi o para hacer un backup local de dicho servidor.
En este caso, es una mejor práctica configurar tus servidores ESXi para que se unan a un dominio del directorio activo para que los usuarios que necesiten tener acceso local tengan que identificarse contra un directorio centralizado (AD). La ventaja de este modelo es que tú, como administrador, puedes seguir usando los usuarios o grupos de tu directorio activo o NIS para conceder acceso local a tus servidores ESXi. Este modelo es más seguro y fácil de implementar que el tener que crear cuentas independientes locales por cada uno de tus servidores ESXi. Por supuesto, una vez que integres tu servidor ESXi con tu directorio activo o servidor NIS, podrás seguir teniendo la posibilidad de crear usuarios o grupos locales a nivel de ESXi. Para añadir tu servidor ESXi a tu directorio activo selecciona la pestaña de Configuration > Authentication Services
Una vez dentro de este menú básicamente tienes que introducir los datos de tu domino (nombre, usuario y passowrd) y seleccionar Join Domain Aviso: ESXi 5 automáticamente concede acceso de administrador al grupo del directorio activo llamado “ESX Admins” lo cual permite la creación de otros grupos de administradores globales.
Capítulo 8. Gestión de recursos en vSphere™
Los Resource pools permiten asignar CPU y memoria dinámicamente. El clúster VMware DRS ofrece una herramienta extraordinaria para la gestión de recursos de una forma mucho más centralizada. El uso de resource pools, límites, reservas y shares es considerado por VMware una mejor práctica para garantizar el uso de los recursos que las máquinas virtuales requieren. Asimismo, es muy recomendable garantizar a cada usuario los permisos necesarios, y no más de los necesarios, para que puedan cumplir con su obligación, que no es otra que la administración del entorno virtual. ¿Qué es un Resource Pool con memoria reservada?
Un resource pool es una abstracción lógica (contenedor) el cual permite asignar recursos de CPU y memoria de forma más dinámica y eficiente. Por tanto, los recursos de un servidor ESXi o un clúster DRS pueden ser divididos y asignados más eficientemente. Los beneficios de un resource pool son los siguientes: 1. Facilidad de delegación y control de acceso. 2. Separación de los recursos del hardware.
Los resource pools pueden ser creados a nivel de servidor ESXi o clúster VMware DRS, pudiendo ser editados y modificados dinámicamente. El indicador amarillo durante el ajuste de los recursos en un resource pool, muestra la cantidad recomendada para ese recurso. El memory overhead de las máquinas virtuales también consume memoria en el resource pool y, por lo tanto, esta memoria es incluida en la reserva del resource pool. Aunque VMware recomienda el uso y las buenas prácticas dentro de los resource pool, no es aconsejable crear una jerarquía de más de tres resource pools. La profundidad máxima de esta jerarquía en los resource pools es de 8. Esto crearía un nivel de “burocracia” excesivo en cuanto al control de acceso se refiere. Aviso: El número máximo de resource pools por host es de 1.600 Cambiando los recursos desde el Resource Allocation
Puesto que todas las máquinas virtuales acceden directamente a los recursos físicos, estas no sabrán qué hacer cuando todas las máquinas virtuales estén accediendo a los mismos recursos, es decir, cuando haya contención en tu sistema. Por consiguiente, vSphere™ incluye un mecanismo para controlar que máquina virtual accede a que recursos y por cuanto tiempo y prioridad. Cuando la memoria o la CPU de un servidor ESXi está en overcommitted, es decir, las máquinas virtuales están configuradas con más memoria y ciclos de reloj de CPU de lo que dispone físicamente el servidor ESXi, necesitamos tener un mecanismo para garantizar los accesos. Es aquí donde entran los conceptos de Shares, Limits y Reservation.
Limit: Es el valor consumido de ciclos de reloj de CPU o memoria física del servidor ESXi del cual no es posible pasarse. Reservation: Este valor es definido en Mhz para CPU y MB para memoria RAM y representa un valor que debe estar disponible cuando la máquina virtual se enciende. Shares: Es un valor que especifica la prioridad relativa o la importancia de acceso de una máquina virtual a un recurso determinado. Los shares compiten entre el límite y la reserva. Por consiguiente, con estos tres parámetros podemos definir SLAs - de las siglas en inglés Sevice Level Agreement - para todas y cada una de nuestras máquinas virtuales. Los shares, limits y reservation también están disponibles a nivel de resource pool. Nota que cuando no hay contención entre máquinas virtuales, el cambio de la configuración de los shares no tiene ningún efecto. No obstante, cuando hay contención entre dos máquinas virtuales a nivel de CPU y defines unos shares más altos a una máquina virtual, estarás dando una prioridad más alta a esta máquina virtual sobre la otra. Es posible cambiar el valor de los shares de CPU y la reserva de memoria desde la pestaña Resource Allocation a nivel de Cluster o a nivel de host ESXi cuando este no está configurado en un clúster. Asimismo, también es posible modificar en "caliente" la reserva de CPU y el tipo de reserva, Fixed o Expandible. Cuando una máquina virtual, con la configuración en shares de memoria en custom, es añadida a un resource pool, es posible que recibas un warning que indica que la máquina virtual obtendrá un porcentaje muy alto del total de los shares para la memoria. Cambia la configuración de los shares de custom a high, medium o low para evitar este warning. Cuando añades un servidor vSphere™ ESXi a un clúster y la opción de DRS no está habilitada, los resource pools que estaban en el servidor vSphere ESX/ESXi son eliminados. Asimismo, si creas un clúster sin la opción de DRS, no podrás crear resource pools a nivel de clúster. Cambio dinámico de los Resource Pools Es posible incluir más de una máquina virtual en un mismo resource pool. En este caso, todas las máquinas virtuales del resource pool competirán por los mismos recursos físicos especificados en el resource pool. En el caso de que el resource pool no haya sido configurado con la opción Explandable Reservation, el rendimiento de las máquinas virtuales puede llegar a verse afectado.
Para incrementar el rendimiento de alguna máquina crítica que este dentro de dicho resource pool, puedes aumentar el límite de CPU del mismo. Los resource pools que están en un mismo nivel son llamados Sibling Pools. ¿Qué tamaño deberían tener mis LUNs de almacenamiento?
VMware tiene dos métodos bien diferenciados a la hora de configurar el tamaño correcto para las LUNs de almacenamiento. El método predictivo o el método adaptivo. El método adaptivo utiliza menos LUNs pero LUNs más grandes mientras que el método predictivo, utiliza varias LUNs con diferentes tipos de RAID para adaptarse mejor a las características de E/S de las diferentes aplicaciones. Una buena práctica a la hora de configurar las LUNs, es crear LUNs de unos 800GB de tamaño y añadir entre 15-20 máquinas virtuales comprobando el rendimiento. Pero puede ser que cuando vas a añadir la máquina virtual número 5 se crea un cuello de botella a nivel de LUN. Por eso es muy importante que antes de añadir una nueva máquina virtual a una LUN, monitorices a nivel de E/S el delay de dicha LUN. Si el rendimiento aun es óptimo, mete otra máquina virtual y vuelve a monitorizar el rendimiento. Si el rendimiento sigue siendo bueno, sigue metiendo más máquinas virtuales. Cuando detectes que el rendimiento no es bueno, y antes de que se genere un cuello de botella en tu LUN, crea otro datastore y empieza a meter nuevas máquinas virtuales en tu nueva LUN y vuelve a empezar con el proceso descrito.
Capítulo 9. Monitorización de recursos en vSphere™
VMware VMkernel trabaja proactivamente para evitar contención en los recursos físicos del servidor ESX/ESXi. No obstante, para maximizar el rendimiento, es necesario analizar y monitorizar constantemente nuestra infraestructura vSphere. El proceso de escrituras desde las máquinas virtuales al disco compartido
Cuando una máquina virtual quiere hacer una operación de E/S al disco FC compartido de la cabina de almacenamiento, el VMkernel ejecuta las siguientes tareas: 1 - El archivo correspondiente a la máquina virtual es localizado en el DataStore VMFS. 2 - La solicitud de los bloques en el disco virtual es asignada a los bloques en el disco físico apropiado.
3 -La solicitud modificada de E/S es enviada desde el driver del controlador de disco duro de la máquina virtual a la tarjeta física HBA. Es impórtate entender este proceso para poder monitorizar bien todos los elementos o capas involucradas durante una operación de escritura. El uso de iniciadores hardware iSCSI descarga al VMkernel de dos tareas principales: 1. La encapsulación de PDU (Protocolo Data Unit ) iSCSI en paquetes TCP/IP 2. La encapsulación de solicitudes I/O de disco en iSCSI PDU. Cuando usas el software de multipathing con el iniciador software iSCSI, debes conectar – port binding - el iniciador software iSCSI con el VMkernel port vía comando (esxcli) o ahora también lo puedes hacer desde la GUI en la versión ESXi. Configurando el tamaño correcto de la memoria en las MVs
El valor máximo recomendado de memoria que se muestra cuando se está configurando una máquina virtual representa el umbral por encima del cual la memoria física del host es insuficiente para ejecutar la máquina virtual con un rendimiento óptimo. El tamaño de la partición swap de la máquina virtual (.vswp) será igual al tamaño de la memoria física seleccionada cuando se configura la máquina virtual. En nuestro caso, el tamaño de nuestro fichero swap sería de 1GB, al asignarle 1GB de memoria RAM a la máquina virtual durante su creación. Esta regla es
diferente cuando se asignan reservas a las máquinas virtuales. Por ejemplo, si creas una máquina virtual con un 1GB de memoria RAM y creas una reserva de 350MB, el tamaño del fichero swap será de 1GB menos 350MB, es decir, 650MB. VMware VMkernel detecta las páginas de memoria que son idénticas en todas las máquinas virtuales y asigna estas páginas a la misma dirección de memoria física, con el consiguiente ahorro potencial de memoria física. Esta técnica es denominada Transparent Memory Page Sharing (TMPS). VMware VMkernel trata las páginas de memoria compartidas como páginas de memoria COW (Copy on write), lo que significa que son páginas de solo lectura cuando son compartidas y páginas privadas cuando una de las máquinas virtuales hace algún cambio. TMPS está siempre activada, a menos que se deshabilite manualmente modificando el fichero de configuración de la máquina virtual (.vmx). Asimismo, Transparent Memory Page Sharing es la técnica de conservación de memoria con un impacto menor que otras técnicas, como pueden ser el ballooning o swaping, por cuanto permite eliminar páginas de memoria duplicadas ubicadas en diferentes máquinas virtuales. No confundas TMPS con el Memory Balloon Driver, el cual permite reubicar memoria no usada de una máquina virtual a otra. Las técnicas de conservación de memoria con Transparent Memory Page Sharing y RAM Overcommit, permiten asegurarse la eliminación de copias de páginas de memoria redundadas entre máquinas virtuales. Una de las nuevas funcionalidades en la versión ESXi 5, en cuanto a la optimización de memoria se refiere, es el llamado Memory Compression.
Esta técnica es también transparente al sistema operativo guest y mucho más rápido, comparado con el proceso de paging a nivel de máquina virtual. Con Memory Compression cada página de memoria considerada para ser paginada a disco, es comprimida y almacenada en una cache de compresión a nivel de máquina virtual. En el ejemplo del diagrama anterior, la página de memoria A y B son comprimidas de 4K a 2K en la cache de la máquina virtual. vSphere y la funcionalidad VMDirectPath I/O
En vSphere ESXi 5 es posible dedicar en exclusiva una tarjeta HBA, de red o incluso un disco USB conectado directamente en el servidor ESXi a una máquina virtual Para configurar VMDirectPath debes seleccionar la pestaña de Configuration > Advanced Settings Un icono verde indica que el dispositivo está habilitado y activo. Un icono naranja indica que el estado del dispositivo ha cambiado y el servidor host debe ser reiniciado antes de que el dispositivo pueda ser utilizado por la máquina virtual. Una vez asignado el hardware a la máquina virtual, este no podrá ser gestionado por el servidor ESXi. La versión anterior ESX/ESXi 4.1 ya soportaba dispositivos USB en modo passthrought. Para más información sobre la configuración de USB en modo passthrought revisa el KB1022290. Puedes conectar hasta dos dispositivos passthrought a una máquina virtual y solo pueden ser tarjetas de red o tarjetas HBAs de fibra para la conexión a la SAN.
Detectando cuellos de botella en el componente disco
Una máquina virtual puede tener un cuello de botella a nivel de E/S de disco si el contador SCSI queue length es alto. Puedes ver en uno de nuestros videos tutoriales de formación gratuitos los dos contadores importantes a monitorizar para ver si hay un cuello de botella a nivel de disco. También aprenderás a ver como se monitorizan estos contadores: http://www.josemariagonzalez.es/curso-online-gratuito Una aplicación en una máquina virtual puede experimentar un rendimiento pobre, aunque la máquina virtual tenga memoria disponible, ya que puede no tener memoria física disponible. El número máximo de vCPUs con el que puedes configurar una máquina virtual es ahora de 32. Para mejorar el rendimiento de una máquina virtual ejecuta los siguientes pasos: 1. Deshabilita dispositivos no usados como puertos COM, floppies o CD-ROM. 2. Optimiza la máquina virtual como si fuera una máquina física. 3. Pon máquinas virtuales con requerimientos similares en el mismo servidor vSphere ESX/ESXi.
Detectando cuellos de botella en el componente vCPU
VMware recomienda mirar el indicador CPU Ready para determinar si la máquina virtual tiene un cuello de botella en el componente CPU. Si el contador de uso de la CPU está al 100% y el contador de CPU Ready está entre un 5-10% durante un periodo largo de tiempo, es muy probable que la máquina virtual tenga un cuello de botella a nivel de CPU. Un incremento en el número de shares de CPU es muy posible que beneficie a una máquina virtual que esté saturada en cuando a CPU. Puedes ver un video tutorial en nuestro curso online gratuito dedicado en exclusiva a la virtualización de sistemas, sobre como monitorizar la capa de CPU en tu entorno virtual para saber si hay un cuello de botella a nivel de CPU: http://www.josemariagonzalez.es/curso-online-gratuito Aviso: Para mejorar el rendimiento de la máquina virtual, o bien creas una afinidad de CPU en la máquina virtual para que esta se ejecute solo en una CPU física, lo cual no es una mejor practica porque entre otras cosas pierdes vMotion o haces una reserva de la CPU física en exclusiva para la máquina virtual en cuestión.
Monitorizando Thin Provisioning con alarmas
Haz clic con el botón derecho sobre la LUN que quieres monitorizar y selecciona Add Alarm. Crea una alarma para el DataStore que quieres monitorizar, selecciona el contador "DataStore Disk Overallocation" y determina el porcentaje apropiado. Después, desde la pestaña de Actions, crea una acción que envíe una notificación vía email al administrador. Aviso: Puedes convertir un disco de máquina virtual de thin a thick con la opción inflate con la máquina virtual apagada. Asimismo, también puedes convertir un disco de thin a thick cuando haces una migración con Storage vMotion y seleccionas cambiar el tipo de disco a Thick. El uso del New Task Wizard en vSphere
Con el nuevo New Task Wizard ahora es posible crear y programar las siguientes tareas: Create a snapshot of a virtual machine, Enter a host in Maintanance Mode, Create a virtual machine template, Migrate a virtual machine with vMotion, etc. Para automatizar estas alarmas, selecciona Home, Management, Scheduled tasks y haz clic en New. Por defecto, vCenter crea 55 alarmas pre-definidas sobre el objeto inventario raíz. Estas alarmas son de solo lectura, excepto cuando editas las alarmas desde el objeto inventario donde fueron definidas. En ese caso podrás modificar las alarmas pre creadas. Configurando vCenter Server para enviar notificaciones por email
Dentro del servidor de vCenter, selecciona Administration en la barra del menú de opciones y elige vCenter Server Settings. Después selecciona la opción Mail. Escribe la dirección IP de tu servidor SMTP centralizado. Debes de configurar tanto el servidor de SMTP como la dirección email desde donde se van a mandar los correos. Asimismo, tu servidor vCenter tiene que tener instalado un agente relay de SMTP para poder mandar las notificaciones vía email. Aviso: Para configurar las notificaciones SMTP, el cliente vSphere debe estar conectado al servidor vCenter.
Capítulo 10. Funcionalidades Enterprise en vSphere™
En este módulo te explicare los servidos Enterprise más importantes de VMware para todo aquel administrador que quiera dotar a su infraestructura virtual de la protección necesaria contra la pérdida de datos (Data Recovery), protegerse contra la caída de los sistemas ESXi (VMware HA), y en definitiva configurar el centro de datos flexible y dinámico del futuro (VMware DRS y VMware DPM). ¿Cómo mover las máquinas virtuales de host con vMotion o de disco con Storage vMotion?
Con vSphere no solo es posible migrar las máquinas virtuales de servidor ESXi con la funcionalidad de vMotion, sino que también es posible mover sus discos virtuales asociados de datastore. Para migrar una máquina virtual, selecciona esta desde el inventario con el botón derecho del rato y selecciona Migrate La imagen anterior muestra el wizard de migraciones de máquinas virtuales. Cuando selecciona la opción Change host estas usando vMotion y cuando selecciones Change datastore lo que estas usando es Storage vMotion. También es posible hacer un vMotion y un Storage vMotion a la vez pero la máquina virtual tendrá que estar apagada.
La idea de usar Storage vMotion es para mover máquinas virtuales entre diferentes DataStores NFS, iSCSI y FC. Uno de los beneficios más grandes de Storage vMotion es el hecho de poder mover un disco virtual de una máquina virtual de un DataStore a otro con menos latencia y comprobar el rendimiento de la máquina virtual en el nuevo DataStore. También es posible migrar una máquina virtual con Storage vMotion con los discos suspendidos. Storage VMotion no puede usarse en máquinas virtuales con NPIV activado. Los discos Raw Device Mapping en compatibilidad física están soportados por vMotion y VMware HA. Asimismo, vMotion está soportado en una máquina virtual con la opción NPIV (N-Port ID Virtualization) habilitada, pero no cuando esta máquina virtual tiene múltiples discos virtuales en diferentes DataStores. NPIV no está soportado en máquina virtual con Fault Tolerance habilitado, otro de los servicios Enterprise que cubriremos más adelante en este libro. Una migración con vMotion no incurre en ningún downtime para la máquina virtual. Recuerda que vMotion es requerido en un clúster DRS/HA. Es posible que los hosts ESXi involucrados en una migración en caliente con vMotion no sean compatibles. Cuando veas una cruz roja, desde la pestaña Maps, en un servidor vSphere ESX/ESXi de un clúster DRS/HA, significará que este servidor no es compatible con VMotion. En cuanto a los requerimientos de vMotion, una máquina virtual no puede ser migrada cuando: 1. La MV tiene una conexión activa a un virtual switch de uso interno.
La MV tiene una conexión activa a un CD o disquete.
La MV tiene configurada afinidad a una CPU.
La MV forma parte de un clúster Microsoft.
El wizard de vMotion produce un aviso cuando:
La MV tiene una conexión a un virtual switch de uso interno pero no está conectado.
La MV tiene una conexión a un CD o disquete pero no está conectado.
La MV tiene uno o más snapshots.
El servidor ESXi no ha recibido un guest OS heartbeat (probablemente las VMware tools no han sido instaladas, configuradas adecuadamente, o el servido de VMware tools está parado).
Recuerda que si recibes un mensaje de error, la máquina virtual no podrá ser migrada. Sin embargo, con un mensaje tipo warning, puede ser migrada con vMotion sin problemas.
Por último, recuerda que los servidores ESXi involucrados en la migración deben tener:
Visibilidad de todas las LUNs (FC, iSCSI o NAS) usadas por la MV.
Una red Gigabyte Ethernet dedicada al tráfico vMotion.
Acceso a la misma red Ethernet física.
CPUs compatibles o similares (misma familia CPU). vMotion también funciona si el servidor origen tiene Hyperthreading activado pero no el servidor destino.
A diferencia de VMware ESX 3.x, el nombre de los switches virtuales configurados para transferir el tráfico generado por vMotion, no tiene por qué ser configurados con el mismo nombre. Aviso: El número máximo de migraciones simultaneas con Storage vMotion en VMware vSphere™ ESXi es de 8 por datastore. Asimismo, no podrás migrar una máquina virtual con Storage vMotion si esta máquina virtual tiene snapshots activos y el disco virtual de dicha máquina virtual ha sido configurado como independent non-presistent. También es posible usar la funcionalidad de Storage vMotion para asegurarte que una vez hayas renombrado tus máquinas virtuales, este nombre también será actualizado a nivel de datastore.
El número máximo de migraciones concurrentes con Storage vMotion por host es de 2. vSphere Data Recovery
vSphere Data Recovery está incluido en la versión vSphere Essentials Plus. Es una herramienta para hacer backups y restores a disco de tus máquinas virtuales el cual se integra con vCenter Server. Es por lo que necesitas la existencia de vCenter Server para poder usar e instalar este appliance de VMware. vSphere Data Recovery utiliza el API VSS(Microsoft Volume Shadow Copy Services) para los backups en Windows Vista 32bit, Windows Server 2003 32bit y Windows Server 2008 32bit. Windows XP no está soportado en Data Recovery. vSphere Data Recovery también soporta servidores ESX 3.5.x. No obstante, el backup de máquinas virtuales hospedadas en servidores ESX 3.5 suelen tardar más que en vSphere ESX 4.x. y ESXi 5. El motivo es que ESX 3.5 no soporta la nueva funcionalidad en vSphere llamada changed-block tracking. Para instalar vSphere Data Recovery has de bajarte el appliance desde la web de VMware, instalarlo en un Servidor ESXi gestionado por vCenter e instalar el plugin cliente en el vSphere Client. El número de tareas máximo de backup o restore que Data Recovery soporta es de 8 tareas simultáneas.
vSphere Data Recovery soporta nuevas funcionalidades como backup a disco y deduplicación por consiguiente hay que asignar un disco al appliance de Data Recovery para hacer los backups. Este disco puede llegar a tener un tamaño de hasta 1TB para discos de FC y de 500GB para discos compartidos via CIFS. El motivo es que si usas tamaños más grandes, según VMware, el rendimiento disminuye considerablemente. Opciones de Clustering para las máquinas virtuales
Es posible clasterizar las aplicaciones dentro de las máquinas virtuales con software de clustering de terceros. El único software de clustering para las máquinas virtuales soportado en vSphere es el software de clustering de Microsoft Windows. Asimismo, existen tres opciones a la hora de clusterizar tus máquinas virtuales con el software de clustering de Microsoft. La primera opción es clúster in-a-box, el cual te permite protegerte contra fallos de usuario, aplicación y sistema operativo. Aviso: Recuerda que el Bus Sharing para el disco SCSI 0 (c:) es = None y el Bus Sharing para el disco SCSI 1 (quorum) es = Virtual. Los discos RDM solo están soportados en modo virtual. La segunda opción es clúster entre hosts ESXi, el cual te protege contra fallos de usuario, aplicaciones, sistemas operativos y hardware. Aviso: Recuerda que en esta configuración el Bus Sharing para el disco SCSI 0 es = None y el Bus Sharing para el disco SCSI 1 es = Físico. Los discos RDM están soportados tanto en modo virtual o físico.
La tercera opción es clúster entre máquina física ESXi y máquina virtual, la cual te permite una solución de redundancia N+1 de bajo coste. En esta configuración es posible que el failover del clúster falle si usas el driver STORport Miniport. Aviso: Recuerda que en esta configuración el Bus Sharing para el disco SCSI 0 es = None y el Bus Sharing para el disco SCSI 1 es = Físico. En esta configuración, los discos RDM solo están soportados en modo físico. Si usas Windows Server 2003 en un clúster Microsoft MSCS asegúrate que la tarjeta virtual en las máquinas virtuales es de tipo "Flexible". Si usas Windows Server 2008 en un clúster Microsoft MSCS asegúrate que el adaptador virtual SCSI en las máquinas virtuales es un "LSI Logic SAS" Cuando creas un clúster Microsoft MSCS entre dos servidores ESXi 5, el disco de la máquina virtual donde residirá el disco quorum del clúster, debe ser un disco RDM en compatibilidad físico o virtual. Personalmente, no veo la necesidad de clusterizar las máquinas virtuales con un software de terceros, en este caso de Microsoft, ya que los servicios de alta disponibilidad en VMware, como HA y FT, nos ofrecen un RTO - de las siglas en ingles Recovery Time Objective – muy bueno y con una configuración mucho más simple y flexible. No obstante, si tu aplicación requiere un RTO de menos de 5 minutos y requiere una configuración de más de una vCPU, no tendrás otra alternativa que clusterizar estas máquinas virtuales con el software de clustering de Microsoft para ofreces ese RTO. VMware Fault Tolerance (FT)
VMware FT es otro de los servicios Enterprise en VMware. A diferencia de VMware HA, donde la máquina virtual tiene un downtime mínimo, una máquina virtual protegida con FT tiene un downtime de cero (menos 14 milisegundos en una red de 1Gb). Solo hardware de última generación soporta la funcionalidad Fault Tolerance en VMware. Asegúrate de verificar con tu proveedor de hardware que este tiene soporte para FT. VMware Fault Tolerance usa la tecnología de VMware vLockstep y no soporta discos thin en las máquinas virtuales. Cuando activas Fault Tolerance en una máquina virtual, esta no puede tener más de una CPU virtual (VMware SMP). VMware Fault Tolerant y las políticas de no-afinidad y afinidad del clúster DRS
Gracias a las políticas de no-afinidad en un clúster DRS, una o más máquinas virtuales nunca podrán estar localizadas en un mismo servidor ESXi. También es posible crear políticas de afinidad, es decir, que una o más máquinas virtuales siempre residan en un mismo servidor ESXi. Un ejemplo típico de una policía de no-afinidad sería el caso de dos controladores de domino. Como veremos más adelante, cuando activamos VMware DRS, este migrara automáticamente las máquinas virtuales de host ESXi para balancear la carga. Yo le llamo el vMotion con celebro. Pero NO queremos tener una situación en donde los dos controladores de dominio se migran automáticamente a un servidor ESXi y que esta falla.
Si claro, VMware HA levantara las dos máquinas virtuales automáticamente si lo tienes configurado - pero estarás unos minutos sin ningún controlador de dominio, y no querrás que esto pase, ¿verdad? Aviso: No obstante, dada una máquina virtual en modo VMware Fault Tolerant, puede suceder que tanto la copia primaria como la copia secundaria residan en el mismo host ESX/ESXi. Este caso solo puede darse cuando la máquina virtual en modo Fault Tolerant está apagada. Para poder activar FT es necesario previamente tener HA configurado. Fault Tolerance y el panel Summary
Desde el panel Summary, puedes ver el estado de la funcionalidad Fault Tolerance, active o Not Protected. Para verificar si una máquina virtual está protegida con Fault Tolerance, selecciona la máquina virtual y la pestaña Summary. Si la máquina virtual reporta el estado "Not Protected" es un indicativo de que la funcionalidad de Fault Tolerance está deshabilitada o que la copia primaria está funcionando sin una copia secundaria, con lo que estarías en un escenario de máquina virtual no protegida. Cuando a la máquina virtual con la opción FT (Fault Tolerance) habilitada y dentro de un clúster DRS/HA, se le habilita la opción Host Monitoring y la primera copia de la máquina falla, una segunda copia (mirror) de dicha máquina virtual no será creada. Por lo tanto, dicha máquina virtual no tendrá una configuración redundante. Una de las formas más sencillas de probar si FT está funcionando en tu entorno es hacer que falle la máquina virtual primaria para ver si la secundaria toma el testigo.
El número máximo de discos virtuales que una máquina virtual puede tener cuando se protege con Fault Tolerance es de 16 virtual disk. Asimismo, no es posible proteger más de 4 máquinas virtuales con FT por servidor ESXi. Otra de las limitaciones en VMware FT es el hecho de que no podrás asignar más de 64GB de memoria RAM a una máquina virtual protegida con FT. VMware High Availability Services (HA)
El servicio de VMware HA en vSphere™ ESXi 5 ha sido completamente rediseñado. Ahora, los nodos en el clúster o son Master o Slave, a diferencia de versiones anteriores donde había nodos primarios y secundarios. VMware HA puede reiniciar automáticamente las máquinas virtuales de un servidor ESX/ESXi que haya fallado debido a un problema de hardware del servidor. No obstante, es posible que una máquina virtual no se reinicie en otro servidor ESX/ESXi del clúster HA en el caso de que haya sido configurada con una prioridad baja (low priority) o que el admission control haya sido configurado. Recuerda que debe haber suficientes recursos en el clúster HA, basados en la reserva de CPU y memoria, para poder reiniciar las máquinas virtuales. Si al arrancar una máquina virtual en clúster VMware HA recibes el error "insufficient resources exist for HA", no tienes suficientes recursos físicos para arrancar más máquinas virtuales. Para poder resolver este problema, puedes cambiar la configuración de VMware HA y seleccionar la opción "Allow virtual machines to be powered on even if they violate HA availability constraints" o añadir otro servidor ESX/ESXi al clúster. Desactivar el control de admisión en VMware HA no es una mejor práctica.
Un clúster VMware HA puede llegar a tener la máxima configuración siguiente:
El número máximo de servidores ESXi permitidos por un clúster VMware HA es de 32 nodos.
El número máximo de máquinas virtuales por host que puedes proteger con HA es de 512, con independencia del número de host que tengas configurados en el clúster HA.
El número máximo de máquinas virtuales por clúster que puedes proteger con HA es de 3.000
Activando vSphere VMware HA/DRS
Antes de configurar VMware HA, verifica que todas las máquinas virtuales pueden ejecutarse en los nodos que vayan a formar el clúster. Recuerda que el acceso a recursos comunes como LUNs y redes virtuales es vital para que VMware HA funcione correctamente. Para crear un clúster con la opción de HA, selecciona el objeto de inventario datacenter con el botón derecho del ratón y selecciona create new clúster. En la imagen anterior se muestra el wizard de creación de un clúster. Para activa la parte de HA del clúster solo tienes que marcar la opción Turn on VMware HA. Es una muy buena práctica tener HA y DRS activados juntos. DRS se activa de la misma forma que activamos VMware HA. VMware HA solo reiniciará las máquinas virtuales en otro servidor vSphere ESXi cuando uno de los servidores del clúster se aísla de la red o un host falla. Recuerda que para que VMware HA funcione perfectamente, todos los servidores vSphere ESX/ESXi en el clúster deben tener acceso a los DataStores compartidos por todos los servidores ESX/ESXi. Asegúrate que tu servidor DNS funciona perfectamente y que puedes hacer ping por nombre corto, FQDN, alias y dirección IP desde todos los servidores ESX/ESXi y desde el vCenter, así como al default gateway. VMware HA instala un agente en cada servidor ESXi el cual monitoriza el host ESXi así como las VMware tools en todas y cada una de las máquinas virtuales registradas. Asimismo, y opcionalmente, este agente también puede ser configurado para monitorizar los heartbeats de las aplicaciones que están corriendo en las máquinas virtuales. Cuando un servidor vSphere ESXi es puesto en modo mantenimiento en un clúster HA/DRS, las máquinas virtuales se migrarán automáticamente a otros servidores vSphere ESXi, siempre que el clúster esté configurado en fully automated. Si el clúster está configurado en partially automated, el administrador de vCenter deberá mover las máquinas virtuales manualmente. Recuerda los tres niveles de automatización para un clúster DRS: Manual, Partially Automated y Fully automated.
Los niveles de automatización en VMware DRS se definen en base a dos valores: dónde se va a arrancar la máquina virtual cuando esté apagada, y dónde se va a mover (vMotion) la máquina virtual cuando esté encendida (balanceo dinámico o DRS). En un clúster DRS, con la configuración fully automated, si deseas que una máquina virtual no se migre a otro servidor vSphere ESX/ESXi, has de cambiar las opciones de la máquina virtual a Partially Automated. La diferencia entre partially automated y fully automated en un clúster DRS es que un clúster con la opción fully automated migra las máquinas virtuales para optimizar el uso de los recursos. En la sección, Virtual Machine Options, puedes cambiar el nivel de automatización por máquina virtual. La diferencia entre default (Partially Automated) y Disable, es que con Disabled el clúster DRS no genera ninguna recomendación para esa máquina virtual en particular. Por consiguiente, esta máquina virtual nunca sería migrada automáticamente con VMware DRS (vMotion). Aviso: En una configuración DRS con solo dos servidores ESXi, es posible que un servidor ESXi esté usando el 100% de los recursos (memoria y CPU) mientras que el otro servidor esté mucho más libre. Este es un caso típico de que no existen recursos suficientes para ejecutar una migración en caliente con vMotion o que las CPUs de los host en el clúster son incompatibles con vMotion.
Cambiando el orden de prioridad en el arranque de mis máquinas virtuales en VMware HA
Edita los Settings de VMware HA y selecciona Virtual Machine Options. En mi ejemplo, para la máquina virtual llamada DC1, he cambiado VM Restart Priority a High. Esto significa que la máquina virtual DC1 arrancará antes que la máquina Windows (VM Restart Priority Medium). Aviso: Recuerda que los settings a nivel de máquina virtual sobrescriben los settings definidos a nivel de clúster. Cuando estableces VM Restart Priority a Disabled, como en la máquina virtual llamada W2k mi ejemplo, le estás indicando al clúster VMware HA que, en caso de fallo hardware en uno de los nodos, no reinicie dicha máquina virtual. Recuerda las 4 opciones disponibles en la opción VM Restart Priority en VMware HA: Disabled, low, Medium y High
Configurando la parte de red en VMware HA
Es recomendable tener dos tarjetas de red para el control del latido del clúster (heartbeat). Asimismo, los uplinks vmnic0 y vmnic1 en mi ejemplo, deberían estar conectados a switches físicos diferentes para estar protegidos también contra fallos en la capa de red física.
La forma en la que vSphere VMware HA calcula el "failover capacity", cuando se activa HA con la primera política de control de admisión (host failures clúster tolerates), es usando el valor más alto de las reservas de memoria y CPU de las máquinas virtuales de un clúster. Recuerda que debe haber
recursos suficientes en el clúster (memoria y CPU) para poder acometer un failover. Un clúster VMware DRS/HA mostrará un estado rojo si el número del contador "failover capacity" es menor que el número "configured capacity".
Aviso: Recuerda que el valor por defecto de Isolation Response es de leave power on, es decir, en caso de aislamiento de uno de los nodos del clúster (perdida del heartbeat), las máquinas virtuales se dejaran encendidas. Restart Priority e Isolation Response son configuraciones a nivel de clúster. Esta configuración puede ser modificada también a nivel de máquina virtual.
Si una máquina virtual en un clúster DRS está teniendo problemas de rendimiento, deberás incrementar los shares de CPU de dicha MV a High o incrementar sus reservas de CPU. Distributed Power Management (DPM)
Distributed Power Management es otro de los servicios Enterprise que se puede activar cuando creamos un clúster HA/DRS. La idea de DPM es tener el centro de datos del futuro en el cual los servidores ESXi se apagan cuando no se necesitan y se enciende cuando se les necesitan. Puedes ver un video tutorial de DPM en acción en nuestro blog de virtualización y cloud computing en español en la siguiente dirección web: http://www.josemariagonzalez.es DPM usa Wake-on-LAN (WOL), IPMI (Intelligent Platform Management Interface) o las tarjetas de gestión remota iLO de HP para poner el host ESX/ESXi en modo standby y volver a encenderlo cuando el clúster DRS lo necesite. DPM está deshabilitado por defecto cuando se crea un clúster DRS.Si lo activas, asegúrate de que las tarjetas de red dedicadas a vMotion soporten WOL pues es por esta red por donde se envían los paquetes “mágicos” de para poner un host en modo standby o para sacarlo de ese modo cuando sea necesario. Quizás DPM tenga más sentido en entornos grandes pues es donde más dinero en energía y refrigeración puedes ahorrar.
No obstante, en clientes pequeños (4 servidores ESXi) donde hemos configurado DPM, estamos ahorrando alrededor u unos 1.200 euros al año, lo suficiente para comprarte otra licencia de VMware Essentiasl! Verificando la configuración del host con Host Profiles
La opción de Host Profiles es otra de las funcionalidades Enterprise que todo centro de datos virtualizado de cierta envergadura debería tener configurado por la cantidad de trabajo que este puede ahorrar al administrador. Básicamente con host profile podemos capturar la configuración de un host ESXi 5 específico y duplicar dicha configuración a otro host o clúster con el consiguiente ahorro en la fase de post-configuración de todos tus servidores ESXi. La funcionalidad de host profile también te permite comprobar que la configuración de los host ESXi 5, en tu centro de datos, siguen las mejores prácticas y están configuradas acorde con el baseline del administrador. Host Profiles es el método recomendado por VMware para configurar servidores ESXi cuando han sido instalados con VMware Auto Deploy. Para poder aplicar una configuración con host profile a un servidor ESXi este tiene que ser puesto primero en modo mantenimiento (maintenance mode) Cuando un servidor ESXi 5 es puesto en modo maintenance mode, ninguna máquina virtual puede ser encendida en ese servidor o migrada al mismo con DRS o manualmente con vMotion.
Aviso: La ejecución de Host profile puede fallar cuando el host no ha sido puesto en modo mantenimiento o es un servidor ESX 3.x ya que la funcionalidad de host profile solo está disponible a partir de las versiones ESX/ESXi 3.5 VMware vCenter Site Recovery Manager
Vmware vCenter Site Recovey Manager (SRM) te permite configurar un plan de contingencias para que, en el caso que el centro de datos primario (Site A) fallase, puedas levantar los servicios en un emplazamiento remoto (Site B). VMware vCenter Site Recovery Manager requiere tener licencias válidas para los servidores VMware ESX/ESXi y una licencia en cada site para VMware vCenter Server. La idea de SRM es protegerte contra caídas de sites mediante la creación de planes de contingencias ante fallos completos del centro de datos. El área de BC/DR - de las siglas en ingles Business Continuity/Desaster Recovery - es bastante amplio como para cubrirlo en este libro. Es por lo que la configuración, instalación y gestión de SRM la tenemos documentada en otro libro totalmente separado. Puedes recibir una copia gratuitamente de la versión ebook del libro: Administrado Site Recovery Manager 4.0 en español al registrarte en nuestro blog de virtualización y cloud computing en español en la siguiente dirección: http://www.josemariagonzalez.es/2009/10/19/vmware-siterecovery-manager-10-en-espanol-capitulo-10-la-recuperacin-del-sitesin-vmware-srm.html
VMware Update Manager (VUM)
Con vCenter Update Manager, en combinación con VMware DRS, es posible actualizar el hardware virtual de las máquinas virtuales, las VMware tools, parchear las appliances y actualizar los servidores ESXi de una forma automatizada (VMware Orchestator), flexible y sin ningún downtime. VUM visto desde el servidor de vCenter
Para instalar VUM, debes de instalar la parte servidor en el mismo servidor donde tienes ya instalado vCenter Server (para entornos pequeños) o en otro servidor independiente al vCenter (entornos grandes). El binario está en el mismo DVD que el vCenter Server.
Una vez que lo hayas instalados, podrás actualizar los siguientes objetos: ESXi, Virtual Appliances, VMware Tools y hardware virtual.
En vSphere 5 ya no es posible actualizar máquinas virtuales pues VMware ha decidido retirar esta posibilidad. Posiblemente, el motivo haya sido el poco uso de los clientes. Los niveles de severidad válidos en vCenter Update Manager para los servidores hosts ESXi son: Critical, Security y General. vCenter Update Manager incluye las siguientes baselines para las máquinas virtuales : VMware Tools Upgrade to Match Host, VM hardware Upgrade to Match Host y VA Upgrade to Laster. Y para los servidores ESXi son: Critical Host Patches y Non-Critical Host Patches
Recuerda que no importa el número de servidores vSphere ESXi que tengas en un clúster, solo podrás actualizar uno cada vez con vCenter Update Manager. Aviso: El número máximo de máquinas virtuales que VMware Update Manager (VUM) puede escanear por instancia de vCenter Server es de 10.000. Asimismo, el número máximo de VMware Tools que puedes actualizar por servidor VUM es de 75 así como virtual machine hardware scans por servidor de VUM. Algo impórtate a destacar, es quizás el hecho de que no es posible actualizar las VMware tools por servidor ESXi, sin usar el servidor VUM, de más de 24 máquinas virtuales a la vez. Recuerda que no podrás actualizar con VUM el hardware virtual de tus máquinas virtuales en servidores legacy, es decir, de servidores hosts que no sean ESXi 5. Por último, los puertos que VMware Update Manager usa son: 8084, 9084, 9087. VMware vSphere™ Storage DRS
Probablemente una de las nuevas funcionalidades de la nueva versión vSphere™ 5 que más interés ha despertado en los usuarios, administradores y público en general es VMware Storage DRS.
Si ya conoces el concepto y la funcionalidad de Storage vMotion, entender esta nueva característica te resultara muy sencillo. Básicamente, Storage DRS te permite automáticamente seleccionar la LUN más adecuada para el funcionamiento de tus máquinas virtuales. Este avanzado mecanismo de balanceo a nivel de LUNs, también permite evitar cuellos de botella y problemas derivados por la falta de espacio en disco. Antes, y sin Storage DRS, manualmente tenías que seleccionar el datastore que pensabas tenía una latencia menor para albergar tus máquinas virtuales. Asimismo, tenías que, manualmente, seleccionar el datasotre correcto para que tus máquinas virtuales no tuvieran ningún tipo de conflicto en cuando al almacenamiento se refiere. Ahora, y con Storage DRS, automáticamente el sistema arrancara tus máquinas virtuales en aquellas LUNs con más espacio y menos latencia en cuanto a E/S.
Antes de activar SDRS (Storage DRS) has de crear un grupo de datastores llamado datastore clúster. Un datasotre clúster con SDRS activado balanceará los discos de tus máquinas virtuales (.vmdk) de la misma forma que un clúster DRS balancea las máquinas virtuales con vMotion. Para crear un datastore clúster, selecciona el objeto de inventario de tu vCenter con el botón derecho del ratón y selecciona New DataStore Cluster. Puedes configurar, como en VMware DRS, tu datastore clúster en modo manual o completamente automático. Quizás lo más importante a la hora de configurar tu datastore clúster es seleccionar unos buenos Thresholds de configuración de E/S en tus LUNs. Esta configuración de los thresholds permitirá a SDRS hacer las recomendaciones necesarias de migraciones. En mi ejemplo, me he creado un datastore clúster con una latencia de I/O mínima de 15 milisegundos. Si mis máquinas virtuales sufrieran una latencia de E/S superior a los 15 milisegundos, SDRS migraría la máquina virtual con Storage vMotion a otro datasotre del clúster que ofrezca el mínimo de latencia configurado. De esta forma podrás crear SLAs - de las siglas en inglés Service Level Agreetment - para todas y cada una de tus máquinas virtuales de una forma rápida, sencilla y automatizada. Sin lugar a dudas, Storage Distribute
Resource Scheduler es una de las funcionalidades del centro de datos del futuro el cual es virtual, flexible, dinámico y “plug & play”.
Gracias y Cierre
Me gustaría darte las gracias personalmente por haber visitado nuestro blog virtualización & Cloud Computing y haberte suscrito a este eBook sobre virtualización con VMware vSphere. Me gustaría poder obsequiarte con un descuento del 31% en mi curso básico online líder de ventas en Udemy: Virtualización con VMware aplicada al mundo empresarial. Ademas, si te gustan las emociones fuertes y ya tienes un "elevado" nivel de administración de VMware vSphere, me gustaría obsequiarte mi curso online avanzado VMware vSphere con un 33% de descuento! En los enlaces que te adjunto arriba en este correo tendrás toda la información de ambos cursos online VMware, así como el código de descuento ya aplicado. Muchas gracias y nos vemos online!. Y recuerda, estamos disponibles para cualquier duda, pregunta o sugerencia que tengas en este correo electrónico: [email protected] Jose Maria Gonzalez CEO & Founder www.jmgvirtualconsulting.com
Virtualización con VMware vSphere
eBook por José María González
José María González [email protected] http://www.jmgvirtualconsulting.com @jmgconsulting
