Optional: Configure volumes for services

Installing Hitachi Content Platform for Cloud Scale

Part Number
To change volume usage:
  1. On the Advanced Configuration page, select a service to configure.
  2. Click the Volumes tab. This tab displays the system-managed volumes that the service supports. By default, each built-in service has both Data and Log volumes.
  3. For each volume, provide Docker volume creation information:
    1. In the Volume Driver field, specify the name of the volume driver that the volume should use. To configure the volume not to use any volume driver, specify bind-mount, which is the default setting.
      Note: Volume drivers are provided by Docker and other third-party developers, not by the HCP for cloud scale system itself. For information on volume drivers, their capabilities, and their valid configuration settings, see the applicable Docker or third-party developer's documentation.
    2. In the Volume Driver Options section, in the Option and Value fields, specify any optional parameters and their corresponding values for the volume driver:
      • 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.
      Tip: Create test volumes by use the command docker volume create with your option/value pairs. Then, to test the volumes you created, use the command docker run hello-world --volume.

      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.
  4. Repeat this procedure for each service that you want to configure.

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:


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:

  1. Log in to your NFS server.
  2. Create a folder.
  3. Within that folder, create one folder 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 folders yourself because the local storage driver will not create them automatically.
  4. Back in the system deployment wizard, in the Volume Driver field, specify local
  5. Specify these options and values:
    Option Value
    type nfs
    o addr= nfs-server-ip,rw
    device :/path-to-folder-from-step-ii/${node_ip}

    With this configuration, each instance of the Database service stores its logs in a different folder on your NFS server.