emc ecs elastic cloud storage · 2020. 3. 12. · 連携へのvdcの追加 ... ecs...

EMC ECS（Elastic Cloud Storage）バージョン 2.0

ECS ドキュメント302-001-980

01

Copyright © 2013-2015 EMC Corporation. All rights reserved.（不許複製・禁無断転載）

2015 年 6 月発行

EMC Corporation は、この資料に記載される情報が、発行日時点で正確であるとみなしています。この情報は予告なく変更されることがあります。

この資料に記載される情報は、「現状有姿」の条件で提供されています。EMC Corporation は、この資料に記載される情報に関する、どのような内容についても表明保証条項を設けず、特に、商品性や特定の目的に対する適応性に対する黙示の保証はいたしません。

EMC²、EMC、および EMC ロゴは、米国およびその他の国における EMC Corporation の登録商標または商標です。他のすべての名称ならびに製品についての商標は、それぞれの所有者の商標または登録商標です。

ご使用の製品に関する規制等についての新情報は、EMC オンラインサポート（https://support.emc.com）を参照してください。

EMC ジャパン株式会社〒 151-0053 東京都渋谷区代々木 2-1-1新宿マインズタワーhttp://japan.emc.comお問い合わせはhttp://japan.emc.com/contact

2 EMC ECS（Elastic Cloud Storage） 2.0 ECS ドキュメント

新情報 11

ECS 2.0 の新機能 13

新機能.......................................................................................................... 14

概念 17

ECS について 19

概要..............................................................................................................20ECS プラットフォーム...................................................................................... 20

ポータルサービス............................................................................ 20ストレージサービス ......................................................................... 21プロビジョニングサービス.................................................................21ファブリックサービス........................................................................ 21インフラストラクチャサービス............................................................21

データ保護の概要 23

概要..............................................................................................................24ストレージサービス....................................................................................... 24オブジェクトの作成........................................................................................ 24オブジェクトの読み取り..................................................................................27消失符号化...................................................................................................28ディスクおよびノード障害のリカバリ............................................................... 29サイトのフェイルオーバーとリカバリ............................................................... 30

インストールとアップグレード 31

インストールの計画 33

概要..............................................................................................................34サイトでの準備..............................................................................................34ECS のインストール準備チェックリスト............................................................ 34単一サイト内での ECS アプライアンスの接続 ................................................ 34複数サイトの要件..........................................................................................36

構成と管理 37

ECS ポータルの準備 39

概要..............................................................................................................40ECS ポータルへのログイン.............................................................................40パスワードの変更..........................................................................................41ポータルエリアへのアクセス......................................................................... 41ポータルでのテーブルの並べ替えと検索....................................................... 44

第 1 部

第 1 章

第 2 部

第 2 章

第 3 章

第 3 部

第 4 章

第 4 部

第 5 章

目次

EMC ECS（Elastic Cloud Storage） 2.0 ECS ドキュメント 3

ストレージプール、VDC、レプリケーショングループの構成 47

ストレージプール、VDC、レプリケーショングループの構成.............................48ストレージプール.......................................................................................... 48

ストレージプールを作成する............................................................ 49VDC（仮想データセンター）............................................................................. 49

単一サイトへの VDC の作成............................................................. 50連携への VDC の追加...................................................................... 51サイトのフェイルオーバー/VDC の削除............................................. 51

レプリケーショングループ..............................................................................52レプリケーショングループの作成......................................................52

ConnectEMC の構成......................................................................................53

ユーザーの追加と役割の割り当て 55

概要..............................................................................................................56ECS のユーザーと役割について ....................................................................56

ECS ユーザー................................................................................... 56ユーザーの役割...............................................................................58ドメインユーザーとローカルユーザー...............................................58ユーザースコープ：グローバルまたはネームスペース......................59

ECS ポータルでのユーザーの操作.................................................................60新しいオブジェクトユーザーの追加.................................................. 62オブジェクトユーザーとしてのドメインユーザーの追加..................... 63ローカル管理ユーザーの作成または管理役割へのドメインユーザーの割り当て...........................................................................................64ネームスペース管理者の作成.......................................................... 65

ECS ポータルでの認証プロバイダーの操作....................................................65認証プロバイダーの追加..................................................................66認証プロバイダーの設定..................................................................67認証プロバイダーを追加する際の考慮事項......................................70

ネームスペースへのユーザーのマッピングの概要......................................... 71ネームスペースへのドメインユーザーのマップ................................. 73

テナントのネームスペースの構成 75

概要..............................................................................................................76テナントの概要.............................................................................................. 76ネームスペースの設定について.....................................................................77ECS ポータルでのネームスペースの操作.......................................................78ネームスペースの作成と構成........................................................................ 78

ライセンスファイルの取得と ECS ポータルへのアップロード 81

ライセンス..................................................................................................... 82EMC ECS ライセンスファイルの取得...............................................................82

テナントの管理 83

概要..............................................................................................................84クォータ......................................................................................................... 84保存期間と保存ポリシー............................................................................... 85バケットとユーザーのロック............................................................................86測定..............................................................................................................87バケットの監査.............................................................................................. 88

第 6 章

第 7 章

第 8 章

第 9 章

第 10 章

目次


EC サイトのフェイルオーバー 91

サイトのフェイルオーバー/VDC の削除.......................................................... 92

モニタ 93

リソースの監視：ハードウェア、ネットワークトラフィック、ディスク帯域

幅、ノード、プロセスの稼働状態 95

リソースの監視について................................................................................ 96監視ページの使用.........................................................................................96ハードウェアの監視....................................................................................... 98ネットワークトラフィックの監視.......................................................................99ディスク帯域幅の監視................................................................................. 100ノードとプロセスの稼働状態の監視............................................................. 102

ストレージの監視：測定と容量 105

概要............................................................................................................106監視ページの使用.......................................................................................106容量の監視.................................................................................................108

ストレージ容量データ..................................................................... 108測定データの監視....................................................................................... 110

測定データ.....................................................................................111

サービスログの監視 113

サービスログ.............................................................................................. 114ECS サービスログの場所............................................................................ 114

サービスの監視：チャンク、消失符号化、ジオレプリケーション、リカバリ

ステータス 115

サービス監視について.................................................................................116監視ページの使用.......................................................................................116チャンクの監視............................................................................................118消失符号化の監視......................................................................................119リカバリステータスの監視........................................................................... 120ジオレプリケーションの監視：レートおよびチャンク......................................121ジオレプリケーションの監視： RPO（Recovery Point Objective：目標復旧時点）................................................................................................................... 122ジオレプリケーションの監視：フェイルオーバー...........................................123ジオレプリケーションの監視：ブートストラップ処理...................................... 124

イベントの監視：監査ポータル、API、CLI イベント、システムアラート 127

イベント監視について.................................................................................. 128日付によるイベントのフィルターと列による結果の並べ替え..........................128

データアクセスの有効化 129

ECS オブジェクトストレージのアドレス指定とベース URL の使用 131

はじめに......................................................................................................132

第 11 章

第 5 部

第 12 章

第 13 章

第 14 章

第 15 章

第 16 章

第 6 部

第 17 章

目次


バケットのアドレス指定................................................................................132DNS の構成................................................................................... 133ベース URL.....................................................................................133

ベース URL の追加...................................................................................... 135ベース URL の例.............................................................................136

バケットの作成と構成 137

はじめに......................................................................................................138バケットの概念と属性.................................................................................. 138バケットの ACL.............................................................................................140ECS ポータルを使用したバケットの作成....................................................... 142バケットの編集............................................................................................ 143ユーザーのバケット ACL 権限の設定........................................................... 143定義済みグループのバケット ACL 権限の設定............................................. 144オブジェクト API を使用したバケットの作成...................................................145

S3 API を使用したバケットの作成（s3curl 使用）.............................. 145バケットとキーの命名規則........................................................................... 148

ECS の S3 バケットおよびオブジェクトの名前　................................ 148ECS の OpenStack Swift コンテナーおよびオブジェクトの名前　...... 149ECS の Atmos バケットおよびオブジェクトの名前　.......................... 149ECS の CAS プールおよびオブジェクトの名前　................................150

オブジェクトストレージアクセス用の秘密キーの取得 151

概要............................................................................................................152オブジェクトユーザーのキーの作成.............................................................152

ECS ポータルからの秘密キーの作成.............................................. 152ECS 管理 REST API を使用した S3 秘密キーの作成.........................152

S3 秘密キーの作成：セルフサービス..........................................................153セルフサービスキーの操作...........................................................153

ECS ポータルを使用した CAS SDK アプリケーションサポートの構成 157

ECS での CAS サポートの設定..................................................................... 158での CAS の保存 ECS への保存...................................................................158ネームスペースの保存ポリシーの設定........................................................ 160CAS のバケットの設定................................................................................. 161CAS オブジェクトユーザーの設定................................................................ 161ユーザーのバケット ACL の設定...................................................................162ECS CAS ユーザーをサポートする REST API..................................................165

ECS HDFS の構成 167

HDFS の概要 169

ECS HDFS とは.............................................................................................170ECS HDFS を使用するための Hadoop の構成 ................................ 171ECS HDFS URI：ファイルシステムアクセス用................................... 171Hadoop 認証モード........................................................................ 172ファイルシステムとの対話操作...................................................... 175未サポートの Hadoop アプリケーション...........................................175

安全ではない Hadoop クラスター内の HDFS の構成 177

第 18 章

第 19 章

第 20 章

第 7 部

第 21 章

第 22 章

目次


ECS HDFS の構成........................................................................................ 178ECS HDFS と Hadoop との統合の計画............................................ 178ECS HDFS インストールおよびサポートパッケージの取得................179HDFS のバケットの作成.................................................................. 179ECS HDFS JAR の展開..................................................................... 180クラスターへの Cloudera パーセルを使用した Hadoop のインストール...................................................................................................... 181Hadoop core-site.xml ファイルの編集.............................................182HBASE hbase-site.xml の編集........................................................ 186

安全な Hadoop クラスター内の HDFS の構成 189

安全な Hadoop クラスターを構成して ECS HDFS を使用する方法 ................ 190ECS HDFS と安全な Hadoop クラスターの統合の計画..................... 190ECS HDFS インストールおよびサポートパッケージの取得................191セキュア HDFS のバケットの作成.................................................... 191セキュアクラスターへの ECS HDFS JAR の展開................................192セキュアクラスターへの Cloudera パーセルを使用した Hadoop のインストール......................................................................................... 193ECS サービスプリンシパルを使用した ECS データノードの構成...... 194core-site.xml の編集...................................................................... 197Kerberos の構成について...............................................................200ECS 管理ツールリファレンス...........................................................203

ECS HDFS 構成のトラブルシューティング 205

トラブルシューティング................................................................................. 206安全な Hadoop クラスターを使用した正しい AD/LDAP 構成の確認. 206AD ユーザーの権限が拒否される................................................... 206hbase 構成後のサービスの再起動.................................................207Pig テストの失敗： Kerberos プリンシパルを取得できない................ 207Kerberos のクライアント側ログの有効化......................................... 207KDC での Kerberos のデバッグ....................................................... 207クロックスキューの排除................................................................. 208

ECS HDFS コアサイトプロパティリファレンス 209

Hadoop ECS HDFS の core-site.xml のプロパティ......................................... 210単純認証モードの core-site.xml の例............................................. 214

ECS データへのアクセス 217

ECS Amazon S3 オブジェクトサービス API サポート 219

Amazon S3 API............................................................................................220S3 API のサポート対象およびサポート対象外の機能...................... 220API の拡張機能..............................................................................223S3 サービスでの認証..................................................................... 227SDK を使って S3 サービスにアクセス..............................................228

ECS OpenStack Swift オブジェクトサービス API サポート 231

OpenStack Swift API....................................................................................232サポート対象の OpenStack Swift 機能........................................... 232

第 23 章

第 24 章

第 25 章

第 8 部

第 26 章

第 27 章

目次


API の拡張機能..............................................................................233OpenStack バージョン 1.0 認証 ..................................................... 238OpenStack バージョン 2.0 認証...................................................... 239コンテナーに対する認証.................................................................241

ECS EMC Atmos オブジェクトサービス API サポート 243

EMC Atmos API のサポート対象機能............................................................244サポート対象の EMC Atmos REST API コール................................................244サポート対象外の EMC Atmos REST API コール............................................245EMC Atmos REST API コールのサブテナントサポート....................................246API の拡張機能........................................................................................... 247

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

REST API の使用 249

ECS 管理 REST API の使用 251

はじめに......................................................................................................252ECS 管理REST APIによる認証.......................................................................252

AUTH-TOKEN を使用した認証 .........................................................252cookie を使用した認証...................................................................253ログアウト...................................................................................... 254whoami..........................................................................................254

ECS 管理 REST API サマリー.........................................................................255

ハードウェアの保守 259

ECS ハードウェア 261

ECS アプライアンスのハードウェアコンポーネント........................................ 262ECS アプライアンスの構成とアップグレードパス...........................................265U シリーズの単相 AC 電源のケーブル接続 ................................................. 268U シリーズの三相 AC 電源のケーブル接続.................................................. 269スイッチ.......................................................................................................273

プライベートスイッチ： Arista 7048..................................................274パブリックスイッチ： Arista 7150S-24..............................................274パブリックスイッチ： Arista 7124SX................................................. 275

ネットワークケーブル接続...........................................................................275ノード.......................................................................................................... 276

サーバーの前面図......................................................................... 277サーバーの背面図......................................................................... 278

ラックとノードのホスト名...............................................................................280ディスクドライブ.......................................................................................... 281内蔵ディスクドライブ................................................................................... 281ディスクおよびエンクロージャ.......................................................................282

DAE のディスクドライブ.................................................................. 282LCC................................................................................................ 286ファンコントロールモジュール........................................................ 287ICM................................................................................................ 287DAE の電源....................................................................................289U シリーズの SAS ケーブル接続..................................................... 291

第 28 章

第 9 部

第 29 章

第 10 部

第 30 章

目次


U シリーズアプライアンスの ECS ストレージディスクの交換 295

ドライブ交換の計画..................................................................................... 296cs_hal list disks コマンドの出力結果........................................................... 296ドライブの交換............................................................................................ 297

サードパーティ製ハードウェアの ECS ストレージディスクの交換 307

ドライブ交換の計画..................................................................................... 308cs_hal list disks コマンドの出力結果........................................................... 308ドライブの交換............................................................................................ 309

U シリーズアプライアンスへの 60 ディスクアップグレードの追加 315

60 ディスクアップグレードの計画................................................................ 316cs_hal コマンド............................................................................................ 32060 ディスクアップグレードの実行................................................................ 321

ECS サードパーティラック要件 327

ECS サードパーティラック要件.................................................................... 328

第 31 章

第 32 章

第 33 章

第 34 章

目次


第 1 部

新情報

第 1 章, "ECS 2.0 の新機能 "

新情報 11

新情報


第 1 章

ECS 2.0 の新機能

l 新機能.................................................................................................................. 14

ECS 2.0 の新機能 13

新機能ECS 2.0 の新機能と機能拡張について説明します。

コントローラー

以前のリリースでは、ECS は ViPR コントローラーを使用して許可、認証、ライセンス、ログなどの多数のサービスを提供していました。これらの機能は、現在は ECS の一部になり、ViPR は不要になりました。

さらに、ECS アプライアンスの初のノードがすべてのノードのインストーラーとして機能するため、ECS をインストールする仮想マシンも不要になりました。

ポータル

ECS は、以前は ViPRUI から構成していました。 ECS 2.0 では、構成、管理、監視の機能をECS およびそのテナントに提供するための新しいポータルが用意されています。

監視と診断

ECS は、包括的な監視と診断の機能を ECS ポータルと ECS API から提供するようになりました。次の機能がサポートされます。

l 測定

n ネームスペースとバケットの使用率の測定

n 時間に基づく、容量、帯域幅、オブジェクト数別のネームスペースとバケットの測定

l 容量使用率

n ストレージプール使用率の監視

l 物理環境の監視

n ノードとディスクの稼働状態の監視

n ノードの稼働状態（CPU、メモリ、NIC の使用状況）の監視

n プロセスの稼働状態の監視

l ストレージの効率性

n 消失符号化ジョブパフォーマンスの監視

n チャンクレベル使用状況の監視

n リカバリ操作の監視

n ストレージ操作（消失符号化、XOR を使用したジオ削除、リカバリ）に関するバックエンドトラフィックの監視

l ジオレプリケーションの監視

n レプリケーションの監視

n フェイルオーバーの監視

n ブートストラップの監視

ジオ機能拡張

次の機能拡張によって、ECS のジオレプリケーションメカニズムが使いやすくなりました。

l ジオ機能拡張：サイトの一時フェイルオーバー（14 ページ）

l ジオ機能拡張： RPO（目標復旧時点）の向上（15 ページ）

l ジオ機能拡張：ジオキャッシュによる複数サイトへのアクセスパフォーマンスの向上（15 ページ）

ジオ機能拡張：サイトの一時フェイルオーバー

ECS 2.0 では、自動化された高度な方法でサイトの障害とフェイルバックを一時的に処理します。この新機能を使用すると、連携した VDC 間が接続されていなくても、アプリケーション



からデータにアクセスできます。サイトがダウンしているときの新しいバケットの作成などの、一部の操作には制限があります。 ECS では、すべてのサイトが稼働して相互に接続しているときに、サイトが自動的に再同期され、データが調整されます。

ジオ機能拡張： RPO（目標復旧時点）の向上

ECS 2.0 より前では、ECS オブジェクトチャンクはサイズが固定され（128MB）、チャンクが満杯になった場合のみ封印されてリモートサイトにレプリケートされていました。この戦略は効率的ですが、サイト全体やラックがダウンした場合に、レプリケートされていない 128MB未満のデータのチャンクが多数発生することがあるという欠点がありました。これを克服するために、ECS 2.0 では、チャンクでデータの受信が開始されるとすぐにレプリケーションプロセスが開始されるようになりました。

ジオ機能拡張：ジオキャッシュによる複数サイトへのアクセスパフォーマンスの向上

ECS 2.0 より前では、複数の VDC が連携している場合にオブジェクトを読み取るには、オブジェクトを所有している VDC に戻る必要がありました。これでは、別のサイトのユーザーがデータにアクセスするたびに、WAN 帯域幅の面でコストがかかり、WAN のレーテンシーによってパフォーマンスが遅くなります。

ECS 2.0 では、セカンダリサイトでのオブジェクトのキャッシュによってこの問題を解決しているため、WAN 転送を使用せずにローカルでデータにアクセスできます。

オブジェクトの測定

オブジェクトの測定によって、テナントおよびテナントに関連づけられたバケットに関する主要な統計を取得できます。測定対象のデータには、容量、オブジェクト数、作成済みオブジェクト数、削除済みオブジェクト数、帯域幅（インバウンドとアウトバウンド）などがあり、特定のポイントインタイムや時間の範囲で取得できます。

保存ポリシー

オブジェクトコンテナーとオブジェクトに保存期間を適用して、指定した期間内に重要なデータが変更されるのを防止できます（オブジェクトコンテナーとは、Amazon S3 のバケット、OpenStack Swift のコンテナー、EMC Atmos のサブテナントを指します）。 ECS にはポリシーを定義してオブジェクトに適用する機能も用意されているため、指定した期間ではなく、定義したポリシーに従って保存期間を適用できます。

クォータ管理

バケットやネームスペースに対してクォータの限度を設定できます。このため、テナントでストレージの大量を指定してそれをネームスペースに使用したり、クォータを制限したバケットをテナントで作成したりできます。ハードクォータとソフトクォータは、ハード制限を適用する前に、レコードとイベントに対して個別にも一緒にも適用できます。

バケットとユーザーのロック

ECS 管理 REST API を使用すると、アクセスを防止する手段として、バケットおよびユーザーレベルでロックを適用できます。

バケットの監査

バケットの監査機能があるため、バケット操作の作成、更新、削除が可能で、バケットアクセスパーミッションの変更が記録されます。

ラックレベルの認識の有効化

ラックを個別の障害ドメインとして扱い、オブジェクトストアのチャンクをドメイン間で分散させて、ラックの故障がサイト全体の障害を引き起こすのを防止できます。


新機能 15

第 2 部

概念

第 2 章, "ECS について"

第 3 章, "データ保護の概要"

概念 17

概念


第 2 章

ECS について

l 概要......................................................................................................................20l ECS プラットフォーム.............................................................................................. 20

ECS について 19

概要ECS は、包括的なソフトウェアデファインドクラウドストレージプラットフォームであり、コモディティハードウェア上の膨大な非構造化データのストレージ、処理、分析をサポートします。 ECS は、モバイル、クラウド、ビッグデータ、ソーシャルネットワーキングの各アプリケーションに対応できるように特別に設計されており、ターンキーストレージアプライアンスとして、または要件を満たすコモディティサーバーとディスクのセット上にインストール可能なソフトウェア製品として導入できます。

ECS スケールアウト地理的分散アーキテクチャは、次の特長を持つクラウドプラットフォームです。

l パブリッククラウドよりも低コスト

l ストレージの効率性とデータアクセスの優れた組み合わせ

l 場所を問わない読み取り/書き込みアクセスにより、整合性が確保され、アプリケーションの展開が容易

l 単一障害点がなく、可用性とパフォーマンスが向上

l 自在にアクセス可能なため、ストレージサイロや ETL/データ移行処理不足を解消

ECS プラットフォームECS プラットフォームには、次のソフトウェアレイヤーとサービスがあります。

図 1 ECS プラットフォームサービス

ポータルサービス

ポータルサービスには、ストレージリソースのプロビジョニング、管理、監視用のインターフェイスが含まれています。以下のインターフェイスがあります。

l GUI：ポータルポータルと呼ぶ組み込み型でブラウザーベースの GUI。

l REST：独自のポータルポータルの開発に使用できる RESTful API。

l CLI（コマンドラインインタフェース）ブラウザーベースのインターフェイスと同じタスクを実行できるコマンドラインインターフェイス。

ECS について


ストレージサービス

ストレージサービスは、USE（非構造化ストレージエンジン）によって提供されます。USEは、データの可用性を確保し、データの破損、ハードウェアの故障、データセンターの災害からデータを保護します。また、地理的に分散したデータセンター間のグローバルネームスペースの管理と、ジオレプリケーションを実現します。 USE では、次のストレージサービスが可能です。

l オブジェクトサービス：非構造化データの格納、アクセス、処理の機能を提供します。オブジェクトサービスは、既存の Amazon S3、OpenStack Swift API、EMC CAS API、EMC Atmos API と互換性があります。

l HDFS：ポータルストレージインフラストラクチャをビッグデータリポジトリとして使用できるようにします。このリポジトリには、Hadoop 分析アプリケーション（インプレース）を実行できます。

プロビジョニングサービス

プロビジョニングサービスは、ストレージリソースとユーザーアクセスのプロビジョニングを管理します。具体的には、以下を処理します。

l ユーザー管理：システムの管理、ストレージリソースのプロビジョニング、REST リクエストによるオブジェクトへのアクセスに関する権限を持つユーザーを継続的に追跡します。ポータルは、ローカルユーザーとドメインユーザーの両方をサポートします。

l すべてのプロビジョニングリクエストの許可と認証：認証ドメインのクエリーを実行して、ユーザーが管理、プロビジョニング、アクセスの操作の実行を許可されているかどうかを確認します。

l リソース管理：許可されたユーザーがストレージプール、仮想データセンター、レプリケーショングループを作成できるようにします。

l マルチ・テナント：テナントを表すネームスペースとその関連バケット/オブジェクトを管理します。

ファブリックサービス

ファブリックサービスは分散型クラスターマネージャーであり、以下を処理します。

l クラスターの稼働状態：ノード固有のハードウェア障害を集計し、クラスター全体の稼働状態についてレポートします。

l ノードの稼働状態：ノードの物理的な状態を監視し、障害を検知およびレポートします。

l ディスクの稼働状態：ディスクとファイルシステムの稼働状態を監視します。ストレージエンジンの高速ロックフリー raw 読み取り/書き込み操作が実行され、各ディスクドライブとそのステータスについて個別に情報が表示されます。これにより、ストレージエンジンはストレージエンジンの組み込み型データ保護アルゴリズムに従って複数のディスクドライブにデータを配置できます。

l ソフトウェア管理：コマンドラインツールを使用して、サービスをインストールおよび実行したり、クラスターのノードでファブリックソフトウェアをインストールおよびアップグレードしたりすることができます。

インフラストラクチャサービス

このレイヤーは、コモディティノードで実行する Linux OS を提供し、ネットワークインターフェイスおよびその他のハードウェア関連ツールを実装します。

ECS について

ストレージサービス 21

ECS について


第 3 章

データ保護の概要

l 概要......................................................................................................................24l ストレージサービス............................................................................................... 24l オブジェクトの作成................................................................................................ 24l オブジェクトの読み取り.......................................................................................... 27l 消失符号化........................................................................................................... 28l ディスクおよびノード障害のリカバリ....................................................................... 29l サイトのフェイルオーバーとリカバリ....................................................................... 30

データ保護の概要 23

概要ECS でレプリケーションと消失符号化を使用してノード、ディスク、サイトの障害から非構造化データを保護する方法について説明します。

ECS は、オブジェクトとそのメタデータのコピーを 3 つ作成してローカルサイト内のノードセットに分散させることにより、オブジェクトの耐久性、信頼性、可用性を確保します。 3 つのコピーが正常に作成されると、ECS はストレージオーバーヘッドを減らすためにオブジェクトコピーを消失符号化します。障害とリカバリ操作は自動的に処理され、追加のバックアップソフトウェアやデバイスは不要です。

ストレージサービスストレージサービスレイヤーは、データの破損、ハードウェアの故障、データセンターの災害に備えて、データの可用性を確保し、データを保護します。

USE（非構造化ストレージエンジン）は、ストレージサービスレイヤーの一部です。各ノードで実行される分散型共有サービスである USE は、トランザクションを管理し、データをノードに保持します。 USE を使用すれば、地理的に分散したデータセンターでジオレプリケーションを利用したグローバルネームスペース管理が可能です。

USE は、すべてのオブジェクト関連データ（ユーザーデータ、メタデータ、オブジェクトの場所データなど）を、チャンクという連続ディスク領域の論理コンテナーに書き込みます。チャンクは、オープンの状態では書き込みを受け入れ、クローズの状態では書き込みを受け入れません。チャンクがクローズの状態になると、ストレージエンジンがチャンクの消失符号化を実行します。ストレージエンジンは追加専用パターンでチャンクに書き込むため、既存のデータが上書きされたり変更されたりすることはありません。この戦略により、I/O 操作でロックとキャッシュ確認が不要になるため、パフォーマンスが向上します。異なるチャンクへの書き込み中に、すべてのノードで同じオブジェクトに対する書き込み要求を同時に処理できます。

ストレージエンジンは、オブジェクト名、チャンク ID、オフセットを記録するインデックスを使用して、オブジェクトの場所を追跡します。チャンクの場所は、チャンク ID とディスクの場所を記録するインデックスによって個別に追跡されます。チャンクの場所のインデックスでは、消失符号化の前に 3 つのディスク場所ポインターが含まれ、消失符号化の後に複数の場所ポインターが含まれています。ストレージエンジンは、チャンクですべてのストレージ操作（消失符号化やオブジェクトリカバリなど）を実行します。

オブジェクトの作成オブジェクトの作成：単一の VDC次の図は、単一の VDC が存在する場合にストレージエンジンがオブジェクトデータを書き込む方法を示しています。この例では 1 台のアプライアンスがサイトに配置されていますが、複数のアプライアンスが配置された場合でも同じ原則が適用されます。単一のレプリケーショングループ内の単一のストレージプールに 8 つのノードが配置されています。



図 2 単一サイト：オブジェクトの作成

1. アプリケーションがバケット内にオブジェクトを作成します。

2. ストレージエンジンが 1 つのチャンクにオブジェクトを書き込みます。このチャンクに対応するディスクの場所は 3 つの異なるディスク/ノード上にあるため、書き込みはそれらのディスク/ノードに並列で実行されます。ストレージエンジンは、バケットのレプリケーショングループに属するノードのいずれかにオブジェクトを書き込むことができます。オブジェクトが作成された VDC は、オブジェクトの所有者です。

3. ストレージエンジンがチャンクのディスクの場所をチャンクの場所のインデックスに記録し、チャンク ID とオフセットをオブジェクトの場所のインデックスに記録します。

4. ストレージエンジンはオブジェクトの場所のインデックスを 1 つのチャンクに書き込み、チャンクに対応するディスクの場所を 3 つの異なるディスク/ノードに書き込むため、書き込みはそれらのディスク/ノードに並列で実行されます。インデックスの場所は、オブジェクトチャンクの場所とは無関係に選択されます。

5. ディスクの場所がすべて正常に書き込まれたら、ストレージエンジンがアプリケーションへの書き込みを確認応答します。

オブジェクトチャンクが満杯になると、ストレージエンジンがチャンクの消失符号化を実行します。オブジェクトの場所のインデックスチャンクの消失符号化は実行されません。

オブジェクトの作成：連携した VDC（2 サイト）

2 つの VDC が連携した環境では、ストレージエンジンがオブジェクトチャンクをローカルVDC とリモート VDC に書き込みます。


オブジェクトの作成 25

図 3 2 サイト：オブジェクトの作成


2. ストレージエンジンがオブジェクトをその送出サイトで 1 つのチャンクに書き込みます。このチャンクに対応するディスクの場所は 3 つの異なるディスク/ノード上にあるため、書き込みはそれらのディスク/ノードに並列で実行されます。ストレージエンジンは、バケットのレプリケーショングループに属するノードのいずれかにオブジェクトを書き込むことができます。ストレージエンジンがチャンクのディスクの場所をチャンクの場所のインデックスに記録し、チャンク ID とオフセットをオブジェクトの場所のインデックスに記録します。オブジェクトが初に送出されたサイトは、オブジェクトの所有者です。


4. ストレージエンジンが連携サイト内の 3 つのノードにチャンクをレプリケートします。また、オブジェクトの場所のインデックス（この図には表示されていません）にあるチャンクの場所を連携サイトの 3 つの異なるノードにも記録します。

チャンクが満杯になると、ストレージエンジンがオブジェクトチャンクの消失符号化を実行します。オブジェクトの場所のインデックスチャンクの消失符号化は実行されません。

レプリケーショングループに 2 つの VDC がある場合は、両方の VDC にオブジェクトの読み取り可能コピーが存在します。



3 サイト：オブジェクトの作成

図 4 オブジェクトの作成：連携した VDC（3 サイト以上）


2. ストレージエンジンがオブジェクトをその送出サイトで 1 つのチャンクに書き込みます。このチャンクに対応するディスクの場所は 3 つの異なるディスク/ノード上にあるため、書き込みはそれらのディスク/ノードに並列で実行されます。ストレージエンジンは、バケットのレプリケーショングループに属するノードのいずれかにオブジェクトを書き込むことができます。ストレージエンジンがチャンクのディスクの場所をチャンクの場所のインデックスに記録し、チャンク ID とオフセットをオブジェクトの場所のインデックス（この図には表示されていません）に記録します。書き込みを受信した VDC はオブジェクトの所有者であり、その VDC にはオブジェクトの読み取り可能コピーが含まれます。


4. ストレージエンジンがレプリケーショングループ内の別の VDC のノードにチャンクをレプリケートします。ストレージの効率性を向上させるために、ストレージエンジンは、そのチャンクと他のチャンク（ノードに保存されている他のオブジェクトのチャンク）に対してXOR を実行します。

チャンクが満杯になると、ストレージエンジンが XOR 実行済みチャンクの消失符号化を実行します。可能な場合は、レプリケーションを実行せずに、XOR チャンクを消失符号化形式で直接書き込みます。オブジェクトの場所のインデックスチャンクの消失符号化は実行されません。

オブジェクトの更新

アプリケーションによってオブジェクトが完全に更新されると、ストレージエンジンは（前述の原則に従って）新しいオブジェクトを書き込みます。次に、ストレージエンジンは、新しい場所を示すようにオブジェクトの場所のインデックスを更新します。古い場所は、これ以降インデックスから参照されません。元のオブジェクトはガベージコレクションで使用できます。

オブジェクトの読み取りオブジェクトの読み取り：単一の VDC単一サイト環境では、クライアントから読み取り要求が送信されると、ストレージエンジンはオブジェクトの場所のインデックスを使用してオブジェクト保存チャンクを検索し、チャンクまたは消去符号化フラグメントを取得し、オブジェクトを再構築してクライアントに返します。


オブジェクトの読み取り 27

オブジェクトの読み取り：連携した VDC（2 サイト）

2 サイト連携環境では、アプリケーションが接続されている VDC のノードから、ストレージエンジンがオブジェクトチャンクまたは消去符号化フラグメントを読み取ります。 2 サイト連携環境では、オブジェクトチャンクは両方のサイトに存在します。

オブジェクトの読み取り：連携した VDC（3 サイト以上）

読み取り要求中のアプリケーションがオブジェクト所有 VDC に接続されている場合は、ストレージエンジンが VDC のノードからオブジェクトチャンクまたは消去符号化フラグメントを読み取ります。読み取り要求中のアプリケーションがオブジェクト所有 VDC に接続されていない場合は、ストレージエンジンがオブジェクト所有 VDC からオブジェクトチャンクまたは消去符号化フラグメントを取得し、それらをアプリケーションが接続されている VDC にコピーし、オブジェクトをアプリケーションに返します。オブジェクトに対して別の読み取り要求が行われた場合に備えて、ストレージエンジンはオブジェクトのコピーをキャッシュに保存します。別の読み取り要求が行われると、ストレージエンジンはキャッシュ内のオブジェクトのタイムスタンプとオブジェクト所有 VDC 内のオブジェクトのタイムスタンプを比較します。タイムスタンプが同じ場合は、ストレージエンジンはオブジェクトをアプリケーションに返します。タイムスタンプが異なる場合は、ストレージエンジンはオブジェクトを再度取得してキャッシュに保存します。

消失符号化ECS は、データ保護を損なうことなくストレージの効率性を上げるために消失符号化を使用します。

ストレージエンジンはリードソロモン 12/4 消失符号化スキームを実装しており、オブジェクトは 12 個のデータフラグメントと 4 個の符号化フラグメントに分けられます。結果として生成される 16 個のフラグメントは、ローカルサイト内のノードに分散されます。ストレージエンジンは、12 個のフラグメントのいずれかからオブジェクトを再構築できます。

表 1 複数のサイト導入時のストレージオーバーヘッド

サイト数ストレージオーバーヘッド

1 1.33

2 2.67

3 2.00

4 1.77

5 1.67

6 1.60

7 1.55

8 1.52

ECS では、オブジェクトサービスを実行するノードが 1 つのサイトに 4 つ以上必要です。耐障害性はノードの数に基づきます。

表 2 1 つのサイトでのノードの耐障害性

総ノード数書き込みに対するノードの耐障害性

4 1

8～24 2



表 2 1 つのサイトでのノードの耐障害性（続き）

オブジェクトが消失符号化されると、元のチャンクデータは、クラスター全体に分散された16 個のフラグメントからなる単一コピーとして存在します。オブジェクトが消失符号化されていれば、ECS はデコードまたは再構築なしでオブジェクトを直接読み取ることができます。ハードウェア障害が発生した場合は、ECS はコードフラグメントのみを使用してオブジェクトを再構築します。

ディスクおよびノード障害のリカバリECS は、クラスターに格納されているノード、ディスク、オブジェクトの稼働状態を継続的に監視します。 ECS ではデータ保護の役割をクラスター全体に分散させているため、ノードやディスクの障害時に危険な状態にあるオブジェクトを自動的に再保護できます。

ディスクの稼働状態

ECS では、ディスクの稼働状態を「Good」、「Suspect」、「Bad」でレポートします。

l Good：良い。ディスクのパーティションに対して、読み取りも書き込みも実行できます。

l Suspect：疑わしい。ディスクはまだ、悪い状態であると判断されるような閾値には達していません。

l Bad：悪い。ハードウェアのパフォーマンス低下を示す特定の閾値に達しています。一度閾値に達すると、データは読み取りも書き込みもできなくなります。

ECS は、良い稼働状態にあるディスクに対してのみ書き込みを実行し、疑わしいまたは悪い稼働状態にあるディスクに対しては書き込みを実行しません。 ECS は、良いおよび疑わしい稼働状態にあるディスクからの読み取りを実行します。オブジェクトのチャンクのうち 2 つが疑わしいディスクにある場合、ECS はそれらのチャンクを他のノードに書き込みます。

ノードの稼働状態

ECS では、ノードの稼働状態を「Good」、「Suspect」、「Degraded」、「Bad」でレポートします。

l Good：ノードは利用可能で、I/O 要求に適切なタイミングで応答しています。内部稼働状態のモニタリングで、良好な状態にあることが示されています。

l Suspect：ノードは利用可能ですが、1 つのファンの障害（ファンが複数ある場合）や、1つの電源の障害（冗長電源がある場合）などの内部稼働状態の情報のレポートがあります。または、ノードは他のノードからアクセス不可能であるにもかかわらず、BMC プローブには表示され、状態は不明となります。

l Degraded：ノードは利用可能ですが、ディスクの状態が悪いまたは疑わしいとレポートされています。

l Bad：ノードはアクセス可能ですが、内部の稼働状態モニタリングによると、稼働状態は良くありません。たとえば、ノードのファンがオフラインである、CPU の温度が高すぎる、メモリエラーが多すぎるなどの状態にあります。また、ノードがオフラインである場合や、許容できない稼働状態であると BMC プローブに示された場合にも、悪い稼働状態であるとレポートされることがあります。

ECS は、良い稼働状態にあるノードに対してのみ書き込みを実行し、疑わしい状態、縮退状態、悪い稼働状態にあるノードに対しては書き込みを実行しません。 ECS は、良いおよび疑わしい稼働状態にあるノードからの読み取りを実行します。オブジェクトのチャンクのうち 2つが疑わしいノードにある場合、ECS は 2 個の新しいチャンクを他のノードに書き込みます。 1 つのノードが疑わしいまたは悪い稼働状態にあるとレポートされた場合、そのノードが管理するディスクもすべて、疑わしいまたは悪い稼働状態にあると見なされます。

データリカバリ

サイトのノードまたはドライブで障害が発生すると、ストレージエンジンは次のことを実行します。


ディスクおよびノード障害のリカバリ 29

1. 障害の影響を受けるチャンクまたは EC フラグメントを識別します。

2. 影響を受けるチャンクまたは EC フラグメントのコピーを、現在コピーのない良好な稼働状態のノードとディスクに書き込みます。

サイトのフェイルオーバーとリカバリECS は、災害やその他の問題（サイトがオフラインになったり、地理的に連携した環境で他のサイトとの接続が切断されたりすること）が原因のサイトの障害に対する保護を提供します。

一時的なサイトの障害

一時的なサイトの障害は、連携した VDC 間でのネットワーク接続の切断や VDC の一時的な停止によって発生します。 VDC が停止すると、［Replication Group］ページでは、アクセスできない VDC に Temporarily unavailableステータスが表示されます。

バケットが構成され、［Access During Outage］プロパティが［On］に設定されている場合は、あらゆるサイトに接続して、アプリケーションでオブジェクトを読み取ることができます。バケットの所有者ではないサイトに接続されたアプリケーションでバケットの書き込みやコンテンツの表示を行うには、アプリケーションで明示的にバケットにアクセスする必要があります。所有者ではない VDC に接続されたアプリケーションでオブジェクトやバケットを変更すると、変更が開始されたサイトにストレージエンジンが所有権を転送します。

以下の操作は、［Access During Outage］の設定に関係なく、一時的な障害が解決されるまで、地理的に連携したサイトで完了できません。

l バケット：バケットの作成や名前変更、バケットのプロパティの変更、ネームスペース所有者サイトにアクセスできない場合のネームスペースのバケットのリスト

l Namespace： create

l ユーザー： create

サイトが再接続されると、ストレージエンジンがバックグラウンドで再同期操作を開始します。ポータルの［Monitor］ > ［Recovery Status］を使用して、再同期操作の進行状況を監視します。

永続的なサイトのフェイルオーバー

サイトで災害が発生し、VDC をオンラインに戻せない場合は、VDC を削除する必要があります。



第 3 部

インストールとアップグレード

第 4 章, "インストールの計画"

インストールとアップグレード 31

インストールとアップグレード


第 4 章

インストールの計画

l 概要......................................................................................................................34l サイトでの準備......................................................................................................34l ECS のインストール準備チェックリスト.................................................................... 34l 単一サイト内での ECS アプライアンスの接続 ........................................................ 34l 複数サイトの要件..................................................................................................36

インストールの計画 33

概要物理環境、データセンター、複数サイトの要件と、プライベート管理ネットワークトポロジーについて説明します。

サイトでの準備サイト準備ガイドを参照して、ECS アプライアンスで使用する 40U-D キャビネットに関連した環境要件を確認します。

ECS のインストール準備チェックリストこのリストを参照して、正常なインストールに必要なインフラストラクチャコンポーネントを確認してください。

ECS アプライアンスの導入は、次のコンポーネントで構成されます。

l 1 個以上のラック。

n ラックは、データトラフィックとリモート管理の両方についてお客様のネットワークにアップリンクされている必要があります。

ラックとすべてのノードの電源をオンにする必要があります。

ノードは、DHCP によって有効な IP アドレスが割り当てられているか、静的に構成されている必要があります。

l インフラストラクチャ要件：データセンター環境には、すべてのノードからアクセス可能な次のサーバーが設置されている必要があります。

n DHCP サーバー（DHCP を使用して IP アドレスを割り当てる場合）

n DNS サーバー（またはフォワーダー）

n NTP サーバー

n SMTP サーバー

SSH が、すべてのノードで有効である必要があります。

次のポートは開かれ、インストーラーによって使用されます。

l Docker レジストリ： 5000

l ライフサイクルエージェント： 9240

l Object: 9020～9025、9040、9091、9094～9098、8088、9898、1095、1096、1098、9100、9101、9111、3218

l ZooKeeper： 9277、9278、9279

開いていなければならないポートのリストについては、「セキュリティガイド」を参照してください。

単一サイト内での ECS アプライアンスの接続ECS アプライアンス管理ネットワークは、NAN（Nile Area Network）を経由して接続されています。 NAN は、ポート 51 またはポート 52 を別の ECS アプライアンスの別の Turtle スイッチに接続して作成されています。この接続を使用して、すべてのセグメントのノードは NAN内の他のノードと通信できます。



https://support.emc.com/docu34561_40U-D-Cabinet-Site-Preparation-Guide.pdf?language=en_US

この極めてシンプルなトポロジーで複数の ECS アプライアンスを接続すると、余分なスイッチハードウェアは不要になります。すべての Turtle スイッチをリニアまたはデイジーチェーンで接続できます。

図 5 リニアまたはデイジーチェーンのトポロジー

このトポロジーでは、接続性が失われた場合にスプリットブレインが発生する可能性があります。

図 6 リニアまたはデイジーチェーンのスプリットブレイン

ネットワークの信頼性を高めるには、デイジーチェーントポロジーの端を接続してリングネットワークを作成します。リングトポロジーではケーブルリンクが 2 か所破損しないとスプリットブレインは発生しないため、リングトポロジーの方が安定します。リングトポロジーの主な欠点は、外部のお客様スイッチまたはアグリゲーションスイッチをリンクに追加しない限り、RMM ポートをお客様のネットワークに接続できないことです。

図 7 リングトポロジー

大規模な導入にはデイジーチェーントポロジーとリングトポロジーを推奨しません。 ECS アプライアンスが 4 台以上の場合は、アグリゲーションスイッチを推奨します。アグリゲーションスイッチをスター型トポロジーで追加すると、スプリットブレインの問題が減少して、フェイルオーバーを向上させることができます。


単一サイト内での ECS アプライアンスの接続 35

図 8 スター型トポロジー

複数サイトの要件複数サイトでの ECS のインストールを計画する場合は、次の要件を満たしてください。

l 2 つ以上の VDC が必要です。

l 複数サイト構成内の各 VDC は、他の VDC に IP 接続する必要があります。

n ネットワークレーテンシー：サイト間の大レーテンシーが 1,000 ミリ秒を超えないようにします。

n 空きストレージ： 1 つのサイトでの障害が継続した状態で（そのサイトをすぐにはリカバリせずに）運用を一定時間続けることが災害復旧計画に盛り込まれている場合は、全サイトにわたる空きストレージで各サイトのデータの再バランシングに対応できる必要があります。全サイトにわたって、合計で次の量の空き領域が残るようにしてください。

free space across n sites =1.33*x/(n-1)/(n-2)

この xは、全 n サイトのユーザーデータの総量です。

フェイルオーバーの直後に新しいサイトを追加し、n-1 サイトの運用を無期限に続けない場合は、この量の空き領域は必要ありません。



第 4 部

構成と管理

第 5 章, "ECS ポータルの準備 "

第 6 章, "ストレージプール、VDC、レプリケーショングループの構成"

第 7 章, "ユーザーの追加と役割の割り当て "

第 8 章, "テナントのネームスペースの構成 "

第 9 章, "ライセンスファイルの取得と ECS ポータルへのアップロード"

第 10 章, " テナントの管理 "

第 11 章, "EC サイトのフェイルオーバー"

構成と管理 37

構成と管理


第 5 章

ECS ポータルの準備

l 概要......................................................................................................................40l ECS ポータルへのログイン.....................................................................................40l パスワードの変更..................................................................................................41l ポータルエリアへのアクセス..................................................................................41l ポータルでのテーブルの並べ替えと検索............................................................... 44

ECS ポータルの準備 39

概要ECS ポータルでは、ECS の構成、管理、監視ができます。

また、テナントでネームスペースを管理および監視し、ネームスペース内のバケットを作成および構成する機能も提供します。

このポータルは、主に ECS の管理ユーザー、システム管理者、ネームスペース/テナント管理者がアクセスするように設計されています。オブジェクトストレージユーザーは、サポートされるオブジェクトプロトコルとそのプロトコルをサポートするクライアントを使用して ECSにアクセスします。 ECS のユーザーと役割の詳細については、ユーザーの追加と役割の割り当て（56 ページ）を参照してください。

ポータルではパブリック ECS 管理 REST API を利用でき、この API を使用して操作を実行するカスタムクライアントを開発できます。

ECS ポータルへのログインブラウザーから ECS ポータルにログインするには、クラスターのいずれかのノードの IP アドレスを指定します。

はじめに

l ECS ポータルには、システム管理者またはネームスペース管理者 ECS 役割が割り当てられている場合にログインできます。

l システム管理者の役割に割り当てられた「ルート」ユーザーアカウントは、初にアクセスするときに使用するものです。

非アクティブ状態が 15 分間続くと自動的にログアウトされます。

手順

1. システムの初のノードのパブリック IP アドレス、または ECS のフロントエンドとして構成されたロードバランサーのアドレスを、次の形式で入力します。（ http:/<node1_public_ip>参照）。

例： http://198.51.100.244ログイン画面が表示されます。



2. ユーザー名とパスワードを入力します。

初期のルート認証情報（root/ChangeMe）を使用してログインした場合は、パスワードを変更することをお勧めします。

ブラウザーを閉じるか、ログアウトすると、セッションが終了します。ログアウトは常にセッションを終了します。ログインできない場合は、管理者に連絡してください。

パスワードの変更ECS ポータルにログインしたときに、自分のパスワードを変更できます。

はじめに

システム管理者ユーザーとネームスペース管理者ユーザーは、［Password］ページにアクセスできます。

ルートユーザーとしてログインした場合のアカウントは、コマンドラインでノードにアクセスするときのルートアカウントとは異なります。このため、ここでパスワードを変更しても、ノードのルートアカウントのパスワードは変更されません。

手順

1. ECS ポータルで、［Settings］ > ［Password］を選択します。

2. ［Password］フィールドに新しいパスワードを入力し、確認のために再度入力します。

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

ポータルエリアへのアクセスポータルには、左側のナビゲーションメニューとページエリアがあります。

システム管理者は、すべてのページにアクセスできます。ネームスペース管理者は、アクセスできるページが限られ、テナントに固有の操作のみ実行できます。


パスワードの変更 41

以降のセクションで、管理ユーザー別にアクセス権について詳しく説明します。

l システム管理者（42 ページ）

l ネームスペース管理者（43 ページ）

システム管理者

次の表に、アクセスできるメニュー項目と、使用方法を詳しく説明したトピックへのリンクを示します。

エリアメニューサポートされる操作

モニタ Metering ネームスペースやバケットのオブジェクトの測定結果を

表示する。

ストレージプール、ノード、ディスクの容量を監視する。

詳細は、以下を参照してください。ストレージの監視：測定と容量（106 ページ）。

Capacity Utilization

Events 監査イベントを表示する。

詳細は、以下を参照してください。イベントの監視：監査

ポータル、API、CLI イベント、システムアラート（128 ペ

ージ）。

Traffic Metrics 次の監視の詳細情報を表示する。l 読み取り/書き込みの帯域幅とレーテンシーの監視l 各ストレージプールのストレージノードおよびディス

クステータスの監視l ノードとプロセスの稼働状態の監視（メモリおよび

CPU の使用率別）l ディスク帯域幅の使用の監視

詳細は、以下を参照してください。リソースの監視：ハードウェア、ネットワークトラフィック、ディスク帯域幅、ノ

ード、プロセスの稼働状態（96 ページ）

Hardware Health

Node and Process Health

Disk Bandwidth

Chunk Summary 次の監視の詳細情報を表示する。l チャンクとチャンクステータスの監視l 消失符号化ステータスの監視l リカバリステータスの監視l ジオレプリケーションアクティビティの監視

詳細は、以下を参照してください。サービスの監視：チャンク、消失符号化、ジオレプリケーション、リカバリステータス（116 ページ）。

Erasure Coding

Recovery Status

Geo Replication

管理 Storage Pools 次の操作を可能にする。l ストレージプールの追加と、それを構成するノード

の指定l VDC の追加と、その接続の詳細の定義l VDC に属するストレージプールの追加によるレプリ

ケーショングループの構成

詳細は、以下を参照してください。ストレージプール、

VDC、レプリケーショングループの構成（48 ページ）。

Virtual Data Center

Replication Group

Authentication ドメインユーザーを認証できる認証プロバイダーを追加

する。




ユーザーの追加と役割の割り当て（56 ページ）

Namespace 次の操作を可能にする。

l 新しいネームスペースの作成

l ネームスペースのクォータの設定

l ネームスペースへのオブジェクトユーザーのマップ

詳細は、以下を参照してください。テナントのネームス

ペースの構成（76 ページ）

Users 次の操作を可能にする。

l ネームスペースのオブジェクトユーザーの作成

l オブジェクトユーザーの編集

l 秘密キーを作成します。

詳細は、以下を参照してください。ユーザーの追加と役

割の割り当て（56 ページ）

Bucket 次の操作を可能にする。

l バケットの作成

l バケット所有者とオブジェクトユーザーへの ACL の

割り当て

詳細は、以下を参照してください。バケットの作成と構

成（138 ページ）

設定 Object Base URL オブジェクトアドレスのどの部分をバケットとネームスペ

ースにするかを決めるベース URL を設定する。

詳細は、以下を参照してください。 ECS オブジェクトスト

レージのアドレス指定とベース URL の使用（132 ペー

ジ）

Change Password 自分のパスワードを変更する。

詳細は、以下を参照してください。パスワードの変更

（41 ページ）

Connect EMC EMC へのイベントの送信を構成する。

Licensing ライセンスステータスを表示し、ライセンスをアップロー

ドする。

詳細は、以下を参照してください。ライセンスファイルの

取得と ECS ポータルへのアップロード（82 ページ）

ネームスペース管理者

次の表に、アクセスできるメニュー項目と、使用方法を詳しく説明したトピックへのリンクを示します。


モニタ Metering ネームスペースやバケットのオブジェクトの測定結果を

表示する。


ポータルエリアへのアクセス 43


詳細については、ストレージの監視：測定と容量（106ページ）を参照してください。

管理 Namespace ネームスペースを編集する。

詳細：テナントのネームスペースの構成（76 ページ）

Users 次の操作を可能にする。

l ネームスペースのオブジェクトユーザーの作成

l オブジェクトユーザーの編集

l オブジェクトユーザーの秘密キーの作成

詳細：ユーザーの追加と役割の割り当て（56 ページ）

Bucket 次の操作を可能にする。

l バケットの作成

l バケット所有者とオブジェクトユーザーへの ACL の

割り当て

詳細：バケットの作成と構成（138 ページ）

設定 Change Password 自分のパスワードを変更する。

詳細：パスワードの変更（41 ページ）

ポータルでのテーブルの並べ替えと検索ポータルに表示されるデータセットが大きい場合、特に複数ページに分かれているときなどは、テーブルを並べ替えて情報を検索すると便利です。

テーブルを含むページの例を次に示します。



テーブル列の並べ替え

選択した列の順序でテーブルの行を並べ替えることができます。テーブル列を並べ替えるには、テーブルヘッダーをクリックします。

テキストデータを含む列がアルファベット順にソートされます。たとえば、ユーザーテーブルの［Namespace］フィールドを選択すると、その列がアルファベット順に並び、その順序で行が表示されます。ページを再入力すると、デフォルトの順序が適用されます。同様に、ページを更新すると、ページはデフォルトの順序に戻ります。

検索の使用

検索機能により、一致するテキスト文字列でテーブル行をフィルタリングできます。

検索ボックスにテキストを入力すると、検索文字列に一致する文字列を含む行が表示されます。検索条件に一致する行の表示順序は、テーブル列の並べ替えで適用された順序に従います（テーブル列の並べ替え（45 ページ）を参照）。

ページの更新

テーブルデータを含むページには、更新用のコントロールがあります。更新すると、テーブルはデフォルトの順序に戻ります。


ポータルでのテーブルの並べ替えと検索 45

第 6 章

ストレージプール、VDC、レプリケーショングループの構成

l ストレージプール、VDC、レプリケーショングループの構成.....................................48l ストレージプール.................................................................................................. 48l VDC（仮想データセンター）..................................................................................... 49l レプリケーショングループ......................................................................................52l ConnectEMC の構成..............................................................................................53

ストレージプール、VDC、レプリケーショングループの構成 47

ストレージプール、VDC、レプリケーショングループの構成ポータルを使用して単一環境または連携環境のストレージプール、VDC、レプリケーショングループを作成、変更、削除する方法と、オブジェクトサービス用の ConnectEMC を構成する方法について説明します。

これらの手順を実行するユーザーには、システム管理者の役割が割り当てられている必要があります。

ストレージプールストレージプールを使用すれば、ビジネス要件に基づいてストレージリソースを整理できます。たとえば、データを物理的に分ける必要がある場合は、ストレージを複数のストレージプールに区分できます。

［Storage Pool Management］ページ（表示するには［Manage］ > ［Storage Pools］を選択）を使用して、既存のストレージプールの詳細表示、新しいストレージプールの作成、既存のストレージプールの変更、ストレージプールの削除を行います。

図 9 ［Storage Pool Management］ページ

表 3 ストレージプールのプロパティ

フィールド説明

Name ストレージプールの名前。

# Nodes ストレージプールに割り当てられたノードの数。

Status ストレージプールやノードの現在の状態。ストレージプールの状態には、次のも

のがあります。

l 準備完了： 4 つ以上のノードがインストールされており、すべてのノードが

ready to use状態になっている。

l Not Ready：ストレージプールのノードが ready to use状態になってい

ない。

l Partially Ready：インストールされているノードが 4 つ未満で、すべてのノー

ドが ready to use状態になっている。

Host Name ノードに割り当てられた完全修飾ホスト名。

Node IP address ノードに割り当てられたパブリック IP アドレス。

Rack ID ノードが設置されているラックに割り当てられた名前。



表 3 ストレージプールのプロパティ（続き）


Actions アクションは、

l ［Edit］：ストレージプールの名前やストレージプール内のノードを変更する

場合に使用。

l ［Delete］：ストレージプールを削除する場合に使用。ストレージプールを

削除するには、ストレージプール内のすべてのノードを削除しておく必要が

あります。システムストレージプール（初に作成されたストレージプール）

は、削除できません。システムストレージプールに空きノードがあり、ノード

数が 5 つ以上の場合は、空きノードを削除できます。

ストレージプールを作成する

ストレージプールにノードを割り当てるには、次の手順を実行します。ストレージプールには、4 つ以上のノードを配置する必要があります。作成された初のストレージプールは、システムメタデータを保存するため、システムストレージプールと呼ばれます。システムストレージプールは削除できません。

手順

1. ポータルで、［Manage］ > ［Storage Pools］を選択します。

2. ［New Storage Pool］をクリックします。

3. ストレージプール名を入力します（例： StoragePool1）。4. ［Available Nodes］リストから、ストレージプールに追加するノードを選択します。

a. ノードを 1 つずつ選択するには、各ノードの［+］アイコンをクリックします。

b. 使用可能なすべてのノードを選択するには、［Available Nodes］リストの上部にある［+］アイコンをクリックします。

c. 使用可能なノードのリストを絞り込むには、［search］フィールドにノードのパブリックIP アドレスまたはホスト名を入力します。

5. ノードの選択が完了したら、［Save］をクリックします。

6. ストレージプールが［Ready］状態になった後、10 分間待ってから、他の構成タスクを実行します。この間に、ストレージプールが初期化されます。

待機時間が十分でないと、次のエラーメッセージが表示されます。 Error 7000(http: 500): An error occurred in the API Service. An erroroccurred in the API service.Cause: error insertVdcInfo.Virtual Data Center creation failure may occur when DataServices has not completed initialization.

このエラーが表示された場合は、数分間待ってから、それ以降の構成を試行してください。

VDC（仮想データセンター）VDC は、論理構成です。ユニットとして管理する ECS インフラストラクチャのコレクションを示す上位のリソースです。

［Virtual Data Center Management］ページ（表示するには［Manage］ > ［Virtual DataCenters］を選択）を使用して、VDC の詳細表示、新しい VDC の作成、既存の VDC の変更、


ストレージプールを作成する 49

VDC の削除、複数サイト環境での複数の VDC の連携を行います。次の例は、連携させた複数サイト環境の［Manage Virtual Data Center］ページを示しています。 3 つのサイトで構成されています。 VDC は、vdc1、vdc2、vdc3 と命名されています。

図 10 VDC 管理ページ

表 4 VDC のプロパティ


Name VDC の名前。

Endpoints VDC を構成するストレージプール内にあるノードのパブリック IP アドレス。

Status 次のいずれかのステータス：

l Online

l Permanently Failed： VDC が削除されている。

Actions アクションは、

l ［Edit］： VDC の名前、アクセスキー、VDC のストレージプール内にあるノードの

パブリック IP アドレスを変更する場合に使用。

l ［Delete］： VDC を削除する場合に使用。削除操作を実行すると、VDC の永続的

なフェイルオーバーがトリガーされるため、同じ名前では再度追加できなくなりま

す。レプリケーショングループの一部になっている VDC を削除するには、まずレ

プリケーショングループからその VDC を削除する必要があります。ログインして

いる VDC は削除できません。

単一サイトへの VDC の作成

単一サイト環境に VDC を作成する場合や、複数サイト連携で初の VDC を作成する場合は、次の手順を実行します。

はじめに

1 つ以上のストレージプールが使用可能であり、Ready状態である必要があります。

手順

1. ECS ポータルで、［Manage］ > ［Virtual Data Center］を選択します。

2. ［New Virtual Data Center］をクリックします。

3. 名前を入力します（例： VDC1）。

名前にはスペースとアンダースコアは使用できません。

4. ［Get VDC Access Key］をクリックします。

VDC アクセスキーは、複数サイト連携の VDC 間でレプリケーショントラフィックを暗号化するための対称鍵として使用されます。



5. ［Endpoints］テキストボックスに、VDC のストレージプールにある各ノードのパブリックIP アドレスを入力します。コンマ区切りリストで入力してください。


連携への VDC の追加

既存の VDC（VDC1 など）に VDC（VDC2 など）を追加して連携を作成するには、次の手順を実行します。

はじめに

root ユーザーまたはシステム管理者認証情報を持つユーザーの［ECS ポータル］認証情報を取得し、両方のサイトにログインします。

追加するサイト（VDC2）のノードのパブリック IP アドレスリストがあることを確認します。

追加するサイト（VDC2）に、アップロードされた有効なライセンスと、Ready状態のストレー

ジプールがあることを確認します。

手順

1. 追加するサイト（VDC2）で［ECS ポータル］にログインします。

デフォルトの認証情報は root/ChangeMeです。

2. ［Manage］ > ［Virtual Data Center］を選択します。

3. ［Get VDC Access Key］をクリックします。

4. アクセスキーを選択し、Ctrl+C キーを押してコピーし、バッファーに保存します。

5. 追加するサイト（VDC2）で［ECS ポータル］からログアウトします。

6. 初の VDC（VDC1）の［ECS ポータル］にログインします。

7. ［Manage］ > ［Virtual Data Center］を選択します。

8. ［New Virtual Data Center］をクリックします。

9. VDC の名前を入力します（例： VDC2）。

10.［Key］フィールドをクリックし、上記の手順 3 と 4 で追加サイト（VDC2）からコピーしたキーを、Ctrl+V キーを押してペーストします。

11.追加するサイトのパブリック IP アドレスを入力します。コンマ区切りリストで入力してください。

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

サイトのフェイルオーバー/VDC の削除

VDC を削除するには、次の手順を実行します。複数サイトの連携の一部となっている VDCを削除すると、サイトのフェイルオーバーが開始します。

災害の発生時は、VDC 全体がリカバリ不能になる可能性があります。 ECS では、リカバリ不能な VDC を初は一時的なサイトの障害として処理します。障害が継続する場合は、連携から VDC を削除してフェイルオーバー処理を開始し、障害が発生した VDC に格納されたオブジェクトを再構築して再度保護する必要があります。リカバリタスクはバックグラウンド処理として実行されます。リカバリプロセスを確認するには、［Monitor］ > ［Geo Replication］ >［Failover Procesing］を使用します。

手順

1. 連携している操作可能な VDC のいずれかにログインします。

2. ［Manage］ > ［Replication Group］を選択します。


連携への VDC の追加 51

3. 削除する VDC が含まれたレプリケーショングループの［Edit］をクリックします。

4. 削除する VDC とストレージプールが含まれた行の［Delete］をクリックします。


6. ［Manage］ > ［VDC］を選択します。完全に削除された VDC のステータスがPermanently failedに変わります。

7. 削除する VDC の行のドロップダウンから［Delete］を選択します。


レプリケーショングループレプリケーショングループは、ストレージプールのコンテンツを保護する場所を定義する論理構成です。レプリケーショングループは、ローカルにもグローバルにも作成できます。ローカルレプリケーショングループは、同じ VDC 内のオブジェクトをディスクやノードの障害から保護します。グローバルレプリケーショングループは、オブジェクトをディスク、ノード、サイトの障害から保護します。

［Manage Replication Groups］ページを使用して、レプリケーショングループの詳細表示、新しいレプリケーショングループの作成、既存のレプリケーショングループの変更を行います。このリリースでは、レプリケーショングループの削除はできません。

図 11 ［Manage Replication Groups］ページ

表 5 レプリケーショングループのプロパティ


Name レプリケーショングループの名前。

VDC レプリケーショングループ内の VDC の数と、ストレージプールのある VDC の名

前。

Storage Pool ストレージプールと関連 VDC の名前。

Status 次のいずれかのステータス：

l Online

l Temp Unavailable：この VDC へのレプリケーショントラフィックに障害が発生。

同じ VDC へのすべてのレプリケーショントラフィックが［Temp Unavailable］状態の場合は、障害の原因を詳しく調査することをお勧めします。

Actions ［Edit］：レプリケーショングループ名を変更したり、レプリケーショングループ内の

VDC やストレージプールを変更したりする場合に使用。

レプリケーショングループの作成

レプリケーショングループを作成するには、次の手順を実行します。

グローバルレプリケーショングループを作成する場合は、複数の VDC からストレージプールを選択します。



手順

1. ［ECS ポータル］で、［Manage］ > ［Replication Group］を選択します。

2. ［New Replication Group］をクリックします。

3. 名前を入力します（例： ReplicationGroup1）。4. ［Add VDC］をクリックします。

5. ドロップダウンから、仮想データセンターとストレージプールを選択します。

この手順を繰り返して、オブジェクトの保護に必要な VDC とストレージプールを追加します。


ConnectEMC の構成ConnectEMC をオブジェクトサービス用に構成するには、次の手順を実行します。

手順

1. ポータルで、［Settings］ > ［ConnectEMC］をクリックします。

2. 転送タイプを選択し、通信を暗号化するかどうかを指定します。

3. 転送タイプが FTPS の場合は、次の表を参照して構成を完了します。

オプション説明

Encryption サービスデータを暗号化するかどうかを指定する。

Hostname corpusfep3.emc.comを指定する。

Email Server 環境で使用されている SMTP サーバーを指定する。

Email Addresses ConnectEMC サービスの通知送信先のメールアドレス。

4. 転送タイプが SMTP の場合は、次の表を参照して構成を完了します。


Encryption サービスデータを暗号化するかどうかを指定する。

Authentication SMTP サーバーを認証する認証タイプまたは［NONE］を選択する。認証が必要な場合、SMTP サーバーを認証するには、［UserName］と［Password］も指定する必要がある。

SMTP Server SMTP サーバーのホスト名または IP アドレスを入力する。

SMTP Port SMTP サーバーのポートを入力する。

From Address ConnectEMC サービスの通知に差出人アドレスとして表示されるメールアドレス。

Email Addresses ConnectEMC サービスの通知送信先の追加メールアドレス。


アラートを自動的に送信するには、システムのライセンスを取得し、ConnectEMC、ストレージプール、VDC、レプリケーショングループを構成している必要があります。


ConnectEMC の構成 53

第 7 章

ユーザーの追加と役割の割り当て

l 概要......................................................................................................................56l ECS のユーザーと役割について ............................................................................56l ECS ポータルでのユーザーの操作.........................................................................60l ECS ポータルでの認証プロバイダーの操作............................................................65l ネームスペースへのユーザーのマッピングの概要................................................. 71

ユーザーの追加と役割の割り当て 55

概要本稿では、ECS でサポートされるユーザーのタイプとユーザーに割り当て可能な役割について説明します。

ECS のユーザーと役割に関連した主要な概念を紹介します。

l ECS のユーザーと役割について（56 ページ）

l ECS ポータルでのユーザーの操作（60 ページ）

以降では、管理ユーザーとオブジェクトユーザーの追加方法について説明します。

l 新しいオブジェクトユーザーの追加（62 ページ）

l オブジェクトユーザーとしてのドメインユーザーの追加（63 ページ）

l ローカル管理ユーザーの作成または管理役割へのドメインユーザーの割り当て（64ページ）

l ネームスペース管理者の作成（65 ページ）

さらに、認証プロバイダーを設定して、ネームスペースへのドメインユーザーのマッピングを実行する方法を示します。

l 認証プロバイダーの追加（66 ページ）

l ネームスペースへのドメインユーザーのマップ（73 ページ）

ECS のユーザーと役割についてECS では、ユーザータイプと役割を定義して、ECS 管理機能とオブジェクトストアへのアクセス権を決定します。

ユーザーと役割に関する主な概念については、以降のトピックで説明します。

l ECS ユーザー（56 ページ）

l ユーザーの役割（58 ページ）

l ドメインユーザーとローカルユーザー（58 ページ）

l ユーザースコープ：グローバルまたはネームスペース（59 ページ）

ECS ユーザー

ECS には、2 つのタイプのユーザーが必要です。管理ユーザーは、ECS の管理を実行できます。オブジェクトユーザーは、サポートされるデータアクセスプロトコル（S3、EMCAtmos、OpenStack Swift、CAS）を使用して、オブジェクトストアにアクセスし、オブジェクトとバケットの読み取り/書き込みを実行できます。

管理ユーザーは、ECS ポータルにアクセスできます。オブジェクトユーザーは、ECS ポータルにアクセスできませんが、ECS データアクセスプロトコルをサポートするクライアントを使用してオブジェクトストアにアクセスできます。

管理ユーザーとオブジェクトユーザーは、異なるテーブルに格納されるため、認証情報が異なります。管理ユーザーには、ローカルのユーザー名とパスワード、またはドメインユーザーアカウントへのリンクが必要です。オブジェクトユーザーには、ユーザー名と秘密キーが必要です。同じ名前を持つ管理ユーザーとオブジェクトユーザーを作成できますが、これらのユーザーは認証情報が異なるため、実際には別のユーザーです。

管理ユーザーとオブジェクトユーザーの名前は、ECS システム内で一意にするか、ネームスペース内で一意にすることができます。これをユーザースコープと呼びます。ユーザースコープ：グローバルまたはネームスペース（59 ページ）を参照してください。



サポートされるユーザータイプの詳細については、以下のセクションで説明します。

l 管理ユーザー（57 ページ）

l オブジェクトユーザー（57 ページ）

l root ユーザー（57 ページ）

管理ユーザー

管理ユーザーは、ECS システムおよび ECS の構成済みテナントの構成と管理を実行できます。

管理ユーザーは、ECS に格納されている認証情報を持つローカルユーザーにすることができ、ローカルに保持された認証情報と比較して ECS によって認証されます。あるいは、AD（Active Directory）または LDAP（Lightweight Directory Access Protocol）で定義されたドメインユーザーにすることができ、それらのシステムに保持されたユーザーと比較して認証されます。ドメインユーザーとローカルユーザーの詳細については、ドメインユーザーとローカルユーザー（58 ページ）で説明します。

管理ユーザーは、地理的に分散して連携している VDC 間ではレプリケートされません。

オブジェクトユーザー

オブジェクトユーザーは、ECS オブジェクトストアのエンドユーザーであり、ECS でサポートされるオブジェクトプロトコル（S3、EMC Atmos、Openstack Swift、CAS）を使用してオブジェクトクライアントからオブジェクトストアにアクセスします。

オブジェクトユーザーは、ユーザー名と秘密キーによって定義され、これらを使用してオブジェクトストアにアクセスできます。ユーザー名はローカル名にするか、名前に「@」が含まれるドメインスタイルのユーザー名にすることができます。

管理ユーザーは、オブジェクトユーザーアカウントを作成でき、作成時に、または作成後いつでも、そのアカウントに秘密キーを割り当てることが可能です。オブジェクトユーザーの秘密キーは、管理ユーザーが作成したときにメールなどで配信されます。

ドメインユーザーであるオブジェクトユーザーは、ECS セルフサービス機能、および ECSREST API と通信するクライアントを使用して、秘密キーを取得できます（オブジェクトユーザーには ECS ポータルへのアクセス権はありません）。ドメインユーザーの詳細については、ドメインユーザーとローカルユーザー（58 ページ）を参照してください。秘密キーの作成については、オブジェクトストレージアクセス用の秘密キーの取得（152 ページ）を参照してください。

オブジェクトユーザーは、ECS で保持される認証情報を使用しますが、アカウントを格納した AD へのリンクは使用しません。したがって、名前が AD に存在するかどうかや、名前がネームスペースにマップされているかどうかは、ECS で確認されません。

オブジェクトユーザーはグローバルリソースです。このため、オブジェクトユーザーを VDCで作成すると、そのユーザーの割り当て先ネームスペース内ですべての VDC でのバケットとオブジェクトの読み取りと書き込みの権限をそのユーザーに付与できます。

root ユーザー

root ユーザーは、システムの初期化で使用でき、システム管理者の役割が事前に割り当てられています。

root ユーザーは、システムに初にアクセスする場合のみ使用します。初にアクセスしたときに、root ユーザーのパスワードを［Settings］ > ［Password］ページで変更し、新しいシステム管理者のアカウントを 1 つ以上作成する必要があります。

監査上、どのユーザーがシステムに対する変更を実行したかを知ることが重要なため、rootは使用しないでください。システム管理者ユーザーはそれぞれ自分のアカウントを持つ必要があります。


ECS ユーザー 57

ユーザーの役割

ECS では、役割を定義して、ECS ポータルで、または ECS 管理 REST API を使用して ECS にアクセスした場合に、ユーザーアカウントが実行可能な操作を決定します。管理ユーザーは、ECS の管理役割が割り当てられ、ローカルユーザーとドメインユーザーのどちらでも可能です。

管理ユーザーがドメインユーザーである場合は、ネームスペース管理者の役割が割り当てられます。このユーザーはネームスペースにマップされている必要があります。

次の管理役割が定義されています。

l システム管理者（58 ページ）

l ネームスペース管理者（58 ページ）

システム管理者

システム管理者の役割では、ECS を構成でき、オブジェクトストアに使用するストレージ、オブジェクトストアのレプリケート方法、テナントからオブジェクトストアへのアクセスの構成方法、割り当てられたネームスペースに対する権限を持つユーザーの指定が可能です。

また、システム管理者はネームスペースを構成してネームスペースを管理したり、ネームスペースに属するユーザーをネームスペース管理者に割り当てたりすることもできます。

システム管理者は ECS ポータルにアクセスできます。システム管理者の操作は、ECS 管理REST API を使用してプログラムクライアントから実行することもできます。

管理ユーザーはサイト全体でレプリケートされないため、システム管理者を必要とする VDCごとにシステム管理者を作成する必要があります。

管理ユーザーがドメインユーザーである場合は、ネームスペース管理者の役割が割り当てられます。このユーザーはネームスペースにマップされている必要があります。

ネームスペース管理者

ネームスペース管理者は管理ユーザーであり、ECS ポータルにアクセスしてクォータや保存期間などのネームスペース設定を行えます。また、ドメインユーザーをネームスペースにマップし、ローカルユーザーをネームスペースのオブジェクトユーザーとして割り当てることができます。ネームスペース管理者の操作は、ECS 管理 REST API を使用して実行することも可能です。

ネームスペース管理者は、単一のネームスペースの管理者にしかなれません。

認証プロバイダーとネームスペースはサイト間でレプリケートされるため（ECS グローバルリソース）、ドメインユーザーがネームスペース管理者である場合は、任意のサイトにログインしてそのサイトからネームスペースを管理できます。

ローカルの管理アカウントはサイト間でレプリケートされないため、ローカルユーザーがネームスペース管理者である場合は、管理ユーザーアカウントの作成元である VDC にしかログインできません。別の VDC に存在するものと同じユーザー名を使用する場合は、もう一方の VDC でもユーザーを作成する必要があります。これらは異なるアカウントであるため、一方の VDC にある同じ名前のアカウントに対する変更（パスワードの変更など）は、もう一方の VDC にある同じ名前のアカウントには伝播されません。

ドメインユーザーとローカルユーザー

ECS は、ローカルユーザーとドメインユーザーをサポートします。

ローカルユーザーは、ECS によって認証情報が格納されているユーザーアカウントです。管理ユーザーとオブジェクトユーザーはどちらもローカルで ECS に定義できます。オブジェクトユーザーの場合、認証情報はグローバルリソースになり、すべての ECS VDC で使用できます。



ローカルユーザーは、ECS の使用を簡単に開始できます。ただし、AD/LDAP を使用すると、既存のユーザーデータベースを活用でき、多数のユーザーがアカウントを作成せずにオブジェクトストアにアクセスできます。

ドメインユーザーは、AD/LDAP データベースに定義されたユーザーです。ECS は、AD/LDAPサーバーと通信して、ユーザーのログインリクエストを認証する必要があります。 ECS は、認証プロバイダーと呼ばれる構成物を使用して、AD/LDAP サーバーとの通信および ECS で使用可能なドメイン/グループの指定に必要な認証情報を提供します。

ドメインユーザーは、[email protected] の形式で定義されます。ECS は、構成されている認証プロバイダーを使用して、この形式のユーザー名の認証を試行します。 @がないユーザー名は、ローカルユーザーデータベースと照合して認証されます。

管理役割が割り当てられたドメインユーザーは、AD/LDAP 認証情報と照合して認証され、ECS にアクセスして ECS 管理操作を実行できます。管理操作は、ECS ポータルから、または ECS 管理 API を使用して実行できます。

ドメインユーザーは、オブジェクトユーザーとして割り当てることもできます。 ECS に多数のオブジェクトユーザーアカウントを手動で作成する際の管理オーバーヘッドを削減するために、セルフサービス機能が用意されています。これにより、ECS でドメインユーザーを認証して自動的にオブジェクトユーザーとして追加し、秘密キーを割り当てることが可能です。

この機能を使用するには、ドメインユーザーをネームスペースにマップする必要があります。ECS には、ドメインとグループメンバーシップ、およびアカウントに関連づけられた属性に基づいて、ドメインユーザーをネームスペースにマップするメカニズムが用意されています。

オブジェクトユーザーについては、ECS は「@」を含む名前をサポートするため、ドメイン名と同じ名前でオブジェクトユーザーを設定できます。この場合、ユーザーは使い慣れた名前で ECS オブジェクトストアにアクセスできます。ただし、認証には AD 認証情報ではなくローカルに保持された秘密キーが使用されます。

オブジェクトユーザーがドメインユーザーも兼ねていて、ネームスペースにマップされている場合は、ECS REST API を使用して新しい秘密キーを取得し、S3 API を使用して ECS オブジェクトストアにアクセスできます。これをセルフサービス機能と呼びます。

ユーザースコープ：グローバルまたはネームスペース

オブジェクトユーザーのスコープは、設定されているユーザースコープによって異なります。スコープの設定は、連携するすべての VDC にわたるすべてのネームスペース内のすべてのユーザーに影響します。

ユーザースコープとして設定可能なのは、GLOBAL または NAMESPACE です。グローバルスコープでは、オブジェクトユーザー名は ECS システム内のすべての VDC で一意です。ネームスペーススコープでは、オブジェクトユーザー名はネームスペース内で一意であるため、同じオブジェクトユーザーアカウント名が別のネームスペースに存在する可能性があります。

デフォルトの設定は GLOBAL です。 ECS をマルチテナント構成で使用する場合に、別のネームスペースで使用されている名前をテナントでも使用できるようにするには、このデフォルト設定を NAMESPACE に変更します。

初のオブジェクトユーザーを作成する前に、ユーザースコープを設定しておく必要があります。


ユーザースコープ：グローバルまたはネームスペース 59

ユーザースコープの設定

ユーザースコープを設定するには、PUT /config/object/properties API を使用して、ペイロードにユーザースコープを渡します。次の例は、user_scope を NAMESPACE に設定するペイロードを示しています。

PUT /config/object/properties/

<property_update> <properties> <properties> <entry> <key>user_scope</key> <value>NAMESPACE</value> </entry> </properties> </property_update>

ECS ポータルでのユーザーの操作ECS ポータルの［Manage］ > ［Users］ページでは、ローカルユーザーを作成してネームスペースのオブジェクトユーザーとして割り当てることができます。このページでは、システム管理者は、ローカル管理ユーザーを作成して管理役割を割り当てたり、ドメインユーザーに管理役割を割り当てたりすることもできます。

［Manage］ > ［Users］ページには、2 つのサブページがあります。

l ［Object Users］ビュー（60 ページ）

l ［Management Users］ビュー（61 ページ）

［Authentication Provider］ページには、ECS のシステム管理者（または root ユーザー）のみがアクセスできます。

［Object Users］ビュー

［Object Users］ビューには［Object Users］テーブルがあり、作成済みのローカルユーザー、ユーザーの割り当て先ネームスペース、ユーザーに対して実行可能なアクションが表示されます。

システム管理者には、すべてのネームスペースのオブジェクトユーザーが表示されます。ネームスペース管理者には、自分のネームスペースに属するユーザーのみが表示されます。

［Object Users］ビューの例を次に示します。



［Object Users］テーブルでは、次の情報と操作にアクセスできます。

属性説明

Name ユーザーの名前。

Namespace ユーザーが割り当てられているネームスペース。

Actions 使用可能なアクションの選択メニュー。使用可能なアクションは［Edit］と［Delete］。

［Object Users］ペインでは、この他にも次のコントロールにアクセスできます。

コントロール説明

New Object User ［New Object User］ボタンを使用すると、オブジェクトユーザーを追加で

きる。

［Management Users］ビュー

［Management Users］ビューには［Management Users］テーブルがあり、作成済みの管理ユーザーと、ユーザーに対して実行可能なアクションが表示されます。このページは、システム管理者の役割を持つユーザーにのみ表示されます。

［Management Users］ビューの例を次に示します。


ECS ポータルでのユーザーの操作 61

［Management Users］テーブルでは、次の情報と操作にアクセスできます。

列説明

Name ユーザーの名前。


［Management Users］ビューでは、この他にも次のコントロールにアクセスできます。


New Management User ［New Management User］ボタンを使用すると、管理ユーザーを追加し

て ECS のシステム管理者の役割を割り当てることができます。

新しいオブジェクトユーザーの追加

新しいローカルユーザーを作成して、サポートされているオブジェクトアクセスプロトコルを使用するように構成できます。作成後は、オブジェクトプロトコルへのアクセス権を追加または削除したり、ユーザーの新しい秘密キーを作成したりして、ユーザーの構成を変更できます。

はじめに

l ECS のシステム管理者は、すべてのネームスペースのユーザーを割り当てることができます。

l ネームスペース管理者は、自分が管理者であるネームスペースのユーザーを割り当てることができます。

l ドメインユーザーをオブジェクトユーザーとして有効化する場合は、オブジェクトユーザーとしてのドメインユーザーの追加（63 ページ）を参照してください。

l Swift ユーザーにパスワードを割り当てると、ユーザーが Swift Admin グループに追加されます。

ユーザーを異なる Swift グループに割り当てる場合は、ECS ポータルでこの操作を実行しないでください。



［Manage］ > ［Users］ページについては、ECS ポータルでのユーザーの操作（60 ページ）を参照してください。

手順

1. ECS ポータルで、［Manage］ > ［Users］を選択します。

デフォルトでは［Object Users］ページが開きます。［Object Users］テーブルに、作成済みローカルユーザーおよびそのユーザーの割り当て先ネームスペースが表示されます。

2. ［New Object User］を選択します。

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

3. ユーザーの名前を入力します。

これは、作成するローカルユーザーの名前です。

「@」が含まれるドメインスタイルの名前を使用できます。たとえば、「[email protected]」です。ただし、これは名前を一意に保って AD の名前との整合性を確保するには便利ですが、認証は、AD または LDAP ではなく、ユーザー名に割り当てられた秘密キーを使用して実行されます。

4. ローカルユーザーの割り当て先のネームスペースを選択します。

ネームスペースを選択したら、ユーザーの［Save］を選択できます。後でユーザーの編集に戻り、オブジェクトプロトコルにアクセスするための秘密キーを割り当てることができます。別の方法として、［Add Passwords］を選択し、ECS オブジェクトプロトコルにアクセスするためのパスワードまたは秘密キーを指定することもできます。

5. ユーザーの秘密キーを設定するには、［Add Passwords］を選択します。

6. ECS オブジェクトストアへのアクセスで使用するオブジェクトプロトコルごとに、S3、Swift、CAS のいずれかへのアクセスで使用するキーを入力するか生成し、キーを保存します。

［Add Password］を選択してキーを保存します。

7. ユーザーのアクセスを可能にするオブジェクトインターフェイスごとにパスワードを指定します。

S3 と CAS の場合は、パスワードを生成できます。

8. 秘密キーとパスワードは自動的に保存されます。［Close］ボタンをクリックすると、［Users］ページに戻ります。

オブジェクトユーザーとしてのドメインユーザーの追加

ドメインユーザーが ECS にアクセスしてユーザー自身の秘密キーを生成するように、ドメインユーザーを構成できます。そのためには、ドメインユーザーをオブジェクトユーザーとして追加します。

はじめに

手順

1. 適切な AD/LDAP システムに接続する認証プロバイダーが構成されていることを確認します。

認証プロバイダーの追加は、システム管理者が実行します。認証プロバイダーの追加（66 ページ）を参照してください。

2. ネームスペースへのドメインユーザーのマップ（73 ページ）の説明に従って、ドメインユーザーをネームスペースにマップします。

この操作はネームスペース管理者が実行できます。


オブジェクトユーザーとしてのドメインユーザーの追加 63

3. オブジェクトストレージアクセス用の秘密キーの取得（152 ページ）の手順に従って、ユーザーに秘密キーの作成を許可します。

ローカル管理ユーザーの作成または管理役割へのドメインユーザーの割り当て

ECS ポータルでは、ローカル管理ユーザーを追加し、ローカル管理ユーザーまたはドメインユーザーに管理役割を割り当てることができます。システムレベルの管理（VDC の管理）とネームスペースの管理を実行するには、管理ユーザーである必要があります。ユーザーが管理操作を実行する必要がなくなった場合は、役割の割り当てを解除できます。

はじめに

l ローカル管理ユーザーの作成や管理役割の割り当てを実行するには、システム管理者である必要があります。

l ECS の root ユーザーは、デフォルトでシステム管理者の役割を持ち、ユーザーにシステム管理者の役割を初に割り当てることができます。

l ドメインユーザーに管理役割を割り当てる場合は、まず認証プロバイダーが追加されていることを確認する必要があります。認証プロバイダーの追加（66 ページ）を参照してください。

l ネームスペース管理者を割り当てる場合は、ここに記載されている操作を使用して管理ユーザーを作成し、ポータルの［Namespace］ページで役割を割り当てます（テナントのネームスペースの構成（76 ページ）を参照）。このユーザーは、ネームスペース管理者の役割（またはシステム管理者の役割）が割り当てられるまでログインできません。


手順


デフォルトでは［Object Users］ページが表示されます。［Management Users］ページに変更する必要があります。

2. ［Management Users］を選択します。

［Management Users］ページに、現在割り当てられているすべてのユーザーが表示され、［New Management User］ボタンが使用可能になります。

3. ［New Management User］を選択します。

［New Management User］ページが表示され、新しいローカルユーザーを作成して管理役割を割り当てるか、ドメインユーザーに管理役割を割り当てることができます。

4. ［Local User］または［AD/LDAP User］を選択します。

ローカルユーザーの場合は、パスワードを定義する必要があります。ドメインユーザーの場合は、ECS でユーザーの認証に使用されるユーザーとパスワードの認証情報がAD/LDAP に保持されるため、パスワードを定義する必要はありません。

5. ユーザーの名前を入力します。

AD/LDAP を選択した場合は、ユーザーが存在し、認証プロバイダーを ECS に追加して使用可能になっている必要があります。

ローカルユーザーを選択した場合は、新しいローカル管理ユーザーが作成されます。

6. ユーザーにシステム管理者の役割を割り当てる場合は、［System Administrator］セレクターで［Yes］を選択します。

作成する管理ユーザーにネームスペースのネームスペース管理者の役割を割り当てる場合は、これを［No］にしておきます。



［Yes］を選択した場合でも、後でユーザーからシステム管理者権限を削除することが必要になったときは、ユーザー設定を編集してこれを［No］に変更できます。

7. ユーザーにネームスペース管理者の役割を割り当てるために、システム管理者を選択しなかった場合は、［In order to log in, non-System Admin users...］ボックスをオンにする必要があります。

［In order to log in, non-System Admin users...］ボックスは、ユーザーがネームスペース管理者の役割を割り当てられるまでログインできないことを確認するものです。

8. ［Save］を選択します。

ネームスペース管理者の作成

ローカルユーザーまたはドメインユーザーをネームスペース管理者として割り当てることができます。

はじめに

l 管理ユーザーを作成してネームスペース管理者の役割を割り当てるには、システム管理者である必要があります。


手順

1. ローカル管理ユーザーにネームスペース管理者の役割を割り当てる場合は、ローカル管理ユーザーの作成または管理役割へのドメインユーザーの割り当て（64 ページ）の説明に従って管理ユーザーを作成する必要があります。

ドメインユーザーにネームスペース管理者の役割を割り当てる場合は、ユーザーに管理役割を明示的に割り当てる必要はありません。

2. ［Manage］ > ［Namespace］ページで、次の手順を実行します。

a. ネームスペースの［Edit］アクションを選択します。

b. ［Namespace Admin］フィールドにユーザーを追加します。ネームスペース管理者が複数いる場合は、ユーザー名をコンマ区切りリストで入力してください。

1 人のユーザーは 1 つのネームスペースに対してのみネームスペース管理者として割り当てることができます。

c. ネームスペースの［Save］を選択します。

ネームスペースの構成の詳細：テナントのネームスペースの構成（76 ページ）

ECS ポータルでの認証プロバイダーの操作ECS ポータルの［Manage］ > ［Authentication］ページでは、認証プロバイダーを追加できます。

［Authentication Provider］ページにアクセスできるのは、ECS のシステム管理者（またはroot ユーザー）のみです。

［Authentication Provider］ページの［Authentication Provider］テーブルには、作成済みの認証プロバイダーが表示されます。例を次に示します。


ネームスペース管理者の作成 65

このテーブルでは、次の情報と操作にアクセスできます。

属性説明

Name 認証プロバイダーの名前。

Type 認証プロバイダーが AD（Active Directory）または LDAP（LightweightDirectory Access Protocol）サーバーのどちらであるかを示す。

Domains 認証プロバイダーのアクセス先であるドメイン。

Enabled 認証プロバイダーが現在有効または無効のどちらであるかを示す。


［Authentication Provider］ページでは、この他にも次のコントロールにアクセスできます。


New AuthenticationProvider

［New Authentication Provider］ボタンを使用すると、認証プロバイダー

を追加できる。

認証プロバイダーの追加

ドメインユーザーのユーザー認証は、ECS に追加されている 1 つ以上の認証プロバイダーを使用して実行されます。認証プロバイダーとは、ECS と AD/LDAP サーバーの接続を可能にし、AD/LDAP を ECS で使用可能にする必要があるドメインとグループを識別する構成物のことです。

はじめに

l 認証プロバイダーを追加するには、ECS でシステム管理者の役割が割り当てられている必要があります。root ユーザーはシステム管理者の役割を持っています。

l 認証プロバイダーの設定（67 ページ）に記載されている認証プロバイダー情報にアクセスする必要があります。マネージャー DN ユーザーに対する要件に特に注意します。

手順

1. ECS ポータルで、［Manage］ > ［Authentication］ > ［New Authentication Providers］を選択します。

2. 属性の値を入力します。認証プロバイダーの設定（67 ページ）を参照してください。




4. 設定を確認するには、［Manage］ > ［Users］ > ［Management Users］を選択して認証プロバイダーからユーザーを追加し、新しいユーザーとしてログインを試みます。

認証プロバイダーの設定

認証プロバイダーを追加または編集する場合は、特定の情報を提供する必要があります。

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

フィールド名説明および要件

Name 認証プロバイダーの名前。異なるドメインで複数のプロバイダー

を持つことができます。

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

Type Active Directory または LDAP。

Domains Active Directory および LDAP は、コンテナーの階層的コレクション

内にネットワークのオブジェクト（ユーザー、コンピューター、デバ

イス）を組織することを管理者に許可します。

ドメインは、共通ディレクトリデータベース、セキュリティポリシー

を共有する、管理上定義されたオブジェクトのコレクションであり、

その他のドメインとの関係を信頼します。このように、各ドメインは

オブジェクトに対する管理上の境界となります。シングルドメイン

は複数の物理的な場所またはサイトに展開することができ、何百

万ものオブジェクトを含むことができます。

認証プロバイダーのフィールドにおける代表的なエントリーには次

のようなものが見られます。

mycompany.com

代替 UPN サフィックスが Active Directory で構成されている場合

は、ドメインリストにはそのドメイン用に構成された代替 UPN も含

まれている必要があります。たとえば、mycoが

mycompany.comの代替 UPN サフィックスとして追加された場

合、ドメインリストには myco と mycompany.comが両方含まれ

ている必要があります。

Server URLs ドメインコンロトーラーの IP アドレスを持つ ldap または ldaps（セキュア LDAP）。デフォルトポートは、ldap は 389、ldaps は 636です。

Usage: 1 つまたはそれ以上の

ldap://<Domain controller IP >:<port>（デフォルトポートではない

場合）

または

ldaps://<Domain controller IP >:<port>（デフォルトポートではない

場合）

認証プロバイダーがマルチドメインフォレストをサポートしている

場合は、グローバルカタログサーバー IP を使用し、常にポート番

号を指定します。 ldap のデフォルトは 3268、ldaps のデフォルト

は 3269 です。

Usage: ldap(s)://<Global catalog server IP>:<port>


認証プロバイダーの設定 67

表 6 認証プロバイダーの設定（続き）


Manager DN ECS が Active Directory または LDAP サーバーへの接続に使用す

る Active Directory バインドユーザーアカウントを示します。この

アカウントは、ECS 管理者が役割の割り当てのためにユーザーを

特定するときの Active Directory の検索などに使用されます。

要件：

このユーザーは、Active Directory 内で［Read allinetOrgPerson information］を持っている必要があります。

InetOrgPerson オブジェクトクラスは、いくつかの Microsoft 以外

の LDAP（Lightweight Directory Access Protocol）および X.500 デ

ィレクトリサービスで使用され、組織内のユーザーを表現します。

この権限を Active Directory で設定するには、［Active DirectoryUsers and Computers］を開き、ドメインの上で右クリックし、

［Delegate Control...］を選択します。［Next］をクリックし、

managerdn を使用しているユーザーを選択して［Next］をクリック

します。必要な権限が次画面の「Read all inetOrgPersoninformation」に表示されます。

例：

CN=Manager,CN=Users,DC=mydomaincontroller,DC=com

この例では、Active Directory のバインドユーザーは、

mydomaincontroller.com のユーザーツリーのマネージャーで

す。通常、managerdn は管理者より少ない権限を持つユーザー

ですが、ユーザー属性やグループ情報を Active Directory に照会

するための十分な権限があります。

managerdn の認証情報が Active Directory で変更された場合は、

ECS でこの値を更新する必要があります。

Manager Password managerdn ユーザーのパスワードです。

managerdn の認証情報が Active Directory で変更された場合は、

ECS でこの値を更新する必要があります。

Providers ECS にサーバーを追加したい場合は［Disabled］を選択しますが、

すぐには認証に使用されません（このプロパティが true であるか

どうかにかかわらず、ECS はプロバイダーの名前およびドメインが

一意であることを検証します）。

Group Attribute グループを指定するために使用される Active Directory の属性を

示します。グループによるディレクトリの検索に使用されます。

例： CN

Active Directory のみ。認証プロバイダーには適用されません。





いったんこの値がプロバイダーに設定されると変更できなくなりま

す。このプロバイダーを使用しているテナントは、現在の属性を使

用しているフォーマットでグループ名を使用して構成された役割の

割り当てと権限をすでに持っていることがあるからです。

Group Whitelist オプションです。認証プロバイダーによって定義された 1 つ以上

のグループ名です。この設定は、ECS がユーザーについて取得し

たグループメンバーシップ情報をフィルターします。

l 1 つまたは複数のグループがホワイトリストに含まれる場合

は、ECS が特定のグループ内のユーザーメンバーシップを認

識することを意味します。複数の値（ECS ポータルでは行ごと

に 1 つ、CLI と API ではコンマ区切り形式）とワイルドカード

（MyGroup*や TopAdminUsers*など）が使用できます。

l 空白の値（デフォルト）は、ECS がユーザーの属する任意およ

びすべてのグループを認識することを意味します。アスタリス

ク（*）は空白と同じです。

例：

UserA が Group1 と Group2 に属しています。

ホワイトリストが空白の場合、ECS は UserA が Group1 と Group2のメンバーであることを認識しています。

ホワイトリストが「Group1」の場合、ECS は UserA が Group1 のメ

ンバーであることは認識していますが、UserA が Group2（または

その他のグループ）のメンバーであることは認識していません。

ホワイトリストの値を追加するときは注意してください。たとえば、

グループメンバーシップに基づいてユーザーをテナントにマッピン

グする場合、ECS はグループにおけるユーザーのメンバーシップ

を認識している必要があります。

ネームスペースへのアクセスを特定のグループのユーザーのみ

に制限するには、次のように操作する必要があります。

l （CLI コマンド viprcli tenant add-groupを使用して）

ネームスペースユーザーマッピングにそれらのグループを

追加します。これにより、テナントはそれらのグループのユー

ザーのみを受け入れるように構成されます。

l それらのグループをホワイトリストに追加します。これにより、

ECS はそれらの情報を受け取ることが許可されます。

デフォルトでは、テナントユーザーマッピングにグループが追加さ

れなかった場合は、ホワイトリストの設定にかかわらず、どのグル

ープのユーザーでも受け入れられることに注意してください。

Active Directory のみ。認証プロバイダーには適用されません。

Search Scope 1 つのレベル（検索ベースの 1 つ下のレベルでユーザーを検索）

またはサブツリー（検索ベースの下でサブツリー全体を検索）。


認証プロバイダーの設定 69



Search Base ログイン時と役割の割り当て時や ACL 設定時に ECS によってユ

ーザーの検索に使用される基本識別名を示します。

例： CN=Users、DC=mydomaincontroller、DC=com

この例は、ユーザーコンテナー内ですべてのユーザーを検索しま

す。

例： CN=Users、OU=myGroup、DC=mydomaincontroller、DC=com

この例は、myGroup の組織単位におけるユーザーコンテナー内

ですべてのユーザーを検索します。

searchbase の値の構造は、「leaf」レベルで始まり、ドメインコント

ローラーレベルに上がることに注意してください。逆の構造は

Active Directory のユーザーおよびコンピューター UI で見られま

す。

Search Filter ユーザーのサブセットを選択するために使用される文字列を示し

ます。例： userPrincipalName=%u

ECS は、認証プロバイダーの追加時にはこの値を検証しません。

Active Directory で代替 UPN サフィックスが構成されている場合、

［Search Filter］値は sAMAccountName=%U 形式である必要があ

ります。%U はユーザー名で、ドメイン名は含まれません。

（この設定は UI では使用できま

せん）。

単一の検索結果で返されるオブジェクトの大数を管理する値で

す。これは返された各オブジェクトのサイズからは独立していま

す。これを指定する場合、0 より大きくなければなりません。認証

プロバイダーで設定された大ページサイズを超えることはでき

ません。

（該当なし） ldaps プロトコルが使用される場合、SSL は認証プロバイダーから

の証明書を検証します。デフォルトは false です。 true に設定さ

れている場合、LDAP は有効な CA 証明書を持っている必要があ

ります。

認証プロバイダーを追加する際の考慮事項

Active Directory と動作するように ECS を設定する場合は、単一の認証プロバイダーで複数のドメインを管理するか、または各ドメインに個別の認証プロバイダーを追加するかを決定する必要があります。

単一の認証プロバイダーを追加するか複数の認証プロバイダーを追加するかについての決定は、環境内のドメイン数およびマネージャーユーザーが検索可能なツリーでの場所によります。認証プロバイダーは、検索が実行される単一の search_base を持ちます。それらは search_base レベルおよびその下で読み取り専用アクセスが必ずある単一のマネージャーアカウントを持ちます。

Active Directory フォレストを管理している場合は、次のように複数のドメインに単一の認証プロバイダーを使用します。



l マネージャーアカウントには、すべてのユーザーエントリーにアクセスできるようにツリー内で上位の検索権限を持たせる

l 検索は、単一の検索ベースから、プロバイダーにリストされているドメインだけではなく、フォレスト全体に実行する

それ以外の場合は、各ドメインで認証プロバイダーを設定します。

たとえフォレストを扱っており正しい権限を持っていたとしても、単一の認証プロバイダーですべてのドメインの管理を望まない場合があり得ることに注意してください。各ドメインで精度と厳格な管理が必要な場合（特に、検索のために検索ベースの起点を設定するなど）であっても、ドメインごとに 1 つの認証プロバイダーを引き続き使用しているかもしれません。構成ごとに 1 つの検索ベースしかないため、検索が機能するように構成内で指定された範囲のすべてを含める必要があります。

検索ベースは、目的のドメイン内のすべてのユーザーを正しく見つけられるよう、フォレストのディレクトリ構造において十分に高度である必要があります。

l 構成内のフォレストに 10 個のドメインが含まれているがターゲットは 3 個である場合、単一のプロバイダー構成は使用しないでください。フォレスト全体に不必要に検索が展開することでパフォーマンスに悪影響を与える可能性があるからです。このような場合は、3 つの個別構成を使用してください。

l 構成内のフォレストに 10 個のドメインが含まれていてターゲットも 10 個にしたい場合、グローバル構成が適です。設定のためのオーバーヘッドがより少ないからです。

ネームスペースへのユーザーのマッピングの概要認証プロバイダーを使用してドメインユーザーを ECS に追加できます。ユーザーをネームスペースユーザーとして使用可能にするには、ユーザーをネームスペースにマップする必要があります。

認証プロバイダーを使用して、ECS で使用可能な指定のドメインとホワイトリストグループにユーザーを所属させます。これらのユーザーにはシステムの役割を割り当てることができます。

ユーザーをネームスペースに関連づけてネームスペースのオブジェクトユーザーの資格を持たせるには、ユーザーが属するドメインをネームスペースと関連づける必要があります。必要に応じて、そのドメインに属するグループおよびドメインユーザーに割り当てられている属性に基づき、詳細なフィルターを適用します。ドメインは、単一のネームスペースにマップすることも、複数のネームスペースにユーザーを提供することもできます。

ECS ポータルと ECS 管理 REST API は、新しいネームスペースの登録時にマッピングを指定する機能を提供し、すべてのネームスペースのマッピングの更新をサポートします。ネームスペースの作成は、システム管理者権限を必要とする操作です。一方、テナントの変更とユーザーマッピングの実行の操作は、ネームスペース管理者が実行できます。

異なるネームスペースへのユーザーマッピングの割り当ては重複させることができないため、Accounts ネームスペースで HR ネームスペースと同じドメインからユーザーをマップする場合は、追加のマッピングを作成してユーザーを区別する必要があります。次の例では、Accounts ネームスペースは corp.sean.com ドメインを使用していますが、特定の属性を持つユーザー（この場合、Active Directory で Department 属性が Accounts に設定されているユーザー）をマップしています。


ネームスペースへのユーザーのマッピングの概要 71

図 12 AD 属性を使ったテナントのユーザーマッピング

次の例では、複数のマッピング基準を使用した場合を示しています。 corp.sean.com ドメインの中で、Storage Admins グループに属し、Department 属性が Accounts、かつ Company属性が Acme に設定されているか、あるいは Storage Admins グループに属し、Department 属性が Finance に設定されているすべてのメンバーが、ネームスペースにマップされます。



図 13 複数のマッピング基準の使用

ネームスペースへのドメインユーザーのマップ

ECS ポータルでは、ユーザーに関連づけられた AD/LDAP ドメイン、グループ、属性に基づき、ユーザーをネームスペースにマップできます。

はじめに

l 認証プロバイダーが ECS で登録されており、ユーザーをマップする元のドメインにアクセスできる必要があります。

l AD の管理者は、AD のグループまたはユーザーを構成した後で、ECS ポータルからユーザーをマップする必要があります。

l 属性マッピングを使う場合、各ユーザーの適切な属性値が AD に設定されている必要があります。ネームスペースへのユーザーのマッピングの概要（71 ページ）を参照して、ユーザーマッピングに関連する概念を理解しておいてください。


ネームスペースへのドメインユーザーのマップ 73

手順

1. ECS ポータルで、［Manage］ > ［Namespace］を選択します。

2. ［Namespaces］テーブルで、編集のために開くネームスペースの［Edit］アクションをクリックします。

3. まだドメインを指定していない場合は、［Add］をクリックしてマッピングを追加し、［Domain］フィールドにドメイン名を入力します。

4. ネームスペースへのユーザーのマップに使用するグループを指定します。

指定したグループは AD に存在している必要があります。

5. ネームスペースへのユーザーのマップに属性を使用する場合は、属性名と属性値を入力します。ネームスペースへのユーザーのマップに属性を使用しない場合は、削除のボタンをクリックして現在のマッピングから属性フィールドを削除します。

ユーザーをドメインにマップするには、ユーザーに設定された属性値が、ECS に指定された属性値と一致する必要があります。

6. ネームスペース設定の［Save］をクリックします。



第 8 章

テナントのネームスペースの構成

l 概要......................................................................................................................76l テナントの概要...................................................................................................... 76l ネームスペースの設定について.............................................................................77l ECS ポータルでのネームスペースの操作............................................................... 78l ネームスペースの作成と構成................................................................................ 78

テナントのネームスペースの構成 75

概要ネームスペースは、複数のテナントが ECS オブジェクトストアにアクセスできるメカニズムを提供し、テナントのユーザーによって書き込まれたオブジェクトとバケットを他のテナントのユーザーから確実に分離します。

本稿では、テナントとネームスペース設定に関するいくつかの概念について説明します。

l テナントの概要（76 ページ）

l ネームスペースの設定について（77 ページ）

l ECS ポータルでのネームスペースの操作（78 ページ）

また、ECS ポータルを使用してネームスペースを構成する際に必要な操作についても説明します。

l ネームスペースの作成と構成（78 ページ）

本稿に記載された構成操作では ECS ポータルを使用しますが、テナントの概要（76 ページ）とネームスペースの設定について（77 ページ）で説明している概念はポータルを使用する場合でも REST API を使用する場合でも当てはまります。

テナントの概要ECS は、複数のテナントによるアクセスをサポートします。各テナントはネームスペースで定義され、ネームスペースに構成されたユーザーはネームスペース内のオブジェクトの保存やアクセスが可能です。

ネームスペースは ECS のグローバルリソースであり、システム管理者/ネームスペース管理者は任意の連携 VDC で ECS にアクセスしてネームスペースの設定を構成することができます。また、ネームスペースに割り当てられたオブジェクトユーザーはグローバルになり、任意の連携 VDC からオブジェクトストアにアクセスできます。

ネームスペースの主な特性として、あるネームスペースのユーザーは、別のネームスペースに属しているオブジェクトにアクセスすることはできません。また、ECS により、エンタープライズ環境でネームスペースを構成してその使用状況を監視および測定したり、構成や監視/測定の操作を実行するための管理権限をテナントに付与したりすることができます。

サブテナントを作成する手段として、バケットを使用することも可能です。バケットの所有者がサブテナントの管理者となり、アクセス制御リストを使用してサブテナントにユーザーを割り当てることができます。ただし、サブテナントはテナントと同レベルの分離はできず、テナントに属するいずれのユーザーにもサブテナントに対する特権を割り当てることができるため、ユーザーの割り当ては注意が必要です。

次のシナリオに対応しています。

エンタープライズシングルテナントすべてのユーザーが、同じネームスペースのバケットとオブジェクトにアクセスします。サブテナント（バケット）を作成することで、ネームスペースユーザーのサブセットに同じオブジェクトセットへのアクセスを許可できます。サブテナントはエンタープライズ内の部門とすることができます。

エンタープライズマルチテナント組織内の異なる部門を異なるネームスペースに割り当て、それぞれのネームスペースに部門ユーザーを割り当てます。

クラウドサービスプロバイダーのシングルテナント単一のネームスペースを構成し、サービスプロバイダーはエンタープライズ内外のユーザーにオブジェクトストアへのアクセス権を付与します。



クラウドサービスプロバイダーのマルチテナントサービスプロバイダーは企業別にネームスペースを割り当て、ネームスペースに管理者を割り当てます。テナントのネームスペース管理者は、ユーザーを割り当てて、バケットとオブジェクトの使用状況を監視および測定できます。

テナントを管理するための機能については、テナントの管理（84 ページ）を参照してください。

各テナントは、システム管理者が準備したレプリケーショングループへのアクセス権を持ちます。テナントのアクセスパターンに応じて、特定の地域のサイトを含むレプリケーショングループが必要になることがあります。たとえば、クライアントテナントが中国にある場合に、中国国内にある VDC を含むレプリケーショングループへのアクセスが望まれることがあります。

ネームスペースの設定についてネームスペースには、オブジェクトとバケットを分離するメカニズムがあります。このため、あるネームスペースのオブジェクトが、別のネームスペースのオブジェクトと同じ名前を持つことができます。 ECS は常に、必要なオブジェクトをネームスペース修飾子によって認識します。ネームスペースの構成には、ネームスペースにアクセスできるユーザーを定義する属性や、ネームスペースの特性を定義する属性も使用されます。 ECS ネームスペースはテナントとみなすことができます。

適切な権限を持つユーザーは、ネームスペースでバケットを作成し、バケット内にオブジェクトを作成できます。

ECS のオブジェクトのアドレス指定におけるネームスペース名とバケット名の使用方法については、ECS オブジェクトストレージのアドレス指定とベース URL の使用（132 ページ）を参照してください。

ECS のネームスペースには、次の属性があります。

デフォルトのレプリケーショングループリクエストでレプリケーショングループが指定されない場合に、バケットが作成されるレプリケーショングループです。レプリケーショングループの構成の詳細については、次を参照してください。ストレージプール、VDC、レプリケーショングループの構成（48 ページ）

ネームスペース管理者ネームスペースでネームスペース管理者の役割に割り当てられたユーザーです。ネームスペース管理者は ECS 管理ユーザーであり、ローカルユーザーでもドメインユーザーでも構いません。

ユーザー・マッピングネームスペースのオブジェクトユーザーとして割り当て可能なユーザーを識別するドメイン、グループ、属性です。ユーザーを ECS に追加して特定のネームスペースにマップする方法については、ユーザーの追加と役割の割り当て（56 ページ）を参照してください。

許可する（許可しない）レプリケーショングループECS 管理 REST API により、クライアントはネームスペースで使用できるレプリケーショングループを指定できます。これは ECS ポータルからは使用できません。

ネームスペースの保存ポリシーとクォータを指定することも可能です。これらの機能の使用方法については、テナントの管理（84 ページ）を参照してください。

クォータ有効にすると、ネームスペースに設定されたクォータサイズに従ってイベントがログに記録される（ソフトクォータ）か、指定のストレージ制限に達したときにアクセスがブロックされます（ハードクォータ）。


ネームスペースの設定について 77

保存ポリシーネームスペースにはいくつかの保存ポリシーを関連づけることができ、それぞれのポリシーで保存期間を定義できます。保存期間を直接適用するのではなく、保存ポリシーをオブジェクトに適用するため、保存ポリシーを変更することで、ポリシーが適用されているすべてのオブジェクトの保存期間を変更できます。保存期間の有効期限が切れる前にリクエストされたオブジェクトの変更は許可されません。

ECS ポータルでのネームスペースの操作ネームスペースポータルページ（［Manage］ > ［Namespace］）でネームスペースを作成できます。既存のネームスペースはネームスペーステーブルにリストされ、そこで編集できます。

図 14 ネームスペース管理ページ

ネームスペーステーブルは次のフィールドで構成されます。


Name ネームスペースの名前

Quota ネームスペースに割り当てられたクォータ（存在する場合）

Replication Group ネームスペースのデフォルトのレプリケーショングループ

Notification Quota これに達すると通知が生成されるクォータ制限

Max Quota これに達するとネームスペースへの書き込みをブロックするクォータ制限

Actions ネームスペースに実行可能なアクション。［Edit］と［Delete］のアクションを実

行可能

ネームスペースの作成と構成［Manage］ > ［Namespace］ページでは、新しいネームスペースを作成したり、既存のネームスペースの構成を変更したりできます。

はじめに

l この操作を行うには、ECS でシステム管理者の役割が割り当てられている必要があります。

l レプリケーショングループが存在する必要があります。レプリケーショングループにより、オブジェクトデータを保存するストレージプールへのアクセスが可能になります。



l ドメインユーザーにネームスペースへのアクセスを許可する場合は、認証プロバイダーが ECS に追加されている必要があります。また、ドメインオブジェクトユーザーを構成する場合は、ネームスペースにユーザーをマップする方法を計画する必要があります。ユーザーのマッピングについては、ユーザーの追加と役割の割り当て（56 ページ）を参照してください。

ネームスペースの設定について（77 ページ）を参照して、ネームスペースの概要をよく理解しておいてください。

手順


2. 新しいネームスペースを作成するには、［New Namespace］を選択します。既存のネームスペースの構成を編集するには、そのネームスペースに関連づけられた［Edit］アクションを選択します。

3. 各フィールドに適切な値を指定します。

各フィールドの設定について、次の表に示します。


Name ネームスペースの名前。この名前はすべて小文字にする必要があります。作成後

はこの名前を変更することはできません。

admin ネームスペース管理者の役割に割り当てる 1 人または複数のユーザーのユーザ

ー ID。ユーザーが複数の場合は、コンマで区切ってリストします。

ネームスペース管理者は、ローカルユーザーでもドメインユーザーでも構いませ

ん。ネームスペース管理者をドメインユーザーにする場合は、認証プロバイダーが

ECS に追加されていることを確認してください。詳細については、「ユーザーの追加

と役割の割り当て（56 ページ）」を参考にしてください。

ReplicationGroup

ネームスペースのデフォルトのレプリケーショングループ。

Quota クォータを有効化するコントロール。クォータに達したときの動作を指定できます。

参照：手順 4（79 ページ）

RetentionPolicies

1 つ以上の保存ポリシーの追加と構成が可能。

既存の保存ポリシーを編集、無効化、削除できます。


Domain AD/LDAP ドメインの指定が可能。ドメインのユーザーを含めるときのルールを構成

できます。

これにより、ドメインに属するユーザーが ECS のセルフサービス機能を使用してオ

ブジェクトユーザーとして登録できます。


4. クォータを有効化して構成します。

a. ネームスペースのクォータを設定する場合は、［Quota］を［Enabled］に設定します。

b. ［Notification Only］または［Block Access］を選択します。

指定のストレージ制限に達したときにアクセスをブロックする場合は、通知を送信するときの制限のパーセンテージも指定できます。

5. 保存ポリシーを追加して構成します。

a. ［Retention Policies］エリアで、［Add］を選択して新しいポリシーを追加します。


ネームスペースの作成と構成 79

b. ポリシーの名前を入力します。

c. 保存ポリシーの期間を指定します。

分単位の値を使用できます。また、［Infinite］チェックボックスをオンにすると、この保存ポリシーを割り当てたバケットを削除しないように指定できます。

6. ECS へのログインとネームスペースの管理タスクの実行が可能なユーザーの AD/LDAPドメインを指定します。

ドメインの名前を入力し、グループと属性を指定することで、現在のネームスペースでECS へのアクセスを許可するドメインユーザーを詳細に制御できます。

グループと属性を使用した複雑なマッピングについては、次を参照してください。ユーザーの追加と役割の割り当て（56 ページ）




第 9 章

ライセンスファイルの取得と ECS ポータルへのアップロード

l ライセンス............................................................................................................. 82l EMC ECS ライセンスファイルの取得.......................................................................82

ライセンスファイルの取得と ECS ポータルへのアップロード 81

ライセンスEMC ECS のライセンスは容量に基づいています。

低限、1 つの ECS ライセンスを取得してアプライアンスにアップロードする必要があります。

詳細については、［Settings］ > ［License］ページを参照してください。

EMC ECS ライセンスファイルの取得EMC ライセンス管理 Web サイトからライセンスファイル（.lic）を取得して ECS にアップロードする必要があります。

はじめに

ライセンスファイルを取得するには、EMC からメールで送信された LAC（ライセンス認証コード）が必要です。

手順

1. support.EMC.com にアクセスします。

2. ［サポート］ > ［サービスセンター］を選択します。

3. ［ライセンスの取得と管理］を選択します。

4. 製品のリストから［ECS］を選択します。

5. LAC リクエストページで、LAC コードを入力し、［Activate］を選択します。

6. アクティブ化する利用資格を選択し、［Start Activation Process］を選択します。

7. ［Add a Machine］を選択して、ライセンスのグループ化のために意味のある文字列を指定します。

「マシン名」はマシンの名前でなくてもかまいません。ライセンスを把握できるような任意の文字列を入力してください。

8. アクティブ化される利用資格ごとに数量を入力するか、または［Activate All］を選択します。［Next］をクリックします。

複数サイト（ジオ）構成用のライセンスを取得する場合は、各仮想データセンターのライセンスファイルを個別に取得するために、必要に応じてコントローラーを分散させる必要があります。

9. オプションとして、アクティブ化トランザクションのサマリーをメールで受信するための宛先を指定します。

10.［Finish］をクリックします。

11.［Save to File］をクリックして、コンピューター上のフォルダーにライセンスファイル（.lic）を保存します。

このライセンスファイルは、ECS の初期セットアップ中に、または ECS ポータル（［Settings］ > ［Licensing］）で新しいライセンスを後から追加するときに必要です。

12.ECS ポータルから、［Settings］ > ［Licensing］を選択します。

13.［Choose File］を選択し、ライセンスファイルを選び、［Upload］を選択します。

ライセンス表示が更新されます。

ライセンスファイルの取得と ECS ポータルへのアップロード


第 10 章

テナントの管理

l 概要......................................................................................................................84l クォータ................................................................................................................. 84l 保存期間と保存ポリシー........................................................................................85l バケットとユーザーのロック....................................................................................86l 測定......................................................................................................................87l バケットの監査...................................................................................................... 88

テナントの管理 83

概要ECS には、テナントの管理をサポートする多くの機能が用意されています。

次の機能がサポートされます。

ユーザーネームスペースのネームスペース管理者の割り当てとネームスペースのオブジェクトユーザーの作成を行う機能です。ユーザーの追加と役割の割り当て（56 ページ）を参照してください。

クォータネームスペースとバケットにクォータを設定する機能です。クォータ（84 ページ）を参照してください。

保存期間保存ポリシーを作成する機能です。保存期間と保存ポリシー（85 ページ）を参照してください。

バケットとユーザーのロックバケットとユーザーをロックする機能です。バケットとユーザーのロック（86 ページ）を参照してください。

測定バケットとネームスペースへのデータの書き込みを測定する機能です。測定（87 ページ）を参照してください。

バケットの監査バケットに関連した操作を監査する機能です。バケットの監査（88 ページ）を参照してください。

クォータネームスペースおよびネームスペース内に作成したバケットに、ソフトクォータとハードクォータを設定できます。

ソフトクォータは、イベントをログに記録して、クォータ制限に達したことを示します。ハードクォータは、バケットまたはネームスペースで使用できるオブジェクトストレージ容量のハード制限を設定します。制限に達すると、バケットまたはネームスペースへのアクセスがブロックされます。

クォータの設定は、ECS ポータルから行うか、API と CLI を使用して行います。

ポータルからのクォータの設定

ネームスペースのクォータは、［Manage］ > ［Namespace］ページで設定します（テナントのネームスペースの構成（76 ページ）を参照）。

バケットのクォータは、［Manage］ > ［Bucket］ページで設定します（バケットの作成と構成（138 ページ）を参照）。

API を使用したクォータの設定

次の API パスを使用して、クォータを設定できます。



方法説明

PUT/GET/DELETE /object/namespaces/namespace/{namespace}/quota

ネームスペースのクォータを設定。ペイロードに

よってハードクォータとソフトクォータを指定しま

す。

PUT/GET/DELETE /object/bucket/{bucketName}/quota

バケットのクォータを設定。ペイロードによってハ

ードクォータとソフトクォータを指定します。

ECS 管理 REST API の詳細については、 ECS 管理 REST API の使用（252 ページ）を参照してください。オンラインのリファレンスについては、こちらを参照してください。

保存期間と保存ポリシーECS には、指定した保存期間内でのデータの変更を防止する機能があります。

保存期間は、オブジェクトとバケットに関連づけられたメタデータで定義でき、オブジェクトの変更リクエストがあるたびに確認されます。保存期間は、すべてのオブジェクトインターフェイス（S3、Swift、Atmos、CAS）でサポートされます。ただし、CAS データは変更できないため、CAS に適用した保存期間は CAS オブジェクトの削除機能が対象になります。

バケットの保存期間は ECS ポータルで設定が可能ですが、オブジェクトへの保存期間/ポリシーの割り当てはオブジェクトインターフェイスを使用して行う必要があります。

保存の定義方法は 2 つあります。保存期間と保存ポリシーです。

保存期間

保存期間は、オブジェクトまたはバケットレベルで割り当てられます。保存期間をバケットに割り当てた場合は、バケット内のオブジェクトの変更を試みるたびに、バケットの保存期間が確認され、有効期限が計算されます。

たとえば、財務ドキュメントを作成日から 3 年間保存する必要がある場合があります。オブジェクトの保存期間を無期限にすることもできます。

保存ポリシー

保存ポリシーを使用すると、保存用途を収集してオブジェクトに適用できます。たとえば、ドキュメントのタイプごとに異なる保存期間を割り当てることができます。必要な保存期間は、次のとおりです。

l 財務：3 年間

l 法務：5 年間

l メール：6 か月間

保存ポリシーが複数のオブジェクトに適用されている場合は、ポリシーを変更することで、ポリシーが適用されているすべてのオブジェクトの保存期間を変更できます。

保存ポリシーの作成方法

ネームスペースに使用可能な保存ポリシーは、ECS ポータルで構成できます。以下のトピックを参照してください。

テナントのネームスペースの構成（76 ページ）

または、ECS 管理 REST API を使用して作成できます。その方法を次にまとめます。

方法説明

PUT /object/bucket/{bucketName}/retention バケットの保存値は、バケット内のすべてのオブ

ジェクトに適用されるデフォルトの保存期間を定


保存期間と保存ポリシー 85

http://www.emc.com/techpubs/api/ecs/v2-0-0-0/index.htm

方法説明

義します。たとえば、保存期間を 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 管理 REST API にアクセスする方法については、 ECS 管理 REST API の使用（252 ページ）を参照してください。オンラインのリファレンスについては、こちらを参照してください。

保存ポリシーと保存期間の適用方法

ECS ポータルを使用して、バケットに保存期間を適用できます。

オブジェクトサービスプロトコルを使用してオブジェクトまたはバケットを作成する（たとえば、S3 プロトコルをサポートするクライアントを使用して S3 バケットを作成する）場合は、x-ems ヘッダーで保存期間または保存ポリシーを適用できます。

オブジェクトの作成では、次の保存期間ヘッダーと保存ポリシーヘッダーを適用できます。

l x-emc-retention-period

l x-emc-retention-policy

バケットの作成では、x-emc-retention-period ヘッダーを使用して保存期間を設定できます。

バケットとユーザーのロックECS では、バケットにアクセスできないように、ユーザーのアクセスを防止できます。

バケットとユーザーのロック操作は、ECS 管理 REST API で行うことができ、ECS ポータルでは行えません。次のコールがサポートされます。

方法説明

PUT /object/bucket/{bucketName}/lock バケットをロックする。バケットに書き込めなくなり

ます。

DELETE /object/bucket/{bucketName}/lock バケットのロックを解除する。バケットに再び書き

込めるようになります。




方法説明

PUT /object/users/{userid}/lock オブジェクトユーザー（AD ユーザーではない）を

ロックする。そのユーザーが以後に API 操作を

行うとエラーになります。

DELETE /object/user/{userid}/lock オブジェクトユーザー（AD ユーザーではない）の

ロックを解除する。そのユーザーが再び API 操作を行えるようになります。

ECS 管理 REST API にアクセスする方法については、 ECS 管理 REST API の使用（252 ページ）を参照してください。オンラインのリファレンスについては、こちらを参照してください。

測定ECS では、ネームスペースとバケットのレベルでオブジェクトストレージの使用状況を測定できます。

ポータルを使用した測定

ECS ポータルを使用して、ネームスペースとバケットの使用状況を監視できます。［Monitor］ > ［Metering］ページでは、ネームスペースまたはネームスペースの特定のバケットを選択すると、その測定データが表示されます。

表 7 バケットとネームスペースの測定

属性説明

Total Size (GB) 選択したネームスペースまたはバケットに保存されたオブジェクト

の合計サイズ。

Object Count フィルターで指定した期間の終了時に、選択したネームスペース

またはバケットに関連づけられているオブジェクトの数。

Objects Created 期間内に、選択したネームスペースまたはバケットに作成された

オブジェクトの数。

Objects Deleted 期間内に、選択したネームスペースまたはバケットから削除され

たオブジェクトの数。

Bandwidth Ingress (MB) 指定の期間内に、選択したネームスペースまたはバケットが受け

取ったオブジェクトデータ（書き込み）の合計。

Bandwidth Egress (MB) 指定の期間内に、選択したネームスペースまたはバケットから送

られたオブジェクトデータ（読み取り）の合計。

測定データは、システムの追加データと削除データの統計を収集するのに長時間を要することから、すぐには利用できません。

これらのデータへのアクセスについては、ストレージの監視：測定と容量（106 ページ）を参照してください。

API を使用した測定

次の API パスを使用して、測定データを取得できます。


測定 87


方法説明

GET /object/billing/buckets/{namespace}/{bucket}/info?sizeunit=<KB|MB|GB>

指定したネームスペース内のバケットの現在の

使用状況を取得。

GET /object/billing//buckets/{namespace}/{bucket}/sample?start_time=<ISO8061_format>&end_time=<ISO8061_format>&marker=<string_marker>&sizeunit=<KB|MB|GB>

指定したタイムスライスのバケットアクティビティ

のサンプルを取得。デフォルトでは、バケットの

小サンプル解像度は 5 分間で、サンプルは

30 日間保持されます。開始時刻と終了時刻が

サンプルの範囲に収まらないと、エラーが返され

ます。時間範囲が複数の下位レベルサンプル

に及ぶ場合は、データが集約されて、期間は 1つのデータポイントを表します。

GET /object/billing/namespace/{namespace_name}/info?marker=<string_marker>&include_bucket_detail=<true|false>&sizeunit=<KB|MB|GB>

ネームスペース内のすべてのバケットの使用状

況データを取得。

バケットの詳細が含まれていると、ディスク上の

合計サイズが、バケットの詳細なしの合計サイズ

と異なる場合があります。これは、合計サイズの

計算でバケットサイズが四捨五入されて集計さ

れるためです。

GET /object/billing/namespace/{namespace_name}/sample?start_time=<ISO8061_format>&end_time=<ISO8061_format>&marker=<string_marker>&include_bucket_detail=<true|false>&sizeunit=<KB|MB|GB>

ネームスペースの特定の時間サンプルのスナッ

プショットを取得。デフォルトでは、バケットとネー

ムスペースのサンプル取得は 5 分おきで、サン

プルは 30 日間保持されます。開始時刻と終了

時刻がサンプルの範囲に収まらないと、エラー

が返されます。時間範囲が複数の下位レベル

サンプルに及ぶ場合は、データが集約されて、

期間は 1 つのデータポイントを表します。


バケットの監査コントローラー API には、S3、EMC Atmos、OpenStack Swift オブジェクトインターフェイスの使用を監査する機能があります。

オブジェクトコンテナー（S3 バケット、EMC Atmos サブテナント、OpenStack Swift コンテナー）への以下の操作がログに記録されます。

l Create Bucket

l Delete Bucket

l Update Bucket

l Set Bucket ACL

l Change Bucket Owner

l Set Bucket Versioning

l Set Bucket Versioning Source

l Set Bucket Metadata




l Set Bucket Head Metadata

l Set Bucket Expiration Policy

l Delete Bucket Expiration Policy

l Set Bucket Cors Configuration

l Delete Bucket Cors Configuration

ポータルでの監査ログ

ポータルの［Monitor］ > ［Events］ページを使用して、監査ログイベントの生成を検出できます。

root ユーザーは、システムに初にアクセスする場合のみ使用します。初にアクセスしたときに、root ユーザーのパスワードを［Settings］ > ［Password］ページで変更し、新しいシステム管理者のアカウントを 1 つ以上作成する必要があります。監査上、どのユーザーがシステムに対する変更を実行したかを知ることが重要なため、root は使用しないでください。システム管理者ユーザーはそれぞれ自分のアカウントを持つ必要があります。

イベントログの使用については、イベントの監視：監査ポータル、API、CLI イベント、システムアラート（128 ページ）を参照してください。

API の監査

バケットの監査は、次の ECS 管理 REST API コールでサポートされます。

方法説明

GET /monitoring/events 指定したネームスペースと期間の監査イベントを

取得する。



バケットの監査 89


第 11 章

EC サイトのフェイルオーバー

l サイトのフェイルオーバー/VDC の削除.................................................................. 92

EC サイトのフェイルオーバー 91

サイトのフェイルオーバー/VDC の削除VDC を削除するには、次の手順を実行します。複数サイトの連携の一部となっている VDCを削除すると、サイトのフェイルオーバーが開始します。

災害の発生時は、VDC 全体がリカバリ不能になる可能性があります。 ECS では、リカバリ不能な VDC を初は一時的なサイトの障害として処理します。障害が継続する場合は、連携から VDC を削除してフェイルオーバー処理を開始し、障害が発生した VDC に格納されたオブジェクトを再構築して再度保護する必要があります。リカバリタスクはバックグラウンド処理として実行されます。リカバリプロセスを確認するには、［Monitor］ > ［Geo Replication］ >［Failover Procesing］を使用します。

手順

1. 連携している操作可能な VDC のいずれかにログインします。

2. ［Manage］ > ［Replication Group］を選択します。

3. 削除する VDC が含まれたレプリケーショングループの［Edit］をクリックします。

4. 削除する VDC とストレージプールが含まれた行の［Delete］をクリックします。


6. ［Manage］ > ［VDC］を選択します。完全に削除された VDC のステータスがPermanently failedに変わります。

7. 削除する VDC の行のドロップダウンから［Delete］を選択します。


EC サイトのフェイルオーバー


第 5 部

モニタ

第 12 章, "リソースの監視：ハードウェア、ネットワークトラフィック、ディスク帯域幅、ノード、プロセスの稼働状態"

第 13 章, "ストレージの監視：測定と容量 "

第 14 章, "サービスログの監視"

第 15 章, "サービスの監視：チャンク、消失符号化、ジオレプリケーション、リカバリス

テータス"

第 16 章, "イベントの監視：監査ポータル、API、CLI イベント、システムアラート"

モニタ 93

モニタ


第 12 章

リソースの監視：ハードウェア、ネットワークトラフィック、ディスク帯域幅、ノード、プロセスの稼働状態

l リソースの監視について........................................................................................ 96l 監視ページの使用.................................................................................................96l ハードウェアの監視............................................................................................... 98l ネットワークトラフィックの監視...............................................................................99l ディスク帯域幅の監視......................................................................................... 100l ノードとプロセスの稼働状態の監視..................................................................... 102

リソースの監視：ハードウェア、ネットワークトラフィック、ディスク帯域幅、ノード、プロセスの稼働状態 95

リソースの監視についてECS ポータルのリソース監視機能について説明します。

リソース監視には以下が含まれます。

l ハードウェアの稼働状態（98 ページ）

l ネットワークトラフィックのメトリック（99 ページ）

l ディスク帯域幅（100 ページ）

l ノードとプロセスの稼働状態（102 ページ）

ECS ポータルの［Monitor］メニューには、これらの監視対象領域に対応するページがあります。

ECS ポータルのその他の監視機能については、以下の記事を参照してください。

l ストレージの監視：測定と容量（106 ページ）

l サービスの監視：チャンク、消失符号化、ジオレプリケーション、リカバリステータス（116 ページ）

l イベントの監視：監査ポータル、API、CLI イベント、システムアラート（128 ページ）

監視ページの使用ECS ポータルの監視ページの基本的な使い方を説明します。

ECS ポータルの監視ページには、共通の操作方法がいくつかあります。それらについては以下のとおりです。

l 検索：監視結果の絞り込みが可能な場合は、検索アイコンが表示されます。検索文字列と一致する文字列を含む結果行を検索できます。図 15 検索

l 更新：更新アイコンをクリックすると、監視の表示を新のデータに更新できます。図 16 更新

l フィルター：フィルターフィールドとデータ範囲を入力して［Filter］を選択すると、すべてのフィルターフィールドに一致する結果行が表示されます。デフォルトのデータ範囲は、昨日と今日です。図 17 フィルター

l 列による並べ替え：列見出しを一度クリックすると、結果が列の昇順に並びます。もう一度クリックすると、降順に並びます。



図 18 並べ替え

l 階層リンクによる表示のドリルダウン：階層リンクを使用して簡単に詳細画面にドリルダウンしたり、そこからドリルアップしたりできます。以下の例を参照してください。

l 履歴チャートでの左から右へのマウス移動による表示：過去 5 日分のデータの時間ごとのスナップショットを示す詳細チャートで、マウスカーソルを左から右に動かしてデータを確認できます。以下の例を参照してください。

図 19 階層リンクを使用した移動

テーブル行のテキストをハイライト表示すると、詳細表示へのリンクが示されます。リンクを選択すると、次の詳細レベルにドリルダウンできます。ドリルダウンした表示では、一連の表示での現在位置がパスの文字列に示されます。このパスの文字列を、階層リンクトレイル（階層リンク）と呼びます。ハイライトされた階層リンクを選択すると、関連する表示にジャンプできます。

図 20 カーソルをアクティブにしたデータチャート

［History］ボタンを選択すると、その行で使用できるすべてのチャートがテーブルの下に表示されます。チャート上で左から右にマウスを動かすと、縦線が表示され、特定の日時のポ


監視ページの使用 97

イントを見つけることができます。ポップアップ表示に、そのポイントの値とタイムスタンプが表示されます。

ハードウェアの監視［Monitor］ > ［Hardware Health］ページの使用方法について説明します。

ハードウェアの稼働状態は、3 種類のステータスで示されます。

l Good：ハードウェアコンポーネントは通常の動作状態にあります。

l Suspect：ハードウェアメトリックの減少によりハードウェアコンポーネントの状態がGood から Bad に変化しているか、下位のハードウェアコンポーネントに問題があるか、接続の問題によりハードウェアがシステムで検出されない状態です。

l Bad：ハードウェアの交換が必要です。

ディスクの場合、これらのステータスは次の意味があります。

l Good：システムはディスクの読み取り/書き込みをアクティブに行っています。

l Suspect：システムはディスクの書き込みを行わなくなりましたが、読み取りは行います。 Suspect ステータスのディスクが多数ある場合は、ノードでの接続の問題が考えられます。このようなディスクは、接続の問題が解消すると、Good ステータスに戻ります。

l Bad：システムはディスクの読み取り/書き込みを行っていません。ディスクを交換してください。 ECS システムで Bad と識別されたディスクは、ECS システム内で再使用することはできません。ディスクに障害が発生すると、ECS のデータ保護機能によって、ディスク上にあったデータのコピーがシステム内の別のディスク上に再作成されます。 Bad ディスクは、単にシステムの容量の損失を表すものであり、データの損失を表すものではありません。ディスクの交換後、新しいディスクにはデータは復元されません。これは単にシステムの raw 容量になります。

手順

1. ［Monitor］ > ［Hardware Health］を選択します。

2. ターゲットストレージプールのテーブル行を見つけます。

3. 必要に応じて、ストレージプール名を選択して、ノード表示をドリルダウンします。

4. 必要に応じて、ノードエンドポイントを選択して、ディスク表示をドリルダウンします。



図 21 Hardware Health

ディスク ID を使用して交換対象ディスクを見つける方法については、U シリーズアプラ

イアンスの ECS ストレージディスクの交換（296 ページ）を参照してください。

ネットワークトラフィックの監視ECS ポータルのネットワークトラフィック監視ページについて説明します。

［Monitor］ > ［Traffic Metrics］ページでは、仮想データセンターまたは各ノードレベルのネットワークのトラフィックメトリックを確認できます。チャートには、過去 7 日間のデータが表示されます。

表 8 ネットワークトラフィックのメトリック

メトリックラベル説明

R Avg. Latency (ms) 読み取りの平均レーテンシー（ミリ秒）。

W Avg. Latency (ms) 書き込みの平均レーテンシー（ミリ秒）。

R Bandwidth 読み取りの帯域幅（MB/秒）。


ネットワークトラフィックの監視 99

表 8 ネットワークトラフィックのメトリック（続き）


W Bandwidth 書き込みの帯域幅（MB/秒）。

R Transactions (per/s) 秒あたりの読み取りトランザクション数。

W Transactions (per/s) 秒あたりの書き込みトランザクション数。

Recent Transaction Failuresper type

監視期間に発生したエラーコードごとの、総エラーにおけるコード

の割合（%）。

手順

1. ［Monitor］ > ［Traffic Metrics］を選択します。

2. ターゲットの VDC 名を見つけます。

3. 必要に応じて、VDC 名を選択して、ノード表示をドリルダウンします。

4. ターゲットの VDC またはノードの［History］ボタンを選択します。

図 22 VDC のネットワークトラフィックチャート

ディスク帯域幅の監視ECS ポータルのディスク帯域幅監視ページについて説明します。

［Monitor］ > ［Disk bandwidth］ページでは、仮想データセンターまたは各ノードレベルのディスク使用状況メトリックを確認できます。 VDC またはノードごとに読み取りに関する行と書き込み関する行があります。チャートには、過去 7 日間のデータが表示されます。



表 9 ディスク帯域幅のメトリック


Total 読み取りまたは書き込み操作で使用された合計ディスク帯域幅（KB/秒）。

HardwareRecovery

ハードウェア障害後にデータリカバリで使用されたディスク帯域幅の量。

Erasure Encoding システムの消失符号化操作で使用されたディスク帯域幅の量。

XOR システムの XOR データ保護操作で使用された合計ディスク帯域幅の量。 XOR操作は、サイト（VDC）が 3 つ以上あるシステムで行われます。

ConsistencyChecker

保護されるデータとそのレプリカとの不整合のチェックで使用されたディスク帯

域幅の量。

Geo ジオレプリケーション操作のサポートで使用されたディスク帯域幅の量。

User Traffic オブジェクトユーザーが使用したディスク帯域幅の量。

手順

1. ［Monitor］ > ［Disk Bandwidth］を選択します。

2. ターゲット VDC の名前を見つけて、その VDC の［Read］または［Write］テーブル行を確認します。

3. 必要に応じて、［Node Count］を選択し、VDC のノードの行を含むテーブルまでドリルダウンします。

4. VDC またはノードの［History］ボタンを選択します。

図 23 ディスク帯域幅


ディスク帯域幅の監視 101

ノードとプロセスの稼働状態の監視ECS ポータルのノードおよびプロセス稼働状態監視ページについて説明します。

［Monitor］ > ［Node & Process Health］ページでは、VDC、ノード、ノードプロセスの稼働状態の評価に役立つメトリックを確認できます。

表 10 VDC、ノード、プロセスの稼働状態のメトリック

メトリックラベルレベル説明

Avg. NIC Bandwidth VDC とノード選択した VDC またはノード

で使用されたネットワーク

インターフェイスコントロー

ラーハードウェアの平均帯

域幅。

Avg. CPU Usage (%) VDC とノード選択した VDC またはノード

で使用された CPU ハード

ウェアの平均割合（%）。

Avg. Memory Usage VDC とノード VDC またはノードで使用可

能な総メモリの平均使用量

（MB）。

Relative NIC (%) VDC とノード選択した VDC またはノード

で使用されたネットワーク

インターフェイスコントロー

ラーハードウェアの使用可

能帯域幅の割合（%）。

Relative Memory (%) VDC とノード選択した VDC またはノード

で使用可能なメモリの使用

された割合（%）。

CPU（%）プロセスプロセスで使用されたノー

ドの CPU の割合（%）。

Memory Usage プロセスプロセスで使用されたメモ

リ（MB）。

Relative Memory (%) プロセスプロセスで使用可能なメモ

リの使用された割合（%）。

Avg. # Thread プロセスプロセスで使用されたスレ

ッドの平均数。

Last Restart プロセスノードでプロセスが前回再

起動された時間。

手順

1. ターゲット VDC のテーブル行を見つけます。

2. 必要に応じて、VDC 名を選択し、VDC の各ノードの行を含むテーブルまでドリルダウンします。

3. 必要に応じて、ノードエンドポイントを選択し、ノードで実行される各プロセスの行を含むテーブルまでドリルダウンします。



4. ターゲットの VDC、ノード、プロセスのいずれかの［History］ボタンを選択します。

図 24 Node & Process Health


ノードとプロセスの稼働状態の監視 103

第 13 章

ストレージの監視：測定と容量

l 概要....................................................................................................................106l 監視ページの使用...............................................................................................106l 容量の監視.........................................................................................................108l 測定データの監視............................................................................................... 110

ストレージの監視：測定と容量 105

概要ECS には、バケットとネームスペースのレベルでのオブジェクトの作成と削除を測定する機能があります。 ECS では、容量使用率も監視できます。

ECS ポータルの［Monitor］メニューには、これらの監視機能に対応するパネルがあります。そのアクセスメカニズムと、パネルに表示されるデータについては、以下のトピックで説明します。

l 測定データの監視（110 ページ）

l 容量の監視（108 ページ）


l リソースの監視：ハードウェア、ネットワークトラフィック、ディスク帯域幅、ノード、プロセスの稼働状態（96 ページ）








l 列による並べ替え：列見出しを一度クリックすると、結果が列の昇順に並びます。もう一度クリックすると、降順に並びます。



図 28 並べ替え










容量の監視ストレージプール、ノード、ディスクの容量使用率を監視できます。

容量テーブルとその表示については、ストレージ容量データ（108 ページ）で説明します。各テーブルに関連づけられた履歴表示で期間内のテーブルデータの変化を確認できます。

ECS 管理 REST API により、カスタムクライアントを使用してプログラム式にデータを取得できます。この機能やテナント管理のためのその他の機能のサポートについては、テナントの管理（84 ページ）を参照してください。ECS 管理 REST API リファレンスについては、こちらを参照してください。

手順

1. ECS ポータルで、［Monitor］ > ［Capacity］を選択します。

2. テーブルの該当するリンクを選択すると、ノードや各ディスクをドリルダウンできます。

テーブルの操作方法については、監視ページの使用（96 ページ）を参照してください。

3. 期間内に容量がどう変化したかを表示するには、対象のストレージプール、ノード、ディスクの［History］を選択します。

ストレージ容量データ

［Monitor］ > ［Capacity Utilization］ページでは、ストレージプール、ノード、ディスクのストレージ容量を確認できます。

以下で容量使用率エリアについて説明します。

l Storage Pool Capacity（108 ページ）

l ノードの容量使用率（109 ページ）

l ディスクの容量使用率（110 ページ）

容量表示の操作方法については、監視ページの使用（96 ページ）を参照してください。

Storage Pool Capacity

表 11 容量使用率：ストレージプール

属性説明

Storage Pool ストレージプールの名前。

Nodes ストレージプール内のノードの数。

表示するノードの番号をクリックします。ノードの容量使用率

（109 ページ）

Disks ストレージプール内のディスクの数。

Usable Capacity 合計有効容量。使用済み容量と割り当て可能空き容量の合計で

す。

Used Capacity ストレージプール内の使用済み容量。

Used Capacity 使用可能な容量。

Actions 次のアクションを実行可能：［History］。




表 11 容量使用率：ストレージプール（続き）

属性説明

［History］を選択すると、容量の使用状況の履歴がグラフ表示さ

れます。

ストレージプールの容量使用率テーブルの履歴表示を次に示します。

ノードの容量使用率

表 12 容量使用率：ノード

属性説明

Nodes ノードの IP アドレス。

Disks ノードに関連づけられたディスクの数。表示するノードの番号をク

リックします。ディスクの容量使用率（110 ページ）

Usable Capacity ノード内のディスクで提供される合計有効容量。使用済み容量と

割り当て可能空き容量の合計です。

Used Capacity ノードで使用されている容量。

Available Capacity ノードで使用可能な残り容量。

Node Status チェックマークが付いていれば、ステータスは「Good」。

Actions 次のアクションを実行可能：［History］［History］を選択すると、容量の使用状況の履歴がグラフ表示さ

れます。

ノードの容量使用率テーブルの履歴表示を次に示します。


ストレージ容量データ 109

ディスクの容量使用率

表 13 容量使用率：ディスク

属性説明

Disk ディスクの ID。

Usable Capacity ディスクで提供される有効容量。

Used Capacity ディスクで使用されている容量。

Available Capacity ディスクで使用可能な残り容量。

Disk Status チェックマークが付いていれば、ステータスは「Good」。

Actions 次のアクションを実行可能：［History］［History］を選択すると、容量の使用状況の履歴がグラフ表示さ

れます。

ディスクの使用率テーブルの履歴表示を次に示します。

測定データの監視測定データを表示したいネームスペースまたはネームスペース内のバケットを選択し、測定データを表示する期間を指定することができます。

使用可能な測定データの詳細については、測定データ（111 ページ）で説明します。

ECS 管理 REST API により、カスタムクライアントを使用してプログラム式にデータを取得できます。この機能やテナント管理のためのその他の機能のサポートについては、テナントの



管理（84 ページ）を参照してください。ECS 管理 REST API リファレンスについては、こちらを参照してください。

手順

1. ECS ポータルで、［Monitor］ > ［Metering］を選択します。

2. 測定データを表示するネームスペースを選択します。

ネームスペース管理者は、自分のネームスペースのみを選択できます。

3. 必要に応じて、オブジェクトデータを表示するバケットの名前を入力します。

バケットを指定しない場合は、オブジェクトの測定データはネームスペース内のすべてのバケットの合計になります。

4. ［From］/［To］のカレンダーを使用して、データを表示する期間を選択します。

測定データは 30 日間保持されます。

5. ［Filter］をクリックすると、選択したネームスペース、バケット、期間の測定データが表示されます。

測定データ

ECS ポータルの［Monitor］ > ［Metering］ページでは、指定のネームスペースまたはネームスペース内の指定のバケットに関するオブジェクト測定データを一定期間取得できます。

表 14 バケットとネームスペースの測定

属性説明

Total Size (GB) 選択したネームスペースまたはバケットに保存されたオブジェクト

の合計サイズ。

Object Count フィルターで指定した期間の終了時に、選択したネームスペース

またはバケットに関連づけられているオブジェクトの数。

Objects Created 期間内に、選択したネームスペースまたはバケットに作成された

オブジェクトの数。

Objects Deleted 期間内に、選択したネームスペースまたはバケットから削除され

たオブジェクトの数。

Bandwidth Ingress (MB) 指定の期間内に、選択したネームスペースまたはバケットが受け

取ったオブジェクトデータ（書き込み）の合計。

Bandwidth Egress (MB) 指定の期間内に、選択したネームスペースまたはバケットから送

られたオブジェクトデータ（読み取り）の合計。

測定データは、システムの追加データと削除データの統計を収集するのに長時間を要することから、すぐには利用できません。


測定データ 111


第 14 章

サービスログの監視

l サービスログ...................................................................................................... 114l ECS サービスログの場所.................................................................................... 114

サービスログの監視 113

サービスログECS サービスのログの場所と機能について説明します。

ストレージ管理者がノードに SSH 接続してログにアクセスする権限を持つ場合は、ECS サービスログにアクセスできます。通常は、システムの状態を知るには、ECS ポータルの［Monitoring］ページを使用する方法が適しています。

ECS サービスログの場所ECS サービスのログの場所と内容について説明します。

ECS サービスログには、ノードの SSH セッションで直接アクセスできます。次のディレクトリに変更します。 /opt/emc/caspian/fabric/agent/services/object/main/log。以下のオブジェクトサービスログがあります。

l authsvc.log：認証サービスの情報を記録するログ。

l blobsvc*.log：BLOB サービスに関して記録するログ。

l cassvc*.log：CAS サービスに関して記録するログ。

l coordinatorsvc.log：コーディネーターサービスの情報を記録するログ。

l ecsportalsvc.log：ECS ポータルサービスの情報を記録するログ。

l eventsvc*.log：イベントサービスに関して記録するログ。この情報は、ECS ポータ

ルの［Monitoring］メニューで利用できます。

l hdfssvc*.log：HDFS サービスに関して記録するログ。

l objcontrolsvc.log：オブジェクトサービスの情報を記録するログ。

l objheadsvc*.log：オブジェクトサービスでサポートされる各種のオブジェクトヘッド

に関して記録するログ。

l provisionsvc*.log：ECS のプロビジョニングサービスに関して記録するログ。

l resourcesvc*.log：ECS のチャンク機能に関して記録するログ。

サービスログの監視


第 15 章

サービスの監視：チャンク、消失符号化、ジオレプリケーション、リカバリステータス

l サービス監視について.........................................................................................116l 監視ページの使用...............................................................................................116l チャンクの監視....................................................................................................118l 消失符号化の監視.............................................................................................. 119l リカバリステータスの監視................................................................................... 120l ジオレプリケーションの監視：レートおよびチャンク..............................................121l ジオレプリケーションの監視： RPO（Recovery Point Objective：目標復旧時点）..... 122l ジオレプリケーションの監視：フェイルオーバー................................................... 123l ジオレプリケーションの監視：ブートストラップ処理.............................................. 124

サービスの監視：チャンク、消失符号化、ジオレプリケーション、リカバリステータス 115

サービス監視についてECS ポータルのサービス監視機能について説明します。

サービス監視には以下が含まれます。

l チャンクサマリー（118 ページ）

l 消失訂正符号（119 ページ）

l リカバリステータス（120 ページ）

l ジオレプリケーション：レートおよびチャンク（121 ページ）

l ジオレプリケーション： RPO（目標復旧時点）（122 ページ）

l ジオレプリケーション：フェイルオーバー処理（123 ページ）

l ジオレプリケーション：ブートストラップ処理（123 ページ）

ECS ポータルの［Monitor］メニューには、これらの監視対象領域に対応するページがあります。［Geo Replication］ページは、4 つに分かれています。












l 列による並べ替え：列見出しを一度クリックすると、結果が列の昇順に並びます。もう一度クリックすると、降順に並びます。図 34 並べ替え










チャンクの監視ECS ポータルのチャンク監視ページについて説明します。

このページには、ローカルゾーンの封印されたチャンクの統計レポートが表示されます。封印されたチャンクとは、書き込みを受け入れることができなくなったチャンクのことです。このチャンクは変更できません。

表 15 チャンクのテーブル

表説明

Chunk Count ofEach Type

ローカルゾーンに構成された各ストレージプールのさまざまなチャンクタイプのう

ち、封印されたチャンクの数と割合（%）。

Total Length ofEach ChunkType


ち、封印されたチャンクの合計論理サイズ。

Avg SealedLength of EachType


ち、封印されたチャンクの平均論理サイズ。

表 16 チャンクメトリック

メトリックラベル

説明

Storagepools

ローカル VDC に構成されたストレージプールのリスト。各行には、指定したストレージ

プールのチャンクメトリックが表示されます。

Repo Userdata

リポ（リポジトリ）チャンクに保存されているユーザーデータ。

この列には、ストレージプール内のリポチャンクの関連データが表示されます。

Level-0btree

B ツリーチャンクには、ユーザーデータの構成と場所に関するシステムメタデータが含

まれます。レベル 0 は、システム内で下位レベルのデータ（オブジェクトテーブルや

基本的なルックアップテーブルなど）を意味します。

この列には、ストレージプール内の B ツリーレベル 0 チャンクの関連データが表示さ

れます。

Level-0journal

ジャーナルチャンクには、障害リカバリデータが含まれます。レベル 0 は、システム内

で下位レベルのデータ（オブジェクトテーブルやルックアップテーブルなど）を意味し

ます。

この列には、ストレージプール内のジャーナルレベル 0 チャンクの関連データが表示

されます。

Level-1btree

B ツリーチャンクには、ユーザーデータの構成と場所に関するシステムメタデータが含

まれます。レベル 1 は、システム内の比較的複雑なデータを意味します。

この列には、ストレージプール内の B ツリーレベル 1 チャンクの関連データが表示さ

れます。

Level-1journal

ジャーナルチャンクには、障害リカバリデータが含まれます。レベル 1 は、システム内

の比較的複雑なデータを意味します。



表 16 チャンクメトリック（続き）

メトリックラベル

説明

このフィールドには、ストレージプール内のジャーナルレベル 1 チャンクの関連データ

が表示されます。

Geo copy ジオチャンクは、他のゾーン（VDC）のデータのレプリカを含むチャンクです。

このフィールドには、ストレージプール内のジオコピーチャンクの関連データが表示さ

れます。

XOR XOR チャンクは、XOR アルゴリズムを使用して他のチャンクのデータを圧縮し、それら

のチャンクを XOR チャンクと置換することにより、ディスク領域を節約するチャンクで

す。

このフィールドには、ストレージプール内の XOR チャンクの関連データが表示されま

す。

Total ストレージプール内のチャンクの合計数。

チャンクメトリック図 37 Chunk Summary

消失符号化の監視［Monitor］ > ［Erasure Coding］ページの使用方法について説明します。

［Erasure Coding］ページでは、ユーザーデータの合計量と、ローカルストレージプール内の消失符号化済みデータを監視します。消失符号化保留中のデータの量、現在の処理速度、予測される完了時間も表示されます。チャートには、7 日分のデータが保持されます。

表 17 消失符号化のメトリック

列説明

Storage Pool


消失符号化の監視 119

表 17 消失符号化のメトリック（続き）

列説明

Total User Data ストレージプール内のユーザーデータチャンクの合計論理サイズ。

Total Erasure CodedData

ストレージプール内のすべての消失符号化済みチャンクの合計論理サイ

ズ。

Rate of Erasure Coding 消失符号化を待機中の現在のデータの処理速度。

Est Time to Complete 現在の消失符号化処理速度から予測される完了時間。

手順

1. ［Monitor］ > ［Erasure Coding］を選択します。


3. ［History］ボタンを選択します。

リカバリステータスの監視［Monitor］ > ［Recovery Status］ページの使用方法について説明します。

リカバリは、ローカルで低品質のデータ（チャンク）が生成された後にデータを再構築するプロセスです。次の表に、ローカルゾーンの各ストレージプールの行を示します。



表 18 リカバリメトリック

列説明

Storage Pool ローカルゾーンの各ストレージプールのリスト

Total Amount Data tobe Recovered

まだリカバリされていないデータの論理サイズ

Recovery Rate 指定したストレージプールでリカバリされるデータのレート（バイト/秒単位）

Time to Completion 現在のリカバリレートから推定されるリカバリ完了予定時間

手順

1. ［Monitor］ > ［Recovery Status］を選択します。


3. ［History］ボタンをクリックします。

ジオレプリケーションの監視：レートおよびチャンクECS ポータルの［Monitor］ > ［Geo-Replication］ > ［Rate and Chunks］ページのテーブルフィールドについて説明します。

このページには、レプリケーションのネットワークトラフィックと、VDC またはレプリケーショングループによるレプリケーションを待機中のチャンクのネットワークトラフィックに関する基本的なメトリックが表示されます。


ジオレプリケーションの監視：レートおよびチャンク 121

表 19 ［Rate and Chunks］の列

列説明

Remote Zone ローカル VDC を含むレプリケーショングループを持つリモート VDC のリスト。

表示されているデータは VDC の UUID です。

Replication Group このゾーン（VDC）が参加するレプリケーショングループのリスト。

Write Traffic VDC またはレプリケーショングループへの現在の書き込みレート（GB/秒単

位）。

Read Traffic VDC またはレプリケーショングループへの現在の読み取りレート（GB/秒単

位）。

Repo ChunksPendingReplication TotalSpace

レプリケーションを待機中のすべてのユーザーデータ（リポジトリ）チャンクの

合計論理サイズ。

Journal ChunksPendingReplication TotalSpace

レプリケーションを待機中のすべてのシステムメタデータチャンクの合計論理

サイズ。

Chunks PendingXOR Total Space

XOR 圧縮アルゴリズムによる処理を待機中のすべてのチャンクの合計論理サ

イズ。

図 38 ［Geo replication］：［Rate and Chunks］

ジオレプリケーションの監視： RPO（Recovery Point Objective：目標復旧時点）

ECS ポータルの［Monitor］ > ［Geo-Replication］ > ［RPO］ページのテーブルフィールドについて説明します。

RPO（目標復旧時点）は、サービスの停止を許容する時間制限を示すビジネスルールです。この画面では、レプリケーショングループまたはゾーンのリカバリの所要時間を確認できます。



表 20 ［RPO］の列

列説明

RemoteReplicationGroup\RemoteZone

ローカルゾーンが参加しているすべてのリモートレプリケーショングループのリ

スト（VDC レベル）。レプリケーショングループレベルでは、この列にはレプリケー

ショングループのリモートゾーンがリストされます。表示されているデータは、

VDC またはレプリケーショングループのシステム識別子を URN で示しています。

Overall RPO(minutes)

レプリケーショングループまたはゾーンの後のリカバリの経過時間

図 39 RPO

ジオレプリケーションの監視：フェイルオーバーECS ポータルの［Monitor］ > ［Geo-Replication］ > ［Failover Processing］ページのメトリックについて説明します。

［Failover Processing］ページには、システム停止後に VDC 間の接続がリストアされた場合のレプリケーショングループ再同期プロセスに関するメトリックが表示されます。

表 21 フェイルオーバーの列


ReplicationGroup

ローカルゾーンが属するレプリケーショングループのリスト。表示されているデータ

は、レプリケーショングループのシステム識別子を URN で示しています。

Failed Zone レプリケーショングループに含まれるゾーンのうち、障害が発生したゾーン。複数

のゾーンで障害が発生した場合は、テーブルのレプリケーショングループに複数の

行が表示されます。表示されているデータは、ゾーンのシステム識別子を URN で

示しています。

Repo chunkspending re-replication(# / TotalSpace)

ゾーンの障害により、元のチャンクが正常にレプリケーションされたことをシステム

で確認できないため、再レプリケーションが必要なユーザーデータ（リポジトリデー

タ）を含むチャンクを表示。このフィールドには、再レプリケーションを待機している

チャンクの数と、それらのチャンクの合計論理サイズがリストされます。


ジオレプリケーションの監視：フェイルオーバー 123

表 21 フェイルオーバーの列（続き）


Journalchunkspending re-replication(# / TotalSpace)

ゾーンに障害が発生したことにより、元のチャンクが正常にレプリケーションされた

ことをシステムで確認できないため、再レプリケーションが必要な障害リカバリデー

タを含むチャンクを表示。このフィールドには、再レプリケーションを待機しているチ

ャンクの数と、それらのチャンクの合計論理サイズがリストされます。

Btree chunkspending re-replication(# / TotalSpace)

ゾーンに障害が発生したことにより、元のチャンクが正常にレプリケーションされた

ことをシステムで確認できないため、再レプリケーションが必要なシステムメタデー

タを含むチャンクを表示。このフィールドには、再レプリケーションを待機しているチ

ャンクの数と、それらのチャンクの合計論理サイズがリストされます。

Repo chunkspending XORdecoding (# /Total Space)

XOR 圧縮スキームによる取得を待機中のチャンクの数と合計論理サイズを表示。

Failover State l BLIND_REPLAY_DONE

l REPLICATION_CHECK_DONE：すべてのレプリケーションチャンクがアクセス可

能な状態であることを確認するプロセスが、正常に完了。

l CONSISTENCY_CHECK_DONE：すべてのシステムメタデータが他のレプリケー

ションデータと完全に整合性があることを確認するプロセスが、正常に完了。

l ZONE_SYNC_DONE：障害が発生したゾーンの同期が、正常に完了。

l ZONE_BOOTSTRAP_DONE：障害が発生したゾーンのブートストラッププロセス

が、正常に完了。

l ZONE_FAILOVER_DONE：フェイルオーバープロセスが、正常に完了。

FailoverProgress

フェイルオーバープロセス全体のステータスをパーセントで表示するインジケータ

ー。

図 40 フェイルオーバー

ジオレプリケーションの監視：ブートストラップ処理ECS ポータルの［Monitor］ > ［Geo Replication］ > ［Bootstrap Processing］ページのフィールドについて説明します。

ブートストラップは、ゾーンに追加されたレプリケーショングループに必要なメタデータをコピーするプロセスです。



表 22 ［Bootstrap Processing］の列

列説明

ReplicationGroup

ローカルゾーンが参加しており新しいゾーンが追加されているレプリケーショングループのリスト。各行には、指定したレプリケーショングループのメトリックが表示

されます。

Added Zone 指定したレプリケーショングループに追加されているゾーン。

Repo ChunksPendingReplicationTotal Space

障害が発生したゾーンへのレプリケーションを待機中のすべてのユーザーデータ

（リポジトリ）チャンクの論理サイズ。

Journal ChunksPendingReplicationTotal Space

障害が発生したゾーンへのレプリケーションを待機中のすべての障害リカバリチャ

ンクの論理サイズ。

Btree ChunksPendingReplicationTotal Space

障害が発生したゾーンへのレプリケーションを待機中のすべてのシステムメタデ

ータチャンクの論理サイズ。

BootstrapState

l Started：システムがレプリケーショングループへのゾーン追加の準備を開

始。

l BlindReplayDone

l ReplicationCheckDone：すべてのレプリケーションチャンクがアクセス可能な

状態であることを確認するプロセスが、正常に完了。

l ConsistencyCheckDone：すべてのシステムメタデータが他のレプリケーショ

ンデータと完全に整合性があることを確認するプロセスが、正常に完了。

l ZoneSyncDone：障害が発生したゾーンの同期が、正常に完了。

l ZoneBootstrapDone：障害が発生したゾーンのブートストラッププロセスが、

正常に完了。

l Done：ブートストラッププロセス全体が、正常に完了。

BootstrapProgress (%)

ブートストラッププロセス全体が完了した割合（%）。

図 41 Bootstrap Processing


ジオレプリケーションの監視：ブートストラップ処理 125

第 16 章

イベントの監視：監査ポータル、API、CLI イベント、システムアラート

l イベント監視について.......................................................................................... 128l 日付によるイベントのフィルターと列による結果の並べ替え..................................128

イベントの監視：監査ポータル、API、CLI イベント、システムアラート 127

イベント監視についてECS ポータルのイベント監視機能について説明します。

［Monitor］メニューの［Events］ページには以下が表示されます。

l ポータル、ECS REST API、ECS CLI を操作しているユーザーのすべてのアクティビティ。

l ECS システムによって発行されたアラート。

l ECS サービスによって発行されたアラート。

ECS ポータルに表示されるイベントデータは 5 日分です。それよりも長くイベントデータを保持する必要がある場合は、ViPR SRM の使用を検討してください。

ECS ポータルのその他の監視ページについては、以下の記事を参照してください。




日付によるイベントのフィルターと列による結果の並べ替えフィルター機能を使用してイベントを特定の日付範囲に絞り込み、結果を並べ替えます。

手順

1. ［From］フィールドに開始日を入力し、［To］フィールドに終了日を入力します。または、カレンダーアイコンをクリックして日付を選択します。デフォルトでは、これらのフィールドには昨日と今日の日付が入力されます。

2. ［Filter］を選択します。

3. ［User ID］、［Description］、［Namespace］、［Timestamp］のいずれかの列見出しをクリックすると、その昇順にデータが並びます。同じ列をもう一度クリックすると、降順に並びます。

図 42 日付範囲でフィルターしてユーザー ID の降順で並べ替えられたイベント表示

イベントの監視：監査ポータル、API、CLI イベント、システムアラート


第 6 部

データアクセスの有効化

第 17 章, "ECS オブジェクトストレージのアドレス指定とベース URL の使用 "

第 18 章, "バケットの作成と構成 "

第 19 章, "オブジェクトストレージアクセス用の秘密キーの取得 "

第 20 章, "ECS ポータルを使用した CAS SDK アプリケーションサポートの構成"

データアクセスの有効化 129

データアクセスの有効化


第 17 章

ECS オブジェクトストレージのアドレス指定とベース URL の使用

l はじめに..............................................................................................................132l バケットのアドレス指定........................................................................................132l ベース URL の追加.............................................................................................. 135

ECS オブジェクトストレージのアドレス指定とベース URL の使用 131

はじめにAmazon S3 を使用するように記述されたアプリケーションは、ベース URL パラメーターを設定することで、ECS オブジェクトストレージを使用できるようになります。ベース URL は、デフォルトでは amazonaws.com に設定されています。本稿では、リクエストが ECS にルーティングされるようにベース URL を設定する方法について説明します。

以降のセクションでは、ECS によってサポートされるアドレス指定スキーム、ベース URL パラメーターの使用、ベース URL パラメーターを設定するメカニズムについて説明します。

l バケットのアドレス指定（132 ページ）

l ベース URL の追加（135 ページ）

バケットのアドレス指定ECSS3 サービスでは、リクエストに定義された操作を実行する対象のバケットをいくつかの方法で識別できます。

Amazon S3 サービスを使用する場合、すべてのバケット名は一意である必要があります。ただし、ECSS3 サービスではネームスペースの使用がサポートされます。バケット名に加えてネームスペースを使用することで、異なるネームスペースで同名のバケットを使用できます。各テナントにそれぞれ名前空間を割り当てると、他のテナントで現在使用されている名前を考慮しなくても、テナント内で任意のバケット名を割り当てることができます。リクエストにネームスペースが指定されていない場合は、リクエストを作成したユーザーが属するテナントに関連づけられたデフォルトのネームスペースが ECS で使用されます。

オブジェクトの場所を示す名前空間は、HTTP リクエストの x-emc-namespace ヘッダー内で指定できます。 ECS では、ホストヘッダーからの場所の抽出もサポートされるので、Amazon S3 と互換性のある以下のアドレス指定スキームを使用できます。

l 仮想ホスト形式のアドレス指定（132 ページ）

l パスベースのアドレス指定（132 ページ）

仮想ホスト形式のアドレス指定

仮想ホスト形式のアドレス指定スキームでは、バケット名がホスト名内に表示されます。たとえば、ecs1.yourco.com ホスト上の「mybucket」というバケットは、次のアドレスを使用してアクセスされます。

http://mybucket.ecs1.yourco.com

また、ECS では、アドレスにネームスペースを含めることができます。例：

<bucketname>.<namespace>.ecs1.yourco.com

この形式のアドレス指定を使用するには、URL のどの部分がバケット名かを認識できるように ECS を構成する必要があります。これには、ベース URL を構成します。また、DNS システムがアドレスを解決可能であることを確認する必要があります。詳細については、以下のセクションを参照してください。

l DNS の構成（133 ページ）

l ベース URL（133 ページ）

パスベースのアドレス指定

パスベースのアドレス指定スキームでは、パスの末尾にバケット名が追加されます。次に例を挙げます。

ecs1.yourco.com/mybucket

名前空間を含める場合は、次の形式を使用します。



ecs1.yourco.com/mynamespace/mybucket

DNS の構成

S3 サービスを使用して ECS ストレージにアクセスする場合は、ECS データノードのアドレスまたはデータノードのロードバランサーのアドレスに URL が解決されることを確認する必要があります。

パス形式のアドレス指定を使用するアプリケーションの場合は、単純に、ベース名が DNSによって解決可能であれば問題ありません。たとえば、通常は ecs1.yourco.com/bucketの形式でリクエストを発行するアプリケーションの場合は、ecs1.yourco.com を ECS ノードアクセス用ロードバランサーの IP アドレスに解決する DNS エントリーを定義する必要があります。 Amazon のサービスを使用している場合は、この URI は s3-eu-west-1.amazonaws.com という形式となります。

仮想ホスト形式のアドレス指定を使用するアプリケーションの場合は、URL にバケット名が含まれ、名前空間が含まれることもあります。このような状況に対応するには、仮想ホスト形式のアドレスを解決する DNS エントリーを含める必要があります。これには、DNS エントリーにワイルドカードを使用します。

たとえば、通常は bucket.s3.yourco.com の形式でリクエストを発行するアプリケーションの場合は、次の 2 つの DNS エントリーが必要となります。

l ecs1.yourco.com

l *.ecs1.yourco.com

また、以前に bucket.s3.amazonaws.com を使用して Amazon S3 サービスに接続したアプリケーションを使用する場合は、次のエントリーが必要です。

l s3.amazonaws.com

l *.s3.amazonaws.com

このようなエントリーを使用することで、サービスレベルのコマンド（バケットリストの表示など）の発行時にベース名が解決され、仮想ホスト形式のバケットアドレスが解決されるようになります。

このサービスの SSL 証明書を作成する場合は、証明書名にワイルドカードエントリーを使用し、ワイルドカードのないバージョンをサブジェクト代替名として使用します。

ベース URL仮想ホスト形式のアドレス指定を使用する S3 アプリケーションの場合、このアプリケーションを使用して ECS に接続するには、アドレスのどの部分がバケット（およびオプションでネームスペース）を表すかが ECS によって認識されるように、ベース URL を設定する必要があります。ベース URL の設定には、ECS ポータルまたは ECS 管理 REST API を使用し、ECS システム管理者の役割が必要です。

［Base URL Management］ページには、作成済みのベース URL と、ECS でのその使用方法が表示されます。


DNS の構成 133

バケットの場所を示すプレフィックスの処理方法を ECS が認識できるようにするには、次のいずれかのオプションを選択して、ベース URL を構成する必要があります。

l 名前空間とともにベース URL を使用

l 名前空間を含めずにベース URL を使用

ECS は、次のようにリクエストを処理します。

1. x-emc-namespace ヘッダーから名前空間の展開を試みます。名前空間が見つかった場合は、次のステップをスキップしてリクエストを処理します。

2. ホストヘッダーから URL のホスト名を抽出し、アドレスの後の部分が、構成されたいずれかのベース URL と一致するかどうかを調べます。

3. 一致するベース URL が存在する場合は、ホスト名のプレフィックス部分（ベース URL を除去すると残る部分）を使用して、バケットの場所を特定します。

Amazon の S3 ブラウザーなど、一部のアプリケーションは、生成するリクエスト内に静的なエンドポイント（s3.amazonaws.comなど）を埋め込みます。このような多くのアプリケー

ションには、通信先のエンドポイントの変更に対応していません。 S3 ブラウザーは、常にs3.amazonaws.com宛にリクエストの送信を試みます。 S3 ブラウザーを ECS と通信す

るように構成した場合でも、このトークンは URI に含まれ、認証文字列内にエンコードされます。

ベース URL を使用すると、S3 ブラウザーのようなアプリケーションを ViPR Controller とともに使用できます。S3 ブラウザーを機能させるには、ベース URL を s3.amazonaws.comに設定します。

以下の例は、受信する HTTP リクエストを ECS がいくつかの方法で処理する例を示します。

例 1

Host: baseball.image.emc.finance.comBaseURL: finance.comUse BaseURL with namespace enabled

Namespace: emcBucket Name: baseball.image

例 2

Host: baseball.image.emc.finance.comBaseURL: finance.comUse BaseURL without namespace enabled

Namespace: null (Use other methods to determine namespace)



Bucket Name: baseball.image.emc

例 3

Host: baseball.image.emc.finance.comBaseURL: not configured

Namespace: null (Use other methods to determine namespace.)Bucket Name: null (Use other methods to determine the bucket name.)

ViPR Controller treats this request as a path-style request.

ベース URL の追加この操作が必要となるのは、オブジェクトの場所とそのネームスペースおよびバケットをURL 内にエンコードするオブジェクトクライアントを使用する場合のみです。この場合、テナント内のオブジェクトへのパスとして、使用するベース URL を名前空間とともに指定できます。

はじめに

この操作では ECS のシステム管理者の役割が必要です。

URL を使用してオブジェクトの場所を指定するリクエストに指定されたドメインが、ECS データノードの場所を、またはデータノードの直前に配置されたロードバランサーの場所を解決できることを確認する必要があります。

手順

1. ECS ポータルで、［Settings］ > ［Object Base URLs］を選択します。

2. ［New Base URL］を選択します。

［New Base URL］ページが表示されます。

3. ベース URL の名前を入力します。これは、ベース URL テーブルで、ベース URL に関する追加情報として表示されます。


ベース URL の追加 135

4. ベース URL を入力します。

オブジェクトの場所を示す URL が https://mybucket.mynamespace.acme.com（つまり bucket.namespace.baseurl）、または https://mybucket.acme.com（つまり bucket.baseurl）という形式の場合、ベース URL は

acme.com となります。

［Namespace］セレクターでは、使用する形式を指定できます。

5. URL にオブジェクトのアドレスをエンコードする形式として、名前空間を使用するか、または使用しないかを選択します。


ベース URL の例

ベース URL の使用例を示します。「images」バケットに格納され、テナントのネームスペースが「ecsdata」、ベース URL が「s3.amazonaws.com」で、「myphoto.jpg」という名前のオブジェクトは、次の URL によってアドレス指定できます。 https://images.ecsdata.s3.amazonaws.com/myphoto.jpg図 43 ベース URL の例



第 18 章

バケットの作成と構成

l はじめに..............................................................................................................138l バケットの概念と属性.......................................................................................... 138l バケットの ACL.....................................................................................................140l ECS ポータルを使用したバケットの作成............................................................... 142l バケットの編集.................................................................................................... 143l ユーザーのバケット ACL 権限の設定................................................................... 143l 定義済みグループのバケット ACL 権限の設定..................................................... 144l オブジェクト API を使用したバケットの作成...........................................................145l バケットとキーの命名規則................................................................................... 148

バケットの作成と構成 137

はじめにオブジェクトデータを格納するためには、コンテナーが必要です。 S3 では、このようなコンテナーをバケットと呼びます。この用語は、ECS では一般用語として使用されています。Atmos でバケットと同じ意味を持つのは、サブテナントです。Swift でバケットと同じ意味を持つのは、コンテナーです。CAS の場合、バケットは CAS プールです。

ECS では、バケットには S3、Swift、Atmos、CAS のいずれかのタイプが割り当てられます。また、S3、Atmos、Swift のバケットは HDFS をサポートするように構成できます。HDFS アクセス用に構成されたバケットには、それぞれのオブジェクトプロトコルと HDFS プロトコルを使用して読み取りと書き込みが可能です。

オブジェクトプロトコルの API を使用して、それぞれのバケットを作成できます。通常は、該当するプロトコルをサポートするクライアントを使用します。 ECS ポータルと ECS 管理 APIは、S3、HDFS、CAS のバケットを作成する際の追加サポートを提供します。ポータルからバケットを作成できるため、HDFS と CAS 用のバケットの作成が容易になり、クオータや保存期間のような ECS の高度なバケット構成オプションも簡単に活用できます。

オブジェクトプロトコルを使用してバケットを作成する場合は、特殊な x-emc ヘッダーでバケットの構成を制御できます。

本稿では、バケットの作成および編集方法、バケット用 ACL の設定方法、ECS ポータルの使用について説明します。また、サポートされるオブジェクトプロトコルを使用する場合にバケット構成の制御に使用可能な追加の x-emc ヘッダーについても説明します。

これは 2.1 にありました。また、S3、Atmos、Swift のバケットは HDFS をサポートするように構成できます。HDFS アクセス用に構成されたバケットには、それぞれのオブジェクトプロトコルと HDFS プロトコルを使用して読み取りと書き込みが可能です。

以下のユースケースについて説明します。

l ECS ポータルを使用したバケットの作成（142 ページ）

l オブジェクト API を使用したバケットの作成（145 ページ）

バケット構成の編集機能とバケット用 ACL の設定機能については、以下で説明します。

l バケットの編集（143 ページ）

l ユーザーのバケット ACL 権限の設定（143 ページ）

バケットの概念と属性バケットは、オブジェクトのコンテナーです。これを使用して、オブジェクトへのアクセスの制御や、含まれるすべてのオブジェクトの属性を定義するプロパティ（保存期間やクォータなど）の設定ができます。

ネームスペースもグローバルリソースであることから、バケットとネームスペースを使用して、リンクされたどの VDC からもオブジェクトのアドレスを指定できます。

バケットのアクセス

バケットにはレプリケーショングループが関連づけられます。レプリケーショングループは複数の VDC に及び、バケットのコンテンツも同じように複数の VDC でレプリケートされます。たとえば、2 つの VDC（VDC1 と VDC2）にわたるレプリケーショングループに属するバケットのオブジェクトは、VDC1 と VDC2 のどちらからもアクセスが可能です。VDC1 のみに関連づけられたレプリケーショングループに属するバケットのオブジェクトには、VDC1 のみからアクセスでき、連携 ECS システムの他の VDC からはアクセスできません。

バケットとそのメタデータ（ACL など）の ID は ECS のグローバル管理情報であり、システムストレージプール間でレプリケートされて、連携したすべての VDC で認識されます。ただ



し、バケットがリストされるのは、バケットが属するレプリケーショングループに含まれるVDC からのみです。

また、ECS のバケットは常にネームスペースに属します。

バケットの所有権

バケットはネームスペースに属し、オブジェクトユーザーもネームスペースに割り当てられます。各オブジェクトユーザーがバケットを作成できるのは属しているネームスペースに限られますが、どの ECS オブジェクトユーザーもバケットやオブジェクトの所有者またはバケット ACL の権限受領者として割り当てることができます（バケットやオブジェクトと同じネームスペースに属さないユーザーであっても可能）。このため、バケットとオブジェクトは異なるネームスペースのユーザー間で共有が可能です。たとえば、ネームスペースが部門であるエンタープライズ環境で、バケットやオブジェクトを異なる部門のユーザー間で共有できます。

オブジェクトユーザーが、自分の属さないネームスペースのバケットにアクセスしたい場合は、x-emc-namespace ヘッダーを使用してネームスペースを指定する必要があります。

一時的なサイト停止時のバケットへのアクセス

ECS には一時的なサイト停止メカニズムがあり、プライマリコピーをホストするサイトが使用不可でオブジェクトのプライマリコピーを使用できない場合でも、オブジェクトを取得することが可能です。

一時的なサイト停止の間に取得したオブジェクトデータは新でない可能性があるので、ユーザーはこれを承諾するために、バケットが停止時に使用可能であるとマークする必要があります。

バケットの属性

ECS ポータルでは、バケットを作成して、［Manage］ > ［Buckets］ページで管理することができます。

［Bucket Management］ページのバケットテーブルには、選択したネームスペースのバケットが表示されます。テーブルにはバケットの属性が表示され、それぞれのバケットに［EditBucket］、［Edit ACL］、［Delete］のアクションを実行できます。

バケットに関連づけられた属性について、次の表で説明します。［Bucket Management］ページに表示されない属性を表示/変更するには、［Edit Bucket］を選択します。

表 23 バケットの属性

属性説明

Name バケットの名前。バケットの命名ガイダンス：バケットとキーの命名規則

（148 ページ）（参照）。

Created バケットの作成時間。

Replication Group バケットを作成するレプリケーショングループ。


バケットの概念と属性 139

表 23 バケットの属性（続き）

属性説明

Namespace バケットが関連づけられたネームスペース。

Owner バケットの所有者。

Notification Quota これに達すると通知が生成されるクォータ設定。これはソフトクォータで、

単独で設定できます。または、ハードクォータに追加して設定できます。

クォータは 1GB 以上に設定する必要があります。バケットに関連づけられ

たクォータは、その存続期間内に変更が可能です。

クォータの詳細：テナントの管理（84 ページ）（参照）。

Max Quota これに達するとバケットへのアクセスがブロックされるハードクォータ。ハードクォータに達する前にトリガーするソフトクォータを設定できます。

File System Enabled ECS でバケットを HDFS（Hadoop 分散ファイルシステム）として使用できる

ように指定。

これは、バケットの作成時に設定する必要があります。バケットの作成後

は変更できません。

ファイルシステムを有効にしたバケットには、停止時のアクセスは設定で

きません。

CAS バケットで CAS データを使用できるように指定。

Access During Outage バケットに設定するフラグ。地理的に分散して連携している構成で一時的

な使用不可ゾーンが設けられた場合にバケットのデータにアクセスすると

きの動作を指定します。

このフラグがオンの場合は、一時的なサイト停止が発生すると、このバケ

ット内のアクセスしたオブジェクトが障害サイトで更新されても、オブジェク

トにアクセスしているサイトに変更が伝播されていない可能性があります。

このため、ユーザーは読み取ったオブジェクトが新でない可能性がある

ことを承諾する必要があります。

フラグがオフの場合は、一時的に停止したゾーンのデータは他のゾーンか

らアクセスできず、障害サイトにプライマリコピーが置かれたデータのオブ

ジェクトの読み取りは失敗します。

このフラグをオンにできるのは、［File System Enabled］フラグをオンにした

ときだけです。

Bucket Retention バケットの保存期間を設定。保存期間の詳細：テナントの管理（84 ペー

ジ）（参照）。

バケット内のオブジェクトの保存期限は、オブジェクトの変更がリクエストさ

れたときに計算され、バケットとオブジェクト自体に設定された値に基づい

て決まります。

保存期間は、バケットの存続期間内に変更が可能です。

バケットの ACLバケットにアクセスするときのユーザーの特権は、ACL を使用して設定します。



バケットを作成して所有者を割り当てると、ACL が作成されて、バケットの所有者にデフォルトの権限が割り当てられます。所有者には、デフォルトでフルコントロールが割り当てられます。

所有者に割り当てられた権限を変更したり、ユーザーに新しい権限を追加したりするには、バケットの［Edit ACL］を選択します。

ECS ポータルの［Bucket ACLs Management］ページにある［User ACLs］パネルと［GroupACLs］パネルでは、各ユーザーや定義済みのグループに関連づけられた ACL を管理できます。

User ACLs［User ACLs］パネルには、ユーザーに適用されている ACL が表示されます。ユーザーにACL を割り当てるには、［Add］ボタンを使用します。

ACL の項目を次の表に示します。

表 24 バケットの ACL

ACL 権限

Read ユーザーはバケットのオブジェクトをリストできる。

Read ACL ユーザーはバケットの ACL を読み取ることができる。

Write ユーザーはバケットのオブジェクトを作成または更新できる。

Write ACL ユーザーはバケットの ACL に書き込みができる。

Execute ファイルシステムとしてアクセスするときの実行権限を設定する。この権限は、ECSオブジェクトプロトコルを使用してオブジェクトにアクセスするときは機能しません。

Full Control ユーザーに Read、Write、Read ACL、Write ACL を許可する。

PrivilegedWrite

ユーザーに標準の書き込み権限がない場合に、ユーザーにバケットやオブジェクト

への書き込みを許可する。 CAS バケットで必須です。

Delete ユーザーにバケットとオブジェクトの削除を許可する。 CAS バケットで必須です。

None ユーザーはバケットに対する権限を持たない。

ECS ポータルは S3、HDFS、CAS のバケットをサポートするため、設定可能な権限の範囲がすべてのバケットタイプに適用されるとは限りません。


バケットの ACL 141

Group ACLs定義済みのグループに権限を設定できます。次のグループがサポートされます。

public認証されたまたはされていないすべてのユーザー

all users認証されたすべてのユーザー

その他バケット所有者以外の認証されたユーザー

log deliveryサポートなし。

割り当て可能な権限については、表 24 （141 ページ）を参照してください。

ECS ポータルを使用したバケットの作成ECS ポータルでは、バケットを作成したり、バケットの構成を指定したりすることができます。ポータルで作成したバケットは、S3、S3 と HDFS、CAS のいずれかのバケットになります。

はじめに

l ECS ポータルでバケットを作成するには、ネームスペース管理者またはシステム管理者である必要があります。

l ネームスペース管理者は、自分のネームスペースのバケットを作成できます。

l システム管理者は、どのネームスペースに属するバケットでも作成できます。

手順

1. ECS ポータルで、［Manage］ > ［Buckets］を選択します。

2. ［New Bucket］を選択します。

3. バケットが関連づけられたレプリケーショングループを選択します。

4. バケットとそのオブジェクトを所属させるネームスペースを選択します。

システム管理者は、ECS システムにネームスペースが複数ある場合、バケットを所属させるネームスペースを選択します。

ネームスペース管理者は、自分のネームスペースのみを選択できます。

5. バケットの所有者を指定します。

バケットの所有者は、ネームスペースの ECS オブジェクトユーザーでなければなりません。ユーザーを指定しなかった場合は、この操作を実行しているユーザーが所有者として割り当てられます。ただし、そのユーザー名がオブジェクトユーザーにも割り当てられるまでは、バケットにアクセスできません。

指定したユーザーには、フルコントロール権限が付与されます。

6. バケットを CAS バケットにする場合は、［CAS］コントロールを［ON］に設定します。

デフォルトでは、バケットは S3 バケットとしてマークされます。

7. バケットで HDFS 操作をサポートするには、［File System Enabled］コントロールを［ON］に設定します。

バケットは HDFS をサポートする S3 バケットになります。

8. バケットが CAS バケットまたは S3 バケットであり、それに対して［File System Enabled］を設定していない場合は、［Access During Outage］を［ON］に設定できます。



9. 必要に応じて、バケットのクォータを指定します。

適用可能な設定の詳細：バケットの概念と属性（138 ページ）.

10.必要に応じて、バケットの保存期間を設定します。

保存期間の詳細：バケットの概念と属性（138 ページ）.

11.［Save］を選択してバケットを作成します。

結果

バケットテーブルの［Actions］メニューから、バケットにユーザーを割り当て、ユーザー（または事前定義済みのグループ）の権限を設定できます。

バケットの編集バケットを作成した後や、オブジェクトを書き込んだ後で、バケットのいくつかの設定を編集できます。

はじめに

l バケットを編集するには、ネームスペース管理者またはシステム管理者である必要があります。

l ネームスペース管理者は、自分のネームスペースに属するバケットの設定を編集できます。

l システム管理者は、どのネームスペースに属するバケットでも設定を編集できます。

手順


2. バケットテーブルで、設定を変更するバケットの［Edit］アクションを選択します。

3. 次のバケット属性を編集できます。

l クォータ

l バケットの所有者

l Access During Outage

バケットの［File System Enabled］がオンに設定されている場合は編集できません。

次のバケット属性は変更できません。

l レプリケーショングループ

l File Access Enabled

l CAS enabled

これらの設定の詳細：バケットの概念と属性（138 ページ）（参照）。


ユーザーのバケット ACL 権限の設定ECS ポータルでは、ユーザーまたはあらかじめ定義されたグループにバケットの ACL を設定できます。


バケットの編集 143

はじめに

l バケットの ACL を編集するには、ネームスペース管理者またはシステム管理者である必要があります。

l ネームスペース管理者は、自分のネームスペースに属するバケットの ACL 設定を編集できます。

l システム管理者は、どのネームスペースに属するバケットでも ACL 設定を編集できます。

手順


2. バケットテーブルで、設定を変更するバケットの［Edit ACL］アクションを選択します。

3. ユーザーの ACL 権限を設定するには、［User ACLs］ボタンを選択します。

グループの ACL を選ぶには、［Group ACLs］を選択します。グループ ACL の設定については、定義済みグループのバケット ACL 権限の設定（144 ページ）を参照してください。

4. 権限が割り当て済みのユーザーの権限を編集したり、権限を割り当てたいユーザーを追加したりすることができます。

l 権限が割り当て済みのユーザーの ACL 権限を設定（または削除）するには、ACL テーブルの［Action ］列で［Edit］（または［Remove］）を選択します。

l 権限を割り当てたいユーザーを追加するには、［Add］を選択します。

バケットの所有者として設定したユーザーには、デフォルトの権限が割り当てられています。

5. ACL を追加した場合は、権限を適用するユーザーのユーザー名を入力します。

6. ユーザーに適用する権限を指定します。

ACL 権限の詳細については、バケットの概念と属性（138 ページ）を参照してください。


定義済みグループのバケット ACL 権限の設定ECS ポータルでは、ユーザーまたはあらかじめ定義されたグループにバケットの ACL を設定できます。

はじめに

l バケットのグループ ACL を編集するには、ネームスペース管理者またはシステム管理者である必要があります。

l ネームスペース管理者は、自分のネームスペースに属するバケットのグループ ACL 設定を編集できます。

l システム管理者は、どのネームスペースに属するバケットでもグループ ACL 設定を編集できます。

手順


2. バケットテーブルで、設定を変更するバケットの［Edit ACL］アクションを選択します。

3. グループの ACL 権限を設定するには、［Group ACLs］ボタンを選択します。

ユーザーの ACL を選ぶには、［User ACLs］を選択します。ユーザー ACL の設定については、ユーザーのバケット ACL 権限の設定（143 ページ）を参照してください。



4. ACL 権限を割り当てるグループを選択します。

定義済み権限の詳細：バケットの概念と属性（138 ページ）

5. グループに割り当てる権限を選択します。


オブジェクト API を使用したバケットの作成オブジェクト API またはオブジェクト API を呼び出すツールを使用してバケットを作成する場合、動作を指定するヘッダーが多数存在します。

以下の x-emcヘッダーが提供されます。

x-emc-dataservice-vpoolこのバケットに関連づけられたオブジェクトの格納に使用されるレプリケーショングループを指定します。 x-emc-dataservice-vpoolヘッダーでレプリケーショングル

ープを指定しなかった場合は、ECS はネームスペースに関連づけられたデフォルトのレプリケーショングループを選択します。

x-emc-file-system-access-enabledHDFS アクセス用にバケットを構成します。ヘッダーは、使用中のインターフェイスと競合してはいけません。つまり、HDFS からのバケット作成リクエストでは、x-emc-file-system-access-enabled=false を指定できません。

x-emc-namespaceこのバケットで使用されるネームスペースを指定します。ネームスペースがホスト/パス形式リクエストの S3 規則を使用して指定されていない場合、x-emc-namespaceヘッダーを使用して指定できます。ネームスペースがこのヘッダーとして指定されていない場合、ユーザーと関連づけられているネームスペースが使用されます。

x-emc-retention-periodバケット内のオブジェクトに適用される保存期間を指定します。バケット内のオブジェクトを変更するリクエストが作成されるたびに、バケットに関連づけられた保存期間に基づいてオブジェクトの保存期間の有効期限が計算されます。

x-emc-is-stale-enabled連携型構成で VDC の一時停止中にバケットにアクセス可能かどうかを示すフラグです。

x-emc-project-id新しいバケットに関連づけるプロジェクト ID を指定します。これは、オブジェクト使用率の測定データをレポートする際に役立ちます。このヘッダーが存在しない場合、関連づけられたテナントに定義されているデフォルトプロジェクト ID が使用されます。

S3curl ツールを使用してバケットを作成する例を以下で確認できます。

l S3 API を使用したバケットの作成（s3curl 使用）（145 ページ）

S3 API を使用したバケットの作成（s3curl 使用）

S3 API を使用して、レプリケーショングループにバケットを作成できます。 ECS はカスタムヘッダー（x-emc）を使用するため、署名する文字列はこれらのヘッダーを含むように構成する必要があります。この手順では s3curl ツールを使用していますが、使用可能なプログラムクライアントは多数存在します（S3 Java クライアントなど）。

はじめに

l ECS に構成済みのレプリケーショングループが 1 つ以上必要です。

l s3curl を実行する Linux マシン上に、Perl がインストールされている必要があります。


オブジェクト API を使用したバケットの作成 145

l curl のインストールおよび s3curl モジュール（curl のラッパーとして動作します）が必要になります。

s3curl を x-emc ヘッダーと使用するには、s3curlスクリプトに小さな変更を加える必要が

あります。これらの変更は手順内で説明されています。

手順

1. バケットを作成するユーザー用の秘密キーを取得します。

詳細については、オブジェクトストレージアクセス用の秘密キーの取得（152 ページ）を参照してください。

2. 作成するバケットが属するレプリケーショングループの ID を取得します。

レプリケーショングループの ID を取得するには、次のように ECS REST API を使用します。

GET https://<ECS IP Address>:4443/vdc/data-service/vpools

レスポンスで、すべてのデータサービス仮想プールの名前と ID を確認できます。次に例を挙げます。

<data_service_vpools><data_service_vpool> <creation_time>1403519186936</creation_time> <id>urn:storageos:ReplicationGroupInfo:8fc8e19b-edf0-4e81-bee8-79accc867f64:global</id> <inactive>false</inactive> <tags/> <description>IsilonVPool1</description> <name>IsilonVPool1</name> <varrayMappings> <name>urn:storageos:VirtualDataCenter:1de0bbc2-907c-4ede-b133-f5331e03e6fa:vdc1</name> <value>urn:storageos:VirtualArray:793757ab-ad51-4038-b80a-682e124eb25e:vdc1</value> </varrayMappings></data_service_vpool></data_service_vpools>

この例では、ID は urn:storageos:ReplicationGroupInfo:8fc8e19b-edf0-4e81-bee8-79accc867f64:globalです。

3. ユーザー認証情報を入力する.s3curl ファイルを作成して、s3curlを設定します。

s3curl.plを実行する際に、.s3curl ファイルは 0600（rw-/---/---）の権限を持って

いる必要があります。

以下の例では、プロファイル「my_profile」を使用して「[email protected]」アカウントのユーザー認証情報を参照し、「root_profile」でルートアカウントの認証情報を参照します。

%awsSecretAccessKeys = ( my_profile => { id => '[email protected]', key => 'sZRCTZyk93IWukHEGQ3evPJEvPUq4ASL8Nre0awN' }, root_profile => { id => 'root', key => 'sZRCTZyk93IWukHEGQ3evPJEvPUq4ASL8Nre0awN'



},);

4. s3curlを使用するエンドポイントを、.s3curl ファイルに追加します。

これは、データノードまたはデータノードの前に位置するロードバランサーのアドレスです。

次に例を挙げます。

push @endpoints , ( '203.0.113.10', 'lglw3183.lss.emc.com',);

5. s3curl.plスクリプトを変更して、「署名する文字列」に x-emc ヘッダーが含まれるよう

にします。

以下の行が変更の対象です。

elsif ($header =~ /^(?'header'[Xx]-(([Aa][Mm][Zz])|([Ee][Mm][Cc]))-[^:]+): *(?'val'.+)$/) {

my $name = lc $+{header}; my $value = $+{val};

以下で置き換えます。

elsif ($header =~ /^([Xx]-(?:(?:[Aa][Mm][Zz])|(?:[Ee][Mm][Cc]))-[^:]+): *(.+)$/) { my $name = lc $1; my $value = $2;

6. s3curl.plを使用してバケットを作成します。

次の項目を指定します。

l ユーザーのプロファイル。

l 作成するバケットが属するレプリケーショングループの ID（<vpool_id>）。これは、x-emc-dataservice-vpoolヘッダーを使用して設定する必要があります。

l x-emc-file-system-access-enabled ヘッダー。ファイルシステムアクセス

を可能します。

l バケットの名前（<BucketName>）。

すべて指定したコマンドは次のようになります。

./s3curl.pl --debug --id=my_profile --acl public-read-write --createBucket -- -H 'x-emc-file-system-access-enabled:true' -H 'x-emc-dataservice-vpool:<vpool_id>' http://<DataNodeIP>:9020/<BucketName>

［-acl public-read-write］引数はオプションですが、匿名環境でバケットにアク

セスする予定の場合は必須になるため注意してください。たとえば、Kerberos を使用し


S3 API を使用したバケットの作成（s3curl 使用） 147

て保護されていない環境から、HDFS としてバケットにアクセスする予定がある場合です。

（--debug がオンで）成功すると、次のような出力が表示されます。

s3curl: Found the url: host=203.0.113.10; port=9020; uri=/S3B4; query=;s3curl: ordinary endpoint signing cases3curl: StringToSign='PUT\n\n\nThu, 12 Dec 2013 07:58:39 +0000\nx-amz-acl:public-read-write\nx-emc-file-system-access-enabled:true\nx-emc-dataservice-vpool:urn:storageos:ReplicationGroupInfo:8fc8e19b-edf0-4e81-bee8-79accc867f64:global:\n/S3B4's3curl: exec curl -H Date: Thu, 12 Dec 2013 07:58:39 +0000 -H Authorization: AWS root:AiTcfMDhsi6iSq2rIbHEZon0WNo= -H x-amz-acl: public-read-write -L -H content-type: --data-binary -X PUT -H x-emc-file-system-access-enabled:true -H x-emc-dataservice-vpool:urn:storageos:ObjectStore:e0506a04-340b-4e78-a694-4c389ce14dc8: http://203.0.113.10:9020/S3B4

以下を使用して、S3 インターフェイスでバケットをリストできます。

./s3curl.pl --debug --id=my_profile http://<DataNodeIP>:9020/

バケットとキーの命名規則バケットとオブジェクト/キーの名前は、ここに示した仕様に従う必要があります。

l ECS の S3 バケットおよびオブジェクトの名前　（148 ページ）

l ECS の OpenStack Swift コンテナーおよびオブジェクトの名前　（149 ページ）

l ECS の Atmos バケットおよびオブジェクトの名前　（149 ページ）

l ECS の CAS プールおよびオブジェクトの名前　（150 ページ）

バケットを HDFS に使用する場合は、URI Java クラスでサポートされないアンダースコアをバケット名に使用しないでください。たとえば、viprfs://my_bucket.ns.site/は無効

な URI であり、Hadoop に認識されないため動作しません。

ネームスペース名

ECS ネームスペース名には、次のルールが適用されます。

l null または空の文字列にはできない

l 長さは 1～255 文字（Unicode 文字）

l 有効な文字は正規表現/[a-zA-Z0-9-_]+/の定義による。これは次のとおりです。

n 英数字

n 必要な特殊文字の数: ハイフン（-）およびアンダースコア（_）

ECS の S3 バケットおよびオブジェクトの名前　

このトピックでは、ECS S3 オブジェクト API を使用するときのバケットとオブジェクトの名前に適用されるルールを説明します。



バケット名

ECS の S3 バケット名には、次のルールが適用されます。

l 名前の長さは、1～255 文字にする必要があります（S3 では、バケット名は 1～255 文字の長さでなければなりません）。

l 名前に含めることができるのは、ドット（.）、ハイフン（-）、アンダースコア（_）、英数字（a～z、A～Z、0～9）です。

l 名前の先頭の文字は、ハイフン（-）または英数字にします。

l 次の名前はサポートされません。

n 先頭がドット（.）

n 二重のドット（..）を含む

n 末尾がドット（.）

n IPv4 アドレス形式

これらを S3 仕様の命名規則と比較できます。 http://docs.aws.amazon.com/AmazonS3/latest/dev/BucketRestrictions.html

オブジェクト名

ECS S3 オブジェクト名には、次のルールが適用されます。



l 文字の検証はなし

ECS の OpenStack Swift コンテナーおよびオブジェクトの名前　

このトピックでは、ECS OpenStack Swift オブジェクト API を使用するときのバケットとオブジェクトの名前に適用されるルールを説明します。

コンテナー名

Swift コンテナー名には、次のルールが適用されます。



l 有効な文字は正規表現/[a-zA-Z0-9\\.\\-_]+/の定義による

n 英数字

n 必要な特殊文字の数: ドット（.）、ハイフン（-）、アンダースコア（_）


Swift オブジェクト名には、次のルールが適用されます。




ECS の Atmos バケットおよびオブジェクトの名前　

このトピックでは、ECS Atmos オブジェクト API を使用するときのバケットとオブジェクトの名前に適用されるルールを説明します。

サブテナント（バケット）

これはサーバーによって作成されるため、クライアントは命名スキームを知る必要はありません。


ECS の OpenStack Swift コンテナーおよびオブジェクトの名前　 149

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

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


Atmos オブジェクト名には、次のルールが適用されます。




名前は、パーセントエンコードの UTF-8 にする必要があります。

ECS の CAS プールおよびオブジェクトの名前　

このトピックでは、CAS API を使用するときに CAS プールおよびオブジェクト（CAS 用語では「クリップ」）の名前に適用されるルールを説明します。

CAS プール名

ECS の CAS プール名には、次のルールが適用されます。

l 大で 255 文字

l 次の文字は使用不可： ' " / & ? * < > <タブ> <改行> <スペース>

クリップ名

CAS API にはユーザー定義のキーはありません。 CAS API を使用するアプリケーションは、クリップを作成するときに、プールを開き、新しいクリップを作成し、タグ、属性、ストリームなどを追加します。クリップが完成すると、デバイスに書き込まれます。

対応するクリップ ID が CAS エンジンによって返され、<プール名>/<クリップ ID>を使用して参照できるようになります。



第 19 章

オブジェクトストレージアクセス用の秘密キーの取得

l 概要....................................................................................................................152l オブジェクトユーザーのキーの作成.....................................................................152l S3 秘密キーの作成：セルフサービス..................................................................153

オブジェクトストレージアクセス用の秘密キーの取得 151

概要ECS オブジェクトサービスのユーザーには、サービスで認証するための秘密キーが必要です。

秘密キーは、次の方法で作成してオブジェクトユーザーが使用できるようにします。

l 管理者が、キーを作成してオブジェクトユーザーに配信します（オブジェクトユーザーのキーの作成（152 ページ）を参照）。

l ドメインユーザーであるオブジェクトユーザーが、ECS 管理 REST API によって提供されるセルフサービス API を使用して新しいキーを作成します（S3 秘密キーの作成：セルフサービス（153 ページ）を参照）。

オブジェクトユーザーのキーの作成ECS 管理ユーザーは、オブジェクトユーザーの秘密キーを作成できます。

l ECS ポータルからの秘密キーの作成（152 ページ）

l ECS 管理 REST API を使用した S3 秘密キーの作成（152 ページ）

ECS ポータルからの秘密キーの作成

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

はじめに

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

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

手順

1. ECS ポータルで、［Manage］ > ［Users］ページを選択します。

2. ［Object Users］テーブルで、秘密キーを割り当てるユーザーの［Edit］を選択します。

3. S3 の場合は、［Generate & Add Password］を選択します。

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

ECS 管理 REST API を使用した S3 秘密キーの作成

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

API は次のとおりです。

API パス説明

/object/user-secret-keys/{uid}

オブジェクトユーザーへの秘密キーの割り当てと秘密キーの管理を行うための

API。

ネームスペース管理者は、自分のネームスペース内のユーザーのキーを作成

できます。システム管理者は、どのネームスペースのユーザーにもキーを割り

当てることができます。



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

S3 秘密キーの作成：セルフサービスECS 管理 REST API により、認証されたドメインユーザーはオブジェクトストアにアクセスするための秘密キーをリクエストすることが可能です。

ECS 管理 REST 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/>

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

セルフサービスキーの操作

ECS 管理 REST API リファレンスを参照して、セルフサービス秘密キーで実行できるいくつかの操作があります。

紹介する例では、curlツールを使用して次の操作を行っています。

l ドメインユーザーとしてのログイン（154 ページ）

l 初のキーの生成（154 ページ）

l 2 番目のキーの生成（154 ページ）

l キーの確認（155 ページ）

l すべての秘密キーの削除（155 ページ）


S3 秘密キーの作成：セルフサービス 153



ドメインユーザーとしてのログイン

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

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>

ユーザーの詳細の確認

ユーザーの詳細を確認できます。このケースでは、ユーザーはネームスペース「ns1」に属している NAMESPACE_ADMIN です。

curl -ks -H "X-SDS-AUTH-TOKEN: BAAcaVAzNU16eVcwM09rOWd2Y1ZoUFZ4QmRTK2JVPQMAQQIADTE0MzAwNzQ4ODA1NTQDAC51cm46VG9rZW46YWJmODA1NTEtYmFkNC00ZDA2LWFmMmMtMTQ1YzRjOTdlNGQ0AgAC0A8=" https://10.241.48.31:4443/user/whoami | xmllint --format -<?xml version="1.0" encoding="UTF-8" standalone="yes"?><user> <common_name>[email protected]</common_name> <distinguished_name/> <namespace>ns1</namespace> <roles> <role>NAMESPACE_ADMIN</role> </roles></user>

初のキーの生成

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

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]"/> <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: BAAcaVAzNU16eVcwM09rOWd2Y1ZoUFZ4QmRTK2JVPQMAQQIADTE0MzAwNzQ4ODA1NTQDAC51cm46VG9rZW46YWJmODA1NTEtYmFkNC00ZDA2LWFmMmMtMTQ1YzRjOTd



lNGQ0AgAC0A8=" -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


セルフサービスキーの操作 155

第 20 章

ECS ポータルを使用した CAS SDK アプリケーションサポートの構成

l ECS での CAS サポートの設定............................................................................. 158l での CAS の保存 ECS への保存...........................................................................158l ネームスペースの保存ポリシーの設定................................................................ 160l CAS のバケットの設定......................................................................................... 161l CAS オブジェクトユーザーの設定........................................................................ 161l ユーザーのバケット ACL の設定...........................................................................162l ECS CAS ユーザーをサポートする REST API..........................................................165

ECS ポータルを使用した CAS SDK アプリケーションサポートの構成 157

ECS での CAS サポートの設定ECS での CAS（コンテンツアドレスストレージ）のサポートについて説明します。

ECS CAS により、CAS SDK ベースのクライアントアプリケーションを使用して ECS ストレージのフィックスコンテンツオブジェクトを格納、取得、削除できます。

基盤となる ECS ストレージは、ECS 設定を構成する前にプロビジョニングする必要があります。プロビジョニングは、通常、新しい ECS ラックの設置時に完了させます。これには、ストレージプール、VDC、レプリケーショングループの設定が含まれます。 ECS CAS では、オブジェクトに CAS 固有の機能は存在しないため、CAS をサポートするオブジェクトの作成や編集が必要になった場合は、標準的な説明を参照できます。ストレージプール、VDC、レプリケーショングループの構成（48 ページ）

次に、以下の標準的な説明を参照して、ネームスペース、ユーザー、バケットを設定します。

l テナントのネームスペースの構成（76 ページ）

l ユーザーの追加と役割の割り当て（56 ページ）

l バケットの作成と構成（138 ページ）

以下では、CAS をサポートする基本構成の変更方法について説明しています。

l ECS での CAS の保存（158 ページ）

l ネームスペースの保存ポリシーの設定（160 ページ）

l CAS のバケットの設定（161 ページ）

l CAS オブジェクトユーザーの設定（161 ページ）

l ユーザーのバケット ACL の設定（162 ページ）

l CAS ユーザーをサポートする ECS REST API（165 ページ）

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

保存期間

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

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

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

保存ポリシーを設定すれば、保存用途を取り入れて C-Clip に適用できます。たとえば、ドキュメントのタイプごとに異なる保存期間を割り当てることができます。必要な保存期間は、次のとおりです。

l 財務： 3 年

l 法務： 5 年

l メール： 6 か月間

保存ポリシーが複数の C-Clip に適用されている場合は、ポリシーを変更すると、ポリシーが適用されているすべてのオブジェクトの保存期間が変更されます。



保存ポリシーは、ECS のネームスペースに関連づけられ、CAS アプリケーションによって保存クラスとして認識されます。

バケットレベルの保存は CAS には非推奨

ECS では、すべてのオブジェクトサービスをバケットレベルで保存できます。バケットレベルの保存はすべての CAS オブジェクトレベル保存を上書きするため、外部の CAS アプリケーションの干渉が生じる可能性があります。

CAS の優先順位

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

CAS 保存期間の適用方法

ECS ポータルのネームスペースに、または ECS REST API を使用して、保存ポリシー（保存クラス）を定義できます。ネームスペースの保存ポリシーの設定（160 ページ）を参照してください。

外部の CAS アプリケーションで、C-Clip の作成時に一定の保存期間や保存クラスを C-Clipに割り当てることができます。

API を使用して保存期間を適用する場合は、期間を秒単位で指定します。

ECS CAS では、保存に関連するすべての計算に C-Clip の作成時間が含まれ、移行時間は含まれません。

ECS REST API を使用した保存ポリシーの作成方法

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

表 25 ECS 保存に使用する REST 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

ネームスペースに定義されている保存クラスを

返します。


での CAS の保存 ECS への保存 159

REST API の詳細については、 ECS 管理 REST API の使用（252 ページ）を参照してください。を参照してください。オンラインのリファレンスは、 ECS 管理 REST API リファレンスをご覧ください。。

ネームスペースの保存ポリシーの設定ネームスペースの保存ポリシーの CAS 固有設定手順について説明します。

ネームスペースの保存ポリシー機能では、ネームスペースに作成されたすべての C-Clip のCAS 保存クラスを定義および管理できます。

ネームスペースに複数の保存ポリシーを設定し、各ポリシーで保存期間を定義することができます。 API を使用して複数の C-Clip に同一の保存ポリシーを適用すれば、保存ポリシーを変更することで、そのポリシーに関連づけられているすべてのオブジェクトの保存期間を変更できます。 CAS では、アプリケーションによってオブジェクトの C-Clip に保存クラスが適用されます。オブジェクトの保存期間中は、そのオブジェクトを変更することはできません。

手順


2. 既存のネームスペースの構成を編集するには、そのネームスペースに関連づけられた［Edit］アクションを選択します。

3. 保存ポリシーを追加して構成します。

a. ［Retention Policies］エリアで、［Add］を選択して新しいポリシーを追加します。

b. ポリシーの名前を入力します。

c. 保存ポリシーの期間を指定します。

［Infinite］チェックボックスをオンにして、このポリシーが設定されているオブジェクトが削除されないようにします。

図 44 新しい保存ポリシー





図 45 ネームスペースの保存ポリシー

CAS のバケットの設定CAS をサポートするバケットを設定します。

バケットレベルの保存ポリシーは、CAS には推奨されません。

手順

1. ECS ポータルで、［Manage］ > ［Bucket］を選択します。

2. 既存のバケットの構成を編集するには、そのバケットに関連づけられた［Edit Bucket］アクションを選択します。

3. ［CAS On］コントロールを選択して、バケットの CAS を有効化します。


CAS オブジェクトユーザーの設定CAS を使用するオブジェクトユーザーを設定します。

オブジェクトユーザーの設定時には、CAS プロファイルの構成要素となるプロファイルにCAS 機能を割り当てることができます。その後、CAS アプリケーションで使用する PEA ファイルを表示できます。

手順


2. 既存のオブジェクトユーザーの構成を編集するには、そのユーザーに関連づけられた［Edit］アクションを選択します。


CAS のバケットの設定 161

図 46 オブジェクトユーザーの CAS 設定

3. CAS エリアで、パスワード（シークレット）を入力するか、［Generate］を選択してポータルでパスワードを作成します。

4. ［Set Password］を選択します。

5. ［Generate PEA File］を選択して、ECS の CAS ストレージへの認証時にアプリケーションに必要な PEA ファイルを生成します。

6. デフォルトバケットを設定すると、バケットを指定しないすべてのユーザーアクションでこのデフォルトバケットが使用されます。デフォルトバケットの名前を入力し、［SetBucket］を選択します。

7. ［Add Attribute］を選択して、ユーザーにメタデータタグを追加します。

8. メタデータタグの名前と値を追加します。

メタデータタグの詳細については、CAS SDK のマニュアルを参照してください。

9. ［Save Metadata］を選択します。

ユーザーのバケット ACL の設定バケットの ACL（アクセス制御リスト）を編集して、ユーザーのアクセスを制限します。

CAS ユーザーのバケット ACL を編集します。 ECS バケット ACL は、CAS 権限にマップされているものもあれば、CAS データにとって無意味なものもあります。

手順

1. ECS ポータルで、［Manage］ > ［Bucket］を選択します。

2. 既存のバケットの ACL を編集するには、そのバケットに関連づけられた［Edit ACL］アクションを選択します。



図 47 バケット ACL の編集

3. ユーザーに関連づけられた［Edit］を選択します。

図 48 ［Bucket ACLs Management］

4. 権限を変更します。


ユーザーのバケット ACL の設定 163

表 26 バケットの ACL

CAS SDK 機能 ECS ACL ACL の定義

Read 読み取りユーザーがバケット内

の C-Clip を開くことが

できる。

Write 書き込みユーザーがバケット内

に C-Clip を作成でき

る。

Exist 読み取りユーザーがバケット内

の C-Clip を開くことが

できる。

Delete 削除ユーザーがバケットか

ら C-Clip を削除できる

Privileged Delete 権限付き書き込みユーザーが C-Clip の

権限付き削除を実行で

きる。権限付き削除で

は、ユーザーが保存期

間中の C-Clip を削除で

きます。

Clip-Enumeration 現在サポートなし ECS

Retention Period 現在サポートなし ECSでサポートされていま

せん

Centera *のみ LitHold（法的証拠保全）をサポ

ート

その他の ECS ACL は、CAS にとって意味がありません。


6. ACL をグループレベルでも編集できます。グループは事前定義されており、グループメンバーシップはユーザーの基準に基づいて自動的に設定されます。［Group ACLs］を選択します。

7. ［Add］を選択します。

8. 編集するグループを［Group Name］リストから選択します。

表 27 バケット ACL グループ

バケット ACL グループ説明

public 認証された/認証されていないすべてのユーザー

all users 認証されたすべてのユーザー



表 27 バケット ACL グループ（続き）

バケット ACL グループ説明

other バケット所有者以外の認証されたユーザー

log delivery サポートなし。

9. ACL を編集し、［Save］を選択します。

ECS CAS ユーザーをサポートする REST APICAS ユーザーおよびプロファイル設定の管理に使用できる ECS REST API リソースについて説明します。

ECS 管理 REST API には、ユーザーの CAS 固有データを管理するためのリソースが含まれます。

REST 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 ユーザーメタデータを取得する。

詳細については、ECS 管理 REST API リファレンスを参照してください。


ECS CAS ユーザーをサポートする REST API 165


第 7 部

ECS HDFS の構成

第 21 章, "HDFS の概要"

第 22 章, "安全ではない Hadoop クラスター内の HDFS の構成"

第 23 章, "安全な Hadoop クラスター内の HDFS の構成"

第 24 章, "ECS HDFS 構成のトラブルシューティング"

第 25 章, "ECS HDFS コアサイトプロパティリファレンス"

ECS HDFS の構成 167

ECS HDFS の構成


第 21 章

HDFS の概要

l ECS HDFS とは.....................................................................................................170

HDFS の概要 169

ECS HDFS とはECS HDFS は、HCFS（Hadoop 互換ファイルシステム）であり、Hadoop 2.0 アプリケーションを ECS ストレージインフラストラクチャ上で実行できるようにするものです。

Hadoop ディストリビューションを構成して、組み込み型 Hadoop ファイルシステムや ECSHDFS に対して、また HDFS、ECS HDFS、使用する環境で利用可能なその他の Hadoop 互換ファイルシステムの任意の組み合わせに対して実行することができます。次の図は、ECS HDFS と既存の Hadoop クラスターがどのように統合されるかを示しています。

図 49 ECS HDFS と Hadoop クラスターの統合

Hadoop Cluster

Job TrackerHadoop Client

ViPRFS JAR

Task Tracker

MapReduce Task

Appliance Commodity

MapReduce Request

ViPRFS JAR

Task Tracker

MapReduce Task

ViPRFS JAR

Task Tracker

MapReduce Task

ECS data nodes

ECS data nodes

ECS data nodes

Hadoop 環境で ECS HDFS を使用するように構成すると、個々の ECS HDFS データノードが、従来の Hadoop NameNode と同様に機能します。つまり、すべての ECS HDFS データノードは、HDFS リクエストを受け入れてサービスを提供する機能を持ちます。

Hadoop クライアントで従来の HDFS ではなく ECS HDFS を使用するように構成した場合は、すべての HDFS アクティビティの実行先として、ECS HDFS がポイントされます。各 ECS HDFSクライアントノード上では、従来のすべての Hadoop コンポーネントは ECS HDFS クライアント（JAR）を使用して HDFS アクティビティを実行します。

ECS HDFS を既存の Hadoop 環境に統合するには、以下の準備が必要です。

HDFS の概要


l Hadoop クラスターがインストールおよび構成済みであること。サポートされるディストリビューションを次の表に示します。

サポートされる Hadoop ディストリビューション

Pivotal 2.1

Cloudera 5.0、Cloudera 5.1.3

Hortonworks 2.0

l Hadoop がインストール済みであり、ECS HDFS をサポートするように構成されていること。以下が必要です。

n ECS 非構造化データ用ライセンス（オブジェクト/HDFS アクセスメソッド付き）。

n ECS レプリケーショングループ。

n HDFS アクセスをサポートする 1 つ以上のバケット。

ECS HDFS を使用するための Hadoop の構成

Hadoop では、core-site.xml と呼ばれるファイルにシステム構成情報が格納されま

す。core-site.xmlの編集は、ECS HDFS 構成では必須です。

core-site.xmlで追加または変更するプロパティには、以下のような複数のタイプがあ

ります。

l ECS HDFS Java クラス：この一連のプロパティでは、ECS HDFS クライアント JAR に含まれる ECS HDFS の実装クラスを定義します。これらのクラスは必須です。

l ファイルシステムのロケーションプロパティ：これらのプロパティは、Hadoop ジョブの実行時に使用するファイルシステム URI（スキームと権限）と、特定の ECS ファイルシステムの ECS データノードの IP アドレスを定義します。

l ID 変換プロパティ：これらのプロパティにより、匿名で所有されているオブジェクトをユーザーにマップし、ユーザーレルムを指定することができます。

l Kerberos レルムとサービスプリンシパルのプロパティ：これらのプロパティは、Kerberos が存在する Hadoop 環境での実行時にのみ必要です。これらのプロパティは、Hadoop ユーザーと ECS HDFS ユーザーをマップします。

core-site.xml Hadoop クラスター内の各ノードに存在します。 core-site.xmlの各

インスタンスに同じプロパティを追加する必要があります。

このような変更をクラスター全体で保持するには、Cloudera ディストリビューションではCloudera Safety Valve を使用し、Hortonworks では Hortonworks Ambari を使用することを推奨します。

ECS HDFS URI：ファイルシステムアクセス用

ECS ファイルシステムを使用するように Hadoop を構成したら、ECS HDFS URI を使用してファイルシステムにアクセスできます。viprfs://に、スキームと権限（ECS バケット、テナン

トネームスペース、ユーザー定義のインストール名の組み合わせ）を指定します。

ECS HDFS URI は次のようになります。

viprfs://［bucket_name］.［namespace］.［installation］/path

HDFS の概要

ECS HDFS を使用するための Hadoop の構成 171

［bucket_name］は、HDFS 対応バケットに対応します。これには、Hadoop を使用して分析するデータが含まれます。［namespace］は、テナントネームスペースに対応します。［installation_name］は、特定の ECS ノードセットまたは 1 つのロードバランサーに割り当てる名前です。 ECS HDFS は、［installation_name］を ECS ノードセットまたは 1 つのロードバランサーに解決します。その場合に、fs.vipr.installation.［installation_name］.hosts プロパティを使用します。このプロパティには、ECS ノードまたはロードバランサーの IP アドレスが含まれます。

installation_name が ECSECS ノードセットにマップされている場合は、ECS でアクティブノードのリストのクエリーを実行する頻度を指定できます。そのためには、fs.vipr.installation.［installation_name］.resolution を dynamic に設定し、fs.vipr.installation.［installation_name］.resolution.dynamic.time_to_live_ms に ECS でのアクティブノードリストのクエリー頻度を指定します。

シンプルなセキュリティを使用する Hadoop 環境では、ECS HDFS URI を fs.defaultFS プロパティの値として設定することで core-site.xml内のデフォルトのファイルシステムとして

指定することができますが、これは必須ではありません。 Kerberos で保護された Hadoop環境では、ECS HDFS をデフォルトのファイルシステムとして設定することはできません。この値を ECS HDFS に設定するかどうかは、ECS HDFS の統合計画において、Hadoop 全体の一部として慎重に検討する必要があります。 ECS HDFS がデフォルトのファイルシステムでない場合は、ECS データにアクセスするときに毎回、パスを含む完全な URI を使用する必要があります。異なるデフォルトのファイルシステムを使用している既存アプリケーションがすでに存在する場合は、それらのアプリケーションを更新する必要があります。

Hadoop 認証モード

ECS HDFS は、単純認証モードまたは Kerberos 認証モードを使用するように構成されたHadoop クラスターと統合されます。各モードを処理するには、ユーザーとサービスがそれぞれ必要なデータにアクセスできるように、core-site.xmlで適切なプロパティを設定す

る必要があります。

Hadoop アプリケーションは、ECS バケットに格納されたデータにアクセスします。したがって、Hadoop ユーザーには読み取ろうとするオブジェクトに対する読み取り権限と書き込もうとするバケットに対する書き込み権限が必要です。 Hadoop サービス（mapred、hive、hbase など）には、システムファイルへの書き込み権限が必要です。

表 28 Hadoop 認証モードのサマリー

認証モード Hadoop ユーザー ECS ユーザーバケットの権限

単純認証 UNIX ユーザーはユーザーまたはサー

ビスとなります。以下に、いくつか例を

示します。

l root

l sally

l cloudera

l mapred

匿名すべてのユーザ

ーにフルコントロ

ールが必要

Kerberos ユーザーは kinit経由で認証されま

す。例：# kinit [email protected]サービスユーザーは、core-site.xmlで

viprfs.security.principal プロパティに

よって定義されます。

ユーザーが書き

込むファイル：[email protected] サービス

が書き込むシステ

ムファイル：

必要に応じてユー

ザーに権限を割り

当てます。

HDFS の概要


表 28 Hadoop 認証モードのサマリー（続き）

認証モード Hadoop ユーザー ECS ユーザーバケットの権限

[email protected]

次の表は、単純認証および Kerberos 認証モードのそれぞれにおいて、ファイルとディレクトリに適用されるデフォルトの ACL を示します。

表 29 デフォルトの ACL

名前単純認証 Kerberos 認証

File 666 644

Directory 777 755

Hadoop のシンプル認証モード

Hadoop クラスターが単純モードで稼働している場合に、ユーザーがファイル、ディレクトリ、オブジェクトを作成すると、それらのファイルとディレクトリは、空の文字列の所有者付きで作成され、匿名のオブジェクトまたは匿名で所有されているオブジェクトを参照します。これが原因で、独自の ACL チェックを行う一部のアプリケーションで問題が発生することがあります。

この問題を解決するには、core-site.xml内の fs.viprfs.auth.anonymous_translationプロパティを「CURRENT_USER」に設定します。この設定により、匿名で所有されているファイルを、現在の UNIX ユーザーによって所有されているかのように表示することができます。この例は、fs.viprfs.auth.anonymous_translation の設定が「NONE」に設定されている場合の動作を示しています。

# hadoop fs -ls /14/01/30 11:36:23 INFO vipr.ViPRFileSystem: Initialized ViPRFS (atom 1.0.1.0-811) for viprfs://hdfs.s3.docsited------rwx - 0 2014-01-30 10:42 /bard------rwx - 0 2014-01-30 10:34 /fooDird------rwx - 0 2014-01-30 06:15 /tmp

設定を「CURRENT_USER」に変更し、ログインユーザーが root の場合、root が所有者になっているのを確認できます。

# hadoop fs -ls /14/01/30 11:30:37 INFO vipr.ViPRFileSystem: Initialized ViPRFS (atom 1.0.1.0-811) for viprfs://hdfs.s3.docsiteFound 3 itemsdrwx------ - root 0 2014-01-30 10:42 /bardrwx------ - root 0 2014-01-30 10:34 /fooDirdrwx------ - root 0 2014-01-30 06:15 /tmp

匿名モードの場合は、すべての人からのアクセスを許可するように ECS バケットを設定して、Hadoop プロセスが ECS バケットにアクセスできるようにします。

ECS HDFS では、Kerberos が存在しない場合にユーザーをレルムにマップする手段としてfs.viprfs.auth.identity_translation が提供されます。ファイルを chownする必要がある場

合は、使用するレルムを指定できます。次に例を挙げます。

hdfs dfs -chown [email protected] /sallys/new/file

HDFS の概要

Hadoop 認証モード 173

「NONE」を指定する場合、ユーザーはファイルを chownするたびにレルムを入力する必要

があります。それ以外の場合は、便宜上「FIXED_REALM」を指定して、fs.viprfs.auth.realmプロパティで使用する実際のレルムを指定できます。

<property><name>fs.viprfs.auth.identity_translation</name><value>FIXED_REALM</value></property><property><name>fs.viprfs.auth.realm</name><value>MYREALM.COM</value></property>

匿名モードでの chownの使用は推奨されません。ファイルまたはディレクトリを chownす

る場合は、所有者を空の文字列から実際の所有者に変更します。ファイルまたはディレクトリに所有者が設定されると、匿名ユーザーはそれらにアクセスできなくなります。

Hadoop Kerberos 認証モード

Kerberos と ECS Active Directory サーバーが統合されると、Kerberos レルムからユーザーの単一のネームスペースが提供され、kinitで認証された Hadoop ユーザーが認証済み

ECS ユーザーとして認識されます。

Kerberos モードで稼働している Hadoop クラスターでは、Kerberos レルムから ActiveDirectory レルムへの一方向のレルム間信頼関係を使用して、ECS ユーザーを認証する必要があります。

core-site.xml内の以下の ID 変換プロパティが、Hadoop と ECS 間のユーザー変換を

正しく行うために使用されます。

l fs.permissions.umask-mode：値を「027」に設定します。

l fs.viprfs.auth.anonymous_translation：値を「CURRENT_USER」に設定します。

l fs.viprfs.auth.identity_translation：値を「CURRENT_USER_REALM」に設定して、ユーザーのレルムが自動的に検出されるようにします。または、fs.viprfs.auth.realm プロパティを使用してユーザーのレルムをハードコードする場合は「FIXED_REALM」に設定します。

さらに、core-site.xml内の以下のプロパティを設定して、サービスプリンシパルを定義

する必要があります。

l viprfs.security.principal

PIG と ACLPIG は独自の ACL チェックを実行してオブジェクトに対する適切な権限がユーザーにあるかどうかを判断するため、ECS HDFS 上で PIG を実行する場合は、以下のいずれかを行う必要があります。

l オプション 1： core-site.xmlに以下のプロパティを設定します。

n fs.<scheme>.auth.identity_translation = CURRENT_USER_REALM（Kerberos 認証モードの場合）または FIXED_REALM（シンプル認証モードの場合）

n fs.<scheme>.auth.anonymous_translation = CURRENT_USER

l オプション 2：以下の環境変数を設定します。

n $VIPR_LOCAL_USER_MODE ="true"

HDFS の概要


SymLink のサポート

標準の HDFS では、ファイルの完全な URI を指定しないシンボリックリンクは、同じ HDFS インスタンス内のパスを指します。

これは、ECS HDFS でも同様です。 SymLink に完全な URI を指定しない場合、ECS HDFS では現在のネームスペースとバケットが root として使用されます。現在のネームスペースとバケットの外側にあるファイルに SymLink を提供するには、スキームと権限の両方を含む完全な URI を指定する必要があります。

Hadoop 2.2 は SymLink をサポートしていません。

ファイルシステムとの対話操作

ECS HDFS と直接対話操作を行う場合、標準の HDFS ファイルシステムとの対話操作に比べて、次のような相違が生じることがあります。

l ファイルシステムを DistributedFileSystem のインスタンスと想定しているアプリケーションの場合は、正しく動作しません。組み込み型の HDFS 実装に対して動作するようにハードコーディングされているアプリケーションは、ECS HDFS を使用するように構成を変更する必要があります。

l ECS HDFS はデータのチェックサムをサポートしません。

l listCorruptFileBlocks 関数を使用する場合、ECS HDFS には破損ブロックという概念がないため、すべてのブロックが正常であると報告されます。

l レプリケーション係数は常に定数 N と報告され、N=1 となります。データは ECS SLA によって保護されます。Hadoop レプリケーションによってではありません。

未サポートの Hadoop アプリケーション

ECS HDFS では、小さなサブセットの Hadoop アプリケーションをサポートしていません。

l HttpFS

l Hue

l Cloudera Impala

l Apache Oozie

次の Hadoop アプリケーションは、安全な（Kerberos）Hadoop クラスターを使用した場合にサポートされません。

l HBase

l Hive

HDFS の概要

ファイルシステムとの対話操作 175

HDFS の概要


第 22 章

安全ではない Hadoop クラスター内の HDFS の構成

l ECS HDFS の構成................................................................................................ 178

安全ではない Hadoop クラスター内の HDFS の構成 177

ECS HDFS の構成本稿では、既存の Hadoop ディストリビューションを構成して ECS ストレージインフラストラクチャ内のデータを ECS HDFS で使用する方法について説明します。 Kerberos 認証ではなく単純認証を使用するように Hadoop ディストリビューションが構成されている場合は、本稿の段階的な手順を使用してください。

Hadoop ディストリビューションが Kerberos 認証用に構成されている場合は、こちら（190ページ）に記載されている手順に従ってください。

本稿の統合手順を実行するには、以下が必要です。

l Hadoop ディストリビューションとその関連ツールに関する実用的な知識。

l Hadoop ノードへのログイン、Hadoop システムファイルの変更、Hadoop サービスの開始/停止に必要な Hadoop 認証情報。

ECS HDFS と Hadoop との統合の計画

次のリストを使用して、統合を成功させるために必要な情報がそろっていることを確認してください。

表 30 ECS HDFS の構成の前提条件

構成要素操作

Hadoop クラスタークラスターがインストールされ動作していることを確認します。

この後の手順で使用するために管理者認証情報を記録します。

ECS クラスター：ECS ノ

ード

この後の手順で使用するために、ECS ノードの IP アドレスを記録します。

ECS クラスター: レプリ

ケーショングループ

ECS にレプリケーショングループがあることを確認します。

HDFS には、ECS レプリケーショングループ内での HDFS の作成を可能に

するバケットが必要です。バケットには、ネームスペースとバケットの名前

を使用してファイルシステムとしてアクセスします。

ECS クラスター: テナン

トの名前空間

テナントの名前空間が構成されていることを確認します。名前を記録しま

す。

ECS HDFS を Hadoop クラスターと統合するには、次のタスクを実行します。

1. ViPR HDFS インストールおよびサポートパッケージの取得（179 ページ）

2. HDFS のバケットの作成（179 ページ）

3. ViPR HDFS JAR の展開（180 ページ）またはクラスターへの Cloudera パーセルを使用した Hadoop のインストール（181 ページ）

4. core-site.xml の編集（182 ページ）

5. 次のサービスを再開します。

l HDFS

l MapReduce

l Pivotal HAWQ（このサービスを使用する場合のみ）

l YARN（Hortonworks 使用時）



Cloudera Manager Safety Valve を使用して core-site.xml プロパティを変更した場合は、デフォルトでは Cloudera Manager がすべてのサービスを再開します。

6. サービスが正常に再開されたことを確認します。

namenode datanode など一部のサービスは、default.fs が ViPRFS に設定されていると再開されず、ECS が非 Kerberos 構成でこれらのタスクを引き継ぎます。

7. ファイルシステムにアクセスできることを確認します。

HBase を使用する場合は、次の追加タスクを実行します。

1. HBASE hbase-site.xml の編集（186 ページ）。

2. HBase サービスの再開。

ECS HDFS インストールおよびサポートパッケージの取得

ECS HDFS JAR および HDFS サポートツールは ZIP ファイル（hdfsclient-1.2.0.0-<version>.zip）で提供されており、ECS サポートページ（support.EMC.com）からダ

ウンロードできます。

ZIP ファイルには、\tools\bin、\playbooks、\client、\parcelsのディレクトリが

含まれています。ファイルを解凍する前に、ZIP ファイルの内容を保存するためのディレクトリを作成して（解凍ツールで作成できる場合もあります）、そのディレクトリに内容を展開します。ファイルを展開すると、ディレクトリ内に以下のものが得られます。

l \tools\bin：ViPRAdminTools.sh が含まれます。ECS オブジェクトプロトコルや ECSポータルを使用せずに、HDFS アクセスをサポートするバケットを作成できます。

l \playbooks：ECS HDFS と通信する安全な Hadoop 環境を構成するための Ansibleプレイブックが含まれます。

l \client：以下のファイルが含まれます。

n ECS （ViPPRFS）JAR ファイル（viprfs-client-<ECS version>-hadoop-<hadoop version>.jar）：さまざまな Hadoop ディストリビューションを構成す

るために使用されます。

n libvipr-<version>.so：ECS HDFS 用に Pivotal HAWQ を構成するために使用

されます。

l \parcelsn 「パーセル」形式の Cloudera ディストリビューション：パーセルには、該当する

ViPRFS JAR ファイルが含まれます。

HDFS のバケットの作成

ECS の Hadoop HDFS サポートは、ECS オブジェクトストアを使用します。 HDFS が使用するためのバケットは多数の方法で作成できますが、HDFS アクセス用にマークされている必要があります。

シンプルなセキュリティ（非 Kerberos）を使用している Hadoop クラスターをサポートするバケットの作成では、以下の章の説明のように、ECS ポータルまたはオブジェクト API を使用できます。



ECS HDFS インストールおよびサポートパッケージの取得 179

権限の設定の詳細については、HDFS のバケット権限の設定（180 ページ）を参照してください。

URI Java クラスでサポートされていないため、アンダースコアはバケット名に使用できません。たとえば、viprfs://my_bucket.ns.site/は無効な URI であり、Hadoop に認

識されないため動作しません。

HDFS のバケット権限の設定

HDFS のアクセスにバケットを使用する前に、権限が適切に設定されていることを確認する必要があります。

ECS データアクセスプロトコルを使用して作成したバケットでは、バケットを作成したユーザーにフルコントロールが付与されます。ただし、バケットを HDFS で使用するには、すべてのユーザーにフルコントロールが付与されるように設定する必要があります。

バケットの権限は、S3 ブラウザーなどのグラフィカルクライアントまたは s3curl などのコマンドラインツールを使用して設定できます。

ECS HDFS JAR の展開

ECS クラスター内の各クライアントノードのクラスパスに ECS HDFS JAR を設定するには、次の手順を実行します。

はじめに

ECS の EMC サポートサイトから、使用する ECS ディストリビューション用の ECS HDFS JARを入手します。ECS HDFS インストールおよびサポートパッケージの取得（179 ページ）を参照してください。

表 31 ECS HDFS JAR

Hadoop 分散 ECS HDFS JAR

Pivotal HD PHD 2.1： viprfs-client-1.2.0.0-hadoop-2.2.jar

Cloudera バージョン CDH5 より前の Cloudera： viprfs-client-1.2.0.0-hadoop-2.0.3-alpha.jarCloudera バージョン CDH5.0.x： viprfs-client-1.2.0.0-hadoop-2.2.jarCloudera バージョン CDH5.1.x 以降： viprfs-client-1.2.0.0-hadoop-2.3.jar

Hortonworks HDP 2.0： viprfs-client-1.2.0.0-hadoop-2.2.jar

Cloudera Hadoop ディストリビューションを使用している場合は、提供される Cloudera パーセルを使用して、ViPRFS JAR 構成済みの Hadoop ディストリビューションをインストールできます。クラスターへの Cloudera パーセルを使用した Hadoop のインストール（181 ページ）を参照してください。

手順

1. ECS クライアントノードにログインします。



2. classpath コマンドを実行して、クラスパス内のディレクトリのリストを取得します。

# hadoop classpath3. ECS HDFS JAR を、classpath コマンドでリストされたフォルダーのうち/conf フォルダー

以降のいずれかのフォルダーにコピーします。

ECS 分散クラスパスの場所（推奨）

Pivotal HD /usr/lib/gphd/hadoop/libCloudera /usr/lib/hadoop/libHortonworks /usr/lib/hadoop/lib

4. 各 ECS クライアントノードに対し、この手順を繰り返します。

クラスターへの Cloudera パーセルを使用した Hadoop のインストール

Cloudera では、Cloudera Manager 管理コンソールから CDH クラスターへのソフトウェア配信メカニズムとしてパーセルを使用します。 ECS には ViPRFS パーセルと呼ばれる Clouderaパーセルがあり、ECS HDFS で使用できるように事前構成されています。

はじめに

ECS（ViPRFS）クライアントを含む Cloudera パーセルは、ECS HDFS インストールおよびサポートパッケージで提供されます（ECS HDFS インストールおよびサポートパッケージの取得（179 ページ）を参照）。

手順

1. パーセルリポジトリを作成します。

Cloudera パーセルリポジトリを作成するには、ViPRFS パーセルファイルを、Web サーバーで公開されるディレクトリに置きます。これは通常、ネットワーク内でホストされている場所です。

2. Cloudera Manager UI から ECS パーセルリポジトリを追加します。

a. ［Administration ］ > ［Settings ］ > ［Parcels］を選択します。

b. ［Parcel Update Frequency］を 1 分に設定して、検出を加速します。

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

3. パーセルをダウンロードします。

［Hosts］ > ［Parcels］ > ［Downloadable］を選択し、新の ViPRFS パーセルをダウンロードします。

4. クラスターにパーセルを配信します。

ViPRFS パーセルの複数のバージョンを配信できますが、一度にアクティブにできるのは1 つのバージョンだけです。

パーセルを削除するには、まずパーセルを非アクティブにし、その後ホストからパーセルを削除する必要があります。以上の操作はすべて、パーセルの UI から実行できます。

5. パーセルをアクティブ化します。

配信したパーセルをアクティブにするには、［Activate］ボタンをクリックします。

Cloudera Manager の指示に従ってクラスターを再起動すると、実行中のプロセスで新しいパーセルを使用できるようになります。

6. ［Restart］をクリックして、クラスターを再起動します。


クラスターへの Cloudera パーセルを使用した Hadoop のインストール 181

Hadoop core-site.xml ファイルの編集

core-site.xmlの更新に ECS HDFS と Hadoop クラスター（単純認証モード）の統合に

必要なプロパティを使用するには、次の手順を実行します。

はじめに

Hadoop ノードにログインして core-site.xmlを変更するためのユーザー資格情報が必

要です。

core-site.xmlの場所は、使用するディストリビューションによって異なります。

表 32 core-site.xml の場所

Hadoop ディストリビューション

core-site.xml の場所更新するノード

Pivotal HD /etc/ghpd/hadoop/conf ComputeMasterとクライアント

Cloudera /etc/hadoop/conf すべてのクライア

ントノード

Hortonworks /etc/hadoop/conf すべてのノード

core-site.xml は、Hadoop クラスター内の個々のノード上に存在します。それぞれの

インスタンス上で、同じプロパティを変更する必要があります。 1 つのノード上で変更を行った後、scp（secure copy）コマンドを使用することで、クラスター内の他のノードにファイルをコピーできます。

設定の必要な各プロパティの詳細については、「core_site.xml property reference」を参照してください。

手順

1. core-site.xmlが置かれているいずれかの HDFS ノードにログインします。

2. core-site.xmlのバックアップコピーを作成します。

cp core-site.xml core-site.backup3. 任意のテキストエディターを使用して、core-site.xmlを開いて編集します。


4. 以下のプロパティおよび値を追加して、ECS HDFS ファイルシステムを実装する Java クラスを定義します。

<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>



5. fs.vipr.installations プロパティを追加します。次の例では、値が Site1 に設定されています。

<property> <name>fs.vipr.installations</name> <value>Site1</value></property>

6. fs.vipr.installation.［installation_name］.hosts プロパティを ECS データノードまたはロードバランサーの IP アドレスのコンマ区切りリストとして追加します。次の例では、installation_name が Site1 に設定されています。

ロードバランサーを使用すると HDFS のシナリオに値が追加されないのは、ノードに直接接続するためのロジックがクライアントにないためです。したがって、このプロパティにはロードバランサーのアドレスではなくデータノードのリストを指定することを推奨します。さらに、fs.vipr.installation.［installation_name］.resolution も「dynamic」に設定してください。

<property> <name>fs.vipr.installation.Site1.hosts</name> <value>203.0.113.10,203.0.113.11,203.0.113.12</value></property>

7. fs.vipr.installation.［installation_name］.resolution プロパティを追加し、以下のいずれかの値に設定します。


dynamic ロードバランサーを使用せずに ECS データノードに直接アクセスする場合。

fixed ロードバランサーを使用して ECS データノードにアクセスする場合。

次の例では、installation_name が Site1 に設定されています。

<property> <name>fs.vipr.installation.Site1.resolution</name> <value>dynamic</value></property>

a. fs.vipr.installation.［installation_name］.resolution を dynamic に設定する場合は、fs.vipr.installation.[installation_name].resolution.dynamic.time_to_live_ms プロパティを追加して、ECS でアクティブノードのリストのクエリーを実行する頻度を指定します。


<property><name>fs.vipr.installation.Site1.resolution.dynamic.time_to_live_ms</name><value>900000</value></property>

8. fs.defaultFS プロパティを特定し、値を変更して、ECS ファイルシステムの URI を指定します。 .

この設定は任意です。ECS ViPRFS に接続するファイルシステムの完全な URL を指定できます。


Hadoop core-site.xml ファイルの編集 183

次のフォーマットを使用します。 viprfs://［<bucket_name.namespace.installation_name］l ［bucket_name］： Hadoop ジョブの実行時に使用するデータを保持するバケットの名

前。単純認証モードを実行している場合は、バケットの所有者は全員（Everybody）に権限を付与する必要があります。次の例では、bucket_name が mybucket に設定されています。

l ［namespace］：［bucket_name］が存在するテナントの名前空間。次の例では、namespace が mynamespace に設定されています。

l ［installation_name］： fs.vipr.installations プロパティによって指定された値。次の例では、installation_name が Site1 に設定されています。

<property> <name>fs.defaultFS</name> <value>viprfs://mybucket.mynamespace.Site1/</value></property>

9. fs.permissions.umask-mode を特定し、値を 022 に設定します。

一部の構成では、このプロパティがこの時点で存在していない可能性があります。その場合は、プロパティを追加します。

<property> <name>fs.permissions.umask-mode</name> <value>022</value></property>

10.fs.viprfs.auth.anonymous_translation プロパティを追加します。このプロパティは、匿名で所有されるオブジェクトを現在のユーザーにマップし、現在のユーザーにこのオブジェクトの変更権限を与えるために使用します。


NONE（デフォルト）匿名で所有されるオブジェクトを現在のユーザーにマップしません。

CURRENT_USER 匿名で所有されるオブジェクトを現在の UNIX ユーザーにマップします。

<property> <name>fs.viprfs.auth.anonymous_translation</name> <value>CURRENT_USER</value></property>

11.fs.viprfs.auth.identity_translation プロパティを追加します。このプロパティは、Kerberos が使用されていない場合、ユーザーをレルムに割り当てるために使用します。


FIXED_REALM この値を指定すると、ECS HDFS は fs.vipr.auth.realm プロパティの値からレルム名を取得する。

NONE（デフォルト） ECS HDFS はレルムを変換しない。

<property> <name>fs.viprfs.auth.identity_translation</name> <value>NONE</value></property>

12.fs.viprfs.auth.identity_translation プロパティを FIXED_REALM に設定した場合は、fs.viprfs.auth.realm プロパティを追加します。



13.Pivotal HAWQ サービスを使用する場合は、hawq.vipr.endpoint プロパティを追加します。次の形式で値を指定します。（［bucket_name.namespace.installation_name］参照）。

各項目の意味は以下のとおりです。

l ［bucket_name］：Hadoop ジョブの実行時に使用するデータを保持するバケットの名前。単純認証モードを実行している場合は、バケットの所有者は全員（Everybody）に権限を付与する必要があります。次の例では、bucket_name が mybucket に設定されています。



Pivotal HAWQ をサポートするバージョンの ECS が実行されている必要があります。詳細については、「サポートマトリックス」を参照してください。

<property><name>hawq.vipr.endpoint</name><value>mybucket.mynamespace.Site1</value></property>

14.core-site.xmlを保存します。

15.core-site.xmlを Hadoop クラスター内の必要な各ノード上で更新します。

16.Cloudera ディストリビューションを使用している場合は、［Cloudera Manager］を使用して、同一のプロパティと値により、core-site.xml の安全バルブを更新します。

17.Hadoop サービスを再起動します。


コマンド

Pivotal HD ComputeMaster：# service hadoop-yarn-resourcemanager restartデータノード：

# service hadoop-hdfs-datanode restart# service hadoop-yarn-nodemanager restartNameNode：

# service hadoop-yarn-nodemanager restartPivotal Hadoop クラスターを、デフォルトのファイルシステムとしてECS HDFS を使用するように構成する場合は（core-site.xmlの

fs.DefaultFS によって指定）、icm_client の cluster start/stop 関数は使用できません。代わりに、すべてのクラスターサービス（HDFS 以外）を個別に開始する必要があります。次に例を挙げます。

icm_client start -s yarn

icm_client start -s zookeeper

以下、同様に続きます。

Cloudera ［Cloudera Manager］を使用して、HDFS および MapReduce サービスを再開します。


Hadoop core-site.xml ファイルの編集 185


コマンド

Apache # stop-all.sh# start-all.sh

18.次のコマンドを実行してディレクトリリストを表示し、構成の結果をテストします。

# hdfs dfs -ls viprfs://mybucket.mynamespace.Site1/

13/12/13 22:20:37 INFO vipr.ViPRFileSystem: Initialized ViPRFS for viprfs://mybucket.mynamespace.Site1/

fs.defaultFS を設定した場合は、次のコマンドを使用できます。# hdfs dfs -ls /

HBASE hbase-site.xml の編集

HBASE を ECS HDFS で使用する場合は、hbase-site.xml内の hbase.rootdir をcore-site.xmlの fs.defaultFS プロパティと同じ値に設定する必要があります。

hbase-site.xml は次のいずれかの場所にあります。

表 33 hbase-site.xml の場所


hbase-site.xml の場所

Pivotal HD /etc/ghpd/hbase/conf/

Cloudera /etc/hbase/conf/

Hortonworks /etc/hbase/conf/

手順

1. hbase-site.xmlを開きます。

2. /hbaseをサフィックスとして追加して、hbase.rootdir プロパティを fs.defaultFS と同じ

値に設定します。

3. 変更を保存します。

a. Cloudera では、hbase-site.xmlの HBase Service Configuration Safety Valveに hbase.rootdir プロパティを追加します。

4. ディストリビューションのサービスを再開します。


説明

Pivotal HD hbase マスターノードで次のコマンドを実行します。

# service hbase-master restart




説明

hbase リージョンサーバーで次のコマンドを実行します。

# service hadoop-regionserver restart

Cloudera Cloudera Manager を使用して HBase サービスを再開します。

Hortonworks # bin/start-hbase.sh

例 1 hbase.rootdir エントリー

<property> <name>hbase.rootdir</name> <value>viprfs://testbucket.s3.testsite/hbase</value></property>


HBASE hbase-site.xml の編集 187

第 23 章

安全な Hadoop クラスター内の HDFS の構成

l 安全な Hadoop クラスターを構成して ECS HDFS を使用する方法 ........................ 190

安全な Hadoop クラスター内の HDFS の構成 189

安全な Hadoop クラスターを構成して ECS HDFS を使用する方法本稿では、既存の Hadoop ディストリビューションを構成して ECS ストレージインフラストラクチャ内のデータを ECS HDFS で使用する方法について説明します。 Hadoop クラスターがKerberos 認証を使用するように構成されている場合は、この手順に従ってください。

Hadoop クラスターが単純認証を使用するように構成されている場合は、こちら（178 ページ）の手順に従ってください。

この手順は、ECS アプライアンスには適用できません。

本稿の統合手順を実行するには、以下が必要です。

l Hadoop クラスターとその関連ツールに関する実用的な知識

l Hadoop ノードへのログイン、Hadoop システムファイルの変更、Hadoop サービスの開始/停止に必要な Hadoop 認証情報

ECS HDFS と安全な Hadoop クラスターの統合の計画

次のリストを使用して、統合を成功させるために必要な情報がそろっていることを確認してください。 Kerberos を使用して Hadoop クラスターを動作させてから、ECS HDFS を構成するのが、ベストプラクティスです。

表 34 ECS HDFS の構成の前提条件

構成要素操作

Hadoop クラスタークラスターがインストールされ動作していることを確認します。

この後の手順で使用するために管理者認証情報を記録します。

ECS クラスター：ECS ノ

ード

この後の手順で使用するために、ECS ノードの IP アドレスを記録します。

ECS クラスター: レプリ

ケーショングループ

ECS にレプリケーショングループがあることを確認します。

HDFS には、ECS レプリケーショングループ内での HDFS の作成を可能に

するバケットが必要です。バケットには、ネームスペースとバケットの名前

を使用してファイルシステムとしてアクセスします。

ECS クラスター: テナン

トの名前空間

テナントの名前空間が構成されていることを確認します。名前を記録しま

す。

また、Kerberos KDC がインストールされて、Hadoop サービスプリンシパルの認証を処理するように構成されていることも確認してください。 ECS ユーザーの認証に Active Directory を使用する場合は、Kerberos レルムと ECS ユーザーレルムの間にレルム間信頼関係を設定する必要があります。 Kerberos KDC の設定と信頼関係の構成については、Kerberos の構成について（200 ページ）を参照してください。

ECS HDFS を安全な Hadoop クラスターと統合するには、次のタスクを実行します。

1. ECS HDFS インストールおよびサポートパッケージの取得（191 ページ）

2. セキュア HDFS のバケットの作成（191 ページ）

3. セキュアクラスターへの ECS HDFS JAR の展開（192 ページ）またはセキュアクラスターへの Cloudera パーセルを使用した Hadoop のインストール（193 ページ）

4. ECS サービスプリンシパルを使用した ECS データノードの構成（194 ページ）

5. core-site.xml の編集（197 ページ）



6. HDFS および MapReduce サービスの再開

7. サービスが正常に再開されたことの確認

8. ファイルシステムにアクセスできることの確認

ECS HDFS インストールおよびサポートパッケージの取得

ECS HDFS JAR および HDFS サポートツールは ZIP ファイル（hdfsclient-1.2.0.0-<version>.zip）で提供されており、ECS サポートページ（support.EMC.com）からダ

ウンロードできます。

ZIP ファイルには、\tools\bin、\playbooks、\client、\parcelsのディレクトリが

含まれています。ファイルを解凍する前に、ZIP ファイルの内容を保存するためのディレクトリを作成して（解凍ツールで作成できる場合もあります）、そのディレクトリに内容を展開します。ファイルを展開すると、ディレクトリ内に以下のものが得られます。

l \tools\bin：ViPRAdminTools.sh が含まれます。ECS オブジェクトプロトコルや ECSポータルを使用せずに、HDFS アクセスをサポートするバケットを作成できます。

l \playbooks：ECS HDFS と通信する安全な Hadoop 環境を構成するための Ansibleプレイブックが含まれます。

l \client：以下のファイルが含まれます。

n ECS （ViPPRFS）JAR ファイル（viprfs-client-<ECS version>-hadoop-<hadoop version>.jar）：さまざまな Hadoop ディストリビューションを構成す

るために使用されます。

n libvipr-<version>.so：ECS HDFS 用に Pivotal HAWQ を構成するために使用

されます。

l \parcelsn 「パーセル」形式の Cloudera ディストリビューション：パーセルには、該当する

ViPRFS JAR ファイルが含まれます。

セキュア HDFS のバケットの作成

Kerberos を使用して Hadoop クラスターが保護されている場合に、Kerberos ドメインに対して認証されているユーザーがバケットを作成できるようにするには、S3 バケットを作成してHDFS アクセスを有効にするか、ECS 管理ツールを使用します。

管理ツールを使うことで簡単にバケットを作成できるため、ECS ポータルへのアクセスやECS 管理 API/S3 オブジェクトサービス API の使用は必要ありません。

これらのメカニズムについて以下で説明します。


l ViPRAdminTool を使用した HDFS 用バケットの作成（191 ページ）

URI Java クラスでサポートされていないため、アンダースコアはバケット名に使用できません。たとえば、viprfs://my_bucket.ns.site/は無効な URI であり、Hadoop に認

識されないため動作しません。

ViPRAdminTool を使用した HDFS 用バケットの作成

Kerberos で保護された Hadoop クラスターから、ViPRAdminTool.shを使用して、オブジ

ェクトプロトコルと HDFS プロトコルで使用するバケットを作成できます。ECS REST API やObject Data Access API の知識は必要ありません。このツールは、ECS HDFS JAR 内の Java


ECS HDFS インストールおよびサポートパッケージの取得 191

クラスのラッパーであるため、Hadoop クラスターが ECS HDFS を使用するように構成されていると実行できます。

はじめに

l ViPRAdminTool.shを取得します。参照： ECS HDFS インストールおよびサポートパッケージの取得（191 ページ）

l Hadoop がインストールされている必要があります。ツールを実行するマシンでは、ECSHDFS JAR がインストールされており、Hadoop クラスターが ECS HDFS にアクセスするように構成されている必要があります。

l Kerberos セキュリティが構成されている必要があります。 Kerberos セキュリティが構成されていない場合は、S3 API または ECS REST API を使用してバケットを作成する必要があります。

ViPRAdminTool ツールのリファレンス情報については、ECS 管理ツールリファレンス（203ページ）を参照してください。

手順

1. ViPRAdminTool.shスクリプトを使用して、 createBucket コマンド、ECS ノードお

よびネームスペースへのパス、新しいバケットの名前、バケットに設定する権限を指定します。

以下のコマンドでは、「newbucket」という名前のバケットが作成され、バケットの権限は0755（rwx/r-x/r-x）として設定されます。バケットが作成されるオブジェクト仮想プールはデフォルトプールで、バケットはデフォルトプロジェクトに割り当てられます。

l ViPRAdminTool.sh createbucket viprfs://<ECS Node Address>/myNamespace newbucket 0755

プロジェクトと仮想プールを指定する場合は、ECS REST API または CLI を使用してこれらの値を取得できます。

セキュアクラスターへの ECS HDFS JAR の展開

ECS クラスター内の各クライアントノードのクラスパスに ECS HDFS JAR を設定するには、次の手順を実行します。

はじめに

ECS の EMC サポートサイトから、使用する ECS ディストリビューション用の ECS HDFS JARを入手します。ECS HDFS インストールおよびサポートパッケージの取得（191 ページ）を参照してください。

表 35 ECS HDFS JAR


Pivotal HD PHD 2.1： viprfs-client-1.2.0.0-hadoop-2.2.jar

Cloudera バージョン CDH5 より前の Cloudera： viprfs-client-1.2.0.0-hadoop-2.0.3-alpha.jarCloudera バージョン CDH5.0.x： viprfs-client-1.2.0.0-hadoop-2.2.jarCloudera バージョン CDH5.1.x 以降： viprfs-client-1.2.0.0-hadoop-2.3.jar



表 35 ECS HDFS JAR （続き）


Hortonworks HDP 2.0： viprfs-client-1.2.0.0-hadoop-2.2.jar

Cloudera Hadoop ディストリビューションを使用している場合は、提供される Cloudera パーセルを使用して、ViPRFS JAR 構成済みの Hadoop ディストリビューションをインストールできます。セキュアクラスターへの Cloudera パーセルを使用した Hadoop のインストール（193 ページ）を参照してください。

手順

1. ECS クライアントノードにログインします。

2. classpath コマンドを実行して、クラスパス内のディレクトリのリストを取得します。

# hadoop classpath3. ECS HDFS JAR を、classpath コマンドでリストされたフォルダーのうち/conf フォルダー

以降のいずれかのフォルダーにコピーします。

ECS 分散クラスパスの場所（推奨）

Pivotal HD /usr/lib/gphd/hadoop/libCloudera /usr/lib/hadoop/libHortonworks /usr/lib/hadoop/lib

4. 各 ECS クライアントノードに対し、この手順を繰り返します。

セキュアクラスターへの Cloudera パーセルを使用した Hadoop のインストール

Cloudera では、Cloudera Manager 管理コンソールから CDH クラスターへのソフトウェア配信メカニズムとしてパーセルを使用します。 ECS には ViPRFS パーセルと呼ばれる Clouderaパーセルがあり、ECS HDFS で使用できるように事前構成されています。

はじめに

ECS（ViPRFS）クライアントを含む Cloudera パーセルは、ECS HDFS インストール/サポートパッケージで提供されます（ECS HDFS インストールおよびサポートパッケージの取得（191 ページ）を参照）。

手順

1. パーセルリポジトリを作成します。

Cloudera パーセルリポジトリを作成するには、ViPRFS パーセルファイルを、Web サーバーで公開されるディレクトリに置きます。これは通常、ネットワーク内でホストされている場所です。

2. Cloudera Manager UI から ECS パーセルリポジトリを追加します。

a. ［Administration ］ > ［Settings ］ > ［Parcels］を選択します。

b. ［Parcel Update Frequency］を 1 分に設定して、検出を加速します。

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


セキュアクラスターへの Cloudera パーセルを使用した Hadoop のインストール 193

3. パーセルをダウンロードします。

［Hosts］ > ［Parcels］ > ［Downloadable］を選択し、新の ViPRFS パーセルをダウンロードします。

4. クラスターにパーセルを配信します。

ViPRFS パーセルの複数のバージョンを配信できますが、一度にアクティブにできるのは1 つのバージョンだけです。

パーセルを削除するには、まずパーセルを非アクティブにし、その後ホストからパーセルを削除する必要があります。以上の操作はすべて、パーセルの UI から実行できます。

5. パーセルをアクティブ化します。

配信したパーセルをアクティブにするには、［Activate］ボタンをクリックします。

Cloudera Manager の指示に従ってクラスターを再起動すると、実行中のプロセスで新しいパーセルを使用できるようになります。

6. ［Restart］をクリックして、クラスターを再起動します。

ECS サービスプリンシパルを使用した ECS データノードの構成

ECS サービスプリンシパルおよび対応する keytab ファイルは、各 ECS データノードに存在している必要があります。提供される Ansible プレイブックを使用してステップを自動化します。

はじめに

この手順を完了する前に、以下の項目を準備しておく必要があります。

l Ansible プレイブックへのアクセス。 Ansible プレイブックを ECS HDFS ソフトウェアパッケージから取得（ViPR HDFS インストールおよびサポートパッケージの取得（191 ページ）を参照）し、Ansible をインストールするノードにコピーします。

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 ノード用のサービスプリンシパルを取得する。

手順

1. Ansible をインストールします。

yum install epel-release && yum install ansible

2. hdfsclient-1.2.0.0-<version>.zip ファイルを解凍します。

このプロシージャのステップでは、viprfs-client-1.2.0.0-<version>/playbooks/samplesディレクトリに格納されたプレイブックを使用します。ステップはviprfs-client-1.2.0.0-<version>/playbooks/samples/README.mdにも格納されています。



3. 提供された Ansible role をインストールします。

ansible-galaxy install -r requirements.txt -f

4. viprfs-client-1.2.0.0-<version>/playbooks/samplesディレクトリの内

容を作業ディレクトリにコピーします。

5. inventory.txtを編集して、ECS データノードと KDC サーバーを参照します。

デフォルトのエントリーは次のとおりです。

[data_nodes]192.168.2.[100:200]

[kdc]192.168.2.10

6. oracle.com から「unlimited」JCE ポリシーアーカイブをダウンロードし、それをUnlimitedJCEPolicyディレクトリに展開します。

強力な暗号化タイプ（AES-256 など）を使用するように Kerberos を構成できます。その場合は、「unlimited」ポリシーを使用するように ECS ノード内の JRE を再度構成する必要があります。

このステップは、強力な暗号化タイプを使用する場合にのみ実行します。

7. krb5.conf ファイルを KDC から作業ディレクトリにコピーします。

8. 必要に応じて 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 です。

9. 実行します。

export ANSIBLE_HOST_KEY_CHECKING=False


ECS サービスプリンシパルを使用した ECS データノードの構成 195

10.Ansible プレイブックを実行して、keytab を生成します。

ansible-playbook -v -k -i inventory.txt generate-vipr-keytabs.yml

11.必要に応じて 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」role を削除します。

12.Ansible プレイブックを実行して、ECS サービスプリンシパルでデータノードを構成します。

./viprfs-client-1.2.0.0-<version>/playbooks/samples/keytabデ

ィレクトリが存在し、krb5.conf ファイルが作業ディレクトリ viprfs-client-1.2.0.0-<version>/playbooks/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です。

core-site.xml の編集

ECS HDFS と ECS クラスター（Kerberos 認証モード）を使用する場合に必要なプロパティでcore-site.xmlを更新するには、次の手順を実行します。

はじめに

ECS ノードにログインして core-site.xmlを変更するための認証情報を取得します。

設定の必要な各プロパティの詳細については、「core_site.xml property reference」を参照してください。

core-site.xml は Hadoop クラスターの各ノードに存在します。ユーザーは各インスタン

スで同じプロパティを変更する必要があります。 1 つのノード上で変更を行った後、scp（secure copy）コマンドを使用することで、クラスター内の他のノードにファイルをコピーできます。ベストプラクティスは、構成手順を開始する前に core-site.xmlをバックアップす

ることです。

core-site.xmlの場所は、使用するディストリビューションによって異なります。

表 36 core-site.xml ファイルの場所

ViPR Controllerディストリビューション

core-site.xml の場所更新するノード

Pivotal HD /etc/ghpd/hadoop/conf ComputeMasterとクライアント

Cloudera /etc/hadoop/conf クライアントノード

Hortonworks /etc/hadoop/conf すべてのノード

手順

1. core-site.xmlが置かれているいずれかの HDFS ノードにログインします。

2. core-site.xmlのバックアップコピーを作成します。

cp core-site.xml core-site.backup3. 任意のテキストエディターを使用して、core-site.xmlを開いて編集します。



core-site.xml の編集 197

4. 以下のプロパティおよび値を追加して、ECS HDFS ファイルシステムを実装する Java クラスを定義します。

<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>

5. fs.vipr.installations プロパティを追加します。次の例では、値が Site1 に設定されています。


6. fs.vipr.installation.［installation_name］.hosts プロパティを ECS データノードまたはロードバランサーの IP アドレスのコンマ区切りリストとして追加します。次の例では、installation_name が Site1 に設定されています。

ロードバランサーを使用すると HDFS のシナリオに値が追加されないのは、ノードに直接接続するためのロジックがクライアントにないためです。したがって、このプロパティにはロードバランサーのアドレスではなくデータノードのリストを指定することを推奨します。さらに、fs.vipr.installation.［installation_name］.resolution も「dynamic」に設定してください。


7. fs.vipr.installation.［installation_name］.resolution プロパティを追加し、以下のいずれかの値に設定します。


dynamic ロードバランサーを使用せずに ECS データノードに直接アクセスする場合。

fixed ロードバランサーを使用して ECS データノードにアクセスする場合。



a. fs.vipr.installation.［installation_name］.resolution を dynamic に設定する場合は、fs.vipr.installation.[installation_name].resolution.dynamic.time_to_live_ms プロパティを追加して、ECS でアクティブノードのリストのクエリーを実行する頻度を指定します。




<property><name>fs.vipr.installation.Site1.resolution.dynamic.time_to_live_ms</name><value>900000</value></property>

8. fs.defaultFS プロパティを特定し、値を変更して、ECS ファイルシステムの URI を指定します。 .

この設定は任意です。ECS ViPRFS に接続するファイルシステムの完全な URL を指定できます。

次のフォーマットを使用します。 viprfs://［<bucket_name.namespace.installation_name］l ［bucket_name］： Hadoop ジョブの実行時に使用するデータを保持するバケットの名

前。単純認証モードを実行している場合は、バケットの所有者は全員（Everybody）に権限を付与する必要があります。次の例では、bucket_name が mybucket に設定されています。




9. 「fs.permissions.umask-mode」を検索し、値を「027」に設定します。

一部の構成では、このプロパティがこの時点で存在していない可能性があります。その場合は、プロパティを追加します。

<property> <name>fs.permissions.umask-mode</name> <value>027</value></property>

10.fs.viprfs.auth.anonymous_translation プロパティを追加します。このプロパティは、匿名で所有されるオブジェクトを現在のユーザーにマップし、現在のユーザーにこのオブジェクトの変更権限を与えるために使用します。


NONE（デフォルト）匿名で所有されるオブジェクトを現在のユーザーにマップしません。

CURRENT_USER 匿名で所有されるオブジェクトを現在の UNIX ユーザーにマップします。


11.［fs.viprfs.auth.identity_translation］プロパティを追加し、［CURRENT_USER_REALM］に設定します。これにより、kinitを使用してサインインしたユーザーのレルムにマッピン

グされます。

<property> <name>fs.viprfs.auth.identity_translation</name>


core-site.xml の編集 199

<value>CURRENT_USER_REALM</value></property>

12.［viprfs.security.principal］プロパティを追加します。このプロパティにより、ECS ユーザーが KDC に通知されます。

プリンシパル名には「_HOST」を含めることができます。これは、実行時に実際のデータノード FQDN に自動的に置換されます。

<property> <name>viprfs.security.principal</name> <value>vipr/[email protected]</value></property>

13.HDFS および MapReduce サービスを再開します。

14.次のコマンドを実行してディレクトリリストを表示し、構成の結果をテストします。

# kinit <［service principal］>

# hdfs dfs -ls viprfs://mybucket.mynamespace.Site1/

13/12/13 22:20:37 INFO vipr.ViPRFileSystem: Initialized ViPRFS for viprfs://mybucket.mynamespace.Site1/

fs.defaultFS を設定した場合は、次のコマンドを使用できます。

# hdfs dfs -ls /

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.EMC.COM の「detscr」ユーザーを使用しています。例のように、KDCREALM とADREALM の間に一方向の信頼関係を作成します。このレルムは「netdom trust」を使用して検証しないでください。


Kerberos の構成について 201

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

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.EMC.COM /Domain:CAMBRIDGE.EMC.COM /add /realm /passwordt:ChangeMeksetup /SetEncTypeAttr LSS.EMC.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\.EMC\.COM$)s/^(.*)@CAMBRIDGE\.EMC\.COM$/$1/gRULE:[2:$1@$0](^.*@CAMBRIDGE\.EMC\.COM$)s/^(.*)@CAMBRIDGE\.EMC\.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

ECS 管理ツールリファレンス

付属の ECS 管理ツール（ViPRAdminTool.sh）を使用すると、ECS ポータルや API を操

作せずに、HDFS をサポートするバケットを HDFS クラスターから作成できます。このツールは、バケットのステータスをリスト、削除、取得するためにも使用できます。

ツールの取得

ViPRAdminTool.shツールは、ECS HDFS JAR 内の Java クラスのラッパーであるため、

Hadoop クラスターが ECS HDFS を使用するように構成されていると実行できます。取得方法については ECS HDFS インストールおよびサポートパッケージの取得（191 ページ）を参照してください。

用途

l ツールを実行するには、以下を使用します。

ViPRAdminTool.sh <COMMAND> [ARGUMENTS]l 以下を使用すると、スクリプトなしでツールを実行し、クラスを直接呼び出せます。

hadoop com/emc/hadoop/fs/vipr/ViPRAdminClient <COMMAND> [ARGUMENTS]<>で示されるコマンドは常に必要です。[]で示される引数はオプションです。

指定したい後の引数まで、すべての引数を入力する必要があります。

コマンド

createbucket <uri><name>[permission][vpoolId][projectId][objectType]

バケットを作成します。statbucket <uri><name>

指定したバケットのステータスを取得します。deletebucket <uri><name>

指定したバケットを削除します。listbucket <uri>

現在のユーザーが読み取り権限を持っているすべてのバケットをリストします。

引数

name作成、ステータス取得、削除の対象にするバケット名です。

uri


ECS 管理ツールリファレンス 203

ECS 環境へのポインターで、<scheme>://<DataNode Address>/<namespace>の形式です。

権限createbucketにのみ有効です。「0755」などの 8 進表記で POSIX 権限を指定しま

す。デフォルト値： 0777vpoolId

createbucketにのみ有効です。使用するレプリケーショングループの ID です。指定されていない場合、デフォルトのレプリケーショングループが使用されます。

objectTypecreatebucketにのみ有効です。このバケットに許可される objectType を指定しま

す。許可されるのは S3 のみです。



第 24 章

ECS HDFS 構成のトラブルシューティング

l トラブルシューティング......................................................................................... 206

ECS HDFS 構成のトラブルシューティング 205

トラブルシューティングここでは、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 サーバーに問題がある可能性があります。

AD ユーザーの権限が拒否される

AD ユーザーとしてアプリケーションを実行するときに、「Permission denied」エラーが発生することがあります。



回避策

/userディレクトリの権限を次のように設定します。

hdfs dfs -chmod 1777 /user

hbase 構成後のサービスの再起動

hbase-site.xml の hbase.rootdir プロパティを編集した後に、hbase サービスが正常に再起動しないことがあります。

回避策

Cloudera または Hortonworks でこの問題が発生する場合は、次の手順を実行して、hbase-master を実行状態にします。

1. zookeeper CLI に接続します。

hbase zkcli2. hbase ディレクトリを削除します。

rmr /hbase3. hbase サービスを再起動します。

Cloudera ですべてのサービスを再起動します。

Pig テストの失敗： Kerberos プリンシパルを取得できない

Pig テスト失敗し、エラー「Info:Error: java.io.IOException： Unable to obtain the Kerberosprincipal」（AD ユーザーとして kinitを実行した場合も含む）または「Unable to openiterator for alias firstten」が表示されることがあります。

この問題は、Pig（0.13 未満）でセカンダリストレージとしての ViPRFS に代行トークンが生成されないことが原因です。

回避策

viprfs://bucket.ns.installation/を［mapreduce.job.hdfs-servers］構成に追加します。例：

set mapreduce.job.hdfs-servers viprfs://KcdhbuckTM2.s3.site1

Kerberos のクライアント側ログの有効化

認証問題のトラブルシューティング用に、使用中の Hadoop クラスターノードで詳細ログを有効化できます。

詳細ログは、現在の SSH セッションのみに適用される環境変数を使用して有効化できます。

export HADOOP_OPTS="-Dsun.security.krb5.debug=true"

KDC での Kerberos のデバッグ

HDFS 操作の際にデバッグを容易にするために KDC の/var/log/krb5kdc.log ファイ

ルに tail を実行します。

tail -f /var/log/krb5kdc.log


hbase 構成後のサービスの再起動 207

クロックスキューの排除

Kerberos は時間の正確さに依存しているため、クライアントとサーバーの間で時間が同期されている必要があります。

AD のデータノードや KDC にクロックスキューがある場合は、NTP サーバーを構成します。次の手順を実行します。

1. リモートデスクトップを使用して、AD サーバーに接続します。

2. 次のコマンドを実行します。

a. w32tm /config /syncfromflags:manual /manualpeerlist:<ntp-server1>,<ntp-server2>

b. net stop w32time

c. net start w32time



第 25 章

ECS HDFS コアサイトプロパティリファレンス

l Hadoop ECS HDFS の core-site.xml のプロパティ................................................. 210

ECS HDFS コアサイトプロパティリファレンス 209

Hadoop ECS HDFS の core-site.xml のプロパティHadoopcore-site.xml ファイルを構成する場合は、プロパティおよびその関連する値

のリファレンスとしてこの表を使用してください。

表 37 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.[installation_name].hosts プロパティでさらに定義されます。この名前は、ECS HFDS フ

ァイルシステム URI の権限セクションのコンポーネントとして使用されます。例：

<property> <name>fs.vipr.installations</name> <value>［<site1>,<abc>,<testsite>］</value> </property>

fs.vipr.installation.[installation_name].hosts

fs.vipr.installations プロパティに名前がリストされた ECS ロードバランサーまたはクラスターのデータノードの IP アドレス。コンマ区切りリストの形式で IP アドレスの値を指定します。次に例を挙げます。

<property> <name>fs.vipr.installation.<［site1>］.hosts</name> <value>203.0.113.10,203.0.113.11,203.0.113.12</value> </property>

<property> <name>fs.vipr.installation.［<abc>］.hosts</name> <value>198.51.100.0,198.51.100.1,198.51.100.2</value> </property>

<property> <name>fs.vipr.installation.<［testsite>］.hosts</name> <value>198.51.100.10,198.51.100.11,198.51.100.12</value> </property>

fs.vipr.installation.[installation_name].resolution

ECS データノードにどのようにアクセスするかを ECS HDFS ソフトウェアに通知する方法を指定。値は以下

のとおりです。



表 37 Hadoop core-site.xml のプロパティ（続き）


l dynamic：ロードバランサーを使用せずに ECS データノードに直接アクセスする場合は、この値を使

用。

l fixed：ロードバランサーを使用して ECS データノードにアクセスする場合は、この値を使用。

<property><name>fs.vipr.installation.testsite.resolution</name><value>dynamic</value>

</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.<［testsite］>.resolution.dynamic.time_to_live_ms</name><value>600000</value>

</property>

ECS ファイルシステム URI

fs.defaultFS デフォルトのファイルシステムへの URI を指定する標準的な Hadoop プロパティ。このプロパティを ECSHDFS ファイルシステムに設定するかどうかは任意です。これを ECS HDFS ファイルシステムに設定しない

場合は、ファイルシステムの各操作で完全な URI を指定する必要があります。 ECS HDFS ファイルシステ

ムの URI の形式は以下のとおりです。

viprfs://[bucket_name].[namespace].[installation_name]

l ［bucket_name］： HDFS 対応バケットの名前。Hadoop® ジョブを実行するときに使用するデータが含ま

れます。

l ［namespace］：HDFS 対応バケットに関連づけられたテナントのネームスペース。

l ［installation_name］： ECS データノードセットに関連づけられた名前。Hadoop® が ECS のデータにア

クセスするときに使用できます。このプロパティの値は、［fs.vipr.installations］プロパティで指定された

値の 1 つと一致している必要があります。


<property><name>fs.defaultFS</name><value>viprfs://testbucket.s3.testsite</value>

</property>

HBase では、デフォルトのファイルシステムを定義しておく必要があります。

Pivotal HAWQ サービス

hawq.vipr.endpoint ECS エンドポイントを指定するプロパティ。このエンドポイントは HAWQ サービスから ECS ファイルシステム

への通信に使用されます。プロパティの構文は以下のとおりです。

［bucket_name］.［namespace］.［installation_name］


Hadoop ECS HDFS の core-site.xml のプロパティ 211



l ［bucket_name］： HDFS 対応バケットの名前。HAWQ サービスと併用するデータが含まれます。

l ［namespace］：HDFS 対応バケットに関連づけられたテナントのネームスペース。

l ［installation_name］： ECS データノードセットに関連づけられた名前。Hadoop® が ECS のデータにア

クセスするときに使用できます。このプロパティの値は、［fs.vipr.installations］プロパティで指定された

値の 1 つと一致している必要があります。


<property> <name>hawq.vipr.endpoint</name> <value>testbucket.s3.testsite</value> </property>

UMASK のプロパティ

fs.permissions.umask-mode

標準的な Hadoop プロパティ。ECS HDFS によるオブジェクトでの権限の処理方法を指定します。権限は、

入力権限で umask を適用することで処理されます。推奨される値は以下のとおりです。

l Kerberos がある場合： 027

l Kerberos がない場合： 022


<property><name>fs.permissions.umask-mode</name><value>027</value></property>

ID 変換のプロパティ

fs.viprfs.auth.identity_translation

特定のユーザーがどの Kerberos レルムに所属するか指定されていない場合に、ECS HDFS クライアントが

所属を決定する方法を指定するプロパティ。 ECS データノードでは、ファイルの所有者は

username@REALM の形式で保存されます（Hadoop では、ファイルの所有者は単にユーザー名で保存さ

れます）。

取り得る値は、以下のとおりです。

l NONE：デフォルト。ユーザーはレルムにマップされません。

l FIXED_REALM：ユーザーは［fs.viprfs.auth.realm］で指定されたレルムにマップされます。

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>FIXED_REALM</value> </property>





fs.viprfs.auth.realm ［fs.viprfs.auth.identity_translation］プロパティが［FIXED_REALM］に設定されている場合に、ユーザーに割

り当てられるレルムです。

<property> <name>fs.viprfs.auth.realm</name> <value>MY_REALM</value> </property>

fs.viprfs.auth.anonymous_translation

このプロパティにより、所有者が匿名のオブジェクトが現在のユーザーにマップされ、現在のユーザーがそ

のオブジェクトを変更できるようになります。

Hadoop では、オブジェクトには所有者がいるものと考えられます。しかし、ECS HDFS では、所有者が匿名

のオブジェクトを誰でも更新できます。値は次のとおりです。

l CURRENT_USER：これにより、所有者が匿名のオブジェクトの読み取りと書き込みを現在のユーザー

ができるようになります。オブジェクトが stat'd の場合、BLOB を「所有」しているユーザーが、現在の

Kerberos ユーザーです。

l NONE：（デフォルト）。マッピングは実行されません。所有者が匿名のオブジェクトの場合、所有者は

空です。アプリケーションによっては、現在のユーザーが、所有者が匿名のオブジェクトにアクセスで

きない場合があります。

<property> <name>fs.viprfs.auth.anonymous_translation</name> <value>CURRENT_USER</value> </property>

Kerberos レルムとサービスプリンシパルのプロパティ

viprfs.security.principal ECS のサービスプリンシパルを指定するプロパティ。このプロパティにより、KDC に ECS サービスのことが

通知されます。この値は、ユーザーの構成に固有です。

プリンシパル名には「_HOST」を含めることができます。これは、実行時に実際のデータノード FQDN に自

動的に置換されます。

<property> <name>viprfs.security.principal</name> <value>vipr/_HOST@［<realm>］</value></property>

例：

<property> <name>viprfs.security.principal</name> <value>vipr/_HOST@［example.com］</value></property>


Hadoop ECS HDFS の core-site.xml のプロパティ 213

YARN の使用

Kerberos が ECS HDFS で有効になっている場合は、YARN の RM（Resource Manager）とNM（Node Manager）を同じ Kerberos プリンシパルとして実行する必要があります。以下は、それを core-site.xmlのプロパティで設定する方法の例です。

fs.vipr.auth.service.yarn.principal = rm/[email protected] = /etc/security/keytab/rm.keytabyarn.nodemanager.keytab = /etc/security/keytab/rm.keytabyarn.nodemanager.principal = rm/[email protected] = /etc/security/keytab/rm.keytabyarn.resourcemanager.principal = rm/[email protected]

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

この core-site.xmlは、単純認証モードの ECS HDFS プロパティの例です。

例 2 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.installation.Site1.resolution.dynamic.time_to_live_ms</name> <value>900000</value></property>



<property> <name>fs.viprfs.auth.identity_translation</name> <value>FIXED_REALM</value></property>



例 2 core-site.xml （続き）

<property> <name>fs.viprfs.auth.realm</name> <value>MY.TEST.REALM</value></property>


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

第 8 部

ECS データへのアクセス

第 26 章, "ECS Amazon S3 オブジェクトサービス API サポート "

第 27 章, "ECS OpenStack Swift オブジェクトサービス API サポート "

第 28 章, "ECS EMC Atmos オブジェクトサービス API サポート "

ECS データへのアクセス 217

ECS データへのアクセス


第 26 章

ECS Amazon S3 オブジェクトサービス API サポート

l Amazon S3 API....................................................................................................220

ECS Amazon S3 オブジェクトサービス API サポート 219

Amazon S3 API本稿では、ECS がサポートする Amazon S3 API について説明します。

Amazon S3 オブジェクトサービスは、次のポートで使用できます。

表 38 Amazon S3 オブジェクトサービスポート

プロトコルポート

HTTP 9020

HTTPS 9021

以降のセクションでは、S3 API のサポートについてと ECS で提供される拡張機能について説明し、サービスでの認証方法と、サービスにアクセスするクライアントの開発に SDK を使用する方法についても説明します。

l S3 API のサポート対象およびサポート対象外の機能（220 ページ）

l API の拡張機能（223 ページ）

l S3 サービスでの認証（227 ページ）

l SDK を使って S3 サービスにアクセス（228 ページ）

バケットのアドレス指定や認証には、ECS 特有のものがあります。既存のアプリケーションをECS と通信するように構成する場合、または S3 API を使用して ECS と通信する新しいアプリケーションを開発する場合は、次の記事を参照してください。

l ECS オブジェクトストレージのアドレス指定とベース URL の使用（132 ページ）

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

ECS は、Amazon S3 REST API のサブセットをサポートしています。

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

l サポートされている S3 API（220 ページ）

l サポートされていない S3 API（222 ページ）

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

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

機能注意事項

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

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

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

例：

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

DELETE Bucket



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

機能注意事項

DELETE Bucket cors

DELETE Bucket lifecycle ライフサイクルでサポートされるのは有効期限部分のみです。アーカイブ（AWS Glacier）に関連するポリシーはサポートされませ

ん。

GET Bucket (List Objects)

GET Bucket cors

GET Bucket acl

GET Bucket lifecycle ライフサイクルでサポートされるのは有効期限部分のみです。アーカイブ（AWS Glacier）に関連するポリシーはサポートされませ

ん。

GET Bucket Object versions

GET Bucket versioning

HEAD Bucket

List Multipart Uploads

PUT Bucket

PUT Bucket cors

PUT Bucket acl

PUT Bucket lifecycle ライフサイクルでサポートされるのは有効期限部分のみです。アーカイブ（AWS Glacier）に関連するポリシーはサポートされませ

ん。

PUT Bucket versioning

DELETE Object

Delete Multiple Objects

GET Object

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 レスポンスとは異なります。


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

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

機能注意事項

Abort Multipart Upload

List Parts

表 40 追加機能

機能注意事項

Pre-signed URLs ECS は署名済み URL の使用をサポートします。これにより、ユー

ザーは認証情報なしでオブジェクトにアクセスできます。

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

Chunked PUT PUT 操作を使用して、オブジェクトをチャンクでアップロードできま

す。チャンクにした転送では、Transfer-Encoding ヘッダー

（Transfer-Encoding: chunked）を使用して、コンテンツをチャンク

で転送するように指定します。これにより、ペイロードの総サイズ

がわかる前に、コンテンツを送信できます。

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

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

機能注意事項

DELETE Bucket policy

DELETE Bucket tagging

DELETE Bucket website

GET Bucket policy

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

GET Bucket logging

GET Bucket notification 通知は S3 の低冗長化機能に対してのみ定義されます。ECS は

現在、通知をサポートしていません。

GET Bucket tagging

GET Bucket requestPayment ECS には独自の支払いモデルがあります。

GET Bucket website

PUT Bucket policy

PUT Bucket logging

PUT Bucket notification 通知は S3 の低冗長化機能に対してのみ定義されます。ECS は

現在、通知をサポートしていません。

PUT Bucket tagging

PUT Bucket requestPayment ECS には独自の支払いモデルがあります。



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

表 41 サポートされていない S3 API （続き）

機能注意事項

PUT Bucket website

オブジェクト APIs

GET Object torrent

POST Object

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

されません。

API の拡張機能

オブジェクト API の複数の拡張機能がサポートされています。

拡張機能とそれらをサポートする API は以下の表に一覧表示されています。

表 42 オブジェクト API の拡張機能

機能注

PUT Object (range-update)

範囲ヘッダーを使用して更新するオブジェクト範囲を指定します。

オブジェクト内でのバイト範囲の更新（223 ページ）

PUT Object (range-overwrite)

範囲ヘッダーを使用して上書きするオブジェクト範囲を指定します。

オブジェクトの一部を上書き（225 ページ）

PUT Object (range-append)

範囲ヘッダーを使用して追加するオブジェクト範囲を指定します。

オブジェクトにデータを追加（225 ページ）

GET Object (range-read)

範囲ヘッダーを使用して読み取りするオブジェクトバイト範囲を指定しま

す。

オブジェクト内での複数のバイト範囲の読み取り（226 ページ）

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

ECS API の拡張機能を使用してオブジェクトのバイト範囲を更新する例を以下に示します。

初めに object1 located in bucket1 という名前のオブジェクトで GET リクエストを行い、

オブジェクトを確認します。 object1 には次の値があります。 The quick brown foxjumps 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


API の拡張機能 223

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-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

オブジェクトを再度読み取ると、新しい値は The quick green fox jumps overthe lazy 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.



オブジェクトの一部を上書き

ECS API の拡張機能を使用してオブジェクトの一部を上書きする例を以下に示します。

データリクエストで開始オフセットを提供するだけで、オブジェクトの一部を上書きできます。書き込まれるリクエストのデータは提供されたオフセットで開始されます。形式は以下のとおりです。 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 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

オブジェクトを取得すると、終的な値 The quick brown cat jumps over thelazy dog and cat.を見ることができます（green foxは brown 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.

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

ECS API の拡張機能を使用してオブジェクトにデータを追加する例を以下に示します。

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

オブジェクトにデータを追加するために特別な値 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 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

オブジェクトを再度取得すると、完全な値 The quick green fox jumps over thelazy 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.

オブジェクト内での複数のバイト範囲の読み取り

ECS API の拡張機能を使用してオブジェクト内の複数のバイト範囲を読み取る例を以下に示します。

object1 という名前のオブジェクト内で 2 つの特定のバイト範囲を読み取るために、

Range: bytes==4-8,41-44に以下の GET リクエストを発行します。読み取りレスポン

スは、quick と lazyが対象になります。



Amazon S3 の API は読み取りに HTTP ヘッダー Rangeを使用する場合は 1 つの範囲しか

サポートしませんが、ECS は複数のバイト範囲をサポートします。

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--bound04acf7f0ae3cccContent-Type: application/octet-streamContent-Range: bytes 41-44/50lazy--bound04acf7f0ae3ccc--

S3 サービスでの認証

Amazon S3 API での認証については、下記の Amazon S3 ドキュメントで説明されています。このトピックでは、認証プロセスの ECS 固有の側面を示します。

Amazon S3 API での ECS システムに対する認証については、後続のセクションで説明します。 S3 認証の完全なアルゴリズムについては、Amazon S3 ドキュメントで説明されています。

Amazon S3 は、すべてのリクエストに存在しなければならない認証ヘッダーを使用して、ユーザーを識別し、リクエストのシグネチャを提供します。 Amazon を呼び出すとき、ヘッダーは次の形式をとります。

Authorization: AWS <AWSAccessKeyId>:<Signature>

ECS では、AWSAccessKeyId は ECS UID（ユーザー ID）にマップされます。 AWS アクセスキー ID は 20 文字ありますが（S3 ブラウザーなどの一部の S3 クライアントで確認されます）、ECS データサービスにはこの制限はありません。

シグネチャは、Amazon S3 ドキュメントで詳しく説明されているように、リクエストの要素とユーザーの秘密キーから計算されます。

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

注意事項を次に示します。

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

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


S3 サービスでの認証 227

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

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

ECS S3 サービスと通信するアプリケーションを開発するにあたり、開発作業を支援するSDK はたくさんあります。

EMC コミュニティでは、利用できるさまざまなクライアントの情報と、その使い方に関するガイダンスを提供しています。 EMC ViPR 開発者リソースを参照してください。

以降のトピックでは、Amazon S3 SDK と EMC ECS Java SDK の使い方について説明します。l Java Amazon SDK の使用（228 ページ）l ECS の Java SDK クライアント　（230 ページ）

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

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 検証エラーを返し、接続に失敗します。

次のスニペットでは、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);



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

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);

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()); }


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

}}

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); } catch (Exception e) { } }}



第 27 章

ECS OpenStack Swift オブジェクトサービス API サポート

l OpenStack Swift API............................................................................................232

ECS OpenStack Swift オブジェクトサービス API サポート 231

OpenStack Swift APIECS は、OpenStack Swift API をサポートします。本稿では、サポート対象の機能を説明し、許可および認証のメカニズムを説明します。

OpenStack Swift サービスは、次のポートで使用できます。

表 43 OpenStack Swift オブジェクトサービスポート


HTTP 9024

HTTPS 9025

以降のセクションでは、サポートされるメソッド、ECS の拡張機能、認証のメカニズムを説明します。

l サポート対象の OpenStack Swift 機能（232 ページ）

l API の拡張機能（233 ページ）

l OpenStack バージョン 1.0 認証（238 ページ）

l OpenStack バージョン 2.0 認証（239 ページ）

l コンテナーに対する認証（241 ページ）

OpenStack Swift API の使用例については、次を参照してください。

l OpenStack API の例

サポート対象の OpenStack Swift 機能

以降のセクションでは、ECS でサポートされる OpenStack REST API リクエストを挙げています。

l サポート対象の OpenStack Swift コール（232 ページ）

l サポート対象外の OpenStack Swift コール（233 ページ）

この情報は、「OpenStack API リファレンス」文書の「Object Storage API V1」セクションから抜粋したものです。

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

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

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

メソッドパス説明

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

取得します。

GET v1/{account}/{container} コンテナーに保存されたオブジェクトのリストを取得しま

す。

PUT v1/{account}/{container} コンテナーを作成します。

DELETE v1/{account}/{container} 空のコンテナーを削除します。

POST v1/{account}/{container} カスタムメタデータヘッダーをコンテナーレベル URI と関連づけることにより、任意のコンテナーメタデータを作



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

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


成または更新します。こうしたヘッダーは、X-Container-Meta-*の形式を取る必要があります。

HEAD v1/{account}/{container} コンテナーメタデータを取得します。現状ではオブジェ

クトカウントや使用バイトを含んでいません。

ユーザーには管理者権限が必要です。

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

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

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

オブジェクトの内容とメタデータを書き込むか上書きしま

す。

ソースを指定する X-Copy-From ヘッダーを使って、既存

のオブジェクトを別のオブジェクトにコピーするために使

います。

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 も、この操作で割り当て

ることができます。ただし、Content-Type などの他のヘ

ッダーは、この操作では変更できません。

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

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

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


HEAD v1/{account} アカウントメタデータ（たとえばコンテナ数や、アカウント

／テナント用の OpenStack オブジェクトストレージに保

存された総バイト数）を取得します。

POST v1/{account} カスタムメタデータヘッダーをアカウントレベル URI と関連づけることにより、アカウントメタデータを作成また

は更新します。こうしたヘッダーは、X-Account-Meta-*の形式を取る必要があります。

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

コピーは、X-Copy-From ヘッダーを持つ PUT v1/{account}/{container}/{object}を使ってサポートされま

す。

API の拡張機能

オブジェクト API の複数の拡張機能がサポートされています。





機能注 API のサポート

PUT Object(range-update)

範囲ヘッダーを使用して更新するオブジェクト範囲を指定し

ます。

オブジェクト内でのバイト範囲の更新（223 ページ）

S3/Atmos/Swift

PUT Object(range-overwrite)

範囲ヘッダーを使用して上書きするオブジェクト範囲を指定

します。

オブジェクトの一部を上書き（225 ページ）

S3/Atmos/Swift

PUT Object(range-append)

範囲ヘッダーを使用して追加するオブジェクト範囲を指定し

ます。


S3/Atmos/Swift

GET Object(range-read)

範囲ヘッダーを使用して読み取りするオブジェクトバイト範

囲を指定します。

オブジェクト内での複数のバイト範囲の読み取り（226ページ）

S3/Atmos/Swift

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

ECS API の拡張機能を使用してオブジェクトのバイト範囲を更新する例を以下に示します。

初めに object1 located in bucket1 という名前のオブジェクトで GET リクエストを行い、

オブジェクトを確認します。 object1 には次の値があります。 The quick brown foxjumps 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-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

オブジェクトを再度読み取ると、新しい値は The quick green fox jumps overthe lazy 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.

オブジェクトの一部を上書き

ECS API の拡張機能を使用してオブジェクトの一部を上書きする例を以下に示します。

データリクエストで開始オフセットを提供するだけで、オブジェクトの一部を上書きできます。書き込まれるリクエストのデータは提供されたオフセットで開始されます。形式は以下のとおりです。 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 -0000



x-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

オブジェクトを取得すると、終的な値 The quick brown cat jumps over thelazy dog and cat.を見ることができます（green foxは brown 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.






形式は以下のとおりです。 Range: bytes=-1-



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 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


た。

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.

オブジェクト内での複数のバイト範囲の読み取り

ECS API の拡張機能を使用してオブジェクト内の複数のバイト範囲を読み取る例を以下に示します。

object1 という名前のオブジェクト内で 2 つの特定のバイト範囲を読み取るために、

Range: bytes==4-8,41-44に以下の GET リクエストを発行します。読み取りレスポン

スは、quick と lazyが対象になります。

Amazon S3 の API は読み取りに HTTP ヘッダー Rangeを使用する場合は 1 つの範囲しか

サポートしませんが、ECS は複数のバイト範囲をサポートします。

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



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

OpenStack バージョン 1.0 認証

通信対象： ECS

手順

1. ECS から UID とパスワードを取得します。UID は LDAP 名または Active Directory 名です。次の ECS REST API を呼び出して、パスワードを生成します。

ECS との通信に OpenStack Swift API を使用するには、次の手順を実行します。

リクエスト：

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: eaaafd18-0fed-4b3a-81b4-663c99ec1cbb 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" 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: 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）認証の限定サポートが含まれます。

はじめに

OpenStack V2 では、Unscoped トークンを使用します。これはテナント情報のクエリーに使用できます。テナント情報を持つ Unscoped トークンは、Scoped トークンのクエリーに使用できます。 Scoped トークンとサービスエンドポイントは、V1 認証について説明している前述のセクションに記載されているように、ECS による認証に使用できます。次に挙げる 2 つの記事は、重要な背景情報を提供しています。

l OpenStack Keystone ワークフローとトークンのスコープ設定

l 管理者 API の認証


OpenStack バージョン 2.0 認証 239

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

手順

1. Unscoped トークンを取得します。

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 から始まります。

{"access": {"token": {"id":"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" : d668b72a011c4edf960324ab2e87438b"}}}' http://203.0.113.10:9024/v2.0/tokens

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

{"access":{"token":{"id":"baf0709e30ed4b138c5db6767ba76a4e","expires":"1376633255485","tenant":{"description":"s3","enabled":true,"name":"s3"}},"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 を使って、迅速に認証を行います。この手順は OpenStack の V1 と同じです。

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



コンテナーに対する認証

OpenStack Swift による認証はコンテナーだけを対象としています。

Swift は現在、2 種類の認証をサポートしています。

l リファラル形式の認証

l グループ形式の認証

ECS 2.0 では、グループベースの認証のみサポートしています。

管理者ユーザーは、アカウント内のすべての操作を行えます。管理者ではないユーザーは、コンテナーの X-Container-Read および X-Container-Write アクセスコントロールリストに基づき、コンテナーごとにのみ操作を行えます。管理者ではないユーザーには次の操作が許可されています。

管理者が読み取りアクセスをコンテナーに割り当て

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

このコマンドは、GROUP LIST に属するユーザーに、コンテナー 1 に対する読み取りアクセス権を持つことを許可します。

読み取り許可が与えられると、対象グループに属するユーザーは次の操作を実行できます。

l HEAD container：コンテナーメタデータの取得。テナント管理者権限を持つグループにユーザーが割り当てられている場合のみ許可されます。

l GET container：コンテナー内のオブジェクトを一覧にします。

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

管理者が書き込みアクセスをコンテナーに割り当て

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

GROUP LIST グループのユーザーに、書き込み許可が与えられます。書き込み許可が与えられると、対象グループに属するユーザーは次の操作を実行できます。

l POST container：メタデータの設定。「X-Container-Meta」のプレフィックスで始めます。

l PUT objects within container：コンテナー内のオブジェクトを書き込み／上書きします。

認証に関する詳細については、次を参照してください。「Container Operations」


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

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

第 28 章

ECS EMC Atmos オブジェクトサービス API サポート

l EMC Atmos API のサポート対象機能....................................................................244l サポート対象の EMC Atmos REST API コール........................................................244l サポート対象外の EMC Atmos REST API コール....................................................245l EMC Atmos REST API コールのサブテナントサポート............................................246l API の拡張機能................................................................................................... 247

ECS EMC Atmos オブジェクトサービス API サポート 243

EMC Atmos API のサポート対象機能ECS は、EMC Atmos API のサブセットをサポートしています。本稿では、サポート対象機能と ECS 拡張機能について説明します。

EMC Atmos オブジェクトサービスは、次のポートで使用できます。

表 47 EMC Atmos オブジェクトサービスポート


HTTP 9022

HTTPS 9023

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

l Atmos Programmer's Guide

すべてのサポート対象機能にワイヤー形式の互換性があります。そのため、「AtmosProgrammer's Guide」に記載されている機能は、ECS が提供する API 機能にも当てはまります。

「Atmos Programmer's Guide」はまた、Atmos API による認証の情報や、多くのサポート機能の包括的な例を提供しています。

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

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

表 48 サポート対象の 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 オブジェクトの名称変更



https://support.emc.com/docu44319_Atmos-Programmer's-Guide.pdf

表 48 サポート対象の 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 一覧可能なタグを取得

l x-emc-wschecksum ヘッダーはサポートされません。

l HTML フォームのアップロードはサポートされません。

l GET /rest/objects では、x-emc-accept の他のレスポンスタイプはサポートされま

せん。たとえば text/plain はサポートされません。

l オブジェクトの有効期間や保持はサポートされません。

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

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


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

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

方法パス説明

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

POST /rest/objects/<ObjectID>?versions オブジェクトのバージョン作成

DELETE /rest/objects/<objectID>?versions オブジェクトバージョンの削除

GET /rest/objects/<objectID>?versions オブジェクトバージョンの一覧

PUT /rest/objects/<objectID>?versions オブジェクトバージョンのリスト

ア

匿名アクセス

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

共有可能 URL

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

GET /rest/accesstokens/<token_id>?info アクセストークンの詳細を取得

DELETE /rest/accesstokens/<token_id> アクセストークンの削除

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

GET /rest/accesstokens/<token_id> 匿名でコンテンツをダウンロー

ド

x-emc-wschecksum カスタムヘッダーを使用したチェックサム保護はサポートされません。

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

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

API コール例

サブテナント作

成

PUT Http url: /rest/subtenant必要なヘッダー： x-emc-uid（たとえば、[email protected]）x-emc-signature

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

サブテナント削

除

DELETE Http url: /rest/subtenants/{subtenantID}必要なヘッダー： x-emc-uid（たとえば、[email protected]）x-emc-signature



API の拡張機能オブジェクト API の複数の拡張機能がサポートされています。



機能注

PUT Object (range-append)

範囲ヘッダーを使用して追加するオブジェクト範囲を指定します。







形式は以下のとおり。 Range: bytes=-1-



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 ヘッダーで返されます。




た。



第 9 部

REST API の使用

第 29 章, "ECS 管理 REST API の使用 "

REST API の使用 249

REST API の使用


第 29 章

ECS 管理 REST API の使用

l はじめに..............................................................................................................252l ECS 管理REST APIによる認証...............................................................................252l ECS 管理 REST API サマリー.................................................................................255

ECS 管理 REST API の使用 251

はじめに本稿では、ECS 管理 REST API へのアクセス方法と API による認証方法について説明し、API パスのサマリーを提供します。 ECS 管理 REST API を利用して、オブジェクトストアの構成と管理ができます。オブジェクトストアが構成されると、それ以降のオブジェクト作成、読み取り、更新、削除の操作は、サポートされている S3、EMC Atmos、OpenStack Swift オブジェクトプロトコルを使用して実行されます。

REST API へのアクセス方法と認証方法については、以下のトピックで説明します。

l ECS 管理REST APIによる認証（252 ページ）

API パスのサマリーが以下で提供されています。

l ECS 管理 REST API サマリー（255 ページ）

また、API リファレンスが以下で提供されています。

l ECS 管理 REST API リファレンス

ECS 管理 REST API リファレンスは、ソースコードから自動生成され、API で利用可能なメソッドのリファレンスを提供します。

ECS 管理REST APIによる認証

ECS は、すべての REST API コールにトークンベースの認証システムを使用します。 ECSREST API による認証（cookie あり/なし）の例について説明します。

ECS でユーザーが認証されると、認証トークンが返され、これを以後のコールの認証に使用できます。

l クライアントが自動でリダイレクトをフォローすると、HTTP 401 コードが返されます。これは、新しいトークンを取得するためにログインと認証が必要であることを示します。

l クライアントが自動でリダイレクトをフォローしない場合は、HTTP 302 コードが返されます。 302 コードでは、クライアントは再認証を行う場所にダイレクトされます。

認証トークンは次の方法で取得できます。

l 成功した認証リクエストの X-SDS-AUTH-TOKEN cookie を保存し、以後のリクエストでこの cookie を送信する。

l 成功した認証リクエストの X-SDS-AUTH-TOKEN HTTP ヘッダーを読み取り、このヘッダーを以後のリクエストにコピーする。

REST API はポート 4443 で使用でき、クライアントは次の形式でログインリクエストを発行して ECS にアクセスします。

https://<ECS_IP>:4443/login

ECS 管理 REST API リファレンスには、本稿で使用している REST API メソッドのパラメーターの説明と完全なリストがあります。

AUTH-TOKEN を使用した認証

この例では、認証トークンを使用する方法として、成功した認証リクエストから X-SDS-AUTH-TOKEN http ヘッダーを読み取り、以後のリクエストにそのヘッダーをコピーする形式を示します。この例では cookie は使用しません。この例は curl で作成され、見やすいように書式を整えてあります。

このコマンドは、/login リソースに GET を実行します。 -u オプションは、基本認証ヘッダーのユーザーを指定します。ユーザーの指定をリクエストに含める必要があります。認証が成






功すると、HTTP 200 コードが返され、エンコードされたトークンを含む X-SDS-AUTH-TOKENヘッダーも返されます。

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):

これで、トークンを次の API コールに渡すことができます。 curl の-H スイッチで X-SDS-AUTH-TOKEN の内容をコピーして次のリクエストに渡すことができます。

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 を渡す形式を示します。この例は curl で作成され、見やすいように書式を整えてあります。


cookie を使用した認証 253

この例では、?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

次のコマンドは、-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 は、セッションを終了します。

1 人のユーザーは、大 100 のコンカレント認証トークンを使用できます。この制限を超えると、トークンが解放されるまで、このユーザーの新しい接続は拒否されます。解放するには、自然に期限が切れるのを待つか、次の URI を明示的にコールします。

https://<ECS_IP>:4443/logout

複数のセッションを同時に実行している場合は、次の URI により、現在のユーザーに関連したすべてのトークンが終了します。

GET https://<ECS_IP>:4443/logout?force=true

ログアウトリクエストの例を次に示します。

リクエスト

GET https://<ECS_IP>:4443/logout

X-SDS-AUTH-TOKEN:{Auth_Token}

認証トークンを含むヘッダーまたは cookie で渡してログアウトします。

応答

HTTP 200

whoamiECS ユーザーは、whoami API コールを使用して、自分のユーザー名、テナント関連づけ、

役割を確認できます。



リクエスト

GET https://<ECS_IP>:4443/user/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>

この whoami の例は、ルートユーザーの出力と、「ns1」ネームスペースのNAMESPACE_ADMIN 役割が割り当てられたユーザーの出力を示しています。

ECS 管理 REST API サマリーECS 管理 REST API を利用して、ECS オブジェクトストアの構成と管理ができます。

また、他の ECS サービスを使用して、ECS オブジェクトストレージの使用をサポートできます。

次の表に ECS 管理 REST API の概要をまとめています。

表 51 ECS 管理 REST API：メソッドのサマリー

API エリア説明

AuthenticationProvider

/vdc/admin/authproviders認証プロバイダーを追加して管理するための API。

Billing /object/billingテナントレベルとバケットレベルでオブジェクトストアの使用状況を測定す

るための API。詳細についてはテナントの管理（84 ページ）を参照してくだ

さい。

Base URL /object/baseurl既存のアプリケーションと ECS オブジェクトストアの連携を可能にするベー

ス URL を作成するための API。ベース URL に関する詳細: .

Bucket /object/bucketバケットのプロビジョニングと管理のための API。


ECS 管理 REST API サマリー 255

表 51 ECS 管理 REST API：メソッドのサマリー（続き）

API エリア説明

/object/bucket/{bucketName}/lockバケットのアクセスをロックするための API。詳細についてはテナントの管

理（84 ページ）を参照してください。

Call Home /vdc/callhome/ConnectEMC を構成して ConnectEMC のアラートイベントを作成するため

の API。

Capacity /object/capacity現在の管理対象容量を取得するための API。

CAS /object/user-casCAS ユーザーへの秘密キーの割り当てと PEA（Pool Entry Authorization）ファイルの生成を行うための API。

Certificate /object-cert証明書を管理するための API。

/object-cert/keystoreEMC で使用される証明書チェーンを指定して証明書をローテーションする

ための API。

ConfigurationProperties

/config/object/propertiesユーザースコープを GLOBAL または NAMESPACE として設定するための

API。

GLOBAL スコープでは、ユーザーはグローバルとなり、ネームスペース間

で共有が可能です。この場合、ユーザーに関連づけられたデフォルトのネ

ームスペースによってオブジェクト操作のネームスペースが決まるため、

操作のためのネームスペースを指定する必要はありません。ユーザースコープが NAMESPACE の場合は、ユーザーはネームスペースに関連づけ

られます。そのため、異なるネームスペースに関連づけられた同じ名前の

ユーザーが複数存在する可能性があります。 NAMESPACE モードでは、す

べての操作にネームスペースを指定する必要があります。

初のユーザーを作成する前に、これを設定する必要があります。デフォ

ルトは GLOBAL です。

Data Store /vdc/data-storesファイルシステム（/vdc/data-stores/filesystems）またはコ

モディティノード（/vdc/data-stores/commodity）でデータスト

アを作成するための API。

Licensing /licenseライセンスを追加してライセンスの詳細を取得するための API。

Monitoring(Dashboard)

/dashboardシステム情報を取得してダッシュボードに表示するための API。




API エリア説明

Monitoring (Events) /vdc/events監査アラートを取得するための API。

Namespace /object/namespacesネームスペースを作成して管理するための API。

ネームスペースの保存期間の設定もできます。詳細についてはテナント

の管理（84 ページ）を参照してください。

Node /vdc/nodes現在クラスターに構成されているノードを取得するための API。

Password Group(Swift)

/object/user-passwordOpenStack Swift 認証で使用するパスワードを生成するための API。

Replication Group /data/data-service/vpoolsレプリケーショングループを作成して管理するための API。

Secret Key /object/user-secret-keysオブジェクトユーザーへの秘密キーの割り当てと秘密キーの管理を行うた

めの API。

Secret Key Self-Service /object/secret-keysS3 ユーザーが新しい秘密キーを作成するための API。これにより、オブジ

ェクトストアにある自分のネームスペース内のオブジェクトやバケットにア

クセス可能になります。

Storage Pool /vdc/data-services/varraysストレージプールを作成して管理するための API。

Temporary Failed Zone /tempfailedzone/すべての一時障害ゾーン、または指定したレプリケーショングループの一

時障害ゾーンを取得するための API。

User (Object) /object/usersオブジェクトユーザーを作成して管理するための API。オブジェクトユーザ

ーは常にネームスペースに関連づけられます。この API は、S3 アクセス

に使用できる秘密キーを返します。 S3 秘密キーを割り当てられたオブジェ

クトユーザーは、REST API を使用してそのキーを変更できます。

/object/users/lock。ユーザーアクセスをロックするための API。

User (Management) /vdc/users管理ユーザーを作成して管理するための API。管理ユーザーには、システ

ム管理者の役割かネームスペース管理者の役割を割り当てることができ

ます。ローカル管理ユーザーパスワードを変更できます。

Virtual Data Center /object/vdcs


ECS 管理 REST API サマリー 257


API エリア説明

VDC を追加し、その中間 VDC エンドポイントと秘密キーを ECS サイト間の

データレプリケーションに指定するための API。



第 10 部

ハードウェアの保守

第 30 章, "ECS ハードウェア"

第 31 章, "U シリーズアプライアンスの ECS ストレージディスクの交換"

第 32 章, "サードパーティ製ハードウェアの ECS ストレージディスクの交換"

第 33 章, "U シリーズアプライアンスへの 60 ディスクアップグレードの追加"

第 34 章, "ECS サードパーティラック要件"

ハードウェアの保守 259

ハードウェアの保守


第 30 章

ECS ハードウェア

l ECS アプライアンスのハードウェアコンポーネント................................................ 262l ECS アプライアンスの構成とアップグレードパス...................................................265l U シリーズの単相 AC 電源のケーブル接続 ......................................................... 268l U シリーズの三相 AC 電源のケーブル接続.......................................................... 269l スイッチ...............................................................................................................273l ネットワークケーブル接続...................................................................................275l ノード.................................................................................................................. 276l ラックとノードのホスト名.......................................................................................280l ディスクドライブ.................................................................................................. 281l 内蔵ディスクドライブ........................................................................................... 281l ディスクおよびエンクロージャ...............................................................................282

ECS ハードウェア 261

ECS アプライアンスのハードウェアコンポーネントECS アプライアンスハードウェアモデルを構成するハードウェアコンポーネントについて説明します。

ECS アプライアンスシリーズ

ECS アプライアンスには、2 つのシリーズがあります。

l U シリーズ：ストレージ容量を大化するように設計された別個の DAE（ディスクアレイエンクロージャ）が付属した非構造化ストレージサーバー

l C シリーズ：コンピューティング容量を大化するように設計された内蔵ディスクを搭載した高密度コンピューティングサーバー

U シリーズ

U シリーズ ECS アプライアンスには、以下のハードウェアコンポーネントが含まれます。

表 52 ECS アプライアンス： U シリーズのハードウェアコンポーネント

コンポーネント説明

40U ラック EMC Titan D ラックには以下が含まれます。

l 単相 PDU と 4 個の電源スロット（各側 2 個ずつ）

l オプションの三相 WYE またはデルタ PDU と 2 個の電源スロ

ット（各側 1 個ずつ）

l 前面ドアと背面ドア

l EMC マニュファクチャリングによってラック済み

プライベートスイッチ 1 個の 1 GbE スイッチ

パブリックスイッチ 2 個の 10 GbE スイッチ

ノード 4 および 8 ノード構成の Intel ベース非構造化サーバー

DAE（ディスクアレイエンクロー

ジャ）

大 60 台の 6 TB 3.5 インチディスクドライブを搭載可能な DAE（ディスクアレイエンクロージャ）ドロワー



図 50 U シリーズ ECS アプライアンスの小構成と大構成

C シリーズ

C シリーズ ECS アプライアンスには、以下のハードウェアコンポーネントが含まれます。

表 53 ECS アプライアンス： C シリーズのハードウェアコンポーネント


40U ラック EMC Titan D コンピューティングラックには以下が含まれます。

l 4 個の水平電源スロット

l 2 個の 2U 構成単相 PDU と 2 個の電源スロット

l オプションの 2 個の三相 WYE または 2U 構成デルタ PDU と

2 個の電源スロット

l 前面ドアと背面ドア

l EMC マニュファクチャリングによってラック済み


ECS アプライアンスのハードウェアコンポーネント 263

表 53 ECS アプライアンス： C シリーズのハードウェアコンポーネント（続き）


プライベートスイッチ 1 個または 2 個の 1 GbE スイッチ。 2 個目のスイッチには、6 台

超のサーバーによる構成が必要です。

パブリックスイッチ 2 個または 4 個の 10 GbE スイッチ。 3 個目と 4 個目のスイッチ

には、6 台超のサーバーによる構成が必要です。

ノード 8～48 ノード構成の Intel ベース非構造化サーバー

ディスク各サーバーにつき 12 台の 6 TB 3.5 インチディスクドライブを内

蔵

図 51 C シリーズ ECS アプライアンスの小構成と大構成

お客様は、10 GbE ポートとお客様提供の相互接続ケーブルを使用して ECS アプライアンスに接続します。同じデータセンターに複数のアプライアンスがインストールされている場合は、デイジーチェーンまたはホームラン接続によってプライベートスイッチをお客様提供のスイッチに接続できます。



ECS アプライアンスの構成とアップグレードパス使用可能な ECS アプライアンスの構成と、構成間のアップグレードパスについて説明します。

U シリーズの構成

U シリーズの ECS アプライアンスは、コモディティハードウェアを使用した高密度のストレージソリューションです。

表 54 U シリーズの構成

モデル番号ノード DAE DAE 1～4 のディスク数

DAE 5～8 のディスク数

ストレージ容量

スイッチ

U300（小

構成）

4 4 15 該当せず 360TB プライベート

×1、パブリッ

ク×2

U700 4 4 30 該当せず 720 TB プライベート

×1、パブリッ

ク×2

U1100 4 4 45 該当せず 1,080 TB プライベート

×1、パブリッ

ク×2

U1500 4 4 60 該当せず 1,440 TB プライベート

×1、パブリッ

ク×2

U1800 8 8 60 15 1,800 TB プライベート

×1、パブリッ

ク×2

U2100 8 8 60 30 2,160 TB プライベート

×1、パブリッ

ク×2

U2500 8 8 60 45 2,520 TB プライベート

×1、パブリッ

ク×2

U3000（大

構成）

8 8 60 60 2,880 TB プライベート

×1、パブリッ

ク×2

U シリーズのアップグレードパス

U シリーズのアップグレードは、既存のモデル番号からすぐ上のモデル番号への移行に必要なディスクとインフラストラクチャハードウェアで構成されています。それ以上のモデルレベルにアップグレードするには、各レベルのアップグレードをオーダーし、サービスコールでそれらを適用してください。


ECS アプライアンスの構成とアップグレードパス 265

表 55 U シリーズのアップグレード

モデル番号ディスクのアップグレード（すぐ下のモデルから）

ハードウェアのアップグレード（すぐ下のモデルから）

U300（小構

成）

該当せず該当せず

U700 60 ディスクキット×1 該当せず



U1800 60 ディスクキット×1 サーバーシャーシ（4 ノード）×1 と

DAE×4



U3000（大構

成）

60 ディスクキット×1 該当せず

C シリーズの構成

C シリーズの ECS アプライアンスは、コモディティハードウェアを使用した高密度のコンピューティングソリューションです。

表 56 C シリーズの構成

Phoenix-12 コンピューティングサーバー

ノードストレージ容量スイッチ

2（小構成） 8 144 TB プライベート×1、パブリック×2

3 12 216 TB プライベート×1、パブリック×2


5 20 360TB プライベート×1、パブリック×2








表 56 C シリーズの構成（続き）


ノードストレージ容量スイッチ


12（大構成） 48 864 TB プライベート×2、パブリック×4

C シリーズのアップグレードパス

C シリーズのアップグレードは、既存のモデル番号からすぐ上のモデル番号への移行に必要なディスクとインフラストラクチャハードウェアで構成されています。それ以上のモデルレベルにアップグレードするには、各レベルのアップグレードをオーダーし、サービスコールでそれらを適用してください。

表 57 C シリーズのアップグレード

モデル番号ディスクのアップグレード（すぐ下のモデルから）

ハードウェアのアップグレード（すぐ下のモデルから）


×2（小構成）

該当せず該当せず


×3内蔵ディスク×12 サーバーシャーシ（4 ノード）×1








×7内蔵ディスク×12 サーバーシャーシ（4 ノード）×1、

プライベートスイッチ×1、パブリッ

クスイッチ×2










×12（大構成）

内蔵ディスク×12 サーバーシャーシ（4 ノード）×1


ECS アプライアンスの構成とアップグレードパス 267

U シリーズの単相 AC 電源のケーブル接続U シリーズ ECS アプライアンスの単相電源ケーブル接続図を示します。

各構成では、スイッチがラック前面に差し込まれ、レールを通って背面に配線されています。

図 52 4 ノード構成の U シリーズ単相 AC 電源ケーブル接続図



図 53 8 ノード構成の U シリーズ単相 AC 電源ケーブル接続図

U シリーズの三相 AC 電源のケーブル接続三相 AC 電源ケーブル接続図を示します。

U シリーズの三相デルタ AC 電源のケーブル接続

次の凡例は、図に示された色付きケーブルの EMC パーツ番号とケーブル長を示しています。


U シリーズの三相 AC 電源のケーブル接続 269

図 54 三相デルタ AC 電源図のケーブルの凡例



図 55 8 ノード構成の三相デルタ AC 電源ケーブル接続


U シリーズの三相 AC 電源のケーブル接続 271

三相 WYE AC 電源ケーブル接続

次の凡例は、図に示された色付きケーブルの EMC パーツ番号とケーブル長を示しています。

図 56 三相 WYE AC 電源図のケーブルの凡例



図 57 8 ノード構成の WYE AC 電源ケーブル接続

スイッチECS アプライアンスには、次のスイッチがあります。

l プライベートスイッチ：管理トラフィックを処理するための 1 GbE プライベートスイッチ×1。 6 台を超えるコンピューティングサーバーが格納された C シリーズラックには、2 個目のプライベートスイッチが追加されています。

l パブリックスイッチ：データトラフィックを処理するための 10 GbE スイッチ×2。 2 つのArista モデルを使用できます。 6 台を超えるコンピューティングサーバーが格納されたC シリーズラックには、2 個のパブリックスイッチが追加されています。


スイッチ 273

プライベートスイッチ： Arista 7048プライベートスイッチは、管理トラフィックのために使用されます。 48 個のポートと、デュアル電源（入力）を備えています。このスイッチは、工場出荷時に構成されます。

図 58 Arista 7048 の構成

1. ポート 1～24：管理

2. ポート 25～48：RMM/IPMI

3. ポート 49～50：10 GbE パブリックスイッチへの管理接続

4. ポート 51：NAN 接続。初のラックでは、RMM へのアクセスが必要な場合にこのポートがお客様のネットワークへのアップリンクを提供します。

5. ポート 52：NAN 接続。初のラックのポート 52 は、次のラックのポート 51 に接続します。以降同様に、ECS サイトのすべてのラックに接続します。

NAN は、サイトのすべての ECS アプライアンスをリンクします。

パブリックスイッチ： Arista 7150S-247150S-24 スイッチは、24 ポートスイッチです。このスイッチには、SFP+ポート 24 個、ホットスワップ可能なデュアル電源、フィールド交換可能な冗長ファンモジュールが搭載されています。

図 59 Arista 7150S-24

1. ポート 1～8：カスタマーアップリンク



2. ポート 9～12：データ用ポートとしてノードに接続

3. ポート 13～20：データ用ポートとしてノードに接続

4. ポート 21～22：パブリックスイッチ間の MLAG インターフェイス用に相互接続

5. ポート 23～24：パブリックスイッチ間の MLAG インターフェイス用に相互接続

6. スイッチ管理 1 ネットワークインターフェイス

7. シリアルコンソール：シリアル接続でスイッチを管理するために使用されるコンソールポート。Ethernet 管理ポートは、1 GbE 管理スイッチに接続されます。

パブリックスイッチ： Arista 7124SXArista 7124SX スイッチには、SFP+ポート 24 個、ホットスワップ可能なデュアル電源、フィールド交換可能な冗長ファンモジュールが搭載されています。

図 60 Arista 7124SX

1. ポート 1～8：カスタマーアップリンクデータ用ポート。これらのポートはユーザーの 10GbE インフラストラクチャへの接続に使用されます。

2. ポート 9～20：ノードに接続されるデータ用ポート

3. ポート 21～22：パブリックスイッチ間の MLAG インターフェイスの HA 相互接続用

4. ポート 23～24：パブリックスイッチ間の MLAG インターフェイスの HA 相互接続用

5. スイッチ管理 1 ネットワークインターフェイス

6. シリアルコンソール

ネットワークケーブル接続ECS アプライアンスのパブリックスイッチとプライベートスイッチのネットワークケーブル接続図を示します。

このネットワークケーブル接続図は、ECS アプライアンスの U シリーズと C シリーズの両方に該当します。

マニュアル内で 3 個のスイッチを区別するために、各スイッチには次のようなニックネームが付けられています。

l Hare：ラック上部にある 10 GbE パブリックスイッチ。

l Rabbit： Hare の下にある 2 つ目の 10 GbE パブリックスイッチ。

l Turtle： Rabbit の下にある 1 GbE プライベートスイッチ。


パブリックスイッチ： Arista 7124SX 275

図 61 4 ノードのパブリックスイッチケーブル接続

図 62 4 ノードのプライベートスイッチケーブル接続

ノードECS アプライアンスには、次のタイプのノードがあります。

l U シリーズ Phoenix-16：オブジェクトおよび HDFS 向け（2014 年 6 月）

l C シリーズ Phoenix-12：オブジェクトおよび HDFS 向け（2014 年 12 月）

U シリーズノードには、次の標準機能が搭載されています。



l 4 ノードサーバー（2U）、各ノードに 2 個の CPU

l 2.4 GHz 4 コア Intel Ivy Bridge CPU

l 4 チャネルのネイティブ DDR3（1333）メモリ

l 各ノードに 1 台または 2 台のシステムディスク

l 各ノードに複数の LED インジケーター

l ホットスワップ可能なデュアルシャーシ電源

l 各ノードに 2 個の SAS インターフェイス

C シリーズノードには、次の標準機能が搭載されています。

l 4 ノードサーバー（2U）、各ノードに 2 個の CPU

l 2.4 GHz 4 コア Intel Ivy Bridge CPU

l 4 チャネルのネイティブ DDR3（1333）メモリ

l 各ノードに 1 台のシステムディスク

l 各ノードに複数の LED インジケーター

l ホットスワップ可能なデュアルシャーシ電源。 N+1 電源をサポート

l 各ノードに 1 個の SAS インターフェイス

l 各サーバーに 12 台のホットスワップ可能な 3.5 インチ SAS ハードドライブ（各ノードに3 台）

サーバーの前面図

図 63 U シリーズシャーシの前面

図 64 C シリーズシャーシの前面

LED インジケーターは、サーバーフロントパネルの左側と右側にあります。


サーバーの前面図 277

図 65 LED（左側）

表 58 サーバー LED

LED 用途説明

A LED 付きシステム電源ボタン

B システム ID LED ボタン複数のサーバーがある場合に、当該サーバーを

識別するために使用されます。デフォルトではオ

フになっています。ボタン操作またはソフトウェア

によってアクティブ化されると、青色になります。

C システムステータス LED 全体的なシステムの稼働状態を示します（緑色、

緑色の点滅、アンバーの点滅、アンバー、オ

フ）。

D ネットワークリンク/アクティビテ

ィ LED

サーバーの背面図

Phoenix-16（U シリーズ）と Phoenix-12（C シリーズ）のサーバーシャーシには、ホットスワップ可能なデュアル電源と 4 個のノードが搭載されています。このシャーシには、各シャーシの HA 電源をすべてのノードで共有することを可能にする CRPS（Common RedundantPower Supply）が搭載されています。これらのノードはホットスワップ可能なトレイに取り付けられており、トレイは、サーバーの背面からアクセス可能な、対応する 4 つのノードスロットにぴったり収まるようになっています。



図 66 Phoenix-12 と Phoenix-16 のサーバーシャーシの背面図

1. ノード 1

2. ノード 2

3. ノード 3

4. ノード 4

図 67 Phoenix-12 と Phoenix-16 のノードの背面ポート

1. 1 GbE：いずれかの 1 GbE スイッチデータ用ポートに接続

2. RMM：（各ノードで）ハードウェアをモニタリングするための専用ポート

3. SAS から DAE（Phoenix-16 のみで使用）

4. 10 GbE（プライマリ）：各ノードの右側の 10 GbE データ用ポートは、10 GbE スイッチのいずれかのプライマリデータ用ポートに接続

5. 10 GbE（セカンダリ）：各ノードの左側の 10 GbE データ用ポートは、10 GbE スイッチのいずれかのセカンダリデータ用ポートに接続


サーバーの背面図 279

ラックとノードのホスト名ECS アプライアンスのデフォルトのラックおよびノードホスト名の一覧は、以下のとおりです。

デフォルトのラック ID と色は、次のようにインストール順に割り当てられています。

表 59 ラック ID 1～50

ラック ID ラックの色ラック ID ラックの色ラック ID ラックの色

1 red 18 carmine 35 cornsilk

2 green 19 auburn 36 ochre

3 blue 20 bronze 37 lavender

4 yellow 21 apricot 38 ginger

5 magenta 22 jasmine 39 ivory

6 cyan 23 army 40 carnelian

7 azure 24 copper 41 taupe

8 violet 25 amaranth 42 navy

9 rose 26 mint 43 indigo

10 orange 27 cobalt 44 veronica

11 chartreuse 28 fern 45 citron

12 pink 29 sienna 46 sand

13 brown 30 mantis 47 russet

14 white 31 denim 48 brick

15 gray 32 aquamarine 49 avocado

16 beige 33 baby 50 bubblegum

17 silver 34 eggplant

ノードのホスト名は、サーバーシャーシ内およびラック内での並び方に基づいて割り当てられます。次の表に、デフォルトのホスト名を示します。

表 60 デフォルトのホスト名

ノード

Host name ノード Host name ノード Host name

1 provo 17 memphis 33 tampa

2 sandy 18 seattle 34 toledo

3 orem 19 denver 35 aurora

4 ogden 20 portland 36 stockton

5 layton 21 tucson 37 buffalo

6 logan 22 atlanta 38 newark



表 60 デフォルトのホスト名（続き）

ノード

Host name ノード Host name ノード Host name

7 Lehi 23 fresno 39 glendale

8 murray 24 mesa 40 lincoln

9 boston 25 omaha 41 norfolk

10 chicago 26 oakland 42 chandler

11 houston 27 miami 43 madison

12 phoenix 28 tulsa 44 orlando

13 dallas 29 honolulu 45 garland

14 detroit 30 wichita 46 akron

15 columbus 31 raleigh 47 reno

16 austin 32 anaheim 48 laredo

サイトの別のラックの同じスロットに配置されているノードは、同じホスト名になります。たとえば、デフォルトのノード名を使用する場合、ノード 4 は常に ogden という名前になります。

システムの出力では、ノードのホスト名とラック名の一意の組み合わせでノードが特定されます。たとえば、ラック 4 のノード 4 とラック 5 のノード 4 は次のように識別されます。

ogden-greenogden-blue

ディスクドライブECS アプライアンスで使用されるディスクドライブについて説明します。

ECS アプライアンスは、ストレージ用に次のディスクドライブを使用します。

表 61 ストレージディスクドライブ

サービスサイズ RPM タイプ

オブジェクト 6 TB 7200 SATA

DAE 内のディスクまたはサーバーシャーシに内蔵されているディスクはすべて、次のルールに従う必要があります。

l すべてのディスクドライブが同じサイズである

l すべてのディスクドライブが同じ速度である

内蔵ディスクドライブサーバーシャーシに内蔵されているストレージディスクについて説明します。

内蔵ディスクのあるサーバーでは、ディスクにはサーバーシャーシの前面からアクセスできます。ディスクはシャーシ内の 4 個のノードに均等に割り当てられています。


ディスクドライブ 281

各ノードに初に割り当てられたディスクドライブは、ディスクドライブ 0（HDD0）と呼ばれま

す。これらのストレージドライブには、一部のシステムデータが保存されます。そのため、

ディスクドライブ 0 は通常はリプレースできません。リプレースするには、EMC のカスタマー

サポートに連絡する必要があります。

図 68 内蔵ディスクとノードマッピング

ディスクおよびエンクロージャU シリーズには、DAE（ディスクアレイエンクロージャ）が搭載されています。この DAE は、40U 高密度ラックからスライドして出し入れする引き出し型です。 DAE のディスクドライブ、LCC、冷却モジュールは、DAE 内部に配置されています。 DAE には、次の機能があります。

l 単一の 4U ドロワーに 15、30、45、60 台の 3.5 インチディスクドライブ（前面から点検修理）

l LCC（リンクコントロールカード）×1 （前面から点検修理）

l ICM（相互接続モジュール）×1 （背面から点検修理）

l ファンまたは冷却モジュール×3、N+1 冗長（前面から点検修理）

l 電源×2、N+1 冗長（背面から点検修理）

C シリーズサーバーには、内蔵ディスクが搭載されています。 12 台の 3.5 インチディスクドライブで、サーバーの前面からアクセスできます。

DAE のディスクドライブ

ディスクドライブは、カートリッジ型のエンクロージャに収納されています。各カートリッジにはラッチが付いており、ディスクドライブの取り付けと取り外しが簡単にできるようになっています。

各 DAE の内部には、印刷されたラベルが DAE の左側と前側にあります。これらのラベルは、ディスクドライブがインストールされている DAE の行（バンク）と列（スロット）を示します。

バンクは A～E、スロットは 0～11 のラベルが付けられています。DAE 内のディスクドライブのレイアウトを説明する場合、DAE のインターフェイス形式は E_D と呼ばれます。つまり、Eはエンクロージャを、D はディスクを示します。たとえば、1_B11 というインターフェイス形式があります。この形式は、エンクロージャ 1、行（バンク）B、スロット番号 11 と解釈されます。

エンクロージャは、ラックの下部から 1～8 の番号が付けられます。背面のケーブルは色分けされています。

DAE のディスクドライブの構成は、以下の図に示す規定のレイアウトと一致している必要があります。

以下の図は、DAE を前面上方から見た場合の DAE のディスクドライブのレイアウトです。



図 69 U シリーズのディスクレイアウト：15 ディスク構成


DAE のディスクドライブ 283



DAE のディスクドライブ 285


LCC各 DAE には、ホットスワップ対応の LCC が付属しています。LCC の主な機能は SAS エクスパンダーであり、エンクロージャサービスを提供します。 LCC は、それぞれ独立してエンクロージャ全体の環境ステータスをモニタリングし、システムに結果を送信します。 LCC には、障害 LED と電源 LED が 1 個ずつ付属しています。

表 62 DAE LCC ステータス LED

LED 色状態説明

電源緑色オン電源オン

– オフ電源オフ

電源障害アンバーオン障害

– オフ障害なし、または電源オフ



図 73 LCC と LED

ファンコントロールモジュール

各 DAE は、DAE の正面に配置された 3 つのファンコントロールモジュール（冷却モジュール）を搭載しています。ファンコントロールモジュールは、各 DAE の冷却容量を強化します。このモジュールは、DAE の上部から DAE ベースボードに直接差し込みます。ファンコントロールモジュール内部では、センサーによって DAE 全体が均等に冷却されるように、外気温が測定されます。

表 63 ファンコントロールモジュールファン障害 LED

LED 色状態説明

ファン障害アンバー – オン障害が検出されました。 1 つ以上のファンに障害があります。

オフ障害は検出されていません。ファンは正常に動作しています。

図 74 ファンコントロールモジュールと LED

ICMICM は主要な相互接続管理エレメントです。これには、USB コネクタ、RJ-12 管理アダプタ、バス ID インジケーター、エンクロージャ ID インジケーター、2 つの入力 SAS コネクタと 2 つ


ファンコントロールモジュール 287

の出力 SAS コネクタを含むプラグインモジュールが含まれています。SAS コネクタは、入力デバイスと出力デバイスの SAS コネクタのリンクとアクティビティを示す対応する LED を備えています。

表 64 ICM バスステータス LED

LED 色状態説明

電源障害緑色オン電源オン

– オフ電源オフ

電源オンアンバーオン障害

– オフ障害なし、または電源オフ

ICM は、背面で以下の I/O ポートをサポートします。

l 6 Gb/秒 PCI Gen 2 SAS ポート×4

l SPS への管理（RJ-12）コネクタ（フィールドサービス診断のみ）×1

l USB コネクタ×1

l 6 Gb/秒 SAS x8 ポート

これは、ICM の背面で、4 つ（2 つは入力、2 つは出力、1 つを使用）の 6 Gb/秒 SAS x8 ポートをサポートします。このポートは、DAE の SAS ドライブおよび NL-SAS ドライブ用のインターフェイスを提供します。

表 65 ICM 6 Gb/秒ポート LED

LED 色状態説明

リンク/アクティ

ビティ

青色オン 6 Gb/秒で動作するすべてのレーンとの 4x また

は 8x 接続を示します。

緑色オン 4x または 8x 以外の幅のワイドポートが確立さ

れていること、または 1 つ以上のレーンが高

速度で動作していないか切断されていることを示

します。

– オフ接続されていません。



図 75 ICM の LED

1. 電源障害 LED（アンバー）

2. 電源 LED（緑）

3. リンクアクティビティ LED（青/緑）

DAE の電源

電源はホットスワップ可能です。つまみネジが組み込まれていて、簡単に取り付けと取り外しができます。各電源は、電源を冷却するファンを搭載しています。電源は、自動認識、力率補正、マルチ出力機能をサポートした専用ラインコード付きオフラインコンバータです。各電源は、フル構成の DAE をサポートし、負荷電流を他の電源と共有します。 DAE では、電源装置は独立した 4 つの電力ゾーンに供給します。ホットスワップ可能な電源装置には、負荷分散高可用性構成において 12 V で 1300 W を供給する能力があります。コントロールとステータスは、I2C インターフェイスを通じて実装されます。

表 66 DAE AC 電源/冷却モジュール LED

LED 色状態説明

AC 電源オン

（12 V 電源）：

緑色オン問題ありません。 AC または SPS 電源が供給さ

れています。すべての出力電圧は、それぞれの


DAE の電源 289

表 66 DAE AC 電源/冷却モジュール LED （続き）

LED 色状態説明

電源コードごと

に 1 個の LED稼働範囲内にありますが、ファン障害は含まれ

ません。

– オフ 12 V 電源は稼働範囲外またはシャットダウン状

態にあるか、ユニット内で障害が検出されていま

す。

電源障害アンバーオン ICM 制御下にあります。ユニットが省電力モード

ではないときに、ファンまたは出力が指定された

動作範囲外にある場合に点灯します。

– オフすべての出力が指定範囲内またはシャットダウ

ン状態にあるか、ユニット内で障害が検出されて

います。

図 76 DAE の電源



U シリーズの SAS ケーブル接続

ノードを DAE に接続する SAS ケーブルの配線図を示します。

ハードウェア図では、ノード番号は 0 から始まっています。 ECS のアーキテクチャとソフトウ

ェアについての他の説明では、ノード番号は 1 から始まっています。


U シリーズの SAS ケーブル接続 291

図 77 4 ノード構成の SAS ケーブル接続



図 78 8 ノード構成の SAS ケーブル接続


U シリーズの SAS ケーブル接続 293

第 31 章

U シリーズアプライアンスの ECS ストレージディスクの交換

l ドライブ交換の計画............................................................................................. 296l cs_hal list disks コマンドの出力結果................................................................... 296l ドライブの交換.................................................................................................... 297

U シリーズアプライアンスの ECS ストレージディスクの交換 295

ドライブ交換の計画ECS アプライアンスを定期的にグルーミングして FAILED および SUSPECT のストレージドライブを交換する効率的な戦略について説明します。

ノードのメインのドライブ（ストレージドライブではなく）を交換する場合は、EMC カスタマー

サポートに連絡し支援を受けてください。

このドキュメントでは、「ドライブ」と「ディスク」を区別しています。ドライブとは、物理スピンドルのことです。ディスクとは、論理エンティティのことです（つまりドライブ上のパーティションです）。

システムがドライブを FAILED と表示している場合は、データ保護ロジックにより、そのドライブのデータがシステム内の他のドライブ上に再構築されます。それ以降は、その FAILED ドライブがシステムに参加することはできません。ドライブの交換には、交換用ドライブにデータをリストアする作業は含まれません。そのため、FAILED ドライブは、システムに対するraw 容量の損失のみを表しています。組み込み型のデータ保護の特性により、ドライブが故障した場合の緊急のサービスアクションの必要性が低減されています。

接続の問題ではなく物理的エラーのために故障が疑われる SUSPECT ドライブも、交換する必要があります。ドライブが SUSPECT と表示されている場合、それ以降システムはそのドライブにデータの書き込みを行いませんが、システムはそこからの読み取りは継続して行います。物理的エラーがある SUSPECT ドライブは、物理的エラーが特定の閾値を超えれば、

終的には FAILED と表示されます。ドライブが SUSPECT にとどまる間は、そのドライブはストレージシステムに完全には参加しません。したがって、提供されている cs_hwmg コマンドラインツールを使用して、該当するドライブのディスクを手動で［Bad］に設定する必要があります。この手順により、そのドライブとの間で保留状態にあるネットワーク上の連携を、システムが終了する機会を提供します。そのドライブ上のデータは、他のドライブからのそのデータのコピーを使って、システムの別の場所に再構築されます。そのため、該当するFAILED ドライブ上のディスクが問題なく BAD に設定されたことがシステムに表示されれば、すぐに交換プロセスを始められます。

ViPR UI は、ノードに SUSPECT または BAD のステータスのストレージディスクがある場合、

ノードを DEGRADED と表示します。

FAILED ドライブを処理する効率的な方法は、定期的に交換することです。交換時期は、そのドライブに関する製造業者の平均故障率を使って計算し、次のサービス予定日までに致命的な数のドライブが故障する危険性がないようにする必要があります。このプロセスは「グルーミング」と呼ばれます。グルーミングには次のものが含まれます。

l 次のサービス予定日までに予想される平均故障率への対処に十分な数のドライブの発注。

l FAILED ドライブの特定。

l 物理的エラーのため故障が疑われる SUSPECT ドライブの特定、および該当するディスクの手動での BAD 表示への強制変更。

l FAILED ドライブの交換。

cs_hal list disks コマンドの出力結果

cs_hal list disks コマンドの出力行の種類を説明します。



cs_hal list disks と略された後に示す出力結果の中に、さまざまな種類の行がある

のでご覧ください。

l 初の 3 行は、ノードの 2 台の内蔵ドライブの RAID 構造を示しています。

l 次の行は、状態の良いストレージドライブを示しています。デバイス名、スロット番号、シリアル番号は、一意であれば cs_hal コマンドで使用できます。エンクロージャー名

も cs_hal コマンドで使用できます。

l 次の行は、障害が発生したストレージドライブを示しています。［Partition Name］は、対応するドライブのディスクがオブジェクトサービスに割り当てられ、ディスクがフォーマット済みで、ディスク状態に問題があることを示しています。

l 次の行は、状態が疑われるストレージドライブを示しています。疑わしい状態に該当するドライブのディスクは、稼働状態の悪化が疑われます。

l 後の行は、空のスロットか、検出できないドライブを示しています。

l ［SMART Status］列で、ドライブの稼働状態を確認します。

［Partition Name］列に示された状態は無視してください。その情報は、この手順には必

要ありません。その他の理由でパーティションの状態を知りたい場合は、cs_hwmgrdisk --list-by-service Object コマンドを使用すると、パーティションの状態

に関する新の正確な情報が［Health］列に示されます。

l DiskSet 列は、将来の使用のために予約されています。

[root@layton-cyan ~]# cs_hal list disksDisks(s):SCSI Device Block Device Enclosure Partition Name Slot Serial Number SMART Status DiskSet----------- ------------ ----------- ----------------------------------- ---- ------------------- -------------- ------------n/a /dev/md0 RAID vol n/a n/a not supported n/a/dev/sg4 /dev/sdb internal 0 KLH6DHXJ GOOD/dev/sg5 /dev/sdc internal 1 KLH6DM1J GOOD/dev/sg8 /dev/sdf /dev/sg0 Object:Formatted:Good A08 WCAW32601327 GOOD/dev/sg9 /dev/sdg /dev/sg0 Object:Formatted:Bad A09 WCAW32568324 FAILED: self-test fail; read element;/dev/sg10 /dev/sdh /dev/sg0 Object:Formatted:Suspect A10 WCAW32547329 SUSPECT: Reallocated_Sector_Count(5)=11...unavailable /dev/sg0 E05

internal: 2 external: 30

total disks: 32

ドライブの交換FAILED および SUSPECT ストレージドライブを交換するには、ノードにコマンド実行します。

ドライブの交換時にノードをメンテナンスモードにしないでください。


ドライブの交換 297

手順

1. 次のように、ラップトップからプライベート（192.168.219.xxx）ネットワークを使用して ECSラック（キャビネット）にアクセスします。

a. ラックの背面扉を開けて、1 GbE プライベートスイッチネットワークポートを見つけます。

b. ラップトップから Arista 1 GbE（Turtle）スイッチのポート 24 にネットワークケーブルを接続します。

図 79 プライベート 1 GbE スイッチのポート 24

c. ラップトップでネットワークインターフェイスを静的アドレス 192.168.219.99、サブネットマスク 255.255.255.0 に設定します。ゲートウェイは不要です。

d. ラップトップとラックのプライベート管理ネットワークの間の一時ネットワークが機能していることを確認するために、ping コマンドを使用します。

C:\>ping 192.168.219.1 Pinging 192.168.219.1 with 32 bytes of data:Reply from 192.168.219.1: bytes=32 time<1ms TTL=64Reply from 192.168.219.1: bytes=32 time<1ms TTL=64Reply from 192.168.219.1: bytes=32 time<1ms TTL=64Reply from 192.168.219.1: bytes=32 time<1ms TTL=64

Ping statistics for 192.168.219.1: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),Approximate round trip times in milli-seconds: Minimum = 0ms, Maximum = 0ms, Average = 0ms

192.168.219.1 から応答がない場合は、192.168.218.2 を試してください。どちらも

応答しない場合は、ラップトップの IP/サブネットマスク、ネットワーク接続、スイッチ

のポート接続を確認してください。

e. ラップトップから SSH を使用してノード 1（provo）にアクセスします。アドレスは192.168.219.1 で、ルートログイン認証情報（パスワードはデフォルトのものまたはお客様が変更したもの）を使用します。



2. cs_hal list disks コマンドを使用して、［SMART Status］列の各ドライブの稼働状

態ステータスを確認します。

# cs_hal list disksDisks(s):SCSI Device Block Device Enclosure Partition Name Slot Serial Number SMART Status DiskSet----------- ------------ ----------- ----------------------------------- ---- ------------------- -------------- ------------n/a /dev/md0 RAID vol n/a n/a not supported n/a/dev/sg4 /dev/sdb internal 0 KLH6DHXJ GOOD/dev/sg5 /dev/sdc internal 1 KLH6DM1J GOOD/dev/sg8 /dev/sdf /dev/sg0 Object:Formatted:Good A08 WCAW32601327 GOOD/dev/sg9 /dev/sdg /dev/sg0 Object:Formatted:Good A09 WCAW32568324 GOOD/dev/sg10 /dev/sdh /dev/sg0 Object:Formatted:Good A10 WCAW32547329 GOOD/dev/sg11 /dev/sdi /dev/sg0 Object:Formatted:Good B08 WCAW32543442 GOOD/dev/sg12 /dev/sdj /dev/sg0 Object:Formatted:Good B07 WCAW32499200 GOOD/dev/sg13 /dev/sdk /dev/sg0 Object:Formatted:Good B06 WCAW32540070 GOOD/dev/sg14 /dev/sdl /dev/sg0 Object:Formatted:Good A11 WCAW32493928 GOOD/dev/sg15 /dev/sdm /dev/sg0 Object:Formatted:Good B10 WCAW32612977 GOOD/dev/sg16 /dev/sdn /dev/sg0 Object:Formatted:Suspect B11 WCAW32599710 SUSPECT: Reallocated_Sector_Count(5)=11/dev/sg17 /dev/sdo /dev/sg0 Object:Formatted:Good C11 WCAW32566491 GOOD/dev/sg18 /dev/sdp /dev/sg0 Object:Formatted:Good D11 WCAW32528145 GOOD/dev/sg19 /dev/sdq /dev/sg0 Object:Formatted:Good C10 WCAW32509214 GOOD/dev/sg20 /dev/sdr /dev/sg0 Object:Formatted:Good D10 WCAW32499242 GOOD/dev/sg21 /dev/sds /dev/sg0 Object:Formatted:Good C09 WCAW32613242 GOOD/dev/sg22 /dev/sdt /dev/sg0 Object:Formatted:Good D09 WCAW32503593 GOOD/dev/sg23 /dev/sdu /dev/sg0 Object:Formatted:Good E11 WCAW32607576 GOOD/dev/sg24 /dev/sdv /dev/sg0 Object:Formatted:Good E10 WCAW32507898 GOOD/dev/sg25 /dev/sdw /dev/sg0 Object:Formatted:Good E09 WCAW32613032 GOOD/dev/sg26 /dev/sdx /dev/sg0 Object:Formatted:Good C08 WCAW32613016 GOOD/dev/sg27 /dev/sdy /dev/sg0 Object:Formatted:Good D08 WCAW32543718 GOOD/dev/sg28 /dev/sdz /dev/sg0 Object:Formatted:Good C07 WCAW32599747 GOOD/dev/sg29 /dev/sdaa /dev/sg0 Object:Formatted:Good E06 WCAW32612688 GOOD/dev/sg30 /dev/sdab /dev/sg0 Object:Formatted:Good E08 WCAW32567229 GOOD/dev/sg31 /dev/sdac /dev/sg0 Object:Formatted:Good D06 WCAW32609899 GOOD/dev/sg32 /dev/sdad /dev/sg0 Object:Formatted:Good C06 WCAW32546152 GOOD/dev/sg33 /dev/sdae /dev/sg0 Object:Formatted:Good D07 WCAW32613312 GOOD/dev/sg34 /dev/sdaf /dev/sg0 Object:Formatted:Good E07



WCAW32507641 GOOD/dev/sg3 /dev/sda /dev/sg0 Object:Formatted:Good A06 WCAW32547444 GOOD/dev/sg6 /dev/sdd /dev/sg0 Object:Formatted:Good A07 WCAW32525128 GOOD/dev/sg7 /dev/sde /dev/sg0 Object:Formatted:Good B09 WCAW32496935 GOOD……unavailable /dev/sg0 E02unavailable /dev/sg0 E03unavailable /dev/sg0 E04unavailable /dev/sg0 E05


total disks: 32

このレポートには、ノードの 2 台の内蔵ドライブ、30 台のストレージドライブ（そのうち 1台の稼働状態が SUSPECT）、使用不可と表示された 30 の空スロットが示されています。

上記のコマンドの出力にドライブのパーティション名が「Object:Formatted:Bad」または

「Object:Formatted:Suspect」と示され、SMART ステータスが「GOOD」である場合は、ここ

で手順を終了します。この状況は、ドライブの稼働状態を判断するときに例外をキャッチ

するハードウェアマネージャーのバグによるものです。 ECS のカスタマーサポートにお

問い合わせになり、問題を修正する回避策が実施されるのをお待ちください。それ以外

の場合は、次の手順に進みます。

ECS ポータルからディスク ID を取得した場合は、次のコマンドで grepを使用して、6 列

目のディスクのシリアル番号を確認します。この例では、シリアル番号は

AR31021EG62L9C です。

# cs_hwmgr disk --list-by-service Object | grep a1d7c15f-9995-4205-99b9-2267794d0154a1d7c15f-9995-4205-99b9-2267794d0154 ... AR31021EG62L9C ...

次に、cs_hwmgr drives --list コマンドで grep とシリアル番号を使用して、

後の列（6 列目）のスロット ID を確認します。この例では、スロット ID は A06 です。

# cs_hwmgr drives --list | grep AR31021EG62L9CATA HGST HUS726060AL AR31021EG62L9C 6001 Good A06

これで、手順に必要な情報が入手できました。

3. FAILED または SUSPECT ドライブのシリアル番号を書き留めます。

4. ターゲットドライブが SUSPECT の場合は、次の手順を実行します。

ドライブの SUSPECT 状態がハードウェアの問題によるものかを確認します。

l cs-hal コマンドの出力の［SMART Status］列に「reallocated_sector_count」データ

が表示される場合は、ドライブ交換の手順を続けます。このデータは、ハードウェアの問題を示します。

l 「reallocated_sector_count」データが表示されない場合は、ドライブ交換の手順を終了します。ドライブの SUSPECT 状態の原因はハードウェア以外の問題（接続の問題など）である可能性があります。



a. cs_hwmgr --list コマンドを使用して、初の 2 列でディスクの VendorId と

ProductID を確認します。

# cs_hwmgr drive --list | grep -i WCAW32599710 ATA HUS726060ALA640 WCAW32599710 6001 Suspect B11

cs_hwgmr drive --list | grep <disk SN#>コマンドで「Suspect」ドライブの出力が返され

ない場合は、ディスクがハードウェアマネージャーの管理対象になっていません。

ECS のカスタマーサポートにお問い合わせください。また、ナレッジベースの記事

197235 を参照してください。

b. cs_hwmgr drive --set-health-bad コマンドで<VendorID>、<ProductID>、<Disk SN#>の値を使用して、ドライブの稼働状態ステータスを「Bad」に設定します。

# cs_hwmgr drive --set-health-bad ATA HUS726060ALA640 WCAW32547329Setting drive health of ATA:HUS726060ALA640:WCAW32547329 to bad...Suceeded

c. cs_hwmgr drive --remove コマンドを使用して、ターゲットドライブ（具体的に

はドライブに関連づけられたディスク）を構成から削除します。このコマンドでは、cs_hwmgr drive --list コマンドの出力結果からドライブは削除されないので

注意してください。

# cs_hwmgr drive --remove ATA HUS726060ALA640 WCAW32599710Removing drive ATA:HUS726060ALA640:WCAW32547329...Suceeded

cs_hwmgr drive --remove コマンドが失敗する場合は、cs_hwmgr drive --force-remove コマンドで<VendorID>、<ProductID>、<Disk SN#>の値を使用しま

す。

5. ターゲットドライブが BAD の場合は、次の手順を実行します。

l cs_hwmgr drive --list コマンドの出力にドライブのシリアル番号が表示され

ない場合は、この手順をスキップします。

l cs_hwmgr drive --list コマンドで報告されたドライブ稼働状態が「Bad」の場

合は、以下の手順に進みます。

a. cs_hwmgr drive --remove コマンドを使用して、ターゲットドライブ（具体的に





す。



6. cs_hal led コマンドとシリアル番号を使用して、ドライブの LED を点滅させます（ドロ

アー内の該当ドライブを見つけるため）。

# cs_hal led WCAW32599710 blink

7. FAILED ドライブがある DAE を見つけます。

8. エンクロージャの左右両側にあるマウント穴の肩付きネジを緩め（左回り）、アクセスできるようにします。エンクロージャのラッチハンドルの刻みが付けられた端を握り、引き出してエンクロージャを中のレールから外します。安定した点検位置にロックされるまでエンクロージャをゆっくりキャビネットから引き出します。

図 80 エンクロージャを肩付きネジと一緒に外し、キャビネットから引き出します。

ロックラッチが簡単に抜けない場合は、ドロアーに押しつけてやり直します。

9. アンバーの（点灯した）障害 LED を見つけて、交換するドライブを特定します。示されたスロット ID が、故障 LED が点灯したドライブと一致することを確認します。ディスクは、12 のドライブアセンブリにそれぞれ 5 列で配列されています。初（手前）の列は A、その奥に行くに従って B、C、D、E となります。ドライブアセンブリは各列左から右に 0～11 の番号が付けられています。



図 81 DAE のドライブレイアウト

CL4749

10.ESD リストバンドを手首とエンクロージャに取り付けます。

11.オレンジ色のリリースタブを押して、ドライブを DAE から外します。ラッチを持ち上げてドライブを取り外し、静電気を帯びていない場所に置きます。



図 82 DAE のドライブモジュールの取り外し

CL4665

2 31

12.新しいドライブを DAE の同じスロットに取り付けます。

13.新しいドライブをスロットのガイドに合わせて、DAE に挿入します。

14.ドライブモジュールのラッチを完全に開いた状態にして、丁寧にモジュールをスロットに入れます。

15.ドライブモジュールのラッチが下向きに回転し始めます。

16.ハンドルを押し下げてラッチをかみ合わせます。ラッチがかみ合ったら、モジュールの端を強く押して、ドライブが正しく設置されていることを確認します。ドライブモジュールがアクティブ状態であることを示すライトが点滅し、ドライブがスピンアップシーケンス中であることが示されます。



図 83 DAE のドライブモジュールの取り付け

CL4666

1 2 3

17.オレンジ色の 2 つのセルフロックラッチを固定して、エンクロージャがキャビネットから滑り出さないようにします。両側の 2 本の肩付きネジをキャビネットのマウント穴に合わせます。肩付きネジをマウント穴にねじ込んで締めつけます。



図 84 キャビネットへの DAE の挿入

18.エンクロージャを閉じたら、ファンの速度が通常の動作レベルに戻ることを確認します。

19.cs_hal list disks コマンドを使って、システムが新しいドライブを認識していること

を確認します。新しいドライブは、交換されたドライブと同じスロット ID を持っています。シリアル番号は新しいので注意してください。新しいディスクが自動的に統合され、適切なサービスで使用できるようになります。

20.cs_hal led コマンドと新しいシリアル番号を使用して、ドライブの LED をオフにしま

す。

# cs_hal led <serial_number_of_new_drive> off

結果

ノードとシステムは自動的にドライブを検出し、初期化して使用できるようにします。



第 32 章

サードパーティ製ハードウェアの ECS ストレージディスクの交換

l ドライブ交換の計画............................................................................................. 308l cs_hal list disks コマンドの出力結果................................................................... 308l ドライブの交換.................................................................................................... 309

サードパーティ製ハードウェアの ECS ストレージディスクの交換 307

ドライブ交換の計画ECS アプライアンスを定期的にグルーミングして FAILED および SUSPECT のストレージドライブを交換する効率的な戦略について説明します。

ノードのメインのドライブ（ストレージドライブではなく）を交換する場合は、EMC カスタマー

サポートに連絡し支援を受けてください。

このドキュメントでは、「ドライブ」と「ディスク」を区別しています。ドライブとは、物理スピンドルのことです。ディスクとは、論理エンティティのことです（つまりドライブ上のパーティションです）。

システムがドライブを FAILED と表示している場合は、データ保護ロジックにより、そのドライブのデータがシステム内の他のドライブ上に再構築されます。それ以降は、その FAILED ドライブがシステムに参加することはできません。ドライブの交換には、交換用ドライブにデータをリストアする作業は含まれません。そのため、FAILED ドライブは、システムに対するraw 容量の損失のみを表しています。組み込み型のデータ保護の特性により、ドライブが故障した場合の緊急のサービスアクションの必要性が低減されています。

接続の問題ではなく物理的エラーのために故障が疑われる SUSPECT ドライブも、交換する必要があります。ドライブが SUSPECT と表示されている場合、それ以降システムはそのドライブにデータの書き込みを行いませんが、システムはそこからの読み取りは継続して行います。物理的エラーがある SUSPECT ドライブは、物理的エラーが特定の閾値を超えれば、

終的には FAILED と表示されます。ドライブが SUSPECT にとどまる間は、そのドライブはストレージシステムに完全には参加しません。したがって、提供されている cs_hwmg コマンドラインツールを使用して、該当するドライブのディスクを手動で［Bad］に設定する必要があります。この手順により、そのドライブとの間で保留状態にあるネットワーク上の連携を、システムが終了する機会を提供します。そのドライブ上のデータは、他のドライブからのそのデータのコピーを使って、システムの別の場所に再構築されます。そのため、該当するFAILED ドライブ上のディスクが問題なく BAD に設定されたことがシステムに表示されれば、すぐに交換プロセスを始められます。

ViPR UI は、ノードに SUSPECT または BAD のステータスのストレージディスクがある場合、

ノードを DEGRADED と表示します。

FAILED ドライブを処理する効率的な方法は、定期的に交換することです。交換時期は、そのドライブに関する製造業者の平均故障率を使って計算し、次のサービス予定日までに致命的な数のドライブが故障する危険性がないようにする必要があります。このプロセスは「グルーミング」と呼ばれます。グルーミングには次のものが含まれます。

l 次のサービス予定日までに予想される平均故障率への対処に十分な数のドライブの発注。

l FAILED ドライブの特定。

l 物理的エラーのため故障が疑われる SUSPECT ドライブの特定、および該当するディスクの手動での BAD 表示への強制変更。

l FAILED ドライブの交換。

cs_hal list disks コマンドの出力結果

cs_hal list disks コマンドの出力行の種類を説明します。




のでご覧ください。

l 初の 3 行は、ノードの 2 台の内蔵ドライブの RAID 構造を示しています。

l 次の行は、状態の良いストレージドライブを示しています。デバイス名、スロット番号、シリアル番号は、一意であれば cs_hal コマンドで使用できます。エンクロージャー名

も cs_hal コマンドで使用できます。

l 次の行は、障害が発生したストレージドライブを示しています。［Partition Name］は、対応するドライブのディスクがオブジェクトサービスに割り当てられ、ディスクがフォーマット済みで、ディスク状態に問題があることを示しています。

l 次の行は、状態が疑われるストレージドライブを示しています。疑わしい状態に該当するドライブのディスクは、稼働状態の悪化が疑われます。

l 後の行は、空のスロットか、検出できないドライブを示しています。

l ［SMART Status］列で、ドライブの稼働状態を確認します。

［Partition Name］列に示された状態は無視してください。その情報は、この手順には必

要ありません。その他の理由でパーティションの状態を知りたい場合は、cs_hwmgrdisk --list-by-service Object コマンドを使用すると、パーティションの状態

に関する新の正確な情報が［Health］列に示されます。

l DiskSet 列は、将来の使用のために予約されています。

[root@layton-cyan ~]# cs_hal list disksDisks(s):SCSI Device Block Device Enclosure Partition Name Slot Serial Number SMART Status DiskSet----------- ------------ ----------- ----------------------------------- ---- ------------------- -------------- ------------n/a /dev/md0 RAID vol n/a n/a not supported n/a/dev/sg4 /dev/sdb internal 0 KLH6DHXJ GOOD/dev/sg5 /dev/sdc internal 1 KLH6DM1J GOOD/dev/sg8 /dev/sdf /dev/sg0 Object:Formatted:Good A08 WCAW32601327 GOOD/dev/sg9 /dev/sdg /dev/sg0 Object:Formatted:Bad A09 WCAW32568324 FAILED: self-test fail; read element;/dev/sg10 /dev/sdh /dev/sg0 Object:Formatted:Suspect A10 WCAW32547329 SUSPECT: Reallocated_Sector_Count(5)=11...unavailable /dev/sg0 E05


total disks: 32

ドライブの交換FAILED および SUSPECT ストレージドライブを交換するには、ノードにコマンド実行します。

ドライブの交換時にノードをメンテナンスモードにしないでください。



手順

1. 次のように、ラップトップからプライベート（192.168.219.xxx）ネットワークを使用して ECSラック（キャビネット）にアクセスします。

a. 1 GbE プライベートスイッチネットワークポートを見つけます。

b. ラップトップから 1 GbE（Turtle）スイッチのポート 24 にネットワークケーブルを接続します。








e. ラップトップから SSH を使用してノード 1（provo）にアクセスします。アドレスは192.168.219.1 で、ルートログイン認証情報（パスワードはデフォルトのものまたはお客様が変更したもの）を使用します。

2. cs_hal list disks コマンドを使用して、［SMART Status］列の各ドライブの稼働状

態ステータスを確認します。

# cs_hal list disksDisks(s):SCSI Device Block Device Enclosure Partition Name Slot Serial Number SMART Status DiskSet----------- ------------ ----------- ----------------------------------- ---- ------------------- -------------- ------------n/a /dev/md0 RAID vol n/a n/a not supported n/a/dev/sg4 /dev/sdb internal 0 KLH6DHXJ GOOD/dev/sg5 /dev/sdc internal 1 KLH6DM1J GOOD/dev/sg8 /dev/sdf /dev/sg0 Object:Formatted:Good A08 WCAW32601327 GOOD/dev/sg9 /dev/sdg /dev/sg0 Object:Formatted:Good A09 WCAW32568324 GOOD/dev/sg10 /dev/sdh /dev/sg0 Object:Formatted:Good A10 WCAW32547329 GOOD/dev/sg11 /dev/sdi /dev/sg0 Object:Formatted:Good B08 WCAW32543442 GOOD/dev/sg12 /dev/sdj /dev/sg0 Object:Formatted:Good B07 WCAW32499200 GOOD/dev/sg13 /dev/sdk /dev/sg0 Object:Formatted:Good B06 WCAW32540070 GOOD



/dev/sg14 /dev/sdl /dev/sg0 Object:Formatted:Good A11 WCAW32493928 GOOD/dev/sg15 /dev/sdm /dev/sg0 Object:Formatted:Good B10 WCAW32612977 GOOD/dev/sg16 /dev/sdn /dev/sg0 Object:Formatted:Suspect B11 WCAW32599710 SUSPECT: Reallocated_Sector_Count(5)=11/dev/sg17 /dev/sdo /dev/sg0 Object:Formatted:Good C11 WCAW32566491 GOOD/dev/sg18 /dev/sdp /dev/sg0 Object:Formatted:Good D11 WCAW32528145 GOOD/dev/sg19 /dev/sdq /dev/sg0 Object:Formatted:Good C10 WCAW32509214 GOOD/dev/sg20 /dev/sdr /dev/sg0 Object:Formatted:Good D10 WCAW32499242 GOOD/dev/sg21 /dev/sds /dev/sg0 Object:Formatted:Good C09 WCAW32613242 GOOD/dev/sg22 /dev/sdt /dev/sg0 Object:Formatted:Good D09 WCAW32503593 GOOD/dev/sg23 /dev/sdu /dev/sg0 Object:Formatted:Good E11 WCAW32607576 GOOD/dev/sg24 /dev/sdv /dev/sg0 Object:Formatted:Good E10 WCAW32507898 GOOD/dev/sg25 /dev/sdw /dev/sg0 Object:Formatted:Good E09 WCAW32613032 GOOD/dev/sg26 /dev/sdx /dev/sg0 Object:Formatted:Good C08 WCAW32613016 GOOD/dev/sg27 /dev/sdy /dev/sg0 Object:Formatted:Good D08 WCAW32543718 GOOD/dev/sg28 /dev/sdz /dev/sg0 Object:Formatted:Good C07 WCAW32599747 GOOD/dev/sg29 /dev/sdaa /dev/sg0 Object:Formatted:Good E06 WCAW32612688 GOOD/dev/sg30 /dev/sdab /dev/sg0 Object:Formatted:Good E08 WCAW32567229 GOOD/dev/sg31 /dev/sdac /dev/sg0 Object:Formatted:Good D06 WCAW32609899 GOOD/dev/sg32 /dev/sdad /dev/sg0 Object:Formatted:Good C06 WCAW32546152 GOOD/dev/sg33 /dev/sdae /dev/sg0 Object:Formatted:Good D07 WCAW32613312 GOOD/dev/sg34 /dev/sdaf /dev/sg0 Object:Formatted:Good E07 WCAW32507641 GOOD/dev/sg3 /dev/sda /dev/sg0 Object:Formatted:Good A06 WCAW32547444 GOOD/dev/sg6 /dev/sdd /dev/sg0 Object:Formatted:Good A07 WCAW32525128 GOOD/dev/sg7 /dev/sde /dev/sg0 Object:Formatted:Good B09 WCAW32496935 GOOD……unavailable /dev/sg0 E02unavailable /dev/sg0 E03unavailable /dev/sg0 E04unavailable /dev/sg0 E05


total disks: 32

このレポートには、ノードの 2 台の内蔵ドライブ、30 台のストレージドライブ（そのうち 1台の稼働状態が SUSPECT）、使用不可と表示された 30 の空スロットが示されています。



上記のコマンドの出力にドライブのパーティション名が「Object:Formatted:Bad」または

「Object:Formatted:Suspect」と示され、SMART ステータスが「GOOD」である場合は、ここ

で手順を終了します。この状況は、ドライブの稼働状態を判断するときに例外をキャッチ

するハードウェアマネージャーのバグによるものです。 ECS のカスタマーサポートにお

問い合わせになり、問題を修正する回避策が実施されるのをお待ちください。それ以外

の場合は、次の手順に進みます。

ECS ポータルからディスク ID を取得した場合は、次のコマンドで grepを使用して、6 列

目のディスクのシリアル番号を確認します。この例では、シリアル番号は

AR31021EG62L9C です。

# cs_hwmgr disk --list-by-service Object | grep a1d7c15f-9995-4205-99b9-2267794d0154a1d7c15f-9995-4205-99b9-2267794d0154 ... AR31021EG62L9C ...

次に、cs_hwmgr drives --list コマンドで grep とシリアル番号を使用して、

後の列（6 列目）のスロット ID を確認します。この例では、スロット ID は A06 です。

# cs_hwmgr drives --list | grep AR31021EG62L9CATA HGST HUS726060AL AR31021EG62L9C 6001 Good A06

これで、手順に必要な情報が入手できました。

3. FAILED または SUSPECT ドライブのシリアル番号を書き留めます。

4. ターゲットドライブが SUSPECT の場合は、次の手順を実行します。

ドライブの SUSPECT 状態がハードウェアの問題によるものかを確認します。

l cs-hal コマンドの出力の［SMART Status］列に「reallocated_sector_count」データ

が表示される場合は、ドライブ交換の手順を続けます。このデータは、ハードウェアの問題を示します。

l 「reallocated_sector_count」データが表示されない場合は、ドライブ交換の手順を終了しますドライブの SUSPECT 状態の原因はハードウェア以外の問題（接続の問題など）である可能性があります。

a. cs_hwmgr --list コマンドを使用して、初の 2 列でディスクの VendorId と

ProductID を確認します。

# cs_hwmgr drive --list | grep -i WCAW32599710 ATA HUS726060ALA640 WCAW32599710 6001 Suspect B11

cs_hwgmr drive --list | grep <disk SN#>コマンドで「Suspect」ドライブの出力が返され

ない場合は、ディスクがハードウェアマネージャーの管理対象になっていません。

ECS のカスタマーサポートにお問い合わせください。また、ナレッジベースの記事

197235 を参照してください。

b. cs_hwmgr drive --set-health-bad コマンドで<VendorID>、<ProductID>、<Disk SN#>の値を使用して、ドライブの稼働状態ステータスを「Bad」に設定します。

# cs_hwmgr drive --set-health-bad ATA HUS726060ALA640 WCAW32547329



Setting drive health of ATA:HUS726060ALA640:WCAW32547329 to bad...Suceeded

c. cs_hwmgr drive --remove コマンドを使用して、ターゲットドライブ（具体的に





す。

5. ターゲットドライブが BAD の場合は、次の手順を実行します。

l cs_hwmgr drive --list コマンドの出力にドライブのシリアル番号が表示され

ない場合は、この手順をスキップします。

l cs_hwmgr drive --list コマンドで報告されたドライブ稼働状態が「Bad」の場

合は、以下の手順に進みます。

a. cs_hwmgr drive --remove コマンドを使用して、ターゲットドライブ（具体的に





す。

6. cs_hal led コマンドとシリアル番号を使用して、ドライブの LED を点滅させます（ドロ

アー内の該当ドライブを見つけるため）。

# cs_hal led WCAW32599710 blink

7. ハードウェアメーカーが示す手順に従い、ディスクを見つけて同じスロットで交換します。

8. cs_hal list disks コマンドを使って、システムが新しいドライブを認識していること

を確認します。新しいドライブは、交換されたドライブと同じスロット ID を持っています。シリアル番号は新しいので注意してください。新しいディスクが自動的に統合され、適切なサービスで使用できるようになります。

9. cs_hal led コマンドと新しいシリアル番号を使用して、ドライブの LED をオフにしま

す。

# cs_hal led <serial_number_of_new_drive> off



結果

ノードとシステムは自動的にドライブを検出し、初期化して使用できるようにします。



第 33 章

U シリーズアプライアンスへの 60 ディスクアップグレードの追加

l 60 ディスクアップグレードの計画........................................................................ 316l cs_hal コマンド.................................................................................................... 320l 60 ディスクアップグレードの実行........................................................................ 321

U シリーズアプライアンスへの 60 ディスクアップグレードの追加 315

60 ディスクアップグレードの計画ECS U シリーズアプライアンスの 60 ディスクアップグレードの計画に関する考慮事項を示します。

60 ディスクアップグレードでは、4 つの DAE/ノードペアにディスクを 15 台ずつ追加します。

セールスオーダーフォームを参照して PSNT 番号を確認し、アップグレードするラックを特定します。ターゲットラックの背面の目立つ場所にタグが貼付されており、そこに PSNT 番号が記載されています。作業を始める前に、ターゲットノードで ECS 1.2（以降）ソフトウェアまたはそれよりも古いバージョンの ECS ソフトウェアのどちらを実行しているかを確認します。手順はソフトウェアのバージョンによって少し異なります。

アップグレード手順を開始する前に、次のルールに従っていることを確認します。

l DAE のディスク数が 15、30、45、60 のいずれかであること。

l ディスクドライブが以下の図のレイアウトに従って設置されていること。

l 下部の 4 個の DAE に同じ数のディスクドライブがあること。

l 下部の 4 個の DAE に事前に 60 台のディスクがあり、さらに 4 つの DAE/ノードペアでラックをアップグレード可能であること。

l 上部の 4 個の DAE に同じ数のディスクドライブがあること。

l DAE 内のすべてのディスクドライブが同じサイズと速度であること。

l DAE に悪い状態（故障）のディスクドライブがある場合に、そのディスクドライブを交換せずにアップグレード手順を続行できること。

初の図は、小構成の ECS U シリーズアプライアンスを示しています。

l ディスクドライブのスロット A0～A11 は常に使用されている。

l ディスクドライブのスロット B0～B2 は常に使用されている。



図 85 ディスク 15 台のレイアウト

以下の図を参照して、フィラーを取り外すドライブスロットとディスクドライブを取り付けるドライブスロットを確認します。

DAE ごとにディスクを 15 台から 30 台にアップグレードする場合：

l ディスクドライブのスロット B3～B11 を使用する。

l ディスクドライブのスロット C0～C5 を使用する。


60 ディスクアップグレードの計画 317


ディスクを 30 台から 45 台にアップグレードする場合：

l ディスクドライブのスロット C6～C11 を使用する。

l ディスクドライブのスロット D0～D8 を使用する。




ディスクを 45 台から 60 台にアップグレードする場合：

l ディスクドライブのスロット D9～D11 を使用する。

l ディスクドライブのスロット E0～E11 を使用する。


60 ディスクアップグレードの計画 319


cs_hal コマンドこの手順で使用する cs_hal コマンドについて説明します。

cs_hal list disks コマンド


のでご覧ください。l 初の 3 行は、ノードの 2 台の内蔵ドライブの RAID 構造を示しています。l 次の行は、［SMART Status］列の状態の良いストレージドライブを示しています。デバ

イス名、スロット番号、シリアル番号は、一意であれば cs_hal コマンドで使用できま

す。エンクロージャ（DAE）名も cs_hal コマンドで使用できます。l 次の行は、障害が発生したストレージドライブを示しています。［Partition Name］は、

対応するドライブのディスクがオブジェクトサービスに割り当てられ、ディスクがフォーマット済みで、ディスク状態に問題があることを示しています。

ディスクドライブの現在の稼働状態を判断するには、［SMART Status］列の値を参照し

ます。

l 次の行は、状態が疑われるストレージドライブを示しています。l 後の行は、空のスロットか、検出できないドライブを示しています。l ［DiskSet］列は、将来の使用のために予約されています。

[root@layton-cyan ~]# cs_hal list disksDisks(s):



SCSI Device Block Device Enclosure Partition Name Slot Serial Number SMART Status DiskSet----------- ------------ ----------- ----------------------------------- ---- ------------------- -------------- ------------n/a /dev/md0 RAID vol n/a n/a not supported n/a/dev/sg4 /dev/sdb internal 0 KLH6DHXJ GOOD/dev/sg5 /dev/sdc internal 1 KLH6DM1J GOOD/dev/sg8 /dev/sdf /dev/sg0 Object:Formatted:Good A08 WCAW32601327 GOOD/dev/sg9 /dev/sdg /dev/sg0 Object:Formatted:Bad A09 WCAW32568324 FAILED: self-test fail; read element;/dev/sg10 /dev/sdh /dev/sg0 Object:Formatted:Suspect A10 WCAW32547329 SUSPECT: Reallocated_Sector_Count(5)=11...unavailable /dev/sg0 E05


total disks: 32

cs_hal list daesこのコマンドは、ノードとペアになる DAE のエンクロージャ ID を見つけるために使用します。

# cs_hal list daes

Enclosure(s):SCSI Device Ext Disks----------- ---------/dev/sg2 15

total: 1

cs_hal list nodeこのコマンドは、操作するノードの名前を見つけるために使用します。名前を見つけたら、図を参照して、ノードに関連づけられた DAE を特定できます。

# cs_hal list node

Node(s):Name HBAs Enclosures Int Disks Ext Disks---------- ---- ---------- --------- ---------provo-sage 2 1 1 16

60 ディスクアップグレードの実行4 個の DAE（ディスクアレイエンクロージャ）に 15 台のディスクを追加することで、60 台のディスクアップグレードを実行します。

はじめに

ノード/DAE ペアごとにディスクドライブをインストールします。

手順

1. 次のように、ラップトップからプライベート（192.168.219.xxx）ネットワークを使用して ECSラックにアクセスします。

a. ラックの背面扉を開けて、1 GbE プライベートスイッチネットワークポートを見つけます。


60 ディスクアップグレードの実行 321

b. ラップトップから Arista 1 GbE（Turtle）スイッチのポート 24 にネットワークケーブルを接続します。

図 89 プライベート 1 GbE スイッチのポート 24








e. 初のノードで SSH セッションを開始します。

2. cs_hal list disks コマンドを使用します。

# cs_hal list disks

出力に使用済みと表示されたディスクドライブスロットが、計画フェーズで想定したもの

と一致する必要があります。



3. 正しい DAE を見つけます。

a. cs_hal list node コマンドを使用して、ノードの名前を確認します。

# cs_hal list node

Node(s):Name HBAs Enclosures Int Disks Ext Disks---------- ---- ---------- --------- ---------provo-sage 2 1 1 16

b. 次の配線図を参照して、正しい DAE を物理的に特定します。

図 90 U シリーズの ECS アプライアンスの配線

4. 配線図で特定した DAE を開きます。

5. 該当のディスクレイアウト図に示されたとおりに、フィラーを取り外し、ディスクドライブをスロットに配置します。



6. DAE を閉じて、2 分間待ちます。

7. cs_hal list disks コマンドを使用して、ノードで正しい数のディスクドライブが認

識されることを確認します。

# cs_hal list disks | grep -i external

external: ［<number of disks>］

［<number of disks>］は、30、45、60 のいずれかです。

8. 結果が想定と異なる場合は、cs_hal list disks コマンドを使用して、ノードで認識

されないディスクドライブを特定します。該当のディスクレイアウト図を使って比較してください。

# cs_hal list disks

9. 出力でディスクドライブが認識されない場合は、次の手順を実行します。

a. DAE を開き、そのスロットにディスクドライブが追加されていることを確認します。

b. ディスクドライブが存在する場合は、取り付け直すか、スロットにディスクドライブを追加します。

c. cs_hal list disks コマンドを再度実行します。

d. それでも出力でディスクドライブが認識されない場合または FAILED と表示される場合は、交換用ディスクドライブを注文してください。

10.残りの 3 つのノード/DAE ペアで手順 1～9 を繰り返します。

11. 後のノードのアップグレードを終えたら、10 分間待ちます。その後、cs_hwmgr コマ

ンドを実行して、すべてのドライブがシステムで認識されることを確認します。

# viprexec "cs_hwmgr ListDrives | grep -i count"

Output from host : ???.???.???.1Persistent drive count: <number of disks> Output from host : ???.???.???.2Persistent drive count: <number of disks> Output from host : ???.???.???.3Persistent drive count: <number of disks> Output from host : ???.???.???.4Persistent drive count: <number of disks>

各項目の意味は次のとおり。

l 表示される IP アドレスの末尾の数字（.1 など）は、ラックのノード番号を示します。

l ［<number of disks>］は、30、45、60 のいずれかです。

viprexec コマンドは、現在の ECS ラック内の各ノードに対して引用符で囲まれたコマ

ンドを実行します。このコマンドを他のノードレベルのコマンドとともに使用する場合は、

注意して行ってください。

12.この出力が想定ドライブ数と一致しない場合は、さらに 10 分待ってから、もう一度viprexec コマンドを実行します。それでもドライブ数が正しくない場合は、ドライブ数

の合わないホストに SSH を使用して手順 11 を繰り返します。



結果

ノードと ECS システムで自動的にディスクドライブが検出され、初期化されて使用可能になります。ディスクがオブジェクトサービスで正常と認識されることを確認するには、cs_hwmgr disk --list-by-service コマンドを使用します。



第 34 章

ECS サードパーティラック要件

l ECS サードパーティラック要件............................................................................ 328


ECS サードパーティラック要件ECS アプライアンスの組み立てにお客様提供のラックを使用する場合は、ラックが次の要件を満たすことを確認する必要があります。

技術情報と要件に追加情報が記載されています。

表 67 サードパーティラック要件

要件カテゴリー

説明

キャビネ

ット

ラックの奥行 44 インチ以上。

キャビネットの両側にケーブルを配線する余裕を残すために幅 24 インチのキャビネット

を推奨。

コンポーネントを必要な相対的順序で設置するためにラック内のどこかに十分な連続ス

ペースが必要。

前面扉を使用する場合は、ベゼルとの間に 1.2 インチ以上のスペースを空けること。

50%以上の空気穴を均等に配分して設けること。サポート担当者が簡単にアクセスで

き、LED が見えるようにすること。

背面扉を使用する場合は、50%以上の空気穴を均等に配分して設けること。

必要に応じて空きパネルを使用して、キャビネット内で空気が再循環するのを防止する

こと。

保守エリアと適切なエアフローを確保するために、キャビネットの前面に 42 インチ以上

のスペース、背面に 36 インチのスペースを推奨。

NEMA レ

ール

1U のインクリメントがマークされた幅 19 インチのレール。

奥行 24～34 インチ。

丸い穴が空いた NEMA レールは、EMC レールで使用される M5 サイズのネジに対応す

ること。

四角の穴が空いた NEMA レールには、EMC の特殊なネジ 036-709-013、またはサード

パーティラックベンダーから提供される丸い穴のレールに対応したクリップを使用可能。

ECS コンポーネントを注文する場合は、ラック構成に適したレールキットを入手できるよ

うに、EMC セールスにお問い合わせください。

電源 AC 電源の要件は AC 200～240 V ±10%、50～60 Hz。

お客様提供のラックに冗長電源領域があり、ラックの両側に別個の PDU が 1 つずつあ

ること。冗長電源領域はそれぞれ大限の電源負荷容量を確保すること。注： EMCは、お客様提供の PDU の故障が原因のいかなる障害、問題、システム停止にも責任を

負いません。

ケーブル

接続

製品のケーブルは工場から出荷された標準的な EMC 製品と同じように配線すること。

これには、垂れ下がったり FRU（フィールド交換可能ユニット）の保守を邪魔したりしない

ように、ケーブルを両側で結束することが含まれる。

オプティカルケーブルは曲げ半径 1.5 インチを維持するように結束すること。



表 67 サードパーティラック要件（続き）

要件カテゴリー

説明

ラック内のサードパーティ製コンポーネントのケーブルは、前面から背面へのエアフロー

や FRU の保守作業を妨げないために、交差させたり EMC ロジックコンポーネントに干

渉を与えたりしないこと。

DAE（ディ

スクアレ

イエンク

ロージャ）

すべての DAE は、傾くリスクを回避するために、下から上にシーケンシャルな順序で設

置すること。

l 警告

l 2つ以上のDAEを同時に開くと、傾く危険があります。

l DAEは必ず一度に1台のみ開いてください。EMCのラックは統合されたソリューションにより、複数のDAEが一度に開かれることのないようにします。お客様提供のラックはこの機能をサポートしていません。

重量お客様提供のラックは EMC 製機器の重量を支持できること。



emc ecs elastic cloud storage · 2020. 3. 12. · 連携へのvdcの追加 ... ecs...

Documents