Modèles de cluster

Azure CycleCloud utilise des modèles pour définir des configurations de cluster. CycleCloud inclut de nombreux modèles par défaut. Pour obtenir la liste complète des modèles pris en charge, consultez 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.

Notation de configuration

Les modèles de cluster Azure CycleCloud vous permettent d’ajouter une ou plusieurs sections [[[configuration]] à un nœud ou un tableau de nœuds. Ces sections spécifient des options de configuration logicielle pour les nœuds démarrés par CycleCloud. Utilisez la notation en pointillés 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 utiliser prefix la notation pour spécifier une section de configuration et 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 ou un tableau de nœuds 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 que vous utilisez pour modifier les valeurs de certaines parties d’un cluster. Vous n’avez pas besoin de modifier le modèle lui-même. Cette fonctionnalité est particulièrement utile lorsque vous souhaitez créer de nombreux clusters similaires avec des différences mineures, telles que le déploiement d’environnements de développement et de production. Pour spécifier un paramètre dans un modèle de cluster, préfixez 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. Avec ce modèle, vous pouvez créer des fichiers texte qui contiennent les valeurs de ces paramètres dans les environnements dev et prod. Vous pouvez utiliser le format JSON ou le format de fichier de propriétés Java pour le fichier de paramètres :

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

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

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

Vous pouvez maintenant importer le modèle à l’aide du fichier de paramètres pour remplir 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

Vous pouvez également 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

Le modèle définit les valeurs par défaut pour chaque paramètre (nous avons utilisé les valeurs de développement comme valeurs par défaut).

Vous pouvez maintenant importer le modèle sans fichier de paramètres et les valeurs de développement sont utilisées automatiquement. Quand il est temps de créer un cluster prod, utilisez le fichier prod-params.properties pour remplacer les valeurs spécifiées dans le fichier de modèle lui-même.

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 paramètre unique 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}

Cette expression prend le plus grand des deux paramètres, a et b, et le 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’elle param soit définie comme 456 et référencée à deux emplacements :

• Attribute1 = $param
• Attribute2 = 123$param

La valeur de Attribute1 est le nombre 456, mais la valeur de Attribute2 est la chaîne "123456". ${param} fonctionne de la même façon que , de sorte que $paramvous pouvez l’utiliser pour inclure 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 param pour obtenir "123456789".

Types d’ordinateurs

Azure CycleCloud prend en charge plusieurs types d’ordinateurs via l’attribut MachineType . La solution tente d’obtenir la capacité dans l’ordre que vous listez.

Spécifications d'initialisation de cluster

L’application web Azure CycleCloud vous permet de sélectionner les spécifications de projet init de cluster lorsque vous créez un cluster. Configurez les spécifications du projet 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]]]

Après avoir ajouté ce paramètre à votre modèle de cluster, vous pouvez utiliser le sélecteur de fichiers pour sélectionner les spécifications de projet appropriées lorsque vous créez un cluster.

Repérer les machines virtuelles

Pour réduire le coût de vos charges de travail, configurez Interruptible à true. Ce paramètre signale votre instance en tant que machine virtuelle spot et lui permet d’utiliser une capacité excédentaire lorsqu’elle est disponible. N’oubliez pas que ces instances ne sont pas toujours disponibles et peuvent être préemptées à tout moment, de sorte qu’elles peuvent ne pas convenir à votre charge de travail.

Par défaut, lorsque vous définissez Interruptible la valeur true, l’instance utilise des machines virtuelles spot avec un prix maximal défini sur -1. Ce paramètre signifie que l’instance n’est pas supprimée en fonction du prix. Le prix de l’instance est le prix actuel des machines virtuelles spot ou le prix d’une instance standard, selon le moins élevé des deux, tant que de la capacité et du quota sont disponibles. Pour définir un prix maximal personnalisé, utilisez l’attribut MaxPrice sur le nœud ou le tableau de nœuds souhaités.

[cluster demo]

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

Tables de recherche

Vous pouvez référencer un paramètre à un autre pour calculer une certaine valeur avec une table de recherche. Par exemple, supposons que vous disposez 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 choix de valeurs :

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

Ce paramètre est masqué. Il n’apparaît donc 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

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

# 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

L’interface graphique utilisateur inclut les attributs Label et Description , qui apparaissent dans l’interface utilisateur graphique, ainsi que l’attribut ParameterType facultatif. L’attribut ParameterType permet aux éléments d’interface utilisateur personnalisés d’être affichés. Dans l’exemple précédent, la Cloud.MachineType valeur affiche une liste déroulante contenant tous les types d’ordinateurs disponibles. Les autres valeurs ParameterType sont les suivantes :

Images utilisateur personnalisées dans les modèles

Azure CycleCloud prend en charge les images personnalisées dans les modèles. Vous pouvez spécifier l’ID d’image (ID de ressource) directement avec ImageId, ou vous pouvez ajouter l’image au registre d’images. Lorsque vous ajoutez l’image au registre, vous pouvez la référencer avec soit Image soit ImageName sur votre nœud. L’image apparaît 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 avec R installée sur celle-ci peut se composer de cet enregistrement de package :

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

Lorsque vous ajoutez cet enregistrement, vous pouvez spécifier l’image en incluant soit Image = R soit ImageName = r_execute dans le modèle de cluster.

Si cette image existait en tant que machine virtuelle unique dans la région USA Est avec un ID de /subscriptions/xxxxxxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/MyResourceGroup/providers/Microsoft.Compute/images/MyCustomImage, vous devez 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. Nous vous recommandons généralement d’utiliser une combinaison du fournisseur et de détails spécifiques au fournisseur, tels que la région. 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, et ainsi de suite) plutôt que d’analyser le nom.

Si vous ajoutez plusieurs packages d’images portant le même nom, chaque package doit avoir un numéro de version différent. Lorsque vous démarrez une instance, CycleCloud sélectionne automatiquement l’image avec le numéro de version le plus élevé. Il traite le numéro de version comme une chaîne en pointillés et compare chaque partie en tant que nombre. Pour remplacer ce comportement, spécifiez ImageVersion sur le nœud en tant qu'un numéro de version littéral (par exemple, 1.2) ou en tant qu'un numéro de version générique (par exemple, 1.x).