Skip to content

Latest commit

 

History

History
243 lines (174 loc) · 8.52 KB

persistent_storage_glusterfs.adoc

File metadata and controls

243 lines (174 loc) · 8.52 KB

Persistent Storage Using {gluster}

{product-author} {product-version} :data-uri: :icons: :experimental: :toc: macro :toc-title: :prewrap!:

Considerations

This section covers a few topics that should be taken into consideration when using {gluster} with {product-title}.

Volume Security

This section covers {gluster} volume security, including Portable Operating System Interface [for Unix] (POSIX) permissions and SELinux considerations. Understanding the basics of Volume Security, POSIX permissions, and SELinux is presumed.

Installation

For standalone {gluster}, there is no component installation required to use it with {product-title}. {product-title} comes with a built-in GlusterFS volume driver, allowing it to make use of existing volumes on existing clusters. See provisioning for more on how to make use of existing volumes.

For {gluster-native} and {gluster-external}, it is recommended to use the cluster installation process to install the required components.

{gluster-external}: Installing {gluster} Nodes

Using the Installer

The cluster installation process can be used to install one or both of two GlusterFS node groups:

  • glusterfs: A general storage cluster for use by user applications.

  • glusterfs-registry: A dedicated storage cluster for use by infrastructure applications such as an integrated OpenShift Container Registry.

It is recommended to deploy both groups to avoid potential impacts on performance in I/O and volume creation. Both of these are defined in the inventory hosts file.

The definition of the clusters is done by including the relevant names in the [OSEv3:children] group, creating similarly named groups, and then populating the groups with the node information. The clusters can then be configured through a variety of variables in the [OSEv3:vars] group. glusterfs variables begin with openshift_storage_glusterfs_ and glusterfs-registry variables begin with openshift_storage_glusterfs_registry_. A few other variables, such as openshift_hosted_registry_storage_kind, interact with the GlusterFS clusters.

It is recommended to specify version tags for all containerized components. This is primarily to prevent components, particularly the {gluster} pods, from upgrading after an outage which may lead to a cluster of widely disparate software versions. The relevant variables are:

  • openshift_storage_glusterfs_version

  • openshift_storage_glusterfs_block_version

  • openshift_storage_glusterfs_s3_version

  • openshift_storage_glusterfs_heketi_version

  • openshift_storage_glusterfs_registry_version

  • openshift_storage_glusterfs_registry_block_version

  • openshift_storage_glusterfs_registry_s3_version

  • openshift_storage_glusterfs_registry_heketi_version

For a complete list of variables, see the GlusterFS role README on GitHub.

Once the variables are configured, there are several playbooks available depending on the circumstances of the installation:

  • The main playbook for cluster installations can be used to deploy the GlusterFS clusters in tandem with an initial installation of {product-title}.

    • This includes deploying an integrated OpenShift Container Registry that uses GlusterFS storage.

    • This does not include OpenShift Logging or OpenShift Metrics, as that is currently still a separate step. See {gluster-native} for OpenShift Logging and Metrics for more information.

  • playbooks/openshift-glusterfs/config.yml can be used to deploy the clusters onto an existing {product-title} installation.

  • playbooks/openshift-glusterfs/registry.yml can be used to deploy the clusters onto an existing {product-title} installation. In addition, this will deploy an integrated OpenShift Container Registry which uses GlusterFS storage.

    Important

    There must not be a pre-existing registry in the {product-title} cluster.

  • playbooks/openshift-glusterfs/uninstall.yml can be used to remove existing clusters matching the configuration in the inventory hosts file. This is useful for cleaning up the {product-title} environment in the case of a failed deployment due to configuration errors.

    Note

    The GlusterFS playbooks are not guaranteed to be idempotent.
    Note

    Running the playbooks more than once for a given installation is currently not supported without deleting the entire GlusterFS installation (including disk data) and starting over.

Example: Basic {gluster-native} Installation

Example: {gluster-native} with an Integrated OpenShift Container Registry

Example: {gluster-native} for OpenShift Logging and Metrics

Example: {gluster-native} for Applications, Registry, Logging, and Metrics

Example: {gluster-external} for Applications, Registry, Logging, and Metrics

Provisioning

GlusterFS volumes can be provisioned either statically or dynamically. Static provisioning is available with all configurations. Only {gluster-native} and {gluster-external} support dynamic provisioning.