Cisco Poland Blog
Share

onePK czyli sieci malowane oprogramowaniem


2 July 2012


Na zakończonym niedawno Cisco Live w Stanach Zjednoczonych ogłosiliśmy zestaw onePK, API pozwalającego w bardzo wygodny ale jednocześnie potężny sposób, budować swoje własne rozwiązania programowe zintegrowane z warstwą sieciową. onePK jest rewolucyjny nie tylko dlatego, że nawiązuje do koncepcji SDN i nie tylko dlatego, że szeroko wychodzi ponad definicję API – sięgając po unikalne powiązania pomiędzy sprzętem i oprogramowaniem oraz właściwości wirtualizacji. onePK jest rewolucyjny przede wszystkim dlatego, że przewidujemy dla niego wsparcie na większości urządzeń z naszej oferty co oznacza, że korzyści wynikające z integracji i elastyczności będą pojawiały się we wszystkich miejscach sieci. Czym jest zatem SDN?

Software Defined Networking

Architektura SDN to koncepcja, w ramach której centralnie działające oprogramowanie steruje siecią dowolnej wielkości i o dowolnym stopniu komplikacji. Dzięki możliwości wnikania bezpośrednio w aplikacje, oprogramowanie może z jednej strony w czasie rzeczywistym reagować na potrzeby aplikacji i użytkowników (pasmo, priorytet, trasę, różnicę w opóźnieniu, użytkownika, konkretną aplikację użytkownika etc) a z drugiej – w dowolnym stopniu, poruszając się tylko w ramach ograniczeń sprzętu – kontrolować infrastrukturę. Dotychczasowe, tradycyjne sieci IP posiłkują się tutaj różnego rodzaju mechanizmami i dopiero od niedawna pozwalają sięgać po informacje z warstwy aplikacji w sposób pozwalający reagować i dostosowywać obsługę ruchu. Prace grupy roboczej ALTO, dostępne w rozwiązaniach Cisco pod nazwą Proximity Routingu, czy też mechanizmy takie jak LISP pozwalają integrować pracę infrastruktury sieciowej z dodatkową inteligencją pozyskiwaną z warstwy aplikacji, lecz jest to integracja “od dołu” stosu sieciowego.

SDN vs tradycyjny model sieci IP

Architektura SDN zakłada integrację “od góry”, zapewniając – jako architektura – styk do infrastruktury sieciowej i mechanizmy współpracy różnego rodzaju funkcji (głównie związanych z wirtualizacją). Pierwszym pomysłem na ustandaryzowanie takiego styku stał się protokół OpenFlow. Specyfikacja protokołu mającego służyć jako uniwersalny styk nie jest jednak wystarczająca.Oprogramowanie sterujące musi posiadać także możliwość budowy warstwy abstrakcji sieci i urządzeń oraz posiadać inteligencję, którą chcemy “zdjąć” z autonomicznych do tej pory, tradycyjnych urządzeń sieciowych. Urządzenia te z kolei muszą mieć świadomość procesów, kontrolowanych przez centralne oprogramowanie.

Architektura SDN

Cisco od początku włączyło się do prac nad protokołem OpenFlow. Choć od początku widać było, że o ile jest on krokiem w dobrym kierunku – sam protokół to daleko za mało. Dzisiaj zarówno tempo prac nad nowymi wersjami standardu zwalnia, maleje również skupienie dostawców oprogramowania nad dostarczaniem coraz to nowych modułów funkcjonalnych.

Dwie podstawowe zalety onePK

onePK, czyli zestaw do tworzenia rozwiązań programowych, to pakiet pozwalający w wygodny sposób nawiązać połączenie pomiędzy własnymi aplikacjami a infrastrukturą zbudowaną z rozwiązań Cisco.

Oznacza to, że wdrażanie idei SDN można rozpocząć bez budowy sieci od zera – na początek węzły mogą pracować nadal w trybie autonomicznym a oprogramowanie będzie jedynie pobierać z nich informacje na potrzeby np. wizualizacji ruchu. Ten tryb działania jest również wygodny do różnego rodzaju testów i symulacji odbywających się w środowisku wirtualnym, ale korzystającym z danych żywej sieci. Następnie można zacząć wpływać na przepływ ruchu, wykorzystując z jednej strony ogromne możliwości sprzętowe platform Cisco a z drugiej – tworzone i pozyskiwane moduły logiczne, realizujące funkcje z warstwy kontroli.

onePK pozwala na wykorzystanie w pełni idei sterowania zcentralizowanego bez ogromnej, wstępnej inwestycji w oprogramowanie pełnej warstwy kontrolnej (choćby w minimalnej postaci). Gotowe rozwiązania tego typu dopiero zaczynają powstawać i są na razie jedynie przeniesieniem gotowych systemów ze świata tradycyjnych sieci IP (pakiety routingu, przetwarzania pakietów, etc.), nie wykorzystując unikalnych możliwości integracji między aplikacjami a sprzętem sieciowym.

Dodatkowo, dzięki ogromnej ilości różnego rodzaju mechanizmów zapewniających już dzisiaj głęboką inteligencję sieci IP na platformach Cisco pracujących pod kontrolą systemów IOS, IOS-XE, IOS-XR oraz NX-OS, korzystanie z onePK pozwala posługiwać się nimi aby zwiększyć szybkość i możliwości – zastosowanie gotowych protokołów takich jak OTV, LISP, protokoły routingu czy rozszerzenia dla MPLS daje potężne środowisko pracy dla wszystkich, chcących budować własne rozwiązanie ponad inteligentną infrastrukturą.

Co można zrealizować z pomocą onePK?

onePK będzie doskonałym narzędziem do szybkiego kreowania abstrakcji istniejących rozwiązań – zarówno na potrzeby testów jak i szybko pojawiających się (i znikających) grup roboczych czy też rozwiązań. Dzisiejsze rozwiązanie w postaci “twardych” mechanizmów, takich jak MPLS, VRFy czy VLANy jest zwykle dużo mniej elastyczne niż rozwiązanie sterowane centralnie za pomocą elastycznego i zwykle dużo bardziej przyjaznego interfejsu oprogramowania zarządzającego całą siecią. Dzisiejszym rozwiązaniom brakuje szybkości i elastyczności, co bierze się zwykle właśnie z autonomiczności wszystkich węzłów na całej kontrolowanej ścieżce.

onePK doskonale sprawdzi się również tam, gdzie wymagana będzie jeszcze lepsza optymalizacja zasobów sieciowych – mając do dyspozycji potężne narzędzie, które daje jako zespół charakterystyk opisujących ruch dodatkowo informacje specyficzne dla użytkownika i aplikacji. Mamy zatem do dyspozycji bardzo dokładne i granularne rozwiązanie pozwalające kontrolować całą ścieżkę w bardzo elastyczny sposób. Tego typu zastosowanie będzie doskonale sprawdzało się głównie w Centrach Przetwarzania Danych, ale również w sieciach kampusowych i korporacyjnych, gdzie ścisłe związanie użytkownika i grupy jego aplikacji jest i tak wymagane z punktu widzenia np. mechanizmów bezpieczeństwa.

Należy jednak pamiętać, że dowolne rozwiązania tworzone programowo zawsze trafią na ograniczenia sprzętu tworzącego infrastrukturę. Czym większa ilość mechanizmów dostępnych na platformach sieciowych i czym lepsza ich skalowalność – tym więcej mechanizmów tworzonych w warstwie oprogramowania będzie można przenieść bez problemów na warstwę przekazywania i kontroli ruchu.

Co dalej?

onePK dostępny jest dzisiaj dla wybranych instytucji badawczych i klientów. Do końca roku elementy pierwszej wersji onePK pojawią się w oprogramowaniu pracującym na platformach Cisco ASR 1000, Cisco ISR oraz na platformach programowych – w tym Nexus 1000v. Zakładamy, że na rynku przez najbliższe parę lat powstanie osobna gałąź sprzętu, zgodnego z sieciami SDN i będzie to naturalna ewolucja, nie rewolucja.

onePK daje potężne narzędzie dla wszystkich, chcących sięgnąć jeszcze głębiej w warstwę integracji i wycisnąć jeszcze więcej, z bardzo bliskiej zależności między oprogramowaniem a sprzętem. Platformy Cisco zapewniają już dzisiaj unikalne mechanizmy i skalowalność dostosowaną do scenariuszy projektowych – onePK stanie się zatem doskonałym dopełnieniem możliwości elastycznego i szybkiego tworzenia nowych rozwiązań.

Tags:
Leave a comment

3 Comments

  1. Z platform programowych obsługujących OpenFlow intensywnie rozwija się Open vSwitch, jako podstawowe rozwiązanie sieci dla wirtualnego środowiska (Xen Server, XCP, KVM, Kontenerów (LXC, OpenVZ), VirtualBox itd.) – rozwiązanie podobne do Nexus 1000v i VMware vNetwork distributed vswitch, pozwala także w połączeniu z Quagga na zbudowanie multi-layer switch, odpowiedni obraz dla GNS3 do testów jest dostępny.
    Krótki opis:
    open-vswitch-siec-dla-maszyn-wirtualnych-i-kontenerow

    • Platform programowych realizujących wirtualizację przełącznikia jest bardzo dużo – vSwitch rozwija się swoją drogą IMHO najwolniej ze swoich wolnych konkurentów. Nie o to jednak idzie – oprogramowanie na upartego zawsze można sobie dopisać, jest bowiem “tanie” w produkcji i potencjalnie jest go już dzisiaj bardzo dużo. Pisałem o zwolnieniu wprowadzania implementacji kolejnych wersji standardów OpenFlow w sprzęcie – a bez tego nie da się przeskoczyć ograniczeń wydajności i wykorzystać modelu SDNowego na szeroką skalę w praktyce.