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

StorageGRID S3 REST API가 가용성과 일관성의 균형을 유지하는 방법

PDF

일관성은 객체의 가용성과 다양한 스토리지 노드 및 사이트 간의 객체 일관성 사이의 균형을 제공합니다. 애플리케이션 요구 사항에 따라 일관성 수준을 변경할 수 있습니다.

기본적으로 StorageGRID는 새로 생성된 객체에 대해 쓰기 후 읽기 일관성을 보장합니다. PUT 작업이 성공적으로 완료된 후 발생하는 모든 GET 요청은 새로 기록된 데이터를 읽을 수 있습니다. 기존 객체 덮어쓰기, 메타데이터 업데이트 및 삭제는 최종 일관성을 보장합니다.

객체 작업을 다른 일관성 수준으로 수행하려면 다음을 수행할 수 있습니다.

  • 각 버킷에 대한 일관성을 지정합니다.

  • 각 API 작업에 대한 일관성을 지정합니다.

  • 다음 작업 중 하나를 수행하여 그리드 전체의 기본 일관성 설정을 변경하십시오.

    • 그리드 관리자에서 구성 > 시스템 > 저장소 설정 > *기본 버킷 일관성*으로 이동합니다.

    • .

      참고 그리드 전체 일관성 설정 변경은 해당 설정이 변경된 후에 생성된 버킷에만 적용됩니다. 변경 사항에 대한 자세한 내용을 확인하려면 `/var/local/log`에 있는 감사 로그를 참조하십시오(consistencyLevel 검색).

일관성 값

일관성은 StorageGRID가 객체를 추적하는 데 사용하는 메타데이터가 노드 간에 분산되는 방식에 영향을 미칩니다. 일관성은 클라이언트 요청에 대한 객체 가용성에 영향을 미칩니다.

버킷 또는 API 작업에 대한 일관성 수준을 다음 값 중 하나로 설정할 수 있습니다.

  • 모두: 모든 노드가 객체 메타데이터를 즉시 수신해야 하며, 그렇지 않으면 요청이 실패합니다.

  • Strong-global: 모든 사이트에서 모든 클라이언트 요청에 대해 쓰기 후 읽기 일관성을 보장합니다. 쿼럼 시맨틱이 구성된 경우 다음과 같은 동작이 적용됩니다.

    • 그리드에 사이트가 세 개 이상 있는 경우 클라이언트 요청에 대한 사이트 장애 허용 기능을 제공합니다. 사이트가 두 개인 그리드에는 사이트 장애 허용 기능이 없습니다.

    • 다음 S3 작업은 사이트 중 하나라도 다운되면 성공하지 못합니다.

      • DeleteBucketEncryption

      • PutBucketBranch

      • PutBucketEncryption

      • PutBucketVersioning

      • PutObjectLegalHold

      • PutObjectLockConfiguration

      • PutObjectRetention

    필요한 경우 "강력한 전역 일관성을 위해 StorageGRID 쿼럼 시맨틱 구성".

  • Strong-site: 객체 메타데이터가 사이트 내 다른 노드로 즉시 배포됩니다. 사이트 내 모든 클라이언트 요청에 대해 쓰기 후 읽기 일관성을 보장합니다.

  • Read-after-new-write: 새 객체에 대해서는 쓰기 후 읽기 일관성을 제공하고, 객체 업데이트에 대해서는 최종 일관성을 제공합니다. 높은 가용성과 데이터 보호를 보장합니다. 대부분의 경우에 권장됩니다.

  • 사용 가능: 새 객체 생성 및 객체 업데이트 모두에 대해 최종 일관성을 제공합니다. S3 버킷의 경우, 필요한 경우에만 사용하십시오(예: 거의 읽지 않는 로그 값이 포함된 버킷 또는 존재하지 않는 키에 대한 HEAD 또는 GET 작업). S3 FabricPool 버킷에서는 지원되지 않습니다.

"새로운 쓰기 후 읽기" 및 "사용 가능" 일관성 사용

HEAD 또는 GET 작업에서 "새로 쓰기 후 읽기" 일관성을 사용하는 경우 StorageGRID는 다음과 같이 여러 단계에 걸쳐 조회를 수행합니다.

  • 먼저 낮은 일관성을 사용하여 객체를 찾습니다.

  • 해당 조회가 실패하면 강력한 전역 설정에 대한 동작과 동일한 일관성 값에 도달할 때까지 다음 일관성 값에서 조회를 반복합니다.

HEAD 또는 GET 작업에서 "새로 쓰기 후 읽기" 일관성 방식을 사용하지만 객체가 존재하지 않는 경우, 객체 조회는 항상 strong-global 방식과 동일한 일관성 상태로 진행됩니다. 이 일관성 방식은 각 사이트에서 객체 메타데이터의 여러 복사본이 있어야 하므로, 동일 사이트의 스토리지 노드 두 개 이상을 사용할 수 없는 경우 500 내부 서버 오류가 많이 발생할 수 있습니다.

Amazon S3와 유사한 일관성 보장이 필요한 경우가 아니라면, HEAD 및 GET 작업에서 일관성 설정을 "Available"로 지정하여 이러한 오류를 방지할 수 있습니다. HEAD 또는 GET 작업에서 "Available" 일관성을 사용하는 경우, StorageGRID는 최종 일관성만 제공합니다. 실패한 작업에 대해 일관성 수준을 높여 재시도하지 않으므로 객체 메타데이터의 여러 복사본을 사용할 수 있어야 하는 요구 사항이 없습니다.

API 작업에 대한 일관성 지정

개별 API 작업에 대한 일관성 설정을 하려면 해당 작업에서 일관성 값이 지원되어야 하며, 요청 헤더에 일관성을 지정해야 합니다. 이 예제는 GetObject 작업에 대해 일관성을 "Strong-site"로 설정합니다.

GET /bucket/object HTTP/1.1
Date: date
Authorization: authorization name
Host: host
Consistency-Control: strong-site
참고 PutObject 및 GetObject 작업 모두에 동일한 일관성을 유지해야 합니다.

버킷에 대한 일관성 지정

버킷의 일관성을 설정하려면 StorageGRID "PUT 버킷 일관성" 요청을 사용할 수 있습니다. 또는 테넌트 관리자에서 "버킷의 일관성 변경" 할 수 있습니다.

버킷의 일관성을 설정할 때 다음 사항에 유의하십시오.

  • 버킷의 일관성 설정은 버킷의 객체 또는 버킷 구성에 대해 수행되는 S3 작업에 사용되는 일관성을 결정합니다. 이는 버킷 자체에 대한 작업에는 영향을 미치지 않습니다.

  • 개별 API 작업에 대한 일관성 설정이 버킷의 일관성 설정보다 우선합니다.

  • 일반적으로 버킷은 기본 일관성 방식인 "새 쓰기 후 읽기"를 사용해야 합니다. 요청이 제대로 작동하지 않으면 가능하면 애플리케이션 클라이언트의 동작을 변경하십시오. 또는 각 API 요청에 대해 일관성 방식을 지정하도록 클라이언트를 구성하십시오. 버킷 수준에서 일관성 방식을 설정하는 것은 최후의 수단으로만 사용하십시오.

일관성과 ILM 규칙이 상호 작용하여 데이터 보호에 영향을 미치는 방식

일관성 설정과 ILM 규칙 모두 객체 보호 방식에 영향을 미칩니다. 이러한 설정은 서로 상호 작용할 수 있습니다.

예를 들어, 객체 저장 시 사용되는 일관성 수준은 객체 메타데이터의 초기 배치에 영향을 미치며, ILM 규칙에 대해 선택된 수집 동작은 객체 복사본의 초기 배치에 영향을 미칩니다. StorageGRID는 클라이언트 요청을 처리하기 위해 객체의 메타데이터와 데이터 모두에 액세스해야 하므로, 일관성 수준과 수집 동작에 대해 동일한 수준의 보호 방식을 선택하면 초기 데이터 보호가 강화되고 시스템 응답이 더욱 예측 가능해질 수 있습니다.

다음 "수집 옵션"은(는) ILM 규칙에 사용할 수 있습니다.

이중 커밋

StorageGRID는 즉시 객체의 임시 복사본을 생성하고 클라이언트에 성공을 반환합니다. ILM 규칙에 지정된 복사본은 가능한 경우 생성됩니다.

엄격한

ILM 규칙에 명시된 모든 사본이 생성되어야만 클라이언트에 성공이 반환됩니다.

균형 잡힌

StorageGRID 데이터 수집 시 ILM 규칙에 지정된 모든 복사본을 생성하려고 시도합니다. 이것이 불가능한 경우, 임시 복사본을 생성하고 클라이언트에 성공을 반환합니다. ILM 규칙에 지정된 복사본은 가능한 경우 생성됩니다.

일관성 규칙과 ILM 규칙이 상호 작용하는 방식의 예시

다음과 같은 ILM 규칙과 일관성 조건을 갖는 3개 사이트 그리드가 있다고 가정해 보겠습니다.

  • ILM 규칙: 객체 복사본 3개를 생성합니다. 하나는 로컬 사이트에, 나머지 두 개는 각 원격 사이트에 생성합니다. 엄격한 수집 동작을 사용합니다.

  • 일관성: Strong-global(오브젝트 메타데이터가 여러 사이트에 즉시 배포됨).

클라이언트가 그리드에 객체를 저장하면 StorageGRID는 객체의 세 가지 복사본을 모두 만들고 메타데이터를 여러 사이트에 배포한 후 클라이언트에 성공 응답을 반환합니다.

객체는 메시지 수집 성공 시점에 손실로부터 완벽하게 보호됩니다. 예를 들어, 수집 직후 로컬 사이트에 장애가 발생하더라도 객체 데이터와 객체 메타데이터의 복사본이 원격 사이트에 여전히 남아 있습니다. 따라서 다른 사이트에서 객체를 완벽하게 복구할 수 있습니다.

동일한 ILM 규칙과 강력한 사이트 일관성을 사용하는 경우, 클라이언트는 객체 데이터가 원격 사이트로 복제된 후 객체 메타데이터가 배포되기 전에 성공 메시지를 수신할 수 있습니다. 이 경우 객체 메타데이터의 보호 수준이 객체 데이터의 보호 수준과 일치하지 않습니다. 수집 직후 로컬 사이트가 손실되면 객체 메타데이터도 손실됩니다. 객체를 검색할 수 없습니다.

일관성과 ILM 규칙 간의 상호 관계는 복잡할 수 있습니다. 도움이 필요하시면 NetApp에 문의하십시오.