VMware NSX – Sieć w modelu IaaS

Myślę, że cykl o VMware NSX warto rozpocząć od nakreślenia problemu, ma on rozwiązać. Zacznijmy, więc od aplikacji, bo w zasadzie cała sprawa SDN, wirtualizacji i całej reszty najnowszych technologii krąży wokół tego tematu. Wyobraźmy ją sobie, jako zegarek, cholernie skomplikowany mechaniczny zegarek. Użytkownicy zarówno aplikacji, jak i tego małego cuda techniki nie mają, i zazwyczaj nie chcą mieć pojęcia, co dzieje się pod jego tarczą. Wystarczy, aby wyglądał odpowiednio dostojnie i umożliwiał przeczytanie godziny. Podobnie jest z aplikacją – komplikacja mechanizmów działających w celu jej prezentacji nie obchodzi nikogo oprócz nas i nam podobnych. Tak, więc im bardziej nasze środowiska są skomplikowane tym bardziej my mamy przechlapane, gdyż dla użytkowników aplikacja na ona działać, a dla zarządu zarabiać pieniądze.

Do obsługi naszej aplikacji posiadamy i będziemy musieli posiadać, przynajmniej w perspektywie najbliższej przyszłości, rozwiązania przeniesione z zwykłych, nie zwirtualizowanych sieci w naszą sieć wirtualną. Tak, więc musimy przyjąć, że aktualny, dosyć skomplikowany model/stos sieciowy wypadałoby zmapować w architekturę chmury, rozwijając go o elementy związane z specyfiką SDN i samej idei IaaS.

Zacznijmy, więc od tego, co mamy aktualnie na naszym podwórku i co de facto będzie wymaganiem w nowej, nadchodzącej architekturze IaaS. Posiadamy, więc:

• Routery,
• Load-balancery,
• Firewalle (na brzegach podsieci jak i na poziomie VM),
• Przeplatające się warstwy L2/L3,
• NAT,
• VPN,
• Podsieci.

Powyższe elementy są niezbędne żeby nasza sieć mogła zostać przeniesiona w chmurę, nie narażając programistów na odwodnienie poprzez paniczną biegunkę połączoną z gorączką. Innymi słowy nie zmuszając ich do przepisania aplikacji, czy zrezygnowania z starych „dobrych” przyzwyczajeń.

Powyższe elementy, są dla nas niezbędne, aby nasza sieć bez rewolucji w aplikacjach mogła zaistnieć w modelu SDN. Tych elementów ma nam dostarczyć sam system SDN. To kwestia „odfizyczna”, czerpiąca całym swym jestestwem z przeszłości… W takim razie, dlaczego w ogóle potrzebujemy SDN skoro to ten sam koncept przeniesiony z softu w blachę? Cóż, nie do końca tak jest. SDN w tym VMware NSX jest odpowiedzią na potrzeby IaaS, które, przez ich skomplikowanie, niezwykle trudno jest realizować w infrastrukturach fizycznych.

Tak, więc rozpocznijmy od tego, jakie wymagania narzuciła idea IaaS zarówno na sieci tradycyjne jak i SDN:

1. Swobodna migracja VM między hypervisorami (VMotion),
2. Szybkie tworzenie nowych sieci/maszyn wirtualnych, zmian w infrastrukturze,
3. Elastyczność i skalowalność,
4. Dynamiczne, nielimitowane rozlokowywanie VM,
5. Całkowita separacja zasobów klientów (multitenancy),
6. QoS.

A tak, że co one implikują:

1. L2 w całym DC,
2. Segmenty i sieci muszą być stworzone w ciągu kliku sekund,
3. Wybór technologii nie powinien limitować skali i ilości aplikacji,
4. Ogromne segmenty sieci,
5. Limit ~4000 VLAN’ów, a co za tym idzie i klientów/aplikacji,
6. Zabezpieczenie się przed zjawiskiem tzw. głośnego sąsiada.

Można, zatem uznać, że sytuacja idealna jest wtedy, gdy każda aplikacja zamknięta w jednym tenantcie, oraz każda VM może pracować na dowolnym hoście w dowolnym miejscu sieci. Pamiętajmy jednak, że w każdej umowie jest drobny druczek, wiec nie zapomnijmy o tym również i tu. Sytuacja idealna wiąże się bowiem z zachowanie aktualnego modelu operacyjnego sieci wraz z adresami IP, mechanizmami bezpieczeństwa itd. itp., oraz utrzymaniem SLA na kuriozalnym poziomie 99,999(9)% wraz z łatwością zarządzania i obniżeniem kosztów…

Dlaczego zatem VLANy nie są wystarczające? W końcu aktualnie są to filary naszej sieci. Odpowiedz wydaje się wypływać z jednego z niezaprzeczalnych praw natury mówiącego, że wszystko w naturze, wszystkie procesy działania wybierają zawsze najkrótszą drogę. Piorun przebija się z nieboskłonu do najwyższego punktu na horyzoncie, woda z kranu spada po najkrótszej linii uderzając w porcelanę zlewu, programista zawsze wybiera najmniej skomplikowaną i zoptymalizowaną metodę, a administrator zawsze będzie chciał zrobić coś najszybciej i przy spaleniu jak najmniejszej ilości dżuli. Tajemnica życia 😉

Tak, więc przede wszystkim chodzi o manualną konfigurację wszystkich podsieci, mechanizmów bezpieczeństwa, zarówno po stronie sieci wirtualnej jak i fizycznej. Oczywiście można to jakoś automatyzować – producenci proponują różne rozwiązanie pozwalające na orkiestrowanie tego procesu, niektóre z nich działają lepiej niektóre gorzej… Przyjmijmy jednak, że wydając pierdylion złotych i oddając nasze zdrowie jakoś udaje nam się to wszystko zautomatyzować. To jednak wciąż mamy dosyć twarde limity. Nie mówię tu nawet o STP czy o single brodcast domain, czy też single failure domain. Po drugie, trzeba dbać o naszą infrastrukturę, co bywa przy dużej skali i skomplikowaniu zadaniem iście tytańskim, konsumującym ogromne ilości zasobów. Po trzecie mamy te nasze 4000 VLANów. Ich ilość wydaje się dosyć dużą liczbą, jednak, gdy przyjmiemy, że dla zwykłej aplikacji webowej potrzebujemy przynajmniej czterech vlanów (dostęp, serwery web, app, db) i podsieci to z 4000 VLANów robi się 1000 aplikacji, co już nie jest taką imponującą liczbą.

Natomiast, co ciekawe następny problem, który napotykamy na drodze skalowalności jest nieco bardziej subtelny i wielu z nas nie jest go nawet świadomych. Otóż zazwyczaj adresy MAC wszystkich VM są widoczne przez nasz rdzeniowy przełącznik L2. Wypada tu sprawdzić jak producent waszych urządzeń sieciowych radzi sobie z obsługa dużej ilości mac na jednym przełączniku. Różni producenci różne liczby – może się okazać, że w waszym switchu skończy się miejsce na MAC i zaocznie on zalewać siec pakietami podnosząc jej obciążenie.

Kolejnym elementem jest fakt, że hypervisor zazwyczaj nie używa mocy obliczeniowej hardware’u karty sieciowej do odbierania ruchu dla wszystkich maszyn wirtualnych. Sytuacja te ma miejsce, gdyż karta sieciowa to prosty byt i na swoim małym chipsecie nie obsłuży ona więcej niż kila adresów MAC. Wyobraźmy, więc, że mamy sytuację gdzie posiadamy setki VM na jednym hypervisorze. Ze względu na niewielką ilość sprzętowo obsługiwanych MAC karta natychmiast jest przełączana w tryb promiscuous. Którego wyjaśniania nie muszę chyba tłumaczyć, jeżeli oczywiście ktoś próbował w akademiku podsłuchać hasło kolegi 😉 Generalnie karta przechodząc w tryb słucha całego ruchu i odbiera ruch sieciowy, który dla hypervisora jest kompletnie nie istotny… musi on jednak na pakiet rzucić okiem a to spala niepotrzebne cykle w CPU w przerwaniach itp.

Idąc krok daje… Mamy standardową sytuację, w której nikomu nic się nie chce, tak, więc na wszystkich portach przełącznika, które idą do hyperviorów mamy skonfigurowane wszystkie VLAN’y. Brzmi znajomo? W takiej, więc sytuacji hypervisor musi przetworzyć wszystkie pakiety ze wszystkich VLAN’ów nawet, jeśli niema on żadnej aktywnej VM w danym VLANIE. Gdy spojrzymy na to z punku widzenia skalowalności jest to rozwiązanie dosyć słabe… przypomina sytuację jednego VLANU rozciągniętego na wszystkie urządzenia w warstwie 2.

Można się wykłócać ile to jest dużo hostów w jednej domenie rozgłoszeniowej jednak RFC 5556 dotyczące TRILL’a mówi jasno. 1000 hostów, co w naszym przypadku oznacza 1000 VM, a to już znów nie jest tak dużo. Czyli jak mamy do 1000 VM możemy używać VLAN’ów i odpuścić lekturę, ale jak mamy więcej… cóż trzeba ci czegoś innego.

Dobrze, jeżeli wciąż tu jesteście to mogę przyjąć, że albo bawimy się w science-fiction albo faktycznie osiągnęliśmy limity standardowej sieci. Co dalej? Przemysł sieciowy jest na to gotowy. Już słychać brzęk, a raczej szelest pieniędzy, które wydamy na rozwiązania zapobiegające problemom siec w skali makro. Potrzebujemy przecież zaledwie kilka mechanizmów…

Tak, więc problem z STP? Niema problemu mamy przecież TRILL’a, czy SPB w odmianach serwowanych przez Cisco (FabricPath), VCS Fabric (Brocade) i Qfabric Juniper i możemy nim zrobić routing w warstwie drugiej oparty o stary i nieśmiertelny IS-IS. Problem z VLANAmi na portach? Nic prostszego mamy tutaj szereg technologii z rodziny EVB – VM-FEX, VM tracer, HyperLink które zabezpieczą nas przed problemem wszytkich VLANów na każdym porcie przełącznika do każdego hypervisora. Za mało VLAN’ów, niema problemu dorzucimy dodatkowe VLAN tagi, za pomocą standardu Q-in-Q. Niedobrze też jest, że napotykamy limit MAC w architekturze, ponieważ wszystkie przełączniki wiedzą o wszystkich przełącznikach. Spoko! To też mamy rozwiązane – PBB (Provider Backbone Bridge) pozwoli na rozwiązanie w stylu X-zibita – zainstalowanie MAC adresu w inny MAC adres. Ciągle za mało? Mam też możliwość zdejmowania VLAN’ów w core sieci poprzez MVRP/VTP, kontroli burz broadcastowych, BPDU, ECMP i tak dalej i tak dalej… i tak na końcu będziecie mieli dalej jedną domenę broadcastową a co za tym idzie jedną domenę awarii.

Prawda, że to daje nam niezwykle prostą infrastrukturę? Oczywiście każdy z tych elementów kosztuje i wymaga lub nowego sprzętu lub dodatkowej licencji. Generalnie jak to zwykle bywa musimy wydać kwadrylion złotych, aby w perspektywie 1000 lat oszczędzić 200 zł, a de facto zyskać kompletnie nic.

Pytanie czy jest inna możliwość rozwiązania tego problemu? Otóż Panie i Panowie tak. Odpowiedzią są programowo definiowane sieci a w śród nich między innymi VMware NSX.

Źródła:

• http://vmwarewalkthroughs.com/NSX/
• http://www.hypervizor.com/2013/11/solution-architecture-vmware-nsx-6-0-with-vcloud-director-part-2-of-2-remote-vpn-access/
• http://www.vmguru.nl/wordpress/2013/11/how-to-install-vmware-nsx/
• http://www.vmguru.nl/wordpress/2013/11/introduction-to-vmware-nsx/
• http://searchvmware.techtarget.com/definition/VMware-NSX
• http://www.ipspace.net
• http://blogs.vmware.com/networkvirtualization/2013/09/vmware_nsx_cisco.html
• http://www.hypervizor.com/2013/10/solution-architecture-vmware-nsx-6-0-with-vcloud-director-part-1-of-2/
• http://blogs.vmware.com/networkvirtualization/2013/08/vmware-nsx-partner-ecosystem.html
• http://bradhedlund.com/2013/01/28/network-virtualization-a-next-generation-modular-platform-for-the-virtual-network/
• http://www.vmware.com/files/pdf/products/nsx/vmw-nsx-network-virtualization-design-guide.pdf