Software-Defined...

SDN w zderzeniu z rzeczywistością

SDN w zderzeniu z rzeczywistością

Rozmowa z Brianem Levy, europejskim dyrektorem ds. technologii w Brocade Communications. Rozmawiamy o przyszłości architektury sprzętu i oprogramowania sieciowego, oczekiwaniach klientów związanych m.in. z wirtualizacją oraz różnych scenariuszach wykorzystania rozwiązań opartych na koncepcji Software-Defined Networking oraz Network Functions Virtualization. Dyskutujemy także na temat kierunków rozwoju architektur aplikacyjnych w związku z upowszechnieniem się trendów SDN i NFV.

 
W jakim kierunku zmierzać będą technologie sieciowe w najbliższym czasie? Brocade wydaje się niewzruszony trwającą rewolucją. Czy to dlatego, że obszar technologii IP jest w Brocade nieduży, czy też z powodu wczesnej inwestycji w firmę Vyatta i jej platformę SDN?

Odpowiem najpierw na drugą część pytania. Nasz biznes w obszarze IP wcale nie jest mały, bynajmniej, a do tego szybko rośnie. Nie jesteśmy może największym producentem rozwiązań sieciowych na świecie, ale należymy do firm będących w wśród awangardy technologicznej i mamy klientów z listy Fortune 500. Jeśli chodzi o Vyatta, jej platforma SDN/NFV bez wątpienia zajmuje czołową pozycję. Cieszymy się, że mamy zespół i produkty Vyatta na pokładzie, ale przyszłość to nie tylko Vyatta.

To znaczy, że…

Chodzi o to, że wirtualizacja jako usługa wysokopoziomowa nie jest atrakcyjna, jeśli nie towarzyszy jej wysoka wydajność połączeń na poziomie sprzętu. Wartość wirtualizacji leży w elastyczności, możliwości dynamicznej rekonfiguracji topologii aplikacji zgodnie ze zmieniającymi się potrzebami. Tradycyjne sieci oparte na hierarchicznej logice i fizycznych portach są trudne do rekonfiguracji, a przez to utrudniają realizację korzyści, które wirtualizacja obiecuje. I właśnie dlatego Vyatta, i SDN w ogóle, to tylko jeden z elementów naszej wizji sieci w przyszłości. Innymi słowy, warstwa fizyczna wciąż się liczy.


„Wartość wirtualizacji leży w elastyczności, możliwości dynamicznej rekonfiguracji topologii aplikacji zgodnie ze zmieniającymi się potrzebami. Tradycyjne sieci oparte na hierarchicznej logice i fizycznych portach są trudne do rekonfiguracji, a przez to utrudniają realizację korzyści, które wirtualizacja obiecuje. I właśnie dlatego Vyatta, i SDN w ogóle, to tylko jeden z elementów naszej wizji sieci w przyszłości. Innymi słowy, warstwa fizyczna wciąż się liczy”

Brian Levy


Rozumiem, że nawiązuje Pan do tego, że większość realistycznych scenariuszy wirtualizacji zakłada utrzymanie poszczególnych środowisk w ramach jednej obudowy blejdowej, ewentualnie tej samej szafy?

Tak, ale lokalność przetwarzania to tylko jeden z wielu elementów większej układanki. Weźmy na przykład problem awarii portu. W tradycyjnej sieci przełączanej na poziomie warstwy 2 modelu OSI awaria to awaria – chyba, że użyty zostanie protokół z rodziny Spanning Tree, który pozwoli przywrócić łączność automatycznie. Szkopuł w tym, że to nie dzieje się natychmiast – sesje aplikacyjne są zrywane na długo przed tym, jak łączność zostaje przywrócona. W tym momencie cały zespół osób musi rzucić to, czym się akurat zajmuje i stawić czoła sytuacji. Wirtualizacja nic tu nie pomoże. Oczywiście, teraz robi się snapszoty itd., co pozwala zachować spójność danych. Prawdziwą bolączką jest jednak ilość pracy, jaką trzeba wykonać, by dokonać diagnozy środowiska, następnie zrekonfigurować je, wreszcie dokonać naprawy. Ilość tej pracy jest nieproporcjonalnie duża w stosunku tak trywialnego zdarzenia, jakim jest awaria portu czy coś analogicznego. Takie problemy powinny być rozwiązywane automatycznie, bez wpływu na warstwę aplikacyjną.

Pełna zgoda, ale… to chyba nie wszystko?

Są jeszcze co najmniej dwa obszary, o których chciałbym powiedzieć. Pierwsza z nich to zarządzanie. W tradycyjnej sieci topologia i konfiguracja sieci zarządzane są na poziomie poszczególnych przełączników. Gdy przełączników jest kilkadziesiąt czy kilkaset, zarządzanie operacyjne topologią i konfiguracją staje się koszmarnie złożone. Druga sprawa to perspektywa konsolidacyjna, w której centralną rolę odgrywa wirtualizacja. Jeśli coś pójdzie nie tak, ryzykujemy utratę całego środowiska. Posiadanie centrum zapasowego staje się koniecznością i w typowym scenariuszu do połączenia centrum podstawowego i zapasowego wykorzystywane są usługi Metro Ethernet, zwłaszcza wtedy, gdy składowanie danych opiera się na technologiach innych niż SAN, np. iSCSI. Co się jednak dzieje, gdy Metro Ethernet zaczyna gubić ramki? Takie usługi zapewniają operatorzy, ale nie zawsze są to usługi klasy operatorskiej.

Faktycznie…

Właśnie z tych i wielu innych powodów stworzyliśmy kompleksową architekturę Ethernet Fabric, która adresuje wszystkie większe i mniejsze problemy Ethernetu.

Nazwa sugeruje, że architektura ta obiecuje spłaszczoną topologię, która jest faktem w kontekście zwirtualizowanych centrów danych.

Spłaszczenie występuje tu w kilku znaczeniach. Zamiast hierarchicznej topologii w warstwie 2 w ramach Ethernet Fabric definiowana jest sieć w warstwie 3, w której ruchem zarządzają protokoły oparte na koncepcji stanu łącza, jak OSPF czy IS-IS. Taka architektura jest trudna do przecenienia. Jeśli wspomniany port ulegnie awarii, ruch jest automatycznie kierowany inną ścieżką. Nie ma też problemu ze Spanning Tree. Poza tym, nagle okazuje się, że możemy wykorzystać wszystkie dostępne porty przełączników jednocześnie, a więc zapewnić aplikacjom znacznie więcej pasma. Spłaszczenie dotyczy także zarządzania – zarządzanie topologią i konfiguracją jest koordynowane przez wszystkie urządzenia w sieci. Wszystkie przełączniki znają aktualną topologię i jeśli na jednym z nich zostaną wprowadzone zmiany, wszystkie pozostałe zaaplikują je automatycznie. Ethernet Fabric, zapewnia także Ethernet klasy operatorskiej, który pomogliśmy stworzyć na podstawie naszych doświadczeń z technologią Fibre Channel.


„Zamiast hierarchicznej topologii w warstwie 2 w ramach Ethernet Fabric definiowana jest sieć w warstwie 3, w której ruchem zarządzają protokoły oparte na koncepcji stanu łącza, jak OSPF czy IS-IS. Taka architektura jest trudna do przecenienia. Jeśli wspomniany port ulegnie awarii, ruch jest automatycznie kierowany inną ścieżką. Nie ma też problemu ze Spanning Tree. Poza tym, nagle okazuje się, że możemy wykorzystać wszystkie dostępne porty przełączników jednocześnie, a więc zapewnić aplikacjom znacznie więcej pasma”

Brian Levy


Jak to wszystko ma się do SDN? Jest cała lista potencjalnych scenariuszy… centrum danych, sieci korporacyjne, sieci dostępowe, sieci operatorskie… z kim prowadzicie Państwo rozmowy na temat wdrożeń SDN i jakie opinie słychać z drugiej strony?

Istnieje wiele potencjalnych przypadków użycia, a każdy z nich rozwija się we własnym tempie. Historycznie wydawało się, że SDN będzie głównie technologią dla centrów danych, ale póki co to nie jest najważniejszy obszar zastosowań. Widzimy za to zainteresowanie i konkretne działania ze strony operatorów telekomunikacyjnych.

Co jest motorem tego zainteresowania?

Można wskazać co najmniej dwa ważne powody, dla których operatorzy interesują się SDN. Pierwszy nazwałbym potrzebą przyspieszenia innowacji w dziedzinie usług. Historycznie operatorzy działali w ten sposób, że kupowali dużo sprzętu i stopniowo podłączali do niego klientów. Ten model już nie ma już jednak przed sobą perspektyw, ponieważ konkurencja i popyt zmieniają się szybciej, niż okres amortyzacji sprzętu wykorzystywanego do dostarczania usług. Inaczej rzecz ujmując, firmy telekomunikacyjne chcą móc wprowadzać innowacje w krótszych cyklach i nawiązać walkę konkurencyjną z Amazonami i Googlami, aby uzyskać istotny udział w tym rynku.

Operatorzy nie mogą pozwolić sobie, by dać się zredukować do roli zarządców drutów…

Dokładnie. Marże na tym rynku są zbyt małe i nie pasują do istniejącej struktury kosztów operatorów, nie mówiąc już o tym, że nie odpowiadają oczekiwaniom inwestorów.

Jakieś inne pomysły na SDN?

To o czym rozmawiamy odnosi się głównie do sieci szkieletowych, ale operatorzy mają przecież wielką infrastrukturę dostępową, której zakup i utrzymanie również kosztuje. SDN jest dobrym sposobem na obniżenie kosztów operacyjnych związanych z urządzeniami działającymi po stronie klienta, czyli CPE (Customer Premises Equimpent – przyp. tłum.). Tradycyjne CPE obrosło funkcjami i stało się skomplikowane. W efekcie zarządzanie i diagnostyka stały się bardziej kosztowne. Złożone urządzenia utrudniają także wdrażanie nowych usług, dzięki którym operatorzy mogą poprawiać rentowność. SDN pozwala zredukować urządzenia klienckie do bardzo prostego zestawu funkcji – modemu, bramy głosowej i być może routera Wi-Fi. Wszystkie inne funkcje mogą być scentralizowane za pomocą oprogramowania SDN działającego w lokalnym POP-ie (Point of Presence – przyp. tłum.) lub w centrum danych. Oznacza to potencjalnie bardzo duży spadek kosztów, a jednocześnie zapewnia elastyczność oraz ochronę inwestycji, na której operatorom bardzo zależy.

A co z centrami danych i klientami korporacyjnymi?

Jeśli chodzi o centra danych, a właściwie rynek firm ISP, SDN jest na etapie ewaluacji jako rozwiązanie dla problemów operacyjnych związanych z wielodomenowością oraz faktem, że duże środowiska webowe zmieniają się bardzo szybko. SDN ułatwia dostawcom usług internetowych dostosowanie się do tych zmian. Pozwala także zmniejszyć wydatki na pozyskanie i utrzymanie sprzętu sieciowego. W tym zastosowaniu SDN jest koncepcyjnie spójny z Ethernet Fabric. Jeśli chodzi o segment korporacyjny, dyrektorzy IT wciąż zastanawiają się jak traktować tę nowość. Wydaje mi się, że katalizatorem wykorzystania SDN będą usługi chmurowe, ponieważ SDN to jeden z istotnych czynników, dzięki którym chmura jest tańsza, niż infrastruktura utrzymywana samodzielnie. Firmy korzystające z usług chmurowych korzystają z SDN, tyle że pośrednio. Bezpośrednie wykorzystanie SDN będzie mieć związek z handlem elektronicznym, który stał się kluczowym elementem biznesu wielu firm. eCommerce już nie jest samotną wyspą, ale centralnym obszarem ich działalności. Motorem napędzającym wykorzystanie SDN będą także aplikacje mobilne, dla których elastyczność w warstwie sieciowej jest korzystna.


„Jeśli chodzi o segment korporacyjny, dyrektorzy IT wciąż zastanawiają się jak traktować tę nowość. Wydaje mi się, że katalizatorem wykorzystania SDN będą usługi chmurowe, ponieważ SDN to jeden z istotnych czynników, dzięki którym chmura jest tańsza, niż infrastruktura utrzymywana samodzielnie. Firmy korzystające z usług chmurowych korzystają z SDN, tyle że pośrednio. Bezpośrednie wykorzystanie SDN będzie mieć związek z handlem elektronicznym, który stał się kluczowym elementem biznesu wielu firm. eCommerce już nie jest samotną wyspą, ale centralnym obszarem ich działalności”

Brian Levy


Środowiska SDN i NFV można zaprojektować na wiele sposobów. Czy możliwe jest stworzenie infrastruktury całkowicie programowej?

Myślę, że będzie zależeć o kategorii aplikacji. Do jednych pasować będzie architektura, w której SDN i NFV są ze sobą ściśle powiązane, w przypadku innych korzystniejsze będzie wyraźniejsze oddzielenie sieci od usług i skalowanie ich niezależnie od siebie. To wszystko są kwestie szczegółowe, wokół których koncentrować będą się strategie poszczególnych dostawców konkurujących o różne segmenty rynku. Architektura będzie mieć wpływ na funkcje niskopoziomowe, jak bezpieczeństwo. Na poziomie aplikacji najważniejsze i tak będzie to, co będzie można zrobić za pomocą interfejsów API.

Czy widzi Pan szanse dla aplikacji lub usług tworzonych od podstaw z myślą w celu wykorzystania SDN lub NFV? Interfejsy API to przecież platformy technologiczne, na których można budować kolejne innowacje.

Tak, istnieje przestrzeń dla aplikacji korzystających intensywnie z sieciowych interfejsów API, np. w sferze mobilnej lub wideo. Nie trzeba wielkiej wyobraźni, by uzmysłowić sobie, że telefon komórkowy może być traktowany jako CPE. W takiej sytuacji telefon nie korzysta z sieci, lecz jest jej elementem. Linie podziału między systemami operacyjnymi i usługami sieciowymi coraz bardziej się zacierają, więc takie możliwości zdecydowanie istnieją.


„Nie trzeba wielkiej wyobraźni, by uzmysłowić sobie, że telefon komórkowy może być traktowany jako CPE. W takiej sytuacji telefon nie korzysta z sieci, lecz jest jej elementem. Linie podziału między systemami operacyjnymi i usługami sieciowymi coraz bardziej się zacierają, więc takie możliwości zdecydowanie istnieją”

 Brian Levy


 
Brian Levy, Brocade
Brian Levy, europejski dyrektor ds. technologii w Brocade Communications.