Usługi dostarczane przez operatorów chmury publicznej nie zawsze są dla nas wystarczające. W takich przypadkach musimy sięgnąć po NVA, czyli wirtualne odpowiedniki znanych nam fizycznych urządzeń sieciowych.

W chmurach publicznych znajdziemy wiele usług sieciowych. Także takich, które są próbą wiernego odwzorowania działania klasycznych urządzeń sieciowych, np. firewalli czy load balancerów. Zazwyczaj jednak usługi te mają swoje ograniczenia lub wprowadzają jedynie część funkcjonalności, które znamy z fizycznych lub wirtualnych urządzeń działających w naszych centrach przetwarzania danych. Bardzo często też funkcjonalności zapewnione przez dostawcę chmury nie są wystarczające. Czy zatem istnieje możliwość uruchomienia własnego routera, firewalla czy sondy IPS w chmurze publicznej? Często jest to możliwe, ale także ma swoje specyficzne ograniczenia.

> Istota NVA

Zacznijmy od tego, że Network Virtual Appliance jest tak naprawdę maszyną wirtualną. Nawet jeżeli za jego pomocą realizujemy takie same usługi jak w przypadku typowej usługi chmurowej, to z naszego punktu widzenia jako administratorów, użytkowników, a także osób, które płacą za tę usługę, mamy do czynienia z maszyną wirtualną. Zatem to do nas będzie należało utworzenie takiej maszyny, aby zapewnić wystarczające zasoby do realizacji przeznaczonych jej zadań. Dlatego też nieodłącznym elementem każdego urządzenia typu NVA są takie parametry jak przypisana do urządzenia pamięć RAM, liczba wirtualnych procesorów i interfejsów sieciowych, a także przestrzeń dyskowa.

NVA to nie tzw. usługa chmurowa, czyli implementacja pojedynczej funkcjonalności lub zespołu funkcji w postaci usługi, którą rozlicza się zgodnie z czasem użycia, jest łatwo skalowalna i powiązana bezpośrednio z innymi usługami chmurowymi. Spójrzmy na przykłady – Azure Public Load Balancer, Azure Internal Load Balancer czy Azure Application Gateway to różne usługi load balancerów, które realizowane są jako usługa chmury publicznej Azure. Każda z tych usług ma inne zastosowanie i zaimplementowane odmienne funkcjonalności. Zarządzamy nimi albo przez panel konfiguracyjny, albo poprzez zautomatyzowane skrypty korzystające z API chmury. Administratorzy mogą jednak decydować się na skorzystanie z load balancera innego niż dostarczany przez dostawcę chmury publicznej. W takiej sytuacji we własnym zakresie mogą wdrożyć na przykład BIG-IP LTM firmy F5. Taki load balancer to właśnie urządzenie NVA. Urządzenia, które najczęściej są uruchamiane w chmurze publicznej jako NVA, to firewalle, sondy IPS, WAF-y i load balancery.

> Zalety korzystania z NVA

Dlaczego administratorzy decydują się na uruchamianie własnych wirtualnych urządzeń sieciowych, zamiast korzystać z dostępnych rozwiązań w chmurze publicznej? Z kilku powodów. Najczęstszym z nich jest konieczność wdrożenia funkcjonalności, których usługi chmurowe nie są w stanie dostarczyć. Jeszcze parę lat temu administratorzy rozwiązań w Azure czy AWS instalowali wirtualne routery i firewalle, by zapewnić połączeniom VPN algorytmy szyfrowania oparte na nowoczesnych algorytmach i długie klucze szyfrujące. W tamtym czasie usługi takie jak Azure VPN Gateway czy AWS Virtual Private Gateway oferowały jedynie ograniczony zestaw predefiniowanych algorytmów. Dlatego administratorzy, którzy musieli wdrożyć wskazane niedostępne w chmurze parametry szyfrowania, sięgali po NVA. Podobna sytuacja ma miejsce, gdy mówimy o zaawansowanych funkcjonalnościach load balancerów, szczególnie tych z wbudowanymi modułami WAF czy z sondami IPS. Te ostatnie nie są w ogóle jako takie dostępne w Azure ani AWS. Co prawda Microsoft w ramach chmury Azure oferuje rozwiązanie Azure Firewall z modułem Threat Intelligence, lecz nie jest to sonda IPS, która skanuje zawartość (payload) przesyłanych pakietów.

Kolejnym powodem wyboru NVA (zamiast równoważnej usługi chmurowej) jest konieczność spełnienia przez administratorów standardów i wytycznych dotyczących bezpieczeństwa. Firmy bardzo często mają dokładnie wyszczególnione, jakie mechanizmy bezpieczeństwa i w których segmentach sieci muszą być wdrożone, zanim połączenie zostanie dopuszczone do serwera z aplikacją. Te wymagania zespoły sieciowe i systemowe przenoszą na konkretne rozwiązania i produkty, które stosują we własnych serwerowniach. Bardzo często najprościej jest przenieść rozwiązanie, które zostało sprawdzone we własnej serwerowni bez większych zmian do chmury publicznej. Równie ważną rolę odgrywa tutaj kwestia kontroli nad rozwiązaniem. Uruchamianie własnych NVA pozwala administratorom na pełną kontrolę nad oprogramowaniem i konfiguracją usług sieciowych. Może to być szczególnie istotne w przypadku aplikacji o wysokich wymaganiach bezpieczeństwa lub specyficznych wymaganiach sieciowych.

Administratorzy mogą wybrać też wdrożenie wirtualnych urządzeń sieciowych, aby ułatwić sobie zarządzanie infrastrukturą. Zazwyczaj będą to urządzenia, które już wykorzystują w swojej sieci lokalnej czy własnym centrum przetwarzania danych. Wiedzą zatem, jak nimi zarządzać, mają gotowe szablony konfiguracji, a niejednokrotnie także zautomatyzowane skrypty, których używają w codziennej pracy. Rozwiązań chmurowych musieliby się od podstaw uczyć, co na pewno prowadziłoby do możliwości popełnienia błędów oraz konieczności biegłego opanowania konfiguracji i monitoringu usług chmurowych.

Wielu administratorów może skusić też chęć obniżenia kosztów, co jest pewnego rodzaju paradoksem. Co do zasady wirtualne urządzenia sieciowe nie są tańsze niż odpowiadające im natywne usługi chmury publicznej (o czym więcej w ramce Koszty wirtualnych urządzeń). Jednakże ze względu na ograniczone funkcje tych drugich może się zdarzyć, że wszystkie niezbędne dla nas funkcjonalności uzyskamy, dopiero gdy wdrażamy dwie lub więcej z nich. W takim wypadku koszt uruchomienia i obsługi pojedynczego urządzenia NVA może być niższy niż sumaryczny koszt wszystkich niezbędnych usług chmurowych.

> Wady używania NVA

Jedna z największych wad używania wirtualnych maszyn typu NVA to pozbawienie się zalet typowej usługi chmurowej związanej z automatyzacją konfiguracji i skalowalnością. To do nas jako administratorów będzie należało odpowiednie przypisanie parametrów maszynie wirtualnej. W zależności od uruchamianego NVA będziemy mieli pełną dowolność w jego konfiguracji lub będziemy musieli wykorzystać jedną z predefiniowanych maszyn wirtualnych, które są przeznaczone dla wybranego przez nas NVA-u. Nie każde zwirtualizowane urządzenie sieciowe pozwala na dowolne ustalenie parametrów maszyny wirtualnej, na której zostanie uruchomione. Co więcej w wielu przypadkach, jeżeli będziemy chcieli zmienić rozmiar maszyny wirtualnej, potrzebując np. większej mocy obliczeniowej w związku z rosnącym ruchem sieciowym, które dane urządzenie ma obsłużyć, to będziemy musieli utworzyć i skonfigurować całkowicie nową maszynę wirtualną, a nie jedynie zmodyfikować zasoby już istniejącej. Większość NVA nie pozwala na dynamiczną zmianę przypisanych do nich zasobów. Pamiętajmy też, że zasoby przypisane do takiej maszyny powinny być przydzielone konkretnie dla niej, a nie współdzielone. W szczególności powinniśmy unikać wykorzystywania maszyn wirtualnych z oversubskrypcją. W chmurze Azure są to maszyny typu B. Charakteryzują się one tym, że zasoby określone w specyfikacji maszyny nie są dostępne cały czas, a jedynie w okresach, gdy oprogramowanie wymaga zwiększonej mocy obliczeniowej. Gwarantowana moc obliczeniowa stanowi jedynie ułamek mocy maksymalnej. Stosuje się w nich mechanizm tokenów, które przypisywane są do urządzenia w okresie, gdy pracuje ono z mniejszą wydajnością. Maszyna wirtualna może okresowo pracować, używając maksymalnie 100% procesorów wirtualnych, gdy aplikacja wymaga wyższej wydajności procesora, zużywając zakumulowane tokeny aż do ich wyczerpania.

[...]

Autor specjalizuje się w rozwiązaniach routing & switching, data center oraz service providers. Promuje automatyzację w środowiskach sieciowych i udziela się jako deweloper w projektach open source. Jest twórcą modułów do Docker Swarm w Ansible i jednym z opiekunów modułów w community.docker. Pracuje jako niezależny konsultant IT. Posiada certyfikat CCIE.