Optional: Configure volumes for services

• If you're using the bind-mount setting, you can edit the value for the hostpath option to change the path where the volume's data is stored on each system instance. However, this must be a path within the HCP for cloud scale installation folder.
• If you're using a volume driver:
  1. Click the trashcan icon to remove the default hostpath option. This option applies only when you are using the bind-mount setting.
  2. Type the name of a volume driver option in the Option field. Then type the corresponding parameter for that option in the Value field.
  3. Click the plus-sign icon to add the option/value pair.
  4. Repeat this procedure for each option/value pair you want to add.

Option/value pairs can specify where data is written to in each volume. These considerations apply:

• 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 (that is, 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.

  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 Folder creation. If you're using such a volume driver, you need to create volume folders yourself. For an example of how to handle this, see the following Docker local volume driver example.

• Floating services do not support volumes that are backed by shared servers, because floating services do not have access to variables that resolve to unique values per service instance.
• Make sure the options and values you specify are valid. Options or values that are not valid can cause system deployment to fail or volumes to be set up incorrectly. For information on volumes, see the volume driver's documentation.

You can include these variables when configuring volume options:

• ${install_dir} is the product installation folder.
• ${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 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 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.