Programowalne sieci komputerowe (Software-defined netowrking)

Krzysztof Kempiński
Mar 17 · 12 min read

W ramach podcastu “Porozmawiajmy o IT” miałem okazję porozmawiać z Krzysztofem Wróblem z CodiLime o programowalnych sieciach komputerowych oraz o pracy programisty w tym obszarze.

Posłuchaj naszej rozmowy w wersji audio 🎧 👇

Cześć! Mój dzisiejszy gość to lider projektów i zespołów w IT. Doświadczony programista z obszaru embedded i automatyzacji testów, osoba pracująca z liderami technicznymi, odpowiedzialny za całościowe dostarczanie projektów. Pracował m.in. w Samsungu. Od 1,5 roku dyrektor techniczny w CodiLime. W wolnym czasie uczy dzieci programowania. Moim i Waszym gościem jest dzisiaj Krzysztof Wróbel. Cześć Krzysztofie, bardzo miło mi gościć cię w podcaście!

Cześć Krzysztofie, bardzo miło mi, że zostałem zaproszony.

Dziś rozmowa dwóch Krzysztofów [śmiech]. Z Krzysztofem porozmawiamy dzisiaj tak naprawdę o dwóch tematach. Pierwszy to Software Defined Network, czym one są i drugi, alternatywna ścieżka rozwoju dewelopera, która właśnie z tego typu sieciami jest związana.

Okej. Zacznę od tradycyjnego pytania, które zawsze u mnie się pojawia, czyli czy słuchasz podcastów? Jeśli tak, to jakich najczęściej?

Tak, słucham podcastów. Na pewno słucham Porozmawiajmy o IT, z tego względu, też przygotowałem się do odpowiedzi, bo wiedziałem, że będziesz o to pytał. Zrobiłem sobie listę i na liście jest ich około 14, więc sporo, ale jeśli miałbym wymienić tak szybko, to Biznes w IT, Mała Wielka Firma, Manager Plus — chyba od tego podcastu w ogóle zaczynałem. Porządny Agile jest też bardzo fajnym podcastem, polecam. Greg Albrecht Podcast też bardzo ciekawy. To takie około biznesowe, około zarządzania, ale też bardziej techniczne, na przykład DevEnv czy też DevTalk Macieja Aniserowicza. Z zachodnich podcastów, obcojęzycznych The Python Podcast czy też Syntax na przykład, z web developmentu. Również zbliżone do naszej dziedziny, czyli Cloud Cast albo Packet Pushers też bardzo ciekawe, aczkolwiek odbiegające już od programowania.

Bardzo fajna lista! Dobrze, to może spróbujemy przybliżyć tę dziedzinę, branżę, w której od pewnego czasu jesteś, w której się specjalizujesz. Powiedz proszę, czym jest Software Defined Network, czyli SDN. W jaki sposób łączy on programowanie ze światem sieciowym, kto zapoczątkował ten kierunek, jakie istnieją warianty sieci? Gdybyś mógł przybliżyć nam tę dziedzinę!

Przede wszystkim należy zacząć od skrótu Software Defined Networking, czyli Sieć Definiowana poprzez Programowanie albo Programowalna. Tu jest właśnie duży problem — dzisiaj jako SDN-y rozumie się bardzo wiele rzeczy, ale to hasło pojawiło się po raz pierwszy chyba przy pracy doktorskiej Martina Casado, bardzo ciekawego człowieka właśnie, pracującego w tym obszarze, który napisał swoją pracę doktorską na Uniwersytecie w Stanford. I tak naprawdę chyba jego możemy uważać jako takiego twórcę tego terminu.

Zgodnie z tym, jak on zdefiniował te SDN-y, to tak naprawdę jest rozdzielenie… Teraz będzie parę trudniejszych słów: rozdzielenie Control Plane‚u od Forwarding Plane‚u, takich dwóch płaszczyzn w urządzeniach sieciowych.

Założenie jest jeszcze takie, że taki jeden Control Plane zarządza wieloma urządzeniami. Teraz właśnie może warto byłoby powiedzieć, czym jest ten Control Plane, czym jest Data Plane albo Forwarding Plane. Control Plane to jest tak jakby mielibyśmy posłużyć się jakąś metaforą, to jest mózg sieci. To jest ta część urządzenia sieciowego, która komunikuje się poprzez różne protokoły routingowe, poprzez narzucanie pewnych polityk i konfiguracji wrzucanych przez administratorów sieciowych do takich urządzeń i to ona decyduje tak naprawdę, co robi ta druga część. Czyli Data Plane, a Data Plane to jest nic innego jak tylko przesyłanie pakietów od urządzenia do urządzenia. Właśnie to, co SDN robi inaczej w stosunku do tego, co było kiedyś, to rozdziela te dwie rzeczy bardzo wyraźnie i jedną z tych części centralizuje. Umieszcza ten Control Plane w jednym miejscu, jako oprogramowanie działające na jakichś generycznych serwerach.

Natomiast Data Plane pozostaje po stronie urządzeń. Urządzeń rozsianych po całej sieci. To są routery, to są switche. Właśnie zadaniem tego Control Plane‚u jest takie wysterowanie tymi urządzeniami, takie narzucenie polityk, którymi one się kierują, przy przesyłaniu pakietów, żeby one docierały do miejsca docelowego, urządzenia docelowego w jak najkrótszym czasie, zachowując pewne ograniczenia co do bezpieczeństwa i różnego tego typu polityk.

Nie wiem, czy jakoś wyraźnie w miarę to pokazałem, bo pewnie łatwiej byłoby narysować.

Jak najbardziej. Chciałbym cię jednak jeszcze dopytać w tym wątku. Powiedziałeś mniej więcej, jaka jest podstawowa różnica w stosunku do tradycyjnego podejścia do tradycyjnych architektur sieciowych. Chciałbym cię natomiast zapytać, jakie są jeszcze inne różnice, bo tez z tym wiąże się pytanie: po co sieci tego typu zostały wymyślone, jaka potrzeba, może jaki brak wpłynął na to, że sieci tego typu powstają? Dlaczego tradycyjne podejście jest, czy było, niewystarczające?

Wydaje mi się, że ta oryginalna potrzeba wzięła się prawdopodobnie z dużych firm, które zarządzały dużymi jednostkami albo centrami danych. Czyli jakimś bardzo dużym zbiorem serwerów, które muszą się ze sobą komunikować, żeby tworzyć tę chmurę, która dla nas jest widoczna jako abstrakcja.

Wydaje mi się, że były dwie takie potrzeby. Z jednej strony to technicznie bardzo trudno jest nadążać za administracją pojedynczych urządzeń, w związku z tym, mając jedno scentralizowane miejsce, gdzie definiujemy sobie pewne polityki, według jakich urządzenia te mają działać, mamy rozwiązany problem tego, że musimy się logować na każde z tych urządzeń z osobna, konfigurować, być może kiedyś za pomocą jakiegoś Command Line Interface, czyli logowania się po prostu poprzez terminal do konsoli każdego z urządzeń, to jest jedna rzecz. Czyli możemy to robić z jednego miejsca za pomocą scentralizowanych, że tak powiem, polityk zarządzanych centralnie.

Z drugiej strony jednak dzisiaj jako SDNy rozumie się nie tylko według tej klasycznej definicji, jak mówiliśmy wcześniej, rozdzielenie tego Control Plane‚u, ale chyba trochę hype spowodował, że zaczęliśmy podciągać pod to hasło tak naprawdę też inne rozwiązania, typu SD WAN czy NFV na przykład. Takie hasła też się pojawiają. Taki SD WAN z kolei to jest problem tego, że mamy wiele różnych sieci lokalnych, rozproszonych. po całym świecie, po całym kraju i problem też jest, czy w takim razie musimy zatrudniać administratora sieciowego do każdej z tych sieci lokalnych? To jest kolejny problem, który te rozwiązania rozwiązują. Możemy sobie zdalnie zarządzać sieciami lokalnymi, dbać o ich bezpieczeństwo, a z drugiej strony te rozwiązania typu SD WAN na przykład powodują, że z punktu widzenia urządzeń podłączonych do naszej jednej sieci lokalnej, wszystkie pozostałe urządzenia są widoczne tak jakby w tej sieci lokalnej były, nawet jeśli oddzielają nas od nich trzy kolejne sieci bądź też Internet. To są więc chyba główne problemy, które SDNy rozwiązują.

Czyli mówisz, że takie typy sieci — znaczy, mówisz, że nie są to do końca typy SDN, tylko ogólnie rodzaje sieci typu SD WAN czy SD LAN dajmy na to. Tak de facto nie do końca podchodzą pod tę definicję, jeśli dobrze zrozumiałem. Trochę próbują się ogrzać w ciepełku tej definicji SDN, natomiast nie do końca podpadają pod tego typu definicje sieci. Dobrze to zrozumiałem?

Tak, jeśli mielibyśmy być tacy bardzo precyzyjni, to one nie podpadają. To jest tak jak z różnego rodzaju hasłami, dzisiaj wszyscy są agilowi, a jest pewien zbiór punktów, który to definiuje, nawet jeśli nie spełniamy wszystkich, albo czujemy, że idziemy w duchu tych haseł, zasad, które są tam spisane, to mówimy, że jesteśmy agile. Tutaj — w porządku — z jednej strony to jest być może trochę wygrzebanie się przy tych dużych projektach i wykorzystywanie tego hype’u. Z drugiej strony wydaje mi się, że ten kierunek SDN-owy właśnie spokojnie możemy rozszerzyć na wszelkie innego typu rozwiązania, gdzie coraz więcej jest uwalniania się od specjalistycznego sprzętu, od firm, które tworzą rozwiązania zamknięte w stronę takiego otwartego oprogramowania i oprogramowania, które może być wykorzystywane generycznie. To powoduje, że mamy bardzo dużo różnych zalet tego typu podejścia.

Tak, jak powiedziałeś, że te rozwiązania typu SD WAN, czy też NFV, one być może nie podpadają pod tę definicję, ale uważam, że są bardzo fajnym kierunkiem, w którym to wszystko zmierza.

Jasne. Tak sobie myślę, że to, co powiedziałeś, że dajmy na to, na te różne urządzenia sieciowe przy SDNie, można wgrywać te wszystkie konfiguracje w sposób zdalny, nie trzeba już w jakiś sposób logować się do każdego urządzenia i konfigurować jak gdyby per urządzenie, to m.in. może wpływać na to, że bezpieczeństwo przesyłu informacji w takiej sieci może być zwiększone. Czy mówi się o takim zagadnieniu, czy to jest faktycznie coś, z czym mamy do czynienia? Czy w sieciach SDN powiedzmy, można mówić o zwiększonym bezpieczeństwie przepływu danych?

Wydaje mi się, że możemy na pewno mówić o zwiększeniu bezpieczeństwa, ale równocześnie też zmniejszeniu w innych aspektach tego bezpieczeństwa.

Przez to, że jesteśmy właśnie elastyczni, że możemy w bardzo szybki sposób, wręcz automatyczny, rekonfigurować taką sieć, izolować pewne fragmenty tej sieci, przekierowywać ruch poprzez inne urządzenia i trasy, co wcale nie byłoby takie łatwe, gdyby nie ta decyzja o tym, jak jest kierowany ruch, była podejmowana zbiorczo przez każde z urządzeń, ponieważ tam czas propagacji, że tak powiem, te informacje, które z urządzeń jest zainfekowane, albo która ze ścieżek powinna być pominięta i tak dalej.

Tutaj mamy te informacje od ręki, w jednym miejscu, więc możemy sobie w bardzo fajny sposób pracować różnego rodzaju algorytmami, które będą sprawnie i szybko reagowały i aplikowały te nowe polityki już w sieci. Coś, co byłoby trudne i czasochłonne do wykonania człowiekowi manualnie. Tu na pewno mamy zwiększenie bezpieczeństwa. Z drugiej strony jednak, mamy też ten jeden punkt, który jest podatny na awarie, jeden, który jest podatny na ataki, czyli ten kontroler. Kontroler to jest tak naprawdę nic innego, jak zbiór usług, aplikacji działających na generycznych serwerach i wtedy jeden punkt ataku może zabić całą sieć. Jeśli jesteśmy w stanie przejąć taki kontroler, mamy właściwie całą sieć.

Z drugiej strony bronimy się w jednym miejscu, a nie na wszystkich urządzeniach z osobna. Ten kontroler musi też komunikować się z tymi urządzeniami sieciowymi, którym narzuca te różne konfiguracje, polityki i tutaj też może być jakiś atak man in the middle może dojść do tego typu ataków, gdzie jesteśmy w stanie też zmienić konfigurację każdego z urządzeń.

Same te urządzenia też potrzebują ciągłej komunikacji z kontrolerem, więc jesteśmy w stanie zainfekować lub zaatakować te urządzenia, to też może być niebezpiecznie. Jak to w życiu bywa — nigdy nie jesteśmy w stanie znaleźć jakiegoś super rozwiązania. Wydaje mi się jednak, że to są problemy, z którymi potrafimy sobie już w jakiś sposób radzić. To są problemy, które dotyczą dzisiaj praktycznie większości systemów i rozwiązań aplikacyjnych.

Pewnie. Jak to właśnie powiedziałeś, jak to w życiu — nie ma nic za darmo, a czasem trzeba wybrać mniejsze zło.

Okej. Chciałbym zapytać cię o kwestię, której trochę powiedziałeś. Z SDNami wiąże się jeszcze koncept takiej architektury sieciowej, nazywanej NVF, prawda? Czyli Network Function Virtualization. Powiedziałeś, że to nie do końca wpasowuje się być może w definicję SDN, ale często w różnych artykułach, blogach itd., gdzieś te dwa pojęcia leżą blisko siebie.

Mógłbyś pokrótce powiedzieć, czym jest ten koncept, w jaki sposób wiąże się z SDNami właśnie?

Tak. Mówiąc wprost, NFV, to jest wirtualizacja funkcji sieciowych. Funkcje sieciowe typu Firewall, typu szyfrowanie, deszyfrowanie wysyłanych treści, pakietów. Usługi typu NAD, DNS, jakieś cachowanie w sieciach. Coś, co nadal jest realizowane za pomocą fizycznych urządzeń. Oczywiście, na tych fizycznych urządzeniach też działa software, ale do tej pory były realizowane jako niezależne, oddzielne funkcje, dostarczane przez wyspecjalizowane w rozwiązaniach firmy.

Powodowało to dużo problemów. Po pierwsze, taki sprzęt jest o wiele droższy. Po drugie, jest dużo mniej elastyczny, bo nagle okazuje się, że aby zmienić albo dołożyć trzeba po prostu dołożyć kolejne urządzenie ze swojej szafy rackowej. Zwiększenie poboru energii, tego typu problemy.

Natomiast idea jest taka, żeby zamiast używania takiego specjalistycznego sprzętu, dobrać generyczny serwer i na nim tak naprawdę postawić jakieś serwisy, usługi, realizowane czysto programowo. Dzięki temu możemy sobie dowolnie dodawać kolejne usługi, dowolnie je skalować, możemy w łatwy sposób aktualizować ich wersje, dodawać całe funkcje do nowych sieci. Jest to więc bardzo fajny koncept.

Natomiast idea jest taka, żeby zamiast używania takiego specjalistycznego sprzętu, dobrać generyczny serwer i na nim tak naprawdę postawić jakieś serwisy, usługi, realizowane czysto programowo. Dzięki temu możemy sobie dowolnie dodawać kolejne usługi, dowolnie je skalować, możemy w łatwy sposób aktualizować ich wersje, dodawać całe funkcje do nowych sieci. Jest to więc bardzo fajny koncept.

Znowu mamy też słabsze strony tego rozwiązania: czasem jest to kwestia wydajności. To jest chyba jedne z większych problemów, ale też z drugiej strony taki czysto ludzko — procesowy, bo jednak włożenie nowego urządzenia do szafy rackowej, wpięcie kilku przewodów, to jest takie bardzo namacalne. Łatwe do zrozumienia. Zainwestowaliśmy pieniądze, w ostateczności przerobimy na szafkę.

Natomiast tutaj, gdy mamy to zwirtualizowane, jednak trudniej się tym zarządza. Trudniej i łatwiej: trudniej z punktu widzenia tego, że nie jest to namacalne, trzeba więc znaleźć też trochę innych ludzi, którzy będą to instalowali, którzy będą się tym opiekowali. Tutaj dużo bardziej złożony jest ten koncept, w związku z czym to też wymaga trochę zmiany podejścia. Jednak bardzo fajna rzecz, szczególnie gdy nagle sobie uzmysłowimy, że mamy jedną z usług zwirtualizowaną, uruchamianą na jakimkolwiek serwerze, no to nagle możemy dołożyć trzecią, czwartą i możemy spostrzec, że właściwie nigdzie nie ma żadnego przewodu. Tak zwany service chaining, możemy łączyć sobie fajnie te usługi ze sobą, możemy dynamicznie przełączać ruch między jedną tego typu usługą a drugą. Jest całe mnóstwo możliwości przed tego typu rozwiązaniami.

No właśnie, gdy czytałem sobie o tym koncepcie, to znalazłem, że w połączeniu z SDN-em, może to być używane to tak zwanego edge computingu. Mógłbyś powiedzieć, czym jest edge computing i do czego służy?

Tu też edge computing dość szeroko może być rozumiany, to też jest jeden z naszych dzisiejszych base wordów, który mocno chwyta.

Tak jak powiedziałeś — przy zastosowaniu NFV, nagle okazuje się, że możemy przenieść przetwarzanie bądź też przechowywanie pewnych danych bliżej klienta i możemy zrobić to zdalnie i automatycznie. Edge computing może być rozumiany jako kamera internetowa, która ma funkcje wytwarzania obrazu i wykrywa ruch albo też osoby znajdujące się w kadrze, ale z drugiej strony to może też być w przypadku operatorów sieciowych przerzucenie usługi firewalla na przykład, czyli takiej zapory ogniowej, na stronę infrastruktury klienta. Może to być zarządzane przez tego operatora. Możemy też takie szyfrowanie, deszyfrowanie także przerzucić bardzo blisko klienta — tutaj też zwiększamy bezpieczeństwo.

Dane mogą być szyfrowane najbliżej źródeł. Dzięki temu możemy również zmniejszyć latency, czyli opóźnienia w komunikacji. Jaki jest sens przesyłania danych, które miały być zaszyfrowane gdzieś tam daleko, na centralny serwer, umieszczony gdzieś w data centre Google’a, jak możemy część z tych operacji wykonać już blisko klienta. Generalnie fajna rzecz: elastyczność i to jest możliwe tylko dzięki temu, że pewne funkcje możemy mieć zwirtualizowane. Wysyłanie paczką, kurierem urządzenia sieciowego do klienta też wchodziłoby w grę, ale jednak trochę bardziej problematyczne.

Powiedziałeś mniej więcej, czym są sieci SDN. Zastanawiam się, jakie są wady i zalety, bo na pewno taki i takie są. Tutaj zarówno od strony technicznej, jak i biznesowej, czym się charakteryzują pozytywnie i negatywnie sieci tego typu?

Pewnie gdzieś już o tym mówiliśmy wcześniej — na pewno jest to szybsze i pewniejsze wdrażanie tych zmian. W momencie, gdy mamy wszystko w jednym miejscu możemy w bardzo łatwy sposób aktualizować sobie polityki tych sieci, konfiguracje i tak dalej. Te programowalne elementy sieciowe pozwalają nam też wdrażać bardzo szybko nowe funkcje. Podsumowując: większa elastyczność, mniejsze koszty operacyjne, ale być może też inwestycyjne.

A z punktu widzenia stricte funkcjonalnego, bardzo fajny case przerabialiśmy jakiś czas temu. On jest też dostępny publicznie. Na przykład, wdrożenie systemu SD WAN, w sieci Rossmann. Wyobraźmy sobie 1200 sklepów i tylko trzech administratorów, którzy są w stanie nad tym wszystkim zapanować. Dzisiaj taki sklep to jest mnóstwo technologii. Od systemów wizyjnych, poprzez systemy kasowe, access pointy dla klientów i tak dalej, i tak dalej.

Każda firma korzysta z sieci, nawet gdy nie jest tego w pełni świadoma, bo dla niej są to jakieś produkty końcowe. To też pokazuje, jak fajnie można sobie zredukować ludzkie koszty. NA pewno też jest zwiększona widoczność, tak zwana visibility tego, co się w sieci dzieje, jak ona wygląda. Coś, co musielibyśmy kiedyś odtwarzać oddolnie, bo mieliśmy mnóstwo urządzeń, które były ze sobą jakoś fizycznie połączone. Dzisiaj my wiemy odgórnie, na poziomie kontrolera, jak ta topologia wygląda. Też dużo łatwiej się o niej rozmawia, planuje. To są tego typu zalety. O wadach też mówiliśmy. To jest ten jeden punkt krytyczny.

Na pewno nie ma też jeszcze standardów. Mówiliśmy też o tym klasycznym SDNie i protokole Open Flow, który jest swego rodzaju standardem dzisiaj, ale tam nadal trwa, wydaje mi się walka i nie ma jednoznacznie ustalonych standardów, które byłyby zaakceptowane przez całą społeczność. No i dwa lata to jest nowa technologia, więc to wymaga naprawdę dużej zmiany po stronie mindsetu. Zmiana też ludzi, którzy do tej pory zajmowali się sieciami. Klasyczny administrator musi zdobywać coraz to nowe kompetencje, poznawać techniki, z którymi być może nie miał do czynienia, więc to jest taka duża zmiana organizacyjna, więc to jest chyba coś, co jeszcze wstrzymuje te sieci przed byciem wykorzystanymi globalnie i przez mniejsze firmy.

dwa lata to jest nowa technologia, więc to wymaga naprawdę dużej zmiany po stronie mindsetu. Zmiana też ludzi, którzy do tej pory zajmowali się sieciami. Klasyczny administrator musi zdobywać coraz to nowe kompetencje, poznawać techniki, z którymi być może nie miał do czynienia, więc to jest taka duża zmiana organizacyjna, więc to jest chyba coś, co jeszcze wstrzymuje te sieci przed byciem wykorzystanymi globalnie i przez mniejsze firmy.

Czytaj dalej na: https://porozmawiajmyoit.pl/poit-059-software-defined-networking/

Krzysztof Kempiński

Written by

IT expert. Ruby on Rails/iOS/Elixir programmer. Blogger. Podcaster.

kkempin’s dev blog

Dev and life blog. Thoughts about programming, design patterns, Ruby and life.

More From Medium

More on Podcast from kkempin’s dev blog

More on Podcast from kkempin’s dev blog

Druk 3D

More on Podcast from kkempin’s dev blog

More on Podcast from kkempin’s dev blog

Specjalista IT zostaje managerem

More on Podcast from kkempin’s dev blog

More on Podcast from kkempin’s dev blog

Globalna marka osobista w IT

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade