Skip to main content
본 한국어 번역은 사용자 편의를 위해 제공되는 기계 번역입니다. 영어 버전과 한국어 버전이 서로 어긋나는 경우에는 언제나 영어 버전이 우선합니다.

크로스 그리드 복제란 무엇인가요?

PDF

크로스 그리드 복제는 연결된 두 개의 StorageGRID 시스템에서 선택된 S3 버킷 간의 객체를 자동으로 복제하는 것입니다."그리드 페더레이션 연결" . "계정 복제" 크로스 그리드 복제에 필요합니다.

크로스 그리드 복제를 위한 워크플로

워크플로 다이어그램은 두 그리드의 버킷 간에 크로스 그리드 복제를 구성하는 단계를 요약한 것입니다.

크로스 그리드 복제 워크플로

크로스 그리드 복제에 대한 요구 사항

테넌트 계정에 하나 이상의 그리드 페더레이션 연결 사용 권한이 있는 경우"그리드 페더레이션 연결" 루트 액세스 권한이 있는 테넌트 사용자는 각 그리드의 해당 테넌트 계정에 동일한 버킷을 생성할 수 있습니다. 이 버킷:

  • 이름은 동일해야 하지만 지역은 다를 수 있습니다.

  • 버전 관리가 활성화되어 있어야 합니다.

  • S3 객체 잠금을 비활성화해야 합니다.

  • 비어 있어야 합니다

두 버킷이 모두 생성된 후에는 두 버킷 중 하나 또는 모두에 대해 크로스 그리드 복제를 구성할 수 있습니다.

자세히 알아보기

"그리드 간 복제 관리"

크로스 그리드 복제 작동 방식

크로스 그리드 복제는 단방향 또는 양방향으로 발생하도록 구성할 수 있습니다.

한 방향으로 복제

한 그리드의 버킷에 대해서만 교차 그리드 복제를 활성화하는 경우 해당 버킷(소스 버킷)에 추가된 객체는 다른 그리드의 해당 버킷(대상 버킷)에 복제됩니다. 하지만 대상 버킷에 추가된 객체는 소스로 다시 복제되지 않습니다. 그림에서 크로스 그리드 복제가 활성화되었습니다. my-bucket 그리드 1에서 그리드 2로의 전송은 가능하지만, 반대 방향으로는 전송이 불가능합니다.

한 방향으로 그리드 연합 연결을 보여주는 이미지

양방향 복제

두 그리드에서 동일한 버킷에 대해 교차 그리드 복제를 활성화하면, 어느 한 버킷에 추가된 객체가 다른 그리드에 복제됩니다. 그림에서 크로스 그리드 복제가 활성화되었습니다. my-bucket 양방향으로.

한 방향 복제와 양방향 복제를 비교한 이미지

객체가 섭취되면 어떤 일이 일어날까요?

S3 클라이언트가 크로스 그리드 복제가 활성화된 버킷에 객체를 추가하면 다음이 발생합니다.

  1. StorageGRID 소스 버킷의 객체를 대상 버킷으로 자동으로 복제합니다. 이 백그라운드 복제 작업을 수행하는 데 걸리는 시간은 보류 중인 다른 복제 작업의 수를 포함한 여러 요인에 따라 달라집니다.

    S3 클라이언트는 GetObject 또는 HeadObject 요청을 실행하여 객체의 복제 상태를 확인할 수 있습니다. 응답에는 StorageGRID 관련 항목이 포함됩니다. x-ntap-sg-cgr-replication-status 응답 헤더는 다음 값 중 하나를 갖습니다. S3 클라이언트는 GetObject 또는 HeadObject 요청을 발행하여 객체의 복제 상태를 확인할 수 있습니다. 응답에는 StorageGRID 관련 항목이 포함됩니다. x-ntap-sg-cgr-replication-status 응답 헤더는 다음 값 중 하나를 갖습니다.

    그리드 복제 상태

    원천

    • 완료: 모든 그리드 연결에 대한 복제가 성공적으로 완료되었습니다.

    • 보류 중: 개체가 적어도 하나의 그리드 연결에 복제되지 않았습니다.

    • 실패: 모든 그리드 연결에 대한 복제가 보류되지 않았으며 적어도 하나는 영구적인 오류로 실패했습니다. 사용자는 오류를 해결해야 합니다.

    목적지

    REPLICA: 개체가 소스 그리드에서 복제되었습니다.
    참고 StorageGRID 지원하지 않습니다 x-amz-replication-status 헤더.

  2. StorageGRID 다른 객체와 마찬가지로 각 그리드의 활성 ILM 정책을 사용하여 객체를 관리합니다. 예를 들어, 그리드 1의 객체 A는 두 개의 복제된 사본으로 저장되어 영구적으로 보관될 수 있는 반면, 그리드 2에 복제된 객체 A의 사본은 2+1 삭제 코딩을 사용하여 저장되고 3년 후에 삭제될 수 있습니다.

객체가 삭제되면 어떤 일이 일어날까요?

에서 설명한 대로"데이터 흐름 삭제" StorageGRID 다음과 같은 이유로 객체를 삭제할 수 있습니다.

  • S3 클라이언트가 삭제 요청을 발행합니다.

  • 테넌트 관리자 사용자는 다음을 선택합니다."버킷에서 객체 삭제" 버킷에서 모든 객체를 제거하는 옵션입니다.

  • 버킷에는 만료되는 수명 주기 구성이 있습니다.

  • 해당 객체에 대한 ILM 규칙의 마지막 기간이 종료되었으며, 더 이상 배치가 지정되지 않았습니다.

StorageGRID 버킷 작업, 버킷 수명 주기 만료 또는 ILM 배치 만료로 인해 객체를 삭제하는 경우, 복제된 객체는 그리드 페더레이션 연결의 다른 그리드에서 삭제되지 않습니다. 그러나 S3 클라이언트 삭제로 인해 소스 버킷에 추가된 삭제 마커는 선택적으로 대상 버킷에 복제될 수 있습니다.

S3 클라이언트가 크로스 그리드 복제가 활성화된 버킷에서 객체를 삭제할 때 어떤 일이 발생하는지 알아보려면 다음과 같이 S3 클라이언트가 버전 관리가 활성화된 버킷에서 객체를 삭제하는 방식을 검토하세요.

  • S3 클라이언트가 버전 ID를 포함하는 삭제 요청을 발행하면 해당 버전의 객체가 영구적으로 제거됩니다. 버킷에 삭제 마커가 추가되지 않습니다.

  • S3 클라이언트가 버전 ID를 포함하지 않는 삭제 요청을 발행하는 경우 StorageGRID 어떠한 객체 버전도 삭제하지 않습니다. 대신 버킷에 삭제 마커를 추가합니다. 삭제 마커를 사용하면 StorageGRID 개체가 삭제된 것처럼 작동합니다.

    • 버전 ID가 없는 GetObject 요청은 다음과 같이 실패합니다. 404 No Object Found

    • 유효한 버전 ID가 있는 GetObject 요청은 성공하고 요청된 개체 버전을 반환합니다.

S3 클라이언트가 크로스 그리드 복제가 활성화된 버킷에서 객체를 삭제하면 StorageGRID 다음과 같이 삭제 요청을 대상에 복제할지 여부를 결정합니다.

  • 삭제 요청에 버전 ID가 포함되어 있는 경우 해당 개체 버전은 소스 그리드에서 영구적으로 제거됩니다. 하지만 StorageGRID 버전 ID가 포함된 삭제 요청을 복제하지 않으므로 대상에서 동일한 개체 버전이 삭제되지 않습니다.

  • 삭제 요청에 버전 ID가 포함되지 않은 경우 StorageGRID 버킷에 대해 크로스 그리드 복제가 구성된 방식에 따라 선택적으로 삭제 마커를 복제할 수 있습니다.

    • 삭제 마커를 복제하도록 선택하는 경우(기본값), 삭제 마커가 소스 버킷에 추가되고 대상 버킷에 복제됩니다. 실제로 해당 객체는 두 그리드 모두에서 삭제된 것처럼 보입니다.

    • 삭제 마커를 복제하지 않도록 선택하면 삭제 마커가 소스 버킷에 추가되지만 대상 버킷에는 복제되지 않습니다. 실제로 소스 그리드에서 삭제된 개체는 대상 그리드에서 삭제되지 않습니다.

그림에서 *삭제 마커 복제*는 *예*로 설정되었습니다."크로스 그리드 복제가 활성화되었습니다." . 버전 ID가 포함된 소스 버킷에 대한 삭제 요청은 대상 버킷에서 개체를 삭제하지 않습니다. 버전 ID가 포함되지 않은 소스 버킷에 대한 삭제 요청은 대상 버킷의 객체를 삭제하는 것처럼 보입니다.

두 그리드 모두에서 복제 클라이언트 삭제를 보여주는 이미지
참고 그리드 간에 개체 삭제를 동기화하려면 해당 항목을 만듭니다."S3 라이프사이클 구성" 두 그리드의 버킷에 대해서.

암호화된 객체가 복제되는 방식

그리드 간 개체를 복제하기 위해 크로스 그리드 복제를 사용하는 경우 개별 개체를 암호화하고, 기본 버킷 암호화를 사용하거나, 그리드 전체 암호화를 구성할 수 있습니다. 버킷에 대한 크로스 그리드 복제를 활성화하기 전이나 후에 기본 버킷이나 그리드 전체 암호화 설정을 추가, 수정 또는 제거할 수 있습니다.

개별 객체를 암호화하려면 소스 버킷에 객체를 추가할 때 SSE( StorageGRID 에서 관리하는 키를 사용한 서버 측 암호화)를 사용할 수 있습니다. 사용하다 x-amz-server-side-encryption 요청 헤더 및 지정 AES256 . 보다 "서버 측 암호화를 사용하세요" .

참고 고객이 제공한 키를 사용한 서버 측 암호화(SSE-C)는 크로스 그리드 복제에 지원되지 않습니다. 수집 작업이 실패합니다.

버킷에 대한 기본 암호화를 사용하려면 PutBucketEncryption 요청을 사용하고 다음을 설정합니다. SSEAlgorithm 매개변수 AES256 . 버킷 수준 암호화는 수집된 모든 객체에 적용됩니다. x-amz-server-side-encryption 요청 헤더. 보다 "버킷 작업" .

그리드 수준 암호화를 사용하려면 저장된 개체 암호화 옵션을 *AES-256*으로 설정합니다. 그리드 수준 암호화는 버킷 수준에서 암호화되지 않거나 암호화되지 않은 모든 개체에 적용됩니다. x-amz-server-side-encryption 요청 헤더. 보다 "네트워크 및 개체 옵션 구성" .

참고 SSE는 AES-128을 지원하지 않습니다. AES-128 옵션을 사용하여 소스 그리드에 대해 저장된 개체 암호화 옵션이 활성화된 경우, AES-128 알고리즘 사용이 복제된 개체로 전파되지 않습니다. 대신 복제된 개체는 대상의 기본 버킷이나 그리드 수준 암호화 설정(사용 가능한 경우)을 사용합니다.

StorageGRID 소스 객체를 암호화하는 방법을 결정할 때 다음 규칙을 적용합니다.

  1. 사용하다 x-amz-server-side-encryption 헤더가 있으면 수집합니다.

  2. 수집 헤더가 없으면 구성된 경우 버킷 기본 암호화 설정을 사용합니다.

  3. 버킷 설정이 구성되지 않은 경우, 구성된 경우 그리드 전체 암호화 설정을 사용합니다.

  4. 그리드 전체 설정이 없으면 소스 개체를 암호화하지 마세요.

복제된 객체를 암호화하는 방법을 결정할 때 StorageGRID 다음 규칙을 다음 순서로 적용합니다.

  1. 해당 개체가 AES-128 암호화를 사용하지 않는 한, 소스 개체와 동일한 암호화를 사용합니다.

  2. 소스 개체가 암호화되지 않았거나 AES-128을 사용하는 경우 대상 버킷의 기본 암호화 설정(구성된 경우)을 사용합니다.

  3. 대상 버킷에 암호화 설정이 없으면 대상의 그리드 전체 암호화 설정(구성된 경우)을 사용합니다.

  4. 그리드 전체 설정이 없으면 대상 개체를 암호화하지 마세요.

PutObjectTagging 및 DeleteObjectTagging은 지원되지 않습니다.

PutObjectTagging 및 DeleteObjectTagging 요청은 크로스 그리드 복제가 활성화된 버킷의 개체에 대해 지원되지 않습니다.

S3 클라이언트가 PutObjectTagging 또는 DeleteObjectTagging 요청을 발행하는 경우 501 Not Implemented 반환됩니다. 메시지는 Put(Delete) ObjectTagging is not available for buckets that have cross-grid replication configured .

분할된 객체가 복제되는 방식

소스 그리드의 최대 세그먼트 크기는 대상 그리드에 복제된 개체에 적용됩니다. 객체가 다른 그리드에 복제되면 소스 그리드의 최대 세그먼트 크기 설정(구성 > 시스템 > 저장소 옵션)이 두 그리드 모두에 사용됩니다. 예를 들어, 소스 그리드의 최대 세그먼트 크기가 1GB이고 대상 그리드의 최대 세그먼트 크기가 50MB라고 가정해 보겠습니다. 소스 그리드에서 2GB 객체를 수집하는 경우 해당 객체는 두 개의 1GB 세그먼트로 저장됩니다. 해당 그리드의 최대 세그먼트 크기가 50MB인 경우에도 대상 그리드에 1GB 세그먼트 두 개로 복제됩니다.