Entiendo los beneficios del Cisco 6500 VSS con los puntos de venta obvios de administración única, instancia de enrutamiento única, eliminación de STP, canales de puertos a través del chasis, etc. Con dos Cisco 6500 independientes que pueden tener canales de puertos L3 y L2 entre ellos, al menos no tienen dependencia operativa entre sí a través del plano de control.
En un mundo VSS, y no tengo experiencia directa con esto, ahora tenemos software y otros protocolos que controlan ambos conmutadores. En mis diseños que esperan que el software del plano de control tenga errores, ¿el VSS reduce el MTBF como sospecho y es una compensación con las capacidades obtenidas o me falta cómo se mejora el MTBF?
Respuestas:
Versión corta de la respuesta: un poco de ambas, pero no pretende ser una tecnología para mejorar directamente la disponibilidad
Versión larga de la respuesta: como otros han señalado, las definiciones tradicionales de MTBF y la disponibilidad del fabricante se centran en fallas de hardware. Otros factores (error humano, software defectuoso, mantenimiento planificado, etc.) son consideraciones al desarrollar una arquitectura, pero se realizan a nivel de usuario individual.
Para una perspectiva solo de hardware, VSS no afecta la disponibilidad. Se está utilizando el mismo hardware, por lo que se utilizan los mismos números MTBF / MTTR y las ecuaciones de disponibilidad final son las mismas.
Para una perspectiva más holística, es realmente una sacudida y dependerá en gran medida de sus deseos y necesidades individuales. Por un lado, podría considerarlo menos confiable ya que es una pieza compleja de tecnología y un solo "punto virtual de falla" (es decir, el plano de control VSS) afectará a ambas piezas de equipo redundante. Por otro lado, se puede ver para aumentar la disponibilidad, ya que un solo dispositivo virtual hace que la red sea mucho más simple, lo que hace menos probable que otras cosas salgan mal (menos dispositivos para administrar, sin HSRP / VRRP, dominio STP no en bucle, topología L3 más simple, etc.).
El mercado ha demostrado que la mayoría de los ingenieros de redes ven VSS y tecnologías similares como una mejora con respecto a una topología de acceso / distribución L2 tradicional, pero hay otras tecnologías con las que podría optar. Por ejemplo, una capa de acceso L3 enrutada podría lograr la mayoría de los beneficios de VSS, pero las VLAN no podrían abarcar múltiples dispositivos de capa de acceso, lo que haría que la solución sea potencialmente inútil en algunos escenarios (por ejemplo, centros de datos virtualizados).
fuente
Desde un punto de vista funcional, VSS básicamente toma dos chasis y los ejecuta en un solo plano de control. Si desea crear un 6500 de 18 ranuras, entonces es la tecnología ideal. Si el objetivo es una mayor disponibilidad, entonces es mucho más difícil de justificar. El punto clave es que al establecer un par VSS ha creado un solo chasis funcional. Cualquier modo de falla en el plano de control, desde el defecto del software hasta el error de configuración, tiene un efecto inmediato en todo el complejo.
Por lo que vale, realmente no he visto muchas implementaciones nuevas de VSS en los últimos cinco años, pero he visto un número justo donde la función se ha eliminado a favor de ejecutar pares 6K independientes.
fuente
Según mi experiencia, VSS alarga el MTBF a través de una complejidad operativa reducida (es decir, sin HSRP / VRRP, menos sintonización de STP, enrutamiento más simple, etc.) especialmente para tiendas con ingenieros con menos experiencia. La reconvergencia después de fallas en los enlaces es generalmente más rápida ya que el resto de la red ve al par como un dispositivo desde una perspectiva L2 y L3. Supongo que habría menos interrupciones relacionadas con los errores del software VSS, que interrupciones atribuidas a las interacciones y los modos de falla de los distintos protocolos que normalmente se ejecutan en esa capa.
fuente