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).
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.
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.
