Component Storage Settings

Why Do Components Need Storage

Component is an abstract concept of Rianbond. The bottom layer is running through container encapsulation. The container disk file is short-lived, that is, the log, generated or processed file of the program in the container is running. Once the container is closed or restarted, The generated or stored file is lost. Therefore, it is necessary to mount a persistent storage space to the component container to store various data generated by the program.

Type of Storage

Kato supports the following storage types by default:

  • Shared storage
  • Local storage (host path/grlocaldata)
  • Configuration file
  • Memory file storage

In addition to the above-mentioned storage types supported by Kato by default, Kato also supports Custom Storage Type to expand other storage as needed.

Shared Storage

Shared storage is a distributed file system. The default is NFS. You can also connect to other distributed file systems (GlusterFS, NAS, etc.). Shared storage has very high reliability and scalability; at the same time, it It also has very high flexibility, can be shared with other components, and allocate and isolate storage space based on tenants and components.

Shared storage has different working modes for stateless components and stateful components:

  • Stateless components
    • Shared storage has no instance difference, and multiple instances have the same data.
    • Can be relied on by other components to realize data sharing between components.
  • Stateful components
    • Each instance has independent storage space
    • Cannot be shared by other components

Local Storage

Local storage uses a local disk (usually an SSD disk) of the host where the running instance corresponding to the current component is located, and it does not have attributes that can be used across hosts. Local storage only supports the stateful component type. Local storage is usually used for components that require very high storage performance, such as database components. They can handle data synchronization between multiple instances from the application level. For example, Mysql uses master-slave synchronization, and TiDB uses an equivalent cluster based on the raft protocol. These components usually do not require data synchronization at the storage level.

The scheduling of components configured with local storage will follow the host where the storage is located, which is a restricted scheduling mechanism. For cluster-like database components, multi-node synchronization for processing stored data from the application layer, using local storage will be a better choice.

Configuration File

Configuration file is a special storage type, this type allows users to directly define the content of the file, usually refers to the configuration file. Kato supports two major features of configuration files:

Dynamic Rendering

The syntax of dynamic rendering configuration file parsing environment variables:

${environment variable name}
${Environment variable name: default value}

Here is a snippet of the MySQL configuration file:

[mysqld]
port = ${PORT:3306}
socket = /tmp/mysql.sock

If the environment variable PORT exists in the component, then Kato will parse the value of PORT into the configuration file; if the environment variable PORT does not exist in the component, then Kato will parse 3306 into the configuration file.

If the specified environment variable does not exist and the default value is not set, then Kato will not parse it

Configure File Sharing

The configuration file can be shared through the storage sharing mechanism. If you have multiple components using the same configuration file, you can share it directly without editing the settings multiple times.

The configuration file storage supports the editing function, that is, the content of the configuration file can be modified as needed after being added, and the components need to be updated to take effect after the modification is completed.

Memory File Storage

The essence of memory file storage is a piece of tmpfs (RAM-backed filesystem), which is temporary, will be created when the component is started, and destroyed when the component is stopped. Although tmpfs is very fast, please note that you write Any files will count towards the component’s memory limit. Therefore, it is generally suitable for disk-based temporary computing scenarios.

How to Add Storage to Components

There are two ways to add storage to components:

New Component Storage

Click Add Storage on the Management Panel/Storage page, and fill in the storage related information to confirm according to the prompts on the form.

Note: The added storage is not mounted, and the component needs to be updated or restarted to take effect.

Share the Storage of Other Components

In Management Panel/Storage_Page Shared Component Storage Management

After clicking the [Mount Shared Storage] button, check the names of other components that need to be mounted, and fill in the directory to mount to this component

Finish mounting other component storage

  • After adding or mounting the storage of other components, the component needs to be updated or restarted. The storage of other components does not support mounting to stateful components.
  • When adding or mounting other component storage, the path of this component cannot use Linux system reserved directories, such as /dev, /usr, /bin, /sys, /proc, etc.

The Persistent Data of Local Docker Running Components Have Been Migrated to Kato

Example gogs:

Step 1 Gogs is started locally through docker run, and related directories are persisted.

docker run -d --net=host -v /var/gogs:/data gogs/gogs

Step 2 Kato platform can also run the above command through docker run mode. After the application is deployed, the storage path can be obtained through the grctl command

Step 3 Back up the gogs data (data1) that needs to be migrated, then close the gogs on the platform, then replace the data of the gogs running on the platform with the backed up data1 data, and start the gogs on the platform

Starting from Kato 5.2 version, due to operating permissions, the /grdata directory is no longer mounted by default under the host. Therefore, you can perform operations in the rbd-chaos component after querying the actual directory of the component stored in the distributed file system.

Common Problems

The meaning of shared storage between components

Do you have a business scenario where one business component generates data and stores it in a local directory, and another business component reads the data for processing. In the traditional deployment model, you can only deploy these two components to the same node, let alone multi-instance high-availability deployment. Use shared storage between components without any modification to the program. When the business runs to any node, the read data can be shared normally.

Does Kato support various storage types in Kubernetes?

Kato supports the existing storage types of Kubernetes by docking with expanded storage. For details, please refer to Custom Storage Type