AIStor can make the loss of an entire site, while significant, a relatively minor incident. Site recovery depends on the replication option you use for the site. Replication type Restoration method Site Replication Total restoration of IAM configurations, bucket configurations, and data from the healthy peer site(s) Bucket Replication Data restoration of objects and metadata from a healthy remote location for each bucket configured for replication mc mirror Data restoration of objects only from a healthy remote location with no versioning Site replication healing automatically adds IAM settings, buckets, bucket configurations, and objects from the existing site(s) to the new site with no further action required.

AIStor Server supports publishing bucket notification events to an Elasticsearch service endpoint. Prerequisites Elasticsearch v7.0 or later. AIStor relies on the v7 project for Elastic connectivity. The elastic/v7 library specifically targets Elasticsearch v7.0 and is not compatible with earlier Elasticsearch versions. The AIStor mc command line tool.

AIStor supports publishing bucket notification events to NSQ 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 an NSQ endpoint to an AIStor Server The following procedure adds a new NSQ service endpoint for supporting bucket notifications in an AIStor Server.

AIStor requires an active and unexpired MinIO Commercial License. Accessing your license The license is available in MinIO SUBNET. Log in to SUBNET. From the Deployments screen, select License Key. Select the copy button to the right of license key string.

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.

For identities managed by an external OpenID Connect (OIDC) compatible provider, AIStor can use either of two methods to assign policies to the authenticated user. AIStor by default denies access to all actions or resources not explicitly allowed by a user’s assigned or inherited policies. Authorization options with OIDC OIDC integration in AIStor supports either of the following authorization methods:

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 publishing bucket notification events to a NATS 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 NATS endpoint to an AIStor Server The following procedure adds a new NATS service endpoint for supporting bucket notifications in an AIStor Server.

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.

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.