Opis szablonów klastrów usługi Azure CycleCloud

  • 5 min

Usługa Azure CycleCloud udostępnia oparte na szablonach wdrożenie klastrów HPC. Domyślnie aplikacja Azure CycleCloud zawiera kilka wbudowanych szablonów do wdrażania najbardziej typowych harmonogramów klastrów, w tym Slurm, PBSPro, LSF, Grid Engine i HT-Condor. Repozytoria GitHub usługi Azure CycleCloud oferują wiele projektów specyficznych dla harmonogramu, które można dostosować i zaimportować do wystąpienia usługi Azure CycleCloud. Istnieje również możliwość implementowania aprowizacji opartej na szablonach dla własnych, opracowanych w firmie harmonogramów przy użyciu wtyczek skalowania automatycznego usługi CycleCloud.

Szablony ułatwiają implementowanie szerokiej gamy funkcji usługi Azure CycleCloud, w tym obsługę niestandardowych obrazów maszyn wirtualnych, skalowania automatycznego i maszyn wirtualnych typu spot. Minimalizują one również nakład pracy związany z aprowizowaniem i konserwowaniem wielu wdrożeń identycznych skonfigurowanych klastrów, często używanych do izolowania środowisk produkcyjnych, programistycznych i testowych.

Te korzyści są zgodne z celami wdrażania nowego klastra rezydenta platformy Azure dla firmy Contoso. Aby zoptymalizować zakres tych korzyści, decydujesz się dowiedzieć się więcej o formacie i procesie implementowania szablonów usługi Azure CycleCloud.

Jaki jest format szablonów usługi Azure CycleCloud?

Szablony to pliki w formacie INI, które używają składni deklaratywnej do opisania struktury i konfiguracji klastra CycleCloud, w tym ról węzłów klastra i ich odpowiednich relacji. Szablony składają się z nazwanych sekcji z nagłówkami wyznaczonymi przez co najmniej jedną parę nawiasów kwadratowych. Sekcje tworzą hierarchię odpowiadającą hierarchii obiektów klastra i odpowiadających im parametrów. Liczba nawiasów kwadratowych reprezentuje poziom w tej hierarchii, zwiększając się kolejno na każdym poziomie.

[cluster]
  [[node, nodearray]]
    [[[volume]]]
    [[[network-interface]]]
    [[[cluster-init]]]
    [[[input-endpoint]]]
    [[[configuration]]]
[environment]
[noderef]
[parameters]
  [[parameters]]
    [[[parameter]]]

W rzeczywistości sekcja [cluster] może zawierać co najmniej jedną sekcję [[node]], która może zawierać wiele [[[volume]]] sekcji. Podobnie, w tym samym szablonie, w sekcji [cluster], można zdefiniować jedną lub więcej sekcji [[nodearray]], z których każda ma własną [[[configuration]]].

Notatka

Kolejność sekcji w tej samej warstwie jest dowolna.

Jakie są główne sekcje szablonu?

Szablon składa się z następujących głównych sekcji:

  • Cluster: sekcja [cluster] zawiera definicję obiektu klastra Azure CycleCloud. Szablon musi zawierać co najmniej jedną sekcję [cluster] zawierającą co najmniej jedną sekcję [[node]] i [[nodearray]] opisującą obiekty podrzędne tego klastra.
  • Node: Reprezentuje pojedynczą, maszynę wirtualną udostępnioną przez platformę.
  • Nodearray: reprezentuje co najmniej jeden zestaw skalowania maszyn wirtualnych platformy Azure.

Notatka

Klastry składają się z węzłów obsługujących wyznaczone role w przetwarzaniu obciążeń klastrowanych. Z punktu widzenia implementacji usługa Azure CycleCloud korzysta z usługi Azure Resource Manager, aby aprowizować je jako poszczególne maszyny wirtualne platformy Azure lub jako elementy członkowskie zestawu skalowania maszyn wirtualnych. Ten ostatni reprezentuje kolekcję identycznych skonfigurowanych maszyn wirtualnych, które w przeciwieństwie do maszyn wirtualnych platformy Azure obsługują skalowanie automatyczne w poziomie. Usługa Azure CycleCloud używa zestawów skalowania maszyn wirtualnych do implementowania obiektów nodearray. W sekcji [[node]] opisano właściwości podstawowych maszyn wirtualnych dostarczonych przez platformę, które mogą być samodzielną maszyną wirtualną na platformie Azure lub należeć do zestawu skalowania maszyn wirtualnych na platformie Azure. W sekcji [[nodearray]] opisano zestaw skalowania maszyn wirtualnych platformy Azure.

Notatka

Tablica węzłów może składać się z wielu zestawów skalowania maszyn wirtualnych platformy Azure, z których każdy składa się z maszyn wirtualnych o różnej konfiguracji. Jednak wszystkie węzły w środowisku nodearray wykonują tę samą rolę w klastrze, na przykład dostarczając zasoby do jednej kolejki harmonogramu klastra.

  • wolumin definiuje zarządzany dysk platformy Azure, który powinien być dołączony do poszczególnych węzłów klastra lub węzłów tworzących strukturę węzłów. Jest to obiekt podrzędny węzła lub tablicy węzłów.
  • interfejs sieciowy definiuje interfejs sieciowy platformy Azure, który powinien być dołączony do poszczególnych węzłów klastra lub węzłów tworzących tę tablicę węzłów. Jest to obiekt podrzędny węzła lub obiektu typu nodearray.
  • Configuration definiuje konfigurowalne właściwości węzła lub tablicy węzłów. Jest to obiekt podrzędny węzła lub obiektu nodearray.
  • cluster-init definiuje specyfikacje projektu Azure CycleCloud, które mają być stosowane do węzła klastra. Projekt to kolekcja zasobów definiujących konfiguracje węzłów w postaci specyfikacji projektu. Po uruchomieniu węzła jest on automatycznie konfigurowany przez przetwarzanie tych specyfikacji. Cluster-init jest obiektem podrzędnym węzła lub tablicy węzłów.
  • Environment definiuje wdrożenie usługi Azure Resource Manager, które aprowizuje lub modyfikuje zasoby platformy Azure do użycia przez klaster. Jest to opcjonalny obiekt najwyższego poziomu.
  • Noderef odwołuje się do węzła w szablonie w celu wyrażenia zależności zasobów. Jest to opcjonalny obiekt najwyższego poziomu.
  • Parametry umożliwiają przenoszenie szablonu, co umożliwia jego użycie do wdrożenia wielu klastrów z pasującą hierarchią obiektów, ale różnymi ustawieniami konfiguracji. Jest to opcjonalny obiekt najwyższego poziomu, ale istnieje możliwość utworzenia hierarchii zagnieżdżonych parametrów. Dla każdego parametru można zdefiniować jego wartość domyślną. Parametry umożliwiają również uwidocznienie konfigurowalnych zmiennych w klastrze za pośrednictwem interfejsu internetowego CycleCloud.

Każda sekcja zawiera kilka par klucz-wartość, które zawierają szczegóły konfiguracji odpowiedniego obiektu reprezentowane przez nagłówek sekcji. Na przykład takie szczegóły dla tablicy węzłów mogą zawierać klucz ImageName z wartością określającą obraz VM Azure, który ma być używany dla jego węzłów, lub klucz Azure.MaxScalesetSize określający maksymalny dozwolony rozmiar zestawu skalowania maszyn wirtualnych jako wartość. Podobnie sekcje węzła lub nodearray mogą zawierać jedną lub więcej sekcji [[[configuration]]].

Jak aprowizować klaster na podstawie szablonu?

Po zidentyfikowaniu szablonu, który ma być używany do aprowizacji klastra usługi Azure CycleCloud, można zastosować dowolną z następujących metod implementacji:

  • Za pomocą interfejsu wiersza polecenia usługi Azure CycleCloud zaimportuj szablon do aplikacji Azure CycleCloud, a następnie użyj interfejsu graficznego aplikacji do aprowizacji klastra. Aby wyzwolić importowanie, uruchom polecenie cyclecloud import_template -f <template_file> (gdzie symbol zastępczy <template_file> reprezentuje nazwę pliku zawierającego szablon). Jeśli szablon zawiera wiele definicji klastra, określ nazwę klastra, który chcesz zaimportować, odwołując się do niego jako wartość parametru -c.
  • Użyj interfejsu wiersza polecenia usługi Azure CycleCloud, aby zaimportować szablon do aplikacji Azure CycleCloud, a następnie aprowizować klaster. Aby wyzwolić importowanie, uruchom polecenie cyclecloud import_template -t -f <template_file> (gdzie symbol zastępczy <template_file> reprezentuje nazwę pliku zawierającego szablon). Po zakończeniu importowania uruchom polecenie cyclecloud create_cluster. Aby na przykład utworzyć klaster o nazwie lab-cluster z zaimportowanego szablonu o nazwie lab-template, należy uruchomić cyclecloud create_cluster lab-template lab-cluster.
  • Użyj interfejsu wiersza polecenia usługi Azure CycleCloud, aby aprowizować klaster bez jawnego importowania szablonu. Aby wyzwolić importowanie, uruchom polecenie cyclecloud import_cluster.

Niezależnie od wybranej metody należy podać wartości wszystkich wymaganych parametrów podczas aprowizacji klastra. W przypadku korzystania z interfejsu wiersza polecenia usługi Azure CycleCloud można je podać, odwołując się do pliku parametrów w formacie JSON.

Notatka

Plik składa się z par klucz-wartość, gdzie klucz reprezentuje nazwę parametru. Aby przejrzeć jego format dla istniejącego klastra, użyj polecenia cyclecloud export_parameters <cluster_name> > params.json, gdzie symbol zastępczy <cluster_name> reprezentuje nazwę istniejącego klastra.

Notatka

Przed wdrożeniem klastra na podstawie zaimportowanego szablonu należy również przesłać zawartość odpowiedniego projektu do magazynu Azure CycleCloud. Aby wykonać przekazywanie, użyj polecenia CLI cyclecloud project upload <locker_name> Azure CycleCloud (gdzie symbol zastępczy <locker_name> reprezentuje nazwę locker). Aby wyświetlić listę dostępnych szafek, uruchom polecenie CLI usługi Azure CycleCloud cyclecloud locker list. Nazwa locker jest wspomniana w sekcji [[[cluster-init]]].

Notatka

Jednym z kroków konfigurowania instalacji usługi Azure CycleCloud jest utworzenie kontenera obiektów blob na koncie usługi Azure Storage. Ten kontener służy jako skrytka, której serwer CycleCloud używa do przygotowywania projektów CycleCloud dla węzłów klastra. Następnie węzły klastrów zarządzanych przez usługę Azure CycleCloud są skonfigurowane do pobierania projektów CycleCloud z tego repozytorium w ramach procesu startowego.