Descrivere i modelli di cluster Azure CycleCloud
Azure CycleCloud consente la distribuzione basata su modelli di cluster HPC. Per impostazione predefinita, l'applicazione Azure CycleCloud include diversi modelli per la distribuzione delle utilità di pianificazione dei cluster più comuni, tra cui Slurm, PBSPro, LSF, Grid Engine e HT-Condor. I repository GitHub di Azure CycleCloud offrono molti progetti specifici delle utilità di pianificazione, che è possibile personalizzare e importare nell'istanza di Azure CycleCloud. È anche possibile implementare il provisioning basato su modelli per le utilità di pianificazione personalizzate sviluppate internamente usando i plug-in di scalabilità automatica di CycleCloud.
I modelli semplificano l'implementazione di un'ampia gamma di funzionalità di Azure CycleCloud, tra cui il supporto per immagini di macchine virtuali (VM) personalizzate, la scalabilità automatica e le VM spot. Riducono inoltre al minimo il sovraccarico associato al provisioning e alla gestione di più distribuzioni di cluster configurati in modo identico, comunemente usati per isolare gli ambienti di produzione, sviluppo e test.
Questi vantaggi sono allineati agli obiettivi dell'implementazione del nuovo cluster residente di Azure per Contoso. Per ottimizzare l'entità di questi vantaggi, si decide di ottenere altre informazioni sul formato e sul processo di implementazione dei modelli di Azure CycleCloud.
Qual è il formato dei modelli di Azure CycleCloud?
I modelli sono file in formato INI che usano la sintassi dichiarativa per descrivere la struttura e la configurazione di un cluster CycleCloud, tra cui i ruoli dei nodi del cluster e le rispettive relazioni. I modelli sono costituiti da sezioni denominate, con intestazioni designate da una o più coppie di parentesi quadre. Le sezioni formano una gerarchia, corrispondente alla gerarchia di oggetti del cluster e ai relativi parametri. Il numero di parentesi quadre rappresenta un livello all'interno della gerarchia e aumenta sequenzialmente con ogni livello.
[cluster]
[[node, nodearray]]
[[[volume]]]
[[[network-interface]]]
[[[cluster-init]]]
[[[input-endpoint]]]
[[[configuration]]]
[environment]
[noderef]
[parameters]
[[parameters]]
[[[parameter]]]
In realtà, la sezione [cluster]
può contenere una o più sezioni [[node]]
, che possono contenere più sezioni [[[volume]]]
. Analogamente, all'interno dello stesso modello, nella sezione [cluster]
è possibile definire una o più sezioni [[nodearray]]
, ognuna con il proprio elemento [[[configuration]]]
.
Nota
L'ordine delle sezioni all'interno dello stesso livello è arbitrario.
Quali sono le sezioni principali di un modello?
Un modello è costituito dalle sezioni principali seguenti:
- Cluster: La sezione
[cluster]
contiene una definizione di un oggetto cluster Azure CycleCloud. Un modello deve includere almeno una sezione[cluster]
, che contiene una o più sezioni[[node]]
e[[nodearray]]
che descrivono gli oggetti figlio del cluster. - Node (Nodo): Rappresenta una singola macchina virtuale con provisioning della piattaforma.
- Nodearray: Rappresenta uno o più set di scalabilità di macchine virtuali di Azure.
Nota
I cluster comprendono nodi che servono i ruoli designati nell'elaborazione dei carichi di lavoro in cluster. Dal punto di vista dell'implementazione, Azure CycleCloud si basa su Azure Resource Manager per effettuare il provisioning come singole macchine virtuali di Azure o come membri di un set di scalabilità di macchine virtuali. Quest'ultimo rappresenta una raccolta di macchine virtuali configurate in modo identico che, a differenza delle macchine virtuali di Azure, supporta la scalabilità automatica orizzontale. Azure CycleCloud usa i set di scalabilità di macchine virtuali per implementare gli oggetti nodearray. La sezione [[node]]
descrive le proprietà delle macchine virtuali sottostanti con provisioning della piattaforma, che possono consistere in macchine virtuali di Azure autonome oppure appartenere a un set di scalabilità di macchine virtuali di Azure. La sezione [[nodearray]]
descrive un set di scalabilità di macchine virtuali di Azure.
Nota
Un oggetto nodearray può essere costituito da più set di scalabilità di macchine virtuali di Azure, ognuno dei quali comprende macchine virtuali configurate in modo diverso. Tutti i nodi in un oggetto nodearray svolgono tuttavia lo stesso ruolo nel cluster, ad esempio fornire risorse a una singola coda dell'utilità di pianificazione del cluster.
- Il volume definisce un disco gestito di Azure che deve essere collegato a singoli nodi del cluster o a nodi che formano un oggetto nodearray. È un oggetto figlio di un nodo o di un oggetto nodearray.
- L'interfaccia di rete definisce un'interfaccia di rete di Azure che deve essere collegata a singoli nodi del cluster o a nodi che formano un oggetto nodearray. È un oggetto figlio di un nodo o di un oggetto nodearray.
- La configurazione definisce le proprietà configurabili di un nodo o un oggetto nodearray. È un oggetto figlio di un nodo o di un oggetto nodearray.
- Cluster-init definisce le specifiche del progetto Azure CycleCloud da applicare a un nodo del cluster. Un progetto è una raccolta di risorse che definisce le configurazioni dei nodi sotto forma di specifiche del progetto. All'avvio, un nodo viene configurato automaticamente elaborando queste specifiche. Cluster-init è un oggetto figlio di un nodo o di un oggetto nodearray.
- L'ambiente definisce una distribuzione di Azure Resource Manager che effettua il provisioning delle risorse di Azure che verranno usate dal cluster o modifica tali risorse. Si tratta di un oggetto di primo livello facoltativo.
- Noderef fa riferimento a un nodo all'interno del modello per esprimere le dipendenze delle risorse. Si tratta di un oggetto di primo livello facoltativo.
- I parametri consentono di rendere portabile un modello, così che sia possibile usarlo per la distribuzione di più cluster con gerarchia di oggetti corrispondente ma impostazioni di configurazione diverse. Si tratta di un oggetto di primo livello facoltativo, ma è possibile scegliere di creare una gerarchia di parametri annidati. Per ogni parametro è possibile definirne il valore predefinito. I parametri consentono anche di esporre variabili configurabili in un cluster tramite l'interfaccia Web di CycleCloud.
Ogni sezione contiene diverse coppie chiave-valore che forniscono i dettagli di configurazione dell'oggetto corrispondente, rappresentato dall'intestazione di sezione. Ad esempio, simili dettagli per un oggetto nodearray possono includere la chiave ImageName
con il valore che designa l'immagine della macchina virtuale di Azure da usare per i relativi nodi o la chiave Azure.MaxScalesetSize
che specifica la dimensione massima consentita del set di scalabilità di macchine virtuali come valore. Analogamente, le sezioni node o nodearray possono includere una o più sezioni [[[configuration]]]
.
Come si effettua il provisioning di un cluster in base a un modello?
Dopo avere identificato il modello da usare per effettuare il provisioning di un cluster Azure CycleCloud, è possibile applicare uno dei metodi di implementazione seguenti:
- Usare l'interfaccia della riga di comando di Azure CycleCloud per importare il modello nell'applicazione Azure CycleCloud, quindi usare l'interfaccia grafica dell'applicazione per effettuare il provisioning del cluster. Per attivare l'importazione, eseguire il comando
cyclecloud import_template -f <template_file>
(dove il segnaposto<template_file>
rappresenta il nome del file contenente il modello). Se il modello contiene più definizioni di cluster, specificare il nome del cluster da importare facendo riferimento a esso come valore del parametro-c
. - Usare l'interfaccia della riga di comando di Azure CycleCloud per importare il modello nell'applicazione Azure CycleCloud, quindi per effettuare il provisioning del cluster. Per attivare l'importazione, eseguire il comando
cyclecloud import_template -t -f <template_file>
(dove il segnaposto<template_file>
rappresenta il nome del file contenente il modello). Al termine dell'importazione, eseguire il comandocyclecloud create_cluster
. Per creare, ad esempio, un cluster denominatolab-cluster
da un modello importato denominatolab-template
, eseguirecyclecloud create_cluster lab-template lab-cluster
. - Usare l'interfaccia della riga di comando di Azure CycleCloud per effettuare il provisioning del cluster senza importare in modo esplicito il modello. Per attivare l'importazione, eseguire il comando
cyclecloud import_cluster
.
Indipendentemente dal metodo scelto, è necessario specificare i valori di tutti i parametri richiesti durante il provisioning del cluster. Quando si usa l'interfaccia della riga di comando di Azure CycleCloud, è possibile fornire i valori facendo riferimento a un file di parametri in formato JSON.
Nota
Il file è costituito da coppie chiave-valore, in cui la chiave rappresenta il nome del parametro. Per verificare il formato per un cluster esistente, usare il comando cyclecloud export_parameters <cluster_name> > params.json
, dove il segnaposto <cluster_name>
rappresenta il nome del cluster esistente.
Nota
Prima di distribuire un cluster basato su un modello importato, è anche necessario caricare il contenuto del progetto corrispondente in un locker Azure CycleCloud. Per eseguire un caricamento, usare il comando cyclecloud project upload <locker_name>
dell'interfaccia della riga di comando di Azure CycleCloud (dove il segnaposto <locker_name>
rappresenta il nome del locker). Per elencare i locker disponibili, eseguire il comando cyclecloud locker list
dell'interfaccia della riga di comando di Azure CycleCloud. Nella sezione[[[cluster-init]]]
viene fatto riferimento al nome del locker.
Nota
Uno dei passaggi per la configurazione di un'installazione di Azure CycleCloud consiste nella creazione di un contenitore BLOB in un account di archiviazione di Azure. Questo contenitore funge da locker usato dal server CycleCloud per lo staging dei progetti CycleCloud per i nodi del cluster. Successivamente, i nodi dei cluster gestiti da Azure CycleCloud vengono configurati per scaricare i progetti CycleCloud da questo locker come parte del processo di avvio.