Core Concepts

A production AIStor Server deployment consists of at least 8 hosts with homogeneous storage and compute resources.

Eight hosts make one server pool Eight identically configured hosts form a single server pool, which AIStor presents to clients as one object store. PRODUCTION DEPLOYMENT 8 hosts · 1 server pool HOST 1 minio-01 HOST 2 minio-02 HOST 3 minio-03 HOST 4 minio-04 HOST 5 minio-05 HOST 6 minio-06 HOST 7 minio-07 HOST 8 minio-08 SERVER POOL 1 minio.example.net One namespace. A client sees one object store, not eight hosts.
Every host in the pool has matching compute, memory, network, and storage. AIStor presents the pool to clients as a single object store.

These hosts make up a server pool, where the AIStor Server presents the aggregated compute, memory, and storage as a single resource to clients. Each pool consists of one or more erasure sets.

To limit the impact of localized failures in Kubernetes deployments, configure spread zones so that MinIO AIStor distributes Pods across separate failure domains, such as racks or availability zones.

Each AIStor Server has a complete picture of the distributed topology, such that an application can connect and direct operations against any node in the deployment.

Applications typically should not manage those connections, because any change to the deployment topology would then require an application update. Production deployments should instead use a load balancer, or a similar network control plane component, to manage connections to the AIStor Server deployment.

A load balancer in front of eight nodes Clients reach the deployment through a load balancer, which routes each request to any node. The receiving node handles internode traffic from there. DEPLOYMENT 8 nodes · one load balancer S3 API request Internode traffic application LOAD BALANCER https://minio.example.net AISTOR DEPLOYMENT the balancer may pick any node NODE 1 RECEIVES NODE 2 NODE 3 NODE 4 NODE 5 NODE 6 NODE 7 NODE 8
The load balancer routes the request to any node in the deployment. The receiving node handles any internode requests thereafter.

Client applications can use any S3-compatible SDK or library to interact with the AIStor Server deployment.

One endpoint, several API surfaces Applications reach AIStor through the MinIO SDKs or any S3-compatible library. The same endpoint also answers an Iceberg REST catalog for tables, S3 over RDMA for GPU-direct transfers, and the file protocols, all from one deployment. CLIENTS one endpoint · S3, Iceberg, RDMA, SFTP Go minio-go Python minio-py Java minio-java .NET minio-dotnet Any S3 SDK aws-sdk, boto3, … LOAD BALANCER AISTOR DEPLOYMENT minio.example.net S3 API Iceberg REST catalog S3 over RDMA FTP, FTPS and SFTP
One endpoint answers every surface: the S3 API for objects, an Iceberg REST catalog for tables, S3 over RDMA for GPU-direct transfers, and the file protocols. One deployment serves all four, with no second system to run.

MinIO provides SDKs for Go, Python, Java, .NET, and more. They cover the S3 API, and the Go, C++, Rust, and Python SDKs also implement S3 over RDMA.

The same deployment answers more than the S3 API.

  • AIStor Tables serves an Apache Iceberg REST catalog from the object store itself, with no separate catalog service or metadata database to run.
  • S3 over RDMA reads an object straight into GPU memory over the RDMA fabric, so the payload never passes through the kernel network stack.
  • FTP, FTPS, and SFTP give file clients access to the same buckets, without an export or a gateway in front.

For how these surfaces and the controls around them serve a training or inference pipeline, see AI Workloads. For how the cluster stores data and repairs itself, see Erasure Coding and Healing.

You can expand an AIStor Server’s available storage through pool expansion.

Each pool consists of an independent group of nodes with their own erasure sets. Adding new pools requires updating all nodes in the deployment with the new topology. In a multi-pool cluster, the receiving AIStor Server node determines which pool to route a given request to.

A deployment with two server pools The receiving node decides which pool holds the erasure set for a key, then writes the object's shards across that pool. The namespace stays single. DEPLOYMENT · TWO POOLS 2 pools · 8 nodes each PUT request PUT /data/object.blob LOAD BALANCER AISTOR DEPLOYMENT one namespace POOL 1 NODE 1 NODE 2 NODE 3 NODE 4 NODE 5 NODE 6 NODE 7 NODE 8 POOL 2 · SELECTED NODE 1 NODE 2 NODE 3 NODE 4 NODE 5 NODE 6 NODE 7 NODE 8
The receiving node determines which pool holds the erasure set for this key and routes the request there. Adding a pool grows capacity without splitting the namespace.

Pool expansion requires updating any load balancers or similar network control plane components with the new hostname layout to ensure even distribution of load across nodes.