Czy ACI, NSX i Inne Twory Przyjmą Się w Polsce: Część II

Jeżeli zastanawiasz się nad tym, czym Cisco ACI i VMware NSX znajdzie miejsce w polskich przedsiębiorstwach… to nie znajdziesz tej informacji tutaj. Natomiast znajdziesz tutaj dość interesującą rozmowę bazujących na doświadczenia Maćka Lelusza i Mirka Burnejko o tym czy i jak podejść do tematów SDN w Polsce.

Część pierwsza: Dwóch Zgryźliwych Tetryków – Czyli Rozmowa o Poszukiwaniu Miejsca dla SDN w Realiach Polskiego IT.

Zaczynamy.

MB: Microsoft zbudował własnego SDN-a opartego o BGP, o czym Petr Lapukhov opowiada w podcaście PacketPushers. Zbierając to do kupy SDN-a od Cisco/VMware nie chce Microsoft, nie chce Google, nie chce Facebook.
Kto tego potrzebuje? Operatorów w Polsce temat SDN nie interesuje, przynajmniej na razie i nikt nie chce o tym słyszeć. Bliżej jest to Network Functions Virtualization (NfV), o czym za chwilę, ale SDN-a nadal nikt nie potrzebuje…

Robiłem nawet spotkania z klientami i rozmowy na przykładzie use case. Dla przykładu potrzebujemy rozwiązania do ochrony DDoS. Stawiamy urządzenie Radware, które dostaje informacje od przełączników po OpenFlow, że dzieje się coś złego (tu pośrednio wykorzystywany jest jeszcze Cisco XNC). Po analizie wstrzykiwana jest informacja do kontrolera/przełączników, że ruch X ma zostać przekierowany do scrubbing center, lub do kosza…. Fajnie to brzmi, fajnie to działa, jest nawet demo, ale nie.

ML: Czyli dla nich (Operatorów) jest to w ogóle nie atrakcyjny temat. Oni nie czują tego klimatu. Ale dlaczego? To nie ta skala? Czy to nie jest ten problem?

MB: Nie ta skala, nie ten problem, ale też… Zobacz, mamy rok 2014. MPLS powstał w 1998, IPv6 w 1996. Zobacz, w jakim czasie to się wdraża. Po 20 latach mówimy, że to dopiero się wdraża. Zaczynamy migracje. Rozmawiam z jednym operatorem, który jeszcze nie ma MPLSa, nie miał takiej potrzeby. Dopiero teraz zaczyna to wdrażać, ale tylko dla tego, że klienci wymagają MPLSa…. 16 lat po wyprodukowaniu standardu w formie RFC.

ML: I obawiasz się, że tak samo będzie z NSX-em, ACI, lub ogólnie pojętym SDN-em?

MB: Tak.

ML: A overlay networks?

MB: Jestem przekonany, że VXLAN-y się przyjmą. Byłem sceptyczny, patrząc na rozmiary polskich sieci. Zmieniłem zdaniem, jak mi opowiedziałeś (na ostatnim PLNOG) o swoim problemie łączenia środowisk wirtualnych i fizycznych. To jest zajebisty temat.

ML: To jest bardzo fajny temat. Będę mówił o NSX-ie, bo go znam, chociaż tak naprawdę, podobnie jak ACI, nikt go nie zna. Znają go pracownicy Niciry, którzy zostali pracownikami VMWare.
Z perspektywy takiego SDN-a, jedyny uzysk jak na razie to automatyzacja konfiguracji wirtualnej sieci, którą można osiągnąć różnymi metodami. Możesz robić konfigurację VXLAN-ów przez API, zestawem komand na Nexus 1000V, vShield-em, vCNS-em. Jest szereg opcji i tak naprawdę NSX to taka nakładka.

MB: A czy chciałbyś, aby w Twojej firmie nagle sieciowcy zaczęli mówić do programistów: „To jest Twoje API, tu masz SDN, twórz sobie usługi, dla swoich aplikacji”?

ML: Tak było do tej pory. Na przykład przy pomocy vCNS-a, mogłeś tworzyć VXLAN-y, za pomocą swojej aplikacji, czy strony internetowej. Teraz masz upakowany pełny, konkretny produkt. Dostajemy pakiet oraz dodatkowe opcje, jak np. routery. Pytanie natomiast brzmi, kto będzie tego używał? Kto się na to odważy? Być może mali dostawcy cloud-owi, którzy będą chcieli to wdrażać u siebie, stawiając kilka serwerów wirtualnych i startując biznes.

MB: Powiedz mi, orientowałeś się w cenach NSX-a?

ML: Nie ma cen NSX-a.

MB: Mali operatorzy oszczędzają na wszystkim.

ML: No tak, sami sobie to napiszą. Masz rację. Mali operatorzy odpadają. Jest to profil firmy, która sama sobie to stworzy. Duży operatorzy (cloud) też odpadają, bo to nie jest temat dla nich. Mają armię ludzi, która może to zrobić. W szczególności, gdy pojawiają się firmy, które świadczą wsparcie dla rozwiązań open source, takich jak OpenStack.
Dzięki Bogu, NSX będzie mógł pracować z OpenStack-iem, tak jak większość SDN-owych rozwiązań na rynku.

MB: Nadal nie mogę znaleźć rozwiązania. Pewnie jakby tu usiadł z nami TME/PM z Cisco, lub z VMware-a, to znalazłby zastosowanie WSZĘDZIE.

ML: Na szczęście ich tu nie ma… Ze wszystkich informacji, które znalazłem w Internecie oraz rozmów, zawsze pojawia się temat, że przy skalowaniu L2 temat SDN-owy będzie wygodny, tj. w temacie robienia olbrzymiego kontenera L2 pomiędzy kilka ośrodków. Ale z tego, co rozumiem, jest to tak samo wygodne jak skalowanie domeny L2 za pomocą zwykłych VXLAN-ów.

MB: Sieć over IP 🙂

ML: Sieć over IP 🙂 Moja prymitywna definicja  Idąc dalej, siecią overlay-ową jesteśmy w stanie osiągnąć dystrybucyjny routing, między hypervisor-ami. Distributed Router działa na każdym hypervisor-rze, ma pełną tablicę MAC i jest modułem kernela (np. w NSX-ie).

MB: Ale o wszystkich MAC-ach?

ML: Z mojej wiedzy tak. Nie wyobrażasz sobie tego?

MB: Mogę wyobrazić, ale przypomniało mi się coś innego  Na ostatnim Cisco Forum w Zakopanem, pojawił się Product Manager od Nexus-ów z USA. Poruszył temat, skąd się biorą pewne funkcjonalności. Po co takiemu Nexus-owi 7700 aż 192 porty 100G?

ML: OPZy? (Opis przedmiotu zamówienia )

MB: Nie. Są klienci, typu Bank of China, którzy mówią, że potrzebują np. 1000 przełączników, z których każdy ma minimum 120 portów 100G…. Wszyscy na sali wydali pomruk. I teraz do takiej Niciry (NSX), czy Insieme (ACI), przychodzi kolos i mówi, że potrzebuje rozwiązania. Tak jest najczęściej. Duża partia funkcjonalności, sprzętu idzie do największego operatora, największego banku, a „ochłapy” są dla małych krajów i dla małych klientów…. Spróbuj Ty Maćku wynegocjować jakąś nową funkcjonalność w Cisco, np. na Nexus 9000.

ML: No tak. Musiałbym zamówić ich dwa tysiące (mógłbym wybudować ekologiczny dom z Nexus-ów, Nexus, jako najdroższy na świecie materiał budulcowy).

MB: Widzisz, marketingowo NSX i ACI bardzo fajnie wygląda, jak i wiele innych pomysłów. Może się bardzo mylę. Ty pewnie uważasz, że się będę mylił, ale chyba w Polsce nie ma miejsca na rozwiązania ala ACI i NSX.

ML: Jest to za duże rozwiązania na za małe potrzeby.

MB: Raczej zbyt skomplikowane duże rozwiązanie, łatwa w zarządzaniu. Pytanie tylko, czy do tego procesu zarządzania kiedyś dojdzie. Powiedz mi, wdrażałeś pewnie coś w bankach?

ML: Mają zatwardziałe reguły.

MB: Np. wdrożenie przełącznika = czas trwania projektu 6 miesięcy.

ML. Boisz się tego, że opór materii, nawet przy spełnianiu wymagań i potrzeb biznesu, będzie zbyt potężny?

MB: Nie wiem 🙂

ML: (Śmiech)

MB: Maćku, a czy Ty w bankach widzisz miejsce na NSX-a? Tylko nie myśl o VXLAN-ach, ale o czegoś w rodzaju kontenerów, w których developerzy będą umieszczać swoje aplikacje.

ML: Widzę. To jest chyba największy temat w sektorze bankowym. Oni chcą mieć separację. Z punktu widzenia administratorów aplikacji, chcą zarządzać również siecią, bo problemem dla nich jest to, że dział sieciowy i bezpieczeństwa jest dziwnym i powolnym działem…. Ale jest jeszcze siła władzy, o której zapominamy.

MB: Ale spotkałeś się z tym, że programiści chcą zarządzać siecią?

ML: Oni nie chcą ją zarządzać… Oni chcą mieć nad nią kontrolę (złowieszczy śmiech).

MB: Standardowy problem. Programiści, sieciowcy, bezpieczniki, systemowcy. Nikt nikogo nie lubi.

ML: Ale widzisz, mam styczność z bankami. NSX adresuje problem „chcicy” władzy……… cdn.