¿Cuál es el beneficio de un diseño Cisco "top of rack"?


7

Además del obvio lío de cableado que evita (lo cual sé que para nosotros como ingenieros de red es excelente, pero difícil de usar como excusa cuando razona con alguien que no ve ningún punto en él), ¿qué gana en comparación con el cobre directamente a un mayor? ¿núcleo?

Contexto: - El precio no es preocupante

  • La compañía ya se había decidido por un núcleo doble Nexus.

    • Opción 1: Nexus 7004, que se llenaría casi por completo con 10G SFP + y conexiones agregadas a varios FEX en la parte superior de cada bastidor en la CC, así como SAN agregado y varias conexiones de servidor

    • Opción 2: núcleos Nexus 7009 que serán aprox. 1/3 se llenó con varios módulos para acomodar la agregación de todas las conexiones de fibra de todos los dispositivos.

  • Este es un centro de datos ubicado

  • Servicios estándar relacionados con el centro de llamadas / dominio empresarial alojados en la red

  • QoS es un punto muy importante para enfatizar dado que esta empresa es un centro de llamadas

Problema:

  • No puedo justificar ir con la configuración "top of rack" de Cisco a pesar de querer menos problemas de cableado y un diseño más modular. No puedo hacerlo porque está insertando un punto de falla en la red. Hacer esto aumenta la latencia (incluso si es solo una pequeña cantidad), etc. No solo eso, sino ahora que lo pienso, ya que todos los FEX dependen del Nexus para operar, no solo aumenta la posibilidad de una falla de hardware derribando un bloque de dispositivos, pero ahora un proceso de software que podría eliminarse y causar que el FEX funcione mal de alguna manera.

Entonces, antes de poner la parte superior del diseño de rack en el cementerio de ideas para este proyecto, ¿alguien más puede ver una razón para no ir con un núcleo más grande y sin FEX debido a la falta de limitación presupuestaria?


No tengo una gran respuesta, pero me viene a la mente el aislamiento de fallas.
Yosef Gunsburg

Sí, lo consideré también. En última instancia, es el aislamiento de fallas a costa de crear el riesgo de más fallas.
skrumcd

Respuestas:


7

Tenga en cuenta que un FEX es un método inherentemente para extender la tela, de ahí el nombre. La capacidad de administrar de forma centralizada mientras se siguen distribuyendo "tarjetas de línea" en todo el DC es la verdadera razón para usar un FEX. Reducir drásticamente el cableado es valioso para cualquiera, técnico o no, y el argumento de poder administrar toda la infraestructura en menos puntos es un ahorro de tiempo, puro y simple.

Una de sus grandes dudas es que le preocupan los puntos únicos de falla. Todos los dispositivos tienen la capacidad de ser doblemente alojados, y en ciertas configuraciones, incluso puedes establecer canales de puertos virtuales con los propios Nexus 2K FEX.

Eche un vistazo a la documentación de Cisco . Descubrirá que puede diseñar una topología que sea tan redundante como la opción de "cable directo" que está considerando, con menos complicaciones.


Podríamos debatir puntos únicos de falla hasta el patrón de electrones que cruzan el cable, así que supongo que solo veo agregar otro, especialmente uno gobernado por un solo conjunto de dispositivos, de los cuales probablemente ejecutan el mismo software y podrían por lo tanto, tienen los mismos errores, que son innecesarios cuando no están limitados por un presupuesto. Supongo que me ayudaste a responder mi propia pregunta :)
skrumcd

En efecto. Una tarjeta de línea es tanto un punto de falla como una FEX. ('aunque es más fácil desconectar el FEX)
Ricky Beam

1
Piensa dónde están tus dominios de falla. ¿Puede tolerar servidores individuales frente a racks individuales frente a una fila de racks que fallan antes de preocuparse demasiado? Esa comprensión impulsa la solución para cumplir con sus objetivos de diseño y dicta el nivel de confiabilidad que necesita obtener en cada punto (servidor, rack, filas) en la red.
generalnetworkerror

13

En cuanto a los beneficios, los primeros cables se vuelven descuidados y, cuando los tengas, se producirán problemas. He visto que el cableado de infraestructura se daña por varias razones en un centro de datos. ¿Necesitas más cables? Entonces alguien está jugando con la planta de cable y algo podría dañarse. Tratar con casi 400 cables conectados a un dispositivo conduce a más desconexiones accidentales que 48. Es mucho más fácil de administrar.

En segundo lugar, esto ayuda a futuras pruebas. Si bien hay cobre de 10 Gbps, las limitaciones de distancia pueden ser problemáticas dependiendo de la situación. Además, el cobre 10G tiende a generar energía adicional cuanto más tiempo pasas.

Tercero, los FEX se pueden reemplazar más fácilmente. Desea cambiar de cobre de 1 Gbps a SFP + de 10 Gbps, solo cambie el FEX. Su núcleo permanece igual y la configuración permanece en gran parte en su lugar.

No veo los aspectos negativos que usted proporciona, y solo veo los beneficios por hacerlo.

Dependiendo de la configuración de su centro de datos, usaría dos extensores de estructura en la parte superior del bastidor o uno (si los servidores pueden compartirse con los bastidores vecinos). Los servidores deben estar conectados a dos extensores separados. Cada extensor de tela se puede conectar con FET a ambos Nexus 7k (que también se debe conectar).

Esto debería reducir sus posibilidades de fracaso. Los FEX son una extensión del chasis (lectura diseñada para el centro de datos con MTBF alto) y más similar a un módulo en un "cuerpo" de 1U en lugar de un dispositivo secundario de distribución o acceso. Arrancan arrancan el software desde el núcleo, por lo que no hay diferencia de software. Puede perder un 7k o un extensor sin pérdida de servicio en cualquier lugar. Potencialmente un 7k y un número de extensores sin perder el servicio.

También puede administrar esto como una sola unidad lógica, permitiendo que cosas como los servidores realmente puedan agregar enlaces incluso cuando están conectados a dos extensores diferentes, lo que aumenta el rendimiento y reduce la posibilidad de falla.

No puedo ver cómo esto aumentaría la latencia de ninguna manera y en realidad podría mejorarla.

Cuando comienzas a usar las funciones más avanzadas de Nexus, solo puedo ver más beneficios.

En última instancia, debe elegir sus propias necesidades. Pero diré esto, si investiga cómo las principales compañías de Internet administran sus centros de datos, descubrirá que la mayoría de ellos tienen algún tipo de despliegue superior. No eligen esto porque aumenta su tiempo de inactividad o disminuye el rendimiento. Lo hacen porque reduce el tiempo de inactividad, aumenta el rendimiento y aumenta en gran medida la capacidad de administración.

Editar: Consolidar a partir de mis comentarios para poder eliminar. El tren de comentarios es demasiado largo en este momento para que esta respuesta sea útil.


Creo que tiene la impresión de que los FEX están proporcionando más de lo que son: podemos hacer que los servidores de múltiples hogares y los FEX tengan la misma facilidad.
skrumcd

Sí, pero en esencia, estamos discutiendo entre la idea de pasar un cable directo al núcleo en lugar de ejecutarlo en dispositivos FEX que podrían fallar.
skrumcd

Entonces, para ser claros, el precio no es una preocupación, ni la densidad de puertos, ya que eso estará cubierto por los 5-6 espacios restantes en cada nexo. Sabiendo eso, ¿aún optaría por poner un fex entre los servidores y el núcleo?
skrumcd

44
Estoy de acuerdo con YLearn, la parte superior del bastidor de FEX que volverá al núcleo será mejor a largo plazo. Descubrimos que no podíamos llenar un chasis completo ya que no podíamos tener más cables en el orificio en la parte inferior del bastidor. Creo que es más probable que tenga una interrupción debido a la gran cantidad de cableado en el bastidor de red central que la falla de un dispositivo. Es fácil desconectar un cable o dos cuando busca algo o ejecuta cables nuevos, también es más fácil y rápido. reemplace un cable de conexión de 2 m de lo que es un cable de 20 m de regreso al núcleo si falla un cable.
Epaphus

3
He ido a demasiados lugares sin una configuración adecuada del interruptor TOR. Es propenso a errores, desordenado y conduce a más interrupciones. En última instancia, esto no es un argumento: son opiniones basadas en la experiencia del mundo real de varias personas. Parece bastante decidido a querer conectarse directamente a los 7K. Esta bien. ¿Funcionará? Si. Si no toca mucho el cableado, funcionará bien. Solo tenga esto en cuenta cuando sean las 2 AM y esté ejecutando un cable largo entre bastidores y esté como "¿Por qué no obtuve los interruptores TOR?" No es el cableado inicial lo que apesta. Es cada uno después de eso.
Bigmstone

4

1.) Las probabilidades son buenas de que si está en el espacio colo desea mirar el 7010 con flujo de aire de adelante hacia atrás en lugar del 7009 de lado a lado.

2.) Uno de los puntos obvios en la discusión de ToR vs cambio centralizado suele ser la escalabilidad. Si su huella colo es bastante fija, entonces no es una gran preocupación. Si está previsto que crezca de manera apreciable, tener la capacidad de expandir la red de manera racional debería ser una consideración. Dicho esto, probablemente sería reacio a usar un 7004 como punto de concentración para las unidades FEX si el crecimiento fuera una preocupación. El 7K puede correr a 48 extensores en este momento, y es probable que aumente en el futuro. Sin embargo, si va a estar en 6 gabinetes por la duración, no importa mucho de ninguna manera.

3.) Lo desconocido aquí (al menos basado en la pregunta inicial) es la densidad de servidores en los bastidores. Si son 6-8 4U, entonces el FEX es excesivo. Si se trata de muchas docenas de enlaces GE de 1U o paso de hoja, entonces el argumento del cableado adquiere un reparto más serio. He visto ciertas configuraciones (disfuncionales) con más de 384 cables en un solo rack. No es algo que quiera ver de nuevo.

En general, la principal diferencia entre un pequeño 7K que aloja un montón de unidades FEX y un 7K más grande que ejecuta esas mismas conexiones no será tremendo a pequeña escala. Como se mencionó anteriormente, el FEX solo aparece como otra tarjeta de línea en el chasis. Con muy pocas excepciones, las características y funciones de los puertos FEX serán equivalentes a los puertos nativos y se administrarán como tales.

Además, en contra de la sospecha popular, la penalización de rendimiento por usar un FEX no es significativa si está diseñada correctamente. Los argumentos sobre la latencia se miden en microsegundos (y todo el diseño se aborda mejor con una plataforma diferente si esto es un problema).


3

No hay mucha diferencia (aparte del costo) entre pasar cables directamente al núcleo o usar extensores de tela en el medio.

  1. Si conecta sus servidores directamente a los núcleos, conectará cada servidor con dos enlaces, uno a cada conmutador central. De esta manera, incluso si un interruptor central falla, el otro mantiene el servicio activo.
  2. Si coloca extensores de estructura en la parte superior de cada rack, sus servidores están conectados por dos enlaces a dos extensores de estructura diferentes que están conectados a dos conmutadores principales. El enlace entre FEX y Core Switch es un enlace L1 y toda la configuración de los extensores de estructura se comporta como un solo interruptor lógico. La configuración no introducirá nodos STP adicionales, por lo tanto, no debería haber más latencia que la primera opción. Para la pérdida de conectividad, los dos conmutadores Core o ambos FEX o sus enlaces correspondientes deberían fallar. La falla de un solo FEX o Core Switch no afectaría el servicio. Si bien los extensores Fabric son una idea relativamente nueva, la forma en que el trabajo es realmente mejor que la opción 1.

Dado que mencionó que mencionó que los presupuestos no son un problema, es posible que desee dimensionar sus Nexus 7K (y conectividad de fibra) para tener la capacidad suficiente para soportar una futura actualización a 40G o 100G. Los FEX se pueden instalar para adaptarse a los requisitos actuales. Más adelante, en caso de que desee actualizar a 100G, solo tendrá que reemplazar los FEX sin tener que cambiar su Nexus 7ks o el cableado.


El extensor de tela no tiene su propio software o configuración. Es un dispositivo plug and play que descarga el software de los conmutadores Nexus principales. Por lo tanto, no creo que pueda considerarlo un punto de falla de software adicional.
Surajram Kumaravel

1
Seguro que puede. Un proceso que se ejecuta en su padre Nexus está haciendo algo para detectar un fex, hacer la actualización flash cuando se detecta, asegurarse de que el fex se reconozca correctamente como una tarjeta de línea, controlar / configurar los FEX como tales, etc.
skrumcd

¿Y en qué se diferencia eso de una solución de chasis? Corren un proceso para detectar cuando se inserta un módulo, compruebe / actualizar el flash en el módulo (y la tarjeta hija si es necesario), asegúrese de que el módulo se reconoce correctamente, aplique la configuración, etc.
yLearn

3

El precio suele ser uno de los grandes impulsores para un diseño de "parte superior del bastidor", y usted ha dicho que el costo no es un problema.

Sin embargo, lo hemos usado por otras dos razones que aún no había visto en la lista: modularidad o facilidad de implementación.

Si tiene un diseño estándar de "bastidor", puede construir y probar un bastidor completo (o un grupo de bastidores) juntos como un módulo, o comprarlos listos para construir. Luego solo tiene que conectar algunos cables en la parte superior, en lugar de volver a conectar todas las máquinas.

El otro caso con la parte superior del bastidor puede tener mucho sentido (o la parte superior de algunos bastidores, dependiendo de su aplicación) es si tiene una configuración de compilación estándar para implementar una "celda" de su infraestructura. A veces, la comunicación dentro de una "célula" es alta (por ejemplo: servidor web, servidor de aplicaciones, servidor db, servidor de imágenes, etc.). No todos tienen este tipo de configuración, pero puede ser útil para que pueda caracterizar el rendimiento de una celda, y escalar significa agregar más celdas en lugar de aumentar toda su infraestructura (lo que puede causar más sorpresas de rendimiento).


1

En última instancia, sin una limitación de presupuesto, no tiene sentido no ir simplemente con el diseño 7009 ya que hay menos dispositivos afectados por la falla de una sola línea de fibra que de un extensor de tela completo.

Nuevamente, el extensor de tejido es un punto de falla de hardware y software adicional dentro de un entorno que no necesita la densidad de puerto adicional más allá de lo que proporciona el dispositivo central.


1
No estoy de acuerdo con esta postura ya que esta es una mentalidad de centro de datos antigua. IIRC Google, Microsoft, Netflix, Facebook y muchos más no están de acuerdo con esta postura. No dude en investigar cómo lo hacen, ya que la mayoría ha proporcionado algunos detalles de sus centros de datos públicamente.
YLearn

1
@YLearn, sin tomar partido aquí, un diseño para los grandes no es necesariamente correcto para un pequeño centro de datos, aunque daría más importancia a lo que están haciendo.
generalnetworkerror
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.