문제 해결 가이드

Red Hat Ceph Storage 4

Red Hat Ceph Storage 문제 해결

Red Hat Ceph Storage Documentation Team

초록

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

1장. 초기 문제 해결

이 장에서는 다음에 대한 정보를 제공합니다.

1.1. 사전 요구 사항

  • 실행 중인 Red Hat Ceph Storage 클러스터.

1.2. 문제 식별

Red Hat Ceph Storage 클러스터에서 오류의 가능한 원인을 확인하려면 Procedure 섹션의 질문에 대답하십시오.

사전 요구 사항

  • 실행 중인 Red Hat Ceph Storage 클러스터.

절차

  1. 지원되지 않는 구성을 사용할 때 특정 문제가 발생할 수 있습니다. 구성이 지원되는지 확인합니다.

  2. Ceph 구성 요소에서 어떤 문제가 발생하는지 알고 계십니까?

    1. 아니요. Red Hat Ceph Storage 문제 해결 가이드의 Ceph스토리지 클러스터 상태 진단을 따르십시오.
    2. Ceph 모니터. Red Hat Ceph Storage 문제 해결 가이드의 Ceph Monitors 문제 해결 섹션을 참조하십시오.
    3. Ceph OSD. Red Hat Ceph Storage 문제 해결 가이드의 Ceph OSD 문제 해결 섹션을 참조하십시오.
    4. Ceph 배치 그룹. Red Hat Ceph Storage Troubleshooting Guide의 Ceph 배치 그룹 문제 해결 섹션을 참조하십시오.
    5. 다중 사이트 Ceph 개체 게이트웨이. Red Hat Ceph Storage 문제 해결 가이드의 다중 사이트 Ceph 개체 게이트웨이 문제 해결 섹션을 참조하십시오.

추가 리소스

1.2.1. 스토리지 클러스터의 상태 진단

다음 절차에서는 Red Hat Ceph Storage 클러스터의 상태를 진단하기 위한 기본 단계를 설명합니다.

사전 요구 사항

  • 실행 중인 Red Hat Ceph Storage 클러스터.

절차

  1. 스토리지 클러스터의 전체 상태를 확인합니다. 

    [root@mon ~]# ceph health detail

    명령에서 HEALTH_WARN 또는 HEALTH_ ERR 을 반환하는 경우 자세한 내용은 Ceph 상태 이해를 참조하십시오.

  2. Ceph 로그 이해에 나열된 오류 메시지가 있는지 Ceph 로그를 확인합니다. 로그는 기본적으로 /var/log/ceph/ 디렉터리에 있습니다.
  3. 로그에 충분한 양의 정보가 포함되지 않으면 디버깅 수준을 높이고 실패한 작업을 재현합니다. 자세한 내용은 로깅 구성을 참조하십시오.

1.3. Ceph 상태 이해

ceph 상태 명령은 Red Hat Ceph Storage 클러스터의 상태에 대한 정보를 반환합니다.

  • HEALTH_OK 는 클러스터가 정상임을 나타냅니다.
  • HEALTH_WARN 은 경고를 나타냅니다. 경우에 따라 Ceph 상태가 HEALTH_OK 로 자동으로 반환되는 경우도 있습니다. 예를 들어 Red Hat Ceph Storage 클러스터가 리밸런싱 프로세스를 완료한 경우입니다. 그러나 클러스터가 HEALTH_WARN 상태에 더 긴 경우 추가 문제 해결을 고려하십시오.
  • HEALTH_ERR 은 즉각적인 주의가 필요한 보다 심각한 문제를 나타냅니다.

보다 자세한 출력을 얻으려면 ceph 상태 세부 정보와 ceph -s 명령을 사용합니다.

추가 리소스

1.4. Ceph 로그 이해

1.4.1. 컨테이너화된 배포가 아닌

기본적으로 Ceph는 해당 로그를 /var/log/ceph/ 디렉터리에 저장합니다.

The CLUSTER_NAME.log 는 글로벌 이벤트가 포함된 기본 스토리지 클러스터 로그 파일입니다. 기본적으로 로그 파일 이름은 ceph.log 입니다. Ceph Monitor 노드에만 기본 스토리지 클러스터 로그가 포함됩니다.

각 Ceph OSD 및 Monitor에는 CLUSTER_NAME-osd.NUMBER.log 및 CLUSTER_NAME-mon.HOSTNAME.log 라는 자체 로그 파일이 있습니다.

Ceph 하위 시스템의 디버깅 수준을 늘리면 Ceph는 해당 하위 시스템에 대한 새 로그 파일도 생성합니다.

1.4.2. 컨테이너 기반 배포

컨테이너 기반 배포의 경우 기본적으로 Ceph 로그는 journald 에 기록되어 journactl 명령을 사용하여 액세스할 수 있습니다. 그러나 구성 설정에서 /var/log/ceph 에 있는 파일에 로그인하도록 Ceph를 구성할 수 있습니다.

  1. Ceph Monitor, Ceph Manager, Ceph Object Gateway 및 기타 데몬 로깅을 활성화하려면 [global] 설정에서 log_to_file 을 true 로 설정합니다.

    예제

    [ceph: root@host01 ~]# ceph config set global log_to_file true

  2. Ceph Monitor 클러스터 및 감사 로그에 대한 로깅을 활성화하려면 mon_cluster_log_to_file 을 true 로 설정합니다.

    예제

    [ceph: root@host01 ~]# ceph config set mon mon_cluster_log_to_file true

참고

파일에 기록하도록 선택하는 경우 journald 에 로깅을 비활성화하거나 다른 모든 항목이 두 번 기록되는 것이 좋습니다. 다음 명령을 실행하여 journald 에 대한 로깅을 비활성화합니다. 

# ceph config set global log_to_journald false
# ceph config set global mon_cluster_log_to_journald false

추가 리소스

1.5. Ansible을 사용하여 Ceph 클러스터에서 여러 호스트에서 로그 수집

Red Hat Ceph Storage 4.2부터 ceph- anible을 사용하여 Ceph 클러스터의 여러 호스트에서 로그를 수집할 수 있습니다. Ceph 노드에서 etc/ceph 및 /var/log/ceph 디렉터리를 캡처합니다. 이 플레이북은 베어 메탈 및 컨테이너화된 스토리지 클러스터에 대한 로그를 수집하는 데 사용할 수 있습니다.

사전 요구 사항

  • 실행 중인 Red Hat Ceph Storage 클러스터.
  • 노드에 대한 루트 수준 액세스입니다.
  • ceph-ansible 패키지가 노드에 설치되어 있습니다.

절차

  1. Ansible 관리 노드에 ansible 사용자로 로그인합니다.

    참고

    노드에 호스트에서 로그를 수집할 수 있는 충분한 공간이 있는지 확인합니다.

  2. /usr/share/ceph-ansible 디렉터리로 이동합니다.

    예제

    [ansible@admin ~]# cd /usr/share/ceph-ansible

  3. Ansible 플레이북을 실행하여 로그를 수집합니다.

    예제

    ansible@admin ceph-ansible]$ ansible-playbook infrastructure-playbooks/gather-ceph-logs.yml -i hosts

    로그는 Ansible 노드의 /tmp 디렉터리에 저장됩니다.

2장. 로깅 구성

이 장에서는 다양한 Ceph 하위 시스템에 대한 로깅을 구성하는 방법에 대해 설명합니다.

중요

로깅은 리소스를 많이 사용합니다. 또한 자세한 로깅을 통해 상대적으로 짧은 시간에 많은 양의 데이터를 생성할 수 있습니다. 클러스터의 특정 하위 시스템에서 문제가 발생하면 해당 하위 시스템의 로깅만 활성화합니다. 자세한 내용은 2.2절. “Ceph 하위 시스템”를 참조하십시오.

또한 로그 파일의 순환을 설정하는 것이 좋습니다. 자세한 내용은 2.5절. “로그 교체 가속화” 을 참조하십시오.

발생하는 문제를 해결하면 하위 시스템 로그 및 메모리 수준을 기본값으로 변경합니다. 모든 Ceph 하위 시스템 목록 및 기본값은 부록 A. Ceph 하위 시스템 기본 로깅 수준 값 을 참조하십시오.

다음을 통해 Ceph 로깅을 구성할 수 있습니다.

2.1. 사전 요구 사항

  • 실행 중인 Red Hat Ceph Storage 클러스터.

2.2. Ceph 하위 시스템

이 섹션에는 Ceph 하위 시스템과 해당 로깅 수준에 대한 정보가 포함되어 있습니다.

Ceph 하위 시스템 및 로깅 수준 이해

Ceph는 여러 하위 시스템으로 구성됩니다.

각 하위 시스템에는 로깅 레벨이 있습니다.

  • 기본적으로 /var/log/ceph/ 디렉토리에 저장된 출력 로그(로그 수준)
  • 메모리 캐시에 저장된 로그(메모리 수준)

일반적으로 다음과 같은 경우가 아니면 메모리에 저장된 로그를 출력 로그에 전송하지 않습니다.

  • 치명적인 신호 발생
  • 소스 코드의 어설션이 트리거됨
  • 요청한 경우

이러한 각 하위 시스템에 대해 다양한 값을 설정할 수 있습니다. Ceph 로깅 수준은 1~20 규모로 작동합니다. 1 는 te re 이고 20 은 자세한 정보 표시입니다.

로그 수준 및 메모리 수준에 단일 값을 사용하여 둘 다 동일한 값으로 설정합니다. 예를 들어 debug_osd = 5 는 ceph-osd 데몬의 디버그 수준을 5 로 설정합니다.

출력 로그 수준 및 메모리 수준에 다른 값을 사용하려면 슬래시(/)로 값을 구분합니다. 예를 들어 debug_mon = 1/5 는 ceph-mon 데몬의 디버그 로그 수준을 1 로 설정하고 메모리 로그 수준을 5 로 설정합니다.

참고

컨테이너 기반 배포의 경우 Ceph는 journald 에 로그를 생성합니다. Ceph 구성 파일의 [global]에서 log_to_file 매개변수를 true 로 설정하여 /var/log/ceph 의 파일에 로깅을 활성화할 수 있습니다. 자세한 내용은 ceph 로그 이해를 참조하십시오.

표 2.1. Ceph 하위 시스템 및 로깅 기본값

하위 시스템로그 수준메모리 수준설명

asok

1

5

관리 소켓

auth

1

5

인증

클라이언트

0

5

librados 를 사용하여 클러스터에 연결하는 모든 애플리케이션 또는 라이브러리

bluestore

1

5

BlueStore OSD 백엔드

journal

1

5

OSD 저널

mds

1

5

메타 데이터 서버

monc

0

5

Monitor 클라이언트는 대부분의 Ceph 데몬과 모니터 간의 통신을 처리합니다.

Mon

1

5

모니터

ms

0

5

Ceph 구성 요소 간 메시징 시스템

osd

0

5

OSD 데몬

paxos

0

5

모니터가 합의를 도출하는 데 사용하는 알고리즘

rados

0

5

Ceph의 핵심 구성 요소인 신뢰할 수 있는 자동 배포 개체 스토어

rbd

0

5

Ceph 블록 장치

rgw

1

5

Ceph 개체 게이트웨이

로그 출력 예

다음 예제에서는 모니터 및 OSD의 세부 정보 표시 수준을 높일 때 로그에 메시지 유형을 보여줍니다.

모니터 디버그 설정

debug_ms = 5
debug_mon = 20
debug_paxos = 20
debug_auth = 20

모니터 디버그 설정의 로그 출력 예

2016-02-12 12:37:04.278761 7f45a9afc700 10 mon.cephn2@0(leader).osd e322 e322: 2 osds: 2 up, 2 in
2016-02-12 12:37:04.278792 7f45a9afc700 10 mon.cephn2@0(leader).osd e322  min_last_epoch_clean 322
2016-02-12 12:37:04.278795 7f45a9afc700 10 mon.cephn2@0(leader).log v1010106 log
2016-02-12 12:37:04.278799 7f45a9afc700 10 mon.cephn2@0(leader).auth v2877 auth
2016-02-12 12:37:04.278811 7f45a9afc700 20 mon.cephn2@0(leader) e1 sync_trim_providers
2016-02-12 12:37:09.278914 7f45a9afc700 11 mon.cephn2@0(leader) e1 tick
2016-02-12 12:37:09.278949 7f45a9afc700 10 mon.cephn2@0(leader).pg v8126 v8126: 64 pgs: 64 active+clean; 60168 kB data, 172 MB used, 20285 MB / 20457 MB avail
2016-02-12 12:37:09.278975 7f45a9afc700 10 mon.cephn2@0(leader).paxosservice(pgmap 7511..8126) maybe_trim trim_to 7626 would only trim 115 < paxos_service_trim_min 250
2016-02-12 12:37:09.278982 7f45a9afc700 10 mon.cephn2@0(leader).osd e322 e322: 2 osds: 2 up, 2 in
2016-02-12 12:37:09.278989 7f45a9afc700  5 mon.cephn2@0(leader).paxos(paxos active c 1028850..1029466) is_readable = 1 - now=2016-02-12 12:37:09.278990 lease_expire=0.000000 has v0 lc 1029466
....
2016-02-12 12:59:18.769963 7f45a92fb700  1 -- 192.168.0.112:6789/0 <== osd.1 192.168.0.114:6800/2801 5724 ==== pg_stats(0 pgs tid 3045 v 0) v1 ==== 124+0+0 (2380105412 0 0) 0x5d96300 con 0x4d5bf40
2016-02-12 12:59:18.770053 7f45a92fb700  1 -- 192.168.0.112:6789/0 --> 192.168.0.114:6800/2801 -- pg_stats_ack(0 pgs tid 3045) v1 -- ?+0 0x550ae00 con 0x4d5bf40
2016-02-12 12:59:32.916397 7f45a9afc700  0 mon.cephn2@0(leader).data_health(1) update_stats avail 53% total 1951 MB, used 780 MB, avail 1053 MB
....
2016-02-12 13:01:05.256263 7f45a92fb700  1 -- 192.168.0.112:6789/0 --> 192.168.0.113:6800/2410 -- mon_subscribe_ack(300s) v1 -- ?+0 0x4f283c0 con 0x4d5b440

OSD 디버그 설정

debug_ms = 5
debug_osd = 20

OSD 디버그 설정의 로그 출력 예

2016-02-12 11:27:53.869151 7f5d55d84700  1 -- 192.168.17.3:0/2410 --> 192.168.17.4:6801/2801 -- osd_ping(ping e322 stamp 2016-02-12 11:27:53.869147) v2 -- ?+0 0x63baa00 con 0x578dee0
2016-02-12 11:27:53.869214 7f5d55d84700  1 -- 192.168.17.3:0/2410 --> 192.168.0.114:6801/2801 -- osd_ping(ping e322 stamp 2016-02-12 11:27:53.869147) v2 -- ?+0 0x638f200 con 0x578e040
2016-02-12 11:27:53.870215 7f5d6359f700  1 -- 192.168.17.3:0/2410 <== osd.1 192.168.0.114:6801/2801 109210 ==== osd_ping(ping_reply e322 stamp 2016-02-12 11:27:53.869147) v2 ==== 47+0+0 (261193640 0 0) 0x63c1a00 con 0x578e040
2016-02-12 11:27:53.870698 7f5d6359f700  1 -- 192.168.17.3:0/2410 <== osd.1 192.168.17.4:6801/2801 109210 ==== osd_ping(ping_reply e322 stamp 2016-02-12 11:27:53.869147) v2 ==== 47+0+0 (261193640 0 0) 0x6313200 con 0x578dee0
....
2016-02-12 11:28:10.432313 7f5d6e71f700  5 osd.0 322 tick
2016-02-12 11:28:10.432375 7f5d6e71f700 20 osd.0 322 scrub_random_backoff lost coin flip, randomly backing off
2016-02-12 11:28:10.432381 7f5d6e71f700 10 osd.0 322 do_waiters -- start
2016-02-12 11:28:10.432383 7f5d6e71f700 10 osd.0 322 do_waiters -- finish

추가 리소스

2.3. 런타임 시 로깅 구성

시스템 런타임에서 Ceph 하위 시스템의 로깅을 구성하여 발생할 수 있는 문제를 해결할 수 있습니다.

사전 요구 사항

  • 실행 중인 Red Hat Ceph Storage 클러스터.
  • Ceph 디버거에 대한 액세스.

절차

  1. Ceph 디버깅 출력을 활성화하려면 런타임 시 dout() 을 사용합니다. 

    ceph tell TYPE.ID injectargs --debug-SUBSYSTEM VALUE [--NAME VALUE]

  2. 교체:

    • Ceph 데몬 유형 (osd,mon 또는 mds)이 있는유형
    • Ceph 데몬의 특정 ID가 있는 ID입니다. 또는 * 를 사용하여 특정 유형의 모든 데몬에 런타임 설정을 적용합니다.
    • 특정 하위 시스템이 있는 SUBSYSTEM.

    • 1 에서 20 사이의 숫자가 있는 VALUE, 1 는 tere이고 20 은 자세한 내용입니다.

      예를 들어 osd.0이라는 OSD 하위 시스템의 로그 수준을 0으로 설정하고 메모리 수준을 5로 설정하려면 다음을 수행합니다. 

      # ceph tell osd.0 injectargs --debug-osd 0/5

런타임 시 구성 설정을 보려면 다음을 수행합니다.

  1. 실행 중인 Ceph 데몬(예: ceph-osd 또는 ceph- mon )을 사용하여 호스트에 로그인합니다.

  2. 구성을 표시합니다. 

    ceph daemon NAME config show | less

    예제

    # ceph daemon osd.0 config show | less

추가 리소스

2.4. 구성 파일에서 로깅 구성

정보, 경고 및 오류 메시지를 로그 파일에 기록하도록 Ceph 하위 시스템을 구성합니다. Ceph 구성 파일에서 디버깅 수준을 기본적으로 /etc/ceph/ceph.conf 로 지정할 수 있습니다.

사전 요구 사항

  • 실행 중인 Red Hat Ceph Storage 클러스터.

절차

  1. 부팅 시 dout() Ceph 디버깅 출력을 활성화하려면 Ceph 구성 파일에 디버깅 설정을 추가합니다.

    1. 각 데몬에 공통된 하위 시스템의 경우 [global] 섹션 아래의 설정을 추가합니다.

    2. 특정 데몬의 하위 시스템의 경우 [mon], [ osd] 또는 [mds] 와 같은 데몬 섹션 아래의 설정을 추가합니다.

      예제

      [global]
        debug_ms = 1/5

[mon]
        debug_mon = 20
        debug_paxos = 1/5
        debug_auth = 2

[osd]
        debug_osd = 1/5
        debug_monc = 5/20

[mds]
        debug_mds = 1

추가 리소스

2.5. 로그 교체 가속화

Ceph 구성 요소의 디버깅 수준이 증가하면 엄청난 양의 데이터가 생성될 수 있습니다. 거의 전체 디스크가 있는 경우 /etc/logrotate.d/ceph 에서 Ceph 로그 회전 파일을 수정하여 로그 회전을 가속화할 수 있습니다. Cron 작업 스케줄러는 이 파일을 사용하여 로그 회전을 예약합니다.

사전 요구 사항

  • 실행 중인 Red Hat Ceph Storage 클러스터.
  • 노드에 대한 루트 수준 액세스.

절차

  1. 로그 회전 파일에 순환 주기 뒤에 size 설정을 추가합니다. 

    rotate 7
weekly
size SIZE
compress
sharedscripts

    예를 들어 로그 파일이 500MB에 도달하면 로그 파일을 순환하려면 다음을 수행합니다. 

    rotate 7
weekly
size 500 MB
compress
sharedscripts
size 500M

  2. crontab 편집기를 엽니다. 

    [root@mon ~]# crontab -e

  3. 항목을 추가하여 /etc/logrotate.d/ceph 파일을 확인합니다. 예를 들어 Cron에 30분마다 /etc/logrotate.d/ceph 를 확인하도록 지시하려면 다음을 수행합니다. 

    30 * * * * /usr/sbin/logrotate /etc/logrotate.d/ceph >/dev/null 2>&1

추가 리소스

3장. 네트워킹 문제 해결

이 장에서는 네트워킹 및 NTP(Network Time Protocol)에 연결된 기본적인 문제 해결 절차를 설명합니다.

3.1. 사전 요구 사항

  • 실행 중인 Red Hat Ceph Storage 클러스터.

3.2. 기본 네트워킹 문제 해결

Red Hat Ceph Storage는 신뢰할 수 있는 네트워크 연결에 크게 의존합니다. Red Hat Ceph Storage 노드는 네트워크를 사용하여 서로 통신합니다. 네트워킹 문제로 인해 Ceph OSD와 같이 많은 문제가 발생하거나 중단으로 잘못 보고될 수 있습니다 . 네트워킹 문제로 인해 Ceph 모니터의 클럭 차이 오류도 발생할 수 있습니다. 또한 패킷 손실, 높은 대기 시간 또는 제한된 대역폭은 클러스터 성능과 안정성에 영향을 줄 수 있습니다.

사전 요구 사항

  • 노드에 대한 루트 수준 액세스.

절차

  1. net-tools 및 telnet 패키지를 설치하면 Ceph 스토리지 클러스터에서 발생할 수 있는 네트워크 문제를 해결할 때 도움이 될 수 있습니다.

    Red Hat Enterprise Linux 7

    [root@mon ~]# yum install net-tools
[root@mon ~]# yum install telnet

    Red Hat Enterprise Linux 8

    [root@mon ~]# dnf install net-tools
[root@mon ~]# dnf install telnet

  2. Ceph 구성 파일의 cluster_network 및 public_network 매개변수에 올바른 값이 포함되어 있는지 확인합니다.

    예제

    [root@mon ~]# cat /etc/ceph/ceph.conf | grep net
cluster_network = 192.168.1.0/24
public_network = 192.168.0.0/24

  3. 네트워크 인터페이스가 작동 중인지 확인합니다.

    예제

    [root@mon ~]# ip link list
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: enp22s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether 40:f2:e9:b8:a0:48 brd ff:ff:ff:ff:ff:ff

  4. Ceph 노드가 짧은 호스트 이름을 사용하여 서로 연결할 수 있는지 확인합니다. 스토리지 클러스터의 각 노드에서 이를 확인합니다.

    구문

    ping SHORT_HOST_NAME

    예제

    [root@mon ~]# ping osd01

  5. 방화벽을 사용하는 경우 Ceph 노드가 적절한 포트의 다른 포트에 연결할 수 있는지 확인합니다. firewall-cmd 및 telnet 툴은 포트 상태를 확인하고 포트가 각각 열려 있는지 확인할 수 있습니다.

    구문

    firewall-cmd --info-zone=ZONE
telnet IP_ADDRESS PORT

    예제

    [root@mon ~]# firewall-cmd --info-zone=public
public (active)
  target: default
  icmp-block-inversion: no
  interfaces: enp1s0
  sources: 192.168.0.0/24
  services: ceph ceph-mon cockpit dhcpv6-client ssh
  ports: 9100/tcp 8443/tcp 9283/tcp 3000/tcp 9092/tcp 9093/tcp 9094/tcp 9094/udp
  protocols:
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:

[root@mon ~]# telnet 192.168.0.22 9100

  6. 인터페이스 카운터에 오류가 없는지 확인합니다. 노드 간 네트워크 연결에 예상되는 대기 시간이 있는지와 패킷 손실이 없는지 확인합니다.

    1. ethtool 명령 사용:

      구문

      ethtool -S INTERFACE

      예제

      [root@mon ~]# ethtool -S enp22s0f0 | grep errors
NIC statistics:
     rx_fcs_errors: 0
     rx_align_errors: 0
     rx_frame_too_long_errors: 0
     rx_in_length_errors: 0
     rx_out_length_errors: 0
     tx_mac_errors: 0
     tx_carrier_sense_errors: 0
     tx_errors: 0
     rx_errors: 0

    2. ifconfig 명령 사용:

      예제

      [root@mon ~]# ifconfig
enp22s0f0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
inet 10.8.222.13  netmask 255.255.254.0  broadcast 10.8.223.255
inet6 2620:52:0:8de:42f2:e9ff:feb8:a048  prefixlen 64  scopeid 0x0<global>
inet6 fe80::42f2:e9ff:feb8:a048  prefixlen 64  scopeid 0x20<link>
ether 40:f2:e9:b8:a0:48  txqueuelen 1000  (Ethernet)
RX packets 4219130  bytes 2704255777 (2.5 GiB)
RX errors 0  dropped 0  overruns 0  frame 0 1
TX packets 1418329  bytes 738664259 (704.4 MiB)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0 2
device interrupt 16

    3. netstat 명령 사용:

      예제

      [root@mon ~]# netstat -ai
Kernel Interface table
Iface          MTU   RX-OK RX-ERR RX-DRP RX-OVR  TX-OK TX-ERR TX-DRP TX-OVR Flg
docker0       1500       0      0      0 0           0      0      0      0 BMU
eno2          1500       0      0      0 0           0      0      0      0 BMU
eno3          1500       0      0      0 0           0      0      0      0 BMU
eno4          1500       0      0      0 0           0      0      0      0 BMU
enp0s20u13u5  1500  253277      0      0 0           0      0      0      0 BMRU
enp22s0f0     9000  234160      0      0 0      432326      0      0      0 BMRU 1
lo           65536   10366      0      0 0       10366      0      0      0 LRU

  7. 성능 문제의 경우 대기 시간 확인 외에 스토리지 클러스터의 모든 노드 간 네트워크 대역폭을 확인하려면 iperf3 툴을 사용합니다. iperf3 툴은 서버와 클라이언트 간에 간단한 지점 간 네트워크 대역폭 테스트를 수행합니다.

    1. 대역폭을 확인할 Red Hat Ceph Storage 노드에 iperf3 패키지를 설치합니다.

      Red Hat Enterprise Linux 7

      [root@mon ~]# yum install iperf3

      Red Hat Enterprise Linux 8

      [root@mon ~]# dnf install iperf3

    2. Red Hat Ceph Storage 노드에서 iperf3 서버를 시작합니다.

      예제

      [root@mon ~]# iperf3 -s
-----------------------------------------------------------
Server listening on 5201
-----------------------------------------------------------

      참고

      기본 포트는 5201이지만 -P 명령 인수를 사용하여 설정할 수 있습니다.

    3. 다른 Red Hat Ceph Storage 노드에서 iperf3 클라이언트를 시작합니다.

      예제

      [root@osd ~]# iperf3 -c mon
Connecting to host mon, port 5201
[  4] local xx.x.xxx.xx port 52270 connected to xx.x.xxx.xx port 5201
[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
[  4]   0.00-1.00   sec   114 MBytes   954 Mbits/sec    0    409 KBytes
[  4]   1.00-2.00   sec   113 MBytes   945 Mbits/sec    0    409 KBytes
[  4]   2.00-3.00   sec   112 MBytes   943 Mbits/sec    0    454 KBytes
[  4]   3.00-4.00   sec   112 MBytes   941 Mbits/sec    0    471 KBytes
[  4]   4.00-5.00   sec   112 MBytes   940 Mbits/sec    0    471 KBytes
[  4]   5.00-6.00   sec   113 MBytes   945 Mbits/sec    0    471 KBytes
[  4]   6.00-7.00   sec   112 MBytes   937 Mbits/sec    0    488 KBytes
[  4]   7.00-8.00   sec   113 MBytes   947 Mbits/sec    0    520 KBytes
[  4]   8.00-9.00   sec   112 MBytes   939 Mbits/sec    0    520 KBytes
[  4]   9.00-10.00  sec   112 MBytes   939 Mbits/sec    0    520 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec  1.10 GBytes   943 Mbits/sec    0             sender
[  4]   0.00-10.00  sec  1.10 GBytes   941 Mbits/sec                  receiver

iperf Done.

      이 출력은 Red Hat Ceph Storage 노드 간 네트워크 대역폭 1.1 Gbits/초와 테스트 중에재전송(Retr)이 없음을 보여줍니다.

      Red Hat은 스토리지 클러스터에 있는 모든 노드 간의 네트워크 대역폭을 검증하는 것이 좋습니다.

  8. 모든 노드의 네트워크 연결 속도가 동일한지 확인합니다. 연결 속도가 느려지면 연결된 노드가 더 느려질 수 있습니다. 또한 스위치 링크가 연결된 노드의 집계 대역폭을 처리할 수 있는지 확인합니다.

    구문

    ethtool INTERFACE

    예제

    [root@mon ~]# ethtool enp22s0f0
Settings for enp22s0f0:
Supported ports: [ TP ]
Supported link modes:   10baseT/Half 10baseT/Full
                        100baseT/Half 100baseT/Full
                        1000baseT/Half 1000baseT/Full
Supported pause frame use: No
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes:  10baseT/Half 10baseT/Full
                        100baseT/Half 100baseT/Full
                        1000baseT/Half 1000baseT/Full
Advertised pause frame use: Symmetric
Advertised auto-negotiation: Yes
Advertised FEC modes: Not reported
Link partner advertised link modes:  10baseT/Half 10baseT/Full
                                     100baseT/Half 100baseT/Full
                                     1000baseT/Full
Link partner advertised pause frame use: Symmetric
Link partner advertised auto-negotiation: Yes
Link partner advertised FEC modes: Not reported
Speed: 1000Mb/s 1
Duplex: Full 2
Port: Twisted Pair
PHYAD: 1
Transceiver: internal
Auto-negotiation: on
MDI-X: off
Supports Wake-on: g
Wake-on: d
Current message level: 0x000000ff (255)
       drv probe link timer ifdown ifup rx_err tx_err
Link detected: yes 3

추가 리소스

3.3. 기본 chrony NTP 문제 해결

이 섹션에는 기본 chrony 문제 해결 단계가 포함되어 있습니다.

사전 요구 사항

  • 실행 중인 Red Hat Ceph Storage 클러스터.
  • Ceph 모니터 노드에 대한 루트 수준 액세스.

절차

  1. chronyd 데몬이 Ceph Monitor 호스트에서 실행 중인지 확인합니다.

    예제

    [root@mon ~]# systemctl status chronyd

  2. chronyd 가 실행 중이 아닌 경우 다음을 활성화하고 시작합니다.

    예제

    [root@mon ~]# systemctl enable chronyd
[root@mon ~]# systemctl start chronyd

  3. chronyd 가 클럭을 올바르게 동기화하는지 확인합니다.

    예제

    [root@mon ~]# chronyc sources
[root@mon ~]# chronyc sourcestats
[root@mon ~]# chronyc tracking

추가 리소스

3.4. 기본 NTP 문제 해결

이 섹션에는 기본 NTP 문제 해결 단계가 포함되어 있습니다.

사전 요구 사항

  • 실행 중인 Red Hat Ceph Storage 클러스터.
  • Ceph 모니터 노드에 대한 루트 수준 액세스.

절차

  1. ntpd 데몬이 Ceph Monitor 호스트에서 실행 중인지 확인합니다.

    예제

    [root@mon ~]# systemctl status ntpd

  2. ntpd 가 실행 중이 아니면 활성화하고 시작합니다.

    예제

    [root@mon ~]# systemctl enable ntpd
[root@mon ~]# systemctl start ntpd

  3. ntpd 가 클록을 올바르게 동기화하는지 확인합니다.

    예제

    [root@mon ~]# ntpq -p

추가 리소스

  • 고급 NTP 문제 해결 단계는 Red Hat 고객 포털에서 NTP 문제 해결 방법을 참조하십시오.
  • 자세한 내용은 Red Hat Ceph Storage Troubleshooting Guide 의 Clock skew 섹션을 참조하십시오.

4장. Ceph 모니터 문제 해결

이 장에서는 Ceph 모니터와 관련된 가장 일반적인 오류를 수정하는 방법에 대해 설명합니다.

4.1. 사전 요구 사항

  • 네트워크 연결을 확인합니다.

4.2. 가장 일반적인 Ceph Monitor 오류

다음 표에는 Ceph 상태 세부 정보 명령에서 반환하거나 Ceph 로그에 포함된 가장 일반적인 오류 메시지가 나열되어 있습니다. 테이블에서는 오류를 설명하는 해당 섹션에 대한 링크를 제공하고 문제를 해결하는 특정 절차를 가리킵니다.

4.2.1. 사전 요구 사항

  • 실행 중인 Red Hat Ceph Storage 클러스터.

4.2.2. Ceph Monitor 오류 메시지

일반적인 Ceph Monitor 오류 메시지 테이블과 잠재적인 수정 사항.

오류 메시지보기

HEALTH_WARN

Mon.X가 다운되었습니다 (쿼럼 제외)

Ceph Monitor가 쿼럼에 없습니다

시간 오차

시간 오차

매장이 너무 커지고 있습니다!

Ceph Monitor 저장소가 너무 커졌습니다.

4.2.3. Ceph 로그의 일반적인 Ceph Monitor 오류 메시지

Ceph 로그에 있는 일반적인 Ceph Monitor 오류 메시지의 표와 잠재적인 수정 사항에 대한 링크입니다.

오류 메시지로그 파일보기

시간 오차

기본 클러스터 로그

시간 오차

시계가 동기화되지 않음

기본 클러스터 로그

시간 오차

손상: 레코드 중간에 오류

로그 모니터링

Ceph Monitor가 쿼럼에 없습니다

Ceph 모니터 저장소 복구

손상: 1 누락된 파일

로그 모니터링

Ceph Monitor가 쿼럼에 없습니다

Ceph 모니터 저장소 복구

포착된 신호 (Bus 오류)

로그 모니터링

Ceph Monitor가 쿼럼에 없습니다

4.2.4. Ceph Monitor가 쿼럼에 없습니다

하나 이상의 Ceph 모니터가 down 으로 표시되지만 다른 Ceph 모니터는 여전히 쿼럼을 구성할 수 있습니다. 또한 ceph health detail 명령은 다음과 유사한 오류 메시지를 반환합니다. 

HEALTH_WARN 1 mons down, quorum 1,2 mon.b,mon.c
mon.a (rank 0) addr 127.0.0.1:6789/0 is down (out of quorum)

이 의미

Ceph는 다양한 이유로 인해 Ceph 모니터를 다운 된 상태로 표시합니다.

ceph-mon 데몬이 실행 중이 아니면 손상된 저장소가 있거나 다른 오류가 있어 데몬이 시작되지 않을 수 있습니다. 또한 /var/ 파티션이 가득 찰 수 있습니다. 결과적으로 ceph-mon 은 기본적으로 /var/lib/ceph/mon-SHORT_HOST_NAME/store.db 에 있는 저장소에 대한 작업을 수행할 수 없습니다.

ceph-mon 데몬이 실행 중이지만 Ceph Monitor가 쿼럼 상태가 되어 down 으로 표시되면 문제가 Ceph Monitor 상태에 따라 달라집니다.

  • Ceph Monitor가 예상보다 긴 프로브 상태인 경우 다른 Ceph 모니터를 찾을 수 없습니다. 이 문제는 네트워킹 문제 또는 Ceph Monitor에 오래된 Ceph 모니터 맵(monmap)이 있을 수 있으며 잘못된 IP 주소의 다른 Ceph 모니터에 연결하려고 할 수 있습니다. 또는 monmap 이 최신 버전인 경우 Ceph Monitor의 시계가 동기화되지 않을 수 있습니다.
  • Ceph Monitor가 예상보다 긴 경우 Ceph Monitor의 클록이 동기화되지 않을 수 있습니다.
  • Ceph Monitor가 동기화 에서 선택으로 해당 상태를 변경하면 클러스터 상태가 진행 중입니다. 즉, 동기화 프로세스에서 처리할 수 있는 것보다 더 빨리 새 맵을 생성합니다.
  • Ceph 모니터 자체를 리더 또는 Pe on 으로 표시하는 경우에는 쿼럼에 있는 것으로 간주되지만 나머지 클러스터는 확실하지 않은 것으로 간주합니다. 이 문제는 클럭 동기화 실패로 인해 발생할 수 있습니다.

이 문제를 해결하려면

  1. ceph-mon 데몬이 실행 중인지 확인합니다. 그렇지 않은 경우 시작합니다. 

    [root@mon ~]# systemctl status ceph-mon@HOST_NAME
[root@mon ~]# systemctl start ceph-mon@HOST_NAME

    HOST_NAME 을 데몬이 실행 중인 호스트의 짧은 이름으로 바꿉니다. 확실하지 않은 경우 hostname -s 명령을 사용합니다.

  2. ceph-mon을 시작할 수 없는 경우 ceph-mon 데몬의 단계를 실행할 수 없습니다.
  3. ceph-mon 데몬을 시작할 수는 있지만 down 으로 표시되면 ceph-mon 데몬이 실행 중이지만 '아래로'로 표시된 단계를 따르십시오.

ceph-mon Daemon을 시작할 수 없음

  1. 기본적으로 /var/log/ceph/ceph-mon에 있는 해당 Ceph Monitor 로그를 확인합니다.HOST_NAME.log.

  2. 로그에 다음과 유사한 오류 메시지가 포함된 경우 Ceph Monitor에 손상된 저장소가 있을 수 있습니다. 

    Corruption: error in middle of record
Corruption: 1 missing files; e.g.: /var/lib/ceph/mon/mon.0/store.db/1234567.ldb

    이 문제를 해결하려면 Ceph 모니터를 교체합니다. 실패한 모니터 교체를 참조하십시오.

  3. 로그에 다음과 유사한 오류 메시지가 포함된 경우 /var/ 파티션이 가득 찰 수 있습니다. /var/ 에서 불필요한 데이터를 삭제합니다. 

    Caught signal (Bus error)
    중요

    Monitor 디렉토리에서 수동으로 데이터를 삭제하지 마십시오. 대신 ceph-monstore-tool 을 사용하여 압축합니다. 자세한 내용은 Ceph Monitor 저장소 를 참조하십시오.

  4. 다른 오류 메시지가 표시되면 지원 티켓을 엽니다. 자세한 내용은 Red Hat 지원 문의를 참조하십시오.

ceph-mon Daemon은 실행 중이지만 S still marked as down

  1. 쿼럼이 없는 Ceph Monitor 호스트에서 mon_status 명령을 사용하여 상태를 확인합니다. 

    [root@mon ~]# ceph daemon ID mon_status

    ID 를 Ceph Monitor의 ID로 바꿉니다. 예를 들면 다음과 같습니다. 

    [root@mon ~]# ceph daemon mon.a mon_status

  2. 상태를 조사하는 경우 mon_status 출력에서 다른 Ceph 모니터의 위치를 확인합니다.

    1. 주소가 올바르지 않으면 Ceph 모니터에 잘못된 Ceph 모니터 맵(기타 맵)이 있습니다. 이 문제를 해결하려면 Injecting a Ceph Monitor map 을 참조하십시오.
    2. 주소가 올바르면 Ceph Monitor 시계가 동기화되었는지 확인합니다. 자세한 내용은 Clock skew 를 참조하십시오. 또한 네트워킹 문제를 해결하려면 네트워킹 문제 해결을 참조하십시오.
  3. 상태가 선택되는 경우 Ceph Monitor 시계가 동기화되었는지 확인합니다. 자세한 내용은 Clock skew 를 참조하십시오.
  4. 상태가 선택에서 동기화 로 변경되면 지원 티켓을 엽니다. 자세한 내용은 Red Hat 지원 문의를 참조하십시오.
  5. Ceph Monitor가 리더 또는 Pe on인 경우 Ceph Monitor 시계가 동기화되었는지 확인합니다. 자세한 내용은 Clock skew 를 참조하십시오. 클록을 동기화하면 지원 티켓을 열면 문제가 해결되지 않습니다. 자세한 내용은 Red Hat 지원 문의를 참조하십시오.

추가 리소스

4.2.5. 시간 오차

Ceph Monitor가 쿼럼이 아니므로 ceph 상태 세부 정보 명령 출력에 다음과 유사한 오류 메시지가 포함되어 있습니다. 

mon.a (rank 0) addr 127.0.0.1:6789/0 is down (out of quorum)
mon.a addr 127.0.0.1:6789/0 clock skew 0.08235s > max 0.05s (latency 0.0045s)

또한 Ceph 로그에는 다음과 유사한 오류 메시지가 포함되어 있습니다. 

2015-06-04 07:28:32.035795 7f806062e700 0 log [WRN] : mon.a 127.0.0.1:6789/0 clock skew 0.14s > max 0.05s
2015-06-04 04:31:25.773235 7f4997663700 0 log [WRN] : message from mon.1 was stamped 0.186257s in the future, clocks not synchronized

이 의미

clock skew 오류 메시지는 Ceph Monitors의 시계가 동기화되지 않았음을 나타냅니다. Ceph 모니터는 시간 정확도에 의존하고 클록이 동기화되지 않는 경우 예측할 수 없는 방식으로 작동하기 때문에 클럭 동기화가 중요합니다.

mon_clock_drift_allowed 매개 변수는 허용된 클록 간의 불일치를 결정합니다. 기본적으로 이 매개변수는 0.05초로 설정됩니다.

중요

이전 테스트 없이는 기본값 mon_clock_drift_allowed 를 변경하지 마십시오. 이 값을 변경하면 일반적으로 Ceph 모니터 및 Ceph 스토리지 클러스터의 안정성에 영향을 미칠 수 있습니다.

클럭 스큐 오류의 가능한 원인으로는 네트워크 문제 또는 이를 구성하는 경우 NTP(Network Time Protocol) 동기화 문제가 있습니다. 또한 가상 시스템에 배포된 Ceph 모니터에서는 시간 동기화가 제대로 작동하지 않습니다.

이 문제를 해결하려면

  1. 네트워크가 올바르게 작동하는지 확인합니다. 자세한 내용은 네트워킹 문제 해결을 참조하십시오. 특히 NTP를 사용하는 경우 NTP 클라이언트의 문제를 해결합니다.

    1. NTP에 chrony를 사용하는 경우 자세한 내용은 Basic chrony NTP 문제 해결 섹션을 참조하십시오.
    2. ntpd 를 사용하는 경우 기본 NTP 문제 해결을 참조하십시오.

  2. 원격 NTP 서버를 사용하는 경우 자체 NTP 서버를 네트워크에 배포하는 것이 좋습니다.

    1. 자세한 내용은 Red Hat Enterprise Linux 8 의 기본 시스템 설정 구성의 NTP 설정에 Chrony 제품군 사용 장을 참조하십시오.
    2. Red Hat Enterprise Linux 7에 대한 시스템 관리자 가이드의 ntpd를 사용하여 NTP 구성 장을 참조하십시오.
참고

Ceph는 5분마다 시간 동기화를 평가하므로 문제를 해결하고 클럭 스큐 메시지를 지울 때까지 지연이 발생합니다.

추가 리소스

4.2.6. Ceph Monitor 저장소가 너무 커졌습니다.

ceph 상태 명령은 다음과 유사한 오류 메시지를 반환합니다. 

mon.ceph1 store is getting too big! 48031 MB >= 15360 MB -- 62% avail

이 의미

Ceph 모니터 저장소는 실제로 항목을 키-값 쌍으로 저장하는 LevelDB 데이터베이스입니다. 데이터베이스에는 클러스터 맵이 포함되어 있으며 기본적으로 /var/lib/ceph/mon/CLUSTER_NAME -SHORT_HOST_NAME/store.db 에 있습니다.

대형 모니터 저장소를 쿼리하는 데 시간이 걸릴 수 있습니다. 결과적으로 Ceph Monitor는 클라이언트 쿼리에 응답하는 데 지연될 수 있습니다.

또한 /var/ 파티션이 가득 찬 경우 Ceph 모니터는 저장소에 쓰기 작업을 수행하고 종료할 수 없습니다. 이 문제 해결에 대한 자세한 내용은 Ceph Monitor가 쿼럼 상태가 아닙니다.

이 문제를 해결하려면

  1. 데이터베이스의 크기를 확인합니다. 

    du -sch /var/lib/ceph/mon/CLUSTER_NAME-SHORT_HOST_NAME/store.db

    클러스터의 이름과 ceph-mon 이 실행 중인 호스트의 짧은 호스트 이름을 지정합니다.

    예제

    # du -sch /var/lib/ceph/mon/ceph-host1/store.db
47G     /var/lib/ceph/mon/ceph-ceph1/store.db/
47G     total

  2. Ceph 모니터 저장소의 압축. 자세한 내용은 Ceph 모니터 저장소에 대한 자세한 내용은 를 참조하십시오.

추가 리소스

4.2.7. Ceph Monitor 상태 이해

mon_status 명령은 다음과 같은 Ceph 모니터에 대한 정보를 반환합니다.

  • 상태
  • 순위
  • 선택 기간
  • 모니터 맵 (monmap)

Ceph 모니터가 쿼럼을 구성할 수 있는 경우 ceph 명령줄 유틸리티와 함께 mon_status 를 사용합니다.

Ceph Monitor에서 쿼럼을 구성할 수 없지만 ceph-mon 데몬이 실행 중인 경우 관리 소켓을 사용하여 mon_status 를 실행합니다.

mon_status의 출력 예

{
    "name": "mon.3",
    "rank": 2,
    "state": "peon",
    "election_epoch": 96,
    "quorum": [
        1,
        2
    ],
    "outside_quorum": [],
    "extra_probe_peers": [],
    "sync_provider": [],
    "monmap": {
        "epoch": 1,
        "fsid": "d5552d32-9d1d-436c-8db1-ab5fc2c63cd0",
        "modified": "0.000000",
        "created": "0.000000",
        "mons": [
            {
                "rank": 0,
                "name": "mon.1",
                "addr": "172.25.1.10:6789\/0"
            },
            {
                "rank": 1,
                "name": "mon.2",
                "addr": "172.25.1.12:6789\/0"
            },
            {
                "rank": 2,
                "name": "mon.3",
                "addr": "172.25.1.13:6789\/0"
            }
        ]
    }
}

Ceph 모니터 상태

리더
선택 단계에서 Ceph 모니터가 리더로 선택되고 있습니다. 순위가 가장 높은 Ceph 모니터는 순위가 가장 낮은 Ceph 모니터입니다. 위의 예에서 리더는 mon.1 입니다.
Peon
Peons는 리더가 아닌 쿼럼의 Ceph 모니터입니다. 리더가 실패하면 순위가 가장 높은 PEon이 새로운 리더가 됩니다.
Probing
다른 Ceph 모니터를 찾는 경우 Ceph Monitor가 검사 상태에 있습니다. 예를 들어 Ceph 모니터를 시작한 후 Ceph 모니터 맵(monmap)에 지정된 Ceph 모니터를 충분히 찾을 때까지 쿼럼을 형성합니다.
선택
리더를 선택하는 프로세스인 경우 Ceph 모니터가 선택 상태에 있습니다. 일반적으로 이 상태는 빠르게 변경됩니다.
동기화 중
다른 Ceph 모니터와 동기화하여 쿼럼에 가입하는 경우 Ceph Monitor가 동기화 상태에 있습니다. Ceph 모니터 저장소가 작을수록 동기화 프로세스가 빨라집니다. 따라서 큰 저장소가 있는 경우 동기화에 시간이 오래 걸립니다.

추가 리소스

4.2.8. 추가 리소스

4.3. monmap삽입

Ceph Monitor에 오래되었거나 손상된 Ceph 모니터 맵(monmap)이 있는 경우 잘못된 IP 주소의 다른 Ceph 모니터에 연결하려고 하므로 쿼럼에 참여할 수 없습니다.

이 문제를 해결하는 가장 안전한 방법은 다른 Ceph 모니터에서 실제 Ceph 모니터 맵을 가져와 삽입하는 것입니다.

참고

이 작업은 Ceph Monitor에서 보관하는 기존 Ceph Monitor 맵을 덮어씁니다.

다음 절차에서는 다른 Ceph 모니터가 쿼럼을 만들 수 있거나 하나 이상의 Ceph 모니터에 올바른 Ceph 모니터 맵이 있는 경우 Ceph Monitor 맵을 삽입하는 방법을 보여줍니다. 모든 Ceph 모니터 저장소가 손상되어 Ceph 모니터 맵도 있는 경우 Ceph 모니터 저장소 복구를 참조하십시오.

사전 요구 사항

  • Ceph 모니터 맵에 대한 액세스.
  • Ceph 모니터 노드에 대한 루트 수준 액세스.

절차

  1. 나머지 Ceph Monitor가 쿼럼을 구성할 수 있는 경우 ceph mon getmap 명령을 사용하여 Ceph Monitor 맵을 가져옵니다. 

    [root@mon ~]# ceph mon getmap -o /tmp/monmap

  2. 나머지 Ceph Monitor가 쿼럼을 구성할 수 없고 올바른 Ceph 모니터 맵이 있는 Ceph Monitor가 하나 이상 있는 경우 해당 Ceph Monitor에서 복사합니다.

    1. Ceph Monitor 맵을 복사하려는 Ceph Monitor를 중지합니다. 

      [root@mon ~]# systemctl stop ceph-mon@<host-name>

      예를 들어 host 1 짧은 호스트 이름이 있는 호스트에서 Ceph Monitor 실행을 중지하려면 다음을 수행합니다. 

      [root@mon ~]# systemctl stop ceph-mon@host1

    2. Ceph 모니터 맵을 복사합니다. 

      [root@mon ~]# ceph-mon -i ID --extract-monmap /tmp/monmap

      ID 를 Ceph Monitor 맵을 복사하려는 Ceph Monitor의 ID로 바꿉니다. 

      [root@mon ~]# ceph-mon -i mon.a  --extract-monmap /tmp/monmap

  3. 손상된 Ceph 모니터 맵을 사용하여 Ceph Monitor를 중지합니다. 

    [root@mon ~]# systemctl stop ceph-mon@HOST_NAME

    예를 들어 host 2 짧은 호스트 이름이 있는 호스트에서 Ceph Monitor 실행을 중지하려면 다음을 수행합니다. 

    [root@mon ~]# systemctl stop ceph-mon@host2

  4. Ceph Monitor 맵을 두 가지 방법으로 ceph 사용자로 삽입할 수 있습니다.

    • ceph 사용자로 명령을 실행합니다.

      구문

      su - ceph -c 'ceph-mon -i ID --inject-monmap /tmp/monmap'

      ID 를 Ceph Monitor의 ID로 교체하여 손상된 Ceph Monitor 맵으로 변경합니다.

      예제

      [root@mon ~]# su - ceph -c 'ceph-mon -i mon.c --inject-monmap /tmp/monmap'

    • root 사용자로 명령을 실행한 다음 chown 을 실행하여 권한을 변경합니다.

      1. root 사용자로 명령을 실행합니다.

        구문

        ceph-mon -i ID --inject-monmap /tmp/monmap

        ID 를 Ceph Monitor의 ID로 교체하여 손상된 Ceph Monitor 맵으로 변경합니다.

        예제

        [root@mon ~]# ceph-mon -i mon.c --inject-monmap /tmp/monmap

      2. 파일 권한을 변경합니다.

        예제

        [root@mon ~]# chown -R ceph:ceph /var/lib/ceph/mon/ceph-c/

  5. Ceph 모니터를 시작합니다. 

    [root@mon ~]# systemctl start ceph-mon@host2

    다른 Ceph Monitor에서 Ceph Monitor 맵을 복사한 경우 해당 Ceph Monitor도 시작합니다. 

    [root@mon ~]# systemctl start ceph-mon@host1

추가 리소스

4.4. 실패한 모니터 교체

모니터에 손상된 저장소가 있는 경우 이 문제를 해결하는 권장 방법은 Ansible 자동화 애플리케이션을 사용하여 모니터를 교체하는 것입니다.

사전 요구 사항

  • 실행 중인 Red Hat Ceph Storage 클러스터.
  • 쿼럼을 형성할 수 있습니다.
  • Ceph 모니터 노드에 대한 루트 수준 액세스.

절차

  1. Monitor 호스트에서 기본적으로 /var/lib/ceph/mon/CLUSTER_NAME -SHORT_HOST_NAME 에 있는 모니터 저장소를 제거합니다. 

    rm -rf /var/lib/ceph/mon/CLUSTER_NAME-SHORT_HOST_NAME

    Monitor 호스트의 짧은 호스트 이름과 클러스터 이름을 지정합니다. 예를 들어 host1 에서 실행 중인 모니터 저장소를 remote 라는 클러스터에서 제거하려면 다음을 수행합니다. 

    [root@mon ~]# rm -rf /var/lib/ceph/mon/remote-host1

  2. 모니터 맵(monmap)에서 Monitor를 제거합니다. 

    ceph mon remove SHORT_HOST_NAME --cluster CLUSTER_NAME

    Monitor 호스트의 짧은 호스트 이름과 클러스터 이름을 지정합니다. 예를 들어 host1 에서 실행 중인 Monitor를 remote 라는 클러스터에서 제거하려면 다음을 수행합니다. 

    [root@mon ~]# ceph mon remove host1 --cluster remote
  3. 모니터 호스트의 기본 파일 시스템 또는 하드웨어와 관련된 문제를 해결하고 수정합니다.

  4. Ansible 관리 노드에서 ceph-ansible 플레이북을 실행하여 Monitor를 재배포합니다. 

    $ /usr/share/ceph-ansible/ansible-playbook site.yml

추가 리소스

4.5. 모니터 저장소 압축

모니터 저장소 크기가 크게 성장하면 압축할 수 있습니다.

  • ceph tell 명령을 사용하여 동적으로.
  • ceph-mon 데몬이 시작될 때.
  • ceph-mon 데몬이 실행되지 않은 경우 ceph-monstore- tool 을 사용합니다. 이전에 언급한 메서드가 모니터 저장소를 압축하지 못하거나 모니터가 쿼럼을 벗어나고 로그에 C appropriate signal(Bus 오류) 오류 메시지가 포함된 경우 이 메서드를 사용합니다.
중요

클러스터가 active+clean 상태가 아니거나 리밸런싱 프로세스 중에 저장소 크기 변경 사항을 모니터링합니다. 이러한 이유로 리밸런싱이 완료되면 모니터 저장소를 압축합니다. 또한 배치 그룹이 active+clean 상태인지 확인합니다.

사전 요구 사항

  • 실행 중인 Red Hat Ceph Storage 클러스터.
  • Ceph 모니터 노드에 대한 루트 수준 액세스.

절차

  1. ceph-mon 데몬이 실행될 때 모니터 저장소를 압축하려면 다음을 수행합니다. 

    ceph tell mon.HOST_NAME compact

  2. HOST_NAME 을 ceph-mon 이 실행 중인 호스트의 짧은 호스트 이름으로 바꿉니다. 확실하지 않은 경우 hostname -s 명령을 사용합니다. 

    # ceph tell mon.host1 compact

  3. [mon] 섹션의 Ceph 구성에 다음 매개변수를 추가합니다. 

    [mon]
mon_compact_on_start = true

  4. ceph-mon 데몬을 다시 시작합니다. 

    [root@mon ~]# systemctl restart ceph-mon@_HOST_NAME_

    HOST_NAME 을 데몬이 실행 중인 호스트의 짧은 이름으로 바꿉니다. 확실하지 않은 경우 hostname -s 명령을 사용합니다. 

    [root@mon ~]# systemctl restart ceph-mon@host1

  5. Monitors가 쿼럼을 구성했는지 확인합니다. 

    [root@mon ~]# ceph mon stat

  6. 필요한 경우 다른 모니터에서 이 단계를 반복합니다.

    참고

    시작하기 전에 ceph-test 패키지가 설치되어 있는지 확인합니다.

  7. 대형 저장소가 있는 ceph-mon 데몬이 실행 중이 아닌지 확인합니다. 필요한 경우 데몬을 중지합니다. 

    [root@mon ~]# systemctl status ceph-mon@HOST_NAME
[root@mon ~]# systemctl stop ceph-mon@HOST_NAME

    HOST_NAME 을 데몬이 실행 중인 호스트의 짧은 이름으로 바꿉니다. 확실하지 않은 경우 hostname -s 명령을 사용합니다. 

    [root@mon ~]# systemctl status ceph-mon@host1
[root@mon ~]# systemctl stop ceph-mon@host1

  8. 다음 두 가지 방법으로 ceph 사용자로 모니터 저장소를 압축합니다.

    • ceph 사용자로 명령을 실행합니다.

      구문

      su - ceph -c 'ceph-monstore-tool /var/lib/ceph/mon/mon.HOST_NAME compact'

      예제

      [root@mon ~]# su - ceph -c 'ceph-monstore-tool /var/lib/ceph/mon/mon.node1 compact'

    • root 사용자로 명령을 실행한 다음 chown 을 실행하여 권한을 변경합니다.

      1. root 사용자로 명령을 실행합니다.

        구문

        ceph-monstore-tool /var/lib/ceph/mon/mon.HOST_NAME compact

        예제

        [root@mon ~]# ceph-monstore-tool /var/lib/ceph/mon/mon.node1 compact

      2. 파일 권한을 변경합니다.

        예제

        [root@mon ~]# chown -R ceph:ceph /var/lib/ceph/mon/mon.node1

  9. ceph-mon 을 다시 시작합니다. 

    [root@mon ~]# systemctl start ceph-mon@HOST_NAME

    예제

    [root@mon ~]# systemctl start ceph-mon@host1

추가 리소스

4.6. Ceph 관리자용 포트 열기

ceph-mgr 데몬은 ceph- osd 데몬과 동일한 범위의 포트에 있는 OSD에서 배치 그룹 정보를 받습니다. 이러한 포트가 열려 있지 않으면 클러스터에서 HEALTH_OK에서 HEALTH_ WARN 으로 디버거되고 PG는 알 수 없는 PG 수로 알 수 없음을 나타냅니다.

사전 요구 사항

  • 실행 중인 Red Hat Ceph Storage 클러스터.
  • Ceph 관리자에 대한 루트 수준의 액세스.

절차

  1. 이 문제를 해결하려면 ceph-mgr 데몬을 실행하는 각 호스트의 경우 포트 6800-7300 을 엽니다.

    예제

    [root@ceph-mgr] # firewall-cmd --add-port 6800-7300/tcp
[root@ceph-mgr] # firewall-cmd --add-port 6800-7300/tcp --permanent

  2. ceph-mgr 데몬을 다시 시작합니다.

4.7. 베어 메탈 배포용 Ceph Monitor 복구

Red Hat Ceph Storage 클러스터에 모든 모니터가 다운되고 ceph -s 명령이 예상대로 실행되지 않으면 monmaptool 명령을 사용하여 모니터를 복구할 수 있습니다. monmaptool 명령은 데몬의 인증 키 파일에서 Ceph 모니터 저장소를 다시 빌드합니다.

참고

이 절차는 베어 메탈 Red Hat Ceph Storage 배포 전용입니다. 컨테이너화된 Red Hat Ceph Storage 배포의 경우 3mon이 모두 중단된 경우 Red Hat Ceph Storage 컨테이너화된 배포의 Knowledgebase 문서 MON 복구 절차를 참조하십시오.

사전 요구 사항

  • 베어 메탈 배포 Red Hat Ceph Storage 클러스터.
  • 모든 노드에 대한 루트 수준 액세스입니다.
  • 모든 Ceph 모니터가 다운되었습니다.

절차

  1. 모니터 노드에 로그인합니다.

  2. 모니터 노드에서 root 사용자가 없는 OSD 노드에 액세스할 수 없는 경우 공개 키 쌍을 OSD 노드에 복사합니다.

    1. SSH 키 쌍을 생성하고 기본 파일 이름을 사용하고 암호를 비워 둡니다.

      예제

      [root@mons-1 ~]# ssh-keygen

    2. 공개 키를 스토리지 클러스터의 모든 OSD 노드에 복사합니다.

      예제

      [root@mons-1 ~]#  ssh-copy-id root@osds-1
[root@mons-1 ~]#  ssh-copy-id root@osds-2
[root@mons-1 ~]#  ssh-copy-id root@osds-3

  3. 모든 OSD 노드에서 OSD 데몬 서비스를 중지합니다.

    예제

    [root@osds-1 ~]#  sudo systemctl stop ceph-osd\*.service ceph-osd.target

  4. 모든 OSD 노드에서 클러스터 맵을 수집하려면 복구 파일을 생성하고 스크립트를 실행합니다.

    1. 복구 파일을 생성합니다.

      예제

      [root@mons-1 ~]# touch recover.sh

    2. 다음 콘텐츠를 파일에 추가하고 OSD_NODES 를 모든 OSD 노드의 IP 주소 또는 Red Hat Ceph Storage 클러스터에 있는 모든 OSD 노드의 호스트 이름으로 교체합니다.

      구문

       --------------------------------------------------------------------------  NOTE: The directory names specified by 'ms', 'db', and 'db_slow' must end
 with a trailing / otherwise rsync will not operate properly.  --------------------------------------------------------------------------
ms=/tmp/monstore/
db=/root/db/
db_slow=/root/db.slow/

mkdir -p $ms $db $db_slow

 --------------------------------------------------------------------------  NOTE: Replace the contents inside double quotes for 'osd_nodes' below with
 the list of OSD nodes in the environment.  --------------------------------------------------------------------------
osd_nodes="OSD_NODES_1 OSD_NODES_2 OSD_NODES_3..."

for osd_node in $osd_nodes; do
echo "Operating on $osd_node"
rsync -avz --delete $ms $osd_node:$ms
rsync -avz --delete $db $osd_node:$db
rsync -avz --delete $db_slow $osd_node:$db_slow

ssh -t $osd_node <<EOF
for osd in /var/lib/ceph/osd/ceph-*; do
    ceph-objectstore-tool --type bluestore --data-path \$osd --op update-mon-db --no-mon-config --mon-store-path $ms
    if [ -e \$osd/keyring ]; then
        cat \$osd/keyring >> $ms/keyring
        echo '    caps mgr = "allow profile osd"' >> $ms/keyring
        echo '    caps mon = "allow profile osd"' >> $ms/keyring
        echo '    caps osd = "allow *"' >> $ms/keyring
    else
        echo WARNING: \$osd on $osd_node does not have a local keyring.
    fi
done
EOF

rsync -avz --delete --remove-source-files $osd_node:$ms $ms
rsync -avz --delete --remove-source-files $osd_node:$db $db
rsync -avz --delete --remove-source-files $osd_node:$db_slow $db_slow
done
 --------------------------------------------------------------------------  End of script
## --------------------------------------------------------------------------

    3. 파일에 실행 가능한 권한을 제공합니다.

      예제

      [root@mons-1 ~]# chmod 755 recover.sh

    4. 파일을 실행하여 스토리지 클러스터의 모든 OSD 노드에서 모든 OSD의 인증 키를 수집합니다.

      예제

      [root@mons-1 ~]# ./recovery.sh

  5. 해당 노드에서 다른 데몬의 인증 키를 가져옵니다.

    1. Ceph Monitor의 경우 인증 키는 모든 Ceph 모니터에 대해 동일합니다.

      구문

      cat /var/lib/ceph/mon/ceph-MONITOR_NODE/keyring

      예제

      [root@mons-1 ~]# cat /var/lib/ceph/mon/ceph-mons-1/keyring

    2. Ceph Manager의 경우 모든 관리자 노드에서 인증 키를 가져옵니다.

      구문

      cat /var/lib/ceph/mgr/ceph-MANAGER_NODE/keyring

      예제

      [root@mons-1 ~]# cat /var/lib/ceph/mgr/ceph-mons-1/keyring

    3. Ceph OSD의 경우 인증 키는 위의 스크립트에서 생성되어 임시 경로에 저장됩니다.

      이 예에서는 OSD 키링이 /tmp/monstore/keyring 파일에 저장됩니다.

    4. 클라이언트의 모든 클라이언트 노드에서 인증 키를 가져옵니다.

      구문

      cat /etc/ceph/CLIENT_KEYRING

      예제

      [root@client ~]# cat /etc/ceph/ceph.client.admin.keyring

    5. 메타 데이터 서버(MDS)의 경우 모든 Ceph MDS 노드에서 인증 키를 가져옵니다.

      구문

      cat /var/lib/ceph/mds/ceph-MDS_NODE/keyring

      예제

      [root@mons-2 ~]# cat /var/lib/ceph/mds/ceph-mds-1/keyring

      이 키 링의 경우 다음과 같은 기능을 추가합니다. 

      caps mds =  "allow"
caps mon = "allow profile mds"
caps osd = "allow *"

    6. Ceph Object Gateway의 경우 모든 Ceph Object Gateway 노드에서 인증 키를 가져옵니다.

      구문

      cat /var/lib/ceph/radosgw/ceph-CEPH_OBJECT_GATEWAY_NODE/keyring

      예제

      [root@mons-3 ~]# cat /var/lib/ceph/radosgw/ceph-rgw-1/keyring

      이 키 링의 경우 다음과 같은 기능을 추가합니다. 

      caps mon = "allow rw"
caps osd = "allow *"

  6. Ansible 관리 노드에서 이전 단계에서 가져온 모든 인증 키를 사용하여 파일을 생성합니다.

    예제

    [root@admin ~]# cat /tmp/monstore/keyring

[mon.]
	key = AQAa+RxhAAAAABAApmwud0GQHX0raMBc9zTAYQ==
	caps mon = "allow *"
[client.admin]
	key = AQAo+RxhcYWtGBAAiY4kKltMGnAXqPLM2A+B8w==
	caps mds = "allow *"
	caps mgr = "allow *"
	caps mon = "allow *"
	caps osd = "allow *"
[mgr.mons-1]
	key = AQA++RxhAAAAABAAKdG1ETTEMR8KPa9ZpfcIzw==
	caps mds = "allow *"
	caps mon = "allow profile mgr"
	caps osd = "allow *"
[mgr.mons-2]
	key = AQA9+RxhAAAAABAAcCBxsoaIl0sdHTz3dqX4SQ==
	caps mds = "allow *"
	caps mon = "allow profile mgr"
	caps osd = "allow *"
[mgr.mons-3]
	key = AQA/+RxhAAAAABAAwe/mwv0hS79fWP+00W6ypQ==
	caps mds = "allow *"
	caps mon = "allow profile mgr"
	caps osd = "allow *"
[osd.1]
key = AQB/+RxhlH8rFxAAL3mb8Kdb+QuWWdJi+RvwGw==
    caps mgr = "allow profile osd"
    caps mon = "allow profile osd"
    caps osd = "allow *"
[osd.5]
key = AQCE+RxhKSNsHRAAIyLO5g75tqFVsl6MEEzwXw==
    caps mgr = "allow profile osd"
    caps mon = "allow profile osd"
    caps osd = "allow *"
[osd.8]
key = AQCJ+Rxhc0wHJhAA5Bb2kU9Nadpm3UCLASnCfw==
    caps mgr = "allow profile osd"
    caps mon = "allow profile osd"
    caps osd = "allow *"
[osd.2]
key = AQB/+RxhhrQCGRAAUhh77gIVhN8zsTbaKMJuHw==
    caps mgr = "allow profile osd"
    caps mon = "allow profile osd"
    caps osd = "allow *"
[osd.4]
key = AQCE+Rxh0mDxDRAApAeqKOJycW5bpP3IuAhSMw==
    caps mgr = "allow profile osd"
    caps mon = "allow profile osd"
    caps osd = "allow *"
[osd.7]
key = AQCJ+Rxhn+RAIhAAp1ImK1jiazBsDpmTQvVEVw==
    caps mgr = "allow profile osd"
    caps mon = "allow profile osd"
    caps osd = "allow *"
[osd.0]
key = AQB/+RxhPhh+FRAAc5b0nwiuK6o1AIbjVc6tQg==
    caps mgr = "allow profile osd"
    caps mon = "allow profile osd"
    caps osd = "allow *"
[osd.3]
key = AQCE+RxhJv8PARAAqCzH2br1xJmMTNnqH3I9mA==
    caps mgr = "allow profile osd"
    caps mon = "allow profile osd"
    caps osd = "allow *"
[osd.6]
key = AQCI+RxhAt4eIhAAYQEJqSNRT7l2WNl/rYQcKQ==
    caps mgr = "allow profile osd"
    caps mon = "allow profile osd"
    caps osd = "allow *"
[osd.1]
key = AQB/+RxhlH8rFxAAL3mb8Kdb+QuWWdJi+RvwGw==
    caps mgr = "allow profile osd"
    caps mon = "allow profile osd"
    caps osd = "allow *"
[osd.5]
key = AQCE+RxhKSNsHRAAIyLO5g75tqFVsl6MEEzwXw==
    caps mgr = "allow profile osd"
    caps mon = "allow profile osd"
    caps osd = "allow *"
[osd.8]
key = AQCJ+Rxhc0wHJhAA5Bb2kU9Nadpm3UCLASnCfw==
    caps mgr = "allow profile osd"
    caps mon = "allow profile osd"
    caps osd = "allow *"
[osd.2]
key = AQB/+RxhhrQCGRAAUhh77gIVhN8zsTbaKMJuHw==
    caps mgr = "allow profile osd"
    caps mon = "allow profile osd"
    caps osd = "allow *"
[osd.0]
key = AQB/+RxhPhh+FRAAc5b0nwiuK6o1AIbjVc6tQg==
    caps mgr = "allow profile osd"
    caps mon = "allow profile osd"
    caps osd = "allow *"
[osd.3]
key = AQCE+RxhJv8PARAAqCzH2br1xJmMTNnqH3I9mA==
    caps mgr = "allow profile osd"
    caps mon = "allow profile osd"
    caps osd = "allow *"
[osd.6]
key = AQCI+RxhAt4eIhAAYQEJqSNRT7l2WNl/rYQcKQ==
    caps mgr = "allow profile osd"
    caps mon = "allow profile osd"
    caps osd = "allow *"
[mds.mds-1]
	key = AQDs+RxhAF9vERAAdn6ArdUJ31RLr2sBVkzp3A==
        caps mds = "allow"
        caps mon = "allow profile mds"
        caps osd = "allow *"
[mds.mds-2]
	key = AQDs+RxhROoAFxAALAgMfM45wC5ht/vSFN2EzQ==
        caps mds = "allow"
        caps mon = "allow profile mds"
        caps osd = "allow *"
[mds.mds-3]
	key = AQDs+Rxhd092FRAArXLIHAhMp2z9zcWDCSoIDQ==
        caps mds = "allow"
        caps mon = "allow profile mds"
        caps osd = "allow *"
[client.rgw.rgws-1.rgw0]
	key = AQD9+Rxh0iP2MxAAYY76Js1AaZhzFG44cvcyOw==
        caps mon = "allow rw"
        caps osd = "allow *"

  7. 선택 사항: 각 Ceph 모니터 노드에서 모니터 맵을 사용할 수 없는지 확인합니다.

    예제

    [root@mons-1 ~]# ceph-monstore-tool /tmp/monstore get monmap -- --out /tmp/monmap
[root@mons-1 ~]# monmaptool /tmp/monmap --print

monmaptool: monmap file /tmp/monmap
monmaptool: couldn't open /tmp/monmap: (2) No such file or directory

Notice theNo such file or directory  error message if monmap is missed

Notice that the “No such file or directory”  error message if monmap is missed

  8. 각 Ceph 모니터 노드에서 MONITOR_ID,IP_ADDRESS_OF_MONITOR, FSID 를 etc/ceph/ceph.conf 파일에서 가져옵니다.

    예제

    [global]
cluster network = 10.0.208.0/22
fsid = 9877bde8-ccb2-4758-89c3-90ca9550ffea
mon host = [v2:10.0.211.00:3300,v1:10.0.211.00:6789],[v2:10.0.211.13:3300,v1:10.0.211.13:6789],[v2:10.0.210.13:3300,v1:10.0.210.13:6789]
mon initial members = ceph-mons-1, ceph-mons-2, ceph-mons-3

  9. Ceph Monitor 노드에서 모니터 맵을 다시 빌드합니다.

    구문

    monmaptool --create --addv MONITOR_ID IP_ADDRESS_OF_MONITOR --enable-all-features --clobber PATH_OF_MONITOR_MAP --fsid FSID

    예제

    [root@mons-1 ~]# monmaptool --create --addv mons-1 [v2:10.74.177.30:3300,v1:10.74.177.30:6789] --addv mons-2 [v2:10.74.179.197:3300,v1:10.74.179.197:6789] --addv mons-3 [v2:10.74.182.123:3300,v1:10.74.182.123:6789] --enable-all-features --clobber /root/monmap.mons-1 --fsid 6c01cb34-33bf-44d0-9aec-3432276f6be8

monmaptool: monmap file /root/monmap.mons-1
monmaptool: set fsid to 6c01cb34-33bf-44d0-9aec-3432276f6be8
monmaptool: writing epoch 0 to /root/monmap.mon-a (3 monitors)

  10. Ceph 모니터 노드에서 생성된 모니터 맵을 확인합니다.

    구문

    monmaptool PATH_OF_MONITOR_MAP --print

    예제

    [root@mons-1 ~]# monmaptool /root/monmap.mons-1 --print

monmaptool: monmap file /root/monmap.mons-1
epoch 0
fsid 6c01cb34-33bf-44d0-9aec-3432276f6be8
last_changed 2021-11-23 02:57:23.235505
created 2021-11-23 02:57:23.235505
min_mon_release 0 (unknown)
election_strategy: 1
0: [v2:10.74.177.30:3300/0,v1:10.74.177.30:6789/0] mon.mons-1
1: [v2:10.74.179.197:3300/0,v1:10.74.179.197:6789/0] mon.mons-2
2: [v2:10.74.182.123:3300/0,v1:10.74.182.123:6789/0] mon.mons-3

  11. 모니터를 복구하는 Ceph 모니터 노드에서 수집된 맵에서 Ceph Monitor 저장소를 다시 빌드합니다.

    구문

    ceph-monstore-tool /tmp/monstore rebuild -- --keyring KEYRING_PATH  --monmap PATH_OF_MONITOR_MAP

    이 예에서 복구는 mons-1 노드에서 실행됩니다.

    예제

    [root@mons-1 ~]# ceph-monstore-tool /tmp/monstore rebuild -- --keyring /tmp/monstore/keyring  --monmap /root/monmap.mons-1

  12. monstore 디렉터리의 소유권을 ceph로 변경합니다.

    예제

    [root@mons-1 ~]# chown -R ceph:ceph /tmp/monstore

  13. 모든 Ceph 모니터 노드에서 손상된 저장소를 백업하십시오.

    예제

    [root@mons-1 ~]# mv /var/lib/ceph/mon/ceph-mons-1/store.db /var/lib/ceph/mon/ceph-mons-1/store.db.corrupted

  14. 모든 Ceph 모니터 노드에서 손상된 저장소를 교체합니다.

    예제

    [root@mons-1 ~]# scp -r /tmp/monstore/store.db mons-1:/var/lib/ceph/mon/ceph-mons-1/

  15. 모든 Ceph 모니터 노드에서 새 저장소의 소유자를 변경합니다.

    예제

    [root@mons-1 ~]# chown -R ceph:ceph /var/lib/ceph/mon/ceph-HOSTNAME/store.db

  16. 모든 Ceph OSD 노드에서 OSD를 시작합니다.

    예제

    [root@osds-1 ~]# sudo systemctl start ceph-osd.target

  17. 모든 Ceph Monitor 노드에서 모니터를 시작합니다.

    예제

    [root@mons-1 ~]# sudo systemctl start ceph-mon.target

4.8. Ceph 모니터 저장소 복구

Ceph 모니터는 클러스터 맵을 LevelDB와 같은 키-값 저장소에 저장합니다. 모니터에서 저장소가 손상되면 모니터가 예기치 않게 종료되고 다시 시작되지 않습니다. Ceph 로그에 다음과 같은 오류가 포함될 수 있습니다. 

Corruption: error in middle of record
Corruption: 1 missing files; e.g.: /var/lib/ceph/mon/mon.0/store.db/1234567.ldb

프로덕션 환경 Red Hat Ceph Storage 클러스터에서는 Ceph 모니터를 3개 이상 사용하므로 오류가 발생할 경우 다른 모니터로 교체할 수 있습니다. 그러나 특정 상황에서 모든 Ceph 모니터가 저장소가 손상될 수 있습니다. 예를 들어 Ceph Monitor 노드의 디스크 또는 파일 시스템 설정이 잘못 구성된 경우 정전이 발생하면 기본 파일 시스템이 손상될 수 있습니다.

모든 Ceph 모니터에 손상이 있는 경우 ceph-monstore-tool 및 ceph-objectstore-tool 이라는 유틸리티를 사용하여 OSD 노드에 저장된 정보로 복구할 수 있습니다.

중요

다음 절차는 다음 정보를 복구할 수 없습니다.

  • 메타데이터 데몬 서버(MDS) 인증 키 및 맵

  • 배치 그룹 설정:

    • ceph pg set_full_ratio 명령을 사용하여 전체 비율 설정
    • ceph pg set_near full_ratio 명령을 사용하여 설정된 거의 전체 비율
중요

이전 백업에서 Ceph Monitor 저장소를 복원하지 마십시오. 다음 단계를 사용하여 현재 클러스터 상태에서 Ceph Monitor 저장소를 다시 빌드하고 해당 저장소에서 복원합니다.

4.8.1. BlueStore를 사용할 때 Ceph 모니터 저장소 복구

모든 Ceph 모니터에서 Ceph 모니터 저장소가 손상되어 BlueStore 백엔드를 사용하는 경우 다음 절차를 따르십시오.

컨테이너화된 환경에서 이 방법을 사용하려면 먼저 Ceph 리포지토리를 연결하고 컨테이너화되지 않은 Ceph 모니터에 복원해야 합니다.

주의

이 절차에서는 데이터 손실이 발생할 수 있습니다. 이 절차의 단계에 대해 확신이 없으면 Red Hat 기술 지원에 문의하십시오. 복구 프로세스에 대한 지원이 제공됩니다.

사전 요구 사항

  • 베어 메탈 배포

    • rsync 및 ceph-test 패키지가 설치됩니다.

  • 컨테이너 배포

    • 모든 OSD 컨테이너가 중지됩니다.
    • 역할에 따라 Ceph 노드에서 Ceph 리포지토리를 활성화합니다.
    • ceph-test 및 rsync 패키지는 OSD 및 Monitor 노드에 설치됩니다.
    • ceph-mon 패키지는 Monitor 노드에 설치됩니다.
    • ceph-osd 패키지는 OSD 노드에 설치됩니다.

절차

  1. 컨테이너에서 Ceph를 사용하는 경우 Ceph 데이터가 있는 모든 디스크를 임시 위치에 마운트합니다. 모든 OSD 노드에 대해 이 단계를 반복합니다.

    1. 데이터 파티션을 나열합니다. 장치를 설정하는 데 사용한 유틸리티에 따라 ceph-volume 또는 ceph-disk 를 사용합니다. 

      [root@osd ~]# ceph-volume lvm list

      또는 

      [root@osd ~]# ceph-disk list

    2. 임시 위치에 데이터 파티션을 마운트합니다. 

      mount -t tmpfs tmpfs /var/lib/ceph/osd/ceph-$i

    3. SELinux 컨텍스트를 복원하십시오. 

      for i in {OSD_ID}; do restorecon /var/lib/ceph/osd/ceph-$i; done

      OSD_ID 를 OSD 노드에서 공백으로 구분된 숫자 Ceph OSD ID 목록으로 바꿉니다.

    4. 소유자와 그룹을 ceph:ceph 로 변경합니다. 

      for i in {OSD_ID}; do chown -R ceph:ceph /var/lib/ceph/osd/ceph-$i; done

      OSD_ID 를 OSD 노드에서 공백으로 구분된 숫자 Ceph OSD ID 목록으로 바꿉니다.

      중요

      update-mon-db 명령이 Monitor 데이터베이스에 추가 db 및 db .slow 디렉토리를 사용하도록 하는 버그로 인해 이러한 디렉터리도 복사해야 합니다. 이를 위해 다음을 수행합니다.

      1. 컨테이너 외부에서 임시 위치를 준비하여 OSD 데이터베이스를 마운트 및 액세스하고 Ceph Monitor를 복원하는 데 필요한 OSD 맵을 추출합니다. 

        ceph-bluestore-tool --cluster=ceph prime-osd-dir --dev OSD-DATA --path /var/lib/ceph/osd/ceph-OSD-ID

        OSD-DATA 를 OSD 데이터의 에 대한 VG(볼륨 그룹) 또는 LV(논리 볼륨) 경로로 바꾸고 OSD-ID 를 OSD의 ID로 바꿉니다.

      2. BlueStore 데이터베이스와 block.db 사이에 심볼릭 링크를 만듭니다. 

        ln -snf BLUESTORE DATABASE /var/lib/ceph/osd/ceph-OSD-ID/block.db

        BLUESTORE-DATABASE 를 BlueStore 데이터베이스의 볼륨 그룹(VG) 또는 논리 볼륨(LV) 경로로 바꾸고 OSD-ID 를 OSD의 ID로 바꿉니다.

  2. 손상된 저장소가 있는 Ceph 모니터 노드에서 다음 명령을 사용합니다. 모든 노드의 모든 OSD에 대해 반복합니다.

    1. 모든 OSD 노드에서 클러스터 맵을 수집합니다. 

      [root@ mon~]# cd /root/
[root@mon ~]# ms=/tmp/monstore/
[root@mon ~]# db=/root/db/
[root@mon ~]# db_slow=/root/db.slow/

[root@mon ~]# mkdir $ms
[root@mon ~]# for host in $osd_nodes; do
                echo "$host"
                rsync -avz $ms $host:$ms
                rsync -avz $db $host:$db
                rsync -avz $db_slow $host:$db_slow

                rm -rf $ms
                rm -rf $db
                rm -rf $db_slow

                sh -t $host <<EOF
                  for osd in /var/lib/ceph/osd/ceph-*; do
                    ceph-objectstore-tool --type bluestore --data-path \$osd --op update-mon-db --mon-store-path $ms

                   done
                EOF

                      rsync -avz $host:$ms $ms
                      rsync -avz $host:$db $db
                      rsync -avz $host:$db_slow $db_slow
                done

    2. 적절한 기능을 설정합니다. 

      [root@mon ~]# ceph-authtool /etc/ceph/ceph.client.admin.keyring -n mon. --cap mon 'allow *' --gen-key
[root@mon ~]# cat /etc/ceph/ceph.client.admin.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 *"

    3. db 및 db .slow 디렉토리에서 임시 위치로 모든 sst 파일을 이동합니다. 

      [root@mon ~]# mv /root/db/*.sst /root/db.slow/*.sst /tmp/monstore/store.db

    4. 수집된 맵에서 Monitor 저장소를 다시 빌드합니다. 

      [root@mon ~]# ceph-monstore-tool /tmp/monstore rebuild -- --keyring /etc/ceph/ceph.client.admin
      참고

      이 명령을 사용하고 나면 OSD에서 추출한 인증 키와 ceph-monstore-tool 명령줄에 지정된 인증 키만 Ceph의 인증 데이터베이스에 표시됩니다. 클라이언트가 클러스터에 액세스할 수 있도록 클라이언트, Ceph 관리자, Ceph 개체 게이트웨이 등과 같은 기타 인증 키를 다시 생성하거나 가져와야 합니다.

    5. 손상된 저장소를 백업합니다. 모든 Ceph Monitor 노드에 대해 이 단계를 반복합니다. 

      mv /var/lib/ceph/mon/ceph-HOSTNAME/store.db /var/lib/ceph/mon/ceph-HOSTNAME/store.db.corrupted

      HOSTNAME 을 Ceph Monitor 노드의 호스트 이름으로 바꿉니다.

    6. 손상된 저장소를 교체합니다. 모든 Ceph Monitor 노드에 대해 이 단계를 반복합니다. 

      scp -r /tmp/monstore/store.db HOSTNAME:/var/lib/ceph/mon/ceph-HOSTNAME/

      HOSTNAME 을 모니터 노드의 호스트 이름으로 바꿉니다.

    7. 새 저장소의 소유자를 변경합니다. 모든 Ceph Monitor 노드에 대해 이 단계를 반복합니다. 

      chown -R ceph:ceph /var/lib/ceph/mon/ceph-HOSTNAME/store.db

      HOSTNAME 을 Ceph Monitor 노드의 호스트 이름으로 바꿉니다.

  3. 컨테이너에서 Ceph를 사용하는 경우 모든 노드에서 임시 마운트된 OSD를 모두 마운트 해제합니다. 

    [root@osd ~]# umount /var/lib/ceph/osd/ceph-*

  4. 모든 Ceph Monitor 데몬을 시작합니다. 

    [root@mon ~]# systemctl start ceph-mon *

  5. 모니터가 쿼럼을 구성할 수 있는지 확인합니다.

    • 베어 메탈 배포 

      [root@mon ~]# ceph -s

    • 컨테이너 

      [user@admin ~]$ docker exec ceph-mon-_HOSTNAME_ ceph -s

      HOSTNAME 을 Ceph Monitor 노드의 호스트 이름으로 바꿉니다.

  6. Ceph Manager 인증 키를 가져오고 모든 Ceph Manager 프로세스를 시작합니다. 

    ceph auth import -i /etc/ceph/ceph.mgr.HOSTNAME.keyring
systemctl start ceph-mgr@HOSTNAME

    HOSTNAME 을 Ceph Manager 노드의 호스트 이름으로 바꿉니다.

  7. 모든 OSD 노드에서 모든 OSD 프로세스를 시작합니다. 

    [root@osd ~]# systemctl start ceph-osd *

  8. OSD가 서비스로 반환되는지 확인합니다.

    • 베어 메탈 배포 

      [root@mon ~]# ceph -s

    • 컨테이너 

      [user@admin ~]$ docker exec ceph-mon-_HOSTNAME_ ceph -s

      HOSTNAME 을 Ceph Monitor 노드의 호스트 이름으로 바꿉니다.

추가 리소스

4.9. 추가 리소스

5장. Ceph OSD 문제 해결

이 장에서는 Ceph OSD와 관련된 가장 일반적인 오류를 수정하는 방법에 대해 설명합니다.

5.1. 사전 요구 사항

  • 네트워크 연결을 확인합니다. 자세한 내용은 네트워킹 문제 해결을 참조하십시오.
  • ceph 상태 명령을 사용하여 모니터에 쿼럼이 있는지 확인합니다. 명령에서 상태(HEALTH_OK, HEALTH_ WARN 또는 HEALTH_ERR )를 반환하는 경우 모니터가 쿼럼을 구성할 수 있습니다. 그렇지 않은 경우 먼저 모니터 문제를 해결합니다. 자세한 내용은 Ceph 모니터 문제 해결을 참조하십시오. Ceph 상태에 대한 자세한 내용은 Ceph 상태이해를 참조하십시오.
  • 선택적으로 리밸런싱 프로세스를 중지하여 시간과 리소스를 절약할 수 있습니다. 자세한 내용은 Stopping 및 리밸런싱 을 참조하십시오.

5.2. 가장 일반적인 Ceph OSD 오류

다음 표에는 Ceph 상태 세부 정보 명령에서 반환하거나 Ceph 로그에 포함된 가장 일반적인 오류 메시지가 나열되어 있습니다. 테이블에서는 오류를 설명하는 해당 섹션에 대한 링크를 제공하고 문제를 해결하는 특정 절차를 가리킵니다.

5.2.1. 사전 요구 사항

  • Ceph OSD 노드에 대한 루트 수준 액세스.

5.2.2. Ceph OSD 오류 메시지

일반적인 Ceph OSD 오류 메시지 테이블과 잠재적인 수정 사항.

오류 메시지보기

HEALTH_ERR

전체 osds

Full OSDS

HEALTH_WARN

backfillfull osds

Backfillfull OSDS

거의 전체 osds

거의 전체 OSDS

OSD가 다운되었습니다

OSDS가 다운되었습니다

비활성 OSDS

요청이 차단됨

느린 요청 또는 요청이 차단됨

느린 요청

느린 요청 또는 요청이 차단됨

5.2.3. Ceph 로그의 일반적인 Ceph OSD 오류 메시지

Ceph 로그에 있는 일반적인 Ceph OSD 오류 메시지 테이블과 잠재적인 수정 사항에 대한 링크입니다.

오류 메시지로그 파일보기

heartbeat_check: osd.X에서 응답하지 않음

기본 클러스터 로그

비활성 OSDS

잘못 표시되었습니다.

기본 클러스터 로그

비활성 OSDS

OSD에 느린 요청이 있습니다.

기본 클러스터 로그

느린 요청 또는 요청이 차단됨

실패 어설션(0 == "hit star timeout")

OSD 로그

OSD 다운

5.2.4. 전체 OSD

ceph 상태 세부 정보 명령은 다음과 유사한 오류 메시지를 반환합니다. 

HEALTH_ERR 1 full osds
osd.3 is full at 95%

이 의미

Ceph에서는 클라이언트가 전체 OSD 노드에서 I/O 작업을 수행하지 못하여 데이터 손실을 방지합니다. 클러스터가 mon _osd_full_ratio 매개 변수로 설정된 용량에 도달하면 HEALTH_ ERR full osds 메시지를 반환합니다. 기본적으로 이 매개변수는 0.05로 설정되며 이는 클러스터 용량의 95%를 의미합니다.

이 문제를 해결하려면

사용 원시 스토리지 (%RAW USED)의 백분율을 결정합니다. 

# ceph df

%RAW USED 가 70-75%를 초과하면 다음을 수행할 수 있습니다.

  • 불필요한 데이터를 삭제합니다. 이는 생산 가동 중지 시간을 방지하기 위한 단기 솔루션입니다.
  • 새 OSD 노드를 추가하여 클러스터를 확장합니다. 이는 Red Hat에서 권장하는 장기적인 솔루션입니다.

추가 리소스

5.2.5. Backfillfull OSD

ceph 상태 세부 정보 명령은 다음과 유사한 오류 메시지를 반환합니다. 

health: HEALTH_WARN
3 backfillfull osd(s)
Low space hindering backfill (add storage if this doesn't resolve itself): 32 pgs backfill_toofull

이것은 무엇을 의미합니까?

하나 이상의 OSD가 백필 풀 임계값을 초과하면 Ceph에서 이 장치로 데이터를 재조정하지 않습니다. 이는 재조정이 완료되지 않고 클러스터가 가득 차 있음을 알리는 조기 경고입니다. 백전체 임계값의 기본값은 90%입니다.

이 문제를 해결하려면

풀에서 사용률을 확인합니다. 

ceph df

%RAW USED 가 70-75%를 초과하는 경우 다음 작업 중 하나를 수행할 수 있습니다.

  • 불필요한 데이터를 삭제합니다. 이는 생산 가동 중지 시간을 방지하기 위한 단기 솔루션입니다.
  • 새 OSD 노드를 추가하여 클러스터를 확장합니다. 이는 Red Hat에서 권장하는 장기적인 솔루션입니다.

  • 복구 프로세스를 계속할 수 있도록 PG가 back full_toofull 에 고정된 PG가 포함된 OSD의 백 필 풀 비율을 늘립니다. 가능한 한 빨리 클러스터에 새 스토리지를 추가하거나 데이터를 제거하여 더 많은 OSD를 채우지 않도록 합니다.

    구문

    ceph osd set-backfillfull-ratio VALUE

    VALUE 의 범위는 0.0에서 1.0입니다.

    예제

    [ceph: root@host01/]# ceph osd set-backfillfull-ratio 0.92

추가 리소스

5.2.6. 거의 전체 OSD

ceph 상태 세부 정보 명령은 다음과 유사한 오류 메시지를 반환합니다. 

HEALTH_WARN 1 nearfull osds
osd.2 is near full at 85%

이 의미

클러스터가 mon osd nearfull ratio defaults 매개 변수에 설정된 용량에 도달하면 Ceph에서 nearfull osd s 메시지를 반환합니다. 기본적으로 이 매개변수는 cluster5로 설정되며 이는 클러스터 용량의 85%를 의미합니다.

Ceph는 가능한 최상의 방식으로 CRUSH 계층 구조를 기반으로 데이터를 배포하지만 동일한 배포를 보장할 수는 없습니다. uneven 데이터 배포의 주요 원인과 거의 전체 osds 메시지는 다음과 같습니다.

  • OSD는 클러스터의 OSD 노드에 분산되지 않습니다. 즉, 일부 OSD 노드는 다른 항목보다 훨씬 많은 OSD를 호스팅하거나 CRUSH 맵에 있는 일부 OSD의 가중치는 용량에 적합하지 않습니다.
  • 배치 그룹(PG) 수는 OSD 수, 사용 사례, OSD당 대상 PG, OSD 사용률에 따라 올바르지 않습니다.
  • 클러스터는 부적절한 CRUSH 튜닝 가능 항목을 사용합니다.
  • OSD의 백엔드 스토리지는 거의 가득 차 있습니다.

이 문제를 해결하려면 다음을 수행합니다.

  1. PG 개수가 충분한지 확인하고 필요한 경우 늘립니다.
  2. CRUSH 튜닝 가능 항목을 클러스터 버전에 최적으로 사용하는지 확인하고 그렇지 않은 경우 조정합니다.
  3. 사용률에 따라 OSD의 가중치를 변경합니다.

  4. 분산을 위해 OSD 간에 배치 그룹(PG) 배치를 최적화하는 Ceph Manager 밸런서 모듈을 활성화합니다.

    예제

    [root@mon ~]# ceph mgr module enable balancer

  5. OSD에서 사용하는 디스크에 남은 공간 크기를 확인합니다.

    1. 일반적으로 사용되는 공간 OSD 양을 보려면 다음을 수행합니다. 

      [root@mon ~]# ceph osd df

    2. 특정 노드에서 사용하는 공간 OSD의 양을 보려면 다음을 수행합니다. 가까운 OSD 가 포함된 노드에서 다음 명령을 사용합니다. 

      $ df
    3. 필요한 경우 새 OSD 노드를 추가합니다.

추가 리소스

5.2.7. OSD 다운

ceph 상태 명령은 다음과 유사한 오류를 반환합니다. 

HEALTH_WARN 1/3 in osds are down

이 의미

서비스 실패 또는 다른 OSD와의 통신 문제로 인해 ceph-osd 프로세스 중 하나를 사용할 수 없습니다. 그 결과 남아 있는 ceph-osd 데몬은 이 오류를 모니터에 보고했습니다.

ceph-osd 데몬이 실행 중이지 않은 경우 기본 OSD 드라이브 또는 파일 시스템이 손상되거나 누락된 인증 키와 같은 다른 오류가 발생하면 데몬이 시작되지 않습니다.

대부분의 경우 네트워킹 문제로 인해 ceph-osd 데몬이 실행 중이지만 여전히 down 으로 표시됩니다.

이 문제를 해결하려면

  1. 다운 된 OSD 확인 : 

    [root@mon ~]# ceph health detail
HEALTH_WARN 1/3 in osds are down
osd.0 is down since epoch 23, last address 192.168.106.220:6800/11080

  2. ceph-osd 데몬을 다시 시작하십시오. 

    [root@mon ~]# systemctl restart ceph-osd@OSD_NUMBER

    OSD_NUMBER 를 다운 된 OSD의 ID로 바꿉니다. 예를 들면 다음과 같습니다. 

    [root@mon ~]# systemctl restart ceph-osd@0
    1. ceph-osd를 시작할 수 없는 경우 ceph -osd 데몬의 단계를 시작할 수 없습니다.
    2. ceph-osd 데몬을 시작할 수 있지만 down 으로 표시되면 ceph-osd 데몬이 실행 중이지만 아직 '다운'으로 표시되어 있습니다.

ceph-osd 데몬을 시작할 수 없습니다.

  1. 다수의 OSD(일반적으로 12개 이상)가 포함된 노드가 있는 경우 기본 최대 스레드(PID 수)가 충분한지 확인합니다. 자세한 내용은 PID 수 증가를 참조하십시오.
  2. OSD 데이터와 저널 파티션이 올바르게 마운트되었는지 확인합니다. ceph-volume lvm list 명령을 사용하여 Ceph Storage 클러스터와 연결된 모든 장치와 볼륨을 나열한 다음 올바르게 마운트되었는지 수동으로 검사할 수 있습니다. 자세한 내용은 mount(8) 매뉴얼 페이지를 참조하십시오.
  3. ERROR: 누락된 인증 키가 있는 경우 인증 오류 메시지에 cephx를 사용할 수 없는 경우 OSD가 인증 키 누락입니다.

  4. ERROR: /var/lib/ceph/osd/ceph-1 오류 메시지에서 OSD 수퍼 블록을 열 수 없는 경우 ceph-osd 데몬이 기본 파일 시스템을 읽을 수 없습니다. 이 오류의 문제를 해결하고 수정하는 방법에 대한 지침은 다음 단계를 참조하십시오.

    참고

    OSD 호스트 부팅 시 이 오류 메시지가 반환되면 Red Hat Bugzilla 1439210 에서 추적된 알려진 문제를 나타낼 수 있으므로 지원 티켓을 엽니다.

  5. 해당 로그 파일을 확인하여 오류의 원인을 확인합니다. 기본적으로 Ceph는 베어 메탈 배포를 위해 /var/log/ceph/ 디렉터리에 로그 파일을 저장합니다.

    참고

    컨테이너 기반 배포의 경우 Ceph는 journald 에 로그를 생성합니다. Ceph 구성 파일의 [global]에서 log_to_file 매개변수를 true 로 설정하여 /var/log/ceph 의 파일에 로깅을 활성화할 수 있습니다. 자세한 내용은 ceph 로그 이해를 참조하십시오.

    1. 다음과 유사한 EIO 오류 메시지는 기본 디스크의 실패를 나타냅니다.

      이 문제를 해결하려면 기본 OSD 디스크를 교체합니다. 자세한 내용은 OSD 드라이브 교체를 참조하십시오.

    2. 로그에 다음과 같은 other FAILED 어설 션 오류가 포함된 경우 지원 티켓을 엽니다. 자세한 내용은 Red Hat 지원 문의를 참조하십시오. 

      FAILED assert(0 == "hit suicide timeout")

  6. dmesg 출력에 기본 파일 시스템 또는 디스크가 있는 오류가 있는지 확인합니다. 

    $ dmesg
    1. dmesg 출력에 SCSI 오류 오류 메시지가 포함된 경우 Red Hat 고객 포털의 SCSI 오류 코드 솔루션 파인더 솔루션을 참조하여 문제를 해결하는 가장 좋은 방법을 확인하십시오.
    2. 또는 기본 파일 시스템을 수정할 수 없는 경우 OSD 드라이브를 교체합니다. 자세한 내용은 OSD 드라이브 교체를 참조하십시오.

  7. 다음과 같은 분할 오류로 OSD가 실패한 경우 필요한 정보를 수집하고 지원 티켓을 여십시오. 자세한 내용은 Red Hat 지원 문의를 참조하십시오. 

    Caught signal (Segmentation fault)

ceph-osd 가 실행 중이지만 여전히 down으로 표시됩니다.

  1. 해당 로그 파일을 확인하여 오류의 원인을 확인합니다. 기본적으로 Ceph는 베어 메탈 배포의 /var/log/ceph/ 디렉터리에 로그 파일을 저장합니다.

    참고

    컨테이너 기반 배포의 경우 Ceph는 journald 에 로그를 생성합니다. Ceph 구성 파일의 [global]에서 log_to_file 매개변수를 true 로 설정하여 /var/log/ceph 의 파일에 로깅을 활성화할 수 있습니다. 자세한 내용은 ceph 로그 이해를 참조하십시오.

    1. 로그에 다음과 유사한 오류 메시지가 포함된 경우 Flapping OSDs를 참조하십시오. 

      wrongly marked me down
heartbeat_check: no reply from osd.2 since back
    2. 다른 오류가 표시되면 지원 티켓을 엽니다. 자세한 내용은 Red Hat 지원 문의를 참조하십시오.

추가 리소스

5.2.8. OSD를 래핑

ceph -w | grep osds 명령은 OSD 를 잠시 중단한 후 다시 한 번 표시합니다. 

# ceph -w | grep osds
2021-04-05 06:27:20.810535 mon.0 [INF] osdmap e609: 9 osds: 8 up, 9 in
2021-04-05 06:27:24.120611 mon.0 [INF] osdmap e611: 9 osds: 7 up, 9 in
2021-04-05 06:27:25.975622 mon.0 [INF] HEALTH_WARN; 118 pgs stale; 2/9 in osds are down
2021-04-05 06:27:27.489790 mon.0 [INF] osdmap e614: 9 osds: 6 up, 9 in
2021-04-05 06:27:36.540000 mon.0 [INF] osdmap e616: 9 osds: 7 up, 9 in
2021-04-05 06:27:39.681913 mon.0 [INF] osdmap e618: 9 osds: 8 up, 9 in
2021-04-05 06:27:43.269401 mon.0 [INF] osdmap e620: 9 osds: 9 up, 9 in
2021-04-05 06:27:54.884426 mon.0 [INF] osdmap e622: 9 osds: 8 up, 9 in
2021-04-05 06:27:57.398706 mon.0 [INF] osdmap e624: 9 osds: 7 up, 9 in
2021-04-05 06:27:59.669841 mon.0 [INF] osdmap e625: 9 osds: 6 up, 9 in
2021-04-05 06:28:07.043677 mon.0 [INF] osdmap e628: 9 osds: 7 up, 9 in
2021-04-05 06:28:10.512331 mon.0 [INF] osdmap e630: 9 osds: 8 up, 9 in
2021-04-05 06:28:12.670923 mon.0 [INF] osdmap e631: 9 osds: 9 up, 9 in

또한 Ceph 로그에는 다음과 유사한 오류 메시지가 포함되어 있습니다. 

2021-07-25 03:44:06.510583 osd.50 127.0.0.1:6801/149046 18992 : cluster [WRN] map e600547 wrongly marked me down
2021-07-25 19:00:08.906864 7fa2a0033700 -1 osd.254 609110 heartbeat_check: no reply from osd.2 since back 2021-07-25 19:00:07.444113 front 2021-07-25 18:59:48.311935 (cutoff 2021-07-25 18:59:48.906862)

이 의미

OSD를 래핑하는 주된 원인은 다음과 같습니다.

  • 스크럽 또는 복구와 같은 특정 스토리지 클러스터 작업은 대규모 인덱스 또는 대규모 배치 그룹이 있는 오브젝트에서 이러한 작업을 수행하는 경우 비정상적인 시간이 걸립니다. 일반적으로 이러한 작업이 완료된 후 플랩 OSD 문제가 해결됩니다.
  • 기본 물리적 하드웨어 문제. 이 경우 ceph 상태 세부 정보 명령은 느린 요청 오류 메시지도 반환합니다.
  • 네트워크 문제.

Ceph OSD는 스토리지 클러스터의 사설 네트워크가 실패하거나 공용 클라이언트를 향한 네트워크에 중요한 대기 시간이 있는 상황을 관리할 수 없습니다.

Ceph OSD는 사설 네트워크를 사용하여 하트비트 패킷을 서로 전송하여 해당 패킷이 작동 중임을 나타냅니다 . 프라이빗 스토리지 클러스터 네트워크가 제대로 작동하지 않으면 OSD에서 하트비트 패킷을 보내고 받을 수 없습니다. 그 결과 서로 Ceph 모니터 로 표시되고 up 으로 표시됩니다.

Ceph 구성 파일의 다음 매개변수는 이 동작에 영향을 미칩니다.

매개변수설명기본값

osd_heartbeat_grace_time

OSD가 하트비트 패킷이 반환될 때까지 OSD를 Ceph 모니터 로 보고할 때까지 기다리는 시간입니다.

20초

mon_osd_min_down_reporters

Ceph 모니터가 OSD를 down으로 표시하기 전에 다른 OSD를 down 으로 보고해야 하는 OSD 수는 몇 개입니까 ?

2

이 테이블에서는 기본 구성에서 Ceph 모니터가 첫 번째 OSD에 대해 3개의 개별 보고서만 다운 된 경우 OSD를 down 으로 표시합니다. 단일 호스트에 네트워크 문제가 발생하는 경우도 있는 경우 전체 클러스터에 OSD가 토핑될 수 있습니다. 이는 호스트에 상주하는 OSD가 클러스터의 다른 OSD를 down 으로 보고하기 때문입니다.

참고

기본 OSD 시나리오에는 OSD 프로세스가 시작된 다음 즉시 종료되는 상황이 포함되지 않습니다.

이 문제를 해결하려면

  1. ceph 상태 세부 명령의 출력을 다시 확인합니다. 느린 요청 오류 메시지가 포함된 경우 이 문제를 해결하는 방법에 대한 자세한 내용은 를 참조하십시오. 

    # ceph health detail
HEALTH_WARN 30 requests are blocked > 32 sec; 3 osds have slow requests
30 ops are blocked > 268435 sec
1 ops are blocked > 268435 sec on osd.11
1 ops are blocked > 268435 sec on osd.18
28 ops are blocked > 268435 sec on osd.39
3 osds have slow requests

  2. down 으로 표시되고 있는 OSD와 해당 노드에 있는 OSD를 확인합니다. 

    # ceph osd tree | grep down
  3. 토핑 OSD가 포함된 노드에서 네트워킹 문제를 해결하고 수정합니다. 자세한 내용은 네트워킹 문제 해결을 참조하십시오.

  4. 또는 noup 및 no down 플래그를 설정하여 OSD를 down 및 up 으로 표시를 중지할 수도 있습니다. 

    # ceph osd set noup
# ceph osd set nodown
    중요

    noup 및 nodown 플래그를 사용하면 문제의 근본 원인을 해결하지 않고 OSD만 토핑하지 못하게 합니다. 지원 티켓을 열려면 자세한 내용은 Red Hat 지원 문의 섹션을 참조하십시오.

중요

Ceph OSD 노드에서 MTU가 잘못 구성되었거나 네트워크 스위치 수준에서 MTU가 잘못되어 OSD를 래핑할 수 있습니다. 이 문제를 해결하려면 계획된 다운 타임과 함께 코어 및 액세스 네트워크 스위치에서 MTU를 모든 스토리지 클러스터 노드에서 균일한 크기로 설정합니다. 이 설정을 변경하면 네트워크 내에서 문제를 숨길 수 있으므로 osd heartbeat 최소 크기를 조정하지 마십시오. 실제 네트워크 불일치가 해결되지 않습니다.

추가 리소스

5.2.9. 느린 요청 또는 요청이 차단됨

ceph-osd 데몬은 요청에 응답하는 속도가 느리고 ceph 상태 세부 정보 명령은 다음과 유사한 오류 메시지를 반환합니다. 

HEALTH_WARN 30 requests are blocked > 32 sec; 3 osds have slow requests
30 ops are blocked > 268435 sec
1 ops are blocked > 268435 sec on osd.11
1 ops are blocked > 268435 sec on osd.18
28 ops are blocked > 268435 sec on osd.39
3 osds have slow requests

또한 Ceph 로그에는 다음과 유사한 오류 메시지가 포함되어 있습니다. 

2015-08-24 13:18:10.024659 osd.1 127.0.0.1:6812/3032 9 : cluster [WRN] 6 slow requests, 6 included below; oldest blocked for > 61.758455 secs
2016-07-25 03:44:06.510583 osd.50 [WRN] slow request 30.005692 seconds old, received at {date-time}: osd_op(client.4240.0:8 benchmark_data_ceph-1_39426_object7 [write 0~4194304] 0.69848840) v4 currently waiting for subops from [610]

이 의미

느린 요청이 있는 OSD는 osd_op_complaint_time 매개 변수로 정의된 시간 내에 큐의 IOPS(초당 IOPS) 작업을 서비스할 수 없는 모든 OSD입니다. 기본적으로 이 매개변수는 30초로 설정됩니다.

OSD의 요청이 느린 주요 원인은 다음과 같습니다.

  • 디스크 드라이브, 호스트, 랙 또는 네트워크 스위치와 같은 기본 하드웨어 문제
  • 네트워크 문제. 이러한 문제는 일반적으로 플랩 OSD와 연결됩니다. 자세한 내용은 Flapping OSDs 를 참조하십시오.
  • 시스템 로드

다음 테이블에서는 느린 요청 유형을 보여줍니다. dump_historic_ops 관리 소켓 명령을 사용하여 느린 요청 유형을 확인합니다. 관리 소켓에 대한 자세한 내용은 Red Hat Ceph Storage 4 관리 가이드의 Ceph 관리 소켓 사용 섹션을 참조하십시오.

느린 요청 유형설명

rw 잠금 대기 중

OSD는 작업을 위해 배치 그룹의 잠금을 얻기 위해 대기 중입니다.

하위 작업 대기 중

OSD는 복제본 OSD가 작업을 저널에 적용할 때까지 대기 중입니다.

도달한 플래그 포인트 없음

OSD가 주요 운영 이정표에 도달하지 않았습니다.

성능이 저하된 오브젝트 대기 중

OSD는 지정된 횟수의 개체를 아직 복제하지 않았습니다.

이 문제를 해결하려면

  1. 디스크 드라이브, 호스트, 랙 또는 네트워크 스위치와 같이 느린 또는 블록 요청이 있는 OSD가 공통 하드웨어 부분을 공유하는지 확인합니다.

  2. OSD가 디스크를 공유하는 경우:

    1. smartmontools 유틸리티를 사용하여 디스크 또는 로그의 상태를 확인하여 디스크 오류를 확인합니다.

      참고

      smartmontools 유틸리티는 smartmontools 패키지에 포함되어 있습니다.

    2. iostat 유틸리티를 사용하여 OSD 디스크에서 I/O 대기 보고서(%iowai)를 가져와 디스크의 로드가 많은지 확인합니다.

      참고

      iostat 유틸리티는 sysstat 패키지에 포함되어 있습니다.

  3. OSD가 다른 서비스와 노드를 공유하는 경우:

    1. RAM 및 CPU 사용률 확인
    2. netstat 유틸리티를 사용하여 NIC(네트워크 인터페이스 컨트롤러)에 대한 네트워크 통계를 확인하고 네트워킹 문제를 해결합니다. 자세한 내용은 네트워킹 문제 해결을 참조하십시오.
  4. OSD가 랙을 공유하는 경우 랙의 네트워크 스위치를 확인합니다. 예를 들어 점보 프레임을 사용하는 경우 경로의 NIC에 점보 프레임이 설정되어 있는지 확인합니다.
  5. 느린 요청으로 OSD에서 공유하는 일반적인 하드웨어를 확인하거나 하드웨어 및 네트워킹 문제를 해결하고 수정할 수 없는 경우 지원 티켓을 엽니다. 자세한 내용은 Red Hat 지원 문의를 참조하십시오.

추가 리소스

5.3. 리밸런싱 중지 및 시작

OSD가 실패하거나 중지하면 CRUSH 알고리즘에서 나머지 OSD에 데이터를 재배포하는 리밸런싱 프로세스를 자동으로 시작합니다.

리밸런싱에는 시간과 리소스가 걸릴 수 있으므로, OSD 문제를 해결하거나 유지 관리하는 동안 리밸런싱을 중지하는 것이 좋습니다.

참고

중지된 OSD 내의 배치 그룹은 문제 해결 및 유지 관리 중에 성능이 저하 됩니다.

사전 요구 사항

  • Ceph 모니터 노드에 대한 루트 수준 액세스.

절차

  1. 이렇게 하려면 OSD를 중지하기 전에 noout 플래그를 설정합니다. 

    [root@mon ~]# ceph osd set noout

  2. 문제 해결 또는 유지 관리를 완료하면 noout 플래그를 설정 해제하여 리밸런싱을 시작합니다. 

    [root@mon ~]# ceph osd unset noout

추가 리소스

5.4. OSD 데이터 파티션 마운트

OSD 데이터 파티션이 올바르게 마운트되지 않으면 ceph-osd 데몬을 시작할 수 없습니다. 파티션이 예상대로 마운트되지 않은 경우 이 섹션의 단계에 따라 마운트합니다.

이 섹션은 베어 메탈 배포에만 적용됩니다.

사전 요구 사항

  • ceph-osd 데몬에 액세스합니다.
  • Ceph 모니터 노드에 대한 루트 수준 액세스.

절차

  1. 파티션을 마운트합니다. 

    [root@ceph-mon]# mount -o noatime PARTITION /var/lib/ceph/osd/CLUSTER_NAME-OSD_NUMBER

    PARTITION 을 OSD 데이터 전용 OSD 드라이브의 파티션 경로로 바꿉니다. 클러스터 이름과 OSD 번호를 지정합니다.

    예제

    [root@ceph-mon]# mount -o noatime /dev/sdd1 /var/lib/ceph/osd/ceph-0

  2. 실패한 ceph-osd 데몬을 시작합니다. 

    [root@ceph-mon]# systemctl start ceph-osd@OSD_NUMBER

    OSD_NUMBER 를 OSD의 ID로 바꿉니다.

    예제

    [root@ceph-mon]# systemctl start ceph-osd@0

추가 리소스

  • 자세한 내용은 Red Hat Ceph Storage 문제 해결 가이드 의 Down OSDs를 참조하십시오.

5.5. OSD 드라이브 교체

Ceph는 내결함성을 위해 설계되었으므로 데이터가 손실되지 않고 성능이 저하된 상태에서 작동할 수 있습니다. 결과적으로 데이터 스토리지 드라이브가 실패해도 Ceph가 작동할 수 있습니다. 실패한 드라이브의 컨텍스트에서 성능이 저하된 상태는 다른 OSD에 저장된 데이터의 추가 복사본이 클러스터의 다른 OSD로 자동으로 백필링됨을 의미합니다. 그러나 이 경우 실패한 OSD 드라이브를 교체하고 OSD를 수동으로 다시 생성합니다.

드라이브에 실패하면 Ceph에서 OSD를 down 으로 보고합니다. 

HEALTH_WARN 1/3 in osds are down
osd.0 is down since epoch 23, last address 192.168.106.220:6800/11080
참고

Ceph는 네트워킹 또는 권한 문제의 결과로 OSD를 down 으로 표시할 수 있습니다. 자세한 내용은 Down OSDs 를 참조하십시오.

일반적으로 서버는 핫스왑 가능 드라이브와 함께 배포되므로 장애가 발생한 드라이브를 가져와 노드를 중단하지 않고 새 드라이브로 교체할 수 있습니다. 전체 절차에는 다음 단계가 포함됩니다.

  1. Ceph 클러스터에서 OSD를 제거합니다. 자세한 내용은 Ceph 클러스터에서 OSD 제거 절차를 참조하십시오.
  2. 드라이브를 교체합니다. 자세한 내용은 Replacing the physical drive] 섹션을 참조하십시오.
  3. 클러스터에 OSD를 추가합니다. 자세한 내용은 Ceph 클러스터에 OSD 추가] 절차를 참조하십시오.

사전 요구 사항

  • Ceph 모니터 노드에 대한 루트 수준 액세스.

  • 다운 된 OSD 확인 : 

    [root@mon ~]# ceph osd tree | grep -i down
ID WEIGHT  TYPE NAME      UP/DOWN REWEIGHT PRIMARY-AFFINITY
 0 0.00999         osd.0     down  1.00000          1.00000

  • OSD 프로세스가 중지되었는지 확인합니다. OSD 노드에서 다음 명령을 사용합니다. 

    [root@mon ~]# systemctl status ceph-osd@_OSD_NUMBER_

  • OSD_NUMBER 를 down 으로 표시된 OSD의 ID로 바꿉니다. 예를 들면 다음과 같습니다. 

    [root@mon ~]# systemctl status ceph-osd@osd.0
...
   Active: inactive (dead)

    ceph-osd 데몬이 실행 중인 경우. down 으로 표시되지만 해당 ceph-osd 데몬이 실행 중인 OSD 문제 해결에 대한 자세한 내용은 Down OSD를 참조하십시오.

절차: Ceph 클러스터에서 OSD 제거

  1. OSD 를 출력으로 표시합니다. 

    [root@mon ~]# ceph osd out osd.OSD_NUMBER

    OSD_NUMBER 를 down 으로 표시된 OSD의 ID로 바꿉니다. 예를 들면 다음과 같습니다. 

    [root@mon ~]# ceph osd out osd.0
marked out osd.0.
    참고

    OSD가 다운 되면 Ceph는 OSD에서 하트비트 패킷을 받지 못하면 600초 후에 자동으로 출력됩니다. 이 경우 실패한 OSD 데이터의 복사본이 있는 기타 OSD가 백필을 시작하여 필요한 사본 수가 클러스터 내에 존재하는지 확인합니다. 클러스터가 백필링되는 동안 클러스터의 성능이 저하된 상태가 됩니다.

  2. 실패한 OSD가 다시 채워졌는지 확인합니다. 출력에는 다음과 유사한 정보가 포함됩니다. 

    [root@mon ~]# ceph -w | grep backfill
2017-06-02 04:48:03.403872 mon.0 [INF] pgmap v10293282: 431 pgs: 1 active+undersized+degraded+remapped+backfilling, 28 active+undersized+degraded, 49 active+undersized+degraded+remapped+wait_backfill, 59 stale+active+clean, 294 active+clean; 72347 MB data, 101302 MB used, 1624 GB / 1722 GB avail; 227 kB/s rd, 1358 B/s wr, 12 op/s; 10626/35917 objects degraded (29.585%); 6757/35917 objects misplaced (18.813%); 63500 kB/s, 15 objects/s recovering
2017-06-02 04:48:04.414397 mon.0 [INF] pgmap v10293283: 431 pgs: 2 active+undersized+degraded+remapped+backfilling, 75 active+undersized+degraded+remapped+wait_backfill, 59 stale+active+clean, 295 active+clean; 72347 MB data, 101398 MB used, 1623 GB / 1722 GB avail; 969 kB/s rd, 6778 B/s wr, 32 op/s; 10626/35917 objects degraded (29.585%); 10580/35917 objects misplaced (29.457%); 125 MB/s, 31 objects/s recovering
2017-06-02 04:48:00.380063 osd.1 [INF] 0.6f starting backfill to osd.0 from (0'0,0'0] MAX to 2521'166639
2017-06-02 04:48:00.380139 osd.1 [INF] 0.48 starting backfill to osd.0 from (0'0,0'0] MAX to 2513'43079
2017-06-02 04:48:00.380260 osd.1 [INF] 0.d starting backfill to osd.0 from (0'0,0'0] MAX to 2513'136847
2017-06-02 04:48:00.380849 osd.1 [INF] 0.71 starting backfill to osd.0 from (0'0,0'0] MAX to 2331'28496
2017-06-02 04:48:00.381027 osd.1 [INF] 0.51 starting backfill to osd.0 from (0'0,0'0] MAX to 2513'87544

  3. CRUSH 맵에서 OSD를 제거합니다. 

    [root@mon ~]# ceph osd crush remove osd.OSD_NUMBER

    OSD_NUMBER 를 down 으로 표시된 OSD의 ID로 바꿉니다. 예를 들면 다음과 같습니다. 

    [root@mon ~]# ceph osd crush remove osd.0
removed item id 0 name 'osd.0' from crush map

  4. OSD와 관련된 인증 키를 제거합니다. 

    [root@mon ~]# ceph auth del osd.OSD_NUMBER

    OSD_NUMBER 를 down 으로 표시된 OSD의 ID로 바꿉니다. 예를 들면 다음과 같습니다. 

    [root@mon ~]# ceph auth del osd.0
updated

  5. Ceph Storage 클러스터에서 OSD를 제거합니다. 

    [root@mon ~]# ceph osd rm osd.OSD_NUMBER

    OSD_NUMBER 를 down 으로 표시된 OSD의 ID로 바꿉니다. 예를 들면 다음과 같습니다. 

    [root@mon ~]# ceph osd rm osd.0
removed osd.0

    OSD를 성공적으로 제거한 경우 다음 명령의 출력에 표시되지 않습니다. 

    [root@mon ~]# ceph osd tree

  6. 베어 메탈 배포의 경우 실패한 드라이브를 마운트 해제합니다. 

    [root@mon ~]# umount /var/lib/ceph/osd/CLUSTER_NAME-OSD_NUMBER

    클러스터 이름과 OSD의 ID를 지정합니다. 예를 들면 다음과 같습니다. 

    [root@mon ~]# umount /var/lib/ceph/osd/ceph-0/

    드라이브를 마운트 해제한 경우 다음 명령의 출력에 표시되지 않습니다. 

    [root@mon ~]# df -h

절차: 물리적 드라이브 교체

물리적 드라이브 교체에 대한 자세한 내용은 하드웨어 노드에 대한 설명서를 참조하십시오.

  1. 드라이브가 hot-swappable인 경우 실패한 드라이브를 새 드라이브로 교체합니다.
  2. 드라이브가 hot-swappable이 아니고 노드에 여러 OSD가 포함된 경우 전체 노드를 종료하고 물리 드라이브를 교체해야 할 수 있습니다. 클러스터가 백필되지 않도록 하십시오. 자세한 내용은 Red Hat Ceph Storage 문제 해결 가이드 의 중지 및 리밸런싱 장을 참조하십시오.
  3. 드라이브가 /dev/ 디렉토리 아래에 표시되면 드라이브 경로를 기록합니다.
  4. OSD를 수동으로 추가하려면 OSD 드라이브를 찾고 디스크를 포맷합니다.

절차: Ceph 클러스터에 OSD 추가

  1. OSD를 다시 추가합니다.

    1. Ansible을 사용하여 클러스터를 배포한 경우 Ceph 관리 서버에서 ceph-anible 플레이북을 다시 실행합니다.

      • 베어 메탈 배포:

        구문

        ansible-playbook site.yml -i hosts --limit NEW_OSD_NODE_NAME

        예제

        [user@admin ceph-ansible]$ ansible-playbook site.yml -i hosts --limit node03

      • 컨테이너 배포:

        구문

        ansible-playbook site-container.yml -i hosts --limit NEW_OSD_NODE_NAME

        예제

        [user@admin ceph-ansible]$ ansible-playbook site-container.yml -i hosts --limit node03

    2. OSD를 수동으로 추가한 경우 Red Hat Ceph Storage 4 운영 가이드의 명령줄 인터페이스를 사용하여 Ceph OSD 추가 섹션을 참조하십시오.

  2. CRUSH 계층 구조가 정확한지 확인합니다. 

    [root@mon ~]# ceph osd tree

  3. CRUSH 계층 구조의 OSD 위치에 만족하지 않으면 OSD를 원하는 위치로 이동합니다. 

    [root@mon ~]# ceph osd crush move BUCKET_TO_MOVE BUCKET_TYPE=PARENT_BUCKET

    예를 들어 sdd:row1 에 있는 버킷을 루트 버킷으로 이동하려면 다음을 수행합니다. 

    [root@mon ~]# ceph osd crush move ssd:row1 root=ssd:root

추가 리소스

5.6. PID 수 증가

12개가 넘는 Ceph OSD를 포함하는 노드가 있는 경우 특히 복구 중에 기본 최대 스레드(PID 수)가 포함될 수 있습니다. 결과적으로 일부 ceph-osd 데몬이 종료되고 다시 시작되지 못할 수 있습니다. 이 경우 허용되는 최대 스레드 수를 늘립니다.

절차

숫자를 일시적으로 늘리려면 다음을 수행합니다. 

[root@mon ~]# sysctl -w kernel.pid.max=4194303

수를 영구적으로 늘리려면 다음과 같이 /etc/sysctl.conf 파일을 업데이트합니다. 

kernel.pid.max = 4194303

5.7. 전체 스토리지 클러스터에서 데이터 삭제

Ceph는 mon_osd_full_ratio 매개 변수로 지정된 용량에 도달하고 전체 osds 오류 메시지를 반환하는 OSD에서 I/O 작업을 자동으로 방지합니다.

다음 절차에서는 불필요한 데이터를 삭제하여 이 오류를 해결하는 방법을 설명합니다.

참고

mon_osd_full_ratio 매개 변수는 클러스터를 생성할 때 full_ratio 매개 변수의 값을 설정합니다. 나중에 mon_osd_full_ratio 의 값을 변경할 수 없습니다. full_ratio 값을 일시적으로 늘리려면 set-full-ratio 를 대신 늘립니다.

사전 요구 사항

  • Ceph 모니터 노드에 대한 루트 수준 액세스.

절차

  1. full_ratio 의 현재 값을 결정하십시오. 기본값으로 설정된 값은 5.05로 설정됩니다. 

    [root@mon ~]# ceph osd dump | grep -i full
full_ratio 0.95

  2. set-full-ratio 의 값을 20487로 일시적으로 늘리십시오. 

    [root@mon ~]# ceph osd set-full-ratio 0.97
    중요

    Red Hat은 set-full-ratio 를 70%7 이상의 값으로 설정하지 않는 것이 좋습니다. 이 매개 변수를 더 높은 값으로 설정하면 복구 프로세스가 더 어려워집니다. 결과적으로 전체 OSD를 전혀 복구하지 못할 수 있습니다.

  3. 매개 변수를 4.17로 성공적으로 설정했는지 확인합니다. 

    [root@mon ~]# ceph osd dump | grep -i full
full_ratio 0.97

  4. 클러스터 상태를 모니터링합니다. 

    [root@mon ~]# ceph -w

    클러스터 상태가 full 에서 nearfull 으로 변경되는 즉시 불필요한 데이터를 삭제합니다.

  5. full_ratio의 값을 기본값으로 다시 설정하십시오. 

    [root@mon ~]# ceph osd set-full-ratio 0.95

  6. 매개 변수를 4.15로 성공적으로 설정했는지 확인합니다. 

    [root@mon ~]# ceph osd dump | grep -i full
full_ratio 0.95

추가 리소스

  • Red Hat Ceph 스토리지 문제 해결 가이드 의 전체 OSD 섹션.
  • Red Hat Ceph Storage 문제 해결 가이드 의 전체 OSD 섹션.

5.8. 스토리지 클러스터를 업그레이드한 후 OSD 재배포

이 섹션에서는 운영 체제를 업그레이드하지 않고 전용 장치에서 block.db 를 사용하여 Red Hat Ceph Storage 3에서 Red Hat Ceph Storage 4로 업그레이드한 후 OSDS를 재배포하는 방법에 대해 설명합니다.

이 절차는 지정하지 않는 한 베어 메탈 및 컨테이너 배포에 모두 적용됩니다.

업그레이드 후 OSD를 재배포하는 플레이북이 오류 메시지를 사용하여 실패할 수 있습니다. 

GPT headers found, they must be removed on: /dev/vdb

block.db 장치에서 파티션을 생성하고 Ansible 플레이북을 실행하여 OSD를 다시 배포할 수 있습니다.

사전 요구 사항

  • 실행 중인 Red Hat Ceph Storage 클러스터.
  • Ansible 관리 노드에 대한 root 수준 액세스.
  • Ansible 사용자 계정이 생성되었습니다.

절차

  1. block.db 장치에 파티션을 만듭니다. 이 sgdisk 명령은 사용 가능한 다음 파티션 번호를 자동으로 사용합니다.

    구문

    sgdisk --new=0:0:_JOURNAL_SIZE_ -- NEW_DEVICE_PATH

    예제

    [root@admin ~]# sgdisk --new=0:0:+2G -- /dev/vdb

  2. host_vars 디렉터리를 생성합니다. 

    [root@admin ~]# mkdir /usr/share/ceph-ansible/host_vars

  3. host_vars 디렉터리로 이동합니다. 

    [root@admin ~]# cd /usr/share/ceph-ansible/host_vars

  4. 스토리지 클러스터의 모든 호스트에 호스트 파일을 생성합니다.

    구문

    touch NEW_OSD_HOST_NAME

    예제

    [root@admin host_vars]# touch osd5

  5. hosts 파일에서 데이터 장치를 정의합니다.

    구문

    lvm_volumes:
- data: DATA_DEVICE_PATH
  journal: NEW_DEVICE_PARTITION_PATH
- data: RUNNING_OSD_DATA_DEVICE_PATH
    journal: PARTITION_PATH
- data: RUNNING_OSD_DATA_DEVICE_PATH
    journal: PARTITION_PATH

    예제

    lvm_volumes:
- data: /dev/vdd
  journal: /dev/vdb2
- data: /dev/sdb
  journal: /dev/sdc1
- data: /dev/sdb
  journal: /dev/sdc2

  6. Ansible 사용자로 전환하고 Ansible이 모든 Ceph 노드에 연결할 수 있는지 확인합니다. 

    [admin@admin ~]$ ansible all -m ping

  7. 디렉터리를 Ansible 구성 디렉터리로 변경합니다. 

    [admin@admin ~]$ cd /usr/share/ceph-ansible

  8. --limit 옵션을 사용하여 다음 Ansible 플레이북을 실행합니다.

    • 베어 메탈 배포: 

      [admin@admin ceph-ansible]$ ansible-playbook site.yml --limit osds -i hosts

    • 컨테이너 배포: 

      [admin@admin ceph-ansible]$ ansible-playbook site-container.yml --limit osds -i hosts

추가 리소스

  • OSD 배포에 대한 자세한 내용은 Red Hat Ceph Storage 운영 가이드 의 디스크 오류 처리 섹션을 참조하십시오.

6장. Ceph MDSs 문제 해결

스토리지 관리자는 Ceph MDS(메타데이터 서버)를 사용할 때 발생할 수 있는 가장 일반적인 문제를 해결할 수 있습니다. 발생할 수 있는 몇 가지 일반적인 오류:

  • MDS 노드 장애에 새 MDS 배포가 필요합니다.
  • MDS 노드 문제로 인해 MDS 노드를 재배포해야 합니다.

6.1. Ceph MDS 재배포

Ceph 메타데이터 서버(MDS) 데몬은 Ceph 파일 시스템을 배포하는 데 필요합니다. 클러스터의 MDS 노드가 실패하면 MDS 서버를 제거하고 새 또는 기존 서버를 추가하여 Ceph 메타데이터 서버를 재배포할 수 있습니다. 명령줄 인터페이스 또는 Ansible 플레이북을 사용하여 MDS 서버를 추가하거나 제거할 수 있습니다.

6.1.1. 사전 요구 사항

  • 실행 중인 Red Hat Ceph Storage 클러스터.

6.1.2. Ansible을 사용하여 Ceph MDS 제거

Ansible을 사용하여 Ceph 메타데이터 서버(MDS)를 제거하려면 shrink-mds 플레이북을 사용합니다.

참고

MDS가 제거되면 사용할 대체 MDS가 없는 경우 클라이언트에서 파일 시스템을 사용할 수 없게 됩니다. 이것이 바람직하지 않은 경우 오프라인으로 전환하려는 MDS를 제거하기 전에 추가 MDS를 추가하는 것이 좋습니다.

사전 요구 사항

  • 하나 이상의 MDS 노드
  • Ansible에서 배포한 Red Hat Ceph Storage 클러스터 실행.
  • Ansible 관리 노드에 대한 root 또는 sudo 액세스.

절차

  1. Ansible 관리 노드에 로그인합니다.

  2. /usr/share/ceph-ansible 디렉터리로 변경합니다.

    예제

    [ansible@admin ~]$ cd /usr/share/ceph-ansible

  3. Ansible shrink-mds.yml 플레이북을 실행하고 메시지가 표시되면 yes 를 입력하여 클러스터 축소를 확인합니다.

    구문

    ansible-playbook infrastructure-playbooks/shrink-mds.yml -e mds_to_kill=ID -i hosts

    ID 를 삭제하려는 MDS 노드의 ID로 바꿉니다. 플레이북이 실행될 때마다 Ceph MDS가 하나만 제거할 수 있습니다.

    예제

    [ansible @admin ceph-ansible]$ ansible-playbook infrastructure-playbooks/shrink-mds.yml -e mds_to_kill=node02 -i hosts

  4. root 또는 sudo 액세스로 /usr/share/ceph-ansible/hosts 인벤토리 파일을 열고 편집한 후 [mds] 섹션의 MDS 노드를 삭제합니다.

    구문

    [mdss]
MDS_NODE_NAME
MDS_NODE_NAME

    예제

    [mdss]
node01
node03

    이 예에서는 node02 가 [mdss] 목록에서 제거되었습니다.

검증

  • MDS 데몬 상태를 확인합니다.

    구문

    ceph fs dump

    예제

    [ansible@admin ceph-ansible]$ ceph fs dump

[mds.node01 {0:115304} state up:active seq 5 addr [v2:172.25.250.10:6800/695510951,v1:172.25.250.10:6801/695510951]]

Standby daemons:
[mds.node03 {-1:144437} state up:standby seq 2 addr [v2:172.25.250.11:6800/172950087,v1:172.25.250.11:6801/172950087]]

추가 리소스

6.1.3. 명령줄 인터페이스를 사용하여 Ceph MDS 제거

명령줄 인터페이스를 사용하여 Ceph 메타데이터 서버(MDS)를 수동으로 제거할 수 있습니다.

참고

현재 MDS가 제거되면 사용할 대체 MDS가 없는 경우 클라이언트에서 파일 시스템을 사용할 수 없게 됩니다. 이것이 바람직하지 않은 경우 기존 MDS를 제거하기 전에 MDS를 추가하는 것이 좋습니다.

사전 요구 사항

  • ceph-common 패키지가 설치되어 있습니다.
  • 실행 중인 Red Hat Ceph Storage 클러스터.
  • MDS 노드에 대한 root 또는 sudo 액세스

절차

  1. MDS 데몬을 삭제할 Ceph MDS 노드에 로그인합니다.

  2. Ceph MDS 서비스를 중지합니다.

    구문

    sudo systemctl stop ceph-mds@HOST_NAME

    HOST_NAME 을 데몬이 실행 중인 호스트의 짧은 이름으로 교체합니다.

    예제

    [admin@node02 ~]$ sudo systemctl stop ceph-mds@node02

  3. MDS 서비스를 이 노드에 재배포하지 않는 경우 다음을 비활성화합니다.

    구문

    sudo systemctl disable ceph-mds@HOST_NAME

    데몬을 비활성화하려면 HOST_NAME 을 호스트의 짧은 이름으로 교체합니다.

    예제

    [admin@node02 ~]$ sudo systemctl disable ceph-mds@node02

  4. MDS 노드의 /var/lib/ceph/mds/ceph-MDS_ID 디렉터리를 삭제합니다.

    구문

    sudo rm -fr /var/lib/ceph/mds/ceph-MDS_ID

    MDS_ID 를 MDS 데몬을 삭제하려는 MDS 노드의 ID로 바꿉니다.

    예제

    [admin@node02 ~]$ sudo rm -fr /var/lib/ceph/mds/ceph-node02

검증

  • MDS 데몬 상태를 확인합니다.

    구문

    ceph fs dump

    예제

    [ansible@admin ceph-ansible]$ ceph fs dump

[mds.node01 {0:115304} state up:active seq 5 addr [v2:172.25.250.10:6800/695510951,v1:172.25.250.10:6801/695510951]]

Standby daemons:
[mds.node03 {-1:144437} state up:standby seq 2 addr [v2:172.25.250.11:6800/172950087,v1:172.25.250.11:6801/172950087]]

추가 리소스

6.1.4. Ansible을 사용하여 Ceph MDS 추가

Ansible 플레이북을 사용하여 Ceph MDS(메타데이터 서버)를 추가합니다.

사전 요구 사항

  • Ansible에서 배포한 Red Hat Ceph Storage 클러스터 실행.
  • Ansible 관리 노드에 대한 root 또는 sudo 액세스.
  • MDS 노드로 프로비저닝할 수 있는 신규 또는 기존 서버.

절차

  1. Ansible 관리 노드에 로그인합니다.

  2. /usr/share/ceph-ansible 디렉터리로 변경합니다.

    예제

    [ansible@admin ~]$ cd /usr/share/ceph-ansible

  3. root 또는 sudo 액세스로 /usr/share/ceph-ansible/hosts 인벤토리 파일을 열고 편집하고 [mds] 섹션에 MDS 노드를 추가합니다.

    구문

    [mdss]
MDS_NODE_NAME
NEW_MDS_NODE_NAME

    NEW_MDS_NODE_NAME 을 MDS 서버를 설치할 노드의 호스트 이름으로 교체합니다.

    또는 [osds] 및 [mds] 섹션에 동일한 노드를 추가하여 한 노드에서 OSD 데몬을 사용하여 MDS 데몬을 배치할 수 있습니다.

    예제

    [mdss]
node01
node03

  4. ansible 사용자로 Ansible 플레이북을 실행하여 MDS 노드를 프로비저닝합니다.

    • 베어 메탈 배포: 

      [ansible@admin ceph-ansible]$ ansible-playbook site.yml --limit mdss -i hosts

    • 컨테이너 배포: 

      [ansible@admin ceph-ansible]$ ansible-playbook site-container.yml --limit mdss -i hosts

      Ansible 플레이북 실행을 완료하면 새로운 Ceph MDS 노드가 스토리지 클러스터에 나타납니다.

검증

  • MDS 데몬 상태를 확인합니다.

    구문

    ceph fs dump

    예제

    [ansible@admin ceph-ansible]$ ceph fs dump

[mds.node01 {0:115304} state up:active seq 5 addr [v2:172.25.250.10:6800/695510951,v1:172.25.250.10:6801/695510951]]

Standby daemons:
[mds.node03 {-1:144437} state up:standby seq 2 addr [v2:172.25.250.11:6800/172950087,v1:172.25.250.11:6801/172950087]]

  • 또는 ceph mds stat 명령을 사용하여 MDS가 활성 상태인지 확인할 수 있습니다.

    구문

    ceph mds stat

    예제

    [ansible@admin ceph-ansible]$ ceph mds stat
cephfs:1 {0=node01=up:active} 1 up:standby

추가 리소스

6.1.5. 명령줄 인터페이스를 사용하여 Ceph MDS 추가

명령줄 인터페이스를 사용하여 수동으로 Ceph 메타데이터 서버(MDS)를 추가할 수 있습니다.

사전 요구 사항

  • ceph-common 패키지가 설치되어 있습니다.
  • 실행 중인 Red Hat Ceph Storage 클러스터.
  • MDS 노드에 대한 root 또는 sudo 액세스
  • MDS 노드로 프로비저닝할 수 있는 신규 또는 기존 서버.

절차

  1. 노드에 로그인하고 MDS 마운트 지점을 생성하여 새 MDS 노드를 추가합니다.

    구문

    sudo mkdir /var/lib/ceph/mds/ceph-MDS_ID

    MDS_ID 를 MDS 데몬을 추가할 MDS 노드의 ID로 바꿉니다.

    예제

    [admin@node03 ~]$ sudo mkdir /var/lib/ceph/mds/ceph-node03

  2. Cephx 인증을 사용하는 경우 새 MDS 노드인 경우 인증 키를 생성합니다.

    구문

    sudo ceph auth get-or-create mds.MDS_ID mon 'profile mds' mgr 'profile mds' mds 'allow *' osd 'allow *' > /var/lib/ceph/mds/ceph-MDS_ID/keyring

    MDS 데몬을 배포할 MDS 노드의 ID로 MDS_ID 를 교체합니다.

    예제

    [admin@node03 ~]$ sudo ceph auth get-or-create mds.node03 mon 'profile mds' mgr 'profile mds' mds 'allow *' osd 'allow *' > /var/lib/ceph/mds/ceph-node03/keyring

    참고

    cephx 인증은 기본적으로 활성화되어 있습니다. Cephx 인증에 대한 자세한 내용은 추가 리소스 섹션의 Cephx 인증 링크를 참조하십시오.

  3. MDS 데몬을 시작합니다.

    구문

    sudo systemctl start ceph-mds@HOST_NAME

    HOST_NAME 을 데몬을 시작할 호스트의 짧은 이름으로 교체합니다.

    예제

    [admin@node03 ~]$ sudo systemctl start ceph-mds@node03

  4. MDS 서비스를 활성화합니다.

    구문

    systemctl enable ceph-mds@HOST_NAME

    서비스를 활성화하려면 HOST_NAME 을 호스트의 짧은 이름으로 교체합니다.

    예제

    [admin@node03 ~]$ sudo systemctl enable ceph-mds@node03

검증

  • MDS 데몬 상태를 확인합니다.

    구문

    ceph fs dump

    예제

    [admin@mon]$ ceph fs dump

[mds.node01 {0:115304} state up:active seq 5 addr [v2:172.25.250.10:6800/695510951,v1:172.25.250.10:6801/695510951]]

Standby daemons:
[mds.node03 {-1:144437} state up:standby seq 2 addr [v2:172.25.250.11:6800/172950087,v1:172.25.250.11:6801/172950087]]

  • 또는 ceph mds stat 명령을 사용하여 MDS가 활성 상태인지 확인할 수 있습니다.

    구문

    ceph mds stat

    예제

    [ansible@admin ceph-ansible]$ ceph mds stat
cephfs:1 {0=node01=up:active} 1 up:standby

추가 리소스

7장. 다중 사이트 Ceph Object Gateway 문제 해결

이 장에서는 다중 사이트 Ceph Object Gateways 구성 및 운영 조건과 관련된 가장 일반적인 오류를 수정하는 방법에 대해 설명합니다.

7.1. 사전 요구 사항

  • 실행 중인 Red Hat Ceph Storage 클러스터.
  • 실행 중인 Ceph 개체 게이트웨이.

7.2. Ceph Object Gateway의 코드 정의 오류

Ceph Object Gateway 로그에는 환경의 문제 해결에 도움이 되는 오류 및 경고 메시지가 포함되어 있습니다. 아래 나열된 일반적인 문제 중 일부는 권장되는 해결 방법을 사용하여 확인할 수 있습니다.

일반적인 오류 메시지

data_sync: 오류: 동기화 작업에서 반환된 오류
이는 하위 수준의 버킷 동기화 프로세스에서 오류를 반환했다고 보고하는 고급 데이터 동기화 프로세스입니다. 이 메시지는 중복되어 있습니다. 버킷 동기화 오류가 로그에 표시됩니다.
데이터 동기화: 오류: 오브젝트를 동기화하지 못했습니다. BUCKET_NAME:_OBJECT_NAME_
프로세스가 원격 게이트웨이에서 HTTP를 통해 필요한 개체를 가져오지 못하거나 프로세스가 RADOS에 해당 오브젝트를 쓰는 데 실패하고 다시 시도됩니다.
데이터 동기화: 오류: 동기화 실패, 백업 중 (sync_status=2)
위의 조건 중 하나를 반영하는 낮은 수준 메시지, 특히 동기화하기 전에 데이터가 삭제되었으므로 -2 ENOENT 상태를 표시합니다.
데이터 동기화: 오류: 동기화 실패, 백업 중 (sync_status=-5)
위 조건 중 하나를 반영하는 낮은 수준의 메시지, 특히 RADOS에 해당 오브젝트를 작성하지 못하여 -5 EIO를 표시했습니다.
오류: 원격 데이터 로그 정보를 가져오지 못했습니다: ret=11
이것은 libcurl 의 EAGAIN 일반 오류 코드로, 다른 게이트웨이의 오류 조건을 반영합니다. 기본적으로 다시 시도됩니다.
메타 동기화: 오류 : (2) 해당 파일이나 디렉토리를 사용하여 mdlog 정보를 읽지 못했습니다
mdlog의 shard가 생성되지 않았으므로 동기화할 항목이 없습니다.

오류 메시지 동기화

오브젝트를 동기화하지 못했습니다
프로세스가 원격 게이트웨이에서 HTTP를 통해 이 오브젝트를 가져오지 못하거나 해당 오브젝트를 RADOS에 쓰지 못하고 다시 시도됩니다.
버킷 인스턴스를 동기화하지 못했습니다. 일시적으로 사용할 수 없는 리소스(11)
기본 영역과 보조 영역 간의 연결 문제.
버킷 인스턴스를 동기화하지 못했습니다. (55) 작업이 취소되었습니다
동일한 RADOS 오브젝트에 대한 쓰기 사이에 경쟁 조건이 있습니다.

추가 리소스

7.3. 다중 사이트 Ceph Object Gateway 동기화

다중 사이트 동기화는 다른 영역에서 변경 로그를 읽습니다. 메타데이터 및 데이터 삭제에서 동기화 진행 상황을 자세히 보려면 다음 명령을 사용할 수 있습니다. 

radosgw-admin sync status

이 명령을 실행하면 소스 영역 뒤에 있는 로그 shard가 나열됩니다.

참고

radosgw-admin sync status 명령을 실행할 때 shard 복구를 관찰할 수 있는 경우가 있습니다. 데이터 동기화의 경우 각각 독립적으로 처리되는 복제 로그의 128개의 shard가 있습니다. 이러한 복제 로그 이벤트에서 트리거한 작업으로 인해 네트워크, 스토리지 또는 다른 곳에서 오류가 발생하는 경우 해당 오류가 추적되므로 작업이 나중에 다시 시도할 수 있습니다. 주어진 shard에는 재시도해야 하는 오류가 있지만 radosgw-admin sync status 명령은 shard를 복구로 보고합니다. 이러한 복구는 자동으로 수행되므로 작업자가 문제를 해결하기 위해 개입할 필요가 없습니다.

위의 보고서 로그 shard를 실행한 동기화 상태의 결과가 뒤에 있는 경우 X 의 shard-id를 대체하는 다음 명령을 실행합니다.

구문

radosgw-admin data sync status --shard-id=X --source-zone=ZONE_NAME

예제

[root@rgw ~]# radosgw-admin data sync status --shard-id=27 --source-zone=_us-eest
{
  "shard_id": 27,
  "marker": {
         "status": "incremental-sync",
         "marker": "1_1534494893.816775_131867195.1",
         "next_step_marker": "",
         "total_entries": 1,
         "pos": 0,
         "timestamp": "0.000000"
   },
   "pending_buckets": [],
   "recovering_buckets": [
         "pro-registry:4ed07bb2-a80b-4c69-aa15-fdc17ae6f5f2.314303.1:26"
   ]
}

출력에는 동기화 옆에 있는 버킷과 이전 오류로 인해 다시 시도되는 버킷(있는 경우)이 나열됩니다.

다음 명령을 사용하여 개별 버킷의 상태를 검사하고 X의 버킷 ID를 대체합니다. 

radosgw-admin bucket sync status --bucket=X.
교체…​
버킷의 ID 번호가 있는 X 입니다.

결과는 소스 영역 뒤에 있는 버킷 인덱스 로그 shard를 보여줍니다.

동기화의 일반적인 오류 는 종종 다른 게이트웨이에서 동기화가 이미 진행 중임을 의미합니다. 다음 명령으로 읽을 수 있는 동기화 오류 로그에 기록된 오류를 읽습니다. 

radosgw-admin sync error list

동기화 프로세스는 성공할 때까지 다시 시도합니다. 개입이 필요할 수 있는 오류가 발생할 수 있습니다.

7.3.1. 다중 사이트 Ceph Object Gateway 데이터 동기화를 위한 성능 카운터

Ceph Object Gateway의 다중 사이트 구성에 다음과 같은 성능 카운터를 사용하여 데이터 동기화를 측정할 수 있습니다.

  • poll_latency 는 원격 복제 로그에 대한 요청의 대기 시간을 측정합니다.
  • fetch_bytes 는 데이터 동기화로 가져온 개체 및 바이트 수를 측정합니다.

ceph 데몬 명령을 사용하여 성능 카운터의 현재 지표 데이터를 확인합니다.

구문

ceph daemon /var/run/ceph/ceph-client.rgw.RGW_ID.asok perf dump data-sync-from-ZONE_NAME

예제

[root@rgw ~]#  ceph daemon /var/run/ceph/ceph-client.rgw.host02-rgw0.103.94309060818504.asok perf dump data-sync-from-us-west

{
    "data-sync-from-us-west": {
        "fetch bytes": {
            "avgcount": 54,
            "sum": 54526039885
        },
        "fetch not modified": 7,
        "fetch errors": 0,
        "poll latency": {
            "avgcount": 41,
            "sum": 2.533653367,
            "avgtime": 0.061796423
        },
        "poll errors": 0
    }
}

참고

데몬을 실행하는 노드에서 ceph 데몬 명령을 실행해야 합니다.

추가 리소스

  • 성능 카운터에 대한 자세한 내용은 Red Hat Ceph Storage 관리 가이드 의 Ceph 성능 카운터 장을 참조하십시오.

8장. Ceph iSCSI 게이트웨이 문제 해결 (Limited Availability)

스토리지 관리자는 Ceph iSCSI 게이트웨이를 사용할 때 발생할 수 있는 가장 일반적인 오류를 해결할 수 있습니다. 다음은 발생할 수 있는 일반적인 오류 중 일부입니다.

  • iSCSI 로그인 문제.
  • VMware ESXi는 다양한 연결 오류를 보고합니다.
  • 시간 제한 오류.
참고

이 기술은 제한적인 가용성입니다. 자세한 내용은 사용 중단된 기능 장을 참조하십시오.

8.1. 사전 요구 사항

  • 실행 중인 Red Hat Ceph Storage 클러스터.
  • 실행 중인 Ceph iSCSI 게이트웨이.
  • 네트워크 연결을 확인합니다.

8.2. VMware ESXi에서 스토리지 실패를 유발하는 연결에 대한 정보를 수집합니다.

시스템 및 디스크 정보를 수집하면 어떤 iSCSI 대상이 연결이 끊어졌는지 판별하는 데 도움이 되며 스토리지 오류가 발생할 수 있습니다. 필요한 경우 이 정보를 Red Hat의 글로벌 지원 서비스에 제공하여 Ceph iSCSI 게이트웨이 문제를 해결할 수도 있습니다.

사전 요구 사항

  • 실행 중인 Red Hat Ceph Storage 클러스터.
  • 실행 중인 Ceph iSCSI 게이트웨이, iSCSI 대상.
  • 실행 중인 VMware ESXi 환경인 iSCSI 이니시에이터.
  • VMware ESXi 노드에 대한 루트 수준 액세스.

절차

  1. VWware ESXi 노드에서 커널 로그를 엽니다. 

    [root@esx:~]# more /var/log/vmkernel.log

  2. VMware ESXi 커널 로그에서 다음 오류 메시지에서 정보를 수집합니다.

    예제

    2020-03-30T11:07:07.570Z cpu32:66506)iscsi_vmk:
iscsivmk_ConnRxNotifyFailure: Sess [ISID: 00023d000005 TARGET:
iqn.2017-12.com.redhat.iscsi-gw:ceph-igw TPGT: 3 TSIH: 0]

    이 메시지에서 ISID 번호, TARGET 이름 및TPGT(대상 포털 그룹 태그) 번호를 기록합니다. 이 예에서는 다음이 있습니다. 

    ISID: 00023d000005
TARGET: iqn.2017-12.com.redhat.iscsi-gw:ceph-igw
TPGT: 3

    예제

    2020-03-30T11:07:07.570Z cpu32:66506)iscsi_vmk:
iscsivmk_ConnRxNotifyFailure: vmhba64:CH:4 T:0 CN:0: Connection rx
notifying failure: Failed to Receive. State=Bound

    이 메시지에서 어댑터 채널 (CH)번호를기록합니다. 이 예에서는 다음이 있습니다. 

    vmhba64:CH:4 T:0

  3. Ceph iSCSI 게이트웨이 노드의 원격 주소를 찾으려면 다음을 수행합니다. 

    [root@esx:~]# esxcli iscsi session connection list

    예제

    ...
vmhba64,iqn.2017-12.com.redhat.iscsi-gw:ceph-igw,00023d000003,0
   Adapter: vmhba64
   Target: iqn.2017-12.com.redhat.iscsi-gw:ceph-igw 1
   ISID: 00023d000003 2
   CID: 0
   DataDigest: NONE
   HeaderDigest: NONE
   IFMarker: false
   IFMarkerInterval: 0
   MaxRecvDataSegmentLength: 131072
   MaxTransmitDataSegmentLength: 262144
   OFMarker: false
   OFMarkerInterval: 0
   ConnectionAddress: 10.2.132.2
   RemoteAddress: 10.2.132.2 3
   LocalAddress: 10.2.128.77
   SessionCreateTime: 03/28/18 21:45:19
   ConnectionCreateTime: 03/28/18 21:45:19
   ConnectionStartTime: 03/28/18 21:45:19
   State: xpt_wait
...

    명령 출력에서 ISID 값과 이전에 수집한 TARGET 이름 값과 일치한 다음 RemoteAddress 값을 기록합니다. 이 예에서는 다음이 있습니다. 

    Target: iqn.2017-12.com.redhat.iscsi-gw:ceph-igw
ISID: 00023d000003
RemoteAddress: 10.2.132.2

    이제 Ceph iSCSI 게이트웨이 노드에서 자세한 정보를 수집하여 문제를 추가로 해결할 수 있습니다.

    1. RemoteAddress 값으로 언급된 Ceph iSCSI 게이트웨이 노드에서 sosreport 를 실행하여 시스템 정보를 수집합니다. 

      [root@igw ~]# sosreport

  4. dead 상태로 전환된 디스크를 찾으려면 다음을 수행하십시오. 

    [root@esx:~]# esxcli storage nmp device list

    예제

    ...
iqn.1998-01.com.vmware:d04-nmgjd-pa-zyc-sv039-rh2288h-xnh-732d78fd-00023d000004,iqn.2017-12.com.redhat.iscsi-gw:ceph-igw,t,3-naa.60014054a5d46697f85498e9a257567c
   Runtime Name: vmhba64:C4:T0:L4 1
   Device: naa.60014054a5d46697f85498e9a257567c 2
   Device Display Name: LIO-ORG iSCSI Disk
(naa.60014054a5d46697f85498e9a257567c)
   Group State: dead 3
   Array Priority: 0
   Storage Array Type Path Config:
{TPG_id=3,TPG_state=ANO,RTP_id=3,RTP_health=DOWN} 4
   Path Selection Policy Path Config: {non-current path; rank: 0}
...

    명령 출력에서 이전에 수집한 TPG T 번호와 이전에 수집한 TPGT 번호를 일치시킨 다음 장치 값을 기록합니다. 이 예에서는 다음이 있습니다. 

    vmhba64:C4:T0
Device: naa.60014054a5d46697f85498e9a257567c
TPG_id=3

    장치 이름을 사용하여 dead 상태에서 각 iSCSI 디스크에 대한 몇 가지 추가 정보를 수집할 수 있습니다.

    1. iSCSI 디스크에 대한 추가 정보를 수집합니다.

      구문

      esxcli storage nmp path list -d ISCSI_DISK_DEVICE > /tmp/esxcli_storage_nmp_path_list.txt
esxcli storage core device list -d ISCSI_DISK_DEVICE > /tmp/esxcli_storage_core_device_list.txt

      예제

      [root@esx:~]# esxcli storage nmp path list -d naa.60014054a5d46697f85498e9a257567c > /tmp/esxcli_storage_nmp_path_list.txt
[root@esx:~]# esxcli storage core device list -d naa.60014054a5d46697f85498e9a257567c > /tmp/esxcli_storage_core_device_list.txt

  5. VMware ESXi 환경에 대한 추가 정보를 수집합니다. 

    [root@esx:~]# esxcli storage vmfs extent list > /tmp/esxcli_storage_vmfs_extent_list.txt
[root@esx:~]# esxcli storage filesystem list > /tmp/esxcli_storage_filesystem_list.txt
[root@esx:~]# esxcli iscsi session list > /tmp/esxcli_iscsi_session_list.txt
[root@esx:~]# esxcli iscsi session connection list > /tmp/esxcli_iscsi_session_connection_list.txt

  6. 잠재적인 iSCSI 로그인 문제를 확인합니다.

추가 리소스

  • Red Hat 글로벌 지원 서비스에 대한 sosreport생성에 대한 Red Hat의 지식베이스 솔루션을 참조하십시오.
  • Red Hat 글로벌 지원 서비스의 파일 업로드 에 대한 Red Hat의 기술 자료 솔루션을 참조하십시오.
  • 고객 포털에서 Red Hat 지원 케이스 를 여는 방법은 무엇입니까?

8.3. 데이터가 전송되지 않았기 때문에 iSCSI 로그인 실패 확인

iSCSI 게이트웨이 노드에서는 기본적으로 /var/log/messages 인 시스템 로그에서 일반 로그인 협상 실패 메시지가 표시될 수 있습니다.

예제

Apr  2 23:17:05 osd1 kernel: rx_data returned 0, expecting 48.
Apr  2 23:17:05 osd1 kernel: iSCSI Login negotiation failed.

시스템이 이 상태에 있는 동안 이 절차에서 제안된 대로 시스템 정보 수집을 시작합니다.

사전 요구 사항

  • 실행 중인 Red Hat Ceph Storage 클러스터.
  • 실행 중인 Ceph iSCSI 게이트웨이, iSCSI 대상.
  • 실행 중인 VMware ESXi 환경인 iSCSI 이니시에이터.
  • Ceph iSCSI 게이트웨이 노드에 대한 루트 수준 액세스.
  • VMware ESXi 노드에 대한 루트 수준 액세스.

절차

  1. 추가 로깅을 활성화합니다. 

    [root@igw ~]# echo "module iscsi_target_mod +p" > /sys/kernel/debug/dynamic_debug/control
[root@igw ~]# echo "module target_core_mod +p" > /sys/kernel/debug/dynamic_debug/control
  2. 추가 디버깅 정보가 시스템 로그를 채울 때까지 몇 분 정도 기다립니다.

  3. 추가 로깅을 비활성화합니다. 

    [root@igw ~]# echo "module iscsi_target_mod -p" > /sys/kernel/debug/dynamic_debug/control
[root@igw ~]# echo "module target_core_mod -p" > /sys/kernel/debug/dynamic_debug/control

  4. sosreport 를 실행하여 시스템 정보를 수집합니다. 

    [root@igw ~]# sosreport

  5. Ceph iSCSI 게이트웨이와 VMware ESXi 노드의 네트워크 트래픽을 동시에 캡처합니다.

    구문

    tcpdump -s0 -i NETWORK_INTERFACE -w OUTPUT_FILE_PATH

    예제

    [root@igw ~]# tcpdump -s 0 -i eth0 -w /tmp/igw-eth0-tcpdump.pcap

    참고

    포트 3260에서 트래픽을 찾습니다.

    1. 네트워크 패킷 캡처 파일은 커질 수 있으므로 Red Hat 글로벌 지원 서비스에 파일을 업로드하기 전에 iSCSI 대상 및 이니시에이터에서 tcpdump 출력을 압축합니다.

      구문

      gzip OUTPUT_FILE_PATH

      예제

      [root@igw ~]# gzip /tmp/igw-eth0-tcpdump.pcap

  6. VMware ESXi 환경에 대한 추가 정보를 수집합니다. 

    [root@esx:~]# esxcli iscsi session list > /tmp/esxcli_iscsi_session_list.txt
[root@esx:~]# esxcli iscsi session connection list > /tmp/esxcli_iscsi_session_connection_list.txt

    1. 각 iSCSI 디스크에 대한 추가 정보를 나열하고 수집합니다.

      구문

      esxcli storage nmp path list -d ISCSI_DISK_DEVICE > /tmp/esxcli_storage_nmp_path_list.txt

      예제

      [root@esx:~]# esxcli storage nmp device list
[root@esx:~]# esxcli storage nmp path list -d naa.60014054a5d46697f85498e9a257567c > /tmp/esxcli_storage_nmp_path_list.txt
[root@esx:~]# esxcli storage core device list -d naa.60014054a5d46697f85498e9a257567c > /tmp/esxcli_storage_core_device_list.txt

추가 리소스

8.4. 시간 초과 또는 포털 그룹을 찾을 수 없기 때문에 iSCSI 로그인 실패 확인

iSCSI 게이트웨이 노드에서 시간 초과를 표시하거나 시스템 로그에서 대상 포털 그룹 메시지를 찾을 수 없습니다(기본값 /var/log/messages ).

예제

Mar 28 00:29:01 osd2 kernel: iSCSI Login timeout on Network Portal 10.2.132.2:3260

또는

예제

Mar 23 20:25:39 osd1 kernel: Unable to locate Target Portal Group on iqn.2017-12.com.redhat.iscsi-gw:ceph-igw

시스템이 이 상태에 있는 동안 이 절차에서 제안된 대로 시스템 정보 수집을 시작합니다.

사전 요구 사항

  • 실행 중인 Red Hat Ceph Storage 클러스터.
  • 실행 중인 Ceph iSCSI 게이트웨이.
  • Ceph iSCSI 게이트웨이 노드에 대한 루트 수준 액세스.

절차

  1. 대기 중인 작업의 덤프를 활성화하고 파일에 씁니다. 

    [root@igw ~]# dmesg -c ; echo w > /proc/sysrq-trigger ; dmesg -c > /tmp/waiting-tasks.txt

  2. 다음 메시지에 대해 대기 중인 작업 목록을 검토합니다.

    • iscsit_tpg_disable_portal_group
    • core_tmr_abort_task
    • transport_generic_free_cmd

    이러한 메시지가 대기 작업 목록에 표시되면 tcmu-runner 서비스에 문제가 있음을 나타냅니다. tcmu-runner 서비스가 제대로 재시작되지 않았거나 tcmu-runner 서비스가 충돌했을 수 있습니다.

  3. tcmu-runner 서비스가 실행 중인지 확인합니다. 

    [root@igw ~]# systemctl status tcmu-runner

    1. tcmu-runner 서비스가 실행 중이지 않은 경우 tcmu -runner 서비스를 다시 시작하기 전에 rbd-target- gw 서비스를 중지합니다. 

      [root@igw ~]# systemctl stop rbd-target-api
[root@igw ~]# systemctl stop rbd-target-gw
[root@igw ~]# systemctl stop tcmu-runner
[root@igw ~]# systemctl start tcmu-runner
[root@igw ~]# systemctl start rbd-target-gw
[root@igw ~]# systemctl start rbd-target-api
      중요

      먼저 Ceph iSCSI 게이트웨이를 중지하면 tcmu-runner 서비스가 중단되는 동안 IO가 중단되지 않습니다.

    2. tcmu-runner 서비스가 실행 중인 경우 새로운 버그일 수 있습니다. 새로운 Red Hat 지원 케이스를 엽니다.

추가 리소스

  • Red Hat 글로벌 지원 서비스에 대한 sosreport생성에 대한 Red Hat의 지식베이스 솔루션을 참조하십시오.
  • Red Hat 글로벌 지원 서비스의 파일 업로드 에 대한 Red Hat의 기술 자료 솔루션을 참조하십시오.
  • 고객 포털에서 Red Hat 지원 케이스 를 여는 방법은 무엇입니까?

8.5. 시간 제한 명령 오류

SCSI 명령이 시스템 로그에서 실패한 경우 Ceph iSCSI 게이트웨이에서 명령 시간 초과 오류를 보고할 수 있습니다.

예제

Mar 23 20:03:14 igw tcmu-runner: 2018-03-23 20:03:14.052 2513 [ERROR] tcmu_rbd_handle_timedout_cmd:669 rbd/rbd.gw1lun011: Timing out cmd.

또는

예제

Mar 23 20:03:14 igw tcmu-runner: tcmu_notify_conn_lost:176 rbd/rbd.gw1lun011: Handler connection lost (lock state 1)

이 의미

처리 대기 중인 다른 중단 작업이 있을 수 있으므로 응답이 적시에 수신되지 않았기 때문에 SCSI 명령이 시간 초과될 수 있습니다. 이러한 오류 메시지의 또 다른 이유는 비정상적인 Red Hat Ceph Storage 클러스터와 관련될 수 있습니다.

이 문제를 해결하려면

  1. 작업이 처리될 수 있는 대기 중인 작업이 있는지 확인합니다.
  2. Red Hat Ceph Storage 클러스터의 상태를 확인합니다.
  3. Ceph iSCSI 게이트웨이 노드에서 iSCSI 이니시에이터 노드로 가는 경로의 각 장치에서 시스템 정보를 수집합니다.

추가 리소스

8.6. 작업 오류 중단

Ceph iSCSI 게이트웨이에서 시스템 로그의 중단 작업 오류를 보고할 수 있습니다.

예제

Apr  1 14:23:58 igw kernel: ABORT_TASK: Found referenced iSCSI task_tag: 1085531

이 의미

실패한 스위치 또는 잘못된 포트와 같은 일부 다른 네트워크 중단으로 인해 이러한 유형의 오류 메시지가 발생할 수 있습니다. 또 다른 가능성은 비정상적인 Red Hat Ceph Storage 클러스터입니다.

이 문제를 해결하려면

  1. 환경에서 네트워크 중단이 있는지 확인합니다.
  2. Red Hat Ceph Storage 클러스터의 상태를 확인합니다.
  3. Ceph iSCSI 게이트웨이 노드에서 iSCSI 이니시에이터 노드로 가는 경로의 각 장치에서 시스템 정보를 수집합니다.

추가 리소스

8.7. 추가 리소스

9장. Ceph 배치 그룹 문제 해결

이 섹션에서는 Ceph 배치 그룹(PG)과 관련된 가장 일반적인 오류를 수정하는 방법에 대해 설명합니다.

9.1. 사전 요구 사항

  • 네트워크 연결을 확인합니다.
  • Monitors(모니터)가 쿼럼을 구성할 수 있는지 확인합니다.
  • 정상적인 OSD가 모두 가동 되어 있고 백필 (back filling) 및 복구 프로세스가 완료되었는지 확인합니다.

9.2. 대부분의 일반적인 Ceph 배치 그룹 오류

다음 표에는 ceph 상태 세부 정보 명령에서 반환한 가장 일반적인 오류 메시지가 나열되어 있습니다. 테이블에서는 오류를 설명하고 문제를 해결하기 위해 특정 절차를 가리키는 해당 섹션에 대한 링크를 제공합니다.

또한 최적 상태가 아닌 배치 그룹을 나열할 수 있습니다. 자세한 내용은 9.3절. “오래된 배치,비활성 또는 불명확한 상태로 배치 그룹 나열” 을 참조하십시오.

9.2.1. 사전 요구 사항

  • 실행 중인 Red Hat Ceph Storage 클러스터.
  • 실행 중인 Ceph 개체 게이트웨이.

9.2.2. 배치 그룹 오류 메시지

일반적인 배치 그룹 오류 메시지의 테이블과 잠재적인 수정 사항.

오류 메시지보기

HEALTH_ERR

PGS 아래로

배치 그룹이 종료되었습니다

PGS 불일치

일관되지 않은 배치 그룹

스크럽 오류

일관되지 않은 배치 그룹

HEALTH_WARN

pgs stale

오래된 배치 그룹

찾을 수 없음

찾을 수 없는 오브젝트

9.2.3. 오래된 배치 그룹

ceph health 명령은 일부 PG(배치 그룹)를 오래된 것으로 나열합니다. 

HEALTH_WARN 24 pgs stale; 3/300 in osds are down

이 의미

Monitor(모니터링)는 배치 그룹 작동 세트의 기본 OSD에서 상태 업데이트를 수신하지 못하거나 다른 OSD에서 기본 OSD가 다운 되었음을 보고한 경우 배치 그룹을 오래된 것으로 표시합니다.

일반적으로 PG는 스토리지 클러스터 를 시작한 후 피어링 프로세스가 완료될 때까지 오래된 상태로 들어갑니다. 그러나 PG가 예상보다 오래 지속되면 해당 PG의 기본 OSD가 다운 되었거나 PG 통계를 모니터에 보고하지 않음을 나타낼 수 있습니다. 오래된 PG를 저장하는 기본 OSD가 백업 되면 Ceph가 PG를 복구하기 시작합니다.

mon_osd_report_timeout 설정은 OSD에서 PGs 통계를 모니터에 보고하는 빈도를 결정합니다. 기본값으로 이 매개 변수는 0.5 로 설정되므로 OSD에서 반마다 통계를 보고합니다.

이 문제를 해결하려면

  1. 오래된 PG와 저장된 OSD를 식별합니다. 오류 메시지에는 다음 예와 유사한 정보가 포함됩니다.

    예제

    # ceph health detail
HEALTH_WARN 24 pgs stale; 3/300 in osds are down
...
pg 2.5 is stuck stale+active+remapped, last acting [2,0]
...
osd.10 is down since epoch 23, last address 192.168.106.220:6800/11080
osd.11 is down since epoch 13, last address 192.168.106.220:6803/11539
osd.12 is down since epoch 24, last address 192.168.106.220:6806/11861

  2. down 으로 표시된 OSD의 문제를 해결합니다. 자세한 내용은 Down OSDs를 참조하십시오.

추가 리소스

9.2.4. 일관되지 않은 배치 그룹

일부 배치 그룹은 active + clean + 불일치로 표시되며 ceph 상태 세부 정보 에서는 다음과 유사한 오류 메시지를 반환합니다. 

HEALTH_ERR 1 pgs inconsistent; 2 scrub errors
pg 0.6 is active+clean+inconsistent, acting [0,1,2]
2 scrub errors

이 의미

Ceph가 배치 그룹에서 하나 이상의 오브젝트 복제본에서 불일치를 감지하면 배치 그룹을 일관되지 않게 표시합니다. 가장 일반적인 비일관성은 다음과 같습니다.

  • 오브젝트의 크기가 올바르지 않습니다.
  • 복구가 완료된 후 하나의 복제본에서 오브젝트가 누락됩니다.

대부분의 경우 배치 그룹 내에서 스크럽 중 오류로 인해 불일치가 발생합니다.

이 문제를 해결하려면

  1. 일관되지 않은 상태인 배치 그룹을 확인합니다. 

    # ceph health detail
HEALTH_ERR 1 pgs inconsistent; 2 scrub errors
pg 0.6 is active+clean+inconsistent, acting [0,1,2]
2 scrub errors

  2. 배치 그룹이 일치하지 않는 이유를 확인합니다.

    1. 배치 그룹에서 심층 스크럽 프로세스를 시작합니다. 

      [root@mon ~]# ceph pg deep-scrub ID

      ID 를 일치하지 않는 배치 그룹의 ID로 바꿉니다. 예를 들면 다음과 같습니다. 

      [root@mon ~]# ceph pg deep-scrub 0.6
instructing pg 0.6 on osd.0 to deep-scrub

    2. ceph -w 의 출력을 검색하여 해당 배치 그룹과 관련된 메시지를 검색합니다. 

      ceph -w | grep ID

      ID 를 일치하지 않는 배치 그룹의 ID로 바꿉니다. 예를 들면 다음과 같습니다. 

      [root@mon ~]# ceph -w | grep 0.6
2015-02-26 01:35:36.778215 osd.106 [ERR] 0.6 deep-scrub stat mismatch, got 636/635 objects, 0/0 clones, 0/0 dirty, 0/0 omap, 0/0 hit_set_archive, 0/0 whiteouts, 1855455/1854371 bytes.
2015-02-26 01:35:36.788334 osd.106 [ERR] 0.6 deep-scrub 1 errors

  3. 출력에 다음과 유사한 오류 메시지가 포함된 경우 일치하지 않는 배치 그룹을 복구할 수 있습니다. 자세한 내용은 일치하지 않는 배치 그룹 복구를 참조하십시오. 

    PG.ID shard OSD: soid OBJECT missing attr , missing attr _ATTRIBUTE_TYPE
PG.ID shard OSD: soid OBJECT digest 0 != known digest DIGEST, size 0 != known size SIZE
PG.ID shard OSD: soid OBJECT size 0 != known size SIZE
PG.ID deep-scrub stat mismatch, got MISMATCH
PG.ID shard OSD: soid OBJECT candidate had a read error, digest 0 != known digest DIGEST

  4. 출력에 다음과 유사한 오류 메시지가 포함된 경우 데이터가 손실될 수 있으므로 일치하지 않는 배치 그룹을 복구하는 것은 안전하지 않습니다. 이러한 상황에서 지원 티켓을 여십시오. 자세한 내용은 Red Hat 지원 문의를 참조하십시오. 

    PG.ID shard OSD: soid OBJECT digest DIGEST != known digest DIGEST
PG.ID shard OSD: soid OBJECT omap_digest DIGEST != known omap_digest DIGEST

추가 리소스

9.2.5. 불명확한 배치 그룹

ceph 상태 명령은 다음과 유사한 오류 메시지를 반환합니다. 

HEALTH_WARN 197 pgs stuck unclean

이 의미

Ceph 구성 파일의 mon_pg_stuck_threshold 매개변수에 지정된 시간(초)에 대해 active+clean 상태를 달성하지 않은 경우 Ceph는 배치 그룹을 불명확하게 표시합니다. mon_pg_stuck_threshold 의 기본값은 300 초입니다.

배치 그룹이 불명확하면 osd_pool_default_size 매개변수에 지정된 횟수를 복제하지 않는 오브젝트가 포함됩니다. osd_pool_default_size 의 기본값은 3 이므로 Ceph에서 세 개의 복제본을 만듭니다.

일반적으로 불 명확한 배치 그룹은 일부 OSD가 다운 될 수 있음을 나타냅니다.

이 문제를 해결하려면

  1. 다운 된 OSD 확인 : 

    # ceph osd tree
  2. OSD 문제를 해결하고 수정합니다. 자세한 내용은 Down OSDs 를 참조하십시오.

추가 리소스

9.2.6. 비활성 배치 그룹

ceph 상태 명령은 다음과 유사한 오류 메시지를 반환합니다. 

HEALTH_WARN 197 pgs stuck inactive

이 의미

Ceph 구성 파일의 mon_pg_stuck_threshold 매개변수에 지정된 시간 동안 활성화되지 않은 경우 Ceph는 배치 그룹을 비활성 상태로 표시합니다. mon_pg_stuck_threshold 의 기본값은 300 초입니다.

일반적으로 비활성 배치 그룹은 일부 OSD가 다운 될 수 있음을 나타냅니다.

이 문제를 해결하려면

  1. 다운 된 OSD 확인 : 

    # ceph osd tree
  2. OSD 문제를 해결하고 수정합니다.

추가 리소스

9.2.7. 배치 그룹이 종료되었습니다

ceph 상태 세부 정보 명령은 일부 배치 그룹이 다운 되었음을 보고합니다. 

HEALTH_ERR 7 pgs degraded; 12 pgs down; 12 pgs peering; 1 pgs recovering; 6 pgs stuck unclean; 114/3300 degraded (3.455%); 1/3 in osds are down
...
pg 0.5 is down+peering
pg 1.4 is down+peering
...
osd.1 is down since epoch 69, last address 192.168.106.220:6801/8651

이 의미

피어링 프로세스를 차단하여 배치 그룹이 활성화되고 사용할 수 없게 되는 경우도 있습니다. 일반적으로 OSD가 실패하면 피어링 오류가 발생합니다.

이 문제를 해결하려면

피어링 프로세스 차단을 결정합니다. 

[root@mon ~]# ceph pg ID query

ID 를 배치 그룹의 ID 로 교체합니다. 예를 들면 다음과 같습니다. 

[root@mon ~]# ceph pg 0.5 query

{ "state": "down+peering",
  ...
  "recovery_state": [
       { "name": "Started\/Primary\/Peering\/GetInfo",
         "enter_time": "2012-03-06 14:40:16.169679",
         "requested_info_from": []},
       { "name": "Started\/Primary\/Peering",
         "enter_time": "2012-03-06 14:40:16.169659",
         "probing_osds": [
               0,
               1],
         "blocked": "peering is blocked due to down osds",
         "down_osds_we_would_probe": [
               1],
         "peering_blocked_by": [
               { "osd": 1,
                 "current_lost_at": 0,
                 "comment": "starting or marking this osd lost may let us proceed"}]},
       { "name": "Started",
         "enter_time": "2012-03-06 14:40:16.169513"}
   ]
}

recovery_state 섹션에는 피어 프로세스가 차단된 이유에 대한 정보가 포함되어 있습니다.

  • 출력에 osds 오류 메시지로 인해 피어링이 차단된 경우 OSD를 Down 으로 참조하십시오.
  • 다른 오류 메시지가 표시되면 지원 티켓을 엽니다. 자세한 내용은 Red Hat 지원 서비스에 문의하십시오.

추가 리소스

9.2.8. 찾을 수 없는 오브젝트

ceph 상태 명령은 unfound 키워드를 포함하는 다음과 유사한 오류 메시지를 반환합니다. 

HEALTH_WARN 1 pgs degraded; 78/3778 unfound (2.065%)

이 의미

Ceph는 이러한 개체 또는 최신 사본이 존재할 때 개체를 찾을 수 없지만 찾을 수 없습니다. 결과적으로 Ceph는 이러한 오브젝트를 복구할 수 없으며 복구 프로세스를 진행할 수 없습니다.

예제 상황

배치 그룹은 osd.1 및 osd. 2 에 데이터를 저장합니다.

  1. OSD.1 이 줄어듭니다.
  2. OSD.2 는 몇 가지 쓰기 작업을 처리합니다.
  3. OSD.1 이 표시됩니다.
  4. osd.1과 osd. 2 사이의 피어링 프로세스가 시작되고 osd.1 에 누락된 오브젝트는 복구를 위해 대기열에 추가됩니다.
  5. Ceph에서 새 개체를 복사하기 전에 osd.2 가 중단 됩니다.

결과적으로 osd.1 은 이러한 오브젝트가 있음을 알 수 있지만 오브젝트 복사본이 있는 OSD는 없습니다.

이 시나리오에서 Ceph는 실패한 노드에 다시 액세스할 수 있을 때까지 대기 중이며 찾을 수 없는 개체가 복구 프로세스를 차단합니다.

이 문제를 해결하려면

  1. 찾을 수 없는 개체를 포함하는 배치 그룹을 확인합니다. 

    [root@mon ~]# ceph health detail
HEALTH_WARN 1 pgs recovering; 1 pgs stuck unclean; recovery 5/937611 objects degraded (0.001%); 1/312537 unfound (0.000%)
pg 3.8a5 is stuck unclean for 803946.712780, current state active+recovering, last acting [320,248,0]
pg 3.8a5 is active+recovering, acting [320,248,0], 1 unfound
recovery 5/937611 objects degraded (0.001%); **1/312537 unfound (0.000%)**

  2. 배치 그룹에 대한 자세한 정보를 나열합니다. 

    [root@mon ~]# ceph pg ID query

    ID 를 찾을 수 없는 개체가 포함된 배치 그룹의 ID로 바꿉니다. 예를 들면 다음과 같습니다. 

    [root@mon ~]# ceph pg 3.8a5 query
{ "state": "active+recovering",
  "epoch": 10741,
  "up": [
        320,
        248,
        0],
  "acting": [
        320,
        248,
        0],
<snip>
  "recovery_state": [
        { "name": "Started\/Primary\/Active",
          "enter_time": "2015-01-28 19:30:12.058136",
          "might_have_unfound": [
                { "osd": "0",
                  "status": "already probed"},
                { "osd": "248",
                  "status": "already probed"},
                { "osd": "301",
                  "status": "already probed"},
                { "osd": "362",
                  "status": "already probed"},
                { "osd": "395",
                  "status": "already probed"},
                { "osd": "429",
                  "status": "osd is down"}],
          "recovery_progress": { "backfill_targets": [],
              "waiting_on_backfill": [],
              "last_backfill_started": "0\/\/0\/\/-1",
              "backfill_info": { "begin": "0\/\/0\/\/-1",
                  "end": "0\/\/0\/\/-1",
                  "objects": []},
              "peer_backfill_info": [],
              "backfills_in_flight": [],
              "recovering": [],
              "pg_backend": { "pull_from_peer": [],
                  "pushing": []}},
          "scrub": { "scrubber.epoch_start": "0",
              "scrubber.active": 0,
              "scrubber.block_writes": 0,
              "scrubber.finalizing": 0,
              "scrubber.waiting_on": 0,
              "scrubber.waiting_on_whom": []}},
        { "name": "Started",
          "enter_time": "2015-01-28 19:30:11.044020"}],

    might_have_unfound 섹션에는 Ceph가 발견되지 않은 오브젝트 를 찾으려고 하는 OSD가 포함되어 있습니다.

    • 이미 probed 상태는 Ceph가 해당 OSD에서 발견되지 않은 개체를 찾을 수 없음을 나타냅니다.
    • osd가 down 상태이면 Ceph가 OSD에 연결할 수 없음을 나타냅니다.
  3. down 으로 표시된 OSD의 문제를 해결합니다. 자세한 내용은 Down OSDs 를 참조하십시오.
  4. OSD가 중단되는 문제를 해결할 수 없는 경우 지원 티켓을 엽니다. 자세한 내용은 Red Hat 지원 문의를 참조하십시오.

9.3. 오래된 배치,비활성 또는 불명확한 상태로 배치 그룹 나열

실패 후 배치 그룹은 성능이 저하 되거나 피어링 과 같은 상태가 됩니다. 이 상태는 오류 복구 프로세스를 통한 정상적인 진행을 나타냅니다.

그러나 배치 그룹이 예상보다 오랜 시간 동안 이러한 상태 중 하나에 남아 있으면 더 큰 문제가 있음을 나타낼 수 있습니다. 배치 그룹이 최적 상태가 아닐 때 모니터가 보고합니다.

Ceph 구성 파일의 mon_pg_stuck_threshold 옵션은 배치 그룹이 비활성, 불투명또는 오래된 것으로 간주되는 시간(초)을 결정합니다.

다음 표에는 이러한 상태와 간단한 설명이 나열되어 있습니다.

상태그것이 무엇을 의미하는지가장 일반적인 원인보기

비활성

PG는 읽기/쓰기 요청을 서비스할 수 없습니다.

  • 피어링 문제

비활성 배치 그룹

불명확함

PG에는 원하는 횟수의 복제되지 않은 오브젝트가 포함됩니다. PG가 복구되지 못하게 하는 문제도 있습니다.

  • 찾을 수 없는 오브젝트
  • OSD가 다운되었습니다
  • 잘못된 설정

불명확한 배치 그룹

stale

ceph-osd 데몬에서 PG의 상태가 업데이트되지 않았습니다.

  • OSD가 다운되었습니다

오래된 배치 그룹

사전 요구 사항

  • 실행 중인 Red Hat Ceph Storage 클러스터.
  • 노드에 대한 루트 수준 액세스.

절차

  1. 고정된 PG를 나열합니다. 

    [root@mon ~]# ceph pg dump_stuck inactive
[root@mon ~]# ceph pg dump_stuck unclean
[root@mon ~]# ceph pg dump_stuck stale

추가 리소스

9.4. 배치 그룹 불일치 나열

rados 유틸리티를 사용하여 오브젝트의 다양한 복제본에 불일치를 나열합니다. format=json-pretty 옵션을 사용하여 자세한 출력을 나열합니다.

이 섹션에서는 다음 목록을 다룹니다.

  • 풀의 일관되지 않은 배치 그룹
  • 배치 그룹의 일관되지 않은 오브젝트
  • 배치 그룹의 일관되지 않은 스냅샷 세트

사전 요구 사항

  • 정상 상태에서 실행 중인 Red Hat Ceph Storage 클러스터.
  • 노드에 대한 루트 수준 액세스.

절차

rados list-inconsistent-pg POOL --format=json-pretty

예를 들어 data 라는 풀의 일관되지 않은 배치 그룹을 모두 나열하십시오. 

# rados list-inconsistent-pg data --format=json-pretty
[0.6]
rados list-inconsistent-obj PLACEMENT_GROUP_ID

예를 들어 ID가 0인 배치 그룹에 일관되지 않은 오브젝트를 나열 하십시오. 

# rados list-inconsistent-obj 0.6
{
    "epoch": 14,
    "inconsistents": [
        {
            "object": {
                "name": "image1",
                "nspace": "",
                "locator": "",
                "snap": "head",
                "version": 1
            },
            "errors": [
                "data_digest_mismatch",
                "size_mismatch"
            ],
            "union_shard_errors": [
                "data_digest_mismatch_oi",
                "size_mismatch_oi"
            ],
            "selected_object_info": "0:602f83fe:::foo:head(16'1 client.4110.0:1 dirty|data_digest|omap_digest s 968 uv 1 dd e978e67f od ffffffff alloc_hint [0 0 0])",
            "shards": [
                {
                    "osd": 0,
                    "errors": [],
                    "size": 968,
                    "omap_digest": "0xffffffff",
                    "data_digest": "0xe978e67f"
                },
                {
                    "osd": 1,
                    "errors": [],
                    "size": 968,
                    "omap_digest": "0xffffffff",
                    "data_digest": "0xe978e67f"
                },
                {
                    "osd": 2,
                    "errors": [
                        "data_digest_mismatch_oi",
                        "size_mismatch_oi"
                    ],
                    "size": 0,
                    "omap_digest": "0xffffffff",
                    "data_digest": "0xffffffff"
                }
            ]
        }
    ]
}

다음 필드는 불일치의 원인을 결정하는 데 중요합니다.

  • name: 일관되지 않은 복제본이 있는 오브젝트의 이름입니다.
  • nspace: 풀을 논리적으로 구분하는 네임스페이스입니다. 기본적으로 비어 있습니다.
  • locator: 배치를 위한 개체 이름의 대체로 사용되는 키입니다.
  • snap: 오브젝트의 스냅샷 ID입니다. 쓰기 가능한 유일한 버전은 head 라고 합니다. 오브젝트가 복제본인 경우 이 필드에는 순차적 ID가 포함됩니다.
  • 버전: 일관되지 않은 복제본이 있는 오브젝트의 버전 ID입니다. 오브젝트에 대한 각 쓰기 작업이 증가합니다.

  • 오류: shard 또는 shard를 결정하지 않고 shard 간 불일치를 나타내는 오류 목록입니다. 오류를 자세히 조사하려면 shard 배열을 참조하십시오.

    • data_digest_mismatch: OSD 간에 읽은 복제본 다이제스트는 다른 OSD와 다릅니다.
    • size_mismatch: 복제본 또는 head 오브젝트의 크기가 예상과 일치하지 않습니다.
    • read_error: 이 오류는 디스크 오류로 인한 불일치가 있음을 나타냅니다.

  • union_shard_error: shard와 관련된 모든 오류 조합. 이러한 오류는 잘못된 shard에 연결됩니다. 로 끝나는 오류는 결함이 있는 개체의 정보를 선택한 오브젝트의 정보와 비교해야 함을 나타냅니다. 오류를 자세히 조사하려면 shard 배열을 참조하십시오.

    위의 예에서 osd.2에 저장된 오브젝트 복제본에는 osd. 0 및 osd. 1 에 저장된 복제본과 다른 다이제스트가 있습니다. 특히 복제본의 다이제스트는 osd.2 에서 읽은 shard에서 계산한 대로 0xffffff 가 아닌 0xe978e67f 입니다. 또한 osd.2 에서 읽은 복제본의 크기는 0인 반면, osd.0 및 osd. 1 에서 보고하는 크기는 968입니다. 

rados list-inconsistent-snapset PLACEMENT_GROUP_ID

예를 들어 ID가 0.23 인 배치 그룹에 일관되지 않은 스냅샷 (snapsets)을 나열하십시오. 

# rados list-inconsistent-snapset 0.23 --format=json-pretty
{
    "epoch": 64,
    "inconsistents": [
        {
            "name": "obj5",
            "nspace": "",
            "locator": "",
            "snap": "0x00000001",
            "headless": true
        },
        {
            "name": "obj5",
            "nspace": "",
            "locator": "",
            "snap": "0x00000002",
            "headless": true
        },
        {
            "name": "obj5",
            "nspace": "",
            "locator": "",
            "snap": "head",
            "ss_attr_missing": true,
            "extra_clones": true,
            "extra clones": [
                2,
                1
            ]
        }
    ]

이 명령은 다음 오류를 반환합니다.

  • ss_attr_missing: 하나 이상의 속성이 누락되어 있습니다. 특성은 키-값 쌍 목록으로 설정된 스냅샷으로 인코딩된 스냅샷에 대한 정보입니다.
  • ss_attr_corrupted: 하나 이상의 특성을 해독할 수 없습니다.
  • clone_missing: 복제본이 누락되었습니다.
  • snapset_mismatch: 스냅샷 세트는 자체적으로 일치하지 않습니다.
  • head_mismatch: 스냅샷 세트는 head 가 있는지 여부를 나타내지만, 그렇지 않으면 스크럽 결과 보고서가 있음을 나타냅니다.
  • 헤드리스: 스냅샷 세트의 헤드 가 누락되었습니다.
  • size_mismatch: 복제본 또는 head 오브젝트의 크기가 예상과 일치하지 않습니다.

추가 리소스

9.5. 일관되지 않은 배치 그룹 복구

심층 스크럽 중에 오류가 발생하기 때문에 일부 배치 그룹에 불일치가 포함될 수 있습니다. Ceph는 이러한 배치 그룹과 일치하지 않음 을 보고합니다. 

HEALTH_ERR 1 pgs inconsistent; 2 scrub errors
pg 0.6 is active+clean+inconsistent, acting [0,1,2]
2 scrub errors
주의

특정 불일치만 복구할 수 있습니다.

Ceph 로그에 다음 오류가 포함된 경우 배치 그룹을 복구하지 마십시오. 

_PG_._ID_ shard _OSD_: soid _OBJECT_ digest _DIGEST_ != known digest _DIGEST_
_PG_._ID_ shard _OSD_: soid _OBJECT_ omap_digest _DIGEST_ != known omap_digest _DIGEST_

대신 지원 티켓을 엽니다. 자세한 내용은 Red Hat 지원 문의를 참조하십시오.

사전 요구 사항

  • Ceph 모니터 노드에 대한 루트 수준 액세스.

절차

  1. 일관되지 않은 배치 그룹을 복구합니다. 
[root@mon ~]# ceph pg repair ID
  1. ID 를 일관되지 않은 배치 그룹의 ID로 바꿉니다.

추가 리소스

9.6. 배치 그룹 늘리기

충분하지 않은 PG(배치 그룹) 수는 Ceph 클러스터 및 데이터 배포 성능에 영향을 미칩니다. 이는 nearfull osds 오류 메시지의 주요 원인 중 하나입니다.

권장 비율은 OSD당 100~300개의 PG입니다. 이 비율은 클러스터에 OSD를 추가할 때 감소할 수 있습니다.

pg_num 및 pgp_num 매개 변수는 PG 개수를 결정합니다. 이러한 매개 변수는 각 풀별로 구성되므로 각 풀을 PG 수가 적을 별도로 조정해야 합니다.

중요

PG 개수를 늘리는 것은 Ceph 클러스터에서 수행할 수 있는 가장 집약적인 프로세스입니다. 속도가 느리고 체계적으로 수행되지 않은 경우 이 프로세스는 심각한 성능 영향을 미칠 수 있습니다. pgp_num 을 늘리면 프로세스를 중지하거나 되돌릴 수 없으며 완료해야 합니다. 비즈니스 크리티컬 처리 시간 할당 외부에서 PG 수를 늘리고 모든 클라이언트에 잠재적인 성능 영향을 경고하는 것이 좋습니다. 클러스터가 HEALTH_ERR 상태에 있는 경우 PG 개수를 변경하지 마십시오.

사전 요구 사항

  • 정상 상태에서 실행 중인 Red Hat Ceph Storage 클러스터.
  • 노드에 대한 루트 수준 액세스.

절차

  1. 개별 OSD 및 OSD 호스트에 데이터 재배포 및 복구로 인한 영향을 줄입니다.

    1. osd max backfills, osd _recovery_max_active 및 osd_ recovery_op_priority 매개변수 값을 낮춥니다. 

      [root@mon ~]# ceph tell osd.* injectargs '--osd_max_backfills 1 --osd_recovery_max_active 1 --osd_recovery_op_priority 1'

    2. 탬프 및 심층 스크럽을 비활성화합니다. 

      [root@mon ~]# ceph osd set noscrub
[root@mon ~]# ceph osd set nodeep-scrub
  2. 풀 계산기당 Ceph 배치 그룹(PG) 을 사용하여 pg_num 및 pgp_num 매개 변수의 최적 값을 계산합니다.

  3. 원하는 값에 도달할 때까지 pg_num 값을 작은 단위로 늘립니다.

    1. 시작 증가 값을 확인합니다. 2의 거듭제곱인 매우 낮은 값을 사용하고 클러스터에 미치는 영향을 결정할 때 늘립니다. 최적의 값은 풀 크기, OSD 수 및 클라이언트 I/O 부하에 따라 다릅니다.

    2. pg_num 값이 증가합니다. 

      ceph osd pool set POOL pg_num VALUE

      풀 이름과 새 값을 지정합니다. 예를 들면 다음과 같습니다. 

      # ceph osd pool set data pg_num 4

    3. 클러스터 상태를 모니터링합니다. 

      # ceph -s

      PGs 상태는 creating 에서 active+clean 로 변경됩니다. 모든 PG가 active+clean 상태가 될 때까지 기다립니다.

  4. 원하는 값에 도달할 때까지 pgp_num 값을 작은 증가로 늘립니다.

    1. 시작 증가 값을 확인합니다. 2의 거듭제곱인 매우 낮은 값을 사용하고 클러스터에 미치는 영향을 결정할 때 늘립니다. 최적의 값은 풀 크기, OSD 수 및 클라이언트 I/O 부하에 따라 다릅니다.

    2. pgp_num 값이 증가합니다. 

      ceph osd pool set POOL pgp_num VALUE

      풀 이름과 새 값을 지정합니다. 예를 들면 다음과 같습니다. 

      # ceph osd pool set data pgp_num 4

    3. 클러스터 상태를 모니터링합니다. 

      # ceph -s

      PGs 상태는 피어링,wait_backfill,백필 링,복구 등을 통해 변경됩니다. 모든 PG가 active+clean 상태가 될 때까지 기다립니다.

  5. PG 수가 충분하지 않은 모든 풀에 대해 이전 단계를 반복합니다.

  6. osd max backfills,osd_recovery_max_active 및 osd_recovery_op_priority 를 기본값으로 설정합니다. 

    # ceph tell osd.* injectargs '--osd_max_backfills 1 --osd_recovery_max_active 3 --osd_recovery_op_priority 3'

  7. 탬프 및 심층 스크럽을 활성화합니다. 

    # ceph osd unset noscrub
# ceph osd unset nodeep-scrub

추가 리소스

9.7. 추가 리소스

10장. Ceph 오브젝트 문제 해결

스토리지 관리자는 ceph-objectstore-tool 유틸리티를 사용하여 상위 수준 또는 낮은 수준의 오브젝트 작업을 수행할 수 있습니다. ceph-objectstore-tool 유틸리티는 특정 OSD 또는 배치 그룹 내의 오브젝트와 관련된 문제를 해결하는 데 도움이 될 수 있습니다.

또한 복구/유지 관리 모드에서 OSD 컨테이너를 시작하여 OSD 노드에 Ceph 패키지를 설치하지 않고도 OSD를 복구할 수 있습니다.

중요

오브젝트 조작으로 인해 복구할 수 없는 데이터 손실이 발생할 수 있습니다. ceph-objectstore-tool 유틸리티를 사용하기 전에 Red Hat 지원팀에 문의하십시오.

10.1. 사전 요구 사항

  • 네트워크 관련 문제가 없는지 확인합니다.

10.2. 컨테이너화된 환경의 Ceph 오브젝트 문제 해결

OSD 컨테이너는 복구/유지 관리 모드로 시작하여 OSD 노드에 Ceph 패키지를 설치하지 않고도 Red Hat Ceph Storage 4에서 OSD를 복구할 수 있습니다.

ceph-bluestore-tool 을 사용하여 fsck 명령으로 일관성 검사를 실행하거나 복구 명령으로 일관성 검사를 실행하고 오류를 복구할 수 있습니다.

중요

이 절차는 컨테이너화된 배포에만 적용됩니다. 베어 메탈 배포에는 이 섹션 건너뛰기

사전 요구 사항

  • 실행 중인 Red Hat Ceph Storage 클러스터.
  • Ceph OSD 노드에 대한 루트 수준 액세스.
  • ceph-osd 데몬 중지.

절차

  1. 클러스터에 noout 플래그를 설정합니다.

    예제

    [root@mon ~]# ceph osd set noout

  2. OSD 컨테이너를 호스팅하는 노드에 로그인합니다.

  3. /etc/systemd/system/ceph-osd@.service 장치 파일을 /root 디렉토리로 백업합니다.

    예제

    [root@osd ~]# cp /etc/systemd/system/ceph-osd@.service /root/ceph-osd@.service.backup

  4. /run/ceph-osd@OSD_ID.service-cid 파일을 /root 로 이동합니다.

    예제

    [root@osd ~]# mv /run/ceph-osd@0.service-cid /root

  5. /etc/systemd/system/ceph-osd@.service 장치 파일을 편집하고 podman 명령에 -it --entrypoint /bin/bash 옵션을 추가합니다.

    예제

    # Please do not change this file directly since it is managed by Ansible and will be overwritten
[Unit]
Description=Ceph OSD
After=network.target

[Service]
EnvironmentFile=-/etc/environment
ExecStartPre=-/usr/bin/rm -f /%t/%n-pid /%t/%n-cid
ExecStartPre=-/usr/bin/podman rm -f ceph-osd-%i
ExecStart=/usr/bin/podman run -it --entrypoint /bin/bash \
  -d --conmon-pidfile /%t/%n-pid --cidfile /%t/%n-cid \
  --rm \
  --net=host \
  --privileged=true \
  --pid=host \
  --ipc=host \
  --cpus=2 \
  -v /dev:/dev \
  -v /etc/localtime:/etc/localtime:ro \
  -v /var/lib/ceph:/var/lib/ceph:z \
  -v /etc/ceph:/etc/ceph:z \
  -v /var/run/ceph:/var/run/ceph:z \
  -v /var/run/udev/:/var/run/udev/ \
  -v /var/log/ceph:/var/log/ceph:z \
  -e OSD_BLUESTORE=1 -e OSD_FILESTORE=0 -e OSD_DMCRYPT=0 \
  -e CLUSTER=ceph \
  -v /run/lvm/:/run/lvm/ \
  -e CEPH_DAEMON=OSD_CEPH_VOLUME_ACTIVATE \
  -e CONTAINER_IMAGE=registry.redhat.io/rhceph/rhceph-4-rhel8:latest \
  -e OSD_ID=%i \
  -e DEBUG=stayalive \
  --name=ceph-osd-%i \
   \
  registry.redhat.io/rhceph/rhceph-4-rhel8:latest
ExecStop=-/usr/bin/sh -c "/usr/bin/podman rm -f `cat /%t/%n-cid`"
KillMode=none
Restart=always
RestartSec=10s
TimeoutStartSec=120
TimeoutStopSec=15
Type=forking
PIDFile=/%t/%n-pid

[Install]
WantedBy=multi-user.target

  6. systemd 관리자 구성을 다시 로드합니다.

    예제

    [root@osd ~]# systemctl daemon-reload

  7. OSD_ID 와 연결된 OSD 서비스를 다시 시작합니다.

    구문

    systemctl restart ceph-osd@OSD_ID.service

    OSD_ID 를 OSD의 ID로 바꿉니다.

    예제

    [root@osd ~]# systemctl restart ceph-osd@0.service

  8. OSD_ID 와 연결된 컨테이너에 로그인합니다.

    구문

    podman exec -it ceph-osd-OSD_ID /bin/bash

    예제

    [root@osd ~]# podman exec -it ceph-osd-0 /bin/bash

  9. osd fsid 를 가져오고 OSD를 활성화하여 OSD의 논리 볼륨(LV)을 마운트합니다.

    구문

    ceph-volume lvm list |grep -A15 "osd\.OSD_ID"|grep "osd fsid"
ceph-volume lvm activate --bluestore OSD_ID OSD_FSID

    예제

    [root@osd ~]# ceph-volume lvm list |grep -A15 "osd\.0"|grep "osd fsid"
              osd fsid                  087eee15-6561-40a3-8fe4-9583ba64a4ff
[root@osd ~]# ceph-volume lvm activate --bluestore 0 087eee15-6561-40a3-8fe4-9583ba64a4ff
Running command: /usr/bin/mount -t tmpfs tmpfs /var/lib/ceph/osd/ceph-0
Running command: /usr/bin/chown -R ceph:ceph /var/lib/ceph/osd/ceph-0
Running command: /usr/bin/ceph-bluestore-tool --cluster=ceph prime-osd-dir --dev /dev/ceph-41c69f8f-30e2-4685-9c5c-c605898c5537/osd-data-d073e8b3-0b89-4271-af5b-83045fd000dc --path /var/lib/ceph/osd/ceph-0 --no-mon-config
Running command: /usr/bin/ln -snf /dev/ceph-41c69f8f-30e2-4685-9c5c-c605898c5537/osd-data-d073e8b3-0b89-4271-af5b-83045fd000dc /var/lib/ceph/osd/ceph-0/block
Running command: /usr/bin/chown -h ceph:ceph /var/lib/ceph/osd/ceph-0/block
Running command: /usr/bin/chown -R ceph:ceph /dev/mapper/ceph--41c69f8f--30e2--4685--9c5c--c605898c5537-osd--data--d073e8b3--0b89--4271--af5b--83045fd000dc
Running command: /usr/bin/chown -R ceph:ceph /var/lib/ceph/osd/ceph-0
Running command: /usr/bin/systemctl enable ceph-volume@lvm-0-087eee15-6561-40a3-8fe4-9583ba64a4ff
 stderr: Created symlink /etc/systemd/system/multi-user.target.wants/ceph-volume@lvm-0-087eee15-6561-40a3-8fe4-9583ba64a4ff.service → /usr/lib/systemd/system/ceph-volume@.service.
Running command: /usr/bin/systemctl enable --runtime ceph-osd@0
 stderr: Created symlink /run/systemd/system/ceph-osd.target.wants/ceph osd@0.service → /usr/lib/systemd/system/ceph-osd@.service.
Running command: /usr/bin/systemctl start ceph-osd@0
 stderr: Running in chroot, ignoring request: start
--> ceph-volume lvm activate successful for osd ID: 0

  10. fsck 를 실행하고 복구 명령을 실행합니다.

    구문

    ceph-bluestore-tool fsck --path /var/lib/ceph/osd/ceph-OSD_ID
ceph-bluestore-tool repair --path /var/lib/ceph/osd/ceph-OSD_ID

    예제

    [root@osd ~]# ceph-bluestore-tool fsck --path /var/lib/ceph/osd/ceph-0
fsck success

    [root@osd ~]# ceph-bluestore-tool repair --path /var/lib/ceph/osd/ceph-0
repair success

  11. 컨테이너를 종료한 후 /root 디렉터리에서 /etc/systemd/system/ceph-osd@.service 장치 파일을 복사합니다.

    예제

    [root@osd ~]# cp /etc/systemd/system/ceph-osd@.service /root/ceph-osd@.service.modified
[root@osd ~]# cp /root/ceph-osd@.service.backup /etc/systemd/system/ceph-osd@.service

  12. systemd 관리자 구성을 다시 로드합니다.

    예제

    [root@osd ~]# systemctl daemon-reload

  13. /run/ceph-osd@OSD_ID.service-cid 파일을 /tmp 로 이동합니다.

    예제

    [root@osd ~]# mv /run/ceph-osd@0.service-cid /tmp

  14. OSD_ID 와 연결된 OSD 서비스를 다시 시작합니다.

    구문

    [root@osd ~]# systemctl restart ceph-osd@OSD_ID.service

    예제

    [root@osd ~]# systemctl restart ceph-osd@0.service

추가 리소스

10.3. 고급 오브젝트 작업 문제 해결

스토리지 관리자는 ceph-objectstore-tool 유틸리티를 사용하여 높은 수준의 오브젝트 작업을 수행할 수 있습니다. ceph-objectstore-tool 유틸리티에서는 다음과 같은 고급 오브젝트 작업을 지원합니다.

  • 오브젝트 나열
  • 손실된 오브젝트 나열
  • 손실된 객체 수정
중요

오브젝트 조작으로 인해 복구할 수 없는 데이터 손실이 발생할 수 있습니다. ceph-objectstore-tool 유틸리티를 사용하기 전에 Red Hat 지원팀에 문의하십시오.

10.3.1. 사전 요구 사항

  • Ceph OSD 노드에 대한 루트 수준 액세스.

10.3.2. 오브젝트 나열

OSD는 0~여 개의 배치 그룹을 포함하고 PG(배포 그룹) 내의 여러 개체에 0을 포함할 수 있습니다. ceph-objectstore-tool 유틸리티를 사용하면 OSD 내에 저장된 오브젝트를 나열할 수 있습니다.

사전 요구 사항

  • Ceph OSD 노드에 대한 루트 수준 액세스.
  • ceph-osd 데몬 중지.

절차

  1. 적절한 OSD가 다운되었는지 확인합니다. 

    [root@osd ~]# systemctl status ceph-osd@OSD_NUMBER

    예제

    [root@osd ~]# systemctl status ceph-osd@1

  2. 컨테이너화된 배포의 경우 bluestore 툴에 액세스하려면 다음 단계를 따르십시오.

    1. 클러스터에 noout 플래그를 설정합니다.

      예제

      [root@mon ~]# ceph osd set noout

    2. OSD 컨테이너를 호스팅하는 노드에 로그인합니다.

    3. /etc/systemd/system/ceph-osd@.service 장치 파일을 /root 디렉토리로 백업합니다.

      예제

      [root@osd ~]# cp /etc/systemd/system/ceph-osd@.service /root/ceph-osd@.service.backup

    4. /run/ceph-osd@OSD_ID.service-cid 파일을 /root 로 이동합니다.

      예제

      [root@osd ~]# mv /run/ceph-osd@0.service-cid /root

    5. /etc/systemd/system/ceph-osd@.service 장치 파일을 편집하고 podman 명령에 -it --entrypoint /bin/bash 옵션을 추가합니다.

      예제

      # Please do not change this file directly since it is managed by Ansible and will be overwritten
[Unit]
Description=Ceph OSD
After=network.target

[Service]
EnvironmentFile=-/etc/environment
ExecStartPre=-/usr/bin/rm -f /%t/%n-pid /%t/%n-cid
ExecStartPre=-/usr/bin/podman rm -f ceph-osd-%i
ExecStart=/usr/bin/podman run -it --entrypoint /bin/bash \
  -d --conmon-pidfile /%t/%n-pid --cidfile /%t/%n-cid \
  --rm \
  --net=host \
  --privileged=true \
  --pid=host \
  --ipc=host \
  --cpus=2 \
  -v /dev:/dev \
  -v /etc/localtime:/etc/localtime:ro \
  -v /var/lib/ceph:/var/lib/ceph:z \
  -v /etc/ceph:/etc/ceph:z \
  -v /var/run/ceph:/var/run/ceph:z \
  -v /var/run/udev/:/var/run/udev/ \
  -v /var/log/ceph:/var/log/ceph:z \
  -e OSD_BLUESTORE=1 -e OSD_FILESTORE=0 -e OSD_DMCRYPT=0 \
  -e CLUSTER=ceph \
  -v /run/lvm/:/run/lvm/ \
  -e CEPH_DAEMON=OSD_CEPH_VOLUME_ACTIVATE \
  -e CONTAINER_IMAGE=registry.redhat.io/rhceph/rhceph-4-rhel8:latest \
  -e OSD_ID=%i \
  -e DEBUG=stayalive \
  --name=ceph-osd-%i \
   \
  registry.redhat.io/rhceph/rhceph-4-rhel8:latest
ExecStop=-/usr/bin/sh -c "/usr/bin/podman rm -f `cat /%t/%n-cid`"
KillMode=none
Restart=always
RestartSec=10s
TimeoutStartSec=120
TimeoutStopSec=15
Type=forking
PIDFile=/%t/%n-pid

[Install]
WantedBy=multi-user.target

    6. systemd 관리자 구성을 다시 로드합니다.

      예제

      [root@osd ~]# systemctl daemon-reload

    7. OSD_ID 와 연결된 OSD 서비스를 다시 시작합니다.

      구문

      systemctl restart ceph-osd@OSD_ID.service

      OSD_ID 를 OSD의 ID로 바꿉니다.

      예제

      [root@osd ~]# systemctl restart ceph-osd@0.service

    8. OSD_ID 와 연결된 컨테이너에 로그인합니다.

      구문

      podman exec -it ceph-osd-OSD_ID /bin/bash

      예제

      [root@osd ~]# podman exec -it ceph-osd-0 /bin/bash

    9. osd fsid 를 가져오고 OSD를 활성화하여 OSD의 논리 볼륨(LV)을 마운트합니다.

      구문

      ceph-volume lvm list |grep -A15 "osd\.OSD_ID"|grep "osd fsid"
ceph-volume lvm activate --bluestore OSD_ID OSD_FSID

      예제

      [root@osd ~]# ceph-volume lvm list |grep -A15 "osd\.0"|grep "osd fsid"
              osd fsid                  087eee15-6561-40a3-8fe4-9583ba64a4ff
[root@osd ~]# ceph-volume lvm activate --bluestore 0 087eee15-6561-40a3-8fe4-9583ba64a4ff
Running command: /usr/bin/mount -t tmpfs tmpfs /var/lib/ceph/osd/ceph-0
Running command: /usr/bin/chown -R ceph:ceph /var/lib/ceph/osd/ceph-0
Running command: /usr/bin/ceph-bluestore-tool --cluster=ceph prime-osd-dir --dev /dev/ceph-41c69f8f-30e2-4685-9c5c-c605898c5537/osd-data-d073e8b3-0b89-4271-af5b-83045fd000dc --path /var/lib/ceph/osd/ceph-0 --no-mon-config
Running command: /usr/bin/ln -snf /dev/ceph-41c69f8f-30e2-4685-9c5c-c605898c5537/osd-data-d073e8b3-0b89-4271-af5b-83045fd000dc /var/lib/ceph/osd/ceph-0/block
Running command: /usr/bin/chown -h ceph:ceph /var/lib/ceph/osd/ceph-0/block
Running command: /usr/bin/chown -R ceph:ceph /dev/mapper/ceph--41c69f8f--30e2--4685--9c5c--c605898c5537-osd--data--d073e8b3--0b89--4271--af5b--83045fd000dc
Running command: /usr/bin/chown -R ceph:ceph /var/lib/ceph/osd/ceph-0
Running command: /usr/bin/systemctl enable ceph-volume@lvm-0-087eee15-6561-40a3-8fe4-9583ba64a4ff
 stderr: Created symlink /etc/systemd/system/multi-user.target.wants/ceph-volume@lvm-0-087eee15-6561-40a3-8fe4-9583ba64a4ff.service → /usr/lib/systemd/system/ceph-volume@.service.
Running command: /usr/bin/systemctl enable --runtime ceph-osd@0
 stderr: Created symlink /run/systemd/system/ceph-osd.target.wants/ceph osd@0.service → /usr/lib/systemd/system/ceph-osd@.service.
Running command: /usr/bin/systemctl start ceph-osd@0
 stderr: Running in chroot, ignoring request: start
--> ceph-volume lvm activate successful for osd ID: 0

  3. 배치 그룹과 관계없이 OSD 내에서 모든 오브젝트를 식별합니다. 

    [root@osd ~]# ceph-objectstore-tool --data-path PATH_TO_OSD --op list

    예제

    [root@osd ~]# ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-0 --op list

  4. 배치 그룹 내에서 모든 오브젝트를 식별합니다. 

    [root@osd ~]# ceph-objectstore-tool --data-path PATH_TO_OSD --pgid PG_ID --op list

    예제

    [root@osd ~]# ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-0 --pgid 0.1c --op list

  5. 오브젝트가 속하는 PG를 확인합니다. 

    [root@osd ~]# ceph-objectstore-tool --data-path PATH_TO_OSD --op list OBJECT_ID

    예제

    [root@osd ~]# ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-0 --op list default.region

  6. 컨테이너화된 배포의 경우 변경 사항을 되돌리려면 다음 단계를 따르십시오.

    1. 컨테이너를 종료한 후 /root 디렉터리에서 /etc/systemd/system/ceph-osd@.service 장치 파일을 복사합니다.

      예제

      [root@osd ~]# cp /etc/systemd/system/ceph-osd@.service /root/ceph-osd@.service.modified
[root@osd ~]# cp /root/ceph-osd@.service.backup /etc/systemd/system/ceph-osd@.service

    2. systemd 관리자 구성을 다시 로드합니다.

      예제

      [root@osd ~]# systemctl daemon-reload

    3. /run/ceph-osd@OSD_ID.service-cid 파일을 /tmp 로 이동합니다.

      예제

      [root@osd ~]# mv /run/ceph-osd@0.service-cid /tmp

    4. OSD_ID 와 연결된 OSD 서비스를 다시 시작합니다.

      구문

      [root@osd ~]# systemctl restart ceph-osd@OSD_ID.service

      예제

      [root@osd ~]# systemctl restart ceph-osd@0.service

추가 리소스

10.3.3. 손실된 오브젝트 나열

OSD는 오브젝트를 lost 또는 unfound 로 표시할 수 있습니다. ceph-objectstore-tool 을 사용하여 OSD에 저장된 손실되거나 unfound 오브젝트를 나열할 수 있습니다.

사전 요구 사항

  • Ceph OSD 노드에 대한 루트 수준 액세스.
  • ceph-osd 데몬 중지.

절차

  1. 적절한 OSD가 다운되었는지 확인합니다. 

    [root@osd ~]# systemctl status ceph-osd@OSD_NUMBER

    예제

    [root@osd ~]# systemctl status ceph-osd@1

  2. 컨테이너화된 배포의 경우 bluestore 툴에 액세스하려면 다음 단계를 따르십시오.

    1. 클러스터에 noout 플래그를 설정합니다.

      예제

      [root@mon ~]# ceph osd set noout

    2. OSD 컨테이너를 호스팅하는 노드에 로그인합니다.

    3. /etc/systemd/system/ceph-osd@.service 장치 파일을 /root 디렉토리로 백업합니다.

      예제

      [root@osd ~]# cp /etc/systemd/system/ceph-osd@.service /root/ceph-osd@.service.backup

    4. /run/ceph-osd@OSD_ID.service-cid 파일을 /root 로 이동합니다.

      예제

      [root@osd ~]# mv /run/ceph-osd@0.service-cid /root

    5. /etc/systemd/system/ceph-osd@.service 장치 파일을 편집하고 podman 명령에 -it --entrypoint /bin/bash 옵션을 추가합니다.

      예제

      # Please do not change this file directly since it is managed by Ansible and will be overwritten
[Unit]
Description=Ceph OSD
After=network.target

[Service]
EnvironmentFile=-/etc/environment
ExecStartPre=-/usr/bin/rm -f /%t/%n-pid /%t/%n-cid
ExecStartPre=-/usr/bin/podman rm -f ceph-osd-%i
ExecStart=/usr/bin/podman run -it --entrypoint /bin/bash \
  -d --conmon-pidfile /%t/%n-pid --cidfile /%t/%n-cid \
  --rm \
  --net=host \
  --privileged=true \
  --pid=host \
  --ipc=host \
  --cpus=2 \
  -v /dev:/dev \
  -v /etc/localtime:/etc/localtime:ro \
  -v /var/lib/ceph:/var/lib/ceph:z \
  -v /etc/ceph:/etc/ceph:z \
  -v /var/run/ceph:/var/run/ceph:z \
  -v /var/run/udev/:/var/run/udev/ \
  -v /var/log/ceph:/var/log/ceph:z \
  -e OSD_BLUESTORE=1 -e OSD_FILESTORE=0 -e OSD_DMCRYPT=0 \
  -e CLUSTER=ceph \
  -v /run/lvm/:/run/lvm/ \
  -e CEPH_DAEMON=OSD_CEPH_VOLUME_ACTIVATE \
  -e CONTAINER_IMAGE=registry.redhat.io/rhceph/rhceph-4-rhel8:latest \
  -e OSD_ID=%i \
  -e DEBUG=stayalive \
  --name=ceph-osd-%i \
   \
  registry.redhat.io/rhceph/rhceph-4-rhel8:latest
ExecStop=-/usr/bin/sh -c "/usr/bin/podman rm -f `cat /%t/%n-cid`"
KillMode=none
Restart=always
RestartSec=10s
TimeoutStartSec=120
TimeoutStopSec=15
Type=forking
PIDFile=/%t/%n-pid

[Install]
WantedBy=multi-user.target

    6. systemd 관리자 구성을 다시 로드합니다.

      예제

      [root@osd ~]# systemctl daemon-reload

    7. OSD_ID 와 연결된 OSD 서비스를 다시 시작합니다.

      구문

      systemctl restart ceph-osd@OSD_ID.service

      OSD_ID 를 OSD의 ID로 바꿉니다.

      예제

      [root@osd ~]# systemctl restart ceph-osd@0.service

    8. OSD_ID 와 연결된 컨테이너에 로그인합니다.

      구문

      podman exec -it ceph-osd-OSD_ID /bin/bash

      예제

      [root@osd ~]# podman exec -it ceph-osd-0 /bin/bash

    9. osd fsid 를 가져오고 OSD를 활성화하여 OSD의 논리 볼륨(LV)을 마운트합니다.

      구문

      ceph-volume lvm list |grep -A15 "osd\.OSD_ID"|grep "osd fsid"
ceph-volume lvm activate --bluestore OSD_ID OSD_FSID

      예제

      [root@osd ~]# ceph-volume lvm list |grep -A15 "osd\.0"|grep "osd fsid"
              osd fsid                  087eee15-6561-40a3-8fe4-9583ba64a4ff
[root@osd ~]# ceph-volume lvm activate --bluestore 0 087eee15-6561-40a3-8fe4-9583ba64a4ff
Running command: /usr/bin/mount -t tmpfs tmpfs /var/lib/ceph/osd/ceph-0
Running command: /usr/bin/chown -R ceph:ceph /var/lib/ceph/osd/ceph-0
Running command: /usr/bin/ceph-bluestore-tool --cluster=ceph prime-osd-dir --dev /dev/ceph-41c69f8f-30e2-4685-9c5c-c605898c5537/osd-data-d073e8b3-0b89-4271-af5b-83045fd000dc --path /var/lib/ceph/osd/ceph-0 --no-mon-config
Running command: /usr/bin/ln -snf /dev/ceph-41c69f8f-30e2-4685-9c5c-c605898c5537/osd-data-d073e8b3-0b89-4271-af5b-83045fd000dc /var/lib/ceph/osd/ceph-0/block
Running command: /usr/bin/chown -h ceph:ceph /var/lib/ceph/osd/ceph-0/block
Running command: /usr/bin/chown -R ceph:ceph /dev/mapper/ceph--41c69f8f--30e2--4685--9c5c--c605898c5537-osd--data--d073e8b3--0b89--4271--af5b--83045fd000dc
Running command: /usr/bin/chown -R ceph:ceph /var/lib/ceph/osd/ceph-0
Running command: /usr/bin/systemctl enable ceph-volume@lvm-0-087eee15-6561-40a3-8fe4-9583ba64a4ff
 stderr: Created symlink /etc/systemd/system/multi-user.target.wants/ceph-volume@lvm-0-087eee15-6561-40a3-8fe4-9583ba64a4ff.service → /usr/lib/systemd/system/ceph-volume@.service.
Running command: /usr/bin/systemctl enable --runtime ceph-osd@0
 stderr: Created symlink /run/systemd/system/ceph-osd.target.wants/ceph osd@0.service → /usr/lib/systemd/system/ceph-osd@.service.
Running command: /usr/bin/systemctl start ceph-osd@0
 stderr: Running in chroot, ignoring request: start
--> ceph-volume lvm activate successful for osd ID: 0

  3. ceph-objectstore-tool 유틸리티를 사용하여 손실된 오브젝트 및 unfound 오브젝트를 나열합니다. 적절한 상황을 선택합니다.

    1. 손실된 오브젝트를 모두 나열하려면 다음을 수행합니다. 

      [root@osd ~]# ceph-objectstore-tool --data-path PATH_TO_OSD --op list-lost

      예제

      [root@osd ~]# ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-0 --op list-lost

    2. 배치 그룹 내에서 손실된 모든 오브젝트를 나열하려면 다음을 수행합니다. 

      [root@osd ~]# ceph-objectstore-tool --data-path PATH_TO_OSD --pgid PG_ID --op list-lost

      예제

      [root@osd ~]# ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-0 --pgid 0.1c --op list-lost

    3. 손실된 오브젝트를 식별자로 나열하려면 다음을 수행합니다. 

      [root@osd ~]# ceph-objectstore-tool --data-path PATH_TO_OSD --op list-lost OBJECT_ID

      예제

      [root@osd ~]# ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-0 --op list-lost default.region

  4. 컨테이너화된 배포의 경우 변경 사항을 되돌리려면 다음 단계를 따르십시오.

    1. 컨테이너를 종료한 후 /root 디렉터리에서 /etc/systemd/system/ceph-osd@.service 장치 파일을 복사합니다.

      예제

      [root@osd ~]# cp /etc/systemd/system/ceph-osd@.service /root/ceph-osd@.service.modified
[root@osd ~]# cp /root/ceph-osd@.service.backup /etc/systemd/system/ceph-osd@.service

    2. systemd 관리자 구성을 다시 로드합니다.

      예제

      [root@osd ~]# systemctl daemon-reload

    3. /run/ceph-osd@OSD_ID.service-cid 파일을 /tmp 로 이동합니다.

      예제

      [root@osd ~]# mv /run/ceph-osd@0.service-cid /tmp

    4. OSD_ID 와 연결된 OSD 서비스를 다시 시작합니다.

      구문

      [root@osd ~]# systemctl restart ceph-osd@OSD_ID.service

      예제

      [root@osd ~]# systemctl restart ceph-osd@0.service

추가 리소스

10.3.4. 손실된 오브젝트 수정

ceph-objectstore-tool 유틸리티를 사용하여 Ceph OSD에 저장된 손실 및 발견되지 않은 오브젝트를 나열하고 수정할 수 있습니다. 이 절차는 레거시 오브젝트에만 적용됩니다.

사전 요구 사항

  • Ceph OSD 노드에 대한 루트 수준 액세스.
  • ceph-osd 데몬 중지.

절차

  1. 적절한 OSD가 다운되었는지 확인합니다.

    구문

    [root@osd ~]# systemctl status ceph-osd@OSD_NUMBER

    예제

    [root@osd ~]# systemctl status ceph-osd@1

  2. 컨테이너화된 배포의 경우 bluestore 툴에 액세스하려면 다음 단계를 따르십시오.

    1. 클러스터에 noout 플래그를 설정합니다.

      예제

      [root@mon ~]# ceph osd set noout

    2. OSD 컨테이너를 호스팅하는 노드에 로그인합니다.

    3. /etc/systemd/system/ceph-osd@.service 장치 파일을 /root 디렉토리로 백업합니다.

      예제

      [root@osd ~]# cp /etc/systemd/system/ceph-osd@.service /root/ceph-osd@.service.backup

    4. /run/ceph-osd@OSD_ID.service-cid 파일을 /root 로 이동합니다.

      예제

      [root@osd ~]# mv /run/ceph-osd@0.service-cid /root

    5. /etc/systemd/system/ceph-osd@.service 장치 파일을 편집하고 podman 명령에 -it --entrypoint /bin/bash 옵션을 추가합니다.

      예제

      # Please do not change this file directly since it is managed by Ansible and will be overwritten
[Unit]
Description=Ceph OSD
After=network.target

[Service]
EnvironmentFile=-/etc/environment
ExecStartPre=-/usr/bin/rm -f /%t/%n-pid /%t/%n-cid
ExecStartPre=-/usr/bin/podman rm -f ceph-osd-%i
ExecStart=/usr/bin/podman run -it --entrypoint /bin/bash \
  -d --conmon-pidfile /%t/%n-pid --cidfile /%t/%n-cid \
  --rm \
  --net=host \
  --privileged=true \
  --pid=host \
  --ipc=host \
  --cpus=2 \
  -v /dev:/dev \
  -v /etc/localtime:/etc/localtime:ro \
  -v /var/lib/ceph:/var/lib/ceph:z \
  -v /etc/ceph:/etc/ceph:z \
  -v /var/run/ceph:/var/run/ceph:z \
  -v /var/run/udev/:/var/run/udev/ \
  -v /var/log/ceph:/var/log/ceph:z \
  -e OSD_BLUESTORE=1 -e OSD_FILESTORE=0 -e OSD_DMCRYPT=0 \
  -e CLUSTER=ceph \
  -v /run/lvm/:/run/lvm/ \
  -e CEPH_DAEMON=OSD_CEPH_VOLUME_ACTIVATE \
  -e CONTAINER_IMAGE=registry.redhat.io/rhceph/rhceph-4-rhel8:latest \
  -e OSD_ID=%i \
  -e DEBUG=stayalive \
  --name=ceph-osd-%i \
   \
  registry.redhat.io/rhceph/rhceph-4-rhel8:latest
ExecStop=-/usr/bin/sh -c "/usr/bin/podman rm -f `cat /%t/%n-cid`"
KillMode=none
Restart=always
RestartSec=10s
TimeoutStartSec=120
TimeoutStopSec=15
Type=forking
PIDFile=/%t/%n-pid

[Install]
WantedBy=multi-user.target

    6. systemd 관리자 구성을 다시 로드합니다.

      예제

      [root@osd ~]# systemctl daemon-reload

    7. OSD_ID 와 연결된 OSD 서비스를 다시 시작합니다.

      구문

      systemctl restart ceph-osd@OSD_ID.service

      OSD_ID 를 OSD의 ID로 바꿉니다.

      예제

      [root@osd ~]# systemctl restart ceph-osd@0.service

    8. OSD_ID 와 연결된 컨테이너에 로그인합니다.

      구문

      podman exec -it ceph-osd-OSD_ID /bin/bash

      예제

      [root@osd ~]# podman exec -it ceph-osd-0 /bin/bash

    9. osd fsid 를 가져오고 OSD를 활성화하여 OSD의 논리 볼륨(LV)을 마운트합니다.

      구문

      ceph-volume lvm list |grep -A15 "osd\.OSD_ID"|grep "osd fsid"
ceph-volume lvm activate --bluestore OSD_ID OSD_FSID

      예제

      [root@osd ~]# ceph-volume lvm list |grep -A15 "osd\.0"|grep "osd fsid"
              osd fsid                  087eee15-6561-40a3-8fe4-9583ba64a4ff
[root@osd ~]# ceph-volume lvm activate --bluestore 0 087eee15-6561-40a3-8fe4-9583ba64a4ff
Running command: /usr/bin/mount -t tmpfs tmpfs /var/lib/ceph/osd/ceph-0
Running command: /usr/bin/chown -R ceph:ceph /var/lib/ceph/osd/ceph-0
Running command: /usr/bin/ceph-bluestore-tool --cluster=ceph prime-osd-dir --dev /dev/ceph-41c69f8f-30e2-4685-9c5c-c605898c5537/osd-data-d073e8b3-0b89-4271-af5b-83045fd000dc --path /var/lib/ceph/osd/ceph-0 --no-mon-config
Running command: /usr/bin/ln -snf /dev/ceph-41c69f8f-30e2-4685-9c5c-c605898c5537/osd-data-d073e8b3-0b89-4271-af5b-83045fd000dc /var/lib/ceph/osd/ceph-0/block
Running command: /usr/bin/chown -h ceph:ceph /var/lib/ceph/osd/ceph-0/block
Running command: /usr/bin/chown -R ceph:ceph /dev/mapper/ceph--41c69f8f--30e2--4685--9c5c--c605898c5537-osd--data--d073e8b3--0b89--4271--af5b--83045fd000dc
Running command: /usr/bin/chown -R ceph:ceph /var/lib/ceph/osd/ceph-0
Running command: /usr/bin/systemctl enable ceph-volume@lvm-0-087eee15-6561-40a3-8fe4-9583ba64a4ff
 stderr: Created symlink /etc/systemd/system/multi-user.target.wants/ceph-volume@lvm-0-087eee15-6561-40a3-8fe4-9583ba64a4ff.service → /usr/lib/systemd/system/ceph-volume@.service.
Running command: /usr/bin/systemctl enable --runtime ceph-osd@0
 stderr: Created symlink /run/systemd/system/ceph-osd.target.wants/ceph osd@0.service → /usr/lib/systemd/system/ceph-osd@.service.
Running command: /usr/bin/systemctl start ceph-osd@0
 stderr: Running in chroot, ignoring request: start
--> ceph-volume lvm activate successful for osd ID: 0

  3. 손실된 기존 오브젝트를 모두 나열하려면 다음을 수행합니다.

    구문

    ceph-objectstore-tool --data-path PATH_TO_OSD --op fix-lost --dry-run

    예제

    [root@osd ~]# ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-0 --op fix-lost --dry-run

  4. ceph-objectstore-tool 유틸리티를 사용하여 ceph 사용자로 손실되거나 unfound 오브젝트를 수정합니다. 적절한 상황을 선택합니다.

    • 손실된 모든 오브젝트를 수정하려면 다음을 수행합니다.

      구문

      su - ceph -c 'ceph-objectstore-tool --data-path PATH_TO_OSD --op fix-lost'

      예제

      [root@osd ~]# su - ceph -c 'ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-0 --op fix-lost'

    • 배치 그룹 내에서 손실된 모든 오브젝트를 수정하려면 다음을 수행합니다. 

      su - ceph -c 'ceph-objectstore-tool --data-path _PATH_TO_OSD_ --pgid _PG_ID_ --op fix-lost'

      예제

      [root@osd ~]# su - ceph -c 'ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-0 --pgid 0.1c --op fix-lost'

    • 손실된 오브젝트를 식별자로 수정하려면 다음을 수행합니다.

      구문

      su - ceph -c 'ceph-objectstore-tool --data-path PATH_TO_OSD --op fix-lost OBJECT_ID'

      예제

      [root@osd ~]# su - ceph -c 'ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-0 --op fix-lost default.region'

  5. 컨테이너화된 배포의 경우 변경 사항을 되돌리려면 다음 단계를 따르십시오.

    1. 컨테이너를 종료한 후 /root 디렉터리에서 /etc/systemd/system/ceph-osd@.service 장치 파일을 복사합니다.

      예제

      [root@osd ~]# cp /etc/systemd/system/ceph-osd@.service /root/ceph-osd@.service.modified
[root@osd ~]# cp /root/ceph-osd@.service.backup /etc/systemd/system/ceph-osd@.service

    2. systemd 관리자 구성을 다시 로드합니다.

      예제

      [root@osd ~]# systemctl daemon-reload

    3. /run/ceph-osd@OSD_ID.service-cid 파일을 /tmp 로 이동합니다.

      예제

      [root@osd ~]# mv /run/ceph-osd@0.service-cid /tmp

    4. OSD_ID 와 연결된 OSD 서비스를 다시 시작합니다.

      구문

      [root@osd ~]# systemctl restart ceph-osd@OSD_ID.service

      예제

      [root@osd ~]# systemctl restart ceph-osd@0.service

추가 리소스

10.4. 낮은 수준의 오브젝트 작업 문제 해결

스토리지 관리자는 ceph-objectstore-tool 유틸리티를 사용하여 낮은 수준의 오브젝트 작업을 수행할 수 있습니다. ceph-objectstore-tool 유틸리티는 다음과 같은 낮은 수준의 오브젝트 작업을 지원합니다.

  • 오브젝트의 콘텐츠를 조작합니다.
  • 개체 제거
  • 개체 맵 (OMAP) 나열
  • AP 헤더를 조작합니다.
  • AP 키를 조작합니다.
  • 오브젝트의 속성 나열
  • 객체의 속성 키 조작
중요

오브젝트 조작으로 인해 복구할 수 없는 데이터 손실이 발생할 수 있습니다. ceph-objectstore-tool 유틸리티를 사용하기 전에 Red Hat 지원팀에 문의하십시오.

10.4.1. 사전 요구 사항

  • Ceph OSD 노드에 대한 루트 수준 액세스.

10.4.2. 오브젝트의 콘텐츠 조작

ceph-objectstore-tool 유틸리티를 사용하면 개체에서 바이트를 가져오거나 설정할 수 있습니다.

중요

개체에서 바이트를 설정하면 복구할 수 없는 데이터 손실이 발생할 수 있습니다. 데이터 손실을 방지하려면 오브젝트의 백업 사본을 만듭니다.

사전 요구 사항

  • Ceph OSD 노드에 대한 루트 수준 액세스.
  • ceph-osd 데몬 중지.

절차

  1. 적절한 OSD가 다운되었는지 확인합니다. 

    [root@osd ~]# systemctl status ceph-osd@$OSD_NUMBER

    예제

    [root@osd ~]# systemctl status ceph-osd@1

  2. 컨테이너화된 배포의 경우 bluestore 툴에 액세스하려면 다음 단계를 따르십시오.

    1. 클러스터에 noout 플래그를 설정합니다.

      예제

      [root@mon ~]# ceph osd set noout

    2. OSD 컨테이너를 호스팅하는 노드에 로그인합니다.

    3. /etc/systemd/system/ceph-osd@.service 장치 파일을 /root 디렉토리로 백업합니다.

      예제

      [root@osd ~]# cp /etc/systemd/system/ceph-osd@.service /root/ceph-osd@.service.backup

    4. /run/ceph-osd@OSD_ID.service-cid 파일을 /root 로 이동합니다.

      예제

      [root@osd ~]# mv /run/ceph-osd@0.service-cid /root

    5. /etc/systemd/system/ceph-osd@.service 장치 파일을 편집하고 podman 명령에 -it --entrypoint /bin/bash 옵션을 추가합니다.

      예제

      # Please do not change this file directly since it is managed by Ansible and will be overwritten
[Unit]
Description=Ceph OSD
After=network.target

[Service]
EnvironmentFile=-/etc/environment
ExecStartPre=-/usr/bin/rm -f /%t/%n-pid /%t/%n-cid
ExecStartPre=-/usr/bin/podman rm -f ceph-osd-%i
ExecStart=/usr/bin/podman run -it --entrypoint /bin/bash \
  -d --conmon-pidfile /%t/%n-pid --cidfile /%t/%n-cid \
  --rm \
  --net=host \
  --privileged=true \
  --pid=host \
  --ipc=host \
  --cpus=2 \
  -v /dev:/dev \
  -v /etc/localtime:/etc/localtime:ro \
  -v /var/lib/ceph:/var/lib/ceph:z \
  -v /etc/ceph:/etc/ceph:z \
  -v /var/run/ceph:/var/run/ceph:z \
  -v /var/run/udev/:/var/run/udev/ \
  -v /var/log/ceph:/var/log/ceph:z \
  -e OSD_BLUESTORE=1 -e OSD_FILESTORE=0 -e OSD_DMCRYPT=0 \
  -e CLUSTER=ceph \
  -v /run/lvm/:/run/lvm/ \
  -e CEPH_DAEMON=OSD_CEPH_VOLUME_ACTIVATE \
  -e CONTAINER_IMAGE=registry.redhat.io/rhceph/rhceph-4-rhel8:latest \
  -e OSD_ID=%i \
  -e DEBUG=stayalive \
  --name=ceph-osd-%i \
   \
  registry.redhat.io/rhceph/rhceph-4-rhel8:latest
ExecStop=-/usr/bin/sh -c "/usr/bin/podman rm -f `cat /%t/%n-cid`"
KillMode=none
Restart=always
RestartSec=10s
TimeoutStartSec=120
TimeoutStopSec=15
Type=forking
PIDFile=/%t/%n-pid

[Install]
WantedBy=multi-user.target

    6. systemd 관리자 구성을 다시 로드합니다.

      예제

      [root@osd ~]# systemctl daemon-reload

    7. OSD_ID 와 연결된 OSD 서비스를 다시 시작합니다.

      구문

      systemctl restart ceph-osd@OSD_ID.service

      OSD_ID 를 OSD의 ID로 바꿉니다.

      예제

      [root@osd ~]# systemctl restart ceph-osd@0.service

    8. OSD_ID 와 연결된 컨테이너에 로그인합니다.

      구문

      podman exec -it ceph-osd-OSD_ID /bin/bash

      예제

      [root@osd ~]# podman exec -it ceph-osd-0 /bin/bash

    9. osd fsid 를 가져오고 OSD를 활성화하여 OSD의 논리 볼륨(LV)을 마운트합니다.

      구문

      ceph-volume lvm list |grep -A15 "osd\.OSD_ID"|grep "osd fsid"
ceph-volume lvm activate --bluestore OSD_ID OSD_FSID

      예제

      [root@osd ~]# ceph-volume lvm list |grep -A15 "osd\.0"|grep "osd fsid"
              osd fsid                  087eee15-6561-40a3-8fe4-9583ba64a4ff
[root@osd ~]# ceph-volume lvm activate --bluestore 0 087eee15-6561-40a3-8fe4-9583ba64a4ff
Running command: /usr/bin/mount -t tmpfs tmpfs /var/lib/ceph/osd/ceph-0
Running command: /usr/bin/chown -R ceph:ceph /var/lib/ceph/osd/ceph-0
Running command: /usr/bin/ceph-bluestore-tool --cluster=ceph prime-osd-dir --dev /dev/ceph-41c69f8f-30e2-4685-9c5c-c605898c5537/osd-data-d073e8b3-0b89-4271-af5b-83045fd000dc --path /var/lib/ceph/osd/ceph-0 --no-mon-config
Running command: /usr/bin/ln -snf /dev/ceph-41c69f8f-30e2-4685-9c5c-c605898c5537/osd-data-d073e8b3-0b89-4271-af5b-83045fd000dc /var/lib/ceph/osd/ceph-0/block
Running command: /usr/bin/chown -h ceph:ceph /var/lib/ceph/osd/ceph-0/block
Running command: /usr/bin/chown -R ceph:ceph /dev/mapper/ceph--41c69f8f--30e2--4685--9c5c--c605898c5537-osd--data--d073e8b3--0b89--4271--af5b--83045fd000dc
Running command: /usr/bin/chown -R ceph:ceph /var/lib/ceph/osd/ceph-0
Running command: /usr/bin/systemctl enable ceph-volume@lvm-0-087eee15-6561-40a3-8fe4-9583ba64a4ff
 stderr: Created symlink /etc/systemd/system/multi-user.target.wants/ceph-volume@lvm-0-087eee15-6561-40a3-8fe4-9583ba64a4ff.service → /usr/lib/systemd/system/ceph-volume@.service.
Running command: /usr/bin/systemctl enable --runtime ceph-osd@0
 stderr: Created symlink /run/systemd/system/ceph-osd.target.wants/ceph osd@0.service → /usr/lib/systemd/system/ceph-osd@.service.
Running command: /usr/bin/systemctl start ceph-osd@0
 stderr: Running in chroot, ignoring request: start
--> ceph-volume lvm activate successful for osd ID: 0

  3. OSD 또는 배치 그룹(PG)의 개체를 나열하여 개체를 찾습니다.

  4. 오브젝트에서 바이트를 설정하기 전에 백업과 오브젝트 작업 복사본을 만듭니다. 

    [root@osd ~]# ceph-objectstore-tool --data-path PATH_TO_OSD --pgid PG_ID \
OBJECT \
get-bytes > OBJECT_FILE_NAME

[root@osd ~]# ceph-objectstore-tool --data-path PATH_TO_OSD --pgid PG_ID \
OBJECT \
get-bytes > OBJECT_FILE_NAME

    예제

    [root@osd ~]# ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-0 --pgid 0.1c \
'{"oid":"zone_info.default","key":"","snapid":-2,"hash":235010478,"max":0,"pool":11,"namespace":""}'  \
get-bytes > zone_info.default.backup

[root@osd ~]# ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-0 --pgid 0.1c \
'{"oid":"zone_info.default","key":"","snapid":-2,"hash":235010478,"max":0,"pool":11,"namespace":""}'  \
get-bytes > zone_info.default.working-copy

  5. 작업 복사본 오브젝트 파일을 편집하고 그에 따라 오브젝트 콘텐츠를 수정합니다.

  6. 오브젝트의 바이트를 설정합니다. 

    [root@osd ~]# ceph-objectstore-tool --data-path PATH_TO_OSD --pgid PG_ID \
OBJECT \
set-bytes < OBJECT_FILE_NAME

    예제

    [root@osd ~]# ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-0 --pgid 0.1c \
'{"oid":"zone_info.default","key":"","snapid":-2,"hash":235010478,"max":0,"pool":11,"namespace":""}' \
set-bytes < zone_info.default.working-copy

  7. 컨테이너화된 배포의 경우 변경 사항을 되돌리려면 다음 단계를 따르십시오.

    1. 컨테이너를 종료한 후 /root 디렉터리에서 /etc/systemd/system/ceph-osd@.service 장치 파일을 복사합니다.

      예제

      [root@osd ~]# cp /etc/systemd/system/ceph-osd@.service /root/ceph-osd@.service.modified
[root@osd ~]# cp /root/ceph-osd@.service.backup /etc/systemd/system/ceph-osd@.service

    2. systemd 관리자 구성을 다시 로드합니다.

      예제

      [root@osd ~]# systemctl daemon-reload

    3. /run/ceph-osd@OSD_ID.service-cid 파일을 /tmp 로 이동합니다.

      예제

      [root@osd ~]# mv /run/ceph-osd@0.service-cid /tmp

    4. OSD_ID 와 연결된 OSD 서비스를 다시 시작합니다.

      구문

      [root@osd ~]# systemctl restart ceph-osd@OSD_ID.service

      예제

      [root@osd ~]# systemctl restart ceph-osd@0.service

추가 리소스

10.4.3. 오브젝트 제거

ceph-objectstore-tool 유틸리티를 사용하여 오브젝트를 제거합니다. 오브젝트를 제거하면 해당 콘텐츠와 참조가 배치 그룹(PG)에서 제거됩니다.

중요

제거한 후에는 오브젝트를 다시 생성할 수 없습니다.

사전 요구 사항

  • Ceph OSD 노드에 대한 루트 수준 액세스.
  • ceph-osd 데몬 중지.

절차

  1. 적절한 OSD가 다운되었는지 확인합니다. 

    [root@osd ~]# systemctl status ceph-osd@$OSD_NUMBER

    예제

    [root@osd ~]# systemctl status ceph-osd@1

  2. 컨테이너화된 배포의 경우 bluestore 툴에 액세스하려면 다음 단계를 따르십시오.

    1. 클러스터에 noout 플래그를 설정합니다.

      예제

      [root@mon ~]# ceph osd set noout

    2. OSD 컨테이너를 호스팅하는 노드에 로그인합니다.

    3. /etc/systemd/system/ceph-osd@.service 장치 파일을 /root 디렉토리로 백업합니다.

      예제

      [root@osd ~]# cp /etc/systemd/system/ceph-osd@.service /root/ceph-osd@.service.backup

    4. /run/ceph-osd@OSD_ID.service-cid 파일을 /root 로 이동합니다.

      예제

      [root@osd ~]# mv /run/ceph-osd@0.service-cid /root

    5. /etc/systemd/system/ceph-osd@.service 장치 파일을 편집하고 podman 명령에 -it --entrypoint /bin/bash 옵션을 추가합니다.

      예제

      # Please do not change this file directly since it is managed by Ansible and will be overwritten
[Unit]
Description=Ceph OSD
After=network.target

[Service]
EnvironmentFile=-/etc/environment
ExecStartPre=-/usr/bin/rm -f /%t/%n-pid /%t/%n-cid
ExecStartPre=-/usr/bin/podman rm -f ceph-osd-%i
ExecStart=/usr/bin/podman run -it --entrypoint /bin/bash \
  -d --conmon-pidfile /%t/%n-pid --cidfile /%t/%n-cid \
  --rm \
  --net=host \
  --privileged=true \
  --pid=host \
  --ipc=host \
  --cpus=2 \
  -v /dev:/dev \
  -v /etc/localtime:/etc/localtime:ro \
  -v /var/lib/ceph:/var/lib/ceph:z \
  -v /etc/ceph:/etc/ceph:z \
  -v /var/run/ceph:/var/run/ceph:z \
  -v /var/run/udev/:/var/run/udev/ \
  -v /var/log/ceph:/var/log/ceph:z \
  -e OSD_BLUESTORE=1 -e OSD_FILESTORE=0 -e OSD_DMCRYPT=0 \
  -e CLUSTER=ceph \
  -v /run/lvm/:/run/lvm/ \
  -e CEPH_DAEMON=OSD_CEPH_VOLUME_ACTIVATE \
  -e CONTAINER_IMAGE=registry.redhat.io/rhceph/rhceph-4-rhel8:latest \
  -e OSD_ID=%i \
  -e DEBUG=stayalive \
  --name=ceph-osd-%i \
   \
  registry.redhat.io/rhceph/rhceph-4-rhel8:latest
ExecStop=-/usr/bin/sh -c "/usr/bin/podman rm -f `cat /%t/%n-cid`"
KillMode=none
Restart=always
RestartSec=10s
TimeoutStartSec=120
TimeoutStopSec=15
Type=forking
PIDFile=/%t/%n-pid

[Install]
WantedBy=multi-user.target

    6. systemd 관리자 구성을 다시 로드합니다.

      예제

      [root@osd ~]# systemctl daemon-reload

    7. OSD_ID 와 연결된 OSD 서비스를 다시 시작합니다.

      구문

      systemctl restart ceph-osd@OSD_ID.service

      OSD_ID 를 OSD의 ID로 바꿉니다.

      예제

      [root@osd ~]# systemctl restart ceph-osd@0.service

    8. OSD_ID 와 연결된 컨테이너에 로그인합니다.

      구문

      podman exec -it ceph-osd-OSD_ID /bin/bash

      예제

      [root@osd ~]# podman exec -it ceph-osd-0 /bin/bash

    9. osd fsid 를 가져오고 OSD를 활성화하여 OSD의 논리 볼륨(LV)을 마운트합니다.

      구문

      ceph-volume lvm list |grep -A15 "osd\.OSD_ID"|grep "osd fsid"
ceph-volume lvm activate --bluestore OSD_ID OSD_FSID

      예제

      [root@osd ~]# ceph-volume lvm list |grep -A15 "osd\.0"|grep "osd fsid"
              osd fsid                  087eee15-6561-40a3-8fe4-9583ba64a4ff
[root@osd ~]# ceph-volume lvm activate --bluestore 0 087eee15-6561-40a3-8fe4-9583ba64a4ff
Running command: /usr/bin/mount -t tmpfs tmpfs /var/lib/ceph/osd/ceph-0
Running command: /usr/bin/chown -R ceph:ceph /var/lib/ceph/osd/ceph-0
Running command: /usr/bin/ceph-bluestore-tool --cluster=ceph prime-osd-dir --dev /dev/ceph-41c69f8f-30e2-4685-9c5c-c605898c5537/osd-data-d073e8b3-0b89-4271-af5b-83045fd000dc --path /var/lib/ceph/osd/ceph-0 --no-mon-config
Running command: /usr/bin/ln -snf /dev/ceph-41c69f8f-30e2-4685-9c5c-c605898c5537/osd-data-d073e8b3-0b89-4271-af5b-83045fd000dc /var/lib/ceph/osd/ceph-0/block
Running command: /usr/bin/chown -h ceph:ceph /var/lib/ceph/osd/ceph-0/block
Running command: /usr/bin/chown -R ceph:ceph /dev/mapper/ceph--41c69f8f--30e2--4685--9c5c--c605898c5537-osd--data--d073e8b3--0b89--4271--af5b--83045fd000dc
Running command: /usr/bin/chown -R ceph:ceph /var/lib/ceph/osd/ceph-0
Running command: /usr/bin/systemctl enable ceph-volume@lvm-0-087eee15-6561-40a3-8fe4-9583ba64a4ff
 stderr: Created symlink /etc/systemd/system/multi-user.target.wants/ceph-volume@lvm-0-087eee15-6561-40a3-8fe4-9583ba64a4ff.service → /usr/lib/systemd/system/ceph-volume@.service.
Running command: /usr/bin/systemctl enable --runtime ceph-osd@0
 stderr: Created symlink /run/systemd/system/ceph-osd.target.wants/ceph osd@0.service → /usr/lib/systemd/system/ceph-osd@.service.
Running command: /usr/bin/systemctl start ceph-osd@0
 stderr: Running in chroot, ignoring request: start
--> ceph-volume lvm activate successful for osd ID: 0

  3. 오브젝트를 제거합니다.

    구문

    ceph-objectstore-tool --data-path PATH_TO_OSD --pgid PG_ID \
OBJECT \
remove

    예제

    [root@osd ~]# ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-0 --pgid 0.1c \
'{"oid":"zone_info.default","key":"","snapid":-2,"hash":235010478,"max":0,"pool":11,"namespace":""}' \
remove

  4. 컨테이너화된 배포의 경우 변경 사항을 되돌리려면 다음 단계를 따르십시오.

    1. 컨테이너를 종료한 후 /root 디렉터리에서 /etc/systemd/system/ceph-osd@.service 장치 파일을 복사합니다.

      예제

      [root@osd ~]# cp /etc/systemd/system/ceph-osd@.service /root/ceph-osd@.service.modified
[root@osd ~]# cp /root/ceph-osd@.service.backup /etc/systemd/system/ceph-osd@.service

    2. systemd 관리자 구성을 다시 로드합니다.

      예제

      [root@osd ~]# systemctl daemon-reload

    3. /run/ceph-osd@OSD_ID.service-cid 파일을 /tmp 로 이동합니다.

      예제

      [root@osd ~]# mv /run/ceph-osd@0.service-cid /tmp

    4. OSD_ID 와 연결된 OSD 서비스를 다시 시작합니다.

      구문

      [root@osd ~]# systemctl restart ceph-osd@OSD_ID.service

      예제

      [root@osd ~]# systemctl restart ceph-osd@0.service

추가 리소스

10.4.4. 오브젝트 맵 나열

ceph-objectstore-tool 유틸리티를 사용하여 개체 맵(OMAP) 내용을 나열합니다. 출력에 키 목록이 제공됩니다.

사전 요구 사항

  • Ceph OSD 노드에 대한 루트 수준 액세스.
  • ceph-osd 데몬 중지.

절차

  1. 적절한 OSD가 다운되었는지 확인합니다. 

    [root@osd ~]# systemctl status ceph-osd@OSD_NUMBER

    예제

    [root@osd ~]# systemctl status ceph-osd@1

  2. 컨테이너화된 배포의 경우 bluestore 툴에 액세스하려면 다음 단계를 따르십시오.

    1. 클러스터에 noout 플래그를 설정합니다.

      예제

      [root@mon ~]# ceph osd set noout

    2. OSD 컨테이너를 호스팅하는 노드에 로그인합니다.

    3. /etc/systemd/system/ceph-osd@.service 장치 파일을 /root 디렉토리로 백업합니다.

      예제

      [root@osd ~]# cp /etc/systemd/system/ceph-osd@.service /root/ceph-osd@.service.backup

    4. /run/ceph-osd@OSD_ID.service-cid 파일을 /root 로 이동합니다.

      예제

      [root@osd ~]# mv /run/ceph-osd@0.service-cid /root

    5. /etc/systemd/system/ceph-osd@.service 장치 파일을 편집하고 podman 명령에 -it --entrypoint /bin/bash 옵션을 추가합니다.

      예제

      # Please do not change this file directly since it is managed by Ansible and will be overwritten
[Unit]
Description=Ceph OSD
After=network.target

[Service]
EnvironmentFile=-/etc/environment
ExecStartPre=-/usr/bin/rm -f /%t/%n-pid /%t/%n-cid
ExecStartPre=-/usr/bin/podman rm -f ceph-osd-%i
ExecStart=/usr/bin/podman run -it --entrypoint /bin/bash \
  -d --conmon-pidfile /%t/%n-pid --cidfile /%t/%n-cid \
  --rm \
  --net=host \
  --privileged=true \
  --pid=host \
  --ipc=host \
  --cpus=2 \
  -v /dev:/dev \
  -v /etc/localtime:/etc/localtime:ro \
  -v /var/lib/ceph:/var/lib/ceph:z \
  -v /etc/ceph:/etc/ceph:z \
  -v /var/run/ceph:/var/run/ceph:z \
  -v /var/run/udev/:/var/run/udev/ \
  -v /var/log/ceph:/var/log/ceph:z \
  -e OSD_BLUESTORE=1 -e OSD_FILESTORE=0 -e OSD_DMCRYPT=0 \
  -e CLUSTER=ceph \
  -v /run/lvm/:/run/lvm/ \
  -e CEPH_DAEMON=OSD_CEPH_VOLUME_ACTIVATE \
  -e CONTAINER_IMAGE=registry.redhat.io/rhceph/rhceph-4-rhel8:latest \
  -e OSD_ID=%i \
  -e DEBUG=stayalive \
  --name=ceph-osd-%i \
   \
  registry.redhat.io/rhceph/rhceph-4-rhel8:latest
ExecStop=-/usr/bin/sh -c "/usr/bin/podman rm -f `cat /%t/%n-cid`"
KillMode=none
Restart=always
RestartSec=10s
TimeoutStartSec=120
TimeoutStopSec=15
Type=forking
PIDFile=/%t/%n-pid

[Install]
WantedBy=multi-user.target

    6. systemd 관리자 구성을 다시 로드합니다.

      예제

      [root@osd ~]# systemctl daemon-reload

    7. OSD_ID 와 연결된 OSD 서비스를 다시 시작합니다.

      구문

      systemctl restart ceph-osd@OSD_ID.service

      OSD_ID 를 OSD의 ID로 바꿉니다.

      예제

      [root@osd ~]# systemctl restart ceph-osd@0.service

    8. OSD_ID 와 연결된 컨테이너에 로그인합니다.

      구문

      podman exec -it ceph-osd-OSD_ID /bin/bash

      예제

      [root@osd ~]# podman exec -it ceph-osd-0 /bin/bash

    9. osd fsid 를 가져오고 OSD를 활성화하여 OSD의 논리 볼륨(LV)을 마운트합니다.

      구문

      ceph-volume lvm list |grep -A15 "osd\.OSD_ID"|grep "osd fsid"
ceph-volume lvm activate --bluestore OSD_ID OSD_FSID

      예제

      [root@osd ~]# ceph-volume lvm list |grep -A15 "osd\.0"|grep "osd fsid"
              osd fsid                  087eee15-6561-40a3-8fe4-9583ba64a4ff
[root@osd ~]# ceph-volume lvm activate --bluestore 0 087eee15-6561-40a3-8fe4-9583ba64a4ff
Running command: /usr/bin/mount -t tmpfs tmpfs /var/lib/ceph/osd/ceph-0
Running command: /usr/bin/chown -R ceph:ceph /var/lib/ceph/osd/ceph-0
Running command: /usr/bin/ceph-bluestore-tool --cluster=ceph prime-osd-dir --dev /dev/ceph-41c69f8f-30e2-4685-9c5c-c605898c5537/osd-data-d073e8b3-0b89-4271-af5b-83045fd000dc --path /var/lib/ceph/osd/ceph-0 --no-mon-config
Running command: /usr/bin/ln -snf /dev/ceph-41c69f8f-30e2-4685-9c5c-c605898c5537/osd-data-d073e8b3-0b89-4271-af5b-83045fd000dc /var/lib/ceph/osd/ceph-0/block
Running command: /usr/bin/chown -h ceph:ceph /var/lib/ceph/osd/ceph-0/block
Running command: /usr/bin/chown -R ceph:ceph /dev/mapper/ceph--41c69f8f--30e2--4685--9c5c--c605898c5537-osd--data--d073e8b3--0b89--4271--af5b--83045fd000dc
Running command: /usr/bin/chown -R ceph:ceph /var/lib/ceph/osd/ceph-0
Running command: /usr/bin/systemctl enable ceph-volume@lvm-0-087eee15-6561-40a3-8fe4-9583ba64a4ff
 stderr: Created symlink /etc/systemd/system/multi-user.target.wants/ceph-volume@lvm-0-087eee15-6561-40a3-8fe4-9583ba64a4ff.service → /usr/lib/systemd/system/ceph-volume@.service.
Running command: /usr/bin/systemctl enable --runtime ceph-osd@0
 stderr: Created symlink /run/systemd/system/ceph-osd.target.wants/ceph osd@0.service → /usr/lib/systemd/system/ceph-osd@.service.
Running command: /usr/bin/systemctl start ceph-osd@0
 stderr: Running in chroot, ignoring request: start
--> ceph-volume lvm activate successful for osd ID: 0

  3. 오브젝트 맵을 나열합니다. 

    [root@osd ~]# ceph-objectstore-tool --data-path PATH_TO_OSD --pgid PG_ID \
OBJECT \
list-omap

    예제

    [root@osd ~]# ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-0 --pgid 0.1c \
'{"oid":"zone_info.default","key":"","snapid":-2,"hash":235010478,"max":0,"pool":11,"namespace":""}' \
list-omap

  4. 컨테이너화된 배포의 경우 변경 사항을 되돌리려면 다음 단계를 따르십시오.

    1. 컨테이너를 종료한 후 /root 디렉터리에서 /etc/systemd/system/ceph-osd@.service 장치 파일을 복사합니다.

      예제

      [root@osd ~]# cp /etc/systemd/system/ceph-osd@.service /root/ceph-osd@.service.modified
[root@osd ~]# cp /root/ceph-osd@.service.backup /etc/systemd/system/ceph-osd@.service

    2. systemd 관리자 구성을 다시 로드합니다.

      예제

      [root@osd ~]# systemctl daemon-reload

    3. /run/ceph-osd@OSD_ID.service-cid 파일을 /tmp 로 이동합니다.

      예제

      [root@osd ~]# mv /run/ceph-osd@0.service-cid /tmp

    4. OSD_ID 와 연결된 OSD 서비스를 다시 시작합니다.

      구문

      [root@osd ~]# systemctl restart ceph-osd@OSD_ID.service

      예제

      [root@osd ~]# systemctl restart ceph-osd@0.service

추가 리소스

10.4.5. 오브젝트 맵 헤더 조작

ceph-objectstore-tool 유틸리티는 개체 맵(OMAP) 헤더를 오브젝트 키와 관련된 값으로 출력합니다.

사전 요구 사항

  • Ceph OSD 노드에 대한 루트 수준 액세스.
  • ceph-osd 데몬 중지.

절차

  1. 컨테이너화된 배포의 경우 bluestore 툴에 액세스하려면 다음 단계를 따르십시오.

    1. 클러스터에 noout 플래그를 설정합니다.

      예제

      [root@mon ~]# ceph osd set noout

    2. OSD 컨테이너를 호스팅하는 노드에 로그인합니다.

    3. /etc/systemd/system/ceph-osd@.service 장치 파일을 /root 디렉토리로 백업합니다.

      예제

      [root@osd ~]# cp /etc/systemd/system/ceph-osd@.service /root/ceph-osd@.service.backup

    4. /run/ceph-osd@OSD_ID.service-cid 파일을 /root 로 이동합니다.

      예제

      [root@osd ~]# mv /run/ceph-osd@0.service-cid /root

    5. /etc/systemd/system/ceph-osd@.service 장치 파일을 편집하고 podman 명령에 -it --entrypoint /bin/bash 옵션을 추가합니다.

      예제

      # Please do not change this file directly since it is managed by Ansible and will be overwritten
[Unit]
Description=Ceph OSD
After=network.target

[Service]
EnvironmentFile=-/etc/environment
ExecStartPre=-/usr/bin/rm -f /%t/%n-pid /%t/%n-cid
ExecStartPre=-/usr/bin/podman rm -f ceph-osd-%i
ExecStart=/usr/bin/podman run -it --entrypoint /bin/bash \
  -d --conmon-pidfile /%t/%n-pid --cidfile /%t/%n-cid \
  --rm \
  --net=host \
  --privileged=true \
  --pid=host \
  --ipc=host \
  --cpus=2 \
  -v /dev:/dev \
  -v /etc/localtime:/etc/localtime:ro \
  -v /var/lib/ceph:/var/lib/ceph:z \
  -v /etc/ceph:/etc/ceph:z \
  -v /var/run/ceph:/var/run/ceph:z \
  -v /var/run/udev/:/var/run/udev/ \
  -v /var/log/ceph:/var/log/ceph:z \
  -e OSD_BLUESTORE=1 -e OSD_FILESTORE=0 -e OSD_DMCRYPT=0 \
  -e CLUSTER=ceph \
  -v /run/lvm/:/run/lvm/ \
  -e CEPH_DAEMON=OSD_CEPH_VOLUME_ACTIVATE \
  -e CONTAINER_IMAGE=registry.redhat.io/rhceph/rhceph-4-rhel8:latest \
  -e OSD_ID=%i \
  -e DEBUG=stayalive \
  --name=ceph-osd-%i \
   \
  registry.redhat.io/rhceph/rhceph-4-rhel8:latest
ExecStop=-/usr/bin/sh -c "/usr/bin/podman rm -f `cat /%t/%n-cid`"
KillMode=none
Restart=always
RestartSec=10s
TimeoutStartSec=120
TimeoutStopSec=15
Type=forking
PIDFile=/%t/%n-pid

[Install]
WantedBy=multi-user.target

    6. systemd 관리자 구성을 다시 로드합니다.

      예제

      [root@osd ~]# systemctl daemon-reload

    7. OSD_ID 와 연결된 OSD 서비스를 다시 시작합니다.

      구문

      systemctl restart ceph-osd@OSD_ID.service

      OSD_ID 를 OSD의 ID로 바꿉니다.

      예제

      [root@osd ~]# systemctl restart ceph-osd@0.service

    8. OSD_ID 와 연결된 컨테이너에 로그인합니다.

      구문

      podman exec -it ceph-osd-OSD_ID /bin/bash

      예제

      [root@osd ~]# podman exec -it ceph-osd-0 /bin/bash

    9. osd fsid 를 가져오고 OSD를 활성화하여 OSD의 논리 볼륨(LV)을 마운트합니다.

      구문

      ceph-volume lvm list |grep -A15 "osd\.OSD_ID"|grep "osd fsid"
ceph-volume lvm activate --bluestore OSD_ID OSD_FSID

      예제

      [root@osd ~]# ceph-volume lvm list |grep -A15 "osd\.0"|grep "osd fsid"
              osd fsid                  087eee15-6561-40a3-8fe4-9583ba64a4ff
[root@osd ~]# ceph-volume lvm activate --bluestore 0 087eee15-6561-40a3-8fe4-9583ba64a4ff
Running command: /usr/bin/mount -t tmpfs tmpfs /var/lib/ceph/osd/ceph-0
Running command: /usr/bin/chown -R ceph:ceph /var/lib/ceph/osd/ceph-0
Running command: /usr/bin/ceph-bluestore-tool --cluster=ceph prime-osd-dir --dev /dev/ceph-41c69f8f-30e2-4685-9c5c-c605898c5537/osd-data-d073e8b3-0b89-4271-af5b-83045fd000dc --path /var/lib/ceph/osd/ceph-0 --no-mon-config
Running command: /usr/bin/ln -snf /dev/ceph-41c69f8f-30e2-4685-9c5c-c605898c5537/osd-data-d073e8b3-0b89-4271-af5b-83045fd000dc /var/lib/ceph/osd/ceph-0/block
Running command: /usr/bin/chown -h ceph:ceph /var/lib/ceph/osd/ceph-0/block
Running command: /usr/bin/chown -R ceph:ceph /dev/mapper/ceph--41c69f8f--30e2--4685--9c5c--c605898c5537-osd--data--d073e8b3--0b89--4271--af5b--83045fd000dc
Running command: /usr/bin/chown -R ceph:ceph /var/lib/ceph/osd/ceph-0
Running command: /usr/bin/systemctl enable ceph-volume@lvm-0-087eee15-6561-40a3-8fe4-9583ba64a4ff
 stderr: Created symlink /etc/systemd/system/multi-user.target.wants/ceph-volume@lvm-0-087eee15-6561-40a3-8fe4-9583ba64a4ff.service → /usr/lib/systemd/system/ceph-volume@.service.
Running command: /usr/bin/systemctl enable --runtime ceph-osd@0
 stderr: Created symlink /run/systemd/system/ceph-osd.target.wants/ceph osd@0.service → /usr/lib/systemd/system/ceph-osd@.service.
Running command: /usr/bin/systemctl start ceph-osd@0
 stderr: Running in chroot, ignoring request: start
--> ceph-volume lvm activate successful for osd ID: 0

  2. 적절한 OSD가 다운되었는지 확인합니다.

    구문

    systemctl status ceph-osd@OSD_NUMBER

    예제

    [root@osd ~]# systemctl status ceph-osd@1

  3. 오브젝트 맵 헤더를 가져옵니다.

    구문

    ceph-objectstore-tool --data-path PATH_TO_OSD \
--pgid PG_ID OBJECT \
get-omaphdr > OBJECT_MAP_FILE_NAME

    예제

    [root@osd ~]# ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-0 \
--pgid 0.1c '{"oid":"zone_info.default","key":"","snapid":-2,"hash":235010478,"max":0,"pool":11,"namespace":""}'  \
get-omaphdr > zone_info.default.omaphdr.txt

  4. 오브젝트 맵 헤더를 설정합니다.

    구문

    ceph-objectstore-tool --data-path PATH_TO_OSD \
--pgid PG_ID OBJECT \
get-omaphdr < OBJECT_MAP_FILE_NAME

    예제

    [root@osd ~]# su - ceph -c 'ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-0 \
--pgid 0.1c '{"oid":"zone_info.default","key":"","snapid":-2,"hash":235010478,"max":0,"pool":11,"namespace":""}'  \
set-omaphdr < zone_info.default.omaphdr.txt

  5. 컨테이너화된 배포의 경우 변경 사항을 되돌리려면 다음 단계를 따르십시오.

    1. 컨테이너를 종료한 후 /root 디렉터리에서 /etc/systemd/system/ceph-osd@.service 장치 파일을 복사합니다.

      예제

      [root@osd ~]# cp /etc/systemd/system/ceph-osd@.service /root/ceph-osd@.service.modified
[root@osd ~]# cp /root/ceph-osd@.service.backup /etc/systemd/system/ceph-osd@.service

    2. systemd 관리자 구성을 다시 로드합니다.

      예제

      [root@osd ~]# systemctl daemon-reload

    3. /run/ceph-osd@OSD_ID.service-cid 파일을 /tmp 로 이동합니다.

      예제

      [root@osd ~]# mv /run/ceph-osd@0.service-cid /tmp

    4. OSD_ID 와 연결된 OSD 서비스를 다시 시작합니다.

      구문

      [root@osd ~]# systemctl restart ceph-osd@OSD_ID.service

      예제

      [root@osd ~]# systemctl restart ceph-osd@0.service

추가 리소스

10.4.6. 오브젝트 맵 키 조작

ceph-objectstore-tool 유틸리티를 사용하여 개체 맵(OMAP) 키를 변경합니다. 데이터 경로, PG ID(배치 그룹 식별자), 오브젝트 및 POSIXAP의 키를 제공해야 합니다.

사전 요구 사항

  • Ceph OSD 노드에 대한 루트 수준 액세스.
  • ceph-osd 데몬 중지.

절차

  1. 컨테이너화된 배포의 경우 bluestore 툴에 액세스하려면 다음 단계를 따르십시오.

    1. 클러스터에 noout 플래그를 설정합니다.

      예제

      [root@mon ~]# ceph osd set noout

    2. OSD 컨테이너를 호스팅하는 노드에 로그인합니다.

    3. /etc/systemd/system/ceph-osd@.service 장치 파일을 /root 디렉토리로 백업합니다.

      예제

      [root@osd ~]# cp /etc/systemd/system/ceph-osd@.service /root/ceph-osd@.service.backup

    4. /run/ceph-osd@OSD_ID.service-cid 파일을 /root 로 이동합니다.

      예제

      [root@osd ~]# mv /run/ceph-osd@0.service-cid /root

    5. /etc/systemd/system/ceph-osd@.service 장치 파일을 편집하고 podman 명령에 -it --entrypoint /bin/bash 옵션을 추가합니다.

      예제

      # Please do not change this file directly since it is managed by Ansible and will be overwritten
[Unit]
Description=Ceph OSD
After=network.target

[Service]
EnvironmentFile=-/etc/environment
ExecStartPre=-/usr/bin/rm -f /%t/%n-pid /%t/%n-cid
ExecStartPre=-/usr/bin/podman rm -f ceph-osd-%i
ExecStart=/usr/bin/podman run -it --entrypoint /bin/bash \
  -d --conmon-pidfile /%t/%n-pid --cidfile /%t/%n-cid \
  --rm \
  --net=host \
  --privileged=true \
  --pid=host \
  --ipc=host \
  --cpus=2 \
  -v /dev:/dev \
  -v /etc/localtime:/etc/localtime:ro \
  -v /var/lib/ceph:/var/lib/ceph:z \
  -v /etc/ceph:/etc/ceph:z \
  -v /var/run/ceph:/var/run/ceph:z \
  -v /var/run/udev/:/var/run/udev/ \
  -v /var/log/ceph:/var/log/ceph:z \
  -e OSD_BLUESTORE=1 -e OSD_FILESTORE=0 -e OSD_DMCRYPT=0 \
  -e CLUSTER=ceph \
  -v /run/lvm/:/run/lvm/ \
  -e CEPH_DAEMON=OSD_CEPH_VOLUME_ACTIVATE \
  -e CONTAINER_IMAGE=registry.redhat.io/rhceph/rhceph-4-rhel8:latest \
  -e OSD_ID=%i \
  -e DEBUG=stayalive \
  --name=ceph-osd-%i \
   \
  registry.redhat.io/rhceph/rhceph-4-rhel8:latest
ExecStop=-/usr/bin/sh -c "/usr/bin/podman rm -f `cat /%t/%n-cid`"
KillMode=none
Restart=always
RestartSec=10s
TimeoutStartSec=120
TimeoutStopSec=15
Type=forking
PIDFile=/%t/%n-pid

[Install]
WantedBy=multi-user.target

    6. systemd 관리자 구성을 다시 로드합니다.

      예제

      [root@osd ~]# systemctl daemon-reload

    7. OSD_ID 와 연결된 OSD 서비스를 다시 시작합니다.

      구문

      systemctl restart ceph-osd@OSD_ID.service

      OSD_ID 를 OSD의 ID로 바꿉니다.

      예제

      [root@osd ~]# systemctl restart ceph-osd@0.service

    8. OSD_ID 와 연결된 컨테이너에 로그인합니다.

      구문

      podman exec -it ceph-osd-OSD_ID /bin/bash

      예제

      [root@osd ~]# podman exec -it ceph-osd-0 /bin/bash

    9. osd fsid 를 가져오고 OSD를 활성화하여 OSD의 논리 볼륨(LV)을 마운트합니다.

      구문

      ceph-volume lvm list |grep -A15 "osd\.OSD_ID"|grep "osd fsid"
ceph-volume lvm activate --bluestore OSD_ID OSD_FSID

      예제

      [root@osd ~]# ceph-volume lvm list |grep -A15 "osd\.0"|grep "osd fsid"
              osd fsid                  087eee15-6561-40a3-8fe4-9583ba64a4ff
[root@osd ~]# ceph-volume lvm activate --bluestore 0 087eee15-6561-40a3-8fe4-9583ba64a4ff
Running command: /usr/bin/mount -t tmpfs tmpfs /var/lib/ceph/osd/ceph-0
Running command: /usr/bin/chown -R ceph:ceph /var/lib/ceph/osd/ceph-0
Running command: /usr/bin/ceph-bluestore-tool --cluster=ceph prime-osd-dir --dev /dev/ceph-41c69f8f-30e2-4685-9c5c-c605898c5537/osd-data-d073e8b3-0b89-4271-af5b-83045fd000dc --path /var/lib/ceph/osd/ceph-0 --no-mon-config
Running command: /usr/bin/ln -snf /dev/ceph-41c69f8f-30e2-4685-9c5c-c605898c5537/osd-data-d073e8b3-0b89-4271-af5b-83045fd000dc /var/lib/ceph/osd/ceph-0/block
Running command: /usr/bin/chown -h ceph:ceph /var/lib/ceph/osd/ceph-0/block
Running command: /usr/bin/chown -R ceph:ceph /dev/mapper/ceph--41c69f8f--30e2--4685--9c5c--c605898c5537-osd--data--d073e8b3--0b89--4271--af5b--83045fd000dc
Running command: /usr/bin/chown -R ceph:ceph /var/lib/ceph/osd/ceph-0
Running command: /usr/bin/systemctl enable ceph-volume@lvm-0-087eee15-6561-40a3-8fe4-9583ba64a4ff
 stderr: Created symlink /etc/systemd/system/multi-user.target.wants/ceph-volume@lvm-0-087eee15-6561-40a3-8fe4-9583ba64a4ff.service → /usr/lib/systemd/system/ceph-volume@.service.
Running command: /usr/bin/systemctl enable --runtime ceph-osd@0
 stderr: Created symlink /run/systemd/system/ceph-osd.target.wants/ceph osd@0.service → /usr/lib/systemd/system/ceph-osd@.service.
Running command: /usr/bin/systemctl start ceph-osd@0
 stderr: Running in chroot, ignoring request: start
--> ceph-volume lvm activate successful for osd ID: 0

  2. 오브젝트 맵 키를 가져옵니다.

    구문

    ceph-objectstore-tool --data-path PATH_TO_OSD \
--pgid PG_ID OBJECT \
get-omap KEY > OBJECT_MAP_FILE_NAME

    예제

    [root@osd ~]# ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-0 \
--pgid 0.1c '{"oid":"zone_info.default","key":"","snapid":-2,"hash":235010478,"max":0,"pool":11,"namespace":""}'  \
get-omap "" > zone_info.default.omap.txt

  3. 오브젝트 맵 키를 설정합니다.

    구문

    ceph-objectstore-tool --data-path PATH_TO_OSD \
--pgid PG_ID OBJECT \
set-omap KEY < OBJECT_MAP_FILE_NAME

    예제

    [root@osd ~]# ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-0 \
--pgid 0.1c '{"oid":"zone_info.default","key":"","snapid":-2,"hash":235010478,"max":0,"pool":11,"namespace":""}'  \
set-omap "" < zone_info.default.omap.txt

    • 오브젝트 맵 키를 제거합니다.

      구문

      ceph-objectstore-tool --data-path PATH_TO_OSD \
--pgid PG_ID OBJECT \
rm-omap KEY

      예제

      [root@osd ~]# ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-0 \
--pgid 0.1c '{"oid":"zone_info.default","key":"","snapid":-2,"hash":235010478,"max":0,"pool":11,"namespace":""}'  \
rm-omap ""

  4. 컨테이너화된 배포의 경우 변경 사항을 되돌리려면 다음 단계를 따르십시오.

    1. 컨테이너를 종료한 후 /root 디렉터리에서 /etc/systemd/system/ceph-osd@.service 장치 파일을 복사합니다.

      예제

      [root@osd ~]# cp /etc/systemd/system/ceph-osd@.service /root/ceph-osd@.service.modified
[root@osd ~]# cp /root/ceph-osd@.service.backup /etc/systemd/system/ceph-osd@.service

    2. systemd 관리자 구성을 다시 로드합니다.

      예제

      [root@osd ~]# systemctl daemon-reload

    3. /run/ceph-osd@OSD_ID.service-cid 파일을 /tmp 로 이동합니다.

      예제

      [root@osd ~]# mv /run/ceph-osd@0.service-cid /tmp

    4. OSD_ID 와 연결된 OSD 서비스를 다시 시작합니다.

      구문

      [root@osd ~]# systemctl restart ceph-osd@OSD_ID.service

      예제

      [root@osd ~]# systemctl restart ceph-osd@0.service

추가 리소스

10.4.7. 오브젝트의 속성 나열

ceph-objectstore-tool 유틸리티를 사용하여 오브젝트의 특성을 나열합니다. 출력에서는 오브젝트의 키와 값을 제공합니다.

사전 요구 사항

  • Ceph OSD 노드에 대한 루트 수준 액세스.
  • ceph-osd 데몬 중지.

절차

  1. 적절한 OSD가 다운되었는지 확인합니다. 

    [root@osd ~]# systemctl status ceph-osd@OSD_NUMBER

    예제

    [root@osd ~]# systemctl status ceph-osd@1

  2. 컨테이너화된 배포의 경우 bluestore 툴에 액세스하려면 다음 단계를 따르십시오.

    1. 클러스터에 noout 플래그를 설정합니다.

      예제

      [root@mon ~]# ceph osd set noout

    2. OSD 컨테이너를 호스팅하는 노드에 로그인합니다.

    3. /etc/systemd/system/ceph-osd@.service 장치 파일을 /root 디렉토리로 백업합니다.

      예제

      [root@osd ~]# cp /etc/systemd/system/ceph-osd@.service /root/ceph-osd@.service.backup

    4. /run/ceph-osd@OSD_ID.service-cid 파일을 /root 로 이동합니다.

      예제

      [root@osd ~]# mv /run/ceph-osd@0.service-cid /root

    5. /etc/systemd/system/ceph-osd@.service 장치 파일을 편집하고 podman 명령에 -it --entrypoint /bin/bash 옵션을 추가합니다.

      예제

      # Please do not change this file directly since it is managed by Ansible and will be overwritten
[Unit]
Description=Ceph OSD
After=network.target

[Service]
EnvironmentFile=-/etc/environment
ExecStartPre=-/usr/bin/rm -f /%t/%n-pid /%t/%n-cid
ExecStartPre=-/usr/bin/podman rm -f ceph-osd-%i
ExecStart=/usr/bin/podman run -it --entrypoint /bin/bash \
  -d --conmon-pidfile /%t/%n-pid --cidfile /%t/%n-cid \
  --rm \
  --net=host \
  --privileged=true \
  --pid=host \
  --ipc=host \
  --cpus=2 \
  -v /dev:/dev \
  -v /etc/localtime:/etc/localtime:ro \
  -v /var/lib/ceph:/var/lib/ceph:z \
  -v /etc/ceph:/etc/ceph:z \
  -v /var/run/ceph:/var/run/ceph:z \
  -v /var/run/udev/:/var/run/udev/ \
  -v /var/log/ceph:/var/log/ceph:z \
  -e OSD_BLUESTORE=1 -e OSD_FILESTORE=0 -e OSD_DMCRYPT=0 \
  -e CLUSTER=ceph \
  -v /run/lvm/:/run/lvm/ \
  -e CEPH_DAEMON=OSD_CEPH_VOLUME_ACTIVATE \
  -e CONTAINER_IMAGE=registry.redhat.io/rhceph/rhceph-4-rhel8:latest \
  -e OSD_ID=%i \
  -e DEBUG=stayalive \
  --name=ceph-osd-%i \
   \
  registry.redhat.io/rhceph/rhceph-4-rhel8:latest
ExecStop=-/usr/bin/sh -c "/usr/bin/podman rm -f `cat /%t/%n-cid`"
KillMode=none
Restart=always
RestartSec=10s
TimeoutStartSec=120
TimeoutStopSec=15
Type=forking
PIDFile=/%t/%n-pid

[Install]
WantedBy=multi-user.target

    6. systemd 관리자 구성을 다시 로드합니다.

      예제

      [root@osd ~]# systemctl daemon-reload

    7. OSD_ID 와 연결된 OSD 서비스를 다시 시작합니다.

      구문

      systemctl restart ceph-osd@OSD_ID.service

      OSD_ID 를 OSD의 ID로 바꿉니다.

      예제

      [root@osd ~]# systemctl restart ceph-osd@0.service

    8. OSD_ID 와 연결된 컨테이너에 로그인합니다.

      구문

      podman exec -it ceph-osd-OSD_ID /bin/bash

      예제

      [root@osd ~]# podman exec -it ceph-osd-0 /bin/bash

    9. osd fsid 를 가져오고 OSD를 활성화하여 OSD의 논리 볼륨(LV)을 마운트합니다.

      구문

      ceph-volume lvm list |grep -A15 "osd\.OSD_ID"|grep "osd fsid"
ceph-volume lvm activate --bluestore OSD_ID OSD_FSID

      예제

      [root@osd ~]# ceph-volume lvm list |grep -A15 "osd\.0"|grep "osd fsid"
              osd fsid                  087eee15-6561-40a3-8fe4-9583ba64a4ff
[root@osd ~]# ceph-volume lvm activate --bluestore 0 087eee15-6561-40a3-8fe4-9583ba64a4ff
Running command: /usr/bin/mount -t tmpfs tmpfs /var/lib/ceph/osd/ceph-0
Running command: /usr/bin/chown -R ceph:ceph /var/lib/ceph/osd/ceph-0
Running command: /usr/bin/ceph-bluestore-tool --cluster=ceph prime-osd-dir --dev /dev/ceph-41c69f8f-30e2-4685-9c5c-c605898c5537/osd-data-d073e8b3-0b89-4271-af5b-83045fd000dc --path /var/lib/ceph/osd/ceph-0 --no-mon-config
Running command: /usr/bin/ln -snf /dev/ceph-41c69f8f-30e2-4685-9c5c-c605898c5537/osd-data-d073e8b3-0b89-4271-af5b-83045fd000dc /var/lib/ceph/osd/ceph-0/block
Running command: /usr/bin/chown -h ceph:ceph /var/lib/ceph/osd/ceph-0/block
Running command: /usr/bin/chown -R ceph:ceph /dev/mapper/ceph--41c69f8f--30e2--4685--9c5c--c605898c5537-osd--data--d073e8b3--0b89--4271--af5b--83045fd000dc
Running command: /usr/bin/chown -R ceph:ceph /var/lib/ceph/osd/ceph-0
Running command: /usr/bin/systemctl enable ceph-volume@lvm-0-087eee15-6561-40a3-8fe4-9583ba64a4ff
 stderr: Created symlink /etc/systemd/system/multi-user.target.wants/ceph-volume@lvm-0-087eee15-6561-40a3-8fe4-9583ba64a4ff.service → /usr/lib/systemd/system/ceph-volume@.service.
Running command: /usr/bin/systemctl enable --runtime ceph-osd@0
 stderr: Created symlink /run/systemd/system/ceph-osd.target.wants/ceph osd@0.service → /usr/lib/systemd/system/ceph-osd@.service.
Running command: /usr/bin/systemctl start ceph-osd@0
 stderr: Running in chroot, ignoring request: start
--> ceph-volume lvm activate successful for osd ID: 0

  3. 오브젝트의 특성을 나열합니다. 

    ceph-objectstore-tool --data-path PATH_TO_OSD \
--pgid PG_ID OBJECT \
list-attrs

    예제

    [root@osd ~]# ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-0 \
--pgid 0.1c '{"oid":"zone_info.default","key":"","snapid":-2,"hash":235010478,"max":0,"pool":11,"namespace":""}' \
list-attrs

  4. 컨테이너화된 배포의 경우 변경 사항을 되돌리려면 다음 단계를 따르십시오.

    1. 컨테이너를 종료한 후 /root 디렉터리에서 /etc/systemd/system/ceph-osd@.service 장치 파일을 복사합니다.

      예제

      [root@osd ~]# cp /etc/systemd/system/ceph-osd@.service /root/ceph-osd@.service.modified
[root@osd ~]# cp /root/ceph-osd@.service.backup /etc/systemd/system/ceph-osd@.service

    2. systemd 관리자 구성을 다시 로드합니다.

      예제

      [root@osd ~]# systemctl daemon-reload

    3. /run/ceph-osd@OSD_ID.service-cid 파일을 /tmp 로 이동합니다.

      예제

      [root@osd ~]# mv /run/ceph-osd@0.service-cid /tmp

    4. OSD_ID 와 연결된 OSD 서비스를 다시 시작합니다.

      구문

      [root@osd ~]# systemctl restart ceph-osd@OSD_ID.service

      예제

      [root@osd ~]# systemctl restart ceph-osd@0.service

추가 리소스

10.4.8. 개체 속성 키 조작

ceph-objectstore-tool 유틸리티를 사용하여 오브젝트의 특성을 변경합니다. 오브젝트의 특성을 조작하려면 데이터 및 저널 경로, 배치 그룹 식별자(PG ID), 개체 및 개체 특성에 있는 키가 필요합니다.

사전 요구 사항

  • Ceph OSD 노드에 대한 루트 수준 액세스.
  • ceph-osd 데몬 중지.

절차

  1. 적절한 OSD가 다운되었는지 확인합니다. 

    [root@osd ~]# systemctl status ceph-osd@$OSD_NUMBER

    예제

    [root@osd ~]# systemctl status ceph-osd@1

  2. 컨테이너화된 배포의 경우 bluestore 툴에 액세스하려면 다음 단계를 따르십시오.

    1. 클러스터에 noout 플래그를 설정합니다.

      예제

      [root@mon ~]# ceph osd set noout

    2. OSD 컨테이너를 호스팅하는 노드에 로그인합니다.

    3. /etc/systemd/system/ceph-osd@.service 장치 파일을 /root 디렉토리로 백업합니다.

      예제

      [root@osd ~]# cp /etc/systemd/system/ceph-osd@.service /root/ceph-osd@.service.backup

    4. /run/ceph-osd@OSD_ID.service-cid 파일을 /root 로 이동합니다.

      예제

      [root@osd ~]# mv /run/ceph-osd@0.service-cid /root

    5. /etc/systemd/system/ceph-osd@.service 장치 파일을 편집하고 podman 명령에 -it --entrypoint /bin/bash 옵션을 추가합니다.

      예제

      # Please do not change this file directly since it is managed by Ansible and will be overwritten
[Unit]
Description=Ceph OSD
After=network.target

[Service]
EnvironmentFile=-/etc/environment
ExecStartPre=-/usr/bin/rm -f /%t/%n-pid /%t/%n-cid
ExecStartPre=-/usr/bin/podman rm -f ceph-osd-%i
ExecStart=/usr/bin/podman run -it --entrypoint /bin/bash \
  -d --conmon-pidfile /%t/%n-pid --cidfile /%t/%n-cid \
  --rm \
  --net=host \
  --privileged=true \
  --pid=host \
  --ipc=host \
  --cpus=2 \
  -v /dev:/dev \
  -v /etc/localtime:/etc/localtime:ro \
  -v /var/lib/ceph:/var/lib/ceph:z \
  -v /etc/ceph:/etc/ceph:z \
  -v /var/run/ceph:/var/run/ceph:z \
  -v /var/run/udev/:/var/run/udev/ \
  -v /var/log/ceph:/var/log/ceph:z \
  -e OSD_BLUESTORE=1 -e OSD_FILESTORE=0 -e OSD_DMCRYPT=0 \
  -e CLUSTER=ceph \
  -v /run/lvm/:/run/lvm/ \
  -e CEPH_DAEMON=OSD_CEPH_VOLUME_ACTIVATE \
  -e CONTAINER_IMAGE=registry.redhat.io/rhceph/rhceph-4-rhel8:latest \
  -e OSD_ID=%i \
  -e DEBUG=stayalive \
  --name=ceph-osd-%i \
   \
  registry.redhat.io/rhceph/rhceph-4-rhel8:latest
ExecStop=-/usr/bin/sh -c "/usr/bin/podman rm -f `cat /%t/%n-cid`"
KillMode=none
Restart=always
RestartSec=10s
TimeoutStartSec=120
TimeoutStopSec=15
Type=forking
PIDFile=/%t/%n-pid

[Install]
WantedBy=multi-user.target

    6. systemd 관리자 구성을 다시 로드합니다.

      예제

      [root@osd ~]# systemctl daemon-reload

    7. OSD_ID 와 연결된 OSD 서비스를 다시 시작합니다.

      구문

      systemctl restart ceph-osd@OSD_ID.service

      OSD_ID 를 OSD의 ID로 바꿉니다.

      예제

      [root@osd ~]# systemctl restart ceph-osd@0.service

    8. OSD_ID 와 연결된 컨테이너에 로그인합니다.

      구문

      podman exec -it ceph-osd-OSD_ID /bin/bash

      예제

      [root@osd ~]# podman exec -it ceph-osd-0 /bin/bash

    9. osd fsid 를 가져오고 OSD를 활성화하여 OSD의 논리 볼륨(LV)을 마운트합니다.

      구문

      ceph-volume lvm list |grep -A15 "osd\.OSD_ID"|grep "osd fsid"
ceph-volume lvm activate --bluestore OSD_ID OSD_FSID

      예제

      [root@osd ~]# ceph-volume lvm list |grep -A15 "osd\.0"|grep "osd fsid"
              osd fsid                  087eee15-6561-40a3-8fe4-9583ba64a4ff
[root@osd ~]# ceph-volume lvm activate --bluestore 0 087eee15-6561-40a3-8fe4-9583ba64a4ff
Running command: /usr/bin/mount -t tmpfs tmpfs /var/lib/ceph/osd/ceph-0
Running command: /usr/bin/chown -R ceph:ceph /var/lib/ceph/osd/ceph-0
Running command: /usr/bin/ceph-bluestore-tool --cluster=ceph prime-osd-dir --dev /dev/ceph-41c69f8f-30e2-4685-9c5c-c605898c5537/osd-data-d073e8b3-0b89-4271-af5b-83045fd000dc --path /var/lib/ceph/osd/ceph-0 --no-mon-config
Running command: /usr/bin/ln -snf /dev/ceph-41c69f8f-30e2-4685-9c5c-c605898c5537/osd-data-d073e8b3-0b89-4271-af5b-83045fd000dc /var/lib/ceph/osd/ceph-0/block
Running command: /usr/bin/chown -h ceph:ceph /var/lib/ceph/osd/ceph-0/block
Running command: /usr/bin/chown -R ceph:ceph /dev/mapper/ceph--41c69f8f--30e2--4685--9c5c--c605898c5537-osd--data--d073e8b3--0b89--4271--af5b--83045fd000dc
Running command: /usr/bin/chown -R ceph:ceph /var/lib/ceph/osd/ceph-0
Running command: /usr/bin/systemctl enable ceph-volume@lvm-0-087eee15-6561-40a3-8fe4-9583ba64a4ff
 stderr: Created symlink /etc/systemd/system/multi-user.target.wants/ceph-volume@lvm-0-087eee15-6561-40a3-8fe4-9583ba64a4ff.service → /usr/lib/systemd/system/ceph-volume@.service.
Running command: /usr/bin/systemctl enable --runtime ceph-osd@0
 stderr: Created symlink /run/systemd/system/ceph-osd.target.wants/ceph osd@0.service → /usr/lib/systemd/system/ceph-osd@.service.
Running command: /usr/bin/systemctl start ceph-osd@0
 stderr: Running in chroot, ignoring request: start
--> ceph-volume lvm activate successful for osd ID: 0

  3. 오브젝트의 특성을 가져옵니다.

    구문

    ceph-objectstore-tool --data-path PATH_TO_OSD \
--pgid PG_ID OBJECT \
get-attrs KEY > OBJECT_ATTRS_FILE_NAME

    예제

    [root@osd ~]# ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-0 \
--pgid 0.1c '{"oid":"zone_info.default","key":"","snapid":-2,"hash":235010478,"max":0,"pool":11,"namespace":""}' \
get-attrs "oid" > zone_info.default.attr.txt

  4. 오브젝트의 특성을 설정합니다.

    구문

    ceph-objectstore-tool --data-path PATH_TO_OSD \
--pgid PG_ID OBJECT \
set-attrs KEY < OBJECT_ATTRS_FILE_NAME

    예제

    [root@osd ~]# ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-0 \
--pgid 0.1c '{"oid":"zone_info.default","key":"","snapid":-2,"hash":235010478,"max":0,"pool":11,"namespace":""}' \
set-attrs "oid" < zone_info.default.attr.txt

  5. 오브젝트의 속성을 제거합니다.

    구문

    ceph-objectstore-tool --data-path PATH_TO_OSD \
--pgid PG_ID OBJECT  \
rm-attrs KEY

    예제

    [root@osd ~]# ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-0 \
--pgid 0.1c '{"oid":"zone_info.default","key":"","snapid":-2,"hash":235010478,"max":0,"pool":11,"namespace":""}' \
rm-attrs "oid"

  6. 컨테이너화된 배포의 경우 변경 사항을 되돌리려면 다음 단계를 따르십시오.

    1. 컨테이너를 종료한 후 /root 디렉터리에서 /etc/systemd/system/ceph-osd@.service 장치 파일을 복사합니다.

      예제

      [root@osd ~]# cp /etc/systemd/system/ceph-osd@.service /root/ceph-osd@.service.modified
[root@osd ~]# cp /root/ceph-osd@.service.backup /etc/systemd/system/ceph-osd@.service

    2. systemd 관리자 구성을 다시 로드합니다.

      예제

      [root@osd ~]# systemctl daemon-reload

    3. /run/ceph-osd@OSD_ID.service-cid 파일을 /tmp 로 이동합니다.

      예제

      [root@osd ~]# mv /run/ceph-osd@0.service-cid /tmp

    4. OSD_ID 와 연결된 OSD 서비스를 다시 시작합니다.

      구문

      [root@osd ~]# systemctl restart ceph-osd@OSD_ID.service

      예제

      [root@osd ~]# systemctl restart ceph-osd@0.service

추가 리소스

10.5. 추가 리소스

  • Red Hat Ceph Storage 지원은 Red Hat 고객 포털 을 참조하십시오.

11장. Red Hat 지원 문의

본 가이드의 정보가 문제 해결에 도움이 되지 않은 경우, 이 장에서는 Red Hat 지원 서비스에 문의하는 방법을 설명합니다.

11.1. 사전 요구 사항

  • Red Hat 지원 계정.

11.2. Red Hat 지원 엔지니어에게 정보 제공

Red Hat Ceph Storage와 관련된 문제를 해결할 수 없는 경우 Red Hat 지원 서비스에 문의하여 지원 엔지니어가 직면한 문제를 보다 신속하게 해결할 수 있는 충분한 양의 정보를 제공합니다.

사전 요구 사항

  • 노드에 대한 루트 수준 액세스.
  • Red Hat 지원 계정.

절차

  1. Red Hat 고객 포털에서 지원 티켓을 엽니다.
  2. 티켓에 sosreport 를 연결하는 것이 이상적입니다. 자세한 내용은 What is a sosreport and how to create one in Red Hat Enterprise Linux 4.6 이상에서 참조하십시오.
  3. 분할 오류로 Ceph 데몬이 실패하는 경우 사람이 읽을 수 있는 코어 덤프 파일을 생성하는 것이 좋습니다. 자세한 내용은 읽기 쉬운 코어 덤프 파일 생성 참조.

11.3. 읽을 수 있는 코어 덤프 파일 생성

Ceph 데몬이 분할 오류로 예기치 않게 종료되면 실패에 대한 정보를 수집하여 Red Hat 지원 엔지니어에게 제공합니다.

이러한 정보로 초기 조사 속도가 빨라집니다. 또한 지원 엔지니어는 코어 덤프 파일의 정보와 Red Hat Ceph Storage 클러스터의 알려진 문제를 비교할 수 있습니다.

11.3.1. 사전 요구 사항

  1. ceph-debuginfo 패키지가 아직 설치되지 않은 경우 설치합니다.

    1. ceph-debuginfo 패키지가 포함된 리포지토리를 활성화합니다.

      Red Hat Enterprise Linux 7:

      subscription-manager repos --enable=rhel-7-server-rhceph-4-DAEMON-debug-rpms

      Ceph 노드 유형에 따라 DAEMON 을 osd 또는 mon 로 바꿉니다.

      Red Hat Enterprise Linux 8:

      subscription-manager repos --enable=rhceph-4-tools-for-rhel-8-x86_64-debug-rpms

    2. ceph-debuginfo 패키지를 설치합니다. 

      [root@mon ~]# yum install ceph-debuginfo

  2. gdb 패키지가 설치되어 있고 그렇지 않은 경우 설치합니다. 

    [root@mon ~]# yum install gdb

배포 유형에 따라 절차를 계속합니다.

11.3.2. 베어 메탈 배포에서 읽을 수 있는 코어 덤프 파일 생성

베어 메탈에서 Red Hat Ceph Storage를 사용하는 경우 코어 덤프 파일을 생성하려면 다음 절차를 따르십시오.

절차

  1. Ceph의 코어 덤프 파일 생성을 활성화합니다.

    1. /etc/systemd/system.conf 파일에 다음 매개변수를 추가하여 코어 덤프 파일의 적절한 ulimits 를 설정합니다. 

      DefaultLimitCORE=infinity

    2. 기본적으로 /lib/systemd/system/CLUSTER_NAME-DAEMON@.service에 있는 Ceph 데몬 서비스 파일의 PrivateTmp=true 매개 변수를 주석 처리합니다. 

      [root@mon ~]# PrivateTmp=true

    3. Ceph 데몬이 덤프 코어 파일을 생성할 수 있도록 suid_dumpable 플래그를 2 로 설정합니다. 

      [root@mon ~]# sysctl fs.suid_dumpable=2

    4. 코어 덤프 파일 위치를 조정합니다. 

      [root@mon ~]# sysctl kernel.core_pattern=/tmp/core

    5. [Coredump] 섹션 아래에 다음 행을 추가하여 /etc/systemd/coredump.conf 파일을 수정합니다. 

      ProcessSizeMax=8G
ExternalSizeMax=8G
JournalSizeMax=8G

    6. 변경 사항을 적용하려면 systemd 서비스를 다시 로드합니다. 

      [root@mon ~]# systemctl daemon-reload

    7. 변경 사항을 적용하려면 Ceph 데몬을 다시 시작하십시오. 

      [root@mon ~]# systemctl restart ceph-DAEMON@ID

      데몬 유형(osd또는 mon) 및 ID(OSS의 수 또는 모니터의 호스트 이름)를 지정합니다. 예를 들면 다음과 같습니다. 

      [root@mon ~]# systemctl restart ceph-osd@1
  2. 실패를 재현합니다. 예를 들어 데몬을 다시 시작합니다.

  3. GDB(GNU Debugger)를 사용하여 애플리케이션 코어 덤프 파일에서 읽을 수 있는 역추적을 생성합니다. 

    gdb /usr/bin/ceph-DAEMON /tmp/core.PID

    데몬 유형 및 실패한 프로세스의 PID를 지정합니다. 예를 들면 다음과 같습니다. 

    $ gdb /usr/bin/ceph-osd /tmp/core.123456

    GDB 명령 프롬프트에서 페이징을 비활성화하고 명령에 set pag off 명령을 입력하고 로그를 설정하여 파일에 대한 로깅을 활성화합니다. 

    (gdb) set pag off
(gdb) set log on

    bt full 을 입력하여 프로세스의 모든 스레드에 backtrace 명령을 적용합니다. 

    (gdb) thr a a bt full

    backtrace가 생성된 후 set log off 를 입력하여 로깅을 해제합니다. 

    (gdb) set log off
  4. 로그 파일 gdb.txt 를 에서 Red Hat 고객 포털에 액세스하는 시스템으로 전송하여 지원 티켓에 연결합니다.

11.3.3. 컨테이너화된 배포에서 읽을 수 있는 코어 덤프 파일 생성

컨테이너에서 Red Hat Ceph Storage를 사용하는 경우 코어 덤프 파일을 생성하려면 다음 절차를 따르십시오. 절차에는 코어 덤프 파일을 캡처하는 두 가지 시나리오가 포함됩니다.

  • SIGILL, SIGTRAP, SIGABRT 또는 SIGSEGV 오류로 인해 Ceph 프로세스가 예기치 않게 종료되는 경우

또는

  • 예를 들어, Ceph 프로세스와 같은 문제를 디버깅하기 위해 수동으로 CPU 주기가 높거나 응답하지 않는 경우가 있습니다.

사전 요구 사항

  • Ceph 컨테이너를 실행하는 컨테이너 노드에 대한 루트 수준 액세스.
  • 적절한 디버깅 패키지 설치.
  • gdb(GNU Project Debugger) 패키지 설치.

절차

  1. SIGILL, SIGTRAP, SIGABRT 또는 SIGSEGV 오류로 인해 Ceph 프로세스가 예기치 않게 종료되는 경우:

    1. Ceph 프로세스가 실패한 컨테이너가 실행 중인 노드의 systemd-coredump 서비스로 코어 패턴을 설정합니다. 예를 들면 다음과 같습니다. 

      [root@mon]# echo "| /usr/lib/systemd/systemd-coredump %P %u %g %s %t %e" > /proc/sys/kernel/core_pattern

    2. Ceph 프로세스로 인해 다음 컨테이너 오류가 있는지 확인하고 /var/lib/systemd/coredump/ 디렉터리에서 코어 덤프 파일을 검색합니다. 예를 들면 다음과 같습니다. 

      [root@mon]# ls -ltr /var/lib/systemd/coredump
total 8232
-rw-r-----. 1 root root 8427548 Jan 22 19:24 core.ceph-osd.167.5ede29340b6c4fe4845147f847514c12.15622.1584573794000000.xz

  2. Ceph Monitors 및 Ceph Manager 에 대한 코어 덤프 파일을 수동으로 캡처하려면 다음을 수행합니다.

    1. 컨테이너에서 Ceph 데몬의 ceph-mon 패키지 세부 정보를 가져옵니다.

      Red Hat Enterprise Linux 7:

      [root@mon]# docker exec -it NAME /bin/bash
[root@mon]# rpm -qa | grep ceph

      Red Hat Enterprise Linux 8:

      [root@mon]# podman exec -it NAME /bin/bash
[root@mon]# rpm -qa | grep ceph

      NAME 을 Ceph 컨테이너의 이름으로 바꿉니다.

    2. 백업 복사본을 만들고 ceph-mon@.service 파일을 편집하기 위해 엽니다. 

      [root@mon]# cp /etc/systemd/system/ceph-mon@.service /etc/systemd/system/ceph-mon@.service.orig

    3. ceph-mon@.service 파일에서 [Service] 섹션에 이러한 세 가지 옵션을 각각 별도의 행에 추가합니다. 

      --pid=host \
--ipc=host \
--cap-add=SYS_PTRACE \

      예제

      [Unit]
Description=Ceph Monitor
After=docker.service

[Service]
EnvironmentFile=-/etc/environment
ExecStartPre=-/usr/bin/docker rm ceph-mon-%i
ExecStartPre=/bin/sh -c '"$(command -v mkdir)" -p /etc/ceph /var/lib/ceph/mon'
ExecStart=/usr/bin/docker run --rm --name ceph-mon-%i \
  --memory=924m \
--cpu-quota=100000 \
-v /var/lib/ceph:/var/lib/ceph:z \
  -v /etc/ceph:/etc/ceph:z \
  -v /var/run/ceph:/var/run/ceph:z \
-v /etc/localtime:/etc/localtime:ro \
--net=host \
--privileged=true \
--ipc=host \ 1
--pid=host \ 2
--cap-add=SYS_PTRACE \ 3
-e IP_VERSION=4 \
        -e MON_IP=10.74.131.17 \
      -e CLUSTER=ceph \
  -e FSID=9448efca-b1a1-45a3-bf7b-b55cba696a6e \
  -e CEPH_PUBLIC_NETWORK=10.74.131.0/24 \
  -e CEPH_DAEMON=MON \
   \
  registry.access.redhat.com/rhceph/rhceph-3-rhel7:latest
ExecStop=-/usr/bin/docker stop ceph-mon-%i
ExecStopPost=-/bin/rm -f /var/run/ceph/ceph-mon.pd-cephcontainer-mon01.asok
Restart=always
RestartSec=10s
TimeoutStartSec=120
TimeoutStopSec=15

[Install]
WantedBy=multi-user.target

    4. Ceph Monitor 데몬을 다시 시작합니다.

      구문

      systemctl restart ceph-mon@MONITOR_ID

      MONITOR_ID 를 Ceph Monitor의 ID 번호로 바꿉니다.

      예제

      [root@mon]# systemctl restart ceph-mon@1

    5. Ceph Monitor 컨테이너 내부에 gdb 패키지를 설치합니다.

      Red Hat Enterprise Linux 7:

      [root@mon]# docker exec -it ceph-mon-MONITOR_ID /bin/bash
sh $ yum install gdb

      Red Hat Enterprise Linux 8:

      [root@mon]# podman exec -it ceph-mon-MONITOR_ID /bin/bash
sh $ yum install gdb

      MONITOR_ID 를 Ceph Monitor의 ID 번호로 바꿉니다.

    6. 프로세스 ID를 찾습니다.

      구문

      ps -aef | grep PROCESS | grep -v run

      PROCESS 를 실패한 프로세스 이름으로 바꿉니다(예: ceph-mon ).

      예제

      [root@mon]# ps -aef | grep ceph-mon | grep -v run
ceph       15390   15266  0 18:54 ?        00:00:29 /usr/bin/ceph-mon --cluster ceph --setroot ceph --setgroup ceph -d -i 5
ceph       18110   17985  1 19:40 ?        00:00:08 /usr/bin/ceph-mon --cluster ceph --setroot ceph --setgroup ceph -d -i 2

    7. 코어 덤프 파일을 생성합니다.

      구문

      gcore ID

      ID 를 이전 단계에서 가져온 실패한 프로세스의 ID(예: 18110 )로 바꿉니다.

      예제

      [root@mon]# gcore 18110
warning: target file /proc/18110/cmdline contained unexpected null characters
Saved corefile core.18110

    8. 코어 덤프 파일이 올바르게 생성되었는지 확인합니다.

      예제

      [root@mon]# ls -ltr
total 709772
-rw-r--r--. 1 root root 726799544 Mar 18 19:46 core.18110

    9. Ceph Monitor 컨테이너 외부에 코어 덤프 파일을 복사합니다.

      Red Hat Enterprise Linux 7:

      [root@mon]# docker cp ceph-mon-MONITOR_ID:/tmp/mon.core.MONITOR_PID /tmp

      Red Hat Enterprise Linux 8:

      [root@mon]# podman cp ceph-mon-MONITOR_ID:/tmp/mon.core.MONITOR_PID /tmp

      MONITOR_ID 를 Ceph Monitor의 ID 번호로 바꾸고 MONITOR_PID 를 프로세스 ID 번호로 바꿉니다.

    10. ceph-mon@.service 파일의 백업 사본을 복원합니다. 

      [root@mon]# cp /etc/systemd/system/ceph-mon@.service.orig /etc/systemd/system/ceph-mon@.service

    11. Ceph Monitor 데몬을 다시 시작합니다.

      구문

      systemctl restart ceph-mon@MONITOR_ID

      MONITOR_ID 를 Ceph Monitor의 ID 번호로 바꿉니다.

      예제

      [root@mon]# systemctl restart ceph-mon@1

    12. Red Hat 지원에 의한 분석용 코어 덤프 파일을 업로드하고 4단계를 참조하십시오.

  3. Ceph OSD 의 코어 덤프 파일을 수동으로 캡처하려면 다음을 수행합니다.

    1. 컨테이너에서 Ceph 데몬의 ceph-osd 패키지 세부 정보를 가져옵니다.

      Red Hat Enterprise Linux 7:

      [root@osd]# docker exec -it NAME /bin/bash
[root@osd]# rpm -qa | grep ceph

      Red Hat Enterprise Linux 8:

      [root@osd]# podman exec -it NAME /bin/bash
[root@osd]# rpm -qa | grep ceph

      NAME 을 Ceph 컨테이너의 이름으로 바꿉니다.

    2. Ceph 컨테이너가 실행 중인 노드에 동일한 버전의 ceph-osd 패키지에 대한 Ceph 패키지를 설치합니다.

      Red Hat Enterprise Linux 7:

      [root@osd]# yum install ceph-osd

      Red Hat Enterprise Linux 8:

      [root@osd]# dnf install ceph-osd

      필요한 경우 먼저 적절한 리포지토리를 활성화합니다. 자세한 내용은 설치 가이드 의 Red Hat Ceph Storage 리포지토리 활성화 섹션을 참조하십시오.

    3. 오류가 발생한 프로세스의 ID를 찾습니다. 

      ps -aef | grep PROCESS | grep -v run

      PROCESS 를 실패한 프로세스의 이름으로 바꿉니다(예: ceph-osd ). 

      [root@osd]# ps -aef | grep ceph-osd | grep -v run
ceph       15390   15266  0 18:54 ?        00:00:29 /usr/bin/ceph-osd --cluster ceph --setroot ceph --setgroup ceph -d -i 5
ceph       18110   17985  1 19:40 ?        00:00:08 /usr/bin/ceph-osd --cluster ceph --setroot ceph --setgroup ceph -d -i 2

    4. 코어 덤프 파일을 생성합니다. 

      gcore ID

      ID 를 이전 단계에서 가져온 실패한 프로세스의 ID(예: 18110 )로 바꿉니다. 

      [root@osd]# gcore 18110
warning: target file /proc/18110/cmdline contained unexpected null characters
Saved corefile core.18110

    5. 코어 덤프 파일이 올바르게 생성되었는지 확인합니다. 

      [root@osd]# ls -ltr
total 709772
-rw-r--r--. 1 root root 726799544 Mar 18 19:46 core.18110
    6. Red Hat 지원으로 분석을 위해 코어 덤프 파일을 업로드하고 다음 단계를 참조하십시오.
  4. 분석을 위해 코어 덤프 파일을 Red Hat 지원 케이스에 업로드합니다. 자세한 내용은 Red Hat 지원 엔지니어에게 정보 제공.

11.3.4. 추가 리소스

부록 A. Ceph 하위 시스템 기본 로깅 수준 값

다양한 Ceph 하위 시스템에 대한 기본 로깅 수준 값의 테이블입니다.

하위 시스템로그 수준메모리 수준

asok

1

5

auth

1

5

버퍼

0

0

클라이언트

0

5

context

0

5

마케도니아

1

5

default

0

5

Filer

0

5

bluestore

1

5

종료자

1

5

heartbeatmap

1

5

javaclient

1

5

journaler

0

5

journal

1

5

lockdep

0

5

MDS 밸런서

1

5

MDS 종료

1

5

MDS 로그 만료

1

5

MDS 로그

1

5

MDS 마이그레이션기

1

5

mds

1

5

monc

0

5

Mon

1

5

ms

0

5

objclass

0

5

objectcacher

0

5

objecter

0

0

optracker

0

5

osd

0

5

paxos

0

5

perfcounter

1

5

rados

0

5

rbd

0

5

rgw

1

5

throttle

1

5

타이머

0

5

tp

0

5

법적 공지

Copyright © 2023 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.