Chapter 1. Preparing to deploy OpenShift Container Storage using Red Hat Virtualization platform

Before you begin the deployment of Red Hat OpenShift Container Storage using dynamic or local storage, ensure that your resource requirements are met. See Planning your deployment.

  1. Optional: If you want to enable cluster-wide encryption using an external Key Management System (KMS):

  2. Minimum starting node requirements [Technology Preview]

    An OpenShift Container Storage cluster will be deployed with minimum configuration when the standard deployment resource requirement is not met. See Resource requirements section in Planning guide.

  3. Ensure that the requirements for installing OpenShift Container Storage using local storage devices are met.

1.1. Enabling key value backend path and policy in Vault

Prerequisites

  • Administrator access to Vault.
  • Carefully, choose a unique path name as the backend path that follows the naming convention since it cannot be changed later.

Procedure

  1. Enable the Key/Value (KV) backend path in Vault.

    For Vault KV secret engine API, version 1: 

    $ vault secrets enable -path=ocs kv

    For Vault KV secret engine API, version 2: 

    $ vault secrets enable -path=ocs kv-v2

  2. Create a policy to restrict users to perform a write or delete operation on the secret using the following commands: 

    echo '
path "ocs/*" {
  capabilities = ["create", "read", "update", "delete", "list"]
}
path "sys/mounts" {
capabilities = ["read"]
}'| vault policy write ocs -

  3. Create a token matching the above policy: 

    $ vault token create -policy=ocs -format json

1.2. Requirements for installing OpenShift Container Storage using local storage devices

Node requirements

The cluster must consist of at least three OpenShift Container Platform worker nodes with locally attached-storage devices on each of them.

  • Each of the three selected nodes must have at least one raw block device available to be used by OpenShift Container Storage.
  • The devices you use must be empty; the disks must not include physical volumes (PVs), volume groups (VGs), or logical volumes (LVs) remaining on the disk.

See the Resource requirements section in Planning guide.

Arbiter stretch cluster requirements [Technology Preview]

  • You need a minimum of five nodes in three zones. Two zones include two nodes per data-center zone while the third zone includes one node. A master node can be used for the arbiter zone.
  • This solution is designed to be deployed where latencies do not exceed 4 milliseconds round-trip time (RTT) between locations. Contact Red Hat Customer Support if you are planning to deploy with higher latencies.

  • Each node must be pre-labeled with its zone label. To label the nodes use the following command: 

    $ oc label nodes <NodeNames> topology.kubernetes.io/zone='<label>'

    For example, you can label the nodes as follows:

    • topology.kubernetes.io/zone=arbiter to master or worker node
    • topology.kubernetes.io/zone=datacenter1 to at least two worker nodes
    • topology.kubernetes.io/zone=datacenter2 to at least two worker nodes

Minimum starting node requirements [Technology Preview]

An OpenShift Container Storage cluster will be deployed with minimum configuration when the standard deployment resource requirement is not met. See Resource requirements section in Planning guide.