Modelli di cluster
Azure CycleCloud usa i modelli per definire le configurazioni del cluster. Per impostazione predefinita, in CycleCloud sono inclusi diversi modelli e in GitHub è disponibile un elenco completo dei modelli supportati. È possibile creare nuovi modelli oppure personalizzare quelli esistenti. Ad esempio, è possibile personalizzare un modello esistente per sfruttare i vantaggi delle macchine virtuali spot oppure aggiungere un VPC per estendere la propria rete.
I modelli di cluster Azure CycleCloud hanno tutte la possibilità di avere una o più sezioni [[[configurazione]]] che appartengono a un nodo o a un nodearray. Queste sezioni specificano le opzioni di configurazione software relative ai nodi avviati da CycleCloud. La notazione punteggiata viene usata per specificare gli attributi da configurare:
[[node scheduler]]
[[[configuration]]]
cycle_server.admin.name = poweruser
cycle_server.admin.pass = super_secret
cycle_server.http_port = 8080
cycle_server.https_port = 8443
È anche possibile specificare una sezione di configurazione usando prefix
la notazione per salvare la digitazione.
La stessa configurazione può essere scritta anche come segue:
[[node scheduler]]
[[[configuration cycle_server]]]
admin.name = poweruser
admin.pass = super_secret
http_port = 8080
https_port = 8443
Un node/nodearray può contenere anche più sezioni di configurazione, se necessario:
[[node scheduler]]
[[[configuration]]]
run_list = role[sge_scheduler_node]
[[[configuration cycle_server.admin]]]
name = poweruser
pass = super_secret
I modelli di cluster possono contenere parametri che modificano i valori di determinate parti di un cluster senza dover modificare il modello stesso. Ciò è particolarmente utile nei casi in cui si desiderano molti cluster simili con differenze minori, ad esempio la distribuzione di ambienti di sviluppo e produzione. La sintassi per specificare un parametro all'interno di un modello di cluster consiste nel anteporre un prefisso a una variabile con '$'. Un esempio di modello di base (non funzionale) con alcuni parametri potrebbe essere simile al seguente:
# template.txt
[cluster gridengine]
[[node scheduler]]
MachineType = $machine_type
[[[configuration]]]
gridengine.slots = $slots
Questo modello definisce due parametri: $machine_type
e $slots
. Usando questo modello, è possibile definire file di testo contenenti i valori dei parametri negli ambienti di sviluppo e produzione. Il file dei parametri può essere in formato JSON o in un formato di file di proprietà Java:
# dev-params.json
{
"machine_type": "H16r",
"slots": 2
}
# prod-params.properties
machine_type = Standard_D4v3
slots = 8
Verrà creato un file JSON contenente i parametri per lo sviluppo e un file con estensione properties contenente i valori per l'ambiente di produzione.
Nota
Il suffisso del nome file per il file dei parametri è importante. Se si usa JSON, il file deve essere denominato foo.json
. Se si usano proprietà Java, il file deve terminare con .properties
. I file di parametri denominati in modo non corretto non verranno importati correttamente.
È ora possibile importare il modello usando il file dei parametri per compilare le parti mancanti:
cyclecloud import_cluster gridengine-dev -f template.txt -p dev-params.json -c gridengine
cyclecloud import_cluster gridengine-prod -f template.txt -p prod-params.properties -c gridengine
È anche possibile definire alcuni o tutti i parametri all'interno del modello di cluster stesso:
# template.txt
[cluster gridengine]
[[node scheduler]]
MachineType = $machine_type
[[[configuration]]]
gridengine.slots = $slots
[parameters]
[[parameter machine_type]]
DefaultValue = Standard_D4v3
[[parameter slots]]
DefaultValue = 2
I valori predefiniti per ogni parametro vengono definiti all'interno del modello (i valori "dev" sono stati usati come valori predefiniti).
È ora possibile importare il modello senza un file di parametri e i valori "dev" verranno usati automaticamente. Quando è il momento di creare un cluster "prod", è possibile usare il file prod-params.properties per sovrascrivere i valori specificati all'interno del file modello stesso.
Nota
I nomi dei parametri possono includere lettere, numeri e caratteri di sottolineatura.
I riferimenti ai parametri nel modello possono assumere una delle due forme seguenti:
$param
: usa il valore di un singolo parametro denominato param
${expr}
: valuta expr
nel contesto di tutti i parametri, che consente di calcolare valori dinamici. Ad esempio:
Attribute = ${(a > b ? a : b) * 100}
In questo modo verranno accettati due parametri a
, e b
, e moltiplicarlo per 100.
L'espressione viene interpretata e valutata in base alla specifica del linguaggio ClassAd.
Se un riferimento a un parametro esiste da solo, viene usato il valore del parametro , che supporta tipi non stringa come booleani, numeri interi e strutture annidate, ad esempio elenchi.
Tuttavia, se il riferimento è incorporato in altro testo, il relativo valore viene convertito e incluso in una stringa.
Si supponga, ad esempio, di param
essere definito come 456
e a cui si fa riferimento in due posizioni:
- Attribute1 = $param
- Attribute2 = 123$param
Il valore di Attribute1
sarebbe il numero 456
, ma il valore di Attribute2
sarebbe la stringa "123456"
. Si noti che ${param}
è identico a $param
, che consente di incorporare riferimenti ai parametri in situazioni più complesse:
- Attribute3 = 123$param789
- Attribute4 = 123${param}789
Attribute3
cercherebbe il parametro denominato param789
, ma Attribute4 utilizzerebbe il valore di param
per ottenere "123456789"
.
Azure CycleCloud supporta più tipi di computer tramite l'attributo MachineType
. Tenterà di acquisire capacità nell'ordine elencato.
L'applicazione Web Azure CycleCloud consente agli utenti di selezionare le specifiche di progetto cluster-init durante la creazione di un nuovo cluster. Le specifiche di progetto vengono configurate all'interno del modello di cluster:
[parameter ClusterInitSpecs]
Label = Cluster-Init
Description = Cluster init specs to apply to nodes
ParameterType = Cloud.ClusterInitSpecs
[cluster demo]
[[node defaults]]
AdditionalClusterInitSpecs = $ClusterInitSpecs
[[[cluster-init myproject:myspec:1.0.0]]]
Dopo aver aggiunto questo parametro al modello di cluster, l'utente può usare la selezione file per selezionare le specifiche di progetto appropriate durante la creazione di un nuovo cluster.
Per ridurre il costo dei carichi di lavoro, è possibile impostare Interruptible = true
. L'istanza verrà contrassegnata come Spot e userà la capacità in eccesso quando disponibile. È importante notare che queste istanze non sono sempre disponibili e possono essere annullate in qualsiasi momento, ovvero non sono sempre appropriate per il carico di lavoro.
Per impostazione predefinita, l'impostazione su Interruptible
true userà istanze spot con un prezzo massimo impostato su -1. Ciò significa che l'istanza non verrà eliminata in base al prezzo. Il prezzo per l'istanza sarà il prezzo corrente per Spot o il prezzo per un'istanza standard, a condizione che sia minore, purché sia disponibile capacità e quota. Se si vuole impostare un prezzo massimo personalizzato, usare l'attributo MaxPrice
nel nodo o nodearray desiderato.
[cluster demo]
[[nodearray execute]]
Interruptible = true
MaxPrice = 0.2
È possibile avere un parametro che fa riferimento a un altro e calcolare un determinato valore con una tabella di ricerca. Si supponga, ad esempio, di avere un parametro da usare per l'immagine, con due opzioni in questo caso:
[[parameter MachineImage]]
Label = Image
DefaultValue = image-1000
Description = Ubuntu 22.04
Config.Plugin = pico.control.AutoCompleteDropdown
[[[list Config.Entries]]]
Name = image-1000
Label = Ubuntu 20.04
[[[list Config.Entries]]]
Name = image-2000
Label = Ubuntu 22.04
È anche possibile ottenere la versione del sistema operativo dell'immagine scelta e usarla per altre configurazioni rendendo e un parametro il cui valore è una tabella di ricerca di valori:
[[parameter AmiLookup]]
ParameterType = hidden
[[[record DefaultValue]]]
image-1000 = Ubuntu 20.04
image-2000 = Ubuntu 22.04
Si noti che questa operazione è nascosta, in modo che non venga visualizzata nell'interfaccia utente.
È possibile ottenere la versione del sistema operativo usata per l'immagine scelta altrove nella definizione del cluster:
[[node node]]
[[[configuration]]]
version = ${AmiLookup[MachineImage]}
La definizione dei parametri all'interno del modello di cluster consente di sfruttare i vantaggi dell'interfaccia utente grafica di Azure CycleCloud. Ad esempio, quando si definiscono i parametri è possibile usare gli attributi seguenti per facilitare la creazione dell'interfaccia utente grafica:
# template.txt
[cluster gridengine]
[[node scheduler]]
MachineType = $machine_type
[[[configuration]]]
gridengine.slots = $slots
[parameters]
[[parameter machine_type]]
DefaultValue = Standard_D4v3
Label = Machine Type
Description = MachineType to use for the Grid Engine scheduler node
ParameterType = Cloud.MachineType
[[parameter slots]]
DefaultValue = 2
Description = The number of slots for Grid Engine to report for the node
Gli attributi "Label" e "Description" sono inclusi che verranno visualizzati nell'interfaccia utente grafica e nell'attributo facoltativo "ParameterType". "ParameterType" consente di visualizzare gli elementi dell'interfaccia utente personalizzati. Nell'esempio precedente il valore "Cloud.MachineType" visualizzerà un elenco a discesa contenente tutti i tipi di computer disponibili. Gli altri valori ParameterType sono:
Tipo di parametro | Descrizione |
---|---|
Cloud.MachineType | Visualizza un elenco a discesa contenente tutti i tipi di computer disponibili. |
Cloud.Credentials | Visualizza un elenco a discesa contenente tutte le credenziali disponibili. |
Cloud.Region | Visualizza un elenco a discesa contenente tutte le aree disponibili. |
Azure CycleCloud porta ChefServer.
Creare il file chefserver.json
e aggiungere le credenziali.
ValidationKey
corrisponde al file validation.pem per il server Chef. È inoltre necessario dimostrare se validation_client_name
è stato modificato dal valore predefinito "chef-validator":
{
"AdType" : "Cloud.Locker",
"ValidationKey" : "YOURVALIDATION.PEMHERE",
"ValidationClientName" : "chef-validator",
"Credentials" : "default",
"Location" : "https://mychefserver",
"ChefRepoType" : "chefserver",
"LockerType" : "chefrepo",
"Name" : "chefrepo",
"AccountId" : "default",
"Shared" : false
}
Inserire quindi il file nella directory /opt/cycle_server/config/data
. Verrà importato automaticamente.
Azure CycleCloud supporta immagini personalizzate nei modelli. Specificare l'ID immagine (ID risorsa) direttamente con ImageId
o aggiungere l'immagine al Registro di sistema delle immagini. Quando l'immagine si trova nel Registro di sistema, farvi riferimento con Image
o ImageName
nel nodo. Verrà visualizzato nell'elenco a discesa dell'immagine nella pagina di creazione del cluster.
Le immagini nel registro immagini sono costituite da un Package
record che identifica il contenuto dell'immagine logica e uno o più record corrispondenti Artifact
che specificano l'ID immagine effettivo nel provider di servizi cloud appropriato. Ad esempio, un'immagine personalizzata in cui è installato R potrebbe essere costituita da questo record del pacchetto:
AdType = "Package"
Name = "r_execute"
Version = "2.1.1"
PackageType = "image"
Label = "R"
Dopo aver aggiunto tale record, è possibile specificare l'immagine includendo Image = R
o ImageName = r_execute
nel modello di cluster.
Se questa immagine esiste come singola macchina virtuale in useast con un ID di /subscriptions/xxxxxxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/MyResourceGroup/providers/Microsoft.Compute/images/MyCustomImage
, è necessario archiviare l'artefatto seguente:
AdType = "Artifact"
Package = "r_execute"
Version = "2.1.1"
Name = "az/useast"
Provider = "az"
ImageId = "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/MyResourceGroup/providers/Microsoft.Compute/images/MyCustomImage"
È necessario specificare Provider
sull'artefatto.
È possibile aggiungere tutti gli artefatti desiderati per un determinato pacchetto di immagini, ma è necessario includere tutti gli artefatti necessari per usare tale immagine in tutte le "posizioni" desiderate (una per ogni account del provider di servizi cloud, aree, progetti e così via). Il nome dell'artefatto non è importante, ad eccezione del fatto che deve essere univoco per tutti gli artefatti per un determinato pacchetto e versione. In genere è consigliabile usare una combinazione di provider e dettagli specifici del provider (ad esempio l'area). CycleCloud seleziona automaticamente l'artefatto corretto in modo che corrisponda al provider e a tutti i dettagli specifici del provider, ma usa l'attributo Provider (e Region e così via) anziché analizzare il Nome.
Se si aggiungono più pacchetti di immagini con lo stesso nome, devono avere numeri di versione diversi. Quando si avvia un'istanza, CycleCloud selezionerà automaticamente l'immagine con il numero di versione più alto, considerando il numero di versione come stringa punteggiata e confrontando ogni parte come numero. Per eseguire l'override di questo, specificare ImageVersion
nel nodo come valore letterale (ad esempio 1.2
) o un carattere jolly (1.x
).