Este documento describe la implementación del modo de equilibrio de carga de red (NLB) de Microsoft en la serie Cisco Unified Computing System-B (UCS-B) con Fabric Interconnect (FI) en modo de host final. También hay una serie de requisitos en los dispositivos ascendentes para facilitar el reenvío correcto del tráfico NLB que se describen en este documento. El ejemplo de configuración se centra en el modo de protocolo de administración de grupos de Internet (IGMP) multidifusión.
Cisco recomienda que tenga conocimiento sobre estos temas:
Este documento no tiene restricciones específicas en cuanto a versiones de software y de hardware.
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.
Microsoft NLB funciona en tres modos operativos diferentes: IGMP de unidifusión, multidifusión y multidifusión. Un grupo de nodos NLB se conoce colectivamente como un clúster NLB. Un clúster NLB proporciona una o más direcciones IP virtuales (VIP). Los nodos del clúster NLB utilizan su algoritmo de balanceo de carga para acordar qué nodo individual prestará servicio al flujo de tráfico particular destinado al VIP NLB.
Este documento no hace recomendaciones de implementación específicas para Microsoft NLB en UCS. Como se describe en este documento, NLB se basa en métodos no convencionales para la entrega del tráfico enlazado al clúster. Se ha observado que los modos IGMP multidifusión y multidifusión parecen tener un funcionamiento estable y uniforme en los servidores de la serie UCS-B. Aunque las directrices de dimensionamiento de NLB están fuera del alcance de este documento, es una solución generalmente recomendada para implementaciones más pequeñas.
El valor predeterminado de NLB es el modo de unidifusión. En el modo de unidifusión, NLB reemplaza la dirección MAC real de cada servidor en el clúster por una dirección MAC NLB común. Normalmente, algo en el rango 02bf:xxxx:xxxx. Todos los nodos en el clúster NLB entienden qué es el VIP NLB y la dirección MAC. El tráfico, que incluye las respuestas del protocolo de resolución de direcciones (ARP) de los nodos NLB, nunca se origina en la dirección MAC o IP del NLB. En su lugar, los nodos NLB utilizan una dirección MAC asignada basada en el ID de host del miembro. La dirección MAC suele estar en el rango 0201:xxxx:xxxx, 0202, 0203, etc., uno para cada nodo del clúster. Esta es la dirección de origen en el encabezado de Capa 2 (L2) cuando se contesta una solicitud ARP. Sin embargo, la información del encabezado ARP contiene la dirección MAC NLB. Por lo tanto, los hosts que desean corresponder con la dirección VIP NLB envían tráfico hacia la dirección MAC NLB.
Los switches compatibles con IEEE (dispositivos L2) crean su tabla de direcciones MAC basándose en el encabezado de origen L2 y no en la información contenida en la carga útil ARP. Esto significa que el tráfico reenviado al clúster NLB se envía a la dirección MAC NLB, que nunca es el origen del tráfico. Por lo tanto, el tráfico destinado a la dirección MAC NLB se inunda como unidifusión desconocida.
El modo de multidifusión asigna la dirección IP virtual de unidifusión de clúster a una dirección MAC de multidifusión que no sea de Internet Assigned Numbers Authority (IANA) (03xx.xxxx.xxxx). La indagación IGMP no registra dinámicamente esta dirección, lo que da lugar a la inundación del tráfico NLB en la VLAN como multicast desconocido.
El modo IGMP de multidifusión asigna la dirección IP virtual del clúster y una dirección MAC de multidifusión dentro del rango IANA (01:00:5E:XX:XX:XX:XX). Los nodos agrupados envían informes de afiliación IGMP para el grupo multicast configurado y, por lo tanto, la FI rellena dinámicamente su tabla de indagación IGMP para señalar hacia los servidores agrupados.
El uso del modo de multidifusión IGMP presenta una ligera ventaja operativa, ya que la información de estado (a través de los informes de pertenencia de IGMP y la indagación de IGMP) sobre los puertos L2 interesados se puede mantener tanto en sentido ascendente como descendente. Sin la optimización de la indagación IGMP, NLB depende de la inundación de multidifusión desconocida en la VLAN NLB para la entrega al clúster a través del receptor de difusión/multidifusión designado por UCS. En las versiones posteriores a UCS Release 2.0, el receptor de difusión/multidifusión designado se elige por VLAN.
Aquí se muestra un resumen de los pasos necesarios para soportar NLB en el modo multicast IGMP:
En este diagrama se muestra una configuración básica de NLB, los nodos pueden ser máquinas virtuales (VM) o una instalación sin software específico del sistema operativo de Windows Server.
VLAN 10 NLB que tiene subred IP 10.1.1.0 /24. La dirección MAC se trunca para su brevedad.
NLB VIP (MAC = 01, IP = 10.1.1.1)
NODO A (MAC = AA, IP = 10.1.1.10)
NODE-B (MAC = BB, IP = 10.1.1.11)
NODE-C (MAC = CC, IP = 10.1.1.12)
La entrada ARP estática en el switch ascendente SVI señala a la dirección VIP 10.1.1.1 a MAC 01.
Los nodos NLB de Microsoft envían el informe de pertenencia de IGMP. Tenga en cuenta que la tabla de indagación IGMP puede tardar entre 30 y 60 segundos en completarse.
Con la indagación de IGMP y el solicitante de VLAN, la tabla de indagación se rellena con la dirección MAC NLB y los grupos que señalan a los puertos L2 correctos.
Consulte estos documentos para obtener más información:
Nexus 1000v sólo admite el modo unidifusión Microsoft NLB. Por lo tanto, en las implementaciones de Nexus 1000v con UCS, el modo de multidifusión IGMP solo funcionará después de desactivar la indagación en Nexus 1000v. Cuando se hace esto, los paquetes NLB de Microsoft en esa VLAN se inundan como multicast desconocidos.
Para minimizar el impacto de las inundaciones:
Los procedimientos de verificación para los ejemplos de configuración descritos en este documento se proporcionan en las secciones respectivas.
Actualmente, no hay información específica de troubleshooting disponible para esta configuración.
Revisión | Fecha de publicación | Comentarios |
---|---|---|
1.0 |
14-Aug-2014 |
Versión inicial |