Stackowanie przełączników Cisco – StackWise i FlexStack
- Podziel się
- Udostępnij
- Tweetnij
- Skomentuj
- 5 806odsłon
Wydawałoby się, że każdy inżynier sieci chciałby w swojej pracy operować na jak największej ilości urządzeń sieciowych. Jednak wszystko ma swoje granice i w pewnym momencie zarządzanie kilkudziesięcioma identycznymi przełącznikami z identyczną konfiguracją przestaje już być tak przyjemne jak wcześniej. Na szczęście Cisco oferuje nam szereg technologii, które ułatwiają nam życie w takich sytuacji. Dzisiaj przyjrzymy się jednej z nich – stackowaniu.
Stackowanie jeszcze do niedawna było w portfolio Cisco czymś wyjątkowym, funkcjonalnością, którą można było spotkać w niewielu modelach przełączników i za którą trzeba było słono zapłacić. Dziś można śmiało powiedzieć, że StackWise oraz FlexStack mocno spowszedniały a Cisco wypuszcza coraz to więcej modeli sprzętu ze wsparciem tych technologii. Nadal pozostaje to jednak dość kosztowna zabawa. Przyjrzyjmy się niuansom tego rozwiązania.
Czym jest stackowanie?
Stackowanie lub też stacking to technologia pozwalająca nam w dużym uproszczeniu połączyć kilka urządzeń sieciowych w jedno. Jest to doskonała alternatywa dla dużych i drogich przełączników z wyższej półki (np. serie Cisco Catalyst 4500 i 6500) i właśnie do tych droższych kuzynów można stackowanie porównywać. Jak wygląda np. taki Catalyst 6513-E? Przede wszystkim charakteryzuje on się modularną budową:

Sam przełącznik to przede wszystkim obudowa (ang. chassis), zasilacze, wentylatory oraz moduły sieciowe. Porozmawiajmy o tych ostatnich. Wśród nich najważniejszą rolę pełnią supervisory, których zazwyczaj w takim przełączniku znajdziemy dwa (dla redundancji). To te moduły biorą na siebie cały management plane (zarządzanie administracyjne urządzeniem) oraz control plane (realizowanie całej logiki działania urządzenia wraz z obsługą protokołów routingu, SNMP, ARP itd). Data plane czyli przełączanie ruchu sieciowego jest natomiast realizowane na pozostałych modułach przełącznika, które właśnie z uwagi na modularną budowę jesteśmy w stanie wyposażyć w różnego rodzaju porty. Powoduje to, że tego typu przełączniki są niezwykle elastyczne w konfiguracji. Niestety w parze z możliwościami idzie w tym przypadku cena.
Wróćmy teraz do stackowania. Stacking pozwala nam połączyć ze sobą przełączniki z niższej półki (m.in. serie Catalyst 3700, 3800 oraz 2900) w jedno urządzenie (z punktu widzenia sieci). Przykładowo mamy 3 oddzielne przełączniki warstwy dostępowej (access):

Cała “magia” dzieje się natomiast z tyłu urządzeń gdzie znajdziemy kable do stackowania łączące ze sobą poszczególne przełączniki w pętlę:

Stack przełączników Catalyst 2960-X z tyłu
Kable te łączą ze sobą backplane’y przełączników. Jeden z przełączników w procesie elekcji zostaje wybrany stack masterem i to ten switch bierze na siebie odpowiedzialność za management i control plane całego stacka. W pewnym sensie pełni on rolę supervisor’a z tą różnicą, że obsługuje również data plane na swoich portach. Tymczasem pozostałe przełączniki zapewniają jedynie dodatkową pulę fizycznych portów, podobnie jak ma to miejsce w przypadku modułów w high-endowych przełącznikach serii 6500.
Zasadzie funkcjonowania stacka przyjrzymy się nieco dalej w tym artykule.
Jakie są zalety i wady stackowania?
Stackowanie ma wiele zalet, ale jak wszędzie tak i tutaj są pewne wady.
Zacznijmy od zalet:
- stacking pozwala na łatwiejszą rozbudowę istniejącej infrastruktury (zwiększa skalowalność),
- dzięki stackowaniu zmniejsza się narzut pracy związany z zarządzaniem wieloma urządzeniami (zwłaszcza przy konfiguracji urządzeń oraz wgrywaniu nowszych wersji IOS),
- stack zapewnia nam redundancję, zakładając, że dane urządzenie końcowe jest podłączone do dwóch różnych stack memberów (szczególnie wartościowe w przypadku uplinków)
- mamy możliwość budowania lepszych uplinków dzięki wykorzystaniu Multichasssis Etherchannel (MEC)
Są też niestety wady:
- kable oraz moduły do stackowania (hardware potrzebny do stworzenia stacka) potrafią być bardzo drogie,
- jesteśmy zmuszeni do stackowania przełączników z tej samej rodziny (np. 3850),
- pomyłki, zła kolejność wykonywania działań oraz niewłaściwe przygotowanie do rozbudowy stacka (dodania kolejnego stack membera) mogą spowodować reboot całego stacka, a w najgorszym wypadku utratę istniejącej konfiguracji. Dlatego też należy się dobrze przygotować, wiedzieć co się robi i dokonywać zmian podczas dedykowanego maintenance window.
Jak działają technologie StackWise oraz FlexStack?
Przyjrzyjmy się teraz bliżej jak działają technologie stackowalne stworzone przez Cisco. Jako pierwszy opiszemy bardziej zaawansowany StackWise, aby potem przejść do jego uproszczonej wersji czyli FlexStack.
StackWise
Cisco StackWise zadebiutował wraz z rodziną przełączników Catalyst 3750. Od tego czasu w tę technologię zostały również wyposażone przełączniki Catalyst 3650 oraz 3850. Najnowsza wersja, z którą mamy do czynienia do StackWise-480. Wspierana jest ona przez przełączniki serii 3850, przy czym możemy mieszać poszczególne wersje sprzętowe tego switcha. Do wyboru mamy m.in.:
- 48 portów Gigabit Ethernet
- 24 portów Gigabit Ethernet
- 12 portów Ethernet SFP
- 24 portów Ethernet SFP

Oczywiście portfolio nieustannie ulega zmianie. W chwili publikacji tego artykułu (styczeń 2019) wygląda ono następująco:

Przełączniki wyposażone w technologię StackWise mają już wbudowane porty do podłączenia kabli do stackowania – nie wymagane są więc w tym celu żadne dedykowane moduły. Porty te wyglądają następująco:

Do łączenia przełączników używamy dedykowane kable do stackowania:

Przełączniki łączymy ze sobą zawsze w zamkniętą pętlę (chociaż nie jest to warunek działania stacka – pętla zwyczajnie zapewnia nam redundancję w przypadku awarii pojedynczego kabla lub przełącznika!):

Połączenie w pełną pętlę ponadto pozwala nam uzyskać pełną przepustowość backplane’u:

Podczas gdy niezamknięta pętla daje nam jedynie połowę przepustowości:

Niezwykle istotne jest aby wszystkie przełączniki w stacku posiadały tę samą wersję IOS. Możemy o to zadbać na dwa sposoby, o czym powiemy sobie przy opisywaniu tworzenia nowego stacka oraz rozbudowy istniejącego. Generalna zasada działania jest taka, że po okablowaniu i uruchomieniu przełączników przechodzą one przez proces elekcji podczas którego wybierany jest stack master. Czynników decydujących o tym, który switch zostanie wybrany masterem jest kilka, w następującej kolejności:
- Priorytet użytkownika: mamy możliwość skonfigurowania ręcznie priorytetu na przełączniku. Domyślnie każdy przełącznik ma priorytet ustawiony jako 1, maksymalna wartość to 15. Masterem zostaje wybrany przełącznik z najwyższym priorytetem. Jeżeli dwa switche posiadają równy najwyższy priorytet to przechodzimy do kolejnego czynnika rozstrzygającego, czyli…
- Priorytet oprogramowania: masterem zostanie wybrany przełącznik z najbardziej zaawansowaną wersją IOS, w kolejności:
- IP Services z obsługą szyfrowania
- IP Services bez obsługi szyfrowania
- IP Base z obsługą szyfrowania
- IP Base bez obsługi szyfrowania
- Stan konfiguracji: w tym kroku pierwszeństwo będzie miał już skonfigurowany przełącznik (taki który nie posiada domyślnej konfiguracji)
- Uptime: tu sprawa jest prosta – masterem zostaje przełącznik z najdłuższym czasem działania
- Adres MAC: ostatnim czynnikiem rozstrzygającym jest adres MAC – pierwszeństwo ma najniższy.
Po wybraniu stack mastera przechodzi on w stan Active. Przełącznik wybrany jako drugi w procesie elekcji przechodzi natomiast w stan Backup. Jest to o tyle istotne, że technologia StackWise synchronizuje ze sobą przełączniki Active oraz Backup. Dzięki temu w razie awarii mastera, backup switch jest w stanie natychmiast przejąć zarządzanie stackiem bez powstania przerwy w działaniu. Ważna adnotacja – awaria zarówno przełącznika Active jak i Backup spowoduje padnięcie całego stacka. Zadbajmy o dobrą separację tych przełączników – przede wszystkim odrębne źródła zasilania!

Wszystkie pozostałe przełączniki przejmują rolę stack membera (czasami jest również używana nazwa stack slave) . Tak jak zostało to wspomniane wcześniej master bierze na siebie cały management plane oraz control plane – jest centralnym punktem, z którego zarządzamy stackiem oraz centralnym punktem przełączania ruchu. Oznacza to, że jeżeli mamy do czynienia z ruchem sieciowym, który “wchodzi” i “wychodzi” na tym samym stack memberze to ruch ten zawsze będzie kierowany (przez kable do stackowania) do stack mastera w celu przełączenia danej ramki. Ponadto master odpowiada za wykrywanie dodanych (bądź odjętych) urządzeń oraz aktualizowanie IOS na stack memberach.
W output’cie komendy powyżej możemy zauważyć, że każdy switch w stacku ma nadany numer. Numer ten wpływa na numerację portów. Przykładowo porty switcha numer 1 to będą porty Gi1/0/X na stacku, z kolei porty switcha numer 3 to będą porty Gi3/0/X na stacku. Mamy oczywiście możliwość zmiany numeracji przełączników.
Przepustowość backplane’u jaki tworzą kable do stackowania różni się w zależności od wersji technologii, której używamy. W przypadku StackWise-480 na Catalyst 3850 jest to zawrotne 480 Gb/s. Co więcej, StackWise-480 wprowadza bardzo ważny wyjątek od zasady – mianowicie lokalny Control Plane. W tej odmiane stackowania ruch nie musi być już przełączany przez stack mastera i zadanie to mogą wykonywać poszczególne membery.
FlexStack
FlexStack jest nieco słabszą i mniej wydajną technologią (a zarazem tańszą), która doskonale sprawdza się w warstwie dostępowej opartej o przełączniki Cisco Catalyst 2960X. W celu zminimalizowania kosztów, switche 2960-X nie mają wbudowanych portów stackowalnych. Zatem jeżeli chcemy zestackować te przełączniki to musimy je wpierw wyposażyć w stosowne moduły:

Poza modułami na dedykowane kable (jak powyżej) istnieją 2 inne rodzaje modułów: na moduły SFP oraz hybrydowe.
Kable FlexStack również się różnią od tych spotykanych w StackWise:

Podobnie jak w przypadku StackWise tak i tutaj mamy do czynienia z różnymi odmianami technologii. Dwie najpopularniejsze to FlexStack oraz FlexStack-Plus, których charakterystyki znajdziesz poniżej:
Podobnie jak w przypadku StackWise tak i tutaj mamy do czynienia z różnymi odmianami technologii. Dwie najpopularniejsze to FlexStack oraz FlexStack-Plus, których charakterystyki znajdziesz poniżej:
Technologia | Max. ilość switchy w stacku | Przepustowość backplane’u | Konwergencja |
FlexStack | 4 | 40 Gb/s | 1-2 sec |
FlexStack-Plus | 8 | 80 Gb/s | 100 msec |
Sama zasada działania FlexStack jest bardzo podobna jak w przypadku StackWise, z tą różnicą, że nie mamy tutaj ról Active/Backup. Awaria mastera powoduje przejęcie stacka przez następnego w kolejności membera. Kluczowe jest to, że nie ma on zsynchronizowanego bieżącego stanu control plane’a, w wyniku czego może wystąpić krótka przerwa w przełączaniu ruchu. Od siebie dodam, że niestety spotkałem się również z sytuacją, w której awaria mastera spowodowała awarię całego stacka (reboot i ponowną elekcję).

FlexStack odróżnia od StackWise ponadto znacznie mniejsza przepustowość backplane’u co ma sens zwłaszcza w warstwie dostępowej sieci.
W tym artykule zapoznaliśmy się z podstawami teoretycznymi stackowania. Wiedza ta przyda nam się podczas pracy ze stackami. O wykorzystaniu tej technologii w praktyce porozmawiamy w jednym z kolejnych artykułów.
🗳 Jak przydatna była ta publikacja?
Średnia ocena / 5. Ilość głosów:
Przykro mi, że ta publikacja okazała się być dla Ciebie nieprzydatna!
Uwaga: Twój głos będzie liczony tylko jeśli udzielisz feedbacku używając formularza poniżej.
Dziękuję za udzielenie feedbacku!
18 Komentarzy (Dodaj nowy)
Przydatny artykuł, dzięki! Mam pytanie, bo zaczynam przygodę z CISCO od nowych modeli switchy serii Catalyst C1000 (48 GbE + 4sfp). Tam występuje pojęcie H-stack i są tylko 4 porty uplink 10G (żadnych miejsc na moduły stackowania z tyłu). Czy to jest to samo, co FlexStack ? Jakie zalety oprócz zarządzania jednym IP ma to rozwiązanie ? Czy wydajnościowo będzie to samo jakbym połączył w topologii gwiazdy 1 switch jako rdzeń i do niego pozostałe 3 po uplinkach 10G (do nich PC i drukarki na 1GbE) a do rdzeniowego serwery (po 1GbE, ewentualnie 2x1GbE zagregowane) ? Czy wydajnościowo H-stack z 4 switchy będzie lepszy (taki sam) ? Wszystkie switche mam w jednym rack. Z góry dziękuje za pomoc i pozdrawiam.
Hej! Super przydatny artykuł 😊 Mam tylko jedno pytanie. Jak to jest z tym version mismatch? Z tego co kojarzę pewne wersje softu współpracują ze sobą i nie muszą być dokładnie takie same (choć jest to zalecane). Kluczowa jest tu “główna wersja”, a nie pełna zgodność, np. Z tego co kojarzę na 2960x 15.2.4.e4 będzie działać z 15.2.4.e6. Istotna tutaj jest zgodność stack protocol version. Możesz rozwinąć ten wątek? Czego unikać, na co zwracać uwagę?
Zgadza się, stack będzie działał na obrazach w ramach tego samego większego releasu. Natomiast jestem zdania, że lepiej nie kusić losu i sprowadzać zawsze do pełnej zgodności – jedna rzecz mniej do troubleshootowania gdy coś nie działa 🙂 Na pewno łatwiej się tego trzymać gdy ma się już dobrze wdrożony Patch Management i możliwość wygodnego sprowadzania softu na przełącznikach do z góry ustalonego baseline’u 🙂
Brawo Damian tak trzymaj.
Dzięki! Trzymam i nie puszczam! 😀
Przy Flexstacku warto też zaznaczyć że istnieją 3 rodzaje modułów , na dedykowane kable , na sfp oraz hybrydowe (https://www.cisco.com/c/dam/en/us/products/collateral/switches/catalyst-2960-x-series-switches/white-paper-c11-739615.pdf) .
Dopisane, jak zwykle świetna robota @disqus_DXa2kJdYwB:disqus!
dobra robota – ale dla mnie to liznołeś tematu, brak przykładów z CLI jak skonfigurowac stacka, brak stackowanie na linkach SFP+
czekam na 2 cześć
Dzięki, będzie druga część i zdecydowanie więcej CLI i praktycznych wskazówek.
dajcie praktyczną instrukcję upgradu softu na stacku cisco i junipera 😉 Kiedyś mało nie umarłem na zawał serca jak mi się wysypał stack 3850 w czasie upgradu w core w DC. Dokumentacja (szczególnie Cisco) jest tu szczególnie parszywa.
Kilka lat temu miałem podobną sytuację bodajże na Cisco 3750. Na szczęście wszystko wstało ale wtedy jeszcze nie wiedziałem, że te pudła mogą potrzebować nawet 30 minut! 😀
Instrukcja do upgrade’u softu na Cisco będzie – w zasadzie miała być częścią już tego artykułu ale byłby on wtedy stanowczo za długi. Z Juniperem… hmm, nie wiem, mam za mało doświadczenia z tym sprzętem żeby o nim swobodnie pisać, wymagałoby to dobrego research’u. Nie obiecuję, może 🙂
Ja mam do czynienie trochę z Juniperami EX 4300,3400,2300 i 2200i QFX 5100. Tam jest rozwiaznie podobne do Cisco Flexa nazywa się Virtual Chassis (VC).
W Juniperze działa OK pod warunkiem ze używasz trybu preprovisioned. Tryb automatyczny (non-prepro…) który jest domyślny potrafi być upierdliwy. Producent zaleca używanie we wszystkich stackach jedenej wersji softu. W VC do obsługi używany prototol IS-IS. Opisywanie tego nie ma sensu bo powstał by z tego wielki artykuł – zresztą opis jest dostępny na stronie Junipera. Aha VC w Juniperze można używać w trybie Mixed (można mieszac platformy np. EX z QFX ) ale trzeba uważać co do wersji oprogramowania w poszczególnych stackach (trzeba koniecznie przestrzegać zaleceń producenta).
Plusem VC jest to ze używa się moduły lub porty standardowe tj RJ45, SFP+ ,QSFP lub gotowych kabli Stackowych. Można stackować poprzez SFP i swiatłowod i zrobić rozproszone VC takie które znajduje się w kilku lokalizacjach ma to swoje zalety zwlaszcza gdy to urzedzenie jest switchem CORE i może być zasilane z rożnych miejsc daje to wieksze bezpieczeństwo ale wymaga to stosowania LAGa do warstwy accessowej ale LAG jest wtedy na dwóch rożnych urzedzeniach. Niestety wymaga to oczywiście rozbudowanej infrastruktury kablowo-swiatlowodowej.
Jeśli chodzi o upgrade VC to procedura nazywa się NSSU (NonStop Software Upgrade) procedura. Trzeba bardzo dokładnie przestrzegać tego co pisza w realese notes i w przypadku przeskakiwania przez więcej wersji np. 16 -18 trzeba koniecznie przechodzić upgrady zgodnie z zaleceniami producenta i zgodnie z odpowiednia mapa wersji. Wiec taki upgrade potrafi trwać bo trzeba przejść przez kilka wersji i kilka resatrtow.
Czasem zdarza się ze trzeba usunąć czesc konfiguracji np. ta dotyczaca QoSów. Ja miałem taki przypadek i dopiero po przelabowaniu znaleźliśmy w czym jest problem… Podczas restartu membera przelatywał komunikat o problemie sparsowania konfiguracji, którego nikt by nie zuważył podczas startu a później tej informacji Juniper nigdzie nie wyświetla nawet w logach ciężko było to znaleźć. Wiec nie jest to takie hop siup.
Fiu fiu, dziękuję za podzielenie się wiedzą! 🙂
Świetna robota men! Chyba jedyny newsletter na mojej skrzynce, który zawsze chętnie czytam!
Dziękuję! 🙂
Myślę, że do opisu można by również dodać opcję “Virtual Stack” 🙂
Z premedytacją to pominąłem bo w moim odczuciu Virtual Stack nie jest tak popularny jak StackWise i FlexStack ^^ Postaram się dopisać coś o Virtual Stacku w wolnej chwili 🙂