cephObjectGateway(Feat. bucket 생성)

개요

Ceph Object Gateway(RADOS Gateway, 또는 RGW)는 오픈 소스 스토리지 솔루션인 Ceph의 구성 요소 중 하나로, 오브젝트 스토리지 기능을 제공합니다.

 

Ceph Object Gateway는 HTTP RESTful 인터페이스를 통해 Ceph 클러스터에 데이터를 저장하고 가져올 수 있게 해줍니다.

 

이를 통해 아마존 S3 및 OpenStack Swift와 같은 Api용 인터페이스로 사용되며 오브젝트 스토리지 서비스와의 호환성을 지원합니다.

 

또한 rook-ceph-tools 파드 내부에 접속해 radosgw(CLI) 명령어를 사용해 제어할 수도 있습니다.

 

ceph object는 스토리지 클러스터에 대한 Restful 게이트웨이를 제공하기 위해 주로 사용됩니다.

 

버킷을 생성하기 위해서는 쿠버네티스 CRD를 활용하는 방법과 AWS CLI를 이용하는 방법이 있는데 AWS CLI는 설치와 설정 이후에 사용해야하므로 제외하고 간단하게 쿠버네티스 서버에서 OBC(ObjectBucketClaim) yaml 파일을 생성해 적용하는 방법을 작성했습니다.

 

• yaml파일 설정은 다음과 같이 구성할 수 있습니다.

apiVersion: objectbucket.io/v1alpha1
kind: ObjectBucketClaim
metadata:
  name: test2
spec:
  bucketName: test2
  storageClassName: rook-ceph-bucket-a

이제 kubectl get ob 명령어를 입력하면 생성된 리소스를 확인할 수 있습니다.

 

마찬가지로 kubectl get obc를 통해 bucket을 확인할 수 있습니다.

 

bucket 생성 의문

제가 운영하는 서버에서 test bucket을 미리 생성했습니다.

 

밑에서 설명하게 될 user를 생성하고 난뒤 bucket을 생성하기 위해서는 반드시 bucket이 미리 생성되어 있어야 하기 때문입니다.

 

그런데 제가 사용했던 test bucket은 ob나 obc에서 확인할 수 없었습니다.(ob,obc의 개념은 맨 하단에 있습니다.) 그 이유는 무엇일까요?

 

바로 다음과 같이 버킷을 관리하는 주체가 나누어져 있기 때문입니다.

 

1. Rook-Ceph Tools에서 관리되는 버킷

Rook-Ceph Tools는 Ceph 클러스터를 관리하는 도구로, Ceph의 다양한 기능을 사용할 수 있는 CLI 도구입니다. 이를 통해 직접 Ceph 클러스터와 상호작용하고, 버킷, 유저, 풀 등 다양한 Ceph 리소스를 생성 및 관리할 수 있습니다.

• radosgw-admin 명령어를 사용하여 Ceph Object Gateway (RGW)에서 직접 버킷을 생성하고 관리할 수 있습니다. 예를 들어, radosgw-admin bucket create와 같은 명령어를 사용하여 버킷을 생성하거나 외부로부터 bucket 생성 API를 전달받아 생성할 수 있습니다.

 

2. Kubernetes에서 ObjectBucketClaim (OBC)을 통해 관리되는 버킷

• Kubernetes OBC: OBC는 Kubernetes 리소스로, ObjectBucket (OB)와 함께 사용되어 S3와 같은 객체 스토리지를 Kubernetes 네이티브 방식으로 관리할 수 있게 해줍니다. 이를 통해 개발자는 쿠버네티스 리소스로 버킷을 생성, 관리할 수 있습니다.
• 스토리지 클래스와 OBC: OBC를 생성하면, Rook-Ceph가 백엔드에서 Ceph RGW를 통해 버킷을 생성합니다. OBC와 연관된 스토리지 클래스가 Ceph Rook Operator에 의해 관리되고, 이는 OBC 리소스를 통해 버킷을 생성하고 관리합니다.

 

차이점 및 관계

1. 관리 인터페이스
   • Rook-Ceph Tools: 직접 CLI를 사용하여 Ceph의 모든 기능을 관리.
   • Kubernetes OBC: Kubernetes 리소스 정의를 통해 간접적으로 Ceph Object Gateway를 관리.
2. 사용 용도
   • Rook-Ceph Tools: 주로 클러스터 관리자나 DevOps 팀이 Ceph 클러스터의 전반적인 설정 및 관리 작업을 수행할 때 사용
   • Kubernetes OBC: 개발자가 쿠버네티스 애플리케이션을 배포할 때 객체 스토리지를 쉽게 사용
3. 상호 작용
   • OBC를 통해 생성된 버킷은 Ceph Rook Operator에 의해 Ceph 클러스터 내에서 관리됩니다.
   • radosgw-admin을 통해 생성된 버킷도 Kubernetes OBC와 연관될 수 있으며, 이는 적절한 OBC 및 스토리지 클래스 설정을 통해 가능합니다.

 

요약

• rook-ceph-tools에서 관리되는 버킷은 Ceph CLI를 통해 직접 관리되는 반면, Kubernetes OBC를 통해 관리되는 버킷은 Kubernetes 리소스 정의를 통해 관리됩니다.
• 두 관리 방식은 서로 다른 인터페이스와 용도로 사용되지만, 동일한 Ceph 클러스터 내에서 상호작용할 수 있습니다.
• Kubernetes OBC는 개발자가 객체 스토리지를 쉽게 사용할 수 있게 해주는 반면, rook-ceph-tools는 Ceph 클러스터의 전반적인 설정 및 관리에 사용됩니다.

 

bucket의 차이점에 대한 결론

• 결국 이러한 차이점이 발생하는건 bucket을 생성하고 관리하는 주체가 누구인지에 따라 달라지는 것입니다.
• 하지만 위에서 작성된 것처럼 설정을 통해 동일한 Ceph 클러스터 내에서 상호작용할 수 있으므로 어느곳에서 생성하던 bucket을 사용할 수는 있습니다.
• 제가 사용하는 storage 서버에서는 bucket을 생성하는 로직도 함께 들어있기 때문에 이를 통해(AWS SDK의 도움을 받아) test bucket을 생성하기도 했습니다.

 

bucket과 user 생성

저는 특별한 설정없이 간단하게 ceph-tools 내부에서 버킷을 확인하고 싶었기에 S3 호환 API(AWS SDK)를 사용해 버킷을 생성했습니다.

implementation("com.amazonaws:aws-java-sdk-s3:1.12.153")

• 스프링을 사용하신다면 해당 라이브러리를 설치해 AmazonS3를 사용하면 bucket에 대한 API를 사용할 수 있습니다.
• 이후 createBucket() 메소드를 사용해 괄호안에 bucketName을 전달해주면 rook-ceph-tools 내부에 버킷이 생성됩니다.
• 당연하게도 버킷을 생성하기 위해서는 rook-ceph의 주소를 알고 있어야 합니다. 필자는 쿠버네티스를 사용하기에 Ceph RGW의 엔드포인트 URL을 확인해 연동했습니다.

• 스프링 서버에서 위의 값들을 채워 설정을 하면 되겠습니다.
• 이후 rook-ceph-tools 파드로 접속
• 정상적으로 test 버킷이 생성된걸 확인할 수 있습니다.

• 이후에는 user를 생성해 test 버킷과 연동시켜줘야 합니다. 이때 설정하는 key값들을 기반으로 외부에서 접근할 수 있습니다.

 

bucket에 user 연동(Feat. rook-ceph-tools)

radosgw-admin bucket list 명령어를 입력해 생성되어 있는 bucket 리스트를 확인합니다.

 

radosgw-admin key create --uid=dev_admin --key-type=s3 --access-key CLLEO6ITKWIPFMXV9Q6O --secret-key hYygMzxvRi0svvu2uQHDJNOg0Zx9j2cUQMh725Hs

• user 생성시 동일한 key를 가진 user가 존재하면 에러가 발생합니다. bucket과 user는 1대1관계이기 때문입니다.
• 동일한 uid에서 keys가 가지고있는 user는 동일해도 무관합니다. 하지만 access_key와 secret_key는 유일해야합니다.

 

radosgw-admin user list로 user 리스트를 확인 할 수 있습니다.

 

이후에는 user를 생성해 test 버킷과 연동시켜줘야 합니다. 이때 설정하는 key값들을 기반으로 외부에서 접근할 수 있습니다.

 

radosgw-admin bucket link --uid=dev_admin --bucket=test

• test bucket에 user 연동 하면 정상적으로 리스트에 출력되는걸 확인해볼 수 있었습니다.
• user를 연동하기 전에는 bucket list에 test가 리스트에 출력되지 않았습니다.

TIP : rook-ceph-tools에서는 RGW의 메타데이터 업데이트가 지연이나 버킷이 특정 사용자에 연결되어 있지 않은 경우 tools에서 확인이 불가능 하기도 합니다.

• 이때 버킷이 존재하지 않으면 다음과 같이 에러가 발생합니다.

 

추가 명령어

// user 삭제 명령어
radosgw-admin user rm --uid=my-user

// user를 삭제하지 않고 내부의 keys 데이터만 지정해 삭제시킬 수도 있습니다.
radosgw-admin key rm --uid=dev_admin --access-key W4RN98I4L1B8NKM0153Y --secret_key FkwsWQLrDFN6vzJahYqHb81mAHDqYc6KBHERfnEi

// user 상세 정보
radosgw-admin user info --uid=my-user

// bucket 상세 정보
radosgw-admin bucket stats --bucket=test

 

스프링 설정(S3client)

@Configuration
class S3ClientConfiguration(val s3ConfigurationProperties: S3ConfigurationProperties) {

    @Bean
    fun credentials(): BasicAWSCredentials {
        return BasicAWSCredentials(
            s3ConfigurationProperties.accessKey,
            s3ConfigurationProperties.secretKey
        )
    }

    @Bean
    fun amazonS3Client(): AmazonS3 {
        return AmazonS3ClientBuilder.standard()
            .withCredentials(AWSStaticCredentialsProvider(this.credentials()))
            .withEndpointConfiguration(AwsClientBuilder.EndpointConfiguration(s3ConfigurationProperties.endpointUrl, s3ConfigurationProperties.region))
            .enablePathStyleAccess()
            .build()
    }
}

• 이처럼 configuration으로 s3client를 설정한뒤 위에서 발급받은 key로 인증을 거친뒤 url과 region까지 설정한다면 외부에서 접근이 가능합니다.
• 이제 스프링을 통해 bucket 내부의 object 데이털 정보에 대해 CRUD가 가능하고 버킷을 만드는 API도 사용할 수 있으니 필요하다면 관련 자료를 찾아봐도 좋을 것 같습니다.
• 스프링 프레임 워크에서는 AWS SDK를 활용해 버킷을 생성하는 것이므로 버킷을 생성하는 방법도 상황에 맞게 생성하면 될 것 같습니다.

 

storeage 동작 개념

1. Bucket

• Bucket은 객체 스토어 (Object Store) 내에서 데이터를 논리적으로 구분하는 단위입니다.
• 각 Bucket은 여러 개의 객체(Object)를 포함하며, 객체는 데이터와 메타데이터로 구성됩니다.
• 예를 들어, AWS S3의 Bucket과 비슷한 개념입니다. 하나의 Bucket에는 다양한 종류의 객체를 저장할 수 있습니다.

 

2. Object Store

• Object Store는 Rook-Ceph에서 데이터를 관리하는 주체입니다.
• Ceph의 Object Store는 RADOS (Reliable Autonomic Distributed Object Store)라고 불리며, 다양한 종류의 데이터를 저장하고 관리할 수 있는 분산 저장 시스템입니다.
• 각각의 데이터는 고유한 키(주로 이름)를 가지고 있으며, 이 키를 사용하여 데이터를 식별하고 접근합니다.

 

3. Pool

• Pool은 Ceph 클러스터에서 데이터가 저장되는 물리적인 공간을 정의하는 개념입니다.
• 각 Pool은 데이터를 저장할 때 사용되는 규칙과 설정을 포함하고 있습니다. 예를 들어, 데이터 복제 수준(Replication Level)과 데이터 압축 여부 등을 정의할 수 있습니다.
• 여러 개의 OSD에 데이터를 분산하여 저장할 수 있도록 도와줍니다.

 

4. PG (Placement Group)

• Placement Group (PG)는 Pool 내에서 데이터를 분산 저장하기 위한 단위입니다.
• PG는 데이터를 샤드로 나누어 여러 개의 OSD에 분산하여 저장하고 관리합니다.
• 각 PG는 데이터의 복제와 데이터 안정성을 관리하는 데 중요한 역할을 합니다.

 

5. OSD (Object Storage Device)

• Object Storage Device (OSD)는 Ceph 클러스터에서 데이터를 실제로 저장하고 관리하는 단위입니다.
• 각 OSD는 디스크와 연결되어 데이터를 저장하며, 데이터의 복제 및 복구를 담당합니다.
• OSD는 Ceph 클러스터의 확장성과 안정성을 제공하는 핵심 컴포넌트입니다.

 

연관성과 동작 방식

• Bucket은 Object Store 내에서 관리되며, Pool과 PG는 데이터를 실제로 저장하는 물리적인 공간을 제공합니다.
• Object Store는 여러 개의 Pool로 구성되고, 각 Pool은 여러 개의 PG로 구성됩니다. 이렇게 분산된 구조는 데이터를 안정적으로 관리하고 복제할 수 있도록 합니다.
• OSD는 데이터를 실제로 저장하고, PG는 데이터를 분산하여 관리하며, Pool은 데이터의 관리 정책을 정의하는 역할을 합니다.
• Bucket은 Object Store 내에서 데이터를 논리적으로 구분하여 관리하는 단위이며, 다양한 데이터의 유형과 용도에 맞게 설정할 수 있습니다.

 

ob와 obc 개념

• OBC (ObjectBucketClaim):
  • 사용자가 객체 스토리지 버킷을 요청하는 리소스입니다.
  • PVC와 유사한 역할을 합니다.
  • 사용자가 생성하고 관리합니다.
• OB (ObjectBucket):
  • OBC에 의해 요청된 실제 객체 스토리지 버킷을 나타내는 리소스입니다.
  • PV와 유사한 역할을 합니다.
  • 쿠버네티스 Operator에 의해 자동으로 생성되고 관리됩니다.

 

동작 과정

1. OBC 생성: 사용자가 OBC를 생성하여 특정 스토리지 클래스로부터 객체 스토리지 버킷을 요청합니다.
2. OB 생성: 쿠버네티스 Operator가 OBC를 감지하고 해당 요청을 처리하여 실제 객체 스토리지 버킷을 생성한 후, 이를 나타내는 OB를 생성합니다.