운영 가이드

Red Hat OpenShift Container Storage 3.11

Red Hat Openshift Container Storage 구성 및 관리.

초록

이 가이드에서는 컨테이너 스토리지 배포 작동에 대한 정보를 제공합니다.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 용어를 교체하기 위해 최선을 다하고 있습니다. 먼저 마스터(master), 슬레이브(slave), 블랙리스트(blacklist), 화이트리스트(whitelist) 등 네 가지 용어를 교체하고 있습니다. 이러한 변경 작업은 작업 범위가 크므로 향후 여러 릴리스에 걸쳐 점차 구현할 예정입니다. 자세한 내용은 CTO Chris Wright의 메시지를 참조하십시오.

I 부. 관리

1장. 클러스터 관리

관리자는 heketi를 사용하면 단일 또는 여러 Red Hat Gluster Storage 클러스터를 관리하여 스토리지 용량을 추가하고 제거할 수 있습니다.

heketi는 Red Hat Gluster Storage 볼륨의 라이프사이클을 관리하는 데 사용할 수 있는 RESTful 관리 인터페이스를 제공합니다. Heketi를 사용하면 OpenStack Manila, Kubernetes 및 OpenShift와 같은 클라우드 서비스가 지원되는 지속성 유형으로 Red Hat Gluster Storage 볼륨을 동적으로 프로비저닝할 수 있습니다. heketi는 클러스터에서 번들의 위치를 자동으로 결정하여 다른 장애 도메인에 브릭과 해당 복제본을 배치해야 합니다. 또한 heketi는 여러 Red Hat Gluster Storage 클러스터를 지원하므로 클라우드 서비스가 단일 Red Hat Gluster Storage 클러스터로 제한되지 않고 네트워크 파일 스토리지를 제공할 수 있습니다.
Heketi를 사용하면 관리자가 더 이상 브릭스, 디스크 또는 신뢰할 수 있는 스토리지 풀을 관리하거나 구성하지 않습니다. heketi 서비스는 관리자의 모든 하드웨어를 관리하여 필요에 따라 스토리지를 할당할 수 있습니다. Heketi에 등록된 모든 디스크는 원시 형식으로 제공해야 하며, 디스크의 LVM을 사용하여 관리합니다.

참고

복제본 3 및 중재자 볼륨은 Heketi를 사용하여 생성할 수 있는 지원되는 볼륨 유형입니다.

heketi 볼륨 생성

heketi 볼륨 생성

Heketi에 대한 볼륨 생성 요청으로 2개의 영역 및 4개 노드에 분산된 브릭을 선택할 수 있습니다. Red Hat Gluster Storage에서 볼륨이 생성된 후 Heketi는 처음에 요청을 수행한 서비스에 볼륨 정보를 제공합니다.

1.1. 스토리지 용량 증가

다음과 같은 방법으로 스토리지 용량을 늘릴 수 있습니다.

  • 장치 추가
  • 새 노드 추가
  • 완전히 새 클러스터 추가.

1.1.1. 새 장치 추가

기존 노드에 장치를 추가하여 스토리지 용량을 늘릴 수 있습니다. 장치를 더 추가할 때 장치를 세트로 추가해야 합니다. 예를 들어 복제본 2의 복제본 수를 사용하여 분산 복제 볼륨을 확장하는 경우 하나 이상의 노드에 하나의 장치를 추가해야 합니다. 복제본 3을 사용하는 경우 하나 이상의 장치를 3개 이상의 노드에 추가해야 합니다.

다음과 같이 CLI를 사용하여 장치를 추가할 수 있습니다.

지정된 장치를 등록합니다. 다음 예제 명령은 장치의 /dev/sde를 노드 d6f2c22f2757bf67b1486d868dcb7794 에 추가하는 방법을 보여줍니다.

# heketi-cli device add --name=/dev/sde --node=d6f2c22f2757bf67b1486d868dcb7794
OUTPUT:
Device added successfully

1.1.2. 새 노드 추가

Heketi에 스토리지를 추가하는 또 다른 방법은 클러스터에 새 노드를 추가하는 것입니다. 장치 추가와 마찬가지로 CLI를 사용하여 기존 클러스터에 새 노드를 추가할 수 있습니다. 클러스터에 새 노드를 추가한 후 해당 노드에 새 장치를 등록해야 합니다.

참고

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

  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.1.3. 기존 Red Hat Openshift Container Storage 설치에 새 클러스터 추가

Red Hat Gluster Storage의 새 클러스터를 추가하여 스토리지 용량을 늘릴 수 있습니다. 새 클러스터의 노드는 OCP 노드(converged 모드) 또는 RHGS 노드(독립 모드)로 준비해야 합니다. 기존 Red Hat Openshift Container Storage 설치에 새 클러스터를 추가하려면 다음 명령을 실행합니다.

  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.2. 스토리지 용량 감소

또한 heketi는 스토리지 용량의 감소를 지원합니다. 장치, 노드 및 클러스터를 삭제하여 스토리지를 줄일 수 있습니다. 이러한 요청은 Heketi CLI 또는 API를 통해서만 수행할 수 있습니다. 명령줄 API 사용에 대한 자세한 내용은 Heketi API https://github.com/heketi/heketi/wiki/API 를 참조하십시오.

참고
  • ID는 heketi-cli topology info 명령을 실행하여 검색할 수 있습니다.

    # heketi-cli topology info
  • heketidbstorage 볼륨은 heketi 데이터베이스가 포함되어 있으므로 삭제할 수 없습니다.

1.2.1. 볼륨 삭제

다음 Heketi CLI 명령을 사용하여 볼륨을 삭제할 수 있습니다.

# heketi-cli volume delete <volume_id>

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

# heketi-cli volume delete 12b2590191f571be9e896c7a483953c3
Volume 12b2590191f571be9e896c7a483953c3 deleted

1.2.2. Bricks 삭제

다음 Heketi CLI 명령을 사용하여 볼륨에서 brick을 삭제할 수 있습니다.

# heketi-cli brick evict <brick_id>

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

# heketi-cli brick evict 000e649d15e7d2a7615de3c2878ee270
  Brick 000e649d15e7d2a7615de3c2878ee270 evicted

brick ID는 Heketi 토폴로지에서 확인할 수 있습니다. 벽돌은 하나의 단일 볼륨에 속하므로 벽돌 ID만 필요합니다. heketi는 brick이 연결된 볼륨을 자동으로 확인하고 새 brick으로 교체합니다.

1.2.3. 장치 삭제

장치를 삭제하면 heketi의 토폴로지에서 장치가 삭제됩니다. brick이 있는 장치는 삭제할 수 없습니다. 장치를 비활성화하고 제거하여 번들이 해제되어 있는지 확인해야 합니다.

1.2.3.1. 장치 비활성화 및 활성화

장치를 비활성화하면 장치에 대한 추가 brick 할당이 중지됩니다. 다음 Heketi CLI 명령을 사용하여 장치를 비활성화할 수 있습니다.

# heketi-cli device disable <device_id>

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

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

장치를 다시 활성화하려면 다음 명령을 실행합니다. 장치를 활성화하면 장치에 brick을 할당할 수 있습니다.

# heketi-cli device enable <device_id>

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

# heketi-cli device enable f53b13b9de1b5125691ee77db8bb47f4
Device f53b13b9de1b5125691ee77db8bb47f4 is now online

1.2.3.2. 장치 제거 및 삭제

장치를 제거하면 장치에서 기존 brick이 다른 장치로 이동합니다. 이렇게 하면 장치가 brick을 사용할 수 있는지 확인하는 데 도움이 됩니다. 장치는 비활성화한 후에만 제거할 수 있습니다.

  1. 다음 명령을 사용하여 장치 제거:

     # heketi-cli device remove <device_id>

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

    # heketi-cli device remove e9ef1d9043ed3898227143add599e1f9
    Device e9ef1d9043ed3898227143add599e1f9 is now removed
  2. 다음 명령을 사용하여 장치를 삭제합니다.

    # heketi-cli device delete <device_id>

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

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

    삭제된 장치를 재사용하는 유일한 방법은 장치를 heketi의 토폴로지에 다시 추가하는 것입니다.

1.2.4. 노드 삭제

장치가 추가된 노드는 삭제할 수 없습니다. 노드를 삭제하려면 노드와 연결된 장치를 삭제해야 합니다. 노드를 비활성화하고 제거하면 모든 기본 장치도 제거됩니다. 노드를 제거하면 해당 노드의 모든 장치를 삭제하고 마지막으로 노드를 삭제할 수 있습니다.

1.2.4.1. 노드 비활성화 및 활성화

노드를 비활성화하면 노드와 연결된 모든 장치에 대한 brick이 추가로 할당됩니다. 다음 Heketi CLI 명령을 사용하여 노드를 비활성화할 수 있습니다.

# heketi-cli node disable <node_id>

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

# heketi-cli node disable 5f0af88b968ed1f01bf959fe4fe804dc
Node 5f0af88b968ed1f01bf959fe4fe804dc is now offline

노드를 다시 활성화하려면 다음 명령을 실행합니다.

# heketi-cli node enable <node_id>

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

# heketi-cli node enable 5f0af88b968ed1f01bf959fe4fe804dc
Node 5f0af88b968ed1f01bf959fe4fe804dc is now online

1.2.4.2. 노드 제거 및 삭제

노드를 제거하면 노드의 모든 장치에서 기존 brick을 클러스터의 다른 장치로 이동합니다. 이렇게 하면 노드의 모든 장치가 brick을 사용할 수 있는지 확인하는 데 도움이 됩니다. 장치는 비활성화한 후에만 제거할 수 있습니다.

  1. 노드를 삭제하려면 다음 명령을 실행합니다.

    # heketi-cli node remove <node_id>

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

    # heketi-cli node remove 5f0af88b968ed1f01bf959fe4fe804dc
    Node 5f0af88b968ed1f01bf959fe4fe804dc is now removed
  2. 연결된 장치가 있는 노드로 다음 명령을 실행하여 노드와 연결된 장치를 삭제할 수 없습니다.

    # heketi-cli device delete <device_id>

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

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

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

  3. 다음 명령을 사용하여 노드를 삭제합니다.

    # heketi-cli node delete <node_id>

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

    # heketi-cli node delete 5f0af88b968ed1f01bf959fe4fe804dc
    Node 5f0af88b968ed1f01bf959fe4fe804dc deleted

    노드를 삭제하면 heketi 토폴로지에서 노드가 삭제됩니다. 삭제된 노드를 재사용하는 유일한 방법은 노드를 heketi의 토폴로지에 다시 추가하는 것입니다.

    참고
    • heketi를 사용하여 gluster 신뢰할 수 있는 스토리지 풀에서 노드가 삭제되면 기존 끝점이 자동으로 업데이트되지 않습니다.
      끝점을 업데이트하려면 다음 명령을 실행합니다.
    # heketi-cli volume endpoint patch <volume-id>
    # oc patch ep <heketi-db-endpoint-name> -p <changes>
    • 선택 사항- heketi를 사용하여 gluster 신뢰할 수 있는 스토리지 풀에서 노드가 삭제되면 삭제된 노드에서 실행 중인 Pod가 계속 있습니다. Pod를 제거하려면 다음 명령을 실행합니다.
    # oc label nodes <node name> glusterfs-

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

    # oc label node 192.168.90.3 glusterfs-
      node "192.168.90.3" labeled

    삭제된 glusterfs 포드가 중지되고 삭제된 노드에서 삭제되도록 하는 glusterfs=storage-host 레이블이 노드에서 제거됩니다. 유지보수 전에 필요한 단계에 대한 자세한 내용은 링크 https://access.redhat.com/documentation/en-us/red_hat_openshift_container_storage/3.11/html-single/operations_guide/index#necessary_steps_to_be_followed_before_maintenance를 참조하십시오.

1.2.5. 클러스터 삭제

다음 Heketi CLI 명령을 사용하여 클러스터를 삭제할 수 있습니다.

참고

클러스터를 삭제하기 전에 클러스터 내부의 모든 노드가 삭제되었는지 확인합니다.

# heketi-cli cluster delete <cluster_id>

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

# heketi-cli cluster delete 0e949d91c608d13fd3fc4e96f798a5b1
Cluster 0e949d91c608d13fd3fc4e96f798a5b1 deleted

1.3. 클러스터 리소스 교체

heketi는 장치와 노드의 교체를 지원합니다. 장치 및 노드 교체 절차가 다음 섹션에서 제공됩니다.

1.3.1. 장치 교체

heketi는 장치를 다른 장치로 교체하는 것을 허용하지 않습니다. 그러나 실패한 장치의 경우 실패한 장치를 교체하는 데 필요한 작업 시퀀스에 대해 아래 예제를 따릅니다.

  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.3.2. 노드 교체

heketi는 다른 노드를 일대일로 교체하는 것을 허용하지 않습니다. 그러나 실패한 노드의 경우 실패한 노드 및 해당 장치를 교체하는 데 필요한 작업 시퀀스에 대해 아래 예제를 따르십시오.

  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절. “블록 스토리지에서 블록 교체”

2장. OpenShift 환경에서 Red Hat Gluster Storage Pod 작업

이 장에서는 Red Hat Gluster Storage Pod(gluster Pod)에서 수행할 수 있는 다양한 작업을 나열합니다.

  • Pod를 나열하려면 다음 명령을 실행합니다.

    # oc get pods -n <storage_project_name>

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

    # oc get pods -n storage-project
    NAME                                                     READY     STATUS    RESTARTS   AGE
    storage-project-router-1-v89qc                           1/1       Running   0          1d
    glusterfs-dc-node1.example.com                           1/1       Running   0          1d
    glusterfs-dc-node2.example.com                           1/1       Running   1          1d
    glusterfs-dc-node3.example.com                           1/1       Running   0          1d
    heketi-1-k1u14                                           1/1       Running   0          23m

    다음은 위 예제의 gluster Pod입니다.

    glusterfs-dc-node1.example.com
    glusterfs-dc-node2.example.com
    glusterfs-dc-node3.example.com
    참고

    topology.json 파일은 지정된 신뢰할 수 있는 스토리지 풀(TSP)의 노드 세부 정보를 제공합니다. 위의 예에서 3개의 Red Hat Gluster Storage 노드는 모두 TSP입니다.

  • gluster Pod 쉘을 시작하려면 다음 명령을 실행합니다.

    # oc rsh <gluster_pod_name> -n <storage_project_name>

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

    # oc rsh glusterfs-dc-node1.example.com -n storage-project
    
    sh-4.2#
  • 피어 상태를 가져오려면 다음 명령을 실행합니다.

    # gluster peer status

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

    # gluster peer status
    
    Number of Peers: 2
    
    Hostname: node2.example.com
    Uuid: 9f3f84d2-ef8e-4d6e-aa2c-5e0370a99620
    State: Peer in Cluster (Connected)
    Other names:
    node1.example.com
    
    Hostname: node3.example.com
    Uuid: 38621acd-eb76-4bd8-8162-9c2374affbbd
    State: Peer in Cluster (Connected)
  • 신뢰할 수 있는 스토리지 풀의 gluster 볼륨을 나열하려면 다음 명령을 실행합니다.

    # gluster volume info

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

    Volume Name: heketidbstorage
    Type: Distributed-Replicate
    Volume ID: 2fa53b28-121d-4842-9d2f-dce1b0458fda
    Status: Started
    Number of Bricks: 2 x 3 = 6
    Transport-type: tcp
    Bricks:
    Brick1: 192.168.121.172:/var/lib/heketi/mounts/vg_1be433737b71419dc9b395e221255fb3/brick_c67fb97f74649d990c5743090e0c9176/brick
    Brick2: 192.168.121.233:/var/lib/heketi/mounts/vg_0013ee200cdefaeb6dfedd28e50fd261/brick_6ebf1ee62a8e9e7a0f88e4551d4b2386/brick
    Brick3: 192.168.121.168:/var/lib/heketi/mounts/vg_e4b32535c55c88f9190da7b7efd1fcab/brick_df5db97aa002d572a0fec6bcf2101aad/brick
    Brick4: 192.168.121.233:/var/lib/heketi/mounts/vg_0013ee200cdefaeb6dfedd28e50fd261/brick_acc82e56236df912e9a1948f594415a7/brick
    Brick5: 192.168.121.168:/var/lib/heketi/mounts/vg_e4b32535c55c88f9190da7b7efd1fcab/brick_65dceb1f749ec417533ddeae9535e8be/brick
    Brick6: 192.168.121.172:/var/lib/heketi/mounts/vg_7ad961dbd24e16d62cabe10fd8bf8909/brick_f258450fc6f025f99952a6edea203859/brick
    Options Reconfigured:
    performance.readdir-ahead: on
    
    Volume Name: vol_9e86c0493f6b1be648c9deee1dc226a6
    Type: Distributed-Replicate
    Volume ID: 940177c3-d866-4e5e-9aa0-fc9be94fc0f4
    Status: Started
    Number of Bricks: 2 x 3 = 6
    Transport-type: tcp
    Bricks:
    Brick1: 192.168.121.168:/var/lib/heketi/mounts/vg_3fa141bf2d09d30b899f2f260c494376/brick_9fb4a5206bdd8ac70170d00f304f99a5/brick
    Brick2: 192.168.121.172:/var/lib/heketi/mounts/vg_7ad961dbd24e16d62cabe10fd8bf8909/brick_dae2422d518915241f74fd90b426a379/brick
    Brick3: 192.168.121.233:/var/lib/heketi/mounts/vg_5c6428c439eb6686c5e4cee56532bacf/brick_b3768ba8e80863724c9ec42446ea4812/brick
    Brick4: 192.168.121.172:/var/lib/heketi/mounts/vg_7ad961dbd24e16d62cabe10fd8bf8909/brick_0a13958525c6343c4a7951acec199da0/brick
    Brick5: 192.168.121.168:/var/lib/heketi/mounts/vg_17fbc98d84df86756e7826326fb33aa4/brick_af42af87ad87ab4f01e8ca153abbbee9/brick
    Brick6: 192.168.121.233:/var/lib/heketi/mounts/vg_5c6428c439eb6686c5e4cee56532bacf/brick_ef41e04ca648efaf04178e64d25dbdcb/brick
    Options Reconfigured:
    performance.readdir-ahead: on
  • 볼륨 상태를 가져오려면 다음 명령을 실행합니다.

    # gluster volume status <volname>

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

    # gluster volume status vol_9e86c0493f6b1be648c9deee1dc226a6
    
    Status of volume: vol_9e86c0493f6b1be648c9deee1dc226a6
    Gluster process                             TCP Port  RDMA Port  Online  Pid
    ------------------------------------------------------------------------------
    Brick 192.168.121.168:/var/lib/heketi/mounts/v
    g_3fa141bf2d09d30b899f2f260c494376/brick_9f
    b4a5206bdd8ac70170d00f304f99a5/brick        49154     0          Y       3462
    Brick 192.168.121.172:/var/lib/heketi/mounts/v
    g_7ad961dbd24e16d62cabe10fd8bf8909/brick_da
    e2422d518915241f74fd90b426a379/brick        49154     0          Y       115939
    Brick 192.168.121.233:/var/lib/heketi/mounts/v
    g_5c6428c439eb6686c5e4cee56532bacf/brick_b3
    768ba8e80863724c9ec42446ea4812/brick        49154     0          Y       116134
    Brick 192.168.121.172:/var/lib/heketi/mounts/v
    g_7ad961dbd24e16d62cabe10fd8bf8909/brick_0a
    13958525c6343c4a7951acec199da0/brick        49155     0          Y       115958
    Brick 192.168.121.168:/var/lib/heketi/mounts/v
    g_17fbc98d84df86756e7826326fb33aa4/brick_af
    42af87ad87ab4f01e8ca153abbbee9/brick        49155     0          Y       3481
    Brick 192.168.121.233:/var/lib/heketi/mounts/v
    g_5c6428c439eb6686c5e4cee56532bacf/brick_ef
    41e04ca648efaf04178e64d25dbdcb/brick        49155     0          Y       116153
    NFS Server on localhost                     2049      0          Y       116173
    Self-heal Daemon on localhost               N/A       N/A        Y       116181
    NFS Server on node1.example.com                                        2049      0          Y       3501
    Self-heal Daemon on node1.example.com                                  N/A       N/A        Y       3509
    NFS Server on 192.168.121.172                  2049      0          Y       115978
    Self-heal Daemon on 192.168.121.172            N/A       N/A        Y       115986
    
    Task Status of Volume vol_9e86c0493f6b1be648c9deee1dc226a6
    ------------------------------------------------------------------------------
    There are no active volume tasks
  • 스냅샷 기능을 사용하려면 노드 중 하나에서 다음 명령을 사용하여 snapshot 모듈을 로드합니다.

    # modprobe dm_snapshot
    중요

    스냅샷 사용 제한 사항

    • 스냅샷을 생성한 후에는 사용자가 관리할 수 있는 스냅샷 기능만 통해 액세스할 수 있어야 합니다. 이 명령을 사용하여 이전 버전의 파일을 필요한 위치에 복사할 수 있습니다.
    • 볼륨을 스냅샷 상태로 되돌리는 것은 지원되지 않으며 데이터의 일관성이 손상될 수 있으므로 절대로 수행해야 합니다.
    • 스냅샷이 있는 볼륨에서 볼륨 변경 작업(예: 볼륨 확장)을 수행하지 않아야 합니다.
    • gluster 블록 기반 PV의 일관된 스냅샷을 생성할 수 없습니다.
  • gluster 볼륨의 스냅샷을 만들려면 다음 명령을 실행합니다.

    # gluster snapshot create <snapname> <volname>

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

    # gluster snapshot create snap1 vol_9e86c0493f6b1be648c9deee1dc226a6
    
    snapshot create: success: Snap snap1_GMT-2016.07.29-13.05.46 created successfully
  • 스냅샷을 나열하려면 다음 명령을 실행합니다.

    # gluster snapshot list

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

    # gluster snapshot list
    
    snap1_GMT-2016.07.29-13.05.46
    snap2_GMT-2016.07.29-13.06.13
    snap3_GMT-2016.07.29-13.06.18
    snap4_GMT-2016.07.29-13.06.22
    snap5_GMT-2016.07.29-13.06.26
  • 스냅샷을 삭제하려면 다음 명령을 실행합니다.

    # gluster snap delete <snapname>

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

    # gluster snap delete snap1_GMT-2016.07.29-13.05.46
    
    Deleting snap will erase all the information about the snap. Do you still want to continue? (y/n) y
    snapshot delete: snap1_GMT-2016.07.29-13.05.46: snap removed successfully

    스냅샷 관리에 대한 자세한 내용은 https://access.redhat.com/documentation/en-us/red_hat_gluster_storage/3.5/html-single/administration_guide/index#chap-Managing_Snapshots 을 참조하십시오.

  • geo-replication의 Red Hat Openshift Container Storage 볼륨을 Red Hat Openshift Container Storage 원격 사이트로 설정할 수 있습니다. Geo-replication은 마스터 슬레이브 모델을 사용합니다. 여기에서 Red Hat Openshift Container Storage 볼륨은 마스터 볼륨 역할을 합니다. Geo-replication을 설정하려면 gluster Pod에서 geo-replication 명령을 실행해야 합니다. gluster Pod 쉘을 시작하려면 다음 명령을 실행합니다.

     # oc rsh <gluster_pod_name> -n <storage_project_name>

    Geo-replication 설정에 대한 자세한 내용은 https://access.redhat.com/documentation/en-us/red_hat_gluster_storage/3.5/html/administration_guide/chap-managing_geo-replication 을 참조하십시오.

  • brick 멀티플렉싱은 하나의 프로세스에 여러 개의 브릭스를 포함할 수 있는 기능입니다. 이렇게 하면 리소스 소비가 줄어들어 동일한 메모리 사용량을 이전에 더 많이 사용할 수 있습니다.

    opm 멀티플렉싱은 기본적으로 Container-Native Storage 3.6에서 활성화됩니다. 해제하려면 다음 명령을 실행합니다.

    # gluster volume set all cluster.brick-multiplex off
  • glusterfs libadapter의 auto_unmount 옵션을 활성화하면 마운트 해제를 수행하는 별도의 모니터 프로세스를 실행하여 FUSE 서버 종료 시 파일 시스템을 마운트 해제할 수 있습니다.

    Openshift의 GlusterFS 플러그인은 gluster 마운트에 대한 auto_unmount 옵션을 활성화합니다.

2.1. 노드에서 유지 관리

2.1.1. 유지 관리 전에 수행해야 하는 단계

  • glusterfs 데몬 세트의 선택기인 glusterfs 또는 이와 동등한 레이블을 제거합니다. 포드가 종료될 때까지 기다립니다.

    • 다음 명령을 실행하여 노드 선택기 를 가져옵니다.

      # oc get ds

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

      # oc get ds
      NAME              DESIRED   CURRENT   READY     UP-TO-DATE   AVAILABLE
      glusterfs-storage   3         3         3         3            3
                         NODE SELECTOR             AGE
                         glusterfs=storage-host    12d
    • 다음 명령을 사용하여 glusterfs 레이블을 제거합니다.

      # oc label node <storge_node1> glusterfs-

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

      # oc label node <storge_node1> glusterfs-
      node/<storage_node1> labeled
    • glusterfs 포드가 종료될 때까지 기다립니다. 아래 명령을 사용하여 확인합니다.

      # oc get pods -l glusterfs

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

      # oc get pods -l glusterfs
      NAME                               READY     STATUS     RESTARTS   AGE
      glusterblock-storage-provisioner   1/1       Running    0          7m
      glusterfs-storage-4tc9c            1/1    Terminating   0          5m
      glusterfs-storage-htrfg            1/1       Running    0          1d
      glusterfs-storage-z75bc            1/1       Running    0          1d
      heketi-storage-1-shgrr             1/1       Running    0          1d
  • 다음 명령을 사용하여 노드를 예약 불가능하게 설정합니다.

    # oc adm manage-node --schedulable=false <storage_node1>

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

    # oc adm manage-node --schedulable=false <storage_node1>
    NAME            STATUS                     ROLES    AGE  VERSION
    storage_node1   Ready,SchedulingDisabled   compute  12d  v1.11.0+d4cacc0
  • 아래 명령을 사용하여 노드를 드레이닝합니다.

    # oc adm drain --ignore-daemonsets <storage_node1>
    참고

    필요한 경우 유지 관리를 수행하고 재부팅하십시오.

2.1.2. 유지 관리 후 필요한 단계

  • 다음 명령을 사용하여 노드를 예약 가능으로 설정합니다.

    # oc adm manage-node --schedulable=true <storage_node1>

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

    # oc adm manage-node --schedulable=true <storage_node1>
    NAME       STATUS    ROLES     AGE       VERSION
    node1      Ready     compute   12d       v1.11.0+d4cacc0
  • glusterfs 데몬 세트의 선택기인 glusterfs 또는 이와 동등한 레이블을 추가합니다. 포드가 준비될 때까지 기다립니다.

    • 다음 명령을 실행하여 노드 선택기 를 가져옵니다.

      # oc get ds

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

      # oc get ds
      NAME               DESIRED   CURRENT   READY     UP-TO-DATE   AVAILABLE
      glusterfs-storage   3         3         3         3            3
                        NODE SELECTOR            AGE
                        glusterfs=storage-host   12d
    • 위의 노드 선택기와 아래 명령을 사용하여 glusterfs 노드에 레이블을 지정합니다.

      # oc label node <storage_node1> glusterfs=storage-host

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

      # oc label node <storage_node1> glusterfs=storage-host
      node/<storage_node1> labeled
    • 포드가 Ready 상태가 될 때까지 기다립니다.

      # oc get pods

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

      # oc get pods
      NAME                                READY     STATUS    RESTARTS   AGE
      glusterblock-storage-provisioner    1/1       Running   0          3m
      glusterfs-storage-4tc9c             0/1       Running   0          50s
      glusterfs-storage-htrfg             1/1       Running   0          1d
      glusterfs-storage-z75bc             1/1       Running   0          1d
      heketi-storage-1-shgrr              1/1       Running   0          1d
    • 포드가 1/1 Ready 상태가 될 때까지 기다립니다.

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

      # oc get pods
      NAME                                 READY     STATUS    RESTARTS   AGE
      glusterblock-storage-provisioner     1/1       Running   0          3m
      glusterfs-storage-4tc9c              1/1       Running   0          58s
      glusterfs-storage-htrfg              1/1       Running   0          1d
      glusterfs-storage-z75bc              1/1       Running   0          1d
      heketi-storage-1-shgrr               1/1       Running   0          1d
  • 복구가 완료될 때까지 기다린 후 oc rsh를 사용하여 glusterfs 포드의 쉘을 가져오고, 아래 명령을 사용하여 복구 기능을 모니터링하고, 항목 수가 0(0)이 될 때까지 기다립니다.

    # for each_volume in gluster volume list; do gluster volume heal $each_volume info ; done

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

    # for each_volume in gluster volume list; do gluster volume heal $each_volume info ; done
    Brick 10.70.46.210:/var/lib/heketi/mounts/vg_64e90b4b94174f19802a8026f652f6d7/brick_564f7725cef192f0fd2ba1422ecbf590/brick
    Status: Connected
    Number of entries: 0
    
    Brick 10.70.46.243:/var/lib/heketi/mounts/vg_4fadbf84bbc67873543472655e9660ec/brick_9c9c8c64c48d24c91948bc810219c945/brick
    Status: Connected
    Number of entries: 0
    
    Brick 10.70.46.224:/var/lib/heketi/mounts/vg_9fbaf0c06495e66f5087a51ad64e54c3/brick_75e40df81383a03b1778399dc342e794/brick
    Status: Connected
    Number of entries: 0
    
    Brick 10.70.46.224:/var/lib/heketi/mounts/vg_9fbaf0c06495e66f5087a51ad64e54c3/brick_e0058f65155769142cec81798962b9a7/brick
    Status: Connected
    Number of entries: 0
    
    Brick 10.70.46.210:/var/lib/heketi/mounts/vg_64e90b4b94174f19802a8026f652f6d7/brick_3cf035275dc93e0437fdfaea509a3a44/brick
    Status: Connected
    Number of entries: 0
    
    Brick 10.70.46.243:/var/lib/heketi/mounts/vg_4fadbf84bbc67873543472655e9660ec/brick_2cfd11ce587e622fe800dfaec101e463/brick
    Status: Connected
    Number of entries: 0

II 부. 작업

3장. 영구 볼륨 생성

OpenShift Container Platform 클러스터는 GlusterFS를 사용하여 영구 스토리지로 프로비저닝할 수 있습니다.

PV(영구 볼륨) 및 PVC(영구 볼륨 클레임)는 단일 프로젝트에서 볼륨을 공유할 수 있습니다. PV 정의에 포함된 GlusterFS 관련 정보는 포드 정의에서 직접 정의될 수 있지만 이렇게 하면 볼륨이 별도의 클러스터 리소스로 생성되지 않으므로 볼륨이 충돌이 발생할 수 있습니다.

라벨 및 선택기로 PV 바인딩

레이블은 오브젝트 사양의 일부로 사용자 정의 태그(키-값 쌍)를 지원하는 OpenShift Container Platform 기능입니다. 주요 목적은 동일한 라벨을 정의하여 임의의 오브젝트 그룹화를 활성화하는 것입니다. 그런 다음 이러한 라벨은 지정된 라벨 값이 있는 모든 오브젝트와 일치하도록 선택기의 대상으로 지정할 수 있습니다. 이 기능은 PVC를 사용하여 PV에 바인딩할 수 있는 기능을 활용할 것입니다.

레이블을 사용하여 볼륨 간에 공유되는 공통 속성 또는 특성을 식별할 수 있습니다. 예를 들어, gluster 볼륨을 정의하여 storage-tier _with a value of _gold _assigned라는 사용자 지정 속성(key)을 지정할 수 있습니다. 이 PV와 일치하도록 _storage-tier=gold 가 있는 PV를 선택할 수 있습니다.

파일 기반 스토리지의 프로비저닝 볼륨에 대한 자세한 내용은 3.1절. “파일 스토리지” 에서 참조하십시오. 마찬가지로 블록 기반 스토리지의 볼륨 프로비저닝에 대한 자세한 내용은 3.2절. “블록 스토리지” 에서 제공됩니다.

3.1. 파일 스토리지

파일 스토리지(파일 수준 또는 파일 기반 스토리지라고도 함)는 계층 구조에 데이터를 저장합니다. 데이터는 파일 및 폴더에 저장되고 시스템을 저장하는 시스템과 동일한 형식으로 검색하는 시스템에 제공됩니다. 파일 기반 스토리지의 경우 볼륨을 정적으로 또는 동적으로 프로비저닝할 수 있습니다.

3.1.1. 볼륨의 정적 프로비저닝

OpenShift 및 Kubernetes에서 영구 볼륨 지원을 활성화하려면 엔드포인트 몇 개와 서비스를 생성해야 합니다.

참고

(기본값) Ansible 설치 프로그램을 사용하여 OpenShift Container Storage를 배포한 경우 다음 단계가 필요하지 않습니다.

샘플 glusterfs 끝점 파일(sample-gluster-endpoints.yaml) 및 샘플 glusterfs 서비스 파일(sample-gluster-service.yaml)은 /usr/share/heketi/templates/ *directory에서 사용할 수 있습니다.

/usr/share/heketi/templates/ 디렉터리는 이러한 배포에 대해 생성되지 않으므로 샘플 끝점 및 서비스 파일을 ansible 배포에 사용할 수 없습니다.

참고

샘플 glusterfs 엔드포인트 파일 / glusterfs 서비스 파일을 선택한 위치에 복사한 다음 복사된 파일을 편집합니다. 예를 들면 다음과 같습니다.

# cp /usr/share/heketi/templates/sample-gluster-endpoints.yaml /<_path_>/gluster-endpoints.yaml
  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
참고

마운트 지점에 권한 거부 오류가 발생하면 https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/configuring_clusters/#install-config-storage-examples-gluster-example 의 섹션 Gluster Volume Security를 참조하십시오.

3.1.2. 볼륨 동적 프로비저닝

동적 프로비저닝을 사용하면 볼륨을 사전에 생성하지 않고 실행 중인 애플리케이션 컨테이너에 Red Hat Gluster Storage 볼륨을 프로비저닝할 수 있습니다. 클레임 요청이 제공될 때 볼륨이 동적으로 생성되고 정확히 동일한 크기의 볼륨이 애플리케이션 컨테이너에 프로비저닝됩니다.

참고

아래에 설명된 단계는 (기본값) Ansible 설치 프로그램을 사용하여 OpenShift Container Storage를 배포하고 설치 중에 생성된 기본 스토리지 클래스(glusterfs-storage)를 사용하는 경우 필요하지 않습니다.

3.1.2.1. 볼륨 동적 프로비저닝 구성

볼륨의 동적 프로비저닝을 구성하려면 관리자는 클러스터에서 제공되는 스토리지의 "classes" 이름을 설명하는 StorageClass 오브젝트를 정의해야 합니다. 스토리지 클래스를 생성한 후에는 영구 볼륨 클레임 생성을 진행하기 전에 heketi 인증에 대한 시크릿을 생성해야 합니다.

3.1.2.1.1. Heketi 인증을 위한 보안 생성

Heketi 인증을 위한 시크릿을 생성하려면 다음 명령을 실행합니다.

참고

admin-key 값(볼륨 세부 정보를 얻기 위해 heketi에 액세스하기 위한 시크릿)이 Red Hat Openshift Container Storage를 배포하는 동안 설정되지 않은 경우 다음 단계를 생략할 수 있습니다.

  1. 다음 명령을 실행하여 암호에 인코딩된 값을 생성합니다.

    # echo -n "<key>" | base64

    여기서 "key"는 Red Hat Openshift Container Storage를 배포하는 동안 생성된 admin-key 의 값입니다.

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

    # echo -n "mypassword" | base64
    bXlwYXNzd29yZA==
  2. 시크릿 파일을 생성합니다. 샘플 보안 파일은 다음과 같습니다.

    # cat glusterfs-secret.yaml
    
    apiVersion: v1
    kind: Secret
    metadata:
      name: heketi-secret
      namespace: default
    data:
      # base64 encoded password. E.g.: echo -n "mypassword" | base64
      key: bXlwYXNzd29yZA==
    type: kubernetes.io/glusterfs
  3. 다음 명령을 실행하여 Openshift에 시크릿을 등록합니다.

    # oc create -f glusterfs-secret.yaml
    secret "heketi-secret" created
3.1.2.1.2. 스토리지 클래스 등록

영구 볼륨 프로비저닝을 위해 StorageClass 오브젝트를 구성할 때 관리자는 사용할 프로비저너 유형과 클래스에 속하는 PersistentVolume을 프로비저닝할 때 프로비저너에서 사용할 매개변수를 설명해야 합니다.

  1. 스토리지 클래스를 생성하려면 다음 명령을 실행합니다.

    # cat > glusterfs-storageclass.yaml
    
    
    apiVersion: storage.k8s.io/v1
    kind: StorageClass
    metadata:
      name: gluster-container
    provisioner: kubernetes.io/glusterfs
    reclaimPolicy: Retain
    parameters:
      resturl: "http://heketi-storage-project.cloudapps.mystorage.com"
      restuser: "admin"
      volumetype: "replicate:3"
      clusterid: "630372ccdc720a92c681fb928f27b53f,796e6db1981f369ea0340913eeea4c9a"
      secretNamespace: "default"
      secretName: "heketi-secret"
      volumeoptions: "client.ssl on, server.ssl on"
      volumenameprefix: "test-vol"
    allowVolumeExpansion: true

    다음과 같습니다.

    resturl
    필요에 따라 gluster 볼륨을 프로비저닝하는 Gluster REST 서비스/Heketi 서비스 URL입니다. 일반 형식은 IPaddress:Port여야 하며 GlusterFS 동적 프로비저너에 대한 필수 매개변수입니다. Heketi 서비스가 openshift/kubernetes 설정에서 라우팅 가능한 서비스로 표시되는 경우 fqdn은 확인 가능한 서비스 URL인 http://heketi-storage-project.cloudapps.mystorage.com 과 유사한 형식을 지정할 수 있습니다.
    restuser
    신뢰할 수 있는 스토리지 풀에서 볼륨을 생성하기 위해 액세스 권한이 있는 Gluster REST 서비스/Heketi 사용자
    volumetype

    사용 중인 볼륨 유형을 지정합니다.

    참고

    distributed-Three-way 복제는 지원되는 유일한 볼륨 유형입니다. 여기에는 표준 3방향 복제 볼륨과 중재 2+1이 모두 포함됩니다.

    clusterid

    볼륨을 프로비저닝할 때 Heketi에서 사용할 클러스터의 ID입니다. 쉼표로 구분된 클러스터 ID 목록일 수도 있습니다. 선택적 매개변수입니다.

    참고

    클러스터 ID를 가져오려면 다음 명령을 실행합니다.

    # heketi-cli cluster list
    secretNamespace + secretName

    Gluster REST 서비스와 통신할 때 사용되는 사용자 암호가 포함된 Secret 인스턴스의 식별입니다. 해당 매개변수는 선택 사항입니다. secretNamespace 및 secretName을 모두 생략하면 비어 있는 암호가 사용됩니다.

    참고

    영구 볼륨이 동적으로 프로비저닝되면 Gluster 플러그인은 gluster-dynamic-<claimname>이라는 이름에 엔드포인트와 헤드리스 서비스를 자동으로 생성합니다. 이 동적 끝점 및 서비스는 영구 볼륨 클레임이 삭제될 때 자동으로 삭제됩니다.

    volumeoptions

    선택적 매개변수입니다. 매개 변수를 "client.ssl on, server.ssl"으로 설정하여 암호화로 glusterfs 볼륨을 만들 수 있습니다. 암호화 활성화에 대한 자세한 내용은 8장. 암호화 활성화 을 참조하십시오.

    참고

    암호화가 활성화되지 않은 경우 스토리지 클래스에 이 매개변수를 추가하지 마십시오.

    volumenameprefix

    선택적 매개변수입니다. heketi에서 생성한 볼륨의 이름을 표시합니다. 자세한 내용은 다음을 참조하십시오. 3.1.2.1.5절. “(선택 사항) 영구 볼륨에 대한 사용자 정의 볼륨 이름 접두사 제공”

    참고

    이 매개변수의 값은 storageclass에 _ 를 포함할 수 없습니다.

    allowVolumeExpansion
    PV 클레임 값을 늘리려면 storageclass 파일의 allowVolumeExpansion 매개변수를 true 로 설정해야 합니다. 자세한 내용은 3.1.2.1.7절. “영구 볼륨 클레임 확장”의 내용을 참조하십시오.
  2. Openshift에 스토리지 클래스를 등록하려면 다음 명령을 실행합니다.

    # oc create -f glusterfs-storageclass.yaml
    storageclass "gluster-container" created
  3. 스토리지 클래스의 세부 정보를 가져오려면 다음 명령을 실행합니다.

    # oc describe storageclass gluster-container
    
    Name: gluster-container
    IsDefaultClass: No
    Annotations: <none>
    Provisioner: kubernetes.io/glusterfs
    Parameters: resturl=http://heketi-storage-project.cloudapps.mystorage.com,restuser=admin,secretName=heketi-secret,secretNamespace=default
    No events.
3.1.2.1.3. 영구 볼륨 클레임 생성

영구 볼륨 클레임을 생성하려면 다음 명령을 실행합니다.

  1. 영구 볼륨 클레임 파일을 생성합니다. 다음은 샘플 영구 볼륨 클레임이 제공됩니다.

    # cat glusterfs-pvc-claim1.yaml
    kind: PersistentVolumeClaim
    apiVersion: v1
    metadata:
      name: claim1
      annotations:
        volume.beta.kubernetes.io/storage-class: gluster-container
    spec:
      persistentVolumeReclaimPolicy: Retain
      accessModes:
        - ReadWriteOnce
      resources:
        requests:
          storage: 5Gi
    persistentVolumeReclaimPolicy

    선택적 매개변수입니다. 이 매개변수가 "tain"으로 설정되면 해당 영구 볼륨 클레임이 삭제된 후에도 기본 영구 볼륨이 유지됩니다.

    참고

    PVC가 삭제되면 "persistentVolumeReclaimPolicy:"Retain"으로 설정된 경우 기본 heketi 및 gluster 볼륨이 삭제되지 않습니다. 볼륨을 삭제하려면 heketi cli를 사용한 다음 PV를 삭제해야 합니다.

  2. 다음 명령을 실행하여 클레임을 등록합니다.

    # oc create -f glusterfs-pvc-claim1.yaml
    persistentvolumeclaim "claim1" created
  3. 클레임의 세부 정보를 가져오려면 다음 명령을 실행합니다.

    # oc describe pvc <_claim_name_>

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

    # oc describe pvc claim1
    
    Name: claim1
    Namespace: default
    StorageClass: gluster-container
    Status: Bound
    Volume: pvc-54b88668-9da6-11e6-965e-54ee7551fd0c
    Labels: <none>
    Capacity: 4Gi
    Access Modes: RWO
    No events.
3.1.2.1.4. 클레임 생성 확인

클레임이 생성되었는지 확인하려면 다음 명령을 실행합니다.

  1. 영구 볼륨 클레임 및 영구 볼륨의 세부 정보를 가져오려면 다음 명령을 실행합니다.

    # oc get pv,pvc
    
    NAME                                          CAPACITY   ACCESSMODES   RECLAIMPOLICY   STATUS     CLAIM                    REASON    AGE
    pv/pvc-962aa6d1-bddb-11e6-be23-5254009fc65b   4Gi        RWO           Delete          Bound      storage-project/claim1             3m
    
    NAME         STATUS    VOLUME                                     CAPACITY   ACCESSMODES   AGE
    pvc/claim1   Bound     pvc-962aa6d1-bddb-11e6-be23-5254009fc65b   4Gi        RWO           4m
  2. 끝점 및 서비스가 클레임 생성의 일부로 생성되는지 확인하려면 다음 명령을 실행합니다.

    # oc get endpoints,service
    
    NAME                          ENDPOINTS                                            AGE
    ep/storage-project-router     192.168.68.3:443,192.168.68.3:1936,192.168.68.3:80   28d
    ep/gluster-dynamic-claim1     192.168.68.2:1,192.168.68.3:1,192.168.68.4:1         5m
    ep/heketi                     10.130.0.21:8080                                     21d
    ep/heketi-storage-endpoints   192.168.68.2:1,192.168.68.3:1,192.168.68.4:1         25d
    
    NAME                           CLUSTER-IP       EXTERNAL-IP   PORT(S)                   AGE
    svc/storage-project-router     172.30.166.64    <none>        80/TCP,443/TCP,1936/TCP   28d
    svc/gluster-dynamic-claim1     172.30.52.17     <none>        1/TCP                     5m
    svc/heketi                     172.30.129.113   <none>        8080/TCP                  21d
    svc/heketi-storage-endpoints   172.30.133.212   <none>        1/TCP                     25d
3.1.2.1.5. (선택 사항) 영구 볼륨에 대한 사용자 정의 볼륨 이름 접두사 제공

생성된 영구 볼륨에 사용자 정의 볼륨 이름 접두사를 제공할 수 있습니다. 사용자 정의 볼륨 이름 접두사를 제공하여 다음을 기반으로 볼륨을 쉽게 검색/필터할 수 있습니다.

  • storageclass 파일에서 "volnameprefix"의 필드 값으로 제공된 모든 문자열입니다.
  • 영구 볼륨 클레임 이름입니다.
  • 프로젝트/네임스페이스 이름.

이름을 설정하려면 volumenameprefix 를 스토리지 클래스 파일에 추가해야 합니다. 자세한 내용은 을 참조하십시오. 3.1.2.1.2절. “스토리지 클래스 등록”

참고

이 매개변수의 값은 storageclass에 _ 를 포함할 수 없습니다.

사용자 정의 볼륨 이름 접두사가 설정되어 있는지 확인하려면 다음 명령을 실행합니다.

# oc describe pv <pv_name>

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

# oc describe pv pvc-f92e3065-25e8-11e8-8f17-005056a55501
Name:            pvc-f92e3065-25e8-11e8-8f17-005056a55501
Labels:          <none>
Annotations:     Description=Gluster-Internal: Dynamically provisioned PV
                 gluster.kubernetes.io/heketi-volume-id=027c76b24b1a3ce3f94d162f843529c8
                 gluster.org/type=file
                 kubernetes.io/createdby=heketi-dynamic-provisioner
                 pv.beta.kubernetes.io/gid=2000
                 pv.kubernetes.io/bound-by-controller=yes
                 pv.kubernetes.io/provisioned-by=kubernetes.io/glusterfs
                 volume.beta.kubernetes.io/mount-options=auto_unmount
StorageClass:    gluster-container-prefix
Status:          Bound
Claim:           glusterfs/claim1
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-claim1
    Path:           test-vol_glusterfs_claim1_f9352e4c-25e8-11e8-b460-005056a55501
    ReadOnly:       false
Events:             <none>

Path 값은 네임스페이스에 연결된 사용자 정의 볼륨 이름 접두사와 이 경우 "test-vol"입니다.

3.1.2.1.6. Pod에서 클레임 사용

Pod에서 클레임을 사용하려면 다음 단계를 실행합니다.

  1. 애플리케이션에서 클레임을 사용하려면 예를 들면 다음과 같습니다.

    # 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: claim1
    # 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 을 참조하십시오.

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

    # oc get pods -n storage-project
    
    NAME                                READY     STATUS         RESTARTS   AGE
    storage-project-router-1-at7tf      1/1       Running        0          13d
    busybox                             1/1       Running        0          8s
    glusterfs-dc-192.168.68.2-1-hu28h   1/1       Running        0          7d
    glusterfs-dc-192.168.68.3-1-ytnlg   1/1       Running        0          7d
    glusterfs-dc-192.168.68.4-1-juqcq   1/1       Running        0          13d
    heketi-1-9r47c                      1/1       Running        0          13d
  3. 영구 볼륨이 컨테이너 내부에 마운트되었는지 확인하려면 다음 명령을 실행합니다.

    # oc rsh busybox
    / $ df -h
    Filesystem                Size      Used Available Use% Mounted on
    /dev/mapper/docker-253:0-666733-38050a1d2cdb41dc00d60f25a7a295f6e89d4c529302fb2b93d8faa5a3205fb9
                             10.0G     33.8M      9.9G   0% /
    tmpfs                    23.5G         0     23.5G   0% /dev
    tmpfs                    23.5G         0     23.5G   0% /sys/fs/cgroup
    /dev/mapper/rhgs-root
                             17.5G      3.6G     13.8G  21% /run/secrets
    /dev/mapper/rhgs-root
                             17.5G      3.6G     13.8G  21% /dev/termination-log
    /dev/mapper/rhgs-root
                             17.5G      3.6G     13.8G  21% /etc/resolv.conf
    /dev/mapper/rhgs-root
                             17.5G      3.6G     13.8G  21% /etc/hostname
    /dev/mapper/rhgs-root
                             17.5G      3.6G     13.8G  21% /etc/hosts
    shm                      64.0M         0     64.0M   0% /dev/shm
    192.168.68.2:vol_5b05cf2e5404afe614f8afa698792bae
                              4.0G     32.6M      4.0G   1% /usr/share/busybox
    tmpfs                    23.5G     16.0K     23.5G   0% /var/run/secrets/kubernetes.io/serviceaccount
    tmpfs                    23.5G         0     23.5G   0% /proc/kcore
    tmpfs                    23.5G         0     23.5G   0% /proc/timer_stats
3.1.2.1.7. 영구 볼륨 클레임 확장

PV 클레임 값을 늘리려면 storageclass 파일의 allowVolumeExpansion 매개변수를 true 로 설정해야 합니다. 자세한 내용은 다음을 참조하십시오. 3.1.2.1.2절. “스토리지 클래스 등록”

참고

OpenShift Container Platform 3.11 웹 콘솔을 통해 PV의 크기를 조정할 수도 있습니다.

영구 볼륨 클레임 값을 확장하려면 다음 명령을 실행합니다.

  1. 기존 영구 볼륨 크기를 확인하려면 앱 Pod에서 다음 명령을 실행합니다.

    # oc rsh busybox
    # df -h

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

    # oc rsh busybox
    / # df -h
    Filesystem                Size      Used Available Use% Mounted on
    /dev/mapper/docker-253:0-100702042-0fa327369e7708b67f0c632d83721cd9a5b39fd3a7b3218f3ff3c83ef4320ce7
                             10.0G     34.2M      9.9G   0% /
    tmpfs                    15.6G         0     15.6G   0% /dev
    tmpfs                    15.6G         0     15.6G   0% /sys/fs/cgroup
    /dev/mapper/rhel_dhcp47--150-root
                             50.0G      7.4G     42.6G  15% /dev/termination-log
    /dev/mapper/rhel_dhcp47--150-root
                             50.0G      7.4G     42.6G  15% /run/secrets
    /dev/mapper/rhel_dhcp47--150-root
                             50.0G      7.4G     42.6G  15% /etc/resolv.conf
    /dev/mapper/rhel_dhcp47--150-root
                             50.0G      7.4G     42.6G  15% /etc/hostname
    /dev/mapper/rhel_dhcp47--150-root
                             50.0G      7.4G     42.6G  15% /etc/hosts
    shm                      64.0M         0     64.0M   0% /dev/shm
    10.70.46.177:test-vol_glusterfs_claim10_d3e15a8b-26b3-11e8-acdf-005056a55501
                              2.0G     32.6M      2.0G   2% /usr/share/busybox
    tmpfs                    15.6G     16.0K     15.6G   0% /var/run/secrets/kubernetes.io/serviceaccount
    tmpfs                    15.6G         0     15.6G   0% /proc/kcore
    tmpfs                    15.6G         0     15.6G   0% /proc/timer_list
    tmpfs                    15.6G         0     15.6G   0% /proc/timer_stats
    tmpfs                    15.6G         0     15.6G   0% /proc/sched_debug
    tmpfs                    15.6G         0     15.6G   0% /proc/scsi
    tmpfs                    15.6G         0     15.6G   0% /sys/firmware

    이 예에서 영구 볼륨 크기는 2Gi입니다.

  2. 영구 볼륨 클레임 값을 편집하려면 다음 명령을 실행하고 다음 storage 매개변수를 편집합니다.

    resources:
        requests:
          storage: <storage_value>
    # oc edit pvc <claim_name>

    예를 들어 스토리지 값을 20Gi로 확장하려면 다음을 수행합니다.

    # oc edit pvc claim3
    apiVersion: v1
    kind: PersistentVolumeClaim
    metadata:
      annotations:
        pv.kubernetes.io/bind-completed: "yes"
        pv.kubernetes.io/bound-by-controller: "yes"
        volume.beta.kubernetes.io/storage-class: gluster-container2
        volume.beta.kubernetes.io/storage-provisioner: kubernetes.io/glusterfs
      creationTimestamp: 2018-02-14T07:42:00Z
      name: claim3
      namespace: storage-project
      resourceVersion: "283924"
      selfLink: /api/v1/namespaces/storage-project/persistentvolumeclaims/claim3
      uid: 8a9bb0df-115a-11e8-8cb3-005056a5a340
    spec:
      accessModes:
      - ReadWriteOnce
      resources:
        requests:
          storage: 20Gi
      volumeName: pvc-8a9bb0df-115a-11e8-8cb3-005056a5a340
    status:
      accessModes:
      - ReadWriteOnce
      capacity:
        storage: 2Gi
    phase: Bound
  3. 확인하려면 앱 Pod에서 다음 명령을 실행합니다.

    # oc rsh busybox
    / # df -h

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

    # oc rsh busybox
    # df -h
    Filesystem                Size      Used Available Use% Mounted on
    /dev/mapper/docker-253:0-100702042-0fa327369e7708b67f0c632d83721cd9a5b39fd3a7b3218f3ff3c83ef4320ce7
                             10.0G     34.2M      9.9G   0% /
    tmpfs                    15.6G         0     15.6G   0% /dev
    tmpfs                    15.6G         0     15.6G   0% /sys/fs/cgroup
    /dev/mapper/rhel_dhcp47--150-root
                             50.0G      7.4G     42.6G  15% /dev/termination-log
    /dev/mapper/rhel_dhcp47--150-root
                             50.0G      7.4G     42.6G  15% /run/secrets
    /dev/mapper/rhel_dhcp47--150-root
                             50.0G      7.4G     42.6G  15% /etc/resolv.conf
    /dev/mapper/rhel_dhcp47--150-root
                             50.0G      7.4G     42.6G  15% /etc/hostname
    /dev/mapper/rhel_dhcp47--150-root
                             50.0G      7.4G     42.6G  15% /etc/hosts
    shm                      64.0M         0     64.0M   0% /dev/shm
    10.70.46.177:test-vol_glusterfs_claim10_d3e15a8b-26b3-11e8-acdf-005056a55501
                             20.0G     65.3M     19.9G   1% /usr/share/busybox
    tmpfs                    15.6G     16.0K     15.6G   0% /var/run/secrets/kubernetes.io/serviceaccount
    tmpfs                    15.6G         0     15.6G   0% /proc/kcore
    tmpfs                    15.6G         0     15.6G   0% /proc/timer_list
    tmpfs                    15.6G         0     15.6G   0% /proc/timer_stats
    tmpfs                    15.6G         0     15.6G   0% /proc/sched_debug
    tmpfs                    15.6G         0     15.6G   0% /proc/scsi
    tmpfs                    15.6G         0     15.6G   0% /sys/firmware

    크기가 2Gi (earlier)에서 20Gi로 변경되었습니다.

3.1.2.1.8. 영구 볼륨 클레임 삭제
참고

스토리지 클래스를 등록할 때 "persistentVolumeReclaimPolicy" 매개변수가 "Retain"으로 설정된 경우 PVC가 삭제되는 경우에도 기본 PV와 해당 볼륨이 남아 있습니다.

  1. 클레임을 삭제하려면 다음 명령을 실행합니다.

    # oc delete pvc <claim-name>

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

    # oc delete pvc claim1
    persistentvolumeclaim "claim1" deleted
  2. 클레임이 삭제되었는지 확인하려면 다음 명령을 실행합니다.

    # oc get pvc <claim-name>

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

    # oc get pvc claim1
    No resources found.

    사용자가 영구 볼륨 클레임을 삭제하는 것 외에도 동적 프로비저닝에서 생성한 영구 볼륨 클레임에 바인딩된 영구 볼륨 클레임을 삭제하면 Kubernetes는 영구 볼륨, 끝점, 서비스 및 실제 볼륨도 삭제합니다. 확인해야 하는 경우 다음 명령을 실행합니다.

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

      # oc get pv <pv-name>

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

      # oc get pv pvc-962aa6d1-bddb-11e6-be23-5254009fc65b
      No resources found.
    • 끝점이 삭제되었는지 확인하려면 다음 명령을 실행합니다.

      # oc get endpoints <endpointname>

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

      # oc get endpoints gluster-dynamic-claim1
      No resources found.
    • 서비스가 삭제되었는지 확인하려면 다음 명령을 실행합니다.

      # oc get service <servicename>

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

      # oc get service gluster-dynamic-claim1
      No resources found.

3.1.3. 볼륨 보안

볼륨에는 UID/GID가 0(root)으로 제공됩니다. 애플리케이션 Pod에서 볼륨에 쓰기 위해서는 UID/GID가 0(root)이어야 합니다. 볼륨 보안 기능을 통해 관리자는 이제 고유한 GID가 있는 볼륨을 생성할 수 있으며 애플리케이션 포드는 이 고유 GID를 사용하여 볼륨에 쓸 수 있습니다.

정적으로 프로비저닝된 볼륨에 대한 볼륨 보안

GID를 사용하여 정적으로 프로비저닝된 볼륨을 생성하려면 다음 명령을 실행합니다.

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

위의 명령에서 GID가 590인 100G 영구 볼륨이 생성되고 이 볼륨을 설명하는 영구 볼륨 사양의 출력이 pv001.json 파일에 추가됩니다.

이 GID를 사용하여 볼륨 액세스에 대한 자세한 내용은 https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html/configuring_clusters/persistent-storage-examples#install-config-storage-examples-gluster-example 을 참조하십시오.

동적으로 프로비저닝된 볼륨에 대한 볼륨 보안

gidMingidMax 라는 두 가지 새로운 매개변수가 동적 프로비저너와 함께 도입되었습니다. 관리자는 이러한 값을 사용하여 스토리지 클래스에서 볼륨의 GID 범위를 구성할 수 있습니다. GID 값을 설정하고 동적으로 프로비저닝된 볼륨에 볼륨 보안을 제공하려면 다음 명령을 실행합니다.

  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"
    참고

    gidMingidMax 값을 제공하지 않으면 동적 프로비저닝 볼륨에 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가 풀에서 해제됩니다.

3.1.4. heketi에서 장치 계층화

heketi는 볼륨을 배치할 때 특정 장치를 사용하는 간단한 태그 일치 접근 방식을 지원합니다. 사용자는 특정 장치 세트에서 키-값 쌍을 지정하고 볼륨 옵션 user.heketi.device-tag-match 키와 간단한 일치 규칙을 사용하여 새 볼륨을 생성해야 합니다.

절차

  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

3.2. 블록 스토리지

블록 스토리지를 사용하면 고성능 개별 스토리지 장치를 생성할 수 있습니다. glusterfs가 지원하는 기존 파일 스토리지 기능과 달리 각 스토리지 볼륨/블록 장치는 독립적인 디스크 드라이브로 취급될 수 있으므로 각 스토리지 볼륨/블록 장치는 개별 파일 시스템을 지원할 수 있습니다.

Gluster-block은 블록 장치를 위한 분산 관리 프레임워크입니다. Gluster 지원 블록 스토리지 생성 및 유지 관리를 가능한 한 간단하게 만드는 것을 목표로 합니다. gluster-block은 블록 장치를 프로비저닝하고 여러 노드에서 iSCSI LUN으로 내보낼 수 있으며 iSCSI 프로토콜을 사용하여 SCSI 블록/명령으로 데이터 전송을 사용합니다.

참고
  • OpenShift Container Storage 3.11에서 블록 볼륨 확장이 지원됩니다. 3.2.3절. “블록 볼륨 확장” 을 참조하십시오.
  • 블록 스토리지에서는 볼륨의 정적 프로비저닝이 지원되지 않습니다. 볼륨의 동적 프로비저닝은 지원되는 유일한 방법입니다.
  • 블록 스토리지에 대해 RHEL(Red Hat Enterprise Linux) 버전을 권장하는 것은 RHEL-7.5.4입니다. 커널 버전이 3.10.0-862.14.4.el7.x86_64와 일치하는지 확인하십시오. 실행을 확인하려면 다음을 수행합니다.

    # uname -r

    최신 커널 업데이트를 적용하려면 노드를 재부팅합니다.

3.2.1. 블록 스토리지를 위한 볼륨 동적 프로비저닝

동적 프로비저닝을 사용하면 볼륨을 사전에 생성하지 않고 실행 중인 애플리케이션 컨테이너에 Red Hat Gluster Storage 볼륨을 프로비저닝할 수 있습니다. 클레임 요청이 제공될 때 볼륨이 동적으로 생성되고 정확히 동일한 크기의 볼륨이 애플리케이션 컨테이너에 프로비저닝됩니다.

참고

아래에 설명된 단계는 (기본값) Ansible 설치 프로그램을 사용하여 OpenShift Container Storage를 배포하고 설치 중에 생성된 기본 스토리지 클래스(glusterfs-storage-block)를 사용하는 경우 필요하지 않습니다.

3.2.1.1. 볼륨 동적 프로비저닝 구성

볼륨의 동적 프로비저닝을 구성하려면 관리자는 클러스터에서 제공되는 스토리지의 "classes" 이름을 설명하는 StorageClass 오브젝트를 정의해야 합니다. 스토리지 클래스를 생성한 후에는 영구 볼륨 클레임 생성을 진행하기 전에 heketi 인증에 대한 시크릿을 생성해야 합니다.

3.2.1.1.1. 모든 Initiators에서 멀티 경로 구성

iSCSI 이니시에이터가 iSCSI 대상과 통신하고 다중 경로를 사용하여 HA를 달성하려면 앱 Pod가 호스팅되는 모든 OpenShift 노드(iSCSI 이니시에이터)에서 다음 단계를 실행합니다.

  1. 이니시에이터를 구성해야 하는 모든 노드에 이니시에이터 관련 패키지를 설치하려면 다음 명령을 실행합니다.

    # yum install iscsi-initiator-utils device-mapper-multipath
  2. 다중 경로를 활성화하려면 다음 명령을 실행합니다.

    # mpathconf --enable
  3. multipath.conf 파일에 다음 내용을 생성하고 추가합니다.

    참고

    업그레이드의 경우 모든 서버 노드가 업그레이드된 후에만 multipath.conf에 대한 변경 사항과 multipathd를 다시 로드해야 합니다.

    # cat >> /etc/multipath.conf <<EOF
    # LIO iSCSI
    devices {
            device {
                    vendor "LIO-ORG"
                    user_friendly_names "yes" # names like mpatha
                    path_grouping_policy "failover" # one path per group
                    hardware_handler "1 alua"
                    path_selector "round-robin 0"
                    failback immediate
                    path_checker "tur"
                    prio "alua"
                    no_path_retry 120
            }
    }
    EOF
  4. 다음 명령을 실행하여 다중 경로 데몬을 시작하고 다중 경로 구성을 로드합니다.

    # systemctl start multipathd
    # systemctl reload multipathd
3.2.1.1.2. Heketi 인증을 위한 보안 생성

Heketi 인증을 위한 시크릿을 생성하려면 다음 명령을 실행합니다.

참고

admin-key 값(볼륨 세부 정보를 얻기 위해 heketi에 액세스하기 위한 시크릿)이 Red Hat Openshift Container Storage를 배포하는 동안 설정되지 않은 경우 다음 단계를 생략할 수 있습니다.

  1. 다음 명령을 실행하여 암호에 인코딩된 값을 생성합니다.

    # echo -n "<key>" | base64

    여기서 key 는 CNS를 배포하는 동안 생성된 admin-key 의 값입니다.

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

    # echo -n "mypassword" | base64
    bXlwYXNzd29yZA==
  2. 시크릿 파일을 생성합니다. 샘플 보안 파일은 다음과 같습니다.

    # cat glusterfs-secret.yaml
    
    apiVersion: v1
    kind: Secret
    metadata:
      name: heketi-secret
      namespace: default
    data:
      # base64 encoded password. E.g.: echo -n "mypassword" | base64
      key: bXlwYXNzd29yZA==
    type: gluster.org/glusterblock
  3. 다음 명령을 실행하여 Openshift에 시크릿을 등록합니다.

    # oc create -f glusterfs-secret.yaml
    secret "heketi-secret" created
3.2.1.1.3. 스토리지 클래스 등록

영구 볼륨 프로비저닝을 위해 StorageClass 오브젝트를 구성할 때 관리자는 사용할 프로비저너 유형과 클래스에 속하는 PersistentVolume을 프로비저닝할 때 프로비저너에서 사용할 매개변수를 설명해야 합니다.

  1. 스토리지 클래스를 생성합니다. 샘플 스토리지 클래스 파일은 다음과 같습니다.

    # cat > glusterfs-block-storageclass.yaml
    
    apiVersion: storage.k8s.io/v1
    kind: StorageClass
    metadata:
     name: gluster-block
    provisioner: gluster.org/glusterblock-infra-storage
    reclaimPolicy: Retain
    parameters:
     resturl: "http://heketi-storage-project.cloudapps.mystorage.com"
     restuser: "admin"
     restsecretnamespace: "default"
     restsecretname: "heketi-secret"
     hacount: "3"
     clusterids: "630372ccdc720a92c681fb928f27b53f,796e6db1981f369ea0340913eeea4c9a"
     chapauthenabled: "true"
     volumenameprefix: "test-vol"

    다음과 같습니다.

    provisioner

    프로비저너 이름은 glusterblock 프로비저너 Pod가 배포된 프로비저너 이름과 일치해야 합니다. 프로비저너 이름을 가져오려면 다음 명령을 사용합니다.

    # oc describe pod <glusterblock_provisioner_pod_name> |grep PROVISIONER_NAME

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

    # oc describe pod glusterblock-registry-provisioner-dc-1-5j8l9 |grep PROVISIONER_NAME
         PROVISIONER_NAME:  gluster.org/glusterblock-infra-storage
    resturl
    필요에 따라 gluster 볼륨을 프로비저닝하는 Gluster REST 서비스/Heketi 서비스 URL입니다. 일반 형식은 IPaddress:Port여야 하며 GlusterFS 동적 프로비저너에 대한 필수 매개변수입니다. Heketi 서비스가 openshift/kubernetes 설정에서 라우팅 가능한 서비스로 표시되는 경우 fqdn은 확인 가능한 서비스 URL인 http://heketi-storage-project.cloudapps.mystorage.com 과 유사한 형식을 지정할 수 있습니다.
    restuser
    신뢰할 수 있는 스토리지 풀에서 볼륨을 생성하기 위해 액세스 권한이 있는 Gluster REST 서비스/Heketi 사용자
    restsecretnamespace + restsecretname
    Gluster REST 서비스에 연결할 때 사용할 사용자 암호가 포함된 Secret 인스턴스를 식별합니다. 해당 매개변수는 선택 사항입니다. restsecretnamespacerestsecretname 을 모두 생략하면 비어 있는 암호가 사용됩니다.
    hacount
    블록 대상 서버에 대한 경로 수입니다. hacount 는 iSCSI의 다중 경로 기능을 통해 고가용성을 제공합니다. 경로 오류가 있는 경우 I/O가 중단되지 않으며 사용 가능한 다른 경로를 통해 제공됩니다.
    clusterids

    볼륨을 프로비저닝할 때 Heketi에서 사용할 클러스터의 ID입니다. 쉼표로 구분된 클러스터 ID 목록일 수도 있습니다. 선택적 매개변수입니다.

    참고

    클러스터 ID를 가져오려면 다음 명령을 실행합니다.

    # heketi-cli cluster list
    chapauthenabled
    CHAP 인증이 활성화된 블록 볼륨을 프로비저닝하려면 이 값을 true로 설정해야 합니다. 선택적 매개변수입니다.
    volumenameprefix

    선택적 매개변수입니다. heketi에서 생성한 볼륨의 이름을 표시합니다. 자세한 내용은 다음을 참조하십시오. 3.2.1.1.6절. “(선택 사항) 영구 볼륨에 대한 사용자 정의 볼륨 이름 접두사 제공”

    참고

    이 매개변수의 값은 storageclass에 _ 를 포함할 수 없습니다.

  2. Openshift에 스토리지 클래스를 등록하려면 다음 명령을 실행합니다.

    # oc create -f glusterfs-block-storageclass.yaml
    storageclass "gluster-block" created
  3. 스토리지 클래스의 세부 정보를 가져오려면 다음 명령을 실행합니다.

    # oc describe storageclass gluster-block
    Name:            gluster-block
    IsDefaultClass:  No
    Annotations:     <none>
    Provisioner:     gluster.org/glusterblock-infra-storage
    Parameters:      chapauthenabled=true,hacount=3,opmode=heketi,restsecretname=heketi-secret,restsecretnamespace=default,resturl=http://heketi-storage-project.cloudapps.mystorage.com,restuser=admin
    Events:          <none>
3.2.1.1.4. 영구 볼륨 클레임 생성

영구 볼륨 클레임을 생성하려면 다음 명령을 실행합니다.

  1. 영구 볼륨 클레임 파일을 생성합니다. 다음은 샘플 영구 볼륨 클레임이 제공됩니다.

    # cat glusterfs-block-pvc-claim.yaml
    kind: PersistentVolumeClaim
    apiVersion: v1
    metadata:
      name: claim1
      annotations:
        volume.beta.kubernetes.io/storage-class: gluster-block
    spec:
      persistentVolumeReclaimPolicy: Retain
      accessModes:
        - ReadWriteOnce
      resources:
        requests:
          storage: 5Gi
    persistentVolumeReclaimPolicy

    선택적 매개변수입니다. 이 매개변수가 "tain"으로 설정되면 해당 영구 볼륨 클레임이 삭제된 후에도 기본 영구 볼륨이 유지됩니다.

    참고

    PVC가 삭제되면 "persistentVolumeReclaimPolicy:"Retain"으로 설정된 경우 기본 heketi 및 gluster 볼륨이 삭제되지 않습니다. 볼륨을 삭제하려면 heketi cli를 사용한 다음 PV를 삭제해야 합니다.

  2. 다음 명령을 실행하여 클레임을 등록합니다.

    # oc create -f glusterfs-block-pvc-claim.yaml
    persistentvolumeclaim "claim1" created
  3. 클레임의 세부 정보를 가져오려면 다음 명령을 실행합니다.

    # oc describe pvc <_claim_name_>

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

    # oc describe pvc claim1
    
    Name:        claim1
    Namespace:    block-test
    StorageClass:    gluster-block
    Status:        Bound
    Volume:        pvc-ee30ff43-7ddc-11e7-89da-5254002ec671
    Labels:        <none>
    Annotations:    control-plane.alpha.kubernetes.io/leader={"holderIdentity":"8d7fecb4-7dba-11e7-a347-0a580a830002","leaseDurationSeconds":15,"acquireTime":"2017-08-10T15:02:30Z","renewTime":"2017-08-10T15:02:58Z","lea...
           pv.kubernetes.io/bind-completed=yes
           pv.kubernetes.io/bound-by-controller=yes
           volume.beta.kubernetes.io/storage-class=gluster-block
           volume.beta.kubernetes.io/storage-provisioner=gluster.org/glusterblock
    Capacity:    5Gi
    Access Modes:    RWO
    Events:
     FirstSeen    LastSeen    Count    From                            SubObjectPath    Type        Reason            Message
     ---------    --------    -----    ----                            -------------    --------    ------            -------
     1m        1m        1    gluster.org/glusterblock 8d7fecb4-7dba-11e7-a347-0a580a830002            Normal        Provisioning        External provisioner is provisioning volume for claim "block-test/claim1"
     1m        1m        18    persistentvolume-controller                Normal        ExternalProvisioning    cannot find provisioner "gluster.org/glusterblock", expecting that a volume for the claim is provisioned either manually or via external software
    1m        1m        1    gluster.org/glusterblock 8d7fecb4-7dba-11e7-a347-0a580a830002            Normal        ProvisioningSucceeded    Successfully provisioned volume pvc-ee30ff43-7ddc-11e7-89da-5254002ec671
3.2.1.1.5. 클레임 생성 확인

클레임이 생성되었는지 확인하려면 다음 명령을 실행합니다.

  1. 영구 볼륨 클레임 및 영구 볼륨의 세부 정보를 가져오려면 다음 명령을 실행합니다.

    # oc get pv,pvc
    
    NAME                                          CAPACITY   ACCESSMODES   RECLAIMPOLICY   STATUS    CLAIM               STORAGECLASS    REASON    AGE
    pv/pvc-ee30ff43-7ddc-11e7-89da-5254002ec671   5Gi        RWO           Delete          Bound     block-test/claim1   gluster-block             3m
    
    NAME         STATUS    VOLUME                                     CAPACITY   ACCESSMODES   STORAGECLASS    AGE
    pvc/claim1   Bound     pvc-ee30ff43-7ddc-11e7-89da-5254002ec671   5Gi        RWO           gluster-block   4m
참고

블록 볼륨 및 블록 호스팅 볼륨을 식별하려면 https://access.redhat.com/solutions/3897581를 참조하십시오.

3.2.1.1.6. (선택 사항) 영구 볼륨에 대한 사용자 정의 볼륨 이름 접두사 제공

생성된 영구 볼륨에 사용자 정의 볼륨 이름 접두사를 제공할 수 있습니다. 사용자 정의 볼륨 이름 접두사를 제공하여 다음을 기반으로 볼륨을 쉽게 검색/필터할 수 있습니다.

  • storageclass 파일에서 "volnameprefix"의 필드 값으로 제공된 모든 문자열입니다.
  • 영구 볼륨 클레임 이름입니다.
  • 프로젝트/네임스페이스 이름.

이름을 설정하려면 volumenameprefix 를 스토리지 클래스 파일에 추가해야 합니다. 자세한 내용은 참조 3.2.1.1.3절. “스토리지 클래스 등록”

참고

이 매개변수의 값은 storageclass에 _ 를 포함할 수 없습니다.

사용자 정의 볼륨 이름 접두사가 설정되어 있는지 확인하려면 다음 명령을 실행합니다.

# oc describe pv <pv_name>

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

# oc describe pv pvc-4e97bd84-25f4-11e8-8f17-005056a55501
    Name:            pvc-4e97bd84-25f4-11e8-8f17-005056a55501
    Labels:          <none>
    Annotations:     AccessKey=glusterblk-67d422eb-7b78-4059-9c21-a58e0eabe049-secret
                     AccessKeyNs=glusterfs
                     Blockstring=url:http://172.31.251.137:8080,user:admin,secret:heketi-secret,secretnamespace:glusterfs
                     Description=Gluster-external: Dynamically provisioned PV
                     gluster.org/type=block
                     gluster.org/volume-id=cd37c089372040eba20904fb60b8c33e
                     glusterBlkProvIdentity=gluster.org/glusterblock
                     glusterBlockShare=test-vol_glusterfs_bclaim1_4eab5a22-25f4-11e8-954d-0a580a830003
                     kubernetes.io/createdby=heketi
                     pv.kubernetes.io/provisioned-by=gluster.org/glusterblock
                     v2.0.0=v2.0.0
    StorageClass:    gluster-block-prefix
    Status:          Bound
    Claim:           glusterfs/bclaim1
    Reclaim Policy:  Delete
    Access Modes:    RWO
    Capacity:        5Gi
    Message:
    Source:
        Type:               ISCSI (an ISCSI Disk resource that is attached to a kubelet's host machine and then exposed to the pod)
        TargetPortal:       10.70.46.177
        IQN:                iqn.2016-12.org.gluster-block:67d422eb-7b78-4059-9c21-a58e0eabe049
        Lun:                0
        ISCSIInterface      default
        FSType:             xfs
        ReadOnly:           false
        Portals:            [10.70.46.142 10.70.46.4]
        DiscoveryCHAPAuth:  false
        SessionCHAPAuth:    true
        SecretRef:          {glusterblk-67d422eb-7b78-4059-9c21-a58e0eabe049-secret }
        InitiatorName:      <none>
Events:                 <none>

glusterBlockShare 의 값은 네임스페이스에 연결된 사용자 정의 볼륨 이름 접두사와 클레임 이름(이 경우 "test-vol")을 갖습니다.

3.2.1.1.7. Pod에서 클레임 사용

Pod에서 클레임을 사용하려면 다음 단계를 실행합니다.

  1. 애플리케이션에서 클레임을 사용하려면 예를 들면 다음과 같습니다.

    # 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: claim1
    # 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 을 참조하십시오.

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

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

    # oc rsh busybox
    /  # df -h
    Filesystem                Size      Used Available Use% Mounted on
    /dev/mapper/docker-253:1-11438-39febd9d64f3a3594fc11da83d6cbaf5caf32e758eb9e2d7bdd798752130de7e
                            10.0G     33.9M      9.9G   0% /
    tmpfs                     3.8G         0      3.8G   0% /dev
    tmpfs                     3.8G         0      3.8G   0% /sys/fs/cgroup
    /dev/mapper/VolGroup00-LogVol00
                             7.7G      2.8G      4.5G  39% /dev/termination-log
    /dev/mapper/VolGroup00-LogVol00
                             7.7G      2.8G      4.5G  39% /run/secrets
    /dev/mapper/VolGroup00-LogVol00
                             7.7G      2.8G      4.5G  39% /etc/resolv.conf
    /dev/mapper/VolGroup00-LogVol00
                             7.7G      2.8G      4.5G  39% /etc/hostname
    /dev/mapper/VolGroup00-LogVol00
                             7.7G      2.8G      4.5G  39% /etc/hosts
    shm                      64.0M         0     64.0M   0% /dev/shm
    /dev/mpatha                  5.0G     32.2M      5.0G   1% /usr/share/busybox
    tmpfs                     3.8G     16.0K      3.8G   0% /var/run/secrets/kubernetes.io/serviceaccount
    tmpfs                     3.8G         0      3.8G   0% /proc/kcore
    tmpfs                     3.8G         0      3.8G   0% /proc/timer_list
    tmpfs                     3.8G         0      3.8G   0% /proc/timer_stats
    tmpfs                     3.8G         0      3.8G   0% /proc/sched_debug
3.2.1.1.8. 영구 볼륨 클레임 삭제
참고

스토리지 클래스를 등록할 때 "persistentVolumeReclaimPolicy" 매개변수가 "Retain"으로 설정된 경우 PVC가 삭제되는 경우에도 기본 PV와 해당 볼륨이 남아 있습니다.

  1. 클레임을 삭제하려면 다음 명령을 실행합니다.

    # oc delete pvc <claim-name>

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

    # oc delete pvc claim1
    persistentvolumeclaim "claim1" deleted
  2. 클레임이 삭제되었는지 확인하려면 다음 명령을 실행합니다.

    # oc get pvc <claim-name>

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

    # oc get pvc claim1
    No resources found.

    사용자가 영구 볼륨 클레임을 삭제하는 것 외에도 동적 프로비저닝에서 생성한 영구 볼륨 클레임에 바인딩된 영구 볼륨 클레임을 삭제하면 Kubernetes는 영구 볼륨, 끝점, 서비스 및 실제 볼륨도 삭제합니다. 확인해야 하는 경우 다음 명령을 실행합니다.

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

      # oc get pv <pv-name>

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

      # oc get pv pvc-962aa6d1-bddb-11e6-be23-5254009fc65b
      No resources found.

다음 단계: Red Hat Openshift Container Storage 3.11을 설치하고 블록 스토리지를 로깅 및 메트릭의 백엔드 스토리지로 사용하려는 경우 7장. Gluster Block Storage를 로깅 및 지표용 백엔드로 진행합니다.

3.2.2. 블록 스토리지에서 블록 교체

리소스가 부족하거나 문제가 있는 노드에서 블록을 교체하려면 새 노드로 교체할 수 있습니다.

중요

새 IP로 Gluster 블록 PV를 업데이트하려면 노드 교체 후 https://access.redhat.com/solutions/5042501를 참조하십시오.

다음 명령을 실행합니다.

  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. 다음 명령을 실행하여 블록 볼륨을 호스팅하는 서버 목록을 가져오고 나중에 사용할 수 있도록 GBIDmanagers 값을 저장합니다.

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

3.2.3. 블록 볼륨 확장

블록 영구 볼륨 클레임을 확장하여 애플리케이션 Pod의 스토리지 양을 늘릴 수 있습니다. 이를 수행하는 방법에는 두 가지가 있습니다. 오프라인 크기 조정 및 온라인 크기 조정.

3.2.3.1. 오프라인 크기 조정

  1. 블록 호스팅 볼륨의 크기가 충분한지 확인하고 블록 PVC를 확장합니다.

    1. PVC의 Heketi 블록 볼륨 ID를 가져오려면 기본 OCP 노드에서 다음 명령을 실행합니다.

      # oc get pv $(oc get pvc <PVC-NAME> --no-headers -o=custom-columns=:.spec.volumeName) -o=custom-columns=:.metadata.annotations."gluster\.org/volume-id"
    2. 블록 볼륨 ID를 가져오려면 다음 명령을 실행합니다.

      # heketi-cli blockvolume info <block-volume-id>
    3. 블록 호스팅 볼륨 정보를 가져오려면 다음 명령을 실행합니다.

      # heketi-cli volume info <block-hosting-volume-id>
      참고

      충분한 여유 공간이 있는지 확인하십시오.

  2. 애플리케이션 포드를 중단합니다.
  3. heketi-cli를 통해 블록 볼륨을 확장하려면 다음 명령을 실행합니다.

    # heketi-cli blockvolume expand <block-volume-id> --new-size=<net-new-size>

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

    # heketi-cli blockvolume expand d911d4bcfd4f11bf07b9688a4798b5dc --new-size=7
    Name: blk_glusterfs_claim2_fc40d362-aaf9-11ea-bb32-0a580a820004
    Size: 7
    UsableSize: 7
    Volume Id: d911d4bcfd4f11bf07b9688a4798b5dc
    Cluster Id: 8d1656d29fb8dc6780388cf797351a6d
    Hosts: [10.70.53.185 10.70.53.203 10.70.53.198]
    IQN: iqn.2016-12.org.gluster-block:8ce8eb4c-4951-4777-9b42-244b7ea525cd
    LUN: 0
    Hacount: 3
    Username: 8ce8eb4c-4951-4777-9b42-244b7ea525cd
    Password: b83a74be-df90-4fd7-b1a1-928fdcfed8c4
    Block Hosting Volume: 2224ac1da64c1737604456a1f511574e
    참고

    확장 출력에서 크기사용 가능한Size 가 일치하는지 확인합니다. 4~8 단계는 SizeUsableSize 가 일치하면 실행될 수 있습니다.

  4. PVC-NAME 을 PVC로 교체하고 블록 볼륨 크기를 새로 고치는 작업을 생성합니다.

    apiVersion: batch/v1
    kind: Job
    metadata:
      name: refresh-block-size
    spec:
      completions: 1
      template:
        spec:
          containers:
            - image: rhel7
              env:
                - name: HOST_ROOTFS
                  value: "/rootfs"
                - name: EXEC_ON_HOST
                  value: "nsenter --root=$(HOST_ROOTFS) nsenter -t 1 -m"
              command: ['sh', '-c', 'echo -e "# df -Th /mnt" && df -Th /mnt &&
                DEVICE=$(df --output=source /mnt | sed -e /^Filesystem/d) &&
                MOUNTPOINT=$($EXEC_ON_HOST lsblk $DEVICE -n -o MOUNTPOINT) &&
                $EXEC_ON_HOST xfs_growfs $MOUNTPOINT > /dev/null &&
                echo -e "\n# df -Th /mnt" && df -Th /mnt']
              name: rhel7
              volumeMounts:
                - mountPath: /mnt
                  name: block-pvc
                - mountPath: /dev
                  name: host-dev
                - mountPath: /rootfs
                  name: host-rootfs
              securityContext:
                privileged: true
          volumes:
            - name: block-pvc
              persistentVolumeClaim:
                claimName: <PVC-NAME>
            - name: host-dev
              hostPath:
                path: /dev
            - name: host-rootfs
              hostPath:
                path: /
          restartPolicy: Never
  5. Pod 로그에서 새 크기를 확인하려면 다음 명령을 실행합니다.

    # oc logs refresh-block-size-xxxxx
    참고

    df -Th 출력이 xfs_growfs 다음에 새 크기를 반영하는지 확인합니다.

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

    # oc logs refresh-block-size-jcbzh
    # df -Th /mnt
    Filesystem         Type  Size  Used Avail Use% Mounted on
    /dev/mapper/mpatha xfs   5.0G   33M  5.0G   1% /mnt
    # df -Th /mnt
    Filesystem         Type  Size  Used Avail Use% Mounted on
    /dev/mapper/mpatha xfs   7.0G   34M  6.0G   1% /mnt
  6. 작업 성공 여부를 확인하려면 다음 명령을 실행합니다.

    # oc get jobs
    NAME                 DESIRED   SUCCESSFUL   AGE
    refresh-block-size   1         1            36m
  7. 작업이 성공하면 다음 명령을 실행합니다.

    # oc delete job refresh-block-size
    job.batch "refresh-block-size" deleted
  8. 애플리케이션 Pod를 가져온 후 새 크기를 사용할 수 있습니다.

3.2.3.2. 온라인 크기 조정

  1. 블록 호스팅 볼륨의 크기가 충분한지 확인하고 블록 PVC를 확장합니다.

    1. PVC의 Heketi 블록 볼륨 ID를 가져오려면 기본 OCP 노드에서 다음 명령을 실행합니다.

      # oc get pv $(oc get pvc <PVC-NAME> --no-headers -o=custom-columns=:.spec.volumeName) -o=custom-columns=:.metadata.annotations."gluster\.org/volume-id"
    2. 블록 볼륨 ID를 가져오려면 다음 명령을 실행합니다.

      # heketi-cli blockvolume info <block-volume-id>
    3. 블록 호스팅 볼륨 정보를 가져오려면 다음 명령을 실행합니다.

      # heketi-cli volume info <block-hosting-volume-id>
      참고

      충분한 여유 공간이 있는지 확인하십시오.

  2. heketi-cli를 통해 블록 볼륨을 확장하려면 다음 명령을 실행합니다.

    # heketi-cli blockvolume expand <BLOCK-VOLUME-ID> --new-size=<net-new-size>

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

    # heketi-cli blockvolume expand d911d4bcfd4f11bf07b9688a4798b5dc --new-size=7
    Name: blk_glusterfs_claim2_fc40d362-aaf9-11ea-bb32-0a580a820004
    Size: 7
    UsableSize: 7
    Volume Id: d911d4bcfd4f11bf07b9688a4798b5dc
    Cluster Id: 8d1656d29fb8dc6780388cf797351a6d
    Hosts: [10.70.53.185 10.70.53.203 10.70.53.198]
    IQN: iqn.2016-12.org.gluster-block:8ce8eb4c-4951-4777-9b42-244b7ea525cd
    LUN: 0
    Hacount: 3
    Username: 8ce8eb4c-4951-4777-9b42-244b7ea525cd
    Password: b83a74be-df90-4fd7-b1a1-928fdcfed8c4
    Block Hosting Volume: 2224ac1da64c1737604456a1f511574e
    참고

    확장 출력에서 크기사용 가능한Size 가 일치하는지 확인합니다. 3~9 단계는 SizeUsableSize 가 일치할 때 실행될 수 있습니다.

  3. PV에 매핑된 iSCSI 대상 IQN 이름을 가져오려면 다음 명령을 실행하고 추가 참조를 위해 이 이름을 기록해 둡니다.

    # oc get pv <PV-NAME> -o=custom-columns=:.spec.iscsi.iqn

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

    # oc get pv pvc-fc3e9160-aaf9-11ea-a29f-005056b781de -o=custom-columns=:.spec.iscsi.iqn
    iqn.2016-12.org.gluster-block:8ce8eb4c-4951-4777-9b42-244b7ea525cd
  4. 애플리케이션 포드의 호스트 노드에 로그인합니다.

    1. 애플리케이션 Pod의 노드 이름을 가져오려면 다음 명령을 실행합니다.

      # oc get pods <POD-NAME> -o=custom-columns=:.spec.nodeName

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

      # oc get pods cirros2-1-8x6w5 -o=custom-columns=:.spec.nodeName
      dhcp53-203.lab.eng.blr.redhat.com
    2. 애플리케이션 Pod의 호스트 노드에 로그인하려면 다음 명령을 실행합니다.

      # ssh <NODE-NAME>

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

      # ssh dhcp53-203.lab.eng.blr.redhat.com
  5. 추가 참조를 위해 다중 경로 매퍼 장치 이름(예: mpatha), 개별 경로의 현재 크기(예: sdd,sdesdf) 및 매퍼 장치를 복사합니다.

    # lsblk | grep -B1 <pv-name>

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

    # lsblk | grep -B1 pvc-fc3e9160-aaf9-11ea-a29f-005056b781de
    sdd                                                                                 8:48   0    6G  0 disk
    └─mpatha                                                                          253:18   0    6G  0 mpath /var/lib/origin/openshift.local.volumes/pods/44b76db5-afa2-11ea-a29f-005056b781de/volumes/kubernetes.io~iscsi/pvc-fc3e9160-aaf9-11ea-a29f-005056b781de
    sde                                                                                 8:64   0    6G  0 disk
    └─mpatha                                                                          253:18   0    6G  0 mpath /var/lib/origin/openshift.local.volumes/pods/44b76db5-afa2-11ea-a29f-005056b781de/volumes/kubernetes.io~iscsi/pvc-fc3e9160-aaf9-11ea-a29f-005056b781de
    sdf                                                                                 8:80   0    6G  0 disk
    └─mpatha                                                                          253:18   0    6G  0 mpath /var/lib/origin/openshift.local.volumes/pods/44b76db5-afa2-11ea-a29f-005056b781de/volumes/kubernetes.io~iscsi/pvc-fc3e9160-aaf9-11ea-a29f-005056b781de
    
        # df -Th| grep <PV-NAME>
     For example:
    # df -Th | grep pvc-fc3e9160-aaf9-11ea-a29f-005056b781de
    /dev/mapper/mpatha                xfs       6.0G   44M  6.0G   1% /var/lib/origin/openshift.local.volumes/pods/44b76db5-afa2-11ea-a29f-005056b781de/volumes/kubernetes.io~iscsi/pvc-fc3e9160-aaf9-11ea-a29f-005056b781de
  6. 3단계에서 IQN 이름을 사용하여 애플리케이션 포드의 호스트 노드(iSCSI 이니시에이터)의 장치를 다시 스캔하여 다음 명령을 실행할 수 있습니다.

    # iscsiadm -m node -R -T <iqn-name>

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

    # iscsiadm -m node -R -T iqn.2016-12.org.gluster-block:a951f673-1a17-47b8-ac02-197baa32b9b1
    Rescanning session [sid: 1, target:iqn.2016-12.org.gluster-block:a951f673-1a17-47b8-ac02-197baa32b9b1, portal: 192.168.124.80,3260]
    Rescanning session [sid: 2, target:iqn.2016-12.org.gluster-block:a951f673-1a17-47b8-ac02-197baa32b9b1, portal: 192.168.124.73,3260]
    Rescanning session [sid: 3, target:iqn.2016-12.org.gluster-block:a951f673-1a17-47b8-ac02-197baa32b9b1, portal: 192.168.124.63,3260]
    참고

    이제 개별 경로(sdd, sde & sdf)에 반영되는 새 크기가 표시됩니다.

    # lsblk | grep -B1 <pv-name>

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

    # lsblk | grep -B1 pvc-fc3e9160-aaf9-11ea-a29f-005056b781de
    sdd            8:48   0    7G  0 disk
    └─mpatha       253:18 0    6G  0 mpath /var/lib/origin/openshift.local.volumes/pods/44b76db5-afa2-11ea-a29f-005056b781de/volumes/kubernetes.io~iscsi/pvc-fc3e9160-aaf9-11ea-a29f-005056b781de
    sde            8:64   0    7G  0 disk
    └─mpatha       253:18 0    6G  0 mpath /var/lib/origin/openshift.local.volumes/pods/44b76db5-afa2-11ea-a29f-005056b781de/volumes/kubernetes.io~iscsi/pvc-fc3e9160-aaf9-11ea-a29f-005056b781de
    sdf            8:80   0    7G  0 disk
    └─mpatha       253:18   0    6G  0 mpath /var/lib/origin/openshift.local.volumes/pods/44b76db5-afa2-11ea-a29f-005056b781de/volumes/kubernetes.io~iscsi/pvc-fc3e9160-aaf9-11ea-a29f-005056b781de
  7. 다중 경로 장치 크기를 새로 고치려면 다음 명령을 실행합니다.

    1. lsblk 출력에서 6 단계에서 다중 경로 매퍼 장치 이름을 가져옵니다.
    2. 다중 경로 매퍼 장치를 새로 고치려면 다음 명령을 실행합니다.

      # multipathd -k'resize map <multipath-mapper-name>'

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

      # multipathd -k'resize map mpatha'
      Ok
      참고

      이제 매퍼 장치 mpatha 를 사용하여 반영하는 새 크기가 표시됩니다. 추가 참조를 위해 다음 명령 출력에서 마운트 지점 경로를 복사합니다.

      # lsblk | grep -B1 <PV-NAME>

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

      # lsblk | grep -B1 pvc-fc3e9160-aaf9-11ea-a29f-005056b781de
      sdd                                                                                 8:48   0    7G  0 disk
      └─mpatha                                                                          253:18   0    7G  0 mpath /var/lib/origin/openshift.local.volumes/pods/44b76db5-afa2-11ea-a29f-005056b781de/volumes/kubernetes.io~iscsi/pvc-fc3e9160-aaf9-11ea-a29f-005056b781de
      sde                                                                                 8:64   0    7G  0 disk
      └─mpatha                                                                          253:18   0    7G  0 mpath /var/lib/origin/openshift.local.volumes/pods/44b76db5-afa2-11ea-a29f-005056b781de/volumes/kubernetes.io~iscsi/pvc-fc3e9160-aaf9-11ea-a29f-005056b781de
      sdf                                                                                 8:80   0    7G  0 disk
      └─mpatha                                                                          253:18   0    7G  0 mpath /var/lib/origin/openshift.local.volumes/pods/44b76db5-afa2-11ea-a29f-005056b781de/volumes/kubernetes.io~iscsi/pvc-fc3e9160-aaf9-11ea-a29f-005056b781de
      # df -Th | grep <pv-name>

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

          # df -Th | grep pvc-fc3e9160-aaf9-11ea-a29f-005056b781de
      /dev/mapper/mpatha                xfs       6.0G   44M  6.0G   1% /var/lib/origin/openshift.local.volumes/pods/44b76db5-afa2-11ea-a29f-005056b781de/volumes/kubernetes.io~iscsi/pvc-fc3e9160-aaf9-11ea-a29f-005056b781de
  8. 파일 시스템 레이아웃을 확장하려면 다음 명령을 실행합니다.

    # xfs_growfs <mount-point>

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

    # xfs_growfs /var/lib/origin/openshift.local.volumes/pods/44b76db5-afa2-11ea-a29f-005056b781de/volumes/kubernetes.io~iscsi/pvc-fc3e9160-aaf9-11ea-a29f-005056b781de
    meta-data=/dev/mapper/mpatha     isize=512    agcount=24, agsize=65536 blks
             =                       sectsz=512   attr=2, projid32bit=1
             =                       crc=1        finobt=0 spinodes=0
    data     =                       bsize=4096   blocks=1572864, imaxpct=25
             =                       sunit=0      swidth=0 blks
    naming   =version 2              bsize=4096   ascii-ci=0 ftype=1
    log      =internal               bsize=4096   blocks=2560, version=2
             =                       sectsz=512   sunit=0 blks, lazy-count=1
    realtime =none                   extsz=4096   blocks=0, rtextents=0
    data blocks changed from 1572864 to 1835008
    # df -Th | grep <pv-name>

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

    # df -Th | grep pvc-fc3e9160-aaf9-11ea-a29f-005056b781de
    /dev/mapper/mpatha                xfs       7.0G   44M  7.0G   1% /var/lib/origin/openshift.local.volumes/pods/44b76db5-afa2-11ea-a29f-005056b781de/volumes/kubernetes.io~iscsi/pvc-fc3e9160-aaf9-11ea-a29f-005056b781de
  9. 이제 애플리케이션 Pod를 재시작하지 않고 새 크기를 사용할 수 있습니다.

4장. gluster 블록 클라이언트 노드 종료

gluster-block 클라이언트 노드를 종료하려면 다음 절차를 따르십시오.

  1. 포드를 비웁니다. 자세한 내용은 https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/cluster_administration/#evacuating-pods-on-nodes을 참조하십시오.
  2. 시스템에 gluster 블록 마운트가 없는지 확인합니다.
  3. 노드를 재부팅합니다. 자세한 내용은 https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/cluster_administration/#rebooting-nodes을 참조하십시오.

5장. S3 Red Hat Openshift Container Storage 환경에서 호환 오브젝트 저장소

중요

컨테이너 기반 스토리지에서 S3 호환 오브젝트 저장소에 대한 지원은 기술 프리뷰로 제공됩니다. 기술 프리뷰 기능은 Red Hat SLA(서비스 수준 계약)에서 완전히 지원되지 않으며 기능적으로 완전하지 않을 수 있으며 프로덕션용이 아닙니다.

기술 프리뷰 기능을 통해 고객은 향후 제품 혁신에 조기 액세스할 수 있어 고객이 개발 과정에서 기능을 테스트하고 피드백을 제공할 수 있습니다.

Red Hat은 일반적으로 기술 프리뷰 기능을 지속적으로 반복할 것을 고려하기 때문에 고객이 이러한 기능을 사용할 때 발생하는 보고된 문제를 해결하기 위해 상업적으로 합리적인 노력을 다할 것입니다.

오브젝트 저장소는 사용자가 오브젝트와 파일로 동일한 데이터에 액세스할 수 있는 시스템을 제공하므로 관리를 단순화하고 스토리지 비용을 제어할 수 있습니다. S3 API는 오브젝트 스토리지 서비스에 대한 HTTP 기반 액세스를 위한 사실상 표준입니다.

참고

S3 호환 오브젝트 저장소는 Red Hat Openshift Container Storage 3.11.4 및 이전 릴리스에서만 사용할 수 있습니다.

5.1. Red Hat Openshift Container Storage용 S3호환 오브젝트 저장소 설정

참고

S3 호환 가능 오브젝트 저장소를 설정하기 전에 cns-deploy 패키지가 설치되었는지 확인합니다. cns-deploy 패키지를 설치하는 방법에 대한 자세한 내용은 https://access.redhat.com/documentation/en-us/red_hat_openshift_container_storage/3.11/html-single/deployment_guide/#part-Appendix를 참조하십시오.

/usr/share/heketi/templates/ 디렉토리에서 다음 단계를 실행하여 Red Hat Openshift Container Storage에 대해 S3 호환 오브젝트 저장소를 설정합니다.

  1. (선택 사항): heketi에 대한 시크릿을 생성하려면 다음 명령을 실행합니다.

    # oc create secret generic heketi-${NAMESPACE}-admin-secret
    --from-literal=key=${ADMIN_KEY} --type=kubernetes.io/glusterfs

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

    # oc create secret generic heketi-storage-project-admin-secret
    --from-literal=key=abcd  --type=kubernetes.io/glusterfs
    1. 다음 명령을 실행하여 시크릿에 레이블을 지정합니다.

      # oc label --overwrite secret heketi-${NAMESPACE}-admin-secret
      glusterfs=s3-heketi-${NAMESPACE}-admin-secret
      gluster-s3=heketi-${NAMESPACE}-admin-secret

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

      # oc label --overwrite secret heketi-storage-project-admin-secret
      glusterfs=s3-heketi-storage-project-admin-secret
      gluster-s3=heketi-storage-project-admin-secret
  2. GlusterFS StorageClass 파일을 만듭니다. 현재 설정에서 HEKETI_URL NAMESPACE를 사용하고 STORAGE_CLASS 이름을 설정합니다.

    # sed -e 's/${HEKETI_URL}/<HEKETI_URL>/g'  -e 's/${STORAGE_CLASS}/<STORAGE_CLASSNAME>/g' -e  's/${NAMESPACE}/<NAMESPACE_NAME>/g'   /usr/share/heketi/templates/gluster-s3-storageclass.yaml | oc create -f -

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

    # sed  -e 's/${HEKETI_URL}/heketi-storage-project.cloudapps.mystorage.com/g'  -e 's/${STORAGE_CLASS}/gluster-s3-store/g' -e 's/${NAMESPACE}/storage-project/g' /usr/share/heketi/templates/gluster-s3-storageclass.yaml | oc create -f -storageclass "gluster-s3-store" created
    참고
    • 다음 명령을 실행하여 HEKETI_URL을 가져올 수 있습니다.

      # oc get routes --all-namespaces | grep heketi

      명령의 샘플 출력은 다음과 같습니다.

      glusterfs   heketi-storage
      heketi-storage-glusterfs.router.default.svc.cluster.local
      heketi-storage   <all>          None

      출력에 여러 줄이 있는 경우 가장 적절한 행을 선택할 수 있습니다.

    • 다음 명령을 실행하여 NAMESPACE를 가져올 수 있습니다.

      oc get project

      명령의 샘플 출력은 다음과 같습니다.

      # oc project
      Using project "glusterfs" on server "master.example.com:8443"

      여기서 glusterfs는 NAMESPACE입니다.

  3. 스토리지 클래스를 사용하여 영구 볼륨 클레임을 생성합니다.

    # sed -e 's/${VOLUME_CAPACITY}/<NEW SIZE in Gi>/g'  -e  's/${STORAGE_CLASS}/<STORAGE_CLASSNAME>/g'  /usr/share/heketi/templates/gluster-s3-pvcs.yaml | oc create -f -

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

    # sed -e 's/${VOLUME_CAPACITY}/2Gi/g'  -e  's/${STORAGE_CLASS}/gluster-s3-store/g'  /usr/share/heketi/templates/gluster-s3-pvcs.yaml | oc create -f -
    persistentvolumeclaim "gluster-s3-claim" created
    persistentvolumeclaim "gluster-s3-meta-claim" created

    이전 단계에서 만든 STORAGE_CLASS 를 사용합니다. 환경 요구 사항에 따라 VOLUME_CAPACITY 를 수정합니다. PVC가 바인딩될 때까지 기다립니다. 다음 명령을 사용하여 동일한지 확인합니다.

    # oc get pvc
    NAME                    STATUS    VOLUME                                     CAPACITY   ACCESSMODES   AGE
    gluster-s3-claim        Bound     pvc-0b7f75ef-9920-11e7-9309-00151e000016   2Gi        RWX           2m
    gluster-s3-meta-claim   Bound     pvc-0b87a698-9920-11e7-9309-00151e000016   1Gi        RWX           2m
  4. 템플릿을 사용하여 glusters3 오브젝트 스토리지 서비스를 시작합니다. S3_ACCOUNT 이름, S3_USER 이름, S3_PASSWORD 를 설정합니다. PVCMETA_PVC 은 이전 단계에서 가져옵니다.

    # oc new-app  /usr/share/heketi/templates/gluster-s3-template.yaml \
    --param=S3_ACCOUNT=testvolume  --param=S3_USER=adminuser \
    --param=S3_PASSWORD=itsmine --param=PVC=gluster-s3-claim \
    --param=META_PVC=gluster-s3-meta-claim
    --> Deploying template "storage-project/gluster-s3" for "/usr/share/heketi/templates/gluster-s3-template.yaml" to project storage-project
    
         gluster-s3
         ---------
         Gluster s3 service template
    
    
         * With parameters:
            * S3 Account Name=testvolume
            * S3 User=adminuser
            * S3 User Password=itsmine
            * Primary GlusterFS-backed PVC=gluster-s3-claim
            * Metadata GlusterFS-backed PVC=gluster-s3-meta-claim
    
    --> Creating resources ...
        service "gluster-s3-service" created
        route "gluster-s3-route" created
        deploymentconfig "gluster-s3-dc" created
    --> Success
    Run 'oc status' to view your app.
  5. 다음 명령을 실행하여 S3 Pod가 실행 중인지 확인합니다.

    # oc get pods -o wide
    NAME                             READY     STATUS    RESTARTS   AGE       IP             NODE
    gluster-s3-azkys                 1/1       Running   0          4m        10.130.0.29    node3
    ..

5.2. 오브젝트 작업

이 섹션에서는 수행할 수 있는 개체 작업의 일부를 나열합니다.

  • S3 OS를 제공하는 경로의 URL을 가져옵니다.

    # s3_storage_url=$(oc get routes   | grep "gluster.*s3"  | awk '{print $2}')
    참고

    https://aws.amazon.com/code/128 에서 s3curl 툴을 다운로드해야 합니다. 이 툴은 오브젝트 작업을 확인하는 데 사용됩니다.

    • s3curl.pl requires Digest::HMAC_SHA1 and Digest::MD5. 이를 위해 perl-Digest-HMAC 패키지를 설치합니다. 다음 명령을 실행하여 perl-Digest-HMAC 패키지를 설치할 수 있습니다.

       # yum install perl-Digest-HMAC
    • 검색된 glusters3object url을 사용하여 s3curl.pl perl 스크립트를 업데이트합니다.

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

      my @endpoints = ( 'glusters3object-storage-project.cloudapps.mystorage.com');
  • 버킷의 PUT 작업을 수행하려면 다음을 수행합니다.

    s3curl.pl --debug --id "testvolume:adminuser" --key "itsmine"  --put /dev/null  -- -k -v  http://$s3_storage_url/bucket1
  • 버킷 내에서 오브젝트의 PUT 작업을 수행하려면 다음을 수행합니다.

    s3curl.pl --debug --id "testvolume:adminuser" --key "itsmine" --put  my_object.jpg  -- -k -v -s http://$s3_storage_url/bucket1/my_object.jpg
  • 버킷에서 오브젝트 목록을 확인하려면 다음을 수행합니다.

    s3curl.pl --debug --id "testvolume:adminuser" --key "itsmine"  -- -k -v -s http://$s3_storage_url/bucket1/

6장. 클러스터 관리자 설정

인증

AllowAll Authentication 메서드를 사용하여 인증을 설정합니다.

AllowAll Authentication

모든 암호를 허용하는 인증 모델을 설정합니다. OpenShift 마스터에서 /etc/origin/master/master-config.yaml 을 편집하고 DenyAllPasswordIdentityProvider 값을 AllowAllPasswordIdentityProvider 로 변경합니다. 그런 다음 OpenShift 마스터를 다시 시작합니다.

  1. 이제 인증 모델이 설정되었으므로 사용자로 로그인합니다(예: admin/admin).

    # oc login openshift master e.g. https://1.1.1.1:8443  --username=admin --password=admin
  2. admin 사용자 계정에 cluster-admin 역할을 부여합니다.

    # oc login -u system:admin -n default
    Logged into "https:// <<openshift_master_fqdn>>:8443" as "system:admin" using existing credentials.
    
    You have access to the following projects and can switch between them with 'oc project <projectname>':
    
    *default
     glusterfs
     infra-storage
     kube-public
     kube-system
     management-infra
     openshift
     openshift-infra
     openshift-logging
     openshift-node
     openshift-sdn
     openshift-web-console
    
    Using project "default".
    
    # oc adm policy add-cluster-role-to-user cluster-admin admin
    cluster role "cluster-admin" added: "admin"

인증 방법에 대한 자세한 내용은 https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/configuring_clusters/#identity-providers-configuring 을 참조하십시오.

7장. Gluster Block Storage를 로깅 및 지표용 백엔드로

다음 섹션에서는 로깅 및 메트릭용 백엔드 스토리지로 Gluster Block Storage를 구성합니다.

참고

OpenShift Container Storage 3.11에서 블록 볼륨 확장이 지원됩니다. 3.2.3절. “블록 볼륨 확장” 을 참조하십시오.

7.1. 사전 요구 사항

gluster 블록 스토리지를 로깅 또는 메트릭의 백엔드로 설정하기 전에 다음 사전 요구 사항이 충족되는지 확인합니다.

  • storageclass 파일에서 기본 스토리지 클래스가 gluster 블록의 스토리지 클래스로 설정되어 있는지 확인합니다. 예를 들면 다음과 같습니다.

    # oc get storageclass
    NAME                TYPE
    gluster-block        gluster.org/glusterblock
  • 기본값이 gluster-block (또는 제공된 다른 이름)으로 설정되지 않은 경우 다음 명령을 실행합니다. 예를 들면 다음과 같습니다.

    # oc patch storageclass gluster-block -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'
    • 다음 명령을 실행하여 확인합니다.

      oc get storageclass
      NAME                     TYPE
      gluster-block (default)   gluster.org/glusterblock

7.2. Gluster 블록 스토리지를 로깅의 백엔드로 활성화

아래에 언급된 작업을 수행하여 로깅을 위한 백엔드로 Gluster Block Storage를 활성화합니다.

  1. Openshift Container Platform에서 로깅을 활성화하려면 https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/configuring_clusters/#install-config-aggregate-logging를 참조하십시오.
  2. openshift_logging_es_pvc_dynamic ansible 변수를 true로 설정해야 합니다.

    [OSEv3:vars] openshift_logging_es_pvc_dynamic=true

    예를 들어 openshift_logging_에 대한 샘플 변수 세트는 다음과 같습니다.

    openshift_logging_install_logging=true
    openshift_logging_es_pvc_dynamic=true
    openshift_logging_kibana_nodeselector={"node-role.kubernetes.io/infra": "true"}
    openshift_logging_curator_nodeselector={"node-role.kubernetes.io/infra": "true"}
    openshift_logging_es_nodeselector={"node-role.kubernetes.io/infra": "true"}
    openshift_logging_es_pvc_size=10Gi
    openshift_logging_es_pvc_storage_class_name="glusterfs-registry-block"
  3. Ansible 플레이북을 실행합니다. 자세한 내용은https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/configuring_clusters/#install-config-aggregate-logging을 참조하십시오.
  4. 확인하려면 다음 명령을 실행합니다.

    # oc get pods -n openshift-logging

7.3. Gluster 블록 스토리지를 지표의 백엔드로 활성화

아래 설명된 작업을 수행하여 Gluster Block Storage를 지표의 백엔드로 활성화합니다.

참고

기본적으로 Container Native Storage는 3방향 복제를 수행하므로 클러스터의 모든 위치에서 재시작된 노드에서 데이터를 사용할 수 있습니다. 따라서 용량 오버헤드를 방지하기 위해 rhcos-level 복제를 해제하는 것이 좋습니다.

  1. Openshift Container 플랫폼에서 메트릭을 활성화하려면 https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/configuring_clusters/#install-config-cluster-metrics를 참조하십시오.
  2. openshift_metrics_cassandra_storage_type ansible 변수를 dynamic 로 설정해야 합니다.

    [OSEv3:vars]openshift_metrics_cassandra_storage_type=dynamic

    예를 들어 openshift_metrics_의 샘플 변수 세트는 다음과 같습니다.

    openshift_metrics_install_metrics=true
    openshift_metrics_storage_kind=dynamic
    openshift_metrics_hawkular_nodeselector={"node-role.kubernetes.io/infra": "true"}
    openshift_metrics_cassandra_nodeselector={"node-role.kubernetes.io/infra": "true"}
    openshift_metrics_heapster_nodeselector={"node-role.kubernetes.io/infra": "true"}
    openshift_metrics_storage_volume_size=10Gi
    openshift_metrics_cassandra_pvc_storage_class_name="glusterfs-registry-block"
  3. Ansible 플레이북을 실행합니다. 자세한 내용은 https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/configuring_clusters/#install-config-cluster-metrics 을 참조하십시오.
  4. 확인하려면 다음 명령을 실행합니다.

    # oc get pods --namespace openshift-infra

    실행 중인 다음 포드가 나열되어야 합니다.

    heapster-cassandra
    heapster-metrics
    hawkular-&*9
참고

지표 스토리지 고려 사항에 대한 자세한 내용은 https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/configuring_clusters/#metrics-data-storage 을 참조하십시오.

7.4. Gluster Block이 백엔드로 설정되어 있는지 확인

다음 명령을 실행하여 로깅 및 메트릭에 대해 gluster 블록이 백엔드로 설정되어 있는지 확인합니다.

  1. 인프라 개요를 보려면 다음 명령을 실행합니다.

    # oc get pods -n logging -o jsonpath='{range .items[].status.containerStatuses[]}{"Name: "}{.name}{"\n  "}{"Image: "}{.image}{"\n"}{"  State: "}{.state}{"\n"}{end}'
  2. 모든 영구 볼륨 클레임의 세부 정보를 가져오려면 다음 명령을 실행합니다.

    # oc get pvc
  3. pvc의 세부 정보를 가져오려면 다음 명령을 실행합니다.

    # oc describe pvc <claim_name>

    볼륨을 마운트할 수 있고 권한이 읽기/쓰기를 허용하는지 확인합니다. 또한 PVC 클레임 이름은 동적으로 프로비저닝된 gluster 블록 스토리지 클래스와 일치해야 합니다.

    자세한 내용은 https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html-single/configuring_clusters/#install-config-aggregate-logging-sizing 을 참조하십시오.

III 부. 보안

8장. 암호화 활성화

Red Hat Gluster Storage는 TLS/SSL을 사용하여 네트워크 암호화를 지원합니다. Red Hat Gluster Storage는 일반 연결에 사용되는 홈 확장 인증 프레임워크 대신 인증 및 권한 부여에 TLS/SSL을 사용합니다. Red Hat Gluster Storage는 다음과 같은 암호화 유형을 지원합니다.

  • I/O 암호화 - Red Hat Gluster Storage 클라이언트와 서버 간 I/O 연결 암호화
  • 관리 암호화 - 신뢰할 수 있는 스토리지 풀 내의 관리(glusterd) 연결 암호화입니다.

8.1. 사전 요구 사항

암호화를 활성화하려면 노드당 3개의 인증서(glusterfs.key, gluserfs.pem 및 glusterfs.ca)가 있어야 합니다. 사전 요구 사항으로 수행할 단계에 대한 자세한 내용은 https://access.redhat.com/documentation/en-us/red_hat_gluster_storage/3.5/html-single/administration_guide/index#chap-Network_Encryption-Preparing_Certificates 을 참조하십시오.

volumeoptions 매개 변수를 사용하여 storageclass 파일을 등록하는 동안 암호화를 활성화해야 합니다. 파일 스토리지의 스토리지 클래스 파일 등록에 대한 자세한 내용은 https://access.redhat.com/documentation/en-us/red_hat_openshift_container_storage/3.11/html-single/operations_guide/index#chap-Documentation-Red_Hat_Gluster_Storage_Container_Native_with_OpenShift_Platform-OpenShift_Creating_Persistent_Volumes-Dynamic_Prov 을 참조하십시오.

참고
  • master를 제외한 모든 OpenShift 노드에서 단계를 수행해야 합니다.
  • 모든 Red Hat Gluster Storage 볼륨은 OpenShift 노드에 마운트되고 애플리케이션 포드에 바인드 마운트됩니다. 따라서 애플리케이션 Pod에서 특히 암호화 관련 작업을 수행할 필요가 없습니다.

8.2. 새로운 Red Hat Openshift Container Storage 설정의 암호화 활성화

I/O 암호화 및 관리 암호화에 대해 새로운 Red Hat Openshift Container Storage 설정에 대한 네트워크 암호화를 구성할 수 있습니다.

8.2.1. 관리 암호화 활성화

Red Hat Gluster Storage는 관리 암호화를 사용하지 않고 I/O 암호화에 대해서만 구성할 수 있지만 관리 암호화를 사용하는 것이 좋습니다. I/O 경로에서만 SSL을 활성화하려면 이 섹션을 건너뛰고 8.2.2절. “볼륨의 I/O 암호화 활성화” 로 진행합니다.

On the server

모든 서버(예: Red Hat Gluster Storage 포드가 실행 중인 OpenShift 노드)에서 다음을 수행합니다.

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

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

On the clients

클라이언트에서 Red Hat Gluster Storage가 실행되지 않는 나머지 모든 OpenShift 노드에서 다음을 수행합니다.

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

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

모든 Red Hat Gluster Storage 볼륨은 OpenShift 노드에 마운트되고 애플리케이션 포드에 바인드 마운트됩니다. 따라서 애플리케이션 Pod에서 특히 암호화 관련 작업을 수행할 필요가 없습니다.

서버 및 클라이언트에서 명령을 실행한 후 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 을 참조하십시오.

8.2.2. 볼륨의 I/O 암호화 활성화

서버와 클라이언트 간의 I/O 암호화를 활성화합니다.

참고

서버는 Red Hat Gluster Storage 포드가 실행되는 OpenShift 노드입니다.

클라이언트는 Red Hat Gluster Storage가 실행되지 않는 나머지 OpenShift 노드입니다.

  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

8.3. 기존 Red Hat Openshift Container Storage 설정에 대한 암호화 활성화

I/O 암호화 및 관리 암호화에 대해 기존 Red Hat Openshift Container Storage 스토리지 설정에 대한 네트워크 암호화를 구성할 수 있습니다.

8.3.1. 볼륨의 I/O 암호화 활성화

볼륨의 서버와 클라이언트 간 I/O 암호화를 활성화합니다.

참고

서버는 Red Hat Gluster Storage 포드가 실행되는 OpenShift 노드입니다.

클라이언트는 Red Hat Gluster Storage가 실행되지 않는 나머지 OpenShift 노드입니다.

  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 볼륨을 사용합니다.

8.3.2. 관리 암호화 활성화

관리 암호화가 권장되지만 Red Hat Gluster Storage는 관리 암호화를 사용하지 않고 I/O 암호화에 대해서만 구성할 수 있습니다. 서버 및 클라이언트를 실행하는 기존 설치에서 볼륨, 애플리케이션, 클라이언트 및 기타 최종 사용자의 다운타임을 예약하여 관리 암호화를 활성화합니다.

현재 암호화되지 않은 연결과 암호화된 연결은 동적으로 변경할 수 없습니다. 서버 및 클라이언트의 번들과 기타 로컬 서비스는 관리 암호화로 전환될 때 실행 중인 경우 pxe에서 알림을 수신하지 않습니다.

  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를 사용하려면 애플리케이션 포드를 시작합니다.

8.4. 암호화 비활성화

다음 두 가지 시나리오에서 Red Hat Openshift Container Storage 설정에서 에 대한 암호화를 비활성화할 수 있습니다.

  • 볼륨의 I/O 암호화 비활성화
  • 관리 암호화 비활성화

8.4.1. 모든 볼륨의 I/O 암호화 비활성화

다음 명령을 실행하여 볼륨과 서버 간 I/O 암호화를 비활성화합니다.

참고

서버는 Red Hat Gluster Storage 포드가 실행되는 OpenShift 노드입니다.

클라이언트는 Red Hat Gluster Storage가 실행되지 않는 나머지 OpenShift 노드입니다.

  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 볼륨을 사용합니다.

8.4.2. 관리 암호화 비활성화

현재 암호화되지 않은 연결과 암호화된 연결은 동적으로 변경할 수 없습니다. 서버 및 클라이언트의 번들과 기타 로컬 서비스는 관리 암호화로 전환될 때 실행 중인 경우 pxe에서 알림을 수신하지 않습니다.

다음 명령을 실행하여 관리 암호화를 비활성화합니다.

  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를 사용하려면 애플리케이션 포드를 시작합니다.

IV 부. Migration

9장. Red Hat Openshift Container Storage를 스토리지 백엔드로 사용하여 레지스트리 업데이트

OpenShift Container Platform은 자동으로 설정된 NFS 지원 영구 볼륨을 사용하여 스토리지가 포함된 통합 레지스트리를 제공합니다. Red Hat Openshift Container Storage를 레지스트리 스토리지의 Gluster 영구 볼륨으로 교체할 수 있습니다. 이를 통해 안정성, 확장성 및 페일오버가 향상됩니다.

OpenShift Container Platform 및 docker-registry에 대한 자세한 내용은 https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html/configuring_clusters/setting-up-the-registry 을 참조하십시오.

9.1. Openshift Container Platform 레지스트리 배포 검증

레지스트리가 올바르게 배포되었는지 확인하려면 다음 명령을 실행합니다.

  1. 마스터 또는 클라이언트에서 다음 명령을 실행하여 클러스터 관리자로 로그인합니다.

    # oc login

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

    # oc login
    
    Authentication required for https://master.example.com:8443 (openshift)
    Username: <cluster-admin-user>
    Password: <password>
    Login successful.
    
    You have access to the following projects and can switch between them with 'oc project <projectname>':
    
      * default
        management-infra
        openshift
        openshift-infra
    
    Using project "default".

    프로젝트 기본값으로 자동으로 로그인하지 않은 경우 다음 명령을 실행하여 해당 프로젝트로 전환합니다.

    # oc project default
  2. Pod가 생성되었는지 확인하려면 다음 명령을 실행합니다.

    # oc get pods

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

    # oc get pods
    NAME                       READY     STATUS    RESTARTS   AGE
    docker-registry-2-mbu0u    1/1       Running   4          6d
    docker-registry-2-spw0o    1/1       Running   3          6d
    registry-console-1-rblwo   1/1       Running   3          6d
  3. 끝점이 생성되었는지 확인하려면 다음 명령을 실행합니다.

    # oc get endpoints

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

    # oc get endpoints
    NAME               ENDPOINTS                                                                  AGE
    docker-registry    10.128.0.15:5000,10.129.0.9:5000                                           7d
    kubernetes         192.168.234.143:8443,192.168.234.143:8053,192.168.234.143:8053             7d
    registry-console   10.128.0.17:9090                                                           7d
    router             192.168.234.144:443,192.168.234.145:443,192.168.234.144:1936 + 3 more...   7d
  4. 영구 볼륨이 생성되었는지 확인하려면 다음 명령을 실행합니다.

    # oc get pv
    NAME   CAPACITY   ACCESSMODES   RECLAIMPOLICY   STATUS      CLAIM  REASON    AGE
    registry-volume           5Gi        RWX           Retain          Bound       default/registry-claim             7d
  5. NFS 레지스트리를 위해 생성된 영구 볼륨의 세부 정보를 가져오려면 다음 명령을 실행합니다.

    # oc describe pv registry-volume
    Name:        registry-volume
    Labels:        <none>
    StorageClass:
    Status:        Bound
    Claim:        default/registry-claim
    Reclaim Policy:    Retain
    Access Modes:    RWX
    Capacity:    5Gi
    Message:
    Source:
        Type:    NFS (an NFS mount that lasts the lifetime of a pod)
        Server:    cns30.rh73
        Path:    /exports/registry
        ReadOnly:    false
    No events.

9.2. Red Hat Openshift Container Storage로 Openshift Container Platform Registry 변환

이 섹션에서는 Red Hat Gluster Storage 볼륨을 생성하고 이를 사용하여 통합 레지스트리에 스토리지를 제공하는 단계를 제공합니다.

Red Hat Gluster Storage 영구 볼륨 설정

다음 명령을 실행하여 레지스트리 데이터를 저장하고 영구 볼륨을 생성할 Red Hat Gluster Storage 볼륨을 생성합니다.

참고

명령은 기본 프로젝트에서 실행해야 합니다.

  1. 기본 프로젝트에 로그인합니다.

    # oc project default

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

    # oc project default
    Now using project "default" on server "https://cns30.rh73:8443"
  2. 다음 명령을 실행하여 gluster-registry-endpoints.yaml 파일을 생성합니다.

     oc get endpoints <heketi-db-storage-endpoint-name> -o yaml --namespace=<project-name> >  gluster-registry-endpoints.yaml
    참고

    Red Hat Gluster Storage 레지스트리를 사용하려는 각 프로젝트에 대한 끝점을 생성해야 합니다. 따라서 기본 프로젝트와 이전 단계에서 생성한 새 프로젝트(storage-project)에 서비스와 엔드포인트가 있습니다.

  3. gluster-registry-endpoints.yaml 파일을 편집합니다. 이름을 gluster-registry-endpoints로 변경하고 다른 모든 메타데이터를 제거하여 다른 모든 메타데이터를 삭제합니다.

    # cat gluster-registry-endpoints.yaml
    apiVersion: v1
    kind: Endpoints
    metadata:
      name: gluster-registry-endpoints
    subsets:
      - addresses:
          - ip: 192.168.124.114
          - ip: 192.168.124.52
          - ip: 192.168.124.83
        ports:
          - port: 1
    protocol: TCP
  4. 다음 명령을 실행하여 끝점을 생성합니다.

    # oc create -f gluster-registry-endpoints.yaml
    endpoints "gluster-registry-endpoints" created
  5. 끝점 생성을 확인하려면 다음 명령을 실행합니다.

    # oc get endpoints
    NAME                       ENDPOINTS                                                                 AGE
    docker-registry            10.129.0.8:5000,10.130.0.5:5000                                           28d
    gluster-registry-endpoints  192.168.124.114:1,192.168.124.52:1,192.168.124.83:1                       10s
    kubernetes                 192.168.124.250:8443,192.168.124.250:8053,192.168.124.250:8053            28d
    registry-console           10.131.0.6:9090                                                           28d
    router                     192.168.124.114:443,192.168.124.83:443,192.168.124.114:1936 + 3 more...   28d
  6. 다음 명령을 실행하여 gluster-registry-service.yaml 파일을 생성합니다.

     oc get services <heketi-storage-endpoint-name> -o yaml --namespace=<project-name> >  gluster-registry-service.yaml
  7. gluster-registry-service.yaml 파일을 편집합니다. 이름을 gluster-registry-service로 변경하고 다른 모든 메타데이터를 제거합니다. 또한 특정 클러스터 IP 주소를 제거합니다.

    # cat gluster-registry-service.yaml
    apiVersion: v1
    kind: Service
    metadata:
      name: gluster-registry-service
    spec:
      ports:
        - port: 1
          protocol: TCP
          targetPort: 1
      sessionAffinity: None
      type: ClusterIP
    status:
    loadBalancer: {}
  8. 다음 명령을 실행하여 서비스를 생성합니다.

    # oc create -f gluster-registry-service.yaml
    services "gluster-registry-service" created
  9. 다음 명령을 실행하여 서비스가 실행 중인지 확인합니다.

    # oc get services
    NAME                       CLUSTER-IP       EXTERNAL-IP   PORT(S)                   AGE
    docker-registry            172.30.197.118   <none>        5000/TCP                  28d
    gluster-registry-service   172.30.0.183     <none>        1/TCP                     6s
    kubernetes                 172.30.0.1       <none>        443/TCP,53/UDP,53/TCP     29d
    registry-console           172.30.146.178   <none>        9000/TCP                  28d
    router                     172.30.232.238   <none>        80/TCP,443/TCP,1936/TCP   28d
  10. 다음 명령을 실행하여 기존 docker-registry Pod의 fsGroup GID를 가져옵니다.

    # export GID=$(oc get po --selector="docker-registry=default" -o go-template --template='{{printf "%.0f" ((index .items 0).spec.securityContext.fsGroup)}}')
  11. 다음 명령을 실행하여 볼륨을 생성

    # heketi-cli volume create --size=5 --name=gluster-registry-volume --gid=${GID}
  12. Red Hat Gluster Storage 볼륨의 영구 볼륨 파일을 만듭니다.

    # cat gluster-registry-volume.yaml
    kind: PersistentVolume
    apiVersion: v1
    metadata:
      name: gluster-registry-volume
      labels:
        glusterfs: registry-volume
    spec:
      capacity:
        storage: 5Gi
      glusterfs:
        endpoints: gluster-registry-endpoints
        path: gluster-registry-volume
      accessModes:
        - ReadWriteMany
    persistentVolumeReclaimPolicy: Retain
  13. 다음 명령을 실행하여 영구 볼륨을 생성합니다.

    # oc create -f gluster-registry-volume.yaml
  14. 다음 명령을 실행하여 생성된 영구 볼륨의 세부 정보를 확인하고 가져옵니다.

    # oc get pv/gluster-registry-volume
    NAME                      CAPACITY   ACCESSMODES   RECLAIMPOLICY   STATUS      CLAIM     REASON    AGE
    gluster-registry-volume   5Gi        RWX           Retain          Available                       21m
  15. 새 영구 볼륨 클레임을 생성합니다. 다음은 기존 registry-storage 볼륨 클레임을 대체하는 데 사용되는 샘플 영구 볼륨 클레임입니다.

    # cat gluster-registry-claim.yaml
    apiVersion: v1
    kind: PersistentVolumeClaim
    metadata:
      name: gluster-registry-claim
    spec:
      accessModes:
        - ReadWriteMany
      resources:
        requests:
          storage: 5Gi
      selector:
        matchLabels:
    glusterfs: registry-volume
  16. 다음 명령을 실행하여 영구 볼륨 클레임을 생성합니다.

    # oc create -f gluster-registry-claim.yaml

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

    # oc create -f gluster-registry-claim.yaml
    persistentvolumeclaim "gluster-registry-claim" created
  17. 다음 명령을 실행하여 클레임이 바인딩되었는지 확인합니다.

    # oc get pvc/gluster-registry-claim

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

    # oc get pvc/gluster-registry-claim
    NAME                     STATUS    VOLUME                    CAPACITY   ACCESSMODES   AGE
    gluster-registry-claim   Bound     gluster-registry-volume   5Gi        RWX           22s
  18. 다음 명령을 실행하여 레지스트리를 읽기 전용으로 설정합니다.

    # oc set env -n default dc/docker-registry 'REGISTRY_STORAGE_MAINTENANCE_READONLY={"enabled":true}'

    값이 readonly로 설정되어 있는지 확인하려면 다음 명령을 실행합니다.

    # oc set env -n default dc/docker-registry --list
  19. 이전 레지스트리에서 Red Hat Gluster Storage 레지스트리로 데이터를 마이그레이션하려면 다음 명령을 실행합니다.

    참고

    이러한 단계는 선택 사항입니다.

    1. 다음 명령을 실행하여 이전 레지스트리 배포 구성(dc)에 Red Hat Gluster Storage 레지스트리를 추가합니다.

      # oc set volume dc/docker-registry --add --name=gluster-registry-storage -m /gluster-registry -t pvc --claim-name=gluster-registry-claim
    2. 다음 명령을 실행하여 레지스트리 Pod 이름을 저장합니다.

      # export REGISTRY_POD=$(oc get po --selector="docker-registry=default" -o go-template --template='{{printf "%s" ((index .items 0).metadata.name)}}')
    3. 다음 명령을 실행하여 이전 레지스트리 디렉터리의 데이터를 Red Hat Gluster Storage 레지스트리 디렉터리에 복사합니다.

      # oc rsh -T $REGISTRY_POD cp -aTv /registry/ /gluster-registry/
    4. 다음 명령을 실행하여 이전 dc 레지스트리에서 Red Hat Gluster Storage 레지스트리를 제거합니다.

      # oc volume dc/docker-registry --remove --name=gluster-registry-storage
  20. 기존 registry-storage 볼륨을 새 gluster-registry-claim PVC로 교체합니다.

    # oc set volume dc/docker-registry --add --name=registry-storage -t pvc --claim-name=gluster-registry-claim --overwrite
  21. 다음 명령을 실행하여 레지스트리 읽기 쓰기를 만듭니다.

    # oc set env dc/docker-registry REGISTRY_STORAGE_MAINTENANCE_READONLY-

    설정이 쓰기로 설정되어 있는지 확인하려면 다음 명령을 실행합니다.

    # oc set env -n default dc/docker-registry --list

레지스트리 액세스에 대한 자세한 내용은 https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html/configuring_clusters/setting-up-the-registry#install-config-registry-accessing 을 참조하십시오.

V 부. 모니터링

10장. OpenShift 3.10 및 3.11에서 볼륨 지표 활성화

Prometheus는 독립형 오픈 소스 시스템 모니터링 및 경고 툴킷이며 OpenShift와 함께 제공됩니다. Prometheus를 사용하여 OpenShift Container Platform 시스템 리소스에 대한 지표 및 경고를 heketi와 같은 PV 및 서비스로 시각화할 수 있습니다.

heketi는 GlusterFS 볼륨의 라이프 사이클과 Prometheus에서 스크랩할 수 있는 지표 끝점을 관리하는 데 사용할 수 있는 RESTful 관리 인터페이스를 제공합니다.

Prometheus는 OpenShift에 OCP 3.10과 3.11 사이에서 약간 다릅니다.

OCP 3.10에서 Prometheus를 설정하는 방법에 대한 자세한 내용은 OpenShift Container Platform의 Prometheus 를 참조하십시오.

OCP 3.11에서 Prometheus를 설정하는 방법에 대한 자세한 내용은 Prometheus 클러스터 모니터링을 참조하십시오.

10.1. 파일 스토리지 및 블록 스토리지에 사용 가능한 지표

다음 목록은 Prometheus에서 볼 수 있는 PV의 다양한 메트릭을 제공합니다.

kubelet_volume_stats_available_bytes
볼륨에서 사용 가능한 바이트 수입니다.
kubelet_volume_stats_capacity_bytes
볼륨의 용량(바이트)입니다.
kubelet_volume_stats_inodes
볼륨의 최대 inode 수입니다.
kubelet_volume_stats_inodes_free
볼륨에서 사용 가능한 inode 수입니다.
kubelet_volume_stats_inodes_used
볼륨에서 사용되는 inode 수입니다.
kubelet_volume_stats_used_bytes
볼륨에서 사용된 바이트 수입니다.

Heketi 서비스는 다음 메트릭을 제공합니다.

heketi_cluster_count
클러스터 수.
heketi_device_brick_count
장치의 브릭 수입니다.
heketi_device_count
host의 장치 수입니다.
heketi_device_free_bytes
장치에서 사용 가능한 여유 공간의 양입니다.
heketi_device_size_bytes
장치의 총 크기입니다.
heketi_device_used_bytes
장치에서 사용되는 공간의 양입니다.
heketi_nodes_count
클러스터의 노드 수입니다.
heketi_up
heketi가 실행 중인지 확인합니다.
heketi_volumes_count
클러스터의 볼륨 수입니다.
heketi_block_volumes_count
클러스터의 블록 볼륨 수입니다.

10.2. OpenShift 3.10에서 Heketi 지표 활성화

OCP 3.10의 Prometheus에서 Heketi 지표를 보려면 다음 명령을 실행합니다.

  1. heketi-storage 서비스(일반적으로 app-storage 네임스페이스에서 실행 중인)에 주석을 추가합니다.

    # oc project app-storage
    # oc annotate svc heketi-storage prometheus.io/scheme=http
    # oc annotate svc heketi-storage prometheus.io/scrape=true
    # oc describe svc heketi-storage
    Name:          	heketi-storage
    Namespace:     	app-storage
    Labels:        	glusterfs=heketi-storage-service
       	            heketi=storage-service
    Annotations:   	description=Exposes Heketi service
       	            prometheus.io/scheme=http
       	             prometheus.io/scrape=true
    Selector:      	glusterfs=heketi-storage-pod
    Type:          	ClusterIP
    IP:            	172.30.90.87
    Port:          	heketi  8080/TCP
    TargetPort:    	8080/TCP
    Endpoints:     	172.18.14.2:8080
    Session Affinity:  None
  2. Prometheus 구성 맵에 heketi 서비스의 app-storage 네임스페이스를 추가합니다.

    # oc get cm prometheus -o yaml -n openshift-metrics
    ....
    - job_name: 'kubernetes-service-endpoints'
    
         tls_config:
         ca_file: /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
         # TODO: this should be per target
         insecure_skip_verify: true
    
         kubernetes_sd_configs:
         - role: endpoints
    
         relabel_configs:
         # only scrape infrastructure components
         - source_labels: [__meta_kubernetes_namespace]
         action: keep
    regex: 'default|logging|metrics|kube-.+|openshift|openshift-.+|app-storage'

    다른 모든 스토리지 네임스페이스(예: infra-storage)에 대해 위의 작업을 수행합니다.

  3. prometheus-0 Pod를 다시 시작하여 Prometheus의 Heketi 지표를 쿼리합니다.

10.3. OpenShift 3.11에서 Heketi 지표 활성화

OCP 3.11에서 Prometheus는 Prometheus Operator에서 도입한 새 리소스인 servicemonitors를 사용합니다. 모든 스토리지 네임스페이스에 대해 servicemonitor를 생성해야 하며 모니터링할 대상 집합을 설명합니다.

OCP 3.11의 Prometheus에서 Heketi 지표를 보려면 다음 명령을 실행합니다.

  1. heketi-storage 서비스에 주석을 추가합니다.

    # oc project app-storage
    # oc annotate svc heketi-storage prometheus.io/scheme=http
    # oc annotate svc heketi-storage prometheus.io/scrape=true
  2. 아래 템플릿을 사용하여 openshift-monitoring 네임스페이스에 heketi-app 서비스monitor를 생성합니다.

    # cat heketi-app-sm.yml
    apiVersion: monitoring.coreos.com/v1
    kind: ServiceMonitor
    metadata:
      name: heketi-app
      labels:
        k8s-app: heketi-app
      namespace: openshift-monitoring
    spec:
      endpoints:
      - bearerTokenFile: /var/run/secrets/kubernetes.io/serviceaccount/token
        interval: 30s
        port: heketi
        scheme: http
        targetPort: 0
      namespaceSelector:
        matchNames:
        - app-storage
      selector:
        matchLabels:
          heketi: storage-service

    여기서 namespaceSelector 및 라벨은 heketi-storage 서비스의 값과 일치해야 합니다.

    # oc describe svc heketi-storage -n app-storage
    Name:              heketi-storage
    Namespace:         app-storage
    Labels:            glusterfs=heketi-storage-service
                       heketi=storage-service
    Annotations:       description=Exposes Heketi service
                       prometheus.io/scheme=http
                       prometheus.io/scrape=true
    Selector:          glusterfs=heketi-storage-pod
    Type:              ClusterIP
    IP:                172.30.3.92
    Port:              heketi  8080/TCP
    TargetPort:        8080/TCP
    Endpoints:         10.128.4.12:8080
    Session Affinity:  None
    Events:            <none>

    올바른 선택기를 설정하면 올바른 선택기가 설정된 openshift-monitoring 네임스페이스에 servicemonitor를 생성합니다.

    # oc create -f heketi-app-sm.yml -n openshift-monitoring
    servicemonitor.monitoring.coreos.com "heketi-app" created
    # oc get servicemonitor -n openshift-monitoring
    NAME                          AGE
    alertmanager                  20d
    cluster-monitoring-operator   20d
    heketi-app                    1m
    kube-apiserver                20d
    kube-controllers              20d
    kube-state-metrics            20d
    kubelet                       20d
    node-exporter                 20d
    prometheus                    20d
    prometheus-operator           20d
  3. OCS 클러스터가 여러 개 있는 경우 위의 단계를 사용하여 OCS 클러스터당 하나의 servicemonitor를 생성해야 합니다.
  4. 다음 명령을 실행하여 prometheus에 cluster-reader 권한을 추가합니다.

    # oc adm policy add-cluster-role-to-user cluster-reader \
    system:serviceaccount:openshift-monitoring:prometheus-k8s -n \
    openshift-monitoring
    cluster role "cluster-reader" added: "system:serviceaccount:openshift-monitoring:prometheus-k8s"
  5. 몇 분 후에 Prometheus는 새 servicemonitor를 로드합니다.

10.4. 지표 보기

메트릭을 보려면 다음을 수행합니다.

  1. Prometheus 에 지표 이름을 추가하고 실행 을 클릭합니다.
  2. Graph (그래프) 탭에 볼륨의 지표 값이 그래프로 표시됩니다.

    예를 들어 다음 이미지에서 사용 가능한 바이트를 확인하려면 kubelet_volume_stats_available_bytes 지표가 Prometheus 의 검색 표시줄에 추가됩니다. 실행 을 클릭하면 사용 가능한 바이트 값이 그래프로 표시됩니다. 자세한 내용을 보려면 줄의 마우스를 가리킬 수 있습니다. (이미지를 자세히 보려면 마우스 오른쪽 버튼으로 클릭하고 View Image를 선택합니다.)

    Viewing metrics

VI 부. 문제 해결

11장. 문제 해결

이 장에서는 Red Hat Openshift Container Storage와 관련된 일반적인 문제 해결 시나리오에 대해 설명합니다.

Red Hat Openshift Container Storage 노드 Fails인 경우 어떻게 해야 합니까?

Red Hat Openshift Container Storage 노드가 실패하고 삭제하려는 경우 노드를 삭제하기 전에 노드를 비활성화합니다. 자세한 내용은 1.2.4절. “노드 삭제”의 내용을 참조하십시오.

Red Hat Openshift Container Storage 노드에 실패하고 교체하려는 경우 1.3.2절. “노드 교체” 을 참조하십시오.

Red Hat Openshift Container Storage 장치가 실패하는 경우 어떻게 해야 합니까?

Red Hat Openshift Container Storage 장치가 실패하고 삭제하려는 경우 장치를 삭제하기 전에 장치를 비활성화합니다. 자세한 내용은 1.2.3절. “장치 삭제”의 내용을 참조하십시오.

Red Hat Openshift Container Storage 장치가 실패하고 이를 교체하려는 경우 1.3.1절. “장치 교체” 를 참조하십시오.

Red Hat Openshift Container Storage 볼륨에 더 많은 용량이 필요한 경우 어떻게 해야 합니까?
장치를 추가하거나 클러스터 크기를 늘리거나 완전히 새로운 클러스터를 추가하여 스토리지 용량을 늘릴 수 있습니다. 자세한 내용은 1.1절. “스토리지 용량 증가”의 내용을 참조하십시오.
Red Hat Openshift Container Storage를 설치할 때 Openshift를 업그레이드하는 방법
Openshift Container Platform을 업그레이드하려면 https://access.redhat.com/documentation/en-us/openshift_container_platform/3.11/html/upgrading_clusters/install-config-upgrading-automated-upgrades#upgrading-to-ocp-3-10 를 참조하십시오.
로그 파일 보기
  • Red Hat Gluster Storage 컨테이너 로그 보기

    Red Hat Gluster Storage 컨테이너와 관련된 디버깅 정보는 컨테이너가 시작된 호스트에 저장됩니다. 특히 로그 및 구성 파일은 Red Hat Gluster Storage 서버 컨테이너가 실행되는 openshift 노드의 다음 위치에서 찾을 수 있습니다.

    • /etc/glusterfs
    • /var/lib/glusterd
    • /var/log/glusterfs
  • Heketi 로그 보기

    Heketi와 관련된 디버깅 정보는 컨테이너 또는 Heketi 컨테이너에 제공된 영구 볼륨에 로컬로 저장됩니다.

    컨테이너가 실행되는 openshift 노드에서 docker logs <container-id> 명령을 실행하여 Heketi에 대한 로그를 가져올 수 있습니다.

heketi 명령은 오류 또는 빈 오류 없이 반환

경우에 따라 heketi-cli 명령을 실행하면 오류 없이 반환되거나 _ Error_.It과 같은 빈 오류가 발생하지 않는 경우가 있습니다. 대부분의 경우 heketi 서버가 올바르게 구성되지 않았기 때문입니다. 먼저 Heketi 서버가 사용 가능한지 확인하고 나중에 _ curl_ 명령 및 _ /hello endpoint_를 사용하여 확인합니다.

# curl http://deploy-heketi-storage-project.cloudapps.mystorage.com/hello
heketi는 토폴로지 파일을 로드하는 동안 오류를 보고합니다.
heketi-cli 보고서 실행: 토폴로지 파일을 로드하는 동안 "커뮤니티 파일을 열 수 없음" 오류 발생 이는 단일 하이픈(-)의 이전 구문을 JSON 옵션의 접두사로 사용하기 때문일 수 있습니다. 두 배 하이픈의 새 구문을 사용하고 토폴로지 파일을 다시 로드해야 합니다.
heketi 서버에 대한 curl 명령이 실패하거나 응답하지 않음

라우터 또는 heketi가 올바르게 구성되지 않은 경우 heketi의 오류 메시지가 명확하지 않을 수 있습니다. 문제를 해결하려면 엔드포인트를 사용하여 heketi 서비스를 ping하고 IP 주소를 사용합니다. IP 주소로 ping이 성공하고 엔드포인트에서 ping이 실패하면 라우터 구성 오류가 표시됩니다.

라우터가 올바르게 설정된 후 다음과 같이 간단한 curl 명령을 실행합니다.

# curl http://deploy-heketi-storage-project.cloudapps.mystorage.com/hello

heketi가 올바르게 구성된 경우 heketi의 시작 메시지가 표시됩니다. 그렇지 않은 경우 heketi 구성을 확인하십시오.

Red Hat Gluster Storage 볼륨이 heketi.db 파일을 저장하는 데 사용되는 경우 heketi가 시작되지 않습니다.

Red Hat Gluster Storage 볼륨을 사용하여 heketi.db를 저장하고 다음 오류를 보고하는 경우 Heketi가 시작되지 않는 경우가 있습니다.

[heketi] INFO 2016/06/23 08:33:47 Loaded kubernetes executor
[heketi] ERROR 2016/06/23 08:33:47 /src/github.com/heketi/heketi/apps/glusterfs/app.go:149: write /var/lib/heketi/heketi.db: read-only file system
ERROR: Unable to start application

Red Hat Gluster Storage 볼륨을 백엔드로 사용하는 동안 위에 표시된 읽기 전용 파일 시스템 오류가 표시될 수 있습니다. Red Hat Gluster Storage 볼륨에 대해 쿼럼이 손실된 경우 이 문제가 발생할 수 있습니다. replica-3 볼륨에서 3개의 브릭 중 2개가 다운되었는지 확인할 수 있습니다. heketi gluster 볼륨에 대해 쿼럼이 충족되었는지 확인해야 하며 heketi.db 파일에 다시 쓸 수 있습니다.

다른 오류가 표시되면 heketi.db 파일을 제공하는 Red Hat Gluster Storage 볼륨을 사용할 수 있는지 확인하는 것이 좋습니다. heketi.db 파일에 대한 액세스 거부는 시작되지 않는 가장 일반적인 이유입니다.

12장. 포트 전달을 사용하는 클라이언트 구성

라우터를 사용할 수 없는 경우 heketi-cli가 Heketi 서비스와 통신할 수 있도록 포트 전달을 설정할 수 있습니다. 포트 전달을 위해 다음 명령을 실행합니다.

  1. 다음 명령을 실행하여 Heketi 서비스 Pod 이름을 가져옵니다.

    # oc get pods
  2. 로컬 시스템의 포트를 Pod로 전달하려면 로컬 시스템의 다른 터미널에서 다음 명령을 실행합니다.

    # oc port-forward <heketi pod name> 8080:8080
  3. 원래 터미널에서 다음 명령을 실행하여 서버와의 통신을 테스트합니다.

    # curl http://localhost:8080/hello

    이렇게 하면 로컬 포트 8080이 Pod 포트 8080으로 전달됩니다.

  4. 다음 명령을 실행하여 Heketi 서버 환경 변수를 설정합니다.

    # export HEKETI_CLI_SERVER=http://localhost:8080
  5. 다음 명령을 실행하여 Heketi에서 정보를 가져옵니다.

    # heketi-cli topology info