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, agregację linków oraz MC-LAG. 

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 miał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).

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.

Multi-Chassis LAG
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) w centrach danych stosuje się technologie oparte o MC-LAG.. 

Idea MC-LAF polega na połączeniu dwóch przełączników w parę  punktu widzenia warstwy II tworząc domenę. 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 przełączników z osobna.

Od strony przełącznika warstwy niższej(ewentualnie serwera) dwa przełączniki ze skonfigurowanym MC-LAG 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 przełączników będzie przeznaczony do hosta który podłączmy jest tylko do drugiego – taki ruchu zostanie przesłany poprzez peer-link (dedykowane połączenie między przełącznikami).

W przypadku awarii jednego z linków lub też jednego z przełączników całość ruchu przesyłana jest drugim pozostałym linkiem. Aby domena MC-LAG działała poprawnie konieczne jest zapewnienie konsystencji następujących wymagań:

MC-LAG a warstwa III
MC-LAG jest technologią stworzoną do obsługi warstwy II. Jednakże spotyka się topologie gdzie przełączniki klasy datacenter  są przełącznikami warstwy III. W takiej sytuacji  każdy przełącznik działa jako osobne urządzenie L3. Istnieje kilka zagadnień o których należy pamiętać.

Jeżeli nasze przełączniki są równocześnie bramkami dla danych VLAN-ów w naszej sieci zapewnienie redundancji wymaga skonfigurowania VRRP. Przełączniki warstw niższych przesyłać będą ruch na wirtualny adres MAC interfejsu VRRP natomiast od strony MC-LAG będzie on rozrzucany pomiędzy przełączniki zgodnie z algorytmem. Jeżeli pakiet trafi do przełącznika, który jest  trybie VRRP standby będzie mógł on być przez niego przesłany dalej. Odpowiedzi na zapytania ARP dotyczące adresu VRRP udzielał będzie jednak tylko przełącznik w trybie active. Jeżeli zapytanie ARP dot. bramki trafi do przełącznika standby zostanie one przesłane do przełącznika active poprzez peer-link.

Jeżeli planujemy wykorzystywać na naszych przełącznikach interfejsy SVI bez VRRP 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 MC-LAGi jego różne konfiguracje, zwłaszcza w parze z routingiem to bardzo rozbudowane i skomplikowane technicznie zagadnienie. Celem postu było pewnego rodzaju wprowadzenie do świata budowy sieci redundantnych z wykorzystaniem technologii datacenter z pozostawieniem pola do dalszej eksploracji i zdobywania wiedzy.

Michał Kaźmierczyk

CTO w Grupie Enteo/ Certyfikowany instruktor w Arrow ESC/ Dziennikarz w IT Professional/ Autor projektu cloudpoint.pl 

Praktyk, trener i pasjonat wysokiej klasy rozwiązań informatycznych związanych z szeroko rozumianym obszarem bezpieczeństwa sieci i infrastruktury IT, technologii wirtualizacji i przetwarzania w chmurze.
Jako lider techniczny nadzoruje, projektuje i bierze udział w procesie integracji projektów z różnych dziedzin, takich jak cyberbezpieczeństwo, chmura, wirtualizacja i sieci.  

Jako certyfikowany instruktor Vmware prowadzi profesjonalne kursy Vmware z NSX i Data Center Virtualization Tracks.  


To również może Cię zainteresować: 


ERP | CRM | DMS | Enova365 | Aplikacje Dedykowane | Analiza Systemowa | Projektowanie Procesów | Zarządzanie Projektami.

Systemy ERP, CRM, DMS, System Enova365, Aplikacje Dedykowane, Analiza Systemowa, Projektowanie Procesów, Zarządzanie Projektami.

NG Firewall | WAF | Antyspam | NG Endpoint | SIEM | Wirtualizacja | Przechowywanie Danych Sieci LAN Data Center, WLAN | Kopie zapasowe i DR | Audyt Bezpieczeństwa

NG Firewall, Waf, Antyspam, NG Endpoint Siem, Wirtualizacja, Przechowywanie Danych, Sieci LAN, Data Center, WLAN, Audyt Bezpieczeństwa

Chmura prywata | Chmura publiczna
IaaS | PaaS | SaaS | BaaS | DRaaS | Systemy bezpieczeństwa dedykowane dla chmury obliczeniowej

Infrastruktura w modelu Cloud.
IAAS, PAAS, SAAS, BAAS i DRAAS, Systemy bezpieczeństwa dedykowane dla chmury obliczeniowej