Actualmente estamos usando Link Status Only para nuestros equipos de NIC en nuestros hosts de VM, pero recientemente nos encontramos con un problema en el que uno de nuestros dos conmutadores tuvo un error de memoria y dejó de pasar tráfico. Todos nuestros hosts de VM fallaron y la mayoría de los invitados (que ya habían estado usando esa ruta de salida) también dejaron de responder hasta que apagamos ese interruptor manualmente.
En el entorno de vinculación de Linux, puede usar arp_intervals como otra forma de detectar el estado del enlace, pero en VMWare solo existe Beacon Probing. BP no es lo mismo que arp_interval en el sentido de que no elige un host para probar la conectividad y necesita tres o más interfaces para hacerlo.
Todos nuestros hosts de VM tienen cuatro NIC, por lo que el requisito de tres NIC no debería ser demasiado problema. Sin embargo, aunque la documentación solo indica que se requieren al menos tres NIC físicas separadas (pNIC), cada ejemplo también tiene tres conmutadores físicos separados y no indica si eso también es un requisito. Mientras buscaba la respuesta a esto, me encontréesteblog que dice:
"No utilice Beacon Probing si más de un pNIC en el vSwitch está conectado al mismo pSwitch. Esto podría dar como resultado que se presente la misma dirección MAC en dos o más puertos del pSwitch, lo cual es "algo muy malo""
No tenemos tres conmutadores en nuestra configuración para agravar este problema, y en algunas de mis pruebas preliminares tuve problemas inexplicables de oscilación de enlaces que pueden estar relacionados con que estuvieran conectados al mismo conmutador.
Entonces, ¿también son necesarios tres interruptores físicos separados para el sondeo de balizas? ¿Estoy relegado al estado de enlace solo para mi configuración? Y, semi-retóricamente, ¿por qué no tienen arp_interval como opción en su equipo de NIC?
Respuesta1
Con el sondeo de baliza se recomienda utilizar al menos 3 pNIC porque así es como funciona mejor la baliza. ESXi envía un paquete de difusión desde las tarjetas NIC físicas. Las otras pNIC dentro del mismo vSwitch esperan para ver si reciben los paquetes de las otras pNIC. Cualquiera que sea la pNIC que no reciba la transmisión, ESXi asume que es un enlace descendente.
Conectar las 3 pNIC al mismo conmutador y utilizar el sondeo de baliza es un desperdicio de recursos cuando el estado del enlace funcionaría porque es más simple. ¿El enlace está activado o desactivado? Los problemas de configuración (STP o bloques de puertos) no aparecerán con el estado del enlace.
La intención y el diseño del sondeo de baliza era tener las pNIC conectadas a diferentes pSwitches porque se usaba para "probar" conmutadores posteriores; interruptores más allá de aquellos a los que estaban conectados los pNIC. BP puede determinar si, por ejemplo, el tercer pSwitch en sentido descendente hacia iSCSI SAN ha fallado, el estado del enlace no lo detectará, pero BP debería hacerlo. Entonces el servidor ESXi puede determinar qué quiere hacer. El estado del enlace continuaría intentando enviar paquetes a la SAN aunque no esté disponible.