CycleCloud GridEngine Cluster

Questa pagina riguarda funzionalità e configurazione dell'uso di GridEngine (Altair) con CycleCloud.

Configurazione delle risorse

L'applicazione cyclecloud-gridengine corrisponde alle risorse di sge alle risorse cloud di Azure per offrire strumenti di scalabilità automatica e configurazione del cluster avanzati. L'applicazione verrà distribuita automaticamente per i cluster creati tramite l'interfaccia utente CycleCloud oppure può essere installata in qualsiasi host amministratore gridengine in un cluster esistente.

Installazione o aggiornamento di cyclecloud-gridengine

Il bundle cyclecloud-gridengine è disponibile in github come artefatto di versione. L'installazione e l'aggiornamento saranno lo stesso processo. L'applicazione richiede Python3 con virtualenv.

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

File importanti

L'applicazione analizza la configurazione di sge ogni volta che viene chiamata : processi, code, complessi. Le informazioni vengono fornite nello stderr e stdout del comando e in un file di log, entrambi a livelli configurabili. Tutti i comandi di gestione gridengine con argomenti vengono registrati anche nel file.

Descrizione	Location
Configurazione della scalabilità automatica	/opt/cycle/gridengine/autoscale.json
Log di scalabilità automatica	/opt/cycle/jetpack/logs/autoscale.log
log di traccia qconf	/opt/cycle/jetpack/logs/qcmd.log

Code SGE, hostgroup e ambienti paralleli

L'utilità di scalabilità automatica cyclecloud-gridengine, azgeaggiungerà host al cluster in base alla configurazione del cluster. Le operazioni di scalabilità automatica eseguono le azioni seguenti.

1. Leggere la richiesta di risorsa del processo e trovare una macchina virtuale appropriata per avviare
2. Avviare la macchina virtuale e attendere che sia pronto
3. Leggere la coda e l'ambiente parallelo dal processo
4. In base alla coda/pe assegnare l'host a un hostgroup appropriato
5. Aggiungere l'host al cluster e a qualsiasi altra coda contenente il gruppo host

Prendere in considerazione la definizione della coda seguente per una coda denominata short.q

hostlist              @allhosts @mpihg01 @mpihg02 @lowprio 
...
seq_no                10000,[@lowprio=10],[@mpihg01=100],[@mpihg02=200]
pe_list               NONE,[@mpihg01=mpi01], \
                      [@mpihg02=mpi02]

L'invio di un processo qsub -q short.q -pe mpi02 12 my-script.sh avvierà al lease di una macchina virtuale e, quando viene aggiunto al cluster, verrà aggiunto al gruppo host @mpihg02 perché è il gruppo host sia disponibile per la coda che per l'ambiente parallelo. Verrà aggiunto anche a @allhosts, ovvero un hostgroup speciale.

Senza specificare un pe, qsub -q short.q my-script.sh la macchina virtuale risultante verrà aggiunta a @allhosts e @lowpriority questi sono i gruppi host nella coda che non sono assegnati pes.

Infine, un processo inviato con qsub -q short.q -pe mpi0* 12 my-script.sh genera una macchina virtuale aggiunta a @mpihg01 o @mpihg02 a seconda delle stime di allocazione CycleCloud.

Gli ambienti paralleli equivalgono in modo implicito al gruppo di posizionamento cyclecloud. Le macchine virtuali in un PE sono vincolate all'interno della stessa rete. Se si vuole usare un PE che non mantiene un gruppo di posizionamento, usare autoscale.json per rifiutare l'annullamento.

Qui si opta per i gruppi di posizionamento per il make pe:

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

Gruppi di posizionamento CycleCloud

I gruppi di posizionamento di CycleCloud mappano uno a uno a una macchina virtuale di Azure con SinglePlacementGroup - Macchine virtuali in un gruppo di posizionamento condividono un'infrastruttura Infiniband e condividono solo le macchine virtuali all'interno del gruppo di posizionamento. Per mantenere in modo intuitivo questi silos, i placementgroup mappano anche 1:1 con ambiente parallelo gridengine.

La specifica di un ambiente parallelo per un processo limita l'esecuzione del processo in un gruppo di posizionamento tramite la logica di assegnazione del gruppo host intelligente. È possibile rifiutare esplicitamente questo comportamento con la configurazione precedente in autoscale.json : "required_placement_groups" : false.

Configurazione della scalabilità automatica

Questo plug-in ridimensiona automaticamente la griglia per soddisfare le esigenze del carico di lavoro. Il file di configurazione autoscale.json determina il comportamento della scalabilità automatica del motore di griglia.

• Impostare i dettagli della connessione cyclecloud
• Impostare il timer di terminazione per i nodi inattive
• La scalabilità automatica multidimensionale è possibile, impostare quali attributi usare nel processo di imballaggio, ad esempio slot, memoria
• Registrare le code, gli ambienti paralleli e i gruppi host da gestire

Configurazione	Tipo	Descrizione
url	string	CC URL
nome utente/password	string	Dettagli connessione CC
cluster_name	string	Nome del cluster CC
default_resources	Mappa	Collegare una risorsa nodo a una risorsa host del motore di griglia per la scalabilità automatica
idle_timeout	Int	Tempo di attesa prima di terminare i nodi inattive (s)
boot_timeout	Int	Tempo di attesa prima di terminare i nodi durante le fasi di configurazione lunghe (s)
gridengine.relevant_complexes	Elenco (stringa)	Complessi del motore di griglia da considerare nella scalabilità automatica, ad esempio gli slot, mem_free
gridengine.logging	File	Percorso del file di configurazione della registrazione
gridengine.pes	Struct	Specificare il comportamento di PES, ad esempio requires_placement_group = false

Il programma di scalabilità automatica considererà solo la risorsa pertinente

Risorsa di scalabilità automatica aggiuntiva

Per impostazione predefinita, il cluster con scalabilità in base al numero di slot richiesti dai processi. È possibile aggiungere un'altra dimensione alla scalabilità automatica.

Si supponga di voler ridimensionare automaticamente la richiesta di risorsa del processo per m_mem_free.

1. Aggiungere m_mem_free all'oggetto gridengine.relevant_resources in autoscale.json
2. Collegamento m_mem_free alla risorsa di memoria a livello di nodo in autoscale.json

Questi attributi possono essere riferimenti con node.* come valore in _default/risorse.

Nodo	Tipo	Descrizione
nodearray	string	Nome del nodo cyclecloudarray
placement_group	string	Nome del gruppo di posizionamento cyclecloud all'interno di un nodearray
vm_size	string	Nome prodotto macchina virtuale, ad esempio "Standard_F2s_v2"
vcpu_count	Int	CPU virtuali disponibili nel nodo come indicato nelle singole pagine del prodotto
pcpu_count	Int	CPU fisiche disponibili nel nodo
memoria	string	Memoria fisica approssimativa disponibile nella macchina virtuale con indicatore unità, ad esempio "8,0g"

Gli attributi aggiuntivi si trovano nello node.resources.* spazio dei nomi, ad esempio 'node.resources.

Nodo	Tipo	Descrizione
ncpus	string	Numero di CPU disponibili nella macchina virtuale
pcpus	string	Numero di CPU fisiche disponibili nella macchina virtuale
ngpus	Integer	Numero di GPU disponibili nella macchina virtuale
memb	string	Memoria fisica approssimativa disponibile nella macchina virtuale con indicatore unità, ad esempio "8.0b"
memkb	string	Memoria fisica approssimativa disponibile nella macchina virtuale con indicatore unità, ad esempio "8,0k"
memmb	string	Memoria fisica approssimativa disponibile nella macchina virtuale con indicatore unità, ad esempio "8,0m"
memgb	string	Memoria fisica approssimativa disponibile nella macchina virtuale con indicatore unità, ad esempio "8,0g"
memtb	string	Memoria fisica approssimativa disponibile nella macchina virtuale con indicatore unità, ad esempio "8.0t"
slot	Integer	Uguale a ncpus
slot_type	string	Etichetta di aggiunta per le estensioni. Non in genere usato.
m_mem_free	string	Memoria libera prevista nell'host di esecuzione, ad esempio "3.0g"
mfree	string	Uguale a _m/_mem/gratuito

Mapping delle risorse

Esistono anche matematicamente disponibili per la default_resources: ridurre gli slot in una determinata matrice di nodi per due e aggiungere la risorsa docker a tutti i nodi:

    "default_resources": [
    {
      "select": {"node.nodearray": "beegfs"},
      "name": "slots",
      "value": "node.vcpu_count",
      "subtract": 2
    },
    {
      "select": {},
      "name": "docker",
      "value": true
    },

Eseguire il mapping delle vCPU del nodo al complesso degli slot e memmb di mem_free usare comunemente le impostazioni predefinite. È necessaria la prima associazione.

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

Si noti che se un complesso ha un collegamento non uguale all'intero valore, definire entrambi in default_resources dove physical_cpu è il nome complesso:

"default_resources": [
    {
      "select": {},
      "name": "physical_cpu",
      "value": "node.pcpu_count"
    },
    {
      "select": {},
      "name": "pcpu",
      "value": "node.resources.physical_cpu"
    }
]

L'ordinamento è importante quando si vuole un comportamento specifico per un attributo specifico. Per allocare un singolo slot per un nodo specifico, mantenendo il numero di slot predefinito per tutti gli altri nodiarray:

    "default_resources": [
    {
      "select": {"node.nodearray": "FPGA"},
      "name": "slots",
      "value": "1",
    },
    {
      "select": {},
      "name": "slots",
      "value": "node.vcpu_count"
    },
]

Hostgroup

Il ridimensionatore automatico CycleCloud, nel tentativo di soddisfare i requisiti del processo, eseguirà il mapping dei nodi al gruppo host appropriato. Le code, gli ambienti paralleli e i complessi sono tutti considerati. Gran parte della logica corrisponde al bucket cyclecloud appropriato (e alla quantità di nodi) con il gruppo host di sge appropriato.

Per un processo inviato come: qsub -q "cloud.q" -l "m_mem_free=4g" -pe "mpi*" 48 ./myjob.sh

CycleCloud troverà l'intersezione dei gruppi host che:

1. Sono inclusi nella pe_list per cloud.q e corrispondono al nome pe, ad esempio pe_list [@allhosts=mpislots],[@hpc1=mpi].
2. Disporre di risorse adeguate e quota di sottoscrizione per fornire tutte le risorse del processo.
3. Non vengono filtrati dalla configurazione dei vincoli del gruppo host.

È possibile che più hostgroup soddisfino questi requisiti, in tal caso la logica dovrà scegliere. Esistono tre modi per risolvere le ambiguità nell'appartenenza al gruppo host:

1. Configurare le code in modo che non siano presenti ambiguità.
2. Aggiungere vincoli a autoscale.json.
3. Consente a CycleCloud di scegliere amoungst i gruppi host corrispondenti in modo ordinato dal nome modificando weight_queue_host_sort < weight_queue_seqno nella configurazione dell'utilità di pianificazione.
4. Impostare seq_no 10000,[@hostgroup1=100],[@hostgroup2=200] nella configurazione della coda per indicare una preferenza del gruppo host.

Vincoli del gruppo host

Quando più hostgroup sono definiti da una coda o da un xproject, tutti questi hostgroup possono potenzialmente avere gli host aggiunti a loro. È possibile limitare i tipi di host a cui è possibile aggiungere code impostando vincoli del gruppo host. Impostare un vincolo in base alle proprietà del nodo.

"gridengine": {
    "hostgroups": {
      "@mpi": {
        "constraints": {
          "node.vm_size": "Standard_H44rs"
        }
      },
      "@amd-mem": {
        "constraints" : { 
            "node.vm_size": "Standard_D2_v3",
            "node.nodearray": "hpc" 
            }
        },
    }
  }

HINT: controllare tutte le proprietà del nodo disponibili in azge bucketsbase a .

azge

Questo pacchetto include una riga di comando, azge. Questo programma deve essere usato per eseguire la scalabilità automatica e ha interrotto tutti i sottoprocessi in scalabilità automatica. Questi comandi si basano sulle variabili di ambiente gridengine da impostare: è necessario essere in grado di chiamare qconf e qsub dallo stesso profilo in cui azge viene chiamato.

comandi azge	Descrizione
validate	Verifica gli errori di configurazione noti nel scalabilità automatica o nel gridengine
jobs	Mostra tutti i processi nella coda
bucket	Mostra i pool di risorse disponibili per la scalabilità automatica
nodes	Mostra gli host e le proprietà del cluster
demand	Corrisponde ai requisiti del processo ai bucket cyclecloud e fornisce risultati di scalabilità automatica
scalabilità automatica	Esegue la scalabilità automatica completa, l'avvio e la rimozione dei nodi in base alle configurazioni

Quando si modificano le configurazioni dell'utilità di pianificazione (qconf) o le configurazioni di scalabilità automatica (autoscale.json) o anche la configurazione per la prima volta, azge può essere usato per verificare che il comportamento della scalabilità automatica corrisponda alle aspettative. Come radice, è possibile eseguire le operazioni seguenti. È consigliabile acquisire familiarità con queste funzionalità per comprendere il comportamento di scalabilità automatica.

1. Eseguire azge validate per verificare le configurazioni per i problemi noti.
2. Eseguire azge buckets per esaminare le risorse offerte dal cluster CycleCloud.
3. Eseguire azge jobs per esaminare i dettagli del processo in coda.
4. Eseguire azge demand il processo per eseguire la corrispondenza tra bucket, esaminare quali processi vengono confrontati con i bucket e i gruppi host.
5. Eseguire azge autoscale per avviare il processo di allocazione dei nodi o aggiungere nodi pronti per l'aggiunta.

Quindi, quando questi comandi si comportano come previsto, abilitare la scalabilità automatica in corso aggiungendo il azge autoscale comando alla radice crontab. (Souce le variabili di ambiente gridengine)

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

Creazione di un cluster ibrido

CycleCloud supporterà lo scenario di bursting nel cloud. La configurazione di base presuppone che la $SGE_ROOT directory sia disponibile per i nodi cloud. Questo presupposto può essere rilassato impostando gridengine.shared.spool = falsegridengine.shared.bin = false e installando GridEngine in locale. Per un caso semplice, è necessario fornire un file system che può essere montato dai nodi di esecuzione che contiene la $SGE_ROOT directory e configurare tale montaggio nelle impostazioni facoltative. Quando viene rilasciata la dipendenza delle directory condivise e degli sched, è possibile arrestare il nodo dell'utilità di pianificazione che fa parte del cluster per impostazione predefinita e usare le configurazioni del file system esterno.

1. Creare un nuovo cluster gridengine.
2. Disabilitare il proxy restituito.
3. Sostituire /sched e /shared con file system esterni.
4. Salvare il cluster.
5. Rimuovere il nodo dell'utilità di pianificazione come azione nell'interfaccia utente.
6. Avviare il cluster, non verrà avviato inizialmente alcun nodo.
7. Configurare cyclecloud-gridengine con autoscale.json per l'uso del nuovo cluster

Uso del motore di griglia Univa in CycleCloud

Il progetto CycleCloud per GridEngine usa sge-2011.11 per impostazione predefinita. È possibile usare i propri programmi di installazione di Altair GridEngine in base al contratto di licenza altair.
Questa sezione illustra come usare Altair GridEngine con il progetto CycleCloud GridEngine.

Prerequisiti

Questo esempio userà la versione demo 8.6.1, ma tutte le versioni > ge 8.4.0 sono supportate.

1. Gli utenti devono fornire file binari UGE

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

2. È necessario configurare l'interfaccia della riga di comando di CycleCloud. La documentazione è disponibile qui

Copiare i file binari nel cloud locker

Una versione complementare di AGE (8.6.7-demo) viene distribuita con CycleCloud. Per usare un'altra versione, caricare i file binari nell'account di archiviazione usato da 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/

Modifica delle configurazioni nel modello di cluster

Creare una copia locale del modello gridengine e modificarla in modo da usare i programmi di installazione UGE anziché il valore predefinito.

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

Nel file gridengine.txt individuare la prima occorrenza di [[[configuration]]] e inserire testo in modo che corrisponda al frammento di codice seguente. Questo file non è sensibile al rientro.

NOTA: i dettagli nella configurazione, in particolare la versione, devono corrispondere al nome del file del programma di installazione.

[[[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"

Queste configurazioni eseguiranno l'override della versione predefinita di gridengine e del percorso di installazione all'avvio del cluster. Non è possibile spostarsi all'esterno /sched di perché si tratta di una posizione nfs specificatamente condivisa nel cluster.