Exportar reglas del Firewall Distribuido de NSX-T con vRNI

Muchas veces bien sea desde el lado de implementación o desde la operación, nos encontramos con el problema de no poder exportar las reglas del Firewall Distribuido de NSX-T en las versiones 3.0 y anteriores. Esta característica ha sido recientemente adicionada a la versión 3.1 (ver aquí), de manera que si tenemos una version anterior nos vemos obligados a recurrir a APIs para poder extraer la configuración de estas políticas y reglas.

Por suerte, por lo general cuando hablamos de Micro-Segmentación casi siempre tenemos a la mano la herramienta vRealize Network Insight con lo cual esta tarea se resume a una consulta y a un export.

PROCEDIMIENTO

En la caja de búsqueda de vRNI realice la siguiente consulta: NSX-T Firewall rule

En el filtro NSX Manager, seleccione el NSX Manager de interés. Si solo tiene un NSX Manager conectado a vRNI omita el paso.

clip_image001

Haga clic en More Option y después clic en Export as CSV.

clip_image002

Clic en Clear All para eliminar todas las propiedades y poder ajustar las que son de nuestro interés.

clip_image003

Clic en ADD PROPERTIES y agregue las siguientes propiedades:

Nota: Puede utilizar el buscador para encontrar las propiedades rapidamente.

  • Section Name
  • Rule ID
  • Configure Source
  • Configure Destination
  • Service
  • Port Range Display
  • Applied to
  • Action
  • Direction
clip_image004

Activamos el check Save changes to: Create a new template, para crea una plantilla con las nueve (9) propiedades seleccionadas.

Por ultimo, en el campo Name asignamos un nombre a la plantilla y hacemos clic en EXPORT.

Seleccionamos el destino y nombre para el archivo .csv y clic en Save.

clip_image005

La próxima vez que desee exportar nuevamente las reglas únicamente tendrá que seleccionar en Property Template la plantilla guardada y automáticamente se cargaran las propiedades asociadas.

clip_image006

Una vez hemos exportado la información simplemente lo importamos en Excel para poder visualizarla como filas y columnas

clip_image007
clip_image008
clip_image009

(Opcional) Una vez la tenemos en este formato, recomiendo crear una tabla dinámica para organizar mejor la información de forma similar a como la vemos en el Firewall Distribuido.

Para esto, active el Diseño de tabla dinámica clásica antes de seleccionar la información de las columnas.

clip_image010

Organice las filas en el siguiente orden y seleccione la opción No mostrar subtotales en el diseño de la tabla dinámica

  • Section Name
  • Rule ID
  • Configure Source
  • Configure Destination
  • Service
  • Port Range Display
  • Applied to
  • Action
  • Direction
clip_image011

Por ultimo, utilice la función buscar y remplazar para eliminar la palabra “default.” que antepone cada security group en la información exportada. De esta manera podrá visualizar mejor la información presentada.

clip_image012

Actualizando vRealize Network Insight 5.x (Online Update)

Antes de comenzar a actualizar la solución es recomendable considerar los siguientes puntos:

  • Después de la actualización, vRealize Network Insight tarda entre 12 y 24 horas en procesar los datos que estaban en proceso durante la operación de actualización y reflejarlos en la interfaz de usuario.
  • vRealize Network Insight no admite rollback ni downgrade del producto por lo que se debe realizar una copia de seguridad antes de continuar con la actualización. Para obtener más información sobre el proceso de backup y restauración ver aquí.
  • En un entorno de clúster, debe realizar la operación de actualización solo en el nodo Platform 1.
  • Después de actualizar a vRealize Network Insight 6.x, algunos de los ID de reglas de firewall pueden cambiar a los nuevos ID devueltos por la API de VMware Cloud on AWS 1.9. Si existe alguna regla de firewall de VMware Cloud on AWS 1.8 adjunta a los flujos:
    • Las reglas de firewall de VMware Cloud on AWS 1.9 correctas o respectivas se adjuntarían inmediatamente después de la actualización para todos los flujos activos.
    • Las reglas de firewall se referirían a reglas inexistentes para los flujos cuyo período de inactividad es mayor a 24 horas antes de actualizar la versión 1.8 a 1.9.
  • La solución debería tener acceso a internet para la descarga de los paquetes necesarios de manera automática. Este acceso a internet puede ser directo o a través de un web proxy.
  • La opción Online Update deberá estar habilitada en Settings | Infrastructure and Support | Overview and Update y deberá existir un paquete disponible para instalar.
  • Asegúrese de tener soporte activo para la solución vRealize Network Insight antes de actualizar.
  • Si va a realizar un Upgrade (cambio a una nueva versión) entonces deberá realizar el upgrade también de la licencia en my.vmware.com.

PROCEDIMIENTO

1. Genere un Snapshot para cada una de la maquinas virtuales que conforman la solución (nodos Platform y Proxies) o asegúrese de tener un backup de cada una de ellas en caso de que algo salga mal.

2. Inicie sesión en vRealize Network Insight como administrador y vaya a Settings | Infrastructure and Support | Overview and Update para revisar la existencia de actualizaciones disponibles.

image

3. Verifique el estado de salud de la infraestructura sea Good.

image

4. Haga clic en el enlace View details frente a la nueva versión de paquete que aparece disponible.

image

5. Revise el numero de compilación de la nueva versión y lea atentamente la información de la ventana emergente. (Opcional) haga clic en View release note para conocer mas acerca de la nueva versión.

image

6. Haga clic en CONTINUE para iniciar el proceso de actualización y espere pacientemente a que todos los pasos finalicen con éxito.

image

7. Cuando aparezca el botón DONE en la parte inferior, sabrá que el proceso de actualización ha terminado. Y podrá hacer clic sobre el para cerrar la ventana emergente e ir a la ventana de inicio de sesión.

image

8. Inicie sesión en la solución vRealize Network Insight como administrador y revise las notas What is New de bienvenida, para familiarizarse con las bondades de la nueva versión. Cierre la ventana emergente haciendo clic en la X.

image

9. Una vez cierre la ventana anterior, aparecerá una notificación para ingresar la licencia asociada a la nueva versión.

Nota: Si únicamente se hace un Update dentro de la misma versión no tendrá que hacer este paso.

image

10. Haga clic en PROCEED para ir automáticamente a la sección License and Usage e ingrese la nueva llave que previamente debió haber actualizado desde el portal de my.vmware.com.

image

11. Verifique que el estado de salud para cada uno de los componentes de la infraestructura continúe en Good, en la sección Settings | Infrastructure and Support | Overview and Updates.

image

12. Por ultimo pero no menos importante, verifique que las fuentes de datos continúen recolectando datos.

image

Identificar el líder en un cluster de NSX-T Manager 3.x

Antes de explicar el sencillo procedimiento para identificar el líder en un clúster, recordemos que un clúster esta formado por un grupo de tres nodos NSX Manager para alta disponibilidad y escalabilidad y que cada NSX Manager appliance tiene incluido los roles de Policy, Manager y Controller.

Podemos construir un clúster de NSX-T Manager de las siguientes dos maneras.

NSX Management Cluster con Dirección IP Virtual

El NSX Management cluster garantiza la alta disponibilidad y es configurado de la siguiente forma:

  • Todos los manager deben estar en la misma subnet.
  • Un nodo Manager es elegido como líder.
  • La IP Virtual del Cluster es unida al manager líder.
  • El trafico NO es balanceado a través de los Managers mientras usa VIP.
  • La IP Virtual del cluster es usada para el trafico destinado a los nodos NSX Manager.
  • El trafico destinado a cualquier Nodo de Transporte usa la IP de management del nodo.
  • Una única dirección IP virtual es usada por los clientes de acceso API y GUI.
image

Cuando se envía una solicitud de usuario a la dirección IP virtual, el manager activo (el líder que tiene la dirección IP virtual adjunta) responde a la solicitud. Si el líder falla los dos managers restantes eligen un nuevo líder y este responderá a las solicitudes enviadas a esa dirección IP virtual.

Las solicitudes de equilibrio de carga y el tráfico no se equilibran entre los administradores mientras se usa VIP.

Si el nodo líder que posee VIP falla, se elige un nuevo líder que envía una solicitud GARP para tomar posesión de la VIP y entonces el nuevo nodo líder recibe todas las nuevas solicitudes de API y UI de los usuarios.

NSX Management Cluster con Load Balancer

Para este caso, un balanceador de carga es el encargado de proveer alta disponibilidad al cluster:

  • Todos los nodos son activos.
  • GUI y API son disponibles en todos los managers.
  • El trafico a la IP Virtual es balanceado a múltiples nodos manager.
  • Los nodos manager pueden estar en diferente subnet.
image

Una vez explicado lo anterior, podría surgir la pregunta -¿Para que querría saber quien es el líder? – pues bien, cuando tenemos un problema con la solución se hace indispensable saber cual de los nodos esta recibiendo las solicitudes de manera que podamos acceder a el a través de la linea de comandos para realizar el debido troubleshooting.

También es útil para la fase de pruebas post implementación (VMware verification workbook) en donde debemos testear la alta disponibilidad y garantizar el correcto funcionamiento del cluster.

PROCEDIMIENTO

1. Inicie sesión SSH hacia la IP Virtual del Cluster con el usuario admin y el password definido en la instalación . Sino tiene habilitado el servicio SSH puede hacer login desde la Consola de la VM en el vCenter.

2. Ejecute el comando get cluster status verbose y observaremos que para cada función del manager tenemos un líder seleccionado.

image

3. Ahora solo debemos buscar debajo de cada función del manager, el líder asociado para cada uno de los servicios de la misma.

En la siguiente grafica se muestra como líder del servicio api para la función HTTPS, al miembro con UUID terminado en 3d60144055b5 que corresponde al FQDN srvctrvmnsxp02.bivcloud.local.

image

Nota: Algunas funciones tendrán mas de un servicio, por lo que tendrán un líder asociado para cada uno.

image

Limpiando particiones en discos para configuración de vSAN

En esta oportunidad explicaremos como abordar una situación en la cual al intentar crear el cluster vSAN de forma manual a través del asistente de configuración, no tenemos disponibles algunos discos que deberían aparecer para la creación de los Disk Groups. En ese momento nos preguntaremos ¿Por qué no aparecen todos los discos disponibles?, pues bien lo más probable es que el o los discos que no aparecen listados para ser Claimed por vSAN no están vacíos y deban ser formateados para poderlos liberar.

Es aquí donde nos podríamos encontrar con un error común que puede convertirse en un dolor de cabeza sino conocemos su causa raíz. El error básicamente se produce al intentar ejecutar la acción Erase Partitions en la configuración del host en el apartado Configure->Storage->Storage Devices, como se muestra en la siguiente imagen.

image

Al hacer clic sobre la opción anterior nos mostrará un resumen de las particiones con las que cuenta este disco y razón por la cual no esta disponible para el asistente de configuración de VSAN.

image

Al hacer click sobre el botón OK,  en la mayoría de los casos, las particiones serán eliminadas y el disco quedará disponible para vSAN. Una forma rápida de verificarlo es que al hacer nuevamente clic sobre Erase Partition, no debería listar ninguna partición y el asistente de configuración de vSAN debería ahora listar el o los discos.

¿Y SI FALLA?…

Es ahora cuando aparece el problema ¿Que hacemos si esta tarea falla y nos muestra el siguiente error: “Cannot change the host configuration”? Primero que todo ¡calma, calma!, no tenemos que ir a ninguna línea de comandos a intentar limpiar estas particiones, la solución es mucho más sencilla que eso.

image

Nota 1: Para las versiones de ESXi anteriores a 7,0, scratch partition es un espacio temporal que se configura automáticamente durante la instalación o el primer arranque de un host ESXi. El instalador de ESXi crea una partición FAT16 de 4GB en el dispositivo de destino durante la instalación si hay suficiente espacio y si el dispositivo se considera local. Esta partición no es creada cuando el hipervisor se instala en tarjetas SD o unidades flash USB.

Nota 2: Si no existe espacio temporal persistente disponible en el disco local o la partición no es creada (en el caso de SD, Flash USB), ESXi almacenará estos datos temporales en la memoria RAM. Esto puede ser problemático en situaciones con poca memoria, pero no es fundamental para el funcionamiento de ESXi.

Explicado lo anterior, el problema pudo haberse producido si ese disco o discos, en algún momento fueron formateados como Datastore (VMFS), y esto hace que el hipervisor configure ese datastore como su mejor candidato para ubicar el Scratch Partition (Partición creada para almacenar la salida de vm-support necesaria para el soporte de VMware).

Por esta razón, la solución a este problema se basa en cambiar la configuración asociada a la opción avanzada del hipervisor ScratchConfig.ConfiguredScratchLocation, que probablemente estará apuntando al datastore local que en algún momento se configuró en dicho disco.

SOLUCIÓN

1. Si ya tiene vCenter instalado navegue en el inventario hasta el Host –> Configure –> Advanced System Settings. Clic en Edit… y en el filtro escriba ScratchConfig.ConfiguredScratchLocation.

image

2. Sino tiene instalado un vCenter aún, inicie sesión en el Host Client del host en cuestión (en cualquier navegador web https://IP_FQDN_Host ) y navegue hasta Manage->System-> Advanced Settings y en el buscador escriba ScratchConfig.ConfiguredScratchLocation o simplemente Scratch.

3. Independientemente de si se realizó el paso anterior desde el vCenter o desde el Host Client, podrá ver que en el campo value aparecerá la ruta hacia un datastore, lo único que debemos hacer es editar este valor y colocar /tmp, para redireccionarlo a la memoria RAM (no recomendado) o especificar la ruta de un almacenamiento persistente diferente.

Nota 3: Al editar el valor de ScratchConfig.ConfiguredScratchLocation será /tmp, mientras el valor de ScratchConfig.CurrentScratchLocation permanecerá sin cambios. Esto se debe a que es necesario realizar un reinicio del host para que los mismo sean aplicados.

image

4. Una vez realizado el reinicio, inicie sesión nuevamente en el Host Client y navegue hasta Manage->System-> Advanced Settings. En el buscador escriba ScratchConfig.ConfiguredScratchLocation o simplemente Scratch.

En la columna value podrá observar que el valor tanto para ScratchConfig.ConfiguredScratchLocation  como para ScratchConfig.CurrentScratchLocation es /tmp.

image

5. Por ultimo, intente nuevamente la acción Erase Partition.

Desde el vCenter

image

o desde el Host Client (Clear partition table)

image

Y notará que la tarea finaliza con éxito.

image

En este momento ya habrá liberado el o los discos y ahora estarán disponibles para ser reclamados por VSAN desde el asistente de configuración.

Implementando vRealize Network Insight (vRNI) 5.2

Si bien éste no será un post en el que revelaremos las grandes ventajas y funcionalidades de vRealize Network Insight, si diremos que es una de las herramientas más potentes que existen para lograr una visión 360° de nuestro Centro de Datos, debido a que nos permite recolectar información de lo que pasa con el flujo de información en el mundo virtual, físico e incluso a través de nuestros ambientes multicloud. Para conocer un poco acerca de los beneficios claves de la solución ver aquí.

Sus principales Casos de Uso

  • Planificación de Microsegmentación para los clientes que no conocen el flujo de información en sus aplicaciones.
  • Visibilidad 360° no solo del ambiente virtual sino también de la capa física.
  • Implementación de mejores practicas para NSX en la infraestructura.

Dicho lo anterior, nos concentraremos en la implementación de la solución para un ambiente virtual y para esto debemos tener presente cada uno de los componentes que hacen parte de la solución.

image

PROCEDIMIENTO

Clic en el siguiente video para visualizar el procedimiento de instalación y configuración de vRealize Network Insight 5.2.

Solucionando error en EMC Unisphere session: The System can not be managed for the following reasons. Certificate has invalid date.

Como su nombre lo indica este post se enfoca en la solución de un problema de vencimiento de certificados para la consola de administración (EMC Unisphere) de nuestro VNX5200 . Sin embargo no hay de que preocuparse, ¡El mensaje de error asusta más que el problema en sí!.

Al intentar ingresar a la consola de administración del EMC Unisphere aparece el siguiente error:  “The System can not be managed for the following reasons. Certificate has invalid date” y simplemente no permite continuar con el inicio de sesión.

image

El problema básicamente radica en que el certificado ha expirado y no permite el inicio de sesión de ninguna manera.

image

SOLUCIÓN

La solución se centra en forzar la generación de un nuevo certificado a través de una interfaz de línea de comandos.

1. Descargue la herramienta EMC Navisphere CLI desde aquí. Iniciando sesión con una cuenta de usuario registrada para poder realizar la descarga.

image

2.  Instale EMC Navisphere CLI en su ordenador siguiendo cada uno de los pasos del asistente.

image
image

Nota 1: Tenga presente la ruta de instalación de la herramienta (la usaremos más adelante). La ruta por default es C:\Program Files (x86)\EMC\Navisphere CLI.

image

Nota 2: En el Paso 3. Deje la validación del certificado en Low para que no verifique el certificado. (Solo para este caso, porque esta vencido).

image
image

3. Una vez finalizada la instalación. Abra una línea de comandos en Command Prompt (CMD) y navegue hasta la ubicación de instalación de la herramienta Navisphere CLI utilizando el siguiente comando:

cd C:\Program Files (x86)\EMC\Navisphere CLI

image

4. Ejecute ahora la herramienta NaviSECCLI.exe utilizando la siguiente línea de comandos:

NaviSECCli.exe -address [IP_Unisphere] -User [usuario] -Password [Contraseña] -Scope 0 security -SPcertificate -generate

image

Nota 3: Verifique que el resultado de la operación sea SPCertificate is generated: Sucess.

Nota 4: Si el equipo cuenta con mas de una controladora, ejecute el comando para cada una de las IPs asociadas a las mismas.

5.  Abra una ventana en su navegador web e intente realizar la conexión hacia la consola de administración EMC Unisphere nuevamente.

image

6. Revise los detalles del nuevo certificado y notará que es valido por cinco años, a partir de la fecha.

image

7. Haga clic en Accept Always, para aceptar el certificado.

image

8. Por último, inicie sesión en su consola y verifique que el problema ha sido resuelto.

image
image

Importando VMs a vRealize Automation 7.x

Una de las tareas que deberíamos incluir en nuestros planes de trabajo, luego de la instalación, configuración y prueba de nuestro ambiente Cloud Privado con vRealize Automation, es la importación de las VMs que ya existían en el ambiente virtual y que podrían comenzar a ser administradas desde el portal de VRA, con el fin de mantener unificada la interfaz de gestión de las VMs desde el lado del usuario. Esto ayudará a limitar el acceso de administradores al vCenter debido a que acciones como (reinicio, apagado, snaphots, reconfiguración, etc.) podrán ser realizadas por el usuario desde el portal del VRA.

¿CÓMO FUNCIONA?

Existe una funcionalidad llamada Bulk Imports, que permite importar, actualizar y migrar máquinas a vRealize Automation. Esta funcionalidad crea un archivo .CSV que contiene datos de la VM como reservation, storage path, blueprint, owner, y custom properties.

Bulk Imports admite las siguientes tareas administrativas:

  • Importar una o más máquinas virtuales no administradas para que puedan administrarse en el entorno de vRealize Automation .
  • Realizar un cambio global en una propiedad de máquina virtual, como una ruta de almacenamiento.
  • Migrar una máquina virtual de un entorno de vRealize Automation a otro.

Nota: Solo vCloud Director y vSphere son compatibles con Bulk Import. Establecer el filtro en otro tipo de endpoint no genera datos en el archivo CSV.

PRERREQUISITOS

  • Inicie sesión en vRealize Automation como fabric administrator y como business group manager.
  • Si está importando máquinas virtuales que usan direcciones IP estáticas, prepare un pool de direcciones configurado correctamente. Para obtener más información, consulte Crear un perfil de red.
  • Cree un Blueprint para la máquina virtual que planea importar. Este plan debe ser publicado y tener un owner válido para ser Entitled a ese propietario.

PROCEDIMIENTO

Clic en el siguiente video, o clic aquí para ver directamente en YouTube.

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

Configurar notificaciones en vRealize Automation 7.x con cuenta Gmail

¿Por qué utilizar una cuenta externa?

En la mayoría de las ocasiones, cuando tenemos un ambiente de Laboratorio, no tenemos los recursos disponibles en la infraestructura para crear nuestro propio servidor de correo, ya sea por capacidad de procesamiento, memoria, storage, licencias, experiencia en la configuración del mismo o simplemente no contamos con el tiempo suficiente para hacerlo.

Es por esta razón, que en este post explicaremos el procedimiento para emplear una cuenta de Gmail (100% gratis) como Email Server, Inbound (usada para responder a las notificaciones y completar tareas) y Outbound (usada para enviar notificaciones basadas en eventos del sistema), de la solución vRealize Automation 7.x y de esta manera poder notificar a los administradores acerca de lo que sucede en la infraestructura.

Nota 1: No se recomienda utilizar cuentas de correo externo para ambientes productivos.

PROCEDIMIENTO

Dicho lo anterior, veamos cada uno de los pasos involucrado en la configuración de las notificaciones para vRealize Automation, empleando una cuenta Gmail.

1. Cree una cuenta Gmail o utilice una cuenta de correo existente.

Para efectos de laboratorio he decido crear una cuenta nueva únicamente para este fin. Para crear una cuenta nueva haga clic aquí. Una vez creada, inicie sesión en su cuenta recientemente creada y siga las instrucciones del asistente de configuración de Gmail.

image

2.  Habilite en la cuenta el acceso IMAP (Internet Message Access Protocol)

El Protocolo de Acceso a Mensajes de Internet (IMAP), es un protocolo de aplicación que permite el acceder los mensajes almacenados en un servidor de Internet y permite tener acceso al correo electrónico desde cualquier equipo que tenga una conexión a Internet.

Por defecto, la cuenta Gmail esta configurada con IMAP deshabilitado por lo que será necesario habilitarlo como sigue:

a) En su computadora, abra Gmail.
b) En la esquina superior derecha, haga clic en Configuración Configuración.
c) Haga clic en Configuración.
d) Haga clic en la pestaña Reenvío y correo POP/IMAP.
e) En la sección “Acceso IMAP”, haga clic en Habilitar IMAP.
f) Por ultimo, haga clic en Guardar cambios.

image

Nota 2: Tenga en cuenta que para configurar el cliente IMAP vamos necesitar mas adelante los siguientes datos propios de Gmail y de la cuenta asociada.

image

3. Active el acceso de apps menos seguras en la cuenta Gmail.

Si una app o un sitio no cumplen con los estándares de seguridad, es posible que Google bloquee a las personas que intenten acceder a su cuenta desde ellos. Las apps menos seguras pueden permitir que los hackers accedan a la cuenta con más facilidad. Es importante bloquear los accesos desde ellas con el fin de mantener su cuenta protegida.

Dicho lo anterior, la cuenta Gmail por defecto es configurada para denegar el acceso de app menos seguras. Sin embargo, para este fin, debe ser habilitado como sigue:

Nota 3: No realice este procedimiento en su cuenta de correo electrónico personal.

a) En su computadora, abra Gmail.
b) En la esquina superior derecha, haga clic en Google Appsimage.
c) Haga clic en Cuenta.
d) Haga clic en Seguridad y baje hasta la sección Acceso de Apps menos seguras.
e) Haga clic en Activar el acceso (no se recomienda).
f) Por ultimo, haga clic en el botón Permitir el acceso de apps menos seguras.

image
image

4. Configure Email Servers en vRealize Automation appliance

Una vez realizado lo anterior, podrá configurar los Email Servers Inbound y Outbound en vRealize Automation 7.x como sigue:

a) Inicie sesión en el Tenant deseado https://IPóHostname_vRA/vcac/org/nombre_tenant con un usuario  Tenant Administrator. (si es el default tenant entonces https://IPóHostname_vRA/vcac/ ).
b) Haga clic en la pestaña Administration.
c) Haga clic en la sección Notifications y luego clic en Email Servers.
d) Clic en New  (Add) y seleccione Email – Inbound.
e) Configure el servidor IMAP con los datos suministrados en la Nota 2 y los datos de la cuenta de correo electrónico creada en el paso 1.
f) Haga click en el botón TEST CONNECTION. Si la conexión es exitosa (image Connection tested successfully) haga clic en OK.

image

Nota 4: El test debería pasar, si no es así verifique la contraseña. Si la contraseña es correcta y recibe el mensaje image Invalid username or password, revise los pasos anteriores para la configuración de IMAP y Acceso de app menos seguras.

g) Clic en New  (Add) y seleccione Email – Outbound.
h) Configure el servidor SMTP con los datos suministrados en la Nota 2 y los datos de la cuenta de correo electrónico creada en el paso 1.
i) Haga click en el botón TEST CONNECTION. Si la conexión es exitosa (image Connection tested successfully) haga clic en OK.

image

Nota 5: El test debería pasar, si no es así verifique la contraseña. Si la contraseña es correcta y recibe el mensaje image Invalid username or password, revise los pasos anteriores para la configuración Acceso de app menos seguras. Adicionalmente, si no ha permitido el Acceso de app menos seguras, recibirá un correo con una advertencia de inicio de sesión.

image

Por ultimo, al finalizar la configuración de Email Servers, la vista deberá lucir de la siguiente forma.

image

5.  Seleccione los escenarios de notificación

En la pestaña Administration | Notifications | Scenarios, seleccione de la lista, la fuente de notificación que desea Activar o Suspender mediante los botones imageo image.

clip_image001

6. Configure una dirección de correo electrónico a los usuarios

vRealize Automation enviará las notificaciones a las cuentas de correo electrónico configurada para cada uno de los usuarios. De esta manera si se han configurado usuarios de dominio, esta configuración deberá realizarse en el Active Directory.

image

Para visualizar el cambio realizado en el AD desde vRealize Automation será necesario forzar una sincronización, para esto debemos realizar los siguientes pasos:

a) Inicie sesión en el Tenant deseado https://IPóHostname_vRA/vcac/org/nombre_tenant con un usuario  Tenant Administrator. (si es el default tenant entonces https://IPóHostname_vRA/vcac/ ).
b) Haga clic en Administration | Directories.
c) Seleccione el Active Directory y clic en Sync Now.

Si por el contrario, esta usando únicamente usuarios locales (no recomendado), defina una cuenta de correo electrónico para los usuarios locales del Tenant, iniciando sesión como System Administrator (Administrator) en https://IPóHostname_vRA/vcac/ .

a) Vaya a la Sección Tenants.
b) Seleccione el nombre del Tenant y clic en editar.
c) Seleccione la pestaña Local Users.
d) Seleccione el usuario local y defina una cuenta de correo electrónico.

image

7. (Opcional) Cree o edite un Custom Group

Los Custom Group proporcionan un control más granular sobre el acceso dentro de vRealize Automation, que los Business Groups que corresponden a una línea de negocio, departamento u otra unidad organizativa; debido a que los Custom Groups permite centralizar la asignación de roles dentro del Tenant.

Para efectos de laboratorio, se ha creado un Custom group LAB-vRA-Admins para agrupar todos los usuarios de dominio con permiso de administrador, y se le han otorgado todos los roles (esto es valido para entorno de laboratorio), para un ambiente productivo deberá segregarse cada uno de los roles. Cree un Custom Group siguiendo los pasos descritos aquí.

clip_image001[5]

En los miembros asignados al Custom Group se encuentra el usuario de dominio Diego Tunubalá (diego.tunubala@lab.local) que como observamos muestra el email diego.tunubala@xxxx.com configurado en el Active Directory.

image

8. (Opcional) Cree o edite un Business Group

Los Business Groups se utilizan para asociar un conjunto de servicios y recursos a un conjunto de usuarios. Estos grupos a menudo corresponden a una línea de negocio, departamento u otra unidad organizativa. Puede crear un Business Group para poder configurar reservas y autorizar a los usuarios a aprovisionar elementos del catálogo de servicios para los miembros del grupo empresarial. Cree un Custom Business Group siguiendo los pasos descritos aquí.

En nuestro ambiente de laboratorio se ha creado el Business Group LAB-BS-Group01 cuyos miembros son el Custom Group LAB-vRA-Admins, con el Role Manager asignado, y el grupo de dominio gvarusers@lab.local con el role de usuario.

clip_image001[7]

Con el fin de verificar las notificaciones tanto del lado del administrador como del lado del usuario, adicionaremos el usuario pruebavra@lab.local al group de dominio gvarusers@lab.local en el Active Directory.

Nota 6: Al usuario pruebavra@lab.local le fue configurado una cuenta de correo electrónico del mismo modo a lo explicado en el paso 6, pero con una cuenta de correo diferente.

9. Verificar la llegada de notificaciones

La verificación de las notificaciones es una tarea muy sencilla, ya que basta con iniciar sesión en el Tenant con un usuario autorizado y realizar la solicitud de un ítem del catalogo. Para este prueba utilizaremos el usuario pruebavra@lab.local y realizaremos una solicitud de despliegue.

image

Debido a que la solicitud de ítems del catalogo tiene configurada un Approval Policy, la solicitud quedará a la espera de la respuesta del usuario Aprobador configurado en el Tenant (para este caso de laboratorio, es el mismo Tenant Administrator) y será enviada una notificación.

image

En este punto podemos pasar a verificar los mensajes enviados en la cuenta de Gmail configurada y observaremos que desde la cuenta se ha enviado un mail tanto al usuario Administrador del Tenant como al usuario solicitante.

image

En la cuenta de correo asociada al Administrador del Tenant diego.tunubala (mismo usuario aprobador), llegará un correo con dos acciones disponibles Approve y Reject. Que permitirán Aceptar o rechazar el despliegue y enviar un comentario al usuario.

image

Mientras tanto en la cuenta de correo asociada al usuario de prueba pruebavra llegará una notificación indicando que la solicitud ha sido presentada.

image

10. Aprobar solicitud a través de email.

Debido a que el usuario de dominio diego.tunubala@lab.local tienen configurado el role de Aprobador, al hacer clic en el enlace Approve, nos dará la opción de enviar un mensaje adjunto a la aprobación que será enviada a vRealize Automation de manera inmediata sin necesidad de entrar al portal de vRA. Lo mismo sucede si elegimos la opción Reject.

image

Una vez aprobada la solicitud, el usuario será notificado mediante un correo con el status Approved.

image

Después de la aprobación de la solicitud el flujo de despliegue continuará, finalizando nuevamente con una notificación vía correo electrónico al usuario, esta vez con la información de la VM o servicio solicitado desde el catálogo.

image

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