오브젝트 게이트웨이 가이드

Red Hat Ceph Storage 5

Ceph Object Gateway 배포, 구성 및 관리

초록

이 문서에서는 Ceph Object Gateway 환경 배포, 구성 및 관리에 대한 지침을 제공합니다. 이 가이드는 "Day Zero", "Day One" 및 "Day Two" 조직 방법론을 사용하여 독자에게 논리적 진행 경로를 제공합니다. Day Zero는 잠재적 솔루션을 구현하기 전에 연구 및 계획을 수행하는 위치이며 1장과 2 장을 참조하십시오. Day 1는 실제 배포 및 소프트웨어 설치가 발생하는 곳입니다 3 장을 참조하십시오. Day 2는 모든 기본 구성 및 고급 구성이 이루어지며 4 장,5 장 및 6 장을 확인합니다.
Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 용어를 교체하기 위해 최선을 다하고 있습니다. 먼저 마스터(master), 슬레이브(slave), 블랙리스트(blacklist), 화이트리스트(whitelist) 등 네 가지 용어를 교체하고 있습니다. 이러한 변경 작업은 작업 범위가 크므로 향후 여러 릴리스에 걸쳐 점차 구현할 예정입니다. 자세한 내용은 CTO Chris Wright의 메시지에서참조하십시오.

1장. Ceph 개체 게이트웨이

Ceph 개체 게이트웨이(RGW(RADOS Gateway)라고도 함)는 Ceph 스토리지 클러스터에 대한 RESTful 게이트웨이를 애플리케이션에 제공하기 위해 librados 라이브러리에 빌드된 오브젝트 스토리지 인터페이스입니다. Ceph Object Gateway는 다음 두 가지 인터페이스를 지원합니다.

S3 호환성:

Amazon S3 RESTful API의 큰 하위 집합과 호환되는 인터페이스가 포함된 오브젝트 스토리지 기능을 제공합니다.

Swift 호환성:

OpenStack Swift API의 대규모 하위 집합과 호환되는 인터페이스가 포함된 오브젝트 스토리지 기능을 제공합니다.

Ceph 개체 게이트웨이는 Ceph 스토리지 클러스터와 상호 작용하는 서비스입니다. 이 솔루션은 OpenStack Swift 및 Amazon S3과 호환되는 인터페이스를 제공하므로 Ceph Object Gateway에는 자체 사용자 관리 시스템이 있습니다. Ceph 개체 게이트웨이는 Ceph 블록 장치 클라이언트에서 데이터를 저장하는 데 사용되는 동일한 Ceph 스토리지 클러스터에 데이터를 저장할 수 있지만 별도의 풀과 다른 CRUSH 계층 구조가 필요합니다. S3 및 Swift API는 공통 네임스페이스를 공유하므로 하나의 API로 데이터를 작성하고 다른 API와 검색할 수 있습니다.

Administrative API:

Ceph Object Gateways를 관리하기 위한 관리 인터페이스를 제공합니다.

관리 API 요청은 관리자 리소스 엔드포인트로 시작하는 URI에서 수행됩니다. 관리 API에 대한 권한 부여는 S3 권한 부여 규칙을 모방합니다. 일부 작업에는 사용자에게 특별한 관리 기능이 있어야 합니다. 응답 유형은 요청에 format 옵션을 지정하여 XML 또는 JSON일 수 있지만 기본값은 JSON 형식입니다.

기본 액세스 다이어그램

2장. 고려 사항 및 권장 사항

스토리지 관리자는 Ceph Object Gateway를 실행하기 전에 고려해야 할 사항을 기본적으로 이해할 수 있습니다. 또한 다중 사이트 Ceph Object Gateway 솔루션을 구현하기 전에 고려해야 할 사항도 있습니다. 이러한 점을 이해하면 하드웨어 및 네트워크 요구 사항을 파악하고 Ceph Object Gateway 및 Red Hat의 권장 사항과 함께 작동하는 워크로드 유형을 파악할 수 있습니다.

2.1. 사전 요구 사항

  • 스토리지 솔루션을 이해하고, 고려하고, 계획하는 시간.

2.2. Red Hat Ceph Storage의 네트워크 고려 사항

클라우드 스토리지 솔루션의 중요한 측면은 네트워크 대기 시간 및 기타 요인으로 인해 스토리지 클러스터가 IOPS에서 실행될 수 있다는 것입니다. 또한 스토리지 클러스터에 스토리지 용량이 부족하기 전에 대역폭 제약으로 인해 처리량이 부족할 수 있습니다. 즉, 가격 대비 성능 요구 사항을 충족하기 위해 네트워크 하드웨어 구성에서 선택한 워크로드를 지원해야 합니다.

스토리지 관리자는 스토리지 클러스터를 최대한 빨리 복구하는 것을 선호합니다. 스토리지 클러스터 네트워크의 대역폭 요구 사항을 신중하게 고려하고 네트워크 링크를 덮어 쓰기하고 클라이언트-클러스터 간 트래픽에서 클러스터 내부 트래픽을 분리합니다. 또한 SSD(Solid State Disks), 플래시, NVMe 및 기타 고성능 스토리지 장치의 사용을 고려할 때 네트워크 성능이 점차 중요한 것으로 간주합니다.

Ceph는 공용 네트워크 및 스토리지 클러스터 네트워크를 지원합니다. 공용 네트워크는 Ceph 모니터와의 통신 및 클라이언트 트래픽을 처리합니다. 스토리지 클러스터 네트워크는 Ceph OSD 하트비트, 복제, 백필링 및 복구 트래픽을 처리합니다. 최소한 하나의 10GB 이더넷 링크를 스토리지 하드웨어에 사용해야 하며 연결 및 처리량을 위해 10GB 이더넷 링크를 추가할 수 있습니다.

중요

Red Hat은 스토리지 클러스터 네트워크에 대역폭을 할당하는 것이 좋습니다. 따라서 복제된 풀에서 여러 풀에 대한 기준으로 osd_pool_default_size 를 사용하는 공용 네트워크의 배수입니다. 또한 별도의 네트워크 카드에서 공용 및 스토리지 클러스터 네트워크를 실행하는 것이 좋습니다.

중요

프로덕션 시 Red Hat Ceph Storage 배포에는 10GB 이더넷을 사용하는 것이 좋습니다. 1GB 이더넷 네트워크는 프로덕션 스토리지 클러스터에 적합하지 않습니다.

드라이브 오류가 발생하는 경우 1GB 이더넷 네트워크에서 1TB의 데이터를 복제하는 데 3시간이 걸리며 3TB의 데이터를 9시간이 소요됩니다. 3TB를 사용하는 것이 일반적인 드라이브 구성입니다. 반대로 10GB 이더넷 네트워크를 사용하면 각각 20분과 1시간이 걸립니다. Ceph OSD가 실패하면 풀 내의 다른 Ceph OSD에 포함된 데이터를 복제하여 스토리지 클러스터를 복구합니다.

랙과 같은 대규모 도메인의 장애는 스토리지 클러스터가 훨씬 더 많은 대역폭을 활용함을 의미합니다. 대규모 스토리지 구현에 공통적인 여러 랙으로 구성된 스토리지 클러스터를 구축할 때 최적의 성능을 위해 "패트 트리" 설계의 스위치 간 네트워크 대역폭을 최대한 활용하는 것이 좋습니다. 일반적인 10GB 이더넷 스위치에는 48개의 10GB 포트와 40GB 포트 4개가 있습니다. 최대 처리량을 위해 스파인에서 40GB 포트를 사용합니다. 또는 다른 랙 및 스파인 라우터에 연결하기 위해 사용하지 않는 10GB 포트를 40GB 이상의 포트로 집계하는 것이 좋습니다. 또한 네트워크 인터페이스를 결합하는 데 LACP 모드 4를 사용하는 것이 좋습니다. 또한 점보 프레임, MTU(최대 전송 단위) 9000, 특히 백엔드 또는 클러스터 네트워크에서 사용합니다.

Red Hat Ceph Storage 클러스터를 설치하고 테스트하기 전에 네트워크 처리량을 확인합니다. Ceph에서 대부분의 성능 관련 문제는 일반적으로 네트워킹 문제로 시작합니다. kinked 또는 bent cat-6 케이블과 같은 간단한 네트워크 문제로 인해 대역폭이 저하될 수 있습니다. 전면 네트워크에 최소 10GB 이더넷을 사용합니다. 대규모 클러스터의 경우 백엔드 또는 클러스터 네트워크에 40GB 이더넷을 사용하는 것이 좋습니다.

중요

네트워크 최적화를 위해 Red Hat은 대역폭당 CPU를 개선하고 차단되지 않는 네트워크 스위치 백 플레인에 점보 프레임을 사용하는 것이 좋습니다. Red Hat Ceph Storage는 공용 네트워크와 클러스터 네트워크 모두에 대해 통신 경로의 모든 네트워킹 장치에 걸쳐 동일한 MTU 값이 필요합니다. 프로덕션에서 Red Hat Ceph Storage 클러스터를 사용하기 전에 MTU 값이 환경의 모든 노드 및 네트워킹 장비에서 같은지 확인합니다.

2.3. 기본 Red Hat Ceph Storage 고려 사항

Red Hat Ceph Storage를 사용하는 첫 번째 고려 사항은 데이터를 위한 스토리지 전략을 개발하는 것입니다. 스토리지 전략은 특정 사용 사례에 서비스를 제공하는 데이터를 저장하는 방법입니다. OpenStack과 같은 클라우드 플랫폼에 대한 볼륨과 이미지를 저장해야 하는 경우 저널용 SSD(Solid State Drives)로 더 빠른 SAS( Serial Attached SCSI) 드라이브에 데이터를 저장하도록 선택할 수 있습니다. 반대로 S3 또는 Swift 호환 게이트웨이에 대한 오브젝트 데이터를 저장해야 하는 경우 기존 SATA(Serial Advanced Technology Attachment) 드라이브와 같이 더 경제적인 것을 사용할 수 있습니다. Red Hat Ceph Storage는 동일한 스토리지 클러스터에 있는 두 시나리오를 모두 수용할 수 있지만, 클라우드 플랫폼에 빠른 스토리지 전략을 제공하는 수단과 개체 저장소에 더 많은 기존 스토리지를 제공하는 수단이 필요합니다.

Ceph 배포의 가장 중요한 단계 중 하나는 스토리지 클러스터의 사용 사례와 워크로드에 적합한 가격대 성능 프로필을 식별하는 것입니다. 사용 사례에 적합한 하드웨어를 선택하는 것이 중요합니다. 예를 들어, 콜드 스토리지 애플리케이션에 최적화된 IOPS 하드웨어를 선택하면 하드웨어 비용이 불필요하게 증가합니다. 반면, IOPS 집약적인 워크로드에서 용량에 최적화된 하드웨어를 선택하는 경우 성능 저하에 대해 불만을 제기하는 사용자가 불만을 줄 수 있습니다.

Red Hat Ceph Storage는 여러 스토리지 전략을 지원할 수 있습니다. 사운드 스토리지 전략을 개발하는 데 도움이 되는 사용 사례, 비용 대비 성능 장단점 및 데이터 지속성이 가장 중요한 고려 사항입니다.

사용 사례

Ceph는 대용량 스토리지 용량을 제공하며 다음과 같은 다양한 사용 사례를 지원합니다.

  • Ceph 블록 장치 클라이언트는 COW(Copy-On-Write 복제)와 같은 고성능 기능을 갖춘 볼륨 및 이미지에 대한 무제한 스토리지를 제공하는 클라우드 플랫폼용 최고의 스토리지 백엔드입니다.
  • Ceph Object Gateway 클라이언트는 오디오, 비트맵, 비디오 및 기타 데이터와 같은 오브젝트에 RESTful S3 호환 및 Swift 호환 개체 스토리지를 제공하는 클라우드 플랫폼용 최고의 스토리지 백엔드입니다.
  • 기존 파일 스토리지를 위한 Ceph 파일 시스템.

비용 vs. 성능 이점

속도가 빨라집니다. 규모가 클수록 더 우수합니다. 높은 지속성이 더 우수합니다. 그러나 각 상위 품질에 대한 가격 및 해당 비용 vs 혜택 거래가 있습니다. 성능 관점에서 다음 사용 사례를 고려하십시오. SSD는 상대적으로 적은 양의 데이터와 저널링에 매우 빠른 스토리지를 제공할 수 있습니다. 데이터베이스 또는 개체 인덱스를 저장하면 매우 빠른 SSD 풀의 이점을 얻을 수 있지만 다른 데이터에 너무 많은 비용이 듭니다. SSD 저널링을 사용하는 SAS 드라이브는 볼륨과 이미지의 경제적인 가격으로 빠른 성능을 제공합니다. SSD 저널링이 없는 SATA 드라이브는 전체 성능이 낮은 저렴한 스토리지를 제공합니다. OSD의 CRUSH 계층 구조를 생성할 때 사용 사례 및 허용 가능한 비용 대신 성능 트레이드를 고려해야 합니다.

데이터 내결함성

대규모 스토리지 클러스터에서 하드웨어 오류는 예외가 아니라 반드시 필요합니다. 그러나 데이터 손실 및 서비스 중단은 허용되지 않습니다. 이러한 이유로 데이터 지속성이 매우 중요합니다. Ceph는 여러 오브젝트 복제본 사본 또는 삭제 코딩 및 여러 코딩 청크를 사용하여 데이터 지속성을 처리합니다. 여러 복사본 또는 여러 코딩 청크를 사용하면 추가 비용과 혜택의 장단점이 있습니다. 즉, 복사본 또는 코딩 청크를 더 적게 저장하는 것이 더 저렴하지만 성능 저하된 상태로 서비스 쓰기 요청을 사용할 수 없게 될 수 있습니다. 일반적으로 두 개의 추가 사본이 있는 하나의 오브젝트 또는 두 개의 코딩 청크를 사용하면 스토리지 클러스터를 복구하는 동안 성능이 저하된 상태로 스토리지 클러스터가 기록되도록 할 수 있습니다.

복제는 하드웨어 장애 발생 시 장애 도메인에서 데이터의 중복 복사본을 하나 이상 저장합니다. 그러나 데이터의 중복 복사본은 규모에 따라 비용이 많이 들 수 있습니다. 예를 들어, 3개 복제를 사용하여 1페타바이트의 데이터를 저장하려면 최소 3페타바이트 이상의 스토리지 용량이 있는 클러스터가 필요합니다.

코딩 삭제는 데이터를 데이터 청크 및 코딩 청크로 저장합니다. 데이터 청크가 손실되는 경우 삭제 코딩은 나머지 데이터 청크 및 코딩 청크를 사용하여 손실된 데이터 청크를 복구할 수 있습니다. 이레이저 코딩은 복제보다 훨씬 더 경제적입니다. 예를 들어 데이터 청크 8개와 코딩 청크 3개가 있는 삭제 코딩을 사용하면 데이터 복사본 3개와 동일한 중복성이 제공됩니다. 그러나 이러한 인코딩 체계에서는 복제를 사용하는 경우 3x에 비해 저장된 초기 데이터의 약 1.5x를 사용합니다.

CRUSH 알고리즘은 Ceph가 스토리지 클러스터 내의 여러 위치에 추가 복사본 또는 코딩 청크를 저장하도록 하여 이 프로세스를 지원합니다. 이렇게 하면 단일 스토리지 장치 또는 노드의 실패로 인해 데이터 손실을 방지하는 데 필요한 모든 복사 또는 코딩 청크가 손실되지 않습니다. 비용 대비 이점의 장단점이 있는 스토리지 전략을 계획하고 데이터 지속성을 염두에 두고 Ceph 클라이언트에 스토리지 풀로 제공할 수 있습니다.

중요

데이터 스토리지 풀만 삭제 코딩을 사용할 수 있습니다. 서비스 데이터 및 버킷 인덱스를 저장하는 풀은 복제를 사용합니다.

중요

Ceph의 개체 복사 또는 코딩 청크를 사용하면 RAID 솔루션이 더 이상 사용되지 않습니다. Ceph는 이미 데이터 지속성을 처리하므로 RAID를 사용하지 마십시오. 성능이 저하된 RAID는 성능에 부정적인 영향을 미치며 RAID를 사용하여 데이터를 복구하는 것은 깊은 복사본 또는 코딩 청크를 사용하는 것보다 훨씬 느립니다.

추가 리소스

2.3.1. 공동 배치의 작동 방식 및 이점

컨테이너화된 Ceph 데몬을 동일한 노드에 공동 배치할 수 있습니다. 다음은 Ceph의 서비스 일부를 조합하면 얻을 수 있는 이점입니다.

  • 소규모로 TCO(총소유비용) 대폭 개선
  • 최소 구성에서 6개의 노드에서 3개로 축소
  • 더 쉬운 업그레이드
  • 리소스 격리 개선
Colocation 작동 방식

Ansible 인벤토리 파일의 해당 섹션에 동일한 노드를 추가하여 OSD 데몬(ceph-osd)을 사용하여 다음 목록에서 하나의 데몬을 공동 배치할 수 있습니다.

  • Ceph 메타데이터 서버(ceph-mds)
  • Ceph Monitor(ceph-mon) 및 Ceph Manager(ceph-mgr) 데몬
  • NFS Ganesha(nfs-ganesha)
  • rbd 미러(rbd-mirror)

또한 Ceph Object Gateway(radosgw)의 경우 RBD 미러를 제외하고 OSD 데몬과 위 목록의 데몬을 함께 배치할 수 있습니다. 예를 들어 다음은 유효한 5개의 노드 공동 배치 구성입니다.

노드데몬데몬데몬

node1

OSD

모니터

 

node2

OSD

모니터

RADOS 게이트웨이

node3

OSD

모니터

RADOS 게이트웨이

node4

OSD

메타 데이터 서버

 

node5

OSD

메타 데이터 서버

 

위 설정과 같이 5개의 노드 클러스터를 배포하려면 다음과 같이 Ansible 인벤토리 파일을 구성합니다.

공동 배치 데몬이 있는 Ansible 인벤토리 파일

[grafana-server]
node1

[mons]
node[1:3]

[mgrs]
node[1:3]

[osds]
node[1:5]

[rgws]
node[2:3]

[mdss]
node[4:5]

참고

ceph-monceph-mgr 은 서로 긴밀하게 작동하므로 공동 배치를 위해 두 개의 개별 데몬으로 계산되지 않습니다.

참고

Red Hat은 Ceph Object Gateway를 Ceph OSD 컨테이너와 연결하여 성능을 향상시키는 것이 좋습니다.

아래 다이어그램은 공동 배치 및 비할당 데몬이 있는 스토리지 클러스터의 차이점을 보여줍니다.

그림 2.1. 공동 배치 데몬

컨테이너 공동 배치 데몬이 Cardinality 2 업데이트

그림 2.2. 배치되지 않은 데몬

공동 배치되지 않은 데몬이 업데이트된 컨테이너

컨테이너화된 Ceph 데몬을 여러 개 동일한 노드에 배치하면 ceph-ansible 플레이북에서 전용 CPU 및 RAM 리소스를 각각에 예약합니다. 기본적으로 ceph-anible 에서는 Red Hat Ceph Storage 하드웨어 가이드권장 최소 하드웨어 장에 나열된 값을 사용합니다. 기본값을 변경하는 방법을 알아보려면 Colocated Daemons에 대한 전용 리소스 설정 섹션을 참조하십시오.

2.4. Red Hat Ceph Storage 워크로드 고려 사항

Ceph 스토리지 클러스터의 주요 이점 중 하나는 성능 도메인을 사용하여 동일한 스토리지 클러스터 내에서 다양한 유형의 워크로드를 지원할 수 있다는 것입니다. 각 성능 도메인과 다른 하드웨어 구성을 연결할 수 있습니다. 스토리지 관리자는 적절한 성능 도메인에 스토리지 풀을 배포할 수 있으므로 애플리케이션에 특정 성능 및 비용 프로필에 맞는 스토리지를 제공할 수 있습니다. 이러한 성능 도메인에 맞게 크기가 조정되고 최적화된 서버를 선택하는 것은 Red Hat Ceph Storage 클러스터를 설계하는 데 있어 필수적인 부분입니다.

데이터를 읽고 쓰는 Ceph 클라이언트 인터페이스의 경우 Ceph 스토리지 클러스터는 클라이언트가 데이터를 저장하는 간단한 풀로 나타납니다. 그러나 스토리지 클러스터는 클라이언트 인터페이스에 완전히 투명한 방식으로 많은 복잡한 작업을 수행합니다. Ceph OSD라고 하는 Ceph 클라이언트 및 Ceph 개체 스토리지 데몬은 모두 오브젝트 스토리지 및 검색에 대해 CRUSH(Controlled Replication Under Scalable Hashing) 알고리즘을 사용합니다. Ceph OSD는 스토리지 클러스터 내의 컨테이너에서 실행할 수 있습니다.

CRUSH 맵은 클러스터 리소스의 토폴로지를 설명하고 이 맵은 클라이언트 노드와 클러스터 내의 Ceph 모니터 노드에 모두 존재합니다. Ceph 클라이언트 및 Ceph OSD는 모두 CRUSH 맵과 CRUSH 알고리즘을 사용합니다. Ceph 클라이언트는 OSD와 직접 통신하여 중앙 집중식 오브젝트 조회 및 잠재적인 성능 병목 현상이 발생하지 않습니다. CRUSH 맵과 피어와의 통신을 인식하여 OSD는 복제, 백필링 및 복구를 처리할 수 있으므로 동적 오류 복구가 가능합니다.

Ceph는 CRUSH 맵을 사용하여 장애 도메인을 구현합니다. 또한 Ceph는 CRUSH 맵을 사용하여 성능 도메인을 구현합니다. 이 도메인은 단순히 기본 하드웨어의 성능 프로파일을 고려하여 고려합니다. CRUSH 맵은 Ceph가 데이터를 저장하는 방법을 설명하고, 이는 단순한 계층 구조, 특히 재활용 그래프 및 규칙 세트로 구현됩니다. CRUSH 맵은 여러 계층 구조를 지원하여 한 가지 유형의 하드웨어 성능 프로필을 분리할 수 있습니다. Ceph는 장치 "클래스"로 성능 도메인을 구현합니다.

예를 들어 동일한 Red Hat Ceph Storage 클러스터에 이러한 성능 도메인을 공존할 수 있습니다.

  • 일반적으로 HDD(하드 디스크 드라이브)는 비용 및 용량 중심 워크로드에 적합합니다.
  • 처리량에 민감한 워크로드는 일반적으로 SSD(반도체 드라이브)에서 Ceph 쓰기 저널과 함께 HDD를 사용합니다.
  • MySQL 및 MariaDB와 같은 IOPS 집약적인 워크로드에서는 SSD를 사용하는 경우가 많습니다.

그림 2.3. 성능 및 오류 도메인

perf 및 실패 도메인 다이어그램

워크로드

Red Hat Ceph Storage는 세 가지 주요 워크로드에 최적화되어 있습니다.

중요

Red Hat Ceph Storage 클러스터에서 실행되는 워크로드를 신중하게 고려하십시오. 구매해야 하는 하드웨어는 스토리지 클러스터의 가격 및 성능에 큰 영향을 미치기 때문입니다. 예를 들어, 워크로드가 용량에 최적화되어 있고 하드웨어가 처리량에 최적화된 워크로드에 더 적합한 경우 하드웨어가 필요한 것보다 비용이 더 높습니다. 반대로 워크로드가 처리량에 최적화되어 있고 하드웨어가 용량에 최적화된 워크로드에 더 적합한 경우 스토리지 클러스터가 성능이 저하될 수 있습니다.

  • 최적화된 IOPS: IOPS(초당 출력) 최적화 배포는 MYSQL 또는 MariaDB 인스턴스를 OpenStack에서 가상 시스템으로 실행하는 등 클라우드 컴퓨팅 작업에 적합합니다. IOPS 최적화된 배포를 위해서는 15k RPM SAS 드라이브와 같은 고성능 스토리지와 빈번한 쓰기 작업을 처리하기 위해 별도의 SSD 저널이 필요합니다. 일부 높은 IOPS 시나리오에서는 모든 플래시 스토리지를 사용하여 IOPS 및 총 처리량을 개선합니다.

    IOPS 최적화된 스토리지 클러스터에는 다음 속성이 있습니다.

    • IOPS당 최저 비용.
    • GB당 가장 높은 IOPS.
    • 99번째 백분위 대기 시간 일관성.

    IOPS 최적화된 스토리지 클러스터의 용도는 다음과 같습니다.

    • 일반적으로 블록 스토리지.
    • SSD(반도체 드라이브)의 경우 하드 디스크 드라이브(HDD) 또는 2x 복제를 위한 3x 복제.
    • OpenStack 클라우드의 MySQL.
  • 처리량 최적화: 처리량 최적화 배포는 그래픽, 오디오 및 비디오 컨텐츠와 같이 상당한 양의 데이터를 처리하는 데 적합합니다. 처리량 최적화된 배포에는 빠른 순차 읽기 및 쓰기 특성을 가진 높은 대역폭 네트워킹 하드웨어, 컨트롤러 및 하드 디스크 드라이브가 필요합니다. 빠른 데이터 액세스가 요구 사항인 경우 처리량에 최적화된 스토리지 전략을 사용합니다. 또한 빠른 쓰기 성능이 필수인 경우 저널에 SSD(Solid State Disks)를 사용하면 쓰기 성능이 크게 향상됩니다.

    처리량 최적화된 스토리지 클러스터에는 다음과 같은 속성이 있습니다.

    • MBps당 최저 비용(처리량).
    • TB당 최고 MBps.
    • BTU당 가장 높은 MBps.
    • 푸트당 최고 MBps.
    • 97번째 백분위 대기 시간 일관성.

    처리량에 최적화된 스토리지 클러스터는 다음과 같습니다.

    • 블록 또는 개체 스토리지.
    • 3배 복제.
    • 비디오, 오디오 및 이미지를 위한 액티브 성능 스토리지.
    • 4k 비디오와 같은 스트리밍 미디어.
  • 최적화된 용량: 용량에 최적화된 배포는 상당한 양의 데이터를 최대한 저렴하게 저장하는 데 적합합니다. 용량 최적화된 배포는 일반적으로 매력적인 가격대를 위해 성능을 교환합니다. 예를 들어 용량 최적화된 배포에서는 저널링에 SSD를 사용하는 대신 더 느리고 값비싼 SATA 드라이브를 사용하고 저널을 공동 배치하는 경우가 많습니다.

    비용 및 용량 최적화된 스토리지 클러스터에는 다음과 같은 속성이 있습니다.

    • TB당 최저 비용.
    • TB당 최저 BTU.
    • TB당 최저 발트 필요.

    비용 및 용량 최적화된 스토리지 클러스터의 용도는 다음과 같습니다.

    • 일반적으로 오브젝트 스토리지.
    • 사용 가능한 용량을 극대화하기 위한 코딩 삭제
    • 개체 아카이브.
    • 비디오, 오디오 및 이미지 오브젝트 리포지토리.

2.5. Ceph Object Gateway 고려 사항

스토리지 클러스터를 설계하는 또 다른 중요한 측면은 스토리지 클러스터가 하나의 데이터 센터 사이트에 있는지 또는 여러 데이터 센터 사이트에 걸쳐 있는지 확인하는 것입니다. 다중 사이트 스토리지 클러스터는 장기 정전, 설비, 장애물, 플러드 또는 기타 재해와 같은 지리적으로 분산된 장애 조치(failover) 및 재해 복구를 통해 이점을 제공합니다. 또한 다중 사이트 스토리지 클러스터에는 클라이언트 애플리케이션을 사용 가능한 가장 가까운 스토리지 클러스터로 지정할 수 있는 액티브-액티브 구성이 있을 수 있습니다. 이는 콘텐츠 전달 네트워크에 적합한 스토리지 전략입니다. 가능한 한 클라이언트에 가까운 데이터를 두는 것이 좋습니다. 이는 처리량을 많이 사용하는 워크로드(예: 4k 비디오 스트리밍)에 중요합니다.

중요

Red Hat은 Ceph의 스토리지 풀을 만들 때 영역, 영역 그룹 및 영역 이름을 확인하는 것이 좋습니다. 일부 풀 이름 앞에 표준 명명 규칙으로 영역 이름을 추가합니다.

추가 리소스

2.5.1. 관리 데이터 스토리지

Ceph 개체 게이트웨이는 인스턴스의 영역 구성에 정의된 일련의 풀에 관리 데이터를 저장합니다. 예를 들어 이후 섹션에서 설명하는 버킷, 사용자, 사용자 할당량 및 사용 통계는 Ceph 스토리지 클러스터의 풀에 저장됩니다. 기본적으로 Ceph Object Gateway는 다음 풀을 만들어 기본 영역에 매핑합니다.

  • .rgw.root
  • .default.rgw.control
  • .default.rgw.meta
  • .default.rgw.log
  • .default.rgw.buckets.index
  • .default.rgw.buckets.data
  • .default.rgw.buckets.non-ec
참고

.default.rgw.buckets.index 풀은 Ceph Object Gateway에서 버킷을 생성한 후에만 생성되는 반면 .default.rgw.buckets.data 풀은 버킷에 데이터를 업로드한 후 생성됩니다.

CRUSH 규칙 세트와 배치 그룹을 설정할 수 있도록 수동으로 풀을 생성하는 것이 좋습니다. 일반적인 구성에서는 Ceph Object Gateway의 관리 데이터를 저장하는 풀에서 동일한 CRUSH 규칙 세트를 사용하는 경우가 많으며 관리 데이터에 대해 10개의 풀이 있으므로 배치 그룹의 수가 줄어듭니다.

Red Hat은 .rgw.root 풀과 서비스 풀에서 동일한 CRUSH 계층 구조를 사용하고 CRUSH 규칙에서 최소 노드를 장애 도메인으로 사용하는 것이 좋습니다. Red Hat은 데이터 지속성을 위해 복제 를 사용하고 .rgw. root 풀과 서비스 풀은 삭제하지 않는 것이 좋습니다.

mon_pg_warn_max_per_osd 설정은 기본적으로 풀에 너무 많은 배치 그룹을 할당하는 경우 경고합니다. 요구 사항 및 하드웨어 기능에 맞게 값을 조정할 수 있습니다. 여기서 n 은 OSD당 최대 PG 수입니다.

mon_pg_warn_max_per_osd = n
참고

서비스 풀( .rgw.root 포함)의 경우 풀 계산기당 Ceph 배치 그룹(PG) 에서 권장되는 PG 수는 Ceph OSD당 대상 PG보다 훨씬 적습니다. 또한 Ceph OSD의 수가 계산기 4단계로 설정되어 있는지 확인합니다.

중요

가비지 컬렉션은AP 대신 일반 RADOS 오브젝트가 있는 .log 풀을 사용합니다. 향후 릴리스에서는 더 많은 기능이 .log 풀에 메타데이터를 저장할 예정입니다. 따라서 Red Hat은 .log 풀에 NVMe/SSD Ceph OSD를 사용하는 것이 좋습니다.

.RGW.root

Ceph Object Gateway 구성이 저장된 풀입니다. 여기에는 영역, 영역 그룹 및 영역이 포함됩니다. 관례적으로 해당 이름은 영역 이름을 앞에 추가하지 않습니다.

서비스 풀

서비스 풀은 서비스 제어, 가비지 컬렉션, 로깅, 사용자 정보 및 사용과 관련된 오브젝트를 저장합니다. 관례적으로 이러한 풀 이름에는 풀 이름에 앞에 붙은 영역 이름이 있습니다.

  • .ZONE_NAME.rgw.control : 제어 풀입니다.
  • .ZONE_NAME.log : 로그 풀에는 생성, 읽기, 업데이트 및 삭제와 같은 모든 버킷, 컨테이너 및 오브젝트 작업의 로그가 포함됩니다.
  • .ZONE_NAME.rgw.buckets.index : 이 풀은 버킷의 인덱스를 저장합니다.
  • .ZONE_NAME.rgw.buckets.data : 이 풀은 버킷의 데이터를 저장합니다.
  • .ZONE_NAME.rgw.meta : 메타데이터 풀은 user_keys 및 기타 중요한 메타데이터를 저장합니다.
  • .ZONE_NAME.meta:users.uid : 사용자 ID 풀에는 고유한 사용자 ID 맵이 포함되어 있습니다.
  • .ZONE_NAME.meta:users.keys : 키 풀에는 각 사용자 ID에 대한 액세스 키 및 비밀 키가 포함됩니다.
  • .ZONE_NAME.meta:users.email : 이메일 풀에는 사용자 ID와 연결된 이메일 주소가 포함됩니다.
  • .ZONE_NAME.meta:users.swift : Swift 풀에는 사용자 ID에 대한 Swift 하위 사용자 정보가 포함되어 있습니다.

추가 리소스

2.5.2. 인덱스 풀

사용 사례와 관계없이 Ceph Object Gateway에서 사용할 Ceph OSD 하드웨어를 선택하는 경우 인덱스 풀 저장을 위해 고성능 드라이브가 하나 이상 있는 Ceph OSD 노드가 있어야 합니다. 버킷에 많은 오브젝트가 포함된 경우 특히 중요합니다.

노드에는 하나 이상의 SSD 또는 NVMe 드라이브가 있어야 합니다. Red Hat 랩 테스트에서 NVMe 드라이브는 동일한 드라이브에서 OSD 저널과 인덱스 풀을 둘 다 지원하지만 NVMe 드라이브의 개별 파티션을 사용할 수 있는 충분한 성능을 나타냈습니다.

참고

Red Hat은 인덱스 풀에 대한 HDD 장치를 지원하지 않습니다. 지원되는 구성에 대한 자세한 내용은 Red Hat Ceph Storage를 참조하십시오. 지원되는 구성 문서.

인덱스 항목은 약 200바이트의 데이터이며, 데이터 맵(omap) 으로 저장됩니다. 이는 적은 양의 데이터이지만 Ceph 개체 게이트웨이를 사용하면 수십 또는 수백 만 개의 개체가 단일 버킷에 포함될 수 있습니다. 인덱스 풀을 고성능 스토리지 미디어의 CRUSH 계층 구조에 매핑함으로써 버킷에 많은 오브젝트가 포함된 경우 대기 시간이 크게 단축됩니다.

중요

프로덕션 Red Hat Ceph Storage 클러스터에서는 OSD 저널 및 인덱스 풀을 저장하기 위한 일반적인 Ceph OSD 노드에는 하나 이상의 SSD 또는 NVMe 드라이브가 있습니다. 이 드라이브는 동일한 물리 드라이브를 사용할 때 별도의 파티션 또는 논리 볼륨을 사용합니다.

2.5.3. 데이터 풀

데이터 풀은 Ceph Object Gateway가 특정 스토리지 정책에 대한 오브젝트 데이터를 저장하는 위치입니다. 데이터 풀은 서비스 풀의 PG 수를 줄이는 대신 PG(배포 그룹)를 완전히 보완합니다. 복제보다 훨씬 효율적이므로 데이터 풀에 삭제 코딩을 사용하는 것이 중요하며 데이터 지속성을 유지하면서 용량 요구 사항을 크게 줄일 수 있습니다.

삭제 코딩을 사용하려면 삭제 코드 프로필을 만듭니다. 자세한 내용은 Storage Strategies Guide의 코드 프로필 생성 섹션을 참조하십시오.

중요

풀을 생성한 후에는 프로필을 변경할 수 없으므로 올바른 프로필을 선택하는 것이 중요합니다. 프로필을 수정하려면 다른 프로필을 사용하여 새 풀을 생성하고 이전 풀에서 새 풀로 오브젝트를 마이그레이션해야 합니다.

기본 구성은 두 개의 데이터 청크와 하나의 인코딩 청크로, 하나의 OSD만 손실할 수 있습니다. 복원력을 높이기 위해 많은 수의 데이터 및 인코딩 청크를 고려하십시오. 예를 들어 일부 대규모 시스템은 8개의 데이터 청크와 3개의 인코딩 청크를 사용하므로 데이터가 손실되지 않고 3개의 OSD가 실패할 수 있습니다.

중요

각 데이터 및 인코딩 청크는 최소한 다른 노드나 호스트에 저장됩니다. 소규모 스토리지 클러스터의 경우 많은 수의 데이터를 사용하고 청크를 인코딩할 때 을 최소 CRUSH 장애 도메인으로 비현실적으로 사용합니다. 따라서 데이터 풀은 일반적으로 host 와 함께 별도의 CRUSH 계층 구조를 최소 CRUSH 장애 도메인으로 사용하는 것이 일반적입니다. Red Hat은 최소 장애 도메인으로 호스트 를 권장합니다. 코드 청크 삭제가 동일한 호스트 내의 Ceph OSD에 저장되면 실패한 저널 또는 네트워크 카드와 같은 호스트 실패로 인해 데이터가 손실될 수 있습니다.

데이터 풀을 생성하려면 풀 이름, PG 및 PGP 수, 삭제 데이터 지속성 방법, 삭제 코드 프로필 및 규칙 이름을 사용하여 ceph osd pool create 를 실행합니다.

2.5.4. 데이터 추가 풀

data_extra_pool 은 삭제 코딩을 사용할 수 없는 데이터용입니다. 예를 들어 다중 파트 업로드를 사용하면 여러 부분의 영화와 같은 큰 오브젝트를 업로드할 수 있습니다. 이 부분은 삭제 코딩 없이 먼저 저장해야 합니다. 이레이저 코딩은 부분적인 업로드가 아닌 전체 객체에 적용됩니다.

참고

풀 계산기당 PG(배치 그룹)는 data_extra_pool 에 대한 풀당 PG 수를 더 적게 권장합니다. 그러나 PG 수는 서비스 풀과 동일한 PG 수이고 버킷 인덱스 풀과 동일합니다.

데이터 추가 풀을 생성하려면 풀 이름, PG 및 PGP 수, 복제된 데이터 지속성 방법 및 규칙 이름을 사용하여 ceph osd pool create 를 실행합니다. 예를 들면 다음과 같습니다.

# ceph osd pool create .us-west.rgw.buckets.non-ec 64 64 replicated rgw-service

2.6. CRUSH 계층 구조 개발

스토리지 관리자로서 Ceph 스토리지 클러스터와 오브젝트 게이트웨이를 배포할 때 일반적으로 Ceph Object Gateway에는 기본 영역 그룹 및 영역이 있습니다. Ceph 스토리지 클러스터에는 기본 풀이 있으므로 기본 CRUSH 계층 구조와 함께 CRUSH 맵과 기본 CRUSH 규칙이 사용됩니다.

중요

기본 rbd 풀은 기본 CRUSH 규칙을 사용할 수 있습니다. Ceph 클라이언트가 클라이언트 데이터를 저장하는 데 사용한 경우 기본 규칙이나 계층 구조를 삭제하지 마십시오.

프로덕션 게이트웨이는 일반적으로 게이트웨이의 사용 및 지리적 위치에 따라 이름이 지정된 영역, 영역 그룹 및 영역을 사용합니다. 또한 Ceph 스토리지 클러스터에는 CRUSH 계층 구조가 여러 개의 CRUSH 맵이 있습니다.

  • 서비스 풀: 하나 이상의 CRUSH 계층 구조는 서비스 풀 및 잠재적으로 데이터에 사용할 수 있습니다. 서비스 풀에는 .rgw.root 및 영역과 연결된 서비스 풀이 포함됩니다. 서비스 풀은 일반적으로 단일 CRUSH 계층 구조에 속하며 데이터 지속성에 복제를 사용합니다. 데이터 풀은 CRUSH 계층 구조를 사용할 수도 있지만, 일반적으로 이 풀은 데이터 지속성을 위해 삭제 코딩으로 구성됩니다.
  • 인덱스: CRUSH 계층 구조 SHOULD 는 하나 이상의 CRUSH 계층 구조가 SSD 또는 NVMe 드라이브와 같은 고성능 미디어에 매핑되는 인덱스 풀에 사용됩니다. 버킷 인덱스는 성능 병목이 될 수 있습니다. 이 CRUSH 계층 구조에서 SSD 또는 NVMe 드라이브를 사용하는 것이 좋습니다. Ceph OSD 저널에 사용되는 SSD 또는 NVMe 드라이브에서 인덱스용 파티션을 생성합니다. 또한 인덱스는 버킷 분할을 사용하여 구성해야 합니다.
  • 배치 풀: 각 배치 대상의 배치 풀에는 버킷 인덱스, 데이터 버킷 및 버킷 추가 기능이 포함됩니다. 이러한 풀은 별도의 CRUSH 계층 구조에 속할 수 있습니다. Ceph Object Gateway는 여러 스토리지 정책을 지원할 수 있으므로 스토리지 정책의 버킷 풀이 각각 최적화된 IOPS, 처리량 최적화 및 용량 최적화와 같은 다양한 사용 사례를 반영하여 다양한 CRUSH 계층 구조와 연결될 수 있습니다. 버킷 인덱스 풀 SHOULD 는 자체 CRUSH 계층 구조를 사용하여 버킷 인덱스 풀을 SSD 또는 NVMe 드라이브와 같은 고성능 스토리지 미디어에 매핑합니다.

2.6.1. CRUSH 루트 생성

관리 노드의 명령줄에서 각 CRUSH 계층 구조에 대한 CRUSH 맵에 CRUSH 루트를 생성합니다. 데이터 스토리지 풀도 제공할 수 있는 서비스 풀에는 CRUSH 계층 구조가 하나 이상 있어야 합니다. SHOULD 에는 버킷 인덱스 풀에 대한 CRUSH 계층이 하나 이상 있으며, SSD 또는 NVMe 드라이브와 같은 고성능 스토리지 미디어에 매핑됩니다.

CRUSH 계층 구조에 대한 자세한 내용은 Red Hat Ceph Storage Storage Strategies Guide 5 의 CRUSH 계층 구조를 참조하십시오.

CRUSH 맵을 수동으로 편집하려면 Red Hat Ceph Storage Storage Strategies Guide 5CRUSH 맵 편집 섹션을 참조하십시오.

다음 예에서 data0, data 1 및 data 2 라는 호스트는 동일한 물리적 호스트를 가리키는 CRUSH 맵에 있는 data0-sas-ssd, data0-index 등과 같은 확장 논리 이름을 사용합니다.

일반적인 CRUSH 루트는 저널의 SAS 드라이브 및 SSD로 노드를 나타낼 수 있습니다. 예를 들면 다음과 같습니다.

##
# SAS-SSD ROOT DECLARATION
##

root sas-ssd {
  id -1   # do not change unnecessarily
  # weight 0.000
  alg straw
  hash 0  # rjenkins1
  item data2-sas-ssd weight 4.000
  item data1-sas-ssd weight 4.000
  item data0-sas-ssd weight 4.000
}

버킷 색인의 CRUSH 루트 SHOULD 는 SSD 또는 NVMe 드라이브와 같은 고성능 미디어를 나타냅니다. OSD 저널을 저장하는 SSD 또는 NVMe 미디어에 파티션을 생성하는 것이 좋습니다. 예를 들면 다음과 같습니다.

##
# INDEX ROOT DECLARATION
##

root index {
  id -2    # do not change unnecessarily
  # weight 0.000
  alg straw
  hash 0  # rjenkins1
  item data2-index weight 1.000
  item data1-index weight 1.000
  item data0-index weight 1.000
}

2.6.2. CRUSH 맵에서 논리 호스트 이름 사용

RHCS 3 이상 릴리스에서 CRUSH는 RHCS 2 및 이전 릴리스에서 지원되지 않는 스토리지 장치 "class"의 개념을 지원합니다. NVMe, SSD 또는 HDD와 같은 스토리지 장치의 여러 클래스가 포함된 호스트 또는 노드가 포함된 RHCS 3 클러스터에서는 장치 클래스와 단일 CRUSH 계층 구조를 사용하여 다양한 스토리지 장치 클래스를 구분합니다. 이렇게 하면 논리 호스트 이름을 사용할 필요가 없습니다. RHCS 2 이전 릴리스에서는 각 장치 클래스에 하나씩 여러 CRUSH 계층 구조를 사용하고 논리적 호스트 이름을 사용하여 CRUSH 계층 구조에서 호스트 또는 노드를 구분합니다.

CRUSH 맵에서 호스트 이름은 고유해야 하며 한 번만 사용해야 합니다. 호스트가 여러 CRUSH 계층 구조 및 사용 사례를 제공하는 경우 CRUSH 맵은 실제 호스트 이름이 한 번만 사용되는지 확인하기 위해 논리 호스트 이름을 사용할 수 있습니다. 예를 들어 노드에는 SSD, SSD 저널이 있는 SAS 드라이브, 공동 배치된 저널이 있는 SATA 드라이브와 같은 여러 개의 드라이브 클래스가 있을 수 있습니다. RHCS 2 및 이전 릴리스에서 동일한 호스트에 대해 여러 CRUSH 계층 구조를 생성하려면 계층 구조에서 실제 호스트 이름 대신 논리 호스트 이름을 사용해야 버킷 이름이 CRUSH 계층 구조 내에서 고유합니다. 예를 들어 호스트 이름이 data2인 경우 CRUSH 계층에서 data 2-sas-ssd 및 data2- index 와 같은 논리 이름을 사용할 수 있습니다. 예를 들면 다음과 같습니다.

host data2-sas-ssd {
  id -11   # do not change unnecessarily
  # weight 0.000
  alg straw
  hash 0  # rjenkins1
  item osd.0 weight 1.000
  item osd.1 weight 1.000
  item osd.2 weight 1.000
  item osd.3 weight 1.000
}

앞서 언급한 예에서 호스트 data2 는 논리 이름 data2-ssd 를 사용하여 SSD의 저널과 SAS 드라이브를 하나의 계층 구조로 매핑합니다. 이전 예에서 osd. 3을 통해 OSD ID osd. 0 은 처리량이 높은 하드웨어 구성에서 SSD 저널을 사용하여 SAS 드라이브를 나타냅니다. 이러한 OSD ID는 다음 예의 OSD ID와 다릅니다.

다음 예에서 호스트 data2-index는 논리 이름 data2-index 를 사용하여 버킷 색인의 SSD 드라이브를 두 번째 계층 구조에 매핑합니다. 다음 예에서 OSD ID osd.4 는 버킷 인덱스 풀에만 사용되는 SSD 드라이브 또는 기타 고속 스토리지 미디어를 나타냅니다.

host data2-index {
  id -21   # do not change unnecessarily
  # weight 0.000
  alg straw
  hash 0  # rjenkins1
  item osd.4 weight 1.000
}
중요

논리 호스트 이름을 사용하는 경우 OSD 시작 스크립트가 시작 시 실제 호스트 이름을 사용하지 못하도록 다음 설정 중 하나가 Ceph 구성 파일에 있는지 확인합니다. 따라서 CRUSH 맵에서 데이터를 찾지 못합니다.

CRUSH 맵에서 앞의 예와 같이 논리 호스트 이름을 사용하는 경우 OSD 시작 스크립트가 초기화 시 실제 호스트 이름에 따라 호스트를 식별하지 못하도록 합니다. Ceph 구성 파일의 [global] 섹션에 다음 설정을 추가합니다.

osd_crush_update_on_start = false

논리적 호스트 이름을 정의하는 또 다른 방법은 Ceph 구성 파일의 [osd.<ID>] 섹션에 있는 각 OSD에 대한 CRUSH 맵의 위치를 정의하는 것입니다. OSD 시작 스크립트에서 정의하는 모든 위치를 재정의합니다. 앞서 언급한 예제에서 항목은 다음과 같을 수 있습니다.

[osd.0]
osd crush location = "host=data2-sas-ssd"

[osd.1]
osd crush location = "host=data2-sas-ssd"

[osd.2]
osd crush location = "host=data2-sas-ssd"

[osd.3]
osd crush location = "host=data2-sas-ssd"

[osd.4]
osd crush location = "host=data2-index"
중요

CRUSH 맵에서 실제 호스트 이름이 아닌 논리적 호스트 이름을 사용하는 경우 권장 접근법 중 하나가 사용되지 않는 경우, 재시작 시 Ceph Storage Cluster는 OSD가 실제 호스트 이름에 매핑되고 실제 호스트 이름은 CRUSH 맵에 표시되지 않으며 Ceph 스토리지 클러스터 클라이언트는 OSD와 해당 데이터를 찾지 못합니다.

2.6.3. CRUSH 규칙 생성

기본 CRUSH 계층 구조와 마찬가지로 CRUSH 맵에는 기본 CRUSH 규칙도 포함되어 있습니다.

참고

기본 rbd 풀에서 이 규칙을 사용할 수 있습니다. 다른 풀에서 고객 데이터를 저장하는 데 기본 규칙을 삭제하지 마십시오.

CRUSH 규칙에 대한 자세한 내용은 Red Hat Ceph Storage 5용 스토리지 전략 가이드의 CRUSH 규칙 섹션을 참조하십시오. CRUSH 맵을 수동으로 편집하려면 Red Hat Ceph Storage 5용 Storage Strategies 가이드의 CRUSH 맵 편집 섹션을 참조하십시오.

각 CRUSH 계층 구조에 대해 CRUSH 규칙을 생성합니다. 다음 예제에서는. rgw.root 를 포함하여 서비스 풀을 저장할 CRUSH 계층 구조의 규칙을 보여줍니다. 이 예에서 루트 sas-ssd 는 주요 CRUSH 계층 구조 역할을 합니다. 이름 rgw-service 를 사용하여 기본 규칙과 구분합니다. 단계는 sas-ssd 행을 통해 풀에 CRUSH 루트 생성에서 생성된 sas-ssd 루트를 사용하도록 알립니다. 해당 하위 버킷에는 SAS 드라이브가 있는 OSD와 처리량이 높은 하드웨어 구성의 저널용 SSD 또는 NVMe 드라이브와 같은 고성능 스토리지 미디어가 포함됩니다. step selectleaf유형 rack 부분은 실패 도메인입니다. 다음 예제에서는 랙입니다.

##
# SERVICE RULE DECLARATION
##

rule rgw-service {
 type replicated
 min_size 1
 max_size 10
 step take sas-ssd
 step chooseleaf firstn 0 type rack
 step emit
}
참고

위 예제에서 데이터가 세 번 복제되는 경우 클러스터에 비슷한 개수의 OSD 노드를 포함하는 랙이 3개 이상 있어야 합니다.

작은 정보

복제된 유형에는 데이터 지속성, 복제본 수 또는 삭제 코딩과 관련된 NOTHING 이 있습니다. 복제된 상태만 지원됩니다.

다음 예제에서는 데이터 풀을 저장할 CRUSH 계층 구조의 규칙을 보여줍니다. 이 예에서 루트 sas-ssd 는 주요 CRUSH 계층 구조-서비스 규칙과 동일한 CRUSH 계층 구조입니다. rgw-throughput 을 사용하여 기본 규칙과 rgw-service 를 구분합니다. 단계는 sas-ssd 행을 통해 풀에 CRUSH 루트 생성에서 생성된 sas-ssd 루트를 사용하도록 알립니다. 해당 하위 버킷에는 SAS 드라이브가 있는 OSD와 처리량이 높은 하드웨어 구성의 SSD 또는 NVMe 드라이브와 같은 고성능 스토리지 미디어가 포함됩니다. step selectleaf호스트 부분은 실패 도메인입니다. 다음 예제에서는 호스트입니다. 규칙은 동일한 CRUSH 계층 구조이지만 다른 오류 도메인을 사용합니다.

##
# THROUGHPUT RULE DECLARATION
##

rule rgw-throughput {
 type replicated
 min_size 1
 max_size 10
 step take sas-ssd
 step chooseleaf firstn 0 type host
 step emit
}
참고

앞의 예에서 풀이 기본값보다 많은 수의 데이터 및 인코딩 청크를 사용하여 삭제 코딩을 사용하는 경우 삭제 코딩 청크를 용이하게 하려면 클러스터에 비슷한 개수의 OSD 노드를 포함하는 랙이 있어야 합니다. 소규모 클러스터의 경우 이는 실용적이지 않을 수 있으므로 위 예제는 host 를 CRUSH 장애 도메인으로 사용합니다.

다음 예제에서는 인덱스 풀을 저장할 CRUSH 계층 구조의 규칙을 보여줍니다. 이 예에서 루트 인덱스 는 기본 CRUSH 계층 구조 역할을 합니다. rgw-index 를 사용하여 rgw-servicergw-throughput 과 구분합니다. 단계에서는 CRUSH 루트 생성에서 생성된 인덱스 루트를 사용하도록 풀에 지시합니다. 해당 버킷 에는 OSD 저널을 저장하는 SSD 또는 NVMe 드라이브의 SSD 또는 NVMe 드라이브와 같은 고성능 스토리지 미디어가 포함됩니다. step selectleaf유형 rack 부분은 실패 도메인입니다. 다음 예제에서는 랙입니다.

##
# INDEX RULE DECLARATION
##

rule rgw-index {
 type replicated
 min_size 1
 max_size 10
 step take index
 step chooseleaf firstn 0 type rack
 step emit
}

2.6.4. 추가 리소스

  • CRUSH 계층 구조에 대한 자세한 내용은 스토리지 전략 가이드의 CRUSH 관리 섹션을 참조하십시오.

2.7. Ceph Object Gateway 다중 사이트 고려 사항

Ceph Object Gateway 다중 사이트 구성에는 Red Hat Ceph Storage 클러스터 2개 이상과 Ceph 개체 게이트웨이 인스턴스가 각각 하나씩 필요합니다. 일반적으로 두 개의 Red Hat Ceph Storage 클러스터는 지리적으로 별도의 위치에 있지만 이와 동일한 다중 사이트 구성은 동일한 물리적 사이트에 있는 두 개의 Red Hat Ceph Storage 클러스터에서 작동할 수 있습니다.

다중 사이트 구성에는 기본 영역 그룹과 기본 영역이 필요합니다. 또한 각 영역 그룹에는 기본 영역이 필요합니다. 영역 그룹에는 하나 이상의 보조 영역이 있을 수 있습니다.

중요

영역의 기본 영역 그룹 내의 기본 영역은 사용자, 할당량 및 버킷을 포함하여 영역 메타데이터의 기본 복사본을 저장합니다. 이 메타데이터는 보조 영역 및 보조 영역 그룹과 자동으로 동기화됩니다. radosgw-admin CLI(명령줄 인터페이스)를 사용하여 실행되는 메타데이터 작업은 기본 영역 그룹의 기본 영역 내의 노드에서 실행되어 보조 영역 그룹 및 영역과 동기화되도록 합니다. 현재 보조 영역 및 영역 그룹에서 메타데이터 작업을 실행할 있지만 동기화되지 않으므로 메타데이터 가 조각화될 수 있으므로 사용하지 않는 것이 좋습니다.

아래 다이어그램은 다중 사이트 Ceph Object Gateway 환경에서 가능한 하나와 두 개의 영역 구성을 보여줍니다.

그림 2.4. Realm 한 개

mulitsite 1개 영역

그림 2.5. 2개의 Realms

mulitsite 두 영역

그림 2.6. 두 개의 Realms 변형

mulitsite 두 영역 변형

2.8. 스토리지 크기 조정 고려

클러스터 설계에서 가장 중요한 요소 중 하나는 스토리지 요구 사항(크기)을 결정하는 것입니다. Ceph 스토리지는 페타바이트 이상으로 확장되도록 설계되었습니다. 다음 예제는 Ceph 스토리지 클러스터의 일반적인 크기입니다.

  • 작은: 250테라바이트
  • 중간: 페타바이트 1개
  • 큰: 2페타바이트 이상.

크기 조정에는 현재 요구 사항과 가까운 미래의 요구 사항이 포함됩니다. 게이트웨이 클라이언트가 클러스터에 새 데이터를 추가할 속도를 고려하십시오. 사용 사례와 다를 수 있습니다. 예를 들어, 4k 동영상을 기록하거나 의료 이미지를 저장하면 금융 시장 데이터와 같은 스토리지 집약적인 정보보다 훨씬 더 빠른 양의 데이터를 추가할 수 있습니다. 또한 복제와 삭제 코딩과 같은 데이터 지속성 방법을 고려하면 스토리지 미디어에 상당한 영향을 미칠 수 있습니다.

크기 조정에 대한 자세한 내용은 OSD 하드웨어 선택에 대한 Red Hat Ceph Storage 하드웨어 선택 가이드 및 관련 링크를 참조하십시오.

2.9. 스토리지 밀도를 고려 중

Ceph 설계의 또 다른 중요한 측면에는 스토리지 밀도가 포함됩니다. 일반적으로 스토리지 클러스터는 10개 이상의 노드에 데이터를 저장하여 복제, 백필링 및 복구 시 적절한 성능을 보장합니다. 스토리지 클러스터에 노드가 10개 이상 있는 노드가 실패하면 데이터의 10%만 남아 있는 노드로 이동해야 합니다. 노드 수가 상당히 적으면 데이터의 비율이 더 높아야 합니다. 또한 스토리지 클러스터에서 데이터를 작성할 수 있도록 노드 오류를 수용하도록 full _ratio 및 near_full_ratio 옵션을 설정해야 합니다. 이러한 이유로 스토리지 밀도를 고려해야 합니다. 높은 스토리지 밀도가 반드시 좋은 아이디어는 아닙니다.

스토리지 밀도가 높은 노드를 더 선호하는 또 다른 요소는 삭제 코딩입니다. 삭제 코딩을 사용하여 오브젝트를 작성하고 최소 CRUSH 장애 도메인으로 노드를 사용하는 경우 Ceph 스토리지 클러스터에는 데이터 및 코딩 청크 수만큼의 노드가 필요합니다. 예를 들어 k=8, m=3 을 사용하는 클러스터에는 최소 11개의 노드가 있어야 각 데이터 또는 코딩 청크가 별도의 노드에 저장되어야 합니다.

핫 스와핑도 중요한 고려 사항입니다. 대부분의 최신 서버는 핫스탬프를 지원합니다. 그러나 일부 하드웨어 구성에서는 드라이브를 교체하려면 둘 이상의 드라이브를 제거해야 합니다. 실패한 디스크를 스왑할 때 필요 이상으로 더 많은 Ceph OSD를 작동할 수 있으므로 이러한 구성을 피하는 것이 좋습니다.

2.10. Ceph 모니터 노드의 디스크 고려

Ceph 모니터는 동기화된 쓰기 대기 시간에 민감한 rocksdb 를 사용합니다. Red Hat은 SSD 디스크를 사용하여 Ceph 모니터 데이터를 저장하는 것이 좋습니다. 순차적 쓰기 및 처리량 특성이 충분한 SSD 디스크를 선택합니다.

2.11. Backfill & 복구 설정 조정

I/O는 백필(backfilling) 및 복구 작업 모두에서 부정적인 영향을 미치므로 성능 저하와 불만족스러운 최종 사용자가 발생할 수 있습니다. 클러스터 확장 또는 복구 중에 I/O 수요를 수용하려면 Ceph 구성 파일에서 다음 옵션과 값을 설정합니다.

[osd]
osd_max_backfills = 1
osd_recovery_max_active = 1
osd_recovery_op_priority = 1

2.12. 클러스터 맵 크기 조정

Red Hat Ceph Storage 버전 2 이전의 경우 클러스터에 OSD가 수천 개 있는 경우 클러스터 맵을 다운로드하고 파일 크기를 확인합니다. 기본적으로 ceph-osd 데몬은 500개의 이전 osdmaps를 캐시합니다. 중복 제거와 함께 맵은 데몬당 많은 메모리를 사용할 수 있습니다. Ceph 구성 파일의 캐시 크기를 조정하면 메모리 사용량을 크게 줄일 수 있습니다. 예를 들면 다음과 같습니다.

[global]
osd_map_message_max=10

[osd]
osd_map_cache_size=20
osd_map_max_advance=10
osd_map_share_max_epochs=10
osd_pg_epoch_persisted_max_stale=10

Red Hat Ceph Storage 버전 3 이상에서는 ceph-manager 데몬이 PG 쿼리를 처리하므로 클러스터 맵이 성능에 영향을 주지 않습니다.

2.13. 스크럽 조정

기본적으로 Ceph는 매일 가벼운 스크럽과 매주 심층 스크럽을 수행합니다. 가벼운 스크럽은 PG가 동일한 개체 데이터를 저장하는지 확인하기 위해 개체 크기 및 체크섬을 확인합니다. 시간이 지남에 따라 디스크 섹터는 개체 크기 및 체크섬에 관계없이 잘못될 수 있습니다. 심층 스크럽은 실제 콘텐츠가 동일한지 확인하기 위해 복제본의 내용과 함께 개체의 콘텐츠를 확인합니다. 이와 같이 심층 스크럽은 fsck 방식으로 데이터 무결성을 보장하지만 절차는 클러스터에 I/O 페널티를 적용합니다. 가벼운 스크럽도 I/O에 영향을 줄 수 있습니다.

기본 설정을 사용하면 Ceph OSD가 최대 작동 시간 또는 로드가 많은 기간과 같이 inopportune 시간에 스크럽을 시작할 수 있습니다. 최종 사용자는 작업을 스크럽할 때 최종 사용자 작업과 충돌할 때 대기 시간 및 성능이 저하될 수 있습니다.

Ceph는 최종 사용자가 성능이 저하되지 않도록 하기 위해 여러 스크럽 설정을 제공하여 부하가 낮거나 피크 시간 외의 시간으로 스크럽을 제한할 수 있습니다. 자세한 내용은 Red Hat Ceph Storage 5 구성 가이드의 스크루 빙 섹션 을 참조하십시오.

클러스터가 야간에 하반기에 높은 부하와 낮은 부하가 발생하는 경우 스크럽을 야간 시간으로 제한하는 것이 좋습니다. 예를 들면 다음과 같습니다.

[osd]
osd_scrub_begin_hour = 23   #23:01H, or 10:01PM.
osd_scrub_end_hour = 6      #06:01H or 6:01AM.

시간 제약 조건이 스크럽 일정을 결정하는 효과적인 방법이 아닌 경우 osd_scrub_load_threshold 를 사용하는 것이 좋습니다. 기본값은 0.5 이지만 낮은 로드 조건에 맞게 수정할 수 있습니다. 예를 들면 다음과 같습니다.

[osd]
osd_scrub_load_threshold = 0.25

2.14. objecter_inflight_ops증가

RHCS 3.0 및 이전 릴리스에서는 objecter_inflight_ops 를 버전 3.1 이상 릴리스의 기본 크기로 늘려 확장성을 개선하는 것이 좋습니다.

objecter_inflight_ops = 24576

2.15. rgw_thread_pool_size증가

RHCS 3.0 및 이전 릴리스에서는 확장성을 향상시키기 위해 rgw_thread_pool_size 를 버전 3.1 및 이후 릴리스의 기본 크기로 늘리는 것이 좋습니다. 예를 들면 다음과 같습니다.

rgw_thread_pool_size = 512

2.16. Ceph를 실행할 때 Linux 커널에 대한 튜닝 고려 사항

프로덕션 Red Hat Ceph Storage 클러스터는 일반적으로 운영 체제(특히 제한 및 메모리 할당)를 튜닝하면 이점이 있습니다. 스토리지 클러스터 내의 모든 노드에 맞게 조정이 설정되어 있는지 확인합니다. 추가 지침을 요청하는 Red Hat 지원 케이스도 열 수 있습니다.

Ceph OSD의 여유 메모리 예약

Ceph OSD 메모리 할당 요청 중에 메모리 관련 오류가 충분하지 않게 하려면 예약에 유지하도록 특정 물리 메모리 양을 설정합니다. Red Hat은 시스템 RAM 용량에 따라 다음 설정을 권장합니다.

  • 64GB의 경우 1GB를 예약하십시오.

    vm.min_free_kbytes = 1048576
  • 128GB의 경우 2GB를 예약하십시오.

    vm.min_free_kbytes = 2097152
  • 256GB의 경우 3GB를 예약하십시오.

    vm.min_free_kbytes = 3145728

파일 디스크립터 증가

파일 설명자가 없으면 Ceph 개체 게이트웨이가 중지될 수 있습니다. Ceph Object Gateway 노드에서 /etc/security/limits.conf 파일을 수정하여 Ceph Object Gateway의 파일 설명자를 늘릴 수 있습니다.

ceph       soft    nofile     unlimited

대용량 스토리지 클러스터의 ulimit 값 조정

대규모 스토리지 클러스터에서 Ceph 관리 명령을 실행하는 경우(예: 1024 Ceph OSD 사용) 다음 콘텐츠를 사용하여 관리 명령을 실행하는 각 노드에 /etc/security/limits.d/50-ceph.conf 파일을 생성합니다.

USER_NAME       soft    nproc     unlimited

USER_NAME 을 Ceph 관리 명령을 실행하는 루트가 아닌 사용자 계정의 이름으로 바꿉니다.

참고

Red Hat Enterprise Linux에서 root 사용자의 ulimit 값은 기본적으로 무제한 으로 설정되어 있습니다.

2.17. 추가 리소스

3장. Deployment

스토리지 관리자는 명령줄 인터페이스를 사용하거나 서비스 사양을 사용하여 Ceph Orchestrator를 사용하여 Ceph Object Gateway를 배포할 수 있습니다. Ceph Orchestrator를 사용하여 다중 사이트 Ceph Object Gateway를 구성하고 Ceph Object Gateway를 제거할 수도 있습니다.

cephadm 명령은 Ceph Object Gateway를 다중 사이트 배포에서 단일 클러스터 배포 또는 특정 영역 및 영역을 관리하는 데몬 컬렉션으로 배포합니다.

참고

cephadm 을 사용하면 Ceph Object Gateway 데몬은 ceph.conf 파일 또는 명령줄 옵션 대신 Ceph Monitor 구성 데이터베이스를 사용하여 구성됩니다. 구성이 client.rgw 섹션에 없는 경우 Ceph Object Gateway 데몬은 기본 설정으로 시작하고 포트 80 에 바인드됩니다.

이 섹션에서는 다음과 같은 관리 작업을 다룹니다.

3.1. 사전 요구 사항

  • 실행 중이고 정상적인 Red Hat Ceph Storage 클러스터.
  • 모든 노드에 대한 루트 수준 액세스.
  • 스토리지 클러스터를 사용할 수 있는 노드입니다.
  • 모든 관리자, 모니터 및 OSD는 스토리지 클러스터에 배포됩니다.

3.2. 명령줄 인터페이스를 사용하여 Ceph Object Gateway 배포

Ceph Orchestrator를 사용하면 명령줄 인터페이스에서 ceph orch 명령을 사용하여 Ceph 개체 게이트웨이를 배포할 수 있습니다.

사전 요구 사항

  • 실행 중인 Red Hat Ceph Storage 클러스터.
  • 모든 노드에 대한 루트 수준 액세스.
  • 호스트가 클러스터에 추가됩니다.
  • 모든 관리자, 모니터 및 OSD 데몬이 배포됩니다.

절차

  1. Cephadm 쉘에 로그인합니다.

    예제

    [root@host01 ~]# cephadm shell

  2. Ceph 개체 게이트웨이 데몬을 다음 세 가지 방법으로 배포할 수 있습니다.

방법 1

  • 영역, 영역 그룹, 영역을 생성한 다음 호스트 이름으로 배치 사양을 사용합니다.

    1. 영역을 생성합니다.

      구문

      radosgw-admin realm create --rgw-realm=REALM_NAME --default

      예제

      [ceph: root@host01 /]# radosgw-admin realm create --rgw-realm=test_realm --default

    2. 영역 그룹을 생성합니다.

      구문

      radosgw-admin zonegroup create --rgw-zonegroup=ZONE_GROUP_NAME  --master --default

      예제

      [ceph: root@host01 /]# radosgw-admin zonegroup create --rgw-zonegroup=default  --master --default

    3. 영역을 생성합니다.

      구문

      radosgw-admin zone create --rgw-zonegroup=ZONE_GROUP_NAME --rgw-zone=ZONE_NAME --master --default

      예제

      [ceph: root@host01 /]# radosgw-admin zone create --rgw-zonegroup=default --rgw-zone=test_zone --master --default

    4. 변경 사항을 커밋합니다.

      구문

      radosgw-admin period update --rgw-realm=REALM_NAME --commit

      예제

      [ceph: root@host01 /]# radosgw-admin period update --rgw-realm=test_realm --commit

    5. ceph orch apply 명령을 실행합니다.

      구문

      ceph orch apply rgw NAME [--realm=REALM_NAME] [--zone=ZONE_NAME] --placement="NUMBER_OF_DAEMONS [HOST_NAME_1 HOST_NAME_2]"

      예제

      [ceph: root@host01 /]# ceph orch apply rgw test --realm=test_realm --zone=test_zone --placement="2 host01 host02"

방법 2

  • 임의의 서비스 이름을 사용하여 단일 클러스터 배포에 대해 두 개의 Ceph 개체 게이트웨이 데몬을 배포합니다.

    구문

    ceph orch apply rgw SERVICE_NAME

    예제

    [ceph: root@host01 /]# ceph orch apply rgw foo

방법 3

  • 레이블이 지정된 호스트 집합에 임의의 서비스 이름을 사용합니다.

    구문

    ceph orch host label add HOST_NAME_1 LABEL_NAME
    ceph orch host label add HOSTNAME_2 LABEL_NAME
    ceph orch apply rgw SERVICE_NAME '--placement=label:_LABEL_NAME_ count-per-host:_NUMBER_OF_DAEMONS_' --port=8000

    예제

    [ceph: root@host01 /]# ceph orch host label add host01 rgw  # the 'rgw' label can be anything
    [ceph: root@host01 /]# ceph orch host label add host02 rgw
    [ceph: root@host01 /]# ceph orch apply rgw foo '--placement=label:rgw count-per-host:2' --port=8000

검증

  • 서비스를 나열합니다.

    예제

    [ceph: root@host01 /]# ceph orch ls

  • 호스트, 데몬 및 프로세스를 나열합니다.

    구문

    ceph orch ps --daemon_type=DAEMON_NAME

    예제

    [ceph: root@host01 /]# ceph orch ps --daemon_type=rgw

3.3. 서비스 사양을 사용하여 Ceph Object Gateway 배포

Ceph Orchestrator를 사용하여 서비스 사양을 사용하여 Ceph 개체 게이트웨이를 배포할 수 있습니다.

사전 요구 사항

  • 실행 중인 Red Hat Ceph Storage 클러스터.
  • 모든 노드에 대한 루트 수준 액세스.
  • 호스트가 클러스터에 추가됩니다.
  • 모든 관리자, 모니터 및 OSD 데몬이 배포됩니다.

절차

  1. Cephadm 쉘에 로그인합니다.

    예제

    [root@host01 ~]# cephadm shell

  2. 다음 디렉터리로 이동합니다.

    구문

    cd /var/lib/ceph/DAEMON_PATH/

    예제

    [ceph: root@host01 nfs/]# cd /var/lib/ceph/rgw/

    rgw 디렉터리가 없는 경우 경로에 디렉터리를 만듭니다.

  3. rgw.yml 파일을 만듭니다.

    예제

    [ceph: root@host01 rgw]# touch rgw.yml

  4. rgw.yml 파일을 편집하여 다음 세부 정보를 포함합니다.

    구문

    service_type: rgw
    service_id: REALM_NAME.ZONE_NAME
    placement:
      hosts:
      - HOST_NAME_1
      - HOST_NAME_2
    spec:
      rgw_realm: REALM_NAME
      rgw_zone: ZONE_NAME
    networks:
      -  NETWORK_IP_ADDRESS # RGW service binds to a specific network

    예제

    service_type: rgw
    service_id: test_realm.test_zone
    placement:
      hosts:
      - host01
      - host02
      - host03
    spec:
      rgw_realm: test_realm
      rgw_zone: test_zone
    networks:
      - 192.169.142.0/24

  5. 서비스 사양을 사용하여 Ceph 오브젝트 게이트웨이를 배포합니다.

    구문

    ceph orch apply -i FILE_NAME.yml

    예제

    [ceph: root@host01 rgw]# ceph orch apply -i rgw.yml

검증

  • 서비스를 나열합니다.

    예제

    [ceph: root@host01 /]# ceph orch ls

  • 호스트, 데몬 및 프로세스를 나열합니다.

    구문

    ceph orch ps --daemon_type=DAEMON_NAME

    예제

    [ceph: root@host01 /]# ceph orch ps --daemon_type=rgw

3.4. Ceph Orchestrator를 사용하여 다중 사이트 Ceph Object Gateway 배포

Ceph 오케스트레이션에서는 Ceph Object Gateway에 대한 다중 사이트 구성 옵션을 지원합니다.

각 오브젝트 게이트웨이가 액티브-액티브 영역 구성에서 작동하도록 구성하여 기본이 아닌 영역에 쓸 수 있습니다. 다중 사이트 구성은 영역이라는 컨테이너 내에 저장됩니다.

이 영역에서는 영역 그룹, 영역 및 기간을 저장합니다. rgw 데몬은 별도의 동기화 에이전트가 필요하지 않은 동기화를 처리하므로 액티브-액티브 구성으로 작동합니다.

CLI(명령줄 인터페이스)를 사용하여 다중 사이트 영역을 배포할 수도 있습니다.

참고

다음 구성에서는 두 개 이상의 Red Hat Ceph Storage 클러스터가 지리적으로 분리된 위치에 있다고 가정합니다. 그러나 이 구성은 동일한 사이트에서도 작동합니다.

사전 요구 사항

  • Red Hat Ceph Storage 클러스터 2개 이상 실행 중
  • Ceph Object Gateway 인스턴스 2개 이상(Red Hat Ceph Storage 클러스터당 하나씩).
  • 모든 노드에 대한 루트 수준 액세스.
  • 스토리지 클러스터에 노드 또는 컨테이너가 추가됩니다.
  • 모든 Ceph Manager, Monitor 및 OSD 데몬이 배포됩니다.

절차

  1. cephadm 쉘에서 기본 영역을 구성합니다.

    1. 영역을 생성합니다.

      구문

      radosgw-admin realm create --rgw-realm=REALM_NAME --default

      예제

      [ceph: root@host01 /]# radosgw-admin realm create --rgw-realm=test_realm --default

      스토리지 클러스터에 단일 영역이 있는 경우 --default 플래그를 지정합니다.

    2. 기본 영역 그룹을 생성합니다.

      구문

      radosgw-admin zonegroup create --rgw-zonegroup=ZONE_GROUP_NAME --endpoints=http://RGW_PRIMARY_HOSTNAME:_RGW_PRIMARY_PORT_NUMBER_1_ --master --default

      예제

      [ceph: root@host01 /]# radosgw-admin zonegroup create --rgw-zonegroup=us --endpoints=http://rgw1:80 --master --default

    3. 기본 영역을 생성합니다.

      구문

      radosgw-admin zone create --rgw-zonegroup=PRIMARY_ZONE_GROUP_NAME --rgw-zone=PRIMARY_ZONE_NAME --endpoints=http://RGW_PRIMARY_HOSTNAME:_RGW_PRIMARY_PORT_NUMBER_1_ --access-key=SYSTEM_ACCESS_KEY --secret=SYSTEM_SECRET_KEY

      예제

      [ceph: root@host01 /]# radosgw-admin zone create --rgw-zonegroup=us --rgw-zone=us-east-1 --endpoints=http://rgw1:80

    4. 선택 사항: 기본 영역, 영역 그룹 및 관련 풀을 삭제합니다.

      중요

      기본 영역 및 영역 그룹을 사용하여 데이터를 저장하는 경우 기본 영역과 해당 풀을 삭제하지 마십시오. 또한 기본 영역 그룹을 제거하면 시스템 사용자를 삭제합니다.

      예제

      [ceph: root@host01 /]# radosgw-admin zonegroup delete --rgw-zonegroup=default
      [ceph: root@host01 /]# ceph osd pool rm default.rgw.log default.rgw.log --yes-i-really-really-mean-it
      [ceph: root@host01 /]# ceph osd pool rm default.rgw.meta default.rgw.meta --yes-i-really-really-mean-it
      [ceph: root@host01 /]# ceph osd pool rm default.rgw.control default.rgw.control --yes-i-really-really-mean-it
      [ceph: root@host01 /]# ceph osd pool rm default.rgw.data.root default.rgw.data.root --yes-i-really-really-mean-it
      [ceph: root@host01 /]# ceph osd pool rm default.rgw.gc default.rgw.gc --yes-i-really-really-mean-it

    5. 시스템 사용자를 생성합니다.

      구문

      radosgw-admin user create --uid=USER_NAME --display-name="USER_NAME" --access-key=SYSTEM_ACCESS_KEY --secret=SYSTEM_SECRET_KEY --system

      예제

      [ceph: root@host01 /]# radosgw-admin user create --uid=zone.user --display-name="Zone user" --system

      access_key 및 secret_key 를 기록합니다.

    6. 기본 영역에 액세스 키와 시스템 키를 추가합니다.

      구문

      radosgw-admin zone modify --rgw-zone=PRIMARY_ZONE_NAME --access-key=ACCESS_KEY --secret=SECRET_KEY

      예제

      [ceph: root@host01 /]# radosgw-admin zone modify --rgw-zone=us-east-1 --access-key=NE48APYCAODEPLKBCZVQ--secret=u24GHQWRE3yxxNBnFBzjM4jn14mFIckQ4EKL6LoW

    7. 변경 사항을 커밋합니다.

      구문

      radosgw-admin period update --commit

      예제

      [ceph: root@host01 /]# radosgw-admin period update --commit

    8. cephadm 쉘 외부에서 스토리지 클러스터 및 프로세스의 FSID 를 가져옵니다.

      예제

      [root@host01 ~]#  systemctl list-units | grep ceph

    9. Ceph Object Gateway 데몬을 시작합니다.

      구문

      systemctl start ceph-FSID@DAEMON_NAME
      systemctl enable ceph-FSID@DAEMON_NAME

      예제

      [root@host01 ~]# systemctl start ceph-62a081a6-88aa-11eb-a367-001a4a000672@rgw.test_realm.us-east-1.host01.ahdtsw.service
      [root@host01 ~]# systemctl enable ceph-62a081a6-88aa-11eb-a367-001a4a000672@rgw.test_realm.us-east-1.host01.ahdtsw.service

  2. Cephadm 쉘에서 보조 영역을 구성합니다.

    1. 호스트에서 기본 영역 구성을 가져옵니다.

      구문

      radosgw-admin realm pull --url=URL_TO_PRIMARY_ZONE_GATEWAY --access-key=ACCESS_KEY --secret-key=SECRET_KEY

      예제

      [ceph: root@host04 /]# radosgw-admin realm pull --url=http://10.74.249.26:80 --access-key=LIPEYZJLTWXRKXS9LPJC --secret-key=IsAje0AVDNXNw48LjMAimpCpI7VaxJYSnfD0FFKQ

    2. 호스트에서 기본 기간 구성을 가져옵니다.

      구문

      radosgw-admin period pull --url=URL_TO_PRIMARY_ZONE_GATEWAY --access-key=ACCESS_KEY --secret-key=SECRET_KEY

      예제

      [ceph: root@host04 /]# radosgw-admin period pull --url=http://10.74.249.26:80 --access-key=LIPEYZJLTWXRKXS9LPJC --secret-key=IsAje0AVDNXNw48LjMAimpCpI7VaxJYSnfD0FFKQ

    3. 보조 영역을 구성합니다.

      구문

      radosgw-admin zone create --rgw-zonegroup=ZONE_GROUP_NAME \
                   --rgw-zone=SECONDARY_ZONE_NAME --endpoints=http://RGW_SECONDARY_HOSTNAME:_RGW_PRIMARY_PORT_NUMBER_1_ \
                   --access-key=SYSTEM_ACCESS_KEY --secret=SYSTEM_SECRET_KEY \
                   --endpoints=http://FQDN:80 \
                   [--read-only]

      예제

      [ceph: root@host04 /]# radosgw-admin zone create --rgw-zonegroup=us --rgw-zone=us-east-2 --endpoints=http://rgw2:80 --access-key=LIPEYZJLTWXRKXS9LPJC --secret-key=IsAje0AVDNXNw48LjMAimpCpI7VaxJYSnfD0FFKQ

    4. 선택 사항: 기본 영역을 삭제합니다.

      중요

      기본 영역 및 영역 그룹을 사용하여 데이터를 저장하는 경우 기본 영역과 해당 풀을 삭제하지 마십시오.

      예제

      [ceph: root@host04 /]# radosgw-admin zone rm --rgw-zone=default
      [ceph: root@host04 /]# ceph osd pool rm default.rgw.log default.rgw.log --yes-i-really-really-mean-it
      [ceph: root@host04 /]# ceph osd pool rm default.rgw.meta default.rgw.meta --yes-i-really-really-mean-it
      [ceph: root@host04 /]# ceph osd pool rm default.rgw.control default.rgw.control --yes-i-really-really-mean-it
      [ceph: root@host04 /]# ceph osd pool rm default.rgw.data.root default.rgw.data.root --yes-i-really-really-mean-it
      [ceph: root@host04 /]# ceph osd pool rm default.rgw.gc default.rgw.gc --yes-i-really-really-mean-it

    5. Ceph 구성 데이터베이스를 업데이트합니다.

      구문

      ceph config set _SERVICE_NAME_ rgw_zone _SECONDARY_ZONE_NAME_

      예제

      [ceph: root@host04 /]# ceph config set rgw rgw_zone us-east-2

    6. 변경 사항을 커밋합니다.

      구문

      radosgw-admin period update --commit

      예제

      [ceph: root@host04 /]# radosgw-admin period update --commit

    7. Cephadm 쉘 외부에서 스토리지 클러스터의 FSID와 프로세스를 가져옵니다.

      예제

      [root@host04 ~]#  systemctl list-units | grep ceph

    8. Ceph Object Gateway 데몬을 시작합니다.

      구문

      systemctl start ceph-FSID@DAEMON_NAME
      systemctl enable ceph-FSID@DAEMON_NAME

      예제

      [root@host04 ~]# systemctl start ceph-62a081a6-88aa-11eb-a367-001a4a000672@rgw.test_realm.us-east-2.host04.ahdtsw.service
      [root@host04 ~]# systemctl enable ceph-62a081a6-88aa-11eb-a367-001a4a000672@rgw.test_realm.us-east-2.host04.ahdtsw.service

  3. 선택 사항: 배치 사양을 사용하여 다중 사이트 Ceph Object Gateway를 배포합니다.

    구문

    ceph orch apply rgw _NAME_ --realm=_REALM_NAME_ --zone=_PRIMARY_ZONE_NAME_ --placement="_NUMBER_OF_DAEMONS_ _HOST_NAME_1_ _HOST_NAME_2_"

    예제

    [ceph: root@host04 /]# ceph orch apply rgw east --realm=test_realm --zone=us-east-1 --placement="2 host01 host02"

검증

  • 동기화 상태를 확인하여 배포를 확인합니다.

    예제

    [ceph: root@host04 /]# radosgw-admin sync status

3.5. Ceph Orchestrator를 사용하여 Ceph Object Gateway 제거

ceph orch rm 명령을 사용하여 Ceph 오브젝트 게이트웨이 데몬을 제거할 수 있습니다.

사전 요구 사항

  • 실행 중인 Red Hat Ceph Storage 클러스터.
  • 모든 노드에 대한 루트 수준 액세스.
  • 호스트가 클러스터에 추가됩니다.
  • 호스트에 배포된 Ceph 개체 게이트웨이 데몬이 하나 이상 있습니다.

절차

  1. Cephadm 쉘에 로그인합니다.

    예제

    [root@host01 ~]# cephadm shell

  2. 서비스를 나열합니다.

    예제

    [ceph: root@host01 /]# ceph orch ls

    1. 서비스 제거

      구문

      ceph orch rm SERVICE_NAME

      예제

      [ceph: root@host01 /]# ceph orch rm rgw.test_realm.test_zone_bb

검증

  • 호스트, 데몬 및 프로세스를 나열합니다.

    구문

    ceph orch ps

    예제

    [ceph: root@host01 /]# ceph orch ps

추가 리소스

4장. 기본 설정

스토리지 관리자는 Ceph Object Gateway 구성의 기본 사항을 알 수 있습니다. 기본값과 Beast라는 포함된 웹 서버에 대해 알아볼 수 있습니다. Ceph Object Gateway 문제 해결을 위해 Ceph Object Gateway에서 생성한 로깅 및 디버깅 출력을 조정하는 방법을 배울 수 있습니다. 또한 Ceph Object Gateway를 사용하여 스토리지 클러스터 액세스를 위해 고가용성 프록시를 제공하는 방법에 대해서도 알아봅니다.

4.1. 사전 요구 사항

  • 실행 중이고 정상적인 Red Hat Ceph Storage 클러스터.
  • Ceph Object Gateway 소프트웨어 패키지 설치.

4.2. DNS에 와일드카드 추가

S3 스타일 하위 도메인과 함께 Ceph를 사용하려면(예: bucket-name.domain-name.com ) 데몬 에서 도메인 이름을 확인하는 데 사용하는 DNS 서버의 DNS 레코드에 와일드카드를 추가합니다.

dnsmasq 의 경우 호스트 이름에 앞에 점(.)을 사용하여 다음 주소 설정을 추가합니다.

address=/.{hostname-or-fqdn}/{host-ip-address}

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

address=/.gateway-node1/192.168.122.75

바인드 하려면 DNS 레코드에 와일드카드를 추가합니다. 예를 들면 다음과 같습니다.

$TTL    604800
@       IN      SOA     gateway-node1. root.gateway-node1. (
                              2         ; Serial
                         604800         ; Refresh
                          86400         ; Retry
                        2419200         ; Expire
                         604800 )       ; Negative Cache TTL
;
@       IN      NS      gateway-node1.
@       IN      A       192.168.122.113
*       IN      CNAME   @

DNS 서버를 다시 시작하고 하위 도메인으로 서버를 ping하여 ceph-radosgw 데몬이 하위 도메인 요청을 처리할 수 있는지 확인합니다.

ping mybucket.{hostname}

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

ping mybucket.gateway-node1

DNS 서버가 로컬 시스템에 있는 경우 로컬 시스템의 nameserver 항목을 추가하여 /etc/resolv.conf 를 수정해야 할 수 있습니다.

마지막으로 DNS 서버의 호스트 이름 또는 주소를 지정합니다.

구문

ceph config set client.rgw rgw_dns_name VALUE

예제

[root@mon ~]# ceph config set client.rgw rgw_dns_name client01

마지막으로 DNS 설정이 적용되도록 Ceph Object Gateway를 다시 시작합니다.

추가 리소스

4.3. Beast 프론트 엔드 웹 서버

Ceph 개체 게이트웨이는 포함된 C/C 내장 프런트 엔드 웹 서버인 Beast를 제공합니다. beast는 'Boost.Beast' C 라이브러리를 사용하여 HTTP를 구문 분석하고 Boost.Asio 는 비동기 네트워크 I/O를 수행합니다.

4.4. Beast의 SSL 구성

OpenSSL 라이브러리를 사용하여 TLS(Transport Layer Security)를 제공하도록 Beast 프런트 엔드 웹 서버를 구성할 수 있습니다. Beast와 함께 SSL(Secure Socket Layer)을 사용하려면 Ceph Object Gateway 노드의 호스트 이름과 일치하는 CA(인증 기관)에서 인증서를 가져와야 합니다. 또한 Beast에는 단일. pem 파일에 있는 비밀 키, 서버 인증서 및 기타 CA가 필요합니다.

중요

비밀 키 해시가 포함되어 있기 때문에 .pem 파일에 대한 무단 액세스를 방지합니다.

중요

Red Hat은 SAN(Subject Alternative Name) 필드가 있는 CA와 S3 스타일 하위 도메인과 함께 사용할 와일드카드를 가져오는 것이 좋습니다.

중요

Red Hat은 소규모에서 중간 규모의 테스트 환경에 대해 Beast 프런트 엔드 웹 서버에서만 SSL을 사용할 것을 권장합니다. 프로덕션 환경의 경우 HAProxy를 사용하고 keepalived 를 사용하여 HAProxy에서 SSL 연결을 종료해야 합니다.

사전 요구 사항

  • 실행 중이고 정상적인 Red Hat Ceph Storage 클러스터.
  • Ceph Object Gateway 소프트웨어 패키지 설치.
  • OpenSSL 소프트웨어 패키지 설치.
  • Ceph Object Gateway 노드에 대한 루트 수준 액세스.

절차

  1. 현재 디렉터리에 rgw.yml 이라는 새 파일을 만듭니다.

    예제

    [root@rgw ~]# touch rgw.yml

  2. 편집할 rgw.yml 파일을 열고 환경에 맞게 사용자 지정합니다.

    구문

    service_type: rgw
    service_id: SERVICE_ID
    service_name: SERVICE_NAME
    placement:
      hosts:
      - HOST_NAME
    spec:
      ssl: true
      rgw_frontend_ssl_certificate: CERT_HASH

    예제

    service_type: rgw
    service_id: foo
    service_name: rgw.foo
    placement:
      hosts:
      - host1
    spec:
      ssl: true
      rgw_frontend_ssl_certificate: |
        -----BEGIN RSA PRIVATE KEY-----
        MIIEpAIBAAKCAQEA+Cf4l9OagD6x67HhdCy4Asqw89Zz9ZuGbH50/7ltIMQpJJU0
        gu9ObNtIoC0zabJ7n1jujueYgIpOqGnhRSvsGJiEkgN81NLQ9rqAVaGpadjrNLcM
        bpgqJCZj0vzzmtFBCtenpb5l/EccMFcAydGtGeLP33SaWiZ4Rne56GBInk6SATI/
        JSKweGD1y5GiAWipBR4C74HiAW9q6hCOuSdp/2WQxWT3T1j2sjlqxkHdtInUtwOm
        j5Ism276IndeQ9hR3reFR8PJnKIPx73oTBQ7p9CMR1J4ucq9Ny0J12wQYT00fmJp
        -----END RSA PRIVATE KEY-----
        -----BEGIN CERTIFICATE-----
        MIIEBTCCAu2gAwIBAgIUGfYFsj8HyA9Zv2l600hxzT8+gG4wDQYJKoZIhvcNAQEL
        BQAwgYkxCzAJBgNVBAYTAklOMQwwCgYDVQQIDANLQVIxDDAKBgNVBAcMA0JMUjEM
        MAoGA1UECgwDUkhUMQswCQYDVQQLDAJCVTEkMCIGA1UEAwwbY2VwaC1zc2wtcmhj
        czUtOGRjeHY2LW5vZGU1MR0wGwYJKoZIhvcNAQkBFg5hYmNAcmVkaGF0LmNvbTAe
        -----END CERTIFICATE-----

  3. 서비스 사양 파일을 사용하여 Ceph Object Gateway를 배포합니다.

    예제

    [root@rgw ~]# ceph orch apply -i rgw.yml

4.5. 로깅 및 디버깅 출력 조정

설정 절차를 완료한 후 로깅 출력을 확인하여 요구 사항을 충족하는지 확인합니다. 기본적으로 Ceph 데몬은 to journald 에 로그를 기록하며 journalctl 명령을 사용하여 로그를 볼 수 있습니다. 또는 /var/log/ceph/CEPH_CLUSTER_ID/ 디렉터리에 있는 파일에 대한 Ceph 데몬 로그를 포함할 수도 있습니다.

중요

상세 로깅은 시간당 1GB의 데이터를 생성할 수 있습니다. 이러한 유형의 로깅은 잠재적으로 운영 체제의 디스크를 채울 수 있으므로 운영 체제가 작동하지 않습니다.

사전 요구 사항

  • 실행 중인 Red Hat Ceph Storage 클러스터.
  • Ceph Object Gateway 소프트웨어 설치.

절차

  1. Ceph Object Gateway 로깅 출력을 늘리려면 다음 매개변수를 설정합니다.

    구문

    ceph config set client.rgw debug_rgw VALUE

    예제

    [root@rgw ~]# ceph config set client.rgw debug_rgw 20

    1. 이러한 설정은 런타임 시 수정할 수도 있습니다.

      구문

      ceph --admin-daemon /var/run/ceph/ceph-client.rgw.NAME.asok config set debug_rgw VALUE

      예제

      [root@rgw ~]# ceph --admin-daemon /var/run/ceph/ceph-client.rgw.rgw.asok config set debug_rgw 20

  2. 선택적으로 출력을 파일에 기록하도록 Ceph 데몬을 구성할 수 있습니다. log_to_filemon_cluster_log_to_file 옵션을 true로 설정합니다.

    예제

    [root@rgw ~]# ceph config set global log_to_file true
    [root@rgw ~]# ceph config set global mon_cluster_log_to_file true

추가 리소스

4.6. 정적 웹 호스팅

스토리지 관리자는 S3 버킷에서 정적 웹사이트를 호스팅하도록 Ceph Object Gateway를 구성할 수 있습니다. 기존 웹 사이트 호스팅에는 콘텐츠가 동적으로 변경되지 않을 때 비효율적으로 리소스를 사용할 수 있는 각 웹 사이트에 대해 웹 서버를 구성하는 작업이 포함됩니다. 예를 들어 PHP, 서블릿, 데이터베이스, nodejs 등과 같은 서버 측 서비스를 사용하지 않는 사이트. 이 접근 방식은 각 사이트에 대해 웹 서버를 사용하는 가상 시스템을 설정하는 것보다 훨씬 더 경제적입니다.

4.6.1. 사전 요구 사항

  • 정상적으로 실행 중인 Red Hat Ceph Storage 클러스터.

4.6.2. 정적 웹 호스팅 가정

정적 웹 호스팅에는 Red Hat Ceph Storage 클러스터가 하나 이상 실행되고 정적 웹 사이트에 대해 Ceph Object Gateway 인스턴스가 2개 이상 필요합니다. Red Hat은 각 영역에 HA(고가용성) 프록시 및 keepalived 와 같은 로드 밸런서를 사용하는 여러 게이트웨이 인스턴스가 있다고 가정합니다.

중요

Red Hat 은 Ceph Object Gateway 인스턴스를 사용하여 표준 S3/Swift API와 정적 웹 호스팅을 동시에 배포하는 것을 지원하지 않습니다.

추가 리소스

4.6.3. 정적 웹 호스팅 요구 사항

정적 웹 호스팅 기능은 자체 API를 사용하므로 S3 버킷에서 정적 웹 사이트를 사용하도록 게이트웨이를 구성하려면 다음이 필요합니다.

  1. S3 정적 웹 호스팅에서는 표준 S3/Swift API 사용 사례에 사용되는 인스턴스와 별도의 Ceph Object Gateway 인스턴스를 사용합니다.
  2. S3 정적 웹 사이트를 호스팅하는 게이트웨이 인스턴스에는 표준 S3/Swift API 게이트웨이 인스턴스와 중복되지 않은 별도의 도메인 이름이 있어야 합니다.
  3. S3 정적 웹 사이트를 호스팅하는 게이트웨이 인스턴스는 표준 S3/Swift API 게이트웨이 인스턴스에서 별도의 공용 방향 IP 주소를 사용해야 합니다.
  4. S3 정적 웹 사이트 부하 분산을 호스팅하는 게이트웨이 인스턴스와 필요한 경우 HAProxy/keepalived를 사용하여 SSL을 종료합니다.

4.6.4. 정적 웹 호스팅 게이트웨이 설정

정적 웹 호스팅을 위해 Ceph Object Gateway를 활성화하려면 다음 옵션을 설정합니다.

구문

ceph config set client.rgw OPTION VALUE

예제

[root@mon ~]# ceph config set client.rgw rgw_enable_static_website true
[root@mon ~]# ceph config set client.rgw rgw_enable_apis s3,s3website
[root@mon ~]# ceph config set client.rgw rgw_dns_name objects-zonegroup.example.com
[root@mon ~]# ceph config set client.rgw rgw_dns_s3website_name objects-website-zonegroup.example.com
[root@mon ~]# ceph config set client.rgw rgw_resolve_cname true

rgw_enable_static_website 설정은 true 여야 합니다. rgw_enable_apis 설정은 s3website API를 활성화해야 합니다. rgw_dns_namergw_dns_s3website_name 설정은 정규화된 도메인을 제공해야 합니다. 사이트에서 정식 이름 확장을 사용하는 경우 rgw_resolve_cname 옵션을 true로 설정합니다.

중요

rgw_dns_name 및 rgw_dns _s3website_name 의 FQDN은 중복 되지 않아야 합니다.

4.6.5. 정적 웹 호스팅 DNS 구성

다음은 가정 DNS 설정의 예입니다. 여기서 처음 두 줄은 표준 S3 인터페이스를 사용하여 게이트웨이 인스턴스의 도메인을 지정하고 각각 IPv4 및 IPv6 주소를 가리킵니다. 세 번째 줄에서는 정식 이름 확장을 사용하여 S3 버킷에 대한 와일드카드 CNAME 설정을 제공합니다. 네 번째 및 다섯 번째 행은 S3 웹사이트 인터페이스를 사용하여 게이트웨이 인스턴스의 도메인을 지정하고 해당 IPv4 및 IPv6 주소를 각각 가리킵니다.

objects-zonegroup.domain.com. IN    A 192.0.2.10
objects-zonegroup.domain.com. IN AAAA 2001:DB8::192:0:2:10
*.objects-zonegroup.domain.com. IN CNAME objects-zonegroup.domain.com.
objects-website-zonegroup.domain.com. IN    A 192.0.2.20
objects-website-zonegroup.domain.com. IN AAAA 2001:DB8::192:0:2:20
참고

처음 두 행의 IP 주소는 네 번째 및 다섯 번째 행의 IP 주소와 다릅니다.

다중 사이트 구성에서 Ceph Object Gateway를 사용하는 경우 라우팅 솔루션을 사용하여 클라이언트와 가장 가까운 게이트웨이로 트래픽을 라우팅하는 것이 좋습니다.

AWS(Amazon Web Service)에는 호스트 이름과 일치하도록 정적 웹 호스트 버킷이 필요합니다. Ceph는 DNS를 구성하는 몇 가지 다른 방법을 제공하며 프록시에 일치하는 인증서가 있는 경우 HTTPS가 작동합니다.

하위 도메인의 버킷에 대한 호스트 이름

AWS 스타일 S3 하위 도메인을 사용하려면 DNS 항목에서 와일드카드를 사용하고 요청을 버킷으로 리디렉션할 수 있습니다. DNS 항목은 다음과 같을 수 있습니다.

*.objects-website-zonegroup.domain.com. IN CNAME objects-website-zonegroup.domain.com.

다음 방식으로 버킷 이름에 액세스합니다.

http://bucket1.objects-website-zonegroup.domain.com

여기서 버킷 이름은 bucket1 입니다.

호스트 이름을 비일치 버킷으로

Ceph에서는 요청에 버킷 이름을 포함하지 않고 Ceph Object Gateway에 고유한 도메인 이름을 버킷에 매핑할 수 있습니다. 도메인 이름을 사용하여 버킷에 액세스하려면 도메인 이름을 버킷 이름에 매핑합니다. DNS 항목은 다음과 같을 수 있습니다.

www.example.com. IN CNAME bucket2.objects-website-zonegroup.domain.com.

버킷 이름이 bucket2인 위치입니다.

다음 방식으로 버킷에 액세스합니다.

http://www.example.com

CNAME을 사용하여 긴 버킷으로 호스트 이름

AWS에는 일반적으로 버킷 이름이 도메인 이름과 일치해야 합니다. CNAME을 사용하여 정적 웹 호스팅을 위해 DNS를 구성하려면 DNS 항목이 다음과 같을 수 있습니다.

www.example.com. IN CNAME www.example.com.objects-website-zonegroup.domain.com.

다음 방식으로 버킷에 액세스합니다.

http://www.example.com

CNAME없이 긴 버킷으로 호스트 이름

DNS 이름에 SOA,NS,MX 또는 TXT 와 같은 CNAME 이외의 다른 레코드가 포함된 경우 DNS 레코드는 도메인 이름을 IP 주소에 직접 매핑해야 합니다. 예를 들면 다음과 같습니다.

www.example.com. IN A 192.0.2.20
www.example.com. IN AAAA 2001:DB8::192:0:2:20

다음 방식으로 버킷에 액세스합니다.

http://www.example.com

4.6.6. 정적 웹 호스팅 사이트 생성

정적 웹 사이트를 생성하려면 다음 단계를 수행합니다.

  1. S3 버킷을 생성합니다. 버킷 이름은 웹사이트의 도메인 이름과 같습니다. 예를 들어 mysite.com 에는 mysite.com의 버킷 이름이 있을 수 있습니다. 이는 AWS에 필요하지만 Ceph에는 필요하지 않습니다. 자세한 내용은 DNS 설정을 참조하십시오.
  2. 정적 웹사이트 콘텐츠를 버킷에 업로드합니다. 콘텐츠에는 HTML, CSS, 클라이언트측 JavaScript, 이미지, 오디오/비디오 콘텐츠 및 기타 다운로드 가능한 파일이 포함될 수 있습니다. 웹 사이트에는 index.html 파일이 있고 MAY에는 error.html 파일이 있어야 합니다.
  3. 웹 사이트의 콘텐츠를 확인합니다. 이때 버킷 생성자만 컨텐츠에 액세스할 수 있습니다.
  4. 공개적으로 읽을 수 있도록 파일에 대한 권한을 설정합니다.

4.7. HA 프록시 및 keepalived

스토리지 관리자는 Ceph Object Gateway의 많은 인스턴스를 단일 영역에 할당할 수 있습니다. 이렇게 하면 부하가 증가하면, 즉 동일한 영역 그룹 및 영역을 확장할 수 있지만 HAProxy 및 keepalived 를 사용하기 위해 통합 아키텍처가 필요하지 않습니다. 각 오브젝트 게이트웨이 인스턴스에는 자체 IP 주소가 있으므로 HAProxy 및 keepalived 를 사용하여 Ceph Object Gateway 서버 간 부하를 분산할 수 있습니다.

HAProxy 및 keepalived 의 또 다른 사용 사례는 HAProxy 서버에서 HTTPS를 종료하는 것입니다. HAProxy 서버를 사용하여 HAProxy 서버에서 HTTPS를 종료하고 HAProxy 서버와 Beast 웹 서버 인스턴스 간에 HTTP를 사용할 수 있습니다.

4.7.1. HAProxy/keepalived 사전 요구 사항

Ceph Object Gateway를 사용하여 HA 프록시를 설정하려면 다음을 수행해야 합니다.

  • 실행 중인 Ceph 클러스터
  • 포트 80 에서 실행하도록 구성된 동일한 영역 내의 두 개 이상의 Ceph Object Gateway 서버. 간단한 설치 절차를 따르는 경우 게이트웨이 인스턴스가 기본적으로 동일한 영역 그룹 및 영역에 있습니다. 연결된 아키텍처를 사용하는 경우 인스턴스가 동일한 영역 그룹 및 영역에 있는지 확인합니다.
  • HAProxy 및 keepalived 용 Red Hat Enterprise Linux 8 서버 2대 이상.
참고

이 섹션에서는 두 개 이상의 Ceph Object Gateway 서버가 실행 중이고 포트 80 을 통해 테스트 스크립트를 실행할 때 각 서버에서 유효한 응답을 얻을 수 있다고 가정합니다.

4.7.2. HAProxy 노드 준비

다음 설정에서는 haproxy 및 haproxy 2 라는 두 개의 HAProxy 노드와 rgw1 및 rgw 2 라는 Ceph Object Gateway 서버가 있다고 가정합니다. 원하는 모든 이름 지정 규칙을 사용할 수 있습니다. 두 개 이상의 HAProxy 노드에서 다음 절차를 수행합니다.

  1. Red Hat Enterprise Linux 8 설치.
  2. 노드를 등록합니다.

    [root@haproxy]# subscription-manager register
  3. RHEL 서버 리포지토리를 활성화합니다.

    [root@haproxy]# subscription-manager repos --enable=rhel-8-server-rpms
  4. 서버를 업데이트합니다.

    [root@haproxy]# dnf update -y
  5. 필요에 따라 관리 도구(예: wget,vim 등)를 설치합니다.
  6. 포트 80 을 엽니다.

    [root@haproxy]# firewall-cmd --zone=public --add-port 80/tcp --permanent
    [root@haproxy]# firewall-cmd --reload
  7. HTTPS의 경우 포트 443 을 엽니다.

    [root@haproxy]# firewall-cmd --zone=public --add-port 443/tcp --permanent
    [root@haproxy]# firewall-cmd --reload

4.7.3. keepalived 설치 및 구성

두 개 이상의 HAProxy 노드에서 다음 절차를 수행합니다.

사전 요구 사항

  • 최소 2개의 HAProxy 노드.
  • 최소 두 개의 Object Gateway 노드.

절차

  1. keepalived 설치 :

    [root@haproxy]# yum install -y keepalived
  2. 두 HAProxy 노드 모두에서 keepalived 를 구성합니다.

    [root@haproxy]# vim /etc/keepalived/keepalived.conf

    구성 파일에는 haproxy 프로세스를 확인하는 스크립트가 있습니다.

    vrrp_script chk_haproxy {
      script "killall -0 haproxy" # check the haproxy process
      interval 2 # every 2 seconds
      weight 2 # add 2 points if OK
    }

    다음으로 기본 및 백업 로드 밸런서의 인스턴스에서 eno1 을 네트워크 인터페이스로 사용합니다. 또한 가상 IP 주소 즉, 192.168.1.20 을 할당합니다.

    기본 로드 밸런서 노드

    vrrp_instance RGW {
        state MASTER # might not be necessary. This is on the primary LB node.
        @main interface eno1
        priority 100
        advert_int 1
        interface eno1
        virtual_router_id 50
        @main unicast_src_ip 10.8.128.43 80
        unicast_peer {
               10.8.128.53
               }
        authentication {
            auth_type PASS
            auth_pass 1111
        }
        virtual_ipaddress {
            192.168.1.20
        }
        track_script {
          chk_haproxy
        }
    }
    virtual_server 192.168.1.20 80 eno1 { #populate correct interface
        delay_loop 6
        lb_algo wlc
        lb_kind dr
        persistence_timeout 600
        protocol TCP
        real_server 10.8.128.43 80 { # ip address of rgw2 on physical interface, haproxy listens here, rgw listens to localhost:8080 or similar
            weight 100
            TCP_CHECK { # perhaps change these to a HTTP/SSL GET?
                connect_timeout 3
            }
        }
        real_server 10.8.128.53 80 { # ip address of rgw3 on physical interface, haproxy listens here, rgw listens to localhost:8080 or similar
            weight 100
            TCP_CHECK { # perhaps change these to a HTTP/SSL GET?
                connect_timeout 3
            }
        }
    }

    백업 로드 밸런서 노드

    vrrp_instance RGW {
        state BACKUP # might not be necessary?
        priority 99
        advert_int 1
        interface eno1
        virtual_router_id 50
        unicast_src_ip 10.8.128.53 80
        unicast_peer {
               10.8.128.43
               }
        authentication {
            auth_type PASS
            auth_pass 1111
        }
        virtual_ipaddress {
            192.168.1.20
        }
        track_script {
          chk_haproxy
        }
    }
    virtual_server 192.168.1.20 80 eno1 { #populate correct interface
        delay_loop 6
        lb_algo wlc
        lb_kind dr
        persistence_timeout 600
        protocol TCP
        real_server 10.8.128.43 80 { # ip address of rgw2 on physical interface, haproxy listens here, rgw listens to localhost:8080 or similar
            weight 100
            TCP_CHECK { # perhaps change these to a HTTP/SSL GET?
                connect_timeout 3
            }
        }
        real_server 10.8.128.53 80 { # ip address of rgw3 on physical interface, haproxy listens here, rgw listens to localhost:8080 or similar
            weight 100
            TCP_CHECK { # perhaps change these to a HTTP/SSL GET?
                connect_timeout 3
            }
        }
    }

  3. keepalived 서비스를 활성화하고 시작합니다.

    [root@haproxy]# systemctl enable keepalived
    [root@haproxy]# systemctl start keepalived

추가 리소스

4.7.4. HAProxy 설치 및 구성

두 개 이상의 HAProxy 노드에서 다음 절차를 수행합니다.

  1. haproxy 를 설치합니다.

    [root@haproxy]# dnf install haproxy
  2. SELinux 및 HTTP에 대해 haproxy 를 구성합니다.

    [root@haproxy]# vim /etc/firewalld/services/haproxy-http.xml

    다음 행을 추가합니다.

    <?xml version="1.0" encoding="utf-8"?>
    <service>
    <short>HAProxy-HTTP</short>
    <description>HAProxy load-balancer</description>
    <port protocol="tcp" port="80"/>
    </service>

    root 로 올바른 SELinux 컨텍스트 및 파일 권한을 haproxy-http.xml 파일에 할당합니다.

    [root@haproxy]# cd /etc/firewalld/services
    [root@haproxy]# restorecon haproxy-http.xml
    [root@haproxy]# chmod 640 haproxy-http.xml
  3. HTTPS를 사용하려는 경우 SELinux 및 HTTPS에 대해 haproxy 를 구성합니다.

    [root@haproxy]# vim /etc/firewalld/services/haproxy-https.xml

    다음 행을 추가합니다.

    <?xml version="1.0" encoding="utf-8"?>
    <service>
    <short>HAProxy-HTTPS</short>
    <description>HAProxy load-balancer</description>
    <port protocol="tcp" port="443"/>
    </service>

    root 로 올바른 SELinux 컨텍스트 및 파일 권한을 haproxy-https.xml 파일에 할당합니다.

    # cd /etc/firewalld/services
    # restorecon haproxy-https.xml
    # chmod 640 haproxy-https.xml
  4. HTTPS를 사용하려는 경우 SSL에 대한 키를 생성합니다. 인증서가 없는 경우 자체 서명된 인증서를 사용할 수 있습니다. 키를 생성하려면 Red Hat Enterprise Linux 7 시스템 관리자 가이드의 새 키 및 인증서 생성을 참조하십시오.

    마지막으로 인증서와 키를 PEM 파일에 넣습니다.

    [root@haproxy]# cat example.com.crt example.com.key > example.com.pem
    [root@haproxy]# cp example.com.pem /etc/ssl/private/
  5. haproxy 구성.

    [root@haproxy]# vim /etc/haproxy/haproxy.cfg

    globaldefaults 는 변경되지 않은 상태로 유지될 수 있습니다. defaults 섹션을 마치면 frontendbackend 섹션을 구성해야 합니다. 예를 들면 다음과 같습니다.

    frontend http_web
      bind *:80
      mode http
      default_backend rgw
    
    frontend rgw­-https
      bind *:443 ssl crt /etc/ssl/private/example.com.pem
      default_backend rgw
    
    backend rgw
        balance roundrobin
        mode http
        server  rgw1 10.0.0.71:80 check
        server  rgw2 10.0.0.80:80 check

    HAProxy 구성에 대한 자세한 내용은 Red Hat 업데이트 인프라 시스템 관리자 가이드의 HAProxy 로드 밸런서 추가 장을 참조하십시오.

  6. haproxy활성화/시작

    [root@haproxy]# systemctl enable haproxy
    [root@haproxy]# systemctl start haproxy

4.7.5. HAProxy 구성 테스트

  1. HAProxy 노드에서 keepalived 구성의 가상 IP 주소가 표시되는지 확인합니다.

    [root@haproxy]# ip addr show
  2. Red Hat Ceph Dashboard 컨테이너를 호스팅하는 노드에서 로드 밸런서 구성을 사용하여 Ceph Object Gateway 노드에 연결할 수 있는지 확인합니다. 예를 들면 다음과 같습니다.

    [root@haproxy]# wget haproxy

    다음과 동일한 결과가 반환되어야 합니다.

    [root@haproxy]# wget rgw1

    다음 내용이 포함된 index.html 파일을 반환하는 경우:

    <?xml version="1.0" encoding="UTF-8"?>
    	<ListAllMyBucketsResult xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
    		<Owner>
    			<ID>anonymous</ID>
    			<DisplayName></DisplayName>
    		</Owner>
    		<Buckets>
    		</Buckets>
    	</ListAllMyBucketsResult>

    그런 다음 구성이 제대로 작동합니다.

4.8. 네임스페이스를 NFS-Ganesha로 내보내기

Ceph Object Gateway와 함께 사용할 새 NFS Ganesha 내보내기를 구성하려면 Red Hat Ceph Storage Dashboard를 사용해야 합니다. 자세한 내용은 Red Hat Ceph Storage 대시보드 가이드의 Ceph 대시보드 섹션에서 NFS Ganesha 내보내기 관리를 참조하십시오.

중요

Ceph Object Gateway를 사용하는 기존 NFS 환경의 경우 Red Hat Ceph Storage 4에서 Red Hat Ceph Storage 5로 업그레이드하는 것은 현재 지원되지 않습니다.

중요

Red Hat은 Ceph Object Gateway를 사용하여 NFS 버전 3 내보내기를 지원하지 않습니다.

5장. 고급 설정

스토리지 관리자는 Ceph Object Gateway의 고급 기능을 구성할 수 있습니다. 다중 사이트 Ceph Object Gateway를 구성하고 Microsoft Active Directory 및 OpenStack Keystone 서비스와 같은 디렉터리 서비스와 통합할 수 있습니다.

5.1. 사전 요구 사항

  • 정상적으로 실행 중인 Red Hat Ceph Storage 클러스터.

5.2. 다중 사이트 구성 및 관리

스토리지 관리자는 다양한 사용 사례에 맞게 여러 Ceph Object Gateway를 구성하고 관리할 수 있습니다. 재해 복구 및 페일오버 이벤트 중에 수행할 작업을 배울 수 있습니다. 또한 다중 사이트 Ceph Object Gateway 환경에서 영역, 영역 및 동기화 정책에 대해 자세히 알아볼 수 있습니다.

5.2.1. 사전 요구 사항

  • 정상적이고 실행 중인 Red Hat Ceph Storage 클러스터.
  • Ceph Object Gateway 소프트웨어 배포.

5.2.2. 풀

풀당 Ceph 배치 그룹당 Ceph 배치 그룹을 사용하여 radosgw 데몬이 생성할 풀에 적합한 개수의 배치 그룹을 계산하는 것이 좋습니다. Ceph 구성 데이터베이스에서 계산된 값을 기본값으로 설정합니다.

예제

[root@mon ~]# ceph config set osd osd_pool_default_pg_num = 50
[root@mon ~]# ceph config set osd osd_pool_default_pgp_num = 50

참고

Ceph Object Gateway 인스턴스가 풀을 만들 때 Ceph 구성을 변경하면 이러한 기본값이 사용됩니다. 또는 수동으로 풀을 만들 수도 있습니다.

영역과 관련된 풀 이름은 ZONE_NAME.POOL_NAME 이라는 명명 규칙을 따릅니다. 예를 들어 us-east 라는 영역에는 다음과 같은 풀이 있습니다.

  • .rgw.root
  • us-east.rgw.control
  • us-east.rgw.meta
  • us-east.rgw.log
  • us-east.rgw.buckets.index
  • us-east.rgw.buckets.data
  • us-east.rgw.buckets.non-ec
  • us-east.rgw.meta:users.keys
  • us-east.rgw.meta:users.email
  • us-east.rgw.meta:users.swift
  • us-east.rgw.meta:users.uid

추가 리소스

  • 풀 생성에 대한 자세한 내용은 Red Hat Ceph Storage Storage Strategies GuidePools 장을 참조하십시오.

5.2.3. 단일 사이트 시스템을 다중 사이트 시스템으로 마이그레이션

기본 영역 그룹 및 영역이 있는 단일 사이트 시스템에서 다중 사이트 시스템으로 마이그레이션하려면 다음 단계를 사용하십시오.

  1. 영역을 생성합니다. <name> 을 영역 이름으로 바꿉니다.

    [root@primary-zone]# radosgw-admin realm create --rgw-realm=<name> --default
  2. 기본 영역 및 영역 그룹의 이름을 변경합니다. <name> 을 zonegroup 또는 zone 이름으로 바꿉니다.

    [root@primary-zone]# radosgw-admin zonegroup rename --rgw-zonegroup default --zonegroup-new-name=<name>
    [root@primary-zone]# radosgw-admin zone rename --rgw-zone default --zone-new-name us-east-1 --rgw-zonegroup=<name>
  3. 기본 영역 그룹을 구성합니다. <name> 을 영역 또는 영역 그룹 이름으로 바꿉니다. <fqdn> 을 영역 그룹에서 정규화된 도메인 이름으로 바꿉니다.

    [root@primary-zone]# radosgw-admin zonegroup modify --rgw-realm=<name> --rgw-zonegroup=<name> --endpoints http://<fqdn>:80 --master --default
  4. 기본 영역을 구성합니다. <name> 을 영역, zonegroup 또는 영역 이름으로 바꿉니다. <fqdn> 을 영역 그룹에서 정규화된 도메인 이름으로 바꿉니다.

    [root@primary-zone]# radosgw-admin zone modify --rgw-realm=<name> --rgw-zonegroup=<name> \
                                --rgw-zone=<name> --endpoints http://<fqdn>:80 \
                                --access-key=<access-key> --secret=<secret-key> \
                                --master --default
  5. 시스템 사용자를 만듭니다. <user-id> 를 사용자 이름으로 바꿉니다. <display-name> 을 표시 이름으로 바꿉니다. 여기에는 공백이 포함될 수 있습니다.

    [root@primary-zone]# radosgw-admin user create --uid=<user-id> \
                                --display-name="<display-name>" \
                                --access-key=<access-key> --secret=<secret-key> \ --system
  6. 업데이트된 구성을 커밋합니다.

    # radosgw-admin period update --commit
  7. Ceph 개체 게이트웨이를 다시 시작합니다.

    참고

    NAME 열 아래의 ceph orch ps 명령의 출력을 사용하여 SERVICE_TYPE.ID 정보를 가져옵니다.

    1. 스토리지 클러스터의 개별 노드에서 Ceph Object Gateway를 다시 시작하려면 다음을 수행합니다.

      구문

      systemctl restart ceph-CLUSTER_ID@SERVICE_TYPE.ID.service

      예제

      [root@primary-zone]# systemctl restart ceph-c4b34c6f-8365-11ba-dc31-529020a7702d@rgw.realm.zone.node1.gwasto.service

    2. 스토리지 클러스터의 모든 노드에서 Ceph Object Gateway를 다시 시작하려면 다음을 수행합니다.

      구문

      ceph orch restart SERVICE_TYPE

      예제

      [root@primary-zone]# ceph orch restart rgw

5.2.4. 아카이브 동기화 모듈 구성(기술 프리뷰)

아카이브 동기화 모듈은 Ceph 개체 게이트웨이에서 S3 오브젝트의 버전 관리 기능을 활용하여 아카이브 영역을 보유합니다. 아카이브 영역에는 아카이브 영역과 연결된 게이트웨이를 통해서만 제거할 수 있는 S3 오브젝트 버전의 기록이 있습니다. 모든 데이터 업데이트와 메타데이터를 캡처하여 S3 오브젝트의 버전으로 통합합니다.

중요

아카이브 동기화 모듈은 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원하지 않으며, 기능상 완전하지 않을 수 있어 프로덕션에 사용하지 않는 것이 좋습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다. 자세한 내용은 Red Hat 기술 프리뷰 기능에 대한 지원 범위를 참조하십시오.

사전 요구 사항

  • 실행 중인 Red Hat Ceph Storage 클러스터.
  • Ceph 모니터 노드에 대한 루트 수준 액세스.
  • Ceph Object Gateway 소프트웨어 설치.

절차

  1. 아카이브 계층을 사용하여 새 영역을 생성할 때 아카이브 동기화 모듈을 구성합니다.

    구문

    radosgw-admin zone create --rgw-zonegroup={ZONE_GROUP_NAME} --rgw-zone={ZONE_NAME} --endpoints={http://FQDN: PORT}[,{http://FQDN: PORT}] --tier-type=archive

    예제

    [root@primary-zone]# radosgw-admin zone create --rgw-zonegroup=us --rgw-zone=us-east --endpoints={http://example.com:8080} --tier-type=archive

5.2.5. 페일오버 및 재해 복구

기본 영역에 오류가 발생하면 재해 복구를 위해 보조 영역으로 장애 조치(failover)합니다.

  1. 보조 영역을 기본 및 기본 영역으로 설정합니다. 예를 들면 다음과 같습니다.

    # radosgw-admin zone modify --rgw-zone={zone-name} --master --default

    기본적으로 Ceph Object Gateway는 액티브-액티브 구성으로 실행됩니다. 클러스터가 액티브-패시브 구성에서 실행되도록 구성된 경우 보조 영역은 읽기 전용 영역입니다. 영역이 쓰기 작업을 수신할 수 있도록 --read-only 상태를 제거합니다. 예를 들면 다음과 같습니다.

    # radosgw-admin zone modify --rgw-zone={zone-name} --master --default
  2. 기간을 업데이트하여 변경 사항을 적용합니다.

    # radosgw-admin period update --commit
  3. Ceph 개체 게이트웨이를 다시 시작합니다.

    참고

    NAME 열 아래의 ceph orch ps 명령의 출력을 사용하여 SERVICE_TYPE.ID 정보를 가져옵니다.

    1. 스토리지 클러스터의 개별 노드에서 Ceph Object Gateway를 다시 시작하려면 다음을 수행합니다.

      구문

      systemctl restart ceph-CLUSTER_ID@SERVICE_TYPE.ID.service

      예제

      [root@primary-zone]# systemctl restart ceph-c4b34c6f-8365-11ba-dc31-529020a7702d@rgw.realm.zone.node1.gwasto.service

    2. 스토리지 클러스터의 모든 노드에서 Ceph Object Gateway를 다시 시작하려면 다음을 수행합니다.

      구문

      ceph orch restart SERVICE_TYPE

      예제

      [root@primary-zone]# ceph orch restart rgw

이전 기본 영역이 복구되면 작업을 되돌립니다.

  1. 복구된 영역에서 현재 기본 영역에서 영역을 가져옵니다.

    # radosgw-admin realm pull --url={url-to-primary-zone-gateway} \
                                --access-key={access-key} --secret={secret}
  2. 복구된 영역을 기본 및 기본 영역으로 설정합니다.

    # radosgw-admin zone modify --rgw-zone={zone-name} --master --default
  3. 기간을 업데이트하여 변경 사항을 적용합니다.

    # radosgw-admin period update --commit
  4. 복구된 영역에서 Ceph Object Gateway를 다시 시작합니다.

    # systemctl restart ceph-radosgw@rgw.`hostname -s`.rgw0
  5. 보조 영역이 읽기 전용 구성이어야 하는 경우 보조 영역을 업데이트합니다.

    # radosgw-admin zone modify --rgw-zone={zone-name} --read-only
  6. 기간을 업데이트하여 변경 사항을 적용합니다.

    # radosgw-admin period update --commit
  7. 보조 영역에서 Ceph 개체 게이트웨이를 다시 시작합니다.

    # systemctl restart ceph-radosgw@rgw.`hostname -s`.rgw0

5.2.6. 멀티사이트를 사용하여 수동으로 버킷 복구

Red Hat Ceph Storage 는 다중 사이트 클러스터에 대한 동적 버킷 재하드를 지원하지 않습니다. 다중 사이트 클러스터에서 버킷을 수동으로 재하드하려면 다음 절차를 사용하십시오.

주의

수동 재하드(resharding)는 매우 비용이 많이 드는 프로세스이며, 특히 수동 복구를 보증하는 대규모 버킷의 경우 프로세스입니다. 모든 보조 영역은 모든 오브젝트를 삭제한 다음 기본 영역에서 다시 동기화합니다.

사전 요구 사항

  • 모든 Ceph Object Gateway 인스턴스를 중지합니다.

절차

  1. master 영역 그룹의 마스터 영역 내의 노드에서 다음 명령을 실행합니다.

    구문

    # radosgw-admin bucket sync disable --bucket=BUCKET_NAME

    모든 영역에서 데이터 동기화가 최신 상태 임을 보고할 때까지 기다립니다.

  2. 모든 영역에서 모든 ceph-radosgw 데몬 중지합니다.
  3. 마스터 영역 그룹의 마스터 영역 내의 노드에서 버킷을 재배치합니다.

    구문

    # radosgw-admin bucket reshard --bucket=BUCKET_NAME --num-shards=NEW_SHARDS_NUMBER

  4. 보조 영역에서 다음을 실행합니다.

    구문

    # radosgw-admin bucket rm --purge-objects --bucket=BUCKET_NAME

  5. 모든 영역에서 모든 ceph-radosgw 데몬을 다시 시작합니다.
  6. master 영역 그룹의 마스터 영역 내의 노드에서 다음 명령을 실행합니다.

    구문

    # radosgw-admin bucket sync enable --bucket=BUCKET_NAME

    메타데이터 동기화 프로세스는 업데이트된 버킷 진입점 및 버킷 인스턴스 메타데이터를 가져옵니다. 데이터 동기화 프로세스는 전체 동기화를 수행합니다.

추가 리소스

5.2.7. 복제없이 다중 영역 구성

서로 복제할 수 없는 여러 영역을 구성할 수 있습니다. 예를 들어 회사에서 각 팀의 전용 영역을 만들 수 있습니다.

사전 요구 사항

  • Ceph Object Gateway 소프트웨어 설치.
  • Ceph Object Gateway 노드에 대한 루트 수준 액세스.

절차

  1. 새 영역을 생성합니다.

    구문

    radosgw-admin realm create --rgw-realm=REALM_NAME [--default]

    예제

    [root@rgw-primary]# radosgw-admin realm create --rgw-realm=movies --default
    {
        "id": "0956b174-fe14-4f97-8b50-bb7ec5e1cf62",
        "name": "movies",
        "current_period": "1950b710-3e63-4c41-a19e-46a715000980",
        "epoch": 1
    }

  2. 새 영역 그룹을 생성합니다.

    구문

    radosgw-admin zonegroup create --rgw-zonegroup=ZONE_GROUP_NAME --endpoints=FQDN : PORT [--rgw-realm=REALM_NAME|--realm-id=REALM_ID] --master --default

    예제

    [root@rgw-primary]# radosgw-admin zonegroup create --rgw-zonegroup=us --endpoints=http://rgw1:80 --rgw-realm=movies --master --default
    {
        "id": "f1a233f5-c354-4107-b36c-df66126475a6",
        "name": "us",
        "api_name": "us",
        "is_master": "true",
        "endpoints": [
            "http:\/\/rgw1:80"
        ],
        "hostnames": [],
        "hostnames_s3webzone": [],
        "master_zone": "",
        "zones": [],
        "placement_targets": [],
        "default_placement": "",
        "realm_id": "0956b174-fe14-4f97-8b50-bb7ec5e1cf62"
    }

  3. 사용 사례에 따라 하나 이상의 영역을 생성합니다.

    구문

    radosgw-admin zone create --rgw-zonegroup=ZONE_GROUP_NAME --rgw-zone=ZONE_NAME --master --default --endpoints=FQDN : PORT[,FQDN : PORT_]

    예제

    [root@rgw-primary]# radosgw-admin zone create --rgw-zonegroup=us --rgw-zone=us-east --master --default --endpoints=http://rgw1:80

  4. 영역 그룹의 구성으로 JSON 파일을 가져옵니다.

    구문

    radosgw-admin zonegroup get --rgw-zonegroup=ZONE_GROUP_NAME > JSON_FILE_NAME

    예제

    [root@rgw-primary]# radosgw-admin zonegroup get --rgw-zonegroup=us > zonegroup-us.json

    1. 편집할 파일을 열고 log_meta,log_ data 및 sync_ from_all 필드를 false로 설정합니다.

      예제

          {
              "id": "72f3a886-4c70-420b-bc39-7687f072997d",
              "name": "default",
              "api_name": "",
              "is_master": "true",
              "endpoints": [],
              "hostnames": [],
              "hostnames_s3website": [],
              "master_zone": "a5e44ecd-7aae-4e39-b743-3a709acb60c5",
              "zones": [
                  {
                      "id": "975558e0-44d8-4866-a435-96d3e71041db",
                      "name": "testzone",
                      "endpoints": [],
                      "log_meta": "false",
                      "log_data": "false",
                      "bucket_index_max_shards": 0,
                      "read_only": "false",
                      "tier_type": "",
                      "sync_from_all": "false",
                      "sync_from": []
                  },
                  {
                      "id": "a5e44ecd-7aae-4e39-b743-3a709acb60c5",
                      "name": "default",
                      "endpoints": [],
                      "log_meta": "false",
                      "log_data": "false",
                      "bucket_index_max_shards": 0,
                      "read_only": "false",
                      "tier_type": "",
                      "sync_from_all": "false",
                      "sync_from": []
                  }
              ],
              "placement_targets": [
                  {
                      "name": "default-placement",
                      "tags": []
                  }
              ],
              "default_placement": "default-placement",
              "realm_id": "2d988e7d-917e-46e7-bb18-79350f6a5155"
          }

  5. 업데이트된 JSON 파일을 사용하여 영역 그룹을 설정합니다.

    구문

    radosgw-admin zonegroup set --rgw-zonegroup=ZONE_GROUP_NAME --infile=JSON_FILE_NAME

    예제

    [root@rgw-primary]# radosgw-admin zonegroup set --rgw-zonegroup=us --infile=zonegroup-us.json

  6. 기간을 업데이트합니다.

    예제

    [root@rgw-primary]# radosgw-admin period update --commit

5.2.8. 동일한 스토리지 클러스터에서 여러 영역 구성

이 섹션에서는 동일한 스토리지 클러스터에서 여러 영역을 구성하는 방법에 대해 설명합니다. 이것은 멀티사이트의 고급 사용 사례입니다. 동일한 스토리지 클러스터에서 여러 영역을 구성하면 로컬 영역을 사용하여 로컬 RGW 클라이언트 트래픽을 처리할 수 있으며 보조 사이트에 복제될 데이터의 복제 영역을 처리할 수 있습니다.

참고

Red Hat은 각 영역에 고유한 Ceph Object Gateway를 보유하는 것이 좋습니다.

사전 요구 사항

절차

  1. 동기화 사용자를 생성합니다.

    구문

    radosgw-admin user create --uid="SYNCHRONIZATION_USER" --display-name="Synchronization User" --system

  2. 스토리지 클러스터의 첫 번째 데이터 센터에 하나의 로컬 영역을 생성합니다.

    구문

    radosgw-admin realm create --rgw-realm=REALM_NAME --default

    예제

    [user@rgw1]$ radosgw-admin realm create --rgw-realm=ldc1 --default

  3. 첫 번째 데이터 센터에 하나의 로컬 마스터 영역 그룹을 생성합니다.

    구문

    radosgw-admin zonegroup create --rgw-zonegroup=ZONE_GROUP_NAME --endpoints=http://RGW_NODE_NAME:80 --rgw-realm=REALM_NAME --master --default

    예제

    [user@rgw1]$ radosgw-admin zonegroup create --rgw-zonegroup=ldc1zg --endpoints=http://rgw1:80 --rgw-realm=ldc1 --master --default

  4. 첫 번째 데이터 센터에 하나의 로컬 영역을 생성합니다.

    구문

    radosgw-admin zone create --rgw-zonegroup=ZONE_GROUP_NAME --rgw-zone=ZONE_NAME --master --default --endpoints=HTTP_FQDN[,HTTP_FQDN]

    예제

    [user@rgw1]$ radosgw-admin zone create --rgw-zonegroup=ldc1zg --rgw-zone=ldc1z --master --default --endpoints=http://rgw.example.com

  5. 기간을 커밋합니다.

    예제

    [user@rgw1]$ radosgw-admin period update --commit

  6. rgw_realm, rgw_ zonegroup 및 rgw_zone 이름으로 ceph.conf 를 업데이트합니다.

    구문

    rgw_realm = REALM_NAME
    rgw_zonegroup = ZONE_GROUP_NAME
    rgw_zone = ZONE_NAME

    예제

    rgw_realm = ldc1
    rgw_zonegroup = ldc1zg
    rgw_zone = ldc1z

  7. Ceph 개체 게이트웨이를 다시 시작합니다.

    참고

    NAME 열 아래의 ceph orch ps 명령의 출력을 사용하여 SERVICE_TYPE.ID 정보를 가져옵니다.

    1. 스토리지 클러스터의 개별 노드에서 Ceph Object Gateway를 다시 시작하려면 다음을 수행합니다.

      구문

      systemctl restart ceph-CLUSTER_ID@SERVICE_TYPE.ID.service

      예제

      [root@rgw1]# systemctl restart ceph-c4b34c6f-8365-11ba-dc31-529020a7702d@rgw.realm.zone.node1.gwasto.service

    2. 스토리지 클러스터의 모든 노드에서 Ceph Object Gateway를 다시 시작하려면 다음을 수행합니다.

      구문

      ceph orch restart SERVICE_TYPE

      예제

      [root@rgw1]# ceph orch restart rgw

  8. 스토리지 클러스터의 두 번째 데이터 센터에 하나의 로컬 영역을 생성합니다.

    구문

    radosgw-admin realm create --rgw-realm=REALM_NAME --default

    예제

    [user@rgw2]$ radosgw-admin realm create --rgw-realm=ldc2 --default

  9. 두 번째 데이터 센터에 하나의 로컬 마스터 영역 그룹을 생성합니다.

    구문

    radosgw-admin zonegroup create --rgw-zonegroup=ZONE_GROUP_NAME --endpoints=http://RGW_NODE_NAME:80 --rgw-realm=REALM_NAME --master --default

    예제

    [user@rgw2]$ radosgw-admin zonegroup create --rgw-zonegroup=ldc2zg --endpoints=http://rgw2:80 --rgw-realm=ldc2 --master --default

  10. 두 번째 데이터 센터에 하나의 로컬 영역을 생성합니다.

    구문

    radosgw-admin zone create --rgw-zonegroup=ZONE_GROUP_NAME --rgw-zone=ZONE_NAME --master --default --endpoints=HTTP_FQDN[, HTTP_FQDN]

    예제

    [user@rgw2]$ radosgw-admin zone create --rgw-zonegroup=ldc2zg --rgw-zone=ldc2z --master --default --endpoints=http://rgw.example.com

  11. 기간을 커밋합니다.

    예제

    [user@rgw2]$ radosgw-admin period update --commit

  12. rgw_realm, rgw_ zonegroup 및 rgw_zone 이름으로 ceph.conf 를 업데이트합니다.

    구문

    rgw_realm = REALM_NAME
    rgw_zonegroup = ZONE_GROUP_NAME
    rgw_zone = ZONE_NAME

    예제

    rgw_realm = ldc2
    rgw_zonegroup = ldc2zg
    rgw_zone = ldc2z

  13. Ceph 개체 게이트웨이를 다시 시작합니다.

    참고

    NAME 열 아래의 ceph orch ps 명령의 출력을 사용하여 SERVICE_TYPE.ID 정보를 가져옵니다.

    1. 스토리지 클러스터의 개별 노드에서 Ceph Object Gateway를 다시 시작하려면 다음을 수행합니다.

      구문

      systemctl restart ceph-CLUSTER_ID@SERVICE_TYPE.ID.service

      예제

      [root@rgw2]# systemctl restart ceph-c4b34c6f-8365-11ba-dc31-529020a7702d@rgw.realm.zone.node1.gwasto.service

    2. 스토리지 클러스터의 모든 노드에서 Ceph Object Gateway를 다시 시작하려면 다음을 수행합니다.

      구문

      ceph orch restart SERVICE_TYPE

      예제

      [root@rgw2]# ceph orch restart rgw

  14. 복제/동기화 사용자를 생성합니다.

    구문

    radosgw-admin user create --uid="REPLICATION_SYNCHRONIZATION_USER" --display-name="Replication-Synchronization User" --system

  15. 스토리지 클러스터의 첫 번째 데이터 센터에 복제된 영역을 생성합니다.

    구문

    radosgw-admin realm create --rgw-realm=REPLICATED_REALM_1

    예제

    [user@rgw1] radosgw-admin realm create --rgw-realm=rdc1

  16. 첫 번째 데이터 센터에 대한 마스터 영역 그룹을 생성합니다.

    구문

    radosgw-admin zonegroup create --rgw-zonegroup=RGW_ZONE_GROUP --endpoints=http://_RGW_NODE_NAME:80 --rgw-realm=_RGW_REALM_NAME --master --default

    예제

    [user@rgw1] radosgw-admin zonegroup create --rgw-zonegroup=rdc1zg --endpoints=http://rgw1:80 --rgw-realm=rdc1 --master --default

  17. 첫 번째 데이터 센터에 마스터 영역을 생성합니다.

    구문

    radosgw-admin zone create --rgw-zonegroup=RGW_ZONE_GROUP --rgw-zone=_MASTER_RGW_NODE_NAME --master --default --endpoints=HTTP_FQDN[,HTTP_FQDN]

    예제

    [user@rgw1]$ radosgw-admin zone create --rgw-zonegroup=rdc1zg --rgw-zone=rdc1z --master --default --endpoints=http://rgw.example.com

  18. 기간을 커밋합니다.

    예제

    [user@rgw1]$ radosgw-admin period update --commit

  19. 첫 번째 데이터 센터에 대해 rgw_realm,rgw_zonegrouprgw_zone 이름으로 ceph.conf 를 업데이트합니다.

    구문

    rgw_realm = REALM_NAME
    rgw_zonegroup = ZONE_GROUP_NAME
    rgw_zone = ZONE_NAME

    예제

    rgw_realm = rdc1
    rgw_zonegroup = rdc1zg
    rgw_zone = rdc1z

  20. Ceph 개체 게이트웨이를 다시 시작합니다.

    참고

    NAME 열 아래의 ceph orch ps 명령의 출력을 사용하여 SERVICE_TYPE.ID 정보를 가져옵니다.

    1. 스토리지 클러스터의 개별 노드에서 Ceph Object Gateway를 다시 시작하려면 다음을 수행합니다.

      구문

      systemctl restart ceph-CLUSTER_ID@SERVICE_TYPE.ID.service

      예제

      [root@rgw1]# systemctl restart ceph-c4b34c6f-8365-11ba-dc31-529020a7702d@rgw.realm.zone.node1.gwasto.service

    2. 스토리지 클러스터의 모든 노드에서 Ceph Object Gateway를 다시 시작하려면 다음을 수행합니다.

      구문

      ceph orch restart SERVICE_TYPE

      예제

      [root@rgw1]# ceph orch restart rgw

  21. 두 번째 데이터 센터에서 복제 영역을 가져옵니다.

    구문

    radosgw-admin realm pull --url=https://tower-osd1.cephtips.com --access-key=ACCESS_KEY --secret-key=SECRET_KEY

    예제

    [user@rgw1]$ radosgw-admin realm pull --url=https://tower-osd1.cephtips.com --access-key=3QV0D6ZMMCJZMSCXJ2QJ --secret-key=VpvQWcsfI9OPzUCpR4kynDLAbqa1OIKqRB6WEnH8

  22. 첫 번째 데이터 센터에서 기간을 가져옵니다.

    구문

    radosgw-admin period pull --url=https://tower-osd1.cephtips.com --access-key=ACCESS_KEY --secret-key=SECRET_KEY

    예제

    [user@rgw1]$radosgw-admin period pull --url=https://tower-osd1.cephtips.com --access-key=3QV0D6ZMMCJZMSCXJ2QJ --secret-key=VpvQWcsfI9OPzUCpR4kynDLAbqa1OIKqRB6WEnH8

  23. 두 번째 데이터 센터에 보조 영역을 생성합니다.

    구문

    radosgw-admin zone create --rgw-zone=RGW_ZONE --rgw-zonegroup=RGW_ZONE_GROUP --endpoints=https://tower-osd4.cephtips.com --access-key=_ACCESS_KEY --secret-key=SECRET_KEY

    예제

    [user@rgw2]$ radosgw-admin zone create --rgw-zone=rdc2z --rgw-zonegroup=rdc1zg --endpoints=https://tower-osd4.cephtips.com --access-key=3QV0D6ZMMCJZMSCXJ2QJ --secret-key=VpvQWcsfI9OPzUCpR4kynDLAbqa1OIKqRB6WEnH8

  24. 기간을 커밋합니다.

    예제

    [user@rgw2]$ radosgw-admin period update --commit

  25. 두 번째 데이터 센터의 rgw_realm,rgw_zonegrouprgw_zone 이름으로 ceph.conf 를 업데이트합니다.

    구문

    rgw_realm = REALM_NAME
    rgw_zonegroup = ZONE_GROUP_NAME
    rgw_zone = ZONE_NAME

    예제

    rgw realm = rdc1
    rgw zonegroup = rdc1zg
    rgw zone = rdc2z

  26. Ceph 개체 게이트웨이를 다시 시작합니다.

    참고

    NAME 열 아래의 ceph orch ps 명령의 출력을 사용하여 SERVICE_TYPE.ID 정보를 가져옵니다.

    1. 스토리지 클러스터의 개별 노드에서 Ceph Object Gateway를 다시 시작하려면 다음을 수행합니다.

      구문

      systemctl restart ceph-CLUSTER_ID@SERVICE_TYPE.ID.service

      예제

      [root@rgw2]# systemctl restart ceph-c4b34c6f-8365-11ba-dc31-529020a7702d@rgw.realm.zone.node1.gwasto.service

    2. 스토리지 클러스터의 모든 노드에서 Ceph Object Gateway를 다시 시작하려면 다음을 수행합니다.

      구문

      ceph orch restart SERVICE_TYPE

      예제

      [root@rgw2]# ceph orch restart rgw

  27. 두 번째 데이터 센터의 엔드포인트에 root 로 로그인합니다.
  28. 마스터 영역에서 동기화 상태를 확인합니다.

    구문

    radosgw-admin sync status

    예제

    [root@rgw2]# radosgw-admin sync status
              realm 59762f08-470c-46de-b2b1-d92c50986e67 (ldc2)
          zonegroup 7cf8daf8-d279-4d5c-b73e-c7fd2af65197 (ldc2zg)
               zone 034ae8d3-ae0c-4e35-8760-134782cb4196 (ldc2z)
      metadata sync no sync (zone is master)

  29. 첫 번째 데이터 센터의 엔드포인트에 root 로 로그인합니다.
  30. replication-synchronization 영역의 동기화 상태를 확인합니다.

    구문

    radosgw-admin sync status --rgw-realm RGW_REALM_NAME

    예제

    [root@rgw1]# radosgw-admin sync status --rgw-realm rdc1
              realm 73c7b801-3736-4a89-aaf8-e23c96e6e29d (rdc1)
          zonegroup d67cc9c9-690a-4076-89b8-e8127d868398 (rdc1zg)
               zone 67584789-375b-4d61-8f12-d1cf71998b38 (rdc2z)
      metadata sync syncing
                    full sync: 0/64 shards
                    incremental sync: 64/64 shards
                    metadata is caught up with master
          data sync source: 705ff9b0-68d5-4475-9017-452107cec9a0 (rdc1z)
                            syncing
                            full sync: 0/128 shards
                            incremental sync: 128/128 shards
                            data is caught up with source
              realm 73c7b801-3736-4a89-aaf8-e23c96e6e29d (rdc1)
          zonegroup d67cc9c9-690a-4076-89b8-e8127d868398 (rdc1zg)
               zone 67584789-375b-4d61-8f12-d1cf71998b38 (rdc2z)
      metadata sync syncing
                    full sync: 0/64 shards
                    incremental sync: 64/64 shards
                    metadata is caught up with master
          data sync source: 705ff9b0-68d5-4475-9017-452107cec9a0 (rdc1z)
                            syncing
                            full sync: 0/128 shards
                            incremental sync: 128/128 shards
                            data is caught up with source

  31. 로컬 사이트에 데이터를 저장하고 액세스하려면 로컬 영역의 사용자를 생성합니다.

    구문

    radosgw-admin user create --uid="LOCAL_USER" --display-name="Local user" --rgw-realm=_REALM_NAME --rgw-zonegroup=ZONE_GROUP_NAME --rgw-zone=ZONE_NAME

    예제

    [user@rgw2] #radosgw-admin user create --uid="local-user" --display-name="Local user" --rgw-realm=ldc1 --rgw-zonegroup=ldc1zg --rgw-zone=ldc1z

    중요

    기본적으로 사용자는 다중 사이트 구성에 추가됩니다. 사용자가 로컬 영역의 데이터에 액세스하려면 radosgw-admin 명령에 --rgw-realm arugument가 필요합니다.

5.2.9. 다중 사이트 동기화 정책 사용(기술 프리뷰)

중요

Ceph Object Gateway 다중 사이트 동기화 정책은 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원하지 않으며, 기능상 완전하지 않을 수 있어 프로덕션에 사용하지 않는 것이 좋습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다. 자세한 내용은 Red Hat 기술 프리뷰 기능에 대한 지원 범위를 참조하십시오.

스토리지 관리자는 버킷 수준에서 다중 사이트 동기화 정책을 사용하여 여러 영역의 버킷 간 데이터 이동을 제어할 수 있습니다. 이러한 정책을 버킷 세분화 동기화 정책이라고 합니다. 이전에는 영역 내의 모든 버킷이 대칭 방식으로 처리되었습니다. 즉, 각 영역에 지정된 버킷의 미러 사본이 포함되어 있으며 버킷 사본이 모든 영역에서 동일합니다. 동기화 프로세스에서는 버킷 동기화 소스와 버킷 동기화 대상이 동일한 버킷을 참조했다고 가정했습니다.

버킷granularity 동기화 정책을 사용하면 다양한 영역의 버킷에 다른 데이터를 포함할 수 있습니다. 이를 통해 버킷은 다른 영역의 다른 버킷에서 데이터를 가져올 수 있으며 해당 버킷에는 데이터를 가져오는 버킷과 동일한 이름 또는 ID가 없습니다. 이 경우 버킷 동기화 소스와 버킷 동기화 대상은 다른 버킷을 참조합니다.

동기화 정책은 이전 영역 그룹 coarse 구성(sync_from*)을 대체합니다. 동기화 정책은 영역 그룹 수준에서 구성할 수 있습니다. 구성된 경우 영역 그룹 수준에서 이전 스타일 구성을 대체하지만 버킷 수준에서 구성할 수도 있습니다.

5.2.9.1. 사전 요구 사항

  • 실행 중인 Red Hat Ceph Storage 클러스터.
  • Ceph 모니터 노드에 대한 루트 수준 액세스.
  • Ceph Object Gateway 소프트웨어 설치.

5.2.9.2. 다중 사이트 동기화 정책 데이터 흐름

동기화 정책에서는 데이터 흐름 구성 목록이 포함될 수 있는 여러 그룹과 파이프 구성 목록을 정의할 수 있습니다. data-flow는 다양한 영역 간 데이터 흐름을 정의합니다. 여러 영역이 서로 데이터를 동기화하는 대칭 데이터 흐름을 정의할 수 있으며, 데이터가 한 영역에서 다른 영역으로 이동하는 방향 데이터 흐름을 정의할 수 있습니다.

파이프는 이러한 데이터 흐름을 사용할 수 있는 실제 버킷과 연결된 속성(예: 소스 오브젝트 접두사)을 정의합니다.

동기화 정책 그룹은 다음 세 가지 상태일 수 있습니다.

  • 활성화되어 있는 apache-cdsync가 허용 및 활성화되어 있습니다.
  • 허용된 POST-cdsync가 허용됩니다.
  • 이 그룹에서 정의한 대로 허용되지 않습니다. 이 그룹의 동기화 상태는 다른 그룹을 재정의할 수 있습니다.

정책은 버킷 수준에서 정의할 수 있습니다. 버킷 수준 동기화 정책은 zonegroup 정책의 데이터 흐름을 상속하며 영역 그룹이 허용하는 항목의 하위 집합만 정의할 수 있습니다.

와일드카드 영역 및 정책의 와일드카드 버킷 매개 변수는 모든 관련 영역 또는 모든 관련 버킷을 정의합니다. 버킷 정책의 컨텍스트에서 이는 현재 버킷 인스턴스를 의미합니다. 전체 영역이 미러링된 재해 복구 구성은 버킷에서 아무것도 구성할 필요가 없습니다. 그러나 미세 조정된 버킷 동기화의 경우 (status=allowed) 영역 그룹 수준(예: 와일드카드 사용)에서 파이프를 동기화하도록 구성하는 것이 더 좋습니다. 버킷 수준(status=enabled)에서만 특정 동기화를 활성화할 수 있습니다. 필요한 경우 버킷 수준의 정책은 데이터 이동을 특정 관련 영역으로 제한할 수 있습니다.

중요

영역 그룹 정책에 대한 변경 사항을 영역 그룹 마스터 영역에 적용해야 하며, 기간 업데이트 및 커밋이 필요합니다. 버킷 정책에 대한 변경 사항을 영역 그룹 마스터 영역에 적용해야 합니다. 변경 사항은 rgw에 의해 동적으로 처리됩니다.

S3 복제 API

S3 버킷 복제 API도 구현되어 사용자가 여러 버킷 간에 복제 규칙을 생성할 수 있습니다. AWS 복제 기능을 사용하면 동일한 영역 내의 버킷 복제가 가능하지만 rgw에서는 현재 이를 허용하지 않습니다. 그러나 사용자가 특정 버킷을 동기화할 영역을 선택할 수 있는 rgw api도 새로운 'Zone' 어레이를 추가했습니다.

5.2.9.3. 현재 정책 검색

스토리지 관리자는 get 명령을 사용하여 현재 영역 그룹 동기화 정책 또는 특정 버킷 정책을 검색할 수 있습니다.

사전 요구 사항

  • 실행 중인 Red Hat Ceph Storage 클러스터.
  • root 또는 sudo 액세스.
  • Ceph Object Gateway가 설치되어 있습니다.

절차

  1. 현재 영역 그룹 동기화 정책 또는 버킷 정책을 검색합니다. 특정 버킷 정책을 검색하려면 --bucket 옵션을 사용합니다.

    구문

    radosgw-admin sync policy get --bucket=BUCKET-NAME

    예제

    [root@master-zone]# radosgw-admin sync policy get --bucket=mybucket

5.2.9.4. 동기화 정책 그룹 생성

스토리지 관리자는 현재 영역 그룹 또는 특정 버킷에 대한 동기화 정책 그룹을 생성할 수 있습니다.

사전 요구 사항

  • 실행 중인 Red Hat Ceph Storage 클러스터.
  • root 또는 sudo 액세스.
  • Ceph Object Gateway가 설치되어 있습니다.

절차

  1. 동기화 정책 그룹 또는 버킷 정책을 생성합니다. 버킷 정책을 생성하려면 --bucket 옵션을 사용합니다.

    구문

    radosgw-admin sync group create --bucket=BUCKET-NAME --group-id=GROUP-ID --status=enabled | allowed | forbidden

    예제

    [root@master-zone]# radosgw-admin sync group create --group-id=mygroup1 --status=enabled

5.2.9.5. 동기화 정책 그룹 수정

스토리지 관리자는 현재 영역 그룹 또는 특정 버킷의 기존 동기화 정책 그룹을 수정할 수 있습니다.

사전 요구 사항

  • 실행 중인 Red Hat Ceph Storage 클러스터.
  • root 또는 sudo 액세스.
  • Ceph Object Gateway가 설치되어 있습니다.

절차

  1. 동기화 정책 그룹 또는 버킷 정책을 수정합니다. 버킷 정책을 수정하려면 --bucket 옵션을 사용합니다.

    구문

    radosgw-admin sync group modify --bucket=BUCKET-NAME --group-id=GROUP-ID --status=enabled | allowed | forbidden

    예제

    [root@master-zone]# radosgw-admin sync group modify --group-id=mygroup1 --status=forbidden

5.2.9.6. 동기화 정책 그룹 표시

스토리지 관리자는 group get 명령을 사용하여 현재 동기화 정책 그룹을 그룹 ID별로 표시하거나 특정 버킷 정책을 표시할 수 있습니다.

사전 요구 사항

  • 실행 중인 Red Hat Ceph Storage 클러스터.
  • root 또는 sudo 액세스.
  • Ceph Object Gateway가 설치되어 있습니다.

절차

  1. 현재 동기화 정책 그룹 또는 버킷 정책을 표시합니다. 특정 버킷 정책을 표시하려면 --bucket 옵션을 사용합니다.

    구문

    radosgw-admin sync group get --bucket=BUCKET-NAME --group-id=GROUP-ID

    예제

    [root@master-zone]# radosgw-admin sync group get --group-id=mygroup

5.2.9.7. 동기화 정책 그룹 제거

스토리지 관리자는 group remove 명령을 사용하여 그룹 ID별로 현재 동기화 정책 그룹을 제거하거나 특정 버킷 정책을 제거할 수 있습니다.

사전 요구 사항

  • 실행 중인 Red Hat Ceph Storage 클러스터.
  • root 또는 sudo 액세스.
  • Ceph Object Gateway가 설치되어 있습니다.

절차

  1. 현재 동기화 정책 그룹 또는 버킷 정책을 제거합니다. 특정 버킷 정책을 제거하려면 --bucket 옵션을 사용합니다.

    구문

    radosgw-admin sync group remove --bucket=BUCKET-NAME --group-id=GROUP-ID

    예제

    [root@master-zone]# radosgw-admin sync group remove --group-id=mygroup

5.2.9.8. 동기화 흐름 생성

스토리지 관리자는 동기화 정책 그룹 또는 특정 버킷에 대해 두 가지 유형의 흐름을 생성할 수 있습니다.

  • 방향 동기화 흐름
  • 대칭 동기화 흐름

group flow create 명령은 동기화 흐름을 생성합니다. 동기화 흐름이 이미 있는 동기화 정책 그룹 또는 버킷에 대해 그룹 flow create 명령을 실행하면 명령에서 동기화 흐름의 기존 설정을 덮어쓰고 지정한 설정을 적용합니다.

사전 요구 사항

  • 실행 중인 Red Hat Ceph Storage 클러스터.
  • root 또는 sudo 액세스.
  • Ceph Object Gateway가 설치되어 있습니다.

절차

  1. 방향 동기화 흐름을 생성하거나 업데이트합니다. 특정 버킷의 방향 동기화 흐름을 생성하거나 업데이트하려면 --bucket 옵션을 사용합니다.

    구문

    radosgw-admin sync group flow create --bucket=BUCKET-NAME --group-id=GROUP-ID --flow-id=FLOW-ID --flow-type=directional --source-zone=SOURCE-ZONE --dest-zone=DESTINATION-ZONE

    • 대칭 동기화 흐름을 생성하거나 업데이트합니다. 대칭 흐름 유형에 대해 여러 영역을 지정하려면 --zones 옵션에 쉼표로 구분된 목록을 사용합니다.

      구문

      radosgw-admin sync group flow create --bucket=BUCKET-NAME --group-id=GROUP-ID --flow-id=FLOW-ID --flow-type=symmetrical --zones=ZONE-NAME

5.2.9.9. 동기화 흐름 및 영역 제거

group flow remove 명령은 동기화 정책 그룹 또는 버킷에서 동기화 흐름 또는 영역을 제거합니다.

방향 흐름을 사용하여 동기화 정책 그룹 또는 버킷의 경우 그룹 흐름 제거 에서 흐름이 제거됩니다. 대칭 흐름을 사용하여 정책 그룹 또는 버킷 동기화의 경우 그룹 flow remove 명령을 사용하여 흐름에서 지정된 영역을 제거하거나 흐름을 제거할 수 있습니다.

사전 요구 사항

  • 실행 중인 Red Hat Ceph Storage 클러스터.
  • root 또는 sudo 액세스.
  • Ceph Object Gateway가 설치되어 있습니다.

절차

  1. 방향 동기화 흐름을 제거합니다. 특정 버킷의 방향 동기화 흐름을 제거하려면 --bucket 옵션을 사용합니다.

    구문

    radosgw-admin sync group flow remove --bucket=BUCKET-NAME --group-id=GROUP-ID --flow-id=FLOW-ID --flow-type=directional --source-zone=SOURCE-ZONE --dest-zone=DESTINATION-ZONE

    • 대칭 동기화 흐름에서 특정 영역을 제거합니다. 대칭 흐름에서 여러 영역을 제거하려면 --zones 옵션에 쉼표로 구분된 목록을 사용합니다.

      구문

      radosgw-admin sync group flow remove --bucket=BUCKET-NAME --group-id=GROUP-ID --flow-id=FLOW-ID --flow-type=symmetrical --zones=ZONE-NAME

    • 대칭 동기화 흐름을 제거합니다. 버킷에서 동기화 흐름을 제거하려면 --bucket 옵션을 사용합니다.

      구문

      radosgw-admin sync group flow create --bucket=BUCKET-NAME --group-id=GROUP-ID --flow-id=FLOW-ID --flow-type=symmetrical --zones=ZONE-NAME

5.2.9.10. 동기화 그룹 파이프 생성 또는 업데이트

스토리지 관리자는 파이프를 정의하여 구성된 데이터 흐름 및 해당 데이터 흐름과 관련된 속성을 사용할 수 있는 버킷을 지정할 수 있습니다.

동기화 그룹 pipe create 명령을 사용하면 특정 버킷 또는 버킷 그룹 간 또는 특정 영역 또는 영역 그룹 간에 사용자 정의 동기화 그룹 데이터 흐름인 파이프를 만들 수 있습니다.

이 명령은 다음 옵션을 사용합니다.

옵션설명필수/선택 사항

--bucket

데이터 흐름을 포함하는 버킷의 이름입니다. 모든 버킷에 와일드카드 * 를 사용합니다.

선택 사항

--group-id

동기화 그룹의 ID

필수 항목

--pipe-id

파이프 ID

필수 항목

--source-zones

동기화 그룹으로 데이터를 보내는 영역입니다. 쉼표를 사용하여 여러 영역을 구분합니다. 데이터 흐름 규칙과 일치하는 모든 영역에 와일드카드 * 를 사용합니다.

필수 항목

--source-bucket

동기화 그룹에 데이터를 보내는 버킷 또는 버킷입니다.

선택 사항

--source-bucket-id

소스 버킷의 ID입니다.

선택 사항

--dest-zones

동기화 데이터를 수신하는 영역 또는 영역입니다. 쉼표를 사용하여 여러 영역을 구분합니다. 데이터 흐름 규칙과 일치하는 모든 영역에 와일드카드 * 를 사용합니다.

필수 항목

--dest-bucket

동기화 데이터를 수신하는 버킷 또는 버킷입니다.

선택 사항

--dest-bucket-id

대상 버킷의 ID입니다.

선택 사항

--prefix

버킷 접두사. 와일드카드 * 를 사용하여 소스 오브젝트를 필터링합니다.

선택 사항

--prefix-rm

필터링에 버킷 접두사를 사용하지 마십시오.

선택 사항

--tags-add

쉼표로 구분된 key=value 쌍 목록입니다.

선택 사항

--tags-rm

태그의 하나 이상의 key=value 쌍을 제거합니다.

선택 사항

--dest-owner

소스에서 오브젝트의 대상 소유자입니다.

선택 사항

--storage-class

소스에서 오브젝트의 대상 stoarge 클래스입니다.

선택 사항

--mode

시스템 모드 또는 사용자 모드에서 시스템 사용.

선택 사항

--UID

사용자 모드에서 권한 검증에 사용됩니다. 동기화 작업이 실행될 사용자 ID를 지정합니다.

선택 사항

사전 요구 사항

  • 실행 중인 Red Hat Ceph Storage 클러스터.
  • root 또는 sudo 액세스.
  • Ceph Object Gateway가 설치되어 있습니다.

절차

  1. 동기화 그룹 파이프를 생성합니다.

    구문

    radosgw-admin sync group pipe create --bucket=BUCKET-NAME --group-id=GROUP-ID --pipe-id=PIPE-ID --source-zones=ZONE-NAME, ZONE-NAME2... --source-bucket=SOURCE-BUCKET1, SOURCE-BUCKET2... --source-bucket-id=SOURCE-BUCKET-ID --dest-zones=ZONE-NAME, ZONE-NAME2... --dest-bucket=SOURCE-BUCKET1, SOURCE-BUCKET2... --dest-bucket-id=DESTINATION-BUCKET-ID --prefix=SOURCE-PREFIX --prefix-rm --tags-add=KEY1=VALUE1, KEY2=VALUE2, ... --tags-rm=KEY1=VALUE1, KEY2=VALUE2, ... --dest-owner=OWNER-ID --storage-class=STORAGE-CLASS --mode=USER --uid=USER-ID

5.2.9.11. 동기화 그룹 파이프 수정 또는 삭제

스토리지 관리자는 sync group pipe remove 명령을 사용하여 특정 옵션을 제거하여 동기화 그룹 파이프를 수정할 수 있습니다. 이 명령을 사용하여 동기화 그룹 파이프를 완전히 제거할 수도 있습니다.

이 명령은 다음 옵션을 사용합니다.

옵션설명필수/선택 사항

--bucket

데이터 흐름을 포함하는 버킷의 이름입니다. 모든 버킷에 와일드카드 * 를 사용합니다.

선택 사항

--group-id

동기화 그룹의 ID

필수 항목

--pipe-id

파이프 ID

필수 항목

--source-zones

동기화 그룹으로 데이터를 보내는 영역입니다. 쉼표를 사용하여 여러 영역을 구분합니다. 데이터 흐름 규칙과 일치하는 모든 영역에 와일드카드 * 를 사용합니다.

필수 항목

--source-bucket

동기화 그룹에 데이터를 보내는 버킷 또는 버킷입니다.

선택 사항

--source-bucket-id

소스 버킷의 ID입니다.

선택 사항

--dest-zones

동기화 데이터를 수신하는 영역 또는 영역입니다. 쉼표를 사용하여 여러 영역을 구분합니다. 데이터 흐름 규칙과 일치하는 모든 영역에 와일드카드 * 를 사용합니다.

필수 항목

--dest-bucket

동기화 데이터를 수신하는 버킷 또는 버킷입니다.

선택 사항

--dest-bucket-id

대상 버킷의 ID입니다.

선택 사항

사전 요구 사항

  • 실행 중인 Red Hat Ceph Storage 클러스터.
  • root 또는 sudo 액세스.
  • Ceph Object Gateway가 설치되어 있습니다.

절차

  1. 동기화 그룹 파이프 옵션을 제거합니다.

    구문

    radosgw-admin sync group pipe remove --bucket=BUCKET-NAME --group-id=GROUP-ID --pipe-id=PIPE-ID --source-zones=ZONE-NAME, ZONE-NAME2... --source-bucket=SOURCE-BUCKET1, SOURCE-BUCKET2... --source-bucket-id=SOURCE-BUCKET-ID --dest-zones=ZONE-NAME, ZONE-NAME2... --dest-bucket=SOURCE-BUCKET1, SOURCE-BUCKET2... --dest-bucket-id=DESTINATION-BUCKET-ID

5.2.9.12. 동기화 작업에 대한 정보 가져오기

sync info 명령을 사용하면 동기화 정책에 정의된 대로 예상 동기화 소스 및 대상에 대한 정보를 가져올 수 있습니다.

버킷에 대한 동기화 정책을 생성할 때 해당 정책은 해당 버킷에서 다른 영역의 다른 버킷으로 이동하는 방법을 정의합니다. 정책을 생성하면 버킷이 다른 버킷과 동기화될 때마다 힌트로 사용되는 버킷 종속성 목록도 생성됩니다. 동기화는 데이터 흐름에서 동기화를 수행할 수 있는지 여부에 따라 달라지므로 버킷은 실제로 동기화하지 않고 다른 버킷을 참조할 수 있습니다.

bucket 및 effective -zone-name 매개변수는 모두 선택 사항입니다. 옵션을 지정하지 않고 sync info 명령을 호출하면 Object Gateway에서 모든 영역의 동기화 정책에 정의된 모든 동기화 작업을 반환합니다.

사전 요구 사항

  • 실행 중인 Red Hat Ceph Storage 클러스터.
  • root 또는 sudo 액세스.
  • Ceph Object Gateway가 설치되어 있습니다.
  • 그룹 동기화 정책이 정의됩니다.

절차

  1. 동기화 작업에 대한 정보를 가져옵니다.

    구문

    radosgw-admin sync info --bucket=BUCKET-NAME --effective-zone-name=ZONE-NAME

5.2.10. 다중 사이트 Ceph Object Gateway 명령줄 사용

스토리지 관리자는 다중 사이트 환경에서 Ceph Object Gateway를 사용하는 방법을 잘 이해할 수 있습니다. 다중 사이트 환경에서 영역, 영역 그룹 및 영역을 더 효율적으로 관리하는 방법을 배울 수 있습니다.

5.2.10.1. 사전 요구 사항

  • 실행 중인 Red Hat Ceph Storage.
  • Ceph Object Gateway 소프트웨어 배포.
  • Ceph Object Gateway 노드 또는 컨테이너에 액세스할 수 있습니다.

5.2.10.2. 영역

영역은 하나 이상의 영역을 포함하는 하나 이상의 영역 그룹과 개체가 포함된 버킷을 포함하는 영역으로 구성된 전역 고유 네임스페이스를 나타냅니다. 영역을 사용하면 Ceph Object Gateway에서 동일한 하드웨어에서 여러 네임스페이스와 해당 구성을 지원할 수 있습니다.

영역에는 마침표의 개념이 포함되어 있습니다. 각 기간은 시간대 그룹 및 영역 구성의 상태를 나타냅니다. 영역 그룹 또는 영역을 변경할 때마다 기간을 업데이트하고 커밋합니다.

기본적으로 Ceph Object Gateway 버전 2는 버전 1.3 및 이전 버전과의 호환성을 위한 영역을 생성하지 않습니다. 그러나 Red Hat은 모범 사례로 새 클러스터에 대한 영역을 생성하는 것이 좋습니다.

5.2.10.2.1. Realm 생성

영역을 생성하려면 영역 생성을 실행하고 영역 이름을 지정합니다. 영역이 기본값인 경우 --default 를 지정합니다.

[root@master-zone]# radosgw-admin realm create --rgw-realm={realm-name} [--default]

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

[root@master-zone]# radosgw-admin realm create --rgw-realm=movies --default

--default를 지정하면 -- rgw-realm 및 영역 이름이 명시적으로 제공되지 않는 한 각 radosgw- admin 호출에서 영역이 암시적으로 호출됩니다.

5.2.10.2.2. Realm을 기본값으로 설정

영역 목록에서 하나의 영역이 기본 영역이어야 합니다. 기본 영역은 하나만 있을 수 있습니다. 영역이 하나뿐이고 생성 시 기본 영역으로 지정되지 않은 경우 기본 영역으로 설정합니다. 또는 기본값인 영역을 변경하려면 다음을 실행합니다.

[root@master-zone]# radosgw-admin realm default --rgw-realm=movies
참고

영역이 기본값이면 명령줄에서 --rgw-realm=<realm-name> 을 인수로 가정합니다.

5.2.10.2.3. 영역 삭제

영역을 삭제하려면 realm delete를 실행하고 영역 이름을 지정합니다.

[root@master-zone]# radosgw-admin realm delete --rgw-realm={realm-name}

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

[root@master-zone]# radosgw-admin realm delete --rgw-realm=movies
5.2.10.2.4. 영역 가져오기

영역을 가져오려면 realm get를 실행하고 영역 이름을 지정합니다.

# radosgw-admin realm get --rgw-realm=<name>

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

# radosgw-admin realm get --rgw-realm=movies [> filename.json]

CLI는 영역 속성을 사용하여 JSON 오브젝트를 에코합니다.

{
    "id": "0a68d52e-a19c-4e8e-b012-a8f831cb3ebc",
    "name": "movies",
    "current_period": "b0c5bbef-4337-4edd-8184-5aeab2ec413b",
    "epoch": 1
}

> 및 출력 파일 이름을 사용하여 JSON 오브젝트를 파일로 출력합니다.

5.2.10.2.5. Realm 설정

영역을 설정하려면 영역 세트를 실행하고 입력 파일 이름을 사용하여 영역 이름을 지정하고 --infile= 을 지정합니다.

[root@master-zone]# radosgw-admin realm set --rgw-realm=<name> --infile=<infilename>

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

[root@master-zone]# radosgw-admin realm set --rgw-realm=movies --infile=filename.json
5.2.10.2.6. Realms 나열

영역을 나열하려면 영역 목록을 실행합니다.

# radosgw-admin realm list
5.2.10.2.7. 영역 기간 나열

영역 기간을 나열하려면 영역 목록을 실행합니다.

# radosgw-admin realm list-periods
5.2.10.2.8. Realm 가져오기

마스터 영역 그룹 및 마스터 영역을 포함하는 노드에서 보조 영역 그룹 또는 영역을 포함하는 노드로 영역을 가져오려면 영역 구성을 수신할 노드에서 영역 가져오기를 실행합니다.

# radosgw-admin realm pull --url={url-to-master-zone-gateway} --access-key={access-key} --secret={secret}
5.2.10.2.9. 영역 이름 변경

영역은 기간의 일부가 아닙니다. 결과적으로 영역 이름 변경은 로컬로만 적용되며 영역 가져오기를 통해 가져오지 않습니다. 여러 영역의 영역 이름을 변경할 때 각 영역에서 명령을 실행합니다. 영역 이름을 변경하려면 다음을 실행합니다.

# radosgw-admin realm rename --rgw-realm=<current-name> --realm-new-name=<new-realm-name>
참고

name 매개 변수를 변경하는 데 realm 을 사용하지 마십시오. 내부 이름만 변경됩니다. --rgw-realm 을 지정하면 이전 영역 이름이 계속 사용됩니다.

5.2.10.3. 영역 그룹

Ceph Object Gateway는 영역 그룹 개념을 사용하여 다중 사이트 배포 및 글로벌 네임스페이스를 지원합니다. 이전에는 지역이라고 하는 영역 그룹은 하나 이상의 Ceph Object Gateway 인스턴스의 지리적 위치를 하나 이상의 영역에 정의합니다.

모든 설정이 Ceph 구성 파일에 종료되지 않으므로 영역 그룹 구성은 일반적인 구성 절차와 다릅니다. 영역 그룹을 나열하고, 영역 그룹 구성을 가져오고, 영역 그룹 구성을 설정할 수 있습니다.

참고

기간 업데이트 단계에서 클러스터 전체에 변경 사항을 전파하므로 radosgw-admin 영역 그룹 작업은 영역 내 모든 노드에서 수행할 수 있습니다. 그러나 radosgw-admin 영역 작업은 영역 내의 호스트에서 수행해야 합니다.

5.2.10.3.1. 영역 그룹 생성

영역 그룹 생성은 영역 그룹 이름을 지정하는 것으로 구성됩니다. 영역을 만들면 --rgw-realm=<realm-name> 이 지정되지 않는 한 기본 영역에 존재한다고 가정합니다. zonegroup이 기본 영역 그룹인 경우 --default 플래그를 지정합니다. zonegroup이 마스터 영역 그룹인 경우 --master 플래그를 지정합니다. 예를 들면 다음과 같습니다.

# radosgw-admin zonegroup create --rgw-zonegroup=<name> [--rgw-realm=<name>][--master] [--default]
참고

zonegroup에서 --rgw-zonegroup=<zonegroup-name> 을 수정하여 기존 영역 그룹의 설정을 수정합니다.

5.2.10.3.2. 영역 그룹을 기본값으로 만들기

영역 그룹 목록에 있는 하나의 zonegroup이 기본 영역 그룹이어야 합니다. 기본 영역 그룹이 하나만 있을 수 있습니다. 영역 그룹이 하나뿐이고 생성 시 기본 영역 그룹으로 지정되지 않은 경우 기본 영역 그룹으로 설정합니다. 또는 기본값인 영역 그룹을 변경하려면 다음을 실행합니다.

# radosgw-admin zonegroup default --rgw-zonegroup=comedy
참고

zonegroup이 default이면 명령줄에서 --rgw-zonegroup=<zonegroup-name> 을 인수로 가정합니다.

그런 다음 기간을 업데이트합니다.

# radosgw-admin period update --commit
5.2.10.3.3. 영역 그룹에 영역 추가

영역 그룹에 영역을 추가하려면 영역에 있을 호스트에서 이 단계를 실행해야 합니다. 영역을 영역 그룹에 추가하려면 다음을 실행합니다.

# radosgw-admin zonegroup add --rgw-zonegroup=<name> --rgw-zone=<name>

그런 다음 기간을 업데이트합니다.

# radosgw-admin period update --commit
5.2.10.3.4. 영역 그룹에서 영역 제거

영역 그룹에서 영역을 제거하려면 다음을 실행합니다.

# radosgw-admin zonegroup remove --rgw-zonegroup=<name> --rgw-zone=<name>

그런 다음 기간을 업데이트합니다.

# radosgw-admin period update --commit
5.2.10.3.5. 영역 그룹 이름 변경

영역 그룹의 이름을 변경하려면 다음을 실행합니다.

# radosgw-admin zonegroup rename --rgw-zonegroup=<name> --zonegroup-new-name=<name>

그런 다음 기간을 업데이트합니다.

# radosgw-admin period update --commit
5.2.10.3.6. 영역 그룹 삭제

영역 그룹을 삭제하려면 다음을 실행합니다.

# radosgw-admin zonegroup delete --rgw-zonegroup=<name>

그런 다음 기간을 업데이트합니다.

# radosgw-admin period update --commit
5.2.10.3.7. 영역 그룹 나열

Ceph 클러스터에는 영역 그룹 목록이 포함되어 있습니다. 영역 그룹을 나열하려면 다음을 실행합니다.

# radosgw-admin zonegroup list

radosgw-admin 은 JSON 형식의 영역 그룹 목록을 반환합니다.

{
    "default_info": "90b28698-e7c3-462c-a42d-4aa780d24eda",
    "zonegroups": [
        "us"
    ]
}
5.2.10.3.8. 영역 그룹 가져오기

영역 그룹의 구성을 보려면 다음을 실행합니다.

# radosgw-admin zonegroup get [--rgw-zonegroup=<zonegroup>]

영역 그룹 구성은 다음과 같습니다.

{
    "id": "90b28698-e7c3-462c-a42d-4aa780d24eda",
    "name": "us",
    "api_name": "us",
    "is_master": "true",
    "endpoints": [
        "http:\/\/rgw1:80"
    ],
    "hostnames": [],
    "hostnames_s3website": [],
    "master_zone": "9248cab2-afe7-43d8-a661-a40bf316665e",
    "zones": [
        {
            "id": "9248cab2-afe7-43d8-a661-a40bf316665e",
            "name": "us-east",
            "endpoints": [
                "http:\/\/rgw1"
            ],
            "log_meta": "true",
            "log_data": "true",
            "bucket_index_max_shards": 0,
            "read_only": "false"
        },
        {
            "id": "d1024e59-7d28-49d1-8222-af101965a939",
            "name": "us-west",
            "endpoints": [
                "http:\/\/rgw2:80"
            ],
            "log_meta": "false",
            "log_data": "true",
            "bucket_index_max_shards": 0,
            "read_only": "false"
        }
    ],
    "placement_targets": [
        {
            "name": "default-placement",
            "tags": []
        }
    ],
    "default_placement": "default-placement",
    "realm_id": "ae031368-8715-4e27-9a99-0c9468852cfe"
}
5.2.10.3.9. 영역 그룹 설정

영역 그룹 정의는 최소한 필요한 설정을 지정하는 JSON 오브젝트를 생성하는 것으로 구성됩니다.

  1. name: 영역 그룹의 이름입니다. 필수 항목입니다.
  2. api_name: 영역 그룹의 API 이름입니다. 선택 사항:
  3. is_master: 영역 그룹이 마스터 영역 그룹인지 여부를 결정합니다. 필수 항목 : 하나의 마스터 영역 그룹만 가질 수 있습니다.
  4. 엔드 포인트 : 영역 그룹의 모든 엔드포인트 목록입니다. 예를 들어 여러 도메인 이름을 사용하여 동일한 영역 그룹을 참조할 수 있습니다. 슬래시(\/)를 이스케이프해야 합니다. 각 엔드포인트에 포트(fqdn:port)를 지정할 수도 있습니다. 선택 사항:
  5. hostnames: 영역 그룹의 모든 호스트 이름 목록입니다. 예를 들어 여러 도메인 이름을 사용하여 동일한 영역 그룹을 참조할 수 있습니다. 선택 사항: rgw dns 이름 설정이 이 목록에 자동으로 포함됩니다. 이 설정을 변경한 후 게이트웨이 데몬을 다시 시작해야 합니다.
  6. master_zone: 영역 그룹의 마스터 영역입니다. 선택 사항: 지정하지 않는 경우 기본 영역을 사용합니다. 참고: 영역 그룹당 하나의 마스터 영역만 가질 수 있습니다.
  7. 영역: 영역 그룹 내의 모든 영역 목록. 각 영역에는 이름(필수), 엔드포인트 목록(선택 사항) 및 게이트웨이가 메타데이터 및 데이터 작업(기본값)을 기록할지 여부가 있습니다.
  8. placement_targets: 배치 대상 목록(선택 사항). 각 배치 대상에는 배치 대상의 이름(필수)과 태그 목록(선택 사항)이 포함되어 있으므로 태그가 있는 사용자만 배치 대상(즉, 사용자 info의 사용자 placement_tags 필드)을 사용할 수 있습니다.
  9. default_placement: 오브젝트 인덱스 및 오브젝트 데이터의 기본 배치 대상입니다. 기본적으로 default-placement 로 설정합니다. 각 사용자에 대한 사용자 정보에 사용자별 기본 배치를 설정할 수도 있습니다.

영역 그룹을 설정하려면 필수 필드로 구성된 JSON 오브젝트를 생성하고 오브젝트를 파일에 저장합니다(예: zonegroup.json).

# radosgw-admin zonegroup set --infile zonegroup.json

여기서 zonegroup.json 은 생성한 JSON 파일입니다.

중요

기본 영역 그룹 is_master 설정은 기본적으로 true 입니다. 새 영역 그룹을 생성하고 마스터 영역 그룹을 생성하려면 기본 영역 그룹 is_master 설정을 false 로 설정하거나 기본 영역 그룹을 삭제해야 합니다.

마지막으로 기간을 업데이트합니다.

# radosgw-admin period update --commit
5.2.10.3.10. 영역 그룹 맵 설정

영역 그룹 맵 설정은 하나 이상의 영역 그룹으로 구성된 JSON 오브젝트를 생성하고 클러스터에 대한 master_zonegroup 을 설정하는 것입니다. 영역 그룹 맵의 각 영역 그룹은 키/값 쌍으로 구성됩니다. 여기서 설정은 개별 영역 그룹 구성에 대한 이름 설정과 동일하며, val 는 개별 영역 그룹 구성으로 구성된 JSON 오브젝트입니다.

is_mastertrue 인 영역 그룹이 하나만 있을 수 있으며 영역 그룹 맵 끝에 master_zonegroup 으로 지정해야 합니다. 다음 JSON 오브젝트는 기본 영역 그룹 맵의 예입니다.

{
    "zonegroups": [
        {
            "key": "90b28698-e7c3-462c-a42d-4aa780d24eda",
            "val": {
                "id": "90b28698-e7c3-462c-a42d-4aa780d24eda",
                "name": "us",
                "api_name": "us",
                "is_master": "true",
                "endpoints": [
                    "http:\/\/rgw1:80"
                ],
                "hostnames": [],
                "hostnames_s3website": [],
                "master_zone": "9248cab2-afe7-43d8-a661-a40bf316665e",
                "zones": [
                    {
                        "id": "9248cab2-afe7-43d8-a661-a40bf316665e",
                        "name": "us-east",
                        "endpoints": [
                            "http:\/\/rgw1"
                        ],
                        "log_meta": "true",
                        "log_data": "true",
                        "bucket_index_max_shards": 0,
                        "read_only": "false"
                    },
                    {
                        "id": "d1024e59-7d28-49d1-8222-af101965a939",
                        "name": "us-west",
                        "endpoints": [
                            "http:\/\/rgw2:80"
                        ],
                        "log_meta": "false",
                        "log_data": "true",
                        "bucket_index_max_shards": 0,
                        "read_only": "false"
                    }
                ],
                "placement_targets": [
                    {
                        "name": "default-placement",
                        "tags": []
                    }
                ],
                "default_placement": "default-placement",
                "realm_id": "ae031368-8715-4e27-9a99-0c9468852cfe"
            }
        }
    ],
    "master_zonegroup": "90b28698-e7c3-462c-a42d-4aa780d24eda",
    "bucket_quota": {
        "enabled": false,
        "max_size_kb": -1,
        "max_objects": -1
    },
    "user_quota": {
        "enabled": false,
        "max_size_kb": -1,
        "max_objects": -1
    }
}

영역 그룹 맵을 설정하려면 다음을 실행합니다.

# radosgw-admin zonegroup-map set --infile zonegroupmap.json

여기서 zonegroupmap.json 은 생성한 JSON 파일입니다. 영역 그룹 맵에 지정된 영역에 대해 생성된 영역이 있는지 확인합니다. 마지막으로 기간을 업데이트합니다.

# radosgw-admin period update --commit

5.2.10.4. 영역

Ceph Object Gateway는 영역 개념을 지원합니다. 영역은 하나 이상의 Ceph Object Gateway 인스턴스로 구성된 논리적 그룹을 정의합니다.

모든 설정이 Ceph 구성 파일에 종료되는 것은 아니므로 영역 구성은 일반적인 구성 절차와 다릅니다. 영역을 나열하고, 영역 구성을 가져오고, 영역 구성을 설정할 수 있습니다.

중요

모든 radosgw-admin 영역 작업은 영역 내에서 작동하거나 작동하는 호스트에서 실행해야 합니다.

5.2.10.4.1. 영역 생성

영역을 생성하려면 영역 이름을 지정합니다. 마스터 영역인 경우 --master 옵션을 지정합니다. 영역 그룹의 영역 하나만 마스터 영역일 수 있습니다. 영역을 영역 그룹에 추가하려면 zonegroup 이름으로 --rgw-zonegroup 옵션을 지정합니다.

중요

영역은 영역 내에 있는 Ceph Object Gateway 노드에서 생성해야 합니다.

[root@zone] radosgw-admin zone create --rgw-zone=<name> \
                [--zonegroup=<zonegroup-name]\
                [--endpoints=<endpoint:port>[,<endpoint:port>] \
                [--master] [--default] \
                --access-key $SYSTEM_ACCESS_KEY --secret $SYSTEM_SECRET_KEY

그런 다음 기간을 업데이트합니다.

# radosgw-admin period update --commit
5.2.10.4.2. 영역 삭제

먼저 영역을 삭제하려면 zonegroup에서 해당 영역을 제거합니다.

# radosgw-admin zonegroup remove --rgw-zonegroup=<name>\
                                 --rgw-zone=<name>

그런 다음 기간을 업데이트합니다.

# radosgw-admin period update --commit

그런 다음 영역을 삭제합니다.

중요

절차는 영역 내의 호스트에서 실행해야 합니다.

다음을 실행합니다.

[root@zone]# radosgw-admin zone delete --rgw-zone<name>

마지막으로 기간을 업데이트합니다.

# radosgw-admin period update --commit
중요

먼저 영역 그룹에서 영역을 제거하지 않고 삭제하지 마십시오. 그렇지 않으면 기간 업데이트에 실패합니다.

삭제된 영역의 풀이 다른 곳에 사용되지 않는 경우 풀을 삭제하는 것이 좋습니다. 아래 예에서 <del-zone> 을 삭제된 영역의 이름으로 바꿉니다.

중요

Ceph가 영역 풀을 삭제하면 복구할 수 없는 방식으로 해당 영역 내의 모든 데이터를 삭제합니다. Ceph 클라이언트에 더 이상 풀 콘텐츠가 필요하지 않은 경우에만 영역 풀을 삭제합니다.

중요

다중 영역 클러스터에서 영역 풀과 함께 .rgw.root 풀을 삭제하면 클러스터의 모든 영역 정보가 제거됩니다. .rgw.root 풀을 삭제하기 전에 .rgw.root 영역이 없는지 확인합니다.

# ceph osd pool delete <del-zone>.rgw.control <del-zone>.rgw.control --yes-i-really-really-mean-it
# ceph osd pool delete <del-zone>.rgw.data.root <del-zone>.rgw.data.root --yes-i-really-really-mean-it
# ceph osd pool delete <del-zone>.rgw.log <del-zone>.rgw.log --yes-i-really-really-mean-it
# ceph osd pool delete <del-zone>.rgw.users.uid <del-zone>.rgw.users.uid --yes-i-really-really-mean-it
중요

풀을 삭제한 후 RGW 프로세스를 다시 시작합니다.

5.2.10.4.3. 영역 수정

영역을 수정하려면 영역 이름과 수정할 매개변수를 지정합니다.

중요

영역은 영역 내에 있는 Ceph Object Gateway 노드에서 수정해야 합니다.

[root@zone]# radosgw-admin zone modify [options]

--access-key=<key>--secret/--secret-key=<key>--master--default--endpoints=<list>

그런 다음 기간을 업데이트합니다.

# radosgw-admin period update --commit
5.2.10.4.4. 영역 나열

root 로 클러스터의 영역을 나열하려면 다음을 실행합니다.

# radosgw-admin zone list
5.2.10.4.5. 영역 가져오기

root 로 영역 구성을 가져오려면 다음을 실행합니다.

# radosgw-admin zone get [--rgw-zone=<zone>]

기본 영역은 다음과 같습니다.

{ "domain_root": ".rgw",
  "control_pool": ".rgw.control",
  "gc_pool": ".rgw.gc",
  "log_pool": ".log",
  "intent_log_pool": ".intent-log",
  "usage_log_pool": ".usage",
  "user_keys_pool": ".users",
  "user_email_pool": ".users.email",
  "user_swift_pool": ".users.swift",
  "user_uid_pool": ".users.uid",
  "system_key": { "access_key": "", "secret_key": ""},
  "placement_pools": [
      {  "key": "default-placement",
         "val": { "index_pool": ".rgw.buckets.index",
                  "data_pool": ".rgw.buckets"}
      }
    ]
  }
5.2.10.4.6. 영역 설정

영역을 구성하려면 일련의 Ceph Object Gateway 풀을 지정해야 합니다. 일관성을 위해 영역 이름과 동일한 풀 접두사를 사용하는 것이 좋습니다. 풀 구성에 대한 자세한 내용은 Pools_를 참조하십시오.

중요

영역은 영역 내에 있는 Ceph Object Gateway 노드에 설정해야 합니다.

영역을 설정하려면 풀로 구성된 JSON 오브젝트를 생성하고 오브젝트를 파일(예: zone.json)에 저장합니다.그런 다음 {zone-name} 을 영역 이름으로 교체하여 다음 명령을 실행합니다.

[root@zone]# radosgw-admin zone set --rgw-zone={zone-name} --infile zone.json

여기서 zone.json 은 생성한 JSON 파일입니다.

그런 다음 root 로 기간을 업데이트합니다.

# radosgw-admin period update --commit
5.2.10.4.7. 영역 이름 변경

영역 이름을 변경하려면 영역 이름과 새 영역 이름을 지정합니다. 영역 내 호스트에서 다음을 실행합니다.

[root@zone]# radosgw-admin zone rename --rgw-zone=<name> --zone-new-name=<name>

그런 다음 기간을 업데이트합니다.

# radosgw-admin period update --commit

5.3. LDAP 및 Ceph Object Gateway 설정

다음 단계를 수행하여 Ceph Object Gateway 사용자를 인증하도록 Red Hat Directory Server를 구성합니다.

5.3.1. Red Hat Directory Server 설치

Java Swing GUI Directory 및 Administration 콘솔을 사용하려면 GUI(그래픽 사용자 인터페이스)가 있는 Red Hat Enterprise Linux 8에 Red Hat Directory Server를 설치해야 합니다. 그러나 Red Hat Directory Server는 CLI(명령줄 인터페이스)에서만 서비스를 제공할 수 있습니다.

사전 요구 사항

  • RHEL(Red Hat Enterprise Linux)이 서버에 설치됩니다.
  • Directory Server 노드의 FQDN은 DNS 또는 /etc/hosts 파일을 사용하여 확인할 수 있습니다.
  • Directory Server 노드를 Red Hat 서브스크립션 관리 서비스에 등록합니다.
  • Red Hat 계정으로 유효한 Red Hat Directory Server 서브스크립션이 제공됩니다.

절차

  1. Red Hat Directory Server 설치 가이드1장 및 2 장에서 지침을 따르십시오.

추가 리소스

5.3.2. 디렉터리 서버 방화벽 설정

LDAP 호스트에서 LDAP 클라이언트가 Directory Server에 액세스할 수 있도록 방화벽에서 Directory Server의 보안(636) 포트에 액세스할 수 있는지 확인합니다. 기본 비보안 포트(389)종료합니다.

# firewall-cmd --zone=public --add-port=636/tcp
# firewall-cmd --zone=public --add-port=636/tcp --permanent

5.3.3. SELinux의 레이블 포트

SELinux가 요청을 차단하지 않도록 하려면 SELinux의 포트에 레이블을 지정합니다. 자세한 내용은 Red Hat Directory Server 10 관리 가이드 의 디렉터리 서버 포트 번호 변경 섹션을 참조하십시오.

5.3.4. LDAPS 설정

Ceph Object Gateway는 간단한 ID와 암호를 사용하여 LDAP 서버로 인증하므로 연결에는 LDAP용 SSL 인증서가 필요합니다. LDAP용 디렉터리 서버를 구성하려면 Red Hat Directory Server 11 관리 가이드보안 연결 구성 장을 참조하십시오.

LDAP가 작동하고 나면 Directory Server의 인증서를 신뢰하도록 Ceph Object Gateway 서버를 구성합니다.

  1. LDAP 서버의 SSL 인증서에 서명한 CA(인증 기관)에 대한 PEM 형식의 인증서를 추출/다운로드.
  2. /etc/openldap/ldap.confTLS_RE¢ERT가 설정되어 있지 않은지 확인합니다.
  3. /etc/openldap/ldap.confTLS_CACERTDIR /etc/openldap/certs 설정이 포함되어 있는지 확인합니다.
  4. certutil 명령을 사용하여 AD CA를 /etc/openldap/certs의 저장소에 추가합니다. 예를 들어 CA가 "msad-frog-MSAD-FROG-CA"이고 PEM 형식 CA 파일이 ldap.pem 인 경우 다음 명령을 사용합니다.

    # certutil -d /etc/openldap/certs -A -t "TC,," -n "msad-frog-MSAD-FROG-CA" -i /path/to/ldap.pem
  5. 모든 원격 LDAP 사이트에서 SELinux를 업데이트합니다.

    # setsebool -P httpd_can_network_connect on
    참고

    SELinux가 허용 모드인 경우에도 이 설정은 계속 설정해야 합니다.

  6. 인증서 데이터베이스를 누구나 읽을 수 있게 만듭니다.

    # chmod 644 /etc/openldap/certs/*

"ldapwhoami"를 루트가 아닌 사용자로 사용하여 서버에 연결합니다. 예를 들면 다음과 같습니다.

$ ldapwhoami -H ldaps://rh-directory-server.example.com -d 9

d 9 옵션은 SSL 협상에서 문제가 발생하는 경우 디버깅 정보를 제공합니다.

5.3.5. Gateway 사용자 Exists 확인

gateway 사용자를 만들기 전에 Ceph Object Gateway에 사용자가 아직 없는지 확인합니다. 예를 들면 다음과 같습니다.

# radosgw-admin metadata list user

사용자 이름은 이 사용자 목록에 없어야 합니다.

5.3.6. 게이트웨이 사용자 추가

Ceph Object Gateway에 대한 LDAP 사용자를 생성하고 binddn 을 기록합니다. Ceph 개체 게이트웨이는 ceph 사용자를 사용하므로 사용자 이름으로 ceph 를 사용하는 것이 좋습니다. 사용자는 디렉터리를 검색할 수 있는 권한이 있어야 합니다.

사용자 생성이 작동하는지 테스트합니다. 여기서 ceph는 People 및 example.com의 사용자 ID이며, 사용자를 검색할 수 있습니다.

Ceph 개체 게이트웨이는 rgw_ldap_binddn 에 지정된 대로 이 사용자에게 바인딩됩니다.

사용자 생성이 작동하는지 테스트합니다. 여기서 cephPeopleexample.com 의 사용자 ID이며, 사용자를 검색할 수 있습니다.

# ldapsearch -x -D "uid=ceph,ou=People,dc=example,dc=com" -W -H ldaps://example.com -b "ou=People,dc=example,dc=com" -s sub 'uid=ceph'

각 게이트웨이 노드에서 사용자 시크릿에 대한 파일을 만듭니다. 예를 들어 시크릿은 /etc/bindpass 라는 파일에 저장될 수 있습니다. 보안을 위해 이 파일의 소유자를 ceph 사용자 및 그룹으로 변경하여 전역적으로 읽을 수 없는지 확인합니다.

rgw_ldap_secret 옵션을 추가합니다.

구문

ceph config set client.rgw OPTION VALUE

예제

[root@mon ~]# ceph config set client.rgw rgw_ldap_secret /etc/bindpass

마지막으로 업데이트된 구성 파일을 각 Ceph 노드에 복사합니다.

# scp /etc/ceph/ceph.conf <node>:/etc/ceph

5.3.7. LDAP를 사용하도록 게이트웨이 설정

  1. Ceph 구성 파일의 [global] 섹션에 다음 설정을 추가합니다. 예를 들면 다음과 같습니다.

    [global]
    rgw_ldap_uri = ldaps://<fqdn>:636
    rgw_ldap_binddn = "<binddn>"
    rgw_ldap_secret = "/etc/bindpass"
    rgw_ldap_searchdn = "<seachdn>"
    rgw_ldap_dnattr = "uid"
    rgw_s3_auth_use_ldap = true

    rgw_ldap_uri 설정의 경우 <fqdn> 을 LDAP 서버의 정규화된 도메인 이름으로 바꿉니다. LDAP 서버가 두 개 이상 있는 경우 각 도메인을 지정합니다.

    rgw_ldap_binddn 설정의 경우 <binddn> 을 bind 도메인으로 바꿉니다. example.com 도메인과 사용자 및 계정ceph 사용자를 사용하면 다음과 같이 표시되어야 합니다.

    rgw_ldap_binddn = "uid=ceph,cn=users,cn=accounts,dc=example,dc=com"

    rgw_ldap_searchdn 설정의 경우 <searchdn> 을 검색 도메인으로 바꿉니다. example.com 의 도메인과 사용자 및 계정 아래에 있는 사용자는 다음과 같이 표시되어야 합니다.

    rgw_ldap_searchdn = "cn=users,cn=accounts,dc=example,dc=com"
  2. 업데이트된 구성 파일을 각 Ceph 노드에 복사합니다.

    scp /etc/ceph/ceph.conf <hostname>:/etc/ceph
  3. Ceph 개체 게이트웨이를 다시 시작합니다.

    참고

    NAME 열 아래의 ceph orch ps 명령의 출력을 사용하여 SERVICE_TYPE.ID 정보를 가져옵니다.

    1. 스토리지 클러스터의 개별 노드에서 Ceph Object Gateway를 다시 시작하려면 다음을 수행합니다.

      구문

      systemctl restart ceph-CLUSTER_ID@SERVICE_TYPE.ID.service

      예제

      [root@primary-zone]# systemctl restart ceph-c4b34c6f-8365-11ba-dc31-529020a7702d@rgw.realm.zone.node1.gwasto.service

    2. 스토리지 클러스터의 모든 노드에서 Ceph Object Gateway를 다시 시작하려면 다음을 수행합니다.

      구문

      ceph orch restart SERVICE_TYPE

      예제

      [root@primary-zone]# ceph orch restart rgw

5.3.8. 사용자 지정 검색 필터 사용

사용자 지정 검색 필터를 생성하여 rgw_ldap_searchfilter 설정을 사용하여 사용자 액세스를 제한할 수 있습니다. Ceph 구성 파일의 [global] 섹션에 이 설정을 지정합니다(/etc/ceph/ceph.conf). rgw_ldap_searchfilter 설정을 사용하는 방법은 두 가지가 있습니다.

  1. 부분 필터 지정

    예제

    "objectclass=inetorgperson"

    Ceph Object Gateway는 토큰에서 사용자 이름과 rgw_ldap_dnattr 값을 사용하여 검색 필터를 생성합니다. 그러면 구성된 필터가 rgw_ldap_searchfilter 값의 부분 필터와 결합됩니다. 예를 들어 사용자 이름 및 설정은 최종 검색 필터를 생성합니다.

    예제

    "(&(uid=joe)(objectclass=inetorgperson))"

    사용자 joe 는 LDAP 디렉토리에서 발견되는 경우에만 액세스 권한이 부여되며, 개체 클래스가 inetorgperson 이고 유효한 암호를 지정합니다.

  2. 완료 필터 지정

    전체 필터에는 인증을 시도하는 동안 사용자 이름으로 대체할 USERNAME 토큰이 포함되어야 합니다. 이 경우에는 rgw_ldap_dnattr 설정을 사용하지 않습니다. 예를 들어 유효한 사용자를 특정 그룹으로 제한하려면 다음 필터를 사용합니다.

    예제

    "(&(uid=@USERNAME@)(memberOf=cn=ceph-users,ou=groups,dc=mycompany,dc=com))"

5.3.9. LDAP 서버에 S3 사용자 추가

LDAP 서버의 관리 콘솔에서 S3 클라이언트가 LDAP 사용자 자격 증명을 사용할 수 있도록 하나 이상의 S3 사용자를 생성합니다. S3 클라이언트에 자격 증명을 전달할 때 사용할 사용자 이름과 시크릿을 기록합니다.

5.3.10. LDAP 토큰 내보내기

LDAP를 사용하여 Ceph Object Gateway를 실행하는 경우 액세스 토큰만 있으면 됩니다. 그러나 액세스 토큰은 액세스 키와 시크릿에서 생성됩니다. 액세스 키와 비밀 키를 LDAP 토큰으로 내보냅니다.

  1. 액세스 키를 내보냅니다.

    # export RGW_ACCESS_KEY_ID="<username>"
  2. 시크릿을 내보냅니다.

    # export RGW_SECRET_ACCESS_KEY="<password>"
  3. 토큰을 내보냅니다. LDAP의 경우 토큰 유형(ttype)으로 ldap 를 사용합니다.

    # radosgw-token --encode --ttype=ldap

    Active Directory의 경우 ad 를 토큰 유형으로 사용합니다.

    # radosgw-token --encode --ttype=ad

    결과는 액세스 토큰인 base-64 인코딩 문자열입니다. 액세스 키 대신 S3 클라이언트에 이 액세스 토큰을 제공합니다. 비밀은 더 이상 필요하지 않습니다.

  4. (선택 사항) S3 클라이언트가 환경 변수를 사용하는 경우 base-64 인코딩 문자열을 RGW_ACCESS_KEY_ID 환경 변수로 내보냅니다.

    # export RGW_ACCESS_KEY_ID="ewogICAgIlJHV19UT0tFTiI6IHsKICAgICAgICAidmVyc2lvbiI6IDEsCiAgICAgICAgInR5cGUiOiAibGRhcCIsCiAgICAgICAgImlkIjogImNlcGgiLAogICAgICAgICJrZXkiOiAiODAwI0dvcmlsbGEiCiAgICB9Cn0K"

5.3.11. S3 클라이언트로 설정 테스트

Python Boto와 같은 Ceph Object Gateway 클라이언트를 선택합니다. RGW_ACCESS_KEY_ID 환경 변수를 사용하도록 구성합니다. 또는 base-64 인코딩 문자열을 복사하여 액세스 키로 지정할 수 있습니다. 그런 다음 Ceph 클라이언트를 실행합니다.

참고

비밀은 더 이상 필요하지 않습니다.

5.4. Active Directory 및 Ceph Object Gateway 구성

다음 단계를 수행하여 Ceph Object Gateway 사용자를 인증하도록 Active Directory 서버를 구성합니다.

5.4.1. Microsoft Active Directory 사용

Ceph Object Gateway LDAP 인증은 Microsoft Active Directory를 포함하여 간단하게 바인딩하도록 구성할 수 있는 모든 LDAP 호환 디렉터리 서비스와 호환됩니다. Active Directory 사용은 Ceph 개체 게이트웨이가 rgw_ldap_binddn 설정에 구성된 사용자로 바인딩되고 LDAP를 사용하여 보안을 보장하기 위해 RH Directory 서버를 사용하는 것과 유사합니다.

Active Directory를 구성하는 프로세스는 기본적으로 LDAP 및 Ceph 개체 게이트웨이 구성과 동일하지만 일부 Windows별 사용이 있을 수 있습니다.

5.4.2. LDAPS용 Active Directory 구성

Active Directory LDAP 서버는 기본적으로 LDAP를 사용하도록 구성되어 있습니다. Windows Server 2012 이상에서는 Active Directory Certificate Services를 사용할 수 있습니다. Active Directory LDAP와 함께 사용할 SSL 인증서를 생성하고 설치하는 방법은 다음 MS TechNet 문서를 참조하십시오. LDAP over SSL(LDAPS) 인증서.

참고

Active Directory 호스트에서 포트 636 이 열려 있는지 확인합니다.

5.4.3. Gateway 사용자 Exists 확인

gateway 사용자를 만들기 전에 Ceph Object Gateway에 사용자가 아직 없는지 확인합니다. 예를 들면 다음과 같습니다.

# radosgw-admin metadata list user

사용자 이름은 이 사용자 목록에 없어야 합니다.

5.4.4. 게이트웨이 사용자 추가

Ceph Object Gateway에 대한 LDAP 사용자를 생성하고 binddn 을 기록합니다. Ceph 개체 게이트웨이는 ceph 사용자를 사용하므로 사용자 이름으로 ceph 를 사용하는 것이 좋습니다. 사용자는 디렉터리를 검색할 수 있는 권한이 있어야 합니다.

사용자 생성이 작동하는지 테스트합니다. 여기서 ceph는 People 및 example.com의 사용자 ID이며, 사용자를 검색할 수 있습니다.

Ceph 개체 게이트웨이는 rgw_ldap_binddn 에 지정된 대로 이 사용자에게 바인딩됩니다.

사용자 생성이 작동하는지 테스트합니다. 여기서 cephPeopleexample.com 의 사용자 ID이며, 사용자를 검색할 수 있습니다.

# ldapsearch -x -D "uid=ceph,ou=People,dc=example,dc=com" -W -H ldaps://example.com -b "ou=People,dc=example,dc=com" -s sub 'uid=ceph'

각 게이트웨이 노드에서 사용자 시크릿에 대한 파일을 만듭니다. 예를 들어 시크릿은 /etc/bindpass 라는 파일에 저장될 수 있습니다. 보안을 위해 이 파일의 소유자를 ceph 사용자 및 그룹으로 변경하여 전역적으로 읽을 수 없는지 확인합니다.

rgw_ldap_secret 옵션을 추가합니다.

구문

ceph config set client.rgw OPTION VALUE

예제

[root@mon ~]# ceph config set client.rgw rgw_ldap_secret /etc/bindpass

마지막으로 업데이트된 구성 파일을 각 Ceph 노드에 복사합니다.

# scp /etc/ceph/ceph.conf <node>:/etc/ceph

5.4.5. Active Directory를 사용하도록 게이트웨이 구성

  1. rgw_ldap_secret 설정을 설정한 후 다음 옵션을 추가합니다.

    구문

    ceph config set client.rgw OPTION VALUE

    예제

    [root@mon ~]# ceph config set client.rgw rgw_ldap_uri ldaps://_FQDN_:636
    [root@mon ~]# ceph config set client.rgw rgw_ldap_binddn "_BINDDN_"
    [root@mon ~]# ceph config set client.rgw rgw_ldap_searchdn "_SEARCHDN_"
    [root@mon ~]# ceph config set client.rgw rgw_ldap_dnattr "cn"
    [root@mon ~]# ceph config set client.rgw rgw_s3_auth_use_ldap true

    rgw_ldap_uri 설정의 경우 FQDN 을 LDAP 서버의 정규화된 도메인 이름으로 바꿉니다. LDAP 서버가 두 개 이상 있는 경우 각 도메인을 지정합니다.

    rgw_ldap_binddn 설정의 경우 BINDDN 을 bind 도메인으로 대체합니다. example.com 도메인과 사용자 및 계정ceph 사용자를 사용하면 다음과 같이 표시되어야 합니다.

    Exaple

    rgw_ldap_binddn "uid=ceph,cn=users,cn=accounts,dc=example,dc=com"

    rgw_ldap_searchdn 설정의 경우 SEARCHDN 을 검색 도메인으로 대체합니다. example.com 의 도메인과 사용자 및 계정 아래에 있는 사용자는 다음과 같이 표시되어야 합니다.

    rgw_ldap_searchdn "cn=users,cn=accounts,dc=example,dc=com"
  2. 업데이트된 구성 파일을 각 Ceph 노드에 복사합니다.

    scp /etc/ceph/ceph.conf <hostname>:/etc/ceph
  3. Ceph 개체 게이트웨이를 다시 시작합니다.

    참고

    NAME 열 아래의 ceph orch ps 명령의 출력을 사용하여 SERVICE_TYPE.ID 정보를 가져옵니다.

    1. 스토리지 클러스터의 개별 노드에서 Ceph Object Gateway를 다시 시작하려면 다음을 수행합니다.

      구문

      systemctl restart ceph-CLUSTER_ID@SERVICE_TYPE.ID.service

      예제

      [root@primary-zone]# systemctl restart ceph-c4b34c6f-8365-11ba-dc31-529020a7702d@rgw.realm.zone.node1.gwasto.service

    2. 스토리지 클러스터의 모든 노드에서 Ceph Object Gateway를 다시 시작하려면 다음을 수행합니다.

      구문

      ceph orch restart SERVICE_TYPE

      예제

      [root@primary-zone]# ceph orch restart rgw

5.4.6. LDAP 서버에 S3 사용자 추가

LDAP 서버의 관리 콘솔에서 S3 클라이언트가 LDAP 사용자 자격 증명을 사용할 수 있도록 하나 이상의 S3 사용자를 생성합니다. S3 클라이언트에 자격 증명을 전달할 때 사용할 사용자 이름과 시크릿을 기록합니다.

5.4.7. LDAP 토큰 내보내기

LDAP를 사용하여 Ceph Object Gateway를 실행하는 경우 액세스 토큰만 있으면 됩니다. 그러나 액세스 토큰은 액세스 키와 시크릿에서 생성됩니다. 액세스 키와 비밀 키를 LDAP 토큰으로 내보냅니다.

  1. 액세스 키를 내보냅니다.

    # export RGW_ACCESS_KEY_ID="<username>"
  2. 시크릿을 내보냅니다.

    # export RGW_SECRET_ACCESS_KEY="<password>"
  3. 토큰을 내보냅니다. LDAP의 경우 토큰 유형(ttype)으로 ldap 를 사용합니다.

    # radosgw-token --encode --ttype=ldap

    Active Directory의 경우 ad 를 토큰 유형으로 사용합니다.

    # radosgw-token --encode --ttype=ad

    결과는 액세스 토큰인 base-64 인코딩 문자열입니다. 액세스 키 대신 S3 클라이언트에 이 액세스 토큰을 제공합니다. 비밀은 더 이상 필요하지 않습니다.

  4. (선택 사항) S3 클라이언트가 환경 변수를 사용하는 경우 base-64 인코딩 문자열을 RGW_ACCESS_KEY_ID 환경 변수로 내보냅니다.

    # export RGW_ACCESS_KEY_ID="ewogICAgIlJHV19UT0tFTiI6IHsKICAgICAgICAidmVyc2lvbiI6IDEsCiAgICAgICAgInR5cGUiOiAibGRhcCIsCiAgICAgICAgImlkIjogImNlcGgiLAogICAgICAgICJrZXkiOiAiODAwI0dvcmlsbGEiCiAgICB9Cn0K"

5.4.8. S3 클라이언트로 설정 테스트

Python Boto와 같은 Ceph Object Gateway 클라이언트를 선택합니다. RGW_ACCESS_KEY_ID 환경 변수를 사용하도록 구성합니다. 또는 base-64 인코딩 문자열을 복사하여 액세스 키로 지정할 수 있습니다. 그런 다음 Ceph 클라이언트를 실행합니다.

참고

비밀은 더 이상 필요하지 않습니다.

5.5. Ceph Object Gateway 및 OpenStack Keystone

스토리지 관리자는 OpenStack의 Keystone 인증 서비스를 사용하여 Ceph Object Gateway를 통해 사용자를 인증할 수 있습니다. Ceph Object Gateway를 구성하려면 Keystone을 먼저 구성해야 합니다. 이렇게 하면 Swift 서비스를 활성화하고 Keystone 서비스가 Ceph Object Gateway를 가리킵니다. 다음으로 Keystone 서비스의 인증 요청을 수락하도록 Ceph Object Gateway를 구성해야 합니다.

5.5.1. 사전 요구 사항

  • 실행 중인 Red Hat OpenStack Platform 환경.
  • 실행 중인 Red Hat Ceph Storage 환경.
  • 실행 중인 Ceph 개체 게이트웨이 환경.

5.5.2. Keystone 인증 및 Ceph Object Gateway

OpenStack Keystone을 사용하여 사용자를 인증하는 조직은 Keystone을 Ceph Object Gateway와 통합할 수 있습니다. Ceph Object Gateway를 사용하면 게이트웨이에서 Keystone 토큰을 수락하고 사용자를 인증하며 해당 Ceph Object Gateway 사용자를 만들 수 있습니다. Keystone에서 토큰을 검증하면 게이트웨이에서 사용자를 인증된 것으로 간주합니다.

혜택

  • Keystone으로 사용자 관리
  • Ceph 개체 게이트웨이의 자동 사용자 생성
  • Ceph 개체 게이트웨이는 Keystone에 폐기된 토큰 목록을 주기적으로 쿼리합니다.

5.5.3. Swift 서비스 생성

Ceph Object Gateway를 구성하기 전에 Swift 서비스가 활성화되고 Ceph Object Gateway를 가리키도록 Keystone을 구성합니다.

사전 요구 사항

  • 실행 중인 Red Hat Ceph Storage 클러스터.
  • Ceph 소프트웨어 리포지토리에 액세스할 수 있습니다.
  • OpenStack 컨트롤러 노드에 대한 루트 수준 액세스.

절차

  1. Swift 서비스를 만듭니다.

    [root@swift~]# openstack service create --name=swift --description="Swift Service" object-store

    서비스를 만들면 서비스 설정이 에코됩니다.

    표 5.1. 예제

    필드현재의

    description

    Swift 서비스

    enabled

    True

    id

    37c4c0e79571404cb4644201a4a6e5ee

    name

    swift

    type

    object-store

5.5.4. Ceph Object Gateway 끝점 설정

Swift 서비스를 만든 후 서비스를 Ceph Object Gateway를 가리킵니다.

사전 요구 사항

  • 실행 중인 Red Hat Ceph Storage 클러스터.
  • Ceph 소프트웨어 리포지토리에 액세스할 수 있습니다.
  • Red Hat OpenStack Platform 13, 15 또는 16 환경에서 실행 중인 Swift 서비스.

절차

  1. Ceph Object Gateway를 가리키는 OpenStack 끝점을 만듭니다.

    구문

    openstack endpoint create --region REGION_NAME swift admin "URL"
    openstack endpoint create --region REGION_NAME swift public "URL"
    openstack endpoint create --region REGION_NAME swift internal "URL"

    REGION_NAME 을 게이트웨이의 영역 그룹 이름 또는 지역 이름의 이름으로 바꿉니다. URL 을 Ceph Object Gateway에 적합한 URL로 바꿉니다.

    예제

    [root@osp ~]# openstack endpoint create --region us-west swift admin "http://radosgw.example.com:8080/swift/v1"
    [root@osp ~]# openstack endpoint create --region us-west swift public "http://radosgw.example.com:8080/swift/v1"
    [root@osp ~]# openstack endpoint create --region us-west swift internal "http://radosgw.example.com:8080/swift/v1"

    필드현재의

    adminURL

    http://radosgw.example.com:8080/swift/v1

    id

    e4249d2b60e44743a67b5e5b38c18dd3

    internalURL

    http://radosgw.example.com:8080/swift/v1

    publicURL

    http://radosgw.example.com:8080/swift/v1

    region

    us-west

    service_id

    37c4c0e79571404cb4644201a4a6e5ee

    service_name

    swift

    service_type

    object-store

    엔드포인트를 설정하면 서비스 엔드포인트 설정이 출력됩니다.

5.5.5. Openstack에서 Ceph Object Gateway 엔드포인트를 사용하고 있는지 확인

Swift 서비스를 만들고 엔드포인트를 설정한 후 엔드포인트를 표시하여 모든 설정이 올바른지 확인합니다.

사전 요구 사항

  • 실행 중인 Red Hat Ceph Storage 클러스터.
  • Ceph 소프트웨어 리포지토리에 액세스할 수 있습니다.

절차

  1. 구성 파일의 설정을 확인합니다.
[root@swift~]# openstack endpoint show object-store

엔드포인트를 표시하면 엔드포인트 설정 및 서비스 설정이 에코됩니다.

표 5.2. 예제

필드현재의

adminURL

http://radosgw.example.com:8080/swift/v1

enabled

True

id

e4249d2b60e44743a67b5e5b38c18dd3

internalURL

http://radosgw.example.com:8080/swift/v1

publicURL

http://radosgw.example.com:8080/swift/v1

region

us-west

service_id

37c4c0e79571404cb4644201a4a6e5ee

service_name

swift

service_type

object-store

5.5.6. Keystone SSL을 사용하도록 Ceph Object Gateway 구성

Keystone에서 Keystone에서 작동하도록 Ceph Object Gateway를 구성하는 OpenSSL 인증서를 변환합니다. Ceph Object Gateway가 OpenStack의 Keystone 인증과 상호 작용하면 Keystone이 자체 서명된 SSL 인증서로 종료됩니다.

사전 요구 사항

  • 실행 중인 Red Hat Ceph Storage 클러스터.
  • Ceph 소프트웨어 리포지토리에 액세스할 수 있습니다.

절차

  1. OpenSSL 인증서를 nss db 형식으로 변환합니다.

    예제

    [root@osp ~]# mkdir /var/ceph/nss
    
    [root@osp ~]# mkdir /var/ceph/nss openssl x509 -in /etc/keystone/ssl/certs/ca.pem -pubkey | \
        certutil -d /var/ceph/nss -A -n ca -t "TCu,Cu,Tuw"
    [root@osp ~]# mkdir /var/ceph/nss openssl x509 -in /etc/keystone/ssl/certs/signing_cert.pem -pubkey | \
        certutil -A -d /var/ceph/nss -n signing_cert -t "P,P,P"

  2. Ceph Object Gateway를 실행하는 노드에 Keystone의 SSL 인증서를 설치합니다. 또는 구성 가능한 rgw_keystone_verify_ssl 설정 값을 false로 설정합니다.

    rgw_keystone_verify_sslfalse 로 설정하면 게이트웨이가 인증서 확인을 시도하지 않습니다.

5.5.7. Keystone 인증을 사용하도록 Ceph Object Gateway 구성

OpenStack의 Keystone 인증을 사용하도록 Red Hat Ceph Storage를 구성합니다.

사전 요구 사항

  • 실행 중인 Red Hat Ceph Storage 클러스터.
  • Ceph 소프트웨어 리포지토리에 액세스할 수 있습니다.
  • 프로덕션 환경에 대한 관리자 권한이 있어야 합니다.

절차

  1. 각 게이트웨이 인스턴스에 대해 다음을 수행합니다.

    1. rgw_s3_auth_use_keystone 옵션을 true로 설정합니다.

      예제

      [root@mon ~]# ceph config set client.rgw rgw_s3_auth_use_keystone true

    2. nss_db_path 설정을 NSS 데이터베이스가 저장된 경로로 설정합니다.

      예제

      [root@mon ~]# ceph config set client.rgw nss_db_path "/var/lib/ceph/radosgw/ceph-rgw.rgw01/nss"

  2. 인증 자격 증명을 제공합니다.

    시스템 관리자가 OpenStack 서비스를 구성하는 방식과 마찬가지로 OpenStack ID API의 Keystone 서비스 테넌트, 사용자 및 암호를 구성할 수 있습니다. 사용자 이름과 암호를 제공하면 rgw_keystone_admin_token 설정에 공유 시크릿이 제공되지 않습니다.

    중요

    Red Hat은 프로덕션 환경에서 관리 토큰으로 인증을 비활성화하는 것이 좋습니다. 서비스 테넌트 자격 증명에는 admin 권한이 있어야 합니다.

    필요한 구성 옵션은 다음과 같습니다.

    구문

    ceph config set client.rgw rgw_keystone_url KEYSTONE_URL:_ADMIN_PORT_
    ceph config set client.rgw rgw_keystone_admin_user KEYSTONE_TENANT_USER_NAME
    ceph config set client.rgw rgw_keystone_admin_password KEYSTONE_TENANT_USER_PASSWORD
    ceph config set client.rgw rgw_keystone_admin_tenant KEYSTONE_TENANT_NAME
    ceph config set client.rgw rgw_keystone_accepted_roles KEYSTONE_ACCEPTED_USER_ROLES
    ceph config set client.rgw rgw_keystone_token_cache_size NUMBER_OF_TOKENS_TO_CACHE
    ceph config set client.rgw rgw_keystone_revocation_interval NUMBER_OF_SECONDS_BEFORE_CHECKING_REVOKED_TICKETS
    ceph config set client.rgw rgw_keystone_make_new_tenants TRUE_FOR_PRIVATE_TENANT_FOR_EACH_NEW_USER

    Ceph Object Gateway 사용자는 Keystone 테넌트에 매핑됩니다. Keystone 사용자는 단일 테넌트가 아닌 다른 역할을 할당합니다. Ceph Object Gateway에서 티켓을 받으면 테넌트와 해당 티켓에 할당된 사용자 역할을 확인하고 구성 가능한 rgw_keystone_accepted_roles 에 따라 요청을 수락하거나 거부합니다.

추가 리소스

5.5.8. Ceph Object Gateway 데몬 다시 시작

Ceph Object Gateway를 다시 시작하여 활성 구성 변경을 수행해야 합니다.

사전 요구 사항

  • 실행 중인 Red Hat Ceph Storage 클러스터.
  • Ceph 소프트웨어 리포지토리에 액세스할 수 있습니다.
  • 프로덕션 환경에 대한 관리자 권한.

절차

  1. Ceph 구성 파일을 저장하고 각 Ceph 노드에 배포한 경우 Ceph Object Gateway 인스턴스를 다시 시작합니다.

    참고

    NAME 열 아래의 ceph orch ps 명령의 출력을 사용하여 SERVICE_TYPE.ID 정보를 가져옵니다.

    1. 스토리지 클러스터의 개별 노드에서 Ceph Object Gateway를 다시 시작하려면 다음을 수행합니다.

      구문

      systemctl restart ceph-CLUSTER_ID@SERVICE_TYPE.ID.service

      예제

      [root@primary-zone]# systemctl restart ceph-c4b34c6f-8365-11ba-dc31-529020a7702d@rgw.realm.zone.node1.gwasto.service

    2. 스토리지 클러스터의 모든 노드에서 Ceph Object Gateway를 다시 시작하려면 다음을 수행합니다.

      구문

      ceph orch restart SERVICE_TYPE

      예제

      [root@primary-zone]# ceph orch restart rgw

6장. 보안

스토리지 관리자는 스토리지 클러스터 환경을 보호하는 것이 중요합니다. Red Hat Ceph Storage는 Ceph Object Gateway 액세스 지점을 보호하기 위한 암호화 및 키 관리를 제공합니다.

6.1. 사전 요구 사항

  • 정상적으로 실행 중인 Red Hat Ceph Storage 클러스터.
  • Ceph Object Gateway 소프트웨어 설치.

6.2. S3 서버 측 암호화

Ceph Object Gateway는 S3 API(애플리케이션 프로그래밍 인터페이스)에 대해 업로드된 오브젝트의 서버 측 암호화를 지원합니다. 서버 측 암호화는 S3 클라이언트가 HTTP를 통해 암호화되지 않은 형태로 데이터를 보내고 Ceph Object Gateway는 해당 데이터를 Red Hat Ceph Storage 클러스터에 암호화된 형식으로 저장함을 의미합니다.

참고

Red Hat은 SLO(Static Large Object) 또는 DLO(Dynamic Large Object)의 S3 객체 암호화를 지원하지 않습니다.

중요

암호화를 사용하려면 클라이언트 요청에서 SSL 연결을 통해 요청을 보내야 합니다. Red Hat은 Ceph Object Gateway에서 SSL을 사용하지 않는 한 클라이언트에서 S3 암호화를 지원하지 않습니다. 그러나 테스트 목적으로 관리자는 ceph 구성 set client.rgw 명령을 사용하여 런타임 시 rgw_crypt_require_ssl 구성 설정을 false 로 설정한 다음 Ceph Object Gateway 인스턴스를 다시 시작하여 테스트 중에 SSL을 비활성화할 수 있습니다.

프로덕션 환경에서는 암호화된 요청을 SSL을 통해 보낼 수 없습니다. 이러한 경우 HTTP를 서버 측 암호화와 함께 사용하여 요청을 보냅니다.

서버 측 암호화를 사용하여 HTTP를 구성하는 방법에 대한 자세한 내용은 아래 추가 리소스 섹션을 참조하십시오.

암호화 키 관리에 대한 두 가지 옵션이 있습니다.

고객 제공 키

고객 제공 키를 사용하는 경우 S3 클라이언트는 암호화된 데이터를 읽거나 쓰기 위한 각 요청과 함께 암호화 키를 전달합니다. 이러한 키를 관리하는 것은 고객의 책임입니다. 고객은 각 오브젝트를 암호화하는 데 사용되는 Ceph 개체 게이트웨이를 기억해야 합니다.

Ceph Object Gateway는 Amazon SSE-C 사양에 따라 S3 API에서 고객 제공 키 동작을 구현합니다.

고객이 키 관리를 처리하고 S3 클라이언트는 Ceph Object Gateway에 키를 전달하므로 Ceph Object Gateway에는 이 암호화 모드를 지원하는 특별한 구성이 필요하지 않습니다.

키 관리 서비스

키 관리 서비스를 사용하는 경우 보안 키 관리 서비스는 키를 저장하고 Ceph Object Gateway는 필요에 따라 데이터를 암호화하거나 암호 해독하기 위한 요청을 제공합니다.

Ceph Object Gateway는 Amazon SSE-KMS 사양에 따라 S3 API에서 키 관리 서비스 동작을 구현합니다.

중요

현재 테스트된 유일한 키 관리 구현은 H¢Corp Vault와 OpenStack Barbican입니다. 그러나 OpenStack Barbican은 기술 프리뷰이며 프로덕션 시스템에서 사용할 수 없습니다.

6.3. 서버 측 암호화 요청

프로덕션 환경에서 클라이언트는 프록시를 통해 Ceph 개체 게이트웨이에 연결하는 경우가 많습니다. 이 프록시는 여러 Ceph Object Gateway에 연결되므로 로드 밸런서라고 합니다. 클라이언트가 Ceph Object Gateway에 요청을 보내면 로드 밸런서에서 이러한 요청을 여러 Ceph Object Gateway에 라우팅하여 워크로드를 배포합니다.

이 유형의 구성에서는 로드 밸런서 및 여러 Ceph 개체 게이트웨이 간에 SSL 종료가 발생할 수 있습니다. HTTP만 사용하는 통신이 발생합니다. 서버 측 암호화 요청을 수락하도록 Ceph Object Gateways를 설정하려면 서버 측 암호화 구성을 참조하십시오.

6.4. 서버 측 암호화 구성

스토리지 관리자는 HTTP를 사용하여 암호화된 요청을 SSL을 통해 보낼 수 없는 경우 HTTP를 사용하여 Ceph Object Gateway에 요청을 보내도록 서버 측 암호화를 설정할 수 있습니다.

이 절차에서는 HAProxy를 프록시 및 로드 밸런서로 사용합니다.

사전 요구 사항

  • 스토리지 클러스터의 모든 노드에 대한 루트 수준 액세스.
  • 실행 중인 Red Hat Ceph Storage 클러스터.
  • Ceph Object Gateway 소프트웨어 설치.
  • HAProxy 소프트웨어 설치.

절차

  1. haproxy.cfg 파일을 편집합니다.

    예제

    frontend http_web *:80
        mode http
        default_backend rgw
    
    frontend rgw­-https
      bind *:443 ssl crt /etc/ssl/private/example.com.pem
      default_backend rgw
    
    backend rgw
        balance roundrobin
        mode http
        server  rgw1 10.0.0.71:8080 check
        server  rgw2 10.0.0.80:8080 check

  2. http 프런트엔드에 대한 액세스를 허용하는 행을 주석 처리하고 대신 https 프런트엔드를 사용하도록 HAProxy에 지시하는 지침을 추가합니다.

    예제

    #     frontend http_web *:80
    #     mode http
    #     default_backend rgw
    
    frontend rgw­-https
      bind *:443 ssl crt /etc/ssl/private/example.com.pem
      http-request set-header X-Forwarded-Proto https if { ssl_fc }
      http-request set-header X-Forwarded-Proto https
    # here we set the incoming HTTPS port on the load balancer (eg : 443)
      http-request set-header X-Forwarded-Port 443
      default_backend rgw
    
    backend rgw
        balance roundrobin
        mode http
        server  rgw1 10.0.0.71:8080 check
        server  rgw2 10.0.0.80:8080 check

  3. rgw_trust_forwarded_https 옵션을 true로 설정합니다.

    예제

    [root@mon ~]# ceph config set client.rgw rgw_trust_forwarded_https true

  4. HAProxy를 활성화하고 시작합니다.

    [root@haproxy]# systemctl enable haproxy
    [root@haproxy]# systemctl start haproxy

6.5. H¢Corp Vault

스토리지 관리자는 Ceph Object Gateway와 함께 사용할 수 있도록 키, 암호 및 인증서를 HseaCorp Vault에 안전하게 저장할 수 있습니다. H¢Corp Vault는 Ceph 개체 게이트웨이에서 사용하는 서버 측 암호화에 대해 안전한 키 관리 서비스를 제공합니다.

Ceph Vault 통합 다이어그램

기본 워크플로우:

  1. 클라이언트는 오브젝트의 키 ID를 기반으로 Vault에서 비밀 키 생성을 요청합니다.
  2. 클라이언트는 오브젝트의 키 ID가 있는 오브젝트를 Ceph Object Gateway에 업로드합니다.
  3. 그러면 Ceph Object Gateway에서 Vault에서 새로 생성된 비밀 키를 요청합니다.
  4. Vault는 비밀 키를 Ceph 개체 게이트웨이에 반환하여 요청에 응답합니다.
  5. 이제 Ceph Object Gateway에서 새 비밀 키를 사용하여 오브젝트를 암호화할 수 있습니다.
  6. 암호화가 완료되면 오브젝트가 Ceph OSD에 저장됩니다.
중요

Red Hat은 기술 파트너와 협력하여 이 문서를 고객에게 서비스로 제공하고 있습니다. 그러나 Red Hat은 이 제품에 대한 지원을 제공하지 않습니다. 이 제품에 대한 기술 지원이 필요한 경우 H¢corp에 문의하십시오.

6.5.1. 사전 요구 사항

  • 실행 중인 Red Hat Ceph Storage 클러스터.
  • Ceph Object Gateway 소프트웨어 설치.
  • HCorp Vault 소프트웨어 설치.

6.5.2. Vault 용 비밀 엔진

HseaCorp Vault는 데이터를 생성, 저장 또는 암호화할 수 있는 여러 가지 비밀 엔진을 제공합니다. API(애플리케이션 프로그래밍 인터페이스)는 해당 데이터에 대한 작업을 요청하는 시크릿 엔진에 데이터 호출을 전송하고 시크릿 엔진은 해당 작업 요청의 결과를 반환합니다.

Ceph Object Gateway는 H¢Corp Vault 비밀 엔진을 2개 지원합니다.

  • 키/값 버전 2
  • 전환

키/값 버전 2

키/값 시크릿 엔진은 Vault 내에 디스크의 임의 시크릿을 저장합니다. kv 엔진 버전 2를 사용하면 키에 구성 가능한 개수의 버전이 있을 수 있습니다. 기본 버전 수는 10입니다. 버전을 삭제하면 기본 데이터가 삭제되지 않지만 데이터가 삭제된 것으로 표시되므로 삭제된 버전을 삭제하지 않을 수 있습니다. API 엔드포인트 또는 destroy 명령을 사용하여 버전의 데이터를 영구적으로 제거할 수 있습니다. 키의 모든 버전 및 메타데이터를 삭제하려면 metadata 명령 또는 API 엔드포인트를 사용할 수 있습니다. 키 이름은 문자열이어야 하며, 명령줄 인터페이스를 사용할 때 엔진은 문자열이 아닌 값을 문자열로 변환합니다. 문자열이 아닌 값을 보존하려면 JSON 파일을 제공하거나 HTTP API(애플리케이션 프로그래밍 인터페이스)를 사용합니다.

참고

ACL(액세스 제어 목록) 정책의 경우 Key/Value secret 엔진은 생성과 업데이트 기능 간의 차이점을 인식합니다.

전환

Transit 비밀 엔진은 전송 중인 데이터에서 암호화 기능을 수행합니다. Transit 비밀 엔진은 해시를 생성할 수 있으며 임의 바이트의 소스일 수 있으며 데이터를 서명하고 확인할 수도 있습니다. Vault는 Transit 비밀 엔진을 사용할 때 데이터를 저장하지 않습니다. Transit 비밀 엔진은 동일한 키를 여러 용도로 사용할 수 있도록 함으로써 키 파생을 지원합니다. 또한 전송 비밀 엔진은 키 버전 지정을 지원합니다. Transit 비밀 엔진은 다음과 같은 주요 유형을 지원합니다.

aes128-gcm96
128비트 AES 키와 96비트 nonce를 사용하는 AES-GCM; 암호화, 암호 해독, 키 파생 및 통합 암호화 지원
aes256-gcm96
256비트 AES 키와 96비트 nonce를 사용하는 AES-GCM; 암호화, 암호 해독, 키 파생 및 통합 암호화(기본값) 지원
chacha20-poly1305
256비트 키가 있는 ChaCha20-Poly1305, 암호화, 암호 해독, 키 파생 및 통합된 암호화 지원
ed25519
Ed25519; 서명, 서명 확인 및 키 파생 지원
ecdsa-p256
곡선 P-256을 사용하는 ECDSA; 서명 및 서명 확인 지원
ecdsa-p384
곡선 P-384를 사용하는 ECDSA; 서명 및 서명 확인 지원
ecdsa-p521
곡선 P-521을 사용하는 ECDSA, 서명 및 서명 확인 지원
rsa-2048
2048비트 RSA 키. 암호화, 암호 해독, 서명 및 서명 확인 지원
rsa-3072
3072비트 RSA 키; 암호화, 암호 해독, 서명 및 서명 확인 지원
rsa-4096
4096비트 RSA 키; 암호화, 암호 해독, 서명 및 서명 확인 지원

추가 리소스

  • 자세한 내용은 Vault의 프로젝트 사이트에 대한 KV Secrets Engine 설명서를 참조하십시오.
  • 자세한 내용은 Vault의 프로젝트 사이트에 대한 Transit Secrets Engine 설명서를 참조하십시오.

6.5.3. Vault를 위한 인증

H¢Corp Vault는 여러 유형의 인증 메커니즘을 지원합니다. Ceph Object Gateway는 현재 Vault 에이전트 방법을 지원합니다. Ceph Object Gateway는 rgw_crypt_vault_authrgw_crypt_vault_addr 옵션을 사용하여 H¢Corp Vault 사용을 구성합니다.

중요

Red Hat은 Vault 에이전트를 컨테이너의 인증 방법으로 지원하며 컨테이너에서 토큰 인증 사용은 지원되지 않습니다.

Vault 에이전트

Vault 에이전트는 클라이언트 노드에서 실행되고 토큰 갱신과 함께 클라이언트 측 캐싱을 제공하는 데몬입니다. Vault 에이전트는 일반적으로 Ceph Object Gateway 노드에서 실행됩니다. Vault 에이전트를 실행하고 토큰 파일을 새로 고칩니다. 이 모드에서 Vault 에이전트를 사용하는 경우 파일 시스템 권한을 사용하여 토큰 사용에 대한 액세스 권한을 제한할 수 있습니다. 또한 Vault 에이전트는 필요한 경우 Vault에서 토큰을 추가하고 실제 서버로 전달하기 전에 토큰을 추가합니다. Vault 에이전트는 Filesystem에 토큰을 저장할 때와 마찬가지로 토큰 갱신을 계속 처리할 수 있습니다. Vault 에이전트는 Ceph Object Gateway가 Vault 에이전트와 연결하는 데 사용하는 네트워크를 보호해야 합니다. 예를 들어 Vault 에이전트는 localhost만 수신 대기합니다.

추가 리소스

6.5.4. Vault용 네임 스페이스

H¢Corp Vault를 엔터프라이즈 서비스로 사용하면 조직 내에서 팀에서 사용할 수 있는 격리된 네임스페이스에 대한 중앙 집중식 관리가 제공됩니다. 이러한 분리된 네임스페이스 환경을 테넌트 라고 하며, 조직 내 팀은 이러한 테넌트 를 활용하여 정책, 비밀 및 ID를 다른 팀으로부터 격리할 수 있습니다. Vault의 네임스페이스 기능은 단일 인프라 내에서 보안 멀티 테넌시를 지원하는 데 도움이 됩니다.

추가 리소스

6.5.5. 전송 엔진 호환성 지원

Transit 엔진을 단순한 키 저장소로 사용한 이전 버전의 Ceph에 대한 호환성 지원이 있습니다. Transit 엔진에서 compat 옵션을 사용하여 호환성 지원을 구성할 수 있습니다. 다음 명령을 사용하여 이전 지원을 비활성화할 수 있습니다.

예제

[root@vault ~]# ceph config set client.rgw rgw_crypt_vault_secret_engine transit compat=0

참고

이는 향후 버전의 기본값이며 새 설치에 현재 버전을 사용할 수 있습니다.

현재 버전의 일반 기본값은 다음과 같습니다.

예제

[root@vault ~]# ceph config set client.rgw rgw_crypt_vault_secret_engine transit compat=1

이를 통해 새로 생성된 개체에 대해 새 엔진을 사용할 수 있으며 이전 엔진을 이전 개체에 계속 사용할 수 있습니다. 오래된 개체와 새 개체에 액세스하려면 Vault 토큰에 이전 및 새 전송 정책이 모두 있어야 합니다.

다음 명령을 사용하여 이전 엔진만 강제로 사용할 수 있습니다.

예제

[root@vault ~]# ceph config set client.rgw rgw_crypt_vault_secret_engine transit compat=2

Vault가 내보내기/암호화-키로 종료되면 기본적으로 이 모드가 선택됩니다.

중요

client.rgw 옵션을 구성한 후 새 값을 적용하려면 Ceph Object Gateway 데몬을 다시 시작해야 합니다.

추가 리소스

6.5.6. Vault에 대한 토큰 정책 생성

토큰 정책은 모든 Vault 토큰에 있는 권한을 지정합니다. 하나의 토큰에 여러 정책이 있을 수 있습니다. 구성에 필요한 정책을 사용해야 합니다.

사전 요구 사항

  • 실행 중인 Red Hat Ceph Storage 클러스터.
  • HCorp Vault 소프트웨어 설치.
  • HseaCorp Vault 노드에 대한 루트 수준 액세스.

절차

  1. 토큰 정책을 생성합니다.

    1. 키/값 시크릿 엔진의 경우:

      예제

      [root@vault ~]# vault policy write rgw-kv-policy -<<EOF
       path "secret/data/*" {
         capabilities = ["read"]
       }
      EOF

    2. Transit 엔진의 경우:

      예제

      [root@vault ~]# vault policy write rgw-transit-policy -<<EOF
        path "transit/keys/*" {
          capabilities = [ "create", "update" ]
          denied_parameters = {"exportable" = [], "allow_plaintext_backup" = [] }
        }
      
        path "transit/keys/*" {
          capabilities = ["read", "delete"]
        }
      
        path "transit/keys/" {
          capabilities = ["list"]
        }
      
        path "transit/keys/+/rotate" {
          capabilities = [ "update" ]
        }
      
        path "transit/*" {
          capabilities = [ "update" ]
        }
      EOF

      참고

      이전 버전의 Ceph에서 Transit 비밀 엔진을 사용한 경우 토큰 정책은 다음과 같습니다.

      예제

      [root@vault ~]# vault policy write old-rgw-transit-policy -<<EOF
        path "transit/export/encryption-key/*" {
          capabilities = ["read"]
        }
      EOF

6.5.7. Vault를 사용하도록 Ceph Object Gateway 구성

H¢Corp Vault를 사용하도록 Ceph Object Gateway를 구성하려면 암호화 키 저장소로 설정해야 합니다. 현재 Ceph Object Gateway는 두 가지 비밀 엔진과 두 가지 다른 인증 방법을 지원합니다.

사전 요구 사항

  • 실행 중인 Red Hat Ceph Storage 클러스터.
  • Ceph Object Gateway 소프트웨어 설치.
  • Ceph Object Gateway 노드에 대한 루트 수준 액세스.

절차

  1. ceph config set client.rgw OPTION VALUE 명령을 사용하여 암호화 키 저장소로 Vault를 활성화합니다.

    구문

    ceph config set client.rgw rgw_crypt_s3_kms_backend vault

  2. 다음 옵션과 값을 추가합니다.

    구문

    ceph config set client.rgw rgw_crypt_vault_auth agent
    ceph config set client.rgw rgw_crypt_vault_addr http://VAULT_SERVER:8100

  3. 사용 사례에 따라 정책을 사용자 지정합니다.
  4. role-id를 가져옵니다.

    예제

    [root@rgw ~]# vault read auth/approle/role/rgw-ap/role-id -format=json | \ jq -r .data.role_id > _PATH_TO_FILE_

  5. secret-id를 가져옵니다.

    예제

    [root@rgw ~]# vault read auth/approle/role/rgw-ap/role-id -format=json | \ jq -r .data.secret_id > _PATH_TO_FILE_

  6. Vault 에이전트에 대한 구성을 생성합니다.

    예제

    pid_file = "/run/kv-vault-agent-pid"
    auto_auth {
      method "AppRole" {
        mount_path = "auth/approle"
        config = {
          role_id_file_path ="/root/vault_configs/kv-agent-role-id"
          secret_id_file_path ="/root/vault_configs/kv-agent-secret-id"
          remove_secret_id_file_after_reading ="false"
        }
      }
    }
    cache {
      use_auto_auth_token = true
    }
    listener "tcp" {
      address = "127.0.0.1:8100"
      tls_disable = true
    }
    vault {
      address = "http://10.8.128.9:8200"
    }

  7. systemctl을 사용하여 영구 데몬을 실행합니다.

    예제

    [root@rgw ~]# /usr/local/bin/vault agent -config=/usr/local/etc/vault/rgw-agent.hcl

  8. Vault 에이전트가 실행될 때 토큰 파일은 유효한 토큰으로 채워집니다.
  9. Vault 비밀 엔진(키/값 또는 Transit)을 선택합니다.

    1. Key/Value 를 사용하는 경우 다음 행을 추가합니다.

      예제

      [root@rgw ~]# ceph config set client.rgw rgw_crypt_vault_secret_engine kv

    2. Transit 을 사용하는 경우 다음 행을 추가합니다.

      예제

      [root@rgw ~]# ceph config set client.rgw rgw_crypt_vault_secret_engine transit

  10. ceph config set client.rgw OPTION VALUE 명령을 사용하여 Vault 네임스페이스를 설정하여 암호화 키를 검색합니다.

    예제

    [root@rgw ~]# ceph config set client.rgw rgw_crypt_vault_namespace testnamespace1

  11. 경로 접두사를 설정하여 Ceph Object Gateway에서 Vault에서 암호화 키를 검색하는 위치를 제한합니다.

    예제

    [root@rgw ~]# ceph config set client.rgw rgw_crypt_vault_prefix /v1/secret/data

    1. 내보낼 수 있는 전송 키의 경우 다음과 같이 접두사 경로를 설정합니다.

      예제

      [root@rgw ~]# ceph config set client.rgw rgw_crypt_vault_prefix /v1/transit/export/encryption-key

      Vault 서버의 도메인 이름이 vault-server 라고 가정하면 Ceph Object Gateway는 다음 URL에서 암호화된 전송 키를 가져옵니다.

      예제

      http://vault-server:8200/v1/transit/export/encryption-key

  12. Ceph Object Gateway 데몬을 다시 시작합니다.

    1. 스토리지 클러스터의 개별 노드에서 Ceph Object Gateway를 다시 시작하려면 다음을 수행합니다.

      구문

      systemctl restart ceph-CLUSTER_ID@SERVICE_TYPE.ID.service

      예제

      [root@rgw]# systemctl restart ceph-c4b34c6f-8365-11ba-dc31-529020a7702d@rgw.realm.zone.node1.gwasto.service

    2. 스토리지 클러스터의 모든 노드에서 Ceph Object Gateway를 다시 시작하려면 다음을 수행합니다.

      구문

      ceph orch restart SERVICE_TYPE

      예제

      [root@rgw]# ceph orch restart rgw

추가 리소스

  • 자세한 내용은 Red Hat Ceph Storage Object Gateway Configuration and Administration GuideVault용 Secret Engine 섹션을 참조하십시오.
  • 자세한 내용은 Red Hat Ceph Storage Object Gateway Configuration and Administration GuideVault에 대한 인증 섹션을 참조하십시오.

6.5.8. kv 엔진을 사용하여 키 생성

Ceph Object Gateway에서 사용할 키를 만들 수 있도록 HCorp Vault Key/Value Secret Engine(kv)을 구성합니다. 시크릿은 kv 시크릿 엔진에 키-값 쌍으로 저장됩니다.

중요

서버 측 암호화 키는 256비트이고 base64 를 사용하여 인코딩되어야 합니다.

사전 요구 사항

  • 실행 중인 Red Hat Ceph Storage 클러스터.
  • HCorp Vault 소프트웨어 설치.
  • HseaCorp Vault 노드에 대한 루트 수준 액세스.

절차

  1. 키/값 버전 2 시크릿 엔진을 활성화합니다.

    예제

    vault secrets enable -path secret kv-v2

  2. 새 키를 생성합니다.

    구문

    vault kv put secret/PROJECT_NAME/BUCKET_NAME key=$(openssl rand -base64 32)

    예제

    [root@vault ~]# vault kv put secret/myproject/mybucketkey key=$(openssl rand -base64 32)
    
    ====== Metadata ======
    Key              Value
    ---              -----
    created_time     2020-02-21T17:01:09.095824999Z
    deletion_time    n/a
    destroyed        false
    version          1

6.5.9. 전송 엔진을 사용하여 키 만들기

Ceph Object Gateway에서 사용할 키를 만들 수 있도록 HCorp Vault Transit 비밀 엔진(전송)을 구성합니다. Ceph Object Gateway로 서버 측 암호화에 사용하려면 Transit 시크릿 엔진을 사용하여 키를 생성할 수 있어야 합니다.

사전 요구 사항

  • 실행 중인 Red Hat Ceph Storage 클러스터.
  • HCorp Vault 소프트웨어 설치.
  • HseaCorp Vault 노드에 대한 루트 수준 액세스.

절차

  1. Transit 비밀 엔진을 활성화합니다.

    [root@vault ~]# vault secrets enable transit
  2. 내보내기 가능한 새 키를 생성합니다.

    구문

    vault write -f transit/keys/BUCKET_NAME exportable=true

    예제

    [root@vault ~]# vault write -f transit/keys/mybucketkey exportable=true

    참고

    기본적으로 위의 명령은 aes256-gcm96 유형 키를 생성합니다.

  3. 키 생성을 확인합니다.

    구문

    vault read transit/export/encryption-key/BUCKET_NAME/VERSION_NUMBER

    예제

    [root@vault ~]# vault read transit/export/encryption-key/mybucketkey/1
    
    Key     Value
    ---     -----
    keys    map[1:-gbTI9lNpqv/V/2lDcmH2Nq1xKn6FPDWarCmFM2aNsQ=]
    name    mybucketkey
    type    aes256-gcm96

    참고

    키 버전을 포함한 전체 키 경로를 제공해야 합니다.

6.5.10. AWS 및 Vault를 사용하여 오브젝트 업로드

Ceph Object Gateway에 오브젝트를 업로드할 때 Ceph Object Gateway는 Vault에서 키를 가져온 다음 오브젝트를 암호화하여 버킷에 저장합니다. 오브젝트 다운로드를 요청하면 Ceph Object Gateway에서 Vault에서 해당 키를 자동으로 검색하고 개체의 암호를 해독합니다. 오브젝트를 업로드하기 위해 Ceph 개체 게이트웨이는 Vault에서 키를 가져온 다음 오브젝트를 암호화하여 버킷에 저장합니다. Ceph Object Gateway는 Vault에서 해당 키를 검색하고 오브젝트 다운로드 요청 시 오브젝트를 암호 해독합니다.

참고

URL은 rgw_crypt_vault_addr 옵션으로 설정된 기본 주소 및 rgw_ crypt_vault_prefix 옵션으로 설정된 경로 접두사를 사용하여 구성됩니다.

사전 요구 사항

  • 실행 중인 Red Hat Ceph Storage 클러스터.
  • Ceph Object Gateway 소프트웨어 설치.
  • HCorp Vault 소프트웨어 설치.
  • Ceph Object Gateway 클라이언트 노드에 액세스합니다.
  • AWS(Amazon Web Services) 액세스.

절차

  1. AWS 명령줄 클라이언트를 사용하여 오브젝트를 업로드하고 요청에 SSE(Secure 사이드 암호화) 키 ID를 제공합니다.

    1. 키/값 시크릿 엔진의 경우:

      예제

      [user@client ~]$ aws --endpoint=http://radosgw:8000 s3 cp plaintext.txt s3://mybucket/encrypted.txt --sse=aws:kms --sse-kms-key-id myproject/mybucketkey

      참고

      이 예제에서 Ceph Object Gateway는 http://vault-server:8200/v1/secret/data/myproject/mybucketkey에서 시크릿을 가져옵니다.

    2. Transit 엔진의 경우:

      예제

      [user@client ~]$ aws --endpoint=http://radosgw:8000 s3 cp plaintext.txt s3://mybucket/encrypted.txt --sse=aws:kms --sse-kms-key-id mybucketkey

참고

이 예제에서 Ceph Object Gateway는 http://vaultserver:8200/v1/transit/mybucketkey에서 시크릿을 가져옵니다.

6.5.11. 추가 리소스

6.6. Ceph Object Gateway 및 다단계 인증

스토리지 관리자는 Ceph Object Gateway 사용자에 대해 시간 기반 TOTP(한 번 암호) 토큰을 관리할 수 있습니다.

6.6.1. 다단계 인증

버킷이 오브젝트 버전 지정에 대해 구성되면 개발자가 삭제 요청에 대해 MFA(다중 인증)를 요구하도록 버킷을 선택적으로 구성할 수 있습니다. MFA를 사용하면 시간 기반 TOTP(한 번 암호) 토큰이 x-amz-mfa 헤더에 키로 전달됩니다. 토큰은 Google Authenticator와 같은 가상 MFA 장치 또는 Gemalto에서 제공하는 것과 같은 하드웨어 MFA 장치로 생성됩니다.

radosgw-admin 을 사용하여 시간 기반 암호 토큰을 사용자에게 할당합니다. 시크릿 시드와 직렬 ID를 설정해야 합니다. radosgw-admin 을 사용하여 토큰을 나열, 제거 및 재동기화할 수도 있습니다.

중요

MFA ID는 사용자 메타데이터에 설정되는 반면 실제 MFA 암호 구성은 로컬 영역의 OSD에 있으므로 다중 사이트 환경에서 다른 영역에 다른 토큰을 사용하는 것이 좋습니다.

표 6.1. 용어

용어설명

TOTP

시간 기반 1회 암호.

토큰 직렬

TOTP 토큰의 ID를 나타내는 문자열입니다.

토큰 시드

TOTP를 계산하는 데 사용되는 시크릿 시드입니다. 16진수 또는 base32일 수 있습니다.

TOTP 초

TOTP 생성에 사용되는 시간 확인.

TOTP 창

토큰을 검증할 때 현재 토큰 전후에 확인되는 TOTP 토큰 수입니다.

TOTP PIN

특정 시간에 TOTP 토큰의 유효한 값입니다.

6.6.2. 다단계 인증을 위한 시드 생성

MFA(다중 인증)를 설정하려면 일회성 암호 생성기 및 백엔드 MFA 시스템에서 사용할 비밀 시드를 생성해야 합니다.

사전 요구 사항

  • Linux 시스템.
  • 명령줄 쉘에 대한 액세스.

절차

  1. urandom Linux 장치 파일에서 30자 시드를 생성하고 쉘 변수 SEED 에 저장합니다.

    예제

    [user@host ~]$ SEED=$(head -10 /dev/urandom | sha512sum | cut -b 1-30)

  2. SEED 변수에서 echo를 실행하여 시드를 출력합니다.

    예제

    [user@host ~]$ echo $SEED
    492dedb20cf51d1405ef6a1316017e

    동일한 시드를 사용하도록 일회성 암호 생성기 및 백엔드 MFA 시스템을 구성합니다.

추가 리소스

6.6.3. 새 다단계 인증 TOTP 토큰 생성

새 MFA(다중 인증) 시간 기반 TOTP(한 번 암호) 토큰을 만듭니다.

사전 요구 사항

  • 실행 중인 Red Hat Ceph Storage 클러스터.
  • Ceph Object Gateway가 설치되어 있습니다.
  • Ceph 모니터 노드에서 root 액세스 권한이 있습니다.
  • 일회성 암호 생성기 및 Ceph Object Gateway MFA의 시크릿 시드가 생성되었습니다.

절차

  1. 새 MFA TOTP 토큰을 생성합니다.

    구문

    radosgw-admin mfa create --uid=USERID --totp-serial=SERIAL --totp-seed=SEED --totp-seed-type=SEED_TYPE --totp-seconds=TOTP_SECONDS --totp-window=TOTP_WINDOW

    USERID 를 사용자 이름으로 설정하여 에서 MFA를 설정하고, SERIAL 을 TOTP 토큰의 ID를 나타내는 문자열로 설정하고, SEED 를 TOTP 계산에 사용되는 16진수 또는 base32 값으로 설정합니다. 다음 설정은 선택 사항입니다. SEED_TYPE16진수 또는 base32 로 설정하고 TOTP_SECONDS 를 초 단위로 설정하거나 TOTP_WINDOW 를 TOTP 토큰 수로 설정하여 토큰을 검증할 때 현재 토큰을 확인할 수 있습니다.

    예제

    [root@mon ~]# radosgw-admin mfa create --uid=johndoe --totp-serial=MFAtest --totp-seed=492dedb20cf51d1405ef6a1316017e

추가 리소스

6.6.4. 다단계 인증 TOTP 토큰 테스트

MFA(다중 인증) 시간 기반 TOTP(한 번 암호) 토큰을 테스트합니다.

사전 요구 사항

  • 실행 중인 Red Hat Ceph Storage 클러스터.
  • Ceph Object Gateway가 설치되어 있습니다.
  • Ceph 모니터 노드에서 root 액세스 권한이 있습니다.
  • MFA TOTP 토큰은 radosgw-admin mfa create를 사용하여 생성되었습니다.

절차

  1. TOTP 토큰 PIN을 테스트하여 TOTP가 올바르게 작동하는지 확인합니다.

    구문

    radosgw-admin mfa check --uid=USERID --totp-serial=SERIAL --totp-pin=PIN

    USERID 를 사용자 이름 MFA로 설정하고, SERIAL 을 TOTP 토큰의 ID를 나타내는 문자열로 설정하고, 일회성 암호 생성기에서 PIN을 최신 PIN으로 설정합니다.

    예제

    [root@mon ~] # radosgw-admin mfa check  --uid=johndoe --totp-serial=MFAtest --totp-pin=870305
    ok

    PIN을 처음 테스트한 경우 실패할 수 있습니다. 실패하면 토큰을 다시 동기화합니다. Red Hat Ceph Storage 개체 게이트웨이 구성 및 관리 가이드에서 다단계 인증 토큰 다시 동기화 를 참조하십시오.

추가 리소스

6.6.5. 다단계 인증 TOTP 토큰 다시 동기화

MFA(다중 인증) 시간 기반 암호 토큰을 다시 동기화합니다.

사전 요구 사항

  • 실행 중인 Red Hat Ceph Storage 클러스터.
  • Ceph Object Gateway가 설치되어 있습니다.
  • Ceph 모니터 노드에서 root 액세스 권한이 있습니다.
  • MFA TOTP 토큰은 radosgw-admin mfa create를 사용하여 생성되었습니다.

절차

  1. 시간 차이 또는 실패한 검사의 경우 다단계 인증 TOTP 토큰을 다시 동기화합니다.

    이를 위해서는 두 개의 연속된 고정, 즉 이전의 고정과 현재 고정을 전달해야 합니다.

    구문

    radosgw-admin mfa resync --uid=USERID --totp-serial=SERIAL --totp-pin=PREVIOUS_PIN --totp=pin=CURRENT_PIN

    USERID 를 사용자 이름 MFA로 설정하고, SERIAL 을 TOTP 토큰의 ID를 나타내는 문자열로 설정하고, PREVIOUS_PIN 을 사용자의 이전 PIN으로 설정하고, CURRENT_PIN 을 사용자의 현재 PIN으로 설정합니다.

    예제

    radosgw-admin mfa resync --uid=johndoe --totp-serial=MFAtest --totp-pin=802017 --totp-pin=439996

  2. 새 PIN을 테스트하여 토큰이 다시 동기화되었는지 확인합니다.

    구문

    radosgw-admin mfa check --uid=USERID --totp-serial=SERIAL --totp-pin=PIN

    USERID 를 사용자 이름 MFA로 설정하고, SERIAL 을 TOTP 토큰의 ID를 나타내는 문자열로 설정하고 PIN 을 사용자의 PIN으로 설정합니다.

    예제

    [root@mon ~]# radosgw-admin mfa check  --uid=johndoe --totp-serial=MFAtest --totp-pin=870305
    ok

추가 리소스

6.6.6. 다단계 인증 TOTP 토큰 나열

특정 사용자가 보유한 모든 MFA(다중 인증) 시간 기반 TOTP(한 번 암호) 토큰을 나열합니다.

사전 요구 사항

  • 실행 중인 Red Hat Ceph Storage 클러스터.
  • Ceph Object Gateway가 설치되어 있습니다.
  • Ceph 모니터 노드에서 root 액세스 권한이 있습니다.
  • MFA TOTP 토큰은 radosgw-admin mfa create를 사용하여 생성되었습니다.

절차

  1. MFA TOTP 토큰을 나열합니다.

    구문

    radosgw-admin mfa list --uid=USERID

    USERID 를 사용자 이름 MFA로 설정합니다.

    예제

    [root@mon ~]# radosgw-admin mfa list --uid=johndoe
    {
        "entries": [
            {
                "type": 2,
                "id": "MFAtest",
                "seed": "492dedb20cf51d1405ef6a1316017e",
                "seed_type": "hex",
                "time_ofs": 0,
                "step_size": 30,
                "window": 2
            }
        ]
    }

추가 리소스

6.6.7. 다단계 인증 TOTP 토큰 표시

직렬를 지정하여 특정 MFA(다중 인증) 시간 기반 일회성 암호(TOTP) 토큰을 표시합니다.

사전 요구 사항

  • 실행 중인 Red Hat Ceph Storage 클러스터.
  • Ceph Object Gateway가 설치되어 있습니다.
  • Ceph 모니터 노드에서 root 액세스 권한이 있습니다.
  • MFA TOTP 토큰은 radosgw-admin mfa create를 사용하여 생성되었습니다.

절차

  1. MFA TOTP 토큰을 표시합니다.

    구문

    radosgw-admin mfa get --uid=USERID --totp-serial=SERIAL

    USERID 를 사용자 이름 MFA로 설정하고 SERIAL 을 TOTP 토큰의 ID를 나타내는 문자열로 설정합니다.

추가 리소스

6.6.8. 다단계 인증 TOTP 토큰 삭제

MFA(다중 인증) 시간 기반 TOTP(한 번 암호) 토큰을 삭제합니다.

사전 요구 사항

  • 실행 중인 Red Hat Ceph Storage 클러스터.
  • Ceph Object Gateway가 설치되어 있습니다.
  • Ceph 모니터 노드에서 root 액세스 권한이 있습니다.
  • MFA TOTP 토큰은 radosgw-admin mfa create를 사용하여 생성되었습니다.

절차

  1. MFA TOTP 토큰을 삭제합니다.

    구문

    radosgw-admin mfa remove --uid=USERID --totp-serial=SERIAL

    USERID 를 사용자 이름 MFA로 설정하고 SERIAL 을 TOTP 토큰의 ID를 나타내는 문자열로 설정합니다.

    예제

    [root@mon ~]# radosgw-admin mfa remove --uid=johndoe --totp-serial=MFAtest

  2. MFA TOTP 토큰이 삭제되었는지 확인합니다.

    구문

    radosgw-admin mfa get --uid=_USERID_ --totp-serial=_SERIAL_

    USERID 를 사용자 이름 MFA로 설정하고 SERIAL 을 TOTP 토큰의 ID를 나타내는 문자열로 설정합니다.

    예제

    [root@mon ~]# radosgw-admin mfa get --uid=johndoe --totp-serial=MFAtest
    MFA serial id not found

추가 리소스

7장. 관리

스토리지 관리자는 radosgw-admin CLI(명령줄 인터페이스)를 사용하거나 Red Hat Ceph Storage 대시보드를 사용하여 Ceph Object Gateway를 관리할 수 있습니다.

참고

Red Hat Ceph Storage 대시보드에서 Ceph Object Gateway 기능을 일부 사용할 수 있는 것은 아닙니다.

7.1. 사전 요구 사항

  • 정상적으로 실행 중인 Red Hat Ceph Storage 클러스터.
  • Ceph Object Gateway 소프트웨어 설치.

7.2. 스토리지 정책 생성

Ceph 개체 게이트웨이는 배치 대상을 식별하고 배치 대상과 연결된 풀에 버킷과 오브젝트를 저장하여 클라이언트 버킷 및 개체 데이터를 저장합니다. 배치 대상을 구성하지 않고 인스턴스의 영역 구성의 풀에 매핑하지 않으면 Ceph Object Gateway는 기본 대상 및 풀(예: default_placement )을 사용합니다.

스토리지 정책을 사용하면 Ceph Object Gateway 클라이언트에 스토리지 전략(예: SSD, SAS 드라이브, SATA 드라이브)을 대상으로 하는 스토리지 전략에 액세스할 수 있습니다. 지속성, 복제, 삭제 코딩 등을 보장하는 특정 방법. 자세한 내용은 Red Hat Ceph Storage 5용 스토리지 전략 가이드를 참조하십시오.

스토리지 정책을 생성하려면 다음 절차를 따르십시오.

  1. 원하는 스토리지 전략을 사용하여 새 pool .rgw.buckets.special 을 생성합니다. 예를 들어, 삭제 코딩, 특정 CRUSH 규칙 세트, 복제본 수, pg_num 및 pgp_num 개수로 사용자 지정된 풀입니다.
  2. 영역 그룹 구성을 가져와 파일에 저장합니다(예: zonegroup.json ):

    구문

    [root@master-zone]# radosgw-admin zonegroup --rgw-zonegroup=<zonegroup_name> get > zonegroup.json

    예제

    [root@master-zone]# radosgw-admin zonegroup --rgw-zonegroup=default get > zonegroup.json

  3. zonegroup.json 파일의 placement_target 아래에 special-placement 항목을 추가합니다.

    {
    	"name": "default",
    	"api_name": "",
    	"is_master": "true",
    	"endpoints": [],
    	"hostnames": [],
    	"master_zone": "",
    	"zones": [{
    		"name": "default",
    		"endpoints": [],
    		"log_meta": "false",
    		"log_data": "false",
    		"bucket_index_max_shards": 5
    	}],
    	"placement_targets": [{
    		"name": "default-placement",
    		"tags": []
    	}, {
    		"name": "special-placement",
    		"tags": []
    	}],
    	"default_placement": "default-placement"
    }
  4. 수정된 zonegroup.json 파일로 영역 그룹을 설정합니다.

    [root@master-zone]# radosgw-admin zonegroup set < zonegroup.json
  5. 영역 구성을 가져와 파일에 저장합니다(예: zone.json ):

    [root@master-zone]# radosgw-admin zone get > zone.json
  6. 영역 파일을 편집하고 placement_pool 아래에 새 배치 정책 키를 추가합니다.

    {
    	"domain_root": ".rgw",
    	"control_pool": ".rgw.control",
    	"gc_pool": ".rgw.gc",
    	"log_pool": ".log",
    	"intent_log_pool": ".intent-log",
    	"usage_log_pool": ".usage",
    	"user_keys_pool": ".users",
    	"user_email_pool": ".users.email",
    	"user_swift_pool": ".users.swift",
    	"user_uid_pool": ".users.uid",
    	"system_key": {
    		"access_key": "",
    		"secret_key": ""
    	},
    	"placement_pools": [{
    		"key": "default-placement",
    		"val": {
    			"index_pool": ".rgw.buckets.index",
    			"data_pool": ".rgw.buckets",
    			"data_extra_pool": ".rgw.buckets.extra"
    		}
    	}, {
    		"key": "special-placement",
    		"val": {
    			"index_pool": ".rgw.buckets.index",
    			"data_pool": ".rgw.buckets.special",
    			"data_extra_pool": ".rgw.buckets.extra"
    		}
    	}]
    }
  7. 새 영역 구성을 설정합니다.

    [root@master-zone]# radosgw-admin zone set < zone.json
  8. 영역 그룹 맵을 업데이트합니다.

    [root@master-zone]# radosgw-admin period update --commit

    특수 위치 항목은 placement_target 으로 나열됩니다.

요청 시 스토리지 정책을 지정하려면 다음을 수행합니다.

예제:

$ curl -i http://10.0.0.1/swift/v1/TestContainer/file.txt -X PUT -H "X-Storage-Policy: special-placement" -H "X-Auth-Token: AUTH_rgwtxxxxxx"

7.3. 인덱스 없는 버킷 생성

생성된 버킷에서 버킷 인덱스를 사용하지 않는 배치 대상(즉, 인덱스가 없는 버킷)을 구성할 수 있습니다. 데이터 복제 또는 목록을 사용하지 않는 배치 대상은 인덱스 없는 버킷을 구현할 수 있습니다. 인덱스리스 버킷은 배치 대상이 특정 버킷의 개체를 추적하지 않는 메커니즘을 제공합니다. 이렇게 하면 개체 쓰기가 발생할 때마다 발생하는 리소스 경합이 제거되고 Ceph Object Gateway에서 Ceph 스토리지 클러스터에 수행해야 하는 왕복 횟수가 줄어듭니다. 이는 동시 작업 및 소규모 오브젝트 쓰기 성능에 긍정적인 영향을 줄 수 있습니다.

중요

버킷 인덱스는 버킷의 올바른 상태를 반영하지 않으며 이러한 버킷을 나열하면 해당 오브젝트 목록이 올바르게 반환되지 않습니다. 이는 여러 기능에 영향을 미칩니다. 특히 버킷 인덱스는 변경 정보를 저장하는 데 사용되지 않으므로 이러한 버킷은 다중 영역 환경에서 동기화되지 않습니다. 버킷 인덱스가 이 기능에 필요하므로 인덱스 없는 버킷에서 S3 오브젝트 버전을 사용하지 않는 것이 좋습니다.

참고

인덱스리스 버킷을 사용하면 단일 버킷에 있는 최대 오브젝트 수 제한이 제거됩니다.

참고

인덱스 없는 버킷의 개체는 NFS에서 나열할 수 없습니다.

사전 요구 사항

  • 실행 중이고 정상적인 Red Hat Ceph Storage 클러스터.
  • Ceph Object Gateway 소프트웨어 설치.
  • Ceph Object Gateway 노드에 대한 루트 수준 액세스.

절차

  1. 영역 그룹에 새 배치 대상을 추가합니다.

    예제

    [root@rgw ~]# radosgw-admin zonegroup placement add --rgw-zonegroup="default" \
      --placement-id="indexless-placement"

  2. 영역에 새 배치 대상을 추가합니다.

    예제

    [root@rgw ~]# radosgw-admin zone placement add --rgw-zone="default" \
       --placement-id="indexless-placement" \
       --data-pool="default.rgw.buckets.data" \
       --index-pool="default.rgw.buckets.index" \
       --data_extra_pool="default.rgw.buckets.non-ec" \
       --placement-index-type="indexless"

  3. zonegroup의 기본 배치를 indexless-placement 로 설정합니다.

    예제

    [root@rgw ~]# radosgw-admin zonegroup placement default --placement-id "indexless-placement"

    이 예에서 indexless-placement 대상에서 생성된 버킷은 인덱싱 없는 버킷이 됩니다.

  4. 클러스터가 다중 사이트 구성에 있는 경우 기간을 업데이트하고 커밋합니다.

    예제

    [root@rgw ~]# radosgw-admin period update --commit

  5. 스토리지 클러스터의 모든 노드에서 Ceph Object Gateway를 다시 시작하여 변경 사항을 적용합니다.

    구문

    ceph orch restart SERVICE_TYPE

    예제

    [root@rgw ~]# ceph orch restart rgw

7.4. 버킷 공유 설정

Ceph 개체 게이트웨이는 버킷 인덱스 데이터를 인덱스 풀(index_pool)에 저장합니다. 기본값은 .rgw.buckets.index 입니다. 클라이언트가 여러 객체를 배치할 때수십만 ~ 수천 개의 객체-버킷당 최대 오브젝트 수에 대한 할당량을 설정하지 않고도 단일 버킷에서 인덱스 풀에 상당한 성능 저하가 발생할 수 있습니다.

버킷 인덱스 분할은 버킷당 많은 객체 수를 허용할 때 성능 병목 현상을 방지하는 데 도움이 됩니다.

새 버킷에 대한 버킷 인덱스 분할을 구성하거나 기존 버킷에서 버킷 인덱스를 변경할 수 있습니다.

Red Hat은 shard 수를 계산된 shard 수에 가장 가까운 정수로 사용할 것을 권장합니다. 소수의 버킷 인덱스 shard는 shard에 버킷 인덱스 항목을 균등하게 분산하는 데 더 효과적입니다. 예를 들어, 이전이 기본이므로 7001 버킷 인덱스 shard가 7000보다 좋습니다.

버킷 인덱스 분할을 구성하려면 다음을 수행합니다.

버킷을 재하드하려면 다음을 수행합니다.

7.4.1. 버킷 공유 제한 사항

중요

다음 제한 사항을 주의하여 사용하십시오. 하드웨어 선택과 관련된 영향이 있으므로 Red Hat 계정 팀과 항상 이러한 요구 사항을 논의해야 합니다.

  • 분할이 필요하기 전에 하나의 버킷에 있는 최대 오브젝트 수입니다. Red Hat은 버킷 인덱스 shard당 최대 102,400개의 객체를 권장합니다. 분할을 최대한 활용하기 위해 Ceph Object Gateway 버킷 인덱스 풀에 충분한 OSD를 제공하여 최대 병렬 처리를 확보합니다.
  • 분할을 사용할 때 최대 오브젝트 수: 이전 테스트를 기반으로 현재 지원되는 버킷 인덱스 shard 수는 65521입니다. Red Hat 품질 보증은 버킷 샤딩에서 전체 확장성 테스트를 수행하지 않았습니다.

7.4.2. 버킷 라이프사이클 병렬 스레드 처리

Red Hat Ceph Storage 4.1의 새로운 기능으로 버킷 라이프사이클의 병렬 스레드 처리를 지원합니다. 이러한 병렬화는 Ceph Object Gateway 인스턴스 수로 확장되며 순서 내 인덱스 shard 열거를 숫자 시퀀스로 대체합니다. 기본 잠금 시간 제한이 60초에서 90초로 연장되었습니다. 각 Ceph Object Gateway 인스턴스에 대해 병렬로 실행되도록 라이프사이클 작업자 스레드를 조정하기 위해 새로운 튜닝 가능 옵션이 추가되었습니다.

rgw_lc_max_worker

이 옵션은 동시에 실행할 라이프사이클 작업자 스레드 수를 지정하므로 버킷과 인덱스 shard를 동시에 처리합니다. rgw_lc_max_worker 옵션의 기본값은 3 입니다.

rgw_lc_max_wp_worker

이 옵션은 각 라이프사이클 작업자의 작업 풀에서 스레드 수를 지정합니다. 이 옵션은 각 버킷을 신속하게 처리하는 데 도움이 될 수 있습니다. rgw_lc_max_wp_worker 옵션의 기본값은 3 입니다.

추가 리소스

7.4.3. 간단한 구성에서 버킷 인덱스 공유 구성

모든 새 버킷에서 버킷 인덱스 분할을 활성화하고 구성하려면 rgw_override_bucket_index_max_shards 매개변수를 사용합니다. 매개변수를 다음과 같이 설정합니다.

  • 버킷 인덱스 분할을 비활성화하려면 0 입니다. 이는 기본값입니다.
  • 버킷 샤딩을 활성화하고 최대 shard 수를 설정하는 0 보다 큰 값입니다.

절차

  1. 권장 shard 수를 계산합니다. 이렇게 하려면 다음 공식을 사용하십시오.

    number of objects expected in a bucket / 100,000

    최대 shard 수는 65521입니다.

  2. 그에 따라 rgw_override_bucket_index_max_shards 옵션을 설정합니다.

    구문

    ceph config set client.rgw rgw_override_bucket_index_max_shards VALUE

    VALUE 를 이전 단계에서 계산된 권장 shard 수로 바꿉니다.

    예제

    [root@mon ~]# ceph config set client.rgw rgw_override_bucket_index_max_shards 10

    • Ceph Object Gateway의 모든 인스턴스에 대한 버킷 인덱스 분할을 구성하려면 [global] 섹션에 rgw_override_bucket_index_max_shards 를 추가합니다.
    • Ceph Object Gateway의 특정 인스턴스에 대해서만 버킷 인덱스 분할을 구성하려면 인스턴스에 rgw_override_bucket_index_max_shards 를 추가합니다.
  3. Ceph Object Gateway를 다시 시작합니다.

    # systemctl restart ceph-radosgw.target

7.4.4. 다중 사이트 구성에서 버킷 인덱스 공유 구성

다중 사이트 구성에서 각 영역에 다른 index_pool 설정이 있어 장애 조치(failover)를 관리할 수 있습니다. 하나의 영역 그룹에서 영역에 대한 일관된 shard 수를 구성하려면 해당 영역 그룹의 구성에서 bucket_index_max_shards 설정을 설정합니다. 매개변수를 다음과 같이 설정합니다.

  • 버킷 인덱스 분할을 비활성화하려면 0 입니다. 이는 기본값입니다.
  • 버킷 샤딩을 활성화하고 최대 shard 수를 설정하는 0 보다 큰 값입니다.
참고

인덱스 풀(해당되는 경우)을 SSD 기반 OSD의 CRUSH 규칙 세트에 매핑하면 버킷 인덱스 성능도 도움이 될 수 있습니다.

절차

  1. 권장 shard 수를 계산합니다. 이렇게 하려면 다음 공식을 사용하십시오.

    number of objects expected in a bucket / 100,000

    최대 shard 수는 65521입니다.

  2. 영역 그룹 구성을 zonegroup.json 파일로 추출합니다.

    $ radosgw-admin zonegroup get > zonegroup.json
  3. zonegroup.json 파일에서 명명된 각 영역에 대해 bucket_index_max_shards 설정을 설정합니다.

    bucket_index_max_shards = VALUE

    VALUE 를 이전 단계에서 계산된 권장 shard 수로 바꿉니다. 예를 들면 다음과 같습니다.

    bucket_index_max_shards = 10
  4. 영역 그룹을 재설정합니다.

    $ radosgw-admin zonegroup set < zonegroup.json
  5. 기간을 업데이트합니다.

    $ radosgw-admin period update --commit

7.4.5. 동적 버킷 인덱스 복구

동적 버킷 재하드 프로세스에서는 모든 Ceph Object Gateway 버킷을 정기적으로 확인하고 재하이드가 필요한 버킷을 탐지합니다. rgw_max_objs_per_shard 매개변수에 지정된 값보다 버킷이 커지면 Ceph Object Gateway에서 버킷을 백그라운드에서 동적으로 다시 작성합니다. rgw_max_objs_per_shard 의 기본값은 shard당 100k 오브젝트입니다.

중요

현재 Red Hat은 다중 사이트 구성에서 동적 버킷 재하드를 지원하지 않습니다. 이러한 구성에서 버킷 인덱스를 재하드하려면 수동으로 멀티사이트로 버킷 복구를 참조하십시오.

절차

  1. rgw_dynamic_resharding 옵션을 기본값인 true 로 설정합니다.
  2. 고려해야 할 선택적 설정입니다. ceph 구성 세트 client.rgw OPTION VALUE 를 사용하여 다음 옵션을 변경합니다.

    • rgw_reshard_num_logs: 재하드 로그의 shard 수입니다. 기본값은 16 입니다.
    • rgw_reshard_bucket_lock_duration: 재하드 중에 버킷의 잠금 기간입니다. 기본값은 360 초입니다.
    • rgw_dynamic_resharding: 동적 재하드를 활성화 또는 비활성화합니다. 기본값은 true입니다.
    • rgw_max_objs_per_shard: shard당 최대 오브젝트 수입니다. 기본값은 shard당 100000 개 오브젝트입니다.
    • rgw_reshard_thread_interval: reshard 스레드 처리 사이의 최대 시간. 기본값은 600 초입니다.
  3. resharding 큐에 버킷을 추가하려면 다음을 수행합니다.

    radosgw-admin reshard add --bucket bucket --num-shards number

    교체:

    • 하드 할 버킷의 이름이 있는 버킷
    • shard 수가 있는 숫자

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

    $ radosgw-admin reshard add --bucket data --num-shards 10
  4. resharding 큐를 나열하려면 다음을 수행합니다.

    $ radosgw-admin reshard list
  5. 버킷 재하드 상태를 확인하려면 다음을 수행합니다.

    radosgw-admin reshard status --bucket bucket

    교체:

    • 하드 할 버킷의 이름이 있는 버킷

    예제

    $ radosgw-admin reshard status --bucket data

    • Resharding queue에서 즉시 항목을 처리하려면 다음을 수행합니다.

      $ radosgw-admin reshard process
    • 보류 중인 버킷 재하드를 취소하려면 다음을 수행합니다.

      radosgw-admin reshard cancel --bucket bucket

      교체:

      • 보류 중인 버킷 의 이름으로 버킷

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

      $ radosgw-admin reshard cancel --bucket data
      중요

      보류 중인 재하드 작업만 취소할 수 있습니다. 진행 중인 재하드 작업을 취소하지 마십시오.

    • Red Hat Ceph Storage 3.1 및 이전 버전을 사용하는 경우 Re sharding(기존 인스턴스 정리) 섹션에 설명된 대로 오래된 버킷 항목을 제거합니다.

7.4.6. 수동 버킷 인덱스 복구

버킷이 초기 구성보다 커진 경우 radosgw-admin 버킷 reshard 명령을 사용하여 버킷 인덱스 풀을 다시 작성합니다. 이 명령은 다음과 같습니다.

  • 지정된 버킷에 대한 새 버킷 인덱스 오브젝트 세트를 생성합니다.
  • 이러한 버킷 인덱스 오브젝트에 오브젝트 항목을 배포합니다.
  • 새 버킷 인스턴스를 만듭니다.
  • 모든 새 인덱스 작업이 새 버킷 인덱스를 통과하도록 새 버킷 인스턴스를 버킷에 연결합니다.
  • 이전 및 새 버킷 ID를 명령 출력에 출력합니다.
중요

이 절차는 간단한 구성에서만 사용하십시오. 다중 사이트 구성에서 버킷을 재하드하려면 멀티사이트 를 사용하여 버킷 수동 복구를 참조하십시오.

절차

  1. 원래 버킷 인덱스를 백업합니다.

    radosgw-admin bi list --bucket=bucket > bucket.list.backup

    교체:

    • 하드 할 버킷의 이름이 있는 버킷

    예를 들어 data 라는 버킷의 경우 다음을 입력합니다.

    $ radosgw-admin bi list --bucket=data > data.list.backup
  2. 버킷 인덱스를 다시 작성합니다.

    radosgw-admin bucket reshard --bucket=bucket
    --num-shards=number

    교체:

    • 하드 할 버킷의 이름이 있는 버킷
    • shard 수가 있는 숫자

    예를 들어 data 라는 버킷과 필요한 shard 수가 100인 경우 다음을 입력합니다.

    $ radosgw-admin bucket reshard --bucket=data
    --num-shards=100
  3. Red Hat Ceph Storage 3.1 및 이전 버전을 사용하는 경우 Re sharding(기존 인스턴스 정리) 섹션에 설명된 대로 오래된 버킷 항목을 제거합니다.

7.4.7. 복구 후 오래된 인스턴스 정리

Red Hat Ceph Storage 3.1 및 이전 버전에서는 resharding 프로세스가 오래된 버킷 항목 인스턴스를 자동으로 정리하지 않습니다. 이러한 오래된 인스턴스는 수동으로 정리되지 않은 경우 클러스터의 성능에 영향을 줄 수 있습니다.

중요

다중 사이트 클러스터에서는 이 절차를 단순한 구성에서만 사용하십시오.

사전 요구 사항

  • Ceph 개체 게이트웨이가 설치되어 있어야 합니다.

절차

  1. 오래된 인스턴스를 나열합니다.

    $ radosgw-admin reshard stale-instances list
  2. 오래된 인스턴스를 정리합니다.

    $ radosgw-admin reshard stale-instances rm

7.5. 압축 활성화

Ceph Object Gateway는 Ceph의 압축 플러그인을 사용하여 업로드된 오브젝트의 서버 측 압축을 지원합니다. 여기에는 다음이 포함됩니다.

  • zlib: 지원됨.
  • snappy: 기술 프리뷰.
  • zstd: 기술 프리뷰.
참고

snappyzstd 압축 플러그인은 기술 프리뷰 기능이므로 Red Hat은 아직 품질 보증 테스트를 완료하지 않았기 때문에 완벽하게 지원되지 않습니다.

설정

영역의 배치 대상에서 압축을 활성화하려면 radosgw-admin 영역 배치 수정 명령에 --compression=<type> 옵션을 제공합니다. 압축 유형은 새 오브젝트 데이터를 작성할 때 사용할 압축 플러그인의 이름을 나타냅니다.

각 압축 오브젝트는 압축 유형을 저장합니다. 설정을 변경해도 기존 압축 오브젝트의 압축을 해제하는 기능도 저하되지 않으며, Ceph Object Gateway에서 기존 개체의 압축을 다시 풉니다.

이 압축 설정은 이 배치 대상을 사용하여 버킷에 업로드된 모든 새 개체에 적용됩니다.

영역의 배치 대상에서 압축을 비활성화하려면 radosgw-admin 영역 배치 수정 명령에 --compression=<type> 옵션을 제공하고 빈 문자열 또는 none 을 지정합니다.

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

$ radosgw-admin zone placement modify --rgw-zone=default --placement-id=default-placement --compression=zlib
{
...
    "placement_pools": [
        {
            "key": "default-placement",
            "val": {
                "index_pool": "default.rgw.buckets.index",
                "data_pool": "default.rgw.buckets.data",
                "data_extra_pool": "default.rgw.buckets.non-ec",
                "index_type": 0,
                "compression": "zlib"
            }
        }
    ],
...
}

압축을 활성화하거나 비활성화한 후 Ceph Object Gateway 인스턴스를 다시 시작하여 변경 사항이 적용됩니다.

참고

Ceph Object Gateway는 기본 영역과 풀 세트를 만듭니다. 프로덕션 배포의 경우 먼저 Create a Realm(영역 만들기 ) 섹션을 참조하십시오.

통계

모든 기존 명령 및 API는 압축되지 않은 데이터를 기반으로 개체 및 버킷 크기를 계속 보고하지만 radosgw-admin 버킷 stats 명령에는 모든 버킷에 대한 압축 통계가 포함됩니다.

$ radosgw-admin bucket stats --bucket=<name>
{
...
    "usage": {
        "rgw.main": {
            "size": 1075028,
            "size_actual": 1331200,
            "size_utilized": 592035,
            "size_kb": 1050,
            "size_kb_actual": 1300,
            "size_kb_utilized": 579,
            "num_objects": 104
        }
    },
...
}

size_utilizedsize_kb_utilized 필드는 각각 바이트와 킬로바이트 단위로 압축 데이터의 총 크기를 나타냅니다.

7.6. 사용자 관리

Ceph Object Storage 사용자 관리는 Ceph Storage 클러스터의 클라이언트 애플리케이션으로 Ceph Object Gateway가 아닌 Ceph Object Storage 서비스의 클라이언트 애플리케이션인 사용자를 나타냅니다. 클라이언트 애플리케이션이 Ceph Object Gateway 서비스와 상호 작용할 수 있도록 사용자를 생성하고 키 및 시크릿에 액세스해야 합니다.

다음 두 가지 사용자 유형이 있습니다.

  • 사용자: 'user'라는 용어는 S3 인터페이스의 사용자를 반영합니다.
  • 하위 사용자: 'subuser'라는 용어는 Swift 인터페이스의 사용자를 반영합니다. 하위 사용자는 사용자와 연결됩니다.

사용자와 하위 사용자를 생성, 수정, 보기, 일시 중단 및 제거할 수 있습니다.

중요

다중 사이트 배포에서 사용자를 관리하는 경우 ALWAYS는 사용자가 master 영역 그룹의 마스터 영역 내의 Ceph Object Gateway 노드에서 radosgw-admin 명령을 실행하여 사용자가 다중 사이트 클러스터 전체에서 동기화되도록 합니다. 보조 영역 또는 보조 영역 그룹에서 다중 사이트 클러스터에서 사용자를 생성, 수정 또는 삭제하지 마십시오. 이 문서에서는 [root@master-zone]# 을 마스터 영역 그룹의 마스터 영역에 있는 호스트에 대한 명령줄 규칙으로 사용합니다.

사용자 및 하위 사용자 ID를 만드는 것 외에도 사용자의 표시 이름과 이메일 주소를 추가할 수 있습니다. 키와 시크릿을 지정하거나 키와 시크릿을 자동으로 생성할 수 있습니다. 키를 생성하거나 지정할 때 사용자 ID는 S3 키 유형에 해당하고 하위 사용자 ID는 swift 키 유형에 해당합니다. Swift 키에는 읽기,쓰기, 읽기, 전체 의 액세스 수준도 있습니다.

사용자 관리 명령줄 구문은 일반적으로 user <command> <user-id> 패턴을 따릅니다. 여기서 <user-id>--uid= 옵션 다음에 사용자 ID(S3) 또는 --subuser= 옵션 뒤에 사용자 이름(Swift)이 옵니다. 예를 들면 다음과 같습니다.

[root@master-zone]# radosgw-admin user <create|modify|info|rm|suspend|enable|check|stats> <--uid={id}|--subuser={name}> [other-options]

실행하는 명령에 따라 추가 옵션이 필요할 수도 있습니다.

7.6.1. 멀티 테넌시

Red Hat Ceph Storage 2 이상에서 Ceph Object Gateway는 S3 및 Swift API 모두에 대해 멀티 테넌시를 지원합니다. 여기서 각 사용자 및 버킷은 "테넌트"에 있습니다. 멀티 테넌시는 여러 테넌트가 "테스트", "main" 등과 같은 일반적인 버킷 이름을 사용할 때 네임스페이스 충돌을 방지합니다.

각 사용자 및 버킷은 테넌트 아래에 있습니다. 이전 버전과의 호환성을 위해 이름이 비어 있는 "기존" 테넌트가 추가됩니다. 특히 테넌트를 지정하지 않고 버킷을 참조할 때마다 Swift API는 "기존" 테넌트를 가정합니다. 기존 사용자는 또한 레거시 테넌트 아래에 저장되므로 이전 릴리스와 동일한 방식으로 버킷 및 개체에 액세스합니다.

따라서 테넌트에는 어떤 작업도 없습니다. 사용자를 관리할 때 필요에 따라 표시 및 사라집니다. 명시적 테넌트가 있는 사용자를 생성, 수정 및 제거하려면 추가 옵션 --tenant 이 제공되거나 radosgw-admin 명령의 매개 변수에 "<tenant>$<user>" 구문을 사용합니다.

S3에 대한 testx$tester 사용자를 만들려면 다음을 실행합니다.

[root@master-zone]# radosgw-admin --tenant testx --uid tester \
                    --display-name "Test User" --access_key TESTER \
                    --secret test123 user create

Swift에 대한 testx$tester 사용자를 만들려면 다음 중 하나를 실행합니다.

[root@master-zone]# radosgw-admin --tenant testx --uid tester \
                    --display-name "Test User" --subuser tester:swift \
                    --key-type swift --access full subuser create

[root@master-zone]# radosgw-admin key create --subuser 'testx$tester:swift' \
                    --key-type swift --secret test123
참고

명시적 테넌트가 있는 하위 사용자를 쉘에 따옴표로 묶어야 합니다.

7.6.2. 사용자 만들기

user create 명령을 사용하여 S3-interface 사용자를 생성합니다. 사용자 ID와 표시 이름을 지정해야 합니다. 이메일 주소도 지정할 수 있습니다. 키 또는 시크릿을 지정하지 않으면 radosgw-admin 이 자동으로 생성됩니다. 그러나 생성된 키/시크릿 쌍을 사용하지 않으려면 키 및/또는 시크릿을 지정할 수 있습니다.

[root@master-zone]# radosgw-admin user create --uid=<id> \
[--key-type=<type>] [--gen-access-key|--access-key=<key>]\
[--gen-secret | --secret=<key>] \
[--email=<email>] --display-name=<name>

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

[root@master-zone]# radosgw-admin user create --uid=janedoe --display-name="Jane Doe" --email=jane@example.com
{ "user_id": "janedoe",
  "display_name": "Jane Doe",
  "email": "jane@example.com",
  "suspended": 0,
  "max_buckets": 1000,
  "auid": 0,
  "subusers": [],
  "keys": [
        { "user": "janedoe",
          "access_key": "11BS02LGFB6AL6H1ADMW",
          "secret_key": "vzCEkuryfn060dfee4fgQPqFrncKEIkh3ZcdOANY"}],
  "swift_keys": [],
  "caps": [],
  "op_mask": "read, write, delete",
  "default_placement": "",
  "placement_tags": [],
  "bucket_quota": { "enabled": false,
      "max_size_kb": -1,
      "max_objects": -1},
  "user_quota": { "enabled": false,
      "max_size_kb": -1,
      "max_objects": -1},
  "temp_url_keys": []}
중요

키 출력을 확인합니다. 경우에 따라 radosgw-admin 이 JSON 이스케이프(\)문자를생성하며 일부 클라이언트는 JSON 이스케이프 문자를 처리하는 방법을 모르는 경우가 있습니다. 해결 방법에는 JSON 이스케이프 문자(\)를 제거하고 문자열을 따옴표로 캡슐화하여 키를 다시 생성하고 JSON 이스케이프 문자가 없는지 확인하거나 키와 시크릿을 수동으로 지정하는 작업이 포함됩니다.

7.6.3. 하위 사용자 만들기

하위 사용자(Swift 인터페이스)를 만들려면 사용자 ID(--uid={username}), 하위 사용자 ID 및 하위 사용자의 액세스 수준을 지정해야 합니다. 키 또는 시크릿을 지정하지 않으면 radosgw-admin 이 자동으로 생성됩니다. 그러나 생성된 키/시크릿 쌍을 사용하지 않으려면 키 및/또는 시크릿을 지정할 수 있습니다.

참고

full 에도 액세스 제어 정책이 포함되어 있으므로 full는 읽기 가 아닙니다.

[root@master-zone]# radosgw-admin subuser create --uid={uid} --subuser={uid} --access=[ read | write | readwrite | full ]

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

[root@master-zone]# radosgw-admin subuser create --uid=janedoe --subuser=janedoe:swift --access=full
{ "user_id": "janedoe",
  "display_name": "Jane Doe",
  "email": "jane@example.com",
  "suspended": 0,
  "max_buckets": 1000,
  "auid": 0,
  "subusers": [
        { "id": "janedoe:swift",
          "permissions": "full-control"}],
  "keys": [
        { "user": "janedoe",
          "access_key": "11BS02LGFB6AL6H1ADMW",
          "secret_key": "vzCEkuryfn060dfee4fgQPqFrncKEIkh3ZcdOANY"}],
  "swift_keys": [],
  "caps": [],
  "op_mask": "read, write, delete",
  "default_placement": "",
  "placement_tags": [],
  "bucket_quota": { "enabled": false,
      "max_size_kb": -1,
      "max_objects": -1},
  "user_quota": { "enabled": false,
      "max_size_kb": -1,
      "max_objects": -1},
  "temp_url_keys": []}

7.6.4. 사용자 정보 가져오기

사용자에 대한 정보를 얻으려면 사용자 정보와 사용자 ID(--uid={username})를 지정합니다.

[root@master-zone]# radosgw-admin user info --uid=janedoe

테넌트된 사용자에 대한 정보를 얻으려면 사용자 ID와 테넌트의 이름을 둘 다 지정합니다.

[root@master-zone]# radosgw-admin user info --uid=janedoe --tenant=test

7.6.5. 사용자 정보 수정

사용자에 대한 정보를 수정하려면 사용자 ID(--uid={username})와 수정할 속성을 지정해야 합니다. 일반적인 수정 사항은 키와 시크릿, 이메일 주소, 표시 이름 및 액세스 수준입니다. 예를 들면 다음과 같습니다.

[root@master-zone]# radosgw-admin user modify --uid=janedoe / --display-name="Jane E. Doe"

하위 사용자 값을 수정하려면 하위 사용자 수정 및 하위 사용자 ID를 지정합니다. 예를 들면 다음과 같습니다.

[root@master-zone]# radosgw-admin subuser modify --subuser=janedoe:swift / --access=full

7.6.6. 사용자 활성화 및 일시 중지

사용자를 생성하면 기본적으로 사용자가 활성화됩니다. 그러나 사용자 권한을 중지하고 나중에 다시 활성화할 수 있습니다. 사용자를 일시 중단하려면 사용자 일시 중지 및 사용자 ID를 지정합니다.

[root@master-zone]# radosgw-admin user suspend --uid=johndoe

일시 중단된 사용자를 다시 활성화하려면 user enable 및 user ID를 지정합니다. :

[root@master-zone]# radosgw-admin user enable --uid=johndoe
참고

사용자를 비활성화하면 하위 사용자가 비활성화됩니다.

7.6.7. 사용자 제거

사용자를 제거하면 사용자와 하위 사용자가 시스템에서 제거됩니다. 그러나 원하는 경우 하위 사용자만 제거할 수 있습니다. 사용자(및 하위 사용자)를 제거하려면 사용자 rm 과 사용자 ID를 지정합니다.

[root@master-zone]# radosgw-admin user rm --uid=<uid> [--purge-keys] [--purge-data]

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

[root@master-zone]# radosgw-admin user rm --uid=johndoe --purge-data

하위 사용자만 제거하려면 subuser rm 및 subuser 이름을 지정합니다.

[root@master-zone]# radosgw-admin subuser rm --subuser=johndoe:swift --purge-keys

옵션은 다음과 같습니다.

  • 데이터 삭제: purge -data 옵션은 UID와 연결된 모든 데이터를 삭제합니다.
  • 키 삭제: purge -keys 옵션은 UID와 연결된 모든 키를 제거합니다.

7.6.8. 하위 사용자 제거

하위 사용자를 제거하면 Swift 인터페이스에 대한 액세스를 제거합니다. 사용자는 시스템에 남아 있게 됩니다. Ceph Object Gateway(오브젝트 게이트웨이) 하위 사용자를 제거하려면 subuser rm 및 subuser ID를 지정합니다.

[root@master-zone]# radosgw-admin subuser rm --subuser=johndoe:test

옵션은 다음과 같습니다.

  • 키 삭제: purge -keys 옵션은 UID와 연결된 모든 키를 제거합니다.

7.6.9. 사용자 이름 변경

사용자의 이름을 변경하려면 radosgw-admin 사용자 rename 명령을 사용합니다. 이 명령이 사용하는 시간은 사용자가 보유한 버킷 및 오브젝트 수에 따라 다릅니다. 숫자가 크면 screen 패키지에서 제공하는 Screen 유틸리티에서 명령을 사용하는 것이 좋습니다.

사전 요구 사항

  • 작동 중인 Ceph 클러스터
  • root 또는 sudo 액세스
  • 설치된 Ceph Object Gateway

절차

  1. 사용자 이름을 변경합니다.

    radosgw-admin user rename --uid=current-user-name --new-uid=new-user-name

    예를 들어 user1의 이름을 user 2 로 변경하려면 다음을 수행합니다.

    # radosgw-admin user rename --uid=user1 --new-uid=user2
    
    {
        "user_id": "user2",
        "display_name": "user 2",
        "email": "",
        "suspended": 0,
        "max_buckets": 1000,
        "auid": 0,
        "subusers": [],
        "keys": [
            {
                "user": "user2",
                "access_key": "59EKHI6AI9F8WOW8JQZJ",
                "secret_key": "XH0uY3rKCUcuL73X0ftjXbZqUbk0cavD11rD8MsA"
            }
        ],
        "swift_keys": [],
        "caps": [],
        "op_mask": "read, write, delete",
        "default_placement": "",
        "placement_tags": [],
        "bucket_quota": {
            "enabled": false,
            "check_on_raw": false,
            "max_size": -1,
            "max_size_kb": 0,
            "max_objects": -1
        },
        "user_quota": {
            "enabled": false,
            "check_on_raw": false,
            "max_size": -1,
            "max_size_kb": 0,
            "max_objects": -1
        },
        "temp_url_keys": [],
        "type": "rgw"
    }

    사용자가 테넌트 내에 있는 경우 사용자 이름과 테넌트를 둘 다 지정합니다.

    구문

    radosgw-admin user rename --uid user-name --new-uid new-user-name --tenant tenant

    예를 들어 테스트 테넌트 내에서 user1 의 이름을 user2 로 변경하려면 다음을 수행합니다.

    예제

    # radosgw-admin user rename --uid=test$user1 --new-uid=test$user2 --tenant test
    
    1000 objects processed in tvtester1. Next marker 80_tVtester1_99
    2000 objects processed in tvtester1. Next marker 64_tVtester1_44
    3000 objects processed in tvtester1. Next marker 48_tVtester1_28
    4000 objects processed in tvtester1. Next marker 2_tVtester1_74
    5000 objects processed in tvtester1. Next marker 14_tVtester1_53
    6000 objects processed in tvtester1. Next marker 87_tVtester1_61
    7000 objects processed in tvtester1. Next marker 6_tVtester1_57
    8000 objects processed in tvtester1. Next marker 52_tVtester1_91
    9000 objects processed in tvtester1. Next marker 34_tVtester1_74
    9900 objects processed in tvtester1. Next marker 9_tVtester1_95
    1000 objects processed in tvtester2. Next marker 82_tVtester2_93
    2000 objects processed in tvtester2. Next marker 64_tVtester2_9
    3000 objects processed in tvtester2. Next marker 48_tVtester2_22
    4000 objects processed in tvtester2. Next marker 32_tVtester2_42
    5000 objects processed in tvtester2. Next marker 16_tVtester2_36
    6000 objects processed in tvtester2. Next marker 89_tVtester2_46
    7000 objects processed in tvtester2. Next marker 70_tVtester2_78
    8000 objects processed in tvtester2. Next marker 51_tVtester2_41
    9000 objects processed in tvtester2. Next marker 33_tVtester2_32
    9900 objects processed in tvtester2. Next marker 9_tVtester2_83
    {
        "user_id": "test$user2",
        "display_name": "User 2",
        "email": "",
        "suspended": 0,
        "max_buckets": 1000,
        "auid": 0,
        "subusers": [],
        "keys": [
            {
                "user": "test$user2",
                "access_key": "user2",
                "secret_key": "123456789"
            }
        ],
        "swift_keys": [],
        "caps": [],
        "op_mask": "read, write, delete",
        "default_placement": "",
        "placement_tags": [],
        "bucket_quota": {
            "enabled": false,
            "check_on_raw": false,
            "max_size": -1,
            "max_size_kb": 0,
            "max_objects": -1
        },
        "user_quota": {
            "enabled": false,
            "check_on_raw": false,
            "max_size": -1,
            "max_size_kb": 0,
            "max_objects": -1
        },
        "temp_url_keys": [],
        "type": "rgw"
    }

  2. 사용자의 이름이 성공적으로 변경되었는지 확인합니다.

    구문

    radosgw-admin user info --uid=new-user-name

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

    예제

    # radosgw-admin user info --uid=user2

    사용자가 테넌트 내에 있는 경우 테넌트$사용자 이름 형식을 사용하십시오.

    radosgw-admin user info --uid=tenant$new-user-name
    # radosgw-admin user info --uid=test$user2

추가 리소스

  • screen(1) 매뉴얼 페이지

7.6.10. 키 만들기

사용자에 대한 키를 생성하려면 키 생성을 지정해야 합니다. 사용자의 경우 사용자 ID 및 s3 키 유형을 지정합니다. 하위 사용자에 대한 키를 만들려면 하위 사용자 ID와 swift 키 유형을 지정해야 합니다. 예를 들면 다음과 같습니다.

[root@master-zone]# radosgw-admin key create --subuser=johndoe:swift --key-type=swift --gen-secret
{ "user_id": "johndoe",
  "rados_uid": 0,
  "display_name": "John Doe",
  "email": "john@example.com",
  "suspended": 0,
  "subusers": [
     { "id": "johndoe:swift",
       "permissions": "full-control"}],
  "keys": [
    { "user": "johndoe",
      "access_key": "QFAMEDSJP5DEKJO0DDXY",
      "secret_key": "iaSFLDVvDdQt6lkNzHyW4fPLZugBAI1g17LO0+87"}],
  "swift_keys": [
    { "user": "johndoe:swift",
      "secret_key": "E9T2rUZNu2gxUjcwUBO8n\/Ev4KX6\/GprEuH4qhu1"}]}

7.6.11. 액세스 키 추가 및 제거

사용자 및 하위 사용자는 S3 및 Swift 인터페이스를 사용하려면 액세스 키가 있어야 합니다. 사용자 또는 하위 사용자를 생성하고 액세스 키와 시크릿을 지정하지 않으면 키와 시크릿이 자동으로 생성됩니다. 키를 생성하고 액세스 키 및/또는 시크릿을 지정하거나 생성할 수 있습니다. 액세스 키와 시크릿을 제거할 수도 있습니다. 옵션은 다음과 같습니다.

  • --secret=<key> 는 비밀 키를 지정합니다(예: 수동으로 생성).
  • --Gen-access-key 는 임의 액세스 키를 생성합니다(기본적으로 S3 사용자의 경우).
  • --Gen-secret 은 임의 비밀 키를 생성합니다.
  • --key-type=<type> 은 키 유형을 지정합니다. 옵션은 swift, s3입니다.

키를 추가하려면 사용자를 지정합니다.

[root@master-zone]# radosgw-admin key create --uid=johndoe --key-type=s3 --gen-access-key --gen-secret

키와 시크릿을 지정할 수도 있습니다.

액세스 키를 제거하려면 사용자와 키를 지정해야 합니다.

  1. 특정 사용자에 대한 액세스 키를 찾습니다.

    [root@master-zone]# radosgw-admin user info --uid=<testid>

    액세스 키는 출력의 "access_key" 값입니다. 예를 들면 다음과 같습니다.

    $ radosgw-admin user info --uid=johndoe
    {
        "user_id": "johndoe",
        ...
        "keys": [
            {
                "user": "johndoe",
                "access_key": "0555b35654ad1656d804",
                "secret_key": "h7GhxuBLTrlhVUyxSPUKUV8r/2EI4ngqJxD7iBdBYLhwluN30JaT3Q=="
            }
        ],
        ...
    }
  2. 액세스 키를 제거하려면 사용자 ID와 이전 단계의 액세스 키를 지정합니다.

    [root@master-zone]# radosgw-admin key rm --uid=<user_id> --access-key <access_key>

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

    [root@master-zone]# radosgw-admin key rm --uid=johndoe --access-key 0555b35654ad1656d804

7.6.12. 관리 기능 추가 및 제거

Ceph Storage 클러스터는 사용자가 REST API를 통해 관리 기능을 실행할 수 있는 관리 API를 제공합니다. 기본적으로 사용자는 이 API에 액세스할 수 없습니다. 사용자가 관리 기능을 수행할 수 있도록 하려면 사용자에게 관리 기능을 제공합니다.

사용자에게 관리 기능을 추가하려면 다음을 실행합니다.

[root@master-zone]# radosgw-admin caps add --uid={uid} --caps={caps}

사용자, 버킷, 메타데이터 및 사용(utilization)에 읽기, 쓰기 또는 모든 기능을 추가할 수 있습니다. 예를 들면 다음과 같습니다.

--caps="[users|buckets|metadata|usage|zone]=[*|read|write|read, write]"

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

[root@master-zone]# radosgw-admin caps add --uid=johndoe --caps="users=*"

사용자의 관리 기능을 제거하려면 다음을 실행합니다.

[root@master-zone]# radosgw-admin caps remove --uid=johndoe --caps={caps}

7.7. 할당량 관리

Ceph 개체 게이트웨이를 사용하면 사용자가 소유한 사용자와 버킷에 할당량을 설정할 수 있습니다. 쿼터에는 버킷의 최대 오브젝트 수와 최대 스토리지 크기(MB)가 포함됩니다.

  • 버킷: bucket 옵션을 사용하면 사용자가 소유한 버킷의 할당량을 지정할 수 있습니다.
  • 최대 객체: max -objects 설정을 사용하면 최대 오브젝트 수를 지정할 수 있습니다. 음수 값은 이 설정을 비활성화합니다.
  • 최대 크기: max -size 옵션을 사용하면 최대 바이트 수에 대한 할당량을 지정할 수 있습니다. 음수 값은 이 설정을 비활성화합니다.
  • 할당량 범위: quota-scope 옵션은 할당량의 범위를 설정합니다. 옵션은 버킷사용자입니다. 버킷 할당량은 사용자가 소유한 버킷에 적용됩니다. 사용자 할당량은 사용자에게 적용됩니다.
중요

오브젝트 수가 많은 버킷으로 인해 심각한 성능 문제가 발생할 수 있습니다. 하나의 버킷에서 권장되는 최대 오브젝트 수는 100,000개입니다. 이 수를 늘리려면 버킷 인덱스 분할을 구성합니다. 자세한 내용은 7.4절. “버킷 공유 설정” 을 참조하십시오.

7.7.1. 사용자 할당량 설정

할당량을 활성화하기 전에 먼저 할당량 매개 변수를 설정해야 합니다. 예를 들면 다음과 같습니다.

[root@master-zone]# radosgw-admin quota set --quota-scope=user --uid=<uid> [--max-objects=<num objects>] [--max-size=<max size>]

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

radosgw-admin quota set --quota-scope=user --uid=johndoe --max-objects=1024 --max-size=1024

num 오브젝트 및 / 또는 max 크기의 음수 값은 특정 할당량 특성 확인이 비활성화되었음을 나타냅니다.

7.7.2. 사용자 할당량 활성화 및 비활성화

사용자 할당량을 설정하고 나면 활성화할 수 있습니다. 예를 들면 다음과 같습니다.

[root@master-zone]# radosgw-admin quota enable --quota-scope=user --uid=<uid>

활성화된 사용자 할당량을 비활성화할 수 있습니다. 예를 들면 다음과 같습니다.

[root@master-zone]# radosgw-admin quota disable --quota-scope=user --uid=<uid>

7.7.3. 버킷 할당량 설정

버킷 할당량은 지정된 uid 가 소유한 버킷에 적용됩니다. 해당 사용자는 사용자와 독립적입니다.

[root@master-zone]# radosgw-admin quota set --uid=<uid> --quota-scope=bucket [--max-objects=<num objects>] [--max-size=<max size in bytes>]

num 오브젝트 및 / 또는 max 크기의 음수 값은 특정 할당량 특성 확인이 비활성화되었음을 나타냅니다.

7.7.4. 버킷 할당량 활성화 및 비활성화

버킷 할당량을 설정하고 나면 활성화할 수 있습니다. 예를 들면 다음과 같습니다.

[root@master-zone]# radosgw-admin quota enable --quota-scope=bucket --uid=<uid>

활성화된 버킷 할당량을 비활성화할 수 있습니다. 예를 들면 다음과 같습니다.

[root@master-zone]# radosgw-admin quota-disable --quota-scope=bucket --uid=<uid>

7.7.5. 할당량 설정 가져오기

사용자 정보 API를 통해 각 사용자의 할당량 설정에 액세스할 수 있습니다. CLI 인터페이스를 사용하여 사용자 할당량 설정 정보를 읽으려면 다음을 실행합니다.

# radosgw-admin user info --uid=<uid>

테넌트된 사용자의 할당량 설정을 가져오려면 사용자 ID와 테넌트 이름을 지정합니다.

+ radosgw-admin user info --uid=_user-id_ --tenant=_tenant_

7.7.6. 할당량 통계 업데이트

할당량 통계가 비동기적으로 업데이트됩니다. 모든 사용자와 모든 버킷에 대한 할당량 통계를 수동으로 업데이트하여 최신 할당량 통계를 검색할 수 있습니다.

[root@master-zone]# radosgw-admin user stats --uid=<uid> --sync-stats

7.7.7. 사용자 할당량 사용 통계 가져오기

사용자가 사용한 할당량의 양을 보려면 다음을 실행합니다.

# radosgw-admin user stats --uid=<uid>
참고

최신 데이터를 받으려면 --sync -stats 옵션을 사용하여 radosgw- admin 사용자 통계를 실행해야 합니다.

7.7.8. 할당량 캐시

할당량 통계는 각 Ceph 게이트웨이 인스턴스에 대해 캐시됩니다. 여러 인스턴스가 있는 경우 각 인스턴스에 할당량에 대한 다른 보기가 있으므로 캐시에서 할당량이 완전히 적용되지 않도록 유지할 수 있습니다. 이를 제어하는 옵션은 rgw 버킷 할당량 ttl,rgw 사용자 할당량 동기화 간격rgw 사용자 할당량 동기화 간격입니다. 이러한 값이 클수록 할당량 작업이 더 효율적이지만 동기화되지 않는 여러 인스턴스는 가 됩니다. 이 값이 낮을수록 여러 인스턴스를 완벽하게 적용할 수 있습니다. 세 개 모두 0이면 할당량 캐싱이 효과적으로 비활성화되고 여러 인스턴스에 완벽한 할당량 적용이 가능합니다. 이러한 옵션에 대한 자세한 내용은 부록 A. 설정 참조 을 참조하십시오.

7.7.9. 글로벌 할당량 읽기 및 작성

영역 그룹 맵에서 할당량 설정을 읽고 쓸 수 있습니다. 영역 그룹 맵을 가져오려면 다음을 수행합니다.

[root@master-zone]# radosgw-admin global quota get

할당량 세트, 할당량활성화할당량 비활성화 명령의 전역 할당량 설정을 사용하여 글로벌 할당량 설정을 조작할 수 있습니다.

[root@master-zone]# radosgw-admin global quota set --quota-scope bucket --max-objects 1024
[root@master-zone]# radosgw-admin global quota enable --quota-scope bucket
참고

영역 및 기간이 있는 다중 사이트 구성에서는 period update --commit 를 사용하여 글로벌 할당량에 대한 변경 사항을 커밋해야 합니다. 기간이 없는 경우 변경 사항을 적용하려면 Ceph 개체 게이트웨이를 다시 시작해야 합니다.

7.8. 버킷 관리

스토리지 관리자는 Ceph Object Gateway를 사용할 때 사용자 간에 이동하고 이름을 변경하여 버킷을 관리할 수 있습니다. 특정 이벤트에서 트리거하도록 버킷 알림을 생성할 수 있습니다. 또한 스토리지 클러스터의 수명 동안 발생할 수 있는 Ceph Object Gateway 내에서 고아 또는 누수 개체를 찾을 수 있습니다.

7.8.1. 버킷 이름 변경

버킷의 이름을 바꿀 수 있습니다.

참고

버킷 이름에 밑줄을 허용하려면 rgw_s3_relaxed_bucket_names 옵션을 true로 설정합니다.

사전 요구 사항

  • 실행 중인 Red Hat Ceph Storage 클러스터.
  • Ceph Object Gateway 소프트웨어 설치.
  • 기존 버킷입니다.

절차

  1. 버킷을 나열합니다.

    radosgw-admin bucket list

    예를 들어 출력의 버킷에 유의하십시오.

    # radosgw-admin bucket list
    [
        "34150b2e9174475db8e191c188e920f6/swcontainer",
        "s3bucket1",
        "34150b2e9174475db8e191c188e920f6/swimpfalse",
        "c278edd68cfb4705bb3e07837c7ad1a8/ec2container",
        "c278edd68cfb4705bb3e07837c7ad1a8/demoten1",
        "c278edd68cfb4705bb3e07837c7ad1a8/demo-ct",
        "c278edd68cfb4705bb3e07837c7ad1a8/demopostup",
        "34150b2e9174475db8e191c188e920f6/postimpfalse",
        "c278edd68cfb4705bb3e07837c7ad1a8/demoten2",
        "c278edd68cfb4705bb3e07837c7ad1a8/postupsw"
    ]
  2. 버킷의 이름을 변경합니다.

    radosgw-admin bucket link --bucket=original-name --bucket-new-name=new-name --uid=user-ID

    예를 들어 s3bucket1 버킷의 이름을 s3 newb 로 변경하려면 다음을 수행합니다.

    # radosgw-admin bucket link --bucket=s3bucket1 --bucket-new-name=s3newb --uid=testuser

    버킷이 테넌트 내에 있는 경우 테넌트도 지정합니다.

    radosgw-admin bucket link --bucket=tenant/original-name --bucket-new-name=new-name --uid=tenant$user-ID

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

    # radosgw-admin bucket link --bucket=test/s3bucket1 --bucket-new-name=s3newb --uid=test$testuser
  3. 버킷의 이름이 변경되었는지 확인합니다.

    radosgw-admin bucket list

    예를 들어 s3newb 라는 버킷이 있습니다.

    # radosgw-admin bucket list
    [
        "34150b2e9174475db8e191c188e920f6/swcontainer",
        "34150b2e9174475db8e191c188e920f6/swimpfalse",
        "c278edd68cfb4705bb3e07837c7ad1a8/ec2container",
        "s3newb",
        "c278edd68cfb4705bb3e07837c7ad1a8/demoten1",
        "c278edd68cfb4705bb3e07837c7ad1a8/demo-ct",
        "c278edd68cfb4705bb3e07837c7ad1a8/demopostup",
        "34150b2e9174475db8e191c188e920f6/postimpfalse",
        "c278edd68cfb4705bb3e07837c7ad1a8/demoten2",
        "c278edd68cfb4705bb3e07837c7ad1a8/postupsw"
    ]

7.8.2. 버킷 이동

radosgw-admin 버킷 유틸리티는 사용자 간에 버킷을 이동하는 기능을 제공합니다. 이를 수행하려면 버킷을 새 사용자에게 연결하고 버킷의 소유권을 새 사용자에게 변경합니다.

버킷을 이동할 수 있습니다.

7.8.2.1. 사전 요구 사항

  • 실행 중인 Red Hat Ceph Storage 클러스터
  • Ceph Object Gateway가 설치되어 있습니다.
  • 버킷
  • 테넌트 및 비 테넌트 사용자

7.8.2.2. 테넌트가 아닌 사용자 간에 버킷 이동

radosgw-admin 버킷 chown 명령은 버킷과 포함된 모든 오브젝트의 소유권을 한 사용자의 다른 사용자로 변경할 수 있는 기능을 제공합니다. 이를 수행하려면 현재 사용자의 버킷을 연결 해제하고 새 사용자에게 연결한 다음 버킷의 소유권을 새 사용자로 변경합니다.

절차

  1. 버킷을 새 사용자에게 연결합니다.

    radosgw-admin bucket link --uid=user --bucket=bucket

    교체:

    • 버킷 연결할 사용자의 사용자 이름과 사용자 이름이 있는 사용자
    • 버킷 이름으로 버킷

    예를 들어 데이터 버킷을 user2 라는 사용자에 연결하려면 다음을 수행합니다.

    # radosgw-admin bucket link --uid=user2 --bucket=data
  2. 버킷이 user2 에 성공적으로 연결되었는지 확인합니다.

    # radosgw-admin bucket list --uid=user2
    [
        "data"
    ]
  3. 버킷의 소유권을 새 사용자로 변경합니다.

    radosgw-admin bucket chown --uid=user --bucket=bucket

    교체:

    • 버킷 소유권 다음으로 변경하기 위해 사용자의 사용자 이름이 있는 사용자
    • 버킷 이름으로 버킷

    예를 들어 데이터 버킷의 소유권을 user2 로 변경하려면 다음을 수행합니다.

    # radosgw-admin bucket chown --uid=user2 --bucket=data
  4. 다음 명령의 출력에서 owner 행을 확인하여 데이터 버킷의 소유권이 성공적으로 변경되었는지 확인합니다.

    # radosgw-admin bucket list --bucket=data

7.8.2.3. 테넌트 사용자 간에 버킷 이동

테넌트된 사용자 간에 버킷을 이동할 수 있습니다.

절차

  1. 버킷을 새 사용자에게 연결합니다.

    radosgw-admin bucket link --bucket=current-tenant/bucket --uid=new-tenant$user

    교체:

    • 버킷이 인 테넌트 이름이 current-tenant
    • 연결할 버킷 의 이름과 버킷
    • 새 사용자가 인 테넌트의 이름이 new-tenant
    • 사용자의 사용자 이름이 있는 사용자

    예를 들어 test 테넌트의 데이터 버킷을 test 2 테넌트의 user2 사용자에게 연결하려면 다음을 수행합니다.

    # radosgw-admin bucket link --bucket=test/data --uid=test2$user2
  2. 버킷이 user2 에 성공적으로 연결되었는지 확인합니다.

    # radosgw-admin bucket list --uid=test$user2
    [
        "data"
    ]
  3. 버킷의 소유권을 새 사용자로 변경합니다.

    radosgw-admin bucket chown --bucket=new-tenant/bucket --uid=new-tenant$user

    교체:

    • 연결할 버킷 의 이름과 버킷
    • 새 사용자가 인 테넌트의 이름이 new-tenant
    • 사용자의 사용자 이름이 있는 사용자

    예를 들어 데이터 버킷의 소유권을 test2 테넌트 내의 user2 로 변경하려면 다음을 수행합니다.

    # radosgw-admin bucket chown --bucket='test2/data' --uid='test$tuser2'
  4. 다음 명령의 출력에서 owner 행을 확인하여 데이터 버킷의 소유권이 성공적으로 변경되었는지 확인합니다.

    # radosgw-admin bucket list --bucket=test2/data

7.8.2.4. 테넌트가 아닌 사용자의 버킷을 테넌트 사용자로 이동

테넌트가 아닌 사용자의 버킷을 테넌트 사용자로 이동할 수 있습니다.

절차

  1. 선택 사항: 아직 여러 개의 테넌트가 없는 경우 rgw_keystone_implicit_tenants 를 활성화하고 외부 테넌트에서 Ceph Object Gateway에 액세스하여 생성할 수 있습니다.

    rgw_keystone_implicit_tenants 옵션을 활성화합니다.

    예제

    [root@mon ~]# ceph config set client.rgw rgw_keystone_implicit_tenants true

    s3cmd 또는 swift 명령을 사용하여 tenant 테넌트에서 Ceph Object Gateway에 액세스합니다.

    # swift list

    또는 s3cmd 를 사용하십시오.

    # s3cmd ls

    외부 테넌트에서 첫 번째 액세스 권한은 동일한 Ceph Object Gateway 사용자를 생성합니다.

  2. 버킷을 테넌트된 사용자로 이동합니다.

    radosgw-admin bucket link --bucket=/bucket --uid='tenant$user'

    교체:

    • 버킷 이름으로 버킷
    • 새 사용자가 있는 테넌트의 이름이 인 테넌트
    • 사용자의 사용자 이름이 있는 사용자

    예를 들어 데이터 버킷을 테스트 테넌트 내부의 tenanted-user 로 이동하려면 다음을 수행합니다.

    # radosgw-admin bucket link --bucket=/data --uid='test$tenanted-user'
  3. 데이터 버킷이 tenanted-user 에 연결되었는지 확인합니다.

    # radosgw-admin bucket list --uid='test$tenanted-user'
    [
        "data"
    ]
  4. 버킷의 소유권을 새 사용자로 변경합니다.

    radosgw-admin bucket chown --bucket='tenant/bucket name' --uid='tenant$user'

    교체:

    • 버킷 이름으로 버킷
    • 새 사용자가 있는 테넌트의 이름이 인 테넌트
    • 사용자의 사용자 이름이 있는 사용자

    예를 들어 데이터 버킷의 소유권을 테스트 테넌트 내부에 있는 tenanted-user 로 변경하려면 다음을 수행합니다.

    # radosgw-admin bucket chown --bucket='test/data' --uid='test$tenanted-user'
  5. 다음 명령의 출력에서 owner 행을 확인하여 데이터 버킷의 소유권이 성공적으로 변경되었는지 확인합니다.

    # radosgw-admin bucket list --bucket=test/data

7.8.3. 고아 및 누수 개체 찾기

정상 스토리지 클러스터에는 고립 또는 누수 개체가 없지만, 경우에 따라 고립 또는 누수 개체가 발생할 수 있습니다. 예를 들어 작업 도중 Ceph Object Gateway가 다운되면 일부 오브젝트가 고립됩니다. 또한 검색되지 않은 버그로 인해 고립된 오브젝트가 발생할 수 있습니다.

Red Hat Ceph Storage 4.1부터 스토리지 관리자는 Ceph Object Gateway 개체를 RADOS 오브젝트에 매핑하는 방법을 확인할 수 있습니다. radosgw-admin 명령은 이러한 잠재적 고립 또는 누수 개체 목록을 검색하고 생성하는 새 도구를 제공합니다. radoslist 하위 명령을 사용하면 버킷 또는 스토리지 클러스터의 모든 버킷에 저장된 오브젝트가 표시됩니다. rgw-orphan-list 스크립트는 풀 내에 고립된 오브젝트를 표시합니다.

중요

radoslist 하위 명령은 더 이상 사용되지 않는 orphans find 및 orphans finish 하위 명령을 대체합니다.

사전 요구 사항

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

절차

  1. 버킷 내에 데이터를 보관하는 오브젝트 목록을 생성하려면 다음을 수행합니다.

    구문

    radosgw-admin bucket radoslist --bucket BUCKET_NAME

    예제

    [root@rgw ~]# radosgw-admin bucket radoslist --bucket mybucket

    참고

    BUCKET_NAME 을 생략하면 모든 버킷의 모든 오브젝트가 표시됩니다.

  2. 풀에 대한 고립자 목록을 생성하려면 다음을 수행합니다.

    [root@rgw ~]# rgw-orphan-list

    예제

    Available pools:
        .rgw.root
        default.rgw.control
        default.rgw.meta
        default.rgw.log
        default.rgw.buckets.index
        default.rgw.buckets.data
        rbd
        default.rgw.buckets.non-ec
        ma.rgw.control
        ma.rgw.meta
        ma.rgw.log
        ma.rgw.buckets.index
        ma.rgw.buckets.data
        ma.rgw.buckets.non-ec
    Which pool do you want to search for orphans?

    orphans를 검색할 풀 이름을 입력합니다.

    중요

    메타데이터 풀이 아닌 rgw-orphan-list 명령을 사용할 때 데이터 풀을 지정해야 합니다.

  3. 목록에서 고립된 오브젝트를 검토합니다.
  4. orphan 오브젝트를 제거하려면 다음을 수행합니다.

    구문

    rados -p POOL_NAME rm OBJECT_NAME

    예제

    [root@rgw ~]# rados -p default.rgw.buckets.data rm myobject

    주의

    올바른 오브젝트를 제거 중인지 확인합니다. rados rm 명령을 실행하면 스토리지 클러스터에서 데이터가 제거됩니다.

추가 리소스

  • 레거시 radosgw-admin orphans find 하위 명령에 대한 자세한 내용은 Red Hat Ceph Storage 3 Object Gateway 관리 가이드Orphan Objects 찾기 섹션을 참조하십시오.

7.8.4. 버킷 알림

버킷 알림은 버킷에서 특정 이벤트가 발생할 때 Ceph Object Gateway에서 정보를 전송하는 방법을 제공합니다. 버킷 알림을 HTTP, AMQP0.9.1 및 Kafka 엔드포인트로 전송할 수 있습니다. 특정 버킷과 특정 주제의 이벤트에 대한 버킷 알림을 보내려면 알림 항목을 생성해야 합니다. 버킷 알림은 이벤트 유형의 하위 집합 또는 모든 이벤트 유형에 대해 기본적으로 만들 수 있습니다. 버킷 알림은 키 접두사 또는 접미사, 키와 일치하는 정규식 및 오브젝트에 연결된 메타데이터 특성 또는 오브젝트 태그에 연결된 메타데이터 특성에 따라 이벤트를 필터링할 수 있습니다. 버킷 알림에는 버킷 알림 메커니즘에 대한 구성 및 제어 인터페이스를 제공하는 REST API가 있습니다.

참고

버킷 알림 API는 기본적으로 활성화되어 있습니다. rgw_enable_apis 구성 매개 변수가 명시적으로 설정된 경우 s3알림이 포함되어 있는지 확인합니다. 이를 확인하려면 ceph --admin-daemon /var/run/ceph/ceph-client.rgw.NAME.asok config get rgw_enable_apis 명령을 실행합니다. NAME(이름 )을 Ceph Object Gateway 인스턴스 이름으로 바꿉니다.

CLI를 사용한 주제 관리

Ceph Object Gateway 버킷에 대한 목록, 가져오기 및 제거를 관리할 수 있습니다.

  • 주제 나열: 다음 명령을 실행하여 모든 주제의 구성을 나열합니다.

    예제

    [ceph: host01 /]# radosgw-admin topic list

  • 주제 가져오기: 다음 명령을 실행하여 특정 주제의 구성을 가져옵니다.

    예제

    [ceph: host01 /]# radosgw-admin topic get --topic=topic1

  • 주제 삭제: 다음 명령을 실행하여 특정 주제의 구성을 제거합니다.

    예제

    [ceph: host01 /]# radosgw-admin topic rm --topic=topic1

    참고

    해당 항목에 Ceph Object Gateway 버킷이 구성되어 있어도 주제가 제거됩니다.

7.8.5. 버킷 알림 생성

버킷 수준에서 버킷 알림을 생성합니다. 알림 구성에는 Red Hat Ceph Storage Object Gateway S3 이벤트, ObjectCreated 및 Object Removed 가 있습니다. 이를 게시하고 버킷 알림을 보내려면 대상을 게시해야 합니다. 버킷 알림은 S3 작업입니다.

사전 요구 사항

  • 실행 중인 Red Hat Ceph Storage 클러스터.
  • 실행 중인 HTTP 서버, RabbitMQ 서버 또는 Kafka 서버.
  • 루트 수준 액세스.
  • Red Hat Ceph Storage 개체 게이트웨이 설치.
  • 사용자 액세스 키 및 비밀 키.
  • 엔드포인트 매개 변수.
중요

Red Hat은 ObjectCreate 이벤트(예:, put,post,multipartUpload, copy )를 지원합니다. Red Hat은 Object _delete 및 s3_multi_object_delete 와 같은 ObjectRemove 이벤트도 지원합니다.

절차

  1. s3 버킷을 만듭니다.
  2. http,amqp 또는 kafka 프로토콜에 대한 pvc 주제를 만듭니다.
  3. s 3:objectCreate 및 s3:object Remove 이벤트에 대한 s3 버킷 알림을 생성합니다.

    예제

    client.put_bucket_notification_configuration(
       Bucket=bucket_name,
       NotificationConfiguration={
           'TopicConfigurations': [
               {
                   'Id': notification_name,
                   'TopicArn': topic_arn,
                   'Events': ['s3:ObjectCreated:*', 's3:ObjectRemoved:*']
               }]})

  4. 버킷에 s3 오브젝트를 생성합니다.
  5. http 또는 rabbitmq 또는 kafka 수신자에서 오브젝트 생성 이벤트를 확인합니다.
  6. 오브젝트를 삭제합니다.
  7. http 또는 rabbitmq 또는 kafka 수신자에서 오브젝트 삭제 이벤트를 확인합니다.

7.8.6. 추가 리소스

7.9. 버킷 라이프사이클

스토리지 관리자는 버킷 라이프사이클 구성을 사용하여 오브젝트를 관리하여 수명 동안 효과적으로 저장할 수 있습니다. 예를 들어 사용 사례에 따라 더 저렴한 스토리지 클래스, 아카이브 또는 오브젝트를 삭제할 수 있습니다.

7.9.1. 스토리지 클러스터 내에서 S3 버킷 라이프사이클 전환

버킷 라이프사이클 구성을 사용하여 개체를 관리할 수 있으므로 개체의 수명 동안 개체가 효과적으로 저장됩니다. 오브젝트 라이프사이클 전환 규칙을 사용하면 오브젝트 수명 동안 오브젝트를 관리하고 효과적으로 저장할 수 있습니다. 더 저렴한 스토리지 클래스, 아키텍처 또는 삭제로 개체를 전환할 수 있습니다.

다음과 같은 스토리지 클래스를 생성할 수 있습니다.

  • I/O 민감한 워크로드의 경우 SSD 또는 NVMe와 같은 빠른 미디어
  • 아카이브를 위한 SAS 또는 SATA와 같은 느린 자기 미디어.

hot 스토리지 클래스와 콜드 스토리지 클래스 간의 데이터 이동 일정을 생성할 수 있습니다. 예를 들어 오브젝트가 만료되고 영구적으로 삭제되도록 지정된 시간 후에 이 이동을 예약할 수 있습니다. 예를 들어 오브젝트를 생성한 후 30일 후에 오브젝트를 스토리지 클래스로 전환하거나 스토리지 클래스로 보관할 수도 있습니다. 전환 규칙을 통해 이 작업을 수행할 수 있습니다. 이 규칙은 하나의 스토리지 클래스에서 다른 스토리지 클래스로 전환하는 오브젝트에 적용됩니다. 라이프사이클 구성에는 <Rule> 요소를 사용하는 하나 이상의 규칙이 포함됩니다.

추가 리소스

7.9.2. 하나의 스토리지 클래스에서 다른 스토리지 클래스로 오브젝트 전환

오브젝트 라이프사이클 전환 규칙을 사용하면 하나의 스토리지 클래스에서 다른 클래스로 오브젝트를 전환할 수 있습니다.

사전 요구 사항

  • Ceph Object Gateway 소프트웨어 설치.
  • Ceph Object Gateway 노드에 대한 루트 수준 액세스.
  • 사용자 액세스 권한으로 생성된 S3 사용자.

절차

  1. 새 데이터 풀을 생성합니다.

    구문

    ceph osd pool create POOL_NAME

    예제

    [root@rgw /]# ceph osd pool create test.hot.data

  2. 새 스토리지 클래스를 추가합니다.

    구문

    radosgw-admin zonegroup placement add  --rgw-zonegroup default --placement-id PLACEMENT_TARGET --storage-class STORAGE_CLASS

    예제

    [root@rgw /]# radosgw-admin zonegroup placement add  --rgw-zonegroup default --placement-id default-placement --storage-class hot.test
    {
            "key": "default-placement",
            "val": {
                "name": "default-placement",
                "tags": [],
                "storage_classes": [
                    "STANDARD",
                    "hot.test"
                ]
            }
        }

  3. 새 스토리지 클래스의 영역 배치 정보를 제공합니다.

    구문

    radosgw-admin zone placement add --rgw-zone default --placement-id PLACEMENT_TARGET --storage-class STORAGE_CLASS --data-pool DATA_POOL

    예제

    [root@rgw /]# radosgw-admin zone placement add --rgw-zone default --placement-id default-placement --storage-class hot.test --data-pool test.hot.data
    {
               "key": "default-placement",
               "val": {
                   "index_pool": "test_zone.rgw.buckets.index",
                   "storage_classes": {
                       "STANDARD": {
                           "data_pool": "test.hot.data"
                       },
                       "hot.test": {
                           "data_pool": "test.hot.data",
                      }
                   },
                   "data_extra_pool": "",
                   "index_type": 0
               }

    참고

    쓰기를 한 번 사용하여 cold 또는 archival 데이터 스토리지 풀을 만들 때 compression_type 을 설정하는 것이 좋습니다.

  4. 데이터 풀에서 rgw 애플리케이션을 활성화합니다.

    구문

    ceph osd pool application enable POOL_NAME rgw

    예제

    [root@rgw /] ceph osd pool application enable test.hot.data rgw
    enabled application 'rgw' on pool 'test.hot.data'

  5. 모든 rgw 데몬을 다시 시작합니다.
  6. 버킷을 생성합니다.

    예제

    [root@rgw /]# aws s3api create-bucket --bucket testbucket10 --create-bucket-configuration LocationConstraint=default:default-placement --endpoint-url http://1x.7x.2xx.1xx:80

  7. 오브젝트를 추가합니다.

    예제

    [root@rgw /]#aws --endpoint=http://1x.7x.2xx.1xx:80 s3api put-object --bucket testbucket10  --key compliance-upload --body /root/test2.txt

  8. 두 번째 데이터 풀을 생성합니다.

    구문

    ceph osd pool create POOL_NAME

    예제

    [root@rgw /]# ceph osd pool create test.cold.data

  9. 새 스토리지 클래스를 추가합니다.

    구문

    radosgw-admin zonegroup placement add  --rgw-zonegroup default --placement-id PLACEMENT_TARGET --storage-class STORAGE_CLASS

    예제

    [root@rgw /]# radosgw-admin zonegroup placement add  --rgw-zonegroup default --placement-id default-placement --storage-class cold.test
    {
            "key": "default-placement",
            "val": {
                "name": "default-placement",
                "tags": [],
                "storage_classes": [
                    "STANDARD",
                    "cold.test"
                ]
            }
        }

  10. 새 스토리지 클래스의 영역 배치 정보를 제공합니다.

    구문

    radosgw-admin zone placement add --rgw-zone default --placement-id PLACEMENT_TARGET --storage-class STORAGE_CLASS --data-pool DATA_POOL

    예제

    [root@rgw /]# radosgw-admin zone placement add --rgw-zone default --placement-id default-placement --storage-class cold.test --data-pool test.cold.data

  11. 데이터 풀에서 rgw 애플리케이션을 활성화합니다.

    구문

    ceph osd pool application enable POOL_NAME rgw

    예제

    [root@rgw /] ceph osd pool application enable test.cold.data rgw
    enabled application 'rgw' on pool 'test.cold.data'

  12. 모든 rgw 데몬을 다시 시작합니다.
  13. 영역 그룹 구성을 보려면 다음을 실행합니다.

    구문

    radosgw-admin zonegroup get
    {
        "id": "3019de59-ddde-4c5c-b532-7cdd29de09a1",
        "name": "default",
        "api_name": "default",
        "is_master": "true",
        "endpoints": [],
        "hostnames": [],
        "hostnames_s3website": [],
        "master_zone": "adacbe1b-02b4-41b8-b11d-0d505b442ed4",
        "zones": [
            {
                "id": "adacbe1b-02b4-41b8-b11d-0d505b442ed4",
                "name": "default",
                "endpoints": [],
                "log_meta": "false",
                "log_data": "false",
                "bucket_index_max_shards": 11,
                "read_only": "false",
                "tier_type": "",
                "sync_from_all": "true",
                "sync_from": [],
                "redirect_zone": ""
            }
        ],
        "placement_targets": [
            {
                "name": "default-placement",
                "tags": [],
                "storage_classes": [
                    "hot.test",
                    "cold.test",
                    "STANDARD"
                ]
            }
        ],
        "default_placement": "default-placement",
        "realm_id": "",
        "sync_policy": {
            "groups": []
        }
    }

  14. 영역 구성을 보려면 다음을 실행합니다.

    구문

    radosgw-admin zone get
    {
        "id": "adacbe1b-02b4-41b8-b11d-0d505b442ed4",
        "name": "default",
        "domain_root": "default.rgw.meta:root",
        "control_pool": "default.rgw.control",
        "gc_pool": "default.rgw.log:gc",
        "lc_pool": "default.rgw.log:lc",
        "log_pool": "default.rgw.log",
        "intent_log_pool": "default.rgw.log:intent",
        "usage_log_pool": "default.rgw.log:usage",
        "roles_pool": "default.rgw.meta:roles",
        "reshard_pool": "default.rgw.log:reshard",
        "user_keys_pool": "default.rgw.meta:users.keys",
        "user_email_pool": "default.rgw.meta:users.email",
        "user_swift_pool": "default.rgw.meta:users.swift",
        "user_uid_pool": "default.rgw.meta:users.uid",
        "otp_pool": "default.rgw.otp",
        "system_key": {
            "access_key": "",
            "secret_key": ""
        },
        "placement_pools": [
            {
                "key": "default-placement",
                "val": {
                    "index_pool": "default.rgw.buckets.index",
                    "storage_classes": {
                        "cold.test": {
                            "data_pool": "test.cold.data"
                        },
                        "hot.test": {
                            "data_pool": "test.hot.data"
                        },
                        "STANDARD": {
                            "data_pool": "default.rgw.buckets.data"
                        }
                    },
                    "data_extra_pool": "default.rgw.buckets.non-ec",
                    "index_type": 0
                }
            }
        ],
        "realm_id": "",
        "notif_pool": "default.rgw.log:notif"
    }

  15. 버킷을 생성합니다.

    예제

    [root@rgw /]# aws s3api create-bucket --bucket testbucket10 --create-bucket-configuration LocationConstraint=default:default-placement --endpoint-url http://1x.7x.2xx.1xx:80

  16. 라이프사이클 구성에 사용할 JSON 파일을 생성합니다.

    예제

    [root@rgw ~]# vi lifecycle.json

  17. 파일에 특정 라이프사이클 구성 규칙을 추가합니다.

    예제

    {
        "Rules": [
            {
                "Filter": {
                    "Prefix": ""
                },
                "Status": "Enabled",
                "Transitions": [
                    {
                        "Days": 5,
                        "StorageClass": "hot.test"
                    },
     {
                        "Days": 20,
                        "StorageClass": "cold.test"
                    }
                ],
                "Expiration": {
                    "Days": 365
                },
                "ID": "double transition and expiration"
            }
        ]
    }

    라이프사이클 구성 예제에서는 기본 STANDARD 스토리지 클래스에서 5일 후에 hot.test 스토리지 클래스로 전환되는 오브젝트를 보여주며 20일 후에 cold.test 스토리지 클래스로 다시 전환되며, 마지막으로 cold.test 스토리지 클래스에서 365일 후에 만료됩니다.

  18. 버킷에서 라이프사이클 구성을 설정합니다.

    예제

    [root@rgw-2 ~] aws s3api put-bucket-lifecycle-configuration --bucket testbucket20 --lifecycle-configuration file://lifecycle.json

  19. 버킷에서 라이프사이클 구성을 검색합니다.

    예제

    [root@rgw ~]aws s3api get-bucket-lifecycle-configuration --bucket testbucket20
    {
        "Rules": [
            {
                "Expiration": {
                    "Days": 365
                },
                "ID": "double transition and expiration",
                "Prefix": "",
                "Status": "Enabled",
                "Transitions": [
                    {
                        "Days": 20,
                        "StorageClass": "cold.test"
                    },
                    {
                        "Days": 5,
                        "StorageClass": "hot.test"
                    }
                ]
            }
        ]
    }

추가 리소스

7.10. 사용법

Ceph Object Gateway는 각 사용자의 사용량을 기록합니다. 날짜 범위 내에서 사용자 사용량도 추적할 수 있습니다.

옵션은 다음과 같습니다.

  • 시작 날짜: start -date 옵션을 사용하면 특정 시작 날짜(형식: yyyy-mm-dd[HH:MM:SS] )에서 사용 통계를 필터링할 수 있습니다.
  • 종료 날짜: end-date 옵션을 사용하면 특정 날짜까지 사용량을 필터링할 수 있습니다(형식: y yy-mm-dd[HH:MM:SS]).
  • 로그 항목: show-log-entries 옵션을 사용하면 사용 통계를 사용하여 로그 항목을 포함할지 여부를 지정할 수 있습니다(옵션: true | false옵션).
참고

몇 분 및 초로 시간을 지정할 수 있지만 1시간 해상도로 저장됩니다.

7.10.1. 사용량 표시

사용량 통계를 표시하려면 사용량을 show 로 지정합니다. 특정 사용자의 사용량을 표시하려면 사용자 ID를 지정해야 합니다. 시작 날짜, 종료 날짜 및 로그 항목을 표시할지 여부를 지정할 수도 있습니다.

# radosgw-admin usage show \
                --uid=johndoe --start-date=2012-03-01 \
                --end-date=2012-04-01

사용자 ID를 생략하여 모든 사용자에 대한 사용 정보에 대한 요약을 표시할 수도 있습니다.

# radosgw-admin usage show --show-log-entries=false

7.10.2. Trim 사용

사용량 로그가 과도하게 사용되면서 스토리지 공간 확보가 시작될 수 있습니다. 모든 사용자와 특정 사용자의 사용 로그를 트리밍할 수 있습니다. 트리밍 작업에 대한 날짜 범위를 지정할 수도 있습니다.

[root@master-zone]# radosgw-admin usage trim --start-date=2010-01-01 \
                    --end-date=2010-12-31

[root@master-zone]# radosgw-admin usage trim --uid=johndoe
[root@master-zone]# radosgw-admin usage trim --uid=johndoe --end-date=2013-12-31

7.11. Ceph Object Gateway의 가비지 컬렉션 최적화

새 데이터 오브젝트가 스토리지 클러스터에 작성되면 Ceph Object Gateway에서 이러한 새 오브젝트에 즉시 스토리지를 할당합니다. 스토리지 클러스터에서 데이터 오브젝트를 삭제하거나 덮어쓰면 Ceph Object Gateway가 버킷 인덱스에서 해당 오브젝트를 삭제합니다. 나중에 Ceph Object Gateway는 스토리지 클러스터에 오브젝트를 저장하는 데 사용된 공간을 제거합니다. 스토리지 클러스터에서 삭제된 오브젝트 데이터를 제거하는 프로세스를 Garbage Collection 또는 GC라고 합니다.

가비지 컬렉션 작업은 일반적으로 백그라운드에서 실행됩니다. 이러한 작업은 지속적으로 실행하거나 활동이 적고 워크로드가 적은 간격 동안만 실행되도록 구성할 수 있습니다. 기본적으로 Ceph Object Gateway는 GC 작업을 지속적으로 수행합니다. GC 작업은 Ceph Object Gateway 작업의 일반적인 일부이므로 가비지 컬렉션에 적합한 삭제된 오브젝트가 대부분 존재합니다.

7.11.1. 가비지 컬렉션 큐 보기

스토리지 클러스터에서 삭제 및 덮어쓰기 오브젝트를 제거하기 전에 radosgw-admin 을 사용하여 가비지 컬렉션을 기다리는 오브젝트를 확인합니다.

사전 요구 사항

  • 실행 중인 Red Hat Ceph Storage 클러스터.
  • Ceph 개체 게이트웨이에 대한 루트 수준 액세스.

절차

  1. 가비지 컬렉션을 기다리는 개체의 큐를 보려면 다음을 수행합니다.

    예제

    [root@rgw ~] radosgw-admin gc list

참고

만료되지 않은 항목을 포함하여 큐의 모든 항목을 나열하려면 --include-all 옵션을 사용합니다.

7.11.2. Garbage 컬렉션 설정 조정

Ceph Object Gateway는 새로 작성한 오브젝트와 덮어쓰는 오브젝트에 즉시 스토리지를 할당합니다. 또한 다중 파트 업로드의 일부는 일부 스토리지도 사용합니다.

버킷 인덱스에서 오브젝트를 삭제한 후 Ceph Object Gateway는 삭제된 오브젝트에 사용된 스토리지 공간을 제거합니다. 마찬가지로 Ceph Object Gateway는 다중 파트 업로드가 완료된 후 또는 업로드가 비활성화되었거나 구성 가능한 시간 동안 완료되지 않은 경우 다중 파트 업로드와 연관된 데이터를 삭제합니다. Red Hat Ceph Storage 클러스터에서 삭제된 개체 데이터를 제거하는 프로세스를 GC(가비지 컬렉션)라고 합니다.

가비지 컬렉션을 기다리는 오브젝트는 다음 명령을 사용하여 수행할 수 있습니다.

radosgw-admin gc list

가비지 컬렉션은 스토리지 관리자가 Ceph 개체 게이트웨이를 구성하는 방법에 따라 지속적으로 또는 낮은 로드 시간에 실행되는 백그라운드 활동입니다. 기본적으로 Ceph Object Gateway는 가비지 컬렉션 작업을 지속적으로 수행합니다. 가비지 컬렉션 작업은 특히 개체 삭제 작업에서 Ceph 개체 게이트웨이의 일반적인 기능이므로 대부분의 경우 가비지 컬렉션에 적합한 개체가 있습니다.

일부 워크로드는 가비지 컬렉션 활동의 속도를 일시적으로 또는 영구적으로 초과할 수 있습니다. 이는 특히 많은 오브젝트가 짧은 기간 동안 저장되고 삭제되는 삭제가 많은 워크로드에 적용됩니다. 이러한 유형의 워크로드의 경우 스토리지 관리자는 다음 구성 매개 변수를 사용하여 다른 작업을 기준으로 가비지 수집 작업의 우선 순위를 늘릴 수 있습니다.

  • rgw_gc_obj_min_wait 구성 옵션은 삭제된 오브젝트의 데이터를 제거하기 전에 최소 시간(초)을 기다립니다. 기본값은 2시간 또는 7200초입니다. 클라이언트가 오브젝트를 읽을 수 있기 때문에 개체가 즉시 제거되지 않습니다. 많은 워크로드를 삭제하면 이 설정이 너무 많은 스토리지를 사용하거나 제거할 오브젝트 수가 많을 수 있습니다. Red Hat은 이 값을 30분 이하 또는 1800초 미만으로 설정하지 않는 것이 좋습니다.
  • rgw_gc_processor_period 구성 옵션은 가비지 컬렉션 사이클 런타임입니다. 즉 가비지 컬렉션 스레드의 연속 실행 사이의 시간입니다. 가비지 컬렉션이 이 기간보다 오래 실행되는 경우 Ceph Object Gateway는 가비지 컬렉션 주기를 다시 실행하기 전에 기다리지 않습니다.
  • rgw_gc_max_concurrent_io 구성 옵션은 게이트웨이 가비지 컬렉션 스레드에서 삭제된 데이터를 삭제할 때 사용할 최대 동시 IO 작업 수를 지정합니다. 많은 워크로드를 삭제하면 이 설정을 다수의 동시 IO 작업으로 늘리는 것이 좋습니다.
  • rgw_gc_max_trim_chunk 구성 옵션은 단일 작업에서 가비지 컬렉터 로그에서 제거할 최대 키 수를 지정합니다. 삭제에 따른 작업에서 각 가비지 수집 작업 중에 더 많은 오브젝트가 제거되도록 최대 키 수를 늘리는 것이 좋습니다.

Red Hat Ceph Storage 4.1부터 가비지 컬렉션 로그에서 인덱스 오브젝트의AP를 해제하면 스토리지 클러스터에서 가비지 수집 작업의 성능에 미치는 영향을 줄일 수 있습니다. 다음과 같이 몇 가지 새로운 구성 매개 변수가 Ceph Object Gateway에 추가되어 가비지 컬렉션 큐를 조정합니다.

  • rgw_gc_max_deferred_entries_size 구성 옵션은 가비지 컬렉션 큐에서 지연된 항목의 최대 크기를 설정합니다.
  • rgw_gc_max_queue_size 구성 옵션은 가비지 컬렉션에 사용되는 최대 큐 크기를 설정합니다. 이 값은 osd_max_object_size - rgw_ gc_max_deferred_entries_size - 1KB보다 크지 않아야 합니다.
  • rgw_gc_max_deferred 구성 옵션은 가비지 컬렉션 큐에 저장된 지연된 최대 항목 수를 설정합니다.
참고

이러한 가비지 컬렉션 구성 매개 변수는 Red Hat Ceph Storage 5 이상용입니다.

참고

테스트에서 50% 삭제 및 50% 쓰기 작업과 같이 균등하게 균형을 맞추는 삭제-쓰기 워크로드가 있는 경우 스토리지 클러스터는 11시간으로 완전히 채워집니다. 이는 Ceph Object Gateway 가비지 컬렉션이 삭제 작업에 보조를 맞추지 못하기 때문입니다. 이 경우 클러스터 상태가 HEALTH_ERR 상태로 전환됩니다. 병렬 가비지 컬렉션 튜닝 가능 항목에 대한 공격적인 설정은 스토리지 클러스터의 시작 부분을 크게 지연시키고 많은 워크로드에 도움이 될 수 있습니다. 일반적인 실제 스토리지 클러스터 워크로드는 주로 가비지 컬렉션으로 인해 스토리지 클러스터 채우기를 유발할 가능성이 낮습니다.

7.11.3. 삭제가 많은 워크로드의 가비지 컬렉션 조정

일부 워크로드는 가비지 컬렉션 활동의 속도를 일시적으로 또는 영구적으로 초과할 수 있습니다. 이는 특히 많은 오브젝트가 짧은 기간 동안 저장되고 삭제되는 삭제가 많은 워크로드에 적용됩니다. 이러한 유형의 워크로드의 경우 다른 작업을 기준으로 가비지 컬렉션 작업의 우선 순위를 늘리는 것이 좋습니다. Ceph Object Gateway Garbage Collection에 대한 추가 질문은 Red Hat 지원팀에 문의하십시오.

사전 요구 사항

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

절차

  1. rgw_gc_max_concurrent_io 의 값을 20 으로 설정하고 rgw_gc_max_trim_chunk 값을 64 로 설정합니다.

    예제

    [root@mon ~]# ceph config set client.rgw rgw_gc_max_concurrent_io 20
    [root@mon ~]# ceph config set client.rgw rgw_gc_max_trim_chunk 64

  2. Ceph Object Gateway를 다시 시작하여 변경된 설정을 적용할 수 있습니다.
  3. GC 활동 중에 스토리지 클러스터를 모니터링하여 증가된 값이 성능에 부정적인 영향을 미치지 않는지 확인합니다.
중요

실행 중인 클러스터에서 rgw_gc_max_objs 옵션의 값을 수정하지 마십시오. RGW 노드를 배포하기 전에 이 값을 변경해야 합니다.

7.12. Ceph Object Gateway의 데이터 개체 스토리지 최적화

버킷 라이프사이클 구성은 데이터 개체 스토리지를 최적화하여 효율성을 높이고 데이터의 수명 동안 효과적인 스토리지를 제공합니다.

Ceph Object Gateway의 S3 API는 현재 AWS 버킷 라이프 사이클 구성 작업의 하위 집합을 지원합니다.

  • 만료
  • NoncurrentVersionExpiration
  • AbortIncompleteMultipartUpload

사전 요구 사항

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

7.12.1. 버킷 라이프 사이클을 위한 병렬 스레드 처리

Ceph Object Gateway를 사용하면 여러 Ceph Object Gateway 인스턴스에서 버킷 라이프사이클의 병렬 스레드 처리를 수행할 수 있습니다. 병렬로 실행되는 스레드 수를 늘리면 Ceph Object Gateway에서 대규모 워크로드를 보다 효율적으로 처리할 수 있습니다. 또한 Ceph Object Gateway는 in-order 번호를 사용하는 대신 인덱스 shard 열거에 숫자 시퀀스를 사용합니다.

7.12.2. 버킷 라이프사이클 최적화

Ceph 구성 파일의 두 가지 옵션은 버킷 라이프사이클 처리 효율성에 영향을 줍니다.

  • rgw_lc_max_worker 은 병렬로 실행할 라이프사이클 작업자 스레드 수를 지정합니다. 이를 통해 버킷 및 인덱스 샤드를 동시에 처리할 수 있습니다. 이 옵션의 기본값은 3입니다.
  • rgw_lc_max_wp_worker 은 각 라이프사이클 작업자 스레드의 작업 풀에 있는 스레드 수를 지정합니다. 이 옵션은 각 버킷의 처리를 가속화하는 데 도움이 됩니다. 이 옵션의 기본값은 3입니다.

많은 버킷이 있는 워크로드의 경우, 예를 들어 수천 개의 버킷이 있는 워크로드는 rgw_lc_max_worker 옵션 값을 늘립니다.

버킷 수가 적지만 각 버킷에 더 많은 오브젝트 수가 있는 워크로드의 경우(예: rgw_lc_max_wp_worker 옵션 값을 늘리는 수만).

참고

이러한 옵션 중 가치를 높이기 전에 현재 스토리지 클러스터 성능과 Ceph Object Gateway 활용도를 검증하십시오. 이 옵션 중 하나에 대해 값을 10개 이상 할당하는 것은 권장되지 않습니다.

사전 요구 사항

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

절차

  1. 병렬로 실행할 스레드 수를 늘리려면 rgw_lc_max_worker 값을 3 에서 9 사이의 값으로 설정합니다.

    예제

    [root@mon ~]# ceph config set client.rgw rgw_lc_max_worker 7

  2. 각 스레드의 작업 풀의 스레드 수를 늘리려면 rgw_lc_max_wp_worker 값을 3 에서 9 사이의 값으로 설정합니다.

    예제

    [root@mon ~]# ceph config set client.rgw rgw_lc_max_wp_worker 7

  3. Ceph Object Gateway를 다시 시작하여 변경된 설정을 적용할 수 있습니다.
  4. 스토리지 클러스터를 모니터링하여 증가한 값이 성능에 부정적인 영향을 미치지 않는지 확인합니다.

추가 리소스

7.12.3. 추가 리소스

8장. 테스트

스토리지 관리자는 기본 기능 테스트를 수행하여 Ceph Object Gateway 환경이 예상대로 작동하는지 확인할 수 있습니다. S3 인터페이스에 대한 초기 Ceph Object Gateway 사용자를 만든 다음 Swift 인터페이스에 대한 하위 사용자를 만들어 REST 인터페이스를 사용할 수 있습니다.

8.1. 사전 요구 사항

  • 정상적으로 실행 중인 Red Hat Ceph Storage 클러스터.
  • Ceph Object Gateway 소프트웨어 설치.

8.2. S3 사용자 만들기

게이트웨이를 테스트하려면 S3 사용자를 만들고 사용자에게 액세스 권한을 부여합니다. man radosgw-admin 명령은 추가 명령 옵션에 대한 정보를 제공합니다.

참고

다중 사이트 배포에서 master 영역 그룹의 마스터 영역에 항상 호스트에 사용자를 생성합니다.

사전 요구 사항

  • root 또는 sudo 액세스
  • Ceph Object Gateway 설치

절차

  1. S3 사용자를 생성합니다.

    radosgw-admin user create --uid=name --display-name="First User"

    name 을 S3 사용자의 이름으로 바꿉니다. 예를 들면 다음과 같습니다.

    [root@master-zone]# radosgw-admin user create --uid="testuser" --display-name="First User"
    {
        "user_id": "testuser",
        "display_name": "First User",
        "email": "",
        "suspended": 0,
        "max_buckets": 1000,
        "auid": 0,
        "subusers": [],
        "keys": [
            {
                "user": "testuser",
                "access_key": "CEP28KDIQXBKU4M15PDC",
                "secret_key": "MARoio8HFc8JxhEilES3dKFVj8tV3NOOYymihTLO"
            }
        ],
        "swift_keys": [],
        "caps": [],
        "op_mask": "read, write, delete",
        "default_placement": "",
        "placement_tags": [],
        "bucket_quota": {
            "enabled": false,
            "check_on_raw": false,
            "max_size": -1,
            "max_size_kb": 0,
            "max_objects": -1
        },
        "user_quota": {
            "enabled": false,
            "check_on_raw": false,
            "max_size": -1,
            "max_size_kb": 0,
            "max_objects": -1
        },
        "temp_url_keys": [],
        "type": "rgw"
    }
  2. 출력을 확인하여 access_key 및 secret_key 값에 JSON 이스케이프 문자(\)가 포함되지 않도록합니다. 이러한 값은 액세스 검증에 필요하지만 값에 JSON 이스케이프 문자가 포함된 경우 특정 클라이언트는 처리할 수 없습니다. 이 문제를 해결하려면 다음 작업 중 하나를 수행하십시오.

    • JSON 이스케이프 문자를 제거합니다.
    • 문자열을 따옴표로 캡슐화합니다.
    • 키를 다시 생성하고 에 JSON 이스케이프 문자가 포함되지 않도록 합니다.
    • 키와 시크릿을 수동으로 지정합니다.

    유효한 문자이므로 슬래시 / 를 제거하지 마십시오.

8.3. Swift 사용자 만들기

Swift 인터페이스를 테스트하려면 Swift 하위 사용자를 만듭니다. Swift 사용자를 만드는 작업은 두 단계로 이루어진 프로세스입니다. 첫 번째 단계는 사용자를 만드는 것입니다. 두 번째 단계는 비밀 키를 생성하는 것입니다.

참고

다중 사이트 배포에서 master 영역 그룹의 마스터 영역에 항상 호스트에 사용자를 생성합니다.

사전 요구 사항

  • Ceph 개체 게이트웨이 설치.
  • Ceph Object Gateway 노드에 대한 루트 수준 액세스.

절차

  1. Swift 사용자를 만듭니다.

    구문

    radosgw-admin subuser create --uid=NAME --subuser=NAME:swift --access=full

    NAME 을 Swift 사용자 이름으로 바꿉니다. 예를 들면 다음과 같습니다.

    예제

    [root@rgw]# radosgw-admin subuser create --uid=testuser --subuser=testuser:swift --access=full
    {
        "user_id": "testuser",
        "display_name": "First User",
        "email": "",
        "suspended": 0,
        "max_buckets": 1000,
        "auid": 0,
        "subusers": [
            {
                "id": "testuser:swift",
                "permissions": "full-control"
            }
        ],
        "keys": [
            {
                "user": "testuser",
                "access_key": "O8JDE41XMI74O185EHKD",
                "secret_key": "i4Au2yxG5wtr1JK01mI8kjJPM93HNAoVWOSTdJd6"
            }
        ],
        "swift_keys": [
            {
                "user": "testuser:swift",
                "secret_key": "13TLtdEW7bCqgttQgPzxFxziu0AgabtOc6vM8DLA"
            }
        ],
        "caps": [],
        "op_mask": "read, write, delete",
        "default_placement": "",
        "placement_tags": [],
        "bucket_quota": {
            "enabled": false,
            "check_on_raw": false,
            "max_size": -1,
            "max_size_kb": 0,
            "max_objects": -1
        },
        "user_quota": {
            "enabled": false,
            "check_on_raw": false,
            "max_size": -1,
            "max_size_kb": 0,
            "max_objects": -1
        },
        "temp_url_keys": [],
        "type": "rgw"
    }

  2. 시크릿 키를 생성합니다.

    구문

    radosgw-admin key create --subuser=NAME:swift --key-type=swift --gen-secret

    NAME 을 Swift 사용자 이름으로 바꿉니다. 예를 들면 다음과 같습니다.

    예제

    [root@rgw]# radosgw-admin key create --subuser=testuser:swift --key-type=swift --gen-secret
    {
        "user_id": "testuser",
        "display_name": "First User",
        "email": "",
        "suspended": 0,
        "max_buckets": 1000,
        "auid": 0,
        "subusers": [
            {
                "id": "testuser:swift",
                "permissions": "full-control"
            }
        ],
        "keys": [
            {
                "user": "testuser",
                "access_key": "O8JDE41XMI74O185EHKD",
                "secret_key": "i4Au2yxG5wtr1JK01mI8kjJPM93HNAoVWOSTdJd6"
            }
        ],
        "swift_keys": [
            {
                "user": "testuser:swift",
                "secret_key": "a4ioT4jEP653CDcdU8p4OuhruwABBRZmyNUbnSSt"
            }
        ],
        "caps": [],
        "op_mask": "read, write, delete",
        "default_placement": "",
        "placement_tags": [],
        "bucket_quota": {
            "enabled": false,
            "check_on_raw": false,
            "max_size": -1,
            "max_size_kb": 0,
            "max_objects": -1
        },
        "user_quota": {
            "enabled": false,
            "check_on_raw": false,
            "max_size": -1,
            "max_size_kb": 0,
            "max_objects": -1
        },
        "temp_url_keys": [],
        "type": "rgw"
    }

8.4. S3 액세스 테스트

S3 액세스를 확인하기 위해 Python 테스트 스크립트를 작성하고 실행해야 합니다. S3 액세스 테스트 스크립트는 radosgw 에 연결하고 새 버킷을 생성하고 모든 버킷을 나열합니다. aws_access_key_idaws_secret_access_key 의 값은 radosgw _admin 명령에서 반환한 access _key 및 secret _ key 값에서 가져옵니다.

사전 요구 사항

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

절차

  1. Red Hat Enterprise Linux 8의 High Availability 리포지토리를 활성화합니다.

    subscription-manager repos --enable=rhel-8-for-x86_64-highavailability-rpms
  2. python3-boto3 패키지를 설치합니다.

    dnf install python3-boto3
  3. Python 스크립트를 생성합니다.

    vi s3test.py
  4. 파일에 다음 내용을 추가합니다.

    구문

    import boto3
    
    endpoint = "" # enter the endpoint URL along with the port "http://URL:_PORT_"
    
    access_key = 'ACCESS'
    secret_key = 'SECRET'
    
    s3 = boto3.client(
            's3',
            endpoint_url=endpoint,
            aws_access_key_id=access_key,
            aws_secret_access_key=secret_key
            )
    
    s3.create_bucket(Bucket='my-new-bucket')
    
    response = s3.list_buckets()
    for bucket in response['Buckets']:
        print("{name}\t{created}".format(
    		name = bucket['Name'],
    		created = bucket['CreationDate']
    ))

    1. ZONE 을 게이트웨이 서비스를 구성한 호스트의 영역 이름으로 바꿉니다. 즉 게이트웨이 호스트입니다. host'setting이 DNS로 확인되는지 확인합니다. PORT 을 게이트웨이의 포트 번호로 바꿉니다.
    2. ACCESSSECRETRed Hat Ceph Storage 개체 게이트웨이 구성 및 관리 가이드의 S3 사용자 만들기 섹션의 access _key secret_key 값으로 바꿉니다.
  5. 스크립트를 실행합니다.

    python3 s3test.py

    출력은 다음과 같습니다.

    my-new-bucket 2021-08-16T17:09:10.000Z

8.5. Swift 액세스 테스트

Swift 액세스는 swift 명령줄 클라이언트를 통해 확인할 수 있습니다. man swift 명령은 사용 가능한 명령줄 옵션에 대한 자세한 정보를 제공합니다.

swift 클라이언트를 설치하려면 다음을 실행합니다.

sudo yum install python-setuptools
sudo easy_install pip
sudo pip install --upgrade setuptools
sudo pip install --upgrade python-swiftclient

swift 액세스를 테스트하려면 다음을 실행합니다.

swift -A http://{IP ADDRESS}:{port}/auth/1.0 -U testuser:swift -K '{swift_secret_key}' list

{IP ADDRESS} 를 게이트웨이 서버의 공용 IP 주소로 바꾸고 {swift_secret_key}swift 사용자에 대해 실행되는 radosgw-admin key create 명령의 값으로 바꿉니다. {port}를 Beast에서 사용 중인 포트 번호로 바꿉니다. 포트를 교체하지 않으면 기본값은 포트 80 입니다.

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

swift -A http://10.19.143.116:80/auth/1.0 -U testuser:swift -K '244+fz2gSqoHwR3lYtSbIyomyPHf3i7rgSJrF/IA' list

출력은 다음과 같아야 합니다.

my-new-bucket

부록 A. 설정 참조

스토리지 관리자는 Ceph Object Gateway에 대한 다양한 옵션을 설정할 수 있습니다. 이러한 옵션에는 기본값이 포함되어 있습니다. 각 옵션을 지정하지 않으면 기본값은 자동으로 설정됩니다.

이러한 옵션에 대한 특정 값을 설정하려면 ceph config set client.rgw OPTION VALUE 명령을 사용하여 구성 데이터베이스를 업데이트합니다.

A.1. 일반 설정

이름설명유형Default

rgw_data

Ceph Object Gateway의 데이터 파일 위치를 설정합니다.

문자열

/var/lib/ceph/radosgw/$cluster-$id

rgw_enable_apis

지정된 API를 활성화합니다.

문자열

s3, s3website, swift, swift_auth, admin, sts, iam, 알림

rgw_cache_enabled

Ceph Object Gateway 캐시가 활성화되었는지 여부.

부울

true

rgw_cache_lru_size

Ceph Object Gateway 캐시의 항목 수입니다.

정수

10000

rgw_socket_path

도메인 소켓의 소켓 경로입니다. FastCgiExternalServer 는 이 소켓을 사용합니다. 소켓 경로를 지정하지 않으면 Ceph Object Gateway가 외부 서버로 실행되지 않습니다. 여기서 지정하는 경로는 rgw.conf 파일에 지정된 경로와 동일해야 합니다.

문자열

해당 없음

rgw_host

Ceph Object Gateway 인스턴스의 호스트입니다. IP 주소 또는 호스트 이름이 될 수 있습니다.

문자열

0.0.0.0

rgw_port

인스턴스가 요청을 수신 대기하는 포트입니다. 지정하지 않으면 Ceph Object Gateway가 외부 FastCGI를 실행합니다.

문자열

없음

rgw_dns_name

제공된 도메인의 DNS 이름입니다. 영역 그룹 내에서 hostnames 설정도 참조하십시오.

문자열

없음

rgw_script_uri

요청에 설정되지 않은 경우 SCRIPT_URI 의 대체 값입니다.

문자열

없음

rgw_request_uri

요청에 설정되지 않은 경우 REQUEST_URI 의 대체 값입니다.

문자열

없음

rgw_print_continue

작동 중인 경우 100-continue 를 활성화합니다.

부울

true

rgw_remote_addr_param

원격 address 매개 변수. 예를 들어 원격 주소를 포함하는 HTTP 필드 또는 역방향 프록시가 작동하는 경우 X-Forwarded-For 주소가 사용됩니다.

문자열

REMOTE_ADDR

rgw_op_thread_timeout

열린 스레드의 시간 제한(초)입니다.

정수

600

rgw_op_thread_suicide_timeout

Ceph Object Gateway 프로세스가 종료되기 전의 시간 제한 (초)입니다. 0으로 설정하면 비활성화됩니다.

정수

0

rgw_thread_pool_size

스레드 풀의 크기입니다.

정수

512 스레드.

rgw_num_control_oids

다양한 rgw 인스턴스 간의 캐시 동기화에 사용되는 알림 개체 수입니다.

정수

8

rgw_init_timeout

Ceph Object Gateway가 초기화 시 종료되는 시간(초)입니다.

정수

30

rgw_mime_types_file

MIME 유형의 경로 및 위치입니다. 오브젝트 유형의 Swift 자동 감지에 사용됩니다.

문자열

/etc/mime.types

rgw_gc_max_objs

하나의 가비지 컬렉션 처리 주기에서 가비지 컬렉션에서 처리할 수 있는 최대 개체 수입니다.

정수

32

rgw_gc_obj_min_wait

가비지 컬렉션 처리로 개체를 제거하고 처리할 수 있는 최소 대기 시간입니다.

정수

2 * 3600

rgw_gc_processor_max_time

연속된 가비지 컬렉션 처리 주기의 시작 시간 최대 시간입니다.

정수

3600

rgw_gc_processor_period

가비지 컬렉션 처리를 위한 사이클 시간입니다.

정수

3600

rgw_s3 success_create_obj_status

create-obj 의 대체 성공 상태 응답입니다.

정수

0

rgw_resolve_cname

rgw 가 요청 호스트 이름 필드의 DNS CNAME 레코드를 사용해야 하는지 여부(호스트 이름이 rgw_dns 이름과동일하지 않은 경우).

부울

false

rgw_object_stripe_size

Ceph Object Gateway 오브젝트의 오브젝트 스트라이프 크기입니다.

정수

4 << 20

rgw_extended_http_attrs

개체에 설정할 수 있는 새 속성 세트를 추가합니다. 이러한 추가 속성은 오브젝트를 배치할 때 HTTP 헤더 필드를 통해 설정할 수 있습니다. 설정된 경우 오브젝트에서 GET/HEAD를 수행할 때 이러한 속성이 HTTP 필드로 반환됩니다.

문자열

없음. 예: "content_foo, content_bar"

rgw_exit_timeout_secs

무조건 종료하기 전에 프로세스 대기 시간(초)입니다.

정수

120

rgw_get_obj_window_size

단일 개체 요청에 대한 창 크기(바이트)입니다.

정수

16 << 20

rgw_get_obj_max_req_size

Ceph Storage 클러스터에 전송된 단일 get 작업의 최대 요청 크기입니다.

정수

4 << 20

rgw_relaxed_s3_bucket_names

영역 그룹 버킷에 대해 완화된 S3 버킷 규칙을 활성화합니다.

부울

false

rgw_list buckets_max_chunk

사용자 버킷을 나열할 때 단일 작업에서 검색할 최대 버킷 수입니다.

정수

1000

rgw_override_bucket_index_max_shards

버킷 인덱스 오브젝트의 shard 수입니다. 값 0 은 분할이 없음을 나타냅니다. 버킷 목록 비용이 증가하므로 너무 큰 값을 설정하지 않는 것이 좋습니다(예: 1000).

radosgw-admin 명령에 자동으로 적용되도록 이 변수는 [client] 또는 [global] 섹션에 설정해야 합니다.

정수

0

rgw_curl_wait_timeout_ms

특정 curl 호출에 대한 시간 제한(밀리초)입니다.

정수

1000

rgw_copy_obj_progress

긴 복사 작업 중에 오브젝트 진행 상황을 활성화합니다.

부울

true

rgw_copy_obj_progress_every_bytes

복사 진행률 출력 사이의 최소 바이트입니다.

정수

1024 * 1024

rgw_admin_entry

관리자 요청 URL의 진입점입니다.

문자열

admin

rgw_content_length_compat

CONTENT_LENGTH 및 HTTP_CONTENT_LENGTH 세트를 사용하여 FCGI 요청의 호환성 처리를 활성화합니다.

부울

false

rgw_bucket_default_quota_max_objects

버킷당 기본 최대 오브젝트 수입니다. 이 값은 다른 할당량이 지정되지 않은 경우 새 사용자에게 설정됩니다. 기존 사용자에게는 영향을 미치지 않습니다.

radosgw-admin 명령에 자동으로 적용되도록 이 변수는 [client] 또는 [global] 섹션에 설정해야 합니다.

정수

-1

rgw_bucket_quota_ttl

캐시된 할당량 정보(초)가 신뢰할 수 있는 시간(초)이 신뢰됩니다. 이 시간 초과 후에는 클러스터에서 할당량 정보를 다시 가져옵니다.

정수

600

rgw_user_quota_bucket_sync_interval

클러스터와 동기화하기 전에 버킷 할당량 정보가 누적되는 시간(초)입니다. 이 기간 동안 다른 RGW 인스턴스는 이 인스턴스의 작업에서 버킷 할당량 통계가 변경되지 않습니다.

정수

180

rgw_user_quota_sync_interval

클러스터와 동기화하기 전에 사용자 할당량 정보가 누적되는 시간(초)입니다. 이 기간 동안 다른 RGW 인스턴스에는 이 인스턴스의 작업에서 사용자 할당량 통계가 변경되지 않습니다.

정수

3600 * 24

A.2. 풀 정보

Ceph 영역은 일련의 Ceph Storage 클러스터 풀에 매핑됩니다.

수동으로 생성된 풀과. 생성된 풀

Ceph Object Gateway의 사용자 키에 쓰기 기능이 포함된 경우 게이트웨이에서 풀을 자동으로 만들 수 있습니다. 이 기능은 시작 시 편리합니다. 그러나 Ceph Object Storage 클러스터에서는 Ceph 구성 파일에 설정되지 않은 한 배치 그룹 기본값을 사용합니다. 또한 Ceph는 기본 CRUSH 계층 구조를 사용합니다. 이러한 설정은 프로덕션 시스템에 적합하지 않습니다.

Ceph Object Gateway의 기본 영역에 대한 기본 풀은 다음과 같습니다.

  • .rgw.root
  • .default.rgw.control
  • .default.rgw.meta
  • .default.rgw.log
  • .default.rgw.buckets.index
  • .default.rgw.buckets.data
  • .default.rgw.buckets.non-ec

Ceph Object Gateway는 영역별로 풀을 생성합니다. 풀을 수동으로 생성하는 경우 영역 이름 앞에 추가합니다. 시스템 풀은 시스템 제어, 로깅, 사용자 정보 등과 관련된 오브젝트를 저장합니다. 관례적으로 이러한 풀 이름에는 풀 이름에 앞에 붙은 영역 이름이 있습니다.

  • .<zone-name>.rgw.control: 제어 풀입니다.
  • .<zone-name>.log: 로그 풀에는 모든 버킷/컨테이너의 로그와 create, read, update, delete 등의 오브젝트 작업이 포함됩니다.
  • .<zone-name>.rgw.buckets.index: 이 풀은 buckes의 인덱스를 저장합니다.
  • .<zone-name>.rgw.buckets.data: 이 풀은 버킷의 데이터를 저장합니다.
  • .<zone-name>.rgw.meta: 메타데이터 풀은 user_keys 및 기타 중요한 메타데이터를 저장합니다.
  • .<zone-name>.meta:users.uid: 사용자 ID 풀에는 고유한 사용자 ID 맵이 포함되어 있습니다.
  • .<zone-name>.meta:users.keys: 키 풀에는 각 사용자 ID에 대한 액세스 키 및 비밀 키가 포함됩니다.
  • .<zone-name>.meta:users.email: 이메일 풀에는 사용자 ID와 연결된 이메일 주소가 포함됩니다.
  • .<zone-name>.meta:users.swift: Swift 풀에는 사용자 ID에 대한 Swift 하위 사용자 정보가 포함되어 있습니다.

Ceph 개체 게이트웨이는 버킷 인덱스(index_pool) 및 버킷 데이터(data_pool)의 데이터를배치 풀에 저장합니다. 이러한 설정이 중복될 수 있습니다. 즉, 인덱스와 데이터에 동일한 풀을 사용할 수 있습니다. 기본 배치를 위한 인덱스 풀은 {zone-name}.rgw.buckets.index 이며 기본 배치를 위한 데이터 풀의 경우 {zone-name}.rgw.buckets 입니다.

이름설명유형Default

rgw_zonegroup_root_pool

모든 영역 그룹별 정보를 저장하는 풀입니다.

문자열

.rgw.root

rgw_zone_root_pool

영역별 정보를 저장하기 위한 풀입니다.

문자열

.rgw.root

A.3. Swift 설정

이름설명유형Default

rgw_enforce_swift_acls

Swift ACL(액세스 제어 목록) 설정을 적용합니다.

부울

true

rgw_swift_token_expiration

Swift 토큰을 만료하는 시간(초)입니다.

정수

24 * 3600

rgw_swift_url

Ceph Object Gateway Swift API의 URL입니다.

문자열

없음

rgw_swift_url_prefix

Swift API의 URL 접두사(예: http://fqdn.com/swift) .

swift

해당 없음

rgw_swift_auth_url

v1 인증 토큰을 확인하기 위한 기본 URL입니다(내부 Swift 인증을 사용하지 않는 경우).

문자열

없음

rgw_swift_auth_entry

Swift 인증 URL의 진입점입니다.

문자열

auth

A.4. 로깅 설정

이름설명유형Default

rgw_log_nonexistent_bucket

Ceph Object Gateway를 통해 존재하지 않는 버킷에 대한 요청을 기록할 수 있습니다.

부울

false

rgw_log_object_name

오브젝트 이름의 로깅 형식입니다. 형식 지정기에 대한 자세한 내용은 manpage 날짜를 참조하십시오.

날짜

%Y-%m-%d-%H-%i-%n

rgw_log_object_name_utc

기록된 개체 이름에 UTC 시간이 포함되어 있는지 여부. false인 경우 로컬 시간을 사용합니다.

부울

false

rgw_usage_max_shards

사용 로깅을 위한 최대 shard 수입니다.

정수

32

rgw_usage_max_user_shards

단일 사용자의 사용 로깅에 사용되는 최대 shard 수입니다.

정수

1

rgw_enable_ops_log

Ceph Object Gateway 작업이 성공할 때마다 로깅을 활성화합니다.

부울

false

rgw_enable_usage_log

사용 로그를 활성화합니다.

부울

false

rgw_ops_log_rados

작업 로그를 Ceph Storage 클러스터 백엔드에 작성할지 여부.

부울

true

rgw_ops_log_socket_path

작업 로그를 작성하는 Unix 도메인 소켓.

문자열

없음

rgw_ops_log_data-backlog

Unix 도메인 소켓에 기록된 작업에 대한 최대 데이터 백로그 데이터 크기입니다.

정수

5 << 20

rgw_usage_log_flush_threshold

동시에 플러시하기 전에 사용 로그에서 더티 병합 항목의 수입니다.

정수

1024

rgw_usage_log_tick_interval

대기 중인 사용 로그 데이터를 n 초마다 플러시합니다.

정수

30

rgw_intent_log_object_name

의도한 로그 오브젝트 이름의 로깅 형식입니다. 형식 지정기에 대한 자세한 내용은 manpage 날짜를 참조하십시오.

날짜

%Y-%m-%d-%i-%n

rgw_intent_log_object_name_utc

의도 로그 오브젝트 이름에 UTC 시간이 포함되어 있는지 여부. false인 경우 로컬 시간을 사용합니다.

부울

false

rgw_data_log_window

데이터 로그 항목(초)입니다.

정수

30

rgw_data_log_changes_size

데이터 변경 로그에 대해 보유할 메모리 내 항목 수입니다.

정수

1000

rgw_data_log_num_shards

데이터 변경 로그를 보관할 shard(개체) 수입니다.

정수

128

rgw_data_log_obj_prefix

데이터 로그의 개체 이름 접두사입니다.

문자열

data_log

rgw_replica_log_obj_prefix

복제본 로그의 오브젝트 이름 접두사입니다.

문자열

복제 로그

rgw_md_log_max_shards

메타데이터 로그의 최대 shard 수입니다.

정수

64

A.5. Keystone 설정

이름설명유형Default

rgw_keystone_url

Keystone 서버의 URL입니다.

문자열

없음

rgw_keystone_admin_token

Keystone 관리 토큰(공유 비밀).

문자열

없음

rgw_keystone_accepted_roles

이 역할은 요청을 처리해야 합니다.

문자열

멤버, admin

rgw_keystone_token_cache_size

각 Keystone 토큰 캐시의 최대 항목 수입니다.

정수

10000

rgw_keystone_revocation_interval

토큰 폐기 검사 간 시간(초)입니다.

정수

15 * 60

A.6. LDAP 설정

이름설명유형예제

rgw_ldap_uri

URI 형식으로 이루어진 LDAP 서버의 공백으로 구분된 목록입니다.

문자열

ldaps://<ldap.your.domain>

rgw_ldap_searchdn

LDAP 검색 도메인 이름(기본 도메인이라고도 함).

문자열

cn=users,cn=accounts,dc=example,dc=com

rgw_ldap_binddn

게이트웨이는 이 LDAP 항목(사용자 일치)과 바인딩됩니다.

문자열

uid=admin,cn=users,dc=example,dc=com

rgw_ldap_secret

rgw_ldap_binddn에 대한 자격 증명이 포함된 파일

문자열

/etc/openldap/secret

rgw_ldap_dnattr

Ceph 개체 게이트웨이 사용자 이름이 포함된 LDAP 속성(Bounddns 형식).

문자열

UID