Configuring and tuning your system for Cloud services

This topic describes the procedure for configuring and tuning your IBM Storage Scale node for Cloud services.

Configuration command execution matrix
This topic describes which Cloud services commands can be run from which nodes. Typically, nodes can be categorized into 3 categories based on what software package (rpm) is installed on them. They are, Cloud services server node, Cloud services client node, and non-Cloud services node.
Designating the Cloud services nodes
This topic describes how to designate a node as Cloud services node in the IBM Storage Scale cluster.
Starting up the Cloud services software
This topic describes how to start the Cloud services software on IBM Storage Scale nodes.
Managing a cloud storage account
You can manage a cloud storage account by using the mmcloudgateway account create/update/delete command.
Defining cloud storage access points (CSAP)
The Cloud Storage Access Point (CSAP) provides access between the cloud account on your object storage and IBM Storage Scale. You must create at least one CSAP per cloud account so your Cloud services have a path to the object storage. Extra CSAPs can also be created. CSAPs that all have about the same lowest latency (which is tested every 30 minutes) to a node are used evenly. CSAPs with higher latency are put in standby and are used only in error scenarios. This provides greater throughput and higher availability in various error scenarios.
Creating Cloud services
You must create at least one Cloud services for each cloud account that is created. You can associate a single Cloud services with only one cloud account but can use it with multiple file systems or file sets.
Configuring Cloud services with SKLM (optional)
To encrypt data that is tiered to the cloud storage, you need to first configure a key manager, before creating a container pair set in the next step. Two types of key manager are supported - local key manager (simple JCEKS based one) and IBM® Security Key Lifecycle Manager (SKLM) server. You need to create one local key manager per cluster. The SKLM key manager is optional and might be created per cluster or per sets of file systems, depending on your security needs.
Binding your file system or fileset to the Cloud service by creating a container pair set
Up to this point, the configuration work was about creating access out to the cloud. Now, you need to bind all this to the data on your cluster, and you do that by creating a container pair set that associates your file system or fileset to the Cloud service. Once you create your container pair set, your Cloud service is usable.
Backing up the Cloud services database to the cloud
Transparent cloud tiering database stores critical information, such as the list of files that are migrated to the cloud and the list of files that are deleted from the cloud, which is associated with each container. It is essential to back up this database for any type of disaster recovery.
Backing up the Cloud services configuration
It is critical that the Cloud services configuration data that is stored in the CCR is always backed up.
Configuring the maintenance windows
This topic describes the procedure for setting up a maintenance window in Cloud services.
Enabling a policy for Cloud data sharing export service
This topic describes how to create a policy for export, a service provided by the IBM Storage Scale Cloud services, Cloud data sharing.
Tuning Cloud services parameters
This topic describes the tunable parameters for Cloud services and the commands to modify them.
Integrating Cloud services metrics with the performance monitoring tool
This topic describes the procedure for integrating Cloud services server nodes with the performance monitoring tool.
Setting up Transparent cloud tiering service on a remotely mounted client
Deploying WORM solutions
This topic describes how you can set up a WORM (write once and read many) solution by using IBM Storage Scale, Transparent cloud tiering, and IBM Cloud® Object Storage.

Parent topic: Configuring