- Each service instance must write its data to a unique location. A unique location can be a file system or a unique path on a shared external storage server.
In this illustration, green arrows show acceptable configurations and red arrows show unacceptable configurations where multiple service instances are writing to the same volume, or multiple volumes are backed by the same storage location:
- For persistent (non-floating) services, favor using the ${container_inst_uuid} variable in your option/value pairs. For persistent services, this variable resolves to a value that's unique to each service instance. See Available variables.
This is especially useful if the volume driver you're using is backed by a shared server. By providing a variable that resolves to a unique value, the volume driver can use the resolved variable to create unique directories on the shared server.
However, some volume drivers, such as Docker's local volume driver, do not support automatic directory creation. If you're using such a volume driver, you need to create volume directories yourself. For an example of how to handle this, see Example: Docker local volume driver for Database service log volume.
- Floating services do not support volumes that are backed by shared servers. This is because floating services do not have access to variables that resolve to unique values per service instance. See Available variables.
For services with multiple types, consider specifying the type name as a part of the path to where service instances of that type write their data:
/example/typeA/${node_ip}
/example/typeB/${node_ip}
For information about the ${node_ip} variable, see Available variables.
- Make sure the options and values you specify are valid. Incorrect options or values can cause system deployment to fail or volumes to be set up incorrectly. For information on volumes, see the volume driver's documentation.
Available variables
You can include these variables when configuring volume options:
- ${install_dir} is the product installation directory.
- ${data_dir} is equal to ${install_dir}/data
- ${log_dir} is equal to ${install_dir}/log
- ${volume_def_name} is the name of the volume you are configuring.
- ${plugin_name} is the name of the underlying service plugin.
- ${container_inst_uuid} is the UUID for the Docker container in which the service instance or job runs. For floating services, this is the same value for all instances of the service.
- ${node_ip} is the IP address for the system instance on which the service or job is running. This cannot be used for floating services.
- ${instance_uuid} is the UUID for the system instance. This cannot be used for floating services. For services with multiple types, this variable resolves to the same value for all instances of the service, regardless of their types.
Example: bind-mount configuration for Database service log volume
The built-in Database service has a volume called log, which stores the service's logs. The log volume has this default configuration:
-
Volume driver: bind-mount
-
Option: hostname, Value: ${log_dir}/${plugin_name}/${container_inst_uuid}
With this configuration, after the system is deployed, logs for the Database service are stored at a unique path on each system instance that runs the Database service:
/<install-dir>/log/com.hds.ensemble.plugins.service.cassandra/service-instance-uuid
For example:
/home/hci/log/com.hds.ensemble.plugins.service.cassandra/12345678-1234-1234-1234-123456789012
Example: Docker local volume driver for Database service log volume
Alternatively, you can configure the Database service to use Docker's built-in local volume driver to store logs on an NFS server. To do this:
- Log in to your NFS server.
- Create a directory.
- Within that directory, create one directory for each of the instances in your system. Name each one using the instance IP address. Note: In this example, you need to create these directories yourself because the local storage driver will not create them automatically.
- Back in the system deployment wizard, in the Volume Driver field, specify local
- Specify these options and values:
Option Value type nfs
o addr=nfs-server-ip,rw
device :/path-to-directory-created-in-step b above/${node_ip}
With this configuration, each instance of the Database service stores its logs in a different directory on your NFS server.