ibm xiv storage system · 2020. 7. 23. · スナップショット .....31 redirect-on-write...

IBM XIV Storage Systemバージョン 11.5.1

製品概要

GC43-0913-07

��

お願い本書および本書で紹介する製品をご使用になる前に、 215ページの『特記事項』に記載されている情報をお読みください。

本装置は、高調波電流規格 JIS C 61000-3-2 に適合しています。

本製品およびオプションに電源コード・セットが付属する場合は、それぞれ専用のものになっていますので他の電気機器には使用しないでください。

本書は、IBM XIV Storage System のバージョン 11.5.1、および新しい版で明記されていない限り、以降のすべてのリリースおよびモディフィケーションに適用されます。

本書は GC43-0913-06 の改訂版です。

お客様の環境によっては、資料中の円記号がバックスラッシュと表示されたり、バックスラッシュが円記号と表示されたりする場合があります。

　

原典： GC27-3912-07

IBM XIV Storage System

Version 11.5.1

Product Overview

発行：日本アイ・ビー・エム株式会社

担当：トランスレーション・サービス・センター

© Copyright IBM Corporation 2008, 2014.

目次図 . . . . . . . . . . . . . . . . . vii

表 . . . . . . . . . . . . . . . . . ix

概要 . . . . . . . . . . . . . . . . xi目的および対象範囲 . . . . . . . . . . . . xi文書のバージョン . . . . . . . . . . . xi対象読者 . . . . . . . . . . . . . . xiアクセシビリティー . . . . . . . . . . . xi本書で使用する注記 . . . . . . . . . . . xi資料のきまり . . . . . . . . . . . . . xii用語および省略語 . . . . . . . . . . . xii

情報、ヘルプ、およびサービスの入手 . . . . . xii

第 1 章概要: IBM XIV Storage System 1フィーチャーと機能性 . . . . . . . . . . . 1ハードウェアの概要 . . . . . . . . . . . . 2ハードウェア・コンポーネント . . . . . . . 2サポートされるインターフェース . . . . . . 4管理オプション . . . . . . . . . . . . 6

信頼性 . . . . . . . . . . . . . . . . 6冗長コンポーネントによる Single Point of Failureの排除 . . . . . . . . . . . . . . . 6データ・ミラーリング . . . . . . . . . . 6自己修復メカニズム . . . . . . . . . . . 6キャッシュの保護 . . . . . . . . . . . . 7予備電源 . . . . . . . . . . . . . . . 7SSD キャッシュ・ドライブ . . . . . . . . 8

パフォーマンス . . . . . . . . . . . . . 8機能性 . . . . . . . . . . . . . . . . 9スナップショット管理 . . . . . . . . . . 9スナップショットの整合性グループ . . . . . . 9ストレージ・プール . . . . . . . . . . 10リモート・モニターと診断 . . . . . . . . 10SNMP . . . . . . . . . . . . . . . 10マルチパス . . . . . . . . . . . . . 10自動イベント通知 . . . . . . . . . . . 10GUI および CLI を使用した管理 . . . . . . 10外部レプリカ生成メカニズム . . . . . . . 11アップグレード可能性 . . . . . . . . . . 11

第 2 章接続 . . . . . . . . . . . . 13IP 接続およびイーサネット接続 . . . . . . . 13イーサネット・ポート . . . . . . . . . . 13IPv6 認証 . . . . . . . . . . . . . . 14管理接続 . . . . . . . . . . . . . . 15フィールド技術員用ポート . . . . . . . . 16構成ガイドラインの要約 . . . . . . . . . 17

ホスト・システム接続 . . . . . . . . . . . 17平衡トラフィック、および Single Point of Failureなし . . . . . . . . . . . . . . . . 17

動的速度適応 . . . . . . . . . . . . . 17ホストへのボリュームの接続 . . . . . . . 18LUN0 の除外 . . . . . . . . . . . . . 18

拡張ホスト接続 . . . . . . . . . . . . . 18iSCSI ホストの CHAP 認証 . . . . . . . . . 19LUN マップへのホストのクラスター化 . . . . . 20ボリューム・マッピングの例外 . . . . . . . 22

VMWare 拡張操作のサポート . . . . . . . . 23ゼロの書き込み . . . . . . . . . . . . 24ハードウェア支援によるロック . . . . . . . 24高速コピー . . . . . . . . . . . . . 25

QoS パフォーマンス・クラス . . . . . . . . 25コール・ホーム・コンタクト・リストの更新 . . . 26ホスト・システム接続コマンド . . . . . . . . 26

第 3 章ボリュームおよびスナップショットの概要 . . . . . . . . . . . . . . 29ボリュームのライフサイクル . . . . . . . . 29

Symantec Storage Foundation のシン・レクラメーション (Thin Reclamation) 機能のサポート . . . 31

スナップショット . . . . . . . . . . . . 31Redirect-on-Write . . . . . . . . . . . . 32ストレージ使用率 . . . . . . . . . . . 34スナップショットの自動削除優先順位 . . . . 34スナップショット名および関連 . . . . . . . 35スナップショットのライフサイクル . . . . . 35スナップショットおよびスナップショット・グループのフォーマット . . . . . . . . . . 41電子ライセンスの受諾 . . . . . . . . . . 43

第 4 章整合性グループの概要 . . . . . 45整合性グループの作成 . . . . . . . . . . . 45整合性グループのスナップショットの取得 . . . . 46スナップショット・グループのライフサイクル . . 47整合性グループの復元 . . . . . . . . . . . 49

第 5 章ストレージ・プールの概要 . . . 51ストレージ・プール・レベルでのスナップショットの保護 . . . . . . . . . . . . . . . . 52シン・プロビジョニング . . . . . . . . . . 52即時スペース再利用 . . . . . . . . . . 55

第 6 章同期リモート・ミラーリング . . 57リモート・ミラーリングの基本概念 . . . . . . 57リモート・ミラーリング操作 . . . . . . . . 58構成オプション . . . . . . . . . . . . . 59ボリュームの構成 . . . . . . . . . . . 59通信エラー . . . . . . . . . . . . . 61カップリングの活動化 . . . . . . . . . . 61

同期ミラーリング状況 . . . . . . . . . . . 61リンク状況 . . . . . . . . . . . . . 62

© Copyright IBM Corp. 2008, 2014 iii

操作可能状況 . . . . . . . . . . . . . 63同期状況 . . . . . . . . . . . . . . 63

入出力操作 . . . . . . . . . . . . . . 64同期化処理 . . . . . . . . . . . . . . 65状態遷移図 . . . . . . . . . . . . . 65カップリングのリカバリー . . . . . . . . 66非コミット・データ . . . . . . . . . . 67制約および制限 . . . . . . . . . . . . 67最終整合スナップショット . . . . . . . . 672 次ロック・エラー状況 . . . . . . . . . 69

役割の切り替え . . . . . . . . . . . . . 70リモート・ミラーリングが操作可能の場合の役割の切り替え . . . . . . . . . . . . . 70リモート・ミラーリングが操作不可の場合の役割の切り替え . . . . . . . . . . . . . 70役割変更後のリモート・ミラーリングの再開 . . 72

その他 . . . . . . . . . . . . . . . . 74リモート・ミラーリングと整合性グループ . . . 74メディア・エラー・リカバリーのためのリモート・ミラーリングの使用 . . . . . . . . . 74サポートされる構成 . . . . . . . . . . 74入出力パフォーマンスと同期速度の最適化 . . . 74その他のコマンドに関する注記 . . . . . . . 75

第 7 章非同期リモート・ミラーリング 77章の範囲 . . . . . . . . . . . . . . . 78フィーチャーのハイライト . . . . . . . . 78用語 . . . . . . . . . . . . . . . . 80仕様 . . . . . . . . . . . . . . . . 81

技術概要 . . . . . . . . . . . . . . . 81複製スキーム . . . . . . . . . . . . . 82スナップショット・ベースのテクノロジー . . . 83特殊スナップショットのミラーリング . . . . 84ミラーリングの初期化 . . . . . . . . . . 85同期ジョブ . . . . . . . . . . . . . 86ミラーリングのスケジュールおよびインターバル 87ミラー・スナップショット (随時同期ジョブ) . . 88複製状態およびミラー状態の判別 . . . . . . 89非同期ミラーリング・プロセスのウォークスルー 100ピアの役割 . . . . . . . . . . . . . 107ミラーリングの活動化 . . . . . . . . . 107

整合性グループのミラーリング . . . . . . . 109整合性グループをミラーリング対象にするための設定 . . . . . . . . . . . . . . . 111ミラーリングされた整合性グループのセットアップ . . . . . . . . . . . . . . . . 112ミラーリングされた整合性グループへのミラーリングされたボリュームの追加 . . . . . . . 113ミラーリングされた整合性グループからのボリュームの削除 . . . . . . . . . . . . . 113

非同期ミラーリング・タスクの管理 . . . . . . 113災害時回復シナリオの提供 . . . . . . . . 113選択非同期ミラーリング・コマンドの概要 . . . 119

第 8 章マルチサイト・ミラーリング 123マルチサイト・ミラーリングに関する用語 . . . . 123

マルチサイト・ミラーリング・テクノロジーの概要 124マルチサイト・ミラーリングのユース・ケース . . 127マルチサイト・ミラーの作成 . . . . . . . 127マスターのフェイルオーバー . . . . . . . 128マスターのフェイルバック . . . . . . . . 134代替マスターでの避難訓練 . . . . . . . . 136代替マスターの障害とフェイルバック . . . . 137テストのためのフェイルオーバー操作およびフェイルバック操作の開始 . . . . . . . . . 139

第 9 章 IBM Hyper-Scale Mobility 141IBM Hyper-Scale Mobility とは . . . . . . . 141IBM Hyper-Scale Mobility の定義 . . . . . . . 142技術概要 . . . . . . . . . . . . . . . 143IBM Hyper-Scale Mobility プロセスのウォークスルー . . . . . . . . . . . . . . . . . 145

[ステージ 1:] IBM Hyper-Scale Mobility の計画 146[ステージ 2:] IBM Hyper-Scale Mobility プロセスのセットアップ . . . . . . . . . . . 151[ステージ 3:] マイグレーションのトラッキング 155[ステージ 4:] プロキシーの確立 . . . . . . 155[ステージ 5:] クリーンアップ . . . . . . . 157[ステージ 6:] 完了後 . . . . . . . . . . 157

IBM Hyper-Scale Mobility CLI コマンド . . . . 157データ・マイグレーション . . . . . . . . . 160データ・マイグレーションの概要 . . . . . . 160データ・マイグレーションでの入出力処理 . . . 161データ・マイグレーションの各ステージ . . . 161障害の処理 . . . . . . . . . . . . . 163

第 10 章保存データの暗号化 . . . . . 165HIPAA の互換性 . . . . . . . . . . . . 165保存データ (data-at-rest) の暗号化とは . . . . . 166SED GUI の資料 . . . . . . . . . . . . 168

第 11 章イベント処理 . . . . . . . 171イベント情報 . . . . . . . . . . . . . 171イベントの表示 . . . . . . . . . . . . . 172イベント通知規則の定義 . . . . . . . . . . 172アラート・イベント構成に関する制限 . . . . 173

宛先の定義 . . . . . . . . . . . . . . 173ゲートウェイの定義 . . . . . . . . . . . 174

第 12 章アクセス制御 . . . . . . . 177ユーザーの役割と権限レベル . . . . . . . . 177事前定義ユーザー . . . . . . . . . . . 179アプリケーション管理者 . . . . . . . . . 179

認証方式 . . . . . . . . . . . . . . . 181ネイティブ認証 . . . . . . . . . . . . 182LDAP 認証 . . . . . . . . . . . . . 182LDAP 認証方式とネイティブ認証方式の切り替え . . . . . . . . . . . . . . . . 188

アクセス制御コマンド . . . . . . . . . . 189アクセス制御の概念に関する用語集 . . . . . . 191

iv IBM XIV Storage System: 製品概要

第 13 章マルチテナンシー . . . . . . 193マルチテナンシーとは . . . . . . . . . . 193技術概要 . . . . . . . . . . . . . . . 195マルチテナンシーの処理 . . . . . . . . . . 196GUI からのマルチテナンシーの操作 . . . . . . 197マルチテナンシー XCLI コマンド . . . . . . 197

第 14 章 VMware Virtual Volumes とXIV . . . . . . . . . . . . . . . . 201VVol を操作するための前提条件 . . . . . . . 201

第 15 章非中断コード・ロード . . . . 203コード・ロードの準備 . . . . . . . . . . 204

用語集 . . . . . . . . . . . . . . 207

特記事項. . . . . . . . . . . . . . 215商標 . . . . . . . . . . . . . . . . 217

索引 . . . . . . . . . . . . . . . 219

目次 v

vi IBM XIV Storage System: 製品概要

図1. IBM XIV Storage System . . . . . . . . 32. IBM XIV Storage System のインターフェース 53. ボリューム、LUN、およびクラスター化されたホスト . . . . . . . . . . . . . . 21

4. すでにマップされている LUN にボリュームをマップすることはできません。 . . . . . . 22

5. ボリュームがすでにマップされている場合、そのボリュームを LUN にマップすることはできません。 . . . . . . . . . . . . . 22

6. ホスト・システム接続コマンド . . . . . . 287. ボリューム操作 . . . . . . . . . . . 308. Redirect-on-Write プロセス: ボリュームのデータおよびポインター . . . . . . . . . . 32

9. Redirect-on-Write プロセス: スナップショットを取得するときは、ヘッダーが最初に書き込まれます。 . . . . . . . . . . . . . 33

10. Redirect-on-Write プロセス: 新規データが書き込まれます。 . . . . . . . . . . . . 33

11. Redirect-on-Write プロセス: スナップショットは古いデータを指すのに対して、ボリュームは新規データを指します。 . . . . . . . . 34

12. スナップショットのライフサイクル . . . . 3613. ボリュームの復元 . . . . . . . . . . 3914. スナップショットの復元 . . . . . . . . 4015. 整合性グループのライフサイクル . . . . . 4516. 整合性グループのボリュームごとのスナップシ

ョットの取得 . . . . . . . . . . . . 4617. スナップショット操作のほとんどはスナップシ

ョット・グループに適用可能 . . . . . . . 4718. カップリングの状態およびアクション . . . . 6619. 同期ミラーリングでは応答時間のずれが拡大 7820. 非同期ミラーリング - 応答時間のずれは拡大し

ない . . . . . . . . . . . . . . . 7821. 複製スキーム . . . . . . . . . . . . 8322. 特殊なスナップショットの場所 . . . . . . 8423. ネットワーク経由での非同期ミラーリングの初

期化 . . . . . . . . . . . . . . . 8524. 非同期ミラーリングの同期ジョブ . . . . . 8725. RPO_OK の判別方法 . . . . . . . . . 9126. RPO_Lagging の判別方法 . . . . . . . . 9127. 非同期ミラーリング状況の判別 - 例 (パート

1) . . . . . . . . . . . . . . . . 9228. 非同期ミラーリング状況の判別 - 例 (パート

2) . . . . . . . . . . . . . . . . 9229. 非同期ミラーリング状況の判別 - 例 (パート

3) . . . . . . . . . . . . . . . . 93

30. 枯渇ストレージの削除優先順位が 3 に設定されている . . . . . . . . . . . . . 95



33. 非同期ミラーリング・ウォークスルー – パート 1 . . . . . . . . . . . . . . 100











44. マルチサイト・ミラーリング・コンポーネントの階層 . . . . . . . . . . . . . 124

45. マスターに障害が起こる . . . . . . . . 13046. フェイルバック中 . . . . . . . . . . 13447. 避難訓練前 . . . . . . . . . . . . 13648. B での避難訓練 . . . . . . . . . . . 13749. 代替マスターの障害 . . . . . . . . . 13850. 代替マスターのフェイルバック . . . . . 13851. IBM Hyper-Scale Mobility のフロー . . . . 14552. データ・マイグレーション・プロセスは、ボ

リュームごとに実行されます。 . . . . . 16053. データ・マイグレーションの各ステップ 16254. 指定された LDAP ディレクトリーへの XIV

ログオン . . . . . . . . . . . . . 18455. システムが LDAP 検索を発行してユーザーを

検証する方法 . . . . . . . . . . . 187

© Copyright IBM Corp. 2008, 2014 vii

viii IBM XIV Storage System: 製品概要

表1. ヘルプ、サービス、および情報を提供する

IBM Web サイト . . . . . . . . . . xii2. ホスト接続に使用されるコマンド . . . . . 273. ボリュームの構成オプション . . . . . . . 594. カップリングの構成オプション . . . . . . 595. 同期ミラーリング状況 . . . . . . . . . 626. 最終整合スナップショットのタイム・スタンプ・プロセスの例 . . . . . . . . . . 69

7. 2 次の整合性に関する決断に至る災害時シナリオ . . . . . . . . . . . . . . . . 71

8. 新しい 1 次ボリュームの同期のためのコミットされていないデータの解決 . . . . . . . 72

9. マルチサイト・ミラーリングを構成するミラーリング関係 . . . . . . . . . . . 125

10. B の代替マスターからマスターへの役割変更後 . . . . . . . . . . . . . . . 132

11. B でマルチサイト・ミラーリングが活動化された後 . . . . . . . . . . . . . . 132

12. フェイルバック中 . . . . . . . . . . 13313. フェイルバック後 . . . . . . . . . . 13514. 使用可能なユーザーの役割 . . . . . . . 17715. アプリケーション管理者のコマンド . . . . 181

© Copyright IBM Corp. 2008, 2014 ix

x IBM XIV Storage System: 製品概要

概要

IBM® XIV® Storage System IBM XIV Storage System は、セキュアで信頼性のある、エンタープライズ・レベルのデータ・ストレージとアクセス、わかりやすいインストールとアップグレード、さらに完全なスケーラビリティーを提供するように設計されています。このシステムはハードウェアの誤動作を補正し、保守作業を最小化し、さらに柔軟性を提供する、独自の新規アルゴリズムを備えています。また、このシステムでは、統合およびサポートが容易な既製のハードウェア・コンポーネントが使用されます。

目的および対象範囲この文書では、IBM XIV Storage System のハードウェアとソフトウェアのすべてのシステム概要が網羅されています。関連する表、グラフ、グラフィック・インターフェース、出力例、およびそれぞれ該当する例も提供されます。

文書のバージョン本書は、現行リリースの IBM XIV Storage System コードをサポートします。

対象読者この資料は、IBM XIV Storage System での処理に関わる管理者および IT スタッフ向けの解説書です。

アクセシビリティーIBM XIV は、年齢や能力に関係なく、すべての人に便利なアクセス機能を備えた製品を提供するように努力しています。

本製品では、標準の Windows ナビゲーション・キーを使用しています。

詳しくは、『参照』セクションのアクセシビリティー機能に関するトピックを参照してください。

本書で使用する注記本書で使用する「注意」および「危険」の注記は、複数の言語で書かれた「IBM

XIV Storage System Safety Notices」資料にも記載されています。「注意」および「危険」の各注記には、安全に関する文書内の対応する注記を参照しやすいように番号が付けられています。

本書では、以下のタイプの注記を使用します。

お願いこの注記は、重要なヒント、ガイダンス、またはアドバイスを示します。

重要この注記は、不都合なまたは問題のある状態を避けるために役立つ情報またはアドバイスを提供します。

© Copyright IBM Corp. 2008, 2014 xi

注意この注記は、プログラム、装置、またはデータに損傷を及ぼすおそれのあることを示します。「注意」の注記は、損傷を起こすおそれのある指示や状態の記述の直前に書かれています。

警告この注記は、何らかの状態が存在しているために人間に危険な損傷を与える可能性のある状態、または何らかの危険な行為のために発生する可能性のある危険な状態を示します。「警告」の注記は、危険となりうる手順または状態の記述の直前に書かれています。

危険この注記は、人間に対して致命的あるいは極めて危険となりうる状態を示します。「危険」の注記は、致命的あるいは極めて危険となりうる手順または状態の記述の直前に書かれています。

資料のきまり本書では、以下の規則が使用されます。

太字体太字体のテキストは、メニュー項目と、大/小文字混合のコマンド名を示します。

イタリック体イタリック体のテキストは、語を強調する場合に使用されます。コマンド構文では、イタリック体は、ユーザーが実際の値を指定する変数に使用されます。

モノスペースモノスペースのテキストは、入力するデータまたはコマンド、コマンド出力の例、あるいはプログラム・コードまたはシステムからのメッセージの例を示します。

用語および省略語用語および省略語の完全なリストについては、 207ページの『用語集』を参照してください。

情報、ヘルプ、およびサービスの入手ヘルプ、サービス、技術支援、または IBM 製品に関する詳しい情報が必要な場合は、その手助けとなるさまざまな情報ソースを見つけることができます。以下の表に、IBM 製品およびサービスに関する情報を入手したり、最新の技術情報およびサポートを検索したりするために表示できる Web ページのリストを記載します。

表 1. ヘルプ、サービス、および情報を提供する IBM Web サイト

Web サイト説明

http://www.ibm.com IBM のメイン・ホーム・ページ

http://www.ibm.com/storage/support IBM Support のホーム・ページ

http://www.ibm.com/planetwide IBM Support ページ (国別の関連する連絡先情報へのポインターを掲載)

xii IBM XIV Storage System: 製品概要

http://www.ibm.com

http://www.ibm.com/storage/support

http://www.ibm.com/planetwide

第 1 章概要: IBM XIV Storage System

この章では、IBM XIV Storage System のさまざまなフィーチャーおよび機能について、そのハードウェア・コンポーネントおよびソフトウェア・コンポーネントの概要と併せて説明します。この概要では、システムの観点から見た主な設計原理の要旨を紹介しますが、ユーザーの観点から見た機能については説明しません。これについては後続の章で説明します。

フィーチャーと機能性IBM XIV Storage System は、以下のフィーチャー・セットを特徴とします。

パフォーマンス

v 完全なロード・バランシング

v すべてのモジュールに組み込まれたキャッシュおよびディスク

v ディスク障害の場合の極めて高速の再ビルド時間

v ゼロ・チューニングを使用した一定の予測可能なハイパフォーマンス

信頼性

v 「ホット・スポット」を除去する固有のデータ配布方式

v フォールト・トレランス、障害分析、および自己修復アルゴリズム

v Single Point of Failure なし

スケーラビリティー

v シン・プロビジョニングのサポート

v 即時スペース再利用のサポート

v データ・マイグレーション

接続

v iSCSI およびファイバー・チャネル (FC) のインターフェース

v 多重ホスト・アクセス

スナップショット

v 革新的なスナップショット機能 (実質的に無制限の数のスナップショット、「スナップのスナップ」、および「スナップからの復元」のサポートを含む)

複製

v リモート・システムに対するボリューム (整合性グループも同様) の同期および非同期の複製

管理の容易性

v ストレージ・プール管理ユニットのサポート

v リモート構成管理

v 中断のないメンテナンスおよびアップグレード

© Copyright IBM Corp. 2008, 2014 1

v 管理ソフトウェア (グラフィカル・ユーザー・インターフェース (GUI)

とコマンド行インターフェース (CLI) を含む)

v E メール、SNMP、または SMS メッセージを使用したイベントの通知

v XIV は以下の IBM 製品でサポートされています。

– IBM Tivoli Storage Productivity Center スイート。ストレージ・インフラストラクチャー管理ツールである IBM Tivoli Storage Productivity

Center スイートは、お客様のタイム・ツー・バリューの改善に貢献するとともに、ストレージ・システム、ストレージ・ネットワーク、レプリケーション・サービス、およびキャパシティー管理に関連したストレージ・タスクを集中化、単純化、最適化することにより、ストレージ環境の管理を単純にします。

– Tivoli Storage FlashCopy Manager では、XIV を使用したアプリケーション認識型スナップショットがサポートされています。IBM Tivoli®

Storage FlashCopy® Manager ソフトウェアは、IBM ストレージ・システムの先進的なスナップショット・テクノロジーを活用して、高速なアプリケーション認識型のバックアップおよびリストアを提供します。

– Tivoli Storage Manager (Tivoli Storage FlashCopy Manager を含む) では、XIV ベースのバックアップとリストアがサポートされていました。IBM Tivoli® Storage Manager ソフトウェアは、単一制御点からさまざまなストレージ管理機能を提供して、企業が情報の大変動を効率的に制御するために役立ちます。

ハードウェアの概要このセクションでは、IBM XIV Storage System ハードウェアの概要について説明します。

ハードウェア・コンポーネントIBM XIV Storage System の構成には、データ・モジュール、インターフェース・モジュール、イーサネット・スイッチ、および無停電電源装置が含まれます。

2 IBM XIV Storage System: 製品概要

データ・モジュール各データ・モジュールには 12 個のディスク DDR3 と 24GB のキャッシュ・メモリーがあります。IBM XIV は、あらゆる種類のニアライン(7200rpm) SAS ドライブ (特に 2TB、4TB、または 6TB のディスク) をサポートします。このディスク・ドライブは、ストレージ・グリッドにデータを保管するための不揮発性メモリーとしてサービスを提供し、キャッシュ・メモリーは、事前読み取りデータのキャッシング、ディスクからのデータのプリフェッチ、および事前書き込みデータの遅延デステージングのために使用されます。

注: データ・モジュールは、ラックの上部と下部両方のセクションに配置されます。

InfiniBand スイッチ (x2)

v 二重電源機構

v 各 IB スイッチが各 XIV モジュールに接続されている

v 両方の IB スイッチがそれぞれのポート 16、17 で相互接続されている

v ポート 18 は予備用に空のままになっている

v ポート 19 から 36 までは非アクティブである

保守モジュールモデムを使用したリモート・サポート・アクセスを可能にします。

インターフェース・モジュール (IM)各インターフェース・モジュールは、データ・モジュールと同様のディスク・ドライブとキャッシュ・メモリーを含みます。さらに、これらのモジュールには、FC および iSCSI ポートを持つホスト・インターフェース・アダプターがあります。

8Gbps FC

図 1. IBM XIV Storage System

第 1 章概要: IBM XIV Storage System 3

v 各インターフェース・モジュール上に 2 個のデュアル・ポート FC

HBA。つまり、各インターフェース・モジュールに 4 ポート、フル・ラックに 24 ポート。

無停電電源装置モジュール複合システム (Uninterruptible power supply modulecomplex)

無停電電源装置モジュール複合システムは、3 つのユニットで構成されます。これは、外部電源機構に一時的な障害が起きた場合に内部電源供給を維持します。持続的な外部電源障害が起きた場合は、IBM XIV Storage System

が安全かつ正しい順序でシャットダウンするために十分な時間だけ、無停電電源装置モジュール複合システムが電源供給を維持します。IBM XIV

Storage System は、外部電源障害を防ぎながら、1 つの無停電電源装置の障害に耐えることができます。

ATS 自動転送スイッチ (ATS) は、外部電源の冗長性を確保できるようにするために、電源コード間の切り替えを行います。

モデムシステムが IBM サポートによるリモート・アクセスのための接続を受けられるようにします。モデムは、保守モジュールに接続します。

データ・モジュールとインターフェース・モジュールは「モジュール」と総称されます。モジュールは、PCIe アダプターにより相互に通信します。各モジュールには、モジュール間通信のための予備のポートが含まれています。ポートはすべてスイッチを介して内部ネットワークにリンクされます。さらに、モニターの目的で、UPS は個々のモジュールに直接接続されます。

サポートされるインターフェースIBM XIV Storage System では以下のインターフェースがサポートされます。

v ホスト・ベースの入出力用ファイバー・チャネル

v ホスト・ベースの入出力用ギガビット・イーサネット、iSCSI プロトコル使用

v 管理 (GUI または CLI) 接続用ギガビット・イーサネット

v 以下のリモート・アクセス・インターフェース:

– コール・ホーム接続 - IBM XIV Storage System を IBM トラブル・チケット・システムに接続します。

– モデム - 着信専用。電話回線と番号はお客様が提供する必要があります。モデムは、IBM サポートのためのリモート・アクセスを可能にする 2 次手段となります。


10Gb イーサネットIBM XIV Storage System は、1Gb および 10Gb の 2 つのイーサネット構成を提供します。

サポートされている 10Gb イーサネット構成は、10Gbps アダプターを使用した高帯域幅の iSCSI ホスト接続ポートを提供します。この構成によりワイヤーの統合を可能にし、22 個の 1Gb ポートを 12 個の 10Gb ポートと置き換えます。IP ルーティングにより、新しい構成はより多くのミラーリングの距離の柔軟性を提供し、データセンター間の 77ページの『第 7 章非同期リモート・ミラーリング』を可能にします。

1Gb システム対 10Gb システム

非混合システムは、1Gb または 10Gb のいずれかで構成できます。これはまた、デュアル・ラックにも適用されます。

1Gb システムから 10Gb システムへのアップグレードホット・アップグレードは利用できません。ハードウェアの交換は、IBM

XIV 担当員により行われます。

Light-weight スタック

10GE アダプターへの iSCSI の移動による IOPS の改善の際に、IBM XIV Storage

System は、ネイティブ Linux TCP/IP スタックを LWIP (Lightweight IP) TCP/IP スタックと置き換えて、それを専用コア上で実行します。

図 2. IBM XIV Storage System のインターフェース


LWIP スタックは、スタック相互間の直接通信を可能にするため、iSCSI と一緒に専用 CPU コアのユーザー・スペース・プロセス上で実行されます。ネイティブ・スタックは引き続き非 iSCSI トラフィックで使用されており、デバッグの参照や様々な標準 Linux ツールによっても使用されます。

管理オプションIBM XIV Storage System には、いくつかの管理オプションが用意されています。

GUI および CLI 管理アプリケーションこれらのアプリケーションを各ワークステーションにインストールして、システムの管理と制御に使用する必要があります。GUI または CLI を使用して、システムをすべての構成とモニターの両面から制御することができます。

SNMP IBM XIV MIB を使用するサード・パーティーの SNMP ベース・モニター・ツールがサポートされています

E メール通知IBM XIV Storage System は、E メール・メッセージを利用して、ユーザー、アプリケーション、またはその両方に障害、構成変更、およびその他の重要情報に関して通知することができます。

SMS 通知ユーザーは、SMS によりすべてのシステム・イベントの通知を受けることができます。

信頼性IBM XIV Storage System の信頼性フィーチャーには、データ・ミラーリング、スペア・ストレージ容量、自己修復メカニズム、およびデータの仮想化が含まれます。

冗長コンポーネントによる Single Point of Failure の排除IBM XIV Storage System ハードウェア・コンポーネントは完全な冗長性を備えており、システムでの Single Point of Failure の発生を防止するために相互のフェイルオーバー保護を確保しています。

システムのフェイルオーバー・プロセスは迅速かつシームレスに完了するため、ユーザーに認識されないで実施されます。

データ・ミラーリングストレージ用にホストから到着するデータは、個別のモジュール内にある 2 つのディスク・ドライブに永続的に書き込まれる前に、2 つの個別のキャッシュに一時的に置かれます。これにより、データが個別のモジュールの起こりうる障害に対して常に保護されることが保証され、さらにこの保護は、データが不揮発性ディスク・メディアに書き込まれる前でさえ効力があります。

自己修復メカニズムIBM XIV Storage System には、個々のコンポーネントの誤動作に対処し、数分でシステム内の完全なデータ冗長性を自動復元する自己修復メカニズムが組み込まれています。


自己修復メカニズムは IBM XIV Storage System 内の信頼性レベルを大幅に向上させます。個々のコンポーネントの誤動作が発生した場合に、発生が見込まれる第 2

のコンポーネントの誤動作を防ぐために、技術員がオンサイトで介入を行わざるを得なくなるという状況ではなく、冗長性が自動的に復元されることで、事前に設定されたルーチン・スケジュールに基づいた安定した保守ポリシーを確立できます。

自己修復メカニズムは、個々のコンポーネントの誤動作発生後に、その対応として開始されるだけでなく、事前対策としても (すなわち、コンポーネントの障害が起こり得る可能性を示す状態を検出すると) 開始されます。多くの場合、バックグラウンドで継続的に実行されている予防的な自己分析の拡張アルゴリズムの支援により、潜在的な問題がその発生前に的確に識別されます。すべての場合において、IBM XIV Storage System に実装されている自己修復メカニズムは、第 2 のコピーが破損した、または破損する危険にさらされている、システム内のすべてのデータ部分を識別します。 IBM XIV Storage System は既存のコピーからセキュアな第 2

のコピーを作成し、システムの最も適切な部分に保管します。こうしたプロセスは、完全なデータの仮想化を利用するとともに、IBM XIV Storage System に実装されているデータ配布スキームに基づくことで、マイグレーションするデータ量を最小限に抑えて完了できます。

システム内の他のすべてのプロセスと同様に、自己修復メカニズムはユーザーにまったく認識されないまま実行され、入出力データ要求への応答といった通常のアクティビティーは、システム・パフォーマンスを低下させずに十分に維持されます。このアクティビティーによって、パフォーマンス、ロード・バランシング、および信頼性が損なわれることはありません。

キャッシュの保護IBM XIV Storage System のキャッシュ書き込みは保護されます。モジュールのキャッシュ・メモリーは ECC (エラー訂正コード) によって保護されます。書き込み要求はすべて、ホストが確認応答を受け取る前に 2 つの別個のキャッシュ・モジュールに書き込まれます。データは後でディスクにデステージされます。

予備電源IBM XIV Storage System では、以下の方法で電源の冗長性が維持されます。

v 3 台の無停電電源装置 - システムは 2 台の無停電電源装置で無期限に稼働し続けることができます。 1 台の無停電電源装置が故障しても、どのシステム・コンポーネントも電源を失うことはありません。

v 各データ・モジュールおよびインターフェース・モジュール内に予備電源機構。各モジュール用に 2 台の電源機構が用意され、モジュールの各電源機構はそれぞれ異なる無停電電源装置から電源が供給されます。

v イーサネット・スイッチ用の予備電源 - 各イーサネット・スイッチは 2 台の無停電電源装置から電源が供給されます。 1 台は直接接続され、もう 1 台はイーサネット・スイッチの予備電源機構を介して接続されます。

v 予備電源コード - 外部電源の喪失を防ぐため、ATS への電源コードが 2 本提供されます。 1 本の電源コードで外部電源が失われると、ATS は自動的にもう一方の電源コードに切り替え、その際のシステムへの影響は生じません。


v 両方の電源コードで外部電源が失われた場合、システム内のすべてのデータの緊急デステージが完了するまで、無停電電源装置がシステムへの電源供給を維持します。緊急デステージが完了すると、システムはその制御のもとで電源遮断を実行します。

SSD キャッシュ・ドライブIBM XIV Storage System は、キャッシュとしてのフラッシュ (SSD) を、キャッシュ・ノードとディスク間の 2 つ目の読み取り専用キャッシング層として使用します。

この方法では、DRAM キャッシュより 1 桁分大きいキャッシュを備えることで、システムでディスク・アクセスが削減されます。現在、システムはモジュールごとに 1 つの SSD ディスクを備えています。キャッシュとしてのフラッシュはモジュールの細分度で設計されているため、あるモジュールにこの機能が存在しなくても、他のモジュールのその機能には影響ありません。キャッシュとしてのフラッシュは実行時に使用可能にも使用不可にも設定できるため、ストレージ・システムはいつでも SSD を装備することができます。

インストール

SSD は 1:SSD:<module:1> として識別される新しいハードウェア・コンポーネントです。これは接続時に自動的に追加されます (equip コマンドは不要)。SSD は通常のディスク・ドライブと同様に、フェーズアウト、テスト、およびフェーズインされます。これは読み取りキャッシュ専用であるため、SSD コンポーネントの状態変更により再作成がトリガーされることはありません。これは他のディスクと同様に、実装およびアクセスされます。

パフォーマンスIBM XIV Storage System は、考え方を根本から変える非常に優れた特性と機能を使用して、企業がその問題を克服するために設計された画期的なハイパフォーマンスのストレージ製品です。

画期的なアーキテクチャーと設計IBM XIV Storage System の革新的な設計により、従来のアーキテクチャーでは通常実現できない非常に優れたパフォーマンスの最適化が可能になります。この最適化では、システム・リソースが効率的に使用され、システムのすべてのハード・ディスク間でワークロードが自動的に分散されます。また、これにより、管理者はパフォーマンスに悪影響を与えることなく、シン・プロビジョニング、ミラーリング、スナップショットなど、システムの多くの高度な組み込み機能を活用できます。

安定した予測可能なパフォーマンスとスケーラビリティーすべてのワークロードに対してすべてのディスク間での負荷の分散を最適化する IBM XIV Storage System の機能と、強力な分散キャッシュの実装とを組み合わせることにより、追加されたストレージ格納装置に比例して変化するハイパフォーマンスを容易に実現します。このハイパフォーマンスは安定していて、手動調整を必要としないため、コンポーネントの障害が発生して


も、ユーザーは、ボリュームとスナップショットの使用パターンに関連した一般的なピークと谷間でも、同様のハイパフォーマンスを得ることができます。

回復力および自己修復IBM XIV Storage System は、ハードウェアの障害が発生しても回復力を維持して、パフォーマンスにほとんど影響を与えることなく機能し続けます。また、このソリューションの高度な自己修復機能により、最初の障害から回復した後に別のハードウェアの障害に対応することができます。

自動最適化および管理従来のストレージ・ソリューションとは異なり、IBM XIV Storage System

は、ハードウェア構成の変更 (コンポーネントの追加や交換または障害など)

に応じてデータの分散を自動的に最適化します。このため、手動による調整や最適化が必要ありません。

機能性IBM XIV Storage System の機能には、ポイント・イン・タイム・コピー、自動通知、および GUI や CLI を使用した簡単な管理などがあります。

スナップショット管理IBM XIV Storage System は、ボリュームのポイント・イン・タイム・コピーを作成するための強力なスナップショット・メカニズムを備えています。

スナップショット・メカニズムには、以下の機能が含まれます。

v ソース・ボリュームとそのスナップショット間で異なるデータに対してのみストレージ・スペースが使用される差分スナップショット

v アプリケーションの中断なしで行われるスナップショットの瞬時作成。そのスナップショットはただちに使用可能になります。

v テスト環境で使用できる書き込み可能スナップショット。実際に変更されたデータ用にのみストレージ・スペースが必要です。

v 書き込み可能スナップショットのスナップショットを取得することが可能

v スナップショット数またはボリュームのサイズに左右されないハイパフォーマンス

v スナップショットからボリュームまたはスナップショットへのリストア機能

スナップショットの整合性グループ複数のボリュームを 1 つの整合性グループに入れることにより、すべてのボリュームの整合性のあるポイント・イン・タイム・スナップショットを単一操作で簡単に作成できるようになります。

これは、複数のボリュームを同時に使用するため、同じ時点のそれらのボリュームすべての整合したスナップショットを必要とするアプリケーションには不可欠です。


ストレージ・プールストレージ・プールは、ボリュームおよびスナップショットのストレージ・リソースを管理するために使用されます。

管理上、IBM XIV Storage System のストレージ・スペースをいくつかのストレージ・プールに分割して、特定のアプリケーションまたは部門によるストレージ・スペースの使用量を制御することができます。

リモート・モニターと診断IBM XIV Storage System は、重要なシステム・イベントを E メールで IBM サポートに通知することができます。

この通知によって、IBM は、ただちにハードウェア障害を検出し、即時の対応および迅速な対処 (例えば、サービス担当員の派遣など) がとられることを保証します。さらに、IBM サポート担当員は、リモート・サポートを行って、保守およびサポートの両方の目的で診断資料を作成します。リモート・サポートはすべてお客様の許可に従って行われ、リモート・サポート・セッションは、チャレンジ応答セキュリティー・メカニズムによって保護されます。

SNMPIBM XIV Storage System MIB 用にサード・パーティーの SNMP ベース・モニター・ツールがサポートされています。

マルチパスホスト・インターフェース・モジュールのアクティビティーの基礎となる並行設計と、システムで達成される完全なデータ仮想化によって、徹底したマルチパス・アクセス・アルゴリズムが実装されています。

したがって、ホストがいくつかの独立したポートを使用してシステムに接続する時には、いずれかのホスト・インターフェース・モジュールから各ボリュームに直接アクセスすることができ、ホスト・インターフェース・アレイのさまざまなモジュールにわたり対話を確立する必要はありません。

自動イベント通知システムが SNMP トラップまたは E メール・メッセージによって適切なアラーム通知メッセージを自動的に送信するように設定できます。

ユーザーは、イベントを送信するためのさまざまなトリガー、およびイベントのタイプと重大度に応じた多方面の宛先を構成できます。また、ユーザーが受信を確認するまで通知を送信するようにシステムを構成することもできます。

GUI および CLI を使用した管理IBM XIV Storage System は、システムを構成し、モニターするための使いやすい直感的な GUI アプリケーションと CLI コマンドを備えています。


これらは、ホスト、ボリューム、整合性グループ、ストレージ・プール、スナップショット、ミラーリング関係、データ・マイグレーション、イベントなどを含む包括的なシステム管理機能を特長として備えています。

詳しくは、「IBM XIV 管理ツール Operations Guide」および「IBM XIV Storage

System XCLI User Manual」を参照してください。

外部レプリカ生成メカニズムIBM XIV Storage System が備えている外部レプリカ生成メカニズムとミラーリング・メカニズムは、内部レプリカ生成メカニズムおよびシステムの機能全体を拡張するものです。

これらの機能は、サイトを災害から保護し、実動が確実に続行されるようにします。ミラーリングは、ファイバー・チャネルまたは iSCSI のいずれを介して実行することも可能で、ホストとストレージ間のプロトコルはミラーリング・プロトコルとは無関係です。

アップグレード可能性IBM XIV Storage System は、6 個のモジュールしか搭載されていない部分搭載ラック・システムでも、15 個のモジュールが搭載されたラック・システムでも使用可能です。

部分搭載ラック・システムは、データ・モジュールおよびインターフェース・モジュールを追加することで、最大 15 個のモジュールが搭載されたラックにアップグレードすることが可能です。

システムは、ホット・フィックスの更新と同様に、中断を伴わないシステムのアップグレードをサポートします。


第 2 章接続

この章では、ストレージ・システムを内部的および外部的に接続する方法を説明します。

IP 接続およびイーサネット接続ストレージ・システムのさまざまな構成を紹介します。

ホスト接続ストレージ・システムとそのホストを接続する方法に関するさまざまなトピックを紹介します。

IBM Hyper-Scale Mobility およびデータ・マイグレーションについては、 141ページの『第 9 章 IBM Hyper-Scale Mobility』を参照してください。

IP 接続およびイーサネット接続

以下のトピックでは、定義できる各種のイーサネット・ポートと IP インターフェース、および IBM XIV Storage System 内で可能なさまざまな構成について、基本的な説明を記載します。

IBM XIV Storage System の IP 接続は、以下の機能を提供します。

v IP ネットワークまたはイーサネット・ネットワークを介して提供される iSCSI

サービス

v 管理のための通信

イーサネット・ポート

使用できる 3 つのタイプのイーサネット・ポートは次のとおりです。

iSCSI サービス・ポートこれらのポートは、IP またはイーサネット・サービスによる iSCSI に使用されます。完全装備のラックは、iSCSI サービス用の 6 つのイーサネット・ポートを用いて構成されます。これらのポートは、ユーザーの IP ネットワークに接続し、iSCSI ホストにコネクティビティーを提供します。iSCSI ポートは管理接続も受け入れることができます。

管理ポートこれらのポートは、発信 SNMP および SMTP 接続に使用されるだけでなく、IBM XIV コマンド行インターフェース (XCLI) および IBM XIV

Storage Management GUI の通信専用にされます。完全装備のラックには 3

つの管理ポートが含まれます。

フィールド技術員用ポートこれらのポートは、着信管理トラフィック専用です (XCLI と IBM XIV

Storage Management GUI の両方のアクセスに使用されます)。これらのポートは、フィールド技術員のラップトップ・コンピューター専用であり、ユーザーの IP ネットワークに接続してはなりません。


IPv6 認証IBM XIV Storage System では、このトピックで説明する IPv6 および IPSec テクノロジーの導入をサポートしています。

IBM XIV Storage System では、管理および VPN ポートに対してステートレス自動構成および完全 IPSec (IKE2、トランスポート、およびトンネル・モード) を使用した IPv6 をサポートしています。

非サポート対象

v 技術員用ノートブック・ポートに対して IPv6 はサポートされません。

v iSCSI ポートはサポートされません。

IPv6 を使用可能または使用不可に設定する

IBM XIV Storage System では、すぐに使用可能な IPv4 アドレスと IPv6 アドレスをサポートしています。この機能が使用可能になっている場合は、ステートレス自動構成も自動的に使用可能になり、システム・インターフェースで IPv6 を使用して作業できるようになります。これにより、DNS アドレスの検索時、システムはAAAA エントリーも検索します。

管理および VPN ポートへの接続を使用しているプログラムでは、IPv6 アドレスをサポートする必要があります。システムの各 IP インターフェースには、現在、静的 IPv4 アドレス、静的 IPv6 アドレス、ステートレス構成リンクおよびサイト・ローカル IPv6 アドレスなどの複数の IP アドレスが存在する可能性があります。各インターフェースに複数の IPv6 静的アドレスが割り当てられている場合、システムではインターフェースごとに 1 つのアドレスしかサポートしません。

IPv6 アドレス指定機能は、必要に応じて使用不可に設定することができます。

IPv6 CLI

ストレージ・システムでの IPV6 の使用は、以下のコマンドによって管理します。

ipinterface_enable_ipv6このコマンドは、システムでの IPv6 の使用を使用可能または使用不可に設定します。

ipinterface_updateこのコマンドは、IPv6 アドレスをシステム管理および VPN インターフェースに割り当てます (iSCSI インターフェースには割り当てません)。

ipinterface_listこのコマンドは、新しい「IPv6 アドレス」フィールドと「IPv6 ゲートウェイ」フィールドを組み込んでインターフェース・アドレスを表示します。

ipinterface_list_ipsこの新しいコマンドは、「アドレス・タイプ」フィールドの値を組み込みます。これらの値は、「静的 IPv4」、「静的 IPv6」、「グローバルIPv6」、「リンク・ローカル IPv6」、および「サイト・ローカル IPv6」です。


管理接続

管理接続は、以下の機能のために使用されます。

v IBM XIV コマンド行インターフェース (XCLI) から XCLI コマンドを実行する

v IBM XIV Storage Management GUI から IBM XIV Storage System を制御する

v イベント・アラートに関する E メール通知メッセージおよび SNMP トラップを送信する

モジュール障害が発生した場合の管理の冗長性を確保するために、IBM XIV Storage

System 管理機能には 3 つの異なる IP アドレスからアクセスできるようになっています。3 つの IP アドレスはそれぞれ異なるハードウェア・モジュールで処理されます。これらの種々の IP アドレスはユーザーには透過的で、管理機能はいずれの IP アドレスからも実行できます。これらのアドレスには、複数のクライアントから同時にアクセスできます。ユーザーが行う必要があるのは、特定のシステム用に定義される IP アドレスのセットに対して IBM XIV Storage Management GUI または XCLI を構成することだけです。

注: 管理 IP インターフェースはすべて同じサブネットに接続され、同じネットワーク・マスク、ゲートウェイ、および MTU を使用しなければなりません。

XCLI および IBM XIV Storage Management GUI による管理

IBM XIV Storage System 管理接続システムを使用すると、ユーザーは XCLI および IBM XIV Storage Management GUI の両方からシステムを管理できます。したがって、XCLI および IBM XIV Storage Management GUI は、iSCSI IP インターフェースを介してシステムを管理するように構成できます。XCLI および IBM XIV

Storage Management GUI による管理は、いずれも TCP ポート 7778 を介して実行されます。トラフィックはすべて Secure Sockets Layer (SSL) プロトコルによって暗号化されます。

システムが開始する IP 通信

IBM XIV Storage System は、IP 通信を開始して、必要に応じてイベント・アラートを送信することもできます。システムが開始する IP 通信には、次の 2 つのタイプがあります。

SMTP プロトコルを介した E メール通知の送信E メールは、E メール通知、および SMTP と SMS 間のゲートウェイを使用する SMS 通知の両方に使用されます。

SNMP トラップの送信

注: SMPT および SNMP 通信は、3 つの IP アドレスのいずれからも開始することができます。これは、ユーザーが開始する、XCLI および IBM

XIV Storage Management GUI とは異なります。したがって、3 つの IP インターフェースすべてを構成し、それらがネットワーク接続を確立しているかを検査することが重要です。

第 2 章接続 15

フィールド技術員用ポート

IBM XIV Storage System は、2 つのイーサネット・ポートをサポートします。これらのポートは以下の理由により専用ポートになります。

v フィールド技術員が使用します

v 初期システム構成です

v サービス担当員がお客様のネットワークに接続できない場合の直接接続です

v ラップトップ・コンピューターを使用して IBM XIV Storage System を直接管理

ラップトップ接続 - DHCP を使用した構成

予備のために 2 つのフィールド技術員用ポートが用意されています。これにより、フィールド技術員は常にラップトップを IBM XIV Storage System に接続できるようになります。これらの 2 つのポートは、動的ホスト構成プロトコル (DHCP) サーバーを使用します。 DHCP サーバーは、ユーザーのラップトップに自動的に IP

アドレスを割り当て、ラップトップを IBM XIV Storage System ネットワークに接続します。どのフィールド技術員用ポートに接続されたラップトップにも IP アドレスが割り当てられ、IBM XIV Storage Management GUI または IBM XIV コマンド行インターフェース (XCLI) は一般に、事前定義済み構成 direct-technician-port

を使用します。

注: 2 つのフィールド技術員用ラップトップ・ポートは、IBM XIV Storage System

との直接接続にのみ使用し、お客様のネットワークには決して接続しないでください。

ラップトップ接続 - DHCP を使用しない構成

技術員のラップトップが DHCP を使用して自動 IP 構成情報を受信するようにセットアップされていない場合は、以下のパラメーターを使用して、そのラップトップを定義する必要があります。

IP アドレス:14.10.202.1

ネットマスク:255.255.255.0

ゲートウェイ:なし

MTU:1536

フィールド技術員用ポートは、XCLI および IBM XIV Storage Management GUI の両方の通信を受け入れます。これらのポートからは、SNMP および SMTP アラートは送信されません。

注: フィールド技術員用ポートはそれぞれ異なるモジュールに接続されます。したがって、1 つのモジュールに障害が起こると、そのポートは作動不能になります。この状況が生じた場合は、ラップトップを 2 番目のポートに接続する必要があります。


構成ガイドラインの要約

出荷時には、IBM XIV Storage System は IP 管理構成が行われていません。したがって、システムを最初にセットアップするときに以下の手順を実行する必要があります。

v パッチ・パネル上のフィールド技術員用ラップトップ・ポートのいずれかに、ラップトップを接続します。

v 1 つ以上の管理 IP インターフェースの構成

v 技術員用ポートまたは構成済み IP インターフェースからの構成プロセスの続行

注: 3 つの管理 IP インターフェースをすべて定義し、3 つのインターフェースのすべてから発信 SNMP および SMTP 接続をテストすることが重要です。 dest_testコマンドは、特定のモジュール上の発信通知をテストするために使用できます。

ホスト・システム接続IBM XIV Storage System は、さまざまなオペレーティング・システムのホストに接続します。

IBM XIV Storage System は、ホスト接続キットおよび補完ユーティリティーのセットを使用してホストに接続します。

注: ホスト・システム接続という語はこれまでホスト接続またはマッピングと呼ばれていました。これらの用語の使用は廃止されました。

平衡トラフィック、および Single Point of Failure なしすべてのホスト・トラフィック (入出力) は、最大 6 個のインターフェース・モジュール (モジュール 4-9) を使用して実施されます。IBM XIV Storage System はすべてのシステム・モジュールにわたってトラフィックを分配しますが、ストレージ管理者は、ホスト入出力操作がさまざまなインターフェース・モジュール間で平等に分配されるようにする責任があります。

ワークロード・バランスは、ホスト・トラフィック・パターンの変更時に監視および検討する必要があります。IBM XIV Storage System は、着信ホスト・トラフィックのバランスを自動的に取りません。ストレージ管理者は、1 つの障害 (例えば、モジュールや HBA などで) により該当のマシンへのすべてのパスで障害が生じることがないように、ホスト接続が冗長性をもつ方法で、ホスト接続が重複して行われるようにする責任があります。さらに、ストレージ管理者は、ホスト・ワークロードがさまざまな接続およびインターフェース・モジュールにわたって適切に分散されるようにする責任があります。

動的速度適応IBM XIV Storage System は、ミラーリング・プロセス用の不十分な帯域幅および外部接続を処理するためのメカニズムを提供します。

ミラーリング・プロセスは、リモート・サイト上にローカル・サイトを複製します(本書の後ろの 57ページの『第 6 章同期リモート・ミラーリング』と 77ページの『第 7 章非同期リモート・ミラーリング』の各章を参照)。プロセスがこれを達

第 2 章接続 17

成するかどうかは、ローカル・ストレージ・システムとリモート・ストレージ・システムの間の帯域幅の可用性によって決まります。

ミラーリング・プロセスの同期速度属性は、正常なミラーリングに必要な帯域幅を決定します。この属性を手動で構成する場合、ユーザーは、ミラーリング・プロセス用の帯域幅の可用性を考慮に入れます。この場合、IBM XIV Storage System は、それ自体を使用可能な帯域幅に調整します。さらに、場合によっては帯域幅が十分でも外部入出力の待ち時間が原因でミラーリング・プロセスが着信入出力より遅れ、そのために、すでに実行された複製ジョブを繰り返し、最終的には、帯域幅が適切に割り振られた場合でも使用可能な帯域幅を十分に利用しないことになります。

IBM XIV Storage System は、入出力待ち時間を継続的に測定して入出力タイムアウトを回避します。過剰着信入出力は、サブミットできるまで事前にキューに入れられます。ミラーリング速度は、事前にキューに入れられた着信入出力の数に動的に適応し、ミラーリング・プロセスの円滑な操作を可能にします。

ホストへのボリュームの接続IBM XIV Storage System が名前によりボリュームおよびスナップショットを識別する一方で、ホストは、論理装置番号 (LUN) に従ってボリュームおよびスナップショットを識別します。

LUN は、システムのボリュームを登録済みホストに接続するときに使用する整数です。各ホストは、ストレージ・システム上の一部または全部のボリュームおよびスナップショットにアクセスすることができます (最大設定数まで)。アクセスされる各ボリュームまたはスナップショットは、LUN を使用してホストによって識別されます。

ホストごとに、LUN は 1 つのボリュームまたはスナップショットを示します。ただし、さまざまなホストは、同じ LUN を使用してさまざまなボリュームまたはスナップショットにアクセスすることができます。

LUN0 の除外LUN 0 を通常の LUN として使用しないでください。

LUN0 は他の LUN と同様にボリュームにマップすることができます。ただし、ボリュームが LUN0 にマップされない場合、HAK はこれを使用して LUN アレイをディスカバーします。したがって、LUN0 を通常の LUN として使用しないことをお勧めします。

拡張ホスト接続IBM XIV Storage System は、フレキシブルなホスト接続オプションを提供します。

以下のホスト接続オプションが選択可能です。

v 同じホスト上のさまざまなポートに対するさまざまなボリューム・マッピングの定義


v ファイバー・チャネル・ポートと iSCSI ポートの両方があるホストのサポート。これらの 2 つのプロトコルを一緒に使用して同じボリュームにアクセスすることはお勧めしませんが、以下の場合には、二重化構成が役立つ可能性があります。

– ホストをファイバー・チャネルから iSCSI に円滑にマイグレーションする方法として

– 同じホストから別々のボリュームにアクセスする方法として (ただし、異なるプロトコルを介して)

iSCSI ホストの CHAP 認証MS-CHAP 拡張機能により、非セキュア環境での IBM XIV Storage System に対するイニシエーター (ホスト) の認証が可能になります (逆もまた同様)。

CHAP サポートが有効になると、ホストは、IBM XIV Storage System によって安全に認証されます。これにより、認証済みのパーティーのみがホスト・ストレージ対話に関係していることを検査することで、全体のシステム・セキュリティーが強化されます。

定義

以下の定義は、認証手順に適用されます。

CHAP チャレンジ・ハンドシェーク認証プロトコル (Challenge Handshake

Authentication Protocol)

CHAP 認証イニシエーターがサブミットする機密ハッシュと、ターゲット上に保管されるそのイニシエーターの機密事項の計算済みハッシュとを比較することによる、ターゲットによる iSCSI イニシエーターの認証プロセス。

イニシエーターホスト。

一方向 (単一方向 CHAP)イニシエーターがターゲットによって認証される CHAP 認証。ただし、ターゲットがイニシエーターによって認証されることはありません。

サポートされる構成CHAP 認証タイプ

一方向 (単一方向) 認証方式。イニシエーター (ホスト) が IBM XIV

Storage System によって認証される必要があることを意味します。

MDS CHAP 認証は MDS ハッシュ・アルゴリズムを使用します。

アクセス有効範囲CHAP 認証済みイニシエーターは、一部のボリュームへのアクセスを制限する可能性があるマッピングによって IBM XIV Storage System へのアクセス権限が付与されます。

認証方式

IBM XIV Storage System は、以下の認証方式をサポートします。

第 2 章接続 19

None (デフォルト)この方式では、イニシエーターは IBM XIV Storage System によって認証されません。

CHAP (一方向)この方式では、イニシエーターは、関係のあるイニシエーターのサブミット済みハッシュに基づいて IBM XIV Storage System によって認証されます。このハッシュは、IBM XIV Storage System 上に保管されているイニシエーターの機密事項から計算されたハッシュと比較されます。

認証方式を None から CHAP に変更するには、ホストの認証が必要です。認証方式を CHAP から None に変更するには、認証は必要ありません。

RFC 3720 の順守

IBM XIV Storage System CHAP 認証は、 CHAP 要件を順守します。次の Web サイトを参照してください。http://tools.ietf.org/html/rfc3720

機密事項の長さ機密事項は、96 ビットから 128 ビットの間でなければなりません。この範囲外の長さの場合は、システムはコマンドの実行に失敗し、要件が満たされていないと応答します。

イニシエーターの機密事項の固有性イニシエーター (ホスト) の機密事項を定義または更新する際に、システムは、入力された機密事項のハッシュとシステムが保管する既存の機密事項を比較し、機密事項が固有のものであるかどうかを判別します。固有のものでない場合は、システムは警告をユーザーに表示しますが、コマンドは正常に完了します。

LUN マップへのホストのクラスター化ホストの管理を強化するために、IBM XIV Storage System は、複数のホストを一緒にクラスター化することを許可します。この場合、クラスター化されたホストには同一マッピングが提供されます。LUN ID へのボリュームのマッピングはクラスターごとに定義され、クラスター内のすべてのホストに適用されます。

クラスターへのホストの追加およびクラスターからのホストの除去は、以下のように行われます。


http://tools.ietf.org/html/rfc3720

クラスターへのホストの追加クラスターへのホストの追加は、ホストがクラスターに追加されて LUN に接続される直接的なアクションです。

v ホストのマッピングをクラスターのマッピングに変更。

v クラスターのマッピングを、新たに追加されたホストのマッピングと同一になるように変更。

クラスターからのホストの除去ホストはクラスターから解除され、LUN への接続は維持されます。

v ホストのマッピングは、クラスターのマッピングと引き続き同一のままです。

v マッピング定義は、ホストの元のマッピング (ホストがクラスターに追加される前に実施されていたマッピング) に復帰しません。

v ホストのマッピングは変更できます。

注:

v IBM XIV Storage System は、同じクラスターのすべてのホストに対して同じマッピングを定義します。クラスターの階層は維持されません。

v ボリュームにすでにマップされている LUN へのボリュームのマッピング。

図 3. ボリューム、LUN、およびクラスター化されたホスト

第 2 章接続 21

v すでにマップされているボリュームの別の LUN へのマッピング。

ボリューム・マッピングの例外IBM XIV Storage System では、クラスターに追加されているホストにクラスターのマッピングを関連付けることができます。このシステムでは、このようなホストに

図 4. すでにマップされている LUN にボリュームをマップすることはできません。

図 5. ボリュームがすでにマップされている場合、そのボリュームを LUN にマップすることはできません。


ついてのマッピングの例外も簡単に指定できます。こうした例外は、クラスターに定義されていないマッピングがホストに必要となるケース (例えば、SAN からブートする場合など) に対応するために認められます。

クラスター内のホストへのボリュームのマッピング既にマップされているボリュームまたは LUN をマップすることはできません。

例えば、ホスト host1 がクラスター cluster1 に所属しており、このクラスターには lun1 に対するボリューム vol1 のマッピングがあるとします。

1. vol1 と lun1 への host1 のマッピングは失敗します。このボリュームとLUN は両方とも既にマップされているためです。

2. vol2 と lun1 への host1 のマッピングは失敗します。この LUN が既にマップされているためです。

3. vol1 と lun2 への host1 のマッピングは失敗します。このボリュームが既にマップされているためです。

4. vol2 と lun2 への host1 のマッピングは成功します。ただし、そのマッピングはホスト固有のものであるという警告が出されます。

ホスト/クラスターにマップされているボリュームのリストクラスターに含まれるマップ済みホストがリストされます (つまり、このリストはクラスター・レベルではなくホスト・レベルのリストです)。

マッピングのリストホストごとに、それがクラスターに所属しているかどうかがこのリストに示されます。

クラスターへのホストの追加ホストの前のマッピングは削除されます。そのホストに関連するマッピングはそのクラスターのマッピングのみであるという事実を反映するためです。

クラスターからのホストの除去ホストは前のマッピングを再取得します。

VMWare 拡張操作のサポートIBM XIV Storage System は、VMWare ESX Server 4 (VMWare vStorage API) で導入された VMWare 拡張操作をサポートします。

VMWare 拡張操作の目的は、VMWare サーバーからストレージ・システムに操作をオフロードすることです。 IBM XIV Storage System は、以下の操作をサポートします。

完全コピーESX サーバーへの書き込みを行わずに、1 つのストレージ・アレイから別のストレージ・アレイにデータをコピーする機能。

ブロックのゼロ化ブロックを解放する手段として、ブロックをすべてゼロにリセットし、プロビジョニングに使用できるようにします。

ハードウェア支援によるロックアトミック・コマンド内でのボリュームのロックを許可します。

第 2 章接続 23

ゼロの書き込みWrite Zeroes コマンドにより、ゼロを送信することなく大規模なストレージ域をゼロにリセットすることができます。

新規 VM が作成されると必ず、ESX サーバーはゼロで満たされた大規模なファイルを作成して、そのファイルをストレージ・システムに送信します。 Write Zeroes

コマンドは、ゼロを送信することなく大規模なストレージ域をゼロにリセットするようにストレージ・コントローラーに指示するための手段です。この目的を達成するには、VMWare の汎用ドライバーと独自のプラグインの両方で WRITE SAME 16

コマンドを使用します。

この方式は、ゼロで満たされた大規模なファイルをホストが作成および送信していた以前の方式とは異なります。

注: ゼロの書き込み操作は、ストレージ・スペースを割り振ることを目的としていないため、シン・プロビジョニング操作ではありません。

ハードウェア支援によるロックハードウェア支援によるロック機能は、VMWare の新しい COMPARE AND

WRITE コマンドを使用して、単一の操作でボリュームのメタデータの読み取りおよび書き込みを行います。

VMWare の COMPARE AND WRITE を使用して SCSI2 予約メカニズムを置き換えると、IBM XIV Storage System は、メタデータ固有のファイルを高速で変更する手段を提供し、メタデータの変更中にすべてのファイルをロックする必要性も除去します。

既存の VMWare SCSI2 予約メカニズムは、VM サーバーがボリュームのメタデータを処理する管理操作を実行する際には必ず使用されます。この方式には、いくつかの欠点があります。その中でも、すべてのボリュームへのアクセス全体をロックすることが必須であることは、他のすべてのサーバーが自身のファイルにアクセスできなくなることを意味します。さらに、SCSI2 予約メカニズムは、ロックを行うために少なくとも 4 つの SCSI 操作 (予約、読み取り、書き込み、解放) の実行を必要とします。

COMPARE AND WRITE (SBC-3、リビジョン 22) と呼ばれる新しい SCSI コマンドを導入することで、他のボリュームのロックを必要としないアトミック操作としてボリュームに表示される、より高速なメカニズムを使用できるようになります。

注: IBM XIV Storage System は、単一ブロックの COMPARE AND WRITE コマンドのみをサポートします。この制限は、VMWare に従って実施されます。

後方互換性

IBM XIV Storage System は、次のように古いバージョンの ESX との互換性を維持しています。

v 各ボリュームは、SCSI 予約を引き続きサポートしているため、既存のホストに接続することが可能です。


v 既存の SCSI 予約メカニズムによってボリュームがブロックされると、必ずCOMPARE AND WRITE コマンドが着信できなくなります。

v 管理者は、ハードウェア支援によるロック機能によって提供されるパフォーマンスの向上の利点をフルに活用するために、既存の VM サーバーを段階的に減らすことが期待されます。

高速コピー高速コピー機能を使用すると、ESX サーバーを介さずにストレージ・システム上でVM のクローンを作成することが可能になります。

高速コピー機能は、ホストから READ および WRITE 要求を発行するのではなく、ストレージ・システム内部でデータのコピーを行うことで、VM のクローン作成操作を高速化します。この実装環境では、ホストとストレージ・システム間の通信を削減することで、パフォーマンスが大幅に向上します。代わりに、この機能はストレージ・システム内で非常に大きな帯域幅を使用します。

QoS パフォーマンス・クラスIBM XIV Storage System では、重要なアプリケーションにより高い入出力速度を割り振ることができます。

QoS パフォーマンス・クラス機能を使用すると、ホストの優先順位付けを行うことによって、より重要とみなされるアプリケーションにより多くの入出力を割り振ることができます。ストレージ・システムに接続されている各ホストは 1 つのグループに関連付けられます。このグループは速度制限を属性として持ちます。

この制限属性およびホストとグループの関連付けにより、特定のホストの入出力速度は以下のように制限されます。

v ホストの速度制限グループは他のホストのグループ化形態 (例えば、クラスター)

とは関係ありません。

v グループは、無制限数のホストに関連付けることができます。

v デフォルトでは、ホストはいずれのホスト速度制限グループにも関連付けられません。

最大帯域幅の制限属性

ホストの速度制限グループには最大帯域幅制限属性があり、これは 1 秒当たりのブロック数で表されます。この数は次のいずれかに設定できます。

v min_rate_limit_bandwidth_blocks_per_sec からmax_rate_limit_bandwidth_blocks_per_sec (いずれの値もストレージ・システムの構成から得られます) までの値。

v 帯域幅が無制限の場合はゼロ (0) です。

コマンド

ホストの速度制限は、以下のコマンドを使用して実施されます。

パフォーマンス・クラス・レベル

第 2 章接続 25

perf_class_createパフォーマンス・クラスを作成します。

perf_class_deleteパフォーマンス・クラスを削除します。

perf_class_renameパフォーマンス・クラスを名前変更します。

perf_class_listパフォーマンス・クラスおよびそれらのホストをリストします。

ホスト・レベル

perf_class_add_hostホストをグループに追加します。

perf_class_remove_hostホストをグループから削除します。

perf_class_list_hostsグループのホストをリストします。

perf_class_set_rateグループの速度制限を設定します。

perf_class_get_rateグループごとに速度制限値を表示します。

コール・ホーム・コンタクト・リストの更新お客様と連絡を取るように IBM に要求するサービス問題が生じた場合に、該当の担当者に通知がなされるようにするために、コンタクト・リストが最新の状態を維持することが重要です。

コンタクト・リストの更新は、XIV GUI を使用して行われます。適切な変更を行うための手順については、XIV GUI を参照してください。

ホスト・システム接続コマンドIBM XIV Storage System は、ホスト・コマンド、クラスター・コマンド、およびマッピング・コマンドを使用して、ホスト接続を管理します。

27ページの表 2 および 28ページの図 6 は、使用可能なコマンド・セットをリストしています。


表 2. ホスト接続に使用されるコマンド

コマンド・セットコマンド

ホスト・コマンドホストの追加と管理、およびホストへのポートの提供には、以下のコマンドが使用可能です。

v host_define

v host_add_port

v host_remove_port

v host_update

v host_list

v host_rename

v host_delete

クラスター・コマンドクラスターの作成と管理、およびクラスターへのホストの投入には、以下のコマンドが使用可能です。

v cluster_create

v cluster_add_host

v cluster_remove_host

v cluster_list

v cluster_rename

v cluster_delete

マッピング・コマンドマップの作成と管理、およびマップへのホストの投入には、以下のコマンドが使用可能です。

v map_vol

v unmap_vol

v mapping_list

v vol_mapping_list

その他現在、HP-UX ホストには以下のコマンドにより提供される特別な接続方式が必要です。

v special_type_set

第 2 章接続 27

図 6. ホスト・システム接続コマンド


第 3 章ボリュームおよびスナップショットの概要

ボリュームは、IBM XIV Storage System 内の基本ストレージ・データ装置です。ボリュームのスナップショットを作成できます。ボリュームのスナップショットは、特定の時点におけるそのボリューム上のデータを表します。複数のボリュームをグループ化して、整合性グループおよびストレージ・プールと呼ばれる、より大きなセットに入れることもできます。

基本的な階層は、以下のように説明できます。

v 1 つのボリュームの複数のスナップショットを作成できる。

v 1 つのボリュームは 1 つだけの整合性グループに所属できる。

v 1 つのボリュームは常に 1 つだけのストレージ・プールの一部である。

v 1 つの整合性グループ内のすべてのボリュームは、同じストレージ・プールに属している必要がある。

以下のサブセクションでは、ボリュームおよびスナップショットについて具体的に説明します。

ボリュームのライフサイクルボリュームは、ホストに論理ディスクとして提供される基本のデータ・コンテナーです。

「ボリューム」という用語は、ボリュームあるいはスナップショットを表すエンティティーに対して使用される場合があります。ホストは、ボリュームとスナップショットを同じプロトコルを介して認識します。必要な場合は、ボリュームをスナップショットのボリュームと明確に区別するために「マスター・ボリューム」という用語を使用します。

各ボリュームには、2 つの構成属性 (名前とサイズ) があります。ボリューム名は、IBM XIV Storage System の内部に存在する英数字ストリングで、GUI および CLI

コマンドの両方に対してボリュームを識別するために使用します。ボリューム名は、SCSI プロトコルとは無関係です。ボリューム・サイズは、ホストが認識するボリューム内のブロック数を表します。

ボリュームは、以下のコマンドで管理することができます。

Create 指定する属性を使用してボリュームを定義します。

Resize ボリュームの仮想容量を変更します。詳しくは、 52ページの『シン・プロビジョニング』を参照してください。

Copy ボリュームを既存のボリュームまたは新規ボリュームにコピーします。

Formatボリュームを消去します。

Lock ホストがボリュームに書き込みを行うことを防止します。


Unlockホストがボリュームに書き込みを行えるようにします。

Rename以前に定義されたすべてのボリューム属性を維持したまま、ボリュームの名前を変更します。

Delete ボリュームを削除します。以下の『即時スペース再利用』を参照してください。

以下の照会コマンドにより、ボリュームがリストされます。

Listing Volumesこのコマンドは、すべてのボリューム、あるいは指定したボリュームまたはプールに一致する特定のボリュームの詳細をリストします。

Finding a Volume Based on a SCSI Serial Numberこのコマンドは、その SCSI シリアル番号に一致するボリューム名を表示します。

これらのコマンドは、IBM XIV Storage Management GUI および IBM XIV コマンド行インターフェース (XCLI) のどちらを使用する場合にも使用可能です。XCLI

で発行できるコマンドについては、「IBM XIV Storage System XCLI User Manual」を参照してください。

図 7 は、ボリュームに対して発行できるコマンドを示しています。

I/O I/O I/O I/O I/O I/O I/O I/O I/O I/O I/O I/O I/O I/O I/O I/O I/O I/O I/O

��

ボリューム

ボリューム

Copy

フォーマットロックアンロック��

/

��サイズ

: Volume_1

: 171GB

xiv

po

ge

n3

00

8

図 7. ボリューム操作


Symantec Storage Foundation のシン・レクラメーション(Thin Reclamation) 機能のサポート

IBM XIV Storage System は、Symantec Storage Foundation のシン・レクラメーション (Thin Reclamation) API をサポートします。

IBM XIV Storage System は、即時スペース再利用機能を特長として備え、既存のIBM XIV シン・プロビジョニング機能を拡張します。 IBM XIV のユーザーは、新しい即時スペース再利用機能を使用して、容量使用率を最適化し、サポートするアプリケーションがシン・プロビジョニングが実施された XIV ボリューム内の未使用のファイル・システム・スペースを即時に再取得できるようにして、コスト節減を可能にします。

IBM XIV Storage System は、即時スペース再利用機能を提供する最初のハイエンド・ストレージ・システムの 1 つです。この新しい即時機能は、Symantec のようなサード・パーティー製品ベンダーのシン・レクラメーション (Thin Reclamation)

機能を IBM XIV Storage System とインターロックして、未使用のスペースを即時かつ自動的に検出し、それをただちに汎用ストレージ・プールに再割り当てし、再利用できるようにします。

これにより、Symantec 製のシン・プロビジョニング認識 (アウェア) の Veritas File

System (VxFS) との統合が可能になり、これは最終的には IBM XIV Storage System

のシン・プロビジョニング認識機能 (アウェアネス) を活用して、ストレージ使用率の大幅な節約を達成できるようにします。

例えば、ユーザーがデータを削除すると、システム管理者はレクラメーション・プロセスを開始することができ、そのプロセスでは IBM XIV Storage System が未使用ブロックを解放し、これらのブロックが使用可能なストレージ・プールに再利用されるようにします。

即時スペース再利用では、以下のオブジェクトのスペース再利用はサポートされません。

v ミラーリングされたボリューム

v スナップショットが取られたボリューム

v スナップショット

スナップショットスナップショットは、特定時点における、ある 1 つのソース・ボリュームの内容を反映する論理ボリュームのことです。

IBM XIV Storage System は、パフォーマンスに影響せずに事実上無制限の数のボリューム・コピーを作成する、拡張スナップショット・メカニズムを使用します。スナップショットの作成と管理は内部ポインターのメカニズムに基づいて行われます。このメカニズムにより、単一データ・コピー内の変更されていないすべての部分をマスター・ボリュームとそのスナップショットが使用できます。

このアプローチは Redirect-on-Write (ROW) とも呼ばれ、より一般的なコピー・オン・ライト (COW) を改善した方法です。これにより入出力アクションが削減されるため、ストレージ使用量の削減につながります。

第 3 章ボリュームおよびスナップショットの概要 31

IBM XIV スナップショットでは、ソース・ボリューム (またはソース・スナップショット) が変更されるまではそのスナップショットによってストレージ容量は消費されません。

Redirect-on-WriteIBM XIV Storage System は Redirect-on-Write (ROW) メカニズムを使用します。

以下の項目は、マスター・ボリュームに書き込み要求が送信されるときに ROW を使用する場合の特性です。

1. 元々マスター・ボリュームに関連付けられているデータは、そのまま残ります。

2. 新規データはディスク上の別の場所に書き込まれます。

3. 書き込み要求が完了し、確認応答が発行されたら、元のデータはスナップショットに関連付けられ、新しく作成されたデータはマスター・ボリュームに関連付けられます。

従来のコピー・オン・ライト方式とは対照的に、Redirect-on-Write ではスナップショットを取得する処理に伴う実際のデータ・アクティビティーが大幅に削減されます。さらに、書き込み要求の対象となるデータのサイズがシステムのスロット・サイズと等しい場合、データのコピーは一切不要になります。書き込み要求のデータ・サイズがシステムのスロット・サイズより小さい場合でも、コピー処理は、標準的なコピー・オン・ライト・アプローチの場合よりはるかに少なくなります。

以下の Redirect-on-Write プロセスの例では、ボリュームとそのデータ、およびこのデータへのポインターが表示されます。

スナップショットを取得するときは、最初に新しいヘッダーが書き込まれます。

ボリューム

データ

ポインター

xiv

pogen3009

図 8. Redirect-on-Write プロセス: ボリュームのデータおよびポインター


新規データはディスク上の別の任意の場所に書き込まれ、既存のデータのコピーは不要です。

スナップショットは古いデータを指すのに対して、ボリュームは新規データを指します (データが入出力によって更新され続けている間、データは新規と見なされます)。

ボリューム


xiv

pogen3010

図 9. Redirect-on-Write プロセス: スナップショットを取得するときは、ヘッダーが最初に書き込まれます。

#$データ

ボリューム


xiv

pogen3011

図 10. Redirect-on-Write プロセス: 新規データが書き込まれます。


スナップショット・メカニズムの最初に設定されるメタデータは、コピー対象のボリュームのサイズから独立しています。このアプローチを使用して、ユーザーは以下のような重要目標を達成できます。

継続的なバックアップスナップショットを取得する間、継続的なデータ保護 (CDP) と同様の頻度でボリュームのバックアップ・コピーが作成されます。ボリューム・レベルとファイル・レベルの両方で論理データが破損した場合、実際に、どの特定時点へも簡単にボリュームを即時リストアできます。

生産性スナップショット・メカニズムにより、データ・マイニング、テスト、および外部バックアップのためのボリュームの短期または長期コピーを瞬時かつ簡単に作成できる手段が得られます。

ストレージ使用率IBM XIV Storage System でのボリュームとそのスナップショットへのスペース割り振りは、スナップショットを取得しても実際に追加スペースが必要になるのはボリュームへの書き込みが行われるときである、という観点で行われます。

ボリュームへの実際の書き込みが行われない限り、スナップショットには実際のスペースは必要ありません。ただし、アプリケーションによっては、スナップショットを取得すると必ずボリュームへの書き込みを行うものがあります。このようなボリュームへの書き込みでは、その新しいスナップショットへのスペースの割り振りが直ちに必要になります。したがって、これらのアプリケーションのスペース使用効率は他のアプリケーションより低くなります。

スナップショットの自動削除優先順位スナップショットは、スナップショットが自動的に削除される順序を制御するための自動削除優先順位に関連付けられます。

ボリューム・スナップショットを取得すると、ボリュームまたはそのスナップショットで変更されるデータの量に従って、ストレージ・スペースが徐々にいっぱいになります。最大ストレージ容量に達したときにスペースを解放するために、システムは、自動削除優先順位を参照して、スナップショットを削除する順序を決定する

ボリュームは#$データを'す

ボリューム


)いデータはそのまま.る

xiv

pogen3012

図 11. Redirect-on-Write プロセス: スナップショットは古いデータを指すのに対して、ボリュームは新規データを指します。


ことができます。各スナップショットが同じ優先順位の場合は、最初に作成されたスナップショットが最初に削除されます。

スナップショット名および関連スナップショットは、ソース・ボリュームからも、ソース・スナップショットからも取得することができます。スナップショットの名前は、作成時にシステムによって自動的に割り当てられる場合、またはスナップショットを作成する XCLI コマンドのパラメーターとして指定する場合があります。スナップショットの自動生成名は、そのボリューム名およびシリアル番号から派生します。以下はスナップショット名の例です。

MASTERVOL.snapshot_XXXXXNewDB-server2.snapshot_00597

パラメーター説明例

MASTERVOL ボリュームの名前。 NewDB-server2

XXXXX 5 桁の、ゼロで埋め込まれたスナップショット番号。

00597

スナップショットのライフサイクルスナップショットの役割がそのライフサイクルを決定します。

36ページの図 12 にスナップショットのライフサイクルを示します。


スナップショットには以下の操作を適用できます。

Create スナップショットを作成します (すなわち、スナップショットを取得します)。

復元ボリュームにスナップショットをコピーし戻します。スナップショットの主な機能は、ボリュームを復元する機能です。

アンロックスナップショットを書き込み可能にするためにアンロックし、状況を「変更済み」に設定します。アンロックしたスナップショットを再びロックすると、それ以降の書き込みはできませんが、状況は「変更済み」から変更されません。

複製スナップショットを複製します。スナップショットを無限に作成できるボリュームと同様に、スナップショット自体を複製することが可能です。

スナップショットのスナップショット書き込み先のスナップショットのバックアップを作成します。書き込み可能なスナップショットのスナップショットを取得する操作は、ボリュームのスナップショットを取得する場合と類似しています。

スナップショットの上書き特定のスナップショットをボリュームの内容によって上書きします。

Delete スナップショットを削除します。

ボリューム

xiv

po

ge

n3

01

3

I/O I/O I/OI/O ボリュームボリュームボリュームI/Oはオーバーライドされた

I/O I/O I/O

��: Volume_1

スナップショットの�� オーバーライド

スナップショットスナップショットスナップショットスナップショットI/O I/O I/O I/O I/O I/O

78

Unlock

9: スナップショットのスナップショット

��ロック;<=>

: Volume_1.snapshot_00001: 2008-08-13 15:22

: Yes: 1

��: Volume_1.snapshot_00002

ロック: No


��ロック;<=>

: Volume_1.snapshot_00004: 2008-08-13 15:26

: Yes: 1

スナップショットスナップショット

?@

図 12. スナップショットのライフサイクル


スナップショットの作成最初に、ボリュームのスナップショットがとられます。システムはボリュームへのポインターを作成するので、スナップショットは即時に作成されたものとみなされます。これは、ごくわずかな時間で完了するアトミック・プロシージャーです。この時点で、ボリュームに関連付けられるすべてのデータ部分も、スナップショットに関連付けられます。

あとで、ボリュームまたはスナップショットから特定のデータ部分を読み取る要求が届くと、そのデータの同じ単一物理コピーから読み取りを行います。

ボリュームのライフサイクルを通して、ボリュームに関連付けられているデータは、システムの進行中の操作の一環として連続的に変更されます。マスター・ボリューム上のデータ部分を変更する要求が届くと必ず、元のデータのコピーが作成され、スナップショットと関連付けられます。そのときに限り、ボリュームは変更されます。このように、スナップショットが取得されるときに元々ボリュームに関連付けられているデータは、スナップショットと関連付けられ、変更前のデータの状態を効果的に反映します。

スナップショットのロックとアンロック最初にスナップショットはロック状態で作成されます。これは、データまたはサイズに関するいかなる変更も防ぎ、内容の読み取りのみを可能にする状態です。これは、イメージまたはイメージ・スナップショットと呼ばれ、スナップショットが作成された時のマスター・ボリュームの正確なレプリカを表します。

スナップショットは作成された後でアンロックすることができます。スナップショットが最初にアンロックされる時に、システムは、不可逆プロシージャーを開始します。このプロシージャーにより、スナップショットは、すべての変更操作に関して通常のボリュームと同様に振る舞う状態になります。特に、スナップショットに対して書き込み要求を可能にします。この状態は、システムによって即時に設定され、変更が行われなかった場合でも、そのスナップショットを永久変更済み状況として示します。変更済みスナップショットはもうイメージ・スナップショットではありません。

アンロックされたスナップショットは、ホストでは、その他の書き込み可能ボリュームとして認識されます。アンロック・スナップショットの内容を変更することができますが、物理ストレージ・スペースは変更のためにのみ使用されます。また、アンロック・スナップショットはサイズ変更することもできます。

マスター・ボリュームもロックおよびアンロックを行うことができます。ロックされたマスター・ボリュームは、ホストからの書き込みコマンドを受け入れることはできません。また、ロックされたボリュームのサイズを変更することはできません。

イメージ・スナップショットの複製ユーザーは、既存のスナップショットを複製して新規スナップショットを作成することができます。複製スナップショットはソース・スナップショットと同一のものです。新規スナップショットは、既存のスナップショットのマスター・ボリュームに関連付けられます。さらに、新規スナップショットは、ソース・スナップショットがとられたまさにその時にその新規スナップショットがとられたものとして表示


されます。アンロックされたことがないイメージ・スナップショットの場合、複製スナップショットには、複製作成日ではなく元のスナップショットとまったく同じ作成日が付与されます。

この機能を使用して、ユーザーは、バックアップ目的でスナップショットの 2 つ以上の同一コピーを作成することができます。また、マスター・ボリュームの未利用バックアップとしてのスナップショットの使用、またはスナップショットから復元する能力を犠牲にせずにそのいずれかのコピーに対して変更操作を行うことができます。

スナップショットのスナップショットアンロック機能を使用して変更されたスナップショットを複製する場合、生成されたスナップショットは、実際にはスナップショットのスナップショットです。新たに作成されたスナップショットの作成時刻はコマンドが発行された時刻であり、その内容は作成時刻のソース・スナップショットの内容を反映します。

新規スナップショットは、作成後にマスター・ボリュームの別のスナップショットとして表示されます。

ボリュームおよびスナップショットの復元ユーザーは復元操作を行うことで、マスター・ボリュームのデータを、そのロックされた任意のスナップショットから瞬時にリカバリーできます。

ボリュームの復元

ボリュームは、その任意のスナップショット (ロック、アンロックを問わず) から復元できます。復元を実行すると、選択したスナップショットがボリュームに複製されます。この操作の結果、マスター・ボリュームはそれが復元されたスナップショットの正確なレプリカになります。他のスナップショットはすべて (新旧を問わず)

変更されないままであり、さらなる復元操作に使用できます。ボリュームは、それが書き込まれた先のスナップショットから復元することもできます。 39ページの図 13 は、ボリュームが 3 つの異なるスナップショットから復元される様子を示しています。


スナップショットの復元

スナップショット自体も別のスナップショットから復元できます。復元されたスナップショットは、その名前やその他の属性を保持します。ホストの観点から見ると、このように復元されたスナップショットは、スナップショットのすべての内容が他の内容によって瞬時に置き換えられたものと見なされます。 40ページの図 14

は、スナップショットが 2 つの異なるスナップショットから復元される様子を示しています。

xiv

po

ge

n3

01

4

ボリューム I/O I/O I/O I/O I/O I/O I/O I/O I/O I/O I/OI/O I/O ボリューム







ボリュームの78

?@

図 13. ボリュームの復元


フル・ボリューム・コピーフル・ボリューム・コピーは、既存ボリュームに上書きして作成され、作成時点では論理的にソース・ボリュームと同じものになります。

コピーが作成されると、両ボリュームは互いに独立したボリュームになります。ホストから、いずれのボリュームにも書き込みを行うことができ、もう一方のボリュームはその影響を受けません。これは、書き込み可能 (アンロック) スナップショットの作成にやや似ていますが、以下の違いと類似点があります。

作成時間と可用性フル・ボリューム・コピーとスナップショットの作成はいずれもほとんど瞬時に起こります。また、新しいスナップショットおよびボリュームは両方ともただちにホストで使用可能になります。これは、作成時に、コピー操作のソースと宛先にまったく同じデータが含まれていることと同じ物理ストレージを共有しているためです。

コピー操作の単一性フル・ボリューム・コピーは、既存ボリュームへの単一コピー操作として実

xiv

pogen3015


スナップショットの78

?@

ボリューム I/O I/O I/O I/O I/O I/O I/O I/O I/O I/O I/OI/O I/O

スナップショットスナップショット



I/O I/O I/O

図 14. スナップショットの復元


施され、元の内容と場合によってはサイズも上書きします。ボリューム・コピーの既存のターゲットをホストにマップすることができます。ホストから見ると、そのボリュームの内容が単一トランザクション内で変更されることになります。一方、新しい書き込み可能スナップショットの作成は、ホストにマップされるべき新規オブジェクトを作成します。

スペース割り振りフル・ボリューム・コピーでは、コピー時に、ターゲット・ボリュームに必要な全スペースが予約されます。ターゲット・ボリュームが入るストレージ・プールに必要なだけの容量を割り振ることができない場合、操作は失敗に終わり、その影響はありません。これは書き込み可能スナップショットとの本質的な違いです。

スナップショットの取得とコピーされたボリュームのミラーリングフル・ボリューム・コピーのターゲットはマスター・ボリュームです。このマスター・ボリュームは、後でスナップショットをとったりミラーを作成したりするためのソースとして使用できます。ただし、コピー時には、ターゲット・ボリュームのスナップショットの取得もリモート・ミラーの作成も許可されません。

Redirect-on-write の実装フル・ボリューム・コピーと書き込み可能スナップショットのいずれにおいても、1 つのボリュームが変更されている間は、他のボリュームがオリジナル・データを維持するように redirect-on-write 操作によって確実に分割されます。

パフォーマンスフル・ボリューム・コピーでは、書き込み可能スナップショットと異なり、入出力操作が実行されない場合でもコピー・プロセスはバックグラウンドで実行されます。ある程度の時間、2 つのボリュームは、同じ論理コンテンツを含んでいたとしても、異なるデータ・コピーを使用することになります。つまり、初回のコピーが完了する前にのみ、書き込みの redirect-on-write オーバーヘッドが生じます。この初回のコピーの後では、追加のオーバーヘッドは生じません。

可用性フル・ボリューム・コピーは、異なるストレージ・プール内のソース・ボリュームとターゲット・ボリュームで実行することができます。

スナップショットおよびスナップショット・グループのフォーマット

この操作を行うと、ホストへのマッピングを維持しながら、スナップショット (またはスナップショット・グループ) の内容が削除されます。

フォーマットの目的は、スナップショット ID および LUN ID を維持しながら、お客様が自分のボリュームをスナップショットによってバックアップできるようにすることです。ボリュームごとに複数のスナップショットをフォーマットできます。


読む必要がある参照項目

このトピックで言及する概念の一部については、この章および本書の後の章で紹介されます。これらのトピックについて理解するには、以下の参照項目リストをご覧ください。

スナップショット35ページの『スナップショットのライフサイクル』

スナップショット・グループ47ページの『スナップショット・グループのライフサイクル』

ホストへの接続17ページの『ホスト・システム接続』

フォーマット操作の結果は、以下のようになりますv フォーマットされたスナップショットは読み取り専用です。

v フォーマット操作はパフォーマンスに影響しません。

v フォーマットされたスナップショットはスペースを消費しません。

v フォーマットされたスナップショットからの読み取りは、常にゼロを返します。

v これはオーバーライド可能です。

v これは削除可能です。

v その削除優先順位は変更可能です。

制限アンロック不可

フォーマットされたスナップショットは読み取り専用であり、アンロックできません。

ボリュームの復元不可フォーマットされたスナップショットが属するボリュームを、そのスナップショットから復元することはできません。

別のスナップショットからの復元不可フォーマットされたスナップショットは別のスナップショットから復元できません。

複製不可フォーマットされたスナップショットは複製できません。

再フォーマット不可フォーマットされたスナップショットは再度フォーマットできません。

ボリューム・コピー不可フォーマットされたスナップショットは、ボリューム・コピーのコピー元として使用できません。

サイズ変更不可フォーマットされたスナップショットはサイズ変更できません。

ユース・ケース1. バックアップする LUN ごとにスナップショットを作成し、それをホストにマウントします。


2. この LUN をバックアップするようにホストを構成します。

3. スナップショットをフォーマットします。

4. スナップショットを再作成します。LUN ID、スナップショット ID、およびマッピングは維持されます。

他の XIV 操作に関連する制限

以下のタイプのスナップショットはフォーマットできません。

内部スナップショット内部スナップショットのフォーマットは、そのスナップショットが含まれるプロセスを妨害するため禁止されています。

同期ジョブに含まれるスナップショット同期ジョブに含まれるスナップショットのフォーマットは、その同期ジョブが意味を失うため禁止されています。

スナップショット・グループに含まれるスナップショットスナップショット・グループに含まれるスナップショットは 1 つの個別スナップショットとして扱うことはできません。

スナップショット・グループの制限スナップショットのフォーマットに関するすべての制限は、スナップショット・グループのフォーマット操作に適用されます。

電子ライセンスの受諾ストレージ・システムの電子ライセンスは、ボリュームの作成前に受諾する必要があります。

IBM XIV Storage System により、ユーザーは、MFG (ご使用条件) をクリックして電子的に受諾することができます。ライセンスの受諾は、システム上のボリュームの作成にとって前提条件です。

受諾は、GUI と CLI の両方から可能です。関連 CLI コマンド:

elicense_acceptライセンスの受諾を許可します。

elicense_status_getライセンスがすでに受諾されているかどうかを指示します。

elicense_blob_getライセンス・テキストを戻します。


第 4 章整合性グループの概要

整合性グループは、複数のボリュームの同時スナップショットを取得するために使用できるため、一群のグループの整合コピーが確保されます。

同期化されたスナップショット・セットの作成は、複数のボリュームを同時に使用するアプリケーションには特に重要です。標準的な例はデータベース・アプリケーションです。この場合、データベースおよびトランザクション・ログはさまざまなストレージ・ボリューム上に常駐しますが、そのすべてのスナップショットは同じ時点で取得する必要があります。

この章は、以下のセクションで構成されています。

整合性グループの作成整合性グループは空の状態で作成され、ボリュームがあとでこれらの整合性グループに追加されます。

整合性グループは、複数のボリュームの管理ユニットであり、複数のボリュームの同時スナップショット生成、ボリューム・グループのミラーリング、およびボリューム・セットの管理を容易にします。

ボリューム

ボリュームABCグループ

スナップショット・グループ

ボリュームのABCグループの��

ABCグループへのボリュームのHI

ボリュームのJ

ABCグループの��

cg_snapshots_create

xiv

po

ge

n3

01

6

図 15. 整合性グループのライフサイクル


整合性グループのスナップショットの取得整合性グループ全体のスナップショットを取得することは、整合性グループの各ボリュームのスナップショットを同じ特定時点で取得することを意味します。これらのスナップショットは、同じグループにグループ分けされ、特定の時点での整合性グループのボリュームを表します。

図 16 では、以下の順序で整合性グループのボリュームごとにスナップショットを取得します。

Time = t0

スナップショットを取得する前。整合性グループ内のすべてのボリュームがアクティブで、読み取りおよび書き込みが行われている。

Time = t1

整合性グループのスナップショットを取得するコマンドが発行され、入出力が中断される。

Time = t2

同じ特定時点でスナップショットが取得される。

Time = t3

入出力が再開され、ボリュームは通常の処理を続行する。

図 16. 整合性グループのボリュームごとのスナップショットの取得


Time = t4

スナップショットが取得された後、ボリュームはアクティブ状態を再開し、読み取りおよび書き込みを続行する。

ほとんどのスナップショット操作は、「スナップショット・セット」と呼ばれるグループ内の各スナップショットに適用することができます。スナップショット・セットには、以下の特性があります。

v スナップショット・セットは、ロックまたはアンロックすることができます。スナップショット・セットをロックまたはアンロックすると、セット内のすべてのスナップショットがロックあるいはアンロックされます。

v スナップショット・セットは、複製することができます。

v スナップショット・セットは、削除することができます。スナップショット・セットを削除すると、セット内のすべてのスナップショットも削除されます。

スナップショット・セットは、解体することができます。これにより、セット内のすべてのスナップショットは独立したスナップショットになり、個別に処理することが可能になります。スナップショット・セット自体は削除されますが、個々のスナップショットは削除されません。

スナップショット・グループのライフサイクルスナップショット操作のほとんどはスナップショット・グループに適用できます。スナップショット・グループではその操作がグループ内のすべてのスナップショットに影響します。

図 17. スナップショット操作のほとんどはスナップショット・グループに適用可能

第 4 章整合性グループの概要 47

スナップショット・グループの作成スナップショット・グループを作成します。

スナップショット・グループからの整合性グループの復元スナップショット・グループの主な目的は、整合性グループ全体を一括して復元し、すべてのボリュームを同じ特定時点に同期できるようにすることです。 .

スナップショット・グループのリストこのコマンドは、スナップショット・グループをその整合性グループおよびスナップショット作成時刻とともにリストします。

注: スナップショット・グループ内のすべてのスナップショットは同時に作成されます。

ロックおよびアンロック個々のスナップショットをアンロックおよびロックする場合と同様に、スナップショット・グループも書き込み可能にすることができ、そのうえで書き込みを行えます。アンロックされたスナップショット・グループは、再度ロックされた場合でも、それ以降、整合性グループの復元に使用することはできません。

スナップショット・グループは再度ロックすることができます。このステージでは、マスター整合性グループの復元には使用できません。この状態では、スナップショット・グループは自身の整合性グループのような働きをします。

上書きスナップショット・グループは別のスナップショット・グループによって上書きできます。

Renameスナップショット・グループは名前を変更できます。

名前の制限スナップショット・グループの名前には、以下のいずれも接頭部として使用しないでください。

1. most_recent

2. last_replicated

複製スナップショット・グループは複製できるため、最初のスナップショット・グループのタイム・スタンプを使用して、同じ整合性グループに対して別のスナップショット・グループを作成できます。

スナップショット・グループの解体スナップショット・グループを構成するスナップショットは、それぞれがそのボリュームに関連しています。スナップショット・グループは整合性グループの復元に不適切とすることができますが、そのグループを構成するスナップショットは引き続きそのボリュームに接続されます。スナップショット・グループを解体すると、そのスナップショット・グループからすべてのスナップショットが切り離されますが、ボリュームへのスナップショットの個々の接続は維持されます。こうした個々のスナップショットは整合性グループを復元できませんが、そのボリュームを個別に復元することはできます。


スナップショット・グループの削除優先順位の変更スナップショット・グループの削除優先順位を手動で設定します。

スナップショット・グループの削除スナップショット・グループをそのスナップショットとともに削除します。

整合性グループの復元整合性グループの復元は、整合性グループに属するすべてのボリュームが、関連するスナップショット・グループに属する対応するスナップショットから復元される単一アクションです。

スナップショット・グループにはボリュームごとに一致するスナップショットがあるだけでなく、すべてのスナップショットには同じタイム・スタンプがあります。これは、復元された整合性グループには、特定時点でのそのグループのボリュームと整合性のあるピクチャーが含まれていることを意味します。

注: 整合性グループは、各ボリューム用のスナップショットをもつスナップショット・グループからのみ復元することができます。スナップショット・グループの受け入れ後に整合性グループまたはスナップショット・グループが変更された場合は、復元アクションは機能しません。

第 4 章整合性グループの概要 49

第 5 章ストレージ・プールの概要

IBM XIV Storage System のストレージ・スペースはストレージ・プールに分割され、各ボリュームは特定のストレージ・プールに所属します。

ストレージ・プールには以下の利点があります。

ストレージ・スペースの管理の向上ストレージ・プール内に特定のボリュームをグループとしてまとめることができます。これにより、特定のボリューム・グループへの特定のストレージ・スペースの割り振りを制御できます。このストレージ・プールは、特定のアプリケーション・グループ用として、または特定の部門のニーズに対して役立てることができます。

ストレージ・スペースの調整の向上スナップショットに割り振られているストレージ容量がすべて消費された時点でスナップショットが自動的に削除されるよう、設定することができます。この自動削除は、各ストレージ・プールで独立して実行されます。したがって、ストレージ・プールのサイズ制限に達したときは、該当するストレージ・プールにあるスナップショットのみが削除されます。詳しくは、 34

ページの『スナップショットの自動削除優先順位』を参照してください。

シン・プロビジョニングの促進ストレージ・プールによってシン・プロビジョニングが使用可能になります。

論理エンティティーとしてのストレージ・プール

ストレージ・プールは論理エンティティーであり、特定のディスクまたはモジュールに関連付けられません。ストレージ・プールはすべて、システム内のすべてのディスクおよびすべてのモジュールに均一に分散されます。

そのため、ストレージ・プールのサイズ制限、またはボリュームとストレージ・プール間の関連に対する制限はありません。次に例を示します。

v ストレージ・プールのサイズは減らすことができます。これは、そのストレージ・プール内のボリュームとスナップショットによって消費されたスペースによってのみ制限されます。

v ターゲット・ストレージ・プールに十分なフリー・スペースがある限り、ストレージ・プール間でボリュームを無制限に移動できます。

注: ストレージ・プールのサイズについては、IBM XIV Storage System データ・シートを参照してください。

上記のトランザクションはすべてアカウンティング上のトランザクションであり、ディスク・ドライブから別のディスク・ドライブへのデータ・コピーを強制的に行うわけではありません。これらのトランザクションは即時に完了します。


ストレージ・プール間でのボリュームの移動

特定のストレージ・プールにボリュームを移動するには、その移動先ストレージ・プールにボリュームを含める十分なスペースが必要です。ストレージ・プールの大きさが十分でない場合、ストレージ・プールのサイズを変更するか、他のボリュームを別の場所に移動して新規ボリューム用のスペースを設ける必要があります。

ボリュームとそのすべてのスナップショットは常に同じストレージ・プールに所属します。ストレージ・プール間でボリュームを移動すると、そのボリュームのスナップショットもすべて一緒に、自動的に移動されます。

ストレージ・プール・レベルでのスナップショットの保護ミラーリング・プロセスに関与しているスナップショットは、プール・スペースの枯渇の発生時に保護することができます。

これは、スナップショット (またはスナップショット・グループ) とストレージ・プールの両方に削除優先順位の属性を指定することによって行います。スナップショットには 0 から 4 の削除優先順位の属性を指定し、ストレージ・プールは、優先順位が特定の値より上のスナップショットを無視するように構成します。構成した値より削除優先順位の低い (すなわち、番号の高い) スナップショットは、プール・スペースの枯渇メカニズムがその発生を示唆するとシステムによって削除される可能性があり、これにより、優先順位が構成した値以上のスナップショットは保護されます。

シン・プロビジョニングIBM XIV Storage System は、シン・プロビジョニングをサポートします。シン・プロビジョニングは、システムにインストールされている物理容量よりもはるかに多くの論理ボリューム・サイズを定義できる機能です。物理容量は、書き込まれたデータを収容するための容量のみが必要で、ボリューム上で書き込みが行われていない部分については物理スペースを消費しません。

この章では、次のことについて説明します。

v ボリュームのハード・サイズおよびソフト・サイズ

v システムのハード・サイズおよびソフト・サイズ

v プールのハード・サイズおよびソフト・サイズ

v ハード容量の枯渇

ボリュームのハード・サイズおよびソフト・サイズ

シン・プロビジョニングを使用しない場合、各ボリュームのサイズは、ホストから認識されるサイズであり、かつ物理ディスク上で予約されているサイズです。シン・プロビジョニングを使用する場合は、各ボリュームには、以下の 2 つのサイズが関連付けられます。

ボリュームのハード・サイズこれは、ホストによって書き込まれたボリューム・エリアのサイズを反映します。ボリュームのハード・サイズは、ユーザーが直接コントロールするものではなく、アプリケーションの動作のみによって決まります。このサイズ


は、ボリュームの作成時またはフォーマット時にゼロから開始し、ボリューム全体に書き込みが行われるとボリュームのソフト・サイズに達します。ボリュームのサイズ変更は、ボリュームのハード・サイズに影響しません。

ボリュームのソフト・サイズこれは、ボリュームの作成時あるいはサイズ変更操作時に定義された論理ボリュームのサイズです。このサイズは、ホストから認識されるサイズで、ユーザーが完全に構成することが可能です。シン・プロビジョニングを使用しない場合、ボリュームのソフト・サイズは、従来のボリューム・サイズです。

システムのハード・サイズおよびソフト・サイズ

シン・プロビジョニングを使用する場合は、各 IBM XIV Storage System は「システムのハード・サイズ」と「システムのソフト・サイズ」に関連付けられます。シン・プロビジョニングを使用しない場合は、これら 2 つのサイズはシステムの容量と同等です。シン・プロビジョニングを使用する場合、これらの概念には次の意味があります。

システムのハード・サイズこれは、取り付けられている物理ディスクの容量です。当然ながら、システムのハード容量がすべてのボリュームの合計ハード容量の上限になります。システムのハード容量は、新規のハードウェア・コンポーネント (ディスクおよびモジュール) を取り付けることによってのみ変更することができます。

システムのソフト・サイズこれは、システム内のすべてのボリュームのソフト・サイズの合計の上限です。このサイズは、システムのハード・サイズより大容量 (最大 79TB) に設定することができます。システムのソフト・サイズは、純粋に論理限界ですが、無計画な値を設定しないようにしてください。システムのハード・サイズをソフト・サイズと同じサイズにアップグレードすることが可能でなければなりません。そうしない場合、アプリケーションがスペースを使い尽くす可能性があります。この要件は、将来のシステム・ハードウェアのアップグレードのために十分なフロア・スペースを確保しておく必要があることを意味します。また、冷却装置および電源インフラストラクチャーがこれらのアップグレードをサポート可能である必要があります。これらの問題は複雑であるため、システムのソフト・サイズの設定は、IBM XIV サポートのみが実行することができます。

プールのハード・サイズおよびソフト・サイズ

ストレージ・プールの概念は、シン・プロビジョニングにも拡張することができます。シン・プロビジョニングが使用されていない場合、ストレージ・プールを使用してボリュームの容量割り振りを定義します。ストレージ・プールは、十分なスペースがない場合に、スナップショットを削除するか、およびどのスナップショットを削除するかをコントロールします。

シン・プロビジョニングが使用されている場合、各ストレージ・プールにはプールのソフト・サイズとハード・サイズがあり、それらは次のように定義および使用されます。

第 5 章ストレージ・プールの概要 53

プールのハード・サイズこれは、ストレージ・プール内のボリュームおよびスナップショットに割り振られた物理ストレージ容量です。ストレージ・プールのハード・サイズは、ストレージ・プール内のすべてのボリュームの合計ハード・サイズ、およびスナップショットによって消費されるすべてのストレージの合計サイズを制限します。ボリュームと異なり、プールのハード・サイズは、ユーザーが完全に構成します。

プールのソフト・サイズこれは、ストレージ・プール内のすべてのボリュームの合計ソフト・サイズを制限します。プールのソフト・サイズは、スナップショットには影響しません。

シン・プロビジョニングは、各ストレージ・プールごとに個別に管理されます。各ストレージ・プールには、独自のソフト・サイズおよびハード・サイズがあります。リソースは、他のストレージ・プールによって制限を受けることなく、このストレージ・プール内のボリュームに割り振られます。これは、スナップショットの削除メカニズムの自然な流れで、シン・プロビジョニングを使用しない場合にも適用されます。各ストレージ・プールには独自のスペースがあり、各ストレージ・プール内のスナップショットは、他のストレージ・プールの状態に関わらず、そのストレージ・プールがスペースを使い尽くすと削除されます。

すべてのストレージ・プールのすべてのソフト・サイズの合計は、常にシステムのソフト・サイズと同じで、これはハード・サイズについても同様です。

ストレージ・プールは、ストレージ・リソースをアプリケーションまたはアプリケーション・グループごとに割り振るための論理的な方法を提供します。シン・プロビジョニングを使用する場合、この機能を使用してソフト容量とハード容量の両方を管理することができます。

ハード容量の枯渇

シン・プロビジョニングには、物理容量が枯渇するという潜在的なリスクがあります。特定のシステムのハード・サイズがソフト・サイズより小さい場合、アプリケーションがホストにマップされたすべてのストレージ・スペースに書き込みを行うと、システムは容量を使い尽くします。そのような状態では、システムは次のように動作します。

スナップショットの削除ボリュームの物理スペースを増やすために、スナップショットが削除されます。スナップショットの削除は、削除の優先順位と作成時間に基づいて行われます。

ボリュームのロックすべてのスナップショットが削除されても、まだ物理容量が不足している場合は、ストレージ・プール内のすべてのボリュームがロックされ、書き込みコマンドは許可されません。これは、追加のハード容量の消費をすべて一時停止します。

注: ボリュームに割り振られている未使用のスペース (ボリュームのソフト・サイズとハード・サイズの差分) は、同じストレージ・プール内のスナップショットが使用することができます。


IBM XIV Storage System のシン・プロビジョニング実装環境では、ストレージ・プールごとにスペース割り振りを管理します。そのため、1 つのストレージ・プールが別のストレージ・プールに影響することはありません。このスキームには、以下の利点と欠点があります。

ストレージ・プールが独立しているストレージ・プールは、シン・プロビジョニングの観点では独立しています。 1 つのストレージ・プール上でのシン・プロビジョニング・ボリュームのロックが、別のストレージ・プールで問題を引き起こすことはありません。

ストレージ・プール間でスペースを再使用することができないストレージ・プールにフリー・スペースがある場合でも、そのスペースを別のストレージ・プールで再使用することはできません。これにより、1 つのストレージ・プールでハード容量の枯渇によってボリュームがロックされる一方で、別のストレージ・プールには使用可能な容量があるという状態が発生します。

重要: ストレージ・プールがハード容量を使い尽くすと、そのストレージ・プールのすべてのボリュームがすべての書き込みコマンドに対してロックされます。既存のデータを上書きする書き込みコマンドは、技術的にはサービスを提供することができますが、整合性を確実にするためにブロックされます。

即時スペース再利用IBM XIV Storage System 即時スペース再利用では、パフォーマンスまたは管理上の影響なしに、ホスト・オペレーティング・システムによって解放される再利用可能な IBM XIV ストレージ・スペースを継続的にリサイクルします。これにより、適度の好結果が得られます。

即時スペース再利用を使用して、ストレージおよびホストの管理者は、システム・キャパシティーを増やし、シン・プロビジョニングの必要性を減らします。ホストからの通知で、IBM XIV は、ゼロを書き込むことによって使用されなくなるスペースを解放します。詳しくは、 24ページの『ゼロの書き込み』を参照してください。

割り振られたスペースが使用されていないか判断するためにホストと通信することは、以下に発展します。

v ホストから割り振り状況を取得

v この状況をプロビジョニングしきい値とマッチングして、結果をレポート

v 再利用に適しているスペースを検出

v このスペースを解放

即時スペース再利用機能は、以下に示すような、一時機能付きボリュームおよびその関係をスキップします。

v 非同期ミラーリングのオフライン初期化

v 多種のデータ・マイグレーション

ミラーリングされたボリューム・ペアの即時スペース再利用のサポートは、同期ミラーリング、ならびに両方のシステムがこの機能をサポートする場合 (すなわち、両方のシステムがバージョン 11.2.0 以降の場合) に限定されます。

第 5 章ストレージ・プールの概要 55

サポートされるプラットフォーム

以下のベンダーは、2012 年の終わりまでに、各社の OS で即時スペース再利用をサポートすると発表しています。

v Microsoft Windows Server 8

v VMWare

v RedHat

v Symantec SSF

即時スペース再利用機能のアクティブ化

即時スペース再利用は、IBM XIV Storage System の製造時にグローバルに使用可能にすることができ、なおかつ技術員が使用不可にし、さらに使用可能にすることができます。


第 6 章同期リモート・ミラーリング

IBM XIV Storage System には、その特長として災害時回復のための同期および非同期のリモート・ミラーリングが用意されています。リモート・ミラーリングは、地理的に離れた 2 つのサイト間でデータを複製する場合に使用できます。複製を行うことで、完全なサイト障害が発生した場合でもビジネス・オペレーションが中断されません。

リモート・ミラーリングにより、以下のタイプのサイト災害でデータが保護されます。

サイト障害別のサイトにリモート接続されているサイトで災害が発生すると、第 2 のサイトが引き継ぎ、最初のサイトに接続されているホストに対するすべてのサービスを維持します。障害が起こったサイトが復旧すると、ミラーは再開されます。

スプリット・ブレーン2 つのサイト間の通信が失われた後、各サイトはそれぞれホストへのすべてのサービスを維持します。接続が再開されると、それらのサイトは相互のデータを補完し合ってミラーリングを再確立します。

同期および非同期のリモート・ミラーリング

この章および次の章で、同期および非同期という 2 つのリモート・ミラーリング方式について説明します。この章では、明確に示されていない限り、リモート・ミラーリングという用語は同期リモート・ミラーリングを示唆します。

リモート・ミラーリングの基本概念同期リモート・ミラーリングを実施すると、災害時のシナリオが適用された場合に重大情報の連続可用性が可能になります。

典型的なリモート・ミラーリング構成には、以下の 2 つのサイトが含まれます。

1 次サイトマスター・ストレージ・システムの場所。

データとアクティブ・サーバーの両方を含むローカル・サイト。

2 次サイト2 次ストレージ・システムの場所。

データのコピーおよびスタンバイ・サーバーを含むリモート・サイト。マスター・サイトで災害が発生すると、2 次サイトのサーバーがアクティブになり、データのコピーの使用を開始します。

マスターミラーリングされるボリュームまたはストレージ・システム。マスター・ボリュームまたはマスター・ストレージ・システムは、通常マスター・サイトにあります。


スレーブマスターのミラーリング先となるボリュームまたはストレージ・システム。スレーブ・ボリュームまたはスレーブ・ストレージ・システムは、通常 2

次サイトにあります。

リモート・ミラーリングの主要目標の 1 つは、2 次サイトにマスター・サイトと同じ (整合した) データが含まれるようにすることです。リモート・ミラーリングを実施すると、2 次サイトのホストおよびストレージ・システムによってサービスがシームレスに提供されます。

両方のストレージ・システムに常に同一データが含まれるようにするプロセスをリモート・ミラーリングと呼びます。同期リモート・ミラーリングは、各書き込み操作時に実行されます。ホストによって発行された書き込み操作は、マスターとスレーブの両方のストレージ・システムに送信されます。

データが 2 次システムにも確実に書き込まれるよう、両方のストレージ・システムにデータが書き込まれた後に初めて書き込み操作の確認応答が発行されます。これにより、まだ確認応答が発行されていない最新の書き込み操作の内容を除き、2 次ストレージ・システムがマスター・ストレージ・システムと確実に整合します。このミラーリング形式が同期ミラーリングと呼ばれています。

リモート・ミラーリング・システムでは、既に説明したように、マスターとスレーブの両方のストレージ・システムで書き込みが実行されている間に、マスター・ストレージ・システムからの読み取りが実行されます。

IBM XIV Storage System は、それぞれのホストに対して、サーバーのペアが交互にマスターと 2 次の役割を果たす構成をサポートします。この結果、あるサイトの 1

つのサーバーが特定のアプリケーションに対してマスター・ストレージ・システムの機能を果たし、それと同時に、別のアプリケーションに対しては 2 次ストレージ・システムの機能を果たすという場合が生じます。

リモート・ミラーリング操作リモート・ミラーリング操作には、構成、初期化、進行中の操作、通信障害の処理、および役割の切り替えの各アクティビティーが含まれます。

以下のリストでは、リモート・ミラーリング操作の各アクティビティーを定義します。

構成ローカルおよびリモートの複製ピアは、1 次ボリュームおよび 2 次ボリュームを指定する管理者によって定義されます。カップリングごとにいくつかの構成オプションを定義できます。

初期化リモート・ミラーリング操作は、データを含むマスター・ボリュームおよびフォーマットされたスレーブ・ボリュームによって開始されます。最初のステップは、マスター・ボリュームからスレーブ・ボリュームへのデータのコピーです。このプロセスは初期化と呼ばれます。初期化は、リモート・ミラーリング・カップリングの存続期間中に 1 回実行されます。初期化が実行されると、両方のボリュームは同期されたと見なされます。

進行中の操作初期化プロセスが完了すると、リモート・ミラーリングは活動化されます。


このアクティビティーの実行中、すべてのデータはマスター・ボリュームに書き込まれ、続いてスレーブ・ボリュームに書き込まれます。スレーブ・ボリュームから確認応答が発行されると、書き込み操作は完了します。どの時点においても、確認応答が発行されていない (保留中の) 書き込みを除き、マスター・ボリュームとスレーブ・ボリュームは同一です。

通信障害の処理ときにより、サイト間の通信が停止する場合があります。その場合、通常は1 次サイトがその機能を続行し、通信再開時に 2 次サイトを更新する方法が推奨されます。このプロセスは同期と呼ばれます。

役割の切り替え1 次サイトでの災害発生や保守操作の結果、あるいは災害時回復手順をテストする演習のため、複製ピアの役割を必要に応じてマスターからスレーブに、あるいはその逆に変更することができます。

構成オプションリモート・ミラーリングの構成プロセスには、ボリュームおよびボリューム・ペアのオプションを構成する操作が含まれます。

ボリュームのペアが相互を指している場合、それはカップリングと呼ばれます。カップリング関係では、リモート・ミラーリング・システムに 2 つのボリュームが参加し、スレーブ・ピアはマスター・ピアのバックアップの機能を果たします。カップリングの構成は、マスター・ボリュームとスレーブ・ボリュームの両方で同一です。

表 3. ボリュームの構成オプション

名前値定義

役割なし、マスター、スレーブボリュームの役割。

(「1 次」および「2 次」はどちらであるかを指定する呼び名です。)

ピアリモート・ターゲットの ID

およびリモート・ターゲット上のボリュームの名前。

ピア・ボリュームを識別します。

表 4. カップリングの構成オプション

名前値定義

活動化アクティブ、スタンバイリモート・ミラーリングを活動化または非活動化します。

ボリュームの構成IBM XIV Storage System 上の各ボリュームおよびそのピア・ボリュームには、リモート・ミラーリング・プロセス内で機能するための役割を定義する必要があります。

以下の概念は、ボリュームおよびボリューム間の関係に対して構成します。

第 6 章同期リモート・ミラーリング 59

v ボリュームの役割

v ピア

ボリュームの役割は、そのボリュームの現在の役割です。以下のボリュームの役割が選択可能です。

なしボリュームは通常のボリューム作成手順を使用して作成され、リモート・ミラーリング構成の一部として構成されていません。

マスター・ボリュームこのボリュームはミラーリングのカップリングに含まれており、マスター・ボリュームとして機能します。

すべての書き込み操作はこのマスター・ボリュームに対して行われます。これにより、書き込み成功の確認応答を発行する前に、確実にスレーブ・ボリュームに書き込み操作が行われます。

スレーブ・ボリュームこのボリュームはミラーリングのカップリングに含まれており、マスター・ボリュームのバックアップとして機能します。

スレーブ・ボリュームからデータは読み取られますが、このボリュームへの書き込みはできません。

ピアはカップリングに含まれているボリュームです。「なし」以外の役割を持つボリュームにはピアの指定が必要であり、対応するマスター・ボリュームまたはスレーブ・ボリュームをそれに割り当てる必要があります。

構成エラー

場合により、それぞれのサイドの構成が非互換の方法で変更されることがあります。これは構成エラーと定義されます。例えば、通信がダウンしたときに一方のサイドの役割のみを切り替えると、接続が再開したときに構成エラーとなります。

混合構成1 つのストレージ・システム上のボリュームには、複数の種類の構成を混合させて定義できます。

例えば、1 つのストレージ・システムに、役割がマスターとして定義されているボリュームと、さらに役割がスレーブとして定義されているボリュームを含めることができます。また、ボリュームによっては、リモート・ミラーリングのカップリングにまったく関与しない場合も考えられます。

ボリュームに割り当てられる役割は一時的です。つまり、現在マスター・ボリュームであるボリュームをスレーブ・ボリュームとして定義することも、また、その逆も可能です。マスターとスレーブの割り当てを切り替えるプロセスにおいては、ローカルという用語はマスター・ボリュームを示し、リモートはスレーブ・ボリュームを示します。


通信エラー2 次ボリュームへの通信リンクに障害が発生した場合、または 2 次ボリューム自体が使用不可の場合、そのボリュームに対する処理は通常どおり続行されます。以下が行われます。

v システムは非同期状態に設定されます。

v マスター・ボリュームへの変更はすべて記録され、通信の復元後にスレーブ・ボリュームに適用されます。

カップリングの活動化リモート・ミラーリングは、カップリングごとに手動で活動化および非活動化できます。リモート・ミラーリングを活動化すると、カップリングはアクティブ・モードになります。非活動化すると、カップリングはスタンバイ・モードになります。

これらのモードには以下の機能があります。

Active (アクティブ)リモート・ミラーリングは機能しており、マスター・ボリュームとスレーブ・ボリュームの両方にデータが書き込まれています。

スタンバイリモート・ミラーリングは非活動化されています。データはスレーブ・ボリュームに書き込まれていませんが、マスター・ボリュームには記録されており、それによって後でスレーブ・ボリュームが同期化されます。

スタンバイ・モードは、主に 2 次サイトで保守が実行されている場合、またはサイト間の通信障害の発生時に使用されます。このモードでは、マスター・ボリュームはミラーリングに障害が起こったというアラートを生成しません。

カップリングのライフサイクルには以下の特性があります。

v カップリングが作成されると、最初は常にスタンバイ・モードになります。

v スタンバイ・モードのカップリングのみが削除可能です。

v 2 つの状態間の移行は、UI から、およびボリューム上においてのみ実行できます。

同期ミラーリング状況同期リモート・ミラーリング・ボリュームの状況は、リモート・ミラーリング操作に関連するストレージ・ボリュームの状態を表します。

ボリュームの状態は、通信リンクの状況およびマスター・ボリュームとスレーブ・ボリュームの間のカップリングの状況を示す機能です。 62ページの『リンク状況』は、リモート・ミラーリング操作中の同期リモート・ミラーリング・ボリュームのさまざまな状況について説明しています。


表 5. 同期ミラーリング状況

エンティティー

名前値定義

リンク状況 v 接続 (Up)

v 切断 (Down)

通信リンクが接続されているか切断されているかを示します。

カップリング操作可能状況 v 操作可能(Operational)

v 操作不可(Non-operational)

リモート・ミラーリングが作動しているかどうかを示します。

同期状況 v 初期化(Initialization)

v 同期済み(Synchronized)

v 非同期(Unsynchronized)

v 整合 (Consistent)

v 不整合 (Inconsistent)

マスター・ボリュームとスレーブ・ボリュームに整合性があるかどうかを示します。

2 次の最後のタイム・スタンプ

ポイント・イン・タイム

2 次ボリュームが最後に同期化されたタイム・スタンプ。

同期化処理の進行状況同期状況操作不可カップリングのため、マスター・ボリュームとスレーブ・ボリュームの間で同期されずに残っているデータ量。

2 次ロックブール値スペース不足のために 2

次が書き込みをロックされている場合は「真(TRUE)」、それ以外の場合は「偽 (FALSE)」。最終整合スナップショット用に十分なスペースがない場合、同期化処理中にこの状況が発生する可能性があります。

構成エラーブール値マスターおよびセカンダリー・スレーブの構成が不整合の場合、「真(TRUE)」。

リンク状況通信リンクの状況は、「接続」か「切断」のいずれかです。マスター・ボリュームのリンク状況は、当然スレーブ・ボリュームのリンク状況でもあります。


操作可能状況マスター・ボリュームとスレーブ・ボリューム間のカップリングは操作可能か操作不可のいずれかです。操作可能にするには、リンク状況が稼働状態であり、カップリングは活動化されている必要があります。リンクが停止している場合、またはリモート・ミラーリング・フィーチャーがスタンバイ・モードの場合、操作可能状況は操作不可です。

同期状況同期状況は、マスター・ボリュームとスレーブ・ボリュームの間のデータの整合性を反映します。リモート・ミラーリング機能の目的は、スレーブ・ボリュームがマスター・ボリュームの完全なコピーであることを確実にすることです。そのため、この状況は、この目的が現在達成されているかどうかを示します。

マスター・ボリュームには、以下の同期状況があります。

初期化リモート・ミラーリングの最初のステップは、ミラーリングの設置を開始したときにマスター・ボリュームからスレーブ・ボリュームにデータをコピーすることです。このステップの間、カップリングの状況は「初期化」のままです。

同期済み (Synchronized) (マスター・ボリュームのみ)この状況は、1 次ボリュームに書き込まれて確認されたすべてのデータが、2 次ボリュームにも書き込まれていることを示します。理想としては、1 次ボリュームと 2 次ボリュームが常に同期された状態であることです。この状況は、2 つのボリュームが完全に一致していることを意味するわけではありません。なぜなら、少量のデータについて、一方のボリュームには書き込まれたが、そのピア・ボリュームにはまだ書き込まれていないという可能性が常にあるためです。これは、それらの書き込み操作がまだ確認されていないことを意味します。これらの書き込みは、保留書き込みとも呼ばれます。

非同期 (Unsynchronized) (1 次ボリュームのみ)

ボリュームが初期化ステージを完了して同期済み状況に達した後に、ボリュームが非同期状態になる場合があります。この状況は、1 次ボリュームに書き込まれたすべてのデータが 2 次ボリュームに書き込まれたかが不明な場合に発生します。この状況は、以下の場合に発生します。

v 通信リンクがダウンしている - 通信リンクがダウンすると、一部のデータが 1 次ボリュームのみに書き込まれ、2 次ボリュームにはまだ書き込まれていないという状態が発生する場合があります。

v 2 次システムがダウンしている - この状況は、通信リンク・エラーと同様です。この状態では、1 次システムのみが更新され、2 次システムは更新されないためです。

v リモート・ミラーリングが非活動化されている - リモート・ミラーリングが非アクティブになると、一部のデータが 1 次ボリュームのみに書き込まれ、2 次ボリュームには書き込まれていないという状態が発生する場合があります。


リンクが再確立されたり、リモート・ミラーリング機能が再活動化されると、非同期状況になった理由に関わらず、いつでも同期済み状況を再確立することが可能です。

2 次ボリュームに書き込まれていない 1 次ボリュームへの更新はすべて記録されているため、これらの更新は 2 次ボリュームに書き込まれます。同期状況は、カップリングが操作不可になったときから同期化処理が正常に完了するまでは、非同期状態のまま残ります。

同期の進行状況同期化処理中に、以前に書き込まれたデータで 2 次ボリュームを更新している間、ボリュームは動的同期化処理状況になります。

この状況は、以下のサブ状況で構成されています。

実行されるサイズ (Size to complete)同期が必要なデータのサイズ。

同期する割合 (Part to synchronize)前回の同期化処理が開始して以降の最大同期サイズで割った同期サイズ。カップリングの初期化の場合、ボリューム・サイズで同期サイズを割ります。

同期にかかる時間 (Time to synchronize)同期化処理が完了し、同期を達成するまでに必要な推定時間 (過去の速度に基づく)。

最終 2 次タイム・スタンプ1 次ボリュームと 2 次ボリューム間のカップリングが操作不可になると、タイム・スタンプがとられます。

このタイム・スタンプは、2 次ボリュームが 1 次ボリュームと最後に整合した時刻を示します。この状況は、カップリングの同期状態がいまだ初期化の場合には意味をもちません。同期されたカップリングの場合、このタイム・スタンプは現在時刻を示します。最も重要なことは、同期されていないカップリングの場合、このタイム・スタンプはカップリングが操作不可になった時刻を示しているという点です。

カップリングが操作可能になり、1 次ボリュームと 2 次ボリュームが同期された後にのみ、このタイム・スタンプは現在に戻ります。

入出力操作入出力操作は、さまざまな構成オプションにまたがって 1 次ボリュームおよび 2

次ボリュームで実行されます。

1 次での入出力読み取り

システムが同期されているかどうかに関係なく、すべてのデータが 1 次(ローカル) サイトから読み取られます。

書き込み

v カップリングが操作可能な場合、データは 1 次ボリュームと 2 次ボリュームの両方に書き込まれます。


v カップリングが操作不可の場合、エラーが返されます。

このエラーは、検出された問題のタイプを反映します。例えば、リモート・ミラーリングが非活動化されている場合、2 次ロック状態エラーまたはリンク・エラーがあります。

2 次での入出力

2 次ボリュームには LUN マップおよびホストを関連付けることができますが、このボリュームには読み取り専用ボリュームとしてのみアクセスできます。これらのマップは、切り替えの実行時にバックアップ・ホストによって使用されます。 2 次ボリュームが 1 次ボリュームになると、ホストはリモート・サイトでそのボリュームに書き込みを行えます。 1 次ボリュームが 2 次ボリュームになると、そのボリュームは読み取り専用になり、新しい 1 次ボリュームによってのみ更新が可能です。

読み取りデータは、他のボリュームからの場合と同様に 2 次ボリュームから読み取られます。

書き込み2 次ボリュームに書き込みをしようとすると、ボリューム読み取り専用SCSI エラーが発生します。

同期化処理障害状態が解決されると、リモート・ミラーリングはカップリングの同期化処理を開始します。この処理により、カップリングが操作不可であった間に発生したすべての変更が 2 次ボリュームに更新されます。

このセクションでは、同期化処理について説明します。

状態遷移図カップリングの状態には、「初期化」、「同期済み」、「タイム・スタンプ」、または「非同期」があります。

次のダイアグラムは、IBM XIV Storage System がその使用期間中に示す可能性があるさまざまなカップリングの状態と、各状態で実行されるアクションを示しています。


以下のリストは、カップリングの各状態を説明しています。

初期化 2 次ボリュームの状況は、初期設定の同期中です。この状態の間に、1 次ボリュームからのデータが 2 次ボリュームにコピーされます。

同期済みカップリングの作動状態です。この状態では、1 次ボリュームと 2 次ボリュームの間に整合性があります。

タイム・スタンプリモート・ミラーリングが操作不可になったため、タイム・スタンプが記録されます。この状況の間に、以下のアクションが実行されます。

1. カップリングの非活動化、またはリンクのダウン。

2. カップリングの再活動化、またはリンクの復元。

非同期通信障害またはリモート・ミラーリングが非活動化されたため、リモート・ミラーリングが操作不可です。そのため、1 次ボリュームと 2 次ボリュームは同期されていません。リモート・ミラーリングが再開されると、「同期済み」状態に戻るための手順が実行されます。

カップリングのリカバリーリモート・ミラーリングは操作不可のカップリングからリカバリーします。

リモート・ミラーリングが操作不可のカップリングからリカバリーすると、以下のアクションが実行されます。

図 18. カップリングの状態およびアクション


v 2 次ボリュームが「同期」状態の場合、2 次ボリュームの最終整合スナップショットが作成され、secondary-volume-time-date-consistent-state というストリングの名前が付きます。

v 1 次ボリュームは「同期」状態になるまで 2 次ボリュームを更新し続けます。

v 同じシステム・ペア間でボリュームをミラーリングするすべてのカップリングが同期された後、1 次ボリュームは特殊スナップショットを削除します。

非コミット・データカップリングが「非同期」状態の場合、ベスト・エフォート・カップリングのために、システムは 1 次ボリューム内のどのデータが変更されたかを追跡し、カップリングが再度操作可能になったときにこれらの変更を 2 次ボリュームにコミットできるようにする必要があります。

2 次ボリュームにコミットしてマークを付ける必要がある 1 次ボリュームの部分は、「非コミット・データ」と呼ばれます。

注: カップリングが操作可能になったときに 2 次ボリュームに書き込む必要がある1 次ボリュームの部分にマークを付けるメタデータのみがあります。

制約および制限カップリングには制約と制限があります。

以下の制約と制限が存在します。

v サイズ、部分、または同期が完了するまでの時間は、同期状況が「非同期」である場合のみに関連します。

v 最終 2 次タイム・スタンプは、カップリングが「非同期」である場合のみに関連します。

最終整合スナップショット同期処理が開始される前に、2 次ボリュームのスナップショットが作成されます。このスナップショットは、同期処理中に 1 次サイトで災害が発生する場合に備えて2 次ボリュームを使いやすい状態にしておくために作成されます。

同期が完了する前に 1 次ボリュームが破棄されると、2 次ボリュームの整合性がなくなる可能性があります。2 次ボリュームは 1 次ボリュームに行われた変更によって部分的にしか更新されていない可能性があるためです。こうした不整合が生じる可能性がある理由は、更新が必ずしもホストによって書き込まれた順序どおりに実行されるとは限らないということです。

この状態に対処するため、1 次ボリュームは常に、2 次マシンへの再接続後、かつ同期処理の開始前に、最終整合 2 次ボリュームのスナップショットを作成します。

最終整合スナップショット

最終整合スナップショット (LCS) は、ミラーリングの再同期を行う必要が生じる直前に、同期ミラーリングのスレーブ・ピアでシステムによって作成されます。ミラーリングの再同期は、リンクの切断が起こった後、またはミラーリングを手動で非活動化した後に行われます。いずれの場合もマスターは引き続きホストの書き込み


を受け入れますが、リンクがダウンしている間またはミラーリングが非活動化されている間はスレーブにその書き込みを複製しません。

ミラーリングが復元され、活動化されると、システムはスレーブのスナップショット (LCS) を取得します。LCS は、ミラーリング済みであることが確認されているデータです。この後に初めて、マスターに書き込まれた、まだミラーリングされていないデータが再同期処理によってスレーブに複製されます。

同じターゲットのすべてのミラーで再同期が完了すると、LCS はシステムによって自動的に削除されますが、再同期中にスレーブ・ピアの役割が変更された場合、このスナップショットは削除されません。

外部最終整合スナップショット

外部最終整合スナップショットが導入される前は、ピアの役割が変更されてスレーブに戻った場合、および場合によっては新しい再同期処理が開始された場合、システムは必ずピアで LCS を検出し、新しい LCS を作成しようとしませんでした。こうした状況の発生時に、そのピアがミラーリングされた整合性グループ (ミラーリングされた CG) には含まれていなかった場合、すべてのボリュームに同じ LCS タイム・スタンプが設定されているとは限らなくなりました。ピアがミラーリングされた整合性グループに含まれていた場合、整合性のある LCS は得られますが、その LCS は想定していたほど最新のものではありません。この状態は、外部最終整合スナップショットの導入によって回避できるようになりました。

(そのボリュームに特定されていないシステム/ターゲット内で) ミラーリングの再同期が進行中に LCS を持つスレーブの役割がマスターに変更されると、その LCS は必ず外部最終整合 (ELCS) に名前変更されます。この ELCS は LCS の削除優先順位 0 を保持します。ピアの役割が後で再びスレーブに変更された場合、および場合によっては新しい再同期処理が開始された後に、新しい LCS が作成されます。

それ以降、スレーブの役割が再び変更されると、既存の外部最終整合スナップショットが外部最終整合 x (x は 1 から始まる番号で、使用可能な最初の番号) に名前変更され、LCS は外部最終整合に名前変更されます。外部最終整合の削除優先順位は 0 になりますが、新しい外部最終整合 x の削除優先順位はシステム・デフォルト (1) になるため、プール・スペースの枯渇が発生すると、システムによって自動的に削除される可能性があります。

再同期を完了できない場合、LCS または ELCS (あるいは、場合によっては ELC

x) をスレーブ・ピアの復元ポイントとして機能させるかどうかを検証することが、非常に重要です。削除優先順位 0 のスナップショットはスペースを解放するためにシステムで自動削除されることはありませんが、外部最終整合および外部最終整合x のスナップショットは、必要があれば管理者が手動で削除できます。これらのスナップショットを削除すると、(マスターが使用可能でないために再同期が完了できない場合) 復元元となる整合スナップショットのない、不整合ピアが残される可能性があるため、ピアの整合性が保たれる保証がない限り、プール・スペースが枯渇する場合でも、通常はこのような削除は回避する必要があります。

最終整合スナップショットの手動削除v XIV サポート・チームのみが最終整合スナップショットを削除できます。 XIV

サポート・チームは delete_mirror_snapshots CLI コマンドを使用します。


v また、XIV サポート・チームは最終整合スナップショットが作成されないようにミラーリングを構成することもできます。この構成は、2 次ボリュームを含むシステムがすべて使用されていて、追加のスナップショットを作成できない場合に必要です。

最終整合スナップショットのタイム・スタンプ1 次ボリュームと 2 次ボリューム間のカップリングが操作不可になると、タイム・スタンプがとられます。このタイム・スタンプは、2 次ボリュームが 1 次ボリュームと最後に整合した時刻を示します。

この状況は、カップリングの同期状態がいまだ初期化の場合には意味をもちません。同期されたカップリングの場合、このタイム・スタンプは現在時刻を示します。最も重要なことは、同期されていないカップリングの場合、このタイム・スタンプはカップリングが操作不可になった時刻を示しているという点です。

表 6 に、障害状態の例を示し、タイム・スタンプによって指定される時刻について説明します。

表 6. 最終整合スナップショットのタイム・スタンプ・プロセスの例時刻カップリングの状況アクション最終整合タイム・

スタンプ

12:00 まで操作可能および同期現在

12:00 から1:00

障害によってカップリングが操作不可になりました。カップリングは「非同期」です。

1 次ボリュームへの書き込みは続行されます。変更がマークされているため、後でその変更をコミットできます。

12:00

13:00 接続は再開し、リモート・ミラーリングは操作可能です。同期が開始されます。カップリングは引き続き「非同期」です。

接続が切断された後のすべての変更、および現在の書き込み操作が 2 次ボリュームにコミットされます。

12:00

13:15 同期済み現在

2 次ロック・エラー状況同期化処理の進行中には、2 次ボリュームと 1 次ボリュームの整合性がない期間があるため、最終整合スナップショットが保持されます。この状態の間、2 次ボリュームに対する入出力操作は、十分なスペースがないために失敗する可能性があります。十分なスペースがないのは、すべての入出力操作が潜在的にパーティションのコピー・オン・ライトを要求するためです。

十分なスペースがないために入出力操作が失敗する場合は、必ずシステム内のすべてのカップリングが 2 次ロック状況に設定され、カップリングは操作不可になります。クリティカル・イベントは管理者に通知され、管理者は 2 次ボリュームが含まれるシステム上のスペースを解放することができます。

この状態が発生した場合は、IBM XIV 技術員に連絡してください。十分なスペースが確保できると、入出力操作が再開し、リモート・ミラーリングを再活動化することができます。


役割の切り替え

リモート・ミラーリングが操作可能の場合の役割の切り替え1 次ボリュームと 2 次ボリューム間の役割の切り替えは、リモート・ミラーリング機能が操作可能になった後に IBM XIV Storage Management GUI または XCLI から実行できます。役割の切り替えを行うと、1 次ボリュームは 2 次ボリュームになり、逆に 2 次ボリュームは 1 次ボリュームになります。

ボリューム間の通信が存在する場合に切り替えを行う理由として典型的なものは 2

つあります。以下のものです。

演習演習は、2 次サイトの機能をテストするために定期的に実行できます。演習では、管理者が災害をシミュレートし、すべての手順が円滑に運用されるかをテストします。

定期保守1 次サイトで保守を実行するには、保守の前日に 2 次サイトへ運用を切り替えます。これは、1 次サイトの問題が発生するとわかっている場合の予防対策として実行できます。

この切り替えは、1 次ボリュームに対する自動操作として実行されます。 1 次ボリュームと 2 次ボリュームが同期されていない場合、この切り替えは実行できません。

リモート・ミラーリングが操作不可の場合の役割の切り替え役割の切り替えにおけるさらに複雑な状態は、2 つのサイト間に通信が存在しない(ネットワークの誤動作のため、または 1 次サイトが操作可能でなくなったため) 場合です。このシナリオの XCLI コマンドは reverse_role です。2 つのサイト間に通信が存在しないため、このコマンドは両方のサイトで同時に発行するか、少なくとも通信が再開する前に発行する必要があります。

1 次ボリュームと 2 次ボリュームが接続されているか否かによって、切り替え手順は異なります。一般的な規則として、以下が当てはまります。

v カップリングが非活動化されている場合、一方のサイドのみで役割を変更することができます。これは、通信の再開前に他方のサイドでも変更が行われるであろうという前提に基づきます。

v カップリングが活動化されても、リンク・エラーが原因で非同期状態または操作不可状態になっている場合、管理者はカップリングが同期されるのを待つか、カップリングを非活動化する必要があります。

v カップリングがアクティブな場合でも、管理者は 2 次ボリュームで役割を変更できます。これは、1 次ボリュームでカップリングが非活動化され、1 次ボリュームでも役割の切り替えが並行して実行されるであろうという前提に基づきます。前提どおりにならない場合、構成エラーが発生します。

2 次から 1 次への切り替えIBM XIV Storage Management GUI または XCLI を使用して、2 次ボリュームの役割を 1 次に切り替えることができます。この切り替えの後、次のようになります。

v 2 次ボリュームが 1 次になっています。


v カップリングの状況が「非同期」になります。

v カップリングは、待機モードのまま残ります。つまり、リモート・ミラーリングは非活動化されています。これにより、他方のサイトの役割が切り替えられた場合に、確実に正しい順序で活動化することができます。

新しい 1 次ボリュームは、ローカル・ホストからの書き込みコマンドの受け入れを開始します。カップリングがアクティブではないため、すべての 1 次ボリュームと同じ方法で、通信が再開されたときにどの書き込み操作を 2 次に送信するかをログに記録して保持します。

通常は、2 次ボリュームを 1 次ボリュームに切り替えた後、少なくとも通信が再開する前に管理者が 1 次ボリュームを 2 次ボリュームに切り替えます。両方のボリュームが同じ役割のまま放置されると、構成エラーが発生します。

2 次の整合性最終整合スナップショットが使用可能でなくなった場合の、2 次ボリュームから 1

次ボリュームへの切り替え

ユーザーが 2 次ボリュームを 1 次ボリュームに切り替えていて、last_consistent 状態のスナップショットが存在する場合に、同期処理中にリンクは切断されているとします。この場合、ユーザーは最新更新バージョン (不整合の可能性あり) を使用するか、last_consistent スナップショットに戻すかを選択できます。表 7 に、このプロセスの概要を示します。

表 7. 2 次の整合性に関する決断に至る災害時シナリオ時刻リモート・ミラーリングの状況アクション

12:00 まで操作可能 (Operational) ボリューム A が 1 次ボリュームで、ボリューム B が 2 次ボリュームです。

12:00 通信障害のために操作不可ボリューム A への書き込みは続行され、ボリューム A はボリューム B にコミットされる変更のログを維持しています。

13:00 接続は再開し、リモート・ミラーリングは操作可能です。

ボリューム B で last_consistent スナップショットが生成されます。その後、ボリューム A

は、通信の切断以降に発生した書き込み操作によるボリューム B への更新を開始します。

13:05 1 次サイトが破壊され、すべての情報が失われます。

13:10 ボリューム B が 1 次になります。オペレーターは、ボリューム B の最新更新バージョン(12:00 から 13:00 までの間にボリューム A にコミットされた書き込み操作の一部のみを含む)

を使用するか、12:00 時点のボリューム B の状態を反映する最終整合スナップショットを使用するかを選択できます。

最終整合スナップショットが存在し、役割が 2 次から 1 次に変更された場合、システムは自動的にボリュームのスナップショットを生成します。このスナップショットの名前はmost_updated スナップショットになります。このスナップショットは、ユーザー・エラーからリカバリーするときに、ボリュームの最新バージョンに安全に戻せるように生成されます。このスナップショットを削除できるのは、IBM

XIV Storage System サポート・チームのみです。


カップリングがいまだ初期化状態にある場合、切り替えは実行できません。初期コピーが完了していない場合でもデータが必要になるという極端なケースでは、1 次ボリュームのボリューム・コピーを使用できます。

1 次から 2 次への切り替えカップリングが非アクティブの場合、1 次マシンの役割を切り替えることができます。そのような切り替えを行うと、1 次ボリュームが 2 次ボリュームになります。

1 次ボリュームは非アクティブのため、非同期状態にあり、非コミット・データ・リストがある可能性があります。これらの変更はすべて失われます。ボリュームが2 次になると、このデータはピア・ボリューム (新しく 1 次ボリュームとなったボリューム) 上のデータと一致するように戻される必要があります。この場合、イベントが作成され、失われた変更のサイズの要約が示されます。

非コミット・データ・リストは、その意味も切り替わり、ローカル・ボリューム(元の 1 次、新しい 2 次) がリモート・ボリューム (元の 2 次、新しい 1 次) に対して行う必要がある更新のリストではなく、リモート・ボリュームからローカル・ボリュームに対して行う必要がある更新を表すリストになっています。

接続を再確立するときに、ローカル・ボリューム (現在の 2 次、元の 1 次) は、この非コミット・データ・リストを使用してリモート・ボリューム (新しい 1 次) を更新します。これらのリストをローカル・ボリューム (新しい 2 次) に同期するのは新しい 1 次ボリュームの責任です。

役割変更後のリモート・ミラーリングの再開両サイドで役割の切り替えが行われた後に通信リンクが再開されると、カップリングには 1 つの 2 次ボリュームと 1 つの 1 次ボリュームが含まれるようになります。

注: 役割の切り替え後、カップリングはスタンバイになります。カップリングの活動化を行うのは、リンク再開の前でも後でもかまいません。

表 8 では、カップリングが操作可能になる (すなわち、通信リンクが再開されて、カップリングが再活動化された) ときのシステムの動作を説明しています。通信が再開されると、新しい 1 次ボリューム (旧 2 次ボリューム) は非同期状態になっている可能性があり、同期すべき非コミット・データ・リストを保有していると考えられます。

新しい 2 次ボリューム (旧 1 次) は、新しい 1 次ボリュームから同期すべき非コミット・データ・リストを保有している可能性があります。これらは、リンクが切断された後、ボリュームの役割が 1 次から 2 次に切り替えられる前に書き込まれた書き込み操作です。これらの変更は、新しい 1 次ボリュームの内容に戻す必要があります。いずれのリストも、新しい 1 次ボリュームが同期を行うために使用する必要があります。

表 8. 新しい 1 次ボリュームの同期のためのコミットされていないデータの解決時刻リモート・ミラーリング

の状況アクション

12:00 まで操作可能および同期ボリューム A が 1 次ボリュームで、ボリューム B が 2 次ボリュームです。


表 8. 新しい 1 次ボリュームの同期のためのコミットされていないデータの解決 (続き)

時刻リモート・ミラーリングの状況

アクション

12:00 から12:30

通信障害が発生し、カップリングが操作不可になっている

ボリューム A は引き続きホストからの書き込み操作を受け入れ、非コミット・データ・リストを維持し、これらの書き込み操作にマーキングします。例えば、ボリューム A はブロック1000 から 2000 までの書き込み操作を受け入れた場合、ブロック 1000 から 2000 を、再接続後にボリューム B にコピーする必要があるものとしてマーキングします。

12:30 両サイドで役割が変更された

ボリューム A は 2 次になり、ボリューム B は 1 次になります。この時点で、ボリューム A は 12:00 から 12:30 の間に行われた変更を元の値に戻す必要があります。このデータ復帰は、2 つのシステムが再接続された後にのみ実行されます。当面、ボリューム A は非コミット・データ・リストのセマンティクスを、ボリューム B からコピーされる必要があるデータに戻します。例えば、ブロック 1000 から 2000 をこの時点ではボリューム B からコピーする必要があります。

12:30 から13:00

ボリューム B が 1 次で、ボリューム A が 2

次であり、カップリングは操作不可

ボリューム A は、操作不可のカップリングで 2 次であるため、変更を受け入れません。ボリューム B は操作不可のカップリングで 1 次になっており、それが 1 次として定義された後に実行された書き込み操作の、非コミット・データ・リストを独自に維持しています。例えば、ホストがブロック 1500 から2500 までを書き込んだ場合、ボリューム B はこれらのブロックにボリューム A にコピーするものとしてマーキングします。

13:00 接続の再開ボリューム B とボリューム A が通信を行い、ボリューム B

がコミットされていないデータのリストをマージします。ボリューム B は、12:30 から 13:00 の間にボリューム B で変更されたブロックを、12:00 から 12:30 の間にボリューム A で変更されたブロックとともに、ボリューム A にコピーします。例えば、ボリューム B がボリューム A にブロック 1000 から2500 までをコピーするとします。この場合、ブロック 1000 から 1500 は、12:00 時点の元の値に戻され、ブロック 1500 から2500 には、12:30 から 13:00 の間にボリューム B に書き込まれた値が入ります。12:00 から 12:30 の間にボリューム A に書き込まれた変更は失われます。

両サイドが同じ役割を持つ場合の再接続リンクのダウン中に一方のサイドが切り替わった場合の発生事象

両サイドが同じ役割に構成されている状態は、リンクがダウンしている間に一方のサイドが切り替えられた場合に発生します。これはユーザー・エラーであるため、ユーザーは以下のガイドラインに従ってこの状態が起きないようにする必要があります。

v リンクが再開する前に両サイドで役割を変更する必要があります。

v 安全策として、最初に 1 次から 2 次への切り替えをすることが推奨されます。

リンクが再開されて、両サイドが同じ役割を持っている場合、カップリングは操作可能になりません。

この問題を解決するには、ユーザーはいずれかのボリュームで役割切り替えメカニズムを使用し、その後にカップリングを活動化する必要があります。

この状態では、システムは以下のように動作します。


v 両サイドが 2 次ボリュームとして構成されている場合、マイナー・エラーが発行されます。

v 両サイドが 1 次ボリュームとして構成されている場合、クリティカル・エラーが発行されます。この状態が解決されるまでは、リモート・ミラーリングが操作不可の状態で両方のボリュームがローカルで更新されます。

その他

リモート・ミラーリングと整合性グループ整合性グループは、ミラーリングと互換性がなければなりません。

以下の前提のもとで、整合性グループの手順がリモート・ミラーリング機能に対応します。

v 整合性グループ内のすべてのボリュームが同一システム上でミラーリングされる(システム上のすべての 1 次ボリュームは同一システム上でミラーリングされるため)。

v 整合性グループ内のすべてのボリュームが同じ役割を持っている。

v last_consistent スナップショットはシステム全体で作成および削除されるため、整合性グループ全体で整合性がある。

注: 管理者は、整合性グループ内の一部のボリュームの役割を (他のボリュームは元の役割のままにして) 誤って切り替えてしまう場合があります。これはシステムでは防ぐことができず、アプリケーション・レベルで検出されます。

メディア・エラー・リカバリーのためのリモート・ミラーリングの使用

カップリングのボリュームのいずれかでメディア・エラーが検出されると、ピア・ボリュームがリカバリーに使用されます。

サポートされる構成同期ミラーリングは、以下の構成をサポートします。

v ファイバー・チャネルまたは iSCSI が、1 次ボリュームと 2 次ボリュームの間のプロトコルとして機能することができます。一方のプロトコルを介してアクセスされたボリュームを、他方のプロトコルを使用して同期化することが可能です。

v リモート・ターゲットの接続定義で、XIV としてリモート・システムを定義する必要があります。

v システム上の同じ整合性グループに属しているボリュームのピアは、すべて単一のリモート・システム上になければなりません。

v 1 次ボリュームと 2 次ボリュームのブロック数は、同じでなければなりません。

入出力パフォーマンスと同期速度の最適化リソースが使い尽くされないようにするために、同期速度を調整することができます。


IBM XIV Storage System には 2 つのグローバル・パラメーターがあり、これらが初期の同期に使用される最大速度、およびカップリングが操作不可になった後の同期に使用される最大速度を制御します。

これらの速度は、同期によって使用されるシステム・リソースや通信回線リソースが過剰になる状態を回避するために使用されます。

この構成パラメーターはいつでも変更できます。これらのパラメーターの設定は、IBM XIV Storage System 技術サポート担当員が行います。

その他のコマンドに関する注記同期ミラーリングを使用すると、ボリュームおよびスナップショットの管理で暗黙に見なされることがいくつかあります。

v ボリュームの名前を変更すると、last_consistent スナップショットおよびmost_updated スナップショットの名前が変更されます。

v すべてのスナップショットを削除しても、last_consistent スナップショットおよびmost_updated スナップショットは削除されません。

v 1 次ボリュームをサイズ変更すると、その 2 次ボリュームがサイズ変更されます。

v リンクがダウンしているときは、1 次ボリュームをサイズ変更できません。

v 2 次ボリュームではサイズ変更、削除、およびフォーマットは許可されません。

v 1 次ボリュームはフォーマットできません。1 次ボリュームをフォーマットする必要がある場合、管理者が、最初にミラーリングを非活動化したうえでミラーリングを削除し、2 次ボリュームと 1 次ボリュームの両方をフォーマットしてから、ミラーリングを再定義する必要があります。

v 2 次ボリュームまたは 1 次ボリュームはコピー操作のターゲットにはできません。

v 2 次ボリュームではロックまたはアンロックは許可されません。

v last_consistent スナップショットおよび most_updated スナップショットはアンロックできません。

v 1 次ボリュームでの削除は許可されません。

v 1 次ボリュームでのスナップショットからの復元は許可されません。

v 2 次ボリュームでのスナップショットからの復元は許可されません。

v last_consistent スナップショットまたは most_updated スナップショットと同じ名前のスナップショットは作成できません。


第 7 章非同期リモート・ミラーリング

非同期ミラーリングにより、1 次ストレージ・ピアに記録されているデータ更新をリモート 2 次ピアに非同期的に複製するプロセスを介して、重要なデータの高可用性を実現することができます。

非同期ミラーリングと同期ミラーリングの相対的な利点は、次の 2 つの重要な目標に照らしてこれらのミラーリングを検討したときに、もっとも明確になります。

v ストレージ・システムの反応性

v ミラーリングされたデータの現行性

同期ミラーリングを使用する場合、ホスト書き込みは、ミラーリング関係にある両方のピアで記録されて初めて、ストレージ・システムによって確認応答が発行されます。これにより、ミラーリングされたデータの現行性は高くなります (両方のミラーリング・ピアに同じデータがあります)。しかし、リモート・ピアがホスト書き込みの確認応答を発行するまでローカル・ピアはホスト書き込みの確認応答を発行することができないので、結果として最良のシステム反応性は得られません。このタイプのプロセスでは、ピア間の距離が増大するにしたがって待ち時間も増大します。

XIV を特徴付けるのは、非同期ミラーリングと同期ミラーリングの両方です。非同期ミラーリングは、さまざまなユース・ケースで有利です。非同期ミラーリングは、離れたサイト間で複製を行う必要がある状態での強力なミラーリング・ソリューションを表します。これは、非同期ミラーリングが同期ミラーリングに固有の待ち時間を解消し、実装コストを引き下げることがあるからです。非同期ミラーリングを注意深く計画することにより、ミラーリング・ピア間の現行性ギャップを最小化し、より良いデータ可用性およびコスト削減を実現するのに役立てることができます。

同期ミラーリング (下記の最初の図) を使用した場合、ピア間の距離が増大するにつれて応答時間 (待ち時間) が増大しますが、両方のピアは同期化されます。非同期ミラーリング (下記の 2 番目の図) を使用した場合、応答時間はピア間の距離による影響を受けませんが、ピア間の同期ギャップは距離による影響を受けやすくなります。


注: 同期ミラーリングについては、 57ページの『第 6 章同期リモート・ミラーリング』で説明しています。

章の範囲この章では、XIV 非同期ミラーリング機能の以下の重要な側面を示します。

v フィーチャーのハイライト

v 用語

v 仕様

v XIV 非同期ミラーリングのテクノロジーの概要

v XIV 非同期ミラーリングの初期化

v XIV 非同期ミラーリング・プロセスのウォークスルー

v XIV 非同期ミラーリングの管理

v 整合性グループの非同期ミラーリング

v XIV 非同期ミラーリングを用いた災害時回復シナリオの提供

v XIV 非同期ミラーリングの分析

フィーチャーのハイライトIBM XIV Storage System は、固有の長所を持つ先進ミラーリング・ソリューションを実現するために XIV の既存のテクノロジーと新規テクノロジーを融合させています。

KLマスターMN

ミラーリング

PQ?RのずれがUV

ホスト

2

34

1

xiv

pogen3020

図 19. 同期ミラーリングでは応答時間のずれが拡大

ホスト

xiv

pogen3021

KLマスターXMN

ミラーリング

ピアRのMNギャップ

2

3

4

1

図 20. 非同期ミラーリング - 応答時間のずれは拡大しない


IBM XIV Storage System 非同期ミラーリングのハイライトを以下に示します。

スナップショット・ベースの拡張テクノロジーIBM XIV の非同期ミラーリングは、XIV スナップショット・テクノロジーに基づいています。このテクノロジーは、一般的なシステム・パフォーマンスに対する影響を最小化しながら、実装を合理化します。このテクノロジーは、以前に同期ミラーリングで効果的に使用された機能を活用し、全部のシステムのミラーリング (数百または数千のミラーへの変換) をサポートするように設計されています。

整合性グループのミラーリングIBM XIV は、ミラーリングされた整合性グループの定義をサポートします。これは、企業にとって非常に都合が良く、1 つの整合性グループに属するすべてのボリュームの複製の管理を容易にします。これにより、1 次サイトが使用できないときに、リモート・サイトから整合性のあるボリューム・グループの合理的な修復を可能にします。

自動および手動の複製非同期ミラーリングでは、インターバルに基づいて自動的に変更を複製できるようにユーザー構成が可能なスケジュールを割り当てることも、手動の(またはスクリプト化された) ユーザー・コマンドの発行時に変更を複製するように構成することも可能です。手動複製により、必要に応じてアプリケーションと矛盾しないレプリカを設定できるのに対して、自動複製ではクラッシュと矛盾しないレプリカを設定できます。 XIV 実装環境では、ミラーをスケジュールされた複製で定義することも、必要に応じてミラーに手動の複製ジョブを実行することもできるため、この両方の方式を組み合わせることができます。

複数の RPO および複数のスケジュールIBM XIV 非同期ミラーリングにより、単一の RPO をすべてのミラーに強制するのではなく、各ミラーに異なる RPO を指定することができます。これにより、一部のミラーの複製を他より優先できるようになるため、アプリケーション RPO 要件や帯域幅の制約に合わせることもより容易になる可能性があります。

柔軟で独立したミラーリング・インターバルIBM XIV 非同期ミラーリングでは、20 秒から 12 時間の範囲のインターバルを指定したスケジュールをサポートします。さらに、インターバルはミラーリング RPO から独立しています。このことにより、帯域幅の制約およびさまざまな RPO に対応するために複製を微調整する能力が強化されます。

柔軟なプール管理IBM XIV 非同期ミラーリングにより、シン・プロビジョニングされたプールに保管されるボリュームおよび整合性グループのミラーリングが可能になります。これは両方のミラーリング・ピアに適用されます。

双方向ミラーリングIBM XIV システムは、複数のミラー・ソースおよびミラー・ターゲットを同時にホストし、システムごとに 1000 個を超えるミラーをサポートすることができます。さらに、任意の IBM XIV Storage System が、他の複数のIBM XIV システムとミラーリング関係をもつことができます。このことにより、ミラーリング構成の設定が非常に柔軟になります。

第 7 章非同期リモート・ミラーリング 79

Storage System とミラーリング関係をもつことができるシステムの数は、本資料の外で指定されています (IBM XIV Storage System Data Sheet を参照)。

同期および非同期の同時ミラーリングIBM XIV Storage System は、同期ミラーと非同期ミラーを同時に実行することができます。

ピアの役割間の容易な移行IBM XIV のミラー・ピアは、マスターとスレーブ間で容易に移行が可能です。

独立ボリューム・ミラーから整合性グループ・ミラーへの容易な移行IBM XIV Storage System では、当該ボリュームのミラーリングを維持しながら、整合性グループ・ミラーの構成、ミラーリングされた整合性グループへのミラーリングされたボリュームの追加、およびミラーリングされた整合性グループからのボリュームの削除を容易に行うことができます。

ターゲットごとの同期速度の制御非同期ミラーリング実装により、管理者はターゲット・システムごとに異なるシステム・ミラーリング速度を構成することができます。

広範囲のモニターおよびイベントIBM XIV システムは、イベントを生成し、ミラーリング・パフォーマンスを評価するために使用できる重要なデータを生成する重要な非同期ミラーリング関連のプロセスをモニターします。

スクリプトによる容易な自動化すべての非同期ミラーリング・コマンドは、スクリプトによって自動化することができます。

用語ミラー・カップリング (場合によってはカップリングと呼ばれます)

ミラーリング関係に関与するストレージ・ピア (ボリュームまたは整合性グループのいずれか) のペア化。

マスターとスレーブミラー・カップリングのデータ複製用のソースおよびターゲットのストレージ・ピアに対応する役割。これらの役割はミラーの作成後に、お客様のニーズに合わせて、またフェイルオーバーおよびフェイルバックのシナリオをサポートするために、システム管理者により変更できます。有効なミラーは、マスター・ピアとスレーブ・ピアをそれぞれ 1 つだけ持つことができます。

ピア指定カップリング・ピアに関連付けられた指定について記述するユーザー構成可能なミラーリング属性。マスターはデフォルトにより 1 次ピアとして指定され、スレーブはデフォルトにより 2 次ピアとして指定されます。これらの値は、ミラーの作成後に実行された役割変更に関係なく、元のピアの指定の参照として使用されますが、ピアの役割 (マスターまたはスレーブのいずれか) と取り違えてはなりません。


最終複製スナップショット (last_replicated スナップショット)スレーブに複製されたことが確認されている最後のマスターの状態を表すスナップショット。

最新のスナップショット (most_recent スナップショット)カップリングが災害時に復帰できる、最後に同期化されたマスターの状態を表すスナップショット。

同期ジョブ (Sync Job)last_replicated スナップショットがとられて以降にマスター上に記録されたすべてのデータ更新の複製を受け持つミラーリング・プロセス。これらの更新はスレーブに複製されます。

スケジュール関連するミラー・カップリングに対して同期ジョブが作成される頻度を指定する管理オブジェクト。

インターバル連続する同期ジョブ間の期間を示すスケジュール・パラメーター。

RPO リカバリー・ポイント目標 (Recovery Point Objective) – マスターとスレーブの間で受け入れ可能な最大データ同期ギャップの目標。マスターに障害が生じた場合またはマスターが利用できない場合の許容データ損失の指標 (時間単位で表される)。

RTO リカバリー時間目標 (Recovery Time Objective) - マスターに障害が生じた後またはマスターが利用できなくなった後にサービスを復元するまでの最大時間の目標。

仕様

ミラーリング操作には、以下の仕様が適用されます。

最小リンク帯域幅10Mbps。

推奨リンク帯域幅20Mbps 以上。

最大往復待ち時間250ms。

ミラーリング用の XIV システムの接続2 つの XIV システム間の接続は SAN を経由する必要があります。

技術概要IBM XIV Storage System の非同期ミラーリングは、既存のテクノロジーと新しいテクノロジーを融合しています。

非同期ミラーリングの実装環境は、スナップショットに基づいており、自動および手動でのミラーリングを確立できることが特徴です。このミラーリングは、向上した柔軟性を備えており、各ミラー・カップリングごとに異なる RPO を割り当てることができます。 RPO とは無関係に各ミラーごとに異なるスケジュールを指定できることで、すべてのミラーを同じミラーリング・パラメーターで制約することな


く、特別なミラーリングの優先順位付けの要件に対応することが可能になります。以降の段落は、以下の IBM XIV 非同期ミラーリングの特徴、テクノロジー、および概念の詳細を示しています。

v 複製スキーム

v スナップショット・ベースのテクノロジー

v IBM XIV 非同期ミラーリングの特殊スナップショット

v IBM XIV 非同期ミラーリングの初期化

v ミラーリングの複製単位: 同期ジョブ

v ミラーリングのスケジュールおよびインターバル

v 手動 (随時) 同期ジョブ

v RPO によるミラー状態の判別

v ミラーリングされた整合性グループ

v IBM XIV 非同期ミラーリングおよびプール・スペースの枯渇

複製スキームIBM XIV の非同期ミラーリングは、IBM XIV Storage System と他の XIV システムの間のミラーリング関係の確立をサポートします。

これらの関係のそれぞれは同期または非同期とすることができ、システムは、1 つの関係ではマスターとして、別の関係ではスレーブとして同時に動作することができます。非同期ミラーリングに関する実際的な距離の制限事項もありません。すなわち、ミラーリング・ピアは同じ大都市圏に配置することも離れた大陸に配置することもできます。

IBM XIV Storage System のそれぞれは、他の IBM XIV Storage System とのミラーリング関係をもつことができます。各ターゲットとの複数の並行ミラーリング関係がサポートされます。


スナップショット・ベースのテクノロジーIBM XIV は、さまざまなリカバリー目標を含んだ並行ミラーを促進する非同期ミラーリングに関する革新的なスナップショット・ベースのテクノロジーを特色にします。

IBM XIV 非同期ミラーリングを使用すると、マスター上の書き込み順序はスレーブ上には保持されません。結果として、任意の時点でスレーブについて取得されるスナップショットは不整合である可能性が高いため、無効です。マスターに障害が生じた場合またはマスターを利用できない場合にデータの高可用性を確保するには、サービスの継続性を確保できるマスターの整合性のあるレプリカを維持することが不可欠です。

これは XIV スナップショットを使用して達成されます。XIV 非同期ミラーリングは、マスターの状態を記録するためにスナップショットを使用し、さらに、対応する複製プロセスの一環としてマスターからスレーブにコピーする必要があるデータを判別するために、連続するスナップショット間の差分を算定します。複製プロセスの完了時に、スレーブについてのスナップショットがとられ、そのスナップショットはマスターの有効なレプリカを反映します。

スナップショット・ベースのテクノロジーが効果的な非同期ミラーリングの実現にいかに役立つかを説明する、精選された技術的プロパティーを以下に示します。

システム A システム B

ミラーリングされたマスター

CG


CG

ミラーリングされた CG��



CG

システム A システム B


ミラーリングされたボリューム��

ミラーリングされたボリュームマスター

xivpogen3022

図 21. 複製スキーム


v 実質的に数が無制限のスナップショットに関する XIV サポートは、サポートされているミラーリング済みボリュームの数に実質的に制限がない完全なシステムのミラーリングを促進します。

v XIV は、ディスク・アクセスを最小限に抑えることで達成できるパフォーマンスをさらに最大化するメモリー最適化手法を実装します。

特殊スナップショットのミラーリング同期化処理の状況および有効範囲は、スナップショットを使用して判別されます。

以下の 2 つの特殊なスナップショットが使用されます。

most_recent スナップショット (MRS)このスナップショットは、新規複製プロセス (同期ジョブ – 下記参照) の作成前に、マスターについて取得される最新のスナップショットです (ボリュームまたは整合性グループのいずれかです)。このスナップショットは、マスター上にのみ存在します。

last_replicated スナップショット (LRS)これは、スレーブに完全に複製されたことが確認される最新のスナップショットです。マスターとスレーブの両方がこのスナップショットを保持します。スレーブでは、このスナップショットは複製プロセスの完了時にとられ、この名前をもつ以前のスナップショットと置き換わります。マスターでは、スレーブがマスターの most_recent スナップショットの対応するレプリカをもっていることが確認された後で、most_recent スナップショットの名前が last_replicated に変更されます。

XIV は、ミラー・カップリングごとに 3 つのスナップショット (マスター上に 2

つ、スレーブ上に 1 つ) を保持します。マスターの有効な (リカバリー可能な) 状態は、last_replicated スナップショットに取り込まれ、さらにスレーブ上の同一スナップショットに取り込まれます。この most_recent スナップショットは、マスターの最新の状態を表し、次にスレーブに複製する必要があります。システムは、マスターのスナップショットを比較して、複製するデータを判別します。

ローカル・サイトリモート・サイト

マスターピアmost_recent

KLピア

9:

Last_replicated Last_replicatedxiv

pogen3023

図 22. 特殊なスナップショットの場所


ミラーリングの初期化XIV ミラーは、CLI または GUI を使用して容易に作成することができます。まず、ミラーを作成して活動化し、次に初期化フェーズを開始します。

XIV ミラーは、スタンバイ状態で作成されるため、明示的に活動化する必要があります。初期化フェーズ中に、システムはマスターの状態の有効なレプリカをスレーブ上に生成します。初期化が完了するまでは、マスターの回復に役立つ (災害が発生した場合) 有効なレプリカはスレーブ上にありません。初期化フェーズが終了すると、スレーブのスナップショットが作成されます。このスナップショットは、マスターの有効なレプリカであり、災害時回復シナリオにおいて整合性のあるマスターの状態を復元するのに使用できます。

初期化では、以下のステップが実行されます (すべてが 1 つのアトミック操作の一部として)。

マスターがスレーブの初期化を開始新規ミラーが定義されると、マスターのスナップショットが作成されます。このスナップショットは、そのミラーを実行する前のマスターの初期状態を表します。初期化の目的は、この状態をスレーブに反映することです。

初期化が終了初期化が終了すると、進行中のミラーリングが同期ジョブを開始します。

確認応答スレーブはマスターに対して初期化の完了を確認応答します。

マスター KL?@

^_

`a

bNcde

xiv

pogen3024

図 23. ネットワーク経由での非同期ミラーリングの初期化


スレーブへのマスターのオフライン複製IBM XIV Storage System では、このボリューム・レプリカをスレーブにオフライン転送することができます。

ミラーの初期化の最初に、ユーザーはマスターからスレーブにどのボリュームを複製するかを示します。通常、マスターのこのレプリカは、短期間の間に生じる差分を累積するスケジュール・ベースのレプリカよりはるかに大きなサイズになります。 IBM XIV Storage System では、このボリューム・レプリカをスレーブにオフライン転送することができます。この転送方式は「トラック・モード」と呼ばれることがあり、mirror_create コマンドによって利用できます。

ミラーのオフライン初期化では、サイト間リンクを使用せずにマスターがスレーブに複製されます。オフライン複製では以下の操作が必要です。

v ミラーリングするボリュームの指定

v ミラー作成コマンドへの初期化タイプの指定

v ミラーリングの活動化

上記の要件を満たすと、システムはマスターのスナップショットを取得し、スレーブ・ボリュームと比較します。差分が見つかった領域のみが初期化の一環として複製されます。続いて、スレーブ・ピアの内容がマスターと照合して検査され、そのまま単純に有効なレプリカと見なされることはありません。この検査を行うと、マスターとスレーブの間の使用可能帯域幅、およびレプリカがマスター・ボリュームと同一である (すなわち、初期化の間にマスターへの書き込みがなかった) かどうかを考慮に入れることで、初期化時間が最適化されます。

同期ジョブマスターとスレーブの間でのデータの同期は、同期ジョブと呼ばれるマスターが実行する処理によって実現されます。

同期ジョブは、前回の同期ジョブが作成されて以降にマスター上に記録されたすべてのデータでスレーブを更新します。この処理は、ユーザーが構成可能なスケジュールに基づいて自動で開始することも、ユーザーが発行するコマンドに基づいて手動で開始することもできます。

同期ジョブの一環として複製するデータの計算同期ジョブが開始されると、その時点でのマスターの状態のスナップショットが作成されます (most_recent_snapshot)。

未処理の同期ジョブがすべて完了すると、システムはこのスナップショットと最新のマスター・スナップショットとの間のデータ差分を計算します。最新のマスター・スナップショットは、スレーブ上の整合性のあるレプリカ(last_replicated_snapshot) と一致します。この差分は、同期ジョブが次に複製するデータを構成します。

複製は、ミラーリング・ピア間のデータ差分のみをコピーするため、非常に効率的です。例えば、マスター上で単一ブロックのみが変更された場合、単一ブロックのみがスレーブに複製されます。


ミラーリングのスケジュールおよびインターバルIBM XIV Storage System は、繰り返し非同期ミラーリング・プロセスの促進に使用されるスケジューリング・メカニズムを実装します。

各非同期ミラーには指定されたスケジュールがあり、そのスケジュールのインターバルは、同期ジョブがそのミラーに対して作成される頻度を示します。

非同期ミラーリングには、以下のフィーチャーがあります。

v スケジュールの概念。スケジュールは、同期ジョブの自動作成用のインターバルを示します。新規同期ジョブは通常、新規インターバルに達したときに作成されます。

v 同期ジョブは、新規インターバルに達したときに、スケジュールに入れられた別の同期ジョブが実行中の場合は作成されません。

v カスタム・スケジュールは、ユーザー別に作成することができます。

v スケジュール・インターバルは、30 秒、1 分、2 分、5 分、10 分、15 分、30

分、1 時間、2 時間、3 時間、6 時間、8 時間、12 時間のいずれかの値に設定することができます。スケジュールの開始時間は 00:00 です。

注: IBM XIV Storage System は、20 秒のインターバルを指定した min_interval

と呼ばれる組み込まれた構成不能のスケジュールを提供します。指定できるのは、この事前定義スケジュールを使用した 20 秒のスケジュールのみです。

ホスト fきhみ

Ack

マスター

MNジョブde

KL

?@

^_

`a

マスターのジョブ`a

xiv

po

ge

n3

02

5

図 24. 非同期ミラーリングの同期ジョブ


v ミラーを作成する場合、2 つのスケジュールがピアごとに 1 つ指定されます。スレーブのスケジュールは、XIV またはサード・パーティー・プロセスによって制御されるフェイルオーバー・シナリオの簡素化に役立てることができます。

v 1 つのスケジュールは、同じシステム上の複数のカップリングによって参照することができます。

v 同じスケジュールを使用したミラー用の同期ジョブ作成は、まったく同時に行われます。これは、同じインターバルを指定したさまざまなスケジュールをもつミラーと対照的です。同じインターバルをもつにもかかわらず、これらのタイプのミラーの同期ジョブは同時に行われるように保証されていません。

v Never と呼ばれる固有のスケジュールは、該当するミラーのために同期ジョブが自動的に作成されないことを示すために用意されています (下記参照)。

スケジュールは単一 XIV システムに対してはローカルである

スケジュールは、スケジュールが定義されてシステム間関係とは独立して設定される XIV システムに対してはローカルです。ソースからターゲットへの所定の複製スケジュールには、反転複製のためにターゲット上で定義される同一スケジュールが要求されません。反転複製のために同一スケジュールを維持するには (マスターとスレーブの役割を変更する必要がある場合)、独立した同一スケジュールを両方のピアに定義する必要があります。

時差に対するスケジュールの感度

ミラーリング・カップルのピアのスケジュールは、時差の影響を受けない方法で定義する必要があります。例えば、マスター・サイトとスレーブ・サイトの間の時差が 2 時間であり、インターバルが 3 時間であり、一方のピアのスケジュールが(12PM、3AM、6AM、...) の場合は、他方のピアのスケジュールは(2AM、5AM、8AM) にする必要があります。シフトされたスケジュール (例えば、2 時間の時差と 1 時間のインターバル) を要求しないケースがありますが、この問題を見過ごすことはできません。

マスターもスレーブも、クロックを同期化する必要があります (例えば、NTP を使用して)。このような同期を行わないと、スケジュール関連の測定 (主に RPO) を妨げる可能性があります。

Never スケジュール

システムは、インターバルのないスケジュールを示す Never と呼ばれる特殊な構成不能のスケジュールを特色にします。このスケジュールは、ミラー用に自動的に作成される同期ジョブがないため、指定された手動コマンドを使用することによってのみミラー用の複製を実行できることを示します。

注: 手動スナップショット・ミラーは、ユーザー定義のスケジュールが割り当てられるすべてのミラーに対して実行することができます。

ミラー・スナップショット (随時同期ジョブ)スケジュール・ベースのオプションの使用に加えて、ミラー・スナップショットを実行するための専用コマンドを手動で発行することができます。


このタイプのミラー・スナップショットは、スケジュールの有無に関係なく、カップリングに対して発行することができます。このコマンドは、マスター上で新規スナップショットを作成し、未処理の同期ジョブの後ろでキューに入れられている同期ジョブを手動で開始します。

ミラー・スナップショットは、以下の目的で使用されます。

v 手動複製ポイントを予定複製プロセスに追加するためのニーズに対応する。

v アプリケーションと整合性のあるレプリカを作成する (整合性が予定複製を介して達成されない場合)。

以下の特性は、非同期ミラーリング・プロセスの手動開始に適用されます。

v 複数のミラー・スナップショット・コマンドを発行できます。この場合、手動で発行できるミラー・スナップショットの数の上限はありません。

v 新規インターバルに達したときに実行中のミラー・スナップショットは、実行する予定になっている次のインターバル・ベースのミラーの開始を遅らせますが、この同期ジョブの作成は取り消しません。

– インターバル・ベースのミラー・スナップショットは、実行中のスナップショット・ミラー (随時) がまだ終了していない場合にのみ取り消されます。

これらの相違点以外は、手動で開始された同期ジョブは、通常のインターバル・ベースの同期ジョブと同一です。

複製状態およびミラー状態の判別ミラー状態は、マスターがユーザーによって指定される目標に従ってミラーリングされるかどうかを示します。

非同期ミラーリングではマスター状態とスレーブ状態の間に存在することがある差が許されるので、ユーザーは、ミラーの制限目標、すなわちリカバリー・ポイント目標 (RPO) を指定する必要があります。システムは、マスターのレプリカがスレーブ上にあるかどうかを検査して、ミラー状態を判別します。スレーブ上のマスター・レプリカが RPO で指定されている目標より新しい場合にのみ、ミラー状態はOK であるとみなされます。

RPO および RTO同期状況の評価は、ミラーの RPO 値に基づいて行われます。RPO と RTO の間の相違点に注意してください。

RPO リカバリー・ポイント目標を意味し、マスターに障害が生じた場合またはマスターが利用できない場合に受け入れることができる最大データ損失の指標を表します。

RPO 単位管理者は、各ミラーに RPO を時間単位で設定する必要があります。有効な RPO 値は、30 秒から 24 時間までの範囲内の値です。60 秒という RPO 値は、スレーブの状態がマスターの状態より 60

秒を超えて古いものであってはならないことを示します。RPO が欠落している場合はユーザーに警告を出すようにシステムに指示することができます。また、システムのミラーリング用の内部優先順位付けプロセスも調整されます。


RTO リカバリー・ターゲット目標を意味し、マスターに障害が生じた場合またはマスターが利用できない場合にシステムがリカバリーに要する時間を表します。

ミラーの RTO は XIV では管理されません。

ミラー状況の値ミラー状況は、ミラー状態およびミラーリング状況に基づいて判別されます。

複製中はマスターでの書き込み順序が維持されないため、同期ジョブの進行中およびそのジョブが完了するまではスレーブ・レプリカは不整合な状態です。この状態を不整合として報告する代わりに、ミラー状態が、スレーブの last_replicated スナップショットのタイム・スタンプに基づいて以下のいずれかとして報告されます。

RPO_OK同期が存在し、その RPO 目標を達成しています。

RPO_Lagging同期は存在しますが、その RPO 目標からの遅れが生じています。

初期化中ミラーが初期化中です。

ミラー状態およびミラー状況の定義:

ミラー状況は、ミラー状態およびミラーリング状況に基づいて判別されます。

ミラー状態複製中はマスターでの書き込み順序が維持されないため、同期ジョブの進行中およびそのジョブが完了するまではスレーブ・レプリカは不整合な状態です。この状態を不整合として報告する代わりに、ミラー状態が、スレーブのlast_replicated スナップショットのタイム・スタンプに基づいて以下のいずれかとして報告されます。

RPO_OK の定義同期が存在し、その RPO 目標を達成しています。

RPO_Lagging の定義同期は存在しますが、その RPO 目標からの遅れが生じています。

初期化中ミラーが初期化中です。

ミラーリング状況ミラーリング状況は複製プロセスの状況を示し、活動化状態とリンク状態を反映します。

有効リカバリー現行性現在時刻と last_replicated_snapshot のタイム・スタンプとの間のデルタとして測定されます。

RPO_OK を宣言有効リカバリー現行性が正です。


RPO_Lagging を宣言有効リカバリー現行性が負です。

ミラー状況の判別方法の例:

ミラーリング状況は複製プロセスの状況を示し、活動化状態とリンク状態を反映します。

以下の例は、ミラーリング状況の判別方法を図とともに示しています。 time 軸は同期ジョブの時刻とスケジュールを示しています (t0 から t5)。図の上部には、両方のRPO 状態が赤と緑で表示されています。

最初の同期ジョブ - RPO は OK

時刻: t0

同期ジョブが開始します。同期ジョブが t1 より前に終了する限り、RPO_OK が維持されます。

時刻: ta

同期ジョブは t1 より前の ta に終了しているため、状況は RPO_OK です。

有効リカバリー現行性同期ジョブの実行中、有効リカバリー現行性の値 (図の上部にある黒のグラフ) は変化します。この値は、t0 から遠のくにつれて上昇し、同期ジョブが完了すると (RPO 設定へと) 下降し、次のスケジュールに到達しない限り上昇は再開しません。

RPO_OK

lmリカバリーneC

last_replicatedスナップショット RPOop

t

xiv

pogen3026

図 25. RPO_OK の判別方法

RPO_Lagging

lmリカバリーneC

RPOop last_replicatedスナップショット

t

xiv

pogen3027

図 26. RPO_Lagging の判別方法


第 2 の同期ジョブ - RPO に対する遅れが生じている

時刻: t1

同期ジョブが開始します。同期ジョブが t2 より前に終了する限り、RPO_OK が維持されます。

時刻: t2

同期ジョブはこの時点で終了していなければなりませんが、まだ実行中です。

この特定時点で実行するようにスケジュールされていた同期ジョブは取り消されます。

時刻: tb

この同期ジョブは t2 より後の tb に終了しているため、状況はRPO_Lagging です。

有効リカバリー現行性有効リカバリー現行性 k.jpg の値は、次の同期ジョブが終了しない限り上昇します。

図 27. 非同期ミラーリング状況の判別 - 例 (パート 1)



第 3 の同期ジョブ - RPO は OK

時刻: t3

新規同期ジョブが開始します。この時点での状況は RPO_Lagging です。

時刻: tc

この同期ジョブは t4 より前に終了しているため、状況は RPO_OK です。

有効リカバリー現行性有効リカバリー現行性 k.jpg の値は、次の同期ジョブが終了する (tc の時点) まで上昇します。この値は直ちに RPO 設定に戻り、次のスケジュール時刻までそのまま維持されます。

複数の RPO の付加価値

システムは、その内部における複製の優先順位付けをミラーの RPO に基づいて行います。したがって、実際のリカバリー目標に対応する複数の RPO をサポートすることが、複製に使用できる帯域幅の最適化に役立ちます。

複数のスケジュールの付加価値

複数のスケジュール・インターバル・オプションを使用することで、ターゲットRPO を達成できます。 RPO から分離した可変のスケジュールを設定することが複製プロセスの最適化に役立ち、必ずしも RPO を変更しなくても RPO の要件に対応できます。

ミラーリングされた整合性グループIBM XIV では、ミラーリングされた整合性グループおよびボリュームのミラーリングによって、ミラー・グループを容易に管理することができます。

整合性グループの非同期ミラーリングは、ボリュームで採用されている方法と同じ方法 (すなわち、スケジュールに基づくか、専用のコマンド・オプションを使用して手動で) でマスター整合性グループのスナップショット・グループを取得することにより実施されます。



ピア同期および状況は、ボリューム・レベルではなく整合性グループ・レベルで管理されます。これは、管理操作が整合性グループ全体に対して実施され、整合性グループ内の特定のボリュームに対して実施されるのではないことを意味します。これには、活動化などの操作、およびスケジュールなどのミラー全体の設定が含まれます。

整合性グループの同期状況は、整合性グループに属するすべてのミラーリングされたボリュームの状況を結合した内容を反映します。この状況は、整合性グループ内の各ボリュームの (システムが内部で保持する) 状況を調べて判別されます。すべてのボリュームで複製が完了し、その状態が RPO_OK であれば、整合性グループのミラー状況も常に RPO_OK です。逆に、複製が未完了であるか、ミラーリングされた整合性グループのいずれかのボリュームの状況が RPO_Lagging であると、整合性グループのミラー状態も RPO_Lagging になります。

ミラーリングに必要なストレージ・スペースIBM XIV により、マスターとスレーブの両方のシン・プロビジョニングされたプールに関するミラーリングに必要なストレージを管理できます。

ミラーリングの実施期間中、last_replicated および most_recent スナップショットは、ボリュームとそのスナップショットに割り振られたスペースを超過することがあります。マスター上に十分なスペースがない場合は、ホスト書き込みを行えない可能性があります。このときにスレーブ上でもスペースが不足している場合、ミラーリング・プロセス自体を中断させる可能性があります。

IBM XIV により、シン・プロビジョニングされたプールに関するミラーリングに必要なストレージを管理できます。このように、IBM XIV Storage System は、 52ページの『シン・プロビジョニング』の章で説明しているスキームに従ってスペースの管理および割り振りを行います。

各ピアのスペースの枯渇の際に、『プール・スペースの枯渇』のメカニズムは効力を生じます。

プール・スペースの枯渇プール・スペースの枯渇は、ホストが実行する着信書き込み要求のためのスペースが不足してミラーリングが維持できなくなるときはいつでも起こるメカニズムです。

プールに新規ホスト書き込みによって必要とされるストレージ要件に適合する十分な空きスペースがない場合は必ず、システムは、書き込み要求を正常に完了させるために使用できるスペースが十分に確保されるまで、そのプール内のスナップショットを漸次削除する多段階プロシージャーを実行します。

この多段階プロシージャーが漸進的であるということは、現行のステップの実行後に書き込み要求をサポートするためのスペースが引き続き不十分である場合にのみ、システムが次のステップに進むことを意味します。

削除優先順位の設定によるスナップショットの保護:

保護されたスナップショットは、プール・スペースが枯渇するプロセスの間、他のスナップショットより優先します。


保護されたスナップショットの概念により、ストレージ・プールにスナップショットの自動削除優先順位属性と比較される属性が割り当てられます。スナップショットにプールの属性より高いか同等の削除優先順位がある場合には常に、そのスナップショットは保護されているとみなされます。

例えば、枯渇ストレージの削除優先順位が 3 に設定されている場合、システムは、削除優先順位 4 のスナップショットを削除します。優先順位が 1、2、および 3 のスナップショットは削除されません。

枯渇ストレージの削除優先順位が 4 に設定されている場合、システムは、すべてのスナップショットを削除する前にミラーリングを非活動化します。

枯渇ストレージの削除優先順位が 0 に設定されている場合、システムは、削除優先順位に関係なくすべてのスナップショットを削除する可能性があります。

図 30. 枯渇ストレージの削除優先順位が 3 に設定されている



削除優先順位の規則

最終複製スナップショットの削除優先順位の保護ミラー関連のスナップショットの削除優先順位は、システムによって暗黙的に設定され、ユーザーがカスタマイズすることはできません (下記参照)。

最終複製スナップショットと最新のスナップショットマスター上の last_replicated および most_recent 非同期ミラーリング・スナップショットの削除優先順位は 1 に設定されます。

スレーブ上の最終複製スナップショットスレーブ上の last_replicated スナップショットの削除優先順位は 0 に設定されます (下記参照)。

スナップショット保護 CLI のデフォルト値デフォルトでは、pool_config_snapshots コマンドのprotected_snapshot_priority パラメーターの値は 0 です。

この値の変更protected_snapshot_priority パラメーターが変更された場合、保護された設定と名目上同等かそれより低い削除優先順位のシステム作成スナップショットとユーザー作成スナップショットは、内部ミラーリング・スナップショットが削除された後でのみ、削除されます。

例えば、protected_snapshot_priority が 1 に変更された場合は、削除優先順位 1 のすべてのシステム作成スナップショットとユーザー作成スナップショット (削除優先順位が変更されていないと想定した上で、ユーザーが作成したすべてのスナップショットを含む) は保護され、内部ミラーリング・スナップショットが削除された後でのみ削除されます。

その他のスナップショットミラーリング関連でないスナップショットは、デフォルトでは削除優先順位1 で作成されます。



最終複製スナップショットの保護

最終複製スナップショットは、非同期ミラーリングでのマスターの整合性のあるレプリカを表します。マスターとスレーブの両方に最終複製スナップショットがありますが、これら 2 つのスナップショットは別々に保護されます。

LRSslave

スレーブには常にマスターの使用可能な整合コピーがなければなりませんが、マスターはそのような可用性をもつ必要はありません (LRSmaster 自体が整合性のあるものとみなされるためです)。結果として、このスナップショットが削除されることはありません。スレーブ上でのプール・スペースの枯渇の際は、ミラーリング・プロセス用のスペースがないときはいつでも、プールはロックされます。

スレーブ上の LRS の削除優先順位は 0 です。

LRSmaster

マスター上の最終複製スナップショットは、プール・スペースの枯渇時に削除に使用できます。

マスター上の LRS の削除優先順位は 1 です。

マスター上のプール・スペースの枯渇:

マスター上の枯渇手順は、以下の各ステップから成ります。

ステップ �1� - 無保護スナップショットの削除

以下のスナップショットは削除されます。

v 通常の (ミラーリングに関連しない) スナップショット

v アクティブではなくなったミラーリング・プロセスのスナップショット

v まだ開始されていないスナップショット・ミラー (別名、随時同期ジョブ) のスナップショット

削除は、個々のスナップショットの削除優先順位の影響下にあります。削除優先順位が機能しない場合には、より古いスナップショットが最初に削除されます。

成功基準:ユーザーは操作を再試行し、ミラーリングを再度使用可能にし、複製を再開します。これに失敗した場合、システムはステップ 2 (下記) に進みます。

ステップ �2� - スケジュールに入れられた未解決の (保留) 同期ジョブのスナップショットの削除

ステップ 1 で実行されたアクションの後も引き続き複製が再開しない場合:

以下のスナップショットは削除されます。

v ステップ 1 で削除されなかったすべてのスナップショット。

成功基準:システムは操作を再試行し、ミラーリングを再度使用可能にし、複製を再開します。


ステップ �3� - ミラーリングの自動非活動化および most_recent ミラー・スナップショットとして指定されたスナップショットの削除

複製が引き続き再開しない場合:

次のことが行われます。

v ミラーリングの自動非活動化

v most_recent スナップショットの削除

v イベントが生成されます。

進行中の随時同期ジョブ随時同期ジョブ中に作成されたスナップショットは most_recent スナップショットとしてみなされます。ただし、このスナップショットはそのようなものとして名前が付けられず、その名前のスナップショットでは複製されません。随時同期ジョブの完了後で、かつこの完了の後でのみ、スナップショットが複製され、その複製にはlast_replicated という名前が付けられます。

ミラーリング・プロセスの手動再活動化の場合:

1. ミラーリング活動化状態が「アクティブ」に変更されます。

2. most_recent スナップショットが作成されます。

3. 新規同期ジョブが開始されます。

ステップ �4� - last_replicated スナップショットの削除

さらに多くのスペースが引き続き必要な場合:


v last_replicated スナップショットの削除 (マスター上で)


削除の後:

1. ミラーリングは非活動状態のままにされ、手動で再活動化する必要があります。

2. ミラーリングは変更トラッキング状態に変更されます。マスターへのホスト入出力が追跡されますが、複製は行われません。

3. システムは、last_replicated スナップショットの作成以後に書き込まれたストレージ域にマークを付けます。

ステップ �5� - 変更トラッキング状態のミラーリングを活動化するときに作成される most_recent スナップショットの削除



v most_recent スナップショットの削除 (マスター上で)


削除の後:この状態の most_recent スナップショットを削除すると、マスターにはスナップショットもビットマップもなくなり、完全な初期化が要求されます。このような削除の可能性を最小限にするために、このスナップショットには特殊な (新しい) 削除優先順位が自動的に


割り当てられます。この削除優先順位は、プール内の他のすべてのlast_replicated スナップショットが削除された後でのみシステムがこのスナップショットを削除することを意味します。新しい優先順位は整合性のあるスレーブ・レプリカをもつミラーにのみ割り当てられ、作成されたばかりのミラー (このミラーの最初の状態も初期化)

には割り当てられないということに注意してください。

ステップ �6� - 保護されたスナップショットの削除




v ミラーリングに関係なく、保護されているすべてのスナップショットの削除。これらのスナップショットは、その削除優先順位および経過日数に応じて削除されます。

削除の後:

v マスターの状態が初期化に変更されます (ミラーが開始される初期化フェーズとは区別される)。

v システムは新規書き込みのマーク付けを停止します。

v most_recent スナップショットが作成されます。

v システムは、追跡されたすべての変更を含む同期ジョブを作成して実行します。

v この同期ジョブの完了後に、last_replicated スナップショットがマスター上で作成され、ミラー状態は Effective RPO で保証されたrpo_ok または rpo_lagging に変更されます。

プール・スペースが初期化の間に枯渇した場合:

v マスターの状態は「初期化」のままになります。


v ミラーリングが非活動化されます。

v most_recent スナップショットが削除されます (完全初期化が要求されます)。

初期化中の手動ミラーリング活動化の場合:

v マスターの状態は「初期化」のままになります。

v most_recent スナップショットが作成されます。

v システムは、most_recent スナップショットに基づいて完全初期化を開始します。

スレーブ上のプール・スペースの枯渇:

スレーブ上のプール・スペースの枯渇は、last_replicated スナップショットに使用できるスペースがないことを意味します。この場合、ミラーリングは非活動化されます。

削除優先順位が 0 のスナップショットは、プール・スペースの枯渇プロセスに関係なく、スレーブ・ピア上のシステムによって作成され、かつスペースを解放するた


めに自動的に削除されない特殊なスナップショットです。非同期ミラーリング・スレーブ・ピアには、そのようなスナップショット (last_replicated スナップショット)

が 1 つあります。

非同期ミラーリング・プロセスのウォークスルーこのセクションでは、初期化から始めて最初の予定同期ジョブを完了するまで、非同期ミラーリング関係の作成をウォークスルーします。

ステップ 1新規ミラーを作成するコマンドが発行される時間は 01:00 です。この例では、120

分という RPO および 60 分というスケジュールがミラーに対して指定されます。

ミラーリング・プロセスは最初に、次の複製のためのベースラインを設定する必要があります。これにより、マスターの現在の状態がスレーブ・ピアに複製される初期化プロセスが保証されます。この処理は、一時的にブロックされるホスト書き込みから始まります (1)。マスター・ピアの状態は、マスターの状態のスナップショット (most_recent スナップショット) を取得することにより取り込むことができます(2)。この most_recent スナップショットは、次のスケジュール・ベースのミラーリングのためのベースラインとして使用されます。このスナップショットを作成した後、ホスト書き込みはブロックされなくなり、ストレージ・システムの更新を続行します (3)。この時点では、スレーブ上に存在するスナップショットはありません。

ステップ 2マスターの状態を取り込んだ後、初期化プロセスの一部として複製する必要があるデータが算定されます。この例では、マスターの most_recent スナップショットは、最初の同期ジョブを使用して複製されるデータを表します (4)。

xivpogen3034

リモート・サイト

スレーブ・ピアmost_recentマスターピア

ホスト

ローカル・サイト

図 33. 非同期ミラーリング・ウォークスルー – パート 1


ステップ 3このステップでは、初期化同期ジョブが正常に進行中です。マスターはホスト書き込みを用いた更新が続行されます。これらの更新は、書き込まれる順序、すなわち、最初に 1、次に 2、最終的に 3 で示されます。初期化同期ジョブは、初期マスター・ピアの状態をスレーブ・ピアに複製します (5)。

ホスト


マスターピア most_recent スレーブ・ピア


��されるデータ

xivpogen3035


ホスト




マスターは

ききホスト

によりされます

、

� �


xivpogen3036

��

��

ジョブの



ステップ 4その後、初期化同期ジョブは完了します。初期化同期ジョブの完了後に、スレーブの状態がスナップショット (last_replicated スナップショット) を取得することより取り込まれます (6)。このスナップショットは、most_recent スナップショットで取り込まれたマスターの状態を反映します。この例では、これは初期化フェーズの開始直前の状態です。

ステップ 5このステップでは、マスターの last_replicated スナップショットが作成されます。マスター上の most_recent スナップショットの名前は last_replicated に変更され(7)、マスターが必要に応じて復元できる最新ポイント・イン・タイムを表します(この状態はスレーブの対応するスナップショットで取り込まれるためです)。

初期化フェーズが終了すると、マスター・ピアとスレーブ・ピアは同一の復元時点を持っており、必要に応じてこの時点に戻すことが可能です。

マスターピア

ホスト


most_recent スレーブ・ピア


last_replicated


xivpogen3037

��

��

ジョブの



ステップ 6ミラーのスケジュールに基づいて、初期化フェーズと同様に新規インターバルに達します。すなわち、ホスト書き込みはブロックされ (1)、マスターの新しいmost_recent スナップショットが作成され (2)、この時点でマスター・ピアの状態が反映されます。

ここで、ホスト書き込みがブロックされなくなります (3)。

更新番号 (4) はスナップショットがとられた後で生じ、次の同期ジョブでは反映されません。これは、most_recent スナップショット図の中の色の濃淡を付けたセルで示されます。

xivpogen3038

ホスト




last_replicatedmost_replicated > last_replicated


スレーブ・ピア

xiv

po

ge

n3

03

9

ホスト


マスターピア most_recent


last_replicatedlast_replicated



ステップ 7新規同期ジョブが設定されます。複製されるデータは、マスターの most_recent スナップショットと last_replicated スナップショットの間の差分に基づいて算定されます (4)。

ステップ 8同期ジョブは処理中です。同期ジョブの実行中は、マスターはホスト書き込みを使用した更新が続行されます (更新 5)。

同期ジョブ・データは、データがマスターで記録された順序でスレーブに複製されません。つまり、スレーブ上の更新の順序は異なります。

xivpogen3040

ホスト








ステップ 9同期ジョブは完了します。スレーブの last_replicated スナップショットは削除され(6)、新規 last_replicated スナップショットで (1 回のアトミック操作で) 置き換えられます。

xivpogen3041

ホスト






��ジョブ(Sync Job)


ホスト

ローカル・サイトxivpogen3042





��

��

ジョブの



ステップ 10同期ジョブは、更新されたスレーブの状態を表す新規 last_replicated スナップショットを生成して完了します (7)。

スレーブの last_replicated スナップショットは、most_recent スナップショットで取り込まれたマスターの状態を反映します。この例では、これはミラー・スケジュールのインターバルの初期の状態です。

ステップ 11新規マスター last_replicated スナップショットが作成されました。1 回のトランザクションで、マスター上の現行の last_replicated スナップショットは削除され(8)、most_recent スナップショットの名前は last_replicated に変更されます (9)。

これで、インターバル同期処理は完了します。マスターとスレーブの両方は、同一の復元時点を持っており、必要に応じてこの時点に戻すことが可能です。

xivpogen3043

ホスト







ピアの役割ピアの状況は、カップリング定義内でのピアの役割を示します。

作成後に、カップリングにより、厳密に 1 つのピアがマスター・ピアとなるように設定され、厳密に 1 つのピアがスレーブ・ピアになるように設定されます。各ピアは、以下の状況を持つことができます。

なしピアがカップリング定義の一部ではありません。

マスター複製カップリングでの実際のソース・ピア。このタイプのピアはホスト要求を満たし、スレーブに対する同期更新のソースです。マスター・ピアは、非同期ミラーリングの際に直接、スレーブに変更することができます。

スレーブ複製カップリングでの実際のターゲット・ピア。このタイプのピアは、ホスト要求を満たさず、対応するマスターから同期更新を受け入れます。スレーブは、非同期ミラーリングの際に直接、マスターに変更することができます。

ミラーリングの活動化ミラーリングの状態は、そのコンポーネントの状態から派生します。

リモート・ミラーリング・プロセスは、プロセスに関与するエンティティーの状態を階層的に管理します。リモート・ミラーリング・プロセスは、以下のコンポーネントの状態に基づいてミラーリングの状態を管理します。

v リンク

v 活動化

ミラーリング状態には以下のものがあります。

マスターピア

xivpogen3044

ホスト


last_replicated last_replicated

most_recent スレーブ・ピア




操作不可 (Non-operational)カップリング状態は、以下の 1 つ以上の条件が満たされると、操作不可として定義されます。

v 活動化状態がスタンバイである。

v リンク状態がエラーである。

v スレーブ・ピアがロックされている。

操作可能 (Operational)カップリングを操作可能として定義するには、以下のすべての条件を満たしていなければなりません。

v 活動化状態がアクティブである。

v リンクが OK である。

v ピアの役割がそれぞれ異なっている。

v スレーブ・ピアがロックされていない。

リンク状態リンク状態は、カップリング操作可能状況を決定する要因の 1 つです。

リンク状態は、マスターからスレーブへの接続を反映します。障害のあるリンクおよび障害のあるスレーブ・システムは、どちらもリンク・エラーとして示されます。リンク状態は、カップリング操作可能状況を決定する要因の 1 つです。

リンク状態には、以下のものがあります。

OK リンクは作動し機能しています。

エラーリンクがダウンしています。

活動化状態カップリングが作成されると、その活動化はスタンバイ状態になります。カップリングが使用可能になると、その活動化はアクティブ状態になります。

スタンバイカップリングが作成されると、その活動化はスタンバイ状態になります。

同期が次のように使用不可にされます。

v 同期ジョブは実行されません。

v データはコピーされません。

v カップリングは削除できます。

Active (アクティブ)同期が次のように使用可能にされます。

v 同期ジョブを実行できます。

v データをピア間でコピーできます。

活動化状態に関係なく、以下が可能です。

v ミラーリング・タイプを同期に変更することができます。

v ピアの役割を変更することができます。


カップリングの非活動化カップリングの非活動化はミラーリング・プロセスを停止します。

ミラーリングはカップリングの非活動化によって終了し、システムに対して以下のことを引き起こします。

v ミラーリングを終了または削除する。

v 以下の結果として、ミラーリング・プロセスを停止する。

– 計画ネットワーク停止

– ネットワーク帯域幅を縮小するためのアプリケーション

– 計画リカバリー・テスト

非活動化により、実行中の同期ジョブは休止し、さらにミラーリングのアクティブ状態が復元されない限り、新規同期ジョブは作成されません。ただし、非活動化により、マスターとスレーブによるインターバル・ベースの状況検査は取り消されません。非活動化されたカップリングの同期状況は、カップリングがアクティブである場合と同様に、各インターバルの開始時に算定されます。

同期ジョブの実行中にカップリングを非活動化し、次のインターバルの開始前にその状態を変更しないと、次の概要の説明のように、RPO_Lagging となる同期状況が生じます。非活動化の際に:

マスター上で活動化状態がスタンバイに変更され、複製が休止し (かつ休止場所が記録され)、さらに複製が活動化の際に再開されます。

注: 進行中の同期ジョブは活動化の際に再開され、次のインターバルまで新規同期ジョブは作成されません。

スレーブ上で適用されません。

カップリングの状態に関係なく、以下が可能です。

v ピアの役割を変更することができます。

注: 整合性グループ・ミラーの場合: 非活動化により、整合性グループに関係するすべての実行中の同期ジョブは休止します。整合性グループ内で 1 つのボリューム同期ジョブを非活動化することはできません。

整合性グループのミラーリングボリュームを整合性グループにグループ化することにより、整合性をもつボリューム・グループのスナップショットを 2 次サイトに維持することができます。

以下が前提となって、整合性グループのセマンティクスをリモート・ミラーリングに使用できます。

整合性グループ・レベルでの管理整合性グループのミラーリングは、ボリューム・レベルではなく整合性グル


ープ・レベルで管理されます。例えば、整合性グループの同期状況は、その整合性グループに属するすべてのミラーリングされたボリュームを調べた後に判別されます。

空の整合性グループによる開始ミラーリングされた整合性グループとして定義できるのは、空の整合性グループのみです。既存の空でない整合性グループをミラーリングされた整合性グループとして定義する場合、最初に整合性グループ内のボリュームを削除する必要があり、その整合性グループをミラーリングされた整合性グループとして定義した後に初めて、ボリュームを元どおり整合性グループに追加します。

既に整合性をもっているグループへのボリュームの追加ミラーリングされた整合性グループに追加できるのは、ミラーリングされたボリュームのみです。この操作を行うには、以下の条件が必須です。

v ボリューム・ピアが整合性グループのピアと同じシステム上にある

v ボリュームの複製タイプが整合性グループで使用されているタイプと同一である。例えば、async_interval などのタイプがあります。

v ボリュームが整合性グループと同じストレージ・プールに所属している

v ボリュームのスケジュールが整合性グループと同じである

v ボリュームの RPO が整合性グループと同じである

v ボリュームと整合性グループの同期状況が同じである (同期ミラーリングでは SYNC_BEST_EFFORT、非同期ミラーリングでは RPO OK)

ミラーリングされた整合性グループがユーザー定義スケジュールによって構成されている (すなわち、Never スケジュールを使用していない) 場合: ミラーリングされた整合性グループまたはボリュームには、開始

していないスナップショット・ミラーまたは終了していないスナップショット・ミラー (随時同期ジョブ)、あるいはこの両方が含まれていてはなりません。

ミラーリングされた整合性グループが Never スケジュールを使用して構成されている場合:

ミラーリングされた整合性グループまたはボリュームには、開始も終了もしていないスナップショット・ミラーまたは終了していないスナップショット・ミラー (随時同期ジョブ)、あるいはこの両方が含まれていてはなりません。ミラーリングされた整合性グループの状況は、次の同期ジョブが完了するまでは「初期化」になります。

ミラーリングされていない整合性グループへのミラーリングされたボリュームの追加ミラーリングされていない整合性グループにミラーリングされたボリューム

を追加することができます。その際に、ボリュームは自身のミラーリング設定を保持します。

整合性グループ全体で単一の同期ジョブミラーリングされた整合性グループでは、その整合性グループ内の関連するすべてのミラーリングされたボリュームに対して同期ジョブは 1 つです。


ミラーリングされた整合性グループの場所整合性グループ内のすべてのミラーリングされたボリュームは、同一システム上でミラーリングされています。

ミラーリングされた整合性グループからのボリュームの削除時におけるボリュームのミラーリング属性の保持

ミラーリングされた整合性グループからボリュームを削除すると、対応するピア・ボリュームがピアの整合性グループから削除されます。ミラーリング(ボリュームが削除された整合性グループと同じ構成) は保持されます。さらに、ピア・ボリュームがピアの整合性グループから削除されます。整合性グループの進行中の同期ジョブは続行されます。

整合性グループのミラーリングの活動化整合性グループの活動化および非活動化は整合性グループのすべてのボリュームに影響します。

役割の更新整合性グループに関する役割の更新は、整合性グループのすべてのボリュームに影響します。

整合性グループ上のボリュームの依存性

v 整合性グループ内の特定のボリュームの活動化、非活動化、または役割の更新を UI から直接行うことはできません。

v 整合性グループ内の特定のボリュームのインターバルを直接変更することはできません。

v 整合性グループ内の特定のボリュームのミラーリングを独立して設定することはできません。

ミラーリングされた整合性グループの保護整合性グループがミラーリングされている場合、整合性グループ関連のコマンド (整合性グループの移動、整合性グループの削除など) の実行は許可されません。整合性グループを削除するには、整合性グループが空であっても、まずミラーリングを削除する必要があります。

整合性グループをミラーリング対象にするための設定ミラーリングされた整合性グループに追加するボリュームは、いくつかの前提条件を満たす必要があります。

同じ整合性グループの一部として一緒にミラーリングされるボリュームは、以下の同じ属性を共有します。

v ターゲット

v プール

v 同期タイプ

v ミラーの役割

v スケジュール

v ミラー状態

v last_replicated スナップショットのタイム・スタンプ


さらに、これらのスナップショットはすべて同じ last_replicated スナップショット・グループに含まれます。

これらの属性の整合性を確保するために、整合性グループをミラーリング対象として設定する場合、まず整合性グループを作成してからその整合性グループをミラーリング対象として設定し、その後に初めて、その整合性グループにボリュームを追加します。これらの設定の意味は、ミラーリングされた整合性グループに新規ボリュームを追加する場合、そのボリュームをその整合性グループ内の他のボリュームとまったく同じようにミラーリング対象として設定 (last_replicated スナップショットのタイム・スタンプを含め) する必要があるということです。これにより、そのボリュームの状況も RPO_OK になります。

注: ミラーリングされた整合性グループにミラーリングされていないボリュームを追加することはできません。ただし、ミラーリングされていない整合性グループにミラーリングされたボリュームを追加し、そのボリュームに自身のミラーリング設定を保持させることは可能です。

ミラーリングされた整合性グループのセットアップミラーリングされた整合性グループの作成プロセスは、以下のステップで構成されます。

ステップ 1整合性グループをミラーリング対象として定義します (この整合性グループは空でなければなりません)。

ステップ 2ミラーを活動化します。

ステップ 3ミラーリングされた整合性グループに、対応するミラーリングされたボリュームを追加します。ミラーリングされた整合性グループおよびミラーリングされたボリュームは、以下に示す同一のパラメーターを含んでいる必要があります。

v ソースとターゲット

v プール

v ミラーリング・タイプ

v RPO

v スケジュール名 (ローカルおよびリモート)

v ミラー状態が RPO_OK であること

v ミラーリング状況はアクティブになっていること

注: ミラーリングされていない整合性グループにミラーリングされたボリュームを追加することは可能です。この場合、そのボリュームは自身のミラーリング設定を保持します。


ミラーリングされた整合性グループへのミラーリングされたボリュームの追加

ボリュームがミラーリングされ、整合性グループと同じ属性を共有するようになったら、特定の条件が満たされた後にそのボリュームを整合性グループに追加することができます。

以下の条件が満たされている必要があります。

v ボリュームが整合性グループと同じシステム上にあること

v ボリュームが整合性グループと同じストレージ・プールに所属していること

v ボリュームと整合性グループのいずれにも未処理の同期ジョブ (スケジュールによるもの、あるいは手動つまり随時) がないこと

v ボリュームと整合性グループの同期状況 (synchronized="best_effort" およびasync_interval="rpo_ok") が同じであること

v ボリュームおよび整合性グループのそれぞれの特殊スナップショット、most_recent と last_replicated のタイム・スタンプが同一であること (これを可能にするには、整合性グループによって使用されているスケジュールにそのボリュームを割り当てます)

v 整合性グループが schedule="never" を指定して割り当てられている場合、同期ジョブが実行されていない限り、整合性グループの状況は「初期化」です。

ミラーリングされた整合性グループからのボリュームの削除ミラーリングされた整合性グループからのボリュームの削除は簡単に行うことができ、ボリュームのミラーリングは維持されます。

ミラーリングされた整合性グループからボリュームを削除すると、対応するピア・ボリュームがピアの整合性グループから削除されます。そのため、ボリュームが削除された整合性グループと同じ構成でミラーリングが保持されます。進行中の整合性グループの同期ジョブはすべて、そのまま実行されます。

非同期ミラーリング・タスクの管理非同期ミラーリング・タスクの管理。

災害時回復シナリオの提供災害は、いずれかのサイト (マスターまたはスレーブ) に障害が起こったかまたはマスター・サイトとスレーブ・サイトの間の通信が失われた状態です。

IBM XIV 非同期ミラーリングは、同期ジョブと呼ばれる繰り返しデータ複製プロセスを介してマスター・ピアとスレーブ・ピアの間の同期を実現します。ユーザー構成可能なスケジュールで実行すると、同期ジョブは、マスターのスナップショット(most_recent スナップショットと呼ばれる) を取得し、このスナップショットと、すでにスレーブに複製されている最新のマスター状態を表す別のスナップショット(および last_replicated スナップショットと呼ばれる DR シナリオの有効なリカバリー・ポイント) を比較します。次に、同期ジョブは、これらの差分に対応するマスター・データをスレーブと同期化します。同期ジョブの完了時に、新規last_replicated スナップショットがスレーブとマスターの両方で作成されます。


災害時回復シナリオでは、上記のいずれかのスナップショットが使用不可になる場合を扱います。このような場合を以下に示します。

計画外のサービス中断

�1� フェイルオーバー計画外のサービス中断は、スレーブに対するフェイルオーバーから始まります。

スレーブはプロモートされ、新規マスターになり、ホスト要求に応じます。

�2� リカバリー次に、マスターとリンクが復元されると必ず、プロモートされたスレーブ (新規マスター) から降格されたマスター (新規スレーブ) への複製が設定されます。

交互に: リカバリーなしリカバリーが可能でない場合は、新規ミラーリングがスレーブ上で設定されます。元のミラーリングは削除され、新規ミラーリング関係が定義されます。

�3� フェイルバックリカバリーに続いて、元のミラーリング構成が再設定されます。マスターはその役割を維持し、スレーブに対してレプリカを生成します。

計画されたサービス中断

�1� フェイルオーバー計画されたサービス中断は、スレーブに対するフェイルオーバーから始まります。スレーブは新規マスターになるようにプロモートされ、マスターは新規スレーブになるように降格されます。プロモートされたスレーブはホスト要求を満たし、降格されたマスターに対してレプリカを生成します。

�2� フェイルバックリカバリーに続いて、元のミラーリング構成が再設定されます。マスターはその役割を維持し、スレーブに対してレプリカを生成します。

テストスレーブ・レプリカのテスト。

意図的でない役割変更/間違った役割変更

�1� リカバリースレーブ上の XCLI/GUI 役割変更コマンドの意図的でない実装/間違った実装からのリカバリー。

このようなケースについては、以下のトピックで説明します。

注: 災害の場合または災害時回復のテストの場合は、明確なガイドラインを入手して正常なテストを確保するために XIV Support にお問い合わせください。

計画外のサービス中断障害が生じると、マスターはサービス提供も、使用もできなくなります。


障害により、すべての未処理の同期ジョブの複製が中断され、その結果、last_replicated スナップショットのタイム・スタンプ以降に記録されたデータが失われます。

フェイルオーバーこの中断により、スレーブをマスターにプロモートする必要が生じます。

手順1. ホスト・システム上でホストの接続を構成し、ホストがスレーブと通信できるようにします。

2. スレーブ・システム上で mirror_change_role コマンドを発行して、スレーブをマスターになるようにプロモートします。これにより、スレーブは暗黙的にlast_replicated スナップショットに戻されることになります。

3. スレーブ・システム上で map_vol コマンドを発行して、スレーブ上のミラー関連ボリュームを関連ホストにマップします。

リカバリーフェイルオーバー後にマスターが使用可能になり、元の複製の構成が必要な場合(つまり、フェイルバックが必要な場合) は、必ず新規マスター (プロモートされたスレーブ) から旧マスターへの複製を設定しなければなりません。その後でのみ、適切なフェイルバック手順を実行できます。

始める前に

注: フェイルオーバーの後、新規マスターから旧マスターへの操作可能なミラーリング複製が適切に設定されるまでは、新規マスターの役割をスレーブに変更してはなりません。変更した場合には、マスターへのプロモーション後にスレーブに書き込まれたデータが失われます (これは、旧マスターがその last_replicated スナップショットに復帰し、フェイルオーバー前の日付になるためです)。

プロモートされたスレーブと旧マスターの間のミラーリングを設定する前に、以下のことを検査します。

1. 旧スレーブの役割が現在、マスターになっている。

2. ホストが新規マスターに直接書き込みを行うように構成されている。

3. ミラーリングが正しく構成されている。

4. 旧マスターと新規マスターが接続状態である (旧マスターが新規マスター上のlast_replicated スナップショットに対応するポイント・イン・タイムに確実に戻ることができるようにするためには、新規マスターをスレーブに変更する前にこの接続が必要となります)。

手順1. マスター・システム上で、mirror_change_role コマンドを発行して、マスターをスレーブに降格します。

注: プール・スペースが枯渇し、新規マスターのスナップショットが削除された場合は、この降格を行うことができません。

2. スレーブ・システム上で、mirror_activate コマンドを発行してミラーリングを活動化します。フェイルオーバー時のミラーリングはスタンバイ状態であり、


明示的にアクティブ状態に設定する必要があります。活動化すると、ミラーリングはプロモートされたスレーブ (新規マスター) から降格されたマスター (新規スレーブ) に実行されます。

リカバリーなしマスターをリカバリーできないときはいつでも、ミラーリングをスレーブ上のデータ用に引き続き設定する必要があり、ミラーリング定義は削除され、新しいミラーリング定義が設定されます。

手順1. スレーブ・システム上で mirror_delete コマンドを発行して、マスターとスレーブの間のミラーリングを削除します。

2. スレーブ・システム上で新規ミラーリングを定義するために、以下のアクションを実行します。

a. 関連コマンドを発行する関連ターゲットを用いた構成を設定して、ホストに接続します。

a. mirror_create コマンドを発行して新規ミラーを作成します。

a. mirror_activate コマンドを発行してミラーを活動化します。

3. スレーブ・システム上で mirror_delete コマンドを発行して、マスターとスレーブの間のミラーリングを削除します。

4. スレーブ・システム上で新規ミラーリングを定義するために、以下のアクションを実行します。

a. 関連コマンドを発行する関連ターゲットを用いた構成を設定して、ホストに接続します。

a. mirror_create コマンドを発行して新規ミラーを作成します。

a. mirror_activate コマンドを発行してミラーを活動化します。

フェイルバックフェイルバックは、元のミラーリング構成を、フェイルオーバーの前の状態に復元します。

始める前に

下記のステップを実行する前に、次のことを検査します。

1. 旧スレーブの役割が現在、マスターになっている。

2. 旧マスターの役割が現在、スレーブになっている。

3. ホストが新規マスターに直接書き込みを行うように構成されている。

4. ミラーリングが正しく構成されている。

手順1. ホスト・システム上でホストの接続を構成し、ホストが旧マスターと通信できるようにします。

2. 旧スレーブ・システム上で以下のアクションを実行します。

a. ホストからの入出力を停止します。


b. スケジュールに入れられている次の同期ジョブが開始するまで待ちます。schedule_list コマンドを発行して、ミラーのスケジュール・インターバルを確認します。次の同期ジョブの作成を促進するために(mirror_change_schedule コマンドを発行して) ミラーのスケジュールをより短いインターバルをもつスケジュールに変更する価値があるかどうかを判別します。

c. ミラーのスケジュールを「Never」に変更します。このスケジュール設定により、システムが新規同期ジョブを自動的に作成しないことが保証されます。

d. アクティブ同期ジョブが完了するまで待ちます。 sync_job_list コマンドを発行して、ミラーに関する同期ジョブがリストされていないことを確認することにより、実行中の同期ジョブがないことを検査できます。

e. mirror_switch_roles コマンドを発行して、ピア間の役割を切り替えます。これにより、マスターがスレーブに降格され、スレーブがマスターにプロモートされます。

リンクが作動すると、ミラーリングが再開します (ミラーリングを明示的に活動化する必要はありません)。

3. 旧マスター・システム上で以下のアクションを実行します。

a. ミラーリング・スケジュール・パラメーターが必要に応じて構成されていることを確認します。

b. map_vol コマンドを発行して、マスター上のすべてのミラー関連のボリュームを関連ホストにマップします。

c. マスター・システムが使用不可の期間に mirror_deactivate コマンドを発行してミラーリングを非活動化します。

計画されたサービス中断サービス中断が計画されたプロセスである場合は、データ損失の量をあらかじめ決めることができます。

フェイルオーバーサービス中断はあらかじめ決められています。マスターは、スレーブがマスターとして機能する必要がある、あらかじめ決められた期間にホスト要求を実施することはできません。計画されたプロセス中に、フェイルオーバーを同期ジョブの完了直後に行うように設定することができます。その結果、データ損失が最小限に抑えられるか、またはデータ損失が発生しません (ホストが最終同期ジョブの作成前に静止 (休止) する場合)。

手順1. ホスト・システム上でホストの接続を構成し、ホストがスレーブと通信できるようにします。

2. マスター・システム上で以下のステップを実行します。

a. 関連ホストの入出力を停止します。

b. スケジュールに入れられている次の同期ジョブが開始するまで待ちます。schedule_list コマンドを発行して、ミラーのスケジュール・インターバルを確認します。次の同期ジョブの作成を促進するために


(mirror_change_schedule コマンドを発行して) ミラーのスケジュールをより短いインターバルをもつスケジュールに変更する価値があるかどうかを判別します。

c. ミラーのスケジュールを「Never」に変更します。このスケジュール設定により、システムが新規同期ジョブを自動的に作成しないことが保証されます。

d. アクティブ同期ジョブが完了するまで待ちます。 sync_job_list コマンドを発行して、ミラーに関する同期ジョブがリストされていないことを確認することにより、実行中の同期ジョブがないことを検査できます。

e. mirror_switch_roles コマンドを発行して、ピア間の役割を切り替えます。これにより、マスターがスレーブに降格され、スレーブがマスターにプロモートされます。

リンクが作動すると、ミラーリングが再開します (ミラーリングを明示的に活動化する必要はありません)。

3. スレーブ・システム上で以下のステップを実行します。

a. ミラーリング・スケジュール・パラメーターが必要に応じて構成されていることを確認します。


c. マスター・システムが使用不可の期間に mirror_deactivate コマンドを発行してミラーリングを非活動化します。

次のタスク

mirror_switch_roles コマンドによりアクティブ・ミラーリング関係が生じるため、計画されたフェイルオーバー手順の後に、ミラーリングを明示的にリカバリーする必要はありません。ただし、降格されたマスターが使用不可である限り、(mirror_deactivate コマンドを使用して) ミラーリングを明示的に非活動化しなければなりません。マスターが再度使用可能になった後は、mirror_activate コマンドを使用してミラーリングを活動化する必要があります。

サービス中断のテストIBM XIV Storage System により、ミラーリングを中断せずにスレーブ上のミラー・レプリカを検証することができます。

検証は、ホストへのスレーブのマッピングによって達成されます。

注: フェイルオーバー・プロセスとフェイルバック・プロセスは、ミラーリングを中断せずにテストすることはできません。

フェイルオーバー・テスト手順1. スレーブ・システム上で mirror_change_role コマンドを発行して、スレーブをマスターにプロモートします。これにより、スレーブは暗黙的に last_replicated

スナップショットに戻されることになります。

2. スレーブ・システム上で map_vol コマンドを発行して、マスター上のすべてのミラー関連のボリュームを関連ホストにマップします。


3. 新規マスターが機能し、ホストが新規マスターからの読み取りおよび新規マスターへの書き込みができるかどうかを確認します。

テストの遂行手順1. スレーブ・システム上で以下のアクションを実行します。

a. スレーブとホスト間のマッピングを削除します。

b. mirror_change_role コマンドを発行して、新規マスターをスレーブに降格します。ピアは、last_replicated スナップショットに戻されます。

注: マスターが新規マスター上の last_replicated スナップショットに対応するポイント・イン・タイムに戻されるようにするために、古いマスターと新規マスターの間の接続がなされていることを確認します。

2. マスター・システム上で mirror_activate コマンドを発行します。

中断のないテスト手順1. 以下のアクションを実行して、last_replicated スナップショットを複製します。

a. snapshot_duplicate (または snap_group_duplicate) コマンドを発行して、last_replicated スナップショットを複製します。


2. 以下のアクションを実行して、last_replicated スナップショットをコピーします。

a. vol_copy コマンドを発行して、last_replicated スナップショットを新規ボリュームにコピーします。


注: 複製/コピーされたレプリカは、テスト目的でのみ作成される独立コピーであり、それ自体ミラーリング・ピアになることはできません。したがって、複製/コピーされたレプリカがテストの一環としてホストによって書き込まれる場合は、新規データを実際のミラー・レプリカに更新することはできません。

役割変更の意図的でない/間違ったアプリケーションXCLI/GUI mirror_change_role コマンドがスレーブ上で無意図的に発行された場合は、スレーブはその元の役割に簡単に変更することができます。

選択非同期ミラーリング・コマンドの概要汎用コマンドmirror_create

このコマンドは、新規ミラー定義を作成します。

このコマンドには、ミラー・タイプ、ターゲット、RPO、スケジュール、参照されたスナップショットから初期化する能力などを指定するためのパラメーターが含まれています。


mirror_deleteこのコマンドはミラーを削除します。

このコマンドは、対応するオブジェクト (ボリュームまたは整合性グループ)

ではなくミラーリング関係を削除します。このコマンドは、マスターとスレーブの両方からミラーリング定義を削除します。マスターとスレーブの間に通信がない場合は、このコマンドをスレーブから操作することができます。

mirror_activateこのコマンドはミラーを活動化します。

このコマンドは、ミラーをアクティブ状態に設定します。この状態では、スレーブはマスターと一緒に更新されます。

mirror_deactivateこのコマンドはミラーを非活動化します。

このコマンドは、ミラーをスタンバイ状態に設定します。この状態では、マスターのみが更新されます。このコマンドは、ミラーのバッチも非活動化することができます。

mirror_change_roleこのコマンドは、マスターとスレーブ間のローカル・ミラー・ピアの役割を変更します。

このコマンドは、各ミラー・ピア上で別個に実行する必要があります。

同期ミラーリングの場合、別のコマンド mirror_switch_roles を使用することができます。

mirror_switch_roleこのコマンドは、マスター・ボリュームとスレーブ・ボリュームの各役割間の切り替えを行います。役割を切り替えるためには、以下の条件を満たす必要があります。

v カップリングが操作可能で同期化されている。

v マスター・ボリュームが last_replicated スナップショットと同一である(すなわち、関係があるすべてのボリューム更新を複製する必要がある)。

v 非同期ミラーリングでは、ミラーリングされたボリュームはlast_replicated スナップショットと同一でなければならない。

このコマンドは、マスター上でのみ実行できます。

切り替えの前に、システムは、ローカル・ボリュームへの新規書き込みの受け入れを停止し、保留中の書き込みをすべて実行します。保留中の書き込みがすべてコミットされた後でのみ、役割が切り替えられます。このコマンドの実行後に、カップリングは非活動化され、ユーザーは同期を再開するためにカップリングを活動化する必要があります。正しくないサーバー構成が原因である論理エラーからのリカバリーを可能にするために、カップリングを非活動化する前にスナップショットを作成することをお勧めします。

このコマンドの実行後に、以前にマスター・ボリュームであったボリュームはスレーブ・ボリュームになり、以前にスレーブ・ボリュームであったボリュームはマスター・ボリュームになります。

mirror_change_rpo(*)

このコマンドはミラー RPO を変更します。


RPO は、ミラーの対応スケジュール・インターバルより大きい必要があります。

mirror_change_schedule(*)

このコマンドは、ミラーの割り当て済みスケジュールを変更します。

このスケジュールのインターバルは、ミラーの対応 RPO より短い必要があります。

mirror_change_remote_schedule(*)

このコマンドは、リモート・ピアのスケジュールを変更します。

このスケジュールのインターバルは、ミラーの対応 RPO より短いものである必要はありません。

mirror_change_designationこのコマンドはピアの指定を変更するため、1 次ピアが 2 次ピアになり、2

次ピアが 1 次ピアになります。

このコマンドが効果をもたらすには、ミラーリングは操作可能である必要があります。

特殊コマンドmirror_create_snapshot

このコマンドは、両方のミラー・ピア上のスナップショットを作成します。このスナップショットは、随時同期ジョブの有効範囲を設定します。

非同期複製では、このコマンドは、ソース・ピア (マスター) の (コマンドの発行時点での) ポイント・イン・タイム・スナップショットを取得して、そのポイント・イン・タイム・スナップショットをスレーブと同期化するプロセスを確立します。

このプロセスは、作成したスナップショットと、ターゲット・ピアと同期化することが保証されている最新のスナップショットとの間の差分をコピーするための新規同期ジョブを設定します。

対照的に同期複製では、このコマンドは、ソース・ピア (マスター) とターゲット・ピア (スレーブ) のスナップショットをまったく同時に取得します。

mirror_cancel_snapshotこのコマンドは、マスターのすべての随時同期ジョブを取り消します。

このコマンドは、まだ実行開始されていない、指定されたマスター・ボリュームまたはマスター整合性グループのすべてのスナップショット・ミラー(随時同期ジョブ) を取り消します。

統計コマンドmirror_list

このコマンドは、定義されたミラーの詳細をリストします。

この出力詳細には、スケジュール、指定、役割、同期タイプ、同期状態、アクティブ状態、操作可能状態、同期の進行状況、同期化するサイズ、RPO、last_replicated_snapshot タイム・スタンプなどが含まれます。


mirror_statistics_get(*)

このコマンドは、指定されたミラーの完了同期ジョブに関する情報をリストします。

このコマンドは、指定のミラーリングされたボリュームまたは整合性グループに対応するこれまでの同期ジョブについて、システムによって自動的に収集される統計を表示します。表示される情報には、ミラーリングされたオブジェクト・タイプ (ボリューム/CG)、ジョブ・タイプ (予定/随時)、ジョブ・サイズ (MB)、作成日時、実行が開始された日時、完了した日時などが含まれます。

sync_job_list(*)

このコマンドは、保留中の同期ジョブまたは実行中の同期ジョブに関する情報をリストします。

この出力には、ミラーリング・カップリング (ボリューム/CG)、タイプ、ミラー・スケジュール、作成時間などの詳細が含まれます。

rpo_thresholds_set(*)

このコマンドは、すべてのミラーに対するシステム規模の RPO しきい値を設定します。このしきい値を超えると、イベントが作成されます。

絶対しきい値と相対しきい値を指定できます。

rpo_thresholds_get(*)

このコマンドは、rpo_threshold_set によって設定された RPO しきい値を表示します。

スケジュール・コマンドschedule_create

このコマンドはスケジュールを定義します。

有効なスケジュール・インターバルは、30 秒、1 分、2 分、5 分、10 分、15 分、30 分、1 時間、2 時間、3 時間、4 時間、6 時間、8 時間、12 時間です (構成不能な、20 秒間隔が指定された min_interval スケジュールもあります)。

schedule_deleteこのコマンドはスケジュール定義を削除します。

schedule_listこのコマンドは、すべてのスケジュール定義をリストします。

schedule_renameこのコマンドはスケジュールの名前を変更します。

schedule_changeこのコマンドは、既存のスケジュールのインターバルを変更します。

(*) このコマンドは、非同期ミラーリングにのみ適用できます。このコマンドは、同期ミラーリングには無関係です。


第 8 章マルチサイト・ミラーリング

マルチサイト・ミラーリングは、お客様がデータの 3 つのコピーを保持して、複数のサイト上に高可用性および災害復旧のソリューションを設定できるようにする、IBM XIV Storage System テクノロジーです。

マルチサイト・ミラーリングの主な機能は、以下のとおりです。

複数の並行マルチサイト・ミラーリング

v IBM XIV のマルチサイト・ミラーリングのアプローチには、3 つのピアが含まれており、1 つは同期複製で、2 つは非同期複製 (そのうちの 1

つはスタンバイ) です。

v 複数のマルチサイト・ミラーリング構成は、システムごとに、それぞれ別個のミラー・ピアを使用して、同時に実行されます。

v ソースは、2 つの異なる宛先への 2 つの並行ミラーを実行します。

v どのシステムも、それぞれ異なるシステムを参照する、複数のマルチサイト構成で表すことができます。

v システムは、異なるマルチサイト構成内で異なる役割を持つミラーリング・ピアをホストすることができます。

拡張性

v 既存の 2Way ミラーリング関係 (同期または非同期) を 3Way ミラーリングに拡張することができ、既存のミラー関係を中断する必要はありません。

注: 3Way ミラーリングは、ミラーリングされた整合性グループに対しては構成できませんが、ローカル整合性グループに対しては構成できます。

v マルチサイト・ミラーリング関係は、既存のターゲット接続に基づいて作成されます。

保守容易性

v マルチサイト・ミラーの一方のミラーに障害が起こった場合、他方のミラーが続行します。

マルチサイト・ミラーリングに関する用語マルチサイト・ミラーリング・テクノロジーでは、同期ミラーリングおよび非同期ミラーリングの章に記載した用語に加えて、新しい用語がいくつか導入されています。

マスター (ソース)ミラーリングされるボリューム。

代替マスター (2 次ソース)ソースを同期でミラーリングするボリューム。

スレーブ (宛先)ソースを非同期でミラーリングするボリューム。


同期ミラーリングおよび非同期ミラーリングの用語

この章で説明される概念の一部のものは、前のミラーリングの章で紹介されたものです。これらの章で使用されている用語の要約については、以下を参照してください。

v 57ページの『リモート・ミラーリングの基本概念』.

v 80ページの『用語』.

マルチサイト・ミラーリング・テクノロジーの概要IBM XIV は、別のシステム上にある 2 つのピア・ボリュームへのボリュームの複製を可能にします。

コンポーネントの階層

マルチサイト関係は、各システムとそのシステムが災害復旧シナリオ時に果たす役割を明確に定義します。

代替マスター (システム B) は、マスター (システム A) と同期でミラーリングされ、マスター (システム A) が使用不可になったときにスレーブ・システム (システム C) に対してマスターの役割を果たします。

C は、A または B の複製です。A-C ミラーリング関係がアクティブの場合は、B-C ミラーリングは非アクティブであり、逆に、B-C ミラーリング関係がアクティブの場合は、A-C ミラーリングは非アクティブです。つまり、A と B の両方が同時に C に書き込むことはできません。

A-B ミラーマスターと代替マスターの間の同期ミラーリング関係。

A-C ミラーマスターとスレーブの間の非同期ミラーリング関係。

マスター

マスター

スレーブ

��

��

��スタンバイ

A B

スレーブ

C

xiv10587

図 44. マルチサイト・ミラーリング・コンポーネントの階層


B-C ミラー代替マスターとスレーブの間の非同期ミラーリング関係。

このミラーリング関係は、スタンバイ・ミラーとも呼ばれます。

B-C ミラーリング関係を構成するミラーリング関係は、以下のいずれかのタイプです。

v スタンバイ・ミラー - マルチサイト・ミラーリング定義の第 3 ミラー (前述の定義)

v ライブ・ミラー - 操作可能なミラーリング関係。これは、災害復旧の場合に、要求によってのみ操作可能になります。

前もってスタンバイ・ミラーリング関係を定義するには、マルチサイト・ミラーリング関係の構成時に、B と C の間のターゲット接続 (または、少なくともその定義) がすべてのシステム間に設定されていることが必要です。

表 9 と 124ページの図 44 は、マルチサイト・ミラーリング関係に関与している各システムの役割を表示しています。

表 9. マルチサイト・ミラーリングを構成するミラーリング関係

システム役割 A-B A-C B-C

A ソース同期ミラーリング関係。システム A はマスターです。ミラーはアクティブです。

非同期ミラーリング関係。システム A はマスターです。ミラーはアクティブです。

B 2 次ソース同期ミラーリング関係。システム B はスレーブです。ミラーはアクティブです。

非同期ミラーリング関係。システム B はマスターです。ミラーはスタンバイです。

C 宛先非同期ミラーリング関係。システム C はスレーブです。ミラーはアクティブです。

非同期ミラーリング関係。システム C はスレーブです。ミラーはスタンバイです。

注: 現在のところ、マルチサイト・ミラーリングは整合性グループ・ミラーリングをサポートしません。ただし、ボリューム・ミラーリングが使用されていて、そのボリュームがローカル整合性グループの一部である場合は、サポートできます。

マルチサイト・ミラーリングの状態

IBM XIV マルチサイト・ミラーリング・テクノロジーには、複数の操作状態 (条件) があります。個々のミラーリング定義にはそれ独自の状態がある一方で、マルチサイト・ミラーリング定義にはグローバル状態もあります。

第 8 章マルチサイト・ミラーリング 125

グローバル状態

以下の状態は、ミラーのグローバル状態に適用されます。

初期化 (Init)すべてのミラーリング定義がデータ転送を開始する準備ができました。

操作可能 (Operational)A-B と A-C の両方がアクティブである定常状態。

機能低下 (Degraded)A-B と A-C の両方がアクティブで同期化されているが、A-C が RPO 遅延である場合、ミラーリング状態は機能低下です。

非アクティブ (Inactive)A-B と A-C の両方が非アクティブの場合、ミラーリング状態は非アクティブです。

暗号漏えい (Compromised)

暗号漏えい状態の考えられる理由は、以下のとおりです。

切断 (Disconnection)A-B または A-C のどちらかのリンクがダウンしています。

再同期 (Resync)A-B または A-C のどちらかが再同期状態にあり、代替マスターがまだ所有権を取得していませんでした。

役割の部分的な変更後 (Following a partial change of role)A-B または A-C のどちらかで役割の変更がありました。

代替マスターとスレーブの状態

以下の状態は、代替マスターとスレーブの状態に適用されます。

接続 (Connected)マスター・システムを持つミラーが接続状態です。

切断 (Disconnected)マスター・システムを持つミラーが切断状態です。

スタンバイ・ミラーリングの状態

以下の状態は、スタンバイ・ミラーに適用されます。

接続 (Up)スタンバイ・ミラーが定義され、接続されています。

切断 (Down)スタンバイ・ミラーが定義され、切断されています。

NA スタンバイ・ミラーは定義されていません。


マルチサイト・ミラーリングのユース・ケースこのセクションでは、前のミラーリングの章で既に紹介した用語を使用しています。

注意事項:

MRS (最新のスナップショット)ミラーリング・プロセスが次回の同期ジョブでスレーブに複製する必要があるデータを計算するために使用する、マスターのスナップショット。このスナップショットは、マスター上にのみ存在します。

このスナップショットは、開始前に同期ジョブのその内容を取り込みます。

LRS (最終複製スナップショット)スレーブが完全に複製されたと認知している最後のスナップショット。つまり、マスターとスレーブの両方がこのスナップショットを持っています。

このスナップショットは、同期ジョブが正常に完了した後でその内容を取り込みます。

MRS および LRS の完全な定義と、それらが同期ジョブ中に取る役割の説明が、84ページの『特殊スナップショットのミラーリング』および 100ページの『非同期ミラーリング・プロセスのウォークスルー』に記載されています。

注: A の MRS と LRS は、B にも複製されており、後で MRSB と LRSC の比較に使用されます。

マルチサイト・ミラーの作成マルチサイト・ミラーリング関係の作成には、各ボリューム・ペア間のミラーリング関係の作成が含まれます。

マルチサイト・ミラーリング関係を確立するには、2 対のミラーリング関係を作成してから、マルチサイト・ミラーリング関係として定義します。

注: マルチサイト・ミラーリングの作成は、XIV GUI を使用すると、より簡単に行えます。詳しくは、「MT Operations Guide, Version 4.4 (SC27-5986-01)」を参照してください。

マスターからの A-B 同期ミラーリングマスターと 2 次マスターの間の同期ミラーリング関係。

v XCLI コマンド - mirror_create

v パラメーター

– vol - master

– target - smaster

– type - sync_best_effort

– part_of_xmirror - yes

その他のパラメーターは、このリストから省略されています。これらのパラメーターの詳しい解説は、「IBM XIV XCLI Reference Guide」に記載されています。

あるいは、既存の同期ミラーリング定義を使用できます。


マスターからの A-C 非同期ミラーリングマスターとスレーブの間の非同期ミラーリング関係。



– vol - master

– target - slave

– type - async_interval



あるいは、既存の非同期ミラーリング定義を使用できます。

代替マスターからの B-C 非同期ミラーリング2 次マスターとスレーブの間の非同期ミラーリング関係。

注: このミラーリング定義はオプションです。これは、マルチサイト・ミラーリングの定義に必須ではありません。



– vol - smaster

– target - slave

– type - async_interval



マスターからのマルチサイト・ミラーリング関係の定義

v XCLI コマンド - xmirror_define


– name - 3-way ミラーリング関係を識別する名前

– smaster - B

– slave - C

マスターのフェイルオーバーマスターに障害が起こった場合、代替マスターがミラーリング関係の所有権を取るように構成できます。代替マスターがマスターになり、B-C 非同期ミラーリング関係が定義されていれば、このミラーが活動化されます。

注: B-C 非同期ミラーリング関係なしでマルチサイト・ミラーリングが定義されている場合、B の役割を代替マスターからマスターに変更する前に、ここで B-C 非同期ミラーリング関係を定義し、マルチサイト・ミラーリングに追加しておく必要


があります。B-C 非同期関係をマルチサイト・ミラーリングに追加するには、次のコマンドを実行します。

xmirror_register_standby_mirror

v xmirror - B

v target - C

130ページの図 45 は、B がマスターとして定義され、B-C がスタンバイから稼働中、非アクティブになる様子を示しています。


B の役割を代替マスターからマスターに変更するには、B で以下のコマンドを実行します。

xmirror_change_role

v xmirror - B

A B

C

/9:

/9: スタンバイ

マスター

マスター

スレーブ

スレーブ

A B

C

;アクティブ (Inactive)

;アクティブ/9:、;アクティブ

マスタースレーブ

スレーブ

xiv10567

図 45. マスターに障害が起こる


v new_role - Master

xmirror_activate

v vol - B

v target - C

B-C スタンバイがアクティブになり、C は A からのすべての書き込みをブロックします。

B-C ミラーを活動化する前に、2 次マスターのスナップショットを調べて、それらが十分に最新のものであるかどうかを判別する必要があります。

最後の A-C 同期ジョブ後の障害システムは MRSB と LRSC のタイム・スタンプを比較して、それらが同一であることを検出します。

リカバリーは不要です。B がマスターになり、B-C が稼働中になります。

最後の A-C 同期ジョブ中の障害LRSB と LRSC のタイム・スタンプが、完了した最後の A-C 同期ジョブと同一です。

これは、最後の同期ジョブ中に A に障害が起こったことを示しており、B

はその LRS と MRS の間の差異を次回の同期ジョブ中に C に送信します。

C の更新後で、B の更新前の障害

注: このシナリオは、最も起こりそうにないものです。LRSC が MRSB より最新になるには、最初に A-B ミラーに障害が起こり、A-C ミラーは非同期スナップショットを取って C に渡せるだけ十分長くアップ状態にあり、しかも結局は障害が起こる結果となる必要があります。

C の LRS が B の MRS よりも最新のタイム・スタンプを持っている場合(つまり、B-A ミラーが切断されている間、A は C の更新を続行し、C がB より最新である場合) は、このミラーの再初期化が必要です。

どのシステムがマスターになるかに関係なく、マルチサイト・ミラーを最初に非活動化する必要があります。マスターで、次のコマンドを実行します。

xmirror_deactivate

B がマスターのまま残ることに決定された場合、C は他のすべてのソースからの書き込み要求を拒否します。これは、A がまだ稼働中であるか、再び稼働中になり、C に更新を送信するケース (「スプリット・ブレーン」) を避けるために必要です。B がマスターのときは、C は B をマスターと見なし、A を無視します。

B の役割が smaster から master に変更されると、システムとミラーの状況が変更されます。 132ページの表 10 は、マルチサイト・ミラーリング関係に関与している各ピアの役割を表示しています。


表 10. B の代替マスターからマスターへの役割変更後

ピア役割 A-B A-C B-C

A マスター (A-B

の場合)

同期ミラーリング関係。システム A はマスターです。拒否された最初の書き込みの時点で、ミラーは稼働中で非アクティブです。

非同期ミラーリング関係。システム A はマスターです。ミラーは稼働中でアクティブです。

B マスター (B-C

の場合)

同期ミラーリング関係。システム B はマスターです。ミラーは稼働中で非アクティブです。

非同期ミラーリング関係。システム B はマスターです。ミラーはスタンバイです。

C スレーブ非同期ミラーリング関係。システム C はスレーブです。ミラーは非アクティブです。

非同期ミラーリング関係。システム C はスレーブです。ミラーはスタンバイです。

B のみが、B の役割変更の影響を受けます。A と C は両方とも前の状態のままです (A-B 関係は別として)。B-C が活動化された時点で、C はマスターに変更があることを認識します。ピア A は、これらの変更を直接には認識しませんが、各ミラーへの次回の書き込みが拒否された時点で、ミラーを非活動化します。

B でマルチサイト・ミラーリングが活動化されると、システムとミラーの状態が変更されます。表 11 は、マルチサイト・ミラーリング関係に関与している各ピアの役割を表示しています。

表 11. B でマルチサイト・ミラーリングが活動化された後


A マスター (A-B

の場合)

同期ミラーリング関係。システム A はマスターです。最初に拒否された書き込み操作の時点で、ミラーは稼働中で非アクティブです。

非同期ミラーリング関係。システム A はマスターです。最初に拒否された書き込み操作の時点で、ミラーは稼働中で非アクティブです。


表 11. B でマルチサイト・ミラーリングが活動化された後 (続き)


B マスター (B-C

の場合)


非同期ミラーリング関係。システム B はマスターです。ミラーは稼働中でアクティブです。

C スレーブ非同期ミラーリング関係。システム C はスレーブです。ミラーはスタンバイで非アクティブです。

非同期ミラーリング関係。システム C はスレーブです。ミラーは稼働中でアクティブです。

フェイルオーバーの完了

フェイルオーバー操作を完了するには、B で以下の XCLI コマンドを実行してマルチサイト・ミラーをアクティブにし、A で役割をマスターから代替マスターに変更し、B-A 同期ミラーを活動化します。

xmirror_activate

v xmirror - B

xmirror_change_role

v xmirror -A

v new_role - SMaster

mirror_activate

v vol - B

v target - A

ミラーの再同期後、同時ジョブ操作が完了するのを待ちます。マルチサイト・ミラーが操作可能であることを確認します。

表 12 と 134ページの図 46 は、マルチサイト・ミラーリング関係に関与している各ピアの役割を表示しています。

表 12. フェイルバック中


A 代替マスター(A-B の場合)

同期ミラーリング関係。システム A は代替マスターです。ミラーは稼働中で非アクティブです。

非同期ミラーリング関係。システム A は代替マスターです。ミラーはスタンバイです。


表 12. フェイルバック中 (続き)


B マスター (B-C

の場合)


非同期ミラーリング関係。システム B はマスターです。ミラーは稼働中でアクティブです。

C スレーブ非同期ミラーリング関係。システム C はスレーブです。ミラーはスタンバイです。

非同期ミラーリング関係。システム C はスレーブです。ミラーは稼働中でアクティブです。

マスターのフェイルバックマスターが障害から復旧すると、A-B ミラーリング関係が再活動化および再同期された後、システム A はマスターとしての役割を再開できます。次回の同期ジョブで、A-C ミラーリング関係も再活動化されます。

xiv10571

A B

C

��

��スタンバイ

smaster マスター

スレーブ

図 46. フェイルバック中


マスターのフェイルバックの目的は、A が失ったデータを備えてマスターの役割に戻ることです。したがって、B は代替マスターの役割を引き受け、A と B の間の同期ミラー関係を再活動化する必要があります。次に、A-C 非同期ミラー関係を再活動化する必要があります。

A-B ミラーが活動化され、B 上の最終変更と同期化されたら、A をマスターとして再定義し、B を代替マスターとして再定義することができます。

再同期プロシージャー (つまり、同期ジョブ) が開始され、古いマスターは、喪失したすべての書き込みを使用して更新されます。マスターと代替マスターの間の再同期が完了した後、1 回のマスター・スレーブ・インターバルが経過して、同期ジョブが正常に完了するまでは、マルチサイト・ミラー状態は暗号漏えいのままです。代替マスター B は現在、ターゲットと同じ LRS を持っています。

必要なステップについては、 139ページの『テストのためのフェイルオーバー操作およびフェイルバック操作の開始』を参照してください。

注: フェイルバック操作を開始する際には、 139ページの『テストのためのフェイルオーバー操作およびフェイルバック操作の開始』に記載されているのと同じ前提条件がありますが、役割は逆です (ここでは B が A であり、A が B になります)。

マルチサイト・ミラーが操作可能になるのを待ちます。

表 13 は、マルチサイト・ミラーリング関係に関与している各ピアの役割を表示しています。

表 13. フェイルバック後


A マスター同期ミラーリング関係。システム A はマスターです。ミラーは稼働中でアクティブです。

非同期ミラーリング関係。システム A はマスターです。ミラーは稼働中でアクティブです。

B 代替マスター同期ミラーリング関係。システム B は代替マスターです。ミラーは稼働中でアクティブです。

非同期ミラーリング関係。システム B は代替マスターです。ミラーはスタンバイです。

C スレーブ非同期ミラーリング関係。システム C はスレーブです。ミラーは稼働中でアクティブです。

非同期ミラーリング関係。システム C はスレーブです。ミラーは非アクティブでスタンバイです。


代替マスターでの避難訓練避難訓練は、代替マスターがホストの書き込みを受け入れる準備ができているかどうかを調べる、お客様の手順です。

この避難訓練の手順を達成できるようにするには、B をマスターとし、ホストが B

を使用できる (読み書きできる) ようにする手段が必要です。この手順の最後に、B

は代替マスターの役割に戻り、マルチサイト・ミラーリングは、短時間の再同期処理により機能フェーズに戻ります。

図 47 は、避難訓練前のマルチサイト・ミラーリング定義を示しています。

避難訓練は、B を活動化することなく、B の役割を 2 次マスターからマスターに変更します。B がマスターになると、B-C と A-B の両方のミラーリング関係が非アクティブになり、 B は、A も C も更新せずに両方の変更を追跡します。

以下の XCLI コマンドを実行します。

mirror_deactivate

v vol - A

v target - B

xmirror_change_role

v xmirror -B

v new_role - Master

xiv

10568

A B

C

/9:

/9: スタンバイ

マスター smaster

スレーブ

図 47. 避難訓練前


図 48 は、避難訓練前のマルチサイト・ミラーリング定義を示しています。

B がその役割を変更して 2 次マスターに戻した場合 (B-C 関係を活動化せずに)、A-B の活動化中にB が復元する必要があります (スレーブが 1 次モードであった同期ミラーの活動化の一部として)。B は、B-C 関係上で追跡した変更をリセットします (必要な場合)。(避難訓練中の) ホストの B への直接書き込みは、A によってオーバーライドされます。

以下の XCLI コマンドを実行します。

xmirror_change_role

v xmirror -B

v new_role - SMaster

mirror_activate

v vol -A

v target - B

代替マスターの障害とフェイルバックB に障害が起こった場合、A は C との非同期ミラーリング関係を維持し、B が再開したときに、A は B を更新する必要があります。

B に障害が起こった場合、マルチサイト・ミラーリング定義は A-C ミラーリング関係に依存して、A の最新ミラーを保持します。 138ページの図 49 は、マルチサイト・ミラーリング関係に関与している各ピアの役割と、さまざまなミラーリング関係内で役割を果たす方法を表示しています。

xiv10569

A B

C

�アクティブ

�アクティブ

マスターマスター

スレーブ

図 48. B での避難訓練


B が戻ると、A は再同期処理を通じて B を更新します。再同期処理では、A は、B の障害以降に A 上で変更されたすべてのデータを転送します。図 50 は、マルチサイト・ミラーリング関係に関与している各ピアの役割を表示しています。

xiv10572

A B

C

�アクティブ

�アクティブ


スレーブ

��

図 49. 代替マスターの障害

xiv10573

A B

C

��

��


スレーブ

��

図 50. 代替マスターのフェイルバック


テストのためのフェイルオーバー操作およびフェイルバック操作の開始

フェイルオーバー操作およびフェイルバック操作の開始は、マルチサイト・ミラーリング関係での B (代替マスター) サイトとの間でのフェイルオーバーおよびフェイルバックの手順をテストするためのお客様の手順です。

マルチサイト・ミラーリング関係は、A、B、および C という 3 つのピアで構成されています。この場合、A-B は同期ミラー、A-C は非同期ミラーであり、両方のミラーはアクティブです。B-C 非同期ミラー関係も使用され、非同期スタンバイ・ミラーとして機能しますが、A が B にフェイルオーバーすると即時にアクティブ化されます。その場合、B が C の新しいマスターとなります (すなわち、A マスターで障害が発生すると、B がマスター代替として機能します)。

A からの B へのフェイルオーバー (ここで A はマスター) は、管理者によって開始されます。すべてのホスト・トラフィックは、管理者が決めた指定期間中、A 上のボリュームから B 上のボリュームへ移動します。この操作が完了すると、A は再度マスターになり、ホスト・トラフィックはすべて、元の A に戻されます。

このテスト操作の目的は、B 上の複製されたボリュームが、A 上での障害時に A

の役割を果たせるようにすることです。したがって、このテストには、稼働中のトラフィックを実行するホストが B 上の複製されたボリュームを使用することが含まれます。このテストでは、データが失われることなく、ホストのトラフィックが A

から B へフェイルオーバーされることも必要です。ホスト・データが失われないようにする唯一の方法は、B へのホスト入出力を停止するために A 上のボリュームをマップ解除することです。

注: 同じ順序のステップを XIV GUI から実行することができます。

最初に、A 上のボリュームにアクセスするすべてのホスト上での入出力を一時停止してから、以下の XCLI コマンドを実行します。

unmap_vol

v vol - A

A 上のボリュームをホストからマップ解除して、A から B へのフェイルオーバー中のデータ損失を回避します。ホストに、ボリュームへのホストのマッピングが削除されたことが通知されます。

xmirror_deactivate

v vol - A

v target - B

両方のピア上での役割を変更するために、マルチサイト・ミラーを非アクティブ化します。

xmirror_change_role

v xmirror -A

v new_role - sMaster

A の役割を代替マスターに変更します。

xmirror_change_role


v xmirror -B

v new_role - Master

B の役割をマスターに変更します。

xmirror_activate

v vol -B

v target - A

A と C を同期するためにマルチサイト・ミラーリング関係を B によってアクティブ化します。

map_vol

v vol - B

ボリュームがまだマップされていない場合は、それらを B にマップします。

B に対するホスト入出力を再開します。

フェイルバック操作の開始

フェイルバック操作を開始する際には、上記と同じ前提条件がありますが、役割は逆です (ここでは B が A であり、A が B になります)。


第 9 章 IBM Hyper-Scale Mobility

IBM Hyper-Scale Mobility を使用すると、ホストが干渉されることなく、XIV システム間でボリュームをシームレスにマイグレーションすることができます。

IBM Hyper-Scale Mobility によって、通常であれば従来のシステムでは困難なプロビジョニング・シナリオを簡単に克服することができます。 IBM Hyper-Scale

Mobility は、データ移動性、ロード・バランシング、オーバープロビジョン、およびマシンのリパーパス (利用環境変更) において、無数の重要なカスタマー・ユース・ケースに対応します。

IBM Hyper-Scale Mobility の主な目的は、以下のとおりです。

v ホストに対して透過的な方法で、複数のバックエンド・ストレージ・フレーム全体にわたって、効率的にストレージ・データを配置できるようにします。

v 組織のための、強力なスケーラビリティー・ソリューションを可能にします。

IBM Hyper-Scale Mobility は、XIV の優れたセットアップおよび管理と整合性があるユーザー・エクスペリエンスを簡素化して示します。IBM Hyper-Scale Mobility

は IBM Hyper-Scale に基づいており、実装されている外観は IBM XIV の同期ミラーリング ( 57ページの『第 6 章同期リモート・ミラーリング』を参照) と同様で、使いやすさも変わりません。 IBM Hyper-Scale は、複数の XIV システムの管理を簡素化したものです。

IBM Hyper-Scale Mobility とはIBM Hyper-Scale Mobility は、オーバープロビジョンのさまざまなシナリオにアプローチします。

IBM Hyper-Scale Mobility は、アプリケーションを中断せずにシステム間でのボリュームの移動を可能にすることにより、XIV 環境全体における操作上の俊敏性を大幅に向上します。 IBM Hyper-Scale Mobility は、この機能がなければ通常対応が困難になるストレージ管理上の目標 (シン・プロビジョニングの最適化、データ・センター全体でのワークロード・バランシングの簡素化、アレイのリパーパスおよびリタイヤメントなど) の実現に役立ちます。

例えば、あるシステムで容量が限界に達しようとしていることが判明すると、ストレージ管理者は IBM Hyper-Scale Mobility を使用して、ボリュームを別のシステムに移動し、必要時に使用できるように元のシステムのスペースを解放することができます。

IBM Hyper-Scale Mobility の主なステージは、以下のとおりです。

計画上記のいずれかのシナリオ (オーバープロビジョン、容量が使い尽くされた状態、またはテクノロジー・リフレッシュの必要性) が発生すると、ストレージ管理者は IBM Hyper-Scale Mobility プロセスに関与する XIV システム(複数の場合もあり) を決定する必要があります。


ストレージ管理者は、IBM Hyper-Scale Mobility プロセスを計画する際に、アプリケーション関連の要件およびゾーニングについて考慮します。

セットアップストレージ管理者は、ソース・ボリュームと宛先ボリュームの間の IBM

Hyper-Scale Mobility 関係を定義します。

ストレージ管理者は次に、ミラーのアクティブ化と同じような方法で IBM

Hyper-Scale Mobility プロセスをアクティブ化し、マイグレーションが実行されます。

マイグレーションのトラッキングこのフェーズで、ストレージ管理者は、システム・パフォーマンスに加えてマイグレーションの進行状況もトラッキングします。

プロキシーの確立ソース・ボリューム・データのマイグレーションは、宛先ボリュームが同期されると完了します。ソースは、ホストと宛先の間のプロキシーとして、ホスト書き込みのサービスを行います。

システム管理者は、IBM Hyper-Scale Mobility 関係を Proxy (プロキシー)

に移行するコマンドを実行します。

システム管理者は次に、ホストを宛先に対してマップします。これ以降、宛先はソースと同期状態ではなくなり、新規のデータは宛先にのみ書き込まれます。

クリーンアップ宛先がホストのサービスを行うようになると、システム管理者は、ソースと宛先の間の IBM Hyper-Scale Mobility 関係を削除します。

完了後システム管理者は、宛先に対するミラーリング関係とスナップショット・ポリシーを確立します。

IBM Hyper-Scale Mobility の定義IBM Hyper-Scale Mobility では、以下の用語が導入されます。

IBM Hyper-Scale Mobilityオンライン・データ・マイグレーションのアプローチであり、ホストに対して透過的な方法でデータをソース・フレームから宛先フレームにマイグレーションします。

ソースマイグレーションされるボリューム。

宛先マイグレーションのターゲット。

ソース・フレームソースが配置されるフレーム。

宛先フレーム宛先が配置されるフレーム。

プロキシーホスト要求に、あたかもその要求のターゲットであるかのように対応するXIV システム (実際にはターゲットを装っているだけです)。


OLVMオンライン・ボリューム・モビリティー - IBM Hyper-Scale Mobility 関係を意味します。

技術概要IBM Hyper-Scale Mobility は、プロセスをコントロールするために以下のフェーズおよび状態を使用します。

フェーズマイグレーション

このフェーズでは、IBM Hyper-Scale Mobility プロセスが、ソースと宛先の間の IBM Hyper-Scale Mobility 関係を設定します。このフェーズでは、新しいデータはソースに書き込まれ、宛先にマイグレーションされます。

プロキシー準備完了このフェーズでは、ボリュームがソースから宛先にマイグレーションされます。データ・マイグレーションが完了すると、ソースと宛先の両方が同期されます。この時点で、システム管理者はプロキシー・モードを確立するようにシステムに指示することができます。このフェーズでは、新しいデータはソースに書き込まれ、宛先と同期されます。

プロキシー新しいデータはソースに書き込まれ、宛先にマイグレーションされます。プロキシーは、あたかもターゲットのようにホスト要求のサービスを行いますが、実際にはターゲットを装っているだけです。

状態

「状態」では、データ・マイグレーションの観点から見た IBM Hyper-Scale

Mobility ピアについて説明します。ピア・ボリュームには、それぞれ独自の状態があります。

ソース・ピア

v 初期化中 - ソース・ボリュームのコンテンツは、宛先ボリュームにコピーされます。この 2 つのボリュームは、まだ同期されていません。この状態は、同期ミラーリングの「初期化中」の状態に類似しています。すべての書き込みが宛先ボリュームによって認識されたことをソース・フレームが確認できない場合、状態は「初期化中」のままです。

v 同期済み - ソース全体が、宛先にコピーされました。この状態は、同期ミラーリングの「同期済み」の状態に類似しています。

v 非同期 - 「同期済み」の状態が確立された後に、リンクの障害、またはIBM Hyper-Scale Mobility プロセスの使用不能化によって、状態が「非同期」に変更されました。

v プロキシー - ソースは、宛先に対するプロキシーとして動作します。

宛先ピア

v 整合 - 宛先ボリュームは、ソース・ボリュームと整合しています。

v 不整合 - 宛先ボリュームは、ソース・ボリュームと整合していません。

第 9 章 IBM Hyper-Scale Mobility 143

v プロキシー処理済み (Proxied) - 宛先は、ソースによってプロキシー処理済みです。

操作可能状況

操作可能状況は、IBM Hyper-Scale Mobility プロセスの状況、ターゲットの接続性、および接続の妥当性に基づいています。操作可能状況は、「はい」または「いいえ」のいずれかです。リンクに障害がありダウンしている場合、イベントが発行され、操作可能状況は「いいえ」になります。リンクが使用可能になると、この状況は「はい」に変わります。操作可能状況は、以下のイベントに影響を受けます。

リンクに障害がある操作可能状況は「いいえ」になります。

この場合、イベントが発行されます。

リンクが稼働している操作可能状況は「はい」になります。

フロー・ダイアグラム

以下のダイアグラムは、IBM Hyper-Scale Mobility のフローを示しています。


IBM Hyper-Scale Mobility プロセスのウォークスルーこのセクションでは、IBM Hyper-Scale Mobility のプロセスおよびステージを段階的に説明します。

IBM Hyper-Scale Mobility プロセスは、以下のステップで構成されています。

146ページの『[ステージ 1:] IBM Hyper-Scale Mobility の計画』

1. IBM Hyper-Scale Mobility の操作に対するトリガーの決定

2. IBM Hyper-Scale Mobility の操作に関するデータの取得

3. IBM Hyper-Scale Mobility の操作の優先順位付け

4. ゾーニング

5. 計画のまとめ

151ページの『[ステージ 2:] IBM Hyper-Scale Mobility プロセスのセットアップ』

1. 事前定義

図 51. IBM Hyper-Scale Mobility のフロー


2. IBM Hyper-Scale Mobility 関係の定義

3. IBM Hyper-Scale Mobility 関係のアクティブ化

155ページの『[ステージ 3:] マイグレーションのトラッキング』

1. 進行状況のモニター

155ページの『[ステージ 4:] プロキシーの確立』

1. 「プロキシー」状態への遷移

2. オンライン反転

157ページの『[ステージ 5:] クリーンアップ』

157ページの『[ステージ 6:] 完了後』

[ステージ 1:] IBM Hyper-Scale Mobility の計画IBM Hyper-Scale Mobility プロセスは、計画フェーズから開始します。このフェーズでは、ストレージ管理者がプロセスに関係する情報を収集し、マイグレーションするボリュームと、ボリュームのマイグレーション先を決定します。

計画フェーズは、以下のステップから構成されます。

[1] IBM Hyper-Scale Mobility の操作に対するトリガーの決定

IBM Hyper-Scale Mobility には、多数の標準的なトリガーがあります。各トリガーは、次のリストが示すように、容量の解放という必要性に対して、それぞれ少しずつ異なるアプローチをします。

オーバープロビジョンIBM Hyper-Scale Mobility は、シン・プロビジョニングされたストレージ・プールで容量が使い尽くされそうになった場合にトリガーされます。

ソース・ボリューム上システムで重要な機能は、シン・プロビジョニングのイベント時にキャプチャーとアラートを行うための包括的なサポートです。アラートは、システム・イベント (特にプールの容量レベルに関するイベント) のモニターを通じて検出することができます。

関連するコマンド

v pool_change_config - ストレージ・プールのロック動作を設定します

v event_redefine_threshold

v rule_create - イベント通知規則を作成します

関連する GUI ビュー

v ストレージ・プール

v プール別のボリューム

v プール・アラートのしきい値 (Pools Alerts Thresholds)

v アラート

v イベント

関連するイベント

v STORAGE_POOL_VOLUME_USAGE_TOO_HIGH


v STORAGE_POOL_VOLUME_USAGE_INCREASED

v STORAGE_POOL_SNAPSHOT_USAGE_INCREASED

v STORAGE_POOL_EXHAUSTED

v MIRROR_RESYNC_FAILED_DUE_TO_THIN_PROVISIONING

v SNAPSHOT_DELETED_DUE_TO_POOL_EXHAUSTION

v SNAPSHOT_GROUP_DELETED_DUE_TO_POOL_EXHAUSTION

v MIRROR_DEACTIVATE_SECONDARY_LOCKED

保守即時の注意を要する容量上の問題。

ソース・ボリューム上容量に関連する一般的なケースで、管理者の注意を喚起するものをトラッキングすることができ、システムの重要機能であるイベントに対するサポートを通じてアラートを出すことができます。

管理者は、容量が使い尽くされる兆候を確認し、その兆候がシン・プロビジョニングに関連するものではないことを検証するようにアドバイスを受けます。


v SYSTEM_CAN_NOT_INCREASE_SPARES

v SYSTEM_SPARES_ARE_LOW

v DATA_REBUILD_COULD_NOT_BE_COMPLETED

システムの廃止例えば、技術上のリフレッシュ。

ソース・ボリューム上ストレージ管理者は、容量が使い尽くされる兆候を確認し、その兆候がシン・プロビジョニングに関するものではないことを検証します。


v SYSTEM_CAN_NOT_INCREASE_SPARES

v SYSTEM_SPARES_ARE_LOW

v DATA_REBUILD_COULD_NOT_BE_COMPLETED

[2] IBM Hyper-Scale Mobility 操作に関するデータの取得

このステップでは、以下のことを決定するのに必要なデータを収集する必要があります。

1. IBM Hyper-Scale Mobility は必要か。

2. IBM Hyper-Scale Mobility プロセスに関与するシステムはどれか。

必要な容量はどのくらいか空き容量が必要な兆候が現れたら、まず解放する必要がある容量がどのくらいかを決定します。

1. 各種のプール・ボリュームに関連付ける容量はどのくらいか

2. どのボリュームに、スナップショットおよびミラー関係があるか

3. しきい値をどのくらい超過したか


4. 転送量はどのくらいにするか

5. 同じシステム上で使用可能な容量はどのくらいか


v system_capacity_list

v pool_list - プールの詳細をリストする

v vol_list - ボリュームの詳細をリストする

v mirror_list - ミラーリングの詳細をリストする

v snapshot_list - スナップショットの詳細をリストする


v システム・リスト (Systems List)


v プール別のボリューム

v ボリュームおよびスナップショット

v ミラーリング (Mirroring)

IBM Hyper-Scale Mobility 以外で実行することができるステップ必要な容量が判明したら、IBM Hyper-Scale Mobility を選択する前に、以下のオプションについて検討します。

1. ボリュームが使用できる容量を確保するために、別のプールのサイズ変更を行う

2. 容量を解放するために、不要なストレージ・プールを削除する

3. 容量が使い尽くされたストレージ・プール、またはそれに伴ってサイズおよび空き領域が減少したその他のプールで、不要な (複数の) ボリューム (または整合性グループ) を削除するか、移動させる


v pool_resize - ストレージ・プールのサイズ変更を行う (例えば、ソフト・サイズをより大きく設定する)

v vol_move - ボリュームを別のストレージ・プールに移動する

v cg_move - ボリュームを別のストレージ・プールに移動する

v pool_delete

v vol_delete


v プールのサイズ変更 (Pool Resize)

v プールの削除 (Pool Delete)

v ボリュームをプールに移動 (Volumes Move to Pool)

v ボリュームの削除 (Volume Delete)

現行の IBM Hyper-Scale MobilityIBM Hyper-Scale Mobility が優先オプションである場合、優先するソースを選択するために以下のステップを考慮してください。

1. 以下のいずれかのオプションを使用して容量を解放することにより、ボリューム容量の要件を満たすことができる。


v 同一のプールにある別のボリュームのマイグレーション (IBM

Hyper-Scale の最初のリリースでマイグレーションすることができないスナップショットおよびミラーリングは除きます。ミラー・ボリュームには特別に注意を払う必要があります。IBM Hyper-Scale Mobility

ピアのミラー関係を削除し、IBM Hyper-Scale Mobility のマイグレーション完了時に新しいミラー関係を確立 (または再確立) する必要があるためです。)。

v 別のプールにあるボリュームのマイグレーション。マイグレーション後にこのプールをサイズダウンすることで、システムの容量を解放できます。

宛先ボリューム上優先する宛先を選択するために以下のステップについて考慮してください。

v 有効なターゲットを決定します (例えば、ソースと宛先は同じ場所に配置されていなければなりません。また、適切な接続オプションが必要です)。新しいシステムをまだターゲットとして設定していない場合でも、以下の優先順位に基づいて (下記も参照)、設定するのが望ましい場合があることに注意してください。

v 使用可能な容量によって、または宛先として使用するために容量を解放できるかどうか、あるいは IBM Hyper-Scale Mobility に対応できるかどうかによって、潜在的なターゲットを決定します。この際、アプリケーションの予想されるパフォーマンスが妨げられることを考慮してください。

v マルチステージのマイグレーション (A>>B、B>>C) について考慮します。ターゲット・マシンに移動する際は、各マシン間のパフォーマンス上の差異 (例えば、構成、メモリー量、SSD などの違いによる) について考慮することをお勧めします。 .

v ホストの「オンライン反転」または「オフライン反転」が必要かどうか考慮してください。「オンライン」オプションを指定すると、ソースおよび宛先の両方の XIV システムによって、同じシリアル番号のボリュームがエクスポートされ、ソースおよび宛先の両方のシステムに対して同じゾーニングが行われます。

v 宛先システムがマイグレーションされたボリュームを (一時的に、または長期的に) 占有するのに必要な時間フレームについて考慮してください。

役割の担当ストレージ管理者に加えて、マイグレーション・オプション (アプリケーションの重要度、ミラーリングおよびスナップショットに関するアプリケーションなど) の優先順位を決定するために、ホスト管理者の関与も必要になる可能性があります。


v target_connectivity_list - システム間の接続

v その他の target _* コマンド

v mirror_list - システム間での複製

v statistics_get - パフォーマンス・メトリック


v host_list

v host_define

v host_add_port

v pool_list - プールの詳細をリストする

v vol_list - ボリュームの詳細をリストする

v mirror_list - ミラーリングの詳細をリストする

v snapshot_list - スナップショットの詳細をリストする


v XIV 接続

v 接続の編集

v ターゲットの作成

v ターゲット・プロパティー

v 統計コマンド

v ホストおよびクラスター

v ホストの追加

v ポートの追加

[3] IBM Hyper-Scale Mobility 操作の優先順位付け

このステップでは、計画済みの IBM Hyper-Scale Mobility プロセスの優先順位を付ける方法を決定する必要があります (アプリケーション関連の特定の要件)。

ソース・ボリューム上マイグレーション・オプション (アプリケーションの重要度、ミラーリングおよびスナップショットに関するアプリケーションなど) の優先順位付けを行います。

役割の担当ホスト管理者の関与が必要な可能性があります。

[4] ゾーニング

このステップでは、ゾーニング関連のステップで実行する必要があるものを決定します。

ソース・ボリューム上同一のホストおよびクラスターに、宛先システムへ接続するオプションがある (または既に接続されている) ことを確実にしてください。これにより、オンラインまたはオフラインの反転マイグレーション (同一または異なるゾーンに対して) が可能になります。

役割の担当ストレージ管理者およびホスト管理者


v host_list

v host_define

v host_add_port



v ホストおよびクラスター

v ホストの追加

v ポートの追加

[5] 計画のまとめ

このステップでは、必要な計画の詳細がすべて使用できることを立証することにより、計画のまとめを行う必要があります。

ソース・ボリューム上計画に関連する詳細がすべて使用可能であることを確実にします。必要に応じて、以下の詳細を収集します。

1. ミラーリング関連のパラメーター (ターゲットなど)

2. スナップショット関連のパラメーター (ショットを取る頻度など)

マイグレーション時にボリューム・ミラーリングが使用できなくなった場合に備えて、コンティンジェンシー・プラン (緊急時対応計画) を準備してください。

宛先ボリューム上IBM Hyper-Scale Mobility プロセスを完了する前後に、宛先システム上で必要な空き容量があることを必ず確認してください。

宛先プールがロックされていないことを確認してください。


v system_capacity_list

v pool_list


v システム・リスト (Systems List)


[ステージ 2:] IBM Hyper-Scale Mobility プロセスのセットアップ

このフェーズでは、ソースと宛先の間の IBM Hyper-Scale Mobility 関係を設定し、アクティブ化します。

[1] 事前定義

このステップは、マイグレーションする予定のボリュームに、ミラーリング関係またはスナップショット (あるいはその両方) がある場合にのみ必要です。例を簡単にするために、1 つのボリュームのみをマイグレーションするとします。

マルチパスIBM Hyper-Scale Mobility の処理を開始する前に、マルチパスを使用していることを確認してください。


マイグレーション済みボリュームの場所の特定xiv_devlist の volName のみを使用します。OS のディスク・マネージャーやディスク・ツールを使用すると、間違った情報が表示される場合があります。

ソース・ボリューム上ソース・ボリュームが現在ミラーリング関係にある場合:

1. ミラーを非アクティブ化する

2. ミラーを削除する


v mirror_list

v mirror_deactivate

v mirror_delete


v ミラーリング (Mirroring)

v ミラーの非アクティブ化 (Mirror Deactivate)

v ミラーの削除 (Mirror Delete)

[2] IBM Hyper-Scale Mobility 関係の定義

IBM Hyper-Scale Mobility 関係は、マイグレーションを目的として、ソース・ボリュームと宛先ボリュームを対にします。この時点で、マイグレーションされる予定のボリュームに関連する関係はありません。使用可能なすべての関係を確認するために olvm_list XCLI コマンドを実行しても、何も検出されません。

以下の画面出力を確認します。

>> olvm_listNo olvms match the given criteria

vol_list XCLI コマンドを実行すると、マイグレーション予定のボリュームが検出されます。この例を簡単にするために、このボリュームを Vol_A と呼ぶことにします。

>> vol_listName Size (GB) Pool Creator Proxy Used Capacity (GB)------- ----------- ------- --------- ---------------- ------------------Vol_A 17 P_122 admin OLVM_TYPE_NONE 0

このボリュームには、マイグレーションに関連する Proxy という属性があります。この現在の値は、ボリュームがいずれの IBM Hyper-Scale Mobility プロセスにも関連付けられていないことを示しています。

プロキシーOLVM_TYPE_NONE

設定がすべて完了したので、IBM Hyper-Scale Mobility 関係の作成を開始します。

olvm_create XCLI コマンドを使用し、以下のパラメーターへの入力を指定して、IBM Hyper-Scale Mobility 関係を作成します。


vol ソース XIV システム上のボリューム名 (上記に示したように、これはVol_A です)。

target 宛先 XIV システムの名前。このシステムにボリュームをマイグレーションします。

remote_pool宛先 XIV システム上のプール名。このプールにボリュームがマイグレーションされます。

この時点で、システム管理者はソース・ボリュームのミラーリング関係を削除します。

実行するコマンドは、次のようになります。

>> olvm_create target='XIV 6030108' remote_pool=P_108 vol=Vol_ACommand completed successfully

次に、olvm_list を実行して、IBM Hyper-Scale Mobility 関係とその属性を確認します。

>> olvm_listVolume name Role Remote System Active Phase State Link Up----------- ------ --------------- ------- -------------------- ------------ ------Vol_A source XIV 6030108 no OLVM_PHASE_MIGRATION Initializing yes

IBM Hyper-Scale Mobility 関係の属性は、以下のとおりです。

役割 Vol_A は、マイグレーションされるボリュームです。

Active (アクティブ)マイグレーションはまだアクティブになっていません。

フェーズプロセスのフェーズは、現在 OLVM_PHASE_MIGRATION です。

状態マイグレーションは現在初期化中の状態であり、アクティブ化されるのを待機しています。

Link Up (リンクアップ)IBM Hyper-Scale Mobility 関係は、ソースと宛先の XIV システムの間のリンクが稼働している場合にのみ発生します。

この時点で、以下のいずれかを実行できます。

v IBM Hyper-Scale Mobility 関係をアクティブ化して、マイグレーションを開始する。

v マイグレーションを中止し、IBM Hyper-Scale Mobility 関係を削除する。

[3] IBM Hyper-Scale Mobility 関係のアクティブ化

マイグレーションをアクティブ化すると、ソース・システムから宛先システムへのボリュームのマイグレーションが開始します。 olvm_activate XCLI コマンドの実行は、次のようになります。


olvm_activate vol=Vol_ACommand completed successfully

必須パラメーターは、マイグレーションされるボリュームの名前のみです。

olvm_list を実行して結果をトレースし、このマイグレーションを追跡してみます。

>> olvm_listVolume name Role Remote System Active Phase State Link Up------------ ------ --------------- -------- ---------------------- -------------- -------Vol_A source XIV 6030108 yes OLVM_PHASE_MIGRATION Initializing yes

Active フィールドの値が yes に変更されていることに注意してください。

olvm_list を実行して XML 形式での出力を要求すると、より多くの情報を確認することができます。

>> olvm_list -x<olvm id="8b814000009"><name value="Vol_A"/><role value="source"/><target_name value="XIV 6030108"/><active value="yes"/><phase value="OLVM_PHASE_MIGRATION"/><state value="Initializing"/><connected value="yes"/><sync_progress value="47"/><size_to_synchronize value=”16281”/><estimated_sync_time value=”32”/><mirror_error value=”No_Error”/></olvm>

sync_progress の値は、ボリュームのマイグレーションの進捗をパーセントで示しています。estimated_sync_time の値は、マイグレーションの終了までの残り時間 (秒)

です。

アクティブ化が終了すると、IBM Hyper-Scale Mobility 関係は Proxy-Ready (プロキシー準備完了) フェーズに移行します。ソースは完全に宛先にマイグレーションされ、IBM Hyper-Scale Mobility プロセスは (システム管理者が指示すれば) Proxy (プロキシー) フェーズに移行できる状態です。

>> olvm_listVolume name Role Remote System Active Phase State Link Up------------ ------- --------------- ------- ---------------------- ------------ -------Vol_B source XIV 6030108 yes OLVM_PHASE_PROXY_READY Synchronized yes


フェーズプロセスのフェーズは、現在 OLVM_PHASE_MIGRATION です。

状態マイグレーションは、現在同期済みの状態です。

次は、オンライン・マイグレーション関係を Proxy-Ready (プロキシー準備完了) から Proxy (プロキシー) のフェーズに上げます。


[ステージ 3:] マイグレーションのトラッキング実行中のマイグレーションの進行状況をトラッキングすることができます。

[1] マイグレーションの進行状況のモニター

このステップでは、IBM Hyper-Scale Mobility プロセスの状態、状況および進行状況をモニターします。


v olvm_list


v オンラインのマイグレーション

以下を使用して、システム・パフォーマンスをモニターすることもできます。


v statistics_get


v 統計コマンド

[ステージ 4:] プロキシーの確立プロキシー・ステージでは、ソースはホストにおいて、宛先ボリュームに対するプロキシーとしてのサービスを行います。

[1] 「プロキシー」状態への遷移

このステップでは、ボリュームをプロキシー (このフェーズでは、ソースは、現在宛先上にのみ存在するボリューム・データに対するプロキシーとしてのサービスをホストに対して行います) に移行する必要があります。マイグレーションされるソース上のボリュームは、後で削除されます。

olvm_proxy XCLI コマンドを実行します。

olvm_proxy vol=Vol_ACommand completed successfully

olvm_list を実行して、結果を表示します。

>> olvm_listVolume name Role Remote System Active Phase State Link Up------------ -------- --------------- -------- ------------------ ------- -------Vol_A source XIV 6030108 yes OLVM_PHASE_PROXY Proxy yes


フェーズプロセスのフェーズは、現在 OLVM_PHASE_PROXY です。

状態マイグレーションは、現在プロキシー (Proxy) の状態です。

宛先上で olvm_list を実行します。


>> olvm_listVolume name Role Remote System Active Phase State Link Up------------ ------------ --------------- -------- ------------------ --------- -------Vol_A destination XIV 6030122 yes OLVM_PHASE_PROXY Proxied yes

IBM Hyper-Scale Mobility 関係の属性は、次のとおりです (宛先から見た場合)。

Volume name (ボリューム名)マイグレーションされたボリュームの名前は、保持されています。

マイグレーションされたボリュームに、新しい名前を設定することができます。XCLI リファレンス・ガイドの olvm_create の資料を参照してください。

役割このフィールドの値は、ここにリストされているボリュームが、IBM

Hyper-Scale Mobility 関係の宛先ボリューム上に存在することを示しています。

フェーズプロセスのフェーズは、現在 OLVM_PHASE_PROXY です。

状態マイグレーションは、現在プロキシー処理済み (Proxied) の状態です。

[2] オンライン反転

このステップでは、Proxy (プロキシー) の操作が機能することを確認するアクションを実行します。

ホストの再スキャンホスト上で RESCAN 操作を実行します。

ホストの宛先へのマッピング入出力の受け入れを開始するために、宛先ボリュームはホストと同期させる必要があります。

>> map_vol vol=Vol_A host=Host_1 lun=1Command completed successfully


v vol_map

v map_list


v ホスト別のボリューム

v LUN マッピングの表示

ホストの再スキャンホストを宛先に接続するために、ホスト上で RESCAN 操作を実行します。

ソースのマップ解除宛先ボリュームがホストに対してマップされたので、ソース・ボリュームのマップを解除することができます。

unmap_vol vol=Vol_A host=Host_1Command completed successfully



v unmap_vol


v ボリュームのマップ解除 (Volumes Unmap)

ホストの再スキャンホスト上で RESCAN 操作を実行します。

関係の状態および状況の確認


v olvm_list


v オンラインのマイグレーション

[ステージ 5:] クリーンアップ宛先ボリュームがホストと連動するようになったら、IBM Hyper-Scale Mobility 関係を削除することができます。

このステップでは、次のようにして IBM Hyper-Scale Mobility 関係を削除することによって、IBM Hyper-Scale Mobility のメイン・プロセスを終了させます。

>> olvm_delete vol=Vol_ACommand completed successfully

olvm_list を実行すると、IBM Hyper-Scale Mobility 関係が存在しなくなっていることが表示されます。

>> olvm_listNo olvms match the given criteria

[ステージ 6:] 完了後IBM Hyper-Scale Mobility プロセスが完了したら、マイグレーションされたボリュームに対するミラーリングとスナップショットをリストアします。

ミラーリングの確立については、本書の以下の章で説明しています。

v 57ページの『第 6 章同期リモート・ミラーリング』

v 77ページの『第 7 章非同期リモート・ミラーリング』

スナップショット・ポリシーの決定については、本書の以下の章およびセクションで説明しています。

v 29ページの『第 3 章ボリュームおよびスナップショットの概要』

v 31ページの『スナップショット』

IBM Hyper-Scale Mobility CLI コマンドこのセクションでは、IBM Hyper-Scale Mobility の定義および操作を行う XCLI コマンドについて簡単に説明します。構文や例を含む詳しい説明は、XCLI リファレンス・ガイドに記載されています。


olvm_createこのコマンドは、マイグレーションされる予定のボリュームと、このマイグレーションのターゲットを識別することにより、IBM Hyper-Scale Mobility

関係を定義します。

このコマンドは、以下の入力を受け付けます。

ローカル・システム上マイグレーションされるボリュームの名前。

ターゲット・システム上ボリュームのマイグレーション先となるターゲット・システムの名前。

ターゲット・システム上のプールの名前。ここにターゲット・システムが作成されます。

olvm_activateこのコマンドは、IBM Hyper-Scale Mobility 関係をアクティブ化します。前提条件として、IBM Hyper-Scale Mobility 関係の作成は、前述したように行う必要があります。


ローカル・システム上マイグレーションされるボリュームの名前。この名前は、IBM

Hyper-Scale Mobility 関係の ID の役割をします。

ターゲット・システム上なし。

olvm_deactivateこのコマンドは、IBM Hyper-Scale Mobility を非アクティブ化します。





olvm_abortこのコマンドは、定義された、またはアクティブ化された IBM Hyper-Scale

Mobility プロセスを中止します。




オプション入力このコマンドは、以下のオプション入力を受け付けます。

v ソース上の IBM Hyper-Scale Mobility 関係を強制的に削除する

v 宛先上の IBM Hyper-Scale Mobility 関係を強制的に削除する


olvm_proxyこのコマンドは、IBM Hyper-Scale Mobility ピアを、プロキシー・フェーズに移行します。


ローカル・システム上ピアの名前。


olvm_deleteこのコマンドは、ローカルにある IBM Hyper-Scale Mobility 関係を削除します。


ローカル・システム上マイグレーションされるボリュームの名前。

オプション入力このコマンドは、以下のオプション入力を受け付けます。

v 宛先上の IBM Hyper-Scale Mobility 関係を強制的に削除する

olvm_listこのコマンドは、XIV システム上にあるすべての IBM Hyper-Scale Mobility

関係をリストします。

このコマンドには、必須パラメーターがありません。ローカル・ボリュームのみに関する情報を返すために、ローカル・ボリュームの名前を入力として受け付けることは可能です。

このコマンドの出力では、IBM Hyper-Scale Mobility 関係のそれぞれについて、以下の情報が提供されます。

v Volume name (ボリューム名)

v Role (役割) - このフィールドは、該当のボリュームが IBM Hyper-Scale

Mobility 関係のソースであるか宛先であるかを示します。

v Remote system (リモート・システム) - もう一方のボリューム (ソースまたは宛先) が存在するリモート・システムの名前。

v Active (アクティブ) - IBM Hyper-Scale Mobility 関係がアクティブであるかどうかを示します。

v Phase (フェーズ) - IBM Hyper-Scale Mobility のフェーズを示します (示される値は、Migration (マイグレーション)、Proxy-Ready (プロキシー準備完了)、Proxy (プロキシー) です)。

v State (状態) - ボリュームの状態。ソースと宛先の役割の状態には、別個のフローがあります。

v Link (リンク) - リンクが現在稼働しているかどうかを示します。


データ・マイグレーション新規ストレージ・システムを使用する場合、前のストレージ・システムから新規IBM XIV Storage System への大量のデータの転送が頻繁に必要となります。この転送には、数時間あるいは数日 (すなわち、通常は、ほとんどの企業が作業システムなしで済ますことができない時間) まで要する可能性があります。データ・マイグレーション機能により、データ転送の進行中でも実動環境を維持することができます。

データ・マイグレーション・プロセスの性質を考慮すると、データ・マイグレーションの計画を立てるときに IBM XIV Storage System サポート・チームに連絡を取り、支援を受けることをお勧めします。

データ・マイグレーションの概要データ・マイグレーション機能により、以下を行うことで、前のストレージ・システムと連動するホストの IBM XIV Storage System への円滑な移行が可能になります。

v ホストを XIV に即時に接続し、データが前のストレージ・システムからコピーされる前でさえ最新のデータへの直接アクセスをホストに提供する。

v バックグラウンド・プロセスとして前のストレージ・システムの内容を XIV にトランスペアレントにコピーすることにより、前のストレージ・システムからXIV を同期化する。

データ・マイグレーション中は、ホストは、XIV に直接接続され、前のストレージ・システムから切断されます。XIV は、図 52で示すように、前のストレージ・システムに接続されます。XIV と前のストレージ・システムは、両方のストレージ・システムが同期化され、データ・マイグレーションが完了するまで、接続されたままでなければなりません。前のストレージ・システムは、XIV をホストとして認識し、マイグレーション中のボリュームからの読み取りおよびオプションでそのボリュームへの書き込みを行います。ホストは、XIV との間でデータの読み取りおよび書き込みを行います。その一方で、XIV は、ホストのコマンドを実施するために、そのデータを読み取るかまたは前のストレージ・システムに書き込む必要が生じる場合があります。

図 52. データ・マイグレーション・プロセスは、ボリュームごとに実行されます。


ホストと XIV の間の通信および XIV と前のストレージ・システムの間の通信は、ファイバー・チャネルです。

データ・マイグレーションでの入出力処理読み取り要求のサービス提供

このステージで、IBM XIV Storage System は、すべてのホストのデータ読み取り要求のサービスを行います。これは、ホストからのアクションを必要とせず、以下のように透過的な方法で行われます。

v 要求されたデータがすでに XIV にコピーされている場合、それは XIV から提供されます。

v 要求されたデータがまだ XIV にコピーされていない場合、XIV が前のストレージ・システムからそのデータを取り出してから、それをホストに提供します。

書き込み要求のサービス提供

このステージで、XIV は、すべてのホストのデータ書き込み要求にサービスを提供します。これは、ホストからのアクションを必要とせず、透過的な方法で行われます。

ホストからの書き込み要求を処理するために、データ・マイグレーションには、以下の 2 つの XIV 構成の選択肢があります。

ソース更新:ホストの書き込み要求は、XIV によって XIV と前のストレージ・システムに書き込まれます。この場合、前のストレージ・システムは、バックグラウンドのコピー・プロセス中に、完全にアップデート済みのままになっています。このプロセスを通じて、前のストレージ・システムのボリュームとXIV のボリュームは同じです。

書き込みコマンドは同期的に実行されるため、XIV は、それ自体への書き込み、前のストレージ・システムへの書き込み、および前のストレージ・システムからの応答の受信の後でのみ書き込み操作を認知します。さらに、通信エラーまたはその他のエラーにより前のストレージ・システムへの書き込みが失敗すると、XIV は、その書き込み操作が失敗したことをホストに報告します。

ソース更新なし:ホストの書き込み要求は、XIV によって XIV にのみ書き込まれ、前のストレージ・システムには書き込まれません。この場合、前のストレージ・システムは、バックグラウンドのコピー・プロセス中はアップデートされないため、2 つのストレージ・システムが同期することはあり得ません。前のストレージ・システムのボリュームは完全なまま保持され、データ・マイグレーション・プロセスの間中、変更されることはありません。

データ・マイグレーションの各ステージ162ページの図 53 は、前のストレージ・システムから IBM XIV Storage System

にボリュームをマイグレーションするプロセスを示したものです。この図は、XIV

がそのデータを前のストレージ・システムと同期化する方法と、同期化のこれらす


べての段階でホストのデータ要求を処理する方法も示しています。

初期構成

XIVのボリュームは、データ・マイグレーションの開始前にフォーマットする必要があります。XIV は、提供予定のデータを保持している前のストレージ・システムにホストとして接続する必要があります。

前のストレージ・システム上のボリュームと XIV 上のボリュームは、同じブロック数でなければなりません。これは、データ・マイグレーション・プロセスの活動化の際に検証されます。

次に、データ・マイグレーションを開始し、XIV と直接かつ単独で連動するようにすべてのホストを構成することができます。

データ・マイグレーションは、dm_define コマンドを使用して定義されます。

データ・マイグレーション構成のテスト

ホストを XIV に接続する前に、dm_test XCLI コマンドを使用して、XIV が前のストレージ・システムにアクセスできるかを確認するためのデータ・マイグレーション定義をテストします。

図 53. データ・マイグレーションの各ステップ


データ・マイグレーションの活動化

XIV と前のストレージ・システムとの間の接続をテストした後で、dm_activateXCLI コマンドを使用してデータ・マイグレーションを活動化し、ホストを XIV に接続します。この時点から、ホストは、XIV との間でデータの読み取りおよび書き込みを行います。さらに、XIV はデータを読み取り、オプションで前のストレージ・システムに書き込みます。

データ・マイグレーションは、dm_deactivate コマンドを使用して非活動化することができます。次に、データ・マイグレーションを再度活動化することができます。データ・マイグレーションを非活動化する間、ホストがボリュームにアクセスすることはできません (読み取りアクセスも書き込みアクセスも許可されません)。

バックグラウンド・コピーおよび入出力操作の提供

データ・マイグレーションは、開始されると、前のストレージ・システムから XIV

にすべてのデータを順次にコピーするバックグラウンド・プロセスを開始します。

同期達成

ボリュームのデータのすべてをコピーした後で、データ・マイグレーションは同期を達成します。同期が達成された後で、すべての読み取り要求は XIV から実施されます。

ソース更新が Yes に設定されている場合、XIV は、データ・マイグレーション設定が削除されるまで、それ自体と前のストレージ・システムの両方へのデータの書き込みを続行します。

データ・マイグレーションの削除

データ・マイグレーションは、削除コマンドを使用して停止されます。データ・マイグレーションを再開することはできません。

障害の処理IBM XIV Storage System は、通信エラーまたは前のストレージ・システムの障害が起きた時に、ホストに対する読み取り要求と書き込み要求の両方を含む入出力操作のサービスを停止します。

XIV が前のストレージ・システムでメディア・エラーを検出した場合 (つまり、XIV が前のストレージ・システムのブロックを読み取ることができない場合)、XIV

は、その状態を自身のストレージ・システムに反映させます (つまり、自身のストレージ・システムの同じブロックとエラーにマークを付けます)。このブロックの状態は、XIV 内のディスクに障害がなくても、メディア・エラーを示すことになります。


第 10 章保存データの暗号化

規則への準拠およびセキュリティー監査に対応できるようにするため、IBM XIV

Storage System はフルディスク暗号化を使用します。

保存データの暗号化は、破棄されたメディアや盗まれたメディアからの XIV システムの機密データの潜在的な漏えいを保護します。暗号化を行うことにより、暗号鍵が保護されている限りデータが読み取られないようにします。この機能は、お客様のサイトにおける物理的セキュリティーを補完し、データに対する無許可アクセスからお客様を保護します。

ディスク・ドライブの暗号化は、IBM XIV Storage System に接続されているホストには認識されず、ホストの管理やパフォーマンスのいずれにも影響を与えません。「伝送途中のデータ」という用語は、ネットワーク・インターフェース、メモリー、Infiniband バックボーンの中のどこにでもある入出力を意味します。このタイプのデータは暗号化されません。

保存データの保護が必要となる一般的なユース・ケースには、以下のものがあります。

v サービス・プロバイダーの SAN における統合ストレージに対する無許可アクセス (例: ディスクの盗難)

v コンポーネントの循環:

– お客様のサイトにおいて IBM XIV Storage System から物理的に削除したあとのデータの保護

– 破棄されたメディアからの情報漏えいの防止 (例: 障害のあるディスク)

v 新規コンポーネントの追加 - SSD またはモジュールのアップグレード (MES) では IBM XIV Storage System の暗号化機能を維持する必要があります。

HIPAA の互換性IBM XIV Storage System は、セキュリティーに関する以下の要件と規格に準拠しています。

IBM XIV Storage System の保存データの暗号化は、以下のように HIPAA の連邦要件に準拠します。

v ユーザー・データは、XIV システム固有の鍵入力要素 (鍵サーバーや認証ファイルなど) がなければアクセスできません。

v 暗号鍵を暗号化されたデータと物理的に分離するには、外部の鍵サーバーを使用します。

v 暗号鍵はユーザーの責任において置き換えることができます。

v 保管する鍵はすべて、暗号文の中 (プレーン・テキストに置いたり、隠し鍵や難読化された鍵にしたりするのではなく) でラップして保管しなければなりません。


v 鍵をラップしたりデータを暗号化したりするには AES 256 暗号化を使用し、公開鍵暗号方式の場合には RSA 2048 暗号化を使用します。

v 暗号化の構成と設定は監査可能でなければならないため、関連する情報と通知はイベント・ログに保持する必要があります。

保存データ (data-at-rest) の暗号化とはIBM XIV Storage System は、以下の保存データの暗号化に関するユース・ケースをサポートします。

v 保存データの暗号化を使用するための XIV システムの構成

– 鍵サーバーへの接続

– セキュリティー管理者の定義

– リカバリー・キーの受信者の指定

– セキュリティー管理者間でのリカバリー・キーの分配

v 保存データの暗号化を使用する処理

– XIV の電源が投入されると、鍵サーバーが使用可能になる

– XIV の電源が投入されても、鍵サーバーが使用可能にならない

v 保存データの暗号化を使用不可にする

v リカバリー・キーを使用せずに暗号化を使用可能にする

始動時に、XIV システム用に鍵サーバーが使用可能である場合と、そうでない場合とを区別します。後者に対応するために、XIV システムはリカバリー・キーを生成します。

鍵サーバーへの接続XIV システムは、鍵サーバーを使用した作業を認知します。

関連する XCLI コマンド:

v encrypt_keyserver_define - 始動時、または暗号化を活動化する際に、XIV システムが使用する鍵サーバーを定義し、暗号処理でディスクをアンロックするのに必要な鍵情報を取得します。

v encrypt_keyserver_rekey - マスター鍵サーバーに対する鍵再設定を開始します。

v encrypt_keyserver_delete - XIV 構成から鍵サーバーを削除します。

v encrypt_keyserver_rename - 鍵サーバーの名前を変更します。

v encrypt_keyserver_list - XIV システムに現在定義されている鍵サーバーを、その接続状況とともにリストします。

v encrypt_keyserver_update - 鍵サーバーのアドレスとポートを変更するために使用します。

セキュリティー管理者の定義XIV では、新しいユーザー・タイプを導入します。このユーザーは暗号化に関連したタスクを実行しますが、ストレージ管理者である必要はありません。一方、ストレージ管理者は、セキュリティー関連のタスクを実行するための許可を持っていません。



v user_define - 各セキュリティー管理者は、リカバリー・キーに関するそれぞれの分担部分を提供するためにこのコマンドを使用します。

リカバリー・キーの受信者の指定セキュリティー管理者は、XIV システムを使用可能にするために必要な最小数のリカバリー・キーを指定し、暗号化されたディスクをアンロックします。また、セキュリティー管理者はリカバリーに関与することもできます。

デフォルトは 2 人のセキュリティー管理者です。


v encrypt_recovery_key_generate - リカバリー・キーを受信するセキュリティー管理者、および暗号化された鍵をアンロックするために入力する(encrypt_recovery_key を使用) 必要がある最小数のリカバリー・キーを指定します。このコマンドを入力したあと、指定されたすべてのセキュリティー管理者は、encrypt_recovery_key_get とencrypt_recovery_key_verify を使用して、リカバリー・キーの取得と検証をそれぞれ行うことになります。

v encrypt_recovery_key_status - 鍵を検査したセキュリティー管理者 (あるいは、ディスクがアンロックされている場合は、鍵を入力したセキュリティー管理者) を指定します。

v encrypt_recovery_key_list - リカバリー・キーの情報、具体的には、その鍵が作成された日付、および鍵をセキュリティー管理者間に分配する方法をリストします。

v encrypt_recovery_key_rekey - リカバリー・キーの生成プロセスを再始動します (encrypt_recovery_key_generate と類似)。

セキュリティー管理者間でのリカバリー・キーの分配リカバリー・キーの受信者として指定された各セキュリティー管理者がXIV システムにログインし、鍵のそれぞれの分担部分を受信します。


v encrypt_recovery_key_get

v encrypt_recovery_key_verify

XIV の電源が投入されると、鍵サーバーが使用可能になるXIV システムは鍵サーバーに接続され、ユーザーの介入は必要ありません。

このユース・ケースでは以下のようになります。

v 保存データの暗号化はこの XIV システム用に活動化されます。

v XIV システムは、構成された鍵サーバーを使用して作業を行うように構成されます (XIV システムが複数の鍵サーバーを使用して作業を行うように構成されている場合もあります)。

v XIV サーバーが鍵サーバーと通信します。

XIV システムと鍵サーバーはお互いに認証し合います (したがって、両方共にスプーフィング (なりすまし) 攻撃や中間者攻撃 (man-in-the-middle

attack) から保護されます)。

XIV の電源が投入されても、鍵サーバーが使用可能にならない電源が投入された時、XIV システムでは、構成されたどの鍵サーバーも使

第 10 章保存データの暗号化 167

用可能な状態にはなりません。鍵サーバーを高可用性マシンに配置することが特に重要です。暗号化が有効になっていて、システムの電源オン時に使用可能な鍵サーバーがない場合、鍵サーバーが到達可能になるか、手動でリカバリー・キーが入力されるまでは、ユーザー・データはアクセス不能 (ロック) のままになります。

このユース・ケースでは、ブート・プロセスは保守モードで停止し、イベントが発行され、どのディスクも使用可能にはなりません。ディスクを使用可能にする (つまり、アンロックする) には、セキュリティー管理者がXIV システムにログインし、各自のリカバリー・キーを提供する必要があります (上記の『リカバリー・キーの受信者の指定』を参照)。


v encrypt_recovery_key_enter - 各セキュリティー管理者は、リカバリー・キーに関するそれぞれの分担部分を提供するためにこのコマンドを使用します。

v encrypt_recovery_key_finish - システムは保守モードからオンに切り替えられ、ディスクが再び使用可能になります。

保存データの暗号化を使用不可にする保存データの暗号化を使用不可にするには、XIV システムが以下の条件を満たす必要があります。

v システム上にボリュームがない。


v encrypt_disable - このコマンドは、XIV システム上で保存データの暗号化を使用不可にします。

リカバリー・キーを使用せずに暗号化を使用可能にするこのユース・ケースでは、XIV システムは、リカバリー・キーを設定せずに暗号化されます。

XIV システムは、鍵サーバーに接続されており、暗号化が使用可能です (下記参照)。鍵サーバーが使用不可になると、システムのディスクはロックされ、アクセス不能です。鍵サーバーが再び使用可能になると、システムは作動を再開します。

このユース・ケースは XCLI からのみ使用可能です。暗号化を使用可能にする場合は、encrypt_enable recovery_key=no を実行します。

SED GUI の資料保存データの暗号化に関する GUI の制御については、XIV の資料に記載されています。

SED GUI の資料は、管理ツールの操作ガイド (リリース 4.3 以降) にあります。「自己暗号化ディスクの管理 (Managing Self-Encrypting Disks)」の章では、以下のトピックについて説明します。

セキュリティー管理者ユーザーの作成すべての SED 管理タスクはセキュリティー管理者が実行します。


単一システムにおけるセキュリティー・アクション鍵サーバーの管理およびリカバリー・キーの生成と獲得に関するタスクは、単一の XIV システム上で実行されます。

鍵サーバーの追加鍵サーバーの追加、編集、鍵再設定、および削除を行います。

リカバリー・キーの生成リカバリー・キーの生成と検査を行います。

暗号化の使用可能化暗号化を使用可能 (あるいは使用不可) にします。

第 10 章保存データの暗号化 169

第 11 章イベント処理

IBM XIV Storage System は、ご使用のストレージ・システムの正常性、構成変更、および活動をモニターし、システム・イベントを生成します。これらのイベントは、システムによって累積され、以下の 2 つの方法でユーザーに役立てることができます。

v ユーザーは、さまざまなフィルターを使用してこれまでに発生したイベントを表示できます。これは、トラブルシューティングおよび問題判別に役立ちます。

v ユーザーは、1 つ以上の通知を送信するようにシステムを構成できます。これらの通知は、特定のイベントの発生時に生じます。これらの通知は、イベント、重大度、およびコードに従ってフィルタリングすることができます。通知は、E メール、SMS メッセージ、または SNMP トラップを使用して送信できます。

イベント情報イベントは、次のようなさまざまなプロセスによって作成されます。

v オブジェクト (ボリューム、スナップショット、マップ、ホスト、およびストレージ・プールを含む) の作成または削除

v 物理コンポーネント・イベント

v ネットワーク・イベント

各イベントには、以下の情報が含まれます。

v システム規模の固有の数値 ID

v イベントのタイプを示すコード

v 作成タイム・スタンプ

v 重大度

v 関連するシステム・オブジェクトおよびコンポーネント (ボリューム、ディスク、モジュールなど)

v テキスト記述

v アラート・フラグ。この場合、イベントはイベント通知規則によるアラートとして分類されます。

v クリアされるフラグ。この場合、アラート・イベントは、クリアされない状態またはクリアされる状態にすることができます。これは、アラート・イベントにのみ関連します。

イベント情報は、以下のいずれかの重大度レベルを用いて分類することができます。

クリティカル直ちに確認が必要

重度すぐに確認が必要

軽度通常の業務時間内での確認が必要

警告問題がないか検査するための急を要さない確認が必要


通知通常の作業手順イベント

イベントの表示IBM XIV Storage System は、次のようにイベントのリストを表示するためのさまざまな基準を提供します。

v タイム・スタンプの前

v タイム・スタンプの後

v コード

v 特定の値以上の重大度

v アラート・イベント (スヌーズ・タイマーに従って繰り返し送信されるイベント)

v 未消去のアラート

フィルタリングされたイベントの表示数は、制限することができます。

イベント通知規則の定義IBM XIV Storage System は、ご使用のストレージ・システムの正常性、構成変更、および活動をモニターし、システム・イベントについての通知をその発生時に送信します。イベント通知は、次の規則に従って送信されます。

対象イベント通知の送信の対象となるイベントの重大度またはイベント・コードあるいはその両方。

場所通知の送信先の宛先または宛先グループ (携帯電話番号 (SMS)、E メール・アドレス、SNMP アドレスなど)。

通知は、次の規則に従って送信されます。

宛先イベントの通知の送信先の宛先または宛先グループ。

フィルターイベント通知の送信を引き起こすイベントを指定するフィルター。通知は、イベント・コードまたは最小重大度 (特定の重大度以上) あるいはその両方でフィルタリングすることができます。

アラートイベントが実際に受信されたことを確認するには、イベント通知が XCLI

コマンドまたは IBM XIV Storage Management GUI によってクリアされるまで、イベント通知を繰り返し送信することができます。このようなイベントはアラート・イベントと呼ばれます。アラート・イベントは、スヌーズ時間が分単位で定義されるイベントです。これは、アラート・イベントが、クリアされるまでスヌーズ時間ごとに繰り返し再送されることを意味します。アラート・イベントは、最初の発生時にはクリアされず、ユーザーがクリアすることができます。クリアされた状態は、問題が解決されたことを意味しません。これは、イベントが問題を解決する責任がある関係要員によって留意されたことを意味するにすぎません。イベントがクリアされるまで通知を繰り返すためのスキームには、スヌーズとエスカレーションの 2 つのスキームがあります。


スヌーズこの規則に合致するイベントは、イベントがクリアされるまで、スヌーズ・タイマーで指定されたインターバルで、繰り返される通知を同じ宛先に送信します。

エスカレーションエスカレーション規則とエスカレーション・タイマーを定義することができます。その結果、イベントがタイマーの有効期限が切れる時刻までにクリアされない場合は、通知が所定の宛先に送信されます。これにより、イベントがクリアされなかった場合に、より広範囲の配布リストに通知を自動的に送信することができます。

アラート・イベント構成に関する制限次の制限が、アラート規則の構成に適用されます。

v 規則は非アラート規則までエスカレートできません。これは、エスカレーションまたはスヌーズ、あるいはその両方がない規則を意味します。

v エスカレーション時間は、スヌーズ時間より短い時間として定義してはなりません。

v エスカレーション規則は、ループ (サイクル・エスカレーション) それ自体まで、またはループまでエスカレートする別の規則までエスカレートすることにより、ループを作成してはなりません。

v アラート規則の構成は、その時点で未解決のアラート・イベントがあるときに変更することはできません。

宛先の定義イベント通知は、1 つ以上の宛先に送信することができます。この宛先は、特定のSMS 携帯番号、E メール・アドレス、または SNMP アドレス、あるいは複数の宛先から構成される宛先グループを指します。以下の各宛先は、説明されているように定義する必要があります。

SMS 宛先

SMS 宛先は、電話番号を指定して定義されます。宛先を定義する場合、接頭部と電話番号を区切る必要があります。これは、一部の SMS ゲートウェイでは接頭部について特殊な処理を行う必要があるからです。

デフォルトでは、すべての SMS ゲートウェイを使用できます。特定の SMS 宛先は、一部の SMS ゲートウェイのみを使用して送信されるように制限することができます。

E メール宛先

E メール宛先は E メール・アドレスで定義されます。デフォルトでは、すべてのSMTP ゲートウェイが使用されます。特定の宛先は、一部の SMTP ゲートウェイのみを使用して送信されるように制限することができます。

第 11 章イベント処理 173

SNMP マネージャー

SNMP マネージャー宛先は、SNMP メッセージを受信するために使用できる SNMP

マネージャーの IP アドレスで指定されます。

宛先グループ

宛先グループは、単にイベント通知の送信先の宛先のリストです。宛先グループは、SMS 携帯番号、E メール・アドレス、SNMP アドレス、またはこの 3 つの任意の組み合わせから構成することができます。宛先グループは、通知の同じリストが複数の規則に使用されるときに役立ちます。

ゲートウェイの定義イベント通知は、SMS、E メール、または SNMP マネージャーで送信することができます。このステップでは、E メールまたは SMS の送信に使用されるゲートウェイを定義します。

E メール (SMTP) ゲートウェイ

複数の E メール・ゲートウェイを、E メールによるイベントの通知を可能にするために定義することができます。デフォルトでは、IBM XIV Storage System は、ユーザーが指定した順序に従って、最初の使用可能なゲートウェイを使用して各 E メール通知の送信を試みます。最初に試行されたゲートウェイがエラーを戻した場合にのみ、後続のゲートウェイが試行されます。特定の E メール宛先も、特定のゲートウェイのみを使用するために定義することができます。

E メールで送信されるすべてのイベント通知は、構成できるアドレスを保持する送信側を示します。この送信側アドレスは、以下の 2 つの理由により有効なアドレスでなければなりません。

v 多くの SMTP ゲートウェイには有効な送信側アドレスが必要です。これがないと、E メールが転送されません。

v 送信側アドレスは、SMTP ゲートウェイが生成するエラー・メッセージ (誤ったE メール・アドレスまたはいっぱいになった E メール・メールボックスなど) の宛先として使用されます。

E メールから SMS へのゲートウェイ

SMS メッセージは、E メールから SMS へのゲートウェイのリストのいずれか 1

つを使用して携帯電話に送信することができます。1 つ以上のゲートウェイを SMS

宛先ごとに定義できます。

E メールから SMS へのこのようなゲートウェイのそれぞれは、それ独自の SMTP

サーバーを持つか、グローバル SMTP サーバー・リストを使用するか、あるいはその両方を行うことができます。

イベント通知が送信される場合、いずれかの SMS ゲートウェイが、定義された順序に従って使用されます。最初のゲートウェイが使用され、さらに、最初に試行されたゲートウェイがエラーを戻した場合にのみ、後続のゲートウェイが試行されます。


各 SMS ゲートウェイには、E メール・メッセージ内で SMS メッセージをエンコードする方法についてのそれ独自の定義があります。

第 11 章イベント処理 175

第 12 章アクセス制御

IBM XIV Storage System は、ネイティブ認証または LDAP ベースの認証を使用した役割ベースの認証を特色にします。

このシステムは、以下のことを行います。

役割ベースのアクセス制御事前定義の役割および関連タスクに準拠したアクセス柔軟性および高水準のセキュリティーのために組み込まれた役割。

アクセス認証の 2 つの方式IBM XIV Storage System は、以下のユーザー認証方式をサポートします。

ネイティブ認証これは、IBM XIV Storage System 上でのユーザーおよびグループの認証のデフォルト・モードです。このモードでは、ユーザーおよびグループはシステム上のデータベースに対して認証されます。

LDAP このモードが有効になると、システムは LDAP リポジトリーに対してユーザーを認証します。

ユーザーの役割と権限レベルユーザーの役割を使用すると、適用する役割および適用可能な各種制限を指定できます。

注: これらのシステム定義のユーザーにはいずれもデータへのアクセス権限はありません。

表 14. 使用可能なユーザーの役割

ユーザーの役割権限および制限標準的な使用法

読み取り専用「読み取り専用」のユーザーは、システム情報のリストおよび表示のみを行えます。

システム・オペレーターは通常、システム状況のモニター、レポート作成、およびすべてのメッセージのロギングを担当します。ただし、これらの職務を専門とするわけではありません。


表 14. 使用可能なユーザーの役割 (続き)

ユーザーの役割権限および制限標準的な使用法

アプリケーション管理者

アプリケーション管理者のみが以下のタスクを実行します。

v 割り当てられたボリュームのスナップショットの作成

v 割り当てられたホストへの自身のスナップショットのマッピング

v 自身のスナップショットの削除

アプリケーション管理者は通常、特定のサーバーで実行されているアプリケーションを管理します。アプリケーション管理者は、サーバー上の特定のボリュームに制限されるように定義できます。アプリケーション管理者の標準的な職務:

v バックアップ環境の管理:

– バックアップ用スナップショットの作成

– バックアップ・サーバーへのスナップショットのマッピング

– バックアップ完了後のスナップショットの削除

– ボリューム内の新規内容を反映するためのスナップショットの更新

v ソフトウェア・テスト環境の管理:

– アプリケーション・インスタンスの作成

– 新規アプリケーション・インスタンスのテスト

ストレージ管理者ストレージ管理者には、以下を除くすべての機能への権限があります。

v 物理コンポーネントの保守、または物理コンポーネントの状況の変更

v admin という事前定義管理者のみが他のユーザーのパスワードを変更できます。

ストレージ管理者はすべての管理職務を担当します。

技術員技術員は、以下のタスクに制限されます。

v 物理システムの保守

v サービス中またはサービス休止中のコンポーネントのフェーズ設定

技術員はシステムの物理コンポーネントを保守します。システムごとに指定する事前定義技術員は 1

人のみです。技術員は IBM XIV

Storage System 技術サポート・チームのメンバーです。

注:

1. ユーザーはすべて物理コンポーネントの状況を表示できますが、技術員のみがコンポーネントの状況を変更できます。

2. ユーザー名には大/小文字の区別があります。


3. パスワードには大/小文字の区別があります。

事前定義ユーザーIBM XIV Storage System ではいくつかの事前定義ユーザーが構成されています。これらのユーザーは削除できません。

ストレージ管理者このユーザー ID は、システムへの最もハイレベルなお客様アクセスを可能にします。

事前定義ユーザー名: admin

デフォルト・パスワード: adminadmin

技術員このユーザー ID は、IBM XIV Storage System サービス担当員のみが使用します。

事前定義ユーザー名: 技術員

デフォルト・パスワード: パスワードは事前定義されており、IBM XIV

Storage System 技術員のみが使用します。

注: 事前定義ユーザーは、それに対する LDAP 認証がアクティブになっている場合でも、常に IBM XIV Storage System によって認証されます。

アプリケーション管理者アプリケーション管理者の主要な職務はスナップショットを作成および管理することです。アプリケーション管理者は特定のボリューム・セットのスナップショットを管理します。アプリケーション管理者が属するユーザー・グループにより、そのアプリケーション管理者が管理できるボリューム・セットが決まります。

ユーザー・グループユーザー・グループは、同じスナップショット作成権限セットを共有するアプリケーション管理者のグループです。これにより、ユーザー・グループ内のすべてのユーザーの権限を単一のコマンドで簡単に更新できます。権限は、ユーザー・グループをホストまたはクラスターに関連付けることで実施されます。ユーザー・グループには以下の特性があります。

v グループに割り当てることができるのは、アプリケーション管理者として定義されたユーザーのみです。

v 1 人のユーザーは単一ユーザー・グループのみに所属できます。

v 1 つのユーザー・グループには最大 8 人のユーザーを含めることができます。

v ユーザー・グループが access_all="yes" を指定して定義されている場合、そのグループのメンバーであるアプリケーション管理者はシステム上のすべてのボリュームを管理できます。

ストレージ管理者はユーザー・グループを作成し、アプリケーション管理者のさまざまな権限を制御します。

第 12 章アクセス制御 179

ユーザー・グループとホストの関連ホストとクラスターは、単一ユーザー・グループのみに関連付けることができます。ユーザーがホストに関連付けられているユーザー・グループに属する場合、そのホストにマップされているボリュームのスナップショットを管理できます。ユーザーとホストの関連には以下の特性があります。

v ユーザー・グループはホストとクラスターの両方に関連付けることができます。これにより、アプリケーション管理者のアクセス権限を特定のボリュームに制限できます。

v クラスターに含まれるホストも一緒にユーザー・グループに関連付けることはできません。

v ホストをクラスターに追加する場合、そのホストの関連は解除されます。ホストにマップされているボリュームの管理に関する制限は、クラスターの関連によって制御されます。

v ホストをクラスターから削除すると、そのホストの関連がクラスターの関連になります。これにより命令のマッピングを継続できるため、すべてのスクリプトが引き続き機能します。

ホストのリストコマンド host_list を使用すると、指定したホストに関連付けられているすべてのグループがリストされ、以下のフィールドに関する情報が表示されます。

範囲すべてのホスト、特定のホスト

デフォルトすべてのホスト

クラスターのリストコマンド cluster_list を使用すると、ユーザー・グループに関連付けられているすべてのクラスターがリストされ、以下のフィールドに関する情報が表示されます。

範囲すべてのクラスター、特定のクラスター

デフォルトすべてのクラスター

コマンドの条件アプリケーション管理者は、いくつかの XCLI コマンドのみへのアクセス権限を持っています。

アプリケーション管理者は、一連のコマンドによって特定の操作を実行できます。181ページの表 15 では、アプリケーション管理者が関連付けの定義と適用可能な条件に従って実行することができるさまざまなコマンドをリストしています。

アプリケーション管理者が access_all=yes を指定して定義されたグループのメンバーである場合、すべてのボリュームでそのコマンドを実行できます。


表 15. アプリケーション管理者のコマンド

関連コマンド条件

cg_snapshot_create このコマンドは、次の条件が満たされる場合、アプリケーション管理者がアクセス可能です。

v 整合性グループの少なくとも 1 つのボリュームが、アプリケーション管理者のユーザー・グループに関連付けられているホストまたはクラスターにマップされている。

map_vol

unmap_vol

アプリケーション管理者はこれらのコマンドを使用して、ボリュームのスナップショットをマップできます。以下の条件を満たしている必要があります。

1. マスター・ボリュームが、そのユーザーを含むユーザー・グループに関連付けられているホストまたはクラスターにマップされている。

vol_lock

snapshot_duplicate

snapshot_delete

snapshot_change_priority

これらのコマンドは、以下の条件が両方とも満たされる場合、アプリケーション管理者がアクセス可能です。


snap_group_lock

snap_group_duplicate

snap_group_delete

snap_group_change_priority

これらのコマンドは、以下の条件が両方とも満たされる場合、アプリケーション管理者がアクセス可能です。

1. 整合性グループの少なくとも 1 つのボリュームが、アプリケーション管理者のユーザー・グループに関連付けられているホストまたはクラスターにマップされている。


snapshot_create このコマンドは、次の条件が満たされる場合、アプリケーション管理者がアクセス可能です。

1. そのボリュームが、そのユーザーを含むユーザー・グループに関連付けられたホストまたはクラスターにマップされている。

2. このコマンドによってスナップショットが上書きされる場合、上書きされるスナップショットは、前にアプリケーション管理者によって作成されたものでなければなりません。

認証方式IBM XIV Storage System では認証にいくつかの方式を提供します。

以下の認証方式が使用可能です。

ネイティブ (デフォルト)IBM XIV Storage System が、サブミットされたユーザー名とパスワードに基づき、これらを IBM XIV Storage System に定義され、保管されているユーザーの資格情報と比較することによって、ユーザーを認証します。


ユーザーは、関連するシステム・アクセス権を指定する IBM XIV Storage

System のユーザー役割と関連付けられている必要があります。

デフォルトではこのモードが設定されます。

LDAP

LDAP ディレクトリーが、LDAP サーバーとの接続に使用される、サブミットされたユーザー名とパスワードに基づいてユーザーを認証します。

事前定義のユーザー認証アドミニストレーターおよび技術員の役割は、認証方式に関係なく常にIBM XIV Storage System によって認証されます。これの役割が LDAP によって認証されることはありません。

ネイティブ認証これは、IBM XIV Storage System 上でのユーザーおよびグループの認証のデフォルト・モードです。

このモードでは、ユーザーおよびグループは、システム上のデータベースに対して認証されます。

ユーザー構成ユーザーの構成時には、以下のオプションを定義する必要があります。

役割システムを操作するときに各ユーザーが保有する役割カテゴリーを指定します。役割カテゴリーは必須です。各役割の説明については、

名前システムへのアクセスが許可されている各ユーザーの名前を指定します。

パスワードユーザーが定義できるパスワードはすべて大文字と小文字が区別されます。パスワードは必須であり、6 から 12 文字の長さにすることができます。大文字または小文字のほかに ~!@#$%^&*()_+-={}|:;<>?,./¥[] の各文字を使用できます。

E メールE メールは、E メール・メッセージによってイベントに関する通知を特定のユーザーに送信する場合に使用します。 E メール・アドレスは標準のアドレス指定手続きに従っている必要があります。 E メールはオプションです。範囲: 任意の正規 E メール・アドレス。

電話番号と市外局番電話番号は、イベントに関する通知を特定のユーザーに送信するためのSMS メッセージの送信に使用します。電話番号と市外局番には、最大 63

桁の数字、ハイフン (-)、およびピリオド (.) を使用できます。範囲: 任意の正規電話番号。デフォルトは N/A

LDAP 認証Lightweight Directory Access Protocol (LDAP) サポートにより、IBM XIV Storage

System は、LDAP リポジトリーを使用してユーザーを認証することができます。

LDAP 認証が使用可能な場合、IBM XIV システムは、IBM XIV Storage System をアクセスする (CLI または GUI を使用して) ユーザーのユーザー名とパスワードを


使用して、指定された LDAP ディレクトリーにログインします。ログインに成功すると、IBM XIV Storage System は、LDAP ディレクトリーに保管されているユーザーの IBM XIV グループ・メンバーシップ・データを取得し、その情報を使用して、ユーザーに IBM XIV 管理役割を関連付けます。

IBM XIV グループ・メンバーシップ・データは、LDAP ディレクトリー上にお客様が定義した事前構成属性内に保管されています。この属性には、IBM XIV 管理役割に関連付けられたストリング値が含まれています。これらの値が LDAP グループ名の場合もありますが、これは IBM XIV Storage System には不要です。属性に含まれる値とそれらに関連付けられる IBM XIV 管理役割もお客様によって定義されます。

サポートされるドメイン

IBM XIV Storage System は、以下のディレクトリーの LDAP 認証をサポートします。

v Microsoft Active Directory

v SUN ディレクトリー

v Open LDAP

LDAP マルチドメインの実装

異なるドメインにまたがる複数の LDAP サーバーをサポートするために、またmemberOf プロパティーを使用するために、IBM XIV Storage System では、ストレージ管理者に対して複数の役割および読み取り専用の役割を割り振ることが可能です。

事前定義の XIV 管理 ID 「admin」と「technician」は LDAP 認証が使用可能であるかどうかにかかわらず、常に IBM XIV ストレージ・システムによって認証されます。

LDAP ディレクトリーとストレージ・システム間の役割分担LDAP とストレージ・システムは、役割および保守されるオブジェクトを分担しています。

IBM XIV システムおよび LDAP ディレクトリーにより保守される役割とデータは次のとおりです。

LDAP ディレクトリー

v 役割 - IBM XIV ユーザーの認証および LDAP 内での IBM XIV 関連グループの割り当て

v 保守 - ユーザー、ユーザー名、パスワード、指定された IBM XIV に関連する LDAP グループ (IBM XIV Storage System に関連付けられている)

IBM XIV Storage System

v 役割 - LDAP グループから IBM XIV 役割へのマッピングによる適切なユーザー役割の決定と IBM XIV ユーザー・システムへのアクセスの実施

v 保守 - LDAP グループから IBM XIV 役割へのマッピング


LDAP 認証プロセスLDAP 認証プロセスは、いくつかの重要なステップから構成されます。

LDAP 認証を使用するには、以下の主要ステップを実行してください。

1. LDAP サーバーおよびシステム・パラメーターを定義します。

2. この LDAP サーバー上で XIV ユーザーを定義します。ストレージ・システムは、認証されたユーザーを検索する際に、このユーザーを使用します。この後、このユーザーは、システムの構成サービス・アカウントとして参照されます。

3. IBM XIV ユーザー役割に関連付けられた値を保管する LDAP 属性を指定します。

4. LDAP 属性に保管された値と IBM XIV ユーザー役割の間のマッピングを定義します。

5. LDAP 認証を使用可能にします。

LDAP が構成され使用可能にされると、事前定義されたユーザーには、IBM XIV

Storage System 自体ではなく LDAP サーバーが認証したログイン資格情報が付与されます。

認証のテスト

ストレージ管理者は、LDAP 構成を活動化する前に、それをテストすることができます。この章の後で、ldap_test コマンドを検索してください。

LDAP 構成シナリオLDAP 構成シナリオにより、ストレージ管理者は LDAP 認証を使用可能にすることができます。

LDAP 構成シナリオの概要を以下に示します。

図 54. 指定された LDAP ディレクトリーへの XIV ログオン


1. ストレージ管理者が IBM XIV ストレージ・システムに対して LDAP サーバーを定義します。

2. ストレージ管理者が LDAP ベースの DN、通信、およびタイムアウトに関するパラメーターを IBM XIV ストレージ・システムに対して定義します。

3. ストレージ管理者が LDAP グループと XIV ストレージ・アドミニストレーター役割間の関連付けを保管するために使用される LDAP XIV グループ属性を定義します。これは、ldap_config_set コマンドを使用する storage administrator

と readonly の役割です。

4. ストレージ管理者が user_group_create コマンドを使用して、LDAP グループ名と IBM XIV アプリケーションのアドミニストレーター役割間のマッピングを定義します。

5. ストレージ管理者が LDAP 認証を使用可能にします。

LDAP ログイン・シナリオIBM XIV Storage System 内から LDAP にログインします。

LDAP 認証ログインのシナリオは次のように進められます。

開始

GUI から開始される場合

1. ユーザーは IBM XIV Storage System GUI を起動します。

2. IBM XIV Storage System はユーザーにログイン画面を表示します。

3. ユーザーは、必要なユーザー資格情報 (例えば、ユーザー名とパスワード) をサブミットしてログインします。

CLI から開始される場合

1. ユーザーは、ユーザー資格情報 (ユーザー名とパスワード) を指定して CLI にログインします。

認証

1. IBM XIV Storage System は、ユーザーからサブミットされた資格情報を使用して、LDAP ディレクトリーにログインを試みます。

2. ログインに失敗した場合:

v IBM XIV Storage System は、次の LDAP サーバーにログインを試みます。

v すべてのサーバーにおいて再度のログインが失敗した場合、該当するエラー・メッセージがユーザーに返されます。

3. ログインに成功した場合、IBM XIV Storage System は、ログインしたユーザーに関連する属性を LDAP ディレクトリーで検索して、そのユーザーに該当する IBM XIV 役割を決定します。これらの属性は事前に IBM

XIV から LDAP へのマッピングで指定されています。

v IBM XIV Storage System は、ユーザー役割が CLI の発行を許可されているかどうかを検査します。

v ユーザー役割が CLI の発行を許可されている場合は、システムに対してそれを発行し、該当する応答がユーザーに返されます。


v ユーザー役割が CLI の発行を許可されていない場合、IBM XIV

Storage System は、ユーザーにエラー・メッセージを送信します。

サポートされるユーザー名の文字

ログイン・メカニズムでは、@、*、および ¥ を含むすべての文字がサポートされ、以下のフォーマットの名前が使用できます。

v UPN: name@domain

v NT ドメイン: domain¥name

間接的に関連付けられたグループ内の検索:

IBM XIV Storage System は、ユーザーの検索の他に、間接的に関連付けられたアクティブ・ディレクトリー・グループを検索することもできます。

間接的に関連付けられたアクティブ・ディレクトリー・グループの検索は、上記のユーザーの検索とは別に実行されます。この間接的に関連付けられたグループの検索は、memberof グループ属性を使用して、次のようなフローで進められます。

注: この検索は、ユーザーの検証照会で間接的に関連付けられたグループすべてを取得するので、SUN ディレクトリーには適用されません。

IBM XIV Storage System によるグループ・メンバーシップの検索は、ユーザーが直接関連付けられているグループから開始して、その後、他のグループへと広がっていきます。これらのグループそれぞれの中で memberof 属性が検索されます。この検索は、以下の停止基準のいずれか 1 つに一致するまで進められます。

検出時に停止

v 構成済み LDAP 規則のいずれかに一致するグループ・メンバーシップが検出されました。

v 検索コマンドは、グループが検出された時に検索が停止するように設定されています。

検出時に停止しない

v 構成済み LDAP 規則のいずれかに一致するグループ・メンバーシップが検出されました。

v 検索コマンドは、グループ・メンバーシップが検出されても検索を停止しません。次のグループで続行するように設定されています。

v 検索コマンドは、検索限界に達した時に停止するように設定されています(下記の『限界に到達』を参照)。

複数検出

v 構成済み LDAP 規則のいずれかに一致するグループ・メンバーシップが複数検出されました。

– 各一致は、複数回検出された場合 (複数の分岐から検出に達した場合)

でも 1 とカウントされます。

– 検索では、前に他の分岐からチェックされたグループの検査も回避しません。


限界に到達以下のいずれかの限界に一致しました (限界は、検索コマンドの一部として設定されます)。

v 検索が検索の深さの限界に達しました。この検索属性は、グループ・ツリー内での検索操作の広がりを制限します。

v 検索が照会の最大数の限界に達しました。

ユーザー検証ユーザーは LDAP に対して検証されます。

ログイン中に、システムは以下のようにしてユーザーの検証を行います。

ユーザー検索の発行システムは、ユーザーが入力したユーザー名に対する LDAP 検索を発行します。

この要求は、システムの構成済みサービス・アカウントの代わりにサブミットされ、XIV LDAP 構成に指定された LDAP サーバー、基本 DN、および参照属性に対する検索が実施されます。

XIV LDAP 構成に指定された基本 DN は、検索の参照開始点として働き、LDAP に対して、サブミットされた値 (ユーザー名) を指定された属性 (値は user_name_attrib に指定されます) 内で見つけるよう指示します。

1 ユーザーが検出された場合 - XIV 役割検索の発行システムは、2 回目の検索要求を発行し (今回はユーザーの代わりで、ユーザーの資格情報を指定して)、XIV LDAP 構成の設定(xiv_group_attrib パラメーターに指定された) に基づいて、ユーザーに関連付けられた XIV の役割を検索します。

1 つの XIV 役割が検出された場合 - 権限の付与システムは、役割に関連付けられた権限を検査して、ユーザ

図 55. システムが LDAP 検索を発行してユーザーを検証する方法


ーのログインを認可します。ユーザーの認可は、XIV LDAP

構成に基づき、XIV によって関連付けられた役割に対応します。

ユーザーの XIV 役割が見つからない場合、あるいは複数の役割が検出された場合

LDAP からの応答が、ユーザーが XIV 役割に関連付けられていない (対象ユーザーの参照された LDAP 属性にユーザー役割名が見つからない) かユーザーが実際には複数の役割と関連付けられている (複数の役割名が見つかった) ことを示す場合、ログインは失敗し、該当するメッセージがユーザーに返されます。

該当するユーザーが見つからないか複数のユーザーが見つかった場合LDAP がレコードを返さない (指定されたユーザー名のユーザーが見つからないことを示す) か複数のレコード (サブミットされたユーザー名が固有でない) を返す場合、ログイン要求は失敗し、該当するメッセージがユーザーに返されます。

LDAP 照会に対する IBM XIV サービス・アカウントの設定IBM XIV Storage System は、サービス・アカウントにより LDAP 検索を実施します。このサービス・アカウントは、ldap_config_set コマンドを使用して設定されます (ここ 189ページの『アクセス制御コマンド』を参照)。

LDAP 認証方式とネイティブ認証方式の切り替えこのセクションでは、LDAP 認証とネイティブ認証を切り替える際のシステムの動作を説明します。

認証方式をネイティブから LDAP に変更した後

システムは、ローカルの IBM XIV Storage System ユーザー・データベースではなく、LDAP サーバーに対して「admin」または「technician」以外のユーザーの認証を開始します。ただし、ローカル・ユーザーのアカウント・データは削除されません。

v LDAP サーバーでアカウントを持たないユーザーは、XIV システムへのアクセスを認可されません。

v LDAP ディレクトリー上の XIV 役割に関連付けられていない LDAP アカウントを持つユーザーは、XIV システムへのアクセスを認可されません。

v LDAP ディレクトリー上の XIV 役割に関連付けられている LDAP アカウントを持つユーザーは、以下の条件が満たされれば XIV システムへのアクセスを認可されます。

– LDAP 上の XIV 役割が XIV システム上の有効な XIV 役割にマップされている

– そのユーザーが LDAP 上の 1 つの XIV 役割のみに関連付けられている

ユーザー・アカウントの管理に関連する以下のコマンドは使用不可になります。これらの操作は LDAP ディレクトリーで実行する必要があります。

v user_define

v user_rename


v user_update

v user_group_add_user

v user_group_remove_user

注: ユーザー・グループを削除する際には、そのユーザー・グループの LDAP 役割にユーザーがまったく含まれていない場合でも、以下の完了コードが示されることがあります。

>> user_group_delete user_group=Appadmincommand 0:administrator:

command:code = "ARE_YOU_SURE_YOU_WANT_TO_DELETE_LDAP_USER_GROUP"status = "3"status_str = "One or more LDAP users might be associated to user group.

Are you sure you want to delete this user group?"warning = "yes"

aserver = "DELIVERY_SUCCESSFUL"

これは、LDAP モードのアクティベーションより前にユーザーが指定の user_group

に関連付けられていた場合に発生することがあります。

認証方式を LDAP からネイティブに変更した後

システムは、ローカルで定義された IBM XIV ユーザー・データベースに対してユーザーの認証を開始します。ネイティブ認証から LDAP 認証への切り替え前に定義されていたユーザーとグループは再び有効になります。 IBM XIV システムはユーザーとグループのローカル管理を許可するようになります。ユーザー・アカウントの管理に関連する以下のコマンドは使用可能になります。

v user_define

v user_rename

v user_update

v user_group_add_user

v user_group_remove_user

ユーザーがシステムにアクセスできるようになるには、そのユーザーを XIV でローカルに定義し、ローカル IBM XIV ユーザー・グループに関連付ける必要があります。

アクセス制御コマンド役割ベースのアクセス制御 (RBAC) の管理には、以下の IBM XIV コマンド行インターフェース (XCLI) コマンドを使用できます。これらのコマンドの詳しい説明については、関連する (ご使用のリリース用の)「IBM XIV Storage System XCLI User

Manual」の「アクセス制御」の詳細が記載されている章を参照してください。

ユーザー関連コマンド

役割ベースのアクセス制御の管理には、以下のユーザー関連コマンドを使用できます。

user_define新規ユーザーを定義します。


user_updateユーザーの属性を更新します。

user_listすべてのユーザーまたは特定のユーザーをリストします。

user_renameユーザーの名前を変更します。

user_deleteユーザーを削除します。

ユーザー・グループ関連コマンド

以下のユーザー・グループ関連コマンドを使用して役割ベースのアクセス制御を管理することもできます。

user_group_createユーザー・グループを作成します。

user_group_update

v Lightweight Directory Access Protocol (LDAP) 役割をもつユーザー・グループを割り当てます。

v ユーザー・グループ名を更新します。

user_group_add_userユーザーをユーザー・グループに追加します。

user_group_remove_userユーザーをユーザー・グループから削除します。

user_group_listすべてのユーザー・グループをそのユーザーとともにリストします。

user_group_renameユーザー・グループの名前を変更します。

user_group_deleteユーザー・グループを削除します。

役割ベースのアクセス制御コマンド

役割ベースのアクセス制御の管理に、以下のリストのアクセス関連コマンドを使用できます。

access_defineユーザー・グループをホストおよびクラスターに関連付けます。

access_deleteユーザー・グループが関連付けられているホストおよびクラスターから、そのユーザー・グループの関連付けを解除します。

access_listアクセスの関連をリストします。

構成関連コマンド

以下の LDAP サーバー構成関連コマンドも使用できます。


ldap_config_setLDAP 構成パラメーターをセットアップします。

ldap_config_getストレージ・システムで動作する LDAP サーバーの構成属性をリストします。

ldap_mode_setストレージ・システムに対する LDAP 認証を有効/無効にします。

ldap_mode_getストレージ・システムの認証方式 (アクティブ/非アクティブ) を返します。

ldap_user_testこのコマンドは、LDAP マシンでユーザーの資格情報を認証します。

ldap_test活動化の前に LDAP 設定を検証します。

非 LDAP コマンド

以下のコマンドは非 LDAP モードで使用可能であり、LDAP モードでは使用できません。

user_defineXIV システムで新規ユーザーを定義します。

user_updateXIV ユーザーの詳細を変更します。

user_renameXIV ユーザーの名前を変更します。

user_group_add_userXIV アプリケーション管理者ユーザー・グループにユーザーを追加します。

user_group_remove_userXIV アプリケーション管理者ユーザー・グループからユーザーを削除します。

アクセス制御の概念に関する用語集役割ベースのアクセス制御に関する記述全体において、以下の重要な定義が適用されます。

LDAP Lightweight Directory Access Protocol。

LDAP 属性 (LDAP attribute)単一または複数の値を持つ LDAP オブジェクトのプロパティー。 XIV の役割に対応するユーザー・グループ・メンバーシップの値を保持するために、LDAP 管理者によって特殊なオブジェクト属性が指定される。

LDAP 認証 (LDAP authentication)サブミットされたユーザーの資格情報を LDAP ディレクトリーに保管されているデータと照合して検証することによって、ユーザーを認証する方式。


LDAP ディレクトリーLDAP サーバー上に保管され、LDAP 呼び出しによってアクセスされる階層データベース。

LDAP サーバー (LDAP Server)LDAP によってディレクトリー・サービスを提供するサーバー。

LDAP 状況 (LDAP status)LDAP サーバーの状況。

Microsoft Active DirectoryMicrosoft Active Directory は、ディレクトリー (検索) サービス、DNS サービス、および認証サービスを提供する。

XIV マッピング (XIV Mapping)LDAP サーバー上のデータ (特定の LDAP 属性) と XIV 上のデータとの関連付け。これは、認証された LDAP ユーザーに付与するアクセス権限を決定するために必要である。


第 13 章マルチテナンシー

IBM XIV Storage System は、ある管理者が別の管理者に関連付けられたリソースにアクセスできないことを保証して、XIV 所有者がストレージ・リソースを複数の独立した管理者に割り振ることができるようにします。

マルチテナンシーは、IBM XIV Storage System の役割ベースのアクセス制御へのアプローチを拡張します。ユーザーを事前定義された操作および有効範囲 (操作が許可されるアプリケーション) のセットと関連付けるのに加えて、IBM XIV Storage

System では、どの操作が許可されるか、またどの場所で許可されるかを、ユーザーが自由に決定できるようにしています。

マルチテナンシーとはマルチテナンシーの主な概念は、ある管理者が別の管理者に関連付けられたリソースにアクセスできないという保証付きで、XIV システムの所有者がストレージ・リソースを複数の独立した管理者に割り振ることを可能にすることです。

このリソース割り振りは、分かりやすく説明すると、システムのリソースを個別の管理可能ドメインに区分化することです。ドメインとは、システムのリソースのサブセット、つまり区分です。これは、ユーザー、プール、ホスト/クラスター、ターゲットなどを関連付けることができる、名前付きのオブジェクトです。ドメインは、ユーザーが管理できるリソースを、そのドメインに関連付けられているリソースに制限します。

ドメインは、(マルチテナンシーが非アクティブのときに) 存在するユーザー関係をXIV システム・レベルで維持します。

ドメイン管理者とは、ドメインに関連付けられているユーザーを指します。ドメイン管理者は、特定のドメインに関連付けられたオブジェクトに対する操作を実行することに制限されます。

ドメイン管理者には、以下のアクセス権限および制限が適用されます。

v ユーザーを作成して、役割 (例えば、ストレージ管理者、アプリケーション管理者、読み取り専用) を割り当てます。

v ドメインに割り当てられる際に、ユーザーは自身に与えられた役割を保持しますが、ドメインの有効範囲に制限されます。

v ドメイン内のオブジェクトへのアクセスは、定義されたユーザー役割が指定のドメイン・アクセスと交差するポイントまでに制限されます。

v デフォルトでは、ドメイン管理者は自身のドメインに関連付けられていないオブジェクトにはアクセスできません。

マルチテナンシーには以下の利点があります。

区分化 XIV システムのリソースが個別のドメインに区分化されます。ドメインは


さまざまなテナントに割り当てられ、各テナント管理者は、特定のドメインまたは複数のドメインについて、関連するドメインの境界内でのみ操作を実行する許可を取得します。

自己完結性ドメイン管理者は、すべてのドメイン・リソースを管理するために必要なフルセットの許可を所有します。

分離テナント間に可視性はありません。ドメイン管理者には、ドメイン外部のリソースの情報は提供されません。外部のリソースはリストに表示されず、それに関連したイベントやアラートも表示されません。

ユーザーとドメインの関連ユーザーは、複数のドメインに対してドメイン管理者の役割を持つことができます。

ドメイン管理者以外のユーザーストレージ管理者、セキュリティー管理者、アプリケーション管理者、および読み取り専用ユーザーは、非ドメイン・ベースの環境で持っているものと同じ操作を実行する権限を保持します。同じ制限下で同じオブジェクトにアクセスできます。

グローバル管理者グローバル管理者は、特定のドメインに関連付けられず、ドメイン内でドメイン管理者が実行できる操作を決定します。

これは、ドメインの作成、編集、および削除と、ドメインへのリソースの関連付けができる唯一のユーザーです。

グローバル管理者がドメインの内部を見ることができる、またはできないようにするために、オープン・ポリシーまたはクローズ・ポリシーを定義できます。

システムのグローバル・リソースに対する許可を持つ、グローバル・ドメイン管理者の介入は、以下の場合にのみ必要です。

v ドメインの初期作成およびドメイン管理者の割り当て

v ハードウェア問題の解決

どのドメインにも関連付けられていないユーザーどのドメインにも関連付けられていないユーザーは、ドメインと一意的に関連付けられていないすべてのエンティティー対するアクセス権限を持ちます。


技術概要このセクションでは、マルチテナンシーの概要をグラフィックで表示します。

v ドメインは、ストレージ・リソースの分離されたセットです。

v ドメイン管理者は、指定されたドメインのみへのアクセス権限を持ちます。

v グローバル管理者は、ドメインを管理し、ドメインに管理者を割り当てることができます。

v プライベート・オブジェクトがドメインに割り当てられます。

v ドメインは、ユーザー、ホスト、クラスター、およびターゲットなど、グローバル・オブジェクトへの接続を維持します。ホスト (およびクラスター) は、複数のドメインにサービスできます。ただし、ドメイン管理者が作成したホストは、そのドメインにのみ割り当てられます。

ドメイン A

プール

プール

ドメイン B

プール

プール

プール

ドメイン C

プール

グローバル��

ユーザー

xiv10588

ホスト

第 13 章マルチテナンシー 195

マルチテナンシーの処理このセクションには、マルチテナンシーとその属性の処理に関する一般的な説明を記載します。

ドメイン管理者ドメイン管理者には、以下の属性があります。

v ドメインとの関連付けの前は、将来のドメイン管理者 (現在はシステム管理者) は、すべての非ドメイン・エンティティーに対するアクセス権限を持ち、ドメイン固有のエンティティーに対するアクセス権限は持っていません。

v ストレージ管理者がドメイン管理者になると、非ドメイン・エンティティーに対するすべてのアクセス権限が失われます。

v ドメイン管理者は、ボリュームとホストの両方がそのドメインに属している限り、ボリュームをホストにマップできます。

v ドメイン管理者は、プールがそのドメイン管理者によって管理されるドメインに属している限り、プール間でボリュームのコピーおよび移動を行うことができます。

v ドメイン管理者は、自身のドメイン内のすべてのボリュームのスナップショットを管理できます。

v ドメイン管理者は、自身のドメイン内のすべてのプールの整合性グループおよびスナップショット・グループを管理できます。プール間の整合性グループの移動は、ソース・プールと宛先プールの両方がその管理者のドメイン内にある限り許可されます。

v ドメイン管理者は、自身のドメインに関連付けられたストレージ制約の下で、プールの作成および管理を行えます。

v ハードウェア・リストおよびイベントは、ドメイン管理者が構成することはできませんが、そのドメインの有効範囲内でドメイン管理者に表示専用で提供されます。

v ドメインに関連付けられていないオブジェクトを操作するコマンドには、ドメイン管理者はアクセス不能です。

ドメイン

ドメインには、以下の属性があります。

v 容量 - ドメインは容量で割り振られ、その容量がさらにプール間に割り振られます。ドメインは、以前はシステム・プール・ボリュームと呼ばれ、現在はシステム・ドメイン・プール・ボリュームと呼ばれる階層に、以下のように追加コンテナーを提供します。

– ドメインの未割り振り容量は、そのドメインのプールに予約されます。

– システムのドメインのハード容量の合計は、XIV システムの合計ハード容量を超えることはできません。

– システムのドメインのソフト容量の合計は、XIV システムの合計ソフト容量を超えることはできません。


v ドメイン当たりのボリュームの最大数 - 1 つのドメインが他のドメインを犠牲にしてシステム・リソースのすべてを消費することはできないという方法で、システム当たりのボリュームの最大数がドメイン間で分割されます。

v ドメイン当たりのプールの最大数 - 1 つのドメインが他のドメインを犠牲にしてシステム・リソースのすべてを消費することはできないという方法で、システム当たりのプールの最大数がドメイン間で分割されます。

v ドメイン当たりのミラーの最大数 - システム当たりのミラーの最大数がドメイン間で分割されます。

v ドメイン当たりの整合性グループの最大数 - システム当たりの整合性グループの最大数がドメイン間で分割されます。

v パフォーマンス・クラス - 最大集約帯域幅および IOPS は、システム・レベルではなく、ドメインのすべてのボリュームを対象に計算されます。

v ドメインは、LDAP 認証のために自身を識別するストリングを持っています。

マルチテナンシー環境でのミラーリング

v ターゲット、ターゲット接続、およびインターバル・スケジュールは、ストレージ管理者が定義、編集、および削除します。

v ドメイン管理者は、そのドメインに関連付けられている、以前に定義されたターゲットおよびターゲット接続に基づいて、ミラーリング関係のプロパティーを作成、活動化、および変更できます。

v リモート・ターゲットは、ドメインに属している必要はありません。

v リモート・ターゲットがドメインに属しているときはいつでも、リモート・ターゲット、プール、およびボリューム (ミラーの作成時に指定された場合) のすべてが同じドメインに属しているか検査されます。

GUI からのマルチテナンシーの操作GUI からマルチテナンシーを操作する方法についての説明は、他の XIV 資料に記載されています。

XIV GUI Release Notes「GUI Release Notes」には、主要な画面を含め、GUI の観点からのマルチテナンシー機能に関する簡略説明が記載されています。

Management Tools Operations Guideドメイン・ベースのマルチテナンシー機能の説明が記載されている XIV ユーザー・ガイド。

マルチテナンシー XCLI コマンドマルチテナンシーを管理するために、IBM XIV コマンド行インターフェース(XCLI) コマンドが提供されています。

これらのコマンドの詳しい説明については、「IBM XIV Storage System XCLI User

Manual」を参照してください。


ドメイン管理domain_createこのコマンドは、システム内に新規ドメインを作成します。

domain_updateこのコマンドは、1 つ以上のドメイン属性を更新します。

domain_deleteこのコマンドは、ドメインを削除します。

domain_renameこのコマンドは、ドメイン・ネームを変更します。

domain_listこのコマンドは、システム・ドメイン、属性、および関連するエンティティーをリストします。

ドメインへのリソースの関連付けdomain_add_poolこのコマンドは、ストレージ・プールをドメインに関連付けます。

domain_remove_poolこのコマンドは、ドメインからストレージ・プールの関連付けを解除します。

domain_move_poolこのコマンドは、ストレージ・プールを 1 つのドメインから別のドメインに移動します。

domain_attach_objectこのコマンドは、オブジェクトをドメインに接続します。オブジェクトは、ターゲット、ホスト、クラスター、またはスケジュールのいずれかです。

domain_detach_objectこのコマンドは、ドメインからオブジェクトを切り離します。

domain_list_objectsこのコマンドは、ドメインに接続されているオブジェクトをリストします。

ドメインへのユーザーの関連付けdomain_add_userこのコマンドは、ユーザーをドメインに追加します。

LDAP ユーザーは、user_define コマンドを使用してドメインに追加されます。

domain_remove_userこのコマンドは、ドメインからユーザーを削除します。

domain_list_usersこのコマンドは、ドメインに追加されているユーザーをリストします。

ドメイン・ポリシーdomain_access_policy_setこのコマンドは、ドメイン管理者がドメイン固有のリソースにアクセスできるかどうかを判別します。


domain_access_policy_getこのコマンドは、現行のポリシー設定を返します。


第 14 章 VMware Virtual Volumes と XIV

XIV が VMware Virtual Volumes (VVol) 対応になりました。VMware Virtual

Volumes (VVol) は、VMware vSphere に今後搭載される機能であり、新しいストレージ・アーキテクチャーに基づいて、1 つの VM を複数の LUN に関連付けます。

VVol を使用すると、VMware vCenter (Web Client) の管理者は、VM 単位のスナップショット生成およびクローン作成を IBM ストレージにオフロードし、ワークロード認識型のポリシーにより IBM ストレージのプロビジョニングを自動化し、IBM

ストレージのスナップショットに基づいて VM 単位のバックアップおよびインプレースのリストアを適用することができます。IBM ストレージの管理者は、ワークロード固有のストレージ・サービスを定義して vCenter に公開できます。そして管理にかかる労力が軽減され、ボリューム・ライフサイクルの管理が完全に自動化されます。また VVol には融通性があり、ストレージ管理者は、データ・ストアに大きな容量を事前に割り振る必要がありません。代わりに、ストレージの割り振り(および再利用) は、オンデマンドで適正な量だけ、即座にかつ自動的に行われます。

VMware VVOL の自動化は、VMware vSphere APIs for Storage Awareness (VASA)

に基づいています。IBM Storage Provider for VMware VASA は、IBM Storage

Integration Server の機能であり、XIV と VVol 操作とのオーケストレーションをすべてサポートします。IBM Storage Provider for VMware VASA および IBM Storage

Integration Server について詳しくは、IBM Storage Provider for VMware VASA

(http://www-01.ibm.com/support/knowledgecenter/STJTAG/hsg/hsg_vasa_kcwelcome.html)

および IBM Storage Integration Server (http://www-01.ibm.com/support/

knowledgecenter/STJTAG/hsg/hsg_isis_kcwelcome.html) の資料を参照してください。

VMware Virtual Volumes (VVol) のプレビューを確認するには、http://blogs.vmware.com/vsphere/2012/10/virtual-volumes-vvols-tech-preview-with-

video.html を参照してください。

VVol を操作するための前提条件使用にあたって、VVol の実装には VVol 対応のストレージ・アレイおよび VASA

プロバイダーが必要になります。

v 以下のソフトウェアおよびサーバーのバージョンがインストールされていることを確認してください。

– XIV バージョン 11.5.1 以降

– IBM Storage Integration Server バージョン 2.0 以降 (VASA 2.0 互換)

– VMware vCenter Server および VMware ESX Server

– VMware vSphere Client

v IBM Storage Provider for VASA の実装 (IBM Storage Integration Server に組み込まれています)

v ストレージ統合管理者 (SIA) ユーザーの役割を定義します。


http://www-01.ibm.com/support/knowledgecenter/STJTAG/hsg/hsg_vasa_kcwelcome.html

http://www-01.ibm.com/support/knowledgecenter/STJTAG/hsg/hsg_isis_kcwelcome.html

http://www-01.ibm.com/support/knowledgecenter/STJTAG/hsg/hsg_isis_kcwelcome.html

http://blogs.vmware.com/vsphere/2012/10/virtual-volumes-vvols-tech-preview-with-video.html

http://blogs.vmware.com/vsphere/2012/10/virtual-volumes-vvols-tech-preview-with-video.html

第 15 章非中断コード・ロード

非中断コード・ロード (ホット・アップグレードとも呼ばれます) を使用すると、アプリケーション・サービスを中断せずに、IBM XIV Storage System のソフトウェアを現行のバージョンから新規バージョンにアップグレードすることができます。

アップグレード・プロセスは、すべてのモジュールで並行して進行し、ホスト上のアプリケーション・サービスに支障をきたすことのないように十分な速さで行われるように設計されています。このアップグレードには、データ・マイグレーションも再作成プロセスも必要ありませんが、すべての内部ネットワーク・パスがアクティブになっている必要があります。

非中断コード・ロード・プロセス中には、「アップグレード復帰不能点」と呼ばれる時点があり、これより前であれば、コード・ロード・プロセスをまだ打ち切ることができます (システムにより自動的に、または専用 CLI を介して手動で)。この時点を過ぎると、非中断コード・ロード・プロセスを元に戻すことはできません。

非中断コード・ロードの注目すべき特徴は次のとおりです。

アップグレード・プロセスの期間新規コードをストレージ・システムにダウンロードしてから、その新規コードに移行するまでのすべてのプロセスは、アプリケーション/ホストに対してオンラインで行われます。

アップグレード・プロセスの所要時間は、以下の要因に影響されます。

v アップグレード・プロセスが、すべての入出力を停止するよう要求する。システムに多数の入出力がある場合、あるいは低速ディスクがある場合、システムが十分な速さで入出力を停止できないことがあるため、それらを少し後で再始動し、再試行することになり、数回の再試行を考慮しておくことになります。

v アップグレード・プロセスでは、ソフトウェアの有効なバージョンをインストールしてから、そのローカル構成を保持するようにします。このプロセスは、構成の構造に対する将来の変更に応じて、かなりの時間がかかります。

前提条件および制約

v アップグレード・プロセスは、データ・マイグレーションまたは再作成プロセスがアクティブである場合は実行できません。データ・マイグレーションまたは再作成プロセスのいずれかがアクティブである時にアップグレード・プロセスを開始しようとすると失敗します。

v 一般に、復帰不能点以降に起こる事象は、そのアップグレードの終了以降に発生したかのように処理されます。

v ホット・アップグレード全体が進行中である間は (最大で数分)、すべての管理操作は実行できず (状況照会は例外)、どのイベントも処理されません。

v 復帰不能点より前では、アップグレードを手動で打ち切ることができます。


ミラーリングへの影響アップグレードの前には、ミラーは自動的に非活動化され、アップグレード後に再度活動化されます。

管理操作への影響非中断コード・ロード・プロセス中に、システムにアップグレード状況を照会することができ、「復帰不能点」より前であれば、プロセスを手動で打ち切ることもできます。この時点より前に障害が発生した場合は、プロセスは自動的に打ち切られます。

アップグレード中のモジュールまたはディスク障害の処理復帰不能点より前に障害が発生した場合は、それによってアップグレードが打ち切られます。復帰不能点後に発生した障害は、アップグレード後に発生したものとして処理されます。

アップグレード中の電源障害の処理復帰不能点より前の電源障害については、システムがアップグレードの準備を行う間 (復帰不能点より前)、電源が監視されます。電源障害が検出されると、アップグレードは打ち切られ、古いバージョンで電源障害が処理されます。

コード・ロードの準備IBM XIV Storage System は、アクティブ・ホストを切断したり、入出力操作を停止したりせずに、システム・コードをアップグレードします。

中断を伴わないコード・ロードは、IBM XIV 担当員のみが実行する操作です。本資料には、通常の操作およびアップグレードに適用可能な必須手順および成功事例の手順が含まれています。

アップグレードの準備

コード・ロードの前に、以下の項目を確認して前提条件を満たしてください。

1. マルチパス機能 (オペレーティング・システムにより提供) がホストで動作している。

2. IBM XIV 上にホストから少なくとも 2 つの異なるインターフェース・モジュールへのパスがある。

3. 各ゾーンに 1 つのイニシエーターしかない (IBM XIV に接続されている SAN

ボリューム・コントローラーを除く)。

4. ホストが、xiv_attach ユーティリティーを使用して IBM XIV に接続されている。

v これは必須です。

v これはインストール可能な HAK とポータブルな HAK の両方に適用されます。

v HAK を使用できないサポート対象のプラットフォーム (VMware またはLinux on Power システムなど) は、この前提条件の例外です。

5. 「IBM XIV Host Attachment Kit for Windows」の最小バージョンは 1.5.3 である。このバージョンは、Windows ホストでの潜在的なアクセスの喪失を防ぎます。


6. IBM XIV でリモート・ミラーリングに FC 接続を使用する場合、2 つのシステムが SAN スイッチに接続されている。直接接続はサポートされておらず、問題があると考えられています。

7. ホストが、FC ポートへは FC スイッチを介して、また、iSCSI ポートへはギガビット・イーサネット・スイッチを介して接続されている。ホスト間での直接接続および IBM XIV Storage System への直接接続はサポートされていません。

注意事項:

1. 他のマルチパス・ソフトウェアとの共存は GA ではサポートされていません(RPQ 承認が必要です)。

2. 同一ホストから他のストレージ・サーバーへの接続は GA ではサポートされていません (RPQ 承認が必要です)。

3. アップグレード中、一時的にミラーリングが自動的に中断して再開します。

4. 10.2.4.x から 10.2.1.x 以前のバージョンへのミラーリングはサポートされていません。

5. MS Geo Cluster が関連する場合は、特別な考慮事項があります。詳しくは、IBM サポートにお問い合わせください。

推奨事項:

1. ホストに最新の XIV Host Attachment Kit をインストールすることを強くお勧めします。HAK のリリースごとに、古いバージョンの既知の問題が修正されます。

v 古いレベルを使用することは、既に検出されて修正された問題にさらされることを意味します。

2. IBM XIV のゾーニングに関するベスト・プラクティスを実行することをお勧めします (Redbook および「XIV Host Attachment Guide」を参照)。

3. Service Pack およびストレージ関連のホット・フィックスに関する OS プロバイダーの推奨事項を実行することを強くお勧めします。これらのフィックスは OS

プロバイダーによって随時リリースされ、IBM XIV が管理するものではありません。一部のフィックスは、最新の HAK のリリース・ノートに記載されており、アップグレード前に適用する必要があります。

4. 最新の BIOS および HBA ドライバーを使用してホスト・システムを保持しておくことをお勧めします。

5. ワークロードが比較的小さいときにアップグレードを実行することをお勧めします。

TA サポートの利用

1. ご使用の IBM XIV Storage System に対して TA サービスが利用可能な場合は、コードのアップグレードを計画する際に担当の技術アドバイザーにお問い合わせください。

第 15 章非中断コード・ロード 205

用語集

本書を通じて使用される用語およびその省略語のアルファベット順リストを以下に記載します。

アクティブ・ディレクトリー (Active directory)Microsoft Active Directory (AD) は、ディレクトリー (検索) サービス、DNS サービス、および認証サービスを提供する。

アラート・イベント (Alerting event)そのイベントがクリアされるまで、イベント通知を繰り返し起動するイベント。

API 「アプリケーション・プログラム・インターフェース (API)(Application

program interface (API))」を参照。

アプリケーション・プログラム・インターフェース (API) (Application programinterface (API))

アプリケーションがオペレーティング・システムおよびその他のサービスにアクセスするインターフェース。

許可レベル (Authorization level)許可レベルは、IBM XIV Storage Management GUI の各種関数に対して許可されるアクセス・レベルを決定する。

読み取り専用 (Read only)表示のみが許可される。

フル (Full)システムのシャットダウンも含め、すべての構成機能および制御機能へのアクセスを使用可能にする。このレベルにはパスワードが必要である。

自動削除優先順位 (Auto delete priority)ストレージ容量が限度に到達すると、スペースを増やすためにスナップショットが自動的に削除される。削除は、以下のように、各スナップショットに設定された値に従って実行される。

1 最後に削除する

4 最初に削除する

各スナップショットには、作成時にデフォルトの自動削除優先順位 1 が設定される。

イベントの消去 (Clearing events)アラート・イベントのイベント通知の繰り返しを停止するプロセス。

CLI IBM XIV コマンド行インターフェース (XCLI)。「コマンド・ライン・インターフェース (CLI) (Command line interface (CLI))」を参照。

コマンド・ライン・インターフェース (CLI) (Command line interface (CLI))set コマンドおよび関数を通じてシステムと対話するために使用される非グ


ラフィカル・ユーザー・インターフェース。IBM XIV Storage System のIBM XIV コマンド行インターフェース (XCLI)。

完了コード (Completion code)CLI コマンドの実行結果として返信されるメッセージ。

整合性グループ (Consistency group)特定の複数のボリュームからなるクラスターであり、すべてボリュームのスナップショット、ミラーリング、および管理をグループとして同時に行うことができる。ボリュームは、単一の整合性グループにのみ関連付けることができる。

整合性グループ内のボリュームは、単一ボリューム・セットとしてグループ化される。そのボリューム・セットのスナップショットを取得して、特定の整合性グループの下に複数のスナップショット・セットを作成できる。「スナップショット・セット (Snapshot set)」、「ボリューム・セット (Volume

set)」も参照。

カップリング (Coupling)ミラーリング関係が確立される 2 つのピア (ボリュームまたは整合性グループ)。

データ・モジュール (Data module)データ・ストレージ専用のモジュール。フル構成のラックには、9 つの専用データ・モジュールが入っており、それぞれが 12 台のディスクを備えている。

宛先 (Destination)「イベント宛先 (Event destination)」を参照。

エスカレーション (Escalation)特定の時間内にイベントがクリアされなかったために、イベント通知がより広範なイベント宛先リストへ送信されるプロセス。

イベント宛先 (Event destination)イベント通知を送信するためのアドレス。

イベント通知規則 (Event notification rule)どのユーザーに、どのイベントを、どのような手段で通知するかを決める規則。

イベント通知 (Event notification)イベントについてユーザーに通知するプロセス。

イベント (Event)ログに (適切なメッセージと一緒に) 記録されるユーザーまたはシステム・アクティビティー。

ファブリック (Fabric)ワークステーションおよびサーバーを SAN のストレージ・デバイスに接続するハードウェア。SAN ファブリックは、ファイバー・チャネル・スイッチング・テクノロジーを使用して、任意のサーバーから任意のストレージ・デバイスへの接続を可能にする。


FC-ALアービトレーテッド・ループとも呼ばれる。ファイバー・チャネル・スイッチを必要としないファイバー・チャネル・トポロジー。装置は、片方向ループ方式で接続される。

FC-HBAファイバー・チャネル・ホスト・バス・アダプター。

FC 「ファイバー・チャネル (fibre channel)」を参照。

ファイバー・チャネル (Fibre channel)コンピューターおよび大容量ストレージ・デバイスの製造メーカーの協会によって開発され、現在 ANSI によって標準化されているシリアル・データ転送アーキテクチャー。

機能エリア (Functional area)IBM XIV Storage Management GUI 画面の左側のペインにある高水準アイコン・グループ (機能モジュール) の 1 つ。例えば、「モニター(Monitor)」、「構成 (Configuration)」、または「ボリューム管理 (Volume

management)」など。「機能モジュール (Functional module)」を参照。

機能モジュール (Functional module)IBM XIV Storage Management GUI 画面の左側のペインにある機能エリアのアイコンの 1 つ。例えば、「システム (System)」(「モニター(Monitor)」の下)、または「ホストおよび LUN (Hosts and LUNs)」(「構成(Configuration)」の下)。「機能エリア (Functional area)」を参照。

グラフィカル・ユーザー・インターフェース (GUI) (Graphical user interface(GUI)) マウスとキーボードによってサポートされるスクリーン内のユーザー・イン

ターフェース。

H/W ハードウェア (Hardware)

HBA ホスト・バス・アダプター (Host bus adapter)

ホスト・インターフェース・モジュール (Host interface module)インターフェース・データ・モジュールは、外部ホスト要求に対してデータ保管機能をサービスする。フル構成のラックには 6 つのインターフェース・データ・モジュールがある。

ホスト (Host)ホストはシステムに接続できるホストのポート名のこと。システムはファイバー・チャネルおよび iSCSI ホストをサポートする。

I/O 入出力 (Input/output)

イメージ・スナップショット (Image snapshot)アンロックされたことがないスナップショット。これはコピー元であるマスター・ボリュームの、作成時点での正確なイメージである。「スナップショット (snapshot)」も参照。

インターネット・プロトコル (Internet Protocol)パケット (データグラムとも呼ばれる) のフォーマットとアドレス指定スキームを指定したもの。「伝送制御プロトコル (TCP) (Transmission Control

Protocol (TCP))」も参照。

IOP 1 秒あたりの入出力 (I/O)。

用語集 209

IP 「インターネット・プロトコル (Internet Protocol)」を参照。

iSCSI Internet SCSI。ネットワークを介してデータ・ストレージ・デバイスをリンクし、IP ネットワーク経由で SCSI コマンドを伝送することによりデータを転送する、IP ベースの規格。

待ち時間 (Latency)命令が発行された瞬間から、それがコミットされる瞬間までの遅延時間。

LDAP Lightweight Directory Access Protocol。

LDAP 属性 (LDAP attribute)LDAP ディレクトリー・データ・モデル内で定義される属性。

LDAP 認証 (LDAP authentication)サブミットされたユーザーの資格情報を LDAP ディレクトリーに保管されているデータと照合して検証することによって、ユーザーを認証する方式。

LDAP ディレクトリー (LDAP directory)LDAP サーバー上に保管され、LDAP 呼び出しによってアクセスされる階層データベース。

LDAP サーバー (LDAP server)LDAP によってディレクトリー・サービスを提供するサーバー。

LDAP 状況 (LDAP status)LDAP サーバーの状況。

ロード・バランシング (Load balancing)システムのすべてのコンポーネントにまたがった均等な負荷の配分。

ロック (Locking)ボリューム (またはスナップショット) を書き込み不可 (読み取り専用)として設定すること。

LUN マップ (LUN map)ボリュームから LUN へのマッピングを示したテーブル。

LUN 論理装置番号 (Logical unit number)。システム・ボリュームを登録済みホストにエクスポートする。

マスター・ボリューム (Master volume)スナップショットを持つボリュームは、そのスナップショットのマスター・ボリュームと呼ばれる。

MIB 管理情報ベース (Management information base)。ネットワーク管理システムがモニターできるオブジェクトのデータベース。SNMP マネージャーは、標準化された MIB フォーマットを使用して SNMP エージェントをモニターする。

Microsoft Active directory「アクティブ・ディレクトリー (Active directory)」を参照。

ミラー・ピア (Mirror peer)指定されたソース・ピア・データのレプリカとなるように設計されるピア(ボリュームまたは整合性グループ)。

ミラーリング (Mirroring)「リモート・ミラーリング (Remote mirroring)」を参照。


変更された状態 (Modified State)スナップショット状態の 1 つ。変更された状態のスナップショットは、マスター・ボリュームのリストアには使用できない。

マルチパス (Multipathing)ホスト・インターフェース・モジュールが任意のボリュームに直接アクセスできるようにする。

ピア (Peer)カップリングを構成する一方の要素を表す。カップリングが定義される場合、それぞれのピアが指定され、一方のピアが 1 次ピア、他方のピアが 2

次ピアとして指定される。

プール (Pool)「ストレージ・プール (Storage pool)」を参照。

1 次ピア (Primary peer)データがバックアップ用にリモート・ストレージ・システムにミラーリングされているピア。

ラック (Rack)システムのすべてのハードウェア・コンポーネントを格納するキャビネット。

リモート・ミラーリング (Remote mirroring)指定されたミラー・ピアに対して、ソース・ピア (ボリュームまたは整合性グループ) の内容のレプリカを生成するプロセス。

リモート・ターゲット接続 (Remote target connectivity)リモート・ターゲットのポート・セットと、ローカル・ストレージ・システム上のモジュールとの間に接続を定義すること。

リモート・ターゲット (Remote target)ミラーリングやデータ・マイグレーションなどに使用されるリモート・サイト上のストレージ・システム。

役割 (Role)特定の状態 (マスターかスレーブ) の結果としてピアが果たす実際の役割を示す。

規則 (Rule)「イベント通知規則 (Event notification rule)」を参照。

SAN ストレージ・エリア・ネットワーク (Storage area network)

SCSI Small computer system interface。

2 次ピア (Secondary peer)1 次ピアのバックアップとしてサービスするピア。

SMS ゲートウェイ (SMS gateway)SMS を送信するために使用される外部サーバー。

SMTP ゲートウェイ (SMTP gateway)SMTP プロトコルによって E メール・メッセージを中継するために使用される外部ホスト。

用語集 211

スナップショット・セット (Snapshot set)整合性グループ内のボリューム・セットの同期スナップショットからなる結果セット。「整合性グループ (Consistency group)」、「ボリューム・セット(Volume set)」も参照。

スナップショット (Snapshot)あるボリュームの特定時点におけるスナップショットまたはコピー。「イメージ・スナップショット (Image snapshot)」も参照。

SNMP エージェント (SNMP agent)SNMP プロトコルを通じて SNMP マネージャーに情報を報告する装置。

SNMP マネージャー (SNMP manager)SNMP エージェントから SNMP プロトコルを通じて情報を収集するホスト。

SNMP トラップ (SNMP trap)SNMP エージェントから SNMP マネージャーへ送信される SNMP メッセージ。ただし、その送信は SNMP マネージャーから送信されたメッセージへの応答としてではなく、SNMP エージェントによって開始される。

SNMP Simple Network Monitor Protocol。ネットワーク装置をモニターするためのプロトコル。「MIB」、「SNMP エージェント (SNMP agent)」、「SNMP

マネージャー (SNMP manager)」、「SNMP トラップ (SNMP trap)」も参照。

スヌーズ (Snooze)繰り返し発生するイベント通知を、そのイベントがクリアされるまで送信するプロセス。

ストレージ・プール (Storage pool)ボリュームのストレージ要件にサービスする、仮想ディスク・スペースの予約済み領域。

同期ベスト・エフォート・モード (Sync best effort mode)1 次ボリュームと 2 次のボリュームの間で通信が失敗したときでも、入出力操作が中断状態にならないリモート・ミラーリングのモード。

同期化 (Synchronization)通信のダウン時間の後、またはミラーリングの初期化時に、1 次ボリュームと 2 次ボリュームを同一にするプロセス。

ターゲット (Target)「リモート・ターゲット (Remote target)」を参照。

TCP/IP「伝送制御プロトコル (Transmission Control Protocol)」、「インターネット・プロトコル (Internet Protocol)」を参照。

シン・プロビジョニング (Thin provisioning)シン・プロビジョニングは、システムにインストールされている物理容量よりもはるかに大きい論理ボリューム・サイズを定義できる機能を提供する。


伝送制御プロトコル (Transmission Control Protocol)インターネット・プロトコル (IP) の上部にある伝送制御プロトコル (TCP)

は、宛先とソースの間に、データ・ストリームを交換できる仮想接続を確立する。「IP」も参照。

トラップ (Trap)「SNMP トラップ (SNMP trap)」を参照。

無関連ボリューム (Unassociated volume)整合性グループに関連付けられていないボリューム。「整合性グループ(Consistency group)」を参照。

無停電電源装置 (Uninterruptible power supply)無停電電源装置は、一定の期間、バッテリー・バックアップ電源を提供し、特に、長時間の電源異常が発生したときに、制御された方法でシステムの電源遮断を行うことができるようにする。

ボリューム・クローン作成 (Volume cloning)ボリュームからスナップショットを作成すること。

ボリューム・セット (Volume set)整合性グループ内の複数の特定ボリュームからなるクラスター。これらすべてのスナップショットを同時に取得できるため、すべてのボリュームの同期がとれたスナップショットを作成できる。そのボリューム・セットのスナップショットを取得して、特定の整合性グループの複数のスナップショット・セットを作成できる。「スナップショット・セット (Snapshot set)」、「ボリューム・セット (Volume set)」も参照。

ボリューム (Volume)ボリューム・ラベルや入出力制御などの、何らかの形式の ID やパラメーター・リストをサポートする、ディスク、テープ、またはその他のデータ記録メディア上の個別のストレージ単位。

ボリュームは論理アドレス・スペースであり、そのデータ内容はシステム・ディスク・ドライブ上に保管される。ボリュームは、すべてのボリュームの合計割り振りストレージ・スペースがシステムの正味容量を超えない限り、仮想的に任意のサイズにすることができる。ボリュームは、接続したホストに LUN を通じてエクスポートできる。ボリュームは、同時に複数のホストへエクスポートできる。「ストレージ・プール (Storage pool)」、「無関連ボリューム (Unassociated volume)」も参照。

WWPNワールド・ワイド・ポート名 (World Wide Port Name)

XCLI IBM XIV コマンド行インターフェース (XCLI) コマンド・セット。「コマンド・ライン・インターフェース (CLI) (Command line interface (CLI))」を参照。

XDRP IBM XIV 用の災害時回復プログラム - IBM XIV のリモート・ミラー・フィーチャー。

XIV-LDAP マッピング (XIV-LDAP mapping)LDAP サーバー上のデータ (特定の LDAP 属性) と IBM XIV 上のデータとの関連付け。これは、認証された LDAP ユーザーに付与すべきアクセス権限を決定するために必要である。

用語集 213

特記事項

本書は米国 IBM が提供する製品およびサービスについて作成したものです。

本書に記載の製品、サービス、または機能が日本においては提供されていない場合があります。日本で利用可能な製品、サービス、および機能については、日本 IBM

の営業担当員にお尋ねください。本書で IBM 製品、プログラム、またはサービスに言及していても、その IBM 製品、プログラム、またはサービスのみが使用可能であることを意味するものではありません。これらに代えて、IBM の知的所有権を侵害することのない、機能的に同等の製品、プログラム、またはサービスを使用することができます。ただし、IBM 以外の製品とプログラムの操作またはサービスの評価および検証は、お客様の責任で行っていただきます。

IBM は、本書に記載されている内容に関して特許権 (特許出願中のものを含む) を保有している場合があります。本書の提供は、お客様にこれらの特許権について実施権を許諾することを意味するものではありません。実施権についてのお問い合わせは、書面にて下記宛先にお送りください。

〒103-8510

東京都中央区日本橋箱崎町19番21号日本アイ・ビー・エム株式会社法務・知的財産知的財産権ライセンス渉外

以下の保証は、国または地域の法律に沿わない場合は、適用されません。 IBM およびその直接または間接の子会社は、本書を特定物として現存するままの状態で提供し、商品性の保証、特定目的適合性の保証および法律上の瑕疵担保責任を含むすべての明示もしくは黙示の保証責任を負わないものとします。国または地域によっては、法律の強行規定により、保証責任の制限が禁じられる場合、強行規定の制限を受けるものとします。

この情報には、技術的に不適切な記述や誤植を含む場合があります。本書は定期的に見直され、必要な変更は本書の次版に組み込まれます。 IBM は予告なしに、随時、この文書に記載されている製品またはプログラムに対して、改良または変更を行うことがあります。

本書において IBM 以外の Web サイトに言及している場合がありますが、便宜のため記載しただけであり、決してそれらの Web サイトを推奨するものではありません。それらの Web サイトにある資料は、この IBM 製品の資料の一部ではありません。それらの Web サイトは、お客様の責任でご使用ください。

IBM は、お客様が提供するいかなる情報も、お客様に対してなんら義務も負うことのない、自ら適切と信ずる方法で、使用もしくは配布することができるものとします。


本プログラムのライセンス保持者で、(i) 独自に作成したプログラムとその他のプログラム (本プログラムを含む) との間での情報交換、および (ii) 交換された情報の相互利用を可能にすることを目的として、本プログラムに関する情報を必要とする方は、下記に連絡してください。

IBM Corporation

Almaden Research

650 Harry Road

Bldg 80, D3-304, Department 277

San Jose, CA 95120-6099

U.S.A.

本プログラムに関する上記の情報は、適切な使用条件の下で使用することができますが、有償の場合もあります。

本書で説明されているライセンス・プログラムまたはその他のライセンス資料は、IBM 所定のプログラム契約の契約条項、IBM プログラムのご使用条件、またはそれと同等の条項に基づいて、IBM より提供されます。

この文書に含まれるいかなるパフォーマンス・データも、管理環境下で決定されたものです。そのため、他の操作環境で得られた結果は、異なる可能性があります。一部の測定が、開発レベルのシステムで行われた可能性がありますが、その測定値が、一般に利用可能なシステムのものと同じである保証はありません。さらに、一部の測定値が、推定値である可能性があります。実際の結果は、異なる可能性があります。お客様は、お客様の特定の環境に適したデータを確かめる必要があります。

IBM 以外の製品に関する情報は、その製品の供給者、出版物、もしくはその他の公に利用可能なソースから入手したものです。IBM は、それらの製品のテストは行っておりません。したがって、他社製品に関する実行性、互換性、またはその他の要求については確証できません。 IBM 以外の製品の性能に関する質問は、それらの製品の供給者にお願いします。

IBM の将来の方向または意向に関する記述については、予告なしに変更または撤回される場合があり、単に目標を示しているものです。

本書はプランニング目的としてのみ記述されています。記述内容は製品が使用可能になる前に変更になる場合があります。

本書には、日常の業務処理で用いられるデータや報告書の例が含まれています。より具体性を与えるために、それらの例には、個人、企業、ブランド、あるいは製品などの名前が含まれている場合があります。これらの名称はすべて架空のものであり、名称や住所が類似する企業が実在しているとしても、それは偶然にすぎません。

この情報をソフトコピーでご覧になっている場合は、写真やカラーの図表は表示されない場合があります。


商標IBM、IBM ロゴ、および ibm.com® は、世界の多くの国で登録された International

Business Machines Corp. の商標です。他の製品名およびサービス名等は、それぞれIBM または各社の商標である場合があります。現時点での IBM の商標リストについては、著作権および商標の情報 Web サイト (www.ibm.com/legal/copytrade.shtml)

の「Copyright and trademark information」をご覧ください。

Microsoft は、Microsoft Corporation の米国およびその他の国における商標です。

特記事項 217

http://www.ibm.com/legal/copytrade.shtml

索引日本語, 数字, 英字, 特殊文字の順に配列されています。なお, 濁音と半濁音は清音と同等に扱われています。

［ア行］アクセス制御 177

コマンド 189

アクティブ活動化状態 107, 108

アクティブ・ディレクトリー 186

アクティブ・モード 61

アップグレード可能性 11

宛先 123, 142

定義 173

E メール 173

SMS 173

宛先 (destination)

同期 141

IBM Hyper-Scale 143

宛先グループ 173

アトミック・テストおよび設定 24

アプリケーション管理者 177, 179

コマンドの条件 180

access_all 180

アラーム通知 9

アルゴリズム 6, 9

イーサネット10GB 5

イーサネット接続 13

イーサネット・ポート 13

管理ポート 13

フィールド技術員用ポート 13

iSCSI サービス・ポート 13

意図的でない役割変更/間違った役割変更113

イニシエーターiSCSI 19

イベント情報 171

処理 171

通知規則 172

表示 172

イベント通知 9

イメージ・スナップショット複製 37

因果関係IBM Hyper-Scale Mobility のフェーズ、状態、および操作状況 143

インストールSSD の 8

インターフェースコール・ホーム 26

サポートされる 4

エラーリンク状態 107, 108

エラー・コード保護 7

オーバープロビジョン 141

オプション管理 6

オフライン初期化 55, 85, 86

オフラインのデータ・マイグレーション141

オンシステム状態 166

オンライン・ボリューム・モビリティー142

［カ行］外部最終整合スナップショット 67

外部接続輻輳 17

外部レプリカ生成メカニズム 9

解放ストレージ・スペース 55

書き込みの宛先変更ミラーリングのコンテキスト内 81

鍵サーバーのアクセス不能性 165

鍵サーバーへの接続 166

拡張スナップショット・メカニズム 31

拡張ホスト接続 18

確認応答 85

活動化IBM Hyper-Scale Mobility 関係 151,

155, 157

カップリング 80

活動化 61

最終整合スナップショット 67

最終整合スナップショットのタイム・スタンプ 69

状態 65, 107, 108

制約と制限 67

タイプ 61

定義 59

非コミット・データ 67

モード 61

間接的に関連付けられたグループLDAP ユーザーの 186

完全コピー 23

管理アクセス制御 177

管理オプション 6

管理者 193, 195, 196

管理接続 15

完了後IBM Hyper-Scale Mobility 141

関連ユーザー・グループとホスト 180

ギガビット・イーサネット 4

技術員 55, 179

既存のミラーリング定義 127

キャッシュ 8

保護 7

キャッシュとしてのフラッシュ 8

キャッシュ・メモリー 2

キャッシュ・モジュール 2

許可のセット 193

切り替え 70

切り離されたメディア 165

区分化ドメイン・ベースのマルチテナンシーでの 193

クラスター化ホスト 20

クリーンアップIBM Hyper-Scale Mobility 141

クリックして受諾 43

グループ、宛先 173

グループの速度制限 25

グローバル・スペア・ストレージ 6

訓練防火 136, 139

ゲートウェイ定義 174

E メール (SMTP) 174

E メールから SMS への 174

ゲートウェイの定義 174

計画IBM Hyper-Scale Mobility 141

計画外のサービス中断 113, 115

計画されたサービス中断 113, 117

計画のまとめ 146

継続的なデータ保護 32

継続的なバックアップ 31, 35

消し込み 6

検索フロー間接的に関連付けられたグループの

186

検出時に停止停止基準 186


検出時に停止しない停止基準 186

コード・ロード 204

コール・ホームコンタクト・リスト 26

コール・ホーム接続 4

構成 184

マルチ・ラック 9

構成ガイドラインの要約 17

構成済み同期速度 17

高速コピー 25

コピー・オン・ライト (COW) 32, 35

コマンドホスト接続 23, 26

コンタクト・リストコール・ホーム 26

コンポーネント冗長性 6

コンポーネント、ハードウェア 2

［サ行］サービス中断テスト 118

災害時回復 57, 77, 113

災害時回復タイプ 57, 58

災害復旧シナリオ 124

最後の A-B 同期ジョブ 128, 135, 136,

137, 139

最終 2 次タイム・スタンプ 64

最終整合スナップショット 67

最終複製スナップショット削除優先順位 95

最新のスナップショット 128, 135, 136,

139

最大同期速度 17

再同期 67

作成整合性グループ 45

差分同期ジョブによって送信されるデータ

86

差分の計算 85

自己完結性ドメイン・ベースのマルチテナンシーでの 193

自己修復メカニズム 7

自己修復メカニズム 6

システムハード・サイズおよびソフト・サイズ

52

システム A に障害が起こる 128, 135,

136, 137, 139

システム接続参照: ホスト・システム接続 18

システム接続 (続き)

「ホスト・システム接続 (host system

attachment)」を参照。 17, 18

システム・キャパシティー 55

システム・リソース 193

事前定義ユーザー 179

認証 181

実装LDAP の 182

自動障害からのリカバリー 7

自動イベント通知 9

自動削除優先順位 34

手動再活動化ミラー・プロセスの 97

手動削除最終整合スナップショットの 67

準備コード・ロードの 204

仕様 81

照会の最大数検索限界として 186

使用可能な整合コピーミラーリング中 95

状態カップリング 65

IBM Hyper-Scale 143

冗長コンポーネント 6

冗長性 6

初期化 85

初期化とは区別すべき 97

同期状況 63

非同期ミラーリングの最初のフェーズ100, 101, 102, 103, 104, 105, 106

初期化タイプ 85, 86

初期化中IBM Hyper-Scale Mobility ソースの状態 143

初期化の 85

診断 9

信頼性 6

シン・プロビジョニング (thin

provisioning) 9, 52

ミラーリング 94

スケジューリング非同期ミラーリング 87

スタンバイ活動化状態 107, 108

スタンバイ・ミラー 123

スタンバイ・モード 61

ステージIBM Hyper-Scale 143

ストレージグローバル・スペア 6

ストレージ、セキュリティー、およびアプリケーションの管理者と読み取り専用ユーザードメイン・ベースのマルチテナンシーでの 193

ストレージ管理者 17, 179

ストレージ・プール 9

概要 51, 52

ハード容量の枯渇 52

ハード・サイズおよびソフト・サイズ52, 55

ボリュームの移動 51, 52


ストレージ・ユニット 141, 142

スナップショット 29, 31, 32, 35, 37, 38

アトミック・プロシージャー、作成の37

関連 35

自動削除優先順位 34

シリアル番号 35

ストレージ使用率 34

名前 35

ハード容量の枯渇 52

フォーマット 41

復元 38

複製 37

保護された 94

無保護 (削除からの) 97

ロックとアンロック 37

スナップショット ID 41

スナップショット、概要 29

スナップショット管理 9

スナップショット作成 31, 35

スナップショット管理 9

整合性グループ 9

スナップショット作成中 32

スナップショットの削除プール枯渇プロセスの一環として 82,

94, 97

スナップショット・アーキテクチャーミラーリングのコンテキスト内 81

スナップショット・グループ 46, 47, 49

フォーマット 41

スナップショット・ポリシー確立、後

IBM Hyper-Scale Mobility 141

スペア・ストレージ 6

スレーブ 80

プロモート、フェイルオーバー時の115

役割のタイプ 107

スレーブ LRS 95

スレーブ・レプリカ不整合 90

制限ホストの速度 25


制限された接頭部スナップショット・グループへの 47

整合 (Consistent)

IBM Hyper-Scale Mobility 宛先の状態143

整合性グループ 9, 49

およびリモート・ミラーリング 74

概要 45

作成 45

スナップショット 46, 47

復元 45, 49


ミラーリング関連タスク 93

セキュリティー管理者 166

セキュリティー管理者間でのリカバリー・キーの分配 166

セキュリティー管理者の定義 166

接続 17, 18

ハードウェア 2

切断の回避 17

セットアップIBM Hyper-Scale Mobility 141

IBM Hyper-Scale Mobility 関係 151,

155, 157

セマンティクスミラーリングされた整合性グループ

93

ゼロの書き込み 24, 55

ソース 123, 141, 142

IBM Hyper-Scale 143

ソースの障害 128, 135, 136, 137, 139

ゾーニング 146

操作可能カップリング状態 107, 108

操作可能状況同期ミラーリング状況 63


操作不可カップリング状態 107, 108

即時スペース再利用 31, 55

［タ行］帯域幅 2

帯域幅の使用効率 17

代替マスター避難訓練 136, 139

タイプ初期化の 85, 86

タイム・スタンプ 64

タイム・スタンプ、last_replicated スナップショットの 115

単一物理コピー、データの 37

中断のないテスト 118

通知E メール 6

通知 (続き)

SMS 6

SNMP 6

データ (キャッシュ) モジュール 2

データ移動性 141

データ差分 86

データの仮想化 6, 9

データ複製 86

データ・マイグレーション 55

概要 160

書き込み要求 161

削除 161

障害 163

ステージ活動化 161

初期構成 161

テスト 161

同期 161

入出力処理 161

読み取り要求 161

データ・ミラーリング 6

データ・モジュール 2

停止基準間接的に関連付けられたグループの検索の 186

テナンシー 193, 195, 196

電子ライセンス 43

伝送役割の 89, 107, 108, 113

伝送途中のデータ 165

同期 64, 123

宛先とソースの間 143

同期状況同期ミラーリング状況 63

判別方法 90, 91

同期ジョブ 86

休止 109

進行状況 90

取り消し 82, 94, 97

含まれるスナップショット 41

保留 97

同期済みリモート・ミラーリング 57, 77, 78

IBM Hyper-Scale Mobility ソースの状態 143

同期速度低 17

同期低速度 17

同期複製 123

同期ミラーリング 55, 57

状況 61

同期ミラーリング状況 64

同期リモート・ミラーリング入出力操作 64

動的速度適応 17

特記事項法規 215

ドメイン 193, 195, 196

ドメイン管理者 193

ドメイン管理者以外のユーザードメイン・ベースのマルチテナンシーでの 193

ドメインの初期作成 193

トラック・モード 85, 86

取り消し同期ジョブ 82, 94, 97

［ナ行］内部スナップショット 41

なし役割のタイプ 107

入出力操作 64

認証 181

XIV 182

認証方式切り替え 188

盗まれたメディア 165

ネイティブ認証 181

［ハ行］ハードウェア支援によるロック 23, 24

ハードウェア接続 2

ハードウェア問題の解決 193

ハードウェア・コンポーネント 2

ハード容量、枯渇 52, 55

バックアップ 59

継続的な 31, 35

パフォーマンス・クラス(QoS) 25

ピア 80

ピア・ボリューム 123

非コミット・データ 67

非中断コード・ロード 203

非同期 123

リモート・ミラーリング 100, 101,

102, 103, 104, 105, 106

IBM Hyper-Scale Mobility ソースの状態 143

非同期複製 123

非同期ミラーリング 57

章の範囲 78

スケジューリング 87

非同期ミラーリング・プロセスウォークスルー 100

非同期リモート・ミラーリング状態マシン 107

ピアの役割 107

索引 221

非同期リモート・ミラーリング (続き)

役割の伝送 89, 107, 108, 113

XCLI 119

避難訓練 127, 136, 139

プール・スペースの枯渇 94, 97

スレーブ上の 99

保護されたスナップショット 95

フィーチャーと機能性 1

フィールド技術員用ポートイーサネット・ポート 16

ラップトップ接続DHCP を使用した構成 16

DHCP を使用しない構成 16

フェイルオーバー 113, 115, 117

マルチサイト・ミラーリング 127,

128, 135, 136, 139

3way ミラーリング 137

フェイルオーバー・テスト 118

フェイルオーバー・プロセス 6

フェイルバック 113, 115, 117

マルチサイト・ミラーリング 127,

128, 135, 136, 139

3way ミラーリング 137

フォーマットスナップショットおよびスナップショット・グループ 41

不揮発性ディスク・メディア 6

復元 49

スナップショット 38

ボリューム 38

複数検出間接的に関連付けられたグループ内の検索時 186

複数のターゲット 82

複数の並行ミラーリング関係 82

複製 77, 78, 123

複製状態 89

複製スキーム 82

不整合 (Inconsistent)

IBM Hyper-Scale Mobility 宛先の状態143

フラッシュ 8

フル・ボリューム・コピー 40

フレーム 141, 142

フロー・ダイアグラムIBM Hyper-Scale 143

プロキシーIBM Hyper-Scale Mobility ソースの状態 143

プロキシー準備完了ステージ 143

プロキシー処理済みIBM Hyper-Scale Mobility 宛先の状態

143

プロキシーの確立IBM Hyper-Scale Mobility 141

プロキシー・ステージ 143

ブロックのゼロ化 23

プロビジョニングシン 9

プロビジョニング、シン 52

分離ドメイン・ベースのマルチテナンシーでの 193

変更トラッキング 97

方式アクセス制御の 177

保護されたスナップショット 94, 95

保守システム状態 166

ディスクの可用性 166

ホストからの通知 55

関連 180

クラスター化 20

速度 25

通信、スレーブ・ボリュームとの 115

ホスト接続 17, 18

ホスト・インターフェース・モジュール2

ホスト・システム接続 17, 18

ホスト・ベースの入出力 4

保存データ (Data-at-Rest) 165

保存データのアクセス 165

保存データの暗号化に関するユース・ケース 166

保存データの暗号化の停止 166

保存データの暗号化を使用する処理 166

保存データの暗号化を使用するためのXIV システムの構成 166

ホット・アップグレード 203

ボリューム 29, 55

構成 59

ハード・サイズおよびソフト・サイズ52

復元 38

フル・ボリューム・コピー 40

ボリュームの構成混合構成 60

保留書き込み 63

［マ行］マイグレーションのトラッキング


マイグレーション・ステージ 143

マシンのリパーパス 141

マスター 80

役割のタイプ 107

マスター LRS 95

マスターの障害 127, 128, 135, 136, 137,

139

マスター・サイト 57

マスター・ボリューム 29

待ち時間待ち時間の克服、同期ミラーリングに固有の 77, 78

マッピングミラー関連のボリューム 115

マッピング、LUN 17

マップ解除ビット 24

マネージャー、SNMP 173

マルチサイト・ミラー作成 127

マルチサイト・ミラーの作成 127

マルチサイト・ミラーリング 123, 124,

127

マルチテナンシー 193, 195, 196

マルチパス 9

マルチ・ラック構成 9

未処理の同期ジョブ中断 115

ミラー 123

ミラー状態 89

ミラーリング 55, 123

終了、削除、非活動化 109

仕様 81

スケジューリング、非同期ミラーリングの 87

データ 6

マルチサイト 123, 124, 127

リモート 57, 77, 100, 101, 102, 103,

104, 105, 106

ミラーリング、整合性グループの 93,

109, 111, 112, 113

ミラーリングおよびスナップショット 84

ミラーリング関係 82

確立、後IBM Hyper-Scale Mobility 141

ミラーリングとスナップショット 81

ミラーリングの再同期 67

ミラーリングの削除 109

ミラーリングの終了 109

ミラーリングの非活動化 109

無保護スナップショット削除 97

メカニズム自己修復 6

モードスタンバイ 61

Active (アクティブ) 61

モジュールキャッシュ 7

データ 2

ホスト・インターフェース 2

UPS 2

モデム 4


［ヤ行］役割非同期ミラーリング・プロセス内の

107

役割の切り替え 70

リモート・ミラーリングが操作可能の場合の 70

リモート・ミラーリングが操作不可の場合の 70

役割の伝送非同期ミラーリング・プロセス内の

89, 107, 108, 113

役割ベースのアクセス制御 177

役割ベースのアクセス制御アプリケーション管理者 179

ユーザーの構成 182

ユーザー検索LDAP 187

ユーザー検証LDAP の使用 187

ユーザーとドメインの関連ドメイン・ベースのマルチテナンシーでの 193

ユーザーの役割アプリケーション管理者 177

技術員 177

権限レベル 177

ストレージ管理者 177

読み取り専用 177

ユーザー・グループ 179

関連 180

ユース・ケース保存データの暗号化 166

LDAP 184

用語 123

用語集 207

予備電源 7

［ラ行］ライセンス電子 43

ライフサイクルボリュームの 29

リカバリー 115, 117

災害からの 113

リカバリー・キー 165

リカバリー・キーの受信者の指定 166

リカバリー・ターゲット目標 89

リカバリー・ポイント目標 89

リサイクル再利用可能なストレージ・スペース

55

リソース割り振り 193, 195, 196

リモート・ミラーリング 57

および整合性グループ 74

カップリング 61

基本概念 57, 58

構成オプション 59

災害時回復タイプ 57, 58

操作 57, 58

同期 63, 65

同期ミラーリング状況 61

ベストエフォート・カップリング・リカバリー 66

ボリュームの構成 59

メディア・エラーのリカバリーのための 74

役割の切り替え 70

役割変更後の再開 72

リモート・モニター 9

リンク状態 107, 108

リンクが稼働しているIBM Hyper-Scale Mobility の操作状況

143

リンク状況同期ミラーリング状況 63

リンクに障害があるIBM Hyper-Scale Mobility の操作状況

143

レプリカ生成メカニズム 9

ロード・バランシング 141

ロックプール・スペースの枯渇中のプールの

95

論理ストレージ・ユニットマイグレーション 141

論理装置番号 17

［ワ行］割り振り状況 55

［数字］2 次サイト 57

2 次ソース 123

2 次ボリュームlast consistent 67

AA に障害が起こる 128, 135, 136, 137,

139

access_all 180, 182

ATS 24

A-B ミラー 123

A-C ミラー 123

BB の役割変更後 128, 135, 136, 137, 139

B-C の定義 128

B-C ミラー 123

CCDP (継続的なデータ保護) 35

CHAP 19

CLI



CLI 管理 15

CLI (コマンド行インターフェース) 9

COW (コピー・オン・ライト) 31, 32, 35

DDR (災害時回復)

災害時回復 113

EE メール (SMTP) ゲートウェイ 174

E メール宛先 173

E メールから SMS へのゲートウェイ174

E メール通知 6

ECLS 67

ECLS x 67

encrypt_recovery_key_finish 166

ESX

高速コピー 25

ゼロの書き込み 24

COMPARE AND WRITE 24

SCSI2 予約メカニズム 24

GGUI


コール・ホーム・コンタクト・リストの更新 26

GUI 管理 15

GUI (グラフィカル・ユーザー・インターフェース) 9

GUI の資料 168

GUI/CLI で開始される LDAP ログイン185

HHAK 18

HBA 17

索引 223

HIPAA コンプライアンス 165

HIPAA の連邦要件 165

Hyper-Scale のビジョン 141

IIBM Hyper-Scale Mobility 141, 142, 145,

158

関係 151, 155, 157

削除 157

クリーンアップ 157

計画 146

セットアップ 151, 155, 157

IBM Hyper-Scale Mobility 関係 143

IBM Hyper-Scale Mobility のステージ143

IBM Hyper-Scale Mobility の操作に関するデータの取得 146

IBM Hyper-Scale Mobility の操作に対するトリガーの決定 146

IBM Hyper-Scale Mobility の操作の優先順位付け 146

IBM Hyper-Scale Mobility の操作方法145, 158

IBM Hyper-Scale (一般) 141

IBM XIV Storage Management GUI 197

IBM XIV XCLI Reference Guide 127

IBM XIV 役割アクセス制御に関連した 183

IP 接続 13

IP 接続、ガイドラインの要約 17

IP 通信、システムによる開始 15

IPv6 14

iSCSI 5

iSCSI CHAP 認証 19

I/O 17

速度制限 25

Llast_replicated

削除 82, 94, 97


タイム・スタンプ 90

last_replicated スナップショット 115

LCS 67

LDAP 191

グループ・マッピング 183

サービス・アカウント 188

ディレクトリー 183

認証 181, 182

認証シナリオ 186

認証方式間の切り替え 188

ユーザー検証 187

LDAP (続き)

ユース・ケース 184

LDAP サーバー定義 184

LDAP サーバーの 184

LDAP 認証シナリオ 185

ldap_test 184

Lightweight Directory Access Protocol 182

LUN ID 41

LUN アレイ 18

LUN0 18

Mmap_vol 115

memberof

グループ属性 186

MFG 43

Microsoft Active Directory 182

Microsoft Windows Server 8 55

mirror_activate 115

mirror_change_role 115

mirror_change_schedule 115

mirror_create 85, 86, 115

mirror_create XCLI コマンド 127

mirror_delete 115

mirror_switch_roles 115

most_recent 85, 86

削除 82, 94, 97


most_recent スナップショット 127, 137

MRS 127, 128, 135, 136, 137, 139

NNever

スケジュール 115

デフォルト・スケジュール 87

OOK

リンク状態 107, 108

Open LDAP 182

Ppart_of_xmirror パラメーター 127

point of failure 6

pool_config_snapshots 95

protected_snapshot_priority 95

QQoS

パフォーマンス・クラス 25

RRedHat 55

Redirect-on-Write (ROW) 32, 35

ROW (Redirect-on-Write) 31, 32, 35

RPO 89

RPO_Lagging 90, 91, 109

RPO_OK 90, 91

RTO 89

SSCSI エラー

2 次ボリュームへの書き込み中 64

SED 168

Single Point of Failure 6

smis_user 179

SMS 宛先 173

SMS 通知 6

SNMP 9

SNMP 通知 6

SNMP マネージャー 173

SSD 8

SUN ディレクトリー 182

Symantec SSF 55

Symantec Storage Foundation のシン・レクラメーション 31

UUPS モジュール 2

USGv6 14

VVM クローン作成 25

VM の作成 24

VMWare 55

VVol 201

VVol について 201

XXCLI

非同期ミラーリング 119


XCLI コマンド 197

XIV GUI

コール・ホーム・コンタクト・リストの更新 26


XIV 鍵のリカバリー 165

XIV から LDAP へのマッピング 185

XIV 所有者 196

xiv 所有者 193, 195

XIV 認証 182

XIV の電源が投入されても、鍵サーバーが使用可能にならない 166

XIV の電源が投入されると、鍵サーバーが使用可能になる 166

XIV マッピング (XIV mapping) 191

XIV 役割の検索LDAP 187

xmirror_define XCLI コマンド 127

索引 225

��

Printed in Japan

GC43-0913-07

ibm xiv storage system · 2020. 7. 23. · スナップショット .....31 redirect-on-write...

Documents