PutObject
S3 PutObject 요청을 사용하여 버킷에 객체를 추가할 수 있습니다.
갈등을 해결하다
두 클라이언트가 같은 키에 쓰는 등 충돌하는 클라이언트 요청은 "최신 승리" 기준으로 해결됩니다. "최신 승리" 평가의 타이밍은 S3 클라이언트가 작업을 시작하는 시점이 아니라 StorageGRID 시스템이 주어진 요청을 완료하는 시점을 기준으로 합니다.
객체 크기
단일 PutObject 작업에 권장되는 최대 크기는 5GiB(5,368,709,120바이트)입니다. 5GiB보다 큰 개체가 있는 경우 다음을 사용하세요."멀티파트 업로드" 대신에.
단일 PutObject 작업에 대해 지원되는 최대 크기는 5TiB(5,497,558,138,880바이트)입니다.
|
|
StorageGRID 11.6 이하 버전에서 업그레이드한 경우 5GiB를 초과하는 객체를 업로드하려고 하면 S3 PUT 객체 크기가 너무 큼 경고가 발생합니다. StorageGRID 11.7 또는 11.8을 새로 설치한 경우 이 경우 알림이 트리거되지 않습니다. 하지만 AWS S3 표준에 맞추기 위해 StorageGRID 의 향후 릴리스에서는 5GiB보다 큰 객체의 업로드를 지원하지 않습니다. |
사용자 메타데이터 크기
Amazon S3에서는 각 PUT 요청 헤더 내의 사용자 정의 메타데이터 크기를 2KB로 제한합니다. StorageGRID 사용자 메타데이터를 24KiB로 제한합니다. 사용자 정의 메타데이터의 크기는 각 키와 값의 UTF-8 인코딩 바이트 수의 합계를 사용하여 측정됩니다.
사용자 메타데이터의 UTF-8 문자
요청에 사용자 정의 메타데이터의 키 이름이나 값에 (이스케이프되지 않은) UTF-8 값이 포함된 경우 StorageGRID 동작은 정의되지 않습니다.
StorageGRID 사용자 정의 메타데이터의 키 이름이나 값에 포함된 이스케이프된 UTF-8 문자를 구문 분석하거나 해석하지 않습니다. 이스케이프된 UTF-8 문자는 ASCII 문자로 처리됩니다.
-
사용자 정의 메타데이터에 이스케이프된 UTF-8 문자가 포함되어 있으면 PutObject, CopyObject, GetObject 및 HeadObject 요청이 성공합니다.
-
StorageGRID 다음을 반환하지 않습니다.
x-amz-missing-meta키 이름이나 값의 해석된 값에 인쇄할 수 없는 문자가 포함된 경우 헤더입니다.
객체 태그 제한
새로운 객체를 업로드할 때 태그를 추가할 수도 있고, 기존 객체에 태그를 추가할 수도 있습니다. StorageGRID 와 Amazon S3는 모두 각 객체에 대해 최대 10개의 태그를 지원합니다. 객체와 연관된 태그에는 고유한 태그 키가 있어야 합니다. 태그 키는 최대 128자의 유니코드 문자까지 가능하고, 태그 값은 최대 256자의 유니코드 문자까지 가능합니다. 키와 값은 대소문자를 구분합니다.
객체 소유권
StorageGRID 에서는 모든 객체는 버킷 소유자 계정이 소유하며, 여기에는 비소유자 계정이나 익명 사용자가 만든 객체도 포함됩니다.
지원되는 요청 헤더
다음 요청 헤더가 지원됩니다.
-
Cache-Control -
Content-Disposition -
Content-Encoding당신이 지정할 때
aws-chunked~을 위한Content-EncodingStorageGRID 다음 항목을 검증하지 않습니다.-
StorageGRID 다음을 확인하지 않습니다.
chunk-signature청크 데이터에 대하여. -
StorageGRID 귀하가 제공한 값을 확인하지 않습니다.
x-amz-decoded-content-length대상에 대하여.
-
-
Content-Language -
Content-Length -
Content-MD5 -
Content-Type -
Expires -
Transfer-Encoding청크 분할 전송 인코딩은 다음과 같은 경우 지원됩니다.
aws-chunked페이로드 서명도 사용됩니다. -
x-amz-checksum-sha256 -
x-amz-meta-, 사용자 정의 메타데이터를 포함하는 이름-값 쌍이 뒤따릅니다.사용자 정의 메타데이터에 대한 이름-값 쌍을 지정할 때 다음과 같은 일반 형식을 사용하세요.
x-amz-meta-name: value
ILM 규칙의 참조 시간으로 사용자 정의 생성 시간 옵션을 사용하려면 다음을 사용해야 합니다.
creation-time객체가 생성된 시점을 기록하는 메타데이터의 이름으로. 예를 들어:x-amz-meta-creation-time: 1443399726
에 대한 가치
creation-time1970년 1월 1일 이후의 초로 계산됩니다.ILM 규칙은 참조 시간에 대한 *사용자 정의 생성 시간*과 균형 잡힌 수집 옵션 또는 엄격한 수집 옵션을 모두 사용할 수 없습니다. ILM 규칙이 생성되면 오류가 반환됩니다. -
x-amz-tagging -
S3 객체 잠금 요청 헤더
-
x-amz-object-lock-mode -
x-amz-object-lock-retain-until-date -
x-amz-object-lock-legal-hold이러한 헤더 없이 요청이 이루어지면 버킷 기본 보존 설정을 사용하여 개체 버전 모드와 보존 기간을 계산합니다. 보다 "S3 REST API를 사용하여 S3 객체 잠금을 구성합니다." .
-
-
SSE 요청 헤더:
-
x-amz-server-side-encryption -
x-amz-server-side-encryption-customer-key-MD5 -
x-amz-server-side-encryption-customer-key -
x-amz-server-side-encryption-customer-algorithm
-
지원되지 않는 요청 헤더
다음 요청 헤더는 지원되지 않습니다.
-
x-amz-acl -
x-amz-sdk-checksum-algorithm -
x-amz-trailer -
x-amz-website-redirect-location그만큼
x-amz-website-redirect-location헤더 반환XNotImplemented.
스토리지 클래스 옵션
그만큼 x-amz-storage-class 요청 헤더가 지원됩니다. 제출된 값 x-amz-storage-class StorageGRID 수집 중에 개체 데이터를 보호하는 방법에 영향을 주며, StorageGRID 시스템에 저장된 개체의 영구 복사본 수(ILM에서 결정)에는 영향을 주지 않습니다.
수집된 개체와 일치하는 ILM 규칙이 엄격한 수집 옵션을 사용하는 경우 x-amz-storage-class 헤더는 효과가 없습니다.
다음 값을 사용할 수 있습니다. x-amz-storage-class :
-
STANDARD(기본)-
이중 커밋: ILM 규칙이 수집 동작에 대해 이중 커밋 옵션을 지정하는 경우, 객체가 수집되자마자 해당 객체의 두 번째 사본이 생성되어 다른 스토리지 노드에 배포됩니다(이중 커밋). ILM을 평가할 때 StorageGRID 이러한 초기 임시 사본이 규칙의 배치 지침을 충족하는지 확인합니다. 그렇지 않은 경우 새로운 객체 복사본을 다른 위치에 만들어야 할 수도 있고, 초기 임시 복사본을 삭제해야 할 수도 있습니다.
-
균형: ILM 규칙이 균형 옵션을 지정하고 StorageGRID 규칙에 지정된 모든 복사본을 즉시 만들 수 없는 경우 StorageGRID 서로 다른 스토리지 노드에 두 개의 임시 복사본을 만듭니다.
StorageGRID ILM 규칙(동기 배치)에 지정된 모든 개체 복사본을 즉시 생성할 수 있는 경우
x-amz-storage-class헤더는 효과가 없습니다.
-
-
REDUCED_REDUNDANCY-
이중 커밋: ILM 규칙이 수집 동작에 대해 이중 커밋 옵션을 지정하는 경우 StorageGRID 객체가 수집될 때 단일 임시 사본을 만듭니다(단일 커밋).
-
균형: ILM 규칙에서 균형 옵션을 지정하는 경우 StorageGRID 시스템이 규칙에 지정된 모든 복사본을 즉시 만들 수 없는 경우에만 단일 임시 복사본을 만듭니다. StorageGRID 동기 배치를 수행할 수 있는 경우 이 헤더는 아무런 효과가 없습니다. 그만큼
REDUCED_REDUNDANCY이 옵션은 개체와 일치하는 ILM 규칙이 단일 복제 복사본을 생성할 때 가장 잘 사용됩니다. 이 경우 사용REDUCED_REDUNDANCY모든 수집 작업에 대해 불필요한 추가 객체 복사본 생성 및 삭제를 제거합니다.
를 사용하여
REDUCED_REDUNDANCY다른 상황에서는 이 옵션을 권장하지 않습니다.REDUCED_REDUNDANCY수집 중에 객체 데이터가 손실될 위험이 높아집니다. 예를 들어, ILM 평가가 발생하기 전에 실패한 스토리지 노드에 단일 사본이 처음 저장된 경우 데이터가 손실될 수 있습니다. -
|
|
특정 기간 동안 복제된 사본이 하나만 있으면 데이터가 영구적으로 손실될 위험이 있습니다. 개체의 복제된 사본이 하나만 있는 경우 스토리지 노드에 장애가 발생하거나 심각한 오류가 발생하면 해당 개체는 손실됩니다. 업그레이드 등의 유지 관리 절차가 진행되는 동안에는 해당 객체에 대한 액세스 권한을 일시적으로 잃게 됩니다. |
지정 REDUCED_REDUNDANCY 객체가 처음 수집될 때 생성되는 복사본의 수에만 영향을 미칩니다. 이는 활성 ILM 정책에 따라 객체를 평가할 때 객체의 복사본이 얼마나 많이 만들어지는지에 영향을 미치지 않으며, StorageGRID 시스템에서 데이터가 더 낮은 수준의 중복으로 저장되는 결과를 초래하지 않습니다.
|
|
S3 객체 잠금이 활성화된 버킷에 객체를 수집하는 경우 REDUCED_REDUNDANCY 옵션은 무시됩니다. 레거시 호환 버킷에 객체를 수집하는 경우 REDUCED_REDUNDANCY 옵션이 오류를 반환합니다. StorageGRID 규정 준수 요구 사항이 충족되는지 확인하기 위해 항상 이중 커밋 수집을 수행합니다.
|
서버 측 암호화를 위한 요청 헤더
다음 요청 헤더를 사용하여 서버 측 암호화로 객체를 암호화할 수 있습니다. SSE와 SSE-C 옵션은 상호 배타적입니다.
-
SSE: StorageGRID 에서 관리하는 고유 키로 객체를 암호화하려면 다음 헤더를 사용합니다.
-
x-amz-server-side-encryption때
x-amz-server-side-encryption헤더는 PutObject 요청에 포함되지 않으며 그리드 전체"저장된 객체 암호화 설정" PutObject 응답에서 생략되었습니다.
-
-
SSE-C: 사용자가 제공하고 관리하는 고유 키로 객체를 암호화하려면 이 세 가지 헤더를 모두 사용합니다.
-
x-amz-server-side-encryption-customer-algorithm: 지정AES256. -
x-amz-server-side-encryption-customer-key: 새 개체에 대한 암호화 키를 지정합니다. -
x-amz-server-side-encryption-customer-key-MD5: 새 객체의 암호화 키의 MD5 다이제스트를 지정합니다.
-
|
|
귀하가 제공한 암호화 키는 결코 저장되지 않습니다. 암호화 키를 잃어버리면 해당 객체도 잃어버리게 됩니다. 고객이 제공한 키를 사용하여 개체 데이터를 보호하기 전에 다음 사항을 검토하십시오."서버 측 암호화 사용" . |
|
|
객체가 SSE 또는 SSE-C로 암호화된 경우 버킷 수준 또는 그리드 수준 암호화 설정은 무시됩니다. |
버전 관리
버킷에 버전 관리가 활성화된 경우 고유한 versionId 저장되는 객체의 버전에 따라 자동 생성됩니다. 이것 versionId 또한 다음을 사용하여 응답으로 반환됩니다. x-amz-version-id 응답 헤더.
버전 관리가 중단되면 개체 버전은 null로 저장됩니다. versionId 그리고 이미 null 버전이 존재하면 덮어쓰여집니다.
Authorization 헤더에 대한 서명 계산
사용 시 Authorization 요청을 인증하는 헤더를 사용하는 StorageGRID 다음과 같은 면에서 AWS와 다릅니다.
-
StorageGRID 에는 필요하지 않습니다
host포함될 헤더CanonicalHeaders. -
StorageGRID 에는 필요하지 않습니다
Content-Type~에 포함될 것CanonicalHeaders. -
StorageGRID 에는 필요하지 않습니다
x-amz-*포함될 헤더CanonicalHeaders.
|
|
일반적인 모범 사례로 항상 다음 헤더를 포함합니다. CanonicalHeaders 검증되었는지 확인합니다. 그러나 이러한 헤더를 제외하면 StorageGRID 오류를 반환하지 않습니다.
|
자세한 내용은 다음을 참조하세요. "권한 부여 헤더에 대한 서명 계산: 단일 청크로 페이로드 전송(AWS 서명 버전 4)" .