Regions
Rescale runs jobs in multiple cloud service provider (CSP) regions around the world. The region a job runs in determines where your compute and storage physically live, how close you are to your data, and which compliance regimes apply. This page explains how Rescale distributes jobs across regions with Region Load Balancing, how you can pin jobs to specific regions for license servers or compliance, and how regions interact with High Performance Storage (HPS).
Why region selection matters
Each CSP region has its own available capacity and its own health state. If capacity is tight in a region, your job waits longer for resources to free up, and in extreme cases the job can lose hardware after execution has already started. If a region is experiencing operational issues such as degraded hardware or a networking overload, job performance and success rate suffer even if the job starts.
You also care about regions when:
- You have data residency requirements (for example, keeping all data and compute inside a specific country or trade bloc).
- You have a compliance regime such as ITAR that requires a specific set of US government regions.
- You have a license server attached to a specific CSP region and want to keep solver traffic local.
- You have a High Performance Storage cluster already running in a region and want jobs to read from it with low latency.
How Region Load Balancing distributes jobs
Region Load Balancing (RLB) is the default behavior on every Rescale platform. It distributes compute and storage across CSP regions based on resource availability and region health, and it is available to all users.
Rescale maintains a default set of regions that compute can be distributed to, plus a dynamically calculated Capacity Health Score per region. When you submit a job, Rescale ranks the eligible regions by health and capacity and picks a region that is healthy and has room. If a region goes into a degraded state, RLB steers new jobs away from it until it recovers.
RLB helps you avoid two common failure modes:
- Queue waits. A job sitting idle because the chosen region is at capacity.
- Mid-run failures. A job losing its instance because the underlying region ran out of capacity or degraded.
Setting region preferences
You can override or augment the default RLB behavior by configuring region preferences at the user, workspace, or partner level. Rescale gives priority to the configured preferences over the default set.
Common reasons to set preferences:
- You have license servers in a specific region and want all jobs that consume that license to run there.
- You have a large workload that needs more regions than the default set in order to find capacity.
- You want to express a priority order among regions (preferred first, fallback second).
Compliance and data residency
If your organization has specific compliance such as ITAR, set your compliance level on the platform so that Region Load Balancing will not dynamically route compute to non-compliant regions. For ITAR, this typically means restricting jobs to US government regions.
Compliance settings are applied before health and capacity scoring, so a compliance restriction always wins over a "better" non-compliant region.
Region pinning with attached storage
If a job or desktop is launched with an HPS attached, the HPS must already be running, and it has its own region. With Region Load Balancing in effect, the job or desktop using the HPS is restricted to run only in the region where the HPS cluster already lives. This keeps the job's scratch and solver I/O local to the storage cluster and avoids expensive cross-region traffic.
When you plan an HPS-backed workload, pick the HPS region first and let the jobs follow. Moving the HPS later is a heavier operation than moving a single job.
Enabling Region Load Balancing
Region Load Balancing is on by default for all users. To configure region preferences, compliance settings, or a custom region list for your organization, contact Rescale Support.