SDN

Forzar Dinámicamente la Selección de Red en vRA 7

diciembre 25, 2016 - - 0 Comentarios

Estoy trabajando en el diseño e implementación de un gran proyecto de Nube Empresarial donde el multi-tenancy es vital para el éxito del proyecto. Cuando se trabaja en un proyecto de nube privada, una infraestructura compartida común es el típico enfoque para hacer viable el caso de negocio. Normalmente, la segregación física se basa principalmente en los requisitos de seguridad y no más en quién compró el hardware. La segregación multi-tenancy se mueve hasta el nivel lógico, convirtiendo la infraestructura en una commodity compartida.

Desde el punto de vista de red, la segregación lógica es soportada por el uso de protocolos como VLAN, PVLAN, GRE, VXLAN y otros. Cada vez que una máquina virtual se aprovisiona a través de vRealize Automation, requiere el acceso a la red para comunicarse con otras cargas de trabajo.

En el caso de user vSphere como plataforma en vRA, las tarjetas de red de la máquina virtual se conectarán a uno de los PortGroups disponibles dentro de la reserva en la que se está aprovisionando. El primer nivel de segregación lógica en vRA es el objeto business group, donde puede tener una o más reservas (el segundo nivel). Si el usuario no es miembro del business group con las reservas enlazadas, no puede aprovisionar ninguna máquina virtual en esta.

Fuente: VMware.com

La reserva incluye qué red o redes el usuario puede conectar tu máquina virtual, pero estas redes no se publican dinámicamente en vRA. El enfoque sencillo es la creación de una custom property denominada “VirtualMachine.NetworkN.Name”, donde N es el índice de la NIC su máquina virtual (comenzando en 0). Durante la creación de esta custom property, tendrás la oportunidad de crear una lista estática o dinámica utilizando cualquier script action que tengas disponible en tu plataforma vRealize Orchestrator que vRA consume.

El reto principal de una lista estática es el mantenimiento de la lista de redes que se muestra al usuario, también esta lista se comparte para todos los usuarios. Desde el punto de vista de seguridad esto no es un problema, ya que la red debe estar habilitada en la reserva del usuario, si no está habilitada, el usuario recibirá un error de que la máquina virtual no se puede aprovisionar porque la reserva no tiene derecho a consumir la red. Si bien esto no implica una riesgo en la seguridad, exponer toda la lista de redes no es el mejor enfoque ya que alguna información confidencial puede estar disponible en el nombre de la red. Por esta razón, crear una lista de redes dinámicas en tiempo real basada en el business group del usuario y la reserva vinculada a esta, parece ser el mejor enfoque que he encontrado hasta ahora. Cuando se trata de un entorno multi-tenancy, los requisitos de seguridad son siempre la pieza más importante del diseño.

Para lograrlo, vamos a aprovechar una script action de vRO disponible desde la versión 7.1 llamada “getApplicableNetworks” (más información). Vamos a ajustar un poco esta script action ya que como viene de forma predeterminada muestra todas las redes permitidas para el usuario independientemente de qué business group está solicitando la máquina virtual. Para filtrar las redes basadas en el business group, crearemos una custom property en el business group con el valor igual al nombre del business group. La razón para crear esta custom property en el business group se debe a que esta no se expone durante el asistente de despliegue de una máquina virtual, por esta razón vRO no puede obtener el valor utilizando las propiedades ASD. Para solucionar este problema, la script action de vRO incluirá una string input que se completa con el valor de la custom property del business group.

Configuración vRO

Comencemos con la configuración de nuestra lista de redes dinámicas forzadas:

  • Copia la script action de vRO incluida en una nueva ubicación. Con este paso nos aseguramos en futuras versiones del plug-in vRA que nada se rompe. Además, la copia será la script action a modificar e incluir el filtro para recuperar solamente las reservas del business group que el solicitante tiene derecho.

Copiar la script action de vRO “getApplicableNetworks”

En vRealize Orchestrator versión 7.2, VMware ha cambiado el código de la script action y la dependencia anterior en 7.1 con la script action llamada “getReservationsForUser”, ha cambiado a “getReservationsForUserAndComponent”. El problema es que la script action “getApplicableNetworks” no funciona en 7.2 ya que VMware se ha olvidado de actualizar el script para incluir como entrada algunos valores que la dependencia “getReservationsForUserAndComponent” requiere.

Si estás utilizando vRO 7.1, puedes omitir este paso.

  • Duplicar la script action actual “getReservationsForUserAndComponent”

Duplicar la script action “getReservationsForUserAndComponent”

  • Degradar a la versión 1.0. El nombre de la script action cambiará a “getReservationsForUser”.

Degradar la script action copiada a version 1.0 (getReservationsForUser)

  • Edita la script action copiada y añade una string input llamada “subtenant”

Añade una string input

  • Ve a la pestaña de script y actualiza la cuarta línea con la carpeta de la script action y el nombre que has duplicado y degradado anteriormente.

var reservations = System.getModule(“com.joseluisgomez.vra.reservations“).getReservationsForUser(user, tenant, host);

  • Entre la 4ª línea (var reservations) y la 5ª línea (var applicableNetworks), agrega la línea siguiente para encontrar el business group con el valor de la custom property de vRA.

var subtenants = vCACCAFEEntitiesFinder.findSubtenants(host, subtenant);

Código actualizado (líneas 4 y 5)

  • El último paso con la script action es agregar un condicional. Se buscará el nombre del business group (subtenant name) que coincida con la string input completada por vRA en todas las reservas recopiladas. Añade la siguiente línea después de “for each“, también puedes agregar una tabulación adicional al código actual para alinearlo correctamente. Además, se requiere una llave de cierre “}” adicional para cerrar el condicional. El código rojo es el nuevo a agregar.

for each(var res in reservations) {
if(res.getSubTenantId() == subtenants[0].id){
var extensionData = res.getExtensionData();
if(extensionData) {
var networks = extensionData.get(“reservationNetworks”);
if(networks) {
for each(var network in networks.getValue()) {
var path = network.getValue().get(“networkPath”);
applicableNetworks.put(path.label, path.label);
}
}
}
}
}
return applicableNetworks;

Condicional a agregar

Hemos terminado con vRO. Ahora es el momento de utilizar esta script action en vRA y nuestro blueprint.

Configuración vRA

  • Crea una custom property para el business group con tu nombre preferido. En mi caso, he utilizado el siguiente:
    • Nombre de la custom property. NGDC.Software.VMware.vRA.Subtenant.Name
    • Valor de la custom property. El nombre del business group (ej .: Tenant_Environment_Service_Index)

Custom property con el nombre del business group como valor

  • Crea una definición de custom property llamada “VirtualMachine.Network0.Name” con la siguiente configuración:
    • Nombre: VirtualMachine.Network0.Name
    • Etiqueta: Select a network
    • Visibilidad: All tenants
    • Orden de muestra: 1
    • Tipo de dato: string
    • Requerido: yes
    • Mostrar como: Dropdown
    • Valores: External values
    • Script action: Haz clic en el botón de cambio y selecciona la script action llamada getApplicableNetworksBySubtenant que hemos creado en los pasos anteriores.
    • Input parameters: Marca la casilla bind y como valor escribe la custom property del business group “NGDC.Software.VMware.vRA.Subtenant.Name“. Nota: La custom property del business group no es descubierta automáticamente si haces clic en la lista desplegable. Debes escribir la custom property.

  • El último paso es agregar en el blueprint la custom property que has creado en el paso anterior. El blueprint no requiere ningún objeto de red, sólo el objeto de máquina virtual de vSphere y agregar a este una NIC virtual. La NIC0 virtual debe tener como custom property lo siguiente:
    • Nombre: VirtualMachine.Network0.Name
    • Valor: Vacío
    • Encriptado: No
    • Sobrescribible: Sí
    • Mostrar en la solicitud: Sí

Blueprint custom property

Resultado

La mejor manera de probar nuestra custom property es crear dos business groups con una reserva cada uno, hacer que el mismo usuario sea el administrador del grupo y crear dos entitlements de catálogo de servicios, uno para cada business group.

La siguiente captura de pantalla muestra el primer business group (Tenant1-Global). Como puedes ver, este business group tiene dos redes. Un dvPortGroup estático (Main) y un NSX VXLAN dvPortGroup (5008-Photon-Hosts)

Lista de red dinámicamente forzada para el business group Tenant1-Global

La siguiente captura de pantalla muestra las redes del segundo business group (CORP_PROD_APP1_01). Como puedes ver, el business group también tiene dos redes, pero diferentes. Dos NSX VXLAN dvPortGroups (5005-NTXCE-Mgmt y 5004-NTXCE-VMs)

Lista de red dinámicamente forzada para el business group CORP_PROD_APP1_01

Conclusión

Espero que lo hayas encontrado útil y pueda ayudarte con implementaciones nuevas y actuales. Este es el mejor enfoque que he encontrado hasta ahora para un diseño multy-tenancy basado en business groups. Este enfoque también funciona si el multi-tenancy se realiza utilizando la funcionalidad de tenants en vRA.

Si te ha gustado, no dudes en compartirlo con tus contactos.

ESXi 6.0.x con NIC Mellanox 10/40 Gb y controlador nmlx4_en no registra las respuestas ARP de Cisco ACI

agosto 8, 2016 - - 0 Comentarios

Actualmente estoy trabajando en un proyecto de diseño y despliegue de una plataforma de nube privada basada en VMware vRealize y Cisco ACI como solución SDN.

Durante casi dos días no fuimos capaces de hacer ping desde el host ESXi (Mellanox) a su puerta de enlace predeterminada proporcionada por una subred dentro de un “Bridge Domain” (BD) en Cisco ACI. Sin embargo, un equipo físico con Windows (Broadcom) en el mismo EPG que los hosts ESXi, era capaz de hacer ping a la misma puerta de enlace predeterminada. Este comportamiento era extraño, ya que el ping entre miembros del mismo EPG funcionaba bien como entre los servidores ESXi, o también con la maquina física Windows.

.

ACI

El primer pensamiento que viene a tu cabeza es que se está pasando algún ajuste en la configuración de ACI. ¿Por qué?, porque estamos hablando de soluciones SDN, la filosofía y la lógica detrás de esta cambia radicalmente. Ahora debes saber acerca de multi-tenancy, bridge domains, endpoint groups, contracts y así sucesivamente, por lo que es muy fácil pasar por alto algo durante la configuración.

Entorno

  • Servidor ESXi.
    • HP DL360 Gen9
    • Mellanox 10/40 Gb – Familia MT27520 (afectada con el bug ARP)
      • Información del controlador NIC:
        • Controlador: nmlx4_en
        • Versión de firmware: 2.35.5100
        • Versión: 3.1.0.0
  • Cisco ACI v ersión 2.0(1n)
  • VMware ESXi 6.0.x
    • Update 1
    • Update 2
    • ISOs de VMware y HPE OEM probadas

Síntoma

  • ESXi no llega a su puerta de enlace predeterminada (IP del ACI BD)
  • Cualquier tráfico encaminado a través de la puerta de enlace no llega a su destino
  • ACI responde la petición ARP de ESXi pero el último no la registra

Tcpdump-uw en ESXi no mostraba las respuestas de ACI. Cuando lanzamos Wireshark en la máquina física, pudimos ver a ACI responder las solicitudes ARP de ESXi.

capture2

Resolución

Después de instalar la última versión del controlador Mellanox disponible en el sitio web de VMware, el servidor ESXi comenzó a ver las respuestas ARP. Estas respuestas fueron registradas y la comunicación desde ESXi a la puerta de enlace predeterminada y otras redes funcionaron correctamente.

Comandos de solución de problemas

Los siguientes comandos se utilizaron para llevar a cabo la solución del problema desde el lado del servidor ESXi.

# Mostrar información del adaptador de red físico (contadores y controlador)
/usr/lib/vmware/vm-support/bin/nicinfo.sh

# Mostrar tabla ARP
esxcli network ip neighbor list

# Mostrar las interfaces de red VMkernel
esxcli network ip interface list

# Mostrar los switches virtuales
esxcli network vswitch standard list

# Verificar la conexión a un puerto
nc -z IP Port

# Capturar tráfico
tcpdump-uw -vv