DOCTECA: Implementar y mantener una red virtual escalable en VMware

Identificar políticas de NIC teaming en vSphere

El termino NIC teaming se refiere al agrupamiento de tarjetas físicas o pNICs de nuestros hosts ESX/ESXi para poder tener tolerancia a fallos y mediante una serie de políticas poder lograr una correcta distribución del trafico entre las mismas. Dentro de nuestro vSphere client conectado ya sea al vCenter o directamente a un host podemos navegar a Configuration>Networking y editamos las propiedades de un vSwitch:

Vamos a conocer todas las políticas que tenemos en esta sección de NIC teaming:

Como primer parámetro o política tenemos la sección de load balancing, aquí tenemos todas las técnicas disponibles en vSphere para la distribución de tráfico entre los distintos portgroups y sus tarjetas de red:

Route based on the originating virtual port ID: este método es el default, cada puerto está configurado para utilizar una tarjeta física de red (pNIC) en específico. Este método es el menos demandante en cuanto a ciclos de cpu ya que no se tiene que hacer un cálculo para dirigir el tráfico. El problema con este método está en que se puede terminar con todo el tráfico intenso en una misma pNIC y no correctamente distribuido.

Route based on source IP hash: este método es el más complejo y más demandante en cuanto a ciclos de cpu de nuestro host ESX/ESXi pero aun así el más efectivo en distribuir las cargas entre distintas pNICs. En este método se utiliza el ultimo byte (LSB) tanto de la mac address de la vm como del host (almacenamiento,cliente,etc) con el cual se entabla una comunicación, para hacer un cálculo y poder determinar que pNIC será la que le corresponderá a dicha vm vamos a ver como funciona este cálculo: Tenemos la VM2 la cual tiene una mac address de 00-0C-29-22-B4-20, y tenemos un file server que tiene la mac address de 00-0C-29-22-B4-02, esta vm esta conectada a un vSwitch con 2 pNICs para saber que pNIC será utilizada para la comunicación de la misma se realiza el siguiente calculo, tomamos los 2 ultimos bytes de cada una de las mac address 20 y 02, que en decimal son 32 y 2, los sumamos y lo dividimos entre el numero de pNICs 34/2=17, aquí tenemos una división exacta por lo cual el restante sería 0 (cero) y le correspondería la pNIC 1:

Route based on source MAC hash: con este método se utiliza el ultimo byte perteneciente a la mac address de la vm a ser encendida y se divide entre el numero de pNICS y el restante de dicha división (en el caso de ser exacta el numero 0) será la pNIC a utilizar, EJ. tenemos un vSwitch con 2 pnics y una nueva vm será encendida, en el caso de dicha vm se tiene una mac address de 00-0C-29-22-B4-20, en este caso dividimos el ultimo byte (LSB – less significant byte) que en decimal seria 32 entre el numero de pnics 32/2=16, aquí podemos ver que es una división exacta por lo cual no tenemos remanentes entonces le tocaría la pNIC numero uno. El problema aquí es que al igual que basado en el puerto o port ID, no se distribuyen el trafico de las vms entre las pNICs según el consumo por lo cual podríamos terminar con todo el tráfico intenso en una misma pNIC.

Use explicit failover: este método en si no “balancea” cargas, en este método se estarán utilizando las pNICs configuradas como “Active Adapters” haciendo solo un simple cálculo de que pNIC es la que ha estado arriba el mayor tiempo, una vez determinada esta pNIC será a través de la cual se estará enviando el trafico. en el caso que las pNICs configuradas como “Activas” no estén arriba se utilizaran las configuradas como “Standby”.

Configurar politicas de Load Balancing desde la linea de comando

Para modificar los de load balancing en nuestros vSwitches necesitamos utilizar vim-cmd:

Modificar la política de load balancing a port ID para el vSwitch 0:

vim-cmd hostsvc/net/vswitch_setpolicy –nicteaming-policy=’loadbalance_srcid’ vSwitch0

Modificar la política de load balancing a IP hash para el vSwitch 0:

vim-cmd /hostsvc/net/vswitch_setpolicy –nicteaming-policy=’loadbalance_ip’ vSwitch0

Modificar la política de load balancing a MAC hash para el vSwitch 0:

vim-cmd /hostsvc/net/vswitch_setpolicy –nicteaming-policy=’loadbalance_srcmac’ vSwitch0

Verificar las políticas de load balancing en todos nuestros vSwitches:

vim-cmd /hostsvc/net/vswitch_info |grep -E ‘(policy|name)’

Network Failover Detection

Link status only: con este método para la detección de una posible falla en nuestra red lo único que tenemos es el estado físico de conexión, es decir si existe un link físico entre el switch y nuestro host ESX/ESXi, en este caso no podemos detectar fallas avanzadas como podría ser un puerto bloqueado por STP (Spanning tree protocol).

Beacon probing: con este método nuestros hosts ESX/ESXi mandan una serie de paquetes broadcast (beacon packets) a través de todas las pNICs que conforman un nic teaming, en el momento que llegan al switch este realiza el forward o reenvio de todos estos paquetes a cada uno puertos que este tenga. En el caso que alguno de las pNICs o uplinks no reciban 3 paquetes consecutivos este link se marca como caido. Este método esta pensado para ser utilizado en el caso que nuestros switches no soporten Link state tracking (también conocido como trunk failover).

Notify Switches

Esta opción básicamente lo que nos va a permitir es el notificar a los switches cambios en cuanto a nuestra red en VMware, se notifican las siguientes acciones:

Operaciones de VMotion: al cambiar de host nuestra vm se tiene que notificar al switch este cambio para que se hagan las modificaciones en su lookup table.
Cambios de MAC address: al realizar cambios de mac es necesario nuevamente notificar esta modificación para poder entablar comunicación.
Failover en nuestro nic teaming: se notifica al switch el cambio de uplink.
Inicio de una vm: estrictamente esto ocurre cada vez que una vm se conecta a un vswitch.

Para realizar las notificaciones se hace uso de RARP (Reverse Address Resolution Protocol) lo cual actualiza las asociaciones en el lookup table de nuestros switches físicos. Si nosotros necesitamos configurar Network load Balancing de Microsoft (NLB) en modo unicast es necesario deshabilitar esta función.

Failback

Aquí simplemente definimos en el caso de realizarse un failover hacia una tarjeta activa debido a la caída de otra si es que se regresara a utilizar la tarjeta fallida en el momento que esta se marca como activa. En el caso de puertos vmkernel utilizados para almacenamiento ip (ISCSI & NFS) se recomienda tener esta opción en “no” para prevenir un “ping-pong” entre los puertos en el caso que experimentemos problemas con puertos en especifico y se tenga lo que se conoce como “

port flapping”.

Failover Order

Aquí básicamente nosotros decidimos que tarjetas de red estarán activamente participando en la comunicación, cuales estarán en standby en el caso de fallo de alguna activa y cuales no quisiéramos que se utilicen: