Diseñando los servicios de Red de vSphere

En este tercer Post de la serie de diseño de vSphere analizaremos el diseño del networking en una infraestructura de VMware vSphere con sus
conceptos, consideraciones, requerimientos, ejemplos y buenas prácticas.

Comenzaremos repasando los principales conceptos.

Conceptos de Red de vSphere

Los servicios de red en una infraestructura de vSphere están compuestos por los siguientes componentes:
-VMNic: interface de red físicos del Host

-vSwitch: objeto lógico al que vinculamos vmnics y en el que creamos Port Groups. Existen dos tipos de Port Groups, Virtual Machine Port
Group y VMkernel Port Group.

Existen además de dos clases de vSwitch, los Standard y los Distribuidos.

-Virtual Machine Port Group: conecta las Máquinas Virtuales a la Red

-VMkernel Port Group: configura los servicios de red necesarios en un Host como la Red de Management, el acceso al Almacenamiento y la
Red de vMotion

-Uplink: nombre que se le da a la asociación entre un vmnic y un vSwitch

Antes de comenzar con nuestro diseño debemos tener muy claros los objetivos, requerimientos, limitaciones, supuestos y alcances pero todo
esto merece un Post exclusivo y será el que cierre la serie de diseño.

Continuaremos realizando unas breves preguntas pero muy específicas que nos ayudarán a aclarar dudas respecto a nuestro diseño.

Deberíamos comenzar con la siguiente pregunta:

Utilizaremos Switches Virtuales Standard o Switches Virtuales Distribuidos?

Como toda respuesta de buen consultor que se precie la respuesta sería: depende ;)

Necesitamos utilizar Network IO Control? Port Mirroring? NetFlow? Cisco Nexus 1000V? PVLANs? Tenemos un número de Host considerable?
Disponemos de la licencia Enterprise Plus?

Muchas preguntas verdad? pues si a cualquiera de ellas hemos respondido que sí y nuestro presupuesto nos permite adquirir licenciamiento
Enterprise Plus entonces utilizaremos Switches Virtuales Distribuidos. En caso contrario utilizaremos los Standard.
Pregunta: Cuántos Port Groups debemos configurar?

Veamos que Port Groups tenemos disponibles y cuáles podríamos necesitar.

Management: es la puerta de entrada a la administración del Host por lo que no solo debemos configurarla sino que además también
deberíamos aplicarle redundancia y posiblemente aislarlo por cuestiones de seguridad.

El Port Group de Management también es utilizado por la red de HA como vía de comunicación entre los Hosts por lo que al aplicarle alta
disponibilidad cumplimos con una recomendación más que importante de HA.

Virtual Machine Port Group: aquí la pregunta no es si debemos utilizarlo sino mas bien cuántos VM Port Groups necesitamos. Posiblemente
necesitemos aislar en diferentes subredes distintos grupos de Máquinas Virtuales y eso podemos hacerlo configurando múltiples VM Port
Groups y posiblemente aislando el tráfico aplicando vLans.

Almacenamiento: si para acceder al Almacenamiento, o parte de él, necesitamos utilizar una red de cobre entonces tendremos que configurar
Port Groups de VMkernel para ese acceso tan importante. Las configuraciones de acceso iSCSI y NFS son bastante diferentes pero a ambas
deberíamos dotarlas tanto de alta disponibilidad como de ancho de banda suficiente. vMotion: para migrar nuestras VMs de Host a Host y poder
utilizar DRS necesitamos un Port Group de VMkernel para vMotion. Para optimizar la red de vMotion podemos utilizar múltiples Port Groups
para que sean utilizados de forma simultánea.

FT: en el supuesto caso que utilicemos FT para dar tolerancia a fallos a VMs críticas necesitaremos una red de FT. Esta red tendrá que ser de al
menos 1Gbps y soportará hasta un máximo de 4 VMs protegidas con FT como máximo por cada Host.

VSAN: este Port Group se utiliza de forma exclusiva para la red de Almacenamiento distribuido. Debe estar completamente aislada. Solo
disponible a partir de vSphere 5.5.

Una vez que hemos repasado los diferentes Port Groups hemos visto que en algunos casos tal vez deberíamos considerar utilizar al menos dos
Port Groups de una misma clase.

Los ejemplos más claros son iSCSI y VM PG. En los casos de Management y NFS nos bastaría con aplicar redundancia a nivel de vmnic.

Llegados a este punto deberíamos continuar con la siguiente pregunta:

Cuántas vmnic necesito por cada Host?

Naturalmente que la respuesta debería estar relacionada con el número de Port Groups, la Alta Disponibilidad que pretendemos y la
segmentación física que busquemos.

Que duda cabe que necesitaremos agrupar o combinar determinados Port Groups para que compartan el medio físico, pero debemos definir en
qué casos los separaremos física y lógicamente así como también cuándo aislar Port Groups utilizando vLans.

Separar Port Groups físicamente requerirá un mayor número de recursos como vmnics, bocas de switch físico y cableado.

Utilizar vLans nos permitirá reducir esos recursos pero compartiremos el caudal disponible sumando algo de gestión en la configuración de los
switches físico. Personalmente me gusta mas esta última opción ya que nos da mucho juego.

Ahora que ya sabemos los tipos y el número de Port Group que necesitamos y también conocemos el número de vmnics en nuestros Hosts la
siguiente pregunta será:

Cuántos vSwitches debemos configurar?

La respuesta es simple. El menor número de vSwitches que nos sea posible.

Aquí es donde aplicamos la frase de Mies van der Rohe “menos es mas” ;)

Si hacermos uso de esa recomendación tendremos un mayor número de vmnics para aplicar redundancia e incrementar el ancho de banda.

Antes de continuar es importante recordar la regla que dice que un vSwitch puede tener una o múltiples vmnics, pero que una misma vmnic sólo
puede tener un uplink a un único vSwitch a la vez.

Entonces ahora sí, veamos dos ejemplos.

En el primer ejemplo contemplamos varios vSwitches con múltiples vmnics.

Si bien en todos los casos disponemos de redundancia también podemos apreciar que necesitamos un buen número de vmnics en los Hosts, el
mismo número de bocas disponible en los switches físicos y naturalmente más recursos y más gestión. A mayor número de dispositivos físicos
involucrados mayor será también la posibilidad de problemas.
Con este segundo ejemplo podemos ver un único vSwitch en el que integramos todos los vmnics y PortGroups. Esta configuración nos dá
opción de incrementar el ancho de banda con agregados de enlaces haciendo crecer la disponibilidad con un mayor número de vmnics, utilizar
un menor número de recursos en los Hosts (menos vmnics) y también en los switches físicos.

El tráfico podemos separarlo en vLans y jugar con un mayor número de opciones.

Aplicando mejores prácticas en los servicios de red de Sphere

-Combinar Onboard NICs y Add-in NICs

Para los PortGroups que requieran de alta disponibilidad intentar siempre aprovisionar alta disponibilidad combinando vmnics integradas en
placa base con vmnics de slots PCIe.

-Red de Gestión
Una buena práctica a nivel de seguridad y que también es realmente útil es aislar la red de Gestión de los Hosts (Management) y asociar a esa
misma red los interfaces de gestión de consola de los Hosts (iLO, iDRAC, CMC, Etc). También podemos conectar a esa red, o vLan, los
interfaces de gestión de los sistemas de Almacenamiento y hasta los interfaces de gestión de los Switches y Routers.

De esta forma podemos controlar de forma perimetral nuestra red de gestión de forma segura y centralizada.

-Separar la red de iSCSI con la de Producción (VMs)

No solamente debemos aislar la red iSCSI de la del tráfico de maquinas virtuales sino que además también deberíamos separarla de la red de
acceso al almacenamiento NFS.

En el peor de los casos que no dispongamos de recursos para utilizar vmnics diferentes para iSCSI y NFS podemos separar el tráfico utilizando
vLans aunque debemos tener en cuenta que compartiríamos el caudal disponible para las dos redes.

-Utilizar DNS siempre que sea posible

Tanto para la red de Management, al agregar los Hosts al vCenter, la red de iSCSI y la red de NFS consideremos seriamente utilizar nombres en
vez de direcciones IPs.

Los certificados digitales autoemitidos se generan en base al nombre de los servicios (vCenter, Host) y en caso de un cambio de
direccionamiento, al gestionar los servicios por nombre, solamente necesitaríamos una actualización de los registros DNS de tipo A y PTR.

-Deshabilitar los cambios de MAC

Por defecto en los vSwitches y Port Groups se permiten cambios en las MAC de las virtual nics. Salvo contados casos como Clusters, IDS y
similares, no tendríamos que permitir el cambio de direcciones MAC.

-Habilitar Jumbo Frames en las redes de Almacenamiento

Si disponemos de vmnics exclusivas para el acceso al almacenamiento iSCSI y/o NFS una muy buena opción sería el uso de Jumbo Frames.
De esta forma incrementamos el tamaño del paquete que viaja de la red desde 1500 a 9000 pudiendo conseguir picos de mejora de hasta un
20%.
Es muy importante tener en cuenta que la aplicación del Jumbo Frame debe ser de extremo a extremo, es decir desde la cabina, pasando por
los switches físicos, vSwitch y Port Group.

Mejores prácticas según el Port Group

Management: Es más importante la disponibilidad que el ancho de banda. La red de HA utiliza este Port Group para su red de Hosts por lo que
deberíamos redundarla con 1 vSwitch+2 Port Groups+2 vmnics o bien 2 vSwitch de 1 Port Group y 1 vmnic.

Sería recomendable utilizar 1 vSwitch con 2 vmnics de forma que podamos combinarlo con la red de vMotion.

vSwitch recomendado para el Port Group: Standard

VM Port Group: Interesa tanto la alta disponibilidad como también el rendimiento. De esto último dependerá el número y tipo de maquinas
virtuales conectadas al Port Group.

Suele ser una buena práctica utilizar vLans con estos Port Groups para compartir los vmnics y separar las redes.

En vSwitches estándar la mejor política de balanceo es IP Hash pero debemos configurar un agregado de enlaces a nivel de switches físicos.

Podemos combinarlo con otros Port Groups de Virtual Machine separados por vLans.

vSwitch recomendado para el Port Group: Distribuido

vMotion: La alta disponibilidad no es la prioridad. Es un Port Group que consume mucho ancho de banda por momentos, solo durante la
migración. Podemos utilizar una red de vMotion multinic utilizando múltiples vmnics.

No debemos combinarla con los Port Groups de Almacenamiento ni Virtual Machine.

Podemos combinarla con la red de Management enrocando vmnics activas y stand-by.

vSwitch recomendado para el Port Group: Distribuido o Standard

FT: Es utilizado por un máximo de 4 maquinas virtuales primarias o secundarias por Host.

Lo ideal es utilizar un sistema de vmnics activo/stand-by combinándolo con vMotion y/o Management. Pero siempre con una vmnic stand-by.

No combinarla con redes de Almacenamiento.

vSwitch recomendado para el Port Group: Standard o Distribuido

iSCSI: Para que el Port Group esté soportado por el sistema Native Multi Path del ESXi debe tener una única vmnic en activo y ninguna en
stand-by. De otra forma no funcionaría el Failover de las rutas adicionales.

No debemos mezclar este Port Group con redes de maquinas virtuales. Tampoco es una buena práctica combinar la vmnic del Port Group con
una red de NFS. En el peor de los casos que no podamos disgregar el Port Group de iSCSI con el de NFS utilizar vLans podría ser la opción
menos mala. Pero debemos considerar que el uso de vLans hará que compartamos el caudal disponible. Considerar el uso de Jumbo Frames
(siempre de extremo a extremo).

Para la alta disponibilidad deberíamos tener dos Port Groups de iSCSI o bien un vSwitch con dos Port Groups enrocando las vmnics como
activa y unused.

vSwitch recomendado para el Port Group: Standard

NFS: El sistema de alta disponibilidad para el protocolo NFS estará provisto por las políticas de balanceo de los vSwitches. La política
recomendada es IP Hash y deberá estar acompañada por la configuración de un agregado de enlaces en los switches físicos.

Considerar el uso de Jumbo Frames.

Si el protocolo NFS solo se utilizará para almacenamiento temporal y/o biblioteca de imagenes ISO entonces podríamos combinar el Port Group
con la red de Management.

A ser posible no combinar con la red iSCSI. En su defecto utilizar vLans.

vSwitch recomendado para el Port Group: Standard