S3
（Simple Storage Service）
実装ガイド
2017年4月 | 215-12532_A0
目次
S3 REST API
のサポート ... 5
S3 REST APIのサポートに関する変更点 ... 5 サポート対象のバージョン ... 5クライアント アプリケーションでのHTTP接続の使用 ... 7
StorageGRID WebscaleにおけるS3テナント アカウント ... 7 S3 APIエンドポイントのドメイン名の指定 ... 8 APIゲートウェイ ノードとストレージ ノードのIPアドレスの特定 ... 9 APIゲートウェイ ノードとストレージ ノードのポート番号 ... 9 S3 REST APIの設定のテスト ... 9StorageGRID Webscale
でのS3 REST APIの実装 ... 11
StorageGRID WebscaleのILMルールによるオブジェクトの管理 ... 12
オブジェクトのバージョン管理 ... 13
S3 REST API
のサポートされる処理と制限事項 ... 15
エラー応答 ... 15 日付の処理 ... 16 共通の要求ヘッダー ... 16 共通の応答ヘッダー ... 17 要求の認証 ... 17 サービスの処理 ... 18 バケットの処理 ... 18 バケットのカスタム処理 ... 20 オブジェクトの処理 ... 21 マルチパート アップロードの処理 ... 26 監査ログで追跡される処理 ... 30StorageGRID Webscale
のS3 REST APIの処理 ... 32
GET Bucket consistency要求 ... 32
PUT Bucket consistency要求 ... 33
GET Storage Usage要求 ... 34
GET Bucket last access time要求 ... 35
PUT Bucket last access time要求 ... 36
REST API
のセキュリティの設定 ... 38
StorageGRID WebscaleシステムでのREST APIのセキュリティの実装 ... 38
バケットとグループのアクセス ポリシー ... 39 ポリシーの例 ... 49 REST APIを使用するクライアント アプリケーションでのセキュリティ 証明書の使用 ... 54 TLSライブラリのハッシュ アルゴリズムと暗号化アルゴリズムのサポー ト ... 54 Write-Once-Read-Many（WORM）による保護 ... 54
処理の監視と監査 ... 56
S3オブジェクトに対するトランザクションの確認 ... 56 監査ログへのアクセスと確認 ... 56
アクティブ、アイドル、および同時HTTP接続のメリット ... 58
HTTP接続の種類別のメリット ... 58 アイドルHTTP接続を開いておくメリット ... 58 アクティブHTTP接続のメリット ... 58 同時HTTP接続のメリット ... 59 読み取り処理用と書き込み処理用の別々のHTTP接続プールの使用 ... 60著作権に関する情報 ... 61
商標に関する情報 ... 62
マニュアルの更新について ... 63
索引 ... 64
S3 REST API
のサポート
StorageGRID Webscaleシステムでは、Simple Storage Service（S3）のRepresentational State
Transferアプリケーション プログラミング インターフェイス（REST API）を使用して
StorageGRID Webscaleシステムとやり取りするクライアント アプリケーションからのオブ
ジェクトの格納と取得をサポートしています。
S3 REST APIのサポートにより、S3 Webサービス用に開発されたサービス指向アプリケー
ションを、StorageGRID Webscaleシステムを使用するオンプレミスのオブジェクト ストレー ジと接続できます。クライアント アプリケーションで現在使用しているS3 REST API呼び 出しの変更は、最小限しか必要ありません。
S3 REST API
のサポートに関する変更点
StorageGRID WebscaleシステムでのS3 REST APIのサポートに関する変更点に注意する必要
があります。
次の表に、StorageGRID WebscaleシステムでのS3 REST APIのサポートに関する変更点を示し ます。
日付 リリース 説明
2014年9月 10.0 StorageGRID WebscaleシステムでS3 REST
APIのサポートが初めて導入されました。
現在サポートされているSimple Storage
Service API Referenceのバージョンは 2006-03-01です。 2015年4月 10.1 マルチパート アップロード、仮想ホスト形 式の要求、およびバージョン4の認証のサ ポートが追加されました。 2015年12月 10.2 グループとバケットのアクセス ポリシー、 およびマルチパート コピー（Upload Part -Copy）のサポートが追加されました。 2016年6月 10.3 バージョン管理のサポートが追加されまし た。 2017年4月 10.4 ILMのスキャン処理のバージョン管理に関
する変更、[Endpoint Domain Names]ページの 更新、ポリシーの条件と変数、ポリシーの 例、およびPutOverwriteObject権限のサポー トが追加されました。
サポート対象のバージョン
StorageGRID WebscaleでサポートしているS3およびHTTPのバージョンは次のとおりです。 項目 バージョン項目 バージョン
HTTP 1.1
HTTPの詳細については、HTTP/1.1（RFC 2616）を参照し
てください。 関連情報
IETF RFC 2616：『Hypertext Transfer Protocol (HTTP/1.1)』
Amazon Web Services（AWS）ドキュメント：「Amazon Simple Storage Service API Reference」
クライアント
アプリケーションでの
HTTP
接続の使用
クライアント アプリケーションでは、HTTP接続を使用してStorageGRID Webscaleシステム にアクセスし、通信を行います。 クライアント アプリケーションは、APIゲートウェイ ノードまたはストレージ ノードに直 接接続してオブジェクトを格納したり読み出したりします。取り込みの負荷をストレージ ノード間で分散するには、負荷分散を実施するAPIゲートウェイ ノードに接続します。負荷 を分散しない場合は、ストレージ ノードに直接接続します。 注：IPv6は、APIゲートウェイ ノード経由のクライアント アプリケーション接続でのみサ ポートされます。 クライアント アプリケーションからストレージ ノードのS3ポートに「OPTIONS /」HTTPS 要求を発行（S3認証クレデンシャルは不要）して、LDRサービスが使用可能かどうかを確認 できます。この要求は監視に使用できるほか、外部のロード バランサがストレージ ノード の停止を特定する目的でも使用できます。 クライアント アプリケーションへの接続を設定するには、次のタスクを実行します。 • S3テナント アカウントの作成 • APIゲートウェイ ノードとストレージ ノードのIPアドレスの特定 • APIゲートウェイ ノードとストレージ ノードのS3ポート番号の特定 • システムのCertificate Authority（CA;認証局）証明書のコピー（サーバの検証が必要なク ライアント アプリケーション用） 関連情報 StorageGRID Webscale 10.4管理者ガイドStorageGRID Webscale
における
S3
テナント
アカウント
StorageGRID Webscaleシステムでは、S3テナント アカウントを作成することで、本来はS3 Webサービスを使用するために開発されたクライアント アプリケーションと接続するよう に設定することができます。 S3テナント アカウントの作成と削除は、グリッド管理インターフェイスの[Tenants]メ ニュー オプションか管理APIを使用して行います。S3のアクセス キーやグループ ポリシー など、S3のグループとユーザの管理には、Tenant Management InterfaceまたはテナントAPIを 使用します。S3クライアントを設定する際に、認証プロセスで使用するS3アカウント情報を 指定する必要があります。詳細については、『管理者ガイド』および『テナント管理者ガイ ド』を参照してください。 関連情報 StorageGRID Webscale 10.4管理者ガイド StorageGRID Webscale 10.4テナント管理者ガイドS3 API
エンドポイントのドメイン名の指定
S3仮想ホスト形式の要求をサポートするには、S3クライアントの接続先となるエンドポイン トのドメイン名のリストを設定する必要があります。 開始する前に • グリッド管理インターフェイスにはサポートされているブラウザを使用してサインイン する必要があります。 • このタスクを実行するには、特定のアクセス権限が必要です。詳細については、管理ユー ザ アカウントおよびグループを使用したシステム アクセスの制御に関する情報を参照 してください。 タスク概要 APIエンドポイントのドメイン名は、DNSサーバで完全修飾ドメイン名を作成したあとに、 S3クライアントの接続先のノードに応じて設定します。 • ゲートウェイ ノードに接続する場合は、ゲートウェイ ノードのドメイン名をリストに含 めます。 • ストレージ ノードに接続する場合は、ストレージ ノードのドメイン名をリストに含めま す。 • 外部のロード バランサを介して接続する場合は、ロード バランサのドメイン名をリスト に含めます。 このリストが空の場合、S3仮想ホスト形式の要求のサポートは無効になります。 さらに、エンドポイントごと、および場合によってはIPアドレスごとに、StorageGRIDWebscaleシステムのカスタム サーバ証明書でワイルドカードのSubject Alternative Name
（SAN）を設定する必要があります。これらの手順は、APIクライアント アプリケーション からエンドポイントに接続する際のSSL証明書の検証とホスト名の確認で必要になります。 手順
1. [Configuration] > [Domain Names]を選択します。
[Endpoint Domain Names]ページが表示されます。
2. [+]アイコンを使用してフィールドを追加し、[Endpoint number]フィールドにS3 APIエン ドポイントのドメイン名のリストを入力して[Save]をクリックします。
警告：ドメイン名の設定は、グリッドのアップグレードの進行中は変更しないでくださ い。 関連情報 StorageGRID Webscale 10.4管理者ガイド
API
ゲートウェイ
ノードとストレージ
ノードの
IP
アドレスの特
定
APIクライアント アプリケーションをStorageGRID Webscaleに接続するには、グリッド ノー
ドのIPアドレスが必要です。 手順
1. サポートされているブラウザを使用してグリッド管理インターフェイスにログインしま す。
2. [Grid]を選択します。
3. [Grid Topology]ツリーで、接続するストレージ ノードまたはAPIゲートウェイ ノードを
選択して展開します。 選択したグリッド ノードのサービスが表示されます。 4. ストレージ ノードまたはAPIゲートウェイ ノードで、[SSM] > [Resources]を選択し、 [Network Addresses]の表までスクロールします。 一覧に表示された任意のIPアドレスを使用して、APIクライアント アプリケーションから のHTTPS接続を確立することができます。
API
ゲートウェイ
ノードとストレージ
ノードのポート番号
クライアント アプリケーションからStorageGRID WebscaleシステムへのHTTP接続は、API ゲートウェイ ノードとストレージ ノードの特定のポートでのみ確立できます。 クライアント アプリケーションからStorageGRID WebscaleシステムへのS3を使用した通信 には、次のポートが使用されます。 グリッド ノード ポート番号 APIゲートウェイ ノード（CLB S3ポート） 8082 ストレージ ノード（LDR S3ポート） 18082S3 REST API
の設定のテスト
Amazon Web Servicesコマンドライン インターフェイス（AWS CLI）を使用してシステムへ
の接続をテストし、システムに対するオブジェクトの読み取りと書き込みが可能であること を確認できます。
開始する前に
• AWS CLIをaws.amazon.com/cliからダウンロードしてインストールしておく必要がありま す。
• StorageGRID WebscaleシステムでS3テナント アカウントを作成しておく必要がありま
す。 手順
1. Amazon Web Servicesの設定で、StorageGRID Webscaleシステムで作成したアカウントを使 用するように設定します。 a. 構成モードに切り替えます。 aws configure b. 作成したアカウントのAWSアクセス キーIDを入力します。 c. 作成したアカウントのAWSシークレット アクセス キーを入力します。 d. 使用するデフォルトのリージョンを入力します（例：us-east-1）。 e. 使用するデフォルトの出力形式を入力するか、Enterキーを押してJSONを選択します。 2. バケットを作成します。
aws s3api --endpoint-url https://10.96.101.17:8082 --no-verify-ssl create-bucket --bucket testbucket
バケットの作成が完了すると、次の例のようにバケットの場所が返されます。 "Location": "/testbucket"
3. オブジェクトをアップロードします。
aws s3api --endpoint-url https://10.96.101.17:8082 --no-verify-ssl put-object --bucket testbucket --key s3.pdf --body C:\s3-test\upload \s3.pdf
オブジェクトのアップロードが完了すると、オブジェクト データのハッシュであるEtag が返されます。
4. バケットの内容をリストして、オブジェクトがアップロードされたことを確認します。 aws s3api --endpoint-url https://10.96.101.17:8082 --no-verify-ssl list-objects --bucket testbucket
5. オブジェクトを削除します。
aws s3api --endpoint-url https://10.96.101.17:8082 --no-verify-ssl delete-object --bucket testbucket --key s3.pdf
6. バケットを削除します。
aws s3api --endpoint-url https://10.96.101.17:8082 --no-verify-ssl delete-bucket --bucket testbucket
StorageGRID Webscale
での
S3 REST API
の実装
クライアント アプリケーションは、ストレージ ノードやAPIゲートウェイ ノードへの接続、 バケットの作成、オブジェクトの格納と読み出しにS3 REST API呼び出しを使用できます。
StorageGRID Webscaleシステムでは、オブジェクトの管理にInformation Lifecycle Management
（ILM;情報ライフサイクル管理）ルールを使用しています。 ILMルールについては、『管理者ガイド』を参照してください。 整合性の保証と制御 StorageGRID Webscaleは、新しく作成されたオブジェクトのリードアフターライト整合性を 保証します。正常に完了したPUTに続くGETでは、新しく書き込まれたデータを読み取るこ とができます。既存のオブジェクトの上書き、メタデータの更新、および削除の整合性レベ ルは、結果整合性です。上書きは通常であれば数秒から数分で反映されますが、最大で15日 かかることもあります。
StorageGRID Webscaleでは、ユーザがバケットやAPI要求の単位で整合性を制御することも可
能になりました。これにより、アプリケーションの要件に応じて整合性と可用性のバランス を調整できます。デフォルトでは、新規のオブジェクトの読み取り時は特定のストレージ ノードを使用できることが必要となります。使用できないストレージ ノードがあると、一 部の新規オブジェクトの読み取りがHTTP 500エラーで失敗することがあります。整合性を 「weak」にして読み取りを行うと、以前の動作に戻り、リードアフターライト整合性よりも 可用性が優先されます。
バケットの整合性制御の設定については、GET Bucket consistency要求（32ページ）および PUT Bucket consistency要求（33ページ）を参照してください。
個々のAPI処理に対して整合性制御を設定するには、その処理でサポートされている整合性 制御を要求ヘッダーで指定する必要があります。次の例では、GET Object処理に対して、整 合性制御を「strong-site」に設定しています。
GET /bucket/object HTTP/1.1
Date: Sat, 29 Nov 2015 01:02:17 GMT
Authorization: AWS 9MOYPG9ACWPAJA1S72R5:jUGbYkLdBApjCWBgK4TxvOjfock= Host: test.com Consistency-Control: strong-site Consistency-Controlヘッダーは、次のいずれかの値に設定する必要があります。 • all：最高レベルの整合性が保証されます。すべてのノードが即座にデータを受け取り、 できない場合は要求が失敗として処理されます。 • strong-global：すべてのサイトにおけるすべての処理について、リードアフターライト整 合性が保証されます。 • strong-site：単一のサイトにおけるすべての処理について、リードアフターライト整合性 が保証されます。 • default：結果整合性と高可用性が確保され、データ保護が保証されます。 • weak：可用性は最も高くなりますが、整合性は保証されず、データ保護の保証レベルが 低下します。 バケットの処理の動作は次のようになります。 • 整合性制御は、バケット内のオブジェクトにのみ適用されます。バケットごとに設定し た整合性制御は、バケット自体ではなく、バケット内のすべてのオブジェクトで実行さ
れるそれぞれのS3処理に適用されます。デフォルト値を変更することは推奨されませ ん。クライアント アプリケーションの動作を修正して問題を解決してください。アプリ ケーションの動作を変更できない場合は、API要求のインスタンスごとに必要な整合性制 御を指定することを推奨します。 • S3 HEAD処理のデフォルトの動作では、低い整合性から処理が試行されます。HEADの 最初の試行で「Not Found」が返されると、整合性を上げながら処理が繰り返し再試行さ れ、それでも見つからない場合は整合性制御「ALL」が使用されます。新規のオブジェ クトに対するS3 HEADでは、再試行の結果、常に最高レベルの整合性制御（すべてのノー ドがオンラインである必要があります）まで「バブルアップ」します。この「バブルアッ プ」の動作は、S3 GET呼び出しにも適用されます。S3のPUT呼び出しとDELETE呼び出 しは、このパターンには従わず、指定された整合性制御で成功か失敗かが判定されます。 • デフォルトの整合性制御を変更した場合、S3のGET呼び出しとHEAD呼び出しに対する 「バブルアップ」の動作は適用されなくなります。つまり、新たに作成したオブジェクト に対してリードアフターライト整合性が保証されなくなります。 注：整合性制御のデフォルト値を変更することは推奨されません。バケット レベルの整合 性制御は最後の手段と考えてください。デフォルトの整合性制御を変更した場合、S3の GET呼び出しとHEAD呼び出しに対する「バブルアップ」の動作は適用されなくなりま す。つまり、新たに作成したオブジェクトに対してリードアフターライト整合性が保証さ れなくなります。
注：StorageGRID WebscaleのConsistency-Controlヘッダーは、書き込み処理と読み取り 処理の両方で一致している必要があります。たとえば、「weak」を使用して書き込んだオ ブジェクトを「strong-global」を使用して再度読み取った場合、すべてのサイトにおける 整合性は保証されません。
関連情報
StorageGRID Webscale 10.4管理者ガイド
StorageGRID Webscale
の
ILM
ルールによるオブジェクトの管
理
Information Lifecycle Management（ILM;情報ライフサイクル管理）ルールを作成して、S3 REST APIクライアント アプリケーションからStorageGRID Webscaleシステムに取り込まれ
たオブジェクトを管理できます。これらのILMルールで、オブジェクト データの格納方法、 格納場所、保管期間を定義します。 ILMの設定により、オブジェクトの次の内容が決まります。 格納場所 StorageGRID Webscaleシステム内のオブジェクトのデータの場所 ストレージの種類 オブジェクト データの格納に使用されるストレージの種類（ディスクまたはアー カイブ メディア） 損失に対する保護 コピーの作成方法（レプリケーション、イレイジャー コーディング、またはその 両方） 保持 オブジェクトのデータの管理方法、格納場所、損失からの保護方法の経過時間に 基づく変更方法
ILMルールでは、オブジェクトの取り込みに使用したインターフェイスに基づいてオブジェ クトをフィルタして選択できます。S3を使用して取り込んだオブジェクトについては、次の メタデータをフィルタ条件として選択できます。 • アカウントID • バケット名 • キー
• 最終アクセス時間。GET Object処理とHEAD Object処理の実行時に更新されます。最終
アクセス時間は、バージョン10.3.0以降で作成されたバケットに対しては、いずれもデ フォルトで無効になります。
注：バケットの最終アクセス時間の設定は、特定のS3 API処理でのみ変更できます。手 順については、「GET Bucket last access time要求」の項を参照してください。
• オブジェクトのサイズ • ユーザのメタデータ ILMルールの詳細については、『管理者ガイド』を参照してください。 関連情報 StorageGRID Webscale 10.4管理者ガイド
オブジェクトのバージョン管理
バージョン管理の機能を使用してオブジェクトの複数のバージョンを保持することで、オブ ジェクトが偶発的に削除される事態に対応したり、以前のバージョンのオブジェクトを読み 出してリストアしたりできます。 StorageGRID Webscaleシステムでは、バージョン管理のほとんどの機能をサポートしていま すが、いくつかの制限事項があります。StorageGRID Webscaleのオブジェクトのバージョン管理は、Information Lifecycle Management
（ILM;情報ライフサイクル管理）と連携できます。AmazonのObject Lifecycle Managementはサ ポートされていません。バケットでバージョン管理機能を使用するには、それぞれのバケッ トに対して明示的に有効にする必要があります。バケット内の各オブジェクトには、
StorageGRID Webscaleシステムによって生成されるバージョンIDが割り当てられます。 Multi-Factor Authentication（MFA;多要素認証）はサポートされていません。
注：バージョン管理は、リリース10.3以降で作成されたバケットでのみ有効にすることが できます。 ILMとバージョン管理 ILMポリシーはオブジェクトのバージョン レベルで適用されます。ILMのスキャン処理で は、すべてのオブジェクトが継続的にスキャンされ、現在のILMポリシーに照らして再評価 されます。ILMポリシーに対する変更は、それまでに取り込まれたすべてのオブジェクトに 適用されます。バージョン管理が有効になっている場合は、それまでに取り込まれたバー ジョンも対象になります。ILMのスキャン処理により、過去に取り込まれたオブジェクトに 変更後の新しいILMの内容が適用されます。さらに、StorageGRID Webscale 10.4にアップグ レードした場合は、以前のバージョンでILMポリシーに対して行った変更が過去に取り込ま れたオブジェクトに遡って適用されます。 バージョン管理が有効なバケット内のS3オブジェクトに対しては、参照時間をnoncurrentに 指定したILMルールを作成できます。それらのオブジェクトの既存バージョンは、そのオブ
ジェクトが更新された時点でnoncurrentになります。noncurrentの時間フィルタを使用するこ とで、旧バージョンのオブジェクトによるストレージへの影響を軽減するポリシーを作成で きます。
S3 REST API
のサポートされる処理と制限事項
StorageGRID Webscaleシステムでは、『Simple Storage Service API Reference』（API Version
2006-03-01）のほとんどの処理をサポートしていますが、いくつかの制限事項があります。 S3 REST APIクライアント アプリケーションを統合するときは、実装の詳細を理解しておく 必要があります。 StorageGRID Webscaleシステムでは、仮想ホスト形式の要求とパス形式の要求の両方をサ ポートしています。 関連情報
Amazon Web Services（AWS）ドキュメント：「Amazon Simple Storage Service API Reference」
エラー応答
StorageGRID Webscaleシステムでは、該当するS3 REST APIの標準のエラー応答をすべてサ
ポートしています。さらに、StorageGRID Webscaleでは、カスタムのXNotImplemented応答 も実装されています。
サポートされているS3 APIのエラーコード
名前 HTTPステータス
AccessDenied 403 Forbidden
BadDigest 400 Bad Request
BucketAlreadyExists 409 Conflict
BucketNotEmpty 409 Conflict
IncompleteBody 400 Bad Request
InternalError 500 Internal Server Error
InvalidAccessKeyId 403 Forbidden
InvalidBucketName 400 Bad Request
InvalidDigest 400 Bad Request
InvalidEncryptionAlgorithmError 400 Bad Request
InvalidPart 400 Bad Request
InvalidPartOrder 400 Bad Request
InvalidRange 416 Requested Range Not Satisfiable
InvalidRequest 400 Bad Request
InvalidStorageClass 400 Bad Request
InvalidURI 400 Bad Request
KeyTooLong 400 Bad Request
MalformedXML 400 Bad Request
名前 HTTPステータス
MethodNotAllowed 405 Method Not Allowed
MissingContentLength 411 Length Required MissingRequestBodyError 400 Bad Request MissingSecurityHeader 400 Bad Request
NoSuchBucket 404 Not Found
NoSuchKey 404 Not Found
NoSuchUpload 404 Not Found
NotImplemented 501 Not Implemented
NoSuchBucketPolicy 404 Not Found
PreconditionFailed 412 Precondition Failed
RequestTimeTooSkewed 403 Forbidden
SignatureDoesNotMatch 403 Forbidden
TooManyBuckets 400 Bad Request
UserKeyMustBeSpecified 400 Bad Request
StorageGRID Webscaleの固有のエラーコード エラー コード 説明 HTTPステータス コード XNotImplemented 指定された要求の処理に必要な機能が実装 されていません。 501 Not Implemented
日付の処理
StorageGRID WebscaleのS3 REST APIの実装では、有効なHTTPの日付形式のみをサポートし
ています。
StorageGRID Webscaleシステムでは、日付の値を設定できるすべてのヘッダーで、有効な
HTTPの日付形式のみがサポートされます。日付の時刻の部分は、Greenwich Mean Time
（GMT;グリニッジ標準時）の形式で指定するか、タイム ゾーンのオフセットなし（+0000を 指定）のUniversal Coordinated Time（UTC;協定世界時）の形式で指定できます。要求に
x-amz-dateヘッダーを含めた場合、Date要求ヘッダーで指定された値よりも優先されます。
AWS署名バージョン4を使用する場合は、dateヘッダーはサポートされないため、署名済み
要求にx-amz-dateヘッダーを含める必要があります。
共通の要求ヘッダー
StorageGRID Webscaleシステムでは、いくつかの例外を除き、Simple Storage Service API
Referenceで定義されている共通の要求ヘッダーがサポートされます。
要求ヘッダー 実装 Authorization AWS署名バージョン2が完全にサポートされます。 AWS署名バージョン4が次の例外を除いてサポートされ ます。 • 要求の本文のSHA256の値は計算されません。ユーザ が送信した値が検証なしで受け入れられます。 • チャンク アップロード オプションをgzipデータ圧縮 と組み合わせて使用する場合は、チャンク オプション を先に指定する必要があります。Content-Encoding パラメータを次のように指定する必要があります。 Content-Encoding: aws-chunked, gzip
x-amz-copy-source-server-side-encryption-customer-key 実装されていません。 x-amz-copy-source-server-side-encryption-customer-key-MD5 実装されていません。 x-amz-security-token 実装されていません。XNotImplementedが返されます。 x-amz-server-side-encryption-customer-algorithm 実装されていません。
共通の応答ヘッダー
StorageGRID Webscaleシステムでは共通の応答ヘッダーがサポートされますが、いくつか例 外があります。StorageGRID Webscaleシステムでは、次の例外を除き、『Simple Storage Service API Reference』
で定義されている共通の応答ヘッダーがすべてサポートされます。
応答ヘッダー 実装
x-amz-id-2 使用されません。
x-amz-expiration 使用されません。
要求の認証
StorageGRID Webscaleシステムでは、S3 APIを使用したオブジェクトへのアクセスについて、
認証アクセスと匿名アクセスの両方をサポートしています。
S3 APIでは、S3 API要求の認証で署名バージョン2と署名バージョン4がサポートされます。
認証された要求は、アクセス キーIDとシークレット アクセス キーで署名する必要がありま す。
StorageGRID Webscaleシステムでは、HTTP Authorizationヘッダーとクエリ パラメータの
2種類の認証方式がサポートされます。
HTTP Authorizationヘッダーの使用
S3 APIでは、バケット ポリシーで許可された匿名の要求を除き、すべての処理で
HTTPAuthorizationヘッダーを使用します。要求の認証に必要なすべての署名情報が Authorizationヘッダーに格納されます。
クエリパラメータの使用 クエリ パラメータを使用すると、URLに認証情報を含めることができます。これは署名付 きURLと呼ばれ、特定のリソースへの一時的なアクセスを許可する場合に使用できます。署 名付きURLを使用すると、シークレット アクセス キーを知らないユーザでもリソースにア クセスできるため、他のユーザに制限付きアクセスを提供することができます。
サービスの処理
StorageGRID Webscaleシステムでサポートされるサービスの処理を次に示します。 処理 実装GET Service Amazon S3 REST APIのすべての動作が実装されていま
す。
GET Storage Usage GET Storage Usage要求を使用すると、アカウントで使用し
ているストレージの総容量とアカウントに関連付けられ ているバケットごとの使用容量を確認できます。この処 理では、パス/とカスタム クエリ パラメータ（?x-ntap-sg-usage）を追加してサービスを操作します。 OPTIONS / クライアント アプリケーションからストレージ ノードの S3ポートに要求を発行（S3認証クレデンシャルは不要） して、LDRサービスが使用可能かどうかを確認できます。
バケットの処理
StorageGRID Webscaleシステムでは、S3テナント アカウントあたり最大100個のバケットが サポートされます。 バケット名については、AWS US Standardリージョンの制限が適用されますが、S3仮想ホス ト形式の要求をサポートするためにDNSの命名規則にも従うことを推奨します。GET Bucket (List Objects)処理とGET Bucket versions処理では、StorageGRID Webscaleの整合性
制御がサポートされます。Consistency-Controlヘッダーの使用については、StorageGRID WebscaleでのS3 REST APIの実装（11ページ）を参照してください。
最終アクセス時間の更新が個々のバケットで有効になっているか無効になっているかを確 認することができます。詳細については、GET Bucket last access time要求（35ページ）を 参照してください。
他のバケットの処理については、「バケットのカスタム処理」を参照してください。 次の表に、StorageGRID Webscaleシステムで実装されているバケットの処理とその実装方法 を示します。
処理 実装
DELETE Bucket Amazon S3 REST APIのすべての動作が実装されていま
す。
DELETE Bucket policy アカウントに必要なアクセス クレデンシャルがある場
合、バケットに関連付けられているポリシーを削除できま す。StorageGRID Webscaleシステムでサポートされてい るポリシー言語については、バケットとグループのアクセ ス ポリシー（39ページ）を参照してください。
処理 実装
GET Bucket (List Objects) アカウントに必要なアクセス クレデンシャルがある場
合、バケット内の一部またはすべて（最大1,000）のオブ ジェクトが返されます。 オブジェクトのストレージ クラスは、 REDUCED_REDUNDANCYストレージ クラスを指定して オブジェクトを取り込んだ場合でも、常にSTANDARDと 表示されます。オブジェクトをStorageGRID Webscaleシ ステムに取り込む際にREDUCED_REDUNDANCYスト レージ クラスを指定した場合、シングルコミットの取り 込み処理が使用されます。これによってStorageGRID Webscaleシステムに格納されるオブジェクトの冗長性が 低下するわけではありません。 注意：REDUCED_REDUNDANCYを使用してオブジェク トを取り込むときは、オブジェクト データのコピーが 最初に1つしか作成されないことに注意してください。 単一のコピーが作成されたストレージ ノードで障害が 発生した場合、ILMをまだ満たしていないと、データが 失われて回復できなくなります。 多数のキーをトラバースする要求では、特別な処理が必要 になります。そのような要求からは、タイムアウトを回避 するために、切り捨てられた応答や空の応答が返されるこ とがあります。 完全な結果を取得するには、結果が切り捨てられたときの 通常の方法と同様に、markerパラメータを更新しながら 繰り返し要求を行う必要があります。NextMarkerが返さ れる場合は常にそのマーカーを使用します。StorageGRID
WebscaleのS3 REST APIの実装では、最後に返されたキー
よりも良い場合、Amazon S3 REST APIでは返されない状 況でNextMarkerが返されることがあります。
GET Bucket acl アカウントに必要なアクセス クレデンシャルがある場
合、バケットの所有者にバケットに対するフル アクセス があることを示す応答が返され、所有者のID、表示名、 および権限が表示されます。
GET Bucket location アカウントに必要なアクセス クレデンシャルがある場
合、バケットのリージョンとして空の文字列が返されま す。StorageGRID Webscaleでは、バケットの場所の制約は ありません。
GET Bucket Object versions バケットに対するREADアクセスがある場合、versions サブリソースを使用して、バケット内のオブジェクトのす べてのバージョンのメタデータのリストが表示されます。
GET Bucket policy アカウントに必要なアクセス クレデンシャルがある場
合、バケットに関連付けられているポリシーが返されま す。StorageGRID Webscaleシステムでサポートされてい るポリシー言語については、バケットとグループのアクセ ス ポリシー（39ページ）を参照してください。
処理 実装
GET Bucket versioning versioningサブリソースを使用して、バケットのバー ジョン管理の状態を取得できます。バケットのバージョ ン管理の状態を取得するには、バケットの所有者である必 要があります。バケットがバージョン管理に対応してい ない場合は「Unversioned」、バージョン管理が有効になっ ている場合は「Enabled」、バージョン管理が一時停止中の 場合は「Suspended」が返されます。
HEAD Bucket Amazon S3 REST APIのすべての動作が実装されていま
す。
PUT Bucket アカウントに必要なアクセス クレデンシャルがある場
合、新しいバケットを作成できます。バケットを作成する と、そのバケットの所有者になります。場所の制約は無視 されます。
PUT Bucket policy アカウントに必要なアクセス クレデンシャルがある場
合、バケットに関連付けるポリシーを設定できます。
StorageGRID Webscaleシステムでサポートされているポ
リシー言語については、バケットとグループのアクセス ポリシー（39ページ）を参照してください。
PUT Bucket versioning versioningサブリソースを使用して、既存のバケットの バージョン管理の状態を設定できます。バージョン管理 の状態を設定するには、バケットの所有者である必要があ ります。バージョン管理の状態は、次のいずれかの値に設 定できます。 • Enabled：バケット内のオブジェクトに対してバージョ ン管理を有効にします。バケットに追加されるすべて のオブジェクトに、一意のバージョンIDが割り当てら れます。 • Suspended：バケット内のオブジェクトに対してバー ジョン管理を無効にします。バケットに追加されるす べてのオブジェクトに、バージョンID nullが割り当て られます。
バケットのカスタム処理
StorageGRID Webscaleシステムでは、S3 REST APIに追加されたシステム固有のカスタム処理
をサポートしています。
次の表に、StorageGRID Webscaleシステムで実装されているバケットのカスタム処理とその 実装方法を示します。
処理 実装
GET Bucket consistency要求 アカウントに必要なアクセス クレデンシャルがある場
合、特定のバケットに適用されている整合性レベルが返さ れます。
詳細については、GET Bucket consistency要求（32ペー ジ）を参照してください。
処理 実装
PUT Bucket consistency要求 アカウントに必要なアクセス クレデンシャルがある場
合、特定のバケットに適用する整合性レベルを設定できま す。
詳細については、PUT Bucket consistency要求（33ペー ジ）を参照してください。
GET Bucket last access time要
求 アカウントに必要なアクセス クレデンシャルがある場合、最終アクセス時間の更新が個々のバケットで有効に なっているか無効になっているかが返されます。
詳細については、GET Bucket last access time要求（35ペー ジ）を参照してください。
PUT Bucket last access time要
求 アカウントに必要なアクセス クレデンシャルがある場合、最終アクセス時間の更新を個々のバケットで有効また は無効にできます。最終アクセス時間は、バージョン
10.3.0以降で作成されたバケットに対しては、デフォルト
ではいずれも無効になります。
詳細については、PUT Bucket last access time要求（36ペー ジ）を参照してください。
オブジェクトの処理
SwiftまたはCDMIを使用してStorageGRID Webscaleシステムに取り込まれたデータ オブジェ
クトにS3を使用してアクセスすることはできません。
オブジェクトの処理では、GET Object ACLとOPTIONS /を除くすべての処理でStorageGRID
Webscaleの整合性制御がサポートされます。Consistency-Controlヘッダーの使用につい ては、StorageGRID WebscaleでのS3 REST APIの実装（11ページ）を参照してください。
StorageGRID Webscaleシステムでサポートされるオブジェクトの処理を次に示します。
処理 実装
DELETE Object
Multi-Factor Authentication（MFA;多要素認証）と応答ヘッダーx-amz-mfaはサ ポートされていません。 バージョン管理 特定のバージョンを削除するには、バケットの所有者がversionIdサブリ ソースを使用して要求を行う必要があります。このサブリソースを使用する と、バージョンが完全に削除されます。versionIdが削除マーカーに対応し ている場合は、応答ヘッダーx-amz-delete-markerがtrueに設定されて返さ れます。 • バージョン管理が有効になっているバケットでversionIdサブリソース を指定せずにオブジェクトを削除すると、削除マーカーが生成されます。 削除マーカーのversionIdがx-amz-version-id応答ヘッダーを使用して 返され、x-amz-delete-marker応答ヘッダーがtrueに設定されて返され ます。 • バージョン管理が一時停止中のバケットでversionIdサブリソースを指 定せずにオブジェクトを削除すると、既存の「null」バージョンまたは 「null」削除マーカーが完全に削除され、新しい「null」削除マーカーが生 成されます。x-amz-delete-marker応答ヘッダーがtrueに設定されて返 されます。
処理 実装
DELETE Multiple Objects
Multi-Factor Authentication（MFA;多要素認証）と応答ヘッダーx-amz-mfaはサ ポートされていません。
1つの要求メッセージで複数のオブジェクトを削除できます。
注：DELETE Multiple Objects要求は、バージョン管理が有効になっているバ
ケットではサポートされません。
PUT Object処理とは異なり、DELETE Multiple Objects処理では、Transfer-Encoding:chunked属性とContent-Encoding:gzip属性はサポートされません。 GET Object 次の要求ヘッダーはサポートされていません。指定した場合は XNotImplementedが返されます。 • x-amz-restore • x-amz-website-redirect-location バージョン管理 versionIdサブリソースが指定されていない場合、バージョン管理が有効に なっているバケットでは、オブジェクトの最新バージョンが取得されます。 オブジェクトの最新バージョンが削除マーカーの場合は、「Not Found」ステー タスが返され、x-amz-delete-marker応答ヘッダーがtrueに設定されます。 GET Object ACL アカウントに必要なアクセス クレデンシャルがある場合、オブジェクトの所 有者にオブジェクトに対するフル アクセスがあることを示す応答が返され、 所有者のID、表示名、および権限が表示されます。 HEAD Object 次の要求ヘッダーはサポートされていません。指定した場合は XNotImplementedが返されます。 • x-amz-restore • x-amz-website-redirect-location バージョン管理 versionIdサブリソースが指定されていない場合、バージョン管理が有効に なっているバケットでは、オブジェクトの最新バージョンが取得されます。 オブジェクトの最新バージョンが削除マーカーの場合は、「Not Found」ステー タスが返され、x-amz-delete-marker応答ヘッダーがtrueに設定されます。
処理 実装 PUT Object ストレージ クラスのオプション x-amz-storage-class要求ヘッダーがサポートされています。指定できる 値は次のとおりです。 • STANDARD：（デフォルト）デュアルコミットの取り込み処理を指定しま す。 • REDUCED_REDUNDANCY：シングルコミットの取り込み処理を指定します。 注：REDUCED_REDUNDANCYストレージ クラスは、ILMポリシーなどの他の効 率的な方法でデータがレプリケートされている場合に冗長なストレージを 制限するためのオプションです。REDUCED_REDUNDANCY値を指定しても、 指定されているILMポリシーに影響はなく、StorageGRID Webscaleシステム に格納されるデータの冗長性が低下するわけではありません。 注意：REDUCED_REDUNDANCYを使用してオブジェクトを取り込むとき は、オブジェクト データのコピーが最初に1つしか作成されないことに注 意してください。単一のコピーが作成されたストレージ ノードで障害が 発生した場合、ILMをまだ満たしていないと、データが失われて回復でき なくなります。
PUT Object処理では、Transfer-Encoding:chunked属性と Content-Encoding:gzip属性がサポートされます。 要求ヘッダー 次の要求ヘッダーがサポートされています。 • x-amz-server-side-encryption • x-amz-meta-ユーザ定義のメタデータの名前と値のペア オブジェクトの作成時間を記録するには、ILMルールの参照時間で[User
Defined Creation Time]オプションを使用できるように、 x-amz-meta-creation-timeという名前のユーザ定義のヘッダーに値を格納する必要 があります。たとえば、「x-amz-meta-creation-time=1443399726」など です。このフィールドの値は、1970年1月1日からの秒数となります。詳細 については、『管理者ガイド』の「参照時間」を参照してください。 次の要求ヘッダーはサポートされていません。 • Expires • x-amz-acl 次の要求ヘッダーはサポートされていません。指定した場合は XNotImplementedが返されます。 • x-amz-server-side-encryption-customer-algorithm • x-amz-server-side-encryption-customer-key • x-amz-server-side-encryption-customer-key-MD5 • x-amz-website-redirect-location
処理 実装 PUT Object (continued) バージョン管理 バケットでバージョン管理が有効になっている場合、格納されるオブジェク トのバージョンごとに一意のversionIdが自動的に生成されます。この versionIdは、x-amz-version-id応答ヘッダーを使用した応答でも返されま す。 バージョン管理が一時停止中の場合は、versionIdがnullの状態でオブジェク トのバージョンが格納され、nullのバージョンがすでに存在する場合は上書き されます。 バージョン管理の詳細については、バケットの処理（18ページ）の「PUT
処理 実装 PUT Object -Copy 次の要求ヘッダーがサポートされています。 • x-amz-meta-ユーザ定義のメタデータの名前と値のペア オブジェクトの作成時間を記録するには、ILMルールの参照時間で[User
Defined Creation Time]オプションを使用できるように、 x-amz-meta-creation-timeという名前のユーザ定義のヘッダーに値を格納する必要 があります。たとえば、「x-amz-meta-creation-time=1443399726」など です。このフィールドの値は、1970年1月1日からの秒数となります。詳細 については、『管理者ガイド』の「参照時間」を参照してください。 • x-amz-metadata-directive：デフォルト値はCOPYで、オブジェクトおよ び関連するメタデータをコピーできます。 REPLACEを指定すると、オブジェクトのコピー時に既存のメタデータを上 書きしたり、オブジェクトのメタデータを更新したりできます。 • x-amz-copy-source • x-amz-copy-source-if-match • x-amz-copy-source-if-none-match • x-amz-copy-source-if-unmodified-since • x-amz-copy-source-if-modified-since • x-amz-server-side-encryption • x-amz-storage-class 次の要求ヘッダーはサポートされていません。指定した場合は XNotImplementedが返されます。 • x-amz-server-side-encryption-customer-algorithm • x-amz-server-side-encryption-customer-key • x-amz-server-side-encryption-customer-key-MD5 • x-amz-website-redirect-location x-amz-copy-sourceヘッダーで指定されたソースのバケットおよびキーが デスティネーションのバケットおよびキーと異なる場合、ソースのオブジェ クト データのコピーがデスティネーションに書き込まれます。ソースとデ スティネーションが同じ場合は、x-amz-metadata-directiveヘッダーで REPLACEが指定されていれば、オブジェクトのメタデータが要求で指定され たメタデータの値に更新されます。 注：オブジェクトのserver-side-encryptionの値は更新できません。代 わりに、コピーを作成し、x-amz-metadata-directive: REPLACEを使用し てserver-side-encryptionの新しい値を設定してください。 バージョン管理 ソースのバケットでバージョン管理が有効になっている場合、 x-amz-copy-sourceヘッダーを使用してオブジェクトの最新バージョンをコピーできま す。オブジェクトの特定のバージョンをコピーするには、コピーするバー ジョンをversionIdサブリソースを使用して明示的に指定する必要がありま す。デスティネーションのバケットでバージョン管理が有効になっている場 合は、生成されたバージョンがx-amz-version-id応答ヘッダーで返されま す。ターゲットのバケットでバージョン管理が一時停止中の場合は、 x-amz-version-idの値として「null」が返されます。
マルチパート
アップロードの処理
注：1つのバケットに対して同時に実行するマルチパート アップロードが1,000件を超えな
いようにしてください。1,000件を超えると、そのバケットに対するList Multipart Uploads のクエリで完全な結果が返されないことがあります。
注：マルチパートの最後のパート以外の各パートのサイズは5MB～5GBでなければなりま せん。最後のパートは5MB未満でもかまいません。これはクライアント側の制限であり、
StorageGRID Webscaleでは強制されません。
マルチパート アップロードでは、すべての処理でStorageGRID Webscaleの整合性制御がサ ポートされます。Consistency-Controlヘッダーの使用については、StorageGRID Webscale
でのS3 REST APIの実装（11ページ）を参照してください。
処理 実装
List Multipart Uploads 次の要求ヘッダーがサポートされています。
• encoding-type • max-uploads • key-marker • prefix • upload-id-marker delimiter要求パラメータはサポートされていません。 バージョン管理 マルチパート アップロードは、アップロードの開始、アッ プロードのリストの表示、パートのアップロード、アップ ロードしたパートの整理、およびアップロードの完了の個 別の処理に分けられます。オブジェクトの作成とバー ジョンの管理（該当する場合）は、Complete Multipart Upload処理が実行された時点で行われます。
処理 実装
Initiate Multipart Upload x-amz-storage-class要求ヘッダーがサポートされてい ます。指定できる値は次のとおりです。 • STANDARD デフォルト。デュアルコミットの取り込み処理を指定 します。 • REDUCED_REDUNDANCY シングルコミットの取り込み処理を指定します。 注：REDUCED_REDUNDANCYストレージ クラスは、ILMポ リシーなどの他の効率的な方法でデータがレプリケー トされている場合に冗長なストレージを制限するため のオプションです。REDUCED_REDUNDANCY値を指定し ても、指定されているILMポリシーに影響はなく、 StorageGRID Webscaleシステムに格納されるデータの 冗長性が低下するわけではありません。 注意：REDUCED_REDUNDANCYを使用してオブジェク トを取り込むときは、オブジェクト データのコピーが 最初に1つしか作成されないことに注意してください。 単一のコピーが作成されたストレージ ノードで障害が 発生した場合、ILMをまだ満たしていないと、データが 失われて回復できなくなります。 次の要求ヘッダーがサポートされています。 • Content-Type • x-amz-meta-ユーザ定義のメタデータの名前と値のペ ア オブジェクトの作成時間を記録するには、ILMルールの参 照時間で[User Defined Creation Time]オプションを使用で きるように、x-amz-meta-creation-timeという名前の ユーザ定義のヘッダーに値を格納する必要があります。 たとえば、「x-amz-meta-creation-time=1443399726」 などです。このフィールドの値は、1970年1月1日からの秒 数となります。詳細については、『管理者ガイド』の「参 照時間」を参照してください。 x-amz-server-side-encryptionヘッダーは、Initiate Multipart Upload要求では直接はサポートされません。マ ルチパート アップロードでサーバ側の暗号化が必要な場 合は、それぞれのUpload Partで x-amz-server-side-encryptionヘッダーを指定する必要があります。この ヘッダーをInitiate Multipart Uploadで指定した場合、要求 は失敗します。
処理 実装
Initiate Multipart Upload (continued) 次の要求ヘッダーはサポートされていません。指定した 場合はXNotImplementedが返されます。 • x-amz-website-redirect-location • x-amz-server-side-encryption-customer-key バージョン管理 マルチパート アップロードは、アップロードの開始、アッ プロードのリストの表示、パートのアップロード、アップ ロードしたパートの整理、およびアップロードの完了の個 別の処理に分けられます。オブジェクトの作成とバー ジョンの管理（該当する場合）は、Complete Multipart Upload処理が実行された時点で行われます。 Upload Part 次の要求ヘッダーがサポートされています。 • Content-Length • x-amz-server-side-encryption マルチパート アップロードでサーバ側の暗号化を指 定する必要がある場合は、それぞれのUpload Partで x-amz-server-side-encryptionを個別に指定する必要 があります。 次の要求ヘッダーはサポートされていません。指定した 場合はXNotImplementedが返されます。 • x-amz-server-side-encryption-customer-algorithm • x-amz-server-side-encryption-customer-key • x-amz-server-side-encryption-customer-key-MD5 バージョン管理 マルチパート アップロードは、アップロードの開始、アッ プロードのリストの表示、パートのアップロード、アップ ロードしたパートの整理、およびアップロードの完了の個 別の処理に分けられます。オブジェクトの作成とバー ジョンの管理（該当する場合）は、Complete Multipart Upload処理が実行された時点で行われます。
処理 実装
Upload Part - Copy Amazon S3 REST APIのすべての動作が実装されていま
す。
StorageGRID Webscaleシステム内で
x-amz-copy-source-rangeで指定されたデータの読み取りと書き込みを行い ます。 次の要求ヘッダーがサポートされています。 • x-amz-copy-source-if-match • x-amz-copy-source-if-none-match • x-amz-copy-source-if-unmodified-since • x-amz-copy-source-if-modified-since バージョン管理 マルチパート アップロードは、アップロードの開始、アッ プロードのリストの表示、パートのアップロード、アップ ロードしたパートの整理、およびアップロードの完了の個 別の処理に分けられます。オブジェクトの作成とバー ジョンの管理（該当する場合）は、Complete Multipart Upload処理が実行された時点で行われます。
Complete Multipart Upload x-amz-storage-class要求ヘッダーがサポートされてい ます。指定できる値は次のとおりです。 • STANDARD デフォルト。デュアルコミットの取り込み処理を指定 します。 • REDUCED_REDUNDANCY シングルコミットの取り込み処理を指定します。 注：REDUCED_REDUNDANCYストレージ クラスは、ILMポ リシーなどの他の効率的な方法でデータがレプリケー トされている場合に冗長なストレージを制限するため のオプションです。REDUCED_REDUNDANCY値を指定し ても、指定されているILMポリシーに影響はなく、 StorageGRID Webscaleシステムに格納されるデータの 冗長性が低下するわけではありません。 注意：ILMポリシーを設定する際、REDUCED_REDUNDANCY が設定されたデータについては、ILMポリシーを満たす まではオブジェクト データのコピーが1つしかレプリ ケートされないことに十分に注意してください。ILM ポリシーを満たす前に、単一のコピーが作成されたスト レージ ノードで障害が発生すると、データが失われて 回復できなくなります。 注意：マルチパート アップロードが15日以内に完了しな いと、非アクティブな処理としてマークされ、関連する すべてのデータがシステムから削除されます。 注：返されるETagの値は、データのMD5サムではなく、
Amazon S3 APIのマルチパート オブジェクト用のETag 値の実装に従います。
処理 実装
Complete Multipart Upload (continued) バージョン管理 マルチパート アップロードは、この処理で完了します。 バケットでバージョン管理が有効になっている場合は、マ ルチパート アップロードの完了時にオブジェクトのバー ジョンが作成されます。 バケットでバージョン管理が有効になっている場合、格納 されるオブジェクトのバージョンごとに一意の versionIdが自動的に生成されます。このversionIdは、 x-amz-version-id応答ヘッダーを使用した応答でも返 されます。 バージョン管理が一時停止中の場合は、versionIdがnull の状態でオブジェクトのバージョンが格納され、nullの バージョンがすでに存在する場合は上書きされます。 注：バケットでバージョン管理が有効になっているとき は、同じオブジェクト キーで同時に複数のマルチパー ト アップロードが実行されている場合でも、マルチ パート アップロードが完了するたびに常に新しいバー ジョンが作成されます。バケットでバージョン管理が 有効になっていないときは、マルチパート アップロー ドの開始後に、同じオブジェクト キーで別のマルチ パート アップロードが開始されて先に完了することが あります。バージョン管理が有効になっていないバ ケットでは、最後に完了したマルチパート アップロー ドが優先されます。
Abort Multipart Upload Amazon S3 REST APIのすべての動作が実装されていま
す。
List Parts Amazon S3 REST APIのすべての動作が実装されていま
す。 関連情報 StorageGRID Webscale 10.4管理者ガイド
監査ログで追跡される処理
バケットおよびオブジェクトのいくつかの処理は、StorageGRID Webscaleの監査ログで追跡 されます。 監査ログで追跡されるバケットの処理 DELETE BucketDELETE Multiple Objects GET Bucket (List Objects) GET Bucket Object versions HEAD Bucket
PUT Bucket
監査ログで追跡されるオブジェクトの処理
Complete Multipart Upload DELETE Object
GET Object HEAD Object PUT Object PUT Object - Copy
StorageGRID Webscale
の
S3 REST API
の処理
StorageGRID Webscaleシステムに固有の処理がS3 REST APIに追加されています。
GET Bucket consistency
要求
GET Bucket consistency要求を使用すると、特定のバケットに適用されている整合性レベルを
確認できます。
新たに作成したオブジェクトに対しては、リードアフターライト整合性を保証するようにデ フォルトの整合性制御が設定されます。Consistency-Controlヘッダーの詳細について は、StorageGRID WebscaleでのS3 REST APIの実装（11ページ）を参照してください。 この処理を完了するには、s3::GetBucketConsistency権限が必要です。
要求
要求のHTTPヘッダー 説明
Authorization 要求に使用するAWS署名とアカウントのアクセス キーID
を示します。
Date 要求の日付と時刻です。
Host 要求の転送先のホスト名です。
要求の例
GET /bucket?x-ntap-sg-consistency HTTP/1.1 Date: Sat, 29 Nov 2015 01:02:17 GMT
Authorization: AWS 9MOYPG9ACWPAJA1S72R5:jUGbYkLdBApjCWBgK4TxvOjfock= Host: test.com
応答
応答のHTTPヘッダー 説明
Connection サーバへの接続が開いているかどうかを示します。
Content-Length 応答の本文の長さです。
Content-Type 応答の本文のMultipurpose Internet Mail Extensions（MIME）
タイプです。 Date 応答の日付と時刻です。 Server 応答を作成したサーバです。 x-amz-request-id 要求を一意に識別する識別子です。S3 APIで作成されま す。 <Consistency>で返される値は、次のいずれかになります。 • all：最高レベルの整合性が保証されます。すべてのノードが即座にデータを受け取り、 できない場合は要求が失敗として処理されます。 • strong-global：すべてのサイトにおけるすべての処理について、リードアフターライト整 合性が保証されます。
• strong-site：単一のサイトにおけるすべての処理について、リードアフターライト整合性 が保証されます。 • default：結果整合性と高可用性が確保され、データ保護が保証されます。 • weak：可用性は最も高くなりますが、整合性は保証されず、データ保護の保証レベルが 低下します。 注：整合性制御のデフォルト値を変更することは推奨されません。代わりに、要求が正し く処理されるようにアプリケーション クライアントの動作を変更してください。これが できない場合は、クライアントでAPI要求ごとに整合性制御を指定するように設定します。 バケット レベルの整合性制御は最後の手段と考えてください。 応答の例 HTTP/1.1 200 OK
Date: Sat, 29 Nov 2015 01:02:18 GMT Connection: CLOSE Server: StorageGRID/10.3.0 x-amz-request-id: 12345 Content-Length: 127 Content-Type: application/xml <?xml version="1.0" encoding="UTF-8"?> <Consistency xmlns="http://s3.storagegrid.com/doc/2015-02-01/">default</ Consistency>
PUT Bucket consistency
要求
PUT Bucket consistency要求を使用すると、バケットで実行される処理に適用する整合性レベ
ルを指定できます。
新たに作成したオブジェクトに対しては、リードアフターライト整合性を保証するようにデ フォルトの整合性制御が設定されます。Consistency-Controlヘッダーの詳細について は、StorageGRID WebscaleでのS3 REST APIの実装（11ページ）を参照してください。 この処理を完了するには、s3::PutBucketConsistency権限が必要です。
要求
要求のHTTPヘッダー 説明
Authorization 要求に使用するAWS署名とアカウントのアクセス キーID
を示します。 Date 要求の日付と時刻です。 Host 要求の転送先のホスト名です。 x-ntap-sg-consistencyパラメータには、次のいずれかの値を指定する必要があります。 • all：最高レベルの整合性が保証されます。すべてのノードが即座にデータを受け取り、 できない場合は要求が失敗として処理されます。 • strong-global：すべてのサイトにおけるすべての処理について、リードアフターライト整 合性が保証されます。 • strong-site：単一のサイトにおけるすべての処理について、リードアフターライト整合性 が保証されます。 • default：結果整合性と高可用性が確保され、データ保護が保証されます。
• weak：可用性は最も高くなりますが、整合性は保証されず、データ保護の保証レベルが 低下します。 注：整合性制御のデフォルト値を変更することは推奨されません。代わりに、要求が正し く処理されるようにアプリケーション クライアントの動作を変更してください。これが できない場合は、クライアントでAPI要求ごとに整合性制御を指定するように設定します。 バケット レベルの整合性制御は最後の手段と考えてください。 要求の例 PUT /bucket?x-ntap-sg-consistency=strong-global HTTP/1.1 Date: Sat, 29 Nov 2015 01:02:17 GMT
Authorization: AWS 9MOYPG9ACWPAJA1S72R5:jUGbYkLdBApjCWBgK4TxvOjfock= Host: test.com
GET Storage Usage
要求
GET Storage Usage要求を使用すると、アカウントで使用しているストレージの総容量とアカ
ウントに関連付けられているバケットごとの使用容量を確認できます。 アカウントとそのバケットで使用しているストレージの容量を確認するには、GET Service要 求を変更してx-ntap-sg-usageクエリ パラメータを使用します。バケットによるストレー ジの使用量は、システムで処理されるPUT要求やDELETE要求とは別に追跡されます。その ため、特にシステムの負荷が高いときなどは、使用量の値がそれらの要求の処理に基づく想 定値と同じになるまでに少し時間がかかることがあります。 この処理を完了するには、s3::ListAllMyBuckets権限が必要です。 要求 要求のHTTPヘッダー 説明
Authorization 要求に使用するAWS署名とアカウントのアクセス キーID
を示します。
Date 要求の日付と時刻です。
Host 要求の転送先のホスト名です。
要求の例
GET /?x-ntap-sg-usage HTTP/1.1 Date: Sat, 29 Nov 2015 00:49:04 GMTT
Authorization: AWS 9MOYPG9ACWPAJA1S72R5:jUGbYkLdBApjCWBgK4TxvOjfock= Host: test.com
応答
応答のHTTPヘッダー 説明
Connection サーバへの接続が開いているかどうかを示します。
Content-Length 応答の本文の長さです。
Content-Type 応答の本文のMultipurpose Internet Mail Extensions（MIME）
タイプです。
応答のHTTPヘッダー 説明 Server 応答を作成したサーバです。 x-amz-request-id 要求を一意に識別する識別子です。S3 APIで作成されま す。 応答の例 HTTP/1.1 200 OK
Date: Sat, 29 Nov 2015 00:49:05 GMT Connection: KEEP-ALIVE Server: StorageGRID/10.2.0 x-amz-request-id: 727237123 Content-Length: 427 Content-Type: application/xml <?xml version="1.0" encoding="UTF-8"?> <UsageResult xmlns="http://s3.storagegrid.com/doc/2015-02-01"> <CalculationTime>2014-11-19T05:30:11.000000Z</CalculationTime> <ObjectCount>4</ObjectCount> <DataBytes>12</DataBytes> <Buckets> <Bucket> <Name>bucket1</Name> <ObjectCount>2</ObjectCount> <DataBytes>6</DataBytes> </Bucket> <Bucket> <Name>bucket2</Name> <ObjectCount>2</ObjectCount> <DataBytes>6</DataBytes> </Bucket> </Buckets> </UsageResult> バージョン管理 応答のObjectCountとDataBytesの値は、格納されているすべてのオブジェクトのバージョ ンから計算されます。ObjectCountの合計に削除マーカーは追加されません。
GET Bucket last access time
要求
GET Bucket last access time要求を使用すると、最終アクセス時間の更新が個々のバケットで
有効になっているか無効になっているかを確認できます。
この処理を完了するには、s3::GetBucketLastAccessTime権限が必要です。
要求
要求のHTTPヘッダー 説明
Authorization 要求に使用するAWS署名とアカウントのアクセス キーID
を示します。
Date 要求の日付と時刻です。
