2 — Big Compute / High Performance Compute

Calcul intensif et traitement par lots (Big Compute / HPC) → Azure Batch pour jobs parallèles greenfield, CycleCloud pour le burst hybride d'un HPC on-prem existant.

A. Decision tree HPC / Batch

Quel type de workload batch / HPC ?
├─ Jobs parallèles managés, greenfield Azure-native
│   └─ Azure Batch (default 305 pour batch)
│
├─ Lift-and-shift HPC on-prem (scripts Slurm/PBS/LSF inchangés)
│   └─ Azure CycleCloud (burst hybride on-prem ↔ Azure)
│
├─ Containers event-driven simples
│   └─ Azure Container Apps Jobs (fiche 3)
│
├─ Containers + orchestration complexe (DAG, workflows)
│   └─ AKS + Argo Workflows (fiche 3)
│
├─ Big Data Spark / SQL
│   └─ Databricks / Synapse (fiche 10)
│
└─ Workflows multi-étapes orchestration métier
    └─ Data Factory / Logic Apps / Durable Functions (fiches 10/5/1)

B. Azure Batch

B.1 C'est quoi

Service managé pour exécuter des jobs parallèles à grande échelle (rendering, simulations, ML training, encoding). MS gère le scheduling, scaling, retry.

B.2 Architecture

Batch Account (point d'entrée régional)
  ├─ Pool  = groupe de N VMs (autoscale possible, réutilisable)
  └─ Job   = container de tasks (pointe vers 1 pool)
        └─ Tasks = les unités de travail, distribuées sur les VMs du pool

💡 1 Pool peut servir N Jobs (persistant). 1 Job pointe vers 1 Pool.

Pourquoi paralléliser : 1000 images × 10s → séquentiel = ~3h ; sur 100 nodes = ~100s (100× plus rapide). Batch distribue automatiquement + retry sur échec.

B.3 Coût — Spot vs Dedicated

C. Embarrassingly parallel vs Tightly-coupled (MPI)

Distinguer ces 2 patterns détermine la VM et le réseau requis.

D. HPC Storage (Awarness)

E. CycleCloud — l'option lift-and-shift

Orchestrateur de clusters HPC (Slurm, PBS Pro, LSF, Grid Engine, HTCondor) sur Azure → réutilise les scripts HPC on-prem sans les réécrire.

🏢 Scénarios d'entreprise (CAF/WAF)

Scénario 1 : Finance / Risk — calcul VaR overnight Monte Carlo

Contexte business : Une banque recalcule chaque nuit le risque (Value-at-Risk) de ses portefeuilles : des millions de simulations indépendantes, à finir en 4h avant l'ouverture des marchés. Récurrent, élastique, budget compute serré. Choix architectural : Azure Batch (tâches indépendantes = loosely coupled). Pool majoritairement Spot pour le coût, avec un socle Dedicated pour tenir le délai. Architecture / pattern :

• Pool de VM compute-optimisées F-series — pas d'InfiniBand (les tâches ne se parlent pas).
• Mix : ex. 20 % Dedicated (garantit le délai) + 80 % Spot (-90%).
• taskSlotsPerNode réglé pour exploiter tous les cœurs d'un node.
• Données sur Blob ; checkpoint des longues tâches (éviction Spot = requeue auto). Trade-offs assumés :
• Gain : facture compute fortement réduite, élasticité, délai tenu par le socle dédié.
• Perte : gestion des évictions (checkpoint), part Spot non garantie en capacité. Pièges à éviter :
• Tout-Spot sans socle dédié → risque de rater la fenêtre nocturne si éviction massive.
• Croire que Spot Batch accepte un max price : faux, éviction pour capacité uniquement.
• Ajouter des nodes au lieu d'augmenter taskSlotsPerNode → gaspillage. 📐 Réf. CAF/WAF — WAF HPC, Design methodology (workload coupling) : Monte Carlo VaR = loosely coupled → networking standard + ressources cost-efficient/scalables, réserver le haut de gamme là où il apporte un gain réel. Lien

Scénario 2 : Énergie / Oil & Gas — simulation de réservoir MPI

Contexte business : Un pétrolier simule des réservoirs : modèles MPI où les 32 nodes échangent en continu (tightly coupled), runs de plusieurs jours. C'est la vitesse du réseau inter-nodes qui dicte le temps de calcul. Pas d'infra on-prem à garder. Choix architectural : Azure Batch (greenfield) + VM HPC InfiniBand + Proximity Placement Group (nodes collés pour une latence minimale). Architecture / pattern :

• VM HBv4 (InfiniBand 400 Gb/s) ou HX si gros besoin mémoire/cache. Éviter HC (retraite 31 mai 2027).
• Inter-node communication : Enabled + PPG pour co-localiser les nodes.
• Scratch parallèle haut débit : Azure Managed Lustre (AMLFS) ; datasets durables sur Blob.
• Nodes Dedicated : le Spot est exclu (1 éviction casse tout le job MPI). Trade-offs assumés :
• Gain : scaling MPI efficace, temps de calcul réduit, débit storage soutenu.
• Perte : coût élevé (HBv4 + AMLFS + Dedicated), aucune économie Spot possible. Pièges à éviter :
• Spot sur un job MPI → une seule éviction invalide tout le run.
• Oublier le PPG → nodes dispersés, latence inter-node dégradée.
• Choisir HC (retraité) au lieu de HBv4/HX/HBv5. 📐 Réf. CAF/WAF — WAF HPC, Performance Efficiency (interconnect & topology) : workloads tightly coupled sensibles à latence/bande passante → VM InfiniBand (HB/HX/ND) + Proximity Placement Groups + storage parallèle (Lustre) pour éviter les goulots. Lien

Scénario 3 : Manufacturing / Recherche — lift-and-shift cluster Slurm avec burst hybride

Contexte business : Un équipementier auto a un cluster CFD/crash on-prem piloté par Slurm (scripts sbatch matures, équipe HPC). Capacité saturée aux pics de projet. Objectif : absorber les pics sans réécrire les jobs ni tout migrer. Choix architectural : Azure CycleCloud (orchestration Slurm) en cloud bursting on-prem ↔ Azure → les jobs débordent vers Azure, scripts inchangés. Architecture / pattern :

• CycleCloud Server (Marketplace) pilote un cluster Slurm et autoscale les node arrays.
• Nodes en HBv4 InfiniBand ; Interruptible = true (Spot) pour les jobs loosely coupled tolérants.
• Connexion hybride par VPN/ExpressRoute, sans IP publique. Trade-offs assumés :
• Gain : zéro réécriture (mêmes scripts/scheduler), élasticité de pic, gouvernance par l'admin.
• Perte : complexité hybride (réseau, déplacement de données, identité), latence si un job MPI est étalé entre régions. Pièges à éviter :
• Choisir Batch ici → Batch impose son modèle API/SDK (réécriture). Lift-and-shift Slurm/PBS → CycleCloud.
• Étaler un job MPI tightly coupled sur plusieurs régions → latence dégradée.
• Mettre du Spot sur les phases tightly coupled ; le réserver aux post-traitements loosely coupled. 📐 Réf. CAF/WAF — CAF, scénario HPC (HPC landing zone accelerator) : modèle hybride/cloud-bursting via CycleCloud avec topologie réseau, identité et gouvernance alignées Azure landing zones. Lien

DEMO

Demo Portail — Azure Batch Account + Pool + Job

1. Créer le Batch Account :

   • Batch accounts > + Create
   • Subscription / RG / Account name batchrenderprod (FQDN unique)
   • Region (proche du Storage)
   • Storage account : + Select existing ou créer stbatchrender
   • Pool allocation mode : Batch service (default, recommandé)
   • Identity : System assigned managed identity : On
   • Review + create

2. Créer un Pool :

   • batchrenderprod > Pools > + Add
   • Pool ID : pool-render-gpu
   • Image type : Marketplace → Publisher microsoft-azure-batch → Offer ubuntu-server-container (ou autre)
   • VM size : ND H100 v5 (GPU H100 pour ML) ou HBv4 (CFD MPI) ou F4s_v2 (CPU general)
   • Target dedicated nodes : 4 (ou 0 si all-Spot)
   • Target Spot/low-priority nodes : 10 (économie -90%)
   • Inter-node communication : Enabled (obligatoire pour MPI tightly-coupled)
   • Network configuration : VNet existant + subnet (optionnel pour isolation)
   • OK → Pool en Resizing puis Steady

3. Créer un Job + Tasks :

   • batchrenderprod > Jobs > + Add
   • Job ID : render-job-001
   • Pool : pool-render-gpu
   • OK
   • Dans le Job : + Add task → command line python render.py --frame 1
   • Ajouter N tasks (1 par frame, par exemple) — Batch distribue auto sur les nodes du pool

💡 Multi-task per node : configurer taskSlotsPerNode (max = min(4 × cores, 256), donc 32 sur un node 8 cores) sur le Pool pour exécuter N tasks parallèles sur le même node si CPU multi-core (default = 1 task/node ; modifiable seulement à la création du pool).

Demo (CLI light) — CycleCloud cluster Slurm

# Pre-req : VM CycleCloud Server provisionnée (Marketplace)
# Sur la VM CycleCloud, via Web UI ou CLI :

# 1. Import un cluster template Slurm
cyclecloud import_cluster slurm -f templates/slurm.txt -c MySlurmCluster

# 2. Configurer (sub, region, VNet, SKUs nodes head/exec, Spot)
cyclecloud edit_cluster MySlurmCluster

# 3. Démarrer le cluster
cyclecloud start_cluster MySlurmCluster

# 4. SSH sur le head node, soumettre un job standard Slurm
ssh cycle-admin@head-node-ip
sbatch my_existing_onprem_job.sh  # script Slurm INCHANGÉ
squeue