Menu Close
Settings Close

Language and Page Formatting Options

Chapter 1. Preparing to deploy OpenShift Container Storage

When you deploy OpenShift Container Storage on OpenShift Container Platform using local storage devices, it provides you with the option to create internal cluster resources. This results in the internal provisioning of the base services, which helps to make additional storage classes available to applications.

Before you begin the deployment of Red Hat OpenShift Container Storage using local storage, ensure that your resource requirements are met. For more information, see requirements for installing OpenShift Container Storage using local storage devices.

After you have addressed the above, follow the sections in the order given:

1.1. 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.

For more information, see the Resource requirements section in the Planning guide.

Arbiter stretch cluster requirements [Technology Preview]

In this case, a single cluster is stretched across two zones with a third zone as the location for the arbiter. This is a technology preview feature that is currently intended for deployment in the OpenShift Container Platform on-premises.

For detailed requirements and instructions, see Configuring OpenShift Container Storage for Metro-DR stretch cluster.

Note

You cannot enable both flexible scaling and arbiter as they have conflicting scaling logic. With flexing scaling, you can add one node at a time to the OpenShift Container Storage cluster. Whereas, in an arbiter cluster, you need to add at least one node in each of the 2 data zones.

Compact mode requirements

OpenShift Container Storage can be installed on a three-node OpenShift compact bare metal cluster, where all the workloads run on three strong master nodes. There are no worker or storage nodes.

To configure OpenShift Container Platform in compact mode, see Configuring a three-node cluster and Delivering a Three-node Architecture for Edge Deployments.

Minimum starting node requirements [Technology Preview]

An OpenShift Container Storage cluster is deployed with minimum configuration when the standard deployment resource requirement is not met.

For more information, see Resource requirements section in the Planning guide.

1.2. Enabling file system access for containers on Red Hat Enterprise Linux based nodes

Deploying OpenShift Container Storage on an OpenShift Container Platform with worker nodes on a Red Hat Enterprise Linux base in a user provisioned infrastructure (UPI) does not automatically provide container access to the underlying Ceph file system.

Note

Skip this section for hosts based on Red Hat Enterprise Linux CoreOS (RHCOS).

Procedure

  1. Log in to the Red Hat Enterprise Linux based node and open a terminal.
  2. For each node in your cluster:

    1. Verify that the node has access to the rhel-7-server-extras-rpms repository.

      # subscription-manager repos --list-enabled | grep rhel-7-server

      If you do not see both rhel-7-server-rpms and rhel-7-server-extras-rpms in the output, or if there is no output, run the following commands to enable each repository.

      # subscription-manager repos --enable=rhel-7-server-rpms
      # subscription-manager repos --enable=rhel-7-server-extras-rpms
    2. Install the required packages.

      # yum install -y policycoreutils container-selinux
    3. Persistently enable container use of the Ceph file system in SELinux.

      # setsebool -P container_use_cephfs on

1.3. Enabling key value backend path and policy in Vault

Prerequisites

  • Administrator access to Vault.
  • 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