Multi-Region Deployment

Note

Proxy groups are an Enterprise-only feature.

This guide covers deploying flexFS across multiple cloud regions with proxy groups acting as regional edge caches. This architecture reduces cross-region data transfer costs and latency for read-heavy workloads.

Architecture Overview

In a multi-region deployment:

1. Metadata and block storage reside in a primary region (e.g., us-east-1).
2. Proxy groups are deployed in each compute region to cache block data locally.
3. Mount clients automatically select the lowest-latency proxy group via RTT probing.

Step 1: Register the Additional Regions

The Enterprise installer already registered the provider and primary region, the block store, the meta store, and the volume, plus a proxy group for the primary region if you chose to set one up. Register only the satellite regions:

configure.flexfs create region --providerCode aws --code eu-west-1 --name "EU West (Ireland)"
configure.flexfs create region --providerCode aws --code ap-southeast-1 --name "Asia Pacific (Singapore)"

If a satellite region belongs to a provider that is not registered yet, create the provider first with configure.flexfs create provider. Creating a provider or region that already exists fails with a 409 conflict.

Step 2: Use the Existing Stores and Volume

Block data and metadata stay in the primary region, so the block store, meta store, and volume the installer created are used as they are, and no new stores are needed. To look up the volume name, run:

configure.flexfs list volumes

Step 3: Deploy Proxy Servers

Deploy proxy.flexfs in each satellite region. On each proxy host that needs static block storage credentials (see Proxy Server Setup), initialize them as root, since the systemd service below runs as root:

sudo proxy.flexfs init creds --blockUser <username> --blockPass <password>

Then install and start the proxy server as a systemd service:

sudo proxy.flexfs init systemd
sudo manage.flexfs start proxy

The systemd service is optional: proxy.flexfs start can also be run directly by any user (see Run the proxy server).

Step 4: Create Proxy Groups

Create a proxy group for each satellite region. Each command reports the new group’s ID (for example, Created proxy group id=2):

configure.flexfs create proxy-group \
  --providerCode aws --regionCode eu-west-1 \
  --addresses proxy-eu-1.example.com:443,proxy-eu-2.example.com:443

configure.flexfs create proxy-group \
  --providerCode aws --regionCode ap-southeast-1 \
  --addresses proxy-ap-1.example.com:443

Step 5: Associate Proxy Groups with Volumes

Use the IDs reported in Step 4:

configure.flexfs create volume-proxy-group \
  --volumeID <volume-name> --proxyGroupID <eu-proxy-group-id>

configure.flexfs create volume-proxy-group \
  --volumeID <volume-name> --proxyGroupID <ap-proxy-group-id>

Step 6: Mount

Mount clients in any region will automatically:

1. Discover all proxy groups associated with the volume.
2. Measure RTT to every server of each group; a group’s RTT is that of its slowest server.
3. Select the lowest-latency group among those whose servers all answer within 125 ms.
4. Fall back to direct object storage if no group answers in time.

mount.flexfs start <volume-name> /mnt/flexfs

Considerations

• Write path: Writes always go to the primary block store. Proxy groups serve reads from cache and perform writeback for writes.
• Cache warming: The first read of a block in a new region goes to object storage. Subsequent reads are served from the proxy cache.
• Dynamic membership: You can add or remove proxy addresses from a group while mounts are active. The change reaches connected mount clients without a remount, and each one re-probes and re-selects its group when it arrives.
• Multiple proxies per group: Deploy multiple proxy servers in a single group for cache capacity and throughput. Each block is routed to one member, so blocks are spread across the group. If requests to a member still fail after 15 seconds of retries, mount clients go directly to object storage and probe again every 5 minutes, preferring another group that answers. A group with an unreachable member is not selected. After switching, a client stays on the new group until it fails, the volume’s proxy groups change, or the volume is remounted.