Core Concepts
A production AIStor Server deployment consists of at least 4 hosts with homogeneous storage and compute resources.
Each AIStor Server host in this pool has matching compute, storage, and network configurations
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.
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.
Clients using a variety of S3-compatible SDKs can perform operations against the same AIStor Server deployment.
MinIO AIStor provides S3-focused SDKs for multiple languages for developer convenience. These libraries provide S3 API functionality only. They do not include extra code to support cloud storage features outside the S3 API.
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.
The PUT request requires checking each pool for the correct erasure set. Once identified, AIStor Server partitions the object and distributes the data and parity shards across the appropriate set.
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.