ANUNCIO: La adquisición de Wesco de Rahi ha sido finalizada. Leer más
ANUNCIO: La adquisición de Wesco de Rahi ha sido finalizada.
Leer másHace unos 20 años hubo una necesidad de más servidores debido a un aumento en la cantidad de aplicaciones debido a una mejor disponibilidad de la red. Por lo tanto, fue necesario aprovisionar una gran cantidad de puertos de acceso en los centros de datos. La computación en la nube no existía en ese momento y los centros de datos privados eran la norma. Cada empresa tuvo que invertir en su infraestructura, y la tenencia múltiple también se limitó a las redes de proveedores de servicios, ya que el espacio de direccionamiento de VLAN se limitó a 4094 VLAN dentro del centro de datos.
Como resultado de la gran cantidad de servidores en el centro de datos, los conmutadores de acceso necesitaban tener más puertos para conectarse a los servidores. Estos formaron la capa de acceso. Estos, a su vez, debían agregarse a una capa de distribución / agregación, generalmente al final de la fila del centro de datos. Los conmutadores de distribución eran normalmente conmutadores modulares con una gran cantidad de puertos descendentes para agregar muchos conmutadores de acceso.
La siguiente consideración de diseño fue conectar todos estos conmutadores de distribución a un núcleo de transporte de gran ancho de banda y baja latencia con un alto nivel de redundancia. La funcionalidad de la capa central es solo el transporte de datos con una sobrecarga de enrutamiento mínima.
La funcionalidad de conmutación se limitaba a las capas de acceso y distribución, y la capa de distribución actuaba como puerta de enlace entre VLAN. La capa Core no participó en la conmutación y se centró solo en el enrutamiento. El resto de la red suele estar conectado al núcleo o un par de conmutadores de distribución dedicados. Se conectaron varios enlaces ascendentes para obtener redundancia en todas las capas y se configuraron pares de dispositivos redundantes con configuraciones idénticas en HA para una rápida conmutación por error. Esto se logró mediante enlaces cruzados. VSS fue una de esas configuraciones populares.
Los centros de datos de 3 niveles se diseñaron principalmente para flujos de tráfico Norte-Sur en un momento en que la virtualización de servidores estaba en una fase incipiente. A medida que la virtualización se volvió más común, las aplicaciones se crearon en varios servidores físicos repartidos por el centro de datos y, en algunos casos, en varios centros de datos. Esto expuso el problema con la cantidad de saltos en la arquitectura de tres niveles. Los flujos de tráfico se veían así: Servidor1 -> Acceso1->Dist1->Core (puede ser más de un salto)->Dist2->Acceso2->Servidor2. Un mínimo de 4 saltos entre los conmutadores de acceso de origen y destino.
El segundo y uno de los factores más importantes fue Spanning-tree. Administrar tantos dominios STP estaba resultando problemático y todos los enlaces ascendentes disponibles no se usaban en la red. El aprovisionamiento de aplicaciones más nuevas requería agilidad, y los equipos de red no podían hacer frente a la naturaleza dinámica de las aplicaciones mientras trabajaban con los rígidos diseños de Capa 2.
Por último, la movilidad de las máquinas virtuales se estaba volviendo cada vez más necesaria para los escenarios de recuperación ante desastres y alta disponibilidad para cargas de trabajo críticas. Esto fue difícil de implementar en el modelo de 3 niveles, ya que el diseño del centro de datos de destino L2 y L3 significaba que era necesario volver a direccionar las VM. Esto rompió las aplicaciones y requirió reconfiguraciones a nivel de usuario y administrador.
Además, el desarrollo de las capacidades de SOC por parte de los OEM de la red significó que las búsquedas de enrutamiento de velocidad cercana a la línea eran posibles. No había una necesidad real de restringir el enrutamiento al núcleo y la capa de distribución únicamente, y podría extenderse a la capa de acceso y aliviar los problemas con Spanning-tree.
Los problemas anteriores con los centros de datos de 3 niveles llevaron a los OEM a diseñar una arquitectura más simple utilizando los siguientes principios:
La red Leaf and Spine es una implementación de la arquitectura CLOS.
En el tejido CLOS, hay nuevos roles de conmutador que debemos comprender. El interruptor de hoja es otro nombre para el interruptor de acceso. Tanto los interruptores de entrada como de salida en el tejido CLOS son interruptores de hoja.
Además, tenemos la función 'Spine', que es otro nombre para la funcionalidad Crossbar en un tejido CLOS de 3 etapas. Como todos los interruptores de 'hoja' se conectan a esta capa, se llama el lomo de la tela y de ahí el nombre.
Cada hoja debe conectarse a todas las espinas de la red y utilizar ECMP para utilizar todas las rutas disponibles para el reenvío. Los interruptores de 'columna' no necesitan conectarse entre sí y se utilizan solo para la conectividad entre los interruptores de hoja.
Si bien es posible conectar redes externas a conmutadores de columna, se recomienda tener conmutadores dedicados llamados conmutadores de 'hoja de borde' que formen el borde de la estructura y se conecten a redes externas.
AdvaEtapas del uso de una arquitectura Leaf-Spine:
Rahi puede ayudar a las empresas a identificar e implementar las últimas soluciones leaf-spine disponibles en el mercado de una multitud de proveedores. Rahi tiene una amplia experiencia en la implementación altamente escalable redes de centros de datos en todo el mundo y servicios profesionales experimentados y equipos de servicios administrados para la configuración del Día 1 y el soporte del Día 2.
Si desea obtener más información, lea la segunda parte
Deje que nuestros expertos diseñen, desarrollen, implementen y administren sus requisitos mientras se concentra en lo que es importante para su negocio