Przykładowa konfiguracja środowiska VMware Cloud Director przez terraform

Ten artykuł to trzeci z cyklu materiałów, w których szczegółowo przyglądamy się funkcjonalnościom i możliwościom rozwiązania VMware Cloud Director oferowanego przez GigaCloud. Moim celem jest przeanalizowanie poszczególnych komponentów tej platformy oraz pokazanie, jak można je wykorzystać w wybranych aspektach codziennej pracy z chmurą opartej na tej technologii. Każdy artykuł będzie się koncentrował na innym aspekcie VMware Cloud Director – od tworzenia maszyny wirtualnej, testy wydajnościowe, przez backup, migrację aż po awaryjne odtwarzanie (DR).

Zapraszam do śledzenia kolejnych wpisów z tej serii, które będą pojawiać się w najbliższym czasie:

1. Przegląd środowiska VMware Cloud Director w Gigacloud.
2. Przykładowa konfiguracja środowiska przez GUI (pierwsza maszyna).
3. Przykładowa konfiguracja środowiska przez IaC (Terraform i wiele maszyn).
4. Testy wydajnościowe łącza internetowego oferowanego przez providera.
5. Testy wydajnościowe wdrożonych maszyn dostępnych dysków.
6. Weryfikacja i konfiguracja funkcji kopii zapasowych od Veeam udostępnionych na platformie.
7. Migracja do VMware Cloud Provider przy pomocy VMware Cloud Director Availability
8. Awaryjne odtwarzanie do centrum danych przez VMware Cloud Director Availability

Wprowadzenie do zakresu bieżącego artykułu

W poprzednich artykułach omówiłem ogólny przegląd środowiska VMware Cloud Director oraz proces tworzenia pierwszej maszyny wirtualnej za pomocą interfejsu graficznego (GUI). Kontynuując tę serię, skupimy się na automatyzacji wdrażania infrastruktury poprzez podejście Infrastructure as Code (IaC) z wykorzystaniem narzędzia Terraform. Takie podejście jest szczególnie przydatne w sytuacjach, gdy potrzebujemy szybko wdrożyć dużą liczbę maszyn wirtualnych, np. dla celów szkoleń, a następnie efektywnie zarządzać ich cyklem życia w celu optymalizacji kosztów.

Zakres artykułu obejmuje:

1. Infrastruktura jako kod (IaC) i Terraform
2. Scenariusz wdrożenia dla grupy 12-osobowej
3. Testy wdrożenia z różnymi liczbami maszyn wirtualnych i politykami przechowywania danych

Poniżej przedstawiam krok po kroku rozwinięcie powyższych punktów oraz przebieg testów wraz z ich wynikami.

1. Infrastruktura jako kod (IaC) i Terraform:

• Definicja IaC: Podejście polegające na zarządzaniu i provisioning infrastruktury za pomocą kodu, co zapewnia spójność i automatyzację.
• Wprowadzenie do Terraform: Narzędzie open-source stworzone przez HashiCorp, umożliwiające definiowanie i zarządzanie infrastrukturą w chmurze za pomocą deklaratywnego języka HCL.

2. Scenariusz wdrożenia dla grupy 12-osobowej:

• Opis potrzeb: Firma szkoleniowa planuje warsztaty dla 12 uczestników, z których każdy potrzebuje dedykowanej maszyny wirtualnej z preinstalowanym oprogramowaniem.
• Konfiguracja Terraform:
  • Provider: Wybór dostawcy chmury obsługiwanego przez VMware Cloud Director.
  • Definicja zasobów: Utworzenie 12 identycznych maszyn wirtualnych z wykorzystaniem pętli w Terraform.
• Cel: Pomiar średnich czasów wdrożenia oraz usuwania zadanej liczby maszyn dwóch dostępnych typach pamięci masowej ClassSSD oraz ClassFastSSD. Konfiguracja na poziomie polityki przechowywania danych (storage policy): ClassSSD – Maximum Disk IOPS: 3000 IOPS, ClassFastSSD – Maximum Disk IOPS: 20 000 IOPS”

Kod użyty w tym ćwiczeniu przechowuje w GITHUBie w tym repo

W tym przypadku nie robiłem pojedynczego pliku terraforma ale poświęciem chwilę więcej czasu i rozbudowałem projekt o proste moduły odpowiedzialne za rózne komponenty infrastruktury.

Wygląda to mniejwięcej w ten sposób:

Terraform Project Structure
└── root/
├── main.tf # Główny plik konfiguracyjny, łączy moduły
├── providers.tf # Definicja dostawców (providerów)
├── variables.tf # Zmienne globalne
├── modules/
│ ├── catalog/
│ │ ├── main.tf
│ │ ├── variables.tf
│ │ ├── outputs.tf
│ ├── vdc/
│ │ ├── main.tf
│ │ ├── variables.tf
│ │ ├── outputs.tf
│ ├── edgegateway/
│ │ ├── main.tf
│ │ ├── variables.tf
│ │ ├── outputs.tf
│ ├── networks/
│ │ ├── main.tf
│ │ ├── variables.tf
│ │ ├── outputs.tf
│ ├── vapp_template/
│ │ ├── main.tf
│ │ ├── variables.tf
│ │ ├── outputs.tf
│ ├── vm-standalone/
│ ├── main.tf
│ ├── variables.tf
│ ├── outputs.tf

Opis głównych plików i katalogów:

• main.tf: Główny plik konfiguracyjny Terraform, który integruje i wywołuje poszczególne moduły zdefiniowane w katalogu modules/.

• providers.tf: Plik definiujący dostawców usług chmurowych (providers), z którymi Terraform będzie się komunikować. W tym przypadku jest to konfiguracja dla VMware vCloud Director.

• variables.tf: Plik zawierający definicje zmiennych wejściowych używanych w main.tf oraz przekazywanych do modułów. Umożliwia łatwe dostosowanie parametrów infrastruktury.

Katalog modules/:

Zawiera moduły Terraform, z których każdy odpowiada za tworzenie określonych zasobów w infrastrukturze:

• catalog/: Moduł odpowiedzialny za zarządzanie katalogami w vCloud Director. Pliki:

  • main.tf: Definicje zasobów katalogu, który obecnie istnieje.
  • variables.tf: Zmienne wejściowe dla modułu katalogu.
  • outputs.tf: Wartości wyjściowe, takie jak ID utworzonego katalogu.

• vdc/: Moduł tworzący Virtual Data Center (VDC). Pliki:

  • main.tf: Definicje zasobów VDC.
  • variables.tf: Zmienne wejściowe dla modułu VDC.
  • outputs.tf: Wartości wyjściowe, np. ID utworzonego VDC.

• edgegateway/: Moduł odpowiedzialny za tworzenie i konfigurację Edge Gateway w VDC. Pliki:

  • main.tf: Definicje zasobów Edge Gateway.
  • variables.tf: Zmienne wejściowe dla modułu Edge Gateway.
  • outputs.tf: Wartości wyjściowe, takie jak ID istniejące w tym przypadku bramy.

• networks/: Moduł zarządzający sieciami w VDC. Pliki:

  • main.tf: Definicje zasobów sieciowych.
  • variables.tf: Zmienne wejściowe dla modułu sieci.
  • outputs.tf: Wartości wyjściowe, np. nazwy utworzonych lub istniejących sieci

• vapp_template/: Moduł zajmujący się tworzeniem szablonów vApp. Pliki:

  • main.tf: Definicje zasobów szablonów vApp.
  • variables.tf: Zmienne wejściowe dla modułu szablonów.
  • outputs.tf: Wartości wyjściowe, takie jak ID utworzonego szablonu.

• vm-standalone/: Moduł odpowiedzialny za tworzenie pojedynczych maszyn wirtualnych. Pliki:

  • main.tf: Definicje zasobów maszyn wirtualnych.
  • variables.tf: Zmienne wejściowe dla modułu maszyn wirtualnych.
  • outputs.tf: Wartości wyjściowe, np. adresy IP utworzonych maszyn.

3. Testy wdrożenia z różnymi liczbami maszyn wirtualnych i politykami przechowywania danych (storage policy)

W celu oceny skalowalności i poprawności wdrożenia infrastruktury w VMware vCloud Director, przeprowadziłem testy dla różnych wartości parametru vm_count w module training-vms. Sprawdzałem działanie przy następujących konfiguracjach:

1. Pojedyncza maszyna wirtualna (vm_count = 1) – pozwala zweryfikować, czy infrastruktura działa poprawnie w minimalnej skali, co jest kluczowe dla testów początkowych i debugowania.

2. Dwie maszyny wirtualne (vm_count = 2) – test dla małej skali, który pozwala sprawdzić podstawowe mechanizmy sieciowe, takie jak przypisywanie adresów IP

3. Dwanaście maszyn wirtualnych (vm_count = 12) – średnia skala wdrożenia pozwalająca ocenić zachowanie zasobów obliczeniowych i zarządzanie alokacją zasobów w VDC.

4. Dwadzieścia jeden maszyn wirtualnych (vm_count = 21) – test większej skali dla tej konfiguracji,

5. Sto maszyn wirtualnych (vm_count = 100) test maksymalnej skali dla tej konfiguracji, który pomoże sprawdzić limity wydajności oraz zgodność z dostępnymi zasobami pamięci masowej.

Aby przeprowadzić testy, modyfikowałem wartość vm_count w module training-vms w pliku main.tf i przeprowadzałem kolejne wdrożenia Terraform (terraform apply).

Testy z różnymi politykami przechowywania danych

Dodatkowo, testy przeprowadzałem dla dwóch różnych polityk przechowywania danych:

• ClassSSD – standardowa polityka zapewniająca wydajność opartą na SSD (do 3000 IOPS).
• ClassFastSSD – wyższa klasa przechowywania z większą liczbą operacji IOPS (do 20000 IOPS).

Porównanie obu polityk pozwoliło nam ocenić wpływ różnych parametrów “storage policy” na wydajność i czas wdrażania maszyn wirtualnych w różnych skalach wdrożenia.

Ograniczenia związane z procesorami i pamięcią maszyn

Z uwagi na limity dostępne w zaalokowanej puli wirtualnych procesorów i pamięci  maksymalna liczba maszyn wirtualnych, jaką zdecydowałem się wdrożyć w naszym środowisku, wyniosła 100. Maszyn właśnie z uwagi no ograniczenie nie wlączałem. Nie było to dla mnie kluczowe. Ostateczne wyniki testów pozwolą na lepsze planowanie zasobów w przyszłych wdrożeniach oraz dostosowywanie parametrów wirtualnego datacenter pod konkretne potrzeby.

Subiektywne wyniki testów

Analizując wyniki testów, można zauważyć kilka zależności:

1. Czas wdrożenia:

   • ClassFastSSD jest szybszy od ClassSSD w częsci tylko przypadków, bez reguły ilości maszyn.
   • Różnica w czasach wdrożenia między ClassFastSSD a ClassSSD jest bardziej widoczna przy pojedynczej maszynie  natomiast przy większych ilościach maszyn czasy się zbliżają.

2. Czas usuwania:

   • ClassFastSSD również wykazuje lepsze czasy usuwania maszyn niż ClassSSD, jednak różnice są mniej wyraźne.
   • Dla większych ilości maszyn czas usuwania wzrasta, ale różnice między politykami storage nie są tak drastyczne

3. Skalowanie:

   • Czas wdrożenia rośnie w miarę wzrostu liczby maszyn, ale nie jest on liniowy – dla 12, 21 i 100 maszyn wzrost czasu wdrożenia nie jest proporcjonalny, co może sugerować narastające ograniczenia infrastruktury lub specyfikę działania terraforma jak i zarządzanie równoległymi taskami VMware Cloud Directora
   • W przypadku usuwania maszyn wzrost czasu również jest zauważalny, ale pozostaje bardziej stabilny w obu politykach storage.

Podsumowując testów, ClassFastSSD oferuje zauważalnie lepsze czasy wdrożenia i usuwania, szczególnie przy mniejszych ilościach maszyn. Przy większej liczbie maszyn różnice w wydajności obu polityk zaczynają się zmniejszać, co może wskazywać na inne ograniczenia w infrastrukturze.

Podsumowanie

Wdrożenie infrastruktury szkoleniowej z wykorzystaniem Terraform w środowisku VMware vCloud Director pozwala na szybkie, elastyczne i powtarzalne tworzenie maszyn wirtualnych dla różnych scenariuszy edukacyjnych. Dzięki temu możemy zautomatyzować cały proces i dostosować środowisko do liczby studentów oraz rodzaju szkolenia.

Zalety wykorzystania Terraform dla różnych typów szkoleń:

1. Szkolenia indywidualne (np. dla jednego studenta lub instruktora)

   • Możliwość szybkiego stworzenia pojedynczego środowiska testowego (vm_count = 1).
   • Idealne dla osób uczących się samodzielnie lub potrzebujących osobistego środowiska testowego.
   • Minimalizacja kosztów infrastruktury.

2. Szkolenia w małych grupach (np. 2-5 studentów)

   • Dzięki Terraform można łatwo wdrożyć środowisko dla kilku uczestników, zapewniając każdemu dostęp do własnej maszyny (vm_count = 2).
   • Możliwość współdzielenia zasobów w ramach jednego VDC.
   • Dobre rozwiązanie dla warsztatów i szkoleń praktycznych.

3. Szkolenia grupowe / klasy szkoleniowe (np. 12-21 studentów)

   • Automatyzacja tworzenia większej liczby stanowisk (vm_count = 12 lub vm_count = 21).
   • Możliwość zapewnienia jednolitych konfiguracji dla wszystkich uczestników.
   • Skalowalność i kontrola nad wydajnością dzięki zastosowaniu różnych polityk przechowywania danych (ClassSSD, ClassFastSSD).
   • Optymalizacja kosztów i czasu wdrożenia poprzez przewidywalny czas provisioning’u.

Zarządzanie kosztami i wydajnością

Dzięki wykorzystaniu Terraform możemy w przewidywalny sposób zarządzać kosztami infrastruktury, dostosowując liczbę maszyn do rzeczywistych potrzeb szkoleniowych. Testy wydajnościowe wykazały, że:

• ClassFastSSD oferuje szybsze wdrożenie i usuwanie maszyn, co może być istotne dla intensywnych kursów o dużej rotacji.
• ClassSSD może być bardziej ekonomicznym rozwiązaniem dla szkoleń długoterminowych, gdzie czas wdrożenia nie jest kluczowym czynnikiem.

Ostatecznie jednak wyniki pomiędzy storage policy w momencie wdrożenia nie są znaczne. Zatem należałoby zastanowić się w okreslonych przypadkach aby nie przepłacać za droższy typ pamięci masowej.

Podsumowanie podsumowania 🙂

Zastosowanie Terraform do zarządzania infrastrukturą szkoleniową w VMware vCloud Director pozwala na:
✔️ Automatyzację i szybkie wdrożenie środowisk dla studentów, niezależnie od ich liczby.
✔️ Optymalizację kosztów, poprzez dostosowanie ilości maszyn do realnych potrzeb.
✔️ Powtarzalność i łatwość odtwarzania środowiska dla kolejnych grup szkoleniowych.
✔️ Elastyczność wyboru polityki przechowywania danych, dostosowanej do wymagań wydajnościowych.

Dzięki takiemu podejściu szkolenia IT stają się bardziej efektywne, elastyczne i skalowalne, co pozwala na ich optymalne dostosowanie do potrzeb zarówno organizatorów, jak i uczestników.

Jeśli chciałbyś być na bieżąco i budować swoją wiedzę razem zemną w tematach IT dodaj się do listy mailowej TUTAJ  . Co jakiś czas będę podsyłał Tobie informacje co się dzieje na blogu i w świecie cloud computingu, którym także się zajmuję.

Masz jakieś pytania lub myślisz, że moglibyśmy zrobić wspólny projekt razem ? daj znać!