Installation

Requirements

Ember-CSI has the following requirements:

  • Operating system: A Red Hat Linux distribution (support for other distributions is possible but not currently provided by the project): - Centos 7 and Centos 8 - RHEL 7 and RHEL 8 - Fedora
  • Container Orchestrator: Both Kubernetes and OpenShift are supported: - Openshift: Recommended version 4.4 or newer. Supported from version 3.10 onward. - Kubernetes: Recommended version 1.17 or newer. Supported from version 1.11 onward.
  • Storage solution: Access and credentials to a supported storage solution.
  • Network: Network connections must be setup appropriately. - Controller nodes: Must have access to the storage management interface. Some drivers require access to the storage data network as well. - Worker nodes: Must have access to the storage data network.
  • Services: Depending on the driver and the configuration we may need additional services running on worker nodes and in some drivers controller nodes.
    • iSCSI: For iSCSI drivers the iSCSI initiator, iscsid provided by the iscsi-initiator-utils package must be configured and running. It can be running baremetal or in a container as long as the appropriate directories from the host are mounted.
    • Multipathing: When selecting multipathing on iSCSI and FC drivers we’ll need to have multipathd, provided by the device-mapper-multipath package, configured and running. It can be running baremetal or in a container as long as the appropriate directories from the host are mounted.

OpenShift

To eliminate configuration and deployment complexities and the errors that come with them, the recommended mechanism to deploy Ember-CSI is using its operator, which makes installing Ember-CSI a simple and intuitive process.

After logging in the OpenShift console as an administrator we go to the OperatorHub:

_images/01-operatorhub.png

Then we search for the Ember-CSI operator and click on it:

_images/02-operatorhub-search-ember.png

If we are installing the Community Operator we’ll be required to confirm that we understand the implications. We click Continue:

_images/03-confirm-community.png

And we are presented with the Ember-CSI Operator page, where we click Install:

_images/04-install-1.png

And then Install again:

_images/05-install-2.png

This will trigger the download and execution of the operator container image. It will take a couple of seconds, and in the meantime we’ll see that the installation is in progress and maybe a couple of weird entries saying at the beginning:

_images/06-installing.png

Once the operator reaches the Succeeded status we click on it:

_images/07-succeeded.png

Inside the Ember-CSI operator page we create a new Storage Backend instance:

_images/08-create-storage-banckend.png

Backends can be configured using YAML, but this is a cumbersome process, so it’s usually only used on automated processes such as CI systems, and the Ember-CSI team recommends using the form interface when doing things manually, which is the default on OpenShift 4.5.

In the form we should change the name field from default to a unique and meaningful name to identify this backend. Then go to the Driver dropdown and select the name of our storage backend. After selecting the appropriate driver the relevant configuration optionsfor the selected driver will be displayed.

_images/09-name-and-driver.png

After setting the configuration options we click Create at the botom of the page:

_images/10-create-backend.png

And a new EmberStorageBackend entity will be created. Don’t wait for the Status to change, since it won’t:

_images/11-EmberStorageBackends.png

You can see that the deployment is complete going to Stateful Sets, Daemon Sets, and Replica Sets pages in the Workloads section to see that the deployed pods are running:

_images/12-StatefulSet.png _images/13-DaemonSet.png _images/14-ReplicaSets.png

You can also check that a new Storage Class has been created in Storage > Storage Classes. The name of the new class will be example.ember-csi.io where example will be the name you gate to the Storage Backend in the form:

_images/15-StorageClass.png

We can set this Storage Class as the default class by going to its actions and selecting Edit Annotations:

_images/16-edit-annotations.png

And then adding key storageclass.kubernetes.io/is-default-class with the value of true.

_images/17-default-sc.png

Warning

If you already have a default and you want to change it to this one, you’ll you need to modify the current default by removing the annotation or setting it to false.

If we have configured everything right we’ll now be able to use our storage solution into OpenShift using the new StorageClass that was created by the operator. In the usage section there is information on how to use the new Storage Backend.

If you see problems in the new Stateful, Daemon, or Replica Sets, please refer to the troubleshooting guide for details on how to resolve installation issues.