Deshacer ELM (Enhanced Linked Mode) en PSC Embedded Windows 6.x (Topología No Soportada)

En nuestra oficio como consultores de TI, siempre estamos buscando alinear al cliente con las mejores prácticas del fabricante. Es por esta razón que cuando encontramos clientes con arquitecturas extrañas y fuera de soporte, es nuestro deber realizar el mejor esfuerzo por corregir y traer devuelta al cliente en la dirección correcta.

Pues bien, esta es la historia de un cliente que implementó sus vCenter Servers basados en Windows (version 6.0.x) con Platform Services Controller (PSC) Embebido en una configuración de Enhanced Linked Mode, creando sin saberlo una topología NO Soportada por VMware (KB2108548).

image

clip_image001[7]

Desafortunadamente, este error puede ser creado ya que en el momento de la implementación el asistente de configuración no realiza una validación de la topología y es responsabilidad del consultor tener en cuenta las mejores prácticas.

Recordemos que Enhanced Linked Mode con PSC Embedded comenzó a ser soportado desde la versión 6.5U2 y para la versión VCSA (vCenter Server Appliance), no para Windows (Ver). Y es ahí donde nos preguntamos: ¿Que hacia un ELM configurado en esos vCenters 6.0?. “¡De todo se ve en la viña del señor!”. A continuación explicaremos el procedimiento (no soportado), para romper el ELM y poder realizar una actualización hacia la version 6.5.

Nota 1: Al ser una topología no soportada, el procedimiento tampoco esta soportado. Sin embargo, es una manera de deshacer el Enhanced Linked Mode de forma segura, pero deberá aplicarlo bajo su propio riesgo.

En este punto podrá surgir la pregunta, ¿Para qué querría separar el ELM si esta funcionando?, las respuestas son básicamente tres:

1. No es una buena práctica, por lo cual no se recomienda configurar en la version 6.0 de vCenter Server basa en Windows.

2. Es una topología No Soportada y si tienes un problema con los vCenter Server, no hay mucho que el fabricante pueda hacer si abrimos un caso con ellos.

3. Al intentar realizar una actualización hacia la versión 6.5.x o posteriores, obtendrá el siguiente error: “You have embedded vCenter configuration with VMware Single Sign On linked to some other node. Unlink single sign on before to upgrading“. Y es esta la razón, por la cual estamos escribiendo este post.

Como podríamos evidenciar, el error es generado en los primeros pasos de la actualización, por lo cual no quedará mas remedio que corregir el error antes de intentar de nuevo la actualización.

image

Nota 2: Para aclarar un poco las topologías antes de iniciar con el procedimiento, mostraré cual es la topología actual No Soportada y cual será la Topología después del procedimiento.

Topología Actual (No Soportada)

image

Topología futura (Soportada)

image

ANTES DE COMENZAR

Existen diferentes caminos para migrar hacia una topología soportada, entre los cuales podríamos tener:

1. Implementar un Platform Services Controller (PSC) Externo en cada sitio, conectados al mismo dominio de Single Sign On, para después re apuntar los vCenters de cada sitio hacia sus correspondientes nuevos PSC Externos KB2113917. Para este caso deberá validar qué soluciones VMware (vRealize Operation, vSphere Replication, Site Recovery Manager, etc)  tiene conectadas al PSC Embedded de los vCenter, ya que tendrá que garantizar el trafico desde dichas soluciones hacia el nuevo direccionamiento de los PSC Externos. Podría necesitar creación nuevas reglas en el FW que no se tenían configuradas.

2. Si su vCenter cuenta con los prerrequisitos para migrar a la versión vCenter Server Appliance (Ver), llevarlo a una versión superior o igual a VCSA 6.5U2, garantizaría la misma Topología pero esta vez soportada por VMware (Ver). De manera que intentar realizar una actualización y migración no suena descabellado.

image

Nota 3: Si ninguno de los caminos presentados anteriormente es una opción viable, o por el contrario es un requerimiento de la organización deshacer el ELM, continúe con el procedimiento.

PROCEDIMIENTO PARA DESHACER ELM

Para nuestro caso de laboratorio hemos construido la misma Topología del cliente (No soportada) con las maquinas virtuales vm06 para el vCenter Server del Sitio-1y vm07 para el vCenter Server del Sitio-2.

1. Tome un snapshot de las VMs asociadas a los vCenter Server del Sitio-1 y Sitio-2, con el fin de tener un mecanismo de rollback si algo va mal. Si tiene soluciones VMware adicionales conectadas a los vCenter, tome un snapshot para esas maquinas también.

2. Abra un navegador web con dos pestañas nuevas, en una inicie sesión hacia el vSphere Web Client de vCenter Server del Sitio-1 (https://vm06.lab.local/vsphere-client/?csp) y en la otra inicie sesión hacia el vSphere Web Client de vCenter Server del Sitio-2 (https://vm07.lab.local/vsphere-client/?csp). Verifique que el estado de los servicios en Home|Administration|System Configuration es saludable para los dos nodos.

3. Apague uno de los vCenter Server. En este caso, comenzaremos realizando el procedimiento en el vCenter Server del Sitio-2 (vm07) por lo cual apagaremos de manera controlada la VM de vCenter Server del Sitio-1 (vm06). Una vez apagado el servidor, al refrescar la vista del vSphere Web Client de Sitio-2, podrá observar que ahora aparece una notificación indicándole que no se puede conectar al nodo https://vm06.lab.local:443/sdk (esto es normal).

image

4. Inicie conexión RDP hacia el servidor Windows Server en donde esta instalado el vCenter Server del Sitio-2 (vm07).

5. Abra una interface de línea comandos CMD como administrador y ejecute los siguientes comando:

cd C:\Program Files\VMware\vCenter Server\bin\
cmsso-util unregister --node-pnid Platform_Services_Controller_System_Name_Site1 --username administrator@your_domain_name --passwd vCenter_Single_Sign_On_password

Ejemplo:
cmsso-util unregister --node-pnid vm06.lab.local --username administrator@vsphere.local --passwd VMware1!

image

Nota 4: La salida de comando debería ser Success.

6. Cierre sesión sobre el vSphere Web Client de vCenter del Sitio-2 que esta encendido (vm07) y luego inicie sesión nuevamente. Ahora puede observar que en Home|Administration|System Configuration, aparece un único nodo y la notificación de la parte superior ya no aparece.

image

6. Encienda la máquina de vCenter Server del Sitio-1 (vm06), y espere que inicialice el servicio de vSphere Web Client para poder iniciar sesión.

image

8. Inicie Sesión en el vSphere Web Client del vCenter Sitio-1 (vm06) aproximadamente 10 min después de haber encendido la VM. Vaya hasta Home|Administration|System Configuration y podrá observar que este nodo aún continua viendo la conexión ELM. Esto es normal ya que al haberlo apagado no se dio cuenta del cambio, pero de haber ejecutado el comando con la VM encendida el PSC de este vCenter estaría muerto. Así que continuemos!

image

9.  Apague de manera controlada ahora la máquina del vCenter Server del Sitio-2 (vm07). Ya que el procedimiento se realizará ahora sobre la VM de vCenter Server del Sitio-1 (vm06), que aún ve la configuración ELM (aunque ya no esta replicando en el dominio de SSO). Una vez apagado el servidor, al refrescar la vista del vSphere Web Client del vCenter del Sitio-1 (vm06), nuevamente podrá observar una notificación en la parte superior indicándole que no se puede conectar ahora al nodo https://vm07.lab.local:443/sdk (esto nuevamente es normal).

image

10. Inicie conexión RDP hacia el servidor Windows Server en donde esta instalado el vCenter Server del Sitio-1 (vm06).

11. Abra una interface de línea comandos CMD como administrador y ejecute los siguientes comando:

cd C:\Program Files\VMware\vCenter Server\bin\
cmsso-util unregister --node-pnid Platform_Services_Controller_System_Name_Site2 --username administrator@your_domain_name --passwd vCenter_Single_Sign_On_password

Ejemplo:
cmsso-util unregister --node-pnid vm07.lab.local --username administrator@vsphere.local --passwd VMware1!

image

Nota 5: La salida de comando debería ser Success.

12. Cierre sesión sobre el vSphere Web Client de vCenter del Sitio-1 que esta encendido (vm06) y luego inicie sesión nuevamente. Ahora puede observar que en Home|Administration|System Configuration, aparece un único nodo y la notificación de la parte superior ya no aparece.

image

13. Encienda el vCenter del Sitio-2 (vm07), y espere que inicialice el servicio de vSphere Web Client para poder iniciar sesión.

image

14. Inicie Sesión en el vSphere Web Client del vCenter del Sitio-2 (vm07) aproximadamente 10 min después de haber encendido la VM. Vaya hasta Home|Administration|System Configuration y podrá observar que el nodo ya ha sido separado y no muestra ninguna dependencia con el vCenter Server del Sitio-1.

image

De igual forma el vCenter Server del Sitio-1 (vm06) no muestra ninguna dependencia con el vCenter Server del Sitio-2.

image

15. (Opcional) Si ahora ejecutamos nuevamente el asistente de actualización sobre cualquiera de los vCenter Server Windows, no obtendrá el error mencionado anteriormente y la actualización se desarrollará de manera satisfactoria. Es así como podemos pasar de una Topología No Soportada a una Topología Soportada.

image

image

CONCLUSIÓN

El KB2106736, indica explícitamente que el comando cmsso no deber ser utilizado para deshacer una configuración ELM, por esta razón este procedimiento no esta soportado. Por otra parte, existe una alternativa si se realizan los pasos como se indicaron.

Si por alguna razón ejecuta el comando con las VMs de ambos sitios encendidas, el resultado será que el vCenter donde ejecutó el comando quedará separado y funcionando. Sin embargo, la suerte para el otro vCenter no será la misma ya que el PSC del otro vCenter tendrá afectación y su vCenter asociado no funcionará mas. Y obtendrá un error como el siguiente:

image

Configurando Direct Attached Storage (DAS) en Cisco UCS (Unified Computing System)

Algunos de nosotros en el rol de consultor, hemos tenido que realizar implementaciones con diferentes tipos de hardware, HP, DELL, Huawei, Intel; pero no es sino hasta que nos encontramos con una infraestructura basada en Cisco Unified Computing System (UCS), con su UCS Manager, FI (Fabric Interconnect), Switches, chasis, blades, IO Modules, que nuestra primera impresión es decir, “Esto es otro mundo!”.

Pues bien, este es uno de los casos en donde la primera impresión no cuenta demasiado, y mas que complejo este tipo de infraestructuras resulta ser muy robusta y a la vez versátil. Alguno de sus beneficios se resumen en la siguiente lista. (Para ver mas información).

  • Aumento de la productividad del personal de TI y la agilidad empresarial a través del aprovisionamiento justo a tiempo y la igualdad de soporte para ambientes virtualizados y bare-metal.
  • TCO (Total Cost of Ownership) reducido a nivel de plataforma, sitio y organización a través de la
    consolidación de infraestructura.
  • Un sistema unificado e integrado que se gestiona, repara y prueba como un
    todo.
  • Un ecosistema de gestión integral que admite completo
    aprovisionamiento y administración de infraestructura que puede hacer a sus instancias de Cisco UCS cualquier cosa, desde un motor de aplicaciones empresariales sin formato hasta un entorno multicloud contenedorizado.
  • Escalabilidad mediante la capacidad de administrar hasta 10,000 servidores con Cisco
    UCS Central Software y escalar el ancho de banda de I/O para satisfacer la demanda.
  • Estándares abiertos de la industria respaldados por un ecosistema partner de industrias lideres.
  • Un sistema que se adapta para satisfacer las futuras necesidades del Centro de Datos como, potencia de computo, memoria y ancho de banda de E/S, etc.

Dicho lo anterior, veamos como configurar de manera sencilla una arquitectura DAS para poder presentar nuestro almacenamiento a los servidores UCS, sin tener que conectarlos a Switches de SAN y realizar las configuración a nivel de Zoning que esto conlleva.

En versiones de UCS anteriores a 2.1, se tenía la opción de usar DAS con UCS. Sin embargo, se necesitaba un Switch SAN conectado a los FI (Fabric Interconnect) para que el Switch pudiera enviar la base de datos de zonas a los FI. Es decir, la plataforma UCS no podía construir una base de datos de zonas por si misma. Por suerte, desde la version 2.1 en adelante UCS ahora tiene la capacidad de construir su propia base de datos de zonas de manera automática. Por lo tanto podemos tener DAS (Direct Attached Storage) con UCS sin la necesidad de un Switch SAN para crear la configuración de zonificación. Esta topología luce de la siguiente forma:

image

PROCEDIMIENTO DE CONFIGURACIÓN

1. Aunque suene obvio el primer paso es realizar las conexiones entre el almacenamiento y las interfaces de los FI.

2. Configurar FI en FC Switch Mode

  1. Inicie sesión en el USC Manager y navegue hasta Equipment.
  2. Expanda Fabric Interconnects.
  3. Click en Fabric Interconnect A.
  4. En la pestaña General click en Set FC Switching Mode
  5. image

  6. Repita los pasos 2(2-4) para el Fabric B.

3. Crear VSAN Requerido

Nota 1: VSAN (Virtual Storage Area Network) es una red de área de almacenamiento virtual. Las VSAN proporcionan aislamiento entre dispositivos que están físicamente conectados a la misma estructura. Con VSAN se pueden crear múltiples SAN lógicas sobre una infraestructura física común y se pueden diseñar múltiples VSAN con diferentes topologías.

Nota 2: Storage VSANs deberían ser creados solo bajo Storage Cloud y no debería ser permitido  en los enlaces ascendentes FC, si es que los hay.

  1. En el UCSM, navegue hasta la pestaña SAN.
  2. Expanda Storage Cloud.
  3. Expanda Fabric A.
  4. Click derecho en VSANs, y seleccione Create Storage VSAN.
  5. Ingrese el nombre de la VSAN.
  6. Seleccione Enabled para FC Zoning.
  7. Seleccione Fabric A.
  8. Ingrese el VSAN ID y un VLAN ID para Fiber Channel over Ethernet (FCoE) para el Fabric A. Asegúrese que el FCoE VLAN ID es un VLAN ID que no esté actualmente usado en la red.
  9. image

  10. Repita los pasos 3(2-8) para el Fabric B.

4.  Configure el rol del puerto en UCS

En este punto vamos a seleccionar los puertos de los FI conectados al almacenamiento para configurarlos como FC Storage Ports.

  1. En el UCSM, navegue hasta la pestaña Equipment.
  2. Expanda Fabric Interconnects.
  3. Expanda Fabric Interconnect A.
  4. Click derecho sobre el puerto conectado al almacenamiento, y seleccione Configure as FC Storage Port.
  5. Seleccione la VSAN correcta para este puerto desde la lista desplegable.
  6. Repita los pasos 4(1-5) para el Fabric B.
  7. image

    image

    Si el puerto está configurado correctamente y está en arriba en el almacenamiento, el puerto de almacenamiento FC en UCS debería estar en línea.

5. Confirme que la WWPN del Storage Port haya iniciado sesión en el Fabric

  1. Inicie sesión a través del shell seguro (SSH) o establezca una conexión Telnet a la IP virtual (VIP) del UCS.
  2. Ingrese el comando
    connect nxos {a | b}
    , donde a | b representa FI A o FI B.
  3. Ingrese el comando
    show flogi database vsan vsan_ID
    , donde vsan ID es el identificador del VSAN. En este ejemplo el identificador es 600.
  4. La siguiente imagen muestra la salida de estos dos comandos, tanto para el Fabric A como para el B y en ellas se observa que la WWPN del puerto de almacenamiento ahora está conectada a la VSAN 600. Asegúrese de confirmar el inicio de sesión de los puerto de almacenamiento en ambos Fabrics.

    image

6. Cree Storage Connection Policy.

  1. En el UCSM, navegue hasta la pestaña SAN.
  2. Expanda Policies, expanda Root, click derecho en Storage Connection Policies, y seleccione Create Storage Connection Policy.
  3. La ventana Create Storage Connection Policy se abre para permitirle definir las WWPN Target del almacenamiento y los detalles del Fabric.

  4. Ingrese el Nombre del Storage Connection Policy.
  5. Seleccione un tipo de Zoning desde las tres opciones:
  6. None: Use esta opción cuando no tenga zonas creadas en el FI, pero tenga zonas usadas para trafico ascendente del FC switch para una VSAN particular.
    Single Initiator Single Target: Use esta opción cuando solo tenga un puerto de almacenamiento conectado a un Fabric.
    Single Initiator Multiple Targets: Use esta opción cuando tenga más de un puerto de almacenamiento conectado a una Fabric. (Para el ejemplo tenemos dos conexiones hacia el almacenamiento desde cada Fabric).

  7. Click en el signo mas (+)Add, para abrir la ventana que permite crear el FC Target Endpoint.
  8. Ingrese la WWPN del FC target (almacenamiento).
  9. Click en Path para el Fabric A.
  10. Seleccione el VSAN ID correspondiente desde la lista desplegable.
  11. Haga click en OK para guardar los cambio y repita los pasos e-h para agregar más WWPNs del almacenamiento (en el caso de haber seleccionado Single Initiator Multiple Targets).
  12. image

    image

  13. Repita los pasos 6(5-9) pero esta vez seleccionando el Path en el Fabric B y agregando las WWNP Target del almacenamiento conectadas al Fabric B.
  14. image

    image

7. Edite el Service Profile.

Si ya tenemos hosts con Service Profiles asignados, solo necesitamos editarlos de la siguiente forma:

  1. En el UCSM navegue hasta la pestaña Servers.
  2. Expanda Servers, expanda Service Profiles, expanda root y seleccione el Service Profile asociado al host al cual desea conectar el almacenamiento.
  3. Nota 3: Si todos los Service Profile de los hosts pertenecen a un mismo Service Profile Template, puede optar por modificar el Template y aplicar los cambios a todos los Service Perfiles desplegados desde esa plantilla.

  4. Haga click en la pestaña Storage del panel central y luego click en vHBA Initiator Groups.
  5. Click en (+) Add, Elija un nombre para el grupo de iniciadores y una descripción.
  6. En Select vHBA Initiators, seleccione la vHBA conectada al Fabric A.
  7. En Storage Connection Policy, seleccione la política creada en el paso anterior para el Fabric A y click en OK.
  8. image

    image

  9. Repita los pasos 7(4-6) seleccionando esta vez la vHBA conectada al Fabric B y la Storage Connection Policy creada para ese Fabric.
  10. image

    image

  11. Como resultado obtendrá una vista como la siguiente.
  12. image

  13. Expanda ahora el Service Profile, expanda vHBAs y seleccione una de las vHBAs del Service Profile (ejemplo vHBA vHBA0).
  14. Haga click en la pestaña General del panel central y luego en la propiedad VSAN seleccione desde la lista desplegable la VSAN correspondiente al Fabric al cual se encuentra conectada (para el ejemplo Test_VSAN_Fabric_A, creada anteriormente).
  15. image

  16. Repita los paso 7(9-10) para la demás vHBAs configuradas en el Service Profile teniendo en cuenta seleccionar en la propiedad VSAN, la correspondiente de acuerdo a la conexión física hacia el Fabric.
  17. clip_image001

8. Verifique la creación de las Zonas

En este punto las zonas deben haber sido creadas de manera automática por los FI y para verificarlas solo siga los siguientes pasos:

  1. En el UCSM navegue hasta la pestaña Servers.
  2. Expanda Servers, expanda Service Profiles, expanda root y seleccione el Service Profile asociado al host al cual presentó el almacenamiento.
  3. Click en la pestaña FC Zone, y verifique la creación de las Zonas de manera automática.
  4. image

Adicionalmente, puede también verificar las Zonas desde CLI de la siguiente forma:

  1. Inicie sesión a través del shell seguro (SSH) a la IP virtual (VIP) del UCS.
  2. Ingrese el comando
    connect nxos {a | b}
    , donde a | b representa FI A o FI B.
  3. Ingrese el comando
show zoneset active vsan vsan_ID>

, donde vsan ID es el identificador para el VSAN. (En este ejemplo, el identificador VSAN es 600).

La siguiente imagen es un ejemplo de la salida de estos dos comandos.

image

Por último, solo debemos realizar rescan a las HBAs del host para visualizar las LUNs presentadas desde el almacenamiento. En este caso dado que es un host ESXi lo haremos de la siguiente forma:

  1. Inicie sesión al vCenter con un usuario administrador.
  2. Navegue hasta el host ESXi y haga click en Configure y luego en Rescan Storage…
  3. Haga click en cada una de las vmhbas y podrá observar que ahora en la pestaña Devices se muestran las LUNs presentadas. Para el ejemplo, solo una LUN de 512GB.
  4. image

Automatizando configuración de Dump Collector en ESXi 6.x

De manera similar a como funciona Syslog Collector el cual recolecta todos los archivos Logs de los hosts ESXi, Dump Collector recopila el estados de la memoria VMkernel (Core Dumps) que generan los hosts cuando el sistema encuentra una falla crítica y se produce la conocida PSOD (Purple Screen of Death) o pantalla de la muerte.

Antes de comenzar con la configuración, debemos saber que durante la instalación del hipervisor ESXi se crean dos particiones (Diagnostic Patition) encargadas de almacenar estos archivos, una Primaria de (110 MB) y una Secundaria de (2.5 GB). Sin embargo, es recomendable configurar un servidor remoto (Log Server) para transferir estos archivos a través de la red con el fin de tener una mayor retención de los mismos y poder realizar un mejor proceso de seguimiento y troubleshooting en la detección de la causa raíz de la falla. Para mayor información acerca del diseño de particiones de ESXi haga click Aquí.

Por suerte sino contamos con un Log Server en nuestra infraestructura a dónde dirigir estos Dumps, podemos utilizar la partición incluida en el vCenter Server Appliance dedicada para este propósito.  Para mayor información de los servicios incluidos en vCenter Server consulte Componentes y Servicios de vCenter Server.

image

(Opcional) CONFIGURAR SERVICIO DUMP COLLECTOR EN VCENTER SERVER APPLIANCE

Si vamos a utilizar la partición del vCenter para almacenar los Core Dumps, debemos tener en cuenta que el servicio Dump Collector no viene activo por defecto por lo que será necesario iniciarlo y dejarlo en modo automático para que se inicie con el Sistema Operativo. Para esto sigamos los siguientes pasos:

1. Inicie sesión en el vCenter Server Appliance (VCSA) desde el vSphere Web Client con un usuario que cuente con permisos de administrador y luego vaya a Home > Administration > System Configuration > Services.

2. En el panel de servicios del lado izquierdo haga click en el servicio VMware vSphere ESXi Dump Collector.

3. En el panel central haga click en Actions > Edit Startup Type…,seleccione Automatic y click en OK.

image

4. (Opcional) Haga click en la pestaña Manage para  verificar el tamaño asignado al repositorio. Si desea cambiarlo haga click en el botón Edit… El valor por defecto es 2 y el máximo 10.

image

5. Haga click en icono Start the Service para iniciar el servicio

clip_image001

CONFIGURAR ESXi DUMP COLLECTOR

Si ya configuramos el servicio de Dump Collector en el VCSA o si por el contrario tenemos un Log Server disponible en la infraestructura, podremos iniciar con la configuración en cada uno de los ESXi como sigue, utilizando como es costumbre la línea de comandos ESXCLI o PowerCLI para automatizar la configuración en todos los hosts del vCenter.

ESXCLI

La utilidad de línea de comando esxcli puede ser utilizada en la consola del host ESXi, en el vCLI  (vSphere CLI) o en el vMA (vSphere Management Assistant).

1. Inicie una sesión SSH al host ESXi que desea configurar ESXi Dump Collector

2. Configure el ESXi con la dirección IP del servidor remoto que será utilizado como Dump Collector ejecutando la siguiente línea de comandos:

esxcli system coredump network set --interface-name vmkX --server-ip xx.xx.xx.xx --server-port 6500

Nota 1: Como mejor practica se recomienda utilizar un puerto VMkernel diferente al de gestión (vmk0). Sin embargo, para ambientes de laboratorio utilizaremos el mismo.

Nota 2: La dirección IP del servidor remoto puede ser IPv4 o IPv6 ya que ambas son soportadas. Para el ejemplo la dirección IP será la dirección del VCSA.

3. Habilite ESXi Dump Collector ejecutando la siguiente línea:

esxcli system coredump network set --enable true

4. (Opcional) Verifique que ESXi Dump Collector esté configurado correctamente ejecutando la siguiente línea de comandos:

esxcli system coredump network check

image

PowerCLI

Con el fin de automatizar la tarea en todos los hosts del vCenter, podemos apoyarnos en la herramienta PowerCLI ejecutando script que se muestra a continuación:

1. Instale PowerCLI sino lo tiene instalado, con ayuda del siguiente video haciendo click aquí.

2. Inicie sesión hacia el vCenter desde el panel de script de PowerShell ISE ejecutando los siguientes cmdlets y espere a que le solicite usuario y contraseña:

Connect-VIServer FQDN_IP_vCenterServer

image

3. Ejecute el siguiente script para configurar ESXi Dump Collector en todos los hosts del vCenter

#Configurar ESXi Dump Collector

$MyLogServer= “IP_FQDN_Remote_Server”

Foreach ($hostx in (Get-VMHost)){
    Write-Host "Configuring Dump Collenctor in $hostx" -ForegroundColor Yellow
    $esxcli = Get-EsxCli -vmhost $hostx
    $esxcli.system.coredump.network.set($null, “vmk0”, $null, $MyLogServer, 6500)
    $esxcli.system.coredump.network.set($true)
    $esxcli.system.coredump.network.get()
}

4. Verifique la configuración ejecutando el siguiente script

#Check ESXi Dump Collector

Foreach ($hostx in (Get-VMHost)){
    Write-Host "Checking dump collector in host $hostx" -ForegroundColor Yellow
    $esxcli = Get-EsxCli -vmhost $hostx
    $esxcli.system.coredump.network.get()
}

image

 

VERIFICACIÓN DE LA TRANSFERENCIA DE CORE DUMPS

Una manera de verificar que los archivos Dump están siendo enviados de manera correcta al servidor remoto configurado, es generar un crash o PSOD en el servidor de manera controlada como sigue:

1. Abra la consola remota del servidor (iLO, CIMC, iDRAC, etc.) en el que desea simular la falla, para monitorear el comportamiento del servidor.

2. Inicie una sesión SSH en el host ESXi y ejecute la siguiente línea de comandos:

vsish -e set /reliability/crashMe/Panic 1

3. Espere que se genere el archivo dump y reinicie el servidor.

clip_image001[1]

4. Verifique en el servidor remoto configurado, la existencia del archivo zdump generado.

5. (Opcional) Si utilizó VCSA como repositorio de los archivos Dump inicie sesión SSH al vCenter Server, active la interfaz shell digitando Shell en la pantalla y verifique el log netdumper.log ejecutando la siguiente línea de comandos para verificar que el archivo haya sido transferido y validar su ruta de destino:

cat /var/log/vmware/netdumper/netdumper.log

image

Nota 3: El nombre del archivo generado contiene el nombre zdump y para el ejemplo con Dump Collector configurado en el VCSA, los archivos son alojados en la siguiente ruta /var/core/netdumps/ffff/AA/BB/CC/DD o lo que es lo mismo /storage/core/netdumps/ffff/AA/BB/CC/DD donde AA.BB.CC.DD indican los octetos de la dirección IP del host ESXi.

Silenciar alarmas de health check en vSAN

En esta ocasión se presenta un procedimiento fácil y rápido para silenciar las alarmas generadas por el health check de vSAN, que puede ser utilizado en ambientes Nested (ESXi virtualizados) o en ambientes de laboratorio propiamente dichos. Esta puede ser una opción para omitir algunas de la verificaciones debido a que no siempre contamos con las condiciones de hardware, firmware y drivers apropiados para implementar la solución; ni mucho menos contamos con vSAN ReadyNodes disponibles para una POC (Proof of Concept).

¡CUIDADO! En ningún momento se recomienda este procedimiento en ambientes vSAN productivos ya que todos los componentes de hardware, drivers y firmware deben coincidir con la Guía de Compatibilidad de VSAN indicada para los nodos que conforman la solución.

Antes de iniciar el procedimiento comentemos un poco acerca de RVC (Ruby vSphere Console). Es una consola de línea de comando para VMware vSphere y Virtual Center. Ruby vSphere Console es basada en la popular interface RbVmomi Ruby para vSphere API. RbVmomi fue creada para reducir drásticamente la cantidad de codificación requerida para realizar tareas rutinarias, así como aumentar la eficacia de la ejecución de tareas, al tiempo que permite la máxima potencia de la API cuando es necesario. RVC se encuentra incluida en el vCenter Server Appliance (VCSA) y la versión de Windows de vCenter Server, y se ha convirtiendo en una de las principales herramientas para administrar y solucionar problemas de entornos Virtual SAN (vSAN).

RVC tiene muchas de las capacidades que se esperan de una interfaz de línea de comandos.

  • Finalización de tabulación
  • Comodines
  • Marcas
  • Modo Ruby
  • Modo Python
  • Introspección VMODL
  • Conexiones múltiples

Extensibilidad

  • Guiones de Ruby de una sola línea
  • Casos de uso y ventajas de RVC
  • Funcionalidad Virtual SAN cubierta
  • Configuración de VSAN y políticas de almacenamiento
  • Comandos de monitorización / resolución de problemas
  • Monitoreo del desempeño a través de VSAN Observer

Ventajas

  • Más información detallada sobre Virtual SAN vSphere Web Client
  • Vista de grupo de VSAN mientras que esxcli solo puede ofrecer una perspectiva de servidor
  • Operaciones masivas a través de comodines
  • Funciona directamente contra ESX host, incluso si VC no funciona

NOTA: Para mayor información acerca de la utilización de RVC aplicada a vSAN podemos consultar la guía oficial VMware Ruby vSphere Console Command Reference for Virtual SAN.

 

PROCEDIMIENTO

1. Tenga presente que existe una lista de checks o validaciones que están disponibles para ser configurados y se encuentran consignados en la siguiente tabla. De manera que primero debemos verificar si la alarma que muestra el monitor de salud de vSAN se encuentra en éste listado.

Descripción Check ID
Cloud Health
Controller utility is installed on host vendortoolpresence
Controller with pass-through and RAID disks mixedmode
Customer experience improvement program (CEIP) vsancloudhealthceipexception
Disks usage on storage controller diskusage
Online health connectivity vsancloudhealthconnectionexception
vSAN and VMFS datastores on a Dell H730 controller with the lsi_mr3 driver mixedmodeh730
vSAN configuration for LSI-3108 based controller h730
vSAN max component size smalldiskstest
Cluster
Advanced vSAN configuration in sync advcfgsync
Deduplication and compression configuration consistency physdiskdedupconfig
Deduplication and compression usage health physdiskdedupusage
Disk format version upgradelowerhosts
ESXi vSAN Health service installation healtheaminstall
Resync operations throttling resynclimit
Software version compatibility upgradesoftware
Time is synchronized across hosts and VC timedrift
vSAN CLOMD liveness clomdliveness
vSAN Disk Balance diskbalance
vSAN Health Service up-to-date healthversion
vSAN cluster configuration consistency consistentconfig
vSphere cluster members match vSAN cluster members clustermembership
Data
vSAN VM health vmhealth
vSAN object health objecthealth
Encryption
CPU AES-NI is enabled on hosts hostcpuaesni
vCenter and all hosts are connected to Key Management Servers kmsconnection
Hardware compatibility
Controller disk group mode is VMware certified controllerdiskmode
Controller driver is VMware certified controllerdriver
Controller firmware is VMware certified controllerfirmware
Controller is VMware certified for ESXi release controllerreleasesupport
Host issues retrieving hardware info hclhostbadstate
SCSI controller is VMware certified controlleronhcl
vSAN HCL DB Auto Update autohclupdate
vSAN HCL DB up-to-date hcldbuptodate
Limits
After 1 additional host failure limit1hf
Current cluster situation limit0hf
Host component limit nodecomponentlimit
Network
Active multicast connectivity check multicastdeepdive
All hosts have a vSAN vmknic configured vsanvmknic
All hosts have matching multicast settings multicastsettings
All hosts have matching subnets matchingsubnet
Hosts disconnected from VC hostdisconnected
Hosts with connectivity issues hostconnectivity
Multicast assessment based on other checks multicastsuspected
Network latency check hostlatencycheck
vMotion: Basic (unicast) connectivity check vmotionpingsmall
vMotion: MTU check (ping with large packet size) vmotionpinglarge
vSAN cluster partition clusterpartition
vSAN: Basic (unicast) connectivity check smallping
vSAN: MTU check (ping with large packet size) largeping
Performance service
All hosts contributing stats hostsmissing
Performance data collection collection
Performance service status perfsvcstatus
Stats DB object statsdb
Stats DB object conflicts renameddirs
Stats master election masterexist
Verbose mode verbosemode
Physical disk
Component limit health physdiskcomplimithealth
Component metadata health componentmetadata
Congestion physdiskcongestion
Disk capacity physdiskcapacity
Memory pools (heaps) lsomheap
Memory pools (slabs) lsomslab
Metadata health physdiskmetadata
Overall disks health physdiskoverall
Physical disk health retrieval issues physdiskhostissues
Software state health physdisksoftware
Stretched cluster
Invalid preferred fault domain on witness host witnesspreferredfaultdomaininvalid
Invalid unicast agent hostwithinvalidunicastagent
No disk claimed on witness host witnesswithnodiskmapping
Preferred fault domain unset witnesspreferredfaultdomainnotexist
Site latency health siteconnectivity
Unexpected number of fault domains clusterwithouttwodatafaultdomains
Unicast agent configuration inconsistent clusterwithmultipleunicastagents
Unicast agent not configured hostunicastagentunset
Unsupported host version hostwithnostretchedclustersupport
Witness host fault domain misconfigured witnessfaultdomaininvalid
Witness host not found clusterwithoutonewitnesshost
Witness host within vCenter cluster witnessinsidevccluster
vSAN Build Recommendation
vSAN Build Recommendation Engine Health vumconfig
vSAN build recommendation vumrecommendation
vSAN iSCSI target service
Home object iscsihomeobjectstatustest
Network configuration iscsiservicenetworktest
Service runtime status iscsiservicerunningtest

2. Inicie sesión SSH en el vCenter Server Appliance y conéctese al Ruby vSphere Console (RVC) ejecutando el siguiente comando (sin habilitar el Shell)

rvc username@localhost

Ejemplo:

Command> rvc administrator@vsphere.local@localhost

image

3. Ingrese el password del usuario administrator@vsphere.local

clip_image001[11]

Se utilizarán los siguientes comandos RVC para verificar y silenciar las alarmas

  • vsan.health.silent_health_check_status
  • vsan.health.silent_health_check_configure

4. Verifique el estado de las alertas con el primer comando, para el cual se debe conocer la ruta de cluster a analizar. Puede apoyarse de los comando cd y ls para navegar hasta encontrar la ruta correcta del cluster vSAN.

image

Ejemplo:

vsan.health.silent_health_check_status /localhost/Datacenter-Lab01/computers/vSAN-Cluster

image

5. Desde el vSphere Web Client navegue hasta el NombredelCluster|vSAN|Health para identificar el nombre de la alerta que se desea silenciar, teniendo en cuenta por supuesto que la misma no sea de impacto para la operación normal de la solución, de lo contrario deberá realizarse una adecuada investigación y solución del problema.

clip_image001

Para este caso al ser un ambiente de laboratorio virtualizado, se tiene la alerta SCSI controller is VMware certified que nos indica acerca de la incompatibilidad de la controladora de discos para el uso de vSAN, que no podemos solucionar debido a que la controladora es virtual; por lo tanto puede ser ignorada o silenciada. (¡Recuerde! Esto acción no debe ser realizada en ambientes productivos).

6. En la salida del comando anterior se muestra el mismo listado de Health Checks disponibles para configurar y su estado actual. De manera que para silenciar la verificación SCSI controller is VMware certified, se debe utilizar su correspondiente identificador o Check ID controlleronhcl

image

7. Ahora solo queda ejecutar el comando de configuración vsan.health.silent_health_check_configure de la siguiente manera para silenciar la alarma

vsan.health.silent_health_check_configure /localhost/Datacenter-Lab01/computers/vSAN-Cluster –a ‘controlleronhcl’

image

Utilice los parámetros de configuración disponibles, de acuerdo a su necesidad.

-a –add-checks= Agregar verificación a la lista silenciosa, uso: -a [Health Check Id].
-r –remove-cheques= Eliminar verificación de la lista silenciosa, uso: -r [Health Check Id]. Para restaurar la lista de verificación silenciosa, utilizando ‘-r all’
-i –interactive-add Usa el modo interactivo para agregar verificación a la lista silenciosa
-n –interactive-remove Usa el modo interactivo para eliminar las verificaciones de la lista silenciosa
-h –help Muestra este mensaje

8. Regrese al vSphere Web Client y haga click en Retest en el Health monitor de vSAN para validar el cambio y podrá observar que la alerta aparece ahora como Skipped y no como Warning.

clip_image001[5]