Czym się kończy brak standaryzacji

Ręczna konfiguracja urządzeń sieciowych to problem w każdym współczesnym centrum danych. Wirtualizacja serwerów w znacznym stopniu wyprzedziła rozwój mechanizmów automatyzacji sieci. Administrator sieci ma komfort, gdy osprzęt różnych dostawców jest ze sobą kompatybilny, bo urządzenia wspierają te same standardy i protokoły sieciowe. Przykładowo, routery BGP (Border Gateway Protocol) od różnych producentów mogą się bez problemu komunikować przy zachowaniu drobnych różnic w aspektach konfiguracyjnych. Dostawcy rozwiązań często modyfikują standardowe protokoły o własne rozszerzenia, ale zawsze podstawowe elementy standardu zostają zachowane. W przypadku sieci zdefiniowanych programowo już tak nie jest. Nie istnieje jedna słuszna droga do budowy kontrolera SDN, brakuje zestawu funkcji. Im bardziej zagłębiamy się w budowę kontrolera oraz architekturę, tym więcej różnic odkrywamy między poszczególnymi rozwiązaniami. Dotyczą one np. umiejętności komunikacji z przełącznikami, zaporami sieciowymi, wirtualnymi przełącznikami bądź urządzeniami do balansowania ruchu.

SDN jest technologią stosunkowo świeżą, więc producenci rozwiązań szukają sposobów na odróżnienie się i zajęcie możliwie najlepszej pozycji na rynku. Niestety takie niejednorodne podejście powoduje wiele problemów z wdrożeniami. Po pierwsze, wątpliwości budzi kwestia, czy dany kontroler ograniczy administratora do stosowania ograniczonej grupy urządzeń fizycznych. Trzeba ustalić, czy kontroler wspiera określony zestaw aplikacji i urządzeń sieciowych i czy modernizacja lub wymiana sprzętu wymusi również wymianę kontrolera. To z kolei rodzi kolejne pytanie: czy aktualnie wykorzystywane aplikacje sieciowe SDN będą pracowały z innym kontrolerem? Aplikacje stworzone dla jednego kontrolera nie muszą pracować na innym, przynajmniej bez wprowadzenia istotnych zmian.

Czas na OpenDaylight

Dlatego powstał projekt OpenDaylight, który ma zunifikować stos SDN w oparciu o modularną architekturę kontrolera. Projekt nie realizuje zadań nowego standardu, ale wiąże istniejące technologie w celu stworzenia otwartej platformy SDN. Poprzez standardy takie jak OpenFlow, oferuje możliwość zapewnienia uniwersalnego interfejsu dla wirtualnych lub fizycznych urządzeń sieciowych, kontrolowanych przez oprogramowanie. Projekt jest kombinacją komponentów zawierających pełny kontroler, interfejsy, protokoły i aplikacje. W przypadku tej platformy klienci i dostawcy mogą współpracować w celu komercjalizacji rozwiązań SDN oraz wirtualizacji funkcji sieciowych (Network Function Virtualization). W projekcie biorą udział m.in. Brocade, Cisco, Citrix, IBM, Juniper, Microsoft, Ericsson, RedHat, VMware i NEC.

Projekt zakłada dostarczanie platformy, w ramach której producenci będą mogli budować własne produkty i usługi. Projekt wspiera protokół OpenFlow, ale także oferuje możliwość wykorzystania innych otwartych standardów komunikacji SDN m.in. I2RS, VxLAN i PCEP. Zawiera otwartą bazę kodów źródłowych, które realizują główne komponenty wymagane do budowy rozwiązania SDN. Dostawcy rozwiązań komercyjnych mogą wykorzystywać OpenDaylight jako część komercyjnych produktów. Zadania przeznaczone dla OpenDaylight wiążą się z programowaniem usług sieciowych i aplikacji. Zakres działania zawiera aplikacje sieciowe, usługi, interfejs użytkownika, API, platformę kontrolera, a także interfejsy i protokoły w ramach Southbound API.

OpenDaylight został napisany w Javie, zawiera REST API oraz interfejs graficzny dostępny z poziomu przeglądarki internetowej. REST API realizuje połączenie do kontrolera, które programiści mogą wykorzystać do tworzenia nowych typów aplikacji uruchamianych w sieciach. Kontroler zapewnia znakomitą skalowalność. Zawiera moduły do implementacji interfejsów, protokołów, czy aplikacji, które mogą zostać wykorzystanie w ramach różnych potrzeb organizacji.

Pierwsza opublikowana wersja OpenDaylight nosiła nazwę Hydrogen i pojawiła się w trzech wersjach: Base, Virtualization i Service Provider Edition. Druga wersja oprogramowania, o nazwie Helium, pojawiła się z nowym interfejsem użytkownika i znacznie łatwiejszym procesem instalacji, dzięki wykorzystaniu kontenera Apache Karaf. Jeżeli zamierzamy zarządzać sieciami z wykorzystaniem OpenDaylight, istnieje możliwość głębszej integracji z OpenStackiem. Włączane są w to udoskonalenia w ramach projektu Open vSwitch Database Integration (implementacja protokołu zarządzania Open vSwitch Database RFC 7047, co pozwala konfigurować wirtualne przełączniki poprzez interfejs southbound), a także zaawansowane funkcje OpenStacka.

Wśród tych ostatnich warto wymienić m.in. zestawy filtrów IP, przypisane do określonej instancji sieci (Security Groups), funkcje routerów rozproszonych warstwy trzeciej (Distributed Virtual Router) oraz usługę balansowania obciążenia zapytań (Load Balancing-as-a-Service).

W wersji Helium zostały też rozwiązane problemy z wydajnością i bezpieczeństwem. Dodano także nowe protokoły i narzędzia usługi Service Function Chaining. Umożliwia ona zdefiniowane określonej listy usług sieciowych (zapór, systemów IDS/IPS, balansowania ruchu, itp.) i realizowanie ich w ściśle określonej kolejności.