Kilka miesięcy temu, przy okazji artykułu wprowadzającego w tematykę Multicloud obiecałem, że opiszę jak funkcjonuje spójna, wykorzystująca jednolite obrazy maszyn wirtualnych platforma, zarówno w lokalnym centrum danych, jak i u globalnego lub lokalnego dostawcy usług.

Dlatego też w poniższym artykule zamierzam przyjrzeć się takiemu rozwiązaniu, czyli VMware Cloud Foundation.

Według definicji VMware Cloud Foundation to „hybrydowa platforma chmurowa do zarządzania maszynami wirtualnymi i orkiestracji kontenerów, zbudowana w oparciu o technologię infrastruktury hiperkonwergentnej (HCI)”.

Platforma ta zbudowana jest z flagowych produktów VMware:

  • vSphere – Software Defined Compute
  • vSAN – Software Defined Storage
  • NSX – Software Defined Networking
  • Pakiet vRealize – monitoring i automatyzacja

Wszystkie elementy “Software Defined”, czyli definiowane cyfrowo, składają się na tzw. Software Defined Data Center (SDDC).

Z powyższego opisu można wywnioskować, że VCF to po prostu paczka oprogramowania z licencjami na kilka produktów, i faktycznie trochę tak właśnie jest. Jednak tym, czego nie widać na pierwszy rzut oka, a co jest w tym pakiecie najważniejsze, jest integracja poszczególnych komponentów oraz automatyzacja ich działania. Włączanie poszczególnych elementów pozwala samoczynnie, bez udziału administratora, uruchamiać wiele wykonywanych w tle zadań, a wszystko to dzieje się w obrębie spójnej, bezpiecznej, łatwo zarządzalnej platformy. Aby lepiej zrozumieć działanie VCF, warto przyjrzeć się bliżej poszczególnym elementom budującym to rozwiązanie.

Cloud Builder

Cloud Builder to taki wirtualny appliance jednorazowego użytku, który uruchamia platformę VCF. Pierwszym krokiem jest wypełnienie przez administratora specjalnego formularza, w którym muszą znaleźć się m.in. hasła do hostów i appliance’ów, konfiguracja sieci (VLANy, adresacja dla hostów, vMotion oraz pod vSAN) oraz informacje o licencjach i fingerprintach. Tak przygotowany plik jest ładowany do Cloud Buildera, którego konfigurator uruchamia pierwszą Managament Domenę i przekazuje kontrolę do SDDC Managera (o którym poniżej). Żeby w pełni zrozumieć, co dzieje się podczas tak zwanego “Bring-Up’u”, czyli procesu tworzenia środowiska, warto obejrzeć ten krótki film. Ponieważ wszystkie wykonywane krok po kroku aktywności są raportowane, można zaobserwować, jak wiele czynności jest zautomatyzowanych.

SDDC Manager

SDDC Manager jest centralnym elementem całej platformy, dającym wgląd zarówno w warstwę fizyczną jak i wirtualną oraz pozwalającym łatwo nimi zarządzać. To z tego miejsca możemy tworzyć nowe Workload Domeny, podłączać do platformy nowe hosty, pobierać paczki z aktualizacjami czy też uruchomić vRealize Suite.

Management Domain

Na Management Domain uruchamiane są wszystkie elementy potrzebne do zarządzania oraz monitorowania stosem SDDC. Są to m.in vCenter SA (dla MD i poszczególnych WD – Workload Domains), NSX Manager, vRealize Automation, Log Insight oraz omawiany wyżej SDDC Manager. MD składa się z minimum 4 węzłów ESXi oraz zawsze wykorzystuje vSAN pod Storage.

Workload Domain

Virtual Infrastructure (VI) Workload Domains (WD) to zbiór zasobów serwerowych, storage oraz sieciowych, na których uruchamiane są już „właściwe” aplikacje. WD tworzona jest zawsze w sposób zgodny z najlepszymi praktykami VMware, w tym z domyślnie uruchomionymi vSphere HA i DRS, a sam proces jest bardzo mocno zautomatyzowany. Minimalna liczba węzłów dla WD to 3 (można wdrożyć MD oraz jedną WD w tzw. modelu “consolidated” i zacząć z VCF już od 4 hostów).

Zobaczmy, co dzieje się w momencie tworzenia Workload Domeny:

  1. Uruchamiane są dodatkowe vCenter dla nowej WD w obrębie MD. Przy korzystaniu z oddzielnego vCenter dla każdej WD aktualizacje mogą odbywać się bez wpływu na pozostałe WD. Można również łatwo wyizolować każdą WD, jeśli zajdzie taka potrzeba.
  2. Serwery ESXi wchodzące w skład nowej WD łączone są z nowym vCenter i tworzy się z nich klaster. Każdy host jest skonfigurowany przy użyciu port grup odpowiednich dla danej WD.
  3. Konfigurowana jest sieć na każdym hoście.
  4. Konfigurowany jest Storage na ESXi-ach. vSAN jest domyślny i rekomendowany, ale w odróżnieniu od MD może to być również NFS, a także VMFS po FC.
  5. Jeśli tworzymy pierwszą WD, system uruchamia klaster trzech NSX Managerów (w obrębie MD) oraz konfiguruje dla nich wirtualne IP (VIP). Dodatkowo uruchamiane są Anti-Affinity Rules, których zadaniem jest zadbanie o to, żeby instancje NSX Managera nie znajdowały się na tym samym hoście, co zapewni ich wysoką dostępność. Kolejne WD mogą skorzystać z już istniejącego klastra NSX Manager, ale mogą też uruchomić nowy.
  6. Podczas powoływania sieci nakładkowych AVN (Aplication Virtual Networks), SDDC tworzy na MD dwuwęzłowy klaster NSX Edge na potrzeby vRealize Suite.
  7. NSX Managery są od razu skonfigurowane tak, aby okresowo backupować się na SFTP
  8. Licencjonowanie i integracja wdrożonych komponenów w stosie VCF.

Uff… jak widać, w tle samoczynnie uruchamia się wiele zadań, które normalnie trzeba byłby wykonać ręcznie. Żeby zobaczyć, jak to wygląda z punktu widzenia administratora, warto zajrzeć do tej interaktywnej symulacji.

Chmura hybrydowa i Multicloud

VMware Cloud Foundation można uznać za taką “chmurę prywatną pod klucz”. Co jednak, jeśli chcielibyśmy skorzystać z zasobów zewnętrznych? Tak się składa, że VCF jest podstawą wielu usług, które możemy znaleźć w ofercie dostawców publicznych. Są to między innymi:

  • VMware Cloud on AWS
  • Azure VMware Solution
  • Google Cloud VMware Engine
  • Oracle Cloud VMware Solution
  • Alibaba Cloud VMware Solution

Jak widać, w zasadzie wszyscy globalni dostawcy mają w ofercie usługę opartą na tym stosie. Możemy również skorzystać z usług lokalnego dostawcy, działającego w modelu Dell Technologies Cloud Service Provider (czyli np. Netii). Jednolity stos on i off-premise daje bardzo dużą elastyczność oraz bezpieczeństwo. Wyobraźmy sobie taką sytuację: startujemy z projektem, który wymaga uruchomienia 50 nowych maszyn na bliżej nieokreślony czas. Możemy skorzystać z zalet chmury publicznej i niemal natychmiast uruchomić to środowisko na zewnątrz. Następnie obserwujemy, czy projekt jest rozwijany i wymaga coraz większych zasobów, czy wręcz przeciwnie – ląduje w koszu. W pierwszym przypadku możemy zdecydować, co dalej – może taniej będzie dołożyć kilka węzłów do lokalnej serwerowni i przenieść do niej aplikację? A może warto przejść do innego dostawcy, bo potrzebujemy integracji z usługą, która działa tylko u niego? Jeśli natomiast projekt nie wypalił, to nie zostaniemy z niewykorzystanym sprzętem. Właśnie dlatego, według IDC, coraz więcej firm wdraża model hybrydowy. Może się jednak okazać, że korzystając z usług różnych dostawców on i off-premise, po prostu tworzymy dodatkowe “silosy”. Jednolity stos SDDC może być sposobem na połączenie tych światów.

W kolejnych artykułach opiszę platformę hardware’ową pod VCF, a także przyjrzę się nowościom (Tanzu!). Polecam również jeden z odcinków “Drogi do Multicloud” , którego tematem był właśnie VCF.