To pierwszy z cyklu trzech artykułów poświęconych następującym zagadnieniom: sieci, pamięci masowej i zasobom obliczeniowym.
Co zmienia się w sieci: Virtual Private Cloud (VPC)
Po ogłoszeniu ogólnej dostępności VMware Cloud Foundation 9.0 w dniu 17 czerwca 2025 r. oraz zmianach wprowadzonych w VCF 9.1 w maju 2026 r. jeden element zasadniczo zmienia sytuację zespołów sieciowych i aplikacyjnych: Virtual Private Cloud (VPC).
Dotychczas podłączenie nowej aplikacji do sieci w VCF wymagało dogłębnej znajomości NSX (Tier-0, Tier-1, Edge VM) oraz zaangażowania zespołu sieciowego przy każdym wdrożeniu. VPC zmienia ten sposób działania. Umożliwia bowiem samoobsługowe korzystanie z sieci, podobnie jak w chmurze publicznej. Ponadto funkcja ta jest dostępna dla zespołów aplikacyjnych bezpośrednio z poziomu vCenter, a nie tylko z konsoli NSX.
VPC stanowi dodatkowe narzędzie w zestawie rozwiązań sieciowych VCF, a nie zamiennik dotychczasowych rozwiązań. Oznacza to, że tradycyjne sieci VLAN, bramy NSX Tier-0/Tier-1 w trybie „tradycyjnym” oraz standardowe mechanizmy zapory sieciowej (DFW, Gateway Firewall) pozostają w pełni dostępne i mogą współistnieć z VPC w zależności od potrzeb.
Ta pierwsza część naszej serii o nowościach w VCF 9 (którą rozpoczęliśmy od podsumowania TLDR tutaj) skupia się na sieciach. Kolejne artykuły będą poświęcone pamięci masowej, a następnie zasobom obliczeniowym.
Czym jest VPC?
Virtual Private Cloud (VPC) to odizolowane, wielodostępne środowisko sieciowe działające w ramach większej chmury prywatnej VCF.
Umożliwia zespołowi aplikacyjnemu definiowanie własnej, logicznie odizolowanej sieci oraz zarządzanie jej adresacją IP, routingiem i regułami bezpieczeństwa. Wszystko to bez konieczności angażowania zespołu sieciowego przy każdej zmianie. Ta koncepcja nie będzie obca architektom, którzy mają już doświadczenie z chmurą publiczną – przenosi bowiem do prywatnej chmury VCF model VPC znany ze wszystkich dużych platform chmurowych.
Aby dowiedzieć się więcej na ten temat, przeczytaj ten artykuł na blogu VMware.
Strukturę VPC tworzą dwa elementy.
- Podsieci: publiczne lub prywatne sieci wirtualne warstwy 3 (L3) modelu OSI. Prywatna podsieć wykorzystuje blok adresów IP, który nigdy nie jest rozgłaszany poza VPC. Podsieć publiczna otrzymuje natomiast adresy bezpośrednio z zewnętrznej puli adresów IP. W OVHcloud są to zazwyczaj bloki adresów IP.
- Bramy: każdy VPC ma własną bramę, która kieruje pakiety między jego podsieciami. W ramach jednego projektu brama Transit Gateway może łączyć ze sobą wszystkie VPC.
VPC może pozostać przypisany do jednej domeny zarządzania lub obejmować kilka domen za pomocą mechanizmu span, pod warunkiem że korzystają one z tej samej instancji NSX. W wersji 9.1 jeden projekt może obejmować kilka bram Transit Gateway, niezależnie od liczby należących do niego VPC. Każdemu VPC połączonemu z bramą Transit Gateway można również przypisać politykę łączności (Community, Promiscuous, Isolated), która kontroluje komunikację z innymi VPC bez konieczności konfigurowania zapory sieciowej. Limity skalowania (liczba VPC i podsieci) nadal są określane przez maksymalne wartości konfiguracyjne NSX podane w dokumentacji VMware.
Podział ról pozostaje jasno określony. To właśnie dzięki niemu model jest rzeczywiście samoobsługowy, bez utraty scentralizowanej kontroli. Podczas wdrażania domeny zarządzania administrator sieci określa bloki adresów IP przeznaczone dla przyszłych VPC. Następnie administratorzy vCenter samodzielnie tworzą VPC i ich podsieci. Nigdy nie wybierają zakresów adresów IP dla sieci publicznych ani tranzytowych – są one przydzielane z wcześniej zdefiniowanych bloków. Zespół aplikacyjny może swobodnie zarządzać jedynie adresami IP całkowicie prywatnych podsieci, które nigdy nie są rozgłaszane na zewnątrz.
W praktyce zespół aplikacyjny potrzebujący nowego, odizolowanego środowiska może utworzyć własny VPC kilkoma kliknięciami, bez konieczności wysyłania zgłoszenia do zespołu sieciowego ani czekania na okno serwisowe.
Wszystkim można więc zarządzać z poziomu zakładki sieciowej w vCenter (tworzenie VPC i podsieci, konfiguracja łączności) lub za pośrednictwem API/PowerCLI. Wobec tego można zintegrować tworzenie VPC bezpośrednio z potokami opartymi na modelu infrastruktury jako kod (IaC), podobnie jak wdrażanie maszyn wirtualnych. Nie jest konieczna żadna ingerencja w fizyczne przełączniki ani routery: NSX automatycznie instaluje bazowe komponenty wirtualne i zarządza nimi.
Osoby, które znają vSphere Client, mogą zobaczyć poniżej, jak przedstawiane są podsieci w ramach VPC w środowisku VCF 9.x.
Ta koncepcja nie jest zupełnie nowa: VCF 5.2.1 wprowadził już w vCenter pierwsze elementy tego rozwiązania. VCF 9.0 upowszechnia ten model. VCF 9.1 rozszerza go o nowe funkcje łączności, które omówimy w kolejnym rozdziale.
Funkcje i komponenty VPC
Łączność scentralizowana a rozproszona
VPC umożliwia połączenie obciążeń z siecią fizyczną na dwa sposoby. W trybie łączności scentralizowanej brama Transit Gateway kieruje ruch do bramy Tier-0 uruchomionej na maszynach wirtualnych NSX Edge: cały ruch przychodzący i wychodzący przechodzi przez te maszyny. W trybie łączności rozproszonej, wprowadzonym w VCF 9.0, brama Transit Gateway opiera się bezpośrednio na sieci VLAN współdzielonej przez wszystkie hosty ESX, bez maszyn wirtualnych Edge ani bramy Tier-0. VCF 9.1 usuwa główne dotychczasowe ograniczenie tego drugiego trybu, czyli brak zaawansowanych usług sieciowych. Wybór między tymi dwoma trybami zależy przede wszystkim od wymaganego poziomu usług sieciowych, a nie tylko od wydajności sieci.
VPC i Distributed Transit Gateway (DTGW)
Model rozproszony był prostszy i wydajniejszy, ale oferował jedynie podstawowe usługi sieciowe (statyczny NAT, rozproszony DHCP). W VCF 9.1 tę lukę wypełnia nowy komponent programowy: Virtual Network Appliance (VNA). Jest to lekkie urządzenie wirtualne wdrażane z poziomu vCenter, które dołącza do rozproszonego środowiska VPC, zapewniając scentralizowane usługi na żądanie: zaawansowany NAT, DHCP, a przede wszystkim równoważenie obciążenia za pomocą Avi Load Balancer. W rezultacie rozproszona brama Transit Gateway może teraz wykorzystywać Avi do udostępniania usługi równoważenia obciążenia, bez konieczności ponownego wprowadzania tradycyjnych maszyn wirtualnych Edge ani rezygnowania z korzyści wydajnościowych modelu rozproszonego.
Uwaga: po przeczytaniu tego artykułu na blogu możesz zapoznać się z naszym planem rozwoju VMware Avi Load Balancer. Zachęcamy do dzielenia się opiniami w komentarzach i/lub głosowania za nadaniem tej funkcji priorytetu.Avi Load Balancer to silnik równoważenia obciążenia warstw L4–L7 zintegrowany z VCF: do wersji VCF 9.1 był dostępny wyłącznie we wdrożeniach wykorzystujących łączność scentralizowaną, ponieważ model rozproszony nie umożliwiał jego integracji. Virtual Network Appliance (VNA) wypełnia tę lukę: administrator sieci wdraża ją jednorazowo na poziomie projektu lub VPC, a następnie łączy z kontrolerem Avi. Następnie zespoły aplikacyjne mogą tworzyć własne usługi wirtualne Avi (Virtual Services), aby udostępniać API, stronę internetową lub Ingress Kubernetes – i to bez ingerowania w konfigurację bazowej infrastruktury sieciowej. Dzięki temu połączeniu model rozproszony sprawdza się w niemal wszystkich zastosowaniach aplikacyjnych, podczas gdy wcześniej obsługiwał jedynie najprostsze scenariusze.
Rozproszona łączność VLAN dla vSphere Supervisor
VNA rozszerza również możliwości wykorzystania łączności rozproszonej: vSphere Supervisor i VCF Automation mogą teraz łączyć się z centrum danych przez zwykłą sieć VLAN zamiast korzystać z bardziej złożonej architektury łączności scentralizowanej. Dla zespołów wdrażających Kubernetes (vSphere Supervisor) lub orkiestrujących środowiska aplikacyjne (VCF Automation) oznacza to znaczne ograniczenie wymagań dotyczących wcześniejszego przygotowania sieci. Nie trzeba już bowiem przygotowywać dedykowanej topologii Edge/Tier-0, aby zapewnić sprawną łączność.
Podsumowanie
Virtual Private Cloud zmienia sposób współpracy zespołów sieciowych i aplikacyjnych w środowisku VCF 9. Oznacza to mniej uzgodnień między zespołami, samoobsługowe korzystanie z sieci, a teraz – dzięki VNA – również dostęp do zaawansowanych usług (Avi Load Balancer, uproszczona łączność VLAN dla Supervisor) bez rezygnacji z prostoty modelu rozproszonego.
Dla architektów przekaz jest prosty: mniej zgłoszeń do zespołu sieciowego, a infrastruktura pozostaje pod kontrolą dzięki wcześniej ustalonym limitom. Zmiana ta wpisuje się w szerszy kierunek rozwoju VCF 9, czyli zbliżanie sposobu korzystania z chmury prywatnej do tego znanego z chmury publicznej, bez rezygnacji z kontroli nad infrastrukturą.
Kolejna część tej serii będzie poświęcona nowościom w zakresie pamięci masowej.
Poznaj ofertę VMware Cloud Foundation w OVHcloud, aby zbudować własną chmurę prywatną opartą na tym samym rozwiązaniu.