9.
Applying Modularity
Introducción
La implementación de una red modular (Network module) al
día de hoy es de gran beneficio, pero ¿cómo podemos
hacerlo?, es decir, como puedo utilizar las tecnologías de hoy
para tener una red con diseño modular. De todo ello y más
conversaremos en este paper.
Nos vamos a centrar en dos enfoques:
- Solutions Hierarchical.
- Virtualization.
Hierarchical
- Hub and Spoke.
- Access, Distribution, Core.
- Collapsed Core.
- Multilayer.
Una simple forma de asegurarse que usted está consiguiendo
la modularidad es pensar de manera Jerárquica. La palabra
“Jerárquica” es algo que debe aprender a tener siempre en
mente cada que usted diseñe una red. Usted implementa
Jerarquía en la red cada vez que usted diseña un hub and
spoke. Hub es un tipo de modulo en su diseño y spoke son
otros tipos de módulos. Hub and Spoke es algo que se usa
frecuentemente debido a las ventajas que nos da para
construir una topología full mesh o partial mesh.
Hub and spoke Partial Mesh Full Mesh
Sabemos que una topología full mesh es muy compleja de
implementar, muy difícil para que converja rápidamente y si
hacemos un partial mesh podemos no tener la resilencia
(resiliency) que queremos. Hub and spoke lo vemos por
todas partes y es un ejemplo de diseño jerárquico modular
design (hierarchical modular desing). El hub es único con
parámetros únicos de los spoke en sí mismo.
Otro que vemos mucho es el modelo acceso, distribución y
core (Access, distribution and core), conocido como three-
layer hierarchical model, y todas las personas refieren a este
modelo como el clásico modelo jerárquico de cisco (classic
cisco hierarchical model).
La capa de acceso (access layer) Su principal característica
es la escalabilidad (scalability) debido a que ofrece gran
cantidad de puertos porqué es donde llegan todas las
personas para tener acceso a la red, donde podría encontrar
cosas como conexión inalámbrica (wireless conectivity,
wired), y entonces ponemos el tráfico en la capa de
distribución (distribution Layer). A La capa de distribución
Jorge Fernando Espejo Gonzales
podemos agregar más capas de acceso, sumarizar, hacer
políticas de seguridad y en la capa core (core layer) nos
interesamos en tres cosas: velocidad, velocidad y más
velocidad. Además, tenemos una alta disponibilidad (high
availability) y gran cantidad de ancho de banda (BW). En
esta capa no deben ir cosas como intensa seguridad y desde
la perspectiva de la calidad de servicio (QoS) debemos hacer
lo mínimo posible porque el objetivo de esta capa es mover
los paquetes tan rápido como sea posible.
Usted empieza a ver beneficios del clásico modelo jerárquico
de Cisco (classic design model hierarchical) porqué
podemos centrarnos en tecnologías especificas de aquellos
que tienen sentido en la infraestructura. Ahora bien, si esto es
muy complejo para su entorno usted puede colapsar el core
(collapse core). Esto es tener una porción de acceso y una
porción de core, las funcionalidades de la capa de
distribución (layer distribution) estarían dentro del core.
Debe tener en mente que puede tener un entorno complejo y
usted pueda necesitar un diseño multicapa (multi-layer).
Esto quiere decir que no es obligatorio tener dos (2) o tres
(3) capas jerárquicas, sino que usted podría construir una
variedad de de capas (multi-layer) cada una con sus
especificaciones. Por tal razón, usted podrá escuchar en
algún momento que se hizo un diseño de red de seis capas.
Entonces, con esto quiero decir que no estamos limitados a
dos (2) capas y tres (3) capas porque usted podría construir
una red con una variedad de capas, cada una con sus
especificaciones claramente definidas.
Una útil manera que usted y yo nos involucramos cuando
estamos diseñando e implementando una red es usar algún
tipo de virtualización.
Virtualizacion
- Logical vs Physical.
- Segregation / Desegregation
- Density.
- High Availabilitiy.
Recuerde, cuando hablamos de virtualización estamos
hablando de recursos físicos que han sido abstraídos a una
representación lógica (logical vs physical). Así, muchos
ejemplos de estos que vienen a mi mente es la segregación
(segregation) que podemos hacer en la red como virtual
LAN (VLAN) en una LAN o si estamos en una SAN podemos
hacer un Virtual SAN (VSAN). Además, también podemos
desagregar (desegregate) usando virtualización. ¿Qué
significa esto? bueno, podemos tener un centro de datos
localizado en una parte del mundo y conectar este data
center con otro que utiliza algún tipo de tecnología de
virtualización de larga distancia como la virtualización de
transporte superposición (overlay transport virtualization
- OTV) de Cisco Systems que puede hacer que dos (2)
lugares parezcan estar conectados en el mismo dominio de
capa dos (2). Así que la segregación o desegregación presentarlo a la red como un gran switch. Por favor, sea
(segregation / desegregation) es muy popular gracias a la consciente de estos diferentes tipos de dispositivos y red
virtualización. virtuales (devices and network virtualization) que podemos
utilizar para modular nuestra red.
OTV
DC 1 DC 2
Recordemos que una de las grandes razones por la que
necesitamos la virtualización es porqué queremos incrementar
la densidad (density) dentro de un particular segmento.
Digamos que tenemos un servidor dentro de un segmento en
particular y desea asegurarse que ese servidor físico se utilice
en una gran capacidad y no tener una proliferación de
servidores. Una proliferación de servidores es cuando tenemos
varios servidores y todos apenas ejecutan cualquier tipo de
capacidad. Lo que hacemos es conseguir un buen servidor,
por ejemplo un BLADE, e instalamos allí varias cajas virtuales
para utilizar mejor el recurso y no tener una baja utilización.
Cualquiera que sea el nivel de utilización, por decir, uso del
CPU constantemente en un 70%, uso de la RAM a un 80%, etc
lo que se busca es una perfecta utilización y no una sub-
utilización del recurso. Por último, la alta disponibilidad (high
Availability) es otra razón por la que tenemos que hacer
modularidad virtual en nuestro ambiente. Digamos una
maquina, dos (2) o más maquinas virtuales si tienen
problemas porque tal vez se sobre utilizo el recurso puede
fácilmente puede migrar estas maquinas virtuales a otro
servidor físico. Otro ejemplo, en un entorno de red virtual
podemos diseñar de tal manera que el tráfico de una VLAN
pueda aprovechar múltiples dispositivos de red físicos. Todo
tipo de grandes ejemplos de alta disponibilidad (high
availability) que podría dar, pero estas son suficientes
razones para recurrir a la virtualización.
Cuando se trata de virtualización probablemente vamos a
necesitar cuantificar exactamente de qué tipo de virtualización
estamos hablando. Podríamos estar hablando de:
- Virtualización de escritorio (desktop virtualization).
- Virtualización de redes (network virtualization).
- Virtualización de dispositivos (devices virtualization).
Sin embargo, de todas estas categorías la de mayor interés
para nosotros y para el examen CCDA 200-310 es la de redes
y dispositivos (Network / Device). Virtualización de red
(Network virtualization) podría ser un virtual storage area
(VSAN), virtual LAN (VLAN). Cuando hacemos virtualización
dentro de un contexto de dispositivo virtual (virtual device
virtualization - VDC) como dentro de un dispositivo NX-OS o
tal vez hablamos de security context en algo como
Adaptative Security Appliance (ASA) de Cisco.
Otro tipo de virtualización de dispositivos (virtualization
device) es el VSS (Virtual Switching System) y esto es
cuando hablamos de múltiples switches y los conectamos para
Ahora bien. Suena genial cuando se trata de virtualización,
pero hay consecuencias (consequences). Son tres las
principales que queremos que sean muy consientes de ello:
- Flate sharing
- Sub-optimal pathing.
- Over use.
Fate Sharing refiere al hecho que usted podría tener un
montón de cosas que suceden en un mismo elemento físico.
Voy a mencionarle uno de los tantos ejemplos que podría
darle. Digamos que este es una conexión física y obviamente
hay dispositivos físicos que hacen que esta conexión sea una
realidad y enviamos dos (2) túneles lógicos en su interior. Si
tenemos que el túnel uno (1) se cae túnel dos (2) tendría que
ser compartido.
TX RX
Esto realmente se vuelve aterrador cuando un ingeniero ha
diseñado redundancia dentro del ambiente, esto es como
decirle al cliente “usted tiene dos (2) diferentes túneles
virtuales y si uno de estos túneles falla el otro es el respaldo y
con ello usted mantendrá las operaciones del día”, pero ha
olvidado que hay un particular fate sharing que podría ocurrir
en el mismo componente físico y podría fallar.
Otra cosa que a menudo sucede cuando hacemos mucha
virtualización es el suboptimal pathing. Ocurre que con una
única ruta física podemos quedar realmente convencidos por
donde fluye el trafico, pero cuando hacemos una fuerte dosis
de virtualización es posible que el trafico tome un camino que
no sospecha, que fluya por una ruta sub optima o que el
retorno sea por un camino diferente al de origen inicial, trafico
asimétrico (asymetric traffic).
Otra consecuencia que sucede todo el tiempo es el sobre uso
de la virtualización (overuse). Déjame darte un ejemplo: La
compañía puede estar creando maquinas virtuales (virtual
machine - VM) sin mediar por qué, esto es hacer algo como
que por cada cosa nueva voy a crear una nueva máquina
virtual o cosas como los dispositivos de contexto (device
contexts). Usted puede tener un Nexus 7K y crear
dispositivos de contexto virtual (virtual device context -
VDC) para un cierto propósito, entonces usted crea otro VDC,
y otro, y otro. Entonces, usted tiene extensiones de la
virtualización en sí mismo cuando no es necesario.
Hoy las compañías crean maquinas virtuales para todo y ni
siquiera han hecho la dirigencia de ver si hay otro recurso
que podría ser perfectamente apropiado y capaz de asumir
ese rol. Por eso es que tenemos un montón de VM
(maquinas virtuales) en nuestra red, pero debemos
asegurar que tiene sentido la implementación de
virtualización y no porqué sea una tendencia tecnológica.