OpenShift Data Foundation 문제 해결

Red Hat OpenShift Data Foundation 4.13

OpenShift Data Foundation 문제 해결 방법

Red Hat Storage Documentation Team

초록

Red Hat OpenShift Data Foundation 문제 해결에 대한 자세한 내용은 이 문서를 참조하십시오.

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

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

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

문서 개선을 위한 의견을 보내 주십시오. 개선할 내용에 대해 알려주십시오. 피드백을 보내주시려면 다음을 확인하십시오.

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

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

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

1장. 개요

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

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

주의

Red Hat은 잘못된 명령을 실행할 때 데이터가 손실될 수 있으므로 OpenShift Data Foundation 클러스터에서 Ceph 명령 실행을 지원하지 않습니다(Red Hat 지원 또는 Red Hat 설명서에 명시되어 있지 않음). 이 경우 Red Hat 지원팀은 상업적으로 합리적인 노력으로만 제공할 수 있으며 데이터 손실 시 모든 데이터를 복원할 수 없습니다.

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

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

중요

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/odf-must-gather-rhel9:v4.13 <local-registry>/odf4/odf-must-gather-rhel9:v4.13 [--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/odf-must-gather-rhel9:v4.13 --dest-dir=<directory-name>
    <directory-name>

    데이터를 작성할 디렉터리의 이름입니다.

    중요

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

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

    지정된 디렉터리에서 다음 정보를 수집합니다.

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

명령 변형

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

    $ oc adm must-gather --image=registry.redhat.io/odf4/odf-must-gather-rhel9:v4.13 --dest-dir=_<directory-name>_ --node-name=_<node-name>_
  • 특정 시간에서 정보를 수집하려는 경우:

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

      $ oc adm must-gather --image=registry.redhat.io/odf4/odf-must-gather-rhel9:v4.13 --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/odf-must-gather-rhel9:v4.13 --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>
    2020년 11월 11일 오전 4시부터 2020-11-10T04:00:00+00:00 과 같이 RFC 3339 타임 스탬프로 정보를 수집할 기간을 지정합니다.

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
  • cephfs 또는 rbd 프로비저너 Pod에 대한 로그를 생성하여 PVC가 BOUND 상태에 없는 경우 문제를 탐지합니다.

    $ 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 로그 및 이벤트를 확인합니다.

    • 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 Operator 버전 및 채널을 가져옵니다.

    # oc get csv -n openshift-storage

    출력 예:

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

    출력 예:

    NAME                                                              PACKAGE                   SOURCE             CHANNEL
    mcg-operator-stable-4.13-redhat-operators-openshift-marketplace   mcg-operator              redhat-operators   stable-4.13
    ocs-operator-stable-4.13-redhat-operators-openshift-marketplace   ocs-operator              redhat-operators   stable-4.13
    odf-csi-addons-operator                                           odf-csi-addons-operator   redhat-operators   stable-4.13
    odf-operator                                                      odf-operator              redhat-operators   stable-4.13
  • 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 페이지의 Digest ID에 매핑합니다.

추가 리소스

3.1. 로그 수준 조정

로그 디버깅에 사용되는 공간의 양이 심각한 문제가 될 수 있습니다. Red Hat OpenShift Data Foundation은 조정할 방법을 제공하므로 로그를 디버깅하여 사용할 스토리지 양을 제어합니다.

디버깅 로그의 상세 수준을 조정하려면 CSI 작업을 담당하는 컨테이너의 로그 수준을 조정할 수 있습니다. 컨테이너의 yaml 파일에서 다음 매개변수를 조정하여 로깅 수준을 설정합니다.

  • CSI_LOG_LEVEL - 기본값은 5입니다.
  • CSI_SIDECAR_LOG_LEVEL - 기본값은 1입니다.

지원되는 값은 0 에서 5 까지입니다. 일반적인 유용한 로그에는 0, 추적 수준 세부 정보 표시에는 5 를 사용합니다.

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. DaemonSets에서 생성한 원래 Pod를 삭제합니다.

    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-token작업시크릿 편집 을 클릭합니다.
    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은 여러 공통 실패 시나리오를 감지하고 자동으로 해결할 수 있습니다. 그러나 일부 문제의 경우 관리자의 개입이 필요합니다.

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

  • observeAlert ing 실행 옵션
  • 개요클러스터
  • 스토리지데이터 기반 스토리지 시스템 → 팝업 → 개요블록 및 파일 탭의 스토리지 시스템 링크
  • 스토리지Data Foundation 스토리지 시스템 → 팝업 → 개요오브젝트 탭의 스토리지 시스템 링크

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

이름:CephMonVersionMismatch

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

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

심각도: 경고

해결 방법 : 수정

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

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

이름:CephOSDVersionMismatch

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

설명:{{ $value }} 다양한 버전의 Ceph OSD 구성 요소가 실행되고 있습니다.

심각도: 경고

해결 방법 : 수정

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

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

이름:CephClusterCriticallyFull

메시지:스토리지 클러스터는 매우 가득 차 있으며 즉각적인 확장이 필요합니다.

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

심각도: Crtical

해결 방법 : 수정

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

이름:CephClusterNearFull

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

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

심각도: 경고

해결 방법 : 수정

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

이름:NooBaaBucketErrorState

NooBaa Bucket Is In Error State

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

심각도: 경고

해결 방법 : 해결 방법

절차:NooBaa Bucket 오류 상태복구

이름:NooBaaNamespaceResourceErrorState

NooBaa 네임스페이스 리소스가 오류 상태에 있는 경우

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

심각도: 경고

해결 방법 : 수정

절차:NooBaa Bucket 오류 상태복구

이름:NooBaaNamespaceBucketErrorState

No o Baa 네임스페이스 버킷이 오류 상태에 있는 경우NooBaa Namespace Bucket Is In Error State

설명:NooBaa 네임스페이스 버킷 {{ $labels.bucket_name }}은 5m 이상에 대한 오류 상태입니다.

심각도: 경고

해결 방법 : 수정

절차:NooBaa Bucket 오류 상태복구

Name: NooBaaBucketExceedingQuotaState

NooBaa Bucket Is In Exceeding Quota State

설명:NooBaa 버킷 {{ $labels.bucket_name }}은 할당량을 초과합니다 - {{ printf "%0.0f" $value }}% 사용 메시지: NooBaa Bucket Is In Exceeding Quota State

심각도: 경고

해결 방법 : 수정

절차: NooBaa Bucket Exceeding Quota State

Name: NooBaaBucketLowCapacityState

메시지:NooBaa Bucket은 낮은 용량 상태에있습니다.

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

심각도: 경고

해결 방법 : 수정

절차:NooBaa 버킷 용량 또는 할당량 상태

Name: NooBaaBucketNoCapacityState

메시지:NooBaa Bucket Is In No Capacity State

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

심각도: 경고

해결 방법 : 수정

절차:NooBaa 버킷 용량 또는 할당량 상태

Name: NooBaaBucketReachingQuotaState

메시지:NooBaa Bucket Is In Reaching Quota State

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

심각도: 경고

해결 방법 : 수정

절차:NooBaa 버킷 용량 또는 할당량 상태

이름:NooBaaResourceErrorState

NooBaa 리소스는 오류 상태에있습니다.

설명:NooBaa 리소스 {{ $labels.resource_name }} 이상 6m의 경우 오류 상태입니다.

심각도: 경고

해결 방법 : 해결 방법

절차:NooBaa Bucket 오류 상태복구

Name: NooBaaSystemCapacityWarning100

메시지:NooBaa 시스템에 접근하여 용량

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

심각도: 경고

해결 방법 : 수정

절차:NooBaa 버킷 용량 또는 할당량 상태

Name: NooBaaSystemCapacityWarning85

메시지:NooBaa 시스템은 액세스 용량에 접근합니다.

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

심각도: 경고

해결 방법 : 수정

절차:NooBaa 버킷 용량 또는 할당량 상태

Name: NooBaaSystemCapacityWarning95

메시지:NooBaa 시스템은 액세스 용량에 접근합니다.

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

심각도: 경고

해결 방법 : 수정

절차:NooBaa 버킷 용량 또는 할당량 상태

이름:CephMdsMissingReplicas

Message:스토리지 메타데이터 서비스를 위한 복제본이 없습니다.

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

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

심각도: 경고

해결 방법:Red Hat 지원에 문의

프로세스:

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

이름:CephMgrIsAbsent

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

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

심각도: 심각

해결 방법:Red Hat 지원에 문의

프로세스:

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

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

이름:CephNodeDown

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

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

심각도: 심각

해결 방법:Red Hat 지원에 문의

프로세스:

  1. 작동이 중지된 노드와 해당 원인을 확인합니다.
  2. 노드를 복구하려면 적절한 작업을 수행합니다. 노드를 복구할 수 없는 경우:

name:CephClusterErrorState

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

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

심각도: 심각

해결 방법:Red Hat 지원에 문의

프로세스:

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

Name: CephClusterWarningState

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

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

심각도: 경고

해결 방법:Red Hat 지원에 문의

프로세스:

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

Name: CephDataRecoveryTakingTooLong

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

설명:데이터 복구가 너무 오래 활성화되어 있습니다.

심각도: 경고

해결 방법:Red Hat 지원에 문의

이름:CephOSDDiskNotResponding

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

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

심각도: 심각

해결 방법:Red Hat 지원에 문의

이름:CephOSDDiskUnavailable

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

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

심각도: 심각

해결 방법:Red Hat 지원에 문의

이름:CephPGRepairTakingTooLong

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

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

심각도: 경고

해결 방법:Red Hat 지원에 문의

이름:CephMonHighNumberOfLeaderChanges

메시지:스토리지 클러스터는 최근에 많은 리더의 변경사항을 확인했습니다.

설명:'Ceph Monitor "{{ $labels.job }}": 인스턴스 {{ $labels.instance }}가 {{ $value printf "%.2f" }} 리더는 최근에 분당 변경됩니다.'

심각도: 경고

해결 방법:Red Hat 지원에 문의

이름:CephMonQuorumAtRisk

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

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

심각도: 심각

해결 방법:Red Hat 지원에 문의

Name: ClusterObjectStoreState

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

설명:Cluster Object Store는 15s 이상의 비정상적인 상태에 있습니다. Ceph 클러스터 상태를 확인하십시오.

심각도: 심각

해결 방법:Red Hat 지원에 문의

프로세스:

이름:CephOSDFlapping

메시지:Storage 데몬 osd.x는 지난 5분 동안 5번 재시작했습니다. Pod 이벤트 또는 Ceph 상태를 확인하여 원인을 확인하십시오.

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

심각도: 심각

해결 방법:Red Hat 지원에 문의

Name: OdfPoolMirroringImageHealth

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

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

심각도: 경고

해결 방법:Red Hat 지원에 문의

이름:OdfMirrorDaemonStatus

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

설명: 전체 클러스터에 대해 Dis disaster recovery가 실패합니다. 미러 데몬은 1m 이상 비정상적인 상태에 있습니다. 이 클러스터에서 미러링이 예상대로 작동하지 않습니다.

심각도: 심각

해결 방법:Red Hat 지원에 문의

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

Red Hat Ceph Storage 클러스터가 OpenShift Data Foundation 사용자 인터페이스에서 해당 쇼를 발생시킬 수 있는 제한된 상태 메시지가 있습니다. 이는 고유 식별자가 있는 상태 점검으로 정의됩니다. 식별자는 도구를 사용하여 상태 점검을 이해할 수 있도록 하고 그 의미가 반영되는 방식으로 표시할 수 있도록 하는 terse 의사-human에서 읽을 수 있는 문자열입니다. 자세한 정보와 문제 해결을 위해 아래 상태 코드를 클릭합니다.

상태 코드설명

MON_DISK_LOW

하나 이상의 Ceph 모니터가 디스크 공간이 부족합니다.

6.2.1. MON_DISK_LOW

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

참고

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

경로 예:

  • PVC 경로를 통해 Mon 배포: /var/lib/ceph/mon
  • hostpath를 통해 Mon을 배포: /var/lib/rook/mon

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

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

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

6.3. 클러스터 경고 해결

Red Hat Ceph Storage 클러스터가 OpenShift Data Foundation 사용자 인터페이스에서 해당 쇼를 발생시킬 수 있는 제한된 상태 경고가 있습니다. 이는 고유 식별자가 있는 상태 경고로 정의됩니다. 식별자는 도구를 사용하여 상태 점검을 이해할 수 있도록 하고 그 의미가 반영되는 방식으로 표시할 수 있도록 하는 terse 의사-human에서 읽을 수 있는 문자열입니다. 자세한 정보와 문제 해결을 위해 상태 경고를 클릭합니다.

표 6.1. 클러스터 상태 경고 유형

상태 경고개요

CephClusterCriticallyFull

스토리지 클러스터 사용률이 80%를 초과했습니다.

CephClusterErrorState

스토리지 클러스터는 10분 이상 오류 상태에 있습니다.

CephClusterNearFull

스토리지 클러스터는 전체 용량에 도달하고 있습니다. 데이터 삭제 또는 클러스터 확장이 필요합니다.

CephClusterReadOnly

스토리지 클러스터는 이제 읽기 전용이며 즉각적인 데이터 삭제 또는 클러스터 확장이 필요합니다.

CephClusterWarningState

스토리지 클러스터는 10분 이상 경고 상태입니다.

CephDataRecoveryTakingTooLong

데이터 복구가 오랜 시간 동안 활성화되었습니다.

CephMdsMissingReplicas

스토리지 메타데이터 서비스에 필요한 최소 복제본은 사용할 수 없습니다. 스토리지 클러스터의 작동에 영향을 미칠 수 있습니다.

CephMgrIsAbsent

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

CephMgrIsMissingReplicas

Ceph 관리자가 복제본이 없습니다. Thispts 상태 보고는 ceph status 명령으로 보고되는 일부 정보가 누락되거나 오래되었습니다. 또한 Ceph 관리자는 Ceph의 기존 기능을 확장하기 위한 관리자 프레임워크를 담당합니다.

CephMonHighNumberOfLeaderChanges

Ceph 모니터 리더는 비정상적인 횟수로 변경되었습니다.

CephMonQuorumAtRisk

스토리지 클러스터 쿼럼이 낮습니다.

CephMonQuorumLost

스토리지 클러스터의 모니터 Pod 수가 충분하지 않습니다.

CephMonVersionMismatch

다양한 버전의 Ceph Mon 구성 요소가 실행되고 있습니다.

CephNodeDown

스토리지 노드가 중단되었습니다. 노드를 즉시 확인합니다. 경고에는 노드 이름이 포함되어야 합니다.

CephOSDCriticallyFull

백엔드 OSD(Object Storage Device)의 사용률은 80%를 초과했습니다. 일부 공간을 즉시 확보하거나 스토리지 클러스터 또는 연락처 지원을 확장합니다.

CephOSDDiskNotResponding

디스크 장치가 호스트 중 하나에 응답하지 않습니다.

CephOSDDiskUnavailable

호스트 중 하나에서 디스크 장치에 액세스할 수 없습니다.

CephOSDFlapping

Ceph 스토리지 OSD 플로팅.

CephOSDNearFull

OSD 스토리지 장치 중 하나가 가득 차 있습니다.

CephOSDSlowOps

OSD 요청을 처리하는 데 시간이 너무 오래 걸립니다.

CephOSDVersionMismatch

실행 중인 다양한 버전의 Ceph OSD 구성 요소가 있습니다.

CephPGRepairTakingTooLong

자동 복구 작업이 너무 오래 걸립니다.

CephPoolQuotaBytesCriticallyExhausted

스토리지 풀 할당량 사용량이 90%를 초과했습니다.

CephPoolQuotaBytesNearExhaustion

스토리지 풀 할당량 사용량이 70%를 초과했습니다.

PersistentVolumeUsageCritical

영구 볼륨 클레임 사용량이 용량의 85%를 초과했습니다.

PersistentVolumeUsageNearFull

영구 볼륨 클레임 사용량이 용량의 75% 이상을 초과했습니다.

6.3.1. CephClusterCriticallyFull

의미

스토리지 클러스터 사용률이 80%를 초과했으며 85%에서 읽기 전용으로 사용됩니다. 사용률이 85%를 초과하면 Ceph 클러스터가 읽기 전용이 됩니다. 일부 공간을 확보하거나 스토리지 클러스터를 즉시 확장합니다. 이 경고보다 먼저 OSD(Object Storage Device) 장치와 관련된 경고는 전체 또는 가까운 것을 볼 수 있습니다.

보안 등급

높음

진단

Scaling storage
클러스터 유형에 따라 스토리지 장치, 노드 또는 둘 다를 추가해야 합니다. 자세한 내용은 스토리지 스케일링 가이드를 참조하십시오.

완화 방법

정보 삭제
클러스터를 확장할 수 없는 경우 일부 공간을 확보하기 위해 정보를 삭제해야 합니다.

6.3.2. CephClusterErrorState

의미

이 경고는 스토리지 클러스터가 예기치 않은 시간 동안 ERROR 상태임을 반영하고 스토리지 가용성을 향상시킵니다. 이 경고보다 먼저 트리거된 다른 경고가 있는지 확인하고 먼저 해당 경고 문제를 해결합니다.

보안 등급

심각

진단

Pod 상태: pending
  1. 리소스 문제, 보류 중인 PVC(영구 볼륨 클레임), 노드 할당 및 kubelet 문제를 확인합니다.

    $ oc project openshift-storage
    $ oc get pod | grep rook-ceph
  2. 문제 Pod로 식별되는 Pod의 변수로 MYPOD 를 설정합니다.

    # Examine the output for a rook-ceph that is in the pending state, not running or not ready
    MYPOD=<pod_name>
    <pod_name>
    문제 Pod로 식별되는 Pod의 이름을 지정합니다.
  3. 리소스 제한 또는 보류 중인 PVC를 찾습니다. 또는 노드 할당을 확인합니다.

    $ oc get pod/${MYPOD} -o wide
Pod 상태: 보류 중이 아니라 실행 중이지만 준비되지 않음
  • 준비 상태 프로브를 확인합니다.

    $ oc describe pod/${MYPOD}
Pod 상태: 보류 중이 아니지만 실행 중이 아닙니다.
  • 애플리케이션 또는 이미지 문제가 있는지 확인합니다.

    $ oc logs pod/${MYPOD}
    중요
    • 노드가 할당된 경우 노드에서 kubelet을 확인합니다.
    • 실행 중인 Pod의 기본 상태가 확인되면 노드의 노드 유사성 및 리소스 가용성이 확인되면 Ceph 툴을 실행하여 스토리지 구성 요소의 상태를 가져옵니다.

완화 방법

디버깅 로그 정보
  • 이 단계는 선택 사항입니다. 다음 명령을 실행하여 Ceph 클러스터에 대한 디버깅 정보를 수집합니다.

    $ oc adm must-gather --image=registry.redhat.io/odf4/odf-must-gather-rhel9:v4.13

6.3.3. CephClusterNearFull

의미

스토리지 클러스터 사용률이 75%를 초과하여 85%로 읽기 전용이 됩니다. 일부 공간을 확보하거나 스토리지 클러스터를 확장합니다.

보안 등급

심각

진단

Scaling storage
클러스터 유형에 따라 스토리지 장치, 노드 또는 둘 다를 추가해야 합니다. 자세한 내용은 스토리지 스케일링 가이드를 참조하십시오.

완화 방법

정보 삭제
클러스터를 확장할 수 없는 경우 일부 공간을 확보하기 위해 정보를 삭제해야 합니다.

6.3.4. CephClusterReadOnly

의미

스토리지 클러스터 사용률이 85% 이상되어 이제 읽기 전용입니다. 일부 공간을 확보하거나 스토리지 클러스터를 즉시 확장합니다.

보안 등급

심각

진단

Scaling storage
클러스터 유형에 따라 스토리지 장치, 노드 또는 둘 다를 추가해야 합니다. 자세한 내용은 스토리지 스케일링 가이드를 참조하십시오.

완화 방법

정보 삭제
클러스터를 확장할 수 없는 경우 일부 공간을 확보하기 위해 정보를 삭제해야 합니다.

6.3.5. CephClusterWarningState

의미

이 경고는 스토리지 클러스터가 잘못된 시간 동안 경고 상태에 있음을 반영합니다. 이 상태에서 스토리지 작업이 계속 작동하지만 클러스터가 오류 상태 입력 작업에 포함되지 않도록 오류를 수정하는 것이 좋습니다. 이 경고보다 먼저 트리거되었을 수 있는 다른 경고를 확인하고 먼저 해당 경고 문제를 해결합니다.

보안 등급

높음

진단

Pod 상태: pending
  1. 리소스 문제, 보류 중인 PVC(영구 볼륨 클레임), 노드 할당 및 kubelet 문제를 확인합니다.

    $ oc project openshift-storage
    oc get pod | grep {ceph-component}
  2. 문제 Pod로 식별되는 Pod의 변수로 MYPOD 를 설정합니다.

    # Examine the output for a {ceph-component}  that is in the pending state, not running or not ready
    MYPOD=<pod_name>
    <pod_name>
    문제 Pod로 식별되는 Pod의 이름을 지정합니다.
  3. 리소스 제한 또는 보류 중인 PVC를 찾습니다. 또는 노드 할당을 확인합니다.

    $ oc get pod/${MYPOD} -o wide
Pod 상태: 보류 중이 아니라 실행 중이지만 준비되지 않음
  • 준비 상태 프로브를 확인합니다.

    $ oc describe pod/${MYPOD}
Pod 상태: 보류 중이 아니지만 실행 중이 아닙니다.
  • 애플리케이션 또는 이미지 문제가 있는지 확인합니다.

    $ oc logs pod/${MYPOD}
    중요

    노드가 할당된 경우 노드에서 kubelet을 확인합니다.

완화 방법

디버깅 로그 정보
  • 이 단계는 선택 사항입니다. 다음 명령을 실행하여 Ceph 클러스터에 대한 디버깅 정보를 수집합니다.
$ oc adm must-gather --image=registry.redhat.io/odf4/odf-must-gather-rhel9:v4.13

6.3.6. CephDataRecoveryTakingTooLong

의미

데이터 복구 속도가 느리다. 모든 OSD(오브젝트 스토리지 장치)가 실행 중인지 확인합니다.

보안 등급

높음

진단

Pod 상태: pending
  1. 리소스 문제, 보류 중인 PVC(영구 볼륨 클레임), 노드 할당 및 kubelet 문제를 확인합니다.

    $ oc project openshift-storage
    oc get pod | grep rook-ceph-osd
  2. 문제 Pod로 식별되는 Pod의 변수로 MYPOD 를 설정합니다.

    # Examine the output for a {ceph-component}  that is in the pending state, not running or not ready
    MYPOD=<pod_name>
    <pod_name>
    문제 Pod로 식별되는 Pod의 이름을 지정합니다.
  3. 리소스 제한 또는 보류 중인 PVC를 찾습니다. 또는 노드 할당을 확인합니다.

    $ oc get pod/${MYPOD} -o wide
Pod 상태: 보류 중이 아니라 실행 중이지만 준비되지 않음
  • 준비 상태 프로브를 확인합니다.

    $ oc describe pod/${MYPOD}
Pod 상태: 보류 중이 아니지만 실행 중이 아닙니다.
  • 애플리케이션 또는 이미지 문제가 있는지 확인합니다.

    $ oc logs pod/${MYPOD}
    중요

    노드가 할당된 경우 노드에서 kubelet을 확인합니다.

완화 방법

디버깅 로그 정보
  • 이 단계는 선택 사항입니다. 다음 명령을 실행하여 Ceph 클러스터에 대한 디버깅 정보를 수집합니다.
$ oc adm must-gather --image=registry.redhat.io/odf4/odf-must-gather-rhel9:v4.13

6.3.7. CephMdsMissingReplicas

의미

스토리지 메타데이터 서비스(MDS)에 필요한 최소 복제본을 사용할 수 없습니다. MDS는 메타데이터 제출을 담당합니다. MDS 서비스 저하는 스토리지 클러스터의 작동 방식에 영향을 미칠 수 있으며( CephFS 스토리지 클래스와 관련된) 최대한 빨리 수정해야 합니다.

보안 등급

높음

진단

Pod 상태: pending
  1. 리소스 문제, 보류 중인 PVC(영구 볼륨 클레임), 노드 할당 및 kubelet 문제를 확인합니다.

    $ oc project openshift-storage
    oc get pod | grep rook-ceph-mds
  2. 문제 Pod로 식별되는 Pod의 변수로 MYPOD 를 설정합니다.

    # Examine the output for a {ceph-component}  that is in the pending state, not running or not ready
    MYPOD=<pod_name>
    <pod_name>
    문제 Pod로 식별되는 Pod의 이름을 지정합니다.
  3. 리소스 제한 또는 보류 중인 PVC를 찾습니다. 또는 노드 할당을 확인합니다.

    $ oc get pod/${MYPOD} -o wide
Pod 상태: 보류 중이 아니라 실행 중이지만 준비되지 않음
  • 준비 상태 프로브를 확인합니다.

    $ oc describe pod/${MYPOD}
Pod 상태: 보류 중이 아니지만 실행 중이 아닙니다.
  • 애플리케이션 또는 이미지 문제가 있는지 확인합니다.

    $ oc logs pod/${MYPOD}
    중요

    노드가 할당된 경우 노드에서 kubelet을 확인합니다.

완화 방법

디버깅 로그 정보
  • 이 단계는 선택 사항입니다. 다음 명령을 실행하여 Ceph 클러스터에 대한 디버깅 정보를 수집합니다.
$ oc adm must-gather --image=registry.redhat.io/odf4/odf-must-gather-rhel9:v4.13

6.3.8. CephMgrIsAbsent

의미

Ceph 관리자가 클러스터 모니터링을 실행하지 않도록 합니다. PVC(영구 볼륨 클레임) 생성 및 삭제 요청은 최대한 빨리 해결되어야 합니다.

보안 등급

높음

진단

  • rook-ceph-mgr Pod가 실패하는지 확인하고 필요한 경우 다시 시작합니다. Ceph mgr pod 재시작이 실패하면 일반 Pod 문제 해결에 따라 문제를 해결합니다.

    • Ceph mgr Pod가 실패하는지 확인합니다.

      $ oc get pods | grep mgr
    • 자세한 내용은 Ceph mgr Pod를 설명합니다.

      $ oc describe pods/<pod_name>
      <pod_name>
      이전 단계의 rook-ceph-mgr 포드 이름을 지정합니다.

      리소스 문제와 관련된 오류를 분석합니다.

    • Pod를 삭제하고 Pod가 다시 시작될 때까지 기다립니다.

      $ oc get pods | grep mgr

일반적인 Pod 문제 해결에 다음 단계를 따르십시오.

Pod 상태: pending
  1. 리소스 문제, 보류 중인 PVC(영구 볼륨 클레임), 노드 할당 및 kubelet 문제를 확인합니다.

    $ oc project openshift-storage
    oc get pod | grep rook-ceph-mgr
  2. 문제 Pod로 식별되는 Pod의 변수로 MYPOD 를 설정합니다.

    # Examine the output for a {ceph-component}  that is in the pending state, not running or not ready
    MYPOD=<pod_name>
    <pod_name>
    문제 Pod로 식별되는 Pod의 이름을 지정합니다.
  3. 리소스 제한 또는 보류 중인 PVC를 찾습니다. 또는 노드 할당을 확인합니다.

    $ oc get pod/${MYPOD} -o wide
Pod 상태: 보류 중이 아니라 실행 중이지만 준비되지 않음
  • 준비 상태 프로브를 확인합니다.

    $ oc describe pod/${MYPOD}
Pod 상태: 보류 중이 아니지만 실행 중이 아닙니다.
  • 애플리케이션 또는 이미지 문제가 있는지 확인합니다.

    $ oc logs pod/${MYPOD}
    중요

    노드가 할당된 경우 노드에서 kubelet을 확인합니다.

완화 방법

디버깅 로그 정보
  • 이 단계는 선택 사항입니다. 다음 명령을 실행하여 Ceph 클러스터에 대한 디버깅 정보를 수집합니다.
$ oc adm must-gather --image=registry.redhat.io/odf4/odf-must-gather-rhel9:v4.13

6.3.9. CephMgrIsMissingReplicas

의미

이 경고를 해결하려면 Ceph 관리자의 제거 원인을 확인하고 필요한 경우 다시 시작해야 합니다.

보안 등급

높음

진단

Pod 상태: pending
  1. 리소스 문제, 보류 중인 PVC(영구 볼륨 클레임), 노드 할당 및 kubelet 문제를 확인합니다.

    $ oc project openshift-storage
    oc get pod | grep rook-ceph-mgr
  2. 문제 Pod로 식별되는 Pod의 변수로 MYPOD 를 설정합니다.

    # Examine the output for a {ceph-component}  that is in the pending state, not running or not ready
    MYPOD=<pod_name>
    <pod_name>
    문제 Pod로 식별되는 Pod의 이름을 지정합니다.
  3. 리소스 제한 또는 보류 중인 PVC를 찾습니다. 또는 노드 할당을 확인합니다.

    $ oc get pod/${MYPOD} -o wide
Pod 상태: 보류 중이 아니라 실행 중이지만 준비되지 않음
  • 준비 상태 프로브를 확인합니다.

    $ oc describe pod/${MYPOD}
Pod 상태: 보류 중이 아니지만 실행 중이 아닙니다.
  • 애플리케이션 또는 이미지 문제가 있는지 확인합니다.

    $ oc logs pod/${MYPOD}
    중요

    노드가 할당된 경우 노드에서 kubelet을 확인합니다.

완화 방법

디버깅 로그 정보
  • 이 단계는 선택 사항입니다. 다음 명령을 실행하여 Ceph 클러스터에 대한 디버깅 정보를 수집합니다.
$ oc adm must-gather --image=registry.redhat.io/odf4/odf-must-gather-rhel9:v4.13

6.3.10. CephMonHighNumberOfLeaderChanges

의미

Ceph 클러스터에는 스토리지 클러스터에 대한 중요한 정보를 저장하는 중복 모니터 Pod 세트가 있습니다. Pod를 정기적으로 모니터링하여 스토리지 클러스터에 대한 정보를 가져옵니다. 가장 업데이트된 정보를 가져오는 첫 번째 모니터 Pod가 리더가 되고 다른 모니터 Pod는 리더를 요청한 후 동기화 프로세스를 시작합니다. 하나 이상의 모니터 Pod의 네트워크 연결 또는 다른 종류의 문제에 문제가 발생하면 리더의 비정상적인 변경이 발생합니다. 이 상황은 스토리지 클러스터 성능에 부정적인 영향을 미칠 수 있습니다.

보안 등급

중간

중요

네트워크 문제가 있는지 확인합니다. 네트워크 문제가 있는 경우 다음 문제 해결 단계를 진행하기 전에 OpenShift Data Foundation 팀으로 에스컬레이션해야 합니다.

진단

  1. 영향을 받는 모니터 Pod의 로그를 출력하여 문제에 대한 자세한 정보를 수집합니다.

    $ oc logs <rook-ceph-mon-X-yyyy> -n openshift-storage
    <rook-ceph-mon-X-yyyy>
    영향을 받는 모니터 Pod의 이름을 지정합니다.
  2. 또는 Openshift 웹 콘솔을 사용하여 영향을 받는 모니터 Pod의 로그를 엽니다. 가능한 원인에 대한 자세한 내용은 로그에 반영됩니다.
  3. 일반 Pod 문제 해결 단계를 수행합니다.

    Pod 상태: pending
  4. 리소스 문제, 보류 중인 PVC(영구 볼륨 클레임), 노드 할당 및 kubelet 문제를 확인합니다.

    $ oc project openshift-storage
    oc get pod | grep {ceph-component}
  5. 문제 Pod로 식별되는 Pod의 변수로 MYPOD 를 설정합니다.

    # Examine the output for a {ceph-component}  that is in the pending state, not running or not ready
    MYPOD=<pod_name>
    <pod_name>
    문제 Pod로 식별되는 Pod의 이름을 지정합니다.
  6. 리소스 제한 또는 보류 중인 PVC를 찾습니다. 또는 노드 할당을 확인합니다.

    $ oc get pod/${MYPOD} -o wide
    Pod 상태: 보류 중이 아니라 실행 중이지만 준비되지 않음
    • 준비 상태 프로브를 확인합니다.
    $ oc describe pod/${MYPOD}
    Pod 상태: 보류 중이 아니지만 실행 중이 아닙니다.
    • 애플리케이션 또는 이미지 문제가 있는지 확인합니다.
    $ oc logs pod/${MYPOD}
    중요

    노드가 할당된 경우 노드에서 kubelet을 확인합니다.

완화 방법

디버깅 로그 정보
  • 이 단계는 선택 사항입니다. 다음 명령을 실행하여 Ceph 클러스터에 대한 디버깅 정보를 수집합니다.
$ oc adm must-gather --image=registry.redhat.io/odf4/odf-must-gather-rhel9:v4.13

6.3.11. CephMonQuorumAtRisk

의미

중복성을 제공하기 위해 여러 MON이 함께 작동합니다. 각 MON은 메타데이터 사본을 유지합니다. 클러스터는 3 MON을 사용하여 배포되며 쿼럼에 대해 2개 이상의 MON이 실행 중이고 스토리지 작업을 실행해야 합니다. 쿼럼이 손실되면 데이터에 대한 액세스가 위험할 수 있습니다.

보안 등급

높음

진단

Ceph MON 쿼리를 복원합니다. 자세한 내용은 문제 해결 가이드 의 OpenShift Data Foundation에서 ceph-monitor 쿼럼 복구를 참조하십시오. Ceph MON 분기의 복원이 실패하면 일반 Pod 문제 해결에 따라 문제를 해결합니다.

일반 Pod 문제 해결을 위해 다음을 수행합니다.

Pod 상태: pending

+[

  1. 리소스 문제, 보류 중인 PVC(영구 볼륨 클레임), 노드 할당 및 kubelet 문제를 확인합니다.

    $ oc project openshift-storage
    oc get pod | grep rook-ceph-mon
  2. 문제 Pod로 식별되는 Pod의 변수로 MYPOD 를 설정합니다.

    # Examine the output for a {ceph-component}  that is in the pending state, not running or not ready
    MYPOD=<pod_name>
    <pod_name>
    문제 Pod로 식별되는 Pod의 이름을 지정합니다.
  3. 리소스 제한 또는 보류 중인 PVC를 찾습니다. 또는 노드 할당을 확인합니다.

    $ oc get pod/${MYPOD} -o wide
Pod 상태: 보류 중이 아니라 실행 중이지만 준비되지 않음
  • 준비 상태 프로브를 확인합니다.
$ oc describe pod/${MYPOD}
Pod 상태: 보류 중이 아니지만 실행 중이 아닙니다.
  • 애플리케이션 또는 이미지 문제가 있는지 확인합니다.
$ oc logs pod/${MYPOD}
중요

노드가 할당된 경우 노드에서 kubelet을 확인합니다.

완화 방법

디버깅 로그 정보
  • 이 단계는 선택 사항입니다. 다음 명령을 실행하여 Ceph 클러스터에 대한 디버깅 정보를 수집합니다.
$ oc adm must-gather --image=registry.redhat.io/odf4/odf-must-gather-rhel9:v4.13

6.3.12. CephMonQuorumLost

의미

Ceph 클러스터에는 스토리지 클러스터에 대한 중요한 정보를 저장하는 중복 모니터 Pod 세트가 있습니다. Pod를 정기적으로 모니터링하여 스토리지 클러스터에 대한 정보를 가져옵니다. 가장 업데이트된 정보를 가져오는 첫 번째 모니터 Pod가 리더가 되고 다른 모니터 Pod는 리더를 요청한 후 동기화 프로세스를 시작합니다. 하나 이상의 모니터 Pod의 네트워크 연결 또는 다른 종류의 문제에 문제가 발생하면 리더의 비정상적인 변경이 발생합니다. 이 상황은 스토리지 클러스터 성능에 부정적인 영향을 미칠 수 있습니다.

보안 등급

높음

중요

네트워크 문제가 있는지 확인합니다. 네트워크 문제가 있는 경우 다음 문제 해결 단계를 진행하기 전에 OpenShift Data Foundation 팀으로 에스컬레이션해야 합니다.

진단

Ceph MON 쿼리를 복원합니다. 자세한 내용은 문제 해결 가이드 의 OpenShift Data Foundation에서 ceph-monitor 쿼럼 복구를 참조하십시오. Ceph MON 분기의 복원이 실패하면 일반 Pod 문제 해결에 따라 문제를 해결합니다.

또는 일반 Pod 문제 해결을 수행합니다.

Pod 상태: pending
  1. 리소스 문제, 보류 중인 PVC(영구 볼륨 클레임), 노드 할당 및 kubelet 문제를 확인합니다.

    $ oc project openshift-storage
    oc get pod | grep {ceph-component}
  2. 문제 Pod로 식별되는 Pod의 변수로 MYPOD 를 설정합니다.

    # Examine the output for a {ceph-component}  that is in the pending state, not running or not ready
    MYPOD=<pod_name>
    <pod_name>
    문제 Pod로 식별되는 Pod의 이름을 지정합니다.
  3. 리소스 제한 또는 보류 중인 PVC를 찾습니다. 또는 노드 할당을 확인합니다.

    $ oc get pod/${MYPOD} -o wide
Pod 상태: 보류 중이 아니라 실행 중이지만 준비되지 않음
  • 준비 상태 프로브를 확인합니다.
$ oc describe pod/${MYPOD}
Pod 상태: 보류 중이 아니지만 실행 중이 아닙니다.
  • 애플리케이션 또는 이미지 문제가 있는지 확인합니다.
$ oc logs pod/${MYPOD}
중요

노드가 할당된 경우 노드에서 kubelet을 확인합니다.

완화 방법

디버깅 로그 정보
  • 이 단계는 선택 사항입니다. 다음 명령을 실행하여 Ceph 클러스터에 대한 디버깅 정보를 수집합니다.
$ oc adm must-gather --image=registry.redhat.io/odf4/odf-must-gather-rhel9:v4.13

6.3.13. CephMonVersionMismatch

의미

일반적으로 이 경고는 업그레이드 중에 시간이 오래 걸리는 동안 트리거됩니다.

보안 등급

중간

진단

ocs-operator 서브스크립션 상태 및 Operator Pod 상태를 확인하여 Operator 업그레이드가 진행 중인지 확인합니다.

  1. ocs-operator 서브스크립션 상태를 확인합니다.

    $ oc get sub $(oc get pods -n openshift-storage | grep -v ocs-operator) -n openshift-storage -o json | jq .status.conditions

    상태 조건 유형은 CatalogSourcesUnhealthy,InstallPlanMissing,InstallPlanPending, InstallPlanFailed 입니다. 각 유형의 상태는 False 여야 합니다.

    출력 예:

    [
      {
        "lastTransitionTime": "2021-01-26T19:21:37Z",
        "message": "all available catalogsources are healthy",
        "reason": "AllCatalogSourcesHealthy",
        "status": "False",
        "type": "CatalogSourcesUnhealthy"
      }
    ]

    예제 출력에는 CatalogSourcesUnHealthly 유형의 False 상태가 표시되며 이는 카탈로그 소스가 정상임을 의미합니다.

  2. OCS Operator Pod 상태를 확인하여 OCS Operator 업그레이드가 진행 중인지 확인합니다.

    $ oc get pod -n openshift-storage | grep ocs-operator OCSOP=$(oc get pod -n openshift-storage -o custom-columns=POD:.metadata.name --no-headers | grep ocs-operator) echo $OCSOP oc get pod/${OCSOP} -n openshift-storage oc describe pod/${OCSOP} -n openshift-storage

    'ocs-operator'is가 진행 중인 것으로 확인되면 5분 정도 기다렸다가 이 경고가 자체적으로 해결되어야 합니다. 대기 중이거나 다른 오류 상태 조건이 표시되면 문제 해결을 계속합니다.

완화 방법

디버깅 로그 정보
  • 이 단계는 선택 사항입니다. 다음 명령을 실행하여 Ceph 클러스터에 대한 디버깅 정보를 수집합니다.

    $ oc adm must-gather --image=registry.redhat.io/odf4/odf-must-gather-rhel9:v4.13

6.3.14. CephNodeDown

의미

Ceph pod를 실행하는 노드가 중단됩니다. 노드 장애를 처리하도록 Ceph가 설계되었으므로 스토리지 작업이 계속 작동하지만 다른 노드의 위험을 최소화하고 스토리지 기능에 영향을 미치는 문제를 해결하는 것이 좋습니다.

보안 등급

중간

진단

  1. 실행 중이고 실패하는 모든 Pod를 나열합니다.

    oc -n openshift-storage get pods
    중요

    OSD(Object Storage Device) Pod가 새 노드에 예약되도록 OpenShift Data Foundation 리소스 요구 사항을 충족하는지 확인합니다. Ceph 클러스터가 실패하고 OSD를 복구하기 위해 데이터를 복구하면 몇 분 정도 걸릴 수 있습니다. 이 복구가 작동하는 것을 모니터링하려면 OSD Pod가 새 작업자 노드에 올바르게 배치되었는지 확인합니다.

  2. 이전에 오류가 발생한 OSD Pod가 실행 중인지 확인합니다.

    oc -n openshift-storage get pods

    이전에 실패한 OSD Pod가 예약되지 않은 경우 describe 명령을 사용하여 Pod가 다시 예약되지 않은 이유로 이벤트를 확인합니다.

  3. 실패한 OSD Pod의 이벤트를 설명합니다.

    oc -n openshift-storage get pods | grep osd
  4. 하나 이상의 실패한 OSD Pod를 찾습니다.

    oc -n openshift-storage describe pods/<osd_podname_ from_the_ previous step>

    events 섹션에서 리소스가 충족되지 않는 등의 실패 이유를 찾습니다.

    또한 rook-ceph-toolbox 를 사용하여 복구를 확인할 수 있습니다. 이 단계는 선택 사항이지만 대규모 Ceph 클러스터에 유용합니다. toolbox에 액세스하려면 다음 명령을 실행합니다.

    TOOLS_POD=$(oc get pods -n openshift-storage -l app=rook-ceph-tools -o name)
    oc rsh -n openshift-storage $TOOLS_POD

    rsh 명령 프롬프트에서 다음을 실행하고 io 섹션에서 "recovery"를 확인합니다.

    ceph status
  5. 실패한 노드가 있는지 확인합니다.

    1. 작업자 노드 목록을 가져오고 노드 상태를 확인합니다.

      oc get nodes --selector='node-role.kubernetes.io/worker','!node-role.kubernetes.io/infra'
    2. 실패에 대한 자세한 정보를 얻으려면 NotReady 상태에 해당하는 노드를 설명합니다.

      oc describe node <node_name>

완화 방법

디버깅 로그 정보
  • 이 단계는 선택 사항입니다. 다음 명령을 실행하여 Ceph 클러스터에 대한 디버깅 정보를 수집합니다.

    $ oc adm must-gather --image=registry.redhat.io/odf4/odf-must-gather-rhel9:v4.13

6.3.15. CephOSDCriticallyFull

의미

OSD(오브젝트 스토리지 장치) 중 하나가 심각합니다. 클러스터를 즉시 확장합니다.

보안 등급

높음

진단

스토리지 공간을 확보하기 위해 데이터 삭제
데이터를 삭제할 수 있으며 클러스터는 자체 복구 프로세스를 통해 경고를 해결합니다.
중요

이는 거의 또는 전체 있지만 읽기 전용 모드가 아닌 OpenShift Data Foundation 클러스터에만 적용할 수 있습니다. 읽기 전용 모드에서는 데이터 삭제, 즉 PVC(영구 볼륨 클레임), 영구 볼륨(PV) 또는 둘 다 삭제가 포함된 변경을 방지합니다.

스토리지 용량 확장
현재 스토리지 크기는 1TB 미만입니다.

먼저 확장 가능성을 평가해야 합니다. 1TB의 스토리지를 추가할 때마다 클러스터에 사용 가능한 최소 2개의 vCPU 및 8GiB 메모리가 있는 노드가 각각 3개 있어야 합니다.

애드온을 통해 스토리지 용량을 4TB로 늘릴 수 있으며 클러스터는 자체 복구 프로세스를 통해 경고를 해결합니다. 최소 vCPU 및 메모리 리소스 요구 사항이 충족되지 않으면 클러스터에 작업자 노드를 3개 더 추가해야 합니다.

완화 방법

  • 현재 스토리지 크기가 4TB인 경우 Red Hat 지원에 문의하십시오.
  • 선택 사항: 다음 명령을 실행하여 Ceph 클러스터에 대한 디버깅 정보를 수집합니다.

    $ oc adm must-gather --image=registry.redhat.io/odf4/odf-must-gather-rhel9:v4.13

6.3.16. CephOSDDiskNotResponding

의미

디스크 장치가 응답하지 않습니다. 모든 OSD(오브젝트 스토리지 장치)가 실행 중인지 확인합니다.

보안 등급

중간

진단

Pod 상태: pending
  1. 리소스 문제, 보류 중인 PVC(영구 볼륨 클레임), 노드 할당 및 kubelet 문제를 확인합니다.

    $ oc project openshift-storage
    $ oc get pod | grep rook-ceph
  2. 문제 Pod로 식별되는 Pod의 변수로 MYPOD 를 설정합니다.

    # Examine the output for a rook-ceph that is in the pending state, not running or not ready
    MYPOD=<pod_name>
    <pod_name>
    문제 Pod로 식별되는 Pod의 이름을 지정합니다.
  3. 리소스 제한 또는 보류 중인 PVC를 찾습니다. 또는 노드 할당을 확인합니다.

    $ oc get pod/${MYPOD} -o wide
Pod 상태: 보류 중이 아니라 실행 중이지만 준비되지 않음
  • 준비 상태 프로브를 확인합니다.

    $ oc describe pod/${MYPOD}
Pod 상태: 보류 중이 아니지만 실행 중이 아닙니다.
  • 애플리케이션 또는 이미지 문제가 있는지 확인합니다.

    $ oc logs pod/${MYPOD}
    중요
    • 노드가 할당된 경우 노드에서 kubelet을 확인합니다.
    • 실행 중인 Pod의 기본 상태가 확인되면 노드의 노드 유사성 및 리소스 가용성이 확인되면 Ceph 툴을 실행하여 스토리지 구성 요소의 상태를 가져옵니다.

완화 방법

디버깅 로그 정보
  • 이 단계는 선택 사항입니다. 다음 명령을 실행하여 Ceph 클러스터에 대한 디버깅 정보를 수집합니다.

    $ oc adm must-gather --image=registry.redhat.io/odf4/odf-must-gather-rhel9:v4.13

6.3.17. CephOSDDiskUnavailable

의미

호스트 중 하나에서 디스크 장치에 액세스할 수 없으며 해당 OSD(Object Storage Device)는 Ceph 클러스터에 의해 표시됩니다. 이 경고는 Ceph 노드를 10분 이내에 복구하지 못할 때 발생합니다.

보안 등급

높음

진단

실패한 노드 확인
  1. 작업자 노드 목록을 가져오고 노드 상태를 확인합니다.
oc get nodes --selector='node-role.kubernetes.io/worker','!node-role.kubernetes.io/infra'
  1. 실패에 대한 자세한 정보를 얻으려면 NotReady 상태인 노드를 설명합니다.

    oc describe node <node_name>

6.3.18. CephOSDFlapping

의미

스토리지 데몬은 지난 5분 동안 5번 재시작했습니다. Pod 이벤트 또는 Ceph 상태를 확인하여 원인을 확인합니다.

보안 등급

높음

진단

Red Hat Ceph Storage 문제 해결 가이드의 Flapping OSDs 섹션에 있는 단계를 따르십시오.

또는 일반 pod troublshooting에 대한 단계를 수행합니다.

Pod 상태: pending
  1. 리소스 문제, 보류 중인 PVC(영구 볼륨 클레임), 노드 할당 및 kubelet 문제를 확인합니다.

    $ oc project openshift-storage
    $ oc get pod | grep rook-ceph
  2. 문제 Pod로 식별되는 Pod의 변수로 MYPOD 를 설정합니다.

    # Examine the output for a rook-ceph that is in the pending state, not running or not ready
    MYPOD=<pod_name>
    <pod_name>
    문제 Pod로 식별되는 Pod의 이름을 지정합니다.
  3. 리소스 제한 또는 보류 중인 PVC를 찾습니다. 또는 노드 할당을 확인합니다.

    $ oc get pod/${MYPOD} -o wide
Pod 상태: 보류 중이 아니라 실행 중이지만 준비되지 않음
  • 준비 상태 프로브를 확인합니다.

    $ oc describe pod/${MYPOD}
Pod 상태: 보류 중이 아니지만 실행 중이 아닙니다.
  • 애플리케이션 또는 이미지 문제가 있는지 확인합니다.

    $ oc logs pod/${MYPOD}
    중요
    • 노드가 할당된 경우 노드에서 kubelet을 확인합니다.
    • 실행 중인 Pod의 기본 상태가 확인되면 노드의 노드 유사성 및 리소스 가용성이 확인되면 Ceph 툴을 실행하여 스토리지 구성 요소의 상태를 가져옵니다.

완화 방법

디버깅 로그 정보
  • 이 단계는 선택 사항입니다. 다음 명령을 실행하여 Ceph 클러스터에 대한 디버깅 정보를 수집합니다.

    $ oc adm must-gather --image=registry.redhat.io/odf4/odf-must-gather-rhel9:v4.13

6.3.19. CephOSDNearFull

의미

호스트에서 백엔드 스토리지 장치 OSD(Object Storage Device)의 사용률이 75% 이상 증가했습니다.

보안 등급

높음

완화 방법

클러스터의 일부 공간을 확보하거나 스토리지 클러스터를 확장하거나 Red Hat 지원에 문의하십시오. 스토리지 확장에 대한 자세한 내용은 스토리지 확장 가이드를 참조하십시오.

6.3.20. CephOSDSlowOps

의미

느린 요청이 있는 OSD(오브젝트 스토리지 장치)는 osd_op_complaint_time 매개변수에 정의된 시간 내에 대기열에서 IOPS(I/O 작업당 I/O 작업 수)를 처리할 수 없는 모든 OSD입니다. 기본적으로 이 매개변수는 30초로 설정됩니다.

보안 등급

중간

진단

Openshift 콘솔을 사용하여 느린 요청에 대한 자세한 정보를 얻을 수 있습니다.

  1. OSD Pod 터미널에 액세스하여 다음 명령을 실행합니다.

    $ ceph daemon osd.<id> ops
    $ ceph daemon osd.<id> dump_historic_ops
    참고

    OSD의 수는 포드 이름에 표시됩니다. 예를 들어 rook-ceph-osd-0-5d86d4d8d4-zlqkx 에서 &lt;0& gt;은 OSD입니다.

완화 방법

요청 속도가 느린 OSD의 주요 원인은 * 디스크 드라이브, 호스트, 랙 또는 네트워크 스위치와 같은 기본 하드웨어 또는 인프라 문제입니다. Openshift 모니터링 콘솔을 사용하여 클러스터 리소스에 대한 경고 또는 오류를 찾습니다. 이를 통해 OSD에서 느린 작업의 근본 원인에 대한 아이디어를 얻을 수 있습니다. * 네트워크에 문제가 있습니다. 이러한 문제는 일반적으로 OSD 플로팅과 연결되어 있습니다. Red Hat Ceph Storage Troubleshooting Guide의 Flapping OSDs 섹션을 참조하십시오. * 네트워크 문제인 경우 OpenShift Data Foundation 팀 * 시스템 로드로 에스컬레이션됩니다. Openshift 콘솔을 사용하여 OSD pod 및 OSD를 실행 중인 노드의 지표를 검토합니다. 더 많은 리소스를 추가하거나 할당하는 것이 가능한 솔루션이 될 수 있습니다.

6.3.21. CephOSDVersionMismatch

의미

일반적으로 이 경고는 업그레이드 중에 시간이 오래 걸리는 동안 트리거됩니다.

보안 등급

중간

진단

ocs-operator 서브스크립션 상태 및 Operator Pod 상태를 확인하여 Operator 업그레이드가 진행 중인지 확인합니다.

  1. ocs-operator 서브스크립션 상태를 확인합니다.

    $ oc get sub $(oc get pods -n openshift-storage | grep -v ocs-operator) -n openshift-storage -o json | jq .status.conditions

    상태 조건 유형은 CatalogSourcesUnhealthy,InstallPlanMissing,InstallPlanPending, InstallPlanFailed 입니다. 각 유형의 상태는 False 여야 합니다.

    출력 예:

    [
      {
        "lastTransitionTime": "2021-01-26T19:21:37Z",
        "message": "all available catalogsources are healthy",
        "reason": "AllCatalogSourcesHealthy",
        "status": "False",
        "type": "CatalogSourcesUnhealthy"
      }
    ]

    예제 출력에는 CatalogSourcesUnHealthly 유형의 False 상태가 표시되며 이는 카탈로그 소스가 정상임을 의미합니다.

  2. OCS Operator Pod 상태를 확인하여 OCS Operator 업그레이드가 진행 중인지 확인합니다.

    $ oc get pod -n openshift-storage | grep ocs-operator OCSOP=$(oc get pod -n openshift-storage -o custom-columns=POD:.metadata.name --no-headers | grep ocs-operator) echo $OCSOP oc get pod/${OCSOP} -n openshift-storage oc describe pod/${OCSOP} -n openshift-storage

    'ocs-operator'is가 진행 중인 것으로 확인되면 5분 정도 기다렸다가 이 경고가 자체적으로 해결되어야 합니다. 대기 중이거나 다른 오류 상태 조건이 표시되면 문제 해결을 계속합니다.

6.3.22. CephPGRepairTakingTooLong

의미

자동 복구 작업이 너무 오래 걸립니다.

보안 등급

높음

진단

일치하지 않는 PG(배치 그룹)를 확인하고 복구합니다. 자세한 내용은 Ceph의 Red Hat 지식베이스 솔루션 처리기 Inconsistent Placement Groups 를 참조하십시오.

6.3.23. CephPoolQuotaBytesCriticallyExhausted

의미

하나 이상의 풀에 도달했거나 할당량에 매우 가깝습니다. 이 오류 조건을 트리거하는 임계값은 mon_pool_quota_crit_threshold 구성 옵션에 의해 제어됩니다.

보안 등급

높음

완화 방법

풀 할당량을 조정합니다. 다음 명령을 실행하여 풀 할당량을 완전히 제거하거나 축소합니다.

ceph osd pool set-quota <pool> max_bytes <bytes>
ceph osd pool set-quota <pool> max_objects <objects>

할당량 값을 0 으로 설정하면 할당량이 비활성화됩니다.

6.3.24. CephPoolQuotaBytesNearExhaustion

의미

하나 이상의 풀이 구성된 풀 임계값에 도달하고 있습니다. 이 경고 조건을 트리거할 수 있는 임계값 중 하나는 mon_pool_quota_warn_threshold 구성 옵션입니다.

보안 등급

높음

완화 방법

풀 할당량을 조정합니다. 다음 명령을 실행하여 풀 할당량을 완전히 제거하거나 축소합니다.

ceph osd pool set-quota <pool> max_bytes <bytes>
ceph osd pool set-quota <pool> max_objects <objects>

할당량 값을 0 으로 설정하면 할당량이 비활성화됩니다.

6.3.25. PersistentVolumeUsageCritical

의미

PVC(영구 볼륨 클레임)는 전체 용량에 도달하고 있으며 적시에 참석하지 않으면 데이터 손실이 발생할 수 있습니다.

보안 등급

높음

완화 방법

PVC 크기를 확장하여 용량을 늘립니다.

  1. OpenShift 웹 콘솔에 로그인합니다.
  2. 스토리지PersistentVolumeClaim 을 클릭합니다.
  3. 프로젝트 드롭다운 목록에서 openshift-storage 를 선택합니다.
  4. 확장하려는 PVC에서 작업 메뉴(ECDHE) → PVC 확장을 클릭합니다.
  5. 전체 크기를 원하는 크기로 업데이트합니다.
  6. Expand 를 클릭합니다.

또는 공간을 차지하고 있을 수 있는 불필요한 데이터를 삭제할 수 있습니다.

6.3.26. PersistentVolumeUsageNearFull

의미

PVC(영구 볼륨 클레임)는 전체 용량에 도달하고 있으며 적시에 참석하지 않으면 데이터 손실이 발생할 수 있습니다.

보안 등급

높음

완화 방법

PVC 크기를 확장하여 용량을 늘립니다.

  1. OpenShift 웹 콘솔에 로그인합니다.
  2. 스토리지PersistentVolumeClaim 을 클릭합니다.
  3. 프로젝트 드롭다운 목록에서 openshift-storage 를 선택합니다.
  4. 확장하려는 PVC에서 작업 메뉴(ECDHE) → PVC 확장을 클릭합니다.
  5. 전체 크기를 원하는 크기로 업데이트합니다.
  6. Expand 를 클릭합니다.

또는 공간을 차지하고 있을 수 있는 불필요한 데이터를 삭제할 수 있습니다.

6.4. NooBaa Bucket 오류 상태 해결

절차

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

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

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

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

6.5. NooBaa Bucket Exceeding Quota State

A NooBaa Bucket을 해결하려면 할당량 상태 오류가 발생한 경우 다음 중 하나를 수행합니다.

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

    1. OpenShift 웹 콘솔에서 스토리지데이터 기반 을 클릭합니다.
    2. 개요 탭의 상태 카드에서 스토리지 시스템을 클릭한 다음 해당 팝업에서 스토리지 시스템 링크를 클릭합니다.
    3. 오브젝트 탭을 클릭합니다.
    4. 세부 정보 카드에서 시스템 이름 필드에 있는 링크를 클릭합니다.
    5. 왼쪽 창에서 Buckets 옵션을 클릭하고 error 상태에서 버킷을 검색합니다.
    6. 버킷 이름을 클릭합니다. 버킷에서 발생한 오류가 표시됩니다.
    7. Bucket PoliciesEdit Quotas 를 클릭하고 할당량을 늘립니다.

6.6. NooBaa Bucket capacity 또는 Quota State 확인

절차

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

6.7. Pod 복구

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

절차

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

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

6.8. EBS 볼륨 분리에서 복구

OSD 디스크가 작업자 Amazon EC2 인스턴스에서 분리된 OSD 또는 MON 탄력적 블록 스토리지(EBS) 볼륨이 있으면 볼륨은 1분에서 2분 이내에 자동으로 다시 연결됩니다. 그러나 OSD Pod는 CrashLoopBackOff 상태가 됩니다. Pod를 복구하고 Running 상태로 되돌리려면 EC2 인스턴스를 다시 시작해야 합니다.

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

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

절차

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

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

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

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

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

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

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

6.10. 비정상 차단 노드 문제 해결

6.10.1. ODFRBDClientBlocked

의미

이 경고는 Kubernetes 클러스터 내의 특정 노드에서 Ceph에서 RBD 클라이언트가 차단될 수 있음을 나타냅니다. blocklisting은 ocs_rbd_client_blocklisted 지표 에서 노드의 1 값을 보고할 때 발생합니다. 또한 동일한 노드의 CreateContainerError 상태에 Pod가 있습니다. blocklisting은 RBD를 사용하는 PVC(영구 볼륨 클레임)의 파일 시스템이 읽기 전용으로 될 수 있습니다. 스토리지 클러스터가 중단되지 않도록 이 경고를 조사하는 것이 중요합니다.

보안 등급

높음

진단

RBD 클라이언트의 차단 목록은 네트워크 또는 클러스터 속도 저하와 같은 여러 요인으로 인해 발생할 수 있습니다. 경우에 따라 3개의 연속 클라이언트(워크로드, 미러 데몬, manager/scheduler) 간의 독점 잠금 경합이 블록 목록으로 이어질 수 있습니다.

완화 방법

  1. 블록 목록에 있는 노드 테인트: Kubernetes에서 Pod 제거를 다른 노드로 트리거하기 위해 차단 목록에 있는 노드를 테인트하는 것이 좋습니다. 이 접근 방식은 마운트 해제 / 매핑되지 않은 프로세스가 정상적으로 진행된다는 가정에 따라 달라집니다. Pod가 성공적으로 제거되면 blocklisted 노드를tainted 상태로 설정하여 블록 목록을 삭제할 수 있습니다. 그런 다음 Pod를 오염되지 않은 노드로 이동할 수 있습니다.
  2. 블록 목록에 있는 노드 재부팅: 노드에 테인트하고 Pod를 제거해도 차단 목록에 있는 노드가 해결되지 않으면 차단된 노드를 재부팅할 수 있습니다. 이 단계는 블록 목록을 유발하는 모든 근본적인 문제를 완화하고 정상적인 기능을 복원하는 데 도움이 될 수 있습니다.
중요

블록 목록 문제를 신속하게 조사하고 해결하는 것은 스토리지 클러스터에 대한 추가 영향을 방지하기 위해 필요합니다.

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는 스토리지 클래스 로컬 블록을 사용합니다. 출력은 다음과 유사합니다.

    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장. 실패한 Ceph Object Storage 장치 제거

실패하거나 원하지 않는 Ceph OSD(Object Storage Devices)는 스토리지 인프라의 성능에 영향을 미칩니다. 따라서 스토리지 클러스터의 안정성과 복원력을 개선하려면 실패하거나 원하지 않는 Ceph OSD를 제거해야 합니다.

Ceph OSD가 실패하거나 원하지 않는 경우 다음을 제거합니다.

  1. Ceph 상태를 확인합니다.

    자세한 내용은 Ceph 클러스터의 정상 확인에서 참조하십시오.

  2. OSD의 프로비저닝에 따라 실패하거나 원하지 않는 Ceph OSD를 제거합니다.

    다음 내용을 참조하십시오.

로컬 디스크를 사용하는 경우 이전 OSD를 제거한 후 이러한 디스크를 재사용할 수 있습니다.

8.1. Ceph 클러스터 상태 확인

스토리지 상태는 블록파일오브젝트 대시보드에 표시됩니다.

절차

  1. OpenShift 웹 콘솔에서 스토리지데이터 기반 을 클릭합니다.
  2. 개요 탭의 상태 카드에서 스토리지 시스템을 클릭한 다음 해당 팝업에서 스토리지 시스템 링크를 클릭합니다.
  3. 블록 및 파일 탭의 상태 카드에서 스토리지 클러스터에 녹색 체크 표시가 있는지 확인합니다.
  4. 세부 정보 카드에서 클러스터 정보가 표시되는지 확인합니다.

8.2. 동적으로 프로비저닝된 Red Hat OpenShift Data Foundation에서 실패 또는 원하지 않는 Ceph OSD 제거

프로세스의 단계에 따라 동적으로 프로비저닝된 Red Hat OpenShift Data Foundation에서 실패하거나 원하지 않는 Ceph OSD를 제거합니다.

중요

클러스터 축소는 Red Hat 지원 팀을 통해서만 지원됩니다.

주의
  • Ceph 구성 요소가 정상 상태가 아닌 경우 OSD를 제거하면 데이터가 손실될 수 있습니다.
  • 두 개 이상의 OSD를 동시에 제거하면 데이터가 손실됩니다.

사전 요구 사항

절차

  1. OSD 배포를 축소합니다.

    # oc scale deployment rook-ceph-osd-<osd-id> --replicas=0
  2. Ceph OSD를 제거할 osd-prepare Pod를 가져옵니다.

    # oc get deployment rook-ceph-osd-<osd-id> -oyaml | grep ceph.rook.io/pvc
  3. osd-prepare Pod를 삭제합니다.

    # oc delete -n openshift-storage pod rook-ceph-osd-prepare-<pvc-from-above-command>-<pod-suffix>
  4. 클러스터에서 실패한 OSD를 제거합니다.

    # failed_osd_id=<osd-id>
    
    # oc process -n openshift-storage ocs-osd-removal -p FAILED_OSD_IDS=$<failed_osd_id> | oc create -f -

    여기서 FAILED_OSD_IDrook-ceph-osd 접두사 직후 포드 이름의 정수입니다.

  5. 로그를 확인하여 OSD가 성공적으로 제거되었는지 확인합니다.

    # oc logs -n openshift-storage ocs-osd-removal-$<failed_osd_id>-<pod-suffix>
  6. 선택 사항: OpenShift Container Platform의 ocs- osd-removal-job Pod에서 삭제하는 데 cephosd:osd.0이 좋지 않아 오류가 발생하는 경우 cephosd:osd.0 오류 문제 해결을 참조하십시오. 실패하거나 원하지 않는 Ceph OSD를 제거하는 동안 제거되지 않음을 참조하십시오.
  7. OSD 배포를 삭제합니다.

    # oc delete deployment rook-ceph-osd-<osd-id>

검증 단계

  • OSD가 성공적으로 삭제되었는지 확인하려면 다음을 실행합니다.

    # oc get pod -n openshift-storage ocs-osd-removal-$<failed_osd_id>-<pod-suffix>

    이 명령은 상태를 Completed 로 반환해야 합니다.

8.3. 로컬 스토리지 장치를 사용하여 프로비저닝된 Ceph OSD 또는 실패한 Ceph OSD 제거

절차의 단계에 따라 로컬 스토리지 장치를 사용하여 프로비저닝된 실패 또는 원하지 않는 Ceph를 제거할 수 있습니다.

중요

클러스터 축소는 Red Hat 지원 팀을 통해서만 지원됩니다.

주의
  • Ceph 구성 요소가 정상 상태가 아닌 경우 OSD를 제거하면 데이터가 손실될 수 있습니다.
  • 두 개 이상의 OSD를 동시에 제거하면 데이터가 손실됩니다.

사전 요구 사항

절차

  1. 강제로 OSD 배포의 복제본을 0으로 확장하여 OSD를 축소합니다. 실패로 OSD가 이미 다운된 경우 이 단계를 건너뛸 수 있습니다.

    # oc scale deployment rook-ceph-osd-<osd-id> --replicas=0
  2. 클러스터에서 실패한 OSD를 제거합니다.

    # failed_osd_id=<osd_id>
    
    # oc process -n openshift-storage ocs-osd-removal -p FAILED_OSD_IDS=$<failed_osd_id> | oc create -f -

    여기서 FAILED_OSD_IDrook-ceph-osd 접두사 직후 포드 이름의 정수입니다.

  3. 로그를 확인하여 OSD가 성공적으로 제거되었는지 확인합니다.

    # oc logs -n openshift-storage ocs-osd-removal-$<failed_osd_id>-<pod-suffix>
  4. 선택 사항: OpenShift Container Platform의 ocs- osd-removal-job Pod에서 삭제하는 데 cephosd:osd.0이 좋지 않아 오류가 발생하는 경우 cephosd:osd.0 오류 문제 해결을 참조하십시오. 실패하거나 원하지 않는 Ceph OSD를 제거하는 동안 제거되지 않음을 참조하십시오.
  5. 실패한 OSD와 관련된 PVC(영구 볼륨 클레임) 리소스를 삭제합니다.

    1. 실패한 OSD와 연결된 PVC 를 가져옵니다.

      # oc get -n openshift-storage -o yaml deployment rook-ceph-osd-<osd-id> | grep ceph.rook.io/pvc
    2. PVC와 연결된 PV( 영구 볼륨 )를 가져옵니다.

      # oc get -n openshift-storage pvc <pvc-name>
    3. 실패한 장치 이름을 가져옵니다.

      # oc get pv <pv-name-from-above-command> -oyaml | grep path
    4. 실패한 OSD와 관련된 준비 Pod 를 가져옵니다.

      # oc describe -n openshift-storage pvc ocs-deviceset-0-0-nvs68 | grep Mounted
    5. 연결된 PVC를 제거하기 전에 osd-prepare Pod 를 삭제합니다.

      # oc delete -n openshift-storage pod <osd-prepare-pod-from-above-command>
    6. 실패한 OSD와 연결된 PVC 를 삭제합니다.

      # oc delete -n openshift-storage pvc <pvc-name-from-step-a>
  6. LocalVolume 사용자 정의 리소스 (CR)에서 실패한 장치 항목을 제거합니다.

    1. 실패한 장치를 사용하여 노드에 로그인합니다.

      # oc debug node/<node_with_failed_osd>
    2. 실패한 장치 이름에 대해 /dev/disk/by-id/<id>를 기록합니다.

      # ls -alh /mnt/local-storage/localblock/
  7. 선택 사항: Local Storage Operator가 OSD 프로비저닝에 사용되는 경우 {osd-id}로 머신에 로그인하고 장치 심볼릭 링크를 제거합니다.

    # oc debug node/<node_with_failed_osd>
    1. 실패한 장치 이름에 대한 OSD 심볼릭 링크를 가져옵니다.

      # ls -alh /mnt/local-storage/localblock
    2. 심볼릭 링크를 제거합니다.

      # rm /mnt/local-storage/localblock/<failed-device-name>
  8. OSD와 연결된 PV를 삭제합니다.
# oc delete pv <pv-name>

검증 단계

  • OSD가 성공적으로 삭제되었는지 확인하려면 다음을 실행합니다.

    #oc get pod -n openshift-storage ocs-osd-removal-$<failed_osd_id>-<pod-suffix>

    이 명령은 상태를 Completed 로 반환해야 합니다.

8.4. 실패하거나 원하지 않는 Ceph OSD를 제거하는 동안 cephosd:osd.0 오류 문제 해결

OpenShift Container Platform의 ocs- osd-removal-job Pod에서 제거하기 위해 cephosd:osd.0이 좋지 않아 오류가 발생하면 FORCE_OSD_REMOVAL 옵션으로 OSD 제거 작업을 실행하여 OSD를 삭제한 상태로 이동합니다.

# oc process -n openshift-storage ocs-osd-removal -p FORCE_OSD_REMOVAL=true -p FAILED_OSD_IDS=$<failed_osd_id> | oc create -f -
참고

FORCE_OSD_REMOVAL 옵션을 모든 PG가 활성 상태인 경우에만 사용해야 합니다. 그렇지 않은 경우 PG는 백 채우기를 완료하거나 활성 상태인지 확인해야 합니다.

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

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

  1. 삭제 시 openshift-storage 네임스페이스가 Terminating 상태로 설정되어 있는지 확인합니다.

    $ oc get project -n <namespace>

    출력:

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

    $ 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 지원에 문의하십시오.

10장. 외부 모드에서 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.volume.pvc-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxx: (1) Operation not permitted)입니다.

    # 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 데이터 풀 이름 >(여기서 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
    [...]

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

3개 모두 다운된 경우 모니터 Pod를 복원하고 OpenShift Data Foundation에서 모니터 Pod를 자동으로 복구할 수 없는 경우 이를 복원합니다.

참고

이는 재해 복구 절차이며 Red Hat 지원 팀의 지침에 따라 수행해야 합니다. Red Hat 지원 팀에 문의하려면 Red Hat 지원.

절차

  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 명령으로 명령 매개 변수를 사용하여 실행합니다.

    # 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 배포를 패치하고 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 포드로 이동하여 검색된 수도원의 소유권을 변경합니다.

    # 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 포드로 이동하여 monstoremonmap 이 있는지 확인합니다.

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

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

      # 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 포드의 ID입니다.
    <mon-a-ip>
    mon-a 포드의 IP 주소입니다.
    <mon-b-id>
    mon-b 포드의 ID입니다.
    <mon-b-ip>
    mon-b 포드의 IP 주소입니다.
    <mon-c-id>
    mon-c 포드의 ID입니다.
    <mon-c-ip>
    mon-c 포드의 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 Pod로 복사합니다.

    # 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 포드로 이동하여 복사한 수도원의 소유권을 변경합니다.

    # 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 배포 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 Pod가 실행 중인지 확인합니다.

  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
  2. MCG(Multicloud Object Gateway) 상태를 확인합니다. 이는 활성 상태여야 하며 backingstore 및 bucketclass는 Ready 상태여야 합니다.

    noobaa status -n openshift-storage
    중요

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

11.1. Multicloud Object Gateway 복원

MCG(Multicloud Object Gateway)가 활성 상태가 아니고 backingstore 및 bucketclass가 Ready 상태가 아닌 경우 모든 MCG 관련 Pod를 재시작하고 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 Object Gateway(RGW)가 구성된 경우 포드를 다시 시작합니다.

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

OpenShift Container Platform 4.11에서 복구 후 RBD PVC가 애플리케이션 Pod에 마운트되지 않습니다. 따라서 애플리케이션 Pod를 호스팅하는 노드를 다시 시작해야 합니다. 애플리케이션 Pod를 호스팅하는 노드 이름을 가져오려면 다음 명령을 실행합니다.

# oc get pods <application-pod> -n <namespace> -o yaml | grep nodeName
  nodeName: node_name

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

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

예를 들어 3개의 mons 가 있고 쿼럼이 손실되는 경우 쿼럼에서 두 개의 잘못된 마우스를 제거하고, 좋은 mon 에 쿼럼에서 유일한 mon 임을 알리고, 좋은 mon 을 다시 시작해야 합니다.

절차

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

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

    주의

    monmap 을 매우 신중하게 삽입해야 합니다. 잘못 실행하면 클러스터를 영구적으로 삭제할 수 있습니다. Ceph monmapmon 쿼럼을 추적합니다. monmap 은 정상 mon만 포함하도록 업데이트되었습니다. 이 예에서 정상 mon은 rook-ceph-mon-b 입니다. 비정상적인 monsrook-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
      참고

      ROOK_CEPH_MON_HOST 변수, ROOK_CEPH_MON_MON_MON_MON_MON_MON_INITIAL_MEMBERS 및 ROOK_POD_IP 관련 단일 따옴표를 제거해야 합니다.

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

      # 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 포드에서 다음 단계를 수행합니다.

      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} 플래그를 추가하여 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 \
               --extract-monmap=${monmap_path}
      4. monmap 의 내용을 검토합니다.

        # monmaptool --print /tmp/monmap
      5. mon map 에서 잘못된 마우스를 제거합니다.

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

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

        # monmaptool ${monmap_path} --rm a
        # monmaptool ${monmap_path} --rm c
      6. ceph mon 명령을 붙여넣고 --inject- monmap =${ mon map_path} 플래그를 다음과 같이 추가하여 수정된 monmap을 좋은 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. Operator에서 mons 를 추적하는 데 사용하는 configmap 을 편집합니다.

      # oc -n openshift-storage edit configmap rook-ceph-mon-endpoints
    2. 데이터 요소에서 다음과 같은 세 개의 mons (또는 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. mon 을 다시 시작합니다.

    원래 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 수에 따라 쿼럼 크기를 다시 늘리기 위해 더 많은 mons 를 자동으로 추가합니다.

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

Data Foundation 콘솔 플러그인은 기본적으로 활성화되어 있습니다. OpenShift Data Foundation Operator 설치 중에 이 옵션을 선택하지 않은 경우 다음 지침을 사용하여 그래픽 사용자 인터페이스(GUI) 또는 명령줄 인터페이스에서 콘솔 플러그인 후 배포를 활성화합니다.

사전 요구 사항

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

절차

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

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

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

검증 단계

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

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

14장. OpenShift Data Foundation 구성 요소의 리소스 변경

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

14.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 에서 28Gi 로 증가합니다.

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

    # oc edit storagecluster -n openshift-storage <storagecluster_name>
    <storagecluster_name>

    스토리지 클러스터의 이름을 지정합니다.

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

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

    스토리지 클러스터의 이름을 지정합니다.

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

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

14.2. MCG의 리소스 튜닝

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

15장. OpenShift Data Foundation 배포 후 Multicloud Object Gateway 외부 서비스 비활성화

OpenShift Data Foundation을 배포하면 OpenShift가 개인 클러스터로 설치된 경우에도 공용 IP가 생성됩니다. 그러나 storagecluster CRD에서 disableLoadBalancerService 변수를 사용하여 MCG(Multicloud Object Gateway) 로드 밸런서 사용을 비활성화할 수 있습니다. 이렇게 하면 MCG가 프라이빗 클러스터에 대한 공용 리소스를 생성하지 못하도록 제한하며 NooBaa 서비스 EXTERNAL-IP 를 비활성화하는 데 도움이 됩니다.

절차

  • 다음 명령을 실행하고 storagecluster YAML에서 disableLoadBalancerService varialbe를 추가하여 서비스를 ClusterIP로 설정합니다.

    $ oc edit storagecluster -n openshift-storage <storagecluster_name>
    [...]
    spec:
      arbiter: {}
      encryption:
        kms: {}
      externalStorage: {}
      managedResources:
        cephBlockPools: {}
        cephCluster: {}
        cephConfig: {}
        cephDashboard: {}
        cephFilesystems: {}
        cephNonResilientPools: {}
        cephObjectStoreUsers: {}
        cephObjectStores: {}
        cephRBDMirror: {}
        cephToolbox: {}
      mirroring: {}
      multiCloudGateway:
        disableLoadBalancerService: true       <--------------- Add this
        endpoints:
    [...]
    참고

    변경 사항을 취소하고 서비스를 LoadBalancer로 설정하려면 disableLoadBalancerService 변수를 false 로 설정하거나 해당 행을 완전히 제거합니다.

16장. 글로벌 Pod 네트워킹을 수동으로 활성화하여 ovs-multitenant 플러그인을 사용하여 odf-console 에 액세스

OpenShift Container Platform에서 ovs-multitenant 플러그인을 소프트웨어 정의 네트워킹(SDN)에 사용하는 경우 다른 프로젝트의 Pod는 다른 프로젝트의 포드 및 서비스에서 패킷을 보내거나 받을 수 없습니다. 프로젝트의 Pod 네트워킹이 글로벌 상태가 아니므로 기본적으로 Pod는 네임스페이스 또는 프로젝트 간에 통신할 수 없습니다.

odf-console에 액세스하려면 openshift-console 네임스페이스의 OpenShift 콘솔 포드가 openshift-storage 네임스페이스의 OpenShift Data Foundation odf-console에 연결되어 있어야 합니다. 이는 글로벌 Pod 네트워킹을 수동으로 사용하는 경우에만 가능합니다.

문제

  • OpenShift Container Platform에서'ovs-multitenant' 플러그인이 사용되는 경우 다음 메시지와 함께 odf-console 플러그인이 실패합니다.

    GET request for "odf-console" plugin failed: Get "https://odf-console-service.openshift-storage.svc.cluster.local:9001/locales/en/plugin__odf-console.json": context deadline exceeded (Client.Timeout exceeded while awaiting headers)

해결

  • OpenShift Data Foundation 프로젝트의 포드 네트워킹을 글로벌로 설정합니다.

    $ oc adm pod-network make-projects-global openshift-storage