Configurar iLO en ESXi

Es probable que en más de una ocasión debamos configurar la iLO en un servidor ESXi para acceder a la DCUI y no tengamos posibilidad de reiniciar el host. También es probable que queramos hacerlo para hacer desaparecer el molesto mensaje de:

 Host Baseboard Management Controller Status

Para ello descargaremos la configuración actual en un archivo XML, el cual editaremos y volveremos a cargar desde el hipervisor.

Lo primero es habilitar el acceso SSH y la Shell en el servidor ESXi desde el apartado de Security Profile:

Establecemos una conexión SSH con el host y ejecutamos el comando ./hponcfg -w ilo.xml desde /opt/hp/tools

Esto generara un archivo XML con la configuración actual que debemos descargar vía WinSCP o copiar a un datastore para su posterior descarga desde el cliente vSphere. En este caso se copia con el comando:

cp ilo.xml /vmfs/volumes/505cc73c-97433240-05b9-ac162d71eaec #

Y se descarga mediante el cliente tradicional:

Editamos el archivo con Notepad++ o similar y añadimos la información necesaria:

Volvemos a subir el archivo XML al datastore y lo copiamos a su emplazamiento original en /opt/hp/tools con el comando:

/vmfs/volumes/505cc73c-97433240-05b9-ac162d71eaec # cp ilo.xml /opt/hp/tools

Para hacer efectiva la configuración la cargaremos con el comando:

 /opt/hp/tools # ./hponcfg -f ilo.xml

Y con esto queda configurada la iLO y desaparecido el error, (si es que lo teníamos).

 

Recordar volver a iniciar los servicios de host SSH y ESX Shell.

Quick stats on hostname is not up-to-date

 Al actualizar o instalar la version ESXi 5.5 de VMware me ha encontrado en mas de una ocasion con el error:

Quick stats on <nombre_de_servidor>  is not up-to-date

Para solucionarlo hay que agregar los siguientes parametros en las opciones avanzadas de vCenter.

vpxd.quickStats.HostStatsCheck	false
vpxd.quickStats.ConfigIssues	false

y reiniciar el servicio de vCenter.

8·2 | MSA P2000 G2/3 iSCSI Multipath

Aunque a fecha de hoy no existe documentación oficial de Best Practices de configuración de Multipathing para la MSA P2000 en entornos VMware, existen multitud de opiniones y foros al respecto. De todas las configuraciones que he probado me quedo con la que explicare a continuación, es la que mejor resultados me ha dado en las pruebas de failover y de rendimiento.

Se asume que para esta configuración disponemos de dos controladoras en la MSA asi como 2 switches para iSCSI o 2 VLANs para separar las dos subredes que configuraremos. También se asume que disponemos de 2 NICs en cada host ESXi para uso con iSCSI.

Si el servidor dispone de 2 tarjetas Ethernet (Placa base y PCI, por ejemplo) intentaremos dedicar una NIC de cada una de ellas por temas de redundancia de hardware.

Cableado:

Conectaremos cada NIC a un switch dedicado para iSCSI, por ejemplo, por cada host la NIC1 al switch1 y la NIC2 al switch2. Asimismo conectaremos el puerto 1 de la controladora A de la MSA al switch1 y el puerto 2 de la controladora A al switch2. Lo mismo con la controladora B. Ver el diagrama.

ESXi Networking:

9·3 | IOMeter

Cuando instalamos una cabina de almacenamiento, ya sea NAS o SAN, es importante conocer el rendimiento de la misma, especialmente si disponemos de discos de diferentes tecnologías y niveles RAID necesitaremos saber cual es el mas apropiado para cada caso, no necesita el mismo rendimiento en almacenamiento un servidor con bases de datos SQL o de Exchange que un Gateway de Terminal Server por ejemplo. Ademas, sin esta información se hace difícil la gestión y el crecimiento. Con IOMeter podemos identificar donde están los cuellos de botella de nuestro sistema de almacenamiento. En alguna ocasión he tenido que testear un disco RDM, desconectarlo y presentárselo a un servidor físico para volverlo a testear y determinar si tengo algún problema en el host (Controladora inadecuada, firmware inadecuada, switch con problemas, Storage Adapter mal configurado, etc..).

Además de medir el rendimiento de I/O disponemos de un componente llamado Dynamo que genera carga de trabajo (Workload) simulando diferentes escenarios de forma granular.

Siempre que sea posible, intentar que el host que contenga la VM que generar los test no contenga mas VMs en marcha para conseguir un resultado mas preciso.

Instalación:

La instalación de IOMeter no tiene ningún secreto, tan solo ha de ejecutarse en la VM sobre la que lanzaremos los tests.

Existen multitud de variables en la configuración de los tests con IOMeter, yo acostumbro a utilizar la siguiente de forma genérica para medir el numero de R/W MB/s secuenciales, IOPS totales, IOPS de escritura, IOPS de lectura y latencia en ms.

A no ser que queramos testear el rendimiento de un disco local de la VM crearemos un disco RDM o VMDK en el datastore o LUN que queramos medir.

Disk Targets:

Crear 4 workers por disco de destino a testear, especificar el disco de destino creado.

El campo sectores "sectors", indica el tamaño de archivo para el test, con 4GB. sera suficiente para Datastores locales, no obstante si vamos a testear una NAS o SAN con caches de controladoras de 4,8 o mas GB. el tamaño de archivo debera ser mayor. Como se ve en la configuración siguiente suelo usar archivos de 32GB. que acustumbran a superar el tamaño de cache de la mayoria de cabinas.

Si lo que queremos es testear subsistemas de discos, caches, etc. usaremos valores mas pequeños para que el workload no llege al disco.

Worker 1:

Maximum Disk Size:  67.108.864 sectores (32 GB para que no quepa todo en la memoria)
Starting Disk Sector: 1
# of Outstanding I/Os: 32

Worker 2:

Maximum Disk Size: 67.108.864 sectores (32 GB para que no quepa todo en la memoria)
Starting Disk Sector: 2
# of Outstanding I/Os: 32

Worker 3:

Maximum Disk Size: 67.108.864 sectores (32 GB para que no quepa todo en la memoria)
Starting Disk Sector: 3
# of Outstanding I/Os: 32

Worker 4:

Maximum Disk Size: 67.108.864 sectores (32 GB para que no quepa todo en la memoria)
Starting Disk Sector: 4
# of Outstanding I/Os: 32

Access Specifications:

Crear dos reglas de Access Specifications para todos los Workers al 50% cada una.

Para testear almacenamiento en entornos virtualizados se recomiendan bloques de 8k.

8K;100% read;0% random (lectura).
8K;0% read;0% random(escritura).

Test Setup:

Ramp Up Time: 30 s
Run Time: 3 minutes

Y por ultimo, en results Display modificaremos la frecuencia de actualización a 1 segundo:

Update Frequency: 1 s

8·3 | QNap NFS

Configurar un Datastore NFS

En varias ocasiones he utilizado dispositivos NAS QNap como destino de copias o laboratorios, incluso en alguna ocasión los he montado para servidores en producción (Desarrollo) con resultados óptimos, personalmente pienso que son unos dispositivos muy buenos en relación calidad/precio.

En este caso vamos a utilizar un QNap TS-419+ para montar un Datastore NFS

Vamos a la practica, para comenzar prepararemos los requisitos del QNap, estos son:

-Habilitar el servicio NFS.

-Desactivar la cache de escritura para EXT4

Iremos a Herramientas de Administración > Configuración de Hardware y desmarcaremos "habilitar caché de escritura (solo EXT4)".

Imagen. Configuración de Hardware.

Seguidamente iremos a Servicio de Red > Servicio NFS y habilitamos el servicio.

Imagen. Servicio NFS.

Bien, ahora crearemos el Share, según el modelo de QNap y la cantidad de discos de que disponga podremos montar uno o mas volúmenes y dedicar uno para NFS, en este caso tengo 4 discos en un único volumen RAID5 y en el tengo Shares y LUNs, por lo tanto no tendré disponible la opción de donde ubicar el Share NFS.


Configuración de Share:

Vamos a Administración de Derechos de Acceso > Carpeta de Recursos Compartidos y crearemos un nuevo Recurso compartido de red.

Imagen. Crear un recurso compartido de red.

Imagen. Siguiente.

En el siguiente paso especificaremos un nombre para el Share y el volumen de destino (en este caso solo tengo uno).

Deberemos ocultar la carpeta, no obstante seguiría siendo visible al acceder a Mis Sitios de red en el caso que la QNap estuviera en la red LAN con el peligro que eso conlleva, en este caso, al ser un dispositivo dedicado para Backup y Laboratorios ira en una LAN dedicada para NFS e iSCSI.

Especificaremos que no bloquee el archivo, no procede para NFS y asignaremos una ruta de forma automática o manualmente, en este caso dejare que la asigne de forma automática.

Imagen. Configuración de el Share

A continuación marcaremos que solo el usuario Admin tiene privilegios de acceso total a el Share y los usuarios invitados no podrán acceder.

Imagen. Privilegios de acceso.

Imagen. Confirmación de la configuración.

Con esto ya tenemos el Share exportado, hemos configurado los privilegios de acceso de usuario, ahora vamos a configurar los de NFS.

 

Imagen. Configuración Completa.

Volvemos a Administración de Derechos de Acceso > Carpeta de Recursos Compartidos y abrimos el apartado de Control de acceso NFS haciendo clic en el icono NFS.

 

Imagen. Control de acceso NFS

Especificaremos como derecho de acceso NFS Sin Limite y especificaremos las IPs que podrán acceder, estas IPs son las que configuraremos mas adelante en los puertos VMKernel de los hosts y conectaremos sus NICs a la VLAN de Backup. En este caso especifico 3 IPs ya que tengo 3 hosts ESXi en el Cluster.

Imagen. Control de Acceso NFS


Configuración del Networking (QNap):

QNap permite realizar agregacion de puertos (802.3ad) y Load Balancing (port bonding “Balance-alb”), para ello deberemos configurarlo en el dispositivo y asignar dos NICs a cada puerto VMKernel, en este caso vamos a configurar un unico puerto LAN de la QNap.
Configuración del Networking (VMware):

Ahora configuraremos el networking de los hosts, para ello iremos al vCenter, a la administración del primer host a configurar.
 
Una vez en el iremos al apartado Networking.

 Imagen. Networking ESXi

Crearemos un nuevo Networking, un nuevo vSwitch y un puerto del tipo VMKernel. En un puerto VMKernel podemos configurar iSCSI, NFS, vMotion y Management, en este caso lo usaremos para NFS.

 

 

Imagen. Puerto VMKernel.

 



Le asignaremos la NIC que hemos designado para NFS, en este caso he conectado la NIC para NFS de cada host a un Switch físico Gigabit y a su vez a el puerto de la QNap, no obstante podríamos conectarlo a un Switch LAN y separar el trafico mediante una VLAN.

 

 

 

Imagen. Creación de un nuevo vSwitch y asignación de la NIC.

 

Especificamos una etiqueta para el Port Group, en este caso NFS Storage, si se va a utilizar una VLAN para separar el trafico la especificaremos, también podríamos habilitar la administración en este Port Group a modo de "puerta trasera" pero en este caso no sera necesario.

 

 

   



Imagen. Propiedades del Port Group.

Configuraremos la IP designada para este host, es una de las que hemos definido en la configuración de acceso NFS del Share. También la mascara de subred.

 

Imagen. Configuración IP

Con esto ya tenemos el networking. Ahora habra que repetir el proceso con el resto de hosts si es que disponemos de ellos, lógicamente cada uno con su IP.

 

 

Imagen. Networking configurado


Creación del Datastore NFS:

Llegados a este punto vamos a montar el Datastore, desde el apartado Configuration de los hosts vamos a Storage y lo añadimos con Add Storage..

 

Imagen. Apartado Datastores

Seleccionamos Network File Systems (NFS).

 

 
Imagen. Tipo de almacenamiento.
 
Comprobamos la ruta que ha asignado automaticamente al Share en las propiedades del mismo.

Imagen. Ruta de Acceso al Share
 
Y la especificamos junto a la dirección IP de la QNap y un nombre para el Datastore.

 

Imagen. Propiedades del Datastore.

 

Ya tenemos el Datastore NFS montado.

Heartbeating: 7 | Errores comunes

Heartbeating: 7 | Errores comunes

7·2 | Credenciales SSO

En ocasiones me he encontrado al actualizar vCenter a la versión 5.1 que no he podido acceder a vCenter con las credenciales del dominio, esto se debe a que Sign-On and Discovery no ha podido descubrir el directorio activo durante la instalación de SSO, seguramente por un problema de resolución DNS, conectividad o otros.

Para solucionar esto tendremos que crear un Identity Source nuevo y vincular SSO con el directorio activo de la organización, para ello seguiremos los siguientes pasos.


1 Accederemos a vCenter mediante vSphere Web Client con las credenciales de admin@system-domain y la contraseña especificada el la instalación.

Imagen. Validacion mediante vSphere Web Client

Nota. si no lo tenemos instalado, deberemos instalar el plug-in de vSphere Web client desde esta misma pantalla

2 En el panel izquierdo ir a Sign-On and Discovery > Configuration

 

Imagen. Configuracion de Sign-On and Discovery

3 Añadir un nuevo Identity Source para vincular Single Sign-On con el directorio activo

 

Imagen. Configuración del Identity Source.

 

4 Una vez creado marcarlo como Identity Source (dominio) por defecto.

 

 

Imagen. Dominios por defecto

 

5 Desplazar el dominio al principio de la lista de consulta o donde proceda.

 

 

Imagen. Vista de orden de dominios por defecto.

 

6 Ahora ya es posible agregar permisos en vCenter a usuarios del dominio desde Add Permissions.

 

 

 

 



7 | Errores comunes

7·1 | CPU/MMU Virtualization

En ocasiones, al realizar una conversión P2V de una maquina Windows 2000 nos podemos encontrar que el procesador se mantiene al 100% de uso. Existen varias posibles soluciones para este problema.

Lo primera a probar seria la siguiente, no siempre me ha funcionado:

Molificación de HAL de procesador:


1 Ejecutar un snapshot de la VM afectada.

2 Acceder al SO de la VM y modificar el HAL a uniprocesador, desde el Administrador de dispositivos > Equipo > cambiar controlador a uniprocesador.

3 Detener la VM y dejarle una única vCPU.

4 Iniciar la VM y reiniciarla si asi lo pidiese

5 Comprobar si el rendimiento es óptimo (no al 100%), debería serlo. De ser así:

6 Iniciar la VM e instalar el controlador multiprocesador. Parar la VM, asignarle una segunda vCPU, iniciar la VM y comprobar rendimiento. Si es óptimo, repetir el proceso añadiendo hasta 4 vCPUs o 8 dependiendo de la versión de Windows 2000 y licencia de VMware, se recomienda no usar mas de 4 vCPUs en sistemas operativos obsoletos.

Me he encontrado frecuentemente con este problema al convertir maquinas físicas Windows 2000 con HAL uniprocesador. Aun así puede funcionar en algunos casos con equipos físicos con HAL multiprocesador.

También seria aconsejable en la VM convertida marcar en el administrador de dispositivos "Ver dispositivos ocultos" y eliminar todos los heredados del servidor físico (los que están en gris claro), como agentes de HP, tarjetas de red, etc.. (snapshot por delante).


Molificación del CPU/MMU Virtualization:

El segundo procedimiento que en ocasiones me ha funcionado es modificar las instrucciones de acceso a memoria de la CPU, por defecto este valor estará en automático pero no siempre el elegido es el mas adecuado.

Imagen. Molificación del CPU/MMU Virtualization.

1·1·4 | NPIV - N Port ID

La tecnología NPIV también conocida como Node Port ID Virtualization, es una capacidad especifica de SAN FC, y es una extensión del estándar de canal de fibra existente, permite la creación de WWNs virtuales en las VMs, de este modo es posible el uso de zonas como si de servidores físicos se trataran.

El uso de NPIV mejora sustancialmente la seguridad, evitando accesos indeseados cuando presentamos una LUN a los servidores ESXi, por ejemplo, para crear un disco RDM. Es posible crear una zona SAN para acceso a una única VM, ante el uso de vMotion no hay requisitos especiales para asegurar que el resto de nodos tienen acceso a la LUN, la VM tiene acceso y es suficiente para que el host de destino herede la capacidad de acceso a el.
 
Para habilitar NPIV en el entorno se requieren varios componentes, los switches SAN deben soportar NPIV, cualquier Switch Brocade con un Fabric OS v5.1.0 o posterior soportara NPIV.

Las HBAs deben soportar NPIV, actualmente cualquier HBA Emulex o QLogic lo soporta.

El uso de NPIV es aplicable únicamente a discos RDM.

vMotion esta soportado para VMs con varios RDMs NPIV, eso si, los punteros a los RDMs deben estar en el mismo datastore.

Storage vMotion no esta soportado con RDMs NPIV.

NPIV es completamente transparente para los arrays de disco, por lo que los sistemas de almacenamiento en sí no requieren una configuración especial.

Bien, vamos a la práctica, conectaremos una LUN a una VM mediante NPIV, dispongo de una cabina HP MSA 2000 G2, HBAs QLogic ISP2532 de 8GB en los hosts y Switches SAN Brocade.

 Preparación del entorno:

Se asume que ya están correctamente configuradas las zonas entre las HBAs de los hosts ESXi y las controladoras de la MSA. De no ser asi, crearlas y comprobar la conectividad.

También se asume que están creados los Hosts con los WWNs pertinentes para las HBAs de los ESXis, de no ser así, también hay que crearlos.

1 En primer lugar crearemos una LUN, en adelante (NPIV_HB) y la presentaremos a los hosts ESXi con el mismo LUN ID para todas las HBAs.

2 En los switches SAN comprobaremos que NPIV este habilitado en los puertos correspondientes, en este caso los que van a las HBAs de los hosts ESXi 5.1
 

 

Imagen. Vista del estado de NPIV en los puertos pertinentes mediante GUI.

Realizamos una conexion SSH al Switch SAN y con el comando portcfgshow seguido del numero de puerto revisamos el estado del mismo.

portcfgshow 0

Comprobar que NPIV Capability este en ON


De no estar habilitado NPIV en los switchs los habilitaremos para cada puerto con el comando

portcfgnpivport --enable seguido del puerto.

Imagen. Activación de NPIV en cada puerto

3 A continuación identificaremos las HBAs en los hosts ESXi, para ello accederemos mediante una sesión SSH hasta la ruta:

/proc/scsi #

con ls identificaremos el folder de las HBAs, en este caso qla2xxx hace referencia a una QLogic ISP2532, una vez dentro nuevamente con ls nos dará las instancias de las HBAs.

Imagen. instancias de las HBA Qlogic del host

Con el comando cat seguido del identificador nos proporcionara la información necesaria sobre la HBA, entre otras cosas si soporta NPIV (NPIV Supported : Yes). y con una revisión rápida para cada instancia comprobaremos el tipo y el estado de conectividad de cada (puerto).
 

Imagen. información sobre una de las instancias de la HBA.

4 A continuación mediante el cliente vSpere pararemos la VM a configurar NPIV y la editaremos.

En la pestaña Options Desmarcaremos la opción Temporarily Disable NPIV for this virtual machine y marcaremos que genere un WWNN y un WWPN nuevos y aceptaremos para que aplique y los genere.

Imagen. Vista de Fibre Channel virtual WWNs.

3 Volvemos a acceder a la configuración de la VM y aparecerán los WWNN/WWPNs

Imagen: WWN y WWPN generados
 

Para comprobar que realmente ha creado y linkado el VPort, abrir una sesión SSH al servidor ESXi y ejecutar el siguiente comando, esxcli storage core adapter list, en la descripción aparecerán con () Virtual y en Link State el estado del mismo.

 

 

 

Imagen. Lista de adaptadores

 

4 Ahora le conectaremos el disco RDM mediante la LUN previamente presentada, especificaremos que use una controladora SCSI separado para la VM (en este caso SCSI (1:0)).

Imagen. Usar un canal SCSi separado para el RDM.

La VM se mantiene apagada en todo momento.

Configuración de zonas para NPIV:

La configuración de zonas para el uso de NPIV tiene una serie de requisitos a tener en cuenta:
-Las HBAs fisicas deben tener acceso a todas las LUNs a las que accedan las VMs.

-El modo de presentación del host (HBA) debe ser igual para cualquier VM que tenga habilitado NPIV a traves de esta HBA.

-Las LUNs deben presentarse con el mismo LUN ID tanto a las HBAs físicas como virtuales.

-El LUN Masking de la cabina debe incluir tanto WWNs fisicos como WWNs virtuales.

Bien, vamos a la configuración de las zonas:

1 Creamos un Alias para la VM NPIVTest

Imagen. Alias nuevo

2 Agregamos el WWPN y el WWNN generado por vCenter para la VM.

 

Imagen. WWPN de la VM

 

Imagen. Vista del Alias creado


3 Crear una zona y agregar el Alias de la VM (NPIVTest) y la cabina de almacenamiento.

 

Imagen. Zona nueva.

 

Imagen. Miembros de la zona.

4 Agregar la zona creada a la configuración de zona e Inicializarla

Imagen. Miembros de configuracion de zona.

Configuración en cabina:


Esta parte varia en cada marca y modelo de cabina de almacenamiento, ire incluyendo la configuración para cada cabina en que lo vaya implementando, por ahora vamos con la HP MSA P2000 G2.

 

1 Acceder a la cabina de almacenamiento, en el apartado de hosts se autodescubrira un nuevo Host con el WWPN generado (vPort ID) en la VM, renombrarlo adecuadamente, en este caso (NPIVTest). De no aparecer se tendrá que agregar el host manualmente.

 

 

 

Imagen. Agregar host (NPIVTest) con el World Wide Port Name WWPN generado en la VM.

2 Ir a la LUN presentada a la VM y presentársela a el nuevo host creado (NPIVTest), asegurarse que el LUN ID es el mismo que se utilizo para presentarla a las HBAs.

 

Imagen. Presentar la LUN perteneciente al RDM al host (NPIVTest).
 

Nota. Es muy importante que el LUN ID sea el mismo para los dos hosts.

 

 

Imagen. LUN presentado a las HBAs físicas y el WWPN de la VM.

Iniciaremos la VM (NPIVTest) y ya lo tenemos configurado.