Scale-out
How BlixtFS spreads metadata and data across servers, and how it keeps serving when a server fails.
Scale-out deployments with more than one active server of a kind require a High Performance Edition license. Without one, extra servers wait as standbys.
Even distributions across file servers
In scale out deployments, files are sharded across partitions that are evenly assigned to file servers. This increases total capacity for both request rates and total number of files.
Cache and write servers
- Cache servers distribute read cache data across servers by consistent hashing, so the cluster’s combined disk and memory form one large cache. Large reads read from all available disks at once.
- Write servers stores written data on one or multiple servers. As long as at least one replica remains, no data is lost.
Default replication factors can be set per bucket with the
read_replication= and write_replication= bucket attributes.
Read replication can also be set manually on a per file basis.
Health and failover
The config server tracks active and standby servers for each server type. When an active server stops responding, a standby server takes over its role or partitions. If a config server fails, a second config server can take over.
Sizing guidance
- Use monitoring to understand your workload requirements.
- Start with three file servers, three cache servers and three write servers. This is the Helm chart’s default.
- File servers scale with metadata operations and client count. The Helm chart can autoscale them.
- Cache servers scale with your working set.
- Write servers scale with write bandwidth and the upload backlog you want to absorb.