Od paru ładnych lat fraza Software Defined Network (SDN) przybiera na popularności bijąc powoli rekordy. Zaczyna też mówić się o coraz mniejszej roli „klasycznych” inżynierów sieciowych, którzy wiedzę zdobywali parę lat temu opanowując teorię sieci pakietowych taką jak Ethernet, czy model ISO/OSI a także ucząc się komend konfiguracyjnych urządzeń sieciowych jak np. switchport access vlan, czy ip route . Artykuły jak „Sorry, network jobs are changing„, czy „Do Network Professionals Need To Be Programmers?” mogą niepokoić specjalistów, którzy ciąglę zdobywają wiedzę podręcznikową o sieciach, czy noszą się z zamiarem wyboru drogi zawodowej. Osobiście widzę wśród znajomych inżynierów i administratorów sieci lekkie zaniepokojenie tym, jak SDN może przeobraźić rynek. Bo co to dla nich tak na prawdę oznacza?
Czym jest (Software Defined Network) SDN?
Wbrew pozorom odpowiedź na to pytanie nie jest trywialna. Spotkałem bowiem masę definicji, a co ważniejsze interpretacji SDN, które w dużej mierze są podyktowane czyimś wyobrażeniem o SDN. Istotną rolę w kształtowaniu definicji odgrywają producenci, którzy chcąc iść z duchem czasu twierdzą, że na erę SDN są gotowi, lub mają już nawet gotowy produkt. Tymczasem można powiedzieć, że postulatem nr 1 Sieci Software Defined jest oderwanie abstrakcji urządzeń, które przenoszą ruch sieciowy (ang. forwarding plane) od abstrakcji warstwy kontrolnej (ang. control plane) w taki sposób, aby umożliwić sterowanie funkcjami sieciowymi przy pomocy warstwy software – w praktyce mogą to być systemy, aplikacji webowe, a także skrypty. Opisany zabieg ma na celu umożliwienie programowania warstwy sieciowej w sposób niezależny od systemów operacyjnych producenta. Stąd też często przy okazji SDN spotyka się określenia network programmability i open networking. Interakcje między warstwami takiego systemu, czyli aplikacją zarządzania, kontrolerem SDN, a urządzeniami sieciowymi narysowałbym tak:
Warto przyjrzeć się schematom komunikacji. W relacji SDN Application – SDN Controller „językiem” komunikacji jest API (Application Programming Interface) kontrolera. Czyli w teorii na tym odcinku możemy wykorzystać dowolny kontoler SDN z dokumentacją API i napisać swoją aplikację lub po prostu skrypt dla sieci SDN. Dalej komunikacja między kontrolerem SDN, a urządzeniami sieciowymi odbywa sie np. z wykorzystaniem protokołu OpenFlow. A to już oznacza, że to co się dzieje z pakietami na urządzeniach sieciowych zaczyna zależeć od zadanego scenariusza de facto z poziomu aplikacji zarządzającej, czy jak niektórzy to nazywają – orkiestratora SDN.
OpenFlow vs Netconf
OpenFlow jest protokołem, który bezpośrednio wpływa na data plane urządzenia, co oznacza, że powoduje bezpośredni wpis w tablicy routingu lub przełączania. Innym popularnym protokołem jest Netconf. Za pomocą Netconf jesteśmy w stanie zmienić konfigurację urządzenia. Zatem bliższe spełnienia postulatu separacji control od data plane w SDN jest użycie OpenFlow, natomiast z OpenFlow nie zachowamy zmian na urządzeniach co z kolei jest zaletą Netconf. Oczywiście, którego protokołu użyjesz w swojej implementacji, decyzję zostawiam Tobie.
No to co zmienia nam SDN?
Infrastruktura złożona z 6 przełączników i 2 routerów faktycznie może nie potrzebować dzisiaj rewolucji SDN, ale już zarządzanie infrastrukturą kilkudziesięciu oddziałów firmy i tysiącem urządzeń sieciowych, a także integracją z Twoim private cloud to znakomita okazja do wykorzystania zdobyczy SDN. SDN w takim wypadku może rozwiązać problem porządku w sieci, automatycznej diagnozy, błyskawicznej rekonfiguracji, a także integracji wielu obszarów IT (np. systemów, sieci, storage).
Czy Software Defined Network może być zagrożeniem dla „klasycznych” sieciowców? Być może miłośnicy czystej formy CLI i konfiguracji sesji BGP niechętnie przywitają rozwiązanie Software Defined Network, ponieważ jak by nie patrzeć jest to w jakimś sensie odebranie im piaskownicy, którą jest command line. Z drugiej jednak strony może to być przyczynek do nowej fascynującej przygody architektów SDN, którzy wykorzystując swoje umiejętności projektowania sieci IP będą w stanie zaprojektować i wdrożyć taką sieć? Spójrzmy też na otwierające się perspektywy zupełnie nowych specjalizacji jak np. Network Automation Engineer, SDN Engineer, który posiadając umiejętności programistyczne (niekoniecznie wyszukane) i znając teorię sieci IP/Ethernet będzie niezastąpionym elementem organizmy SDN pisząc skrypty i rozwijając aplikację zarządzającą SDN.
Co jeszcze?
Dzięki swojej otwartości i „programowalności” to właśnie SDN otwiera drzwi do pełnego wykorzystania potencjału urządzeń sieciowych do tej pory jednak limitowanego w pewien sposób przez język konfiguracji narzucony przez danego producenta. Wyobraźmy sobie, że za pomocą naszego skryptu i NetFlow jesteśmy w stanie de facto napisać interesującą nas funkcjonalność w warstwie data plane.. Takie podejście do zagadnienia zdaje się więcej otwierać, niż zamykać!
Czy z SDN można się przeszkolić?
Tak pojemne zagadnienie łączy w oczywisty sposób wiedzę programistyczną z wiedzą o architekturze sieci i znajomości podstaw Ethernet i IP. Szkolenie z SDN, na ten moment nazwane Coding the Network (practicing SDN) to coś co niebawem pojawi się na naszej mapie szkoleń, a więc stay connected!
