The mc idp ldap accesskey enable enables the specified access key on the local server. Syntax Example The following example enables the access key mykey from the myaistor deployment:

The mc replicate command configures and manages per-bucket Server-Side Bucket Replication for an AIStor deployment, including active-active replication configurations and resynchronization. For site-level replication, see mc admin replicate. Subcommands mc replicate includes the following subcommands: Subcommand Description add Create a new server-side replication rule for a bucket on an AIStor deployment. backlog Show a list of unreplicated new or deleted objects. export Export the JSON-formatted replication rules for an AIStor bucket to STDOUT. import Import JSON-formatted replication rules for an AIStor bucket from STDIN. ls List all replication rules on an AIStor bucket. resync Resynchronize all objects in the specified AIStor bucket to a remote replication target. rm Remove a replication rule from an AIStor bucket. status Display the replication status of an AIStor bucket. The status also lists the remote target path or location. update Modify an existing bucket replication rule.

The mc mirror command synchronizes content to an AIStor deployment, similar to the rsync utility. mc mirror supports filesystems, AIStor deployments, and other S3-compatible hosts as the synchronization source. The target synchronization site file names are normalized using the shortest equivalent name. For example, s3/miniocloud//this/./object becomes miniocloud-backup/this/object. mc mirror only synchronizes the current object without any version information or metadata other than tags. To synchronize an object’s version history and other metadata, consider using mc replicate for bucket replication or mc admin replicate for site replication.

This page covers settings that control Information Lifecycle Management (ILM) for the AIStor process. You can establish or modify settings by defining: an environment variable on the host system prior to starting or restarting the AIStor Server. Refer to your operating system’s documentation for how to define an environment variable. a configuration setting using mc admin config set. If you define both an environment variable and the similar configuration setting, AIStor uses the environment variable value.

This page reflects limits and thresholds that apply to AIStor Server. S3 API limits Item Specification Maximum object size 50 TiB Minimum object size 0 B Maximum object size per PUT operation 5 TiB for non-multipart upload50 TiB for multipart upload Maximum number of parts per upload 10,000 Part size range 5 MiB to 5 GiB. Last part can be 0 B to 5 GiB Maximum number of parts returned per list parts request 10,000 Maximum number of objects returned per list objects request 1,000 Maximum number of multipart uploads returned per list multipart uploads request 1,000 Maximum length for bucket names 63 Maximum length for object names 1024 Maximum length for each / separated segment of an object name 255 Maximum number of object versions for a unique object 10000 (Configurable) Erasure code limits Item Specification Maximum number of servers per cluster no limit Minimum number of servers 1 Minimum number of drives per server when server count is 1 1 (for deployments, which do not provide additional reliability or availability) Minimum number of drives per server when server count is 2 or more 1 Maximum number of drives per server no limit Read quorum $$N/2$$ Write quorum $$(N/2)+1$$ Object name limitations Filesystem and operating system restrictions Object names in AIStor are restricted primarily by the local operating system and filesystem. Windows and some other operating systems restrict file systems with certain special characters, such as ^, *, |, \, /, &, ", or ;.

Memory primarily constrains the number of concurrent simultaneous connections per node. MinIO recommends at least 256GiB of RAM per host. Caching memory usage By default, deployments have caching enabled. The AIStor Server allocates up to 75% of host memory as a drive-level per-shard cache for supporting GET operations.

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

Drive type MinIO recommends using flash-based storage (NVMe or SSD) for all workload types at any scale. Workloads that require high performance should prefer NVMe over SSD. For best performance, use 30+TB drives with NVMe over PCIe 4.0 or 5.0. Directly attached storage For best performance, provide AIStor with drives attached directly to each host node as a JBOD array with no RAID or similar management layers. AIStor requires the XFS filesystem for best performance and behavior at scale. Using any other type of backing storage (SAN/NAS, ext4, RAID, LVM) typically results in a reduction in performance, reliability, predictability, and consistency.

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.

This page documents environment variables for configuring AIStor to publish data to an HTTP webhook endpoint and trigger an Object Lambda function. See Transforms with Object Lambda for more complete documentation and tutorials on using these environment variables. Environment Variables You can specify multiple targets by appending a unique identifier _ID for each set of related settings.