Klaster CycleCloud GridEngine
Program Open Grid Scheduler (Grid Engine) można łatwo włączyć w klastrze usługi Azure CycleCloud, modyfikując "run_list" w definicji klastra. Dwa podstawowe składniki klastra aparatu siatki to węzeł główny, który udostępnia udostępniony system plików, w którym jest uruchomione oprogramowanie aparatu siatki, oraz węzły "execute", które są hostami, które zainstalują udostępniony system plików i wykonują przesłane zadania. Na przykład prosty fragment kodu szablonu klastra aparatu grid engine może wyglądać następująco:
[cluster grid-engine]
[[node master]]
ImageName = cycle.image.centos7
MachineType = Standard_A4 # 8 cores
[[[configuration]]]
run_list = role[sge_master_role]
[[nodearray execute]]
ImageName = cycle.image.centos7
MachineType = Standard_A1 # 1 core
[[[configuration]]]
run_list = role[sge_execute_role]
Uwaga
Nazwy ról zawierają "sge" ze starszych powodów: Grid Engine był produktem Sun Microsystems.
Importowanie i uruchamianie klastra z definicją w usłudze CycleCloud spowoduje uzyskanie jednego węzła głównego. Węzły wykonywania można dodać do klastra za pomocą cyclecloud add_node
polecenia . Aby na przykład dodać 10 kolejnych węzłów do wykonania:
cyclecloud add_node grid-engine -t execute -c 10
Autoskalowanie aparatu siatki
Usługa Azure CycleCloud obsługuje skalowanie automatyczne dla aparatu grid, co oznacza, że oprogramowanie będzie monitorować stan kolejki i włączać i wyłączać węzły w zależności od potrzeb, aby ukończyć pracę w optymalnym czasie/koszcie. Skalowanie automatyczne dla aparatu grid można włączyć, dodając Autoscale = true
do definicji klastra:
[cluster grid-engine]
Autoscale = True
Domyślnie wszystkie zadania przesłane do kolejki aparatu siatki będą uruchamiane na maszynach typu "execute", są to maszyny zdefiniowane przez tablicę węzłów o nazwie "execute". Nazwa "execute" nie jest ograniczona do pojedynczego typu konfiguracji maszyny do uruchamiania zadań i automatycznego skalowania.
Na przykład typowym przypadkiem może być to, że masz klaster z dwiema różnymi definicjami węzłów, które służą do uruchamiania "normalnych" zadań korzystających ze standardowego procesora CPU, podczas gdy inny typ zadania może używać maszyn gpu. W takim przypadku chcesz niezależnie skalować kolejkę zarówno przez normalne zadania, jak i zadania procesora GPU, aby upewnić się, że masz odpowiednią ilość każdej maszyny do korzystania z kolejki pracy. Przykładowa definicja będzie wyglądać następująco:
[cluster grid-engine]
Autoscale = True
[[node master]]
ImageName = cycle.image.centos7
MachineType = Standard_A3 # 4 cores
[[[configuration]]]
run_list = role[sge_master_role]
[[nodearray execute]]
ImageName = cycle.image.centos7
MachineType = Standard_A4 # 8 cores
[[[configuration]]]
run_list = role[sge_execute_role]
[[nodearray gpu]]
MachineType = Standard_NV12 # 2 GPUs
ImageName = cycle.image.centos7
# Set the number of cores to the number of GPUs for autoscaling purposes
CoreCount = 2
[[[configuration]]]
run_list = role[sge_execute_role]
gridengine.slot_type = gpu
gridengine.slots = 2
W powyższym przykładzie istnieją teraz dwie tablice węzłów: Jedna jest "standardową" tablicą węzłów wykonywania, a druga ma nazwę "gpu", zapewniając typ maszyny z dwoma procesorami GPU firmy Nvidia (Standard_NV12 na platformie Azure). Należy również zauważyć, że istnieją teraz dwa nowe elementy w sekcji konfiguracji oprócz przepisu "csge:sgeexec". Dodanie gridengine.slot_type = gpu
informuje harmonogram aparatu siatki, że te węzły powinny mieć nazwę "gpu" węzły, dlatego powinny uruchamiać tylko zadania "gpu". Nazwa "gpu" jest dowolna, ale najbardziej przydatna jest nazwa opisując węzeł. Ustaw wartość gridengine.slots = 2
, która informuje oprogramowanie, aby upewnić się, że ten typ węzła może uruchamiać tylko dwa zadania jednocześnie (Standard_NV12 ma tylko 2 procesory GPU. Domyślnie liczba miejsc na węzeł w aksiecie siatki będzie liczbą procesorów w systemie, co w tym przypadku spowodowałoby zbyt wiele zadań do współbieżnego wykonywania w węźle. W powyższym przykładzie CoreCount=2
parametr jest ustawiany na tablicy nodearray tak, aby odpowiadał liczbie procesorów GPU dostępnych w typie maszyny, co pozwala usłudze CycleCloud na poprawne skalowanie tej tablicy na procesorze GPU i liczbie procesorów CPU.
Liczbę miejsc i slot_type maszyn można sprawdzić, uruchamiając polecenie :
-bash-4.1# qstat -F slot_type
queuename qtype resv/used/tot. load_avg arch states
---------------------------------------------------------------------------------
all.q@ip-0A000404 BIP 0/0/4 0.17 linux-x64
hf:slot_type=execute
---------------------------------------------------------------------------------
all.q@ip-0A000405 BIP 0/0/2 2.18 linux-x64
hf:slot_type=gpu
---------------------------------------------------------------------------------
all.q@ip-0A000406 BIP 0/0/4 0.25 linux-x64
Zwróć uwagę, że istnieje jedna z każdej wartości "slot_type", którą określiliśmy (execute i gpu), a liczba miejsc dla gniazda "execute" wynosi 4, czyli liczbę procesorów CPU na maszynie. Liczba miejsc dla typu gniazda "gpu" wynosi 2, które określono w szablonie konfiguracji klastra. Trzecia maszyna to węzeł główny, który nie uruchamia zadań.
Zaawansowane użycie aparatu siatki
Powyższe ustawienia konfiguracji umożliwiają zaawansowane dostosowywanie węzłów i tablic węzłów. Jeśli na przykład zadania wymagają określonej ilości pamięci, powiedzmy, 10 GB, można zdefiniowaćarray wykonywania, które uruchamia maszyny z 60 GB pamięci, a następnie dodać w opcjach gridengine.slots = 6
konfiguracji, aby upewnić się, że tylko 6 zadań może być uruchomionych współbieżnie na tym typie węzła (upewniając się, że każde zadanie będzie mieć co najmniej 10 GB pamięci do pracy z).
Zgrupowane węzły w aucie siatki
Gdy zadanie równoległe jest przesyłane do aparatu siatki, domyślne zachowanie autoskalowania używane przez usługę CycleCloud polega na traktowaniu każdego zadania MPI jako żądania pogrupowanego węzła. Zgrupowane węzły są ściśle powiązane i idealnie nadają się do przepływów pracy MPI.
Gdy zestaw zgrupowanych węzłów dołączy do klastra aparatu siatki, identyfikator grupy każdego węzła jest używany jako wartość wartości affinity_group
złożonej . Wymaganie określenia elementu affinity_group
dla zadań umożliwia harmonogramowi aparatu siatki zapewnienie, że zadania znajdują się tylko na maszynach, które znajdują się w tej samej grupie.
Automatyzacja usługi CycleCloud automatycznie zażąda zgrupowanych węzłów i przypisze je do dostępnych grup koligacji po napotkaniu zadań równoległych.
Przesyłanie zadań do aparatu siatki
Najbardziej ogólnym sposobem przesyłania zadań do harmonogramu aparatu siatki jest polecenie:
qsub my_job.sh
To polecenie prześle zadanie, które będzie uruchamiane w węźle typu "execute", czyli węźle zdefiniowanym przez nodearray "execute". Aby zadanie zostało uruchomione na węźle innego typu, na przykład typ węzła "gpu" powyżej, zmodyfikujemy nasze przesyłanie:
qsub -l slot_type=gpu my_gpu_job.sh
To polecenie zapewni, że zadanie jest uruchamiane tylko na slot_type "gpu".
Jeśli slot_type zostanie pominięty, polecenie "execute" zostanie automatycznie przypisane do zadania. Mechanizm, który automatycznie przypisuje slot_type do zadań, można zmodyfikować przez użytkownika. Można utworzyć skrypt języka Python znajdujący się w lokalizacji /opt/cycle/jetpack/config/autoscale.py , który powinien definiować pojedynczą funkcję "sge_job_handler". Ta funkcja otrzymuje reprezentację słownika zadania, podobną do danych wyjściowych qstat -j JOB_ID
polecenia i powinna zwrócić słownik zasobów twardych, które należy zaktualizować dla zadania. Na przykład poniżej znajduje się skrypt, który przypisze zadanie do slot_type "gpu", jeśli nazwa zadania zawiera litery "gpu". Umożliwiłoby to użytkownikowi przesyłanie zadań z zautomatyzowanego systemu bez konieczności modyfikowania parametrów zadania i nadal będą uruchamiane zadania w systemach i automatyczne skalowanie prawidłowych węzłów:
#!/usr/env python
#
# File: /opt/cycle/jetpack/config/autoscale.py
#
def sge_job_handler(job):
# The 'job' parameter is a dictionary containing the data present in a 'qstat -j JOB_ID':
hard_resources = {'slot_type': 'execute', 'affinity_group' : 'default' }
# Don't modify anything if the job already has a slot type
# You could modify the slot type at runtime by not checking this
if 'hard_resources' in job and 'slot_type' in job['hard_resources']:
return hard_resources
# If the job's script name contains the string 'gpu' then it's assumed to be a GPU job.
# Return a dictionary containing the new job_slot requirement to be updated.
# For example: 'big_data_gpu.sh' would be run on a 'gpu' node.
if job['job_name'].find('gpu') != -1:
hard_resources {'slot_type': 'gpu'}
else:
return hard_resources
Przekazany parametr "job" jest słownikiem zawierającym dane w wywołaniu qstat -j JOB_ID
:
{
"job_number": 5,
"job_name": "test.sh",
"script_file": "test.sh",
"account": "sge",
"owner": "cluster.user",
"uid": 100,
"group": "cluster.user",
"gid": 200,
"submission_time": "2013-10-09T09:09:09",
"job_args": ['arg1', 'arg2', 'arg3'],
"hard_resources": {
'mem_free': '15G',
'slot_type': 'execute'
}
}
Za pomocą tej funkcji skryptów można automatycznie przypisywać slot_type na podstawie dowolnego parametru zdefiniowanego w zadaniu, takiego jak argumenty, inne wymagania dotyczące zasobów, takie jak pamięć, przesyłanie użytkownika itp.
Jeśli chcesz przesłać 5 zadań z każdej "slot_type":
qsub -t 1:5 gpu_job.sh
qsub -t 1:5 normal_job.sh
W kolejce będzie teraz 10 zadań. Ze względu na zdefiniowany powyżej skrypt pięć zadań o nazwie "gpu" zostanie automatycznie skonfigurowanych do uruchamiania tylko na węzłach "slot_type=gpu". Mechanizm automatycznego skalowania CycleCloud wykryłby, że istnieją 5 zadań "gpu" i 5 zadań "execute". Ponieważ węzeł nodearray "gpu" jest zdefiniowany jako mający 2 miejsca na węzeł, usługa CycleCloud uruchamiałaby 3 z tych węzłów (5/2=2,5 zaokrąglone do 3). Istnieje 5 normalnych zadań, ponieważ typ maszyny dla "execute" nodearray ma 4 procesory CPU każdy, usługa CycleCloud uruchamia 2 z tych węzłów w celu obsługi zadań (5/4=1,25 zaokrąglone do 2). Po krótkim czasie, zanim nowo uruchomione węzły zostaną uruchomione i skonfigurowane, wszystkie 10 zadań zostanie uruchomionych do ukończenia, a następnie 5 węzłów zostanie automatycznie zamkniętych przed ponownym rozliczeniem przez dostawcę usług w chmurze.
Zakłada się, że zadania mają czas trwania jednej godziny. Jeśli środowisko uruchomieniowe zadania jest znane, algorytm skalowania automatycznego może skorzystać z tych informacji. Poinformuj automatyczne skalowanie oczekiwanego czasu wykonywania zadania przez dodanie go do kontekstu zadania. Poniższy przykład informuje o automatycznym skalowaniu, że środowisko uruchomieniowe zadania wynosi średnio 10 minut:
qsub -ac average_runtime=10 job_with_duration_of_10m.sh
Dokumentacja konfiguracji aparatu siatki
Poniżej przedstawiono opcje konfiguracji specyficzne dla aparatu siatki, które można przełączać w celu dostosowania funkcji:
Opcje konfiguracji SGE-Specific | Opis |
---|---|
gridengine.slots | Liczba miejsc dla danego węzła do raportowania do aparatu siatki. Liczba miejsc to liczba współbieżnych zadań, które może wykonać węzeł. Ta wartość jest domyślnie ustawiona na liczbę procesorów NA danym komputerze. Tę wartość można zastąpić w przypadkach, gdy zadania nie są uruchamiane na podstawie procesora CPU, ale pamięci, procesorów GPU itp. |
gridengine.slot_type | Nazwa typu "slot" zapewnia węzeł. Wartość domyślna to "execute". Gdy zadanie jest oznaczone zasobem twardym "slot_type=", to zadanie zostanie uruchomione tylko na maszynie tego samego typu gniazda. Dzięki temu można tworzyć różne konfiguracje oprogramowania i sprzętu na węzeł i zapewnić, że odpowiednie zadanie jest zawsze zaplanowane we właściwym typie węzła. |
gridengine.ignore_fqdn | Wartość domyślna: true. Ustaw wartość false, jeśli wszystkie węzły w klastrze nie są częścią jednej domeny DNS. |
gridengine.version | Ustawienie domyślne: "2011.11". Jest to wersja aparatu grid do zainstalowania i uruchomienia. Jest to obecnie opcja domyślna i tylko . W przyszłych dodatkowych wersjach oprogramowania Grid Engine mogą być obsługiwane. |
gridengine.root | Ustawienie domyślne: "/sched/sge/sge-2011.11" Jest to miejsce, w którym aparat siatki zostanie zainstalowany i zainstalowany na każdym węźle w systemie. Zaleca się, aby ta wartość nie została zmieniona, ale jeśli jest, powinna być ustawiona na tę samą wartość w każdym węźle w klastrze. |
Usługa CycleCloud obsługuje standardowy zestaw atrybutów automatycznego ściągnięcia między harmonogramami:
Atrybut | Opis |
---|---|
cyclecloud.cluster.autoscale.stop_enabled | Czy w tym węźle jest włączone automatyczne zatrzymanie? [true/false] |
cyclecloud.cluster.autoscale.idle_time_after_jobs | Czas (w sekundach) dla węzła do bezczynności po zakończeniu zadań przed skalowaniem w dół. |
cyclecloud.cluster.autoscale.idle_time_before_jobs | Czas (w sekundach) dla węzła do bezczynności przed ukończeniem zadań przed skalowaniem w dół. |
Znane problemy
-
qsh
polecenie sesji interakcyjnej nie działa. Użyjqrsh
jako alternatywy. - Kompleks
exclusive=1
nie jest przestrzegany przez autoskalowanie. W rezultacie może zaczynać się mniej węzłów niż oczekiwano.
Uwaga
Mimo że system Windows jest oficjalnie obsługiwaną platformą GridEngine, usługa CycleCloud nie obsługuje obecnie uruchamiania narzędzia GridEngine w systemie Windows.
Ta strona dotyczy możliwości i konfiguracji używania (Altair) GridEngine z usługą CycleCloud.
Konfigurowanie zasobów
Aplikacja cyclecloud-gridengine pasuje do zasobów sge do zasobów w chmurze platformy Azure, aby zapewnić zaawansowane narzędzia do skalowania automatycznego i konfiguracji klastra. Aplikacja zostanie wdrożona automatycznie dla klastrów utworzonych za pośrednictwem interfejsu użytkownika usługi CycleCloud lub może zostać zainstalowana na dowolnym hoście administracyjnym gridengine w istniejącym klastrze.
Instalowanie lub uaktualnianie cyklucloud-gridengine
Pakiet cyclecloud-gridengine jest dostępny w serwisie github jako artefakt wydania. Instalowanie i uaktualnianie będzie tym samym procesem. Aplikacja wymaga języka Python3 z programem virtualenv.
tar xzf cyclecloud-gridengine-pkg-*.tar.gz
cd cyclecloud-gridengine
./install.sh
Ważne pliki
Aplikacja analizuje konfiguracjęge za każdym razem, gdy jest wywoływana — zadania, kolejki, kompleksy. Informacje są dostarczane w stderr i stdout polecenia, a także do pliku dziennika, zarówno na konfigurowalnych poziomach. Wszystkie polecenia zarządzania gridengine z argumentami są również rejestrowane w pliku.
Opis | Lokalizacja |
---|---|
Autoskaluj konfigurację | /opt/cycle/gridengine/autoscale.json |
Dziennik automatycznego skalowania | /opt/cycle/jetpack/logs/autoscale.log |
dziennik śledzenia qconf | /opt/cycle/jetpack/logs/qcmd.log |
Kolejki, grupy hostów i środowiska równoległe SGE
Narzędzie autoskalowania azge
cyclecloud-gridengine , doda hosty do klastra zgodnie z konfiguracją klastra. Operacje skalowania automatycznego wykonują następujące akcje.
- Przeczytaj żądanie zasobu zadania i znajdź odpowiednią maszynę wirtualną do uruchomienia
- Uruchom maszynę wirtualną i poczekaj na jej gotowość
- Odczytywanie kolejki i środowiska równoległego z zadania
- Na podstawie kolejki/pe przypisz hosta do odpowiedniej grupy hostów
- Dodaj hosta do klastra, a także do innej kolejki zawierającej grupę hostów
Rozważ następującą definicję kolejki dla kolejki o nazwie short.q
hostlist @allhosts @mpihg01 @mpihg02 @lowprio
...
seq_no 10000,[@lowprio=10],[@mpihg01=100],[@mpihg02=200]
pe_list NONE,[@mpihg01=mpi01], \
[@mpihg02=mpi02]
Przesyłanie zadania przez qsub -q short.q -pe mpi02 12 my-script.sh
program rozpocznie się od dzierżawy jednej maszyny wirtualnej, a po dodaniu go do klastra dołączy do grupy hostów @mpihg02 , ponieważ jest to grupa hostów dostępna zarówno dla kolejki, jak i do środowiska równoległego. Zostanie również dodana do @allhosts, która jest specjalną grupą hostów.
Bez określenia pe wynikowa qsub -q short.q my-script.sh
maszyna wirtualna zostanie dodana do @allhosts i @lowpriority są to grupy hostów w kolejce, które nie są przypisane pes.
Na koniec przesłane qsub -q short.q -pe mpi0* 12 my-script.sh
zadanie spowoduje dodanie maszyny wirtualnej do @mpihg01 lub @mpihg02 w zależności od przewidywań alokacji usługi CycleCloud.
Środowiska równoległe niejawnie utożsamiają się z grupą umieszczania w chmurze. Maszyny wirtualne w środowisku PE są ograniczone do bycia w tej samej sieci. Jeśli chcesz użyć pe, który nie przechowuje grupy umieszczania, użyj pliku autoscale.json , aby zrezygnować.
W tym miejscu zrezygnujemy z grup umieszczania dla aplikacji make pe:
"gridengine": {
"pes": {
"make": {
"requires_placement_groups": false
}
},
Grupy umieszczania w usłudze CycleCloud
Grupy umieszczania cycleCloud mapuj jeden do jednego do usługi Azure VMSS z singlePlacementGroup — maszyny wirtualne w grupie umieszczania współużytkować sieć szkieletową Infiniband i udostępniać tylko maszynom wirtualnym w grupie umieszczania. Aby intuicyjnie zachować te silosy, grupach umieszczania mapuje również 1:1 ze środowiskiem równoległym gridengine.
Określenie środowiska równoległego dla zadania spowoduje ograniczenie zadania do uruchomienia w grupie umieszczania za pomocą logiki przypisania grupy hostów inteligentnych. Możesz zrezygnować z tego zachowania za pomocą wyżej wymienionej konfiguracji w pliku autoscale.json : "required_placement_groups" : false
.
Konfiguracja autoskalu
Ta wtyczka automatycznie skaluje siatkę, aby zaspokoić wymagania obciążenia. Plik konfiguracji autoskalowania.json określa zachowanie autoskalatora aparatu siatki.
- Ustawianie szczegółów połączenia cyclecloud
- Ustawianie czasomierza zakończenia dla bezczynnych węzłów
- Możliwe jest skalowanie automatyczne wielowymiarowe, ustawienie atrybutów używanych w zadaniu pakowania, np. miejsc, pamięci
- Rejestrowanie kolejek, środowisk równoległych i grup hostów do zarządzania
Konfiguracja | Typ | Opis |
---|---|---|
url | Ciąg | CC URL |
nazwa użytkownika/hasło | Ciąg | Szczegóły połączenia CC |
cluster_name | Ciąg | Nazwa klastra CC |
default_resources | Mapa | Łączenie zasobu węzła z zasobem hosta aparatu siatki w celu automatycznego skalowania |
idle_timeout | int | Czas oczekiwania przed zakończeniem bezczynnych węzłów (s) |
boot_timeout | int | Czas oczekiwania przed kończeniem węzłów w długich fazach konfiguracji (s) |
gridengine.relevant_complexes | Lista (ciąg) | Aparat siatki złożony do rozważenia w autoskalowaniu, np. gniazda, mem_free |
gridengine.logging | Plik | Lokalizacja pliku konfiguracji rejestrowania |
gridengine.pes | Struktura | Określ zachowanie pEs, np. requires_placement_group = false |
Program skalowania automatycznego będzie uwzględniał tylko odpowiedni zasób
Dodatkowy zasób skalowania automatycznego
Domyślnie klaster z skalowaniem na podstawie liczby miejsc żądanych przez zadania. Możemy dodać kolejny wymiar do skalowania automatycznego.
Załóżmy, że chcemy automatycznie skalować według żądania zasobu zadania dla m_mem_free
polecenia .
- Dodaj
m_mem_free
do pliku w plikugridengine.relevant_resources
autoscale.json - Łącze
m_mem_free
do zasobu pamięci na poziomie węzła w pliku autoscale.json
Te atrybuty mogą być odwołaniami jako node.*
wartością w _default/zasobach.
Węzeł | Typ | Opis |
---|---|---|
nodearray | Ciąg | Nazwa cyklu nodearray nodearray |
placement_group | Ciąg | Nazwa grupy umieszczania w usłudze cyclecloud w środowisku nodearray |
vm_size | Ciąg | Nazwa produktu maszyny wirtualnej, np. "Standard_F2s_v2" |
vcpu_count | int | Wirtualne procesory CPU dostępne w węźle, jak wskazano na poszczególnych stronach produktu |
pcpu_count | int | Fizyczne procesory CPU dostępne w węźle |
pamięć | Ciąg | Przybliżona pamięć fizyczna dostępna na maszynie wirtualnej ze wskaźnikiem jednostki, np. "8,0g" |
Dodatkowe atrybuty znajdują się w node.resources.*
przestrzeni nazw, np. "node.resources".
Węzeł | Typ | Opis |
---|---|---|
ncpus | Ciąg | Liczba procesorów CPU dostępnych na maszynie wirtualnej |
pcpus | Ciąg | Liczba fizycznych procesorów CPU dostępnych na maszynie wirtualnej |
ngpus | Liczba całkowita | Liczba procesorów GPU dostępnych na maszynie wirtualnej |
memb | Ciąg | Przybliżona pamięć fizyczna dostępna na maszynie wirtualnej ze wskaźnikiem jednostki, np. "8,0b" |
memkb | Ciąg | Przybliżona pamięć fizyczna dostępna na maszynie wirtualnej ze wskaźnikiem jednostki, np. "8,0 tys." |
memmb | Ciąg | Przybliżona ilość pamięci fizycznej dostępnej na maszynie wirtualnej ze wskaźnikiem jednostki, np. "8,0 mln" |
memgb | Ciąg | Przybliżona pamięć fizyczna dostępna na maszynie wirtualnej ze wskaźnikiem jednostki, np. "8,0g" |
memtb | Ciąg | Przybliżona pamięć fizyczna dostępna na maszynie wirtualnej ze wskaźnikiem jednostki, np. "8,0t" |
Slotów | Liczba całkowita | Tak samo jak ncpus |
slot_type | Ciąg | Etykieta dodawania dla rozszerzeń. Zazwyczaj nie jest używany. |
m_mem_free | Ciąg | Oczekiwano wolnej pamięci na hoście wykonywania, np. "3.0g" |
mfree | Ciąg | Taki sam jak _m/_mem/bezpłatny |
Mapowanie zasobów
Istnieją również matematyki dostępne dla default_resources — zmniejsz miejsca w określonej tablicy węzłów o dwa i dodaj zasób platformy Docker do wszystkich węzłów:
"default_resources": [
{
"select": {"node.nodearray": "beegfs"},
"name": "slots",
"value": "node.vcpu_count",
"subtract": 2
},
{
"select": {},
"name": "docker",
"value": true
},
Mapowanie wirtualnych procesorów wirtualnych węzła na złożone gniazda i memmb
mem_free
często używane wartości domyślne.
Pierwsze skojarzenie jest wymagane.
"default_resources": [
{
"select": {},
"name": "slots",
"value": "node.vcpu_count"
},
{
"select": {},
"name": "mem_free",
"value": "node.resources.memmb"
}
],
Należy pamiętać, że jeśli złożony skrót nie jest równy całej wartości, zdefiniuj obie wartości w default_resources gdzie physical_cpu
jest nazwą złożoną:
"default_resources": [
{
"select": {},
"name": "physical_cpu",
"value": "node.pcpu_count"
},
{
"select": {},
"name": "pcpu",
"value": "node.resources.physical_cpu"
}
]
Kolejność jest ważna, jeśli chcesz mieć określone zachowanie dla określonego atrybutu. Aby przydzielić jedno miejsce dla określonego węzłaarray, zachowując domyślną liczbę miejsc dla wszystkich innych węzłów:
"default_resources": [
{
"select": {"node.nodearray": "FPGA"},
"name": "slots",
"value": "1",
},
{
"select": {},
"name": "slots",
"value": "node.vcpu_count"
},
]
Grupy hostów
Narzędzie do automatycznego skalowania Usługi CycleCloud, próbując spełnić wymagania dotyczące zadania, zamapuje węzły na odpowiednią grupę hostów. Wszystkie kolejki, środowiska równoległe i kompleksy są brane pod uwagę. Większość logiki jest zgodna z odpowiednim zasobnikiem cyclecloud (i ilością węzłów) z odpowiednią grupą hostów sge.
Dla zadania przesłanego jako: qsub -q "cloud.q" -l "m_mem_free=4g" -pe "mpi*" 48 ./myjob.sh
Usługa CycleCloud znajdzie skrzyżowanie grup hostów, które:
- Są uwzględniane w pe_list dla pliku cloud.q i pasują do nazwy pe, np.
pe_list [@allhosts=mpislots],[@hpc1=mpi]
. - Mieć odpowiednie zasoby i limit przydziału subskrypcji, aby zapewnić wszystkie zasoby zadań.
- Nie są filtrowane przez konfigurację ograniczeń grupy hostów.
Istnieje możliwość, że wiele grup hostów spełni te wymagania, w takim przypadku logika będzie musiała wybrać. Istnieją trzy sposoby rozpoznawania niejednoznaczności w członkostwie w grupie hostów:
- Skonfiguruj kolejki, aby nie było niejednoznaczności.
- Dodaj ograniczenia do pliku autoscale.json.
- Let CycleCloud wybierz amoungst pasujących grup hostów w sposób uporządkowany według nazwy, dostosowując się
weight_queue_host_sort < weight_queue_seqno
do konfiguracji harmonogramu. - Ustaw
seq_no 10000,[@hostgroup1=100],[@hostgroup2=200]
w konfiguracji kolejki, aby wskazać preferencję grupy hostów.
Ograniczenia grupy hostów
Gdy wiele grup hostów jest definiowanych przez kolejkę lub xproject, wszystkie te grupy hostów mogą potencjalnie mieć dodane do nich hosty. Można ograniczyć rodzaje hostów, które można dodać do kolejek, ustawiając ograniczenia grupy hostów. Ustaw ograniczenie na podstawie właściwości węzła.
"gridengine": {
"hostgroups": {
"@mpi": {
"constraints": {
"node.vm_size": "Standard_H44rs"
}
},
"@amd-mem": {
"constraints" : {
"node.vm_size": "Standard_D2_v3",
"node.nodearray": "hpc"
}
},
}
}
WSKAZÓWKA: Sprawdź wszystkie dostępne właściwości węzła według .
azge buckets
azge
Ten pakiet jest dostarczany z wierszem polecenia, azge. Ten program powinien służyć do automatycznego skalowania i rozbił wszystkie podprocesy w ramach autoskalowania.
Te polecenia polegają na ustawieniu zmiennych środowiskowych gridengine — musisz mieć możliwość wywołania qconf
i qsub
z tego samego profilu, w którym azge
jest wywoływana.
polecenia azge | Opis |
---|---|
walidacja | Sprawdza znane błędy konfiguracji w narzędziu autoscaler lub gridengine |
Zadania | Pokazuje wszystkie zadania w kolejce |
Wiadra | Pokazuje dostępne pule zasobów na potrzeby skalowania automatycznego |
Węzłów | Pokazuje hosty i właściwości klastra |
Żądanie | Spełnia wymagania dotyczące zadań w zasobnikach cyclecloud i zapewnia wynik autoskalowania |
autoscale | Wykonuje pełne autoskalowanie, uruchamianie i usuwanie węzłów zgodnie z konfiguracjami |
Podczas modyfikowania konfiguracji harmonogramu (qconf) lub konfiguracji autoskalowania (autoskalowanie.json), a nawet skonfigurowania po raz pierwszy, azge może służyć do sprawdzania zachowania autoskalowania jest zgodne z oczekiwaniami. Jako główny możesz uruchomić następujące operacje. Zaleca się zapoznanie się z tymi elementami w celu zrozumienia zachowania autoskalowania.
- Uruchom polecenie ,
azge validate
aby zweryfikować konfiguracje pod kątem znanych problemów. - Uruchom polecenie ,
azge buckets
aby sprawdzić, jakie zasoby oferuje klaster CycleCloud. - Uruchom polecenie ,
azge jobs
aby sprawdzić szczegóły zadania w kolejce. - Uruchom
azge demand
zadanie, aby dopasować zasobnik, sprawdź, które zadania są zgodne z zasobnikami i grupami hostów. - Uruchom polecenie
azge autoscale
, aby rozpocząć proces alokacji węzłów lub dodać węzły, które są gotowe do przyłączenia.
Następnie, gdy te polecenia zachowują się zgodnie z oczekiwaniami, włącz trwające autoskalowanie, dodając azge autoscale
polecenie do głównej tabeli crontab. (Souce gridengine zmienne środowiskowe)
* * * * * . $SGE_ROOT/common/settings.sh && /usr/local/bin/azge autoscale -c /opt/cycle/gridengine/autoscale.json
Tworzenie klastra hybrydowego
Usługa CycleCloud będzie obsługiwać scenariusz rozszerzenia chmury. Podstawowa konfiguracja zakłada, że $SGE_ROOT
katalog jest dostępny dla węzłów w chmurze. To założenie może być złagodzone przez ustawienie gridengine.shared.spool = false
, gridengine.shared.bin = false
i zainstalowanie usługi GridEngine lokalnie.
W przypadku prostego przypadku należy podać system plików, który można zainstalować przez węzły wykonywania zawierające $SGE_ROOT
katalog i skonfigurować instalację w ustawieniach opcjonalnych. Po wydaniu zależności katalogów sched i udostępnionych można zamknąć węzeł harmonogramu, który jest częścią klastra domyślnie i używać konfiguracji z zewnętrznego systemu plików.
- Utwórz nowy klaster gridengine.
- Wyłącz zwrotny serwer proxy.
- Zastąp /sched i /shared z zewnętrznymi systemami plików.
- Zapisz klaster.
- Usuń węzeł harmonogramu jako akcję w interfejsie użytkownika.
- Uruchom klaster. Początkowo nie będą uruchamiane żadne węzły.
- Konfigurowanie
cyclecloud-gridengine
za pomocą pliku autoscale.json do korzystania z nowego klastra
Korzystanie z aparatu siatki Univa w usłudze CycleCloud
Projekt CycleCloud dla GridEngine domyślnie używa sge-2011.11 . Możesz użyć własnych instalatorów Altair GridEngine zgodnie z umową licencyjną Altair.
W tej sekcji opisano sposób korzystania z usługi Altair GridEngine z projektem CycleCloud GridEngine.
Wymagania wstępne
W tym przykładzie zostanie użyta wersja demonstracyjna 8.6.1, ale obsługiwane są wszystkie wersje ge w wersji > 8.4.0.
- Użytkownicy muszą podać pliki binarne UGE
- ge-8.6.x-bin-lx-amd64.tar.gz
- ge-8.6.x-common.tar.gz
- Należy skonfigurować interfejs wiersza polecenia CycleCloud. Dokumentacja jest dostępna tutaj
Kopiowanie plików binarnych do funkcji locker w chmurze
Uzupełniająca wersja AGE (8.6.7-demo) jest dystrybuowana z usługą CycleCloud. Aby użyć innej wersji, przekaż pliki binarne na konto magazynu używane przez usługę CycleCloud.
$ azcopy cp ge-8.6.12-bin-lx-amd64.tar.gz https://<storage-account-name>.blob.core.windows.net/cyclecloud/gridengine/blobs/
$ azcopy cp ge-8.6.12-common.tar.gz https://<storage-account-name>.blob.core.windows.net/cyclecloud/gridengine/blobs/
Modyfikowanie konfiguracji do szablonu klastra
Utwórz lokalną kopię szablonu gridengine i zmodyfikuj go, aby zamiast domyślnego używać instalatorów UGE.
wget https://raw.githubusercontent.com/Azure/cyclecloud-gridengine/master/templates/gridengine.txt
W pliku gridengine.txt znajdź pierwsze wystąpienie [[[configuration]]]
i wstaw tekst, tak aby był zgodny z poniższym fragmentem kodu. Ten plik nie jest wrażliwy na wcięcie.
UWAGA: Szczegóły konfiguracji, szczególnie wersji, powinny być zgodne z nazwą pliku instalatora.
[[[configuration gridengine]]]
make = ge
version = 8.6.12-demo
root = /sched/ge/ge-8.6.12-demo
cell = "default"
sge_qmaster_port = "537"
sge_execd_port = "538"
sge_cluster_name = "grid1"
gid_range = "20000-20100"
qmaster_spool_dir = "/sched/ge/ge-8.6.12-demo/default/spool/qmaster"
execd_spool_dir = "/sched/ge/ge-8.6.12-demo/default/spool"
spooling_method = "berkeleydb"
shadow_host = ""
admin_mail = ""
idle_timeout = 300
managed_fs = true
shared.bin = true
ignore_fqdn = true
group.name = "sgeadmin"
group.gid = 536
user.name = "sgeadmin"
user.uid = 536
user.gid = 536
user.description = "SGE admin user"
user.home = "/shared/home/sgeadmin"
user.shell = "/bin/bash"
Te konfiguracje zastąpią domyślną wersję i lokalizację instalacji gridengine po uruchomieniu klastra.
Nie można bezpiecznie przenieść się z /sched
klastra, ponieważ jest to specjalnie udostępniona lokalizacja nfs w klastrze.