2 — Big Compute / High Performance Compute (AZ-305)

A. Decision tree HPC / Batch AZ-305 ⭐⭐

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 ⭐

🎯 "Minimiser le coût d'un batch tolérant aux interruptions" → Spot.

B.4 Use cases typiques

Burst rendering (films) · genomics · simulation risque finance (Monte Carlo / VaR) · transcoding vidéo · ML training distribué · CFD/FEA (ANSYS, OpenFOAM).

C. Embarrassingly parallel vs Tightly-coupled (MPI) ⭐⭐

LE piège exam 305. Distinguer ces 2 patterns détermine la VM et le réseau requis.

🎯 Mots-clés tightly-coupled : MPI, CFD, FEA, training distribué multi-nodes, PyTorch DDP, Horovod → VM HB/HC/HX/ND + InfiniBand + Proximity Placement Group.

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

🎯 Mémo 305 :

• "Greenfield batch parallel Azure-native" → Batch
• "Migration HPC on-prem, scripts Slurm/PBS inchangés" → CycleCloud
• "Burst hybride dynamique" → CycleCloud

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 : NDv5 (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 ~256) sur le Pool pour exécuter N tasks parallèles sur le même node si CPU multi-core (default = 1 task/node).

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

🎯 Vraie valeur CycleCloud = sbatch / qsub inchangés depuis on-prem.