Intégrez la Suite OKA à votre cluster AWS

Gérer efficacement une infrastructure HPC est complexe et souvent dépourvu des outils appropriés pour suivre et obtenir des insights sur le comportement des utilisateurs ainsi que sur la réactivité du cluster face à la demande. Cette complexité est encore accrue lors de l’utilisation de clusters Cloud. En raison de leur nature transitoire et dynamique, les informations sur les types d’instances, l’emplacement et les coûts sont des éléments importants à surveiller, surtout lorsque vous payez pour l’utilisation.

La tâche de gérer et de présenter ces métriques devient de plus en plus difficile à mesure que l’infrastructure grandit ou subit des changements au fil du temps, ce qui est une situation courante dans les environnements Cloud.

Les métriques et les informations « standard » fournies par le planificateur de tâches pourraient ne pas suffire pour gérer efficacement les clusters Cloud. Par exemple, le suivi des coûts d’exécution des tâches devient encore plus important pour surveiller et gérer votre budget, ainsi que pour redistribuer les coûts aux utilisateurs ou aux départements. En raison de la grande variété de types d’instances de calcul dans le Cloud, il peut également être intéressant de suivre sur quels types d’instances les tâches ont été exécutées, afin de vérifier leurs performances et les coûts associés, et d’améliorer davantage le placement et la sélection des instances pour les tâches.

OKA offre de nombreux avantages pour surveiller vos tâches et plonger en profondeur dans le comportement de vos clusters ainsi que dans leur utilisation par vos utilisateurs finaux. Accéder aux informations sur le Cloud dans OKA est simple, à condition d’avoir configuré votre environnement correctement. Dans cet article, nous présentons une intégration simple qui peut être réalisée dans un cluster Slurm sur AWS pour récupérer le type d’instances sur lesquelles s’exécutent les tâches, leurs informations tarifaires (à la demande/instance spot, prix par heure…), la région AWS et pratiquement toutes les informations concernant l’environnement AWS que vous utilisez.

Les scripts fournis ci-dessous sont donnés à titre d’exemples, et peuvent facilement être adaptés pour récupérer des informations plus détaillées ou pour fonctionner avec d’autres planificateurs de tâches (par exemple, LSF, PBS…).

Il existe de nombreuses façons de créer un cluster sur AWS, les détails sortent du champ d’application de cet article, mais vous pouvez par exemple utiliser AWS ParallelCluster ou CCME.

Note : la solution présentée ici est extraite de CCME où elle est disponible prête à l’emploi.

Le principe décrit ici est très simple et repose sur deux composants :

Un Slurm epilog script qui collectera des informations sur l’environnement AWS sur lequel la tâche s’exécute et stockera ces informations sous forme de valeurs séparées par des virgules (CSV) dans le champ Comment de la tâche. Les informations collectées sont les suivantes :
- instance type
- instance id of the « main » job node
- availability zone
- region
- instance price
- cost type: ondemand or spot
- tenancy: shared, reserved…
Un Data Enhancer OKA qui analysera les valeurs du champ Comment et les stockera en tant qu’informations supplémentaires pour chaque tâche.

Le principe décrit ici peut également être facilement adapté à d’autres fournisseurs Cloud. Par exemple, vous pourriez suivre les indications présentées dans l’intégration d’Azure avec Slurm présentée ici dans la section « Granular Cost Control ».

Script Slurm epilog

Ce script Slurm epilog récupère des informations sur le type d’instance et son tarif lorsque la tâche se termine, et stocke les informations dans le champ Comment de la tâche dans sacct. Les commentaires fournis par l’utilisateur sont conservés, et les informations sont ajoutées à la fin après un point-virgule. Le format du champ Comment est le suivant :

Copy to clipboard

Les packages suivants sont nécessaires et doivent être disponibles sur chaque noeud du cluster :

jq
awscli

Notez également que cette solution nécessite que Slurm soit configuré pour conserver des informations comptables sur les tâches. Consultez la documentation Slurm pour configurer la comptabilité manuellement, ou si vous utilisez AWS ParallelCluster, vous pouvez suivre ce guide ce guide.

Lorsque l’epilog script contacte les API AWS pour collecter les informations, il doit s’exécuter sur des instances ayant (au minimum) la politique suivante attachée au rôle de l’instance:

Copy to clipboard

Script

Copy to clipboard

#!/bin/bash
declare logFile="/var/log/ccme.slurmepilog.log"
touch "${logFile}"; chmod -v 600 "${logFile}"
exec  > >(awk '{printf "[%s] %s\n", strftime("%FT%T%z"), $0; fflush()}' >>"${logFile}" || true)
exec 2>&1;
# Uncomment the following line for debug traces
#set -x

slurm_env="/opt/slurm/etc/slurm.sh"
if [[ -f "${slurm_env}" ]]; then
  # shellcheck source=/dev/null
  . "${slurm_env}"
fi

declare -A regions
regions["af-south-1"]="Africa (Cape Town)"
regions["ap-east-1"]="Asia Pacific (Hong Kong)"
regions["ap-east-1"]="Asia Pacific (Hong Kong)"
regions["ap-northeast-1"]="Asia Pacific (Tokyo)"
regions["ap-northeast-2"]="Asia Pacific (Seoul)"
regions["ap-south-1"]="Asia Pacific (Mumbai)"
regions["ap-south-2"]="Asia Pacific (Hyderabad)"
regions["ap-southeast-1"]="Asia Pacific (Singapore)"
regions["ap-southeast-2"]="Asia Pacific (Sydney)"
regions["ap-southeast-3"]="Asia Pacific (Jakarta)"
regions["ap-southeast-4"]="Asia Pacific (Melbourne)"
regions["ca-central-1"]="Canada (Central)"
regions["eu-central-1"]="EU (Frankfurt)"
regions["eu-central-2"]="Europe (Zurich)"
regions["eu-north-1"]="EU (Stockholm)"
regions["eu-south-1"]="Europe (Milan)"
regions["eu-south-2"]="Europe (Spain)"
regions["eu-west-1"]="EU (Ireland)"
regions["eu-west-2"]="EU (London)"
regions["eu-west-3"]="EU (Paris)"
regions["me-central-1"]="Middle East (UAE)"
regions["me-south-1"]="Middle East (Bahrain)"
regions["sa-east-1"]="South America (Sao Paulo)"
regions["us-east-1"]="US East (N. Virginia)"
regions["us-east-2"]="US East (Ohio)"
regions["us-west-1"]="US West (N. California)"
regions["us-west-2"]="US West (Oregon)"

# Gather Information about job environment on AWS
TOKEN=$(curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")
insttype=$(curl -s -H "X-aws-ec2-metadata-token: ${TOKEN}" -v http://169.254.169.254/latest/meta-data/instance-type)
instid=$(curl -s  -H "X-aws-ec2-metadata-token: ${TOKEN}" -v http://169.254.169.254/latest/meta-data/instance-id)
az=$(curl -s -H "X-aws-ec2-metadata-token: ${TOKEN}" -v http://169.254.169.254/latest/meta-data/placement/availability-zone)
region=$(curl -s -H "X-aws-ec2-metadata-token: ${TOKEN}" -v http://169.254.169.254/latest/dynamic/instance-identity/document | jq -r .region || true)

# We try to detect if we use spot through AWS APIs
# https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-purchasing-options.html#check-instance-lifecycle
# Use the following describe-instances command:
# aws ec2 describe-instances --instance-ids i-1234567890abcdef0
# - If the instance is running on a Dedicated Host, the output contains the following information: "Tenancy": "host"
# - If the instance is a Dedicated Instance, the output contains the following information: "Tenancy": "dedicated"
# - If the instance is a Spot Instance, the output contains the following information: "InstanceLifecycle": "spot"
# - If the instance is a Scheduled Instance, the output contains the following information: "InstanceLifecycle": "scheduled"
# - Otherwise, the output does not contain InstanceLifecycle.
lifecycle=$(aws --region="${region}" ec2 describe-instances --instance-ids "${instid}" | jq -r ".Reservations[0].Instances[0].InstanceLifecycle" || true)
tenancy=$(aws --region="${region}" ec2 describe-instances --instance-ids "${instid}" | jq -r ".Reservations[0].Instances[0].Placement.Tenancy" || true)

costtype="ondemand"  # Default value
if [[ "${lifecycle}" == "spot" ]]; then
  costtype="spot"
elif [[ "${lifecycle}" == "" ]]; then
  costtype="ondemand"
fi

# Get instance price
if [[ "${costtype}" == "ondemand" ]]; then
  if [[ "${tenancy}" == "default" ]]; then
    tenancy="shared"
  fi

filters=(
  "Type=TERM_MATCH,Field=instanceType,Value=${insttype}"
  "Type=TERM_MATCH,Field=location,Value=${regions[${region}]}"
  "Type=TERM_MATCH,Field=operatingSystem,Value=Linux"
  "Type=TERM_MATCH,Field=preInstalledSw,Value=NA"
  "Type=TERM_MATCH,Field=capacitystatus,Value=Used"
  "Type=TERM_MATCH,Field=tenancy,Value=${tenancy}"
  )
  # Warning: if tenancy==host (reserved), then the price will be $0.00
  instprice=$(aws --region=us-east-1 pricing get-products --service-code AmazonEC2 --filter "${filters[@]}" | jq -rc '.PriceList[0]' | jq -r '[.terms.OnDemand[].priceDimensions[].pricePerUnit.USD][0]' || true)
elif [[ "${costtype}" == "spot" ]]; then
  instprice=$(aws --region "${region}" ec2 describe-spot-price-history --availability-zone "${az}" --instance-types "${insttype}" --start-time "$(date '+%Y-%m-%dT%H:%M:%S')" --product-descriptions "Linux/UNIX" | jq -r '.SpotPriceHistory[0].SpotPrice' || true)
else
  # Currently we do not manage other types of pricing
  instprice=0
fi

# shellcheck disable=SC2154
comment=$(scontrol show job "${SLURM_JOBID}" | grep 'Comment=' | awk -F'Comment=' '{print $2}' || true)
comment+=":PricingInfo=${insttype};${instid};${az};${region};${instprice};${costtype};${tenancy}"

echo "Setting comment for job ${SLURM_JOBID}: ${comment}"

sacctmgr -i -Q modify job where JobID="${SLURM_JOBID}" set Comment="${comment}"

Installation

Copiez le script epilog sur un dossier accessible par tous les noeuds, e.g., /shared_nfs/slurm/slurm-epilog.sh, et donnez lui des droits d’exécution: chmod +x /shared_nfs/slurm/slurm-epilog.sh
Editez /etc/slurm/slurm.conf (sur tous les noeuds), et paramétrez l’option Epilog en /shared_nfs/slurm/slurm-epilog.sh
Reconfigurez les daemons Slurm : scontrol reconfigure, ou redémarrez-les: systemctl restart slurmd

Ensuite soumettez un job. Une fois terminé, vérifiez que l’output de sacct dans le champs Comment est bien l’output attendu : sacct --format "jobid,comment".

OKA Data Enhancer

Un Data Enhancer doit être créé et configuré dans OKA afin de traiter les données supplémentaires collectées par le script d’épilogue Slurm. Nous proposons ici un exemple de Data Enhancer que vous pouvez adapter à vos besoins (le commentaire inclus la génération de données « fictives » si vous souhaitez d’abord le tester) :

Copy to clipboard

import logging
    import numpy as np

logger = logging.getLogger("oka_main")

class EnhancerAWSSLURMFeature():
        VERSION = "1.0.0"

def parse_comment(comment):
            # :pricinginfo=${instance type};${instance id};${availability zone};${region};${price};${spot|ondemand};{tenancy}
            # e.g., :pricinginfo=c5n.18xlarge;i-0cd3c13fa4599d4d5;eu-west-1b;eu-west-1;1.241400;spot;shared
            scsv = comment.split(':pricinginfo=')[1].split(';')
            insttype = scsv[0]
            instid = scsv[1]
            az = scsv[2]
            region = scsv[3]
            instprice = float(scsv[4]) if scsv[4].lower() not in ["na", "nan"] else 0.0
            costtype = scsv[5]
            tenancy = scsv[6]
            return insttype, instid, az, region, instprice, costtype, tenancy

def run(self, data, **kwargs):
            try:
                # Uncomment the following lines for testing with fake data
                # from random import random, randint
                # azs = [["a", "b", "c"][randint(0,2)] for y in range(len(data))]
                # prices = [random() for y in range(len(data))]
                # inst = [["c5n.18xlarge", "c5n.9xlarge", "c5n.4xlarge", "c5.4xlarge", "g4dn.8xlarge"][randint(0,4)] for y in range(len(data))]
                # data.loc[:, "Comment"] = ["comment:pricinginfo={};id12;eu-west-1{};eu-west-1;{};spot;shared".format(inst[x], azs[x], prices[x]) for x in range(len(data))]

# Fill missing values with a set of default values
                data["Comment"].fillna(":pricinginfo=NA;NA;NA;NA;0;ondemand;shared", inplace=True)

data.loc[:, "instance_type"], data.loc[:, "instance_id"], data.loc[:, "availability_zone"], data.loc[:, "region"], instprice, data.loc[:, "price_type"], data.loc[:, "tenancy"] = zip(*data["Comment"].apply(EnhancerAWSSLURMFeature.parse_comment))

duration = (data["End"].astype(np.datetime64) - data["Start"].astype(np.datetime64)).astype('timedelta64[s]')/3600.0
                data.loc[:, "Cost"] = instprice * duration * data["Allocated_Nodes"]

except Exception as e:
                logger.error(f"Cost information not available: {e}")

Installation

Veuillez vous référer à la section Data Enhancer pour des explications sur la manière d’installer et de configurer ce Data Enhancer dans le pipeline d’ingestion.

Accédez à vos informations AWS dans OKA

Les informations récupérées via le Data Enhancer sont ensuite disponibles dans OKA à travers plusieurs plugins et filtres.
Nous présentons ci-dessous quelques exemples d’endroits où les informations peuvent être consultées et utilisées pour analyser vos charges de travail :

AWS costs in KPI

Filters allow to select workloads based on the information gathered from AWS.

Detailed information in Plugin Consumers

Cost per job status in Plugin State to detect waste.

Conclusion

Cet article a présenté une approche d’intégration simple pour un cluster Slurm sur AWS. En exploitant un script d’épilogue Slurm et un Data Enhancer OKA, des informations précieuses sur l’environnement AWS peuvent être récupérées et analysées.

En utilisant les informations AWS intégrées dans OKA, les administrateurs ont accès à divers plugins et filtres pour analyser et visualiser les charges de travail. Cela permet une meilleure gestion des coûts, un contrôle plus granulaire et l’identification de pratiques inefficaces.

Dans l’ensemble, l’intégration d’un cluster AWS avec OKA permet aux administrateurs d’optimiser leur infrastructure HPC, d’obtenir des informations sur l’utilisation des ressources et les coûts, et de prendre des décisions basées sur les données pour une gestion efficace des clusters dans les environnements cloud.