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
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.
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).
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_group
complexe . 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.
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
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. |
-
qsh
la commande pour la session interactive ne fonctionne pas. Utilisezqrsh
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.
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.
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
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 |
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
}
},
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
.
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
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
à dansgridengine.relevant_resources
autoscale.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 |
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"
},
]
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.
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
.
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
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 = false
et 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
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.
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
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/
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.