viernes, 16 de septiembre de 2011

Ejemplos de diseño de uplinks en HP Virtual Connect

Algunos ejemplos explicativos de diseño de uplinks en los Virtual Connect

Para poder entender el esquema de conexionado externo hay que tener en cuenta que los Virtual Connect no interactúan con el protocolo Spanning-tree,  ya que nunca formará un bucle de red debido a su arquitectura interna.

La topología habitual para los Virtual Connect es la creación de un único dominio de configuración (Virtual Connect Domain) mediante la conexión de los diferentes módulos de Virtual Connect con enlaces de stack. Gracias a la existencia de un solo dominio la plataforma puede ser gestionada desde un mismo punto y permite compartir los uplinks de cada módulo de Virtual Connect a lo largo de toda la arquitectura, incluso si se disponen en diferentes Enclosures (chasis c7000).

Ilustración 1 – Módulo Virtual Connect Ethernet

Los Virtual Connect disponen de 8 puertos, nombrados desde X1 a X8. Hay que remarcar el comportamiento de algunos de ellos:

·         X1: La interfaz nombrada X1 dispone de dos conectores físicos diferentes que trabajan como una única desde un punto de vista lógico. El conector X1 de la izquierda es 10GBASE-CX4 mientras que el de la derecha es XFP. Este interfaz suele ser utilizado para la formación de stack externo.

·         X7 y X8: Los conectores X7 y X8 pueden ser utilizados tanto para la conectividad interna entre los Virtual Connect de las bahías 1 y 2 (formación de stack), como para conexiones externas.

·         X2 al X6: Interfaces para uplink de datos.

A continuación se exponen algunos ejemplos de diferentes utilizaciones de los uplinks disponibles.

Ejemplo A: 1 Enclosure, 2 Virtual Connect, 2 túneles y 2 agregados activo-activo

Este es el esquema puesto a modo de ejemplo en este apartado. En la parte superior aparecen las dos bahías que son ocupadas por los Virtual Connect de red en la inferior cada uno de los Blade Server.

Ilustración 2Ejemplo A de Gestión de uplinks en Virtual Connect

El diseño anterior refleja una configuración de dos túneles a los cuales se les ha asociado cada una de las dos tarjetas físicas de los servidores Blade, es decir, las NICs no están divididas, pero se muestran cuatro muescas para indicar que cada una de ellas puede ser dividida hasta en cuatro FLEX-NICs.

Entre los dos Virtual Connect se ha formado el stack mediante los puertos X7 y X8.

Debido a que, para que se forme un agregado las interfaces deben pertenecer a un mismo módulo, para maximizar la utilización se han vinculado los 4 uplink de cada Virtual Connect a un túnel respectivo, de tal manera que todos los uplinks podrán funcionar de manera activa. Para que se puedan utilizar los dos agregados al mismo tiempo se debe configurar algún método de balanceo de carga por parte del Sistema Operativo que esté instalado en cada uno de los Blade (deberá hacer uso de ambas NICs).

El control de failover también recaerá sobre el sistema operativo del Blade, es decir, si se pierde uno de los agregados deberá ser el Sistema Operativo quien envíe todo el tráfico por el interfaz restante. Debido a que dicho control se realiza en el propio Blade, la falta de conectividad en el uplink deberá propagarse hasta la tarjeta NIC de cada uno de los servidores, es decir, en el ejemplo citado, si se desconectasen los cuatro enlaces de la izquierda, se deberían desconectar también todos los enlaces de color verde. Esta propagación del error se realiza mediante una funcionalidad llamada Smart Link, cuya configuración se verá más adelante dentro de este mismo documento.

Ejemplo B: 1 Enclosure, 2 Virtual Connect, 2 SUS y 2 agregados activo-activo

Este caso es casi idéntico al anterior, con la salvedad de que no se está utilizando el VLAN tunneling, tal y como se refleja en el esquema de conectividad:

Ilustración 3 -  Ejemplo B de Gestión de uplinks en Virtual Connect

Dentro de cada Shared Uplink Set se definen las Virtual Networks asociadas, pudiendo modificar en cada una de ellas el tag de VLAN entrante.

Lo más destacable es que cada SUS mantiene sus propias Virtual Networks, aunque se comparta el id de VLAN, lo que permite la utilización de ambos enlaces de manera diferenciada.

Ejemplo C: 2 Enclosures, 4 Virtual Connect, 4 SUS y 4 agregados activo-activo

Este ejemplo introduce el concepto de propagación del dominio de Virtual Connect a lo largo de múltiples Enclosures:
Ilustración 4 -  Ejemplo C de Gestión de uplinks en Virtual Connect

Como se puede observar,  en este diseño existen dos Enclosures diferentes unidos por las interfaces X1 de los Virtual Connect. Gracias a esos enlaces de Stack se puede configurar que las NIC de los servidores Blade de un Enclosure estén asociados a un Tunel que tenga los uplinks por el Enclosure parejo, es decir, un servidor del Chasis A puede estar conectado al exterior mediante los uplinks del Chasis B.

Ejemplo D: 1 Enclosure,2 Virtual Connect, 2 túneles y 4 agregados activo-pasivo

El último ejemplo es este diseño en el que se asocian dos grupos de interfaces agregados a un único túnel/SUS.

 
Existen dos diferencias fundamentales en el caso de optar por este diseño:

1.     El failover ante la caída del agregado de enlace lo realiza el Virtual Connect, no el Sistema Operativo contenido en los Blade Server. Este punto también determina que no es completamente necesaria la activación de la funcionalidad de SmartLink.

2.     Solo uno de los agregados asociados al mismo túnel/SUS se encontrará activo, no como en los anteriores diseños en los que, dependiendo de las políticas de balanceo implementadas en los Sistemas Operativos instalados en los Blades, podían ser utilizados todos al mismo tiempo. En el caso de este diseño, el agregado activo es siempre el que más interfaces tiene conectadas correctamente.