Czy Cisco 6500 VSS poprawia lub szkodzi MTBF?

Rozumiem zalety Cisco 6500 VSS z oczywistymi zaletami pojedynczego zarządzania, pojedynczej instancji routingu, eliminacji STP, kanałów portów na obudowie itp. Dzięki dwóm niezależnym Cisco 6500, które mogą mieć między sobą kanały portów L3 i L2, przynajmniej nie są od siebie zależne operacyjnie przez płaszczyznę sterowania.

W świecie VSS - i nie mam z tym bezpośredniego doświadczenia - mamy teraz oprogramowanie i inne protokoły, które kontrolują oba przełączniki. Czy w moich projektach, które oczekują błędów w oprogramowaniu samolotu sterującego, VSS obniża MTBF, jak podejrzewam, i czy jest to kompromis z uzyskanymi możliwościami, czy też brakuje mi ulepszenia MTBF?

Krótka wersja odpowiedzi: trochę obu, ale nie jest to technologia bezpośrednio poprawiająca dostępność

Długa wersja odpowiedzi: jak zauważyli inni, tradycyjne definicje MTBF i dostępności koncentrują się na awariach sprzętowych. Inne czynniki - błąd ludzki, błędne oprogramowanie, planowana konserwacja itp. - to kwestie, które należy wziąć pod uwagę przy projektowaniu architektury, ale są one podejmowane na poziomie poszczególnych użytkowników.

Z perspektywy sprzętowej VSS nie wpływa na dostępność. Używa się tego samego sprzętu, więc wykorzystywane są te same numery MTBF / MTTR, a równania dostępności końcowej są takie same.

Dla bardziej holistycznej perspektywy jest to naprawdę losowanie i będzie zależeć w dużej mierze od twoich indywidualnych potrzeb i potrzeb. Z jednej strony można uznać to za mniej niezawodne, ponieważ jest to złożony element technologii, a pojedynczy „wirtualny punkt awarii” (tj. Płaszczyzna sterowania VSS) wpłynie na oba elementy redundantnego sprzętu. Z drugiej strony można to zaobserwować w celu zwiększenia dostępności, ponieważ pojedyncze urządzenie wirtualne znacznie upraszcza sieć, zmniejszając prawdopodobieństwo awarii innych urządzeń (mniej urządzeń do zarządzania, brak HSRP / VRRP, nie zapętlona domena STP, prostsza topologia L3 itp.).

Rynek pokazał, że większość inżynierów sieciowych postrzega VSS i podobne technologie jako ulepszenie w stosunku do tradycyjnej topologii dystrybucji / dostępu L2, ale są też inne technologie, z którymi można by skorzystać. Na przykład routowana warstwa dostępu L3 mogłaby osiągnąć większość korzyści z VSS, ale sieci VLAN nie byłyby w stanie rozciągać się na wiele urządzeń warstwy dostępu, co czyniło to rozwiązanie potencjalnie bezużytecznym w niektórych scenariuszach (np. W zwirtualizowanych centrach danych).

Z funkcjonalnego punktu widzenia VSS zajmuje zasadniczo dwa podwozia i uruchamia je na jednej płaszczyźnie sterowania. Jeśli chcesz stworzyć 18-slotowy 6500, jest to idealna technologia. Jeśli celem jest większa dostępność, trudniej jest to uzasadnić. Kluczową kwestią jest to, że tworząc parę VSS stworzyłeś pojedyncze funkcjonalne podwozie. Każdy tryb awarii na płaszczyźnie sterowania - od usterki oprogramowania po błąd konfiguracji - ma natychmiastowy wpływ na cały kompleks.

Co jest warte, tak naprawdę nie widziałem wielu nowych wdrożeń VSS w ciągu ostatnich pięciu lat, ale widziałem sporo, w których ta funkcja została usunięta na korzyść niezależnych par 6K.

Z mojego doświadczenia wynika, że ​​VSS wydłuża MTBF poprzez zmniejszoną złożoność operacyjną (tj. Brak HSRP / VRRP, mniej tuningu STP, prostsze trasowanie itp.), Szczególnie dla sklepów z mniej doświadczonymi inżynierami. Rekonwergencja po awariach łącza jest na ogół szybsza, ponieważ reszta sieci postrzega parę jako jedno urządzenie z perspektywy L2 i L3. Domyślam się, że jest mniej przestojów związanych z błędami oprogramowania VSS, niż przestojów przypisywanych interakcjom i trybom awarii różnych protokołów zwykle działających na tej warstwie.