Ejemplo de Configuración de la Implementación de Balanceo de Carga de Red de Microsoft en Servidores UCS-B Series

Introducción

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.

Prerequisites

Requirements

Cisco recomienda que tenga conocimiento sobre estos temas:

• Equilibrio de carga de red de Microsoft
• Servidores de la serie B de Cisco UCS
• Switches Cisco Catalyst y/o Nexus

Componentes Utilizados

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.

Antecedentes

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.

Configuración

Modos NLB de Microsoft

Modo unidifusión

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.

Precaución: NLB en el modo de unidifusión se basa en la inundación de unidifusión desconocida para la entrega de paquetes enlazados en clúster. El modo unidifusión no funcionará en los servidores UCS B-Series cuando la FI esté en el modo de host final, ya que las tramas unicast desconocidas no se inundan como requiere este modo. Para obtener más detalles sobre el comportamiento de reenvío L2 de UCS en modo de host final, vea Modos de switching Ethernet de Cisco Unified Computing System.

Modo IGMP multidifusión/multidifusión

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.

Precaución: Independientemente de la versión del modo multidifusión elegido, la dirección VIP NLB requiere una entrada ARP estática en el dispositivo ascendente, que normalmente es la interfaz virtual conmutada (SVI) para la VLAN. Esta es una solución alternativa ya que las respuestas ARP de los nodos NLB contienen una dirección MAC multicast. Según RFC 1812, las respuestas ARP que contienen una dirección MAC multicast deben ignorarse. Por lo tanto, la dirección MAC VIP no se puede aprender dinámicamente en los dispositivos compatibles con RFC 1812.

Aquí se muestra un resumen de los pasos necesarios para soportar NLB en el modo multicast IGMP:

1. Las entradas ARP estáticas para las direcciones IP NLB virtuales se encuentran normalmente en la VLAN SVI. Si utiliza el protocolo de router en espera en caliente (HSRP) o el protocolo de redundancia de primer salto (FHRP), asegúrese de que ambos dispositivos tengan la entrada ARP estática.
2. Un consultor de indagación IGMP en la VLAN NLB. En las versiones posteriores a la versión 2.1 de UCS, UCS Manager admite la funcionalidad de consultas de indagación.
3. La detección de IGMP debe habilitarse en todos los switches, lo que incluye UCS. Tenga en cuenta que la mayoría de las plataformas que incluyen UCS tienen la función de indagación IGMP activada de forma predeterminada.

Consejo: Estas guías de configuración son para los switches Cisco. Incluyen detalles sobre cómo implementar diferentes modos de Microsoft NLB.

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)

Flujo de datos NLB de Microsoft

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.

1. Los clientes fuera de la subred envían tráfico a la dirección VIP NLB 10.1.1.1.
2. Este tráfico se enruta a la interfaz VLAN 10 que utiliza una entrada ARP estática para resolver la dirección MAC (01) del NLB VIP.
3. Dado que se trata de un destino de trama multicast, se reenvía por la tabla de indagación IGMP.
4. La trama llega a todos los nodos NLB (Nodo A,B,C).
5. El clúster NLB utiliza su algoritmo de balanceo de carga para determinar qué nodo prestará servicio al flujo. Sólo un nodo responde.

Consulte estos documentos para obtener más información:

• Ejemplo de Configuración de Switches Catalyst para Balanceo de Carga de Red de Microsoft
• Ejemplo de Configuración de Equilibrio de Carga de Red de Microsoft en Nexus 7000

Consideración especial para Nexus 1000v

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:

1. Inhabilite la indagación sólo en esa VLAN en el Nexus 1000v.
2. Utilice una VLAN dedicada para el tráfico NLB de Microsoft.

Verificación

 Los procedimientos de verificación para los ejemplos de configuración descritos en este documento se proporcionan en las secciones respectivas.

Troubleshoot

 Actualmente, no hay información específica de troubleshooting disponible para esta configuración.

Información Relacionada

• Descripción general técnica del equilibrio de carga de red
• Debate sobre la comunidad de soporte de Cisco
• Modos de switching Ethernet de Cisco Unified Computing System (busque el equilibrio de carga de red de Microsoft)
• Soporte Técnico y Documentación - Cisco Systems