Networking has the greatest impact on AIStor Server performance. Low per-host bandwidth artificially constrains the potential performance of the storage. MinIO recommends high speed networking to support the maximum possible throughput of the attached storage (aggregated drives, storage controllers, and PCIe busses). For best performance, use 100GbE or higher networking infrastructure. The following table provides a general guideline for the maximum storage throughput supported by a given physical or virtual network interface. This table assumes all network infrastructure components, such as routers, switches, and physical cabling, also supports the NIC bandwidth.

This tutorial deploys AIStor onto Kubernetes distributions that follow the upstream API and functionality. The steps in this procedure may work on forked Kubernetes distributions. This procedure requires the installation of Kubernetes operators and associated resources including CustomResourceDefinitions, Statefulsets, and secrets into new or existing namespaces. You must perform the operations in this procedure as a user that has broad permissions to create resources within multiple namespaces. Deploy AIStor using Helm This procedure documents installation on Kubernetes with the AIStor Helm Charts. MinIO recommends Helm version 3.17 or later.

AIStor server-side bucket replication is an automatic bucket-level configuration that synchronizes objects between a source and destination bucket. AIStor server-side replication requires the source and destination bucket be two separate AIStor clusters running the same Object Store version. For each write operation to the bucket, AIStor checks all configured replication rules for the bucket and applies the matching rule with highest configured priority. AIStor synchronizes new objects and object mutations, such as new object versions or changes to object metadata. This includes metadata operations such as enabling or modifying object locking or retention settings.

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 replicate batch job replicates objects from one AIStor deployment (the source deployment) to another AIStor deployment (the target deployment). The deployment specified as the alias becomes the ’local’ deployment for the purposes of replication.

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 server to take advantage of the server-side processing power without constraints of the local machine where you run the AIStor Client. The expire batch job applies Automatic Object Expiration behavior to a single bucket. The job determines expiration eligibility based on the provided configuration, independent of any configured expiration rules.

MinIO publishes the following Software Development Kits (SDK): Go Download from GitHub Python Install methods Java Install methods .NET Download from NuGet JavaScript Install Haskell Install C++ Install Rust Go GitHub: minio/minio-go

AIStor’s Object Lambda enables developers to programmatically transform objects on demand. You can transform objects as needed for your use case, such as redacting personally identifiable information (PII), enriching data with information from other sources, or converting between formats. Overview An Object Lambda handler is a small code module that transforms the contents of an object and returns the results. Like Amazon S3 Object Lambda functions, you trigger an AIStor Object Lambda handler function with a GET request from an application. The handler retrieves the requested object from AIStor, transforms it, and returns the modified data back to AIStor to send to the original application. The original object remains unchanged.

This page documents the installation of the AIStor Key Encryption Service. You may require root or sudo permissions to perform some of the steps. Install the AIStor KES binary on each node in your KES cluster. Linux AMD64 curl --progress-bar --retry 10 -L https://dl.min.io/aistor/kes/release/linux-amd64/kes -o kes chmod +x ./kes mv ./kes /usr/local/bin/kes kes --version ARM64

The AIStor Security Token Service (STS) AssumeRoleWithCustomToken API endpoint generates a token for use with the AIStor External Identity Management Plugin. Request endpoint The AssumeRoleWithCustomToken endpoint has the following form: POST https://aistor.example.net?Action=AssumeRoleWithCustomToken[&ARGS] The following example uses all supported arguments. Replace the aistor.example.net hostname with the appropriate URL for your AIStor cluster:

The AIStor Security Token Service (STS) AssumeRoleWithLDAPIdentity API endpoint generates temporary access credentials using Active Directory or LDAP user credentials. This page documents the AIStor Server AssumeRoleWithLDAPIdentity endpoint. For instructions on implementing STS using an S3-compatible SDK, defer to the documentation for that SDK. The AIStor STS AssumeRoleWithLDAPIdentity API endpoint is modeled after the AWS AssumeRoleWithWebIdentity endpoint and shares certain request/response elements. This page documents the AIStor-specific syntax and links out to the AWS reference for all shared elements.