Description The mc admin accesskey command and its subcommands create and manage Access Keys for internally managed users on an AIStor deployment. Each access key is linked to a user identity and inherits the policies attached to its parent user or those groups in which the parent user has membership. Each access key also supports an optional inline policy which further restricts access to a subset of actions and resources available to the parent user.

AIStor supports publishing bucket notification events to a Redis service endpoint. Prerequisites The AIStor mc command line tool This procedure uses the mc command line tool for certain actions. See the mc Quickstart for installation instructions. Add a Redis endpoint to an AIStor Server The following procedure adds a new Redis service endpoint for supporting bucket notifications in an AIStor Server.

The following procedure adds a server pool to an existing AIStor cluster running on Kubernetes infrastructure. Each pool expands the total available storage capacity of the cluster with new nodes and persistent volumes while maintaining the overall availability of the cluster. Pay particular attention to the parity (EC:M) value of the existing cluster and the new pool. MinIO strongly recommends seeking an architecture review from MinIO Engineering through SUBNET to analyze potential performance impacts before committing to a new pool for your cluster.

If an AIStor node suffers complete hardware failure (for example, loss of all drives, data, etc.), the node begins healing operations once it rejoins the deployment. AIStor healing occurs only on the replaced hardware and does not typically impact deployment performance. AIStor healing ensures consistency and correctness of all data restored onto the drive. Changed in RELEASE.2025-02-04T00-52-01Z If multiple drives within the same erasure set require healing, AIStor prioritizes the first drive that begins healing within the erasure set. Other drives in the erasure set wait until healing finishes on the first drive before the next drive starts healing.

AIStor supports hot-swapping failed drives with new healthy drives. Healing AIStor detects and heals those drives without requiring any node or deployment-level restart. AIStor healing occurs only on the replaced drive(s) and in most cases has minimal or negligible impact on deployment performance.

Metrics and alerts AIStor Server publishes point-in-time metrics using the Prometheus Data Model. You can use any scraping tool which supports that data model to pull those metrics into a database for populating historical views, performing query/analysis of metrics data, or creating alerts on preferred data points.

The mc alias set command sets or updates an alias in the AIStor Client configuration. Syntax Example The following command sets an alias named myaistor:

This page describes how to upgrade AIStor Helm deployments that use a private container registry but have internet access to helm.min.io for chart updates. If your deployment uses public registries or is in an airgapped environment, see: Upgrade with Public Registries Upgrade in Airgapped Environment Overview AIStor Helm upgrades involve updating two components:

This section provides documentation for operating and maintaining AIStor Object Store deployments. Use this documentation for Day 2 and ongoing operational tasks in production environments, including monitoring, scaling, troubleshooting, and managing production AIStor deployments. You can find detailed explanations for core concepts that underpin AIStor. Understanding topics like erasure coding, distributed architecture, and data protection mechanisms provide a foundation for effectively using your cluster. AIStor provides comprehensive monitoring capabilities to maintain reliability and performance. Use metrics, logging, audit trails, and healthcheck endpoints to track deployment health and identify performance bottlenecks.

AIStor allows you to temporarily remove nodes from active service for planned maintenance operations. Removing nodes allows administrators to gracefully take nodes offline without disrupting cluster operations, similar to the cordon functionality in Kubernetes. A cordoned node finishes in-flight operations and marks itself as unavailable for any other operation. Use this to do hardware maintenance on a node, complete operating system updates, or perform troubleshooting. AIStor cordoning on Kubernetes In Kubernetes environments, the AIStor cordoning function applies to the Pod running the associated workload. It does not affect any other Pods or services running on the Kubernetes worker, and acts to ensure the scheduler does not reschedule that Pod during ongoing maintenance operations. The following diagram illustrates the node state transitions during the maintenance workflow: