CycleCloud GridEngine Cluster

Article
06/21/2023

Open Grid Scheduler (Grid Engine) peut facilement être activé sur un cluster Azure CycleCloud en modifiant le « run_list » dans la définition du cluster. Les deux composants de base d’un cluster Grid Engine sont le nœud « maître » qui fournit un système de fichiers partagé sur lequel le logiciel Grid Engine s’exécute, et les nœuds « exécuter » qui sont les hôtes qui montent le système de fichiers partagé et exécutent les travaux envoyés. Par exemple, un simple extrait de modèle de cluster Grid Engine 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 génèreront un seul nœud « maître ». 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 supplémentaires, exécutez :

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 qui signifie que le logiciel surveille l’état de votre file d’attente et active et désactive les nœuds si nécessaire pour effectuer le travail dans un délai/coût optimal. Vous pouvez activer la mise à l’échelle automatique pour Grid Engine en ajoutant Autoscale = true à votre définition de cluster :

[cluster grid-engine]
Autoscale = True

Par défaut, tous les travaux soumis dans la file d’attente du moteur de grille s’exécutent sur les machines de type « execute », il s’agit d’ordinateurs définis par le tableau de nœuds nommé « execute ». Vous n’êtes pas limité au nom « exécuter », ni à un seul type de configuration de machine sur lequel exécuter des travaux et mettre à l’échelle automatiquement.

Par exemple, un cas courant peut être que vous avez un cluster avec deux définitions de nœud différentes, l’une est pour exécuter des travaux « normaux » qui consomment du processeur standard, tandis qu’un autre type de travail peut utiliser des machines GPU. Dans ce cas, vous souhaitez mettre à l’échelle votre file d’attente de manière indépendante en fonction des travaux normaux et des travaux GPU pour vous assurer que vous disposez d’une quantité appropriée de chaque ordinateur pour utiliser la file d’attente de travail. Voici un exemple de définition :

[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 ci-dessus, il existe maintenant deux tableaux de nœuds : l’un est un tableau de nœuds d’exécution « standard », le second est nommé « gpu » fournissant un MachineType qui a deux GPU Nvidia (Standard_NV12 dans Azure). Notez également qu’il existe désormais 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 nœuds « 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 nombre d’emplacements par nœud dans Grid Engine correspond au nombre de processeurs sur le système, ce qui, dans ce cas, entraînerait l’exécution simultanée d’un trop grand nombre de travaux sur le nœud. Dans l’exemple ci-dessus, 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 et de processeurs.

Vous pouvez vérifier le nombre d’emplacements et les slot_type de vos machines 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 existe un de chaque « slot_type » que nous avons spécifié (exécuter et gpu) et que le nombre d’emplacements pour l’emplacement « execute » est de 4, soit le nombre de processeurs sur la machine. Le nombre d’emplacements pour le type d’emplacement « gpu » est de 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

Les paramètres de configuration ci-dessus permettent une personnalisation avancée des nœuds et des tableaux de nœuds. Par exemple, si les 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 (en vous assurant que chaque travail aura au moins 10 Go de mémoire à utiliser).

Nœuds groupés dans le moteur de grille

Lorsqu’un travail parallèle est soumis au moteur de grille, le comportement de mise à l’échelle automatique par défaut utilisé par CycleCloud consiste à traiter chaque travail MPI comme une demande de nœud groupée. Les nœuds groupés sont étroitement couplés et parfaitement 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 exigeant qu’un affinity_group soit spécifié pour les travaux, il permet au planificateur du moteur de grille de s’assurer que les travaux atterrissent uniquement sur les machines qui se trouvent dans le même groupe.

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

Envoi de travaux au moteur de grille

La méthode la plus générique pour envoyer des travaux à un planificateur Grid Engine est la commande :

qsub my_job.sh

Cette commande envoie un travail qui s’exécutera 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 nodearray d’un autre type, par exemple le type de nœud « gpu » ci-dessus, 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 affecté au travail. Le mécanisme qui affecte automatiquement slot_type aux travaux peut être modifié par l’utilisateur. Vous pouvez créer un script Python situé dans /opt/cycle/jetpack/config/autoscale.py , qui doit définir une seule fonction « sge_job_handler ». Cette fonction reçoit une représentation par 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, vous trouverez ci-dessous un script qui affectera un travail au slot_type « gpu » si le nom des travaux contient les lettres « gpu ». Cela permettrait à un utilisateur de soumettre ses travaux à partir d’un système automatisé sans avoir à modifier les paramètres de travail et à les exécuter sur et à mettre à l’échelle automatiquement les nœuds appropriés :

#!/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 qstat -j JOB_ID appel :

{
    "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 défini dans le travail, comme les arguments, d’autres besoins en ressources comme la mémoire, l’envoi d’un utilisateur, etc.

Si vous envoyez 5 travaux de chaque « slot_type » :

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

Il y aurait maintenant 10 travaux dans la file d’attente. En raison du script défini ci-dessus, les cinq travaux avec « gpu » dans le nom sont automatiquement configurés pour s’exécuter uniquement sur les nœuds de « slot_type=gpu ». Le mécanisme de mise à l’échelle automatique CycleCloud détecte qu’il existe 5 travaux « gpu » et 5 travaux « d’exécution ». Étant donné que le nodearray « gpu » est défini comme ayant 2 emplacements par nœud, CycleCloud démarrerait 3 de ces nœuds (5/2 =2,5 arrondi à 3). Il existe 5 travaux normaux, étant donné que le type de machine pour le nodearray « execute » a 4 processeurs chacun, CycleCloud démarrerait 2 de ces nœuds pour gérer les travaux (5/4=1,25 arrondi à 2). Après une courte période de démarrage et de configuration des nœuds nouvellement démarrés, les 10 travaux s’exécutent jusqu’à l’achèvement, puis les 5 nœuds s’arrêtent automatiquement avant que vous ne soyez à nouveau facturé 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 la mise à l’échelle automatique du temps d’exécution attendu du travail en l’ajoutant au contexte du travail. L’exemple suivant indique que la mise à l’échelle automatique du runtime du travail est en moyenne de 10 minutes :

qsub -ac average_runtime=10 job_with_duration_of_10m.sh

Informations de référence sur la 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	Description
gridengine.slots	Nombre d’emplacements pour 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	Nom du type « emplacement » fourni par un nœud. La valeur par défaut est « execute ». Lorsqu’un travail est marqué avec la ressource matérielle « slot_type= », ce travail s’exécute uniquement sur une machine du même type d’emplacement. Cela 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éfinissez 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 ». Il s’agit de la version du moteur de grille à installer et à exécuter. Il s’agit actuellement de l’option par défaut et uniquement . À l’avenir, d’autres versions du logiciel Grid Engine pourront être prises en charge.
gridengine.root	Valeur par défaut : « /sched/sge/sge-2011.11 » C’est là que le moteur de grille sera installé et monté sur chaque nœud du système. Il est recommandé de ne pas modifier cette valeur, mais si elle l’est, elle doit être définie sur la même valeur sur chaque nœud du cluster.

CycleCloud prend en charge un ensemble standard d’attributs autostop sur les planificateurs :

Attribut	Description
cyclecloud.cluster.autoscale.stop_enabled	L’arrêt automatique est-il activé sur ce nœud ? [true/false]
cyclecloud.cluster.autoscale.idle_time_after_jobs	Durée (en secondes) pendant laquelle un nœud reste inactif après l’exécution des travaux avant sa mise à l’échelle.
cyclecloud.cluster.autoscale.idle_time_before_jobs	Durée (en secondes) pendant laquelle un nœud reste inactif avant d’effectuer des travaux avant sa mise à l’échelle.

Problèmes connus

qsh la commande pour la session interactive ne fonctionne pas. Utilisez qrsh comme alternative.
Le exclusive=1 complexe n’est pas respecté par la mise à l’échelle automatique. Par conséquent, moins de nœuds peuvent démarrer que 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 pour l’instant.

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

Configuration des ressources

L’application cyclecloud-gridengine met en correspondance les ressources sge aux ressources cloud Azure pour fournir des outils de configuration de cluster et de mise à l’échelle automatique enrichis. L’application est déployée automatiquement pour les clusters créés via l’interface utilisateur CycleCloud ou peut être installée sur n’importe quel hôte d’administration 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 mise en production. L’installation et la mise à niveau seront 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 est appelée : travaux, files d’attente, complexes. Des informations sont fournies dans stderr et stdout de la commande, ainsi que dans un fichier journal, à des niveaux configurables. Toutes les commandes de gestion gridengine avec des arguments sont également consignées dans le fichier.

Description	Emplacement
Configuration de la 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, groupes hôtes et environnements parallèles SGE

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

Lire la demande de ressource de travail et trouver une machine virtuelle appropriée pour démarrer
Démarrez la machine virtuelle et attendez qu’elle soit prête
Lire la file d’attente et l’environnement parallèle à partir du travail
En fonction de la file d’attente/pe, affectez l’hôte à un groupe hôte approprié
Ajouter l’hôte au cluster ainsi qu’à 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]

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

Sans spécifier de pe, qsub -q short.q my-script.sh la machine virtuelle résultante est ajoutée à @allhosts et @lowpriority il s’agit des groupes hôtes de la file d’attente qui ne sont pas affectés à pes.

Enfin, un travail envoyé avec qsub -q short.q -pe mpi0* 12 my-script.sh entraîne l’ajout d’une machine virtuelle à @mpihg01 ou @mpihg02 en fonction des prédictions d’allocation CycleCloud.

Les environnements parallèles correspondent implicitement au groupe de placement cyclecloud. Les machines virtuelles d’un PE sont limitées à se trouver dans le même réseau. Si vous souhaitez utiliser un PE qui ne conserve pas de groupe de placement, utilisez le fichier autoscale.json pour vous désinscrire.

Ici, nous refusons les groupes de placement pour le make pe:

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

Groupes de placement CycleCloud

Les groupes de placement CycleCloud mappent un-à-un à Azure VMSS avec SinglePlacementGroup : les machines virtuelles d’un groupe de placement partagent une infrastructure Infiniband et partagent uniquement avec des machines virtuelles au sein du groupe de placement. Pour conserver intuitivement ces silos, les groupes de placement mappent également 1:1 à l’environnement parallèle gridengine.

La spécification d’un environnement parallèle pour un travail restreindra l’exécution du travail dans un groupe de placement via la logique d’attribution de groupe hôte intelligent. Vous pouvez refuser ce comportement avec la configuration susmentionnée dans autoscale.json : "required_placement_groups" : false.

Configuration de la mise à l’échelle automatique

Ce plug-in met automatiquement à l’échelle la grille pour répondre aux demandes de la charge de travail. Le fichier de configuration autoscale.json détermine le comportement de la mise à l’échelle automatique du moteur de grille.

Définir les détails de la connexion cyclecloud
Définir le minuteur d’arrêt pour les nœuds inactifs
La mise à l’échelle automatique multidimensionnelle est possible. Définissez les attributs à utiliser dans l’empaquetage du travail, par exemple, les emplacements, la mémoire
Inscrire les files d’attente, les environnements parallèles et les groupes hôtes à gérer

Configuration	Type	Description
url	String	CC URL
nom d’utilisateur/mot de passe	String	Détails de la connexion CC
nom_cluster	String	Nom du cluster CC
default_resources	Mappage	Lier une ressource de nœud à une ressource hôte grid Engine pour la mise à l’échelle automatique
idle_timeout	Int	Temps d’attente avant l’arrêt des nœuds inactifs
boot_timeout	Int	Temps d’attente avant l’arrêt des nœuds pendant les phases de configuration longues (s)
gridengine.relevant_complexes	List (String)	Complexes de moteurs de grille à prendre en compte dans la mise à l’échelle automatique, par exemple des emplacements, des mem_free
gridengine.logging	Fichier	Emplacement du fichier de configuration de journalisation
gridengine.pes	Structure	Spécifier le comportement des PE, par exemple , requires_placement_group = false

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

Ressource de mise à l’échelle automatique supplémentaire

Par défaut, le cluster avec mise à l’échelle en fonction du nombre d’emplacements demandés par les travaux. Nous pouvons ajouter une autre dimension à la mise à l’échelle automatique.

Supposons que nous souhaitions mettre à l’échelle automatiquement la demande de ressource de travail pour m_mem_free.

Ajouter m_mem_free à dans gridengine.relevant_resourcesautoscale.json
Lien m_mem_free vers la ressource mémoire au niveau du nœud dans autoscale.json

Ces attributs peuvent être des références avec node.* comme valeur dans _default/resources.

Nœud	Type	Description
nodearray	String	Nom du nodearray cyclecloud
placement_group	String	Nom du groupe de placement cyclecloud dans un nodearray
vm_size	String	Nom du produit de machine virtuelle, par exemple « Standard_F2s_v2 »
vcpu_count	Int	Processeurs virtuels disponibles sur le nœud, comme indiqué dans les pages de produits individuelles
pcpu_count	Int	Processeurs physiques disponibles sur le nœud
mémoire	String	Mémoire physique approximative disponible dans la machine virtuelle avec un indicateur d’unité, par exemple « 8.0g »

Des attributs supplémentaires se trouvent dans l’espace node.resources.* de noms, par exemple « node.resources ».

Nœud	Type	Description
ncpus	String	Nombre de processeurs disponibles dans la machine virtuelle
pcpus	String	Nombre de processeurs physiques disponibles dans la machine virtuelle
ngpus	Integer	Nombre de GPU disponibles dans la machine virtuelle
memb	String	Mémoire physique approximative disponible dans la machine virtuelle avec un indicateur d’unité, par exemple « 8.0b »
memkb	String	Mémoire physique approximative disponible dans la machine virtuelle avec un indicateur d’unité, par exemple « 8,0 0 000 »
memmb	String	Mémoire physique approximative disponible dans la machine virtuelle avec un indicateur d’unité, par exemple « 8,0 m »
memgb	String	Mémoire physique approximative disponible dans la machine virtuelle avec un indicateur d’unité, par exemple « 8.0g »
memtb	String	Mémoire physique approximative disponible dans la machine virtuelle avec un indicateur d’unité, par exemple « 8.0t »
slots	Integer	Identique à ncpus
slot_type	String	Étiquette d’ajout pour les extensions. Non utilisé généralement.
m_mem_free	String	Mémoire libre attendue sur l’hôte d’exécution, par exemple « 3.0g »
mfree	String	Identique à _m/_mem/gratuit

Mappage des ressources

Il existe également des mathématiques disponibles pour le default_resources : réduisez de deux les emplacements sur un tableau de nœuds particulier 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
    },

Le mappage des processeurs virtuels de nœud aux emplacements complexes et memmb à mem_free sont des valeurs par défaut couramment utilisées. La première association est requise.

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

Notez que si un complexe a un raccourci différent de la valeur entière, définissez les deux dans default_resources où physical_cpu est le nom complexe :

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

Le classement est important lorsque vous souhaitez un comportement particulier pour un attribut spécifique. Pour allouer un seul emplacement à 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 programme de mise à l’échelle automatique CycleCloud, dans le but 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 correspond au compartiment cyclecloud approprié (et à la quantité de nœud) avec le 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 trouvera l’intersection des groupes hôtes qui :

Sont inclus dans le pe_list pour cloud.q et correspondent au nom pe, par exemple pe_list [@allhosts=mpislots],[@hpc1=mpi].
Disposez de ressources et d’un quota d’abonnement adéquats pour fournir toutes les ressources de travail.
Ne sont pas filtrés par la configuration des contraintes de groupe hôte.

Il est possible que plusieurs groupes hôtes répondent à ces exigences, auquel cas la logique doit choisir. Il existe trois façons de résoudre les ambiguïtés dans l’appartenance au groupe hôte :

Configurez les files d’attente afin qu’il n’y ait pas d’ambiguïtés.
Ajoutez des contraintes à autoscale.json.
Laissez CycleCloud choisir amoungst les groupes hôtes correspondants d’une manière ordonnée par nom en ajustant weight_queue_host_sort < weight_queue_seqno la configuration du planificateur.
Défini 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 hôte

Lorsque plusieurs groupes hôtes sont définis par une file d’attente ou un projet x, tous ces groupes hôtes peuvent potentiellement avoir des hôtes ajoutés. Vous pouvez limiter les types d’hôtes pouvant être ajoutés aux files d’attente en définissant des contraintes de groupe hôte. Définissez une contrainte basée sur les 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" 
            }
        },
    }
  }

CONSEIL : 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 doit être utilisé pour effectuer une mise à l’échelle automatique et a décomposé tous les sous-processus sous mise à l’échelle automatique. 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 où azge est appelé.

commandes azge	Description
validate	Vérifie les erreurs de configuration connues dans l’autoscaler ou gridengine
jobs	Affiche tous les travaux de la file d’attente
compartiments	Affiche les pools de ressources disponibles pour la mise à l’échelle automatique
nœuds	Affiche les hôtes et les propriétés du cluster
demand	Correspond aux exigences du 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 de configurations de planificateur (qconf) ou de mise à l’échelle automatique (autoscale.json), ou même lors de la première configuration, azge peut être utilisé pour vérifier que le comportement de mise à l’échelle automatique correspond aux attentes. En tant que racine, vous pouvez exécuter les opérations suivantes. Il est conseillé de se familiariser avec ceux-ci pour comprendre le comportement de mise à l’échelle automatique.

Exécutez azge validate pour vérifier les configurations pour les problèmes connus.
Exécutez azge buckets pour examiner les ressources offertes par votre cluster CycleCloud.
Exécutez azge jobs pour inspecter les détails du travail mis en file d’attente.
Exécutez azge demand la mise en correspondance du travail au compartiment, examinez quels travaux sont mis en correspondance avec quels compartiments et groupes hôtes.
Exécutez azge autoscale pour lancer le processus d’allocation de nœuds ou ajoutez des nœuds prêts à rejoindre.

Ensuite, lorsque ces commandes se comportent comme prévu, activez la mise à l’échelle automatique en cours en ajoutant la azge autoscale commande au crontab racine. (Souce the gridengine environment variables)

* * * * * . $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 d’éclatement vers le cloud. 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 = falseet gridengine.shared.bin = false en installant GridEngine localement. Pour un cas simple, vous devez fournir un système de fichiers qui peut être monté par les nœuds d’exécution qui contiennent le $SGE_ROOT répertoire et configurez ce montage dans les paramètres facultatifs. Lorsque la dépendance des répertoires sched et partagés est libérée, vous pouvez arrêter le nœud du planificateur qui fait partie du cluster par défaut et utiliser les configurations du système de fichiers externe.

Créez un cluster gridengine.
Désactivez le proxy de retour.
Remplacez /sched et /shared par des systèmes de fichiers externes.
Enregistrez le cluster.
Supprimez le nœud du planificateur en tant qu’action dans l’interface utilisateur.
Démarrez le cluster. Aucun nœud ne démarrera initialement.
Configurer cyclecloud-gridengine avec autoscale.json pour utiliser le nouveau cluster

Utilisation d’Univa Grid Engine dans CycleCloud

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

Prérequis

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

Les utilisateurs doivent fournir des fichiers binaires UGE

ge-8.6.x-bin-lx-amd64.tar.gz
ge-8.6.x-common.tar.gz

L’interface CLI CycleCloud doit être configurée. La documentation est disponible ici

Copier les fichiers binaires dans le casier 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 sur 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 , recherchez la première occurrence de et insérez du [[[configuration]]] texte de sorte qu’il corresponde à l’extrait de code ci-dessous. Ce fichier n’est pas sensible à la mise en retrait.

REMARQUE : Les détails de la configuration, en particulier la version, doivent correspondre au nom du fichier du programme 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 remplacent la version et l’emplacement d’installation par défaut de gridengine au démarrage du cluster. Il n’est pas sûr de quitter le /sched car il s’agit d’un emplacement nfs spécifiquement partagé dans le cluster.

Partager via