n nsx-t data center 1 - vmware...estado en los motores de reenvío. el lcp comparte el mismo destino...

Guía de instalación deNSX-TVMware NSX-T Data Center 1.1

Guía de instalación de NSX-T

VMware, Inc. 2

Puede encontrar la documentación técnica más actualizada en el sitio web de VMware:

https://docs.vmware.com/es/

El sitio web de VMware también ofrece las actualizaciones de producto más recientes.

Si tiene comentarios relacionados con esta documentación, envíelos a:

[email protected]

Copyright © 2017 VMware, Inc. Todos los derechos reservados. Información sobre el copyright y marca comercial.

VMware, Inc.3401 Hillview Ave.Palo Alto, CA 94304www.vmware.com

VMware Spain, S.L.Calle Rafael Boti 262.ª plantaMadrid 28023Tel.: +34 914125000www.vmware.com/es

https://docs.vmware.com/es/

mailto:[email protected]

http://pubs.vmware.com/copyright-trademark.html

Contenido

Guía de instalación de NSX-T 5

1 Descripción general de NSX-T 6

Plano de datos 8

Plano de control 8

Plano de administración 9

NSX Manager 9

NSX Controller 10

Conmutadores lógicos 10

Enrutadores lógicos 11

NSX Edge 12

Zonas de transporte 13

Conceptos clave 13

2 Preparación para la instalación 17

Requisitos del sistema 17

Puertos y protocolos 20

Puertos TCP y UDP usados por NSX Manager 21

Puertos TCP y UDP usados por NSX Controller 22

Puertos TCP y UDP usados por NSX Edge 24

Puertos TCP usados por el administrador de claves 26

Descripción general de la instalación 26

3 Trabajar con KVM 28

Configurar KVM 28

Administrar sus VM invitadas en la CLI de KVM 32

4 Instalación de NSX Manager 34

Instalar NSX Manager en ESXi utilizando vSphere Web Client 35

Instalar NSX Manager en ESXi utilizando la herramienta OVF de la línea de comandos 38

Instalar NSX Manager en KVM 41

5 Instalación y agrupación en clústeres de NSX Controller 45

Instalar NSX Controller en ESXi utilizando una GUI 46

Instalar NSX Controller en ESXi utilizando la herramienta OVF de la línea de comandos 49

Instalar NSX Controller en KVM 52

Unir NSX Controller al plano de administración 55

Inicializar el clúster de control para crear un maestro de clústeres de control. 56

VMware, Inc. 3

Unir controladoras de NSX adicionales al maestro de clústeres 58

6 Instalación de NSX Edge 62

Configuración de red de NSX Edge 63

Instalar NSX Edge en ESXi utilizando una GUI 69

Instalar NSX Edge en ESXi utilizando la herramienta OVF de la línea de comandos 72

Instalar NSX Edge mediante un archivo ISO con un servidor PXE 76

Instalar NSX Edge sin sistema operativo 83

Instalar NSX Edge mediante un archivo ISO como un dispositivo virtual 85

Unir NSX Edge al plano de administración 88

7 Preparación del host 90

Instalar paquetes de terceros en un host de KVM 90

Agregar un host de hipervisor al tejido de NSX-T 91

Instalación manual de módulos kernel NSX-T 96

Unir los hosts del hipervisor al plano de administración 101

8 Zonas de transporte y nodos de transporte 104

Acerca de las zonas de transporte 104

Crear un grupo de direcciones IP para direcciones IP de endpoints de túneles 106

Crear un perfil de vínculo superior 109

Crear zonas de transporte 112

Crear un nodo de transporte de host 114

Crear un nodo de transporte de NSX Edge 120

Crear un clúster de NSX Edge 124

9 Desinstalar NSX-T 126

Desconfigurar una superposición de NSX-T 126

Eliminar un host de NSX-T o desinstalar NSX-T por completo 126


VMware, Inc. 4


La Guía de instalación de NSX-T describe cómo instalar el producto VMware NSX-T ®. La informaciónincluye instrucciones de configuración paso a paso y prácticas recomendadas.

Público objetivoEsta información está dirigida a quien desee instalar o utilizar NSX-T. Esta información está destinada alos administradores de sistemas con experiencia que estén familiarizados con la tecnología de máquinasvirtuales y las operaciones de centros de datos virtuales. Este manual da por sentado que el lector estáfamiliarizado con un servicio de administración de máquinas virtuales, como VMware vSphere 5.5 o 6.0,incluyendo VMware ESX, vCenter Server y vSphere Web Client, VMware OVF Tool, o cualquier otroservicio de administración de máquinas virtuales con máquinas virtuales basadas en kernel (KVM).

Glosario de publicaciones técnicas de VMwarePublicaciones técnicas de VMware proporciona un glosario de términos que podrían resultarledesconocidos. Si desea ver las definiciones de los términos que se utilizan en la documentación técnicade VMware, visite la página http://www.vmware.com/support/pubs.

VMware, Inc. 5

http://www.vmware.com/support/pubs

Descripción general de NSX-T 1De manera muy similar al modo en que la virtualización del servidor, mediante programación, crea,elimina, restaura y crea instantáneas de máquinas virtuales basadas en software, la virtualización deredes de NSX-T, mediante programación, crea, elimina, restaura y crea instantáneas de redes virtualesbasadas en software.

Con la virtualización de red, el equivalente funcional de un hipervisor de red reproduce en el software elconjunto completo de servicios de red de Capa 2 a Capa 7 (por ejemplo, conmutación, enrutamiento,control de acceso, protección de firewall, calidad de servicio [QoS]). Como consecuencia, estos serviciospueden ensamblarse mediante programación en cualquier combinación arbitraria para producir redesvirtuales únicas y aisladas en cuestión de segundos.

NSX-T funciona implementando tres planos independientes pero integrados, que son los planos deadministración, control y datos. Los tres planos se implementan como un conjunto de procesos, módulosy agentes que residen en tres tipos de nodos: nodos de administrador, de controladora y de transporte.n Cada nodo aloja un agente del plano de administración.

n El nodo de NSX Manager aloja los servicios de API. Cada instalación de NSX-T admite un úniconodo de NSX Manager, pero no admite ningún clúster de NSX Manager.

n Los nodos de NSX Controller alojan los demonios del clúster del plano de control central.

n Los nodos de NSX Manager y NSX Controller pueden alojarse conjuntamente en el mismo servidorfísico.

VMware, Inc. 6

n Los nodos de transporte alojan demonios del plano de control local y motores de reenvío.

Plano de administración

Nodos de controladora Nodos de transporte

Nodos de administrador

Agente del MP Agente del MP

Demonios del LCP

Motor de reenvío

Agente del MP

Bus de plano de administración

Clúster del CCPPlano de control centralizado

Plano de control localizado

Plano de datos

Este capítulo incluye los siguientes temas:

n Plano de datos

n Plano de control

n Plano de administración

n NSX Manager

n NSX Controller

n Conmutadores lógicos

n Enrutadores lógicos

n NSX Edge

n Zonas de transporte

n Conceptos clave


VMware, Inc. 7

Plano de datosRealiza el envío sin estado o la transformación de paquetes basándose en tablas rellenadas por el planode control, y transmite la información sobre la topología al plano de control. Asimismo, mantiene lasestadísticas de nivel de paquete.

El plano de datos es el origen de verdad para la topología física y el estado, por ejemplo, ubicación deVIF, estado de túnel, etc. Si está tratando con paquetes que se mueven de un lugar a otro, se encuentraen el plano de datos. El plano de datos también mantiene el estado de y gestiona los errores entre variosvínculos/túneles. El rendimiento por paquete es primordial, con unos requisitos muy estrictos de latenciao vibración. El plano de datos no se contiene necesariamente en su totalidad en el kernel, en loscontroladores, en el espacio de usuario ni en procesos de espacio de usuario específicos. El plano dedatos se restringe al reenvío totalmente sin estado basado en tablas/reglas rellenadas por el plano decontrol.

El plano de datos también podría tener componentes que mantengan cierta cantidad de estado paradeterminadas funciones, como la de terminación TCP. Esto es diferente desde el estado administrado porel plano de control, como asignaciones de túnel de IP MAC, porque el estado administrado por el planode control consiste en cómo reenviar los paquetes, mientras que el estado administrado por el plano dedatos se ve limitado a cómo manipular la carga.

Plano de controlCalcula todo el estado en tiempo de ejecución efímero basándose en la configuración del plano deadministración, disemina información sobre topología notificada por los elementos del plano de datos einserta configuración sin estado en motores de reenvío.

El plano de control se describe a veces como el sistema de señales de la red. Si está tratando conmensajes en proceso para mantener el plano de datos en presencia de una configuración de usuarioestática, está en el plano de control (por ejemplo, responder a una vMotion de una máquina virtual (VM)es responsabilidad del plano de control, pero conectar la VM a la red lógica es responsabilidad del planode administración). A menudo, el plano de control actúa como un reflector de información topológicadesde los elementos del plano de datos entre sí, como, por ejemplo, asignaciones de MAC/túnel paraVTEP. En otros casos, el plano de control actúa sobre los datos recibidos desde algunos elementos delplano de datos para (re)configurar algunos elementos del plano de datos, como usar localizadores VIFpara calcular y establecer la malla de subconjunto de túneles adecuada.

El conjunto de objetos con los que trata el plano de control incluyen VIF, redes lógicas, puertos lógicos,enrutadores lógicos, direcciones IP, etc.

El plano de control se divide en dos partes en NSX-T, el plano de control central (CCP), que se ejecutaen los nodos de clúster de NSX Controller y el plano de control local (LCP), que se ejecuta en los nodosde transporte, adyacentes al plano de datos que controla. El plano de control central calcula algún estadoen tiempo de ejecución efímero basado en la configuración del plano de administración y disemina lainformación notificada por los elementos del plano de datos mediante el plano de control local. El plano


VMware, Inc. 8

de control local supervisa el estado de los vínculos locales, calcula la mayoría del estado en tiempo deejecución efímero basándose en actualizaciones del plano de datos y CCP inserta una configuración sinestado en los motores de reenvío. El LCP comparte el mismo destino que el elemento del plano de datosque lo aloja.

Plano de administraciónEl plano de administración proporciona un punto de entrada único de la API al sistema, mantiene laconfiguración de los usuarios, administra las solicitudes de los usuarios y realiza tareas operacionales entodos los nodos de administración, de control y de plano de datos del sistema.

Para NSX-T cualquier cosa que tenga que ver con solicitar, modificar y persistir la configuración de losusuarios es responsabilidad del plano de administración, mientras que la diseminación de dichaconfiguración hasta el subconjunto adecuado de elementos del plano de datos es responsabilidad delplano de control. Esto significa que algunos datos pertenecen a varios planos en función de la etapa enla que se encuentre su existencia. El plano de administración también se encarga de solicitar lasestadísticas y los estados recientes al plano de control y a veces directamente al plano de datos.

El plano de administración es la única fuente de datos fidedigna para el sistema configurado (lógico), talcomo lo gestiona el usuario mediante configuración. Los cambios se realizan utilizando una RESTful APIo la IU de NSX-T.

En NSX también hay un agente de plano de administración (MPA) ejecutándose en todos los nodos declúster y transporte. Algunos de los casos de uso son las configuraciones de arranque, como estados,estadísticas, paquetes y credenciales de dirección (o direcciones) de nodos de administración central. ElMPA puede ejecutarse de manera relativamente independiente con respecto al plano de control y alplano de datos y se puede reiniciar independientemente de que su proceso se bloquee. No obstante, hayescenarios en los que tienen el mismo destino porque se ejecutan en el mismo host. Se puede accederal MPA tanto de manera local como remota. El MPA se ejecuta en los nodos de transporte, en los nodosde control y en los nodos de administración para la administración de nodos. En los nodos de transportetambién puede realizar tareas relacionadas con el plano de datos.

Entre las tareas que suceden en el plano de administración se incluyen:

n Persistencia de configuración (estado lógico deseado)

n Validación de entrada

n Administración de usuarios -- asignaciones de funciones

n Administración de directivas

n Seguimiento de tareas en segundo plano

NSX ManagerNSX Manager proporciona la interfaz de usuario gráfica (GUI) y las API REST para crear, configurar ysupervisar los componentes de NSX-T, como controladoras, conmutadores lógicos y puertas de enlacede servicios Edge.


VMware, Inc. 9

NSX Manager es el plano de administración para el ecosistema de NSX-T. NSX Manager proporcionauna vista de sistema agregada y es el componente de administración de red centralizada de NSX-T.Proporciona un método para supervisar y solucionar problemas de cargas de trabajo adjuntadas a redesvirtuales creadas por NSX-T. Proporciona configuración y orquestación de:

n Componentes de redes lógicas: conmutación y enrutamiento lógicos

n Servicios Edge y de redes

n Servicios de seguridad y firewall distribuido: componentes integrados de NSX Manager oproveedores de terceros integrados pueden suministrar servicios perimetrales y de seguridad.

NSX Manager permite orquestar a la perfección tanto los servicios integrados como los externos. Todoslos servicios de seguridad, tanto los integrados como los de terceros, se implementan y configuranmediante el plano de administración de NSX-T. El plano de administración proporciona una ventanaúnica para ver la disponibilidad de los servicios. También facilita el encadenamiento de servicios basadosen directivas, la compartición de contexto y la gestión de eventos entre servicios. Esto simplifica laauditoría de la postura de seguridad, optimizando la aplicación de los controles basados en identidad(como los perfiles de movilidad y AD).

NSX Manager también proporciona puntos de entrada a la API REST para automatizar el consumo. Estaarquitectura flexible permite la automatización de todos los aspectos de configuración y supervisiónmediante cualquier plataforma de administración de la nube, plataforma de proveedor de seguridad omarco de trabajo de automatización.

El Agente del plano de administración (MPA) de NSX-T es un componente de NSX Manager que resideen cada uno de los nodos (hipervisor). El MPA está a cargo de persistir el estado deseado del sistema ycomunicar mensajes sin control de flujo (NFC) como configuración, estadísticas, estado y datos entiempo real entre los nodos de transporte y el plano de administración.

NSX ControllerNSX Controller es un sistema de administración de estado distribuido avanzado que controla las redesvirtuales y los túneles de transporte superpuestos.

NSX Controller se implementa como un clúster de dispositivos virtuales de alta disponibilidadresponsables de la implementación mediante programación de redes virtuales en toda la arquitectura deNSX-T. El Plano de control central (CCP) de NSX-T se separa lógicamente de todo el tráfico del plano dedatos, lo que significa que cualquier error en el plano de control no afectará a las operaciones existentesdel plano de datos. El tráfico no pasa por la controladora. En su lugar, la controladora es responsable deproporcionar la configuración a otros componentes de NSX Controller, como los conmutadores lógicos,los enrutadores lógicos y la configuración de servidores perimetrales. La estabilidad y la fiabilidad deltransporte de datos son una cuestión primordial en las redes. Para mejorar aún más la alta disponibilidady escalabilidad, NSX Controller se implementa en un clúster de tres instancias.

Conmutadores lógicosLa capacidad de conmutación lógica de la plataforma NSX Edge permite girar redes de Capa 2 lógicasaisladas con la misma flexibilidad y agilidad que existe para máquinas virtuales.


VMware, Inc. 10

Una implementación de nube para un centro de datos virtual tiene una variedad de aplicaciones envarios arrendatarios. Estas aplicaciones y arrendatarios requieren estar aislados entre sí por motivos deseguridad y de aislamiento de errores, y para evitar problemas de superposición de direccionamiento IP.Los endpoints, tanto virtuales como físicos, se pueden conectar a segmentos lógicos y establecerconectividad independientemente de su ubicación física en la red del centro de datos. Esto se permite eldesacoplamiento de la infraestructura de red de la red lógica (esto es, la red subyacente desde la redsuperpuesta) proporcionado por la virtualización de red de NSX-T.

Un conmutador lógico proporciona una representación de la conectividad conmutada de la Capa 2 a lolargo de muchos hosts con la accesibilidad de IP de Capa 3 entre ellas. Si planea restringir algunasredes lógicas a un conjunto de hosts limitado o tiene requisitos de conectividad personalizados, puedeque deba crear conmutadores lógicos adicionales.

Enrutadores lógicosLos enrutadores lógicos de NSX-T proporcionan conectividad de norte a sur, lo que permite a losarrendatarios acceder a redes públicas, y conectividad de este a oeste entre las distintas redes dentro delos mismos arrendatarios.

Un enrutador lógico es una partición configurada de un enrutador de hardware de red tradicional. Replicala funcionalidad del hardware, lo cual crea múltiples dominios de enrutamiento dentro de un únicoenrutador. Los enrutadores lógicos realizan un subconjunto de las tareas que puede gestionar elenrutador físico, y cada una de ellas puede contener múltiples instancias de enrutamiento y tablas deenrutamiento. El uso de enrutadores lógicos puede ser una forma eficaz de maximizar el uso delenrutador, porque un conjunto de enrutadores dentro de un único enrutador físico pueden realizar lasoperaciones que antiguamente realizaban varios equipos.

Con NSX-T es posible crear una topología de enrutador lógico de dos niveles: el enrutador lógico denivel superior es el de nivel 0 y el de nivel inferior es el de nivel 1. Esta estructura concede tanto aladministrador de proveedores como al administrador de arrendatarios un control completo sobre susservicios y políticas. Los administradores controlan y configuran los servicios y el enrutamiento de nivel 0y los administradores de arrendatarios controlan y configuran el nivel 1. El extremo norte del nivel 0 seconecta a la red física. Además, es en este extremo donde se pueden configurar los protocolos deenrutamiento dinámico para intercambiar información de enrutamiento con los enrutadores físicos. Elextremo sur del nivel 0 se conecta a múltiples capas de enrutamiento de nivel 1 y recibe información deenrutamiento de ellos. Para optimizar el uso de los recursos, la capa de nivel 0 no inserta todas las rutasprocedentes de la red física hacia el nivel 1, pero proporciona información predeterminada.

En dirección sur, la capa de enrutamiento de nivel 1 se conecta a los conmutadores lógicos definidos porlos administradores de arrendatarios y proporciona una función de enrutamiento de un salto entre ellos.Para que se pueda acceder a las subredes adjuntas del nivel 1 desde la red física, debe estar habilitadala redistribución de rutas hacia la capa de nivel 0. Sin embargo, no hay un protocolo de enrutamientoclásico (como OSPF o BGP) ejecutándose entre la capa de nivel 1 y la de nivel 0, y todas las rutas pasan


VMware, Inc. 11

por el plano de control de NSX-T. Tenga en cuenta que la topología de enrutamiento de dos niveles noes obligatoria. Si no hay necesidad de separar a proveedores de arrendatarios, se puede crear unatopología de un solo nivel y en este escenario los conmutadores lógicos se conectan directamente a lacapa de nivel 0 y no hay capa de nivel 1.

Un enrutador lógico consiste en dos partes opcionales: un enrutador distribuido (DR) y uno o variosenrutadores de servicio (SR).

Un DR abarca los hipervisores cuyas VM están conectadas a este enrutador lógico, así como los nodosperimetrales a los que está asociado el enrutador lógico. En el aspecto funcional, el DR es responsabledel enrutamiento distribuido de un salto entre conmutadores lógicos o enrutadores lógicos conectados aeste enrutador lógico. El SR es responsable de suministrar los servicios que no estén implementadosactualmente de forma distribuida, como NAT con estado.

Un enrutador lógico siempre tiene un DR, y varios SR si se cumple cualquiera de las siguientescondiciones:

n El enrutador lógico es un enrutador de nivel 0, aunque no se configuraron servicios con estado.

n El enrutador lógico es un enrutador de nivel 1 vinculado a un enrutador de nivel 0 y tiene serviciosconfigurados que no tienen una implementación distribuida (como NAT, LB o DHCP).

El plano de administración (MP) de NSX-T es responsable de crear automáticamente la estructura queconecta el enrutador de servicios al enrutador distribuido. El MP crea un conmutador lógico de tránsito ylo asigna a una interfaz de red virtual (VNI) y, a continuación, crea un puerto en cada SR y DR, losconecta al conmutador lógico de tránsito y asigna direcciones IP al SR y DR.

NSX EdgeNSX Edge proporciona servicios de enrutamiento y conectividad a las redes externas a laimplementación de NSX-T.

Con NSX Edge, las máquinas virtuales o cargas de trabajo que residen en el mismo host, en diferentessubredes, pueden comunicarse entre sí sin necesidad de atravesar una interfaz de enrutamientotradicional.

NSX Edge es requerido para establecer conectividad externa desde el dominio de NSX-T, a través de unenrutador de nivel 0 mediante enrutamiento estático o BGP. Además, debe implementarse un NSX Edgesi requiere servicios de traducción de direcciones de red (NAT) en los enrutadores lógicos de nivel 0 o denivel 1.

La puerta de enlace de NSX Edge conecta redes aisladas de zona de rutas internas con redescompartidas (vínculo superior) proporcionando servicios de perta de enlace comunes, comoenrutamiento dinámico y NAT. Entre las implementaciones comunes de NSX Edge se incluyen DMZ y losentornos de nube multiarrendatario, donde NSX Edge crea límites virtuales para cada arrendatario.


VMware, Inc. 12

Zonas de transporteUna zona de transporte controla con qué hosts puede comunicarse un conmutador lógico. Puede abarcaruno o más clústeres de host. Las zonas de transporte establecen qué hosts y, por lo tanto, qué máquinasvirtuales pueden participar en el uso de una red determinada.

Una zona de transporte define una colección de hosts que se pueden comunicar entre sí a través de unainfraestructura de red física. Esta comunicación tiene lugar a través de una o varias interfaces definidascomo endpoints de túnel virtual (VTEP).

Si hay dos nodos de transporte en una misma zona de transporte, las VM alojadas en dichos nodos detransporte podrán "ver" y, por tanto, conectarse a conmutadores lógicos de NSX-T que también seencuentren en esa zona de transporte. Esta conexión permite a las VM comunicarse entre sí, siempreque las VM tengan disponibilidad de Capa 2/Capa 3. Si las VM están conectadas a conmutadores queestén en distintas zonas de transporte, las VM no se pueden comunicar entre sí. Las zonas de transporteno reemplazan los requisitos de disponibilidad de Capa 2/Capa 3, pero aplican un límite dedisponibilidad. Dicho de otro modo, pertenecer a la misma zona de transporte es un requisito previo parapoder establecer la conexión. Si se cumple dicho requisito previo, la disponibilidad es posible, pero noautomática. Para que la disponibilidad sea real, las redes de Capa 2 y (para distintas subredes) Capa 3deben estar operativas.

Un nodo puede servir como nodo de transporte si contiene al menos un conmutador de host. Cuandocrea un nodo de transporte de host y a continuación agrega el nodo a una zona de transporte, NSX-Tinstala un conmutador de host en el host. Para cada zona de transporte a la que pertenezca el host, seinstala un conmutador de host aparte. El conmutador de host se utiliza para conectar VM aconmutadores lógicos de NSX-T y para crear vínculos superiores e inferiores de enrutador lógico deNSX-T.

Conceptos claveLos conceptos comunes de NSX-T que se utilizan en la documentación y la interfaz de usuario.

Plano de control Calcula el estado de ejecución basándose en la configuración del plano deadministración. El plano de control difunde la información sobre latopología notificada por los elementos del plano de datos e inserta unaconfiguración sin estado en los motores de reenvío.

Plano de datos Realiza el reenvío sin estado o la transformación de paquetes basándoseen tablas rellenadas por el plano de control. El plano de datos suministrainformación sobre la topología al plano de control y conserva lasestadísticas relativas al nivel de los paquetes.

Red externa Una red física o VLAN no administrada por NSX-T. Puede vincular su redlógica o red superpuesta a una red externa mediante un NSX Edge. Porejemplo, una red física en un centro de datos de cliente o una VLAN en unentorno físico.


VMware, Inc. 13

Nodo de tejido Nodo registrado con el plano de administración de NSX-T y que tieneinstalados módulos de NSX-T. Para que un host de hipervisor o NSX Edgeforme parte de la superposición de NSX-T, debe agregarse al tejido deNSX-T.

Perfil de tejido Representa una configuración específica que se puede asociar a un clústerde NSX Edge. Por ejemplo, el perfil de tejido puede contener laspropiedades de tunelización para la detección de pares muertos.

Salida de puertoslógicos

El tráfico de red entrante que llega a la VM o red lógica se denomina tráficode salida porque sale de la red del centro de datos y accede al espaciovirtual.

Entrada de puertoslógicos

El tráfico de red saliente que va de la VM a la red del centro de datos sedenomina tráfico de entrada porque es tráfico de acceso a la red física.

Enrutador lógico Entidad de enrutamiento de NSX-T.

Puerto de enrutadorlógico

Puerto de red lógica al que puede adjuntar un puerto de conmutador lógicoo un puerto de vínculo superior a una red física.

Conmutador lógico Entidad API que proporciona conmutación de Capa 2 virtual para interfacesde VM e interfaces de puerta de enlace. Un conmutador lógico da a losadministradores de la red de arrendatarios el equivalente lógico de unconmutador de Capa 2 físico, lo que les permite conectar un conjunto deVM a un dominio de difusión común. Un conmutador lógico es una entidadlógica independiente de la infraestructura de hipervisor física y abarca amuchos hipervisores, conectando VM independientemente de su ubicaciónfísica. Esto permite a las VM migrar sin necesidad de que el administradorde la red de arrendatarios tenga que realizar la reconfiguración.

En una nube de múltiples arrendatarios, pueden existir muchosconmutadores lógicos lado a lado en el mismo hardware de hipervisor, concada segmento de Capa 2 aislado del resto. Los conmutadores lógicos sepueden conectar mediante enrutadores lógicos y los enrutadores lógicospueden proporcionar puertos de vínculos superiores conectados a la redfísica externa.

Puerto de conmutadorlógico

Punto de conexión de conmutador lógico para establecer una conexión auna interfaz de red de máquina virtual o una interfaz de enrutador lógico. Elpuerto de conmutador lógico indica el perfil de conmutación aplicado, elestado del puerto y el estado del vínculo.


VMware, Inc. 14

Plano deadministración

Proporciona un punto de entrada único de la API al sistema, persiste laconfiguración de los usuarios, administra las solicitudes de los usuarios yrealiza tareas operacionales en todos los nodos de administración, controly plano de datos del sistema. El plano de administración también esresponsable de consultar, modificar y persistir la configuración de losusuarios.

Clúster deNSX Controller

Se implementa como un clúster de dispositivos virtuales de altadisponibilidad responsables de la implementación mediante programaciónde redes virtuales en toda la arquitectura de NSX-T.

Clúster de NSX Edge Colección de dispositivos de nodos de NSX Edge que tienen la mismaconfiguración que los protocolos implicados en la supervisión de altadisponibilidad.

Nodo de NSX Edge Parte integrante del objetivo funcional es el proporcionar potencia decálculo para suministrar las funciones de servicios IP y enrutamiento IP.

Conmutador de host deNSX-T o KVM OpenvSwitch

Software que se ejecuta en el hipervisor y proporciona reenvío de tráficofísico. El conmutador de host u OVS es invisible para el administrador de lared de arrendatarios y proporciona el servicio de reenvío subyacente en elque se basa cada conmutador lógico. Para conseguir la virtualización de lared, un controlador de red debe configurar los conmutadores de host delhipervisor con tablas de flujo de red que forman los dominios de difusiónlógica que definieron los administradores de arrendatarios cuando crearony configuraron sus conmutadores lógicos.

Cada dominio de difusión lógica se implementa mediante la tunelizacióndel tráfico de VM a VM y del tráfico de VM a enrutador lógico utilizando elmecanismo de encapsulación de túneles Geneve. El controlador de redtiene la visión global del centro de datos y garantiza que las tablas de flujodel conmutador de host del hipervisor se actualicen cuando se creen,muevan o eliminen máquinas virtuales (VM).

NSX Manager Nodo que aloja los servicios API, el plano de administración y los serviciosde agente.

Open vSwitch (OVS) Conmutador de software de código abierto que actúa como un conmutadorde host del hipervisor dentro de XenServer, Xen, KVM y otros hipervisoresbasados en Linux. Los componentes de conmutación de NSX Edge sebasan en OVS.

Red lógica superpuesta Red lógica implementada mediante el uso de tunelización de Capa2 enCapa 3 de tal modo que la topología vista por las VM se desacopla de lade la red física.

Interfaz física (pNIC) Interfaz de red en un servidor físico en el que se instaló un hipervisor.


VMware, Inc. 15

Enrutador lógico denivel 0

El enrutador lógico proveedor también se conoce como enrutador lógico denivel 0 y se conecta a la red física. El enrutador lógico de nivel 0 es unenrutador de nivel superior y se puede realizar como clúster activo-activo oactivo-en espera del enrutador de servicios. El enrutador lógico ejecutaBGP y pares con enrutadores físicos. En el modo activo-en espera, elenrutador lógico también puede proporcionar servicios con estado.

Enrutador lógico denivel 1

El enrutador lógico de nivel 1 es el enrutador de segundo nivel que seconecta a un enrutador lógico de nivel 0 para la conectividad en direcciónnorte y a una o varias redes superpuestas para la conectividad endirección sur. El enrutador lógico de nivel 1 puede ser un clúster activo-enespera del enrutador de servicios que proporciona servicios con estado.

Zona de transporte Colección de nodos de transporte que define el alcance máximo deconmutadores lógicos. Una zona de transporte representa un conjunto dehipervisores suministrados de manera similar y los conmutadores lógicosque conectan VM en dichos hipervisores. NSX-T puede implementar lospaquetes de software de soporte necesarios para los hosts porque sabequé funciones están habilitadas en los conmutadores lógicos.

Interfaz de VM (vNIC) Interfaz de red en una máquina virtual que proporciona conectividad entreel sistema operativo del invitado virtual y el vSwitch estándar o elconmutador distribuido vSphere. La vNIC se puede adjuntar a un puertológico. Puede identificar una vNIC basándose en su ID exclusivo (UUID).

VTEP Endpoint de túnel virtual. Los endpoints de túnel permiten a los hosts delhipervisor participar en una superposición de NSX-T. La superposición deNSX-T implementa una red de Capa 2 sobre un tejido de redes de Capa 3existente encapsulando tramas dentro de paquetes y transfiriendo lospaquetes a través de una red de transporte subyacente. La red detransporte subyacente puede ser otra red de Capa 2 o puede cruzar loslímites de la Capa 3. El VTEP es el punto de conexión en el que seproduce la encapsulación y la desencapsulación.


VMware, Inc. 16

Preparación para la instalación 2Antes de instalar NSX-T, asegúrese de que su entorno esté preparado.

Este capítulo incluye los siguientes temas:n Requisitos del sistema

n Puertos y protocolos

n Puertos TCP y UDP usados por NSX Manager

n Puertos TCP y UDP usados por NSX Controller

n Puertos TCP y UDP usados por NSX Edge

n Puertos TCP usados por el administrador de claves

n Descripción general de la instalación

Requisitos del sistemaNSX-T tiene requisitos específicos en lo referente a los recursos de hardware y las versiones desoftware.

HipervisorTabla 2‑1. Requisitos del hipervisor

Hipervisor Versión Núcleos de CPU Memoria

ESXi n 6.5n 6.0 versión de revisión P04

4 16 GB

KVM en RHEL 7.1 (solo kernel 3.10.0-229), 7.2 (solo kernel3.10.0-327)

4 16 GB

KVM en Ubuntu 14.04.x (kernel 3.13 o 4.4), 16.04.x (solo kernel 4.4) 4 16 GB

VMware, Inc. 17

Para ESXi, NSX-T no admite las funciones Perfiles de host (Host Profiles) e Implementación automática(Auto Deploy).

Precaución En RHEL, el comando yum update podría actualizar la versión del kernel y acabar con lacompatibilidad con NSX-T. Asegúrese de deshabilitar las actualizaciones del kernel cuando ejecute yumupdate. Además, tras ejecutar yum install, compruebe que NSX-T sea compatible con la versión dekernel.

NSX Manager y NSX ControllerTabla 2‑2. Requisitos de recursos de NSX Manager y NSX Controller

Dispositivo Memoria vCPU Espacio de disco

NSX Manager 16 GB 2 140 GB

NSX Controller 16 GB 2 120 GB

Las máquinas virtuales de NSX Manager y NSX Controller son compatibles con la versión 5.5 devSphere ESXi y con sus versiones posteriores.

NSX EdgeTabla 2‑3. Requisitos de recursos de NSX Edge

Tamaño de laimplementación Memoria vCPU Espacio de disco

Pequeño 4 GB 2 120 GB

Mediano 8 GB 4 120 GB

Grande 16 GB 8 120 GB

Tabla 2‑4. Requisitos de hardware físico de NSX Edge

Hardware Tipo

CPU n Xeon 56xx (Westmere-EP)n Xeon E7-xxxx (Westmere-EX)n Xeon E5-xxxx (Sandy Bridge)

NIC n Intel 82599n Intel X540

Requisitos de sistema de NSX Edge sin sistema operativoCódigos de producto

n X520QDA1

n E10G42BT (X520-T2)

n E10G42BTDA (X520-DA2)


VMware, Inc. 18

n E10G42BTDABLK

n X520DA1OCP

n X520DA2OCP

n E10G41BFSR (X520-SR1)

n E10G41BFSRBLK

n E10G42BFSR (X520-SR2)

n E10G42BFSRBLK

n E10G41BFLR (X520-LR1)

n E10G41BFLRBL

ID de dispositivo PCI de NIC Descripción

0x10F7 IXGBE_DEV_ID_82599_KX4

0x1514 IXGBE_DEV_ID_82599_KX4_MEZZ

0x1517 IXGBE_DEV_ID_82599_KR

0x10F8 IXGBE_DEV_ID_82599_COMBO_BACKPLANE

0x000C IXGBE_SUBDEV_ID_82599_KX4_KR_MEZZ

0x10F9 IXGBE_DEV_ID_82599_CX4

0x10FB IXGBE_DEV_ID_82599_SFP

0x11A9 IXGBE_SUBDEV_ID_82599_SFP

0x1F72 IXGBE_SUBDEV_ID_82599_RNDC

0x17D0 IXGBE_SUBDEV_ID_82599_560FLR

0x0470 IXGBE_SUBDEV_ID_82599_ECNA_DP

0x152A IXGBE_DEV_ID_82599_BACKPLANE_FCOE

0x1529 IXGBE_DEV_ID_82599_SFP_FCOE

0x1507 IXGBE_DEV_ID_82599_SFP_EM

0x154D IXGBE_DEV_ID_82599_SFP_SF2

0x154A IXGBE_DEV_ID_82599_SFP_SF_QP

0x1558 IXGBE_DEV_ID_82599_QSFP_SF_QP

0x1557 IXGBE_DEV_ID_82599EN_SFP

0x10FC IXGBE_DEV_ID_82599_XAUI_LOM

0x151C IXGBE_DEV_ID_82599_T3_LOM

0x1528 IXGBE_DEV_ID_X540T

0x1560 IXGBE_DEV_ID_X540T1


VMware, Inc. 19

Exploradores compatibles con NSX ManagerTabla 2‑5. Exploradores compatibles con NSX Manager

Explorador Windows 10 Windows 8,1 Windows 7 Ubuntu 12, 14.04Mac OSX 10.9,10.10, 10.11

Internet Explorer 11 Sí Sí

Firefox 50 Sí Sí Sí Sí

Chrome 54 Sí Sí Sí Sí Sí

Safari 9 Sí

Microsoft Edge 25 Sí

Puertos y protocolosEl siguiente diagrama muestra todas las rutas de comunicación de nodo a nodo en NSX-T, cómo seprotegen y autentican las rutas y la ubicación de almacenamiento de las credenciales que se utilizanpara establecer la autenticación mutua.

Las flechas indican qué agente inicia la comunicación. De forma predeterminada, todos los certificadosson certificados autofirmados. El certificado API en dirección norte y la clave privada se puedenreemplazar.

Hay demonios internos que se comunican a través del bucle invertido o de sockets de dominio UNIX:

n KVM: MPA, netcpa, nsx-agent, OVS

n ESX: netcpa, ESX-DP (en el kernel)

En la base de datos (db) de usuarios de RMQ, se asignan hash a las contraseñas mediante una funciónhash no reversible. De modo que h(p1) es el hash de la contraseña p1.

Los cuadrados coloreados con un icono con forma de candado en la esquina superior derecha denotanlas claves privadas. Los cuadrados sin iconos de candado son claves públicas.


VMware, Inc. 20

Cabak NSX: certificado de cliente por nodo, TLS

Gemfire: certificado de cliente por nodo, TLSAPI/IU: autenticación de sesión, HTTPSCLI: nombre de usuario/contraseña, SSH

Plano de admin.

(u1, p1)

Plano de control

(u2, p2)

Clave de OpenVPN

RabbitMQ (TCP/5672)

API/IU

CLI

HTTPS (TCP/443)

SSH (TCP/22)CLI

SSH (TCP/22)

El túnel OpenVPN transporta:- Zookeeper (TCP/1100,1200,1300)- Moot (TCP/7777)

Gemfire (TCP/9091,7070;TCP 65000-65002;UDP 65000-65002)

ESXi HV

(u3, p3)

MPA LCP

KVM HV

(u4, p4)

MPA LCP

Edge HV

(u5, p5)

MPA LCP

Canal NSX (TCP/1234)

CLISSH (TCP/22)

(u1, h(p1))(u2, h(p2))

base de datos de usuarios de

RMQ

Regiónpersistentede Gemfire

RMQ: secreto compartido/nombre de cuenta por nodo, TLS

Agrupación: zk y moot a través de un túnel OpenVPN, autenticación de certificados o secreto compartido

(u2, p2) Nombre de cuenta RMQ/secreto compartido (unico por host/edge/ccp)

Cert. de servidor de Gemfire, clave privada

Cert. de servidor de RMQ, clave privada

Cert. de servidor de canal NSX, clave privada

Cert. de servidor de API, clave privada

Cert. de cliente de canal NSX, clave privada

CCP Plano de control central

LCP Plano de control local

MP Plano de administración

MPA Agente de plano de administración

Puertos TCP y UDP usados por NSX ManagerNSX Manager utiliza algunos puertos UDP y TCP para comunicarse con otros productos y componentes.Estos puertos deben abrirse en el firewall.

Puede usar una llamada de API o un comando de la CLI si desea especificar puertos personalizadospara transferir archivos (22 es el predeterminado) y para exportar los datos syslog (514 y 6514 son lospredeterminados). Si lo hace, es necesario que configure el firewall de acuerdo a estos cambios.


VMware, Inc. 21

Tabla 2‑6. Puertos TCP y UDP usados por NSX Manager

Origen Destino Puerto Protocolo Descripción

Cualquiera (Any)

Administrador

22 TCP SSH

Cualquiera (Any)

Administrador

123 UDP NTP

Cualquiera (Any)

Administrador

443 TCP Servidor de NSX API

Cualquiera (Any)

Administrador

161 UDP SNMP

Cualquiera (Any)

Administrador

8080 TCP Instalar o actualizar el repositorio HTTP

Cualquiera (Any)

Administrador

5671 TCP Mensajes de NSX

Administrador

Cualquiera(Any)

22 TCP SSH (cargar paquetes de soporte, copias de seguridad, etc.)

Administrador

Cualquiera(Any)

53 TCP DNS

Administrador

Cualquiera(Any)

53 UDP DNS

Administrador

Cualquiera(Any)

123 UDP NTP

Administrador

Cualquiera(Any)

161, 162 TCP SNMP

Administrador

Cualquiera(Any)

161, 162 UDP SNMP

Administrador

Cualquiera(Any)

514 TCP Syslog

Administrador

Cualquiera(Any)

514 UDP Syslog

Administrador

Cualquiera(Any)

6514 TCP Syslog

Administrador

Cualquiera(Any)

6514 UDP Syslog

Administrador

Cualquiera(Any)

9000 TCP Agente Log Insight

Administrador

Cualquiera(Any)

33434 -33523

UDP Traceroute

Puertos TCP y UDP usados por NSX ControllerNSX Controller utiliza algunos puertos UDP y TCP para comunicarse con otros productos ycomponentes. Estos puertos deben abrirse en el firewall.


VMware, Inc. 22


Tabla 2‑7. Puertos TCP y UDP usados por NSX Controller

Origen Destino PuertoProtocolo Descripción

Cualquiera (Any)

Controlador

22 TCP SSH

Cualquiera (Any)

Controlador

53 UDP DNS

Cualquiera (Any)

Controlador

123 UDP NTP

Cualquiera (Any)

Controlador

161 UDP SNMP

Cualquiera (Any)

Controlador

1100 TCP Cuórum de Zookeeper

Cualquiera (Any)

Controlador

1200 TCP Algoritmo de elección de Zookeeper

Cualquiera (Any)

Controlador

1300 TCP Servidor de Zookeeper

Cualquiera (Any)

Controlador

1234 TCP Comunicación CCP-netcpa

Cualquiera (Any)

Controlador

7777 TCP Moot RPC

Cualquiera (Any)

Controlador

11000 -11004

UDP Túneles para otros nodos del clúster. Debe abrir más puertos si el clústertiene más de 5 nodos.

Cualquiera (Any)

Controlador

33434 -33523

UDP Traceroute

Controlador

Cualquiera(Any)

22 TCP SSH

Controlador

Cualquiera(Any)

53 UDP DNS

Controlador

Cualquiera(Any)

53 TCP DNS

Controlador

Cualquiera(Any)

80 TCP HTTP

Controlador

Cualquiera(Any)

123 UDP NTP

Controlador

Cualquiera(Any)


Controlador

Cualquiera(Any)

7777 TCP Moot RPC


VMware, Inc. 23

Tabla 2‑7. Puertos TCP y UDP usados por NSX Controller (Continuación)


Controlador

Cualquiera(Any)

9000 TCP Agente Log Insight

Controlador

Cualquiera(Any)

11000 -11004

TCP Túneles para otros nodos del clúster. Debe abrir más puertos si el clústertiene más de 5 nodos.

Controlador

Cualquiera(Any)

8080 TCP Actualización de NSX

Controlador

Cualquiera(Any)

33434 -33523

UDP Traceroute

Controlador

Cualquiera(Any)

514 UDP Syslog

Controlador

Cualquiera(Any)

514 TCP Syslog

Controlador

Cualquiera(Any)

6514 TCP Syslog

Puertos TCP y UDP usados por NSX EdgeNSX Edge utiliza algunos puertos UDP y TCP para comunicarse con otros productos y componentes.Estos puertos deben abrirse en el firewall.


Tabla 2‑8. Puertos TCP y UDP usados por NSX Edge


Cualquiera (Any)

Edge 22 TCP SSH

Cualquiera (Any)

Edge 123 UDP NTP

Cualquiera (Any)

Edge 161 UDP SNMP

Cualquiera (Any)

Edge 67, 68 UDP DHCP

Cualquiera (Any)

Edge 1167 TCP Backend DHCP

Cualquiera (Any)

Edge 3784, 3785 UDP BDF

Cualquiera (Any)

Edge 5555 TCP Nube pública


VMware, Inc. 24

Tabla 2‑8. Puertos TCP y UDP usados por NSX Edge (Continuación)


Cualquiera (Any)

Edge 6666 TCP Nube pública

Cualquiera (Any)

Edge 8080 TCP Actualización de NSX, NAPI

Cualquiera (Any)

Edge 2480 TCP Nestdb

Edge Cualquiera(Any)

22 TCP SSH


53 UDP DNS


80 TCP HTTP


123 UDP NTP


161, 162 UDP SNMP


161, 162 TCP SNMP


179 TCP BGP


443 TCP HTTPS


514 TCP Syslog


514 UDP Syslog


1167 TCP Backend DHCP


1234 TCP netcpa


VMware, Inc. 25

Tabla 2‑8. Puertos TCP y UDP usados por NSX Edge (Continuación)



3000 - 9000 TCP Proxy de metadatos




6514 TCP Syslog a través de TLS


33434 -33523

UDP Traceroute

Puertos TCP usados por el administrador de clavesEl administrador de claves utiliza algunos puertos TCP para comunicarse con otros productos ycomponentes. Estos puertos deben abrirse en el firewall.

Tabla 2‑9. Puertos TCP usados por el administrador de claves

Origen Destino Puerto Protocolo Descripción

Cualquiera (Any)

Administrador declaves

22 TCP SSH

MP Administrador declaves

8992 TCP Plano de administración para la comunicación del administrador de claves

Hipervisor


8443 TCP Hipervisor para la comunicación del administrador de claves


Cualquiera(Any)

22 TCP SSH

Descripción general de la instalaciónPor lo general, para la instalación inicial, el orden de los procedimientos es el siguiente:

1 Instale NSX Manager.

2 Instale los NSX Controller.

3 Una los NSX Controller al plano de administración.


VMware, Inc. 26

4 Inicialice el clúster de control para crear una controladora maestra.

Este paso es obligatorio aunque solo tenga un NSX Controller en su entorno.

5 Una los NSX Controller en un clúster de control.

6 Instale los módulos de NSX-T en hosts del hipervisor.

Cuando se instalan módulos de NSX-T, se crean certificados en el hipervisor.

7 Una los hosts del hipervisor al plano de administración.

Esto hace que el host envíe su certificado de host al plano de administración.

8 Instale los NSX Edge.

9 Una los NSX Edge al plano de administración.

10 Cree zonas de transporte y nodos de transporte.

Esto hace que se cree un conmutador de host de NSX-T en cada host. En este momento, el plano deadministración envía los certificados de host al plano de control y el plano de administración insertala información del plano de control en los hosts. Cada uno de los hosts se conecta al plano de controlmediante SSL presentando su certificado. El plano de control valida el certificado cotejándolo con elcertificado de host proporcionado por el plano de administración. Las controladoras aceptan laconexión si la validación se realizó correctamente.

Este es el orden recomendado, pero no es obligatorio seguirlo.

NSX Manager se puede instalar en cualquier momento.

Los NSX Controller se pueden instalar y unir al plano de administración en cualquier momento.

Los módulos de NSX-T se pueden instalar en un host de hipervisor antes de que se una al plano deadministración o puede realizar ambos procedimientos al mismo tiempo utilizando la IU Tejido (Fabric) >Hosts (Hosts) > Agregar (Add) o la API POST fabric/nodes.

Los NSX Controller, NSX Edge y los hosts con módulos de NSX-T pueden unirse al plano deadministración en cualquier momento.

Tras la instalaciónCuando los hosts son nodos de transporte, puede crear zonas de transporte, conmutadores lógicos,enrutadores lógicos y otros componentes de red a través de la API o la IU de NSX Manager en cualquiermomento. Cuando los NSX Controller, NSX Edge y los hosts se unen al plano de administración, lasentidades lógicas de NSX-T y el estado de configuración se insertan en los NSX Controller, NSX Edge ylos hosts de forma automática.

Para obtener más información, consulte la Guía de administración de NSX-T.


VMware, Inc. 27

Trabajar con KVM 3NSX-T es compatible con KVM de dos maneras: 1) como nodo de transporte de host y 2) como host paraNSX Manager y NSX Controller.

Este capítulo incluye los siguientes temas:n Configurar KVM

n Administrar sus VM invitadas en la CLI de KVM

Configurar KVMSi planea utilizar KVM como nodo de transporte o como host para VM invitadas de NSX Controller yNSX Manager, pero aún no configuró KVM, puede utilizar el procedimiento descrito aquí.

Procedimiento

1 Instale las utilidades de puente y KVM.

Distribución de Linux Comandos

Ubuntuapt-get install -y qemu-kvm libvirt-bin ubuntu-vm-builder bridge-utils virtinst virt-manager virt-viewer

RHELyum groupinstall "Virtualization Hypervisor"yum groupinstall "Virtualization Client"yum groupinstall "Virtualization Platform"yum groupinstall "Virtualization Tools"

2 Compruebe la capacidad de virtualización del hardware.

cat /proc/cpuinfo | egrep "vmx|svm"

La salida debería contener vmx.

VMware, Inc. 28

3 Asegúrese de que está instalado el módulo KVM.

Distribución de Linux Comandos

Ubuntukvm-ok

INFO: /dev/kvm existsKVM acceleration can be used

RHELlsmod | grep kvm

kvm_intel 53484 6kvm 316506 1 kvm_intel

4 (Para que KVM se utilice como host para NSX Manager o NSX Controller) Prepare el puente de red.

En el siguiente ejemplo, la primera interfaz de Ethernet (eth0 o ens32) se utiliza para conectarse a lapropia máquina Linux. Dependiendo de su entorno de implementación, esta interfaz puede utilizaruna configuración de IP estática o DHCP.

Nota Los nombres de la interfaz pueden variar en función del entorno.

Distribución deLinux Configuración de red

Ubuntu Edite el archivo /etc/network/interfaces:

auto loiface lo inet loopback

auto eth0iface eth0 inet manual

auto br0iface br0 inet dhcp bridge_ports eth0

RHEL Edite /etc/sysconfig/network-scripts/ifcfg-ens32:

DEVICE="ens32" TYPE="Ethernet" NAME="ens32" UUID="<something>" BOOTPROTO="none" HWADDR="<something>" ONBOOT="yes" NM_CONTROLLED="no" BRIDGE="br0"

Edite el archivo /etc/sysconfig/network-scripts/ifcfg-br0:

DEVICE="br0" BOOTPROTO="dhcp" NM_CONTROLLED="no" ONBOOT="yes" TYPE="Bridge"


VMware, Inc. 29

5 (Para que KVM se utilice como nodo de transporte) Prepare el puente de red.

En el siguiente ejemplo, la primera interfaz de Ethernet (eth0 o ens32) se utiliza para conectarse a lapropia máquina Linux. Dependiendo de su entorno de implementación, esta interfaz puede utilizaruna configuración de IP estática o DHCP.


VMware, Inc. 30

Configura una interfaz más que en el paso anterior.

Nota Los nombres de la interfaz pueden variar en función del entorno.

Distribución deLinux Configuración de red

Ubuntu Edite el archivo /etc/network/interfaces:

auto loiface lo inet loopback



auto br0iface br0 inet dhcp Bridge_ports eth0

RHEL Edite /etc/sysconfig/network-scripts/ifcfg-ens32:

DEVICE="ens32" TYPE="Ethernet" NAME="ens32" UUID="<something>" BOOTPROTO="none" HWADDR="<something>" ONBOOT="yes" NM_CONTROLLED="no" BRIDGE="br0"

Edite /etc/sysconfig/network-scripts/ifcfg-ens33:

DEVICE="ens33" TYPE="Ethernet" NAME="ens33" UUID="<something>" BOOTPROTO="none" HWADDR="<something>" ONBOOT="yes" NM_CONTROLLED="no"

Edite el archivo /etc/sysconfig/network-scripts/ifcfg-br0:

DEVICE="br0" BOOTPROTO="dhcp" NM_CONTROLLED="no" ONBOOT="yes" TYPE="Bridge"

Importante Para Ubuntu, todas las configuraciones de red deben especificarseen /etc/network/interfaces. No cree archivos de configuración de red individual,como /etc/network/ifcfg-eth1, que pueden dar lugar a errores en la creación de nodos detransporte.


VMware, Inc. 31

Una vez que el host de KVM esté configurado como nodo de transporte, la interfaz de puente "nsx-vtep0.0" se creará automáticamente. En Ubuntu, /etc/network/interfaces tendrán entradas como lasiguiente:

iface nsx-vtep0.0 inet static

pre-up ip addr flush dev nsx-vtep0.0

address <IP address>

netmask <subnet mask>

mtu 1600

down ifconfig nsx-vtep0.0 down

up ifconfig nsx-vtep0.0 up

En RHEL, nsxa creará un archivo de configuración denominado ifcfg-nsx-vtep0.0, que tiene entradascomo la siguiente:

DEVICE=nsx-vtep0.0

BOOTPROTO=static

NETMASK=<IP address>

IPADDR=<subnet mask>

MTU=1600

ONBOOT=yes

USERCTL=no

NM_CONTROLLED=no

6 Para que los cambios en la red tengan efecto, reinicie la red o el servidor Linux.

7 Prepare el host para volcados de núcleo.

Distribución deLinux Preparar para núcleos de volcado

RHEL Ejecute los siguientes comandos:

mkdir /var/coreschmod 1777 /var/coresecho "kernel.core_pattern = /var/cores/core.%e.%t.%p" >> /etc/sysctl.confsysctl -p

Agregue las siguientes líneas en /etc/security/limits.conf:

* soft core unlimited* hard core unlimitedroot soft core unlimitedroot hard core unlimited

Administrar sus VM invitadas en la CLI de KVMNSX Manager y NSX Controller se pueden instalar como VM de KVM. Además, KVM puede utilizarsecomo el hipervisor para nodos de transporte de NSX.

La administración de VM invitadas de KVM no entra dentro del alcance de esta guía. No obstante, aquíse muestran algunos comandos sencillos de la CLI de KVM con los que podrá ponerse en marcha.


VMware, Inc. 32

Para administrar sus VM invitadas en la CLI de KVM, puede utilizar los comandos virsh. A continuaciónse muestran algunos comandos de virsh comunes. Si desea obtener información adicional, consulte ladocumentación de KVM.

# List running

virsh list

# List all

virsh list --all

# Control instances

virsh start <instance>

virsh shutdown <instance>

virsh destroy <instance>

virsh undefine <instance>

virsh suspend <instance>

virsh resume <instance>

# Access an instance's CLI

virsh console <instance>

En la CLI de Linux, el comando ifconfig muestra la interfaz vnetX, que representa la interfaz creadapara la VM invitada. Si agrega VM invitadas adicionales, se agregan interfaces vnetX adicionales.

ifconfig

...

vnet0 Link encap:Ethernet HWaddr fe:54:00:b0:a0:6d

inet6 addr: fe80::fc54:ff:feb0:a06d/64 Scope:Link

UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1

RX packets:13183 errors:0 dropped:0 overruns:0 frame:0

TX packets:181524 errors:0 dropped:0 overruns:0 carrier:0

collisions:0 txqueuelen:500

RX bytes:4984832 (4.9 MB) TX bytes:29498709 (29.4 MB)


VMware, Inc. 33

Instalación de NSX Manager 4NSX Manager proporciona una interfaz gráfica de usuario (GUI) y varias API REST para crear, configurary supervisar componentes de NSX-T, como conmutadores lógicos, enrutadores lógicos y firewalls.NSX Manager proporciona una vista del sistema y es el componente de administración de NSX-T.

NSX Manager es compatible con vSphere ESXi o KVM. Solo puede instalar una instancia deNSX Manager. Puede utilizar la función de alta disponibilidad (HA) de vSphere para garantizar ladisponibilidad de NSX Manager. En ESXi, se recomienda que el dispositivo de NSX Manager se instaleen el almacenamiento compartido. vSphere HA requiere almacenamiento compartido, de modo que eldispositivo de NSX Manager pueda reiniciarse en otro host si se producen errores en el original.

NSX Manager es compatible con los siguientes métodos de implementación:n OVA/OVF

n QCOW2

NSX Manager debe disponer de una dirección IP estática. No puede cambiar la dirección IP tras lainstalación.

Los dispositivos NSX-T tienen los siguientes requisitos de complejidad para sus contraseñas:n Al menos ocho caracteres

n Al menos una letra en minúsculas

n Al menos una letra en mayúsculas

n Al menos un dígito

n Al menos un carácter especial

n Al menos cinco caracteres distintos

n Sin palabras del diccionario

n Sin palíndromos

VMware, Inc. 34

La instalación se realizará correctamente aunque la contraseña no cumpla los requisitos de complejidad.Si no especifica una contraseña suficientemente compleja para el usuario admin durante laimplementación, deberá iniciar sesión como admin tras la implementación y responder a la petición decambio de contraseña. Si el usuario root tampoco tiene una contraseña lo suficientemente compleja,cambie la contraseña con el siguiente comando cuando tenga la sesión iniciada como admin:

set user root password <password>

Nota En una instalación nueva del administrador, en un reinicio del sistema o tras cambiar lacontraseña de admin cuando se le solicita en el primer inicio de sesión, puede que el administrador tardevarios minutos en arrancar.

Los servicios principales del dispositivo no se iniciarán hasta que se establezca una contraseña con unnivel de complejidad suficiente.

Después de implementar NSX Manager desde un archivo OVA, no puede cambiar la configuración de laIP de la máquina virtual si apaga esta máquina virtual y modifica la configuración OVA en vCenter Server.

Al instalar NSX Manager, elija un nombre de host que no contenga guiones bajos. Si especifica unnombre de host que contenga un guión bajo, después de la implementación el dispositivo tendrá unnombre de host predeterminado, como nsx-manager.

Importante Las instalaciones de máquina virtual del componente NSX incluyen VMware Tools. No sepermite la eliminación o actualización de VMware Tools para dispositivos NSX.


n Instalar NSX Manager en ESXi utilizando vSphere Web Client

n Instalar NSX Manager en ESXi utilizando la herramienta OVF de la línea de comandos

n Instalar NSX Manager en KVM

Instalar NSX Manager en ESXi utilizando vSphere WebClientPuede utilizar vSphere Web Client para implementar NSX Manager como dispositivo virtual.

Nota Se recomienda usar vSphere Web Client en lugar de vSphere Client. Si no tiene vCenter Serveren su entorno, use ovftool para implementar NSX Manager. Consulte Instalar NSX Manager en ESXiutilizando la herramienta OVF de la línea de comandos.

Requisitos previos

n Compruebe que se cumplan los requisitos del sistema. Consulte Requisitos del sistema.

n Compruebe que estén abiertos los puertos necesarios. Consulte Puertos y protocolos.


VMware, Inc. 35

n Si aún no tiene una, cree la red del grupo de puertos de VM de destino. La mayoría de lasimplementaciones colocan los dispositivos NSX en una red de VM de administración.

Si tiene varias redes de administración, puede agregar rutas estáticas a las otras redes desde eldispositivo NSX. Prepare el grupo de puertos de VM de administración sobre el que se comunicaránlos dispositivos NSX.

n Planifique su esquema de direcciones IP IPv4 IP. Esta versión de NSX-T no es compatible con IPv6.

Procedimiento

1 Localice el archivo OVA u OVF de NSX Manager.

Puede copiar la URL de descarga, o bien descargar el archivo OVA en el equipo.

2 En vSphere Web Client, inicie el asistente Implementar plantilla OVF y vaya al archivo .ova oestablezca un vínculo a él.

3 Introduzca un nombre para el NSX Manager y seleccione una carpeta o centro de datos.

El nombre que escriba aparecerá en el inventario.

La carpeta que seleccione se utilizará para aplicar permisos al NSX Manager.

4 Seleccione un almacén de datos para almacenar los archivos de dispositivos virtuales delNSX Manager.

5 Si está realizando la instalación en vCenter, seleccione un host o clúster sobre el que implementar eldispositivo NSX Manager.

Por lo general, colocaría el NSX Manager en un clúster que proporcione utilidades de administraciónde redes.

6 Seleccione el grupo de puertos o la red de destino de NSX Manager.

Por ejemplo, si utiliza conmutadores distribuidos de vSphere, puede colocar NSX Manager en ungrupo de puertos denominado Mgmt_VDS - Mgmt.


VMware, Inc. 36

7 Establezca las contraseñas y la configuración de direcciones IP de NSX Manager.

Por ejemplo, esta pantalla muestra la pantalla de revisión final después de que se configuraran todaslas opciones.

8 Para que el rendimiento sea óptimo, reserve memoria para el componente NSX.

Una reserva de memoria es un límite inferior garantizado para la cantidad de memoria física que elhost reserva para una máquina virtual, incluso cuando la memoria está sobrecomprometida.Establezca la reserva en un nivel que garantice que el componente de NSX tenga suficiente memoriacomo para ejecutarse de forma eficiente. Consulte Requisitos del sistema.

Abra la consola del componente NSX para hacer un seguimiento del proceso de arranque.

Una vez que el componente de NSX termine de arrancar, inicie sesión en la interfaz de línea decomandos (CLI) y ejecute el comando get interface eth0 para comprobar que la dirección IP seaplicó según lo previsto.

nsx-component> get interface eth0

Interface: eth0

Address: 192.168.110.25/24

MAC address: 00:50:56:86:7b:1b

MTU: 1500

Default gateway: 192.168.110.1

Broadcast address: 192.168.110.255

...


VMware, Inc. 37

Asegúrese de que su componente de NSX tiene la conectividad requerida.

n Asegúrese de que pueda hacer ping a su componente de NSX.

n Asegúrese de que el componente de NSX puede hacer ping a su puerta de enlace predeterminada.

n Asegúrese de que su componente de NSX puede hacer ping a los hosts del hipervisor que estén enla misma red que el componente de NSX.

n Asegúrese de que el componente de NSX puede hacer ping a su servidor DNS y a su servidor NTP.

n Si habilitó SSH, asegúrese de que puede utilizar SSH con su componente de NSX.

Si no se estableció la conectividad, asegúrese de que el adaptador de red esté en la VLAN o redadecuada.

Pasos siguientes

Conecte a la GUI de NSX Manager desde un explorador web compatible. La URL es https://<dirección IPo nombre de host de NSX Manager>. Por ejemplo: https://192.168.110.75.

Nota Debe utilizar HTTPS. No se admite HTTP.

Instalar NSX Manager en ESXi utilizando la herramientaOVF de la línea de comandosSi prefiere automatizar la instalación de NSX Manager, puede utilizar la herramienta OVF de VMware,que es una utilidad de línea de comandos.

Por motivos de seguridad, nsx_isSSHEnabled y nsx_allowSSHRootLogin están deshabilitados de formapredeterminada. Cuando están deshabilitadas, no puede utilizar SSH ni iniciar sesión en la línea decomandos de NSX Manager. Si habilita nsx_isSSHEnabled pero no habilita nsx_allowSSHRootLogin,puede utilizar SSH con NSX Manager pero no puede iniciar sesión como raíz.

Requisitos previos







VMware, Inc. 38

Procedimiento

n (Para un host independiente) Ejecute el comando ovftool con los parámetros adecuados. Porejemplo,

C:\Users\Administrator\Downloads>ovftool

--name=nsx-manager

--X:injectOvfEnv

--X:logFile=ovftool.log

--allowExtraConfig

--datastore=ds1

--network="management"

--acceptAllEulas

--noSSLVerify

--diskMode=thin

--powerOn

--prop:nsx_ip_0=192.168.110.75

--prop:nsx_netmask_0=255.255.255.0

--prop:nsx_gateway_0=192.168.110.1

--prop:nsx_dns1_0=192.168.110.10

--prop:nsx_domain_0=corp.local

--prop:nsx_ntp_0=192.168.110.10

--prop:nsx_isSSHEnabled=<True|False>

--prop:nsx_allowSSHRootLogin=<True|False>

--prop:nsx_passwd_0=<password>

--prop:nsx_cli_passwd_0=<password>

--prop:nsx_hostname=nsx-manager

nsx-<component>.ova

vi://root:<password>@192.168.110.51

Opening OVA source: nsx-<component>.ova

The manifest validates

Source is signed and the certificate validates

Opening VI target: vi://root:<password>@192.168.110.51

Deploying to VI: vi://root:<password>@192.168.110.51

Transfer Completed

Powering on VM: nsx-manager

Task Completed

Warning:

- No manifest entry found for: 'nsx-<component>.ovf'.

- File is missing from the manifest: 'nsx-<component>.ovf'.

- ExtraConfig options exists in source.

- Skipping monitor as the --X:waitForIp option is not given.

Completed successfully


VMware, Inc. 39

n (Para un host administrado por vCenter Server) Ejecute el comando ovftool con los parámetrosadecuados. Por ejemplo,


--name=nsx-manager

--X:injectOvfEnv


--allowExtraConfig

--datastore=ds1


--acceptAllEulas

--noSSLVerify

--diskMode=thin

--powerOn

--prop:nsx_ip_0=192.168.110.75



--prop:nsx_dns1_0=192.168.110.10


--prop:nsx_ntp_0=192.168.110.10





--prop:nsx_hostname=nsx-manager

nsx-<component>.ova

vi://[email protected]:<password>@192.168.110.24/?ip=192.168.110.51




Opening VI target: vi://[email protected]@192.168.110.24:443/

Deploying to VI: vi://[email protected]@192.168.110.24:443/

Transfer Completed

Powering on VM: nsx-manager

Task Completed

Warning:






n Para que el rendimiento sea óptimo, reserve memoria para el componente NSX.



VMware, Inc. 40




Interface: eth0

Address: 192.168.110.25/24


MTU: 1500



...








Pasos siguientes



Instalar NSX Manager en KVMNSX Manager se puede instalar como dispositivo virtual en un host de KVM.

El procedimiento de instalación de QCOW2 utiliza guestfish, una herramienta de línea de comandos deLinux para escribir la configuración de máquina virtual en el archivo QCOW2.

Requisitos previos

n Configuración de KVM. Consulte Configurar KVM.

n Privilegios para implementar una imagen QCOW2 en el host de KVM.




VMware, Inc. 41




Procedimiento

1 Descargue la imagen QCOW2 de NSX Manager y cópiela en la ubicación en la que deba estar.

2 (Solo para Ubuntu) Agregue el usuario que tiene iniciada la sesión actualmente como un usuariolibvirtd:

adduser $USER libvirtd

3 En el mismo directorio en el que guardó la imagen QCOW2, cree un archivo llamado guestinfo (sinextensión de archivo) y rellénelo con las propiedades de la VM de NSX Manager.

Por ejemplo:

<?xml version="1.0" encoding="UTF-8"?>

<Environment

xmlns="http://schemas.dmtf.org/ovf/environment/1"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xmlns:oe="http://schemas.dmtf.org/ovf/environment/1">

<PropertySection>

<Property oe:key="nsx_allowSSHRootLogin" oe:value="True"/>

<Property oe:key="nsx_cli_passwd_0" oe:value="<password>"/>

<Property oe:key="nsx_dns1_0" oe:value="192.168.110.10"/>

<Property oe:key="nsx_domain_0" oe:value="corp.local"/>

<Property oe:key="nsx_gateway_0" oe:value="192.168.110.1"/>

<Property oe:key="nsx_hostname" oe:value="nsx-manager1"/>

<Property oe:key="nsx_ip_0" oe:value="192.168.110.19"/>

<Property oe:key="nsx_isSSHEnabled" oe:value="True"/>

<Property oe:key="nsx_netmask_0" oe:value="255.255.255.0"/>

<Property oe:key="nsx_ntp_0" oe:value="192.168.110.10"/>

<Property oe:key="nsx_passwd_0" oe:value="<password>"/>

</PropertySection>

</Environment>

En el ejemplo, están habilitados nsx_isSSHEnabled y nsx_allowSSHRootLogin. Cuando estándeshabilitadas, no puede utilizar SSH ni iniciar sesión en la línea de comandos de NSX Manager. Sihabilita nsx_isSSHEnabled pero no habilita nsx_allowSSHRootLogin, puede utilizar SSH conNSX Manager pero no puede iniciar sesión como raíz.


VMware, Inc. 42

4 Use guestfish para escribir el archivo guestinfo en la imagen QCOW2.

Si está creando varios administradores, realice una copia aparte de la imagen QCOW2 para cadaadministrador. Una vez que la información de guestinfo esté escrita en una imagen QCOW2, no sepodrá sobrescribir la información.

guestfish --rw -i -a nsx-manager1-build.qcow2 upload guestinfo /config/guestinfo

5 Implemente la imagen QCOW2 con el comando virt-install.

user@ubuntu1604:/var/lib/libvirt/images$ sudo virt-install --import --name nsx-manager1 --ram

16348 --vcpus 4 --network=bridge:br0,model=e1000 --disk path=/var/lib/libvirt/images/nsx-

manager-1.1.0.0.0.4446302.qcow2,format=qcow2 --nographics

Starting install...

Creating domain... | 0 B 00:01

Connected to domain nsx-manager1

Escape character is ^]

nsx-manager1 login:

Una vez que NSX Manager arranque, se mostrará la consola de NSX Manager.




Una vez que arranque por completo el componente NSX, espere 3 minutos y, a continuación, iniciesesión como administrador en la CLI. Se muestra la pantalla del Contrato de licencia para el usuario final(CLUF). Acepte el CLUF. A continuación, ejecute el comando get interface eth0 para verificar que ladirección IP se aplicó según lo esperado.


Interface: eth0

Address: 192.168.110.25/24


MTU: 1500



...




VMware, Inc. 43






Pasos siguientes




VMware, Inc. 44

Instalación y agrupación enclústeres de NSX Controller 5NSX Controller es un sistema de administración de estado avanzado distribuido que proporcionafunciones del plano de control para funciones de enrutamiento y conmutación lógicos de NSX-T. Sirvecomo punto de control central para todos los conmutadores lógicos de una red y mantiene informaciónsobre todos los hosts, conmutadores lógicos y enrutadores lógicos. Los NSX Controller controlan losdispositivos que realizan el reenvío de paquetes. Estos dispositivos de reenvío se conocen comoconmutadores virtuales. Los conmutadores virtuales (como conmutador de host de NSX-T u OpenvSwitch —OVS—) existen dentro de ESX y otros hipervisores, como KVM.

NSX Controller dispone de los siguientes métodos de implementación compatibles:n OVA/OVF

n QCOW2

NSX Controller es compatible con ESX o KVM.

No se admite la instalación de NSX Controller mediante arranque PXE.

Un NSX Controller debe disponer de una dirección IP estática. No puede cambiar la dirección IP tras lainstalación.

Los dispositivos NSX-T tienen los siguientes requisitos de complejidad para sus contraseñas:n Al menos ocho caracteres







n Sin palíndromos

VMware, Inc. 45

La instalación se realizará correctamente aunque la contraseña no cumpla los requisitos de complejidad.Sin embargo, cuando inicie sesión por primera vez, se le pedirá que cambie la contraseña.

Nota Los servicios principales del dispositivo no se iniciarán hasta que se establezca una contraseñacon un nivel de complejidad suficiente.

Después de implementar NSX Controller desde un archivo OVA, no puede cambiar la configuración de laIP de la máquina virtual si apaga esta máquina virtual y modifica la configuración OVA en vCenter Server.

Al instalar NSX Manager, elija un nombre de host que no contenga guiones bajos. De lo contrario, elnombre de host se establece en localhost.



n Instalar NSX Controller en ESXi utilizando una GUI

n Instalar NSX Controller en ESXi utilizando la herramienta OVF de la línea de comandos

n Instalar NSX Controller en KVM

n Unir NSX Controller al plano de administración

n Inicializar el clúster de control para crear un maestro de clústeres de control.

n Unir controladoras de NSX adicionales al maestro de clústeres

Instalar NSX Controller en ESXi utilizando una GUISi prefiere una instalación interactiva de NSX Controller, puede utilizar una herramienta deadministración de VM basada en IU, como vSphere Client conectado a vCenter Server.

Para permitir realizar copias de seguridad y restauraciones, los dispositivos NSX Controller deben tenerdirecciones IP de administración estáticas. No se permite el uso de DHCP para asignar direcciones IP deadministración. No se permite cambiar las direcciones IP de administración. Consulte la Guía deadministración de NSX-T para obtener información sobre las copias de seguridad y las restauraciones.

Sus contraseñas deben cumplir las restricciones de seguridad para contraseñas. Los dispositivos NSX-Taplican las siguientes reglas de complejidad:

n Al menos ocho caracteres








VMware, Inc. 46

n Sin palíndromos

Para la instalación de PXE, debe proporcionar la cadena de contraseña cifrada con el algoritmo sha-512para la contraseña de usuario administrador y raíz.

La instalación se realizará correctamente si la contraseña no cumple los requisitos. Sin embargo, cuandoinicie sesión por primera vez, se le pedirá que cambie la contraseña.

Importante Los servicios principales del dispositivo no se iniciarán hasta que se establezca unacontraseña con un nivel de complejidad suficiente.


Requisitos previos






n Privilegios para implementar una plantilla OVF en el host ESXi.

n Elija nombres de host que no incluyan guiones bajos. De lo contrario, el nombre de host se estableceen nsx-manager.

n Una herramienta de administración que puede implementar plantillas OVF, como el vCenter Server ovSphere Client.

La herramienta de implementación de OVF debe admitir opciones de configuración que permitanrealizar la configuración de forma manual.

n Debe estar instalado el complemento de integración de clientes.

Procedimiento

1 Localice el archivo OVA u OVF de NSX Controller.


2 En la herramienta de administración, inicie el asistente Implementar plantilla OVF (Deploy OVFtemplate) y vaya al archivo .ova o establezca un vínculo con él.


VMware, Inc. 47

3 Introduzca un nombre para el NSX Controller y seleccione una carpeta o centro de datos.


La carpeta que seleccione se utilizará para aplicar permisos al NSX Controller.

4 Seleccione un almacén de datos para almacenar los archivos de dispositivos virtuales delNSX Controller.

5 Si está usando vCenter, seleccione un host o clúster sobre el que implementar el dispositivo deNSX Controller.

Por lo general, colocaría el NSX Controller en un clúster que proporcione utilidades de administraciónde redes.

6 Seleccione el grupo de puertos o la red de destino de NSX Controller.

Por ejemplo, si utiliza conmutadores distribuidos de vSphere, puede colocar NSX Controller en ungrupo de puertos denominado Mgmt_VDS - Mgmt.

7 Establezca la contraseña y la configuración de direcciones IP de NSX Controller.

Por ejemplo, esta pantalla muestra la pantalla de revisión final después de que se configuraron todaslas opciones.


VMware, Inc. 48






Interface: eth0

Address: 192.168.110.25/24


MTU: 1500



...








Pasos siguientes

Una el NSX Controller al plano de administración. Consulte Unir NSX Controller al plano deadministración.

Instalar NSX Controller en ESXi utilizando la herramientaOVF de la línea de comandosSi prefiere automatizar la instalación de NSX Controller, puede utilizar la herramienta OVF de VMware,que es una utilidad de línea de comandos.

Por motivos de seguridad, nsx_isSSHEnabled y nsx_allowSSHRootLogin están deshabilitados de formapredeterminada. Cuando están deshabilitadas, no puede utilizar SSH ni iniciar sesión en la línea decomandos de NSX Controller. Si habilita nsx_isSSHEnabled pero no habilita nsx_allowSSHRootLogin,puede utilizar SSH con NSX Controller pero no puede iniciar sesión como raíz.


VMware, Inc. 49

Requisitos previos






n Herramienta OVF, versión 4.0 o posterior.

Procedimiento

n (para un host independiente) Ejecute el comando ovftool con los parámetros adecuados.


--name=nsx-controller

--X:injectOvfEnv


--allowExtraConfig

--datastore=ds1


--acceptAllEulas

--noSSLVerify

--diskMode=thin

--powerOn

--prop:nsx_ip_0=192.168.110.210



--prop:nsx_dns1_0=192.168.110.10


--prop:nsx_ntp_0=192.168.110.10





--prop:nsx_hostname=nsx-controller

<path/url to nsx component ova>





Opening VI target: vi://[email protected]

Deploying to VI: vi://[email protected]

Transfer Completed

Powering on VM: nsx-controller

Task Completed


VMware, Inc. 50

Warning:






n (para un host administrado por vCenter Server) Ejecute el comando ovftool con los parámetrosadecuados.


--name=nsx-controller

--X:injectOvfEnv


--allowExtraConfig

--datastore=ds1


--acceptAllEulas

--noSSLVerify

--diskMode=thin

--powerOn

--prop:nsx_ip_0=192.168.110.210



--prop:nsx_dns1_0=192.168.110.10


--prop:nsx_ntp_0=192.168.110.10





--prop:nsx_hostname=nsx-controller






Opening VI target: vi://administrator%[email protected]:443/

Deploying to VI: vi://administrator%[email protected]:443/

Transfer Completed

Powering on VM: nsx-controller

Task Completed

Warning:







VMware, Inc. 51






Interface: eth0

Address: 192.168.110.25/24


MTU: 1500



...








Pasos siguientes


Instalar NSX Controller en KVMNSX Controller sirve como punto de control central para todos los conmutadores lógicos de una red ymantiene información sobre todos los hosts, conmutadores lógicos y enrutadores lógicos distribuidos.

El procedimiento de instalación de QCOW2 utiliza guestfish, una herramienta de línea de comandos deLinux para escribir la configuración de máquina virtual en el archivo QCOW2.


VMware, Inc. 52

Requisitos previos

n Configuración de KVM. Consulte Configurar KVM.

n Privilegios para implementar una imagen QCOW2 en el host de KVM.






Procedimiento

1 Descargue la imagen QCOW2 de NSX Controller.

2 (Solo para Ubuntu) Agregue el usuario que tiene iniciada la sesión actualmente como un usuariolibvirtd:

adduser $USER libvirtd

3 En el mismo directorio en el que guardó la imagen QCOW2, cree un archivo llamado guestinfo (sinextensión de archivo) y rellénelo con las propiedades de la VM de NSX Controller.

Por ejemplo:

<?xml version="1.0" encoding="UTF-8"?>

<Environment

xmlns="http://schemas.dmtf.org/ovf/environment/1"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xmlns:oe="http://schemas.dmtf.org/ovf/environment/1">

<PropertySection>

<Property oe:key="nsx_allowSSHRootLogin" oe:value="True"/>

<Property oe:key="nsx_cli_passwd_0" oe:value="<password>"/>

<Property oe:key="nsx_dns1_0" oe:value="192.168.110.10"/>

<Property oe:key="nsx_domain_0" oe:value="corp.local"/>

<Property oe:key="nsx_gateway_0" oe:value="192.168.110.1"/>

<Property oe:key="nsx_hostname" oe:value="nsx-Controller1"/>

<Property oe:key="nsx_ip_0" oe:value="192.168.110.34"/>

<Property oe:key="nsx_isSSHEnabled" oe:value="True"/>

<Property oe:key="nsx_netmask_0" oe:value="255.255.255.0"/>

<Property oe:key="nsx_ntp_0" oe:value="192.168.110.10"/>

<Property oe:key="nsx_passwd_0" oe:value="<password>"/>

</PropertySection>

</Environment>


VMware, Inc. 53

En el ejemplo, están habilitados nsx_isSSHEnabled y nsx_allowSSHRootLogin. Cuando estándeshabilitadas, no puede utilizar SSH ni iniciar sesión en la línea de comandos de NSX Controller. Sihabilita nsx_isSSHEnabled pero no habilita nsx_allowSSHRootLogin, puede utilizar SSH conNSX Controller pero no puede iniciar sesión como raíz.

4 Use guestfish para escribir el archivo guestinfo en la imagen QCOW2.

Si está creando varias controladoras , realice una copia aparte de la imagen QCOW2 para cadacontroladora. Una vez que la información de guestinfo esté escrita en una imagen QCOW2, no sepodrá sobrescribir la información.

guestfish --rw -i -a nsx-Controller1-build.qcow2 upload guestinfo /config/guestinfo

5 Implemente la imagen QCOW2 con el comando virt-install.

user@ubuntu1604:/var/lib/libvirt/images$ sudo virt-install --import --name nsx-controller1 --ram

16348 --vcpus 4 --network=bridge:br0,model=e1000 --disk path=/var/lib/libvirt/images/nsx-

manager-1.1.0.0.0.4446302.qcow2,format=qcow2 --nographics

Starting install...

Creating domain... | 0 B 00:01

Connected to domain nsx-Controller1

Escape character is ^]

nsx-Controller1 login:

Una vez que NSX Controller arranque, se mostrará la consola de NSX Controller.






Interface: eth0

Address: 192.168.110.25/24


MTU: 1500



...


VMware, Inc. 54








Pasos siguientes


Unir NSX Controller al plano de administraciónUnir NSX Controller al plano de administración garantiza que NSX Manager y NSX Controller se puedencomunicar entre sí.

Requisitos previos

Compruebe que esté instalado NSX Manager.

Procedimiento

1 Abra una sesión SSH en NSX Manager.

2 Abra una sesión SSH para cada uno de los dispositivos NSX Controller.

Por ejemplo, NSX-Controller1, NSX-Controller2 y NSX-Controller3.

3 En NSX Manager, ejecute el comando get certificate api thumbprint. Por ejemplo,

NSX-Manager> get certificate api thumbprint

...

4 En cada uno de los dispositivos NSX Controller, ejecute el comando join management-plane.

Proporcione la siguiente información:

n Nombre de host o dirección IP del NSX Manager con un número de puerto opcional

n Nombre de usuario del NSX Manager

n Huella digital del certificado del NSX Manager


VMware, Inc. 55

n Contraseña del NSX Manager

NSX-Controller1> join management-plane NSX-Manager username admin thumbprint <NSX-Manager's-

thumbprint>

Password for API user: <NSX-Manager's-password>

Node successfully registered and controller restarted

Ejecute este comando en cada nodo de controladora.

Compruebe el resultado ejecutando el comando get managers en sus NSX Controller.

NSX-Controller1> get managers

- 192.168.110.47 Connected

En el dispositivo NSX Manager, ejecute el comando de get management-cluster status y asegúresede que se enumeran los NSX Controller.

NSX-Manager> get management-cluster status

Number of nodes in management cluster: 1

- 192.168.110.47 (UUID 45A8869B-BB90-495D-8A01-69B5FCC56086) Online

Management cluster status: STABLE

Number of nodes in control cluster: 3

- 192.168.110.201 (UUID 45A8869B-BB90-495D-8A01-69B5FCC56086)

- 192.168.110.202 (UUID 45A8869B-BB90-495D-8A01-69B5FCC56086)

- 192.168.110.203 (UUID 45A8869B-BB90-495D-8A01-69B5FCC56086)

Pasos siguientes

Inicialice el clúster de control. Consulte Inicializar el clúster de control para crear un maestro de clústeresde control..

Inicializar el clúster de control para crear un maestro declústeres de control.Tras instalar el primer NSX Controller en su implementación de NSX-T, puede inicializar el clúster decontrol. Inicializar el clúster de control es necesario aunque esté configurando un entorno de prueba deconcepto pequeño con un único nodo de controladora. Si no inicializa el clúster de control, ninguna desus controladoras podrá comunicarse con los hosts del hipervisor.

Requisitos previos

n Instale al menos un NSX Controller.

n Una los NSX Controller al plano de administración.

n Elija una contraseña secreta compartida. Una contraseña secreta compartida es una contraseñasecreta compartida definida por el usuario (por ejemplo, "secret123"). La contraseña debe ser comúnpara los tres nodos del clúster.


VMware, Inc. 56

Procedimiento

1 Abra una sesión SSH para su NSX Controller.

2 Ejecute el comando set control-cluster security-model shared-secret e introduzca unsecreto compartido cuando se le solicite.

3 Ejecute el comando initialize control-cluster.

Este comando convierte a esta controladora en el maestro de clústeres de control.

Por ejemplo:

NSX-Controller1> initialize control-cluster

Control cluster initialization successful.

Ejecute el comando get control-cluster status verbose y asegúrese de que es maestro (ismaster) y en mayoría (in majority) sean verdadero (true), el estado sea activo (active) e IP delservidor Zookeeper (Zookeeper Server IP) sea accesible, ok (reachable, ok).

nsx-controller1> get control-cluster status verbose

NSX Controller Status:

uuid: 78d5b561-4f66-488d-9e53-089735eac1c1

is master: true

in majority: true

uuid address status

78d5b561-4f66-488d-9e53-089735eac1c1 192.168.110.34 active

Cluster Management Server Status:

uuid rpc address rpc port global id

vpn address status

557a911f-41fd-4977-9c58-f3ef55b3efe7 192.168.110.34 7777 1

10.0.0.1 connected

Zookeeper Ensemble Status:

Zookeeper Server IP: 10.0.0.1, reachable, ok

Zookeeper version: 3.5.1-alpha--1, built on 03/08/2016 01:18 GMT

Latency min/avg/max: 0/0/1841

Received: 212095

Sent: 212125

Connections: 5

Outstanding: 0

Zxid: 0x10000017a

Mode: leader

Node count: 33

Connections: /10.0.0.1:51726[1]

(queued=0,recved=60324,sent=60324,sid=0x100000f14a10003,lop=PING,est=1459376913497,to=30000,lcxid=0x8,l

zxid=0x10000017a,lresp=604617273,llat=0,minlat=0,avglat=0,maxlat=1088)

/10.0.0.1:35462[0](queued=0,recved=1,sent=0)

/10.0.0.1:51724[1]

(queued=0,recved=45786,sent=45803,sid=0x100000f14a10001,lop=GETC,est=1459376911226,to=40000,lcxid=0x21e


VMware, Inc. 57

,lzxid=0x10000017a,lresp=604620658,llat=0,minlat=0,avglat=0,maxlat=1841)

/10.0.0.1:51725[1]

(queued=0,recved=60328,sent=60333,sid=0x100000f14a10002,lop=PING,est=1459376913455,to=30000,lcxid=0xc,l

zxid=0x10000017a,lresp=604618294,llat=0,minlat=0,avglat=0,maxlat=1356)

/10.0.0.1:51730[1]

(queued=0,recved=45315,sent=45324,sid=0x100000f14a10006,lop=PING,est=1459376914516,to=40000,lcxid=0x49,

lzxid=0x10000017a,lresp=604623243,llat=0,minlat=0,avglat=0,maxlat=1630)

Pasos siguientes

Agregue NSX Controller adicionales al clúster de control. Consulte Unir controladoras de NSXadicionales al maestro de clústeres.

Unir controladoras de NSX adicionales al maestro declústeresTener un clúster multinodo de NSX Controller ayuda a garantizar que siempre haya disponible al menosun NSX Controller.

Requisitos previos

n Instale tres dispositivos NSX Controller.

n Asegúrese de que los nodo de NSX Controller se unieron al plano de administración. Consulte UnirNSX Controller al plano de administración.

n Inicialice el clúster de control para crear un maestro de clústeres de control.

n En el comando join control-cluster, debe utilizar una dirección IP, no un nombre de dominio.

n Si está utilizando vCenter y está implementando componentes de NSX-T al mismo clúster,asegúrese de configurar reglas antiafinidad de DRS. Las reglas antiafinidad evitan que el DRS migremás de un nodo a un único host.

Procedimiento

1 Abra una sesión de SSH para cada uno de sus dispositivos NSX Controller.

Por ejemplo, NSX-Controller1, NSX-Controller2 y NSX-Controller3. En este ejemplo, NSX-Controller1ya inicializó el clúster de control y es el maestro de clústeres de control.


VMware, Inc. 58

2 En los NSX Controller no maestros, ejecute el comando set control-cluster security-modelcon una contraseña secreta compartida. La contraseña secreta compartida introducida para NSX-Controller2 y NSX-Controller3 debe coincidir con la contraseña secreta compartida introducida enNSX-Controller1.

Por ejemplo:

NSX-Controller2> set control-cluster security-model shared-secret secret <NSX-Controller1’s-shared-

secret-password>

Security secret successfully set on the node.

NSX-Controller3> set control-cluster security-model shared-secret secret <NSX-Controller1’s-shared-

secret-password>

Security secret successfully set on the node.

3 En los NSX Controller no maestros, ejecute el comando get control-cluster certificatethumbprint.

La salida de comandos es una cadena de números única para cada NSX Controller.

Por ejemplo:

NSX-Controller2> get control-cluster certificate thumbprint

...

NSX-Controller3> get control-cluster certificate thumbprint

...

4 En el NSX Controller maestro, ejecute el comando join control-cluster.


n Dirección IP con un número de puerto opcional de los NSX Controller no maestros (NSX-Controller2 y NSX-Controller3 en el ejemplo).

n Huella digital del certificado de los NSX Controller no maestros.

No ejecute los comandos join en varias controladoras en paralelo. Asegúrese de que cada unión secompleta antes de unirse a otra controladora.

NSX-Controller1> join control-cluster <NSX-Controller2-IP> thumbprint <nsx-controller2's-

thumbprint>

Node 192.168.210.48 has successfully joined the control cluster.

Please run 'activate control-cluster' command on the new node.


VMware, Inc. 59

Asegúrese de que NSX-Controller2 se unió al clúster ejecutando el comando get control-clusterstatus.

NSX-Controller1> join control-cluster <NSX-Controller3-IP> thumbprint <nsx-controller3's-

thumbprint>

Node 192.168.210.49 has successfully joined the control cluster.

Please run 'activate control-cluster' command on the new node.

Asegúrese de que NSX-Controller3 se unió al clúster ejecutando el comando get control-clusterstatus.

5 En los dos nodos de NSX Controller que se unieron al maestro de clústeres de control, ejecute elcomando activate control-cluster.

Nota No ejecute los comandos activate en varias controladoras en paralelo. Asegúrese de quecada activación se completa antes de activar otra controladora.

Por ejemplo:

NSX-Controller2> activate control-cluster

Control cluster activation successful.

En NSX-Controller2, ejecute el comando get control-cluster status verbose y asegúrese deque IP del servidor Zookeeper (Zookeeper Server IP) sea accesible, correcto(reachable, ok).

NSX-Controller3> activate control-cluster

Control cluster activation successful.

En NSX-Controller3, ejecute el comando get control-cluster status verbose y asegúrese deque la IP del servidor Zookeeper (Zookeeper Server IP) sea accesible, correcto(reachable, ok).

Compruebe el resultado ejecutando el comando get control-cluster status.

NSX-Controller1> get control-cluster status

uuid: db4aa77a-4397-4d65-ad33-9fde79ac3c5c

is master: true

in majority: true

uuid address status

0cfe232e-6c28-4fea-8aa4-b3518baef00d 192.168.210.47 active

bd257108-b94e-4e6d-8b19-7fa6c012961d 192.168.210.48 active

538be554-1240-40e4-8e94-1497e963a2aa 192.168.210.49 active


VMware, Inc. 60

El primer UUID enumerado es para el clúster de control en su totalidad. También tiene un UUID cadanodo de controladora.

Nota Si intenta unir una controladora a un clúster y falla el comando set control-clustersecurity-model o join control-cluster, los archivos de configuración del clúster podrían estar enun estado inconsistente. Para resolver este problema, realice los siguientes pasos:

n En la controladora a la que intenta unir el clúster, ejecute el comando deactivate control-cluster.

n En la controladora maestra, si el comando get control-cluster status o get control-cluster status verbose muestra información sobre la controladora que da error, ejecute elcomando detach control-cluster <IP address of failed controller>.

Pasos siguientes

Agregar hosts de hipervisor al tejido de NSX-T. Consulte Capítulo 7Preparación del host.


VMware, Inc. 61

Instalación de NSX Edge 6NSX Edge proporciona servicios de enrutamiento y conectividad a las redes externas a laimplementación de NSX-T. Se requiere un NSX Edge si quiere implementar un enrutador de nivel 0 o unenrutador de nivel 1 con traducción de direcciones IP (NAT).

NSX Edge dispone de los siguientes métodos de implementación compatibles:

n OVA/OVF

n ISO con PXE

n ISO sin PXE

NSX Edge solo es compatible en ESXi o sin sistema operativo. NSX Edge no es compatible con KVM.

Para la instalación de PXE, debe proporcionar la cadena de contraseña cifrada con el algoritmo sha-512para la contraseña de usuario administrador y raíz.

Los dispositivos NSX-T tienen los siguientes requisitos de complejidad para sus contraseñas:








n Sin palíndromos

La instalación se realizará correctamente aunque la contraseña no cumpla los requisitos de complejidad.Sin embargo, cuando inicie sesión por primera vez, se le pedirá que cambie la contraseña.

Nota Los servicios principales del dispositivo no se iniciarán hasta que se establezca una contraseñacon un nivel de complejidad suficiente.

Después de implementar NSX Edge desde un archivo OVA, no puede cambiar la configuración de la IPde la máquina virtual si apaga esta máquina virtual y modifica la configuración OVA en vCenter Server.

VMware, Inc. 62

Al instalar NSX Manager, elija un nombre de host que no contenga guiones bajos. Si especifica unnombre de host que contenga un guión bajo, después de la implementación el dispositivo tendrá unnombre de host predeterminado, como nsx-manager.



n Configuración de red de NSX Edge

n Instalar NSX Edge en ESXi utilizando una GUI

n Instalar NSX Edge en ESXi utilizando la herramienta OVF de la línea de comandos

n Instalar NSX Edge mediante un archivo ISO con un servidor PXE

n Instalar NSX Edge sin sistema operativo

n Instalar NSX Edge mediante un archivo ISO como un dispositivo virtual

n Unir NSX Edge al plano de administración

Configuración de red de NSX EdgeNSX Edge se puede instalar mediante arranque ISO, OVA/OVF o PXE. Independientemente del métodode instalación, asegúrese de que la red del host esté preparada antes de instalar NSX Edge.

Vista de alto nivel de NSX Edge dentro de una zona de transporteLa vista de alto nivel de NSX-T muestra dos nodos de transporte en una zona de transporte. Un nodo detransporte es un host. El otro es un NSX Edge.


VMware, Inc. 63

Figura 6‑1. Vista de alto nivel de NSX Edge

DR

SR

DR

SR

DR denivel 0

Nodo detransporte

de host

Nodo de transporte de NSX Edge

LCP

MP

CCP

Zona detransporte

Conmutadorde host

Nivel 0

Nivel 1

pnic1 pnic2

Tránsito interno de nivel 1 169.254.0.0/28

Enrutador de nivel 0-nivel 1 100.64.1.0/24

Tránsito interno de nivel 0 169.254.0.0/28

Puertos físicos defp-ethX de vmxnet3administrados mediantela ruta de acceso a los datos

vínculo

DR denivel 1

Cuando implementa NSX Edge por primera vez, puede verlo como un contenedor vacío. NSX Edge nohace nada hasta que usted crea los enrutadores lógicos. NSX Edge proporciona respaldo de procesopara enrutadores lógicos de nivel 0 y 1. Cada enrutador lógico contiene un enrutador de servicios (SR) yun enrutador distribuido (DR). Cuando decimos que un enrutador es distribuido, queremos decir que estáreplicado en todos los nodos de transporte que pertenecen a la misma zona de transporte. En la figura,el nodo de transporte del host contiene los mismos enrutadores distribuidos (DR) contenidos en losenrutadores de nivel 0 y 1. Se requiere un enrutador de servicios si el enrutador lógico se va a configurarpara realizar servicios, como NAT. Todos los enrutadores lógicos de nivel 0 tienen un enrutador deservicios. Un enrutador de nivel 1 puede tener un enrutador de servicios si fuese necesario teniendo encuenta sus consideraciones de diseño.

De manera predeterminada, los vínculos entre el SR y el DR utilizan la subred 169.254.0.0/28. Estosvínculos de tránsito entre enrutadores se crean automáticamente al implementar un enrutador lógico denivel 0 o 1. No tiene que configurar ni modificar la configuración de vínculo salvo que ya se estéutilizando la subred 169.254.0.0/28 en su implementación. Tenga en cuenta que en un enrutador lógicode nivel 1, el SR solo está presente si selecciona un clúster de NSX Edge al crear el enrutador lógico denivel 1.

El espacio de dirección predeterminado asignado a las conexiones de nivel 0 a nivel 1 es 100.64.0.0/10.A cada conexión del mismo nivel de nivel 0 a nivel 1 se le proporciona una subred /31 dentro del espaciode direcciones 100.64.0.0/10. Este vínculo se crea de forma automática al crear un enrutador de nivel 1 yconectarlo a un enrutador de nivel 0. No tiene que configurar ni modificar las interfaces de este vínculosalvo que ya se esté utilizando la subred 100.64.0.0/10 en su implementación.


VMware, Inc. 64

Todas las implementaciones de NSX-T tienen un clúster de plano de administración (MP) y un clúster deplano de control (CCP). El MP y el CCP insertan configuraciones en el plano de control local (LCP) decada zona de transporte. Cuando un host o NSX Edge se une al plano de administración, el agente delplano de administración (MPA) establece la conectividad con el host o NSX Edge, y el host o NSX Edgese convierten en un nodo de tejido de NSX-T. Cuando el nodo de tejido se agrega a continuación comoun nodo de transporte, se establece la conectividad del LCP con el host o NSX Edge.

Por último, la figura muestra un ejemplo de dos NIC físicas (pnic1 y pnic2) que se conectan paraproporcionar una alta disponibilidad. Estas NIC físicas son administradas mediante la ruta de acceso alos datos. Pueden servir como vínculos superiores de VLAN a una red externa o como vínculos deendpoints de túnel a redes de máquinas virtuales (VM) internas administradas por NSX-T.

Un procedimiento recomendado consiste en asignar al menos dos vínculos físicos a cada NSX Edge. Deforma opcional, puede solapar los grupos de puertos en la misma NIC física utilizando distintos ID deVLAN. El primer vínculo de red se utiliza para la administración. Por ejemplo, en una VM de NSX Edge,el primer vínculo hallado podría ser vnic1. En una instalación sin sistema operativo, el primer vínculohallado podría ser eth0 o em0. Los vínculos restantes se utilizan para los vínculos superiores y túneles.Por ejemplo, uno podría ser para un endpoint de túnel utilizado por las VM administradas por NSX-T. Elotro podría utilizarse para un vínculo superior de NSX Edge a TOR externo.

Puede ver la información del vínculo físico en la interfaz de línea de comandos (CLI) de NSX Edgeejecutando los comandos get interfaces y get physical-ports. En la API, puede utilizar la llamadaAPI GET fabric/nodes/<edge-node-id>/network/interfaces. En la siguiente sección se hablasobre los vínculos físicos en mayor profundidad.

Independientemente de que instale NSX Edge como un dispositivo de VM o sin sistema operativo,dispone de varias opciones para configurar la red en función de la implementación que lleve a cabo.

Zonas de transporte y conmutadores de hostPara comprender las redes de NSX Edge, debe saber algo sobre zonas de transporte y conmutadoresde host. Las zonas de transporte controlan el alcance de las redes de Capa 2 en NSX-T. Un conmutadorde host es un conmutador de software que se crea en un nodo de transporte. El propósito de unconmutador de host es asociar vínculos superiores e inferiores de enrutador lógico a tarjetas NIC físicas.Para cada zona de transporte a la que pertenece un NSX Edge, se instala un conmutador de hostindividual en el NSX Edge.

Hay dos tipos de zonas de transporte:

n Superposición para tunelización de NSX-T interna entre nodos de transporte. El NSX Edge solopuede pertenecer a una zona de transporte superpuesta.

n VLAN para vínculos superiores externos a NSX-T. No hay restricción con respecto al número dezonas de transporte de VLAN a las que puede pertenecer un NSX Edge.


VMware, Inc. 65

Un NSX Edge puede pertenecer a cero zonas de transporte VLAN o a muchas. En el caso de cerozonas de transporte VLAN, el NSX Edge sigue pudiendo tener vínculos superiores porque losvínculos superiores de NSX Edge pueden utilizar el mismo conmutador de host instalado para lazona de transporte superpuesta. Debería hacer esto si quiere que cada NSX Edge tenga solamenteun conmutador de host. Otra opción de diseño consiste en que el NSX Edge pertenezca a variaszonas de transporte VLAN, una para cada vínculo superior.

La opción de diseño más común está compuesta por tres zonas de transporte: una zona de transportesuperpuesta y dos zonas de transporte VLAN para vínculos superiores redundantes.

Tenga en cuenta que si necesita utilizar el mismo ID de VLAN para una red de transporte para el tráficosuperpuesto y para otro tráfico VLAN, como para un vínculo superior de VLAN, debe configurarlos endos conmutadores de host diferentes: uno para VLAN y el otro para la superposición.

Para obtener más información sobre las zonas de transporte, consulte Acerca de las zonas detransporte.

Redes de NSX Edge de dispositivos virtuales/VMCuando instala NSX Edge como un dispositivo virtual o VM, se crean interfaces internas, llamadas fp-ethX, donde X es 0, 1, 2 y 3. Estas interfaces se asignan para vínculos superiores a conmutadores paraparte superior del rack (TOR) y para la tunelización superpuesta de NSX-T.

Cuando cree el nodo de transporte de NSX Edge, puede seleccionar interfaces fp-ethX para asociarlas alos vínculos superiores y al túnel superpuesto. Puede decidir cómo utilizar las interfaces fp-ethX.

En el conmutador distribuido de vSphere o el conmutador vSphere Standard, debe asignar al menos dosvmnics al NSX Edge: uno para la administración de NSX Edge y otro para vínculos superiores y túneles.

En la siguiente topología física de ejemplo, se utiliza fp-eth0 para el túnel superpuesto de NSX-T. fp-eth1se utiliza para el vínculo superior de VLAN. fp-eth2 y fp-eth3 no se utilizan.

Figura 6‑2. Una configuración recomendada de vínculo para redes de VM de NSX Edge

Túnel asociado

VM de NSX Edge

fp-eth0Conmutador de host

superpuesto

Conmutador de host devínculo superior de VLAN

fp-eth1

fp-eth2

vNIC3 devínculo superior

(No utilizado) vNIC4

fp-eth3(No utilizado) vNIC5

eth0vNIC1 de adm.

VM

ESXi

VDS/VSS

vmnic0

vmnic1


VMware, Inc. 66

El NSX Edge que se muestra en este ejemplo pertenece a dos zonas de transporte (una superpuesta yuna de VLAN) y, por lo tanto, tiene dos conmutadores de host, uno para el túnel y otro para el tráfico devínculos superiores.

Esta captura de pantalla muestra los grupos de puertos de máquinas virtuales, el túnel de NSX y elvínculo superior de VLAN.

Durante la implementación debe especificar los nombres de red que se corresponden con los nombresconfigurados en sus grupos de puertos de VM. Por ejemplo, para que se correspondan con los grupos depuertos de VM del ejemplo, su configuración de ovftool de red sería tal como se indica a continuación siutilizarse la ovftool para implementar NSX Edge:

--net:"Network 0-Mgmt" --net:"Network 1-nsx-tunnel" --net:"Network 2-vlan-uplink"

El ejemplo mostrado aquí utiliza los nombres de grupos de puertos de VM Mgmt, nsx-tunnel y vlan-uplink. Este es solo un ejemplo. Puede utilizar el nombre que quiera para sus grupos de puertos de VM.

Los grupos de puertos de VM de vínculos superiores y túnel configurados para el NSX Edge no tienenque asociarse a puertos VMkernel ni a direcciones IP proporcionadas. Esto se debe a que solo seutilizan en la Capa 2. Si su implementación va a utilizar DHCP para proporcionar una dirección a lainterfaz de administración, asegúrese de que solo se asigne la NIC a la red de administración.

Tenga en cuenta que los grupos de puertos de túnel y VLAN se configuran como puertos troncales. Estoes obligatorio. Por ejemplo, en un vSwitch estándar, los puertos troncales se configuran de la siguientemanera: Host (Host)> Configuración (Configuración ) > Redes (Networking) > Agregar redes (AddNetworking) > Máquina virtual (Virtual Machine) > ID VLAN todos (VLAN ID All) (4095).

Si está utilizando un NSX Edge de VM o basado en dispositivo, puede utilizar conmutadores vSwitch oconmutadores distribuidos vSphere.

Se puede implementar un NSX Edge y un nodo de transporte de host en el mismo hipervisor.

De forma opcional, puede instalar varios dispositivos/VM de NSX Edge en un mismo host, y todos losNSX Edge instalados pueden utilizar los grupos de puertos de endpoint de túnel.

Una vez que estén configurados los grupos de puertos de VM y los vínculos físicos subyacentes activos,puede instalar el NSX Edge.


VMware, Inc. 67

Redes de NSX Edge sin sistema operativoEl NSX Edge sin sistema operativo contiene interfaces denominadas fp-ethX, donde X es 0, 1, 2, 3, y asísucesivamente. El número de interfaces fp-ethX creado depende de cuántas NIC físicas tenga suNSX Edge sin sistema operativo. Algunas de estas interfaces o todas ellas se pueden asignar paravínculos superiores a conmutadores para parte superior de bastidor rack (ToR) y tunelizaciónsuperpuesta de NSX-T.

Cuando cree el nodo de transporte de NSX Edge, puede seleccionar interfaces fp-ethX para asociarlas alos vínculos superiores y al túnel superpuesto.

Puede decidir cómo utilizar las interfaces fp-ethX. En la siguiente topología física de ejemplo, se asociany utilizan fp-eth0 y fp-eth1 para el túnel superpuesto de NSX-T. fp-eth2 y fp-eth3 se utilizan comovínculos superiores de VLAN a las TOR.

Figura 6‑3. Una configuración recomendada de vínculo para redes de NSX Edge sin sistemaoperativo

Túnel asociado

Nodo de transporte de NSX Edgesin sistema operativo

fp-eth0Conmutador de host

superpuesto

Conmutador de host devínculo superior de VLAN

fp-eth1

fp-eth2

fp-eth3

Vínculosuperior 1

Vínculosuperior 2

eth3eth4

eth0

eth1eth2

Admin.

Redundancia de vínculos superiores de NSX EdgeLa redundancia de vínculos superiores de NSX Edge permite utilizar dos vínculos superiores Multipathde igual coste (ECMP) en la conexión de red de NSX Edge a TOR externa.

Si tiene dos vínculos superiores de VLAN ECMP, también debe tener dos conmutadores TOR paradisfrutar de una alta disponibilidad y una conectividad totalmente de malla. Cada conmutador lógico deVLAN tienen asociado un ID de VLAN.

Cuando agrega un NSX Edge a una zona de transporte de VLAN, se instala un nuevo conmutador dehost. Por ejemplo, si agrega un nodo de NSX Edge a cuatro zonas de transporte VLAN, tal como semuestra en la figura, se instalan cuatro conmutadores de host en el NSX Edge.


VMware, Inc. 68

Figura 6‑4. Una configuración recomendada de VLAN ECMP para NSX Edge a TOR.

enrutador lógico de nivel 0

ToR

conmutadorlógico deVLAN 100

VLAN TZ


VLAN TZ


VLAN TZ


VLAN TZ

VLAN 100 VLAN 300 VLAN 200 VLAN 400

ToR

NSX Edge

enrutador lógico de nivel 0

NSX Edge

Instalar NSX Edge en ESXi utilizando una GUISi prefiere una instalación interactiva de NSX Edge, puede utilizar una herramienta de administración deVM basada en IU, como vSphere Client conectado a vCenter Server.

Esta versión de NSX-T no es compatible con IPv6.

Requisitos previos








VMware, Inc. 69

n Elija nombres de host que no incluyan guiones bajos. De lo contrario, el nombre de host se estableceen localhost.

n Una herramienta de administración que puede implementar plantillas OVF, como el vCenter Server ovSphere Client.

La herramienta de implementación de OVF debe admitir opciones de configuración que permitanrealizar la configuración de forma manual.

n Debe estar instalado el complemento de integración de clientes.

n Consulte los requisitos de red de NSX Edge en Configuración de red de NSX Edge.

Procedimiento

1 Localice el archivo OVA u OVF de NSX Edge.


2 En la herramienta de administración, inicie el asistente Implementar plantilla OVF (Deploy OVFtemplate) y vaya al archivo .ova o establezca un vínculo con él.

3 Introduzca un nombre para el NSX Edge y seleccione una carpeta o centro de datos.


La carpeta que seleccione se utilizará para aplicar permisos al NSX Edge.

4 Seleccione un tamaño de configuración: pequeño, medio o grande.

Los requisitos del sistema varían en función del tamaño de configuración. Consulte la Notas de laversión de NSX-T.

5 Seleccione un almacén de datos para almacenar los archivos de dispositivos virtuales del NSX Edge.

6 Si está realizando la instalación en vCenter, seleccione un host o clúster sobre el que implementar eldispositivo NSX Edge.

Por lo general, colocaría el NSX Edge en un clúster que proporcione utilidades de administración deredes.

7 Seleccione las redes sobre las que colocar las interfaces de NSX Edge.

Puede cambiar las redes después de que se implemente el NSX Edge.


VMware, Inc. 70

8 Establezca la contraseña y la configuración de direcciones IP de NSX Edge.

Por ejemplo, esta pantalla muestra la pantalla de revisión final después de que se configuraron todaslas opciones.



Abra la consola del componente NSX Edge para hacer un seguimiento del proceso de arranque. Si no seabre la ventana, asegúrese de que no estén bloqueadas las ventanas emergentes.

Una vez que NSX Edge termine de arrancar, inicie sesión en la interfaz de línea de comandos (CLI) yejecute el comando get interface eth0 para comprobar que la dirección IP se aplicó según loesperado.

nsx-edge-1> get interface eth0

Interface: eth0

Address: 192.168.110.37/24

MAC address: 00:50:56:86:62:4d


VMware, Inc. 71

MTU: 1500



...

Si fuese necesario, ejecute el comando set interface eth0 ip <CIDR> gateway <gateway-ip>plane mgmt para actualizar la interfaz de administración. De forma opcional, puede iniciar el servicioSSH con el comando start service ssh.

Asegúrese de que su dispositivo NSX Edge tenga la conectividad requerida.

n Asegúrese de que pueda hacer ping a su NSX Edge.

n Asegúrese de que NSX Edge puede hacer ping a su puerta de enlace predeterminada.

n Asegúrese de que NSX Edge puede hacer ping a los hosts del hipervisor que estén en la misma redque NSX Edge.

n Asegúrese de que NSX Edge puede hacer ping a su servidor DNS y a su servidor NTP.

n Si habilitó SSH, asegúrese de que puede utilizar SSH con su NSX Edge.

Nota Si no se estableció la conectividad, asegúrese de que el adaptador de red de la máquina virtualesté en la VLAN o red adecuada.

De forma predeterminada, la ruta de acceso a datos de NSX Edge reclama todas las NIC de máquinasvirtuales a excepción de la NIC de administración (la que tiene una dirección IP y una rutapredeterminada). Si DHCP asigna una NIC errónea como NIC de administración, puede corregirlo de lasiguiente manera:

1 stop service dataplane

2 set interface eth0 dhcp plane mgmt

3 Coloque eth0 en la red DHCP y espere a que se asigne una dirección IP a eth0.

4 start service dataplane

Los puertos fp-ethX de la ruta de datos utilizados para el vínculo superior VLAN y la superposición detúnel se muestran en los comandos get interfaces y get physical-port en NSX Edge.

Pasos siguientes

Una el NSX Edge al plano de administración. Consulte Unir NSX Edge al plano de administración.

Instalar NSX Edge en ESXi utilizando la herramienta OVFde la línea de comandosSi prefiere automatizar la instalación de NSX Edge, puede utilizar la herramienta OVF de VMware, quees una utilidad de línea de comandos.

Esta versión de NSX-T no es compatible con IPv6.


VMware, Inc. 72

Requisitos previos








n Elija nombres de host que no incluyan guiones bajos. De lo contrario, el nombre de host se estableceen localhost.

n Herramienta OVF, versión 4.0 o posterior.

Procedimiento

n (Para un host independiente) Ejecute el comando ovftool con los parámetros adecuados.


--name=nsx-edge-1

--deploymentOption=medium

--X:injectOvfEnv


--allowExtraConfig

--datastore=ds1

--net:"Network 0=Mgmt"

--net:"Network 1=nsx-tunnel"

--net:"Network 2=vlan-uplink"


--acceptAllEulas

--noSSLVerify

--diskMode=thin

--powerOn

--prop:nsx_ip_0=192.168.110.37



--prop:nsx_dns1_0=192.168.110.10


--prop:nsx_ntp_0=192.168.110.10

--prop:nsx_isSSHEnabled=True

--prop:nsx_allowSSHRootLogin=True




VMware, Inc. 73

--prop:nsx_hostname=nsx-edge






Opening VI target: vi://[email protected]

Deploying to VI: vi://[email protected]

Transfer Completed

Powering on VM: nsx-edge-1

Task Completed

Warning:






n (Para un host administrado por vCenter Server) Ejecute el comando ovftool con los parámetrosadecuados.


--name=nsx-edge-1

--deploymentOption=medium

--X:injectOvfEnv


--allowExtraConfig

--datastore=ds1

--net:"Network 0=Mgmt"

--net:"Network 1=nsx-tunnel"



--acceptAllEulas

--noSSLVerify

--diskMode=thin

--powerOn

--prop:nsx_ip_0=192.168.110.37



--prop:nsx_dns1_0=192.168.110.10


--prop:nsx_ntp_0=192.168.110.10

--prop:nsx_isSSHEnabled=True

--prop:nsx_allowSSHRootLogin=True




VMware, Inc. 74

--prop:nsx_hostname=nsx-edge






Opening VI target: vi://[email protected]@192.168.110.24:443/

Deploying to VI: vi://[email protected]@192.168.110.24:443/

Transfer Completed

Powering on VM: nsx-edge-1

Task Completed

Warning:











Interface: eth0

Address: 192.168.110.37/24

MAC address: 00:50:56:86:62:4d

MTU: 1500



...





VMware, Inc. 75












Pasos siguientes


Instalar NSX Edge mediante un archivo ISO con unservidor PXEPuede instalar dispositivos de NSX Edge de forma automatizada en un sistema sin sistema operativo ocomo una VM utilizando PXE. Tenga en cuenta que la instalación de arranque de PXE no es compatiblecon NSX Manager ni con NSX Controller. Esto incluye el ajuste automático de la configuración de red,como dirección IP, puerta de enlace, máscara de red, NTP y DNS.

Este procedimiento demuestra cómo configurar un servidor PXE en Ubuntu. PXE está formado por doscomponentes: DHCP y TFTP.

DHCP distribuye dinámicamente ajustes de IP a componentes de NSX-T, como NSX Edge. En unentorno PXE, el servidor DHCP permite a NSX Edge solicitar y recibir automáticamente una dirección IP.

TFTP es un protocolo de transferencia de archivos. El servidor TFTP siempre está escuchando en buscade clientes de PXE en la red. Si detecta que hay algún cliente PXE de la red solicitando servicios PXE,proporciona el archivo ISO del componente NSX-T y la configuración de instalación contenida en unarchivo de preconfiguración.

Una vez que esté listo el servidor PXE, el procedimiento muestra cómo instalar NSX Edge con un archivode configuración preconfigurado.


VMware, Inc. 76

Requisitos previos







n Un servidor PXE debe estar disponible en su entorno de implementación. El servidor PXE se puedeestablecer en cualquier distribución de Linux. El servidor PXE debe tener dos interfaces, una para lascomunicaciones externas y otra para suministrar los servicios TFTP y DHCP IP.

Procedimiento

1 (opcional) Cree un archivo inicial.

Un archivo inicial es un archivo de texto que contiene comandos CLI que normalmente ejecutaría enel dispositivo tras el primer arranque.

El archivo inicial debe recibir un nombre

nsxcli.install

y debe copiarse en su servidor web, por ejemplo en /var/www/html/nsx-edge/nsxcli.install.

En el archivo inicial, puede agregar los comandos CLI deseados.

Por ejemplo:

Para configurar la dirección IP de la interfaz de administración:

stop dataplane

set interface eth0 <ip-cidr-format> plane mgmt

start dataplane

Para cambiar la contraseña del usuario administrador:

set user admin password <password>

Tenga en cuenta que, si especifica una contraseña en el archivo preseed.cfg, debe utilizar la mismacontraseña en el archivo inicial. De lo contrario, utilice la contraseña predeterminada, que es"default".


VMware, Inc. 77

Para unir el NSX Edge al plano de administración:

join management-plane <mgr-ip> thumbprint <mgr-thumbprint> username <mgr-username> password <mgr

password>

2 Cree dos interfaces, una para administración y otra para servicios DHCP y TFTP.

Asegúrese de que la interfaz DHCP/TFTP esté en la misma subred en la que residirá el NSX Edge.

Por ejemplo, si las interfaces de administración del NSX Edge van a estar en la subred192.168.210.0/24, coloque eth1 en esa misma subred.

# The loopback network interface

auto lo

iface lo inet loopback

# PXE server's management interface

auto eth0

iface eth0 inet static

address 192.168.110.81

gateway 192.168.110.1

netmask 255.255.255.0

dns-nameservers 192.168.110.10

# PXE server's DHCP/TFTP interface

auto eth1

iface eth1 inet static

address 192.168.210.82

gateway 192.168.210.1

netmask 255.255.255.0

dns-nameservers 192.168.110.10

3 Instale el software de servidor DHCP.

sudo apt-get install isc-dhcp-server -y

4 Edite el archivo /etc/default/isc-dhcp-server y agregue la interfaz que suministra el servicioDHCP.

INTERFACES="eth1"

5 (Opcional) Si quiere que este servidor DHCP sea el servidor DHCP oficial de la red local, quite lamarca de comentario de la línea authoritative; del archivo /etc/dhcp/dhcpd.conf.

...

authoritative;

...


VMware, Inc. 78

6 En /etc/dhcp/dhcpd.conf, defina la configuración DHCP.

Por ejemplo:

subnet 192.168.210.0 netmask 255.255.255.0 {

range 192.168.210.90 192.168.210.95;

option subnet-mask 255.255.255.0;

option domain-name-servers 192.168.110.10;

option routers 192.168.210.1;

option broadcast-address 192.168.210.255;

default-lease-time 600;

max-lease-time 7200;

}

7 Inicie el servicio DHCP.

sudo service isc-dhcp-server start

8 Asegúrese de que se esté ejecutando el servicio DHCP.

service --status-all | grep dhcp

9 Instale Apache, TFTP y el resto de componentes necesarios requeridos para el arranque de PXE.

sudo apt-get install apache2 tftpd-hpa inetutils-inetd

10 Asegúrese de que el servidor TFTP y Apache se estén ejecutando.

service --status-all | grep tftpd-hpa

service --status-all | grep apache2

11 Agregue las siguientes líneas al archivo /etc/default/tftpd-hpa.

RUN_DAEMON="yes"

OPTIONS="-l -s /var/lib/tftpboot"

12 Agregue la siguiente línea al archivo /etc/inetd.conf.

tftp dgram udp wait root /usr/sbin/in.tftpd /usr/sbin/in.tftpd -s /var/lib/tftpboot

13 Reinicie el servicio TFTP.

sudo /etc/init.d/tftpd-hpa restart

14 Copie o descargue el archivo ISO del instalador de NSX Edge en la ubicación adecuada.


VMware, Inc. 79

15 Monte el archivo ISO y copie los componentes de instalación en el servidor TFTP y el servidorApache.

sudo mount -o loop ~/nsx-edge.<build>.iso /mnt

cd /mnt

sudo cp -fr install/netboot/* /var/lib/tftpboot/

sudo mkdir /var/www/html/nsx-edge

sudo cp -fr /mnt/* /var/www/html/nsx-edge/

16 (Opcional) Edite el archivo /var/www/html/nsx-edge/preseed.cfg para modificar las contraseñascifradas.

Puede utilizar una herramienta Linux como mkpasswd para crear un hash de contraseña.

sudo apt-get install whois

sudo mkpasswd -m sha-512

Password:

$6$SUFGqs[...]FcoHLijOuFD

Para modificar la contraseña raíz, edite el archivo /var/www/html/nsx-edge/preseed.cfg ybusque la siguiente línea:

d-i passwd/root-password-crypted password $6$tgmLNLMp$9BuAHhN...

Reemplace la cadena hash. No es necesario escapar ningún carácter especial, como $, ', " o \.

También puede agregar el comando usermod al archivo preseed.cfg para establecer la contraseñapara raíz, administrador o para ambos. Por ejemplo, puede agregar las dos líneas siguientes:

usermod --password '\$6\$VS3exId0aKmzW\$U3g0V7BF0DXlmRI.LR0v/VgloxVotEDp00bO2hUF8u/' root; \

usermod --password '\$6\$VS3exId0aKmzW\$U3g0V7BF0DXlmRI.LR0v/VgloxVotEDp00bO2hUF8u/' admin; \

La cadena hash solo es un ejemplo. Debe escapar todos los caracteres especiales. La contraseñaraíz del primer comando usermod reemplaza a la contraseña establecida en d-i passwd/root-password-crypted password $6$tgm....

Si utiliza el comando usermod para establecer la contraseña, no se pide al usuario que cambie lacontraseña tras iniciar sesión por primera vez. De lo contrario, el usuario deberá cambia lacontraseña al iniciar sesión por primera vez.

17 Agregue las siguientes líneas al archivo /var/lib/tftpboot/pxelinux.cfg/default.

Asegúrese de reemplazar 192.168.210.82 con la dirección IP de su servidor TFTP.

label nsxedge

kernel ubuntu-installer/amd64/linux

ipappend 2

append netcfg/dhcp_timeout=60 auto=true priority=critical vga=normal partman-

lvm/device_remove_lvm=true netcfg/choose_interface=auto debian-


VMware, Inc. 80

installer/allow_unauthenticated=true preseed/url=http://192.168.210.82/nsx-edge/preseed.cfg

mirror/country=manual mirror/http/hostname=192.168.210.82 nsx-

kickstart/url=http://192.168.210.82/nsx-edge/nsxcli.install mirror/http/directory=/nsx-edge

initrd=ubuntu-installer/amd64/initrd.gz mirror/suite=trusty --

18 Agregue las siguientes líneas al archivo /etc/dhcp/dhcpd.conf.

Asegúrese de reemplazar 192.168.210.82 con la dirección IP de su servidor DHCP.

allow booting;

allow bootp;

next-server 192.168.210.82; #Replace this IP address

filename "pxelinux.0";

19 Reinicie el servicio DHCP.

sudo service isc-dhcp-server restart

Nota Si se devuelve un error (por ejemplo: "parada: Instancia desconocida: inicio: No se pudoiniciar el trabajo" [stop: Unknown instance: start: Job failed to start]), ejecutesudo /etc/init.d/isc-dhcp-server stop y, a continuación, sudo /etc/init.d/isc-dhcp-server start. El comando sudo /etc/init.d/isc-dhcp-server start devuelve informaciónsobre el origen del error.

20 Utilice las instrucciones de instalación sin sistema operativo o las instrucciones de instalación ISOpara completar la instalación.

n Instalar NSX Edge sin sistema operativo

n Instalar NSX Edge mediante un archivo ISO como un dispositivo virtual

21 Encienda la máquina virtual (VM).

22 En el menú de arranque, seleccione nsxedge.

La red se configura automáticamente, se crean las particiones y se instalan los componentes deNSX Edge.

Cuando se muestra la solicitud de inicio de sesión de NSX Edge, puede iniciar sesión comoadministrador o raíz.

De forma predeterminada, la contraseña raíz de inicio de sesión es vmware y la contraseña de iniciode sesión de administración es default.




VMware, Inc. 81




Interface: eth0

Address: 192.168.110.37/24

MAC address: 00:50:56:86:62:4d

MTU: 1500



...
















VMware, Inc. 82

Pasos siguientes


Instalar NSX Edge sin sistema operativoPuede instalar dispositivos de NSX Edge de forma manual en un equipo sin sistema operativo utilizandoun archivo ISO. Esto incluye el ajuste de la configuración de red, como dirección IP, puerta de enlace,máscara de red, NTP y DNS. Este método de instalación se suele utilizar en un laboratorio de prueba deconcepto (POC) sin acceso a un servidor PXE.

Requisitos previos







Procedimiento

1 Cree un archivo de arranque con el archivo ISO de NSX Edge en él.

2 Arranque el host desde el disco.

3 Seleccione Instalación automatizada (Automated installation).

Después de pulsar la tecla Intro podría haber una pausa de 10 segundos.

Durante el encendido, el instalador solicita una configuración de red mediante DHCP. Si DHCP noestá disponible en su entorno, el instalador le pide la configuración de IP.






VMware, Inc. 83



Interface: eth0

Address: 192.168.110.37/24

MAC address: 00:50:56:86:62:4d

MTU: 1500



...















Pasos siguientes



VMware, Inc. 84

Instalar NSX Edge mediante un archivo ISO como undispositivo virtualPuede instalar dispositivos de NSX Edge de forma manual utilizando un archivo ISO. Este método deinstalación se suele utilizar en un laboratorio de prueba de concepto (POC) sin acceso a un servidorPXE.


Requisitos previos







Procedimiento

1 En un host independiente o en vCenter Web Client, cree una VM y asigne los siguientes recursos:

n Sistema operativo de invitado: otro (64 bits).

n 3 NIC VMXNET3. NSX Edge no es compatible con el controlador de NIC e1000.

n Los recursos de sistema adecuados requeridos para su implementación de NSX-T.


VMware, Inc. 85

2 Enlace el archivo ISO de NSX Edge a la VM.

Asegúrese de que el estado del dispositivo de la unidad de CD/DVD esté establecido en Conectaren el encendido (Connect at power on).

3 Durante el arranque ISO, abra la consola de VM y seleccione Instalación automatizada (Automatedinstallation).

Después de pulsar la tecla Intro, podría haber una pausa de 10 segundos.

Durante el encendido, la VM solicita una configuración de red mediante DHCP. Si DHCP no estádisponible en su entorno, el instalador le pide la configuración de IP.


Cuando inicie sesión por primera vez, se le pedirá que cambie la contraseña. Este método de cambiode contraseña tiene reglas estrictas de complejidad, incluyendo las siguientes:





VMware, Inc. 86





n Sin palíndromos

Importante Los servicios principales del dispositivo no se iniciarán hasta que se establezca unacontraseña con un nivel de complejidad suficiente.






Interface: eth0

Address: 192.168.110.37/24

MAC address: 00:50:56:86:62:4d

MTU: 1500



...








VMware, Inc. 87









Pasos siguientes

Una NSX Edge al plano de administración. Consulte Unir NSX Edge al plano de administración.

Unir NSX Edge al plano de administraciónUnir NSX Edge al plano de administración garantiza que NSX Manager y NSX Edge se puedencomunicar entre sí.

Procedimiento

1 Abra una sesión SSH en el dispositivo de NSX Manager.

2 Abra una sesión SSH en el NSX Edge.

3 En el dispositivo NSX Manager, ejecute el comando get certificate api thumbprint.

La salida de comandos es una cadena de números única para este NSX Manager.

Por ejemplo:

NSX-Manager1> get certificate api thumbprint

...

4 En el NSX Edge, ejecute el comando join management-plane.


n Nombre de host o dirección IP del NSX Manager con un número de puerto opcional

n Nombre de usuario del NSX Manager

n Huella digital del certificado del NSX Manager


VMware, Inc. 88

n Contraseña del NSX Manager

NSX-Edge1> join management-plane NSX-Manager1 username admin thumbprint <NSX-Manager1's-thumbprint>

Password for API user: <NSX-Manager1's-password>

Node successfully registered and Edge restarted

Repita este comando en cada nodo de NSX Edge.

Compruebe el resultado ejecutando el comando get managers en sus NSX Edge.

nsx-edge-1> get managers

- 192.168.110.47 Connected

En la IU NSX Manager, el NSX Edge aparece en la página Tejido (Fabric) > Servidores perimetrales(Edges). La conectividad del MPA debe estar Activa (Up). Si la conectividad del MPA no está Activa (Up),actualice la pantalla del explorador.

Pasos siguientes

Agregue los NSX Edge como nodos de transporte. Consulte Crear un nodo de transporte de NSX Edge.


VMware, Inc. 89

Preparación del host 7Cuando los hosts del hipervisor están preparados para operar con NSX-T, se les denomina nodos detejido. Los hosts que son nodos de tejido tienen módulos de NSX-T instalados y están registrados en elplano de administración de NSX-T.


n Instalar paquetes de terceros en un host de KVM

n Agregar un host de hipervisor al tejido de NSX-T

n Instalación manual de módulos kernel NSX-T

n Unir los hosts del hipervisor al plano de administración

Instalar paquetes de terceros en un host de KVMPara preparar un host de KVM para que se convierta en un nodo de tejido, debe instalar algunospaquetes de terceros.

Procedimiento

n Para Ubuntu 14.04, ejecute estos comandos:

apt-get install libunwind8 libgflags2 libgoogle-perftools4 traceroute

apt-get install python-mako python-simplejson python-support python-unittest2 python-yaml python-

netaddr

apt-get install libprotobuf8

apt-get install libboost-filesystem1.54.0 libboost-chrono1.54.0

apt-get install dkms

n Para Ubuntu 16.04, ejecute estos comandos:

apt-get install libunwind8 libgflags2v5 libgoogle-perftools4 traceroute

apt-get install python-mako python-simplejson python-unittest2 python-yaml python-netaddr

apt-get install libprotobuf9v5

apt-get install libboost-filesystem1.58.0 libboost-chrono1.58.0 libgoogle-glog0v5

apt-get install dkms

VMware, Inc. 90

n Para RHEL 7.2, ejecute estos comandos:

yum groupinstall “Virtualization Hypervisor”

yum groupinstall “Virtualization Client”

yum groupinstall "Virtualization Platform"

yum groupinstall "Virtualization Tools"

yum install boost-filesystem PyYAML boost-iostreams boost-chrono python-mako python-netaddr python-

six gperftools-libs libunwind yum-utils wget net-tools redhat-lsb-core tcpdump wget

Agregar un host de hipervisor al tejido de NSX-TUn nodo de tejido es un nodo que se registró con el plano de administración de NSX-T y que tienemódulos de NSX-T instalados. Para que un host de hipervisor forme parte de la superposición de NSX-T,debe agregarse primero al tejido de NSX-T.

Nota Puede omitir este procedimiento si instaló manualmente los módulos en los hosts y unió los hostsal plano de administración mediante la CLI.

Requisitos previos

n Por cada host que planee agregar al tejido de NSX-T, recopile primero la siguiente información delhost:

n Nombre de host

n Dirección IP de administración

n Nombre de usuario

n Contraseña

n (KVM) Huella digital SHA-256 SSL

n (ESXi) Huella digital SHA-256 SSL

n De forma opcional, recupere la huella digital del hipervisor para que pueda proporcionarlo al agregarel host al tejido.

n Un método para recopilar la información por sí mismo consiste en ejecutar el siguiente comandoen un shell de Linux:

# echo -n | openssl s_client -connect <esxi-ip-address>:443 2>/dev/null | openssl x509 -noout -

fingerprint -sha256

n Otro método utiliza la CLI de ESXi:

[root@host:~] openssl x509 -in /etc/vmware/ssl/rui.crt -fingerprint -sha256 -noout


VMware, Inc. 91

n Para recuperar la huella digital SHA-256 de un hipervisor KVM, ejecute los siguientes comandos:

# ssh-keyscan -t rsa hostname > hostname.pub

# awk '{print $3}' hostname.pub | base64 -d | sha256sum -b | sed 's/ .*$//' | xxd -r -p |

base64

where hostname is the hypervisor’s hostname or IP address.

n Para Ubuntu, compruebe que estén instalados los paquetes de terceros requeridos. Consulte Instalarpaquetes de terceros en un host de KVM.

Procedimiento

1 En la CLI de NSX Manager, compruebe que se esté ejecutando el servicio de instalación-actualización.

nsx-manager-1> get service install-upgrade

Service name: install-upgrade

Service state: running

Enabled: True

2 Desde un explorador, inicie sesión en un NSX Manager en https://<nsx-mgr>.

3 Seleccione Tejido (Fabric) > Nodos (Nodes) > Hosts (Hosts) y haga clic en Agregar (Add).


VMware, Inc. 92

4 Introduzca el nombre de host, la dirección IP, el nombre de usuario, la contraseña y la huella digitalopcional.

Por ejemplo:

Si no introduce la huella digital del host, la interfaz de usuario (IU) de NSX-T le pide que utilice lahuella digital predeterminada recuperada del host.


VMware, Inc. 93

Por ejemplo:

Cuando se agrega correctamente un host al tejido de NSX-T, la IU NSX Manager Tejido (Fabric) >Nodos (Nodes) > Hosts (Hosts) muestra Estado de implementación: Instalación correcta(Deployment Status: Installation Successful) y Conectividad de MPA: Activa (MPA Connectivity:Up). La Conectividad de LCP (LCP Connectivity) permanece no disponible hasta que el nodo de tejidose convierta en un nodo de transporte.

Como resultado de agregar un host al tejido de NSX-T, se instalan en el host una colección de módulosde NSX-T. En ESXi, los módulos se empaquetan como VIB. Para KVM en RHEL, se empaquetan comoRPM. Para KVM en Ubuntu, se empaquetan como DEB.

Para verificar en ESXi, puede ejecutar el comando esxcli software vib list | grep nsx, donde lafecha es el día que realizó la instalación.

Para realizar la verificación en RHEL, ejecute el comando yum list installed o rpm -qa.

Para realizar la verificación en Ubuntu, ejecute el comando dpkg --get-selections.

Puede ver los nodos del tejido mediante la llamada API GET https://<nsx-mgr>/api/v1/fabric/nodes/<node-id>:

{

"resource_type" : "HostNode",

"id" : "f36d5a79-233c-47c9-9c17-9adc9f8ec466",

"display_name" : "10.143.1.177",

"fqdn" : "w1-mvpcloud-177.eng.vmware.com",

"ip_addresses" : [ "10.143.1.177" ],

"external_id" : "f36d5a79-233c-47c9-9c17-9adc9f8ec466",

"discovered_ip_addresses" : [ "192.168.150.104", "10.143.1.177" ],

"os_type" : "ESXI",

"os_version" : "6.5.0",

"managed_by_server" : "",

"_create_time" : 1480369243245,

"_last_modified_user" : "admin",


VMware, Inc. 94

"_last_modified_time" : 1480369243245,

"_create_user" : "admin",

"_revision" : 0

}

Puede supervisar el estado en la API con la llamada API GET https://<nsx-mgr>/api/v1/fabric/nodes/<node-id>/status.

{

"lcp_connectivity_status" : "UP",

"mpa_connectivity_status" : "UP",

"last_sync_time" : 1480370899198,

"mpa_connectivity_status_details" : "Client is responding to heartbeats",

"lcp_connectivity_status_details" : [ {

"control_node_ip" : "10.143.1.47",

"status" : "UP"

} ],

"inventory_sync_paused" : false,

"last_heartbeat_timestamp" : 1480369333415,

"system_status" : {

"mem_used" : 2577732,

"system_time" : 1480370897000,

"file_systems" : [ {

"file_system" : "root",

"total" : 32768,

"used" : 5440,

"type" : "ramdisk",

"mount" : "/"

}, {

"file_system" : "etc",

"total" : 28672,

"used" : 264,

"type" : "ramdisk",

"mount" : "/etc"

}, {

"file_system" : "opt",

"total" : 32768,

"used" : 20,

"type" : "ramdisk",

"mount" : "/opt"

}, {

"file_system" : "var",

"total" : 49152,

"used" : 2812,

"type" : "ramdisk",

"mount" : "/var"

}, {

"file_system" : "tmp",

"total" : 262144,

"used" : 21728,

"type" : "ramdisk",

"mount" : "/tmp"

}, {

"file_system" : "iofilters",


VMware, Inc. 95

"total" : 32768,

"used" : 0,

"type" : "ramdisk",

"mount" : "/var/run/iofilters"

}, {

"file_system" : "hostdstats",

"total" : 116736,

"used" : 2024,

"type" : "ramdisk",

"mount" : "/var/lib/vmware/hostd/stats"

} ],

"load_average" : [ 0.03999999910593033, 0.03999999910593033, 0.05000000074505806 ],

"swap_total" : 0,

"mem_cache" : 0,

"cpu_cores" : 2,

"source" : "cached",

"mem_total" : 8386740,

"swap_used" : 0,

"uptime" : 3983605000

},

"software_version" : "1.1.0.0.0.4649755",

"host_node_deployment_status" : "INSTALL_SUCCESSFUL"

}

Pasos siguientes

Si tiene un gran número de hipervisores (por ejemplo, 500 o más), NSX Manager podría experimentarproblemas de rendimiento y uso elevado de CPU. Puede evitar el problema ejecutando el scriptaggsvc_change_intervals.py, que se encuentra en el almacén de archivos de NSX. (Puede utilizar elcomando copy file de la CLI de NSX o la API POST /api/v1/node/file-store/<file-name>?action=copy_to_remote_file para copiar el script en un host). Este script cambia los intervalos desondeo de determinados procesos. Ejecute el script de la siguiente manera:

python aggsvc_change_intervals.py -m '<NSX Manager IP address>' -u 'admin' -p '<password>' -i 900

Para restablecer los valores predeterminados de los intervalos de sondeo:

python aggsvc_change_intervals.py -m '<NSX Manager IP address>' -u 'admin' -p '<password>' -r

Cree una zona de transporte. Consulte Acerca de las zonas de transporte.

Instalación manual de módulos kernel NSX-TComo alternativa al uso de la IU Tejido (Fabric) > Nodos (Nodes) > Hosts (Hosts) > Agregar (Add) deNSX-T o la API POST /api/v1/fabric/nodes, puede instalar manualmente módulos kernel de NSX-Tdesde la línea de comandos del hipervisor.


VMware, Inc. 96

Instalar manualmente módulos kernel de NSX-T en hipervisores deESXiPara preparar hosts para que participen en NSX-T, debe instalar módulos kernel de NSX-T en hosts deESXi. Esto le permite crear el tejido del plano de administración y del panel de control de NSX-T. Losmódulos de kernel de NSX-T empaquetados en archivos VIB se ejecutan dentro del kernel del hipervisory ofrecen servicios, como enrutamiento distribuido, firewall distribuido y capacidades de puente.

Puede descargar los VIB de NSX-T manualmente y hacer que formen parte de la imagen del host. Tengaen cuenta que las rutas de descarga pueden variar en cada versión de NSX-T. Compruebe siempre lapágina de descargas de NSX-T para obtener los VIB apropiados.

Procedimiento

1 Inicie sesión en el host como raíz o usuario con privilegios administrativos.

2 Desplácese hasta el directorio /tmp.

[root@host:~]: cd /tmp

3 Descargue y copie el archivo nsx-lcp en el directorio /tmp.

4 Ejecute el comando de instalación.

[root@host:/tmp]: esxcli software vib install -d /tmp/nsx-lcp-<release>.zip

Installation Result

Message: Operation finished successfully.

Reboot Required: false

VIBs Installed: VMware_bootbank_nsx-aggservice_<release>, VMware_bootbank_nsx-da_<release>,

VMware_bootbank_nsx-esx-datapath_<release>, VMware_bootbank_nsx-exporter_<release>,

VMware_bootbank_nsx-host_<release>, VMware_bootbank_nsx-lldp_<release>, VMware_bootbank_nsx-

mpa_<release>, VMware_bootbank_nsx-netcpa_<release>, VMware_bootbank_nsx-python-

protobuf_<release>, VMware_bootbank_nsx-sfhc_<release>, VMware_bootbank_nsxa_<release>,

VMware_bootbank_nsxcli_<release>

VIBs Removed:

VIBs Skipped:

Dependiendo de lo que ya esté instalado en el host, podrían instalarse, eliminarse u omitirsedeterminados VIB. No es necesario reiniciar el equipo salvo que la salida de comandos diga RebootRequired: true.

Como resultado de agregar un host ESXi al tejido de NSX-T, se instalan en el host los siguientes VIB.

n nsx-aggservice: proporciona bibliotecas en el lado de host para el servicio de agregación de NSX-T.El servicio de agregación de NSX-T se ejecuta en los nodos del plano de administración y captura elestado de los componentes de NSX-T.

n nsx-da: recopila datos del agente de detección (DA) sobre la versión del SO del hipervisor, lasmáquinas virtuales y las interfaces de red. Proporciona los datos al plano de administración, que seutilizarán en las herramientas de solución de problemas.


VMware, Inc. 97

n nsx-esx-datapath: proporciona la funcionalidad de procesamiento de paquetes del plano de datos deNSX-T.

n nsx-exporter: proporciona agentes de host que comunican el estado en tiempo de ejecución alservicio de agregación que se ejecuta en el plano de administración.

n nsx-host: proporciona metadatos para el paquete de VIB que está instalado en el host.

n nsx-lldp: proporciona soporte para el protocolo de detección de nivel de vínculo (LLDP), que es unprotocolo de nivel de vínculo utilizado por dispositivos de red para anunciar su identidad,capacidades y vecinos en una red LAN.

n nsx-mpa: proporciona comunicación entre NSX Manager y los hosts de hipervisor.

n nsx-netcpa: proporciona comunicación entre el plano de control central y los hipervisores. Recibe elestado de red lógica del plano de control central y programa este estado en el plano de datos.

n nsx-python-protobuf: proporciona enlaces de Python para búferes de protocolo.

n nsx-sfhc: componente de host de tejido de servicios (SFHC). Proporciona un agente de host paraadministrar el ciclo de vida del hipervisor como un host de tejido en el inventario del plano deadministración. Esto proporciona un canal para operaciones como las de actualización ydesinstalación de NSX-T y la de supervisión de módulos de NSX-T en hipervisores.

n nsxa: realiza configuraciones de nivel de host, como configuración de vínculos superiores y creaciónde conmutador de host.

n nsxcli: proporciona la CLI de NSX-T en hosts del hipervisor.

n nsx-support-bundle-client: ofrece la capacidad de recolectar agrupaciones de soporte.

Para verificarlo, puede ejecutar el comando esxcli software vib list | grep nsx o esxcli software viblist | grep <yyyy-mm-dd> en el host ESXi, donde la fecha es el día que realizó la instalación.

Pasos siguientes

Agregue el host al plano de administración de NSX-T. Consulte Unir los hosts del hipervisor al plano deadministración.

Instalar manualmente módulos kernel de NSX-T en hipervisores deKVM en UbuntuPara preparar hosts para que participen en NSX-T, debe instalar módulos kernel de NSX-T en hosts deKVM en Ubuntu. Esto le permite crear el tejido del plano de administración y del panel de control deNSX-T. Los módulos de kernel de NSX-T empaquetados en archivos DEB se ejecutan dentro del kerneldel hipervisor y ofrecen servicios, como enrutamiento distribuido, firewall distribuido y capacidades depuente.

Puede descargar los DEB de NSX-T manualmente y hacer que formen parte de la imagen del host.Tenga en cuenta que las rutas de descarga pueden variar en cada versión de NSX-T. Compruebesiempre la página de descargas de NSX-T para obtener los DEB apropiados.


VMware, Inc. 98

Requisitos previos

n Compruebe que estén instalados los paquetes de terceros requeridos. Consulte Instalar paquetes deterceros en un host de KVM.

Procedimiento

1 Inicie sesión en el host como usuario con privilegios de administrador.

2 (opcional) Desplácese hasta el directorio /tmp.

cd /tmp


4 Descomprima el paquete.

tar -xvf nsx-lcp-<release>-ubuntu-trusty_amd64.tar.gz

5 Desplácese hasta el directorio del paquete.

cd nsx-lcp-trusty_amd64/

6 Instale los paquetes.

sudo dpkg -i *.deb

Para realizar la comprobación, puede ejecutar el comando dpkg –l | grep nsx.

user@host:~$ dpkg -l | grep nsx

ii nsx-agent <release> amd64 NSX Agent

ii nsx-aggservice <release> all NSX Aggregation Service Lib

ii nsx-cli <release> all NSX CLI

ii nsx-da <release> amd64 NSX Inventory Discovery Agent

ii nsx-host <release> all NSX host meta package

ii nsx-host-node-status-reporter <release> amd64 NSX Host Status Reporter for

Aggregation Service

ii nsx-lldp <release> amd64 NSX LLDP Daemon

ii nsx-logical-exporter <release> amd64 NSX Logical Exporter

ii nsx-mpa <release> amd64 NSX Management Plane Agent Core

ii nsx-netcpa <release> amd64 NSX Netcpa

ii nsx-sfhc <release> amd64 NSX Service Fabric Host Component

ii nsx-transport-node-status-reporter <release> amd64 NSX Transport Node Status Reporter

ii nsxa <release> amd64 NSX L2 Agent

Lo más probable es que los errores se deban a la existencia de dependencias incompletas. El comandoapt-get install -f intentará resolver las dependencias y volver a ejecutar la instalación de NSX-T.


VMware, Inc. 99

Pasos siguientes


Instalar manualmente módulos kernel de NSX-T en hipervisores deKVM en RHELPara preparar hosts para que participen en NSX-T, debe instalar módulos kernel de NSX-T en hosts deKVM en RHEL. Esto le permite crear el tejido del plano de administración y del panel de control deNSX-T. Los módulos de kernel de NSX-T empaquetados en archivos RPM se ejecutan dentro del kerneldel hipervisor y ofrecen servicios, como enrutamiento distribuido, firewall distribuido y capacidades depuente.

Puede descargar los RPM de NSX-T manualmente y hacer que formen parte de la imagen del host.Tenga en cuenta que las rutas de descarga pueden variar en cada versión de NSX-T. Compruebesiempre la página de descargas de NSX-T para obtener los RPM apropiados.

Requisitos previos

n Capacidad para acceder al repositorio de RHEL.

Procedimiento

1 Inicie sesión en el host como administrador.


3 Descomprima el paquete.

tar -xvf nsx-lcp-<release>-rhel71_x86_64.tar.gz

4 Desplácese hasta el directorio del paquete.

cd nsx-lcp-rhel71_x86_64/

5 Instale los paquetes.

sudo yum install *.rpm

Al ejecutar el comando de instalación yum, se resuelven todas las dependencias de NSX-T,suponiendo que la máquina RHEL pueda acceder al repositorio de RHEL.

6 Vuelva a cargar el módulo kernel de OVS.

/etc/init.d/openvswitch force-reload-kmod


VMware, Inc. 100

Para realizar la comprobación, puede ejecutar el comando rpm -qa | grep nsx.

user@host:~$ rpm -qa | grep nsx

nsxa-<release>.el7.x86_64.rpm

nsx-agent-<release>.el7.x86_64.rpm

nsx-aggservice-<release>.el7.x86_64.rpm

nsx-cli-<release>.x86_64.rpm

nsx-da-<release>.el7.x86_64.rpm

nsx-host-<release>.x86_64.rpm

nsx-host_node_status_reporter-<release>.el7.x86_64.rpm

nsx-lldp-<release>.el7.x86_64.rpm

nsx-logical_exporter-<release>.el7.x86_64.rpm

nsx-mpa-<release>.el7.x86_64.rpm

nsx-netcpa-<release>.el7.x86_64.rpm

nsx-sfhc-<release>.el7.x86_64.rpm

nsx-transport_node_status-<release>.el7.x86_64.rpm

Pasos siguientes


Unir los hosts del hipervisor al plano de administraciónUnir los hosts del hipervisor al plano de administración garantiza que NSX Manager y los hosts sepueden comunicar entre sí.

Requisitos previos

Se debe haber completado la instalación de los módulos de NSX-T.

Procedimiento

1 Abra una sesión SSH en el dispositivo de NSX Manager.

2 Abra una sesión SSH para el host del hipervisor.

3 En el dispositivo NSX Manager, ejecute el comando get certificate api thumbprint.

La salida de comandos es una cadena de números única para este NSX Manager.

Por ejemplo:

NSX-Manager1> get certificate api thumbprint

...


VMware, Inc. 101

4 En el host del hipervisor, ejecute el comando /opt/vmware/nsx-cli/bin/scripts/nsxcli para acceder ala CLI de NSX-T.

Nota Para KVM, ejecute el comando como superusuario (sudo).

[user@host:~] nsxcli

host>

El aviso cambia.

5 En el host del hipervisor, ejecute el comando join management-plane.


n Nombre de host o dirección IP de NSX Manager con un número de puerto opcional

n Nombre de usuario de NSX Manager

n Huella digital del certificado de NSX Manager

n Contraseña de NSX Manager

host> join management-plane NSX-Manager1 username admin thumbprint <NSX-Manager1's-thumbprint>

Password for API user: <NSX-Manager1's-password>

Node successfully joined

Compruebe el resultado ejecutando el comando get managers en sus hosts.

host> get managers

- 192.168.110.47 Connected

En la IU de NSX Manager en Tejido (Fabric) > Nodo (Node) > Hosts (Hosts) , compruebe que estéconfigurada como Activa (Up) la conectividad de MPA del host.

Puede ver el estado del host del tejido con la llamada API GET https://<nsx-mgr>/api/v1/fabric/nodes/<id_nodo_tejido>/state:

{

"details": [],

"state": "success"

}

El plano de administración envía los certificados de host al plano de control y el plano de administracióninserta la información del plano de control en los hosts.

Debería ver las direcciones de NSX Controller en /etc/vmware/nsx/controller-info.xml en cadahost ESXi.

[root@host:~] cat /etc/vmware/nsx/controller-info.xml

<?xml version="1.0" encoding="utf-8"?>

<config>

<connectionList>


VMware, Inc. 102

<connection id="0">

<server>10.143.1.47</server>

<port>1234</port>

<sslEnabled>true</sslEnabled>

<pemKey>-----BEGIN CERTIFICATE-----...-----END CERTIFICATE-----</pemKey>

</connection>

<connection id="1">


<port>1234</port>



</connection>

<connection id="2">


<port>1234</port>



</connection>

</connectionList>

</config>

La conexión del host con NSX-T se inicia y se queda en estado "CIERRE_ESPERA" (CLOSE_WAIT)hasta que el host sea ascendido a nodo de transporte. Puede verlo con el comando esxcli network ipconnection list | grep 1234.

# esxcli network ip connection list | grep 1234

tcp 0 0 192.168.210.53:45823 192.168.110.34:1234 CIERRE_ESPERA (CLOSE_WAIT)

37256 newreno netcpa

Para KVM, el comando es netstat -anp --tcp | grep 1234.

user@host:~$ netstat -anp --tcp | grep 1234

tcp 0 0 192.168.210.54:57794 192.168.110.34:1234 CIERRE_ESPERA (CLOSE_WAIT) -

Pasos siguientes

Cree una zona de transporte. Consulte Acerca de las zonas de transporte.


VMware, Inc. 103

Zonas de transporte y nodos detransporte 8Las zonas de transporte y los nodos de transporte son conceptos importantes en NSX-T.


n Acerca de las zonas de transporte

n Crear un grupo de direcciones IP para direcciones IP de endpoints de túneles

n Crear un perfil de vínculo superior

n Crear zonas de transporte

n Crear un nodo de transporte de host

n Crear un nodo de transporte de NSX Edge

n Crear un clúster de NSX Edge

Acerca de las zonas de transporteUna zona de transporte es un contenedor que define el alcance potencial de los nodos de transporte. Losnodos de transporte son hosts del hipervisor y varios NSX Edge que participarán en una superposiciónde NSX-T. Para un host de hipervisor, esto significa que aloja máquinas virtuales (VM) que secomunicarán a través de conmutadores lógicos de NSX-T. Para los NSX Edge, esto significa que tendrávínculos superiores e inferiores de enrutador lógico.

Si hay dos nodos de transporte en una misma zona de transporte, las VM alojadas en dichos nodos detransporte podrán "ver" y, por tanto, conectarse a conmutadores lógicos de NSX-T que también seencuentren en esa zona de transporte. Esta conexión permite a las VM comunicarse entre sí, siempreque tengan disponibilidad de Capa 2/Capa 3. Si las VM están conectadas a conmutadores que estén endistintas zonas de transporte, las VM no se pueden comunicar entre sí. Las zonas de transporte noreemplazan los requisitos de disponibilidad de Capa 2/Capa 3, pero aplican un límite de disponibilidad.Dicho de otro modo, pertenecer a la misma zona de transporte es un requisito previo para poderestablecer la conexión. Si se cumple dicho requisito previo, la disponibilidad es posible, pero noautomática. Para que la disponibilidad sea real, las redes de Capa 2 y (para distintas subredes) Capa 3deben estar operativas.

Los nodos de transporte pueden ser hosts del hipervisor o servidores NSX Edge. Los servidoresNSX Edge pueden pertenecer a varias zonas de transporte. Los hosts del hipervisor (y conmutadoreslógicos de NSX-T) pueden pertenecer a una sola zona de transporte.

VMware, Inc. 104

Suponga que un único nodo de transporte contiene tanto VM normales como VM de alta seguridad. En eldiseño de su red, las VM normales deberían ser capaces de conectarse entre sí, pero no deberían sercapaces de conectarse a las VM de alta seguridad. Para lograr este objetivo, puede colocar las VMseguras en hosts que pertenezcan a una zona de transporte denominada secure-tz. Las VM normalesestarían de este modo en otra zona de transporte denominada general-tz. Las VM normales se conectana un conmutador lógico de NSX-T que también está en general-tz. Las VM de alta seguridad se conectana un conmutador lógico de NSX-T que está en secure-tz. Las VM que se encuentran en otras zonas detransporte no se pueden comunicar entre sí aunque estén en la misma subred. La conexión de VM aconmutador lógico es lo que controla en última instancia la disponibilidad de las VM. Por tanto, dado quedos conmutadores lógicos se encuentran en diferentes zonas de transporte, "web VM"y "secure VM" nose pueden comunicar entre sí.

Un nodo de transporte de NSX Edge puede pertenecer a varias zonas de transporte: a una zona detransporte superpuesta y a varias zonas de transporte de VLAN. Las zonas de transporte de VLAN sonpara los vínculos superiores de VLAN al mundo exterior.

Por ejemplo, en la siguiente figura se muestra un NSX Edge que pertenece a tres zonas de transporte:dos zonas de transporte de VLAN y una zona de transporte superpuesta 2. La zona de transportesuperpuesta 1 contiene un host, un conmutador lógico de NSX-T y una VM segura. Dado que NSX Edgeno pertenece a la zona de transporte 1, la VM segura no tiene acceso a o desde la arquitectura física.Por el contrario, la Web VM de la zona de transporte superpuesta 2 se puede comunicar con laarquitectura física porque NSX Edge pertenece a la zona de transporte superpuesta 2.


VMware, Inc. 105

Figura 8‑1. Zonas de transporte de NSX-T

VM VM

conmutadorlógico 1

VM segura

Máquina virtualweb

nivel 0

Arquitecturafísica

zona detransportede VLAN

nivel 1

conmutador lógico 2

NSX Edge

Host

zona de transporte

superpuesta 1

zona de transporte

superpuesta 2

zona detransportede VLAN

Arquitecturafísica

Host

Crear un grupo de direcciones IP para direcciones IP deendpoints de túnelesPuede utilizar un grupo de direcciones IP para los endpoints de túneles. Los endpoints de túneles son lasdirecciones IP de origen y destino que se utilizan en el encabezado IP externo para identificar de formaúnica a los hosts del hipervisor que originan y finalizan la encapsulación de tramas de NSX-T. Para lasdirecciones IP de endpoints de túneles, puede utilizar DHCP o grupos de direcciones IP configuradasmanualmente.

Si está utilizando tanto hosts de ESXi como hosts de KVM, una opción de diseño sería utilizar dossubredes diferentes para el grupo de direcciones IP de extremos de túneles de ESXI (sub_a) y el grupode direcciones IP de extremos de túneles de KVM (sub_b). En este caso, en los hosts de KVM se debeagregar una ruta estática a sub_a con una puerta de enlace predeterminada dedicada.


VMware, Inc. 106

Este es un ejemplo de la tabla de enrutamiento resultante en un host de Ubuntu donde sub_a =192.168.140.0 y sub_b = 192.168.150.0. (La subred de administración, por ejemplo, podría ser192.168.130.0).

Tabla de enrutamiento de direcciones IP de kernel:

Destination Gateway Genmask Iface

0.0.0.0 192.168.130.1 0.0.0.0 eth0

192.168.122.0 0.0.0.0 255.255.255.0 virbr0

192.168.130.0 0.0.0.0 255.255.255.0 eth0

192.168.140.0 192.168.150.1 255.255.255.0 nsx-vtep0.0

192.168.150.0 0.0.0.0 255.255.255.0 nsx-vtep0.0

La ruta se puede agregar al menos de dos formas diferentes.

route add -net 192.168.140.0 netmask 255.255.255.0 gw 192.168.150.1 dev nsx-vtep0.0

En /etc/network/interfaces, antes de "up ifconfig nsx-vtep0.0 up" agregue esta ruta estática:

post-up route add -net 192.168.140.0 netmask 255.255.255.0 gw 192.168.150.1

Procedimiento


2 Seleccione Inventario (Inventory) > Grupos de direcciones IP (IP Pools) y haga clic en Agregar(Add).

3 Escriba el nombre del grupo de direcciones IP, una descripción opcional y la configuración de red.

La configuración de red incluye:

n Rango de direcciones IP

n Puerta de enlace

n Dirección de red en notación CIDR

n (opcional) Lista separada por comas de servidores DNS


VMware, Inc. 107

n (opcional) Sufijo DNS

Por ejemplo:

Puede ver los grupos de direcciones IP con la llamada API GET https://<nsx-mgr>/api/v1/pools/ip-pools:

{

"cursor": "0036e2d8c2e8-f6d7-498e-821b-b7e44d2650a9ip-pool-1",

"sort_by": "displayName",

"sort_ascending": true,

"result_count": 1,

"results": [

{

"id": "e2d8c2e8-f6d7-498e-821b-b7e44d2650a9",

"display_name": "comp-tep",

"resource_type": "IpPool",

"subnets": [

{

"dns_nameservers": [

"192.168.110.10"

],

"allocation_ranges": [

{

"start": "192.168.250.100",

"end": "192.168.250.200"

}

],

"gateway_ip": "192.168.250.1",

"cidr": "192.168.250.0/24",

"dns_suffix": "corp.local"


VMware, Inc. 108

}

],

"_last_modified_user": "admin",

"_last_modified_time": 1443649891178,

"_create_time": 1443649891178,

"_system_owned": false,

"_create_user": "admin",

"_revision": 0

}

]

}

Pasos siguientes

Cree un perfil de vínculo superior. Consulte Crear un perfil de vínculo superior.

Crear un perfil de vínculo superiorUn perfil de vínculo superior es un perfil de conmutador de host, lo que significa que define las directivaspara los vínculos que van de los hosts del hipervisor a los conmutadores lógicos de NSX-T o desde losnodos de NSX Edge a los conmutadores para la parte superior del bastidor.

La configuración definida por los perfiles de vínculo superior podrían incluir políticas de formación deequipos, vínculos activos/en espera, el ID de la red VLAN de transporte y la configuración de MTU.

Los perfiles de vínculo superior le permiten configurar de manera coherente capacidades idénticas paraadaptadores de red en varios hosts o nodos. Los perfiles de vínculo superior son contenedores para laspropiedades o capacidades que quiera que tengan sus adaptadores de red. En lugar de configurarpropiedades o capacidades individuales para cada adaptador de red, puede especificar las capacidadesen perfiles de vínculo superior, que después puede aplicar al crear nodos de transporte de NSX-T.

Si el NSX Edge está instalado en un equipo sin sistema operativo, puede utilizar el perfil de vínculosuperior predeterminado. El perfil de vínculo superior predeterminado requiere un vínculo superior activoy un vínculo en espera pasivo. Los vínculos superiores en espera no son compatibles con NSX Edgebasados en VM/dispositivo. Cuando instala NSX Edge como un dispositivo virtual, debe crear un perfil devínculo superior personalizado en lugar de utilizar el predeterminado. Por cada perfil de vínculo superiorcreado en un NSX Edge basado en VM, el perfil debe especificar solo un vínculo superior activo y ningúnvínculo superior en espera.

Nota Dicho eso, las VM de NSX Edge permiten varios vínculos superiores si crea un conmutador dehost aparte para cada vínculo superior, utilizando una red VLAN distinta para cada uno de ellos. Elobjetivo es permitir un nodo único de NSX Edge que se conecte a varios conmutadores TOR.

Requisitos previos

Asegúrese de que comprende cómo funcionan las redes de NSX Edge. Consulte Configuración de redde NSX Edge.

Cada vínculo superior debe corresponderse a un vínculo físico activo y disponible de su host dehipervisor o del nodo de NSX Edge.


VMware, Inc. 109

Por ejemplo, suponga que su host de hipervisor tiene dos vínculos físicos activos: vmnic0 y vmnic1.Suponga que vmnic0 se está utilizando actualmente para redes de almacenamiento y administración,mientras que vmnic1 no se está utilizando actualmente. Esto significaría que vmnic1 se puede utilizarcomo vínculo superior de NSX-T, pero vmnic0 no. Para formar equipos de vínculos, debe tener dosvínculos físicos disponibles que no se estén utilizando, como vmnic1 y vmnic2.

Para un NSX Edge, el endpoint del túnel y los vínculos superiores de VLAN pueden utilizar el mismovínculo físico. De modo que, por ejemplo, vmnic0/eth0/em0 podría utilizarse para su red deadministración y vmnic1/eth1/em1 podría utilizarse para sus vínculos fp-ethX.

Procedimiento


2 Seleccione Tejido (Fabric) > Perfiles (Profiles) > Perfiles de vínculo superior (Uplink Profiles) yhaga clic en Agregar (Add).

3 Introduzca la siguiente información:

n Nombre (Name) de perfil de vínculo superior.

n (Opcional) Descripción (Description).

n Política de formación de equipos (Teaming policy): orden de conmutación por error u origen deequilibrio de carga (el valor predeterminado es orden de conmutación por error).

n Orden de conmutación por error (Failover order): en la lista de adaptadores activos, utilicesiempre el vínculo superior de orden más alto que cumple los criterios de detección deconmutación por error. No se realiza ningún equilibrio de carga mediante esta opción.

n Origen de equilibrio de carga (Load balance source): seleccione un vínculo superiorbasándose en un hash de la dirección MAC Ethernet de origen.

n (Opcional) Grupos de adición de vínculos (LAGs) que usan el Protocolo de control de adición devínculos (LACP) para la red de transporte.

n Lista separada por comas de nombres de vínculos superiores activos.

n (Opcional) Lista separada por comas de nombres de vínculos en espera.

Los nombres de vínculo superior activos y en espera que cree aquí pueden ser cualquier textoque represente vínculos físicos. Más adelante, cuando usted crea nodos de transporte, se hacereferencia a estos nombres de vínculos superiores. LA IU/API del nodo de transporte le permiteespecificar qué vínculo físico se corresponde a cada vínculo superior con nombre.

n (Opcional) VLAN de transporte (Transport VLAN)


VMware, Inc. 110

n MTU (MTU) (el valor predeterminado es 1600)

Por ejemplo:

Puede ver los perfiles de vínculo superior con la llamada API GET /api/v1/host-switch-profiles:

{

"result_count": 2,

"results": [

{

"resource_type": "UplinkHostSwitchProfile",

"id": "16146a24-122b-4274-b5dd-98b635e4d52d",

"display_name": "comp-uplink",

"transport_vlan": 250,

"teaming": {

"active_list": [

{

"uplink_type": "PNIC",

"uplink_name": "uplink-1"

}

],

"standby_list": [],

"policy": "FAILOVER_ORDER"

},

"mtu": 1600,


"_create_time": 1457984399526,




VMware, Inc. 111


"_revision": 0

},

{

"resource_type": "UplinkHostSwitchProfile",

"id": "c9e35cec-e9d9-4c51-b52e-17a5c1bd9a38",

"display_name": "vlan-uplink",

"transport_vlan": 100,

"teaming": {

"active_list": [

{

"uplink_type": "PNIC",


}

],

"standby_list": [],

"policy": "FAILOVER_ORDER"

},

"mtu": 1600,


"_create_time": 1457984399574,




"_revision": 0

}

]

}

Pasos siguientes

Cree una zona de transporte. Consulte Crear zonas de transporte.

Crear zonas de transporteLas zonas de transporte establecen qué hosts y, por lo tanto, qué máquinas virtuales pueden participaren el uso de una red determinada. Una zona de transporte hace esto limitando los hosts que pueden"ver" un conmutador lógico y, por tanto, qué VM pueden conectarse al conmutador lógico. Una zona detransporte puede abarcar a uno o varios clústeres de host.

Un entorno de NSX-T puede contener una o más zonas de transporte según los requisitos del usuario.Un host puede corresponder a varias zonas de transporte. Un conmutador lógico puede corresponder auna sola zona de transporte.

NSX-T no permite conectar máquinas virtuales que se encuentran en diferentes zonas de transporte. Laexpansión de un conmutador lógico se limita a una zona de transporte, de modo que las máquinasvirtuales de diferentes zonas de transporte no pueden estar en la misma red de Capa 2.

La zona de transporte superpuesta es utilizada por ambos nodos de transporte de host y NSX Edge.Cuando un host o nodo de transporte de NSX Edge se agrega a una zona de transporte superpuesta, seinstala un conmutador de host de NSX-T en el host o NSX Edge.


VMware, Inc. 112

La zona de transporte de VLAN es utilizada por el NSX Edge para sus vínculos superiores de VLAN.Cuando se agrega un NSX Edge a una zona de transporte de VLAN, se instala un conmutador de hostde VLAN en el NSX Edge.

Los conmutadores de host permiten el flujo de paquetes virtuales a físicos asociando vínculos superioresde enrutador lógico a vínculos inferiores a las NIC físicas.

Cuando crea una zona de transporte, debe proporcionar un nombre para el conmutador de host que seinstalará en los nodos de transporte cuando se agreguen más adelante a esta zona de transporte. Puedeasignar al conmutador de host el nombre que desee.

Procedimiento


2 Seleccione Tejido (Fabric) > Zonas de transporte (Transport Zones) y haga clic en Agregar(Add).

3 Introduzca un nombre para la zona de transporte, un nombre de conmutador de host y el tipo detráfico (superposición o VLAN).

Por ejemplo:

Puede ver la nueva zona de transporte con la llamada API GET https://<nsx-mgr>/api/v1/transport-zones:

{

"cursor": "00369b661aed-1eaa-4567-9408-ccbcfe50b416tz-vlan",

"result_count": 2,

"results": [

{

"resource_type": "TransportZone",

"description": "comp overlay transport zone",

"id": "efd7f38f-c5da-437d-af03-ac598f82a9ec",

"display_name": "tz-overlay",

"host_switch_name": "overlay-hostswitch",

"transport_type": "OVERLAY",

"transport_zone_profile_ids": [

{

"profile_id": "52035bb3-ab02-4a08-9884-18631312e50a",

"resource_type": "BfdHealthMonitoringProfile"


VMware, Inc. 113

}

],

"_create_time": 1459547126454,





"_revision": 0,

"_schema": "/v1/schema/TransportZone"

},

{

"resource_type": "TransportZone",

"description": "comp vlan transport zone",

"id": "9b661aed-1eaa-4567-9408-ccbcfe50b416",

"display_name": "tz-vlan",

"host_switch_name": "vlan-uplink-hostwitch",

"transport_type": "VLAN",


{



}

],

"_create_time": 1459547126505,





"_revision": 0,

"_schema": "/v1/schema/TransportZone"

}

]

}

Pasos siguientes

De forma opcional, cree un perfil de zona de transporte personalizado y asócielo a la zona de transporte.Puede crear perfiles personalizados de zona de transporte mediante la APIPOST /api/v1/transportzone-profiles. No existe flujo de trabajo de IU para crear un perfil de zonade transporte. Una vez que se creó el perfil de la zona de transporte, podrá encontrarlo en la zona detransporte mediante la API PUT /api/v1/transport-zones/<transport-zone-id>.

Crear un nodo de transporte. Consulte Crear un nodo de transporte de host.

Crear un nodo de transporte de hostUn nodo de transporte es un nodo que es capaz de participar en una superposición de NSX-T o redesVLAN de NSX-T.


VMware, Inc. 114

Para un host de KVM, puede preconfigurar el conmutador de host o puede hacer que NSX Managerrealice la configuración. Para un host ESXi, NSX Manager siempre configura el conmutador de host.

Nota Si planea crear nodos de transporte desde una VM de plantilla, asegúrese de que no hayacertificados en el host en /etc/vmware/nsx/. El agente netcpa no crea un nuevo certificado si ya existeun certificado.

Requisitos previos

n El host debe unirse con el plano de administración y la conectividad MPA debe estar activa en lapágina Tejido (Fabric) > Hosts (Hosts).

n Debe haber una zona de transporte configurada.

n Un perfil de vínculo superior (denominado también perfil de conmutador de host) debe configurarse opuede utilizar el perfil de vínculo superior predeterminado.

n Se debe configurar un grupo de direcciones IP o debe estar disponible el protocolo DHCP en laimplementación de la red.

n Debe haber disponible al menos una tarjeta NIC física no utilizada en el nodo host.

Procedimiento


2 Seleccione Tejido (Fabric) > Nodos (Nodes) > Nodos de transporte (Transport Nodes) y hagaclic en Agregar (Add).

3 Introduzca un nombre para el nodo de transporte.

4 Seleccione un nodo del menú desplegable.

5 (opcional) Seleccione una zona de transporte de la lista desplegable.

6 (opcional) Desde un nodo KVM, seleccione un tipo de conmutador de host.

Opción Descripción

Estándar NSX Manager crea el conmutador host. Esta opción está seleccionada demanera predeterminada.

Preconfigurado El conmutador de host ya está configurado. Para un nodo que no sea KVM, el tipo de conmutador de host siempre es Estándar (Standard).

7 Para un conmutador de host estándar, introduzca o seleccione la siguiente información delconmutador de host:

n El nombre del conmutador de host. Este nombre debe ser igual al nombre del conmutador dehost de la zona de transporte a la que pertenece el nodo.

n El perfil de vínculo superior.


VMware, Inc. 115

n La asignación de dirección IP. Puede seleccionar Usar DHCP (Use DHCP), Usar grupo dedirecciones IP (Use IP Pool) o Usar lista de direcciones IP estáticas (Use Static IP List). Siselecciona Usar lista de direcciones IP estáticas (Use Static IP List), debe especificar una listade direcciones IP separadas por comas, una puerta de enlace y una máscara de subred.

n Información de NIC física

Importante Asegúrese de que la NIC física no se esté utilizando ya (por ejemplo, mediante unvSwitch estándar o un conmutador distribuido vSphere). De lo contrario, el estado del nodo detransporte será parcialmente correcto (partial success) y no se podrá establecer la conectividaddel LCP del nodo de tejido.

8 Para un conmutador de host preconfigurado, introduzca la siguiente información del conmutador dehost:

n El ID externo del conmutador de host. Este ID debe ser igual al nombre del conmutador de hostde la zona de transporte a la que pertenece este nodo.

n El nombre del endpoint de túnel virtual (VTEP).


VMware, Inc. 116

Tras agregar el host como un nodo de transporte, la conexión del host a NSX Controller cambia delestado "CIERRE_ESPERA" (CLOSE_WAIT) al estado "ESTABLECIDO" (ESTABLISHED). Puede veresto con el comando esxcli network ip connection list | grep 1234.

# esxcli network ip connection list | grep 1234

tcp 0 0 192.168.210.53:20514 192.168.110.34:1234 ESTABLECIDO (ESTABLISHED) 1000144459

newreno netcpa

Para KVM, el comando es netstat -anp --tcp | grep 1234.

user@host:~$ netstat -anp --tcp | grep 1234

tcp 0 0 192.168.210.54:57794 192.168.110.34:1234 ESTABLECIDO (ESTABLISHED) -

Puede ver el nodo de transporte con la llamada API GET https://<nsx-mgr>/api/v1/transport-nodes/<node-id>:

{

"resource_type": "TransportNode",

"description": "",

"id": "95c8ce77-f895-43de-adc4-03a3ae2565e2",

"display_name": "node-comp-01b",

"tags": [],

"transport_zone_endpoints": [

{

"transport_zone_id": "efd7f38f-c5da-437d-af03-ac598f82a9ec",


{



}

]

}

],

"host_switches": [

{

"host_switch_profile_ids": [

{

"value": "8abdb6c0-db83-4e69-8b99-6cd85bfcc61d",

"key": "UplinkHostSwitchProfile"

},

{

"value": "9e0b4d2d-d155-4b4b-8947-fbfe5b79f7cb",

"key": "LldpHostSwitchProfile"

}

],


"pnics": [

{

"device_name": "vmnic1",


}


VMware, Inc. 117

],

"static_ip_pool_id": "c78ac522-2a50-43fe-816a-c459a210127e"

}

],

"node_id": "c551290a-f682-11e5-ae84-9f8726e1de65",

"_create_time": 1460051753373,





"_revision": 0

}

Si el nodo de transporte se creó correctamente, Conectividad del LCP (LCP Connectivity) cambia aActivo (Up) en Tejido (Fabric) > Nodos (Nodes) > Hosts (Hosts). Para ver el cambio, actualice lapantalla del explorador.

Pasos siguientes

Cree un nodo de transporte de NSX Edge. Consulte Crear un nodo de transporte de NSX Edge.

Comprobar el estado de nodos de transporteAsegúrese de que el proceso de creación de nodos de transporte esté funcionando correctamente.

Tras crear un nodo de transporte de host, el conmutador de host NSX-T se instala en el host.

Procedimiento

1 Vea el conmutador de host de NSX-T en ESXi con el comando esxcli network ip interfacelist.

En ESXi , la salida de comandos debería incluir una interfaz vmk (como vmk10) con un nombre deVDS que coincida con el nombre que utilizó al configurar la zona de transporte y el nodo detransporte.

# esxcli network ip interface list

...

vmk10

Name: vmk10

MAC Address: 00:50:56:64:63:4c

Enabled: true

Portset: DvsPortset-1

Portgroup: N/A

Netstack Instance: vxlan

VDS Name: overlay-hostswitch

VDS UUID: 18 ae 54 04 2c 6f 46 21-b8 ae ef ff 01 0c aa c2

VDS Port: 10

VDS Connection: 10

Opaque Network ID: N/A

Opaque Network Type: N/A


VMware, Inc. 118

External ID: N/A

MTU: 1600

TSO MSS: 65535

Port ID: 67108895

...

Si está utilizando vSphere Client, puede ver el conmutador de host instalado en la IU seleccionandoConfiguración (Configuration) > Adaptadores de red (Network Adapters) del host.

El comando de KVM para comprobar la instalación del conmutador de host de NSX-T es ovs-vsctlshow. Tenga en cuenta que en KVM, el nombre del conmutador de host es nsx-switch.0. No coincidecon el nombre en la configuración del nodo de transporte. Esto es así por diseño.

# ovs-vsctl show

...

Bridge "nsx-switch.0"

Port "nsx-uplink.0"

Interface "em2"

Port "nsx-vtep0.0"

tag: 0

Interface "nsx-vtep0.0"

type: internal

Port "nsx-switch.0"

Interface "nsx-switch.0"

type: internal

ovs_version: "2.4.1.3340774"

2 Compruebe la dirección del endpoint del túnel asignado del nodo de transporte.

La interfaz vmk10 recibe una dirección IP desde DHCP o el grupo de direcciones IP de NSX-T, talcomo se muestra aquí:

# esxcli network ip interface ipv4 get

Name IPv4 Address IPv4 Netmask IPv4 Broadcast Address Type DHCP DNS

----- -------------- ------------- --------------- ------------ --------

vmk0 192.168.210.53 255.255.255.0 192.168.210.255 STATIC false

vmk1 10.20.20.53 255.255.255.0 10.20.20.255 STATIC false

vmk10 192.168.250.3 255.255.255.0 192.168.250.255 STATIC false


VMware, Inc. 119

En KVM, puede verificar la asignación de direcciones IP y el endpoint de túnel mediante el comandoifconfig.

# ifconfig

...

nsx-vtep0.0 Link encap:Ethernet HWaddr ba:30:ae:aa:26:53

inet addr:192.168.250.4 Bcast:192.168.250.255 Mask:255.255.255.0

...

3 Compruebe la API para obtener la información sobre el estado.

Utilice la llamada API GET https://<nsx-mgr>/api/v1/transport-nodes/<transport-node-id>/state. Por ejemplo:

{

"state": "success",

"host_switch_states": [

{

"endpoints": [

{

"default_gateway": "192.168.250.1",

"device_name": "vmk10",

"ip": "192.168.250.104",

"subnet_mask": "255.255.255.0",

"label": 69633

}

],

"transport_zone_ids": [

"efd7f38f-c5da-437d-af03-ac598f82a9ec"

],


"host_switch_id": "18 ae 54 04 2c 6f 46 21-b8 ae ef ff 01 0c aa c2"

}

],

"transport_node_id": "2d030569-5769-4a13-8918-0c309c63fdb9"

}

Crear un nodo de transporte de NSX EdgeUn nodo de transporte es un nodo que es capaz de participar en una superposición de NSX-T o redesVLAN de NSX-T. Cualquier nodo puede servir como nodo de transporte si contiene un conmutador dehost. Este tipo de nodos incluye pero no está limitado a NSX Edge. Este procedimiento demuestra cómoagregar un NSX Edge como nodo de transporte.


VMware, Inc. 120

Un NSX Edge puede pertenecer a una zona de transporte superpuesta y a múltiples zonas de transportede VLAN. Si una VM requiere acceso al mundo exterior, el NSX Edge debe pertenecer a la misma zonade transporte a la que pertenece el conmutador lógico de la VM. Por lo general, el NSX Edge perteneceal menos a una zona de transporte de VLAN para proporcionar el acceso al vínculo superior.

Nota Si planea crear nodos de transporte desde una VM de plantilla, asegúrese de que no hayacertificados en el host en /etc/vmware/nsx/. El agente netcpa no crea un nuevo certificado si ya existeun certificado.

Requisitos previos

n El NSX Edge debe unirse al plano de administración y la conectividad MPA debe estar configuradacomo Activa (Up) en la página Tejido (Fabric) > Servidores perimetrales (Edges). Consulte UnirNSX Edge al plano de administración.

n Se deben configurar las zonas de transporte.

n Se debe configurar un perfil de vínculo superior (perfil de conmutador de host), o puede utilizar elperfil de vínculo superior predeterminado para nodos de NSX Edge sin sistema operativo.

n Se debe configurar un grupo de direcciones IP o debe estar disponible el protocolo DHCP en laimplementación de la red.

n Debe haber disponible al menos una tarjeta NIC física no utilizada en el host o nodo de NSX Edge.

Procedimiento


2 Seleccione Tejido (Fabric) > Nodos (Nodes) > Nodos de transporte (Transport Nodes) y hagaclic en Agregar (Add).

3 Introduzca la siguiente información: la dirección IP, el nombre del conmutador de host, el perfil devínculo superior, el grupo de direcciones IP (o seleccione DHCP) y la información de la NIC física.

n Introduzca un nombre para el nodo de transporte de NSX Edge.

n Seleccione un nodo de tejido de NSX Edge de la lista desplegable.

n Seleccione las zonas de transporte. Por lo general, un nodo de transporte de NSX Edgepertenece al menos a dos zonas de transporte: 1) Superposición para la conectividad de NSX-Ty 2) VLAN para la conectividad de vínculos superiores.

n Introduzca un nombre para el conmutador de host. El nombre del conmutador perimetral(denominado a veces nombre de conmutador de host). Los nombres de conmutadoresperimetrales deben concordar con los nombres que configuró al crear las zonas de transporte.

n Seleccione el perfil de vínculo superior.

n Seleccione un grupo de direcciones IP para el conmutador host superpuesto. Para losconmutadores host de la red VLAN, deje el campo Grupo de direcciones IP en blanco. No senecesita ninguna dirección IP de endpoint de túnel superpuesto porque los conmutadores dehost superpuestos solo se utilizan para el tráfico de VLAN de vínculo superior.


VMware, Inc. 121

n Seleccione el vínculo superior y la NIC virtual. Tenga en cuenta que, al contrario que un nodo detransporte host, que utiliza vmnicX como la NIC física, un nodo de transporte de NSX Edge utilizafp-ethX.

n Seleccione el vínculo superior. Los vínculos superiores disponibles dependen de la configuracióndel perfil de vínculo superior seleccionado.

Por ejemplo:

--

4 Haga clic en Guardar (Save) para salir.

Puede ver el nodo de transporte con la llamada API GET https://<nsx-mgr>/api/v1/transport-nodes/<transport-node-id>:

GET https://<nsx-mgr>/api/v1/transport-nodes/78a03020-a3db-44c4-a8fa-f68ad4be6a0c

{

"resource_type": "TransportNode",

"id": "78a03020-a3db-44c4-a8fa-f68ad4be6a0c",

"display_name": "node-comp-01b",


VMware, Inc. 122

"transport_zone_endpoints": [

{

"transport_zone_id": "efd7f38f-c5da-437d-af03-ac598f82a9ec",


{



}

]

}

],

"host_switches": [

{

"host_switch_profile_ids": [

{

"value": "8abdb6c0-db83-4e69-8b99-6cd85bfcc61d",

"key": "UplinkHostSwitchProfile"

},

{

"value": "9e0b4d2d-d155-4b4b-8947-fbfe5b79f7cb",

"key": "LldpHostSwitchProfile"

}

],


"pnics": [

{

"device_name": "vmnic1",


}

],

"static_ip_pool_id": "c78ac522-2a50-43fe-816a-c459a210127e"

}

],

"node_id": "c551290a-f682-11e5-ae84-9f8726e1de65",

"_create_time": 1459547122893,




"_revision": 1

}

Para obtener información sobre el estado, utilice la llamada API GET https://<nsx-mgr>/api/v1/transport-nodes/<transport-node-id>/status. Por ejemplo:

{

"control_connection_status": {

"degraded_count": 0,

"down_count": 0,

"up_count": 1,

"status": "UP"

},

"tunnel_status": {


VMware, Inc. 123

"down_count": 0,

"up_count": 0,

"status": "UNKNOWN",

"bfd_status": {

"bfd_admin_down_count": 0,

"bfd_up_count": 0,

"bfd_init_count": 0,

"bfd_down_count": 0

},

"bfd_diagnostic": {

"echo_function_failed_count": 0,

"no_diagnostic_count": 0,

"path_down_count": 0,

"administratively_down_count": 0,

"control_detection_time_expired_count": 0,

"forwarding_plane_reset_count": 0,

"reverse_concatenated_path_down_count": 0,

"neighbor_signaled_session_down_count": 0,

"concatenated_path_down_count": 0

}

},

"pnic_status": {

"degraded_count": 0,

"down_count": 0,

"up_count": 4,

"status": "UP"

},

"mgmt_connection_status": "UP",

"node_uuid": "cd4a8501-0ffc-44cf-99cd-55980d3d8aa6",

"status": "UNKNOWN"

}

Si el nodo de transporte se creó correctamente, Conectividad del LCP (LCP Connectivity cambia aActivo (Up) en Tejido (Fabric) > Nodos (Nodes) > Servidores perimetrales (Edges). Puede que tengaque volver a cargar la pantalla del explorador para ver este cambio.

Pasos siguientes

Agregue el nodo de NSX Edge a un clúster de servidores perimetrales. Consulte Crear un clúster deNSX Edge.

Crear un clúster de NSX EdgeTener un clúster multinodo de NSX Edge ayuda a garantizar que siempre haya disponible al menos unNSX Edge. Para crear un enrutador lógico de nivel 0 o un enrutador de nivel 1 con NAT, debe asociarlo aun clúster de NSX Edge. Por tanto, aunque solo tenga un NSX Edge, debe pertenecer a un clúster deNSX Edge para que sea útil.

Un nodo de transporte de NSX Edge solo se puede agregar a un único clúster de NSX Edge.

Un clúster de NSX Edge se puede utilizar para respaldar varios enrutadores lógicos.

Tras crear el clúster de NSX Edge, puede editarlo para agregar NSX Edge adicionales.


VMware, Inc. 124

Requisitos previos

n Instale al menos un nodo de NSX Edge.

n Una los NSX Edge al plano de administración.

n Agregue los NSX Edge como nodos de transporte.

n De manera alternativa, cree un perfil de clústeres de NSX Edge para alta disponibilidad (HA) enTejido (Fabric) > Perfiles (Profiles) > Perfiles de clústeres de servidores perimetrales (EdgeCluster Profiles). También puede utilizar el perfil de clústeres de NSX Edge predeterminado.

Procedimiento

1 En la IU de NSX Manager, vaya a Tejido (Fabric) > Nodos (Nodes) > Clústeres de servidoresperimetrales (Edge Clusters).

2 Introduzca un nombre para el clúster de NSX Edge.

3 Seleccione un perfil de clústeres de NSX Edge.

4 Haga clic en Editar (Edit) y seleccione Física (Physical) o Virtual (Virtual).

"Física" hace referencia a los NSX Edge que están instalados sin sistema operativo. "Virtual" hacereferencia a los NSX Edge que se instalan como máquinas/dispositivos virtuales.

5 Desde la columna Disponible (Available), seleccione los NSX Edge y haga clic en la flecha derechapara moverlos a la columna Seleccionados (Selected).

Pasos siguientes

Ahora puede crear topologías de redes lógicas y configurar servicios. Consulte la Guía de administraciónde NSX-T.


VMware, Inc. 125

Desinstalar NSX-T 9Puede eliminar los elementos de una superposición de NSX-T, eliminar un host hipervisor de NSX-T, odesinstalar NSX-T por completo.


n Desconfigurar una superposición de NSX-T

n Eliminar un host de NSX-T o desinstalar NSX-T por completo

Desconfigurar una superposición de NSX-TSi quiere eliminar una superposición conservando en su lugar los nodos de transporte, siga estos pasos.

Procedimiento

1 En su herramienta de administración de VM, desconecte todas las VM de cualquier conmutadorlógico.

2 En la API o IU de NSX Manager, elimine todos los enrutadores lógicos.

3 En la API o IU de NSX Manager, elimine todos los puertos de conmutadores lógicos y a continuacióntodos los conmutadores lógicos.

4 En la API o IU de NSX Manager, elimine todos los NSX Edge y, a continuación, todos los clústeresde NSX Edge.

5 Configure una nueva superposición de NSX-T en la medida que sea necesario.

Eliminar un host de NSX-T o desinstalar NSX-T porcompletoSi quiere desinstalar NSX-T por completo o simplemente eliminar un host de hipervisor de NSX-T paraque el host ya no participe en la superposición de NSX-T, siga los pasos indicados a continuación.

El siguiente programa describe cómo realizar una desinstalación completa de NSX-T.

Procedimiento

1 En su herramienta de administración de VM, desconecte todas las VM del host de cualquierconmutador lógico de NSX-T.

VMware, Inc. 126

2 En NSX Manager, elimine el nodo de transporte mediante la IU Tejido (Fabric) > Nodos (Nodes) >Nodos de transporte (Transport Nodes) o con la API DELETE /api/v1/transport-node/<node-id>.

Eliminar el nodo de transporte hace que el conmutador de host de NSX-T sea eliminado del host.Puede confirmarlo ejecutando el siguiente comando.

[root@host:~] esxcli network vswitch dvs vmware list

En KVM, el comando es:

ovs-vsctl show

3 En la CLI de NSX Manager, habilite e inicie el servicio de instalación de NSX-T.

nsx-manager-1> set service install-upgrade enable

nsx-manager-1> start service install-upgrade

4 Elimine del registro el host del plano de administración y elimine los módulos de NSX-T.

Eliminar todos los módulos de NSX-T podría tardar hasta 10 minutos.

Hay varios métodos que puede utilizar para eliminar los módulos de NSX-T:

n En NSX Manager, use la IU Tejido (Fabric) > Nodos (Nodes) > Hosts (Hosts) > Eliminar(Delete).

En la IU, asegúrese de que esté marcada la opción Desinstalar componentes de NSX(Uninstall NSX Components). Esto hace que se desinstalen del host los módulos de NSX-T.Tenga en cuenta que el uso de Tejido (Fabric) > Nodos (Nodes) > Hosts (Hosts) > Eliminar(Delete) sin marcar la opción Desinstalar componentes de NSX (Uninstall NSX Components)no está pensado para ser utilizado en un host que se encuentra en un estado bueno. Solo sepensó como solución alternativa para hosts que están en un estado malo.

n Utilice la API DELETE /api/v1/fabric/nodes/<node-id>.

n Utilice la CLI.

1 Obtenga la huella digital del administrador.

manager> get certificate api thumbprint

2 En la CLI de NSX-T del host, ejecute el siguiente comando para desconectar el host delplano de administración.

host> detach management-plane <MANAGER> username <MANAGER-USERNAME> password <MANAGER-

PASSWORD> thumbprint <MANAGER-THUMBPRINT>

3 En el host, ejecute el siguiente comando para eliminar los filtros.

[root@host:~] vsipioctl clearallfilters


VMware, Inc. 127

4 En el host, ejecute el siguiente comando para detener netcpa.

[root@host:~] /etc/init.d/netcpad stop

5 Apague las máquinas virtuales en el host.

6 Desinstale manualmente los módulos de NSX-T del host.

Tenga en cuenta que no se permite eliminar módulos individuales. Debe eliminar todos losmódulos con un único comando.

esxcli software vib remove -n nsx-aggservice -n nsx-da -n nsx-esx-datapath -n nsx-exporter

-n nsx-host -n nsx-lldp -n nsx-mpa -n nsx-netcpa -n nsx-python-protobuf -n nsx-sfhc -n nsx-

support-bundle-client -n nsxa -n nsxcli

En RHEL, utilice el comando sudo yum remove <package-name>. En Ubuntu, utilice elcomando apt-get remove <package-name>.

En ambos casos, utilice caracteres comodín para seleccionar los módulos de NSX-T.

Asimismo, elimine los siguientes módulos:

n En Ubuntu: tcpdump-ovs, nicira-ovs-hypervisor-node, python-openvswitch, openvswitch-*, libgoogle-glog0, libjson-spirit

n En RHEL: tcpdump-ovs, openvswitch, kmod-openvswitch, glog, json_spirit

Pasos siguientes

Tras realizar este cambio, se elimina el host del plano de administración y ya no podrá formar parte de lasuperposición de NSX-T.

Si va a eliminar NSX-T por completo, en su herramienta de administración de VM, apagueNSX Manager, NSX Controller y NSX Edge y elimínelos del disco.


VMware, Inc. 128

n nsx-t data center 1 - vmware...estado en los motores de reenvío. el lcp comparte el mismo destino...

Documents