CycleCloud GridEngine Cluster

Open Grid Scheduler (Grid Engine) można łatwo włączyć w klastrze Usługi Azure CycleCloud, modyfikując definicję "run_list". Klaster Grid Engine składa się z dwóch podstawowych komponentów. Pierwszy to węzeł "główny", który udostępnia wspólny system plików, w którym działa oprogramowanie Grid Engine. Drugi to zestaw węzłów wykonawczych, które jako hosty montują wspólny system plików i uruchamiają przesłane zadania. Na przykład prosty fragment szablonu klastra 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]

Importowanie i uruchamianie klastra z definicją w usłudze CycleCloud powoduje utworzenie jednego węzła głównego. Węzły execute można dodać do klastra za pomocą polecenia cyclecloud add_node. Na przykład, aby dodać 10 kolejnych węzłów „execute”:

cyclecloud add_node grid-engine -t execute -c 10

Autoskalowanie systemu Grid Engine

Usługa Azure CycleCloud obsługuje skalowanie automatyczne dla Grid Engine. To zachowanie oznacza, że oprogramowanie stale monitoruje stan kolejki i automatycznie włącza lub wyłącza węzły zgodnie z potrzebami, aby wydajnie ukończyć obciążenie zarówno pod względem czasu, jak i kosztu. Automatyczne skalowanie dla Grid Engine można włączyć, dodając Autoscale = true do definicji klastra.

[cluster grid-engine]
Autoscale = True

Domyślnie wszystkie zadania przesłane do kolejki Grid Engine są wykonywane na maszynach typu "execute". Te maszyny zdefiniowane przez tablicę węzłów o nazwie "execute". Nie jesteś ograniczony do nazwy 'execute', ani do jednego typu konfiguracji maszyny, aby uruchamiać zadania i skalować automatycznie.

Na przykład typowy scenariusz obejmuje klaster z dwiema różnymi definicjami węzłów. Jeden z nich jest przeznaczony do uruchamiania "normalnych" zadań, które używają standardowych procesorów CPU. Druga jest przeznaczona dla zadań wymagających maszyn z obsługą procesora GPU. W takim przypadku należy niezależnie skalować kolejkę zarówno przez zwykłe zadania, jak i zadania GPU, aby upewnić się, że masz odpowiednią liczbę każdej maszyny do obsługi 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 przedstawionym przykładzie istnieją teraz dwie tablice węzłów: jedna jest standardową tablicą węzłów execute, a druga nosi nazwę gpu, dostarczając typ maszyny z dwoma układami GPU NVIDIA (Standard_NV12 w Azure). Należy również pamiętać, że istnieją teraz dwa nowe elementy w sekcji konfiguracji oprócz przepisu "csge:sgeexec". Dodanie gridengine.slot_type = gpu informuje harmonogram Grid Engine, że te węzły powinny być nazwane jako węzły "gpu", a zatem powinny uruchamiać tylko zadania "gpu". Nazwa "gpu" jest dowolna, ale najbardziej przydatna jest nazwa opisującą węzeł. Ustaw gridengine.slots = 2, aby poinformować oprogramowanie, że ten typ węzła może maksymalnie uruchamiać dwa zadania jednocześnie (Standard_NV12 ma tylko 2 GPU).

Domyślnie Grid Engine przypisuje liczbę miejsc na węzeł na podstawie liczby jednostek CPU w systemie. W takim przypadku domyślne zachowanie może spowodować jednoczesne uruchomienie zbyt wielu zadań w jednym węźle. W przedstawionym przykładzie parametr CoreCount=2 jest ustawiany na tablicy nodearray, aby dopasować liczbę procesorów GPU dostępnych w typie maszyny, co umożliwia usłudze CycleCloud poprawne skalowanie tej tablicy zgodnie z liczbą procesorów GPU w porównaniu do liczby procesorów CPU.

Liczbę gniazd i typy gniazda dla maszyn można zweryfikować, 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 jest po jednym rodzaju "slot_type", czyli "execute" i "gpu". Typy gniazd są konfigurowane indywidualnie, a liczba gniazd dla gniazda "execute" wynosi 4, co odpowiada liczbie procesorów CPU w maszynie. Liczba miejsc dla typu gniazda "gpu" wynosi 2, które określono w naszym szablonie konfiguracji klastra. Trzecia maszyna to węzeł główny, który nie uruchamia zadań.

Zaawansowane korzystanie z systemu "Grid Engine"

Te ustawienia konfiguracji umożliwiają zaawansowane dostosowywanie węzłów i tablic węzłów. Na przykład, jeśli zadania wymagają określonej ilości pamięci, powiedzmy 10 GB każde, można zdefiniować tablicę węzłów 'wykonawczych', która uruchamia maszyny z 60 GB pamięci, a następnie dodać opcje konfiguracji gridengine.slots = 6 w celu zapewnienia, że na tego typu węźle może być uruchomionych współbieżnie tylko 6 zadań (zapewniając, że każde zadanie ma co najmniej 10 GB pamięci do pracy).

Pogrupowane węzły w Grid Engine

Gdy zadanie równoległe jest przesyłane do silnika gridowego, domyślne zachowanie autoskalowania stosowane przez CycleCloud traktuje każde zadanie MPI jako pojedyncze żądanie dotyczące pogrupowania węzłów. Pogrupowane 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 Grid Engine, identyfikator grupy każdego węzła jest używany jako wartość złożona affinity_group. Wymaganie określenia elementu affinity_group dla zadań umożliwia harmonogramowi Grid Engine zapewnienie, że zadania umieszczane są tylko na maszynach, które znajdują się w tej samej grupie.

Automatyzacja usługi CycleCloud automatycznie tworzy zapotrzebowanie na zgrupowane węzły i przypisuje je do dostępnych grup affinity po napotkaniu zadań równoległych.

Przesyłanie zadań do Grid Engine

Najbardziej ogólnym sposobem przesyłania zadań do harmonogramu Grid Engine jest użycie polecenia:

qsub my_job.sh

To polecenie przesyła zadanie uruchamiane na węźle typu "execute", czyli na węźle zdefiniowanym przez zbiór węzłów 'nodearray' "execute". Aby wykonać zadanie w środowisku nodearray innego typu, na przykład pokazano typ węzła "gpu", modyfikujemy nasze przesyłanie:

qsub -l slot_type=gpu my_gpu_job.sh

To polecenie gwarantuje, że zadanie jest uruchamiane tylko na 'slot_type' równym 'gpu'.

W przypadku pominięcia slot_type polecenie "execute" automatycznie przypisuje zadanie. Użytkownik może zmodyfikować mechanizm, który automatycznie przypisuje slot_type do zadań. Skrypt języka Python znajdujący się w lokalizacji /opt/cycle/jetpack/config/autoscale.py można utworzyć, co powinno definiować pojedynczą funkcję "sge_job_handler". Ta funkcja otrzymuje słownikową reprezentację zadania, podobną do danych wyjściowych qstat -j JOB_ID polecenia i powinna zwrócić słownik zasobów twardych, które muszą zostać zaktualizowane dla zadania.

Na przykład poniższy skrypt przypisuje zadanie do slot_type "gpu", jeśli nazwa zadania zawiera litery "gpu". Użytkownicy mogą automatycznie przesyłać swoje zadania bez zmieniania parametrów zadania, jednocześnie zapewniając uruchamianie zadań i automatyczne skalowanie odpowiednich 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

Parametr "job" przekazany jako argument 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 zdefiniowanego parametru zadania, takiego jak argumenty, wymagania dotyczące zasobów, takie jak pamięć lub przesyłający użytkownik.

Załóżmy, że przesyłasz 5 zadań dla każdego rodzaju „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 skrypt pięć zadań ze słowem 'gpu' w nazwie zostanie automatycznie skonfigurowanych do uruchamiania tylko na węzłach 'slot_type=gpu'. Mechanizm automatycznego skalowania CycleCloud wykryłby, że istnieje 5 zadań „gpu” i 5 zadań „wykonawczych”. Ponieważ tablica węzłów 'gpu' jest zdefiniowana jako mająca 2 gniazda na węzeł, usługa CycleCloud uruchomi 3 z tych węzłów (5/2=2,5 zaokrąglone do 3).

Istnieje pięć normalnych zadań, ponieważ typ maszyny dla "execute" nodearray ma 4 CPU, CycleCloud uruchomi 2 z tych węzłów, aby obsłużyć zadania (5/4=1,25 zaokrąglone do 2). Po krótkim okresie uruchamiania nowo uruchomione węzły są uruchamiane i konfigurowane samodzielnie. Po przygotowaniu wszystkie 10 zadań zostanie wykonanych do końca. Następnie 5 węzłów zostanie automatycznie zamkniętych przed rozpoczęciem kolejnego cyklu rozliczeniowego od dostawcy 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 korzystać z tych informacji. Poinformuj o automatycznym skalowaniu oczekiwanego czasu wykonywania zadania, dodając go do kontekstu zadania. Poniższy przykład ustawia czas wykonywania zadania dla automatycznego skalowania na 10 minut.

qsub -ac average_runtime=10 job_with_duration_of_10m.sh

Dokumentacja konfiguracji Grid Engine

Poniżej przedstawiono opcje konfiguracji specyficzne dla Grid Engine, które można przełączać, aby dostosować funkcjonalność:

Usługa CycleCloud obsługuje standardowy zestaw atrybutów automatycznego zatrzymania w różnych harmonogramach.

Znane problemy

• qsh polecenie sesji interakcyjnej nie działa. Użyj qrsh jako alternatywy.
• Skalowanie automatyczne nie uwzględnia exclusive=1 kompleksu, co może spowodować uruchomienie mniejszej liczby węzłów niż oczekiwano.

Ta strona dotyczy możliwości i konfiguracji używania (Altair) GridEngine z usługą CycleCloud.

Konfigurowanie zasobów

Aplikacja cyclecloud-gridengine dopasowuje zasoby SGE do zasobów w chmurze Microsoft Azure, aby zapewnić zaawansowane narzędzia do automatycznego skalowania oraz konfiguracji klastra. Aplikacja jest wdrażana automatycznie dla klastrów utworzonych za pośrednictwem interfejsu użytkownika cycleCloud lub można ją zainstalować na dowolnym hoście administracyjnym usługi GridEngine w istniejącym klastrze.

Instalowanie lub uaktualnianie CycleCloud-GridEngine

Pakiet cyclecloud-gridengine jest dostępny na GitHub jako artefakt wydania. Instalowanie i uaktualnianie jest zgodne z tym samym procesem. Aplikacja wymaga języka Python3 z elementem virtualenv.

tar xzf cyclecloud-gridengine-pkg-*.tar.gz
cd cyclecloud-gridengine
./install.sh

Ważne pliki

Aplikacja analizuje konfigurację sge za każdym razem, gdy jest uruchamiana — zadania, kolejki, kompleksy. Informacje są udostępniane w stderr i stdout polecenia i w pliku dziennika, zarówno na konfigurowalnych poziomach. Wszystkie polecenia zarządzania GridEngine z argumentami również są rejestrowane w pliku.

Kolejki SGE, grupy hostów i środowiska równoległe

Narzędzie do automatycznego skalowania cyclecloud-gridengine dodaje azgehosty do klastra zgodnie z konfiguracją klastra. Operacje skalowania automatycznego wykonują następujące akcje.

1. Przeczytaj żądanie zasobu zadania i znajdź odpowiednią maszynę wirtualną do uruchomienia
2. Uruchom maszynę wirtualną i poczekaj na jej gotowość
3. Odczytaj kolejkę i środowisko równoległe z zadania
4. Na podstawie kolejki/pe przypisz hosta do odpowiedniej grupy hostów
5. Dodaj hosta do klastra i do dowolnej 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]

Przesłanie zadania przez qsub -q short.q -pe mpi02 12 my-script.sh uruchamia przynajmniej jedną maszynę wirtualną. Po dodaniu klastra dołącza do @mpihg02 grupy hostów, ponieważ jest to grupa hostów dostępna zarówno dla kolejki, jak i środowiska równoległego. Również dołącza do specjalnej grupy hostów @allhosts.

Jeśli przesyłasz zadanie z elementem qsub -q short.q my-script.sh i nie określisz środowiska równoległego pe, wynikowa maszyna wirtualna dołącza do grup hostów @allhosts i @lowpriority połączonych z kolejką, do której nie są przypisane żadne pe.

Ostatecznie, zadanie przesłane z qsub -q short.q -pe mpi0* 12 my-script.sh skutkuje dodaniem maszyny wirtualnej do @mpihg01 lub @mpihg02, w zależności od przewidywań co do alokacji usługi CycleCloud.

Środowiska równoległe niejawnie są równoważne grupie umieszczania Cyclecloud. Maszyny wirtualne w środowisku PE są ograniczone do znajdowania się w tej samej sieci. Jeśli chcesz użyć pe, który nie przechowuje grupy umieszczania, użyj autoscale.json , aby zrezygnować.

W tym miejscu zrezygnujemy z grup alokacji dla make pe:

"gridengine": {
    "pes": {
      "make": {
        "requires_placement_groups": false
      }
    },

Grupy umieszczania CycleCloud

Grupy umieszczania CycleCloud mapują się jeden do jednego do usługi Azure VMSS z funkcją SinglePlacementGroup — maszyny wirtualne w grupie umieszczania współużytkują fabrykę Infiniband i udostępniają tylko maszynom wirtualnym w grupie umieszczania. Aby intuicyjnie zachować te silosy, grupy umieszczania mapują 1:1 ze środowiskiem równoległym GridEngine.

Określenie środowiska równoległego dla zadania ogranicza jego uruchamianie do grupy lokalizacyjnej za pomocą logiki inteligentnego przypisania do grupy hostów. To zachowanie można wyłączyć za pomocą odpowiedniej konfiguracji w autoscale.json: "required_placement_groups" : false.

Konfiguracja skalowania automatycznego

Ta wtyczka automatycznie skaluje siatkę w celu spełnienia wymagań obciążenia. Plik konfiguracjiautoscale.json określa zachowanie autoskalatora aparatu siatki.

• Ustawianie szczegółów połączenia cyclecloud
• Ustaw czasomierz zakończenia dla bezczynnych węzłów
• Obsługiwane jest skalowanie automatyczne wielowymiarowe. Można skonfigurować atrybuty, które mają być używane w pakowaniu zadania, na przykład miejsca lub pamięć
• Rejestruj kolejki, środowiska równoległe i grupy hostów do zarządzania

Program skalowania automatycznego uwzględnia tylko odpowiedni zasób

Inny zasób automatycznego skalowania

Domyślnie zadania żądają wielu miejsc, a klaster jest skalowany na podstawie tych żądań.

Załóżmy, że chcemy automatycznie skalować względem zasobu wymaganego przez zadanie dla elementu m_mem_free.

1. Dodaj m_mem_free do gridengine.relevant_resourcesautoscale.json
2. Połącz m_mem_free z zasobem pamięci na poziomie węzła w autoscale.json

Te atrybuty mogą być odwoływane za pomocą node.* jako wartość w _default/zasobach.

Inne atrybuty znajdują się w node.resources.* przestrzeni nazw, na przykład "node.resources".

Mapowanie zasobów

Dostępne są również obliczenia matematyczne dla default_resources — zmniejsz liczbę miejsc 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 procesorów wirtualnych węzła na złożoną strukturę gniazd oraz wartości domyślne memmb i mem_free są często używane. Pierwsze skojarzenie jest wymagane.

    "default_resources": [
    {
      "select": {},
      "name": "slots",
      "value": "node.vcpu_count"
    },
    {
      "select": {},
      "name": "mem_free",
      "value": "node.resources.memmb"
    }
 ],

Jeśli kompleks ma skrót nie równy całej wartości, zdefiniuj obie 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, gdy chcesz uzyskać określone zachowanie dla konkretnego atrybutu. Aby przydzielić jedno miejsce dla określonej tablicy węzłów przy zachowaniu domyślnej liczby miejsc dla wszystkich innych tablic 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 CycleCloud, próbując spełnić wymagania dotyczące zadań, przypisuje węzły do odpowiedniej grupy hostów. Wszystkie kolejki, środowiska równoległe i złożone są brane pod uwagę. Większość logiki polega na dopasowywaniu odpowiedniego koszyka cyclecloud (i liczby węzłów) do odpowiedniej grupy hostów sge.

W przypadku zadania przesłanego jako: qsub -q "cloud.q" -l "m_mem_free=4g" -pe "mpi*" 48 ./myjob.sh

Usługa CycleCloud znajduje skrzyżowanie grup hostów, które:

1. Są uwzględniane w pe_list dla pliku cloud.q i są zgodne z nazwą pe, na przykład pe_list [@allhosts=mpislots],[@hpc1=mpi].
2. Mieć odpowiednie zasoby i limit subskrypcji, aby zapewnić wszystkie zasoby zadań.
3. Konfiguracja ograniczeń grupy hostów nie filtruje ich.

Wiele grup hostów może spełniać te wymagania. W takim przypadku system musi zdecydować, który z nich ma być używany. Istnieją trzy sposoby rozwiązywania konfliktów członkostwa grupy hostów:

1. Skonfiguruj kolejki, żeby uniknąć niejednoznaczności.
2. Dodaj ograniczenia do autoscale.json.
3. Pozwól CycleCloud wybrać odpowiednie grupy hostów w kolejności alfabetycznej, dostosowując weight_queue_host_sort < weight_queue_seqno w konfiguracji harmonogramu.
4. Ustaw seq_no 10000,[@hostgroup1=100],[@hostgroup2=200] w konfiguracji kolejki, aby wskazać preferencję grupy hostów.

Ograniczenia grupy hostów

Gdy kolejka lub xproject definiuje wiele grup hostów, każda z tych grup może potencjalnie przyjmować nowe hosty. Aby kontrolować, które hosty kwalifikują się do kolejki, można zastosować ograniczenia grupy hostów 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 za pomocą azge buckets.

azge

Ten pakiet jest dostarczany z wierszem polecenia, azge. Ten program służy do automatycznego skalowania i przerywa wszystkie podprocesy w ramach autoskalowania na oddzielne składniki. 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.

Podczas modyfikowania konfiguracji harmonogramu (qconf) lub konfiguracji autoskalowania (autoscale.json), a nawet przy pierwszej konfiguracji, narzędzie azge może być używane do sprawdzania, czy zachowanie autoskalowania jest zgodne z oczekiwaniami. Jako użytkownik główny możesz uruchomić następujące operacje. Aby zrozumieć, jak działa autoskalowanie, ważne jest, aby zapoznać się z tymi pojęciami.

1. Uruchom polecenie azge validate , aby zweryfikować konfiguracje pod kątem znanych problemów.
2. Uruchom polecenie azge buckets , aby sprawdzić zasoby oferowane przez klaster CycleCloud.
3. Uruchom polecenie azge jobs, aby sprawdzić szczegóły zadania w kolejce.
4. Uruchom azge demand i wykonaj zadanie dopasowywania do zasobnika. Następnie zbadaj, które zadania są przypisane do konkretnych segmentów i grup hostów.
5. Uruchom polecenie azge autoscale , aby rozpocząć proces alokacji węzła lub dodaj węzły, które są gotowe do przyłączenia.

Gdy polecenia będą działać zgodnie z oczekiwaniami, włącz bieżące autoskalowanie, dodając polecenie azge autoscale do głównego pliku crontab. Upewnij się, że z wyprzedzeniem załadujesz zmienne środowiskowe GridEngine.

* * * * * . $SGE_ROOT/common/settings.sh && /usr/local/bin/azge autoscale -c /opt/cycle/gridengine/autoscale.json

Tworzenie klastra hybrydowego

Usługa CycleCloud obsługuje scenariusz cloud bursting. Konfiguracja podstawowa zakłada, że $SGE_ROOT katalog jest dostępny dla węzłów chmury. To założenie może być złagodzone przez ustawienie gridengine.shared.spool = false, gridengine.shared.bin = falsei zainstalowanie usługi GridEngine lokalnie.

Dla prostego przypadku należy zapewnić system plików, który węzły "execute" mogą zamontować. Ten system plików musi zawierać ... katalog, a montowanie skonfigurujesz w ustawieniach opcjonalnych. Po wydaniu zależności katalogów 'sched' oraz 'shared', można zamknąć węzeł harmonogramu, który domyślnie jest częścią klastra, i korzystać z konfiguracji znajdujących się w zewnętrznym systemie plików.

1. Utwórz nowy klaster Gridengine.
2. Wyłącz proxy zwrotny.
3. Zastąp /sched i /shared zewnętrznymi systemami plików.
4. Zapisz klaster.
5. Usuń węzeł harmonogramu jako akcję w interfejsie użytkownika.
6. Uruchom klaster. Początkowo nie uruchamia się żadnych węzłów.
7. Skonfiguruj cyclecloud-gridengine za pomocą autoscale.json w celu użycia nowego klastra

Korzystanie z Univa Grid Engine w usłudze CycleCloud

Projekt CycleCloud dla GridEngine domyślnie używa biblioteki sge-2011.11 . Możesz korzystać z 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 użyto wersji demonstracyjnej 8.6.1, ale obsługiwane są wszystkie wersje GE większe niż 8.4.0.

1. Użytkownicy muszą podać pliki binarne ugE

• ge-8.6.x-bin-lx-amd64.tar.gz
• ge-8.6.x-common.tar.gz

2. Należy skonfigurować interfejs wiersza polecenia CycleCloud. Dokumentacja jest dostępna tutaj

Skopiuj pliki binarne do przechowalni w chmurze

Uzupełniająca wersja AGE (8.6.7-demo) jest dystrybuowana z aplikacją CycleCloud. Aby użyć innej wersji, prześlij pliki binarne na konto magazynowania, które wykorzystuje 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 tak, aby używał instalatorów UGE zamiast domyślnego.

wget https://raw.githubusercontent.com/Azure/cyclecloud-gridengine/master/templates/gridengine.txt

W pliku gridengine.txt znajdź pierwsze wystąpienie [[[configuration]]] i wstaw tekst, aby dopasować go do poniższego fragmentu kodu. Plik nie jest wrażliwy na wcięcie.

[[[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 GridEngine zastępują domyślną wersję i lokalizację instalacji GridEngine po uruchomieniu klastra. Nie jest bezpieczne przeniesienie się z /sched, ponieważ jest to wspólna lokalizacja systemu plików NFS w klastrze.