Red Hat OpenStack: Network Function Virtualization (NFV)
Platforma Red Hat OpenStack dość powszechnie wykorzystywana jest przez dostawców usług telekomunikacyjnych, internetowych i telewizyjnych, którzy potrzebują wygodnie oraz wydajnie wirtualizować różne usługi i urządzenia sieciowe. Spotkać można ją też na brzegu (ang. edge) infrastruktury, gdzie w ramach jednego pudełka uruchamiane jest wiele usług wirtualnych.
Funkcje sieciowe (NF - Network Function) pełnione są przez fizyczne urządzenia, jak m.in. przełączniki, routery czy urządzenia typu Firewall. Mają one też swoje odpowiedniki w świecie wirtualnym, które określane są jako Virtual Network Function (VNF). Przykładem VNF jest Cisco Firewall Threat Defence Virtual (FTDv), Cisco ASAv, Cisco Catalyst 8000v, Cisco Secure Email Virtual Gateway (CSEVG), Cisco Secure Web Appliance Virtual (CSWAV) i Cisco Catalyst 9800-CL Wireless Controller for Cloud.
Zatem VNF pełnione są przez wirtualne urządzenia sieciowe, zajmujące się m.in. rozkładem obciążenia, obsługą VPN, wykrywaniem zagrożeń w ruchu, analizą i filtrowaniem ruchu, kierowaniem ruchu czy jego akceleracją.
NFV (Network Function Virtualization) to nic innego, jak wirtualizacji funkcji sieciowych. Jest to coraz modniejsze, zarówno ze względu na szeroką popularność chmur publicznych i prywatnych, jak i wygodną metodę dostarczania wielu różnych funkcji sieciowych i usług w postaci jednego urządzenia brzegowego (edge). Do uruchamiania VNF wymagana jest infrastruktura, w skład której wchodzą m.in. serwery, pamięć masowa i fizyczne urządzenia sieciowe. Jest ona określana jako NVFI (NVF Infrastructure).
Przykładem kompleksowego NVFI jest Cisco Enterprise NFVI Software. Można je wdrożyć na urządzeniach Cisco ENCS (Enterprise Network Compute System), serwerach Cisco UCS oraz modułach serwerowych Cisco UCS-E do urządzeń brzegowych Cisco Catalyst 8000 CPE. Jedną ze składowych tego rozwiązania jest właśnie Red Hat OpenStack Platform. Rozwiązanie to nadaje się do zastosowań zarówno w przedsiębiorstwach, jak i u operatorów czy dostawców usług komunikacyjnych. Oczywiście, platforma Red Hat OpenStack może pełnić opisane tu funkcje także na bazie sprzętu innych producentów czy też w ramach innego ekosystemu.
Niezależny instytut standaryzacyjny ETSI (European Telecommunications Standards Institute) opracował cały model, w tym szereg wymagań i specyfikacji, które powinna spełniać architektura do obsługi NFV.
Zarówno Red Hat, jak i Cisco Systems świetnie się w nią wpasowują ze swoimi produktami, wzajemnie dopełniając.
Sprzedajemy produkty Red Hat na polskim rynku. Za naszym pośrednictwem można zakupić Red Hat OpenStack Platform. Jesteśmy także w stanie pomóc w jego wdrożeniu i obsłudze. Zainteresowanych
Na rynku jest zbyt dużo sprzętu z szarego kanału, stąd koniecznie sprawdzaj, czy firma sprzedająca produkty firmy Cisco Systems lub Red Hat jest na 100% jej partnerem handlowym.
Sprawdzić można to w Cisco Partner Locator oraz Red Hat Partner Locator gdzie też jesteśmy.
Wydajna obsługa sieci w Red Hat OpenStack
Obsługa NFV nie byłoby możliwa, bez bardzo wydajnego komponentu sieciowego. Za jej obsługę w platformie Red Hat OpenStack odpowiada usługa Neutron, która dostarcza wspólną warstwę abstrakcji do obsługi OVS (Open vSwitch), OVS-OVN (Open Virtual Network) i rozwiązań SDN (Software-Defined Network) innych producentów, jak Cisco ACI (Application Centric Infrastructure).
OVS (Open vSwitch) stara się przełączać pakiety na poziomie jądra hosta. Każdy z jego portów jest oddzielnym vhost-net, w stronę virtio-net maszyny wirtualnej lub interfejsem do sieci zewnętrznej. Jest to dość podobne do standardowego przełącznika w jądrze hosta. Jako, że obsługuje on więcej funkcjonalności niż standardowy przełącznik, pewne jego elementy musiały zostać wyniesione do przestrzeni użytkownika. Znajduje się tam jego baza danych (ovsdb-server) i daemon kontrolujący przełącznik (ovs-vswitchd).
Aby jak najwięcej ruchu mogło być przełączane na poziomie jądra, utrzymywana jest na poziomie jądra tablica przepływów. W związku z tym, że tablica ta najpierw musi się zbudować, niewielka część pakietów jest przełączana w przestrzeni użytkownika. Dopiero, kiedy daemon ovs-vswitchd przeanalizuje pakiet i doda odpowiedni wpis do tablicy przepływów, kolejne pakiety danego przepływu przełączane są bezpośrednio na poziomie jądra.
Do ciekawszych funkcji, jakie udostępnia OVS należy m.in.:
- IPv4/IPv6, NetFlow, IPFIX, SPAN/RSPAN,
- LACP (IEEE 802.1AX-2008), VLAN i Trunk (IEEE 802.1Q),
- STP (IEEE 802.1D-1998) i RSTP (IEEE 802.1D-2004),
- Multicast Snooping (IGMP/MLD),
- IETF Auto-Attach SPBM i LLDP,
- BFD i 802.1ag Link Monitoring,
- bardzo granularny QoS i limitowanie ruchu,
- kolejkowanie ruchu z użyciem HFSC (Hierarchical Fair Service Curve),
- obsługa protokołu OpenFlow i jego rozszerzeń,
- tunelowanie GRE, VXLAN, STT, Geneve i IPsec.
Z związku z tym, że niektóre operacje wymagają interakcji z przestrzenią użytkownika, co z kolei ma wpływ na spadek wydajności, została opracowana architektura na bazie DPDK (Data Plane Development Kit), która daje:
- dostęp aplikacji z przestrzeni użytkownika do karty sieciowej z pominięciem jądra (pominięcie przełączania kontekstu użytkownika/jądra oraz obsługi całego stosu sieciowego i sterowników na poziomie jądra),
- dostęp do karty sieciowej bez żadnych przerwań i blokad (zamiast czekać na przerwanie od karty sieciowej, dedykowany dla Poll Mode Driver (PMD) rdzeń procesora cały czas sprawdza i odpytuje jej kolejkę, do której ma wyłączny dostęp, bez blokad).
Jest to oczywiście kosztem wspomnianego rdzenia procesora, który zajmuje się ciągłym odpytywaniem kolejki karty sieciowej. Najczęściej dla PMD (Poll Mode Driver) rezerwowany jest jeden lub więcej rdzeni procesora, z których użyciem odpytuje on nieustannie kolejki wejściowe przypisanych mu portów kart sieciowych.
W ten sposób, działający w przestrzeni użytkownika OVS-DPDK dostaje bezpośredni i bardzo wydajny dostęp do kart sieciowych. Dodatkowo, może on udostępniać taki dostęp w stronę instancji wirtualnych. Realizuje to za pomocą modułu vhost-user, który działa w przestrzeni użytkownika hosta (w odróżnieniu od modułu jądra hosta vhost-net).
OVS-DPDK może też oddać bezpośredni dostęp do swoich portów aplikacji działającej w przestrzeni użytkownika wirtualnej instancji, wtedy zamiast virtio-net stosuje ona sterownik virtio-pmd.
Red Hat OpenStack Platform daje także możliwość oddania maszynie wirtualnej bezpośredniego, współdzielonego lub wyłączonego dostępu do karty sieciowej w gnieździe PCI Express (PCIe). Wyłączny dostęp rezerwuje kartę sieciową dla pojedynczej wirtualnej instancji, a współdzielony umożliwia jej współdzielenie przez wiele instancji wirtualnych równocześnie. Współdzielony dostęp realizowany jest poprzez SR-IOV (Single-Root Input/Output Virtualization) lub vDPA (vHost Data Path Acceleration).
Z vDPK i SR-IOV mogą korzystać instancje, kontenery oraz OVS-DPDK.
Karta sieciowa z obsługą SR-IOV może być współużytkowana przez wiele instancji. Do każdej z nich udostępniana jest wirtualna karta sieciowa, zwana VF (Virtual Function), która obsługiwana jest na wewnętrznym, wbudowanym w kartą sieciową przełączniku. Funkcjonalność, wydajność i ilość obsługiwanych VF może być różna, w różnych kartach sieciowych. Dodatkowo do obsługi SR-IOV mogą być potrzebne specyficzne sterowniki danego producenta.
vDPA standaryzuje obsługę warstwy kontrolnej SR-IOV u różnych producentów. Udostępnia uniwersalny interfejs warstwy kontrolnej, który komunikuje się warstwą kontrolną kart różnych producentów.
Na poziomie hosta nadal jest potrzebny odpowiedni sterownik dla karty sieciowej danego producenta, natomiast na poziomie systemu gościa (wirtualna instancja lub kontener) wystarczy, że będzie dostępny tylko sterownik vDPA. Ścieżka danych w SR-IOV i vDPA nie zmienia się, gdyż vDPA zmienia tylko sposób obsługi warstwy kontrolnej.
OVS-DPDK, SR-IOV i vDPA mają kluczowe znaczenia przy wykorzystaniu VNF (Network Function Virtualization).
OVN (Open Virtual Network) jest kontrolerem SDN, służącym do wysokopoziomowego zarządzania wieloma OVS i w ten sposób kreowania wirtualnych topologii sieciowych L2 i L3 (IPv4/IPv6). OVN stara się jak najwięcej funkcji implementować bezpośrednio na poziomie OVS i obsługuje też OVS-DPDK. Jest on backend-em dla usługi Neutron. Poza obsługą OVS, OVN umożliwia m.in. skalowalne i wygodne filtrowanie z wykorzystaniem mechanizmu security groups, obsługę NAT, DHCP, DNS i ruchomych IP (ang. floating IPs). Domyślnie OVS-OVN stosuje enkapsulację GENEVE (Generic Network Virtualization Encapsulation).
Dość ciekawym mechanizem w OVN jest Flow Caching, który pozwala pominąć przetwarzanie pakietu na każdym z wirtualnych urządzeń L2/L3, jakie stoją na jego drodze. Dzięki niemu, kontroler jest w stanie określić końcowe miejsce przeznaczenia pakietu. Na tej podstawie m.in. zmniejsza odpowiednio wartość pola TTL i ustawia odpowiednie adresy MAC, a następnie przekazuje go już do końcowego miejsce przeznaczenia. Znacząco podnosi to wydajność przełączania i routingu oraz umożliwia osiągnięcie podobnej wydajności i opóźnień zarówno dla przełączania w L2, jak i routingu L3.
Dzięki funkcji ARP/ND Suppression, OVN minimalizuje także ilość ruchu rozgłoszeniowego związanego z działaniem ARP w IPv4 i ND w IPv6. Lokalny kontroler węzła jest w stanie przechwycić takie zapytanie i wygenerować stosowne odpowiedzi. Dzięki temu, ruch ten niepotrzebnie nie jest tunelowany do innych węzłów.
Platforma Red Hat OpenStack posiada także wbudowane mechanizmy rozkładu obciążenia (ang. load balancing) i dystrybucji ruch do działających instancji. W tym celu stosowana jest usługa Octavia.
Zapraszamy do
NUMA (Non-Uniform Memory Access), a wydajność
W celu poprawy wydajności, możliwe jest przypisanie (ang. pinning) instancji do procesorów i węzłów NUMA. Funkcje te dostępne są na poziomie usługi Nova, gdzie można zdefiniować całą topologię NUMA, na podstawie której będą przydzielane zasoby.
Stosowana w obecnych serwerach architektura NUMA (Non-Uniform Memory Access) została podzielona na strefy, nazywane węzłami NUMA. Najlepiej, gdy dana instancja korzysta z zasobów jednego węzła NUMA. Dotyczy to nie tylko procesora i pamięci, ale też urządzeń sieciowych (SR-IOV/OVS-DPDK). Na węzeł NUMA składać się mogą rdzenie procesora wraz z ich lokalną pamięcią, a nawet bezpośrednio dołączone urządzenia PCIe.
Nie można też tutaj zapomnieć o rezerwacji odpowiednich zasobów procesora z każdego węzła NUMA, na potrzeby wspomnianego wcześniej PMD, kiedy chcemy korzystać OVS-DPDK.
Dostępna do włączenia jest również funkcja automatycznego balansowania NUMA. Polega ono na uruchamianiu procesów najbliżej obszarów przydzielonej pamięci oraz przenoszeniu danych pamięci bliżej procesów, które z nich korzystają.
Szukasz rozwiązania kopii zapasowej dla platformy OpenStack? Polecamy Storware Backup & Recovery!
Red Hat OpenStack i OpenShift
Red Hat OpenStack Platform umożliwia bardzo dobrą kooperację i integrację z Red Hat OpenShift Container Platform.
Potrafi automatycznie zbudować środowisko Red Hat OpenShift na serwerach fizycznych (ang. bare metal) i wirtualnych, hostować platformę Red Hat OpenShift, zapewnić wysoką dostępność i rozkład obciążenia do jej komponentów, usług i obsługiwanych aplikacji oraz udostępnić jej przestrzeń danych i usługi sieciowe.
Dzięki Kuryr, możliwe jest umiejscowienie kontenerów z platformy Red Hat OpenShift razem z wirtualnymi instancjami platformy Red Hat OpenStack w jednej współdzielonej sieci. Bez użycia Kuryr, sieć SDN z Red Hat OpenShift działa na warstwie sieci SDN platformy Red Hat OpenStack, czyli dochodzi do podwójnej enkapsulacji.
W ramach Red Hat OpenShift Container Platform możliwe jest uruchomienie całej infrastruktury usługowej dla Red Hat OpenStack. Ma to nawet swoją specjalną nazywę: Red Hat OpenStack Services on OpenShift. W powstałej architekturze, same instancje wirtualne nadal mogą działać w ramach węzłów z systemem RHEL.
Zapraszamy do
