운영 가이드

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) 등 네 가지 용어를 교체하고 있습니다. 이러한 변경 작업은 작업 범위가 크므로 향후 여러 릴리스에 걸쳐 점차 구현할 예정입니다. 자세한 내용은 Red Hat CTO Chris Wright의 메시지를 참조하십시오.

1장. 스토리지 클러스터 크기 관리

스토리지 관리자는 스토리지 용량이 확장되거나 축소될 때 Ceph 모니터 또는 OSD를 추가하거나 제거하여 스토리지 클러스터 크기를 관리할 수 있습니다. Ceph Ansible을 사용하거나 CLI(명령줄 인터페이스)를 사용하여 스토리지 클러스터 크기를 관리할 수 있습니다.

1.1. 사전 요구 사항

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

1.2. Ceph 모니터

Ceph 모니터는 스토리지 클러스터 맵의 마스터 복사본을 유지하는 경량 프로세스입니다. 모든 Ceph 클라이언트가 Ceph에 접속하여 스토리지 클러스터 맵의 현재 사본을 검색하여 클라이언트가 풀에 바인딩하고 데이터를 읽고 쓸 수 있습니다.

Ceph 모니터는 Paxos 프로토콜의 변형을 사용하여 맵과 스토리지 클러스터 전체의 기타 중요 정보에 대한 합의점을 구축합니다. Ceph는 Paxos의 특성으로 인해 쿼럼을 설정하기 위해 대부분의 모니터를 실행해야 하므로 합의점을 설정합니다.

중요

프로덕션 클러스터에 대한 지원을 받으려면 별도의 호스트에 3개 이상의 모니터가 필요합니다.

홀수의 모니터 배포를 권장합니다. 홀수의 Ceph 모니터는 심지어 모니터 수보다 실패 가능성이 높습니다. 예를 들어, 2개 모니터 배포에서 쿼럼을 유지 관리하기 위해 Ceph는 3개의 모니터, 1개의 모니터, 1개의 모니터, 5개의 모니터가 있는 2개의 오류를 허용할 수 없습니다. 따라서 홀수의 숫자를 사용하는 것이 좋습니다. Ceph에서는 대부분의 모니터가 실행되고 있고 서로 통신할 수 있어야 하며, 3개 중 2개, 4개 중 3개 등에서 통신할 수 있어야 합니다.

멀티 노드 Ceph 스토리지 클러스터의 초기 배포를 위해 Red Hat은 세 개 이상의 모니터가 있는 경우 한 번에 2개 이상의 모니터를 늘려야 합니다.

Ceph 모니터는 경량이므로 OpenStack 노드와 동일한 호스트에서 실행할 수 있습니다. 그러나 Red Hat은 별도의 호스트에서 모니터를 실행하는 것이 좋습니다.

중요

Red Hat은 동일한 노드에서 Ceph 모니터 및 OSD의 배치를 지원하지 않습니다. 이렇게 하면 스토리지 클러스터 성능에 부정적인 영향을 미칠 수 있습니다.

Red Hat은 컨테이너화된 환경에서 Ceph 서비스를 조합하여만 지원합니다.

스토리지 클러스터에서 모니터를 제거하면 Ceph 모니터가 Paxos 프로토콜을 사용하여 마스터 스토리지 클러스터 맵에 대한 합의점을 설정한다고 고려하십시오. 쿼럼을 설정하기 위해 충분한 수의 Ceph 모니터가 있어야 합니다.

추가 리소스

1.2.1. 새 Ceph Monitor 노드 준비

배포를 위해 새 Ceph 모니터 노드를 준비하기 전에 Red Hat Ceph Storage 설치 가이드의 Red Hat Ceph Storage 설치 요구 사항 장을 검토하십시오.

중요

각 새 Ceph Monitor를 별도의 노드에 배포하고 스토리지 클러스터의 모든 Ceph Monitor 노드는 동일한 하드웨어에서 실행해야 합니다.

사전 요구 사항

  • 네트워크 연결.
  • 새 노드에 대한 루트 수준의 액세스.

절차

  1. 새 노드를 서버 랙에 추가합니다.
  2. 새 노드를 네트워크에 연결합니다.

  3. 최신 버전의 Red Hat Enterprise Linux 7 또는 Red Hat Enterprise Linux 8을 설치합니다.

    1. Red Hat Enterprise Linux 7의 경우 ntp 를 설치하고 안정적인 시간 소스를 설정합니다. 

      [root@mon ~]# yum install ntp

    2. Red Hat Enterprise Linux 8의 경우 chrony 를 설치하고 안정적인 시간 소스를 구성합니다. 

      [root@mon ~]# dnf install chrony

  4. 방화벽을 사용하는 경우 TCP 포트 6789를 엽니다. 

    [root@mon ~]# firewall-cmd --zone=public --add-port=6789/tcp
[root@mon ~]# firewall-cmd --zone=public --add-port=6789/tcp --permanent

추가 리소스

1.2.2. Ansible을 사용하여 Ceph 모니터 추가

홀수의 모니터를 유지하기 위해 한 번에 두 개의 Ceph 모니터를 추가할 것을 권장합니다. 예를 들어 스토리지 클러스터에 3개의 Ceph 모니터가 있는 경우 모니터 수를 5개로 확장하는 것이 좋습니다.

사전 요구 사항

  • 새 노드에 대한 루트 수준의 액세스.
  • Ansible 관리 노드.
  • Ansible에서 배포한 실행 중인 Red Hat Ceph Storage 클러스터.

절차

  1. [mons] 섹션의 /etc/ansible/hosts Ansible 인벤토리 파일에 새 Ceph Monitor 노드를 추가합니다.

    예제

    [mons]
monitor01
monitor02
monitor03
NEW_MONITOR_NODE_NAME
NEW_MONITOR_NODE_NAME

  2. Ansible이 Ceph 노드에 연결할 수 있는지 확인합니다. 

    [root@admin ~]# ansible all -m ping

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

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

  4. 다음 단계 중 하나를 사용하여 Ceph Monitor를 추가할 수 있습니다.

    • 베어 메탈 및 컨테이너 배포 모두 infrastructure-playbook 을 실행합니다. 

      [root@admin ceph-ansible]# ansible-playbook -vvvv -i hosts infrastructure-playbooks/add-mon.yml

    • ansible 사용자로 사이트 플레이북 또는 site -container 플레이북을 실행합니다.

      • 베어 메탈 배포:

        예제

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

      • 컨테이너 배포:

        예제

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

        Ansible 플레이북이 실행을 완료하고 나면 새 Ceph Monitor 노드가 스토리지 클러스터에 표시됩니다.

  5. 구성 파일을 업데이트합니다.

    1. 베어 메탈 배포:

      예제

      [user@admin ceph-ansible]$ ansible-playbook -vvvv -i hosts site.yml --tags ceph_update_config

    2. 컨테이너 배포:

      예제

      [user@admin ceph-ansible]$ ansible-playbook -vvvv -i hosts site-container.yml --tags ceph_update_config

추가 리소스

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

홀수의 모니터를 유지하기 위해 한 번에 두 개의 Ceph 모니터를 추가할 것을 권장합니다. 예를 들어 스토리지 클러스터에 3개의 Ceph 모니터가 있는 경우 모니터 수를 5개로 확장하는 것이 좋습니다.

중요

노드당 하나의 Ceph Monitor 데몬만 실행하는 것이 좋습니다.

사전 요구 사항

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

절차

  1. Red Hat Ceph Storage 4 모니터 리포지토리를 추가합니다.

    Red Hat Enterprise Linux 7

    [root@mon ~]# subscription-manager repos --enable=rhel-7-server-rhceph-4-mon-rpms

    Red Hat Enterprise Linux 8

    [root@mon ~]# subscription-manager repos --enable=rhceph-4-mon-for-rhel-8-x86_64-rpms

  2. 새 Ceph Monitor 노드에 ceph-mon 패키지를 설치합니다.

    Red Hat Enterprise Linux 7

    [root@mon ~]# yum install ceph-mon

    Red Hat Enterprise Linux 8

    [root@mon ~]# dnf install ceph-mon

  3. 스토리지 클러스터에서 실행 중인 노드에서 Ceph 구성 파일의 [mon] 섹션에서 mon_host 설정 목록을 편집합니다.

    1. 새 Ceph Monitor 노드의 IP 주소를 mon_host 설정 목록에 추가합니다.

      구문

      [mon]
mon_host = MONITOR_IP : PORT MONITOR_IP : PORT ... NEW_MONITOR_IP : PORT

      새 Ceph 모니터의 IP 주소를 Ceph 구성 파일의 [mon] 섹션에 추가하는 대신 새 모니터 노드에 대해 파일에 특정 섹션을 생성할 수 있습니다.

      구문

      [mon.MONITOR_ID]
host = MONITOR_ID
mon_addr = MONITOR_IP

      참고

      mon_host 설정 목록은 DNS에서 확인할 수 있는 호스트 이름 또는 IP 주소 목록입니다. "" 또는 ";" 또는 "". 이 목록을 사용하면 스토리지 클러스터가 시작 또는 재시작 중에 새 Monitor 노드를 확인할 수 있습니다.

      중요

      mon_initial_members 설정은 Ceph Monitor 노드의 초기 쿼럼 그룹을 나열합니다. 해당 그룹의 한 멤버가 실패하면 해당 그룹의 다른 노드가 초기 모니터 노드가 됩니다. 프로덕션 스토리지 클러스터의 고가용성을 보장하기 위해 Ceph 구성 파일의 mon_initial_members 및 mon_ host 섹션에 3개 이상의 모니터 노드를 나열합니다. 이렇게 하면 초기 모니터 노드가 실패하면 스토리지 클러스터가 잠기지 않습니다. 추가하는 모니터 노드는 mon_initial_members 및 mon_ host 의 일부인 모니터를 대체하는 경우 두 섹션에 새 모니터를 추가합니다.

  4. 모니터가 초기 쿼럼 그룹의 일부를 만들려면 Ceph 구성 파일의 [global] 섹션에 있는 mon_initial_members 매개 변수에 호스트 이름을 추가합니다.

    예제

    [global]
mon_initial_members = node1 node2 node3 node4 node5
...
[mon]
mon_host = 192.168.0.1:6789 192.168.0.2:6789 192.168.0.3:6789 192.168.0.4:6789 192.168.0.5:6789
...
[mon.node4]
host = node4
mon_addr = 192.168.0.4

[mon.node5]
host = node5
mon_addr = 192.168.0.5

  5. 업데이트된 Ceph 구성 파일을 모든 Ceph 노드 및 Ceph 클라이언트에 복사합니다.

    구문

    scp /etc/ceph/CLUSTER_NAME.conf TARGET_NODE_NAME:/etc/ceph

    예제

    [root@mon ~]# scp /etc/ceph/ceph.conf node4:/etc/ceph

  6. 새 모니터 노드에 모니터의 데이터 디렉터리를 생성합니다.

    구문

    mkdir /var/lib/ceph/mon/CLUSTER_NAME - MONITOR_ID

    예제

    [root@mon ~]# mkdir /var/lib/ceph/mon/ceph-node4

  7. 실행 중인 Ceph Monitor 노드와 새 모니터 노드에 임시 디렉터리를 생성하고 해당 디렉터리에서 이 프로세스에 필요한 파일을 유지합니다. 각 노드의 임시 디렉터리는 노드의 기본 디렉터리와 달라야 합니다. 모든 단계가 완료된 후 제거할 수 있습니다.

    구문

    mkdir TEMP_DIRECTORY_PATH_NAME

    예제

    [root@mon ~]# mkdir /tmp/ceph

  8. ceph 명령을 실행할 수 있도록 실행 중인 Ceph Monitor 노드에서 새 Ceph Monitor 노드로 관리 키를 복사합니다.

    구문

    scp /etc/ceph/CLUSTER_NAME.client.admin.keyring TARGET_NODE_NAME:/etc/ceph

    예제

    [root@mon ~]# scp /etc/ceph/ceph.client.admin.keyring node4:/etc/ceph

  9. 실행 중인 Ceph Monitor 노드에서 monitor 인증 키를 검색합니다.

    구문

    ceph auth get mon. -o TEMP_DIRECTORY_PATH_NAME/KEY_FILE_NAME

    예제

    [root@mon ~]# ceph auth get mon. -o /tmp/ceph/ceph_keyring.out

  10. 실행 중인 Ceph Monitor 노드에서 모니터 맵을 검색합니다.

    구문

    ceph mon getmap -o TEMP_DIRECTORY_PATH_NAME/MONITOR_MAP_FILE

    예제

    [root@mon ~]# ceph mon getmap -o /tmp/ceph/ceph_mon_map.out

  11. 수집된 Ceph Monitor 데이터를 새 Ceph Monitor 노드에 복사합니다.

    구문

    scp /tmp/ceph TARGET_NODE_NAME:/tmp/ceph

    예제

    [root@mon ~]# scp /tmp/ceph node4:/tmp/ceph

  12. 이전에 수집한 데이터에서 새 모니터를 위해 데이터 디렉터리를 준비합니다. 모니터에서 쿼럼 정보를 검색하는 모니터의 경로를 'fsid's와 함께 지정합니다. 모니터 인증 키의 경로를 지정합니다.

    구문

    ceph-mon -i MONITOR_ID --mkfs --monmap TEMP_DIRECTORY_PATH_NAME/MONITOR_MAP_FILE --keyring TEMP_DIRECTORY_PATH_NAME/KEY_FILE_NAME

    예제

    [root@mon ~]# ceph-mon -i node4 --mkfs --monmap /tmp/ceph/ceph_mon_map.out --keyring /tmp/ceph/ceph_keyring.out

  13. 사용자 지정 이름이 있는 스토리지 클러스터의 경우 /etc/sysconfig/ceph 파일에 다음 행을 추가합니다.

    구문

    echo "CLUSTER=CUSTOM_CLUSTER_NAME" >> /etc/sysconfig/ceph

    예제

    [root@mon ~]# echo "CLUSTER=example" >> /etc/sysconfig/ceph

  14. 새 모니터 노드에서 소유자 및 그룹 권한을 업데이트합니다.

    구문

    chown -R OWNER : GROUP DIRECTORY_PATH

    예제

    [root@mon ~]# chown -R ceph:ceph /var/lib/ceph/mon
[root@mon ~]# chown -R ceph:ceph /var/log/ceph
[root@mon ~]# chown -R ceph:ceph /var/run/ceph
[root@mon ~]# chown -R ceph:ceph /etc/ceph

  15. 새 모니터 노드에서 ceph-mon 프로세스를 활성화하고 시작합니다.

    구문

    systemctl enable ceph-mon.target
systemctl enable ceph-mon@MONITOR_ID
systemctl start ceph-mon@MONITOR_ID

    예제

    [root@mon ~]# systemctl enable ceph-mon.target
[root@mon ~]# systemctl enable ceph-mon@node4
[root@mon ~]# systemctl start ceph-mon@node4

추가 리소스

1.2.4. 모니터 선택 전략 구성

모니터 선택 전략은 순 분할을 식별하고 오류를 처리합니다. 선택 모니터 전략을 세 가지 모드로 구성할 수 있습니다.

  1. Classic - 가장 낮은 순위의 모니터가 두 사이트 간의 투표 모듈에 따라 투표되는 기본 모드입니다.
  2. Disallow - 이 모드를 사용하면 모니터를 허용하지 않은 것으로 표시할 수 있습니다. 이 경우 쿼럼에 참여하고 클라이언트에 서비스를 제공하지만 선택한 리더가 될 수는 없습니다. 이를 통해 허용하지 않은 리더 목록에 모니터를 추가할 수 있습니다. 모니터가 비활성화 목록에 있으면 항상 다른 모니터로 지연됩니다.
  3. 연결 - 이 모드는 주로 네트워크 불일치를 해결하는 데 사용됩니다. 각 모니터에서 피어에 대해 제공되는 연결 점수를 평가하고 가장 연결되고 신뢰할 수 있는 모니터를 리더로 선택합니다. 이 모드는 순 분할을 처리하도록 설계되었으므로 클러스터가 여러 데이터 센터로 확장되거나 취약성이 발생할 수 있습니다. 이 모드에서는 연결 점수 등급을 통합하고 가장 좋은 점수로 모니터를 선택합니다.

다른 모드의 기능이 필요하지 않은 한, 기존의 모드를 유지할 것을 권장합니다.

클러스터를 구성하기 전에 다음 명령에서 election_strategy 를 classic , disallow 또는 connectivity 로 변경합니다.

구문

ceph mon set election_strategy {classic|disallow|connectivity}

1.2.5. Ansible을 사용하여 Ceph 모니터 제거

Ansible을 사용하여 Ceph 모니터를 제거하려면 shrink-mon.yml 플레이북을 사용합니다.

사전 요구 사항

  • Ansible 관리 노드.
  • Ansible에서 배포한 실행 중인 Red Hat Ceph Storage 클러스터.

절차

  1. 모니터가 ok-to-stop 인지 확인합니다.

    구문

    ceph mon ok-to-stop MONITOR_ID

    예제

    [root@mon ~]# ceph mon ok-to-stop node03

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

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

  3. 베어 메탈 및 컨테이너 배포의 경우 shrink-mon.yml Ansible 플레이북을 실행합니다.

    구문

    ansible-playbook infrastructure-playbooks/shrink-mon.yml -e mon_to_kill=NODE_NAME -u ANSIBLE_USER_NAME -i hosts

    교체:

    • Ceph Monitor 노드의 짧은 호스트 이름이 있는 NODE_NAME. 플레이북이 실행될 때마다 하나의 Ceph 모니터만 제거할 수 있습니다.
    • Ansible 사용자의 이름이 있는 ANSIBLE_USER_NAME

    예제

    [user@admin ceph-ansible]$ ansible-playbook infrastructure-playbooks/shrink-mon.yml -e mon_to_kill=node03 -u user -i hosts

  4. ansible 인벤토리 호스트 /etc/ansible/hosts 에서 해당 항목을 수동으로 제거합니다.

  5. ceph-ansible 플레이북을 실행합니다.

    1. 베어 메탈 배포:

      예제

      [user@admin ceph-ansible]$ ansible-playbook site.yml --tags ceph_update_config -i hosts

    2. 컨테이너 배포:

      예제

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

  6. Ceph 모니터가 성공적으로 제거되었는지 확인합니다. 

    [root@mon ~]# ceph -s

추가 리소스

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

Ceph 모니터를 제거하려면 스토리지 클러스터에서 ceph-mon 데몬을 제거하고 스토리지 클러스터 맵을 업데이트해야 합니다.

사전 요구 사항

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

절차

  1. 모니터가 ok-to-stop 인지 확인합니다.

    구문

    ceph mon ok-to-stop HOSTNAME

    예제

    [root@mon ~]# ceph mon ok-to-stop node03

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

    구문

    systemctl stop ceph-mon@MONITOR_ID

    예제

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

  3. 스토리지 클러스터에서 Ceph Monitor를 제거합니다.

    구문

    ceph mon remove MONITOR_ID

    예제

    [root@mon ~]# ceph mon remove node3

  4. Ceph 구성 파일에서 Ceph Monitor 항목을 제거합니다. 구성 파일의 기본 위치는 /etc/ceph/ceph.conf 입니다.

  5. 스토리지 클러스터의 나머지 모든 Ceph 노드에 Ceph 구성 파일을 재배포합니다.

    구문

    scp /etc/ceph/CLUSTER_NAME.conf USER_NAME @ TARGET_NODE_NAME :/etc/ceph/

    예제

    [root@mon ~]# scp /etc/ceph/ceph.conf root@node3:/etc/ceph/

  6. 컨테이너 배포의 경우 Ceph Monitor 서비스를 비활성화하고 제거합니다.

    1. Ceph Monitor 서비스를 비활성화합니다.

      구문

      systemctl disable ceph-mon@MONITOR_ID

      예제

      [root@mon ~]# systemctl disable ceph-mon@node3

    2. systemd 에서 서비스 제거: 

      [root@mon ~]# rm /etc/systemd/system/ceph-mon@.service

    3. systemd 관리자 구성을 다시 로드합니다. 

      [root@mon ~]# systemctl daemon-reload

    4. 실패한 Ceph 모니터 노드의 상태를 재설정합니다. 

      [root@mon ~]# systemctl reset-failed

  7. 선택 사항: Ceph Monitor 데이터를 아카이브합니다.

    구문

    mv /var/lib/ceph/mon/CLUSTER_NAME - MONITOR_ID /var/lib/ceph/mon/removed- CLUSTER_NAME - MONITOR_ID

    예제

    [root@mon ~]# mv /var/lib/ceph/mon/ceph-node3 /var/lib/ceph/mon/removed-ceph-node3

  8. 선택 사항: Ceph Monitor 데이터를 삭제합니다.

    구문

    rm -r /var/lib/ceph/mon/CLUSTER_NAME - MONITOR_ID

    예제

    [root@mon ~]# rm -r /var/lib/ceph/mon/ceph-node3

1.2.7. 비정상적인 스토리지 클러스터에서 Ceph 모니터 제거

배치 그룹이 활성 + clean 상태가 아닌 비정상 스토리지 클러스터에서 ceph-mon 데몬을 제거할 수 있습니다.

사전 요구 사항

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

절차

  1. 남아 있는 Ceph Monitor 노드에 로그인합니다.

    구문

    ssh root@MONITOR_NODE_NAME

    예제

    [root@admin ~]# ssh root@mon2

  2. ceph-mon 데몬을 중지하고 monmap 파일의 사본을 추출합니다. :

    구문

    systemctl stop ceph-mon@MONITOR_ID
ceph-mon -i SHORT_HOSTNAME --extract-monmap TEMP_PATH

    예제

    [root@mon2 ~]# systemctl stop ceph-mon@mon1
[root@mon2 ~]# ceph-mon -i mon1 --extract-monmap /tmp/monmap

  3. 남아 있지 않은 Ceph 모니터 제거:

    구문

    monmaptool TEMPORARY_PATH --rm _MONITOR_ID

    예제

    [root@mon2 ~]# monmaptool /tmp/monmap --rm mon1

  4. 제거된 모니터가 있는 급증 모니터 맵을 Ceph 모니터에 삽입합니다.

    구문

    ceph-mon -i SHORT_HOSTNAME --inject-monmap TEMP_PATH

    예제

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

  5. 생존 모니터만 시작하고, 모니터가 쿼럼을 형성하는지 확인합니다.

    예제

    [root@mon2 ~]# ceph -s

  6. 선택 사항: 삭제된 Ceph Monitor의 데이터 디렉터리를 /var/lib/ceph/mon 디렉터리에 보관합니다.

1.3. Ceph Manager

Ceph Manager 데몬(ceph-mgr)은 데몬과 함께 실행되어 외부 모니터링 및 관리 시스템에 추가 모니터링 및 인터페이스를 제공합니다. 일반 작업을 수행하려면 ceph-mgr 데몬이 필요합니다. 기본적으로 Ceph Manager 데몬에는 실행 중인 것 외에 추가 구성이 필요하지 않습니다. mgr 데몬이 실행되지 않으면 해당 효과에 대한 상태 경고가 표시되고 Ceph Manager가 시작될 때까지 ceph status 의 출력에 있는 일부 정보는 누락되거나 부실됩니다.

1.3.1. Ansible을 사용하여 Ceph Manager 추가

일반적으로 Ansible 자동화 유틸리티는 Red Hat Ceph Storage 클러스터를 배포할 때 Ceph Manager 데몬(ceph-mgr)을 설치합니다. Ceph Manager 서비스 또는 데몬이 다운되면 Ansible을 사용하여 ceph-mgr 데몬을 재배포할 수 있습니다. manager 데몬을 제거하고 새 노드 또는 기존 노드를 추가하여 Ceph Manager 데몬을 배포할 수 있습니다. Red Hat은 동일한 노드에서 Ceph Manager 및 Ceph Monitor 데몬을 배치하는 것이 좋습니다.

사전 요구 사항

  • Ansible에서 배포한 실행 중인 Red Hat Ceph Storage 클러스터.
  • Ansible 관리 노드에 대한 root 또는 sudo 액세스.
  • Ceph Manager 데몬을 배포할 새 노드 또는 기존 노드

절차

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

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

    예제

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

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

    구문

    [mgrs]
CEPH_MANAGER_NODE_NAME
CEPH_MANAGER_NODE_NAME

    CEPH_MANAGER_NODE_NAME 을 Ceph Manager 데몬을 설치하려는 노드의 호스트 이름으로 교체합니다.

  4. ansible 사용자로 Ansible 플레이북을 실행합니다.

    • 베어 메탈 배포: 

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

    • 컨테이너 배포: 

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

      Ansible 플레이북 실행을 완료하면 새 Ceph Manager 데몬 노드가 스토리지 클러스터에 표시됩니다.

검증

  • 모니터 노드에서 스토리지 클러스터의 상태를 확인합니다.

    구문

    ceph -s

    예제

    [root@ceph-2 ~]# ceph -s

mgr: ceph-3(active, since 2h), standbys: ceph-1, ceph-2

추가 리소스

1.3.2. Ansible을 사용하여 Ceph Manager 제거

shrink-mgr 플레이북을 사용하여 Ceph Manager 데몬을 제거할 수 있습니다. 이 플레이북은 클러스터에서 Ceph 관리자를 제거합니다.

사전 요구 사항

  • Ansible에서 배포한 실행 중인 Red Hat Ceph Storage 클러스터.
  • Ansible 관리 노드에 대한 root 또는 sudo 액세스.
  • Ansible 관리 노드에 대한 관리자 액세스.

절차

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

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

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

  3. 베어 메탈 및 컨테이너 배포의 경우 shrink-mgr.yml Ansible 플레이북을 실행합니다.

    구문

    ansible-playbook infrastructure-playbooks/shrink-mgr.yml -e mgr_to_kill=NODE_NAME -u ANSIBLE_USER_NAME -i hosts

    교체:

    • Ceph Manager 노드의 짧은 호스트 이름이 있는 NODE_NAME. 플레이북이 실행될 때마다 하나의 Ceph Manager만 제거할 수 있습니다.
    • Ansible 사용자의 이름이 있는 ANSIBLE_USER_NAME

    예제

    [admin@admin ceph-ansible]$ ansible-playbook infrastructure-playbooks/shrink-mgr.yml -e mgr_to_kill=ceph-2 -u admin -i hosts

  4. 루트 사용자로 /usr/share/ceph-ansible/hosts 인벤토리 파일을 편집하고 [mgrs] 섹션에서 Ceph Manager 노드를 삭제합니다.

    구문

    [mgrs]
CEPH_MANAGER_NODE_NAME
CEPH_MANAGER_NODE_NAME

    예제

    [mgrs]
ceph-1
ceph-3

    이 예에서 ceph-2 는 [mgrs] 목록에서 제거되었습니다.

검증

  • 모니터 노드에서 스토리지 클러스터의 상태를 확인합니다.

    구문

    ceph -s

    예제

    [root@ceph-2 ~]# ceph -s

mgr: ceph-3(active, since 112s), standbys: ceph-1

추가 리소스

1.4. Ceph MDSs

Ceph Metadata Server(MDS) 노드는 Ceph File System(CephFS)에 저장된 파일과 관련된 메타데이터를 관리하는 MDS 데몬(ceph-mds)을 실행합니다. MDS는 소유권, 타임스탬프, 모드를 포함하여 POSIX 호환 공유 파일 시스템 메타데이터 관리를 제공합니다. MDS는 RADOS(Reliable Autonomic Distributed Object Storage)를 사용하여 메타데이터를 저장합니다.

MDS를 사용하면 CephFS가 Ceph Object Store와 상호 작용하고 inode를 오브젝트에 매핑하고 Ceph가 트리 내에서 데이터를 저장하는 위치를 매핑할 수 있습니다. CephFS 파일 시스템에 액세스하는 클라이언트는 먼저 올바른 OSD에서 파일 내용을 가져오는 데 필요한 정보를 제공하는 MDS에 요청합니다.

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

추가 리소스

1.4.2. 명령줄 인터페이스를 사용하여 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

추가 리소스

1.4.3. 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]]

추가 리소스

1.4.4. 명령줄 인터페이스를 사용하여 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]]

추가 리소스

1.5. Ceph OSD

Red Hat Ceph Storage 클러스터가 가동되어 실행되면 런타임 시 스토리지 클러스터에 OSD를 추가할 수 있습니다.

Ceph OSD는 일반적으로 스토리지 드라이브 1대와 노드 내에서 연결된 저널을 위한 하나의 ceph-osd 데몬으로 구성됩니다. 노드에 여러 스토리지 드라이브가 있는 경우 각 드라이브에 대해 하나의 ceph-osd 데몬을 매핑합니다.

스토리지 용량의 상위에 도달하고 있는지 확인하기 위해 클러스터의 용량을 정기적으로 확인하는 것이 좋습니다. 스토리지 클러스터가 전체 비율에 도달하므로 하나 이상의 OSD를 추가하여 스토리지 클러스터의 용량을 확장합니다.

Red Hat Ceph Storage 클러스터의 크기를 줄이거나 하드웨어를 교체하려는 경우 런타임 시 OSD를 제거할 수도 있습니다. 노드에 스토리지 드라이브가 여러 개 있는 경우 해당 드라이브의 ceph-osd 데몬 중 하나를 제거해야 할 수도 있습니다. 일반적으로 스토리지 클러스터의 용량을 확인하여 용량의 상단에 도달했는지 확인하는 것이 좋습니다. 스토리지 클러스터가 거의 전체 비율에 있지 않은 OSD를 제거해야 합니다.

중요

OSD를 추가하기 전에 스토리지 클러스터가 전체 비율에 도달할 수 없도록 하십시오. 스토리지 클러스터가 거의 전체 비율에 도달한 후 발생하는 OSD 오류는 스토리지 클러스터가 전체 비율을 초과할 수 있습니다 . Ceph는 스토리지 용량 문제를 해결할 때까지 데이터를 보호하기 위한 쓰기 액세스를 차단합니다. 먼저 전체 비율에 미치는 영향을 고려하지 않고 OSD를 제거하지 마십시오.

1.5.1. Ceph OSD 노드 구성

OSD를 사용할 풀의 스토리지 전략으로 Ceph OSD와 지원 하드웨어를 유사하게 구성합니다. Ceph에서는 일관된 성능 프로필을 위해 풀 간에 균일한 하드웨어를 선호합니다. 최상의 성능을 위해 동일한 유형 또는 크기의 드라이브가 있는 CRUSH 계층 구조를 고려하십시오.

상이한 크기의 드라이브를 추가하는 경우 그에 따라 가중치를 조정합니다. OSD를 CRUSH 맵에 추가할 때 새 OSD의 가중치를 고려합니다. 하드 드라이브 용량은 연간 약 40% 증가하므로 최신 OSD 노드는 스토리지 클러스터의 이전 노드보다 더 큰 하드 드라이브를 사용할 수 있습니다. 즉, 가중치가 더 클 수 있습니다.

새 설치를 수행하기 전에 설치 가이드 의 Red Hat Ceph Storage 설치 요구 사항 장을 검토하십시오.

추가 리소스

1.5.2. 컨테이너 OSD ID를 드라이브에 매핑

경우에 따라 컨테이너화된 OSD가 사용 중인 드라이브를 식별해야 합니다. 예를 들어 OSD에 문제가 있는 경우 드라이브 상태를 확인하는 데 사용하는 드라이브를 알아야 할 수 있습니다. 또한 컨테이너화되지 않은 OSD의 경우 OSD ID를 참조하여 시작하여 중지하지만, 컨테이너화된 OSD를 시작하고 중지하려면 사용하는 드라이브를 참조합니다.

중요

아래 예제는 Red Hat Enterprise Linux 8에서 실행 중입니다. Red Hat Enterprise Linux 8에서 podman 은 기본 서비스이며 이전 Docker 서비스를 대체합니다. Red Hat Enterprise Linux 7에서 실행 중인 경우 podman 을 docker 로 대체하여 제공된 명령을 실행합니다.

사전 요구 사항

  • 컨테이너화된 환경에서 실행 중인 Red Hat Ceph Storage 클러스터.
  • 컨테이너 노드에 대한 루트 액세스 권한 보유.

절차

  1. 컨테이너 이름을 찾습니다. 예를 들어 osd.5와 연결된 드라이브를 식별하려면 osd.5 가 실행 중인 컨테이너 노드에서 터미널을 연 다음 podman ps 를 실행하여 모든 컨테이너를 나열합니다.

    예제

    [root@ceph3 ~]# podman ps
CONTAINER ID        IMAGE                                                     COMMAND             CREATED             STATUS              PORTS               NAMES
3a866f927b74        registry.redhat.io/rhceph/rhceph-4-rhel8:latest   "/entrypoint.sh"    About an hour ago   Up About an hour                        ceph-osd-ceph3-sdd
4e242d932c32        registry.redhat.io/rhceph/rhceph-4-rhel8:latest   "/entrypoint.sh"    About an hour ago   Up About an hour                        ceph-osd-ceph3-sdc
91f3d4829079        registry.redhat.io/rhceph/rhceph-4-rhel8:latest   "/entrypoint.sh"    22 hours ago        Up 22 hours                             ceph-osd-ceph3-sdb
73dfe4021a49        registry.redhat.io/rhceph/rhceph-4-rhel8:latest   "/entrypoint.sh"    7 days ago          Up 7 days                               ceph-osd-ceph3-sdf
90f6d756af39        registry.redhat.io/rhceph/rhceph-4-rhel8:latest   "/entrypoint.sh"    7 days ago          Up 7 days                               ceph-osd-ceph3-sde
e66d6e33b306        registry.redhat.io/rhceph/rhceph-4-rhel8:latest   "/entrypoint.sh"    7 days ago          Up 7 days                               ceph-mgr-ceph3
733f37aafd23        registry.redhat.io/rhceph/rhceph-4-rhel8:latest   "/entrypoint.sh"    7 days ago          Up 7 days                               ceph-mon-ceph3

  2. podman exec 을 사용하여 이전 출력의 OSD 컨테이너 이름에서 ceph-volume lvm 목록을 실행합니다.

    예제

    [root@ceph3 ~]# podman exec ceph-osd-ceph3-sdb ceph-volume lvm list

====== osd.5 =======

  [journal]    /dev/journals/journal1

      journal uuid              C65n7d-B1gy-cqX3-vZKY-ZoE0-IEYM-HnIJzs
      osd id                    1
      cluster fsid              ce454d91-d748-4751-a318-ff7f7aa18ffd
      type                      journal
      osd fsid                  661b24f8-e062-482b-8110-826ffe7f13fa
      data uuid                 SlEgHe-jX1H-QBQk-Sce0-RUls-8KlY-g8HgcZ
      journal device            /dev/journals/journal1
      data device               /dev/test_group/data-lv2
      devices                   /dev/sda

  [data]    /dev/test_group/data-lv2

      journal uuid              C65n7d-B1gy-cqX3-vZKY-ZoE0-IEYM-HnIJzs
      osd id                    1
      cluster fsid              ce454d91-d748-4751-a318-ff7f7aa18ffd
      type                      data
      osd fsid                  661b24f8-e062-482b-8110-826ffe7f13fa
      data uuid                 SlEgHe-jX1H-QBQk-Sce0-RUls-8KlY-g8HgcZ
      journal device            /dev/journals/journal1
      data device               /dev/test_group/data-lv2
      devices                   /dev/sdb

    이 출력에서 osd.5 가 /dev/sdb 와 연결되어 있음을 확인할 수 있습니다.

추가 리소스

1.5.3. 동일한 디스크 토폴로지가 있는 Ansible을 사용하여 Ceph OSD 추가

디스크 토폴로지가 동일한 Ceph OSD의 경우 Ansible은 /usr/share/ceph-ansible/group_vars/osds.yml 파일의 devices: 섹션에 지정된 동일한 장치 경로를 사용하여 다른 OSD 노드와 동일한 개수의 OSD를 추가합니다.

참고

새로운 Ceph OSD 노드는 나머지 OSD와 동일한 구성을 갖습니다.

사전 요구 사항

  • 실행 중인 Red Hat Ceph Storage 클러스터.
  • Red Hat Ceph Storage 설치 가이드의 Red Hat Ceph Storage 설치 요구 사항 장을 검토하십시오.
  • 새 노드에 대한 루트 액세스 권한 보유.
  • 스토리지 클러스터의 다른 OSD 노드와 동일한 OSD 데이터 드라이브 수입니다.

절차

  1. Ceph OSD 노드를 [osds] 섹션 아래의 /etc/ansible/hosts 파일에 추가합니다.

    구문

    [osds]
...
osd06
NEW_OSD_NODE_NAME

  2. Ansible이 Ceph 노드에 연결할 수 있는지 확인합니다. 

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

  3. Ansible 구성 디렉터리로 이동합니다. 

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

  4. 베어 메탈 및 컨테이너 배포의 경우 add-osd.yml Ansible 플레이북을 실행합니다.

    참고

    새 OSD 호스트의 경우 --limit 옵션을 사용하여 site.yml 또는 site-container.yml 플레이북을 실행해야 합니다. node-exporter 및 ceph-crash 서비스는 osds.yml 플레이북이 있는 노드에 배포되지 않습니다.

    예제

    [user@admin ceph-ansible]$ ansible-playbook infrastructure-playbooks/add-osd.yml -i hosts

    새 OSD 호스트의 경우 site.yml 또는 site-container.yml Ansible 플레이북을 실행합니다.

    • 베어 메탈 배포:

      구문

      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

참고

OSD를 추가할 때 Placement s와 함께 플레이북이 active+clean으로 보고되지 않은 경우 all.yml 파일에서 다음 변수를 구성하여 재시도 및 지연을 조정합니다. 

# OSD handler checks
handler_health_osd_check_retries: 50
handler_health_osd_check_delay: 30

추가 리소스

1.5.4. 다양한 디스크 토폴로지가 있는 Ansible을 사용하여 Ceph OSD 추가

디스크 토폴로지가 다른 Ceph OSD의 경우 새 OSD 노드를 기존 스토리지 클러스터에 추가하는 두 가지 방법이 있습니다.

사전 요구 사항

  • 실행 중인 Red Hat Ceph Storage 클러스터.
  • Red Hat Ceph Storage 설치 가이드의 Red Hat Ceph Storage 설치 요구 사항 장을 검토하십시오.
  • 새 노드에 대한 루트 액세스 권한 보유.

절차

  1. 첫 번째 접근 방식

    1. [osds] 섹션의 /etc/ansible/hosts 파일에 새 Ceph OSD 노드를 추가합니다.

      예제

      [osds]
...
osd06
NEW_OSD_NODE_NAME

    2. /etc/ansible/host_vars/ 디렉터리에 스토리지 클러스터에 추가된 각 새 Ceph OSD 노드의 새 파일을 만듭니다.

      구문

      touch /etc/ansible/host_vars/NEW_OSD_NODE_NAME

      예제

      [root@admin ~]# touch /etc/ansible/host_vars/osd07

    3. 새 파일을 편집하고 devices: 및 dedicated_devices: 섹션을 파일에 추가합니다. 이러한 각 섹션 아래에 -, 공백을 추가한 다음 이 OSD 노드의 블록 장치 이름에 대한 전체 경로를 추가합니다.

      예제

      devices:
  - /dev/sdc
  - /dev/sdd
  - /dev/sde
  - /dev/sdf

dedicated_devices:
  - /dev/sda
  - /dev/sda
  - /dev/sdb
  - /dev/sdb

    4. Ansible이 모든 Ceph 노드에 연결할 수 있는지 확인합니다. 

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

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

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

    6. 베어 메탈 및 컨테이너 배포의 경우 add-osd.yml Ansible 플레이북을 실행합니다.

      참고

      새 OSD 호스트의 경우 --limit 옵션을 사용하여 site.yml 또는 site-container.yml 플레이북을 실행해야 합니다. node-exporter 및 ceph-crash 서비스는 osds.yml 플레이북이 있는 노드에 배포되지 않습니다.

      예제

      [user@admin ceph-ansible]$ ansible-playbook infrastructure-playbooks/add-osd.yml -i hosts

      새 OSD 호스트의 경우 site.yml 또는 site-container.yml Ansible 플레이북을 실행합니다.

      • 베어 메탈 배포:

        구문

        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. 두 번째 접근 방식

    1. 새 OSD 노드 이름을 /etc/ansible/hosts 파일에 추가하고, 다른 디스크 토폴로지를 지정하여 devices 및 dedicated_devices 옵션을 사용합니다.

      예제

      [osds]
...
osd07 devices="['/dev/sdc', '/dev/sdd', '/dev/sde', '/dev/sdf']" dedicated_devices="['/dev/sda', '/dev/sda', '/dev/sdb', '/dev/sdb']"

    2. Ansible이 모든 Ceph 노드에 연결할 수 있는지 확인합니다. 

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

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

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

  3. 베어 메탈 및 컨테이너 배포의 경우 add-osd.yml Ansible 플레이북을 실행합니다.

    참고

    새 OSD 호스트의 경우 --limit 옵션을 사용하여 site.yml 또는 site-container.yml 플레이북을 실행해야 합니다. node-exporter 및 ceph-crash 서비스는 osds.yml 플레이북이 있는 노드에 배포되지 않습니다.

    예제

    [user@admin ceph-ansible]$ ansible-playbook infrastructure-playbooks/add-osd.yml -i hosts

    새 OSD 호스트의 경우 site.yml 또는 site-container.yml Ansible 플레이북을 실행합니다.

    • 베어 메탈 배포:

      구문

      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

추가 리소스

1.5.5. ceph-volume을 사용하여 Ceph OSD 생성

create 하위 명령은 prepare 하위 명령을 호출한 다음 activate 하위 명령을 호출합니다.

사전 요구 사항

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

생성 프로세스를 더 많이 제어하려는 경우 create를 사용하는 대신 OSD를 생성하도록 prepare 및 enable 하위 명령을 별도로 사용할 수 있습니다 . 두 개의 하위 명령을 사용하여 대량의 데이터의 균형을 유지하면서 새 OSD를 스토리지 클러스터에 점진적으로 도입할 수 있습니다. 두 접근 방식 모두 동일한 방식으로 작동합니다. 단, create 하위 명령을 사용하면 완료 후 즉시 OSD가 가동 됩니다.

절차

  1. 새 OSD를 만들려면 다음을 수행합니다.

    구문

    ceph-volume lvm create --bluestore --data VOLUME_GROUP/LOGICAL_VOLUME

    예제

    [root@osd ~]# ceph-volume lvm create --bluestore --data example_vg/data_lv

추가 리소스

1.5.6. ceph-volume과 함께 배치 모드 사용

batch 하위 명령은 단일 장치를 제공하는 경우 여러 OSD 생성을 자동화합니다.

ceph-volume 명령은 드라이브 유형에 따라 OSD를 생성하는 데 사용할 최상의 방법을 결정합니다. Ceph OSD 최적화는 사용 가능한 장치에 따라 다릅니다.

  • 모든 장치가 일반적인 하드 드라이브인 경우 배치는 장치당 하나의 OSD 를 생성합니다.
  • 모든 장치가 솔리드 스테이트 드라이브인 경우 배치는 장치당 두 개의 OSD를 생성합니다.
  • 전통적인 하드 드라이브와 솔리드 스테이트 드라이브가 혼합된 경우 배치는 기존의 하드 드라이브를 데이터에 사용하고, 솔리드 스테이트 드라이브에서 가능한 최대 저널(block.db)을 생성합니다.
참고

batch 하위 명령은 write-ahead-log(block.wal) 장치에 대해 별도의 논리 볼륨 생성을 지원하지 않습니다.

사전 요구 사항

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

절차

  1. 여러 드라이브에서 OSD를 생성하려면 다음을 수행합니다.

    구문

    ceph-volume lvm batch --bluestore PATH_TO_DEVICE [PATH_TO_DEVICE]

    예제

    [root@osd ~]# ceph-volume lvm batch --bluestore /dev/sda /dev/sdb /dev/nvme0n1

추가 리소스

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

다음은 Red Hat Ceph Storage에 OSD를 수동으로 추가하기 위한 상위 수준 워크플로입니다.

  1. ceph-osd 패키지를 설치하고 새 OSD 인스턴스를 생성합니다.
  2. OSD 데이터 및 저널 드라이브를 준비하고 마운트합니다.
  3. 볼륨 그룹 및 논리 볼륨 만들기.
  4. CRUSH 맵에 새 OSD 노드를 추가합니다.
  5. 소유자 및 그룹 권한을 업데이트합니다.
  6. ceph-osd 데몬을 활성화하고 시작합니다.
중요

ceph-disk 명령은 더 이상 사용되지 않습니다. 이제 명령줄 인터페이스에서 OSD를 배포하는 데 ceph-volume 명령이 선호됩니다. 현재 ceph-volume 명령은 lvm 플러그인만 지원합니다. Red Hat은 두 명령을 참조로 사용하여 이 가이드의 예제를 제공하므로 스토리지 관리자가 ceph-disk를 사용하는 모든 사용자 지정 스크립트를 ceph- volume 으로 변환할 수 있습니다.

참고

사용자 지정 스토리지 클러스터 이름의 경우 ceph 및 ceph -osd 명령과 함께 --cluster CLUSTER_NAME 옵션을 사용합니다.

사전 요구 사항

  • 실행 중인 Red Hat Ceph Storage 클러스터.
  • Red Hat Ceph Storage 설치 가이드의 Red Hat Ceph Storage 설치 요구 사항 장을 검토하십시오.
  • 새 노드에 대한 루트 액세스.
  • 선택 사항: ceph-volume 유틸리티에서 볼륨 그룹과 논리 볼륨을 자동으로 생성하지 않도록 하려면 수동으로 생성합니다. Red Hat Enterprise Linux 8의 논리 볼륨 구성 및 관리 가이드를 참조하십시오.

절차

  1. Red Hat Ceph Storage 4 OSD 소프트웨어 리포지토리를 활성화합니다.

    Red Hat Enterprise Linux 7

    [root@osd ~]# subscription-manager repos --enable=rhel-7-server-rhceph-4-osd-rpms

    Red Hat Enterprise Linux 8

    [root@osd ~]# subscription-manager repos --enable=rhceph-4-osd-for-rhel-8-x86_64-rpms

  2. /etc/ceph/ 디렉토리를 만듭니다. 

    [root@osd ~]# mkdir /etc/ceph

  3. 새 OSD 노드에서 Ceph Monitor 노드 중 하나에서 Ceph 관리 인증 키링 및 구성 파일을 복사합니다.

    구문

    scp USER_NAME @ MONITOR_HOST_NAME :/etc/ceph/CLUSTER_NAME.client.admin.keyring /etc/ceph
scp USER_NAME @ MONITOR_HOST_NAME :/etc/ceph/CLUSTER_NAME.conf /etc/ceph

    예제

    [root@osd ~]# scp root@node1:/etc/ceph/ceph.client.admin.keyring /etc/ceph/
[root@osd ~]# scp root@node1:/etc/ceph/ceph.conf /etc/ceph/

  4. 새 Ceph OSD 노드에 ceph-osd 패키지를 설치합니다.

    Red Hat Enterprise Linux 7

    [root@osd ~]# yum install ceph-osd

    Red Hat Enterprise Linux 8

    [root@osd ~]# dnf install ceph-osd

  5. OSD를 준비합니다.

    • 이전에 생성된 논리 볼륨을 사용하려면 다음을 수행합니다.

      구문

      ceph-volume lvm prepare --bluestore --data VOLUME_GROUP/LOGICAL_VOLUME

    • 논리 볼륨을 자동으로 생성하기 위해 ceph-volume 에 원시 장치를 지정하려면 다음을 수행합니다.

      구문

      ceph-volume lvm prepare --bluestore --data /PATH_TO_DEVICE

      자세한 내용은 OSD 준비 섹션을 참조하십시오.

  6. noup 옵션을 설정합니다. 

    [root@osd ~]# ceph osd set noup

  7. 새 OSD를 활성화합니다.

    구문

    ceph-volume lvm activate --bluestore OSD_ID OSD_FSID

    예제

    [root@osd ~]# ceph-volume lvm activate --bluestore 4 6cc43680-4f6e-4feb-92ff-9c7ba204120e

    자세한 내용은 OSD 활성화 섹션을 참조하십시오.

    참고

    단일 명령으로 OSD를 준비하고 활성화할 수 있습니다. 자세한 내용은 OSD 생성 섹션을 참조하십시오. 또는 단일 명령으로 여러 드라이브를 지정하고 OSD를 만들 수도 있습니다. 배치 모드를 사용하여 를 참조하십시오.

  8. OSD를 CRUSH 맵에 추가합니다. 버킷을 두 개 이상 지정하는 경우 명령은 지정된 버킷에 OSD를 배치하고 지정한 다른 버킷 아래의 버킷을 이동합니다.

    구문

    ceph osd crush add OSD_ID WEIGHT [ BUCKET_TYPE = BUCKET_NAME ...]

    예제

    [root@osd ~]# ceph osd crush add 4 1 host=node4

    참고

    버킷을 두 개 이상 지정하는 경우 명령은 지정된 버킷에 OSD를 배치하고 지정한 다른 버킷 아래의 버킷을 이동합니다.

    참고

    CRUSH 맵을 수동으로 편집할 수도 있습니다. Red Hat Ceph Storage Storage Strategies Guide의 CRUSH 맵 편집 섹션을 참조하십시오.

    중요

    루트 버킷만 지정하면 OSD가 root에 직접 연결되지만 CRUSH 규칙에는 호스트 버킷 내부에 OSD가 있어야 합니다.

  9. noup 옵션을 설정 해제합니다. 

    [root@osd ~]# ceph osd unset noup

  10. 새로 생성된 디렉터리에 대한 소유자 및 그룹 권한을 업데이트합니다.

    구문

    chown -R OWNER : GROUP PATH_TO_DIRECTORY

    예제

    [root@osd ~]# chown -R ceph:ceph /var/lib/ceph/osd
[root@osd ~]# chown -R ceph:ceph /var/log/ceph
[root@osd ~]# chown -R ceph:ceph /var/run/ceph
[root@osd ~]# chown -R ceph:ceph /etc/ceph

  11. 사용자 정의 이름으로 스토리지 클러스터를 사용하는 경우 적절한 파일에 다음 행을 추가합니다. 

    [root@osd ~]# echo "CLUSTER=CLUSTER_NAME" >> /etc/sysconfig/ceph

    CLUSTER_NAME 을 사용자 지정 스토리지 클러스터 이름으로 교체합니다.

  12. 새 OSD가 가동 되어 데이터를 수신할 준비가 되었는지 확인하려면 OSD 서비스를 활성화하고 시작합니다.

    구문

    systemctl enable ceph-osd@OSD_ID
systemctl start ceph-osd@OSD_ID

    예제

    [root@osd ~]# systemctl enable ceph-osd@4
[root@osd ~]# systemctl start ceph-osd@4

추가 리소스

1.5.8. 컨테이너화된 환경에서 명령줄 인터페이스를 사용하여 Ceph OSD 추가

컨테이너화된 Red Hat Ceph Storage 클러스터에서 명령줄 인터페이스를 사용하여 단일 또는 여러 Ceph OSD를 수동으로 추가할 수 있습니다.

중요

Ceph OSD를 수동으로 추가해야 하는 경우 예외 또는 특정 사용 사례가 없는 한 ceph-ansible 을 사용하여 Ceph OSD를 추가하는 것이 좋습니다. 확실하지 않은 경우 Red Hat 지원에 문의하십시오.

사전 요구 사항

  • 컨테이너화된 환경에서 실행 중인 Red Hat Ceph Storage 클러스터.
  • 컨테이너 노드에 root 액세스 권한이 있어야 합니다.
  • 기존 OSD 노드.
중요

아래 예제는 Red Hat Enterprise Linux 8에서 실행 중입니다. Red Hat Enterprise Linux 8에서 podman은 기본 서비스이며 이전 docker 서비스를 대체했습니다. Red Hat Enterprise Linux 7에서 실행 중인 경우 podman을 docker로 대체하여 지정된 명령을 실행합니다.

절차

  1. 단일 OSD를 만들려면 lvm prepare 명령을 실행합니다.

    구문

    podman run --rm --net=host --privileged=true --pid=host --ipc=host -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 -v /run/lvm/:/run/lvm/ --entrypoint=ceph-volume PATH_TO_IMAGE --cluster CLUSTER_NAME lvm prepare --bluestore --data PATH_TO_DEVICE --no-systemd

    예제

    [root@osd ~]# podman run --rm --net=host --privileged=true --pid=host --ipc=host -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 -v /run/lvm/:/run/lvm/ --entrypoint=ceph-volume registry.redhat.io/rhceph/rhceph-4-rhel8:latest --cluster ceph lvm prepare --bluestore --data /dev/sdh --no-systemd

    이 예제에서는 /dev/sdh 에 있는 데이터가 있는 단일 Bluestore Ceph OSD를 준비합니다.

    참고

    OSD를 활성화하고 시작하려면 다음 명령을 실행합니다.

    예제

    [root@osd ~]# systemctl enable ceph-osd@4
[root@osd ~]# systemctl start ceph-osd@4

    다음 선택적 인수를 사용할 수도 있습니다.

    dmcrypt
    설명
    기본 OSD 장치에 대한 암호화를 활성화합니다.
    block.db
    설명
    bluestore block.db 논리 볼륨 또는 파티션에 대한 경로입니다.
    block.wal
    설명
    bluestore block.wal 논리 볼륨 또는 파티션에 대한 경로입니다.

  2. 여러 Ceph OSD를 만들려면 lvm batch 명령을 실행합니다.

    구문

    podman run --rm --net=host --privileged=true --pid=host --ipc=host -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 -v /run/lvm/:/run/lvm/ --entrypoint=ceph-volume PATH_TO_IMAGE --cluster CLUSTER_NAME lvm batch --bluestore --yes --prepare _PATH_TO_DEVICE PATH_TO_DEVICE --no-systemd

    예제

    [root@osd ~]# podman run --rm --net=host --privileged=true --pid=host --ipc=host -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 -v /run/lvm/:/run/lvm/ --entrypoint=ceph-volume registry.redhat.io/rhceph/rhceph-4-rhel8:latest --cluster ceph lvm batch --bluestore --yes --prepare /dev/sde /dev/sdf --no-systemd

    이 예제에서는 /dev/sde 및 /dev/sdf 의 데이터가 있는 여러 Bluestore Ceph OSD를 준비합니다.

    다음 선택적 인수를 사용할 수도 있습니다.

    dmcrypt
    설명
    기본 OSD 장치에 대한 암호화를 활성화합니다.
    db-devices
    설명
    bluestore block.db 논리 볼륨 또는 파티션에 대한 경로입니다.
    wal-devices
    설명
    bluestore block.wal 논리 볼륨 또는 파티션에 대한 경로입니다.

1.5.9. Ansible을 사용하여 Ceph OSD 제거

경우에 따라 Red Hat Ceph Storage 클러스터의 용량을 축소해야 할 수도 있습니다. Ansible을 사용하여 Red Hat Ceph Storage 클러스터에서 OSD를 제거하려면 shrink-osd.yml 플레이북을 실행합니다.

중요

스토리지 클러스터에서 OSD를 제거하면 해당 OSD에 포함된 모든 데이터가 삭제됩니다.

중요

OSD를 제거하기 전에 클러스터에 리밸런스에 충분한 공간이 있는지 확인합니다.

중요

배치 그룹이 active+clean 상태이고 OSD에는 동일한 오브젝트에 대한 복제본 또는 삭제 코딩 shard가 포함되지 않는 한 동시에 OSD를 제거하지 마십시오. 확실하지 않은 경우 Red Hat 지원팀에 문의하십시오.

사전 요구 사항

  • Ansible에서 배포한 실행 중인 Red Hat Ceph Storage.
  • 실행 중인 Ansible 관리 노드.

절차

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

    구문

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

  2. Ceph Monitor 노드의 /etc/ceph/ 에서 제거하려는 OSD가 포함된 노드로 관리자 인증 키를 복사합니다.

  3. Ceph의 일반 또는 컨테이너화된 배포에 대해 Ansible 플레이북을 실행합니다.

    구문

    ansible-playbook infrastructure-playbooks/shrink-osd.yml -e osd_to_kill=ID -u ANSIBLE_USER_NAME -i hosts

    교체:

    • OSD 노드 의 ID가 있는 ID입니다. 여러 OSD를 제거하려면 OSD ID를 쉼표로 구분합니다.
    • Ansible 사용자의 이름과 ANSIBLE_USER_NAME.

    예제

    [user@admin ceph-ansible]$ ansible-playbook infrastructure-playbooks/shrink-osd.yml -e osd_to_kill=1 -u user -i hosts

  4. OSD가 성공적으로 제거되었는지 확인합니다.

    구문

    [root@mon ~]# ceph osd tree

추가 리소스

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

스토리지 클러스터에서 OSD를 제거하려면 다음과 같은 단계가 포함됩니다. * 클러스터 맵 업데이트. * 인증 키 제거. * OSD 맵에서 OSD 제거. * ceph.conf 파일에서 OSD를 제거합니다.

OSD 노드에 여러 드라이브가 있는 경우 제거하려는 각 OSD에 대해 이 절차를 반복하여 각 드라이브의 OSD를 제거해야 할 수 있습니다.

사전 요구 사항

  • 실행 중인 Red Hat Ceph Storage 클러스터.
  • 스토리지 클러스터가 거의 가득 차지 않도록 사용 가능한 OSD가 충분합니다.
  • OSD 노드에 대한 루트 수준의 액세스.

절차

  1. OSD 서비스를 비활성화하고 중지합니다.

    구문

    systemctl disable ceph-osd@OSD_ID
systemctl stop ceph-osd@OSD_ID

    예제

    [root@osd ~]# systemctl disable ceph-osd@4
[root@osd ~]# systemctl stop ceph-osd@4

    OSD가 중지되면 종료됩니다.

  2. 스토리지 클러스터에서 OSD를 제거합니다.

    구문

    ceph osd out OSD_ID

    예제

    [root@osd ~]# ceph osd out 4

    중요

    OSD가 제거되면 Ceph에서 리밸런싱 및 스토리지 클러스터의 나머지 OSD에 데이터를 복사하기 시작합니다. 다음 단계를 진행하기 전에 스토리지 클러스터가 active+clean 이 될 때까지 기다리는 것이 좋습니다. 데이터 마이그레이션을 관찰하려면 다음 명령을 실행합니다.

    구문

    [root@mon ~]# ceph -w

  3. CRUSH 맵에서 OSD를 제거하여 더 이상 데이터를 받지 않도록 합니다.

    구문

    ceph osd crush remove OSD_NAME

    예제

    [root@osd ~]# ceph osd crush remove osd.4

    참고

    OSD와 여기에 포함된 버킷을 수동으로 제거하려면 CRUSH 맵의 압축을 풀거나, 장치 목록에서 OSD를 제거하거나, 호스트 버킷에서 항목으로 장치를 제거하거나, 호스트 버킷을 제거할 수도 있습니다. CRUSH 맵에 있고 호스트를 제거하려는 경우 맵을 다시 컴파일하여 설정합니다. 자세한 내용은 스토리지 전략 가이드에서 CRUSH 맵을 decompilimg 지침을 참조하십시오.

  4. OSD 인증 키를 제거합니다.

    구문

    ceph auth del osd.OSD_ID

    예제

    [root@osd ~]# ceph auth del osd.4

  5. OSD를 제거합니다.

    구문

    ceph osd rm OSD_ID

    예제

    [root@osd ~]# ceph osd rm 4

  6. 스토리지 클러스터의 구성 파일을 편집합니다. 파일의 기본 이름은 /etc/ceph/ceph.conf 입니다. 파일이 있는 경우 파일에서 OSD 항목을 제거합니다.

    예제

    [osd.4]
host = _HOST_NAME_

  7. OSD를 수동으로 추가한 경우 /etc/fstab 파일에서 OSD에 대한 참조를 제거합니다.

  8. 업데이트된 구성 파일을 스토리지 클러스터에 있는 다른 모든 노드의 /etc/ceph/ 디렉터리에 복사합니다.

    구문

    scp /etc/ceph/CLUSTER_NAME.conf USER_NAME@HOST_NAME:/etc/ceph/

    예제

    [root@osd ~]# scp /etc/ceph/ceph.conf root@node4:/etc/ceph/

1.5.11. 명령줄 인터페이스를 사용하여 BlueStore 데이터베이스 디스크 교체

BlueStore DB 장치를 교체할 때 BlueStore OSD의 내부 메타데이터가 포함된 BlueStore DB 장치를 교체할 때 Red Hat은 Ansible과 CLI(명령줄 인터페이스)를 사용하여 모든 OSD의 재배포를 지원합니다 . 손상된 block.db 파일은 해당 block.db 파일에 포함된 모든 OSD에 영향을 미칩니다.

BlueStore block.db 디스크를 교체하는 절차는 각 장치를 차례로 표시하고, 데이터를 클러스터에서 복제할 때까지 기다린 다음 OSD를 교체한 다음 다시 다시 표시하는 것입니다. 교체된 디스크에 새 block.db 파티션을 사용하여 OSD_ID 를 유지하고 OSD를 다시 생성할 수 있습니다. 이는 간단한 절차이지만 많은 데이터 마이그레이션이 필요합니다.

참고

block.db 장치에 여러 OSD가 있는 경우 block.db 장치의 각 OSD에 대해 다음 절차를 따르십시오. ceph-volume lvm list 를 실행하여 block.db 를 확인하여 관계를 차단할 수 있습니다.

사전 요구 사항

  • 실행 중인 Red Hat Ceph Storage 클러스터.
  • 파티션이 있는 스토리지 장치.
  • 모든 노드에 대한 루트 수준의 액세스.

절차

  1. 모니터 노드의 현재 Ceph 클러스터 상태를 확인합니다. 

    [root@mon ~]# ceph status
[root@mon ~]# ceph df

  2. 교체할 실패한 OSD를 확인합니다. 

    [root@mon ~]# ceph osd tree | grep -i down

  3. OSD 노드에서 OSD 서비스를 중지하고 비활성화합니다.

    구문

    systemctl disable ceph-osd@OSD_ID
systemctl stop ceph-osd@OSD_ID

    예제

    [root@osd1 ~]# systemctl stop ceph-osd@1
[root@osd1 ~]# systemctl disable ceph-osd@1

  4. 모니터 노드에서 OSD 를 설정합니다.

    구문

    ceph osd out OSD_ID

    예제

    [root@mon ~]# ceph osd out 1

  5. 데이터가 OSD에서 마이그레이션될 때까지 기다립니다.

    구문

    while ! ceph osd safe-to-destroy OSD_ID ; do sleep 60 ; done

    예제

    [root@mon ~]# while ! ceph osd safe-to-destroy 1 ; do sleep 60 ; done

  6. OSD 노드에서 OSD 데몬을 중지합니다.

    구문

    systemctl kill ceph-osd@OSD_ID

    예제

    [root@osd1 ~]# systemctl kill ceph-osd@1

  7. 이 OSD가 사용 중인 장치를 기록해 둡니다.

    구문

    mount | grep /var/lib/ceph/osd/ceph-OSD_ID

    예제

    [root@osd1 ~]# mount | grep /var/lib/ceph/osd/ceph-1

  8. OSD 노드에서 실패한 드라이브 경로의 마운트 지점을 마운트 해제합니다.

    구문

    umount /var/lib/ceph/osd/CLUSTER_NAME-OSD_ID

    예제

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

  9. 백필 및 재조정을 방지하려면 noout 및 norebalance 를 설정합니다. 

    [root@mon ~]# ceph osd set noout
[root@mon ~]# ceph osd set norebalance
  10. 물리적 드라이브를 교체하십시오. 노드의 하드웨어 벤더 설명서를 참조하십시오. 계속 진행하기 전에 새 드라이브가 /dev/ 디렉터리에 표시되도록 허용하고 드라이브 경로를 기록합니다.

  11. 모니터 노드에서 OSD를 삭제합니다.

    구문

    ceph osd destroy OSD_ID --yes-i-really-mean-it

    예제

    [root@mon ~]# ceph osd destroy 1 --yes-i-really-mean-it

    중요

    이 단계는 장치의 내용을 삭제합니다. 장치의 데이터가 필요하지 않으며 클러스터가 정상인지 확인합니다.

  12. OSD 디스크에서 논리 볼륨 관리자를 제거합니다.

    구문

    lvremove /dev/VOLUME_GROUP/LOGICAL_VOLUME
vgremove VOLUME_GROUP
pvremove /dev/DEVICE

    예제

    [root@osd1 ~]# lvremove /dev/data-vg1/data-lv1
[root@osd1 ~]# vgremove data-vg1
[root@osd1 ~]# pvremove /dev/sdb

  13. OSD 노드의 OSD 디스크를 zap합니다.

    구문

    ceph-volume lvm zap DEVICE

    예제

    [root@osd1 ~]# ceph-volume lvm zap /dev/sdb

  14. OSD 디스크에서 lvm 재생성:

    구문

    pvcreate /dev/DEVICE
vgcreate VOLUME_GROUP /dev/DEVICE
lvcreate -l SIZE -n LOGICAL_VOLUME VOLUME_GROUP

    예제

    [root@osd1 ~]# pvcreate /dev/sdb
[root@osd1 ~]# vgcreate data-vg1 /dev/sdb
[root@osd1 ~]# lvcreate -l 100%FREE -n data-lv1 data-vg1

  15. 새 block.db 디스크에 lvm을 생성합니다.

    구문

    pvcreate /dev/DEVICE
vgcreate VOLUME_GROUP_DATABASE /dev/DEVICE
lvcreate -Ll SIZE -n LOGICAL_VOLUME_DATABASE VOLUME_GROUP_DATABASE

    예제

    [root@osd1 ~]# pvcreate /dev/sdb
[root@osd1 ~]# vgcreate db-vg1 /dev/sdb
[root@osd1 ~]# lvcreate -l 100%FREE -n lv-db1 db-vg1

  16. OSD 노드에서 OSD를 재생성합니다.

    구문

    ceph-volume lvm create --bluestore --osd-id OSD_ID --data VOLUME_GROUP/LOGICAL_VOLUME --block.db VOLUME_GROUP_DATABASE/LOGICAL_VOLUME_DATABASE

    예제

    [root@osd1 ~]# ceph-volume lvm create --bluestore --osd-id 1 --data data-vg1/data-lv1 --block.db db-vg1/db-lv1

    참고

    Red Hat은 이전 단계에서 삭제한 것과 동일한 OSD_ID 를 사용할 것을 권장합니다.

  17. OSD 노드에서 OSD 서비스를 시작하고 활성화합니다.

    구문

    systemctl start ceph-osd@OSD_ID
systemctl enable ceph-osd@OSD_ID

    예제

    [root@osd1 ~]# systemctl start ceph-osd@1
[root@osd1 ~]# systemctl enable ceph-osd@1

  18. CRUSH 계층 구조를 확인하여 OSD가 클러스터에 있는지 확인합니다. 

    [root@mon ~]# ceph osd tree

  19. noout 및 norebalance를 설정 해제합니다. 

    [root@mon ~]# ceph osd unset noout
[root@mon ~]# ceph osd unset norebalance

  20. HEALTH_OK: 

    [root@mon ~]# watch -n2 ceph -s

추가 리소스

1.5.12. 데이터 마이그레이션 관찰

OSD를 CRUSH 맵에 추가하거나 제거하면 Ceph에서 배치 그룹을 새 OSD 또는 기존 OSD로 마이그레이션하여 데이터 리밸런싱을 시작합니다.

사전 요구 사항

  • 실행 중인 Red Hat Ceph Storage 클러스터.
  • 최근에 OSD를 추가하거나 제거했습니다.

절차

  1. 데이터 마이그레이션을 관찰하려면 다음을 수행합니다. 

    [root@monitor ~]# ceph -w
  2. 마이그레이션이 완료되면 배치 그룹 상태가 active+clean 에서 활성, 일부 저하된 개체 및 마지막으로 활성+clean 으로 변경되는 것을 봅니다.
  3. 유틸리티를 종료하려면 Ctrl + C 를 누릅니다.

1.6. 배치 그룹 재계산

배치 그룹(PG)은 사용 가능한 OSD에서 풀 데이터의 분배를 정의합니다. 배치 그룹은 지정된 중복 알고리즘을 기반으로 구축되어 사용할 수 있습니다. 3방향 복제의 경우 중복은 세 개의 다른 OSD를 사용하도록 정의됩니다. Earsure-coded 풀의 경우 사용할 OSD 수는 청크 수로 정의됩니다.

참고

풀을 정의할 때 배치 그룹의 수는 사용 가능한 모든 OSD에 걸쳐 데이터가 분산되는 세분화 등급을 정의합니다. 크기가 클수록 용량 부하의 동등화가 더 클 수 있습니다. 그러나 데이터를 재구성하는 경우 배치 그룹을 처리하는 것도 중요하므로 신중하게 선택하는 것이 중요합니다. 계산 작업을 지원하기 위해 툴을 사용하여 민첩한 환경을 생성할 수 있습니다.

스토리지 클러스터의 라이프사이클 동안 풀은 초기에 예상되는 한계보다 증가할 수 있습니다. 드라이브 수가 늘어나면 재계산이 권장됩니다. OSD당 배치 그룹 수는 약 100개여야 합니다. 스토리지 클러스터에 OSD를 더 추가하면 OSD당 DC 수가 시간이 지남에 따라 줄어듭니다. 스토리지 클러스터에서 처음 120개의 드라이브로 시작하고 풀의 pg_num 을 4000개로 설정하면 OSD당 100개의 Placements가 되며, 3개의 복제 요소가 적용됩니다. 시간이 지남에 따라 OSD 수를 10배로 늘릴 경우 OSD당 DC 수는 10개로 줄어듭니다. OSD당 배치 수가 적지 않게 분산된 용량이기 때문에 풀당 PPP를 조정하는 것이 좋습니다.

배치 그룹의 수를 조정하는 작업은 온라인으로 수행할 수 있습니다. 재계산은 PPP 숫자를 재계산하는 것뿐만 아니라 데이터 재배치가 포함될 것이며, 이는 긴 프로세스가 될 것입니다. 그러나 데이터 가용성은 언제든지 유지됩니다.

실패한 OSD에 있는 모든 DC의 재구성이 즉시 시작되므로 OSD당 VDO 수가 매우 많으면 안 됩니다. 많은 IOPS가 적시에 재구성을 수행해야 하므로 사용할 수 없을 수 있습니다. 이로 인해 깊은 I/O 대기열과 스토리지 클러스터를 사용할 수 없게 되거나 복구 시간이 길어집니다.

추가 리소스

  • 지정된 사용 사례에 따른 값을 계산하려면 DASD 계산기 를 참조하십시오.
  • 자세한 내용은 Red Hat Ceph Storage Strategies Guide(Red Hat Ceph 스토리지 전략 가이드 )의 코드 풀 장을 참조하십시오.

1.7. Ceph Manager 밸런서 모듈 사용

이 밸런서는 자동으로 또는 감독된 방식으로 분산 배포를 수행하기 위해 OSD 간에 배치 그룹(PG)의 배치를 최적화하는 Ceph Manager(ceph-mgr)용 모듈입니다.

모드

현재 두 가지 지원되는 밸런서 모드가 있습니다.

  • crush-compat: CRUSH 호환성 모드는 Ceph Luminous에 도입된 compat weight-set 기능을 사용하여 CRUSH 계층 구조의 장치에 대한 대체 가중치 집합을 관리합니다. 일반 가중치는 장치에 저장하려는 대상 데이터 양을 반영하도록 장치의 크기로 설정되어야 합니다. 그런 다음 밸런서는 가능한 한 가깝게 대상 배포와 일치하는 배포를 달성하기 위해 weight-set 값을 최적화하여 작은 증분으로 조정하거나 축소합니다. PG 배치는 의사 임의 프로세스이므로 배치에는 자연적인 변형이 있습니다. 가중치를 최적화함으로써 밸런서는 이러한 자연적 변형을 수행합니다.

    이 모드는 이전 클라이언트와 완전히 호환됩니다. OSDMap 및 CRUSH 맵이 이전 클라이언트와 공유되면 밸런서는 최적화된 가중치를 실제 가중치로 제공합니다.

    이 모드의 기본 제한은 계층 구조의 하위 트리가 모든 OSD를 공유하는 경우 다양한 배치 규칙으로 여러 CRUSH 계층 구조를 처리할 수 없다는 것입니다. 이 구성을 사용하면 공유 OSD에서 공간 사용률을 관리하기가 어렵기 때문에 일반적으로 사용하지 않는 것이 좋습니다. 따라서 이 제한은 일반적으로 문제가 아닙니다.

  • upmap: Luminous부터 OSDMap은 개별 OSD에 대한 명시적 매핑을 일반 CRUSH 배치 계산에 예외적으로 저장할 수 있습니다. 이러한 upmap 항목은 PG 매핑에 대한 세분화된 제어를 제공합니다. 이 CRUSH 모드는 분산 배포를 수행하기 위해 개별 PG의 배치를 최적화합니다. 대부분의 경우 이 배포는 균등하게 분배되지 않을 수 있으므로 각 OSD +/-1 PG에 동일한 수의 PG가 있는 "perfect"입니다.

    중요

    이 기능을 사용하려면 다음 명령을 사용하여 고급 또는 이후 클라이언트만 지원해야 함을 클러스터에 알려야 합니다. 

    [root@admin ~]# ceph osd set-require-min-compat-client luminous

    기존 클라이언트 또는 데몬이 모니터에 연결되어 있으면 이 명령이 실패합니다.

    알려진 문제로 인해 커널 CephFS 클라이언트는 자신을 jewel 클라이언트로 보고합니다. 이 문제를 해결하려면 --yes-i-really-mean-it 플래그를 사용합니다. 

    [root@admin ~]# ceph osd set-require-min-compat-client luminous --yes-i-really-mean-it

    다음과 함께 사용 중인 클라이언트 버전을 확인할 수 있습니다. 

    [root@admin ~]# ceph features

사전 요구 사항

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

절차

  1. 밸런서 모듈이 에 있는지 확인합니다.

    예제

    [root@mon ~]# ceph mgr module ls | more
{
    "always_on_modules": [
        "balancer",
        "crash",
        "devicehealth",
        "orchestrator_cli",
        "progress",
        "rbd_support",
        "status",
        "volumes"
    ],
    "enabled_modules": [
        "dashboard",
        "pg_autoscaler",
        "prometheus"
    ],

    1. balancer 모듈이 always_on 또는 enabled 모듈에 나열되지 않은 경우 활성화합니다.

      구문

      ceph mgr module enable balancer

  2. balancer 모듈을 켭니다. 

    [root@mon ~]# ceph balancer on

  3. 기본 모드는 crush-compat 입니다. 모드는 다음을 사용하여 변경할 수 있습니다. 

    [root@mon ~]# ceph balancer mode upmap

    또는 

    [root@mon ~]# ceph balancer mode crush-compat

상태

pod의 현재 상태는 다음을 사용하여 언제든지 확인할 수 있습니다. 

[root@mon ~]# ceph balancer status

자동 분산

기본적으로 balancer 모듈을 활성화하면 자동 분산이 사용됩니다. 

[root@mon ~]# ceph balancer on

다음을 사용하여 밸런서를 다시 끌 수 있습니다. 

[root@mon ~]# ceph balancer off

이 명령은 이전 클라이언트와 역호환되는 crush-compat 모드를 사용하며 시간이 지남에 따라 데이터 배포를 약간 변경하여 OSD를 동일하게 활용합니다.

제한

클러스터가 성능이 저하되고 OSD가 실패하여 시스템이 아직 복구되지 않은 경우와 같이 cluster가 저하된 경우는 Placement 배포에서 조정되지 않습니다.

클러스터가 정상이면 밸런서에서 잘못된 배치 또는 이동해야 하는 PC의 백분율이 기본적으로 5% 미만인 만큼 해당 변경 사항을 제한합니다. 이 백분율은 target_max_misplaced_ratio 설정을 사용하여 조정할 수 있습니다. 예를 들어 임계값을 7%로 늘리려면 다음을 수행합니다.

예제

[root@mon ~]# ceph config set mgr target_max_misplaced_ratio .07

자동 밸런싱의 경우:

  • 자동 밸런서 실행 사이에 절전할 시간(초)을 설정합니다.

예제

[root@mon ~]# ceph config set mgr mgr/balancer/sleep_interval 60

  • HHMM 형식으로 자동 균형을 시작할 시간을 설정합니다.

예제

[root@mon ~]# ceph config set mgr mgr/balancer/begin_time 0000

  • HHMM 형식으로 자동 균형을 완료하는 시간을 설정합니다.

예제

[root@mon ~]# ceph config set mgr mgr/balancer/end_time 2359

  • 이 요일 또는 이후 버전으로 자동 균형을 제한합니다. crontab과 동일한 규칙을 사용하며 0 은 줄임말이며 1 은 월요일입니다.

예제

[root@mon ~]# ceph config set mgr mgr/balancer/begin_weekday 0

  • 이번 주 또는 이전 요일에 대한 자동 균형을 제한합니다. 이것은 crontab과 동일한 규칙을 사용하며 0 은 줄임말이며 1 은 월요일입니다.

예제

[root@mon ~]# ceph config set mgr mgr/balancer/end_weekday 6

  • 자동 밸런싱이 제한된 풀 ID를 정의합니다. 이 기본값은 빈 문자열입니다. 즉, 모든 풀이 균형을 유지합니다. ceph osd pool ls detail 명령을 사용하여 숫자 풀 ID를 가져올 수 있습니다.

예제

[root@mon ~]#  ceph config set mgr mgr/balancer/pool_ids 1,2,3

감독된 최적화

밸런서 작업은 다음과 같은 몇 가지 단계로 나뉩니다.

  1. 계획 수립.
  2. 데이터 배포의 품질(현재 DASD 배포 또는 계획 실행 후 발생 시 발생)에 대한 데이터 배포 품질을 평가합니다.

  3. 계획 실행.

    • 현재 배포를 평가하고 점수를 매기려면 다음을 수행합니다. 

      [root@mon ~]# ceph balancer eval

    • 단일 풀의 배포를 평가하려면 다음을 수행합니다.

      구문

      ceph balancer eval POOL_NAME

      예제

      [root@mon ~]# ceph balancer eval rbd

    • 평가에 대한 세부 정보를 보려면 다음을 수행합니다. 

      [root@mon ~]# ceph balancer eval-verbose ...

    • 현재 구성된 모드를 사용하여 계획을 생성하려면 다음을 수행합니다.

      구문

      ceph balancer optimize PLAN_NAME

      PLAN_NAME 을 사용자 지정 계획 이름으로 교체합니다.

      예제

      [root@mon ~]# ceph balancer optimize rbd_123

    • 계획 내용을 보려면 다음을 수행합니다.

      구문

      ceph balancer show PLAN_NAME

      예제

      [root@mon ~]# ceph balancer show rbd_123

    • 이전 계획을 삭제하려면 다음을 수행합니다.

      구문

      ceph balancer rm PLAN_NAME

      예제

      [root@mon ~]# ceph balancer rm rbd_123

    • 현재 기록된 계획을 보려면 상태 명령을 사용합니다. 

      [root@mon ~]# ceph balancer status

    • 계획을 실행한 후 발생하는 배포 품질을 계산하려면 다음을 수행합니다.

      구문

      ceph balancer eval PLAN_NAME

      예제

      [root@mon ~]# ceph balancer eval rbd_123

    • 계획을 실행하려면 다음을 수행합니다.

      구문

      ceph balancer execute PLAN_NAME

      예제

      [root@mon ~]# ceph balancer execute rbd_123

      참고

      배포를 개선할 것으로 예상되는 경우에만 계획을 실행합니다. 실행 후 계획이 취소됩니다.

1.8. upmap 을 사용하여 OSD에서 데이터를 수동으로 리밸런스

스토리지 관리자는 선택한 배치 그룹(PG)을 특정 OSD로 이동하여 OSD에서 데이터를 수동으로 리밸런스할 수 있습니다. 수동 재조정을 수행하려면 Ceph Manager 밸런서 모듈을 끄고 upmap 모드를 사용하여 PG를 이동합니다.

사전 요구 사항

  • 실행 중인 Red Hat 스토리지 클러스터.
  • 스토리지 클러스터의 모든 노드에 대한 루트 수준의 액세스.

절차

  1. 밸런서 모듈이 에 있는지 확인합니다.

    예제

    [root@mon ~]# ceph mgr module ls | more
{
    "always_on_modules": [
        "balancer",
        "crash",
        "devicehealth",
        "orchestrator_cli",
        "progress",
        "rbd_support",
        "status",
        "volumes"
    ],
    "enabled_modules": [
        "dashboard",
        "pg_autoscaler",
        "prometheus"
    ],

    1. balancer 모듈이 always_on 또는 enabled 모듈에 나열되지 않은 경우 활성화합니다.

      구문

      ceph mgr module enable balancer

  2. 밸런서 모드를 upmap 으로 설정 :

    구문

    ceph balancer mode upmap

  3. balancer 모듈을 끕니다.

    구문

    ceph balancer off

  4. 밸런서 상태 확인:

    예제

    [root@mon ~]# ceph balancer status
{
    "plans": [],
    "active": false,
    "last_optimize_started": "",
    "last_optimize_duration": "",
    "optimize_result": "",
    "mode": "upmap"
}

  5. OSD의 norebalance 플래그를 설정합니다.

    구문

    ceph osd set norebalance

  6. ceph pg dump pgs_brief 명령을 사용하여 스토리지 클러스터의 풀과 각 공간을 나열합니다. grep 을 사용하여 풀 재대 매핑을 검색합니다.

    예제

    [root@mon ~]# ceph pg dump pgs_brief
PG_STAT STATE                         UP               UP_PRIMARY ACTING         ACTING_PRIMARY
dumped pgs_brief
7.270   active+remapped+backfilling  [8,48,61]          8 [46,48,61]             46
7.1e7   active+remapped+backfilling [73,64,74]         73 [18,64,74]             18
7.1c1   active+remapped+backfilling  [29,14,8]         29 [29,14,24]             29
7.17f   active+remapped+backfilling [73,71,50]         73 [50,71,69]             50
7.16c   active+remapped+backfilling   [66,8,4]         66  [66,4,57]             66
7.13d   active+remapped+backfilling [73,27,56]         73 [27,56,35]             27
7.130   active+remapped+backfilling [53,47,73]         53 [53,47,72]             53
9.e0    active+remapped+backfilling  [8,75,14]          8 [14,75,58]             14
7.db    active+remapped+backfilling [10,57,60]         10 [10,60,50]             10
9.7     active+remapped+backfilling [26,69,38]         26 [26,38,41]             26
7.4a    active+remapped+backfilling [73,10,76]         73 [10,76,29]             10
9.9a    active+remapped+backfilling [20,15,73]         20 [20,15,29]             20
7.ac    active+remapped+backfilling   [8,74,3]          8  [3,74,37]              3
9.c2    active+remapped+backfilling  [57,75,7]         57   [4,75,7]              4
7.34d   active+remapped+backfilling [23,46,73]         23 [23,46,56]             23
7.36a   active+remapped+backfilling  [40,32,8]         40 [40,32,44]             40

  7. PG를 상주할 OSD로 이동합니다. 예를 들어 PG 7.ac을 OSD 8 및 3에서 OSD 3 및 37으로 이동하려면 다음을 수행합니다.

    예제

    PG_STAT STATE                         UP               UP_PRIMARY ACTING         ACTING_PRIMARY
dumped pgs_brief
7.ac    active+remapped+backfilling   [8,74,3]          8  [3,74,37]              3

[root@mon ~]# ceph osd pg-upmap-items 7.ac 8 3 3 37

7.ac   active+clean                 [3,74,37]          8 [3,74,37]             3

    참고

    이 단계를 반복하여 각 매핑 PG를 한 번에 하나씩 이동합니다.

  8. ceph pg dump pgs_brief 명령을 다시 사용하여 PG가 active+clean 상태로 이동하는지 확인합니다.

    예제

    [root@mon ~]# ceph pg dump pgs_brief
PG_STAT STATE                         UP               UP_PRIMARY ACTING         ACTING_PRIMARY
dumped pgs_brief
7.270   active+clean                [8,48,61]          8 [46,48,61]              46
7.1e7   active+clean                [73,64,74]         73 [18,64,74]             18
7.1c1   active+clean                [29,14,8]          29 [29,14,24]             29
7.17f   active+clean                [73,71,50]         73 [50,71,69]             50
7.16c   active+clean                [66,8,4]           66  [66,4,57]             66
7.13d   active+clean                [73,27,56]         73 [27,56,35]             27
7.130   active+clean                [53,47,73]         53 [53,47,72]             53
9.e0    active+clean                [8,75,14]          8 [14,75,58]              14
7.db    active+clean                [10,57,60]         10 [10,60,50]             10
9.7     active+clean                [26,69,38]         26 [26,38,41]             26
7.4a    active+clean                [73,10,76]         73 [10,76,29]             10
9.9a    active+clean                [20,15,73]         20 [20,15,29]             20
7.ac    active+clean                [3,74,37]          8 [3,74,37]               3
9.c2    active+clean                [57,75,7]          57 [4,75,7]                4
7.34d   active+clean                [23,46,73]         23 [23,46,56]             23
7.36a   active+clean                [40,32,8]          40 [40,32,44]             40

    PG가 active+clean 으로 이동하는 데 걸리는 시간은 PG와 OSD 수에 따라 다릅니다. 또한 잘못된 오브젝트 수는 mgr target_max_misplaced_ratio 에 설정된 값에 따라 달라집니다. target_max_misplaced_ratio 에 대해 설정된 값이 클수록 잘못된 객체 수가 증가하므로 모든 PG가 활성+clean 이 되는 데 시간이 더 오래 걸립니다.

  9. norebalance 플래그를 설정 해제합니다.

    구문

    ceph osd unset norebalance

  10. balancer 모듈을 다시 켭니다.

    구문

    ceph balancer on

balancer 모듈을 활성화하면 스토리지 클러스터의 CRUSH 규칙에 따라 PG를 원하는 OSD로 느리게 이동합니다. 균형을 조정하는 데 시간이 다소 걸릴 수 있지만 결국 완료됩니다.

1.9. Ceph Manager alerts 모듈 사용

Ceph Manager alerts 모듈을 사용하여 Red Hat Ceph Storage 클러스터 상태에 대한 간단한 경고 메시지를 이메일로 보낼 수 있습니다.

참고

이 모듈은 강력한 모니터링 솔루션이 될 수 없습니다. Ceph 클러스터 자체의 일부로 실행된다는 사실은 ceph-mgr 데몬 실패 시 경고가 전송되지 않도록 기본적으로 제한됩니다. 그러나 이 모듈은 기존 모니터링 인프라가 없는 환경에 존재하는 독립 실행형 클러스터에 유용할 수 있습니다.

사전 요구 사항

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

절차

  1. alerts 모듈을 활성화합니다.

    예제

    [root@host01 ~]# ceph mgr module enable alerts

  2. alerts 모듈이 활성화되었는지 확인합니다.

    예제

    [root@host01 ~]# ceph mgr module ls | more
{
    "always_on_modules": [
        "balancer",
        "crash",
        "devicehealth",
        "orchestrator_cli",
        "progress",
        "rbd_support",
        "status",
        "volumes"
    ],
    "enabled_modules": [
        "alerts",
        "dashboard",
        "pg_autoscaler",
        "nfs",
        "prometheus",
        "restful"
    ]

  3. SMTP(Simple Mail Transfer Protocol)를 구성합니다.

    구문

    ceph config set mgr mgr/alerts/smtp_host SMTP_SERVER
ceph config set mgr mgr/alerts/smtp_destination RECEIVER_EMAIL_ADDRESS
ceph config set mgr mgr/alerts/smtp_sender SENDER_EMAIL_ADDRESS

    예제

    [root@host01 ~]# ceph config set mgr mgr/alerts/smtp_host smtp.example.com
[root@host01 ~]# ceph config set mgr mgr/alerts/smtp_destination example@example.com
[root@host01 ~]# ceph config set mgr mgr/alerts/smtp_sender example2@example.com

  4. 선택 사항: 기본적으로 alerts 모듈은 SSL 및 포트 465를 사용합니다. 이를 변경하려면 smtp_ssl 을 false 로 설정합니다.

    구문

    ceph config set mgr mgr/alerts/smtp_ssl false
ceph config set mgr mgr/alerts/smtp_port PORT_NUMBER

    예제

    [root@host01 ~]# ceph config set mgr mgr/alerts/smtp_ssl false
[root@host01 ~]# ceph config set mgr mgr/alerts/smtp_port 587

  5. SMTP 서버에 인증합니다.

    구문

    ceph config set mgr mgr/alerts/smtp_user USERNAME
ceph config set mgr mgr/alerts/smtp_password PASSWORD

    예제

    [root@host01 ~]# ceph config set mgr mgr/alerts/smtp_user admin1234
[root@host01 ~]# ceph config set mgr mgr/alerts/smtp_password admin1234

  6. 선택 사항: 기본적으로 SMTP From name은 Ceph 입니다. 이를 변경하려면 smtp_from_name 매개 변수를 설정합니다.

    구문

    ceph config set mgr mgr/alerts/smtp_from_name CLUSTER_NAME

    예제

    [root@host01 ~]# ceph config set mgr mgr/alerts/smtp_from_name 'Ceph Cluster Test'

  7. 선택 사항: 기본적으로 alerts 모듈은 스토리지 클러스터의 상태를 1분마다 확인하고 클러스터 상태가 변경될 때 메시지를 보냅니다. 빈도를 변경하려면 interval 매개변수를 설정합니다.

    구문

    ceph config set mgr mgr/alerts/interval INTERVAL

    예제

    [root@host01 ~]# ceph config set mgr mgr/alerts/interval "5m"

    이 예에서는 간격이 5분으로 설정됩니다.

  8. 선택 사항: 즉시 경고를 보냅니다.

    예제

    [root@host01 ~]# ceph alerts send

추가 리소스

1.10. Ceph 관리자 크래시 모듈 사용

Ceph 관리자 크래시 모듈을 사용하면 데몬 크래시 덤프에 대한 정보를 수집하고 추가 분석을 위해 Red Hat Ceph Storage 클러스터에 저장할 수 있습니다.

기본적으로 데몬 크래시 덤프는 /var/lib/ceph/crash 에 덤프됩니다. crash dir 옵션을 사용하여 크래시 덤프를 구성할 수 있습니다. 크래시 디렉터리의 이름은 시간, 날짜 및 임의로 생성된 UUID로 지정되며, 동일한 crash_id 와 함께 메타데이터 파일 메타 및 최근 로그 파일을 포함합니다.

ceph-crash.service 를 사용하여 이러한 충돌을 자동으로 제출하고 Ceph 모니터에서 유지할 수 있습니다. ceph-crash.service 는 crashdump 디렉터리를 감시하고 ceph 크래시 포스트 로 업로드합니다.

RECENT_CRASH heath 메시지는 Ceph 클러스터에서 가장 일반적인 상태 메시지 중 하나입니다. 이 상태 메시지는 하나 이상의 Ceph 데몬이 최근에 충돌했으며, 충돌이 아직 보관 또는 승인되지 않았음을 의미합니다. 이는 소프트웨어 버그, 오류가 발생한 디스크 등의 하드웨어 문제 또는 기타 일부 문제를 나타낼 수 있습니다. 옵션은 mgr/crash/warn_recent_interval 이 최근에 의미하는 시간을 제어합니다. 기본값은 2주입니다. 다음 명령을 실행하여 경고를 비활성화할 수 있습니다.

예제

[root@mon ~]# ceph config set mgr/crash/warn_recent_interval 0

mgr/crash/retain_interval 옵션은 충돌 보고서를 자동으로 제거하기 전에 유지하려는 기간을 제어합니다. 이 옵션의 기본값은 1년입니다.

사전 요구 사항

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

절차

  1. crash 모듈이 활성화되었는지 확인합니다.

    예제

    [root@mon ~]# ceph mgr module ls | more
{
    "always_on_modules": [
        "balancer",
        "crash",
        "devicehealth",
        "orchestrator_cli",
        "progress",
        "rbd_support",
        "status",
        "volumes"
    ],
    "enabled_modules": [
        "dashboard",
        "pg_autoscaler",
        "prometheus"
    ]

  2. 크래시 덤프를 저장합니다. 메타데이터 파일은 크래시 dir에 메타 형식으로 저장된 JSON Blob입니다. stdin에서 읽는 ceph 명령 -i - 옵션을 호출할 수 있습니다.

    예제

    [root@mon ~]# ceph crash post -i meta

  3. 새로운 및 아카이브의 모든 크래시 정보에 대한 타임스탬프 또는 UUID 충돌 ID를 나열합니다.

    예제

    [root@mon ~]# ceph crash ls

  4. 모든 새로운 충돌 정보에 대한 타임스탬프 또는 UUID 충돌 ID를 나열합니다.

    예제

    [root@mon ~]# ceph crash ls-new

  5. 모든 새로운 충돌 정보에 대한 타임스탬프 또는 UUID 충돌 ID를 나열합니다.

    예제

    [root@mon ~]# ceph crash ls-new

  6. 기간별로 그룹화된 저장된 충돌 정보 요약을 나열합니다.

    예제

    [root@mon ~]# ceph crash stat
8 crashes recorded
8 older than 1 days old:
2021-05-20T08:30:14.533316Z_4ea88673-8db6-4959-a8c6-0eea22d305c2
2021-05-20T08:30:14.590789Z_30a8bb92-2147-4e0f-a58b-a12c2c73d4f5
2021-05-20T08:34:42.278648Z_6a91a778-bce6-4ef3-a3fb-84c4276c8297
2021-05-20T08:34:42.801268Z_e5f25c74-c381-46b1-bee3-63d891f9fc2d
2021-05-20T08:34:42.803141Z_96adfc59-be3a-4a38-9981-e71ad3d55e47
2021-05-20T08:34:42.830416Z_e45ed474-550c-44b3-b9bb-283e3f4cc1fe
2021-05-24T19:58:42.549073Z_b2382865-ea89-4be2-b46f-9a59af7b7a2d
2021-05-24T19:58:44.315282Z_1847afbc-f8a9-45da-94e8-5aef0738954e

  7. 저장된 충돌의 세부 정보를 확인합니다.

    구문

    ceph crash info CRASH_ID

    예제

    [root@mon ~]# ceph crash info 2021-05-24T19:58:42.549073Z_b2382865-ea89-4be2-b46f-9a59af7b7a2d
{
    "assert_condition": "session_map.sessions.empty()",
    "assert_file": "/builddir/build/BUILD/ceph-16.1.0-486-g324d7073/src/mon/Monitor.cc",
    "assert_func": "virtual Monitor::~Monitor()",
    "assert_line": 287,
    "assert_msg": "/builddir/build/BUILD/ceph-16.1.0-486-g324d7073/src/mon/Monitor.cc: In function 'virtual Monitor::~Monitor()' thread 7f67a1aeb700 time 2021-05-24T19:58:42.545485+0000\n/builddir/build/BUILD/ceph-16.1.0-486-g324d7073/src/mon/Monitor.cc: 287: FAILED ceph_assert(session_map.sessions.empty())\n",
    "assert_thread_name": "ceph-mon",
    "backtrace": [
        "/lib64/libpthread.so.0(+0x12b30) [0x7f679678bb30]",
        "gsignal()",
        "abort()",
        "(ceph::__ceph_assert_fail(char const*, char const*, int, char const*)+0x1a9) [0x7f6798c8d37b]",
        "/usr/lib64/ceph/libceph-common.so.2(+0x276544) [0x7f6798c8d544]",
        "(Monitor::~Monitor()+0xe30) [0x561152ed3c80]",
        "(Monitor::~Monitor()+0xd) [0x561152ed3cdd]",
        "main()",
        "__libc_start_main()",
        "_start()"
    ],
    "ceph_version": "14.1.0-486.el8cp",
    "crash_id": "2021-05-24T19:58:42.549073Z_b2382865-ea89-4be2-b46f-9a59af7b7a2d",
    "entity_name": "mon.ceph-adm4",
    "os_id": "rhel",
    "os_name": "Red Hat Enterprise Linux",
    "os_version": "8.3 (Ootpa)",
    "os_version_id": "8.3",
    "process_name": "ceph-mon",
    "stack_sig": "957c21d558d0cba4cee9e8aaf9227b3b1b09738b8a4d2c9f4dc26d9233b0d511",
    "timestamp": "2021-05-24T19:58:42.549073Z",
    "utsname_hostname": "host02",
    "utsname_machine": "x86_64",
    "utsname_release": "4.18.0-240.15.1.el8_3.x86_64",
    "utsname_sysname": "Linux",
    "utsname_version": "#1 SMP Wed Feb 3 03:12:15 EST 2021"
}

  8. KEEP 일보다 오래된 저장된 크래시 제거: 여기서 KEEP 는 정수여야 합니다.

    구문

    ceph crash prune KEEP

    예제

    [root@mon ~]# ceph crash prune 60

  9. 충돌 보고서를 보관하여 더 이상 RECENT_CRASH 상태 점검으로 간주되지 않고 충돌 ls-new 출력에 표시되지 않도록 합니다. 이는 충돌 ls 에 나타납니다.

    구문

    ceph crash archive CRASH_ID

    예제

    [root@mon ~]# ceph crash archive 2021-05-24T19:58:42.549073Z_b2382865-ea89-4be2-b46f-9a59af7b7a2d

  10. 모든 크래시 보고서를 보관합니다.

    예제

    [root@mon ~]# ceph crash archive-all

  11. 크래시 덤프 제거:

    구문

    ceph crash rm CRASH_ID

    예제

    [root@mon ~]# ceph crash rm 2021-05-24T19:58:42.549073Z_b2382865-ea89-4be2-b46f-9a59af7b7a2d

추가 리소스

1.11. RBD 미러링 데몬 마이그레이션

베어 메탈 스토리지 클러스터에서 명령줄 인터페이스를 사용하여 구성된 양방향 블록 장치(RBD) 미러링의 경우 클러스터는 RBD 미러링을 마이그레이션하지 않습니다. 스토리지 클러스터를 업그레이드하거나 클러스터를 컨테이너로 변환하기 전에 RBD 미러 데몬을 CLI에서 Ceph-Ansible로 마이그레이션합니다.

사전 요구 사항

  • 실행 중인 Red Hat Ceph Storage 컨테이너화되지 않은 베어 메탈, 클러스터.
  • Ansible 관리 노드에 대한 액세스.
  • ansible 사용자 계정.
  • ansible 사용자 계정에 대한 sudo 액세스 권한.

절차

  1. Ceph 클라이언트 노드에서 사용자를 생성합니다.

    구문

    ceph auth get client.PRIMARY_CLUSTER_NAME -o /etc/ceph/ceph.PRIMARY_CLUSTER_NAME.keyring

    예제

    [root@rbd-client-site-a ~]# ceph auth get client.rbd-mirror.site-a -o /etc/ceph/ceph.client.rbd-mirror.site-a.keyring

  2. /etc/ceph 디렉토리의 auth 파일의 사용자 이름을 변경합니다.

    예제

    [client.rbd-mirror.rbd-client-site-a]
    key = AQCbKbVg+E7POBAA7COSZCodvOrg2LWIFc9+3g==
    caps mds = "allow *"
    caps mgr = "allow *"
    caps mon = "allow *"
    caps osd = "allow *"

  3. 인증 파일을 가져와 관련 권한을 추가합니다.

    구문

    ceph auth import -i PATH_TO_KEYRING

    예제

    [root@rbd-client-site-a ~]# ceph auth import -i /etc/ceph/ceph.client.rbd-mirror.rbd-client-site-a.keyring

  4. RBD 미러 노드의 서비스 이름을 확인합니다.

    예제

    [root@rbd-client-site-a ~]# systemctl list-units --all

systemctl stop ceph-rbd-mirror@rbd-client-site-a.service
systemctl disable ceph-rbd-mirror@rbd-client-site-a.service
systemctl reset-failed ceph-rbd-mirror@rbd-client-site-a.service
systemctl start ceph-rbd-mirror@rbd-mirror.rbd-client-site-a.service
systemctl enable ceph-rbd-mirror@rbd-mirror.rbd-client-site-a.service
systemctl status ceph-rbd-mirror@rbd-mirror.rbd-client-site-a.service

  5. rbd-mirror 노드를 /etc/ansible/hosts 파일에 추가합니다.

    예제

    [rbdmirrors]
ceph.client.rbd-mirror.rbd-client-site-a

1.12. 추가 리소스

2장. 디스크 오류 처리

스토리지 관리자는 스토리지 클러스터 수명 동안 일정 시점에서 디스크 오류를 처리해야 합니다. 실제 오류가 발생하기 전에 디스크 오류를 테스트하고 시뮬레이션하면 실제 일이 발생할 때 대비할 수 있습니다.

다음은 실패한 디스크를 교체하는 상위 수준 워크플로입니다.

  1. 실패한 OSD를 찾습니다.
  2. OSD 제거.
  3. 노드에서 OSD 데몬을 중지합니다.
  4. Ceph 상태를 확인합니다.
  5. CRUSH 맵에서 OSD를 제거합니다.
  6. OSD 권한 부여를 삭제합니다.
  7. 스토리지 클러스터에서 OSD를 제거합니다.
  8. 노드에서 파일 시스템을 마운트 해제합니다.
  9. 실패한 드라이브를 바꿉니다.
  10. OSD를 스토리지 클러스터에 다시 추가합니다.
  11. Ceph 상태를 확인합니다.

2.1. 사전 요구 사항

  • 실행 중인 Red Hat Ceph Storage 클러스터.
  • 오류가 발생한 디스크.

2.2. 디스크 오류

Ceph는 내결함성을 위해 설계되었습니다. 즉, 데이터를 손실하지 않고 Ceph가 성능이 저하된 상태에서 작동할 수 있습니다. 데이터 스토리지 드라이브가 실패해도 Ceph가 계속 작동할 수 있습니다. 성능이 저하된 상태는 다른 OSD에 저장된 추가 데이터 사본이 스토리지 클러스터의 다른 OSD로 자동으로 다시 입력됨을 의미합니다. OSD가 아래로 표시되면 드라이브가 실패할 수 있습니다.

드라이브에 오류가 발생하면 초기에 OSD 상태가 다운 되지만 스토리지 클러스터에서는 여전히 OSD 상태가 중지 됩니다. 네트워킹 문제가 실제로 작동 중이더라도 OSD를 다운 상태로 표시할 수도 있습니다. 먼저 환경의 네트워크 문제를 확인합니다. 네트워킹이 확인되면 OSD 드라이브가 실패할 가능성이 큽니다.

최신 서버는 일반적으로 핫 스왑 가능 드라이브로 배포하므로 오류가 발생한 드라이브를 가져와 노드를 중단하지 않고 새 드라이브로 교체할 수 있습니다. 그러나 Ceph를 사용하면 OSD의 소프트웨어 정의 부분도 제거해야 합니다.

2.3. 디스크 오류 시뮬레이션

하드 및 소프트의 두 가지 디스크 장애 시나리오가 있습니다. 하드 오류는 디스크를 교체합니다. 소프트 오류는 장치 드라이버 또는 일부 다른 소프트웨어 구성 요소에 문제가 될 수 있습니다.

소프트 오류의 경우 디스크 교체가 필요하지 않을 수 있습니다. 디스크를 교체하는 경우 오류가 발생한 디스크를 제거하고 Ceph에 대체 디스크를 추가하려면 단계를 따라야 합니다. 소프트 디스크 오류를 시뮬레이션하기 위해 가장 좋은 방법은 장치를 삭제하는 것입니다. 장치를 선택하고 시스템에서 장치를 삭제합니다.

사전 요구 사항

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

절차

  1. sysfs 에서 블록 장치 제거 :

    구문

    echo 1 > /sys/block/BLOCK_DEVICE/device/delete

    예제

    [root@osd ~]# echo 1 > /sys/block/sdb/device/delete

    Ceph OSD 로그의 OSD 노드에서 Ceph는 오류를 감지하고 복구 프로세스를 자동으로 시작했습니다.

    예제

    [root@osd ~]# tail -50 /var/log/ceph/ceph-osd.1.log
2020-09-02 15:50:50.187067 7ff1ce9a8d80  1 bdev(0x563d263d4600 /var/lib/ceph/osd/ceph-2/block) close
2020-09-02 15:50:50.440398 7ff1ce9a8d80 -1 osd.2 0 OSD:init: unable to mount object store
2020-09-02 15:50:50.440416 7ff1ce9a8d80 -1 ^[[0;31m ** ERROR: osd init failed: (5) Input/output error^[[0m
2020-09-02 15:51:10.633738 7f495c44bd80  0 set uid:gid to 167:167 (ceph:ceph)
2020-09-02 15:51:10.633752 7f495c44bd80  0 ceph version 12.2.12-124.el7cp (e8948288b90d312c206301a9fcf80788fbc3b1f8) luminous (stable), process ceph-osd, pid 36209
2020-09-02 15:51:10.634703 7f495c44bd80 -1 bluestore(/var/lib/ceph/osd/ceph-2/block) _read_bdev_label failed to read from /var/lib/ceph/osd/ceph-2/block: (5) Input/output error
2020-09-02 15:51:10.635749 7f495c44bd80 -1 bluestore(/var/lib/ceph/osd/ceph-2/block) _read_bdev_label failed to read from /var/lib/ceph/osd/ceph-2/block: (5) Input/output error
2020-09-02 15:51:10.636642 7f495c44bd80 -1 bluestore(/var/lib/ceph/osd/ceph-2/block) _read_bdev_label failed to read from /var/lib/ceph/osd/ceph-2/block: (5) Input/output error
2020-09-02 15:51:10.637535 7f495c44bd80 -1 bluestore(/var/lib/ceph/osd/ceph-2/block) _read_bdev_label failed to read from /var/lib/ceph/osd/ceph-2/block: (5) Input/output error
2020-09-02 15:51:10.641256 7f495c44bd80  0 pidfile_write: ignore empty --pid-file
2020-09-02 15:51:10.669317 7f495c44bd80  0 load: jerasure load: lrc load: isa
2020-09-02 15:51:10.669387 7f495c44bd80  1 bdev create path /var/lib/ceph/osd/ceph-2/block type kernel
2020-09-02 15:51:10.669395 7f495c44bd80  1 bdev(0x55a423da9200 /var/lib/ceph/osd/ceph-2/block) open path /var/lib/ceph/osd/ceph-2/block
2020-09-02 15:51:10.669611 7f495c44bd80  1 bdev(0x55a423da9200 /var/lib/ceph/osd/ceph-2/block) open size 500103643136 (0x7470800000, 466GiB) block_size 4096 (4KiB) rotational
2020-09-02 15:51:10.670320 7f495c44bd80 -1 bluestore(/var/lib/ceph/osd/ceph-2/block) _read_bdev_label failed to read from /var/lib/ceph/osd/ceph-2/block: (5) Input/output error
2020-09-02 15:51:10.670328 7f495c44bd80  1 bdev(0x55a423da9200 /var/lib/ceph/osd/ceph-2/block) close
2020-09-02 15:51:10.924727 7f495c44bd80  1 bluestore(/var/lib/ceph/osd/ceph-2) _mount path /var/lib/ceph/osd/ceph-2
2020-09-02 15:51:10.925582 7f495c44bd80 -1 bluestore(/var/lib/ceph/osd/ceph-2/block) _read_bdev_label failed to read from /var/lib/ceph/osd/ceph-2/block: (5) Input/output error
2020-09-02 15:51:10.925628 7f495c44bd80  1 bdev create path /var/lib/ceph/osd/ceph-2/block type kernel
2020-09-02 15:51:10.925630 7f495c44bd80  1 bdev(0x55a423da8600 /var/lib/ceph/osd/ceph-2/block) open path /var/lib/ceph/osd/ceph-2/block
2020-09-02 15:51:10.925784 7f495c44bd80  1 bdev(0x55a423da8600 /var/lib/ceph/osd/ceph-2/block) open size 500103643136 (0x7470800000, 466GiB) block_size 4096 (4KiB) rotational
2020-09-02 15:51:10.926549 7f495c44bd80 -1 bluestore(/var/lib/ceph/osd/ceph-2/block) _read_bdev_label failed to read from /var/lib/ceph/osd/ceph-2/block: (5) Input/output error

  2. Ceph OSD 디스크 트리를 보면 디스크가 오프라인 상태인지 확인할 수 있습니다.

    예제

    [root@osd ~]# ceph osd tree
ID WEIGHT  TYPE NAME      UP/DOWN REWEIGHT PRIMARY-AFFINITY
-1 0.28976 root default
-2 0.09659     host ceph3
 1 0.09659         osd.1       down 1.00000          1.00000
-3 0.09659     host ceph1
 2 0.09659         osd.2       up  1.00000          1.00000
-4 0.09659     host ceph2
 0 0.09659         osd.0       up  1.00000          1.00000

2.4. 실패한 OSD 디스크 교체

OSD를 교체하는 일반적인 절차에는 스토리지 클러스터에서 OSD를 제거하고 드라이브를 교체한 다음 OSD를 다시 생성해야 합니다.

사전 요구 사항

  • 실행 중인 Red Hat Ceph Storage 클러스터.
  • 오류가 발생한 디스크.

절차

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

    [root@mon ~]# ceph health

  2. CRUSH 계층 구조에서 OSD 위치를 식별합니다. 

    [root@mon ~]# ceph osd tree | grep -i down

  3. OSD 노드에서 OSD를 시작합니다.

    구문

    systemctl start ceph-osd@OSD_ID

    명령에서 OSD가 이미 실행 중임을 나타내는 경우 하트비트 또는 네트워킹 문제가 있을 수 있습니다. OSD를 다시 시작할 수 없는 경우 드라이브가 실패할 수 있습니다.

    참고

    OSD가 다운 되면 OSD가 결국 표시됩니다. 이는 Ceph Storage의 정상적인 동작입니다. OSD가 표시되지 않으면 실패한 OSD 데이터 복사본이 있는 기타 OSD가 스토리지 클러스터 내에 필요한 복사본 수가 있는지 확인하기 위해 백필을 시작합니다. 스토리지 클러스터가 백필되는 동안 클러스터가 저하된 상태가 됩니다.

  4. Ceph의 컨테이너화된 배포의 경우 OSD_ID 를 사용하여 OSD 컨테이너를 시작합니다.

    구문

    systemctl start ceph-osd@OSD_ID

    명령에서 OSD가 이미 실행 중임을 나타내는 경우 하트비트 또는 네트워킹 문제가 있을 수 있습니다. OSD를 다시 시작할 수 없는 경우 드라이브가 실패할 수 있습니다.

    참고

  5. 실패한 OSD 마운트 지점을 확인합니다.

    참고

    Ceph 컨테이너 배포의 경우 OSD가 다운되고 OSD 드라이브가 마운트 해제되므로 run df 를 실행하여 마운트 지점을 확인할 수 없습니다. 다른 방법을 사용하여 OSD 드라이브가 실패했는지 확인합니다. 예를 들어 컨테이너 노드의 드라이브에서 smartctl 을 실행합니다. 

    [root@osd ~]# df -h

    OSD를 다시 시작할 수 없는 경우 마운트 지점을 확인할 수 있습니다. 마운트 지점이 더 이상 나타나지 않으면 OSD 드라이브를 다시 마운트하고 OSD를 다시 시작할 수 있습니다. 마운트 지점을 복원할 수 없는 경우 OSD 드라이브가 실패할 수 있습니다.

    smartctl utility cab를 사용하여 드라이브가 정상인지 확인하는 데 도움이 됩니다.

    구문

    yum install smartmontools
smartctl -H /dev/BLOCK_DEVICE

    예제

    [root@osd ~]# smartctl -H /dev/sda

    드라이브가 실패한 경우 이를 교체해야 합니다.

  6. OSD 프로세스를 중지합니다.

    구문

    systemctl stop ceph-osd@OSD_ID

  7. Ceph의 컨테이너화된 배포의 경우 OSD 컨테이너를 중지합니다.

    구문

    systemctl stop ceph-osd@OSD_ID

  8. 스토리지 클러스터에서 OSD를 제거합니다.

    구문

    ceph osd out OSD_ID

  9. 실패한 OSD가 다시 입력되었는지 확인합니다. 

    [root@osd ~]# ceph -w

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

    구문

    ceph osd crush remove osd.OSD_ID

    참고

    이 단계는 OSD를 영구적으로 제거하고 재배포하지 않는 경우에만 필요합니다.

  11. OSD의 인증 키를 제거합니다.

    구문

    ceph auth del osd.OSD_ID

  12. OSD 키가 나열되지 않았는지 확인합니다.

    예제

    [root@osd ~]# ceph auth list

  13. 스토리지 클러스터에서 OSD를 제거합니다.

    구문

    ceph osd rm osd.OSD_ID

  14. 실패한 드라이브 경로를 마운트 해제합니다.

    구문

    umount /var/lib/ceph/osd/CLUSTER_NAME-OSD_ID

    예제

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

    참고

    Ceph의 컨테이너화된 배포의 경우 OSD가 다운되고 OSD 드라이브가 마운트 해제됩니다. 이 경우 마운트 해제할 항목이 없으며 이 단계를 건너뛸 수 있습니다.

  15. 물리적 드라이브를 교체하십시오. 노드의 하드웨어 벤더 설명서를 참조하십시오. 드라이브를 핫 스왑할 수 있는 경우 오류가 발생한 드라이브를 새 드라이브로 바꾸기만 하면 됩니다. 드라이브가 핫 스왑할 수 없고 노드에 여러 OSD가 포함된 경우, 노드를 중단하여 실제 드라이브를 교체해야 합니다. 노드를 일시적으로 중단해야 하는 경우 백필을 방지하기 위해 클러스터를 noout 으로 설정할 수 있습니다.

    예제

    [root@osd ~]# ceph osd set noout

    드라이브를 교체하고 노드와 OSD를 다시 온라인 상태가 되면, noout 설정을 제거하십시오.

    예제

    [root@osd ~]# ceph osd unset noout

    계속 진행하기 전에 새 드라이브가 /dev/ 디렉터리에 표시되도록 허용하고 드라이브 경로를 기록합니다.

  16. OSD 드라이브를 찾아서 디스크를 포맷합니다.

  17. OSD를 다시 생성합니다.

    1. Ceph Ansible 사용.
    2. 명령줄 인터페이스 사용.

  18. CRUSH 계층 구조를 확인하여 정확한지 확인합니다.

    예제

    [root@osd ~]# ceph osd tree

    CRUSH 계층 구조의 OSD 위치에 만족하지 않으면 move 명령으로 이동할 수 있습니다.

    구문

    ceph osd crush move BUCKET_TO_MOVE BUCKET_TYPE=PARENT_BUCKET

  19. OSD가 온라인 상태인지 확인합니다.

2.5. OSD ID를 유지하면서 OSD 드라이브 교체

실패한 OSD 드라이브를 교체하는 경우 원래 OSD ID와 CRUSH 맵 항목을 유지할 수 있습니다.

참고

ceph-volume lvm 명령의 기본값은 OSD의 BlueStore입니다.

사전 요구 사항

  • 실행 중인 Red Hat Ceph Storage 클러스터.
  • 오류가 발생한 디스크.

절차

  1. OSD를 삭제합니다.

    구문

    ceph osd destroy OSD_ID --yes-i-really-mean-it

    예제

    [root@osd ~]# ceph osd destroy 1 --yes-i-really-mean-it

  2. 교체 디스크를 이전에 사용한 경우 선택적으로 디스크를 zap 해야 합니다.

    구문

    ceph-volume lvm zap DEVICE

    예제

    [root@osd ~]# ceph-volume lvm zap /dev/sdb

    참고

    ceph osd 트리,ceph osd 메타데이터 및 df 와 같은 다양한 명령의 출력을 비교하여 DEVICE 를 찾을 수 있습니다.

  3. 기존 OSD ID를 사용하여 새 OSD를 생성합니다.

    구문

    ceph-volume lvm create --osd-id OSD_ID --data DEVICE

    예제

    [root@mon ~]# ceph-volume lvm create --osd-id 1 --data /dev/sdb

추가 리소스

3장. 노드 오류 처리

스토리지 관리자는 스토리지 클러스터 내에서 전체 노드가 실패할 수 있으며 노드 오류를 처리하는 것은 디스크 오류를 처리하는 것과 유사합니다. 노드 장애가 발생하면 Ceph 복구 배치 그룹(PG) 대신 하나의 디스크에 대해서만 배치 그룹(PG)을 복구해야 합니다. Ceph에서 OSD가 모두 다운되었음을 감지하고 자동 복구라는 복구 프로세스를 자동으로 시작합니다.

노드 장애 시나리오는 세 가지입니다. 다음은 노드를 교체할 때 각 시나리오에 대한 상위 수준 워크플로입니다.

  • 노드 교체는 하지만 오류가 발생한 노드에서 root 및 Ceph OSD 디스크를 사용합니다.

    1. 백필을 비활성화합니다.
    2. 노드를 교체하여 이전 노드에서 디스크를 가져와 새 노드에 추가합니다.
    3. 백필을 활성화합니다.

  • 노드를 교체하고 운영 체제를 다시 설치하고 실패한 노드에서 Ceph OSD 디스크를 사용합니다.

    1. 백필을 비활성화합니다.
    2. Ceph 구성의 백업을 만듭니다.

    3. 노드를 교체하고 실패한 노드에서 Ceph OSD 디스크를 추가합니다.

      1. 디스크를 JBOD로 구성.
    4. 운영 체제를 설치합니다.
    5. Ceph 구성을 복원합니다.
    6. ceph-ansible 을 실행합니다.
    7. 백필을 활성화합니다.

  • 노드를 교체하고 운영 체제를 다시 설치하고 모든 새 Ceph OSD 디스크를 사용합니다.

    1. 백필을 비활성화합니다.
    2. 스토리지 클러스터에서 장애가 발생한 노드의 모든 OSD를 제거합니다.
    3. Ceph 구성의 백업을 만듭니다.

    4. 노드를 교체하고 실패한 노드에서 Ceph OSD 디스크를 추가합니다.

      1. 디스크를 JBOD로 구성.
    5. 운영 체제를 설치합니다.
    6. ceph-ansible 을 실행합니다.
    7. 백필을 활성화합니다.

3.1. 사전 요구 사항

  • 실행 중인 Red Hat Ceph Storage 클러스터.
  • 실패한 노드.

3.2. 노드를 추가하거나 제거하기 전에 고려해야 할 사항

Ceph의 뛰어난 기능 중 하나는 런타임에 Ceph OSD 노드를 추가하거나 제거하는 기능입니다. 즉, 스토리지 클러스터를 중단하지 않고도 스토리지 클러스터 용량의 크기를 조정하거나 하드웨어를 교체할 수 있습니다.

스토리지 클러스터가 성능이 저하된 상태에서 Ceph 클라이언트에 서비스를 제공하는 기능도 작동할 수 있습니다. 예를 들어, 시간 초과 또는 주말을 작업하는 대신 정규 업무 시간 동안 하드웨어를 추가하거나 제거할 수 있습니다. 그러나 Ceph OSD 노드를 추가하고 제거하면 성능에 큰 영향을 미칠 수 있습니다.

Ceph OSD 노드를 추가하거나 제거하기 전에 스토리지 클러스터 성능에 미치는 영향을 고려하십시오.

  • 스토리지 클러스터 용량을 확장하거나 줄이는지 여부에 따라 Ceph OSD 노드를 추가하거나 제거하면 스토리지 클러스터 리밸런싱으로 백필이 발생합니다. 이 리밸런싱 기간 동안 Ceph는 추가 리소스를 사용하므로 스토리지 클러스터 성능에 영향을 줄 수 있습니다.
  • 프로덕션 Ceph 스토리지 클러스터에서 Ceph OSD 노드에는 특정 유형의 스토리지 전략을 용이하게 하는 특정 하드웨어 구성이 있습니다.
  • Ceph OSD 노드는 CRUSH 계층 구조의 일부이므로 노드를 추가하거나 제거하는 성능에는 일반적으로 CRUSH 규칙을 사용하는 풀의 성능에 영향을 미칩니다.

추가 리소스

3.3. 성능 고려 사항

다음 요소는 일반적으로 Ceph OSD 노드를 추가하거나 제거할 때 스토리지 클러스터의 성능에 영향을 미칩니다.

  • Ceph 클라이언트는 I/O 인터페이스에 로드를 Ceph에 배치합니다. 즉, 클라이언트가 풀에 로드를 배치합니다. 풀은 CRUSH 규칙 세트에 매핑됩니다. 기본 CRUSH 계층 구조를 통해 Ceph는 장애 도메인에 데이터를 배치할 수 있습니다. 기본 Ceph OSD 노드에 클라이언트 부하가 높은 풀이 포함된 경우 클라이언트 로드가 복구 시간에 크게 영향을 미치고 성능을 저하시킬 수 있습니다. 쓰기 작업에 내구성을 위해 데이터 복제가 필요하므로 쓰기 집약적 클라이언트 로드가 특히 스토리지 클러스터를 복구하는 데 걸리는 시간이 증가할 수 있습니다.
  • 일반적으로 추가하거나 제거하는 용량은 스토리지 클러스터의 복구 시간에 영향을 미칩니다. 또한 추가하거나 제거하는 노드의 스토리지 밀도가 복구 시간에 영향을 줄 수 있습니다. 예를 들어 OSD가 36개인 노드는 일반적으로 OSD가 12개인 노드보다 복구하는 데 시간이 오래 걸립니다.
  • 노드를 제거할 때는 예비 용량이 충분하여 전체 비율 또는 거의 전체 비율에 도달하지 않도록 해야 합니다. 스토리지 클러스터가 전체 비율에 도달하면 Ceph에서 쓰기 작업을 일시 중단하여 데이터 손실을 방지합니다.
  • Ceph OSD 노드는 하나 이상의 Ceph CRUSH 계층 구조에 매핑되며 계층 구조는 하나 이상의 풀에 매핑됩니다. CRUSH 규칙 세트를 사용하는 각 풀에는 Ceph OSD 노드를 추가하거나 제거할 때 성능에 영향을 미칩니다.
  • 복제 풀은 더 많은 네트워크 대역폭을 사용하여 데이터의 심층 복사본을 복제하는 경향이 있지만, 이레이저 코딩 풀은 더 많은 CPU를 사용하여 k+m 코딩 청크를 계산하는 경향이 있습니다. 데이터에 대한 복사본이 많을수록 스토리지 클러스터를 복구하는 데 시간이 오래 걸립니다. 예를 들어, 더 큰 풀 또는 k+m 청크 수가 더 많은 경우 동일한 데이터의 복사본이 적은 복제 풀보다 복구하는 데 시간이 더 오래 걸립니다.
  • 드라이브, 컨트롤러 및 네트워크 인터페이스 카드는 모두 복구 시간에 영향을 줄 수 있는 처리량 특성을 갖습니다. 일반적으로 처리량이 높은 10Gbps 및 SSD와 같은 노드는 처리량이 낮은 노드(예: 1Gbps 및 SATA 드라이브)보다 빠르게 복구됩니다.

3.4. 노드 추가 또는 제거 권장 사항

Red Hat은 노드 내에서 한 번에 하나의 OSD를 추가하거나 제거하고 다음 OSD로 진행하기 전에 스토리지 클러스터를 복구할 것을 권장합니다. 이렇게 하면 스토리지 클러스터 성능에 미치는 영향을 최소화하는 데 도움이 됩니다. 노드에 오류가 발생하면 한 번에 하나의 OSD 대신 전체 노드를 한 번에 변경해야 할 수 있습니다.

OSD를 제거하려면 다음을 수행합니다.

OSD를 추가하려면 다음을 수행합니다.

Ceph OSD 노드를 추가하거나 제거할 때 다른 진행 중인 프로세스도 스토리지 클러스터 성능에 영향을 미칩니다. 클라이언트 I/O에 미치는 영향을 줄이기 위해 Red Hat은 다음을 권장합니다.

용량 계산

Ceph OSD 노드를 제거하기 전에 스토리지 클러스터가 전체 비율에 도달하지 않고 모든 OSD의 콘텐츠를 백필할 수 있는지 확인합니다. 전체 비율에 도달하면 스토리지 클러스터가 쓰기 작업을 거부합니다.

일시적으로 스크럽 비활성화

스크럽은 스토리지 클러스터 데이터의 내구성을 보장하는 데 필수적이지만 리소스 집약적입니다. Ceph OSD 노드를 추가하거나 제거하기 전에 스크럽 및 심층 스크럽을 비활성화하고 진행하기 전에 현재 스크럽 작업을 완료하도록 합니다. 

ceph osd_set_noscrub
ceph osd_set_nodeep-scrub

Ceph OSD 노드를 추가하거나 제거하고 스토리지 클러스터가 active+clean 상태로 반환되면 noscrub 및 nodeep-scrub 설정을 설정 해제합니다.

백필 및 복구 제한

적절한 데이터 내구성이 있는 경우 성능이 저하된 상태에서 작동하는 데 아무런 문제가 없습니다. 예를 들어 osd_pool_default_ size = 3 및 osd_pool_default_min_size = 2 로 스토리지 클러스터를 작동할 수 있습니다. 가능한 가장 빠른 복구 시간을 위해 스토리지 클러스터를 조정할 수 있지만 Ceph 클라이언트 I/O 성능에 큰 영향을 미칩니다. 가장 높은 Ceph 클라이언트 I/O 성능을 유지하려면 백필 및 복구 작업을 제한하고 시간이 더 오래 걸릴 수 있습니다. 

osd_max_backfills = 1
osd_recovery_max_active = 1
osd_recovery_op_priority = 1

osd_recovery_sleep 과 같은 sleep 및 delay 매개 변수를 설정하는 것도 고려할 수 있습니다.

배치 그룹 수 증가

마지막으로 스토리지 클러스터 크기를 확장하는 경우 배치 그룹의 수를 늘려야 할 수 있습니다. 배치 그룹 수를 확장해야 한다고 판단되면 Red Hat은 배치 그룹 수를 점진적으로 늘리는 것이 좋습니다. 배치 그룹의 수를 상당한 금액으로 늘리면 성능이 상당히 저하됩니다.

참고

3.5. Ceph OSD 노드 추가

Red Hat Ceph Storage 클러스터의 용량을 확장하려면 OSD 노드를 추가합니다.

사전 요구 사항

절차

  1. 스토리지 클러스터의 다른 노드가 짧은 호스트 이름으로 새 노드에 연결할 수 있는지 확인합니다.

  2. 일시적으로 스크럽을 비활성화합니다.

    예제

    [root@mon ~]# ceph osd set noscrub
[root@mon ~]# ceph osd set nodeep-scrub

  3. 백필 및 복구 기능을 제한합니다.

    구문

    ceph tell DAEMON_TYPE.* injectargs --OPTION_NAME VALUE [--OPTION_NAME VALUE]

    예제

    [root@mon ~]# ceph tell osd.* injectargs --osd-max-backfills 1 --osd-recovery-max-active 1 --osd-recovery-op-priority 1

  4. CRUSH 맵에 새 노드를 추가합니다.

    구문

    ceph osd crush add-bucket BUCKET_NAME BUCKET_TYPE

    예제

    [root@mon ~]# ceph osd crush add-bucket node2 host

  5. 노드의 각 디스크에 OSD를 스토리지 클러스터에 추가합니다.

    • Ansible 사용.

    • 명령줄 인터페이스 사용.

      중요

      Red Hat Ceph Storage 클러스터에 OSD 노드를 추가할 때 노드 내에서 하나의 OSD를 추가하고 다음 OSD로 진행하기 전에 클러스터가 active+clean 상태로 복구되도록 하는 것이 좋습니다.

  6. 스크럽을 활성화합니다.

    구문

    ceph osd unset noscrub
ceph osd unset nodeep-scrub

  7. 백필 및 복구 기능을 기본값으로 설정합니다.

    구문

    ceph tell DAEMON_TYPE.* injectargs --OPTION_NAME VALUE [--OPTION_NAME VALUE]

    예제

    [root@mon ~]# ceph tell osd.* injectargs --osd-max-backfills 1 --osd-recovery-max-active 3 --osd-recovery-op-priority 3

추가 리소스

3.6. Ceph OSD 노드 제거

스토리지 클러스터의 용량을 줄이려면 OSD 노드를 제거합니다.

주의

Ceph OSD 노드를 제거하기 전에 스토리지 클러스터가 전체 비율에 도달하지 않고 모든 OSD의 콘텐츠를 백필할 수 있는지 확인합니다. 전체 비율에 도달하면 스토리지 클러스터가 쓰기 작업을 거부합니다.

사전 요구 사항

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

절차

  1. 스토리지 클러스터의 용량을 확인합니다.

    구문

    ceph df
rados df
ceph osd df

  2. 일시적으로 스크럽을 비활성화합니다.

    구문

    ceph osd set noscrub
ceph osd set nodeep-scrub

  3. 백필 및 복구 기능을 제한합니다.

    구문

    ceph tell DAEMON_TYPE.* injectargs --OPTION_NAME VALUE [--OPTION_NAME VALUE]

    예제

    [root@mon ~]# ceph tell osd.* injectargs --osd-max-backfills 1 --osd-recovery-max-active 1 --osd-recovery-op-priority 1

  4. 스토리지 클러스터에서 노드의 각 OSD를 제거합니다.

    • Ansible 사용.

    • 명령줄 인터페이스 사용.

      중요

      스토리지 클러스터에서 OSD 노드를 제거할 때 노드 내에서 하나의 OSD를 제거하고 다음 OSD를 제거하기 전에 클러스터가 active+clean 상태로 복구되도록 하는 것이 좋습니다.

      1. OSD를 제거한 후 스토리지 클러스터가 거의 전체 비율에 도달하지 않는지 확인합니다.

        구문

        ceph -s
ceph df

      2. 노드의 모든 OSD가 스토리지 클러스터에서 제거될 때까지 이 단계를 반복합니다.

  5. 모든 OSD가 제거되면 CRUSH 맵에서 호스트 버킷을 제거합니다.

    구문

    ceph osd crush rm BUCKET_NAME

    예제

    [root@mon ~]# ceph osd crush rm node2

  6. 스크럽을 활성화합니다.

    구문

    ceph osd unset noscrub
ceph osd unset nodeep-scrub

  7. 백필 및 복구 기능을 기본값으로 설정합니다.

    구문

    ceph tell DAEMON_TYPE.* injectargs --OPTION_NAME VALUE [--OPTION_NAME VALUE]

    예제

    [root@mon ~]# ceph tell osd.* injectargs --osd-max-backfills 1 --osd-recovery-max-active 3 --osd-recovery-op-priority 3

추가 리소스

3.7. 노드 오류 시뮬레이션

하드 노드 오류를 시뮬레이션하려면 노드의 전원을 끄고 운영 체제를 다시 설치합니다.

사전 요구 사항

  • 정상 실행 중인 Red Hat Ceph Storage 클러스터.
  • 스토리지 클러스터의 모든 노드에 대한 루트 수준의 액세스.

절차

  1. 스토리지 클러스터의 용량을 확인하여 노드 제거의 영향을 확인합니다.

    예제

    [root@ceph1 ~]# ceph df
[root@ceph1 ~]# rados df
[root@ceph1 ~]# ceph osd df

  2. 선택적으로 복구 및 백필을 비활성화합니다.

    예제

    [root@ceph1 ~]# ceph osd set noout
[root@ceph1 ~]# ceph osd set noscrub
[root@ceph1 ~]# ceph osd set nodeep-scrub

  3. 노드를 종료합니다.

  4. 호스트 이름을 변경하는 경우 CRUSH 맵에서 노드를 제거합니다.

    예제

    [root@ceph1 ~]# ceph osd crush rm ceph3

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

    예제

    [root@ceph1 ~]# ceph -s

  6. 노드에 운영 체제를 다시 설치합니다.

  7. Ansible 사용자를 추가하고 SSH 키를 생성합니다.

    예제

    [root@ceph3 ~]# useradd ansible
[root@ceph3 ~]# passwd ansible
[root@ceph3 ~]# cat << EOF > /etc/sudoers.d/ansible
ansible ALL = (root) NOPASSWD:ALL
Defaults:ansible !requiretty
EOF
[root@ceph3 ~]# su - ansible
[ansible@ceph3 ~]$ ssh-keygen

  8. Ansible 관리 노드에서 다시 설치된 노드에서 ansible 사용자의 SSH 키를 복사합니다. 

    [ansible@admin ~]$ ssh-copy-id ceph3

  9. Ansible 관리 노드에서 Ansible 플레이북을 다시 실행합니다.

    예제

    [ansible@admin ~]$ cd /usr/share/ceph-ansible
[ansible@admin ~]$ ansible-playbook site.yml -i hosts

PLAY RECAP ********************************************************************
ceph1                      : ok=368  changed=2    unreachable=0    failed=0
ceph2                      : ok=284  changed=0    unreachable=0    failed=0
ceph3                      : ok=284  changed=15   unreachable=0    failed=0

  10. 선택적으로 복구 및 백필을 활성화합니다.

    예제

    [root@ceph3 ~]# ceph osd unset noout
[root@ceph3 ~]# ceph osd unset noscrub
[root@ceph3 ~]# ceph osd unset nodeep-scrub

  11. Ceph의 상태를 확인합니다.

    예제

    [root@ceph3 ~]# ceph -s
    cluster 1e0c9c34-901d-4b46-8001-0d1f93ca5f4d
     health HEALTH_OK
     monmap e1: 3 mons at {ceph1=192.168.122.81:6789/0,ceph2=192.168.122.82:6789/0,ceph3=192.168.122.83:6789/0}
            election epoch 36, quorum 0,1,2 ceph1,ceph2,ceph3
     osdmap e95: 3 osds: 3 up, 3 in
            flags sortbitwise
      pgmap v1190: 152 pgs, 12 pools, 1024 MB data, 441 objects
            3197 MB used, 293 GB / 296 GB avail
                 152 active+clean

추가 리소스

4장. 데이터 센터 오류 처리

스토리지 관리자는 데이터 센터 장애 발생을 방지하기 위해 예방 조치를 취할 수 있습니다. 이러한 예방 조치에는 다음이 포함됩니다.

  • 데이터 센터 인프라 구성.
  • CRUSH 맵 계층 구조 내에서 장애 도메인 설정.
  • 도메인 내에서 오류 노드 지정.

4.1. 사전 요구 사항

  • 정상 실행 중인 Red Hat Ceph Storage 클러스터.
  • 스토리지 클러스터의 모든 노드에 대한 루트 수준의 액세스.

4.2. 데이터 센터 오류 방지

데이터 센터 인프라 구성

확장 클러스터 내의 각 데이터 센터는 로컬 기능 및 종속 항목을 반영하기 위해 다른 스토리지 클러스터 구성을 가질 수 있습니다. 데이터 센터 간 복제를 설정하여 데이터를 보존합니다. 한 데이터 센터에 오류가 발생하면 스토리지 클러스터의 다른 데이터 센터에 데이터 복사본이 포함됩니다.

CRUSH 맵 계층 구조 내에서 장애 도메인 설정

실패 또는 페일오버 도메인은 스토리지 클러스터 내 도메인의 중복 사본입니다. 활성 도메인이 실패하면 장애 도메인이 활성 도메인이 됩니다.

기본적으로 CRUSH 맵은 플랫 계층 구조 내의 스토리지 클러스터의 모든 노드를 나열합니다. 그러나 최상의 결과를 위해 CRUSH 맵 내에 논리적 계층 구조를 생성합니다. 계층 구조는 각 노드가 속한 도메인과 장애 도메인을 포함하여 스토리지 클러스터 내 해당 도메인 간의 관계를 지정합니다. 계층 구조 내에서 각 도메인의 장애 도메인을 정의하면 스토리지 클러스터의 안정성이 향상됩니다.

여러 데이터 센터가 포함된 스토리지 클러스터를 계획할 때 CRUSH 맵 계층 구조에 노드를 배치하여 하나의 데이터 센터가 다운되면 나머지 스토리지 클러스터가 가동되어 실행됩니다.

도메인 내에서 오류 노드 지정

스토리지 클러스터 내 데이터에 3방향 복제를 사용하려는 경우 장애 도메인 내의 노드 위치를 고려합니다. 데이터 센터 내에서 중단이 발생하는 경우 일부 데이터가 하나의 복사본에만 있을 수 있습니다. 이 시나리오가 발생하면 다음 두 가지 옵션이 있습니다.

  • 표준 설정을 사용하여 데이터를 읽기 전용 상태로 둡니다.
  • 정전 기간 동안 단 하나의 사본으로만 라이브.

표준 설정을 사용하고 노드에서 데이터 배치의 임의성 때문에 모든 데이터가 영향을 받는 것은 아니지만 일부 데이터는 하나의 복사본만 가질 수 있으며 스토리지 클러스터는 읽기 전용 모드로 되돌아갑니다. 그러나 일부 데이터가 하나의 복사본에만 있는 경우 스토리지 클러스터는 읽기 전용 모드로 돌아갑니다.

4.3. 데이터 센터 오류 처리

Red Hat Ceph Storage는 확장 클러스터에서 데이터 센터 중 하나를 분실하는 등 인프라 장애에 대처할 수 있습니다. 표준 오브젝트 저장소 사용 사례의 경우 세 개의 데이터 센터를 둘 간에 설정한 복제와 독립적으로 구성할 수 있습니다. 이 시나리오에서는 로컬 기능 및 종속성을 반영하여 각 데이터 센터의 스토리지 클러스터 구성이 다를 수 있습니다.

배치 계층 구조의 논리적 구조를 고려해야 합니다. 인프라 내에서 장애 도메인의 계층 구조를 반영하여 적절한 CRUSH 맵을 사용할 수 있습니다. 논리적 계층 구조 정의를 사용하면 표준 계층 구조 정의를 사용하는 대신 스토리지 클러스터의 안정성이 향상됩니다. 실패 도메인은 CRUSH 맵에 정의되어 있습니다. 기본 CRUSH 맵에는 플랫 계층 구조의 모든 노드가 포함됩니다. 확장 클러스터와 같은 3개의 데이터 센터 환경에서 하나의 데이터 센터가 다운될 수 있는 방식으로 노드 배치를 관리해야 하지만 스토리지 클러스터는 계속 가동되고 실행됩니다. 데이터에 3방향 복제를 사용할 때 노드가 상주하는 장애 도메인을 고려하십시오.

아래 예제에서는 6개의 OSD 노드가 있는 스토리지 클러스터의 초기 설정에서 결과 맵을 가져옵니다. 이 예제에서 모든 노드에는 하나의 디스크만 있으므로 OSD가 한 개만 있습니다. 모든 노드는 기본 루트, 즉 계층 구조 트리의 표준 루트에 따라 정렬됩니다. 2개의 OSD에 할당된 가중치가 있으므로 이러한 OSD에는 다른 OSD보다 더 적은 데이터 청크가 부여됩니다. 이러한 노드는 초기 OSD 디스크보다 큰 디스크가 나중에 도입되었습니다. 이는 노드 그룹의 실패를 견디도록 데이터 배치에는 영향을 미치지 않습니다.

예제

[root@mon ~]# ceph osd tree
ID WEIGHT  TYPE NAME           UP/DOWN REWEIGHT PRIMARY-AFFINITY
-1 0.33554 root default
-2 0.04779     host ceph-node3
 0 0.04779         osd.0            up  1.00000          1.00000
-3 0.04779     host ceph-node2
 1 0.04779         osd.1            up  1.00000          1.00000
-4 0.04779     host ceph-node1
 2 0.04779         osd.2            up  1.00000          1.00000
-5 0.04779     host ceph-node4
 3 0.04779         osd.3            up  1.00000          1.00000
-6 0.07219     host ceph-node6
 4 0.07219         osd.4            up  0.79999          1.00000
-7 0.07219     host ceph-node5
 5 0.07219         osd.5            up  0.79999          1.00000

논리적 계층적 정의를 사용하여 노드를 동일한 데이터 센터로 그룹화하면 데이터 배치 완성도를 달성할 수 있습니다. 루트,데이터센터,랙,행 및 호스트의 가능한 정의 유형을 사용하면 세 개의 데이터 센터에 대한 장애 도메인을 반영할 수 있습니다.

  • ceph-node1 및 ceph-node2 노드가 데이터 센터 1(DC1)에 상주합니다.
  • 노드 ceph-node3 및 ceph-node5는 DC2(데이터 센터 2)에 상주합니다.
  • ceph-node4 및 ceph-node6 노드가 데이터센터 3(DC3)에 상주합니다.
  • 모든 데이터 센터는 동일한 구조(모든 DC)에 속합니다.

호스트의 모든 OSD가 호스트 정의에 속해 있으므로 변경할 필요가 없습니다. 스토리지 클러스터 런타임 중에 다음을 통해 다른 모든 할당을 조정할 수 있습니다.

  • 다음 명령을 사용하여 버킷 구조를 정의합니다. 

    ceph osd crush add-bucket allDC root
ceph osd crush add-bucket DC1 datacenter
ceph osd crush add-bucket DC2 datacenter
ceph osd crush add-bucket DC3 datacenter

  • CRUSH 맵을 수정하여 이 구조 내에서 노드를 적절한 위치로 이동합니다. 

    ceph osd crush move DC1 root=allDC
ceph osd crush move DC2 root=allDC
ceph osd crush move DC3 root=allDC
ceph osd crush move ceph-node1 datacenter=DC1
ceph osd crush move ceph-node2 datacenter=DC1
ceph osd crush move ceph-node3 datacenter=DC2
ceph osd crush move ceph-node5 datacenter=DC2
ceph osd crush move ceph-node4 datacenter=DC3
ceph osd crush move ceph-node6 datacenter=DC3

이 구조 내에서 새 호스트도 추가할 수 있으며 새 디스크도 추가할 수 있습니다. 계층 구조에서 OSD를 올바른 위치에 배치하면 CRUSH 알고리즘은 구조 내의 다른 장애 도메인에 중복 조각을 배치하도록 변경됩니다.

위 예제는 다음과 같습니다.

예제

[root@mon ~]# ceph osd tree
ID  WEIGHT  TYPE NAME               UP/DOWN REWEIGHT PRIMARY-AFFINITY
 -8 6.00000 root allDC
 -9 2.00000     datacenter DC1
 -4 1.00000         host ceph-node1
  2 1.00000             osd.2            up  1.00000          1.00000
 -3 1.00000         host ceph-node2
  1 1.00000             osd.1            up  1.00000          1.00000
-10 2.00000     datacenter DC2
 -2 1.00000         host ceph-node3
  0 1.00000             osd.0            up  1.00000          1.00000
 -7 1.00000         host ceph-node5
  5 1.00000             osd.5            up  0.79999          1.00000
-11 2.00000     datacenter DC3
 -6 1.00000         host ceph-node6
  4 1.00000             osd.4            up  0.79999          1.00000
 -5 1.00000         host ceph-node4
  3 1.00000             osd.3            up  1.00000          1.00000
 -1       0 root default

위의 목록은 osd 트리를 표시하여 결과 CRUSH 맵을 보여줍니다. 이제 호스트가 데이터 센터에 속한 방법 및 모든 데이터 센터가 동일한 최상위 수준에 속하지만 위치를 명확하게 구분할 수 있습니다.

참고

맵에 따라 적절한 위치에 데이터를 배치하면 정상 클러스터 내에서만 올바르게 작동합니다. 일부 OSD를 사용할 수 없는 경우에는 Misplacement가 발생할 수 있습니다. 이러한 불일치는 가능한 한 자동으로 수정됩니다.

추가 리소스

  • 자세한 내용은 Red Hat Ceph Storage 전략 가이드의 CRUSH 관리 장을 참조하십시오.

5장. 컨테이너화되지 않은 Red Hat Ceph Storage 클러스터를 컨테이너화된 환경으로 마이그레이션

컨테이너화되지 않은 베어 메탈의 Red Hat Ceph Storage 클러스터를 컨테이너화된 환경으로 수동으로 마이그레이션하려면 ceph-ansible switch-from-containerized-to-containerized-ceph-daemons.yml 플레이북을 사용합니다.

참고

스토리지 클러스터에 ceph-ansible 에서 배포하지 않은 RBD 미러 데몬이 있는 경우 컨테이너화된 클러스터로 변환하기 전에 데몬을 마이그레이션해야 합니다. 자세한 내용은 Migrating RBD mirroring daemon을 참조하십시오.

사전 요구 사항

  • 실행 중인 Red Hat Ceph Storage 컨테이너화되지 않은 베어 메탈, 클러스터.
  • Ansible 관리 노드에 대한 액세스.
  • ansible 사용자 계정.
  • ansible 사용자 계정에 대한 sudo 액세스 권한.

절차

  1. 컨테이너 구성을 포함하도록 group_vars/all.yml 파일을 편집합니다. 

    ceph_docker_image_tag: "latest"
ceph_docker_image: rhceph/rhceph-4-rhel8
containerized_deployment: true
ceph_docker_registry: registry.redhat.io
    중요

    ceph_docker_image_tag 의 경우 현재 스토리지 클러스터가 최신 버전에 있는 경우 latest를 사용하거나 적절한 이미지 태그를 사용합니다. 자세한 내용은 Red Hat Ceph Storage 릴리스 및 해당 Ceph 패키지 버전은 무엇입니까? 를 참조하십시오.

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

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

  3. Ansible 관리 노드에서 Ansible 마이그레이션 플레이북을 실행합니다.

    구문

    ansible-playbook ./infrastructure-playbooks/switch-from-non-containerized-to-containerized-ceph-daemons.yml -i INVENTORY_FILE

    예제

    [ansible@admin ceph-ansible]$ ansible-playbook ./infrastructure-playbooks/switch-from-non-containerized-to-containerized-ceph-daemons.yml -i hosts

    클러스터가 컨테이너화된 환경으로 전환되었는지 확인합니다.

  4. monitor 노드에서 실행 중인 컨테이너를 모두 나열합니다.

    Red Hat Enterprise Linux 7

    [root@mon ~]$ sudo docker ps

    Red Hat Enterprise Linux 8

    [root@mon ~]$ sudo podman ps

추가 리소스

법적 공지

Copyright © 2024 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.