Capítulo 1: Primeros pasos en la certificación VMware vSphere™
VCP550™
¿Por qué la virtualización es tan importante?
En 1998, VMware descubrió una tecnología que fue considerada hasta entonces algo imposible de lograr, virtualizar la plataforma x86. Esta solución fue una combinación de traducción binaria (binary translation) y ejecución directa (direct execution) directamente en el procesador, lo que permitió que múltiples sistemas operativos “Guest” se pudiesen ejecutar a la vez en el mismo hardware físico, totalmente aislados unos de otros y con una "sobrecarga" en la capa virtualización relativamente pequeña.
El ahorro que decenas de miles de empresas han obtenido con el despliegue de esta
tecnología, está impulsando, de una forma pronunciada y rápida, la adopción de la tecnología de virtualización desde el centro de datos hasta el escritorio.
Resolver el problema de la proliferación de servidores, la falta de espacio, el consumo de energía y la refrigeración en las salas de servidores mediante la sustitución de servidores de aplicaciones individuales por máquinas virtuales consolidadas en un número mucho menor de equipos físicos, son sólo algunos de los principales beneficios de la virtualización de
servidores.
Otros de los beneficios de la virtualización son:
Mejor uso del hardware del servidor mediante el despliegue de nuevos servidores en máquinas virtuales, evitando añadir más servidores físicos infrautilizados al centro de datos.
Reducir drásticamente el tiempo de aprovisionamiento de nuevos servidores en máquinas virtuales, pasando a minutos en lugar de días o semanas necesarias para aprovisionar un servidor físico.
Asimismo, como la capacidad de procesamiento en los servidores ha aumentado de manera constante en los últimos años, y no cabe duda que seguirá aumentando, la virtualización ha demostrado ser una tecnología muy potente para simplificar el despliegue de software y servicios, dotando al Centro de Datos de mucha más agilidad, flexibilidad y, lo que quizás haya pasado desapercibido pero no por ello es menos importante, la reducción significativa de los costes energéticos y el impacto medio ambiental.
Este libro pretende descubrirte todos los secretos en la instalación, configuración y gestión de VMware vSphere™ 5 y, de paso, prepararte para la certificación de VMware VCP510.
¿Cómo conseguir la certificación VCP™ 510?
Para obtener la titulación VMware Certified Professional debes seguir tres pasos muy sencillos:
1. Participar en un curso autorizado y oficial VMware para adquirir experiencia. Este curso es impartido por un instructor oficial VMware, el cual te enseñara las mejores prácticas en la instalación, configuración y gestión de VMware vSphere™ 5.x
Los cursos aceptados son:
VMware vSphere 5.x: Install, Configure and Manage v5.x
VMware vSphere 5: What´s New (Este curso es necesario solo para los candidatos que ya han pasado la certificación VCP4)
2. Adquirir experiencia con los productos VMware. Aquellos profesionales que no han tenido experiencia previa con los productos VMware, les resultará más difícil pasar el examen VCP™ 510.
3. Inscribirse y aprobar el examen oficial. Para inscribirse en el examen VCP™ 5 (VMware Certified Professional), has de darte de alta en VMware en la siguiente dirección:
http://mylearn.vmware.com/mgrReg/plan.cfm?plan=45082&ui=www_cert
Para ver los cursos autorizados oficiales por VMware, donde se imparten los cursos oficiales, puedes visitar la siguiente dirección web:
http://www.jmgvirtualconsulting.com/formacion
Algunas preguntas frecuentes sobre VMware™ VCP™
¿Cuál es la “Hoja de Ruta” para obtener la certificación VCP™ en vSphere™?
Hay cuatro caminos posibles para lograr la certificación VCP5™ en vSphere™ 5. 1. Si eres nuevo en el mundo VMware:
Aprueba el examen VCP510 en vSphere™ 5.
2. Si eres actualmente un VCP3 en VMware Infrastructure 3:
Asiste al curso oficial VMware vSphere™ 5: Install, Configure and Manage o al curso oficial What´s New 5.
Aprueba el examen VCP510 en vSphere™ 5. Esta opción, solo estará disponible hasta el 29 de Febrero del 2012.
3. Si eres actualmente un VCP4 en VMware ESX/ESXI 4.x:
Aunque no hay ninguna limitación imporante, es importante destacar que si estará limitado en cuanto al tiempo transcurrido desde que hiciste el curso de formación hasta cuando quieras presentarte al examen VCP510™ en vSphere™ 5. La ultima fecha que me ha dado VMware es febrero del año 2012.
Asiste al curso oficial VMware vSphere™ 5: What´s New 5.
4. Si no eres VCP pero has asistido a uno de los cursos requeridos para la certificación oficial VCP4™ (VMware Install, Configure and Manage):
Asiste al curso VMware vSphere™ 5: What´s New 5.
Aprueba el examen VCP™ en vSphere™ 4.x.
Aprueba el examen VCP™ en vSphere™ 5.
Puedes ver los plazos y el “Last minute” en la siguiente URL: http://www.jmgvirtualconsulting.com/formacion
¿Cómo puedo saber si el curso es oficial VMware?
Los cursos que no estén autorizados por VMware, no cumplen los requisitos para la certificación VCP5 en vSphere™ 5. Asegúrate de asistir a un curso oficial VMware confirmando que dicho curso aparece en la página web de VMware:
http://mylearn.vmware.com/mgrreg/index.cfm
¿Realmente necesito asistir al curso oficial para poder obtener la certificación VCP5™ en vSphere 5™?
El curso oficial VMware es un requisito obligatorio para la certificación. VMware no hace ninguna excepción en este requisito.
El examen VMware Certified Professional es administrado por Pearson VUE, un centro autorizado externo. Pearson VUE tiene más de 3.500 centros de exámenes autorizados en todo el mundo.
¿Cuántas preguntas hay en el examen VCP510™ de vSphere™ 5?
En el examen hay 85 preguntas tipo test. Tienes 90 minutos para responder a todas las preguntas. En países donde el inglés no es el primer idioma, los candidatos recibirán
automáticamente 30 minutos adicionales. Necesitas una puntuación de 300 o más para poder aprobar el examen, siendo 500 la puntuación máxima.
¿Qué ocurre si suspendo el examen?
Podrás intentarlo de nuevo siempre que quieras, pero tendrás que esperar 7 días antes de intentarlo otra vez. Cada intento exige un nuevo pago para cubrir el coste del examen. ¿Cómo puedo saber lo que abarca el examen VCP™510?
En la dirección web adjunta, podrás encontrar una guía oficial VMware (VCP5 Exam
Blueprint) sobre la materia que se cubre en el examen. Usa esta guía como referencia para preparar el examen:
http://mylearn.vmware.com/portals/certification/
¿Hay alguna forma de practicar el examen antes de presentarse al examen oficial? VMware ha puesto a disposición del público en general, una dirección web donde puedes practicar antes de presentarte al examen oficial:
Recuerda que las preguntas mostradas en este simulacro, solo son meramente orientativas. No obstante, te servirán para saber si estás preparado para presentarte al examen o, por el contrario, si necesitas estudiar un poco más y retrasar la fecha del examen.
Capítulo 2: Instalación vSphere™ 5.x
En esta primera sección verás una introducción a la virtualización y la instalación de VMware vSphere™ ESXi 5.x, los mínimos y máximos tanto soportados como certificados por VMware vSphere™ ESXi 5/ vCenter Server™ 5.x, la nueva versión de vCenter Server Appliance™ para entornos Linux, así como los mínimos y máximos para las máquinas virtuales en vSphere™ 5.x
¿Cómo es la virtualización con VMware vSphere™ 5.x?
Los servidores y los desktops cada día son más potentes y el software de virtualización de servidores ha demostrado, una vez más, ser una tecnología indispensable para simplificar el centro de datos y dotarlo de inteligencia propia.
En un entorno físico tradicional, el sistema operativo y el software asociado se están ejecutando en un único servidor físico. Este modelo de una aplicación por servidor puede
llegar a ser, y de hecho lo es en muchos casos, inflexible e ineficiente. Esta relación 1:1 precisamente es la que hace que servidores de muchos centros de datos que estén infrautilizados, alcanzado tan solo el uso de entre un 5 y un 10% de los recursos físicos de dichos servidores.
Asimismo, el aprovisionamiento de servidores físicos en un centro de datos es un proceso costoso en cuanto al tiempo necesario que se dedica a aprovisionar un servidor físico. En un entorno no virtualizado has de dedicar tiempo a comprar nuevo hardware, enrackar los servidores, instalar el sistema operativo y las aplicaciones.
Con el software de virtualización de servidores podemos transformar hardware en software. De esta forma, podemos ejecutar diferentes sistemas operativos, como por ejemplo Windows, Linux, Solaris, incluso MS-DOS, simultáneamente y en el mismo servidor físico. Así, cada contenedor, dotado de su sistema operativo “Guest” o invitado, es llamado virtual
machine (máquina virtual en inglés) o VM como acrónimo.
Pero la virtualización de servidores, no es un software de simulación o emulación, como el software de training de Cisco que simula un router de Cisco para poder hacer prácticas, es un software de ejecución.
Veamos ya algunas de las diferencias importantes de esta nueva versión de VMware vSphere con las versiones anteriores.
Primero, y quizás uno de los cambios más importantes en vSphere™ 5 es que la versión vSphere™ ESX ya no está disponible.
También, ahora con la nueva versión de ESXi™ 5, es posible instalar la imagen de un ESXi 5 directamente en la memoria del host físico usando una nueva funcionalidad llamada
vSphere™ Auto Deploy ESXi, de la cual hablaremos más adelante en este libro.
VMware vSphere™ 5 incluye una nueva versión para su sistema de archivos llamada VMFS-5 el cual, y a diferencia de las versiones anteriores, solo incluye un block size de 1MB a la hora de formatear el datastore.
VMware vSphere™ Storage Appliance - de las siglas en inglés VSA - es otra de las nuevas funcionalidades incluidas en la esta versión. Aunque hablaremos de esta nueva funcionalidad más adelante, recordarte que el VSA Manager ha de ser instalado en tu servidor de vCenter para que puedas configurar esta nueva herramienta.
VMware vSphere™ ESXi Dump Collector te permitirá recoger todos los log score dumps de tus servidores ESXi. Otra nueva funcionalidad en VMware vSphere™ 5.
Para poder ver el video tutorial de instalación de un servidor ESXi 5 y muchos más videos tutoriales, entra en nuestra página web dedicada en exclusiva al contenido multimedia extra de este libro en http://www.josemariagonzalez.es/video-tutoriales/formacion-vsphere-5
Alternativamente, también puedes ver videos tutoriales de instalación y configuración de VMware vSphere ESXi 5, así como manuales, artículos y posts interesantes para preparar el examen de certificación oficial VCP™510 en la página oficial del blog de virtualización y cloud computing en español en http://www.josemariagonzalez.es/
¿Cómo es una máquina virtual en vSphere™ 5?
Una máquina virtual en VMware vSphere™ 5, es básicamente un conjunto de ficheros planos y binarios los cuales conforman la máquina virtual (MV) completa con su sistema operativo y aplicaciones incluidas. Los ficheros más importantes que componen una máquina virtual son: el fichero de configuración (.vmx), el fichero de disco virtual (.vmdk), el fichero BIOS de la máquina virtual (.nvram) y el fichero de log (.log).
El tamaño del fichero swap de la máquina virtual (.vswp) es igual a la cantidad de memoria RAM configurada en dicha máquina virtual. Recuerda que este fichero se genera cuando la máquina virtual se arranca y se borra cuando se apaga.
Con la nueva versión vSphere™ ESXi 5, el máximo número de discos virtuales por host se ha aumentado a 2048 discos virtuales.
El tamaño máximo de un disco virtual que puedes configurar en una máquina virtual es de 2TB menos 512Bytes (espacio necesario del overhead del disco virtual).!
En cuanto a la memoria RAM asignada a las máquinas virtuales, ahora es posible asignar hasta un 1TB de memoria RAM física de tu host, el cual es el tamaño máximo que un host ESXi físico puede tener configurado.
Asimismo, es posible tener hasta un máximo de 512 máquinas virtuales por servidor ESXi. El número máximo de adaptadores SCSI para una máquina virtual es de cuatro por máquina virtual.
A cada máquina virtual le puedes conectar un controlador IDE máximo al cual puedes conectar hasta 4 dispositivos IDE.
En cuanto a dispositivos xHCI USB se refiere, es posible conectar hasta 20 controladores USB por máquina virtual. Sin embargo, solo es posible conectar un dispositivo USB 3.0 por
máquina virtual. A fecha de publicación de este libro, VMware vSphere™ ESXi 5 aun no soporta dispositivos USB 3.0 conectados directamente en el servidor.
Por último, puedes configurar hasta 128MB de memoria RAM destinada a la memoria de video por máquina virtual. Asimismo, el máximo número de vCPUs (virtual CPUs) por host ESXi es de 2048, siendo 25 el número máximo de vCPUs por core. El número máximo de vCPUs que podrás asignar a tus máquinas virtuales es de 32 vCPUs. Nota que para llegar a este número de vCPUs también el sistema operativo tiene que soportarlo.
Si estas usando este libro para prepararte el examen oficial de certificación VCP™510, asegúrate bien que conoces los mínimos y máximos de una máquina virtual y prepárate para poder responder preguntas tipo como:
¿Cuántos puertos serie, paralelo, CDROMs, floppies, NICs, puede llegar a tener una máquina virtual?
Asimismo, recuerda que aunque una máquina virtual puede tener como número máximo 10 tarjetas virtuales, solo podrás conectar cuatro tarjetas máximo durante la creación de tus máquinas virtuales con el wizard de creación de máquinas virtuales de vCenter Server 5. VMware vSphere™ 5 permite crear máquinas virtuales usando dos
wizards: Typical yCustom. Si seleccionas el método Typical, el wizard solo te pedirá el nombre, DataStore para la máquina virtual, sistema operativo y el tamaño del disco virtual, sin embargo no tendrás la opción de configurar otras opciones como el número de vCPUs, la versión del hardware virtual, la cantidad de memoria y un largo etcétera.
Por consiguiente, es una mejor práctica seleccionar la opción Custom para poder personalizar de una forma más profunda la configuración hardware de tus máquinas virtuales.
Aviso: Recuerda que una máquina virtual en vSphere™ 5 soporta hardware virtual versión 8 y que este hardware virtual no es compatible con versiones anteriores a vSphere™ 5. Por consiguiente, si quieres tener un entorno mixto, ESX/ESXi 4.x y vSphere™ ESXi 5, has de dejar el hardware virtual de tus máquinas virtuales con la versión 7 correspondiente a la versión 4 de VMware vSphere™ ESX/ESXi 4. Para terminar con un dato más sobre las máquinas virtuales y su configuración, el número máximo de virtual SCSI targets por máquina virtual es de 60.
Para poder ver el video tutorial de instalación de una máquina virtual en un servidor ESXi 5, entra en nuestra página web dedicada en exclusiva a los videos tutoriales de contenido multimedia de este libro en
http://www.josemariagonzalez.es/video-tutoriales/formacion-vsphere-5
Alternativamente, también puedes ver los videos tutoriales de instalación y configuración de VMware vSphere ESXi 5 para preparar el examen de certificación oficial VCP™510 en la página web oficial de YouTube en:
http://www.youtube.com/blogvirtualizacion
¿Cuál es la diferencia entre un software de virtualización basado en un hipervisor y la virtualización basada en host?
La virtualización basada en hipervisor (también denominada Bare-Metal), como por ejemplo vSphere™ ESXi, Microsoft HyperV o Citrix XenServer, está instalada en un servidor físico sin la necesidad de que exista un sistema operativo (Windows o Linux) instalado previamente. No obstante, la virtualización basada en host, como por ejemplo VMware Server, VMware Workstation o VMware Fusion, necesita previamente un sistema operativo instalado, ya sea Microsoft Windows, Mac OS o Linux.
Hay varias razones por las que un cliente elegiría el software de virtualización basado en hipervisor, como por ejemplo vSphere™ ESXi, en lugar de un software de virtualización basado en host, como por ejemplo VMware Server.
Primero, con el software de virtualización basado en hipervisor, es posible actualizar las máquinas virtuales que se albergan en los servidores físicos sin ningún tipo de downtime. Segundo, es muy probable que la empresa ya esté virtualizando varios servidores físicos y quiera tener la opción de tener una gestión centralizada.
Por último, un hipervisor baremetal siempre ofrece una mayor confiabilidad y rendimiento al no precisar de un sistema operativo Host lo cual se elimina un posible punto de fallo a nivel de hardware.
Aunque la virtualización basada en hipervisor ofrece un mayor rendimiento, es la virtualización basada en host la que ofrece una compatibilidad con el hardware mucho más amplia, es decir, si puedes instalar Windows o Linux en tu servidor físico entonces podrás instalar la solución de virtualización basada en host.
Por consiguiente, una de las mayores diferencias de la solución de virtualización basada en hipervisor y la solución de virtualización basada en host - aparte de las obvias ya mencionadas - , es que esta última tiende a tener una lista de hardware certificado mucha más amplia. Sin embargo, la virtualización basada en hipervisor tiene un mayor rendimiento, mayor fiabilidad y estabilidad, mayor escalabilidad y mucha más funcionalidad.
Para ver más información sobre los tres factores más importantes a la hora de elegir un hipervisor para el software de virtualización entra en este
enlace:http://www.jmgvirtualconsulting.com/
A diferencia de las versiones anteriores a VMware vSphere™ ESXi, solo las variables, memoria reservada y memoria configurada (Reserved Memory y Configured Memory) afectan ahora al incremento o reducción del memory overhead, el cual es una “penalización” a nivel de la capa de memoria que todos tenemos que pagar por el simple hecho de virtualizar
nuestro servidor físico. Esta penalización se mide en megas de memoria RAM y son megas de memoria que dejamos de ver y de usar en nuestro servidor físico.
Como consecuencia de este “impuesto revolucionario” que existía por el simple hecho de virtualizar nuestro servidor, VMware vSphere™ ESXi 5 usa una nueva funcionalidad llamada VMX swap con la que es posible reducir el memory overhead de tus máquinas virtuales. Básicamente, con una nueva tecnología llamada VMX swap, el tamaño del memory overhead se crea en un fichero swap con lo que este espacio de memoria puede llegar a ser re-utilizado por el hipervisor. Esta técnica posibilita un aumento en el ratio de consolidación de VMware vSphere™ 5 con respecto a versiones anteriores de VMware.
¿Cuáles son los nuevos prerrequisitos hardware en VMware vSphere™ ESXi 5? A día de hoy, es posible instalar VMware vSphere™ ESXi 5 en cualquier tipo de servidor de nueva generación. Asimismo, la lista de compatibilidad de hardware para VMware vSphere™ ESXi 5 ha aumentado considerablemente en esta última versión, debido principalmente, a que ESXI es la única versión disponible en vSphere™ 5.
Estos son los requerimientos de hardware mínimos para poder instalar VMware vSphere™ ESXi 5:
Procesador: Solo CPUs de 64-bit x86, Intel o AMD, máximo 160 CPUs (cores o hyperthreads).
Memoria: 2GB de RAM mínimo, 1TB máximo.
Red: Una o más tarjetas Gigabit Ethernet. Las tarjetas Ethernet de 10Gb también están soportadas. El número máximo de tarjetas de 1Gb Ethernet (tg3 de Broadcom) por servidor es de 32.
Controladora de disco: Controladora SCSI, controladora FC (Fibre Channel), controladora iSCSI, controladora RAID interna, SAS y SATA.
Almacenamiento: disco SCSI, LUN (Logical Unit Number) FC, disco iSCSI o RAID LUN con espacio disponible sin particionar.
Es posible instalar VMware vSphere™ ESXi 5 en una LUN de la SAN, método conocido con el nombre de Boot from SAN (BFS). BFS está soportado en Fibre Channel SAN, en iSCSI (iniciadores de software iSCSI y dependent hardware iSCSI) y en FCoE - de las siglas en inglés Fibre Channel over Ethernet - para aquellas cabinas de almacenamiento que estén incluidas en la matriz de compatibilidad. VMware vSphere™ ESXi 5 puede configurarse con un máximo de 256 LUNs de FC (Fibre Channel).
Recuerda que los dos requerimientos necesarios para poder hacer boot from SAN son: 1. La BIOS de la HBA (Host Bus Adapter) debe estar habilitada.
2. Debes seleccionar la HBA con el número de slot PCI menor.
Aviso: Recuerda que si haces una actualización de ESX/ESXi 4.1 a VMware vSphere™ ESXi 5, aquellos puertos no conocidos - no listados en la pestaña security profile - que se hayan abierto con el comando de consola esxcfg-firewall en tu servidor ESX/ESXi 4.x, no
permanecerán abiertos después del upgrade.
Asimismo, VMware vSphere™ ESXi 5 soporta un máximo de 8 dispositivos PCI/PCIe en modo VMDirectPath passtrough. Sin embargo, una máquina virtual no puede tener configurados más de dos dispositivos PCIx/PCIe configurados como VMDirectPath.
Si usas iniciadores de software iSCSI para hacer BFS y tu administrador deshabilita este iniciador de software iSCSI, el servidor ESXi 5 volverá habilitar dicho iniciador la próxima vez que se reinicie el servidor para poder hacer BFS.
Algunos aspectos importantes que deberías saber sobre la diferencias y similitudes entre VMware vSphere™ ESX y ESXi 5
En VMware ESX y ESXi hay más similitudes que diferencias, aunque quizá, el beneficio más importante de ESXi sobre ESX es que ESXi aumenta la seguridad y la fiabilidad de nuestro hipervisor.
VMware ESXi 5 tiene mucho menos código (76MB de footprint) que parchear y, por lo tanto, tiene una superficie de ataque mucho menor. La versión ESX ha desaparecido como tal con el lanzamiento de la versión de VMware vSphere 5.
La versión VMware vSphere™ ESXi 5 como la versión ESX comparten el mismo VMkernel y VMM - de las siglas en ingles Virtual Machine Manager -, aunque hay algunas connotaciones muy importantes a destacar:
1. Extensiones VMkernel: Mientras que en la versión clásica de VMware ESX podías instalar agentes y drivers de empresas de terceras partes, en ESXi solo se permite instalar
extensiones en el VMkernel que hayan sido previamente firmados digitalmente por VMware. Esta restricción ayuda mucho a asegurar el entorno y mantener el código seguro en el VMkernel.
2. Muchos de los agentes y deamons que se ejecutaban en el Service Console (COS) en la versión clásica del ESX, han sido convertidos y embebidos para que se ejecuten directamente en el VMkernel del ESXi.
3. La imagen del sistema en ESXi - system image - es una imagen bootable que es cargada directamente en memoria física. El propio “installer” usa esa misma imagen de sistema para copiar los ficheros en un disco local para futuros arranques.
Debido a que la imagen del sistema es cargada en memoria, la versión ESXi no necesita obligatoriamente de un disco local cuando este se está ejecutando. Esto significa que el disco local podría fallar pero, sin embargo, nuestro VMkernel continuaría ejecutándose.
4. La partición scratch. Es una partición de 4GB virtual y de tipo FAT (VFAT) la cual es creada por defecto en el primer disco local del servidor ESXi, si tu servidor tiene discos locales, claro. Si el servidor no tiene ningún disco local, esta partición no existirá pero se “rediccionara” el directorio scratch a una partición de tipo ramdisk llamada /tmp. Esto significa que el contenido de esta partición scratch no “sobrevivirá” a un reinicio del servidor ESXi. Por consiguiente, el servidor ESXi puede necesitar hasta 4GB de memoria RAM para almacenar esta partición scratch.
5. Y por último, pero no por ello menos importante, tenemos la partición bootbank. Esta partición contiene la imagen del sistema sobre un sistema de archivos. Si hay un disco local al cual ESXi pueda escribir, este almacena dos copias del bootbank. Pero ojo, solo una es montada en la estructura del sistema de archivos del ESXi en el directorio /bootbank. La segunda copia se usa únicamente durante actualizaciones para mantener una segunda copia como backup en caso de problemas durante actualizaciones del sistema.
Por otro lado, en VMware vSphere™ ESXi 5 es posible hacer una instalación de la imagen directamente en la memoria del servidor físico usando una nueva funcionalidad
llamada vSphere™ Auto Deploy ESXi Installation Option.
Con VMware vSphere™ Auto Deploy podrás acceder al fichero de instalación desatendido (answer file) via CIFS, SFTP o HTTP.
VMware vSphere™ ESXi 5 soporta la designación de capacidad de disco dinámicamente mediante una funcionalidad llamada vStorage Thin Provisioning.
Ahora, con VMware vSphere™ ESXi 5 es posible hacer una migración en caliente con Storage vMotion de una máquina virtual que tiene snapshots.
VMFS-5 soporta un máximo de 9.000 discos virtuales por datastore. Solo existe una única opción de tamaño de bloque para un datastore formateado con la versión 5 de VMFS. Este block size es únicamente de 1MB y te permite crear discos virtuales con un tamaño de hasta 2Gb.
Ahora en VMware vSphere™ ESXi 5 y VMFS-5 es posible tener hasta un máximo de 4 ficheros swap por máquina virtual.
También ahora es posible con VMware vSphere™ ESXi 5 hacer un “unmount” del datastore siempre y cuando se cumplan los tres requisitos siguientes:
1. El datastore no puede contener ninguna máquina virtual. 2. El datastore no puede ser usado por vSphere™ HA heartbeat. 3. El datatore no puede pertenecer a un datastore clúster.
VMware vSphere™ ESXi 5 soporta ahora hasta 3.000 máquinas virtuales por clúster HA/DRS con independencia del número de servidores ESXi que hayas configurado en tu clúster. Por último, recuerda que VMFS-5 “solo” soporta 256 volúmenes o datastores VMFS por servidor ESXi.
Aviso: Cuando actualizas VMFS-3 a la versión VMFS-5, la configuración del block size de tu datastore VMFS-3 es heredara, es decir, si tu datastore VMFS-3 fue configurado con un block
size de 4MB, al actualizar a la versión VMFS-5 el block size seguirá siendo de 4MB. Nota que el block size de un datastore VMFS-5 no actualizado no puede ser distinto de 1MB.
Diferentes tipos de instalación en vSphere ESXi 5
VMware vSphere™ ESXi 5 solo es posible instalarlo en modo texto, a diferencia de VMware ESX donde era posible instalarlo también en modo gráfico.
Una nueva funcionalidad en VMware vSphere™ ESXi 5 llamada Image Builder te permitirá hacer instalaciones personalizadas de tu ESXi así como asociar actualizaciones del binario del ESXi a dicha personalización. Hablaremos del Image Builder más adelante en este libro. Solo apuntar que el formato de los paquetes que usa VMware vSphere™ ESXi Image Builder se llaman VIB - de las siglas en inglés vSphere™ Installation Bundle.
Si usas la nueva funcionalidad llamada VMware Auto Deploy, recuerda que los logs de tu servidor ESXi serán almacenados en memoria con lo que al reinicializar tu servidor perderás estos logs por defecto. Para definir profiles de imágenes para tus servidores ESXi con Auto Deploy tendrás que usar cmdlet incluidos en el vSphere™ Power CLI image builder.
Es posible también actualizar servidores ESXi con la utilidad Enterprise llamada VMware Update Manager (VUM), de la que hablaremos también en este libro.
Una mejora practica antes de actualizar un servidor ESXi, es guardar la configuración del servidor que vas actualizar con el siguiente comando de vCLI: vicfg-cfgbackup -s
Aviso: Con VMware vSphere™ ESXi 5, el número total de caminos de FC (Fiber Channel) por servidor se han aumentado hasta los 1.204. En VMware vSphere™ ESXi 5 el máximo número de servidores conectados a volúmenes VMFS es de 64 hosts por volumen VMFS.
Asimismo, el número máximo de datastores conectados a un Cluster HA/DRS es de 32. Tampoco es posible actualizar varios servidores ESXi en un clúster simultáneamente, es decir, solo está permitido actualizar un servidor ESXi a la vez dentro de tu clúster.
Datos importantes sobre el nuevo installer en vSphere™ 5
Durante la instalación de vSphere™ ESXi 5, el installer de VMware, escanea no solo los discos locales conectados al servidor físico ESXi, sino que también hará un escaneo de los discos de tu SAN de FC y los mostrara si este tiene acceso a ellos.
Por consiguiente, y para evitar la instalación del binario de ESXi en una de tus LUNs de la SAN FC, recuerda esta “Best Practices” de VMware para evitar la sobre escritura de una LUN: Establece o solicita al administrador SAN de tu empresa un “LUN Masking” o mejor aún, si vas a instalar el binario en discos locales, desconecta los cables de la SAN de tu servidor ESXi. Además, está mejor práctica reduce el tiempo que necesita elinstaller de VMware en buscar discos conectados al sistema.
Si estas instalando un servidor ESXi en un disco que ya contiene una versión previa a la versión vSphere™ 5, el installer te da la opción de actualizar esa versión.
Cuando configuras una cabina SAN de FC con vSphere™, asegúrate de seguir las mejores recomendaciones:
1. Cada LUN debería contener solo un DataStore VMFS.
2. Cada LUN debería ser presentada a todos los servidores ESXi con el mismo LUN ID. Hay cuatro opciones o métodos para instalar la nueva versión de VMware vSphere™ ESXi 5:
Usando vSphere Auto Deploy
Mediante una instalación via script
Actualizando un servidor ya existente con VUM
Esta última opción es el método de instalación recomendado cuando has de instalar un número pequeño de servidores VMware vSphere™ ESXi 5.
VMware vSphere™ 5 ha dejado de soportar máquinas virtuales de 32bit y por consiguiente VMM de 32bits. Solo Virtual Machine Monitors de 64 bits pueden ejecutar sistemas operativos de 32bits. Por consiguiente, el uso exclusivo de un VMM de 64bits en vSphere™ 5 requiere instrucciones específicas a nivel de CPU llamadas LAHF y SAHF las cuales no se encuentran en arquitecturas de 32bit más antiguas. LAHF y SAHF solo están soportados en vSphere™ 5. Aviso: Una vez instalado, un servidor VMware vSphere™ ESXi 5 puede tener hasta256 LUNs FC (Fiber Channel) por servidor. Asimismo, el número máximo del ID en FC es de 255 pues los IDs de FC empiezan por el número 0 y no por el número 1.
Sin embargo, el número máximo de caminos iSCSI que un servidor ESXi pues ver es de 1.024.
Una instalación inicial de vSphere™ ESXi usa el formato GPT - de las siglas en inglésGUID Particion Table en lugar del formato MBR - de las siglas en
ingles Master BootRecord - lo cual permite instalar ESXi 5 en discos con un tamaño superior a 2TB. No obstante, si actualizas de versión VMware ESX/ESXi 4.x a ESXi 5 no se usara el formato GPT, sino que se mantendrá el formato MBR.
Aspectos importantes sobre la configuración y la seguridad de vSphere ESXi™ 5
Ahora VMware vSphere™ ESXi 5 incluye dos nuevas funcionalidades para aumentar la seguridad del VMkernel:
1. Memory Hardening: El kernel del ESXi, aplicaciones user-mode y ejecutables como drivers y librerías están localizadas en zonas de memoria aleatorias para evitar que
software del tipo troyanos averigüen de una forma sencilla la localización de estas zonas de memoria.
2. Kernel Module Integrity: Los módulos, drives y aplicaciones de ESXi son “firmados”
digitalmente para asegurar la integridad de estos una vez que el VMkernel los carga en memoria.
Asimismo, a diferencia de las versiones VMware ESX 4.x, en VMware vSphere™ ESXi 5 es posible hacer boot de tu servidor ESXi desde un disco USB externo.
También, ahora es posible instalar tus servidores ESXi con la opción de VMware Auto Deploy, sobre todo cuando tienes un número de host importante que instalar. De esta forma,
acelerarás la fase de instalación del binario de ESXi y el despliegue de tus máquinas virtuales. Si haces una actualización de la versión ESX 4.x a la versión ESXi 5 el portgroup tipoService Console (solo disponible en versiones ESX) será borrado ya que en los servidores ESXi no existe un Service Console. Asimismo, el portgroup de gestión en ESXi es
llamado Management Port. Recuerda antes de actualizar un servidor ESXi hacer una copia de seguridad de su configuración con el comando vicfg-cfgbackup desde el vCli.
Desde el punto de vista de almacenamiento compartido SAN iSCSC, el número máximo de LUNs iSCSI que puedes conectar a un servidor ESXi es de 256. Otro de los límites que han cambiado en esta nueva versión de VMware vSphere™ ESXi 5 con respecto a las versiones anteriores, es que ahora es posible tener arrancadas hasta 2.048 máquinas virtuales por volumen VMFS.
También, ahora es posible activar - y está soportado - el modo soporte (TSM - de las siglas en inglés Tech Support Mode) de modo que podrás entrar vía SSH a tu servidor ESXi. Puedes activar el modo TSM desde la DCUI (de las siglas en inglés Direct Console User Interface) o con el vSphere Client a través del panel Security Profilelocalizado dentro de la pestaña de Configuration.
Una vez entres en la consola de tu servidor ESXi, via comando podrás ver los logs de tu sistema, configurar las propiedades de los servicios de DNS, NTP, arrancar máquinas virtuales, apagar servidores ESXi y un largo etcétera. Sin embargo, una de las pocas tareas que no podrás hacer desde consola es la de poner tu host ESXi en modo mantenimiento. Para poder ver una guía de referencia de todos los comandos disponibles por consola en la versión ESXi 5.0, te recomiendo que veas el episodio número 31 de nuestro canal de
televisión web sobre la virtualización y el cloud computing en español en la siguiente dirección: http://www.virtualizacion.tv
Asimismo, con el fin de mejorar la seguridad del servidor ESXi, VMware ha añadido un firewall embebido en el VMkernel. A diferencia de las versiones anteriores, este firewall no está basado en IPtables de Linux.
Aviso: El máximo número de tarjetas HBA de FC soportadas por un servidor ESXi es de ocho. También, el número máximo de CPUs lógicas por servidor ESXi 5 ha aumentado a las 160 por host.
Si aún tienes servidores ESX en tu entorno virtual y necesitas aplicar parches en el Service Console del ESX, debes de asegúrate de aplicar dichos parches solo y únicamente cuando VMware haya hecho público las actualizaciones y siempre que sea sugerido por personal autorizado de VMware o por el equipo experto de VMware llamado VMware Security Advisories.
Para poder recibir alertas de seguridad sobre vulnerabilidades del software de VMware, puedes suscribirte en esta dirección: http://www.vmware.com/security.
Tipos de almacenamiento soportados en VMware vSphere™ ESXi versus funcionalidad
En la tabla adjunta, se muestran los cinco tipos de almacenamiento soportados en VMware vSphere™ ESXi 5, así como las diferentes funcionalidades soportadas por cada tipo de almacenamiento.
Con relación a la conectividad iSCSI y su iniciador de software iSCSI, el máximo número de iSCSI targets es de 265. Asimismo, no es posible crear más de un NIC Teaming con el iniciador de software iSCSI con más de 8 vmnics (uplinks o tarjetas de red físicas disponibles en el servidor ESXi). Solo es posible tener un número máximo de ocho caminos por LUN para los volúmenes VMFS conectados via software o hardware iSCSI.
En cuanto al tamaño máximo de un volumen VMFS para la versión 3 (VMFS-3) es de 2TB menos 512Bytes de espacio con un block size de 8MB. Sin embargo, en VMFS versión 5 (VMFS-5) el tamaño del block size es de tan solo 1MB, aunque es posible crear ficheros .vmdk con un tamaño máximo de 2TB. Recuerda que en VMFS versión 3 y con un block size de
1MB, el tamaño de disco de la máquina virtual (.vmdk) no podrá superar los 256GB de espacio en disco.
Asimismo, el tamaño máximo para un volumen RDM (de las siglas en inglés Raw Device Mapping) en VMFS-5 es de 64TB, siempre y cuando uses la funcionalidad de extenders a nivel VMFS, de la cual hablaremos más adelante en este libro, y el modo de compatibilidad de este RDM sea físico. Sin embargo, para un volumen RDM VFMS-5 en modo de compatibilidad virtual, el tamaño máximo es de 2TB menos 512 bytes.
VMware vSphere™ ESXi 5 usa el protocolo NFS versión 3 para comunicarse con cabinas de tipo NAS. Nota que aunque NFS también puede usar la versión 4, esta no está soportada por VMware. En la versión VMware vSphere™ ESXi 5, ahora es posible montar hasta 256 volúmenes NFS por host.
Con relación a los ficheros swaps de las máquinas virtuales, el tamaño máximo que puede alcanzar este tipo de ficheros es de 1TB por máquina virtual, siempre y cuando, configures tu máquina virtual con 1TB de memoria RAM.
Puedes ver más información sobre la configuración del block size en VMFS-5 en nuestro canal oficial de YouTube: VMware vSphere 5.0 en entornos SAN iSCS
En cuanto al número máximo de targets que un servidor host puede ver con un adaptador Broadcom 10GB iSCSI es de 128 targets. El número máximo de tarjetas 1GB Ethernet Broadcom (bnx2) que un servidor host ESXi puede tener es de 16.
Aviso: El número máximo de caminos por LUN de FC es de 32. Y si te pica la curiosidad por saber cuál es el número máximo de ficheros que puedes tener en un volumen VMFS-5, es de 130.690 ficheros, aunque me temo que muy probablemente no alcances nunca ese límiteJ. En VMFS-3 el máximo número de ficheros era de 30.720 ficheros.
Diagnosticando un problema en vSphere 5
Para poder diagnosticar un problema con vSphere ESXi 5, necesitas exportar los logs. Desde el vSphere Client, selecciona File > Export > Export System Logs.
Ten en cuenta el tamaño requerido para almacenar estos logs, sobre todo si cambias el nivel de lo que quieres que se logee en tu sistemas. Para ponértelo en contexto, los logs pueden llegar a crecer hasta 9GB en una instalación de 10 ESXi y aproximadamente 100 máquinas virtuales con respecto al nivel estándar de logeo.
También, y si no tienes configurado un servidor de vCenter, puedes conectarte directamente a tu host ESXi y exportar los logs seleccionado la opción, File > Export.
Ayer aprendimos lo básico de la certificación oficial VMware y vimos los dos primeros capítulos.
Hoy veremos los dos próximos capítulos, la red y el almacenamiento: Hasta mañana,
Jose Maria Gonzalez
CEO and Founder de www.jmgvirtualconsulting.com
Capítulo 3: Red en vSphere™ 5.
La funcionalidad de red en una infraestructura virtual es de suma importancia. Permite que las máquinas virtuales en un servidor VMware vSphere™ ESXi 5 puedan comunicarse con otras máquinas físicas o máquinas virtuales en otros servidores VMware vSphere™, mediante la configuración de los virtual switches. También te permite comunicarte con el Management Network de los servidores VMware vSphere™ 5 para poder gestionarlos y con el VMkernel para poder configurar vMotion y cabinas de almacenamiento basadas en protocolos NFS o iSCSI.
En este capítulo te enseñaré a entender el propósito general de un virtual switch y
undistributed virtual switch, cómo configurarlos y conectar uplink ports, así como a entender las diferentes configuraciones y políticas de seguridad que se pueden definir a nivel de virtual switch, port group o ambas.
Diferentes tipos de port groups en vSphere™ ESXi 5
Un virtual switch estándar (VSS) tiene tres funciones principales:
1. Comunicar con máquinas virtuales dentro de un mismo servidor VMware ESXi o con otras máquinas físicas o máquinas virtuales en otro servidor VMware ESXi, para lo que utilizamos un Virtual Machine Port Group.
2. Comunicar con nuestro servidor ESXi via SSH (puerto 22) o vSphere Client, para lo que utilizamos un Management Network Port.
3. Comunicar con el VMkernel y puertos IP de tipo VMotion, NFS e iSCSI, para lo que utilizamos un VMkernel Port.
A diferencia de los switches físicos, no es posible conectar dos virtual switch juntos mediante un ISL (InterSwitch Link Protocol), ni puedes mapear la misma tarjeta de red a más de un virtual switch a la vez. Recuerda que sí es posible configurar un virtual switch sin ninguna tarjeta de red, lo que es denominado como internal switch only.
Cuando creas un NIC teaming (una o más tarjetas de red mapeadas a un virtual switch para incrementar el ancho de banda o dotar de alta disponibilidad a la capa de red), todas las tarjetas de red dentro del teaming pasan a ser activas por defecto. Para crear virtual
switches puedes usar el vSphere Client o, desde la consola del servidor ESXi, puedes usar el comando: esxcfg-vswitch -a "nombre vswitch".
Si hay dos máquinas virtuales conectadas a dos virtual switches diferentes, el tráfico entre dichas máquinas fluirá a través de las tarjetas físicas mapeadas a los switches virtuales y entre servidores ESXi. Por el contrario, si varias máquinas virtuales están conectadas al mismo VSS del mismo servidor ESXi, los paquetes no salen por la red, sino que son transmitidos internamente en el servidor ESXi por el VMkernel.
Para mejorar el rendimiento de red de las máquinas virtuales es posible mapear más de una tarjeta física (uplink) al VSS.
Aviso: También es posible configurar switches distribuidos virtuales (Virtual Distributed Switch). La configuración de los switches distribuidos (VDS) es almacenada en el servidor vCenter a diferencia de los switches estándar, los cuales almacenan la configuración en los servidores ESXi. Un Virtual Distributed Switch no es más que un VSS que es compartido entre múltiples servidores VMware vSphere™ ESXi. Los VDS solo están incluidos en la versión Enterprise Plus.
Port groups y el virtual switch estándar
En vSphere™ ESXi 5, el número máximo de puertos soportados para un VSS es de4088. A este vSwitch, puedes conectar ninguno, uno o más de un uplink.
Recuerda que es posible cambiar el número de puertos en los VSS siempre que sea
necesario. Sin embargo, dicho cambio requiere un “reboot” del servidor ESXi para que los cambios tengan efecto.
Los port groups de tipo Management Network, Virtual Machine y VMkernel pueden todos ser configurados en un único VSS. Asimismo, sólo un VLAN ID puede ser especificado por port group pero múltiples port groups pueden especificar el mismo VLAN ID.
Es posible también garantizar un mínimo de servido o ancho de banda a todas y cada una de tus máquinas virtuales. Para ello, puedes usar una técnica de gestión de recursos
llamada Traffic shapping, a nivel de port group, donde está incluida la máquina virtual para aliviar problemas de congestión de red o garantizar un ancho de banda determinado. Esta funcionalidad para los VSS te permite limitar el ancho de banda desde la máquina virtual hacia afuera (outbound) pero no desde fuera hacia la máquina virtual (inbound).
Si precisas tener que limitar el ancho de banda desde fuera hacia dentro y desde dentro hacia afuera (outbound y inbound) tendrás que usar los switches distribuidos (VDS). Recuerda que este switch distribuido se crea en el vCenter Server, con lo que para usar VDS, aparte, debes de contar con una licencia de vCenter.
Por defecto, y para los VSS, cuando creas un virtual switch por defecto es creado con 120 puertos. Sin embargo, si utilizas la línea de comando y ejecutas el comando“esxcfg-vswitch – l” verás que en realidad son 128 puertos.
Estos ocho puertos son puertos extra que usa el VMkernel internamente y que no podemos usar desde la GUI. Estos ocho puertos extras solo pueden verse desde la línea de comando en ESXi 5:
Aviso: Es posible que tengas la necesidad de limitar el ancho de banda en los diferentes tipos de conexiones descritas anteriormente, y sobre todo, que tengas que aliviar problemas de cuellos de botella en la capa de red. En capítulos posteriores cubriremos algunas técnicas para aliviar cuellos de botella en los diferentes componentes de vSphere 5.
Cada virtual switch, es una representación lógica vía software de un switch físico de capa dos. Los tres tipos de virtual switch que puedes crear en un servidor ESXi 5 son los siguientes: 1. Internal switch only. Este switch es usado únicamente para conectar, vía red, las máquinas virtuales instaladas en el mismo servidor VMware ESXi, las cuales no necesitan conexión con el mundo exterior.
2. Virtual switch con un adaptador de red. Este switch es usado para conectar, vía red, máquinas virtuales, Management Network (gestión) y puertos VMkernel con el mundo exterior, o dicho de otro modo, con otros servidores y máquinas virtuales de nuestro entorno virtual. 3. Virtual switch con más de un adaptador de red. Este switch es usado para conectar, vía red, máquinas virtuales, Management Network y puertos VMkernel con el mundo exterior con una funcionalidad adicional, como es el balanceo de carga y redundancia a fallos en los componentes de red.
Las políticas de seguridad y de traffic shaping son configuradas a nivel de port
groupy vSwitch. Una configuración incorrecta del traffic shaping afectaría no sólo al tráfico de las máquinas virtuales sino también al tráfico en general.
En vSphere™ ESXi 5, una tarjeta mapeada a un switch virtual puede ser configurada para trasmitir y recibir tramas “Jumbo Frame”. El MTU (Maximum Transmision Unit) de un ”Jumbo Frame” es de 9000. VMware ESXi 5 también soporta “Jumbo Frames”, tanto en los VSS como en los VDS.
Ahora, también es posible activar desde la GUI de los VSS el uso de los mismos. La configuración de Jumbo Frames es considerada una mejor práctica para las redes de tipo iSCSI, vMotion y Fault Tolerance.
Aviso: Los tres tipos de virtual switch pueden soportar hasta un total de 4088 puertos por switch virtual estándar.
Para los tres tipos de virtual switch, no existen colisiones de red en el tráfico interno. Asimismo la dirección MAC de los adaptadores de red conectados a los virtual switchesno será usada en ningún momento de forma interna.
Las políticas de balanceo de carga en un VSS en vSphere™ 5
En VMware vSphere™ 5, el adaptador NIC físico conectado al primer puerto deManagement Network es denominado vmk0. El primer puerto de gestión definido en nuestro servidor VMware ESXi 5 es denominado "Management Network".
La configuración de las políticas de balanceo de carga en un NIC teaming y para un VSS son tres:
Route based on the originating virtual port ID
Route based on source destination MAC hash
Y Route based on IP hash
Sin embargo, las políticas de balanceo de carga para un NIC teaming en un VDS incluye otra política adicional llamada Route Based on physical NIC load como veremos más adelante.
Aviso: En una configuración de NIC teaming a nivel de VSS, es muy importante activar la opción Notify Switches. Cuando configuras una política de NIC teaming en un VSS y
seleccionas la opción Notify Switches, el switch físico será alertado cuando la localización de una tarjeta virtual cambia de puerto. Esto ocurre, por ejemplo, cuando se hace una migración de una máquina virtual en caliente con vMotion.
Propiedades de los adaptadores de red en VMware ESXi 5
Para ver las propiedades de tus tarjetas de red, selecciona el servidor ESXi en el panel inventario, luego en la pestaña Configuration, selecciona el enlace Networking en la
parte Hardware y luego Properties en el switch virtual que tiene conectado el adaptador de red que quieres modificar.
Existe nueva tecnología en vSphere™ ESXi 5 que puedes usar para incrementar el throughput de tus máquinas virtuales es el Split RX como veremos más adelante.
Si estas usando adaptadores de red Gigabit Ethernet, es considerada una mejor práctica dejar la velocidad y la configuración de dúplex en auto negotiate ya que el auto negotiate es parte del estándar en redes Gigabit Ethernet.
Aviso: Para configurar NetQueue, y mejorar así el rendimiento de red de las máquinas virtuales en un servidor ESXi, es necesario habilitarlo en el driver de la tarjeta física y en las opciones avanzadas del VMkernel. Si el rendimiento de la consola remota para una máquina virtual es lento, verifica la configuración (speed, duplex) de la tarjeta física asignada al port group del switch virtual.
Los diferentes tipos de políticas de seguridad en vSphere
En los VSS, hay tres tipos diferentes de políticas de seguridad: Traffic shaping Policy, NIC Teaming Policy y Security Policy. En un Virtual Distributed Switch, aparte de estas tres políticas de seguridad, existe otra nueva, Port Blocking Policy.
Las políticas pueden ser definidas a nivel de virtual switch, las cuales se convertirían también en las políticas por defecto para todos los port groups creados en dicho virtual switch, o a nivel de port group.
Las políticas definidas a nivel de port group, siempre sobrescriben las políticas definidas a nivel de virtual switch. Un vSwitch o vSwitch port group en "Promiscuous Mode" permitirá que una máquina virtual pueda "escuchar" todo el tráfico contenido en ese VSS y no solo el tráfico destinado para esta máquina virtual en concreto.
Una mejor practica en la capa de red con vSphere™ 5 es que antes de crear los diferentes tipos de switches virtuales, protocolos de balanceo de carga, VLANs, port groups y NIC teaming, hables con el administrador de tu red física sobre lo que necesitas a nivel de red virtual.
Es muy corriente implementar IP hash a nivel de red virtual en entonos de producción relativamente importantes para luego darse cuenta que no está funcionando correctamente porque no se ha activado en el switch físico.
La configuración predeterminada en vSphere™ 5, dentro de la política de seguridad Security
La configuración predeterminada para la política de seguridad Security y para todos los VSS es la siguiente:
Promiscuous Mode: Reject - Significa que el virtual switch no redireccionará ninguna trama a otros puertos del switch (modo switch). Si Promiscuous Mode es cambiado aAccept, el switch se comportaría como un HUB y redireccionará todas las tramas entrantes y salientes a todos los puertos del virtual switch.
Esta configuración suele ser útil cuando "pinchamos" un sistema IDS (Intrusion Detection System) o sniffer en un virtual switch para analizar todas las tramas de dicho switch. MAC Address Changes: Accept - Significa que el virtual switch no haría un drop de la trama entrante si la dirección MAC de ésta no coincide con la dirección MAC de la máquina virtual conectada en ese port group. Por defecto, esta opción se suele cambiar a Reject para evitar ataques tipo MAC spoofing.
Forged Transmit: Accept - Significa que el virtual switch no haría un drop de la
tramasaliente si la dirección MAC de ésta no coincide con la dirección MAC de la máquina virtual guardada en el fichero de configuración (.vmx) de dicha máquina virtual. Por defecto, esta opción se suele cambiar a Reject para evitar ataques tipo MAC flooding y MAC spoofing. En resumen, Forged Transmit permite a una máquina virtual transmitir paquetes (outbound) que contienen una dirección MAC diferente a la que se ha definido en esa máquina virtual. Recuerda que las políticas de seguridad de red a nivel de VSS y port
group sonReject (Promiscuous Mode), Accept (MAC address Changes) y Accept (Forget Transmit).
Aviso: No cambies la configuración por defecto de MAC Address Changes ni Forged Transmits si tienes configurado en el virtual switch un clúster Microsoft NLB (Network Load Balancing) en modo unicast.
Para ver más información sobre la configuración determinada con Microsoft NLB, ver elKB número 1556 en la página de VMware: http://kb.vmware.com
Asimismo, cuando tengas que hacer una conversión P2V - de las siglas en inglés Physical to Virtual - con el software de conversiones de VMware llamado vConverter, asegúrate de configurar Allow Mac Adress Changes en Accept, si el servidor físico que estas intentando convertir tiene software instalado que fue licenciado usando la dirección MAC de su tarjeta física.
La configuración predeterminada, dentro de la política de seguridad de Traffic Shaping
Esta política de seguridad de traffic shaping, para el vswitch y port group, está desactivada por defecto. Con la opción network traffic shaping puedes limitar eloutbound peak bandwidth y el outbound average bandwidth.
Esta política de traffic shaping solo se aplica a las conexiones de dentro hacia fuera (outbound), es decir, desde dentro del virtual switch hacia fuera del virtual switch.
No es posible definir una política de traffic shaping desde fuera del virtual switch hacia dentro (inbound) en un VSS.
Una primera alternativa para limitar el tráfico de tipo inbound es la de usar algún sistema externo de balanceo de carga o activar la opción de rate-limiting en tu router físico.
La segunda alternativa la encontramos en los VDS. En los Virtual Distributed Switches es posible definir el Traffic Shaping en ambas direcciones (Ingress inbound y Egress outbound).
En vSphere™ 5 hay dos formas de migrar una máquina virtual desde un vSwitch estándar a un Virtual Distributed Switch.
La primera opción es seleccionando un dvPort group desde las propiedades de la
configuración de red de la máquina virtual, y la segunda, seleccionando la máquina virtual desde la lista de máquinas virtuales cuando usas la opción "Migrate Virtual Machine Networking".
Una nueva funcionalidad en los VDS de la versión ESXi 5 es la de habilitar la opción deNetFlow. Esta opción te permitirá mandar tráfico de red desde un VDS a una máquina virtual, la cual si tiene un software de análisis de red podrás hacer un estudio muy exhaustivo de tu red de datos y del tipo de tráfico enviado por tu red.
Para terminar con las diferencias entre un VSS y un VDS, estas son las tres funcionalidades más importantes que están disponibles en los VDS y no en VSS:
NetFlow Monitoring
Network I/O Control
Egress Traffic Shapping
Cuando creas un dvPort group, el port binding dinámico (Dynamic Binding) se asegura de asignar un puerto a la máquina virtual la primera vez que es encendida.
Recuerda que si usas un uplink que ya está previamente en uso en un VSS para crear un VDS, las máquinas virtuales que estuvieran usando ese uplink perderán la conectividad. Aviso: Ten en cuenta que el Average Bandwidth y Peak Bandwidth son medidos enKbps, mientras que el Burst Size es medido en KB.
De la misma manera se mide en los Virtual Distributed Switch. Asimismo, recuerda que el máximo número de VDS por servidor de vCenter es de 32.
Como he mencionado anteriormente, el VDS se crea en el servidor de vCenter y se gestiona desde ese mismo servidor de vCenter.
Existen tres métodos a la hora de crear un port groups en un Virtual Distributed Switch: 1. El adaptador de red con la configuración del port group puede ser asociado con unport group existente en un Virtual Distributed Switch.
2. El port group también puede ser migrado desde un virtual switch estándar a un VDS y viceversa.
3. Un adaptador de red con la configuración de un port group puede ser creado durante la instalación de un Virtual Distributed Switch.
Una mejor practica de VMware es la de usar VDS en lugar de VSS ya que los swithes distribuidos ofrecen algunas funcionalidades Enterprise que no están incluidas en los VSS. Naturalmente tendrás que evaluar el coste adicional asociado al uso de los VDS ya que solo es posible configurar VDS si tienes la licencia Enterprise plus.
La configuración predeterminada en vSphere™ 5, dentro de la política de seguridad de NIC Teaming.
Para la política de seguridad de NIC Teaming, existen cuatro opciones en el algoritmo de load balancing a seleccionar: route based on the originating virtual port ID (por defecto), route based on ip hash (es necesario etherchannel), route based on sourceMAC hash y explicit failover order. Recuerda que las políticas de load balancingpara el Virtual Distributed Switch son las mismas, más una extra adicional.
Para habilitar el NIC teaming es necesario conectar más de una tarjeta de red física a un único virtual switch o virtual distributed switch.
Si la opción "explicit failover order" no es elegida como algoritmo de balanceo de carga en un virtual switch con múltiples uplinks (NIC teaming) y una de las tarjetas físicas del teaming “se cae", el VMkernel verifica el contador "reported uptime" de las otras NICs para asignar una NIC del teaming y proceder al failover.
Beacon Probing se usa en vSphere™ para detectar e identificar fallos en el
enlaceupstream. Es muy útil en entornos Blade y en donde tenemos Spaning Three Protocol activado en nuestra red física. De esta forma podremos detectar fallos de red en los caminos alternativos.
En un VSS con un port group de tipo Management Netowrk y un port group tipoVMkernel, y mapeas dos uplinks al VSS, es posible separar el tráfico de gestión y del
trafico VMkernel seleccionando la política de balanceo "Explict Failover order".
Asimismo, es posible ver más información sobre la configuración actual de los VSS con el siguiente comando desde la consola de servidor ESXi:
Algunos máximos y mínimos importantes de red en VMware vSphere™ ESXi 5
Éstos son algunos de los máximos y mínimos en la capa de red para VMware vSphere™ ESXi 5:
256 es el número máximo de port groups ephemeral por vCenter.
256 es el número máximo de port groups por switch virtual estándar (VSS de las siglas en ingles virtual switch standard).
5.000 es el número máximo de port groups estáticos por instancia de vCenter.
5.000 es el número máximo de puertos virtuales en switches distribuidos por vCenter.
4.088 es el número máximo de puertos de red en los VSS.
350 es el número máximo de servidores ESXi 5 que puedes conectar por VDS.
32 es el número máximo de VDS por instancia de vCenter.
4096 es el número máximo de puertos virtuales de red por host (VSS y VDS).
1.016 es el número máximo de puertos activos por host (VSS y VDS).
24 es el número máximo de tarjetas de 1GB Ethernet (e1000e Intel PCI-e) por host.
32 es el número máximo de tarjetas de 1GB Ethernet (e1000e Intel PCI-x) por host.
24 es el número máximo de tarjetas de 10GB Ethernet (NetXen) por host.
4 es el número máximo de iniciadores de hardware iSCSI Broadcom de 10Gb por host.
512 es el número máximo de máquinas virtuales por host.
Aviso: En cuanto a las diferentes tarjeterías de red y sus combinaciones, VMware vSphere™ ESXi 5 soporta un máximo de seis tarjetas de 10GB y cuatro de 1GB en un mismo host. La importancia de VLANs en vSphere 5
La configuración de VLANs en un entorno virtual con vSphere mejora la seguridad de nuestra solución de virtualización.
Para la implementación de VLANs, los servidores VMware ESXi usan una metodología llamada port group policies. Para conectar una máquina virtual en un virtual switchcon una VLAN, debes usar el vSphere Client. Como vemos en la imagen de arriba, la red VM Network es la que ha sido configurada con un VLAN ID.
Si no configuras VLANs, las máquinas virtuales que estén mapeadas en cualquier port group del virtual switch podrán ver todo el tráfico.
Capítulo 4: Almacenamiento en vSphere™ 5.
El almacenamiento es, sin duda, uno de los pilares más importantes de una solución de virtualización. Es un componente crítico para poder dotar a nuestro entorno de un plan de contingencia a fallos, alta disponibilidad y migración de máquinas virtuales entre servidores VMware vSphere™ESXi.
La configuración de la zona a nivel del fabric de fibra es un mecanismo muy usando tanto para entornos físicos de SAN FC como para entornos virtualizados con una red de SAN FC. El Zoning se hace a nivel de switch de fibra para restringir las conexiones de los servidores ESXi o servidores físicos a la cabina de datos y prevenir que otros servidores destruyan los datos en los volúmenes.
LUN Masking se puede hacer en dos niveles: a nivel de procesadores de datos (en Ingles SP - Storage Processors) y a nivel de servidor ESXi. Aunque, en la actualidad elLUN Masking se suele hacer más a nivel de SP, también es posible hacerlo a nivel de servidor ESXi sobre todo cuando usamos Boot From SAN(BFS).
Asimismo en los switches de FC de nueva generación también es posible hacer LUN Masking. BFS puede llegar a ser útil para configuraciones diskless en servidores tipo Blade. Cuando estás haciendo BFS, la LUN FC desde donde arranque el servidor ESXi, deberá ser solo visible para ese servidor. Los otros DataStores VMFS, deberían ser visibles a todos los servidores ESXi.
Asegúrate siempre de que cambies tu configuración de la zona del fabric de FC o las propiedades de las LUNs, hacer un rescan de tu fabric a nivel de centro de datos. De esta forma te aseguras que todos los servidores tienen la última configuración de tu SAN.
Desde VMware vSphere™ 4, aparecieron APIs por doquier, lo cual ha permitido evolucionar el producto a nivel de almacenamiento con características muy innovadoras. Una de las APIs más importantes, y que ya apareció en la versión 4.1, es la vSphere APIs for Array Integration, también conocida por el acrónimo VAAI.
En consecuencia, una cabina con soporte VAAI para la nueva versión de VMware vSphere™ ESXi tendrá un mayor rendimiento en las siguientes operaciones:
Write Same/Zero nos ayuda a eliminar I/O en tareas repetitivas y disminuir el consumo de CPU, por ejemplo, la clonación masiva o el aprovisionamiento de máquinas virtuales. Fast/Full Copy nos permite realizar Storage vMotion sin tráfico en la red o las HBAs, ya que lo realiza la cabina SAN. La duración de la migración disminuye en un 25%, según datos proporcionados por EMC.
Hardware Offloaded Locking es una gran funcionalidad. Hasta ahora las reservas SCSI que se realizan sobre un datastore VMFS se realizan a nivel de LUN, por tanto, en un momento dado, solo una máquina virtual puede acceder a la LUN en algunas tareas, con Hardware Offloaded Locking el bloqueo se realiza a nivel de bloque no de LUN. Esto nos permitirá aumentar el número de máquinas virtuales por datastore en nuestros diseños y disminuirá el tiempo de creación de datastores VMFS y NFS.
Thin Provisioning Stun evita que nos quedemos sin espacio en disco poniendo la máquina virtual en pausa hasta que consigamos disco. Esta situación, puede llegar a ocurrir si aprovisionamos en modo Thin y necesitamos más disco del que tenemos.
VAAI está activado por defecto en vSphere™ ESXi 5 a partir de la licencia Enterprise. Por supuesto, ni que decir tiene, la cabina de datos también tiene que soportar VAAI.
Para terminar con VAAI, una cabina con soporte VAAI y con el uso de thin provisioning ofrece la posibilidad de “reclamar” espacio cuando una máquina virtual es migrada a un datastore diferente con Storage vMotion o cuando el disco virtual es borrado.
Con el vSphere Client y desde la pestaña Storage Views podrás ver información muy interesante relativa a tus datastores VMFS, como por ejemplo:
El estado del algoritmo de multipathing para tus datastores
El espacio usado en tus datastores
Y un montón de otras cosas interesantes relativas a la configuración de tu datastore ¿Cómo mostrar más información de los volúmenes o datastores en vSphere™ 5?
Para obtener más información sobre los DataStores VMFS, como, por ejemplo, el estado del Multipathing actual y el espacio usado, selecciona la pestaña Storage Views.
El Runtime Name, para un dispositivo de almacenamiento en FC, equivale al nombre de la ruta del dispositivo en formato vmhba:C:T:L, donde C es Controler, T es Target y L es LUN.
El seudo name vmhba32 es el nombre que el VMkernel utiliza para los iniciadores software iSCSI. Recuerda que tanto el adaptador de software iSCSI como el adaptador dependent hardware iSCSI necesitan un port group tipo VMkernel para ser configurados del todo. Si usas una adaptador de tipo dependent hardware iSCSI para tu conexión iSCSI, es posible que el rendimiento de las tarjetas de red asociadas con este adaptador muestren muy poca actividad, incluso cuando el trafico via iSCSI es muy alto. Esto es consecuencia directa de que el trafico iSCSI hace un bypass del trafico normal de red y no se verá reportado por las
herramientas internas de monitorización de red del servidor ESXi (esxtop).
Asimismo, para obtener un mejor rendimiento iSCSI con adaptadores de tipodependent hardware iSCSI es una mejor práctica habilitar la opción de flow control.
Flow control está habilitado por defecto en todas las tarjetas de red en los servidores ESXi 5. Es posible deshabilitar flow control. Puedes ver el KB 1013413 en el siguiente enlace para deshabilitarlo: http://kb.vmware.com/kb/1013413
Presentando LUNs FC a los servidores vSphere 5™
La buena noticia es que el módulo para el adaptador de fibra es reconocido por
elVMkernel durante la secuencia de arranque, con lo que si el Zoning está bien configurado, no deberías de tener mayor problema en ver tus LUNs de FC.
Para acceder a las nuevas LUNs, no es necesario hacer un reboot del servidor ESXi. Las nuevas LUNs serán descubiertas por los servidores ESXi siempre que se realice
un Rescan en cada servidor vSphere ESXi o desde el objeto de inventario DataCenter. Adicionalmente, cuando elimines un DataStore de un servidor ESXi, realiza un Rescanen todos los servidores ESXi para actualizar los cambios. Desde la versión vSphere™ 4.x, se incluye una opción de Rescan centralizado para buscar cambios en la granja de SAN de todos los servidores ESXi incluidos en el mismo objeto de inventario de tipo DataCenter.
QLA es el nombre corto del módulo del driver Linux para una HBA del proveedorQlogic. LPFC es el nombre corto del módulo del driver Linux para una HBA del proveedorEmulex. Recuerda que las HBAs tiene un número identificativo único y global llamado World Wide Nane, también conocido con el acrónimo WWN.
Como en la parte de configuración de red, es una mejor práctica que antes de configurar la parte de SAN en tu entorno virtual, hables con tu administrador de SAN sobre tus necesidades en cuanto a la capa de almacenamiento se refiere.
Algunos de los temas que deberías de tener claro y preguntar a tu administrador de SAN antes de implementar el almacenamiento en tu entorno virtual incluyen lo siguiente: El tamaño necesario de tus LUNs
I/O bandwidth que requieren tus aplicaciones virtualizadas
El tamaño de la cache, zoning y LUN masking de tu fabric de SAN
La configuración del multipathing en ESXi, es decir, si es una cabina activa/activa, activa/pasiva o activa/activa con soporte ALUA.
Aviso: El número máximo de HBAs soportadas en vSphere™ ESXi 5 ha aumentado de 8 tarjetas HBAs por host ESXi 5 a 16. Asimismo, el número máximo de targets por HBA de FC es de 256.
¿Cómo se configura el iniciador software iSCSI en vSphere™ 5?
Una SAN de tipo iSCSI consiste de una cabina de datos con conexiones tipo iSCSI (red de 1Gb o 10Gb Ethernet) la cual contiene una o más LUNs así como SPs. La comunicación entre el host ESXi y la cabina iSCSI se establece a través de una red Ethernet de datos.
iSCSI usa el IQN (iSCSI Qualify Name), donde el primer número representa el año, mes y la organización que registró el dominio: iqn.2006-01.com.openfiler:volume.vmware. Este nombre IQN no puede superar los 255 caracteres.
Los servidores ESXi vienen configurados, por defecto, con un iniciador de software iSCSI. Este iniciador iSCSI transmite comandos SCSI por una red de datos. El target, es decir, la cabina de datos iSCSI, recibe estos comandos SCSI y el SP los procesa.
Es posible tener múltiples iniciadores y targets en nuestra red iSCSI. Y a diferencia en las versiones anteriores, en vSphere™ 5, el iniciador de software no viene instalado por defecto. Puedes ver el video tutorial de la instalación del iniciador de software iSCSI en vSphere™ ESXi en un video tutorial de nuestro canal de YouTube llamado:VMware vSphere 5.0 en entornos SAN iSCSI
VMware vSphere™ 5 utiliza CHAP (Challenge Handshake Authentication Protocol) para ofrecer lo que se denomina Initiator authentication. Es una buena práctica aislar la red de gestión, de la red iSCSI y de la red donde están conectadas todas las máquinas virtuales. Debido al hecho de que las redes IPs que usan la tecnología iSCSI no encriptan los datos trasmitidos, es aconsejable para configuraciones iSCSI, activar la funcionalidad de CHAP que se incluye tanto en la cabina (target) como en el iniciador de software iSCSI en el servidor ESXi.
Si configuras el servidor ESXi con la opción de CHAP para acceder a una LUN iSCSI y después deshabilitas CHAP en el servidor, el acceso a las LUNs iSCSI no se verá afectado hasta que no se reinicie el servidor ESX/ESXi o la cabina iSCSI. Puedes activar el CHAP en la pestaña General después de seleccionar las propiedades del iniciador de software iSCSI.
Aviso: No olvides abrir el puerto 3260 en el firewall del servidor ESXi. El protocolo iSCSI utiliza este puerto para la comunicación entre la cabina iSCSI (Target) y el servidor ESX (iSCSI initiator).
