Lire en anglais

Partager via


CycleCloud GridEngine Cluster

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]

Notes

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.

Notes

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.

  1. Lire la demande de ressource de travail et trouver 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 à partir du travail
  4. En fonction de la file d’attente/pe, affectez l’hôte à un groupe hôte approprié
  5. 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.

  1. Ajouter m_mem_free à dans gridengine.relevant_resourcesautoscale.json
  2. 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_resourcesphysical_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 :

  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 et d’un quota d’abonnement adéquats pour fournir toutes les ressources de travail.
  3. 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 :

  1. Configurez les files d’attente afin qu’il n’y ait pas d’ambiguïtés.
  2. Ajoutez des contraintes à autoscale.json.
  3. 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.
  4. 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.

  1. Exécutez azge validate pour vérifier les configurations pour les problèmes connus.
  2. Exécutez azge buckets pour examiner les ressources offertes par votre cluster CycleCloud.
  3. Exécutez azge jobs pour inspecter les détails du travail mis en file d’attente.
  4. 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.
  5. 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.

  1. Créez un cluster gridengine.
  2. Désactivez le proxy de retour.
  3. Remplacez /sched et /shared par des systèmes de fichiers externes.
  4. Enregistrez 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émarrera initialement.
  7. 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.

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