Elastic Cloud Storage (ECS)...Hadoop サービスの開始とECS へのHadoop アクセスの確認.....160 トラブルシューティング 161 概要..... 162 安全なHadoop クラスタを使用した正しい

Elastic Cloud Storage (ECS)バージョン 3.1

データアクセスガイド302-003-865

01

Copyright © 2013-2017 Dell Inc. その関連会社。 All rights reserved. （不許複製・禁無断転載）

2017 年 8 月発行

掲載される情報は、発信現在で正確な情報であり、予告なく変更される場合があります。

本文書に記載される情報は、「現状有姿」の条件で提供されています。本文書に記載される情報に関する、どのような内容についても表明保証条項を設けず、特に、商品性や特定の目的に対する適応性に対する黙示的保証はいたしません。この資料に記載される、いかなる Dell ソフトウェアの使用、複製、頒布も、当該ソフトウェアライセンスが必要です。

Dell、EMC、および Dell または EMC が提供する製品及びサービスにかかる商標は Dell Inc.またはその関連会社の商標又は登録商標です。その他の商標は、各社の商標又は登録商標です。Published in the USA.

EMC ジャパン株式会社〒 151-0053 東京都渋谷区代々木 2-1-1 新宿マインズタワーwww.DellEMC.com/ja-jp/index.htmお問い合わせはwww.DellEMC.com/ja-jp/index.htm

2 Elastic Cloud Storage (ECS) 3.1 データアクセスガイド

7

9

S3 11

S3 13ECS の Amazon S3 API サポート....................................................................14S3 API のサポート対象およびサポート対象外の機能.......................................... 14

バケットがすでに存在する場合の動作...................................................17バケットポリシーのサポート............................................................................... 18

バケットポリシーの作成、割り当て、管理..............................................20バケットポリシーのシナリオ.................................................................. 20サポートされているバケットポリシー操作............................................... 22サポートされているバケットポリシーの条件.............................................23

S3 の拡張機能.............................................................................................24バイト範囲拡張機能........................................................................ 25保存期間........................................................................................29ファイルシステム対応.........................................................................29

メタデータの検索............................................................................................30バケットへのメタデータインデックス値の割り当て...................................... 31暗号化をメタデータ検索と組み合わせて使用：.................................... 33S3 プロトコルによるメタデータのオブジェクトへの割り当て..........................34メタデータ検索クエリーの使用............................................................. 34ECS Java SDK からのメタデータ検索の使用 .......................................39ECS のシステムメタデータとオプション属性............................................40

S3 と Swift の相互運用性............................................................................. 41秘密キーの作成と管理...................................................................................43

オブジェクトユーザーのキーの作成....................................................... 43S3 シークレットキーの作成：セルフサービス.........................................44

S3 サービスでの認証......................................................................................47ECS での s3curl の使用................................................................................ 48SDK を使って S3 サービスにアクセス................................................................. 49

Java Amazon SDK の使用...............................................................49ECS用の Java SDK クライアント........................................................ 51

OpenStack Swift 53

OpenStack Swift 55ECS の OpenStack Swift サポート................................................................ 56サポート対象の OpenStack Swift機能..........................................................56Swift の拡張機能........................................................................................ 58Swiftバイト範囲拡張機能............................................................................ 58

オブジェクト内でのバイト範囲の更新....................................................59

図

表

第 1部

第 1章

第 2部

第 2章

目次

Elastic Cloud Storage (ECS) 3.1 データアクセスガイド 3

オブジェクトの一部を上書き................................................................60オブジェクトにデータを追加.................................................................. 61オブジェクト内での複数のバイト範囲の読み取り.................................... 62

保存期間.....................................................................................................62ファイルシステム対応......................................................................................63S3 と Swift の相互運用性.............................................................................64OpenStack Swift の認証............................................................................. 64

ECS ポータルでの Swift ユーザーの作成............................................. 64OpenStackバージョン 1.0認証 ........................................................65OpenStackバージョン 2.0認証.........................................................67ECS Keystone V3統合を使用した認証............................................ 69

コンテナーに対する認証.................................................................................. 72

EMC Atmos 75

EMC Atmos 77ECS の EMC Atmos API サポート.................................................................. 78サポート対象の EMC Atmos REST API コール.................................................78サポート対象外の EMC Atmos REST API コール.............................................80EMC Atmos REST API コールのサブテナントサポート........................................81API の拡張機能............................................................................................81

オブジェクトにデータを追加.................................................................. 81Atmos オブジェクトの保存と、保存の有効期限に対する ECS のサポート....82

CAS 89

CAS 91ECS の CAS サポートの設定.......................................................................... 92コールドストレージ......................................................................................... 92コンプライアンス..............................................................................................93

プラットフォームの堅牢化とコンプライアンス.............................................93コンプライアンスと保存ポリシー.............................................................94コンプライアンスエージェント................................................................ 95

ECS での CAS の保存.................................................................................. 95CAS アプリケーションの高度な保存：イベントベースの保存、法的証拠保全、最小/最大ガバナー................................................................................................ 97ネームスペースの保存ポリシーの設定.............................................................. 103CAS ユーザーのバケットの作成および設定.......................................................104CAS オブジェクトユーザーの設定................................................................... 105CAS のバケット ACL の設定..........................................................................106CAS ユーザーをサポートする ECS管理 API.................................................... 108CAS（コンテンツアドレスストレージ）SDK API サポート.................................. 109

ECS Management REST API 111

ECS Management REST API 113ECS Management REST API の概要...........................................................114

第 3部

第 3章

第 4部

第 4章

第 5部

第 5章

目次


ECS Management REST API による認証..................................................... 114cookie を使用しない認証 ................................................................ 114ログアウト........................................................................................ 116ECS Management REST API の whoami コマンド.............................116ECS Management REST API のサマリー.......................................... 117

HDFS 121

ECS HDFSの概要 123ECS HDFS の概要......................................................................................124ECS HDFS を使用するための Hadoop の構成 .............................................. 125Hadoop の認証モード.................................................................................. 125

ファイルシステムとしてのバケットへのアクセス.........................................126バケットのカスタムグループ ACL とデフォルトグループ.............................127Hadoop のスーパーユーザーとスーパーグループ.....................................127マルチプロトコル（クロスヘッド）アクセス............................................ 128プロキシユーザー............................................................................. 128同等ユーザー..................................................................................128

シンプルな Hadoop クラスターから Kerberos Hadoop クラスターへの移行............ 129Hadoop Kerberos認証モード......................................................... 129

ファイルシステムとの対話操作........................................................................130サポートされる Hadoop アプリケーション........................................................... 130

ECS HDFS を使用したシンプルな Hadoop クラスタの構成 131シンプルな Hadoop クラスタと ECS HDFS の統合............................................ 132Ambari を使用した Hortonworks HDP のインストール..................................... 132ECS ポータルを使用した HDFSバケットの作成................................................ 134

カスタムグループバケット ACL の設定................................................ 137ユーザーバケット ACL の設定........................................................... 138Hadoop権限と ECSバケット権限の例..............................................139

ECS HDFS と Hadoop の統合の計画............................................................ 141ECS HDFS インストールおよびサポートパッケージの取得................................... 141ECS HDFS クライアントライブラリの導入......................................................... 142ECS クライアントプロパティの構成.................................................................. 143Hive の設定................................................................................................144ECS への Hadoop アクセスの確認................................................................. 145バケットのセキュリティ保護.............................................................................. 146HDFS から ECSバケットへのデフォルトファイルシステムの再配置....................... 147

ECS HDFS を使用した安全な（Kerberos対応）Hadoop クラスタの構成149

安全な Hadoop クラスタと ECS HDFS の統合 ............................................... 150シンプルなクラスターから Kerberos クラスターへの移行のプランニング.................... 150グループ名のマップ......................................................................................... 151ECS サービスプリンシパルを使用した ECS ノードの構成.................................... 151Ambari を使用した Kerberos の有効化.........................................................155メタデータを使用した ECSバケットの保護........................................................156

管理 REST API を使用した ECS へのメタデータ値のロード...................159ECS クライアントプロパティの再構成...............................................................160

第 6部

第 6章

第 7章

第 8章

目次


Hadoop サービスの開始と ECS への Hadoop アクセスの確認............................160

トラブルシューティング 161概要.......................................................................................................... 162安全な Hadoop クラスタを使用した正しい AD/LDAP構成の確認.....................162Pig テストの失敗：Kerberos プリンシパルを取得できない................................. 163AD ユーザーの権限が拒否される....................................................................163権限エラー.................................................................................................. 163リクエストの処理の失敗.................................................................................166Kerberos クライアント側のログおよびデバッグの有効化...................................... 166KDC での Kerberos のデバッグ...................................................................... 167クロックスキューの排除.................................................................................. 167ECS サービスプリンシパルを使用した 1 つ以上の新規 ECS ノードの構成.............167Yarn ディレクトリが存在しないエラーの回避策.................................................. 169

付録：Kerberosの構成について 173Kerberos の構成について............................................................................. 174

Kerberos KDC のセットアップ............................................................ 174Kerberos の AD ユーザー認証の構成................................................175

付録：ECS HDFSの Hadoop core-site.xmlプロパティ 179ECS HDFS の Hadoop core-site.xml プロパティ............................................ 180

単純認証モードの core-site.xml の例...............................................183

付録：安全なバケットメタデータの例 185安全なバケットメタデータ...............................................................................186

第 9章

第 10章

第 11章

第 12章

目次


ECS Portal の新しいネームスペースでコンプライアンスを有効化........................................... 95CASバケットの保存オプション..........................................................................................98EBR のシナリオ............................................................................................................ 100法的証拠保全のシナリオ...............................................................................................102新しい保存ポリシー.......................................................................................................104ネームスペースの保存ポリシー.........................................................................................104オブジェクトユーザーの CAS設定.................................................................................. 105バケット ACL の編集.....................................................................................................106［Bucket ACLs Management］...................................................................................107ECS HDFS の Hadoop クラスタとの統合........................................................................ 124

12345678910

図


図


サポートされている S3 API...............................................................................................14追加機能..................................................................................................................... 16サポートされていない S3 API............................................................................................17オブジェクト操作のための権限..........................................................................................22バケット操作のための権限...............................................................................................22バケットのサブリソース操作のための権限............................................................................23サポートされる汎用 AWS条件キー..................................................................................23オブジェクト操作でサポートされている S3固有の条件キー................................................... 24バケット操作でサポートされている S3固有の条件キー........................................................ 24サポート対象の OpenStack Swift コール.........................................................................57追加機能.....................................................................................................................58サポート対象外の OpenStack Swift コール..................................................................... 58Keystone認証プロバイダーの設定.................................................................................. 72サポート対象の Atmos REST API コール......................................................................... 78サポート対象外の Atmos REST API コール......................................................................80Atmos の保存期間.......................................................................................................83通常のアーカイブとコールドアーカイブの要件の比較............................................................92保存期間のための ECS管理 API リソース........................................................................97イベントベース保存のための CAS API関数..................................................................... 101法的証拠保全のために CAS API関数.......................................................................... 102バケットの ACL.............................................................................................................107バケット ACL グループ................................................................................................... 108ECS Management REST API：メソッドのサマリー........................................................... 117シンプル Hadoop クラスタでのファイルシステムアクセスのバケット権限例.............................. 140Kerberos認証を使用する Hadoop クラスタでのファイルシステムアクセスのバケット権限例.... 140ECS HDFS構成の動作条件........................................................................................ 141ECS HDFS クライアントライブラリ................................................................................... 142ECS アクセスを可能にする Hadoop の構成.....................................................................143Hive templeton構成..................................................................................................144Hive の同時アクセスと ACID トランザクションを有効化する Hadoop の構成......................... 147ECS アクセスを可能にする Hadoop の構成.....................................................................160Hadoop core-site.xml のプロパティ............................................................................... 180

1234567891011121314151617181920212223242526272829303132

表


表


第 1部

S3

第 1章, "S3"

S3 11

S3


第 1章

S3

l ECS の Amazon S3 API サポート........................................................................... 14l S3 API のサポート対象およびサポート対象外の機能..................................................14l バケットポリシーのサポート.......................................................................................18l S3 の拡張機能.................................................................................................... 24l メタデータの検索................................................................................................... 30l S3 と Swift の相互運用性.....................................................................................41l 秘密キーの作成と管理.......................................................................................... 43l S3 サービスでの認証..............................................................................................47l ECS での s3curl の使用........................................................................................48l SDK を使って S3 サービスにアクセス.........................................................................49

S3 13

ECSの Amazon S3 API サポートECS では、Amazon S3（Amazon Simple Storage Service）API（アプリケーションプログラミングインタフェース）のサポートを提供しています。Amazon S3 オブジェクトサービスは、次のポートで使用できます。

プロトコルポート

HTTP 9020

HTTPS 9021

以降のトピックでは、S3 API のサポートについてと、ECS で提供される拡張機能について説明し、サービスでの認証方法と、サービスにアクセスするクライアントの開発に SDK（SoftwareDevelopment Kit）を使用する方法についても説明します。l S3 API のサポート対象およびサポート対象外の機能（14 ページ）l S3 の拡張機能（24 ページ）l メタデータの検索（30 ページ）l 秘密キーの作成と管理（43 ページ）l S3 サービスでの認証（47 ページ）l SDK を使って S3 サービスにアクセス（49 ページ）バケットのアドレス指定や認証には、ECS特有のものがあります。既存のアプリケーションを ECS と通信するよう構成する場合、または S3 API を使う新しいアプリケーションを開発して ECS との通信に使用する場合は、ECS製品ドキュメントページ内の使用可能な「ECS管理ガイド」の「ベースURL」セクションを参照してください。

S3 APIのサポート対象およびサポート対象外の機能ECSは、Amazon S3 REST API のサブセットをサポートしています。

以下のセクションでは、サポートされている API とサポートされていない API について詳しく説明します。l サポートされている S3 API（14 ページ）l サポートされていない S3 API（17 ページ）

サポートされている S3 APIサポートされている S3 API メソッドを次の表に示します。

表 1 サポートされている S3 API

機能注

GET Service ECSはバケットリストのページングを有効化する marker および max-

keysパラメーターをサポートします。

GET /?marker=<bucket>&max-keys=<num>

S3


https://community.emc.com/docs/DOC-56978

表 1 サポートされている S3 API （続き）

機能注

例：

GET /?marker=mybucket&max-keys=40

DELETE Bucket

DELETE Bucket cors

DELETE Bucket lifecycle ライフサイクルでサポートされるのは有効期限部分のみです。アーカイブ（AWS Glacier）に関連するポリシーはサポートされません。ファイルシステム対応バケットでは、ライフサイクルはサポートされません。

DELETE Bucket policy

GET Bucket (List Objects) ファイルシステム対応バケットでは、バケット内のオブジェクトの一覧表示時に/区切り文字のみをサポートします。

GET Bucket cors

GET Bucket acl

GET Bucket lifecycle ライフサイクルでサポートされるのは有効期限部分のみです。アーカイブ（AWS Glacier）に関連するポリシーはサポートされません。ファイルシステム対応バケットでは、ライフサイクルはサポートされません。

GET Bucket policy

GET Bucket Object versions

GET Bucket versioning

HEAD Bucket

List Multipart Uploads

PUT Bucket ここで PUTは既存のバケットに対して実行されます。バケットがすでに存在する場合の動作（17 ページ）を参照してください。

PUT Bucket cors

PUT Bucket acl

PUT Bucket lifecycle ライフサイクルでサポートされるのは有効期限部分のみです。アーカイブ（AWS Glacier）に関連するポリシーはサポートされません。ファイルシステム対応バケットでは、ライフサイクルはサポートされません。

PUT Bucket policy ファイルシステム対応または CAS対応のバケットに対してバケットポリシーを構成することはできません。ECS でサポートされていないオペレーションには、バケットポリシーを構成できません。バケットポリシーのサポートの詳細については、バケットポリシーのサポートを参照してください。

PUT Bucket versioning

DELETE Object

Delete Multiple Objects

GET Object

S3

S3 API のサポート対象およびサポート対象外の機能 15

表 1 サポートされている S3 API （続き）

機能注

GET Object ACL

HEAD Object

PUT Object チャンクにした PUT をサポート

PUT Object acl

PUT Object - Copy

OPTIONS object

Initiate Multipart Upload

Upload Part

Upload Part - Copy

Complete Multipart Upload ECSはこのリクエストに対して 00 の ETag を返します。これはAmazon S3 レスポンスとは異なります。

Abort Multipart Upload

List Parts

l 3文字未満の名前を使用したバケットの作成は、400 Bad Request、InvalidBucketName として失敗します。

l 空のコンテンツでバケットまたはオブジェクトを作成すると、ECSは 400 invalidcontent-length value を返します。これは、400 Bad Request を返す、AWS とは異なります。

l 同じユーザーメタデータインデックスキーである一方でデータタイプの異なるインデックスを作成するオブジェクトを別のバケットにコピーすることはサポートされておらず、500 ServerError で失敗します。

l バケット内のオブジェクトを一覧表示する場合に、プレフィックスおよび区切り文字を使用する一方で無効なマーカーを指定すると、ECSは、500 Server Error、またはファイルシステム対応バケットに対する 400 Bad Request をスローします。これは、OK 200 を返してオブジェクトを一覧表示しない AWS とは異なります。

表 2 追加機能

機能注

Pre-signed URLs ECSは署名済み URL の使用をサポートします。これにより、認証情報を必要とせずにオブジェクトへのアクセスを与えます。

詳細については、こちらを参照してください。

Chunked PUT PUT操作を使用して、オブジェクトをチャンクでアップロードできます。これにより、ペイロードの総サイズがわかる前に、コンテンツを送信できます。チャンク転送は Transfer-Encoding ヘッダー（Transfer-

S3


http://docs.aws.amazon.com/AmazonS3/latest/dev/PresignedUrlUploadObject.html

表 2 追加機能（続き）

機能注

Encoding: chunked）を使用して、コンテンツがチャンクに転送されるように指定します。

サポートされていない S3 APIサポートされていない S3 API メソッドを次の表に示します。

表 3 サポートされていない S3 API

機能注

DELETE Bucket tagging

DELETE Bucket website

GET Bucket location ECSは単一の VDC（仮想データセンター）のみを認識します。

GET Bucket logging

GET Bucket notification 通知は S3 の低冗長化機能に対してのみ定義されます。ECSは現在、通知をサポートしていません。

GET Bucket tagging

GET Bucket requestPayment ECS では独自の支払いモデルを使用します。

GET Bucket website

PUT Bucket logging

PUT Bucket notification 通知は S3 の低冗長化機能に対してのみ定義されます。ECSは現在、通知をサポートしていません。

PUT Bucket tagging

PUT Bucket requestPayment ECS では独自の支払いモデルを使用します。

PUT Bucket website

オブジェクト API

GET Object torrent

POST Object

POST Object restore この操作は AWS Glacier に関連しているため、ECS ではサポートされません。

バケットがすでに存在する場合の動作

すでに存在する名前でバケットを作成しようとした場合、ECS の動作は AWS とは異なります。AWS では、バケットに対するフルコントロール権限またはその他の任意の権限を持つユーザーがバケットの再作成を試みた場合、常に 409 Conflict を返します。バケットに対するFULL_CONTROL またはWRITE_ACP を持つ ECS ユーザーがバケットの再作成を試みた場合、ECSは 200 OK を返した上で ACL が上書きされますが、所有者は変更されません。書き込

S3

バケットがすでに存在する場合の動作 17

み/読み取り権限を持つ ECS ユーザーがバケットの再作成を試みると、409 Conflict を受け取ることになります。バケットの所有者がバケットの再作成を試みると、ECSは 200 OK を返し、ACL を上書きします。AWSは、同じ方法で動作します。ユーザーがバケット対するアクセス権限を持たない場合、バケットを再作成しようとすると 409Conflict エラーがスローされます。AWSは、同じ方法で動作します。

バケットポリシーのサポートECS では、S3バケットアクセスポリシーの設定をサポートしています。すべてのアクションを許可するかまったく許可しない ACL とは異なり、アクセスポリシーは、特定のユーザーまたはすべてのユーザーに、特定のアクションに対する条件付きで細分性の高い権限を付与する機能を提供します。ポリシーの条件は、条件と一致するさまざまなオブジェクトの権限を割り当てるために使用でき、新しくアップロードされたオブジェクトに権限を自動的に割り当てるために使用できます。S3 プロトコルを使用するときにリソースへのアクセスを管理する方法については http://docs.aws.amazon.com/AmazonS3/latest/dev/s3-access-control.html に記載されており、ECS における S3バケットポリシーを理解し、使用する基礎として使用できます。このセクションに記載される情報は、バケットポリシーの使用に関する基本的な情報を提供し、ECS でバケットポリシーを使用する場合の相違点を特定するために提供されています。ECSバケットポリシーの例を次に示します。

{ "Version": "2012-10-17", "Id": "S3PolicyIdNew2", "Statement":[ { "Sid":"Granting PutObject permission to user2 ", "Effect":"Allow", "Principal": "user_n2", "Action":["s3:PutObject"], "Resource":["PolicyBuck1/*"], "Condition": { "StringEquals": {"s3:x-amz-server-side-encryption": [ "AES256"]} } } ]}

各ポリシーは、バージョン、識別子、および 1 つ以上のステートメントで構成される JSON（JavaScript Object Notation）ドキュメントです。

Version

［Version］フィールドは、ポリシー言語バージョンを指定し、2012-10-17 または2008-10-17 のいずれかです。バージョンが指定されていない場合は 2008-10-17 が自動的に挿入されます。

これは、新しいポリシーのポリシー言語は最新バージョンの 2012-10-17 に設定することをお勧めします。

Id

［Id］フィールドはオプションです。

各ステートメントは、次の要素で構成されています。

S3


http://docs.aws.amazon.com/AmazonS3/latest/dev/s3-access-control.html

http://docs.aws.amazon.com/AmazonS3/latest/dev/s3-access-control.html

SID

ステートメント ID。これは、ステートメントで行う操作を説明する文字列です。

リソースステートメントの対象になっているバケットまたはオブジェクトです。リソースには、Resource または NotResource ステートメントを関連づけることができます。

リソース名はバケットとキー名前で、次に示すように、仮想ホスト形式のアドレス指定を使用しているのか、パス形式のアドレス指定を使用しているかに応じて指定が異なります。

Host Style: http://bucketname.ns1.emc.com/objectnamePath Style: http://ns1.emc.com/bucketname/objectname

いずれの場合も、リソース名は次のようになります。bucketname/objectname 。ワイルドカード文字の*および?を使用できます。アスタリスク（*）は 0個以上の文字の任意の組み合わせを表し、疑問符（?）は任意の 1文字を表します。たとえば、次のように使用して［bucketname］というバケット内のすべてのオブジェクトを表すことができます。

bucketname/*

Actions

権限（許可または拒否）を割り当てる一連の操作です。サポートされているすべての操作は、サポートされているバケットポリシー操作（22 ページ）のリストに示されています。

操作には Action または NotAction ステートメントを関連づけることができます。

作用Allow または Deny に設定して、指定されたアクションを許可するのか拒否するのかを判別できます。

Principal

指定されたアクションを許可または拒否される ECS オブジェクトユーザーです。

匿名アクセスと呼ばれるすべてのユーザーへの権限付与は、プリンシパルの値に、次のようにワイルドカード「*」を設定することで実現できます。

"Principal":"*"

ECSバケットポリシーはフェデレーションユーザーをサポートせず、Amazon IAM のユーザーとロールもサポートしません。

Conditions

ポリシーが有効になる条件です。条件式を使用して、ポリシーに規定されている条件と、リクエストに規定されている条件が照合されます。

次の条件演算子はサポートされません。Binary、ARN、IfExists、Check Key Exists。サポートされている条件キーは、サポートされているバケットポリシーの条件（23 ページ）の一覧に示されています。

S3

バケットポリシーのサポート 19

ポリシーで使用できるエレメントの詳細については、ここにある Amazon S3 のドキュメントで説明されています。

バケットポリシーの作成、割り当て、管理

ECS Portal からバケットのバケットポリシーを作成できます（ECS製品ドキュメントページ内の使用可能な「ECS管理ガイド」を参照してください）。別のエディタを使用してポリシーを作成し、ECSManagement REST API を使用するか ECS S3 API を使用してバケットにポリシーを関連付けることもできます。ECS Management REST API には、バケットポリシーサブリソースの追加、取得、削除を可能にする次の API が用意されています。l PUT /object/bucket/{bucketName}/policyl GET /object/bucket/{bucketName}/policyl DELETE /object/bucket/{bucketName}/policyECS Management REST API を使用してポリシーを設定するには、ECS システム管理者またはネームスペース管理者のいずれかのロールを持つ必要があります。ECS S3 API には、次の API が用意されています。l PUT Bucket Policyl GET Bucket Policyl DELETE Bucket Policy

S3 API を使用してポリシーを設定するには、バケットの所有者である必要があります。

これらの API の詳細については、ECS API リファレンスを参照してください。

バケットポリシーのシナリオ

一般に、バケットの所有者にはバケットに対するフルコントロールがあり、他のユーザーに権限を付与し、S3 クライアントを使用して S3バケットのポリシーを設定することができます。ECS で、ECS システムまたはネームスペース管理者は ECS Portal でバケットポリシーエディタを使用してバケットポリシーを設定できます。次の一般的なシナリオでは、バケットポリシーを使用できます。l ユーザーにバケットの権限を付与します。（20 ページ）l すべてのユーザーにバケットの権限を付与します。（21 ページ）l 作成するオブジェクトへの権限の自動割り当て（21 ページ）

ユーザーにバケットの権限を付与します。バケットの所有者以外のユーザーにバケットに対する権限を付与する場合、権限を変更するリソースを指定し、主な属性をユーザー名に設定し、許可する 1 つ以上のアクションを指定できます。次の例では、ユーザー名 user1 にバケット名 mybucket のオブジェクトの更新および読み取りの権限を付与するポリシーを示します。

{ "Version": "2012-10-17", "Id": "S3PolicyId1",

S3


http://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html


http://doc.isilon.com/ECS/3.1/API/index.html

"Statement": [ { "Sid": "Grant permission to user1", "Effect": "Allow", "Principal": ["user1"], "Action": [ "s3:PutObject","s3:GetObject" ], "Resource":[ "mybucket/*" ] } ]}

条件を追加することもできます。たとえば、ユーザーに特定の IP アドレスからバケットにアクセスするときに、オブジェクトを読み取りおよび書き込みできるようにする場合、次のポリシーに示すようにIpAddress条件を追加できます。

{ "Version": "2012-10-17", "Id": "S3PolicyId1", "Statement": [ { "Sid": "Grant permission ", "Effect": "Allow", "Principal": ["user1"], "Action": [ "s3:PutObject","s3:GetObject" ], "Resource":[ "mybucket/*" ] "Condition": {"IpAddress": {"aws:SourceIp": "<Ip address>"} } ]}

すべてのユーザーにバケットの権限を付与します。バケットの所有者以外のユーザーにバケットに対する権限を付与する場合、権限を変更するリソースを指定し、誰でも(*)として主な属性を設定し、許可する 1 つ以上のアクションを指定できます。次の例では、誰にでもバケット名 mybucket のオブジェクトの読み取りの権限を付与するポリシーを示します。

{ "Version": "2012-10-17", "Id": "S3PolicyId2", "Statement": [ { "Sid": "statement2", "Effect": "Allow", "Principal": ["*"], "Action": [ "s3:GetObject" ], "Resource":[ "mybucket/*" ] } ]}

作成するオブジェクトへの権限の自動割り当てバケットポリシーを使用して、取得したオブジェクトデータへのアクセスを自動的に有効化できます。次のバケットポリシーの例では、user1 と user2 がバケット名 mybucket のサブリソース（つまり、オブジェクト）を作成し、オブジェクト ACL を設定できます。ACL を設定できると、ユーザーが他のユーザーの権限を設定できます。同一の操作で ACL を設定する場合は、オブジェクトを作成するときに、あらかじめ用意された ACL のパブリックな読み取りを指定する必要があるなどの条件を設

S3

バケットポリシーのシナリオ 21

定できます。これにより、作成されたオブジェクトはすべて、どのユーザーでも読み取り可能になります。

{ "Version": "2012-10-17", "Id": "S3PolicyId3", "Statement": [ { "Sid": "statement3", "Effect": "Allow", "Principal": ["user1", "user2"], "Action": [ "s3:PutObject, s3:PutObjectAcl" ], "Resource":[ "mybucket/*" ] "Condition":{"StringEquals":{"s3:x-amz-acl":["public-read"]}} } ]}

サポートされているバケットポリシー操作

次の表は、サポートされている権限キーワードと、制御対象のバケット、オブジェクト、サブリソースに対する操作を示します。

表 4 オブジェクト操作のための権限

権限キーワードサポートされる S3操作

s3:GetObjectはバージョン対応バケットの最新バージョンに適用されます。

GET Object、HEAD Object

s3:GetObjectVersion GET Object、HEAD Object

この権限は、バージョン番号を指定するリクエストをサポートしています。

s3:PutObject PUT Object、POST Object、Initiate Multipart Upload、Upload

Part、Complete Multipart Upload PUT Object - Copy

s3:GetObjectAcl GET Object ACL

s3:GetObjectVersionAcl GET ACL（オブジェクトの特定バージョンが対象）

s3:PutObjectAcl PUT Object ACL

s3:PutObjectVersionAcl PUT Object（オブジェクトの特定バージョンが対象）

s3:DeleteObject DELETE Object

s3:DeleteObjectVersion DELETE Object（オブジェクトの特定バージョンが対象）

s3:ListMultipartUploadParts List Parts

s3:AbortMultipartUpload Abort Multipart Upload

表 5 バケット操作のための権限


s3:DeleteBucket DELETE Bucket

s3:ListBucket GET Bucket (List Objects)、HEAD Bucket

S3


表 5 バケット操作のための権限（続き）


s3:ListBucketVersions GET Bucket Object versions

s3:GetLifecycleConfiguration GET Bucket lifecycle

s3:PutLifecycleConfiguration PUT Bucket lifecycle

表 6 バケットのサブリソース操作のための権限


s3:GetBucketAcl GET Bucket acl

s3:PutBucketAcl PUT Bucket acl

s3:GetBucketCORS GET Bucket cors

s3:PutBucketCORS PUT Bucket cors

s3:GetBucketVersioning GET Bucket versioning

s3:PutBucketVersioning PUT Bucket versioning

s3:GetBucketPolicy GET Bucket policy

s3:DeleteBucketPolicy DELETE Bucket policy

s3:PutBucketPolicy PUT Bucket policy

サポートされているバケットポリシーの条件条件要素を使用して、ポリシーが有効である状況を判別する条件を指定します。次の表は、ECS でサポートされており、条件式に使用できる条件キーを示します。

表 7 サポートされる汎用 AWS条件キー

キー名説明該当する演算子

aws:CurrentTime 日付/時刻の条件をチェックするために使用日付の演算子

aws:EpochTime エポックまたは UNIX時間の日付を使用して日付/

時刻の条件を確認するために使用します（日付の条件演算子を参照してください）。

日付の演算子

aws:principalType 現在のリクエストに対するプリンシパルのタイプ（ユーザー、アカウント、連携されたユーザーなど）を確認するために使用します。

文字列の演算子

aws:SourceIp リクエスターの IP アドレスを確認するために使用します。


aws:UserAgent リクエスターのクライアントアプリケーションを確認するために使用します。


aws:username リクエスターのユーザー名を確認するために使用します。


S3

サポートされているバケットポリシーの条件 23

表 8 オブジェクト操作でサポートされている S3固有の条件キー

キー名説明適用される権限

s3:x-amz-acl ユーザーがオブジェクトをアップロードするときに特定のアクセス権限を必要とする条件を設定します。

s3:PutObject、s3:PutObjectAcl、s3:PutObjectVersionAcl

s3:x-amz-grant-permission

（明示的な権限用）で、可能な権限は read、write、read-acp、write-acp、full-control

バケットの所有者は、これらのキーを使用して特定の権限を必要とする条件を追加できます。

s3:PutObject、s3:PutObjectAcl、s3:PutObjectVersionAcl

s3:x-amz-server-side-encryption

リクエストでこのヘッダーを指定することをユーザーに要求します。

s3:PutObject、s3:PutObjectAcl

s3:VersionId オブジェクトの特定バージョンのデータに対してにのみユーザーのアクセスを制限します。

s3:PutObject、s3:PutObjectAcl、s3:DeleteObjectVersion

表 9 バケット操作でサポートされている S3固有の条件キー

キー名説明適用される権限

s3:x-amz-acl ユーザーがオブジェクトをアップロードするときに特定のアクセス権限を必要とする条件を設定

s3:CreateBucket、s3:PutBucketAcl

s3:x-amz-grant-permission

（明示的な権限用）で、可能な権限は read、write、read-acp、write-acp、full-control

バケットの所有者は、これらのキーを使用して特定の権限を必要とする条件を追加可能

s3:CreateBucket、s3:PutBucketAcl

s3:prefix 特定のプレフィックスを持つオブジェクトキーのみを取得します。

s3:ListBucket、s3:ListBucketVersions

s3:delimiter Get Bucket (List Objects)リクエストに区切り文字パラメーターを指定することをユーザーに要求します。


s3:max-keys max-keysパラメーターを指定することをユーザーに要求することで、Get Bucket (List Objects)

リクエストへのレスポンスで ECS が返すキーの数を制限します。


S3の拡張機能ECSは、さまざまな S3 API の拡張機能をサポートします。

拡張機能とサポート APIは以下の一覧表示のとおりです。l バイト範囲拡張機能（25 ページ）l 保存期間（29 ページ）l ファイルシステム対応（29 ページ）

S3


l メタデータの検索（30 ページ）

バイト範囲拡張機能

次のバイト範囲の拡張機能があります。l オブジェクト内でのバイト範囲の更新（25 ページ）l オブジェクトの一部を上書き（26 ページ）l オブジェクトにデータを追加（27 ページ）l オブジェクト内での複数のバイト範囲の読み取り（28 ページ）

バージョン管理されたオブジェクトに対するバイト範囲操作（更新/付加/上書き）では、新しいバージョンは作成されず、最新バージョン自体が更新されます。オブジェクトの古いバージョンに対するバイト範囲操作（更新/付加/上書き）では、最新バージョンが更新されます。

オブジェクト内でのバイト範囲の更新S3 プロトコルに対する ECS拡張機能を使用してオブジェクト内のバイト範囲を更新できます。オブジェクトの部分的な更新は、多くの場合に便利なことがあります。大容量ファイルの先頭に格納されているバイナリヘッダーを変更する場合などです。Amazon またはその他の S3 と互換性のあるプラットフォームでは、ファイル全体を再送信する必要があります。次のデモでは、バイト範囲更新の使用例を示しています。例では、 object1 の値は Thequick brown fox jumps over the lazy dog.

GET /bucket1/object1 HTTP/1.1Date: Mon, 17 Jun 2013 20:04:40 -0000x-emc-namespace: emcContent-Type: application/octet-streamAuthorization: AWS wuser1:9qxKiHt2H7upUDPF86dvGp8VdvI=Accept-Encoding: gzip, deflate, compress HTTP/1.1 200 OKDate: Mon, 17 Jun 2013 20:04:40 GMTContent-Type: application/octet-streamLast-Modified: Mon, 17 Jun 2013 20:04:28 GMTETag: 6Content-Type: application/jsonContent-Length: 43 The quick brown fox jumps over the lazy dog.

このオブジェクト内の特定の範囲を更新するには、オブジェクトデータリクエスト内の範囲ヘッダーに、更新するオブジェクトの開始および終了オフセットが含まれている必要があります。形式は次のとおりです。Range: bytes=<startOffset>-<endOffset>。以下の例では、10、11、12、13、14バイトがリクエストで送信された値によって置き換えられることを示す値 bytes=10-14 での範囲ヘッダーが PUT リクエストに含まれています。ここで、新しい値green が送信されます。

PUT /bucket1/object1 HTTP/1.1Content-Length: 5Range: bytes=10-14

S3

バイト範囲拡張機能 25

ACCEPT: application/json,application/xml,text/html,application/octet-streamDate: Mon, 17 Jun 2013 20:15:16 -0000x-emc-namespace: emcContent-Type: application/octet-streamAuthorization: AWS wuser1:xHJcAYAEQansKLaF+/4PdLBHyaM=Accept-Encoding: gzip, deflate, compress green HTTP/1.1 204 No ContentETag: 10x-amz-id-2: object1x-amz-request-id: 027f037c-29ea-4670-8670-de82d0e9f52aContent-Length: 0Date: Mon, 17 Jun 2013 20:15:16 GMT

オブジェクトを再度読み取ると、新しい値は The quick green fox jumps over thelazy dog.になります。単語 brown を green に置き換えてこのオブジェクト内の特定のバイト範囲が更新されています。

GET /bucket1/object1 HTTP/1.1Cookie: JSESSIONID=wdit99359t8rnvipinz4tbtuACCEPT: application/json,application/xml,text/html,application/octet-streamDate: Mon, 17 Jun 2013 20:16:00 -0000x-emc-namespace: emcContent-Type: application/octet-streamAuthorization: AWS wuser1:OGVN4z8NV5vnSAilQTdpv/fcQzU=Accept-Encoding: gzip, deflate, compress HTTP/1.1 200 OKDate: Mon, 17 Jun 2013 20:16:00 GMTContent-Type: application/octet-streamLast-Modified: Mon, 17 Jun 2013 20:15:16 GMTETag: 10Content-Type: application/jsonContent-Length: 43 The quick green fox jumps over the lazy dog.

オブジェクトの一部を上書きS3 プロトコルに対する ECS拡張機能を使用してオブジェクトの一部を上書きできます。オブジェクトの一部を上書きするには、書き込み先のデータと、開始オフセットを指定します。書き込まれるリクエストのデータは提供されたオフセットで開始されます。形式は次のとおりです。Range:<startingOffset>-。たとえば、オフセット 10 でデータ brown cat の書き込みを開始する場合、この PUT リクエストを発行します。

PUT /bucket1/object1 HTTP/1.1Content-Length: 9Range: bytes=10-ACCEPT: application/json,application/xml,text/html,application/octet-streamDate: Mon, 17 Jun 2013 20:51:41 -0000x-emc-namespace: emcContent-Type: application/octet-streamAuthorization: AWS wuser1:uwPjDAgmazCP5lu77Zvbo+CiT4Q=Accept-Encoding: gzip, deflate, compress

S3


brown cat HTTP/1.1 204 No ContentETag: 25x-amz-id-2: object1x-amz-request-id: 65be45c2-0ee8-448a-a5a0-fff82573aa3bContent-Length: 0Date: Mon, 17 Jun 2013 20:51:41 GMT

オブジェクトを取得するとき、データの一部が提供した開始オフセットで置き換えられ（green foxを brown cat で置き換え）、最終的な値は次になります。The quick brown catjumps over the lazy dog and cat.

GET /bucket1/object1 HTTP/1.1Date: Mon, 17 Jun 2013 20:51:55 -0000x-emc-namespace: emcContent-Type: application/octet-streamAuthorization: AWS wuser1:/UQpdxNqZtyDkzGbK169GzhZmt4=Accept-Encoding: gzip, deflate, compress HTTP/1.1 200 OKDate: Mon, 17 Jun 2013 20:51:55 GMTContent-Type: application/octet-streamLast-Modified: Mon, 17 Jun 2013 20:51:41 GMTETag: 25Content-Type: application/jsonContent-Length: 51 The quick brown cat jumps over the lazy dog and cat.

オブジェクトにデータを追加S3 プロトコルに対する ECS拡張機能を使用してオブジェクトの末尾にデータを追加できます。オブジェクトに追加したいものの、正確なバイトオフセットの決定が不十分または不便な場合があるかもしれません。このシナリオでは、ECS がオフセットを指定せずに（正しいオフセットは応答で返されます）、オブジェクトの末尾にデータを追加する機能を提供します。たとえば、Amazon またはその他の S3 と互換性のあるプラットフォーム上でログファイルの末尾に行を追加するには、完全なログファイルを再送信する必要があります。オブジェクトにデータを追加するために特別な値 bytes=-1-の範囲ヘッダーを使用できます。この方法で、既存のオブジェクトサイズを知らなくてもオブジェクトを拡張できます。形式は次のとおりです。Range: bytes=-1-サンプルのリクエストで、bytes=-1-の範囲の値を使用して既存のオブジェクトの末尾に追加する方法を次の例に示します。ここでは、値 and catはリクエストで送信されています。

PUT /bucket1/object1 HTTP/1.1Content-Length: 8Range: bytes=-1-ACCEPT: application/json,application/xml,text/html,application/octet-streamDate: Mon, 17 Jun 2013 20:46:01 -0000x-emc-namespace: emcContent-Type: application/octet-streamAuthorization: AWS wuser1:/sqOFL65riEBSWLg6t8hL0DFW4c=Accept-Encoding: gzip, deflate, compress and cat

S3

バイト範囲拡張機能 27

HTTP/1.1 204 No ContentETag: 24x-amz-id-2: object1x-amz-request-id: 087ac237-6ff5-43e3-b587-0c8fe5c08732Content-Length: 0Date: Mon, 17 Jun 2013 20:46:01 GMT

オブジェクトを取得したときに and cat が末尾に追加されて、次の完全な値が表示されます。The quick green fox jumps over the lazy dog and cat.

GET /bucket1/object1 HTTP/1.1ACCEPT: application/json,application/xml,text/html,application/octet-streamDate: Mon, 17 Jun 2013 20:46:56 -0000x-emc-namespace: emcContent-Type: application/octet-streamAuthorization: AWS wuser1:D8FSE8JoLl0MTQcFmd4nG1gMDTg=Accept-Encoding: gzip, deflate, compress HTTP/1.1 200 OKDate: Mon, 17 Jun 2013 20:46:56 GMTContent-Type: application/octet-streamLast-Modified: Mon, 17 Jun 2013 20:46:01 GMTETag: 24Content-Type: application/jsonContent-Length: 51 The quick green fox jumps over the lazy dog and cat.

オブジェクト内での複数のバイト範囲の読み取りS3 プロトコルに対する ECS拡張機能を使用してオブジェクト内の複数のバイト範囲を読み取ることができます。オブジェクトの複数の部分を読み取ることは、多くの場合に非常に便利なことがあります。たとえば、ビデオの複数の部分を取得する場合が挙げられます。Amazon またはその他の S3 と互換性のあるプラットフォームでは、各部分に対して異なるリクエストを送信する必要があります。object1 という名前のオブジェクト内で 2 つの特定のバイト範囲を読み取るために、Range:bytes==4-8,41-44 に以下の GET リクエストを発行します。読み取りレスポンスは、単語quick と lazy です。

GET /bucket1/object1 HTTP/1.1Date: Mon, 17 Jun 2013 20:51:55 -0000x-emc-namespace: emcRange: bytes==4-8,41-44Content-Type: application/octet-streamAuthorization: AWS wuser1:/UQpdxNqZtyDkzGbK169GzhZmt4=Accept-Encoding: gzip, deflate, compress HTTP/1.1 206 Partial ContentDate: Mon, 17 Jun 2013 20:51:55 GMTContent-Type: multipart/byteranges;boundary=bound04acf7f0ae3cccLast-Modified: Mon, 17 Jun 2013 20:51:41 GMTContent-Length: 230 --bound04acf7f0ae3cccContent-Type: application/octet-streamContent-Range: bytes 4-8/50quick--bound04acf7f0ae3ccc

S3


Content-Type: application/octet-streamContent-Range: bytes 41-44/50lazy--bound04acf7f0ae3ccc--

保存期間

ECS S3 ヘッドは、オブジェクトの削除または変更を一定期間防止するための保存期間をサポートします。これは ECS拡張機能であり、標準 S3 API では使用できません。保存期間は次のように設定します。オブジェクトの保存期間

オブジェクトに保存期間を格納します。保存期間は、x-emc-retention-period ヘッダーを使用してオブジェクトに設定します。

オブジェクトの保存ポリシーオブジェクトに保存ポリシーを設定することができ、ポリシーに関連づけられた期間をネームスペースに設定することができます。これにより、ポリシーを使用してオブジェクトのグループの保存期間を同じ値に設定でき、ポリシーを変更すればすべてのオブジェクトを変更することができます。ポリシーの使用により、オブジェクトに保存期間を適用するよりもはるかに高い柔軟性が得られます。さらに、1 つのネームスペースに複数の保存ポリシーを設定できるため、オブジェクトのグループごとに異なる保存期間を設定できます。保存ポリシーは、オブジェクト上の x-emc-retention-policy ヘッダーを使用してオブジェクトに適用されます。ポリシー保存期間は、ECS管理者が ECS Portal からか、ECSManagement REST API を使用して設定する必要があります。

バケットの保存期間バケットに対して格納されている保存期間により、すべてのオブジェクトに保存期間が設定されます。より長期にわたる保存が必要な場合は、オブジェクトレベル保存期間またはポリシーを使用して、オブジェクト固有の設定を行います。保存期間は、x-emc-retention-period ヘッダーを使用してバケットに設定します。

オブジェクトを変更または削除しようとする際に、バケット保存期間とオブジェクト保存期間のいずれが長いのかにより、この操作を実行できるかどうかが判別されます。オブジェクトの期間は、オブジェクトに直接設定されるか、オブジェクトの保存ポリシーを使用して設定されます。ECS Management REST API または ECS Portal で S3バケットを作成し、そこからバケットの保存期間を設定することもできます。

ライフサイクル（有効期限）と保存期間

ECSは、バージョン対応バケットとバージョン非対応バケットの両方で S3 LifecycleConfigurationをサポートします。オブジェクトの変更および削除後も、オブジェクトが一定期間確実に存在しているようにするには、バケットのバージョン管理を有効化し、ライフサイクル機能を使用して削除対象バージョンのオブジェクトをいつ ECS から削除するかを指定します。バージョン管理とライフサイクルは標準 S3機能です。ただし、ライフサイクルの有効期限は、ECS拡張機能である保存期間と密接に関連しています。保存期間が切れる前にライフサイクルの有効期限が切れても、保存期間が切れるまでオブジェクトは削除されません。

ファイルシステム対応

S3

保存期間 29

S3バケットは、FS（ファイルシステム）で使用できるようにすることもできます。S3 プロトコルを使用して書き込んだファイルを、NFSや HDFSなどのファイルプロトコルを使用して読み取ることができます。

FS アクセスの有効化S3 プロトコルを使用してバケットを作成する場合に、x-emc-file-system-access-enabled ヘッダーを使用すれば、FS アクセスが可能になります。ECS Portal から（または ECSManagement REST API を使用して）バケットを作成する場合も、ファイルシステムアクセスを有効にできます。

FS サポートの制限事項次の制限が適用されます。l バケットが FS対応になっている場合は、S3 ライフサイクル管理は有効化できません。l バケットが FS対応になっている場合は、保存期間を使用することはできません。

FSのクロスヘッドサポートクロスヘッドサポートとは、あるプロトコルで書いたオブジェクトに、別の ECS サポートプロトコルを使用してアクセスすることです。S3 ヘッドを使用して書き込まれたオブジェクトを、NFS および HDFS ファイルシステムプロトコルを使用して読み取り/書き込むことができます。クロスヘッドサポートで重要なことは、オブジェクトおよびファイルの権限をプロトコル間でどのように変換するかです。ファイルシステムアクセスの場合は、オブジェクトおよびファイルプロトコル間でのユーザーとグループの概念をどのように変換するかとなります。ファイルシステムによるクロスヘッドサポートの詳細については、ECS製品ドキュメントページ内の使用可能な「ECS管理ガイド」をご覧ください。

メタデータの検索ECS S3互換 API により、メタデータ検索拡張機能が使用できるようになります。この API を使用すると、メタデータに基づいてバケット内のオブジェクトのインデックスが作成され、メタデータインデックスのクエリーによってオブジェクトと関連データを見つけることができます。従来から、ECS S3 API を使用してメタデータをオブジェクトに関連づけることができ、対象オブジェクトの ID が分かれば、そのメタデータを読み取ることはできます。ただし、ECS メタデータ検索機能がなければ、バケット内のオブジェクトセットでの反復処理なしで、メタデータに基づいてオブジェクトを検索することはできません。メタデータは、「ユーザーメタデータ」でも「システムメタデータ」でもかまいません。システムメタデータは、ECS によって定義され自動的にオブジェクトに書き込まれます。ユーザーメタデータは、エンドユーザー要件に基づいてクライアントによって書き込まれます。システムメタデータとユーザーメタデータのどちらも、メタデータ検索のベースとしてインデックス作成し、使用することができます。インデックス作成できるメタデータ値の数は 30 までで、バケットの作成時に定義する必要があります。

小規模オブジェクト（100 KB以下）の場合、インデックスキーの数を増やすと、データの送出率がわずかに減少します。小規模オブジェクトに対してメタデータインデックスを使用した場合のインパクトは、「ECSパフォーマンスホワイトペーパー」に記載されているパフォーマンステストデータに示されています。

インデックス付けされたメタデータに基づいてオブジェクトをクエリーする場合は、クエリーに一致するオブジェクトと、インデックス付けされたメタデータの値が返されます。返されたオブジェクトに関連付けられたシステムおよび/またはユーザーメタデータをすべて返すこともできます。システムメタデータに加えて、オブジェクトにはオプションでメタデータ検索結果の一部として返すことのできる属性がありま

S3



す。インデックス作成できる使用可能システムメタデータ値と、オプションで検索クエリーの結果とともに返すことができるメタデータ値のリストは、こちらです。次のトピックでは、メタデータ検索機能を設定して使用するための手順が説明されています。l バケットへのメタデータインデックス値の割り当て（31 ページ）l S3 プロトコルによるメタデータのオブジェクトへの割り当て（34 ページ）l メタデータ検索クエリーの使用（34 ページ）

バケットへのメタデータインデックス値の割り当てECS Portal または ECS Management REST API を使用して、あるいは S3 プロトコルを使用して、バケットにメタデータインデックス値を設定することができます。インデックス値はインデックスしているメタデータの名前を反映している必要があり、システムメタデータまたはユーザーメタデータに基づきます。使用可能なシステムメタデータのリストは ECS のシステムメタデータとオプション属性（40 ページ）にあります。インデックス値は、バケットの作成時に設定されます。バケットに対するインデックス使用を無効化することはできますが、個々のインデックス値を変更または削除することはできません。

ポータルを使用したインデックス値の設定

［Manage］ > ［Bucket］ページで、バケットを作成し、作成時にインデックス値を割り当てることができます。詳細については、ECS製品ドキュメントページ内の使用可能な「ECS管理ガイド」を参照してください。

ECS Management REST API を使用したインデックス値の設定

次の表は、ECS Management REST API によるインデックス操作方法の説明と、API リファレンスへのリンクを示しています。

APIパス説明

GET /object/bucket/searchmetadata 新しいバケットへの割り当てに使用可能なすべてシステムメタデータキーの名前を一覧表示します。

POST /object/bucket 指定したバケットをインデックスするメタデータインデックス名を割り当てます。インデックス名はメソッドペイロードに指定します。

GET /object/bucket バケットのリストを取得します。各バケットのバケット情報はメタデータ検索の詳細を示しています。

GET /object/bucket/{bucketname}/info 選択したバケットの詳細を取得します。バケットの情報には、メタデータ検索の詳細が含まれます。

DELETE /object/bucket/{bucketname}/searchmetadata

メタデータキーを使用したインデックス作成を停止します。

例：使用可能なメタデータ名のリストを取得次の例では、インデックス作成に使用可能で、クエリーで返すことができるメタデータ名のリスト全体を取得します。

s3curl.pl --id myuser -- http://{host}:9020/?searchmetadata

S3

バケットへのメタデータインデックス値の割り当て 31


クエリーの結果は次のとおりです。

<MetadataSearchList xmlns="http://s3.amazonaws.com/doc/2006-03-01/"> <IndexableKeys> <Key> <Name>LastModified</Name> <Datatype>datetime</Datatype> </Key> <Key> <Name>Owner</Name> <Datatype>string</Datatype> </Key> <Key> <Name>Size</Name> <Datatype>integer</Datatype> </Key> <Key> <Name>CreateTime</Name> <Datatype>datetime</Datatype> </Key> <Key> <Name>ObjectName</Name> <Datatype>string</Datatype> </Key> </IndexableKeys> <OptionalAttributes> <Attribute> <Name>ContentType</Name> <Datatype>string</Datatype> </Attribute> <Attribute> <Name>Expiration</Name> <Datatype>datetime</Datatype> </Attribute> <Attribute> <Name>ContentEncoding</Name> <Datatype>string</Datatype> </Attribute> <Attribute> <Name>Expires</Name> <Datatype>datetime</Datatype> </Attribute> <Attribute> <Name>Retention</Name> <Datatype>integer</Datatype> </Attribute> </OptionalAttributes></MetadataSearchList>

例：バケットをインデックスしているキーのリストを取得次の例では、現在バケットをインデックスしているメタデータキーのリストを取得します。

s3curl.pl --id myuser -- http://{host}:9020/mybucket/?searchmetadata

この例の結果は次のとおりです。

<MetadataSearchList xmlns="http://s3.amazonaws.com/doc/2006-03-01/"> <MetadataSearchEnabled>true</MetadataSearchEnabled> <IndexableKeys> <Key> <Name>Size</Name> <Datatype>integer</Datatype> </Key>

S3


<Key> <Name>x-amz-meta-DAT</Name> <Datatype>datetime</Datatype> </Key> </IndexableKeys></MetadataSearchList>

S3 API を使用した値の設定

次の表は、S3 API によるインデックス操作方法の説明と、API リファレンスへのリンクを示しています。APIパス説明

GET /?searchmetadata 新規バケットのインデックス作成に使用可能なすべてのシステムメタデータの名前を一覧表示します。

PUT /{bucket} -H x-emc-metadata-search:{name[;datatype],...}

ヘッダーに示されている検索メタデータキーでバケットを作成します。

データタイプはユーザーメタデータキーと関連づけられている必要がありますが、システムメタデータキーの必要はありません。

GET /{bucket}/?searchmetadata 現在バケットをインデックスしているメタデータキーのリストを取得します。

例次の例は、3 つのシステムメタデータキーと 2 つのユーザーメタデータキーのメタデータインデックスを含むバケットの作成方法を示しています。

s3curl.pl --id myuser --createbucket -- http://{host}:9020/mybucket -H "x-emc-metadata-search:Size,CreateTime,LastModified,x-amz-meta-STR;String,x-amz-meta-INT;Integer"

新しいオブジェクトに x-amz-meta-を追加する場合、特殊文字を含む値を URL エンコードする必要はありません。

暗号化をメタデータ検索と組み合わせて使用：バケットで暗号化を使用するとき、インデックス付けされたオブジェクトメタデータキーは非暗号化形式で格納されるため、暗号化されたバケットに対するメタデータ検索を常に実行できます。システムが用意したキーを使用して暗号化が実行された場合、クエリーによって返されるオブジェクトのメタデータは暗号化され、テキスト形式で表示されます。一方、ユーザーが指定した暗号化キーを使用してデータが暗号化された場合、インデックス化されていないメタデータは、ユーザーが暗号化したキーを、クエリーを介して提供できないため、メタデータ検索クエリーが返すときにまだ暗号化されていることになります。

S3

暗号化をメタデータ検索と組み合わせて使用： 33

S3 プロトコルによるメタデータのオブジェクトへの割り当てエンドユーザーは、「x-amz-meta-」ヘッダーを使用して、オブジェクトにユーザーメタデータを割り当てることができます。割り当てる値は任意のテキスト文字列であり、大文字と小文字を区別します。

メタデータをオブジェクト検索（メタデータ検索機能）のベースとして使用できるようにメタデータのインデックスを作成する場合は、データにデータタイプを割り当てます。オブジェクトにメタデータを書き込む場合、検索で正しく使用できるように、クライアントは適切な形式でデータを書き込む必要があります。データタイプは次のとおりです。String

検索インデックス用語がテキストとしてマークされている場合、すべての検索比較においてメタデータ文字列は文字列として処理されます。

Integer

検索インデックス用語が整数としてマークされている場合、検索比較においてメタデータ文字列は整数に変換されます。

Decimal

検索インデックス用語が 10進数としてマークされている場合、メタデータ文字列は 10進数値に変換され、「.」文字は小数点とみなされます。

Datetime

検索インデックス用語が日付/時刻としてマークされている場合、メタデータ文字列は yyyy-MM-ddTHH:mm:ssZ という形式の日時として処理されます。文字列を日時として処理するためには、メタデータを yyyy-MM-ddTHH:mm:ssZ という形式で指定する必要があります。

例次の例では、S3 API を使用して、オブジェクトとそのオブジェクト上の 2 つのユーザーメタデータ値をアップロードします。

s3curl.pl --id myuser --put myfile -- http://{host}:9020/mybucket/file4 -i -H x-amz-meta-STR:String4 -H x-amz-meta-INT:407

メタデータ検索クエリーの使用メタデータ検索機能は、インデックスされたメタデータの検索ができる機能豊かなクエリー言語です。構文は、次の表のとおりです。

API の構文レスポンスボディ

GET /{bucket}/?query={expression}&attributes={fieldname,…}&sorted={selector}&include_older_version={true|false}&max-keys=(num_keys)&marker=(marker value)

<BucketQueryResult xmlns:ns2="http://s3.amazonaws.com/doc/2006-03-01/"> <Name>mybucket</Name> <Marker/> <NextMarker>NO MORE PAGES</NextMarker> <MaxKeys>0</MaxKeys> <ObjectMatches> <object> <objectName>file4</objectName> <objectId>09998027b1b7fbb21f50e13fabb481a237ba2f60f352d437c8da3c7c1c8d7589</objectId>

S3


API の構文レスポンスボディ

<versionId>0</versionId> <queryMds> <type>SYSMD</type> <mdMap> <entry> <key>createtime</key> <value>1449081778025</value> </entry> <entry> <key>size</key> <value>1024</value> </entry> <entry> <key>mtime</key> <value>1449081778025</value> </entry> </mdMap> </queryMds> <queryMds> <type>USERMD</type> <mdMap> <entry> <key>x-amz-meta-INT</key> <value>407</value> </entry> <entry> <key>x-amz-meta-STR</key> <value>String4</value> </entry> </mdMap> </queryMds> <indexKey/> </object> <object ... </object> </ObjectMatches></BucketQueryResult>

式のキーワードと意味は次のとおりです。expression

形式の表記例：

[(]{condition1}[%20[and/or]%20{condition2}][)][%20[and/or]%20…]

ここで、「condition」はフォーム内のメタデータキーの名前フィルターです。

{selector} {operator}{argument},

例：

LastModified > 2015-09-02T11:22:00Z

selector

バケットに関連づけられた検索可能キーの名前です。

operator

演算子です。==、>、<、<=、>= のいずれか

S3

メタデータ検索クエリーの使用 35

argument

selector の検証対象値。

attributes=[fieldname,...]

レポートに含める必要があるオプションのオブジェクト属性をすべて指定します。その属性がオブジェクトで使用されていれば、属性値がレポートに含まれます。オプションの属性値には次のものがあります。l ContentEncoding

l ContentType

l Retention

l Expiration

l Expires

さらに、検索クエリーから返されるオブジェクトに関連付けられたインデックスなしのメタデータを返すことができます。次の値があります。ALL

返されるオブジェクトに関連付けられているシステムとユーザーの両方のメタデータが一覧表示されます。

ALL_SMD

返されるオブジェクトに関連付けられているシステムメタデータが一覧表示されます。

ALL_UMD

返されるオブジェクトに関連付けられているユーザーメタデータが一覧表示されます。

sorted=[selector]

バケットに関連づけられた検索可能なキーの名前を 1 つ指定します。キー名は式の中にあるキーの必要があります。&sorted=keyname がない場合は、クエリー式に表示される最初のキー名にしたがって出力がソートされます。

式に「or」演算子がある場合は、ソート順は特定できません。

include-older-versions=[true|false]

バケットの S3 のバージョン管理が有効になります。true に設定すると、式に一致するオブジェクトの現在のバージョンと以前のバージョンが返されます。デフォルトは false です。

max-keys

返されるクエリーに一致するオブジェクトの最大数。max-keys より多くのオブジェクトがある場合、次の一致の取得に使用できるマーカーが返されます。

marker

前のクエリーが返したマーカーです。クエリーの一致を再開すべき位置を示します。

Datetime クエリー

ユーザーメタデータの datetime値は、ISO-8601形式「yyyy-MM-dd'T'HH:mm:ssZ」で指定され、その形式で ECS に永続化されます。メタデータクエリーも、この形式を使用します。ただし、

S3


ECSはシステムメタデータの datetime値を、1970年を起点としたミリ秒単位の数である「エポック時刻」として永続化します。クエリーが結果を返す場合は、ECS によって永続化された datetime形式で返されます。2 つの形式の例は次のとおりです。ユーザーメタデータのアップロードヘッダーの例：

-H x-amz-meta-Foo:2015-11-30T12:00:00Z

ユーザーおよびシステムクエリー式の形式：

?query=CreateTime>2015-01-01T00:00:00Z and x-amz-meta-Foo==2015-11-30T12:00:00Z

クエリーの結果のフラグメント：システムメタデータ

<key>createtime</key> <value>1449081777620</value>

クエリーの結果のフラグメント：ユーザーメタデータ

<key>x-amz-meta-Foo</key> <value>2015-11-30T12:00:00Z</value>

markers と max-keys を使用した結果のページ割り付け

max-keys クエリーパラメーターを使用して、クエリーが返すオブジェクトの最大数を指定することができます。次の例では、オブジェクトの最大数に 3 を指定します。

?query=CreateTime>2015-01-01T00:00:00Z and x-amz-meta-Foo==2015-11-30T12:00:00Z&max-keys=3

指定された max-keys より多くのオブジェクトがクエリーに一致すると、クエリーに一致したにもかかわらず今回返されなかったオブジェクトを、次のページで返す際に使用するマーカーも返されます。次のクエリーでは、前のクエリーで取得したマーカーを指定します。

?query=CreateTime>2015-01-01T00:00:00Z and x-amz-meta-Foo==2015-11-30T12:00:00Z&max-keys=3&marker=rO0ABXNyAD...

返されたオブジェクトが最後のページのオブジェクトの場合、レスポンスボディの NextMarker に「NO MORE PAGES」が返されます。

<NextMarker>NO MORE PAGES</NextMarker>

クエリーでの特殊文字の使用

S3

メタデータ検索クエリーの使用 37

確実に ECS REST サービスが特殊文字を正確に受信するようにするには、URL エンコーディングを使用する必要があります。ECS がクエリーを解析する場合に、記号を間違って解釈することがないように、引用符で囲む必要がある場合もあります。例：l x-amz-meta の値をクエリーする場合は、特殊文字を URL エンコードする必要があります。

例：「%」（ASCII 25 16進数）や「/」（ASCII %2F）を使用する場合、それぞれ%25 と 2Fにエンコードする必要があります。

l SQL の予約文字を含む x-amz-meta の値をクエリーする場合は、予約文字をエスケープする必要があります。これは、ECS が使用する SQLパーサがこうした文字を演算子として認識しないためです。例：'ab < cd'（ECS が使用する SQLパーサがこうした文字を演算子として認識しないため、引用符のペアがサービスに確実に渡されるようにします）。SQL の予約文字には、比較演算子（=、<、>、+、-、!、~）と構文のセパレータ（コンマ、セミコロン）があります。引用符で囲む場合に、使用するクライアントに応じて、別の方法を使用することもできます。例えば、S3curl.pl のような Unix コマンドラインツールの場合は、次のようになります。

?query="'ab+cd<ed;ef'"

この例では、検索値がシングルクォートで囲まれ、それがさらにダブルクォートで囲まれています。

メタデータ検索の例

次の例では、S3 API を使用して、特定のオブジェクトサイズとユーザーメタデータ値に一致するバケットを検索しています。

一部の REST クライアントでは、「スペース」を url コード%20 にエンコードする必要がある場合があります。

s3curl.pl --id myuser -- "http://{host}:9020.mybucket?query=Size>1000%20and%20x-amz-meta-STR>=String4

検索に一致した 3 つのオブジェクトが結果として表示されます。

<BucketQueryResult xmlns:ns2="http://s3.amazonaws.com/doc/2006-03-01/"> <Name>mybucket</Name> <Marker/> <NextMarker>NO MORE PAGES</NextMarker> <MaxKeys>0</MaxKeys> <ObjectMatches> <object> <objectName>file4</objectName> <objectId>09998027b1b7fbb21f50e13fabb481a237ba2f60f352d437c8da3c7c1c8d7589</objectId> <versionId>0</versionId> <queryMds> <type>SYSMD</type> <mdMap> <entry> <key>createtime</key> <value>1449081778025</value> </entry> <entry>

S3


<key>size</key> <value>1024</value> </entry> <entry> <key>mtime</key> <value>1449081778025</value> </entry> </mdMap> </queryMds> <queryMds> <type>USERMD</type> <mdMap> <entry> <key>x-amz-meta-INT</key> <value>407</value> </entry> <entry> <key>x-amz-meta-STR</key> <value>String4</value> </entry> </mdMap> </queryMds> <indexKey/> </object> <object> <objectName>file5</objectName> <objectId>1ad87d86ef558ca0620a26855662da1030f7d9ff1d4bbc7c2ffdfe29943b9150</objectId> <queryMds> <type>SYSMD</type> <mdMap> <entry> <key>createtime</key> <value>1449081778396</value> </entry> <entry> <key>size</key> <value>1024</value> </entry> <entry> <key>mtime</key> <value>1449081778396</value> </entry> </mdMap> </queryMds> <queryMds> <type>USERMD</type> <mdMap> <entry> <key>x-amz-meta-INT</key> <value>507</value> </entry> <entry> <key>x-amz-meta-STR</key> <value>Sring5</value> </entry> </mdMap> </queryMds> <indexKey/> </object> </ObjectMatches></BucketQueryResult>

ECS Java SDK からのメタデータ検索の使用

S3

ECS Java SDK からのメタデータ検索の使用 39

SDK 3.0 には、3.0 より前の ECS に接続する場合に、シグネチャから「search」パラメーターと「searchmetadata」パラメーターを除外するオプションがあります。これらのパラメーターは ECS 2.xのシグネチャ計算にはありませんが、セキュリティの拡張のために計算に加えられました。次の表は、SDK のメタデータ検索機能の互換性を示しています。

ECSバージョン

2.x 3.x

SDK 2.x ○ ×

SDK 3.x ○ ○

ECS のシステムメタデータとオプション属性システムメタデータは、オブジェクトストアに格納された各オブジェクトに自動的に関連づけられます。システムメタデータの一部は常に使用され、インデックスキーとして使用することができます。その他のメタデータは常に使用されるわけではありません。存在していれば、メタデータ検索クエリーの結果とともに返すことができます。

システムメタデータ次の表に記載されているシステムメタデータは、メタデータ検索インデックスのキーとして使用することができます。

名前（エイリアス）タイプ説明

ObjectName string オブジェクトの名前。

Owner string オブジェクトの所有者の ID。

Size integer オブジェクトのサイズ。

CreateTime datetime オブジェクトの作成日時。

LastModified datetime オブジェクトの最後変更日時。

変更は純粋な S3 API ではなく、ECS S3バイト範囲更新拡張機能でサポートされています。

オプションのメタデータ属性オプションのシステムメタデータ属性は、オブジェクトで使用されている場合とされていない場合があります。オプションで、検索クエリー結果とともに返すことができます。次の表は、オプションのシステムメタデータ属性の一覧です。

名前（エイリアス）タイプ

ContentType string

Expiration datetime

ContentEncoding string

Expires datetime

Retention integer

S3


S3 と Swiftの相互運用性S3 と Swift のプロトコルは相互運用性を持つため、S3 アプリケーションは Swiftバケット内のオブジェクトにアクセスでき、Swift アプリケーションは S3バケット内のオブジェクトにアクセスできます。S3 ヘッドを使用して作成されたオブジェクトに Swift ヘッドを使用してアクセスできるかどうかおよびこの逆のパターンを検討する場合は、ユーザーがバケット（Swift ではコンテナと呼ぶ）にアクセスできるかどうかをまず検討する必要があります。バケットには、バケットを作成した ECS ヘッドに基づいてバケットタイプ（S3、Swiftなど）が割り当てられます。アプリケーションが Swift と S3 の両方のバケットにアクセスできることを確実化するには、オブジェクトユーザーにこのバケットのタイプに対する適切な権限があることを確認する必要があります。権限を判別する方法は Swiftバケットと S3バケットで異なるため、この作業にはいくらかの考慮が必要です。

S3 と Swift の相互運用性は、バケットポリシーの使用と互換性がありません。バケットポリシーは、S3 ヘッドを使用するバケットアクセスのみに適用され、Swift API を使用してバケットにアクセスする際には適用されません。

ECS では、S3 と Swift の両方の認証情報に同一のオブジェクトユーザー名を指定できます。そのため、ECS に関する限り、Swift ユーザーとして認証されている john というユーザーは、john がアクセスを許可されているすべての S3 リソースにアクセスできます。リソースへのアクセスは、バケットの所有者であることによるか、ACL を使用してバケット上で権限を割り当てられていることによって判別されます。たとえば、バケットが S3 ユーザーによって作成されている場合、このバケットはこの S3 ユーザー名によって所有され、このバケットに対するフル権限がそのユーザーに与えられます。そして、同じ名前を持つ Swift ユーザーに、そのバケットに対するフル権限が同様に与えられます。所有者以外のユーザーがバケットにアクセスできるようにするには、ACL を使用して権限を割り当てることができます。Swift コンテナへのアクセスはグループ ACL（ECS では、カスタムグループ ACL）を使用して許可でき、Swift ヘッドでは、グループ ACL権限をチェックする前にグループメンバーシップのチェックを実行します。Swift コンテナには admin グループが暗黙的に追加されていると見なすことが可能で、そのため admin グループのメンバーであるすべてのユーザー（admin ユーザー）は、admin ユーザーのその他のすべてのコンテナにアクセスできます。admin ユーザーのみが、すべてのコンテナを作成、削除、リストする権限を持ちます。admin ユーザーの権限は、ユーザーが所属するネームスペースにのみ適用されます。S3バケットへのアクセスは、グループの権限ではなくユーザーの権限（ユーザー ACL）に依存します。バケットへのアクセスを判別するために、S3 ヘッドでは、ユーザーがバケットに対する ACL権限を持つかどうかをチェックします。これを次の図に示します。

S3

S3 と Swift の相互運用性 41

S3 HEAD SWIFT HEAD

S3 APPLICATION

S3 BUCKET ACCESS SWIFT BUCKET ACCESS

GROUP ACLUSER ACL

SWIFT APPLICATION

ECS OBJECT USER

S3 KEY

SWIFT PASSWORDSWIFT GROUP

Swift user accessto Swift containerS3 user access

to S3 bucket

check Swift group ACLpermissions

Swift user access to S3 bucket

S3 user access to Swift container

check S3user ACL

CROSSHEAD

Swift ではグループを使用してリソースへのアクセスを有効化するため、S3 ユーザーが Swift コンテナにアクセスできるようにするには、S3 ユーザーを Swift グループに割り当てる必要もあります。このグループは、admin グループ、またはコンテナに対するカスタムグループ ACL を与えられているグループです。まとめると、S3バケットにアクセスするためには、次の条件のいずれかを満たす必要があります。l Swift ユーザーまたは S3 ユーザーはバケットの所有者である必要があります。l Swift ユーザーまたは S3 ユーザーはバケットの ACL に追加されていなければなりません。Swift コンテナにアクセスするには、次の条件のいずれかを満たす必要があります。l S3 ユーザーまたは Swift ユーザーはコンテナの所有者である必要があります。l S3 ユーザーは Swift ユーザーでもある必要があり、Swift グループに追加されている必要もあ

ります。ユーザーが、Swift admin グループのメンバー（カスタムグループが自動的に追加される）でない限り、この Swift グループをカスタムグループとして追加する必要があります。

l Swift ユーザーは、コンテナのグループ ACL に追加されているか、Swift admin グループに属している（カスタムグループが自動的に追加される）必要があります。

S3 API経由での Swift DLO オブジェクトの読み取りは機能しません。これは、リクエストは、オブジェクトを個別のパスから再度切り替えることのできる X-Object-Manifest メタデータキーの存在を知ることなく、読み取りの一般的なコードパスに従うことになるためです。

S3


MPU アップロードでは、「?uploadId=<uploadId>」サブリソースを認識できないため Swift listparts操作は失敗します。

秘密キーの作成と管理ECS オブジェクトサービスのユーザーには、サービスで認証するための秘密キーが必要です。秘密キーは、次の方法で作成してオブジェクトユーザーが使用できるようにします。l 管理者がキーを作成してオブジェクトユーザーに配信します（オブジェクトユーザーのキーの作

成（43 ページ）を参照）。l ドメインユーザーは、ECS Management REST API によって提供されるセルフサービス API

を使用して新しいシークレットキーを作成することでオブジェクトユーザーアカウントを作成します（S3 シークレットキーの作成：セルフサービス（44 ページ）を参照）。

1人のユーザーが秘密キーを 2 つ持つこともできます。秘密キーを変更する（「ロールオーバー」とも呼ばれる）場合、古いキーに分単位の有効期限を設定することができます。有効期限のインターバル中は、リクエストはどちらのキーも受け入れます。これは、新しいキーを使用するためにアプリケーションを更新する猶予期間になります。

オブジェクトユーザーのキーの作成ECS管理ユーザーは、オブジェクトユーザーの秘密キーを作成できます。l ECS ポータルからの秘密キーの作成（43 ページ）l ECS Management REST API を使用した S3 シークレットキーの作成（44 ページ）ECS ユーザーの詳細については、ECS製品ドキュメントページ内の使用可能な「ECS管理ガイド」を参照してください。

ECS ポータルからの秘密キーの作成ECS ポータルで秘密キーを生成できます。

はじめにl ECS システム管理者またはネームスペース管理者である必要があります。

システム管理者は、どのネームスペースに属するオブジェクトユーザーのシークレットキーでも作成できます。ネームスペース管理者は、自分のネームスペースに属するオブジェクトユーザーのシークレットキーを作成できます。

手順1. ECS Portal で、［Manage］ > ［Users］ページを選択します。2. ［Object Users］テーブルで、［New Object User］を選択するか、シークレットキーを割

り当てる既存ユーザーの［Edit］を選択します。3. S3 の場合は、［Generate & Add Password］を選択します。

ユーザーのシークレットキーを変更するには、2 つ目のシークレットキーを生成し、最初のキーの期限が切れる日時を指定できます。

4. 生成されたキーをコピーして、オブジェクトユーザーにメールで送信します。

S3

秘密キーの作成と管理 43


ECS Management REST API を使用した S3 シークレットキーの作成管理ユーザーは、ECS Management REST API を使用して S3 オブジェクトユーザーの秘密キーを作成できます。

APIは次のとおりです。APIパス説明

/object/user-secret-keys/{uid} オブジェクトユーザーへの秘密キーの割り当てと秘密キーの管理を行うための API。

ネームスペース管理者は、自分のネームスペースに属しているユーザーのキーを作成できます。システム管理者は、どのネームスペースのユーザーにもキーを割り当てることができます。

キーを変更するために、2番目のキーを割り当て、最初のキーの有効期限が切れる時刻を指定できます。

API コールの詳細については、ECS API リファレンスを参照してください。

S3 シークレットキーの作成：セルフサービスECS Management REST API により、認証されたドメインユーザーはオブジェクトストアにアクセスするための秘密キーをリクエストすることが可能です。ECS API リファレンスを参照して、特定の ECS管理操作を実行するためのカスタムクライアントを作成できます。操作は簡単で、ドメインユーザーは curl またはブラウザーベースの HTTP クライアントを使用して、秘密キーを作成するための API を実行できます。ユーザーが object/secret-keys API を実行すると、ECSは自動でオブジェクトユーザーを作成して秘密キーを割り当てます。

APIパス説明

/object/secret-keys S3 クライアントユーザーが新しい秘密キーを作成するための API。これにより、自分のネームスペース内のオブジェクトやバケットにアクセス可能になります。

これは、セルフサービス API とも呼ばれます。

/object/secret-keys のペイロードには、オプションとして既存のキーの有効期限を含めることができます。

<secret_key_create_param> <existing_key_expiry_time_mins></existing_key_expiry_time_mins> </secret_key_create_param>

秘密キーを初めて作成する場合は、existing_key_expiry_time_minsパラメーターを省略でき、コールは次のようになります。

POST object/secret-keys

Request body <?xml version="1.0" encoding="UTF-8"?> <secret_key_create_param/>

S3




Response <user_secret_key> <secret_key>...</secret_key> <key_timestamp>...</key_timestamp> <link rel="..." href="..." /> </user_secret_key>

セルフサービスキーの操作ここで示す例は、ECS Management REST API を使用したシークレットキーの作成、読み取り、管理に役立ちます。シークレットキーを使用した操作を実行するには、まずManagement API で認証する必要があります。ここで示した例では、curl ツールを使用しています。l ドメインユーザーとしてのログイン（45 ページ）l 最初のキーの生成（45 ページ）l 2番目のキーの生成（46 ページ）l キーの確認（46 ページ）l すべての秘密キーの削除（46 ページ） .

ドメインユーザーとしてのログインドメインユーザーとしてログインし、以後のリクエストの認証に使用可能な認証トークンを取得することができます。

curl -ik -u [email protected]:<Password> https://10.241.48.31:4443/loginHTTP/1.1 200 OKDate: Mon, 27 Apr 2015 17:29:38 GMTContent-Type: application/xmlContent-Length: 107Connection: keep-aliveX-SDS-AUTH-TOKEN: BAAcaVAzNU16eVcwM09rOWd2Y1ZoUFZ4QmRTK2JVPQMAQQIADTE0MzAwNzQ4ODA1NTQDAC51cm46VG9rZW46YWJmODA1NTEtYmFkNC00ZDA2LWFmMmMtMTQ1YzRjOTdlNGQ0AgAC0A8=

<?xml version="1.0" encoding="UTF-8" standalone="yes"?><loggedIn><user>[email protected]</user></loggedIn>

最初のキーの生成秘密キーを生成できます。

curl -ks -H "X-SDS-AUTH-TOKEN: BAAcaVAzNU16eVcwM09rOWd2Y1ZoUFZ4QmRTK2JVPQMAQQIADTE0MzAwNzQ4ODA1NTQDAC51cm46VG9rZW46YWJmODA1NTEtYmFkNC00ZDA2LWFmMmMtMTQ1YzRjOTdlNGQ0AgAC0A8=" -H "Content-Type: application/json" -X POST -d "{}" https://10.241.48.31:4443/object/secret-keys | xmllint --format -

<?xml version="1.0" encoding="UTF-8" standalone="yes"?><user_secret_key> <link rel="self" href="/object/user-secret-keys/[email protected]"/>

S3

S3 シークレットキーの作成：セルフサービス 45

<secret_key>7hXZ9/EHTVvmFuYly/z3gHpihXtEUX/VZxdxDDBd</secret_key> <key_expiry_timestamp/> <key_timestamp>2015-04-27 17:39:13.813</key_timestamp></user_secret_key>

2番目のキーの生成2番目の秘密キーを生成して、最初のキーの有効期限を設定することができます。

curl -ks -H "X-SDS-AUTH-TOKEN: BAAcaVAzNU16eVcwM09rOWd2Y1ZoUFZ4QmRTK2JVPQMAQQIADTE0MzAwNzQ4ODA1NTQDAC51cm46VG9rZW46YWJmODA1NTEtYmFkNC00ZDA2LWFmMmMtMTQ1YzRjOTdlNGQ0AgAC0A8=" -H "Content-Type: application/json" -X POST -d "{\"existing_key_expiry_time_mins\": \"10\"}" https://10.241.48.31:4443/object/secret-keys | xmllint --format -

<?xml version="1.0" encoding="UTF-8" standalone="yes"?><user_secret_key> <link rel="self" href="/object/user-secret-keys/[email protected]"/> <secret_key>l3fPCuFCG/bxoOXCPZoYuPwhXrSTwU0f1kFDaRUr</secret_key> <key_expiry_timestamp/> <key_timestamp>2015-04-27 17:40:12.506</key_timestamp></user_secret_key>

キーの確認自分に割り当てられたキーを確認できます。このケースでは、2 つのキーを使用し、最初のキーに有効期限の日時が設定されています。

curl -ks -H "X-SDS-AUTH-TOKEN: BAAcaVAzNU16eVcwM09rOWd2Y1ZoUFZ4QmRTK2JVPQMAQQIADTE0MzAwNzQ4ODA1NTQDAC51cm46VG9rZW46YWJmODA1NTEtYmFkNC00ZDA2LWFmMmMtMTQ1YzRjOTdlNGQ0AgAC0A8=" https://10.241.48.31:4443/object/secret-keys | xmllint --format -<?xml version="1.0" encoding="UTF-8" standalone="yes"?><user_secret_keys> <secret_key_1>7hXZ9/EHTVvmFuYly/z3gHpihXtEUX/VZxdxDDBd</secret_key_1> <secret_key_2>l3fPCuFCG/bxoOXCPZoYuPwhXrSTwU0f1kFDaRUr</secret_key_2> <key_expiry_timestamp_1>2015-04-27 17:50:12.369</key_expiry_timestamp_1> <key_expiry_timestamp_2/> <key_timestamp_1>2015-04-27 17:39:13.813</key_timestamp_1> <key_timestamp_2>2015-04-27 17:40:12.506</key_timestamp_2> <link rel="self" href="/object/secret-keys"/></user_secret_keys>

すべての秘密キーの削除秘密キーを再生成するために削除する必要がある場合は、次のように実行できます。

curl -ks -H "X-SDS-AUTH-TOKEN: BAAcaVAzNU16eVcwM09rOWd2Y1ZoUFZ4QmRTK2JVPQMAQQIADTE0MzAwNzQ4ODA1NTQDAC51cm46VG9rZW46YWJmODA1NTEtYmFkNC00ZDA2LWFmMmMtMTQ1YzRjOTdlNGQ0AgAC0A8=" -H "Content-Type: application/json" -X POST -d "{}" https://10.241.48.31:4443/object/secret-keys/deactivate

S3


S3 サービスでの認証ECS S3 サービスでは、シグネチャバージョン 2 とシグネチャバージョン 4 を使用する認証が可能です。このトピックでは、認証プロセスの ECS固有の側面を示します。Amazon S3は、すべてのリクエストに存在しなければならない認証ヘッダーを使用して、ユーザーを識別し、リクエストのシグネチャを提供します。シグネチャバージョン 2 の認証とシグネチャバージョン4 の認証では、認証ヘッダの形式が異なります。認証ヘッダーを作成するには、AWS アクセスキー ID とシークレットアクセスキーが必要です。ECSでは、AWS アクセスキー IDは、ECS UID（ユーザー ID）にマップされます。AWS アクセスキー IDは 20文字（S3 ブラウザなどの一部の S3 クライアントでは要確認）ですが、ECS データサービスにはこの制限はありません。シグネチャ V2 とシグネチャ V4 を使用する認証は、以下で導入されています。l シグネチャ V2 を使用する認証l シグネチャ V4 を使用する認証注意事項を次に示します。l ECS オブジェクトデータサービスでは、（ECS API または ECS UI を介して）2個の秘密キー

で UID を構成できます。ECS データサービスは 1個目の秘密キーの使用を試み、計算されたシグネチャが一致しない場合は、2個目の秘密キーの使用を試みます。2個目の秘密キーが失敗した場合には、データサービスはリクエストを拒否します。秘密キーを追加または変更するユーザーは、すべてのデータサービスノードが新しい秘密キーで更新されるように、2分間待ってから新しい秘密キーを使用する必要があります。

l ECS データサービスでは、ネームスペースも HMAC シグネチャの計算に取り入れられます。

シグネチャ V2 を使用する認証

シグネチャ V2 を使用する場合の認証ヘッダーは、次のようになります。

Authorization: AWS <AWSAccessKeyId>:<Signature>

例：

GET /photos/puppy.jpg?AWSAccessKeyId=user11&Expires=1141889120&Signature=vjbyPxybdZaNmGa%2ByT272YEAiv4%3D HTTP/1.1Host: myco.s3.amazonaws.comDate: Mon, 26 Mar 2007 19:37:58 +0000

シグネチャ V2 を使用する認証については、以下を参照してください。l http://docs.aws.amazon.com/AmazonS3/latest/dev/RESTAuthentication.html

シグネチャ V4 を使用する認証

シグネチャ V4 を使用する場合の認証ヘッダーは、次のようになります。

Authorization: AWS4-HMAC-SHA256 Credential=user11/20130524/us/s3/aws4_request, SignedHeaders=host;range;x-amz-date,

S3

S3 サービスでの認証 47

http://docs.aws.amazon.com/AmazonS3/latest/dev/RESTAuthentication.html

Signature=fe5f80f77d5fa3beca038a248ff027d0445342fe2855ddc963176630326f1024

認証情報コンポーネントは、アクセスキー ID と、それに続く認証情報の範囲で構成されます。認証情報の範囲は、日付/リージョン/サービス名/終了文字列で構成されます。ECS では、サービス名は常に S3 ですが、リージョンは任意の文字列です。シグネチャを計算する場合、ECSはクライアントから渡されるリージョン文字列を使用します。シグネチャ V4 を使用する認証については、以下を参照してください。l http://docs.aws.amazon.com/AmazonS3/latest/API/sig-v4-authenticating-

requests.html

l http://docs.aws.amazon.com/AmazonS3/latest/API/sig-v4-header-based-auth.html

シグネチャ V4 を使用する PUTバケットリクエストの例を以下に示します。

PUT /bucket_demo HTTP/1.1x-amz-date: 20160726T033659ZAuthorization: AWS4-HMAC-SHA256 Credential=user11/20160726/us/s3/aws4_request,SignedHeaders=host;x-amz-date;x-emc-namespace,Signature=e75a150daa28a2b2f7ca24f6fd0e161cb58648a25121d3108f0af5c9451b09cex-emc-namespace: ns1x-emc-rest-client: TRUEx-amz-content-sha256: e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855Content-Length: 0Host: 10.247.195.130:9021Connection: Keep-AliveUser-Agent: Apache-HttpClient/4.2.1 (java 1.5)

レスポンス：

HTTP/1.1 200 OKDate: Tue, 26 Jul 2016 03:37:00 GMTServer: ViPR/1.0x-amz-request-id: 0af7c382:156123ab861:4192:896x-amz-id-2: 3e2b2280876d444d6c7215091692fb43b87d6ad95b970f48911d635729a8f7ffLocation: /bucket_demo_2016072603365969263Content-Length: 0

ECSでの s3curlの使用ECS で使用するには、s3curl の改変バージョンが必要です。ECS カスタムヘッダー（x-emc）を使用する場合は、カスタムヘッダーを含めるように認証ヘッダーのシグネチャエレメントを構築する必要があります。さらに、ECS 3.0以降に接続する場合、「search」および「searchmetadata」パラメーターは、シグネチャ計算の一部です。これらの条件を処理するように変更された s3curl の ECS固有バージョンは、EMCECS Git リポジトリから入手できます。

S3


http://docs.aws.amazon.com/AmazonS3/latest/API/sig-v4-authenticating-requests.html

http://docs.aws.amazon.com/AmazonS3/latest/API/sig-v4-authenticating-requests.html

http://docs.aws.amazon.com/AmazonS3/latest/API/sig-v4-header-based-auth.html

http://docs.aws.amazon.com/AmazonS3/latest/API/sig-v4-header-based-auth.html

https://github.com/EMCECS/s3curl

https://github.com/EMCECS/s3curl

SDK を使って S3 サービスにアクセスECS S3 サービスと通信するアプリケーションを開発するにあたり、開発作業を支援する SDKはたくさんあります。ECS コミュニティでは、利用できるさまざまなクライアントの情報と、その使い方に関するガイダンスを提供しています。ECS コミュニティ：開発者リソース。以降のトピックでは、Amazon S3 SDK と ECS Java SDK の使い方について説明します。l Java Amazon SDK の使用（49 ページ）l ECS用の Java SDK クライアント（51 ページ）

ECS API拡張機能（S3 の拡張機能（24 ページ）参照）の利用では、ECS Java SDK でこうした拡張機能のサポートが提供されます。ECS拡張機能のサポートが不要な場合、またはそれを使用する既存のアプリケーションがある場合は、Amazon Java SDK を使用できます。

ECS Java SDK とメタデータ検索拡張機能との互換性については、「ECS Java SDK からのメタデータ検索の使用（39 ページ）」を参照してください。

Java Amazon SDK の使用Java S3 SDK を使用して ECS オブジェクトストレージにアクセスできます。AmazonS3Client クライアントオブジェクトは、デフォルトでは amazon.com に対して動作を直接実行するようにコーディングされています。このセクションでは、ECS に対して動作を実行するようにAmazonS3Client をセットアップする方法を説明します。AmazonS3Client オブジェクトのインスタンスを作成するには、認証情報を渡す必要があります。そのためには、AWSCredentials オブジェクトを作成し、AWS アクセスキー（ECS ユーザー名）とECS用生成済み秘密キーをオブジェクトに渡します。次のコードスニペットは、その実装方法を示しています。

AmazonS3Client client = new AmazonS3Client(new BasicAWSCredentials(uid, secret));

デフォルトでは、Amazon クライアントは Amazon WebServices に接続しようとします。この動作を無効にして ECS に接続するには、特別なエンドポイントを設定する必要があります。エンドポイントは、setEndpoint メソッドを使って設定します。エンドポイントで指定されるプロトコルは、クライアントが HTTP ポート（9020）と HTTPS ポート（9021）のどちらを経由すべきかを表しています。

HTTPS ポートを使用する場合は、ECS証明書を確認するようにアプリケーションの JDK をセットアップする必要があります。そうしないと、クライアントが SSL検証エラーを返し、接続に失敗します。

S3

SDK を使って S3 サービスにアクセス 49

https://community.emc.com/community/products/ecs#developer

次のスニペットでは、HTTP経由で ECS にアクセスするためのクライアントが使用されています。

AmazonS3Client client = new AmazonS3Client(new BasicAWSCredentials(uid, secret));client.setEndpoint("http://ecs1.emc.com:9020");

パス形式のアドレス指定（ecs1.emc.com/mybucket）を使用する場合は、次のようにsetPathStyleAccess オプションを設定する必要があります。

S3ClientOptions options = new S3ClientOptions();options.setPathStyleAccess(true);

AmazonS3Client client = new AmazonS3Client(new BasicAWSCredentials(uid, secret));client.setEndpoint("http://ecs1.emc.com:9020");client.setS3ClientOptions(options);

次のコードは、バケット内のオブジェクトを一覧にする方法を示しています。

ObjectListing objects = client.listObjects("mybucket");for (S3ObjectSummary summary : objects.getObjectSummaries()) { System.out.println(summary.getKey()+ " "+summary.getOwner());}

CreateBucket操作は、リージョン指定を求めらる点で他の操作とは異なります。これは S3 に対しては、バケットを作成するデータセンターを示すはずのものです。しかし、ECSはリージョンをサポートしないため、 CreateBucket操作をコールするときは標準リージョンを指定し、AWS クライアントが Amazon CloudFront から Amazon Region構成ファイルをダウンロードしないようにします。

client.createBucket("mybucket", "Standard");

ECS S3 データサービスと通信し、バケットを作成し、オブジェクトを操作するまでの全体的な例は、次のようになります。

public class Test { public static String uid = "root"; public static String secret = "KHBkaH0Xd7YKF43ZPFbWMBT9OP0vIcFAMkD/9dwj"; public static String viprDataNode = "http://ecs.yourco.com:9020";

public static String bucketName = "myBucket"; public static File objectFile = new File("/photos/cat1.jpg");

public static void main(String[] args) throws Exception {

AmazonS3Client client = new AmazonS3Client(new BasicAWSCredentials(uid, secret));

S3ClientOptions options = new S3ClientOptions(); options.setPathStyleAccess(true);

AmazonS3Client client = new AmazonS3Client(credentials); client.setEndpoint(viprDataNode); client.setS3ClientOptions(options);

client.createBucket(bucketName, "Standard"); listObjects(client);

S3


client.putObject(bucketName, objectFile.getName(), objectFile); listObjects(client);

client.copyObject(bucketName,objectFile.getName(),bucketName, "copy-" + objectFile.getName()); listObjects(client); }

public static void listObjects(AmazonS3Client client) { ObjectListing objects = client.listObjects(bucketName); for (S3ObjectSummary summary : objects.getObjectSummaries()) { System.out.println(summary.getKey()+ " "+summary.getOwner()); } }}

ECS用の Java SDK クライアントECS Java SDKは、Amazon S3 Java SDK をベースに構築され、ECS API拡張機能をサポートします。ViPRS3client の使用例を次に示します。

package com.emc.ecs.sample;

import com.amazonaws.util.StringInputStream;import com.emc.vipr.services.s3.ViPRS3Client;

public class BucketCreate {

private ViPRS3Client s3;

public BucketCreate() {

URI endpoint = new URI(“http://ecs.yourco.com:9020”); String accessKey = “[email protected]”; String secretKey = “pcQQ20rDI2DHZOIWNkAug3wK4XJP9sQnZqbQJev3”; BasicAWSCredentials creds = new BasicAWSCredentials(accessKey, secretKey); ViPRS3Client client = new ViPRS3Client(endpoint, creds);

}

public static void main(String[] args) throws Exception { BucketCreate instance = new BucketCreate(); instance.runSample(); } public void runSample() { String bucketName="mybucket"; String key1 = "test1.txt"; String content = "Hello World!"; try { s3.createBucket(bucketName); s3.putObject(bucketName, key1, new StringInputStream(content), null);

S3

ECS用の Java SDK クライアント 51

} catch (Exception e) { } }}

S3


第 2部

OpenStack Swift

第 2章, "OpenStack Swift"

OpenStack Swift 53

OpenStack Swift


第 2章

OpenStack Swift

l ECS の OpenStack Swift サポート........................................................................56l サポート対象の OpenStack Swift機能................................................................. 56l Swift の拡張機能................................................................................................58l Swiftバイト範囲拡張機能....................................................................................58l 保存期間............................................................................................................ 62l ファイルシステム対応............................................................................................. 63l S3 と Swift の相互運用性.................................................................................... 64l OpenStack Swift の認証.....................................................................................64l コンテナーに対する認証..........................................................................................72

OpenStack Swift 55

ECSの OpenStack Swift サポートECS には、OpenStack Swift API のサポートが含まれており、OpenStack環境での Swift を置き換えることができます。ここでは、サポート対象の処理と、許可および認証のメカニズムを説明します。OpenStack Swift サービスは、次のポートで使用できます。


HTTP 9024

HTTPS 9025

ECS では、OpenStack Swift API をサポートしており、この API をサポートするアプリケーションで使用できます。以降のトピックでは、サポートされるメソッド、ECS の拡張機能、認証のメカニズムを説明します。l サポート対象の OpenStack Swift機能（56 ページ）l Swift の拡張機能（58 ページ）l OpenStack Swift の認証（64 ページ）l コンテナーに対する認証（72 ページ）OpenStack Swift API の使用例については、次を参照してください。l OpenStack API の例OpenStack環境では、OpenStack Swift コンポーネントのリプレースとして、または既存のOpenStack Swift インストールとともに ECS を使用できます。ECSは、すべての OpenStack ディストリビューションで使用できますが、Mirantis OpenStack 9.1 を使用してテストされています。ECSは、Glanceバックエンドではなくエンドユーザーオブジェクトストレージの Swift のリプレースとしてテストされていることに注意してください。ECS で OpenStack を使用するには、OpenStack ユーザーを認証できるように ECS を構成する必要があります。認証の構成については、ECS Keystone V3統合を使用した認証を参照してください。

サポート対象の OpenStack Swift機能以降のセクションでは、ECS でサポートされる OpenStack REST API リクエストを挙げています。l サポート対象の OpenStack Swift コール（56 ページ）l サポート対象外の OpenStack Swift コール（58 ページ）この情報は、「OpenStack API リファレンス」文書の「Object Storage API V1」セクションから抜粋したものです。

サポート対象の OpenStack Swift コールECS では、次の OpenStack Swift REST API コールがサポートされます。

OpenStack Swift


http://docs.openstack.org/api/openstack-object-storage/1.0/content/ch_object-storage-dev-troubleshooting.html

http://developer.openstack.org/api-ref-objectstorage-v1.html

表 10 サポート対象の OpenStack Swift コール

方法パス説明

GET v1/{account} 既存のストレージコンテナを名前順に並べたリストを取得します。

POST v1/{account} カスタムメタデータヘッダーをアカウントレベル URI と関連づけることにより、アカウントメタデータを作成または更新します。こうしたヘッダーは、X-Account-Meta-*の形式を取る必要があります。

GET v1/{account}/{container}

コンテナに保存されたオブジェクトのリストを取得します。

PUT v1/{account}/{container}

コンテナを作成します。

DELETE v1/{account}/{container}

空のコンテナを削除します。

POST v1/{account}/{container}

カスタムメタデータヘッダーをコンテナレベル URI と関連づけることにより、任意のコンテナメタデータを作成または更新します。こうしたヘッダーは、X-Container-Meta-*の形式を取る必要があります。

HEAD v1/{account}/{container}

コンテナメタデータを取得します。現状ではオブジェクトカウントや使用バイトを含んでいません。ユーザーには管理者権限が必要です。

GET v1/{account}/{container}/{object}

オブジェクトのデータを取得します。

ECS 3.0以前にあらかじめセグメントが作成されていた場合、SLO（静的な大規模オブジェクト）に対する GET範囲は機能しません。

PUT v1/{account}/{container}/{object}

オブジェクトの内容とメタデータを書き込むか上書きします。ソースを指定する X-Copy-From ヘッダーを使って、既存のオブジェクトを別のオブジェクトにコピーするために使います。

DLO（動的な大規模オブジェクト）または SLO の場合、ここの説明のように、オブジェクトをマニフェストにすることができます。

DELETE v1/{account}/{container}/{object}

ストレージシステムからオブジェクトを恒久的に削除します。COPY コマンドと組み合わせて、COPY の次に DELETE を使うと、オブジェクトを有効に移動できます。

HEAD v1/{account}/{container}/{object}

オブジェクトメタデータと他の標準 HTTP ヘッダーを取得します。

POST v1/{account}/{container}/{object}

任意のオブジェクトメタデータを設定し上書きします。こうしたメタデータは、X-Object-Meta-*の形式を取る必要があります。オブジェクトの有効期限を設定する X-Delete-At またはX-Delete-After も、この操作で割り当てることができます。

OpenStack Swift

サポート対象の OpenStack Swift機能 57

http://docs.openstack.org/developer/swift/api/large_objects.html#static-large-objects

http://docs.openstack.org/developer/swift/api/large_objects.html#static-large-objects

表 10 サポート対象の OpenStack Swift コール（続き）

方法パス説明

ただし、Content-Typeなどの他のヘッダーは、この操作では変更できません。

表 11 追加機能

機能注

一時的な URL ECSは一時的な URL の使用をサポートします。これにより、ユーザーは認証情報なしでオブジェクトにアクセスできます。

詳細については、こちらを参照してください。

サポート対象外の OpenStack Swift コールECS では、次の OpenStack Swift REST API コールはサポートされません。

表 12 サポート対象外の OpenStack Swift コール

方法パス説明

COPY v1/{account}/{container}/{object}

コピー操作は、X-Copy-From ヘッダーを持つ PUT v1/

{account}/{container}/{object}を使って実現できます。

HEAD v1/{account} アカウントメタデータを取得します。格納されているバイト数（X-Account-Bytes-Used）にはゼロを返すため、完全にはサポートされていません。

Swiftの拡張機能ECSは、さまざまな Swift API の拡張機能をサポートします。

拡張機能とサポート APIは以下の一覧表示のとおりです。l Swiftバイト範囲拡張機能（58 ページ）l 保存期間（62 ページ）l ファイルシステム対応（63 ページ）

Swiftバイト範囲拡張機能次のバイト範囲の拡張機能があります。l オブジェクト内でのバイト範囲の更新（59 ページ）l オブジェクトの一部を上書き（60 ページ）l オブジェクトにデータを追加（61 ページ）l オブジェクト内での複数のバイト範囲の読み取り（62 ページ）

OpenStack Swift


https://docs.openstack.org/kilo/config-reference/content/object-storage-tempurl.html

オブジェクト内でのバイト範囲の更新Swift プロトコルに対する ECS拡張機能を使用してオブジェクト内のバイト範囲を更新できます。オブジェクトの部分的な更新は、多くの場合に便利です。大容量ファイルの先頭に格納されているバイナリヘッダーを変更する場合などです。Swift またはその他の Swift と互換性のあるプラットフォームでは、ファイル全体を再送信する必要があります。次のデモでは、バイト範囲更新の使用例を示しています。例では、 object1 の値は Thequick brown fox jumps over the lazy dog.

GET /container1/object1 HTTP/1.1Date: Mon, 17 Jun 2013 20:04:40 -0000x-emc-namespace: emcContent-Type: application/octet-streamAuthorization: AWS wuser1:9qxKiHt2H7upUDPF86dvGp8VdvI=Accept-Encoding: gzip, deflate, compress HTTP/1.1 200 OKDate: Mon, 17 Jun 2013 20:04:40 GMTContent-Type: application/octet-streamLast-Modified: Mon, 17 Jun 2013 20:04:28 GMTETag: 6Content-Type: application/jsonContent-Length: 43 The quick brown fox jumps over the lazy dog.

このオブジェクト内の特定の範囲を更新するには、オブジェクトデータリクエスト内の範囲ヘッダーに、更新するオブジェクトの開始および終了オフセットが含まれている必要があります。形式は次のとおりです。Range: bytes=<startOffset>-<endOffset>。以下の例では、10、11、12、13、14バイトがリクエストで送信された値によって置き換えられることを示す値 bytes=10-14 での範囲ヘッダーが PUT リクエストに含まれています。ここで、新しい値green が送信されます。

PUT /container1/object1 HTTP/1.1Content-Length: 5Range: bytes=10-14ACCEPT: application/json,application/xml,text/html,application/octet-streamDate: Mon, 17 Jun 2013 20:15:16 -0000x-emc-namespace: emcContent-Type: application/octet-streamAuthorization: AWS wuser1:xHJcAYAEQansKLaF+/4PdLBHyaM=Accept-Encoding: gzip, deflate, compress green HTTP/1.1 204 No ContentETag: 10x-amz-id-2: object1x-amz-request-id: 027f037c-29ea-4670-8670-de82d0e9f52aContent-Length: 0Date: Mon, 17 Jun 2013 20:15:16 GMT

OpenStack Swift

オブジェクト内でのバイト範囲の更新 59

オブジェクトを再度読み取ると、新しい値は The quick green fox jumps over thelazy dog.になります。単語 brown を green に置き換えてこのオブジェクト内の特定のバイト範囲が更新されています。

GET /container1/object1 HTTP/1.1Cookie: JSESSIONID=wdit99359t8rnvipinz4tbtuACCEPT: application/json,application/xml,text/html,application/octet-streamDate: Mon, 17 Jun 2013 20:16:00 -0000x-emc-namespace: emcContent-Type: application/octet-streamAuthorization: AWS wuser1:OGVN4z8NV5vnSAilQTdpv/fcQzU=Accept-Encoding: gzip, deflate, compress HTTP/1.1 200 OKDate: Mon, 17 Jun 2013 20:16:00 GMTContent-Type: application/octet-streamLast-Modified: Mon, 17 Jun 2013 20:15:16 GMTETag: 10Content-Type: application/jsonContent-Length: 43 The quick green fox jumps over the lazy dog.

オブジェクトの一部を上書きSwift プロトコルに対する ECS拡張機能を使用してオブジェクトの一部を上書きできます。オブジェクトの一部を上書きするには、書き込み先のデータと、開始オフセットを指定します。書き込まれるリクエストのデータは提供されたオフセットで開始されます。形式は次のとおりです。Range:<startingOffset>-たとえば、オフセット 10 でデータ brown cat の書き込みを開始する場合、次の PUT リクエストを発行します。

PUT /container1/object1 HTTP/1.1Content-Length: 9Range: bytes=10-ACCEPT: application/json,application/xml,text/html,application/octet-streamDate: Mon, 17 Jun 2013 20:51:41 -0000x-emc-namespace: emcContent-Type: application/octet-streamAuthorization: AWS wuser1:uwPjDAgmazCP5lu77Zvbo+CiT4Q=Accept-Encoding: gzip, deflate, compress brown cat HTTP/1.1 204 No ContentETag: 25x-amz-id-2: object1x-amz-request-id: 65be45c2-0ee8-448a-a5a0-fff82573aa3bContent-Length: 0Date: Mon, 17 Jun 2013 20:51:41 GMT

オブジェクトを取得するとき、データの一部が提供した開始オフセットで置き換えられ（green foxを brown cat で置き換え）、最終的な値は次になります。The quick brown catjumps over the lazy dog and cat.

GET /container1/object1 HTTP/1.1Date: Mon, 17 Jun 2013 20:51:55 -0000

OpenStack Swift


x-emc-namespace: emcContent-Type: application/octet-streamAuthorization: AWS wuser1:/UQpdxNqZtyDkzGbK169GzhZmt4=Accept-Encoding: gzip, deflate, compress HTTP/1.1 200 OKDate: Mon, 17 Jun 2013 20:51:55 GMTContent-Type: application/octet-streamLast-Modified: Mon, 17 Jun 2013 20:51:41 GMTETag: 25Content-Type: application/jsonContent-Length: 51 The quick brown cat jumps over the lazy dog and cat.

オブジェクトにデータを追加Swift プロトコルに対する ECS拡張機能を使用してオブジェクトの末尾にデータを追加できます。オブジェクトに追加したいものの、正確なバイトオフセットの決定が不十分または不便な場合があるかもしれません。このシナリオでは、ECS がオフセットを指定せずに（正しいオフセットは応答で返されます）、オブジェクトの末尾にデータを追加する機能を提供します。たとえば、Swift またはその他のSwift と互換性のあるプラットフォーム上でログファイルの末尾に行を追加するには、完全なログファイルを再送信する必要があります。オブジェクトにデータを追加するために特別な値 bytes=-1-の範囲ヘッダーを使用します。この方法で、既存のオブジェクトサイズを知らなくてもオブジェクトが拡張されます。形式は次のとおりです。Range: bytes=-1-サンプルのリクエストで、bytes=-1-の範囲の値を使用して既存のオブジェクトの末尾に追加する方法を次の例に示します。ここでは、値 and catはリクエストで送信されています。

PUT /container1/object1 HTTP/1.1Content-Length: 8Range: bytes=-1-ACCEPT: application/json,application/xml,text/html,application/octet-streamDate: Mon, 17 Jun 2013 20:46:01 -0000x-emc-namespace: emcContent-Type: application/octet-streamAuthorization: AWS wuser1:/sqOFL65riEBSWLg6t8hL0DFW4c=Accept-Encoding: gzip, deflate, compress and cat HTTP/1.1 204 No ContentETag: 24x-amz-id-2: object1x-amz-request-id: 087ac237-6ff5-43e3-b587-0c8fe5c08732Content-Length: 0Date: Mon, 17 Jun 2013 20:46:01 GMT

オブジェクトを取得したときに and cat が末尾に追加されて、次の完全な値が表示されます。The quick green fox jumps over the lazy dog and cat.

GET /container1/object1 HTTP/1.1ACCEPT: application/json,application/xml,text/html,application/octet-streamDate: Mon, 17 Jun 2013 20:46:56 -0000x-emc-namespace: emc

OpenStack Swift

オブジェクトにデータを追加 61

Content-Type: application/octet-streamAuthorization: AWS wuser1:D8FSE8JoLl0MTQcFmd4nG1gMDTg=Accept-Encoding: gzip, deflate, compress HTTP/1.1 200 OKDate: Mon, 17 Jun 2013 20:46:56 GMTContent-Type: application/octet-streamLast-Modified: Mon, 17 Jun 2013 20:46:01 GMTETag: 24Content-Type: application/jsonContent-Length: 51 The quick green fox jumps over the lazy dog and cat.

オブジェクト内での複数のバイト範囲の読み取りSwift プロトコルに対する ECS拡張機能を使用してオブジェクト内の複数のバイト範囲を読み取ることができます。オブジェクトの複数の部分を読み取ることは、多くの場合に非常に便利です。たとえば、ビデオの複数の部分を取得する場合が挙げられます。Swift またはその他の Swift と互換性のあるプラットフォームでは、各部分に対して異なるリクエストを送信する必要があります。object1 という名前のオブジェクト内で 2 つの特定のバイト範囲を読み取るために、Range:bytes==4-8,41-44 に以下の GET リクエストを発行します。読み取りレスポンスは、単語quick と lazy です。

GET /container1/object1 HTTP/1.1Date: Mon, 17 Jun 2013 20:51:55 -0000x-emc-namespace: emcRange: bytes==4-8,41-44Content-Type: application/octet-streamAuthorization: AWS wuser1:/UQpdxNqZtyDkzGbK169GzhZmt4=Accept-Encoding: gzip, deflate, compress HTTP/1.1 206 Partial ContentDate: Mon, 17 Jun 2013 20:51:55 GMTContent-Type: multipart/byteranges;boundary=bound04acf7f0ae3cccLast-Modified: Mon, 17 Jun 2013 20:51:41 GMTContent-Length: 230 --bound04acf7f0ae3cccContent-Type: application/octet-streamContent-Range: bytes 4-8/50quick--bound04acf7f0ae3cccContent-Type: application/octet-streamContent-Range: bytes 41-44/50lazy--bound04acf7f0ae3ccc--

保存期間ECS Swift ヘッドは、オブジェクトの削除または変更を一定期間防止するための保存期間をサポートします。これは ECS拡張機能であり、標準 Swift API では使用できません。保存期間は次のように設定します。

OpenStack Swift


オブジェクトの保存期間オブジェクトに保存期間を格納します。保存期間は、x-emc-retention-period ヘッダーを使用してオブジェクトに設定します。

オブジェクトの保存ポリシーオブジェクトに保存ポリシーを設定することができ、ポリシーに関連づけられた期間をネームスペースに設定することができます。これにより、ポリシーを使用してオブジェクトのグループの保存期間を同じ値に設定でき、ポリシーを変更すればすべてのオブジェクトを変更することができます。ポリシーの使用により、オブジェクトに保存期間を適用するよりもはるかに高い柔軟性が得られます。さらに、1 つのネームスペースに複数の保存ポリシーを設定できるため、オブジェクトのグループごとに異なる保存期間を設定できます。保存ポリシーは、オブジェクト上の x-emc-retention-policy ヘッダーを使用してオブジェクトに適用されます。ポリシー保存期間は、ECS Management REST API を使用して（または ECS Portal から）設定する必要があります。

バケットの保存期間バケットに対して格納されている保存期間により、すべてのオブジェクトに保存期間が設定されます。より長期にわたる保存が必要な場合は、オブジェクトレベル保存期間またはポリシーを使用して、オブジェクト固有の設定を行います。保存期間は、x-emc-retention-period ヘッダーを使用してバケットに設定します。

オブジェクトの変更および削除の際に、オブジェクトに直接設定するかオブジェクト保存ポリシーを使用して、バケット保存期間とオブジェクト保存期間のいずれが長いのかにより、この操作を実行できるかどうかが判別されます。

ファイルシステム対応Swiftバケットは、FS（ファイルシステム）で使用できるようにすることもできます。Swift プロトコルを使用して書き込んだファイルを、NFSや HDFSなどのファイルプロトコルを使用して読み取ることができます。

FS アクセスの有効化Swift プロトコルを使用してバケットを作成する場合に、x-emc-file-system-access-enabled ヘッダーを使用すれば、ファイルシステムアクセスが可能になります。ECS Portal（ECSManagement REST API を使用して）からバケットを作成する場合も、ファイルシステムアクセスを有効にできます。

FS サポートの制限事項次の制限が適用されます。l バケットが FS対応になっている場合は、保存期間を使用することはできません。

FSのクロスヘッドサポートクロスヘッドサポートとは、あるプロトコルで書いたオブジェクトに、別の ECS サポートプロトコルを使用してアクセスすることです。Swift ヘッドを使用して書き込まれたオブジェクトを、NFS およびHDFS ファイルシステムプロトコルを使用して読み取り/書き込むことができます。クロスヘッドサポートで重要なことは、オブジェクト/ファイルの権限をプロトコル間でどのように変換するかです。ファイルシステムアクセスの場合は、オブジェクトおよびファイルプロトコル間でのユーザーとグループの概念をどのように変換するかです。ファイルシステムによるクロスヘッドサポートの詳細については、ECS製品ドキュメントページ内の使用可能な「ECS管理ガイド」をご覧ください。

OpenStack Swift

ファイルシステム対応 63


S3 と Swiftの相互運用性S3 と Swift のプロトコルは相互運用性を持つため、S3 アプリケーションは Swiftバケット内のオブジェクトにアクセスでき、Swift アプリケーションは S3バケット内のオブジェクトにアクセスできます。Swift と S3 の相互運用性の詳細については、S3 と Swift の相互運用性を参照してください。

S3 と Swift の相互運用性は、バケットポリシーの使用と互換性がありません。バケットポリシーは、S3 ヘッドを使用するアクセスのみに適用され、Swift API を使用してバケットにアクセスする際には適用されません。

OpenStack Swiftの認証ECSは、複数バージョンの OpenStack Swift認証プロトコルをサポートしています。v1

認証は ECS Swift サービスを使用して行われ、オブジェクトユーザーは認証トークンを取得して、ECS Swift サービスの 2回目以降の API コールを行います。「OpenStackバージョン1.0認証（65 ページ）」を参照してください。

v2

認証は ECS Swift サービスを使用して行われ、オブジェクトユーザーはテナント（プロジェクトと同等）に関連づけられている Scoped トークンを取得して、ECS Swift サービスの 2回目以降の API コールを行います。OpenStackバージョン 2.0認証（67 ページ）を参照

v3

ECSは、Keystone プロジェクトを適用範囲とするトークンを示す Keystone V3 ユーザーを検証します。「ECS Keystone V3統合を使用した認証（69 ページ）」を参照してください。

v1 および v2 プロトコルでは、OpenStack Swift プロトコルを使用した ECS オブジェクトストアへのアクセスには、ECS オブジェクトユーザーアカウントと Swiftパスワードが必要です。v3 では、Keystone V3 サービスを使用して、ECS の外部でユーザーが作成され、プロジェクトおよびロールに割り当てられます。ECSは認証を行いませんが、Keystone V3 サービスにより認証トークンを検証します。ECS オブジェクトユーザーへの Swift認証情報の割り当てについては、「ECS ポータルでの Swiftユーザーの作成（64 ページ）」を参照してください。

ECS ポータルでの Swift ユーザーの作成ECS オブジェクトユーザーに対して、OpenStack Swift プロトコルを使用して ECS オブジェクトストアにアクセスするための認証情報を指定することができます。はじめにECS システム管理者である必要があります。

ECS オブジェクトユーザーの追加に関する詳細情報については、ECS製品ドキュメントページ内の使用可能な「ECS管理ガイド」を参照してください。

OpenStack Swift



手順1. ECS Portal で、［Manage］ > ［Users］を選択します。

［User Management］ページが表示されます。

2. ［User Management］ページで、［New Object User］を選択するか、またはユーザーテーブルに一覧表示されているユーザーの［Edit］アクションを選択して既存ユーザーへのSwiftパスワードを追加します。

新規ユーザーを作成する場合は、ユーザー名を入力して、ユーザーが所属するネームスペースを選択します。

3. Swift の領域の［Groups］フィールドに、ユーザーが所属するグループを入力します。

次の図では、Swift領域をハイライト表示しています。

admin グループを指定した場合、ユーザーは自動的にすべてのコンテナ操作を実行できるようになります。別のグループを指定した場合は、コンテナーに関する権限をそのグループに指定する必要があります。コンテナー認証に関する詳細については、「コンテナーに対する認証（72 ページ）」を参照してください。

4. Swift ユーザーのパスワードを入力します。5. ［Set Password & Groups］を選択します。

OpenStackバージョン 1.0認証認証プロトコルの V1 を使用して ECS OpenStack Swift サービスで認証することができます。手順

1. ECS オブジェクトユーザーの UID とパスワードを取得します。

これは ECS ポータル（「ECS ポータルでの Swift ユーザーの作成（64 ページ）」を参照）から行うこともできますが、次の ECSREST API をコールしてパスワードを作成することもできます。

OpenStack Swift

OpenStackバージョン 1.0認証 65

リクエスト：

PUT /object/user-password/[email protected] <user_password_create> <password>myPassword</password> <namespace>EMC_NAMESPACE</namespace> </user_password_create>

レスポンス：

HTTP 200

2. 次に示す OpenStack認証 REST API を呼び出します。HTTP の場合はポート 9024、HTTPS の場合は 9025 を使います。

リクエスト：

GET /auth/v1.0 X-Auth-User: [email protected] X-Auth-Key: myPassword

レスポンス：

HTTP/1.1 204 No Content Date: Mon, 12 Nov 2010 15:32:21 GMT Server: Apache

X-Storage-Url: https://{hostname}/v1/account X-Auth-Token: ECS_e6384f8ffcd849fd95d986a0492ea9a6 Content-Length: 0

結果UID とパスワードが ECS により検証されると、ストレージ URL とトークンがレスポンスヘッダーで返されます。以降のリクエストは、このトークンを含むことで認証されます。ストレージ URLは、ホスト名とリソースのアドレスを示します。次の X-Storage-Url ヘッダーを提示することで、コンテナーやオブジェクトにアクセスできます。

X-Storage-Url: https://{hostname}/v1/{account}/{container}/{object}

生成されたトークンの有効期限は、作成後 24時間です。24時間以内に同じ UID とパスワードを使って認証リクエストを繰り返すと、OpenStackは同じトークンを返します。24時間の有効期間が過ぎると、OpenStackは新しいトークンを返します。

次のシンプルな認証の例では、最初の REST コールは X-Auth-Token を返します。2番目のREST コールは X-Auth-Token を使用してアカウントに GET リクエストを行います。

$ curl -i -H "X-Storage-User: [email protected]" -H "X-Storage-Pass: 1fO9X3xyrVhfcokqy3U1UyTY029gha5T+k+vjLqS"

OpenStack Swift


http://ecs.yourco.com:9024/auth/v1.0

HTTP/1.1 204 No Content X-Storage-Url: http://ecs.yourco.com:9024/v1/s3 X-Auth-Token: ECS_8cf4a4e943f94711aad1c91a08e98435 Server: Jetty(7.6.4.v20120524)

$ curl -v -X GET -s -H "X-Auth-Token: 8cf4a4e943f94711aad1c91a08e98435" http://ecs.yourco.com:9024/v1/s3

* About to connect() to ecs.yourco.com port 9024 (#0) * Trying 203.0.113.10... * Adding handle: conn: 0x7f9218808c00 * Adding handle: send: 0 * Adding handle: recv: 0 * Curl_addHandleToPipeline: length: 1 * - Conn 0 (0x7f9218808c00) send_pipe: 1, recv_pipe: 0 * Connected to ecs.yourco.com (203.0.113.10) port 9024 (#0)

> GET /v1/s3 HTTP/1.1 > User-Agent: curl/7.31.0 > Host: ecs.yourco.com:9024 > Accept: */* > X-Auth-Token: 8cf4a4e943f94711aad1c91a08e98435 > < HTTP/1.1 204 No Content < Date: Mon, 16 Sep 2013 19:31:45 GMT < Content-Type: text/plain * Server Jetty(7.6.4.v20120524) is not blacklisted < Server: Jetty(7.6.4.v20120524) <

* Connection #0 to host ecs.yourco.com left intact

OpenStackバージョン 2.0認証ECS には、OpenStackバージョン 2（Keystone）認証の限定サポートが含まれます。

はじめに

ECS には、V2認証を使用してユーザー認証を行う Swift アプリケーションを実行するOpenStack Swift V2 ID サービスが実装されています。ユーザーは、Swift プロトコルで ECS オブジェクトストアにアクセスするために必要な、OpenStack Swift認証情報が割り当てられているECS オブジェクトユーザーである必要があります。Swift API コールに使用できるのは、ECS ネームスペース（Swift プロジェクトと同等）を適用範囲とするトークンのみです。Unscoped トークンを取得し、ID サービスにアクセスしてテナント ID を取得します。そして、テナントとサービスエンドポイントを適用範囲とするトークンを取得します。Scoped トークンとサービスエンドポイントは、V1認証について説明している前述のセクションに記載されているように、ECS による認証に使用できます。次に挙げる 2 つの記事は、重要な背景情報を提供しています。

OpenStack Swift

OpenStackバージョン 2.0認証 67

l OpenStack Keystone ワークフローとトークンのスコープ設定l 管理者 API の認証

手順1. ECS から Unscoped トークンを取得するには、/v2.0/tokens API を使用し、ECS

Swift サービスにユーザー名とパスワードを提供します。

curl -v -X POST -H 'ACCEPT: application/json' -H "Content-Type: application/json" -d '{"auth": {"passwordCredentials" : {"username" : "swift_user", "password" : "123"}}}' http://203.0.113.10:9024/v2.0/tokens

レスポンスは次のように見えます。Unscoped トークンの最初は「id」で始まり、ECS によって生成されたトークンには頭に「ecs_」というプレフィックスが付きます。

{"access": {"token": {"id":"ecs_d668b72a011c4edf960324ab2e87438b","expires":"1376633127950"l},"user": {"name": "sysadmin", "roles":[ ], "role_links":[ ] },"serviceCatalog":[ ] }} , }

2. Unscoped トークンと関連づけられたテナント情報を取得します。

curl -v http://203.0.113.10:9024/v2.0/tenants -H 'X-Auth-Token: d668b72a011c4edf960324ab2e87438b'

レスポンスは次のように見えます。

{"tenants_links":[], "tenants":[{"description":"s3","enabled":true, "name": "s3"}]}

3. Scoped トークンとストレージ URL を一緒に取得します。

curl -v -X POST -H 'ACCEPT: application/json' -H "Content-Type: application/json" -d '{"auth": {"tenantName" : "s3", "token":{"id" : ecs_d668b72a011c4edf960324ab2e87438b"}}}' http://203.0.113.10:9024/v2.0/tokens

レスポンスの例は次のようになります。Scoped トークンは ID から始まります。

{"access":{"token":{"id":"ecs_baf0709e30ed4b138c5db6767ba76a4e","expires":"1376633255485","tenant":{"description":"s3","enabled":true,"name":"s3"}},

OpenStack Swift


http://bodenr.blogspot.com/2014/03/openstack-keystone-workflow-token.html

http://docs.openstack.org/api/openstack-identity-service/2.0/content/POST_authenticate_v2.0_tokens_.html

"user":{"name":"swift_admin","roles":[{"name":"member"},{"name":"admin"}],"role_links":[]}, "serviceCatalog":[{"type":"object-store", "name":"Swift","endpoints_links":[],"endpoint":[{"internalURL": "http://203.0.113.10:9024/v1/s3","publicURL":"http://203.0.113.10:9024/v1/s3"}]}]}}

4. Scoped トークンとサービスエンドポイント URL を使って、Swift認証を行います。この手順は OpenStack の V1 と同じです。

curl -v -H "X-Auth-Token: baf0709e30ed4b138c5db6767ba76a4e" http://203.0.113.10:9024/v1/s3/{container}/{object}

ECS Keystone V3統合を使用した認証ECSは Keystone V3 をサポートし、OpenStack Swift ユーザーが提供する認証トークンを検証します。Keystone V3 では、ECS Keystone V3 サービスを使用して、ECS外部にユーザーが作成されます。ECSは認証を行いませんが、Keystone V3 サービスにより認証トークンを検証します。

Keystone ドメインでは、プロジェクトと ECS のテナント/ネームスペースは同等とみなすことができます。ECS ネームスペースはテナントとみなすことができます。

Keystone V3 ではユーザーにロールが割り当てられ、ロールのメンバーシップに応じて実行可能なアクションが決まります。ただし ECS の Keystone V3 サポートは、Keystone ポリシーをサポートしません。そのため、コンテナ操作を実行するには、ユーザーは admin グループ（ロール）に属している必要があります。認証トークンはプロジェクトを適用範囲にする必要があります。ECS では Unscoped トークンは使用できません。プロジェクト（ECS のテナントと同等）およびサービスのリスト取得などの Unscopedトークン関連の操作は、ユーザーが Keystone サービスに対して直接実行する必要があります。ユーザーは Keystone サービスから ECS が検証可能な Scoped トークンを取得し、有効であればECS による認証に使用します。ECS の検証をオンにするには、ECS に認証プロバイダーを構成する必要があります。ユーザーからプロジェクト Scoped トークンを受信すると、ECSは Keystone V3認証プロバイダーに対してそれを検証します。さらに、Keystone プロジェクトに対応する ECS ネームスペースを作成する必要があります。詳細については、「OpenStack Swift と ECS の統合の構成（70 ページ）」を参照してください。

許可チェックECSは、Keystone トークンによって提供される情報を使用して、承認決定を行います。許可チェックは、次の手順で行われます。1. ECSは、トークンがスコープされているプロジェクトが URI のプロジェクトに一致するかどうかを確

認します。2. 操作がオブジェクト操作の場合、ECSはオブジェクトに関連づけられている ACL を評価して、

操作を許可するかどうかを判断します。3. 操作がコンテナ操作の場合、ECS ではリクエストされた操作を評価します。ユーザーが admin

ロールを持つ場合、ユーザーは、一覧表示、作成、更新、読み取り、および削除のコンテナ操作を実行できます。

OpenStack Swift

ECS Keystone V3統合を使用した認証 69

ドメインKeystone V3 では、すべてのユーザーがドメインに属し、複数のプロジェクトが 1 つのドメインに属することができます。ユーザーのプロジェクトへのアクセスは、ロールに応じます。ユーザーがドメインに割り当てられていない場合、ドメインは「デフォルト」です。Swift Keystone V3 ユーザーを使用して作成されたオブジェクトとコンテナーは、<ユーザー>@<ドメイン.com>に属します。ユーザーがドメインに割り当てられていない場合、コンテナーやオブジェクトに割り当てられるユーザー名は<ユーザー>@default です。

OpenStack Swift と ECS の統合の構成Keystone V3 を使用する OpenStack Swift サービスを ECS で認証できることを確認するには、Swift と ECS の構成に矛盾がないことを確認する必要があります。

はじめに次の動作条件が適用されます。l Swift サービス管理者アカウントの認証情報があることを確認します。ECS で Keystone サー

ビスを使用して認証できるようにするには、これらの認証情報が必要になります。l ECS にアクセスする Swift ユーザーが所属している Keystone プロジェクトの ID を入手してい

ることを確認します。l ECS システム管理者アカウントの認証情報があることを確認します。手順

1. ECS エンドポイントが Swift サービスカタログに追加され、正しくフォーマットされていることを確認します。エンドポイントが、「デフォルト」の Keystone ドメイン内に存在することを確認する必要があります。

2. システム管理者として、ECS Portal にログインします。3. Keystone V3 サービスエンドポイントを指定する認証プロバイダーと、トークンの検証に使

用できる管理者アカウントの認証情報を作成します。Keystone認証プロバイダーの追加（71 ページ）を参照してください。

4. 認証するユーザーが属している Keystone プロジェクト/アカウントと ID が同じ ECS ネームスペースを作成します。Keystone プロジェクト ID を取得します。

a. ECS Portal で、［Manage］ > ［Namespace］ > ［New Namespace］を選択します。

b. ネームスペースの名前を入力します。これは、Swift プロジェクトの名前である必要があります。

c.［User Admin］としてネームスペース管理者アカウントを入力します。これは、以前に作成した管理ユーザーの名前である必要があります。

d. 必要なその他のネームスペース設定を構成します。ネームスペース設定と ECS でのユーザーの作成の詳細については、ECS製品ドキュメントページ内の使用可能な「ECS管理ガイド」を参照してください。

結果ネームスペースを作成すると、対応する Keystone プロジェクトに属しているユーザーと、そのプロジェクトにスコープされているトークンを所有しているユーザーは、ECS を介して（Keystone認証プロバ

OpenStack Swift




イダーと通信している ECS を介して）認証を行い、Swift API を使用して ECS オブジェクトストアにアクセスすることができます。

Keystone認証プロバイダーの追加OpenStack Swift ユーザーを認証する Keystone認証プロバイダーを追加することができます。

はじめにl この操作には ECS のシステム管理者のロールが必要です。l Keystone の認証プロバイダーを 1 つだけ追加できます。l Keystone認証プロバイダーの設定（72 ページ）に記載されている認証プロバイダー情報を

入手します。手順

1. ECS ポータルで、［Manage］ > ［Authentication］を選択します。2. ［Authentication Provider Management］ページで、［New Authentication

Provider］をクリックします。3. ［New Authentication Provider］ページの［Type］フィールドで、［Keystone V3］

を選択します。必要なフィールドが表示されます。

4. ［Name］、［Description］、［Server URL］、［Keystone Administrator］、［AdminPassword］フィールドに値を入力します。これらのフィールドの詳細については、 Keystone認証プロバイダーの設定（72 ページ）を参照してください。

5. ［Save］をクリックします。

OpenStack Swift

ECS Keystone V3統合を使用した認証 71

Keystone認証プロバイダーの設定Keystone認証プロバイダーを追加または編集するときに、認証プロバイダーの情報を指定する必要があります。

表 13 Keystone認証プロバイダーの設定

フィールド説明

Name Keystone認証プロバイダーの名前。この名前は、ECS でプロバイダーを特定するために使用されます。

Description 認証プロバイダーのフリーテキストによる説明。

Type Keystone V3.

Server URL Swift ユーザーを確認するために ECS が接続する、Keystone システムの URl です。

Keystone Administrator Keystone システムの管理者のユーザー名です。このユーザー名を使用して、ECS からKeystone システムに接続します。

Administrator Password 指定した Keystone管理者のパスワード。

コンテナーに対する認証OpenStack Swift による認証はコンテナーだけを対象としています。Swiftは現在、2種類の認証をサポートしています。l リファラル形式の認証l グループ形式の認証ECSは、グループベースの認証のみサポートします。管理者ユーザーは、アカウント内のすべての操作を行えます。管理者ではないユーザーは、コンテナの X-Container-Read および X-Container-Write アクセス制御リストに基づき、コンテナごとにのみ操作を行えます。管理者ではないユーザーには次の操作が許可されています。

管理者が読み取りアクセスをコンテナーに割り当て「admin」ユーザーは、次のようにして、グループへの読み取り許可を割り当てることができます。

curl -X PUT -v -H 'X-Container-Read: {GROUP LIST}' -H 'X-Auth-Token: {TOKEN}' http://127.0.0.1:8080/v1/{account}/{container1}"

このコマンドは、GROUP LIST に属するユーザーに、コンテナー 1 に対する読み取りアクセス権を持つことを許可します。たとえば、「Member」グループに読み取り許可を割り当てるには次のようにします。

curl –X PUT -v –H 'X-Container-Read: Member' –H 'X-Auth-Token: {ADMIN_TOKEN}' http://127.0.0.1:8080/v1/{account}/{container1}

読み取り権限が与えられると、ターゲットグループに属するユーザーは次の操作を実行できます。l HEAD container：コンテナーメタデータの取得。テナント管理者権限を持つグループにユーザ

ーが割り当てられている場合のみ許可されます。

OpenStack Swift


l GET container：コンテナ内のオブジェクトを一覧にします。l GET objects with container：コンテナ内のオブジェクトの内容を読み取ります。

管理者が書き込みアクセスをコンテナーに割り当て「admin」ユーザーは、次のようにして、グループへの読み取り許可を割り当てることができます。

curl -XPUT -v -H 'X-Container-Write: {GROUP LIST}' -H 'X-Auth-Token: {TOKEN}' http://127.0.0.1:8080/v1/{account}/{container1}"

このコマンドは、GROUP LIST に属するユーザーに、コンテナー 1 に対する書き込みアクセス権を持つことを許可します。たとえば、「Member」グループに書き込み許可を割り当てるには次のようにします。

curl –X PUT -v –H 'X-Container-Write: Member' –H 'X-Auth-Token: {ADMIN_TOKEN}' http://127.0.0.1:8080/v1/{account}/{container1}

GROUP LIST グループのユーザーに、書き込み許可が与えられます。書き込みアクセス権が与えられると、ターゲットグループに属するユーザーは次の操作を実行できます。l POST container：メタデータの設定。「X-Container-Meta」のプレフィックスで始めます。l PUT objects within container：コンテナ内のオブジェクトを書き込み／上書きします。認証に関する詳細については、次を参照してください。「Container Operations」。

OpenStack Swift

コンテナーに対する認証 73

http://ceph.com/docs/master/radosgw/swift/containerops/

OpenStack Swift


第 3部

EMC Atmos

第 3章, "EMC Atmos"

EMC Atmos 75

EMC Atmos


第 3章

EMC Atmos

l ECS の EMC Atmos API サポート..........................................................................78l サポート対象の EMC Atmos REST API コール........................................................ 78l サポート対象外の EMC Atmos REST API コール.................................................... 80l EMC Atmos REST API コールのサブテナントサポート............................................... 81l API の拡張機能....................................................................................................81

EMC Atmos 77

ECSの EMC Atmos API サポートECSは、EMC Atmos API のサブセットをサポートしています。ここでは、サポート対象機能と ECS拡張機能の詳細について説明します。Atmos オブジェクトサービスは、次のポートで使用できます。


HTTP 9022

HTTPS 9023

サポート対象機能の詳細については、ECS サポートサイトの「Atmos Programmer’s Guide」を参照してください。l Atmos Programmer's Guide

すべてのサポート対象機能にワイヤー形式の互換性があります。そのため、「Atmos Programmer'sGuide」に記載されている機能は、ECS が提供する API機能にも当てはまります。「Atmos Programmer's Guide」はまた、Atmos API による認証の情報や、多くのサポート機能の包括的な例を提供しています。

サポート対象の EMC Atmos REST API コールECSは、EMC Atmos API のサブセットをサポートしています。

サポート対象の Atmos REST API コールには次のものがあります。オブジェクトとネームスペースの両方についてインターフェイスのコールが示されています。

表 14 サポート対象の Atmos REST API コール

方法パス説明

サービス操作

GET /rest/service システムに関する情報を取得

オブジェクト操作

POST /rest/objects/rest/namespace/<path>

オブジェクトの作成

（以下の注を参照）

DELETE /rest/objects/<ObjectID/rest/namespace/<path>

オブジェクトの削除

PUT /rest/objects/<ObjectID/rest/namespace/<path>

オブジェクトの更新

（以下の注を参照）

GET /rest/objects/<ObjectID/rest/namespace/<path>

オブジェクト（またはディレクトリリスト）の読み取り

POST /rest/namespace/<path>?rename オブジェクトの名称変更

メタデータ操作

EMC Atmos


http://support.emc.com

表 14 サポート対象の Atmos REST API コール（続き）

方法パス説明

GET /rest/objects/<ObjectID>?metadata/user/rest/namespace/<path>?metadata/user

オブジェクトのユーザーメタデータを取得

POST /rest/objects/<ObjectID>?metadata/user/rest/namespace/<path>?metadata/user

ユーザーメタデータの設定

DELETE /rest/objects/<objectID>?metadata/user/rest/namespace/<path>?metadata/user

ユーザーメタデータの削除

GET /rest/objects/<ObjectID>?metadata/system/rest/namespace/<path>?metadata/system

オブジェクトのシステムメタデータを取得

GET /rest/objects/<ObjectID>?acl/rest/namespace/<path>?acl

ACL の取得

POST /rest/objects/<ObjectID>?acl/rest/namespace/<path>?acl

ACL の設定

GET /rest/objects/<ObjectID>?metadata/tags/rest/namespace/<path>?metadata/tags

オブジェクトのメタデータタグを取得

GET /rest/objects/<ObjectID>?info/rest/namespace/<path>?info

オブジェクト情報の取得

Head /rest/objects/<ObjectID/rest/namespace/<path>

すべてのオブジェクトメタデータを取得

オブジェクトスペース操作

GET /rest/objects オブジェクトの一覧

GET /rest/objects?listabletags 一覧可能なタグを取得

匿名アクセス

GET /rest/objects/<ObjectId>?uid=<uid>&expires=<exp>&signature=<sig>/rest/namespace/<path>?uid=<uid>&expires=<exp>&signature=<sig>

共有可能 URL

l x-emc-wschecksum ヘッダーは ECS でサポートされます。l HTML フォームのアップロードはサポートされません。l GET /rest/objects では、x-emc-accept の他のレスポンスタイプはサポートされませ

ん。たとえば text/plainはサポートされません。l 読み取り、書き込み、削除の ACLは、ECS でも Atmos と同様に動作します。l POST /rest/objects では、従来の（44文字の）オブジェクト ID を有効化するために x-

emc-object-id ヘッダーがサポートされています。

EMC Atmos

サポート対象の EMC Atmos REST API コール 79

Atmosの一覧可能タグ一覧可能タグとは、オブジェクトの一覧表示またはフィルタリングに使用される特別なユーザー定義タグです。たとえばアプリケーションは、エンドユーザーが画像（オブジェクト）のグループに「Vacation2016」のようなタグをタグ付けできるようにすることができます。後でこの一覧可能タグをタグ付けされたオブジェクトのみを一覧表示することにより、アプリケーションは「Vacation2016」クエリーに応答することができます。ECS で Atmos プロトコルを使用するとき、ユーザーは別のユーザーの一覧可能タグを削除したり変更したりすることはできません。いくつかの条件下では、ネイティブ Atmos でこの機能が動作します。一覧可能タグは ECS でインデックスされるため、タグ付けされたオブジェクト取得のパフォーマンスと拡張性が向上します。ECS では、EMC_TAGS メタデータタグが、リスト可能タグの保持に使用されます。このタグ名を、ユーザー定義メタデータタグでは使用しないでください。

オブジェクト IDの長さECS での Atmos API のサポートでは、オブジェクト ID の長さが 44文字から 101文字までに拡張されます。そのため、アプリケーションを Atmos から ECS に移行する場合は、オブジェクト ID の長さが異なることに留意する必要が生じます。従来の 44文字の長さの ID を使用してオブジェクトを作成するには、x-emc-object-id ヘッダーを使用できます。これにより、オブジェクトを Atmos に移行できます。

サポート対象外の EMC Atmos REST API コール次の Atmos REST API コールはサポートされません。

表 15 サポート対象外の Atmos REST API コール

方法パス説明

オブジェクトのバージョン設定

POST /rest/objects/<objectID>?versions

オブジェクトのバージョン作成

DELETE /rest/objects/<objectID>?versions

オブジェクトバージョンの削除

GET /rest/objects/<objectID>?versions

オブジェクトバージョンの一覧

PUT /rest/objects/<objectID>?versions

オブジェクトバージョンのリストア

匿名アクセス

POST /rest/accesstokens アクセストークンの作成

GET /rest/accesstokens/<token_id>?info

アクセストークンの詳細を取得

DELETE /rest/accesstokens/<token_id>

アクセストークンの削除

GET /rest/accesstokens アクセストークンの一覧

EMC Atmos


表 15 サポート対象外の Atmos REST API コール（続き）

方法パス説明

GET /rest/accesstokens/<token_id>

匿名でコンテンツをダウンロード

EMC Atmos REST API コールのサブテナントサポートECS には、Atmos アプリケーションに ECS サブテナントサポートを追加するための 2 つのネイティブの REST API コールが含まれます。

コールには次のものがあります。

API コール例

サブテナント作成 PUT Http url: /rest/subtenant

必要なヘッダー：x-emc-uid（たとえば、x-emc-

[email protected]）および x-emc-

signature。

サブテナント IDは、レスポンスのヘッダーの「subtenantID」に設定されます。

サブテナント削除 DELETE Http url: /rest/subtenants/{subtenantID}

必要なヘッダー：x-emc-uid（たとえば、x-emc-

[email protected]）および x-emc-

signature。

サブテナント IDは、移行後に ECS に保持されます。ヘッダーは、x-emc-subtenant-id:{original_subt_id}です。

APIの拡張機能ECSは、さまざまな Atmos API の拡張機能をサポートします。

拡張機能とサポート APIは以下の一覧表示のとおりです。l オブジェクトにデータを追加（81 ページ）l Atmos オブジェクトの保存と、保存の有効期限に対する ECS のサポート（82 ページ）

オブジェクトにデータを追加EMC Atmos プロトコルに対する ECS拡張機能を使用してオブジェクトの末尾にデータを追加できます。オブジェクトに追加したいものの、正確なバイトオフセットの決定が不十分または不便な場合があるかもしれません。このシナリオでは、ECS がオフセットを指定せずに（正しいオフセットは応答で返されます）、オブジェクトにデータをアトミックに追加する機能を提供します。

EMC Atmos

EMC Atmos REST API コールのサブテナントサポート 81

オブジェクトにデータを追加するために特別な値 bytes=-1-の範囲ヘッダーを使用します。この方法で、既存のオブジェクトサイズを知らなくてもオブジェクトを拡張できます。形式は次のとおりです。Range: bytes=-1-サンプルのリクエストで、bytes=-1-の範囲の値を使用して既存のオブジェクトの末尾に追加する方法を次の例に示します。ここでは、値 and catはリクエストで送信されています。

PUT /rest/namespace/myObject HTTP/1.1Content-Length: 8Range: bytes=-1-ACCEPT: application/json,application/xml,text/html,application/octet-streamDate: Mon, 17 Jun 2013 20:46:01 -0000x-emc-date: Mon, 17 Jun 2013 20:46:01 -0000x-emc-namespace: emcx-emc-uid: fa4e31a68d3e4929bec2f964d4cac3de/[email protected]: ZpW9KjRb5+YFdSzZjwufZUqkExc=Content-Type: application/octet-streamAccept-Encoding: gzip, deflate, compress

and cat

HTTP/1.1 200 OKx-emc-mtime: 1431626712933Date: Mon, 17 Jun 2013 20:46:01 GMTx-emc-policy: defaultx-emc-utf8: truex-emc-request-id: 0af9ed8d:14cc314a9bc:112f6:9x-emc-delta: 8x-emc-append-offset: 24Content-Length: 0Server: Jetty(7.6.4.v20120524)

データが追加されたオフセット位置は、x-emc-append-offset ヘッダーで返されます。オブジェクトを取得したときに and cat が末尾に追加されて、次の完全な値が表示されます。The quick green fox jumps over the lazy dog and cat.

Atmos オブジェクトの保存と、保存の有効期限に対する ECS のサポートECS では、Atmos オブジェクト上への保存期間と、保存の有効期限の設定をサポートしています。

保存期間保存期間では、オブジェクトが編集または削除できるようになる前の ECS によって保持される期間を定義します。保存期間中はオブジェクトを編集することもシステムから削除することもできず、保存期間の有効期限切れまでこの状態が続きます。ECS内で Atmos オブジェクトを作成するときは、オブジェクトの保存を次のように扱うことができます。l オブジェクトに直接定義l オブジェクトが作成される ECSバケットに設定されている保存期間を継承します。保存ポリシーが ECS ネームスペースに設定されている場合は、オブジェクトにも保存期間を直接設定する必要があります。ネームスペース内の保存ポリシーはオブジェクトによって継承されません。

EMC Atmos


表 16 Atmos の保存期間

保存期間の設定先

使用する手法注

オブジェクト次を通じた Atmos API

l 秒単位でのヘッダーの保存期間：'x-emc-retention-period:60'

l UMD（ユーザーメタデータ）、終了日：'x-emc-meta:user.maui.retentionEnable=true,user.maui.retentionEnd=2016-10-21:10:00Z'

l ヘッダーと UMD の両方：'x-emc-meta:user.maui.retentionEnable =true,user.maui.retentionEnd=2016-10-21T18:14:30Z' -header 'x-emc-retention-period:60'

l 保存設定はオブジェクトの作成時またはオブジェクトの設定の更新中にオブジェクトに設定できます。

l ヘッダーの保存期間は秒単位で定義されます。

l UMD保存設定は終了日によって定義されます。

l ヘッダーと UMD の両方から保存期間が設定されている場合は、まず UMD属性が確認され、ヘッダーの設定よりも優先されます。

l 保存期間がオブジェクトに設定された後は、有効期限切れになるまで保存期間を変更できません。

l x-emc ヘッダーを使用して保存期間を設定する場合n -1 を指定すると無期限の保存期間が設定され、定義されている有効期限があればこれも無効化されます。

n -2 を指定すると、オブジェクトに設定された保存期間は無効化されます。

ECS のネームスペース

ECS Portal の［NewNamespace］ページまたは［Edit Namespace］ページ。

l オブジェクトの保存期間を設定する場合に、保存ポリシーがオブジェクトユーザーのネームスペースに定義されているとしても、前述のように、オブジェクトに直接保存期間を定義する必要があります。

l ECS のネームスペースに保存ポリシーが設定されているか、このネームスペース内のバケットに保存期間が設定されている、またはこの両方の場合に、バケット内にオブジェクトを作成するとき、ECS では、ネームスペースまたはバケットのいずれかに設定された最長の保存期間までネームスペース、バケット、オブジェクトを保持します。

l オブジェクトヘッダーを通じてオブジェクト自体に保存期間が設定されている場合、ECS では、ネームスペース、バケット、またはオブジェクトに設定されている最長期間までオブジェクトを保持します。

l Atmos API を介して保存期間の終了日がオブジェクトに定義されていた場合、ECS では、オブジェクトに設定されている Atmos API

の保存終了日付を使用し、ネームスペースの

ECS REST APIPOST /object/namespaces/namespace/{namespace}/retention

ECSバケット ECS Portal の［NewBucket］ページまたは［EditBucket］ページから。

ECS REST APIPUT /object/bucket/{bucketName}/retention

EMC Atmos

Atmos オブジェクトの保存と、保存の有効期限に対する ECS のサポート 83

表 16 Atmos の保存期間（続き）

保存期間の設定先

使用する手法注

保存ポリシーおよびバケットの保存期間を無視して、オブジェクトを作成します。

l Atmos オブジェクトを含むサブテナント（バケット）に保存ポリシーを適用する場合、この保存ポリシーは、保存ポリシーが設定された後にサブテナントに作成されたオブジェクトと、保存ポリシーが設定される前にサブテナントに作成されたオブジェクトの両方に適用されることになります。

ネームスペース保存ポリシーとバケット保存期間の詳細については、ECS製品ドキュメントページ内の使用可能な「ECS管理ガイド」を参照してください。

例：保存設定を含めてオブジェクトを作成するリクエストおよびレスポンス：

POST /rest/namespace/file1 HTTP/1.1User-Agent: curl/7.37.0Host: 10.247.179.228:9022Accept: */*x-emc-date:Thu, 16 Feb 2017 19:28:13 GMTx-emc-meta:user.maui.retentionEnable=true,user.maui.retentionEnd=2017-06-30T06%3A38%3A44Zx-emc-uid:f082110e13f249649340e172fb7b4956/u1x-emc-utf8:trueContent-Type:plain/textx-emc-signature:2Gz51WT+jQdMjlobDV0mz7obsXM=Content-Length: 774

Response

HTTP/1.1 201 CreatedDate: Thu, 16 Feb 2017 19:28:17 GMTx-emc-policy: defaultx-emc-utf8: truex-emc-request-id: 0af7b3e4:15a4849d95e:37c:0x-emc-delta: 774Location: /rest/objects/0a40bd045f7373d367639f095d1db0d15acadb82d5d2cd108e2142f4be04635c-59bdb9b6-20c0-4f55-bc91-9db728a58854x-emc-mtime: 1487273295379Content-Length: 0Server: ViPR/1.0

例：オブジェクトのメタデータを取得するリクエストおよびレスポンス：

curl --head -H "x-emc-date:Mon, 30 Jan 2017 16:56:35 GMT" -H "x-emc-uid:7a2593be81374744adbf8e3983e7bd84/u1" -H "x-emc-signature:CQgfoiIQ/DCif7TafcIskWyVpME=" http://10.247.179.228:9022/rest/objects/d1bced53f2ebbcbc51af1d84747bd198d123d3b8585293a5bf0d32bb73c6cf4b-365f4482-c24a-4eca-b24a-070efe29bf63

EMC Atmos



Response

HTTP/1.1 200 OKDate: Mon, 30 Jan 2017 16:56:35 GMTx-emc-mtime: 1485795387838［x-emc-retention-period: 21798212］x-emc-meta: ［user.maui.retentionEnd=2017-10-10T00:00:00Z,user.maui.retentionEnable=true］,allow-inline-update=false,atime=2017-01-30T16:45:48Z,ctime=2017-01-30T16:56:27Z,ctype=plain/text,data-range=CAAQgFA=,dek=kq/W1Rg/7qbmaCcLF8pFvqlDJ8+suPTdVddBBZFwZA86muG3P0Pb7w==,dekAlgo=AESKeyWrapRFC5649,etag=0-,fs-mtime-millisec=1485795387838,itime=2017-01-30T16:45:48Z,kekId=s3.7a2593be81374744adbf8e3983e7bd843cdda755061bac6c12c06eb02800a7fee4b11ac2e03f62bb01eee02995068e56,keypoolid=s3.7a2593be81374744adbf8e3983e7bd84,keypoolname=7a2593be81374744adbf8e3983e7bd84,keyversion=0,mtime=2017-01-30T16:56:27Z,namespace=s3,nlink=1,object-name=,objectid=d1bced53f2ebbcbc51af1d84747bd198d123d3b8585293a5bf0d32bb73c6cf4b-365f4482-c24a-4eca-b24a-070efe29bf63,objname=file,parentOid=53ae036bfcfb46f5580b912222f3026835e3ef972c7e3e532ba4a5de30b1946e,parentZone=urn:storageos:VirtualDataCenterData:365f4482-c24a-4eca-b24a-070efe29bf63,policyname=default,retention=CgYIoKOZmlE=,size=0,type=regular,uid=u1,parent=apache,gid=apachex-emc-useracl: u1=FULL_CONTROLx-emc-groupacl: other=READx-emc-policy: defaultx-emc-request-id: 0af7b3e4:159f0185cf7:957:4Content-Type: plain/textContent-Length: 0Server: ViPR/1.0

例：オブジェクトの保存期間の値を更新

POST /rest/namespace/file2?metadata/user HTTP/1.1User-Agent: curl/7.37.0Host: 10.247.179.228:9022Accept: */*x-emc-date:Thu, 16 Feb 2017 19:37:15 GMTx-emc-meta:user.maui.retentionEnable=true,user.maui.retentionEnd=2017-07-30T06%3A38%3A44Zx-emc-uid:f082110e13f249649340e172fb7b4956/u1x-emc-utf8:trueContent-Type:plain/textx-emc-signature:5UPpZcCfO0vtxMTW62fa2/2SmLg=

Response

HTTP/1.1 200 OK

Date: Thu, 16 Feb 2017 19:37:16 GMTx-emc-policy: _intx-emc-utf8: truex-emc-request-id: 0af7b3e4:15a4849d95e:582:0Content-Length: 0Server: ViPR/1.0

有効期限Atmos オブジェクトの保存期間の終了日が定義されており、オブジェクトにも有効期限が設定されている場合、ECS では、有効期限に定義された日付でオブジェクトを自動的に削除します。有効期限は次のように扱われます。

EMC Atmos


l Atmos API または x-emc ヘッダーを使用してオブジェクト上に設定できます。l 有効期限は保存期間の終了日以降である必要があります。l デフォルトでは、有効期限は無効化されます。l x-emc ヘッダーを使用して保存設定と有効期限を設定する場合、値-1 を指定すると有効期

限は無効化されます。例：x-emc ヘッダーを使用した有効期限の設定：

POST /rest/namespace/file2 HTTP/1.1User-Agent: curl/7.37.0Host: 10.247.179.228:9022Accept: */*x-emc-date:Tue, 31 Jan 2017 19:38:00 GMTx-emc-expiration-period:300x-emc-uid:a2b85977fd08488b80e646ea875e990b/u1Content-Type:plain/textx-emc-signature:krhYBfKSiM3mFOT6FtRB+2/xZnw=Content-Length: 10240Expect: 100-continue

例：Atmos API を使用したリクエストとレスポンス：

POST /rest/namespace/file2 HTTP/1.1User-Agent: curl/7.37.0Host: 10.247.179.228:9022Accept: */*x-emc-date:Thu, 02 Feb 2017 02:47:32 GMTx-emc-meta:user.maui.expirationEnable=true,user.maui.expirationEnd=2017-03-30T20:20:00Zx-emc-uid:239e20dec7a54301a0b02f6090edcace/u1Content-Type:plain/textx-emc-signature:5tGEyK/9qUZCPSnQ9OPOdktN+Zo=Content-Length: 10240Expect: 100-continue

Response

HTTP/1.1 100 ContinueHTTP/1.1 201 CreatedDate: Thu, 02 Feb 2017 02:47:33 GMTx-emc-policy: defaultx-emc-request-id: 0af7b3e4:159fb81ddae:345e:0x-emc-delta: 10240Location: /rest/objects/5c3abaf60e0e207abec96baf0618c0461b7cd716898f8a12ee236aed1ec94bea-c86ee0e9-8709-4897-898e-c3d1895e1d93x-emc-mtime: 1486003652813Content-Length: 0Server ViPR/1.0 is not blacklistedServer: ViPR/1.0

例：Atmos API を使用したメタデータを更新するためのリクエストとレスポンス：

POST /rest/namespace/file?metadata/user HTTP/1.1User-Agent: curl/7.37.0Host: 10.247.179.228:9022Accept: */*x-emc-date:Thu, 02 Feb 2017 02:44:13 GMTx-emc-meta:user.maui.expirationEnable=true,user.maui.expirationEnd=2017-03-30T20:20:00Z

EMC Atmos


x-emc-uid:239e20dec7a54301a0b02f6090edcace/u1Content-Type:plain/textx-emc-signature:9pzcc/Ce4Lq3k52QKdfWLYlZ1Yc=

Response

HTTP/1.1 200 OKDate: Thu, 02 Feb 2017 02:44:14 GMTx-emc-policy: _intx-emc-request-id: 0af7b3e4:159fb81ddae:339e:0Content-Length: 0Server ViPR/1.0 is not blacklistedServer: ViPR/1.0

EMC Atmos


EMC Atmos


第 4部

CAS

第 4章, "CAS"

CAS 89

CAS


第 4章

CAS

l ECS の CAS サポートの設定..................................................................................92l コールドストレージ.................................................................................................92l コンプライアンス......................................................................................................93l ECS での CAS の保存.......................................................................................... 95l CAS アプリケーションの高度な保存：イベントベースの保存、法的証拠保全、最小/最大ガ

バナー..................................................................................................................97l ネームスペースの保存ポリシーの設定...................................................................... 103l CAS ユーザーのバケットの作成および設定.............................................................. 104l CAS オブジェクトユーザーの設定........................................................................... 105l CAS のバケット ACL の設定................................................................................. 106l CAS ユーザーをサポートする ECS管理 API............................................................108l CAS（コンテンツアドレスストレージ）SDK API サポート.......................................... 109

CAS 91

ECSの CAS サポートの設定ECS での CAS（コンテンツアドレスストレージ）のサポートについて説明します。ECS CAS により、CAS SDK ベースのクライアントアプリケーションを使用して、ECS ストレージのフィックスコンテンツオブジェクトを格納、取得、削除できます。基盤となる ECS ストレージは、ECS設定を構成する前にプロビジョニングする必要があります。プロビジョニングは、通常、新しい ECS ラックの設置時に完了させます。これには、ストレージプール、VDC、レプリケーショングループの設定が含まれます。ECS CAS で、CAS をサポートするオブジェクトの作成や編集が必要な場合には、標準のドキュメントを参照します。ECS製品ドキュメントページ内の使用可能な「ECS管理ガイド」を参照してください。お使いのストレージプールで、コールドアーカイブの設定の検討が必要になる場合があります。コールドストレージ（92 ページ）を参照してください。次に、以下の標準的なドキュメントを参照して、ネームスペース、ユーザー、バケットを設定します。ECS製品ドキュメントページ内の使用可能な「ECS管理ガイド」を参照してください。本章では、CAS をサポートする基本構成の変更方法について説明します。

コールドストレージコールドアーカイブストレージについて説明します。

コールドアーカイブには頻繁に変更されないオブジェクトが格納されており、堅牢なデフォルト EC スキームは必要ありません。コールドアーカイブで使用される EC スキームは、データフラグメントが 10個、符号化フラグメントが 2個です（10/12）。効率性は 1.2x です。新しいストレージプールを作成する場合に、コールドアーカイブ（コールドストレージ）を指定できます。ストレージプールの作成後に、EC スキームを変更することはできません。このスキームは、1 ノードの消失をサポートできます。6 ドライブ中の 1 ドライブの消失、別々の 2 ノード上の 12 ドライブ中の 2 ドライブの消失もサポートできます。

EC要件表 17 通常のアーカイブとコールドアーカイブの要件の比較

使用例有効化方法最低必要ノード数

最低必要ディスク数

推奨されるディスク数

EC効率性 EC スキーム

定期的アーカイブ

標準 4 16* 32 1.33倍 12/16

コールドアーカイブ

システム管理者が構成 8 12* 24 1.2倍 10/12

*C シリーズアプライアンスの導入可能な最小構成が 12 ディスクずつ搭載した 2台のアプライアンスであるため、最小有効構成は 24 ディスクです。

ストレージプールの構成ポータルでコールドアーカイブを同期化するには、新しいストレージプールを作成するときに［ColdStorage］を選択します。この設定は、ストレージプールの作成後は変更できません。

CAS





コンプライアンス電子記録の保存に関する政府や業界の標準をサポートする ECS機能について説明します。ECSは、Cohasset Associates Inc に認定された、次の規格のストレージ要件を満たしています。l SEC（証券取引委員会）規制 17 C.F.R. § 240.17a-4（f）l CFTC（コモディティ先物取引委員会）規制 17 C.F.R. § 1.31（b）-（c）ECSバージョン 2.2.1 ソフトウェア以降を使用している ECS アプライアンスは、コンプライアンス認定されています。ECS認定されたサードパーティ製ハードウェア上で実行されている ECS ソフトウェア専用バージョン 3.0以降のインストールも認定されています。コンプライアンスは、3 つのコンポーネントから構成されます。l プラットフォームハードニング：共通のセキュリティ脆弱性に対処します。l ポリシーベースの記録保存期間：保存中の記録の保存ポリシーを変更する機能を制限しま

す。l コンプライアンスレポート作成：システムエージェントによる定期的なレポート作成により、システ

ムのコンプライアンスステータスが定期的に記録されます。

プラットフォームの堅牢化とコンプライアンス次の ECS のセキュリティ機能では、コンプライアンス標準をサポートしています。ECS プラットフォームのセキュリティ機能：

CAS

コンプライアンス 93

l ノードへのユーザーの root アクセスは無効化されています（ユーザーの root ログインを許可しません）。

l ECS のお客様は、初回インストール時に設定した管理ユーザーを通じてノードにアクセスできます。

l 管理ユーザーが sudo を使用してノード上でコマンドを実行します。l sudo コマンドによるフル監査ログ機能があります。l ESRS には、ノードへのすべてのリモートアクセスをシャットダウンする機能があります。［ESRS

Policy Manager］で、［Start Remote Terminal］アクションを［Never Allow］に設定します。

l 不要なポート（ftpd、sshd）はすべて閉じられます。l ロック管理者ロールを持つ emcsecurity ユーザーは、クラスタ内のノードをロックできます。つ

まり、SSH によるネットワーク経由でのリモートアクセスが無効になります。ロック管理者はノードのロックを解除して、リモートメインテナンスアクティビティなどの権限が必要なアクセスを可能にします。

ノードのロックは、ECS Portal または ECS Management API の許可されたユーザーに影響を与えません。

コンプライアンスと保存ポリシーコンプライアンスが有効な ECS システム上での記録保持のための高度なルールについて説明します。ECS では、オブジェクト、バケット、ネームスペースのレベルで、オブジェクト保存機能が［Enabled］に設定されます。コンプライアンスは、保存中のオブジェクトに対する保存設定への変更を制限することによって、これらの機能を強化します。次のようなルールがあります。l コンプライアンスはネームスペースレベルで有効化します。つまり、ネームスペース内のすべてのバ

ケットの保存期間が、0 より大きい必要があります。CAS では、［Enforce RetentionInformation in Object］設定を有効にすると、保存期間がゼロのバケットを作成できます。

l コンプライアンスの有効化は、ネームスペースの作成時にのみ可能です。（既存のネームスペースにコンプライアンスを追加することはできません。）

l いったん有効化したコンプライアンスは無効化できません。l ネームスペース内のすべてのバケットの保存期間が、0 より大きい必要があります。

オブジェクトレベルで保存期間を割り当てるアプリケーションがある場合に、ECS を使用してアプリケーションの保存期間を超える保存期間を割り当てることはしないでください。このアクションによって、アプリケーションエラーが発生します。

l 保存されている値にかかわらず、中にデータが入ったバケットは削除できません。l バケットに［Infinite］オプションを適用すると、コンプライアンスが有効なネームスペースのバケッ

ト内のオブジェクトは永久削除できなくなります。l オブジェクトの保存期間を削除または短縮することはできません。したがって、バケットの保存期

間を削除または短縮することはできません。l オブジェクトおよびバケットの保存期間は延長することができます。l 保存期間中のオブジェクトを削除する機能はありません。これには、CAS管理者権限による

削除の場合も同様です。

CAS


図 1 ECS Portal の新しいネームスペースでコンプライアンスを有効化

コンプライアンスエージェントコンプライアンスエージェントの動作について説明します。コンプライアンス監視を除くコンプライアンス機能が、デフォルトで有効化されています。監視が有効化されている場合、エージェントは定期的にメッセージをログに記録します。

コンプライアンス監視を有効にするには、カスタマーサポートと調整します。ノードからのコマンドにより、メッセージをモニタリングすることができます。メッセージは ECS ポータルには表示されません。

ECSでの CASの保存CAS C-Clip では、保存期間を定義できます。この期間中は関連オブジェクトが ECS ストレージに保持され、期間が終了するとアプリケーションによってオブジェクトが削除されます。

保存期間保存期間は、CAS アプリケーションによってオブジェクトの C-Clip に割り当てられます。

CAS

コンプライアンスエージェント 95

たとえば、財務ドキュメントを作成日から 3年間保存する必要がある場合は、財務ドキュメントに関連づけられた C-Clip に 3年間の保存期間を指定します。ドキュメントの保存期間を無期限にすることもできます。

保存ポリシー（保存クラス）

Centera の「保存クラスの設定」の概念は、ECS の「保存ポリシー」にマッピングされます。本ドキュメントでは「保存ポリシー」を使用します。

保存ポリシーを設定すれば、保存用途を取り入れて C-Clip に適用できます。たとえば、ドキュメントのタイプごとに異なる保存期間を割り当てることができます。必要な保存期間は、次のとおりです。l 財務：3年間l 法務：5年間l E メール：6 か月間保存ポリシーが複数の C-Clip に適用されている場合は、ポリシーを変更すると、ポリシーが適用されているすべてのオブジェクトの保存期間が変更されます。保存ポリシーは、ECS のネームスペースに関連づけられ、CAS アプリケーションによって保存クラスとして認識されます。

ECSバケットレベルの保存と CASバケットレベルの保存は、Centera のプールのデフォルト保存ではありません。ECS での CAS のデフォルト保存期間は常にゼロです。

オブジェクトレベル保存期間なしにコンプライアンスのネームスペース内に書き込まれると、オブジェクトのデフォルト保存期間の動作は変ります。ECS 3.0 から開始すると、アプリケーションがオブジェクト保存期間なしの C-Clip をコンプライアンスネームスペース内の ECS CASバケットに書き込み、バケットに保存期間値（例、6 か月）が設定されていると、C-Clip にはデフォルト保存期間 infinite（-1）が割り当てられます。C-Clip の有効保存期間は、バケットレベル保存期間とデフォルトのオブジェクトレベル保存期間の 2 つの保存期間の長い方なので、C-Clip が削除されることはありません。これは ECS 2.2.1 の動作からの変更点です。ECS 2.2.1 では、ECS の動作は Centera の動作と同じで、CE+コンプライアンスモードのデフォルトプールの保存期間は常に infinite（-1）です。ECS 2.2.1 では、アプリケーションがオブジェクト保存期間なしの C-Clip をコンプライアンスネームスペース内の ECS CASバケットに書き込み、バケットに保存期間値（例、6 か月）が設定されていると、C-Clip に割り当てられている保存期間がゼロ（0）になります。この場合、C-Clip の有効保存期間はバケット保存期間値（6 か月）になります。6 か月すると、C-Clipは削除できます。ECS 2.2.1 から ECS 3.0以降にアップグレードすると、ECS 2.2.1 の動作に依存していたアプリケーションは永久に削除されない C-Clip を書くことになります。ECS 3.0以降のバージョンと動作する前に、適切なオブジェクトレベル保存期間を割り当てるために、アプリケーションをいったん停止して再構成します。先の例では、アプリケーションはオブジェクトレベル保存期間として、6 か月を C-Clip に割り当てる必要があります。

CASの優先順位ECS の CAS オブジェクトに複数の保存期間が適用されている場合は、保存期間の適用方法に関係なく、高い値を持つ保存期間が優先されます。

CAS


CAS保存期間の適用方法ECS ポータルで、または ECS管理 API を使用して、ネームスペースの保存ポリシーを定義することができます。ネームスペースの保存ポリシーの設定（103 ページ）を参照してください。外部の CAS アプリケーションで、C-Clip の作成時に一定の保存期間や保存ポリシーを C-Clip に割り当てることができます。API を使用して保存期間を適用する場合は、期間を秒単位で指定します。ECS CAS では、保存に関連するすべての計算に C-Clip の作成時間が含まれ、移行時間は含まれません。

ECS管理 API を使用した保存ポリシーの作成方法ECS Management REST API を使用して保存期間と保存ポリシーを作成できます。その概要は次のとおりです。

表 18 保存期間のための ECS管理 API リソース

方法説明

PUT /object/bucket/{bucketName}/retention

バケットの保存期間の値により、バケット内のすべてのオブジェクトに適用される強制的な保存期間が定義されます。保存期間を 1年間に設定すると、そのバケットのオブジェクトは 1年間削除できません。

GET /object/bucket/{bucketName}/retention

指定したバケットに現在設定されている保存期間を返します。

POST /object/namespaces/namespace/{namespace}/retention

ネームスペースに対して、保存設定はポリシーのように機能します。各ポリシーは<名前>:<保存期間>のペアになっています。ネームスペースに複数の保存ポリシーを定義できます。また、ネームスペース内のオブジェクトにポリシーを名前別に割り当てることができます。そのため、該当するポリシーを変更することで、同じポリシーが割り当てられた複数のオブジェクトの保存期間を変更できます。

PUT /object/namespaces/namespace/{namespace}/retention/{class}

ネームスペースに関連づけられている保存期間の期間を更新します。

GET /object/namespaces/namespace/{namespace}/retention

ネームスペースに定義されている保存ポリシーを返します。

ECS Management API の詳細については、ECS Management REST API の概要（114 ページ）を参照してください。オンラインリファレンスは次の場所にあります。ECS API リファレンス。

CAS アプリケーションの高度な保存：イベントベースの保存、法的証拠保全、最小/最大ガバナー

ECS でサポートされている CAS API で使用できる高度な保存機能について説明します。カスタマーアプリケーションは、CAS API を使用して保存戦略を有効化します。CAS のワークロードを ECS に移行すると、ECS が CAS API の機能を認識し、カスタマーアプリケーションは、引き続き移行されたデータで作業を続けることができます。ECS では、次の ARM（Advanced RetentionManagement）機能を利用できます。別ライセンスは必要ありません。l イベントベースの保存：CAS アプリケーションが指定イベントを受信すると、C-Clip を利用して

オブジェクトを構成し、保存期間または保存ポリシーを適用（トリガー）する機能です。

CAS

CAS アプリケーションの高度な保存：イベントベースの保存、法的証拠保全、最小/最大ガバナー 97


l 法的証拠保全：CAS アプリケーションが C-Clip を使用して法的証拠保全をオブジェクトに適用した場合に、オブジェクトの削除を防止します。CAS アプリケーションは、固有の法的証拠保全 ID を作成および適用することより、法的証拠保全を最大 100 オブジェクトに適用できます。

l 最大/最小ガバナー：管理者は、固定保存期間または可変保存期間に対して、バケットレベルの制限を設定することができます。可変保存期間は、イベントベース保存期間のサポートに設定されます。ECS の System Admin または Namespace Adminは、ECS Portal を使用して値を設定します。プログラマは、ECS Management API を使用して値を設定します。

ARMは、ECS に移行済みの、任意のネーミングスキーマで書かれたレガシーな CAS データをサポートします。

CASバケットレベル保存期のための最小/最大ガバナーECS Portalバケットから CAS を検索して、［Edit］を選択します。以下の画面に表示されるコントロールは、［Bucket Retention Period］コントロールを除き、すべて CAS専用の機能です。［Bucket Retention Period］は、すべての ECSバケットタイプをサポートする標準 ECSバケット保存機能です。図 2 CASバケットの保存オプション

CASバケット保存機能を以下に一覧表示します。

機能説明

EnforceRetention

このコントロールが有効になっている場合、保存情報（期間またはポリシー）を含まない CAS オブジェクトは作成できません。このようなオブジェクトを保存しようとすると、エ

CAS


機能説明

Information inObject

ラーを返します。有効になっている場合は、コンプライアンスが有効な環境でも、［Bucket Retention Period］を構成する必要はありません。

CE+モードの Centera からの ECS への移行の場合は、バケットの［EnforceRetention Information］はデフォルトで有効です。

Bucket RetentionPeriod

バケット保存期間を指定する場合に、バケットレベルとオブジェクトレベルの両方の保存期間がある場合、長い方の期間が適用されます。コンプライアンスが有効な環境では、オブジェクトに保存情報が適用されていなければ、［Bucket Retention Period］が必須です。ただし、いったん構成した［Bucket Retention Period］は、オブジェクトに保存情報を適用しても、リセットできません。

Minimum FixedRetention Period

この機能は、オブジェクトで指定された保存期間を決定します。オブジェクト保存期間がこの指定値の範囲外の場合、そのオブジェクトを書き込もうとすると失敗します。保存ポリシーを使用する場合、最小/最大設定値は適用されません。

［Minimum Fixed Retention Period］で［Infinite］を選択すると、すべての保存期間の値が無期限になります。［Maximum Fixed RetentionPeriod］に選択した場合は、最大保存期間がなくなります。最小/最大保存値は、バケットに書き込まれたすべての C-Clip に適用されます。SDK ベースのサードパーティ製ツールを使用してクリップを移行する場合、保存期間内の保存である必要があります。そうでなければ、エラーがスローされます。

Maximum FixedRetention Period

Minimum VariableRetention Period

この機能は、EBR（イベントベース保存）を使用してオブジェクトに指定される可変保存期間を決定します。EBR にはベース保存期間が設定されており、トリガーが発生すると、プログラムされたトリガー関数で保存期間を延長することができます。オブジェクトの新しい保存期間がこの指定値の範囲外の場合、そのオブジェクトを書き込もうとすると失敗がトリガーされます。保存ポリシーを使用する場合、最小/最大設定値は適用されません。

［Minimum Variable Retention Period］で［Infinite］を選択すると、すべての保存期間の値が無期限になります。［Maximum VariableRetention Period］に選択した場合は、最大保存期間がなくなります。最小/最大保存値は、バケットに書き込まれたすべての C-Clip に適用されます。SDK ベースのサードパーティ製ツールを使用してクリップを移行する場合、保存期間内の保存である必要があります。そうでなければ、エラーがスローされます。

MaximumVariableRetention Period

システム管理者またはプログラマが固定保存期間と可変保存期間の値を設定していない場合は、ECS Management API の get関数は最小/最大設定値を返しません。［C-Clip の Enforce

Retention Information］は、デフォルト値 false を返します。

イベントベースの保存EBR（イベントベース保存）とは、イベント発生前とイベント発生後も指定期間中は、レコードが削除できないことを指定する命令です。CAS の EBRはベース保存期間または保存ポリシーが指定された C-Clip であり、さらにトリガー発生時に保存期間を延長するためのアプリケーション定義トリガーも指定されています。保存期間は、トリガーが発生して初めて開始されます。EBR にマークされた

CAS


C-Clipは、管理者権限による削除を使用しない限り、イベントの発生前に削除することはできません。EBR を使用する場合の C-Clip のライフサイクルは、次のとおりです。l 作成：アプリケーションが新しい C-Clip を作成し、EBR下にあることをマークします。アプリケー

ションは最小保存期間として動作する固定保存期間を指定できますが、イベントベース保存期間またはポリシーの指定は必須です。

l トリガーとなるイベント：アプリケーションがイベントをトリガーし、それがイベントベース保存期間または保存ポリシーの開始点になります。この時点で、アプリケーションは新たなイベントベース保存期間を設定して、C-Clip作成時に割り当てられているよりも長い保存期間を割り当てることができます。

l 削除：アプリケーションが C-Clip を削除する場合は、次の条件を満たしている必要があります。n ポリシー（ネームスペース）保存期間が期限切れになっているn バケット保存期間が期限切れになっているn 固定保存期間が期限切れになっているn イベントがトリガーされているn 作成時の EBR設定と、それに続くイベント発生時の変更（拡張）の、両方の期限が切れている

次の図は、EBR の下の C-Clip の可能性のある 3 つのシナリオを示しています。l C1は固定または最小保存期間で、イベントの発生前に、すでに期限が切れていた。l C2は固定または最小保存期間で、EBR の有効期限が切れる前に、期限が切れる。l C3は固定または最小保存期間で、EBR の期限切れ後に、期限が切れる。図 3 EBR のシナリオ

非準拠ネームスペースに対しては、管理者権限による削除コマンドにより、EBR の固定保存期間と可変保存期間を上書きします。EBR の保存期間を適用する場合は、可変保存期間の最小/最大ガバナー設定に従う必要があります。

CAS


表 19 イベントベース保存のための CAS API関数

機能説明

FPClip_EnableEBRWithClass 将来のイベントを受信できるように C-Clip を設定し、生成中の C-Clip に EBR（イベントベース保護）クラスを割り当てることができるようにします。

FPClip_EnableEBRWithPeriod 将来のイベントを受信できるように C-Clip を設定し、生成中の C-Clip に EBR（イベントベース保護）期間を割り当てることができるようにします。

FPClip_IsEBREnabled C-Clip が EBR（イベントベース保護）に対して有効かどうかを示すブール値を返します。

FPClip_GetEBRClassName C-Clip に割り当てられている EBR（イベントベース保存）ポリシーの名前を取得します。

FPClip_GetEBREventTime C-Clip の EBR（イベントベース保存）イベントのトリガー時に、C-Clip に設定されたイベント時刻を返します。

FPClip_GetEBRPeriod C-Clip に関連づけられた EBR（イベントベース保存）期間の値（秒）を返します。

FPClip_TriggerEBREvent EBR（イベントベース保存）が有効になって C-Clip のイベントをトリガーします。

FPClip_TriggerEBREventWithClass EBR（イベントベース保存）が有効になっている C-Clip

のイベントをトリガーし、その C-Clip に新しい EBR ポリシーを割り当てます。

FPClip_TriggerEBREventWithPeriod EBR（イベントベース保存）が有効になっている C-Clip

のイベントをトリガーし、その C-Clip に新しい EBR期間を割り当てます。

法的証拠保全法的証拠保全により、CAS アプリケーションは一時的に C-Clip の削除を防止することができます。法的証拠保全は、正式な調査、令状、照会の対象データに便利であり、調査終了までデータが削除できなくなります。データを保存する必要がなくなれば、アプリケーションにより法的証拠保全を解除して、通常の保存動作を再開します。CAS アプリケーションは、法的証拠保全を C-Clip レベルに配置して削除します。

法的証拠保全の下では、管理者権限による削除でも C-Clip を削除することはできません。

1 つの C-Clip が、複数の法的証拠保全管理下に存在することができます。アプリケーションは固有の法的証拠保全 ID を生成して、C-clip に関連づけられている特定の法的証拠保全をトラッキングできる必要があります。アプリケーションは、この情報を求めて C-Clip をクエリーすることはできません。C-Clip の法的証拠保全状態の決定は関数のみの機能です。C-Clip に法的証拠保全が 1つ以上ある場合関数は true を返し、それ以外の場合は false を返します。法的証拠保全を使用する場合の C-Clip のライフサイクルは、次のとおりです。l 作成：アプリケーションが新しい C-Clip を作成し、固定またはイベントベース保存期間を設定

します。l 法的証拠保全の設定：アプリケーションが C-Clip を保留中にします。このアプリケーションは、

C-Clip を作成したアプリケーションとは別のアプリケーションでもかまいません。

CAS


l 法的証拠保全のリリース：アプリケーションが C-Clip をリリースします。このアプリケーションは、法的証拠保全を設定したり、C-Clip を書いたアプリケーションとは別のアプリケーションでもかまいません。

l 削除：アプリケーションが C-Clip を削除するには、次の条件を満たす必要があります。n C-Clip に対応中の他の法的証拠保全がない。n ポリシー保存期間が期限切れになっている。n 標準バケット保存期間が期限切れになっている。（標準バケット保存期間はすべての ECSオブジェクトタイプに対して使用できますが、CAS には推奨されません）。

n 固定保存期間が期限切れになっている（CAS専用機能）。n イベントベース保存期間が期限切れになっている（CAS専用機能）。

次の図は、法的証拠保全状態の C-Clip の、可能性のある 3 つのシナリオを示しています。l 法的証拠保全状態になった時点で期限切れの固定保存期間が C1 に設定されている。l 法的証拠保全状態中に期限が切れる固定保存期間が C2 に設定されている。l 法的証拠保全のリリース後に期限切れになる固定保存期間が C3 に設定されている。図 4 法的証拠保全のシナリオ

C-Clip には、複数の法的証拠保全を割り当てることもできます。その場合は、法的証拠保全ごとに固有の ID を使用して、法的証拠保全別に API コールを行う必要があります。

法的証拠保全 ID の最大サイズは 64文字です。C-Clip ごとの法的証拠保全 ID の最大数は100 です。これらの制限事項は CAS API によって適用されます。

表 20 法的証拠保全のために CAS API関数

機能説明

FPClip_GetRetentionHold C-Clip の保全状態を決定し、true または false

を返します。

CAS


表 20 法的証拠保全のために CAS API関数（続き）

機能説明

FPClip_SetRetentionHold C-Clip の保存保全を設定またはリセットします。法的証拠保全が複数ある場合は、保全ごとに固有の法的証拠保全 ID付けます。保全が複数ある場合、ID ごとに 1 コールします。

ネームスペースの保存ポリシーの設定ネームスペースの保存ポリシーの CAS固有設定手順について説明します。

ネームスペースの保存ポリシー機能では、ネームスペースに作成されたすべての C-Clip の CAS保存クラスを定義および管理できます。ネームスペースに複数の保存ポリシーを設定し、各ポリシーで保存期間を定義することができます。API を使用して複数の C-Clip に同一の保存ポリシーを適用すれば、保存ポリシーを変更することで、そのポリシーに関連づけられているすべてのオブジェクトの保存期間を変更できます。CAS では、アプリケーションによってオブジェクトの C-Clip に保存クラスが適用されます。オブジェクトの保存期間中は、そのオブジェクトを変更することはできません。手順

1. ECS ポータルで、［Manage］ > ［Namespace］を選択します。2. 既存のネームスペースの構成を編集するには、そのネームスペースに関連づけられた［Edit］

アクションを選択します。3. 保存ポリシーを追加して構成します。

a.［Retention Policies］エリアで、［Add］を選択して新しいポリシーを追加します。b. ポリシー名を入力します。c. 保存ポリシーの期間を指定します。［Infinite］チェックボックスをオンにして、このポリシーが設定されているオブジェクトが削除されないようにします。

CAS

ネームスペースの保存ポリシーの設定 103

図 5 新しい保存ポリシー

4. ［Save］を選択します。図 6 ネームスペースの保存ポリシー

CAS ユーザーのバケットの作成および設定CAS ユーザーをサポートするバケットを構成します。

ECS では、管理ユーザーがバケットを作成して、バケット所有者になります。CAS では、オブジェクトユーザーをバケット所有者として設定する必要があります。CASバケットを正しく設定して、CAS ユーザーをバケット所有者にするためには、次の手順を実行します。この例では、newcasadmin1は管理ユーザー、newcasuser1は CAS オブジェクトユーザー、newcasns1はネームスペースです。この手順では、2人のユーザーとネームスペースが設定済みであると仮定します。

手順1. newcasadmin1 として ECS Portal にログインします。2. ECS ポータルで、［Manage］ > ［Bucket］を選択します。3. ［New Bucket］を選択します。4. 次のように、フィールドに入力します。

CAS


フィールド値

Replication Group 自分のレプリケーショングループ

Set current user as Bucket Owner チェック内容

CAS Enabled

5. ［Save］を選択します。6. ［Manage］ > ［User］を選択します。7. ［Object User］タブがアクティブなことを確認し、newcasuser1 を検索して、［Edit］を

選択します。8. ［Default Bucket］で、newcasbucket1 を入力して、［Set Bucket］を選択します。9. ［Close］を選択します。

10. ［Manage］ > ［Bucket］を選択します。11. newcasbucket1 を検索して、［Edit bucket］を選択します。12. ［Bucket Owner］で、newcasuser1 を入力します。13. ［Save］を選択します。

CAS オブジェクトユーザーの設定CAS を使用するオブジェクトユーザーを設定します。

オブジェクトユーザーの設定時には、CAS プロファイルの構成要素となるプロファイルに CAS機能を割り当てることができます。その後、CAS アプリケーションで使用する PEA ファイルを表示できます。

手順1. ECS ポータルで、［Manage］ > ［Users］を選択します。2. 既存のオブジェクトユーザーの構成を編集するには、そのユーザーに関連づけられた［Edit］

アクションを選択します。図 7 オブジェクトユーザーの CAS設定

CAS

CAS オブジェクトユーザーの設定 105

3. CAS エリアで、パスワード（シークレット）を入力するか、［Generate］を選択してポータルでパスワードを作成します。

4. ［Set Password］を選択します。5. ［Generate PEA File］を選択して、ECS の CAS ストレージへの認証時にアプリケーション

に必要な PEA ファイルを生成します。6. デフォルトバケットを設定すると、バケットを指定しないすべてのユーザーアクションでこのデフ

ォルトバケットが使用されます。デフォルトバケットの名前を入力し、［Set Bucket］を選択します。

7. ［Add Attribute］を選択して、ユーザーにメタデータタグを追加します。8. メタデータタグの名前と値を追加します。

メタデータタグの詳細については、CAS SDK のマニュアルを参照してください。

9. ［Save Metadata］を選択します。

CASのバケット ACLの設定バケットの ACL（アクセス制御リスト）を編集して、ユーザーのアクセスを制限します。

ECSバケット ACLは、CAS権限にマップされているものもあれば、CAS データにとって無意味なものもあります。手順

1. ECS ポータルで、［Manage］ > ［Bucket］を選択します。2. 既存のバケットの ACL を編集するには、そのバケットに関連づけられた［Edit ACL］アクシ

ョンを選択します。図 8 バケット ACL の編集

3. ユーザーに関連づけられた［Edit］を選択します。

CAS


図 9 ［Bucket ACLs Management］

4. 権限を変更します。

表 21 バケットの ACL

ECS ACL ACL の定義

READ 読み取り、クエリー、既存の機能

WRITE 書き込みと法的証拠保全の機能

FULL_CONTROL 読み取り、削除、クエリー、既存、クリップコピー、書き込み、法的証拠保全

PRIVILEDGED_WRITE 権限による削除

DELETE 削除

その他の ECS ACLは、CAS にとって意味がありません。

5. ［Save］を選択します。

CAS

CAS のバケット ACL の設定 107

6. ACL をグループレベルでも編集できます。グループは事前定義されており、グループメンバーシップはユーザーの基準に基づいて自動的に設定されます。［Group ACLs］を選択します。

7. ［Add］を選択します。8. 編集するグループを［Group Name］リストから選択します。

表 22 バケット ACL グループ

バケット ACL グループ説明

public 認証された/認証されていないすべてのユーザー

all users 認証されたすべてのユーザー

other バケット所有者以外の認証されたユーザー

log delivery サポートなし。

9. ACL を編集し、［Save］を選択します。

CAS ユーザーをサポートする ECS管理 APICAS ユーザーおよびプロファイル設定の管理に使用できる ECS管理 API リソースについて説明します。ECS管理 API リソースについて説明します。l GET /object/user-cas/secret/{uid} ：指定したユーザーの CAS シークレットを

取得する。l GET /object/user-cas/secret/{namespace}/{uid}：指定したネームスペー

スとユーザーの CAS シークレットを取得する。l POST /object/user-cas/secret/{uid}：指定したユーザーの CAS シークレットを

作成または更新する。l GET /object/user-cas/secret/{namespace}/{uid}/pea：指定したユーザ

ーの PEA ファイルを生成する。l POST /object/user-cas/secret/{uid}/deactivate：指定したユーザーの

CAS シークレットを削除する。l GET /object/user-cas/bucket/{namespace}/{uid}：指定したネームスペー

スとユーザーのデフォルトバケットを取得する。l GET /object/user-cas/bucket/{uid}：指定したユーザーのデフォルトバケットを

取得する。l POST /object/user-cas/bucket/{namespace}/{uid}：指定したネームスペ

ースとユーザーのデフォルトバケットを更新する。l GET /object/user-cas/applications/{namespace}：指定したネームスペー

スの CAS登録アプリケーションを取得する。l POST /object/user-cas/metadata/{namespace}/{uid}：指定したネームス

ペースとユーザーの CAS登録アプリケーションを更新する。l GET /object/user-cas/metadata/{namespace}/{uid}：指定したネームス

ペースとユーザーの CAS ユーザーメタデータを取得する。

CAS


詳細については、を参照してください。

CAS（コンテンツアドレスストレージ）SDK API サポートサポートされるバージョンECSは CAS ビルド 3.1.544以降をサポートします。さらに、利用している ISV のアプリケーションが、ECS をサポートしていることを確認する必要があります。ECS CAS サポートの詳細は、ECS の CAS サポートの設定（92 ページ）に記述されています。

Cas Query サポートCAS Queryは、ECS 2.2以降サポートされています。

ECS では、CAS Query操作により、既存の C-Clip の作成時間と削除済み C-Clip（反映）の削除時間に基づいた結果が返されます。EMC Centera では、クエリー操作により、オブジェクトの書き込み時間に基づいた結果が返されます。

ECS 3.0より前の ECSバージョンではサポートされない APIECS 3.0 より前の ECSバージョンではサポートされない CAS SDK API コール：l FPClip_EnableEBRWithClass

l FPClip_EnableEBRWithPeriod

l FPClip_SetRetentionHold

l FPClip_TriggerEBREvent

l FPClip_TriggerEBREventWithClass

l FPClip_TriggerEBREventWithPeriod

l FPClip_GetEBRClassName

l FPClip_GetEBREventTime

l FPClip_GetEBRPeriod

l FPClip_GetRetentionHold

l FPClip_IsEBREnabled

CAS

CAS（コンテンツアドレスストレージ）SDK API サポート 109

CAS


第 5部

ECS Management REST API

第 5章, "ECS Management REST API"




第 5章


l ECS Management REST API の概要.................................................................. 114l ECS Management REST API による認証............................................................. 114


ECS Management REST APIの概要このセクションでは、ECS Management REST API へのアクセスと認証方法を説明し、APIパスのサマリーを示します。ECS Management REST API を使用してオブジェクトストアを構成および管理できます。オブジェクトストアの構成が完了すれば、ECS でサポートするオブジェクトおよびファイルプロトコルを使用して、オブジェクトの作成、読み取り、更新、削除の操作を実行できます。ECS Management REST API の詳細については、次のトピックを参照してください。l ECS Management REST API による認証（114 ページ）l ECS Management REST API のサマリー（117 ページ）さらに、ソースコードから自動生成され、API で利用可能なメソッドのリファレンスを提供する ECSAPI リファレンスも参考になります。

ECS Management REST API による認証ECSは、REST API コールにトークンベースの認証システムを使用します。このセクションでは、cookie あり/なしでの ECS API認証の例を示します。ECS で認証するときに、ECS APIは認証トークンを返します。このトークンを以後のコールで認証に使用することができます。l クライアントが自動でリダイレクトをフォローする場合、ECS APIは HTTP 401 コードを返しま

す。この場合は、ログイン後に認証して新しいトークンを取得する必要があります。l クライアントが自動でリダイレクトをフォローしない場合、ECS APIは HTTP 302 コードを返しま

す。302 コードでは、クライアントは再認証を行う場所にダイレクトされます。認証トークンは次の方法で取得できます。l 成功した認証リクエストの X-SDS-AUTH-TOKEN cookie を保存し、以後のリクエストでこの

cookie を送信する。l 成功した認証リクエストの X-SDS-AUTH-TOKEN HTTP ヘッダーを読み取り、このヘッダーを

以後のリクエストにコピーする。ECS APIはポート 4443上で使用可能です。クライアントは次の形式のログインリクエストを発行して ECS にアクセスします。

https://<ECS_IP>:4443/login

cookie を使用しない認証次の例では、認証トークンを使用する方法として、成功した認証リクエストから X-SDS-AUTH-TOKEN HTTP ヘッダーを読み取り、以後のリクエストにそのヘッダーをコピーする形式を示します。この例では cookieは使用しません。この例は curl コマンドラインツールを使用して記述されており、読みやすいようにフォーマットされています。次の ECS API コールは、/login リソースに対する GET を実行します。-u オプションは、基本認証ヘッダーのユーザーを指定します。リクエストでこのユーザーを指定する必要があります。認証が成功すると、ECS APIは HTTP 200 コードと、エンコードされたトークンを含む X-SDS-AUTH-TOKEN ヘッダーを返します。ECS API トークンのデフォルト有効期間は 8時間であり、8時間を経過するとトークンは無効になります。トークンのデフォルトアイドル時間は 2時間であり、アイドル時間が 2時間を経過すると、ト





ークンの有効期限が終了します。有効期限切れのトークンを使用すると、/login URL にリダイレクトされます。これ以降に有効期限切れのトークンを使用すると HTTP ステータスエラーコード 401を受け取ることになります。

curl -L --location-trusted -k https://10.247.100.247:4443/login -u "root:ChangeMe" -v

> GET /login HTTP/1.1> Authorization: Basic cm9vdDpDaGFuZ2VNZQ==> User-Agent: curl/7.24.0 (i386-pc-win32) libcurl/7.24.0 OpenSSL/0.9.8t zlib/1.2.5> Host: 10.247.100.247:4443> Accept: */*>< HTTP/1.1 200 OK< Date: Tue, 26 Nov 2013 22:18:25 GMT< Content-Type: application/xml< Content-Length: 93< Connection: keep-alive< X-SDS-AUTH-TOKEN: BAAcQ0xOd3g0MjRCUG4zT3NJdnNuMlAvQTFYblNrPQMAUAQADTEzODU0OTQ4NzYzNTICAAEABQA5dXJu OnN0b3JhZ2VvczpUb2tlbjo2MjIxOTcyZS01NGUyLTRmNWQtYWZjOC1kMGE3ZDJmZDU3MmU6AgAC0A8=<<?xml version="1.0" encoding="UTF-8" standalone="yes"?><loggedIn> <user>root</user></loggedIn>* Connection #0 to host 10.247.100.247 left intact* Closing connection #0* SSLv3, TLS alert, Client hello (1):

X-SDS-AUTH-TOKEN の内容をコピーして、次の例に示すように curl ツールの -H スイッチを通じて次の API コールに渡すことができます。

curl https://10.247.100.247:4443/object/namespaces -k -H "X-SDS-AUTH-TOKEN: BAAcOHZLaGF4MTl3eFhpY0czZ0tWUGhJV2xreUE4PQMAUAQADTEzODU0OTQ4NzYzNTICAAEABQA5dXJu OnN0b3JhZ2VvczpUb2tlbjpkYzc3ODU3Mi04NWRmLTQ2YjMtYjgwZi05YTdlNDFkY2QwZDg6AgAC0A8="

<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <namespaces> <namespace> <id>ns1</id> <link rel="self" href="/object/namespaces/namespace/ns1"/> <names>ns1</name> </namespace></namespaces>

cookie を使用した認証この例では、認証トークンを使用する方法として、成功した認証リクエストから cookie を保存し、以後のリクエストにその cookie を渡す形式を示します。


cookie を使用しない認証 115

次の例では、?using-cookies=true パラメーターを使用して、標準の HTTP ヘッダーに加えて cookie を受け取るように指示しています。この curl コマンドは、認証トークンをカレントディレクトリの cookiefile というファイルに保存します。

curl -L --location-trusted -k https://<ECS_IP>:4443/login?using-cookies=true -u "root:Password" -c cookiefile -v

次のコマンドは、curl コマンドの-b スイッチを使用して認証トークンを含む cookie を渡し、ユーザーのテナント情報を返します。

curl -k https://10.247.100.247:4443/object/namespaces -b cookiefile -v

<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <namespaces> <namespace> <id>ns1</id> <link rel="self" href="/object/namespaces/namespace/ns1"/> <names>ns1</name> </namespace></namespaces>

ログアウトログアウト APIは、セッションを終了します。

各ユーザーは、最大 100 のコンカレント認証トークンを使用できます。この制限を超えると、トークンが解放されるまで、ユーザーの新しい接続は拒否されます。トークンは、自然に期限切れになることによるか、次の ECS API コールを発行することで解放できます。

GET https://<ECS_IP>:4443/logout

複数のセッションを同時に実行している場合は、次の API コールにより、現在のユーザーに関連したすべてのトークンが終了します。

GET https://<ECS_IP>:4443/logout?force=true

次の例は、ログアウトリクエストを示しています。ヘッダーまたは cookie で認証トークンを渡してログアウトします。

GET https://<ECS_IP>:4443/logout

X-SDS-AUTH-TOKEN:{Auth_Token}

レスポンスは HTTP 200 になります。

ECS Management REST API の whoami コマンドECS ユーザーは、whoami API コールを使用して、自分のユーザー名、テナント関連づけ、役割を確認できます。



リクエスト

GET https://<ECS_IP>:4443/user/whoami

次のレスポンスは、root ユーザーに対する whoami出力と、ns1 ネームスペースのNAMESPACE_ADMIN役割が割り当てられたユーザーに対する whoami出力を示しています。レスポンス

HTTP 200

GET /user/whoami<user> <common_name>root</common_name> <distinguished_name/> <namespace/> <roles> <role>SYSTEM_ADMIN</role> </roles></user>

HTTP 200

GET /user/whoami<user> <common_name>[email protected]</common_name> <distinguished_name/> <namespace>ns1</namespace> <roles> <role>NAMESPACE_ADMIN</role> </roles></user>

ECS Management REST API のサマリーECS Management REST API を利用して、ECS オブジェクトストアの構成と管理ができます。

次の表に ECS Management REST API の概要をまとめています。表 23 ECS Management REST API：メソッドのサマリー

API エリア説明

［Configuration］

証明書 /object-cert証明書を管理する API。

/object-cert/keystoreECS によって使用される証明書チェーンを指定およびローテーションする API。

構成のプロパティ /config/object/propertiesユーザースコープを GLOBAL または NAMESPACE として設定する API。最初のユーザーを作成する前に、これを設定する必要があります。デフォルトはGLOBAL です。

GLOBAL スコープでは、ユーザーはグローバルとなり、ネームスペース間で共有が可能です。この場合、ユーザーに関連づけられたデフォルトのネームスペースによっ


ECS Management REST API のサマリー 117

表 23 ECS Management REST API：メソッドのサマリー（続き）

API エリア説明

てオブジェクト操作のネームスペースが決まるため、操作のためのネームスペースを指定する必要はありません。NAMESPACE スコープでは、ユーザーはネームスペースに関連づけられます。この場合は、同じ名前を持つユーザーが複数存在し、それぞれに別のネームスペースが関連づけられている可能性があり、すべての操作にネームスペースを指定する必要があります。

ライセンス /licenseライセンスを追加してライセンスの詳細を取得する API。

機能 /feature/機能の詳細を取得する API。

Syslog /vdc/syslog/configSyslog構成を管理して、トラブルシューティングとデバッグ用にアラートを Syslog

サーバに送信する API。

SNMP /vdc/snmp/configSNMP構成を管理して、トラブルシューティングとデバッグ用にアラートを SNMP

サーバに送信する API。

［CAS］

CAS ユーザープロファイル

/object/user-casCAS ユーザーへのシークレットキーの割り当てと PEA（Pool Entry

Authorization）の生成を行う API。

［ファイルシステムアクセス］

NFS /object/nfsECSバケットに基づく NFS エクスポートの作成と、UNIX ユーザーと UNIX グループによるエクスポートへのアクセスを実現する API。

［測定］

課金 /object/billingテナントレベルとバケットレベルでオブジェクトストアの使用状況を測定するAPI。

［移行］

変換 /object/transformationデータの変換を有効にする API。

［監視］

容量 /object/capacity現在の管理対象容量を取得する API。

［ダッシュボード］

アラート /vdc/alerts




API エリア説明

監査アラートを取得する API。

イベント /vdc/events指定のネームスペースの監査イベントを返す API。

［マルチテナント］

ネームスペース /object/namespacesネームスペースを作成および管理する API。

この API では、ネームスペースの保存期間も設定します。保存期間の詳細については、ECS製品ドキュメントページ内の使用可能な「ECS管理ガイド」を参照してください。

［ジオレプリケーション］

レプリケーショングループ /data/data-service/vpoolsレプリケーショングループを作成および管理する API。

一時障害ゾーン /tempfailedzone/すべての一時障害ゾーン、または指定したレプリケーショングループの一時障害ゾーンを取得する API。

［プロビジョニング］

ベース URL /object/baseurl既存のアプリケーションと ECS オブジェクトストアの連携を可能にするベースURL を作成する API。ベース URL の詳細については、ECS製品ドキュメントページ内の使用可能な「ECS管理ガイド」を参照してください。

バケット /object/bucketバケットのプロビジョニングと管理を行う API。

/object/bucket/{bucketName}/lockバケットのアクセスをロックする API。

データストア /vdc/data-storesファイルシステム（/vdc/data-stores/filesystems）またはコモディティノード（/vdc/data-stores/commodity）でデータストアを作成する API。

ノード /vdc/nodes現在クラスタに構成されているノードを取得する API。

ストレージプール /vdc/data-services/varraysストレージプールを作成および管理する API。

仮想データセンター /object/vdcs


ECS Management REST API のサマリー 119





API エリア説明

VDC を追加し、ECS サイト間のデータレプリケーション用に中間 VDC エンドポイントとシークレットキーを指定する API。

VDC キーストア /vdc/keystoreVDC の証明書を管理する API。

［サポート］

オートコール /vdc/callhome/ESRS構成の管理と、ConnectEMC へのアラートの送信を行う API。

CLIパッケージ /cliECS CLIパッケージをダウンロードする API。

［ユーザー管理］

認証プロバイダー /vdc/admin/authproviders認証プロバイダーを追加して管理する API。

パスワードグループ（Swift）

/object/user-passwordOpenStack Swift認証で使用するパスワードを生成する API。

シークレットキー /object/user-secret-keysオブジェクトユーザーへのシークレットキーの割り当てとシークレットキーの管理を行う API。

シークレットキーセルフサービス

/object/secret-keysS3 ユーザーが新しい秘密キーを作成するための API。これにより、オブジェクトストアにある自分のネームスペース内のオブジェクトやバケットにアクセス可能になります。

ユーザー（オブジェクト） /object/usersオブジェクトユーザーを作成および管理する API。オブジェクトユーザーは常にネームスペースに関連づけられます。この APIは、S3 アクセスに使用できる秘密キーを返します。S3秘密キーを割り当てられたオブジェクトユーザーは、REST

API を使用してそのキーを変更できます。

/object/users/lock.

ユーザーアクセスをロックする API。

/object/users/{userName}/tags.

タグをユーザー ID と関連付ける API。タグは、name=value ペアの形式です。

ユーザー（管理） /vdc/usersユーザーを作成および管理する API。管理ユーザーには、システム管理者ロールかネームスペース管理者ロールを割り当てることができます。この API を使用して、ローカル管理ユーザーパスワードを変更できます。



第 6部

HDFS

第 6章, "ECS HDFS の概要"

第 7章, "ECS HDFS を使用したシンプルな Hadoop クラスタの構成"

第 8章, "ECS HDFS を使用した安全な（Kerberos対応）Hadoop クラスタの構成"

第 9章, "トラブルシューティング"

第 10章, "付録：Kerberos の構成について"

第 11章, "付録：ECS HDFS の Hadoop core-site.xml プロパティ"

第 12章, "付録：安全なバケットメタデータの例"

HDFS 121

HDFS


第 6章

ECS HDFS の概要

l ECS HDFS の概要............................................................................................. 124l ECS HDFS を使用するための Hadoop の構成 ...................................................... 125l Hadoop の認証モード.......................................................................................... 125l シンプルな Hadoop クラスターから Kerberos Hadoop クラスターへの移行....................129l ファイルシステムとの対話操作............................................................................... 130l サポートされる Hadoop アプリケーション................................................................... 130

ECS HDFS の概要 123

ECS HDFSの概要ECS HDFSは、ECS ストレージインフラストラクチャ上で Hadoop2.x アプリケーションを実行できるようにするための HCFS（Hadoop互換ファイルシステム）です。ECS HDFS を使用するとき、Hadoop ディストリビューションは組み込み型の Hadoop ファイルシステムに対してではなく、ECS HDFS に対して実行するよう構成されます。次の図は、ECS HDFS と既存の Hadoop クラスタがどのように統合されるかを示しています。図 10 ECS HDFS の Hadoop クラスタとの統合

Hadoop Cluster

ResourceManager

Hadoop Client

ECS Client Library

Node Manager

MapReduce Task

Appliance Software

MapReduce Request

Node Manager

MapReduce Task

Node Manager

MapReduce Task

ECS nodes

ECS nodes

ECSnodes

ECS Client Library ECS Client Library

ECS HDFS を使用するように構成されている Hadoop環境では、個々の ECS ノードが、従来のHadoop NameNode および DataNode と同様に機能します。この結果、すべての ECS ノードは、HDFS リクエストを受け入れてサービスを提供できます。Hadoop クライアントで従来の HDFS ではなく ECS HDFS を使用するように構成した場合は、すべての HDFS アクティビティの実行先として ECS HDFS がポイントされます。各 ECS HDFS クライアントノード上では、従来のすべての Hadoop コンポーネントは ECS クライアントライブラリ（ViPRFS JAR ファイル）を使用して HDFS アクティビティを実行します。ECS HDFS を既存の Hadoop環境に統合するには、以下の準備が必要です。

ECS HDFS の概要


l インストールおよび構成済みの Hadoop クラスタ。次のディストリビューションがサポートされています。n Hortonworks HDP 2.5

l インストール済みであり、ECS HDFS をサポートするように構成されている Hadoop クラスタ。以下が必要です。n HDFS アクセス用のファイルシステム対応バケット。

Hadoop クラスタごとに 1 つのバケットのみがサポートされます。ECS HDFSはデフォルトのファイルシステムである必要があります。

n クラスタに導入された ECS クライアントライブラリ。l Kerberos、または Kerberos と Active Directory を使用する Hadoop クラスタの場合。

n Kerberos設定ファイルと、ECS クラスタに導入されるサービスプリンシパルのキータブファイル。

n バケットに導入された安全なメタデータ。

ECS HDFS を使用するための Hadoopの構成Hadoopは、システム構成情報を core-site.xml、hdfs-site.xml、hive-site.xmlなどの多くのファイルに保存します。ECS HDFS の構成では、core-site.xml を編集する必要があります。core-site.xml ファイル内にある次のようないくつかのタイプのプロパティを追加または変更する必要があります。l ECS HDFS Java クラス：この一連のプロパティでは、ECS HDFS クライアントライブラリに含ま

れる ECS HDFS の実装クラスを定義します。l ファイルシステムのロケーションプロパティ：これらのプロパティは、Hadoop ジョブの実行時に使

用するファイルシステム URI（スキームと権限）と、特定の ECS ファイルシステムの ECS データノードの IP アドレスまたは完全修飾ドメイン名を定義します。

l Kerberos レルムとサービスプリンシパルのプロパティ：これらのプロパティは、Kerberos が存在する Hadoop環境でのみ必要です。これらのプロパティは、Hadoop ユーザーと ECS HDFS ユーザーをマップします。

core-site.xml ファイルは Hadoop クラスタ内の各ノードに存在します。core-site.xmlの各インスタンスに同じプロパティを追加する必要があります。

設定ファイルを変更する場合は、ファイルを手動で編集せずに、管理インターフェイス（Ambari）を使用する必要があります。Ambari管理インターフェイスを使用して行った変更は、クラスタ全体で維持されます。

Hadoopの認証モードHadoopは、ユーザー ID決定のために、シンプルモードと Kerberos モードの 2 つの操作モードをサポートしています。

ECS HDFS の概要

ECS HDFS を使用するための Hadoop の構成 125

シンプルシンプルモードでは、クライアントプロセスの IDは、ホストオペレーティングシステムによって決定されます。UNIX系のシステムでは、ユーザー名は whoami に相当します。

Kerberos

Kerberos を使用する Hadoop環境では、クライアントプロセスの IDは、Kerberos認証情報によって決定されます。たとえば、kinit ユーティリティを使用して Kerberos TGT（Ticket-Granting-Ticket）を取得し、klist を使用して現在のプリンシパルを判別できます。Kerberos プリンシパルを HDFS ユーザー名にマッピングする場合、auth_to_localHadoop プロパティを使用すると、プライマリ以外のすべてのコンポーネントはドロップされます。たとえばプリンシパル todd/[email protected]は、HDFS上でシンプルなユーザー名「todd」として動作します。

ECS HDFSは、単純認証または Kerberos認証モードを使用するように構成されている Hadoopクラスターと統合されます。Hadoop クラスタで Kerberos を使用する場合、[email protected]形式の Kerberos プリンシパルを使用してユーザーへのアクセスを許可するように ECS を構成できます。また ECS がユーザーの認証に AD を使用する場合は、Kerberos環境と AD間に単方向の信頼を構成することもできます。この場合ユーザーは、[email protected]形式の AD認証情報を使用してユーザーを認証することができます。新しく作成したファイルとディレクトリの権限は umask（fs.permissions.umask-mode）によって制限されます。推奨の umaskは 022 です。

ファイルシステムとしてのバケットへのアクセスHDFS ファイルシステムストレージは、ECSバケットにより提供されます。バケットを作成するときは、ファイルシステムとして利用できるように ECS内でバケットを構成する必要があります。ECSは（ECS クライアントライブラリを通じて）バケットに対して構成された権限および Hadoopcore-site.xml ファイル内の設定を使用してルートファイルシステム（バケット）へのアクセスを判別します。Hadoop ユーザーとサービスが、バケット内にファイルとディレクトリを作成できるように十分なアクセスを構成してあることを確認する必要があります。一般に、ファイルおよびディレクトリのすべての操作はバケット ACL によって許可される必要があります。また、バケット内の個々のファイルとディレクトリオブジェクトは、それぞれそれ自体のオブジェクトACL を持ちます。オブジェクトのすべての操作も、オブジェクト ACL によって許可される必要があります。オブジェクトの操作がバケットの ACL を満たさない場合、操作は拒否されます。オブジェクトの操作がオブジェクトの ACL を満たさない場合、操作は拒否されます。これに対する例外は、バケットの所有者と、Hadoop スーパーユーザー、および Hadoop スーパーグループのメンバー（hdfs-site.xml で定義）であり、バケットとオブジェクトの ACL に関係なく、任意のファイルシステム操作の実行が常に許可されます。バケット上のユーザーごとにユーザー ACL を明示的に追加するか、またはカスタムグループ ACL を指定することによりバケット ACL を設定できます。詳細については、バケットのカスタムグループ ACLとデフォルトグループ（127 ページ）を参照してください。バケットの所有者は ECS オブジェクトユーザーである必要があります。他のユーザーは ECS オブジェクトユーザーである必要はなく、Hadoop クラスタからの UNIX ユーザー名にすることができます。さらに例外があり、通常の ECSバケットと異なり、ファイルシステム対応 ECSバケットはルートディレクトリを表す特別なオブジェクトおよびディレクトリごとの特別なオブジェクトを持ちます。新しいファイルシステム対応バケットにはルートディレクトリオブジェクトは存在しませんが、このバケット対する最初のファイルシステム操作が実行されたときに作成されます。このようなルートディレクトリオブジェクトが存在する場合、一部の ECS HDFS API コールではバケット ACL チェックを実行しません。

ECS HDFS の概要


API コールに関係なく一貫性のある権限を確実にするには、ルートディレクトリオブジェクト ACL がバケット ACL を複製することを確認する必要があります。ユーザーがファイルシステムへのアクセス権を持つと、ユーザーが作成するファイルとディレクトリはcore-site.xml ファイル内の umask プロパティによって判別される権限を持ちます。

バケットのカスタムグループ ACL とデフォルトグループバケットへのアクセスは、ユーザー ACL に基づくか、カスタムグループ ACL を割り当てることによって有効化します。カスタムグループとは Hadoop クラスター上で定義されたユーザーグループの名前で、Hadoop ユーザーの HDFS によるバケットへのアクセスを有効化します。Hadoop クラスタ上に定義される標準的なグループには、hdfs（ユーザー hdfs）、hadoop（通常すべてのサービスユーザーを含む）、users（Hadoop クラスタ上のアプリケーションにアクセスするその他の非サービスユーザーを含む）があります。ECS Portal内に対応するグループを作成し、このグループに権限を割り当てることができます。バケットに「デフォルトグループ」を割り当てることもできます。デフォルトグループとは、root（/）ファイルシステムに割り当てられるグループです。たとえば、バケットの所有者が hdfs であり、デフォルトグループに hadoop が設定されている場合、/のユーザーとグループにはそれぞれ hdfs:hadoopが設定されます。デフォルトグループはカスタムグループでもあり、Custom Group ACL リストにも表示されます。デフォルトグループが定義されていない場合、次の例に示すように、ファイルシステムの root にはグループはありません。

drwx---rwx+ - hdfs 0 2015-12-09 12:30 /

デフォルトグループ hadoop が定義されている場合、所有権と権限は、次の例に示すように表示されます。

drwxrwxrwx+ - hdfs hadoop 0 2015-12-09 12:28 /

これらの権限は、root で作成したディレクトリには継承されません。デフォルトグループが割り当てられていない場合、hdfs dfs -chgrp および hdfs dfs -chmod コマンドを使用して Hadoop から HDFS にアクセスするときに、バケットの所有者（root ファイルシステムの所有者）がグループを割り当てることができます。

Hadoop のスーパーユーザーとスーパーグループHadoop環境でのスーパーユーザーは常、namenode を開始するユーザーで、hdfs または[email protected] です。ECS HDFS構成では、スーパーユーザーはバケット所有者です。そのため、Hadoop スーパーユーザーに ECSバケットのスーパーユーザーアクセス権を持たせる場合は、バケットが hdfs、[email protected]、または [email protected]（Hadoop環境でのユーザー認証に Active Directory を使用する場合）に所有されていることを確認する必要があります。Hadoop クライアントに確実にスーパーユーザーアクセスを持たせるには、core-site.xml ファイルで dfs.permissions.superusergroup プロパティを使用してスーパーユーザーグループを構成することもできます。シンプルモードでは、dfs.permissions.supergroupHadoop プロパティの値をチェックすることで、ユーザーがスーパーグループのメンバーであるかどうかがクライアント上で判別されます。Kerberos モードでは、ユーザーがスーパーグループのメンバーかどうかを判断するためのチェックは、ECS サーバーで行われます。

ECS HDFS の概要

バケットのカスタムグループ ACL とデフォルトグループ 127

一般に、Hadoop スーパーユーザーまたは Hadoop スーパーユーザーグループによるアクセスのためにバケットを構成する場合、スーパーユーザーはバケットに対するフル（読み取り/書き込み）アクセス権を持ちます。スーパーユーザー権限を持たないユーザーには通常読み取りアクセス権がありますが、これはバケットの作成方法に依存します。バケットへのアクセス権を付与する場合、ユーザーがECS オブジェクトユーザーである必要はありません。名前は UNIX ローカル、Kerberos、または ADユーザー（使用する認証モードに依存）と一致する必要があります。hdfs ユーザーまたは hdfs プリンシパルの一方がバケットの所有者（スーパーユーザー）かスーパーユーザーグループのメンバーであることを、確認することがベストプラクティスです。

マルチプロトコル（クロスヘッド）アクセスECSは、S3 プロトコルを使用してバケットにデータを書き込み、そのデータを HDFS経由のファイルとして使用できるようにする機能をサポートします。マルチプロトコルアクセス（クロスヘッドアクセス）とは、S3 プロトコルを使用してバケットに記述されたオブジェクトが、MapReduceなどの Hadoop ジョブの対象になることを意味します。同様に、HDFS で書き込まれたディレクトリとファイルを、S3 クライアントを使用して読み取り変更することができます。S3 を使用して書き込まれたデータにファイルとしてアクセスするには、バケット管理者がバケットにデフォルトグループを設定し、そのグループが所有するファイルとディレクトリのデフォルト権限を設定します。S3 での作成時に、オブジェクトにデフォルトの UNIX グループを割り当てます。これにより、オブジェクトは所有者およびグループメンバーシップとグループ権限を所有するため HDFS が Hadoop クラスタからアクセスできます。HDFS を使用して作成され、S3 プロトコルを使用してアクセスされるファイルは、デフォルト権限の影響を受けません。デフォルト権限が適用されるのは、S3 プロトコルを使用して作成されるオブジェクトのみであるためです。

プロキシユーザーECS HDFSは、Hadoop プロキシユーザーの使用をサポートします。プロキシユーザーにより、Hadoop ユーザーは、別のユーザーに代わってジョブを送信したり、HDFSにアクセスしたりできます。プロキシユーザー機能は、実行可能プログラムの権限設定による識別に従って、あるユーザーが別のユーザーの ID でコマンドを実行する UNIX/Linux の［有効ユーザー］機能と比較することができます。ネームスペース（またはバケット）単位の安全な偽装のために、プロキシユーザーを構成します。プロキシユーザーは、シンプルモードおよび Kerberos モードでサポートされます。どちらのモードでも、管理者は hadoop.proxyuser.*.*プロパティを使用してプロキシの偽装を制限することができます。

同等ユーザーECSは、3パートプリンシパルを 2パートプリンシパルに変換します。Kerberos プリンシパルは、一般に primary/instance@realm の形式をしています。インスタンスは必須ではないため、その場合は primary@realm プリンシパルがレルム内のすべてのホストに適用されます。インスタンスが指定されている場合、インスタンスは joe/[email protected] または joe/[email protected] のように特定のホストを指定するために使用されることがあります。この 2 つのプリンシパルのプライマリユーザー（joe）は同一ですが、指定されたホスト（host1 または host2）の認証のみが付与されます。

ECS HDFS の概要


このタイプのユーザープリンシパルには、高度なセキュリティを提供することをお勧めします。ECS の立場からすると、各プリンシパルを ECS に追加する必要があります。これは非常に煩雑なため、同等ユーザー機能により、3パートプリンシパルが使用されている場合でも、2パートプリンシパル（primary@realm）を使用して ECS認証を実行することが可能です。

シンプルな Hadoop クラスターから Kerberos Hadoop クラスターへの移行

ECSは、シンプルな Hadoop環境から Kerberos によって保護された Hadoop環境への移行をサポートします。シンプルなセキュリティを使用する Hadoop環境に ECS HDFS を統合すると、Hadoop ユーザーによって作成されたファイルとディレクトリ、およびプロセスは、安全でないユーザーによって所有されます。その後 Hadoop クラスタを Kerberos セキュリティの使用に移行すると、安全でないユーザーはECS HDFS に書き込まれたファイルとディレクトリにアクセスできなくなります。ECS には短い名前と Kerberos プリンシパル間のマッピングを可能にする移行機能が組み込まれており、マップ済みの Kerberos プリンシパルから、安全でない短い名前によって所有されているファイルにアクセスすることができます。短い名前のユーザーによって書き込まれたファイルが少数しかない場合は、Kerberos プリンシパルによって所有されるように変更（chown を使用）した方が良いかもしれません。しかしファイル数が多い場合は、この移行機能を使用すれば、所有権を変更する必要がなくなります。この機能はバケットには実装されておらず、ユーザーによるアクセスに依存している場合に Kerberosプリンシパルからアクセスできるようにするには、バケット ACL を変更する必要があります。ただし、主に、アクセスできるようにするためにグループメンバーシップを使用している場合は、バケット ACL を変更する必要はありません。ECS では、グループを使用して、バケット、ファイル、ディレクトリへのアクセスを簡素化することができます。グループは常に UNIX の簡単な名前を使用するため、バケット、ファイル、ディレクトリに関連づけられたグループ名は、シンプルなクラスタまたは Kerberos クラスタからアクセスする場合と同じです。シンプルな環境からアクセスする場合、グループメンバーシップは UNIX マシンから決定されます。Kerberized クラスタからアクセスする場合は、マッピングを割り当てることでグループメンバーシップを構成できます。グループ名のマッピングについては、グループ名のマップ（151 ページ）を参照してください。AD認証情報を使用する場合、AD プリンシパルと UNIX プリンシパル間のマッピングはドメインサフィックスを削除することによって実現されます。このためユーザー [email protected]は hdfs になります。これは、[email protected] から hdfs へのマッピングが可能な Kerberos プリンシパルを使用しているときほど柔軟ではありません。Active Directory のグループを使用する場合は、グループのメンバーシップが確認できるように、ECS で認証プロバイダーを構成する必要があります。

Hadoop Kerberos認証モードKerberos と ECS Active Directory サーバが統合されると、Kerberos レルムからユーザーの単一のネームスペースが提供され、kinit で認証された Hadoop ユーザーが認証済み ECS ユーザーとして認識されます。Kerberos モードで稼働している Hadoop クラスタでは、Kerberos レルムから Active Directoryレルムへの一方向のレルム間信頼関係を使用して、ECS ユーザーを認証する必要があります。core-site.xml ファイル内の以下の ID変換プロパティが、Hadoop と ECS間のユーザー変換を正しく行うために使用されます。

ECS HDFS の概要

シンプルな Hadoop クラスターから Kerberos Hadoop クラスターへの移行 129

l fs.permissions.umask-mode：値を「022」に設定します。l fs.viprfs.auth.anonymous_translation：値を CURRENT_USER に設定しま

す。l fs.viprfs.auth.identity_translation：ユーザーのレルムが自動検出されるよ

うに、値を CURRENT_USER_REALM に設定します。さらに、core-site.xml ファイル内の以下のプロパティを設定して、サービスプリンシパルを定義する必要があります。l viprfs.security.principal：vipr/[email protected]、ここで REALM.COM

には Kerberos レルム名が入ります。

ファイルシステムとの対話操作ECS HDFS と直接対話操作を行う場合、標準の HDFS ファイルシステムとの対話操作に比べて、次のような相違が生じることがあります。l ファイルシステムを DistributedFileSystem のインスタンスと想定しているアプリケーションの場

合は、正しく動作しません。組み込み型の HDFS実装に対して動作するようにハードコーディングされているアプリケーションは、ECS HDFS を使用するように構成を変更する必要があります。

l ECS HDFSはデータのチェックサムをサポートしません。l listCorruptFileBlocks関数を使用する場合、ECS HDFS には破損ブロックという概念がな

いため、すべてのブロックが正常であると報告されます。l レプリケーション係数は常に定数 N と報告されます。ここで、N = 1 です。データは ECS SLA に

よって保護されます。Hadoop レプリケーションではありません。

サポートされる Hadoop アプリケーションECSHDFSは、Hadoop エコシステムの大部分のアプリケーションをサポートしています。

Hadoop エコシステムの次のアプリケーションがサポートされています。l YARN

l MapRedeuce

l Pig

l Hive

l Spark

l Zookeeper

l Ambari

l Sqoop

l Flume

ECS HDFS の概要


第 7章

ECS HDFS を使用したシンプルな Hadoop クラスタの構成

l シンプルな Hadoop クラスタと ECS HDFS の統合....................................................132l Ambari を使用した Hortonworks HDP のインストール.............................................132l ECS ポータルを使用した HDFSバケットの作成........................................................134l ECS HDFS と Hadoop の統合の計画....................................................................141l ECS HDFS インストールおよびサポートパッケージの取得........................................... 141l ECS HDFS クライアントライブラリの導入.................................................................142l ECS クライアントプロパティの構成.......................................................................... 143l Hive の設定....................................................................................................... 144l ECS への Hadoop アクセスの確認.........................................................................145l バケットのセキュリティ保護......................................................................................146l HDFS から ECSバケットへのデフォルトファイルシステムの再配置............................... 147

ECS HDFS を使用したシンプルな Hadoop クラスタの構成 131

シンプルな Hadoop クラスタと ECS HDFSの統合ECS ストレージインフラストラクチャと ECS HDFS を使用するように Hadoop ディストリビューションを構成することができます、本稿の統合手順を実行するには、以下が必要です。l Hadoop ディストリビューションとその関連ツールに関する実用的な知識。l Hadoop ノードにログインし、Hadoop のシステムファイルを変更したり、Hadoop サービスを開

始/停止したりできるようにするための Hadoop認証情報。次のステップに従う必要があります。1. Ambari を使用した Hortonworks HDP のインストール（132 ページ）2. ECS ポータルを使用した HDFSバケットの作成（134 ページ）3. ECS HDFS と Hadoop の統合の計画（141 ページ）4. ECS HDFS インストールおよびサポートパッケージの取得（141 ページ）5. ECS HDFS クライアントライブラリの導入（142 ページ）（ECS用の Ambari Hortonworks

を使用した場合は、必要ありません）6. ECS クライアントプロパティの構成（143 ページ）7. ECS への Hadoop アクセスの確認（145 ページ）8. HDFS から ECSバケットへのデフォルトファイルシステムの再配置（147 ページ）構成が完了すると、Hadoop クラスタのデフォルトのファイルシステム内にあるファイルが、ECSバケット内のファイルにマップします。たとえば、デフォルトファイルシステム上の/foo/barはviprfs://<bucket_name>.<namespace>.<federation_name>/foo/bar にマップします。

Ambari を使用した Hortonworks HDPのインストールAmbari サーバをインストールし、これを使用して Hortonworks HDP をインストールします。

以下の処理手順では、Ambari サーバをインストールして設定するための基本的なコマンドを説明します。Ambari サーバをインストールする方法の詳細については、Hortonworks のマニュアルを参照してください。手順

1. Ambari リポジトリをダウンロードします。

wget -nv http://public-repo-1.hortonworks.com/ambari/centos7/2.x/updates/2.4.2.0/ambari.repo -O /etc/yum.repos.d/ambari.repo

2. Ambari サーバーをインストールします。

yum install -y ambari-server

3. Ambari サーバを設定します。

ambari-server setup -s



https://docs.hortonworks.com/HDPDocuments/Ambari-2.4.2.0/bk_ambari-installation/content/ch_Getting_Ready.html

4. Ambari サーバを開始します。

ambari-server start

5. http://ambari.example.com:8080/を参照します。6. ［Select Stack］ページで、Hadoop のバージョン HDP 2.5 を選択し、OSバージョンを選

択します。7. 次の例に示すように、有効化する Hadoop サービスを選択します。


Ambari を使用した Hortonworks HDP のインストール 133

8. インストールウィザードを完了します。

ECSポータルを使用した HDFSバケットの作成ECS ポータルを使用して、HDFS で使用するために構成したバケットを作成します。



はじめにネームスペース管理者またはシステム管理者の役割に割り当てられていることを確認します。ネームスペース管理者は、自分のネームスペースのバケットを作成できます。システム管理者は、どのネームスペースに属するバケットでも作成できます。Hadoop のユーザーとサービスに HDFS ファイルシステム（バケット）へのアクセス権があること、ファイルとディレクトリに適切なユーザーおよびグループからアクセスできることを確認する必要があります。これは、次の方法で行います。l バケットの所有者を Hadoop のスーパーユーザー（通常 hdfs または [email protected]）

と同じにします。l グループメンバーシップによるバケットへのアクセスを有効化します。

n バケットにデフォルトグループを割り当てます。このとき、カスタムグループ ACL が自動的に割り当てられます。

n バケットの作成後、アクセス権を必要とするその他のグループにカスタムグループ ACL を追加します。

l バケットにユーザー ACL を追加して、個人のアクセス権を有効化します。l HDFS へのスーパーユーザーアクセス権が必要な Hadoop ユーザーが、Hadoop スーパーグル

ープの一員になっていることを確認します。オブジェクトプロトコルを使用してバケットに書き込まれたオブジェクトデータに HDFS からアクセスする場合は、そのバケットにデフォルトグループが割り当てられていること、そのグループにデフォルトのファイルおよびディレクトリ権限が設定されていることを確認する必要があります。ユーザーおよび権限の詳細については、ファイルシステムとしてのバケットへのアクセス（126 ページ）および Hadoop権限と ECSバケット権限の例（139 ページ）を参照してください。

手順1. ECS Portal で、［Manage］ > ［Buckets］ > ［New Bucket］を選択します。2. ［New Bucket］ページの［Name］フィールドに、バケットの名前を入力します。

URI Java クラスでサポートされていないため、アンダースコアはバケット名に使用しないでください。たとえば、viprfs://my_bucket.ns.site/は無効な URI であり、Hadoopに認識されないため動作しません。

3. ［Namespace］フィールドで、バケットの所属先にするネームスペースを選択します。4. ［Replication Group］フィールドで、レプリケーショングループを選択するか、空白のままに

してネームスペース用のデフォルトレプリケーショングループを使用します。5. ［Bucket Owner］フィールドに、バケット所有者の名前を入力します

HDFSバケットの場合はバケットの所有者は通常 hdfs です。Kerberosバケットの場合は、[email protected] です。Hadoop hdfs ユーザーには、HDFS のスーパーユーザー権限が必要です。このためには、バケットの所有者を hdfs にします。その他にも、スーパーユーザー権限を必要とする Hadoop ユーザーがいるかもしれません。こうしたユーザーにはグループを割り当て、そのグループをスーパーユーザーグループにすることによって権限を付与します。

6. ［CAS］を有効化しないでください。


ECS ポータルを使用した HDFSバケットの作成 135

HDFS として使用するバケットは、CAS として使用できません。［File System］を有効化すると、［CAS］フィールドは無効化されます。

7. その他の必要なバケット機能を有効化します。次の機能は、HDFSバケット上で有効化できます。l Quota

l Server-side Encryption

l Metadata Search

l Access During Outage

l Compliance（注を参照）l Bucket Retention

これらの各設定の詳細と構成方法については、ECS製品ドキュメントページ内の使用可能な「ECS管理ガイド」を参照してください。

コンプライアンスが有効になったバケットには、HDFS プロトコルを使用して書き込むことはできません。ただし、オブジェクトプロトコルを使用して書き込まれたデータは、HDFS から読み取ることができます。

8. ［File System］フィールドで［Enabled］を選択します。

有効化すると、ファイルシステム/バケットのデフォルトグループの設定と、バケット内に作成されたファイルとディレクトリのグループ権限の割り当てを行うフィールドが使用可能になります。これらのフィールドを、次の例に示します。

9. ［Default Bucket Group］フィールドにデフォルトバケットグループの名前を入力します。

このグループは、HDFS のルートファイルシステムに関連づけられたグループであり、グループのメンバーである Hadoop ユーザーは HDFS にアクセスできるようになります。

デフォルトグループは、HDFS上のデータにアクセスする必要があるサービスが属しているhdfs、hadoopなどのグループの可能性もありますが、Hadoop の構成に意味があるもの




であればグループ名は何でもかまいません。たとえば管理者が、バケットにアップロードされたすべての S3 ファイルを、グループ S3DataUsers に割り当てるとします。このとき、すべてのS3 ファイルにこのグループが割り当てられます。Hadoop ノードでは、Hadoop管理者のユーザーがグループ S3DataUsers のメンバーになります。S3DataUsersは、Linux グループでも、Active Directory グループでもかまいません。ファイルがアップロードされてそのグループに割り当てられているため、Hadoop ユーザーは S3 データにアクセスすることができます。

バケットの作成時にデフォルトのグループを指定する必要があります。そうしない場合、後からファイルシステムの所有者が Hadoop からグループを割り当てる必要があります。

10. ［Group File Permissions］フィールドと［Group Directory Permissions］フィールドで、オブジェクトプロトコルを使用してバケットで作成されたファイルとディレクトリのデフォルトの権限を設定します。これらの設定は、オブジェクトプロトコルを使用して作成されたオブジェクトに UNIX グループ権限を適用するために使用します。これらの権限は、オブジェクトまたはディレクトリがHadoop で一覧表示される場合に、HDFS グループ（［Default Bucket Group］）に適用されます。ファイルシステムへのデフォルトグループと権限の設定に関する詳細情報については、マルチプロトコル（クロスヘッド）アクセス（128 ページ）を参照してください。

a.［Group File Permissions］フィールドで、適切な権限ボタンを選択します。通常は、［Read］権限と［Execute］権限を設定します。

b.［Group Directory Permissions］フィールドで、適切な権限ボタンを選択します。通常は、［Read］権限と［Execute］権限を設定します。

11. ［Save］をクリックしてバケットを作成します。

カスタムグループバケット ACL の設定ECS ポータルのバケットのグループ ACL を設定し、ユーザーのグループ（カスタムグループ ACL）、個々のユーザー、または両方の組み合わせのバケット ACL を設定できます。たとえば、ユーザーのグループにはバケットへのフルアクセスを付与しておき、グループの個別のユーザーに制限をつけたり、拒否したりすることができます。はじめにl この操作には、ECS でのシステム管理者またはネームスペース管理者ロールが必要です。l システム管理者は、どのネームスペースのバケットでもグループ ACL設定を編集できます。l ネームスペース管理者は、管理者となっているネームスペース内のバケットのグループ ACL設

定を編集できます。［Custom Group ACLs］で、グループを定義し、権限を割り当てることができます。バケットにグループを割り当てる主な理由は、たとえばバケットを NFS または HDFS で使用できるようにする場合などのように、ファイルシステムとしてのバケットへのアクセスをサポートするためです。UNIX グループのメンバーは、ファイルシステム（NFS または HDFS を使用）としてアクセスする場合、バケットにアクセスできます。手順

1. ECS Portal で、［Manage］ > ［Buckets］を選択します。

2. ［Bucket Management］ページで、編集するバケットをテーブルで見つけ、［Edit ACL］アクションを選択します。

3. ［Custom Group User ACLs］をクリックし、カスタムグループの ACL を選択します。4. ［Add］をクリックします。


カスタムグループバケット ACL の設定 137

［Edit Custom Group］ページの表示を、次のスクリーンショットに示します。

5. ［Edit Custom Group］ページの［Custom Group Name］フィールドで、グループの名前を入力します。入力する名前は、UNIX/Linux グループの名前でも、Active Directory グループの名前でもかまいません。

6. グループの権限を設定します。少なくとも、［Read］、［Write］、［Execute］、［Read ACL］を割り当てる必要があります。


ユーザーバケット ACL の設定ECS Portal でバケットのユーザー ACL を設定できます。ECS ではバケット所有者に自動的に権限が割り当てられます。その他の Hadoop ユーザーにユーザー ACL を割り当てれば、バケット/ファイルシステムにアクセスできるようになります。カスタムグループ ACL に割り当てられているグループのメンバーになって、バケットへのアクセス権を得ることもできます。はじめにl バケットの ACL を編集するには、ECS ネームスペース管理者またはシステム管理者である必

要があります。l ネームスペース管理者は、自分のネームスペースに属するバケットの ACL設定を編集できま

す。l システム管理者は、どのネームスペースに属するバケットでも ACL設定を編集できます。



手順1. ECS Portal で、［Manage］ > ［Buckets］を選択します。

2. ［Bucket Management］ページで、編集するバケットをテーブルで見つけ、［Edit ACL］アクションを選択します。

3. ［Bucket ACL Management］ページで、［User ACL］タブが選択されていることを確認します。これは、デフォルトです。

4. ［User ACL］タブで、権限が割り当て済みのユーザーの権限を編集したり、権限を割り当てたいユーザーを追加したりすることができます。l 権限が割り当て済みのユーザーの ACL権限を設定（または削除）するには、ACL テーブルの［Action］列で［Edit］（または［Remove］）を選択します。

l 権限を割り当てたいユーザーを追加するには、［Add］をクリックし、権限を適用するユーザーのユーザー名を入力します。ユーザーに適用する権限を指定します。

バケットの所有者として設定したユーザーには、デフォルトの権限がすでに割り当てられています。

次の例のバケットは hdfs ユーザーによって所有されており、hdfs には所有者としてフルコントロールが付与されています。フルコントロール権限では、Hadoop/UNIX環境での読み取り、書き込み、実行が可能です。ユーザー sally には、バケットにアクセスする読み取りおよび実行の権限が付与されています。

ACL権限の詳細については、ECS製品ドキュメントページ内の使用可能な「ECS管理ガイド」を参照してください。


Hadoop権限と ECSバケット権限の例ここでは、Hadoop ユーザー/グループと、ECS ユーザー ACL およびカスタムグループ ACL を通してバケットにアクセスする権限を割り当てられたユーザー/グループ間の関係の例を説明します。

ECS では、バケットの作成時にバケット所有者とデフォルトグループに ACL を自動で割り当てます。デフォルトグループは HDFS を使用してアクセスした場合のグループ割り当てです。バケットには常に所有者が必要ですが、デフォルトグループをバケットに割り当てる必要はありません。バケット所有者以外のユーザーおよびグループ（カスタムグループ）には、バケットに対する ACL を割り当てることができます。この方法で割り当てられている ACLは、Hadoop ユーザーの権限として解釈されます。


Hadoop権限と ECSバケット権限の例 139


表 24 シンプル Hadoop クラスタでのファイルシステムアクセスのバケット権限例

Hadoop ユーザーおよびグループバケットの権限バケット/ファイルシステムアクセス

グループ ACL を使用したバケットアクセス

ユーザー（サービス）hdfs、mapred、yarn、hive、pig

ユーザー（アプリケーション）sally、fred

グループhdfs（hdfs）hadoop（hdfs、mapred、yarn、hive、pig）users（sally、fred）

スーパーグループhdfs

バケット所有者hdfs

デフォルトグループ

カスタムグループ ACL

hadoop、users、hive、spark（フルコントロール）

ユーザー ACL

hdfs（所有者）

カスタムグループ ACLは ECS Portal でバケット上に設定する必要があります。hadoop、users、hive、spark のグループに対するフルコントロールをバケット/ルートファイルシステム上に割り当てます。

この例では、hdfs がスーパーユーザー（namenode

を開始するユーザー）であると仮定しています。

S3 ユーザーが作成したバケット（クロスヘッドアクセス）

ユーザー（サービス）hdfs、mapred、yarn、hive、pig

ユーザー（アプリケーション）sally、fred

グループhdfs（hdfs）hadoop（hdfs、mapred、yarn、hive、pig）users（sally、fred）


バケット所有者s3user

デフォルトグループhadoop

（グループファイル権限Read、Write

グループディレクトリ権限：Read、Write、Execute）


hadoop（デフォルト）

ユーザー ACL

s3user（所有者）、sally、fred

S3 ユーザーが作成したオブジェクトに HDFS からファイルとしてアクセスするには、Hadoop ユーザーおよびサービスにグループメンバーシップによるファイルへの権限を持たせるために、デフォルトグループ（hadoop）を定義する必要があります。

デフォルトグループには、バケット/ファイルシステムのカスタムグループ ACL が自動的に割り当てられます。次の例では、hadoop がデフォルトグループに設定されており、ルートファイルシステムの権限は 777

であることを示しています。

drwxrwxrwx+ - s3user hadoop 0 2015-12-09 12:28 /

ユーザー ACL を追加するか、またはユーザーが所属するグループにカスタムグループ ACL を追加して、ユーザーにアクセス権を付与することができます。

表 25 Kerberos認証を使用する Hadoop クラスタでのファイルシステムアクセスのバケット権限例

Hadoop ユーザーバケットの権限バケット/ファイルシステムアクセス

ユーザー（サービス）[email protected]、[email protected]、[email protected]、[email protected]、[email protected]

バケット所有者[email protected]

デフォルトグループhadoop

hadoop および users グループがバケット/ルートファイルシステム上で権限を持てるように、Portal でバケットに設定されたカスタムグループ ACL。

バケットに安全にアクセスできるように、Hadoop クラスタのユーザー情報が ECS から利用できる必要があります。この情報はバケットメタデータを使用して提



表 25 Kerberos認証を使用する Hadoop クラスタでのファイルシステムアクセスのバケット権限例

Hadoop ユーザーバケットの権限バケット/ファイルシステムアクセス

ユーザー（アプリケーション）[email protected]、[email protected]、[email protected]

グループhdfs（[email protected]）hadoop（[email protected]、[email protected]、[email protected]、[email protected]、[email protected]）users（[email protected]、[email protected]）



hadoop（デフォルト）、users

ユーザー ACL

[email protected]（所有者）

供されます。メタデータファイルの例は安全なバケットメタデータ（186 ページ）にあります。

ECS HDFS と Hadoopの統合の計画次の表を使用して、統合を成功させるために必要な情報が揃っていることを確認してください。

表 26 ECS HDFS構成の動作条件

構成要素対処方法

Hadoop クラスタークラスターがインストールされ動作していることを確認します。

この後の手順で使用するために管理者認証情報を記録します。

ECS クラスター：ECS ノード

この後の手順で使用するために、ECS のノードの IP アドレスを記録します。

ECS クラスター：バケット HDFS では、HDFS対応のバケットが ECS レプリケーショングループ内に作成されていることを必要とします。バケットには、ネームスペースとバケット名を使用して、ファイルシステムとしてアクセスします。

バケットの名前を記録します。

ECS クラスター：テナントのネームスペース

テナントのネームスペースが構成されていることを確認します。名前を記録します。

ECS HDFS インストールおよびサポートパッケージの取得ECS HDFS クライアントライブラリと HDFS サポートツールは、HDFS Client ZIP ファイルhdfsclient-<ECS version>-<version>.zip に入っています、このファイルは、ECSサポートページ（support.emc.com）からダウンロードできます。


ECS HDFS と Hadoop の統合の計画 141

ZIP ファイルには、/playbooks および/client ディレクトリが含まれています。ファイルを解凍する前に、ZIP ファイルの内容を保存するためのディレクトリを作成して（解凍ツールで作成できる場合もあります）、そのディレクトリに内容を展開します。ファイルを展開すると、ディレクトリ内に以下のものが得られます。l /playbooks：ECS HDFS と通信する安全な Hadoop環境を構成するための Ansible プ

レイブックが含まれています。l /client：以下のファイルが含まれます。

n ECS クライアントライブラリ（ViPPRFS）JAR ファイル（viprfs-client-<ECSversion>-hadoop-<Hadoop version>.jar）：さまざまな Hadoop ディストリビューションを構成するために使用されます。

ECS HDFS クライアントライブラリの導入ECS クラスタ内の各クライアントノードのクラスパスに Hadoop HDFS クライアントライブラリ JAR を設定するには、次の手順を実行します。はじめにECS サポートページから、使用する Hadoop ディストリビューション用の ECS HDFS クライアントライブラリを入手します。ECS HDFS インストールおよびサポートパッケージの取得（141 ページ）を参照してください。HDFS クライアントライブラリは、次の命名規則 viprfs-client-<ECS version>-hadoop-<Hadoop version>.jar を使用します。これらのリリースで使用するための JAR ファイルを、次の表に一覧表示します。

表 27 ECS HDFS クライアントライブラリ

Hadoop ディストリビューション

Version ECS HDFS JAR

Hortonworks HDP 2.5 viprfs-client-<ECSバージョン>-hadoop-2.7.jar

l ECS の新しいバージョンにアップグレードする場合は、アップグレード先のリリースには、ECSHDFS クライアントライブラリを導入する必要があります。

手順1. すべての Hadoop ノードに対してパスワードを必要としない SSH アクセス権を持つノードにログインします。

2. classpath コマンドを実行して、クラスパス内のディレクトリのリストを取得します。# hadoop classpath

3. 次の手順を実行することで、すべての Hadoop ノードにクライアント JAR ファイルを展開します。a. すべての Hadoop マスターノードの IP アドレスまたは完全修飾ドメイン名を 1行につき

1 つリストした masters という名前のテキストファイルを作成します。

b. すべての Hadoop ワーカーノードの IP アドレスまたは完全修飾ドメイン名を 1行につき1 つリストした workers という名前のテキストファイルを作成します。



c. すべてのノードにディレクトリ/usr/lib/hadoop/lib を作成します。次のコマンドを使用します。

# cat masters workers | xargs -i -n 1 ssh root@{} mkdir -p /usr/lib/hadoop/lib

d. 次のコマンドを使用してすべてのノードに ECS クライアント jar をコピーします。

cat masters workers | xargs -i -n 1 scp viprfs-client-3.1.0.0-hadoop-2.7.jar root@{}:/usr/lib/hadoop/lib/

ECS クライアントプロパティの構成Ambari を使用して、ECS クライアントで必要な次の構成プロパティを設定できます。

core-site.xmlパラメーターの詳細については、ECS HDFS の Hadoop core-site.xml プロパティ（180 ページ）を参照してください。

表 28 ECS アクセスを可能にする Hadoop の構成

Hadoop の場所

プロパティ値

コアサイト fs.viprfs.impl com.emc.hadoop.fs.vipr.ViPRFileSystem

fs.AbstractFileSystem.viprfs.impl com.emc.hadoop.fs.vipr.ViPRAbstractFileSystem

fs.viprfs.auth.identity_translation NONE

fs.viprfs.auth.anonymous_translation LOCAL_USER

fs.vipr.installations federation1など任意の名前にすることができ、$FEDERATION として参照されます。複数の独立した ECS フェデレーションがある場合は、コンマで区切られた複数の値を入力します。

fs.vipr.installation.$FEDERATION.hosts ローカルサイト内の各 ECS ホストの完全修飾ドメイン名または IP アドレスのコンマ区切りリスト

fs.vipr.installation.$FEDERATION.hosts.resolution dynamic

fs.vipr.installation.$FEDERATION.resolution.dynamic.time_to_live_ms

900000

hdfs サイト fs.permissions.umask-mode 022

yarn サイト yarn.application.classpath 末尾に次の内容を追加します。

/usr/lib/hadoop/lib/*


ECS クライアントプロパティの構成 143

表 28 ECS アクセスを可能にする Hadoop の構成（続き）

Hadoop の場所

プロパティ値

mapred サイト mapreduce.application.classpath 末尾に次の内容を追加します。


tez サイト tez.cluster.additional.classpath.prefix 末尾に次の内容を追加します。


HDFS hadoop-env テンプレート末尾に次の内容を追加します。

export HADOOP_CLASSPATH=${HADOOP_CLASSPATH}:/usr/lib/hadoop/lib/*

Spark spark-env テンプレート末尾に次の内容を追加します。

export SPARK_DIST_CLASSPATH="${SPARK_DIST_CLASSPATH}:/usr/lib/hadoop/lib/*:/usr/hdp/current/hadoop-client/client/guava.jar"

Hiveの設定この処理手順で説明している追加のステップは Hive を構成するために必要です。

はじめに

Hive を使用する場合は、Hive のメタストアウェアハウスが ViPRFS の場所に向けられていることも確認する必要があります。Hive のメタストアの場所を識別するのに mysql を使用していると仮定した場合は、mysql を開始し、Hive データベースに移動して、DBS テーブルの内容を表示し、次のように設定します。手順

1. Hive で templeton が使用されている場合は、次のプロパティを変更する必要があり、これらのプロパティはすでに定義されています。

表 29 Hive templeton構成

Hadoop の場所プロパティ値（例）

詳細 webhcat サイト templeton.hive.archive viprfs://hdfsBucket2.s3.site1/hdp/apps/${hdp.version}/hive/hive.tar.gz



表 29 Hive templeton構成（続き）


templeton.pig.archive viprfs://hdfsBucket2.s3.site1/hdp/apps/${hdp.version}/pig/pig.tar.gz

templeton.sqoop.archive viprfs://hdfsBucket2.s3.site1/hdp/apps/${hdp.version}/sqoop/sqoop.tar.gz

templeton.streaming.jar viprfs://hdfsBucket2.s3.site1/hdp/apps/${hdp.version}/mapreduce/hadoop-streaming.jar

2. mysql を開始します。

[root@hdfs-pansy2 lib]# mysql -u hive -pEnter password: Welcome to the MySQL monitor. Commands end with ; or \g.

3. Hive データベースに移動します。

mysql> use hive;Reading table information for completion of table and column namesYou can turn off this feature to get a quicker startup with -A

4. データベースの内容を表示します。

select * from DBS;+------+-------------+-----------------------------------+--------+-------+------+|DB_ID | DESC | DB_LOCATION_URI | NAME | OWNER | OWNER|| | | | | _NAME | _TYPE|+------+-------------+-----------------------------------+--------+-------+------+| 1 | Default Hive| hdfs://hdfs-pansy1.ecs.lab.emc. |default |public |ROLE || | database | com:8020/apps/hive/warehouse | | | || | | | | | || 6 | NULL | viprfs://hdfsbucket.ns.Site1/ |retail |hdfs |USER || | | apps/hive/warehouse/retail_demo.db| _demo | | |+------+-------------+-----------------------------------+--------+-------+------+2 rows in set (0.00 sec)

5. データベースを変更します。

mysql> update DBS set DB_LOCATION_URI='viprfs://hdfsbucket3.ns.Site1/apps/hive/warehouse' where DB_ID=1;Query OK, 1 row affected (0.00 sec)Rows matched: 1 Changed: 1 Warnings: 0

ECS への Hadoop アクセスの確認ECSバケットへのアクセスを確認する必要があります。


ECS への Hadoop アクセスの確認 145

Hadoop のすべてのクライアントサービスが開始されたら、Hadoop CLI を使用して ECSバケットにアクセスできることを確認します。URI の形式は、viprfs://bucket.namespace.federation/です。URI viprfs://hive-warehouse-1.ns1.federation1/を持つバケットの場合は、次のコマンドを使用してディレクトリリストを試みることができます。

[root@mycluster1-master-0 ~]# hdfs dfs -ls viprfs://hive-warehouse-1.ns1.federation1/

新しいバケットは空になり、何も返されません。同じバケットに対する次のコマンドでは、空のファイルが作成され、ファイルを表示するディレクトリ一覧表示が実行されます。

[root@mycluster1-master-0 ~]# hdfs dfs -touchz viprfs://hive-warehouse-1.ns1.federation1/hive-warehouse-1[root@mycluster1-master-0 ~]# hdfs dfs -ls viprfs://hive-warehouse-1.ns1.federation1/

バケットのセキュリティ保護バケット ACL の構成に加えて、バケットの作成後すぐにルートディレクトリエントリーを作成し、セキュリティ保護する必要があります。はじめにこの手続きは、バケットの所有者、この例では hdfs として実行する必要があります。手順

1. バケットの所有者とデフォルトグループのみがバケットにアクセスできるように、ルートディレクトリオブジェクト ACL にモードビットを設定します。other グループは、すべての ECS HDFSクライアントユーザーを含むグループで、ルートディレクトリへのアクセスは許可されません。したがって、バケット内のファイルへのアクセスは許可されません。

[hdfs@hadoop-0 ~]$fs=viprfs://bucket.ns.fedhadoop fs -chmod 750 $fs/hadoop fs -chown hdfs:hdfs $fs/

2. setfacl コマンドを使用して、ルートディレクトリオブジェクト ACL に特定のグループとユーザーを追加する必要があります。これらの権限では、すべての HDFS API が確実に同一の実効権限を保持するように、バケットのカスタムグループ ACL が複製されることに注意してください。

hadoop fs -setfacl -m group:hadoop:r-x $fs/hadoop fs -setfacl -m group:users:r-x $fs/hadoop fs -setfacl -m group:hive:r-x $fs/hadoop fs -setfacl -m group:spark:r-x $fs/



3. 権限を確認します。

hadoop fs -ls -d $fs/drwxr-x---+ - hdfs hdfs 0 2017-08-22 20:44 viprfs://bucket.ns.fed/

hadoop fs -getfacl $fs/# file: viprfs://bucket.ns.fed/# owner: hdfs# group: hdfsuser::rwxgroup::r-xgroup:hadoop:r-xgroup:hive:r-xgroup:spark:r-xgroup:users:r-xmask::r-xother::---

HDFSから ECSバケットへのデフォルトファイルシステムの再配置システムは使用可能になって、うまく機能するように見えるかもしれませんが、HDFS をデフォルトのファイルシステムとして使用した構成はサポートされません。したがって、デフォルトファイルシステムをHDFS からルート ECSバケットに再配置する必要があります。この手続きでは、HDFS ファイルシステムから ECSバケットにすべてのファイルをコピーし、ECS バケットをデフォルトのファイルシステムとして設定します。手順

1. Ambari を使用して、HDFS、YARN、Zookeeper を除くすべてのサービスを停止します。2. DAS HDFS ファイルシステム上にあるすべての既存のファイルを ECSバケットにコピーしま

す。Hadoop の新規インストールには、デフォルトの Hadoop ファイルシステムに存在する必要がある重要なディレクトリがあります。DistCp を使用してファイルコピーを実行します。

[hdfs@mycluster1-master-0~]$ hadoop distcp -skipcrccheck -update -pugp -i / viprfs://mycluster1-root.ns1.federation/

3. Ambari を使用して次の設定を行います。

表 30 Hive の同時アクセスと ACID トランザクションを有効化する Hadoop の構成


HDFS の高度なコアサイト fs.defaultFS viprfs://<bucket_name>.<namespace>.<federation_name>例：viprfs://mycluster1-root.ns1.federation1


HDFS から ECSバケットへのデフォルトファイルシステムの再配置 147

表 30 Hive の同時アクセスと ACID トランザクションを有効化する Hadoop の構成（続き）


Spark の高度な spark デフォルト spark.eventLog.dir viprfs://<bucket_name>.<namespace>.<federation>/<spark-history>例：viprfs://mycluster1-root.ns1.federation1/spark-history

Spark の高度な spark デフォルト spark.history.fs.logDirectory viprfs://<bucket_name>.<namespace>.<federation>/<spark-history>例：viprfs://mycluster1-root.ns1.federation1/spark-history

4. Ambari を使用してすべてのサービスを停止および開始します。5. ディレクトリの権限が適切であることを確認します。DistCp でエラーが発生する場合は、必

要な権限が重要なディレクトリに適用されてない可能性あがります。次のコマンドにより適切な権限が設定されます。

[hdfs@mycluster1-master-0~]$hadoop fs -chmod 777 /apps/hive/warehousehadoop fs -chown hive:hdfs /apps/hive/warehousehadoop fs -chmod -R 770 /user/ambari-qahadoop fs -chown -R ambari-qa:hdfs /user/ambari-qa



第 8章

ECS HDFS を使用した安全な（Kerberos対応）Hadoop クラスタの構成

l 安全な Hadoop クラスタと ECS HDFS の統合 .......................................................150l シンプルなクラスターから Kerberos クラスターへの移行のプランニング............................150l グループ名のマップ................................................................................................ 151l ECS サービスプリンシパルを使用した ECS ノードの構成............................................151l Ambari を使用した Kerberos の有効化................................................................ 155l メタデータを使用した ECSバケットの保護............................................................... 156l ECS クライアントプロパティの再構成...................................................................... 160l Hadoop サービスの開始と ECS への Hadoop アクセスの確認................................... 160

ECS HDFS を使用した安全な（Kerberos対応）Hadoop クラスタの構成 149

安全な Hadoop クラスタと ECS HDFSの統合Kerberos を使用してセキュリティが確保される既存の Hadoop ディストリビューションを ECSHDFS と統合できます。Kerberos をオプションで有効化する前に、安全でない Hadoop と ECS の完全なインストールを実行する必要があります。統合の手順を実行する前に、次の操作を行う必要があります。l Kerberos KDC（キー配布センター）がインストールされており、Hadoop サービスプリンシパル

の認証を処理するように構成されていることを確認してください。ECS ユーザーの認証にActive Directory を使用する場合は、Kerberos レルムと ECS ユーザーレルムの間にレルム間信頼関係を設定する必要があります。Kerberos KDC をセットアップする方法および信頼を構成する方法は、Kerberos の構成について（174 ページ）を参照してください。

l HDFS ファイルシステムのバケットを作成済みであることを確認してください（ECS ポータルを使用した HDFSバケットの作成（134 ページ）を参照）。

l 統合を計画するためのガイドラインを読んだことを確認します（ECS HDFS と Hadoop の統合の計画（141 ページ）を参照）。

l サポートパッケージをダウンロードしてインストールしたことを確認してください（ECS HDFS インストールおよびサポートパッケージの取得（141 ページ）を参照）。

ECS HDFS を安全な Hadoop クラスタと統合するには、次のタスクを実行します。1. シンプルなクラスターから Kerberos クラスターへの移行のプランニング（150 ページ）2. グループ名のマップ（151 ページ）3. ECS サービスプリンシパルを使用した ECS ノードの構成（151 ページ）4. メタデータを使用した ECSバケットの保護（156 ページ）5. ECS クライアントプロパティの再構成（160 ページ）6. Hadoop サービスの開始と ECS への Hadoop アクセスの確認（160 ページ）

シンプルなクラスターから Kerberos クラスターへの移行のプランニングECSは、シンプルなセキュリティを使用する Hadoop クラスターから、Kerberos によって保護されたHadoop クラスターへの移行をサポートします。シンプルな環境から安全な環境に移行する場合は、シンプルな Hadoop クラスターから KerberosHadoop クラスターへの移行（129 ページ）を参照してください。一般には、ECS の移行機能によってファイルとディレクトリが Kerberos ユーザーからシームレスにアクセスできるようになります。ただし、次の点に注意してください。l Hadoop クラスタを保護する Ambari ウィザードは、最後のステップで Hadoop サービスを開始

するときにエラーをレポートします。これは予期された動作です。安全のために ECSバケットを再構成すると、Hadoop サービスを開始できます。

l ユーザーとプロセスがバケットにアクセスできるには、バケットにアクセスできるグループのメンバーである必要があります。そうでない場合は、Kerberos ユーザーがアクセスできるように、バケットのACL を変更する必要があります。



グループ名のマップhdfs、hiveなどの Hadoop サービスプリンシパルのために、ECS からグループの詳細をマップできる必要があります。Active Directory を使用している場合は、バケットメタデータと ActiveDirectory の 2 つの異なるソースでグループ情報を見ることができます。ECSは、/opt/storageos/conf/hdfssvc.conf設定ファイル（[hdfs.fs.request]セクション）の構成パラメーター設定で、どちらのソースを使用するかを決定します。ECS で、Active Directory ではなくバケットメタデータからグループ情報を入手するようにするには（該当する場合）、次のようにパラメーターを定義します。

[hdfs.fs.request]prefer_secure_metadata_bucket_for_groups = true

ECS で、バケットメタデータではなく Active Directory からグループ情報を入手するようにするには、次のようにパラメーターを定義します。

[hdfs.fs.request]prefer_secure_metadata_bucket_for_groups = false

デフォルト値は true であるため、この値を定義しないと ECSは Kerberos プリンシパルのグループ詳細をバケットメタデータから入手します。すべての ECS ノードにすべての変更を適用する必要があり、すべてのノードで dataheadsvc を再開する必要があります。

ECS サービスプリンシパルを使用した ECS ノードの構成ECS サービスプリンシパルおよび対応する keytab ファイルは、各 ECS データノードに存在している必要があります。提供される Ansible プレイブックを使用してこれらのステップを自動化する必要があります。はじめにこの手順を完了する前に、以下の項目を準備しておく必要があります。l Ansible プレイブックへのアクセス。Ansible プレイブックを ECSHDFS ソフトウェアパッケージから

入手します。ECS HDFS インストールおよびサポートパッケージの取得（141 ページ）の説明に従います。

l IP アドレスを指定する ECS ノードのリスト。l KDC の IP アドレス。l このスクリプトを実行する DNS の解決が、Hadoop ホストの DNS の解決と同じであること。異

なっていると、vipr/_HOST@REALM が機能しません。ECS では、再利用可能な Ansible コンテンツを「role」と呼びます。これは python スクリプト、YAML ベースのタスクリスト、テンプレートファイルで構成されています。l vipr_kerberos_config：Kerberos用に ECS ノードを構成する。l vipr_jce_config：JCE ポリシーファイルをインストールして、無制限強度の暗号化用の

ECS データノードを構成する。l vipr_kerberos_principal：ECS ノード用のサービスプリンシパルを取得する。


グループ名のマップ 151

この手順では、Ansibleは ECS に付随してインストールされたユーティリティ Docker コンテナを使用して実行されます。手順

1. ECS ノード 1 にログインして、hdfsclient-<ECS version>-<version>.zip ファイルをノードにコピーします。例：/home/admin/ansible 。support.emc.com から直接パッケージを入手するには、wget を使用します。別のマシンにダウンロード済みの場合は、scp を使用できます。

2. hdfsclient-<ECS version>-<version>.zip ファイルを解凍します。このプロシージャのステップでは、viprfs-client-<ECS version>-<version>/playbooks/samples ディレクトリに格納されたプレイブックを使用します。ステップはviprfs-client-<ECS version>-<version>/playbooks/samples/README.md にも格納されています。

3. inventory.txt ファイル（playbooks/samples ディレクトリ内）を編集して、ECSデータノードと KDC サーバを参照します。

デフォルトのエントリーは次のとおりです。

[data_nodes]192.168.2.[100:200]

[kdc]192.168.2.10

4. oracle.com から［unlimited］ JCE ポリシーアーカイブをダウンロードして、viprfs-client-<ECS version>-<version>/playbooks/samples のUnlimitedJCEPolicy ディレクトリに展開します。

このステップは、強力な暗号化タイプを使用する場合にのみ実行してください。

Kerberosは、AES-256などの強力な暗号化タイプを使用するように構成できます。その場合は、を使用するように ECS ノード内の JRE を再構成する必要があります。

ポリシー

5. ECS ノード 1 でユーティリティコンテナを起動して、Ansible プレイブックがコンテナから使用できるようにします。a. ユーティリティコンテナのイメージをロードします。

例：

sudo docker load -i /opt/emc/caspian/checker/docker/images/utilities.txz

b. Docker イメージの ID を取得します。

例：

admin@provo-lilac:~> sudo docker images



イメージ ID が出力されます。

REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZEutilities 1.5.0.0-403.cb6738e 186bd8577a7a 2 weeks ago 738.5 MB

c. 起動して、ユーティリティイメージを入力します。例：

sudo docker run -v /opt/emc/caspian/fabric/agent/services/object/main/log:/opt/storageos/logs -v /home/admin/ansible/viprfs-client-3.0.0.0.85325.a05145b/playbooks:/ansible --name=ecs-tools -i -t --privileged --net=host 186bd8577a7a /bin/bash

この例では、Ansible プレイブックが圧縮解除された場所/home/admin/ansible/viprfs-client-3.0.0.0.85325.a05145b/playbooksは、ユーティリティコンテナ内の/ansible ディレクトリにマッピングされます。

6. コンテナ内の作業ディレクトリに変更します。例：

cd /ansible

7. krb5.conf ファイルを KDC から作業ディレクトリにコピーします。8. 提供された Ansible role をインストールします。

ansible-galaxy install -r requirements.txt -f

9. 必要に応じて generate-vipr-keytabs.yml を編集し、ドメイン名を設定します。例：

[root@nile3-vm22 samples]# cat generate-vipr-keytabs.yml---#### Generates keytabs for ViPR/ECS data nodes.### - hosts: data_nodes serial: 1 roles: - role: vipr_kerberos_principal kdc: "{{ groups.kdc | first }}" principals: - name: vipr/[email protected] keytab: keytabs/[email protected]

この例では、デフォルト値（vipr/[email protected]）が（vipr/[email protected]）で置き換えられており、ドメインは MA.EMC.COM です。

10. 次のコマンドを実行します。

export ANSIBLE_HOST_KEY_CHECKING=False


ECS サービスプリンシパルを使用した ECS ノードの構成 153

11. Ansible プレイブックを実行して、keytab を生成します。

ansible-playbook -v -k -i inventory.txt --user admin –b --become-user=root generate-vipr-keytabs.yml

12. 必要に応じて setup-vipr-kerberos.yml ファイルを編集します。デフォルトのファイル内容は次のとおりです。

# cat setup-vipr-kerberos.yml

---### # Configures ViPR/ECS for Kerberos authentication.# - Configures krb5 client # - Installs keytabs# - Installs JCE policy### - hosts: data_nodes roles: - role: vipr_kerberos_config krb5: config_file: krb5.conf service_principal: name: vipr/[email protected] keytab: keytabs/[email protected]

- role: vipr_jce_config jce_policy: name: unlimited src: UnlimitedJCEPolicy/

この例では、デフォルト値（vipr/[email protected]）が（vipr/[email protected]）で置き換えられており、ドメインは MA.EMC.COM です。

強力な暗号化タイプを使用しない場合は、vipr_jce_config ロールを削除する必要があります。

13. Ansible プレイブックを実行して、ECS サービスプリンシパルでデータノードを構成します。

/ansible/samples/keytab ディレクトリが存在し、krb5.conf ファイルが作業ディレクトリ/ansible/samples内にあることを確認します。

ansible-playbook -v -k -i inventory.txt --user admin –b --become-user=root setup-vipr-kerberos.yml



正しい ECS サービスプリンシパルがデータノードに 1 つずつ次のように（KDC から）作成されていることを確認します。

# kadmin.local -q "list_principals" | grep viprvipr/[email protected]/[email protected]

正しい keytab が生成され、次の場所に保存されていることを確認します：/data/hdfs/krb5.keytab（すべての ECS データノード上）。keytab に strings コマンドを使用すると、人間が判読可能なテキストを抽出できます。テキストに適切なプリンシパルが含まれていることを確認してください。例：

dataservice-10-247-199-69:~ # strings /data/hdfs/krb5.keytabMA.EMC.COMviprnile3-vm42.centera.lab.emc.com

この場合、プリンシパルは vipr/nile3-vm42.centera.lab.emc.com です。

Ambari を使用した Kerberosの有効化Ambari を使用して Kerberos を有効化する必要があります。

この処理手順では、Kerberos を有効化するために行う必要がある基本的なステップを説明します。Ambari Kerberos ウィザードの詳細については、ここを参照してください。

手順1. Ambari インターフェイスで、［Ambari］ > ［Admin］ > ［Kerberos］ > ［Enable

Kerberos］を選択して Enable Kerberos ウィザードを表示します。2. ウィザードの［Kerberize Cluster］パネルの手順に従います。［X］をクリックして Kerberos

ウィザードを中止します。

この時点では Hadoop サービスを開始できないため、この Kerberize Cluster ステップはここではスキップできます。


Ambari を使用した Kerberos の有効化 155

https://docs.hortonworks.com/HDPDocuments/Ambari-2.2.0.0/bk_Ambari_Security_Guide/content/_running_the_kerberos_wizard.html

3. ［Confirmation］ダイアログで［Exit Anyway］をクリックしてウィザードを終了することを確認します。

メタデータを使用した ECSバケットの保護ECSバケットが安全な Hadoop クラスターと動作できることを確認するには、バケットがクラスターに関する情報にアクセスできる必要があります。安全な Hadoop クラスターでは、HDFS ユーザー名に Kerberos プリンシパルがマッピングされている必要があります。さらに、ユーザーが UNIX グループにマッピングされている必要があります。Hadoop クラスター内で、NameNode が、Hadoop ノード自体と構成ファイル（core-site.xml と hdfs.xml）からこの情報を収集します。ECS ノードがこの情報を確認してクライアントリクエストの妥当性を検査できるようにするには、ECS ノードの次のデータが使用可能になっている必要があります。l UNIX ユーザーおよびグループに対する Kerberos ユーザーのマッピングl スーパーユーザーグループl プロキシユーザー設定データはメタデータとして保存されている名前と値のペアのセットとして、ECS ノードから使用されます。

Kerberos ユーザーバケットへの Hadoop アクセス権限が必要な各 Kerberos ユーザー（AD ユーザーではない）に関する情報を、ECS にアップロードする必要があります。次のデータが必要です。l プリンシパル名l プリンシパルの短い名前（マップされた名前）l プリンシパルグループHadoop ノードに Kerberos プリンシパルが 10人いる場合、JSON入力ファイルに名前と値のペアを 30 ペア作成する必要があります。名前はすべて一意である必要があるため、各プリンシパル名、プリンシパルの短い名前、プリンシパルグループに一意の名前を割り当てる必要があります。ECS では、JSON エントリー名のプレフィックスとサフィックスは、固定長の必要があります。各 Kerberos ユーザーエントリーに必要なプレフィックスは internal.kerberos.user であり、使用できる 3 つのサフィックスは name、shortname、groups です。次に例を示します。

{ "name": "internal.kerberos.user.hdfs.name", "value": "hdfs-cluster999@EXAMPLE_HDFS.EMC.COM"},{ "name": "internal.kerberos.user.hdfs.shortname", "value": "hdfs"},



{ "name": "internal.kerberos.user.hdfs.groups", "value": "hadoop,hdfs"},

プレフィックスとサフィックスの間の値は、エントリーを一意に識別できる限り任意です。たとえば、次のように使用できます。

"name": "internal.kerberos.user.1.name","name": "internal.kerberos.user.1.shortname","name": "internal.kerberos.user.1.groups",

プリンシパルは、さまざまなユーザーにマッピングできます。たとえば rm プリンシパルユーザーは、Hadoop クラスタの auth_to_local設定を使用して、通常次のように yarn ユーザーにマッピングされます。

RULE:[2:$1@$0](rm@EXAMPLE_HDFS.EMC.COM)s/.*/yarn/

さまざまなプリンシパルにマッピングされる任意のプリンシパル（たとえば、rm プリンシパルを yarn プリンシパルにマッピング）で、shortname値に「マップ済み」のプリンシパルを使用する必要があります。したがって、rm プリンシパルのエントリーは次のようになります。

{"name": "internal.kerberos.user.rm.name","value": "rm@EXAMPLE_HDFS.EMC.COM"},{"name": "internal.kerberos.user.yarn.shortname","value": "yarn@EXAMPLE_HDFS.EMC.COM"},{"name": "internal.kerberos.user.yarn.groups","value": "hadoop"},

スーパーグループHadoop ノード上のユーザーのどの Linux グループが、グループに基づくスーパーユーザー権限を持つのかを ECS に伝える必要があります。supergroup指定ができるのは、JSON入力ファイルのエントリーの 1 つだけです。次のようになります。

{ "name": "dfs.permissions.supergroup", "value": "hdfs"}

プロキシ設定プロキシをサポートするためには、各 Hadoop アプリケーションが使用するすべてのプロキシ設定を識別する必要があります。ここでアプリケーションとは、hiveなど Hadoop でサポートされているアプリケーションのいずれかです。次の例では、hive アプリケーションのためのプロキシサポートが s3users グループ（AD またはLinux グループ）のメンバーであるユーザーに付与されるため、Hadoop クラスタのどのホストでも hive


メタデータを使用した ECSバケットの保護 157

を実行することができます。このための JSON エントリーは、名前/値の 2 つのペアです。1 つがホスト設定用で、もう 1 つがグループ設定用です。

{ "name": "hadoop.proxyuser.hive.hosts", "value": "*"},{ "name": "hadoop.proxyuser.hive.groups", "value": "s3users"}

ファイル全体3種類のメタデータを、1 つの JSON ファイルにまとめる必要があります。JSON ファイルの形式を次の例に示します。

{ "head_type": "hdfs", "metadata": [ { "name": "METADATANAME_1", "value": "METADATAVALUE_1" }, { "name": "METADATANAME_2", "value": "METADATAVALUE_2" },

:

{ "name": "METADATANAME_N", "value": "METADATAVALUE_N" } ]}

最後の名前/値のペアの後ろには「,」記号がありません。

JSON ファイルの例を次に示します。安全なバケットメタデータ（186 ページ）。

安全なバケットと安全でないバケットメタデータがロードされたバケットは［安全なバケット］と呼ばれ、Kerberos プリンシパルがアクセスする必要があります。安全でない Hadoop ノードからのリクエストは拒否されます。メタデータがロードされていないバケットは安全ではなく、安全な Hadoop ノードからのリクエストは拒否されます。安全でないクラスタから安全なバケットにアクセスしようとした場合、次のエラーが表示されます。安全なクラスターから安全でないバケットにアクセスしようとした場合も、同様のメッセージが表示されます。

[hdfs@sandbox ~]$ hadoop fs -ls -R viprfs://hdfsBucket3.s3.site1/ls: ViPRFS internal error (ERROR_FAILED_TO_PROCESS_REQUEST).



管理 REST API を使用した ECS へのメタデータ値のロードECS Management REST API コマンドを実行して、安全な Hadoop クラスタで ECSバケットを安全に使用するために必要なメタデータ値を指定することができます。はじめにそのためには、ECS システム管理者の認証情報が必要です。

Hadoop管理者が ECS システム管理者ではない場合、バケットに安全なメタデータをロードするには、Hadoop管理者は ECS システム管理者と連携して作業する必要があります。Hadoop管理者は、ECS システム管理者が JSON メタデータファイルを利用できるようにすることができます。その後 ECS システム管理者は、次の処理手順に従ってメタデータをロードします。1人のユーザーが両方のロールを持つ場合、そのユーザーは JSON メタデータファイルを作成して、それを ECSバケットにロードする責任があります。

手順1. 次の資料を参照してメタデータを含む JSON ファイルを作成します。メタデータを使用した

ECSバケットの保護（156 ページ）。2. ECS管理コマンドの実行時に使用する認証トークンを取得するために、システム管理者の

認証情報を使用して ECS にログインします。

login コマンドは、curl を使用して実行できます。次の例では、<username>:<password>を ECS システム管理者の認証情報で置き換え、ECS ノードの IP アドレスまたはホスト名を入力する必要があります。

TOKEN=$(curl -s -k -u <username>:<password> -D - -o /dev/null https://<ECS node IP or hostname>:4443/login | grep X-SDS-AUTH-TOKEN | tr -cd '\40-\176')

3. 次の例に示すように、ECS Management REST API コマンド PUT object/bucket/<bucketname>/metadata を実行して、メタデータを導入します。

curl -s -k -X PUT -H "$TOKEN" -H "Accept: application/json" -H "Content-Type: application/json" -T <bucketDetails>.json https:/<hostname>:4443/object/bucket/<bucketname>/metadata?namespace=<namespace>

次の置き換えが必要です。l <username>を、ECS システム管理者のユーザー名に置き換えます。l <password>を、指定した ECS システム管理者ユーザー名のパスワードに置き換えます。

l <bucketname>を、HDFS データを使用しているバケットの名前に置き換えます。l <hostname>を、ECS ノードの IP アドレスまたはホスト名に置き換えます。l <bucketdetails>を、名前と値のペアを含む JSON ファイルのファイル名に置き換えます。

l <namespace>を、バケットがあるネームスペースの名前に置き換えます。

導入が完了すると、すべての ECS ノードからメタデータが使用できるようになります。


管理 REST API を使用した ECS へのメタデータ値のロード 159

ECS クライアントプロパティの再構成Ambari を使用して、ECS クライアントで必要な構成プロパティを設定できます。

以下の表は、必要なプロパティの一覧です。

表 31 ECS アクセスを可能にする Hadoop の構成

Hadoop の場所

プロパティ値

コアサイト fs.viprfs.auth.identity_translation CURRENT_USER_REALM

fs.viprfs.auth.anonymous_translation CURRENT_USER

viprfs.security.principal vipr/[email protected] ここで、REALM.COMはKerberos レルム名で置き換えられます。

各 core_site.xmlパラメーターの詳細については、ECS HDFS の Hadoop core-site.xml プロパティ（180 ページ）を参照してください。

Hadoop サービスの開始と ECS への Hadoop アクセスの確認Hadoop サービスを開始します。手順

1. Ambari を使用して、Hadoop サービスを開始します。2. Hadoop のすべてのクライアントサービスが開始されたら、次のコマンドを使用して、Hadoop

CLI から ECSバケットにアクセスできることを確認します。

hdfs dfs -ls /



第 9章

トラブルシューティング

l 概要.................................................................................................................. 162l 安全な Hadoop クラスタを使用した正しい AD/LDAP構成の確認............................ 162l Pig テストの失敗：Kerberos プリンシパルを取得できない.........................................163l AD ユーザーの権限が拒否される........................................................................... 163l 権限エラー.......................................................................................................... 163l リクエストの処理の失敗........................................................................................ 166l Kerberos クライアント側のログおよびデバッグの有効化.............................................. 166l KDC での Kerberos のデバッグ.............................................................................. 167l クロックスキューの排除..........................................................................................167l ECS サービスプリンシパルを使用した 1 つ以上の新規 ECS ノードの構成.................... 167l Yarn ディレクトリが存在しないエラーの回避策.......................................................... 169

トラブルシューティング 161

概要このセクションでは、ECS HDFS を構成するときに発生することのある問題の回避策を説明します。

安全な Hadoop クラスタを使用した正しい AD/LDAP構成の確認Kerberos（KDC）と Hadoop クラスターを使用して AD または LDAP が正しく設定されていることを確認する必要があります。構成が正しい場合は、AD/LDAP ユーザーに対して kinit を使用できます。また、Hadoop クラスターがローカル HDFS用に構成されている場合は、ECS をクラスターに追加する前に、ローカルHDFS ディレクトリをリストできることを確認する必要があります。

解決策Hadoop クラスターで KDC を使用して AD/LDAP ユーザーとして認証されない場合は、ECSHadoop構成に進む前にこの問題を解決する必要があります。正常なログインの例は、次のとおりです。

[kcluser@lvipri054 root]$ kinit [email protected] for [email protected]:

[kcluser@lvipri054 root]$ klistTicket cache: FILE:/tmp/krb5cc_1025Default principal: [email protected]

Valid starting Expires Service principal04/28/15 06:20:57 04/28/15 16:21:08 krbtgt/[email protected] renew until 05/05/15 06:20:57

上記が成功しない場合は、次のチェックリストを使用して調査します。l KDC サーバ上の/etc/krb5.conf ファイルの正確さと構文を確認します。レルムは設定フ

ァイル内の場合や kinit コマンドと使用する場合に大文字と小文字が区別されることがあります。

l KDC サーバから/etc/krb5.conf ファイルがすべての Hadoop ノードにコピーされていることを確認します。

l AD/LDAP と KDC サーバーの間で一方向の信頼関係が正しく作成されていることを確認します。

l AD/LDAP サーバーの暗号化タイプが KDC サーバーの暗号化タイプと一致していることを確認します。

l /var/kerberos/krb5kdc/kadm5.acl ファイルと/var/kerberos/krb5kdc/kdc.conf ファイルが正しいことを確認します。

l KDC サーバーにサービスプリンシパルとしてログインして、KDC サーバー自体が正常に機能していることを確認します。

l KDC サーバーに直接、同じ AD/LDAP ユーザーとしてログインを試行します。正常に機能しない場合は、KDC サーバーに問題がある可能性があります。



Pig テストの失敗：Kerberosプリンシパルを取得できないPig テストが失敗し、エラー「Info:Error: java.io.IOException: Unable toobtain the Kerberos principal」（AD ユーザーとして kinit を実行した場合も含む）または「Unable to open iterator for alias firstten」が表示されることがあります。この問題は、Pig（リリース 0.13以前）でセカンダリストレージとしての ViPRFS に代行トークンが生成されないことが原因です。

解決策viprfs://bucket.ns.installation/を mapreduce.job.hdfs-servers構成の末尾に追加します。例：

set mapreduce.job.hdfs-servers viprfs://KcdhbuckTM2.s3.site1

AD ユーザーの権限が拒否されるAD ユーザーとしてアプリケーションを実行するときに、「Permission denied」エラーが表示されることがあります。

解決策/user ディレクトリの権限を次のように設定します。

hdfs dfs -chmod 1777 /user

権限エラー権限不足エラーが発生する理由は、数多くあります。このタイプのエラーは hadoop fs コマンドの実行中に受信したり、mapreduce または hive のログなどのアプリケーションログに表示されたりします。

INSUFFICIENT_PERMISSIONS エラー

次の例では、jhs プリンシパルがディレクトリ（/tmp）を作成しようとして、INSUFFICIENT_PERMISSIONS エラーを受信しています。この例では、ルートディレクトリの権限が、このユーザーにディレクトリの作成を許可しませんでした。

root@lrmk042:/etc/security/keytabs# hadoop fs -mkdir /tmp15/11/08 21:03:09 ERROR vipr.ViPRFileSystemClientBase: Permissions failure for request: User: jhs/lrmk042.lss.emc.com@HOP171_HDFS.EMC.COM (auth:KERBEROS), host: hdfsBucket3.s3.site1, namespace: s3, bucket: hdfsBucket315/11/08 21:03:09 ERROR vipr.ViPRFileSystemClientBase: Request message sent: MkDirRequestMessage[kind=MKDIR_REQUEST,namespace=s3,bucket=hdfsBucket3,path=/tmp,hdfsTrustedStatus=HDFS_USER_NOT_TRUSTED,permissions=rwxr-xr-x,createParent=true]mkdir: java.security.AccessControlException: ERROR_INSUFFICIENT_PERMISSIONS

root@lrmk042:/etc/security/keytabs# hadoop fs -ls -d /drwxr-xr-x - hdfs hdfs 0 2015-11-08 16:58 /root@lrmk042:/etc/security/keytabs#


Pig テストの失敗：Kerberos プリンシパルを取得できない 163

権限不足エラーのケースがクライアントに明らかでない場合は、サーバーログを確認します。dataheadsvc-error.log で、エラーの検索を開始します。各 ECS ノードのターミナルウィンドウを開き、dataheadsvc-error.log ファイルを編集します。クライアントでエラーが表示された時間に該当するエラーを検索します。

認証情報取得の失敗

dataheadsvc-error.log に次のようなエラーが表示されている場合、

2015-11-08 22:36:21,985 [pool-68-thread-6] ERROR RequestProcessor.java (line 1482) Unable to get group credentials for principal 'jhs@HOP171_HDFS.EMC.COM'. This principal will default to use local user groups. Error message: java.io.IOException: Failed to get group credentials for 'jhs@HOP171_HDFS.EMC.COM', status=ERROR

これはエラーではありません。このメッセージは、リクエストを行ったプリンシパルユーザーの ActiveDirectory グループがキャッシュされているかどうかを確認するために、サーバがプリンシパル名を検索しようとしていることを意味します。このエラーは Kerberos ユーザーに対して返されます。エラーには、リクエストをしたユーザー名が示されます。覚えておいてください。

バケットアクセスエラー

バケットへのアクセスをリクエストしているユーザーに ACL権限がない場合に、このエラーがdataheadsvc-error.log に表示されることがあります。

2015-11-08 21:35:26,652 [pool-68-thread-1] ERROR BucketAPIImpl.java (line 220) Getting bucket failed withcom.emc.storageos.objcontrol.object.exception.ObjectAccessException: you don't have GET_KEYPOOL_ACL permission to this keypoolat com.emc.storageos.objcontrol.object.exception.ObjectAccessException.createExceptionForAPI(ObjectAccessException.java:286)at com.emc.storageos.data.object.ipc.protocol.impl.ObjectAccessExceptionParser.parseFrom(ObjectAccessExceptionParser.java:61)

この例では、バケットの明示的なユーザー ACL を追加するか、ユーザーがメンバーになっているグループのいずれかのカスタムグループ ACL を追加する必要があります。

オブジェクトアクセスエラー

その他の権限エラーに、オブジェクトアクセスエラーがあります。オブジェクト（ファイルおよびディレクトリ）へのアクセスを、バケットへのアクセスと混同してはいけません。ユーザーがバケットへの完全な管理権限（読み取り/書き込み/削除）を持つにもかかわらず INSUFFICIENT_PERMISSIONSエラーを受信する場合があります。これは、アクセスしようとしているパスに存在する 1 つ以上のオブジェクトへのアクセス権を持たないためです。オブジェクトアクセスエラーの例を次に示します。

2015-11-08 22:36:21,995 [pool-68-thread-6] ERROR FileSystemAccessHelper.java (line 1364) nfsProcessOperation failed to process path: mr-history/done2015-11-08 22:36:21,995 [pool-68-thread-6] ERROR ObjectControllerExceptionHelper.java (line 186) Method nfsGetSMD failed due to exceptioncom.emc.storageos.data.object.exception.ObjectControllerException: directory server returns error ERROR_ACCESS_DENIEDat com.emc.storageos.data.object.FileSystemAccessLayer.FileSystemAccessHelper.nfsProcessOperation(FileSystemAccessHelper.java:1368)



at com.emc.storageos.data.object.FileSystemAccessLayer.FileSystemAccessHelper.getSystemMetadata(FileSystemAccessHelper.java:466)at com.emc.storageos.data.object.FileSystemAccessLayer.FileSystemAccessLayer.getSystemMetadata(FileSystemAccessLayer.java:532)at com.emc.storageos.data.object.blob.client.BlobAPI.getStat(BlobAPI.java:1294)at com.emc.vipr.engine.real.RealBlobEngine.stat(RealBlobEngine.java:1976)at com.emc.vipr.engine.real.RealBlobEngine.stat(RealBlobEngine.java:802)at com.emc.vipr.hdfs.fs.RequestProcessor.accept(RequestProcessor.java:499)at com.emc.vipr.hdfs.net.ConnectionManager$RequestThread.run(ConnectionManager.java:136)at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)at java.lang.Thread.run(Thread.java:745)

ここで注意するべき 2 つの重要な項目に、リクエストされたアクション（stat）とオブジェクトのパス（mr-history/done）があります。先頭のスラッシュ文字は表示されないため、実際のパスは/mr-history/done であることに注意してください。これで、デバッグに関する重要な 3種類の情報を入手しました。l ユーザープリンシパル（jhs@HOP171_HDFS.EMC.COM）l アクション（statは hadoop fs -ls）l パス（/mr-history/done）追加のデバッグには、2 つのアプローチがあります。l blobsvc ログのデバッグ（165 ページ）l Hadoop クライアントのデバッグ（165 ページ）

blobsvc ログのデバッグ失敗した権限リクエストには、blobsvc に次のようなエラーがあります。

2015-11-08 22:36:21,994[TaskScheduler-BlobService-COMMUNICATOR-ParallelExecutor-5892]ERROR ObjectAclChecker.java (line 101) not permit, cred jhs@HOP171_HDFS.EMC.COM[hadoop]false1 withaction GET_OBJECT_ACL on object with acl/owner/group user={hdfs@hop171_hdfs.emc.com=[FULL_CONTROL]},groups={hdfs=[READ_ACL, EXECUTE, READ]}, other=[], owner=hdfs@hop171_hdfs.emc.com, group=hdfs

not permit を探します。これにより、リクエストしたユーザー（jhs）、オブジェクトの所有者（hdfs）、オブジェクトグループ（hdfs）、所有者やグループなどの権限がわかります。権限チェックに失敗した実際のオブジェクトはわかりません。Hadoop ノードでは、hdfs プリンシパルになって、パスから開始して、他のデバッグ方法につながるツリーを調べて、クライアントから Hadoop ファイルシステムを調べます。

Hadoop クライアントのデバッグ権限エラーを受信した場合、リクエストをしたユーザープリンシパル、リクエストされたアクション、リクエスト対象項目を把握する必要があります。例では、jhs ユーザーが、/mr-history/done ディレクトリに一覧表示されているエラーを受信しました。分析を行って、根本原因を特定します。スーパーユーザーアカウントへのアクセス権がある場合は、そのアカウントで次の手順を実行します。

root@lrmk042:/var/log/hadoop-mapreduce/mapred# hadoop fs -ls -d /mr-history/donedrwxrwxrwt - mapred hadoop 0 2015-11-08 16:58 /mr-history/done


権限エラー 165

次の例は、このディレクトリを一覧表示するためには、jhs プリンシパルはアクセス権が必要だったことを示しています。

root@lrmk042:/var/log/hadoop-mapreduce/mapred# hadoop fs -ls -d /mr-historydrwxr-xr-x - hdfs hdfs 0 2015-11-08 16:58 /mr-history

同様に、次の出力はディレクトリにアクセスの問題がないことを示しています。

root@lrmk042:/var/log/hadoop-mapreduce/mapred# hadoop fs -ls -d /drwxr-x--- - hdfs hdfs 0 2015-11-08 16:58 /

ここでの問題は、ルートディレクトリが hdfs に所有され、グループ名は hdfs ですが、others設定が-（0）であることです。リクエストしたユーザーは jhs@REALM であり、このユーザーは hadoopのメンバーであって hdfs のメンバーではありません。したがって、このユーザーには/mr-history/done ディレクトリを一覧表示するオブジェクト ACLはありません。ルートディレクトリでchmod コマンドを実行すれば、このユーザーはタスクを実行できるようになります。

root@lrmk042:/var/log/hadoop-mapreduce/mapred# hadoop fs -chmod 755 /

root@lrmk042:/var/log/hadoop-mapreduce/mapred# hadoop fs -ls -d /drwxr-xr-x - hdfs hdfs 0 2015-11-08 16:58 /

リクエストの処理の失敗バケットを一覧表示するときに、プロセスのリクエスト失敗が表示されます。たとえば次のように、バケット一覧表示コマンドを実行すると、

# hadoop fs -ls viprfs://hdfsBucket2.s3.site1/

次の ViPRFS内部エラーが発生します。

ERROR_FAILED_TO_PROCESS_REQUEST

解決策このエラーの考えられる理由は以下のとおりです。1. Hadoop ノードの viprfs クライアント JAR ファイルが、ECS ソフトウェアと同期していない。2. 安全でない（Kerberos ではない）Hadoop ノードから、安全な（Kerberos）バケットにアク

セスしようとしている。3. 安全な（Kerberos）Hadoop ノードから、安全でない（Kerberos ではない）バケットにアク

セスしようとしている

Kerberos クライアント側のログおよびデバッグの有効化認証問題のトラブルシューティングのために、使用中の Hadoop クラスターノードで詳細ログとデバッグを有効にすることができます。



クライアント側での詳細ログの有効化次の例に示すように、現在の SSH セッションのみに適用される環境変数を使用して詳細ログを有効化できます。

export HADOOP_OPTS="-Dsun.security.krb5.debug=true"

Hadoop クライアント側でのデバッグの有効化Hadoop ノードと ECS間の Hadoop アクティビティのトラブルシューティングを行うために、次のようにして Hadoop の詳細ログを有効にできます。

export HADOOP_ROOT_LOGGER="Debug,console"

KDCでの KerberosのデバッグKDC の/var/log/krb5kdc.log ファイルに対して tail コマンドを使用することで、KDC上で Kerberos をデバッグすることにより、HDFS操作を実行するときのデバッグを容易にできます。

tail -f /var/log/krb5kdc.log

クロックスキューの排除Kerberosは時間の正確さに依存しているため、クライアントとサーバの間で時間が確実に同期されていることが重要となります。Active Directory のデータノードや KDC にクロックスキューがある場合は、NTP サーバを構成する必要があります。次の手順を実行します。1. リモートデスクトップを使用して、AD サーバーに接続します。2. 次のコマンドを実行します。

a. w32tm /config /syncfromflags:manual /manualpeerlist:<ntp-server1>,<ntp-server2>

b. net stop w32timec. net start w32time

ECS サービスプリンシパルを使用した 1 つ以上の新規 ECS ノードの構成

ECS構成に 1 つ以上の新しいノードを追加する場合は、ECS サービスプリンシパルと対応するkeytab を新規ノードに導入する必要があります。

はじめにl この処理手順は、こちらの手順をすでに完了していることが前提であり、Ansible プレイブックが

インストールされアクセス可能になっている必要があります。この手順を完了する前に、以下の項目を準備しておく必要があります。l IP アドレスを指定する ECS ノードのリスト。


KDC での Kerberos のデバッグ 167

l KDC の IP アドレス。l このスクリプトを実行する DNS の解決が、Hadoop ホストの DNS の解決と同じであること。異

なっていると、vipr/_HOST@REALM が機能しません。手順

1. ノード 1 にログインして、ツールがインストール済みで、プレイブックが利用可能なことを確認します。以前の使用例は次のとおりです。

/home/admin/ansible/viprfs-client-<ECS version>-<version>/playbooks

2. inventory.txt ファイル（playbooks/samples ディレクトリ内）を編集して、ECSノードを追加します。デフォルトのエントリーを、次の抜粋に示します。

[data_nodes]192.168.2.[100:200]

[kdc]192.168.2.10

3. ECS ノード 1 でユーティリティコンテナを起動して、Ansible プレイブックがコンテナから使用できるようにします。a. ユーティリティコンテナのイメージをロードします。

例：

sudo docker load -i /opt/emc/caspian/checker/docker/images/utilities.txz

b. Docker イメージの ID を取得します。

例：

admin@provo-lilac:~> sudo docker images

イメージ ID が出力されます。

REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZEutilities 1.5.0.0-403.cb6738e 186bd8577a7a 2 weeks ago 738.5 MB

c. 起動して、ユーティリティイメージを入力します。

例：

sudo docker run -v /opt/emc/caspian/fabric/agent/services/object/main/log:/opt/storageos/logs -v /home/admin/ansible/viprfs-client-3.0.0.0.85325.a05145b/playbooks:/ansible --name=ecs-tools -i -t --privileged --net=host 186bd8577a7a /bin/bash



この例では、Ansible プレイブックが圧縮解除された場所/home/admin/ansible/viprfs-client-3.0.0.0.85325.a05145b/playbooksは、ユーティリティコンテナ内の/ansible ディレクトリにマッピングされます。

4. コンテナ内の作業ディレクトリに変更します。例：

cd /ansible

5. Ansible プレイブックを実行して、keytab を生成します。

ansible-playbook -v -k -i inventory.txt generate-vipr-keytabs.yml

6. Ansible プレイブックを実行して、ECS サービスプリンシパルでデータノードを構成します。

/ansible/samples/keytab ディレクトリが存在し、krb5.conf ファイルが作業ディレクトリ/ansible/samples内にあることを確認します。

ansible-playbook -v -k -i inventory.txt setup-vipr-kerberos.yml

正しい ECS サービスプリンシパルがデータノードに 1 つずつ次のように（KDC から）作成されていることを確認します。

# kadmin.local -q "list_principals" | grep viprvipr/[email protected]/[email protected]

正しい keytab が生成され、次の場所に保存されていることを確認します：/data/hdfs/krb5.keytab（すべての ECS データノード上）。keytab に strings コマンドを使用すると、人間が判読可能なテキストを抽出できます。テキストに適切なプリンシパルが含まれていることを確認してください。例：

dataservice-10-247-199-69:~ # strings /data/hdfs/krb5.keytabMA.EMC.COMviprnile3-vm42.centera.lab.emc.com

この場合、プリンシパルは vipr/nile3-vm42.centera.lab.emc.com です。

Yarn ディレクトリが存在しないエラーの回避策Kerberos認証による HDP クラスタとの組み合わせで、デフォルトのファイルシステムとして ECS を構成する場合、/ats/done does not exist のようなエラーを受け取ることがあります。これに加え、リソースマネージャが開始されません。

この処理手順では、これらの問題の回避策を説明します。手順

1. Hadoop ノードで ECS ノードを解決できるかどうかを確認します。


Yarn ディレクトリが存在しないエラーの回避策 169

a. Hadoop ノードに nslookup ツールをインストールします。

yum install -y bind-utils

b. このツールで ECS ノードを解決できることを確認します。

nslookup <address of ECS node>

c. 正しいホスト名に解決できない場合は、Hadoop ノード上の/etc/resolv.conf にECS DNS を追加します。

次のコマンドを実行して、DNS エントリーがここに存在することをチェックできます。

cat /etc/resolv.conf

d. これで、Hadoop ノードは ECS ノードを解決するようになります。

nslookup を再度実行して解決されることを確認します。

nslookup <address of ECS node>

2. Hadoop ノード、ECS ノード、KDC でシステム時刻を確認します。

以下を使用します。

# date

システムの時刻が統合されていない場合は、同一の ntp サーバに同期する必要があります。これについては、NTP の有効化で説明します。

3. 前のステップが機能しない場合は、/ats の下でフォルダ done または active の手動作成を試みることができます。

# sudo -u hdfs hdfs dfs -mkdir /ats/done

# sudo -u hdfs hdfs dfs -mkdir /ats/active



HTTPS://DOCS.HORTONWORKS.COM/HDPDOCUMENTS/AMBARI-2.4.2.0/BK_AMBARI-INSTALLATION/CONTENT/ENABLE_NTP_ON_THE_CLUSTER_AND_ON_THE_BROWSER_HOST.HTML

ディレクトリが存在することを確認します。

$ hdfs dfs -ls /ats

Found 2 items drwxrwxrwt - yarn hadoop 0 2016-07-12 09:00 /ats/active drwx------ - yarn hadoop 0 2016-07-12 09:00 /ats/done


Yarn ディレクトリが存在しないエラーの回避策 171



第 10章

付録：Kerberos の構成について

l Kerberos の構成について..................................................................................... 174

付録：Kerberos の構成について 173

Kerberosの構成についてHadoop クラスターでの Kerberos の構成について説明します。

Kerberos KDC のセットアップKerberos KDC をセットアップするには、次の手順を実行します。手順

1. krb5-workstation をインストールします。

以下のコマンドを使用します。

yum install -y krb5-libs krb5-server krb5-workstation

2. /etc/krb5.conf を変更して、レルム名と拡張子を指定します。3. /var/kerberos/krb5kdc/kdc.conf を変更して、レルム名を自分のものと同じ名

前にします。4. KDC が VM である場合は、/dev/random を再作成します（再作成しないと、次の手順

での KDC データベースの作成に非常に時間がかかります）。a. 次のように削除します。

# rm -rf /dev/random

b. 次のように再作成します。

# mknod /dev/random c 1 9

5. KDC データベースを作成します。

# kdb5_util create -s

初期のプリンシパルに誤りがある場合、たとえば「kdb5_util create -s」を誤って実行した場合は、/var/kerberos/krb5kdc/ ディレクトリのこれらのプリンシパルを明示的に削除する必要があります。

6. kadm5.acl を変更して、管理者権限を持つユーザーを指定します。

*/[email protected] *



7. /var/kerberos/krb5kdc/kdc.conf を変更して、des-cbc-crc:normal以外の暗号化タイプをすべて削除します。レルム名も変更します。

8. iptables と selinux がすべてのノード（KDC サーバーと Hadoop ノード）でオフになっていることを確認します。

9. KDC サービスを開始し、ローカル管理者のプリンシパルを作成します。

kadmin.local

# service krb5kdc start

# service kadmin start

# /usr/kerberos/sbin/kadmin.local-q "addprinc root/admin"

# kinit root/admin

10. krb5.conf ファイルをすべての Hadoop ノードにコピーします。

いずれかの構成ファイルに変更を加えた場合は、次のサービスを再起動し、krb5.conf ファイルを関連する Hadoop ホストと ECS にコピーします。

11. サービスを再起動します。

service krb5kdc restart

service kadmin restart

12. Kerberos KDC のセットアップ手順の詳細については、http://www.centos.org/docs/4/html/rhel-rg-en-4/s1-kerberos-server.html を参照してください。

Kerberos の AD ユーザー認証の構成Hadoop環境で Kerberos セキュリティを構成する場合は、ECS AD ドメインに対して認証するように構成できます。ADREALM の AD ユーザーが存在することを確認してください。次の例では、ADREALMCAMBRIDGE.ACME.COM の「detscr」ユーザーを使用しています。例のように、KDCREALM とADREALM の間に一方向の信頼関係を作成します。このレルムは「netdom trust」を使用して検証しないでください。

Active Directoryの場合KDC レルムから AD レルムに一方向のレルム間信頼関係を設定する必要があります。設定するには、コマンドプロンプトで次のコマンドを実行します。

ksetup /addkdc KDC-REALM <KDC hostname>netdom trust KDC-REALM /Domain:AD-REALM /add /realm /passwordt:<TrustPassword>ksetup /SetEncTypeAttr KDC-REALM <enc_type>

例：

ksetup /addkdc LSS.EMC.COM lcigb101.lss.emc.comnetdom trust LSS.ACME.COM /Domain:CAMBRIDGE.ACME.COM /add /realm /


Kerberos の AD ユーザー認証の構成 175

https://www.centos.org/docs/5/html/5.1/Deployment_Guide/s1-kerberos-server.html

https://www.centos.org/docs/5/html/5.1/Deployment_Guide/s1-kerberos-server.html

passwordt:ChangeMeksetup /SetEncTypeAttr LSS.ACME.COM DES-CBC-CRC

この例では、des-cbc-crc暗号化を使用しています。ただし、これはデモ専用の弱い暗号化方式です。選択する暗号化は、AD、KDC、クライアントでサポートされる方式である必要があります。

KDCの場合（ルートとして）一方向の信頼関係をセットアップするには、「krbtgt」サービスプリンシパルを作成する必要があります。名前は krbtgt/KDC-REALM@AD-REALM にします。これにパスワード「ChangeMe」または上記の/passwordt引数に指定したパスワードを設定します。1. KDC で次のコマンドを実行します（root として）。

# kadminkadmin: addprinc -e "des-cbc-crc:normal" krbtgt/[email protected]

導入時は、暗号化タイプは選択したタイプに制限することをお勧めします。これが機能したら、他の暗号化タイプを追加できます。

2. 次のルールを core-site.xml hadoop.security.auth_to_local プロパティに追加します。

RULE:[1:$1@$0](^.*@CAMBRIDGE\.ACME\.COM$)s/^(.*)@CAMBRIDGE\.ACME\.COM$/$1/gRULE:[2:$1@$0](^.*@CAMBRIDGE\.ACME\.COM$)s/^(.*)@CAMBRIDGE\.ACME\.COM$/$1/g

3. AD または LDAP に Kerberos（KDC）サーバーが正しく設定されていることを確認します。ユーザーは AD ユーザーに「kinit」を実行してローカルの HDFS ディレクトリをリストできる必要があります。

Hadoop クラスターと ECS で AD を使用した認証を行う構成の場合は、すべての Hadoop ノードで kinit実行対象の AD ユーザーのローカル Linux ユーザーアカウントを作成し、その ADユーザーを使用してすべての Hadoop ホストに kinit を実行できることを確認します。たとえば、userX@ADREALM として kinit を実行する場合は、すべての Hadoop ホストでローカルユーザー userX を作成します。kinit を実行するために、「kinit userX@ADREALM」をそのユーザーのすべてのホストに使用します。

次の例では、「kinit [email protected]」として認証を行うために、ユーザー「detscr」を作成し、このユーザーで Hadoop ホストに kinit を実行します。次のとおりです。

[root@lviprb159 ~]# su detscr [detscr@lviprb159 root]$ whoami detscr [detscr@lviprb159 root]$ kinit [email protected] Password for [email protected]: [detscr@lviprb159 root]$ klist Ticket cache: FILE:/tmp/krb5cc_1010 Default principal: [email protected] Valid starting Expires Service principal 12/22/14 14:28:27 03/02/15 01:28:30 krbtgt/



[email protected] renew until 09/17/17 15:28:27 [detscr@lviprb159 root]$ hdfs dfs -ls /Found 4 itemsdrwx---rwx - yarn hadoop 0 2014-12-23 14:11 /app-logsdrwx---rwt - hdfs 0 2014-12-23 13:48 /appsdrwx---r-x - mapred 0 2014-12-23 14:11 /mapreddrwx---r-x - hdfs 0 2014-12-23 14:11 /mr-history


Kerberos の AD ユーザー認証の構成 177



第 11章

付録：ECS HDFS の Hadoop core-site.xml プロパティ

l ECS HDFS の Hadoop core-site.xml プロパティ....................................................180

付録：ECS HDFS の Hadoop core-site.xml プロパティ 179

ECS HDFSの Hadoop core-site.xmlプロパティHadoopcore-site.xml ファイルを構成する場合は、プロパティおよびその関連する値のリファレンスとしてこの表を使用します。

表 32 Hadoop core-site.xml のプロパティ

プロパティ説明

ファイルシステム実装のプロパティ

fs.viprfs.impl<property><name>fs.viprfs.impl</name><value>com.emc.hadoop.fs.vipr.ViPRFileSystem</value></property>

fs.AbstractFileSystem.viprfs.impl <property>

<name>fs.AbstractFileSystem.viprfs.impl</name> <value>com.emc.hadoop.fs.vipr.ViPRAbstractFileSystem</value> </property>

ECS HDFS ファイルシステム URI の権限セクションを定義するプロパティ

fs.vipr.installations 名前のリスト（コンマ区切り）。名前は、ECS データノードセットを一意に識別するために fs.vipr.installation.

[federation].hosts プロパティでさらに定義されます。この名前は、ECS HDFS ファイルシステム URI の権限セクションのコンポーネントとして使用されます。例：

<property> <name>fs.vipr.installations</name> <value><federation>,<site1>,<testsite></value> </property>

fs.vipr.installation.[federation].hosts

fs.vipr.installations プロパティに名前がリストされた ECS ロードバランサーまたはクラスタのデータノードの IP アドレス。IP アドレスまたは完全修飾ドメイン名のコンマ区切りリストの形式で値を指定します。例：

<property> <name>fs.vipr.installation.<federation>.hosts</name> <value>203.0.113.10,203.0.113.11,203.0.113.12</value> </property>

fs.vipr.installation.[installation_name].resolution

ECS データノードにアクセスする方法を ECS HDFS ソフトウェアに通知する方法を指定します。値は以下のとおりです。l dynamic：ロードバランサーを使用せずに ECS データノードに直接アクセスする場合は、この値を使用。l fixed：ロードバランサーを使用して ECS データノードにアクセスする場合は、この値を使用。

<property> <name>fs.vipr.installation.<federation>.resolution</name> <value>dynamic</value>



表 32 Hadoop core-site.xml のプロパティ（続き）


</property>

fs.vipr.installation.[installation_name].resolution.dynamic.time_to_live_ms

fs.vipr.installation.[installation_name].resolution プロパティが dynamic に設定されている場合、このプロパティは、ECS に対してアクティブノードのリストをクエリーする頻度を指定します。値はミリ秒単位です。デフォルトは 10分です。

<property> <name>fs.vipr.installation.<federation>.resolution.dynamic.time_to_live_ms</name> <value>600000</value> </property>

ECS ファイルシステム URI

fs.defaultFS デフォルトのファイルシステムへの URI を指定する標準的な Hadoop プロパティ。このプロパティを ECS HDFS ファイルシステムに設定するかどうかは任意です。これを ECS HDFS ファイルシステムに設定しない場合は、ファイルシステムの各操作で完全な URI を指定する必要があります。ECS HDFS ファイルシステムの URI の形式は以下のとおりです。

viprfs://[bucket_name].[namespace].[federation]

l bucket_name：HDFS対応バケットの名前。Hadoop ジョブを実行するときに使用するデータが含まれます。l namespace：namespace：HDFS対応バケットに関連づけられたテナントのネームスペース。l federation：ECS データノードセットに関連づけられた名前。Hadoop が ECS のデータにアクセスするときに

使用できます。このプロパティの値は、［fs.vipr.installations］プロパティで指定された値の 1 つと一致している必要があります。

例：

<property> <name>fs.defaultFS</name> <value>viprfs://testbucket.s3.federation1</value> </property>

umask プロパティ

fs.permissions.umask-mode

標準的な Hadoop プロパティ。ECS HDFS によるオブジェクトでの権限の処理方法を指定します。権限は、入力権限で umask を適用することで処理されます。シンプルおよび Kerberos両方の構成の推奨値は次のとおりです。022。例：

<property><name>fs.permissions.umask-mode</name><value>022</value></property>


ECS HDFS の Hadoop core-site.xml プロパティ 181



ID変換のプロパティ

fs.viprfs.auth.identity_translation

このプロパティは、指定されていない場合に特定のユーザーが属する Kerberos レルムを ECS HDFS クライアントが決定する方法を指定します。ECS データノードにはファイル所有者が username@REALM として格納され、Hadoop にはファイル所有者のユーザー名のみが格納されます。有効な値は次のとおり：l NONE：デフォルト。ユーザーはレルムにマップされません。この設定は、シンプルなセキュリティを使用する

Hadoop クラスターに使用します。この設定では、ECS HDFSはレルムの変換を実行しません。l CURRENT_USER_REALM：Kerberos がある場合に有効です。ユーザーのレルムは自動的に検出されます。

これは、現在サインインしているユーザーのレルムです。次の例では、sally が EMC.COM レルムにいるため、レルムは EMC.COM です。ファイルの所有権は、[email protected] に変更されました。

# kinit [email protected]# hdfs dfs -chown john /path/to/file

コマンドラインで入力されたレルムは、プロパティの設定より優先されます。

<property> <name>fs.viprfs.auth.identity_translation </name> <value>CURRENT_USER_REALM</value> </property>

FIXED_REALM は廃止されました。

fs.viprfs.auth.realm fs.viprfs.auth.identity_translation プロパティが FIXED_REALM に設定されているときにユーザーに割り当てられるレルム。廃止されました。

fs.viprfs.auth.anonymous_translation

このプロパティは、新規に作成されたファイルに、ユーザーとグループを割り当てる方法を決定するために使用されます。

このプロパティは、所有者がないファイルに何が起こったのかを判別するために使用されていました。これらのファイルはanonymous によって所有されているとされていました。今後、ファイルとディレクトリが匿名で所有されることはありません。

値は次のとおりです。l LOCAL_USER：この設定は、シンプルなセキュリティを使用する Hadoop クラスタに使用します。新しく作成し

たファイルとディレクトリに、Hadoop クラスタの UNIX ユーザーとグループを割り当てます。l CURRENT_USER：この設定は、Kerberos を使用する Hadoop クラスタに使用します。Kerberos プリンシパ

ル（[email protected]）をファイルまたはディレクトリの所有者として割り当て、バケットのデフォルトとして割り当てられているグループを使用します。





l NONE：（非推奨）以前は、匿名で所有されるオブジェクトから、現在のユーザーへのマッピングを実行するべきでないことを示していました。

<property> <name>fs.viprfs.auth.anonymous_translation</name> <value>CURRENT_USER</value> </property>

Kerberos レルムとサービスプリンシパルのプロパティ

viprfs.security.principal このプロパティは、ECS のサービスプリンシパルを指定します。このプロパティにより、KDC に ECS サービスのことが通知されます。この値は、ユーザーの構成に固有です。プリンシパル名には_HOST を含めることができます。これは、実行時に実際のデータノード完全修飾ドメイン名に自動的に置換されます。

例：

<property> <name>viprfs.security.principal</name> <value>vipr/[email protected]</value></property>

単純認証モードの core-site.xml の例次の core-site.xml ファイルは、単純認証モードの ECS HDFS プロパティの例です。

例 1 core-site.xml

<property> <name>fs.viprfs.impl</name> <value>com.emc.hadoop.fs.vipr.ViPRFileSystem</value></property>

<property> <name>fs.AbstractFileSystem.viprfs.impl</name> <value>com.emc.hadoop.fs.vipr.ViPRAbstractFileSystem</value></property>

<property> <name>fs.vipr.installations</name> <value>federation1</value></property>

<property> <name>fs.vipr.installation.federation1.hosts</name> <value>203.0.113.10,203.0.113.11,203.0.113.12</value></property>

<property> <name>fs.vipr.installation.federation1.resolution</name> <value>dynamic</value>


単純認証モードの core-site.xml の例 183

例 1 core-site.xml （続き）

</property>

<property> <name>fs.vipr.installation.federation1.resolution.dynamic.time_to_live_ms</name> <value>900000</value></property>

<property> <name>fs.defaultFS</name> <value>viprfs://mybucket.mynamespace.federation1/</value></property>

<property> <name>fs.viprfs.auth.anonymous_translation</name> <value>LOCAL_USER</value></property>

<property> <name>fs.viprfs.auth.identity_translation</name> <value>NONE</value></property>



第 12章

付録：安全なバケットメタデータの例

l 安全なバケットメタデータ...................................................................................... 186

付録：安全なバケットメタデータの例 185

安全なバケットメタデータ次の例では、安全なバケットメタデータの名前と値のペアを一覧表示します。

{ "head_type": "hdfs", "metadata": [ { "name": "internal.kerberos.user.ambari-qa.name", "value": "ambari-qa@EXAMPLE_HDFS.EMC.COM" }, { "name": "internal.kerberos.user.ambari-qa.shortname", "value": "ambari-qa" }, { "name": "internal.kerberos.user.ambari-qa.groups", "value": "hadoop,users" }, { "name": "internal.kerberos.user.cmaurer.name", "value": "cmaurer@EXAMPLE_HDFS.EMC.COM" }, { "name": "internal.kerberos.user.cmaurer.shortname", "value": "cmaurer" }, { "name": "internal.kerberos.user.cmaurer.groups", "value": "cmaurer,adm,cdrom,sudo,dip,plugdev,users,lpadmin,sambashare" }, { "name": "internal.kerberos.user.dn.name", "value": "dn@EXAMPLE_HDFS.EMC.COM" }, { "name": "internal.kerberos.user.dn.shortname", "value": "hdfs@EXAMPLE_HDFS.EMC.COM" }, { "name": "internal.kerberos.user.dn.groups", "value": "hadoop,hdfs" }, { "name": "internal.kerberos.user.hdfs.name", "value": "hdfs@EXAMPLE_HDFS.EMC.COM" }, { "name": "internal.kerberos.user.hdfs.shortname", "value": "hdfs" }, { "name": "internal.kerberos.user.hdfs.groups", "value": "hadoop,hdfs" }, { "name": "internal.kerberos.user.hive.name", "value": "hive@EXAMPLE_HDFS.EMC.COM" }, { "name": "internal.kerberos.user.hive.shortname", "value": "hive" },



{ "name": "internal.kerberos.user.hive.groups", "value": "hadoop" }, { "name": "internal.kerberos.user.jhs.name", "value": "jhs@EXAMPLE_HDFS.EMC.COM" }, { "name": "internal.kerberos.user.jhs.shortname", "value": "mapred" }, { "name": "internal.kerberos.user.jhs.groups", "value": "hadoop" }, { "name": "internal.kerberos.user.nm.name", "value": "nm@EXAMPLE_HDFS.EMC.COM" }, { "name": "internal.kerberos.user.nm.shortname", "value": "yarn@EXAMPLE_HDFS.EMC.COM" }, { "name": "internal.kerberos.user.nm.groups", "value": "hadoop" }, { "name": "internal.kerberos.user.nn.name", "value": "nn@EXAMPLE_HDFS.EMC.COM" }, { "name": "internal.kerberos.user.nn.shortname", "value": "hdfs@EXAMPLE_HDFS.EMC.COM" }, { "name": "internal.kerberos.user.nn.groups", "value": "hadoop,hdfs" }, { "name": "internal.kerberos.user.rm.name", "value": "rm@EXAMPLE_HDFS.EMC.COM" }, { "name": "internal.kerberos.user.rm.shortname", "value": "yarn@EXAMPLE_HDFS.EMC.COM" }, { "name": "internal.kerberos.user.rm.groups", "value": "hadoop" }, { "name": "internal.kerberos.user.spark.name", "value": "spark@EXAMPLE_HDFS.EMC.COM" }, { "name": "internal.kerberos.user.spark.shortname", "value": "spark" }, { "name": "internal.kerberos.user.spark.groups", "value": "hadoop" }, { "name": "internal.kerberos.user.yarn.name", "value": "yarn@EXAMPLE_HDFS.EMC.COM" },


安全なバケットメタデータ 187

{ "name": "internal.kerberos.user.yarn.shortname", "value": "yarn" }, { "name": "internal.kerberos.user.yarn.groups", "value": "hadoop" }, { "name": "internal.kerberos.user.zookeeper.name", "value": "zookeeper@EXAMPLE_HDFS.EMC.COM" }, { "name": "internal.kerberos.user.zookeeper.shortname", "value": "ams" }, { "name": "internal.kerberos.user.zookeeper.groups", "value": "hadoop" }, { "name": "hadoop.proxyuser.hcat.groups", "value": "*" }, { "name": "hadoop.proxyuser.hcat.hosts", "value": "*" }, { "name": "hadoop.proxyuser.yarn.users", "value": "*" }, { "name": "hadoop.proxyuser.yarn.hosts", "value": "*" }, { "name": "hadoop.proxyuser.hive.hosts", "value": "10.247.179.42" }, { "name": "hadoop.proxyuser.hive.users", "value": "*" }, { "name": "hadoop.proxyuser.hcat.groups", "value": "*" }, { "name": "hadoop.proxyuser.hcat.hosts", "value": "*" }, { "name": "dfs.permissions.supergroup", "value": "hdfs" } ]}

