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

교차 그리드 복제란 무엇입니까?

기여자
PDF

그리드 간 복제는 에 연결된 두 StorageGRID 시스템에서 선택한 S3 버킷 간에 오브젝트를 자동 복제하는 것입니다"그리드 페더레이션 연결". "계정 클론" 그리드 간 복제에 필요합니다.

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

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

교차 그리드 복제 워크플로우

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

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

  • 이름은 같아야 하지만 영역이 다를 수 있습니다

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

  • S3 오브젝트 잠금을 비활성화해야 합니다

  • 비어 있어야 합니다

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

자세한 정보

"교차 그리드 복제 관리"

교차 그리드 복제의 작동 방식

교차 그리드 복제는 한 방향 또는 양쪽 방향으로 실행되도록 구성할 수 있습니다.

복제 기능을 제공합니다

하나의 그리드에서만 버킷에 대해 교차 그리드 복제를 활성화하면 해당 버킷(소스 버킷)에 추가된 객체가 다른 그리드(대상 버킷)의 해당 버킷에 복제됩니다. 하지만 대상 버킷에 추가된 오브젝트는 다시 소스에 복제되지 않습니다. 그림에서 그리드 1에서 그리드 2로 교차 그리드 복제가 활성화되지만 my-bucket 다른 방향에서는 활성화되지 않습니다.

그리드 페더레이션 연결을 한 방향으로 보여 주는 이미지입니다

양방향으로 복제

두 그리드에서 동일한 버킷에 대해 교차 그리드 복제를 활성화하면 두 버킷에 추가된 객체가 다른 그리드에 복제됩니다. 그림에서 교차 그리드 복제는 양방향으로 에 대해 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는 버킷에 대해 크로스 그리드 복제가 구성된 방식에 따라 삭제 마커를 선택적으로 복제할 수 있습니다.

    • 삭제 마커(기본값)를 복제하도록 선택하면 삭제 마커가 소스 버킷에 추가되고 대상 버킷에 복제됩니다. 실제로 두 그리드에서 오브젝트가 삭제된 것으로 나타납니다.

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

그림에서 * Replicate delete marker * 는 * Yes * 로 설정되어 "교차 그리드 복제가 설정되었습니다"있습니다. 버전 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 * 옵션을 사용하여 소스 그리드에 대해 * Stored object encryption * 옵션을 활성화하면 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 세그먼트 2개로 복제됩니다.