Partager via

Cluster CycleCloud GridEngine

Open Grid Scheduler (moteur de grille) peut facilement être activé sur un cluster Azure CycleCloud en modifiant le « run_list » dans la définition du cluster. Un cluster Grid Engine se compose de deux composants principaux. Le premier est le nœud « master », qui fournit un système de fichiers partagé où le logiciel du moteur de grille s’exécute. Le deuxième est l’ensemble de nœuds « execute », qui sont les hôtes qui montent le système de fichiers partagé et exécutent les travaux soumis. Par exemple, un extrait de modèle de cluster Grid Engine simple peut ressembler à ceci :

[cluster grid-engine]

[[node master]]
    ImageName = cycle.image.centos7
    MachineType = Standard_A4 # 8 cores

    [[[configuration]]]
    run_list = role[sge_master_role]

[[nodearray execute]]
    ImageName = cycle.image.centos7
    MachineType = Standard_A1  # 1 core

    [[[configuration]]]
    run_list = role[sge_execute_role]

Remarque

Les noms de rôles contiennent « sge » pour des raisons héritées : Grid Engine était un produit de Sun Microsystems.

L’importation et le démarrage d’un cluster avec une définition dans CycleCloud entraînent un nœud « master » unique. Les nœuds d’exécution peuvent être ajoutés au cluster via la cyclecloud add_node commande. Par exemple, pour ajouter 10 nœuds d’exécution supplémentaires :

cyclecloud add_node grid-engine -t execute -c 10

Mise à l’échelle automatique du moteur de grille

Azure CycleCloud prend en charge la mise à l’échelle automatique pour Grid Engine. Ce comportement signifie que le logiciel surveille en permanence l’état de votre file d’attente et active ou désactive automatiquement les nœuds si nécessaire pour terminer la charge de travail efficacement en termes de temps et de coût. Vous pouvez activer la mise à l’échelle automatique pour le moteur de grille en ajoutant Autoscale = true à votre définition de cluster :

[cluster grid-engine]
Autoscale = True

Par défaut, tous les travaux soumis à la file d’attente de Grid Engine s’exécutent sur des machines de type « exécuter ». Ces machines sont définies par le tableau de nœuds nommé « execute ». Vous n’êtes pas limité au nom « execute », ni à un seul type de configuration de machine pour exécuter des travaux et une mise à l’échelle automatique.

Par exemple, un scénario courant implique un cluster avec deux définitions de nœud différentes. L’un d’eux est conçu pour exécuter des travaux « normaux » qui utilisent des PROCESSEURs standard. L’autre est destiné aux travaux qui nécessitent des machines compatibles GPU. Dans ce cas, vous souhaitez mettre à l’échelle indépendamment votre file d’attente en utilisant des travaux normaux et des travaux GPU pour vous assurer de disposer d’une quantité appropriée de chaque ordinateur pour consommer la file d’attente de travail. Un exemple de définition ressemble à ceci :

[cluster grid-engine]
Autoscale = True

[[node master]]
    ImageName = cycle.image.centos7
    MachineType = Standard_A3  # 4 cores

    [[[configuration]]]
    run_list = role[sge_master_role]

[[nodearray execute]]
    ImageName = cycle.image.centos7
    MachineType = Standard_A4  # 8 cores

    [[[configuration]]]
    run_list = role[sge_execute_role]

[[nodearray gpu]]
    MachineType = Standard_NV12 # 2 GPUs
    ImageName = cycle.image.centos7

    # Set the number of cores to the number of GPUs for autoscaling purposes
    CoreCount = 2  

    [[[configuration]]]
    run_list = role[sge_execute_role]
    gridengine.slot_type = gpu
    gridengine.slots = 2

Dans l’exemple illustré, il existe maintenant deux tableaux de nœuds : l’un est un tableau de nœuds d’exécution « standard », le deuxième est nommé « gpu » fournissant un MachineType qui a deux GPU NVIDIA (Standard_NV12 dans Azure). Notez également qu’il existe maintenant deux nouveaux éléments dans la section de configuration en plus de la recette « csge :sgeexec ». L’ajout gridengine.slot_type = gpu indique au planificateur du moteur de grille que ces nœuds doivent être nommés « gpu » et doivent donc exécuter uniquement des travaux « gpu ». Le nom « gpu » est arbitraire, mais un nom qui décrit le nœud est le plus utile. Définissez gridengine.slots = 2, qui indique au logiciel de s’assurer que ce type de nœud ne peut exécuter que deux travaux à la fois (Standard_NV12 n’a que 2 GPU).

Par défaut, le moteur de grille affecte le nombre d’emplacements par nœud en fonction du nombre de processeurs du système. Dans ce cas, ce comportement par défaut peut entraîner un trop grand nombre de travaux s’exécutant simultanément sur un seul nœud. Dans l’exemple illustré, CoreCount=2 est défini sur le nodearray pour correspondre au nombre de GPU disponibles sur MachineType, ce qui permet à CycleCloud de mettre correctement à l’échelle ce tableau en fonction du nombre de GPU par rapport au nombre d’UC.

Vous pouvez vérifier le nombre de slots et le type de slot que vos machines possèdent en exécutant la commande :

    -bash-4.1# qstat -F slot_type
    queuename                      qtype resv/used/tot. load_avg arch          states
    ---------------------------------------------------------------------------------
    all.q@ip-0A000404              BIP   0/0/4          0.17     linux-x64
        hf:slot_type=execute
    ---------------------------------------------------------------------------------
    all.q@ip-0A000405              BIP   0/0/2          2.18     linux-x64
        hf:slot_type=gpu
    ---------------------------------------------------------------------------------
    all.q@ip-0A000406              BIP   0/0/4          0.25     linux-x64

Notez qu’il y a l’un des « slot_type » spécifiés « execute » et « gpu ». Les slot_types sont configurées individuellement, et le nombre d’emplacements pour l’emplacement « execute » est 4, qui correspond au nombre de processeurs sur l’ordinateur. Le nombre d’emplacements pour le type d’emplacement « gpu » est 2, que nous avons spécifié dans notre modèle de configuration de cluster. La troisième machine est le nœud maître qui n’exécute pas de travaux.

Utilisation avancée de Grid Engine

Ces paramètres de configuration permettent la personnalisation avancée des nœuds et des tableaux de nœuds. Par exemple, si des travaux nécessitent une quantité spécifique de mémoire, par exemple 10 Go chacun, vous pouvez définir un nœud d’exécution qui démarre les machines avec 60 Go de mémoire, puis ajouter les options gridengine.slots = 6 de configuration pour vous assurer que seuls 6 travaux peuvent s’exécuter simultanément sur ce type de nœud (s’assurer que chaque travail a au moins 10 Go de mémoire à utiliser).

Nœuds groupés dans Grid Engine

Lorsqu'un travail parallèle est soumis au moteur de grille, CycleCloud utilise par défaut un comportement de mise à l'échelle automatique pour traiter chaque travail MPI comme une demande de nœuds groupée. Les nœuds regroupés sont étroitement couplés et idéalement adaptés aux flux de travail MPI.

Lorsqu’un ensemble de nœuds groupés joint un cluster Grid Engine, l’ID de groupe de chaque nœud est utilisé comme valeur de la valeur affinity_groupcomplexe. En demandant de spécifier un affinity_group pour les travaux, cela permet à l'ordonnanceur Grid Engine de s’assurer que les travaux s'exécutent uniquement sur les machines du même groupe.

L’automatisation de CycleCloud demande automatiquement des nœuds regroupés et les affecte aux groupes d’affinités disponibles lorsque des travaux parallèles sont rencontrés.

Soumission de travaux au moteur de grille

La manière la plus générale d’envoyer des travaux à un ordonnanceur Grid Engine est la commande :

qsub my_job.sh

Cette commande soumet un travail qui s’exécute sur un nœud de type « execute », c’est-à-dire un nœud défini par le nodearray « execute ». Pour exécuter un travail sur un nœud d’un type différent, par exemple le type de nœud « gpu » indiqué, nous modifions notre soumission :

qsub -l slot_type=gpu my_gpu_job.sh

Cette commande garantit que le travail s’exécute uniquement sur un « slot_type » de « GPU ».

Si slot_type est omis, « execute » est automatiquement attribué au travail. L’utilisateur peut modifier le mécanisme qui affecte automatiquement des slot_type aux travaux. Un script Python situé à l’emplacement /opt/cycle/jetpack/config/autoscale.py peut être créé, ce qui doit définir une fonction unique « sge_job_handler ». Cette fonction reçoit une représentation de dictionnaire du travail, similaire à la sortie d’une qstat -j JOB_ID commande et doit retourner un dictionnaire de ressources matérielles qui doivent être mises à jour pour le travail.

Par exemple, le script suivant affecte un travail au « gpu » slot_type si le nom des travaux inclut les lettres « gpu ». Les utilisateurs sont autorisés à soumettre automatiquement leurs travaux sans en modifier les paramètres, tout en s’assurant qu’ils s’exécutent sur les nœuds appropriés et qu’ils sont mis à l’échelle automatiquement :

#!/usr/env python
#
# File: /opt/cycle/jetpack/config/autoscale.py
#
def sge_job_handler(job):
  # The 'job' parameter is a dictionary containing the data present in a 'qstat -j JOB_ID':
    hard_resources = {'slot_type': 'execute', 'affinity_group' : 'default' }

  # Don't modify anything if the job already has a slot type
  # You could modify the slot type at runtime by not checking this
  if 'hard_resources' in job and 'slot_type' in job['hard_resources']:
      return hard_resources

  # If the job's script name contains the string 'gpu' then it's assumed to be a GPU job.
  # Return a dictionary containing the new job_slot requirement to be updated.
  # For example: 'big_data_gpu.sh' would be run on a 'gpu' node.
  if job['job_name'].find('gpu') != -1:
      hard_resources {'slot_type': 'gpu'}
  else:
      return hard_resources

Le paramètre « job » passé est un dictionnaire qui contient les données d’un appel qstat -j JOB_ID :

{
    "job_number": 5,
    "job_name": "test.sh",
    "script_file": "test.sh",
    "account": "sge",
    "owner": "cluster.user",
    "uid": 100,
    "group": "cluster.user",
    "gid": 200,
    "submission_time": "2013-10-09T09:09:09",
    "job_args": ['arg1', 'arg2', 'arg3'],
    "hard_resources": {
       'mem_free': '15G',
       'slot_type': 'execute'
    }
}

Vous pouvez utiliser cette fonctionnalité de script pour affecter automatiquement des slot_type en fonction de n’importe quel paramètre de travail défini, tel que les arguments, les besoins en ressources comme la mémoire ou l’utilisateur soumis.

Supposons que vous soumettez 5 travaux pour chaque « slot_type » :

qsub -t 1:5 gpu_job.sh
qsub -t 1:5 normal_job.sh

Il y aurait maintenant 10 emplois dans la file d’attente. En raison du script défini, les cinq travaux avec « gpu » dans le nom sont automatiquement configurés pour s’exécuter uniquement sur les nœuds « slot_type=gpu ». Le mécanisme de mise à l’échelle automatique CycleCloud détecterait qu’il existe 5 travaux « gpu » et 5 travaux « d’exécution ». Étant donné que le nœud « gpu » est défini comme ayant 2 emplacements par nœud, CycleCloud démarre 3 de ces nœuds (5/2=2,5 arrondi à 3).

Il existe 5 travaux normaux, étant donné que le type d’ordinateur pour le nodearray « execute » comporte 4 PROCESSEURs chacun, CycleCloud démarre 2 de ces nœuds pour gérer les travaux (5/4=1,25 arrondi à 2). Après une brève période de démarrage, les nœuds nouvellement lancés démarrent et se configurent eux-mêmes. Une fois prêtes, les 10 tâches sont exécutées jusqu’à la fin. Les 5 nœuds s’arrêtent ensuite automatiquement avant qu’un autre cycle de facturation commence par le fournisseur de cloud.

Les travaux sont supposés avoir une durée d’une heure. Si le runtime de travail est connu, l’algorithme de mise à l’échelle automatique peut tirer parti de ces informations. Informez l'autoscale de la durée d'exécution du travail attendue en l'ajoutant au contexte du travail. L'exemple suivant définit la durée d'exécution du travail pour l'autoscale à 10 minutes :

qsub -ac average_runtime=10 job_with_duration_of_10m.sh

Référence de configuration du moteur de grille

Voici les options de configuration spécifiques au moteur de grille que vous pouvez activer pour personnaliser les fonctionnalités :

options de configuration SGE-Specific Descriptif
gridengine.slots Nombre de slots d’un nœud donné à signaler au moteur de grille. Le nombre d’emplacements est le nombre de travaux simultanés qu’un nœud peut exécuter, cette valeur correspond par défaut au nombre de processeurs sur un ordinateur donné. Vous pouvez remplacer cette valeur dans les cas où vous n’exécutez pas de travaux basés sur le processeur, mais sur la mémoire, les GPU, etc.
gridengine.slot_type Le nom du type d'« emplacement » qu'un nœud fournit. La valeur par défaut est « execute ». Lorsqu’un travail est étiqueté avec la ressource matérielle « slot_type= », ce travail s’exécute uniquement sur un ordinateur du même type d’emplacement. Ce balisage vous permet de créer différentes configurations logicielles et matérielles par nœud et de vous assurer qu’un travail approprié est toujours planifié sur le type de nœud approprié.
gridengine.ignore_fqdn Valeur par défaut : true. Défini sur false si tous les nœuds de votre cluster ne font pas partie d’un seul domaine DNS.
gridengine.version Valeur par défaut : « 2011.11 ». Cette option de configuration spécifie la version du moteur de grille à installer et à exécuter. Actuellement, il s’agit de la valeur par défaut et de la seule option disponible. D’autres versions du logiciel Grid Engine peuvent être prises en charge ultérieurement.
gridengine.root Par défaut : '/sched/sge/sge-2011.11' Cet emplacement est celui où Grid Engine s'installe et se monte sur chaque nœud du système. Il est préférable de conserver cette valeur inchangée. Toutefois, si vous modifiez, veillez à définir la même valeur sur chaque nœud du cluster.

CycleCloud prend en charge un ensemble standard d'attributs d'arrêt automatique pour les planificateurs

Caractéristique Descriptif
cyclecloud.cluster.autoscale.stop_enabled La fonction d'arrêt automatique est-elle activée sur ce nœud ? [vrai/faux]
cyclecloud.cluster.autoscale.idle_time_after_jobs Durée (en secondes) pendant laquelle un nœud reste inactif après avoir terminé les tâches avant que sa capacité ne soit réduite.
cyclecloud.cluster.autoscale.temps_d'attente_avant_les_jobs Durée (en secondes) pendant laquelle un nœud reste inactif avant de terminer les tâches, avant d'être réduit en capacité.

Problèmes connus

  • qsh la commande pour la session interactive ne fonctionne pas. Utilisez qrsh comme alternative.
  • La mise à l’échelle automatique ne respecte pas le complexe exclusive=1, ce qui peut entraîner le démarrage d’un nombre de nœuds inférieur à celui prévu.

Remarque

Même si Windows est une plateforme GridEngine officiellement prise en charge, CycleCloud ne prend pas en charge l’exécution de GridEngine sur Windows.

Cette page concerne les fonctionnalités et la configuration de l’utilisation (Altair) GridEngine avec CycleCloud.

Configuration des ressources

L'application cyclecloud-gridengine associe les ressources sge aux ressources cloud Azure pour fournir des outils riches en fonctionnalités pour la configuration de cluster et la mise à l'échelle automatique. L’application est déployée automatiquement pour les clusters créés via l’interface utilisateur CycleCloud ou sur n’importe quel hôte d’administrateur gridengine sur un cluster existant.

Installation ou mise à niveau de Cyclecloud-Gridengine

Le bundle cyclecloud-gridengine est disponible dans GitHub en tant qu’artefact de version. L’installation et la mise à niveau suivent le même processus. L’application nécessite python3 avec virtualenv.

tar xzf cyclecloud-gridengine-pkg-*.tar.gz
cd cyclecloud-gridengine
./install.sh

Fichiers importants

L’application analyse la configuration sge chaque fois qu’elle s’exécute : tâches, files d’attente, complexes. Les informations sont fournies dans le stderr et stdout de la commande et dans un fichier journal, à des niveaux configurables. Toutes les commandes de gestion gridengine avec des arguments sont également enregistrées dans le fichier.

Descriptif Emplacement
Configuration de mise à l’échelle automatique /opt/cycle/gridengine/autoscale.json
Journal de mise à l’échelle automatique /opt/cycle/jetpack/logs/autoscale.log
journal de suivi qconf /opt/cycle/jetpack/logs/qcmd.log

Files d’attente SGE, groupes hôtes et environnements parallèles

L’utilitaire de mise à l’échelle automatique cyclecloud-gridengine ajoute azgedes hôtes au cluster en fonction de la configuration du cluster. Les opérations de mise à l’échelle automatique effectuent les actions suivantes.

  1. Lisez la demande de ressource de travail et recherchez une machine virtuelle appropriée pour démarrer
  2. Démarrez la machine virtuelle et attendez qu’elle soit prête
  3. Lire la file d’attente et l’environnement parallèle du travail
  4. En fonction de queue/pe, attribuer l’hôte à un groupe d'hôtes approprié
  5. Ajouter l’hôte au cluster et à toute autre file d’attente contenant le groupe hôte

Considérez la définition de file d’attente suivante pour une file d’attente nommée short.q

hostlist              @allhosts @mpihg01 @mpihg02 @lowprio 
...
seq_no                10000,[@lowprio=10],[@mpihg01=100],[@mpihg02=200]
pe_list               NONE,[@mpihg01=mpi01], \
                      [@mpihg02=mpi02]

La soumission d’un travail par qsub -q short.q -pe mpi02 12 my-script.sh démarre au moins une machine virtuelle. Lorsque le cluster est ajouté, il joint le groupe hôte @mpihg02 , car il s’agit du groupe hôte disponible à la fois pour la file d’attente et pour l’environnement parallèle. Il rejoint également @allhosts, un groupe hôte spécial.

Si vous soumettez un travail avec qsub -q short.q my-script.sh sans spécifier d’environnement parallèle pe, la machine virtuelle résultante rejoint les groupes-hôtes @allhosts et @lowpriority liés à la file d’attente qui n’a pas été attribuée à des pes.

Enfin, un travail soumis avec qsub -q short.q -pe mpi0* 12 my-script.sh résulte en une machine virtuelle ajoutée à @mpihg01 ou @mpihg02 en fonction des prédictions d’allocation de CycleCloud.

Les environnements parallèles correspondent implicitement au groupe de placement cyclecloud. Les machines virtuelles d’un PE sont contraintes d’être au sein du même réseau. Si vous souhaitez utiliser un PE qui ne conserve pas de groupe de placement, utilisez le fichier autoscale.json pour refuser.

Ici, nous choisissons de ne pas utiliser les groupes de placement pour le make pe :

"gridengine": {
    "pes": {
      "make": {
        "requires_placement_groups": false
      }
    },

Groupes de placement CycleCloud

Les groupes de placement CycleCloud correspondent de manière un-à-un à Azure VMSS avec SinglePlacementGroup : les machines virtuelles d’un groupe de placement partagent un réseau Infiniband et ne partagent qu'avec des machines virtuelles au sein du groupe de placement. Pour préserver intuitivement ces silos, les groupes de placement mappent également à 1:1 avec l’environnement parallèle du moteur de grille.

La spécification d'un environnement parallèle pour un travail restreint l'exécution de celui-ci à un groupe de placement via une logique de répartition intelligente des groupes hôtes. Vous pouvez désactiver ce comportement via la configuration correspondante dans autoscale.json: "required_placement_groups" : false.

Configuration de mise à l’échelle automatique

Ce plug-in met automatiquement à l’échelle la grille pour répondre aux exigences de la charge de travail. Le fichier de configurationautoscale.json détermine le comportement de l’autoscaler du Grid Engine.

  • Définir les détails de la connexion cyclecloud
  • Définir le minuteur d’arrêt pour les nœuds inactifs
  • Une mise à l’échelle automatique multidimensionnelle est possible, définissez les attributs à utiliser dans l’empaquetage des travaux, par exemple, slots, mémoire
  • Inscrire les files d’attente, les environnements parallèles et les groupes hôtes à gérer
Paramétrage Catégorie Descriptif
URL Chaîne CC URL
nom d’utilisateur/mot de passe Chaîne Détails de la connexion CC
nom du cluster Chaîne Nom du cluster CC
ressources_par_défaut Carte Lier une ressource de nœud à une ressource hôte du moteur de grille pour la mise à l’échelle automatique
idle_timeout Int Temps d’attente avant de terminer les nœuds inactifs (s)
boot_timeout Int Temps d’attente avant la fin des nœuds pendant les phases de configuration longues (s)
gridengine.relevant_complexes Liste (chaîne) Complexes du moteur de grille à prendre en compte dans la mise à l’échelle automatique, par exemple les slots, mem_free
gridengine.logging Fichier Emplacement du fichier de configuration de log
gridengine.pes Struct Spécifie le comportement des PE, par exemple requires_placement_group = false

Le programme de mise à l’échelle automatique prend uniquement en compte la ressource pertinente

Une autre ressource de mise à l’échelle automatique

Par défaut, les travaux demandent de nombreux emplacements et le cluster est mis à l’échelle en fonction de ces demandes.

Supposons que nous voulons mettre à l’échelle automatique en utilisant la requête de ressource de travail m_mem_free.

  1. Ajouter m_mem_free au gridengine.relevant_resources dans autoscale.json
  2. Reliez m_mem_free à la ressource mémoire au niveau du nœud dans autoscale.json

Ces attributs peuvent être utilisés comme références avec node.* en tant que valeur dans _default/ressources.

Nœud Catégorie Descriptif
nodearray Chaîne Nom du nodearray cyclecloud
groupe de placement Chaîne Nom du groupe de placement cyclecloud dans un nodearray
vm_size Chaîne Nom du produit de machine virtuelle, par exemple « Standard_F2s_v2 »
vcpu_count Int Processeurs virtuels disponibles sur le nœud, comme indiqué sur des pages de produit individuelles
pcpu_count Int Processeurs physiques disponibles sur le nœud
mémoire Chaîne Mémoire physique approximative disponible dans la machine virtuelle avec indicateur d’unité, par exemple « 8,0g »

D’autres attributs se trouvent dans l’espace node.resources.* de noms, par exemple « node.resources ».

Nœud Catégorie Descriptif
ncpus Chaîne Nombre de processeurs disponibles dans la machine virtuelle
pcpus Chaîne Nombre de processeurs physiques disponibles dans la machine virtuelle
ngpus Nombre entier Nombre de GPU disponibles dans la machine virtuelle
memb Chaîne Mémoire physique approximative disponible dans la machine virtuelle avec indicateur d’unité, par exemple « 8.0b »
memkb Chaîne Mémoire physique approximative disponible dans la machine virtuelle avec indicateur d’unité, par exemple « 8,0k »
memmb Chaîne Mémoire physique approximative disponible dans la machine virtuelle avec indicateur d’unité, par exemple « 8,0m »
memgb Chaîne Mémoire physique approximative disponible dans la machine virtuelle avec indicateur d’unité, par exemple « 8,0g »
memtb Chaîne Mémoire physique approximative disponible dans la machine virtuelle avec indicateur d’unité, par exemple « 8.0t »
Slots Nombre entier Identique à ncpus
slot_type Chaîne Étiquette d’ajout des extensions. Aucun affichage.
m_mem_free Chaîne Mémoire libre attendue sur l’hôte d’exécution, par exemple « 3.0g »
mfree Chaîne Identique à _m/_mem/free

Mappage des ressources

Il existe également des mathématiques disponibles pour l’default_resources : réduisez les emplacements sur un tableau de nœuds particulier par deux et ajoutez la ressource Docker à tous les nœuds :

    "default_resources": [
    {
      "select": {"node.nodearray": "beegfs"},
      "name": "slots",
      "value": "node.vcpu_count",
      "subtract": 2
    },
    {
      "select": {},
      "name": "docker",
      "value": true
    },

Les mappages des vCPUs de nœud vers les complexes de slots, et memmb à mem_free sont couramment utilisés par défaut. La première association est requise.

    "default_resources": [
    {
      "select": {},
      "name": "slots",
      "value": "node.vcpu_count"
    },
    {
      "select": {},
      "name": "mem_free",
      "value": "node.resources.memmb"
    }
 ],

Si un complexe a un raccourci différent de la valeur entière, définissez les deux dans default_resources où physical_cpu se trouve le nom complexe :

"default_resources": [
    {
      "select": {},
      "name": "physical_cpu",
      "value": "node.pcpu_count"
    },
    {
      "select": {},
      "name": "pcpu",
      "value": "node.resources.physical_cpu"
    }
]

L’ordre est important lorsque vous souhaitez un comportement particulier pour un attribut spécifique. Pour allouer un emplacement unique pour un nodearray spécifique tout en conservant le nombre d’emplacements par défaut pour tous les autres nodearrays :

    "default_resources": [
    {
      "select": {"node.nodearray": "FPGA"},
      "name": "slots",
      "value": "1",
    },
    {
      "select": {},
      "name": "slots",
      "value": "node.vcpu_count"
    },
]

Groupes hôtes

Le générateur de mise à l’échelle automatique CycleCloud, en tentant de répondre aux exigences du travail, mappe les nœuds au groupe hôte approprié. Les files d’attente, les environnements parallèles et les complexes sont tous pris en compte. Une grande partie de la logique consiste à faire correspondre le compartiment cyclecloud approprié (et la quantité de nœuds) au groupe hôte sge approprié.

Pour un travail soumis en tant que : qsub -q "cloud.q" -l "m_mem_free=4g" -pe "mpi*" 48 ./myjob.sh

CycleCloud trouve l’intersection des groupes hôtes qui :

  1. Sont inclus dans le pe_list pour cloud.q et correspondent au nom pe, par exemple pe_list [@allhosts=mpislots],[@hpc1=mpi].
  2. Disposez de ressources adéquates et d’un quota d’abonnement pour fournir toutes les ressources de travail.
  3. La configuration des contraintes de groupe hôte ne les filtre pas.

Plusieurs groupes hôtes peuvent répondre à ces exigences. Dans ce cas, le système doit décider de celui à utiliser. Il existe trois façons de résoudre les conflits d’appartenance au groupe hôte :

  1. Configurez les files d’attente pour éviter les ambiguïtés.
  2. Ajoutez des contraintes à autoscale.json.
  3. Laissez CycleCloud choisir les groupes hôtes correspondants de manière ordonnée par nom en ajustant weight_queue_host_sort < weight_queue_seqno la configuration du planificateur.
  4. Définissez seq_no 10000,[@hostgroup1=100],[@hostgroup2=200] dans la configuration de la file d’attente pour indiquer une préférence de groupe hôte.

Contraintes de groupe d’hôtes

Lorsqu’une file d’attente ou un xproject définit plusieurs groupes hôtes, l’un de ces groupes peut potentiellement recevoir de nouveaux hôtes. Pour contrôler les hôtes éligibles pour les files d’attente, vous pouvez appliquer des contraintes de groupe d’hôtes en fonction des propriétés du nœud.

"gridengine": {
    "hostgroups": {
      "@mpi": {
        "constraints": {
          "node.vm_size": "Standard_H44rs"
        }
      },
      "@amd-mem": {
        "constraints" : { 
            "node.vm_size": "Standard_D2_v3",
            "node.nodearray": "hpc" 
            }
        },
    }
  }

HINT : Inspectez toutes les propriétés de nœud disponibles par azge buckets.

azge

Ce package est fourni avec une ligne de commande, azge. Ce programme est utilisé pour effectuer la mise à l’échelle automatique et décompose tous les sous-processus sous mise à l’échelle automatique en composants distincts. Ces commandes s’appuient sur les variables d’environnement gridengine à définir. Vous devez être en mesure d’appeler qconf et qsub à partir du même profil que celui où azge il est appelé.

Commandes azge Descriptif
valider Vérifie les erreurs de configuration connues dans l'autoscaler ou le moteur de grille
Emplois Affiche tous les travaux de la file d’attente
Seaux Affiche les pools de ressources disponibles pour la mise à l’échelle automatique
Nœuds Affiche les hôtes de cluster et les propriétés
demande Fait correspondre les exigences de travail aux compartiments Cyclecloud et fournit un résultat de mise à l’échelle automatique
mise à l'échelle automatique Effectue la mise à l’échelle automatique complète, le démarrage et la suppression des nœuds en fonction des configurations

Lors de la modification des configurations du planificateur (qconf) ou des configurations de mise à l’échelle automatique (autoscale.json), ou même la configuration pour la première fois, azge peut être utilisé pour vérifier que le comportement de mise à l’échelle automatique correspond aux attentes. En tant qu'utilisateur root, vous pouvez exécuter les opérations suivantes. Pour comprendre le fonctionnement de la mise à l’échelle automatique, il est important de vous familiariser avec ces concepts.

  1. Exécutez azge validate pour vérifier les configurations pour les problèmes connus.
  2. Exécutez azge buckets pour vérifier les ressources offertes par le cluster CycleCloud.
  3. Exécutez azge jobs pour inspecter les détails de la tâche en attente.
  4. Exécutez azge demand pour effectuer la mise en correspondance entre le travail et le compartiment. Examinez ensuite quels travaux correspondent aux compartiments et aux groupes d'hôtes.
  5. Exécutez azge autoscale pour lancer le processus d’allocation de nœuds ou ajouter des nœuds prêts à être joints.

Une fois que les commandes fonctionnent comme prévu, activez la mise à l’échelle automatique en continu en ajoutant la azge autoscale commande au crontab racine. Veillez à définir à l’avance les variables d’environnement gridengine.

* * * * * . $SGE_ROOT/common/settings.sh && /usr/local/bin/azge autoscale -c /opt/cycle/gridengine/autoscale.json

Création d’un cluster hybride

CycleCloud prend en charge le scénario de cloud bursting. La configuration de base suppose que le $SGE_ROOT répertoire est disponible pour les nœuds cloud. Cette hypothèse peut être assouplie en définissant gridengine.shared.spool = false, gridengine.shared.bin = falseet en installant GridEngine localement.

Pour un cas simple, vous devez fournir un système de fichiers que les nœuds d’exécution peuvent monter. Ce système de fichiers doit inclure le ... répertoire, et vous configurez le montage dans les paramètres facultatifs. Lorsque les dépendances des répertoires sched et partagé sont publiées, vous pouvez arrêter le nœud du planificateur qui fait partie du cluster par défaut et utiliser les configurations à partir du système de fichiers externe.

  1. Créez un cluster de moteur de grille.
  2. Désactivez le proxy de retour.
  3. Remplacez /sched et /shared par des systèmes de fichiers externes.
  4. Sauvegardez le cluster.
  5. Supprimez le nœud du planificateur en tant qu’action dans l’interface utilisateur.
  6. Démarrez le cluster, aucun nœud ne démarre initialement.
  7. Configurer cyclecloud-gridengine avec autoscale.json pour utiliser le nouveau cluster

Utilisation du moteur de grille Univa dans CycleCloud

Le projet CycleCloud pour GridEngine utilise sge-2011.11 par défaut. Vous pouvez utiliser vos propres programmes d’installation Altair GridEngine en fonction de votre contrat de licence Altair. Cette section explique comment utiliser Altair GridEngine avec le projet CycleCloud GridEngine.

Conditions préalables

Cet exemple utilise la version de démonstration 8.6.1, mais toutes les versions > ge 8.4.0 sont prises en charge.

  1. Les utilisateurs doivent fournir des fichiers binaires UGE
  • ge-8.6.x-bin-lx-amd64.tar.gz
  • ge-8.6.x-common.tar.gz
  1. L’interface CLI CycleCloud doit être configurée. La documentation est disponible ici

Copier les fichiers binaires dans le coffre de stockage cloud

Une version complémentaire d’AGE (8.6.7-demo) est distribuée avec CycleCloud. Pour utiliser une autre version, chargez les fichiers binaires dans le compte de stockage utilisé par CycleCloud.


$ azcopy cp ge-8.6.12-bin-lx-amd64.tar.gz https://<storage-account-name>.blob.core.windows.net/cyclecloud/gridengine/blobs/
$ azcopy cp ge-8.6.12-common.tar.gz https://<storage-account-name>.blob.core.windows.net/cyclecloud/gridengine/blobs/

Modification des configurations dans le modèle de cluster

Effectuez une copie locale du modèle gridengine et modifiez-le pour utiliser les programmes d’installation UGE au lieu de la valeur par défaut.

wget https://raw.githubusercontent.com/Azure/cyclecloud-gridengine/master/templates/gridengine.txt

Dans le fichier gridengine.txt, localisez la première occurrence de [[[configuration]]] et insérez le texte pour qu'il corresponde à l'extrait de code suivant. Le fichier n’est pas sensible à l'indentation.

Remarque

Les détails de la configuration, en particulier la version, doivent correspondre au nom du fichier d’installation.

[[[configuration gridengine]]]
    make = ge
    version = 8.6.12-demo
    root = /sched/ge/ge-8.6.12-demo
    cell = "default"
    sge_qmaster_port = "537"
    sge_execd_port = "538"
    sge_cluster_name = "grid1"
    gid_range = "20000-20100"
    qmaster_spool_dir = "/sched/ge/ge-8.6.12-demo/default/spool/qmaster" 
    execd_spool_dir = "/sched/ge/ge-8.6.12-demo/default/spool"
    spooling_method = "berkeleydb"
    shadow_host = ""
    admin_mail = ""
    idle_timeout = 300

    managed_fs = true
    shared.bin = true

    ignore_fqdn = true
    group.name = "sgeadmin"
    group.gid = 536
    user.name = "sgeadmin"
    user.uid = 536
    user.gid = 536
    user.description = "SGE admin user"
    user.home = "/shared/home/sgeadmin"
    user.shell = "/bin/bash"

Ces configurations gridengine remplacent la version gridengine par défaut et l’emplacement d’installation au démarrage du cluster. Il n’est pas sûr de se déplacer hors de /sched, car il s’agit d’un emplacement partagé NFS dans le cluster.