AIStore stores, maintains, and utilizes a number of system files that serve a variety of different purposes.
For the most recently updated system filenames and configuration directories, please see
This section tries to enumerate the system files and briefly describe their respective usages.
First, there’s a node configuration usually derived from a single configuration template and populated at deployment time.
- Local Playground: a single configuration template and the script we use to populate it when we run the cluster locally on our development machines;
- Production K8s deployment: a set of configuration templates and the
values.yamlfile that can be located in the parent directory and that comprises all the values that must be set, modified, or tuned-up for a specific Kubernetes deployment.
The second category of system files and directories includes:
||file||gateway||Buckets Metadata||Names and properties of all buckets, including replicated remote buckets and remote AIStore buckets|
||file||gateway and target||Cluster Map||Description of whole cluster which includes IDs and IPs of all the nodes.|
||file||storage target||Rebalancing State||Used internally to make sure that cluster-wide rebalancing runs to completion in presence of all possible events including cluster membership changes and cluster restarts.|
||dir||storage target||Persistent state markers||Used for many purposes like determining node restart or rebalance/resilver abort. The role of the markers is to survive potential node’s process crash (eg. due to power outage or mistake).|
||file||gateway||Gateway node id||Used during node startup to detect a node ID if not specified with
||AuthN server configuration|
||Registered clusters, a token blacklist, user roles, user credentials and permissions|
And on the machine where you run AIS CLI expect to see the following two files (by default, under
||Configuration file (if doesn’t exist, the config gets created and populated with default values upon the first CLI run)|
||The token file is created iff
Finally, there’s also
ais.db that each AIS node may store locally to maintain component-specific runtime information in the form of key-value records. The components in-question include dSort and Downloader and the example of the stored information would be running downloading jobs and their errors (if any).