VMware NSX Controller

Publicado el 07 enero 2015 por Pipearaque

Hola que tal

Buen día

En Post anteriores se han visto conceptos sobre NSX, el plano de control, datos y administración. También se ha revisado acerca de VMware NSX Manager y cómo se instala. Continuando con esta seria de Posts acerca de NSX es tiempo de hablar acerca de NSX Controller, el cual es otra máquina virtual que se estaría encargando de varias funciones, como las tablas de ARP, enrutamiento, MAC y VTEP.

Recordar de la Parte 2 de esta serie de Post que NSX cuenta con tres planos. En el plano de control se puede hallar a NSX Controller.

NSX Controller es el encargado de almacenar cuatro tablas:

  • Tabla ARP
  • Tabla MAC
  • Tabla VTEP (Para el funcionamiento de VXLAN)
  • Tabla de enrutamiento

También es el encargado de:

1. NSX Controller cuenta con dos Roles utilizados por las cargas de trabajo. El primero es el rol de "Distribuir las VXLAN" y el segundo el de "Información de red de enrutamiento lógico". Al primer Rol se le puede resumir como "VXLAN" y al segundo "Logical Router", aunque ciertamente el primer rol es más conocido como "Logical Switch".

Es interesante saber que estos dos Roles son distribuidos a través del " Clúster ". NSX Controller puede ser desplegado como una única máquina virtual, pero también pueden ser desplegadas varias instancias, formando así un Clúster. La idea de un clúster permite escalabilidad y disponibilidad.

Nota: VMware recomienda que el clúster sea formado por tres instancias o también conocido como Nodos.

Nota: Nodo es lo mismo a instancia como a máquina virtual de NSX Controller.

Cada rol necesita un maestro, por tanto un proceso de elección se lleva a cabo para elegirlos. VMware se basa en un algoritmo "Paxos" para llegar a un consenso y elegir un maestro por cada rol. Es decir que habrá un master para el Rol de VXLAN y un master para el de Logical Router. Podría suceder que un nodo tenga ambos maestros, es decir, que una máquina virtual de NSX Controller posea tanto el rol de Logical Switch como el de logical router o podría suceder también que en un nodo cuente con el rol de Logical Switch y otro nodo el de logical router.

En la figura 2 notar que se tiene un clúster con tres nodos, A,B, y C. Paxos ha llegado a un consenso y ha decidido que el nodo B sea el maestro tanto del rol de Logical Switch como el de Logical Router. Una función vital del maestro es la de " repartir de la carga de trabajo de forma uniforme " entre los nodos. Llámese a carga de trabajo tanto Logical Switch como a Logical Router. Ahora, si por ejemplo el Nodo B falla, el clúster inicia un nuevo proceso de elección entre A y C. El nuevo maestro de cada rol debe reasignar las cargas de trabajo que estaba ejecutando B y debe hacerlo entre A y C.

NSX Controller debe en conclusión distribuir las cargas de trabajo (Logical Switch y Logical Router) entre todos los nodos, pero también debe redistribuir las cargas cuando falla un nodo o cuando se ingresa un nuevo nodo al clúster y todo esto de forma transparente para las aplicaciones. VMware ideó un método para garantizar esta distribución y redistribución. La solución fue el " Slicing " o rebanadas.

En el Slicing:

  • Por cada rol se crea un número de rebanadas: NSX Controller primero debe ser conciente de cuántos Logical Switch y Logical Routers existen y cuál es el número de nodos de NSX Contoller. Con base en esto, divide los LS y LR entre todos los nodos del clúster.
  • El maestro de LS "Logical Switch" divide los LS en rebanadas y los asigna a los distintos nodos.
  • El maestro de LR "Logical Router" divide los LR en rebanas y los asigna a los distintos nodos.
  • Por último, los objetos son asignados a los slices.

Notar que el maestro también se estaría encargando de realizar esta tarea. Suponer en un ejemplo que se han creado 9 slices por cada rol en un clúster con tres nodos.

Suponer también que los nueve primeros en color azul son slices para los LS y los 9 restantes para los LR.

A continuación se definen los objetos que serán rebanados:

Por último los objetos son asignados a los slices:

Cómo serian repartidos estos slices a cada uno de esos tres nodos? Una idea podría darla la siguiente figura:

2. NSX Controller también se encarga de recibir información de los ESXi y el NSX Logical Router Virtual Machine acerca de lo que han aprendido a nivel de red, como tablas VTEP en el caso de los ESXi y tablas de enrutamiento para el caso de NSX Logical Router Virtual Machine. Mediante el agente de UWA los ESXi pueden tener comuinicación con NSX Controller.

3. Podría remover el enrutamiento de multicast y la necesidad de configurar el protocolo PIM en la red física. De esto se hablará con más detalle en futuros posts.

4. Podría remover el tráfico de broadcast. Si por ejemplo una máquina virtual envía un ARP request en busca de la dirección MAC de otra máquina virtual, este broadcast es capturado por el ESXi y por medio de UWA enviado al NSX Controller. NSX Controller busca la dirección MAC para esa dirección IP en su tabla ARP y si tiene una entrada para esta, devuelve la dirección MAC al ESXi. En este caso se suprime un broadcast que no estaría viajando por la insfraestructura, ahorrando ancho de banda.

5. NSX Controller emplea certificados autogenerados por NSX Manager para la comunicación de forma segura con otros componentes de la solución.

Primero, NSX Manager crea certificados autogenerados. A continuación estos son almacenados en su base de datos. Cuando un NSX Controller es desplegado, NSX Manager le da el certificado. A continuación y empleando el Bus de mensajes, NSX Manager instala los VIBs en los ESXi. La comunicación entre los ESXi y NSX Controller se da a través de UWA. Finalmente la interacción entre NSX Manager y NSX Controller y NSX Controller con ESXi se da a través de SSL.

Cómo desplegar NSX Controller

Para desplegar NSX Controller no es necesario descargar un OVA u OVF. Recordar que NSX Manager es el encargado de facilitarnos esta tarea.

NSX Controller requiere:

  • NSX Manager previamnete instalado y lincado con vCenter Server.
  • 4GB de RAM por cada nodo.
  • 20 GB de disco por nodo.
  • 4 vCPUs por nodo.

Paso 1. Ir a "Network and Security" y despúes clic en "Installation".

Paso 2. A la derecha, clic en "+" debajo de NSX Controller Nodes.

Paso 3. Especificar:

  • NSX Manager: La instancia de NSX Manager en la cual este NSX Controller será registrado.
  • Datacenter: En qué Datacenter lógico será ubicada esta máquina virtual.
  • Cluster/Resource Pool: En este punto se debe definir en qué clúster o pool de recursos se destinará esta máquina virtual.
  • Datastore: Elegir el datastore en dónde se ubicará la máquina virtual.
  • Host: Definir el ESXi en donde correrá la máquina virtual.
  • Coonected to: Especificar el grupo de puertos de máquina virtual a dónde se conectará NSX Controller. Es importante que esta red pueda alcanzar a NSX Manager. Generalmente se conecta a la red de administración.
  • Password: La clave para ingresar por CLI. Es importante que esta misma clave sea especificada en cada nodo del clúster.

En IP Pool se crea un pool de IPs para que cada Nodo de NSX Controller pueda contar con una dirección IP. A medida que se vayan desplegando nuevos nodos, NSX Manager destina una IP a cada uno de éstos de este Pool. En IP Pool seleccionar la opción "New IP Pool":

Nota: Si no está seguro acerca de qué información especificar en la figura 10, consultar con el administrador de la red. Lo que si es cierto es que este Pool debe tener información (IPs) acorde con la red escogida en "Connected to" de la figura 9.

Ya está todo listo, finalmente dar clic en OK para dar inicio al despliegue del primer NSX Controller:

Paso 4. Monitorear el estado del despliegue. En status verifcar el estado del deployment de esta máquina virtual. Se verá como Deploying mientres esté creando y configurando la VM.

Nota: Este proceso puede tomar varios minutos. Se está copiando una máquina virtual y después se encenderá y configurará automáticamente por primera vez.

Tras el despliegue, encendido y configuración inicial, la máquina virtual de NSX Controller debería verse de la siguiente forma:

Verificación de NSX Controller

Con la ayuda de un cliente SSH ingresar a NSX Controller. Según la figura 13 la IP de esta primera instancia de NSX Controller es 192.168.1.180. El usuario es admin y la contraseña es la especificada en la figura 9.

show control-cluster status

Una vez se encuentre en el NSX Controller vía SSH, ingresar el siguiente comando:

show control-cluster status
  • Join status: Muestra el estado actual de unión al clúster de este NSX Controller. El resultado del comando muestra que se encuentra en "Join Complete" y desde cuándo (01/07 16:34:28).
  • Majority status: Muestra si el controlador se encuentra activo. El resultado "Connected to cluster majority" significa que este nodo se encuentra activo.
  • Restart status: Muetra si este nodo puede ser reiniciado de forma segura.
  • Cluster ID: Aquí se puede encontrar el identificador del clúster, un número de 32 dígitos hexadecimales que identifican un clúster y es automáticamente generado durante el despliegue del primer nodo.
  • Node UUID: Otro identificador de 32 dígitos hexadecimales que identifican un nodo de forma única. Este también es generado automáticamente durante el despliegue de este primer nodo.
  • Role: Permite ver los distintos Roles, estado de configuración y estado activo.

De lo anterior se puede decir que:

  • Hay 5 roles habilitados (enabled) y activados (actived).
  • Este controlador puede ser reiniciado de forma segura (safely restarted). El comando para reiniciar un NSX Controller es restart controller.
  • Este controlador está atado/unido a un clúster identificado con el ID 13cc8298-7071-44bf-968e-5f2027b03031. Todos los demas nodos que sean desplegados deberían ser atados al mismo ID de clúster.
show control-cluster startup-nodes

Para verificar las direcciones IP de los nodos activos en el lúster, dar el siguiente comando:

show control-cluster startup-nodes

Hasta ahora se ha desplegado solo un NSX Controller. El resultado del comando de la figura 15 refleja esa realidad.

show control-cluster roles

Para ver un reporte más detallado acerca de los roles, dar el siguiente comando:

show control-cluster roles

De la figuras 16 puede notar que etse nodo es el maestro de todos los 5 roles. Es normal ver api_provider como Not Configured.

show control-cluster connections

Otro comando útil es "connections", el cual permite ver qué conexiones tiene el contralador actualmente y qué tipos de conexiones emplea.

show control-cluster connections

En la figura 17 se puede apreciar que:
- Hay 4 roles que tienen componentes que activamente están escuchando en un puerto de red.
- Existen 7 puertos usados para las comunicaciones de estos 4 roles. Los puertos son el 443, 2878, 2888, 3888, 6632, 6633 y 7777.

Nota: Para una lista más detallada de comandos, visitar:

https://pubs.vmware.com/NSX-6/topic/com.vmware.ICbase/PDF/nsx_60_cli.pdf

A continuación se recomienda desplegar dos nodos más empleando los mismos 4 pasos descritos anteriormente. VMware NSX Manager automáticamente ata los nodos al clúster, elige los maestros, divide las cargas de trabajo y asigna los slices a cada nodo.

En el siguiente Post se estará hablando acerca de las VXLAN.

Un saludo!!!

Parte 1: Introducción a VMware NSX. Conceptos iniciales
Parte 2: VMware NSX: Planos
Parte 3: Instalación y configuración de NSX Manager 6.X 
Parte 4: VMware NSX Controller

Soy Andrés Felipe Araque D. Ingeniero dse Telecomunicaciones y apasionado por la Virtualización y VMware.


Tags: VMware NSX NSX Controller