Menu Close
Settings Close

Language and Page Formatting Options

OpenShift Data Foundation 문제 해결

Red Hat OpenShift Data Foundation 4.10

OpenShift Data Foundation 문제 해결에 대한 지침

초록

Red Hat OpenShift Data Foundation 문제 해결에 대한 지침은 이 문서를 읽어 보십시오.

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

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

Red Hat 문서에 관한 피드백 제공

문서 개선을 위한 의견을 보내 주십시오. Red Hat이 이를 개선하는 방법을 알려 주십시오. 피드백을 제공하려면 다음을 수행하십시오.

  • 특정 문구에 대한 간단한 의견 작성 방법은 다음과 같습니다.

    1. 문서가 Multi-page HTML 형식으로 표시되는지 확인합니다. 또한 문서 오른쪽 상단에 피드백 버튼이 있는지 확인합니다.
    2. 마우스 커서를 사용하여 주석 처리하려는 텍스트 부분을 강조 표시합니다.
    3. 강조 표시된 텍스트 아래에 표시되는 피드백 추가 팝업을 클릭합니다.
    4. 표시된 지침을 따릅니다.
  • 보다 상세하게 피드백을 제출하려면 다음과 같이 Bugzilla 티켓을 생성하십시오.

    1. Bugzilla 웹 사이트로 이동하십시오.
    2. 구성 요소 섹션에서 문서 를 선택합니다.
    3. Description 필드에 문서 개선을 위한 제안 사항을 기입하십시오. 관련된 문서의 해당 부분 링크를 알려주십시오.
    4. Submit Bug를 클릭하십시오.

1장. 개요

OpenShift Data Foundation 문제 해결은 관리자가 Red Hat OpenShift Data Foundation 클러스터의 문제 해결 및 수정 방법을 이해할 수 있도록 작성되었습니다.

대부분의 문제 해결 작업은 수정 사항 또는 해결 방법에 중점을 둡니다. 이 문서는 관리자가 발생할 수 있는 오류에 따라 장으로 나뉩니다.

2장. must-gather를 사용하여 로그 파일 및 진단 정보 다운로드

Red Hat OpenShift Data Foundation에서 문제를 자동으로 해결할 수 없는 경우 must-gather 툴을 사용하여 로그 파일 및 진단 정보를 수집하여 사용자 또는 Red Hat 지원이 문제를 검토하고 솔루션을 확인할 수 있도록 합니다.

중요

Red Hat OpenShift Data Foundation이 외부 모드로 배포되는 경우 must-gather 는 OpenShift Data Foundation 클러스터에서 로그만 수집하고 외부 Red Hat Ceph Storage 클러스터에서 디버그 데이터 및 로그를 수집하지 않습니다. 외부 Red Hat Ceph Storage 클러스터에서 디버그 로그를 수집하려면 Red Hat Ceph Storage 문제 해결 가이드 를 참조하여 Red Hat Ceph Storage 관리자에게 문의하십시오.

사전 요구 사항

  • 선택 사항: OpenShift Data Foundation이 연결이 끊긴 환경에 배포된 경우 연결이 끊긴 환경에서 사용 가능한 미러 레지스트리에 개별 must-gather 이미지를 미러링해야 합니다.

    $ oc image mirror registry.redhat.io/odf4/ocs-must-gather-rhel8:v4.10 <local-registry>/odf4/ocs-must-gather-rhel8:v4.10 [--registry-config=<path-to-the-registry-config>] [--insecure=true]
    <local-registry>
    연결이 끊긴 OpenShift Container Platform 클러스터에 사용 가능한 로컬 이미지 미러 레지스트리입니다.
    <path-to-the-registry-config>
    기본적으로 레지스트리 인증 정보의 경로는 ~/.docker/config.json 입니다.
    --insecure
    미러 레지스트리가 안전하지 않은 경우에만 이 플래그를 추가합니다.

    자세한 내용은 Red Hat Knowledgebase 솔루션을 참조하십시오.

절차

  • OpenShift Data Foundation 클러스터에 연결된 클라이언트에서 must-gather 명령을 실행합니다.

    $ oc adm must-gather --image=registry.redhat.io/odf4/ocs-must-gather-rhel8:v4.10 --dest-dir=<directory-name>
    <directory-name>

    데이터를 쓸 디렉터리의 이름입니다.

    중요

    연결이 끊긴 환경 배포의 경우 --image 매개변수의 이미지를 미러링된 must-gather 이미지로 교체합니다.

    $ oc adm must-gather --image=<local-registry>/odf4/ocs-must-gather-rhel8:v4.10 --dest-dir=<directory-name>
    <local-registry>
    연결이 끊긴 OpenShift Container Platform 클러스터에 사용 가능한 로컬 이미지 미러 레지스트리입니다.

    이렇게 하면 지정된 디렉터리에서 다음 정보가 수집됩니다.

    • 모든 Red Hat OpenShift Data Foundation 클러스터 관련 CR(사용자 정의 리소스) 및 네임스페이스.
    • 모든 Red Hat OpenShift Data Foundation 관련 포드의 포드 로그입니다.
    • Status, Cluster Health 등 일부 표준 Ceph 명령 출력.

명령 변형

  • 하나 이상의 마스터 노드가 Ready 상태가 아닌 경우 --node-name 을 사용하여 must-gather Pod를 안전하게 예약할 수 있도록 Ready 상태인 마스터 노드를 제공합니다.

    $ oc adm must-gather --image=registry.redhat.io/odf4/ocs-must-gather-rhel8:v4.10 --dest-dir=_<directory-name>_ --node-name=_<node-name>_
  • 특정 시간에서 정보를 수집하려면 다음을 수행합니다.

    • 수집된 로그에 대한 상대 기간(예: 5초 또는 2일)을 지정하려면 /usr/bin/gather since=<duration> 를 추가합니다.

      $ oc adm must-gather --image=registry.redhat.io/odf4/ocs-must-gather-rhel8:v4.10 --dest-dir=_<directory-name>_ /usr/bin/gather since=<duration>
    • 로그를 수집할 특정 시간을 지정하려면 /usr/bin/gather since-time=<rfc3339-timestamp> 를 추가합니다.

      $ oc adm must-gather --image=registry.redhat.io/odf4/ocs-must-gather-rhel8:v4.10 --dest-dir=_<directory-name>_ /usr/bin/gather since-time=<rfc3339-timestamp>

    이러한 명령에서 예제 값을 다음과 같이 바꿉니다.

    <node-name>
    하나 이상의 마스터 노드가 Ready 상태가 아닌 경우 이 매개변수를 사용하여 아직 Ready 상태인 마스터 노드의 이름을 제공합니다. 이렇게 하면 must-gather Pod가 준비되지 않은 마스터 노드에 예약되지 않도록 하여 스케줄링 오류가 발생하지 않습니다.
    <directory-name>
    must-gather 에서 수집한 정보를 저장하는 디렉터리입니다.
    <duration>
    정보를 상대 기간으로 수집하는 기간을 지정합니다(예: 5시간 부터 시작).
    <rfc3339-timestamp>
    에서 RFC 3339 타임 스탬프로 정보를 수집하는 기간을 지정합니다(예: 2020-11-10T04:00:00+00:00 ).

3장. 문제 해결에 필요한 일반적으로 로그

OpenShift Data Foundation 문제 해결에 일반적으로 사용되는 일부 로그는 해당 로그를 생성하는 명령과 함께 나열됩니다.

  • 특정 Pod에 대한 로그를 생성합니다.

     $ oc logs <pod-name> -n <namespace>
  • Ceph 또는 OpenShift Data Foundation 클러스터에 대한 로그 생성:

    $ oc logs rook-ceph-operator-<ID> -n openshift-storage
    중요

    현재 rook-ceph-operator 로그는 오류에 대한 정보를 제공하지 않으며 문제 해결에서 제한으로 작동합니다. rook-ceph-operator에 대한 디버그 로그 활성화 및 비활성화 를 참조하십시오.

  • cephfs 또는 rbd와 같은 플러그인 Pod의 로그를 생성하여 app-pod의 PVC 마운트에서 문제를 감지합니다.

    $ oc logs csi-cephfsplugin-<ID> -n openshift-storage -c csi-cephfsplugin
    $ oc logs csi-rbdplugin-<ID> -n openshift-storage -c csi-rbdplugin
    • CSI Pod의 모든 컨테이너에 대한 로그를 생성하려면 다음을 수행합니다.

      $ oc logs csi-cephfsplugin-<ID> -n openshift-storage --all-containers
      $ oc logs csi-rbdplugin-<ID> -n openshift-storage --all-containers
  • PVC가 BOUND 상태가 아닌 경우 문제를 감지하기 위해 cephfs 또는 rbd 프로비저너 Pod의 로그를 생성합니다.

    $ oc logs csi-cephfsplugin-provisioner-<ID> -n openshift-storage -c csi-cephfsplugin
    $ oc logs csi-rbdplugin-provisioner-<ID> -n openshift-storage -c csi-rbdplugin
    • CSI Pod의 모든 컨테이너에 대한 로그를 생성하려면 다음을 수행합니다.

      $ oc logs csi-cephfsplugin-provisioner-<ID> -n openshift-storage --all-containers
      $ oc logs csi-rbdplugin-provisioner-<ID> -n openshift-storage --all-containers
  • cluster-info 명령을 사용하여 OpenShift Data Foundation 로그 생성:

    $ oc cluster-info dump -n openshift-storage --output-directory=<directory-name>
  • Local Storage Operator를 사용하는 경우 cluster-info 명령을 사용하여 로그를 생성할 수 있습니다.

    $ oc cluster-info dump -n openshift-local-storage --output-directory=<directory-name>
  • OpenShift Data Foundation 운영자 로그 및 이벤트를 확인합니다.

    • Operator 로그를 확인하려면 다음을 수행합니다.

      # oc logs <ocs-operator> -n openshift-storage
      <ocs-operator>
      # oc get pods -n openshift-storage | grep -i "ocs-operator" | awk '{print $1}'
    • Operator 이벤트를 확인하려면 다음을 수행합니다.

      # oc get events --sort-by=metadata.creationTimestamp -n openshift-storage
  • OpenShift Data Foundation 운영자 버전 및 채널을 가져옵니다.

    # oc get csv -n openshift-storage

    출력 예 :

    NNAME                             DISPLAY                       VERSION   REPLACES   PHASE
    mcg-operator.v4.10.0              NooBaa Operator               4.10.0               Succeeded
    ocs-operator.v4.10.0              OpenShift Container Storage   4.10.0               Succeeded
    odf-csi-addons-operator.v4.10.0   CSI Addons                    4.10.0               Succeeded
    odf-operator.v4.10.0              OpenShift Data Foundation     4.10.0               Succeeded
    # oc get subs -n openshift-storage

    출력 예 :

    NAME                                                              PACKAGE                   SOURCE             CHANNEL
    mcg-operator-stable-4.10-redhat-operators-openshift-marketplace   mcg-operator              redhat-operators   stable-4.10
    ocs-operator-stable-4.10-redhat-operators-openshift-marketplace   ocs-operator              redhat-operators   stable-4.10
    odf-csi-addons-operator                                           odf-csi-addons-operator   redhat-operators   stable-4.10
    odf-operator                                                      odf-operator              redhat-operators   stable-4.10
  • installplan이 생성되었는지 확인합니다.

    # oc get installplan -n openshift-storage
  • OpenShift Data Foundation 업데이트 후 구성 요소의 이미지를 확인합니다.

    • 이미지가 실행 중인지 확인할 구성 요소의 Pod 노드를 확인합니다.

      # oc get pods -o wide | grep <component-name>

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

      # oc get pods -o wide | grep rook-ceph-operator

      출력 예:

      rook-ceph-operator-566cc677fd-bjqnb 1/1 Running 20 4h6m 10.128.2.5 rook-ceph-operator-566cc677fd-bjqnb 1/1 Running 20 4h6m 10.128.2.5 dell-r440-12.gsslab.pnq2.redhat.com <none> <none>
      
      <none> <none>

      Dell-r440-12.gsslab.pnq2.redhat.comnode-name 입니다.

    • 이미지 ID를 확인합니다.

      # oc debug node/<node name>

      <node-name>

      는 이미지가 실행 중인지 확인할 구성 요소의 Pod입니다.

      # chroot /host
      # crictl images | grep <component>

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

      # crictl images | grep rook-ceph

      IMAGEID 를 기록해 두고 Rook Ceph Operator 페이지의 다이제스트 ID에 매핑합니다.

추가 리소스

4장. OpenShift Data Foundation 사후 배포에 대한 클러스터 전체 기본 노드 선택기 덮어쓰기

OpenShift Data Foundation에 클러스터 수준 기본 노드 선택기를 사용하는 경우 CSI 데몬 세트에서 생성한 Pod는 선택기와 일치하는 노드에서만 시작할 수 있습니다. 선택기와 일치하지 않는 노드에서 OpenShift Data Foundation을 사용하려면 명령줄 인터페이스에서 다음 단계를 수행하여 클러스터 전체 기본 노드 선택기 를 재정의합니다.

절차

  1. openshift-storage 네임스페이스에 빈 노드 선택기를 지정합니다.

    $ oc annotate namespace openshift-storage openshift.io/node-selector=
  2. DaemonSet에서 생성한 원래 포드를 삭제합니다.

    oc delete pod -l app=csi-cephfsplugin -n openshift-storage
    oc delete pod -l app=csi-rbdplugin -n openshift-storage

5장. 암호화 토큰이 삭제되거나 만료됨

키 관리 시스템의 암호화 토큰이 삭제되거나 만료되면 토큰을 업데이트하려면 다음 절차를 사용하십시오.

사전 요구 사항

  • 삭제되거나 만료된 토큰과 동일한 정책이 있는 새 토큰이 있는지 확인합니다.

절차

  1. OpenShift Container Platform 웹 콘솔에 로그인합니다.
  2. 워크로드 → 시크릿 을 클릭합니다.
  3. 클러스터 전체 암호화에 사용되는 ocs-kms-token 을 업데이트하려면 다음을 수행합니다.

    1. 프로젝트를 openshift-storage 로 설정합니다.
    2. ocs-kms-tokenActionsEdit Secret 을 클릭합니다.
    3. Value 필드에 암호화 토큰 파일을 드래그 앤 드롭하거나 업로드합니다. 토큰은 복사 및 붙여넣기할 수 있는 파일 또는 텍스트일 수 있습니다.
    4. 저장을 클릭합니다.
  4. 암호화된 영구 볼륨으로 지정된 프로젝트 또는 네임스페이스에 대해 ceph-csi-kms-token 을 업데이트하려면 다음을 수행합니다.

    1. 필수 프로젝트를 선택합니다.
    2. ceph-csi-kms-tokenActionsEdit Secret 을 클릭합니다.
    3. Value 필드에 암호화 토큰 파일을 드래그 앤 드롭하거나 업로드합니다. 토큰은 복사 및 붙여넣기할 수 있는 파일 또는 텍스트일 수 있습니다.
    4. 저장을 클릭합니다.

      참고

      토큰은 ceph-csi-kms-token 을 사용하는 모든 암호화된 PVC가 삭제된 후에만 삭제할 수 있습니다.

6장. OpenShift Data Foundation에서 경고 및 오류 문제 해결

6.1. 경고 및 오류 해결

Red Hat OpenShift Data Foundation은 다양한 일반적인 오류 시나리오를 감지하고 자동으로 해결할 수 있습니다. 그러나 일부 문제에는 관리자의 개입이 필요합니다.

현재 실행 중인 오류를 확인하려면 다음 위치 중 하나를 확인하십시오.

  • 관찰경고 → 실행 옵션
  • 개요클러스터
  • 팝업 개요 블록 및 파일 탭의 스토리지 기반 → 스토리지 시스템 링크
  • 팝업 개요 오브젝트 탭의 스토리지 기반 → 스토리지 시스템 링크

표시된 오류를 복사하고 다음 섹션에서 검색하여 심각도 및 해결 방법을 확인합니다.

이름: CephMonVersionMismatch

메시지: 여러 버전의 스토리지 서비스가 실행되고 있습니다.

설명: 실행 중인 Ceph Mon 구성 요소의 {{ $value }} 다른 버전이 있습니다.

심각도: 경고

해결 방법 : 수정

절차: 사용자 인터페이스를 검사하고 로그한 다음 업데이트가 진행 중인지 확인합니다.

  • 업데이트가 진행 중인 경우 이 경고는 일시적입니다.
  • 업데이트가 진행되지 않은 경우 업그레이드 프로세스를 다시 시작합니다.

이름: CephOSDVersionMismatch

메시지: 여러 버전의 스토리지 서비스가 실행되고 있습니다.

설명: Ceph OSD 구성 요소의 {{ $value }} 다른 버전이 실행됩니다.

심각도: 경고

해결 방법 : 수정

절차: 사용자 인터페이스를 검사하고 로그한 다음 업데이트가 진행 중인지 확인합니다.

  • 업데이트가 진행 중인 경우 이 경고는 일시적입니다.
  • 업데이트가 진행되지 않은 경우 업그레이드 프로세스를 다시 시작합니다.

이름: CephClusterCriticallyFull

메시지: 스토리지 클러스터는 매우 꽉 우며 즉시 확장이 필요합니다.

설명: 스토리지 클러스터 사용률이 85%를 넘었습니다.

심각도: Crtical

해결 방법 : 수정

절차: 불필요한 데이터를 제거하거나 클러스터를 확장합니다.

이름: CephClusterNearFull

수정됨: 스토리지 클러스터가 가득 찼습니다. 확장이 필요합니다.

설명: 스토리지 클러스터 사용률이 75%를 넘었습니다.

심각도: 경고

해결 방법 : 수정

절차: 불필요한 데이터를 제거하거나 클러스터를 확장합니다.

이름: NooBaaBucketErrorState

메시지: NooBaa 버킷이 오류 상태입니다

설명: NooBaa 버킷 {{ $labels.bucket_name }}이 6m 이상 동안 오류 상태에 있습니다.

심각도: 경고

해결 방법 : 해결방법

절차: NooBaa 버킷 오류 상태 해결

이름: NooBaaNamespaceResourceErrorState

메시지: NooBaa 네임 스페이스 리소스가 오류 상태입니다

설명: NooBaa 네임 스페이스 리소스 {{ $labels.namespace_resource_name }}이 5m 이상 오류 상태에 있습니다.

심각도: 경고

해결 방법 : 수정

절차: NooBaa 버킷 오류 상태 해결

이름: NooBaaNamespaceBucketErrorState

메시지: NooBaa 네임 스페이스 버킷이 오류 상태입니다

설명: NooBaa 네임 스페이스 버킷 {{ $labels.bucket_name }}이 5m 이상 동안 오류 상태에 있습니다.

심각도: 경고

해결 방법 : 수정

절차: NooBaa 버킷 오류 상태 해결

이름: NooBaaBucketExceedingQuotaState

메시지: 할당량을 무시하고 있는 NooBaa 버킷

설명: NooBaa 버킷 {{ $labels.bucket_name }}이 할당량을 초과합니다. {{ printf "%0.0f" $ value }}% used 메시지: 할당량을 무시하고 있는 NooBaa 버킷

심각도: 경고

해결 방법 : 수정

절차: NooBaa 버킷 초과 할당량 해결

이름: NooBaaBucketLowCapacityState

메시지: NooBaa 버킷이 낮은 용량 상태입니다.

설명: NooBaa 버킷 {{ $labels.bucket_name }}은 {{ printf "%0.0f" $value }}%를 사용하고 있습니다.

심각도: 경고

해결 방법 : 수정

절차: NooBaa 버킷 용량 또는 할당량 확인

이름: NooBaaBucketNoCapacityState

메시지: NooBaa 버킷이 용량 상태 없음

설명: NooBaa 버킷 {{ $labels.bucket_name }}이 모든 용량을 사용하고 있습니다

심각도: 경고

해결 방법 : 수정

절차: NooBaa 버킷 용량 또는 할당량 확인

이름: NooBaaBucketReachingQuotaState

메시지: 쿼터 상태에 있는 NooBaa 버킷

설명: NooBaa 버킷 {{ $labels.bucket_name }}은 {{ printf "%0.0f" $value }}%를 사용 중입니다.

심각도: 경고

해결 방법 : 수정

절차: NooBaa 버킷 용량 또는 할당량 확인

이름: NooBaaResourceErrorState

메시지: NooBaa 리소스가 오류 상태입니다

설명: NooBaa 리소스 {{ $labels.resource_name }}이 6m 이상 오류 상태에 있습니다.

심각도: 경고

해결 방법 : 해결방법

절차: NooBaa 버킷 오류 상태 해결

이름: NooBaaSystemCapacityWarning100

메시지: 용량에 대한 NooBaa 시스템

설명: NooBaa 시스템은 용량에 접근했으며 사용량은 100%입니다.

심각도: 경고

해결 방법 : 수정

절차: NooBaa 버킷 용량 또는 할당량 확인

이름: NooBaaSystemCapacityWarning85

메시지: NooBaa 시스템이 용량에 대한 접근

설명: NooBaa 시스템은 용량에 접근하고 있으며 사용량은 85% 이상입니다.

심각도: 경고

해결 방법 : 수정

절차: NooBaa 버킷 용량 또는 할당량 확인

이름: NooBaaSystemCapacityWarning95

메시지: NooBaa 시스템이 용량에 대한 접근

설명: NooBaa 시스템은 용량에 접근하고 있으며 사용량은 95% 이상입니다.

심각도: 경고

해결 방법 : 수정

절차: NooBaa 버킷 용량 또는 할당량 확인

이름: CephMdsMissingReplicas

메시지: 스토리지 메타데이터 서비스를 위한 복제본이 충분하지 않습니다.

설명: '스토리지 메타 데이터 서비스의 최소 필수 복제본을 사용할 수 없습니다.

스토리지 클러스터 작동에 영향을 미칠 수 있습니다.

심각도: 경고

해결 방법 : Red Hat 지원 문의

절차:

  1. 경고 및 운영자 상태를 확인합니다.
  2. 문제를 식별할 수 없는 경우 Red Hat 지원팀에 문의하십시오.

이름: CephMgrIsAbsent

메시지: 스토리지 지표 수집기 서비스를 더 이상 사용할 수 없습니다.

설명: Ceph Manager가 Prometheus 대상 검색에서 사라졌습니다.

심각도: 심각

해결 방법 : Red Hat 지원 문의

절차:

  1. 사용자 인터페이스를 검사하고 로그한 다음 업데이트가 진행 중인지 확인합니다.

    • 업데이트가 진행 중인 경우 이 경고는 일시적입니다.
    • 업데이트가 진행되지 않은 경우 업그레이드 프로세스를 다시 시작합니다.
  2. 업그레이드가 완료되면 경고 및 운영자 상태를 확인합니다.
  3. 문제가 계속되거나 식별되지 않는 경우 Red Hat 지원에 문의하십시오.

이름: CephNodeDown

메시지: 스토리지 노드 {{ $labels.node }}이 종료되었습니다

설명: 스토리지 노드 {{ $labels.node }}이 중단되었습니다. 노드를 즉시 확인하십시오.

심각도: 심각

해결 방법 : Red Hat 지원 문의

절차:

  1. 어떤 노드가 기능과 그 원인을 중지했는지 확인합니다.
  2. 노드를 복구하려면 적절한 작업을 수행합니다. 노드를 복구할 수 없는 경우 다음을 수행합니다.

이름: CephClusterErrorState

메시지: 스토리지 클러스터가 오류 상태입니다

설명: 스토리지 클러스터가 10m 이상 오류 상태입니다.

심각도: 심각

해결 방법 : Red Hat 지원 문의

절차:

  1. 경고 및 운영자 상태를 확인합니다.
  2. 문제를 식별할 수 없는 경우 must-gather를 사용하여 로그 파일과 진단 정보를 다운로드합니다.
  3. must-gather 출력의 첨부 파일을 사용하여 Red Hat 지원팀으로 지원 티켓을 엽니다.

이름: CephClusterWarningState

메시지: 스토리지 클러스터의 성능이 저하됨

설명: 스토리지 클러스터가 10m 이상 경고 상태입니다.

심각도: 경고

해결 방법 : Red Hat 지원 문의

절차:

  1. 경고 및 운영자 상태를 확인합니다.
  2. 문제를 식별할 수 없는 경우 must-gather를 사용하여 로그 파일과 진단 정보를 다운로드합니다.
  3. must-gather 출력의 첨부 파일을 사용하여 Red Hat 지원팀으로 지원 티켓을 엽니다.

이름: CephDataRecoveryTakingTooLong

메시지: 데이터 복구 속도가 느립니다.

설명: 데이터 복구가 너무 오래 활성 상태였습니다.

심각도: 경고

해결 방법 : Red Hat 지원 문의

이름: CephOSDDiskNotResponding

메시지: 디스크에 응답하지 않음

설명: 호스트 {{ $labels.host }}에서 디스크 장치 {{ $labels.device }}이 응답하지 않습니다.

심각도: 심각

해결 방법 : Red Hat 지원 문의

이름: CephOSDDiskUnavailable

메시지: 디스크에 액세스할 수 없음

설명: 호스트 {{ $labels.host }}에서 디스크 장치 {{ $labels.device }}에 액세스할 수 없습니다.

심각도: 심각

해결 방법 : Red Hat 지원 문의

이름: CephPGRepairTakingTooLong

메시지: 자체 복구 문제 감지

설명: 자체 복구 작업은 너무 오래 걸립니다.

심각도: 경고

해결 방법 : Red Hat 지원 문의

이름: CephMonHighNumberOfLeaderChanges

메시지: 스토리지 클러스터는 최근 여러 리더가 변경되었습니다.

설명: 'Ceph Monitor "{{ $labels.job }}": instance {{ $labels.instance }}은 최근 분당 {{ $value printf "%.2f" }} 리더가 변경되었습니다.'

심각도: 경고

해결 방법 : Red Hat 지원 문의

이름: CephMonQuorumAtRisk

메시지: 위험한 스토리지 쿼럼

설명: 스토리지 클러스터 쿼럼이 적습니다.

심각도: 심각

해결 방법 : Red Hat 지원 문의

이름: ClusterObjectStoreState

메시지: 클러스터 오브젝트 저장소가 비정상 상태입니다. Ceph 클러스터 상태 를 확인하십시오.

설명: 클러스터 오브젝트 저장소는 15초 이상 비정상 상태입니다. Ceph 클러스터 상태 를 확인하십시오.

심각도: 심각

해결 방법 : Red Hat 지원 문의

절차:

이름: CephOSDFlapping

메시지: 스토리지 데몬 osd.x가 지난 5분 동안 5번 다시 시작되었습니다. pod 이벤트 또는 Ceph 상태를 확인하여 cause 를 확인하십시오.

설명: 스토리지 OSD는 5분 내에 5회 이상 다시 시작합니다.

심각도: 심각

해결 방법 : Red Hat 지원 문의

이름: OdfPoolMirroringImageHealth

메시지: 풀 <pool-name>에서 미러링 이미지 (PV)는 1m 이상 Warning 상태에 있습니다. 미러링이 예상대로 작동하지 않을 수 있습니다.

설명: 하나 또는 몇몇 애플리케이션에 대해 재해 복구가 실패합니다.

심각도: 경고

해결 방법 : Red Hat 지원 문의

이름: OdfMirrorDaemonStatus

메시지: 미러 데몬이 비정상입니다.

설명: 전체 클러스터에 대해 재해 복구가 실패합니다. 미러 데몬은 1분 이상 비정상 상태입니다. 이 클러스터의 미러링이 예상대로 작동하지 않습니다.

심각도: 심각

해결 방법 : Red Hat 지원 문의

6.2. 클러스터 상태 문제 해결

Red Hat Ceph Storage 클러스터가 OpenShift Data Foundation 사용자 인터페이스에 표시되도록 할 수 있는 일련의 가능한 상태 메시지가 있습니다. 이러한 항목은 고유 식별자가 있는 상태 점검으로 정의됩니다. 식별자는 도구가 상태 점검을 이해할 수 있도록 하고 의미를 반영하는 방식으로 표시하는 데 사용되는 tere pseudo-readable 문자열입니다. 자세한 내용 및 문제 해결을 위해 아래의 상태 코드를 클릭하십시오.

상태 코드설명

MON_DISK_LOW

디스크 공간에는 하나 이상의 Ceph 모니터가 적습니다.

6.2.1. MON_DISK_LOW

이 경고는 모니터 데이터베이스를 백분율로 저장하는 파일 시스템의 사용 가능한 공간이 mon_data_avail_warn 아래에 삭제되는 경우 트리거됩니다(기본값: 15%). 이는 시스템의 다른 프로세스나 사용자가 모니터에서 사용하는 것과 동일한 파일 시스템을 채우고 있음을 나타낼 수 있습니다. 모니터의 데이터베이스가 커졌음을 나타낼 수도 있습니다.

참고

파일 시스템의 경로는 mons의 배포에 따라 다릅니다. mon이 storagecluster.yaml 에 배포된 위치를 찾을 수 있습니다.

경로 예:

  • PVC 경로를 통해 Mon deploy: /var/lib/ceph/mon
  • hostpath를 통해 Mon deployed: /var/lib/rook/mon

공간을 지우려면 파일 시스템에서 사용량이 많은 파일을 확인하고 삭제할 파일을 선택합니다. 파일을 보려면 다음을 실행합니다.

# du -a <path-in-the-mon-node> |sort -n -r |head -n10

<path-in-the-mon-node> 를 mons가 배포된 파일 시스템의 경로로 바꿉니다.

6.3. NooBaa 버킷 오류 상태 해결

절차

  1. OpenShift 웹 콘솔에서 스토리지 → 데이터 기반 을 클릭합니다.
  2. Overview(개요 ) 탭의 Status (상태) 카드에서 Storage System (스토리지 시스템)을 클릭한 다음 표시되는 팝업에서 스토리지 시스템 링크를 클릭합니다.
  3. Object(오브젝트 ) 탭을 클릭합니다.
  4. 세부 정보 카드에서 시스템 이름 필드에 있는 링크를 클릭합니다.
  5. 왼쪽 창에서 버킷 옵션을 클릭하고 오류 상태에서 버킷을 검색합니다. 버킷의 오류 상태가 네임 스페이스 버킷인 경우 네임 스페이스 버킷 창을 클릭해야합니다.
  6. 버킷 이름을 클릭합니다. 버킷에 오류가 표시됩니다.
  7. 버킷의 특정 오류에 따라 다음 중 하나 또는 둘 다를 수행합니다.

    1. 공간 관련 오류의 경우:

      1. 왼쪽 창에서 Resources (리소스) 옵션을 클릭합니다.
      2. 오류 상태에서 리소스를 클릭합니다.
      3. 에이전트를 추가하여 리소스를 확장합니다.
    2. 리소스 상태 오류의 경우 다음을 수행합니다.

      1. 왼쪽 창에서 Resources (리소스) 옵션을 클릭합니다.
      2. 오류 상태에서 리소스를 클릭합니다.
      3. 연결 오류는 백업 서비스를 사용할 수 없으며 복원해야 함을 의미합니다.
      4. 액세스/권한 오류의 경우 연결의 액세스 키시크릿 키를 업데이트합니다.

6.4. NooBaa 버킷 초과 할당량 해결

NooBaa 버킷을 해결하려면 할당량을 초과하는 경우 다음 중 하나를 수행하십시오.

  • 버킷의 일부 데이터를 정리합니다.
  • 다음 단계를 수행하여 버킷 할당량을 늘립니다.

    1. OpenShift 웹 콘솔에서 스토리지 → 데이터 기반 을 클릭합니다.
    2. Overview(개요 ) 탭의 Status (상태) 카드에서 Storage System (스토리지 시스템)을 클릭한 다음 표시되는 팝업에서 스토리지 시스템 링크를 클릭합니다.
    3. Object(오브젝트 ) 탭을 클릭합니다.
    4. 세부 정보 카드에서 시스템 이름 필드에 있는 링크를 클릭합니다.
    5. 왼쪽 창에서 버킷 옵션을 클릭하고 오류 상태에서 버킷을 검색합니다.
    6. 버킷 이름을 클릭합니다. 버킷에 오류가 표시됩니다.
    7. 버킷 정책할당량 편집을 클릭하고 할당량을 늘립니다.

6.5. NooBaa 버킷 용량 또는 할당량 확인

절차

  1. OpenShift 웹 콘솔에서 스토리지 → 데이터 기반 을 클릭합니다.
  2. Overview(개요 ) 탭의 Status (상태) 카드에서 Storage System (스토리지 시스템)을 클릭한 다음 표시되는 팝업에서 스토리지 시스템 링크를 클릭합니다.
  3. Object(오브젝트 ) 탭을 클릭합니다.
  4. 세부 정보 카드에서 시스템 이름 필드에 있는 링크를 클릭합니다.
  5. 왼쪽 창에서 Resources 옵션을 클릭하고 PV 풀 리소스를 검색합니다.
  6. 용량 상태가 낮은 PV 풀 리소스의 리소스 이름을 클릭합니다.
  7. 풀 구성을 편집하고 에이전트 수를 늘립니다.

6.6. Pod 복구

일부 문제로 인해 첫 번째 노드( NODE1허용)가 NotReady 상태로 전환되면 RWO(ReadWriteOnce) 액세스 모드에서 PVC를 사용하는 호스트 포드는 두 번째 노드( NODE2확인)로 이동하려고 하지만 다중 연결 오류로 인해 중단됩니다. 이러한 경우 다음 단계를 사용하여 MON, OSD 및 애플리케이션 포드를 복구할 수 있습니다.

절차

  1. NODE1 의 전원을 끄고(AWS 또는 vSphere 측) NODE1 이 완전히 꺼졌는지 확인합니다.
  2. 다음 명령을 사용하여 NODE1 에서 Pod를 강제 삭제합니다.

    $ oc delete pod <pod-name> --grace-period=0 --force

6.7. EBS 볼륨 분리에서 복구

OSD 디스크가 작업자 Amazon EC2 인스턴스에서 분리되는 OSD 또는 MON EBS(Elastic Block Storage) 볼륨이 작업자 Amazon EC2 인스턴스에서 분리되면 볼륨이 1~2분 이내에 자동으로 다시 연결됩니다. 그러나 OSD 포드는 a CrashLoopBackOff 상태로 전환됩니다. 포드를 복구하고 Running 상태로 되돌리려면 EC2 인스턴스를 다시 시작해야 합니다.

6.8. rook-ceph-operator의 디버그 로그 활성화 및 비활성화

rook-ceph-operator의 디버그 로그를 활성화하여 문제 해결에 도움이 되는 실패에 대한 정보를 가져옵니다.

절차

디버그 로그 활성화
  1. rook-ceph-operator의 구성 맵을 편집합니다.

    $ oc edit configmap rook-ceph-operator-config
  2. ROOK_LOG_LEVEL을 추가합니다. rook-ceph-operator-config yaml 파일의 DEBUG 매개변수로 rook-ceph-operator에 대한 디버그 로그를 활성화합니다.

    …
    data:
      # The logging level for the operator: INFO | DEBUG
      ROOK_LOG_LEVEL: DEBUG

    이제 rook-ceph-operator 로그가 디버그 정보로 구성됩니다.

디버그 로그 비활성화
  1. rook-ceph-operator의 구성 맵을 편집합니다.

    $ oc edit configmap rook-ceph-operator-config
  2. ROOK_LOG_LEVEL을 추가합니다. rook-ceph-operator의 디버그 로그를 비활성화하기 위한 rook-ceph-operator-config yaml 파일의 INFO 매개변수입니다.

    …
    data:
      # The logging level for the operator: INFO | DEBUG
      ROOK_LOG_LEVEL: INFO

7장. Local Storage Operator 배포 확인

Local Storage Operator가 있는 Red Hat OpenShift Data Foundation 클러스터는 로컬 스토리지 장치를 사용하여 배포됩니다. 로컬 스토리지 장치를 사용하여 OpenShift Data Foundation이 있는 기존 클러스터가 배포되었는지 확인하려면 다음 절차를 따르십시오.

사전 요구 사항

  • OpenShift Data Foundation은 openshift-storage 네임스페이스에 설치 및 실행됩니다.

절차

OpenShift Data Foundation 클러스터의 PVC(영구 볼륨 클레임)와 연결된 스토리지 클래스를 확인하여 로컬 스토리지 장치를 사용하여 클러스터가 배포되었는지 확인할 수 있습니다.

  1. 다음 명령을 사용하여 OpenShift Data Foundation 클러스터의 PVC와 연결된 스토리지 클래스를 확인합니다.

    $ oc get pvc -n openshift-storage
  2. 출력을 확인합니다. Local Storage Operator가 있는 클러스터의 경우 ocs-deviceset 과 연결된 PVC는 스토리지 클래스 localblock 을 사용합니다. 출력은 다음과 유사합니다.

    NAME                      STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS                  AGE
    db-noobaa-db-0            Bound    pvc-d96c747b-2ab5-47e2-b07e-1079623748d8   50Gi       RWO            ocs-storagecluster-ceph-rbd   114s
    ocs-deviceset-0-0-lzfrd   Bound    local-pv-7e70c77c                          1769Gi     RWO            localblock                    2m10s
    ocs-deviceset-1-0-7rggl   Bound    local-pv-b19b3d48                          1769Gi     RWO            localblock                    2m10s
    ocs-deviceset-2-0-znhk8   Bound    local-pv-e9f22cdc                          1769Gi     RWO            localblock                    2m10s

8장. 설치 제거 중 나머지 리소스 문제 해결 및 삭제

필요한 모든 정리 작업을 수행했지만 운영자가 관리하는 일부 사용자 지정 리소스가 완료될 종료자에서 대기 중인 "Terminating" 상태로 남아 있는 경우가 있습니다. 이러한 경우 이러한 리소스를 강제로 제거해야 합니다. 이렇게 하지 않으면 제거 단계를 모두 수행한 후에도 리소스가 "Terminating" 상태로 유지됩니다.

  1. 삭제 시 openshift-storage 네임스페이스가 Terminating 상태인지 확인합니다.

    $ oc get project -n <namespace>

    출력:

    NAME                DISPLAY NAME   STATUS
    openshift-storage                  Terminating
  2. 명령 출력의 STATUS 섹션에서 NamespaceFinalizersRemaining 및 NamespaceContentRemaining 메시지를 확인하고 나열된 각 리소스에 대해 다음 단계를 수행합니다.

    $ oc get project openshift-storage -o yaml

    출력 예 :

    status:
      conditions:
      - lastTransitionTime: "2020-07-26T12:32:56Z"
        message: All resources successfully discovered
        reason: ResourcesDiscovered
        status: "False"
        type: NamespaceDeletionDiscoveryFailure
      - lastTransitionTime: "2020-07-26T12:32:56Z"
        message: All legacy kube types successfully parsed
        reason: ParsedGroupVersions
        status: "False"
        type: NamespaceDeletionGroupVersionParsingFailure
      - lastTransitionTime: "2020-07-26T12:32:56Z"
        message: All content successfully deleted, may be waiting on finalization
        reason: ContentDeleted
        status: "False"
        type: NamespaceDeletionContentFailure
      - lastTransitionTime: "2020-07-26T12:32:56Z"
        message: 'Some resources are remaining: cephobjectstoreusers.ceph.rook.io has
          1 resource instances'
        reason: SomeResourcesRemain
        status: "True"
        type: NamespaceContentRemaining
      - lastTransitionTime: "2020-07-26T12:32:56Z"
        message: 'Some content in the namespace has finalizers remaining: cephobjectstoreuser.ceph.rook.io
          in 1 resource instances'
        reason: SomeFinalizersRemain
        status: "True"
        type: NamespaceFinalizersRemaining
  3. 이전 단계에 나열된 나머지 리소스를 모두 삭제합니다.

    각 리소스를 삭제할 경우 다음을 수행합니다.

    1. 제거해야 하는 리소스의 개체 유형을 가져옵니다. 위의 출력에서 메시지를 확인합니다.

      예:

      메세지: 네임스페이스의 일부 콘텐츠에는 종료자가 남아 있습니다. cephobjectstoreuser.ceph.rook.io

      여기에서 cephobjectstoreuser.ceph.rook.io 는 오브젝트 종류입니다.

    2. 오브젝트 유형에 해당하는 오브젝트 이름을 가져옵니다.

      $ oc get  <Object-kind> -n  <project-name>

      예:

      $ oc get cephobjectstoreusers.ceph.rook.io -n openshift-storage

      출력 예:

      NAME                           AGE
      noobaa-ceph-objectstore-user   26h
    3. 리소스를 패치합니다.

      $ oc patch -n <project-name> <object-kind>/<object-name> --type=merge -p '{"metadata": {"finalizers":null}}'

      예제:

      $ oc patch -n openshift-storage cephobjectstoreusers.ceph.rook.io/noobaa-ceph-objectstore-user \
      --type=merge -p '{"metadata": {"finalizers":null}}'

      출력:

      cephobjectstoreuser.ceph.rook.io/noobaa-ceph-objectstore-user patched
  4. openshift-storage 프로젝트가 삭제되었는지 확인합니다.

    $ oc get project openshift-storage

    출력:

    Error from server (NotFound): namespaces "openshift-storage" not found

    문제가 해결되지 않는 경우 Red Hat 지원팀에 문의하십시오.

9장. 외부 모드에서 CephFS PVC 생성 문제 해결

Red Hat Ceph Storage 클러스터를 4.1.1 미만의 버전에서 최신 릴리스로 업데이트했으며 새로 배포된 클러스터가 아닌 경우, 외부 모드에서 CephFS PVC를 생성할 수 있도록 Red Hat Ceph Storage 클러스터에서 CephFS 풀의 애플리케이션 유형을 수동으로 설정해야 합니다.

  1. CephFS pvc가 Pending 상태인지 확인합니다.

    # oc get pvc -n <namespace>

    출력 예 :

    NAME                      STATUS    VOLUME
    CAPACITY  ACCESS MODES    STORAGECLASS                        AGE
    ngx-fs-pxknkcix20-pod     Pending
                              ocs-external-storagecluster-cephfs  28h
    [...]
  2. describe 출력을 확인하여 각 pvc의 이벤트를 확인합니다.

    예상 오류 메시지 cephfs_metadata/csi.volumes.default/csi.volume.pvc-xxxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxxxxx: (1) 작업이 허용되지 않음)

    # oc describe pvc ngx-fs-pxknkcix20-pod -n nginx-file

    출력 예:

    Name:          ngx-fs-pxknkcix20-pod
    Namespace:     nginx-file
    StorageClass:  ocs-external-storagecluster-cephfs
    Status:        Pending
    Volume:
    Labels:        <none>
    Annotations:   volume.beta.kubernetes.io/storage-provisioner: openshift-storage.cephfs.csi.ceph.com
    Finalizers:    [kubernetes.io/pvc-protection]
    Capacity:
    Access Modes:
    VolumeMode:    Filesystem
    Mounted By:    ngx-fs-oyoe047v2bn2ka42jfgg-pod-hqhzf
    Events:
     Type     Reason              Age                   From                                                                                                                      Message
     ----     ------              ----                  ----                                                                                                                      -------
     Warning  ProvisioningFailed  107m (x245 over 22h)  openshift-storage.cephfs.csi.ceph.com_csi-cephfsplugin-provisioner-5f8b66cc96-hvcqp_6b7044af-c904-4795-9ce5-bf0cf63cc4a4
     (combined from similar events): failed to provision volume with StorageClass "ocs-external-storagecluster-cephfs": rpc error: code = Internal desc = error (an error (exit status 1) occurred while
     running rados args: [-m 192.168.13.212:6789,192.168.13.211:6789,192.168.13.213:6789 --id csi-cephfs-provisioner --keyfile=stripped -c /etc/ceph/ceph.conf -p cephfs_metadata getomapval
     csi.volumes.default csi.volume.pvc-1ac0c6e6-9428-445d-bbd6-1284d54ddb47 /tmp/omap-get-186436239 --namespace=csi]) occurred, command output streams is ( error getting omap value
     cephfs_metadata/csi.volumes.default/csi.volume.pvc-1ac0c6e6-9428-445d-bbd6-1284d54ddb47: (1) Operation not permitted)
  3. <cephfs 메타데이터 풀 이름> (여기에서 cephfs_metadata ) 및 <cephfs 데이터 풀 name> (이전 cephfs_data)에 대한 설정을 확인합니다. 명령을 실행하려면 Red Hat Ceph Storage 클라이언트 노드에 jq 가 사전 설치되어 있어야 합니다.

    # ceph osd pool ls detail --format=json | jq '.[] | select(.pool_name| startswith("cephfs")) | .pool_name, .application_metadata' "cephfs_data"
    {
      "cephfs": {}
    }
    "cephfs_metadata"
    {
       "cephfs": {}
    }
  4. CephFS 풀의 애플리케이션 유형을 설정합니다.

    • Red Hat Ceph Storage 클라이언트 노드에서 다음 명령을 실행합니다.

      # ceph osd pool application set <cephfs metadata pool name> cephfs metadata cephfs
      # ceph osd pool application set <cephfs data pool name> cephfs data cephfs
  5. 설정이 적용되는지 확인합니다.

     # ceph osd pool ls detail --format=json | jq '.[] | select(.pool_name| startswith("cephfs")) | .pool_name, .application_metadata' "cephfs_data"
      {
        "cephfs": {
          "data": "cephfs"
       }
      }
      "cephfs_metadata"
      {
        "cephfs": {
          "metadata": "cephfs"
        }
      }
  6. CephFS PVC 상태를 다시 확인합니다. 이제 PVC가 Bound 상태여야 합니다.

    # oc get pvc -n <namespace>

    출력 예 :

    NAME                      STATUS    VOLUME
    CAPACITY  ACCESS MODES    STORAGECLASS                        AGE
    ngx-fs-pxknkcix20-pod     Bound     pvc-1ac0c6e6-9428-445d-bbd6-1284d54ddb47
    1Mi       RWO             ocs-external-storagecluster-cephfs  29h
    [...]

10장. OpenShift Data Foundation에서 모니터 Pod 복원

세 개가 모두 중단되고 OpenShift Data Foundation이 모니터 포드를 자동으로 복구할 수 없는 경우 모니터 포드를 복원합니다.

절차

  1. rook-ceph-operatorocs Operator 배포를 축소합니다.

    # oc scale deployment rook-ceph-operator --replicas=0 -n openshift-storage
    # oc scale deployment ocs-operator --replicas=0 -n openshift-storage
  2. openshift-storage 네임스페이스에 모든 배포의 백업을 생성합니다.

    # mkdir backup
    # cd backup
    # oc project openshift-storage
    # for d in $(oc get deployment|awk -F' ' '{print $1}'|grep -v NAME); do echo $d;oc get deployment $d -o yaml > oc_get_deployment.${d}.yaml; done
  3. OSD 배포를 패치하여 livenessProbe 매개 변수를 제거하고 sleep 으로 command 매개 변수를 사용하여 실행합니다.

    # for i in $(oc get deployment -l app=rook-ceph-osd -oname);do oc patch ${i} -n openshift-storage --type='json' -p '[{"op":"remove", "path":"/spec/template/spec/containers/0/livenessProbe"}]' ; oc patch ${i} -n openshift-storage -p '{"spec": {"template": {"spec": {"containers": [{"name": "osd", "command": ["sleep", "infinity"], "args": []}]}}}}' ; done
  4. 모든 OSD에서 monstore 클러스터 맵을 검색합니다.

    1. recover_mon.sh 스크립트를 생성합니다.

      #!/bin/bash
      ms=/tmp/monstore
      
      rm -rf $ms
      mkdir $ms
      
      for osd_pod in $(oc get po -l app=rook-ceph-osd -oname -n openshift-storage); do
      
        echo "Starting with pod: $osd_pod"
      
        podname=$(echo $osd_pod|sed 's/pod\///g')
        oc exec $osd_pod -- rm -rf $ms
        oc cp $ms $podname:$ms
      
        rm -rf $ms
        mkdir $ms
      
        echo "pod in loop: $osd_pod ; done deleting local dirs"
      
        oc exec $osd_pod -- ceph-objectstore-tool --type bluestore --data-path /var/lib/ceph/osd/ceph-$(oc get $osd_pod -ojsonpath='{ .metadata.labels.ceph_daemon_id }') --op update-mon-db --no-mon-config --mon-store-path $ms
        echo "Done with COT on pod: $osd_pod"
      
        oc cp $podname:$ms $ms
      
        echo "Finished pulling COT data from pod: $osd_pod"
      done
    2. recover_mon.sh 스크립트를 실행합니다.

      # chmod +x recover_mon.sh
      # ./recover_mon.sh
  5. MON 배포를 패치하고 command 매개 변수를 sleep 으로 사용하여 실행합니다.

    1. MON 배포를 편집합니다.

      # for i in $(oc get deployment -l app=rook-ceph-mon -oname);do oc patch ${i} -n openshift-storage -p '{"spec": {"template": {"spec": {"containers": [{"name": "mon", "command": ["sleep", "infinity"], "args": []}]}}}}'; done
    2. MON 배포를 패치하여 initialDelaySeconds 를 늘립니다.

      # oc get deployment rook-ceph-mon-a -o yaml | sed "s/initialDelaySeconds: 10/initialDelaySeconds: 2000/g" | oc replace -f -
      # oc get deployment rook-ceph-mon-b -o yaml | sed "s/initialDelaySeconds: 10/initialDelaySeconds: 2000/g" | oc replace -f -
      # oc get deployment rook-ceph-mon-c -o yaml | sed "s/initialDelaySeconds: 10/initialDelaySeconds: 2000/g" | oc replace -f -
  6. 이전에 검색한 monstoremon-a 포드에 복사합니다.

    # oc cp /tmp/monstore/ $(oc get po -l app=rook-ceph-mon,mon=a -oname |sed 's/pod\///g'):/tmp/
  7. MON 포드로 이동하여 검색된 monstore 의 소유권을 변경합니다.

    # oc rsh $(oc get po -l app=rook-ceph-mon,mon=a -oname)
    # chown -R ceph:ceph /tmp/monstore
  8. mon db 를 다시 빌드하기 전에 인증 키 템플릿 파일을 복사합니다.

    # oc rsh $(oc get po -l app=rook-ceph-mon,mon=a -oname)
    # cp /etc/ceph/keyring-store/keyring /tmp/keyring
    # cat /tmp/keyring
      [mon.]
        key = AQCleqldWqm5IhAAgZQbEzoShkZV42RiQVffnA==
        caps mon = "allow *"
      [client.admin]
        key = AQCmAKld8J05KxAArOWeRAw63gAwwZO5o75ZNQ==
        auid = 0
        caps mds = "allow *"
        caps mgr = "allow *"
        caps mon = "allow *"
        caps osd = "allow *”
  9. 해당 시크릿에서 다른 모든 Ceph 데몬(MGR, MDS, RGW, Crash, CSI 및 CSI 프로비저너)의 인증 키를 식별합니다.

    # oc get secret rook-ceph-mds-ocs-storagecluster-cephfilesystem-a-keyring -ojson  | jq .data.keyring | xargs echo | base64 -d
    
    [mds.ocs-storagecluster-cephfilesystem-a]
    key = AQB3r8VgAtr6OhAAVhhXpNKqRTuEVdRoxG4uRA==
    caps mon = "allow profile mds"
    caps osd = "allow *"
    caps mds = "allow"

    인증 키 파일의 예, /etc/ceph/ceph.client.admin.keyring:

    [mon.]
    	key = AQDxTF1hNgLTNxAAi51cCojs01b4I5E6v2H8Uw==
    	caps mon = "allow "
    [client.admin]
            key = AQDxTF1hpzguOxAA0sS8nN4udoO35OEbt3bqMQ==
            caps mds = "allow " caps mgr = "allow *" caps mon = "allow *" caps osd = "allow *" [mds.ocs-storagecluster-cephfilesystem-a] key = AQCKTV1horgjARAA8aF/BDh/4+eG4RCNBCl+aw== caps mds = "allow" caps mon = "allow profile mds" caps osd = "allow *" [mds.ocs-storagecluster-cephfilesystem-b] key = AQCKTV1hN4gKLBAA5emIVq3ncV7AMEM1c1RmGA== caps mds = "allow" caps mon = "allow profile mds" caps osd = "allow *" [client.rgw.ocs.storagecluster.cephobjectstore.a] key = AQCOkdBixmpiAxAA4X7zjn6SGTI9c1MBflszYA== caps mon = "allow rw" caps osd = "allow rwx" [mgr.a] key = AQBOTV1hGYOEORAA87471+eIZLZtptfkcHvTRg== caps mds = "allow *" caps mon = "allow profile mgr" caps osd = "allow *" [client.crash] key = AQBOTV1htO1aGRAAe2MPYcGdiAT+Oo4CNPSF1g== caps mgr = "allow rw" caps mon = "allow profile crash" [client.csi-cephfs-node] key = AQBOTV1hiAtuBBAAaPPBVgh1AqZJlDeHWdoFLw== caps mds = "allow rw" caps mgr = "allow rw" caps mon = "allow r" caps osd = "allow rw tag cephfs *=" [client.csi-cephfs-provisioner] key = AQBNTV1hHu6wMBAAzNXZv36aZJuE1iz7S7GfeQ== caps mgr = "allow rw" caps mon = "allow r" caps osd = "allow rw tag cephfs metadata="
    [client.csi-rbd-node]
    	key = AQBNTV1h+LnkIRAAWnpIN9bUAmSHOvJ0EJXHRw==
    	caps mgr = "allow rw"
    	caps mon = "profile rbd"
    	caps osd = "profile rbd"
    [client.csi-rbd-provisioner]
    	key = AQBNTV1hMNcsExAAvA3gHB2qaY33LOdWCvHG/A==
    	caps mgr = "allow rw"
    	caps mon = "profile rbd"
    	caps osd = "profile rbd"
    중요
    • client.csi 관련 인증 키의 경우 이전 인증 키 파일 출력을 참조하고 각 OpenShift Data Foundation 시크릿에서 키를 가져온 후 기본 대문자 를 추가합니다.
    • OSD 인증 키는 복구 후 자동으로 추가됩니다.
  10. mon-a pod로 이동하여 monstoremonmap 이 있는지 확인합니다.

    1. mon-a 포드로 이동합니다.

      # oc rsh $(oc get po -l app=rook-ceph-mon,mon=a -oname)
    2. monstore에 mon map 이 있는지 확인합니다.

      # ceph-monstore-tool /tmp/monstore get monmap -- --out /tmp/monmap
      # monmaptool /tmp/monmap --print
  11. 선택 사항: monmap 이 누락된 경우 새 monmap 을 만듭니다.

    # monmaptool --create --add <mon-a-id> <mon-a-ip> --add <mon-b-id> <mon-b-ip> --add <mon-c-id> <mon-c-ip> --enable-all-features --clobber /root/monmap --fsid <fsid>
    <mon-a-id>
    mon-a Pod의 ID입니다.
    <mon-a-ip>
    mon-a 포드의 IP 주소입니다.
    <mon-b-id>
    mon-b Pod의 ID입니다.
    <mon-b-ip>
    mon-b 포드의 IP 주소입니다.
    <mon-c-id>
    mon-c Pod의 ID입니다.
    <mon-c-ip>
    mon-c Pod의 IP 주소입니다.
    <fsid>
    는 파일 시스템 ID입니다.
  12. monmap 을 확인합니다.

    # monmaptool /root/monmap --print
  13. monmap 가져오기.

    중요

    이전에 생성된 인증 키 파일을 사용합니다.

    # ceph-monstore-tool /tmp/monstore rebuild -- --keyring /tmp/keyring --monmap /root/monmap
    # chown -R ceph:ceph /tmp/monstore
  14. 이전 store.db 파일의 백업을 만듭니다.

    # mv /var/lib/ceph/mon/ceph-a/store.db /var/lib/ceph/mon/ceph-a/store.db.corrupted
    # mv /var/lib/ceph/mon/ceph-b/store.db /var/lib/ceph/mon/ceph-b/store.db.corrupted
    # mv /var/lib/ceph/mon/ceph-c/store.db /var/lib/ceph/mon/ceph-c/store.db.corrupted
  15. 다시 빌드 저장소 store.db 파일을 monstore 디렉터리에 복사합니다.

    # mv /tmp/monstore/store.db /var/lib/ceph/mon/ceph-a/store.db
    # chown -R ceph:ceph /var/lib/ceph/mon/ceph-a/store.db
  16. monstore 디렉터리를 다시 빌드한 후 store.db 파일을 local에서 MON 포드의 나머지 부분에 복사합니다.

    # oc cp $(oc get po -l app=rook-ceph-mon,mon=a -oname | sed 's/pod\///g'):/var/lib/ceph/mon/ceph-a/store.db /tmp/store.db
    # oc cp /tmp/store.db $(oc get po -l app=rook-ceph-mon,mon=<id> -oname | sed 's/pod\///g'):/var/lib/ceph/mon/ceph-<id>
    <id>
    MON Pod의 ID입니다.
  17. 나머지 MON 포드로 이동하여 복사한 monstore 의 소유권을 변경합니다.

    # oc rsh $(oc get po -l app=rook-ceph-mon,mon=<id> -oname)
    # chown -R ceph:ceph /var/lib/ceph/mon/ceph-<id>/store.db
    <id>
    MON Pod의 ID입니다.
  18. 패치된 변경 사항을 되돌립니다.

    • MON 배포의 경우:

      # oc replace --force -f <mon-deployment.yaml>
      <mon-deployment.yaml>
      MON deployment yaml 파일입니다.
    • OSD 배포의 경우:

      # oc replace --force -f <osd-deployment.yaml>
      <osd-deployment.yaml>
      OSD 배포 yaml 파일입니다.
    • MGR 배포의 경우:

      # oc replace --force -f <mgr-deployment.yaml>
      <mgr-deployment.yaml>

      MGR 배포 yaml 파일입니다.

      중요

      MON, MGR 및 OSD 포드가 실행 중인지 확인합니다.

  19. rook-ceph-operatorocs-operator 배포를 확장합니다.

    # oc -n openshift-storage scale deployment ocs-operator --replicas=1

검증 단계

  1. Ceph 상태를 확인하여 CephFS가 실행 중인지 확인합니다.

    # ceph -s

    출력 예:

    cluster:
       id:     f111402f-84d1-4e06-9fdb-c27607676e55
       health: HEALTH_ERR
                1 filesystem is offline
                1 filesystem is online with fewer MDS than max_mds
                3 daemons have recently crashed
    
       services:
         mon: 3 daemons, quorum b,c,a (age 15m)
         mgr: a(active, since 14m)
         mds: ocs-storagecluster-cephfilesystem:0
         osd: 3 osds: 3 up (since 15m), 3 in (since 2h)
    
       data:
         pools:   3 pools, 96 pgs
         objects: 500 objects, 1.1 GiB
         usage:   5.5 GiB used, 295 GiB / 300 GiB avail
         pgs:     96 active+clean
    중요

    파일 시스템이 오프라인 상태이거나 MDS 서비스가 없는 경우 CephFS를 복원해야 합니다. 자세한 내용은 10.1절. “CephFS 복원”의 내용을 참조하십시오.

  2. MCG(Multicloud Object Gateway) 상태를 확인합니다. 활성 상태여야 하며 backingstore 및 버킷 클래스는 Ready 상태여야 합니다.

    noobaa status -n openshift-storage
    중요

    MCG가 활성 상태가 아니며 backstore 및 bucketclass가 Ready 상태가 아닌 경우 모든 MCG 관련 Pod를 다시 시작해야 합니다. 자세한 내용은 10.2절. “Multicloud Object Gateway 복원”의 내용을 참조하십시오.

10.1. CephFS 복원

파일 시스템이 오프라인 상태이거나 MDS 서비스가 누락된 경우 CephFS를 복원해야 합니다.

절차

  1. rook-ceph-operatorocs Operator 배포를 축소합니다.

    # oc scale deployment rook-ceph-operator --replicas=0 -n openshift-storage
    # oc scale deployment ocs-operator --replicas=0 -n openshift-storage
  2. MDS 배포를 패치하여 livenessProbe 매개 변수를 제거하고 sleep 으로 command 매개 변수를 사용하여 실행합니다.

    # for i in $(oc get deployment -l app=rook-ceph-mds -oname);do oc patch ${i} -n openshift-storage --type='json' -p '[{"op":"remove", "path":"/spec/template/spec/containers/0/livenessProbe"}]' ; oc patch ${i} -n openshift-storage -p '{"spec": {"template": {"spec": {"containers": [{"name": "mds", "command": ["sleep", "infinity"], "args": []}]}}}}' ; done
  3. CephFS 복구.

    # ceph fs reset ocs-storagecluster-cephfilesystem --yes-i-really-mean-it

    reset 명령이 실패하면 data 및 metadata 풀로 기본 파일 시스템을 강제로 생성한 다음 재설정합니다.

    참고

    cephfilesystem 이 누락된 경우 재설정 명령이 실패할 수 있습니다.

    # ceph fs new ocs-storagecluster-cephfilesystem ocs-storagecluster-cephfilesystem-metadata ocs-storagecluster-cephfilesystem-data0 --force
    # ceph fs reset ocs-storagecluster-cephfilesystem --yes-i-really-mean-it
  4. MDS 배포를 교체합니다.

    # oc replace --force -f oc_get_deployment.rook-ceph-mds-ocs-storagecluster-cephfilesystem-a.yaml
    # oc replace --force -f oc_get_deployment.rook-ceph-mds-ocs-storagecluster-cephfilesystem-b.yaml
  5. rook-ceph-operatorocs-operator 배포를 확장합니다.

    # oc scale deployment ocs-operator --replicas=1 -n openshift-storage
  6. CephFS 상태를 확인합니다.

    # ceph fs status

    상태가 active여야 합니다.

중요
  • CephFS PVC(Persistent Volume Claims)를 사용하는 배포에 연결된 애플리케이션 포드가 CephFS를 복원하면 CreateContainerError 상태가 복원되면 애플리케이션 포드를 다시 시작합니다.

    # oc -n <namespace> delete pods <cephfs-app-pod>
    <namespace>
    프로젝트 네임스페이스입니다
    <cephfs-app-pod>
    CephFS 애플리케이션 Pod의 이름입니다.
  • 새로운 CephFS 또는 RBD PVC가 바인딩되지 않으면 Ceph CSI와 관련된 모든 Pod를 다시 시작합니다.

10.2. Multicloud Object Gateway 복원

MCG(Multicloud Object Gateway)가 활성 상태가 아니며 backingstore 및 버킷 클래스가 Ready 상태가 아닌 경우 모든 MCG 관련 포드를 재시작하고 MCG 상태가 다시 실행되고 있는지 확인해야 합니다.

절차

  1. MCG와 관련된 모든 Pod를 다시 시작합니다.

    # oc delete pods <noobaa-operator> -n openshift-storage
    # oc delete pods <noobaa-core> -n openshift-storage
    # oc delete pods <noobaa-endpoint> -n openshift-storage
    # oc delete pods <noobaa-db> -n openshift-storage
    <noobaa-operator>
    MCG Operator의 이름입니다.
    <noobaa-core>
    MCG 코어 Pod의 이름입니다.
    <noobaa-endpoint>
    MCG 엔드 포인트의 이름입니다.
    <noobaa-db>
    MCG db Pod의 이름입니다.
  2. RADOS 개체 게이트웨이(RGW)가 구성된 경우 포드를 다시 시작합니다.

    # oc delete pods <rgw-pod> -n openshift-storage
    <rgw-pod>
    RGW Pod의 이름입니다.

11장. OpenShift Data Foundation에서 ceph-monitor 쿼럼 복원

경우에 따라 ceph-mons 에서 쿼럼이 손실될 수 있습니다. mons 가 쿼럼을 다시 구성할 수 없는 경우 쿼럼을 다시 가져올 수 있는 수동 절차가 있습니다. 유일한 요구 사항은 적어도 하나의 이 건강해야 한다는 것입니다. 다음 단계에서는 쿼럼에서 비정상적인 mons 를 제거하고 단일 mon 으로 쿼럼을 다시 작성한 다음 쿼럼을 원래 크기로 되돌릴 수 있습니다.

예를 들어 3개의 mon s 및 lose 쿼럼이 있는 경우 쿼럼에서 두 개의 잘못된 mon s 를 제거하고, 쿼럼의 유일한 원주임을 확인한 다음, 좋은 원수를 다시 시작해야 합니다.

절차

  1. monmap 을 수정할 때 mons 가 실패하지 않도록 rook-ceph-operator 를 중지합니다.

    # oc -n openshift-storage scale deployment rook-ceph-operator --replicas=0
  2. monmap 을 삽입합니다.

    주의

    몬맵 을 매우 신중하게 삽입해야 합니다. 잘못 실행하면 클러스터가 영구적으로 삭제될 수 있습니다. Ceph monmapmon quorum를 추적합니다. 몬맵 은 건강한 원만 포함하도록 업데이트됩니다. 이 예에서 정상적인 mon은 rook-ceph-mon-b 이지만 비정상 원은 rook-ceph-mon-arook-ceph-mon-c 입니다.

    1. 현재 rook-ceph-mon-b 배포를 백업하십시오.

      # oc -n openshift-storage get deployment rook-ceph-mon-b -o yaml > rook-ceph-mon-b-deployment.yaml
    2. YAML 파일을 열고 mon 컨테이너에서 명령인수를 복사합니다(다음 예제의 컨테이너 목록 참조). 이는 monmap 의 변경에 필요합니다.

      [...]
        containers:
        - args:
          - --fsid=41a537f2-f282-428e-989f-a9e07be32e47
          - --keyring=/etc/ceph/keyring-store/keyring
          - --log-to-stderr=true
          - --err-to-stderr=true
          - --mon-cluster-log-to-stderr=true
          - '--log-stderr-prefix=debug '
          - --default-log-to-file=false
          - --default-mon-cluster-log-to-file=false
          - --mon-host=$(ROOK_CEPH_MON_HOST)
          - --mon-initial-members=$(ROOK_CEPH_MON_INITIAL_MEMBERS)
          - --id=b
          - --setuser=ceph
          - --setgroup=ceph
          - --foreground
          - --public-addr=10.100.13.242
          - --setuser-match-path=/var/lib/ceph/mon/ceph-b/store.db
          - --public-bind-addr=$(ROOK_POD_IP)
          command:
          - ceph-mon
      [...]
    3. 복사된 명령args 필드를 정리하여 다음과 같이 붙여넣을 수 있는 명령을 형성합니다.

      # ceph-mon \
          --fsid=41a537f2-f282-428e-989f-a9e07be32e47 \
          --keyring=/etc/ceph/keyring-store/keyring \
          --log-to-stderr=true \
          --err-to-stderr=true \
          --mon-cluster-log-to-stderr=true \
          --log-stderr-prefix=debug \
          --default-log-to-file=false \
          --default-mon-cluster-log-to-file=false \
          --mon-host=$ROOK_CEPH_MON_HOST \
          --mon-initial-members=$ROOK_CEPH_MON_INITIAL_MEMBERS \
          --id=b \
          --setuser=ceph \
          --setgroup=ceph \
          --foreground \
          --public-addr=10.100.13.242 \
          --setuser-match-path=/var/lib/ceph/mon/ceph-b/store.db \
          --public-bind-addr=$ROOK_POD_IP
      참고

      --log-stderr-prefix 플래그와 parenthesis가 통과 중인 ROOK_CEPH_TripleO_ HOST , ROOK_CEPH_TripleO_INITIAL_ MEMBERS, ROOK_MEMBERS 및 ROOK_POD_IP )의 단일 따옴표를 제거해야 합니다.

    4. mon pod를 삭제하지 않고 이 mon 의 작동을 중지하도록 rook-ceph-mon-b 배포를 패치합니다.

      # oc -n openshift-storage patch deployment rook-ceph-mon-b  --type='json' -p '[{"op":"remove", "path":"/spec/template/spec/containers/0/livenessProbe"}]'
      
      # oc -n openshift-storage patch deployment rook-ceph-mon-b -p '{"spec": {"template": {"spec": {"containers": [{"name": "mon", "command": ["sleep", "infinity"], "args": []}]}}}}'
    5. mon-b Pod에서 다음 단계를 수행합니다.

      1. 정상적인 mon 의 Pod에 연결하고 다음 명령을 실행합니다.

        # oc -n openshift-storage exec -it <mon-pod> bash
      2. 변수를 설정합니다.

        # monmap_path=/tmp/monmap
      3. 좋은 mon 배포에서 ceph mon 명령을 붙여넣고 --extract- monmap =${monmap_path} 플래그를 추가하여 mon map 을 파일로 추출합니다.

        # ceph-mon \
               --fsid=41a537f2-f282-428e-989f-a9e07be32e47 \
               --keyring=/etc/ceph/keyring-store/keyring \
               --log-to-stderr=true \
               --err-to-stderr=true \
               --mon-cluster-log-to-stderr=true \
               --log-stderr-prefix=debug \
               --default-log-to-file=false \
               --default-mon-cluster-log-to-file=false \
               --mon-host=$ROOK_CEPH_MON_HOST \
               --mon-initial-members=$ROOK_CEPH_MON_INITIAL_MEMBERS \
               --id=b \
               --setuser=ceph \
               --setgroup=ceph \
               --foreground \
               --public-addr=10.100.13.242 \
               --setuser-match-path=/var/lib/ceph/mon/ceph-b/store.db \
               --public-bind-addr=$ROOK_POD_IP \
               --extract-monmap=${monmap_path}
      4. monmap 의 내용을 검토합니다.

        # monmaptool --print /tmp/monmap
      5. monmap 에서 나쁜 원을 제거하십시오.

        # monmaptool ${monmap_path} --rm <bad_mon>

        이 예제에서는 mon0mon2 를 제거합니다.

        # monmaptool ${monmap_path} --rm a
        # monmaptool ${monmap_path} --rm c
      6. 다음과 같이 Ceph mon 명령을 붙여넣고 --inject- monmap =${monmap_path} 플래그를 추가하여 수정된 mon map 을 좋은 Monmap에 삽입합니다.

        # ceph-mon \
               --fsid=41a537f2-f282-428e-989f-a9e07be32e47 \
               --keyring=/etc/ceph/keyring-store/keyring \
               --log-to-stderr=true \
               --err-to-stderr=true \
               --mon-cluster-log-to-stderr=true \
               --log-stderr-prefix=debug \
               --default-log-to-file=false \
               --default-mon-cluster-log-to-file=false \
               --mon-host=$ROOK_CEPH_MON_HOST \
               --mon-initial-members=$ROOK_CEPH_MON_INITIAL_MEMBERS \
               --id=b \
               --setuser=ceph \
               --setgroup=ceph \
               --foreground \
               --public-addr=10.100.13.242 \
               --setuser-match-path=/var/lib/ceph/mon/ceph-b/store.db \
               --public-bind-addr=$ROOK_POD_IP \
               --inject-monmap=${monmap_path}
      7. 쉘을 종료하여 계속합니다.
  3. Rook 구성 맵 편집합니다.

    1. 운영자가 mon s 를 추적하는 데 사용하는 configmap을 편집합니다.

      # oc -n openshift-storage edit configmap rook-ceph-mon-endpoints
    2. 데이터 요소에서 다음과 같은 세 개의 몬수(또는 moncount 에 따라 더 많은 정보)가 표시되는지 확인합니다.

      data: a=10.100.35.200:6789;b=10.100.13.242:6789;c=10.100.35.12:6789
    3. 하나의 좋은 원으로 종료하기 위해 목록에서 잘못된 원을 삭제합니다. 예를 들면 다음과 같습니다.

      data: b=10.100.13.242:6789
    4. 파일을 저장하고 종료합니다.
    5. 이제 mons 및 기타 구성 요소에 사용되는 시크릿 을 조정해야 합니다.

      1. good_mon_id 변수의 값을 설정합니다.

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

        # good_mon_id=b
      2. oc patch 명령을 사용하여 rook-ceph-config 시크릿을 패치하고 두 개의 키/값 쌍 mon_hostmon_initial_members 를 업데이트할 수 있습니다.

        # mon_host=$(oc -n openshift-storage get svc rook-ceph-mon-b -o jsonpath='{.spec.clusterIP}')
        
        # oc -n openshift-storage patch secret rook-ceph-config -p '{"stringData": {"mon_host": "[v2:'"${mon_host}"':3300,v1:'"${mon_host}"':6789]", "mon_initial_members": "'"${good_mon_id}"'"}}'
        참고

        hostNetwork: true 를 사용하는 경우 mon_host var을 mon 이 고정된 노드 IP (nodeSelector)로 교체해야 합니다. 이는 해당 "mode"에서 생성된 rook-ceph-mon-* 서비스가 없기 때문입니다.

  4. 을 다시 시작합니다.

    변경 사항을 찾으려면 원래 ceph-mon 명령으로 좋은 mon pod를 다시 시작해야 합니다.

    1. mon 배포 YAML 파일의 백업에서 oc replace 명령을 사용합니다.

      # oc replace --force -f rook-ceph-mon-b-deployment.yaml
      참고

      옵션 --force 에서 배포를 삭제하고 새 항목을 생성합니다.

    2. 클러스터 상태를 확인합니다.

      상태에는 쿼럼에 하나의 mon 이 표시되어야 합니다. 상태가 정상인 경우 클러스터가 다시 정상이어야 합니다.

  5. 더 이상 쿼럼에 없을 것으로 예상되지 않은 두 개의 mon 배포를 삭제합니다.

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

    # oc delete deploy <rook-ceph-mon-1>
    # oc delete deploy <rook-ceph-mon-2>

    이 예에서 삭제할 배포는 rook-ceph-mon-arook-ceph-mon-c 입니다.

  6. Operator를 다시 시작합니다.

    1. rook Operator를 다시 시작하여 클러스터의 상태 모니터링을 다시 시작합니다.

      참고

      여러 리소스가 이미 존재하는 오류를 무시하는 것이 안전합니다.

      # oc -n openshift-storage scale deployment rook-ceph-operator --replicas=1

      Operator는 mon count에 따라 쿼럼 크기를 다시 늘리기 위해 자동으로 더 많은 원을 추가합니다.

12장. Red Hat OpenShift Data Foundation 콘솔 플러그인 활성화

OpenShift Data Foundation Operator를 설치한 후 자동으로 활성화되지 않은 경우 console 플러그인 옵션을 활성화합니다. 콘솔 플러그인은 웹 콘솔에 포함된 사용자 정의 인터페이스를 제공합니다. GUI(그래픽 사용자 인터페이스) 또는 명령줄 인터페이스에서 콘솔 플러그인 옵션을 활성화할 수 있습니다.

사전 요구 사항

  • OpenShift 웹 콘솔에 대한 관리자 액세스 권한이 있습니다.
  • OpenShift Data Foundation Operator는 openshift-storage 네임스페이스에 설치 및 실행됩니다.

절차

사용자 인터페이스에서
  1. OpenShift 웹 콘솔에서 Operator → 설치된 Operator를 클릭하여 설치된 모든 Operator를 확인합니다.
  2. 선택한 프로젝트openshift-storage 인지 확인합니다.
  3. OpenShift Data Foundation Operator를 클릭합니다.
  4. 콘솔 플러그인 옵션을 활성화합니다.

    1. 세부 정보 탭에서 콘솔 플러그인 아래에 있는 연필 아이콘을 클릭합니다.
    2. 사용을 선택하고 저장을 클릭합니다.
명령줄 인터페이스
  • 다음 명령을 실행하여 콘솔 플러그인 옵션을 활성화합니다.

    $ oc patch console.operator cluster -n openshift-storage --type json -p '[{"op": "add", "path": "/spec/plugins", "value": ["odf-console"]}]'

검증 단계

  • 콘솔 플러그인 옵션이 활성화되면 메시지가 포함된 팝업 이 GUI에 웹 콘솔 업데이트가 표시됩니다. 콘솔 변경 사항을 반영하려면 이 팝업 창에서 웹 콘솔 새로 고침을 클릭합니다.

    • 웹 콘솔에서 Storage 로 이동하여 Data Foundation 을 사용할 수 있는지 확인합니다.

13장. OpenShift Data Foundation 구성 요소에 대한 리소스 변경

OpenShift Data Foundation을 설치할 때 OpenShift Data Foundation Pod에서 사용할 수 있는 사전 정의된 리소스가 제공됩니다. I/O 로드가 높은 경우 이러한 제한을 늘려야 할 수 있습니다.

13.1. rook-ceph Pod에서 CPU 및 메모리 리소스 변경

OpenShift Data Foundation을 설치하면 rook-ceph Pod에 대한 사전 정의된 CPU 및 메모리 리소스가 제공됩니다. 요구 사항에 따라 이러한 값을 수동으로 늘릴 수 있습니다.

다음 Pod에서 CPU 및 메모리 리소스를 변경할 수 있습니다.

  • mgr
  • mds
  • rgw

다음 예제에서는 rook-ceph Pod에서 CPU 및 메모리 리소스를 변경하는 방법을 보여줍니다. 이 예에서는 cpumemory 의 기존 MDS Pod 값이 각각 14Gi 에서 8Gi 로 증가했습니다.

  1. 스토리지 클러스터를 편집합니다.

    # oc edit storagecluster -n openshift-storage <storagecluster_name>
    <storagecluster_name>
    스토리지 클러스터의 이름을 지정합니다.

    예 13.1. 예제

    # oc edit storagecluster -n openshift-storage ocs-storagecluster
  2. 스토리지 클러스터 CR(사용자 정의 리소스)에 다음 행을 추가합니다.

    spec:
      resources:
        mds:
          limits:
            cpu: 2
            memory: 8Gi
          requests:
            cpu: 2
            memory: 8Gi
  3. 변경 사항을 저장하고 편집기를 종료합니다.
  4. 또는 oc patch 명령을 실행하여 mds Pod의 CPU 및 메모리 값을 변경합니다.

    # oc patch -n openshift-storage storagecluster <storagecluster_name>
        --type merge \
        --patch '{"spec": {"resources": {"mds": {"limits": {"cpu": "2","memory": "8Gi"},"requests": {"cpu": "2","memory": "8Gi"}}}}}'
    <storagecluster_name>
    스토리지 클러스터의 이름을 지정합니다.

    예 13.2. 예제

    # oc patch -n openshift-storage storagecluster ocs-storagecluster \
        --type merge \
        --patch '{"spec": {"resources": {"mds": {"limits": {"cpu": "2","memory": "8Gi"},"requests": {"cpu": "2","memory": "8Gi"}}}}}'

13.2. MCG의 리소스 튜닝

MCG(Multicloud Object Gateway)의 기본 구성은 성능이 저하되고 리소스 사용에 최적화되어 있습니다. MCG에 대한 리소스를 조정하는 방법에 대한 자세한 내용은 NooBaa(Multicloud Object Gateway)에 대한 Red Hat 지식베이스 솔루션 성능 튜닝 가이드 를 참조하십시오.