Guía de administración de NSX-T. VMware NSX-T 1.1

Transcripción

1 VMware NSX-T 1.1

2 Puede encontrar la documentación técnica más actualizada en el sitio web de WMware en: En el sitio web de VMware también están disponibles las últimas actualizaciones del producto. Si tiene algún comentario sobre esta documentación, envíelo a la siguiente dirección de correo electrónico: docfeedback@vmware.com Copyright 2017 VMware, Inc. Todos los derechos reservados. Copyright e información de marca registrada. VMware, Inc Hillview Ave. Palo Alto, CA VMware, Inc. Paseo de la Castellana 141. Planta Madrid. Tel.: Fax: VMware, Inc.

3 Contenido Acerca de administrar VMware NSX-T 7 1 Descripción general de NSX-T 9 Plano de datos 11 Plano de control 11 Plano de administración 12 NSX Manager 12 NSX Controller 13 Conmutadores lógicos 13 Enrutadores lógicos 14 NSX Edge 15 Zonas de transporte 15 Conceptos clave 15 2 Crear conmutadores lógicos y configurar la asociación de máquinas virtuales 19 Información sobre los modos de replicación del marco BUM 20 Crear un conmutador lógico 21 Puente de Capa 2 22 Crear un conmutador lógico VLAN para el vínculo superior de NSX Edge 25 Conectar una VM a un conmutador lógico 27 Probar la conectividad de Capa Configurar perfiles de conmutación para conmutadores lógicos y puertos lógicos 39 Información sobre el perfil de conmutación de QoS 40 Información sobre el perfil de conmutación de creación de reflejo del puerto 42 Información sobre el perfil de conmutación de detección de direcciones IP 45 Información sobre SpoofGuard 46 Información sobre el perfil de conmutación de seguridad del conmutador 49 Información sobre el perfil de conmutación de gestión de direcciones MAC 50 Asociar un perfil personalizado a un conmutador lógico 51 Asociar un perfil personalizado con un puerto de conmutador lógico 52 4 Configurar el enrutador lógico de nivel 1 55 Crear un enrutador lógico de nivel 1 56 Agregar puertos de vínculo inferior para el enrutador lógico de nivel 1 56 Configurar anuncios de rutas en un enrutador lógico de nivel 1 57 Configurar una ruta estática de enrutador lógico de nivel Configurar un enrutador lógico de nivel 0 63 Crear un enrutador lógico de nivel 0 64 VMware, Inc. 3

4 Adjuntar nivel 0 y nivel 1 65 Conectar un enrutador lógico de nivel 0 a un conmutador lógico VLAN 68 Configurar una ruta estática 71 Opciones de configuración de BGP 75 Configurar BFD en un enrutador lógico de nivel 0 80 Habilitar la redistribución de rutas en el enrutador lógico de nivel 0 80 Información sobre el enrutamiento ECMP 82 Crear una lista de prefijos IP 87 Crear un mapa de rutas 88 6 Traducción de direcciones de red 89 NAT de nivel 1 90 NAT de nivel Secciones y reglas de firewall 99 Agregar una sección de reglas de firewall 100 Eliminar una sección de reglas de firewall 101 Habilitar y deshabilitar reglas de sección 101 Habilitar y deshabilitar registros de sección 101 Acerca de las reglas de firewall 101 Agregar una regla de firewall 103 Eliminar una regla de firewall 106 Editar la regla de Distributed Firewall predeterminada 106 Cambiar el orden de una regla de firewall 107 Filtrar reglas de firewall 107 Excluir objetos de cumplimiento de reglas del firewall Configurar grupos y servicios 109 Crear un conjunto de direcciones IP 109 Crear un grupo de direcciones IP 110 Crear un conjunto de direcciones MAC 110 Crear un grupo NSGroup 111 Configurar servicios y grupos de servicios DHCP 115 Crear un perfil de servidor DHCP 115 Crear un servidor DHCP 116 Adjuntar un servidor DHCP a un conmutador lógico 116 Desasociar un servidor DHCP de un conmutador lógico 117 Crear un perfil de retransmisión DHCP 117 Crear un servicio de retransmisión DHCP 117 Agregar un servicio DHCP a un puerto de enrutador lógico Configurar servidores proxy de metadatos 119 Agregar un servidor proxy de metadatos 119 Adjuntar un servidor proxy de metadatos a un conmutador lógico 120 Desconectar un servidor proxy de metadatos de un conmutador lógico VMware, Inc.

5 Contenido 11 Operaciones y administración 123 Agregar una clave de licencia 123 Administrar cuentas de usuarios 124 Configurar certificados 125 Configurar dispositivos 129 Administrar etiquetas 130 Buscar objetos 130 Buscar la huella digital SSH de un servidor remoto 131 Restaurar y hacer copias de seguridad de NSX Manager 132 Administrar dispositivos y clústeres de dispositivos 142 Mensajes del sistema de registro 153 Configurar IPFIX 155 Rastrear la ruta de un paquete con Traceflow 157 Consultar información sobre la conexión de puertos 158 Supervisar la actividad de un puerto del conmutador lógico 159 Supervisar las sesiones de creación de reflejo del puerto 159 Supervisar nodos de tejido 161 Recopilar paquetes de soporte 161 Índice 163 VMware, Inc. 5

6 6 VMware, Inc.

7 Acerca de administrar VMware NSX-T La Guía de administración de NSX-T proporciona información sobre la configuración y la administración de redes para VMware NSX-T, incluida información sobre cómo crear puertos y conmutadores lógicos y sobre cómo configurar las redes para enrutadores lógicos con niveles. También describe cómo configurar firewalls NAT, SpoofGuard, agrupaciones y DHCP. Público objetivo Esta información está dirigida a quien desee configurar NSX-T. La información está escrita para administradores de sistemas Windows o Linux con experiencia y que estén familiarizados con la tecnología de máquinas virtuales, las redes y las operaciones de seguridad. Glosario de publicaciones técnicas de VMware Publicaciones técnicas de VMware proporciona un glosario de términos que podrían resultarle desconocidos. Si desea ver las definiciones de los términos que se utilizan en la documentación técnica de VMware, visite la página VMware, Inc. 7

8 8 VMware, Inc.

9 Descripción general de NSX-T 1 De 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 de redes de NSX-T, mediante programación, crea, elimina, restaura y crea instantáneas de redes virtuales basadas en software. Con la virtualización de red, el equivalente funcional de un hipervisor de red reproduce en el software el conjunto 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 servicios pueden ensamblarse mediante programación en cualquier combinación arbitraria para producir redes virtuales únicas y aisladas en cuestión de segundos. NSX-T funciona implementando tres planos independientes pero integrados, que son los planos de administración, control y datos. Los tres planos se implementan como un conjunto de procesos, módulos y agentes que residen en tres tipos de nodos: nodos de administrador, de controladora y de transporte. Cada nodo aloja un agente del plano de administración. El nodo de NSX Manager aloja los servicios de API. Cada instalación de NSX-T admite un único nodo de NSX Manager, pero no admite ningún clúster de NSX Manager. Los nodos de NSX Controller alojan los demonios del clúster del plano de control central. Los nodos de NSX Manager y NSX Controller pueden alojarse conjuntamente en el mismo servidor físico. VMware, Inc. 9

10 Los nodos de transporte alojan demonios del plano de control local y motores de reenvío. Plano de administración Nodos de administrador Bus de plano de administración Nodos de controladora Agente del MP Agente del MP Nodos de transporte Agente del MP Plano de control centralizado Clúster del CCP Plano de control localizado Demonios del LCP Plano de datos Motor de reenvío Este capítulo cubre los siguientes temas: Plano de datos, página 11 Plano de control, página 11 Plano de administración, página 12 NSX Manager, página 12 NSX Controller, página 13 Conmutadores lógicos, página 13 Enrutadores lógicos, página 14 NSX Edge, página 15 Zonas de transporte, página 15 Conceptos clave, página VMware, Inc.

11 Capítulo 1 Descripción general de NSX-T Plano de datos Realiza el envío sin estado o la transformación de paquetes basándose en tablas rellenadas por el plano de control, y transmite la información sobre la topología al plano de control. Asimismo, mantiene las estadí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 de VIF, estado de túnel, etc. Si está tratando con paquetes que se mueven de un lugar a otro, se encuentra en el plano de datos. El plano de datos también mantiene el estado de y gestiona los errores entre varios vínculos/túneles. El rendimiento por paquete es primordial, con unos requisitos muy estrictos de latencia o vibración. El plano de datos no se contiene necesariamente en su totalidad en el kernel, en los controladores, en el espacio de usuario ni en procesos de espacio de usuario específicos. El plano de datos se restringe al reenvío totalmente sin estado basado en tablas/reglas rellenadas por el plano de control. El plano de datos también podría tener componentes que mantengan cierta cantidad de estado para determinadas funciones, como la de terminación TCP. Esto es diferente desde el estado administrado por el plano de control, como asignaciones de túnel de IP MAC, porque el estado administrado por el plano de control consiste en cómo reenviar los paquetes, mientras que el estado administrado por el plano de datos se ve limitado a cómo manipular la carga. Plano de control Calcula todo el estado en tiempo de ejecución efímero basándose en la configuración del plano de administración, disemina información sobre topología notificada por los elementos del plano de datos e inserta 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 con mensajes en proceso para mantener el plano de datos en presencia de una configuración de usuario estática, está en el plano de control (por ejemplo, responder a una vmotion de una máquina virtual o VM es responsabilidad del plano de control, pero conectar la VM a la red lógica es responsabilidad del plano de administración). A menudo, el plano de control actúa como un reflector de información topológica desde los elementos del plano de datos entre sí, como, por ejemplo, asignaciones de MAC/túnel para VTEP. En otros casos, el plano de control actúa sobre los datos recibidos desde algunos elementos del plano de datos para (re)configurar algunos elementos del plano de datos, como usar localizadores VIF para 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 ejecuta en los nodos de clúster de NSX Controller y el plano de control local (LCP), que se ejecuta en los nodos de transporte, adyacentes al plano de datos que controla. El plano de control central calcula algún estado en tiempo de ejecución efímero basado en la configuración del plano de administración y disemina la información notificada por los elementos del plano de datos mediante el plano de control local. El Plano de control local supervisa el estado de los vínculos locales, calcula la mayoría del estado en tiempo de ejecución efímero basándose en actualizaciones del plano de datos y CCP inserta una configuración sin estado en los motores de reenvío. El LCP comparte el mismo destino que el elemento del plano de datos que lo aloja. VMware, Inc. 11

12 Plano de administración El plano de administración proporciona un punto de entrada único de la API al sistema, mantiene la configuración de los usuarios, administra las solicitudes de los usuarios y realiza tareas operacionales en todos 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 los usuarios es responsabilidad del plano de administración, mientras que la diseminación de dicha configuración hasta el subconjunto adecuado de elementos del plano de datos es responsabilidad del plano de control. Esto significa que algunos datos pertenecen a varios planos en función de la etapa en la que se encuentre su existencia. El plano de administración también se encarga de solicitar las estadí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), tal como lo gestiona el usuario mediante configuración. Los cambios se realizan utilizando una API RESTful API o la IU de NSX-T. En NSX también hay un agente de plano de administración (MPA) ejecutándose en todos los nodos de clú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. El MPA puede ejecutarse de manera relativamente independiente con respecto al plano de control y al plano de datos y se puede reiniciar independientemente de que su proceso se bloquee. No obstante, hay escenarios en los que tienen el mismo destino porque se ejecutan en el mismo host. Se puede acceder al MPA tanto de manera local como remota. El MPA se ejecuta en los nodos de transporte, en los nodos de control y en los nodos de administración para la administración de nodos. En los nodos de transporte también puede realizar tareas relacionadas con el plano de datos. Entre las tareas que suceden en el plano de administración se incluyen: Persistencia de configuración (estado lógico deseado) Validación de entrada Administración de usuarios -- asignaciones de funciones Administración de directivas Seguimiento de tareas en segundo plano NSX Manager NSX Manager proporciona la interfaz de usuario gráfica (GUI) y las API REST para crear, configurar y supervisar los componentes de NSX-T, como controladoras, conmutadores lógicos y puertas de enlace de servicios Edge. NSX Manager es el plano de administración para el ecosistema de NSX-T. NSX Manager proporciona una 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 redes virtuales creadas por NSX-T. Proporciona configuración y orquestación de: Componentes de redes lógicas: conmutación y enrutamiento lógicos Servicios Edge y de redes Servicios de seguridad y firewall distribuido: componentes integrados de NSX Manager o proveedores de terceros integrados pueden suministrar servicios perimetrales y de seguridad. 12 VMware, Inc.

13 Capítulo 1 Descripción general de NSX-T NSX Manager permite orquestar a la perfección tanto los servicios integrados como los externos. Todos los servicios de seguridad, tanto los integrados como los de terceros, se implementan y configuran mediante 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 basados en directivas, la compartición de contexto y la gestión de eventos entre servicios. Esto simplifica la auditorí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. Esta arquitectura flexible permite la automatización de todos los aspectos de configuración y supervisión mediante cualquier plataforma de administración de la nube, plataforma de proveedor de seguridad o marco de trabajo de automatización. El Agente del plano de administración (MPA) de NSX-T es un componente de NSX Manager que reside en cada uno de los nodos (hipervisor). El MPA está a cargo de persistir el estado deseado del sistema y comunicar mensajes sin control de flujo (NFC) como configuración, estadísticas, estado y datos en tiempo real entre los nodos de transporte y el plano de administración. NSX Controller NSX Controller es un sistema de administración de estado distribuido avanzado que controla las redes virtuales y los túneles de transporte superpuestos. NSX Controller se implementa como un clúster de dispositivos virtuales de alta disponibilidad responsables de la implementación mediante programación de redes virtuales en toda la arquitectura de NSX-T. El Plano de control central (CCP) de NSX-T se separa lógicamente de todo el tráfico del plano de datos, lo que significa que cualquier error en el plano de control no afectará a las operaciones existentes del plano de datos. El tráfico no pasa por la controladora. En su lugar, la controladora es responsable de proporcionar 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 del transporte de datos son una cuestión primordial en las redes. Para mejorar aún más la alta disponibilidad y escalabilidad, NSX Controller se implementa en un clúster de tres instancias. Conmutadores lógicos La capacidad de conmutación lógica de la plataforma NSX Edge permite girar redes L2 lógicas aisladas con la misma flexibilidad y agilidad que existe para máquinas virtuales. Una implementación de nube para un centro de datos virtual tiene una variedad de aplicaciones en varios arrendatarios. Estas aplicaciones e arrendatarios requieren estar aislados entre sí por motivos de seguridad 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 establecer conectividad independientemente de su ubicación física en la red del centro de datos. Esto se permite el desacoplamiento de la infraestructura de red de la red lógica (esto es, la red subyacente desde la red superpuesta) 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 lo largo de muchos hosts con la accesibilidad de IP de Capa 3 entre ellas. Si planea restringir algunas redes lógicas a un conjunto de hosts limitado o tiene requisitos de conectividad personalizados, puede que deba crear conmutadores lógicos adicionales. VMware, Inc. 13

14 Enrutadores lógicos Los enrutadores lógicos de NSX-T proporcionan conectividad de norte a sur, lo que permite a los arrendatarios acceder a redes públicas, y conectividad de este a oeste entre las distintas redes dentro de los mismos arrendatarios. Un enrutador lógico es una partición configurada de un enrutador de hardware de red tradicional. Replica la funcionalidad del hardware, lo cual crea múltiples dominios de enrutamiento dentro de un único enrutador. Los enrutadores lógicos realizan un subconjunto de las tareas que puede gestionar el enrutador físico, y cada una de ellas puede contener múltiples instancias de enrutamiento y tablas de enrutamiento. El uso de enrutadores lógicos puede ser una forma eficaz de maximizar el uso del enrutador, porque un conjunto de enrutadores dentro de un único enrutador físico pueden realizar las operaciones 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 de nivel superior es el de nivel 0 y el de nivel inferior es el de nivel 1. Esta estructura concede tanto al administrador de proveedores como al administrador de arrendatarios un control completo sobre sus servicios y políticas. Los administradores controlan y configuran los servicios y el enrutamiento de nivel 0 y los administradores de arrendatarios controlan y configuran el nivel 1. El extremo norte del nivel 0 se conecta a la red física. Además, es en este extremo donde se pueden configurar los protocolos de enrutamiento dinámico para intercambiar información de enrutamiento con los enrutadores físicos. El extremo sur del nivel 0 se conecta a múltiples capas de enrutamiento de nivel 1 y recibe información de enrutamiento de ellos. Para optimizar el uso de los recursos, la capa de nivel 0 no inserta todas las rutas procedentes 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 por los 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 habilitada la redistribución de rutas hacia la capa de nivel 0. Sin embargo, no hay un protocolo de enrutamiento clásico (como OSPF o BGP) ejecutándose entre la capa de nivel 1 y la de nivel 0, y todas las rutas pasan por el plano de control de NSX-T. Tenga en cuenta que la topología de enrutamiento de dos niveles no es obligatoria. Si no hay necesidad de separar a proveedores de arrendatarios, se puede crear una topología de un solo nivel y en este escenario los conmutadores lógicos se conectan directamente a la capa 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 varios enrutadores de servicio (SR). Un DR abarca los hipervisores cuyas VM están conectadas a este enrutador lógico, así como los nodos perimetrales a los que está asociado el enrutador lógico. En el aspecto funcional, el DR es responsable del enrutamiento distribuido de un salto entre conmutadores lógicos o enrutadores lógicos conectados a este enrutador lógico. El SR es responsable de suministrar los servicios que no estén implementados actualmente de forma distribuida, como NAT con estado. Un enrutador lógico siempre tiene un DR, y varios SR si se cumple cualquiera de las siguientes condiciones: El enrutador lógico es un enrutador de nivel 0, aunque no se configuraron servicios con estado. El enrutador lógico es un enrutador de nivel 1 vinculado a un enrutador de nivel 0 y tiene servicios configurados 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 que conecta el enrutador de servicios al enrutador distribuido. El MP crea un conmutador lógico de tránsito y lo asigna a una interfaz de red virtual (VNI) y, a continuación, crea un puerto en cada SR y DR, los conecta al conmutador lógico de tránsito y asigna direcciones IP al SR y DR. 14 VMware, Inc.

15 Capítulo 1 Descripción general de NSX-T NSX Edge NSX Edge proporciona servicios de enrutamiento y conectividad a las redes externas a la implementación de NSX-T. Con NSX Edge, las máquinas virtuales o cargas de trabajo que residen en el mismo host, en diferentes subredes, pueden comunicarse entre sí sin necesidad de atravesar una interfaz de enrutamiento tradicional. NSX Edge es requerido para establecer conectividad externa desde el dominio de NSX-T, a través de un enrutador de nivel 0 mediante enrutamiento estático o BGP. Además, debe implementarse un NSX Edge si requiere servicios de traducción de direcciones de red (NAT) en los enrutadores lógicos de nivel 0 o de nivel 1. La puerta de enlace de NSX Edge conecta redes aisladas de zona de rutas internas con redes compartidas (vínculo superior) proporcionando servicios de perta de enlace comunes, como enrutamiento dinámico y NAT. Entre las implementaciones comunes de NSX Edge se incluyen DMZ y los entornos de nube multiarrendatario, donde NSX Edge crea límites virtuales para cada arrendatario. Zonas de transporte Una zona de transporte controla con qué hosts puede comunicarse un conmutador lógico. Puede abarcar uno o más clústeres de host. Las zonas de transporte establecen qué hosts y, por lo tanto, qué máquinas virtuales 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 una infraestructura de red física. Esta comunicación tiene lugar a través de una o varias interfaces definidas como endpoints de túnel virtual (VTEP). Si hay dos nodos de transporte en una misma zona de transporte, las VM alojadas en dichos nodos de transporte podrán "ver" y, por tanto, conectarse a conmutadores lógicos de NSX-T que también se encuentren en esa zona de transporte. Esta conexión permite a las VM comunicarse entre sí, siempre que las VM tengan disponibilidad de Capa 2/Capa 3. Si las VM están conectadas a conmutadores que estén en distintas zonas de transporte, las VM no se pueden comunicar entre sí. Las zonas de transporte no reemplazan 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 poder establecer la conexión. Si se cumple dicho requisito previo, la disponibilidad es posible, pero no automática. Para que la disponibilidad sea real, las redes de Capa 2 y (para distintas subredes) Capa 3 deben estar operativas. Un nodo puede servir como nodo de transporte si contiene al menos un conmutador de host. Cuando crea un nodo de transporte de host y a continuación agrega el nodo a una zona de transporte, NSX-T instala un conmutador de host en el host. Para cada zona de transporte a la que pertenezca el host, se instala un conmutador de host aparte. El conmutador de host se utiliza para conectar VM a conmutadores lógicos de NSX-T y para crear vínculos superiores e inferiores de enrutador lógico de NSX-T. Conceptos clave Los conceptos comunes de NSX-T que se utilizan en la documentación y la interfaz de usuario. Plano de control Plano de datos Calcula el estado de ejecución basándose en la configuración del plano de administración. El plano de control difunde la información sobre la topología notificada por los elementos del plano de datos e inserta una configuración sin estado en los motores de reenvío. Realiza el reenvío sin estado o la transformación de paquetes basándose en tablas rellenadas por el plano de control. El plano de datos suministra información sobre la topología al plano de control y conserva las estadísticas relativas al nivel de los paquetes. VMware, Inc. 15

16 Red externa Nodo de tejido Perfil de tejido Salida de puertos lógicos Entrada de puertos lógicos Enrutador lógico Puerto de enrutador lógico Conmutador lógico Una red física o VLAN no administrada por NSX-T. Puede vincular su red lógica o red superpuesta a una red externa mediante un NSX Edge. Por ejemplo, una red física en un centro de datos de cliente o una VLAN en un entorno físico. Nodo registrado con el plano de administración de NSX-T y que tiene instalados módulos de NSX-T. Para que un host de hipervisor o NSX Edge forme parte de la superposición de NSX-T, debe agregarse al tejido de NSX-T. Representa una configuración específica que se puede asociar a un clúster de NSX Edge. Por ejemplo, el perfil de tejido puede contener las propiedades de tunelización para la detección de pares muertos. El tráfico de red entrante que llega a la VM o red lógica se denomina tráfico de salida porque sale de la red del centro de datos y accede al espacio virtual. El tráfico de red saliente que va de la VM a la red del centro de datos se denomina tráfico de entrada porque es tráfico de acceso a la red física. Entidad de enrutamiento de NSX-T. Puerto de red lógica al que puede adjuntar un puerto de conmutador lógico o un puerto de vínculo superior a una red física. Entidad API que proporciona conmutación de Capa 2 virtual para interfaces de VM e interfaces de puerta de enlace. Un conmutador lógico da a los administradores de la red de arrendatarios el equivalente lógico de un conmutador de Capa 2 físico, lo que les permite conectar un conjunto de VM a un dominio de difusión común. Un conmutador lógico es una entidad lógica independiente de la infraestructura de hipervisor física y abarca a muchos hipervisores, conectando VM independientemente de su ubicación física. Esto permite a las VM migrar sin necesidad de que el administrador de la red de arrendatarios tenga que realizar la reconfiguración. En una nube de múltiples arrendatarios, pueden existir muchos conmutadores lógicos lado a lado en el mismo hardware de hipervisor, con cada segmento de Capa 2 aislado del resto. Los conmutadores lógicos se pueden conectar mediante enrutadores lógicos y los enrutadores lógicos pueden proporcionar puertos de vínculos superiores conectados a la red física externa. Puerto de conmutador lógico Plano de administración Clúster de NSX Controller Punto de conexión de conmutador lógico para establecer una conexión a una interfaz de red de máquina virtual o una interfaz de enrutador lógico. El puerto de conmutador lógico indica el perfil de conmutación aplicado, el estado del puerto y el estado del vínculo. Proporciona un punto de entrada único de la API al sistema, persiste la configuración de los usuarios, administra las solicitudes de los usuarios y realiza tareas operacionales en todos los nodos de administración, control y plano de datos del sistema. El plano de administración también es responsable de consultar, modificar y persistir la configuración de los usuarios. Se implementa como un clúster de dispositivos virtuales de alta disponibilidad responsables de la implementación mediante programación de redes virtuales en toda la arquitectura de NSX-T. 16 VMware, Inc.

17 Capítulo 1 Descripción general de NSX-T Clúster de NSX Edge Nodo de NSX Edge Conmutador de host de NSX-T o KVM Open vswitch Colección de dispositivos de nodos de NSX Edge que tienen la misma configuración que los protocolos implicados en la supervisión de alta disponibilidad. Parte integrante del objetivo funcional es el proporcionar potencia de cálculo para suministrar las funciones de servicios IP y enrutamiento IP. Software que se ejecuta en el hipervisor y proporciona reenvío de tráfico físico. El conmutador de host u OVS es invisible para el administrador de la red de arrendatarios y proporciona el servicio de reenvío subyacente en el que se basa cada conmutador lógico. Para conseguir la virtualización de la red, un controlador de red debe configurar los conmutadores de host del hipervisor con tablas de flujo de red que forman los dominios de difusión lógica que definieron los administradores de arrendatarios cuando crearon y configuraron sus conmutadores lógicos. Cada dominio de difusión lógica se implementa mediante la tunelización del tráfico de VM a VM y del tráfico de VM a enrutador lógico utilizando el mecanismo de encapsulación de túneles Geneve. El controlador de red tiene la visión global del centro de datos y garantiza que las tablas de flujo del conmutador de host del hipervisor se actualicen cuando se creen, muevan o eliminen máquinas virtuales (VM). NSX Manager Open vswitch (OVS) Red lógica superpuesta Interfaz física (pnic) Enrutador lógico de nivel 0 Enrutador lógico de nivel 1 Zona de transporte Nodo que aloja los servicios API, el plano de administración y los servicios de agente. Conmutador de software de código abierto que actúa como un conmutador de host del hipervisor dentro de XenServer, Xen, KVM y otros hipervisores basados en Linux. Los componentes de conmutación de NSX Edge se basan en OVS. Red lógica implementada mediante el uso de tunelización de Capa2 en Capa 3 de tal modo que la topología vista por las VM se desacopla de la de la red física. Interfaz de red en un servidor físico en el que se instaló un hipervisor. El enrutador lógico proveedor también se conoce como enrutador lógico de nivel 0 y se conecta a la red física. El enrutador lógico de nivel 0 es un enrutador de nivel superior y se puede realizar como clúster activo-activo o activo-en espera del enrutador de servicios. El enrutador lógico ejecuta BGP y pares con enrutadores físicos. En el modo activo-en espera, el enrutador lógico también puede proporcionar servicios con estado. El enrutador lógico de nivel 1 es el enrutador de segundo nivel que se conecta a un enrutador lógico de nivel 0 para la conectividad en dirección norte y a una o varias redes superpuestas para la conectividad en dirección sur. El enrutador lógico de nivel 1 puede ser un clúster activo-en espera del enrutador de servicios que proporciona servicios con estado. Colección de nodos de transporte que define el alcance máximo de conmutadores lógicos. Una zona de transporte representa un conjunto de hipervisores suministrados de manera similar y los conmutadores lógicos que conectan VM en dichos hipervisores. NSX-T puede implementar los paquetes de software de soporte necesarios para los hosts porque sabe qué funciones están habilitadas en los conmutadores lógicos. VMware, Inc. 17

18 Interfaz de VM (vnic) VTEP Interfaz de red en una máquina virtual que proporciona conectividad entre el sistema operativo del invitado virtual y el vswitch estándar o el conmutador distribuido vsphere. La vnic se puede adjuntar a un puerto lógico. Puede identificar una vnic basándose en su ID exclusivo (UUID). Endpoint de túnel virtual. Los endpoints de túnel permiten a los hosts del hipervisor participar en una superposición de NSX-T. La superposición de NSX-T implementa una red de Capa 2 sobre un tejido de redes de Capa 3 existente encapsulando tramas dentro de paquetes y transfiriendo los paquetes a través de una red de transporte subyacente. La red de transporte subyacente puede ser otra red de Capa 2 o puede cruzar los límites de la Capa 3. El VTEP es el punto de conexión en el que se produce la encapsulación y la desencapsulación. 18 VMware, Inc.

19 Crear conmutadores lógicos y configurar la asociación de máquinas virtuales 2 Un conmutador lógico de NSX-T reproduce la funcionalidad de conmutación y el tráfico de multidifusión (BUM), unidifusión desconocida y difusión en un entorno virtual completamente independiente del hardware subyacente. Los conmutadores lógicos son similares a las VLAN en cuanto a que proporcionan conexiones de red a las que se pueden conectar máquinas virtuales. De este modo, las máquinas virtuales pueden comunicarse entre ellas mediante túneles entre hipervisores si están conectadas al mismo conmutador lógico. Cada conmutador lógico tiene un identificador de red virtual (VNI), como un ID de VLAN. A diferencia de VLAN, los VNI se escalan bien más allá de los límites de los ID de VLAN. Al agregar conmutadores lógicos, es importante que planifique la topología que crea. Figura 2 1. Topología del conmutador lógico Conmutador lógico de aplicaciones VM VM Máquina virtual de aplicaciones 1 Máquina virtual de aplicaciones 2 Por ejemplo, la topología muestra un único conmutador lógico conectado a dos máquinas virtuales. Las dos máquinas virtuales pueden estar en hosts diferentes o en el mismo host, en clústeres de hosts diferentes o en el mismo clúster de hosts. Como las máquinas virtuales del ejemplo están en la misma red virtual, las direcciones IP subyacentes configuradas en las máquinas virtuales deben estar en la misma subred. Este capítulo cubre los siguientes temas: Información sobre los modos de replicación del marco BUM, página 20 Crear un conmutador lógico, página 21 Puente de Capa 2, página 22 Crear un conmutador lógico VLAN para el vínculo superior de NSX Edge, página 25 VMware, Inc. 19

20 Conectar una VM a un conmutador lógico, página 27 Probar la conectividad de Capa 2, página 34 Información sobre los modos de replicación del marco BUM Cada nodo de transporte del host es un endpoint de túnel. Cada endpoint de túnel tiene una dirección IP. Estas direcciones IP pueden encontrarse en la misma subred o en diferentes subredes en función de la configuración de los grupos de direcciones IP o de DHCP para los nodos de transporte. Cuando dos máquinas virtuales de hosts diferentes se comunican directamente, el tráfico encapsulado de unidifusión se intercambia entre las dos direcciones IP del endpoint de túnel asociadas a los dos hipervisores sin utilizar la inundación. Sin embargo, al igual que con cualquier red de Capa 2, a veces el tráfico que origina una máquina virtual necesita inundarse, lo que significa que necesita enviarse al resto de las máquinas virtuales que pertenecen al mismo conmutador lógico. Esto sucede con el tráfico de multidifusión, de unidifusión desconocida y de difusión de Capa 2 (tráfico BUM). Recuerde que un único conmutador lógico de NSX-T puede abarcar varios hipervisores. El tráfico BUM que origina una máquina virtual de un determinado hipervisor necesita replicarse en los hipervisores remotos que alojan otras máquinas virtuales que están conectadas al mismo conmutador lógico. Para habilitar esta inundación, NSX-T admite dos modos de replicación diferentes: Segundo nivel jerárquico (en ocasiones denominado MTEP) Encabezado (en ocasiones denominado origen) El modo de replicación del segundo nivel jerárquico queda ilustrado en el siguiente ejemplo. Imaginemos que tiene un host A, que cuenta con dos máquinas virtuales conectadas a los identificadores de red virtual (VNI) 5.000, y Imagine que los VNI son similares a las VLAN, pero cada conmutador lógico tiene un único VNI asociado a él. Por esta razón, los términos VNI y el conmutador lógico se suelen utilizar indistintamente. Cuando decimos que un host se encuentra en un VNI, queremos decir que tiene máquinas virtuales que están conectadas a un conmutador lógico con ese VNI. Una tabla de endpoints de túnel muestra las conexiones entre el VNI y el host. El host A examina la tabla de endpoints de túnel del VNI y determina las direcciones IP de endpoints de túneles de los otros hosts del VNI Algunas de estas conexiones de VNI se encontrarán en la misma subred IP, también denominado segmento de IP, como el endpoint de túnel del host A. Para cada una de ellas, el host A creará una copia independiente de cada marco BUM y enviará la copia directamente a cada host. Otros endpoints de túneles de los hosts se encuentran en diferentes subredes o segmentos de IP. Para cada segmento en el que haya varios endpoints de túneles, el host A propone uno de estos endpoints para que sea el replicador. El replicador recibe del host A una copia de cada marco BUM del VNI Esta copia se marca como Replicar localmente (Replicate locally) en el encabezado de encapsulación. El host A no envía copias a otros hosts del mismo segmento de IP como el replicador. El replicador deberá crear una copia del marco BUM para cada host que sabe que está en el VNI y en el mismo segmento de IP como ese host del replicador. El proceso se replica para el VNI y Es posible que la lista de endpoints de túneles y los replicadores resultantes sean distintos para otros VNI. Con la replicación de encabezado (también conocida como replicación de cabecera), no hay ningún replicador. El host A simplemente crea una copia de cada marco BUM para cada endpoint de túnel que sabe que está en el VNI y lo envía. Si todos los endpoints de túneles del host están en la misma subred, la opción del modo de replicación no será distinta porque el comportamiento no será diferente. Si los endpoints de túneles del host están en diferentes subredes, la replicación del segundo nivel jerárquico ayudará a distribuir la carga entre varios hosts. El segundo nivel jerárquico es el modo predeterminado. 20 VMware, Inc.

21 Capítulo 2 Crear conmutadores lógicos y configurar la asociación de máquinas virtuales Crear un conmutador lógico Los conmutadores lógicos se asocian a una o varias máquinas virtuales en la red. Las máquinas virtuales conectadas a un conmutador lógico pueden comunicarse entre sí con los túneles entre los hipervisores. Prerequisitos Compruebe que esté configurada una zona de transporte. Consulte la Guía de instalación de NSX-T. Compruebe que los nodos de tejido estén conectados correctamente al agente de plano de gestión (MPA) de NSX-T y al plano de control local (LCP) de NSX-T. En la llamada de API GET el valor de state debe ser success. Consulte la Guía de instalación de NSX-T. Compruebe que los nodos de transporte se agregaron a la zona de transporte. Consulte la Guía de instalación de NSX-T. Compruebe que los hipervisores se agregaron al tejido de NSX-T y que las máquinas virtuales estén alojadas en dichos hipervisores. Familiarícese con los conceptos de replicación del marco BUM y la topología del conmutador lógico. Consulte Capítulo 2, Crear conmutadores lógicos y configurar la asociación de máquinas virtuales, página 19 y Información sobre los modos de replicación del marco BUM, página 20. Compruebe que el clúster de NSX Controller sea estable. 1 Desde su explorador, inicie sesión en un NSX Manager en 2 Seleccione Conmutación (Switching) > Conmutadores (Switches). 3 Haga clic en Agregar (Add). 4 Asigne un nombre al conmutador lógico. 5 Seleccione una zona de transporte para el conmutador lógico. Las máquinas virtuales asociadas a los conmutadores lógicos que se encuentren en la misma zona de transporte pueden comunicarse entre sí. 6 Seleccione un modo de replicación para el conmutador lógico. El modo de replicación (de encabezado o segundo nivel jerárquico) es necesario para los conmutadores lógicos de superposición, pero no para los conmutadores lógicos basados en VLAN. Modo de replicación Segundo nivel jerárquico Encabezado Descripción El replicador es un host que realiza una replicación del tráfico BUM a otros hosts con el mismo VNI. Cada host propone un endpoint de túnel de host en cada VNI para que sea el replicador. Este proceso se realiza para cada VNI. Los hosts crean una copia de cada marco BUM y la envían a cada endpoint de túnel que conoce de cada VNI. 7 (Opcional) Haga clic en la pestaña Perfiles de conmutación (Switching Profiles) y seleccione perfiles de conmutación. 8 Haga clic en Guardar (Save). En la interfaz de usuario de NSX Manager, el conmutador lógico nuevo es un vínculo en el que se puede hacer clic. VMware, Inc. 21

22 Qué hacer a continuación Asocie máquinas virtuales al conmutador lógico. Consulte Conectar una VM a un conmutador lógico, página 27. Puente de Capa 2 Cuando un conmutador lógico de NSX-T requiere una conexión de Capa 2 a un grupo de puertos respaldados por VLAN o necesita llegar a otro dispositivo, como una puerta de enlace situada fuera de una implementación de NSX-T, puede utilizar un puente de Capa 2 de NSX-T. Esto es especialmente útil en un escenario de migraciones, en el que necesita dividir una subred en las cargas de trabajo virtuales y físicas. Los conceptos de NSX-T que forman parte del puente de Capa 2 son clústeres de puente, endpoints de puente y nodos de puente. Un clúster de puente es un conjunto de alta disponibilidad (HA) de nodos de puente. Un nodo de puente es un nodo de transporte que realiza un puente. Cada conmutador lógico que se utiliza para realizar un puente entre la implementación física y una virtual tiene un ID de VLAN asociado. Un endpoint de puente identifica los atributos físicos del puente, como el ID de clúster de puente y el ID de VLAN asociado. En la versión de NSX-T, el puente de Capa 2 es proporcionado por hosts ESXi que sirven de nodos de puente. Un nodo de puente es un nodo de transporte de hosts ESXi que se agregó al clúster de puente. En el siguiente ejemplo, dos nodos de transporte de NSX-T forman parte de la misma zona de transporte de superposición. Esto permite que sus conmutadores de host de NSX-T (en ocasiones denominados vswitches de NSX-T, tal y como se muestra en la figura) se asocien al mismo conmutador lógico respaldado por puentes. Figura 2 2. Topología de puente Nodo de puente de NSX Nodo de transporte de NSX Otro nodo VM máquina virtual de aplicaciones VM máquina virtual de bases de datos Conmutador lógico respaldado por puentes (VLAN 150) Grupo de puertos de la máquina virtual (VLAN 150) conmutador host de NSX conmutador host de NSX vswitch/vds estándar vmnic1 vmnic1 vmnic1 El nodo de transporte de la izquierda pertenece a un clúster de puente y, por tanto, es un nodo de puente. Como el conmutador lógico está asociado a un clúster de puente, este se denomina conmutador lógico respaldado por puentes. Para que un conmutador lógico pueda estar respaldado por puentes, debe encontrarse en una zona de transporte de superposición y no en una zona de transporte VLAN. El nodo de transporte del centro no forma parte del clúster de puente. No es un nodo de transporte normal. Puede ser un host ESXi o KVM. En el diagrama, una máquina virtual de este nodo denominada "máquina virtual de aplicaciones" está asociada al conmutador lógico respaldado por puentes. 22 VMware, Inc.

23 Capítulo 2 Crear conmutadores lógicos y configurar la asociación de máquinas virtuales El nodo de la derecha no forma parte de la superposición de NSX-T. Puede ser cualquier hipervisor con una máquina virtual (tal y como se muestra en el diagrama) o un nodo de red física. Si el nodo que no es de NSX-T es un host ESXi, puede utilizar un vswitch estándar o un conmutador distribuido vsphere para la asociación de puertos. Un requisito es que el ID de VLAN asociado a la asociación de puertos debe coincidir con el ID de VLAN del conmutador lógico respaldado por puentes. Además, la comunicación se produce mediante la Capa 2, por lo que los dos dispositivos finales deben tener direcciones IP en la misma subred. Tal y como se indicó anteriormente, la finalidad de realizar el puente es permitir la comunicación de Capa 2 entre las dos máquinas virtuales. Cuando el tráfico se transmite entre las dos máquinas virtuales, el tráfico atraviesa el nodo de puente. Crear un clúster de puente Un clúster de puente es un conjunto de nodos de transporte que realizan un puente y participan en alta disponibilidad (HA). Solo hay un nodo de transporte activo a la vez. Tener un clúster de varios nodos de los nodos de puente de NSX-T garantiza que al menos un nodo de puente de NSX-T siempre esté disponible. Para crear un conmutador lógico respaldado por puentes, debe asociarlo a un clúster de puente. Por lo tanto, si solo tiene un nodo de puente, debe pertenecer a un clúster de puente para ser útil. Después de crear el clúster de puente, puede editarlo para añadir otros nodos de puente. Prerequisitos Cree al menos un nodo de transporte de NSX-T para utilizarlo como nodo de puente. El nodo de transporte utilizado como nodo de puente debe ser un host ESXi. KVM no es compatible con los nodos de puente. Le recomendamos que los nodos de puente no tengan ninguna máquina virtual alojada. Un nodo de transporte se puede agregar a un único clúster de puente. No puede agregar el mismo nodo de transporte a varios clústeres de puente. 1 En la interfaz de usuario de NSX Manager, acceda a Tejido (Fabric) > Configuración (Configuration) > Puentes (Bridges). 2 Asigne un nombre al clúster de puente. 3 Seleccione una zona de transporte para el clúster de puente. El tipo de la zona de transporte debe ser de superposición, no VLAN. 4 En la columna Disponibles (Available), seleccione los nodos de transporte y haga clic en la flecha derecha para moverlos a la columna Seleccionados (Selected). Qué hacer a continuación Ahora puede asociar un conmutador lógico al clúster de puente. Crear un conmutador lógico respaldado por puentes de Capa 2 Cuando tenga máquinas virtuales conectadas a la superposición de NSX-T, puede configurarlas para que tengan conectividad de Capa 2 con otros dispositivos u otras máquinas virtuales que estén fuera de la implementación de NSX-T. En este caso, puede utilizar un conmutador lógico respaldado por puentes. Para ver una topología de ejemplo, consulte Figura 2-2. VMware, Inc. 23

24 Prerequisitos Al menos un host ESXi como nodo de puente. Un nodo de puente es un nodo de transporte ESXi que solo realiza un puente. Este nodo de transporte se debe agregar a un clúster de puente. Consulte Crear un clúster de puente, página 23. Al menos un host ESXi o KVM como nodo de transporte regular. Este nodo tiene máquinas virtuales alojadas que necesitan conectarse con dispositivos fuera de una implementación de NSX-T. Una máquina virtual u otro dispositivo final fuera de la implementación de NSX-T. Este dispositivo final se debe asociar a un puerto VLAN que coincida con el ID de VLAN del conmutador lógico respaldado por puentes. Un conmutador lógico en una zona de transporte de superposición como el conmutador lógico respaldado por puentes. 1 Desde un explorador, inicie sesión en un NSX Manager en 2 Seleccione Conmutación (Switching) > Conmutadores (Switches). 3 En la lista de conmutadores, seleccione un conmutador de superposición (tipo de tráfico: de superposición). 4 En la página de configuración del conmutador, seleccione Relacionado (Related) > Clústeres de puente (Bridge Clusters). 5 Haga clic en ASOCIAR (ATTACH), seleccione un clúster de puente e introduzca un ID de VLAN. Por ejemplo: 6 Conecte las máquinas virtuales al conmutador lógico (si aún no están conectadas). Las máquinas virtuales deben encontrarse en nodos de transporte de la misma zona de transporte que el clúster de puente. Puede probar la funcionalidad del puente. Para ello, envíe un ping desde la máquina virtual interna de NSX-Ta un nodo externo a NSX-T. Por ejemplo, en Figura 2-2, la máquina virtual de aplicaciones del nodo de transporte de NSX-T debe poder hacer ping a la máquina virtual de bases de datos del nodo externo y viceversa. Puede acceder a Conmutación (Switching) > Conmutadores (Switches) > Supervisar (Monitor) para supervisar el tráfico del conmutador de puente. 24 VMware, Inc.

25 Capítulo 2 Crear conmutadores lógicos y configurar la asociación de máquinas virtuales Puede consultar el tráfico del puente con la llamada de API GET { } "tx_packets": { "total": , "dropped": 0, "multicast_broadcast": 0 }, "rx_bytes": { "total": 22164, "multicast_broadcast": 0 }, "tx_bytes": { "total": , "multicast_broadcast": 0 }, "rx_packets": { "total": 230, "dropped": 0, "multicast_broadcast": 0 }, "last_update_timestamp": , "endpoint_id": "ba5ba59d-22f1-4a02-b6a0-18ef0e37ef31" Crear un conmutador lógico VLAN para el vínculo superior de NSX Edge Los vínculos de carga de Edge pasan por los conmutadores lógicos VLAN. Al crear un conmutador lógico VLAN, es importante elegir una topología en particular para el diseño. Por ejemplo, la siguiente topología sencilla muestra un único conmutador lógico VLAN dentro de una zona de transporte VLAN. El conmutador lógico VLAN tiene el ID de VLAN 100. Esto coincide con el ID de VLAN del puerto TOR conectado al puerto de host de hipervisor que se utiliza para el vínculo superior VLAN de Edge. VMware, Inc. 25