The mc ilm tier add command creates a new remote storage tier to a supported storage services. See Object Transition for a complete list. Syntax Example The following example creates a new remote tier called WARM-MINIO-TIER on the myaistor deployment. The command creates a tier for a remote AIStor deployment located at the hostname https://warm-minio.example.com.

The mc license register command connects your deployment with your MinIO SUBNET account. The registration process collects the following information about the cluster for upload to SUBNET: Deployment ID Cluster Name Used capacity AIStor Object Store version Number of server pools Number of servers Number of drives Space on each drive Space used on each drive Number of buckets Number of objects After registration, you can upload deployment health reports directly to SUBNET using the mc support diag command.

The mc idp ldap add command creates an AD/LDAP IDP server configuration. AIStor supports no more than one (1) AD/LDAP provider per deployment. Syntax Example The following example sets the AD/LDAP configuration settings for the myaistor deployment.

The mc idp openid accesskey commands allow you to list, delete, or display information about OIDC access key pairs on the AIStor deployment. This command works against access keys created by an OIDC user after authenticating to AIStor. Authenticated users can create access keys with the AIStor console, or with the mc admin accesskey create command. An authenticated user cannot create access keys for another OIDC user. AIStor also supports using AssumeRoleWithWebIdentity to generate temporary access keys using the Security Token Service.

Configure load balancers and reverse proxies for AIStor on Linux. Includes example configurations for NGINX and HAProxy.

Use the following checklist when planning the software configuration for a production, distributed MinIO deployment. AIStor pre-requisites Description ☐ Servers running a Linux operating system with a kernel of 6.11.x or later for access to critical performance features.Red Hat Enterprise Linux (RHEL) 10 and Ubuntu Server 24.0.2 LTS use appropriate kernel versions by default. ☐ A method to synchronize time servers across nodes, such as with ntp, timedatectl or timesyncd.The method to use varies by operating system.Check with your operating system’s documentation for how to synchronize time with a time server. ☐ Disable system services that index, scan, or audit the filesystem, system-level calls, or kernel-level calls.These services can reduce performance due to resource contention or interception of AIStor operations.MinIO strongly recommends uninstalling or disabling the following services on hosts running AIStor:- mlocate or plocate- updatedb- auditd- Antivirus software (clamav)The above list represents the most common services or softwares known to cause performance or behavioral issues with high performance systems like AIStor.Consider removing or disabling any other service or software which functions similarly to those listed above on AIStor hosts.Alternatively, configure these services to ignore or exclude the AIStor process and all drives or drive paths accessed by AIStor. ☐ System administrator access to the remote servers ☐ A management tool for distributed systems, such as Ansible, Terraform, or Kubernetes for orchestrated environments.Kubernetes infrastructures should use the AIStor Operator for best results. ☐ Load balancer to handle routing of requests (for example, NGINX) ☐ Prometheus or a Prometheus-compatible setup for monitoring and metrics ☐ Grafana or similar Prometheus-compatible visual dashboard ☐ (Optional) mc installed on the local host system AIStor install Install a matching version of AIStor across all nodes in the deployment.

This procedure deploys AIStor Object Store on Kubernetes clusters using a private container registry for images while installing Helm charts from the public MinIO Helm repository. Use this procedure when your environment has internet access to install Helm charts from helm.min.io but you need to pull container images from a private container registry instead of the public quay.io registry. This procedure requires installation of Kubernetes operators and associated resources including CustomResourceDefinitions, StatefulSets, and secrets into new or existing namespaces. You must perform the operations in this procedure as a user that has broad permissions to create resources within multiple namespaces.

Deployment Checklists The following checklists provide a high-level guideline for validating production-readiness of AIStor Servers. These checklists may not meet the precise requirements of your unique deployment topology or architecture, and are intended as a best-effort guide to reliable production deployments.

Distributed AIStor deployments rely on Erasure Coding to provide built-in tolerance for multiple drive or node failures. Depending on the deployment topology and the selected erasure code parity, AIStor can tolerate the loss of up to half the drives or nodes in the deployment while maintaining read access (“read quorum”) to objects. The following table lists the typical types of failure in an AIStor deployment and links to procedures for recovering from each:

AIStor Server implements Erasure Coding as a core component in providing data redundancy and availability. The diagrams and content in this section present a simplified view of erasure coding operations and are not intended to represent the complexities of the AIStor Server’s full erasure coding implementation. AIStor groups drives in each server pool into one or more Erasure Sets of the same size.