En este cuarto capitulo de la serie dedicada a la instalación y configuración de NSX-T 3.x, explicaremos los conceptos asociados a los Uplink Profiles y Transport Node Profiles. Adicionalmente, mostraremos en el laboratorio el procedimiento para su creación dentro de la interfaz gráfica del NSX Manager.
ATENCIÓN!!!
TODOS LOS NOMBRES DE VMS USADOS EN ESTE BLOG SON INVENTADOS Y OBEDECEN A UN AMBIENTE DE LABORATORIO PROPIO, UTILIZADO PARA FINES DE ESTUDIO.
En este tercer capitulo de la serie dedicada a la instalación y configuración de NSX-T 3.x, agregaremos el vCenter Server como Compute Manager, crearemos Transport Zone tipo VLAN y Overlay y definiremos los IP Pools para los Tunnel End Points (TEPs) de los Transport Nodes.
ATENCIÓN!!!
TODOS LOS NOMBRES DE VMS USADOS EN ESTE BLOG SON INVENTADOS Y OBEDECEN A UN AMBIENTE DE LABORATORIO PROPIO, UTILIZADO PARA FINES DE ESTUDIO.
En este segundo capitulo de la serie dedicada a la instalación y configuración de NSX-T 3.x, prepararemos la infraestructura del laboratorio y realizaremos las configuraciones iniciales (NTP, Log Forwarding y Backup) en el NSX Manager.
ATENCIÓN!!!
TODOS LOS NOMBRES DE VMS USADOS EN ESTE BLOG SON INVENTADOS Y OBEDECEN A UN AMBIENTE DE LABORATORIO PROPIO, UTILIZADO PARA FINES DE ESTUDIO.
Después de algunos días de grabaciones y aprendizaje a prueba y error acerca de diferentes herramientas de edición, comenzamos a explorar una nueva forma de compartir nuestro conocimiento.
Con este post iniciamos el primer capitulo de una serie de videos publicados en YouTube acerca del proceso de instalación y configuración de NSX-T 3.x en nuestro ambiente. La idea principal de este mini curso es no solo proveer los conceptos básicos de la solución y la arquitectura de NSX-T sino que ademas mostrar en el laboratorio cómo se ejecutan algunas de estas tareas de implementación.
Sin más preámbulos, los invito a ver el primer capitulo llamado «Arquitectura de NSX-T – Parte 1» donde revisaremos conceptos básicos de la arquitectura y desplegaremos en el laboratorio el NSX-T Manager.
Por último, no olviden seguir el canal de NachoAprendeVirtualizacion si desean recibir notificaciones de las siguientes publicaciones.
ATENCIÓN!!!
TODOS LOS NOMBRES DE VMS USADOS EN ESTE BLOG SON INVENTADOS Y OBEDECEN A UN AMBIENTE DE LABORATORIO PROPIO, UTILIZADO PARA FINES DE ESTUDIO.
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.
Haga clic en More Option y después clic en Export as CSV.
Clic en Clear All para eliminar todas las propiedades y poder ajustar las que son de nuestro interés.
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
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 de texto Create a new template asignamos un nombre a la plantilla (en este caso hemos definido Export DF Rules Template)y hacemos clic en EXPORT.
Seleccionamos el destino y nombre para el archivo .csv y clic en Save.
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.
Una vez hemos exportado la información simplemente lo importamos en Excel para poder visualizarla como filas y columnas.
(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.
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
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.
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.
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.
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.
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 nsxp02.lab.local.
Nota: Algunas funciones tendrán mas de un servicio, por lo que tendrán un líder asociado para cada uno.
ATENCIÓN!!!
TODOS LOS NOMBRES DE VMS USADOS EN ESTE BLOG SON INVENTADOS Y OBEDECEN A UN AMBIENTE DE LABORATORIO PROPIO, UTILIZADO PARA FINES DE ESTUDIO.
A continuación, se presentará la instalación y algunos ejemplos de utilización del producto PowerNSX que nos permitirá automatizar tareas repetitivas en el NSX Manager y ahorrar tiempo valioso en nuestras implementaciones y tareas de administración.
PASO 1: Instalación de PowerNSX
Para comenzar con PowerNSX se requiere un entorno que tenga PowerShell y PowerCLI instalados. PowerCLI Core ahora es compatible, por lo que este puede ser un dispositivo Windows, Linux o macOS.
Los pasos de instalación para las diversas plataformas requieren lo siguiente:
PowerShell y PowerCLI deberían estar instalados para Windows
Al menos PowerShell 3, se recomienda PowerShell 4 (Win7-8.1, Server 2012/R2), PowerShell 5 (Win10, Server2016)
PowerCLI 5.5 ya no es compatible y se requiere mínimo la versión 6.0 R3
PowerShell Core y PowerCLI Core deberían estar instalados para macOS y Linux
Al momento de escribir este artículo, la versión compatible es PowerShell Core alpha 18.
Adicionalmente se requiere la versión PowerCLI Core 1.0
El método recomendado para instalar PowerNSX es ejecutando una línea de PowerShell que descarga e invoca el Instalador PowerNSX directamente desde el repositorio GitHub de VMware. PowerNSX trasladará su mecanismo de distribución a la galería PowerShell en el futuro, por lo que se recomienda verificar https://powernsx.github.io para obtener las últimas instrucciones de instalación específicas de la plataforma.
Nota 1: Al seguir las secciones de ejemplo, copie las instrucciones de instalación apropiadas en https://powernsx.github.io en lugar de copiarlas manualmente desde este documento.
Nota 2: Este módulo no está soportado por VMware y no incluye garantías explícitas o implícitas, por lo que se recomienda probar y validar su funcionalidad en un ambiente de laboratorio antes de usar este producto en un entorno de producción.
Al hacer clic sobre el botón INSTALAR, la página nos llevará al proceso de instalación y a un breve resumen del PowerNSX.
La instalación a través de PowerShell Gallery solo es compatible con Windows en este momento. La Galería PowerShell está disponible de forma nativa en PowerShell 5 y superior, y se puede instalar fácilmente en versiones anteriores.
Instalar PowerNSX a través de la Galería PowerShell – Windows
PowerNSX se puede instalar a través de una serie de métodos. Comenzar con PowerNSX es rápido y eficiente gracias a la distribución a través de la Galería de PowerShell en Windows, mientras que para los usuarios de macOS y Linux esto puede ser a través del script de instalación o ejecutarse manualmente.
Ejecute los siguientes comandos en una ventana de PowerShell para instalar PowerNSX en el usuario actual o para todos los usuarios de acuerdo a su necesidad. Si PowerCLI no está instalado, los componentes requeridos se descargan e instalan automáticamente. La galería PowerShell es el método recomendado para usuarios de Windows.
Ejecute el siguiente comando para instalar PowerNSX en el usuario actual:
Para instalar en todos los usuarios, ejecute PowerShell como administrador:
Find-Module PowerNSX | Install-Module
Paso 2: Trabajando con PowerNSX
Una vez integrada la herramienta con PowerShell, es momento de aprovechar todas las ventajas de automatización que nos ofrece siguiendo algunos ejemplos comunes, que van desde la conexión al NSX Manager para listar sus propiedades hasta la creación de reglas en el Firewall Distribuido para procesos de micro segmentación.
Conectando a NSX Manager
Los administradores pueden aprovechar SSO o una conexión directa para garantizar el nivel correcto de acceso cuando se utiliza la API de NSX Manager. Con una conexión establecida para vCenter y NSX Manager, un administrador puede realizar operaciones con PowerNSX, de manera que es necesaria una cuenta de usuarios con permisos tanto en vCenter como en el NSX Manager.
La conexión con una cuenta SSO requiere una definición explícita del servidor vCenter. La cuenta que se conecta a vCenter se usará para conectarse a la API de NSX, que creará una sesión PowerCLI y PowerNSX con los permisos de SSO aplicados.
En la consola de PowerShell o PowerShell ISE ejecute el siguiente comando para realizar la conexión, a continuación ingrese usuario y contraseña con permisos en vCenter Server y en NSX Manager
Una vez conectado obtendrá una vista como la siguiente
Ejemplos de configuración con PowerNSX
En la página web oficial del PowerNSX, podremos encontrar algunos ejemplos para operar con NSX Manager como crear Logical Switches, DRL, Security Groups entre otros. Se recomienda visitar el enlace https://powernsx.github.io/get-started
Para efectos de mostrar la utilidad de Power NSX y teniendo en cuenta que debo hacer la creación de 150 Security Groups que me agrupen las 150 aplicaciones de un cliente, veo de gran utilidad utilizar esta herramienta ya que aprovisionarlos de forma manual a través de la interface grafica tardaría mayor tiempo y realmente no soy muy amigo de las tareas repetitivas, por lo que prefiero automatizarlas.
Ejemplo 1: Para visualizar los Security Groups creados en el NSX Manager basta con utilizar el siguiente comando
/> Get-NsxSecurityGroup | select name, objectid | ft -auto
Comprobamos que nos muestra lo mismo desde el NSX Manager UI
Ejemplo 2: Podemos ahora comprobar los miembros de un security group de la siguiente forma
El cmdlet Get-NsxSecurityGroupEffectiveMember toma un objeto Security Grupo de la fuente de información y valida las máquinas virtuales que se resuelven. En el ejemplo anterior, las máquinas virtuales que resultan en el security Group SG_KASPERSKY se incluyen como propiedades.
El resultado del Ejemplo anterior devuelve el objeto primario de la membresía. Si bien es posible usar la notación de puntos para atravesar el objeto y encontrar más detalles, hay cmdlets adicionales que logran el mismo resultado.
Nota: Para miembros que contienen espacio se deben escribir el nombre del miembro entre comillas para evitar errores.
Adicionalmente, podríamos definir los miembros en una variable que puede contener una o varias máquinas virtuales de la siguiente forma, para posteriormente adicionarlas al Security Group creado
/> $Member= get-vm -Name ‘VMName’
Seguidamente para adicionar el miembro al security group solo hace falta ejecutar el siguiente comando
Además de verificar con el cmdlet (Get-NsxSecurityGroup -name SecurityGroupName).member.name que la máquina haya sido agregada al Security Group, podemos también corroborar que aparezca incluida desde la interface gráfica
Ejemplo 4: Para un proceso de micro segmentación se recomienda crear nuevas secciones para no modificar la sección por default. Esto lo podemos lograr con PowerNSX de la siguiente forma
La propiedad -position indica que se debe crear la sección antes de la sección por Default
Para obtener más ejemplos de cómo usar el cmdlet puede ejecutar el siguiente comando
/> Get-help New-NsxFirewallSection -Examples
Ejemplo 5: Por último, nos falta crear por lo menos una regla dentro de la sección por lo que nos apoyaremos en el siguiente comando.
Nota: Se debe ser consiente que todos los objetos puede ser Universales o Locales. Una regla de una sección que NO es universal no puede contener objetos universales por lo que si definimos una variable como $Servicename solo como get-nsxservice HTTPS tomará tanto las propiedades universales como locales y al ejecutar el comando de abajo fallará. Es por esta razón que en la variable $Servicename solo guardaremos sus valores locales como se muestra a continuación.
Una vez aclarado lo anterior, procedemos a ejecutar los siguientes comandos que nos crearán una regla con un origen, un destino, el servicio HTTPS, tendrá la acción de permitir el tráfico y estará logueando el tráfico con la Etiqueta «Testing creating a rule»