The mc ilm tier update command modifies an existing configured remote tier. Syntax Example The following example updates the credentials for an existing remote tier called S3TIER on the myaistor deployment.

The mc replicate ls command lists all replication rules on an AIStor bucket. The output includes the remote bucket, rule ID, priority, and ARN for each rule. Syntax Example The following command lists all enabled replication rules for the mydata bucket on the myaistor AIStor deployment:

The procedure on this page creates a new object lifecycle management rule that transition objects from an AIStor bucket to a remote storage tier on the storage backend. This procedure supports use cases like moving aged data to low-cost public cloud storage solutions after a certain time period or calendar date. Requirements Install and configure mc This procedure uses mc for performing operations on the AIStor cluster. Install mc on a machine with network access to both source and destination clusters. See the mc Installation Quickstart for instructions on downloading and installing mc.

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.

AIStor Server publishes cluster and node metrics using the Prometheus Data Model. You can use any scraping tool to pull metrics data from AIStor Server for further analysis and alerting. This page covers metrics version 3, which has additional metrics and endpoints. Existing deployments can continue to use version 2 metrics. Version 3 endpoints The base endpoint, without an added path, returns cluster, node, and per-bucket statistic metrics from /cluster/usage/buckets.

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 publishing audit logs to one or more configured Apache Kafka receivers. AIStor send an event for each API operation to the receiver for processing and storage. The receiver is responsible for correctly processing events, including returning 200OK or similar success messages upon receipt of the event. AIStor cannot recover events that were successfully sent but not correctly stored on the receiver. You can configure a new Kafka audit endpoint using either environment variables or runtime configuration settings. If you configure both, AIStor uses the environment variables.

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.

AIStor uses Policy-Based Access Control (PBAC) to define the authorized actions and resources to which an authenticated user has access. Each policy describes one or more actions and conditions that outline the permissions of a user or group of users. AIStor PBAC is built for compatibility with AWS IAM policy syntax, structure, and behavior. This documentation makes a best-effort to cover IAM-specific behavior and functionality. Refer also to the AWS IAM documentation for more information.