절차

1. OpenShift 웹 콘솔에서 스토리지 → OpenShift Data Foundation 을 클릭합니다.
2. 백업 저장소 탭을 클릭합니다.
3. 백업 저장소 생성 을 클릭합니다.

4. 새 백업 저장소 생성 페이지에서 다음을 수행합니다.

   1. 백업 저장소 이름을 입력합니다.
   2. 공급자를 선택합니다.
   3. Region 을 선택합니다.
   4. 끝점을 입력합니다. 이는 선택 사항입니다.

   5. 드롭다운 목록에서 보안을 선택하거나 고유 보안을 생성합니다. 필요한 경우 필요한 시크릿 을 채울 수 있는 자격 증명 보기로 전환 할 수 있습니다.

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

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

      참고

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

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

검증 단계

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

절차

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

   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 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"

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 끝점 액세스를 참조하십시오.

절차

1. OpenShift 웹 콘솔에서 스토리지 → OpenShift Data Foundation 을 클릭합니다.
2. Storage Systems 탭에서 스토리지 시스템을 선택한 다음 개요 → 오브젝트 탭을 클릭합니다.
3. Multicloud Object Gateway 링크를 선택합니다.

1. 아래에서 강조 표시된 왼쪽의 리소스 탭을 선택합니다. 채워지는 목록에서 클라우드 리소스 추가 를 선택합니다.

   

2. 새 연결 추가를 선택합니다.

   

3. 관련 네이티브 클라우드 공급자 또는 S3 호환 옵션을 선택하고 세부 정보를 입력합니다.

   

4. 새로 생성된 연결을 선택하고 기존 버킷에 매핑합니다.

   
5. 필요에 따라 백업 저장소를 만들려면 이 단계를 반복합니다.

절차

1. OpenShift 웹 콘솔에서 스토리지 → OpenShift Data Foundation 을 클릭합니다.
2. 버킷 클래스 탭을 클릭합니다.
3. Create Bucket Class 를 클릭합니다.

4. Create new Bucket Class 페이지에서 다음을 수행합니다.

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

      1. BucketClass 유형을 선택합니다. 다음 옵션 중 하나를 선택합니다.

         • 표준: MCG(Multicloud Object Gateway)에서 데이터를 소비하고, 축소, 압축 및 암호화됩니다.

         • 네임스페이스: 데이터는 중복 제거, 압축 또는 암호화를 수행하지 않고 네임 스페이스 저장소에 저장됩니다.

           기본적으로 Standard는 선택되어 있습니다.By default, Standard is selected.

      2. 버킷 클래스 이름을 입력합니다.
      3. 다음을 클릭합니다.

   2. 배치 정책에서 계층 1 - 정책 유형을 선택하고 다음을 클릭합니다. 요구 사항에 따라 옵션 중 하나를 선택할 수 있습니다.

      • 스프레드 를 사용하면 선택한 리소스에 걸쳐 데이터를 분산할 수 있습니다.
      • mirror 를 사용하면 선택한 리소스에서 데이터를 완전히 복제할 수 있습니다.
      • Add Tier 를 클릭하여 다른 정책 계층을 추가합니다.

   3. Tier 1 - Policy Type 을 Spread 로 선택한 경우 사용 가능한 목록에서 백업 저장소 리소스를 하나 이상 선택하고 다음을 클릭합니다. 또는 새 백업 저장소를 만들 수도 있습니다.

      참고

      이전 단계에서 미러링으로 정책 유형을 선택할 때 최소한 2개의 백업 저장소를 선택해야 합니다.

   4. 버킷 클래스 설정을 검토하고 확인합니다.
   5. Create Bucket Class 를 클릭합니다.

검증 단계

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

절차

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

절차

1. OpenShift 웹 콘솔에서 스토리지 → OpenShift Data Foundation 을 클릭합니다.
2. 버킷 클래스 탭을 클릭합니다.

3. 편집하려는 Bucket 클래스 옆에 있는 Action Menu (및 작업 메뉴) 를 클릭합니다.

   
4. Edit Bucket Class Resources 를 클릭합니다.

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

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

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

     
6. 저장을 클릭합니다.

절차

1. OpenShift 웹 콘솔에 로그인합니다.
2. 스토리지 → OpenShift Data Foundation을 클릭합니다.

3. 네임 스페이스 저장소 탭을 클릭하여 네임 스페이스 버킷에 사용할 네임 스페이스 저장소 리소스를 생성합니다.

   1. 네임스페이스 저장소 생성 을 클릭합니다.
   2. 네임스페이스 저장소 이름을 입력합니다.
   3. 공급자를 선택합니다.
   4. region을 선택합니다.
   5. 기존 시크릿을 선택하거나 Switch to credentials 를 클릭하여 보안 키 및 시크릿 액세스 키를 입력하여 시크릿을 생성합니다.
   6. 대상 버킷을 선택합니다.
   7. 생성을 클릭합니다.
   8. namespacestore가 Ready 상태인지 확인합니다.
   9. 원하는 양의 리소스가 있을 때까지 이러한 단계를 반복합니다.

4. 버킷 클래스 탭 → 새 버킷 클래스 생성을 클릭합니다.

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

6. 대상 리소스를 선택합니다.

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

13. Create Namespace Bucket 을 클릭합니다.

    1. 이름 선택 탭에서 네임 스페이스 버킷의 이름을 지정하고 다음을 클릭합니다.

    2. Set Placement 탭에서 다음을 수행합니다.

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

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

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에 대한 자세한 내용은 9장. 오브젝트 버킷 클레임 를 참조하십시오.

1. OpenShift 웹 콘솔에서 스토리지 → OpenShift Data Foundation 을 클릭합니다.
2. 상태 카드에서 Storage System 을 클릭하고 표시되는 팝업에서 스토리지 시스템 링크를 클릭합니다.
3. Object 탭에서 Multicloud Object Gateway 링크를 클릭합니다.

4. NooBaa 페이지에서 왼쪽의 버킷 아이콘을 클릭합니다. 버킷 목록을 볼 수 있습니다.

   
5. 업데이트하려는 버킷을 클릭합니다.

6. 계층 1 리소스 편집 을 클릭합니다.

   

7. 미러 를 선택하고 이 버킷에 사용할 관련 리소스를 확인합니다. 다음 예제에서 AWS에 있는 noobaa-default-backing-store 와 AWS에 있는 AWS-backingstore 간의 데이터가 미러링됩니다.

   
8. 저장을 클릭합니다.

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 Bucket Policy Examples 를 참조하십시오.

   S3 사용자 생성에 대한 지침은 7.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. ENDPOINT 를 S3 끝점으로 교체합니다.
   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 명령에 대한 자세한 내용은 AWS CLI 명령 참조에서 put-bucket-policy 를 참조하십시오.

      참고

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

      참고

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

절차

1. OpenShift 웹 콘솔에서 스토리지 → OpenShift Data Foundation 을 클릭합니다.
2. 상태 카드에서 Storage System 을 클릭하고 표시되는 팝업에서 스토리지 시스템 링크를 클릭합니다.
3. Object 탭에서 Multicloud Object Gateway 링크를 클릭합니다.

4. 계정 탭에서 계정 생성 을 클릭합니다.

   

5. S3 Access only 을 선택하고 계정 이름 (예: john.doe@example.com)을 제공합니다. mailto:john.doe@example.com 다음을 클릭합니다.

   

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

   

절차

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 application image> 를 애플리케이션 이미지로 바꿉니다.

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_HOST 와 관련이 있습니다. 예를 들어 BUCKET_HOST 가 https://my.example.com 이고 BUCKET_PORT 가 443이면 오브젝트 서비스의 끝점이 https://my.example.com:443 여야 합니다.
   • BUCKET_NAME - 요청되거나 생성된 버킷 이름입니다.
   • AWS_ACCESS_KEY_ID - 인증 정보의 일부인 액세스 키입니다.
   • AWS_SECRET_ACCESS_KEY - 인증 정보의 일부인 보안 액세스 키입니다.

절차

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 끝점 정보가 포함되어 있습니다.

절차

1. OpenShift 웹 콘솔에 로그인합니다.

2. 왼쪽 탐색 모음에서 스토리지 → 오브젝트 버킷 클레임 → 오브젝트 버킷 클레임 생성 을 클릭합니다.

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

      내부 모드

      

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

      • OCS-storagecluster-ceph-rgw 는 Ceph Object Gateway(RGW)를 사용합니다.
      • openshift-storage.nooba.io 는 MCG(Multicloud Object Gateway)를 사용합니다.

      외부 모드

      

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

      • OCS-external-storagecluster-ceph-rgw 는 RGW를 사용합니다.

      • openshift-storage.nooba.io 는 MCG를 사용합니다.

        참고

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

   2. 생성을 클릭합니다.

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

      

절차

1. 왼쪽 탐색 모음에서 스토리지 → 오브젝트 버킷 클레임 을 클릭합니다.

2. 생성한 OBC 옆에 있는 Action 메뉴 (octets) 를 클릭합니다.

   1. 드롭다운 메뉴에서 Attach to Deployment 를 선택합니다.

      

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

      

절차

1. OpenShift 웹 콘솔에 로그인합니다.

2. 왼쪽 탐색 모음에서 스토리지 → 오브젝트 버킷을 클릭합니다.

   

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

3. 세부 정보를 표시하려는 오브젝트 버킷을 선택합니다. 오브젝트 버킷 세부 정보 페이지로 이동합니다.

절차

1. 왼쪽 탐색 모음에서 스토리지 → 오브젝트 버킷 클레임 을 클릭합니다.

2. 삭제하려는 OBC (오브젝트 버킷 클레임) 옆에 있는 Action 메뉴(octets)를 클릭합니다.

   
   1. Delete Object Bucket Claim 을 선택합니다.
   2. 삭제를 클릭합니다.

절차

1. NamespaceStore 리소스를 생성합니다. NamespaceStore는 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> 를 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> 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> 을 namespacestore에 대해 생성한 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> 를 이전 단계에서 생성한 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단계에서 생성된 버킷 클래스의 이름으로 바꿉니다.

절차

1. NamespaceStore 리소스를 생성합니다. NamespaceStore는 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> 를 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 ACCESS KEY ID ENCODED IN BASE64> 및 <IBM COS ACCESS KEY ENCODED IN BASE64> ACCESS KEY

      <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> 을 namespacestore에 대해 생성한 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> 를 이전 단계에서 생성한 namespacestore로 바꿉니다.

3. 다음 명령을 실행하여 2단계에서 정의된 버킷 클래스를 사용하는 Object Bucket Claim 리소스를 사용하여 버킷을 생성합니다.

   noobaa obc create <my-bucket-claim> my-app --bucketclass <custom-bucket-class>

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

절차

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