Entendiendo la arquitectura de un Virtual Distributed Switch
Como he mencionado anteriormente en alguno de mis post pasados, el VDS (virtual distribute switch) se crea en el servidor de vCenter y se gestiona desde ese mismo servidor de vCenter.
Existen tres métodos a la hora de crear port groups en un Virtual Distributed Switch:
1. El adaptador de red con la configuración del port group puede ser asociado con un port group existente en un Virtual Distributed Switch.
2. El port group también puede ser migrado desde un virtual switch estándar a un VDS y viceversa.
3. Un adaptador de red con la configuración de un port group puede ser creado durante la instalación de un Virtual Distributed Switch.
Una mejor práctica de VMware es la de usar VDS en lugar de VSS ya que los switches distribuidos ofrecen algunas funcionalidades Enterprise que no están incluidas en los VSS.
Naturalmente tendrás que evaluar el coste adicional asociado al uso de los VDS ya que solo es posible configurar VDS si tienes la licencia Enterprise plus.
La configuración predeterminada en vSphere™ 5 dentro de la política de seguridad de NIC Teaming.
Para la política de seguridad de NIC Teaming, existen cuatro opciones en el algoritmo de load balancing a seleccionar: route based on the originating virtual port ID (por defecto), route based on IP hash (es necesario etherchannel), route based on source MAC hash y Explicit failover order. Recuerda que las políticas de load balancing para el Virtual Distributed Switch son las mismas, más una extra adicional.
Para habilitar el NIC teaming es necesario conectar más de una tarjeta de red física a un único virtual switch o virtual distributed switch.
Si la opción «Explicit failover order» no es elegida como algoritmo de balanceo de carga en un virtual switch con múltiples uplinks (NIC teaming) y una de las tarjetas físicas del teaming “se cae», el VMkernel verifica el contador «reported uptime» de las otras NICs para asignar una NIC del teaming y proceder al failover.
Beacon Probing se usa en vSphere™ para detectar e identificar fallos en el enlace upstream. Es muy útil en entornos Blade y en donde tenemos Spaning Three Protocol activado en nuestra red física. De esta forma podremos detectar fallos de red en los caminos alternativos.
En un VSS con un port group de tipo Management Network y un port group tipo VMkernel, y mapeas dos uplinks al VSS, es posible separar el tráfico de gestión y del tráfico VMkernel seleccionando la política de balanceo «Explict Failover order«.
Es posible ver más información sobre la configuración actual de los VSS con el siguiente comando desde la consola de servidor ESXi:
esxcfg-vswitch -l
Si te ha gustado este articulo, por favor,compártelo en Twitter o en Facebook con los botones de abajo o deja tus comentarios. Muchas gracias por tu apoyo!