Expand Available Storage

AIStor supports expanding an existing distributed deployment by adding a new Server Pool. Each pool expands the total available storage capacity of the cluster.

Expansion does not provide Business Continuity/Disaster Recovery (BC/DR)-grade protections. While each pool is an independent set of servers with distinct erasure sets for availability, the complete loss of one pool results in MinIO stopping I/O for all pools in the deployment. Similarly, an erasure set which loses quorum in one pool represents data loss of objects stored in that set, regardless of the number of other erasure sets or pools.

The new server pool does not need to use the same type or size of hardware and software configuration as any existing server pool, though doing so may allow for simplified cluster management and more predictable performance across pools. All drives in the new pool should be of the same type and size within the new pool. Review MinIO’s hardware recommendations for more complete guidance on selecting an appropriate configuration.

To provide BC-DR grade failover and recovery support for your single or multi-pool AIStor deployments, use site replication.

AIStor does not automatically rebalance objects across the new server pools. Instead, AIStor performs new write operations to the pool with the most free storage weighted by the amount of free space on the pool divided by the free space across all available pools.

The formula to determine the probability of a write operation on a particular pool is

Consider a situation where a group of three pools has a total of 10 TiB of free space distributed as:

• Pool A has 3 TiB of free space
• Pool B has 2 TiB of free space
• Pool C has 5 TiB of free space

AIStor calculates the probability of a write operation to each of the pools as:

• Pool A: 30% chance (3TiB / 10TiB)
• Pool B: 20% chance (2TiB / 10TiB)
• Pool C: 50% chance (5TiB / 10TiB)

In addition to the free space calculation, if a write option (with parity) would bring a drive usage above 99% or a known free inode count below 1000, AIStor does not write to the pool.

If desired, you can manually initiate a rebalance procedure with mc admin rebalance.

Likewise, MinIO does not write to pools in a decommissioning process.

Adding a new server pool requires restarting all Object Store processes in the deployment at around same time.

MinIO strongly recommends restarting all Object Store processes in a deployment simultaneously. AIStor operations are atomic and strictly consistent. As such the restart procedure is non-disruptive to applications and ongoing operations.

Do not perform “rolling” (that is, one node at a time) restarts.

MinIO recommends planning storage capacity sufficient to store at least 2 years of data before reaching 70% usage. Performing server pool expansion more frequently or on a “just-in-time” basis generally indicates an architecture or planning issue.

For example, consider an application suite expected to produce at least 100 TiB of data per year and a 3 year target before expansion. The deployment has ~500TiB of usable storage in the initial server pool, such that the cluster safely met the 70% threshold with some buffer for data growth. The new server pool should ideally meet at minimum 500TiB of additional storage to allow for a similar lifespan before further expansion.

Since AIStor erasure coding requires some storage for parity, the total raw storage must exceed the planned usable capacity. Consider using the MinIO Erasure Code Calculator for guidance in planning capacity around specific erasure code settings.

This tutorial assumes all hosts running MinIO use a recommended Linux operating system.

All hosts in the deployment should run with matching software configurations.