Architektura dla wielkiej chmury

Tradycyjna architektura IT w centrum danych oraz znajdującej się w nim sieci transportowej wykorzystuje protokół Spanning Tree (STP), złożone protokoły warstwy 3. (takie jak OSPF, IS-IS i BGP) oraz metodę podłączania wielu urządzeń do jednego portu (oversubscription) w celu zapewnienia optymalnego wykorzystania przepustowości przełączników oraz ich portów. W takim modelu cały ruch jest routowany pomiędzy warstwami 2. i 3. w jednym punkcie – zwykle jest to router warstwy agregacji, który często staje się wąskim gardłem. Dodatkowo procesory przełączników mogą być nadmiernie obciążone przez transmisje z protokołem ARP, tabele routingu o dużym rozmiarze i wskutek wprowadzania zmian w topologii sieci. Tego typu architektura nie działa dobrze w przypadku, gdy konieczne jest zapewnienie wysokiej przepustowości pomiędzy serwerami w centrum danych, co jest typowe dla sieci bankowych, infrastruktury wysoko wydajnych komputerów i rozwiązań chmurowych.

W odpowiedzi na te wyzwania powstał projekt bazujący na dwuwarstwowej architekturze spine-and-leaf (kręgosłup i liść). Zapewnia ona optymalizację przepustowości pomiędzy portami przełączników przez stworzenie struktury składającej się z wielu przełączników spine, które łączą porty brzegowe umieszczone w przełącznikach typu leaf. Taka konstrukcja zapewnia opóźnienia o stałej wartości i minimalizuje liczbę połączeń między serwerami w różnych szafach. Architektura typu spine-and-leaf wykorzystywana jest w rozwiązaniu Big Cloud Fabric firmy Big Switch Networks. Modularne środowisko, które może być zainstalowane w przełącznikach HPE Altoline, łatwo można połączyć z siecią starszego typu za pomocą standardowego interfejsu warstwy 3.
Ten model architektury jest jak najbardziej odpowiedni do stworzenia niezależnego, nadającego się do replikacji środowiska, które łatwo jest skalować i uaktualniać bez zakłócania ruchu sieciowego. Aby zwiększyć liczbę portów brzegowych do łączenia się z serwerami, wystarczy po prostu dodać więcej przełączników typu leaf (zalecana przepustowość to 10 GbE), a żeby poprawić wydajność całej architektury, należy zwiększyć liczbę przełączników typu spine (40 GbE). Porty brzegowe 10 GbE mogą być agregowane z wykorzystaniem statycznych lub dynamicznych grup agregacji łącza (LAG) w celu zapewnienia jeszcze większej przepustowości wybranym serwerom.

Monitoring nowej generacji

W centrach danych coraz częściej stosowana jest architektura sieciowa o przepustowości 10/40 GbE oraz 40/100 GbE. Popularne staje się też wykorzystanie usług mobilnych 4G/LTE, przetwarzanie danych w chmurze oraz analiza masowych ilości danych. Dlatego w rozwiązaniach sieciowych nowej generacji powinno się prowadzić także monitorowanie ruchu. Aby skuteczniej zarządzać pracą nowoczesnego centrum danych, duża część ruchu sieciowego musi być skopiowana i zagregowana z portów TAP lub SPAN i przesłana do narzędzi do monitorowania i analizy.
Dostępnych jest wiele pakietów oprogramowania (jak np. Wireshark) oraz rozwiązań sprzętowych do zarządzania wydajnością sieci i analizowania ruchu, wykrywania włamań i wycieków danych, a także dokonywania pomiarów na potrzeby sporządzania raportów stanowiących podstawę do realizacji umów SLA. Ale agregowanie ruchu za pomocą brokerów pakietów sieciowych (NPB) starszego typu nie pozwala w efektywny kosztowo sposób zwiększyć skali rozwiązania, zwłaszcza wtedy, gdy trzeba monitorować wszystkie szafy rack, a szczególnie znajdujące się w różnych lokalizacjach.
Rozwiązanie problemu gwarantuje otwarty, wydajny i skalowalny system do monitorowania Big Monitoring Fabric firmy Big Switch Networks, bazujący na koncepcji Software Defined Networking. Kontroler Big Monitoring Fabric, który może być zainstalowany na wydajnych przełącznikach HPE Altoline, upraszcza zarządzanie siecią monitorującą oraz umożliwia ekonomiczne weryfikowanie poprawności pracy sieci w centrach danych za pomocą kilku tysięcy portów TAP i SPAN.

Istnieje szereg korzyści z zastosowania rozwiązania Big Monitoring Fabric do monitorowania centrum danych. Najważniejsze z nich to:

– widoczność całej sieci: dostarczanie ruchu z dowolnego urządzenia TAP/SPAN do dowolnego narzędzia, w dowolnym momencie,

– elastyczność i skalowalność: duża liczba portów 1, 10, 40 i 100 GbE (tysiące w jednej sieci monitorującej),

– udostępnianie sieci wielu grupom użytkowników (multitenancy): umożliwia monitorowanie środowisk
sieciowych przez wiele zespołów (sieć monitorująca jako usługa),

– ogromne uproszczenie operacyjne: udostępnia pojedynczy punkt zarządzania, monitorowania i usuwania błędów za pomocą scentralizowanego kontrolera SDN, eliminując potrzebę konfigurowania box-by-box,

– możliwość programistycznego zarządzania rozwiązaniem: architektura bazująca na REST API zapewnia automatyczne zarządzanie konfiguracją, także na podstawie zdarzeń wykrytych w sieci produkcyjnej,

– wysokie oszczędności: wielokrotna redukcja całkowitych kosztów posiadania dzięki wykorzystaniu przełączników Open Networking, zmniejszeniu liczby brokerów pakietów sieciowych, zoptymalizowaniu użycia narzędzi oraz automatyzacji obsługi SDN.
Do Big Monitoring Fabric można dołączyć urządzenie usługowe Big Mon Service Node z procesorem x86, które uzupełnia całe rozwiązanie o wyspecjalizowane funkcje pakietowe, takie jak deduplikacja, skracanie pakietów, usuwanie nagłówków, maskowanie danych lub wyszukiwanie pakietów na podstawie wyrażeń regularnych. Po podłączeniu do sieci monitorującej kontroler Big Mon automatycznie wykrywa węzeł serwisowy i staje się pojedynczym centralnym punktem zarządzania oraz konfiguracji węzła serwisowego. Ta wysoce skalowalna architektura umożliwia powiązanie wielu węzłów serwisowych w celu tworzenia łańcuchów usługowych albo zwiększenia przepływności lub liczby usług. Rozwiązanie to ma też funkcję tunelowania Generic Routing Encapsulation, dzięki której można połączyć przełączniki w wielu lokalizacjach w jedną wielką sieć lub zbierać dane dotyczące ruchu ze środowisk wirtualizacyjnych.

Artykuł Przełączanie i monitoring sieci zgodnie z najnowszymi trendami pochodzi z serwisu CRN.

W przyszłości
naprawdę ważna stanie się kompatybilność urządzenia z kontrolerem. Takie
podejście umożliwia uzyskanie – przy użyciu stosunkowo tanich urządzeń
– funkcji, w które wyposażone są drogie routery i przełączniki.
Ponadto bardzo istotną cechą rozwiązania jest możliwość tworzenia aplikacji SDN
przez niezależnych deweloperów. Dlatego koncepcja zyskała miano „Cisco killer”.
Jednak wbrew tej opinii uznani wytwórcy sprzętu sieciowego sami wprowadzają
w swoich produktach funkcjonalności SDN i uważają, że jest to
właściwy kierunek rozwoju sieci. Należą do nich m.in. Alcatel-Lucent, Cisco,
Citrix, Dell, HP, IBM czy VMware, a kompletna lista jest dużo dłuższa.

OpenFlow

Obecnie najpopularniejszą specyfikacją wykorzystywaną do
tworzenia takich rozwiązań jest protokół OpenFlow, który umożliwia
administratorom m.in. zdalne kontrolowanie tablicy routingu. Zastosowanie
architektury typu SDN zapewnia przedsiębiorstwom programowanie sieci,
sterowanie ruchem, a także kontrolę i modyfikację aplikacji
w tych sieciach. Administrator może kształtować ruch z centralnej
konsoli bez logowania się do poszczególnych przełączników, więc to dla niego
ważne ułatwienie. Tą drogą da się zmienić dowolne parametry urządzenia, np. priorytety
dla ruchu sieciowego czy blokowanie określonych typów pakietów. Jest to
szczególnie przydatne w środowiskach cloud computing, w których
działają zróżnicowane aplikacje, ponieważ umożliwia elastyczne i bardziej
efektywne zarządzanie ruchem.

Łukasz Bromirski

dyrektor ds. technicznych, Cisco Systems

Kreowanie własnych rozwiązań za pomocą Cisco OnePK będzie
dawało naszym obecnym, jak też nowym partnerom ogromne możliwości połączenia
klasycznych rozwiązań sieciowych ze światem aplikacji. Mamy w Polsce już
cztery firmy i dwie uczelnie wyższe, które zapoznając się z OnePK,
pracują nad swoimi konkretnymi aplikacjami. Dla partnerów Cisco oznacza to
zmniejszenie kosztów wejścia w bardzo zaawansowane integracje rozwiązań
i jednocześnie ułatwienie ich monetyzacji.

Wirtualizacja sieci

SDN przypomina koncepcję rozwiązań do wirtualizacji
serwerów. W obu przypadkach mamy do czynienia z centralnym punktem
sterującym infrastrukturą odpowiedzialnym za zaawansowane funkcjonalności oraz
dodatkową warstwą abstrakcji (wirtualizacji) sprzętu, oddzielającą sprzęt od
działających na nim aplikacji. W przypadku SDN warstwa abstrakcji
umożliwia centralnemu serwerowi komunikację z różnymi kontrolowanymi przez
niego urządzeniami sieciowymi. Taka warstwa jest potrzebna, ponieważ sprzęt
sieciowy może działać pod kontrolą różnych wersji systemów operacyjnych czy
pochodzić od różnych producentów. Wtedy wykonanie określonej akcji na
poszczególnych urządzeniach jest inicjowane różnymi poleceniami. Warstwa
wirtualizacji rozwiązuje problem, tłumacząc polecenia otrzymywane od kontrolera
na komendy właściwe dla danego urządzenia i systemu operacyjnego.

Na tym nie koniec podobieństw. Najpopularniejsze rozwiązania
do wirtualizacji serwerów nie są sprzedawane przez wytwórców sprzętu, lecz
przez firmy oferujące oprogramowanie. Podobny scenariusz jest niewykluczony
również w świecie urządzeń sieciowych. Już teraz na rynku są produkty
takich firm, jak Big Switch Network, Vello czy znanej już w Polsce Vyatta.

Trzeba dodać, że między wirtualizacją serwerów a koncepcją
SDN jest też istotna różnica. Mianowicie urządzenia sieciowe,
w odróżnieniu od serwerów, potrafią się ze sobą komunikować przy użyciu
zaawansowanych, rozwijanych od 20 lat mechanizmów. Dzięki temu mogą koordynować
swoje działanie bez używania centralnego punktu sterującego. Takie podejście ma
kilka zalet, jak choćby odporność na problemy z komunikacją
z centralnym punktem sterującym.

Dlatego zdaniem ekspertów
scenariusz, według którego w sieciach nastąpi rewolucja podobna jak
w świecie serwerów, jest mało realny. W praktyce sieci będę ewoluować
w kierunku rozwiązań hybrydowych, w których wykorzystywane będę
zarówno mechanizmy SDN, jak i komunikacji między urządzeniami sieciowymi.

Rynek kontrolerów

Sercem rozwiązania SDN
jest kontroler. Po pierwsze to na nim będę uruchamiane aplikacje sterujące
urządzeniami sieciowymi. Po drugie kontroler pośredniczy w komunikacji
między programem a urządzeniem sieciowym, wykorzystując do tego otwarty
protokół OpenFlow bądź zamknięty protokół opracowany przez producenta sprzętu
sieciowego. OpenFlow daje możliwość budowy sieci przy użyciu urządzeń różnych
wytwórców, natomiast funkcjonalność sieci będzie zależała w dużym stopniu
od kontrolera.

Mariusz Kochański

dyrektor Działu Systemów Sieciowych, Veracomp

Najpierw SDN będą
wdrażać duzi klienci końcowi, którzy już dzisiaj budują data center,
konsolidują zasoby i wdrażają usługi multimedialne. Dla tych klientów
budowa taniego w utrzymaniu, skalowalnego i bezpiecznego środowiska
już teraz jest priorytetem. To oni zapraszają naszych partnerów na rozmowy
o takich produktach, jak Blue Coat, Silverpeak, F5, Radware czy Extreme
Networks.

Przykładowo kontroler opracowany przez Cisco będzie można
wykorzystać w sieci zbudowanej z urządzeń HP i F5 Networks. Da
się również zastosować kontroler HP w sieci zbudowanej, np.
z urządzeń Cisco i Junipera (warunek: obsługa protokołu OpenFlow
przez urządzenia). To znaczy, że producenci – nie tylko sprzętu sieciowego
– będą ze sobą rywalizować na płaszczyźnie możliwości oferowanych przez
kontroler. Poza tym bardzo ważny będzie ekosystem zbudowany wokół danego
kontrolera i dostępność działających w nim aplikacji.

Producenci będą czynić różne zabiegi, żeby zapewnić przewagę
swoim rozwiązaniom. Przykładem jest platforma Cisco OnePK, której kontroler
może komunikować się z urządzeniami sieciowymi za pośrednictwem OpenFlow
bądź jego zamkniętego odpowiednika opracowanego przez Cisco. W tym drugim
przypadku komunikacja jest możliwa wyłącznie z urządzeniami Cisco.
Wytwórca argumentuje, że obecnie rozwój protokołu OpenFlow został zatrzymany,
a opracowana wersja 1.0 jest bardzo uboga i w wielu miejscach
niedostosowana do wymagań środowisk sieciowych.

Teraźniejszość i przyszłość

Jak każda innowacja
w IT, aby osiągnąć sukces rynkowy, SDN wymaga niezależnej od producentów
standaryzacji. Ten proces zachodzi obecnie, dlatego w ciągu najbliższych
trzech do pięciu lat SDN ma szansę stać się równie popularny w sieciach
firmowych jak obecnie wirtualizacja serwerów centrach danych. Na razie Software Defined Networking można zobaczyć głównie na
prezentacjach, zaś aktualna sytuacja przywodzi na myśl początki protokołu IPv6
czy też początki MPLS, o których dużo się o mówiło, ale właściwie
poza centrami badawczymi i uczelniami nikt nie odważył się zrealizować
komercyjnego wdrożenia. Przyszłość SDN w dużej mierze będzie zależała od polityki producentów urządzeń sieciowych. Od tego, na ile zdeterminowani
będą we wprowadzaniu i popularyzacji produktów tego typu. Obecnie wielu
z nich, mówiąc o SDN, ma na myśli tzw. wsparcie eksperymentalne, co
jednoznacznie pokazuje klientom, że nie jest to jeszcze rozwiązanie do
komercyjnego zastosowania. Trendy rynkowe świadczą jednak o tym, że SDN ma
przed sobą dobre perspektywy rozwoju. Idea SDN, jako rozwiązania
upraszczającego wiele zadań w sieci, powinna zyskiwać na znaczeniu wraz ze
wzrostem popularności wirtualizacji, chmury oraz usług multimedialnych, pozwoli
bowiem na zmniejszenie TCO w obszarze infrastruktury sieciowej.
Oszczędności te będą wynikać nie tylko ze skrócenia czasu konfiguracji
przełączników LAN, ale także z łatwości przenoszenia jej pomiędzy
urządzeniami różnych producentów.

Prymat startupów

Obecnie liderami na rynku kontrolerów SDN są nowo powstałe
firmy, które już przyciągają duże pieniądze. Jedna z takich firm, Nicira,
została w zeszłym roku kupiona przez VMware za 1,2 mld dol. (przejęta
technologia ma ułatwić budowanie środowisk chmurowych). Do gry wchodzą też duże
firmy obecne od lat na rynku. W zeszłym roku HP ogłosiło swoje rozwiązanie
– Virtual Application Networks SDN Controller. Parę miesięcy temu premierę
miała platforma Cisco One, której jednym z elementów jest kontroler SDN.
Światowy zasięg tych firm otwiera przed SDN drogę do szerokiego grona odbiorców.
Według badań IDC w bieżącym roku światowa wartość sprzedaży rozwiązań
Software Defined Networking wyniesie 360 mln dol., ale już
w 2016 r. wrośnie do 3,7 mld dol., na co składa się sprzedaż
kontrolerów, usług wdrożeniowych i powiązanej infrastruktury sieciowej.

Jak zarobić na SDN

SDN otwiera przed rynkiem IT kilka możliwości. Deweloperzy
otrzymują środowisko, w którym stosunkowo prosto tworzy się aplikacje
wprowadzające do sieci nowe funkcje. Można spodziewać się, że część klientów
będzie zamawiała takie programy tworzone wyłącznie zgodnie z ich
wymaganiami. Dla partnerów handlowych możliwości sprzedażowe to początkowo
głównie szkolenia  i wsparcie
konsultacyjne w zakresie możliwości migracji infrastruktury do SDN.
W kolejnym etapie będzie to też implementacja, utrzymanie i rozwój
rozwiązań SDN od strony aplikacyjnej. Od integratora klient będzie oczekiwał
przede wszystkim budowy i utrzymania aplikacji dostosowanych do potrzeb
danej firmy. Ponieważ rynek jest we wczesnej fazie rozwoju, to dobry moment,
aby edukować inżynierów sieciowych w zakresie programowania usług
sieciowych.

Pierwsi klienci

Wdrożenie SDN jest
uzasadnione w dużych i małych środowiskach IT, ale forpocztę
użytkowników stanowią firmy świadczące usługi telekomunikacyjne i dostępu
do Internetu. Na przełomie roku najwięksi światowi operatorzy (m.in. Orange
i Verizon), a także producenci IT i sprzętu telekomunikacyjnego
utworzyli grupę roboczą Network Functions Virtualization (NFV), która ma
sprecyzować wymagania funkcjonalne dla zwirtualizowanych sieci. Koncepcja NFV
jest zgodna z założeniami SDN i ma stać się bazującym na standardach
frameworkiem do wdrażania technologii wirtualizacyjnych w sieciach
operatorskich. Zadaniem grupy jest między innymi zredukowanie liczby wyspecjalizowanego
sprzętu wymaganego do budowy sieci. Pozwoli to nie tylko zmniejszyć koszty
kapitałowe i operacyjne, ale także skrócić czas wprowadzania nowych usług
na rynek, zwiększyć stopę zwrotu, poprawić skalowalność usług
telekomunikacyjnych oraz zminimalizować ryzyko związane z wprowadzaniem
nowych usług.

Wraz ze wzrostem
popularności chmury w Polsce, co nastąpi w perspektywie kilku lat,
architekturą SDN powinni zainteresować się również operatorzy centrów danych
oraz integratorzy. Na przykład może się okazać, że będą oferować w swoich
centrach danych w chmurze niestandardowe rozwiązania informatyczne, które z racji braku ekonomii skali lub
specyfiki lokalnej nie znajdą się w polu zainteresowania dużych
producentów IT. Natomiast dzięki właściwościom SDN można nie tylko szybciej
wprowadzać nowe usługi, ale także lepiej dostosować je do wymagań klienta.

Można podjąć ryzyko
i już teraz przekonać klient do wdrożenia SDN. Dzięki temu, zanim
zareaguje konkurencja, będzie on czerpać korzyści oferowane przez tę nową
technologią. Należy się jednak liczyć z trudnymi początkami
i koniecznością przecierania nowych ścieżek. Alternatywnie, można poczekać
z wdrożeniem, aż dostawcy sprzętu i oprogramowania udoskonalą swoje
produkty.     

Marcin Ścieślicki

Business Development Manager HP Networking w HP

HP w najbliższym czasie planuje zacieśnić współpracę swoich
centrów badawczych z polskimi uczelniami celem edukacji studentów
w zakresie rozwiązań SDN oraz OpenFlow. Następnym etapem jest przekazanie
naszym partnerom urządzeń demonstracyjnych i edukacja także tej grupy. Przełomem
w popularyzacji komercyjnych rozwiązań SDN będą na pewno pierwsze krajowe
referencje, które powinny pojawić się już niedługo.

Artykuł W sieci najważniejszy będzie software pochodzi z serwisu CRN.