SOLUTIONS — Multi On-Premise

Federate every cluster you operate. Schedule like one.

Unified control plane across campuses, business units, or hardware vendors. Heterogeneous GPUs scheduled as one pool. Zero-downtime live migration when capacity tightens.

Get the Federation Architecture Guide → Read Documentation

2×+

GPU pool expansion

−50%

idle resources

0

single-cluster SPOF

< 5s

live migration handoff

Recommended For

For organizations that already have GPUs in more than one place.

If your AI lab spans a headquarters and a branch campus, or if your enterprise has data centres in two regions, Multi On-Premise consolidates them into a single virtual GPU pool — without moving hardware.

• Multi-campus universities (e.g. main + medical school + engineering branch)
• Mid-to-large research institutions with siloed compute by department
• Mid-sized AI enterprises with HQ + regional ops + DR site
• Government and defence research labs requiring heterogeneous-vendor procurement

Typical environment

GPU pool	32 to 256 GPUs
Clusters	2 to 8
GPU mix	NVIDIA + AMD, mixed gen
Inter-cluster link	InfiniBand or RDMA over Ethernet
Storage	Shared NFS / Ceph + local NVMe
Topology	HQ + branches or HA pair

Federation Architecture

One control plane. Many clusters.

The Federated Orchestrator runs on a small dedicated control-plane node and manages every connected cluster as a peer. Workloads are scheduled globally; they are placed locally.

Federated Multi-Cluster Architecture

Multi On-Premise — federated architecture diagram

Click the diagram to view full resolution.

                          ┌────────────────────────────────────────┐
                          │   UNIFIED CONTROL PLANE                │
                          │   (Federated Orchestrator)             │
                          │                                        │
                          │  ┌──────────┐  ┌──────────────────┐    │
                          │  │ Global   │  │ Federation Mgr   │    │
                          │  │Scheduler │  │ membership +     │    │
                          │  │priority  │  │ heartbeat        │    │
                          │  │+ deadline│  └────────┬─────────┘    │
                          │  └────┬─────┘           │              │
                          │       │  ┌──────────────▼──────────┐   │
                          │       │  │ Live Migration Engine   │   │
                          │       │  │ checkpointless handoff  │   │
                          │       │  └─────────────────────────┘   │
                          │       │                                │
                          │  ┌────▼──────────────────────────┐     │
                          │  │ Unified Policy Engine         │     │
                          │  │ RBAC · quota · audit · SLO    │     │
                          │  └───────────────────────────────┘     │
                          └────────────┬───────────────────────────┘
                                       │  InfiniBand / RDMA / VPN
              ┌────────────────────────┼─────────────────────────┐
              │                        │                         │
   ┌──────────▼───────────┐  ┌─────────▼──────────┐  ┌───────────▼──────────┐
   │ Cluster A            │  │ Cluster B          │  │ Cluster C  (DR)       │
   │ NVIDIA H100 / A100   │  │ NVIDIA L40S / A40  │  │ AMD MI250 / MI300     │
   │ 64 GPUs              │  │ 32 GPUs            │  │ 32 GPUs               │
   │ training + eval      │  │ inference + dev    │  │ standby / failover    │
   └──────────────────────┘  └────────────────────┘  └────────────────────────┘

Workload Routing

The right cluster for the right job.

Global Scheduler considers GPU type, network distance, data locality, queue depth, and policy. You declare intent; CNLab decides placement.

Large-scale Training

→ Cluster A (H100)

Multi-GPU jobs with high memory bandwidth go to the H100 cluster. Adjacent slices on the same NVLink fabric are preferred.

Lightweight Experiments

→ Cluster B (L40S)

Hyperparameter sweeps and student notebooks land on L40S. Faster start, better cost per experiment.

Inference Workloads

→ Cluster B (A40)

Stable, low-latency inference on A40. Pinned per-tenant for predictable tail latency.

Cluster A Overloaded

→ Auto Live Migration to B

When A's queue depth crosses threshold, in-flight jobs migrate to compatible B nodes. No checkpoint, no restart, no user-visible change.

Integrated Technologies

Built on open infrastructure.

🚄

InfiniBand & RDMA

Inter-cluster connectivity at 200+ Gb/s. Live migration uses RDMA-direct transfers — pages move without crossing the kernel TCP stack.

🤝

Heterogeneous GPU

NVIDIA H100/A100/L40S and AMD MI250/MI300 co-managed. The scheduler knows each device's compute capability and FP precision support.

💾

Shared Storage

Mount the same NFS or Ceph volumes across clusters. Datasets and checkpoints are cluster-agnostic; users never re-upload.

🔐

Unified RBAC

A single role assignment applies across every federated cluster. Permission changes propagate in seconds, not deploys.

📊

Cluster-aware Quota

Quotas can be global (any cluster) or local (specific cluster). Mix and match per project.

🛰️

DR Failover

When a cluster goes offline, scheduler reroutes. Stateful services migrate with their pods. Zero manual intervention.

Live Migration Deep Dive

Zero-downtime workload mobility.

Live migration is the differentiator. Other federation tools require checkpoint-restart on relocation. CNLab does it without checkpointing — the GPU's memory, kernels, and CUDA contexts move atomically.

PHASE 1

Pre-copy

Memory pages copied over RDMA while the source job continues. Dirty pages tracked for the next round.

PHASE 2

Stop-and-copy

Source pauses for sub-second window. Final pages and CUDA context flushed to target.

PHASE 3

Resume

Target resumes from exact instruction. End-user sees no interruption beyond a single batch lag.

FAQ

Five questions before you federate.

How many clusters can I federate?

Up to 16 in a single federation. Beyond 16, customers typically partition by region with a federation-of-federations topology.

What's the WAN latency requirement?

Sub-50 ms one-way is recommended for live migration. Above that, jobs run cluster-local; only scheduling decisions cross the WAN.

Can clusters run different OS versions?

Yes. Each cluster is independent. CNLab compatibility matrix supports Ubuntu 22.04+, RHEL 8+, and Rocky 9.

What happens if the federation control plane fails?

Each cluster keeps running with its last-known scheduler state. New cross-cluster scheduling pauses; in-cluster work is unaffected. The control plane is HA by default.

Does live migration work across vendors?

Across NVIDIA generations, yes. NVIDIA-to-AMD requires checkpoint/restart and is treated as a stop-the-world migration with user opt-in.

Federate Your GPUs in 14 Days.

Free 60-minute architecture review with our federation specialist. We'll bring a topology diagram for your specific clusters.

Book Architecture Review →