일관성 제어
변경 제안
PDF
일관성 제어는 애플리케이션의 요구에 따라 오브젝트의 가용성과 서로 다른 스토리지 노드 및 사이트 전체에서 오브젝트의 일관성 간에 균형을 조정합니다.
기본적으로 StorageGRID는 새로 생성된 개체에 대해 쓰기 후 읽기 일관성을 보장합니다. 성공적으로 완료된 PUT를 팔로우하면 새로 작성된 데이터를 읽을 수 있습니다. 기존 오브젝트, 메타데이터 업데이트 및 삭제를 덮어쓰는 것은 결국 일관성이 유지됩니다. 덮어쓰기는 일반적으로 전파되는 데 몇 초 또는 몇 분이 걸리지만 최대 15일이 소요될 수 있습니다.
오브젝트 작업을 다른 정합성 보장 레벨에서 수행하려는 경우 각 버킷 또는 각 API 작업에 대해 정합성 제어를 지정할 수 있습니다.
일관성 제어
정합성 보장 제어는 StorageGRID에서 객체를 추적하는 데 사용하는 메타데이터가 노드 간에 분산되므로 클라이언트 요청에 대한 객체의 가용성에 영향을 줍니다.
버킷 또는 API 작업에 대한 정합성 제어를 다음 값 중 하나로 설정할 수 있습니다.
| 일관성 제어 | 설명 |
|---|---|
모두 |
모든 노드가 데이터를 즉시 수신하거나 요청이 실패합니다. |
강함 - 글로벌 |
모든 사이트에서 모든 클라이언트 요청에 대해 쓰기 후 읽기 정합성을 보장합니다. |
강력한 사이트 |
사이트 내의 모든 클라이언트 요청에 대해 쓰기 후 읽기 일관성을 보장합니다. |
읽기-후-새로-쓰기 |
(기본값) 새 객체에 대한 읽기 후 쓰기 정합성을 보장하고 객체 업데이트에 대한 최종 일관성을 제공합니다. 고가용성 및 데이터 보호 보장 제공 Amazon S3 일관성 보장 과 일치합니다.
|
사용 가능(헤드 작업의 최종 일관성) |
"새 쓰기 후 다시 쓰기" 정합성 수준과 동일하게 동작하지만 헤드 작업에 대한 최종 정합성 보장만 제공합니다. 스토리지 노드를 사용할 수 없는 경우 "새 쓰기 후"보다 헤드 작업에 더 높은 가용성을 제공합니다. 헤드 작업에 대한 Amazon S3 정합성 보장과 다릅니다. |
"새 쓰기 후"와 "사용 가능한" 일관성 제어 기능을 사용합니다
헤드 또는 GET 연산에서 "read-after-new-write" 정합성 제어 또는 GET 연산에서 ""Available"" 정합성 제어를 사용하는 경우 StorageGRID는 다음과 같이 여러 단계로 조회를 수행합니다.
-
먼저 낮은 일관성을 사용하여 오브젝트를 찾습니다.
-
이 조회가 실패하면 개체 메타데이터의 모든 복사본을 사용할 수 있어야 하는 가장 높은 일관성 수준, 즉 "모두"에 도달할 때까지 다음 일관성 수준에서 조회가 반복됩니다.
머리나 GET 연산에서 "재후기입" 일관성 제어를 사용하지만 개체가 없으면 개체 조회는 항상 ""모두"" 일관성 수준에 도달합니다. 이 정합성 보장 수준에서는 객체 메타데이터의 모든 복제본을 사용할 수 있어야 하므로 하나 이상의 스토리지 노드를 사용할 수 없는 경우 500개의 내부 서버 오류가 많이 발생할 수 있습니다.
Amazon S3와 유사한 일관성 보증이 필요하지 않으면 일관성 제어를 ""사용 가능""으로 설정하여 헤드 작업에서 이러한 오류를 방지할 수 있습니다. 헤드 작업에서 ""사용 가능"" 정합성 제어를 사용할 경우 StorageGRID는 최종 일관성만 제공합니다. "모두" 정합성 보장 수준에 도달할 때까지 실패한 작업을 다시 시도하지 않으므로 객체 메타데이터의 모든 복제본을 사용할 필요가 없습니다.
API 작업에 대한 정합성 제어 지정
개별 API 작업의 정합성 제어를 설정하려면 작업에 대해 정합성 보장 제어가 지원되어야 하며 요청 헤더에 정합성 제어를 지정해야 합니다. 이 예제에서는 개체 가져오기 작업을 위해 일관성 컨트롤을 "문자열 사이트"로 설정합니다.
GET /bucket/object HTTP/1.1
Date: date
Authorization: authorization name
Host: host
Consistency-Control: strong-site
|
개체 넣기 작업과 개체 가져오기 작업 모두에 대해 동일한 일관성 컨트롤을 사용해야 합니다. |
버킷의 일관성 제어 지정
버킷의 일관성 제어를 설정하려면 StorageGRID PUT 버킷 정합성 보장 요청 및 GET 버킷 정합성 보장 요청을 사용할 수 있습니다. 또는 테넌트 관리자 또는 테넌트 관리 API를 사용할 수 있습니다.
버킷의 정합성 제어 기능을 설정할 때는 다음 사항에 유의하십시오.
-
버킷의 일관성 제어를 설정하면 버킷의 오브젝트 또는 버킷 구성에 대해 수행된 S3 작업에 사용되는 일관성 제어가 결정됩니다. 버킷 자체의 작동에는 영향을 미치지 않습니다.
-
개별 API 작업의 정합성 제어는 버킷의 정합성 제어를 재정의합니다.
-
일반적으로 버킷은 기본 일관성 제어인 "read-after-new-write"를 사용해야 합니다. 요청이 올바르게 작동하지 않는 경우 가능한 경우 응용 프로그램 클라이언트 동작을 변경합니다. 또는 클라이언트가 각 API 요청에 대한 정합성 제어를 지정하도록 구성합니다. 버킷 레벨에서만 정합성 제어를 최후의 수단으로 설정하십시오.
일관성 제어 및 ILM 규칙이 상호 작용하여 데이터 보호에 영향을 미치는 방식
일관성 제어와 ILM 규칙 모두 오브젝트의 보호 방법에 영향을 미칩니다. 이러한 설정은 상호 작용할 수 있습니다.
예를 들어, 개체가 저장될 때 사용되는 일관성 컨트롤은 오브젝트 메타데이터의 초기 배치에 영향을 미치는 반면 ILM 규칙에 대해 선택된 수집 동작은 오브젝트 복사본의 초기 배치에 영향을 줍니다. StorageGRID에서는 클라이언트 요청을 이행하기 위해 오브젝트의 메타데이터와 해당 데이터에 모두 액세스해야 하므로 일관성 수준과 수집 동작에 적합한 보호 수준을 선택하면 초기 데이터 보호 수준을 높이고 시스템 응답을 더욱 정확하게 예측할 수 있습니다.
ILM 규칙에 대해 다음과 같은 수집 동작을 사용할 수 있습니다.
-
* Strict * : ILM 규칙에 지정된 모든 사본은 클라이언트에 반환되기 전에 만들어야 합니다.
-
* 균형 *: StorageGRID는 수집 시 ILM 규칙에 지정된 모든 복제본을 생성하려고 합니다. 그렇지 않을 경우 중간 복사본이 만들어지고 클라이언트에 성공적으로 반환됩니다. ILM 규칙에 지정된 복사본은 가능한 경우 만들어집니다.
-
* 이중 커밋*: StorageGRID는 즉시 개체의 임시 복사본을 만들고 클라이언트에 성공을 반환합니다. ILM 규칙에 지정된 복사본은 가능한 경우 만들어집니다.
|
|
ILM 규칙의 수집 동작을 선택하기 전에 정보 수명 주기 관리를 통해 개체를 관리하기 위한 지침에서 이러한 설정에 대한 전체 설명을 읽어보십시오. |
일관성 제어 및 ILM 규칙이 상호 작용하는 방법의 예
다음 ILM 규칙 및 다음 일관성 수준 설정이 있는 두 사이트 그리드가 있다고 가정합니다.
-
* ILM 규칙 *: 로컬 사이트와 원격 사이트에 각각 하나씩, 두 개의 오브젝트 복사본을 만듭니다. Strict 수집 동작이 선택됩니다.
-
* Consistency level *: "trong-global"(개체 메타데이터가 모든 사이트에 즉시 배포됩니다.)
클라이언트가 오브젝트를 그리드에 저장할 때 StorageGRID는 오브젝트 복사본을 둘 다 만들고 메타데이터를 두 사이트에 분산한 다음 클라이언트에 성공을 반환합니다.
수집 성공 메시지가 표시된 시점에 객체가 손실로부터 완벽하게 보호됩니다. 예를 들어, 수집 직후 로컬 사이트가 손실되면 오브젝트 데이터와 오브젝트 메타데이터의 복사본이 원격 사이트에 계속 존재합니다. 개체를 완전히 검색할 수 있습니다.
대신 동일한 ILM 규칙 및 "'strong-site' 정합성 보장 수준을 사용한 경우 객체 데이터가 원격 사이트에 복제되었지만 객체 메타데이터가 그 위치에 배포되기 전에 클라이언트에 성공 메시지가 표시될 수 있습니다. 이 경우 오브젝트 메타데이터의 보호 수준이 오브젝트 데이터의 보호 수준과 일치하지 않습니다. 수집 후 곧바로 로컬 사이트가 손실되면 오브젝트 메타데이터가 손실됩니다. 객체를 검색할 수 없습니다.
일관성 수준과 ILM 규칙 간의 상호 관계는 복잡할 수 있습니다. 도움이 필요한 경우 NetApp에 문의하십시오.