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.

The AIStor Batch Framework allows you to create, manage, monitor, and execute jobs using a YAML-formatted job definition file (a “batch file”). The batch jobs run directly on the AIStor deployment to take advantage of the server-side processing power without constraints of the local machine where you run the AIStor Client. The keyrotate batch job type cycles the SSE-S3 or SSE-KMS keys for encrypted objects on an AIStor deployment. The YAML configuration supports filters to restrict key rotation to a specific set of objects by creation date, tags, metadata, or kms key. You can also define retry attempts or set a notification endpoint and token.

The following procedure adds a server pool to an existing AIStor deployment running on Kubernetes infrastructure. Each pool expands the total available storage capacity of the cluster while maintaining the overall availability of the cluster. All commands provided below use example values. Replace these values with those appropriate for your deployment. Retrieve and review the existing object store Helm chart. The objectStore.pools key describes the current deployment topology and pool configuration. Each element in the pools array describes a single server pool in the AIStor deployment.

This page provides an overview of AIStor Server deployment architectures from a production perspective. 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

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 mc admin cluster iam import command imports IAM metadata as created by the mc admin cluster iam export command. You can use this command to manually restore IAM metadata settings for an AIStor deployment. The command outputs the results of the import, including the following: count of individual entities imported by entity type list of policies imported by entity type they imported to list of entities that failed to import Syntax Example The following command imports the IAM metadata of the specified file onto the myaistor deployment.

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.

Lists the entities associated with a policy, user, or group on a target AIStor deployment. This command only returns minio-managed users and groups. To list entities associated with an Active Directory or LDAP (AD/LDAP) configuration, use mc idp ldap policy entities. For example, you can list all of the users and groups attached to a policy or list all of the policies attached to a specific user or group.

Generates a metrics scraping configuration file for use with Prometheus. Syntax Example The following command generates a v3 Prometheus scraping configuration file for the deployment at alias myaistor:

AIStor Helm installations consist of two primary parts: The operator chart that controls resources like CustomResourceDefinitions The object-store chart that deploys the AIStor Server You can also upgrade only the AIStor Server image used by a given chart. This page documents a procedure for all three upgrade paths. All AIStor software supports non-disruptive upgrades with zero downtime. In optimal environments, cluster-wide upgrades typically complete in under 500 milliseconds with large clusters (1000+ nodes) completing in less than 5 seconds.