Choose an orchestrator

This document explains how to choose between Slurm orchestration and managed compute orchestration when you create a cluster in Cluster Director.

An orchestrator is the system that coordinates individual Compute Engine instances so that they operate as a single cluster to run your workloads. In Cluster Director, your choice of orchestrator defines the following aspects of your cluster:

  • Node organization and lifecycle: how Cluster Director groups, starts, scales, and replaces the compute instances in your cluster.

  • Workload execution: how you connect to the cluster, submit jobs, and allocate compute, memory, and accelerator resources to each task.

  • Software and storage setup: which operating system (OS) images run on your nodes and how shared storage mounts across the cluster.

Compare orchestrators

When you create a cluster in Cluster Director, you choose either Slurm orchestration or managed compute orchestration. The following table compares the two orchestration options:

Feature Slurm orchestration Managed compute orchestration
Target audience AI researchers, high performance computing (HPC) engineers, and IT administrators who support multiple users on a shared cluster and want a ready-to-use job scheduler. Machine learning (ML) platform engineers who run their own orchestrator, and researchers who run dedicated distributed workloads on compute instances.
Primary use case Multi-user clusters that need a managed job queue, priority-based job placement, and dynamic scaling of idle nodes. Clusters that run a custom scheduler (such as Ray or HTCondor) or launch distributed workloads (such as JAX, MaxText, or MPI) on compute instances by using SSH.
Control plane and login nodes Provisions a managed Slurm controller node and one or more login nodes. Doesn't provision a Slurm controller or login nodes. You connect to compute instances in the managed instance group (MIG) by using SSH.
Compute node organization Organizes compute nodes into Slurm partitions and nodesets with staticNodeCount and maxDynamicNodeCount. Each nodeset uses a single machine type, and a cluster can include multiple nodesets and partitions with different machine types. Organizes compute nodes into zonal MIGs with a configurable targetSize. Each MIG uses a single machine type, and a cluster can include multiple MIGs with different machine types.
Supported machine series
  • GPU: A4X Max, A4X, A4, A3 Ultra, A3 Mega, G4
  • TPU: TPU7x, TPU v6e, TPU v5p
  • CPU: C4A1, H4D, N2
  • GPU: A4X Max, A4X, A4, A3 Ultra, A3 Mega, G4
  • TPU: TPU7x, TPU v6e, TPU v5p
  • CPU: H4D, N2
Scaling behavior Scales compute nodes between staticNodeCount and maxDynamicNodeCount based on pending jobs in the Slurm queue, and deletes dynamic nodes after five minutes in an idle state. Maintains the number of compute instances specified by targetSize in each MIG, or queues a MIG resize request.
Shared network storage Requires a Filestore or Google Cloud Managed Lustre instance mounted in the /home directory across all nodesets and login nodes. Network storage is optional. Each MIG can mount any combination of Filestore instances, Managed Lustre instances, or Cloud Storage buckets (including in the /home directory), with 30-second mount updates that don't restart compute instances.
Additional block storage Supports standalone boot disks and Google Cloud Hyperdisk storage pools for boot disks. Supports standalone boot disks and read-write additional disks for each compute instance.
OS images Uses Slurm OS images (-slurm-) that include Slurm daemons, Enroot, Pyxis, and Open MPI. Uses non-Slurm OS images (-ce-) or custom OS images without Slurm daemons or Enroot.
Pre-configured AI and HPC templates Yes Yes

1 You can only use the C4A machine series for login nodes in Slurm clusters.

Choose an orchestrator

To choose the orchestrator that fits your cluster and workload requirements, answer the following questions:

  1. Do you want Cluster Director to provide a built-in job scheduler, login nodes, and a central job queue so that multiple users can share the cluster?

  2. Do you want Cluster Director to set up the cluster infrastructure while you run your own scheduler (such as Ray or HTCondor) or launch jobs by using SSH?

  3. Do you want the cluster to create and delete compute nodes based on pending jobs in a queue, or maintain a fixed number of compute instances that you resize on demand?