Elastic Cloud Storage (ECS)...ECS では、複数ノードと接続されたストレージデバイスを含む、拡張性の高いアーキテクチャを使用します。そのノードとストレージ

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

管理ガイド302-003-863

02

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

2017 年 9 月発行

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

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

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

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

2 Elastic Cloud Storage (ECS) 3.1 管理ガイド

7

9

概要 11はじめに........................................................................................................ 12ECS プラットフォーム....................................................................................... 12ECS データ保護............................................................................................ 14

可用性、耐久性、復元性の構成........................................................15ECS ネットワーク............................................................................................ 16ロードバランシングに関する考慮事項................................................................ 17

ECSの使用開始 19初期構成.....................................................................................................20ECS Portal へのログイン................................................................................ 20Getting Started Task Checklist の表示........................................................ 21ECS Portal ダッシュボードの表示.................................................................... 22

右上のメニューバー...........................................................................23リクエストの表示................................................................................24容量使用率の表示.......................................................................... 24パフォーマンスを表示......................................................................... 24ストレージの効率性の表示................................................................ 25Geo Monitoring の表示...................................................................25ノードとディスクの正常性を表示.......................................................... 26アラートの表示................................................................................. 26

ストレージプール、VDC、レプリケーショングループ 27ストレージプール、VDC、レプリケーショングループの概要..................................... 28ECS Portal でのストレージプールの扱い.......................................................... 29

ストレージプールの作成.....................................................................30ストレージプールの編集.....................................................................32

ECS Portal での VDC の扱い ........................................................................32単一サイトへの VDC の作成.............................................................. 33連携への VDC の追加...................................................................... 34VDC の編集....................................................................................35VDC の削除とサイトのフェールオーバー.................................................36

ECS Portal でのレプリケーショングループの扱い.................................................37レプリケーショングループの作成........................................................... 38レプリケーショングループの編集........................................................... 42

認証プロバイダー 43認証プロバイダーの概要................................................................................. 44ECS Portal での認証プロバイダーの操作......................................................... 44

図

表

第 1章

第 2章

第 3章

第 4章

目次

Elastic Cloud Storage (ECS) 3.1 管理ガイド 3

Active Directory認証プロバイダーを追加する際の考慮事項................45AD または LDAP認証プロバイダーの追加............................................45Keystone認証プロバイダーの追加..................................................... 49

ネームスペース 51ネームスペースの概要.....................................................................................52ネームスペーステナンシー................................................................................52ネームスペース設定........................................................................................53

保存期間と保存ポリシー................................................................... 55ECS Portal でのネームスペースの操作.............................................................56

ネームスペースの作成........................................................................ 57ネームスペースの編集........................................................................60ネームスペースの削除.........................................................................61

ユーザーおよびロール 63ユーザーとロールの概要.................................................................................. 64ECS のユーザー............................................................................................ 64

管理ユーザー................................................................................... 64デフォルトの管理ユーザー................................................................... 65オブジェクトユーザー..........................................................................65ドメインユーザーとローカルユーザー..................................................... 66ユーザースコープ...............................................................................68ユーザータグ.................................................................................... 68

ECS での管理ロール......................................................................................69システム管理者................................................................................69システム監視者................................................................................69ネームスペース管理者....................................................................... 69ロック管理者.................................................................................... 70ロールによって実行されるタスク............................................................ 70

ECS ポータルでのユーザーの操作.................................................................... 73オブジェクトユーザーの追加................................................................75オブジェクトユーザーとしてのドメインユーザーの追加...............................78ネームスペースへのドメインユーザーの追加........................................... 79ローカル管理ユーザーの作成または管理ロールへのドメインユーザーまたはAD グループの割り当て...................................................................... 79ユーザーまたは AD グループへのネームスペース管理者ロールの割り当て....80

Buckets 83バケットの概要.............................................................................................. 84

バケットの所有権.............................................................................. 84バケットのアクセス..............................................................................84

バケットの設定.............................................................................................. 85デフォルトグループ.............................................................................87メタデータインデックスキー..................................................................87バケットのタグ機能............................................................................ 89

ECS Portal でのバケットの扱い....................................................................... 89バケットの作成................................................................................. 90バケットの編集.................................................................................. 91ACL の設定.................................................................................... 92バケットポリシーエディタの使用...........................................................97

第 5章

第 6章

第 7章

目次


S3 API を使用したバケットの作成（s3curl使用）.......................................... 101バケットの HTTP ヘッダー.................................................................. 104

バケット、オブジェクト、ネームスペースの命名規則..............................................104S3バケットとオブジェクトの ECS での命名...........................................105OpenStack Swift コンテナとオブジェクトの ECS での命名....................105Atmosバケットとオブジェクトの ECS での命名.....................................106CAS プールとオブジェクトの ECS での命名..........................................106

ファイルアクセス 107ファイルアクセスの概要..................................................................................108

ディレクトリおよびファイルへのマルチプロトコルアクセス........................... 108NFS構成のための ECS ポータルのサポート..................................................... 109

ECS Portal でのエクスポートの扱い................................................... 109ECS Portal での User/Group Mappings の取り扱い......................... 110

ECS NFS構成タスク.................................................................................... 111ECS ポータルを使用した NFSバケットの作成...................................... 112ECS Portal を使用して NFS エクスポートを追加................................. 113ECS Portal を使用してユーザーまたはグループマッピングを追加.............116Kerberos セキュリティを使用した NFS の構成......................................117NFS エクスポートのマウントの例.........................................................124

ECS NFS を使用する場合のベストプラクティス................................................ 125マルチプロトコル（クロスヘッド）アクセスの権限...............................................126ファイル API サマリー......................................................................................128

証明書 129証明書の概要.............................................................................................130証明書の生成.............................................................................................130

秘密キーの作成.............................................................................. 131SAN構成の生成............................................................................ 131自己署名証明書の生成..................................................................132証明書署名リクエストの生成............................................................ 134

証明書のアップロード.................................................................................... 135ECS Management REST API による認証........................................136管理証明書のアップロード................................................................ 136データアクセスエンドポイントのデータ証明書のアップロード..................... 138

インストールされている証明書の確認.............................................................. 139管理証明書の確認.........................................................................139オブジェクト証明書の検証................................................................ 140

ECS設定 143ECS設定の概要.........................................................................................144オブジェクトベース URL................................................................................. 144

バケットとネームスペースのアドレス指定............................................... 144DNS の構成.................................................................................. 146ベース URL の追加..........................................................................147

パスワードの変更..........................................................................................148ESRS（EMC セキュアリモートサービス）.......................................................149

ESRS の構成の確認.......................................................................149イベント通知サーバ.......................................................................................150

SNMP サーバ................................................................................. 151

第 8章

第 9章

第 10章

目次


Syslog サーバ................................................................................ 158プラットフォームのロック................................................................................... 162

ECS管理 REST API を使用して、ノードをロックし、ロック解除します。... 162ECS Portal を使用したノードのロックおよびロック解除...........................163

ライセンス.................................................................................................... 164EMC ECS ライセンスファイルの取得..................................................164ECS ライセンスファイルのアップロード.................................................. 165

この VDC について........................................................................................165

ECSの停止とリカバリ 167ECS サイトの停止と復旧の概要.................................................................... 168TSO動作.................................................................................................. 168

無効化された ADOバケットのプロパティを使用した TSO の動作............ 169有効化された ADOバケットプロパティを使用した TSO動作................. 170TSO に関する考慮事項.................................................................. 176TSO中の NFS ファイルシステムのアクセス..........................................176

PSO動作.................................................................................................. 176ディスクおよびノード障害のリカバリ....................................................................177

ノードの障害時の NFS ファイルシステムアクセス.................................. 178新しいノード追加後のデータの再バランシング.................................................... 178

第 11章

目次


ECS コンポーネントレイヤー.............................................................................................13ポータルからログアウトします。........................................................................................... 21［Guide］アイコン ..........................................................................................................21Getting Started Task Checklist...................................................................................22ECS ダッシュボード......................................................................................................... 23右上のメニューバー........................................................................................................233 つのサイトにまたがるレプリケーショングループと、2 つのサイトをまたがるレプリケーショングループ................................................................................................................................... 29［Storage Pool Management］ページ........................................................................... 29Virtual Data Center の管理ページ................................................................................. 32［Replication Group Management］ページ................................................................... 38［Authentication Provider Management］ページ.......................................................... 44ネームスペース管理ページ............................................................................................... 571 つの AD属性を使用して、ネームスペースにドメインユーザーのサブセットを追加します。..........67複数の AD属性を使用して、ネームスペースにドメインユーザーのサブセットを追加します。........67［User Management］ページ........................................................................................ 74［Bucket Management］ページ.................................................................................... 90Bucket ACLs Management ページの［User ACLs］タブ................................................94バケットポリシーエディタのコードビュー.............................................................................. 98バケットポリシーエディタのツリービュー.............................................................................. 99［File］ページ上の［Exports］タブ................................................................................110［File］ページ上の［User/Group Mapping］タブ........................................................... 111オーナー以外のサイトからデータにアクセスする場合や、オーナーサイトが TSO である場合の、TSO中の読み取り/書き込み要求の失敗.............................................................................. 169オーナーサイトからデータにアクセスする場合や、オーナー以外のサイトが TSO である場合の、TSO中の読み取り/書き込み要求の成功...............................................................................170オーナー以外のサイトから ADO が有効化されたデータにアクセスする場合や、オーナーサイトがTSO である場合の、TSO中の読み取り/書き込み要求の成功...........................................1712 サイト連携で、TSO中に書き込みのためのオブジェクト所有権の例................................... 1733 サイトのフェデレーションで、TSO中の読み取り要求ワークフローの例..................................174正常な状態の Geo-Passive レプリケーション................................................................... 175Geo-Passive レプリケーションの TSO..............................................................................175

1234567

8910111213141516171819202122

23

24

25262728

図


図


ECS がサポートするデータサービス....................................................................................13標準およびコールドアーカイブの EC の要件 ...................................................................... 14ストレージオーバーヘッド..................................................................................................15ECS データ保護スキーム.................................................................................................15ストレージプールのプロパティ............................................................................................30VDC のプロパティ........................................................................................................... 33レプリケーショングループのプロパティ.................................................................................. 38認証プロバイダーのプロパティ............................................................................................44AD または LDAP認証プロバイダーの設定.........................................................................46Keystone認証プロバイダーの設定..................................................................................50ネームスペース設定........................................................................................................53ネームスペースのプロパティ............................................................................................... 57デフォルトの管理ユーザー................................................................................................65ECS管理ユーザーロールによって実行されるタスク............................................................. 70オブジェクトユーザープロパティ......................................................................................... 74管理ユーザーのプロパティ................................................................................................ 75バケットの属性.............................................................................................................. 85バケットの ACL.............................................................................................................. 93バケットのヘッダー..........................................................................................................104ECS によって使用される Syslog ファシリティ..................................................................... 160Syslog の重大度のキーワード........................................................................................160ECS管理 REST API がノードのロックを管理します。........................................................ 163

12345678910111213141516171819202122

表


表


第 1章

概要

l はじめに................................................................................................................12l ECS プラットフォーム............................................................................................... 12l ECS データ保護.................................................................................................... 14l ECS ネットワーク....................................................................................................16l ロードバランシングに関する考慮事項....................................................................... 17

概要 11

はじめにDell EMC ECS（Elastic Cloud Storage）は、包括的なソフトウェアデファインドクラウドストレージプラットフォームであり、コモディティハードウェア上の膨大な非構造化データの保管、処理、分析をサポートします。ECS をターンキーストレージアプライアンスまたは認定コモディティサーバとディスクにインストールされているソフトウェア製品として導入することができます。ECS では、コモディティインフラストラクチャのコストの利点と、従来のアレイのエンタープライズクラスの信頼性、可用性、保守性を提供します。ECS では、複数ノードと接続されたストレージデバイスを含む、拡張性の高いアーキテクチャを使用します。そのノードとストレージデバイスはコモディティコンポーネントであり、一般的に利用できるデバイスと同様であり、1 つ以上のラックに格納されます。ラックとそのコンポーネントが Dell EMC によって提供され、ソフトウェアがプリインストールされていますが、ECS［アプライアンス］として参照されます。ラックとコモディティノードは Dell EMC で提供されませんが、Dell EMC ECS［ソフトウェアのみのソリューション］として参照されます。複数ラックは、［クラスタ］として参照されます。ラックまたは結合された複数のラックは、処理と ECS インフラストラクチャソフトウェアによって一貫性のあるユニットとして処理されるストレージを使用して、［サイト］として、ECS ソフトウェアレベルではVDC（［仮想データセンター］）として参照されます。管理ユーザーがアクセスできる ECSUIは、ECS ポータルとして参照され、管理タスクを実行します。管理ユーザーには、システム管理者、Namespace管理者、システム監視のロールが含まれます。ECS ポータルで実行可能な管理タスクを、ECS管理 REST API を使用して実行することもできます。ECS管理者は、ECS ポータルの次のタスクを実行できます。l オブジェクトユーザーのオブジェクトストアインフラストラクチャ（コンピューティングとストレージリソ

ース）を構成し、管理します。l ユーザー、ロール、ネームスペース内のバケットを管理します。ネームスペースはテナントに相当し

ます。オブジェクトユーザーは、ECS ポータルにアクセスできませんが、次のデータアクセスプロトコルをサポートするクライアントを使用して、オブジェクトストアにアクセスしてオブジェクトとバケットに読み取りと書き込みができます。l Amazon S3（Amazon Simple Storage Service）l EMC Atmos

l OpenStack Swift

l ECSCAS（コンテンツアドレスストレージ）オブジェクトユーザータスクに関する詳細については、ECS製品ドキュメントページ内の使用可能な「ECS データアクセスガイド」を参照してください。システム監視タスクに関する詳細については、ECS製品ドキュメントページ内の使用可能な「ECS監視ガイド」を参照してください。

ECSプラットフォームECS プラットフォームはデータサービス、ポータル、ストレージエンジン、ファブリック、インフラストラクチャ、ハードウェアコンポーネントの各レイヤーで構成されています。

概要


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


図 1 ECS コンポーネントレイヤー

Data Services Portal

Storage Engine

Fabric

Infrastructure

Hardware

ECSSoftware

データサービスデータサービスコンポーネントレイヤーでは、オブジェクト、HDFS、NFS v3 プロトコルを介しての ECS オブジェクトストアへのアクセスをサポートしています。一般に、ECS では次のマルチプロトコルアクセスを提供します。あるプロトコルで取得されたデータに、他のプロトコルを介してアクセスできます。たとえば、S3 で取得されたデータを Swift、NFS v3、HDFS を介して変更できます。このマルチプロトコルアクセスには、いくつかの例外があります。プロトコルのセマンティクスやプロトコルの設計方法のためです。

次の表に、サポートされ、相互運用されているオブジェクト API とプロトコルを示します。

表 1 ECS がサポートするデータサービス

プロトコルサポート相互運用性

オブジェクト S3 バイト範囲の更新やリッチ ACLなどの追加機能ファイルシステム（HDFS と NFS）、Swift

Atmos バージョン 2.0 NFS（パスベースのオブジェクトのみで、オブジェクト ID

スタイルのオブジェクトではない）

Swift V2 API、Swift認証、Keystone v3認証ファイルシステム（HDFS と NFS）、S3

CAS SDK v3.1.544以降該当なし

HDFS Hadoop 2.7互換 S3、Swift*

NFS NFSv3 S3、Swift、Atmos（パスベースのオブジェクトのみ）

* ファイルシステムのアクセスでバケットを有効化すると、NFS ファイルシステムとしてバケットにアクセスするときに、HDFS を使用して設定した権限が有効になり、その逆も同じになります。

ポータルECS Portal コンポーネントレイヤーはWeb ベースの GUI を提供し、管理、ライセンス、ECSノードのプロビジョニングができるようにします。ポータルには、次の包括的なレポート作成機能があります。l 各サイト、ストレージプール、ノード、ディスクの容量使用率

l パフォーマンス監視としてのレイテンシ、スループット、1秒あたりのトランザクション数、レプリケーションの進行状況とレート

l ノードやディスクのリカバリステータスと各ノードのハードウェアおよびプロセスの稼働状態に関する統計情報など、パフォーマンスとシステムのボトルネックを特定する診断情報

概要

ECS プラットフォーム 13

ストレージエンジンストレージエンジンコンポーネントレイヤーは非構造化ストレージエンジンを提供し、データの保存と取得、トランザクションの管理、データの保護とレプリケートをします。ストレージエンジンは複数のオブジェクトストレージプロトコルおよび NFS と HDFS のファイルプロトコルを使用して、取得したオブジェクトへのアクセスを提供します。

Fabric

ファブリックコンポーネントレイヤーは、クラスタリング、システムの正常性管理、ソフトウェア管理、構成管理、アップグレード機能、アラートを提供します。ファブリックレイヤーは、サービスの実行を継続し、ディスク、コンテナ、ファイアウォール、ネットワークなどのリソースを管理します。障害の検出など、環境の変化をトラッキングし、それに対応します。また、システムの稼働状態に関連するアラートを提供します。

インフラストラクチャインフラストラクチャコンポーネントレイヤーは、ECS アプライアンスのベースオペレーティングシステムとして、あるいは有用なハードウェア構成の Linux オペレーティングシステムとして認定された、SUSE Linux Enterprise Server 12 を使用します。Docker がインフラストラクチャにインストールされていて、別の ECS コンポーネントレイヤーに導入されます。ECS ソフトウェアはJava で記述されているため、JVM（Java仮想マシン）がインフラストラクチャの一部としてインストールされます。

ハードウェアハードウェアコンポーネントレイヤーは、ECS アプライアンスまたは認定された業界標準のハードウェアです。ECS ハードウェアの詳細については、ECS製品ドキュメントページ内の使用可能な「ECS ハードウェアおよびケーブル接続ガイド」を参照してください。

ECS データ保護ECS がサイト内のデータを保護するために、複数ノード上のデータをミラーリングし、EC（消失訂正符号）を使用してデータチャンクを複数のフラグメントに分割したり、ノード間でフラグメントを分散したりします。ECは、ストレージオーバーヘッドを削減し、データの耐久性とディスク障害およびノード障害に対する復元性を確保します。デフォルトでは、ストレージエンジンはリードソロモン 12 + 4 EC スキームを実装しており、オブジェクトは 12個のデータフラグメントと 4個の符号化フラグメントに分けられます。結果として生成される16個のフラグメントは、ローカルサイト内のノードに分散されます。オブジェクトが消失訂正符号化されていれば、ECSはデコードまたは再構築なしでオブジェクトを 12個のデータフラグメントから直接読み取ることができます。ハードウェア障害が発生した場合には、コードフラグメントを使用してオブジェクトのみを再構築します。ECSはコールドストレージアーカイブを使用する 10 + 2 スキームもサポートし、頻繁に変更されず、より堅牢なデフォルト EC スキームは必要としないオブジェクトを格納しています。次の表では、EC スキームをサポートするための要件を示します。

表 2 標準およびコールドアーカイブの EC の要件

用途最低必要ノード数最低必要ディスク数

推奨されるディスク数

EC効率性 EC スキーム

定期的アーカイブ 4 16 32 1.33 12 + 4

コールドアーカイブ 6 12 24 1.2 10 + 2

概要



サイトを統合してデータを他のサイトにレプリケートし、可用性とデータの耐久性を向上させ、サイトの障害に対する ECS の復元性を確保できます。3 つ以上のサイトでは、サイトでのチャンクの ECに加え、別のサイトにレプリケートされるチャンクを XOR と呼ばれる技法を使用して結合し、ストレージ効率の向上を実現します。次の表は、複数のサイトが使用する ECS によって到達可能なストレージ効率を示します。

表 3 ストレージオーバーヘッド

レプリケーショングループ内のサイトの数

ストレージオーバーヘッド

デフォルト（EC：12+4）コールドアーカイブのユースケース（EC：10+2）

1 1.33 1.2

2 2.67 2.4

3 2.00 1.8

4 1.77 1.6

5 1.67 1.5

6 1.60 1.44

7 1.55 1.40

8 1.52 1.37

1 つのサイトがある場合、EC を使用すると、オブジェクトデータチャンクは raw データが必要とするバイト数より多くのスペース（1.33 またはストレージオーバーヘッドの 1.2倍）を使用します。2 つのサイトがある場合、ストレージオーバーヘッドは 2倍（2.67 またはストレージオーバーヘッドの 2.4倍）になります。両サイトでデータのレプリカを格納し、両サイトでデータが消失符号化されるからです。3 つ以上のサイトがある場合、ECSはチャンクをレプリケートするので、予想に反し、ストレージオーバーヘッドは削減されます。データの耐久性、復元性、可用性を提供する ECS によって使用されるメカニズムの詳細については、「Elastic Cloud Storage高可用性設計ホワイトペーパー」を参照してください。

可用性、耐久性、復元性の構成ECS システム内のサイトの数によっては、さまざまなデータ保護スキームは可用性を向上し、パフォーマンスに対するデータ保護要件のバランスを取ることができます。ECSは、レプリケーショングループを使用して、データ保護スキーム（ストレージプール、VDC、レプリケーショングループの概要（28ページ）を参照）を構成します。次の表では、使用可能なデータ保護スキームを示します。

表 4 ECS データ保護スキーム

サイト数データ保護スキーム

ローカルプロテクション

フルコピーの防止 Geo-Active Geo-Passive

1 ○ 該当なし該当なし該当なし

2 ○ 常時該当なし該当なし

3以上 ○ オプション標準オプション

概要

可用性、耐久性、復元性の構成 15

表 4 ECS データ保護スキーム（続き）

サイト数データ保護スキーム

ローカルプロテクション

フルコピーの防止 Geo-Active Geo-Passive

* フルコピー保護を、Geo Active で選択できます。フルコピー保護は、Geo-Passive が選択されている場合には使用できません。

ローカルプロテクションデータは、トリプルミラーリングと、サイトの障害に対してではなくディスクやノードの障害からの復元性を提供する EC を使用して、ローカルで保護されます。

フルコピーの防止［すべてのサイトにレプリケート］プロパティをレプリケーショングループを有効化する場合、レプリケーショングループは、レプリケーショングループ内のすべてのサイトに、すべてのオブジェクトの読み取り可能なフルコピーを作成します。オブジェクトの完全に読み取り可能なコピーがすべての VDC の全データがレプリケーショングループにあるため、データの耐久性に優れ、すべてのサイトでローカルパフォーマンスが改善しますが、ストレージの効率性は低下します。

Geo-Active

Geo-Activeは、デフォルトの ECS構成です。Geo-Active としてレプリケーショングループを構成すると、データが統合サイトにレプリケートされ、強力な整合性を使用してすべてのサイトからアクセスできます。2 つのサイトがある場合、データチャンクのフルコピーを他のサイトにコピーします。3 つ以上のサイトがある場合、レプリケートされたチャンクは結合（XOR）し、ストレージ効率が向上します。

データの所有者ではないサイトからデータにアクセスすると、非所有者サイトでそのデータがキャッシュされるまで、アクセス時間が増加します。同様に、データのプライマリコピーを含む所有者サイトが失敗した場合、非所有者サイトにリクエストしたグローバルなロードバランサーがあると、非所有者サイトは、XOR されたチャンクのデータを再作成する必要があり、アクセス時間が増加します。

Geo-Passive

Geo-Passive構成では、常に 3 つのサイトを含み、少なくとも 3 つのサイトを利用可能です。この構成では、2 つのサイトがアクティブです。第 3 のサイトはパッシブであり、レプリケーションターゲットです。バックアップサイトとして特定のサイトを設計し、3 つのサイトのストレージ効率（ストレージオーバーヘッドは 2.0倍）を実現できます。ストレージ効率は、Geo-Active の 3 つのサイト構成と同じです。Geo-Passive構成で、すべてのレプリケーションデータチャンクは、パッシブサイトに送信され、XOR操作がパッシブサイトでのみ実行されます。Geo-Active構成では、XOR操作はすべてのサイトで実行されます。

すべてのサイトがオンプレミスである場合、3 つのサイトのいずれかがレプリケーションターゲットです。Geo-Passive構成の重要なユースケースは、パッシブサイトがサードパーティによりホストされ、ホストされたサイトがレプリケーションターゲットとして選択されている場合です。ECS管理 REST API を使用して、この構成を変更し、レプリケーションターゲットとして、オンプレミスのサイトを選択することができます。

ECSネットワーク

概要


ECS ネットワークのインフラストラクチャは、トップオブラックスイッチであり、次のタイプのネットワーク接続があります。l パブリックネットワーク：ECS ノードを組織のネットワークに接続し、データを提供します。l インターナルプライベートネットワーク：ノードとスイッチをラック内およびラック間で管理します。ECS ネットワークの詳細については、「ECS ネットワークとベストプラクティスのホワイトペーパー」を参照してください。

ロードバランシングに関する考慮事項ECS の前処理でロードバランサーを使用することをお勧めします。ECS クラスターノード間で負荷を分散することに加え、ロードバランサーは、正常なノードにトラフィックをルーティングすることで ECS クラスターに HA（高可用性）を提供します。ネットワーク分離が実装されており、データと管理のトラフィックが分離されている場合は、ロードバランサーを構成し、ユーザーリクエストが、サポートされるデータアクセスプロトコルを使用して、データネットワークの IP アドレス間で分散されるようにする必要があります。ECS管理 REST API リクエストは、管理ネットワーク上のノード IP に直接要求するか、HA の管理ネットワーク間で負荷分散できます。ロードバランサー構成は、ロードバランサーのタイプによります。テスト済みの構成とベストプラクティスについては、カスタマーサポート担当者までお問い合わせください。

概要

ロードバランシングに関する考慮事項 17

概要


第 2章

ECS の使用開始

l 初期構成............................................................................................................ 20l ECS Portal へのログイン........................................................................................20l Getting Started Task Checklist の表示................................................................21l ECS Portal ダッシュボードの表示............................................................................ 22

ECS の使用開始 19

初期構成ECS を開始するために必要な初期構成の手順には、最初の ECS Portal へのログイン、ECSPortal Getting Started Task Checklist とダッシュボードの使用、ライセンスのアップロード、ECSVDC（仮想データセンター）の設定が含まれます。

ECS を初期構成するには、root ユーザーまたはシステム管理者であることが最低限必要です。

手順1. ECS のライセンスをアップロードします。

ライセンス（164 ページ）を参照してください。

2. 少なくとも 1 つのストレージプールを作成する一連のノードを選択します。

ストレージプールの作成（30 ページ）を参照してください。

3. VDC を作成します。

単一サイトへの VDC の作成（33 ページ）を参照してください。

4. 少なくとも 1 つのレプリケーショングループを作成します。

レプリケーショングループの作成（38 ページ）を参照してください。

a. オプション：認証を設定します。ECS に AD（Active Directory）、LDAP、Keystone認証プロバイダーを追加して、ECS の外部システムでユーザーを認証できるようにすることができます。認証プロバイダーの概要（44 ページ）を参照してください。

5. 少なくとも 1 つのネームスペースを作成します。ネームスペースは、テナントに相当します。

ネームスペースの作成（57 ページ）を参照してください。

a. オプション：オブジェクトユーザーおよび/または管理ユーザーの作成

ECS ポータルでのユーザーの操作（73 ページ）を参照してください。

6. 少なくとも 1 つのバケットを作成します。

バケットの作成（90 ページ）を参照してください。

初期 VDC を構成した後、追加の VDC を作成し、最初の VDC を連携させる場合は、連携への VDC の追加（34 ページ）を参照してください。

ECS Portal へのログインECS Portal にログインし、VDC の初期構成を設定する必要があります。任意のノードの IP アドレスまたは FQDN（完全修飾ドメイン名）か、ECS へのフロントエンドとして機能するロードバランサーを指定することにより、ブラウザから ECS Portal にログインします。ログイン手順について、次に説明します。はじめにECS Portal へのログインには、システム管理者ロール、システム監視者ロール、ロック管理者（emcsecurity ユーザー）ロール、またはネームスペース管理者ロールが必要です。

ECS の使用開始


最初に ECS Portal ログインする場合、システム管理者ロールを持つデフォルト root ユーザーとしてログインします。

手順1. システムの最初のノードのパブリック IP アドレス、またはフロントエンドとして構成されたロードバランサーのアドレスを、次のブラウザのアドレスに入力します。https://<node1_public_ip>。

2. デフォルト root認証情報を使用して、ログインします。l ［ユーザー名：］rootl ［パスワード：］ChangeMeメッセージが表示されたら、すぐに root ユーザーのパスワードを変更します。

3. 初回ログイン時にパスワードを変更した後、［Save］をクリックします。

ログアウトされ、ECS のログインスクリーンが表示されます。4. ［User Name］と［Password］を入力します。5. ECS Portal の右上隅のメニューバーで、ユーザー名の横にある矢印をクリックし、［Logout］をクリックします。

図 2 ポータルからログアウトします。

Getting Started Task Checklistの表示ECS Portal の Getting Started Task Checklist では、ECS の初期構成について説明します。最初にログインし、初期構成が完了していないことをポータルが検出すると、チェックリストが表示されます。チェックリストは、閉じられるまで、自動的に表示されます。任意の ECS Portal ページの右上のメニューバーで、［Guide］アイコンをクリックして、チェックリストを開きます。図 3 ［Guide］アイコン

Getting Started Task Checklistは、ポータルに表示されます。

ECS の使用開始

Getting Started Task Checklist の表示 21

図 4 Getting Started Task Checklist

1. チェックリストの現在のステップです。2. 完了済みのステップです。3. オプションのステップです。このステップでは、ステップを完了している場合でも、チェックマークは表示されません。

4. 現在のステップについての情報です。5. 選択可能なアクション6. このチェックリストを閉じます。完了したチェックリストには、もう一度リストを参照するか、構成を再確認するためのオプションが表示されます。

ECS Portal ダッシュボードの表示ECS Portal ダッシュボードには、現在ログインしている VDC の ECS プロセスに関する重要な情報が表示されます。ダッシュボードは、ログイン後に最初に表示されるページです。各パネル（ボックス）のタイトルは、監視している箇所をより詳細に表示する［Portal Monitoring］ページへのリンクになっています。

ECS の使用開始


図 5 ECS ダッシュボード

右上のメニューバー各 ECS Portal ページの右上にメニューバーが表示されます。図 6 右上のメニューバー

1 42 3 5

メニューアイテムには、次のアイコンとメニューが含まれます。1.［Alert］アイコンに表示される数字は、現在の VDC に対して保留中の未確認アラートの数を示しています。99件以上ある場合は、99+と表示されます。［Alert］アイコンをクリックして［Alert］メニューを表示すると、現在の VDC で直近の 5 つのアラートを表示できます。

2.［Help］アイコンを選択すると、現在のポータルページに対するオンラインドキュメントが表示されます。

3.［Guide］アイコンを選択すると、Getting Started Task Checklist が開始されます。4.［VDC］メニューには、現在の VDC の名前が表示されます。AD または LDAP の認証情報により複数の VDC へのアクセスが許可されている場合は、認証情報を再入力しなくてもポータルの表示を別の VDC に切り替えることができます。

5.［User］メニューには現在のユーザーが表示され、ログアウトもここから行います。

ECS の使用開始

右上のメニューバー 23

リクエストの表示［リクエスト］パネルには、リクエストの総数、成功したリクエスト、失敗したリクエストが表示されます。失敗したリクエストは、システムエラーとユーザーのエラーです。ユーザーの障害は、通常 HTTP400 エラーです。システムの障害は、通常 HTTP 500 エラーです。［リクエスト］をクリックして、さらにリクエストのメトリックを表示します。

容量使用率の表示［容量使用率］パネルには、合計、使用済み、使用可能な容量が表示されます。グラフの中央には、現在使用中の有効容量の割合が表示されます。容量には、取得データ、レプリカ、システムデータが考慮に入れられます。［容量使用率］をクリックして、さらに容量メトリックを表示します。

パフォーマンスを表示［Performance］パネルには、ネットワークの読み取りおよび書き込み処理の現在の実行状況と過去 24時間の読み取り/書き込みのパフォーマンスの平均が表示されます。［Performance］をクリックして、包括的なパフォーマンスメトリックを表示します。

ECS の使用開始


ストレージの効率性の表示［ストレージの効率性］パネルには、EC（消失訂正符号）プロセスの効率性が表示されます。チャートには現在の EC プロセスの進行状況が表示され、その横には EC プロセス待ちの EC データ量と EC プロセスの現在のレートが表示されます。［ストレージの効率性］をクリックして、さらにストレージ効率性のメトリックを表示します。

Geo Monitoring の表示［Geo Monitoring］パネルには、ジオレプリケーション待ちのローカル VDC のデータ量とレプリケーションのレートが表示されます。［RPO］（目標復旧時点）とは、リカバリ可能な過去のポイントです。この値は、レプリケーションの完了前にローカル VDC に障害が発生した場合に、消失のリスクがある最も古いデータを示します。［Failover Progress］には、ローカル VDC にかかわるフェデレーションで発生したあらゆるアクティブなフェールオーバーの進行状況が表示されます。［Bootstrap Progress］には、フェデレーションに新しい VDC を追加するためのあらゆるアクティブなプロセスの進行状況が表示されます。［GeoMonitoring］をクリックして、さらにジオレプリケーションメトリックを表示します。

ECS の使用開始

ストレージの効率性の表示 25

ノードとディスクの正常性を表示［ノードとディスク］パネルには、ディスクおよびノードの正常性のステータスが表示されます。ノード数またはディスク数の横にある緑色のチェックマークは、正常状態のディスク数またはノード数を示します。赤色の xは、悪い状態を示します。［ノードとディスク］をクリックして、ハードウェアの正常性メトリックをさらに表示します。不良なディスク数またはノード数がゼロ以外の数値である場合は、カウントをクリックすると、［システムの正常性］ページの対応する［ハードウェアの正常性］タブ（［オフラインディスク］または［オフラインノード］）に移動します。

アラートの表示［Alerts］パネルには、重要なアラートおよびエラーの数が表示されます。［Alerts］をクリックすると、現在のアラートの全リストが表示されます。すべてのクリティカルまたはエラーのアラートが［イベント］ページの［Alerts］タブにリンクされ、ここでクリティカルまたはエラーの重要度のアラートのみがフィルタされ、表示されます。

ECS の使用開始


第 3章

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

l ストレージプール、VDC、レプリケーショングループの概要.............................................28l ECS Portal でのストレージプールの扱い..................................................................29l ECS Portal での VDC の扱い ............................................................................... 32l ECS Portal でのレプリケーショングループの扱い........................................................ 37

ストレージプール、VDC、レプリケーショングループ 27

ストレージプール、VDC、レプリケーショングループの概要このトピックでは、ストレージプール、VDC（仮想データセンター）、レプリケーショングループについての概念的な情報を説明し、次のトピックで、それらを構成するために必要な操作について説明します。l ECS Portal でのストレージプールの扱いl ECS Portal での VDC の扱いl ECS Portal でのレプリケーショングループの扱いVDC に関連付けられているストレージはストレージプールに割り当てられる必要があり、ストレージプールは、1個以上のレプリケーショングループに割り当てられ、バケットとオブジェクトを作成する必要があります。ストレージプールを、1個以上のレプリケーショングループに関連づけできます。ベストプラクティスは、サイトに 1個のストレージプールがあることです。ただし、各プール内に最低 4 ノード（かつ 16台のディスク）で、必要に応じて多くのストレージプールを持つことがができます。次の理由により、単一のサイトで 1個以上のストレージプールを作成する必要があります。l ストレージプールを、コールドアーカイブに使用します。コールドアーカイブで使用する消失訂正

符号スキームは、デフォルト ECS の 12+4符号化ではなく、10+2符号化を使用して設定します。

l テナントには、別の物理メディアに保存するデータが必要です。ストレージプールには 4 ノード以上が必要で、書き込みができるように 10%を超える空き容量のあるノードが 3 ノード以上必要です。この予約済み領域は、ECS でシステムメタデータを保持している間に容量不足にならないために必要です。この条件が満たされていない場合、書き込みは失敗します。ストレージプールで書き込みを受け入れる能力は、他のプールで書き込みを受け入れる能力には影響しません。たとえば、書き込みの失敗を検出すると、ロードバランサーが別の VDC にリダイレクトします。ECS がレプリケーショングループを使用して、データを別のサイトにレプリケートすることで、データを保護して、別のアクティブなサイトからアクセスできます。バケットを作成する際に、それの入っているレプリケーショングループ内で指定します。ECS では、バケットとバケット内のオブジェクトを、レプリケーショングループ内のすべてのサイトにレプリケートしたことを確認します。ECS では、1個以上のレプリケーションスキームを使用して、データにアクセスして保護する要件によって、構成できます。次の図に、すべての 3 つのサイトにまたがるレプリケーショングループ（RG 1）を示します。RG 1 では、次の 3 つ以上のサイトを使用する場合、ECS によって提供される XOR ストレージ効率を利用します。2 つのサイトにまたがるレプリケーショングループ（RG 2）の図には、オブジェクトデータチャンクのフルコピーがあり、XOR を使用しないためストレージ効率は向上しません。



図 7 3 つのサイトにまたがるレプリケーショングループと、2 つのサイトをまたがるレプリケーショングループ

VDC C

VDC AVDC B

SP 1VDC C

SP 2

Federation

RG 1 (SP 1,2,3)

RG 2 (SP 1,3)

Rack 1

Rack 1

Rack 1

RG 1RG 1

SP 3

各サイトでレプリケーショングループを使用する物理ストレージは、レプリケーショングループに含まれているストレージプールによって決定されます。ストレージプールでは、4 つ以上の各ノードのディスクストレージを集約し、消失訂正符号フラグメントの配置に対応できます。ノードは、複数のストレージプールに存在できません。ストレージプールがラックをまたがることはできますが、サイト内に限られます。

ECS Portalでのストレージプールの扱いストレージプールを使用すれば、ビジネス要件に基づいてストレージリソースを整理できます。たとえば、データを物理的に分ける必要がある場合は、ストレージを複数のストレージプールに区分できます。［Storage Pool Management］ページ（表示するには［Manage］ > ［Storage Pools］を選択）を使用して、既存のストレージプールの詳細表示、新しいストレージプールの作成、既存のストレージプールの変更を行います。このリリースで、ストレージプールを削除することはできません。図 8 ［Storage Pool Management］ページ


ECS Portal でのストレージプールの扱い 29

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

フィールド説明

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

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

Status ストレージプールやノードの状態。

l Ready：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 ノードが設置されているラックに割り当てられた名前。

Actions このアクションは、ストレージプールで実行する。

l ［Edit］：ストレージプールの名前やストレージプール内のノードを変更する。l ［Delete］：カスタマーサポートがストレージプールを削除する場合に使用する。システム管理者または root ユ

ーザーがストレージプールを削除しようとする場合ではありません。ECS Portal でこの操作をしようとすると、この操作はサポートされていませんというエラーメッセージを受信します。ストレージプールを削除する必要がある場合は、カスタマーサポート担当者の担当者にお問い合わせください。

Cold Storage コールドストレージとして指定されているストレージプール。コールドストレージは、アクセス頻度の低いオブジェクトに対して EC（消失符号化）スキームをより効率的に使用します。コールドストレージはコールドアーカイブとも呼ばれます。ストレージプールを作成すると、この設定は変更できません。

ストレージプールの作成ストレージプールには、4 つ以上のノードを配置する必要があります。作成された最初のストレージプールは、システムメタデータを保存するため、システムストレージプールと呼ばれます。

はじめにこの操作には ECS のシステム管理者のロールが必要です。手順

1. ECS Portal で、［Manage］ > ［Storage Pools］を選択します。2. ［Storage Pool Management］ページで、［New Storage Pool］をクリックします。



3. ［New Storage Pool］ページの［Name］フィールドに、ストレージプール名（たとえば、StoragePool1）を入力します。

4. ［Cold Storage］フィールドで、このストレージプールがコールドストレージであるかどうかを指定します。コールドストレージには、アクセス頻度の低いデータが格納されます。コールドストレージ向け ECS データ保護スキームは、ストレージ効率を向上させるために最適化されます。ストレージプールを作成すると、この設定は変更できません。

コールドストレージには、最低 6 ノードのハードウェア構成が必要です。詳細については、ECS データ保護（14 ページ）を参照してください。

5. ［Available Nodes］リストから、ストレージプールに追加するノードを選択します。a. ノードを 1 つずつ選択するには、各ノードに並んでいる［+］アイコンをクリックします。b. 使用可能なすべてのノードを選択するには、［Available Nodes］リストの上部にある［+］アイコンをクリックします。

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

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


ストレージプールの作成 31

7. ストレージプールが［Ready］状態になった後、10分間待ってから、他の構成タスクを実行すると、ストレージプールの時刻を初期化できます。

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

ストレージプールの編集ストレージプールの名前やストレージプール内のノードを変更します。


1. ECS Portal で、［Manage］ > ［Storage Pools］を選択します。2. ［Storage Pool Management］ページで、編集するストレージプールを表で表示します。

編集するストレージプールの隣の［Actions］列で［Edit］をクリックします。3. ［Edit Storage Pool］ページで、次の手順に従います。

l ストレージプール名を変更するには、［Name］フィールドに、新しい名前を入力します。l ストレージプールに含まれるノードを変更します。

n ［Selected Nodes］リストで、ノードの横にある［-］アイコンをクリックして、ストレージプール内の既存のノードを削除します。

n ［Available Nodes］リストで、ノードの横にある［+］アイコンをクリックして、ストレージプールにノードを追加します。

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

ECS Portalでの VDCの扱いECS VDC（仮想化データセンター）は、ユニットとして管理する ECS インフラストラクチャコンポーネントのコレクションを示す最上位のリソースです。［Manage］ > ［Virtual Data Centers］で利用可能な［Virtual Data CenterManagement］ページを使用して、VDC の詳細表示、新しい VDC の作成、既存の VDC の変更、VDC の削除、複数サイト環境での複数の VDC の連携ができます。次の例は、連携させた複数サイト環境の［Virtual Data Center の管理］ページを示しています。vdc1 と vdc2 という名前の 2 サイトで構成されます。図 9 Virtual Data Center の管理ページ



表 6 VDC のプロパティ


Name VDC の名前。

Type ホストできる、またはオンプレミスの VDC タイプ。

Replication Endpoints サイト間のレプリケーションデータ通信用エンドポイント。レプリケーションネットワークが別に構成されている場合は、各ノードのレプリケーション IP アドレスを表示します。レプリケーションネットワークが別に構成されていない場合は、各ノードのパブリック IP アドレスを表示します。

レプリケーションネットワークも管理ネットワークも分離されていない場合、レプリケーションエンドポイントと管理エンドポイントは同一です。

ノードのレプリケーション IP アドレス間のロードを分散するロードバランサーを構成する場合、ロードバランサー上で構成されているアドレスを表示します。

Management Endpoints サイト間の管理コマンド通信用エンドポイント。管理ネットワークが別に構成されている場合は、各ノードの管理 IP アドレスを表示します。管理ネットワークが別に構成されていない場合は、各ノードのパブリック IP アドレスを表示します。

管理ネットワークもレプリケーションネットワークも分離されていない場合、管理エンドポイントとレプリケーションエンドポイントは同一です。

Status VDC の状態。

l オンラインl Permanently Failed：VDC が削除されている。

Actions このアクションは、VDC で実行できます。

l ［Edit］：VDC名、VDC アクセスキー、VDC レプリケーションと管理エンドポイントを変更します。l ［Delete］：VDC の削除。削除操作を実行すると、VDC の永続的なフェールオーバーがトリガーされるため、

同じ名前では再度 VDC を追加できなくなります。レプリケーショングループの一部になっている VDC を削除するには、まずレプリケーショングループからその VDC を削除する必要があります。ログインしている VDCは削除できません。

単一サイトへの VDC の作成単一サイト環境に VDC を作成したり、複数サイト連携で最初の VDC を作成したりできます。

はじめにこの操作には ECS のシステム管理者のロールが必要です。1 つ以上のストレージプールが使用可能であり、Ready状態であることを確認します。手順

1. ECS Portal で、［Manage］ > ［Virtual Data Center］を選択します。2. ［Virtual Data Center Management］ページで、［New Virtual Data Center］をク

リックします。3. ［New Virtual Data Center］ページの［Name］フィールドに、VDC名を入力します（例：VDC1）。

VDC名は、1 から 255文字を指定できます。有効な文字は、a～z、A～Z、0～9、ダッシュ（-）、アンダースコア（_）です。


単一サイトへの VDC の作成 33

4. VDC のアクセスキーを、次のように作成することもできます。l VDC アクセスキー値を［Key］フィールドに入力するか、l ［Generate］をクリックして、VDC アクセスキーを生成します。

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

5. ［Replication Endpoints］フィールドに、VDC に割り当てられているストレージプール内の各ノードのレプリケーション IP アドレスを入力します。コンマ区切りリストで入力してください。

ネットワークの分離がインストール時に構成されている場合、各ノードのレプリケーション IP アドレスが表示されます。レプリケーションネットワークの分離がインストール時に構成されている場合、各ノードのパブリック IP アドレスが表示されます。ノードのレプリケーション IP アドレス間のロードを分散するロードバランサーを構成する場合、ロードバランサー上で構成されているアドレスを表示します。

6. ［Management Endpoints］フィールドに、VDC に割り当てられているストレージプール内の各ノードの管理 IP アドレスを入力します。コンマ区切りリストで入力してください。

ネットワークの分離がインストール時に構成されている場合、各ノードの管理 IP アドレスが表示されます。管理ネットワークの分離がインストール時に構成されている場合、各ノードのパブリック IP アドレスが表示されます。


VDC を作成すると、ECS が自動的に VDC の［Type］を［On-Premise］または［Hosted］のいずれかに設定します。

連携への VDC の追加既存の VDC（vdc1など）に VDC を追加して連携を作成します。

はじめにroot ユーザーまたはシステム管理者認証情報を持つユーザーの［ECS Portal］認証情報を取得し、両方のサイトにログインします。追加するサイトのノードのパブリック IP アドレスがあることを確認します。管理ネットワークとレプリケーションネットワークが分離されている場合は、管理 IP アドレスとレプリケーション IP アドレスがあることを確認します。ノードのレプリケーション IP アドレス間のロードを分散するロードバランサーを構成する場合、ロードバランサー上で構成されているアドレスが必要です。追加するサイトに、有効な ECS ライセンスがアップロードされ、Ready状態のストレージプールが少なくとも 1 つあることを確認します。

フェデレーションに追加するサイトで VDC を作成しないことに注意してください。代わりに、追加するサイトで［VDC Access Key］を取得し、既存のフェデレーション内の最初のノードに新しいVDC を作成します。

手順1. 追加するサイト上では、ECS Portal（vdc2など）にログインします。

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

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



3. ［Virtual Data Center Management］ページで、［Get VDC Access Key］をクリックします。

4. アクセスキーを選択し、Ctrl+C を押してコピーします。5. 追加するサイトで、ECS Potal からログアウトします。6. フェデレーションの最初の VDC で、ECS Portal（vdc1など）にログインします。7. ［Manage］ > ［Virtual Data Center］を選択します。8. ［Virtual Data Center Management］ページで、［New Virtual Data Center］をク

リックします。9. ［New Virtual Data Center］ページの［Name］フィールドに、VDC名（vdc2など）

を入力します。10. ［Key］フィールドをクリックして、Ctrl+V を押し、追加するサイト（vdc2）からコピーしたア

クセスキーをペーストします。11. ［Replication Endpoints］フィールドと［Management Endpoints］フィールドに、追

加するサイトに割り当てられているストレージプール内の各ノードのレプリケーション IP アドレスと管理 IP アドレスを入力します。コンマ区切りリストで入力してください。レプリケーションネットワークまたは管理ネットワークを分離しない場合は、VDC のノードと同じパブリック IP アドレスが両方のフィールドに含まれます。管理ネットワークおよびレプリケーションネットワークが分離されている場合、適切なネットワークの IP アドレスをリストに表示する必要があります。ノードのレプリケーション IP アドレス間のロードを分散するロードバランサーを構成する場合、レプリケーションエンドポイントはロードバランサー上で構成されている IP アドレスです。


結果VDC をフェデレーションに追加すると、ECS が VDC のタイプを自動的に［On-Premise］または［Hosted］のいずれかに設定します。

VDC の編集VDC名、VDC アクセスキー、VDC レプリケーションと管理エンドポイントを変更します。


1. ECS Portal で、［Manage］ > ［Virtual Data Center］を選択します。2. ［Virtual Data Center Management］ページで、編集する VDC を表で表示します。編

集する VDC の隣の［Actions］列で［Edit］をクリックします。3. ［Edit Virtual Data Center］ページで、次の手順に従います。

l VDC名を変更するには、［Name］フィールドに、新しい名前を入力します。l ログインするノードの VDC アクセスキーを変更するには、［Key］フィールドで新しいキーの値を入力するか、［Generate］をクリックして、新しい VDC アクセスキーを生成します。

l VDC内のノードのレプリケーションと管理 IP アドレスを変更するには、［ReplicationEndpoints］フィールドと［Management Endpoints］フィールドに、コンマ区切りリストで、新しい IP アドレスを入力します。ネットワークの分離が構成されていない場合、レプリケーション IP アドレスと管理 IP アドレスは同じです。


VDC の編集 35

VDC の［Type］フィールドを編集することはできません。最初に VDC を作成するときに、ECS がそのタイプを自動的に［On-Premise］または［Hosted］に決定します。


VDC の削除とサイトのフェールオーバーVDC を削除することができます。複数サイトの連携の一部となっている VDC を削除すると、サイトのフェールオーバーが開始されます。はじめにこの操作には ECS のシステム管理者のロールが必要です。

災害が発生した場合は、VDC全体がリカバリ不能になる可能性があります。ECSは、まずリカバリ不可能な VDC の一時的なサイトの障害として処理します。障害が継続する場合は、連携からVDC を削除してフェールオーバー処理を開始し、障害が発生した VDC に格納されたオブジェクトを再構築して再度保護する必要があります。リカバリタスクはバックグラウンド処理として実行されます。連携から VDC を削除するには、それが属しているすべてのレプリケーショングループから VDC を削除する必要があります。［重要：］次の手順を実行する前に、カスタマーサポート担当者担当者に問い合わせ、システムから VDC を削除する前に必要な内部構成の手順を実行します。手順

1. 連携している操作可能な VDC のいずれかにログインします。2. ECS Portal で、［Manage］ > ［Replication Group］を選択します。3. ［Replication Group Management］ページで、削除する VDC が含まれたレプリケーシ

ョングループの隣にある、［Edit］をクリックします。4. ［Edit Replication Group］ページの削除する VDC とストレージプールを含む列で、［Delete］をクリックします。

5. ［Save］をクリックします。6. 削除する VDC が含まれているすべてのレプリケーショングループに対して、ステップ 3～5 を

繰り返します。7. ECS Portal で、［Manage］ > ［VDC］を選択します。［Virtual Data Center Management］ページで、完全に削除された VDC のステータスを Permanently failed に変更します。

8. ［Virtual Data Center Management］ページで、Permanently failed ステータスである VDC の行にある、［Actions］列の［Delete］を選択します。


結果［Monitor］ > ［Geo Replication］ > ［Failover Processing］ページで、リカバリプロセスの進行状況を表示することができます。

その VDC にのみ属するレプリケーショングループを持つ VDC を削除VDC を削除するには、その VDC のみに属するレプリケーショングループが含まれている場合、VDCを削除する前に、レプリケーショングループに別の VDC を追加する必要があります。

はじめにこの操作には ECS のシステム管理者のロールが必要です。



削除する VDC のみに属するレプリケーショングループがある場合、VDC を削除する前に、レプリケーショングループに別の VDC を追加する必要があります。これが必要なのは、ECS では削除するレプリケーショングループをサポートしていないためです。たとえば、VDC1 にレプリケーショングループRG1 がある場合、地理的連携の設定を検討します。RG1は、VDC1 のみに属しています。VDC2には、RG2 があります。RG2は、VDC2 のみに属しています。VDC1 を削除するには、次の操作を行う必要があります。手順

1. ［Edit Replication Group RG1］ページで、［Add VDC］をクリックし、RG1 に VDC2 を追加します。


次のエラーメッセージが表示されます。Error 30026 (http: 503): Serviceis busy. The Data services system is busy. Please tryagain. このエラーメッセージは無視します。

［Save］をクリックすると、レプリケーショングループの［Name］フィールドが空白になります。

3. VDC1 の隣にある［Delete］ボタンをクリックします。

［You must confirm that you understand the consequence of this delete ］ダイアログが表示されます。このダイアログは、RG1 から VDC1 を削除することで、地理的に連携しているシステムから VDC1 を完全に削除することを通知しています。

4. ダイアログボックスの空白フィールドに、Please remove VDC1 (PermanentlyFailed) from the system と入力します。

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

VDC1は、RG1 から削除されました。これで RG1は、VDC2 のみに属しています。VDC1は、ECS の地理的に連携しているシステムから完全に削除されます。

6. ［Edit Replication Group］ページで、［Name］フィールドの空白に、RG1 を入力します。

7. ［Save］をクリックします。8. ［Virtual Data Center Management］ページで、Permanently failed ステータ

スである VDC1 の横にある、［Actions］列の［Delete］を選択します。9. ［Save］をクリックします。

ECS Portalでのレプリケーショングループの扱いレプリケーショングループを使用して、ストレージプールのコンテンツを保護する場所を定義できます。レプリケーショングループは、ローカルにもグローバルにも作成できます。ローカルレプリケーショングループはデータを別の VDC にレプリケートしませんが、ミラーリングと消失訂正符号技術を使用して、ディスクやノードの障害に対し、同じ VDC内のオブジェクトを保護します。グローバルレプリケーショングループでは、ECS統合内の別のサイトにレプリケートすることでオブジェクトを保護し、これによって、サイトの障害から保護します。［Manage Replication Groups］ページを使用して、レプリケーショングループの詳細表示、新しいレプリケーショングループの作成、既存のレプリケーショングループの変更を行います。このリリースでは、レプリケーショングループの削除はできません。


ECS Portal でのレプリケーショングループの扱い 37

図 10 ［Replication Group Management］ページ

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


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

Replication Type レプリケーションタイプは、Geo Active または Geo Passive にできます。Geo Passive では、サイトがレプリケーションデータのターゲットとして設計され、実際に 3 サイトが存在する場合にのみ使用可能です。［Replicate to All Sites］が有効化されている場合、Geo Passive を選択することはできません。ホスティングサイトがある場合、Geo Passive構成でのレプリケーションのターゲットとして自動的に選択されます。

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

Storage Pool ストレージプールと関連 VDC の名前。レプリケーショングループには、統合された中の各 VDC のストレージプールを含めることができます。

Replication Target Geo Passive構成でのレプリケーションターゲットになっているレプリケーショングループ内のストレージプール。

Status レプリケーショングループの状態。

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

ョントラフィックが［Temp Unavailable］状態の場合は、障害の原因を詳しく調査することをお勧めします。

Actions レプリケーショングループで実行できるアクション。［Edit］：レプリケーショングループ名を変更したり、レプリケーショングループ内の VDCやストレージプールを変更します。

レプリケーショングループの作成レプリケーショングループは VDC に対してローカルであることが可能であり、またサイト間でデータをレプリケートすることでデータを保護できます。はじめにこの操作には ECS のシステム管理者のロールが必要です。複数の VDC にわたるレプリケーショングループが必要な場合は、サイトがインストール済みであり、レプリケーショングループに属することができる VDC ID とストレージプールで初期化されていることを確認する必要があります。



手順1. ECS Portal で、［Manage］ > ［Replication Group］を選択します。2. ［Replication Group Management］ページで、［New Replication Group］をクリッ

クします。3. ［New Replication Group］ページの［Name］フィールドに、名前（たとえば、

ReplicationGroup1）を入力します。4. オプションとして、このレプリケーショングループの［Replicate to All Sites］を有効化しま

す。このオプションは作成時にのみ有効化でき、後から無効化することはできません。Geo-Passive構成では、［Disabled］を選択します。

オプション説明［Disabled］をすべてのサイトにレプリケートします。

レプリケーショングループは、デフォルトレプリケーションを使用します。デフォルトレプリケーションでは、プライマリサイトにデータが格納され、レプリケーショングループ内のサイトから選択したセカンダリサイトにフルコピーが格納されます。セカンダリコピーは、トリプルミラーリングと消失符号化によって保護されます。これにより、データの耐久性とストレージ効率が実現します。

有効化されたサイトすべてをレプリケート

レプリケーショングループでは、レプリケーショングループ内のすべてのサイト（VDC）に、すべてのオブジェクトの完全に読み取り可能なコピーが作成されます。オブジェクトの完全に読み取り可能なコピーがすべての VDC の全データがレプリケーショングループにあるため、データの耐久性に優れ、すべてのサイトでローカルパフォーマンスが改善しますが、ストレージの効率性は低下します。

5. ［レプリケーションタイプ］を選択します。［Geo-Active］または［Geo-Passive］です。

Geo-Passiveは、次の 3 つ以上のサイトがある場合にのみ使用できます。

6. ［Add VDC］をクリックして、ストレージプールをサイトからレプリケーショングループに追加します。ストレージプールをレプリケーショングループに追加する手順は、単一のサイト、Geo-Active環境、Geo-Passive環境があるかどうかによります。

7. ストレージプールを Geo-Active（または単一のサイト）構成に追加するには、次の手順を使用します。a.［Virtual Data Center］リストで、レプリケーショングループのストレージプールを提供する VDC を選択します。


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

b.［Storage Pool］リストで、選択した VDC に属するストレージプールを選択します。c. レプリケーショングループにその他のサイトを追加するには、［Add VDC］をクリックします。

d. レプリケーショングループに追加するストレージプールごとに、これらの手順を繰り返します。

8. Geo-Passive構成のストレージプールを追加するには、次の手順を実行します。

［Geo-Passive］構成で、ECSはパッシブレプリケーションターゲットとしての 1 つのサイトと2 つのアクティブサイトを追加することができます。



a.［Target VDC for Replication Virtual Data Center］リストで、レプリケーションターゲットとして追加するサイトを選択します。ホスティングサイトがある場合、レプリケーションターゲットとして自動的に選択されます。

b.［Target VDC for Replication Storage Pool］リストで、選択した VDC に属するストレージプールを選択します。

c. 2 つの［Source VDC for Replication Virtual Data Center］リストのそれぞれで、アクティブサイトとして追加するサイトを選択します。

d. 2 つの［Target VDC for Replication Storage Pool］リストのそれぞれで、選択した VDC に属するストレージプールを選択します。これらのストレージプールでは、2 つのアクティブサイトでストレージを提供します。


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


レプリケーショングループの編集レプリケーショングループ名を変更したり、レプリケーショングループ内の VDCやストレージプールを変更したりできます。はじめにこの操作には ECS のシステム管理者のロールが必要です。

複数サイト連携で、レプリケーショングループを編集し、属しているレプリケーショングループからVDC を削除する場合、連携から VDC を完全に削除します。連携から VDC を完全に削除すると、その VDC（およびストレージプール）が所有するオブジェクトが残りの VDCのいずれかによって所有されている場合、フェールオーバープロセスが発生します。ECSでは、各オブジェクトにプライマリ、または所有する VDCがあります。このフェールオーバープロセスの完了に要した時間は、移動する必要があるデータの量によって異なります。［Replicate to All Sites］オプションを有効化してレプリケーショングループを作成した場合、すべてのサイトにコピーが存在するため、すべてのデータを残りのサイトに移行するのにかかる時間は短くなります。

［Replicate to All Sites］フィールドと［Replication Type］フィールドは編集できません。レプリケーショングループを最初に作成するときに、これらのオプションを設定すると、変更できません。

手順1. ECS Portal で、［Manage］ > ［Replication Group］を選択します。2. ［Replication Group Management］ページで、編集するレプリケーショングループの隣

にある、［Edit］をクリックします。3. ［Edit Replication Group］ページで、次の手順に従います。

l レプリケーショングループ名を変更するには、［Name］フィールドに新しい名前を入力します。

l レプリケーショングループに VDC を追加するには、［Add VDC］をクリックして、リストから VDC とストレージプールを選択します。

l レプリケーショングループから VDC を削除するには、VDC（およびそのストレージプール）の横にある［Delete］ボタンをクリックします。

VDC を属しているレプリケーショングループから削除すると、連携から完全にこのVDC を削除することになります。VDCの削除とサイトのフェールオーバー（36 ページ）を参照してください。




第 4章

認証プロバイダー

l 認証プロバイダーの概要......................................................................................... 44l ECS Portal での認証プロバイダーの操作.................................................................44

認証プロバイダー 43

認証プロバイダーの概要ECS外部のシステムでユーザーを認証する場合、ECS に認証プロバイダーを追加できます。認証プロバイダーとは、ECS に代わってユーザーを認証することができる ECS外部のシステムです。認証プロバイダーに接続できる情報を ECS に格納することで、ECS からユーザーの認証を要求できます。ECS では、次のタイプの認証プロバイダーを利用できます。l AD（Active Directory）認証または LDAP（Lightweight Directory Access Protocol）

の認証 ECS で管理ロールに割り当てられているドメインユーザーの認証に使用されます。l Keystone：OpenStack Swift オブジェクトユーザーの認証に使用されます。認証プロバイダーは、ECS ポータル（「ECS Portal での認証プロバイダーの操作（44 ページ）」を参照）から作成するか、または ECS管理 REST API または CLI を使用して作成します。次の手順に従って、AD/LDAP または Keystone の認証プロバイダーを作成します。l AD または LDAP認証プロバイダーの追加（45 ページ）l Keystone認証プロバイダーの追加（49 ページ）

ECS Portalでの認証プロバイダーの操作［Manage］ > ［Authentication］から利用可能な［Authentication ProviderManagement］ページを使用して、既存の認証プロバイダーの詳細の表示、認証プロバイダーの追加、既存の認証プロバイダーの変更、認証プロバイダーの削除ができます。図 11 ［Authentication Provider Management］ページ

表 8 認証プロバイダーのプロパティ


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

Type 認証プロバイダーのタイプ。認証プロバイダーが、AD（Active Directory）、LDAP（Lightweight Directory

Access Protocol）、Keystone V3 のいずれかです。

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

Enabled 認証プロバイダーが有効化されているか無効化されているかのどちらであるかを示す。

Actions このアクションは、認証プロバイダーで実行できます。



表 8 認証プロバイダーのプロパティ（続き）


l ［Edit］：表 9 （46 ページ）に記載されている AD または LDAP認証プロバイダーの設定を変更するか、表 10 （50 ページ）に記載されている Keystone認証プロバイダーの設定を変更します。

l ［Delete］：認証プロバイダーを削除します。l ［New Authentication Provider］ボタン：認証プロバイダーを追加します。

Active Directory認証プロバイダーを追加する際の考慮事項AD（Active Directory）と動作するように ECS を設定する場合は、複数ドメインを管理する単一の AD認証プロバイダーを追加するか、または各ドメインに対する個別の認証プロバイダーを追加するかを決定する必要があります。単一の AD認証プロバイダーを追加するか、複数の認証プロバイダーを追加するかについての決定は、環境内のドメイン数およびマネージャユーザーが検索可能なツリーでの場所によります。認証プロバイダーには検索を開始する場所に単一の検索ベースがあり、単一のマネージャアカウントには検索ベースレベル以下に読み取りアクセス権があります。次の条件下では、複数のドメインに単一の認証プロバイダーを追加できます。l AD フォレストを管理します。l マネージャアカウントには、ツリー内ですべてのユーザーエントリーを検索できる権限を持たせるl 検索は、単一の検索ベースから、プロバイダーにリストされているドメインだけではなく、フォレスト

全体に対して実行するそれ以外の場合は、各ドメインで個別の認証プロバイダーを追加します。

AD フォレストを管理し、必要なマネージャアカウントの権限がある場合、各ドメインの認証プロバイダーをさらに追加するシナリオがあります。たとえば、各ドメインの厳格な管理および設定上の高い細分性が必要な場合の、その検索用の検索ベースの起点です。

検索ベースは、目的のドメイン内のすべてのユーザーを正しく見つけられるよう、フォレストのディレクトリ構造において十分に高度である必要があります。次の検索例では、いずれか 1 つまたは複数の認証プロバイダーを追加するための最善のオプションについて説明します。l 10個のドメインを含む構成内のフォレストで、3個のみを対象とするシナリオでは、単一の認証

プロバイダーを追加して複数ドメインを管理する必要はありません。検索をフォレスト全体に展開する必要がないからです。パフォーマンスに悪影響を及ぼす場合があります。この例では、ドメインごとに 3 つの個別の認証プロバイダーを追加する必要があります。

l 構成内のフォレストに 10個のドメインが含まれ、10個のドメインをターゲットにするシナリオでは、単一の認証プロバイダーを追加して複数ドメインを管理することをお勧めします。少ないオーバーヘッドで設定できるためです。

AD または LDAP認証プロバイダーの追加ECS ドメインユーザーのユーザー認証を実行するには、1 つ以上の認証プロバイダーを ECS に追加します。


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

はじめにl この操作には ECS のシステム管理者のロールが必要です。l AD/LDAP認証プロバイダーの設定に記載されている認証プロバイダー情報を入手する必要

があります。マネージャー DN ユーザーに対する要件に特に注意します。手順

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

Provider］をクリックします。3. ［New Authentication Provider］ページで、フィールドの値を入力します。これらのフィー

ルドの詳細については、AD/LDAP認証プロバイダーの設定を参照してください。4. ［Save］をクリックします。5. 設定を確認するには、［Manage］ > ［Users］ > ［Management Users］を選択し

て認証プロバイダーからユーザーを追加し、新しいユーザーとしてログインを試みます。必要条件これらのユーザーに ECS オブジェクトユーザーの操作を実行させる場合は、ネームスペースにドメインユーザーを追加（割り当て）する必要があります。詳細については、ネームスペースへのドメインユーザーの追加（79 ページ）を参照してください。

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

表 9 AD または LDAP認証プロバイダーの設定

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

Name 認証プロバイダーの名前。異なるドメインで複数のプロバイダーを持つことができます。

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

Type 認証プロバイダーのタイプ。Active Directory または LDAP。

Domains 共通ディレクトリデータベース、セキュリティポリシー、信頼関係を共有する、管理上定義されたオブジェクトのコレクション。ドメインは複数の物理的な場所またはサイトに展開することができ、何百万ものオブジェクトを含むことができます。例：mycompany.com代替 UPN サフィックスが Active Directory で構成されている場合は、ドメインフィールドにはそのドメイン用に構成された代替 UPN も含まれている必要があります。たとえば、myco が mycompany.com の代替 UPN サフィックスとして追加された場合、ドメインフィールドには myco と mycompany.com が両方含まれている必要があります。

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

1 つ以上の LDAP または LDAPS認証プロバイダーを指定できます。

例：ldap://<Domain controller IP>:<port>（デフォルトポートでない場合）または ldaps://<Domain controller IP>:<port>（デフォルトポートでない場合）



表 9 AD または LDAP認証プロバイダーの設定（続き）


認証プロバイダーがマルチドメインフォレストをサポートしている場合は、グローバルカタログサーバー IP を使用し、常にポート番号を指定します。LDAP用のデフォルトポートは 3268 です。LDAPS用のデフォルトポートは 3269

です。

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

Manager DN ECS が Active Directory または LDAP サーバへの接続に使用する Active Directoryバインドユーザーアカウント。このアカウントは、ECS管理者がロールの割り当てのためにユーザーを特定する場合に、Active Directory の検索に使用されます。

このユーザーアカウントは、Active Directory に Read all inetOrgPerson information を持つ必要があります。InetOrgPerson オブジェクトクラスは、いくつかのMicrosoft以外の LDAP および X.500 ディレクトリサービスで使用され、組織内のユーザーを表します。

Active Directory で、この権限を次のようにして設定します。

1.［Active Directory Users and Computers］を開きます。2. ドメインを右クリックし、［Delegate Control］を選択し、［Next］をクリックします。3.［Delegation of Control］ウィザードで、［Next］をクリックし、［Add］をクリックします。4.［Select Users, Computers, or Groups］ダイアログボックスで、managerdn を使用してユーザーを選択し、［Next］をクリックします。

5.［Tasks to Delegate］ページの［Delegate the following common tasks］で、Read allinetOrgPerson information タスクを確認し、［Next］をクリックします。

6.［Finish］をクリックします。この例では次のとおりです。CN=Manager,CN=Users,DC=mydomaincontroller,DC=com、Active

Directoryバインドユーザーは、mydomaincontroller.com ドメインの Users のツリーの Manager です。通常、managerdnは管理者より少ない権限を持つユーザーですが、ユーザー属性やグループ情報を Active

Directory にクエリーするための十分な権限があります。

［重要：］ managerdn の認証情報が Active Directory で変更された場合は、ECS でこのユーザーアカウントを更新する必要があります。

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

［重要：］ managerdn の認証情報が Active Directory で変更された場合は、ECS でこのパスワードを更新する必要があります。

Providers 認証プロバイダーを追加する場合に、この設定はデフォルトで有効化されます。ECSは、有効な認証プロバイダーの接続性と、有効な認証プロバイダーの名前とドメインが一意であることを確認します。ECS に認証プロバイダーを追加する場合にのみ［Disabled］を選択しますが、すぐには認証に使用できません。ECSは無効化された認証プロバイダーの接続性を確認しませんが、認証プロバイダーの名前とドメインが一意であることを確認します。

Group Attribute この属性は、Active Directory のみに適用されます。つまり、他の認証プロバイダーのタイプには適用されません。グループの識別に使用する AD属性。グループによるディレクトリの検索に使用されます。

例：CN


AD または LDAP認証プロバイダーの追加 47



この属性を AD認証プロバイダーに設定すると、変更できません。このプロバイダーを使用しているテナントは、現在の属性を使用しているフォーマットでグループ名を使用して構成されたロールの割り当てと権限をすでに持っていることがあるからです。

Group Whitelist この設定は、Active Directory のみに適用されます。つまり、他の認証プロバイダーのタイプには適用されません。

オプションです。認証プロバイダーによって定義された 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 グループをユーザーマッピングしたネームスペースに追加します。これらのグループのユーザーのみを受け入れるよ

う、ネームスペースを構成します。l そのグループをホワイトリストに追加します。ECSはそれらの情報を受け取ることが許可されます。

デフォルトでは、ネームスペースユーザーマッピングにグループが追加されなかった場合は、ホワイトリストの設定にかかわらず、どのグループのユーザーでも受け入れられます。

Search Scope 検索レベル。使用可能な値：l 1 レベル（検索ベースの下でユーザーを 1 レベルで検索）。l サブツリー（検索ベースの下でサブツリー全体を検索）。

Search Base ログイン時、ロールの割り当て時、ACL設定時に、ECS によってユーザーの検索に使用される基本識別名。次の例では、Users コンテナ内ですべてのユーザーを検索します。CN=Users,DC=mydomaincontroller,DC=com次の例では、myGroupUsers ユニット内のコンテナ内ですべてのユーザーを検索します。検索ベースの値の構造は、リーフレベルで始まり、ドメインコントローラレベルに上がります。逆の構造は［Active Directory Usersand Computers］スナップインで見られます。CN=Users,OU=myGroup,DC=mydomaincontroller,DC=com

Search Base ユーザーのサブセットを選択するために使用される文字列。例：userPrincipalName=%u





ECS では、認証プロバイダーを追加したときはこの値を検証しません。

Active Directory で代替 UPN サフィックスが構成されている場合、［Search Filter］値は sAMAccountName=%U形式である必要があります。%Uはユーザー名で、ドメイン名は含まれません。

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

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

入手します。手順

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

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

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


Keystone認証プロバイダーの追加 49

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


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

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


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

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

Type Keystone V3.

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

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

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



第 5章

ネームスペース

l ネームスペースの概要............................................................................................ 52l ネームスペーステナンシー....................................................................................... 52l ネームスペース設定............................................................................................... 53l ECS Portal でのネームスペースの操作.................................................................... 56

ネームスペース 51

ネームスペースの概要ネームスペースを使用して、複数のテナントが ECS オブジェクトストアにアクセスでき、各テナントのユーザーによって書き込まれたオブジェクトとバケットを他のテナントのユーザーから確実に分離します。このセクションのトピックでは、テナントとネームスペース設定に関するいくつかの概念を次のように説明します。l ネームスペース設定（53 ページ）l ECS Portal でのネームスペースの操作（56 ページ）また、ECS ポータルを使用してネームスペースを構成する際に必要な操作についても説明します。l ネームスペースの作成（57 ページ）ECS管理 REST API を使用して、ECS ポータルで実行できるネームスペースの構成タスクを実行することもできます。ECSは、複数のテナントによるアクセスをサポートします。各テナントはネームスペースによって定義され、ネームスペースに構成されたユーザーはネームスペース内のオブジェクトの保存やアクセスが可能です。あるネームスペースのユーザーは、別のネームスペースに属するオブジェクトにはアクセスできません。ネームスペースは、ECS のグローバルリソースです。システム管理者またはネームスペースの管理者は任意の連携 VDC で ECS にアクセスしてネームスペースの設定を構成することができます。ネームスペースに割り当てられたオブジェクトユーザーはグローバルであり、任意の連携 VDC からオブジェクトストアにアクセスできます。ネームスペースにアクセスできるユーザーを定義する属性や、ネームスペースの特性を定義する属性を使用して、ネームスペースを構成します。適切な権限を持つユーザーは、ネームスペースでバケットを作成し、バケット内にオブジェクトを作成できます。1 つのネームスペース内のオブジェクトは、別のネームスペースのオブジェクトと同じ名前にできます。ECSは、ネームスペース修飾子でオブジェクトを特定できます。ネームスペースを構成してその使用状況を監視および測定したり、管理権限をテナントに付与して構成、監視、測定の操作を実行したりできます。バケットを使用し、サブテナントを作成できます。バケットの所有者がサブテナントの管理者となり、ACL を使用してサブテナントにユーザーを割り当てることができます。ただし、サブテナントはテナントと同レベルに分離されません。テナントに割り当てられているすべてのユーザーにはサブテナントでの権限が割り当てられる可能性があるため、ユーザーへの割り当てを行うときには注意を払う必要があります。

ネームスペーステナンシーシステム管理者は、次のテナントシナリオのネームスペースを設定できます。エンタープライズシングルテナント

すべてのユーザーが、同じネームスペースのバケットとオブジェクトにアクセスします。サブテナントのバケットを作成することで、ネームスペースユーザーのサブセットは同じオブジェクトセットへアクセスできます。たとえば、サブテナントには組織内の部門である場合があります。

エンタープライズマルチテナント組織内の部門を異なるネームスペースに割り当て、それぞれのネームスペースに部門ユーザーを割り当てます。



クラウドサービスプロバイダーのシングルテナント単一のネームスペースを構成し、サービスプロバイダーは組織内外のユーザーにオブジェクトストアへのアクセス権を付与します。

クラウドサービスプロバイダーのマルチテナントサービスプロバイダーは企業別にネームスペースを割り当て、ネームスペースに管理者を割り当てます。テナントのネームスペース管理者は、ユーザーを割り当てて、バケットとオブジェクトの使用状況を監視および測定できます。

ネームスペース設定次の表で、ECS ネームスペースを作成または編集するときに指定できる設定を説明します。ECS のオブジェクトのアドレス指定におけるネームスペース名とバケット名の使用方法については、オブジェクトベース URL（144 ページ）を参照してください。

表 11 ネームスペース設定

フィールド説明編集可否

Name 小文字で、ネームスペースの名前を記載します。 ×

User Admin Namespace管理者ロールを割り当てる 1人または複数のユーザーのユーザー ID。ユーザーが複数の場合は、コンマで区切って一覧表示します。ネームスペース管理者は、ローカルユーザーでもドメインユーザーでも可能です。ネームスペース管理者をドメインユーザーにする場合は、認証プロバイダーが ECS に追加されていることを確認します。詳細については、ユーザーとロールの概要（64 ページ）を参照してください。

○

Domain Group Admin Namespace管理者ロールに割り当てられたドメイングループ。すべてのメンバーが認証されている場合、ネームスペースの Namespace管理者ロールに割り当てられます。ドメイングループを、ネームスペースの［Domain User Mappings］の設定で、ネームスペースに割り当てる必要があります。この機能を使用するためには、認証プロバイダーが ECS に追加済みである必要があります。詳細については、ユーザーとロールの概要（64 ページ）を参照してください。

○

Replication Group ネームスペースのデフォルトのレプリケーショングループ。 ○

Namespace Quota ネームスペースに対して指定されているストレージ領域の制限。ネームスペースのストレージ制限を指定し、クォータに達したときの通知とアクセス動作を定義します。ネームスペースのクォータの設定を、1 GB未満にすることはできません。次のクォータの動作のオプションから 1 つ選択します。

<quota>時のみ通知これに達すると通知が生成されるクォータ設定。

<quota>時のみアクセスをブロックハードクォータに達すると、バケットにアクセスしての作成/更新を禁止します。

<quota>でアクセスをブロックし、<% of quota>で通知を送信ハードクォータに達すると、バケットにアクセスしての作成/更新を禁止し、設定したクォータの割合（%）で通知します。

○

Default Bucket Quota このネームスペースで作成されたバケットに指定されているデフォルトのストレージの制限。ハードクォータに達すると、バケットにアクセスしての作成/更新を禁止します。

○


ネームスペース設定 53

表 11 ネームスペース設定（続き）


デフォルトバケットクォータを変更しても、すでに作成されているバケットのバケットクォータは変更できません。

Server-side Encryption このネームスペースで作成されたバケットに適用されるサーバ側暗号化のデフォルト値。サーバ側暗号化は、静止データ暗号化または D@RE と呼ばれ、ECS のディスクまたはドライブに格納する前にデータをインラインで暗号化します。この暗号化は、破棄されたメディアまたは盗難にあったメディアからの機密データの取得を防止します。

ネームスペースで暗号化を有効にした場合、すべてのバケットが暗号化され、バケットの作成時にこの設定を変更できません。ネームスペースでバケットを非暗号化するには、ネームスペースで暗号化が無効になっている必要があります。暗号化がネームスペースで無効化されている場合、個々のバケットを作成時に暗号化するよう設定できます。

機能の完全な説明については、ECS製品ドキュメントページ内の使用可能な「ECS セキュリティガイド」を参照してください。

×

Access During Outage 地理的連携を設定中の一時的なサイト停止時に、このネームスペース内に作成されたバケット内のデータにアクセスするときのデフォルトの動作です。

このフラグが有効化され、一時的なサイト停止が発生し、バケットが作成されている障害の発生しているサイト（所有者サイト）のバケットにアクセスできない場合、別のサイトのバケットのコピーにアクセスできます。ネームスペース内のバケット内のアクセスしたオブジェクトが障害の発生しているサイトで更新されても、オブジェクトにアクセスしているサイトに変更が反映されていない可能性があります。

フラグを無効化すると、一時的に停止したサイトのデータは他のサイトからアクセスできず、障害の発生しているサイトにあるデータのオブジェクトの読み取りは失敗します。

詳細については、有効化された ADOバケットプロパティを使用した TSO動作（170 ページ）を参照してください。

○

Compliance この規則では、保存中のオブジェクトに対する保存設定への変更を制限します。ECS には、オブジェクト、バケット、ネームスペースレベルで有効化し、定義するオブジェクト保存機能があります。コンプライアンスは、保存中のオブジェクトに対する保存設定への変更を制限することによって、これらの機能を強化します。

コンプライアンスはネームスペースの作成時にのみ有効化でき、有効化したあとは無効化できません。

コンプライアンスは、S3 と CAS システムでサポートされています。コンプライアンスによって適用されるルールに関する詳細については、ECS製品ドキュメントページ内の使用可能な「ECS データアクセスガイド」を参照してください。

×

Retention Policy 1 つ以上の保存ポリシーの追加と構成が可能。ネームスペースには１つ以上の保存ポリシーを関連づけることができ、それぞれのポリシーで保存期間を定義できます。個々のオブジェクトではなく、オブジェクトの数に、保存ポリシーを適用すると、保存ポリシーの変更時に、ポリシーを適用するすべてのオブジェクトの保存期間が変更されます。保存期間の有効期限が切れる前にリクエストされたオブジェクトの変更は許可されません。

多数のオブジェクトの保存ポリシーを指定することに加え、保存ポリシーとネームスペース全体のクォータを指定できます。

保存の詳細については、保存期間と保存ポリシー（55 ページ）を参照してください。

○

Domain AD または LDAP のドメインの指定と、ドメインのユーザーを含めるときのルールの構成ができます。

○





表 11 ネームスペース設定（続き）


ドメインユーザーは ECS管理ロールを割り当て、ECS のセルフサービス機能を使用してオブジェクトユーザーとして登録できます。

ドメインユーザーのネームスペースへのマッピングの詳細については、ドメインユーザーは、オブジェクトユーザーの操作を実行するために、割り当てられたネームスペースを必要とします。（66

ページ）を参照してください。

次の属性は、ECS ポータルからではなく、ECS管理 REST API を使用して設定します。Allowed (and Disallowed) Replication Groups

クライアントはネームスペースが使用するレプリケーショングループを指定できます。

保存期間と保存ポリシーECS には、指定した保存期間内でのデータの変更や削除を防止する機能があります。オブジェクトとバケットに関連づけられたメタデータで定義される保存期間と保存ポリシーを使用して、保存を指定できます。保存期間と保存ポリシーにより、作成されたオブジェクトを変更するリクエストがあるたびにチェックされます。保存期間は、すべての ECS オブジェクトプロトコル（S3、Swift、Atmos、CAS）でサポートされます。

CAS保存と高度な CAS保存を含む、オブジェクトインターフェイスでの保存の設定に関する詳細については、ECS製品ドキュメントページ内の使用可能な「ECS データアクセスガイド」を参照してください。

保存期間保存期間は、オブジェクトレベルまたはバケットレベルで割り当てられます。オブジェクトに対する変更または削除のリクエストがされるたびに、有効期限が算出されます。オブジェクトの有効期限は、オブジェクトの作成時間と保存期間の合計に等しくなります。バケットに保存期間が割り当てられている場合は、オブジェクトの保存期間とバケットの保存期間のいずれか長い方の値に基づいて、オブジェクトの有効期限が算出されます。

バケットに保存期間を適用する場合、バケット内のすべてのオブジェクトの保存期間はいつでも変更することができ、オブジェクトクライアントによってオブジェクトに書き込まれた値をより長い期間で上書きすることができます

オブジェクトの保存期間を無期限にすることもできます。

保存ポリシーネームスペースに関連づけられている保存ポリシーです。ネームスペースに関連づけられているすべてのポリシーを、ネームスペースに属するオブジェクトに割り当てることができます。保存ポリシーには、保存期間が関連づけられます。

ポリシーに関連づけられている保存期間を変更すると、そのポリシーが割り当てられているオブジェクトの保存期間が自動的に変更されます。

オブジェクトに保存ポリシーを適用できます。ユーザーがオブジェクトを変更または削除すると、保存ポリシーが取得されます。保存ポリシー内の保存期間を、オブジェクトの保存期間とバケットの保存期間で使用して、リクエストを許可するかどうかを確認します。

たとえば、次のような種類のドキュメントに対して保存ポリシーを定義して、各ポリシーに適切な保存期間を適用します。ユーザーが法的ドキュメントを作成した 4年後に変更または削除を


保存期間と保存ポリシー 55


リクエストする場合、バケットの保存期間またはオブジェクトの保存期間の大きい方を使用して、操作を実行するかどうかを確認します。この例では、リクエストが許可されていないので、さらに 1年間はドキュメントを変更も削除もできません。

l E メール：6 か月

l 財務：3年間

l 法務：5年間

ECS管理 REST API保存ポリシーの方法ECS Portal で実行される保存ポリシーの作成と構成のタスクは、ECS Management REST APIを使用して、実行できます。次の表では、保存ポリシーに関連する ECS Management RESTAPI の方法について説明します。

ECS管理 REST API の方法説明

PUT /object/bucket/{bucketName}/retention

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

GET /object/bucket/{bucketName}/retention

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

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

ネームスペースに対する保存設定はポリシーのように機能します。各ポリシーは<name>:

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

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

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

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

ネームスペースに定義されている保存クラスの設定を返します。

ECS Management REST API にアクセスする方法の詳細については、ECS製品ドキュメントページ内の使用可能な「ECS データアクセスガイド」を参照してください。

ECS Portalでのネームスペースの操作［Manage］ > ［Namespace］から利用可能な［Namespace Management］ページを使用して、既存ネームスペースの詳細の表示、新規ネームスペースの作成、既存ネームスペースの変更、ネームスペースの削除を実行できます。





図 12 ネームスペース管理ページ

表 12 ネームスペースのプロパティ


Name ネームスペースの名前。

デフォルトのレプリケーショングループネームスペースのデフォルトのレプリケーショングループ。

Notification Quota これに達すると通知が生成されるクォータ制限。

Max Quota これに達するとネームスペースへの書き込みをブロックするクォータ制限。

Encryption ネームスペースの D@RE サーバー側暗号化が有効になっているかどうかを指定。

Actions このアクションは、ネームスペースで実行できます。l ［Edit］：ネームスペースの名前、Namespace管理者、デフォルトのレプリケーショングループ、ネ

ームスペースクォータ、バケットのクォータ、サーバ側の暗号化、システム停止中のアクセス、ネームスペースのコンプライアンス設定を変更します。

l ［Delete］：ネームスペースを削除します。

ネームスペースの作成ネームスペースを作成することができます。はじめにl この操作には ECS のシステム管理者のロールが必要です。l レプリケーショングループが存在する必要があります。レプリケーショングループにより、オブジェク

トデータを保存するストレージプールへのアクセスが可能になります。l ドメインユーザーがネームスペースにアクセスできるようにするには、認証プロバイダーを ECS に

追加する必要があります。ドメインオブジェクトユーザーまたはドメイングループを構成するには、ネームスペースにユーザーをマッピングする方法を考える必要があります。ユーザーのマッピングの詳細については、ドメインユーザーは、オブジェクトユーザーの操作を実行するために、割り当てられたネームスペースを必要とします。（66 ページ）を参照してください。

ネームスペースの詳細については、ネームスペース設定（53 ページ）を参照してください。

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


ネームスペースの作成 57

2. ［Namespace Management］ページで、［New Namespace］をクリックします。

3. ［New Namespace］ページの［Name］フィールドに、ネームスペース名を入力します。

名前に使用できるのは小文字のみです。4. ［User Admin］フィールドで、ドメインまたはネームスペース管理者ロールを割り当てるローカ

ルユーザーのユーザー ID を指定します。［Domain Group Admin］フィールドに、ネームスペース管理者ロールを割り当てる 1 つ以上のドメイングループも追加できます。

コンマ区切りのリストで、複数のユーザーとグループを追加することができます。5. ［Replication Group］フィールドで、このネームスペース用のデフォルトレプリケーショングル

ープを選択します。6. ［Namespace Quota］フィールドに、このネームスペース用のストレージ領域制限を有効に

するかどうかを指定します。ネームスペースクォータを有効化する場合、次のクォータの動作のオプションから 1 つ選択します。a.［<quota>時のみ通知］



クォータの設定に達したときに通知する場合に、このオプションを選択します。

b.［<quota>時のみアクセスをブロック］

クォータに達したときに、このネームスペースのバケットへの書き込み/更新アクセスをブロックする場合は、このオプションを選択します。

c.［<quota>でアクセスをブロックし、<% of quota>で通知を送信］

全クォータの指定されたパーセンテージに達したときに、このネームスペースのバケットへの書き込み/更新アクセスをブロックして通知する場合は、このオプションを選択します。

7. ［Default Bucket Quota］フィールドに、このネームスペースで作成されたすべてのバケット用のストレージ領域制限を有効にするかどうかを指定します。

8. ［Server-side Encryption］フィールドに、このネームスペースにサーバ側暗号化が必要かどうかを指定します。有効化されると、ネームスペース内で作成されたすべてのバケットのサーバ側暗号化が有効化され、バケット内のすべてのオブジェクトが暗号化されます。［Disabled］のままであっても、作成時にネームスペース内での個々のバケットに、サーバ側暗号化を適用することができます。

9. ［Access During Outage］フィールドに、地理的連携を設定中の一時的なサイト停止時に、このネームスペース内に作成されたバケット内のデータにアクセスするときのデフォルトの動作を指定します。有効化されると、一時的なサイト停止が地理的連携システム内で発生し、バケットが作成された障害の発生しているサイト（所有者サイト）のバケットにアクセスできない場合、別のサイトのバケットのコピーにアクセスできます。

無効化されると、一時的に停止したサイトのデータは他のサイトからアクセスできず、障害の発生しているサイトにあるデータのオブジェクトの読み取りは失敗します。

10. ［Compliance］フィールドに、このネームスペース内のオブジェクトのコンプライアンス機能を有効にするかどうかを指定します。一度この設定を有効にすると、無効化できません。

この設定は、ネームスペースの作成時にのみ有効化できます。

コンプライアンスの設定を有効にする場合は、次の手順を実行して、保存ポリシーを追加します。

a.［Retention Policies］エリアで、［Add］をクリックして新しいポリシーを追加します。b.［Name］フィールドに、ポリシーの名前を入力します。c.［Value］フィールドに、この保存ポリシーの保存期間を入力し、測定単位（秒、分、時間、日、月、年）を選択します。特定の保存期間を指定するのではなく、［Infinite］チェックボックスを選択し、この保存ポリシーに割り当てられたバケットを削除しないようにすることもできます。

11. ECS にログインしネームスペースの管理タスクの実行するユーザーを含む、AD（ActiveDirectory）または LDAP（Lightweight Directory Access Protocol）ドメインを指定するには、［Domain］をクリックします。a.［Domain］フィールドに、ドメインの名前を入力します。b.［Groups］、［Attribute］、［Values］フィールドに値を入力して、このネームスペースで ECS にアクセスを許可されているドメインユーザーのグループと属性の値を指定します。


ネームスペースの作成 59

グループと属性を使用して複雑なマッピングを実行する方法については、ドメインユーザーは、オブジェクトユーザーの操作を実行するために、割り当てられたネームスペースを必要とします。（66 ページ）を参照してください。


ネームスペースの編集既存のネームスペースの構成を変更することができます。はじめにこの操作には ECS のシステム管理者のロールが必要です。ネームスペース管理者ロールは、AD または LDAP ドメインを変更できます。ネームスペースのネームスペース管理者ロールを割り当てたオブジェクトユーザーまたは管理ユーザーである、ネームスペースのユーザーが含まれています。ネームスペースを作成した後に、［Name］、［Server-side Encryption］、［Compliance］フィールドを編集することはできません。手順

1. ECS ポータルで、［Manage］ > ［Namespace］を選択します。2. ［Namespace Management］ページで、編集するアカウントをテーブル内で指定します。

編集するネームスペースの［Actions］列で、［Edit］をクリックします。3. ［Edit Namespace］ページで、次の手順に従います。

l ネームスペース管理者ロールを割り当てるドメインユーザーまたはローカルユーザーを変更するには、［User Admin］または［Domain Group Admin］フィールドで、ユーザー ID を変更します。

l このネームスペース用のデフォルトレプリケーショングループを変更するには、［Replication Group］フィールドで、別のレプリケーショングループを選択します。

l 次の有効化されている機能のうちいずれかを変更するには、適切な［Enabled］または［Disabled］オプションをクリックします。n ［Namespace Quota ］n ［Default Bucket Quota］n ［Access During Outage］

4. 既存の保存ポリシーを変更するには、［Retention Policies］エリアで次のことを実行します。a. 編集する保持ポリシーの横にある、［アクション］列の［編集］をクリックします。b. ポリシー名を変更するには、［Name］フィールドに、新しい保存ポリシー名を入力します。

c. 保存期間を変更するには、［Value］フィールドに、この保存ポリシーの新しい保存期間を入力します。

5. ネームスペースのネームスペース管理者ロールを割り当てたオブジェクトユーザーまたは管理ユーザーである、ネームスペースがユーザーが含まれている、AD または LDAP ドメインを変更するには、［Domain］をクリックします。a. ドメイン名を変更するには、［New Domain Name］フィールドに、ドメイン名を入力します。



b. このネームスペースで ECS にアクセスを許可されているドメインユーザーのグループと属性の値を変更するには、［Groups］、［Attribute］、［Values］フィールドに値を入力します。


ネームスペースの削除ネームスペースを削除することができますが、最初にネームスペース内のバケットを削除する必要があります。はじめにこの操作には ECS のシステム管理者のロールが必要です。手順

1. ECS ポータルで、［Manage］ > ［Namespace］を選択します。2. ［Namespace Management］ページで、削除するアカウントをテーブル内で指定します。

削除するネームスペースの［Actions］列で、［Delete］をクリックします。

アラートでは、ネームスペース内のバケット数が表示し、ネームスペースを削除する前に、ネームスペース内のバケットを削除するように指示します。［OK］をクリックします。

3. ネームスペース内のバケットを削除します。a.［Manage］ > ［Bucket］を選択します。b.［Bucket Management］ページで、削除するアカウントをテーブル内で指定します。削除するバケットの［Actions］列で、［Delete］をクリックします。

c. ネームスペース内のすべてのバケットで、手順 4b.を繰り返します。4. ［Namespace Management］ページで、削除するアカウントをテーブル内で指定します。

削除するネームスペースの［Actions］列で、［Delete］をクリックします。

このネームスペース内のバケットは存在しないため、このネームスペースを削除することを確認するメッセージが表示されます。［OK］をクリックします。



ネームスペースの削除 61



第 6章

ユーザーおよびロール

l ユーザーとロールの概要.......................................................................................... 64l ECS のユーザー.................................................................................................... 64l ECS での管理ロール............................................................................................. 69l ECS ポータルでのユーザーの操作............................................................................ 73

ユーザーおよびロール 63

ユーザーとロールの概要ECS でユーザーとロールを構成し、ECS の管理タスクとオブジェクトストアへのアクセスを制御します。管理ユーザーは、ECS Portal で管理タスクを実行できます。オブジェクトユーザーは、ECSPortal にアクセスできませんが、ECS データアクセスプロトコルをサポートするクライアントを使用してオブジェクトストアにアクセスできます。ECS でロールを定義することにより、ECS Portal で管理ユーザーが実行可能な操作、またはECS管理 REST API を使用して実行可能な操作を決定します。管理ユーザーとオブジェクトユーザーは、異なるテーブルに格納されるため、認証情報が異なります。管理ユーザーには、ローカルのユーザー名とパスワード、またはドメインユーザーアカウントへのリンクが必要です。オブジェクトユーザーには、ユーザー名と秘密キーが必要です。同じ名前を持つ管理ユーザーとオブジェクトユーザーを作成できますが、これらのユーザーは認証情報が異なるため、実際には別のユーザーです。管理ユーザーとオブジェクトユーザーの名前は、ECS システム内で一意にするか、ネームスペース内で一意にすることで、ユーザースコープとして参照できます。ローカルユーザーおよびドメインユーザーは、管理ユーザーまたはオブジェクトユーザーとして割り当てることができます。ECS では、ローカルユーザーの認証情報が格納されています。ドメインユーザーは、AD/LDAP データベースに定義されたユーザーです。ECSは AD/LDAP サーバと通信して、ユーザーのログインリクエストを認証する必要があります。次のトピックでは、ECS でのユーザータイプ、管理ユーザーに割り当てられた管理ロール、ECSPortal で実行されることがあるユーザーに関連するタスクについて説明します。l ECS のユーザー（64 ページ）l ECS での管理ロール（69 ページ）l ECS ポータルでのユーザーの操作（73 ページ）

ECSのユーザーECS に必要な 2種類のユーザー：管理ユーザーは、ECS の管理を実行できます。オブジェクトユーザーは、オブジェクトストアにアクセスし、オブジェクトとバケットの読み取り/書き込みを実行できます。次のトピックでは、ECS ユーザーのタイプと概念について説明します。l 管理ユーザー（64 ページ）l デフォルトの管理ユーザー（65 ページ）l オブジェクトユーザー（65 ページ）l ドメインユーザーとローカルユーザー（66 ページ）l ユーザースコープ（68 ページ）l ユーザータグ（68 ページ）

管理ユーザー管理ユーザーは、ECS システムおよび ECS の構成済みネームスペース（テナント）の構成と管理を実行できます。管理ユーザーに割り当てられるロールは、ECS での管理ロール（69 ページ）に説明されている、システム管理者、システム監視者、ネームスペース管理者、ロック管理者です。



管理ユーザーは、ローカルユーザーまたはドメインユーザーとして割り当てることができます。ローカルユーザーである管理ユーザーは、ローカルに保持された認証情報と照合され、ECS によって認証されます。ドメインユーザーである管理ユーザーは、AD（Active Directory）または LDAP（Lightweight Directory Access Protocol）のシステムで認証されます。ドメインユーザーとローカルユーザーについての詳細は、ドメインユーザーとローカルユーザー（66 ページ）を参照してください。管理ユーザーは、地理的に分散して連携している VDC間ではレプリケートされません。

デフォルトの管理ユーザーインストール時に、ECSは 2 つデフォルトローカル管理ユーザー、root、emcsecurity を作成し、ECS の初期の構成と継続中の構成を利用できます。ECS Portal または ECS ManagementREST API を使用して、root および emcsecurity管理ユーザーが ECS システムにアクセスできます。これらのデフォルトユーザーを ECS システムから削除することはできません。また、これらのデフォルトユーザーは地理的に連携しているサイト間ではレプリケートされません。次の表では、デフォルトの管理ユーザーについて説明します。

表 13 デフォルトの管理ユーザー

デフォルトユーザー

デフォルトのパスワード

ユーザーの説明ユーザーへのロールの割り当て

役割の権限さらにユーザーを作成できるか

root ChangeMe このユーザーは、ECS システムの初期構成を実行し、システム管理者ロールを持つユーザーを作成します。root ユーザーが初めてECS にアクセスするときに、ユーザーはパスワードを変更し、新しいパスワードを使用してすぐに再度ログインするよう要求されます。監査上、どのユーザーがシステムに対する変更を実行したかを知ることが重要です。そのため、システムの初期化後は root ユーザーを使用しないでください。システムの初期化後、各システム管理者ユーザーは、root ユーザーの資格情報ではなく、独自の資格情報を使用してシステムにログインする必要があります。

システム管理者管理ユーザーとオブジェクトユーザーの作成および削除

ユーザーパスワードの変更

オブジェクトユーザーへの権限の付与

ストレージプール、ネームスペース、バケット、レプリケーショングループの作成、削除、変更

監視メトリックの表示

○

emcsecurity ChangeMe このユーザーは、このユーザーをロックすることにより、ノードへのリモート SSH アクセスを防止できます。このユーザーのパスワードは、システムのインストール後に変更し、安全に記録する必要があります。

ロック管理者ノードのロックおよびロック解除

自分のパスワードの変更

×

オブジェクトユーザーオブジェクトユーザーは、ECS オブジェクトストアのエンドユーザーであり、ECS がサポートするオブジェクトプロトコル（S3、EMC Atmos、Openstack Swift、CAS）を使用してオブジェクトクライアントから ECS にアクセスします。HDFS用のファイルシステムとしてエクスポートしたバケットにアクセスするために、オブジェクトユーザーに UNIX スタイルの権限を割り当てることもできます。管理ユーザー（システム管理者またはネームスペース管理者）は、オブジェクトユーザーを作成できます。管理ユーザーはユーザー名を定義し、ユーザーが作成されたとき、またはそれ以降の任意の


デフォルトの管理ユーザー 65

時点で、オブジェクトユーザーにシークレットキーを割り当てます。ユーザー名をローカル名にするか、名前に@が含まれるドメインスタイルのユーザー名にすることができます。オブジェクトユーザーは、シークレットキーを使用して、ECS のオブジェクトストアにアクセスできます。オブジェクトユーザーのシークレットキーは、メールや他の方法で配信されます。ドメインユーザーとして ECS に追加されたユーザーは、ECS管理 REST API と通信するクライアント経由で ECS のセルフサービス機能を使用して、独自の秘密キーを作成し、続けて自分自身をオブジェクトユーザーとして追加できます。指定したオブジェクトユーザー名は、そのドメインの名前と同じです。オブジェクトユーザーは、ECS ポータルにアクセスしません。ドメインユーザーについての詳細は、ドメインユーザーとローカルユーザー（66 ページ）を参照してください。シークレットキーの作成方法の詳細については、ECS製品ドキュメントページ内の使用可能な「ECS データアクセスガイド」を参照してください。オブジェクトユーザーはグローバルリソースです。オブジェクトユーザーは、割り当て先ネームスペース内のバケットとオブジェクトの、VDC からの読み取りおよび書き込みの権限を付与されています。

ドメインユーザーとローカルユーザーECSは、ローカルユーザーとドメインユーザーをサポートします。ローカルユーザーおよびドメインユーザーは、管理ユーザーまたはオブジェクトユーザーとして割り当てることができます。ECS のセルフサービス機能では、ドメインユーザーを認証し、ドメインユーザーが自身のシークレットキーを作成できます。ドメインユーザーが自分のシークレットキーを作成すると、ECS システムのオブジェクトユーザーとなります。AD と LDAP を使用して、既存のユーザーデータベースアクセスから多数のユーザーを ECS オブジェクトストアに（オブジェクトユーザーとして）移し、各ユーザーを個別に作成しません。

オブジェクトユーザーであるドメインユーザーをネームスペースに追加（マップ）する必要があります。詳細については、ネームスペースへのドメインユーザーの追加（79 ページ）を参照してください。

ECS では、ローカルユーザーの認証情報が格納されています。オブジェクトユーザーの認証情報はグローバルリソースであり、ECS のすべての VDC で利用できます。ドメインユーザーは、AD（Active Directory）や LDAP データベースで定義されます。ドメインユーザー名は [email protected]形式を使用して定義します。@がないユーザー名は、ローカルユーザーデータベースと照合して認証されます。ECSは認証プロバイダーを使用して、AD またはLDAP サーバと通信するための認証情報を提供し、ドメインユーザーのログインリクエストを認証します。管理ロールが割り当てられたドメインユーザーは、AD/LDAP認証情報と照合して認証され、ECS にアクセスして ECS管理操作を実行できます。

ドメインユーザーは、オブジェクトユーザーの操作を実行するために、割り当てられたネームスペースを必要とします。

これらのユーザーに ECS オブジェクトユーザーの操作を実行させる場合は、ネームスペースにドメインユーザーを追加（割り当て）する必要があります。ECS オブジェクトストアにアクセスするには、オブジェクトユーザーとネームスペース管理者はネームスペースを割り当てなければなりません。ユーザーのドメイン全体をネームスペースに追加するか、特定のグループまたはドメインに関連づけられた属性を指定することで、ネームスペースにドメインユーザーのサブセットを追加することができます。ドメインはユーザーを複数のネームスペースに提供することができます。たとえば、corp.sean.com ドメインのアカウント部門などのユーザーのセットを Namespace1 に追加し、corp.sean.com ドメインの財務部門などのユーザーのセットを Namespace2 に追加することができます。この場合、corp.sean.com ドメインは、2 つのネームスペースにユーザーを提供します。




ドメイン全体、ユーザーの特定のセット、特定のユーザーを複数のネームスペースに追加することはできません。たとえば、corp.sean.com ドメインを Namespace1 に追加することはできますが、そのドメインを Namespace2 にも追加することはできません。次の例では、システム管理者またはネームスペース管理者が corp.sean.com ドメインのユーザーのサブセットをネームスペースに追加します。つまり、部門属性を持つユーザー = ActiveDirectory のアカウントです。システム管理者またはネームスペース管理者が、ECS Portal の［Edit Namespace］ページを使用して、ネームスペースにこのドメインのアカウント部門にユーザーを追加します。図 13 1 つの AD属性を使用して、ネームスペースにドメインユーザーのサブセットを追加します。

次の例では、システム管理者またはネームスペース管理者がより高い精度でネームスペースにユーザーを追加する、別の例を示します。この例では、システム管理者またはネームスペース管理者がcorp.sean.com ドメインにメンバーを追加します。そのメンバーは、部門属性のあるストレージ管理グループに所属=アカウント属性および会社属性=ACME、または部門属性のあるストレージ管理グループに所属=財務属性となります。図 14 複数の AD属性を使用して、ネームスペースにドメインユーザーのサブセットを追加します。


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

ECS Portal を使用してネームスペースにドメインユーザーを追加する方法の詳細については、ネームスペースへのドメインユーザーの追加（79 ページ）を参照してください。

ユーザースコープユーザースコープの設定は、連携するすべての VDC にわたるすべてのネームスペース内のすべてのオブジェクトユーザーに影響します。ユーザースコープは、GLOBAL または NAMESPACE になります。範囲が GLOBAL に設定されている場合、オブジェクトユーザー名は ECS システムのすべての VDC で一意です。スコープがNAMESPACE に設定されている場合、オブジェクトユーザー名はネームスペース内で一意であるため、同じオブジェクトユーザー名が別のネームスペースに存在する可能性があります。デフォルトの設定は GLOBAL です。マルチテナント構成で ECS を使用し、ネームスペースが他のネームスペースで使用されている名前を使用する場合、この設定を NAMESPACE に変更する必要があります。

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

ユーザースコープの設定ECS管理 REST API を使用してユーザースコープを設定することができます。

はじめにこの操作には ECS のシステム管理者のロールが必要です。デフォルトのユーザースコープ設定を GLOBAL から NAMESPACE に変更する場合、ECS に最初のオブジェクトユーザーを作成する前に実行する必要があります。

ユーザースコープ設定は、ECS内のすべてのオブジェクトユーザーに影響します。

手順1. ECS管理 REST API を使用して、PUT /config/object/propertiesAPI を使用し、ペイロードのユーザースコープを渡します。

次の例では、user_scope から NAMESPACE に設定するペイロードを示します。

PUT /config/object/properties/

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

ユーザータグ名前形式のタグ=オブジェクトユーザーのユーザー ID に関連づけられた値のペアであり、アプリケーションによって取得されます。たとえば、オブジェクトユーザーをプロジェクトやコストセンターに関連づけることができます。タグは、管理ユーザーに関連づけできません。



この機能は ECS Portal から使用できません。タグをオブジェクトユーザーに設定でき、オブジェクトユーザーに関連づけられたタグを ECS Management REST API を使用して取得できます。最大20 タグを追加できます。

ECSでの管理ロールECS では、ロールを定義することにより、ECS ポータルでユーザーが実行可能な操作、または ECS管理 REST API を使用して ECS にアクセスした場合に実行可能な操作を決定します。管理ユーザーおよびグループは、ECS の管理ロールに割り当てることができ、ローカルユーザーまたはドメインユーザーのどちらにもなることができます。Active Directory グループ名にロールを割り当てることもできます。次の管理ロールが定義されています。l システム管理者（69 ページ）l システム監視者（69 ページ）l ネームスペース管理者（69 ページ）l ロック管理者（70 ページ）

システム管理者システム管理者ロールによってユーザーは ECS を構成でき、オブジェクトストアに使用するストレージ、オブジェクトストアのレプリケート方法、テナントからオブジェクトストアへのアクセスの構成方法（ネームスペースを定義）、割り当てられたネームスペース内で権限を持つユーザーの指定が可能です。また、システム管理者はネームスペースを構成してネームスペースを管理したり、ネームスペースに属するユーザーをネームスペース管理者に割り当てたりすることもできます。システム管理者は ECS ポータルにアクセスできます。システム管理者の操作は、ECSManagement REST API を使用してプログラムクライアントから実行することもできます。ECS の初回インストールの後のシステム管理者は、root と呼ばれる事前プロビジョニングされたローカル管理ユーザーです。デフォルトの root ユーザーについては、デフォルトの管理ユーザー（65 ページ）で説明します。管理ユーザーはサイト間でレプリケートされないため、システム管理者を必要とする VDC ごとにシステム管理者を作成する必要があります。

システム監視者システム監視者ロールでは、ユーザーが ECS Portal への読み取り専用アクセスを許可します。システム監視者は、パスワード、シークレットキーのデータなどのユーザーの詳細情報を除くすべてのECS Portal ページとページ上のすべての情報を表示します。システム監視者は、ECS システムをプロビジョニングまたは構成することはできません。たとえば、監視者は、ポータルまたは ECS管理API を使用して、ストレージプール、レプリケーショングループ、ネームスペース、バケット、ユーザーなどを作成または更新することはできません。監視者は、自分のパスワードを除く他のポータル設定を変更することはできません。管理ユーザーはサイト間でレプリケートされないため、システム監視者を必要とする VDC ごとにシステム管理者を作成する必要があります。

ネームスペース管理者ネームスペース管理者は、ECS ポータルにアクセスして、ローカルユーザーをネームスペースのオブジェクトユーザーとして割り当てることのできる管理ユーザーであり、ネームスペース内にバケットを作成


ECS での管理ロール 69

して管理します。ネームスペース管理者の操作は、ECS Management REST API を使用して実行することも可能です。ネームスペース管理者は、単一のネームスペースの管理者にしかなれません。認証プロバイダーとネームスペースはサイト間でレプリケートされるため（ECS グローバルリソース）、ドメインユーザーがネームスペース管理者である場合は、任意のサイトにログインしてそのサイトからネームスペースを管理できます。

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

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

ロック管理者ロック管理者は、ECS Portal または ECS Management API を通じてノードのロックとロック解除を唯一実行できる管理ユーザーです。ノードの「［ロック］」は、ノードへのリモート SSH アクセスを無効化する機能です。ロック管理者は、emcsecurity と呼ばれるデフォルトのローカルユーザーです。emcsecurity ユーザーについては、デフォルトの管理ユーザー（65 ページ）で説明します。ロック管理者が行えるのは、パスワードの変更と、ノードのロックおよびロック解除のみです。ロック管理者ロールは、別のユーザーに割り当てることはできません。システム管理者とシステム監視者は、ノードのロックステータスを表示できます。ノードのロックとロック解除の手順については、ECS Portalを使用したノードのロックおよびロック解除（163 ページ）を参照してください。

ロールによって実行されるタスク

ECS Portal で実行できるタスクまたはロールごとの ECS Management REST API については、次の表で説明します。

表 14 ECS管理ユーザーロールによって実行されるタスク

タスクシステム管理者システム監視者ネームスペース管理者 Lock Admin

［テナント］

ネームスペース（テナント）の作成 ○ × × ×

ネームスペースの削除 ○ × × ×

［ユーザー管理（別途示されていない場合は管理ユーザーとオブジェクトユーザー）］

ローカルオブジェクトユーザーを作成し、ネームスペースに割り当てる

○（すべてのネームスペース内） × ○（1 つのネームスペース内）

×

ローカル管理ユーザーを作成し、ネームスペースに割り当てる

○（すべてのネームスペース内） × × ×

ローカルオブジェクトユーザーの削除 ○（すべてのネームスペース内） × ○（1 つのネームスペース内）

×



表 14 ECS管理ユーザーロールによって実行されるタスク（続き）


ローカル管理ユーザーの削除 ○（すべてのネームスペース内） × × ×

すべてのオブジェクトユーザー向けユーザースコープの設定（グローバルまたはネームスペース）

○ × × ×

AD、LDAP、Keystone の認証プロバイダーの追加


AD、LDAP、Keystone の認証プロバイダーの削除


AD と LDAP のドメインユーザーまたは AD グループのネームスペースへの追加

○（すべてのネームスペース内） × ○（1 つのネームスペース内）

×

AD グループの作成（LDAP およびKeystone のグループはサポートされません）


ドメインユーザーまたは AD グループの削除


［ロール管理］

ローカルユーザーとドメイン管理ユーザーおよび AD グループへの管理ロールの割り当て


ローカルユーザーとドメインユーザーおよび AD グループからのロールの取り消し


［ストレージ構成］

ストレージプールの作成、変更 ○（システム管理者が作成された VDC内）

× × ×

VDC の作成、変更、削除 ○（システム管理者が作成された VDC内）

× × ×

レプリケーショングループの作成、変更 ○（システム管理者が作成された VDC内）

× × ×

バケットの作成、変更、削除 ○（すべてのネームスペース内） × ○（1 つのネームスペース内）

×

ユーザーのバケット ACL権限の設定 ○（すべてのネームスペース内のバケット）

× ○（1 つのネームスペース内のバケット）

×

NFS エクスポートの作成、変更、削除

○（すべてのネームスペース内のバケット）


×

ユーザーおよびグループからバケット内のファイルおよびオブジェクトへのマッピングの作成、変更、削除

○（すべてのネームスペース内のバケット）


×


ロールによって実行されるタスク 71



ECS オブジェクトストレージでAmazon S3 アプリケーション向けに使用するオブジェクトベース URL の追加、変更、削除


［監視/レポート作成］

各ネームスペースとバケットの測定情報の取得

○（すべてのネームスペース内）○（すべてのネームスペース内）

○（1 つのネームスペース内）

×

監査情報（ECS Portal と ECS

Management API を使用しているユーザーのすべてのアクティビティのリスト）の取得


× ×

アラートの表示およびアラートアクションの実行（アラートの確認や割り当てなど）


× ×

アラートの構成 ○（すべてのネームスペース内） × × ×

ストレージプール、ノード、ディスク、および VDC全体の容量使用率の監視


× ×

インフラストラクチャ環境の正常稼働と使用率の監視（ノード、ディスク、NIC

帯域幅、CPU、メモリ使用率）


× ×

VDC とノードに対するリクエストとネットワークパフォーマンスの監視


× ×

各ストレージプールのデータ消去エンコーディングステータスの監視


× ×

システム停止または故障（データ再構築プロセス）を受けたストレージプールのリカバリステータスの監視


× ×

VDC または個々のノードレベルでのディスク使用メトリックの監視


× ×

ネットワークトラフィック、データペンディングレプリケーション、および XOR、フェールオーバー、およびブートストラップの処理ステータスなど、ジオレプリケーションメトリックの監視


× ×

クラウドホスト型 VDC およびクラウドのレプリケーショントラフィックに関する情報の監視


× ×

［ライセンス、ESRS、セキュリティ、およびイベントの構成］

すべてのコンポーネントに関するライセンスおよびサブスクリプション情報の表示

○ ○ × ×





新しいライセンスの調達および適用 ○ × × ×

ESRS（EMC セキュアリモートサービス）サーバの追加、変更、削除

○ × × ×

パスワードの変更 ○ ○ ○ ○

ノードをロックして SSH経由でのリモートアクセスを防止

× × × ○

ECS イベントの転送先である SNMP

トラップ受信者の追加または削除○ × × ×

ECS のログメッセージをリモートで格納するシステムログサーバの追加または削除

○ × × ×

ECSポータルでのユーザーの操作［Manage］ > ［Users］で利用可能な［User Management］ページを使用して、ネームスペースのオブジェクトユーザーとして割り当てられているローカルユーザーを作成します。管理ユーザーを作成することも可能で、管理ロールを割り当てる新規のローカルユーザーまたは管理ロールを割り当てるドメインユーザーにできます。［User Management］ページには 2 つのタブがあります。［Object Users］タブと［ManagementUsers］タブです。

［Object Users］タブ［Object Users］タブを使用して、オブジェクトユーザーの詳細を表示し、オブジェクトユーザーを編集し、オブジェクトユーザーを削除できます。このページに一覧表示されるオブジェクトユーザーは、次のとおりです。l ECS Portal でシステム管理者またはネームスペース管理者によって作成されたローカルオブジ

ェクトユーザー。l ECS管理 REST API と通信するクライアントを使用してシークレットキーを取得したことでオブ

ジェクトユーザーになったドメインユーザー。システム管理者には、すべてのネームスペースのオブジェクトユーザーが表示されます。ネームスペース管理者には、自身のネームスペースのオブジェクトユーザーのみが表示されます。


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

図 15 ［User Management］ページ

表 15 オブジェクトユーザープロパティ

属性説明

Name オブジェクトユーザー名。

Namespace オブジェクトユーザーが割り当てられているネームスペース。

Actions このアクションは、オブジェクトユーザーで実行できます。

l ［Edit］：オブジェクトユーザー名、ユーザーが割り当てられているネームスペース、ユーザーの S3、Swift、CAS オブジェクトへのアクセスパスワードを変更します。

l ［Delete］：オブジェクトユーザーを削除します。l ［New Object User］ボタン：新しいオブジェクトユーザーの追加。

［Management Users］タブ［Management Users］タブを使用して、ローカルおよびドメイン管理ユーザーの詳細を表示し、管理ユーザーを編集し、管理ユーザーを削除することができます。このタブは、システム管理者にのみ表示されます。



表 16 管理ユーザーのプロパティ

列説明

Name 管理ユーザーの名前。

Actions このアクションは、管理ユーザーで実行できます。l ［Edit］：ローカル管理ユーザー向けは次のとおりです。ユーザー名、パスワード、システム管理者または

システム監視者ロールの割り当てを変更します。ドメイン管理ユーザー向けは次のとおりです。AD/

LDAP ユーザー名または AD グループ名、およびシステム管理者またはシステム監視者ロールの割り当てを変更します。

l ［Delete］：管理ユーザーを削除します。l ［New Management User］ボタン：新しい管理ユーザーを追加し、システム管理者ロールまたは

システム監視者ロールに割り当てることができます。

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

はじめにl この操作には、ECS でのシステム管理者またはネームスペース管理者ロールが必要です。l システム管理者は、どのネームスペースの新しいオブジェクトユーザーにも割り当てることができま

す。l ネームスペース管理者は、管理者となっているネームスペースに新しいオブジェクトユーザーを割

り当てることができます。l OpenStack Swift オブジェクトプロトコルを使用して、ECS オブジェクトストアにアクセスするオ

ブジェクトユーザーを作成する場合は、Swift ユーザーが OpenStack グループに属する必要があります。グループは、OpenStack管理者によってロールを割り当てられている Swift ユーザーのコレクションです。admin グループに属する Swift ユーザーは、属しているネームスペースのSwiftバケット（コンテナ）のすべての操作を実行できます。通常の Swift ユーザーを adminグループに追加する必要はありません。admin グループ以外の任意のグループに属しているSwift ユーザーでは、認証は Swiftバケットに設定されている権限によります。バケットのカスタムグループ ACL を使用して、OpenStack Dashboard のユーザーインターフェイスから、または


オブジェクトユーザーの追加 75

ECS Portal でバケットに権限を割り当てることができます。詳細については、カスタムグループバケット ACL の設定（95 ページ）を参照してください。

手順1. ECS ポータルで、［Manage］ > ［Users］を選択します。2. ［User Management］ページで、［New Object User］をクリックします。3. ［New Object User］サブページの［Name］フィールドに、ローカルオブジェクトユーザー

の名前を入力します。@が含まれるドメインスタイルの名前を入力することができます（例：[email protected]）。これを実行し、名前を一意で AD の名前と整合性を持つことが可能です。ただし、ローカルオブジェクトユーザーは ADや LDAP ではなく、ユーザー名に割り当てられたシークレットキーを使用して、認証されます。

ユーザー名に使用できるのは、大文字、小文字、数字、「! # $ & ' ( ) * + , - . / : ; = ?@ _ ~」の各文字です。

4. ［Namespace］フィールドで、オブジェクトユーザーを割り当てるネームスペースを選択し、次の手順のいずれかを実行します。l オブジェクトユーザーを追加するには、ECS オブジェクトプロトコルにアクセスするパスワードやシークレットキーを指定する前に、［Save］をクリックします。

l ECS オブジェクトプロトコルにアクセスするパスワードやシークレットキーを指定するには、［Next to Add Passwords］をクリックしします。

5. ［Update Passwords for User <username>］サブページの［Object Access］エリアで、ECS オブジェクトストアにアクセスするユーザーに使用させたい各プロトコル用に、S3、Swift、CAS のインターフェイスへのアクセスで使用するキーを入力または生成します。a. S3 アクセスのために、［S3］ボックスで、［Generate & Add Password］をクリックします。パスワード（シークレットキー）が生成されます。

平文でパスワードを表示するには、［Show Password］チェックボックスを選択します。

セキュリティ上の理由で最初のパスワードと交換する 2 つ目のパスワードを作成するには、［Generate & Add Password］をクリックします。

［Add S3 Password/Set Expiration on Existing Password］ダイアログが表示されます。2 つ目のパスワードを追加する場合は、最初のパスワードを保持する期間を指定できます。この期間が過ぎると、最初のパスワードの期限が切れます。



［Minutes］フィールドに、期限切れになる前に、最初のパスワードを保持する時間を分単位で入力します。たとえば、3分を入力する場合は、ポータルで次を参照してください。

3分後に、最初のパスワードは期限切れとして表示されます。その後、削除できます。

b. Swift アクセスについては、次のとおりです。l ［Groups］フィールドに、ユーザーが属する OpenStack グループを入力します。l ［Password］フィールドに、ユーザーの OpenStack Swift のパスワードを入力します。

l ［Set Password & Groups］をクリックします。

S3 ユーザーが Swift のバケットにアクセスできるようにする場合は、Swiftパスワードおよびユーザーのグループを追加する必要があります。S3 シークレットキーを使用して S3 ユーザーを認証し、Swift のグループメンバーシップが Swiftバケットにアクセスできるようになります。


オブジェクトユーザーの追加 77

c. CAS アクセスについては、次のとおりです。l ［CAS］ボックスにパスワードを入力し、［Set Password］か［Generate］をクリックして、自動的にパスワードを生成し、［Set Password］をクリックします。

l ［Generate PEA file］をクリックして、PEA（プールエントリー認証) ファイルを生成します。ファイルの出力を［PEA file］ボックスに表示します。出力は次の例に似ています。PEA ファイルは、CAS が ECS にアクセスを許可する前に、CAS に認証情報を提供します。この情報には、ユーザー名とシークレットが含まれています。シークレットは、ECS アプリケーションの認証に使用される BASE64 でエンコードされたパスワードです。

<pea version="1.0.0"><defaultkey name="s3user4"><credential id="csp1.secret" enc="base64">WlFOOTlTZUFSaUl3Mlg3VnZaQ0k=</credential></defaultkey><key type="cluster" id="93b8729a-3610-33e2-9a38-8206a58f6514" name="s3user4"><credential id="csp1.secret" enc="base64">WlFOOTlTZUFSaUl3Mlg3VnZaQ0k=</credential></key></pea>

l ［Default Bucket］フィールドで、バケットを選択し、［Set Bucket］をクリックします。

l オプションです。［属性を追加］をクリックして、［Attribute］フィールドと［Group］フィールドに値を入力します。

l ［Save Metadata］をクリックします。

6. ［Close］をクリックします。

パスワード/シークレットキーは自動的に保存されます。

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

はじめにl AD または LDAP認証プロバイダー経由で、AD または LDAP ドメインユーザーを ECS に追

加する必要があります。認証プロバイダーの追加は、システム管理者が実行します。 AD またはLDAP認証プロバイダーの追加（45 ページ）を参照してください。

l ネームスペースへのドメインユーザーの追加（79 ページ）に従ってシステム管理者またはネームスペース管理者が、ドメインユーザーをネームスペースに追加する必要があります。

手順1. ドメインユーザーは、ECS製品ドキュメントページ内の使用可能な「ECS データアクセスガイド」の手順を使用して、自身のシークレットキーを作成することができます。

ドメインユーザーが自分のシークレットキーを作成すると、ECS システムのオブジェクトユーザーとなります。




ネームスペースへのドメインユーザーの追加ECS Portal で、AD、LDAP ドメイン、グループ、ユーザーに関連づけられた属性に基づいてネームスペースにドメインユーザーを追加することができます。ECS オブジェクトユーザーの操作を実行するために、ドメインユーザーをネームスペースに追加（マップ）する必要があります。

はじめにl この操作には、ECS でのシステム管理者またはネームスペース管理者ロールが必要です。l 認証プロバイダーは、ネームスペースに追加するユーザーを含むドメインへのアクセスを提供する

ECS システム内に存在する必要があります。手順

1. ECS ポータルで、［Manage］ > ［Namespace］を選択します。2. ［Namespace Management］ページで、ネームスペースの横にある、［Edit］をクリックし

ます。3. ［Edit Namespace］ページで、［Domain］をクリックし、［Domain］フィールド内にドメ

イン名を入力します。4. ［Groups］フィールドに、ネームスペースにユーザーを追加し、使用するグループの名前を入

力します。指定したグループは AD に存在している必要があります。

5. ［Attribute］と［Values］フィールドに、属性の名前と属性の値を入力します。

ユーザーの指定された属性値が AD または LDAP に指定された属性値と一致する必要があります。

ネームスペースへのユーザーのマップに属性を使用しない場合は、ごみ箱アイコンの［Attribute］ボタンをクリックして属性フィールドを削除します。


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

ローカル管理ユーザーを作成し、ローカルユーザー、ドメインユーザー、AD グループのいずれかに管理ロールを割り当てることができます。管理ユーザーは、システムレベルの管理（VDC の管理）とネームスペースの管理を実行できます。管理ロールの割り当てを削除することもできます。はじめにl この操作には、ECS でのシステム管理者またはネームスペース管理者ロールが必要です。l デフォルトで、ECS の root ユーザーはシステム管理者ロールを割り当てられ、ユーザーにシステ

ム管理者ロールを最初に割り当てることができます。l ドメインユーザーまたは AD グループを管理ロールに割り当てるには、認証プロバイダーを使用し

て、ドメインユーザーまたは AD グループを ECS に追加する必要があります。認証プロバイダーの追加は、システム管理者が実行します。 AD または LDAP認証プロバイダーの追加（45 ページ）を参照してください。

l ネームスペース管理者ロールを管理ユーザーに割り当てるには、次の手順を使用して管理ユーザーを作成し、ECS Portal の［Edit Namespace］ページ上でロールの割り当てを実行する必要があります（ユーザーまたは AD グループへのネームスペース管理者ロールの割り当て（80ページ）を参照）。ネームスペース管理者ロールが割り当てられるまで、ユーザーはログインできません。


ネームスペースへのドメインユーザーの追加 79

手順1. ECS ポータルで、［Manage］ > ［Users］を選択します。2. ［User Management］ページで、［Management Users］タブをクリックします。3. ［New Management User］をクリックします。4. ［AD/LDAP User or AD Group］または［Local User］をクリックします。

l ドメインユーザーの場合は、［Username］フィールドに、ユーザー名を入力します。ECSがユーザー認証に使用するユーザー名とパスワードが AD/LDAP に保存されるため、パスワードを定義する必要はありません。

l AD グループの場合は、［Group Name］フィールドにグループ名を入力します。ECS がAD グループの認証に使用するユーザー名とパスワードが AD に保存されるため、パスワードを定義する必要はありません。

l ローカルユーザーの場合は、［Name］フィールドにユーザー名前を入力し、［Password］フィールドにユーザーのパスワードを入力します。

ユーザー名に使用できるのは、大文字、小文字、数字、「! # $ & ' ( ) * + , - . / : ; = ?@ _ ~」の各文字です。

5. システム管理者ロールをユーザーまたは AD グループに割り当てるには、［SystemAdministrator］ボックスで［Yes］をクリックします。

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

6. システム監視ロールをユーザーまたは AD グループに割り当てるには、［System Monitor］ボックスで［Yes］をクリックします。


ユーザーまたは AD グループへのネームスペース管理者ロールの割り当てネームスペース管理者ロールを ECS システム内に存在するローカル管理ユーザー、ドメインユーザー、AD グループのいずれかに割り当てることができます。

はじめにl この操作には ECS のシステム管理者のロールが必要です。手順

1. ECS ポータルで、［Manage］ > ［Namespace］を選択します。2. ［Namespace Management］ページで、ネームスペース管理者を割り当てるネームスペ

ースの横にある、［Edit］をクリックします。3. ［Edit Namespace］ページで、次の手順に従います。

a. ローカル管理ユーザーまたはドメインユーザーの場合は、［User Admin］フィールドに、ネームスペース管理者ロールを割り当てるユーザーの名前を入力します。1 つ以上のネームスペース管理者を追加するには、名前をコンマで区切ります。

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



b. AD グループの場合は、［Domain Group Admin］フィールドに、ネームスペース管理者ロールを割り当てる AD グループの名前を入力します。

AD グループをネームスペース管理者ロールに割り当てる場合、グループ内のすべてのユーザーにこのロールが割り当てられます。

AD グループがネームスペース管理者になれるネームスペースは 1 つだけです。



ユーザーまたは AD グループへのネームスペース管理者ロールの割り当て 81



第 7章

Buckets

l バケットの概要...................................................................................................... 84l バケットの設定......................................................................................................85l ECS Portal でのバケットの扱い...............................................................................89l S3 API を使用したバケットの作成（s3curl使用）..................................................101l バケット、オブジェクト、ネームスペースの命名規則..................................................... 104

Buckets 83

バケットの概要コンテナを使用して、オブジェクトへのアクセスの制御や、含まれるすべてのオブジェクトの属性を定義するプロパティ（保存期間やクォータなど）の設定ができます。バケットに関する主な概念については、以降のトピックで説明します。l バケットの所有権l バケットのアクセスl バケットの設定l バケットとキーの命名規則このセクションでは、バケットの作成および編集と、ECS Portal を使用してバケットに ACL（アクセス制御リスト）の権限を割り当てる方法についても説明します。l バケットの作成l バケットの編集l バケットポリシーエディタl ACL の設定さらに、このセクションで S3 API を使用したバケットの作成（s3curl使用）（101 ページ）の方法について説明します。S3 では、オブジェクトコンテナは［バケット］と呼ばれており、ECS でもこの用語を総称として採用しました。Atmos では、バケットの同義語は［サブテナント］です。Swift では、バケットの同義語は［コンテナ］です。CAS では、バケットは［CAS プール］です。ECS では、バケットには S3、Swift、Atmos、CAS のいずれかのタイプが割り当てられます。S3、Atmos、Swift のバケットを構成し、ファイルシステム（NFS および HDFS）のアクセスをサポートすることができます。ファイルシステムアクセス用に構成されたバケットは、それぞれのオブジェクトプロトコルまたは NFS/HDFS プロトコルを使用して、読み取りと書き込みが可能です。S3 および Swiftのバケットには、互いのプロトコルを使用してアクセスすることもできます。1 つ以上のプロトコルを使用してバケットにアクセスすると、［クロスヘッドサポート］として、しばしば参照されます。オブジェクトプロトコルの API を使用して、それぞれのバケットを作成できます。通常は、該当するプロトコルをサポートするクライアントを使用します。また、ECS Portal と ECS Management API を使用して、S3、有効なファイルシステム（NFS または HDFS)、CAS のバケットを作成することができます。

バケットの所有権バケットはネームスペースに割り当てられ、オブジェクトユーザーもネームスペースに割り当てられます。オブジェクトユーザーは、オブジェクトユーザーが割り当てられているネームスペースでのみバケットを作成できます。ECS システム管理者またはネームスペース管理者は、ユーザーがバケットと同じネームスペースに属していなくても、オブジェクトユーザーをバケットの所有者またはバケット ACL の受領者として割り当てることができます。そのため、バケットを異なるネームスペースのユーザー間で共有できます。たとえば、ネームスペースが部門である組織で、バケットを異なる部門のユーザー間で共有できます。

バケットのアクセスバケットへのアクセスは、関連づけられているレプリケーショングループによって異なります。複数の VDC にわたるレプリケーショングループに属しているバケット内のオブジェクトには、レプリケーショングループ内のすべての VDC からアクセスできます。単一の VDC に関連付けられているレプリ

Buckets


ケーショングループに属しているバケット内のオブジェクトは、その VDC からのみアクセスできます。バケットにはアクセスできず、レプリケーショングループに属さない他の VDC のリストに表示されることはありません。ただし、バケットとそのメタデータ（ACLなど）の IDは ECS のグローバル管理情報であり、グローバル管理情報はシステムストレージプール間でレプリケートされるため、バケットの存在は連携したすべての VDC で認識されます。サイトのシステム停止中にバケット内のオブジェクトにアクセスする方法については、有効化されたADOバケットプロパティを使用した TSO動作（170 ページ）を参照してください。

バケットの設定バケットに関連づけられた属性について、次の表で説明します。

表 17 バケットの属性

属性説明編集可否

Name バケットの名前。バケットの命名方法の詳細については、バケット、オブジェクト、ネームスペースの命名規則（104 ページ）を参照してください。

×

Namespace バケットが関連づけられたネームスペース。 ×

Replication Group バケットを作成するレプリケーショングループ。 ×

Bucket Owner バケットの所有者。 ○

Bucket Tagging バケットに対して定義する、バケットを分類するための名前と値のペア。バケットのタグ機能の詳細については、バケットのタグ機能（89 ページ）を参照してください。

○

Quota バケットに対して指定されているストレージ領域の制限。バケットのストレージ制限を指定し、クォータに達したときの通知とアクセス動作を定義します。バケットのクォータの設定は、1 GB未満にすることはできません。次のクォータの動作のオプションから 1 つ選択します。

<quota>時のみ通知これに達すると通知が生成されるクォータ設定。

<quota>時のみアクセスをブロックハードクォータに達すると、バケットにアクセスしての作成/更新を禁止します。

<quota>でアクセスをブロックし、<% of quota>で通知を送信ハードクォータに達すると、バケットにアクセスしての作成/更新を禁止し、設定したクォータの割合（%）で通知します。

クォータの実行は、ECS が測定し報告される使用量によって異なります。測定とは、バックグラウンド処理として設計され、フォアグラウンドトラフィックに影響を与えません。測定値は、実際の使用率より遅延することがあります。測定遅延のために、クォータの実行が遅延することがあります。

○

Server-side Encryption サーバ側暗号化を有効化/無効化する場合に指定。サーバ側暗号化は、静止データ暗号化または D@RE と呼ばれ、ECS のディスクまたはドライブに格納する前にデータをインラインで暗号化します。この暗号化は、破棄されたメディアまたは盗難にあったメディアからの機密データの取得を防止します。バケット作成時に暗号化を有効化すると、あとでこの機能を無効にすることはできません。

×

Buckets

バケットの設定 85

表 17 バケットの属性（続き）


バケットのネームスペースが暗号化されている場合は、すべてのバケットが暗号化されます。ネームスペースが暗号化されていない場合は、個々のバケットの暗号化を選択できます。

機能の完全な説明については、ECS製品ドキュメントページ内の使用可能な「ECS セキュリティガイド」を参照してください。

ファイルシステムファイルシステム（NFS エクスポートまたは HDFS）として、バケットを使用できるかどうかを示します。ファイルシステム、デフォルトグループ、グループに関連づけられたデフォルト権限へのアクセスの簡素化を定義することができます。詳細については、デフォルトグループ（87 ページ）を参照してください。

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

×

CAS CAS データのバケットが有効か無効かを示します。 ×

Metadata Search 指定したキーの値に基づいて、バケットのメタデータ検索インデックスを作成することを指定。有効な場合、バケットのオブジェクトをインデックスするためのベースとして使用するメタデータキーを定義することができます。キーの指定はバケットの作成時に行う必要があります。

バケットの作成後に検索を無効化することはできますが、構成済みのインデックスキーは変更できません。

属性の定義方法の説明：メタデータインデックスキー（87 ページ）。

ECS 3.1以降、インデックス作成に使用されるメタデータは暗号化されません。サーバ側暗号化（D@RE）を有効化すると、バケットでメタデータ検索を引き続き使用できます。

×

Access During Outage 地理的連携を設定中の一時的なサイト停止時に、バケット内のデータにアクセスするときのデフォルトの動作です。

このフラグが有効化され、一時的なサイト停止が発生し、バケットが作成されている障害の発生しているサイト（所有者サイト）のバケットにアクセスできない場合、別のサイトのバケットのコピーにアクセスできます。ネームスペース内のバケット内のアクセスしたオブジェクトが障害の発生しているサイトで更新されても、オブジェクトにアクセスしているサイトに変更が反映されていない可能性があります。

フラグを無効化すると、一時的に停止したサイトのデータは他のサイトからアクセスできず、障害の発生しているサイトにあるデータのオブジェクトの読み取りは失敗します。

詳細については、有効化された ADOバケットプロパティを使用した TSO動作（170 ページ）を参照してください。

○

障害発生時の読み取り専用アクセス

Access During Outage を有効化しているバケットに読み取り専用または読み取り/書き込みとしてアクセスできるかどうかを指定します。システム停止中の Read-Only アクセスを有効化している場合、バケットはシステム停止時に読み取り専用モードでのみアクセスできます。

×

Bucket Retention バケットの保存期間。バケット内のオブジェクトの保存期限は、オブジェクトの変更がリクエストされたときに計算され、バケットとオブジェクト自体に設定された値に基づいて決まります。

保存期間は、バケットの存続期間内に変更が可能です。

○

Buckets



表 17 バケットの属性（続き）


保存および保存期間とポリシーの適用に関する詳しい情報は、保存期間と保存ポリシー（55

ページ）で入手できます。

デフォルトグループファイルシステムへのアクセスのバケットを有効化すると、バケットにデフォルトグループを割り当てることができます。デフォルトグループは UNIX グループであり、そのメンバーには、ファイルシステムとしてアクセスするときに、バケットで権限があります。この割り当てがない場合は、バケットの所有者のみがファイルシステムにアクセスできます。オブジェクトプロトコルを使用して作成されたファイルとディレクトリに適用する UNIX の権限を指定し、ファイルシステムとしてバケットにアクセスする場合に、アクセスできるようにすることもできます。次のスクリーンショットでは、デフォルトグループ、ファイル、ディレクトリの権限を設定できるようにするダイアログを有効化するファイルシステムを示します。

メタデータインデックスキーバケットでメタデータ検索を有効にすると、バケット内のオブジェクトをメタデータフィールドに基づいてインデックス作成できます。S3 オブジェクトクライアントは、高度なクエリー言語を使用して、インデックス付けされたメタデータに基づいて、オブジェクトを検索することができます。各オブジェクトには、自動的に割り当てられる一連のシステムメタデータがあり、ユーザーにメタデータを割り当てることもできます。システムメタデータとユーザーメタデータのどちらもインデックスに含まれ、メタデータ検索の条件として使用することができます。［Add Metadata Search Key］ダイアログで、メタデータ検索キーに対して［System］または［User］を選択します。［Metadata Key Type of System］を選択すると、バケット内のオブジェクトに自動的に割り当てられているメタデータが選択用に［Key Names］メニューに一覧表示されます。選択したシステムキータイプのダイアログを、次のスクリーンショットで示します。

Buckets

デフォルトグループ 87

［Metadata Key Type］で［User］を選択すると、ユーザーメタデータの名前を指定して、インデックスを作成する必要があります。検索クエリーで指定されたメタデータ値の解釈方法を ECS が決定できるように、データタイプを指定する必要もあります。選択したユーザーキータイプのダイアログを、次のスクリーンショットで示します。

メタデータ検索機能の詳細については、ECS製品ドキュメントページ内の使用可能な「ECS データアクセスガイド」を参照してください。

Buckets



バケットのタグ機能バケットにタグを割り当てて、バケットのオブジェクトデータを分類できます。たとえば、タグを使用して、バケットのデータをコストセンターやプロジェクトに関連づけることができます。タグは、名前と値のペア形式の中にあります。バケットのタグと値は、ECS ポータルまたは ECS管理 REST API によるカスタムクライアントを使用して、割り当てることができます。バケットのタグは、ECS ポータルに表示されるか、または ECS管理REST API を使用して取得される測定データレポートに記載されています。次のスクリーンショットは、［Bucket Tagging］ダイアログを示します。

ECS Portalでのバケットの扱い［Manage］ > ［Buckets］から利用可能な［Bucket Management］ページを使用して、選択したネームスペース内の既存のバケットの詳細の表示、ACL（アクセス制御リスト）の変更、バケットのポリシーの変更、バケットの削除ができます。

Buckets

バケットのタグ機能 89

図 16 ［Bucket Management］ページ

バケットの作成ECS Portal の S3、S3+FS、CAS のバケットを作成し、構成できます。

はじめにl この操作には、ECS でのシステム管理者またはネームスペース管理者ロールが必要です。l システム管理者は、どのネームスペースのバケットでも作成できます。l ネームスペース管理者は、管理者となっているネームスペース内のバケットの設定を編集できま

す。CAS オブジェクトユーザーによる CASバケットの設定に関する CAS固有の手順については、ECS製品ドキュメントページ内の使用可能な「ECS データアクセスガイド」を参照してください。

手順1. ECS Portal で、［Manage］ > ［Buckets］を選択します。2. ［Manage］［Buckets］ページで、［New Bucket］を選択します。3. ［New Bucket］ページの［Name］フィールドに、バケットの名前を入力します。4. ［Namespace］フィールドで、バケットとそのオブジェクトの属するネームスペースを選択しま

す。5. ［Replication Group］フィールドに、バケットを関連付けるレプリケーショングループを選択

します。6. ［Bucket Owner］フィールドに、バケット所有者を入力します。

バケットの所有者を、ネームスペースの ECS オブジェクトユーザーにする必要があります。ユーザーを指定しなかった場合は、この操作を実行しているユーザーが所有者として割り当てられます。ただし、そのユーザー名がオブジェクトユーザーにも割り当てられるまでは、バケットにアクセスできません。

指定したユーザーには、フルコントロール権限が付与されます。

7. ［Bucket Tagging］フィールドで、［Add］をクリックしてタグを追加し、名前と値のペアを入力します。詳細については、バケットのタグ機能（89 ページ）を参照してください。

8. ［Quota］フィールドで、［Enabled］をクリックしてバケットのクォータを指定し、必要なクォータの設定を選択します。

Buckets




適用できる設定の詳細は、バケットの設定（85 ページ）を参照してください。

9. ［Server-side Encryption］フィールドで、［Enabled］をクリックしてバケットを暗号化するかを指定します。

10. ［File System］フィールドで、［Enabled］をクリックしてバケットがファイルシステム（NFSまたは HDFS アクセス用）としての操作をサポートするよう指定します。

バケットはファイルシステムをサポートする S3バケットになります。

バケットとバケット内に作成されたオブジェクトにアクセスするための、デフォルトの Unix グループを設定することができます。詳細については、デフォルトグループ（87 ページ）を参照してください。

11. ［CAS］フィールドで、［Enabled］をクリックして CASバケットとしてバケットを設定します。

デフォルトでは、CASは無効化され、バケットは S3バケットとしてマークされます。

12. ［Metadata Search］フィールドで、［Enabled］をクリックして、バケットがオブジェクトメタデータに基づく検索をサポートするよう指定します。メタデータ検索を有効化すると、オブジェクトインデックスの作成に使用するユーザーメタデータキーとシステムメタデータキーを追加できます。メタデータ検索キーを入力する方法については、メタデータインデックスキー（87 ページ）を参照してください。

バケットが CAS をサポートする場合、メタデータ検索が自動的に有効化され、CreateTimeキーが自動的に作成されます。S3 メタデータ検索機能を使用するか、Centera API を使用して、メタデータを検索できます。

13. サイトでの一時的な障害発生時にもバケットを使用可能にするには、［Access DuringOutage］フィールドで、［Enabled］をクリックします。このオプションの詳細については、有効化された ADOバケットプロパティを使用した TSO動作（170 ページ）を参照してください。

14. バケットで［Access During Outage］を有効化した場合、一時的なサイト障害時にバケットのオブジェクトでの作成、更新、削除の操作を制限するならば、［Read-Only AccessDuring Outage］を有効化できます。［Read-Only Access During Outage］オプションをバケット上で有効化すると、バケットの作成後に変更することはできません。このオプションの詳細については、有効化された ADOバケットプロパティを使用した TSO動作（170ページ）を参照してください。

15. ［Bucket Retention Period］フィールドに、バケットのバケット保存期間を入力するか、永久に保存するバケットのオブジェクトがある場合には［Infinite］をクリックします。

保存期間の詳細については、保存期間と保存ポリシー（55 ページ）を参照してください。

16. ［Save］をクリックしてバケットを作成します。

結果ユーザーまたはグループに対するバケットの権限を割り当てるには、このセクションのタスクを参照してください。

バケットの編集バケットを作成した後や、オブジェクトを書き込んだ後で、バケットのいくつかの設定を編集できます。

Buckets

バケットの編集 91

はじめにl この操作には、ECS でのシステム管理者またはネームスペース管理者ロールが必要です。l システム管理者は、どのネームスペースに属するバケットでも設定を編集できます。l ネームスペース管理者は、管理者となっているネームスペース内のバケットの設定を編集できま

す。バケットを編集するには、ネームスペース管理者またはシステム管理者ロールが割り当てられている必要があります。次のバケット設定を編集できます。l Quota

l Bucket Owner

l Bucket Tagging

l Access During Outage

l Bucket Retention

以下のバケット設定は変更できません。l Replication Group

l Server-side Encryption

l File System Enabled

l CAS Enabled

l Metadata Search

手順1. ECS Portal で、［Manage］ > ［Buckets］を選択します。2. ［Bucket Management］ページのバケットのテーブルで、設定を変更するバケットの［Edit］アクションを選択します。

3. 変更する設定を編集しますバケット設定の詳細は、バケットの設定（85 ページ）にあります。


ACL の設定バケットにアクセスするときのユーザーの特権は、ACL（アクセス制御リスト）を使用して設定します。ユーザー、事前定義済みのグループ（全ユーザーなど）、カスタムグループに ACL を割り当てることができます。バケットを作成して所有者を割り当てると、ACL が作成されて、バケットの所有者にデフォルトの権限が割り当てられます。所有者には、デフォルトでフルコントロールが割り当てられます。所有者に割り当てられた権限を変更したり、ユーザーに新しい権限を追加したりするには、バケットの［Edit ACL］を選択します。ECS Portal の［Bucket ACLs Management］ページにある［User ACLs］タブ、［GroupACLs］タブ、［Custom Group ACLs］タブで、個々のユーザーと事前定義済みグループに関連づけられている ACL を管理します。グループは、ファイルシステムとしてバケットにアクセスする際に使用できるように定義することができます。

Buckets


CASバケットを含む ACL の詳細については、ECS製品ドキュメントページ内の使用可能な「ECS

データアクセスガイド」を参照してください。

バケット ACL の参考事例

割り当て可能な ACL の権限は、次の表に記載されています。適用される権限は、バケットのタイプによって異なります。

表 18 バケットの ACL

ACL 権限

Read ユーザーはバケットのオブジェクトをリストできる。

Read ACL ユーザーはバケットの ACL を読み取ることができる。

Write ユーザーはバケットのオブジェクトを作成または更新できる。

Write ACL ユーザーはバケットの ACL に書き込みができる。

Execute ファイルシステムとしてアクセスするときの実行権限を設定する。この権限は、ECS オブジェクトプロトコルを使用してオブジェクトにアクセスするときは機能しません。

Full Control ユーザーに Read、Write、Read ACL、Write ACL を許可する。

Privileged Write ユーザーに標準の書き込み権限がない場合に、ユーザーにバケットやオブジェクトへの書き込みを許可する。CASバケットで必須です。

Delete ユーザーにバケットとオブジェクトの削除を許可する。CASバケットで必須です。

None ユーザーはバケットに対する権限を持たない。

ユーザーのバケット ACL権限の設定ECS ポータルでは、ユーザーまたはあらかじめ定義されたグループにバケット ACL を設定できます。

はじめにl この操作には、ECS でのシステム管理者またはネームスペース管理者ロールが必要です。l システム管理者は、どのネームスペースに属するバケットでも ACL設定を編集できます。l ネームスペース管理者は、管理者となっているネームスペース内のバケット n の ACL設定を編

集できます。手順

1. ECS Portal で、［Manage］ > ［Buckets］を選択します。2. ［Bucket Management］ページのバケットのテーブルで、設定を変更するバケットの［Edit

ACL］アクションを選択します。3. ［Bucket ACLs Management］ページで、［User ACLs］をクリックし、ユーザーの ACL

権限を設定します。［User ACLs］タブには、ユーザーに適用されている ACL が表示されます。ユーザーに ACLを割り当てるには、［Add］ボタンを使用します。

Buckets

ACL の設定 93


図 17 ［Bucket ACLs Management］ページの［User ACLs］タブ

ECS ポータルは S3、S3 +ファイルシステム（HDFS または NFS）、CAS のバケットをサポートするため、設定可能な権限の範囲がすべてのバケットタイプに適用されるとは限りません。

4. 権限が割り当て済みのユーザーの権限を編集したり、権限を割り当てたいユーザーを追加したりするには、次の手順の 1 つを実行します。l 権限が割り当て済みのユーザーの ACL権限を設定（または削除）するには、ACL テーブルの［Action］列で［Edit］（または［Remove］）を選択します。

l ユーザーを追加し、ACL権限を割り当てるには、［Add］をクリックします。

バケットの所有者には、割り当てられたデフォルト権限があります。5. ACL を追加した場合は、権限を適用するユーザーのユーザー名を入力します。6. ユーザーに適用する権限を指定します。

ACL権限の詳細については、バケット ACL の参考事例（93 ページ）を参照してください。


定義済みグループのバケット ACL権限の設定ECS ポータルでは、あらかじめ定義されたグループにバケットの ACL を設定できます。

はじめにl この操作には、ECS でのシステム管理者またはネームスペース管理者ロールが必要です。l システム管理者は、どのネームスペースのバケットでもグループ ACL設定を編集できます。l ネームスペース管理者は、管理者となっているネームスペース内のバケットのグループ ACL設

定を編集できます。手順

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

2. ［Bucket Management］ページのバケットのテーブルで、設定を変更するバケットの［EditACL］アクションを選択します。

3. ［Group ACLs］タブをクリックして、次のスクリーンショットに示すように、事前に定義されたグループの ACL権限を設定します。

Buckets


グループ名を次の表で説明します。

グループ説明

public 認証された/認証されていないすべてのユーザー

all users 認証されたすべてのユーザー

other バケット所有者以外の認証されたユーザー

log delivery サポートなし。

4. グループに割り当てる権限を選択します。5. ［Save］をクリックします。

カスタムグループバケット ACL の設定ECS ポータルのバケットのグループ ACL を設定し、ユーザーのグループ（カスタムグループ ACL）、個々のユーザー、または両方の組み合わせのバケット ACL を設定できます。たとえば、ユーザーのグループにはバケットへのフルアクセスを付与しておき、グループの個別のユーザーに制限をつけたり、拒否したりすることができます。はじめにl この操作には、ECS でのシステム管理者またはネームスペース管理者ロールが必要です。l システム管理者は、どのネームスペースのバケットでもグループ ACL設定を編集できます。l ネームスペース管理者は、管理者となっているネームスペース内のバケットのグループ ACL設

定を編集できます。

Buckets

ACL の設定 95

［Custom Group ACLs］で、グループを定義し、権限を割り当てることができます。バケットにグループを割り当てる主な理由は、たとえばバケットを NFS または HDFS で使用できるようにする場合などのように、ファイルシステムとしてのバケットへのアクセスをサポートするためです。UNIX グループのメンバーは、ファイルシステム（NFS または HDFS を使用）としてアクセスする場合、バケットにアクセスできます。手順

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

2. ［Bucket Management］ページで、編集するバケットをテーブルで見つけ、［Edit ACL］アクションを選択します。

3. ［Custom Group User ACLs］をクリックし、カスタムグループの ACL を選択します。4. ［Add］をクリックします。

［Edit Custom Group］ページの表示を、次のスクリーンショットに示します。

5. ［Edit Custom Group］ページの［Custom Group Name］フィールドで、グループの名前を入力します。入力する名前は、UNIX/Linux グループの名前でも、Active Directory グループの名前でもかまいません。

6. グループの権限を設定します。少なくとも、［Read］、［Write］、［Execute］、［Read ACL］を割り当てる必要があります。


Buckets


バケットポリシーエディタの使用ECS Portal では、バケットポリシーエディタが提供され、既存のバケットとバケットポリシーを関連づけることができます。それぞれのバケットで、オブジェクトユーザーの ACL を定義できます。バケットポリシーには、ACL よりも高い柔軟性があり、バケット操作およびバケット内のオブジェクトについての操作に対する権限を細かく調整できます。ポリシーの条件は、条件と一致するさまざまなオブジェクトの権限を割り当てるために使用でき、新しくアップロードされたオブジェクトに権限を自動的に割り当てるために使用できます。ポリシーは、JSON形式で定義され、ポリシーに使用する構文は、Amazon AWS で使用するものと同じです。割り当てできる権限の操作は、ECS でサポートされているこれらの操作に限定されています。詳細については、ECS製品ドキュメントページ内の使用可能な「ECS データアクセスガイド」を参照してください。バケットポリシーエディタには、コードビューとツリービューがあります。次のスクリーンショットに示すように、コードビューでは、スクラッチからの JSON ポリシーの入力や、既存のポリシーをエディタにペーストしての変更ができます。たとえば、JSON形式で既存のポリシーがある場合、コードビューにそれらを貼り付けて、変更できます。

Buckets

バケットポリシーエディタの使用 97


図 18 バケットポリシーエディタのコードビュー

次のスクリーンショットに示すように、ツリービューでは、ポリシーを移動するメカニズムを提供しているため、ポリシーのステートメントが多数ある場合に便利です。ステートメントを展開し、結合して、検索することができます。

Buckets


図 19 バケットポリシーエディタのツリービュー

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

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

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

{ "Version": "2012-10-17", "Id": "S3PolicyId1", "Statement": [ { "Sid": "Grant permission to user1", "Effect": "Allow", "Principal": ["user1"], "Action": [ "s3:PutObject","s3:GetObject" ], "Resource":[ "mybucket/*" ] }

Buckets

バケットポリシーエディタの使用 99

]}

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

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

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

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

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

{ "Version": "2012-10-17", "Id": "S3PolicyId3", "Statement": [ {

Buckets


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

バケットのポリシーの作成ECS Portal でバケットポリシーエディタを使用して、選択したバケットのバケットポリシーを作成できます。はじめにこの操作には、システム管理者または（バケットが属するネームスペースの）ネームスペース管理者のロールが必要です。テキストエディタでバケットポリシーを作成し、ECS管理 REST API または S3 API を使用して導入することができます。手順

1. ECS Portal で、［Manage］ > ［Buckets］を選択します。2. ［Namespace］ドロップダウンで、バケットが属するネームスペースを選択します。3. バケットの［Actions］列で、ドロップダウンメニューから［Edit Policy］を選択します。4. ポリシーが有効な場合は、バケットポリシーエディタのツリービューに切り換えることができま

す。ツリービューでは、ポリシーを表示し、ステートメントを拡張または縮小することが容易です。

5. バケットポリシーエディタでは、ポリシーの入力または以前に作成したポリシーのコピーとペーストをします。いくつかの例はバケットポリシーのシナリオ（99 ページ）に記載され、サポートされる操作や条件の完全な詳細情報は ECS製品ドキュメントページ内の使用可能な「ECS データアクセスガイド」に記載されています。

6. ［Save］をクリックして保存します。ポリシーが検証され、有効である場合、バケットポリシーエディタを終了し、ポータルで［Bucket Management］ページを表示します。ポリシーが有効でない場合、エラーメッセージでポリシーが無効である理由情報を提供します。

S3 API を使用したバケットの作成（s3curl使用）S3 API を使用して、レプリケーショングループにバケットを作成できます。ECSはカスタムヘッダー（x-emc）を使用するため、署名する文字列はこれらのヘッダーを含むように構成する必要があります。この手順では s3curl ツールを使用していますが、使用可能なプログラムクライアントは多数存在します（S3 Java クライアントなど）。

はじめにl バケットを作成するには、ECS に構成済みのレプリケーショングループが 1 つ以上必要です。l s3curl を実行する Linux マシン上に、Perl がインストールされていることを確認します。l curl ツールおよび s3curl ツールがインストールされていることを確認します。s3curl ツールは、

curl周辺のラッパーとして動作します。

Buckets

S3 API を使用したバケットの作成（s3curl使用） 101


l s3curlを x-emc ヘッダーと使用するには、s3curlスクリプトにマイナーな変更を加える必要があります。変更された s3curl の ECS 固有バージョンは、EMC ECS Git Repository から入手できます。

l バケットを作成するユーザー用のシークレットキーを取得してあることを確認します。詳細については、ECS製品ドキュメントページ内の使用可能な「ECS データアクセスガイド」を参照してください。

バケットで使用できる EM ヘッダーについては、バケットの HTTP ヘッダー（104 ページ）を参照してください。手順

1. 次のコマンドを入力して、作成するバケットが属するレプリケーショングループの ID を取得します。

GET https://<ECS IP Address>:4443/vdc/data-service/vpools

レスポンスで、すべてのデータサービス仮想プールの名前と ID を確認できます。次の例では、IDは「urn:storageos:ReplicationGroupInfo:8fc8e19bedf0-4e81-bee8-79accc867f64:global」です。

<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>

2. ユーザー認証情報を入力する.s3curl ファイルを作成して、s3curl を設定します。s3curl.pl を実行する際に、.s3curl ファイルは 0600（rw-/---/---）の権限を持っている必要があります。

次の例では、プロファイル my_profile が [email protected] アカウントのユーザー認証情報を参照し、root_profile が root アカウントの認証情報を参照します。

%awsSecretAccessKeys = (my_profile => {

id => '[email protected]',key => 'sZRCTZyk93IWukHEGQ3evPJEvPUq4ASL8Nre0awN'

},root_profile => {

id => 'root',key => 'sZRCTZyk93IWukHEGQ3evPJEvPUq4ASL8Nre0awN'

Buckets


https://github.com/EMCECS/s3curl


},);

3. s3curl を使用するエンドポイントを、.s3curl ファイルに追加します。エンドポイントは、データノードかデータノードの前に位置するロードバランサーのアドレスです。

push @endpoints , ( '203.0.113.10', 'lglw3183.lss.emc.com',);

4. s3curl.pl を使用してバケットを作成し、次のパラメーターを指定します。l ユーザーのプロファイルl 作成するバケットが属するレプリケーショングループの ID（x-emc-dataservice-

vpool ヘッダーを使用して設定される<vpool_id>）。l 任意のカスタム x-emc ヘッダー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>

この例では、作成するバケットが属するレプリケーショングループを指定する x-emc-dataservice-vpool ヘッダー、およびバケットのファイルシステムへのアクセスを有効化するヘッダー x-emc-file-system-access-enabled（NFSや HDFSなど）を使用します。

-acl public-read-write引数はオプションですが、バケットへのアクセスを有効にする権限を設定するために使用できます（たとえば、Kerberos を使用して保護されていない環境から NFS としてバケットにアクセスする場合）。

（--debug on で）成功すると、出力は次に表示されているようになります。

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:

Buckets

S3 API を使用したバケットの作成（s3curl使用） 103

--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/

バケットの HTTP ヘッダーオブジェクト API を使用してバケットを作成する場合、ECS の動作を指定するヘッダーが多数存在します。以下の x-emc ヘッダーが提供されます。

表 19 バケットのヘッダー

ヘッダー説明

x-emc-dataservice-vpool このバケットに関連づけられたオブジェクトの格納に使用されるレプリケーショングループを指定します。x-emc-dataservice-vpool ヘッダーでレプリケーショングループを指定しなかった場合は、ECSはネームスペースに関連づけられたデフォルトのレプリケーショングループを選択します。

x-emc-file-system-access-enabled NFS または HDFS アクセス用にバケットを構成します。ヘッダーが、使用中のインターフェイスと競合しないようにする必要があります。つまり、NFS または HDFS からのバケット作成リクエストでは x-emc-file-system-access-enabled=false を指定できません。

x-emc-namespace このバケットで使用されるネームスペースを指定します。ネームスペースがホスト/パス形式リクエストの S3 の表記法を使用して指定されていない場合、x-emc-namespace ヘッダーを使用して指定できます。ネームスペースがこのヘッダーで指定されていない場合、ユーザーと関連づけられているネームスペースを使用します。

x-emc-retention-period バケット内のオブジェクトに適用される保存期間を指定します。バケット内のオブジェクトを変更するリクエストが作成されるたびに、バケットに関連づけられた保存期間に基づいてオブジェクトの保存期間の有効期限が計算されます。

x-emc-is-stale-allowed 連携型構成で VDC の一時停止中にバケットにアクセス可能かどうかを示します。

x-emc-server-side-encryption-enabled バケットに書き込まれるオブジェクトを暗号化するかどうかを指定します。

x-emc-metadata-search バケットのオブジェクトのインデックスを作成するために使用する、1人以上のユーザーメタデータ値またはシステムメタデータ値を指定します。インデックスを使用したオブジェクト検索の実行が可能です。インデックスを作成したメタデータに基づいたフィルタリングができます。

バケット、オブジェクト、ネームスペースの命名規則バケットとオブジェクト（キーとしても参照可）の名前は、ここに示した仕様に従う必要があります。l S3バケットとオブジェクトの ECS での命名（105 ページ）l OpenStack Swift コンテナとオブジェクトの ECS での命名（105 ページ）l Atmosバケットとオブジェクトの ECS での命名（106 ページ）

Buckets


l CAS プールとオブジェクトの ECS での命名（106 ページ）

バケットを HDFS に使用する場合は、URI Java クラスでサポートされないアンダースコアをバケット名に使用できません。たとえば、viprfs://my_bucket.ns.site/は無効な URI であり、Hadoop に認識されません。

ネームスペース名ECS ネームスペース名には、次のルールが適用されます。l null または空の文字列にはできないl 長さは 1～255文字（Unicode文字）l 有効な文字は正規表現/[a-zA-Z0-9-_]+/の定義による。つまり、英数字、ハイフン（-）、ア

ンダースコア（_）の特殊文字です。

S3バケットとオブジェクトの ECS での命名ECSS3 オブジェクト API を使用する場合、バケットとオブジェクトの名前は、ECS の命名仕様に従う必要があります。

バケット名ECS の S3バケット名には、次のルールが適用されます。l 名前の長さは、1～255文字にする必要があります（S3 では、バケット名は 1～255文字の

長さでなければなりません）。l 含めることができるのは、ドット（.）、ハイフン（-）、アンダースコア（_）、英数字（a～z、A～Z、

0～9）です。l 先頭の文字は、ハイフン（-）または英数字にできます。l 先頭にドット（.）を使用することはできませんl 二重のドット（..）を含めることはできませんl 最後にドット（.）を使用することはできませんl IPv4 アドレス形式にする必要はありません。これを S3仕様で特定された命名制限と比較することができます。http://docs.aws.amazon.com/AmazonS3/latest/dev/BucketRestrictions.html。

オブジェクト名ECS の S3 オブジェクトの命名には、次のルールが適用されます。l null または空の文字列にはできないl 長さは 1～255文字（Unicode文字）l 文字の検証はなし

OpenStack Swift コンテナとオブジェクトの ECS での命名ECSOpenStack Swift オブジェクト API を使用する場合、コンテナとオブジェクトの名前は、ECSの命名仕様に従う必要があります。

コンテナ名Swift コンテナー名には、次のルールが適用されます。l null または空の文字列にはできない

Buckets

S3バケットとオブジェクトの ECS での命名 105

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

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

l 長さは 1～255文字（Unicode文字）l 含めることができるのは、ドット（.）、ハイフン（-）、アンダースコア（_）、英数字（a～z、A～Z、

0～9）です。

オブジェクト名Swift オブジェクト名には、次のルールが適用されます。l null または空の文字列にはできないl 長さは 1～255文字（Unicode文字）l 文字の検証はなし

Atmosバケットとオブジェクトの ECS での命名ECSAtmos オブジェクト API を使用する場合、サブテナントとオブジェクトの名前は、ECS の命名仕様に従う必要があります。

サブテナント（バケット）サブテナントはサーバによって作成されるため、クライアントは命名スキームを知る必要はありません。

オブジェクト名Atmos オブジェクト名には、次のルールが適用されます。l null または空の文字列にはできないl 長さは 1～255文字（Unicode文字）l 文字の検証はなしl 名前は、パーセントエンコードの UTF-8 にする必要があります。

CAS プールとオブジェクトの ECS での命名CAS プールおよびオブジェクト（CAS の用語の［クリップ］）の名前は、CAS API を使用する場合は ECS の命名仕様に従う必要があります。

CASプール名ECS の CAS プール名には、次のルールが適用されます。l 名前は最大 255文字で指定。l 次の文字は使用不可：' " / & ? * < > <タブ> <改行> <スペース>

クリップ名CAS APIは、ユーザー定義のキーをサポートしていません。CAS API を使用するアプリケーションはクリップを作成する場合に、プールを開き、新しいクリップを作成し、タグ、属性、ストリームなどを追加します。クリップが完成すると、デバイスに書き込まれます。対応するクリップ ID が CAS エンジンによって返され、<プール名>/<クリップ ID>を使用して参照できるようになります。

Buckets


第 8章

ファイルアクセス

l ファイルアクセスの概要......................................................................................... 108l NFS構成のための ECS ポータルのサポート............................................................ 109l ECS NFS構成タスク............................................................................................ 111l ECS NFS を使用する場合のベストプラクティス........................................................125l マルチプロトコル（クロスヘッド）アクセスの権限...................................................... 126l ファイル API サマリー............................................................................................. 128

ファイルアクセス 107

ファイルアクセスの概要ファイルアクセスに関する主な概念については、以降のトピックで説明します。l ディレクトリおよびファイルへのマルチプロトコルアクセスl NFS構成のための ECS ポータルのサポートl ECS NFS を使用する場合のベストプラクティスl マルチプロトコル（クロスヘッド）アクセスの権限l ファイル API サマリーこのセクションでは、これらの NFS構成のタスクについても説明します。l ECS ポータルを使用した NFSバケットの作成l ECS Portal を使用して NFS エクスポートを追加l ECS Portal を使用してユーザーまたはグループマッピングを追加l Kerberos を使用した NFS セキュリティの構成l NFS エクスポートのマウント：例ECS では、NFSv3 による NFS ファイルシステムとしてアクセスするようにオブジェクトのバケットを構成することができます。UNIX ユーザーがファイルシステムにアクセスできるようにするために、ECS オブジェクトユーザーをUNIX ユーザーにマッピングするメカニズムが ECS にはあります。ECSバケットには常に所有者がおり、バケットの所有者を UNIX ID にマッピングすると、UNIX ユーザーの権限がファイルシステムに反映されます。さらに ECS ではバケットにデフォルトカスタムグループを割り当てることができるため、ECS デフォルトカスタムグループにマッピングされた Unix グループのメンバーはそのバケットにアクセスすることができます。さらに ECSはマルチプロトコルアクセスもサポートしており、NFS で書き込まれたファイルに、Amazon S3（Amazon Simple Storage Service）、OpenStack Swift、EMC Atmos の各オブジェクトプロトコルでアクセスすることもできます。同様に、S3 および OpenStack Swift オブジェクトプロトコルで書き込まれたオブジェクトを、NFS で使用することもできます。Atmos では、ネームスペースインターフェイスを使用して作成されたオブジェクトを NFS で一覧表示できますが、オブジェクトID を使用して作成されたオブジェクトは一覧表示できません。オブジェクトのユーザーとグループをマッピングすることにより、オブジェクトプロトコルを使用して作成されたオブジェクトとディレクトリに、UNIX ユーザーと UNIX グループのメンバーからアクセスすることができます。ECS NFS ではアドバイザリロックが可能であり、次のロックをサポートしています。l 複数サイトにまたがるロックl 共有および排他ロックECS NFSは、Kerberos セキュリティをサポートします。

ディレクトリおよびファイルへのマルチプロトコルアクセスECS では、S3 プロトコルで書き込んだオブジェクトに、NFS でファイルとしてアクセスすることができます。また反対に、NFS で書き込んだファイルに、S3 プロトコルでオブジェクトとしてアクセスすることもできます。マルチプロトコルアクセスを使用する場合、ディレクトリ管理方法を理解する必要があります。S3 プロトコルは、フォルダーまたはディレクトリを作成するためのプロビジョニングは行いません。マルチプロトコル操作を可能にするために、ECS の S3 プロトコルのサポートでは/を正式に使用できるようにして、オブジェクト名のすべての中間パスに対して［ディレクトリ］オブジェクトを作成しま



す。/a/b/c.txt という名前のオブジェクトが c.txt という名前のファイルオブジェクトと a およびb のディレクトリオブジェクトを作成します。ディレクトリオブジェクトが S3 プロトコルを使用してユーザーに公開されていないと、ファイルシステムベースの API でのマルチプロトコルアクセスと互換性を提供することのみが維持されます。したがって、NFS または HDFS ファイルシステムとしてバケットを表示する場合、ECSは複数のファイルを単一ディレクトリ構造に表示することができます。

制限事項l ディレクトリオブジェクトとファイルオブジェクトの両方を同じ名前で作成すると、問題が発生しま

す。この問題は、次のようにして発生します。n ファイル path1/path2 を NFS で作成してから、オブジェクト path1/path2/path3を S3 で作成します。S3 では別のオブジェクトの名前をプレフィックスとして使用するオブジェクトを作成できるため、これはサポート対象の有効な操作です。path2はファイルおよびディレクトリとして存在します。

n ディレクトリ path1/path2 を NFS で作成してから、オブジェクト path1/path2 を S3で作成します。ディレクトリ path1/path2は S3 API を介して表示されないため、この操作は S3 で有効な操作です。path2はファイルおよびディレクトリとして存在します。

この問題を解決するために、S3 からのリクエストには常にファイルが返され、NFS からのリクエストには常にディレクトリが返されます。ただしこの場合、最初のケースで NFS で作成されたファイルが、S3 で作成されたオブジェクトのために表示されません。

l NFS では最後が/で終わるファイル名はサポートされませんが、S3 プロトコルではサポートされます。NFS では、これらのファイルは表示されません。

NFS構成のための ECSポータルのサポート［Manage］ > ［File］で利用可能な［File］ページを使用して、NFS エクスポートを作成し、ECS ユーザーとグループをマップすると、NFS エクスポートにアクセスできます。［File］ページには、［Exports］タブと［User/Group Mapping］タブがあります。デフォルトでは、［Exports］タブが表示されます。また、ECS管理 REST API および CLI を使用して、NFSエクスポートを構成しユーザーマッピングを設定することもできます。［ExExports］タブと［User/Group Mapping］タブについては、以下のトピックで説明されています。l ECS Portal でのエクスポートの扱い（109 ページ）l ECS Portal での User/Group Mappings の取り扱い（110 ページ）

ECS Portal でのエクスポートの扱い［Exports］ビューでは、作成済み NFS エクスポートの表示、新規 NFS エクスポートの作成、既存エクスポートの編集が行えます。


NFS構成のための ECS ポータルのサポート 109

図 20 ［File］ページ上の［Exports］タブ

［Exports］タブには、［Namespace］フィールドがあり、ネームスペースを選択して、現在定義されているエクスポートを表示することができます。次のフィールドが、［Exports］テーブルに表示されます。


Namespace 基盤となるストレージが属するテナント/ネームスペース。

Bucket NFS エクスポート用の基盤ストレージを提供するバケット。

Export Path エクスポートに関連づけられたマウントポイントは、次の形式で記載されます。/

<namespace_name>/<bucket_name>/<export_name>。エクスポート名は、バケット内に存在するディレクトリをエクスポートする場合にのみ指定します。

Actions NFS エクスポートで実行できるアクションです。

l ［Edit］：バケットのクォータを編集し、ホストオプションをエクスポートします。l ［Delete］：NFS エクスポートを削除します。

［New Export］をクリックして、新しい NFS エクスポートを追加します。

ECS Portal での User/Group Mappings の取り扱いECSは、バケットの所有者およびグループと、バケット内のファイルとディレクトリの所有者およびグループを、それぞれ ECS オブジェクトユーザー名およびカスタムグループ名として格納します。NFS ユーザーに適切な権限を持つアクセス権を付与するためには、名前を UNIX ID にマッピングする必要があります。マッピングによって、ECSは ECS オブジェクトユーザーと NFS ユーザーを、2種類の認証情報を持つ同一ユーザーとして処理できるようになります。1 つは NFS による ECS アクセス用であり、もう 1 つはオブジェクトプロトコルによる ECS アクセス用です。アカウントがマップされているため、NFS ユーザーが書き込んだファイルに、マップされたオブジェクトユーザーはオブジェクトとしてアクセスでき、オブジェクトユーザーが書き込んだオブジェクトに、NFS ユーザーはファイルとしてアクセスできます。



ファイルまたはオブジェクトに関連づけられた権限は、POSIX ACL権限とオブジェクトプロトコルACL権限間のマッピングに基づいています。マッピングの詳細については、「マルチプロトコル（クロスヘッド）アクセスの権限（126 ページ）」で説明します。［File］ページの［User/Group Mapping］タブは、User/Group Mapping テーブルを示します。図 21 ［File］ページ上の［User/Group Mapping］タブ

［User/Group Mapping］タブには［Namespace］フィールドがあり、選択したネームスペースに構成されたユーザーとグループを、テーブルで表示できます。［User/Group Mapping］テーブルには、次のフィールドが表示されます。


User/Group Name ユーザーのオブジェクトユーザー名。

ID オブジェクトユーザーにマッピングされている UNIX ユーザー ID またはグループID。

Type ユーザーの ID か、グループの ID かの区別。

Actions このアクションは、ユーザーまたはグループマッピングで実行できます。これらは次のとおりです。［View］および［Delete］

［New User/Group Mapping］をクリックして、新しいマッピングを追加します。

ECS NFS構成タスクECS NFS を構成するには、次のタスクを実行する必要があります。手順

1. ECS ポータルを使用した NFSバケットの作成（112 ページ）2. ECS Portal を使用して NFS エクスポートを追加（113 ページ）3. ECS Portal を使用してユーザーまたはグループマッピングを追加（116 ページ）4. Kerberos セキュリティを使用した NFS の構成（117 ページ）


ECS NFS構成タスク 111

ECS ポータルを使用した NFSバケットの作成ECS ポータルを使用して、NFS で使用するために構成したバケットを作成できます。

はじめにl この操作には、ECS でのネームスペース管理者またはシステム管理者のロールが必要です。l ネームスペース管理者は、自分のネームスペースのバケットを作成できます。l システム管理者は、どのネームスペースに属するバケットでも作成できます。ここでは、NFS での使用に適したバケットを作成するために実行する必要のある構成に注目して手順を説明します。作成するバケットは、ファイルシステムの使用を有効にする S3バケットです。

手順1. ECS ポータルで、［Manage］ > ［Buckets］ > ［New Bucket］を選択します。2. ［New Bucket］ページの［Name］フィールドに、バケットの名前を入力します。3. ［Namespace］フィールドで、バケットの所属先にするネームスペースを選択します。4. ［Replication Group］フィールドで、レプリケーショングループにするか、空白のままにしてネ

ームスペース用のデフォルトレプリケーショングループを使用するか、選択します。5. ［Bucket Owner］フィールドに、バケット所有者の名前を入力します。6. ［CAS］フィールドで、CAS を有効化しません。

NFS として使用するバケットは、CAS として使用できません。［File System］フィールドを有効化すると、［CAS］フィールドは無効化されます。

7. その他の必要なバケット機能を有効化します。次の機能はいずれも、NFSバケットで有効化できます。l クォータl サーバ側暗号化l メタデータ検索l 停止時のアクセスl 障害発生時の読み取り専用アクセスl コンプライアンス（注を参照）l バケットの保存期間これらの設定については、バケットの設定（85 ページ）を参照してください。

コンプライアンスが有効になったバケットには、NFS プロトコルを使用して書き込むことはできません。ただし、オブジェクトプロトコルを使用して書き込まれたデータは、NFS から読み取ることができます。

8. ［File System］フィールドで、［Enabled］をクリックします。

有効化すると、ファイルシステム/バケットのデフォルトグループの設定と、バケット内に作成されたファイルとディレクトリのグループ権限の割り当てを行うフィールドが使用可能になります。



9. ［Default Bucket Group］フィールドにデフォルトバケットグループの名前を入力します。

このグループは、NFS の root ファイルシステム、および NFS エクスポートで作成されたファイルまたはディレクトリに関連づけられたグループになります。これにより、グループのメンバーであるユーザーが NFS エクスポートにアクセスでき、ファイルおよびディレクトリにアクセスできるようになります。

バケットの作成時に、このグループを指定する必要があります。そうしないと、後からグループを NFS クライアントから割り当てる必要があります。

10. オブジェクトプロトコルを使用してバケットで作成されたファイルとディレクトリに、デフォルト権限を設定します。これらの設定は、オブジェクトプロトコルを使用して作成されたオブジェクトに対する UNIX のグループ権限の適用に使用されます。

S3 プロトコルではグループの概念がないため、S3 でグループ権限を設定したり、UNIX の権限にマッピングしたりする機会がありません。そのため、これは S3 プロトコルを使用して作成したファイルやディレクトリに 1回限りの機会を提供し、ここで指定された権限を持つ指定されたデフォルトのグループに割り当てられます。

a. 適切な権限ボタンをクリックして、［Group File Permissions］を設定します。

通常は、Read権限と Execute権限を設定します。

b. 適切な権限ボタンをクリックして、［Group Directory Permissions］を設定します。

通常は、Read権限と Execute権限を設定します。

11. ［Save］をクリックしてバケットを作成します。

ECS Portal を使用して NFS エクスポートを追加ECS Portal を使用して、NFS エクスポートを作成し、エクスポートへのアクセスを制御するオプションを設定することができます。はじめにl この操作には、ECS でのネームスペース管理者またはシステム管理者のロールが必要です。l ネームスペース管理者は、自分のネームスペースに NFS エクスポートを追加できます。l システム管理者は、すべてのネームスペースに NFS エクスポートを追加できます。l エクスポートのための基盤ストレージを提供するバケットが作成されている必要があります。


ECS Portal を使用して NFS エクスポートを追加 113

手順1. ECS ポータルでは、［File］ > ［Exports］ > ［New Export］ページを選択します。

［New File Export］サブページが表示されます。次の図では、NFS クライアントホストでアクセス用に構成されたエクスポートを示します。

=

2. ［New File Export］サブページの［Namespace］フィールドで、エクスポートするバケットを所有しているネームスペースを選択します。

3. ［Bucket］フィールドで、バケットを選択します。4. ［Export Path］フィールドにパスを指定します。

ECS では、ネームスペースとバケットに基づいてエクスポートパスが自動的に生成されます。バケット内にすでに存在するディレクトリをエクスポートする場合は、名前を入力する必要があるだけです。そのため、たとえば/namespace1/bucket1/dir1 を入力する場合、dir1 が存在することを確認する必要があります。存在しない場合は、エクスポートのマウントは失敗します。

5. 次の手順を実行して、エクスポートにアクセスできるようにするホストを追加します。a.［Export Host Options］エリアで、［Add］をクリックします。

［Add Export Host］ダイアログボックスが表示されます。



b.［Add Export Host］ダイアログで、エクスポートにアクセスできるようにする 1台以上のホストを指定し、アクセスオプションを構成します。

［Authentication］オプションを選択する必要があります。Kerberos を構成する場合を除き、これは通常 Sys です。［Permissions (ro)］および［Write Transfer Policy(async)］のデフォルト値はすでに［Add Export Host］ダイアログで設定済みで、NFS サーバに渡されます。残りのオプションは、NFS サーバのデフォルト値と同じであるため、変更した場合のみ ECS から渡されます。

次の表で、ホストを追加するときに指定できるパラメーターを説明します。

設定説明

Export Host ホスト、またはエクスポートにアクセスできるホストの IP アドレスを設定します。複数のホストは、コンマ区切りリストを使用して指定します。

Permissions 読み取り/書き込みまたは読み取り専用として設定されるエクスポートへのアクセスを有効にします。これは/etc/exports の rw または ro の設定と同じです。

Write Transfer Policy 同期または非同期の書き込み転送ポリシーを設定します。デフォルトは非同期です。このパラメーターは/etc/exports でのエクスポートの sync または async の設定と同じです。

Authentication エクスポートによってサポートされる認証タイプを設定します。

Mounting Directories Inside Export エクスポートパスのサブディレクトリがマウントポイントとして使用できるかどうかを指定します。このパラメーターは/etc/exports での alldir の設定と同じです。


ECS Portal を使用して NFS エクスポートを追加 115

設定説明

alldir オプションを使用して、たとえば/namespace1/bucket1 をエクスポートした場合、既存ディレクトリの/namespace1/bucket1/dir1 のようなサブディレクトリもマウントできます。

AnonUser エクスポートにアクセスする匿名ユーザー、および root_squash が設定されている root アクセスに対して有効なユーザー ID を設定します。これは/etc/exports の anonuid の設定と同じです。

AnonGroup エクスポートにアクセスする匿名グループ、および root_squash が設定されている root アクセスに対する有効なグループ ID を設定します。これは/etc/exports の anongid の設定と同じです。

RootSquash root がエクスポートで使用できるかどうかを指定します。root が使用できない場合、root ユーザーのUID（UID=0）をユーザー nobody の UID か、AnonUser で指定した UID に変換します。このパラメーターは/etc/exports での root_squash と同じです。

c.［Add］をクリックして、ホストオプションの定義を完了します。6. エクスポートにアクセスできる異なるオプションの他のホストを追加する場合は、これまでのス

テップを繰り返します。7. NFS エクスポート定義を保存するには、［Save］をクリックします。

ECS Portal を使用してユーザーまたはグループマッピングを追加ファイルシステム（バケット）にアクセスする NFS を提供するには、UNIX ユーザーがオブジェクトユーザーと同じ権限を取得するように、バケットでの権限を持つオブジェクトユーザーを UNIX UID（ユーザー ID）にマッピングする必要があります。または、バケットに権限を持つ ECS カスタムグループをUNIX グループのメンバーのアクセスを提供する UNIX GID（グループ ID）にマッピングすることができます。はじめにl この操作には、ECS でのネームスペース管理者またはシステム管理者のロールが必要です。l ネームスペース管理者は、自分のネームスペースにユーザーまたはグループマッピングを追加で

きます。l システム管理者は、すべてのネームスペースにユーザーまたはグループマッピングを追加できま

す。l NFS クライアントに UID が存在し、ユーザー名が ECS オブジェクトのユーザー名であることを確

認します。l グループメンバーがファイルシステムにアクセスするには、デフォルトのカスタムグループがバケット

に割り当てられていることを確認します。l オブジェクトプロトコルを使用して作成されたオブジェクトおよびディレクトリにグループメンバーが

アクセスするには、デフォルトのオブジェクトおよびディレクトリの権限がバケットに割り当てられていることを確認します。

手順1. ECS ポータルの［Manage］ > ［File］ページで、［User/Group Mapping］タブをクリックします。

2. ［User/Group Mapping］タブで、［New Mapping］をクリックして、［New User/GroupMapping］サブページを表示します。



3. ［User/Group Name］フィールドに、ECS オブジェクトユーザー名または UNIX の UID または GID にマッピングする ECS カスタムグループ名を入力します。

4. ［Namespace］フィールドで、ECS オブジェクトユーザーまたはカスタムグループが属するネームスペースを選択します。

5. ［ID］フィールドで、ESC ユーザーまたはグループをマップする UNIX の UID または GID を入力します。

6. ［Type］フィールドで、マッピングのタイプをクリックします。［User］または［Group］で、入力した ID が UID または GID であることを ECS で認識できます。


Kerberos セキュリティを使用した NFS の構成Kerberos セキュリティを使用した NFS を構成できます。次のシナリオに対応しています。l ECS クライアントから単一 ECS ノード。NFS サーバーとして使用する各 ECS上のキータブ

は、そのノードに固有である必要があります。l ECS クライアントからロードバランサー。すべての ECS ノード上のキータブは同じで、ロードバラ

ンサーのホスト名が使用されます。Kerberos セキュリティを使用した ECS NFS の構成（118 ページ）を参照。内部 IT設定に応じて、KDC を使用することも、自分の KDC として AD（Active Directory）を使用することもできます。


Kerberos セキュリティを使用した NFS の構成 117

AD を使用するには、次のタスクの手順に従います。Active Directory を使用した ECS ノードの登録（121 ページ）および Active Directory を使用した Linux NFS クライアントの登録（123ページ）です。

Kerberos セキュリティを使用した ECS NFS の構成NFS ECS で Kerberos認証を構成するには、ECS ノードと NFS クライアントの両方で構成する必要があり、NFS サーバプリンシパル用と NFS クライアントプリンシパル用のキータブを作成する必要があります。手順

1. ECS ノードのホスト名を解決できることを確認します。

hostname コマンドを使用して、ECS ノードの完全修飾ドメイン名が/etc/HOSTNAMEに追加されていることを確認できます。

dataservice-10-247-142-112:~ # hostname ecsnode1.yourco.comdataservice-10-247-142-112:~ # hostname -i10.247.142.112 dataservice-10-247-142-112:~ # hostname -fecsnode1.yourco.comdataservice-10-247-142-112:~ #

2. Kerberos構成ファイル（krb5.conf）を ECS ノード上に/opt/emc/caspian/fabric/agent/services/object/data/hdfs/krb5.conf として作成します。HDFS がすでに構成されている場合を除き、755（drwxr-xr-x）権限（chmod 755hdfs）で hdfs ディレクトリを作成し、uid 444 のユーザーと gid 444 のグループを所有者（chown 444:444 hdfs）として作成する必要があります。

ファイル権限を 644 に変更し、id 444（storageos）を持つユーザーをファイルの所有者にします。

次の例では、次の値が使用されており、各自の設定と置き換える必要があります。Kerberos レルム

この例では、NFS のレルムを設定します。

KDC

この例では kdcname.yourco.com を設定します。

KDC管理サーバーこの例では、KDCは管理サーバーとして機能します。

[libdefaults] default_realm = NFS-REALM.LOCAL[realms] NFS-REALM.LOCAL = { kdc = kdcname.yourco.com admin_server = kdcname.yourco.com }[logging] kdc = FILE:/var/log/krb5/krb5kdc.log admin_server = FILE:/var/log/krb5/kadmind.log default = SYSLOG:NOTICE:DAEMON



Kerberos の HDFS がすでに構成済みの場合、/opt/emc/caspian/fabric/agent/services/object/data/hdfs/krb5.conf を置き換える代わりに、レルム情報を既存の krb5.conf ファイルにマージします（異なる場合）。REALMは HDFSで構成されるため、通常はこのファイルは変更しません。さらに、デフォルトの権限と所有者をHDFS ですでに構成済みのため、変更の必要がありません。

3. ECS ノードのホストプリンシパルを追加し、プリンシパルのキータブを作成します。この例では、ECS ノードの完全修飾ドメイン名は ecsnode1.yourco.com

$ kadminkadmin> addprinc -randkey nfs/ecsnode1.yourco.comkadmin> ktadd -k /datanode.keytab nfs/ecsnode1.yourco.com kadmin> exit

4. キータブ（datanode.keytab）を/opt/emc/caspian/fabric/agent/services/object/data/hdfs/krb5.keytab にコピーします。HDFS がすでに構成済みの場合を除き、755（drwxr-xr-x）権限（chmod 755 hdfs）で hdfs ディレクトリを作成し、uid 444 のユーザーおよび gid 444 のグループを所有者（chown 444:444hdfs）として作成する必要があります。このユーザーのファイルの権限を 644 に変更して、id 444（storageos）を使用してこのユーザーを所有者にします。

HDFS がすでに構成済みの場合、/opt/emc/caspian/fabric/agent/services/object/data/hdfs/krb5.keytab を置き換える代わりに、datanode.keytab ファイルを既存のキータブファイルに ktutil を使用してマージします。デフォルトの権限と所有者は、HDFS によってすでに構成済みであり、変更の必要はありません。

5. oracle.com から［unlimited］ JCE ポリシーアーカイブをダウンロードして、/opt/emc/caspian/fabric/agent/services/object/data/jce/unlimited ディレクトリに展開します。AES-256などの強力な暗号化タイプを使用するように、Kerberos が構成されている場合があります。そのような場合は、「unlimited」ポリシーを使用するように、ECS ノードの JREを再構成する必要があります。

このステップは、強力な暗号化タイプを使用する場合にのみ実行します。

HDFS がすでに構成済みの場合は、このステップは HDFS Kerberos の構成ですでに完了しています。

6. オブジェクトのコンテナー内から次のコマンドを実行します。

service storageos-dataservice restarthdfs

7. クライアントを設定するには、まずクライアントのホスト名を解決できることを確認してください。



hostname コマンドを使用して、ECS ノードの完全修飾ドメイン名が/etc/HOSTNAMEに追加されていることを確認できます。

dataservice-10-247-142-112:~ # hostname ecsnode1.yourco.comdataservice-10-247-142-112:~ # hostname -i10.247.142.112 dataservice-10-247-142-112:~ # hostname -fecsnode1.yourco.comdataservice-10-247-142-112:~ #

8. クライアントで SUSE Linux が実行されている場合は、/etc/sysconfig/nfs でNFS_SECURITY_GSS="yes"の行がコメント解除されていることを確認します。

9. Ubuntu の場合は、/etc/default/nfs-common に NEED_GSSD=yes の行があることを確認します。

10. rpcbind および nfs-common をインストールします。apt-get または zypper を使用します。SUSE Linux の場合は、nfs-commo で次を使用します。

zypper install yast2-nfs-common

デフォルトでは、Ubuntu クライアントではこれらはオフになっています。11. Kerberos構成ファイルを設定します。

次の例では、次の値が使用されており、各自の設定に置き換える必要があります。Kerberos レルム

この例では NFS-REALM を設定します。KDC

この例では kdcname.yourco.com を設定します。

KDC管理サーバーこの例では、KDCは管理サーバーとして機能します。

[libdefaults] default_realm = NFS-REALM.LOCAL[realms] NFS-REALM.LOCAL = { kdc = kdcname.yourco.com admin_server = kdcname.yourco.com }[logging] kdc = FILE:/var/log/krb5/krb5kdc.log admin_server = FILE:/var/log/krb5/kadmind.log default = SYSLOG:NOTICE:DAEMON

12. NFS クライアントのホストプリンシパルを追加し、プリンシパルのキータブを作成します。この例では、NFS クライアントの完全修飾ドメイン名は nfsclient.yourco.com

$kadminkadmin> addprinc -randkey host/nfsclient.yourco.com



kadmin> ktadd -k /nkclient.keytab host/nfsclient.yourco.comkadmin> exit

13. キータブファイル（nfsclient.keytab）を KDC マシンから NFS クライアントマシン上の/etc/krb5.keytab にコピーします。

scp /nkclient.keytab [email protected]:/etc/krb5.keytabssh [email protected] 'chmod 644 /etc/krb5.keytab'

14. NFS エクスポートにアクセスするユーザーのプリンシパルを作成します。

$kadminkadmin> addprinc [email protected]> exit

15. root としてログインし、次のエントリーを/etc/fstab ファイルに追加します。

HOSTNAME:MOUNTPOINT LOCALMOUNTPOINT nfs rw,user,nolock,noauto,vers=3,sec=krb5 0 0

例：

ecsnode1.yourco.com:/s3/b1 /home/kothan3/1b1 nfs rw,user,nolock,noauto,vers=3,sec=krb5 0 0

16. 非 root ユーザーとしてログインし、作成した非 root ユーザーとして kinit を実行します。

kinit [email protected]

17. これで、NFS エクスポートをマウントすることができますようになりました。

root ユーザーとしてマウントすると、kinit を使用する必要はありません。ただし、root を使用しているときは、Kerberos のプリンシパルではなく、クライアントマシンのホストのプリンシパルを使用して認証が行われます。オペレーティングシステムによっては、ログインしたときにKerberos チケットを取得する認証モジュールを構成することができます。これにより、kinit を使用して手動でチケットを取得する必要がなくなり、NFS共有を直接マウントできるようになります。

Active Directory を使用した ECS ノードの登録AD（Active Directory）を NFS Kerberos構成の KDC として使用するには、AD にクライアントとサーバのアカウントを作成し、そのアカウントをプリンシパルにマップする必要があります。NFS サーバーでは、プリンシパルは NFS サービスアカウントを表し、NFS クライアントでは、プリンシパルはクライアントホストマシンを表します。



はじめにAD ドメインコントローラーの管理者の認証情報が必要です。手順

1. AD にログインします。2. Server Manager で、［Tools］ > ［Active Directory Users and Computers］の

順に移動します。3. 「nfs-<host>」形式を使用して NFS プリンシパルのユーザーアカウントを作成します。例：

「nfs-ecsnode1」。パスワードを設定し、使用期間が終了しないように設定します。4. 自分のアカウントを作成します（オプション、1回のみ）。5. 次のコマンドを実行して NFS サービスアカウントのキータブファイルを作成します。

ktpass -princ nfs/<fqdn>REALM.LOCAL +rndPass -mapUser nfs-<host>@REALM.LOCAL -mapOp set -crypto All -ptype KRB5_NT_PRINCIPAL -out filename.keytab

たとえば、nfs-ecsnode1 アカウントをプリンシパル nfs/[email protected] に関連づけるには、次を使用してキータブを生成できます。

ktpass -princ nfs/[email protected] +rndPass -mapUser [email protected] -mapOp set -crypto All -ptype KRB5_NT_PRINCIPAL -out nfs-ecsnode1.keytab

6. ECS ノードにキータブをインポートします。

ktutilktutil> rkt <keytab to import>ktutil> wkt /etc/krb5.keytab

7. 実行して、登録をテストします。

kinit -k nfs/<fqdn>@NFS-REALM.LOCAL

8. klist コマンドを実行して、キャッシュされている認証情報を表示します。9. kdestroy コマンドを実行して、キャッシュされている認証情報を削除します。

10. klist コマンドを実行して、キータブファイルにエントリーを表示します。

例：

klist -kte /etc/krb5.keytab

11. 「Kerberos セキュリティを使用した ECS NFS の構成（118 ページ）」から「2（118 ページ）」、「4（119 ページ）」、「5（119 ページ）」のステップに従い、Kerberos構成ファイル（krb5.conf、krb5.keytab 、jce/unlimited）を ECS ノードに配置します。



Active Directory を使用した Linux NFS クライアントの登録AD（Active Directory）を NFS Kerberos構成の KDC として使用するには、AD にクライアントとサーバーのアカウントを作成し、そのアカウントをプリンシパルにマップする必要があります。NFS サーバーでは、プリンシパルは NFS サービスアカウントを表し、NFS クライアントでは、プリンシパルはクライアントホストマシンを表します。

はじめにAD ドメインコントローラーの管理者の認証情報が必要です。手順

1. AD にログインします。2. Server Manager で、［Tools］ > ［Active Directory Users and Computers］の

順に移動します。3. ［Active Directory Users and Computers］ページで、クライアントマシンのコンピュータ

ーアカウントを作成します。次に例を挙げます。nfsclient。パスワードを設定し、使用期間が終了しないように設定します。

4. ユーザーのアカウントを作成（オプション、1回）5. 次のコマンドを実行して NFS サービスアカウントのキータブファイルを作成します。

ktpass -princ host/<fqdn>@REALM.LOCAL +rndPass -mapUser <host>@REALM.LOCAL -mapOp set -crypto All -ptype KRB5_NT_PRINCIPAL -out filename.keytab

たとえば、nfs-ecsnode1 アカウントをプリンシパル host/[email protected] に関連づけるには、次のことを使用してキータブを生成します。

ktpass -princ host/[email protected] +rndPass -mapUser [email protected] -mapOp set -crypto All -ptype KRB5_NT_PRINCIPAL -out nfsclient.keytab

6. クライアントノードにキータブをインポートします。

ktutilktutil> rkt <keytab to import>ktutil> wkt /etc/krb5.keytab

7. 実行して、登録をテストします。

kinit -k host/<fqdn>@NFS-REALM.LOCAL

8. klist コマンドを実行して、キャッシュされている認証情報を表示します。9. kdestroy コマンドを実行して、キャッシュされている認証情報を削除します。

10. klist コマンドを実行して、キータブファイルにエントリーを表示します。次に例を挙げます。

klist -kte /etc/krb5.keytab



11. 「Kerberos セキュリティを使用した ECS NFS の構成（118 ページ）」から「2（118 ページ）」、「4（119 ページ）」、「5（119 ページ）」のステップに従い、Kerberos構成ファイル（krb5.conf、krb5.keytab 、jce/unlimited）を ECS ノードに配置します。

NFS エクスポートのマウントの例

エクスポートをマウントする場合、次の前提条件のステップを実行する必要があります。l バケット所有者名を UNIX の UID にマッピングします。l デフォルトグループをバケットに割り当て、デフォルトグループの名前を Linux GID にマッピングし

ます。これにより、エクスポートをマウントするときに、デフォルトグループが関連づけられた Linuxグループとして表示されます。

次の手順は、ECS NFS エクスポートファイルシステムをマウントする方法の例を示しています。1. エクスポートをマウントするディレクトリを作成します。ディレクトリは、バケットと同じ所有者に属している必要があります。この例では、ユーザー fred が、エクスポートをマウントするディレクトリ/home/fred/nfsdir を作成します。

su - fredmkdir /home/fred/nfsdir

2. root ユーザーとして、作成したディレクトリマウントポイント内でエクスポートをマウントします。

mount -t nfs -o "vers=3,nolock" 10.247.179.162:/s3/tc-nfs6 /home/fred/nfsdir

NFS エクスポートをマウントする場合、VDC内の任意のノードの名前または IP アドレス、またはロードバランサーのアドレスを指定します。-o "vers=3"を指定することが重要です。

3. ユーザー fred として、ファイルシステムにアクセスできることを確認します。a. ユーザー fred に切り換えます。

$ su - fred

b. マウントポイントディレクトリを作成したディレクトリにいることを確認します。

$ pwd/home/fred

c. ディレクトリを一覧表示します。

fred@lrmh229:~$ ls -altotaldrwxr-xr-x 7 fred fredsgroup 4096 May 31 05:38 .drwxr-xr-x 18 root root 4096 May 30 04:03 ..-rw------- 1 fred fred 16 May 31 05:31 .bash_historydrwxrwxrwx 3 fred anothergroup 96 Nov 24 2015 nfsdir

この例では、バケット所有者が fred で、デフォルトグループ anothergroup がこのバケットに関連づけられました。



グループマッピングが作成されていない場合、またはデフォルトグループがバケットに関連づけられていない場合は、グループ名は表示されませんが、以下に示すように大きな数値が表示されます。

fred@lrmh229:~$ ls -altotal drwxr-xr-x 7 fred fredssgroup 4096 May 31 05:38 .drwxr-xr-x 18 root root 4096 May 30 04:03 ..-rw------- 1 fred fred 16 May 31 05:31 .bash_historydrwxrwxrwx 3 fred 2147483647 96 Nov 24 2015 nfsdir

グループマッピングを忘れた場合、ECS Portal で適切なマッピングを作成できます。/etc/group の中を調べて、このグループ ID を見つけることができます。

fred@lrmh229:~$ cat /etc/group | grep anothergroupanothergroup:x:1005:

名前と GID の間のマッピングを追加します（この場合は、anothergroup => GID1005）。

root ユーザーとして、またはこのファイルシステムで権限を持たない別のユーザーとしてマウントされたファイルシステムにアクセスを試行すると、次のように?が表示されます。

root@lrmh229:~# cd /home/fredroot@lrmh229:/home/fred# ls -altotal drwxr-xr-x 8 fred fredsgroup 4096 May 31 07:00 .drwxr-xr-x 18 root root 4096 May 30 04:03 ..-rw------- 1 fred fred 1388 May 31 07:31 .bash_historyd????????? ? ? ? ? ? nfsdir

ECS NFS を使用する場合のベストプラクティスECS の NFS エクスポートをマウントする場合は、次の推奨事項が適用されます。

非同期の使用可能であれば、「非同期」マウントオプションを使用する必要があります。このオプションにより、レーテンシーの大幅な短縮し、スループットの向上、クライアントからの接続数の削減を行えます。

wsize と rsizeの設定によるクライアントからのラウンドトリップの削減大規模ファイルの読み取り/書き込みを行う場合は、rsize および wsize マウントオプションを使用してファイルの読み取りまたは書き込みサイズを適切に設定するようにする必要があります。クライアントからのラウンドトリップ数を削減するために、rsize と wsize を可能な限り大きな値に設定することを一般にお勧めします。通常は、512 KB（524288 B）。たとえば 10 MB の書き込みの場合、wsize が 524288（512 KB）に設定されていれば個別に行われる呼び出しの回数は 20回ですが、wsize が 32 KB に設定されていると、その回数は 16倍に及びます。


ECS NFS を使用する場合のベストプラクティス 125

mount コマンドを使用する場合は、オプション（-o）スイッチを使用して読み取りサイズおよび書き込みサイズを指定できます。例：

# mount 10.247.97.129:/home /home -o "vers=3,nolock,rsize=524288,wsize=524288"

マルチプロトコル（クロスヘッド）アクセスの権限オブジェクトには、NFS およびオブジェクトサービスを使用してアクセスすることができます。各アクセスメソッドには、次のような権限の保存方法があります。オブジェクトの ACL（アクセス制御リスト）権限とファイルシステム権限。

オブジェクトプロトコルでオブジェクトを作成または変更すると、オブジェクト所有者に関連づけられている権限が NFS権限にマッピングされ、対応する権限が格納されます。同様に、オブジェクトがNFS で作成または変更されると、ECS が所有者の NFS権限をオブジェクトの権限にマッピングし格納します。S3 オブジェクトプロトコルには、グループの概念はありません。NFS からのグループ所有権または権限の変更を、対応するオブジェクトの権限にマップする必要はありません。バケットまたはバケット内のオブジェクト（ファイルおよびディレクトリに相当）を作成した場合は、ECS で UNIX グループの権限を割り当てることができ、NFS ユーザーがそれらにアクセスできるようになります。NFS では、次の ACL属性が保存されます。l 所有者l グループl その他オブジェクトアクセスの場合は、次の ACL が保存されます。l ユーザーl カスタムグループl グループ（事前定義）l 所有者（「ユーザー」の中の特定のユーザー）l プライマリグループ（「カスタムグループ」の中の特定のグループ）ACL の詳細については、ACL の設定（92 ページ）を参照してください。次の表は、NFS ACL属性とオブジェクト ACL属性の間のマッピングを示しています。

NFS ACL属性オブジェクト ACL属性

所有者所有者でもあるユーザー

グループプライマリグループでもあるカスタムグループ

その他事前定義されたグループ

このマッピングの例は、このトピックで後述します。次の ACE（アクセス制御エントリー）を ACL の各属性に割り当てできます。NFS ACE：l 読み込み（R）l 書き込み（W）l 実行（X）



オブジェクト ACE：l 読み込み（R）l 書き込み（W）l 実行（X）l ReadAcl（RA）l WriteAcl（WA）l フルコントロール（FC）

NFS を使用したオブジェクトの作成および修正とオブジェクトサービスを使用したアクセスNFS ユーザーが NFS プロトコルでオブジェクトを作成すると、所有者の権限が、バケットの所有者として指定されているオブジェクトユーザーの ACL にミラーリングされます。NFS ユーザーに RWX権限がある場合、オブジェクト ACL ではフルコントロールがオブジェクト所有者に割り当てられます。NFS ファイルまたはディレクトリが属するグループに割り当てられている権限は、同じ名前のカスタムグループ（存在する場合）に反映されます。ECSは、「その他」と関連づけられた権限を、事前定義されたグループの権限に反映します。次の例では、オブジェクト権限に対する NFS権限のマッピングを示しています。

NFS ACL Setting Object ACL Setting

Owner John : RWX Users John : Full ControlGroup ecsgroup : R-X ---> Custom Groups ecsgroup : R-XOther RWX Groups All_Users : R, RA Owner John Primary Group ecsgroup

ユーザーが NFS で ECS にアクセスし、オブジェクトの所有権を変更する場合、新しい所有者は所有者 ACL権限を継承し、さらに Read_ACL とWrite_ACL が付与されます。以前の所有者の権限は、そのオブジェクトユーザーの ACL に保持されます。chmod操作を実行する場合は、オブジェクトを作成するときと同じ方法で権限を ECS が反映します。オブジェクトユーザーの ACL にすでに存在している場合、Write_ACLはグループと「その他」の権限に保存されます。

オブジェクトサービスを使用したオブジェクトの作成および変更と NFS を使用したアクセスオブジェクトユーザーがオブジェクトサービスでオブジェクトを作成する場合、ユーザーはオブジェクトの所有者であり、オブジェクトのフルコントロールを自動的に許可します。ファイルの所有者には、RWX権限が付与されます。所有者の権限がフルコントロール以外のものに設定されている場合、ECSはオブジェクトの RWX権限にファイルの RWX権限を反映しています。RX権限を持つオブジェクトの所有者は、RX権限を持つ NFS ファイル所有者になります。バケットのデフォルトグループを使用して設定されているオブジェクトのプライマリグループは、オブジェクトが属するカスタムグループになり、オブジェクトの権限は設定されているデフォルトの権限に基づいて設定されます。これらの権限は、NFS.group の権限に反映します。オブジェクトのカスタムグループがフルコントロールになる場合は、これらの権限は NFS グループに対しては RWX権限になります。事前定義済みグループがバケット上に指定されている場合は、これらがオブジェクトに適用され、NFS ACL の「その他」の権限として反映されます。次の例では、NFS権限に対するオブジェクト権限のマッピングを示しています。

Object ACL Setting NFS ACL Setting


マルチプロトコル（クロスヘッド）アクセスの権限 127

Users John : Full Control Owner John : RWXCustom Groups ecsgroup : R-X ----> Group ecsgroup : R-X Groups All_Users : R, RA Other RWX Owner JohnPrimary Group ecsgroup

オブジェクトの所有者を変更する場合、新しい所有者に関連づけられている権限は、オブジェクトに適用され、ファイルの RWX権限に反映されます。

ファイル API サマリーNFS アクセスは、ECS管理 REST API を使用して構成および管理することができます。

次の表に、使用できる API のサマリーを示します。

方法説明

POST /object/nfs/exports エクスポートを作成。ペイロードには、エクスポートパス、エクスポートにアクセスできるホスト、エクスポートのセキュリティ設定を定義する文字列を指定します。

PUT/GET/DELETE /object/nfs/exports/{id} 指定されたエクスポート上で選択された動作を実行。

GET /object/nfs/exports 現在のネームスペースに対して定義されているすべてのユーザーエクスポートを取得。

POST /object/nfs/users ECS オブジェクトユーザー名またはグループ名とUNIX ユーザー ID またはグループ ID間のマッピングを作成。

PUT/GET/DELETE /object/nfs/users/{mappingid}

指定されたユーザーまたはグループのマッピングで選択されたオペレーションを実行。

GET /object/nfs/users 現在のネームスペースに対して定義されているすべてのユーザーマッピングを取得。

API の完全な詳細情報については、API のドキュメントに記述されています。NFS エクスポート方法に関するドキュメントは、ECS API リファレンスから入手できます。



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

第 9章

証明書

l 証明書の概要.................................................................................................... 130l 証明書の生成.................................................................................................... 130l 証明書のアップロード............................................................................................ 135l インストールされている証明書の確認...................................................................... 139

証明書 129

証明書の概要出荷された ECS には、ノードごとにキーストアにインストールされている SSL証明書が付属しています。この証明書は、ECS と通信するアプリケーション、またはユーザーが ECS Portal から ECS にアクセスする際のブラウザでは信頼されません。証明書が信頼されないというエラーの表示なしで、またはアプリケーションと ECS が通信するには、信頼できる CA（証明書機関）によって署名された証明書をインストールする必要があります。CAの署名済み証明書を持つまで使用する自己署名証明書を生成することができます。自己署名証明書は、ECS にアクセスするすべてのマシンの証明書ストアにインストールされます。ECS では、次の 2種類の SSL証明書を使用します。管理証明書

ECS管理 REST API API を使用して、管理リクエストで使用します。これらの HTTPS リクエストは、ポート 4443 を使用します。

オブジェクト証明書サポートされるオブジェクトプロトコルを使用して、リクエストで使用します。これらの HTTPS リクエストは、ポート 9021（S3）、9023（Atmos）、9025（Swift）を使用します。

自己署名証明書または CA認証局によって署名された証明書をアップロードします。オブジェクト証明書の場合は、ECS に生成をリクエストすることができます。このキー/証明書のペアはどちらも、ポート 4443 で ECS管理 REST API API を介して ECS にアップロードすることができます。以降のトピックでは、証明書の作成、アップロード、検証の方法について説明します。l 証明書の生成（130 ページ）l 証明書のアップロード（135 ページ）l インストールされている証明書の確認（139 ページ）

証明書の生成自己署名証明書を生成するか、CA（認証局）から証明書を購入します。任意のクライアントマシンが追加手順なしで証明書を検証できるため、商用の場合は CA署名済み証明書を強くお勧めします。証明書は PEM でエンコードされた x509形式である必要があります。証明書を作成する場合、通常は証明書を使用するホスト名を指定します。ECSは複数ノードを使用し、それぞれのノードが独自のホスト名を使用するため、特定のホスト名用に作成された証明書をインストールすると、そのホスト名を持たないノード上で共通名不整合エラーが発生することがあります。証明書は、代替 IP アドレス、または SAN（主体者代替名）と呼ばれるホスト名で作成することができます。オブジェクトプロトコルとの互換性を最大に高めるには、証明書の CN（共通名）を S3 で使用するワイルドカード DNS エントリーにする必要があります。これは、S3 が、仮想ホスト型バケットを使用する（つまり、ホスト名にバケット名を挿入する）唯一のプロトコルであるためです。SSL証明書で使用できるワイルドカードエントリーを 1 つのみ指定し、それは CN に存在している必要があります。Atmos プロトコルおよび Swift プロトコルのロードバランサー用のその他の DNS エントリーは、SAN（主体者代替名）として証明書に登録する必要があります。このセクションのトピックでは、 openssl を使用した証明書または証明書リクエストの生成方法を説明しますが、お客様の IT組織の証明書生成の要件または処理手順は異なる場合もあります。

証明書


秘密キーの作成自己署名証明書に署名するために、リクエストの署名作成できる秘密キーを作成します。SSLは、秘密キーと公開キーが必要な公開鍵暗号化を使用します。構成の最初のステップでは、秘密キーを作成します。公開キーは、証明書署名リクエストまたは証明書を作成するときに、秘密キーを使用して自動的に作成されます。次の手順では、OpenSSL ツールを使用して、秘密キーを作成する方法について説明します。

手順1. ECS ノードにログインするか、ECS クラスタに接続することができるノードにログインします。2. openssl ツールを使用して秘密キーを生成します。

たとえば、server.key というキーを作成するには次のようにします。

openssl genrsa -des3 -out server.key 2048

3. メッセージが表示されたら、秘密キーのパスフレーズを入力し、確認のためにもう一度入力します。自己署名証明書または証明書署名のリクエストをキーを使用して作成する場合に、このパスフレーズを入力する必要があります。キーを ECS にアップロードする前に削除されるパスフレーズを使用して、キーのコピーを作成する必要があります。詳細については、証明書のアップロード（135 ページ）を参照してください。

4. キーファイルの権限を設定します。

chmod 0400 server.key

SAN構成の生成SAN（主体者代替名）をサポートする証明書が必要な場合、構成ファイルに代替名を定義する必要があります。OpenSSL では、コマンドラインから SANs（サブジェクトの別名）を受け渡すことができないため、最初に構成ファイルに追加する必要があります。これには、デフォルトの OpenSSL構成ファイルを指定する必要があります。Ubuntu では、これは/usr/lib/ssl/openssl.cnf にあります。手順

1. 構成ファイルを作成します。

cp /usr/lib/ssl/openssl.cnf request.conf

2. テキストエディタで構成ファイルを編集し、次のように変更します。a.［alternate_names］を追加します。

例：

[ alternate_names ]DNS.1 = os.example.comDNS.2 = atmos.example.comDNS.3 = swift.example.com

証明書

秘密キーの作成 131

ブラケットとセクション名の間にスペースがあります。

ロードバランサーではなく、ECS ノードに証明書をアップロードする場合、その形式は次のようになります。

[ alternate_names ]IP.1 = <IP node 1>IP.2 = <IP node 2>IP.3 = <IP node 3>...

b.［v3_ca］のセクションに次の行を追加します。

subjectAltName = @alternate_namesbasicConstraints = CA:FALSEkeyUsage = nonRepudiation, digitalSignature, keyEnciphermentextendedKeyUsage = serverAuth

次の行は、この［v3_ca］セクションにすでに存在する可能性が高いです。証明書署名リクエストを作成している場合は、次のようにコメントアウトする必要があります。

#authorityKeyIdentifier=keyid:always,issuer

c.［req］のセクションに次の行を追加します。

x509_extensions = v3_ca #for self signed certreq_extensions = v3_ca #for cert signing req

d.［CA_default］セクションでは、コメントを削除または行を追加します。

copy_extension=copy

自己署名証明書の生成自己署名証明書を作成できます。はじめにl 秘密キーの作成（131 ページ）の手順を使用して、秘密キーを作成する必要があります。l SAN を使用する証明書を作成する場合は、SAN構成の生成（131 ページ）の手順を使用

して、SAN構成ファイルを作成する必要があります。手順

1. 秘密キーを使用して、リクエストに署名する自己署名証明書を生成します。署名リクエストを作成する 2 つの方法を説明します。1 つ目の方法は、すでに代替サーバ名を指定する SAN構成ファイルを作成済みの場合、もう 1 つの方法は、作成していない場合です。

証明書


SAN を使用している場合：

openssl req -x509 -new -key server.key -config request.conf -out server.crt

SAN を使用していない場合：

openssl req -x509 -new -key server.key -out server.crt

サンプル出力。

Signature oksubject=/C=US/ST=GA/

2. 秘密キーのパスフレーズを入力します。3. プロンプトが表示されたら、証明書の DN のフィールドに入力します。

ほとんどのフィールドはオプションです。CN（一般名）を入力する必要があります。

CNは完全修飾ドメイン名の必要があります。ECS ノードに、証明書をインストールする場合でも、完全修飾ドメイン名を使用する必要があり、すべての IP アドレスが代替名のセクションに必要です。

次のプロンプトが表示されます。

You are about to be asked to enter information that will be incorporatedinto your certificate request.What you are about to enter is what is called a Distinguished Name or a DN.There are quite a few fields but you can leave some blankFor some fields there will be a default value,If you enter '.', the field will be left blank.-----Country Name (2 letter code) [AU]:USState or Province Name (full name) [Some-State]:Locality Name (eg, city) []:Organization Name (eg, company) [Internet Widgits Pty Ltd]:AcmeOrganizational Unit Name (eg, section) []:Common Name (e.g. server FQDN or YOUR name) []:*.acme.comEmail Address []:

4. プロンプトが表示されたら、DN（識別名）の詳細情報を入力します。DN フィールドの詳細は、DN（識別名）フィールド（133 ページ）のとおりです。

5. 証明書を表示します。

openssl x509 -in server.crt -noout -text

DN（識別名）フィールド

次の表に、DN フィールドの説明を示します。

証明書

自己署名証明書の生成 133

項目説明例

Common Name (CN) サーバの FQDN（完全修飾ドメイン名）。ECS アプリケーションをインストールするときに指定した名前です。

*. yourco.comecs1.yourco.com

Organization 組織の正式名称です。短縮せずに、Inc.、Corp、LLCなどのサフィックスを含める必要があります。

Yourco inc.

Organizational Unit 証明書を処理する組織の部門。 IT部門

Locality/City 組織が所在する都道府県/地域です。これは省略しません。 Mountain View

State/Province 組織が所在する市区町村名です。カリフォルニア

Country 組織が所在する国の 2文字の ISO コードです。 US

Email address お客様の組織に連絡するためのメールアドレスです。 [email protected]

証明書署名リクエストの生成署名済み証明書を取得するには、CA に送信する証明書署名リクエストを作成します。

はじめにl 秘密キーの作成（131 ページ）の手順を使用して、秘密キーを作成する必要があります。l SAN を使用する証明書を作成する場合は、SAN構成の生成（131 ページ）の手順を使用

して、SAN構成ファイルを作成する必要があります。手順

1. 秘密キーを使用して、リクエストに署名する証明書を生成します。署名リクエストを作成する 2 つの方法を説明します。1 つ目の方法は、すでに代替サーバ名を指定する SAN構成ファイルを作成済みの場合、もう 1 つの方法は、作成していない場合です。

SAN を使用している場合：

openssl req -new -key server.key -config request.conf -out server.csr

SAN を使用していない場合：

openssl req -new -key server.key -out server.csr

署名リクエストを作成する場合は、フィールドの数を構成する DN（識別名）を指定するよう求められます。共通名のみが必要で、他のパラメーターにはデフォルトを受け入れることができます。

2. 秘密キーのパスフレーズを入力します。3. プロンプトが表示されたら、証明書の DN のフィールドに入力します。

ほとんどのフィールドはオプションです。ただし、CN（一般名）を入力する必要があります。

証明書


CNは完全修飾ドメイン名の必要があります。ECS ノードに、証明書をインストールする場合でも、完全修飾ドメイン名を使用する必要があり、すべての IP アドレスが代替名のセクションに必要です。

次のプロンプトが表示されます。

You are about to be asked to enter information that will be incorporatedinto your certificate request.What you are about to enter is what is called a Distinguished Name or a DN.There are quite a few fields but you can leave some blankFor some fields there will be a default value,If you enter '.', the field will be left blank.-----Country Name (2 letter code) [AU]:USState or Province Name (full name) [Some-State]:Locality Name (eg, city) []:Organization Name (eg, company) [Internet Widgits Pty Ltd]:AcmeOrganizational Unit Name (eg, section) []:Common Name (e.g. server FQDN or YOUR name) []:*.acme.comEmail Address []:

DN フィールドの詳細は、DN（識別名）フィールド（133 ページ）のとおりです。

4. オプションのチャレンジパスワードと会社名の入力を求められます。

Please enter the following 'extra' attributesto be sent with your certificate requestA challenge password []:An optional company name []:

5. 証明書を表示します。

openssl req -in server.csr -text -noout

結果証明書署名リクエストを CA に送信すると、署名済み証明書ファイルが返されます。

証明書のアップロードECS に管理またはデータの証明書をアップロードできます。アップロードするいずれのタイプの証明書も、API を使用して認証する必要があります。l ECS Management REST API による認証（136 ページ）l 管理証明書のアップロード（136 ページ）l データアクセスエンドポイントのデータ証明書のアップロード（138 ページ）

証明書

証明書のアップロード 135

ECS Management REST API による認証ECS Management REST API コマンドを実行するには、まず、API サービスで認証して、認証トークンを取得する必要があります。手順

1. ECS Management REST API を使用して認証し、API を使用して、証明書をアップロードまたは検証する際に使用する認証トークンを取得します。a. 次のコマンドを実行します。

export TOKEN=`curl -s -k -v -u <user>:<password> https://$(hostname -i):4443/login 2>&1 | grep X-SDS-AUTH-TOKEN | awk '{print $2, $3}'`

ユーザー名とパスワードは、ECS Portal へのアクセスに使用されます。public_ipは、ノードのパブリック IP アドレスです。

b. トークンが正常にエクスポートされたことを確認します。

echo $TOKEN

サンプル出力：

X-SDS-AUTH-TOKEN:BAAcTGZjUjJ2Zm1iYURSUFZzKzhBSVVPQVFDRUUwPQMAjAQASHVybjpzdG9yYWdlb3M6VmlydHVhbERhdGFDZW50ZXJEYXRhOjcxYjA1ZTgwLTNkNzktNDdmMC04OThhLWI2OTU4NDk1YmVmYgIADTE0NjQ3NTM2MjgzMTIDAC51cm46VG9rZW46YWMwN2Y0NGYtMjE5OS00ZjA4LTgyM2EtZTAwNTc3ZWI0NDAyAgAC0A8=

管理証明書のアップロードECS Portalや ECS管理 REST APIなどの管理エンドポイントへのアクセス認証に使用される管理証明書をアップロードします。はじめにl ECS管理 REST API を使用して認証済みであることと、ECS Management REST API に

よる認証（136 ページ）の説明に従って、変数（$TOKEN）にトークンを格納済みであることを確認します。

l 使用するマシンに適切な REST クライアント（curlなど）があり、ECS管理 REST API を使用して ECS ノードにアクセスできることを確認します。

l お客様の秘密キーと証明書が、アップロードを実行するマシンで使用可能なことを確認します。手順

1. 秘密キーにパスフレーズがないことを確認します。ある場合は、次のコマンドを入力して、パスフレーズを削除したコピーを作成します。

openssl rsa -in server.key -out server_nopass.key

2. 秘密キーと署名済み証明書を使用して、データパスのキーストアをアップロードします。

証明書


curl を次のように使用します。

curl -svk -H "$TOKEN" -H "Content-type: application/xml" -H "X-EMC-REST-CLIENT: TRUE" -X PUT -d "<rotate_keycertchain><key_and_certificate><private_key>`cat privateKeyFile` <private_key>`</private_key><certificate_chain>`catcertificateFile`</certificate_chain></key_and_certificate></rotate_keycertchain>" https://<ecs_node_address>:4443/vdc/keystore

ECS CLI（ecscli.py）を次のように使用します。

python ecscli.py vdc_keystore update –hostname <ecs_host_ip> -port 4443 –cf <cookiefile> –privateKey privateKeyFile -certificateChain certificateFile

privateKeyFile（たとえば<path>/server_nopass.key）とcertificateFile（たとえば<path>/server.crt）は、証明書ファイルやキーへのパスを書き換える必要があります。

3. ECS ノードの 1 つに、管理ユーザーとしてログインします。4. MACHINES ファイルの内部にすべてのノードがあることを確認します。

viprexec のように、すべてのノードでコマンドを実行する ECS ラッパースクリプトによって、MACHINES ファイルが使用されます。

MACHINES ファイルは/home/admin にあります。

a. MACHINES ファイルのコンテンツを表示します。

cat /home/admin/MACHINES

b. MACHINES ファイルにすべてのノードが含まれていない場合は、再作成します。

getrackinfo -c MACHINES

MACHINES ファイルがすべてのノードを格納したことを確認します。5. objcontrolsvc サービスと nginx サービスを再起動すると、管理証明書が適用され

ます。a. オブジェクトサービスを再起動します。

viprexec -f ~/MACHINES -i 'pidof objcontrolsvc; kill `pidof objcontrolsvc`; sleep 60; pidof objcontrolsvc'

b. nginx サービスを再起動します。

sudo -i viprexec -i -c "/etc/init.d/nginx restart;sleep 60;/etc/init.d/nginx status"

必要条件次の手順を使用して、証明書が正常にアップロードされたことを確認することができます。管理証明書の確認（139 ページ）。

証明書

管理証明書のアップロード 137

データアクセスエンドポイントのデータ証明書のアップロードS3、EMC Atmos、OpenSatck Swift プロトコルのアクセス認証に使用されるデータ証明書をアップロードします。はじめにl ECS管理 REST API を使用して認証済みであることと、変数（$TOKEN）にトークンを格納

済みであることを確認します。ECS Management REST API による認証（136 ページ）を参照。

l 使用するマシンに適切な REST クライアント（curlなど）があり、ECS管理 REST API を使用して ECS ノードにアクセスできることを確認します。

l お客様の秘密キーと証明書が、アップロードを実行するマシンで使用可能なことを確認します。手順

1. 秘密キーにパスフレーズがないことを確認します。パスフレーズがある場合は、削除されたパスフレーズを使用してコピーを作成できます。次のコマンドを使用します。

openssl rsa -in server.key -out server_nopass.key

2. 秘密キーと署名済み証明書を使用して、データパスのキーストアをアップロードします。

curl -svk -H "$TOKEN" -H "Content-type: application/xml" -H "X-EMC-REST-CLIENT: TRUE" -X PUT -d "<rotate_keycertchain><key_and_certificate><private_key>`cat privateKeyFile`</private_key><certificate_chain>`catcertificateFile`</certificate_chain></key_and_certificate></rotate_keycertchain>" https://<ecs_node_address>:4443/object-cert/keystore


python ecscli.py keystore update –hostname <ecs_host_ip> -port 4443 –cf <cookiefile> -pkvf privateKeyFile -cvf certificateFile -ss false

privateKeyFile（たとえば<path>/server_nopass.key）とcertificateFile（たとえば<path>/server.crt）は、証明書ファイルやキーへのパスを書き換える必要があります。

3. 証明書を発行する場合、dataheadsvc サービスを再起動します。これは、次のコマンドで実行できます。

証明書


データ証明書を変更する場合は、サービスを再起動する必要はありません、dataheadsvcは、証明書の更新から 2時間後に各ノードで自動的に再起動されます。

ssh admin@<ecs_ip_where_cert_uploaded>

sudo kill `pidof dataheadsvc`

必要条件次の手順を使用して、証明書が正常にアップロードされたことを確認することができます。オブジェクト証明書の検証（140 ページ）。

インストールされている証明書の確認オブジェクト証明書と管理証明書にはそれぞれ、インストールされている証明書を取得するための独自の ECS Management API GET リクエストがあります。l 管理証明書の確認（139 ページ）l オブジェクト証明書の検証（140 ページ）

管理証明書の確認ECS管理 REST API を使用して、インストールされている管理証明書を取得することができます。

はじめにl ECS管理 REST API を使用して認証済みであることと、変数（$TOKEN）にトークンを格納

済みであることを確認します。ECS Management REST API による認証（136 ページ）を参照します。

l サービスを再起動した場合、すぐに証明書を利用できます。そうでない場合は、証明書がすべてのノードに反映されることを確認するのに、2時間待つ必要があります。

手順1. 証明書を返すには、GET /vdc/keystore メソッドを使用します。

curl ツールを使用すると、メソッドは次のように入力して実行できます。

curl -svk -H "X-SDS-AUTH-TOKEN: $TOKEN" https://x.x.x.x:4443/vdc/keystore


python ecscli.py vdc_keystore get –hostname <ecs_host_ip> -port 4443 –cf <cookiefile>

<?xml version="1.0" encoding="UTF-8" standalone="yes"?><certificate_chain><chain>-----BEGIN CERTIFICATE-----MIIDgjCCAmoCCQCEDeNwcGsttTANBgkqhkiG9w0BAQUFADCBgjELMAkGA1UEBhMC

証明書

インストールされている証明書の確認 139

VVMxCzAJBgNVBAgMAkdBMQwwCgYDVQQHDANBVEwxDDAKBgNVBAoMA0VNQzEMMAoG A1UECwwDRU5HMQ4wDAYDVQQDDAVjaHJpczEsMCoGCSqGSIb3DQEJARYdY2hyaXN0 b3BoZXIuZ2hva2FzaWFuQGVtYy5jb20wHhcNMTYwNjAxMTg0MTIyWhcNMTcwNjAy MTg0MTIyWjCBgjELMAkGA1UEBhMCVVMxCzAJBgNVBAgMAkdBMQwwCgYDVQQHDANB VEwxDDAKBgNVBAoMA0VNQzEMMAoGA1UECwwDRU5HMQ4wDAYDVQQDDAVjaHJpczEs MCoGCSqGSIb3DQEJARYdY2hyaXN0b3BoZXIuZ2hva2FzaWFuQGVtYy5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDb9WtdcW5HJpIDOuTB7o7ic0RK dwA4dY/nJXrk6Ikae5zDWO8XH4noQNhAu8FnEwS5kjtBK1hGI2GEFBtLkIH49AUp c4KrMmotDmbCeHvOhNCqBLZ5JM6DACfO/elHpb2hgBENTd6zyp7mz/7MUf52s9Lb x5pRRCp1iLDw3s15iodZ5GL8pRT62puJVK1do9mPfMoL22woR3YB2++AkSdAgEFH 1XLIsFGkBsEJObbDBoEMEjEIivnTRPiyocyWki6gfLh50u9Y9B2GRzLAzIlgNiEs L/vyyrHcwOs4up9QqhAlvMn3Al01VF+OH0omQECSchBdsc/R/Bc35FAEVdmTAgMB AAEwDQYJKoZIhvcNAQEFBQADggEBAAyYcvJtEhOq+n87wukjPMgC7l9n7rgvaTmo tzpQhtt6kFoSBO7p//76DNzXRXhBDADwpUGG9S4tgHChAFu9DpHFzvnjNGGw83ht qcJ6JYgB2M3lOQAssgW4fU6VD2bfQbGRWKy9G1rPYGVsmKQ59Xeuvf/cWvplkwW2 bKnZmAbWEfE1cEOqt+5m20qGPcf45B7DPp2J+wVdDD7N8198Jj5HJBJt3T3aUEwj kvnPx1PtFM9YORKXFX2InF3UOdMs0zJUkhBZT9cJ0gASi1w0vEnx850secu1CPLF WB9G7R5qHWOXlkbAVPuFN0lTav+yrr8RgTawAcsV9LhkTTOUcqI= -----END CERTIFICATE-----</chain></certificate_chain>

2. すべてのノードで openssl を使用して、証明書を確認することもできます。

openssl s_client -showcerts -connect <node_ip>:<port>

管理ポートは 4443 です。

次に例を挙げます。

openssl s_client -showcerts -connect 10.1.2.3:4443

オブジェクト証明書の検証ECS管理 REST API を使用して、インストールされているオブジェクト証明書を取得することができます。はじめにl ECS管理 REST API を使用して認証済みであることと、変数（$TOKEN）にトークンを格納

済みであることを確認します。ECS Management REST API による認証（136 ページ）を参照。

l サービスを再起動した場合、すぐに証明書を利用できます。そうでない場合は、証明書がすべてのノードに反映されることを確認するのに、2時間待つ必要があります。

手順1. 証明書を返すには、GET /object-cert/keystore メソッドを使用します。

curl ツールを使用すると、メソッドは次のように入力して実行できます。

curl -svk -H "X-SDS-AUTH-TOKEN: $TOKEN" https://x.x.x.x:4443/object-cert/keystore

証明書



python ecscli.py keystore show –hostname <ecs_host_ip> -port 4443 –cf <cookiefile>

2. すべてのノードで openssl を使用して、証明書を確認することもできます。

openssl s_client -showcerts -connect <node_ip>:<port>

ポートは次のようになります。s3: 9021、Atmos: 9023、Swift: 9025

例：

openssl s_client -showcerts -connect 10.1.2.3:9021

証明書

オブジェクト証明書の検証 141

証明書


第 10章

ECS設定

l ECS設定の概要................................................................................................ 144l オブジェクトベース URL........................................................................................ 144l パスワードの変更................................................................................................. 148l ESRS（EMC セキュアリモートサービス）.............................................................. 149l イベント通知サーバ.............................................................................................. 150l プラットフォームのロック...........................................................................................162l ライセンス............................................................................................................164l この VDC について............................................................................................... 165

ECS設定 143

ECS設定の概要このセクションでは、システム管理者が ECS Portal の［Settings］セクションで表示し、構成できる設定について説明します。これらの設定を含めます。l オブジェクトベース URL

l パスワードl ESRS

l イベント通知サーバl プラットフォームのロックl ライセンスl この VDC について

オブジェクトベース URLECS では、仮想ホスト形式とスキームをアドレス指定するパス形式を使用する、Amazon S3 と互換性のあるアプリケーションをサポートします。マルチテナント構成で、ECS ではネームスペースをURL で提供することができます。ベース URLは、オブジェクトアドレスの一部として使用されます。アドレス指定する仮想ホスト形式を使用して、ECS からアドレスのどの部分がバケットとネームスペース（オプション）を参照しているかを確認できます。たとえば、フォーム mybucket.mynamespace.mydomain.com のアドレスがあるネームスペースを含むアドレス指定のスキームを使用する場合、ECS に mydomain.com がベース URL であると教え、ECS が mybucket.mynamespace をバケットおよびネームスペースとして判別できるようにします。デフォルトでは、ベース URLは s3.amazonaws.com に設定されます。ECS システム管理者は、ECS Portal または ECS管理 REST API を使用して、ベース URL を追加できます。次のトピックで説明するのは、ECS によるアドレス指定スキーム、ECS が S3 アプリケーションからのAPI リクエストを処理する方法、アドレス指定のスキームが DNS解決にどのように影響するか、および ECS Portal のベース URL を追加する方法です。l バケットとネームスペースのアドレス指定（144 ページ）l DNS の構成（146 ページ）l ベース URL の追加（147 ページ）

バケットとネームスペースのアドレス指定S3互換アプリケーションが API リクエストを作成し、ECSバケットでの操作を実行すると、ECSはいくつかの方法でバケットを特定できます。認証 API リクエストの場合、ECS がメンバーである認証済みユーザーのネームスペースを使用して、ネームスペースを推測します。匿名で、CORS サポートまたはオブジェクトへの匿名アクセスを必要とする認証されていないリクエストをサポートするには、ECS がリクエストのネームスペースを特定できるように、アドレスにネームスペースを含める必要があります。

ECS設定


ユーザースコープが NAMESPACE である場合、同じユーザー ID が複数のネームスペースに存在できます（例：namespace1/user1 および namespace2/user1）。そのため、アドレスにネームスペースを含める必要があります。ECSは、ユーザー ID からネームスペースを推定できません。ネームスペースアドレスがワイルドカードの DNS エントリー（*.ecs1.yourco.comなど）、および HTTPS を使用する場合に一致するワイルドカード SSL証明書が必要です。非ネームスペースのアドレスとパス形式のアドレスは、ワイルドカードが不要です。全トラフィックに対するホスト名が 1 つのみであるためです。仮想ホスト形式のバケットを持つ非ネームスペースを使用する場合は、ワイルドカード DNS エントリーとワイルドカード SSL証明書が必要です。HTTP リクエストの x-emc-namespace ヘッダーで、ネームスペースを指定することができます。ECS も、ホストヘッダーからの場所の抽出をサポートします。

仮想ホスト形式のアドレス指定

仮想ホスト形式のアドレス指定スキームでは、バケット名がホスト名内にあります。たとえば、次のアドレスを使用して、ホスト ecs1.yourco.com上の mybucket という名前のバケットにアクセスすることができます。http://mybucket.ecs1.yourco.comアドレスにネームスペースを含めることもできます。例：mybucket.mynamespace.ecs1.yourco.com仮想ホスト形式のアドレス指定を使用するには、ECS が URL のどの部分がバケット名であるか識別できるように、ECS のベース URL を構成する必要があります。アドレスを解決するために、DNSシステムが構成されていることも確認する必要があります。DNS構成の詳細については、DNS の構成（146 ページ）を参照してください。

パス形式のアドレス指定

パス形式のアドレス指定スキームでは、パスの末尾にバケット名が追加されます。例：ecs1.yourco.com/mybucketx-emc-namespace ヘッダーの使用、またはパス形式のアドレスにネームスペースを含めることにより、ネームスペースを指定できます。例：mynamespace.ecs1.yourco.com/mybucket

ECS アドレスの処理

ECS が ECS ストレージにアクセスする S3互換のアプリケーションからのリクエストを処理すると、ECSは次のアクションを実行します。

1. x-emc-namespace ヘッダーからネームスペースの展開をします。名前空間が見つかった場合は、次のステップをスキップしてリクエストを処理します。

2. ホストヘッダーから URL のホスト名を抽出し、アドレスの最後の部分が、構成されたいずれかのベース URL と一致するかどうかを調べます。

3. 一致するベース URL が存在する場合は、ホスト名のプレフィックス部分（ベース URL を除去すると残る部分）を使用して、バケットの場所を特定します。

ECS が、受信する HTTP リクエストをいくつかの方法で処理する例を以下に示します。

ECS設定

バケットとネームスペースのアドレス指定 145

ECS にベース URL を追加すると、URL が ECS Portal の［New Base URL］ページの［Usebase URL with Namespace］フィールドのネームスペースを含めるかどうかを指定することができます。これは、ECS に、バケットの場所のプレフィックスの処理方法を指示しています。詳細については、ベース URL の追加（147 ページ）を参照してください。

例 1：仮想ホスト形式のアドレス指定では、ネームスペースを使用するベース URLの使用が有効になっています。

Host: baseball.image.yourco.finance.comBaseURL: finance.comUse BaseURL with namespace enabled

Namespace: yourcoBucket Name: baseball.image

例 2：仮想ホスト形式のアドレス指定では、ネームスペースを使用するベース URLの使用が無効になっています。

Host: baseball.image.yourco.finance.comBaseURL: finance.comUse BaseURL without namespace enabled

Namespace: null (Use other methods to determine namespace)Bucket Name: baseball.image.yourco

例 3：ECSでは、パス形式リクエストとして、このリクエストを処理します。

Host: baseball.image.yourco.finance.comBaseURL: not configured

Namespace: null (Use other methods to determine namespace.)Bucket Name: null (Use other methods to determine the bucket name.)

DNS の構成S3互換アプリケーションが ECS ストレージにアクセスする場合は、ECS データノードのアドレスまたはデータノードのロードバランサーのアドレスに URL が解決されることを確認する必要があります。アプリケーションで、パス形式のアドレス指定を使用する場合は、DNS システムがアドレスを解決できることを確認する必要があります。たとえば、アプリケーションが形式 ecs1.yourco.com/bucket でリクエストを発行する場合、ecs1.yourco.com を解決して、ECS ノードへのアクセスに使用されるロードバランサーの IP アドレスにする DNS エントリーが必要です。アプリケーションがAmazon S3 と通信するように構成されている場合は、URIは形式 s3-eu-west-1.amazonaws.com です。仮想ホスト形式のアドレス指定を使用するアプリケーションの場合は、URL にバケット名が含まれ、ネームスペースが含まれることもあります。このような状況下で、DNS エントリーのワイルドカードを使用して、仮想ホスト形式のアドレスを解決する DNS エントリーがある必要があります。これは、ネームスペースを URL に含めるパススタイルのアドレスを使用する場合にも当てはまります。

ECS設定


たとえば、アプリケーションが形式 mybucket.s3.yourco.com でリクエストを発行する場合、次の DNS エントリーがある必要があります。l ecs1.yourco.coml *.ecs1.yourco.comアプリケーションが mybucket.s3.amazonaws.com を使用して Amazon S3 サービスに接続されていた場合、次の DNS エントリーがある必要があります。l s3.amazonaws.coml *.s3.amazonaws.comサービスレベルのコマンド（バケットリストの表示など）の発行時に、これらのエントリーが仮想ホスト形式のバケットアドレスおよびベース名を解決します。ECS S3 サービスの SSL証明書を作成する場合は、証明書名にワイルドカードエントリーを使用し、ワイルドカードのないバージョンをサブジェクト代替名として使用します。

ベース URL の追加オブジェクトの場所、そのネームスペース（オプション）、URL内のバケットをエンコードするオブジェクトクライアントを使用する場合に、ベース URL を追加する必要があります。

はじめにこの操作には ECS のシステム管理者ロールが必要です。

URL を使用してオブジェクトの場所を指定するリクエストに指定されたドメインが、ECS データノードの場所を、またはデータノードの直前に配置されたロードバランサーの場所を解決できることを確認する必要があります。手順

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

［Base URL Management］ページには、ベース URL のリストが表示されます。［Usewith Namespace］プロパティは、URL がネームスペースを含めるかどうかを示します。

2. ［Base URL Management］ページで、［New Base URL］をクリックします。

ECS設定

ベース URL の追加 147

3. ［New Base URL］ページの［Name］フィールドに、ベース URL の名前を入力します。

［Base URL Management］ページのベース URL のリストで、このベース URL のラベルを示す名前です。

4. ［Base URL］フィールドに、ベース URL を入力します。

オブジェクト URL が形式 https://mybucket.mynamespace.acme.com（つまり、bucket.namespace.baseurl）または https://mybucket.acme.com（つまり、bucket.baseurl）の場合は、ベース URLは acme.com になります。

5. URL がネームスペースを含める場合、［Use base URL with Namespace］フィールドで、［Yes］をクリックします。


パスワードの変更ECS ポータルを使用して、パスワードを変更できます。

はじめにこの操作には、ECS でのシステム管理者ロール、ネームスペース管理者ロール、ロック管理者（emcsecurity）ロール、またはシステム監視者ロールが必要です。手順

1. ECS ポータルで、［Settings］ > ［Change Password］を選択します。2. ［Change Password］ページの［Password］フィールドに、新しいパスワードを入力し、［Confirm Password］フィールドに再入力します。


ECS設定


ESRS（EMC セキュアリモートサービス）ECS Portal を使用して、ESRS サーバを追加したり更新したりすることができます。ESRSは、情報インフラストラクチャの可用性を向上させることができるエラーのアラートなどの ECS イベントレポートへの、即時の安全なレスポンスを提供するよう設計されています。はじめにl 初期の ESRS のセットアップおよび構成を終了している必要があります。ECS で ESRS を構

成する最初のステップを実行するには、カスタマーサポート担当者担当者にお問い合わせください。

l すでに ESRS サーバーが有効になっている場合は、それを削除してから、新しいサーバーを追加する必要があります。

l この操作には ECS のシステム管理者のロールが必要です。手順

1. ECS Portal で、［Settings］ > ［ESRS］ > ［New Server］を選択します。2. ［New ESRS Server］ページで、次の手順に従います。

a.［FQDN/IP］フィールドに、ESRS Gateway の完全修飾ドメイン名または IP アドレスを入力します。

b.［PORT］フィールドに、ESRS Gateway のポート（デフォルトでは 9443）を入力します。

c.［Username］フィールドに、ECS サポートとのインターフェイスに使用するログインユーザー名を入力します。これは、support.emc.com へのログインに使用されるのと同じログインユーザー名です。

d.［Password］フィールドに、ログインユーザー名で設定したパスワードを入力します。3. ［Save］をクリックします。

サーバに接続するまで数分かかる場合があります。プロセスを監視するには、［Refresh］ボタンをクリックします。移行の状態には、［Processing］、［Connected］、［Failed］があります。

4. ESRS が高可用性のために複数のゲートウェイを構成する場合は、手順 1～3 を繰り返して、追加の ESRS Gateway サーバを追加します。

ESRS の構成の確認ESRS が設定され、正常にカスタマーサポートセンターに問い合わせることができることを確認します。テストアラートを生成し、その後アラートが受信されているかどうかをチェックして、ESRS が稼働しているかどうかをテストすることができます。手順

1. テストアラートを生成するには、次の手順を実行します。a. ECS管理 REST API による認証。たとえば、curl コマンドラインツールを使用して、次のコマンドを入力します。

curl -L --location-trusted -k https://192.0.2.49:4443/login -u "root:ChangeMe" -v

ECS設定

ESRS（EMC セキュアリモートサービス） 149

X-SDS-AUTH-TOKEN:を使用して ECS で認証し、ECS管理 REST API コマンドを実行します。

X-SDS-AUTH-TOKEN: BAAcaGtkTzRZU2k0SE5acVYxdFNCYUlUby9mOVM4PQMAjAQASHVybjpzdG9yYWdlb3M6VmlydHVhbERhdGFDZW50ZXJEYXRhOjMwOTFjMDY1LTgzMDAtNGNlNi1iNDY3LTU5NDFiM2MyYTBmZAIADTE0NzM3NzkxMzA4OTMDAC51cm46VG9rZW46M2Y4NTMzMzctN2ZiZi00NWRiLTk0M2YtY2NkYTc2OWQ0ZTc4AgAC0A8=

b. 認証トークン（X-SDS-AUTH-TOKEN）を環境変数で保存することができます。

export AUTH_TOKEN="X-SDS-AUTH-TOKEN: BAAcaGtkTzRZU2k0SE5acVYxdFNCYUlUby9mOVM4PQMAjAQASHVybjpzdG9yYWdlb3M6VmlydHVhbERhdGFDZW50ZXJEYXRhOjMwOTFjMDY1LTgzMDAtNGNlNi1iNDY3LTU5NDFiM2MyYTBmZAIADTE0NzM3NzkxMzA4OTMDAC51cm46VG9rZW46M2Y4NTMzMzctN2ZiZi00NWRiLTk0M2YtY2NkYTc2OWQ0ZTc4AgAC0A8="

c. テストアラートを生成します。

たとえば、$AUTH_TOKEN環境変数を使用して、次のコマンドを入力します。

user_strパラメータを使用すると、テストメッセージを指定することができ、contactパラメータを使用すると、メールアドレスを提供することができます。

curl -ks -H "$AUTH_TOKEN" -H "Content-Type: application/json" -d '{"user_str": "test alert > for ESRS", "contact": "[email protected]"}' https://10.241.207.57:4443/vdc/callhome/alert | xmllint -format -

2. ECS Portal で、ESRS通知を受信したことを確認します。3. 最新のテストアラートが存在するかを確認します。

a. ESRS サーバに SSH でログインします。b. RSC ファイルの場所に移動します。

cd /opt/connectemc/archive/

c. 最新の RSC ファイルをチェックします。

ls –lrt RSC_<SERIAL NUMBER>*”

d. ファイルを開き、最新のテストアラートが記述されているかどうか確認します。

イベント通知サーバECS に SNMPv2 サーバ、SNMPv3 サーバ、Syslog サーバを追加し、SNMP と Syslog イベント通知を外部システムにルートできます。ECS では、次のタイプのイベント通知のサーバを追加できます。

ECS設定


l SNMP エージェントとも呼ばれる SNMP（Simple Network Management Protocol）サーバは、ネットワーク管理デバイスのステータスと統計に関するデータを SNMP ネットワーク管理ステーションのクライアントに提供します。詳細については、「SNMP サーバ」を参照してください。

l Syslog サーバは、システムログメッセージの一元的な保存と取得に使用されます。ECSはリモート Syslog サーバへのアラートおよび監査メッセージの転送をサポートします。また、BSDSyslog と構造化 Syslog のアプリケーションプロトコルを使用した操作をサポートします。詳細については、「Syslog サーバ」を参照してください。

ECS Portal から、あるいは ECS管理 REST API API または CLI を使用して、イベント通知サーバを追加できます。l SNMP v2 トラップ受信者の追加（151 ページ）l SNMP v3 トラップ受信者の追加（153 ページ）l Syslog サーバの追加（158 ページ）

SNMP サーバSNMP エージェントとも呼ばれる SNMP（Simple Network Management Protocol）サーバは、ネットワーク管理デバイスのステータスと統計に関するデータを SNMP ネットワーク管理ステーションのクライアントに提供します。SNMP エージェントと SNMP ネットワーク管理ステーションクライアント間の通信を許可するには、同じ認証情報を使用するように両サイドを構成する必要があります。SNMPv2 を使用するには、両サイドが同じコミュニティ名を使用する必要があります。SNMPv3 を使用するには、両サイドが同じ Engine ID、ユーザー名、認証プロトコルと認証パスフレーズ、プライバシープロトコルとプライバシーパスフレーズを使用する必要があります。SNMP サーバと SNMP ネットワーク管理ステーションクライアント間のトラフィックを認証し、ホスト間でメッセージの整合性を検証するには、ECSは次の暗号形式ハッシュ関数を使用するSNMPv3標準をサポートします。l MD5（メッセージダイジェスト 5）l SHA-1（セキュアハッシュアルゴリズム 1）SNMPv3 サーバと SNMP ネットワーク管理ステーション間のすべてのトラフィックを暗号化する場合は、ECSは次の暗号形式プロトコルによる SNMPv3 トラフィックの暗号化をサポートします。l デジタル暗号化標準（56 ビットキーを使用）l 高度暗号化標準（128 ビット、192 ビット、256 ビットキーを使用）

ECS SNMP トラップ機能を使用した高度なセキュリティモード（AES192/256）のサポートは、特定の SNMP ターゲット（iReasoningなど）とは互換性がない場合があります。

SNMP v2 トラップ受信者の追加SNMP v2 の標準的なメッセージングを使用して、ECS ファブリックによって生成される SNMP トラップの SNMP v2 トラップ受信者としてネットワーク管理ステーションクライアントを構成することができます。はじめにこの操作には ECS のシステム管理者のロールが必要です。手順

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

ECS設定

SNMP サーバ 151

［Event Notification］ページが表示され、［SNMP］タブを開きます。このページでは、ECS に追加されている SNMP サーバを一覧表示し、SNMP サーバのターゲットを構成することができます。

2. ［Event Notification］ページで、［New Target］をクリックします。

［New SNMP Target］サブページが表示されます。

3. ［New SNMP Target］サブページで、次の手順を実行します。

ECS設定


a.［FQDN/IP］フィールドに、snmptrapd サーバを実行する SNMP v2c トラップ受信者ノードの完全修飾ドメイン名または IP アドレスを入力します。

b.［Port］フィールドに、ネットワーク管理ステーションクライアントで実行される SNMPv2csnmptrapd のポート番号を入力します。デフォルトのポート番号は 162 です。

c.［Version］フィールドで、［SNMPv2］を選択します。d.［Community Name］フィールドに、SNMP コミュニティ名を入力します。

RFC 1157 および RFC 3584 の基準によって定義されているように、SNMP サーバとそれにアクセスするすべてのネットワーク管理ステーションクライアントの両方が、信頼性の高い SNMP メッセージのトラフィックを確保するために、同じコミュニティ名を使用する必要があります。

デフォルトのコミュニティ名は public です。


SNMP v3 トラップ受信者の追加SNMP v3 の標準的なメッセージングを使用して、ECS ファブリックによって生成される SNMP トラップの SNMP v3 トラップ受信者としてネットワーク管理ステーションクライアントを構成することができます。はじめにこの操作には ECS のシステム管理者のロールが必要です。手順

1. ECS ポータルで、［Settings］ > ［Event Notification］を選択します。2. ［Event Notification］ページで、［New Target］をクリックします

ECS設定

SNMP サーバ 153

3. ［New SNMP Target］サブページで、次の手順を実行します。a.［FQDN/IP］フィールドに、snmptrapd サーバを実行する SNMP v3 トラップ受信者ノードの完全修飾ドメイン名または IP アドレスを入力します。

b.［Port］フィールドに、ネットワーク管理ステーションクライアントで実行される SNMPv3snmptrapd のポート番号を入力します。デフォルトのポート番号は 162 です。

c.［Version］フィールドで、［SNMPv3］を選択します。d.［Username］フィールドに、RFC 3414 によって定義される USM（ユーザーベースのセキュリティモデル）のような認証とメッセージのトラフィックで使用されるユーザー名を入力します。通信を確保するためには、SNMP サーバとそれにアクセスするすべてのネットワーク管理ステーションクライアントの両方は、同じユーザー名を指定する必要があります。これは、最大 32文字のオクテット文字列です。

e.［Authentication］ボックスで、［Enabled］をクリックして、すべての SNMPv3 のデータ転送でMD5（メッセージダイジェスト 5）（128 ビット）または SHA-1（セキュアハッシュアルゴリズム 1）認証を有効にし、次の操作を実行します。l ［Authentication Protocol］フィールドで、［MD5］または［SHA］を選択します。

ECS設定


これは、ホスト間でメッセージの正確さを検証するために使用する暗号形式ハッシュ関数です。デフォルトは［MD5］です。

l ［Authentication Passphrase］フィールドに、メッセージダイジェストの計算時に、SNMP v3 USM標準のホスト間の認証用のシークレットキーとして使用する文字列を入力します。パスフレーズの長さは、MD5 では 16 オクテット、SHA-1 では 20 オクテットにすることができます。

f.［Privacy］ボックスで、［Enabled］をクリックして、すべての SNMPv3 のデータ転送でDES（デジタル暗号化標準）（56 ビット）または AES（高度暗号化標準）（128 ビット、192 ビット、256 ビット）の暗号化を有効にする場合、次の操作を実行します。l ［Privacy Protocol］フィールドで、［DES］、［AES128］、［AES192］、［AES256］のいずれかを選択します。これは、SNMP サーバと SNMP ネットワーク管理ステーションクライアント間のすべてのトラフィックを暗号化する場合に使用する暗号化プロトコルです。デフォルト値は［DES］です。

l ［Privacy Passphrase］フィールドで、SNMP v3 USM の標準的なホスト間での暗号化用シークレットキーとして暗号化アルゴリズムで使用する文字列を入力します。このキーの長さは、DES では 16 オクテット、AES プロトコルではそれより長くする必要があります。


結果最初の SNMP v3構成を作成する際に、ECS システムは、SNMP v3 トラフィックに使用するSNMP エンジン ID を作成します。［Event Notification］ページの［Engine ID］フィールドに、その SNMP エンジン ID が表示されます。または、ネットワークモニタリングツールからエンジン ID を取得して、そのエンジン ID を［Engine ID］フィールドに指定することもできます。重要なことは、SNMP サーバと、SNMP v3 トラフィックを使用して SNMP サーバと通信する必要がある SNMPネットワーク管理ステーションクライアントは、そのトラフィックで同じ SNMP エンジン ID を使用する必要があるということです。

ECS での SNMP データコレクション、クエリー、MIB のサポート

ECSは、次のようにして SNMP（Simple Network Management Protocol）データコレクション、クエリー、MIB をサポートします。l ECS インストール処理中に、カスタマーサポート担当者の担当者は snmpd サーバを構成し

て起動し、ECS ノードレベルのメトリックの特別監視をサポートすることができます。ネットワーク管理ステーションクライアントは、これらのカーネルレベルの snmpd サーバをクエリーして、標準MIB で定義されているように、メモリおよび CPU の使用状況に関する情報を ECS ノードから収集することができます。ECS が SNMP クエリーをサポートするMIB のリストについては、ECSでのクエリーのためにサポートされた SNMP管理情報ベース（156 ページ）を参照してください。

l ECS ファブリックのライフサイクルレイヤーには、SNMP サーバとして機能する snmp4j ライブラリが含まれます。これは、SNMPv2 トラップおよび SNMPv3 トラップを生成して、10個のSNMP トラップ受信ネットワーク管理ステーションクライアントに送信します。ECS が SNMP トラップとしてサポートするMIB の詳細については、ECS-MIB SNMP オブジェクト ID の階層と管理情報ベースの定義（156 ページ）を参照してください。ECS Portal の［EventNotNotification］ページを使用して、SNMP トラップ受信サーバを追加できます。詳細につ

ECS設定

SNMP サーバ 155

いては、「 SNMP v2 トラップ受信者の追加（151 ページ）」および「 SNMP v3 トラップ受信者の追加（153 ページ）」を参照してください。

ECSでのクエリーのためにサポートされた SNMP管理情報ベース次の SNMP MIB のネットワーク管理ステーションのクライアントから各 ECS ノードで起動できる、snmpd サーバでクエリーを実行できます。l MIB-2

l DISMAN-EVENT-MIB

l HOST-RESOURCES-MIB

l UCD-SNMP-MIB

SNMP管理ステーションもしくは同等のソフトウェアを使用して、ECS ノードで次の基本的な情報をクエリーすることができます。l CPU使用率l メモリ使用量l 実行中のプロセス数

ECS-MIB SNMP オブジェクト IDの階層と管理情報ベースの定義このトピックでは、SNMP OID ヒエラルキーと、ECS-MIB として知られるエンタープライズMIB の完全な SNMP MIB-II の定義について説明します。

ECS-MIB という名の SNMP エンタープライズMIBは、オブジェクトtrapAlarmNotification、notifyTimestamp、notifySeverity、notifyType、notifyDescription を定義します。SNMP エンタープライズでは、ECS アプライアンスハードウェアの管理に関連する SNMP トラップがサポートされます。ECSは、snmp4jJava ライブラリで提供されるサービスを使用して、ファブリックライフサイクルコンテナからトラップを送信します。ECS-MIB内のオブジェクトには、次の階層があります。

emc.............................1.3.6.1.4.1.1139 ecs.........................1.3.6.1.4.1.1139.102 trapAlarmNotification...1.3.6.1.4.1.1139.102.1.1 notifyTimestamp.....1.3.6.1.4.1.1139.102.0.1.1 notifySeverity......1.3.6.1.4.1.1139.102.0.1.2 notifyType..........1.3.6.1.4.1.1139.102.0.1.3 notifyDescription...1.3.6.1.4.1.1139.102.0.1.4

アドオンの［Downloads］セクションの［Support Site］から、ECS-MIB定義を（ファイル ECS-MIB-v2.mib として）ダウンロードすることができます。次のMIB構文では、ECS-MIB という名のSNMP エンタープライズMIB を定義します。

ECS-MIB DEFINITIONS ::= BEGIN IMPORTS enterprises, Counter32, OBJECT-TYPE, MODULE-IDENTITY, NOTIFICATION-TYPE FROM SNMPv2-SMI; ecs MODULE-IDENTITY LAST-UPDATED "201605161234Z" ORGANIZATION "EMC ECS" CONTACT-INFO "EMC Corporation 176 South Street Hopkinton, MA 01748" DESCRIPTION "The EMC ECS Manager MIB module" ::= { emc 102 } emc OBJECT IDENTIFIER ::= { enterprises 1139 }

ECS設定


-- Top level groups notificationData OBJECT IDENTIFIER ::= { ecs 0 } notificationTrap OBJECT IDENTIFIER ::= { ecs 1 } -- The notificationData group -- The members of this group are the OIDs for VarBinds -- that contain notification data. genericNotify OBJECT IDENTIFIER ::= { notificationData 1 } notifyTimestamp OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-only STATUS current DESCRIPTION "The timestamp of the notification" ::= { genericNotify 1 } notifySeverity OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-only STATUS current DESCRIPTION "The severity level of the event" ::= { genericNotify 2 } notifyType OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-only STATUS current DESCRIPTION "A type of the event" ::= { genericNotify 3 } notifyDescription OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-only STATUS current DESCRIPTION "A complete description of the event" ::= { genericNotify 4 } -- The SNMP trap -- The definition of these objects mimics the SNMPv2 convention for -- sending traps. The enterprise OID gets appended with a 0 -- and then with the specific trap code. trapAlarmNotification NOTIFICATION-TYPE OBJECTS { notifyTimestamp, notifySeverity, notifyType, notifyDescription, } STATUS current DESCRIPTION "This trap identifies a problem on the ECS. The description can be used to describe the nature of the change" ::= { notificationTrap 1 }END

ECS Portal の［Monitor］ > ［Events］ > ［Alerts］ページに、次のフォーマット Disk{diskSerialNumber} on node {fqdn} has failed で送信される DiskFailure アラートの応答として作成されるトラップメッセージ。

2016-08-12 01:33:22 lviprbig248141.lss.emc.com [UDP: [10.249.248.141]:39116->[10.249.238.216]]:iso.3.6.1.6.3.18.1.3.0 = IpAddress: 10.249.238.216 iso.3.6.1.6.3.1.1.4.1.0 = OID: iso.

ECS設定

SNMP サーバ 157

3.6.1.4.1.1139.102.1.1 iso.3.6.1.4.1.1139.102.0.1.1 = STRING: "Fri Aug 12 13:48:03 GMT 2016" iso.3.6.1.4.1.1139.102.0.1.2 = STRING: "Critical" iso.3.6.1.4.1.1139.102.0.1.3 = STRING: "2002" iso.3.6.1.4.1.1139.102.0.1.4 = STRING: "Disk 1EGAGMRB on node provo-mustard.ecs.lab.emc.com has failed"

ECS Portal の［Monitor］ > ［Events］ > ［Alerts］ページに、次のフォーマット Disk{diskSerialNumber} on node {fqdn} was revived で送信される DiskBack Up アラートの応答として作成されるトラップメッセージ。

2016-08-12 04:08:42 lviprbig249231.lss.emc.com [UDP: [10.249.249.231]:52469->[10.249.238.216]]:iso.3.6.1.6.3.18.1.3.0 = IpAddress: 10.249.238.216 iso.3.6.1.6.3.1.1.4.1.0 = OID: iso.3.6.1.4.1.1139.102.1.1 iso.3.6.1.4.1.1139.102.0.1.1 = STRING: "Fri Aug 12 16:23:23 GMT 2016" iso.3.6.1.4.1.1139.102.0.1.2 = STRING: "Info" iso.3.6.1.4.1.1139.102.0.1.3 = STRING: "2025" iso.3.6.1.4.1.1139.102.0.1.4 = STRING: "Disk 1EV1H2WB on node provo-copper.ecs.lab.emc.com was revived"

Syslog サーバSyslog サーバは、システムログメッセージの一元的な保存と取得に使用されます。ECSはリモートSyslog サーバへのアラートおよび監査メッセージの転送をサポートします。また、次のアプリケーションプロトコルを使用した操作をサポートします。l BSD Syslog

l 構造化 Syslog

Syslog サーバに送信されるアラートと監査メッセージは、OS レベルの Syslog メッセージ（ノードSSH ログインメッセージなど）を除いて、ECS Portal にも表示されます。OS レベルの Syslog メッセージは、Syslog サーバを介してのみ送信され、ECS Portal には表示されません。Syslog サーバを追加すると、ECSは各ノード上の Syslog コンテナを開始します。メッセージトラフィックは、TCP またはデフォルト UDP のいずれかを介して実行されます。ECSは、次の形式を使用して、重大度レベルを含む監査ログメッセージを Syslog サーバに送信します。${serviceType} ${eventType} ${namespace} ${userId} ${message}ECSは、次の形式を使用して、ECS Portal に表示されるとおり、同じ重大度を使用したアラートログを Syslog サーバに送信します。${alertType} ${symptomCode} ${namespace} ${message}ECSは、次の形式を使用して、ファブリックのアラートを送信します。Fabric {symptomCode} "{description}"ECS 3.1以降では、ECSは次の OS ログのみを Syslog サーバに転送します。l 外部の SSH メッセージl Info レベル以上の重大度のすべての sudo メッセージl セキュリティ関連のメッセージと認証関連のメッセージである、Warning レベル以上の重大度の

認証ファシリティからのすべてのメッセージ

Syslog サーバの追加Syslog サーバを構成して、ECS ログメッセージをリモートから記録することができます。

ECS設定


はじめにl この操作には ECS のシステム管理者のロールが必要です。手順

1. ECS ポータルで、［Settings］ > ［Event Notification］を選択します。2. ［Event Notification］ページで、［Syslog］をクリックします。

このページでは、ECS に追加されている Syslog サーバを一覧表示し、新しい Syslog サーバを構成することができます。

3. ［Event Notification］ページで、［New Server］をクリックします。［New Syslog Server］サブページが表示されます。

ECS設定

Syslog サーバ 159

4. ［New Syslog Server］サブページで、次の手順を実行します。a.［Protocol］フィールドで［UDP］または［TCP］を選択します。

UDP がデフォルトのプロトコルです。

b.［FQDN/IP］フィールドに、Syslog サーバを実行するノードの完全修飾ドメイン名またはIP アドレスを入力します。

c.［Port］フィールドに、ログメッセージを格納する Syslog サーバのポート番号を入力します。デフォルトのポート番号は 514 です。

d.［Severity］フィールドで、ログに送信するメッセージの閾値の重大度を選択します。ドロップダウンオプションには、［Emergency］、［Alert］、［Critical］、［Error］、［Warning］、［Notice］、［Informational］、［Debug］があります。


Syslog メッセージのサーバ側でのフィルタリングこのトピックでは、ECS の Syslog メッセージがサーバ側の構成でさらにフィルタリングされる方法について説明します。ECS Portal で（または ECS管理 REST API を使用して）Syslog サーバを構成するには、サーバに送信されるメッセージを指定します。サーバ側のフィルタリング技術を使用して、ログに保存されているメッセージの数を削減できます。フィルタリングは、ファシリティレベルで実行されます。ファシリティは、メッセージをタイプ別に分割します。ECSは、次の表に示すように、ファシリティへのメッセージを管理します。

表 20 ECS によって使用される Syslog ファシリティ

Facility キーワード定義された使用法 ECS を使用

1 user ユーザーレベルのメッセージファブリックのアラート

3 daemon システムデーモン OS メッセージ

4 auth セキュリティ/認証メッセージ ssh と sudo の成功/失敗メッセージ

16 local0 ローカル使用なしオブジェクトのアラート、オブジェクトの監査

すべてのファシリティ *

次の形式を使用して、各ファシリティに重大度レベルごとにフィルタリングできます。facility-keyword.severity-keyword重大度のキーワードは、次の表に記載されています。

表 21 Syslog の重大度のキーワード

重大度レベルの数重大度レベルキーワード

0 Emergency emerg

1 Alert alert

2 Critical crit

ECS設定


表 21 Syslog の重大度のキーワード（続き）

重大度レベルの数重大度レベルキーワード

3 Error err

4 Warning warn

5 Notice notice

6 Informational info

7 Debug debug

すべての重大度すべての重大度 *

/etc/rsyslog.conf ファイルを使用して、Syslog サーバの構成を変更します。Syslog サーバ上の/etc/rsyslog.conf ファイルを編集することにより、既存の構成を変更することができます。手順

1. 次の方法で/etc/rsyslog.conf ファイルを構成します。a. すべての機能とすべての重大度レベルから送信される ECS メッセージを受信するには、この構成を使用してを完全なパスとターゲットのログファイル名を次のように指定します。

*.* /var/log/ecs-messages.all

b. すべてのファブリックのアラート、オブジェクトのアラート、オブジェクトの監査を受信するには、フルパスとターゲットのログファイル名でこの構成を使用します。

user.*,local0.* /var/log/ecs-fabric-object.all

c. すべてのファブリックのアラート、オブジェクトのアラート、オブジェクトの監査を受信し、警告以上の重要度である認証機能のメッセージを制限するには、フルパスとターゲットのログファイル名でこの構成を使用します。

user.*,local0.*/var/log/ecs-fabric-object.allauth.warn /var/log/ecs-auth-messages.warn

d. ファシリティへのトラフィックを複数のファイルにセグメント化する、ログファイルは次のとおりです。

auth.info /var/log/ecs-auth-info.logauth.warn /var/log/ecs-auth-warn.logauth.err /var/log/ecs-auth-error.log

2. 構成ファイルの変更後に、Syslog サーバで Syslog サービスを再起動します。

# service syslog restart

ECS設定

Syslog サーバ 161

出力：

Shutting down syslog services doneStarting syslog services done

プラットフォームのロックノードへのリモートアクセスをロックするには、ECS Portal を使用します。

ECS には、管理者ロールを割り当てられた管理ユーザーが、ECS Portal または ECS管理 RESTAPI を介してアクセスできます。ECS には、権限のあるデフォルトノードのユーザー（最初に ECS をインストールしたときに作成された admin）が、ノードレベルでのアクセスもできます。このデフォルトノードのユーザーは、ノード上のサービス処理手順を実行し、次にアクセスできます。l 管理スイッチを介してサービスノートパソコンをノードに直接接続して SSH を使用するか、また

は CLI でノードのオペレーティングシステムに直接アクセスします。l ネットワーク経由でリモートにノードに接続するには SSH を使用し、ノードのオペレーティングシ

ステムに直接アクセスするには CLI を使用します。デフォルト admin ノードレベルのユーザーの詳細については、ECS製品ドキュメントページ内の使用可能な「ECS セキュリティガイド」を参照してください。ノードロックは、リモートノードアクセスに対するセキュリティレイヤーになります。ノードをロックしないと、admin ノードレベルのユーザーがいつでもノードにリモートアクセスして、データの収集、ハードウェアの構成、Linux コマンドの実行を行うことができます。クラスタ内のすべてのノードをロックすると、指定ウィンドウに対するリモートアクセスを計画的にスケジュール設定できるため、不正なアクティビティの機会を最小限に抑えることができます。ECS Portal または ECS Management API で、クラスタ内の選択したノードまたはクラスタ内のすべてのノードをロックできます。ロックすると、ロックされたノードに（SSH により）リモートアクセスする機能にのみ影響があります。ロックにより、ECS Portal および ECS Management API からの、ノードへのアクセス方法が変わることはありません。また管理スイッチを経由してノードに直接接続する機能にも影響はありません。メンテナンスリモートアクセスを使用してノードの保守を行う場合は、1 つのノードをロック解除して、admin アカウントによるクラスタ全体への SSH を使用したリモートアクセスができるようにします。admin ユーザーはロック解除されたノードに SSH を使用して正常にログインし、adminはそのノードからクラスタ内の他の任意のノードにプライベートネットワークを経由して SSH接続します。ノードをロック解除し、OS レベルの読み取り専用の診断をするコマンドをリモートで使用できます。

監査ノードロックおよびロック解除のイベントは監査ログと Syslog に表示されます。ノードのロックまたはロック解除の失敗もログに表示されます。

ECS管理 REST API を使用して、ノードをロックし、ロック解除します。次の API を使用して、ノードロックの管理を行います。

ECS設定



表 22 ECS管理 REST API がノードのロックを管理します。

リソース説明

GET /vdc/nodes 現在クラスタに構成されているデータノードを取得します。

GET /vdc/lockdown VDC のロック/ロック解除ステータスを取得します。

PUT /vdc/lockdown VDC のロック/ロック解除ステータスを設定します。

PUT /vdc/nodes/{nodeName}/lockdown ノードのロック/ロック解除ステータスを設定します。

GET /vdc/nodes/{nodeName}/lockdown ノードのロック/ロック解除ステータスを取得します。

ECS Portal を使用したノードのロックおよびロック解除ECS ノードへのリモート SSH アクセスをロックおよびロック解除するには、ECS Portal を使用します。はじめにこの操作には、ECS の emcsecurity ユーザーに割り当てられたロック管理者ロールが必要です。ロックすると、ロックされたノードに（SSH により）リモートアクセスする機能にのみ影響があります。ロックにより、ECS Portal および ECS Management API からの、ノードへのアクセス方法が変わることはありません。また管理スイッチを経由してノードに直接接続する機能にも影響はありません。手順

1. emcsecurity ユーザーとしてログインします。このユーザーの最初のログイン時には、パスワードを変更し、再度ログインするように求められます。

2. ECS Portal で、［Settings］ > ［Platform Locking］を選択します。

画面に、クラスタ内のノードが一覧表示され、ロックのステータスが表示されます。

ノードには、次のような状態があります。l ロック解除: オープンで緑色のロックアイコンと［Lock］アクションボタンが表示されます。l ロック：閉じた赤いロックアイコンと［Unlock］アクションボタンが表示されます。l オフライン：円にスラッシュがあるアイコンを表示します。ノードが到達不能でロック状態を判断できないため、アクションボタンは表示されません。

ECS設定

ECS Portal を使用したノードのロックおよびロック解除 163

3. 次のいずれかの手順を実行します。a. ロックするノードの隣の［Actions］列で［Lock］をクリックします。

SSH または CLI によりリモートでログインしているすべてのユーザーは、そのセッションを終了するまでに約 5分の時間があります。ユーザーの端末画面にシャットダウン直前のメッセージが表示されます。

b. ロックを解除するノードの隣の［Actions］列で［Unlock］をクリックします。admin デフォルトノードユーザーは、数分後にリモートでノードにログインできます。

c. VDC内のロックされていないオンラインのすべてのノードをロックする場合、［Lock theVDC］をクリックします。この機能は、新しいまたはオフラインの任意のノードが一度検出されると自動的にロックされる状態には設定しません。

ライセンスEMC ECS のライセンスは容量に基づいています。少なくとも 1 つの ECS ライセンスを取得して、アプライアンスにアップロードする必要があります。各アプライアンス（ラック）に、ライセンスがあります。

EMC ECS ライセンスファイルの取得EMC ライセンス管理Web サイトからライセンスファイル（.lic）を取得できます。

はじめにライセンスファイルを取得するには、EMC からメールで送信された LAC（ライセンス認証コード）が必要です。LAC が届かない場合には、カスタマーサポート担当者にお問い合わせください。手順

1. ライセンスページ https://support.emc.com/servicecenter/license/にアクセスします。

2. 製品のリストから［ECSAppliance］を選択します。3. LAC リクエストページで、LAC コードを入力し、［Activate］をクリックします。4. 有効にする利用資格を選択し、［Start Activation Process］をクリックします。5. ［Add a Machine］を選択して、ライセンスのグループ化のために意味のある文字列を指定

します。マシンの名前で、ライセンスのトラッキングを保持するのに役立つすべての文字列を入力します。（実際のマシン名である必要はありません。）

6. エンタイトルメントごとに数量を入力するか、［Activate All］を選択して、［Next］をクリックします。地理的に連携しているシステムの複数のサイトで、必要に応じてコントローラを配布し、VDC（仮想データセンター）ごとに個別のライセンスファイルを取得します。

7. オプションとして、アクティブ化トランザクションのサマリーをメールで受信するための宛先を指定します。

8. ［Finish］をクリックします。9. ［Save to File］をクリックして、コンピューター上のフォルダーにライセンスファイル（.lic）を

保存します。

ECS設定


このライセンスファイルは、ECS の初期セットアップ中、または ECS ポータルで新しいライセンスを後から追加するときに必要です。

ECS ライセンスファイルのアップロードECS ライセンスファイルは ECS Portal からアップロードできます。

はじめにl この操作には ECS のシステム管理者のロールが必要です。l 有効なライセンスファイルがあることを確認します。「EMC ECS ライセンスファイルの取得（164

ページ）」で説明されている手順に従えば、ライセンスを取得することができます。地理的に連携しているシステムで複数のサイトをインストールする場合、サイト間でのライセンス体系を同じにする必要があります。既存のクラスタに暗号化が有効なライセンスがある場合、追加された新しいサイトには、同じライセンスが必要です。同様に、既存のサイトに暗号化が有効なライセンスがない場合は、クラスタに追加される新しいサイトは、同じモデルに従う必要があります。手順

1. ECS Portal で、［Settings］ > ［Licensing］を選択します。2. ［Licensing］ページの［Upload a New License File］フィールドで［Browse］をクリ

ックして、ライセンスファイルのローカルコピーに移動します。3. ［Upload］ボタンをクリックしてライセンスを追加します。

追加されたライセンスがライセンスリストに表示されます。

この VDC についてVDC内の現在のノードまたは他のノードのソフトウェアのバージョン番号に関する情報を［Aboutthis VDC］ページで表示できます。

［About］タブでは、現在接続中のノードに関連する情報を提供します。VDC で使用可能なノードの名前、IP アドレス、ラック ID、ソフトウェアバージョンを［ノード］タブで表示できます。［Nodes］タブでは、現在接続中のノードとはソフトウェアバージョンが異なるノードもすべて特定できます。

手順1. ECS ポータルで、［Settings］ > ［About this VDC］を選択します。

［About this VDC］ページが表示され、［About］タグが表示されます。このページでは、現在のノードの ECS ソフトウェアのバージョンと ECS オブジェクトサービスのバージョンに関する情報を表示します。

2. ［About this VDC］ページでは、［Nodes］タブをクリックして、クラスタ内のアクセス可能なノードのソフトウェアバージョンを表示します。

ECS設定

ECS ライセンスファイルのアップロード 165

青いチェックマークは、現在のノードを示します。星は、さまざまなソフトウェアバージョンがあるノードを示します。

ECS設定


第 11章

ECS の停止とリカバリ

l ECS サイトの停止と復旧の概要............................................................................168l TSO動作.......................................................................................................... 168l PSO動作.......................................................................................................... 176l ディスクおよびノード障害のリカバリ........................................................................... 177l 新しいノード追加後のデータの再バランシング............................................................178

ECS の停止とリカバリ 167

ECS サイトの停止と復旧の概要ECSは、災害やその他の問題（サイトがオフラインになったり、地理的に連携した環境で他のサイトとの接続が切断されたりすること）が原因のサイトの障害に対する保護を提供するよう設計されています。サイトの停止は、TSO（一時的なサイト停止）や PSO（永続的なサイト停止）として分類されます。TSOは、2 つのサイトの間のWAN接続の障害、またはサイト全体の一時的な障害（例：電源障害）です。TSO後、サイトをオンラインに復旧できます。ECSは、この種の一時的なサイトの障害を検出し、自動的に処理することができます。PSOは、災害が発生した場合など、サイト全体が完全にリカバリ不能になったときです。この例では、システム管理者は VDC の削除とサイトのフェールオーバー（36 ページ）の説明に従って、連携から恒久的にフェールオーバーを起動し、フェールオーバー処理を開始する必要があります。TSO と PSO の動作については、以下のトピックで説明します。l TSO動作（168 ページ）l TSO に関する考慮事項（176 ページ）l TSO中の NFS ファイルシステムのアクセス（176 ページ）l PSO動作（176 ページ）

TSO と PSO の行動の詳細については、「Elastic Cloud Storage High Availability Design」ホワイトペーパーを参照してください。

ECS のリカバリとデータ分散の動作については、これらのトピックで説明します。l ディスクおよびノード障害のリカバリ（177 ページ）l 新しいノード追加後のデータの再バランシング（178 ページ）

TSO動作ジオレプリケーション環境の VDC には、ハートビートメカニズムがあります。構成可能な時間（デフォルトで 15分）にハートビートの失敗が継続すると、ネットワークまたはサイトの停止と、TSO を識別するシステムの移行を示します。ECSは到達不可能なサイトを TSO として示し、サイトの状態を ECS Portal の［ReplicationGroup Management］ページに Temporarily unavailable として表示します。TSO中に ECS システムがどのように動作するかを決定する 2 つの重要な概念があります。l ［Owner］：バケットまたはオブジェクトをサイト A のネームスペース内に作成する場合は、サイト

A がそのバケットやオブジェクトのオーナーです。TSO が発生すると、読み取り/書き込み要求の動作は、バケットまたはオブジェクトを所有するサイトからのリクエストか、オブジェクトのプライマリコピーを持たないオーナー以外のサイトからかによって異なります。

l ［ADO（Access During Outage）バケットプロパティ］：バケットと、TSO中のバケット内のオブジェクトへのアクセスは、バケットで ADO プロパティが有効化されたかどうかによって異なります。ADO プロパティをバケットレベルで設定できます。つまり、このオプションをいくつかのバケットで有効化し、その他のバケットでは有効化しないことができます。n バケットで ADO プロパティが無効化されている場合は、TSO中に強力な整合性を維持するために、アクセスできるサイトが所有するデータにアクセスし、障害が発生したサイトが所有するデータにアクセスさせないことを継続します。



n ADO プロパティがバケットで有効化されている場合は、すべてのジオレプリケーションされたデータへの読み取りおよびオプションでの書き込みアクセスは、障害が発生したサイトで所有しているデータを含め、可能です。TSO中に、ADO が有効化されたバケット内のデータを一時的に、最終的な整合性に切り替えます。つまり、すべてのサイトをオンラインに戻すと、強力な整合性に復元します。

詳細については、以下のトピックを参照してください。l 無効化された ADOバケットのプロパティを使用した TSO の動作（169 ページ）l 有効化された ADOバケットプロパティを使用した TSO動作（170 ページ）

無効化された ADOバケットのプロパティを使用した TSO の動作停止中のアクセス（ADO）のプロパティがバケットに設定されていない場合、使用可能なサイトによって所有されているならば、TSO中にはバケットのデータへのアクセスのみできます。障害が発生したサイトが所有するバケットのデータには、アクセスできません。次の図に示すように、ECS システムの例では、サイト A が TSO として示され、使用できません。サイト Aは、バケット（および内部のオブジェクト）が作成された場所であることから、バケット 1 のオーナーです。バケット 1 が作成された時点で、ADO プロパティが無効化されています。サイト A に接続するアプリケーションによって行われた、そのバケット内のオブジェクトの読み取り/書き込み要求は失敗します。アプリケーションは、オーナーでないサイト（サイト B）のそのバケット内のオブジェクトにアクセスしようとする際に、読み取り/書き込み要求も失敗します。サイトがシステムによって TSO と正式に示される以前に作成されたリクエストの場合（ハートビートが継続的に消失した後に発生します。デフォルトで 15分に設定されています）でも、シナリオは同じです。つまり、読み取り/書き込み要求が電源停止の 15分以内にサイト B に接続するアプリケーションから実行された場合も、リクエストが失敗します。図 22 オーナー以外のサイトからデータにアクセスする場合や、オーナーサイトが TSO である場合の、TSO中の読み取り/書き込み要求の失敗

Site A (owner site of object) Site B (non-owner site)

power outage occurs,Site A is unavailable

1

X

Application

X

heartbeat stops between sites

checks primary copy to see if Site B copy is latest copy - primary copy unavailable

Namespace

primary copy

Bucket 1 Bucket 1

2

5

4 16 minutes after power outage, an application connected to Site Bmakes a read or write request for an object owned by Site A

secondary copy

3 after 15 minutes, ECS marks Site A as TSO

TSO

6X read/writerequest fails

次の図では、バケットで無効化されている ADO プロパティを使用する TSO として示されている、オーナー以外のサイトを表示します。アプリケーションがオーナーサイトのプライマリコピーにアクセスしよ


無効化された ADOバケットのプロパティを使用した TSO の動作 169

うとする場合、オーナーサイトへの読み取り/書き込み要求が成功します。オーナー以外のサイトに接続するアプリケーションからの読み取り/書き込み要求は失敗します。図 23 オーナーサイトからデータにアクセスする場合や、オーナー以外のサイトが TSO である場合の、TSO中の読み取り/書き込み要求の成功

power outage occurs,Site B is unavailable

1

Site A (owner site of object) Site B (non-owner site)X

Application

Xheartbeat stops between sites

Namespace

primary copy

Bucket 1 Bucket 1

2

416 minutes after power outage, an appconnected toSite A makes a read or writerequest for an object owned by Site A

secondary copy

3 after 15 minutes, ECS marks Site B as TSO TSO

5 read/writerequestsucceeds

有効化された ADOバケットプロパティを使用した TSO動作ECSは、TSO中にデータにアクセスできることを確認するためのメカニズムを提供します。バケットのADO（アクセス中停止）プロパティを設定し、バケットを所有するサイトに障害が発生した場合でも、そのバケットのオブジェクトのプライマリコピーが使用できるようにします。バケットに ADO プロパティが設定しない場合、障害が発生したサイトの所有するバケットのオブジェクトに対して読み取り/書き込み要求を別のサイトから実行できません。バケットが［Access During Outage］プロパティが［On］に設定されている場合は、あらゆるサイトに接続して、アプリケーションでそのバケット内のオブジェクトを読み取ることができます。バケットで有効化された ADO プロパティを使用し、一時停止を検出すると、次の図に示すように、所有者以外のサイトに接続するアプリケーションからの読み取り/書き込み要求が受け入れられます。

アプリケーションがバケットの所有者ではないサイトに接続すると、アプリケーションは、ネームスペースのバケットを一覧表示せず、ベケットやオブジェクトへのアクセスを明示的にする必要があります。詳細については、TSO に関する考慮事項（176 ページ）を参照してください。



図 24 オーナー以外のサイトから ADO が有効化されたデータにアクセスする場合や、オーナーサイトが TSO

である場合の、TSO中の読み取り/書き込み要求の成功

Site A (owner site of object) Site B (non-owner site)

power outage occurs,Site A is unavailable

1

X

Application

X

heartbeat stops between sites

checks primary copy to see if Site B copy is latest copy - primary copy

Namespace

primary copy

2

5

416 minutes after the power outage, an application connected to Site B makes a read or write request for an object owned by Site A

secondary copy

3 after 15 minutes, ECS marks Site A as TSOTSO

6 read/writerequestsucceeds

ADO-enabled Bucket 1 ADO-enabled Bucket 1

available

ECS システムは、バケットで有効化された ADO を使用して、TSO中に結果的に整合性モデルで運用します。あるサイトでオブジェクトに変更が行われると、［最終的に］他のサイトの、そのオブジェクトのコピー全体で整合を取ります。他のサイトへの変更をレプリケートするのに十分な時間が経過するまでは、その値が特定の時点で、データの複数のコピー間で整合性が取れない可能性があります。考慮すべき重要な点は、バケットで有効化された ADO のパフォーマンスの結果です。つまり、有効化された ADO の読み取り/書き込みのパフォーマンスは、ADO が無効化されたバケットよりも低速になります。パフォーマンスの違いは ADO のバケットが有効化されているためであり、TSO後にすべてのサイトが使用可能になる場合には、強力な整合性を提供するために ECSはオブジェクトの所有権を最初に解決する必要があります。ADO がバケットで有効化されない場合、ECSはオブジェクトの所有権を解決する必要がありません。バケットが TSO中にオブジェクトの所有権を変更できないためです。ADO プロパティの利点は、一時的なサイトの停止中にデータにアクセスできることです。一方不利な点は、返されるデータが古くなり、ADOバケットでの読み取り/書き込みのパフォーマンスが遅くなることです。ADO（［Access During Outage］）プロパティを有効化するか無効化するか選択し、TSO中にバケットのオブジェクトにアクセスできるかどうかを定義できます。さらに、［Read-Only AccessDuring Outage］プロパティを有効化するか無効化するかでサイト停止中にバケットのオブジェクトにアクセスするタイプを定義できます。

［Read-Only Access During Outage］プロパティを有効化して、ADO が有効化されているバケットに、ADO が無効化されているバケットよりも低速な読み取り/書き込みのパフォーマンスにできる場合もあります。

デフォルトでは、［Access During Outage］は無効化されていて、TSO中に取得されたデータが最新でない可能性があるためです。［Access During Outage］を有効化すると、バケットとバケット内のすべてのオブジェクトを、システム停止時に使用可能であると示します。バケットの作成時に［Access During Outage］を有効化し、バケット作成後にこのプロパティを変更できます（すべてのサイトはオンラインです）。


有効化された ADOバケットプロパティを使用した TSO動作 171

［Access During Outage］プロパティを有効化すると、次のことが TSO中に発生します。l デフォルトでは、システム停止時にオブジェクトデータには読み取り処理でも書き込み処理でも

アクセスできます。l ファイルシステムが有効化された（HDFS と NFS）バケット内ファイルシステムは、使用不可の

サイトが所有され、システム停止時に読み取り専用です。バケットを作成して、［Access During Outage］プロパティを有効化すると、バケットの［Read-Only Access During Outage］プロパティ有効化するオプションもあります。バケットの作成時に、［Read-Only Access During Outage］の設定だけができます。つまり、バケットの作成後は、このプロパティを変更することはできません。［Read-Only Access During Outage］プロパティを有効化すると、次のことが TSO中に発生します。l バケット内の新規オブジェクトの作成が制限されます。l ［Access During Outage］をファイルシステムのバケットに設定すると、ファイルシステムへのア

クセスは自動的に読み取り専用モードになるため、影響ありません。次のインターフェイスからバケットを作成する場合、［Access During Outage］プロパティと［Read-Only Access During Outage］プロパティを設定することができます。l ECS Portal（バケットの作成（90 ページ）を参照）l ECS管理 REST API

l ECS CLI

l S3、Swift、Atmosなどのオブジェクト API REST インターフェイスADO が有効化されたバケットでの TSO動作については、次の ECS システム構成で説明します。l ADO が有効化されたバケットを使用した 2 サイトによる地理的連携環境（172 ページ）l ADO が有効化されたバケットを使用して、3 サイトの Geo-Active の導入（173 ページ）l ADO が有効化されたバケットを使用して、3 サイトの Geo-Passive を導入（174 ページ）

ADO が有効化されたバケットを使用した 2 サイトによる地理的連携環境

アプリケーションを非オーナーサイトに接続し、ネットワークの停止中に ADO が有効化されたバケット内のオブジェクトを変更すると、ECSはオブジェクトが変更されたサイトにオブジェクトの所有権を転送します。次の図に、2 サイトによる地理的連携環境での TSO中に、非オーナーサイトへの書き込みがオブジェクトの所有権を非オーナーサイトに取得させるしくみを示します。この機能により、各サイトに接続するアプリケーションは共有ネームスペースのバケットからのオブジェクトの読み取りおよび書き込みを継続できます。TSO中にサイト A とサイト B の［両方］で同じオブジェクトを変更すると、非オーナーサイト上のコピーが権限のあるコピーになります。ネットワークの障害発生時にサイト B が所有するオブジェクトをサイト A とサイト B の両方で変更すると、サイト A上のコピーは権限のあるコピーとして保持され、もう一方のコピーは上書きされます。2 つのサイト間のネットワーク接続がリストアされると、ハートビートメカニズムが接続性を自動的に検出し、サービスをリストアして、2 つのサイトからオブジェクトを調整します。この同期化操作はバックグラウンドで実行され、ECS Portal の［Monitor］ > ［Recovery Status］ページで監視することができます。



図 25 2 サイト連携で、TSO中に書き込みのためのオブジェクト所有権の例

Site A Site B

Before TSO - normal state

Site A Site B

During TSO - Site A is temporarily unavailable

Application connected to Site B writes

to the secondary copy of Word doc

Site A Site B

After TSO - Site A rejoins federation and object versions are reconciled

Primary copy of updated Word doc now exists in Site B

after TSO is over. Site B is owner site of Word doc.

Primary copies of these 2 objects still reside in

Site A. SIte A is owner site of these objects.

Application Application connected to Site A makes write requests to create ADO-enabled Bucket 1

and objects within it. Site A is the owner site of Bucket 1 and the objects within it.

Application

Namespace

secondary copies replicated

to Site B

secondary copies

of objects

primary copies

of objects

Namespace

Namespace

ADO-enabled Bucket 1





X TSO

network

connection

network

connection down

network connection

ADO が有効化されたバケットを使用して、3 サイトの Geo-Active の導入

レプリケーショングループ 3 つ以上のサイトがあり、1 つのサイトと他の 2 つのサイトの間でネットワーク接続が中断された場合、書き込み/更新/所有権操作の操作は 2 つのサイトで継続できますが、読み取り要求に対応するプロセスはより複雑です。アプリケーションがアクセスできないサイトによって所有されているオブジェクトを要求する場合、ECSがオブジェクトのセカンダリコピーで、サイトにリクエストを送信します。セカンダリコピーはデータ縮小操作の対象となった可能性があり、新しいデータセットを生成する 2 つの差分データセット間のXOR です。セカンダリコピーのあるサイトでは、元の XOR演算に含まれるオブジェクトのチャンクを取得する必要があり、リカバリコピーでこれらのチャンクを XORする必要があります。この操作では、オーナーサイトに保存されていた元のチャンクのコンテンツを返します。リカバリしたオブジェクトのチャンクを再構築し、返します。チャンクを再構築する場合、それをキャッシュし、サイトが後続のリクエストがより迅速に応答します。再構築には時間がかかります。レプリケーショングループ内の多くのサイトでは、チャンクを他のサイトから取得する必要があり、そのため、オブジェクトを再構築にはより時間がかかります。次の図では、3 サイトのフェデレーションで読み取り要求に対応するプロセスを示します。



図 26 3 サイトのフェデレーションで、TSO中の読み取り要求ワークフローの例

Site A - owner site Site B - non-owner site Site C - non-owner site

Application

1

2

MP4

XORcopy

MP4

load balancer

read request for MP4 object

load balancer routes request to one of the sites that is up, Site C

3

6

Site C routes request to Site B where secondary copy resides; it is an XOR copy, so it must bereconstructed

read requestsuccessfullycompleted

MP4

XORcopy

MP4

primary copy ofobject reconstructed

secondarycopy of object

use XOR chunks to reconstructsecondary copy of object

retrieve XOR chunks 4

5

Namespace

ADO-enabled Bucket 1 ADO-enabled Bucket 1ADO-enabled Bucket 1

X TSO

Network connection between Site A and Sites B and C is down

ADO が有効化されたバケットを使用して、3 サイトの Geo-Passive を導入

3 サイトの Geo-Passive構成に ECS を導入すると、TSO の動作は ADO が有効化されたバケットを使用して、3 サイトの Geo-Active の導入（173 ページ）の説明と同様で、1 つだけ相違点があります。アクティブサイトとパッシブサイトの間のネットワーク接続に障害が発生した場合、ECSは（アクティブサイトではなく）TSO としてのパッシブサイトを常に示します。2 つのアクティブサイト間のネットワーク接続に障害が発生した場合、次の通常の TSO動作が発生します。

1. ECS（使用不可能な）TSO としてアクティブサイトのいずれかを示します。たとえば、オーナーサイト B です。

2. 起動しているサイト（サイト A）から、読み取り/書き込み/更新のリクエストが表示されます。3. 読み取り要求については、サイト A がパッシブサイト（サイト C）のオブジェクトを要求します。4. サイト C が XOR チャンクをデコード（XOR を元に戻す）し、サイト A に送信します。5. サイト Aは、読み取り要求を許可するオブジェクトのコピーを再構築します。6. 作成/更新リクエストがある場合、サイト A がオブジェクトのオーナーになり、システム停止後に所有権を保持します。

次の図では、Geo-Passive構成の通常の状態を示します。ユーザーがサイト A と B に読み取りと書き込みができ、データおよびメタデータは、パッシブサイト C に一方向でレプリケートされます。サイト Cはアクティブサイトのデータを XOR します。



図 27 正常な状態の Geo-Passive レプリケーション

Site A - Active Site

Site C - Passive Site



Namespace

metadata

replication

user data & metadata replication

Site B - Active Site

chunk 1 chunk 2

chunk 3(chunk 1 XOR chunk 2 = chunk 3)

ADADO-enabled Bucket 11111

chunk 1

ADO-enabled Bucket 1ADO-enabled Bucket 1

次の図では、Geo-Passive構成の 3 つのサイトで、TSO中に行われた書き込み要求のワークフローを示します。図 28 Geo-Passive レプリケーションの TSO

Site C - Passive Site

Namespace

updated object - Site Anow owns this object

MP4

load balancer

Application

write request for MP4 object

load balancer routes request to the site that is up, Site A

Chunks are replicated to Site C

MP4

primary copy of object

XTSO

primary copy primary copy primary copy

MP4 Namespace

MP4

ri primary copy

Network connection down



4

Changes are saved onlocal chunks

Site A - Active Site Site B - Active Site

1

2

3

5



TSO に関する考慮事項TSO中には、多くのオブジェクト操作を実行できます。ADOバケットの設定に関係なく、一時的な障害が解決するまで、地理的に連携している任意のサイトで次のエンティティで、作成、削除、更新の操作を実行できません。l ネームスペースl Buckets

l オブジェクトユーザーl 認証プロバイダーl レプリケーショングループ（サイトのフェールオーバー用のレプリケーショングループから VDC を削

除できます）l NFS ユーザーおよびグループマッピング次の制限事項は、TSO中にバケットに適用されます。l ネームスペースオーナーサイトにアクセスできない場合は、ネームスペースのバケットを一覧表示

することはできません。使用可能なサイトが所有するバケット内のオブジェクトと、使用不可のサイトが所有する ADO が有効化されたバケット内のオブジェクトを一覧表示できます。使用不可のサイトが所有する ADO が有効化されたバケットのオブジェクトを一覧表示すると、レプリケートされたオブジェクトのみを返し、リストが完全でない可能性があります。

l ファイルシステムが有効化された（HDFS と NFS）バケット内ファイルシステムは、使用不可のサイトが所有され、読み取り専用です。

l 使用不可のサイトが所有するバケットのオブジェクトをコピーすると、そのコピーはソースオブジェクトのフルコピーになります。これは、同じオブジェクトのデータが複数回保存されていることを意味します。TSO以外の通常の状況では、オブジェクトのコピーはオブジェクトのデータの全複製ではなく、オブジェクトデータのインデックスで構成されます。

l OpenStack Swift ユーザーは、TSO中 OpenStack にログインできません。ECS が TSO中に Swift ユーザーを認証できないためです。TSO後、Swift ユーザーは再認証する必要があります。

TSO中の NFS ファイルシステムのアクセスNFSはすべての ECS ノードにわたって単一のネームスペースを使用するため、TSO のイベントが発生した場合でも動作を継続することができます。NFS エクスポートをマウントする場合、任意のECS ノードを NFS サーバとして指定することができます。ロードバランサーのアドレスを指定してもかまいません。どのノードを指定しても、ECS システムはファイルシステムのパスを解決できます。TSO が発生しても、ロードバランサーがトラフィックを別のサイトに切り替えることができる場合は、NFS エクスポートは引き続き使用可能です。そうでない場合は、障害の発生していない別サイトからエクスポートを再マウントする必要があります。オーナーサイトで障害が発生し、オーナーでないサイトをポイントするように ECS を再構成しなければならない場合は、NFS非同期書き込みのデータと、未完了の ECS データレプリケーション操作によって、データが消失する可能性があります。NFS が有効化されたバケットにアクセスする方法についての詳細は、ファイルアクセスの概要（108ページ）を参照してください。

PSO動作



障害が発生した場合、サイト全体が復旧不可能になります。これについては、PSO（永続的なサイト停止）としての ECS が参考になります。ECSは復旧できないサイトを一時的なサイトの障害として扱いますが、サイト全体がダウンしているか、WAN経由で完全に到達できない場合は除きます。障害が永続的な場合、システム管理者はフェールオーバー処理を開始するフェデレーションから、永続的にサイトのフェールオーバーする必要があります。これによって、障害が発生したサイトに保存されているオブジェクトの再同期化と再保護を開始します。リカバリタスクはバックグラウンド処理として実行されます。ECS Portal でのフェールオーバーの手順を実行する方法の詳細については、VDCの削除とサイトのフェールオーバー（36 ページ）を参照してください。ECS Portal で PSO を開始する前に、カスタマーサポート担当者に連絡することが推奨されていても、担当者がクラスタの正常性を検証できます。データは、フェールオーバー処理が完了するまではアクセスできません。ECS Portal の［Monitor］ > ［Geo RepReplication］ > ［FailoverProcessing］タブで、フェールオーバー処理の進行状況を監視することができます。フェールオーバー処理が完了すると、このタブはステータスを表示しません。フェールオーバー処理が完了し、リカバリのバックグラウンドタスクが実行されている間、リカバリタスクが完全に終了するまで、削除されたサイトからデータをいくつかを読み取りしない可能性があります。

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

ディスクの稼働状態ECS では、ディスクの稼働状態を「Good」、「Suspect」、「Bad」でレポートします。l Good：ディスクのパーティションに対して、読み取りも書き込みも実行できます。l Suspect：ディスクはまだ、悪い状態であると判断されるような閾値には達していません。l Bad：ハードウェアのパフォーマンス低下を示す特定の閾値に達しています。閾値に達すると、デ

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

ノードの稼働状態ECS では、ノードの稼働状態を「Good」、「Suspect」、「Bad」でレポートします。l Good：ノードは利用可能で、I/O要求に適切なタイミングで応答しています。l Suspect：ノードが 30分を超えて利用できません。l Bad：ノードが 1時間を超えて利用できません。ECSは、ノードの稼働状態に関係なく、アクセス可能なノードに書き込みます。オブジェクトのチャンクのうち 2 つが疑わしいノードにある場合、ECSは 2個の新しいチャンクを他のノードに書き込みます。

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

1. 障害の影響を受けるチャンクまたは消失訂正符号フラグメントを識別します。2. 影響を受けるチャンクまたは消失訂正符号フラグメントのコピーを、現在コピーのない正常なノードとディスクに書き込みます。


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

ノードの障害時の NFS ファイルシステムアクセスNFSはすべての ECS ノードにわたって単一のネームスペースを使用するため、ノードの障害が発生した場合でも動作を継続することができます。NFS エクスポートをマウントする場合、任意の ECSノードを NFS サーバとして指定することができます。ロードバランサーのアドレスを指定してもかまいません。どのノードを指定しても、ECS システムはファイルシステムのパスを解決できます。ノードに障害が発生した場合、ECSはデータフラグメントを使用してデータをリカバリします。NFS エクスポートが非同期書き込み用に構成されている場合は、ディスクに書き込まれていないすべてのトランザクションに関連するデータが消失する危険があります。これは、どの NFS実装の場合も同じです。ECS ノードを指定してファイルシステムをマウントしそのノードに障害が発生した場合、別のノードをNFS サーバとして指定してエクスポートを再マウントする必要があります。ロードバランサーのアドレスを使用してエクスポートをマウントした場合は、ロードバランサーでノードの障害が処理され、別のノードに自動的にリクエストが送信されます。

新しいノード追加後のデータの再バランシング新しいラックまたはストレージノードの追加によりサイトのノード数が拡張すると、新しい消失符号化チャンクが新しいストレージに割り当てられ、既存のデータチャンクが新しいノード間で再分配（再バランシング）されます。チャンクの消失符号化の発生には、4 ノード以上が必要です。必要な 4 ノードを超えて新しいノードを追加すると、消失訂正符号の再バランシングが発生します。消失訂正符号フラグメントの再分配はバックグラウンドタスクとして実行されるため、再分配プロセス中もチャンクデータへアクセスできます。さらに、新たなフラグメントデータの分配は低い優先度で行われるため、ネットワーク帯域幅の消費量は最小に抑えられます。フラグメントの再分配は、最初にエンコードされたのと同じ消失訂正符号スキームに従って行われます。コールドストレージ消失訂正符号スキームを使用してチャンクが書き込まれた場合、ECSは再分配のために新たなフラグメントを作成する際にもコールドストレージスキームを使用します。



Documents

Elastic Cloud Storage (ECS)...ECS では、複数ノードと接続されたストレージ デバイスを含む、拡張性の高いアーキテクチャを使用 します。そのノードとストレージ

Elastic Cloud Storage (ECS)...ECS では、複数ノードと接続されたストレージデバイスを含む、拡張性の高いアーキテクチャを使用します。そのノードとストレージ