To jest 119. odcinek podcastu Porozmawiajmy o IT, w którym z moim gościem rozmawiam o języku P4 i programowaniu urządzeń sieciowych.

Przypominam, że w poprzednim odcinku mówiłem o transformacji do chmury. 

Wszystkie linki oraz transkrypcję dzisiejszej rozmowy znajdziesz pod adresem porozmawiajmyoit/119. 

Ocena lub recenzja podcastu w Twojej aplikacji jest bardzo cenna, więc nie zapomnij poświęcić na to kilku minut.

 

Partnerem dzisiejszego odcinka jest firma MOTIFE, krakowska firma konsultingowa, która pomaga międzynarodowym firmom software’owym otwierać oddziały w Polsce. MOTIFE współpracuje z firmami technologicznymi między innymi z USA, Kanady, UK czy Skandynawii. Na stronie MOTIFE, pod adresem motife.com/jobs, można znaleźć oferty pracy IT w nowych oddziałach firm zagranicznych. W ofertach firmy MOTIFE zawsze znajdziesz informację o wynagrodzeniu oraz o tym, jak będzie wyglądał proces rekrutacyjny.

 

MOTIFE jest autorem raportu „Krakow IT Market Report 2021”, najbardziej szczegółowego przeglądu rynku IT w Krakowie. Raport możesz pobrać bezpłatnie na stronie motife.com/itreport. To nie wszystko, do 30 czerwca 2021, w ramach programu rekomendacyjnego REFER A FRIEND, MOTIFE potraja kwotę za polecenie znajomego. Możesz zgarnąć nawet siedem i pół tysiąca złotych i możesz polecić dowolną liczbę osób. Szczegóły akcji znajdziesz również na stronie motife.com/jobs. Pamiętaj, akcja trwa do 30 czerwca 2021 roku.

 

Nazywam się Krzysztof Kempiński, a moją misją jest poszerzanie horyzontów ludzi z branży IT. Środkiem do tego jest między innymi ten właśnie podcast. Zostając patronem na platformie Patronite możesz mi w tym pomóc już dziś. Wejdź na porozmawiajmyoit.pl/wspieram i sprawdź szczegóły. 

Jednocześnie bardzo dziękuję moim obecnym patronom.

A teraz życzę miłego Ci już miłego słuchania.

Odpalamy!

 

Cześć! Mój dzisiejszy gość to absolwent telekomunikacji na Politechnice Warszawskiej, wieloletni pracownik Orange Polska związany z sieciami SDN, podejściem DevOps, cloud i edge computing, obecnie na stanowisku senior network engineer of CodiLime, gdzie koordynuje pracami R&D, zarządza zespołami budującymi innowacyjne rozwiązania sieciowe w obszarze SDN, NFV i dzieli się swoją wiedzą. Moim i Waszym gościem jest Paweł Parol. 

Cześć, Pawle! Bardzo miło mi gościć Cię w podcaście.

 

Cześć! Witam serdecznie! 

 

Z Pawłem będę dzisiaj rozmawiał o trochę egzotycznym, dosyć specyficznym języku programowania, jakim jest P4 i w ogólności o programowaniu urządzeń sieciowych.

Pawle, chciałbym Cię zapytać, zresztą tak jak czynię ze wszystkimi swoimi gośćmi, czy słuchasz podcastów? Jeśli tak, to może masz jakieś audycje do zarekomendowania?

 

Mówiąc szczerze, rzadko. Zdarzało mi się wprawdzie okazjonalnie, ale raczej nie mam takiego zwyczaju. Natomiast ja bardzo chętnie na przykład oglądam przeróżne techniczne materiały na YouTubie, takie jak TechToki, webinaria czy nagrania z konferencji albo jakichś innych eventów. Także raczej tak to u mnie wygląda.

 

Dobrze, to przejdźmy już do tej części właściwej. Porozmawiajmy o języku P4. To jest język, który wywodzi się, czy właściwie jego nazwa pochodzi, od czterech liter p występujących w pełnej nazwie, czyli Programming Protocol-Independent Packet Processors, sporo tych słów. On powstał całkiem niedawno, około roku 2014. Taka unowocześniona wersja, unowocześniony standard to jest rok 2016-2017. Więc można powiedzieć, że jak na standardy nawet panujące w IT, to stosunkowo świeżynka jest. Opowiedz proszę o tym, skąd się ten język wziął, kto go stworzył, jakim celom miał on pierwotnie służyć.

 

Tak, to jest wciąż dość świeża technologia, można powiedzieć. Sama koncepcja języka została po raz pierwszy przedstawiona w publikacji z 2014 roku, której tytuł zresztą wymieniłeś. Ja nie podejmę próby przetłumaczenia tego tytułu jeden do jednego na Polski, bo to mogłoby zabrzmieć trochę sztucznie, natomiast mam nadzieję, że w trakcie naszej rozmowy uda mi się nieco rozjaśnić, o co tutaj w ogóle chodzi. Sama nazwa P4 to jest, tak jak sam powiedziałeś zresztą, skrót od pierwszych liter wyrazów w tytule tego artykułu. Jego autorami są przedstawiciele świata akademickiego oraz dużych firm technologicznych, głównie z Kalifornii.

A mówię o tym dlatego, żeby zwrócić uwagę, że to była dość ważna publikacja. Nie był to jeden z wielu artykułów. Mówiąc niezwykle skrótowo, istotą tej pracy jest prezentacja pewnego użytecznego narzędzia, które pozwala na programowanie urządzeń sieciowych. Tym narzędziem jest właśnie język P4.

 

Powiedziałbyś szerzej na temat twórców? Oczywiście to się trochę zmieniało, mówiliśmy o tym unowocześnionym standardzie, pewnie wiele firm przyłożyło się do powstania języka P4. Ale kogo wymieniłbyś jako podstawowego twórcę czy może zespół osób, firm, które się przyłożyły najbardziej do powstania tego języka?

 

To były osoby ze środowiska uniwersyteckiego, głównie mam na myśli Uniwersytet Stanforda. Tam był zespół profesora Nicka McKeowna, który wcześniej zajmował się szeregiem projektów związanych z SDN-ami. Jego doktorantem był między innymi Martin Casado i on stworzył podwaliny pod protokół, który się nazywał OpenFlow. A poza tym inne osoby z tak zwanego Big Techu, ja nie pamiętam dokładnie nazwisk, ale to były osoby bodajże z Microsoft, chyba ktoś z Google. Tak więc tego typu osoby.

 

Dobrze, to znamy mniej więcej historię języka P4 i nie jest to język szerokiego, ogólnego przeznaczenia, jak chociażby Java czy C#. Jest to język domenowy, o tym jeszcze będziemy dzisiaj rozmawiać. Chcę Cię zapytać, skąd wzięła się koncepcja tego języka, na czym ta koncepcja w ogóle polega i na jakie zapotrzebowanie ten język odpowiada?

 

Aby to zrozumieć, należy najpierw uświadomić sobie kilka podstawowych kwestii dotyczących większości urządzeń używanych dzisiaj w sieciach, takich jak routery, switche, firewalle. One mają oczywiście różną charakterystykę funkcjonalną, ale to, co je łączy, to pewien wysokopoziomowy koncept architektoniczny. Ogólnie każde z takich urządzeń ma w środku jakiś system operacyjny, który nadzoruje działanie wszystkich układów wewnątrz. Zwykle to jest jakaś dystrybucja Linuxa bądź Unixa i w user space tego systemu uruchomiony jest tak zwany control plane.

To jest taka aplikacja, albo zbiór aplikacji, które decydują, jak ma działać data plane urządzenia, czyli ta jego logiczna część, której zadaniem jest przetwarzanie w odpowiedni sposób napływających do urządzenia pakietów. Ale żeby to było w ogóle możliwe, to w urządzeniu zamontowany jest specjalny chipset, który fizycznie realizuje wykonywanie operacji na pakietach. To jest de facto takie serce całego urządzenia, patrząc z perspektywy funkcji sieciowych, które on oferuje. 

Teraz kluczowa rzecz, chipset, o którym tutaj mówimy, to jest jednostka o pewnym z góry ustalonym zbiorze funkcjonalności. To oznacza, że gdybyśmy chcieli nasze urządzenie doposażyć na przykład w jakąś nową funkcjonalność, której chipset po prostu nie wspiera, to mamy spory problem. Możemy oczywiście, i to byłaby naturalna droga, zwrócić się z prośbą do firmy, która ten chipset wyprodukowała, żeby tę nową funkcjonalność, która jest nam potrzebna, w nim zaimplementować, ale musimy być wtedy przygotowani, że najprawdopodobniej dostaniemy taką odpowiedź, że ok, to jest możliwe, ale niestety to trochę potrwa. 

Zła informacja jest taka, że mówimy tu o czasie rzędu kilku lub nawet kilkunastu miesięcy. A jest tak dlatego, że zrobienie całego redesignu układu może być w ogólności zadaniem całkiem nie trywialnym i cały taki proces może wymagać sporo czasu. Widzimy, że czekanie tak długo może być dla nas jako dostawców urządzenia zwyczajnie nieopłacalne. Biorąc pod uwagę uwarunkowania biznesowe czy z jakichś innych powodów. W przypadku standardowego podejścia do budowy urządzeń sieciowych, można w pewnym uproszczeniu powiedzieć, że wszystko kręci się tak naprawdę wokół tego chipsetu i jego możliwości. Ten paradygmat nosi nazwę bottom-up, czyli od dołu do góry. On pokazuje pewien logiczny kierunek budowy naszego urządzenia.

Tymczasem w przypadku innych obszarów IT mamy do czynienia z zupełnie innym podejściem, które określa się mianem top-down, czyli z góry na dół. To z kolei polega na tym, że niejako arbitralnie określamy funkcjonalności jakiejś aplikacji, już na samym starcie. Potem opisujemy ją za pomocą domenowego języka programowania. Następnie kompilujemy kod, po czym jest on wykonywany przez tak zwany domenowy procesor. 

O co chodzi z tą domenowością? Tym terminem określamy po prostu główne zastosowanie danego procesora. Najpopularniejszym przykładem będzie oczywiście CPU, czyli jednostki do ogólnych zastosowań obliczeniowych. Ale są także procesory o nieco bardziej specyficznych zastosowaniach, jak choćby GPU, których architektura jest dobrze zoptymalizowana do renderowania grafiki, czy na przykład procesory sygnałowe, DSP, które oferują odpowiednią wydajność w procesie przetwarzania różnych sygnałów w czasie rzeczywistym. Dla każdego z tych przypadków dysponujemy zbiorem pewnych języków domenowych, czyli takich języków programowania czy bibliotek, dzięki którym możemy tworzyć kod dla aplikacji, które są potem wykonywane na tych jednostkach.

Dla przykładu, dla CPU będzie to cała gama języków, które dobrze znamy typu C++, Java, Python, Golang i tak dalej. W przypadku GPU będzie to na przykład OpenGL albo DirectX, a w przypadku wspomnianych procesorów DSP, może być to na przykład cały framework MATLABa. Natomiast to, z czego warto sobie zdać sprawę i co dotyczy w zasadzie każdego z wymienionych tu obszarów to jest fakt, że mamy tu do czynienia z takim sposobem tworzenia aplikacji, w którym procesor zasadniczo nie ogranicza ani nie narzuca pewnego potencjału funkcjonalnego aplikacji. I to jest właśnie istota paradygmatu top-down. 

Teraz automatycznie powstaje pytanie, jak można by w takim razie zaadoptować to podejście do urządzeń sieciowych, gdzie jak pokazywałem, bazujemy na zupełnie innym paradygmacie. Żeby to zrobić, potrzebujemy dwóch rzeczy. Po pierwsze, musimy dysponować innymi chipsetami niż dotychczas. Te nowe chipy muszą być programowalne. A po drugie, musimy dysponować frameworkiem, który pozwoli te chipy odpowiednio zaprogramować. I tutaj wreszcie dochodzimy do języka P4, który właśnie do tego nam służy.

 

Po pierwsze, musimy dysponować innymi chipsetami niż dotychczas. Te nowe chipy muszą być programowalne. A po drugie, musimy dysponować frameworkiem, który pozwoli te chipy odpowiednio zaprogramować. I tutaj wreszcie dochodzimy do języka P4, który właśnie do tego nam służy. 

 

Powiedzmy może nieco więcej na temat designu i architektury tego języka. Na czym polega to programowanie data plane’u, o którym powiedziałeś, przy użyciu P4?

 

Zacznę może od tego, że aby w ogóle móc tego języka efektywnie używać, to trzeba mieć pewne wyobrażenie o tym, jak działają sieci i jak wygląda pewien proces komunikacji między węzłami w sieciach. Takim podstawowym modelem odniesienia czy też pewną abstrakcją, której powszechnie używa się do opisu tych kwestii, jest tak zwany model OSI. To jest taki model, który wyodrębnia w systemach sieciowych pewne warstwy. Jeżeli ktoś zna się trochę na sieciach, to z pewnością wie, o czym mówię i zna to pojęcie, ponieważ to jest w zasadzie wiedza podstawowa. Każda z tych warstw w modelu OSI ma pewne swoje specyficzne znaczenie i specyficzne zadania w ramach obsługi całego procesu komunikacji między dwoma węzłami w sieci.

Żeby ta komunikacja na poszczególnych warstwach odbywała się efektywnie, dla każdej takiej warstwy określony jest zestaw tak zwanych protokołów, które służą do tego, żeby wymiana informacji właściwych dla danej warstwy odbywała się w sposób zestandaryzowany. Wymienię może kilka nazw, które myślę, że każdemu słuchaczowi obiły się kiedyś o uszy. Nawet jeżeli ktoś nie zajmuje się sieciami na co dzień, to na pewno słyszał takie pojęcia, jak choćby Ethernet, IP, TCP, UDP, DHCP i tak dalej. To są właśnie przykłady popularnych protokołów komunikacyjnych. 

Pakiety, które przesyłane są w sieciach w postaci ciągu bitów de facto, mają swoją pewną strukturę, w której wyodrębnić można między innymi zestaw tak zwanych nagłówków. A każdy pojedynczy nagłówek, to taki fragment tego ciągu bitów, który zawiera pewne charakterystyczne informacje dla danego protokołu. Dla przykładu, pakiet może zawierać nagłówek Ethernetowy, dalej nagłówek protokołu IP, nagłówek protokołu TCP i tak dalej. 

Natomiast samą istotą procesu przetwarzania pakietów w jakimkolwiek urządzeniu sieciowym jest odczytywanie informacji zawartych w nagłówkach i wykonywanie na tej podstawie akcji, jak modyfikacja wartości poszczególnych pól w danym nagłówku czy przekierowanie pakietu na wskazany interfejs fizyczny. To się zwykle odbywa w postaci tak zwanego pipeline’u, czyli pewnej logicznej sekwencji tablic, które po kolei odwiedza pakiet. A każda taka tablica ma zwykle jakąś swoją charakterystyczną rolę, na przykład może się zajmować tylko nagłówkami określonego typu, czyli ma jasno zdefiniowane, jakie dokładnie pola w nagłówkach ma oglądać i jakie na tej podstawie decyzje podejmować.

W urządzeniach sieciowych zbudowanych na bazie tradycyjnego podejścia, cały ten schemat przetwarzania jest z góry ustalony na poziomie chipsetu i nie można go zmienić. Natomiast gdy użyjemy chipów programowalnych, to za pomocą języka P4 możemy cały proces przetwarzania zdefiniować po swojemu. Co to oznacza? To oznacza, że my decydujemy, ile ma być tablic i jakie one mają być. Decydujemy, jaka ma być kolejność ich odwiedzania przez pakiety, decydujemy, jakie nagłówki, jakie konkretne pola w nagłówkach będziemy analizować w poszczególnych tablicach. Sami też określamy wszystkie dostępne akcje do wykonania w każdej tablicy. Oczywiście też definiujemy szczegółowo mechanikę działania każdej akcji. To jest w zasadzie wszystko przedmiotem implementacji. I tu właśnie tkwi największa siła P4, bo nam chodzi o tę elastyczność.

Co więcej, warte podkreślenia jest to, że P4 nie określa żadnego predefiniowanego zbioru nagłówków, na których możemy operować. Struktura wszystkich nagłówków, nawet tych, które się odnoszą do popularnych protokołów musi być explicite zdefiniowana przez programistę w każdym programie P4. To się odbywa w takim specjalnym bloku kodu, który określany jest mianem parsera. To założenie języka ma ciekawy wymiar użytkowy, ponieważ dzięki temu, możemy za pomocą P4 testować nawet, jak zachowują się zupełnie customowe protokoły, które zresztą sami możemy sobie projektować. 

A jak już jesteśmy przy samym języku, to wszystkie te zagadnienia, o których przed momentem wspomniałem, mówiąc tutaj o swobodzie w definiowaniu zachowania całego data plane’u, czyli tablic, akcji, kolejności wyzwalania pewnych rzeczy, to wszystkie te aspekty w języku P4 odwzorowane są za pomocą słów kluczowych, takich jak table, action, control, parser, apply. W tej nowszej wersji języka, która nosi nazwę P4-16, mamy bodajże około czterdziestu takich słów kluczowych. Używając tych słów w kodzie po prostu wskazujemy, jakie struktury czy jakie elementy będziemy w danej chwili definiować. Tak to wygląda.

 

Ok, rozumiem. To jest faktycznie dosyć szeroki wachlarz różnych możliwości, o których powiedziałeś. Wiadomo, że one muszą być wykorzystywane na jakimś sprzęcie, na jakichś urządzeniach. Mówiłeś, że urządzenia sieciowe są naturalnym targetem do uruchamiania programów w P4. Chcę Cię zapytać, jakie urządzenia sieciowe? Dowolne czy może jest jakiś zakres tych urządzeń? Czy język P4 sięga też dalej, czy wychodzi poza urządzenia sieciowe, czy to jest jego jedyna domena?

 

Najkrócej można by odpowiedzieć, że my możemy przy pomocy P4 programować w zasadzie wszystkie urządzenia, które zawierają programowalne chipsety wspierające tę technologię. Natomiast w praktyce, można wyodrębnić trzy grupy takich urządzeń, a w zasadzie trzy grupy tak zwanych targetów. W nomenklaturze P4 urządzenia, na które piszemy kod, nazywamy targetami.

Pierwszą grupą będą tak zwane urządzenia wieloportowe. Chodzi o takie urządzenia, które instaluje się zwykle w centrach danych, w serwerowniach bądź obiektach operatorów telekomunikacyjnych. Umownie, w ramach pewnej konwencji, nazywamy je ogólnie switchami. Przy czym należy od razu zaznaczyć, że ich funkcjonalność może być znacznie szersza, niż tradycyjnych switchy L2. 

Klasyczne urządzenia sieciowe, wszystkie te, które są oparte o chipsety o tej ustalonej funkcjonalności, czyli budowane według tradycyjnego podejścia, mają już niejako z definicji wpisaną jakąś specjalizację. Na przykład, jeżeli urządzenie jest routerem, to będzie realizować routing, bo do takiej pracy zostało zaprojektowane i zoptymalizowane. Jeżeli urządzenie jest switchem L2, to będzie działać jako przełącznik. Jeżeli jest firewallem, to będzie robiło firewalling. Możemy wymieniać dalej. 

Natomiast w przypadku urządzeń wspierających P4, ten umowny switch wieloportowy raz będzie routerem, innym razem będzie zoptymalizowany do działania jako switch L2, jak go przeprogramujemy. Jeszcze innym razem będzie firewallem lub urządzeniem BNG albo DPI-em albo w ogóle mieszanką kilku funkcjonalności na raz. 

 

Natomiast w przypadku urządzeń wspierających P4, ten umowny switch wieloportowy raz będzie routerem, innym razem będzie zoptymalizowany do działania jako switch L2, jak go przeprogramujemy. Jeszcze innym razem będzie firewallem lub urządzeniem BNG albo DPI-em albo w ogóle mieszanką kilku funkcjonalności na raz. 

 

Dlaczego tak jest? Dlatego, że my to urządzenie możemy wielokrotnie reprogramować przy użyciu języka P4, czyli tworzyć zupełnie arbitralną strukturę jego data plane’u, która raz będzie miała jakiś określony przez nas design, czyli wszystkie te tablice, akcje, jakie chcemy na daną chwilę. Innym razem, po przeprogramowaniu, będzie to inny design w zależności od tego, jakie mamy na dany czas potrzeby. I to jest jedna, taka duża grupa urządzeń.

Druga grupa targetów, o których warto wspomnieć, to są tak zwane SmartNICi. To jest rodzaj takich inteligentnych kart sieciowych, które można zamontować na przykład w serwerze. Nie wchodząc już w jakieś duże zawiłości techniczne, to są po prostu takie karty, które oferują dużo większe możliwości niż standardowe karty sieciowe, ponieważ można w ogólności uruchomić na nich różne funkcje sieciowe. Obecnie na rynku dostępnych jest już kilka kart, które oferują także wsparcie dla technologii P4, co oznacza, że możemy po prostu programować je przy użyciu P4.

Robiliśmy jakiś czas temu nawet taki przegląd rozwiązań dla tego segmentu rynku. Wyniki opisaliśmy na naszym blogu technologicznym. Gdyby ktoś chciał pogłębić ten temat, to serdecznie zapraszam do odwiedzenia oficjalnej witryny CodiLime i zapoznania się z tym blog postem. 

Jest jeszcze trzecia grupa rozwiązań wspierających P4, którą bym wyodrębnił. W zasadzie to nie są urządzenia fizyczne, tylko switche software’owe, czyli takie wirtualne urządzenia sieciowe, do których możemy podłączać wirtualne maszyny czy kontenery. Także w tej grupie istnieją takie, które możemy programować przy użyciu języka P4.

Przy okazji myślę, że warto jeszcze wspomnieć o jednej, bardzo istotnej kwestii, która związana jest z urządzeniami P4. Standard P4-16, czyli ta nowsza wersja języka, wprowadza takie pojęcie, jak model architektury. O co tutaj chodzi? Każde urządzenie w ramach architektury swojego data plane’u może mieć różne bloki funkcjonalne. Tak naprawdę nawet nie wszystkie z nich muszą być programowalne w P4. Zachowania niektórych bloków w tym procesie przetwarzania pakietów mogą być po prostu ustalone z góry i wtedy to nie podlega żadnym modyfikacjom ze strony programisty. 

To jest w dalszym ciągu akceptowalne, ponieważ nie wszystkie bloki w urządzeniu muszą być programowalne, aby można było mówić, że ono wspiera P4. Wystarczy, aby istniały takie, które programować się da. Ale programista musi o tym wiedzieć, musi dysponować pewnym widokiem, czyli jak wygląda wysokopoziomowy schemat data plane’u targetu. Ile tam jest łącznie wszystkich bloków funkcjonalnych, które są programowalne, a które nie są oraz jakie funkcje pełnią te, których nie można programować.

Pewną abstrakcją, która dostarcza tych informacji, jest tak zwany model architektury P4. To jest zadanie producenta urządzenia, który musi zadeklarować, z którym modelem jego rozwiązanie jest zgodne. Ponieważ istnieją zarówno standardowe czy quasi standardowe modele i takie zupełnie własnościowe, czyli projektowane przez producentów.

 

Rozumiem. Powiedziałeś o programiście, jestem ciekaw, jak się programuje w takim języku na co dzień. Jakie narzędzia programiści mają do dyspozycji? Czy są może dedykowane IDE, coś co by ułatwiało tworzenie kodu w P4?

 

Standardowy proces tworzenia programu P4 można opisać następująco. Po pierwsze, musimy wiedzieć, co jest naszym targetem. Czy to jest switch, czy to jest SmartNIC, a może jeszcze coś innego? Od razu sprawdzamy ten model architektury, o którym wspomniałem, który ten target wspiera. Jest to naturalnie potrzebne, żeby stwierdzić, jakie dokładnie bloki funkcjonalne naszego data plane’u możemy oprogramować, jakie mamy możliwości, jakie ograniczenia. 

Kiedy już to wszystko wiemy, wtedy dopiero przystępujemy do pisania kodu w języku P4. Standardowo można to robić w dowolnie wybranym przez siebie edytorze. Najlepiej w takim, który posiada wsparcie dla języka P4, czyli potrafi rozpoznać jego składnię, słowa kluczowe dla większej wygody pisania kodu. Jest kilka darmowych edytorów, które takie wsparcie dla P4 oferują. Kiedy nasz kod jest już gotowy, należy go skompilować. Kompilator powinien być dostarczony przez producenta urządzenia, na które piszemy nasz program. Jeśli kompilacja zakończy się sukcesem, jej produkty należy wgrać na urządzenie docelowe. Używam liczby mnogiej, ponieważ w szczególności może to być więcej niż jeden plik. Na przykład jakiś plik binarny plus opcjonalnie dodatkowe pliki konfiguracyjne.  Ta sekwencja kroków, o której tutaj powiedziałem, jest taką ogólną procedurą tworzenia programów w języku P4. 

Natomiast skoro zapytałeś o rozwiązania typu IDE, to z tego, co wiem, niektórzy dostawcy urządzeń wspierających P4 rzeczywiście oferują taki software typu studio, który zawiera dedykowany edytor, zintegrowany builder czy kompilator, czy też inne dodatkowe toole. Niezależnie od tego, jakich narzędzi będziemy używać, chodzi nam o to, aby napisać taki kod, który da się skompilować i aby odpowiednie pliki wykonywalne osadzić na urządzeniu docelowym. To w zasadzie tyle od strony formalnej. Natomiast czy nasz program działa zgodnie z naszym oczekiwaniem pod względem funkcjonalnym, to już jest zupełnie inne pytanie. Tego się dowiadujemy w fazie testów.

 

Niezależnie od tego, jakich narzędzi będziemy używać, chodzi nam o to, aby napisać taki kod, który da się skompilować i aby odpowiednie pliki wykonywalne osadzić na urządzeniu docelowym. To w zasadzie tyle od strony formalnej. Natomiast czy nasz program działa zgodnie z naszym oczekiwaniem pod względem funkcjonalnym, to już jest zupełnie inne pytanie. Tego się dowiadujemy w fazie testów. 

 

Przejdźmy może do testowania, bo najczęściej w nowoczesnym software developemencie jest tak, że jeśli mówimy o programowaniu, to mówimy też o testowaniu naszych rozwiązań. Jestem ciekaw, jak to wygląda w przypadku P4, czy możemy na etapie pisania kodu w jakiś sposób przeprowadzić jego testy? Z tego co zrozumiałem, wydaje mi się, że może być niezbędne uruchomienie tego napisanego i skompilowanego kodu na urządzeniu fizycznym, żeby sprawdzić tak na sto procent poprawność napisanego przez nas oprogramowania. Czy może tutaj się mylę i są jakieś rozwiązania wspomagające testowanie już na etapie pisania kodu?

 

Odpowiedź brzmi – to jest jedna z ulubionych odpowiedzi ludzi z IT, zresztą chyba nie tylko – to zależy. Znowu wraca kwestia tak zwanych modeli architektury, które wspierają urządzenia. Jest na przykład taki pseudo standardowy model, który nazywa się V1 model i jeśli jakieś fizyczne urządzenie sieciowe, na które piszemy nasz program w P4 wspiera ten model, to możemy sobie bardzo ułatwić wtedy fazę testowania. A dzieje się tak dlatego, że ten model jest wspierany przez takiego software’owego switcha, który się nazywa BMv2. To jest bardzo popularne rozwiązanie do budowania testowych setupów P4. Wtedy w praktyce możemy zastosować takie podejście, że najpierw testujemy nasz program na tym software’owym switchu BMv2, a dopiero w fazie końcowej już na fizycznym urządzeniu.

Ale to jest taki specyficzny przypadek, ogólnie nie zawsze jest to możliwe. W niektórych przypadkach może się okazać, że trzeba będzie testować od początku na fizycznym sprzęcie. A sam proces testowania sprowadza się do tego, że my musimy ocenić, jak zachowuje się zaprojektowany przez nas mechanizm przetwarzania pakietów tak naprawdę. 

Jak pamiętamy, mam nadzieję, składają się na niego przede wszystkim stworzone przez nas tablice i tak zwane akcje, które są w nich wyzwalane na rzecz tych trafiających do tych tablic pakietów. Tablice są na początku zupełnie puste, więc pierwsze, co musimy zrobić, to utworzyć w nich odpowiednie wpisy. Każdy taki wpis mówi nam, jaka konkretnie kombinacja wartości pól w nagłówkach pakietów nas interesuje, a ponadto, którą ze zdefiniowanych przez nas operacji mamy na takim pakiecie zrealizować oraz z jakimi parametrami dokładnie. Mówiąc obrazowo, musimy zasilić te tablice odpowiednimi danymi, żeby one wiedziały, co dokładnie zrobić z konkretnymi już pakietami, kiedy one już do nich napłyną.

Ten proces się nazywa populacją tablic danymi. Ona się może odbywać w różnoraki sposób. Możemy na przykład zrobić jakiś statyczny plik konfiguracyjny, który będzie za to odpowiadał albo możemy napisać zewnętrzny moduł software’owy, który będzie dynamicznie dodawał bądź zmieniał wpisy w tablicach. 

Kolejna istotna kwestia to same pakiety, bo należy pamiętać, że musimy je jakoś wygenerować. I tutaj opcji też jest wiele. Ogólnie można korzystać z software’owych bądź fizycznych nawet generatorów ruchu, jeśli ktoś ma taką możliwość. Ewentualnie generować pakiety przy pomocy dedykowanych bibliotek programistycznych. Na przykład stosunkowo łatwo napisać takie skryty w Pythonie.

Jeżeli natomiast cały nasz setup jest stricte software’owy, to może się okazać, że dla naszych konkretnych przypadków testowych zupełnie wystarczający będzie jakiś emulator topologii sieciowych typu Mininet, który jest takim wygodnym narzędziem do testowania różnych elementów sieciowych w środowisku wirtualnym czy software’owym po prostu. Tak więc wszystko tutaj sprowadza się do określenia, jakie są nasze potrzeby i jakie są możliwości.

 

Ok, rozumiem. Chciałbym Cię jeszcze dopytać trochę o zastosowania i cele używania P4. Wyobrażam sobie, że jeśli mamy te różne protokoły z modelu OSI, które przywołałeś, to one są już jakoś ustalone, w sensie funkcjonują tam zasady panujące nieraz już od dziesięcioleci. Po co chcielibyśmy programowo w to jeszcze ingerować, skoro moglibyśmy tę implementację zawrzeć na stałe w krzemie? Szersze pytanie brzmi, jakie są ogólnie zastosowania P4? Czy to jest tylko research i developement, czy może faktycznie jakieś produkcyjne rozwiązania są na szerszą skalę tworzone?

 

Zastosowania mogą być przeróżne. Pierwszym przykładem może być wykorzystanie P4 do optymalizacji działania sieci w data center. Tutaj mam na myśli tak zwany Leaf-spine fabric, to jest taka specyficzna topologia, która składa się z dwóch grup switchy o pewnej krotności i rozpiętych między nimi połączeniach fizycznych. Jest to bardzo popularne rozwiązanie w dzisiejszych centrach danych. Taki szkielet sieciowy można zbudować na przykład na bazie tradycyjnych urządzeń dostępnych na rynku, które mają z zasady jakiś zestaw dostępnych funkcjonalności. Potem te funkcjonalności wykorzystujemy, aby zrealizować całą sieciową inżynierię ruchową w naszym data center, którą sobie wcześniej określiliśmy czy zaprojektowaliśmy. 

W wielu przypadkach może się okazać, że do obsługi wszystkich wzorców czy schematów ruchowych, które będą w praktyce występować w tym naszym data center, potrzebne jest znacznie mniej albo trochę mniej funkcji niż oferują nam urządzenia sieciowe, które wcześniej kupiliśmy. Sporego wachlarza funkcji możemy w ogóle nie potrzebować, mimo że za to tak naprawdę zapłaciliśmy. Tutaj pojawia się opcja wykorzystania P4. Zamiast tego można użyć urządzeń z programowalnymi chipami, w których za pomocą języka P4 zaprojektujemy takie działanie data plane’u, które będzie dobrze zoptymalizowane do naszych bieżących potrzeb. Przetwarzanie pakietów będzie wówczas oparte tylko na tych mechanizmach, które są nam naprawdę potrzebne. 

 

Sporego wachlarza funkcji możemy w ogóle nie potrzebować, mimo że za to tak naprawdę zapłaciliśmy. Tutaj pojawia się opcja wykorzystania P4. Zamiast tego można użyć urządzeń z programowalnymi chipami, w których za pomocą języka P4 zaprojektujemy takie działanie data plane’u, które będzie dobrze zoptymalizowane do naszych bieżących potrzeb. Przetwarzanie pakietów będzie wówczas oparte tylko na tych mechanizmach, które są nam naprawdę potrzebne. 

 

Ale to jest tylko jeden aspekt, spójrzmy na kolejny. Wyobraźmy sobie teraz, że z czasem w naszym data center będziemy obsługiwać nowe workloady o pełnej specyfice. Może się okazać, że aby to zrobić w wydajny sposób, będzie potrzebne pewne przedefiniowanie naszej dotychczasowej sieciowej inżynierii ruchowej. Jeśli mamy urządzenia programowalne, to jesteśmy w stanie łatwo to zrobić, po raz kolejny stworzyć za pomocą P4 taki optymalny design data plane’u, naszej sieci data centerowej. To jest jeden przykład potencjalnych zastosowań.

Drugi przykład zastosowania związany jest z koncepcją NFV, czyli wirtualizacją funkcji sieciowych. To jest obecnie jeden z bardzo ważnych trendów w sieciach. Gdyby ktoś słyszał o tym po raz pierwszy, to nadmienię tylko, że w NFV chodzi o przeniesienie funkcji sieciowych z dedykowanego hardware’u na uniwersalne serwery, jakie stosuje się w IT. Wtedy te funkcje nazywamy tak zwanymi VNF-ami, czyli wirtualnymi funkcjami sieciowymi. I ten paradygmat V ma bardzo dużo zalet i to nie ulega kwestii.

Natomiast w dalszym ciągu jest cały szereg aspektów związanych z pewną efektywnością deploymentów opartych o tę koncepcję. Mam na myśli aspekty wydajnościowe przede wszystkim. Aby uzyskać zadowalający performance niektórych funkcji w pewnych konkretnych use case’ach, jedną z metod, jaką się stosuje jest tak zwany offloading, czyli przeniesienie niektórych jednostkowych funkcji z powrotem do hardware’u. Może to być przeniesienie całościowe lub częściowe. To drugie, można powiedzieć takie hybrydowe podejście, polega na wyodrębnieniu z oryginalnej funkcji dwóch oddzielnych części. Jedna część dalej jest realizowana jako funkcja wirtualna, natomiast ta druga, ta bardziej krytyczna ze względu na performance, jest wtedy wykonywana bezpośrednio na dedykowanym sieciowym hardwarze.

Nie trudno zgadnąć, że niezależnie od przypadku, aby móc to robić skutecznie i elastycznie, to potrzeba hardware’u programowalnego, takiego jak jakiś switch, który akurat mamy czy SmartNIC i wtedy możemy zrealizować na nich żądaną funkcjonalność tworząc po prostu odpowiedni kod w P4. Łatwo będzie także taki hardware potem przeprogramować, gdyby się okazało, że z czasem zmieniła nam się architektura albo charakter naszego deploymentu i trzeba będzie za chwilę offloadować jakąś inną funkcję.

Kolejny przykład obszaru, w którym P4 jest niezwykle użytecznym narzędziem, to jest tak zwana koncepcja INT. Ten skrót się rozwija jako inboud network telemetry  i tutaj chodzi o stworzenie takiego wewnętrznego systemu telemetrycznego działającego w jakimś konkretnym segmencie sieci, który będzie gromadził cały szereg metadanych o pakietach na etapie przetwarzania ich w poszczególnych węzłach sieci, na całej ścieżce routingowej. To są na przykład takie informacje, jak opóźnienie, którego doznaje pakiet w danym węźle, zajętość kolejki, do której trafia w urządzeniu, obciążenie na łączu, z którego opuszcza urządzenie i tego typu informacje czy parametry. 

Taki system może być bardzo użytecznym narzędziem, które pozwala na uzyskanie dużego wglądu w to, co się aktualnie dzieje w sieci. Ale nie będziemy teraz o tym mówić. Ten system można zrealizować na kilka sposobów. Jednym z nich jest enkapsulowanie tych wymienionych rodzajów metadanych w specjalne nagłówki, a następnie doklejenie ich w każdym pakiecie do jego nagłówków protokołowych i potem przesyłanie pakietu do kolejnego węzła, który zrobi to samo. Żeby to było możliwe, trzeba odpowiednio zaprogramować urządzenia, bo standardowe urządzenia sieciowe tak nie działają, żeby uzyskać takie zachowania, o jakie nam chodzi. Nie będzie wielkim zaskoczeniem pewnie, jak powiem, że świetnie nadaje się do tego właśnie P4. 

 

Domyślam się.

 

Podałem tylko kilka przykładów zastosowań, może być ich znacznie więcej. To jest kwestia identyfikacji potrzeb z jednej strony, a z drugiej, powiedzmy, pewnej kreatywności.

 

Wobec tego, jak wygląda rozwój tego języka? Faktycznie tych obszarów jest coraz więcej, domyślam się, że będzie coraz więcej. Czy jest jakaś jedna instytucja, firma, organizacja, która stoi za rozwojem, czy też może jest to bardziej rozwój wychodzący od community? Kto zarządza tym projektem? Jakbyś mógł tutaj kilka słów powiedzieć.

 

Obecnie język jest rozwijany pod auspicjami Open Networking Foundation, w skrócie ONF. To jest organizacja typu non-profit, która od wielu już lat działa jako główny promotor idei open networkingu. Wspiera rozwój koncepcji SDN, czyli Software Defined Networking i prowadzi szereg innowacyjnych projektów z tego obszaru. Są to inicjatywy, które kreślą ciekawe koncepcje architektoniczne dla sieci oraz wytwarzają związane z nimi oprogramowanie czy wręcz frameworki technologiczne. Przykładem może być kontroler SDN-owy ONOS czy cała gama rozwiązań bazujących na tak zwanej koncepcji Open Court. Są oczywiście projekty, w których wykorzystywana jest też technologia P4, jak choćby Stratum czy Trellis. To jest taka główna organizacja, która stoi za rozwojem języka.

Ważnym źródłem z punktu widzenia samego języka, jest również oficjalna witryna p4.org, na której znajdują się oficjalne specyfikacje i szereg innych interesujących materiałów. Jest również bardzo użyteczny zbiór repozytoriów na GitHubie o nazwie p4lang, który też jest publicznie dostępny. Natomiast community, z tego co mi wiadomo, aktualnie liczy ponad sto organizacji, w tym głównie są to firmy technologiczne, a resztę stanowią uniwersytety. 

 

Jak byś ocenił popularność tego języka w branży sieciowej? Czy to jest taki standard, czy też może języki szerszego zastosowania C, Golang, Python jednak królują, a to jest taki dodatek w wąskich zastosowaniach?

 

W moim odczuciu, w tej chwili nie można jeszcze mówić o powszechności ani masowej popularności. Myślę, że P4 dopiero ją zdobywa. W dalszym ciągu, to trzeba przyznać, jest stosunkowo mało urządzeń, które wspierają P4. Musimy pamiętać, że to jest jednak zupełna zmiana paradygmatu myślenia o dostarczaniu funkcji sieciowych. Do tej pory tworzonych było na świecie sporo setupów z wykorzystaniem P4 o charakterze głównie demonstracyjnym, czyli typu proof-of-concept, aby pokazać, że to rzeczywiście może działać. Z tego co mi wiadomo, ONF podejmuje obecnie wysiłki mające na celu zachęcenie różnych podmiotów do uruchamiania triali sieciowych, w których wykorzystywana jest technologia P4, aby testować ją w środowisku zbliżonym do produkcyjnego bądź nawet produkcyjnym w małej skali. Zobaczymy, jak się rozwinie sytuacja. 

 

Rozumiem. Przedstawiając Cię, mówiłem, że kierujesz pracami działu R&D w CodiLime .Czy zajmujecie się tam też projektami związanymi z P4?

 

Tak, w zeszłym roku chociażby zrealizowaliśmy w naszym R&D projekt, którego jednym z kluczowych założeń było właśnie użycie P4. Stworzyliśmy pewien setup, którego jednym z elementów sieciowych był SmartNIC i zachowanie tego SmartNICa programowaliśmy właśnie przy pomocy języka P4. Ważnym aspektem naszego rozwiązania była integracja tego SmartNICa z zewnętrznym kontrolerem SDN-owym, którym był wspomniany ONOS. Wybraliśmy ONOS-a ponieważ chcieliśmy mieć sprawdzone narzędzie, dzięki któremu moglibyśmy sterować działaniem SmartNICa w naszym setupie już w fazie runtime, czyli w czasie rzeczywistym. Ponieważ integracja bezpośrednio z różnych powodów nie była możliwa, stworzyliśmy specjalny software’owy adapter, który to zrealizował.

Jak wspomniałem, ONF bardzo dużo robi w obszarze P4, natomiast do tej pory wszystkie ich projekty dotyczyły głównie switchy wieloportowych. My natomiast, przynajmniej według mojej najlepszej wiedzy, zrealizowaliśmy jedną z pierwszych na świecie integracji SmartNICa wspierającego P4 z kontrolerem ONOS, o ile w ogóle nie pierwszą na tamten czas. Była to dla nas na pewno duża satysfakcja. Nagraliśmy zresztą webinarium prezentujące to rozwiązanie, jest ono publicznie dostępne na naszym kanale na YouTubie, więc serdecznie zapraszam wszystkich zainteresowanych do zapoznania się z tym materiałem.

 

ONF bardzo dużo robi w obszarze P4, natomiast do tej pory wszystkie ich projekty dotyczyły głównie switchy wieloportowych. My natomiast, przynajmniej według mojej najlepszej wiedzy, zrealizowaliśmy jedną z pierwszych na świecie integracji SmartNICa wspierającego P4 z kontrolerem ONOS, o ile w ogóle nie pierwszą na tamten czas. Była to dla nas na pewno duża satysfakcja. 

 

Super, wielkie gratulacje. Parę razy, pośrednio albo bezpośrednio, wspomniałeś, że obszar, zakres sieci SDN to jest takie naturalne miejsce, gdzie można spotkać język P4. Oczywiście odsyłam też do 59. odcinka podcastu z Krzysztofem Wróblem, gdzie więcej na temat tych sieci mówiliśmy, jeśli ktoś chciałby się doszkolić, dowiedzieć więcej. Natomiast chcę Cię zapytać, jaką rolę ma język P4 na mapie rozwiązań SDN?

 

Myślę, że z koncepcją SDN jest pewna trudność polegająca na tym, że kiedy dwie osoby zaczynają o niej rozmawiać, to może się szybko okazać, że rozumieją to pojęcie nieco inaczej. To jest paradoksalnie naturalna rzecz w tym przypadku, ponieważ dzisiaj nie ma jednej obowiązującej definicji SDN. Pod tym pojęciem kryje się tak naprawdę pewien zbiór technik i mechanizmów i żeby lepiej zrozumieć, o czym mówimy, zacznę od takiej próby wskazania trzech głównych obszarów w ramach SDN.

Pierwsza grupa to jest tak zwany Open SDN, czyli pewien koncept zakładający, że w urządzeniu sieciowym dokonujemy wyraźnej separacji data plane’u oraz control plane’u, czyli tej logiki, która steruje zachowaniem data plane’u. To nie wszystko, control plane w tym przypadku jest realizowany w postaci zupełnie zewnętrznej aplikacji. Mówiąc obrazowo, jest zabrany z urządzenia. Co więcej, zdefiniowany jest standardowy interfejs czy protokół do komunikacji między control planem a data planem. Ten aspekt, czyli właśnie ta komunikacja przestaje być już czymś specyficznym dla danego urządzenia czy linii produktowej urządzeń pochodzącej od danego dostawcy, tylko zostaje to niejako otworzone. Doskonałym przykładem jest tutaj standard OpenFlow.

Drugi rodzaj SDN-a nazywany jest często jako SDN oparty o API. W tym przypadku, w przeciwieństwie do tego pierwszego typu, nie wyodrębniamy żadnego control plane’u z urządzenia, natomiast to, co robimy, to implementujemy w urządzeniu pewne nowe mechanizmy na poziomie tak zwanego interfejsu północnego, które pozwalają sterować i zarządzać urządzeniem w sposób dużo bardziej wygodny i zautomatyzowany niż przy użyciu klasycznych metod typu CLI, SNMP czy TL1. W ramach tego SDN-a opartego o API mamy cały szereg rozwiązań, które dużo lepiej się do tego nadają, jak choćby Netconfig, jak REST API, jak rozwiązania oparte o gRPC czy nawet natywne API programistyczne. 

Trzecia popularna odmiana SDN-a to tak zwane overlay networking i on jest rozpowszechniony zwłaszcza w centrach danych i wszelkiej maści środowiskach wirtualnych. Tutaj z kolei chodzi o mechanizm, który pozwala w sposób automatyczny tworzyć i konfigurować takie wirtualne sieci, które są rozpinane pomiędzy na przykład wirtualnymi maszynami. Wykorzystuje się do tego mechanizmy tunelowania ruchu sieciowego, takie jak VxLAN, NVGRE albo jeszcze inne. Ponieważ takie sieci tworzone są ponad istniejącą infrastrukturą sieciową, to mówimy o nich jako o sieciach overlayowych. 

Zamykając ten krótki przegląd rozwiązań SDN-owych można dość łatwo zauważyć, że mimo iż wszystkie one są nazywane SDN-ami, to mogą się różnić znacząco w kontekście swojej mechaniki działania czy wręcz koncepcyjnie. Teraz pytanie, gdzie zatem umiejscowić P4 w tym wszystkim? Na pewno najbliżej będzie do tego pierwszego typu SDN-ów, którego reprezentantem jest wspomniany OpenFlow. Zresztą publikacja, o której rozmawialiśmy na samym początku naszej rozmowy, czyli ta, w której została przedstawiona idea języka P4, wprost określa P4 jako pewną ewolucję standardu OpenFlow. W przypadku OpenFlow możemy również bardzo granularnie przetwarzać pakiety na poziomie data plane’u, ale tam bazujemy mimo wszystko na pewnym skończonym zbiorze jednostkowych akcji, które możemy wykonywać oraz skończonym zbiorze pól w nagłówkach pakietów, które możemy analizować. P4 natomiast jest pod tym względem narzędziem znacznie potężniejszym, ponieważ tutaj nie ma takich ograniczeń.

 

Jeśli ktoś byłby zainteresowany poznaniem tej technologii, takiego języka, to, według Ciebie, od czego mógłby zacząć swoją przygodę, skąd czerpać wiedzę, jak się uczyć? Co mógłbyś poradzić na początku?

 

Tak jak już sobie powiedzieliśmy dzisiaj, P4 nie jest językiem ogólnego przeznaczenia, tylko językiem specyficznym w tym sensie, że on jest adresowany do konkretnych zastosowań. W tym przypadku są to zastosowania sieciowe. Chcąc programować w P4, trzeba mieć jakieś elementarne pojęcie o sieciach, czyli na pewno o warstwach wspomnianego wcześniej modelu OSI i reprezentatywnych dla tych warstw protokołach. Należy właściwie rozpoznawać, co jest nagłówkiem, a co jest danymi w strukturze danego protokołu i tak dalej. Co jeszcze? Warto umieć odróżniać routing od switchingu, warto wiedzieć, czym są tak zwane porty w warstwie transportowej. Przy czym mówiąc to wszystko, ja nie chciałbym stwarzać takiego wrażenia, że to musi być od razu wiedza ekspercka. Oczywiście taka wiedza bardzo się przydaje, to jest jasne, ale żeby zacząć przygodę z P4, to w moim odczuciu można bazować po prostu na pewnej wiedzy fundamentalnej w tym zakresie. Podsumowując ten aspekt, jest jakiś próg wejścia, patrząc z perspektywy wiedzy o sieciach, i nie jest on zupełnie zerowy.

Drugi wymiar tych, nazwijmy to wymagań wstępnych, to jest takie elementarne rozumienie, czym jest w ogóle programowanie. Aczkolwiek myślę, że akurat ten warunek spełnić jest dzisiaj bardzo łatwo, bo chyba każdy, kto obraca się dziś w branży IT ma o tym przynajmniej jakieś elementarne pojęcie. Zapytałeś także, jak praktycznie można zacząć swoją przygodę z P4. Ja myślę, że dobrym startem będzie GitHub, a konkretnie ten wspomniany zbiór repozytoriów o nazwie p4lang. On zawiera między innymi dość użyteczne tutoriale, a także takie środowisko, które nazywa się p4app. To jest rodzaj takiego sendboxa, który można sobie, mówiąc żargonem, postawić lokalnie na swoim laptopie na przykład i można w nim pisać programy P4 i testować je w takim emulowanym środowisku sieciowym. Równolegle można przyswajać sobie oficjalną specyfikację języka, na przykład tę dostępną na stronach p4.org, by po prostu lepiej go poznawać, coraz lepiej rozumieć. 

 

Jasne. A jak wygląda zapotrzebowanie na specjalistów znających język P4, jak wygląda rynek pracy? Czy w ofertach pracy w ogóle pojawia się takie wymaganie, czy to jest raczej nice to have?

 

Zacząłbym może od obserwacji  nieco ogólniejszej natury. Otóż w moim odczuciu, dzisiaj wyzwania stojące przed inżynierem zajmującym się sieciami są trochę inne niż jeszcze dziesięć lat temu. Kiedyś nacisk kładziony był przed wszystkim na dobrą znajomość protokołów i pewną biegłość przy konsoli, żeby po prostu sprawnie konfigurować urządzenia. A dzisiaj, kiedy działamy już w paradygmacie SDN, NFV, to ten tak zwany skillset sieciowca powinien być znacznie szerszy. Dedykowane urządzenia fizyczne nie są już jedynymi elementami, które dostarczają funkcji sieciowych. Tak zwany deployment tych funkcji jest obecnie realizowany zarówno na komponentach fizycznych, jaki i zwirtualizowanych. Wobec tego, trzeba dobrze wiedzieć, jak działają takie technologie, jak chociażby Docker, Kubernetes, OpenStack, żeby móc te dwa światy jakoś ze sobą połączyć i swobodnie się w tym poruszać. 

Co więcej, należy również rozumieć i znać techniki z rodziny SDN. Na przykład przydaje się bardzo umiejętność pracy z różnymi kontrolerami i platformami SDN-owymi, znajomość tak zwanych swap boundowych mechanizmów, SDN-owych, takich jak OpenFlow, NETCONF, towarzyszących im metod modelowania danych. Przydaje się umiejętność programowania w Pythonie czy Golangu albo w jakimś jeszcze innym języku, a nawet praktyczne umiejętności w zakresie różnych technik DevOpsowych. 

Myślę, że osoby dysponujące taką wiedzą i umiejętnościami, przy jednoczesnym posiadaniu tego rdzennego backgroundu sieciowego są po prostu na rynku poszukiwane. W tym kontekście znajomość P4 jest po prostu dodatkowym plusem. Tym bardziej, że według mojej wiedzy takich specjalistów jest wciąż dosyć mało. Być może w środowisku sieciowym sporo osób słyszało już o P4, ale przypuszczam, że wciąż niewielu jest takich, którzy dysponują pewnymi praktycznymi umiejętnościami na tym polu. Tak więc, w moim odczuciu, zwyczajnie warto się tego uczyć.

 

Rozumiem. Czy jest jakiś język, który znasz, który może być składniowo, koncepcyjnie podobny do P4, czy raczej ciężko to wskazać?

 

Składniowo P4 trochę przypomina C, ale posiada znacznie mniejszą elastyczność niż C, mam tu na myśli przede wszystkim strukturę samego kodu P4, który już na starcie jest określony. Ta struktura jest na starcie określona przez tak zwany model architektury, który tutaj wielokrotnie wspominaliśmy. W praktyce nie zaczynamy zupełnie od zera pisząc program w P4, tylko taki podstawowy szkielet jest już w pewien sposób z góry zadany. Tak naprawdę programista wypełnia go konkretnym kodem i tworzy implementacje w ten sposób.

Ponadto warto też wspomnieć, że P4 aktualnie nie posiada pewnych mechanizmów, które są typowe dla większości języków ogólnego przeznaczenia, jak choćby pętle. Ma za to dedykowany zestaw słów kluczowych, które bezpośrednio wskazują, jaki rodzaj funkcjonalności w danej chwili implementujemy. Podsumowując, można powiedzieć, że jednak P4 ma po prostu jakąś swoją własną specyfikę. 

 

A jest coś takiego, na co najbardziej narzekasz, stosując ten język na co dzień? Widzisz jakieś mocne braki tego języka? 

 

Biorąc pod uwagę to, co powiedziałem wcześniej, to pewnie łatwo zgadnąć, że ogólna niekompatybilność różnych modeli architektonicznych może powodować takie sytuacje, w których kod działający na jednym urządzeniu nie będzie działał czy nie będzie się nadawał na inne, które wspiera inną architekturę. Z tym że należy pamiętać, że to jest konsekwencja pewnych założeń, które zostały przyjęte przez twórców języka P4 w wersji szesnastej. To nie jest bug, to jest po prostu pewna właściwość.

Druga kwestia, która czasami może okazać się pewnym wyzwaniem, to zestawienie we właściwy sposób całego środowiska testowego, zwłaszcza kiedy piszemy program na urządzenia fizyczne. Nie będzie chyba wielkim zaskoczeniem, jak powiem, że co do zasady, jest to nieco bardziej wymagające niż na przykład upewnienie się, że poprawnie wyświetla nam się na konsoli systemowej Hello World napisane w Javie czy w Pythonie. 

 

Tak, potrafię sobie wyobrazić, że debugowanie takiego kodu jest nieco bardziej skomplikowane i trudniejsze niż, tak jak powiedziałeś, proste debugowanie Javy czy nawet C++. To teraz może jeszcze pytanie o przyszłość. Jakie obszary związane z sieciami SDN, które można definiować albo rozumieć na różne sposoby, bo to jest naprawdę worek różnych technologii czy zjawisk, będą się rozwijały w kontekście języka P4? W sensie tam, gdzie język P4 będzie odgrywał jakąś rolę, gdzie być może jego znaczenie będzie rosło.

 

Moim zdaniem SDN to jest naprawdę bardzo ciekawe zagadnienie, razem z koncepcją NFV zresztą, ponieważ mam wrażenie, że te dwa paradygmaty w bardzo wydatny sposób popchnęły sieci w zupełnie nową stronę. Dzięki SDN, NFV, zyskaliśmy cały szereg nowych możliwości, dzięki którym możemy efektywniej sterować i zarządzać funkcjami sieciowymi, ich konfiguracją, sposobem deploymentu, cyklem życia i tak dalej. To wszystko nadaje  pewnego przyspieszenia takim zagadnieniom jak automatyzacja sieci czy ewolucja architektur sieciowych w stronę modeli bardziej hybrydowych. Myślę, że to będzie mieć swoją kontynuację. P4 jako jedna z nowo dostępnych technologii, również wpisuje się w ten kontekst, ponieważ może być w obrębie kreślonego tutaj krajobrazu z jednej strony bardzo użytecznym narzędziem do optymalizacji działania pewnych komponentów sieci, a z drugiej strony stwarzać zupełnie nowe możliwości.

 

To wszystko nadaje  pewnego przyspieszenia takim zagadnieniom jak automatyzacja sieci czy ewolucja architektur sieciowych w stronę modeli bardziej hybrydowych. Myślę, że to będzie mieć swoją kontynuację. P4 jako jedna z nowo dostępnych technologii, również wpisuje się w ten kontekst, ponieważ może być w obrębie kreślonego tutaj krajobrazu z jednej strony bardzo użytecznym narzędziem do optymalizacji działania pewnych komponentów sieci, a z drugiej strony stwarzać zupełnie nowe możliwości. 

 

Swego czasu na jednej z branżowych konferencji, bodajże którejś edycji ONF Connect, wspomniany już dzisiaj profesor ze Stanforda Nick McKeown, dość duży autorytet jeśli chodzi o SDN, bardzo opiniotwórczy człowiek zresztą, przedstawił dość futurystyczną wizję przyszłości SDN-ów, która zawierała śmiałe tezy. Na przykład takie, że znikną zupełnie protokoły sieciowe, które dzisiaj znamy i poszczególne segmenty sieci będą miały swoje własne mechanizmy do komunikacji wewnętrznej, które będą się jeszcze mogły zmieniać w zależności od potrzeb w czasie.

Kolejną jego ideą było to, że poszczególne sieci miałyby samodzielnie monitorować swój stan w ramach ciągłego procesu i poprzez tak zwany mechanizm zamkniętej pętli, samodzielnie dokonywać różnych modyfikacji, nawet samego kodu aplikacji, które sterują zachowaniem data plane’u, gdyby się okazało, że zostały wykryte jakieś anomalie. P4 miałby być w tym wszystkim jednym z kluczowych enablerów dla realizacji tego typu pomysłów.

Dzisiaj, nie ma co ukrywać, to brzmi trochę egzotycznie czy wręcz nieprawdopodobnie, biorąc pod uwagę stan, w jakim jesteśmy, ale mówiąc szczerze, ja bym był ostrożny w takim zupełnym negowaniu czy wyśmiewaniu tych koncepcji, czy klasyfikacji ich jako zupełnie odrealnionych, ponieważ przyszłość często lubi zaskakiwać. Tak więc, nie wiemy, jak będzie.

Z drugiej strony nie można jeszcze zapominać o aspektach praktycznych, bo niektóre technologie się stosunkowo łatwo adaptują, a niektóre nie. Wpływ na to ma naprawdę wiele czynników, nie tylko stricte merytorycznych czy wynikających z przewagi lub zalet danej technologii. Nie można pomijać uwarunkowań innego rodzaju, na przykład biznesowych czy operacyjnych. Nie bez znaczenia jest też fakt, to jest może pewien truizm, ale jednak tak jest i trzeba to powiedzieć, że małe kroki zawsze jest łatwiej wykonywać niż duże. 

Chcąc prześledzić adaptacje różnych dotychczasowych technik z rodziny SDN, to można zauważyć, że chyba najłatwiej przyjął się tak zwany overlay networking. Gdyby ktoś chciał się zastanowić dlaczego tak się stało, to można poczynić kilka ciekawych obserwacji. Po pierwsze, ta technika znalazła zastosowanie przede wszystkim w data center, które ze wszystkich obszarów sieciowych ma obecnie największą dynamikę. Po drugie, wielkość rynku, a więc możliwość zysku jest tu olbrzymia, co jest naturalne. Po trzecie, overlay networking był dość dobrą odpowiedzią na problemy związane ze skalowalnością w tym środowisku. A po czwarte, miał stosunkowo niski próg wejścia od strony technologicznej, ponieważ nie są tu stosowane jakieś wielce wyrafinowane mechanizmy. Wszystkie te aspekty przemawiały na korzyść tego rozwiązania i najprawdopodobniej przyczyniły się do jego szybkiej, masowej adaptacji.

Trzeba zdawać sobie sprawę, że to też nie jest tak, że koncepcje, które wydają się być o wiele bardziej wymagające czy trudniejsze do zastosowania na dużą skalę, z góry są skazane na niepowodzenie, zwłaszcza jeżeli przynoszą dużą wartość i są przełomowe w jakichś aspektach. Jeśli zaś chodzi o P4, to nie ulega wątpliwości, moim zdaniem, że to jest narzędzie bardzo potężne i bardzo obiecujące, natomiast mi się wydaje, że aby ono się upowszechniło w tej czy innej formie, to musi jednak minąć trochę czasu. Tak mi się wydaje. No cóż, zobaczymy, jak będzie.

 

Bardzo dobrze to podsumowałeś słowami, że przyszłość lubi nas zaskakiwać. Bardzo Ci dziękuję za dzisiejszą rozmowę, bardzo merytoryczną, rzeczową i konkretną. Ja sam się sporo dowiedziałem, stąd wielkie dzięki za ten poświęcony czas.

Powiedz, proszę, na koniec, gdzie Cię można znaleźć w Internecie, jak się z Tobą skontaktować?

 

Po pierwsze, ja również dziękuję. Było mi niezwykle miło. Co do mnie, można znaleźć trochę materiałów ze mną na YouTube, gdyby ktoś na przykład był ciekaw, czym zajmowałem się przez ostatnie lata. To są na przykład wystąpienia na konferencjach branżowych typu PLNOG albo jakieś webinaria, które prowadziłem. Zdarza mi się czasem także coś napisać na blogu technologicznym CodiLime. Natomiast gdyby ktoś chciał się skontaktować ze mną tak po prostu, bezpośrednio, to myślę, że najlepszym narzędziem będzie LinkedIn, jak najbardziej można do mnie napisać. Zapraszam serdecznie.

 

Świetnie, oczywiście wszystkie linki będą w notatce do tego odcinka.

Pawle, dzięki jeszcze raz. Do usłyszenia!

Cześć!

 

Dziękuję, cześć!

 

I to na tyle z tego, co przygotowałem dla Ciebie na dzisiaj. Programowanie odgrywa znaczącą rolę w każdej dziedzinie IT i nie inaczej jest z urządzeniami sieciowymi. Język P4 idealnie sprawdza się tych zastosowaniach, ponieważ nie jest językiem ogólnego przeznaczenia. Natomiast został zaprojektowany tak, by odpowiadać na specyficzne problemy i wymagania tej właśnie dziedziny.

Jeśli ten odcinek był dla Ciebie interesujący i ciekawy, odwdzięcz się proszę recenzją, oceną lub komentarzem w social mediach.

Jeśli masz jakieś pytania, pisz śmiało na krzysztof@porozmawiajmyoit.pl. Zapraszam też do moich mediów społecznościowych.

Ja się nazywam Krzysztof Kempiński, a to był odcinek podcastu Porozmawiajmy o IT o języku P4 i programowaniu urządzeń sieciowych.

Zapraszam do kolejnego odcinka już za tydzień.

Cześć!