Stwierdzenie, że sieć stanowi obecnie jeden z najistotniejszych komponentów każdej nawet najmniejszej serwerowni nie mówiąc już o centrach danych jest powszechnie rozumiane i akceptowane. Można wręcz powiedzieć, że to swojego rodzaju truizm. W związku z tym konieczne jest poznanie mechanizmów pozwalających na zwiększenie bezpieczeństwa tego jakże kluczowego elementy.
Zanim jednak przejdziemy do rozważań stricte technologicznych zastanówmy się co rozumiemy przez dostępność sieci oraz do jakiego stanu dążymy podczas ich projektowania i implementacji.
Z definicji – dostępność należy rozumieć jako czas w którym, możliwe jest wykorzystanie danego systemu, w tym wypadku sieci. Im bardziej kluczowe są systemy informatycznego w naszej firmie tym wyższej dostępności będziemy oczekiwać. W mniejszej organizacji, która poradzi sobie bez swoich systemów IT (notując tylko spadek wydajności) akceptacja niedostępności będzie znacznie większa niż np. w centrum danych świadczącym usługi dla tysięcy klientów gdzie awaria sieci zwłaszcza w części rdzeniowej jest praktycznie nieakceptowalna.
Aby zminimalizować lub praktycznie wyeliminować niedostępności sieci stosuje się tzw. redundancję czyli dublowanie urządzeń i połączeń w ramach sieci. Jednakże samo zdublowanie nie jest jeszcze rozwiązaniem potrzebne są odpowiednie technologie, które poradzą sobie z wykryciem problemu i podjęciem w takiej sytuacji adekwatnego działania.
W kontekście stale zwiększającego się wolumenu transmitowanych danych dąży się również do wykorzystanie takich technologii, które oprócz zapewnienia dostępności nie będą dokonywać tego kosztem dostępnej przepustowości.
Istnieje wiele dostępnych technologii. Poniżej postaram się pokrótce opisać miejsca implementacji redundancji, problemy z tym związane oraz najpowszechniejsze z dostępnych rozwiązań tj. STP oraz agregację linków.
W szczególności skupię się na dostępnej w rodzinie Cisco Nexus implementacji agregacji znanej jako vPC tj. virtual PortChannel.
Architektura sieci redundantnej
Na początku należy wspomnieć, iż pisząc o redundancji sieci będziemy odnosić się tylko do warstwy II. Wysoka dostępność w warstwie III to temat znacznie bardziej rozbudowany i skomplikowany, który trudno byłoby objąć w ramach jednego artykułu. Implementując redundancje sieci mamy de facto dwie możliwości, które notabene są dość często miksowane.
Zakładając, że projekt naszej sieci oparty jest o model trój warstwowy lub jego wariacje czyli, że mamy co najmniej warstwę dostępową do której podłączane są urządzenia końcowe oraz warstwę dystrybucyjną i rdzeniową lub też dystrybucyjno-rdzeniową kluczowym jest zapewnienie żeby awaria któregokolwiek z przełączników pośredniczących nie maiła istotnego wpływu na transport w ramach sieci. W praktyce realizowane jest to taki sposób, że każdy z przełączników dostępowych podłączony jest minimum jednym linkiem do dwóch przełączników warstwy dystrybucyjnej, z której natomiast każdy podłączony jest do dwóch przełączników warstwy rdzeniowej.
Drugim miejscem w którym, możemy wdrożyć redundancje jest połączenie teoretycznego punktu końcowego (serwera) z przełącznikiem dostępowym. W przypadku serwerów fizycznych stosuje się tzw. NIC teaming lub też bonding (w zależności od systemu operacyjnego) i tworzy się jedną wirtualną kartę sieciową złożoną z dwóch kart fizycznych. Linki w ramach takiej karty podłącza się do dwóch niezależnych przełączników dostępowych. Jeżeli połączenie jest w trybie active-standby nie ma potrzeby stosowania dodatkowych technologii jeżeli chcemy natomiast zastosować tryb active-active koniczne jest wykorzystanie LACP (agregacji) a przełączniki dostępowe muszą obsługiwać cross-stack Etherchannel lub VSS lub wspomniane vPC (lub też inną tego typu technologię od innego vendora niż Cisco).
W przypadku serwerów przeznaczonych pod wirtualizację fizyczny przełącznik dostępowy jest de facto przełącznikiem dystrybucyjnym dla przełączników wirtualnych w ramach Hypervisorów. W takiej topologii bez dodatkowych technologii sieciowych, mechanizmy wbudowane w Hypervisory pozwalają na aktywne wykorzystanie wszystkich linków zapewniając jednocześnie wysoką dostępność. W przypadku jednak konieczności lepszej optymalizacji (równomierności) wykorzystania każdego z linków analogicznie jak w przypadku serwerów fizycznych musimy zastosować LACP i odpowiednie wspomniane technologie agregacji po stronie przełączników.
LACP
Aby lepiej zrozumieć zagadnienie zacznijmy od opisania wykorzystania LACP (Link Aggregation Control Protocol) pomiędzy dwoma urządzeniami.
Jeżeli połączymy dwa niezależne przełączniki dwoma linkami to bez zastosowania dodatkowych technologii powstanie pętla. Jeżeli na naszych przełącznikach skonfigurujemy STP jeden z dwóch linów zostanie zablokowany i jedyne co zyskamy z takiego połączenia to zabezpieczenie przez awarią pojedynczego linku.
Jeśli natomiast chcielibyśmy oprócz zabezpieczenia uzyskać również teoretycznie podwojoną przepustowość, stosujemy jak już wspomniałem agregację, która najczęściej realizowana jest w oparciu o protokół LACP.
LACP w dużym uproszczeniu działa w następujący sposób. Wybieramy od dwóch do ośmiu fizycznych linków z których wszystkie muszą być w pewnym zakresie homogeniczne tj. posiadać m.in. identyczne przepustowości, duplexy etc. W ramach tych „n” linków łączymy je (programowo) w jeden link logiczny, traktowany przez przełącznik jako odseparowane pojedyncze połączenie. Analogicznej konfiguracji dokonujemy na drugim z przełączników.
Podczas konfiguracji ustalamy parametry protokołu LACP takie jak np. czy któryś z przełączników ma aktywie próbować zestawić link LACP czy tylko nasłuchiwać na próbę takiego zestawienia inicjowaną z drugiej strony. Po pierwszej konfiguracji i fizycznym połączeniu linków przełącznik wykorzystując LACP wynegocjują sobie parametry linku logicznego takie jak np. ilość linków fizycznych czy algorytm hash-owania. Algorytm ten o którym za chwile, jest również konfigurowalny i musi się zgadzać po obu stronach.
Po wynegocjowaniu linku LACP transmisja poprzez niego wygląda w taki sposób, że w zależności od przyjętego algorytmu ruch rozrzucany jest pomiędzy linki fizyczne. Sposobem (rozrzucenia – hash-owania) może być np. hash ze źródłowego i docelowego adresu MAC czy hash ze źródłowego i decylowego adresu IP (dla każdego transmitowanego pakietu). W ten sposób dobierając odpowiedni algorytm do charakterystyki naszego ruchu jesteśmy wstanie osiągnąć względnie zrównoważone rozłożenie ruchu pomiędzy liki fizyczne.
Jeżeli, któryś z linków fizycznych przestanie funkcjonować całość ruchu będzie automatycznie transmitowana poprzez pozostałe w ramach grupy. Nie ma tu konieczności żadnego przeliczania topologii bowiem obie strony traktują grupę jako pojedynczy link, który w momencie awarie jednego z członków traci po prostu na przepustowości.
LACP pomiędzy trzema przełącznikami
Jak już wcześniej wspominałem w architekturze sieci redundantnej dąży się do tego, żeby każdy przełącznik warstwy niższej podłączony był do dwóch przełączników warstwy wyższej. Zastosowanie STP powoduje marnotrawienie przepustowości dlatego oczywistym wydaje się, że świetnie sprawdziłoby się w takiej topologii LACP w takim wariancie, że na przełączniku niższym mamy jedne link logiczny LACP złożony z dwóch fizycznych, z których każdy prowadzi do innego niezależnego przełącznika warstwy wyższej.
Podczas normalnej pracy ruch jest rozrzucany pomiędzy dwa wyższe przełączniki zgodnie z algorytmem natomiast w przypadku awarii jednego z przełączników całość idzie przez drugi sprawny. Analogiczną topologię możemy zastosować w relacji serwer – dwa przełączniki dostępowe.
Aby jednak taka realizacja LACP była możliwa konieczny jest odpowiedni sprzęt i technologia która pozawala dwóm niezależnym przełącznikom utrzymywać pojedynczy link logiczny LACP.
Jeśli chodzi o portfolio Cisco to najprostszym sprzętem w ramach którego takie połączenie jest realizowane to przełączniki Catalyst z serii 37xx połączone za pomocą technologii StackWise w stos. W ramach jednego stosu mamy możliwość skonfigurowania linku LACP z portów fizycznych z różnych członków stosu. Całość konfiguracji oraz tablice CAM i synchronizacja portów realizowane są w ramach połączenia Stacwise. Takie zestawienie LACP w Cisco nazywa się cross-tack EtherChannel. Ma on jednak kilka wad oraz nie jest dostępne w ramach innych wyższych serii przełączników.
Virtual Port Channel (vPC)
Do podstawowych problemów związanych z wykorzystaniem połączonych w stos przełączników jako bazę do budowy redundantnych linków LACP zalicza się miedzy innymi fakt, że takim stosem zarządzamy jak jednym fizycznym urządzeniem.
Każda zmiana dokonana w konfiguracji jest automatycznie propagowana na wszystkich członków stosu. Tego typu zachowanie jest korzystne z punktu widzenia zarządzania ale nie z punktu widzenia bezpieczeństwa oraz rozwiązywania problemów. Błąd w konfiguracji (błąd ludzki) czyli jeden z istotniejszych czynników ryzyka będzie afektowała wszystkie urządzania a tym samym może niekorzystnie wpłynąć na dostępność naszej sieci.
Innym problem jest możliwość konfiguracji warstwy III. Jeżeli mówimy przełącznikach obsługujących rozproszone linki LACP będziemy mieć zwykle do czynienia z przełącznikami warstwy III. W przypadku stosu konfiguracja routingu odbywa się per stos, co w wielu zwłaszcza większych i bardziej skomplikowanych topologiach może nie być akceptowalne.
W związku z ww. problemami (aczkolwiek nie tylko z ich powodu) flagowe obecnie przełączniki Cisco tj. rodzina Nexus wspierają inne podejście, tj. wspominany już Virtual Port Channel (vPC). Od nowszych wersjach softu NX-OS vPC jest już dostępne od serii 3000, co istotne aby je wykorzystać Nexusy nie muszą być identyczne.
Idea vPC polega na połączeniu dwóch przełączników Nexus w tzw. domenę vPC. W ramach takiej domeny możemy na każdym z przełączników skonfigurować link LACP i przypiąć go do naszej domeny informując w ten sposób przełączniki, że mamy odczynienia z linkiem którego porty fizyczne znajdują się na dwóch odseparowanych urządzeniach. Konfiguracyjne każda zmiana dokonywana jest na każdym z Nexusów z osobna.
Aby zestawić domenę vPC konieczne jest połączenie przełączników m.in. dwoma a zgodnie z rekomendacją Cisco trzema połączeniami. Pierwsze połączenie realizowane zwykle poprzez Interfejsy oznaczone jako MGMT to tzw. KeepAlive Link w ramach które wymienianie są heartbeaty mające wykryć problemy z którymś z członków domeny.
Pozostałe dwa połączenia to link zagregowany (LACP) zwany PeerLink, o którym w razie konieczności może być transmitowany ruch oraz jest wykorzystywany do synchronizacji stanów portów i tablic MAC pomiędzy członkami domeny.
Od strony przełącznika warstwy wyższej (ewentualnie serwera) dwa Nexusy ze skonfigurowanym vPC w ramach warstwy II widoczne są jako pojedyncze urządzenie. Ruch będzie rozrzucany pomiędzy linki fizyczne zgodnie z przyjętym algorytmem hash-owania. Jeżeli zaistnieje sytuacja w której ruch przesłany do jednego z Nexusów będzie przeznaczony do hosta który podłączmy jest tylko do drugiego – taki ruchu zostanie przesłany poprzez peer-link.
W przypadku awarii jednego z linków lub też jednego z nexus-ów całość ruchu przesyłana jest drugim pozostałym linkiem. Aby domena vPC działała poprawnie konieczne jest zapewnienie konsystencji następujących wymagań:
- Tryb Port-channel: on, off, or active
- Link speed per channel
- Duplex mode per channel
- Trunk mode per channel:
- Native VLAN
- VLANs allowed on trunk
- Tagging of native VLAN traffic
- Spanning Tree Protocol (STP) mode
- STP region configuration for Multiple Spanning Tree
- Enable/disable state per VLAN
- STP global
- Bridge Assurance
- Port type setting – rekomendowane jest ustawienie wszystkich portów vPC jako porty typu Network.
- Loop Guard
- STP interface
- Port type
- Loop Guard
- Root Guard
- Maximum Transmission Unit (MTU)
vPC a warstwa III
vPC jest technologią stworzoną do obsługi warstwy II. Jednakże Nexusy są przełącznikami warstwy III i pomimo, iż w zakresie IP każdy Nexus działa jako osobne urządzenie istnieje kilka zagadnień o których należy pamiętać.
Jeżeli nasze nexusy są równocześnie bramkami dla danych VLAN-ów w naszej sieci zapewnienie redundancji wymaga skonfigurowania HSRP. Przełączniki warstw niższych przesyłać będą ruch na wirtualny adres MAC interfejsu HASP natomiast d strony vPC będzie on rozrzucany pomiędzy Nexusy zgodnie z algorytmem. Jeżeli pakiet trafi do Nexusa, który jest trybie HSPR standby będzie mógł on być przez niego przesłany dalej. Odpowiedzi na zapytania ARP dotyczące adresu HSRP udzielał będzie jednak tylko Nexus w trybie active. Jeżeli zapytanie arp dot. bramki trafi do Nexusa standby zostanie one przesłane do Nexusa active poprzez peer-link.
Jeżeli planujemy wykorzystywać na naszych Nexusach intefejsy SVI bez HSRP należy pamiętać, że nie wspierany jest routing po połączeniu peer-link i należy dedykować osobne linki najlepiej warstwy III do obsługi routing.
Podsumowanie
Przedstawione informacje to tylko pewien bardzo wąski wycinek mechanizmów wykorzystywanych do zapewnienia redundancji w warstwie II. W szczególności vPC i jego różne konfiguracje, zwłaszcza w parze z routingiem to bardzo rozbudowane i skomplikowane technicznie zagadnienie. Celem artykuły było pewnego rodzaju wprowadzenie do świata budowy sieci redundantnych z wykorzystaniem technologii Cisco z pozostawienie pola do dalszej eksploracji i zdobywania wiedzy.