Operations Guide

1. Scaleup the OCP cluster to add the new node. For more information see, https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/configuring_clusters/#adding-cluster-hosts_adding-hosts-to-cluster

   Note
   • If the new node is already part of OCP cluster then skip this step and proceed with Step 2.
   • The OCP cluster can be scaled up to add new nodes as either compute nodes or infra nodes. For example, for infra it is node3.example.com openshift_node_group_name='node-config-infra' and for compute node it is node3.example.com openshift_node_group_name='node-config-compute'.

2. Configure the firewall rules:

   Note

   For adding a node to be successful, ensure the ports are opened for glusterd communication. For more information about the ports, see https://access.redhat.com/documentation/en-us/red_hat_gluster_storage/3.5/html/installation_guide/port_information

   1. Add the following rules to the /etc/sysconfig/iptables file of the newly added glusterfs node:

      -A OS_FIREWALL_ALLOW -p tcp -m state --state NEW -m tcp --dport 24007 -j ACCEPT
      -A OS_FIREWALL_ALLOW -p tcp -m state --state NEW -m tcp --dport 24008 -j ACCEPT
      -A OS_FIREWALL_ALLOW -p tcp -m state --state NEW -m tcp --dport 2222 -j ACCEPT
      -A OS_FIREWALL_ALLOW -p tcp -m state --state NEW -m multiport --dports 49152:49664 -j ACCEPT
      -A OS_FIREWALL_ALLOW -p tcp -m state --state NEW -m tcp --dport 24010 -j ACCEPT
      -A OS_FIREWALL_ALLOW -p tcp -m state --state NEW -m tcp --dport 3260 -j ACCEPT
      -A OS_FIREWALL_ALLOW -p tcp -m state --state NEW -m tcp --dport 111 -j ACCEPT

   2. Reload/restart the iptables:

      # systemctl restart iptables

3. Execute the following steps to add labels to the node where the RHGS Container will be deployed:

   1. Verify that Red Hat Openshift Container Storage is deployed and working as expected in the existing project by executing the following command:

      # oc get ds

      For example:

      # oc get ds
      NAME                DESIRED   CURRENT   READY     UP-TO-DATE   AVAILABLE   NODE SELECTOR            AGE
      glusterfs-storage   3         3         3         3            3           glusterfs=storage-host   1d

   2. Add the label for each node which is newly added, where the Red Hat Gluster Storage pods are to be added for the new cluster:

      # oc label node <NODE_NAME> glusterfs=<node_label>

      where,

      • NODE_NAME: is the name of the newly created node.
      • node_label: The name that is used in the existing daemonset. This is the value you get in the previous step when you execute oc get ds.

      For example:

      # oc label node 192.168.90.3 glusterfs=storage-host
      node "192.168.90.3" labeled

   3. Verify if the Red Hat Gluster Storage pods are running on the newly added node by executing the following command:

      Observe additional Gluster Storage pods spawned on these new nodes

      # oc get pods

      For example:

      # oc get pods
      NAME              READY     STATUS    RESTARTS   AGE
      glusterfs-356cf   1/1       Running   0          30d
      glusterfs-fh4gm   1/1       Running   0          30d
      glusterfs-hg4tk   1/1       Running   0          30d
      glusterfs-v759z   0/1       Running   0          1m

      You should see additional Gluster Storage pods, in this example 4 gluster pods instead of just 3 as before. It will take 1-2 minutes for them to become healthy. (i.e. glusterfs-v759z 0/1 not healthy yet).

   4. Verify if the Red Hat Gluster Storage pods are running

      # oc get pods -o wide -l glusterfs=storage-pod

4. Add a new node to the cluster by using Heketi CLI. Following shows an example of how to add new node in zone 1 to `597fceb5d6c876b899e48f599b988f54 ` cluster using the CLI:

   # heketi-cli node add --zone=1 --cluster=597fceb5d6c876b899e48f599b988f54 --management-host-name=node4.example.com --storage-host-name=192.168.10.104
   
   OUTPUT:
   Node information:
   Id: 095d5f26b56dc6c64564a9bc17338cbf
   State: online
   Cluster Id: 597fceb5d6c876b899e48f599b988f54
   Zone: 1
   Management Hostname node4.example.com
   Storage Hostname 192.168.10.104

5. Add devices to the cluster by using Heketi CLI. For more information on adding devices, refer Section 1.1.1, “Adding New Devices”.
6. Manually update the endpoints as they are not updated automatically when a node is added to a gluster trusted storage pool using heketi. For more information on how to update the endpoints, see Section 1.1.2.1, “Updating the endpoints after adding a new node”.

1. Verify that Red Hat Openshift Container Storage is deployed and working as expected in the existing project by executing the following command. :

   # oc get ds

   For example:

   # oc get ds
   NAME                DESIRED   CURRENT   READY     UP-TO-DATE   AVAILABLE   NODE SELECTOR            AGE
   glusterfs-storage   3         3         3         3            3           glusterfs=storage-host   1d

   Note

   Add new hosts by performing step 1 and step 2 in Section 1.1.2, “Adding New Nodes” section. Repeat the steps for all the nodes you want to add.

2. Verify if the Red Hat Gluster Storage pods are running by executing the following command:

   # oc get pods

3. Add the label for each node which is newly added , where the Red Hat Gluster Storage pods are to be added for the new cluster to start by executing the following command:

   # oc label node <NODE_NAME> glusterfs=<node_label>

   where,

   • NODE_NAME: is the name of the newly created node
   • node_label: The name that is used in the existing daemonset.

   For example:

   # oc label node 192.168.90.3 glusterfs=storage-host
   node "192.168.90.3" labeled

   Observe additional Gluster Storage pods spawned on these new nodes

   # oc get pods

   For example:

   # oc get pods
   NAME              READY     STATUS    RESTARTS   AGE
   glusterfs-356cf   1/1       Running   0          30d
   glusterfs-fh4gm   1/1       Running   0          30d
   glusterfs-hg4tk   1/1       Running   0          30d
   glusterfs-v759z   0/1       Running   0          1m
   glusterfs-rgs3k   0/1       Running   0          1m
   glusterfs-gtq9f   0/1       Running   0          1m

   You should see additional Gluster Storage pods, in this example 6 gluster pods instead of just 3 as before. It will take 1-2 minutes for them to become healthy. (i.e. glusterfs-v759z, glusterfs-rgs3k, and glusterfs-gtq9f 0/1 not healthy yet).

4. Verify if the Red Hat Gluster Storage pods are running by executing the following command:

   # oc get ds

   For example:

   # oc get ds
   NAME                DESIRED   CURRENT   READY     UP-TO-DATE   AVAILABLE   NODE SELECTOR            AGE
   glusterfs-storage   6         6         6         6            6           glusterfs=storage-host   2h

5. Create a new cluster in Heketi by using the following command:

   # heketi-cli cluster create

6. Add nodes and devices to the newly created cluster as described in sections Adding New Devices and Adding New Nodes.

1. Locate the device that has failed using the following command:

   # heketi-cli topology info

   …
   …
   ...
       Nodes:
   Node Id: 8faade64a9c8669de204b66bc083b10d
   ...
   ...
   …
                   Id:a811261864ee190941b17c72809a5001   Name:/dev/vdc            State:online    Size (GiB):499     Used (GiB):281     Free (GiB):218
                           Bricks:
                                   Id:34c14120bef5621f287951bcdfa774fc   Size (GiB):280     Path: /var/lib/heketi/mounts/vg_a811261864ee190941b17c72809a5001/brick_34c14120bef5621f287951bcdfa774fc/brick
   …
   …
   ...

   The example below illustrates the sequence of operations that are required to replace a failed device. The example uses device ID a811261864ee190941b17c72809a5001 which belongs to node with id 8faade64a9c8669de204b66bc083b10das.

2. Add a new device preferably to the same node as the device being replaced.

   # heketi-cli device add --name /dev/vdd --node 8faade64a9c8669de204b66bc083b10d
   Device added successfully

3. Disable the failed device.

   # heketi-cli device disable a811261864ee190941b17c72809a5001
   Device a811261864ee190941b17c72809a5001 is now offline

4. Remove the failed device.

   # heketi-cli device remove a811261864ee190941b17c72809a5001
   Device a811261864ee190941b17c72809a5001 is now removed

   At this stage, the bricks are migrated from the failed device. Heketi chooses a suitable device based on the brick allocation algorithm. As a result, there is a possibility that all the bricks might not be migrated to the newly added device.

5. Delete the failed device.

   1. Delete the device using the following heketi-cli delete command:

      # heketi-cli device delete a811261864ee190941b17c72809a5001
      Device a811261864ee190941b17c72809a5001 deleted

      Note
      • You can use the --force-forget option along with the Heketi-cli device delete <device-ID> command to delete failed devices. However, it is recommended to use this option only when the device delete command fails.
      • You must ensure that the device is removed or the system is clean outside of heketi using the system commands and only then use the --force-forget option.

   2. performance.read-ahead option must be disabled in order to allow the heal to complete.

      # gluster volume set <VOLUME> performance.read-ahead off

      Note

      Set performance.read-ahead option as OFF until the task of healing the volume is accomplished, once healing is complete set it back to the default state that is ON state.

   3. Extra shd’s must be started if more than 100,000 entries require healing. For more information on how to start additional self-heal daemon, see https://access.redhat.com/solutions/3794011

6. Before repeating the above sequence of steps on another device, you must wait for the self-heal operation to complete. You can verify that the self-heal operation completed when the Number of entries value returns a 0 value.

   # oc rsh <any_gluster_pod_name>
   for each in $(gluster volume list) ; do gluster vol heal $each info | grep "Number of entries:" ; done
   Number of entries: 0
   Number of entries: 0
   Number of entries: 0

1. Locate the node that has failed using the following command:

   # heketi-cli topology info
   
   …
   …
   ...
       Nodes:
   Node Id: 8faade64a9c8669de204b66bc083b10d
   ...
   ...
   …
             Id:a811261864ee190941b17c72809a5001   Name:/dev/vdc            State:online    Size (GiB):499     Used (GiB):281     Free (GiB):218
                     Bricks:
                             Id:34c14120bef5621f287951bcdfa774fc   Size (GiB):280     Path: /var/lib/heketi/mounts/vg_a811261864ee190941b17c72809a5001/brick_34c14120bef5621f287951bcdfa774fc/brick
   …
   …
   ...

   The example below illustrates the sequence of operations that are required to replace a failed node. The example uses node ID 8faade64a9c8669de204b66bc083b10d.

   Scale up the OCP cluster to add the replacement node. For more detail how to add a node, refer to the steps in section Section 1.1.2, “Adding New Nodes”.

   Note

   If the replacement node is already part of OCP cluster then skip this step and proceed with step 2.

2. Add a new node, preferably with the same number of devices and size as the node being replaced. Refer to the steps in section, Section 1.1.2, “Adding New Nodes”.

   # heketi-cli node add --zone=1 --cluster=597fceb5d6c876b899e48f599b988f54 --management-host-name=node4.example.com --storage-host-name=192.168.10.104
   
   # heketi-cli device add --name /dev/vdd --node 8faade64a9c8669de204b66bc083b10d
   
   Node and device added successfully

3. Disable the failed node.

   # heketi-cli node disable 8faade64a9c8669de204b66bc083b10d
   Node 8faade64a9c8669de204b66bc083b10d is now offline

4. Remove the failed node.

   # heketi-cli node remove 8faade64a9c8669de204b66bc083b10d
   Node 8faade64a9c8669de204b66bc083b10d is now removed

   At this stage, the bricks are migrated from the failed node. Heketi chooses a suitable device based on the brick allocation algorithm.

5. Delete the devices associated with the node by executing the following command as the nodes that have devices associated with it cannot be deleted:

   # heketi-cli device delete <device_id>

   For example:

   # heketi-cli device delete 56912a57287d07fad0651ba0003cf9aa
   Device 56912a57287d07fad0651ba0003cf9aa deleted

   Execute the command for every device on the node.

6. Delete the failed node.

   # heketi-cli node delete 8faade64a9c8669de204b66bc083b10d
   Node 8faade64a9c8669de204b66bc083b10d deleted

   Note

   If you want to replace a block from a node, refer to Section 3.2.2, “Replacing a node on Block Storage”

1. To specify the endpoints you want to create, update the copied sample-gluster-endpoints.yaml file with the endpoints to be created based on the environment. Each Red Hat Gluster Storage trusted storage pool requires its own endpoint with the IP of the nodes in the trusted storage pool.

   # cat sample-gluster-endpoints.yaml
   apiVersion: v1
   kind: Endpoints
   metadata:
     name: glusterfs-cluster
   subsets:
     - addresses:
         - ip: 192.168.10.100
       ports:
         - port: 1
     - addresses:
         - ip: 192.168.10.101
       ports:
         - port: 1
     - addresses:
         - ip: 192.168.10.102
       ports:
   - port: 1

   name

   The name of the endpoint.

   ip

   The ip address of the Red Hat Gluster Storage nodes.

2. Execute the following command to create the endpoints:

   # oc create -f <name_of_endpoint_file>

   For example:

   # oc create -f sample-gluster-endpoints.yaml
   endpoints "glusterfs-cluster" created

3. To verify that the endpoints are created, execute the following command:

   # oc get endpoints

   For example:

   # oc get endpoints
   NAME                       ENDPOINTS                                                     AGE
   storage-project-router     192.168.121.233:80,192.168.121.233:443,192.168.121.233:1936   2d
   glusterfs-cluster          192.168.121.168:1,192.168.121.172:1,192.168.121.233:1         3s
   heketi                     10.1.1.3:8080                                                 2m
   heketi-storage-endpoints   192.168.121.168:1,192.168.121.172:1,192.168.121.233:1         3m

4. Execute the following command to create a gluster service:

   # oc create -f <name_of_service_file>

   For example:

   # cat sample-gluster-service.yaml
   apiVersion: v1
   kind: Service
   metadata:
     name: glusterfs-cluster
   spec:
     ports:
   - port: 1

   # oc create -f sample-gluster-service.yaml
   service "glusterfs-cluster" created

5. To verify that the service is created, execute the following command:

   # oc get service

   For example:

   # oc get service
   NAME                       CLUSTER-IP      EXTERNAL-IP   PORT(S)                   AGE
   storage-project-router     172.30.94.109   <none>        80/TCP,443/TCP,1936/TCP   2d
   glusterfs-cluster          172.30.212.6    <none>        1/TCP                     5s
   heketi                     172.30.175.7    <none>        8080/TCP                  2m
   heketi-storage-endpoints   172.30.18.24    <none>        1/TCP                     3m

   Note

   The endpoints and the services must be created for each project that requires a persistent storage.

6. Create a 100G persistent volume with Replica 3 from GlusterFS and output a persistent volume specification describing this volume to the file pv001.json:

   $ heketi-cli volume create --size=100 --persistent-volume-file=pv001.json

   cat pv001.json
   {
     "kind": "PersistentVolume",
     "apiVersion": "v1",
     "metadata": {
       "name": "glusterfs-f8c612ee",
       "creationTimestamp": null
     },
     "spec": {
       "capacity": {
         "storage": "100Gi"
       },
       "glusterfs": {
         "endpoints": "TYPE ENDPOINT HERE",
         "path": "vol_f8c612eea57556197511f6b8c54b6070"
       },
       "accessModes": [
         "ReadWriteMany"
       ],
       "persistentVolumeReclaimPolicy": "Retain"
     },
     "status": {}

   Important

   You must manually add the Labels information to the .json file.

   Following is the example YAML file for reference:

   apiVersion: v1
   kind: PersistentVolume
   metadata:
     name: pv-storage-project-glusterfs1
     labels:
       storage-tier: gold
   spec:
     capacity:
       storage: 12Gi
     accessModes:
       - ReadWriteMany
     persistentVolumeReclaimPolicy: Retain
     glusterfs:
       endpoints: TYPE END POINTS NAME HERE,
   path: vol_e6b77204ff54c779c042f570a71b1407

   name

   The name of the volume.

   storage

   The amount of storage allocated to this volume

   glusterfs

   The volume type being used, in this case the glusterfs plug-in

   endpoints

   The endpoints name that defines the trusted storage pool created

   path

   The Red Hat Gluster Storage volume that will be accessed from the Trusted Storage Pool.

   accessModes

   accessModes are used as labels to match a PV and a PVC. They currently do not define any form of access control.

   labels

   Use labels to identify common attributes or characteristics shared among volumes. In this case, we have defined the gluster volume to have a custom attribute (key) named storage-tier with a value of gold assigned. A claim will be able to select a PV with storage-tier=gold to match this PV.

   Note
   • heketi-cli also accepts the endpoint name on the command line (--persistent-volume-endpoint=”TYPE ENDPOINT HERE”). This can then be piped to oc create -f - to create the persistent volume immediately.
   • If there are multiple Red Hat Gluster Storage trusted storage pools in your environment, you can check on which trusted storage pool the volume is created using the heketi-cli volume list command. This command lists the cluster name. You can then update the endpoint information in the pv001.json file accordingly.
   • When creating a Heketi volume with only two nodes with the replica count set to the default value of three (replica 3), an error "No space" is displayed by Heketi as there is no space to create a replica set of three disks on three different nodes.
   • If all the heketi-cli write operations (ex: volume create, cluster create..etc) fails and the read operations ( ex: topology info, volume info ..etc) are successful, then the possibility is that the gluster volume is operating in read-only mode.

7. Edit the pv001.json file and enter the name of the endpoint in the endpoint’s section:

   cat pv001.json
   {
     "kind": "PersistentVolume",
     "apiVersion": "v1",
     "metadata": {
       "name": "glusterfs-f8c612ee",
       "creationTimestamp": null,
       "labels": {
         "storage-tier": "gold"
       }
     },
     "spec": {
       "capacity": {
         "storage": "12Gi"
       },
       "glusterfs": {
         "endpoints": "glusterfs-cluster",
         "path": "vol_f8c612eea57556197511f6b8c54b6070"
       },
       "accessModes": [
         "ReadWriteMany"
       ],
       "persistentVolumeReclaimPolicy": "Retain"
     },
     "status": {}
   }

8. Create a persistent volume by executing the following command:

   # oc create -f pv001.json

   For example:

   # oc create -f pv001.json
   persistentvolume "glusterfs-4fc22ff9" created

9. To verify that the persistent volume is created, execute the following command:

   # oc get pv

   For example:

   # oc get pv
   
   NAME                 CAPACITY   ACCESSMODES   STATUS      CLAIM     REASON    AGE
   glusterfs-4fc22ff9   100Gi      RWX           Available                       4s

10. Create a persistent volume claim file. For example:

    # cat pvc.yaml
    apiVersion: v1
    kind: PersistentVolumeClaim
    metadata:
      name: glusterfs-claim
    spec:
      accessModes:
        - ReadWriteMany
      resources:
        requests:
          storage: 100Gi
        selector:
          matchLabels:
    storage-tier: gold

11. Bind the persistent volume to the persistent volume claim by executing the following command:

    # oc create -f pvc.yaml

    For example:

    # oc create -f pvc.yaml
    persistentvolumeclaim"glusterfs-claim" created

12. To verify that the persistent volume and the persistent volume claim is bound, execute the following commands:

    # oc get pv
    # oc get pvc

    For example:

    # oc get pv
    
    NAME                 CAPACITY   ACCESSMODES   STATUS    CLAIM                  REASON    AGE
    glusterfs-4fc22ff9   100Gi      RWX           Bound     storage-project/glusterfs-claim             1m

    # oc get pvc
    
    NAME              STATUS    VOLUME               CAPACITY   ACCESSMODES   AGE
    glusterfs-claim   Bound     glusterfs-4fc22ff9   100Gi      RWX           11s

13. The claim can now be used in the application. For example:

    # cat app.yaml
    
    apiVersion: v1
    kind: Pod
    metadata:
      name: busybox
    spec:
      containers:
        - image: busybox
          command:
            - sleep
            - "3600"
          name: busybox
          volumeMounts:
            - mountPath: /usr/share/busybox
              name: mypvc
      volumes:
        - name: mypvc
          persistentVolumeClaim:
    claimName: glusterfs-claim

    # oc create -f app.yaml
    pod "busybox" created

    For more information about using the glusterfs claim in the application see, https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/configuring_clusters/#install-config-storage-examples-gluster-example.

14. To verify that the pod is created, execute the following command:

    # oc get pods -n <storage_project_name>

    For example:

    # oc get pods -n storage-project
    
    NAME                               READY     STATUS    RESTARTS   AGE
    block-test-router-1-deploy         0/1       Running     0          4h
    busybox                            1/1       Running   0          43s
    glusterblock-provisioner-1-bjpz4   1/1       Running   0          4h
    glusterfs-7l5xf                    1/1       Running   0          4h
    glusterfs-hhxtk                    1/1       Running   3          4h
    glusterfs-m4rbc                    1/1       Running   0          4h
    heketi-1-3h9nb                     1/1       Running   0          4h

15. To verify that the persistent volume is mounted inside the container, execute the following command:

    # oc rsh busybox

    / $ df -h
    Filesystem                Size      Used Available Use% Mounted on
    /dev/mapper/docker-253:0-1310998-81732b5fd87c197f627a24bcd2777f12eec4ee937cc2660656908b2fa6359129
                          100.0G     34.1M     99.9G   0% /
    tmpfs                     1.5G         0      1.5G   0% /dev
    tmpfs                     1.5G         0      1.5G   0% /sys/fs/cgroup
    192.168.121.168:vol_4fc22ff934e531dec3830cfbcad1eeae
                           99.9G     66.1M     99.9G   0% /usr/share/busybox
    tmpfs                     1.5G         0      1.5G   0% /run/secrets
    /dev/mapper/vg_vagrant-lv_root
                           37.7G      3.8G     32.0G  11% /dev/termination-log
    tmpfs                     1.5G     12.0K      1.5G   0% /var/run/secretgit s/kubernetes.io/serviceaccount

1. Create a storage class file with the GID values. For example:

   # cat glusterfs-storageclass.yaml
   
   apiVersion: storage.k8s.io/v1
   kind: StorageClass
   metadata:
     name: gluster-container
   provisioner: kubernetes.io/glusterfs
   parameters:
     resturl: "http://heketi-storage-project.cloudapps.mystorage.com"
     restuser: "admin"
     secretNamespace: "default"
     secretName: "heketi-secret"
     gidMin: "2000"
   gidMax: "4000"

   Note

   If the gidMin and gidMax values are not provided, then the dynamic provisioned volumes will have the GID between 2000 and 2147483647.

2. Create a persistent volume claim. For more information see, Section 3.1.2.1.3, “Creating a Persistent Volume Claim”
3. Use the claim in the pod. Ensure that this pod is non-privileged. For more information see, Section 3.1.2.1.6, “Using the Claim in a Pod”

4. To verify if the GID is within the range specified, execute the following command:

   # oc rsh busybox

   $ id

   For example:

   $ id
   uid=1000060000 gid=0(root) groups=0(root),2001

   where, 2001 in the above output is the allocated GID for the persistent volume, which is within the range specified in the storage class. You can write to this volume with the allocated GID.

   Note

   When the persistent volume claim is deleted, the GID of the persistent volume is released from the pool.

Procedure

1. Apply the required tags on the heketi devices.

   # heketi-cli device settags <device-name> <key>:<value>

   Example :

   # heketi-cli device settags 1fe1b83e5660efb53cc56433cedf7771 disktype:hdd

2. Remove the applied tag from the device.

   # heketi-cli device rmtags <device-name> <key>

   Example :

   # heketi-cli device rmtags 1fe1b83e5660efb53cc56433cedf7771 disktype

3. Verify the added tag on the device.

   # heketi-cli device info <device-name>

   Example :

   # heketi-cli device info 1fe1b83e5660efb53cc56433cedf7771

   Example output :

   Device Id: 1fe1b83e5660efb53cc56433cedf7771
   State: online
   Size (GiB): 49
   Used (GiB): 41
   Free (GiB): 8
   Create Path: /dev/vdc
   Physical Volume UUID: GpAnb4-gY8e-p5m9-0UU3-lV3J-zQWY-zFgO92
   Known Paths: /dev/disk/by-id/virtio-bf48c436-04a9-48ed-9 /dev/disk/by-path/pci-0000:00:08.0 /dev/disk/by-path/virtio-pci-0000:00:08.0 /dev/vdc
   Tags:
     disktype: hdd    ---> added tag

4. Use tagged devices to create the volume.

    # heketi-cli volume create --size=<size in GiB> --gluster-volume-options'user.heketi.device-tag-match <key>=<value>’

   Important
   • When creating volumes, you must pass a new volume option user.heketi.device-tag-match where the value of the option is a tag key followed by either "=" or "!=" and followed by a tag value.
   • All matches are exact and case sensitive and only one device-tag-match can be specified.

   Example :

   # heketi-cli volume create --size=5 --gluster-volume-options 'user.heketi.device-tag-match disktype=hdd’

   Note

   Once a volume is created the volume options list is fixed. The tag-match rules persist with the volume metadata for volume expansion and brick replacement purposes.

5. Create a storage class.

   • Create a storage class that only creates volumes on hard disks.

     # cat hdd-storageclass.yaml

     apiVersion: storage.k8s.io/v1
     kind: StorageClass
     metadata:
       annotations:
         storageclass.kubernetes.io/is-default-class: "false"
       name: glusterfs-storage-hdd
       selfLink: /apis/storage.k8s.io/v1/storageclasses/glusterfs-storage
     parameters:
       resturl: http://heketi-storage.glusterfs.svc:8080
       restuser: admin
       secretName: heketi-storage-admin-secret
       secretNamespace: glusterfs
       volumeoptions: "user.heketi.device-tag-match disktype=hdd"
     provisioner: kubernetes.io/glusterfs
     reclaimPolicy: Delete
     volumeBindingMode: Immediate

   • Create a storage class that only creates volumes using faster solid state storage.

     Important

     You must use a negative tag matching rule that excludes hard disk devices.

     # cat sdd-storageclass.yaml

     apiVersion: storage.k8s.io/v1
     kind: StorageClass
     metadata:
       annotations:
         storageclass.kubernetes.io/is-default-class: "false"
       name: glusterfs-storage-dd
       selfLink: /apis/storage.k8s.io/v1/storageclasses/glusterfs-storage
     parameters:
       resturl: http://heketi-storage.glusterfs.svc:8080
       restuser: admin
       secretName: heketi-storage-admin-secret
       secretNamespace: glusterfs
       volumeoptions: "user.heketi.device-tag-match disktype!=hdd"
     provisioner: kubernetes.io/glusterfs
     reclaimPolicy: Delete
     volumeBindingMode: Immediate

1. Execute the following command to fetch the zone and cluster info from heketi

   # heketi-cli topology info --user=<user> --secret=<user key>

   --user

   heketi user

   --secret

   Secret key for a specified user

2. After obtaining the cluster id and zone id, refer to Adding New Nodes to add a new node.

3. Execute the following command to add the device

   # heketi-cli device add --name=<device name> --node=<node id> --user=<user> --secret=<user key>

   --name

   Name of device to add

   --node

   Newly added node id

   For example:

   # heketi-cli device add --name=/dev/vdc --node=2639c473a2805f6e19d45997bb18cb9c --user=admin --secret=adminkey
   Device added successfully

4. After the new node and its associated devices are added to heketi, the faulty or unwanted node can be removed from heketi

   To remove any node from heketi, follow this workflow:

   • node disable (Disallow usage of a node by placing it offline)
   • node replace (Removes a node and all its associated devices from Heketi)
   • device delete (Deletes a device from Heketi node)
   • node delete (Deletes a node from Heketi management)

5. Execute the following command to fetch the node list from heketi

   #heketi-cli node list --user=<user> --secret=<user key>

   For example:

   # heketi-cli node list --user=admin --secret=adminkey
   Id:05746c562d6738cb5d7de149be1dac04    Cluster:607204cb27346a221f39887a97cf3f90
   Id:ab37fc5aabbd714eb8b09c9a868163df    Cluster:607204cb27346a221f39887a97cf3f90
   Id:c513da1f9bda528a9fd6da7cb546a1ee    Cluster:607204cb27346a221f39887a97cf3f90
   Id:e6ab1fe377a420b8b67321d9e60c1ad1    Cluster:607204cb27346a221f39887a97cf3f90

6. Execute the following command to fetch the node info of the node, that has to be deleted from heketi:

   # heketi-cli node info <nodeid> --user=<user> --secret=<user key>

   For example:

   # heketi-cli node info c513da1f9bda528a9fd6da7cb546a1ee --user=admin --secret=adminkey
   Node Id: c513da1f9bda528a9fd6da7cb546a1ee
   State: online
   Cluster Id: 607204cb27346a221f39887a97cf3f90
   Zone: 1
   Management Hostname: dhcp43-171.lab.eng.blr.redhat.com
   Storage Hostname: 10.70.43.171
   Devices:
   Id:3a1e0717e6352a8830ab43978347a103   Name:/dev/vdc            State:online    Size (GiB):499     Used (GiB):100     Free (GiB):399     Bricks:1
   Id:89a57ace1c3184826e1317fef785e6b7   Name:/dev/vdd            State:online    Size (GiB):499     Used (GiB):10      Free (GiB):489     Bricks:5

7. Execute the following command to disable the node from heketi. This makes the node go offline:

   # heketi-cli node disable <node-id> --user=<user> --secret=<user key>

   For example:

   # heketi-cli node disable ab37fc5aabbd714eb8b09c9a868163df --user=admin --secret=adminkey
   Node ab37fc5aabbd714eb8b09c9a868163df is now offline

8. Execute the following command to remove a node and all its associated devices from Heketi:

   #heketi-cli node remove <node-id> --user=<user> --secret=<user key>

   For example:

   # heketi-cli node remove ab37fc5aabbd714eb8b09c9a868163df --user=admin --secret=adminkey
   Node ab37fc5aabbd714eb8b09c9a868163df is now removed

9. Execute the following command to delete the devices from heketi node:

   # heketi-cli device delete <device-id> --user=<user> --secret=<user key>

   For example:

   # heketi-cli device delete 0fca78c3a94faabfbe5a5a9eef01b99c --user=admin --secret=adminkey
   Device 0fca78c3a94faabfbe5a5a9eef01b99c deleted

10. Execute the following command to delete a node from Heketi management:

    #heketi-cli node delete <nodeid> --user=<user> --secret=<user key>

    For example:

    # heketi-cli node delete ab37fc5aabbd714eb8b09c9a868163df --user=admin --secret=adminkey
    Node ab37fc5aabbd714eb8b09c9a868163df deleted

11. Execute the following commands on any one of the gluster pods to replace the faulty node with the new node:

    1. Execute the following command to get a list of block volumes hosted under block-hosting-volume:

       # gluster-block list <block-hosting-volume> --json-pretty

    2. Execute the following command to get the list of servers that are hosting the block volume, also save the GBID and PASSWORD values for later use:

       # gluster-block info <block-hosting-volume>/<block-volume> --json-pretty

    3. Execute the following command to replace the faulty node with the new node:

       # gluster-block replace <volname/blockname> <old-node> <new-node> [force]

       For example:

       {
         "NAME":"block",
         "CREATE SUCCESS":"192.168.124.73",
         "DELETE SUCCESS":"192.168.124.63",
         "REPLACE PORTAL SUCCESS ON":[
           "192.168.124.79"
         ],
         "RESULT":"SUCCESS"
       }
       
       Note: If the old node is down and does not come up again then you can force replace:
       gluster-block replace sample/block 192.168.124.63 192.168.124.73 force --json-pretty
       
       {
         "NAME":"block",
         "CREATE SUCCESS":"192.168.124.73",
         "DELETE FAILED (ignored)":"192.168.124.63",
         "REPLACE PORTAL SUCCESS ON":[
           "192.168.124.79"
         ],
         "RESULT":"SUCCESS"
       }

    Note

    The next steps are to be executed only if the block that is to be replaced is still in use.

12. Skip this step if the block volume is not currently mounted. If the block volume is in use by the application, we need to reload the mapper device on the initiator side.

    1. Identify the initiator node and targetname:

       To find initiator node:

       # oc get pods -o wide | grep <podname>

       where podname is the name of the pod on which the blockvolume is mounted.

       For example

       # oc get pods -o wide | grep cirros1 cirros1-1-x6b5n   1/1       Running   0          1h        10.130.0.5     dhcp46-31.lab.eng.blr.redhat.com    <none>

       To find the targetname:

       # oc describe pv <pv_name> | grep IQN

       For example:

       # oc describe pv pvc-c50c69db-5f76-11ea-b27b-005056b253d1 | grep IQN
         IQN: iqn.2016-12.org.gluster-block:87ffbcf3-e21e-4fa5-bd21-7db2598e8d3f

    2. Execute the following command on the initiator node to find the mapper device:

       # mount | grep <targetname>

    3. Reload the mapper device:

       # multipath -r mpathX

       For example:

       # mount | grep iqn.2016-12.org.gluster-block:d6d18f43-8a74-4b2c-a5b7-df1fa3f5bc9a/dev/mapper/mpatha on /var/lib/origin/openshift.local.volumes/plugins/kubernetes.io/iscsi/iface-default/192.168.124.63:3260-iqn.2016-12.org.gluster-block:d6d18f43-8a74-4b2c-a5b7-df1fa3f5bc9a-lun-0 type xfs (rw,relatime,seclabel,attr2,inode64,noquota)
       # multipath -r mpatha

13. Log out of the old portal by executing the following command on the initiator:

    # iscsiadm -m node -T <targetname> -p <old node> -u

    For example:

    # iscsiadm -m node -T iqn.2016-12.org.gluster-block:d6d18f43-8a74-4b2c-a5b7-df1fa3f5bc9a -p 192.168.124.63 -u
    Logging out of session [sid: 8, target: iqn.2016-12.org.gluster-block:d6d18f43-8a74-4b2c-a5b7-df1fa3f5bc9a, portal: 192.168.124.63,3260]
    Logout of [sid: 8, target: iqn.2016-12.org.gluster-block:d6d18f43-8a74-4b2c-a5b7-df1fa3f5bc9a, portal: 192.168.124.63,3260] successful.

14. To re-discover the new node execute the following command:

    # iscsiadm -m discovery -t st -p <new node>

    For example:

    # iscsiadm -m discovery -t st -p 192.168.124.73
    192.168.124.79:3260,1 iqn.2016-12.org.gluster-block:d6d18f43-8a74-4b2c-a5b7-df1fa3f5bc9a
    192.168.124.73:3260,2 iqn.2016-12.org.gluster-block:d6d18f43-8a74-4b2c-a5b7-df1fa3f5bc9a

15. Log in to the new portal by executing the following:

    1. Update the authentication credentials (use GBID and PASSWORD from step 11ii)

       # iscsiadm -m node -T <targetname> -o update -n node.session.auth.authmethod -v CHAP -n node.session.auth.username -v <GBID> -n node.session.auth.password -v <PASSWORD> -p <new node ip>

    2. Log in to the new portal

       # iscsiadm -m node -T <targetname> -p <new node ip> -l

       For example:

       # iscsiadm -m node -T iqn.2016-12.org.gluster-block:d6d18f43-8a74-4b2c-a5b7-df1fa3f5bc9a -o update -n node.session.auth.authmethod -v CHAP -n node.session.auth.username -v d6d18f43-8a74-4b2c-a5b7-df1fa3f5bc9a -n node.session.auth.password -v a6a9081f-3d0d-4e8b-b9b0-d2be703b455d -p 192.168.124.73
       # iscsiadm -m node -T iqn.2016-12.org.gluster-block:d6d18f43-8a74-4b2c-a5b7-df1fa3f5bc9a -p 192.168.124.73 -l

16. To verify if the enabled hosting volume is replaced and running successfully, execute the following command on the initiator:

    # ll /dev/disk/by-path/ip-* | grep <targetname> | grep <“new node ip”>

17. Ensure that you update a gluster block Persistent Volume (PV) with the new IP address.

    The PVs are immutable by definition, so you cannot edit the PV, which means that you cannot change the old IP address on the PV. A document was created with the procedure to workaroud this issue (recreate a new PV and delete the old PV definition using the same data/underlying storage device), see the Red Hat Knowledgebase solution Gluster block PVs are not updated with new IPs after gluster node replacement.

1. Create the /var/lib/glusterd/secure-access file.

   # touch /var/lib/glusterd/secure-access

1. Create the /var/lib/glusterd/secure-access file.

   # touch /var/lib/glusterd/secure-access

1. Ensure Red Hat Openshift Container Storage is deployed before proceeding with further steps. For more information see, https://access.redhat.com/documentation/en-us/red_hat_openshift_container_storage/3.11/html-single/deployment_guide/#chap-Documentation-Red_Hat_Gluster_Storage_Container_Native_with_OpenShift_Platform-Setting_the_environment-Deploy_CNS

2. You can either create a statically provisioned volume or a dynamically provisioned volume. For more information about static provisioning of volumes, see https://access.redhat.com/documentation/en-us/red_hat_openshift_container_storage/3.11/html-single/operations_guide/#chap-Documentation-Red_Hat_Gluster_Storage_Container_Native_with_OpenShift_Platform-OpenShift_Creating_Persistent_Volumes-Static_Prov. For more information about dynamic provisioning of volumes, see https://access.redhat.com/documentation/en-us/red_hat_openshift_container_storage/3.11/html-single/operations_guide/#chap-Documentation-Red_Hat_Gluster_Storage_Container_Native_with_OpenShift_Platform-OpenShift_Creating_Persistent_Volumes-Dynamic_Prov

   Note

   To enable encryption during the creation of statically provisioned volume, execute the following command:

    # heketi-cli volume create --size=100 --gluster-volume-options="client.ssl on","server.ssl on"

3. Stop the volume by executing the following command:

   # oc rsh <gluster_pod_name> gluster volume stop VOLNAME

   The gluster pod name is the name of one of the Red Hat Gluster Storage pods of the trusted storage pool to which the volume belongs.

   Note

   To get the VOLNAME, execute the following command:

   # oc describe pv <pv_name>

   For example:

   # oc describe pv  pvc-01569c5c-1ec9-11e7-a794-005056b38171
   Name:           pvc-01569c5c-1ec9-11e7-a794-005056b38171
   Labels:         <none>
   StorageClass:   fast
   Status:         Bound
   Claim:          storage-project/storage-claim68
   Reclaim Policy: Delete
   Access Modes:   RWO
   Capacity:       1Gi
   Message:
   Source:
       Type:               Glusterfs (a Glusterfs mount on the host that shares a pod's lifetime)
       EndpointsName:      glusterfs-dynamic-storage-claim68
       Path:               vol_0e81e5d6e46dcbf02c11ffd9721fca28
       ReadOnly:           false
   No events.

   The VOLNAME is the value of "path" in the above output.

4. Set the list of common names of all the servers to access the volume. Ensure to include the common names of clients which will be allowed to access the volume.

   # oc rsh <gluster_pod_name> gluster volume set VOLNAME auth.ssl-allow 'server1,server2,server3,client1,client2,client3'

   Note

   If you set auth.ssl-allow option with * as value, any TLS authenticated clients can mount and access the volume from the application side. Hence, you set the option’s value to * or provide common names of clients as well as the nodes in the trusted storage pool.

5. Enable the client.ssl and server.ssl options on the volume.

   # oc rsh <gluster_pod_name> gluster volume set VOLNAME client.ssl on
   # oc rsh <gluster_pod_name> gluster volume set VOLNAME server.ssl on

6. Start the volume.

   # oc rsh <gluster_pod_name> gluster volume start VOLNAME

1. Stop all the application pods that have the Red Hat Gluster Storage volumes.

2. Stop the volume.

   # oc rsh <gluster_pod_name> gluster volume stop VOLNAME

   The gluster pod name is the name of one of the Red Hat Gluster Storage pods of the trusted storage pool to which the volume belongs.

3. Set the list of common names for clients allowed to access the volume. Be sure to include the common names of all the servers.

   # oc rsh <gluster_pod_name> gluster volume set VOLNAME auth.ssl-allow 'server1,server2,server3,client1,client2,client3'

   Note

   If you set auth.ssl-allow option with * as value, any TLS authenticated clients can mount and access the volume from the application side. Hence, you set the option’s value to * or provide common names of clients as well as the nodes in the trusted storage pool.

4. Enable client.ssl and server.ssl on the volume by using the following command:

   # oc rsh <gluster_pod_name> gluster volume set VOLNAME client.ssl on
   # oc rsh <gluster_pod_name> gluster volume set VOLNAME server.ssl on

5. Start the volume.

   # oc rsh <gluster_pod_name> gluster volume start VOLNAME

6. Start the application pods to use the I/O encrypted Red Hat Gluster Storage volumes.

1. Stop all the application pods that have the Red Hat Gluster Storage volumes.

2. Stop all the volumes.

   # oc rsh <gluster_pod_name> gluster volume stop VOLNAME

3. Stop the Red Hat Gluster Storage pods.

   # oc delete daemonset glusterfs-storage

4. On deletion of daemon set the pods go down. To verify if the pods are down, execute the following command:

   # oc get pods

5. Create the /var/lib/glusterd/secure-access file on all OpenShift nodes.

   # touch /var/lib/glusterd/secure-access

6. Create the Red Hat Gluster Storage daemonset by executing the following command:

   Note

   For Ansible deployments, the image name and the version has to be specified in the template, before executing the command.

   # oc process glusterfs | oc create -f -

7. On creation of daemon set the pods are started. To verify if the pods are started, execute the following command:

   # oc get pods

8. Start all the volumes.

   # oc rsh <gluster_pod_name> gluster volume start VOLNAME

9. Start the application pods to use the management encrypted Red Hat Gluster Storage.

1. Stop all the application pods that have the Red Hat Gluster Storage volumes.

2. Stop all the volumes.

   # oc rsh <gluster_pod_name> gluster volume stop VOLNAME

3. Reset all the encryption options for a volume:

   # oc rsh <gluster_pod_name> gluster volume reset VOLNAME auth.ssl-allow
   # oc rsh <gluster_pod_name> gluster volume reset VOLNAME client.ssl
   # oc rsh <gluster_pod_name> gluster volume reset VOLNAME server.ssl

4. Delete the files that were used for network encryption using the following command on all the OpenShift nodes:

   # rm /etc/ssl/glusterfs.pem /etc/ssl/glusterfs.key /etc/ssl/glusterfs.ca

   Note

   Deleting these files in a setup where management encryption is enabled will result in glusterd failing on all gluster pods and hence should be avoided.

5. Stop the Red Hat Gluster Storage pods.

   # oc delete daemonset glusterfs

6. On deletion of daemon set the pods go down. To verify if the pods are down, execute the following command:

   # oc get pods

7. Create the Red Hat Gluster Storage daemonset by executing the following command:

   Note

   For Ansible deployments, the image name and the version has to be specified in the template, before executing the command.

   # oc process glusterfs | oc create -f -

8. On creation of daemon set the pods are started. To verify if the pods are started, execute the following command:

   # oc get pods

9. Start the volume.

   # oc rsh <gluster_pod_name> gluster volume start VOLNAME

10. Start the application pods to use the I/O encrypted Red Hat Gluster Storage volumes.

1. Stop all the application pods that have the Red Hat Gluster Storage volumes.

2. Stop all the volumes.

   # oc rsh <gluster_pod_name> gluster volume stop VOLNAME

3. Stop the Red Hat Gluster Storage pods.

   # oc delete daemonset glusterfs

4. On deletion of daemon set the pods go down. To verify if the pods are down, execute the following command:

   # oc get pods

5. Delete the /var/lib/glusterd/secure-access file on all OpenShift nodes to disable management encryption.

   # rm /var/lib/glusterd/secure-access

6. Delete the files that were used for network encryption using the following command on all the OpenShift nodes:

   # rm /etc/ssl/glusterfs.pem /etc/ssl/glusterfs.key /etc/ssl/glusterfs.ca

7. Create the Red Hat Gluster Storage daemonset by executing the following command:

   Note

   For Ansible deployments, the image name and the version has to be specified in the template, before executing the command.

   # oc process glusterfs | oc create -f -

8. On creation of daemon set the pods are started. To verify if the pods are started, execute the following command:

   # oc get pods

9. Start all the volumes.

   # oc rsh <gluster_pod_name> gluster volume start VOLNAME

10. Start the application pods to use the management encrypted Red Hat Gluster Storage.