i czym się różni od innych technologii sieciowych?
O SD-WAN powiedziano już sporo i wynika z tego, że jest on różnie rozumiany przez rynek i klientów (niekiedy nawet, że nie jest rozumiany właściwie). Podczas spotkań z klientami niejednokrotnie spotykam się z opinią, że choć rozmawiali już z dwoma dostawcami, żaden nie potrafił wskazać wartości wynikającej z tego rozwiązania.
Żeby było trudniej, sami producenci pozycjonują i pokazują SD-WAN w różny sposób. W dzisiejszym wpisie postaram się przybliżyć koncepcję oraz sposób działania SD-WAN i podpowiem, czym różni się od innych, dostępnych na rynku rozwiązań.
Zaczynajmy!
Przedstawiając technologię SD-WAN zawsze opieram się na czterech podstawowych filarach. Są nimi:
Rozdzielenie Data Plane i Control Plane;
Overlay i sposób utylizacji łączy;
Aplikacje i bezpieczeństwo;
Automatyzacja i zarządzanie oraz gotowość do wejścia do chmury.
Nie biorąc pod uwagę kolejności tych zagadnień, priorytetem w wyborze rozwiązania SD-WAN i jego wyróżnikiem może być zarówno nacisk na jakość transmisji ruchu aplikacyjnego w sieci WAN, uniezależnienie logiki naszej sieci WAN od dostawców łączy, ale także np. równoczesna utylizacja wielu łączy WAN w ramach jednej lokalizacji, czy w końcu aspekt ekonomiczny.
Wszystko zależy od tego, czego potrzebujemy i jak na to patrzymy.
Filary SD-WAN
Control Plane (CP) możemy zdefiniować jako obszar, w którym zachodzi logika obliczania najlepszych (np. “najtańszych”) tras między punktem A i B. Zachodzi tam m.in. konwersacja dynamicznych protokołów routingu, czyli wszystko to, co router musi zrozumieć lub obliczyć, aby poprawnie kierować ruch użytkowników i systemów w odpowiednią stronę. Ten obszar najczęściej związany jest z obciążeniem procesora (CPU), ew. pamięci RAM.
Natomiast Data Plane (DP) jest obszarem odpowiedzialnym za samą transmisję (czyli jak najszybsze przesyłanie) pakietów z danymi produkcyjnymi, np. użytkowników, systemów i aplikacji. Ten obszar routera może być związany np. z efektywnością i jakością programowalnych układów scalonych.
Rozdzielenie obszarów opisanej wyżej logiki w przypadku sieci SD-WAN, to wyniesienie roli kontrolerów CP, czyli rozdzielenie kontrolerów sieci Software Defined WAN od routerów sieci WAN (DP). Obrazując ten zabieg, możemy powiedzieć, że routery są zainstalowane fizycznie w lokalizacjach firmy ( w formie fizycznej lub wirtualnej), a kontrolery mamy obok – fizycznie lub wirtualnie (np. w chmurze).
Głównym zadaniem kontrolerów CP jest obliczanie informacji związanych z topologią sieci, routingiem i obliczeniami najlepszej ścieżki z perspektywy sieci SD-WAN, czyli krótko mówiąc, jak trafić z lokalizacji początkowej do lokalizacji docelowej. Ocenia to i definiuje nam kontroler, a następnie przekazuje odpowiednie informacje w formie wyników np. gotowych wpisów routingu prosto do routera SD-WAN. Routery w tym przypadku zajmują się już tylko jak najszybszym przekazaniem pakietów zgodnie z logiką podaną przez kontroler.
Control plane i Data plan w SD-WAN
Jest to związane ze skalowaniem. Różnicę może być widać nie przy trzech czy dziesięciu lokalizacjach, a przy kilkudziesięciu lub kilkuset. Tradycyjnie, routery wyliczały optymalną ścieżkę w tym samym “paśmie”, którego używały do transmisji Data Plane, a także tymi samymi zasobami np. CPU (które co warto podkreślić używane są do realizacji np. niektórych funkcjonalności bezpieczeństwa). W momencie kiedy mamy dużą sieć, każdy router musiałby brać udział w wyliczeniach tworząc sąsiedztwa routingu z innymi routerami w sieci angażując zasoby.
Zakładając, że w naszej sieci WAN budujemy topologię Full Mesh, czyli każdy z każdym, liczba relacji CP i obliczeń tras może rosnąć nawet wykładniczo w stosunku do liczby routerów w sieci. Bez rozdzielenia CP i DP, cały narzut obliczeniowy i utrzymanie sąsiedztw routingu jest właśnie po stronie routera. W momencie rozdzielenia tych dwóch ról, narzut na wyliczenia najszybszej ścieżki znajduje się po stronie kontrolera. Opisaną sytuację pokazuję dwa kolejne schematy.
To pozwala na bardzo wydajne skalowanie sieci WAN, co jest szczególnie przydatne w przypadku firm dysponujących wieloma oddziałami, które muszą się ze sobą sprawnie komunikować.
Podejście bez Disaggregation
Tradycyjne podejście do budowania sieci rozległych, czyli wprowadzanie dynamicznego protokołu routingu między lokalizacjami, np. OSPF lub BGP w ramach tuneli GRE lub jakiegoś innego, specyficznego dla danego producenta.
Jeśli wyobrazimy sobie sieć z 50-oma lokalizacjami zdalnymi i 2-oma lokalizacjami centralnymi i spojrzymy na wyliczenia pod rysunkiem, dojdziemy do ciekawych wniosków.
Obliczenia dotyczą routerów w różnych konfiguracjach:
a) w konfiguracji Hub & Spoke, 2 x Hub (1 łącze) i 50 lokalizacji (2 łącza),
b) w konfiguracji Full Mesh, 2 x Hub (1 łącze) i 50 lokalizacji (2 łącza),
c) w konfiguracji Full Mesh, 2 x Hub (2 łącza) i 100 lokalizacji (2 łącza).
Tutaj, budując sieć overlay w oparciu o BGP z wykorzystaniem standardowego podejścia (bez rozdzielenia CP i DP), powinniśmy zestawić sesję BGP “per łącze”, czyli utrzymać dla przypadku a) min. 101 sesji na każdym routerze Hub oraz 4 sesje na każdym routerze Spoke, dla b) odpowiednio 101 sesji na każdym routerze Hub i 102 sesje na każdym Spoke, dla c) 204 sesji na Hub i 204 sesje na każdym Spoke!
To właśnie w sytuacji Full Mesh mamy ten najgorszy przypadek, jeśli chodzi o skalowanie. W krytycznych, niekoniecznie źle zaprojektowanych sieciach, liczba sesji rośnie wykładniczo w przypadku Full Mesh. Może to być 200 sesji w przypadku 50 site’ów i już nawet 400 sesji w przypadku 100 lokalizacji.
Disaggregation – Przykład
Kiedy mówimy o rozdzieleniu CP i DP, mamy najczęściej dwa kontrolery i cała konwersacja protokołu routingu, który np. w SD-WAN Cisco nosi nazwę OMP (Overlay Management Protocol), odbywa się zawsze w ramach jednej sesji z jednego interfejsu do każdego kontrolera, co oznacza przy 2 łączach ISP 4 sesje CP. Oznacza to, że liczba lokalizacji nie wpływa na wzrost liczby sesji OMP pojedynczego routera!
Tutaj odnajdujemy potencjał postulatu disaggregation.
Kolejnym fundamentem SD-WAN jest tzw. overlay.
Co to oznacza?
Overlay jako pojęcie jest dobrze znane wśród inżynierów sieciowych (być może bardziej jako enkapsulacja). Może nim być np. tunel GRE (Generic Routing Encapsulation) czy VXLAN. Potocznie, jest to sytuacja, w której pakujemy pakiet w pakiet, lub inaczej, na pakiet A z nagłówkiem A nakładamy kolejny nagłówek B. Sieć widzi i interpretuje nowo utworzony pakiet z perspektywy nagłówka B. Dzięki takiej enkapsulacji możemy transportować pakiety np. z sieci prywatnej do sieci prywatnej z wykorzystaniem sieci Internet. Overlay (sieć nakładkowa) w tym przykładzie tworzy nagłówek A, Underlay (sieć podkładowa) kieruje się nagłówkiem B.
Overlay w SD-WAN to opakowanie pewnej logiki sieci WAN w nagłówek zewnętrzny (Underlay), który rozumiany jest przez sieć operatora np. biznesowy MPLS, łącze Metro Ethernet, Radiolinia, LTE, czy klasyczne łącze do Internetu.
Dlatego budując sieć overlay posługujemy się własną logiką, niezależną od sieci podkładowej operatora. Łącza operatorskie w SD-WAN są pewnego rodzaju zasobami, które wykorzystujemy pod budowę SD-WAN. Dzięki takiemu podejściu możliwa staje się niezwykła elastyczność funkcjonowania sieci WAN. Uproszczona staje się wymiana operatora, dołączenie kolejnego łącza, a co najważniejsze, bez względu na specyfikę operatorów, zachowana zostaje zawsze nasz logika routingu i topologii sieci.
Dzisiaj oczywiste jest, że biznes, aplikacje biznesowe i ich wymagania są czymś, czemu musimy służyć jako infrastruktura IT, a w tym przypadku SD-WAN.
To one są jednym z elementów, które definiują, usprawniają i umożliwiają realizację biznesu naszej firmy.
W kontekście SD-WAN, możemy skoncentrować się właśnie na aplikacjach i zapewnieniu ich jakości. SD-WAN “rozumie” aplikacje.
Routery SD-WAN potrafią rozpoznać rodzaj aplikacji np. typu SaaS jak Microsoft 365, a dzięki temu pokierować ich ruchem w sposób , który zaplanujemy, np. skierować ruch do M365 bezpośrednio w ramach DIA (Direct Internet Access) nie obciążając zasobów routerów centralnych. Dzięki umiejętności rozpoznania aplikacji, SD-WAN umożliwia budowę polityki, operującej właśnie na rodzaju aplikacji. Przykładem jest skierowanie konkretnej grupy aplikacji ścieżką o danych parametrach, a innej grupy aplikacji alternatywną dostępną ścieżką.
Tutaj widzimy dwie ciekawe właściwości:
możliwość dbania o jakość tzw. QoE (Quality of Experience)
możliwość wysycania na raz dostępnych łączy
Routery SD-WAN zaglądają nie tylko w nagłówek IP, czyli warstwę trzecią (L3 OSI), ale też w warstwę aplikacyjną.
W kontekście sieci WAN, bezpieczeństwo na poziomie routerów ograniczało się do zestawiania tuneli i ew. szyfrowania danych w tych tunelach. Aktualnie wiemy, że sieć WAN i lokalizacje zdalne mogą też być w pewnym sensie wektorem ataków. SD-WAN odpowiada na takie wyzwania i w ramach routera już dziś mamy dostępne takie technologie jak: anti-malware protection, IPS, stateful firewalling i DNS security, które w przypadku Cisco SD-WAN opiera się na rozwiązaniu Cisco Umbrella.
Wszystkie te mechanizmy dostępne są na poziomie routera SD-WAN i są to mechanizmy już znane, spójne z portfolio danego producenta. W takim przypadku router SD-WAN jest kolejnym elementem w holistycznym podejściu do bezpieczeństwa sieci.
Kiedyś mogliśmy automatyzować sieci, skryptować, budować systemy, które zarządzają sieciami i je monitorują. Łącząc nasze zasoby z chmurą publiczną wykorzystywaliśmy IPSec site-to-site z wirtualnym urządzeniem dostawcy chmury (do dziś tak oczywiście możemy).
Dzisiaj jednak wyposażając naszą sieć rozległą w rozwiązanie SD-WAN, mamy powyższe “w standardzie”. Wszystko w jednym miejscu jako integralną część rozwiązania SD-WAN, np. w kontrolerze vManage – spójnym dashboardzie do zarządzania całą siecią SD-WAN. Być może już dzisiaj takie podejście jest swego rodzaju definicją nowoczesnej sieci typu software-defined?
Z kolei gotowość wejścia do chmury to ten postulat, który pokazuje, że zasoby w chmurze np. IaaS możemy potraktować po prostu jako kolejną lokalizację WAN. Możemy uruchomić router SD-WAN w formie wirtualnej instancji, w danej chmurze publicznej np. AWS czy w Azure, de facto w ciągu minut (może godzin w przypadku bardziej skomplikowanej topologii w chmurze). Nie musimy dostarczać tam fizycznego sprzętu, a tylko włączyć lokalizację.
To, co najważniejsze, to fakt, że widzimy ten zasób jako naszą lokalizację WAN. Nie jest to nieznana nam, odseparowana sieć. Nieustannie ją widzimy i możemy mierzyć np. wydajność aplikacji end-to-end.
Tak wyglądają postulaty, które formułują sieć SD-WAN. Dzięki wprowadzeniu ich w życie z Software-Defined WAN możliwe jest dzisiaj wdrożenie kompleksowego rozwiązania WAN z funkcjonalną architekturą zabezpieczeń, możliwością skalowania wraz ze wzrostem liczby oddziałów, gotowymi narzędziami automatyzacji i monitoringu.
Marcin Biały jest architektem systemów sieciowych i bezpieczeństwa IT i kierownikiem organizacji technicznej w Grandmetric. W swojej karierze prowadził duże projekty transformacyjne u klientów z branży bankowości, sektora enterprise, produkcji czy instytucji państwowych. Spędził setki godzin przy konfiguracji, diagnostyce i projektowaniu sieci IP. Jest autorem kursów, workbook’ów do szkoleń autorskich Grandmetric i organizatorem inicjatyw takich jak Network & Wireless meetup zrzeszających społeczność specjalistów sieciowych. Jego specjalizacje obejmują obszar Network Security, Routing & Switching, a przy okazji posiada szereg certyfikatów branżowych takich jak np. Cisco CCSI#35269, CCNP, CCNA. Był także był jednym z pierwszych inżynierów w Polsce uzyskując certyfikat FCNSP#7207 (dzisiejsza ścieżka NSE).
Dodaj komentarz