This section documents best practices and tutorials for updating the AIStor server on Linux and Kubernetes infrastructure to a newer release. 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. Applications using MinIO or S3 SDKs can rely on the built-in transparent retry to ensure continuous operations during the update procedure.

You can use the AIStor Console to perform several of the identity and access management functions available in AIStor, such as: Create and manage user credentials or groups with the built-in AIStor IDP, connect to one or more OIDC providers, or add an LDAP provider for Single Sign On. Configure single sign on workflows using either OpenID Connect or AD/LDAP. View, manage, and create access policies. Create child access keys that inherit the parent’s permissions. IAM Users The IAM Users section provides a management interface for AIStor-managed users.

Each AIStor server process exposes unauthenticated endpoints for probing server uptime and deployment high availability for simple healthchecks. These endpoints return an HTTP status code indicating whether the underlying resource is healthy or satisfies read/write quorum. The server exposes no other data through these endpoints. AIStor liveness Use the following endpoint to test if the specified AIStor server is up and ready to serve requests:

AIStor supports scaling deployments by expanding or decomissioning server pools. Ideally, deployments should plan for 3 years of data growth at installation.

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 MinIO deployment to take advantage of the server-side processing power without constraints of the local machine where you run the MinIO Client. A batch file defines one job task. Once started, the AIStor server starts processing the batch job. Time to completion depends on the resources available to the deployment.

The procedure on this page creates a new bucket replication rule for two-way “active-active” synchronization of objects between AIStor buckets. Requirements Replication requires all participating clusters meet the bucket replication requirements. This procedure assumes you have reviewed and validated those requirements.

The procedure on this page creates a new bucket replication rule for one-way synchronization of objects from one AIStor bucket to another AIStor bucket. The buckets can be on the same AIStor deployment or on separate AIStor deployments. Requirements Replication requires all participating clusters meet the bucket replication requirements. This procedure assumes you have reviewed and validated those requirements.

Description The mc admin prometheus command and its subcommands provide access to MinIO Prometheus metrics. Subcommands Subcommand Description generate The mc admin prometheus generate command generates a metrics scraping configuration file for use with Prometheus. metrics The mc admin prometheus metrics command prints Prometheus metrics for a cluster.

Description The mc admin replicate command creates and manages site replication for a set of AIStor peer sites. Site replication mimics an active-active bucket replication, but for multiple AIStor deployments. Wherever a change occurs to IAM settings, buckets, or objects across the set of sites, the change replicates across all sites in the site replication group.

Description The mc encrypt commands set, update, or disable the default bucket Server-Side Encryption (SSE) mode. AIStor automatically encrypts objects using the specified SSE mode. Subcommands mc encrypt includes the following subcommands: