운영 가이드

1. OCP 클러스터를 확장하여 새 노드를 추가합니다. 자세한 내용은 https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/configuring_clusters/#adding-cluster-hosts_adding-hosts-to-cluster에서 참조하십시오.

   참고
   • 새 노드가 OCP 클러스터에 이미 속하는 경우 이 단계를 건너뛰고 2단계로 진행합니다.
   • OCP 클러스터는 새 노드를 컴퓨팅 노드 또는 인프라 노드로 추가하도록 확장할 수 있습니다. 예를 들어 infra는 node3.example.com openshift_node_group_name='node-config-infra'이고 컴퓨팅 노드의 경우 node3.example.com openshift_node_group_name='node-config-compute'입니다.

2. 방화벽 규칙을 설정합니다.

   참고

   노드 추가가 성공하려면 pxe 통신용으로 포트가 열려 있는지 확인합니다. 포트에 대한 자세한 내용은 https://access.redhat.com/documentation/en-us/red_hat_gluster_storage/3.5/html/installation_guide/port_information을 참조하십시오.

   1. 새로 추가된 glusterfs 노드의 /etc/sysconfig/iptables 파일에 다음 규칙을 추가합니다.

      -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. iptables를 다시 로드/시작합니다.

      # systemctl restart iptables

3. 다음 단계를 실행하여 RHGS 컨테이너가 배포될 노드에 라벨을 추가합니다.

   1. 다음 명령을 실행하여 기존 프로젝트에서 Red Hat Openshift Container Storage가 배포되고 예상대로 작동하는지 확인합니다.

      # oc get ds

      예를 들면 다음과 같습니다.

      # 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. 새 클러스터에 대해 Red Hat Gluster Storage Pod를 추가할 각 노드에 대한 레이블을 추가합니다.

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

      다음과 같습니다.

      • NODE_NAME:는 새로 생성된 노드의 이름입니다.
      • node_label: 기존 daemonset에서 사용되는 이름입니다. oc get ds 를 실행할 때 이전 단계에서 얻은 값입니다.

      예를 들면 다음과 같습니다.

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

   3. 다음 명령을 실행하여 새로 추가된 노드에서 Red Hat Gluster Storage Pod가 실행 중인지 확인합니다.

      이러한 새 노드에서 생성된 추가 Gluster Storage 포드 관찰

      # oc get pods

      예를 들면 다음과 같습니다.

      # 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

      추가 Gluster Storage 포드(이 예에서는 이전과 마찬가지로 3개가 아닌 4개의 포드)가 표시되어야 합니다. 상태가 되는 데 1~2분(즉, glusterfs-v759z 0/1은 정상 상태가 아닌 경우)입니다.

   4. Red Hat Gluster Storage 포드가 실행 중인지 확인합니다.

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

4. Heketi CLI를 사용하여 클러스터에 새 노드를 추가합니다. 다음은 CLI를 사용하여 영역 1 의 새 노드를 '597fceb5d6c876b899e48f599e48f599b988f54' 클러스터에 추가하는 방법의 예를 보여줍니다.

   # 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. Heketi CLI를 사용하여 클러스터에 장치를 추가합니다. 장치 추가에 대한 자세한 내용은 1.1.1절. “새 장치 추가” 을 참조하십시오.

   참고

   heketi를 사용하여 gluster 신뢰할 수 있는 스토리지 풀에 노드를 추가하면 기존 끝점이 자동으로 업데이트되지 않습니다.
   끝점을 업데이트하려면 다음 명령을 실행합니다.

   # heketi-cli volume endpoint patch <volume-id>

   # oc patch ep <heketi-db-endpoint-name> -p <changes>

1. 다음 명령을 실행하여 기존 프로젝트에서 Red Hat Openshift Container Storage가 배포되고 예상대로 작동하는지 확인합니다. :

   # oc get ds

   예를 들면 다음과 같습니다.

   # 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

   참고

   1.1.2절. “새 노드 추가” 섹션에서 1단계와 2단계를 수행하여 새 호스트를 추가합니다. 추가할 모든 노드에 대해 단계를 반복합니다.

2. 다음 명령을 실행하여 Red Hat Gluster Storage Pod가 실행 중인지 확인합니다.

   # oc get pods

3. 다음 명령을 실행하여 새 클러스터가 시작되도록 Red Hat Gluster Storage 포드를 추가할 각 노드의 레이블을 추가합니다.

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

   다음과 같습니다.

   • NODE_NAME: 새로 생성된 노드의 이름입니다.
   • node_label: 기존 daemonset에서 사용되는 이름입니다.

   예를 들면 다음과 같습니다.

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

   이러한 새 노드에서 생성된 추가 Gluster Storage 포드 관찰

   # oc get pods

   예를 들면 다음과 같습니다.

   # 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

   추가 Gluster Storage 포드(이 예에서는 이전과 마찬가지로 3개가 아닌 6 Gluster 포드)가 표시되어야 합니다. 이 값이 정상 상태가 되는 데 1~2분(예: glusterfs-v759z, glusterfs-rgs3k, glusterfs-manageq9f 0/1은 정상 상태가 아닌)입니다.

4. 다음 명령을 실행하여 Red Hat Gluster Storage Pod가 실행 중인지 확인합니다.

   # oc get ds

   예를 들면 다음과 같습니다.

   # 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. 다음 명령을 사용하여 Heketi에 새 클러스터를 생성합니다.

   # heketi-cli cluster create

6. 새 장치 추가 및 새 노드 추가 섹션에 설명된 대로 새로 생성된 클러스터에 노드 및 장치를 추가합니다.

1. 다음 명령을 사용하여 실패한 장치를 찾습니다.

   # 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
   …
   …
   ...

   아래 예제에서는 실패한 장치를 교체하는 데 필요한 작업 시퀀스를 보여줍니다. 이 예에서는 ID 8faade64 a9c8669de204b66bc083b10das 가 있는 노드에 속하는 장치 ID a81126941b17c17c728a5001 을 사용합니다.

2. 교체 중인 장치와 동일한 노드에 새 장치를 더합니다.

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

3. 실패한 장치를 비활성화합니다.

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

4. 실패한 장치를 제거합니다.

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

   이 단계에서는 실패한 장치에서 brick이 마이그레이션됩니다. heketi는 벽돌 할당 알고리즘을 기반으로 적절한 장치를 선택합니다. 결과적으로 모든 brick을 새로 추가한 장치로 마이그레이션하지 못할 가능성이 있습니다.

5. 실패한 장치를 삭제합니다.

   1. 다음 heketi-cli delete 명령을 사용하여 장치를 삭제합니다.

      # heketi-cli device delete a811261864ee190941b17c72809a5001
      Device a811261864ee190941b17c72809a5001 deleted

      참고
      • Heketi-cli 장치 delete <device-ID> 명령과 함께 --force- forget 옵션을 사용하여 실패한 장치를 삭제할 수 있습니다. 그러나 device delete 명령이 실패하는 경우에만 이 옵션을 사용하는 것이 좋습니다.
      • 장치가 제거되었거나 시스템이 시스템 명령을 사용하여 heketi 외부에서 정리되었는지 확인한 다음 --force-forget 옵션만 사용해야 합니다.

   2. 복구가 완료될 수 있도록 performance.read-ahead 옵션을 비활성화해야 합니다.

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

      참고

      볼륨 복구 작업을 완료할 때까지 performance.read-ahead 옵션을 OFF 로 설정하고, 복구가 완료되면 ON 상태인 기본 상태로 다시 설정합니다.

   3. 10만 개 이상의 항목이 복구가 필요한 경우 추가 소진을 시작해야 합니다. 추가 자동 복구 데몬을 시작하는 방법에 대한 자세한 내용은 https://access.redhat.com/solutions/3794011을 참조하십시오.

6. 다른 장치에서 위의 단계 시퀀스를 반복하기 전에 자동 복구 작업이 완료될 때까지 기다려야 합니다. 항목 수 값이 0 값을 반환하면 자동 복구 작업이 완료되었는지 확인할 수 있습니다.

   # 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. 다음 명령을 사용하여 실패한 노드를 찾습니다.

   # 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
   …
   …
   ...

   아래 예제에서는 실패한 노드를 교체하는 데 필요한 작업 시퀀스를 보여줍니다. 예에서는 노드 ID 8faade64a9c8669de20b66bc083b10d를 사용합니다.

   OCP 클러스터를 확장하여 대체 노드를 추가합니다. 노드를 추가하는 방법에 대한 자세한 내용은 섹션 1.1.2절. “새 노드 추가” 의 단계를 참조하십시오.

   참고

   대체 노드가 OCP 클러스터에 이미 속하는 경우 이 단계를 건너뛰고 2단계를 진행합니다.

2. 교체 중인 노드와 동일한 장치를 갖는 새 노드를 추가합니다.

   # 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. 실패한 노드를 비활성화합니다.

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

4. 오류가 발생한 노드를 제거합니다.

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

   이 단계에서는 실패한 노드에서 번들이 마이그레이션됩니다. heketi는 벽돌 할당 알고리즘을 기반으로 적절한 장치를 선택합니다.

5. 연결된 장치가 있는 노드로 다음 명령을 실행하여 노드와 연결된 장치를 삭제할 수 없습니다.

   # heketi-cli device delete <device_id>

   예를 들면 다음과 같습니다.

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

   노드의 모든 장치에 대해 명령을 실행합니다.

6. 오류가 발생한 노드를 삭제합니다.

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

   참고

   노드에서 블록을 교체하려면 다음을 참조하십시오. 3.2.2절. “블록 스토리지에서 블록 교체”

1. 생성하려는 끝점을 지정하려면 환경에 따라 생성할 끝점으로 복사된 sample-gluster-endpoints.yaml 파일을 업데이트합니다. 각 Red Hat Gluster Storage 신뢰할 수 있는 스토리지 풀에는 신뢰할 수 있는 스토리지 풀에서 노드의 IP가 있는 자체 엔드포인트가 필요합니다.

   # 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

   끝점의 이름입니다.

   ip

   Red Hat Gluster Storage 노드의 ip 주소입니다.

2. 다음 명령을 실행하여 끝점을 생성합니다.

   # oc create -f <name_of_endpoint_file>

   예를 들면 다음과 같습니다.

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

3. 끝점이 생성되었는지 확인하려면 다음 명령을 실행합니다.

   # oc get endpoints

   예를 들면 다음과 같습니다.

   # 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. 다음 명령을 실행하여 gluster 서비스를 생성합니다.

   # oc create -f <name_of_service_file>

   예를 들면 다음과 같습니다.

   # 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. 서비스가 생성되었는지 확인하려면 다음 명령을 실행합니다.

   # oc get service

   예를 들면 다음과 같습니다.

   # 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

   참고

   영구 스토리지가 필요한 프로젝트마다 끝점과 서비스를 생성해야 합니다.

6. GlusterFS에서 Replica 3을 사용하여 100G 영구 볼륨을 생성하고 이 볼륨을 파일 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": {}

   중요

   .json 파일에 라벨 정보를 수동으로 추가해야 합니다.

   다음은 참조를 위한 YAML 파일의 예입니다.

   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

   볼륨의 이름입니다.

   storage

   이 볼륨에 할당된 스토리지 용량

   glusterfs

   사용 중인 볼륨 유형(이 경우 glusterfs 플러그인)

   끝점

   생성된 신뢰할 수 있는 스토리지 풀을 정의하는 끝점 이름입니다.

   경로

   신뢰할 수 있는 스토리지 풀에서 액세스할 Red Hat Gluster Storage 볼륨.

   accessModes

   accessModes는 PV 및 PVC와 일치하도록 라벨로 사용됩니다. 현재 액세스 제어 형식을 정의하지 않습니다.

   labels

   레이블을 사용하여 볼륨 간에 공유되는 공통 속성 또는 특성을 식별합니다. 이 경우 gluster 볼륨을 정의하여 storage-tier 라는 사용자 지정 속성(key)을 gold 값이 할당되어 있어야 합니다. 이 PV와 일치하도록 storage-tier=gold 가 있는 PV를 선택할 수 있습니다.

   참고
   • 또한 heketi-cli는 명령줄의 끝점 이름(--persistent-volume-endpoint="TYPE ENDPOINT here)을 허용합니다. 그런 다음 oc create -f - 로 파이프하여 영구 볼륨을 즉시 생성할 수 있습니다.
   • 환경에 Red Hat Gluster Storage 신뢰할 수 있는 스토리지 풀이 여러 개 있는 경우 heketi-cli volume list 명령을 사용하여 볼륨이 생성되는 신뢰할 수 있는 스토리지 풀을 확인할 수 있습니다. 이 명령은 클러스터 이름을 나열합니다. 그런 다음 pv001.json 파일에서 끝점 정보를 적절하게 업데이트할 수 있습니다.
   • 복제본 수가 기본값인 3개의 값(복제 공간 3)으로 설정된 두 개의 노드만 사용하여 Heketi를 생성할 때 서로 다른 세 개의 노드에 복제본 세트를 생성할 공간이 없으므로 오류 "No space"가 표시됩니다.
   • 모든 heketi-cli 쓰기 작업(ex: volume create, cluster create..etc)이 실패하고 읽기 작업( ex: topology info, volume info .etc)이 성공하면 gluster 볼륨이 읽기 전용 모드로 작동할 가능성이 있습니다.

7. pv001.json 파일을 편집하고 끝점의 섹션에 끝점 이름을 입력합니다.

   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. 다음 명령을 실행하여 영구 볼륨을 생성합니다.

   # oc create -f pv001.json

   예를 들면 다음과 같습니다.

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

9. 영구 볼륨이 생성되었는지 확인하려면 다음 명령을 실행합니다.

   # oc get pv

   예를 들면 다음과 같습니다.

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

10. 영구 볼륨 클레임 파일을 생성합니다. 예를 들면 다음과 같습니다.

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

11. 다음 명령을 실행하여 영구 볼륨 클레임에 영구 볼륨을 바인딩합니다.

    # oc create -f pvc.yaml

    예를 들면 다음과 같습니다.

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

12. 영구 볼륨 및 영구 볼륨 클레임이 바인딩되었는지 확인하려면 다음 명령을 실행합니다.

    # oc get pv
    # oc get pvc

    예를 들면 다음과 같습니다.

    # 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. 이제 애플리케이션에서 클레임을 사용할 수 있습니다. 예를 들면 다음과 같습니다.

    # 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

    애플리케이션에서 glusterfs 클레임을 사용하는 방법에 대한 자세한 내용은 https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/configuring_clusters/#install-config-storage-examples-gluster-example 을 참조하십시오.

14. Pod가 생성되었는지 확인하려면 다음 명령을 실행합니다.

    # oc get pods -n <storage_project_name>

    예를 들면 다음과 같습니다.

    # 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. 영구 볼륨이 컨테이너 내부에 마운트되었는지 확인하려면 다음 명령을 실행합니다.

    # 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. GID 값을 사용하여 스토리지 클래스 파일을 생성합니다. 예를 들면 다음과 같습니다.

   # 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"

   참고

   gidMin 및 gidMax 값을 제공하지 않으면 동적 프로비저닝 볼륨에 2000에서 2147483647 사이의 GID가 있습니다.

2. 영구 볼륨 클레임을 생성합니다. 자세한 내용은 다음을 참조하십시오. 3.1.2.1.3절. “영구 볼륨 클레임 생성”
3. Pod에서 클레임을 사용합니다. 이 Pod에 권한이 없는지 확인합니다. 자세한 내용은 다음을 참조하십시오. 3.1.2.1.6절. “Pod에서 클레임 사용”

4. GID가 지정된 범위 내에 있는지 확인하려면 다음 명령을 실행합니다.

   # oc rsh busybox

   $ id

   예를 들면 다음과 같습니다.

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

   여기서 위의 출력에서 2001은 스토리지 클래스에 지정된 범위 내에 있는 영구 볼륨에 할당된 GID입니다. 할당된 GID를 사용하여 이 볼륨에 작성할 수 있습니다.

   참고

   영구 볼륨 클레임이 삭제되면 영구 볼륨의 GID가 풀에서 해제됩니다.

절차

1. 필요한 태그를 heketi 장치에 적용합니다.

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

   예:

   # heketi-cli device settags 1fe1b83e5660efb53cc56433cedf7771 disktype:hdd

2. 장치에서 적용된 태그를 제거합니다.

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

   예:

   # heketi-cli device rmtags 1fe1b83e5660efb53cc56433cedf7771 disktype

3. 장치에 추가된 태그를 확인합니다.

   # heketi-cli device info <device-name>

   예:

   # heketi-cli device info 1fe1b83e5660efb53cc56433cedf7771

   출력 예 :

   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. 태그된 장치를 사용하여 볼륨을 만듭니다.

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

   중요
   • 볼륨을 생성할 때 새 볼륨 옵션 user.heketi.device-tag-match 를 전달해야 합니다. 여기서 옵션 값은 태그 키이고 "=" 또는 "!=" 및 뒤에 태그 값을 차례로 입력합니다.
   • 모든 일치는 정확하고 대소문자를 구분하며 하나의 device-tag-match만 지정할 수 있습니다.

   예:

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

   참고

   볼륨이 생성되면 볼륨 옵션 목록이 수정되었습니다. tag-match 규칙은 볼륨 확장 및 brick 교체 목적으로 볼륨 메타데이터로 유지됩니다.

5. 스토리지 클래스를 생성합니다.

   • 하드 디스크에서 볼륨만 생성하는 스토리지 클래스를 생성합니다.

     # 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

   • 더 빠른 솔리드 상태 스토리지를 사용하여 볼륨만 생성하는 스토리지 클래스를 생성합니다.

     중요

     하드 디스크 장치를 제외하는 음수 태그 일치 규칙을 사용해야 합니다.

     # 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. 다음 명령을 실행하여 heketi에서 영역 및 클러스터 정보를 가져옵니다.

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

   --user

   heketi 사용자

   --secret

   지정된 사용자의 시크릿 키

2. 클러스터 ID 및 영역 ID를 가져온 후 새 노드 추가 를 참조하여 새 노드를 추가합니다.

3. 다음 명령을 실행하여 장치를 추가합니다.

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

   --name

   추가할 장치 이름

   --node

   새로 추가된 노드 ID

   예를 들면 다음과 같습니다.

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

4. 새로운 노드와 관련 장치가 heketi에 추가되면 결함이 있거나 원치 않는 노드가 heketi에서 제거 될 수 있습니다.

   heketi에서 노드를 제거하려면 다음 워크플로우를 따르십시오.

   • node disable (DEallow usage of a node byplacing it offline)
   • node replace(노드 제거 및 Heketi에서 연결된 모든 장치 제거)
   • 장치 삭제( Heketi 노드에서 장치 삭제)
   • 노드 삭제( Heketi 관리에서 노드 삭제)

5. 다음 명령을 실행하여 heketi에서 노드 목록을 가져옵니다.

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

   예를 들면 다음과 같습니다.

   # 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. 다음 명령을 실행하여 heketi에서 삭제해야 하는 노드의 노드 정보를 가져옵니다.

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

   예를 들면 다음과 같습니다.

   # 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. 다음 명령을 실행하여 heketi에서 노드를 비활성화합니다. 그러면 노드가 오프라인 상태가 됩니다.

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

   예를 들면 다음과 같습니다.

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

8. 다음 명령을 실행하여 Heketi에서 노드와 연결된 모든 장치를 제거합니다.

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

   예를 들면 다음과 같습니다.

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

9. 다음 명령을 실행하여 heketi 노드에서 장치를 삭제합니다.

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

   예를 들면 다음과 같습니다.

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

10. 다음 명령을 실행하여 Heketi 관리에서 노드를 삭제합니다.

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

    예를 들면 다음과 같습니다.

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

11. gluster Pod 중 하나에서 다음 명령을 실행하여 문제가 있는 노드를 새 노드로 교체합니다.

    1. 다음 명령을 실행하여 block-hosting-volume에서 호스팅되는 블록 볼륨 목록을 가져옵니다.

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

    2. 다음 명령을 실행하여 블록 볼륨을 호스팅하는 서버 목록을 가져오고 나중에 사용할 수 있도록 GBID 및 managers 값을 저장합니다.

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

    3. 다음 명령을 실행하여 문제가 있는 노드를 새 노드로 교체합니다.

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

       예를 들면 다음과 같습니다.

       {
         "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"
       }

    참고

    다음 단계는 교체할 블록이 아직 사용 중인 경우에만 실행해야 합니다.

12. 블록 볼륨이 현재 마운트되어 있지 않은 경우 이 단계를 건너뜁니다. 블록 볼륨이 애플리케이션에서 사용 중인 경우 이니시에이터 측에서 매퍼 장치를 다시 로드해야 합니다.

    1. 이니시에이터 노드 및 targetname을 식별합니다.

       이니시에이터 노드를 찾으려면 다음을 수행합니다.

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

       여기서 podname은 blockvolume이 마운트된 Pod의 이름입니다.

       예를 들면 다음과 같습니다

       # 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>

       대상 이름을 찾으려면 다음을 수행합니다.

       # oc describe pv <pv_name> | grep IQN

       예를 들면 다음과 같습니다.

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

    2. 이니시에이터 노드에서 다음 명령을 실행하여 매퍼 장치를 찾습니다.

       # mount | grep <targetname>

    3. 매퍼 장치를 다시 로드합니다.

       # multipath -r mpathX

       예를 들면 다음과 같습니다.

       # 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. 이니시에이터에서 다음 명령을 실행하여 이전 포털에서 로그아웃합니다.

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

    예를 들면 다음과 같습니다.

    # 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. 새 노드를 다시 검색하려면 다음 명령을 실행합니다.

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

    예를 들면 다음과 같습니다.

    # 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. 다음을 실행하여 새 포털에 로그인합니다.

    1. 인증 인증 정보 업데이트 (단계 11ii에서 GBID 및 암호 해독 사용)

       # 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. 새 포털에 로그인합니다.

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

       예를 들면 다음과 같습니다.

       # 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. 활성화된 호스팅 볼륨이 교체되고 성공적으로 실행 중인지 확인하려면 이니시에이터에서 다음 명령을 실행합니다.

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

1. /var/lib/glusterd/secure-access 파일을 만듭니다.

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

1. /var/lib/glusterd/secure-access 파일을 만듭니다.

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

1. 추가 단계를 진행하기 전에 Red Hat Openshift Container Storage가 배포되었는지 확인합니다. 자세한 내용은 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. 정적으로 프로비저닝된 볼륨 또는 동적으로 프로비저닝된 볼륨을 생성할 수 있습니다. 볼륨의 정적 프로비저닝에 대한 자세한 내용은 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 을 참조하십시오. 볼륨의 동적 프로비저닝에 대한 자세한 내용은 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를 참조하십시오.

   참고

   정적으로 프로비저닝된 볼륨을 생성하는 동안 암호화를 활성화하려면 다음 명령을 실행합니다.

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

3. 다음 명령을 실행하여 볼륨을 중지합니다.

   # oc rsh <gluster_pod_name> gluster volume stop VOLNAME

   gluster 포드 이름은 볼륨이 속한 신뢰할 수 있는 스토리지 풀의 Red Hat Gluster Storage Pod 중 하나의 이름입니다.

   참고

   VOLNAME을 가져오려면 다음 명령을 실행합니다.

   # oc describe pv <pv_name>

   예를 들면 다음과 같습니다.

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

   VOLNAME은 위 출력에서 "path"의 값입니다.

4. 볼륨에 액세스할 모든 서버의 공통 이름 목록을 설정합니다. 볼륨에 액세스할 수 있는 클라이언트의 공통 이름을 포함해야 합니다.

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

   참고

   auth.ssl-allow 옵션을 * 값으로 설정하면 모든 TLS 인증 클라이언트가 애플리케이션 측에서 볼륨을 마운트하고 액세스할 수 있습니다. 따라서 옵션의 값을 *로 설정하거나 일반적인 클라이언트 이름과 신뢰할 수 있는 스토리지 풀의 노드를 제공합니다.

5. 볼륨에서 client.ssl 및 server.ssl 옵션을 활성화합니다.

   # 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. 볼륨을 시작합니다.

   # oc rsh <gluster_pod_name> gluster volume start VOLNAME

1. Red Hat Gluster Storage 볼륨이 있는 모든 애플리케이션 포드를 중지합니다.

2. 볼륨을 중지합니다.

   # oc rsh <gluster_pod_name> gluster volume stop VOLNAME

   gluster 포드 이름은 볼륨이 속한 신뢰할 수 있는 스토리지 풀의 Red Hat Gluster Storage Pod 중 하나의 이름입니다.

3. 볼륨에 액세스할 수 있는 클라이언트의 공통 이름 목록을 설정합니다. 모든 서버의 공통 이름을 포함해야 합니다.

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

   참고

   auth.ssl-allow 옵션을 * 값으로 설정하면 모든 TLS 인증 클라이언트가 애플리케이션 측에서 볼륨을 마운트하고 액세스할 수 있습니다. 따라서 옵션의 값을 *로 설정하거나 일반적인 클라이언트 이름과 신뢰할 수 있는 스토리지 풀의 노드를 제공합니다.

4. 다음 명령을 사용하여 볼륨에서 client.ssl 및 server.ssl을 활성화합니다.

   # 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. 볼륨을 시작합니다.

   # oc rsh <gluster_pod_name> gluster volume start VOLNAME

6. 애플리케이션 포드를 시작하여 I/O 암호화된 Red Hat Gluster Storage 볼륨을 사용합니다.

1. Red Hat Gluster Storage 볼륨이 있는 모든 애플리케이션 포드를 중지합니다.

2. 모든 볼륨을 중지합니다.

   # oc rsh <gluster_pod_name> gluster volume stop VOLNAME

3. Red Hat Gluster Storage 포드를 중지합니다.

   # oc delete daemonset glusterfs-storage

4. 데몬 세트를 삭제하면 Pod가 다운됩니다. Pod가 다운되었는지 확인하려면 다음 명령을 실행합니다.

   # oc get pods

5. 모든 OpenShift 노드에 /var/lib/glusterd/secure-access 파일을 만듭니다.

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

6. 다음 명령을 실행하여 Red Hat Gluster Storage 데몬 세트를 생성합니다.

   참고

   Ansible 배포의 경우 명령을 실행하기 전에 이미지 이름과 버전을 템플릿에 지정해야 합니다.

   # oc process glusterfs | oc create -f -

7. 데몬 세트 생성 시 Pod가 시작됩니다. Pod가 시작되었는지 확인하려면 다음 명령을 실행합니다.

   # oc get pods

8. 모든 볼륨을 시작합니다.

   # oc rsh <gluster_pod_name> gluster volume start VOLNAME

9. 관리 암호화된 Red Hat Gluster Storage를 사용하려면 애플리케이션 포드를 시작합니다.

1. Red Hat Gluster Storage 볼륨이 있는 모든 애플리케이션 포드를 중지합니다.

2. 모든 볼륨을 중지합니다.

   # oc rsh <gluster_pod_name> gluster volume stop VOLNAME

3. 볼륨의 모든 암호화 옵션을 재설정합니다.

   # 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. 모든 OpenShift 노드에서 다음 명령을 사용하여 네트워크 암호화에 사용된 파일을 삭제합니다.

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

   참고

   관리 암호화가 활성화된 설정에서 이러한 파일을 삭제하면 모든 Gluster Pod에서 Ingester가 실패하므로 피해야 합니다.

5. Red Hat Gluster Storage 포드를 중지합니다.

   # oc delete daemonset glusterfs

6. 데몬 세트를 삭제하면 Pod가 다운됩니다. Pod가 다운되었는지 확인하려면 다음 명령을 실행합니다.

   # oc get pods

7. 다음 명령을 실행하여 Red Hat Gluster Storage 데몬 세트를 생성합니다.

   참고

   Ansible 배포의 경우 명령을 실행하기 전에 이미지 이름과 버전을 템플릿에 지정해야 합니다.

   # oc process glusterfs | oc create -f -

8. 데몬 세트 생성 시 Pod가 시작됩니다. Pod가 시작되었는지 확인하려면 다음 명령을 실행합니다.

   # oc get pods

9. 볼륨을 시작합니다.

   # oc rsh <gluster_pod_name> gluster volume start VOLNAME

10. 애플리케이션 포드를 시작하여 I/O 암호화된 Red Hat Gluster Storage 볼륨을 사용합니다.

1. Red Hat Gluster Storage 볼륨이 있는 모든 애플리케이션 포드를 중지합니다.

2. 모든 볼륨을 중지합니다.

   # oc rsh <gluster_pod_name> gluster volume stop VOLNAME

3. Red Hat Gluster Storage 포드를 중지합니다.

   # oc delete daemonset glusterfs

4. 데몬 세트를 삭제하면 Pod가 다운됩니다. Pod가 다운되었는지 확인하려면 다음 명령을 실행합니다.

   # oc get pods

5. 모든 OpenShift 노드에서 /var/lib/glusterd/secure-access 파일을 삭제하여 관리 암호화를 비활성화합니다.

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

6. 모든 OpenShift 노드에서 다음 명령을 사용하여 네트워크 암호화에 사용된 파일을 삭제합니다.

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

7. 다음 명령을 실행하여 Red Hat Gluster Storage 데몬 세트를 생성합니다.

   참고

   Ansible 배포의 경우 명령을 실행하기 전에 이미지 이름과 버전을 템플릿에 지정해야 합니다.

   # oc process glusterfs | oc create -f -

8. 데몬 세트 생성 시 Pod가 시작됩니다. Pod가 시작되었는지 확인하려면 다음 명령을 실행합니다.

   # oc get pods

9. 모든 볼륨을 시작합니다.

   # oc rsh <gluster_pod_name> gluster volume start VOLNAME

10. 관리 암호화된 Red Hat Gluster Storage를 사용하려면 애플리케이션 포드를 시작합니다.