Modèles de cluster

Article
06/21/2023

Azure CycleCloud utilise des modèles pour définir des configurations de cluster. Un certain nombre de modèles sont inclus dans CycleCloud par défaut et une liste complète des modèles pris en charge est disponible dans GitHub. Vous pouvez créer de nouveaux modèles ou personnaliser des modèles existants. Par exemple, vous pouvez personnaliser un modèle existant pour tirer parti des machines virtuelles Spot ou ajouter un VPC pour étendre votre propre réseau.

Configuration Notation

Les modèles de cluster Azure CycleCloud ont toutes la possibilité d’avoir une ou plusieurs sections [[[configuration]]] qui appartiennent à un nœud ou à un nœud. Ces sections spécifient des options de configuration logicielle sur les nœuds démarrés par CycleCloud. La notation en pointillés est utilisée pour spécifier les attributs que vous souhaitez configurer :

[[node scheduler]]
  [[[configuration]]]
  cycle_server.admin.name = poweruser
  cycle_server.admin.pass = super_secret
  cycle_server.http_port = 8080
  cycle_server.https_port = 8443

Vous pouvez également spécifier une section de configuration à l’aide prefix de la notation pour enregistrer la saisie. La même configuration peut également être écrite comme suit :

[[node scheduler]]
  [[[configuration cycle_server]]]
  admin.name = poweruser
  admin.pass = super_secret
  http_port = 8080
  https_port = 8443

Un nœud/nodearray peut également contenir plusieurs sections de configuration si nécessaire :

[[node scheduler]]
  [[[configuration]]]
  run_list = role[sge_scheduler_node]

  [[[configuration cycle_server.admin]]]
  name = poweruser
  pass = super_secret

Paramètres du modèle de cluster

Les modèles de cluster peuvent contenir des paramètres qui modifient les valeurs de certaines parties d’un cluster sans avoir à modifier le modèle lui-même. Cela est particulièrement utile dans les cas où de nombreux clusters similaires présentant des différences mineures sont souhaités, comme le déploiement d’environnements de développement et de production. La syntaxe permettant de spécifier un paramètre au sein d’un modèle de cluster consiste à préfixer une variable avec un ' $'. Un exemple de modèle de base (non fonctionnel) avec certains paramètres peut ressembler à ceci :

# template.txt
[cluster gridengine]

  [[node scheduler]]
  MachineType = $machine_type

    [[[configuration]]]
    gridengine.slots = $slots

Ce modèle définit deux paramètres : $machine_type et $slots. À l’aide de ce modèle, vous pouvez définir des fichiers texte contenant les valeurs des paramètres dans les environnements de développement et de production. Le fichier de paramètres peut être au format JSON ou dans un format de fichier de propriétés Java :

# dev-params.json
{
  "machine_type": "H16r",
  "slots": 2
}

# prod-params.properties
machine_type = Standard_D4v3
slots = 8

Cela crée un fichier JSON contenant les paramètres du développement et un fichier .properties contenant les valeurs de production.

Notes

Le suffixe de nom de fichier de votre fichier de paramètres est important ! Si vous utilisez JSON, votre fichier doit être nommé foo.json. Si vous utilisez des propriétés Java, votre fichier doit se terminer par .properties. Les fichiers de paramètres nommés incorrectement ne seront pas importés correctement.

Vous pouvez maintenant importer le modèle à l’aide du fichier de paramètres pour renseigner les éléments manquants :

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

Il est également possible de définir certains ou tous les paramètres au sein du modèle de cluster lui-même :

# template.txt
[cluster gridengine]

  [[node scheduler]]
  MachineType = $machine_type

    [[[configuration]]]
    gridengine.slots = $slots

[parameters]
  [[parameter machine_type]]
  DefaultValue = Standard_D4v3

  [[parameter slots]]
  DefaultValue = 2

Les valeurs par défaut de chaque paramètre sont définies dans le modèle (nous avons utilisé les valeurs « dev » comme valeurs par défaut).

Il est désormais possible d’importer le modèle sans fichier de paramètres, et les valeurs « dev » sont utilisées automatiquement. Quand il est temps de créer un cluster « prod », vous pouvez utiliser le fichier prod-params.properties pour remplacer les valeurs spécifiées dans le fichier de modèle lui-même.

Notes

Les noms de paramètres peuvent inclure des lettres, des chiffres et des traits de soulignement.

Les références de paramètre dans le modèle peuvent prendre l’une des deux formes suivantes :

$param: utilise la valeur d’un seul paramètre nommé param

${expr}: évalue dans le contexte de tous les paramètres, ce qui vous permet de calculer des valeurs dynamiques expr . Par exemple :

Attribute = ${(a > b ? a : b) * 100}

Cela prend la plus grande de deux paramètres, a et ble multiplie par 100. L’expression est interprétée et évaluée en fonction de la spécification du langage ClassAd.

Si une référence de paramètre existe elle-même, la valeur du paramètre est utilisée, qui prend en charge des types non-chaîne tels que des booléens, des entiers et des structures imbriquées telles que des listes. Toutefois, si la référence est incorporée dans un autre texte, sa valeur est convertie et incluse dans une chaîne. Par exemple, supposons qu’il param soit défini comme 456 et référencé à deux endroits :

Attribute1 = $param
Attribute2 = 123$param

La valeur de Attribute1 serait le nombre 456, mais la valeur de Attribute2 serait la chaîne "123456". Notez qu’il ${param} est identique à $param, ce qui vous permet d’incorporer des références de paramètres dans des situations plus complexes :

Attribute3 = 123$param789
Attribute4 = 123${param}789

Attribute3 recherche le paramètre nommé param789, mais Attribute4 utilise la valeur de l’obtention param"123456789".

Types d’ordinateurs

Azure CycleCloud prend en charge plusieurs types de machines via l’attribut MachineType . Il tentera d’acquérir de la capacité dans l’ordre indiqué.

Spécifications init de cluster

L’application web Azure CycleCloud permet aux utilisateurs de sélectionner des spécifications de projet cluster-init lors de la création d’un cluster. Les spécifications de projet sont configurées dans le modèle de 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]]]

Une fois ce paramètre ajouté à votre modèle de cluster, votre utilisateur peut utiliser le sélecteur de fichiers pour sélectionner les spécifications de projet appropriées lors de la création d’un cluster.

Machines virtuelles Spot

Pour réduire le coût de vos charges de travail, vous pouvez définir Interruptible = true. Cela signale votre instance comme Spot et utilise une capacité excédentaire lorsqu’elle est disponible. Il est important de noter que ces instances ne sont pas toujours disponibles et peuvent être préemptées à tout moment, ce qui signifie qu’elles ne sont pas toujours appropriées pour votre charge de travail.

Par défaut, la valeur Interruptible true utilise des instances spot avec un prix maximal défini sur -1 ; cela signifie que l’instance ne sera pas supprimée en fonction du prix. Le prix de l’instance sera le prix actuel de Spot ou le prix d’une instance standard, la valeur la plus faible étant retenue, à condition que la capacité et le quota soient disponibles. Si vous souhaitez définir un prix maximal personnalisé, utilisez l’attribut MaxPrice sur le nœud ou le nœud souhaité.

[cluster demo]

  [[nodearray execute]]
  Interruptible = true
  MaxPrice = 0.2

Tables de recherche

Vous pouvez avoir une référence de paramètre une autre et calculer une certaine valeur avec une table de recherche. Par exemple, supposons que vous disposiez d’un paramètre pour l’image à utiliser, avec deux choix dans ce cas :

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

Vous pouvez également obtenir la version du système d’exploitation de l’image choisie et l’utiliser pour d’autres configurations en rendant e un paramètre dont la valeur est une table de valeurs de recherche :

[[parameter AmiLookup]]
  ParameterType = hidden
  [[[record DefaultValue]]]
      image-1000 = Ubuntu 20.04
      image-2000 = Ubuntu 22.04

Notez qu’il est masqué, afin qu’il n’apparaisse pas dans l’interface utilisateur.

Vous pouvez obtenir la version du système d’exploitation utilisée pour l’image choisie n’importe où dans la définition du cluster :

[[node node]]
[[[configuration]]]
version = ${AmiLookup[MachineImage]}

Intégration de l’interface graphique utilisateur

La définition de paramètres dans le modèle de cluster permet de tirer parti de l’interface graphique utilisateur Azure CycleCloud. Par exemple, lors de la définition des paramètres, les attributs suivants peuvent être utilisés pour faciliter la création de l’interface graphique graphique :

# 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

Les attributs « Label » et « Description » sont inclus, qui apparaîtront dans l’interface graphique utilisateur, ainsi que l’attribut facultatif « ParameterType ». Le paramètre « ParameterType » permet l’affichage des éléments d’interface utilisateur personnalisés. Dans l’exemple ci-dessus, la valeur « Cloud.MachineType » affiche une liste déroulante contenant tous les types d’ordinateurs disponibles. Les autres valeurs ParameterType sont les suivantes :

Type de paramètre	Description
Cloud.MachineType	Affiche une liste déroulante contenant tous les types d’ordinateurs disponibles.
Cloud.Credentials	Affiche une liste déroulante contenant toutes les informations d’identification disponibles.
Cloud.Region	Affiche une liste déroulante contenant toutes les régions disponibles.

Prise en charge du serveur Chef

Azure CycleCloud suports ChefServer.

Créez le fichier chefserver.json et ajoutez vos informations d’identification. ValidationKey correspond au fichier validation.pem de votre serveur Chef. Vous devez également prouver si validation_client_name vous l’avez modifié par rapport à la valeur par défaut de « 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
}

Ensuite, placez le fichier dans le répertoire /opt/cycle_server/config/data. Elle sera importée automatiquement.

Images utilisateur personnalisées dans les modèles

Azure CycleCloud prend en charge les images personnalisées dans les modèles. Spécifiez l’ID d’image (ID de ressource) directement avec ImageId, ou ajoutez l’image au registre d’images. Lorsque l’image se trouve dans le Registre, référencez-la avec Image votre nœud ou ImageName sur celui-ci. Elle s’affiche dans la liste déroulante de l’image dans la page de création du cluster.

Les images du registre d’images se composent d’un Package enregistrement qui identifie le contenu de l’image logique et d’un ou plusieurs enregistrements correspondants Artifact qui spécifient l’ID d’image réel dans le fournisseur de cloud approprié. Par exemple, une image personnalisée sur laquelle R est installé peut se composer de cet enregistrement de package :

AdType = "Package"
Name = "r_execute"
Version = "2.1.1"
PackageType = "image"
Label = "R"

Une fois que vous avez ajouté cet enregistrement, vous pouvez spécifier cette image en incluant l’un Image = R ou l’autre des ImageName = r_execute modèles de cluster.

Si cette image existait sous la forme d’une seule machine virtuelle utilisée avec un ID de /subscriptions/xxxxxxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/MyResourceGroup/providers/Microsoft.Compute/images/MyCustomImage, il faudrait stocker l’artefact suivant :

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"

Vous devez spécifier Provider sur l’artefact.

Vous pouvez ajouter autant d’artefacts que vous le souhaitez pour un package d’images donné, mais vous devez inclure tous les artefacts requis pour utiliser cette image dans tous les « emplacements » souhaités (un par compte de fournisseur de cloud, régions, projets, etc.). Le nom de l’artefact n’est pas important, sauf qu’il doit être unique à tous les artefacts d’un package et d’une version donnés. L’utilisation d’une combinaison des détails spécifiques du fournisseur et du fournisseur (par exemple, région) est généralement recommandée. CycleCloud sélectionne automatiquement l’artefact approprié pour qu’il corresponde au fournisseur et à tous les détails spécifiques au fournisseur, mais il utilise l’attribut fournisseur (et la région, etc.) au lieu d’analyser le nom.

Si vous ajoutez plusieurs packages d’images portant le même nom, ils doivent avoir des numéros de version différents. Lors du démarrage d’une instance, CycleCloud sélectionne automatiquement l’image avec le numéro de version le plus élevé, en traitant le numéro de version comme une chaîne en pointillés et en comparant chaque partie sous forme de nombre. Pour remplacer cela, spécifiez ImageVersion sur le nœud, sous la forme d’un littéral (par exemple 1.2) ou d’un caractère générique (1.x).