Managing hybrid and multicloud resources

Red Hat OpenShift Data Foundation 4.10

NooBaa(Multicloud Object Gateway)를 사용하여 하이브리드 클라우드 또는 다중 클라우드 환경에서 스토리지 리소스를 관리하는 방법에 대한 지침.

초록

이 문서에서는 하이브리드 클라우드 또는 다중 클라우드 환경에서 스토리지 리소스를 관리하는 방법을 설명합니다.

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

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

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

문서 개선을 위한 의견을 보내 주십시오. Red Hat이 이를 개선하는 방법을 알려 주십시오. 피드백을 제공하려면 다음을 수행하십시오.

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

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

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

1장. Multicloud Object Gateway 정보

MCG(Multicloud Object Gateway)는 OpenShift용 경량 오브젝트 스토리지 서비스로, 사용자가 소규모를 시작한 다음 필요에 따라 온프레미스, 여러 클러스터에서 클라우드 네이티브 스토리지를 사용하여 확장할 수 있습니다.

2장. 애플리케이션을 사용하여 Multicloud Object Gateway에 액세스

AWS S3을 대상으로 하는 모든 애플리케이션 또는 AWS S3 Software Development Kit(SDK)를 사용하는 코드를 사용하여 오브젝트 서비스에 액세스할 수 있습니다. 애플리케이션에서 MCG(Multicloud Object Gateway) 엔드포인트, 액세스 키 및 시크릿 액세스 키를 지정해야 합니다. 터미널 또는 MCG CLI를 사용하여 이 정보를 검색할 수 있습니다.

RADOS 개체 게이트웨이(RGW) S3 엔드포인트 액세스에 대한 자세한 내용은 RADOS 개체 게이트웨이 S3 엔드포인트 액세스를 참조하십시오.

사전 요구 사항

  • 실행 중인 OpenShift Data Foundation Platform.
  • 관리가 용이한 MCG 명령줄 인터페이스를 다운로드하십시오.

    # subscription-manager repos --enable=rh-odf-4-for-rhel-8-x86_64-rpms
    # yum install mcg
    참고

    서브스크립션 관리자를 사용하여 리포지토리를 활성화하기 위한 적절한 아키텍처를 지정합니다.

    • IBM Power의 경우 다음 명령을 사용합니다.
    # subscription-manager repos --enable=rh-odf-4-for-rhel-8-ppc64le-rpms
    • IBM Z 인프라의 경우 다음 명령을 사용합니다.
    # subscription-manager repos --enable=rh-odf-4-for-rhel-8-s390x-rpms
  • 또는 Download RedHat OpenShift Data Foundation 페이지에 있는 OpenShift Data Foundation RPM에서 MCG 패키지를 설치할 수도 있습니다.

    참고

    아키텍처에 따라 올바른 제품 변형을 선택합니다.

다음 두 가지 방법으로 관련 끝점, 액세스 키 및 비밀 액세스 키에 액세스할 수 있습니다.

예 2.1. 예제

가상 호스팅 스타일을 사용하여 MCG 버킷 액세스
클라이언트 애플리케이션이 https://<bucket-name>.s3-openshift- storage.apps.mycluster-cluster.qe.rh-ocs.com에 액세스하려고 하면
<bucket-name>

MCG 버킷의 이름입니다.

예: https://mcg-test-bucket.s3-openshift-storage.apps.mycluster-cluster.qe.rh-ocs.com

mcg-test-bucket.s3-openshift-storage.apps.mycluster-cluster.qe.rh-ocs.com 에서 S3 서비스를 가리키려면 DNS 항목이 필요합니다.

중요

클라이언트 애플리케이션이 가상 호스팅 스타일을 사용하여 MCG 버킷을 가리키도록 DNS 항목이 있는지 확인합니다.

2.1. 터미널에서 Multicloud Object Gateway에 액세스

절차

describe 명령을 실행하여 액세스 키(AWS_ACCESS_KEY_ID 값) 및 비밀 액세스 키(AWS_SECRET_ACCESS_KEY 값)를 포함하여 MCG(Multicloud Object Gateway) 엔드포인트에 대한 정보를 봅니다.

# oc describe noobaa -n openshift-storage

출력은 다음과 유사합니다.

Name:         noobaa
Namespace:    openshift-storage
Labels:       <none>
Annotations:  <none>
API Version:  noobaa.io/v1alpha1
Kind:         NooBaa
Metadata:
  Creation Timestamp:  2019-07-29T16:22:06Z
  Generation:          1
  Resource Version:    6718822
  Self Link:           /apis/noobaa.io/v1alpha1/namespaces/openshift-storage/noobaas/noobaa
  UID:                 019cfb4a-b21d-11e9-9a02-06c8de012f9e
Spec:
Status:
  Accounts:
    Admin:
      Secret Ref:
        Name:           noobaa-admin
        Namespace:      openshift-storage
  Actual Image:         noobaa/noobaa-core:4.0
  Observed Generation:  1
  Phase:                Ready
  Readme:

  Welcome to NooBaa!
  -----------------

  Welcome to NooBaa!
    -----------------
    NooBaa Core Version:
    NooBaa Operator Version:

    Lets get started:

    1. Connect to Management console:

      Read your mgmt console login information (email & password) from secret: "noobaa-admin".

        kubectl get secret noobaa-admin -n openshift-storage -o json | jq '.data|map_values(@base64d)'

      Open the management console service - take External IP/DNS or Node Port or use port forwarding:

        kubectl port-forward -n openshift-storage service/noobaa-mgmt 11443:443 &
        open https://localhost:11443

    2. Test S3 client:

      kubectl port-forward -n openshift-storage service/s3 10443:443 &
1
      NOOBAA_ACCESS_KEY=$(kubectl get secret noobaa-admin -n openshift-storage -o json | jq -r '.data.AWS_ACCESS_KEY_ID|@base64d')
2
      NOOBAA_SECRET_KEY=$(kubectl get secret noobaa-admin -n openshift-storage -o json | jq -r '.data.AWS_SECRET_ACCESS_KEY|@base64d')
      alias s3='AWS_ACCESS_KEY_ID=$NOOBAA_ACCESS_KEY AWS_SECRET_ACCESS_KEY=$NOOBAA_SECRET_KEY aws --endpoint https://localhost:10443 --no-verify-ssl s3'
      s3 ls


    Services:
      Service Mgmt:
        External DNS:
          https://noobaa-mgmt-openshift-storage.apps.mycluster-cluster.qe.rh-ocs.com
          https://a3406079515be11eaa3b70683061451e-1194613580.us-east-2.elb.amazonaws.com:443
        Internal DNS:
          https://noobaa-mgmt.openshift-storage.svc:443
        Internal IP:
          https://172.30.235.12:443
        Node Ports:
          https://10.0.142.103:31385
        Pod Ports:
          https://10.131.0.19:8443
      serviceS3:
        External DNS: 3
          https://s3-openshift-storage.apps.mycluster-cluster.qe.rh-ocs.com
          https://a340f4e1315be11eaa3b70683061451e-943168195.us-east-2.elb.amazonaws.com:443
        Internal DNS:
          https://s3.openshift-storage.svc:443
        Internal IP:
          https://172.30.86.41:443
        Node Ports:
          https://10.0.142.103:31011
        Pod Ports:
          https://10.131.0.19:6443
1
액세스 키 (AWS_ACCESS_KEY_ID 값)
2
시크릿 액세스 키 (AWS_SECRET_ACCESS_KEY 값)
3
MCG 엔드 포인트

2.2. MCG 명령줄 인터페이스에서 Multicloud Object Gateway에 액세스

사전 요구 사항

  • MCG 명령줄 인터페이스를 다운로드합니다.

    # subscription-manager repos --enable=rh-odf-4-for-rhel-8-x86_64-rpms
    # yum install mcg
    참고

    서브스크립션 관리자를 사용하여 리포지토리를 활성화하기 위한 적절한 아키텍처를 지정합니다.

    • IBM Power의 경우 다음 명령을 사용합니다.
    # subscription-manager repos --enable=rh-odf-4-for-rhel-8-ppc64le-rpms
    • IBM Z 인프라의 경우 다음 명령을 사용합니다.
    # subscription-manager repos --enable=rh-odf-4-for-rhel-8-s390x-rpms

절차

status 명령을 실행하여 엔드포인트, 액세스 키 및 시크릿 액세스 키에 액세스합니다.

noobaa status -n openshift-storage

출력은 다음과 유사합니다.

INFO[0000] Namespace: openshift-storage
INFO[0000]
INFO[0000] CRD Status:
INFO[0003] ✅ Exists: CustomResourceDefinition "noobaas.noobaa.io"
INFO[0003] ✅ Exists: CustomResourceDefinition "backingstores.noobaa.io"
INFO[0003] ✅ Exists: CustomResourceDefinition "bucketclasses.noobaa.io"
INFO[0004] ✅ Exists: CustomResourceDefinition "objectbucketclaims.objectbucket.io"
INFO[0004] ✅ Exists: CustomResourceDefinition "objectbuckets.objectbucket.io"
INFO[0004]
INFO[0004] Operator Status:
INFO[0004] ✅ Exists: Namespace "openshift-storage"
INFO[0004] ✅ Exists: ServiceAccount "noobaa"
INFO[0005] ✅ Exists: Role "ocs-operator.v0.0.271-6g45f"
INFO[0005] ✅ Exists: RoleBinding "ocs-operator.v0.0.271-6g45f-noobaa-f9vpj"
INFO[0006] ✅ Exists: ClusterRole "ocs-operator.v0.0.271-fjhgh"
INFO[0006] ✅ Exists: ClusterRoleBinding "ocs-operator.v0.0.271-fjhgh-noobaa-pdxn5"
INFO[0006] ✅ Exists: Deployment "noobaa-operator"
INFO[0006]
INFO[0006] System Status:
INFO[0007] ✅ Exists: NooBaa "noobaa"
INFO[0007] ✅ Exists: StatefulSet "noobaa-core"
INFO[0007] ✅ Exists: Service "noobaa-mgmt"
INFO[0008] ✅ Exists: Service "s3"
INFO[0008] ✅ Exists: Secret "noobaa-server"
INFO[0008] ✅ Exists: Secret "noobaa-operator"
INFO[0008] ✅ Exists: Secret "noobaa-admin"
INFO[0009] ✅ Exists: StorageClass "openshift-storage.noobaa.io"
INFO[0009] ✅ Exists: BucketClass "noobaa-default-bucket-class"
INFO[0009] ✅ (Optional) Exists: BackingStore "noobaa-default-backing-store"
INFO[0010] ✅ (Optional) Exists: CredentialsRequest "noobaa-cloud-creds"
INFO[0010] ✅ (Optional) Exists: PrometheusRule "noobaa-prometheus-rules"
INFO[0010] ✅ (Optional) Exists: ServiceMonitor "noobaa-service-monitor"
INFO[0011] ✅ (Optional) Exists: Route "noobaa-mgmt"
INFO[0011] ✅ (Optional) Exists: Route "s3"
INFO[0011] ✅ Exists: PersistentVolumeClaim "db-noobaa-core-0"
INFO[0011] ✅ System Phase is "Ready"
INFO[0011] ✅ Exists:  "noobaa-admin"

#------------------#
#- Mgmt Addresses -#
#------------------#

ExternalDNS : [https://noobaa-mgmt-openshift-storage.apps.mycluster-cluster.qe.rh-ocs.com https://a3406079515be11eaa3b70683061451e-1194613580.us-east-2.elb.amazonaws.com:443]
ExternalIP  : []
NodePorts   : [https://10.0.142.103:31385]
InternalDNS : [https://noobaa-mgmt.openshift-storage.svc:443]
InternalIP  : [https://172.30.235.12:443]
PodPorts    : [https://10.131.0.19:8443]

#--------------------#
#- Mgmt Credentials -#
#--------------------#

email    : admin@noobaa.io
password : HKLbH1rSuVU0I/souIkSiA==

#----------------#
#- S3 Addresses -#
#----------------#

1
ExternalDNS : [https://s3-openshift-storage.apps.mycluster-cluster.qe.rh-ocs.com https://a340f4e1315be11eaa3b70683061451e-943168195.us-east-2.elb.amazonaws.com:443]
ExternalIP  : []
NodePorts   : [https://10.0.142.103:31011]
InternalDNS : [https://s3.openshift-storage.svc:443]
InternalIP  : [https://172.30.86.41:443]
PodPorts    : [https://10.131.0.19:6443]

#------------------#
#- S3 Credentials -#
#------------------#

2
AWS_ACCESS_KEY_ID     : jVmAsu9FsvRHYmfjTiHV
3
AWS_SECRET_ACCESS_KEY : E//420VNedJfATvVSmDz6FMtsSAzuBv6z180PT5c

#------------------#
#- Backing Stores -#
#------------------#

NAME                           TYPE     TARGET-BUCKET                                               PHASE   AGE
noobaa-default-backing-store   aws-s3   noobaa-backing-store-15dc896d-7fe0-4bed-9349-5942211b93c9   Ready   141h35m32s

#------------------#
#- Bucket Classes -#
#------------------#

NAME                          PLACEMENT                                                             PHASE   AGE
noobaa-default-bucket-class   {Tiers:[{Placement: BackingStores:[noobaa-default-backing-store]}]}   Ready   141h35m33s

#-----------------#
#- Bucket Claims -#
#-----------------#

No OBC's found.
1
엔드포인트
2
액세스 키
3
시크릿 액세스 키

이제 애플리케이션에 연결하기 위해 관련 끝점, 액세스 키 및 비밀 액세스 키가 있어야 합니다.

예 2.2. 예제

AWS S3 CLI가 애플리케이션인 경우 다음 명령은 OpenShift Data Foundation의 버킷을 나열합니다.

AWS_ACCESS_KEY_ID=<AWS_ACCESS_KEY_ID>
AWS_SECRET_ACCESS_KEY=<AWS_SECRET_ACCESS_KEY>
aws --endpoint <ENDPOINT> --no-verify-ssl s3 ls

3장. Multicloud Object Gateway Console에 대한 사용자 액세스 허용

사용자에게 MCG(Multicloud Object Gateway) 콘솔에 액세스할 수 있도록 하려면 사용자가 다음 조건을 충족하는지 확인합니다.

  • 사용자는 cluster-admins 그룹에 있습니다.
  • 사용자는 system:cluster-admins 가상 그룹에 있습니다.

사전 요구 사항

  • 실행 중인 OpenShift Data Foundation Platform.

절차

  1. MCG 콘솔에 대한 액세스를 활성화합니다.

    클러스터에서 다음 단계를 한 번 수행합니다.

    1. cluster-admins 그룹을 만듭니다.

      # oc adm groups new cluster-admins
    2. 그룹을 cluster-admin 역할에 바인딩합니다.

      # oc adm policy add-cluster-role-to-group cluster-admin cluster-admins
  2. cluster-admins 그룹에서 사용자를 추가하거나 제거하여 MCG 콘솔에 대한 액세스를 제어합니다.

    • cluster-admins 그룹에 사용자를 추가하려면 다음을 수행합니다.

      # oc adm groups add-users cluster-admins <user-name> <user-name> <user-name>...

      여기서 <user-name> 은 추가할 사용자의 이름입니다.

      참고

      사용자 집합을 cluster-admins 그룹에 추가하는 경우 새로 추가된 사용자를 cluster-admin 역할에 바인딩하여 OpenShift Data Foundation 대시보드에 액세스할 수 있습니다.

    • cluster-admins 그룹에서 사용자를 제거하려면 다음을 수행합니다.

      # oc adm groups remove-users cluster-admins <user-name> <user-name> <user-name>...

      여기서 <user-name> 은 제거할 사용자의 이름입니다.

검증 단계

  1. OpenShift 웹 콘솔에서 Multicloud Object Gateway Console에 대한 액세스 권한이 있는 사용자로 로그인합니다.
  2. 스토리지 → 데이터 기반으로 이동합니다.
  3. Storage Systems 탭에서 스토리지 시스템을 선택한 다음 OverviewObject 탭을 클릭합니다.
  4. Multicloud Object Gateway(Multicloud Object Gateway) 링크를 선택합니다.
  5. Allow selected permissions (선택한 권한 허용)를 클릭합니다.

4장. 하이브리드 또는 Multicloud 용 스토리지 리소스 추가

4.1. 새 백업 저장소 생성

OpenShift Data Foundation에서 새 백업 저장소를 생성하려면 다음 절차를 사용하십시오.

사전 요구 사항

  • OpenShift Data Foundation에 대한 관리자 액세스.

절차

  1. OpenShift 웹 콘솔에서 스토리지 → 데이터 기반 을 클릭합니다.
  2. 백업 저장소 탭을 클릭합니다.
  3. Create Backing Store (백업 저장소 만들기)를 클릭합니다.
  4. Create New Backing Store (새 백업 저장소 생성) 페이지에서 다음을 수행합니다.

    1. 백업 저장소 이름을 입력합니다.
    2. 공급업체 선택.
    3. 지역 선택.
    4. 엔드포인트 입력. 이는 선택 사항입니다.
    5. 드롭다운 목록에서 Secret 을 선택하거나 고유한 보안을 생성합니다. 필요한 경우 Credentials(자격 증명) 보기로 전환 하여 필요한 시크릿을 입력할 수 있습니다.

      OCP 보안 생성에 대한 자세한 내용은 Openshift Container Platform 설명서의 보안 생성 섹션을 참조하십시오.

      각 백업 저장소에는 다른 보안이 필요합니다. 특정 백업 저장소에 대한 시크릿 생성에 대한 자세한 내용은 4.2절. “MCG 명령줄 인터페이스를 사용하여 하이브리드 또는 Multicloud용 스토리지 리소스 추가” 을 참조하고 YAML을 사용하여 스토리지 리소스 추가 절차를 따르십시오.

      참고

      이 메뉴는 Google Cloud 및 로컬 PVC를 제외한 모든 공급자와 관련이 있습니다.

    6. 대상 버킷 을 입력합니다. 대상 버킷은 원격 클라우드 서비스에서 호스팅되는 컨테이너 스토리지입니다. MCG가 시스템에 이 버킷을 사용할 수 있음을 알려주는 연결을 만들 수 있습니다.
  5. Create Backing Store (백업 저장소 만들기)를 클릭합니다.

검증 단계

  1. OpenShift 웹 콘솔에서 스토리지 → 데이터 기반 을 클릭합니다.
  2. 백업 저장소 탭을 클릭하여 모든 백업 저장소를 확인합니다.

4.2. MCG 명령줄 인터페이스를 사용하여 하이브리드 또는 Multicloud용 스토리지 리소스 추가

MCG(Multicloud Object Gateway)는 클라우드 공급자와 클러스터에서 데이터를 확장하는 프로세스를 간소화합니다.

MCG에서 사용할 수 있는 백업 스토리지를 추가합니다.

배포 유형에 따라 다음 절차 중 하나를 선택하여 백업 스토리지를 생성할 수 있습니다.

VMware 배포의 경우 4.3절. “s3 호환 Multicloud Object Gateway 백업 저장소 생성” 로 건너뜁니다.

4.2.1. AWS 지원 백업 저장소 생성

사전 요구 사항

  • MCG(Multicloud Object Gateway) 명령줄 인터페이스를 다운로드합니다.

    # subscription-manager repos --enable=rh-odf-4-for-rhel-8-x86_64-rpms
    # yum install mcg
    참고

    서브스크립션 관리자를 사용하여 리포지토리를 활성화하기 위한 적절한 아키텍처를 지정합니다. 예를 들어 IBM Z 인프라의 경우 다음 명령을 사용합니다.

    # subscription-manager repos --enable=rh-odf-4-for-rhel-8-s390x-rpms
  • 또는 https://access.redhat.com/downloads/content/547/ver=4/rhel---8/4/x86_64/packages에 있는 OpenShift Data Foundation RPM에서 MCG 패키지를 설치할 수도 있습니다.

    참고

    아키텍처에 따라 올바른 제품 변형을 선택합니다.

절차

  1. MCG 명령줄 인터페이스에서 다음 명령을 실행합니다.

    noobaa backingstore create aws-s3 <backingstore_name> --access-key=<AWS ACCESS KEY> --secret-key=<AWS SECRET ACCESS KEY> --target-bucket <bucket-name> -n openshift-storage
  1. <backingstore_name> 을 백업 저장소의 이름으로 바꿉니다.
  2. <AWS ACCESS KEY><AWS SECRET ACCESS KEY> 를 이 목적을 위해 생성한 AWS 액세스 키 ID 및 시크릿 액세스 키로 바꿉니다.
  3. <bucket-name> 을 기존 AWS 버킷 이름으로 바꿉니다. 이 인수는 MCG에 백업 저장소에 대상 버킷으로 사용할 버킷을 알려줍니다. 그런 다음 데이터 스토리지 및 관리에 사용됩니다.

    출력은 다음과 유사합니다.

    INFO[0001] ✅ Exists: NooBaa "noobaa"
    INFO[0002] ✅ Created: BackingStore "aws-resource"
    INFO[0002] ✅ Created: Secret "backing-store-secret-aws-resource"

YAML을 사용하여 스토리지 리소스를 추가할 수도 있습니다.

  1. 인증 정보를 사용하여 보안을 생성합니다.

    apiVersion: v1
    kind: Secret
    metadata:
      name: <backingstore-secret-name>
      namespace: openshift-storage
    type: Opaque
    data:
      AWS_ACCESS_KEY_ID: <AWS ACCESS KEY ID ENCODED IN BASE64>
      AWS_SECRET_ACCESS_KEY: <AWS SECRET ACCESS KEY ENCODED IN BASE64>
    1. Base64를 사용하여 자체 AWS 액세스 키 ID 및 시크릿 액세스 키를 제공하고 인코딩해야 하며 <AWS ACCESS KEY ID ENCODED in BASE64> 및 < AWS SECRET ACCESS KEY ENCODED in BASE64> 대신 결과를 사용해야 합니다.
    2. <backingstore-secret-name> 을 고유한 이름으로 바꿉니다.
  2. 특정 백업 저장소에 대해 다음 YAML을 적용합니다.

    apiVersion: noobaa.io/v1alpha1
    kind: BackingStore
    metadata:
      finalizers:
      - noobaa.io/finalizer
      labels:
        app: noobaa
      name: bs
      namespace: openshift-storage
    spec:
      awsS3:
        secret:
          name: <backingstore-secret-name>
          namespace: openshift-storage
        targetBucket: <bucket-name>
      type: aws-s3
    1. <bucket-name> 을 기존 AWS 버킷 이름으로 바꿉니다. 이 인수는 MCG에 백업 저장소에 대상 버킷으로 사용할 버킷을 알려줍니다. 그런 다음 데이터 스토리지 및 관리에 사용됩니다.
    2. <backingstore-secret-name> 을 이전 단계에서 생성한 보안의 이름으로 바꿉니다.

4.2.2. IBM COS 지원 백업 저장소 생성

사전 요구 사항

  • MCG(Multicloud Object Gateway) 명령줄 인터페이스를 다운로드합니다.

    # subscription-manager repos --enable=rh-odf-4-for-rhel-8-x86_64-rpms
    # yum install mcg
    참고

    서브스크립션 관리자를 사용하여 리포지토리를 활성화하기 위한 적절한 아키텍처를 지정합니다. 예를 들면 다음과 같습니다.

    • IBM Power의 경우 다음 명령을 사용합니다.
    # subscription-manager repos --enable=rh-odf-4-for-rhel-8-ppc64le-rpms
    • IBM Z 인프라의 경우 다음 명령을 사용합니다.
    # subscription-manager repos --enable=rh-odf-4-for-rhel-8-s390x-rpms
  • 또는 https://access.redhat.com/downloads/content/547/ver=4/rhel---8/4/x86_64/packages에 있는 OpenShift Data Foundation RPM에서 MCG 패키지를 설치할 수도 있습니다.

    참고

    아키텍처에 따라 올바른 제품 변형을 선택합니다.

절차

  1. MCG 명령줄 인터페이스에서 다음 명령을 실행합니다.

    noobaa backingstore create ibm-cos <backingstore_name> --access-key=<IBM ACCESS KEY> --secret-key=<IBM SECRET ACCESS KEY> --endpoint=<IBM COS ENDPOINT> --target-bucket <bucket-name> -n openshift-storage
    1. <backingstore_name> 을 백업 저장소의 이름으로 바꿉니다.
    2. <IBM ACCESS KEY>, <IBM SECRET ACCESS KEY>, <IBM COS ENDPOINT> 를 IBM 액세스 키 ID, 시크릿 액세스 키 및 기존 IBM 버킷 위치에 해당하는 해당 지역 엔드포인트로 바꿉니다.

      IBM 클라우드에서 위의 키를 생성하려면 대상 버킷에 대한 서비스 자격 증명을 생성하는 동안 HMAC 인증 정보를 포함해야 합니다.

    3. <bucket-name> 을 기존 IBM 버킷 이름으로 바꿉니다. 이 인수는 MCG에 백업 저장소에 대상 버킷으로 사용할 버킷을 알려줍니다. 그런 다음 데이터 스토리지 및 관리에 사용됩니다.

      출력은 다음과 유사합니다.

      INFO[0001] ✅ Exists: NooBaa "noobaa"
      INFO[0002] ✅ Created: BackingStore "ibm-resource"
      INFO[0002] ✅ Created: Secret "backing-store-secret-ibm-resource"

YAML을 사용하여 스토리지 리소스를 추가할 수도 있습니다.

  1. 인증 정보를 사용하여 보안을 생성합니다.

    apiVersion: v1
    kind: Secret
    metadata:
      name: <backingstore-secret-name>
      namespace: openshift-storage
    type: Opaque
    data:
      IBM_COS_ACCESS_KEY_ID: <IBM COS ACCESS KEY ID ENCODED IN BASE64>
      IBM_COS_SECRET_ACCESS_KEY: <IBM COS SECRET ACCESS KEY ENCODED IN BASE64>
    1. Base64를 사용하여 자체 IBM COS 액세스 키 ID 및 비밀 액세스 키를 제공하고 인코딩해야 하며 <IBM COS COS 키 ID ENCODED IN BASE64> 및 < IBM COS SECRET ACCESS KEY ENCODED IN BASE64> 대신 결과를 사용해야 합니다.
    2. <backingstore-secret-name> 을 고유한 이름으로 바꿉니다.
  2. 특정 백업 저장소에 대해 다음 YAML을 적용합니다.

    apiVersion: noobaa.io/v1alpha1
    kind: BackingStore
    metadata:
      finalizers:
      - noobaa.io/finalizer
      labels:
        app: noobaa
      name: bs
      namespace: openshift-storage
    spec:
      ibmCos:
        endpoint: <endpoint>
        secret:
          name: <backingstore-secret-name>
          namespace: openshift-storage
        targetBucket: <bucket-name>
      type: ibm-cos
    1. <bucket-name> 을 기존 IBM COS 버킷 이름으로 바꿉니다. 이 인수는 MCG에 백업 저장소에 대상 버킷으로 사용할 버킷을 알려줍니다. 그런 다음 데이터 스토리지 및 관리에 사용됩니다.
    2. <endpoint> 를 기존 IBM 버킷 이름의 위치에 해당하는 지역 끝점으로 바꿉니다. 이 인수는 백업 저장소에 사용할 엔드포인트를 Multicloud Object Gateway에 지시하고 그 다음에는 데이터 스토리지 및 관리에 지시합니다.
    3. <backingstore-secret-name> 을 이전 단계에서 생성한 보안의 이름으로 바꿉니다.

4.2.3. Azure 지원 백업 저장소 생성

사전 요구 사항

  • MCG(Multicloud Object Gateway) 명령줄 인터페이스를 다운로드합니다.

    # subscription-manager repos --enable=rh-odf-4-for-rhel-8-x86_64-rpms
    # yum install mcg
    참고

    서브스크립션 관리자를 사용하여 리포지토리를 활성화하기 위한 적절한 아키텍처를 지정합니다. 예를 들어 IBM Z 인프라의 경우 다음 명령을 사용합니다.

    # subscription-manager repos --enable=rh-odf-4-for-rhel-8-s390x-rpms
  • 또는 https://access.redhat.com/downloads/content/547/ver=4/rhel---8/4/x86_64/packages에 있는 OpenShift Data Foundation RPM에서 MCG 패키지를 설치할 수도 있습니다.

    참고

    아키텍처에 따라 올바른 제품 변형을 선택합니다.

절차

  1. MCG 명령줄 인터페이스에서 다음 명령을 실행합니다.

    noobaa backingstore create azure-blob <backingstore_name> --account-key=<AZURE ACCOUNT KEY> --account-name=<AZURE ACCOUNT NAME> --target-blob-container <blob container name>
    1. <backingstore_name> 을 백업 저장소의 이름으로 바꿉니다.
    2. <AZURE ACCOUNT KEY><AZURE ACCOUNT NAME> 을 이 목적을 위해 생성한 AZURE 계정 키 및 계정 이름으로 바꿉니다.
    3. <blob 컨테이너 이름> 을 기존 Azure Blob 컨테이너 이름으로 바꿉니다. 이 인수는 MCG에 백업 저장소에 대상 버킷으로 사용할 버킷을 알려줍니다. 그런 다음 데이터 스토리지 및 관리에 사용됩니다.

      출력은 다음과 유사합니다.

      INFO[0001] ✅ Exists: NooBaa "noobaa"
      INFO[0002] ✅ Created: BackingStore "azure-resource"
      INFO[0002] ✅ Created: Secret "backing-store-secret-azure-resource"

YAML을 사용하여 스토리지 리소스를 추가할 수도 있습니다.

  1. 인증 정보를 사용하여 보안을 생성합니다.

    apiVersion: v1
    kind: Secret
    metadata:
      name: <backingstore-secret-name>
    type: Opaque
    data:
      AccountName: <AZURE ACCOUNT NAME ENCODED IN BASE64>
      AccountKey: <AZURE ACCOUNT KEY ENCODED IN BASE64>
    1. Base64를 사용하여 자체 Azure 계정 이름과 계정 키를 제공하고 인코딩해야 하며 <AZURE ACCOUNT NAME ENCODED IN BASE64> 및 < AZURE ACCOUNT KEY ENCODED IN BASE64> 대신 결과를 사용해야 합니다.
    2. <backingstore-secret-name> 을 고유한 이름으로 바꿉니다.
  2. 특정 백업 저장소에 대해 다음 YAML을 적용합니다.

    apiVersion: noobaa.io/v1alpha1
    kind: BackingStore
    metadata:
      finalizers:
      - noobaa.io/finalizer
      labels:
        app: noobaa
      name: bs
      namespace: openshift-storage
    spec:
      azureBlob:
        secret:
          name: <backingstore-secret-name>
          namespace: openshift-storage
        targetBlobContainer: <blob-container-name>
      type: azure-blob
    1. <blob-container-name> 을 기존 Azure Blob 컨테이너 이름으로 바꿉니다. 이 인수는 MCG에 백업 저장소에 대상 버킷으로 사용할 버킷을 알려줍니다. 그런 다음 데이터 스토리지 및 관리에 사용됩니다.
    2. <backingstore-secret-name> 을 이전 단계에서 생성한 보안의 이름으로 바꿉니다.

4.2.4. GCP 지원 백업 저장소 생성

사전 요구 사항

  • MCG(Multicloud Object Gateway) 명령줄 인터페이스를 다운로드합니다.

    # subscription-manager repos --enable=rh-odf-4-for-rhel-8-x86_64-rpms
    # yum install mcg
    참고

    서브스크립션 관리자를 사용하여 리포지토리를 활성화하기 위한 적절한 아키텍처를 지정합니다. 예를 들어 IBM Z 인프라의 경우 다음 명령을 사용합니다.

    # subscription-manager repos --enable=rh-odf-4-for-rhel-8-s390x-rpms
  • 또는 https://access.redhat.com/downloads/content/547/ver=4/rhel---8/4/x86_64/packages에 있는 OpenShift Data Foundation RPM에서 MCG 패키지를 설치할 수도 있습니다.

    참고

    아키텍처에 따라 올바른 제품 변형을 선택합니다.

절차

  1. MCG 명령줄 인터페이스에서 다음 명령을 실행합니다.

    noobaa backingstore create google-cloud-storage <backingstore_name> --private-key-json-file=<PATH TO GCP PRIVATE KEY JSON FILE> --target-bucket <GCP bucket name>
    1. <backingstore_name> 을 백업 저장소의 이름으로 바꿉니다.
    2. <PATH TO GCP PRIVATE KEY JSON FILE> 을 이 목적을 위해 생성된 GCP 개인 키의 경로로 바꿉니다.
    3. <GCP 버킷 이름> 을 기존 GCP 오브젝트 스토리지 버킷 이름으로 바꿉니다. 이 인수는 MCG에 백업 저장소에 대상 버킷으로 사용할 버킷을 알려줍니다. 그런 다음 데이터 스토리지 및 관리에 사용됩니다.

      출력은 다음과 유사합니다.

      INFO[0001] ✅ Exists: NooBaa "noobaa"
      INFO[0002] ✅ Created: BackingStore "google-gcp"
      INFO[0002] ✅ Created: Secret "backing-store-google-cloud-storage-gcp"

YAML을 사용하여 스토리지 리소스를 추가할 수도 있습니다.

  1. 인증 정보를 사용하여 보안을 생성합니다.

    apiVersion: v1
    kind: Secret
    metadata:
      name: <backingstore-secret-name>
    type: Opaque
    data:
      GoogleServiceAccountPrivateKeyJson: <GCP PRIVATE KEY ENCODED IN BASE64>
    1. Base64를 사용하여 자체 GCP 서비스 계정 개인 키를 제공하고 인코딩해야 하며 <GCP PRIVATE KEY ENCODED IN BASE64> 대신 결과를 사용해야 합니다.
    2. <backingstore-secret-name> 을 고유한 이름으로 바꿉니다.
  2. 특정 백업 저장소에 대해 다음 YAML을 적용합니다.

    apiVersion: noobaa.io/v1alpha1
    kind: BackingStore
    metadata:
      finalizers:
      - noobaa.io/finalizer
      labels:
        app: noobaa
      name: bs
      namespace: openshift-storage
    spec:
      googleCloudStorage:
        secret:
          name: <backingstore-secret-name>
          namespace: openshift-storage
        targetBucket: <target bucket>
      type: google-cloud-storage
    1. <target bucket> 을 기존 Google 스토리지 버킷으로 바꿉니다. 이 인수는 MCG에 백업 저장소에 대상 버킷으로 사용할 버킷을 알려줍니다. 그런 다음 데이터 스토리지 및 관리에 사용됩니다.
    2. <backingstore-secret-name> 을 이전 단계에서 생성한 보안의 이름으로 바꿉니다.

4.2.5. 로컬 영구 볼륨 백업 백업 저장소 생성

사전 요구 사항

  • MCG(Multicloud Object Gateway) 명령줄 인터페이스를 다운로드합니다.

    # subscription-manager repos --enable=rh-odf-4-for-rhel-8-x86_64-rpms
    # yum install mcg
    참고

    서브스크립션 관리자를 사용하여 리포지토리를 활성화하기 위한 적절한 아키텍처를 지정합니다. 예를 들어 IBM Z 인프라의 경우 다음 명령을 사용합니다.

    # subscription-manager repos --enable=rh-odf-4-for-rhel-8-s390x-rpms
  • 또는 https://access.redhat.com/downloads/content/547/ver=4/rhel---8/4/x86_64/packages에 있는 OpenShift Data Foundation RPM에서 MCG 패키지를 설치할 수도 있습니다.

    참고

    아키텍처에 따라 올바른 제품 변형을 선택합니다.

절차

  1. MCG 명령줄 인터페이스에서 다음 명령을 실행합니다.

    참고

    이 명령은 openshift-storage 네임스페이스 내에서 실행해야 합니다.

    noobaa backingstore create  pv-pool <backingstore_name> --num-volumes=<NUMBER OF VOLUMES>  --pv-size-gb=<VOLUME SIZE> --storage-class=<LOCAL STORAGE CLASS>
    1. <backingstore_name> 을 백업 저장소의 이름으로 바꿉니다.
    2. <NUMBER OF VOLUMES> 를 생성하려는 볼륨 수로 바꿉니다. 볼륨 수를 늘리면 스토리지가 확장됩니다.
    3. <VOLUME SIZE> 를 각 볼륨의 필수 크기(GB)로 바꿉니다.
    4. ocs-storagecluster-ceph-rbd 를 사용하는 데 권장되는 로컬 스토리지 클래스로 <LOCAL STORAGE CLASS> 를 바꿉니다.

      출력은 다음과 유사합니다.

      INFO[0001] ✅ Exists: NooBaa "noobaa"
      INFO[0002] ✅ Exists: BackingStore "local-mcg-storage"

YAML을 사용하여 스토리지 리소스를 추가할 수도 있습니다.

  1. 특정 백업 저장소에 대해 다음 YAML을 적용합니다.

    apiVersion: noobaa.io/v1alpha1
    kind: BackingStore
    metadata:
      finalizers:
      - noobaa.io/finalizer
      labels:
        app: noobaa
      name: <backingstore_name>
      namespace: openshift-storage
    spec:
       pvPool:
        numVolumes: <NUMBER OF VOLUMES>
        resources:
          requests:
            storage: <VOLUME SIZE>
        storageClass: <LOCAL STORAGE CLASS>
      type: pv-pool
    1. <backingstore_name> 을 백업 저장소의 이름으로 바꿉니다.
    2. <NUMBER OF VOLUMES> 를 생성하려는 볼륨 수로 바꿉니다. 볼륨 수를 늘리면 스토리지가 확장됩니다.
    3. <VOLUME SIZE> 를 각 볼륨의 필수 크기(GB)로 바꿉니다. 문자 G 는 유지되어야 합니다.
    4. ocs-storagecluster-ceph-rbd 를 사용하는 데 권장되는 로컬 스토리지 클래스로 <LOCAL STORAGE CLASS> 를 바꿉니다.

4.3. s3 호환 Multicloud Object Gateway 백업 저장소 생성

MCG(Multicloud Object Gateway)는 S3 호환 오브젝트 스토리지를 백업 저장소(예: Red Hat Ceph Storage의 RADOS Object Gateway)로 사용할 수 있습니다. 다음 절차에서는 Red Hat Ceph Storage의 RGW에 대해 S3 호환 MCG 백업 저장소를 만드는 방법을 보여줍니다. RGW가 배포되면 OpenShift Data Foundation Operator는 MCG에 대해 S3 호환 백업 저장소를 자동으로 생성합니다.

절차

  1. MCG 명령줄 인터페이스에서 다음 명령을 실행합니다.

    참고

    이 명령은 openshift-storage 네임스페이스 내에서 실행해야 합니다.

    noobaa backingstore create s3-compatible rgw-resource --access-key=<RGW ACCESS KEY> --secret-key=<RGW SECRET KEY> --target-bucket=<bucket-name> --endpoint=<RGW endpoint>
    1. <RGW ACCESS KEY><RGW SECRET KEY> 를 가져오려면 RGW 사용자 시크릿 이름을 사용하여 다음 명령을 실행합니다.

      oc get secret <RGW USER SECRET NAME> -o yaml -n openshift-storage
    2. Base64에서 액세스 키 ID와 액세스 키를 디코딩하고 유지합니다.
    3. <RGW USER ACCESS KEY><RGW USER SECRET ACCESS KEY> 를 이전 단계의 적절한 디코딩된 데이터로 바꿉니다.
    4. <bucket-name> 을 기존 RGW 버킷 이름으로 바꿉니다. 이 인수는 MCG에 백업 저장소에 대상 버킷으로 사용할 버킷을 알려줍니다. 그런 다음 데이터 스토리지 및 관리에 사용됩니다.
    5. <RGW 엔드포인트> 를 가져오려면 RADOS 개체 게이트웨이 S3 끝점 액세스를 참조하십시오.

      출력은 다음과 유사합니다.

      INFO[0001] ✅ Exists: NooBaa "noobaa"
      INFO[0002] ✅ Created: BackingStore "rgw-resource"
      INFO[0002] ✅ Created: Secret "backing-store-secret-rgw-resource"

YAML을 사용하여 백업 저장소를 생성할 수도 있습니다.

  1. CephObjectStore 사용자를 만듭니다. 이렇게 하면 RGW 인증 정보가 포함된 보안도 생성됩니다.

    apiVersion: ceph.rook.io/v1
    kind: CephObjectStoreUser
    metadata:
      name: <RGW-Username>
      namespace: openshift-storage
    spec:
      store: ocs-storagecluster-cephobjectstore
      displayName: "<Display-name>"
    1. <RGW-Username><Display-name> 을 고유한 사용자 이름 및 표시 이름으로 바꿉니다.
  2. S3 호환 백업 저장소에 다음 YAML을 적용합니다.

    apiVersion: noobaa.io/v1alpha1
    kind: BackingStore
    metadata:
      finalizers:
      - noobaa.io/finalizer
      labels:
        app: noobaa
      name: <backingstore-name>
      namespace: openshift-storage
    spec:
      s3Compatible:
        endpoint: <RGW endpoint>
        secret:
          name: <backingstore-secret-name>
          namespace: openshift-storage
        signatureVersion: v4
        targetBucket: <RGW-bucket-name>
      type: s3-compatible
    1. <backingstore-secret-name> 을 이전 단계에서 CephObjectStore 로 생성된 시크릿 이름으로 바꿉니다.
    2. <bucket-name> 을 기존 RGW 버킷 이름으로 바꿉니다. 이 인수는 MCG에 백업 저장소에 대상 버킷으로 사용할 버킷을 알려줍니다. 그런 다음 데이터 스토리지 및 관리에 사용됩니다.
    3. <RGW 엔드포인트> 를 가져오려면 RADOS 개체 게이트웨이 S3 끝점 액세스를 참조하십시오.

4.4. 사용자 인터페이스를 사용하여 하이브리드 및 Multicloud용 스토리지 리소스 추가

절차

  1. OpenShift 웹 콘솔에서 스토리지 → 데이터 기반 을 클릭합니다.
  2. Storage Systems 탭에서 스토리지 시스템을 선택한 다음 OverviewObject 탭을 클릭합니다.
  3. Multicloud Object Gateway(Multicloud Object Gateway) 링크를 선택합니다.
  1. 아래에 강조 표시된 왼쪽에서 Resources(리소스 ) 탭을 선택합니다. 채워지는 목록에서 클라우드 리소스 추가를 선택합니다.

    MCG, 클라우드 리소스 추가
  2. Add new connection(새 연결 추가)을 선택합니다.

    MCG에서 새 연결을 추가합니다.
  3. 관련 기본 클라우드 공급자 또는 S3 호환 옵션을 선택하고 세부 정보를 입력합니다.

    MCG, 클라우드 연결 추가
  4. 새로 생성된 연결을 선택하고 기존 버킷에 매핑합니다.

    MCG를 기존 버킷에 매핑
  5. 이 단계를 반복하여 필요한 만큼의 백업 저장소를 만듭니다.
참고

NooBaa UI에서 생성된 리소스는 OpenShift UI 또는 MCG CLI에서 사용할 수 없습니다.

4.5. 새 버킷 클래스 생성

버킷 클래스는 OBC(오브젝트 버킷 클래스)에 대한 계층화 정책 및 데이터 배치를 정의하는 버킷 클래스를 나타내는 CRD입니다.

OpenShift Data Foundation에서 버킷 클래스를 생성하려면 다음 절차를 사용하십시오.

절차

  1. OpenShift 웹 콘솔에서 스토리지 → 데이터 기반 을 클릭합니다.
  2. 버킷 클래스 탭을 클릭합니다.
  3. Create 버킷 클래스( 버킷 클래스 만들기)를 클릭합니다.
  4. Create new Bucket Class(새 버킷 클래스 생성) 페이지에서 다음을 수행합니다.

    1. 버킷 클래스 유형을 선택하고 버킷 클래스 이름을 입력합니다.

      1. 버킷 클래스 유형을 선택합니다. 다음 옵션 중 하나를 선택하십시오.

        • Standard: MCG(Multicloud Object Gateway)에서 데이터를 사용하고, 중복 제거, 압축 및 암호화됩니다.
        • namespace: 데이터는 중복 제거, 압축 또는 암호화를 수행하지 않고 네임 스페이스 저장소에 저장됩니다.

          기본적으로 Standard 가 선택됩니다.

      2. 버킷 클래스 이름을 입력합니다.
      3. 다음을 클릭합니다.
    2. Placement Policy (배치 정책)에서 Tier 1 - Policy Type(계층 1 - Policy Type )을 선택하고 Next (다음)를 클릭합니다. 요구 사항에 따라 옵션 중 하나를 선택할 수 있습니다.

      • 분산 을 사용하면 선택한 리소스 전체에 데이터를 분산할 수 있습니다.
      • 미러 를 사용하면 선택한 리소스에서 데이터를 완전히 복제할 수 있습니다.
      • Add Tier (계층 추가)를 클릭하여 다른 정책 계층을 추가합니다.
    3. Tier 1 - Policy TypeSpread 로 선택한 경우 사용 가능한 목록에서 하나 이상의 백업 저장소 리소스를 선택하고 Next (다음)를 클릭합니다. 또는 새 백업 저장소를 만들 수도 있습니다.

      참고

      이전 단계에서 Policy Type(정책 유형)을 mirror로 선택할 때 최소 2개의 백업 저장소를 선택해야 합니다.

    4. 버킷 클래스 설정을 검토하고 확인합니다.
    5. Create 버킷 클래스( 버킷 클래스 만들기)를 클릭합니다.

검증 단계

  1. OpenShift 웹 콘솔에서 스토리지 → 데이터 기반 을 클릭합니다.
  2. 버킷 클래스 탭을 클릭하고 새 버킷 클래스를 검색합니다.

4.6. 버킷 클래스 편집

Openshift 웹 콘솔에서 편집 버튼을 클릭하여 YAML 파일을 통해 버킷 클래스 구성 요소를 편집하려면 다음 절차를 사용합니다.

사전 요구 사항

  • OpenShift 웹 콘솔에 대한 관리자 액세스.

절차

  1. OpenShift 웹 콘솔에서 스토리지 → 데이터 기반 을 클릭합니다.
  2. 버킷 클래스 탭을 클릭합니다.
  3. 편집할 버킷 클래스 옆에 있는 작업 메뉴 (kube) 를 클릭합니다.
  4. Edit 버킷 Class( 버킷 클래스 편집)를 클릭합니다.
  5. YAML 파일로 리디렉션되어 이 파일에 필요한 변경 작업을 수행하고 저장을 클릭합니다.

4.7. 버킷 클래스의 백업 저장소 편집

다음 절차에 따라 기존 MCG(Multicloud Object Gateway) 버킷 클래스를 편집하여 버킷 클래스에 사용된 기본 백업 저장소를 변경합니다.

사전 요구 사항

  • OpenShift 웹 콘솔에 대한 관리자 액세스.
  • 버킷 클래스.
  • 백업 저장소.

절차

  1. OpenShift 웹 콘솔에서 스토리지 → 데이터 기반 을 클릭합니다.
  2. 버킷 클래스 탭을 클릭합니다.
  3. 편집할 버킷 클래스 옆에 있는 작업 메뉴 (kube) 를 클릭합니다.

    버킷 클래스 리소스 편집
  4. Edit 버킷 Class Resources( 버킷 클래스 리소스 편집)를 클릭합니다.
  5. 버킷 클래스 리소스 편집 페이지에서 버킷 클래스에 백업 저장소를 추가하거나 버킷 클래스에서 백업 저장소를 제거하여 버킷 클래스 리소스를 편집합니다. 하나 또는 두 개의 계층과 다양한 배치 정책을 사용하여 생성된 버킷 클래스 리소스를 편집할 수도 있습니다.

    • 버킷 클래스에 백업 저장소를 추가하려면 백업 저장소의 이름을 선택합니다.
    • 버킷 클래스에서 백업 저장소를 제거하려면 백업 저장소의 이름을 지웁니다.

      버킷 클래스의 백업 저장소 편집
  6. 저장을 클릭합니다.

5장. 네임스페이스 버킷 관리

네임 스페이스 버킷을 사용하면 여러 공급자의 데이터 리포지토리를 함께 연결할 수 있으므로 단일 통합 뷰를 통해 모든 데이터와 상호 작용할 수 있습니다. 각 공급자와 연결된 오브젝트 버킷을 네임 스페이스 버킷에 추가하고 네임 스페이스 버킷을 통해 데이터에 액세스하여 모든 오브젝트 버킷을 한 번에 확인합니다. 이를 통해 원하는 스토리지 공급자에 쓰는 동시에 다른 여러 스토리지 공급자로부터 읽을 수 있어 새 스토리지 공급자로 마이그레이션하는 데 드는 비용을 크게 줄일 수 있습니다.

참고

네임 스페이스 버킷은 쓰기 대상이 사용 가능하고 작동하는 경우에만 사용할 수 있습니다.

5.1. 네임스페이스 버킷의 오브젝트에 대한 Amazon S3 API 끝점

Amazon S3(Simple Storage Service) API를 사용하여 네임스페이스 버킷의 오브젝트와 상호 작용할 수 있습니다.

Red Hat OpenShift Data Foundation 4.6 이상에서는 다음과 같은 네임 스페이스 버킷 작업을 지원합니다.

이러한 작업 및 사용 방법에 대한 최신 정보는 Amazon S3 API 참조 문서를 참조하십시오.

5.2. Multicloud Object Gateway CLI 및 YAML을 사용하여 네임스페이스 버킷 추가

네임스페이스 버킷에 대한 자세한 내용은 네임스페이스 버킷 관리를 참조하십시오.

배포 유형 및 YAML 또는 MCG(Multicloud Object Gateway) CLI를 사용할지 여부에 따라 다음 절차 중 하나를 선택하여 네임스페이스 버킷을 추가합니다.

5.2.1. YAML을 사용하여 AWS S3 네임 스페이스 버킷 추가

사전 요구 사항

절차

  1. 인증 정보를 사용하여 보안을 생성합니다.

    apiVersion: v1
    kind: Secret
    metadata:
      name: <namespacestore-secret-name>
      type: Opaque
    data:
      AWS_ACCESS_KEY_ID: <AWS ACCESS KEY ID ENCODED IN BASE64>
      AWS_SECRET_ACCESS_KEY: <AWS SECRET ACCESS KEY ENCODED IN BASE64>
    1. Base64를 사용하여 자체 AWS 액세스 키 ID 및 시크릿 액세스 키를 제공하고 인코딩해야 하며 <AWS ACCESS KEY ID ENCODED in BASE64> 및 < AWS SECRET ACCESS KEY ENCODED in BASE64> 대신 결과를 사용해야 합니다.
    2. <namespacestore-secret-name> 을 고유한 이름으로 바꿉니다.
  2. OpenShift CRD(Custom Resource Definitions)를 사용하여 네임스페이스 저장소 리소스를 생성합니다. 네임 스페이스 저장소는 MCG 네임 스페이스 버킷의 데이터에 대한 읽기 또는 쓰기 대상으로 사용할 기본 스토리지를 나타냅니다. 네임스페이스 저장소 리소스를 생성하려면 다음 YAML을 적용합니다.

    apiVersion: noobaa.io/v1alpha1
    kind: NamespaceStore
    metadata:
      finalizers:
      - noobaa.io/finalizer
      labels:
        app: noobaa
      name: <resource-name>
      namespace: openshift-storage
    spec:
      awsS3:
        secret:
          name: <namespacestore-secret-name>
          namespace: <namespace-secret>
        targetBucket: <target-bucket>
      type: aws-s3
    1. <resource-name> 을 리소스에 제공할 이름으로 바꿉니다.
    2. <namespacestore-secret-name> 을 1 단계에서 생성된 보안으로 교체합니다.
    3. <namespace-secret> 을 보안을 찾을 수 있는 네임스페이스로 바꿉니다.
    4. <target-bucket> 을 네임 스페이스 저장소에 대해 생성한 대상 버킷으로 바꿉니다.
  3. 네임스페이스 버킷에 대한 네임스페이스 정책을 정의하는 네임스페이스 버킷 클래스를 생성합니다. 네임스페이스 정책에는 단일 또는 multi 의 유형이 필요합니다.

    • type single 의 네임스페이스 정책에는 다음과 같은 구성이 필요합니다.

      apiVersion: noobaa.io/v1alpha1
      kind: BucketClass
      metadata:
        labels:
          app: noobaa
        name: <my-bucket-class>
        namespace: openshift-storage
      spec:
        namespacePolicy:
          type:
          single:
            resource: <resource>
      • <my-bucket-class> 를 고유한 네임 스페이스 버킷 클래스 이름으로 바꿉니다.
      • <resource> 를 네임 스페이스 버킷의 읽기 및 쓰기 대상을 정의하는 단일 네임 스페이스 저장소의 이름으로 바꿉니다.
    • type multi 의 네임스페이스 정책에는 다음과 같은 구성이 필요합니다.

      apiVersion: noobaa.io/v1alpha1
      
      kind: BucketClass
      metadata:
        labels:
          app: noobaa
        name: <my-bucket-class>
        namespace: openshift-storage
      spec:
        namespacePolicy:
          type: Multi
          multi:
            writeResource: <write-resource>
            readResources:
            - <read-resources>
            - <read-resources>
      • <my-bucket-class> 를 고유한 버킷 클래스 이름으로 바꿉니다.
      • <write-resource> 를 네임 스페이스 버킷의 쓰기 대상을 정의하는 단일 네임 스페이스 저장소의 이름으로 바꿉니다.
      • <read-resources> 를 네임 스페이스 버킷의 읽기 대상을 정의하는 namespace-stores의 이름 목록으로 바꿉니다.
  4. 다음 YAML을 적용하여 2단계에 정의된 버킷 클래스를 사용하는 OBC(개체 버킷 클래스) 리소스를 사용하여 버킷을 생성합니다.

    apiVersion: objectbucket.io/v1alpha1
    kind: ObjectBucketClaim
    metadata:
      name: <resource-name>
      namespace: openshift-storage
    spec:
      generateBucketName: <my-bucket>
      storageClassName: openshift-storage.noobaa.io
      additionalConfig:
        bucketclass: <my-bucket-class>
    1. <resource-name> 을 리소스에 제공할 이름으로 바꿉니다.
    2. <my-bucket> 을 버킷에 제공할 이름으로 바꿉니다.
    3. <my-bucket-class> 를 이전 단계에서 생성한 버킷 클래스로 바꿉니다.

Operator가 OBC를 프로비저닝하면 MCG에서 버킷이 생성되고 Operator는 동일한 이름과 OBC의 동일한 네임스페이스에 있는 Secret 및 ConfigMap을 생성합니다.

5.2.2. YAML을 사용하여 IBM COS 네임 스페이스 버킷 추가

사전 요구 사항

절차

  1. 인증 정보를 사용하여 보안을 생성합니다.

    apiVersion: v1
    kind: Secret
    metadata:
      name: <namespacestore-secret-name>
      type: Opaque
    data:
      IBM_COS_ACCESS_KEY_ID: <IBM COS ACCESS KEY ID ENCODED IN BASE64>
      IBM_COS_SECRET_ACCESS_KEY: <IBM COS SECRET ACCESS KEY ENCODED IN BASE64>
    1. Base64를 사용하여 자체 IBM COS 액세스 키 ID 및 비밀 액세스 키를 제공하고 인코딩해야 하며 <IBM COS COS 키 ID ENCODED IN BASE64> 및 < IBM COS SECRET ACCESS KEY ENCODED IN BASE64> 대신 결과를 사용해야 합니다.
    2. <namespacestore-secret-name> 을 고유한 이름으로 바꿉니다.
  2. OpenShift CRD(Custom Resource Definitions)를 사용하여 네임스페이스 저장소 리소스를 생성합니다. 네임 스페이스 저장소는 MCG 네임 스페이스 버킷의 데이터에 대한 읽기 또는 쓰기 대상으로 사용할 기본 스토리지를 나타냅니다. 네임스페이스 저장소 리소스를 생성하려면 다음 YAML을 적용합니다.

    apiVersion: noobaa.io/v1alpha1
    kind: NamespaceStore
    metadata:
      finalizers:
      - noobaa.io/finalizer
      labels:
        app: noobaa
      name: bs
      namespace: openshift-storage
    spec:
      s3Compatible:
        endpoint: <IBM COS ENDPOINT>
        secret:
          name: <namespacestore-secret-name>
          namespace: <namespace-secret>
        signatureVersion: v2
        targetBucket: <target-bucket>
      type: ibm-cos
    1. <IBM COS ENDPOINT> 를 적절한 IBM COS 엔드포인트로 바꿉니다.
    2. <namespacestore-secret-name> 을 1 단계에서 생성된 보안으로 교체합니다.
    3. <namespace-secret> 을 보안을 찾을 수 있는 네임스페이스로 바꿉니다.
    4. <target-bucket> 을 네임 스페이스 저장소에 대해 생성한 대상 버킷으로 바꿉니다.
  3. 네임스페이스 버킷에 대한 네임스페이스 정책을 정의하는 네임스페이스 버킷 클래스를 생성합니다. 네임스페이스 정책에는 단일 또는 multi 의 유형이 필요합니다.

    • type single 의 네임스페이스 정책에는 다음과 같은 구성이 필요합니다.

      apiVersion: noobaa.io/v1alpha1
      kind: BucketClass
      metadata:
        labels:
          app: noobaa
        name: <my-bucket-class>
        namespace: openshift-storage
      spec:
        namespacePolicy:
          type:
          single:
            resource: <resource>
      • <my-bucket-class> 를 고유한 네임 스페이스 버킷 클래스 이름으로 바꿉니다.
      • <resource> 를 단일 네임 스페이스 저장소 이름으로 교체하여 네임 스페이스 버킷의 읽기 및 쓰기 대상을 정의합니다.
    • type multi 의 네임스페이스 정책에는 다음과 같은 구성이 필요합니다.

      apiVersion: noobaa.io/v1alpha1
      kind: BucketClass
      metadata:
        labels:
          app: noobaa
        name: <my-bucket-class>
        namespace: openshift-storage
      spec:
        namespacePolicy:
          type: Multi
          multi:
            writeResource: <write-resource>
            readResources:
            - <read-resources>
            - <read-resources>
      • <my-bucket-class> 를 고유한 버킷 클래스 이름으로 바꿉니다.
      • <write-resource> 를 네임 스페이스 버킷의 쓰기 대상을 정의하는 단일 네임 스페이스 저장소의 이름으로 바꿉니다.
      • <read-resources> 를 네임 스페이스 버킷의 읽기 대상을 정의하는 namespace-stores 이름 목록으로 바꿉니다.
  4. 다음 YAML을 적용하여 2단계에 정의된 버킷 클래스를 사용하는 OBC(개체 버킷 클래스) 리소스를 사용하여 버킷을 생성합니다.

    apiVersion: objectbucket.io/v1alpha1
    kind: ObjectBucketClaim
    metadata:
      name: <resource-name>
      namespace: openshift-storage
    spec:
      generateBucketName: <my-bucket>
      storageClassName: openshift-storage.noobaa.io
      additionalConfig:
        bucketclass: <my-bucket-class>
    1. <resource-name> 을 리소스에 제공할 이름으로 바꿉니다.
    2. <my-bucket> 을 버킷에 제공할 이름으로 바꿉니다.
    3. <my-bucket-class> 를 이전 단계에서 생성한 버킷 클래스로 바꿉니다.

Operator가 OBC를 프로비저닝하면 MCG에서 버킷이 생성되고 Operator는 동일한 이름과 OBC의 동일한 네임스페이스에 있는 Secret 및 ConfigMap을 생성합니다.

5.2.3. Multicloud Object Gateway CLI를 사용하여 AWS S3 네임 스페이스 버킷 추가

사전 요구 사항

# subscription-manager repos --enable=rh-odf-4-for-rhel-8-x86_64-rpms
# yum install mcg
참고

서브스크립션 관리자를 사용하여 리포지토리를 활성화하기 위한 적절한 아키텍처를 지정합니다. 예를 들어 IBM Z 인프라의 경우 다음 명령을 사용합니다.

# subscription-manager repos --enable=rh-odf-4-for-rhel-8-s390x-rpms

또는 https://access.redhat.com/downloads/content/547/ver=4/rhel---8/4/x86_64/package 에 있는 OpenShift Data Foundation RPM에서 MCG 패키지를 설치할 수도 있습니다.

참고

아키텍처에 따라 올바른 제품 변형을 선택합니다.

절차

  1. 네임스페이스 저장소 리소스를 생성합니다. 네임 스페이스 저장소는 MCG 네임 스페이스 버킷의 데이터에 대한 읽기 또는 쓰기 대상으로 사용할 기본 스토리지를 나타냅니다. MCG 명령줄 인터페이스에서 다음 명령을 실행합니다.

    noobaa namespacestore create aws-s3 <namespacestore> --access-key <AWS ACCESS KEY> --secret-key <AWS SECRET ACCESS KEY> --target-bucket <bucket-name> -n openshift-storage
    1. <namespacestore> 를 네임 스페이스 저장소의 이름으로 바꿉니다.
    2. <AWS ACCESS KEY><AWS SECRET ACCESS KEY> 를 이 목적을 위해 생성한 AWS 액세스 키 ID 및 시크릿 액세스 키로 바꿉니다.
    3. <bucket-name> 을 기존 AWS 버킷 이름으로 바꿉니다. 이 인수는 MCG에 백업 저장소에 대상 버킷으로 사용할 버킷을 알려줍니다. 그런 다음 데이터 스토리지 및 관리에 사용됩니다.
  2. 네임스페이스 버킷에 대한 네임스페이스 정책을 정의하는 네임스페이스 버킷 클래스를 생성합니다. 네임스페이스 정책에는 단일 또는 multi 의 유형이 필요합니다.

    • 다음 명령을 실행하여 단일 유형의 네임스페이스 정책으로 네임 스페이스 버킷 클래스를 생성합니다.

      noobaa bucketclass create namespace-bucketclass single <my-bucket-class> --resource <resource> -n openshift-storage
      • <resource-name> 을 리소스를 제공할 이름으로 바꿉니다.
      • <my-bucket-class> 를 고유한 버킷 클래스 이름으로 바꿉니다.
      • <resource> 를 네임 스페이스 버킷의 읽기 및 쓰기 대상을 정의하는 단일 네임 스페이스 저장소로 바꿉니다.
    • 다음 명령을 실행하여 유형 multi 의 네임스페이스 정책으로 네임 스페이스 버킷 클래스를 생성합니다.

      noobaa bucketclass create namespace-bucketclass multi <my-bucket-class> --write-resource <write-resource> --read-resources <read-resources> -n openshift-storage
      • <resource-name> 을 리소스를 제공할 이름으로 바꿉니다.
      • <my-bucket-class> 를 고유한 버킷 클래스 이름으로 바꿉니다.
      • <write-resource> 를 네임 스페이스 버킷의 쓰기 대상을 정의하는 단일 네임 스페이스 저장소로 바꿉니다.
      • <read-resources> 를 네임 스페이스 버킷의 읽기 대상을 정의하는 쉼표로 구분된 네임 스페이스 저장소 목록으로 바꿉니다.
  3. 다음 명령을 실행하여 2단계에 정의된 버킷 클래스를 사용하는 OBC(개체 버킷 클래스) 리소스를 사용하여 버킷을 생성합니다.

    noobaa obc create my-bucket-claim -n openshift-storage --app-namespace my-app --bucketclass <custom-bucket-class>
    1. <bucket-name> 을 선택한 버킷 이름으로 바꿉니다.
    2. <custom-bucket-class> 를 2단계에서 생성된 버킷 클래스의 이름으로 바꿉니다.

Operator가 OBC를 프로비저닝하면 MCG에서 버킷이 생성되고 Operator는 동일한 이름과 OBC의 동일한 네임스페이스에 있는 Secret 및 ConfigMap을 생성합니다.

5.2.4. Multicloud Object Gateway CLI를 사용하여 IBM COS 네임 스페이스 버킷 추가

사전 요구 사항

  • 실행 중인 OpenShift Data Foundation Platform.
  • MCG(Multicloud Object Gateway)에 액세스하고 2장, 애플리케이션과 함께 Multicloud Object Gateway에 액세스.
  • MCG 명령줄 인터페이스를 다운로드합니다.

    # subscription-manager repos --enable=rh-odf-4-for-rhel-8-x86_64-rpms
    # yum install mcg
    참고

    서브스크립션 관리자를 사용하여 리포지토리를 활성화하기 위한 적절한 아키텍처를 지정합니다.

    • IBM Power의 경우 다음 명령을 사용합니다.
    # subscription-manager repos --enable=rh-odf-4-for-rhel-8-ppc64le-rpms
    • IBM Z 인프라의 경우 다음 명령을 사용합니다.
    # subscription-manager repos --enable=rh-odf-4-for-rhel-8-s390x-rpms

    또는 https://access.redhat.com/downloads/content/547/ver=4/rhel---8/4/x86_64/package 에 있는 OpenShift Data Foundation RPM에서 MCG 패키지를 설치할 수도 있습니다.

    참고

    아키텍처에 따라 올바른 제품 변형을 선택합니다.

절차

  1. 네임스페이스 저장소 리소스를 생성합니다. 네임 스페이스 저장소는 MCG 네임 스페이스 버킷의 데이터에 대한 읽기 또는 쓰기 대상으로 사용할 기본 스토리지를 나타냅니다. MCG 명령줄 인터페이스에서 다음 명령을 실행합니다.

    noobaa namespacestore create ibm-cos <namespacestore> --endpoint <IBM COS ENDPOINT> --access-key <IBM ACCESS KEY> --secret-key <IBM SECRET ACCESS KEY> --target-bucket <bucket-name> -n openshift-storage
    1. <namespacestore> 를 네임 스페이스 저장소의 이름으로 바꿉니다.
    2. <IBM ACCESS KEY>, <IBM SECRET ACCESS KEY>, <IBM COS ENDPOINT> 를 IBM 액세스 키 ID, 시크릿 액세스 키 및 기존 IBM 버킷 위치에 해당하는 해당 지역 엔드포인트로 바꿉니다.
    3. <bucket-name> 을 기존 IBM 버킷 이름으로 바꿉니다. 이 인수는 MCG에 백업 저장소에 대상 버킷으로 사용할 버킷을 알려줍니다. 그런 다음 데이터 스토리지 및 관리에 사용됩니다.
  2. 네임스페이스 버킷에 대한 네임스페이스 정책을 정의하는 네임스페이스 버킷 클래스를 생성합니다. 네임스페이스 정책에는 단일 또는 multi 의 유형이 필요합니다.

    • 다음 명령을 실행하여 단일 유형의 네임스페이스 정책으로 네임 스페이스 버킷 클래스를 생성합니다.

      noobaa bucketclass create namespace-bucketclass single <my-bucket-class> --resource <resource> -n openshift-storage
      • <resource-name> 을 리소스를 제공할 이름으로 바꿉니다.
      • <my-bucket-class> 를 고유한 버킷 클래스 이름으로 바꿉니다.
      • <resource> 를 네임 스페이스 버킷의 읽기 및 쓰기 대상을 정의하는 단일 네임 스페이스 저장소로 바꿉니다.
    • 다음 명령을 실행하여 유형 multi 의 네임스페이스 정책으로 네임 스페이스 버킷 클래스를 생성합니다.

      noobaa bucketclass create namespace-bucketclass multi <my-bucket-class> --write-resource <write-resource> --read-resources <read-resources> -n openshift-storage
      • <resource-name> 을 리소스를 제공할 이름으로 바꿉니다.
      • <my-bucket-class> 를 고유한 버킷 클래스 이름으로 바꿉니다.
      • <write-resource> 를 네임 스페이스 버킷의 쓰기 대상을 정의하는 단일 네임 스페이스 저장소로 바꿉니다.
      • <read-resources> 를 네임 스페이스 버킷의 읽기 대상을 정의하는 쉼표로 구분된 네임 스페이스 저장소 목록으로 바꿉니다.
  3. 다음 명령을 실행하여 2단계에 정의된 버킷 클래스를 사용하는 OBC(개체 버킷 클래스) 리소스를 사용하여 버킷을 생성합니다.

    noobaa obc create my-bucket-claim -n openshift-storage --app-namespace my-app --bucketclass <custom-bucket-class>
    1. <bucket-name> 을 선택한 버킷 이름으로 바꿉니다.
    2. <custom-bucket-class> 를 2단계에서 생성된 버킷 클래스의 이름으로 바꿉니다.

Operator가 OBC를 프로비저닝하면 MCG에서 버킷이 생성되고 Operator는 동일한 이름과 OBC의 동일한 네임스페이스에 있는 Secret 및 ConfigMap을 생성합니다.

5.3. OpenShift Container Platform 사용자 인터페이스를 사용하여 네임스페이스 버킷 추가

OpenShift Data Foundation 4.8부터 OpenShift Container Platform 사용자 인터페이스를 사용하여 네임스페이스 버킷을 추가할 수 있습니다. 네임스페이스 버킷에 대한 자세한 내용은 네임스페이스 버킷 관리를 참조하십시오.

사전 요구 사항

  • OpenShift Data Foundation 운영자가 설치된 OpenShift Container Platform
  • MCG(Multicloud Object Gateway)에 액세스합니다.

절차

  1. OpenShift 웹 콘솔에 로그인합니다.
  2. 스토리지 → Data Foundation을 클릭합니다.
  3. Namespace Store (네임스페이스 저장소) 탭을 클릭하여 네임스페이스 버킷에서 사용할 네임스페이스 저장소 리소스를 생성합니다.

    1. Create namespace store (네임스페이스 저장소 만들기)를 클릭합니다.
    2. 네임스페이스 저장소 이름을 입력합니다.
    3. 공급업체 선택.
    4. 지역 선택.
    5. 기존 시크릿을 선택하거나 Switch to credentials 를 클릭하여 보안 키 및 시크릿 액세스 키를 입력하여 시크릿을 생성합니다.
    6. 대상 버킷을 선택합니다.
    7. 생성을 클릭합니다.
    8. 네임스페이스 저장소가 Ready 상태인지 확인합니다.
    9. 원하는 리소스 양이 될 때까지 다음 단계를 반복합니다.
  4. 버킷 클래스 탭 → 새 버킷 클래스를 생성합니다.

    1. 네임스페이스 라디오 버튼을 선택합니다.
    2. 버킷 클래스 이름을 입력합니다.
    3. 설명 추가(선택 사항).
    4. 다음을 클릭합니다.
  5. 네임 스페이스 버킷에 대한 네임스페이스 정책 유형을 선택한 다음 Next (다음)를 클릭합니다.
  6. 대상 리소스를 선택합니다.

    • 네임스페이스 정책 유형이 Single 인 경우 읽기 리소스를 선택해야 합니다.
    • 네임스페이스 정책 유형이 Multi 인 경우 읽기 리소스와 쓰기 리소스를 선택해야 합니다.
    • 네임스페이스 정책 유형이 Cache 인 경우 네임 스페이스 버킷의 읽기 및 쓰기 대상을 정의하는 Hub 네임 스페이스 저장소를 선택해야 합니다.
  7. 다음을 클릭합니다.
  8. 새 버킷 클래스를 검토한 다음 Create Bucketclass(Bucketclass 만들기 )를 클릭합니다.
  9. BucketClass 페이지에서 새로 생성된 리소스가 Created 단계에 있는지 확인합니다.
  10. OpenShift 웹 콘솔에서 스토리지 → 데이터 기반 을 클릭합니다.
  11. 상태 카드에서 Storage System (스토리지 시스템)을 클릭하고 표시되는 팝업에서 스토리지 시스템 링크를 클릭합니다.
  12. Object 탭에서 Multicloud Object Gateway버킷 → 네임 스페이스 버킷 탭을 클릭합니다.
  13. 네임스페이스 버킷 생성을 클릭합니다.

    1. Choose Name (이름 선택) 탭에서 네임스페이스 버킷 이름을 지정하고 Next (다음)를 클릭합니다.
    2. Set Placement (배치 설정) 탭에서 다음을 수행합니다.

      1. Read Policy (읽기 정책)에서 네임스페이스 버킷이 데이터를 읽도록 5단계에서 생성된 각 네임스페이스 리소스의 확인란을 선택합니다.
      2. 사용 중인 네임스페이스 정책 유형이 Multi 이면 Read Policy(쓰기 정책)에서 네임스페이스 버킷에서 데이터를 작성해야 하는 네임스페이스 리소스를 지정합니다.
      3. 다음을 클릭합니다.
    3. 생성을 클릭합니다.

검증

  • State 열, 예상되는 읽기 리소스 수 및 예상 쓰기 리소스 이름에 녹색 확인 표시가 포함된 네임스페이스 버킷이 나열되는지 확인합니다.

5.4. S3 프로토콜을 사용하여 기존 애플리케이션 데이터를 클라우드 네이티브 애플리케이션과 공유

대부분의 기존 애플리케이션에서는 파일 시스템을 사용하여 데이터 세트를 공유합니다. S3 작업을 사용하여 파일 시스템의 레거시 데이터에 액세스하고 공유할 수 있습니다. 데이터를 공유하려면 다음을 수행해야 합니다.

  • 기존 파일 시스템 데이터 세트(즉, Ceph FileSystem(CephFS)와 같은 RWX 볼륨)를 내보내거나 S3 프로토콜을 사용하여 새 파일 시스템 데이터 세트를 생성합니다.
  • 파일 시스템과 S3 프로토콜 모두에서 파일 시스템 시스템 데이터 집합에 액세스합니다.
  • S3 계정을 구성하고 기존 또는 새 파일 시스템 고유 식별자(UID) 및 그룹 식별자(GID)에 매핑합니다.

5.4.1. 파일 시스템을 사용하기 위해 네임스페이스 저장소 생성

사전 요구 사항

  • OpenShift Data Foundation 운영자가 설치된 OpenShift Container Platform
  • MCG(Multicloud Object Gateway)에 액세스합니다.

절차

  1. OpenShift 웹 콘솔에 로그인합니다.
  2. 스토리지데이터 기반 을 클릭합니다.
  3. NamespaceStore 탭을 클릭하여 네임스페이스 버킷에 사용할 NamespaceStore 리소스를 생성합니다.
  4. Create namespacestore 를 클릭합니다.
  5. 네임스페이스 저장소의 이름을 입력합니다.
  6. 공급자로 Filesystem 을 선택합니다.
  7. 영구 볼륨 클레임을 선택합니다.
  8. 폴더 이름을 입력합니다.

    폴더 이름이 있는 경우 해당 폴더를 사용하여 NamespaceStore를 생성하거나 해당 이름의 폴더가 생성됩니다.

  9. 생성을 클릭합니다.
  10. NamespaceStore가 Ready 상태인지 확인합니다.

5.4.2. NamespaceStore 파일 시스템 구성을 사용하여 계정 생성

YAML을 편집하여 NamespaceStore 파일 시스템 구성을 사용하여 새 계정을 생성하거나 기존 일반 계정을 NamespaceStore 파일 시스템 계정으로 변환할 수 있습니다.

참고

계정에서 NamespaceStore 파일 시스템 구성을 제거할 수 없습니다.

사전 요구 사항

  • MCG(Multicloud Object Gateway) 명령줄 인터페이스를 다운로드합니다.

    # subscription-manager repos --enable=rh-odf-4-for-rhel-8-x86_64-rpms
    # yum install mcg

절차

  • MCG 명령줄 인터페이스를 사용하여 NamespaceStore 파일 시스템 구성을 사용하여 새 계정을 생성합니다.

    $ noobaa account create <noobaa-account-name> [flags]

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

    $ noobaa account create testaccount --full_permission --nsfs_account_config --gid 10001 --uid 10001 –default_resource fs_namespacestore

    allow_bucket_create

    계정이 새 버킷을 만들 수 있는지 여부를 나타냅니다. 지원되는 값은 true 또는 false 입니다. 기본값은 true 입니다.

    allowed_buckets

    사용자가 액세스 및 관리 권한을 가질 수 있는 버킷 이름의 쉼표로 구분된 목록입니다.

    default_resource

    S3 CreateBucket 작업을 사용할 때 새 버킷을 생성할 NamespaceStore 리소스입니다. NamespaceStore는 RWX(ReadWriteMany) PVC(영구 볼륨 클레임)가 지원해야 합니다.

    full_permission

    계정이 전체 권한을 허용할지 여부를 나타냅니다. 지원되는 값은 true 또는 false 입니다. 기본값은 false 입니다.

    new_buckets_path

    새 버킷에 해당하는 디렉터리가 생성되는 파일 시스템 경로입니다. 경로는 새로 생성된 오브젝트 버킷 클래스의 파일 시스템 매핑 역할을 하기 위해 새 디렉터리가 생성되는 NamespaceStore 파일 시스템 PVC 파일 시스템 내에 있습니다.

    nsfs_account_config

    계정이 NamespaceStore 파일 시스템에 사용되는지 여부를 나타내는 필수 필드입니다.

    nsfs_only

    계정이 NamespaceStore 파일 시스템에만 사용되는지 여부를 나타냅니다. 지원되는 값은 true 또는 false 입니다. 기본값은 false 입니다. 'true'로 설정하면 다른 유형의 버킷에 액세스할 수 없게 됩니다.

    uid

    MCG 계정이 매핑되고 파일 시스템의 데이터에 액세스하고 관리하는 데 사용되는 파일 시스템의 사용자 ID

    GID

    MCG 계정이 매핑되고 파일 시스템의 데이터에 액세스하고 관리하는 데 사용되는 파일 시스템의 그룹 ID

    MCG 시스템은 계정 구성 및 S3 인증 정보로 응답을 전송합니다.

    # NooBaaAccount spec:
    allow_bucket_creation: true
    Allowed_buckets:
      full_permission: true
      permission_list: []
    default_resource: noobaa-default-namespace-store
    Nsfs_account_config:
      gid: 10001
      new_buckets_path: /
      nsfs_only: true
      uid: 10001
    INFO[0006] ✅ Exists: Secret "noobaa-account-testaccount"
    Connection info:
      AWS_ACCESS_KEY_ID      : <aws-access-key-id>
      AWS_SECRET_ACCESS_KEY  : <aws-secret-access-key>

    다음 명령을 사용하여 모든 CRD(사용자 정의 리소스 정의) 기반 계정을 나열할 수 있습니다.

    $ noobaa account list
    NAME          ALLOWED_BUCKETS   DEFAULT_RESOURCE               PHASE   AGE
    testaccount   [*]               noobaa-default-backing-store   Ready   1m17s

    특정 계정에 관심이 있는 경우 계정 이름으로 CRD(사용자 정의 리소스 정의)를 직접 읽을 수 있습니다.

    oc get noobaaaccount/testaccount -o yaml
    spec:
      allow_bucket_creation: true
      allowed_buckets:
        full_permission: true
        permission_list: []
      default_resource: noobaa-default-namespace-store
      nsfs_account_config:
        gid: 10001
        new_buckets_path: /
        nsfs_only: true
        uid: 10001

5.4.3. openshift-storage 네임스페이스에서 레거시 애플리케이션 데이터에 액세스

MCG(Multicloud Object Gateway)를 사용하는 경우 데이터가 openshift-storage 네임스페이스에 있는 PVC(영구 볼륨 클레임) 기능을 사용해야 합니다. 거의 모든 경우에 액세스해야 하는 데이터는 openshift-storage 네임스페이스에 없지만 레거시 애플리케이션에서 사용하는 네임스페이스에 있습니다.

다른 네임스페이스에 저장된 데이터에 액세스하려면 openshift-storage 네임스페이스에서 레거시 애플리케이션이 사용하는 동일한 CephFS 볼륨을 가리키는 PVC를 생성해야 합니다.

절차

  1. scc 로 애플리케이션 네임스페이스를 표시합니다.

    $ oc get ns <application_namespace> -o yaml | grep scc
    <application_namespace>

    애플리케이션 네임스페이스의 이름을 지정합니다.

    예 5.1. 예제

    $ oc get ns testnamespace -o yaml | grep scc

    예 5.2. 출력 예

    openshift.io/sa.scc.mcs: s0:c26,c5
    openshift.io/sa.scc.supplemental-groups: 1000660000/10000
    openshift.io/sa.scc.uid-range: 1000660000/10000
  2. 애플리케이션 네임스페이스로 이동합니다.

    $ oc project <application_namespace>

    예 5.3. 예제

    $ oc project testnamespace
  3. MCG NSFS 기능을 사용하여 noobaa S3 끝점에서 사용할 Pod에 ReadWriteMany(RWX) PVC가 마운트되었는지 확인합니다.

    $ oc get pvc

    예 5.4. 출력 예

    NAME                                               STATUS VOLUME
    CAPACITY ACCESS MODES STORAGECLASS              AGE
    cephfs-write-workload-generator-no-cache-pv-claim  Bound  pvc-aa58fb91-c3d2-475b-bbee-68452a613e1a
    10Gi     RWX          ocs-storagecluster-cephfs 12s
    $ oc get pod

    예 5.5. 출력 예

    NAME                                                READY   STATUS              RESTARTS   AGE
    cephfs-write-workload-generator-no-cache-1-cv892    1/1     Running             0          11s
  4. Pod 내에서 영구 볼륨(PV)의 마운트 지점을 확인합니다.

    1. Pod에서 PV의 볼륨 이름을 가져옵니다.

      $ oc get pods <pod_name> -o jsonpath='{.spec.volumes[]}'
      <pod_name>

      Pod 이름을 지정합니다.

      예 5.6. 예제

      $ oc get pods cephfs-write-workload-generator-no-cache-1-cv892 -o jsonpath='{.spec.volumes[]}'

      예 5.7. 출력 예

      {"name":"app-persistent-storage","persistentVolumeClaim":{"claimName":"cephfs-write-workload-generator-no-cache-pv-claim"}}

      이 예에서 PVC의 볼륨 이름은 cephfs-write-workload-generator-no-cache-pv-claim 입니다.

    2. Pod의 모든 마운트를 나열하고 이전 단계에서 식별한 볼륨의 마운트 지점을 확인합니다.

      $ oc get pods <pod_name> -o jsonpath='{.spec.containers[].volumeMounts}'

      예 5.8. 예제

      $ oc get pods cephfs-write-workload-generator-no-cache-1-cv892 -o jsonpath='{.spec.containers[].volumeMounts}'

      예 5.9. 출력 예

      [{"mountPath":"/mnt/pv","name":"app-persistent-storage"},{"mountPath":"/var/run/secrets/kubernetes.io/serviceaccount","name":"kube-api-access-8tnc5","readOnly":true}]
  5. Pod에서 RWX PV의 마운트 지점을 확인합니다.

    $ oc exec -it <pod_name> -- df <mount_path>
    <mount_path>

    이전 단계에서 확인한 마운트 지점의 경로를 지정합니다.

    예 5.10. 예제

    $ oc exec -it cephfs-write-workload-generator-no-cache-1-cv892 -- df /mnt/pv

    예 5.11. 출력 예

    main
    Filesystem
    1K-blocks Used Available  Use%  Mounted on
    172.30.202.87:6789,172.30.120.254:6789,172.30.77.247:6789:/volumes/csi/csi-vol-cc416d9e-dbf3-11ec-b286-0a580a810213/edcfe4d5-bdcb-4b8e-8824-8a03ad94d67c
    10485760  0    10485760   0%    /mnt/pv
  6. UID 및 SELinux 레이블이 레거시 네임스페이스가 사용하는 것과 같은지 확인합니다.

    $ oc exec -it <pod_name> -- ls -latrZ <mount_path>

    예 5.12. 예제

    $ oc exec -it cephfs-write-workload-generator-no-cache-1-cv892 -- ls -latrZ /mnt/pv/

    예 5.13. 출력 예

    total 567
    drwxrwxrwx. 3 root       root system_u:object_r:container_file_t:s0:c26,c5      2 May 25 06:35 .
    -rw-r--r--. 1 1000660000 root system_u:object_r:container_file_t:s0:c26,c5 580138 May 25 06:35 fs_write_cephfs-write-workload-generator-no-cache-1-cv892-data.log
    drwxrwxrwx. 3 root       root system_u:object_r:container_file_t:s0:c26,c5     30 May 25 06:35 ..
  7. openshift-storage 네임스페이스에서 액세스할 수 있도록 하려면 레거시 애플리케이션 RWX PV의 정보를 가져옵니다.

    $ oc get pv | grep <pv_name>
    <pv_name>

    PV 이름을 지정합니다.

    예 5.14. 예제

    $ oc get pv | grep pvc-aa58fb91-c3d2-475b-bbee-68452a613e1a

    예 5.15. 출력 예

    pvc-aa58fb91-c3d2-475b-bbee-68452a613e1a   10Gi       RWX            Delete           Bound    testnamespace/cephfs-write-workload-generator-no-cache-pv-claim   ocs-storagecluster-cephfs              47s
  8. openshift-storage 네임스페이스에서 PVC에 액세스하여 하나 이상의 noobaa-endpoint Pod가 PVC에 액세스할 수 있도록 합니다.

    1. volumeAttributes 에서 subvolumePathvolumeHandle 의 값을 찾습니다. 레거시 애플리케이션 PV의 YAML 설명에서 이러한 값을 가져올 수 있습니다.

      $ oc get pv <pv_name> -o yaml

      예 5.16. 예제

      $ oc get pv pvc-aa58fb91-c3d2-475b-bbee-68452a613e1a -o yaml

      예 5.17. 출력 예

      apiVersion: v1
      kind: PersistentVolume
      metadata:
        annotations:
          pv.kubernetes.io/provisioned-by: openshift-storage.cephfs.csi.ceph.com
        creationTimestamp: "2022-05-25T06:27:49Z"
        finalizers:
        - kubernetes.io/pv-protection
        name: pvc-aa58fb91-c3d2-475b-bbee-68452a613e1a
        resourceVersion: "177458"
        uid: 683fa87b-5192-4ccf-af2f-68c6bcf8f500
      spec:
        accessModes:
        - ReadWriteMany
        capacity:
          storage: 10Gi
        claimRef:
          apiVersion: v1
          kind: PersistentVolumeClaim
          name: cephfs-write-workload-generator-no-cache-pv-claim
          namespace: testnamespace
          resourceVersion: "177453"
          uid: aa58fb91-c3d2-475b-bbee-68452a613e1a
        csi:
          controllerExpandSecretRef:
            name: rook-csi-cephfs-provisioner
            namespace: openshift-storage
          driver: openshift-storage.cephfs.csi.ceph.com
          nodeStageSecretRef:
            name: rook-csi-cephfs-node
            namespace: openshift-storage
          volumeAttributes:
            clusterID: openshift-storage
            fsName: ocs-storagecluster-cephfilesystem
            storage.kubernetes.io/csiProvisionerIdentity: 1653458225664-8081-openshift-storage.cephfs.csi.ceph.com
            subvolumeName: csi-vol-cc416d9e-dbf3-11ec-b286-0a580a810213
            subvolumePath: /volumes/csi/csi-vol-cc416d9e-dbf3-11ec-b286-0a580a810213/edcfe4d5-bdcb-4b8e-8824-8a03ad94d67c
          volumeHandle: 0001-0011-openshift-storage-0000000000000001-cc416d9e-dbf3-11ec-b286-0a580a810213
        persistentVolumeReclaimPolicy: Delete
        storageClassName: ocs-storagecluster-cephfs
        volumeMode: Filesystem
      status:
        phase: Bound
    2. 이전 단계에서 식별한 subvolumePathvolumeHandle 값을 사용하여 기존 애플리케이션 PV와 동일한 CephFS 볼륨을 가리키는 openshift-storage 네임스페이스에 새 PV 및 PVC 오브젝트를 생성합니다.

      예 5.18. YAML 파일 예

      $ cat << EOF >> pv-openshift-storage.yaml
      apiVersion: v1
      kind: PersistentVolume
      metadata:
        name: cephfs-pv-legacy-openshift-storage
      spec:
        storageClassName: ""
        accessModes:
        - ReadWriteMany
        capacity:
          storage: 10Gi     1
        csi:
          driver: openshift-storage.cephfs.csi.ceph.com
          nodeStageSecretRef:
            name: rook-csi-cephfs-node
            namespace: openshift-storage
          volumeAttributes:
          # Volume Attributes can be copied from the Source testnamespace PV
            "clusterID": "openshift-storage"
            "fsName": "ocs-storagecluster-cephfilesystem"
            "staticVolume": "true"
          # rootpath is the subvolumePath: you copied from the Source testnamespace PV
            "rootPath": /volumes/csi/csi-vol-cc416d9e-dbf3-11ec-b286-0a580a810213/edcfe4d5-bdcb-4b8e-8824-8a03ad94d67c
          volumeHandle: 0001-0011-openshift-storage-0000000000000001-cc416d9e-dbf3-11ec-b286-0a580a810213-clone   2
        persistentVolumeReclaimPolicy: Retain
        volumeMode: Filesystem
      ---
      apiVersion: v1
      kind: PersistentVolumeClaim
      metadata:
        name: cephfs-pvc-legacy
        namespace: openshift-storage
      spec:
        storageClassName: ""
        accessModes:
        - ReadWriteMany
        resources:
          requests:
            storage: 10Gi     3
        volumeMode: Filesystem
        # volumeName should be same as PV name
        volumeName: cephfs-pv-legacy-openshift-storage
      EOF
      1
      openshift-storage 네임스페이스에서 생성하는 PV의 스토리지 용량은 원래 PV와 동일해야 합니다.
      2
      openshift-storage 에서 생성하는 대상 PV의 볼륨 핸들에는 원래 애플리케이션 PV와 다른 핸들이 있어야 합니다(예: 볼륨 처리 끝에 -clone 추가).
      3
      openshift-storage 네임스페이스에서 생성하는 PVC의 스토리지 용량은 원래 PVC와 동일해야 합니다.
    3. 이전 단계에서 지정한 YAML 파일을 사용하여 openshift-storage 네임스페이스에 PV 및 PVC를 생성합니다.

      $ oc create -f <YAML_file>
      <YAML_file>

      YAML 파일의 이름을 지정합니다.

      예 5.19. 예제

      $ oc create -f pv-openshift-storage.yaml

      예 5.20. 출력 예

      persistentvolume/cephfs-pv-legacy-openshift-storage created
      persistentvolumeclaim/cephfs-pvc-legacy created
    4. openshift-storage 네임스페이스에서 PVC를 사용할 수 있는지 확인합니다.

      $ oc get pvc -n openshift-storage

      예 5.21. 출력 예

      NAME                                  STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS                  AGE
      cephfs-pvc-legacy                     Bound    cephfs-pv-legacy-openshift-storage         10Gi       RWX                                          14s
    5. openshift-storage 프로젝트로 이동합니다.

      $ oc project openshift-storage

      예 5.22. 출력 예

      Now using project "openshift-storage" on server "https://api.cluster-5f6ng.5f6ng.sandbox65.opentlc.com:6443".
    6. NSFS 네임스페이스 저장소를 생성합니다.

      $ noobaa namespacestore create nsfs <nsfs_namespacestore> --pvc-name='<cephfs_pvc_name>' --fs-backend='CEPH_FS'
      <nsfs_namespacestore>
      NSFS 네임스페이스 저장소의 이름을 지정합니다.
      <cephfs_pvc_name>

      openshift-storage 네임스페이스에서 CephFS PVC의 이름을 지정합니다.

      예 5.23. 예제

      $ noobaa namespacestore create nsfs legacy-namespace --pvc-name='cephfs-pvc-legacy' --fs-backend='CEPH_FS'
    7. noobaa-endpoint Pod가 다시 시작되고 NSFS 네임스페이스 저장소에서 PVC를 성공적으로 마운트하십시오(예: /nsfs/legacy-namespace 마운트 지점).

      $ oc exec -it <noobaa_endpoint_pod_name> -- df -h /nsfs/<nsfs_namespacestore>
      <noobaa_endpoint_pod_name>

      noobaa-endpoint Pod의 이름을 지정합니다.

      예 5.24. 예제

      $ oc exec -it noobaa-endpoint-5875f467f5-546c6 -- df -h /nsfs/legacy-namespace

      예 5.25. 출력 예

      Filesystem                                                                                                                                                Size  Used Avail Use% Mounted on
      172.30.202.87:6789,172.30.120.254:6789,172.30.77.247:6789:/volumes/csi/csi-vol-cc416d9e-dbf3-11ec-b286-0a580a810213/edcfe4d5-bdcb-4b8e-8824-8a03ad94d67c   10G     0   10G   0% /nsfs/legacy-namespace
    8. MCG 사용자 계정을 생성합니다.

      $ noobaa account create <user_account> --full_permission --allow_bucket_create=true --new_buckets_path='/' --nsfs_only=true --nsfs_account_config=true --gid <gid_number> --uid <uid_number> --default_resource='legacy-namespace'
      <user_account>
      MCG 사용자 계정의 이름을 지정합니다.
      <gid_number>
      GID 번호를 지정합니다.
      <uid_number>

      UID 번호를 지정합니다.

      예 5.26. 예제

      중요

      레거시 애플리케이션의 것과 동일한 UIDGID 를 사용합니다. 이전 출력에서 찾을 수 있습니다.

      $ noobaa account create leguser --full_permission --allow_bucket_create=true --new_buckets_path='/' --nsfs_only=true --nsfs_account_config=true --gid 0 --uid 1000660000 --default_resource='legacy-namespace'
    9. MCG 버킷을 만듭니다.

      1. 레거시 애플리케이션 Pod의 CephFS PV 및 PVC에서 NSFS 공유 내에 S3 전용 폴더를 생성합니다.

        $ oc exec -it <pod_name> -- mkdir <mount_path>/nsfs

        예 5.27. 예제

        $ oc exec -it cephfs-write-workload-generator-no-cache-1-cv892 -- mkdir /mnt/pv/nsfs
      2. nsfs/ 경로를 사용하여 MCG 버킷을 생성합니다.

        $ noobaa api bucket_api create_bucket '{
          "name": "<bucket_name>",
          "namespace":{
            "write_resource": { "resource": "<nsfs_namespacestore>", "path": "nsfs/" },
            "read_resources": [ { "resource": "<nsfs_namespacestore>", "path": "nsfs/" }]
          }
        }'

        예 5.28. 예제

        $ noobaa api bucket_api create_bucket '{
          "name": "legacy-bucket",
          "namespace":{
            "write_resource": { "resource": "legacy-namespace", "path": "nsfs/" },
            "read_resources": [ { "resource": "legacy-namespace", "path": "nsfs/" }]
          }
        }'
    10. 레거시 애플리케이션 및 openshift-storage 네임스페이스의 PVC에 있는 폴더의 SELinux 레이블을 확인합니다.

      $ oc exec -it <noobaa_endpoint_pod_name> -n openshift-storage -- ls -ltraZ /nsfs/<nsfs_namespacstore>

      예 5.29. 예제

      $ oc exec -it noobaa-endpoint-5875f467f5-546c6 -n openshift-storage -- ls -ltraZ /nsfs/legacy-namespace

      예 5.30. 출력 예

      total 567
      drwxrwxrwx. 3 root       root system_u:object_r:container_file_t:s0:c0,c26      2 May 25 06:35 .
      -rw-r--r--. 1 1000660000 root system_u:object_r:container_file_t:s0:c0,c26 580138 May 25 06:35 fs_write_cephfs-write-workload-generator-no-cache-1-cv892-data.log
      drwxrwxrwx. 3 root       root system_u:object_r:container_file_t:s0:c0,c26     30 May 25 06:35 ..
      $ oc exec -it <pod_name> -- ls -latrZ <mount_path>

      예 5.31. 예제

      $ oc exec -it cephfs-write-workload-generator-no-cache-1-cv892 -- ls -latrZ /mnt/pv/

      예 5.32. 출력 예

      total 567
      drwxrwxrwx. 3 root       root system_u:object_r:container_file_t:s0:c26,c5      2 May 25 06:35 .
      -rw-r--r--. 1 1000660000 root system_u:object_r:container_file_t:s0:c26,c5 580138 May 25 06:35 fs_write_cephfs-write-workload-generator-no-cache-1-cv892-data.log
      drwxrwxrwx. 3 root       root system_u:object_r:container_file_t:s0:c26,c5     30 May 25 06:35 ..

      이 예제에서는 SELinux 레이블이 동일하지 않아 권한 거부 또는 액세스 문제가 발생하는 것을 확인할 수 있습니다.

  9. 레거시 애플리케이션 및 openshift-storage 포드에서 파일에서 동일한 SELinux 레이블을 사용하는지 확인합니다.

    다음 두 가지 방법 중 하나를 수행할 수 있습니다.

  10. NSFS 네임스페이스 저장소를 삭제합니다.

    1. MCG 버킷을 삭제합니다.

      $ noobaa bucket delete <bucket_name>

      예 5.33. 예제

      $ noobaa bucket delete legacy-bucket
    2. MCG 사용자 계정을 삭제합니다.

      $ noobaa account delete <user_account>

      예 5.34. 예제

      $ noobaa account delete leguser
    3. NSFS 네임스페이스 저장소를 삭제합니다.

      $ noobaa namespacestore delete <nsfs_namespacestore>

      예 5.35. 예제

      $ noobaa namespacestore delete legacy-namespace
  11. PV 및 PVC를 삭제합니다.

    중요

    PV 및 PVC를 삭제하기 전에 PV에 정책이 구성되어 있는지 확인합니다.

    $ oc delete pv <cephfs_pv_name>
    $ oc delete pvc <cephfs_pvc_name>
    <cephfs_pv_name>
    레거시 애플리케이션의 CephFS PV 이름을 지정합니다.
    <cephfs_pvc_name>

    레거시 애플리케이션의 CephFS PVC 이름을 지정합니다.

    예 5.36. 예제

    $ oc delete pv cephfs-pv-legacy-openshift-storage
    $ oc delete pvc cephfs-pvc-legacy

5.4.3.1. openshift-storage 프로젝트의 기본 SELinux 레이블과 일치하도록 레거시 애플리케이션 프로젝트의 기본 SELinux 레이블 변경

  1. sa.scc.mcs 로 현재 openshift-storage 네임스페이스를 표시합니다.

    $ oc get ns openshift-storage -o yaml | grep sa.scc.mcs

    예 5.37. 출력 예

    openshift.io/sa.scc.mcs: s0:c26,c0
  2. 레거시 애플리케이션 네임스페이스를 편집하고 openshift-storage 네임스페이스의 sa.scc.mcs 값을 사용하여 sa.scc.mcs 를 수정합니다.

    $ oc edit ns <appplication_namespace>

    예 5.38. 예제

    $ oc edit ns testnamespace
    $ oc get ns <application_namespace> -o yaml | grep sa.scc.mcs

    예 5.39. 예제

    $ oc get ns testnamespace -o yaml | grep sa.scc.mcs

    예 5.40. 출력 예

    openshift.io/sa.scc.mcs: s0:c26,c0
  3. 레거시 애플리케이션 포드를 다시 시작합니다. 모든 파일의 레이블을 다시 지정하고 이제 SELinux 레이블이 openshift-storage 배포와 일치합니다.

5.4.3.2. 레거시 애플리케이션 PVC를 마운트하는 포드가 있는 배포 구성에만 SELinux 레이블 수정

  1. openshift-storage 프로젝트에서 사용하는 MCS(Multi category Security)를 사용하여 MustRunAsseLinuxOptions 옵션을 사용하여 새 scc 를 생성합니다.

    예 5.41. YAML 파일 예

    $ cat << EOF >> scc.yaml
    allowHostDirVolumePlugin: false
    allowHostIPC: false
    allowHostNetwork: false
    allowHostPID: false
    allowHostPorts: false
    allowPrivilegeEscalation: true
    allowPrivilegedContainer: false
    allowedCapabilities: null
    apiVersion: security.openshift.io/v1
    defaultAddCapabilities: null
    fsGroup:
      type: MustRunAs
    groups:
    - system:authenticated
    kind: SecurityContextConstraints
    metadata:
      annotations:
      name: restricted-pvselinux
    priority: null
    readOnlyRootFilesystem: false
    requiredDropCapabilities:
    - KILL
    - MKNOD
    - SETUID
    - SETGID
    runAsUser:
      type: MustRunAsRange
    seLinuxContext:
      seLinuxOptions:
        level: s0:c26,c0
      type: MustRunAs
    supplementalGroups:
      type: RunAsAny
    users: []
    volumes:
    - configMap
    - downwardAPI
    - emptyDir
    - persistentVolumeClaim
    - projected
    - secret
    EOF
    $ oc create -f scc.yaml
  2. 배포에 대한 서비스 계정을 생성하고 새로 생성된 scc 에 추가합니다.

    1. 서비스 계정을 생성합니다.

      $ oc create serviceaccount <service_account_name>
      <service_account_name>

      서비스 계정의 이름을 지정합니다.

      예 5.42. 예제

      $ oc create serviceaccount testnamespacesa
    2. 새로 생성된 scc 에 서비스 계정을 추가합니다.

      $ oc adm policy add-scc-to-user restricted-pvselinux -z <service_account_name>

      예 5.43. 예제

      $ oc adm policy add-scc-to-user restricted-pvselinux -z testnamespacesa
  3. 새로 생성된 서비스 계정을 사용하도록 레거시 애플리케이션 배포를 패치합니다. 이제 배포에 SELinux 레이블을 지정할 수 있습니다.

    $ oc patch dc/<pod_name> '{"spec":{"template":{"spec":{"serviceAccountName": "<service_account_name>"}}}}'

    예 5.44. 예제

    $ oc patch dc/cephfs-write-workload-generator-no-cache --patch '{"spec":{"template":{"spec":{"serviceAccountName": "testnamespacesa"}}}}'
  4. 배포를 편집하여 배포 구성의 SELinux 라벨에서 사용할 보안 컨텍스트를 지정합니다.

    $ oc edit dc <pod_name> -n <application_namespace>

    다음 행을 추가합니다.

    spec:
     template:
        metadata:
          securityContext:
            seLinuxOptions:
              Level: <security_context_value>
    <security_context_value>

    명령을 실행하여 NSFS 공유 내에 S3용 전용 폴더를 생성할 때 레거시 애플리케이션 Pod의 CephFS PV 및 PVC에서 이 값을 찾을 수 있습니다.

    예 5.45. 예제

    $ oc edit dc cephfs-write-workload-generator-no-cache -n testnamespace
    spec:
     template:
        metadata:
          securityContext:
            seLinuxOptions:
              level: s0:c26,c0
  5. 배포 구성의 SELinux 레이블에서 사용할 보안 컨텍스트가 올바르게 지정되었는지 확인합니다.

    $ oc get dc <pod_name> -n <application_namespace> -o yaml | grep -A 2 securityContext

    예 5.46. 예제

    $ oc get dc cephfs-write-workload-generator-no-cache -n testnamespace -o yaml | grep -A 2 securityContext

    예 5.47. 출력 예

          securityContext:
            seLinuxOptions:
              level: s0:c26,c0

    레거시 애플리케이션이 재시작되어 openshift-storage 네임스페이스와 동일한 SELinux 레이블을 사용하기 시작합니다.

6장. Multicloud Object Gateway에서 보안을 강화하기 위해 기본 계정 자격 증명 변경

애플리케이션 문제를 방지하고 더 나은 계정 보안을 보장하기 위해 명령줄 인터페이스를 사용하여 MCG(Multicloud Object Gateway) 계정 자격 증명을 변경하고 순환합니다.

기본 MCG 계정 자격 증명을 변경하는 방법에 대한 자세한 내용은 Red Hat Knowledgebase 솔루션에서 기본 계정 자격 증명을 변경하여 Multicloud Object Gateway에서 보안을 개선하는 방법을 참조하십시오.

7장. 하이브리드 및 멀티 클라우드 버킷의 데이터 미러링

MCG(Multicloud Object Gateway)는 클라우드 공급자와 클러스터 전체에서 데이터를 포괄하는 프로세스를 간소화합니다.

사전 요구 사항

그런 다음 데이터 관리 정책 미러링을 반영하는 버킷 클래스를 생성합니다.

절차

다음 세 가지 방법으로 미러링 데이터를 설정할 수 있습니다.

7.1. MCG 명령줄 인터페이스를 사용하여 데이터를 미러링하는 버킷 클래스 생성

  1. MCG(Multicloud Object Gateway) 명령줄 인터페이스에서 다음 명령을 실행하여 미러링 정책으로 버킷 클래스를 생성합니다.

    $ noobaa bucketclass create placement-bucketclass mirror-to-aws --backingstores=azure-resource,aws-resource --placement Mirror
  2. 새로 생성된 버킷 클래스를 새 버킷 클레임으로 설정하고 두 위치 간에 미러링될 새 버킷을 생성합니다.

    $ noobaa obc create  mirrored-bucket --bucketclass=mirror-to-aws

7.2. YAML을 사용하여 데이터를 미러링하도록 버킷 클래스 생성

  1. 다음 YAML을 적용합니다. 이 YAML은 로컬 Ceph 스토리지와 AWS 간의 데이터를 미러링하는 하이브리드 예입니다.

    apiVersion: noobaa.io/v1alpha1
    kind: BucketClass
    metadata:
      labels:
        app: noobaa
      name: <bucket-class-name>
      namespace: openshift-storage
    spec:
      placementPolicy:
        tiers:
        - backingStores:
          - <backing-store-1>
          - <backing-store-2>
          placement: Mirror
  2. 표준 OBC(오브젝트 버킷 클레임)에 다음 행을 추가합니다.

    additionalConfig:
      bucketclass: mirror-to-aws

    OBC에 대한 자세한 내용은 10장. 개체 버킷 클레임 의 내용을 참조하십시오.

7.3. 사용자 인터페이스를 사용하여 데이터를 미러링하도록 버킷 구성

  1. OpenShift 웹 콘솔에서 스토리지 → 데이터 기반 을 클릭합니다.
  2. 상태 카드에서 Storage System (스토리지 시스템)을 클릭하고 표시되는 팝업에서 스토리지 시스템 링크를 클릭합니다.
  3. Object(개체 ) 탭에서 Multicloud Object Gateway(Multicloud Object Gateway) 링크를 클릭합니다.
  4. NooBaa 페이지의 왼쪽에 있는 버킷 아이콘을 클릭합니다. 버킷 목록은 다음과 같습니다.

    MCG noobaa 버킷 아이콘
  5. 업데이트할 버킷을 클릭합니다.
  6. 계층 1 리소스 편집을 클릭합니다.

    MCG 계층 1 리소스 편집
  7. Mirror 를 선택하고 이 버킷에 사용할 관련 리소스를 확인합니다. 다음 예제에서는 AWS에 있는 RGW 및 AWS 지원 저장소에 있는 noobaa-default-backing-store 간 데이터를 미러링합니다.

    MCG 미러 관련 리소스
  8. 저장을 클릭합니다.
참고

NooBaa UI에서 생성된 리소스는 OpenShift UI 또는 MCG(Multicloud Object Gateway) CLI에서 사용할 수 없습니다.

8장. Multicloud Object Gateway의 버킷 정책

OpenShift Data Foundation은 AWS S3 버킷 정책을 지원합니다. 버킷 정책을 사용하면 버킷 및 해당 객체에 대한 액세스 권한을 사용자에게 부여할 수 있습니다.

8.1. 버킷 정책 정보

버킷 정책은 AWS S3 버킷 및 오브젝트에 대한 권한을 부여할 수 있는 액세스 정책 옵션입니다. 버킷 정책은 JSON 기반 액세스 정책 언어를 사용합니다. 액세스 정책 언어에 대한 자세한 내용은 AWS Access Policy Language Overview 를 참조하십시오.

8.2. 버킷 정책 사용

사전 요구 사항

절차

MCG에서 버킷 정책을 사용하려면 다음을 수행합니다.

  1. JSON 형식으로 버킷 정책을 생성합니다. 다음 예제를 참조하십시오.

    {
        "Version": "NewVersion",
        "Statement": [
            {
                "Sid": "Example",
                "Effect": "Allow",
                "Principal": [
                        "john.doe@example.com"
                ],
                "Action": [
                    "s3:GetObject"
                ],
                "Resource": [
                    "arn:aws:s3:::john_bucket"
                ]
            }
        ]
    }

    버킷 정책에는 액세스 권한과 관련하여 사용 가능한 많은 요소가 있습니다.

    이러한 요소 및 액세스 권한을 제어하는 데 사용할 수 있는 방법에 대한 예제에 대한 자세한 내용은 AWS Access Policy Language 개요 를 참조하십시오.

    버킷 정책의 예를 보려면 AWS 버킷 정책 예제 를 참조하십시오.

    S3 사용자를 생성하는 방법은 8.3절. “Multicloud Object Gateway에서 AWS S3 사용자 생성” 에서 확인할 수 있습니다.

  2. AWS S3 클라이언트를 사용하여 put-bucket-policy 명령을 사용하여 버킷 정책을 S3 버킷에 적용합니다.

    # aws --endpoint ENDPOINT --no-verify-ssl s3api put-bucket-policy --bucket MyBucket --policy BucketPolicy
    1. S3 엔드포인트로 ENDPOINT 를 교체합니다.
    2. MyBucket 을 버킷으로 교체하여 정책을 에 설정합니다.
    3. BucketPolicy 를 버킷 정책 JSON 파일로 교체합니다.
    4. 기본 자체 서명 인증서를 사용하는 경우 --no-verify-ssl 을 추가합니다.

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

      # aws --endpoint https://s3-openshift-storage.apps.gogo44.noobaa.org --no-verify-ssl s3api put-bucket-policy -bucket MyBucket --policy file://BucketPolicy

      put-bucket-policy 명령에 대한 자세한 내용은 put-bucket-policy 에 대한 AWS CLI 명령 참조를 참조하십시오.

      참고

      principal 요소는 버킷과 같은 리소스에 대한 액세스가 허용되거나 거부된 사용자를 지정합니다. 현재는 NooBaa 계정만 주체로 사용할 수 있습니다. 개체 버킷 클레임의 경우 NooBaa는 자동으로 계정 obc-account.<generated 버킷 이름>@noobaa.io 를 생성합니다.

      참고

      버킷 정책 조건이 지원되지 않습니다.

8.3. Multicloud Object Gateway에서 AWS S3 사용자 생성

사전 요구 사항

절차

  1. OpenShift 웹 콘솔에서 스토리지 → 데이터 기반 을 클릭합니다.
  2. 상태 카드에서 Storage System (스토리지 시스템)을 클릭하고 표시되는 팝업에서 스토리지 시스템 링크를 클릭합니다.
  3. Object(개체 ) 탭에서 Multicloud Object Gateway(Multicloud Object Gateway) 링크를 클릭합니다.
  4. Accounts (계정) 탭에서 Create Account(계정 만들기 )를 클릭합니다.

    MCG 계정 생성 버튼
  5. S3 액세스만 선택하고 계정 이름 (예: john.doe@example.com)을 입력합니다 . 다음을 클릭합니다.

    MCG create account s3 user
  6. S3 기본 배치 (예: noobaa-default-backing-store )를 선택합니다. 버킷 권한을 선택합니다. 특정 버킷 또는 모든 버킷을 선택할 수 있습니다. 생성을 클릭합니다.

    MCG create account s3 user2

9장. Multicloud Object Gateway 버킷 복제

한 MCG(Multicloud Object Gateway) 버킷에서 다른 MCG 버킷으로 데이터 복제를 수행하면 복원력이 뛰어나고 협업 옵션이 향상됩니다. 이러한 버킷은 지원되는 스토리지 솔루션(S3, Azure 등)에서 지원하는 데이터 버킷 또는 네임 스페이스 버킷일 수 있습니다.

복제 정책은 복제 규칙 목록으로 구성됩니다. 각 규칙은 대상 버킷을 정의하고 오브젝트 키 접두사를 기반으로 필터를 지정할 수 있습니다. 두 번째 버킷에서 복제 정책을 보완하면 양방향 복제가 생성됩니다.

사전 요구 사항

  • 실행 중인 OpenShift Data Foundation Platform.
  • Multicloud Object Gateway에 액세스하여 애플리케이션을 사용하여 Multicloud Object Gateway에 액세스하는 링크를 참조하십시오.
  • MCG(Multicloud Object Gateway) 명령줄 인터페이스를 다운로드합니다.

    # subscription-manager repos --enable=rh-odf-4-for-rhel-8-x86_64-rpms
    # yum install mcg
    중요

    서브스크립션 관리자를 사용하여 리포지토리를 활성화하기 위한 적절한 아키텍처를 지정합니다. 예를 들어 IBM Power의 경우 다음 명령을 사용합니다.

    # subscription-manager repos --enable=rh-odf-4-for-rhel-8-ppc64le-rpms
  • 또는 https://access.redhat.com/downloads/content/547/ver=4/rhel---8/4/x86_64/packages에 있는 OpenShift Data Foundation RPM에서 mcg 패키지를 설치할 수도 있습니다.

    중요

    아키텍처에 따라 올바른 제품 변형을 선택합니다.

    참고

    특정 MCG 기능은 특정 MCG 버전에서만 사용할 수 있으며 MCG의 기능을 완전히 활용하려면 해당 MCG CLI 도구 버전을 사용해야 합니다.

버킷을 복제하려면 다른 버킷에 버킷 복제를 참조하십시오.

버킷 클래스 복제 정책을 설정하려면 버킷 클래스 복제 정책 설정을 참조하십시오.

9.1. 다른 버킷에 버킷 복제

다음과 같은 두 가지 방법으로 버킷 복제 정책을 설정할 수 있습니다.

9.1.1. MCG 명령줄 인터페이스를 사용하여 다른 버킷에 버킷 복제

특정 복제 정책이 필요한 MCG(Multicloud Object Gateway) 버킷이 필요한 애플리케이션에서는 OBC(오브젝트 버킷 클레임)를 생성하고 JSON 파일에서 복제 정책 매개 변수를 정의할 수 있습니다.

절차

  • MCG 명령줄 인터페이스에서 다음 명령을 실행하여 특정 복제 정책으로 OBC를 생성합니다.

    noobaa obc create <bucket-claim-name> -n openshift-storage --replication-policy /path/to/json-file.json
    <bucket-claim-name>
    버킷 클레임의 이름을 지정합니다.
    /path/to/json-file.json

    복제 정책을 정의하는 JSON 파일의 경로입니다.

    JSON 파일의 예:

    [{ "rule_id": "rule-1", "destination_bucket": "first.bucket", "filter": {"prefix": "repl"}}]
    "prefix"
    은 선택 사항입니다. 복제해야 하는 오브젝트 키의 접두사이며, 비어 있을 수도 있습니다(예: {"prefix": ""} ).

    예 9.1. 예제

    noobaa obc create my-bucket-claim -n openshift-storage --replication-policy /path/to/json-file.json

9.1.2. YAML을 사용하여 다른 버킷에 버킷 복제

특정 복제 정책이 있도록 MCG(Multicloud Object Gateway) 데이터 버킷이 필요한 애플리케이션에서 OBC(Object Bucket Claim)를 생성하고 spec.additionalConfig.replication-policy 매개변수를 OBC에 추가할 수 있습니다.

절차

  • 다음 YAML을 적용합니다.

    apiVersion: objectbucket.io/v1alpha1
    kind: ObjectBucketClaim
    metadata:
      name: <desired-bucket-claim>
      namespace: <desired-namespace>
    spec:
      generateBucketName: <desired-bucket-name>
      storageClassName: openshift-storage.noobaa.io
      additionalConfig:
        replication-policy: [{ "rule_id": "<rule id>", "destination_bucket": "first.bucket", "filter": {"prefix": "<object name prefix>"}}]
    <desired-bucket-claim>
    버킷 클레임의 이름을 지정합니다.
    <desired-namespace>
    네임스페이스를 지정합니다.
    <desired-bucket-name>
    버킷 이름의 접두사를 지정합니다.
    "rule_id"
    규칙의 ID 번호를 지정합니다(예: {"rule_id": "rule-1"} ).
    "destination_bucket"
    대상 버킷의 이름을 지정합니다(예: {"destination_bucket": "first.bucket"} ).
    "prefix"
    은 선택 사항입니다. 복제해야 하는 오브젝트 키의 접두사이며, 비어 있을 수도 있습니다(예: {"prefix": ""} ).

추가 정보

9.2. 버킷 클래스 복제 정책 설정

특정 버킷 클래스에서 생성된 모든 버킷에 자동으로 적용되는 복제 정책을 설정할 수 있습니다. 다음 두 가지 방법으로 이 작업을 수행할 수 있습니다.

9.2.1. MCG 명령줄 인터페이스를 사용하여 버킷 클래스 복제 정책 설정

특정 복제 정책이 필요한 Multicloud Object Gateway(MCG) 버킷 클래스가 필요한 애플리케이션은 버킷 클래스를 생성하고 JSON 파일에 replication-policy 매개 변수를 정의할 수 있습니다.

두 가지 유형의 버킷 클래스에 대해 버킷 클래스 복제 정책을 설정할 수 있습니다.

  • 배치
  • 네임스페이스

절차

  • MCG 명령줄 인터페이스에서 다음 명령을 실행합니다.

    noobaa -n openshift-storage bucketclass create placement-bucketclass <bucketclass-name> --backingstores <backingstores> --replication-policy=/path/to/json-file.json
    <bucketclass-name>
    버킷 클래스의 이름을 지정합니다.
    <BackingStores>
    백업 저장소의 이름을 지정합니다. 쉼표로 구분된 여러 백업 저장소를 전달할 수 있습니다.
    /path/to/json-file.json

    복제 정책을 정의하는 JSON 파일의 경로입니다.

    JSON 파일의 예:

    [{ "rule_id": "rule-1", "destination_bucket": "first.bucket", "filter": {"prefix": "repl"}}]
    "prefix"
    은 선택 사항입니다. 복제해야 하는 오브젝트 키의 접두사이며, 비어 있을 수도 있습니다(예: {"prefix": ""} ).

    예 9.2. 예제

    noobaa -n openshift-storage bucketclass create placement-bucketclass bc --backingstores azure-blob-ns --replication-policy=/path/to/json-file.json

    이 예제에서는 JSON 파일에 정의된 특정 복제 정책을 사용하여 배치 버킷 클래스를 생성합니다.

9.2.2. YAML을 사용하여 버킷 클래스 복제 정책 설정

특정 복제 정책이 필요한 Multicloud Object Gateway(MCG) 버킷 클래스가 필요한 애플리케이션은 spec.replicationPolicy 필드를 사용하여 버킷 클래스를 생성할 수 있습니다.

절차

  1. 다음 YAML을 적용합니다.

    apiVersion: noobaa.io/v1alpha1
    kind: BucketClass
    metadata:
      labels:
        app: <desired-app-label>
      name: <desired-bucketclass-name>
      namespace: <desired-namespace>
    spec:
      placementPolicy:
        tiers:
        - backingstores:
          - <backingstore>
          placement: Spread
      replicationPolicy: [{ "rule_id": "<rule id>", "destination_bucket": "first.bucket", "filter": {"prefix": "<object name prefix>"}}]

    이 YAML은 배치 버킷 클래스를 생성하는 예입니다. 버킷에 업로드된 각 Object 버킷 클레임(OBC) 오브젝트는 접두사를 기반으로 필터링되며 first.bucket.bucket에 복제됩니다.

    <desired-app-label>
    앱의 레이블을 지정합니다.
    <desired-bucketclass-name>
    버킷 클래스 이름을 지정합니다.
    <desired-namespace>
    버킷 클래스가 생성되는 네임스페이스를 지정합니다.
    <BackingStore>
    백업 저장소의 이름을 지정합니다. 여러 개의 백업 저장소를 전달할 수 있습니다.
    "rule_id"
    규칙의 ID 번호를 지정합니다(예: '{"rule_id": "rule-1"} ).
    "destination_bucket"
    대상 버킷의 이름을 지정합니다(예: {"destination_bucket": "first.bucket"} ).
    "prefix"
    은 선택 사항입니다. 복제해야 하는 오브젝트 키의 접두사이며, 비어 있을 수도 있습니다(예: {"prefix": ""} ).

10장. 개체 버킷 클레임

개체 버킷 클레임은 워크로드에 대해 S3 호환 버킷 백엔드를 요청하는 데 사용할 수 있습니다.

다음 세 가지 방법으로 오브젝트 버킷 클레임을 생성할 수 있습니다.

개체 버킷 클레임은 새 액세스 키 및 시크릿 액세스 키를 포함하여 버킷에 대한 권한이 있는 NooBaa에 새 버킷 및 애플리케이션 계정을 생성합니다. 애플리케이션 계정은 단일 버킷에만 액세스할 수 있으며 기본적으로 새 버킷을 생성할 수 없습니다.

10.1. 동적 개체 버킷 클레임

영구 볼륨과 유사하게 애플리케이션의 YAML에 개체 버킷 클레임(OBC)의 세부 정보를 추가하고, 오브젝트 서비스 엔드포인트, 액세스 키 및 시크릿에서 사용 가능한 시크릿 액세스 키를 가져올 수 있습니다. 이 정보를 애플리케이션의 환경 변수로 동적으로 읽기가 쉽습니다.

참고

Multicloud Object Gateway 끝점은 OpenShift에서 자체 서명된 인증서를 사용하는 경우에만 자체 서명 인증서를 사용합니다. OpenShift에서 서명된 인증서를 사용하면 Multicloud Object Gateway 엔드포인트 인증서를 서명된 인증서로 자동 대체합니다. 브라우저를 통해 끝점에 액세스하여 Multicloud Object Gateway에서 현재 사용하는 인증서를 가져옵니다. 자세한 내용은 애플리케이션을 사용하여 Multicloud Object Gateway 액세스를 참조하십시오.

절차

  1. 애플리케이션 YAML에 다음 행을 추가합니다.

    apiVersion: objectbucket.io/v1alpha1
    kind: ObjectBucketClaim
    metadata:
      name: <obc-name>
    spec:
      generateBucketName: <obc-bucket-name>
      storageClassName: openshift-storage.noobaa.io

    이 행은 OBC 자체입니다.

    1. <obc-name> 을 고유한 OBC 이름으로 바꿉니다.
    2. <obc-bucket-name> 을 OBC의 고유한 버킷 이름으로 바꿉니다.
  2. YAML 파일에 더 많은 줄을 추가하여 OBC 사용을 자동화할 수 있습니다. 아래 예제는 데이터를 사용한 구성 맵과 인증 정보가 있는 시크릿인 버킷 클레임 결과 간의 매핑입니다. 이 특정 작업은 NooBaa의 개체 버킷을 클레임하여 버킷과 계정을 생성합니다.

    apiVersion: batch/v1
    kind: Job
    metadata:
      name: testjob
    spec:
      template:
        spec:
          restartPolicy: OnFailure
          containers:
            - image: <your application image>
              name: test
              env:
                - name: BUCKET_NAME
                  valueFrom:
                    configMapKeyRef:
                      name: <obc-name>
                      key: BUCKET_NAME
                - name: BUCKET_HOST
                  valueFrom:
                    configMapKeyRef:
                      name: <obc-name>
                      key: BUCKET_HOST
                - name: BUCKET_PORT
                  valueFrom:
                    configMapKeyRef:
                      name: <obc-name>
                      key: BUCKET_PORT
                - name: AWS_ACCESS_KEY_ID
                  valueFrom:
                    secretKeyRef:
                      name: <obc-name>
                      key: AWS_ACCESS_KEY_ID
                - name: AWS_SECRET_ACCESS_KEY
                  valueFrom:
                    secretKeyRef:
                      name: <obc-name>
                      key: AWS_SECRET_ACCESS_KEY
    1. <obc-name> 의 모든 인스턴스를 OBC 이름으로 바꿉니다.
    2. <your 애플리케이션 이미지> 를 애플리케이션 이미지로 바꿉니다.
  3. 업데이트된 YAML 파일을 적용합니다.

    # oc apply -f <yaml.file>

    <yaml.file> 을 YAML 파일의 이름으로 바꿉니다.

  4. 새 구성 맵을 보려면 다음을 실행합니다.

    # oc get cm <obc-name> -o yaml

    obc-name 을 OBC 이름으로 바꿉니다.

    출력에 다음 환경 변수가 있을 수 있습니다.

    • BUCKET_HOST - 애플리케이션에서 사용할 엔드 포인트입니다.
    • BUCKET_PORT - 애플리케이션에 사용할 수 있는 포트입니다.

    • BUCKET_NAME - 요청되거나 생성된 버킷 이름입니다.
    • AWS_ACCESS_KEY_ID - 자격 증명의 일부인 액세스 키입니다.
    • AWS_SECRET_ACCESS_KEY - 자격 증명의 일부인 비밀 액세스 키입니다.
중요

AWS_ACCESS_KEY_IDAWS_SECRET_ACCESS_KEY 를 검색합니다. 이름은 AWS S3 API와 호환되도록 사용됩니다. 특히 MCG(Multicloud Object Gateway) 버킷에서 S3 작업을 수행하는 동안 키를 지정해야 합니다. 키는 Base64로 인코딩됩니다. 키를 사용하기 전에 디코딩합니다.

# oc get secret <obc_name> -o yaml
<obc_name>
오브젝트 버킷 클레임의 이름을 지정합니다.

10.2. 명령줄 인터페이스를 사용하여 개체 버킷 클레임 생성

명령줄 인터페이스를 사용하여 OBC(오브젝트 버킷 클레임)를 생성할 때 애플리케이션에서 오브젝트 스토리지 서비스를 사용하는 데 필요한 모든 정보가 포함된 구성 맵과 시크릿을 가져옵니다.

사전 요구 사항

  • MCG(Multicloud Object Gateway) 명령줄 인터페이스를 다운로드합니다.

    # subscription-manager repos --enable=rh-odf-4-for-rhel-8-x86_64-rpms
    # yum install mcg
    참고

    서브스크립션 관리자를 사용하여 리포지토리를 활성화하기 위한 적절한 아키텍처를 지정합니다.

    • IBM Power의 경우 다음 명령을 사용합니다.
    # subscription-manager repos --enable=rh-odf-4-for-rhel-8-ppc64le-rpms
    • IBM Z 인프라의 경우 다음 명령을 사용합니다.
    # subscription-manager repos --enable=rh-odf-4-for-rhel-8-s390x-rpms

절차

  1. 명령줄 인터페이스를 사용하여 새 버킷 및 자격 증명의 세부 정보를 생성합니다. 다음 명령을 실행합니다.

    # noobaa obc create <obc-name> -n openshift-storage

    <obc-name> 을 고유한 OBC 이름으로 바꿉니다(예: myappobc ).

    또한 --app-namespace 옵션을 사용하여 OBC 구성 맵과 시크릿이 생성되는 네임스페이스(예: myapp-namespace )를 지정할 수 있습니다.

    출력 예:

    INFO[0001] ✅ Created: ObjectBucketClaim "test21obc"

    MCG 명령줄-인터페이스에서 필요한 구성을 생성하고 OpenShift에 새 OBC에 대해 알립니다.

  2. 다음 명령을 실행하여 OBC를 확인합니다.

    # oc get obc -n openshift-storage

    출력 예:

    NAME        STORAGE-CLASS                 PHASE   AGE
    test21obc   openshift-storage.noobaa.io   Bound   38s
  3. 다음 명령을 실행하여 새 OBC에 대한 YAML 파일을 확인합니다.

    # oc get obc test21obc -o yaml -n openshift-storage

    출력 예:

    apiVersion: objectbucket.io/v1alpha1
    kind: ObjectBucketClaim
    metadata:
      creationTimestamp: "2019-10-24T13:30:07Z"
      finalizers:
      - objectbucket.io/finalizer
      generation: 2
      labels:
        app: noobaa
        bucket-provisioner: openshift-storage.noobaa.io-obc
        noobaa-domain: openshift-storage.noobaa.io
      name: test21obc
      namespace: openshift-storage
      resourceVersion: "40756"
      selfLink: /apis/objectbucket.io/v1alpha1/namespaces/openshift-storage/objectbucketclaims/test21obc
      uid: 64f04cba-f662-11e9-bc3c-0295250841af
    spec:
      ObjectBucketName: obc-openshift-storage-test21obc
      bucketName: test21obc-933348a6-e267-4f82-82f1-e59bf4fe3bb4
      generateBucketName: test21obc
      storageClassName: openshift-storage.noobaa.io
    status:
      phase: Bound
  4. openshift-storage 네임스페이스 내에서 이 OBC를 사용할 구성 맵과 시크릿을 찾을 수 있습니다. CM 및 시크릿의 이름은 OBC와 동일합니다. 다음 명령을 실행하여 보안을 확인합니다.

    # oc get -n openshift-storage secret test21obc -o yaml

    출력 예:

    Example output:
    apiVersion: v1
    data:
      AWS_ACCESS_KEY_ID: c0M0R2xVanF3ODR3bHBkVW94cmY=
      AWS_SECRET_ACCESS_KEY: Wi9kcFluSWxHRzlWaFlzNk1hc0xma2JXcjM1MVhqa051SlBleXpmOQ==
    kind: Secret
    metadata:
      creationTimestamp: "2019-10-24T13:30:07Z"
      finalizers:
      - objectbucket.io/finalizer
      labels:
        app: noobaa
        bucket-provisioner: openshift-storage.noobaa.io-obc
        noobaa-domain: openshift-storage.noobaa.io
      name: test21obc
      namespace: openshift-storage
      ownerReferences:
      - apiVersion: objectbucket.io/v1alpha1
        blockOwnerDeletion: true
        controller: true
        kind: ObjectBucketClaim
        name: test21obc
        uid: 64f04cba-f662-11e9-bc3c-0295250841af
      resourceVersion: "40751"
      selfLink: /api/v1/namespaces/openshift-storage/secrets/test21obc
      uid: 65117c1c-f662-11e9-9094-0a5305de57bb
    type: Opaque

    시크릿은 S3 액세스 자격 증명을 제공합니다.

  5. 구성 맵을 보려면 다음 명령을 실행합니다.

    # oc get -n openshift-storage cm test21obc -o yaml

    출력 예:

    apiVersion: v1
    data:
      BUCKET_HOST: 10.0.171.35
      BUCKET_NAME: test21obc-933348a6-e267-4f82-82f1-e59bf4fe3bb4
      BUCKET_PORT: "31242"
      BUCKET_REGION: ""
      BUCKET_SUBREGION: ""
    kind: ConfigMap
    metadata:
      creationTimestamp: "2019-10-24T13:30:07Z"
      finalizers:
      - objectbucket.io/finalizer
      labels:
        app: noobaa
        bucket-provisioner: openshift-storage.noobaa.io-obc
        noobaa-domain: openshift-storage.noobaa.io
      name: test21obc
      namespace: openshift-storage
      ownerReferences:
      - apiVersion: objectbucket.io/v1alpha1
        blockOwnerDeletion: true
        controller: true
        kind: ObjectBucketClaim
        name: test21obc
        uid: 64f04cba-f662-11e9-bc3c-0295250841af
      resourceVersion: "40752"
      selfLink: /api/v1/namespaces/openshift-storage/configmaps/test21obc
      uid: 651c6501-f662-11e9-9094-0a5305de57bb

    구성 맵에는 애플리케이션의 S3 끝점 정보가 포함되어 있습니다.

10.3. OpenShift 웹 콘솔을 사용하여 개체 버킷 클레임 생성

OpenShift 웹 콘솔을 사용하여 OBC(오브젝트 버킷 클레임)를 생성할 수 있습니다.

사전 요구 사항

  • OpenShift 웹 콘솔에 대한 관리 액세스.
  • 애플리케이션이 OBC와 통신하려면 configmap 및 secret을 사용해야 합니다. 이에 대한 자세한 내용은 10.1절. “동적 개체 버킷 클레임” 의 내용을 참조하십시오.

절차

  1. OpenShift 웹 콘솔에 로그인합니다.
  2. 왼쪽 네비게이션 바에서 스토리지개체 버킷 클레임 → 개체 버킷 클레임 생성을 클릭합니다.

    1. 오브젝트 버킷 클레임의 이름을 입력하고 드롭다운 메뉴에서 배포(내부 또는 외부)를 기반으로 적절한 스토리지 클래스를 선택합니다.

      내부 모드
      개체 버킷 클레임 생성 마법사

      배포 후에 생성된 다음 스토리지 클래스를 사용할 수 있습니다.

      • oCS-storagecluster-ceph-rgw 는 Ceph Object Gateway(RGW)를 사용합니다.
      • openshift-storage.noobaa.io 는 MCG(Multicloud Object Gateway)를 사용합니다.
      외부 모드
      개체 버킷 클레임 생성 마법사

      배포 후에 생성된 다음 스토리지 클래스를 사용할 수 있습니다.

      • oCS-external-storagecluster-ceph-rgw 에서 RGW 사용
      • openshift-storage.noobaa.io 는 MCG를 사용합니다.

        참고

        RGW OBC 스토리지 클래스는 OpenShift Data Foundation 버전 4.5의 새로운 설치에서만 사용할 수 있습니다. 이전 OpenShift Data Foundation 릴리스에서 업그레이드된 클러스터에는 적용되지 않습니다.

    2. 생성을 클릭합니다.

      OBC를 생성하면 세부 정보 페이지로 리디렉션됩니다.

      개체 버킷 클레임 세부 정보 페이지

10.4. 배포에 오브젝트 버킷 클레임 연결

생성되고 나면 OBC(오브젝트 버킷 클레임)를 특정 배포에 연결할 수 있습니다.

사전 요구 사항

  • OpenShift 웹 콘솔에 대한 관리 액세스.

절차

  1. 왼쪽 네비게이션 바에서 스토리지개체 버킷 클레임 을 클릭합니다.
  2. 생성한 OBC 옆에 있는 작업 메뉴(kube) 를 클릭합니다.

    1. 드롭다운 메뉴에서 Attach to Deployment (배포에 연결)를 선택합니다.

      배포에 개체 버킷 클레임 연결
    2. Deployment Name(배포 이름) 목록에서 원하는 배포를 선택한 다음 Attach(연결 )를 클릭합니다.

      배포 이름 목록

10.5. OpenShift 웹 콘솔을 사용하여 오브젝트 버킷 보기

OpenShift 웹 콘솔을 사용하여 OBC(오브젝트 버킷 클레임)에 대해 생성된 개체 버킷의 세부 정보를 볼 수 있습니다.

사전 요구 사항

  • OpenShift 웹 콘솔에 대한 관리 액세스.

절차

  1. OpenShift 웹 콘솔에 로그인합니다.
  2. 왼쪽 네비게이션 바에서 스토리지개체 버킷을 클릭합니다.

    개체 버킷 페이지

    또는 특정 OBC의 세부 정보 페이지로 이동하고 리소스 링크를 클릭하여 해당 OBC의 개체 버킷을 볼 수도 있습니다.

  3. 세부 정보를 볼 개체 버킷을 선택합니다. 오브젝트 버킷 세부 정보 페이지로 이동합니다.

10.6. 개체 버킷 클레임 삭제

사전 요구 사항

  • OpenShift 웹 콘솔에 대한 관리 액세스.

절차

  1. 왼쪽 네비게이션 바에서 스토리지개체 버킷 클레임 을 클릭합니다.
  2. 삭제할 OBC (오브젝트 버킷 클레임) 옆에 있는 작업 메뉴(kube)를 클릭합니다.

    MCG OBC 작업 메뉴 첨부
    1. 개체 버킷 클레임 삭제를 선택합니다.
    2. 삭제를 클릭합니다.

11장. 오브젝트 버킷의 캐싱 정책

캐시 버킷은 hub 대상 및 캐시 대상이 있는 네임스페이스 버킷입니다. hub 대상은 S3 호환 가능한 대형 오브젝트 스토리지 버킷입니다. 캐시 버킷은 로컬 MCG(Multicloud Object Gateway) 버킷입니다. AWS 버킷 또는 IBM COS 버킷을 캐시하는 캐시 버킷을 생성할 수 있습니다.

11.1. AWS 캐시 버킷 생성

사전 요구 사항

  • MCG(Multicloud Object Gateway) 명령줄 인터페이스를 다운로드합니다.

    # subscription-manager repos --enable=rh-odf-4-for-rhel-8-x86_64-rpms
    # yum install mcg
    참고

    서브스크립션 관리자를 사용하여 리포지토리를 활성화하기 위한 적절한 아키텍처를 지정합니다. IBM Z 인프라의 경우 다음 명령을 사용합니다.

    # subscription-manager repos --enable=rh-odf-4-for-rhel-8-s390x-rpms

    또는 https://access.redhat.com/downloads/content/547/ver=4/rhel---8/4/x86_64/package 에 있는 OpenShift Data Foundation RPM에서 MCG 패키지를 설치할 수도 있습니다.

    참고

    아키텍처에 따라 올바른 제품 변형을 선택합니다.

절차

  1. 네임스페이스 저장소 리소스를 생성합니다. 네임 스페이스 저장소는 MCG 네임 스페이스 버킷의 데이터에 대한 읽기 또는 쓰기 대상으로 사용할 기본 스토리지를 나타냅니다. MCG 명령줄 인터페이스에서 다음 명령을 실행합니다.

    noobaa namespacestore create aws-s3 <namespacestore> --access-key <AWS ACCESS KEY> --secret-key <AWS SECRET ACCESS KEY> --target-bucket <bucket-name>
    1. <namespacestore> 를 네임스페이스 저장소의 이름으로 바꿉니다.
    2. <AWS ACCESS KEY><AWS SECRET ACCESS KEY> 를 이 목적을 위해 생성한 AWS 액세스 키 ID 및 시크릿 액세스 키로 바꿉니다.
    3. <bucket-name> 을 기존 AWS 버킷 이름으로 바꿉니다. 이 인수는 MCG에 백업 저장소에 대상 버킷으로 사용할 버킷을 알려줍니다. 그런 다음 데이터 스토리지 및 관리에 사용됩니다.

      YAML을 적용하여 스토리지 리소스를 추가할 수도 있습니다. 먼저 인증 정보를 사용하여 보안을 생성합니다.

      apiVersion: v1
      kind: Secret
      metadata:
        name: <namespacestore-secret-name>
      type: Opaque
      data:
        AWS_ACCESS_KEY_ID: <AWS ACCESS KEY ID ENCODED IN BASE64>
        AWS_SECRET_ACCESS_KEY: <AWS SECRET ACCESS KEY ENCODED IN BASE64>

      Base64를 사용하여 자체 AWS 액세스 키 ID 및 시크릿 액세스 키를 제공하고 인코딩해야 하며 <AWS ACCESS KEY ID ENCODED in BASE64> 및 < AWS SECRET ACCESS KEY ENCODED in BASE64> 대신 결과를 사용해야 합니다.

      <namespacestore-secret-name> 을 고유한 이름으로 바꿉니다.

      그런 다음 다음 YAML을 적용합니다.

      apiVersion: noobaa.io/v1alpha1
      kind: NamespaceStore
      metadata:
        finalizers:
        - noobaa.io/finalizer
        labels:
          app: noobaa
        name: <namespacestore>
        namespace: openshift-storage
      spec:
        awsS3:
          secret:
            name: <namespacestore-secret-name>
            namespace: <namespace-secret>
          targetBucket: <target-bucket>
        type: aws-s3
    4. <namespacestore> 를 고유한 이름으로 바꿉니다.
    5. <namespacestore-secret-name> 을 이전 단계에서 생성한 보안으로 바꿉니다.
    6. <namespace-secret> 을 이전 단계에서 보안을 생성하는 데 사용된 네임스페이스로 바꿉니다.
    7. <target-bucket> 을 네임스페이스 저장소용으로 생성한 AWS S3 버킷으로 바꿉니다.
  2. 다음 명령을 실행하여 버킷 클래스를 생성합니다.

    noobaa bucketclass create namespace-bucketclass cache <my-cache-bucket-class> --backingstores <backing-store> --hub-resource <namespacestore>
    1. <my-cache-bucket-class> 를 고유한 버킷 클래스 이름으로 바꿉니다.
    2. <backing-store> 를 관련 백업 저장소로 바꿉니다. 이 필드에 쉼표로 구분된 하나 이상의 백업 저장소를 나열할 수 있습니다.
    3. <namespacestore> 를 이전 단계에서 생성한 네임스페이스 저장소로 바꿉니다.
  3. 다음 명령을 실행하여 2단계에 정의된 버킷 클래스를 사용하는 OBC(개체 버킷 클레임) 리소스를 사용하여 버킷을 생성합니다.

    noobaa obc create <my-bucket-claim> my-app --bucketclass <custom-bucket-class>
    1. <my-bucket-claim> 을 고유한 이름으로 바꿉니다.
    2. <custom-bucket-class> 를 2단계에서 생성된 버킷 클래스의 이름으로 바꿉니다.

11.2. IBM COS 캐시 버킷 생성

사전 요구 사항

  • MCG(Multicloud Object Gateway) 명령줄 인터페이스를 다운로드합니다.

    # subscription-manager repos --enable=rh-odf-4-for-rhel-8-x86_64-rpms
    # yum install mcg
    참고

    서브스크립션 관리자를 사용하여 리포지토리를 활성화하기 위한 적절한 아키텍처를 지정합니다.

    • IBM Power의 경우 다음 명령을 사용합니다.
    # subscription-manager repos --enable=rh-odf-4-for-rhel-8-ppc64le-rpms
    • IBM Z 인프라의 경우 다음 명령을 사용합니다.
    # subscription-manager repos --enable=rh-odf-4-for-rhel-8-s390x-rpms

    또는 https://access.redhat.com/downloads/content/547/ver=4/rhel---8/4/x86_64/package 에 있는 OpenShift Data Foundation RPM에서 MCG 패키지를 설치할 수도 있습니다.

    참고

    아키텍처에 따라 올바른 제품 변형을 선택합니다.

절차

  1. 네임스페이스 저장소 리소스를 생성합니다. 네임 스페이스 저장소는 MCG 네임 스페이스 버킷의 데이터에 대한 읽기 또는 쓰기 대상으로 사용할 기본 스토리지를 나타냅니다. MCG 명령줄 인터페이스에서 다음 명령을 실행합니다.

    noobaa namespacestore create ibm-cos <namespacestore> --endpoint <IBM COS ENDPOINT> --access-key <IBM ACCESS KEY> --secret-key <IBM SECRET ACCESS KEY> --target-bucket <bucket-name>
    1. <namespacestore> 를 네임 스페이스 저장소의 이름으로 바꿉니다.
    2. <IBM ACCESS KEY>, <IBM SECRET ACCESS KEY>, <IBM COS ENDPOINT> 를 IBM 액세스 키 ID, 시크릿 액세스 키 및 기존 IBM 버킷 위치에 해당하는 해당 지역 엔드포인트로 바꿉니다.
    3. <bucket-name> 을 기존 IBM 버킷 이름으로 바꿉니다. 이 인수는 MCG에 백업 저장소에 대상 버킷으로 사용할 버킷을 알려줍니다. 그런 다음 데이터 스토리지 및 관리에 사용됩니다.

      YAML을 적용하여 스토리지 리소스를 추가할 수도 있습니다. 먼저 인증 정보를 사용하여 보안을 생성합니다.

      apiVersion: v1
      kind: Secret
      metadata:
        name: <namespacestore-secret-name>
      type: Opaque
      data:
        IBM_COS_ACCESS_KEY_ID: <IBM COS ACCESS KEY ID ENCODED IN BASE64>
        IBM_COS_SECRET_ACCESS_KEY: <IBM COS SECRET ACCESS KEY ENCODED IN BASE64>

      Base64를 사용하여 자체 IBM COS 액세스 키 ID 및 비밀 액세스 키를 제공하고 인코딩해야 하며 <IBM COS COS 키 ID ENCODED IN BASE64> 및 < IBM COS SECRET ACCESS KEY ENCODED IN BASE64> 대신 결과를 사용해야 합니다.

      <namespacestore-secret-name> 을 고유한 이름으로 바꿉니다.

      그런 다음 다음 YAML을 적용합니다.

      apiVersion: noobaa.io/v1alpha1
      kind: NamespaceStore
      metadata:
        finalizers:
        - noobaa.io/finalizer
        labels:
          app: noobaa
        name: <namespacestore>
        namespace: openshift-storage
      spec:
        s3Compatible:
          endpoint: <IBM COS ENDPOINT>
          secret:
            name: <backingstore-secret-name>
            namespace: <namespace-secret>
          signatureVersion: v2
          targetBucket: <target-bucket>
        type: ibm-cos
    4. <namespacestore> 를 고유한 이름으로 바꿉니다.
    5. <IBM COS ENDPOINT> 를 적절한 IBM COS 엔드포인트로 바꿉니다.
    6. <backingstore-secret-name> 을 이전 단계에서 생성한 보안으로 바꿉니다.
    7. <namespace-secret> 을 이전 단계에서 보안을 생성하는 데 사용된 네임스페이스로 바꿉니다.
    8. <target-bucket> 을 네임스페이스 저장소용으로 생성한 AWS S3 버킷으로 바꿉니다.
  2. 다음 명령을 실행하여 버킷 클래스를 생성합니다.

    noobaa bucketclass create namespace-bucketclass cache <my-bucket-class> --backingstores <backing-store> --hubResource <namespacestore>
    1. <my-bucket-class> 를 고유한 버킷 클래스 이름으로 바꿉니다.
    2. <backing-store> 를 관련 백업 저장소로 바꿉니다. 이 필드에 쉼표로 구분된 하나 이상의 백업 저장소를 나열할 수 있습니다.
    3. <namespacestore> 를 이전 단계에서 생성한 네임스페이스 저장소로 바꿉니다.
  3. 다음 명령을 실행하여 2단계에 정의된 버킷 클래스를 사용하는 개체 버킷 클레임 리소스를 사용하여 버킷을 생성합니다.

    noobaa obc create <my-bucket-claim> my-app --bucketclass <custom-bucket-class>
    1. <my-bucket-claim> 을 고유한 이름으로 바꿉니다.
    2. <custom-bucket-class> 를 2단계에서 생성된 버킷 클래스의 이름으로 바꿉니다.

12장. 끝점을 추가하여 Multicloud Object Gateway 성능 확장

MCG(Multicloud Object Gateway) 성능은 한 환경마다 다를 수 있습니다. 경우에 따라 특정 애플리케이션에는 S3 엔드포인트를 확장하여 쉽게 처리할 수 있는 더 빠른 성능이 필요한 경우도 있습니다.

MCG 리소스 풀은 기본적으로 두 가지 유형의 서비스를 제공하는 NooBaa 데몬 컨테이너 그룹입니다.

  • 스토리지 서비스
  • S3 끝점 서비스

S3 끝점 서비스

S3 엔드포인트는 MCG에서 과중한 데이터 다이제스트를 처리하는 모든 MCG(Multicloud Object Gateway)가 기본적으로 제공하는 서비스입니다. 엔드포인트 서비스는 인라인 데이터 청크, 중복 제거, 압축 및 암호화를 처리하고 MCG의 데이터 배치 명령을 허용합니다.

12.1. MultiCloud Object Gateway 엔드 포인트 자동 확장

MCG(MultiCloud Object Gateway) 끝점의 수는 MCG S3 서비스의 부하가 증가하거나 감소하면 자동으로 확장됩니다. OpenShift Data Foundation 클러스터는 하나의 활성 MCG 엔드 포인트와 함께 배포됩니다. 각 MCG 끝점 포드는 기본적으로 1개의 CPU 및 2Gi 메모리 요청으로 구성되며 요청과 일치하는 제한이 있습니다. 엔드포인트의 CPU 로드가 일관된 기간 동안 80%의 사용 임계값을 초과하면 첫 번째 엔드포인트의 부하를 줄이는 두 번째 엔드포인트가 배포됩니다. 두 끝점의 평균 CPU 로드가 일관된 기간 동안 80% 임계값 미만으로 떨어지면 엔드포인트 중 하나가 삭제됩니다. 이 기능을 사용하면 MCG의 성능 및 서비스 성능이 향상됩니다.

12.2. 스토리지 노드를 사용하여 Multicloud Object Gateway 확장

사전 요구 사항

  • MCG(Multicloud Object Gateway)에 액세스할 수 있는 OpenShift Container Platform에서 실행 중인 OpenShift Data Foundation 클러스터입니다.

MCG의 스토리지 노드는 하나 이상의 PV(영구 볼륨)에 연결되고 로컬 오브젝트 서비스 데이터 스토리지에 사용되는 NooBaa 데몬 컨테이너입니다. NooBaa 데몬은 Kubernetes 노드에 배포할 수 있습니다. 이 작업은 StatefulSet Pod로 구성된 Kubernetes 풀을 생성하여 수행할 수 있습니다.

절차

  1. OpenShift 웹 콘솔에 로그인합니다.
  2. MCG 사용자 인터페이스에서 개요스토리지 리소스 추가를 클릭합니다.
  3. 창에서 Deploy Kubernetes Pool (Kubernetes 풀 배포)을 클릭합니다.
  4. Create Pool(풀 만들기 ) 단계에서 향후 설치된 노드의 대상 풀을 생성합니다.
  5. 구성 단계에서 요청된 Pod 수 및 각 PV 크기를 구성합니다. 새 포드마다 하나의 PV가 생성되어야 합니다.
  6. 검토 단계에서 새 풀의 세부 정보를 찾고 사용할 배포 방법을 선택할 수 있습니다(로컬 또는 외부 배포). 로컬 배포를 선택하면 Kubernetes 노드가 클러스터 내에 배포됩니다. 외부 배포를 선택하면 외부에서 실행할 YAML 파일이 제공됩니다.
  7. 모든 노드는 첫 번째 단계에서 선택한 풀에 할당되며 리소스 → 스토리지 리소스 → 리소스 이름에서 확인할 수 있습니다.

13장. RADOS 오브젝트 게이트웨이 S3 끝점 액세스

사용자는 RGW(RADOS Object Gateway) 엔드포인트에 직접 액세스할 수 있습니다.

이전 버전의 Red Hat OpenShift Data Foundation에서는 RGW 공용 경로를 생성하기 위해 RGW 서비스를 수동으로 노출해야 했습니다. OpenShift Data Foundation 버전 4.7부터 RGW 경로는 기본적으로 생성되며 rook-ceph-rgw-ocs-storagecluster-cephobjectstore 입니다.