Modelli di cluster

Articolo
06/21/2023

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.

Notazione della configurazione

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

Parametri del modello di cluster

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

Tipi di computer

Azure CycleCloud supporta più tipi di computer tramite l'attributo MachineType . Tenterà di acquisire capacità nell'ordine elencato.

Specifiche init del cluster

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.

Spot Macchine virtuali

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

Tabelle di ricerca

È 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]}

Integrazione dell'interfaccia utente grafica

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.

Supporto del server Chef

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.

Immagini utente personalizzate nei modelli

Azure CycleCloud supporta immagini personalizzate nei modelli. Specificare l'ID immagine (ID risorsa) direttamente con ImageIdo 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).