Proxy Groups

Note

Proxy groups are an Enterprise feature. Community edition users can use local on-disk writeback caching (--diskWriteback) on the mount client as an alternative latency mitigation strategy.

Proxy groups are managed through the admin server using configure.flexfs. A proxy group defines a set of proxy server addresses that collectively cache blocks for associated volumes.

Creating a proxy group

Use configure.flexfs to create a proxy group:

configure.flexfs create proxy-group \
  --providerCode aws \
  --regionCode us-east-1 \
  --addresses proxy1.example.com:443,proxy2.example.com:443

A proxy group has the following properties:

Property	Description
ID	Auto-assigned unique identifier (integer)
Provider Code	Provider where the proxy servers are deployed
Region Code	Region where the proxy servers are deployed
Addresses	Comma-separated list of proxy server host:port addresses

Associating proxy groups with volumes

A volume can be associated with multiple proxy groups. This is done by creating volume-proxy-group associations:

configure.flexfs create volume-proxy-group \
  --volumeID my-volume \
  --proxyGroupID 1

You can associate multiple proxy groups with the same volume:

configure.flexfs create volume-proxy-group \
  --volumeID my-volume \
  --proxyGroupID 1

configure.flexfs create volume-proxy-group \
  --volumeID my-volume \
  --proxyGroupID 2

When a mount client connects, it receives all proxy groups associated with its volume and selects the one with the lowest RTT.

Dynamic membership

Proxy group membership can be modified while mounts are active:

Adding a proxy server

configure.flexfs update proxy-group 1 \
  --addresses proxy1.example.com:443,proxy2.example.com:443,proxy3.example.com:443

Mount clients will discover the new proxy server on their next configuration refresh and begin routing blocks to it via rendezvous hashing. Only blocks that hash to the new server are affected — existing routing assignments remain stable.

Removing a proxy server

Remove a proxy server by updating the addresses list without it:

configure.flexfs update proxy-group 1 \
  --addresses proxy1.example.com:443,proxy2.example.com:443

Blocks previously routed to the removed server are redistributed among the remaining servers. Clients that still have the old server in their routing table will experience cache misses for those blocks, which will be re-fetched from object storage and cached on the new target.

Scaling considerations

• Adding servers: Causes a partial cache warm-up as some blocks are re-routed. The more servers in the group, the smaller the fraction of blocks affected.
• Removing servers: Causes the removed server’s block assignments to shift to other servers, triggering cache misses.
• Replacing servers: Equivalent to adding the new server and removing the old one.

How mount clients discover proxy groups

1. During startup, the mount client fetches volume settings from the admin server. The settings include the list of proxy groups (and their addresses) associated with the volume.
2. The client probes each group by measuring RTT to one or more servers in the group.
3. The lowest-RTT group is selected.
4. The client periodically refreshes this configuration from the admin server to pick up membership changes.

If all proxy groups become unreachable, the mount client falls back to direct object storage access. When a proxy group becomes reachable again, the client resumes using it.

SSL certificates for proxy groups

Mount clients connect to proxy servers over HTTPS by default. Each proxy server auto-generates a self-signed certificate on first start. Since mount clients are configured to trust the proxy server (they use the admin-server-provided address list, not public DNS), self-signed certificates work without additional CA configuration.

For environments requiring trusted certificates, deploy custom certificates on each proxy server using the --sslCert and --sslKey flags.