Klastry CycleCloud
W usłudze CycleCloud termin klaster służy do opisywania grupy połączonych komputerów (węzłów) pracujących razem jako pojedynczy system. Klastry można zagnieżdżać; na przykład klaster obliczeniowy składający się z węzła głównego harmonogramu aparatu siatki i węzłów obliczeniowych może zainstalować klaster BeeGFS składający się z kilku metadanych i serwerów magazynu, z klastrami obliczeniowymi i magazynowymi połączonymi w ramach pojedynczego nadrzędnego klastra HPC lub systemu.
Węzły i tablice węzłów
Klastry zasadniczo składają się z węzłów, z których każda pełni określoną rolę w systemie HPC. Terminy node i VM są używane zamiennie od czasu do czasu, ale są semantycznie oddzielone w CycleCloud. Węzły tworzące klaster są w istocie maszynami wirtualnymi na platformie Azure, które ukończyły proces przygotowywania i konfiguracji. Innymi słowy, maszyny wirtualne są aprowizowane z warstw usługi infrastruktury platformy Azure, a ich stany końcowe to węzły klastra HPC po wykonaniu kroków instalacji i konfiguracji oprogramowania.
Istnieją dwa oddzielne wcielenia węzłów w usłudze CycleCloud. Pierwszy jako węzeł autonomiczny i drugi jako węzełarray, który jest kolekcją identycznych skonfigurowanych węzłów (rozróżnienie node vs nodearray jest zgodne z analogią DevOps Pets vs Cattle w duchu). Ogólnie rzecz biorąc, ale nie ściśle, autonomiczne węzły są tworzone z pojedynczych maszyn wirtualnych na platformie Azure, podczas gdy nodearrays mapują na zestawy skalowania maszyn wirtualnych (VMSS).
Istnieją jednak istotne różnice między węzłamiarrays i zestawami skalowania maszyn wirtualnych. Podstawową jest to, że pojedyncza pula węzłów może składać się z wielu zestawów skalowania maszyn wirtualnych. Umożliwia to tworzenie pojedynczego węzła z maszyn wirtualnych o różnych rozmiarach, a nawet różnych rodzin maszyn wirtualnych, przy czym jedynym ograniczeniem jest to, że wszystkie węzły w węźle wykonują tę samą rolę w klastrze, na przykład dostarczając zasoby do jednej kolejki harmonogramu.
Szablony klastrów
Topologia lub sposób organizowania węzłów w klastrze CycleCloud są definiowane w szablonach tekstowych, które określają relacje między węzłami klastra, a w przypadku zagnieżdżonych klastrów relacja nadrzędny-podrzędna klastrów. Szablony udostępniają również metody definiowania roli, jaką odgrywa każdy węzeł.
Szablony klastrów są definiowane w formacie INI. Sekcje, delineated przy użyciu nawiasów kwadratowych [
,]
są używane do definiowania klastrów, węzłów i węzłówarrays. Podstawowym elementem plików INI są asercji par klucz-wartość, które zapewniają szczegóły konfiguracji każdej sekcji. Te szczegóły konfiguracji zawierają informacje kontekstowe używane do tworzenia każdego węzła klastra na podstawie obrazu maszyny wirtualnej używanego do rozruchu maszyny wirtualnej do podsieci, w którą ma zostać aprowizowana maszyna wirtualna.
Przeczytaj więcej na temat szablonów klastrów CycleCloud
Przygotowywanie i konfiguracja węzła
Usługa CycleCloud aprowizuje maszyny wirtualne z podstawowych obrazów maszyn wirtualnych zdefiniowanych w szablonie klastra oraz za pośrednictwem serii kroków zarządzanych przez agenta CycleCloud (Jetpack) podczas procesu rozruchu, inicjuje i konfiguruje system operacyjny na maszynie wirtualnej, aby przekonwertować go na działający węzeł HPC. Te kroki obejmują od skryptów, aby zainstalować i skonfigurować oprogramowanie do planowania, po konfigurację ostatniej mili na potrzeby instalowania systemu plików.
Zdefiniowana w sekcji konfiguracji każdego węzła to specyfikacje inicjowania klastra — specyfikacje udostępniane dla każdej rozruchowej maszyny wirtualnej używanej do przygotowania jej do określonej roli w klastrze. Usługa CycleCloud korzysta z programu Chef jako platformy automatyzacji infrastruktury do przygotowywania i konfigurowania każdego węzła. W istocie każda specyfikacja typu cluster-init jest mapowana na jedną z więcej ról programu Chef i/lub przepisów książki kucharskiej , które należy wykonać na rozruchowej maszynie wirtualnej.
Usługa CycleCloud korzysta z programu Chef w trybie autonomicznym, który nie opiera się na scentralizowanym serwerze Chef. Zamiast tego cały zestaw książek kucharskich chef potrzebny do przygotowania każdej maszyny wirtualnej jest pobierany z konta usługi Azure Storage należącego do użytkownika podczas fazy rozruchu maszyny wirtualnej. Ten zestaw książek kucharskich jest buforowany z serwera aplikacji CycleCloud do konta magazynu podczas fazy tworzenia klastra.
Po pobraniu tych książek kucharskich program Chef przetwarza listę przepisów zdefiniowanych w specyfikacjach klastra węzła, wyzwalając fazę przygotowania i konfiguracji, która konwertuje maszynę wirtualną na działający węzeł HPC.
Specyfikacje są tworzone jako kolekcje logiczne nazywane projektami. Na przykład projekt harmonogramu wsadowego, taki jak Slurm, składa się z co najmniej dwóch specyfikacji: jeden dla węzłów głównych harmonogramu, a drugi dla węzłów obliczeniowych. Dowiedz się więcej o projektach CycleCloud
Orkiestracja węzłów
W zależności od harmonogramu i usług używanych w klastrze usługa CycleCloud czasami musi zorganizować fazę przygotowania węzłów w klastrze przez koordynację różnych węzłów. Na przykład niektóre harmonogramy wymagają, aby każdy węzeł obliczeniowy zarejestrował się względem demona harmonogramu, co nie tylko wymaga, aby węzły obliczeniowe wiedziały o adresie węzła głównego, ale są również w stanie rozpoznać, że węzeł główny jest w pełni przygotowany i poczekaj, jeśli tak nie jest.
Ten element odnajdywania usługi jest również używany w przypadku relacji serwer-klient systemu plików i jest funkcją w usłudze CycleCloud.