Dell EMC ストレージ システム PowerStore および Unity XT メトロ ノード機能向け管 理者ガイド Version 7.
メモ、注意、警告 メモ: 製品を使いやすくするための重要な情報を説明しています。 注意: ハードウェアの損傷やデータの損失の可能性を示し、その危険を回避するための方法を説明しています。 警告: 物的損害、けが、または死亡の原因となる可能性があることを示しています。 © 2020 2021 Dell Inc.またはその関連会社。All rights reserved.（不許複製・禁無断転載）Dell、EMC、および Dell または EMC が提供する製品及びサー ビスにかかる商標は Dell Inc.
目次 章 1: CLI ワークスペースとユーザー アカウント.................................................................................... 7 CLI ワークスペースの構成...................................................................................................................................................7 コンソール ログのしきい値の設定............................................................................................................................. 7 ウィンドウ幅を 100 に設定.........................................................................
章 6: ボリュームの拡張................................................................................................................... 32 概要.......................................................................................................................................................................................32 追加のドキュメント....................................................................................................................................................32 ボリューム拡張メソッド.....................
サブネット コンテキスト.......................................................................................................................................... 55 /connectivity/back-end/............................................................................................................................................. 56 /connectivity/front-end/.............................................................................................................................................
ポートのモニタリング...................................................................................................................................................... 92 はじめに.........................................................................................................................................................................92 レポートの E メール送信スクリプトのセット アップ..........................................................................................92 スクリプト ステータスのチェック.....................................
1 CLI ワークスペースとユーザー アカウント この章では、メトロ ノードのコマンド ライン インターフェイス（CLI）を使用して CLI ワークスペースを構成し、ユーザー アカウン トを管理する方法について説明します。 トピック： • CLI ワークスペースの構成 CLI ワークスペースの構成 ワークスペースは、CLI セッションの表示と作動です。このセクションで説明する手順を使用して、コマンドの出力とコンソールに 送信されるログ メッセージのレベルを制御し、現在の CLI セッションのコマンド履歴を検索できます。 メモ: メトロ ノード CLI を開始するために、ユーザー名とパスワードは必要なくなりました。自動スクリプトによってユーザー 名またはパスワードが入力されていないことを確認してください。 コンソール ログのしきい値の設定 コンソール ロガーには、コンソールのダイレクターから受信したメッセージが表示されます。 デフォルトでは、コンソールに緊急（レベル 0）メッセージのみが表示されます。 メッセージは 8 段階の重大度（0-7）に分類され、0 は最も重大です。 7：debug（デバッグレベ
ここで、n は 0-7 です。 メモ: しきい値は、重大度が高いまたは同等のメッセージをすべてフィルタリングします。 critical（2）以上（0 と 1）を表示するには、しきい値を 3 に設定します。 error（3）以上（0、1、2）を表示するには、しきい値を 4 に設定します。 ウィンドウ幅を 100 に設定 多くのコマンドから出力される列の幅は、80 を超えています。メトロ ノード CLI を実行しているコマンド ウィンドウを拡張して、 幅を少なくとも 100 にしてください。 コンテキスト ツリーの検索 特定のパターンに一致するコンテキスト名とデータをコンテキスト ツリーで検索できます。 Find コマンドを使用したコンテキスト ツリーの検索 パターンに一致するすべてのコンテキストを検索するには、このコマンドを使用します。対話形式で呼び出すと、コマンドによっ てコンテキストが画面に出力されます。 パターンには、リテラル文字列またはワイルドカード文字を含む文字列を使用できます。対応している CLI ワイルドカード文字のリ スト全体については、CLI 参照ガイドのトピック「ワイルドカード」を参照
2 メタ ボリューム この章では、メトロ ノード CLI を使用してメタデータとメタボリュームを管理する手順について説明します。 トピック： • • • • • • メタボリュームの概要 メタボリュームの移動 メタボリュームの名前の変更 メタボリュームの削除 メタボリュームの表示 メタボリュームの整合性の確認 メタボリュームの概要 メトロ ノードのメタデータには、仮想環境から物理環境へのマッピング、デバイスに関するデータ、仮想ボリューム、システム構 成の設定が含まれています。 メタデータは、キャッシュに保存され、メタ ボリュームと呼ばれる専用の外部ボリュームにバックアップされます。 メタボリュームは、システムのセットアップ中に作成されます。 クラスターの初回構成時には、メタボリュームをメトロ ノードに表示される最初のストレージにする必要があります。これにより、 メタボリュームが誤って上書きされるのを防ぐことができます。 メタボリュームが構成されると、メタデータへのアップデートは、メトロ ノード構成が変更される際に、キャッシュとメタボリュー ムの両方に書き込まれます。 バックアップ メタボリュームは、現在
可用性はメタボリュームにとって重要です。メタボリュームはシステムのリカバリーに不可欠です。2 個以上のバックエンド アレ イでメタ ボリュームのミラーリングをして、データ ロスが起こる可能性を排除することをお勧めします。メタボリュームのミラー リングを行うアレイを選択して、同時移行が必要ないようにしてください。 警告: 単一のストレージ アレイのボリュームを使用してメタボリュームを作成しないでください。単一のアレイのメタボリュ ームは高可用性構成ではなく、単一障害点となります。 メトロ ノードからすべてのメタボリュームへのアクセスが一時的に失われた場合、アクセスが回復すると、キャッシュ内の現在の メタデータがメタボリュームに自動で書き込まれます。 メトロ ノードから両方のメタボリュームへのアクセスが恒久的に失われた場合、メモリー内のメタデータに基づいて処理が継続さ れます。構成の変更は、新しいメタボリュームが作成されるまで中断されます。 メモ: メトロ ノードからすべてのメタボリュームへのアクセスが失われ、すべてのダイレクターで障害が発生したか再起動が行 われた場合、アクセス不可になった後にメタデータ（メトロ
手順 1. /clusters/cluster/system-volumes/コンテキストにアクセスします。 VPlexcli:/> cd clusters/cluster-2/system-volumes/ VPlexcli:/clusters/cluster-2/system-volumes> 2. ll コマンドを使用して、メタボリュームの名前を表示します。 3. /clusters/cluster/system-volumes/target-meta-volume コンテキストにアクセスします。 例： VPlexcli:/clusters/cluster-2/system-volumes> cd new_meta1_backup_2010May24_163810 4.
メモ: メタデータ ボリュームを削除した後、今後は混乱が起きないようにするため、外部手段を通じてストレージ ボリュー ムのデータを削除します。 メタボリュームの表示 メタボリュームのステータスを表示するには、次のように ll コマンドを使用します。 VPlexcli:/clusters/cluster-1/system-volumes/svtmeta> ll /clusters/cluster-1/system-volumes/svtmeta: Attributes: Name Value ---------------------- ----------active true application-consistent false block-count 20971264 block-size 4K capacity 80G component-count 2 free-slots 63997 geometry raid-1 health-indications [] health-state ok locality local operational-status ok ready true rebu
表 1.
表 1.
3 システム管理 この章では、コールホーム通知の使用方法、イベント ログの場所、VAAI を使用したハードウェア アクセラレーションについて説明 します。 トピック： • • • • • • コールホーム通知 イベント ログの場所 VAAI によるハードウェア アクセラレーション XCOPY を使用したコピー オーバーヘッドのオフロード メトロ ノード クラスターの名前の変更 LCD 前面パネルの設定 コールホーム通知 コールホーム通知の概要 コールホーム通知とは、重大な問題が発生した場合に、Dell EMC カスタマー サービスおよび/またはカスタマー サポートの担当者に 自動的に送信されるメッセージです。コールホーム通知により、Dell EMC では関連担当者がプロアクティブに連携し、構成済みの ESRS ゲートウェイを使用して問題を解決できるようになります。 システム イベントには 4 個のレベルがあります。コールホーム通知が送信されるのは、次の 3 個のレベルに関してのみです。 表 2.
コールホーム通知と SYR の両方の設定がすでに構成されている場合は、現在の構成情報が表示されます。 開始する前に コールホーム通知の構成を完了するには、次の情報が必要です。 ● Dell EMC へのコールホーム通知の転送に使用される ESRS ゲートウェイの IP アドレス。Dell EMC は、プライマリー接続アドレス に ESRS ゲートウェイを使用することを推奨しています。 ● （オプション）プライマリー サーバー障害発生時に、Dell EMC へのコールホーム通知の転送に使用されるセカンダリー ESRS ゲー トウェイ サーバーの IP アドレス（1 個以上）。これらのアドレスは、プライマリー SESRS ゲートウェイ サーバーのアドレスとは 別にする必要があります。 ● （オプション）コールホーム通知が配信された時に E メール メッセージを受信する必要のある担当者の E メール アドレス（1 個以 上）。 追加のドキュメント SupportAssist を構成する手順については、メトロ ノード ジェネレーターを参照してください。 次の SupportAssist 構成コマンドの詳細について
VAAI によるハードウェア アクセラレーション アレイ統合向け VMware API（VAAI）では、次のことを実行できます。 ● ● ● ● コンピューティング側からストレージ ハードウェアへのストレージ操作をオフロードする。 スナップショットのプロビジョニングと作成を行う I/O 集約型操作を、ハイパーバイザーからメトロ ノードに移動する。 ハイパーバイザー メモリーと処理リソースを他の機能専用にする。 シン プロビジョニングをしたボリュームから未使用のストレージ ブロックの割り当てを解除する。 メトロ ノードにおけるシ ン サポート 、p.
● ストレージ ビュー：すべての既存のストレージ ビューに対して有効または無効になります。CAW 後に作成されたストレージ ビ ューは、システムのデフォルト設定を継承したストレージ ビュー レベルで有効/無効になります。Dell EMC は、すべてのストレ ージ ビューで同様の CAW 設定を維持することを推奨しています。特定のストレージ ビューに対して CAW を無効にする必要が ある場合は、既存および将来のすべてのストレージ ビューに対して無効にする必要があります。将来のストレージ ビューに新し い設定が反映されるようにするには、システムのデフォルト（次に記載）を変更します。 ● システムのデフォルト：システムのデフォルトとして有効または無効になります。CAW 後に作成されたストレージ ビューは、 システムのデフォルト設定を継承したシステム デフォルト レベルで有効/無効になります。システムのデフォルトを有効にす ると、新しいストレージ ビューの CAW サポートも有効になります。 CAW 設定の表示 /clusters/cluster/exports/storage-views コンテキストで ls
CAW をシステム デフォルトとして有効化/無効化 /clusters/cluster コンテキストで set コマンドを使用して、クラスター全体の CAW を有効または無効にします。 CAW をクラスター システムのデフォルトとして有効化するには、次のようにします。 VPlexcli:/clusters/cluster-1> set default-caw-template true CAW をクラスター システムのデフォルトとして無効化するには、次のようにします。 VPlexcli:/clusters/cluster-1> set default-caw-template false CAW の統計情報 CAW のパフォーマンス統計情報は、フロントエンド ボリューム（fe-lu）、フロントエンド ポート（fe-prt）、フロントエンド ダイレ クター（fe-director）のターゲットに含まれています。 使用可能な統計情報の一覧については、「統計表 、p.
特定のストレージ ビューに対して WriteSame（16）を無効にする必要がある場合は、既存および将来のすべてのストレージ ビュ ーに対しても無効にする必要があります。将来のストレージ ビューに新しい設定を反映させるには、システムのデフォルトを変 更します。 ● システムのデフォルト：システムのデフォルトとして有効または無効になります。WriteSame（16）後に作成されたストレージ ビューは、システムのデフォルト設定を継承したシステム デフォルト レベルで有効/無効になります。システムのデフォルトを 有効にすると、新しいストレージ ビューの WriteSame（16）サポートも有効になります。 注意: Write Same（16）のデフォルトのテンプレートを無効にするには、すべての将来のビューで Write Same（16）が無 効になるように、すべての既存のビューに対する Write Same（16）を無効にして、Write Same（16）テンプレートを無効 にする必要があります。Write Same（16）のデフォルトのテンプレートを有効にするには、すべての将来のビューで Write Same（1
ストレージ ビューに対して WriteSame（16）を無効化するには、次のようにします。 VPlexcli:/clusters/cluster-1/exports/storage-views/recoverpoint_vols> set write-same-16enabled false WriteSame（16）をシステム デフォルトとして有効化/無効化 /clusters/cluster コンテキストで set コマンドを使用して、クラスター全体の WriteSame（16）を有効または無効にします。 WriteSame（16）をクラスター システムのデフォルトで有効にするには、次のようにします。 VPlexcli:/clusters/cluster-1> set default-write-same-16-template true WriteSame（16）をクラスター システムのデフォルトで無効にするには、次のようにします。 VPlexcli:/clusters/cluster-1> set default-write-same-16-template false XCOPY を使用したコピ
2. 次のようにクラスター コンテキストのすべての属性をリスト表示して、default-xcopy-template 属性のステータスを 確認します。 VPlexcli:/clusters/cluster-1> ls XCOPY 統計情報の表示 メトロ ノードは、XCOPY 操作のパフォーマンスと頻度を追跡する統計情報を提供します。これらの統計情報は、フロントエンドで 収集されます。 統計情報 、p. 96 を参照してください。 XCOPY モニターのセット アップ 永続モニタリングの一環として自動収集されないすべての統計情報については、モニターを手動で作成して、特定のメトロ ノード 仮想ボリューム上の XCOPY レイテンシーの統計情報を収集できます。 モニターを作成してファイル シンクを構成し、特定の fe-lu（メトロ ノード仮想ボリューム）の統計情報が、構成したファイルに収 集されるようにします。 次の例では、モニターの作成して、特定のボリューム（VAAI_Vol1_Device_vol）の fe-lu.
注意: このパネルは、iDRAC と R640 のいずれかの設定を変更するために使用しないでください。設定を変更すると、メトロ ノードの設定に干渉して、機能障害が発生する可能性があります。 システム管理 23
4 メトロ ノードにおけるシン サポート この章では、メトロ ノードによるシン対応機能のサポート方法について説明します。 トピック： • • • • メトロ ノードにおけるシン サポート シン プロビジョニング シン ストレージ管理 シンのミラーリングと移行 メトロ ノードにおけるシン サポート シン対応は、メトロ ノード仮想ボリュームをシン ボリュームとしてホストに提示する機能です。シン ボリュームにより、使用され るリソース量が割り当て済みの量よりもかなり少なくなるため、効率性が向上します。必要なリソースのみを提供することによっ てもたらされるこのメリットは、使用される仮想化テクノロジーのコストを上回るものです。シン サポートのあるストレージ ボリ ュームのストレージ ブロックを動的に解放できます。シン サポートにより、必要に応じて物理ブロックに 1 個以上の論理ブロック をマッピングすることができます。論理ブロックは、ストレージ アドレス スペース（論理ユニット容量）をホストに提供します。 物理ストレージが論理ユニットに割り当てられるのは、論理ユニット使用時のみです。これにより、論理ユニットには、
シン移行 メトロ ノードは、シン デバイス上のデータ移動機能に対応しています。移行のソースまたはターゲットがシンでない場合や、ソー スとターゲットが異なるストレージアレイ ファミリーに属している場合、メトロ ノード仮想ボリュームはシン プロパティを失いま す。このような状況では、仮想ボリュームでシン ストレージ管理操作を行うことができません。移行が完了してコミットされると、 仮想ボリュームはターゲット デバイスのシン機能を継承します。シン対応ストレージの移行に関する詳細については、「シン対応ス トレージの移行」を参照してください。 次の表では、メトロ ノードによるシン対応機能のサポート方法について説明しています（メトロ ノードでアレイがシン対応である かどうかに基づいています）。 表 4.
○ UNMAP 機能がアレイでオンになっていない場合 従来のプロビジョニング メソッドによる thin-enabled 仮想ボリュームの作成 従来のメソッドでは、次の 2 通りの方法で thin-enabled 仮想ボリュームを作成できます。 ● EZ プロビジョニング：storage-tool compose --thin コマンドを使用して、特定のストレージボリューム上に仮想ボリュ ームを作成し、必要に応じて、中間のエクステント、ローカル、分散デバイスすべてを構築できます。 ● 高度なプロビジョニング：次のタスクを実行できます。 ○ メトロ ノードによって検出されたシン ストレージ ボリュームを手動で要求する。 ○ extent create コマンドを使用して、thin-capable ストレージ ボリューム上にエクステントを作成する。 ○ local-device create コマンドを使用して、thin-capable のローカル デバイスを作成する。 ○ virtual-volume create --thin コマンドを使用して、thin-enabled 仮想ボリュームを作成する。 メモ:
Name -------------------------block-count block-size cache-mode capacity consistency-group expandable expandable-capacity expansion-method expansion-status health-indications health-state locality operational-status scsi-release-delay service-status storage-tier supporting-device system-id thin-capable thin-enabled volume-type vpd-id Value ---------------------------------------5242880 4K synchronous 20G true 0B storage-volume [] ok local ok 0 running XtremIO_LUN_1 XtremIO_LUN_1_vol true enabled virtual-vo
ストレージ アレイが通知できるストレージ ブロック不足エラーは、主に 2 種類あります。これらは次のとおりです。 ● 一時的な不足：ストレージ アレイのスペース解放プロセス中に、書き込み成功の応答をすぐに返せない場合に発生します。こ のような場合、メトロ ノードは書き込みが失敗してストレージ ボリュームに hardware-dead とマーク付けする前に、短時間の I/O を再試行します。コール ホームはこのような場合に発行されます。ストレージ ボリュームが正常性テストの応答に成功す ると、メトロ ノードはストレージ ボリュームの自動リカバリーを試みます。正常なミラーによってストレージ ボリュームが保護 されている場合、正常なミラー レッグがホストに対する I/O 処理を継続するため、ホストでサービスの停止が認識されることは ありません。 ● 恒久的な不足：ホストが write コマンドを発行したアドレスにマッピングを行うための使用可能ストレージ ブロックがない場合 に発生します。メトロ ノードは、このエラーに対し、ミラーリングをしたデバイスとミラーリングをしていないデバイスで異な る処理を行います。 ミラー
シン対応デバイスにシック ミラーを接続するために device attach-mirror -d コマンドを実行すると、デバイスがシン対応に なっていないことを示す警告が表示されます。また、続行するかどうかを確認するメッセージが表示されます。--force オプショ ンを使用して確認を省略できますが、結果として表示されるデバイスはシンではありません。 VPlexcli:/clusters/cluster-1/storage-elements/extents> device attach-mirror -d myDevice -m extent_TOP_101_1 The top-level device 'myDevice' is thin-capable. After attaching the mirror, the new top-level device will not be thin-capable.
5 ストレージのプロビジョニング この章では、メトロ ノードの統合ストレージ プロビジョニングを使用したストレージのプロビジョニング方法を説明します。 トピック： プロビジョニングの概要 EZ プロビジョニングを使用したストレージ プロビジョニング 仮想ボリュームのシン特性の変更 • • • プロビジョニングの概要 メトロ ノードの使用を開始するには、ストレージのプロビジョニングを行い、ホストがストレージにアクセスできるようにする必 要があります。メトロ ノードでストレージのプロビジョニングを行う方法は 3 種類あります。 ● EZ プロビジョニング ● 高度なプロビジョニング メモ: Dell EMC は、メトロ ノード Unisphere GUI を使用したストレージのプロビジョニングを推奨しています。 EZ プロビジョニングを使用したストレージ プロビジョニ ング EZ プロビジョニングは、メトロ ノード向けの Unisphere でのみ使用できる簡単なプロビジョニング メソッドです。EZ プロビジョ ニングは、選択したストレージ ボリュームに対する 1 対 1 のマッピングで仮想ボリュームを作
Name -------------------------block-count block-size cache-mode capacity consistency-group expandable expandable-capacity expansion-method expansion-status health-indications health-state locality operational-status scsi-release-delay service-status storage-tier supporting-device system-id thin-capable thin-enabled volume-type vpd-id Value ---------------------------------------5242880 4K synchronous 20G true 0B storage-volume [] ok local ok 0 running XtremIO_LUN_1 XtremIO_LUN_1_vol true enabled virtual-vo
6 ボリュームの拡張 この章では、仮想ボリュームを拡張する方法について説明します。 トピック： 概要 ボリューム拡張メソッド 仮想ボリュームの拡張 • • • 概要 メトロ ノード仮想ボリュームはデバイスまたは分散デバイスに作成され、ストレージ ビューを通じてホストに提示されます。さま ざまな理由から、仮想ボリュームの容量拡張が必要になる場合があります。 ボリュームが拡張に対応している場合、メトロ ノードは拡張によって得られた容量を検出します。次に、使用できる拡張メソッド： storage-volume を判断します。メトロ ノードでは、使用できる拡張メソッドも検出できます。 すべての仮想ボリュームを拡張することはできません。詳細については、「ボリューム拡張メソッドの判断」を参照してください。 次の簡単で無停止の手順を使用して、ボリュームの拡張を実行します。 1. 基盤となるストレージ アレイ上の仮想ボリュームに関連付けられているストレージ ボリュームを拡張します。 2. メトロ ノードが、基盤となるストレージ アレイを再検出できるようにします。 3.
. . . capacity consistency-group expandable expandable-capacity expansion-method expansion-status 0.5G true 0.
仮想ボリュームの拡張 ストレージボリューム拡張メソッド ストレージボリューム メソッドを使用して仮想ボリュームを拡張するには、次のガイドラインに従います。 概要 ストレージ ボリュームの拡張方法では、さまざまなデバイス ジオメトリーでシンプルかつ高速に拡張できます。ここでは、最も一 般的なデバイス ジオメトリーのうちの 3 個について説明します。 1 対 1 の仮想ボリュームとストレージ ボリューム 図 2.
デュアルレッグ RAID 1 図 3.
注意: ボリューム サイズの変更を検出するために、主要なホスト操作（LIP リセットなど）を実行すると、ホストからアクセ スをするボリュームにリスクが発生します。ボリュームの拡張時には、リソースの集中するこのような操作を行わないことを お勧めします。 ● 拡張初期化トラフィックが、ホストの I/O を実行していないディスク領域で発生します。また、新しく追加された容量の 初期化にかかる時間は、アレイのホスティング パフォーマンス、つまりストレージ ボリュームに左右されます。しかしな がら、想定されるパフォーマンスは、ボリュームの再構築にかかる時間よりは依然として短くなります。 ● 分散 RAID 1 デバイス全体での初期化プロセスでは、各クラスターの初期化がローカルで実行されるため、WAN データ帯域 幅が消費されません。 ● RAID 1 および分散 RAID 1 デバイスでは、メトロ ノードが拡張されたスペースについての一貫した情報をすべての RAID 1 レッグに配置します。 ● RAID 1 および分散 RAID 1 デバイス ジオメトリーの冗長性レベルは、拡張と初期化のプロセスにより維持されます。 ●
トラブルシューティングと正常性の表示 ボリュームの拡張が失敗した場合、失敗した理由に関する情報が health indications 属性に追加されます。拡張が失敗した場 合でも、仮想ボリュームの全体的な正常性、稼働ステータス、またはサービス ステータスが縮退することはありません。 ボリューム拡張エラーからのリカバリー手順は、SolVe Desktop の「メトロ ノードのトラブルシューティング」セクションに記載され ています。 アレイの再検出 拡張後に、アレイの再検出が必要になる場合があります。バックエンド アレイのタイプと構成によっては、ストレージ アレイがメ トロ ノードによる自動検出に対応していない可能性があります。 ベスト プラクティス メトロ ノードがストレージ ボリュームの変更を自動検出しない場合は、array-rediscover コマンドを使用して、メトロ ノード にバックエンドの拡張を強制的に認識させます。 アレイ上で複数のストレージ ボリュームを拡張している場合は、すべてのストレージ ボリュームの拡張を完了してから、アレイを 1 度だけ再検出し、メトロ ノードにすべての拡張を強制的
7 データ移行 この章では、データ移行と再構築について説明します。 トピック： • • • • • データ移行の概要 シン対応ストレージの移行 再構築の概要 1 回限りのデータ移行 バッチ移行 データ移行の概要 データ移行には次の 2 種類があります。 ● 1 回限りの移行：dm migration start コマンドが使用された時に、ただちにデバイスの移行を開始します。 ● バッチ移行：再使用できる移行計画ファイルを使用して、バッチ ジョブとして実行されます。単一のコマンドを使用して、デ バイスまたはエクステントの複数の移行を実行できます。 1 回限りの移行 1 回限りの移行には次の移行が含まれます。 ● デバイス移行：デバイスは 1 対 1 のマッピングが行われたデバイスか、エクステントまたは他のデバイスに構築された RAID 1 デバイスです。 デバイスの移行では、同じクラスター上のデバイス間、または異なるクラスター上のデバイス間でデータを移動します。デバイ ス移行を使用すると、次の操作を実行できます。 ○ 異なる種類のアレイ間でデータを移行します。 ○ ホット ボリュームをより高速なアレイに
1. 2. 3. 4. 5. 移行計画の作成とチェックを行います（バッチ移行の場合のみ）。 移行を開始します。 移行の進行状況を監視します。 移行を中断、再開またはキャンセルします（オプション）。 移行をコミットします。コミットにより、ソース仮想ボリューム、デバイスがターゲットに転送されます。 システムによってデバイス上の仮想ボリュームにデフォルト名が割り当てられている場合、デバイス移行のコミットをすると、 仮想ボリュームの名前がターゲット デバイスにちなんだ名前に変更されます。 6.
表 5.
● シンからシック エクステントへの移行（対応仮想ボリュームなし）では、ソースが thin-capable でターゲットが thin-capable で はない場合、ソースは移行後にシン機能を失います。 VPlexcli:/clusters/cluster-1/storage-elements/extents> dm migration start --paused --name my_migration --from thin_extent_2 --to thick_extent_1 The source 'thin_extent_2' is thin-capable but the target 'thick_extent_1' is not thincapable. Thin-capability will be lost after migration.
● シンからシック エクステントへの移行（対応仮想ボリュームなし）では、メトロ ノード CLI に、移行後にソースのシン機能が 失われることを示す警告が表示されます。 VPlexcli:/> batch-migrate create-plan --file migration.txt --sources extent_thin_1, extent_thin_2 --targets extent_thick_1, extent_thick_2 Extents matching source pattern: extent_thin_1, extent_thin_2 Extents matching target pattern: extent_thick_2, extent_thick_1 Creating file /var/log/VPlex/cli/migration.txt as migration plan file. Wrote file /var/log/VPlex/cli/migration.txt.
再構築の概要 再構築では、ソース ドライブからターゲット ドライブにデータを同期します。RAID のレッグ間で相違が生じた場合は、再構築によ って古いレッグのアップデートが行われます。 再構築の作動には次の 2 種類があります。 ● フル再構築では、ターゲットにソース コンテンツ全体のコピーが行われます。 ● ログ再構築では、変更されたブロックのみがソースからターゲットにコピーされます。 ローカル ミラーのアップデートはフル再構築を使用します（ローカル デバイスはログ ボリュームを使用しません）。 メトロ ノードの Metro 構成では、すべての分散デバイスにログ ボリュームが関連付けられています。ログ ボリュームは、クラスタ ー間リンクのアウテージ中に書き込まれたブロックの追跡を継続します。リンクやレッグが復元されると、メトロ ノード システム ではログ ボリュームの情報を使い、リンク経由で変更したブロックのみを送信してミラーを同期します。 ログ ボリュームの再構築は、分散 RAID 1 のレッグがアクセス不可になったものの、すぐにリカバリーをした場合にも実行されま す。 レッグに「out-of-date」
していて、レッグが RAID 1 の最後の冗長レッグである場合、シン プロビジョニングをしたデバイスへの書き込みをさらに行 うと、ボリュームがデバイスにアクセスできなくなります。この問題により、データ欠損が発生する場合があります。 パフォーマンスに関する考慮事項 メトロ ノード全体のパフォーマンスを向上させるには、自動再構築を無効にするか、再構築の転送サイズを変更してください。 ● 2 個のクラスターを再接続する際の大量のアクティビティーを回避するには、自動再構築を無効にします。 注意: 自動再構築を無効にすると、分散 RAID 1 が同期されなくなります。子デバイスが古くなると、リモートの読み取り になる可能性が高くなります。 ● 再構築の転送サイズを変更します。詳細については、「転送サイズの概要」を参照してください。 1 回限りのデータ移行 1 回限りのデータ移行では、dm start migration コマンドを使用すると、指定したソースとターゲットの間ですぐにデータを移 動できます。バッチ移行の場合とは異なり、再使用できる移行計画ファイルは作成されません。 1 回限りのデバイス移行の開始 手順
このタスクについて VPlexcli:/> ls data-migrations/device-migrations/ migrate_012 Name Value --------------- ---------------------------from-cluster cluster-1 percentage-done 10 source device_012 source-exported false start-time Fri May 28 13:32:23 MDT 2010 status in progress target device_012a target-exported false to-cluster cluster-2 transfer-size 12M type full 表 7.
このタスクについて アクティブな移行を一時停止して、ピーク トラフィック時にホスト I/O の帯域幅を解放します。 移行を一時停止するには、dm migration pause --migrations コマンドを使用します。 デバイス名がグローバル ネームスペース内で一意の場合は、名前で migration-name を指定します。それ以外の場合は、フル パス名 を指定します。 例： ● デバイス移行を一時停止します。 VPlexcli:/data-migrations/device-migrations> dm migration pause --migrations migrate_012 一時停止した移行を再開するには、dm migration resume --migrations コマンドを使用します。 デバイス名がグローバル ネームスペース内で一意の場合は、名前で migration-name を指定します。それ以外の場合は、フル パス名 を指定します。 例： ● 一時停止したデバイス移行を再開します。 VPlexcli:/data-migrations/device-migrations> d
● 次に、デバイス移行のコミットを行います。 VPlexcli:/data-migrations/device-migrations> dm migration commit --force --migrations migrate_012 Committed 1 data migration(s) out of 1 requested migration(s).
2. バッチ移行計画ファイルのテストを行う（batch-migrate check-plan コマンドを使用）。 前提条件 バッチ移行では、次の前提条件を満たす必要があります。 ● ソースとターゲットはどちらもデバイスであること。 ● ローカル デバイスはターゲット アレイ上で構成すること（デバイス移行）。 ● ターゲットの構造はソースの構造と同じであること。 バッチ移行計画の作成 batch-migrate create-plan コマンドは、指定されたソースとターゲットを使用して移行計画を作成します。 このタスクについて 次の例では、batch-migrate create-plan コマンドは、「MigDev-test.txt」という名前のバッチ移行を次のように作成します。 ● クラスター 1 にある 2 個のデバイスを、クラスター 2 にある 2 個のデバイスに移行します。 ● 既存の計画を同じ名前で上書きします。 VPlexcli:/> batch-migrate create-plan --file MigDev-test.
バッチ移行ファイルの変更 バッチ移行ファイルを変更するには、次のいずれかを実行します。 このタスクについて ● batch-migrate create-plan コマンドを使用して同じファイル名を指定し、--force オプションを使用して古い計画を新 しい計画で上書きします。 ● 管理サーバーを終了して、/var/log/VPlex/cli/にアクセスします。 テキスト エディター（vi）を使用して、ファイルを編集および保存します。 VPlexcli:/> exit Connection closed by foreign host.
特定のアクティブな移行を一時停止するには、batch-migrate pause コマンドを使用します。例： VPlexcli:/data-migrations/device-migrations> batch-migrate pause --file migrate.txt 特定の一時停止した移行を再開するには、batch-migrate resume コマンドを使用します。例： VPlexcli:/data-migrations/device-migrations> batch-migrate resume --file migrate.txt バッチ移行のキャンセル（オプション） アクティブなバッチ移行をキャンセルして、ソース ボリュームを移行の開始前の状態に戻します。 このタスクについて 特定のバッチ移行をキャンセルするには、batch-migrate cancel コマンドを使用します。例： VPlexcli:/data-migrations/device-migrations> batch-migrate cancel --file migrate.
このタスクについて 例： VPlexcli:/> batch-migrate summary migrate.txt Processed 10 migrations from batch migration BR0: committed: 0 complete: 10 in-progress: 0 paused: 0 error: 0 cancelled: 0 no-record: 0 表 8. バッチ移行の概要 フィールド 説明 Processed....
バッチ移行のクリーニング デバイス移行のクリーニングでは、ソース デバイスのストレージ ボリュームまでが破棄されます。使用されなくなったストレージ ボリュームに対する要求は行われません。 このタスクについて デバイスの移行の場合のみ、オプションの--rename-target 引数を使用して、ターゲット デバイスの名前をソース デバイスにち なんだ名前に変更します。ターゲット デバイスの名称変更時に、ターゲット デバイスにシステムの割り当てたデフォルト名が付い ていると、そのターゲット デバイスの上位にある仮想ボリュームの名前も変更されます。 名前を変更しないと、ターゲット デバイスはそのターゲット名を持ち続けるため、ボリュームとデバイス間の関係が明らかになら ない場合があります。 特定のバッチ移行のクリーニングを行うには、batch-migrate clean --file コマンドを使用します。 注意: このコマンドは、バッチ移行が削除されてしまう前に実行する必要があります。このコマンドでは、VPlexcli コンテキ スト ツリーにレコードのない移行のクリーニングを行うことはできません。 次の例では、ソ
8 WAN ネットワークの構成 各メトロ ノード ダイレクター上の 2 個の WAN ポートは、デュアル 10 ギガビット イーサネットのクラスター間リンクに対応してい ます。WAN ポートは、2 番目のクラスターのインストールの一環として構成されます。この章では、インストール時に作成された 構成を変更す CLI のコンテキストと手順について説明します。 トピック： • • • • • メトロ ノード ハードウェアおよび WAN ポート Metro over IP WAN ポートの構成ルール CLI コンテキスト バックエンド ネットワークの管理とモニタリング LDAP メトロ ノード ハードウェアおよび WAN ポート メトロ ノード Metro over IP クラスター内のダイレクターには、WC-00 と WC-01 という名前の 2 個の 10 ギガビット イーサネット （10 GbE）ポートがあります。 警告: メトロ ノード Metro 構成内のダイレクター上およびクラスター間の WAN ポートを移動するデータは暗号化されません。 DNS 攻撃を防ぐため、安全で信頼できるネットワークでのみ
● front-end ：ホストとの接続の構成。 ● back-end ：ストレージ アレイとの接続の構成。 port-groups コンテキスト 接続の各役割（back-end、front-end、local-com、wan-com）に割り当てられたポート グループ（または通信パス）は、各役割の port-groups サブコンテキストに記載されています。 各クラスターの WC-00 という名前のポートは、総称して ip-port-group-0 と呼ばれます。ip-port-group-0 は 2 個あり、各クラスター に 1 個ずつ用意されています。各クラスターの ip-port-group-0 から、クラスター間通信チャネルが 1 個形成されます。 各クラスターの WC-01 という名前のポートは、総称して ip-port-group-1 と呼ばれます。port-group-1 は 2 個あり、各クラスターに 1 個ずつ用意されています。各クラスターの ip-port-group-1 から、2 番目のクラスター間通信チャネルが形成されます。 次の例は、各クラスターに 2 個の back-end fc
IP port-groups には次のものが含まれます。 ● option-set コンテキストは、メンバー ポートに共通する構成オプションを記載しています。 ● subnet コンテキストは、IP ネットワーキングの構成オプションを記載しています。それぞれの役割に異なるネットワーキング ニーズがあるため、サブネット コンテキストにはさまざまなプロパティが含まれています。これらのサブネットは、関連付け られている役割内で説明されています。 ● enabled ：個々のメンバー ポートの有効ステータスがまとめてあります。 メンバー ポート member-ports コンテキスト内のプロパティは、すべて読み取り専用です。 すべての port-groups には、ポート グループ内の各ダイレクターのポートをリスト表示する member-ports コンテキストが含まれて います。port-groups は、アクセス不可になったダイレクターの member-ports を記憶します。ダイレクターがアクセス不可になる と、port-group はアクセス不可のポートを表示しますが、アクセス不可であることを示すのみです
● prefix にはクラスターアドレスを含めること。 ● prefix にはゲートウェイを含めること。 ● gateway はローカル クラスター上で一意のアドレスであること。 次の点に注意してください。 ● 削除されたアドレスはすべてのプレフィックスに含まれており、どのアドレスとも一致しません。 ● 削除されたプレフィックスには、すべてのアドレスが含まれています。 ● 特定のサブネット コンテキストに存在しないプロパティは、削除されたものと見なされます。 サブネットに変更を加えた場合は、その変更が検証され、このサブネットを使用するすべてのポートに適用されます。 port-group の再構成時には、複数の値で互いに整合性を持たせる必要があります。他の値を変更する前に、属性の一部の値を削除 または消去しなければならない場合があります。 VPlexcli:/clusters/cluster-1/connectivity/wan-com/port-groups/ip-port-group-3> cd subnets/ VPlexcli:/clusters/cluster-1/connectivity/wan-c
/connectivity/local-com/ local ロール コンテキストには、現在のクラスター内のダイレクター間通信に関する構成情報が含まれています。 ローカルの役割には、関連づけられたプロパティはありません。 バックエンド ネットワークの管理とモニタリング 高可用性のために、各ダイレクターには各ストレージ ボリュームへのパスを複数割り当てる必要があります。ネットワークの混雑 状態やアレイの問題といった環境の問題は、これらのパスの可用性とパフォーマンスに影響を与える可能性があります。詳細につ いては、 ［メトロ ノード向けのベスト プラクティス ドキュメント］を参照してください。メトロ ノードは各バックエンド IT Nexus のレイテンシーを監視しますが、バックエンド パスのパフォーマンスを低下させる可能性があります。メトロ ノードには、パフォ ーマンス インパクトを制限するためのメカニズムがいくつかあります。 高レイテンシーによるバックエンド IT Nexus のサービス停止 ITL（IT Nexus 上のイニシエーター-ターゲット-LUN）における I/O の完了に 1 秒よりも時間がかか
ディレクトリ構造 ディレクトリーの組織は、ツリー構造になっています。ディレクトリー最上部のエントリーは、ルート エントリーと呼ばれていま す。通常、このエントリーはディレクトリーを所有する組織を表しています。 図 4. LDAP ディレクトリーの構造 LDAP の構成については、メトロ ノードの SolVe Desktop を参照してください。 例（ldapsearch コマンド） ディレクトリー サーバーの属性マッピングの値を確認するには、ldapsearch コマンドを使用します。 ● 特定の組織単位の下に存在するユーザーを決定するには、次のようにします。 service@ManagementServer:~> /usr/bin/ldapsearch -x -LLL -l 30 -H ldap://10.31.50.
cn: dev1 objectClass: top objectClass: person objectClass: organizationalPerson objectClass: posixAccount uid: dev1 loginShell: /bin/bash homeDirectory: /u/v/x/y/dev1 uidNumber: 50000 gidNumber: 80000 WAN ネットワークの構成 59
9 コンシステンシー グループ この章では、メトロ ノード コンシステンシー グループを管理および操作する方法について説明します。 トピック： • • • • メトロ ノード コンシステンシー グループの概要 コンシステンシー グループのプロパティ コンシステンシー グループの管理 コンシステンシー グループの操作 メトロ ノード コンシステンシー グループの概要 メトロ ノード コンシステンシー グループは、各ボリュームを集約します。これにより、グループ全体でプロパティの共通セットを 適用できます。 図 5.
図 6.
図 7.
図 8.
● 1 個のクラスターにストレージを持ち、グローバルな可視性を持つボリュームのみを含むようにコンシステンシー グループを構成 する。 ● 両方のクラスターで、レッグで分散されたボリュームのみを含むようにコンシステンシー グループを構成する。 コンシステンシー グループの可視性がクラスターに設定されている場合、コンシステンシー グループはクラスターの/clusters/ cluster-n/consistency-groups コンテキストの下に表示されます。 メモ: 指定したコンシステンシー グループのコンテキストは、コンシステンシー グループの可視性プロパティにそのクラスター が含まれている場合にのみ、クラスターのコンシステンシー グループの CLI コンテキストに表示されます。 通常のオペレーションでは、可視性プロパティを変更して 1 個のクラスターから両方のクラスターに拡張できます。 可視性プロパティを変更するには、 /clusters/cluster/consistency-groups/consistency-group コンテキストで set コマンドを使用します。コンシステンシー グループの「T
デタッチルール デタッチ ルールは、クラスター間リンクのアウテージが発生した場合に優先クラスターを自動選択するコンシステンシー グループの ポリシーです。 メトロ ノードの Metro 構成には、次の 2 種類のコンシステンシー グループ デタッチ ルールがあります。 ● no-automatic-winner ：コンシステンシー グループは優先クラスターを選択しません。 ● winner cluster-name delay seconds ：クラスター間リンクのアウテージが delay で指定された秒数より長く続く場合、 cluster-name で指定されたクラスターが優先クラスターとして認定されます。 コンシステンシー グループにデタッチ ルールが構成されている場合、そのルールはコンシステンシー グループ内のすべてのボリュ ームに適用され、個別のボリュームに適用されるあらゆるルールセットより優先されます。 このプロパティは、ローカル コンシステンシー グループには適用されません。 デフォルトでは、コンシステンシー グループに対して構成されている特定のデタッチ ルールはありません。その代わり、両方のク
Auto-resume-at-loser クラスター間リンクが障害後に修復されたときに、劣勢クラスターが I/O を自動的に再開するかどうかを決定します。 リンクが復元されると、劣勢クラスターは、優先クラスター上のデータが異なることを検出します。劣勢クラスターでは、優先クラ スターのデータを突然変更するか、I/O の中断を続けるかを決定する必要があります。 デフォルトでは、auto-resume は有効になっています。 通常、このプロパティを false に設定しておくことで、管理者は休止してアプリケーションを再起動する時間を得ることができま す。そうでないと、ホストのキャッシュ内のダーティー データと、優先クラスターが書き込みを行っていたディスク上のイメージに 整合性がなくなる可能性があります。ホストがダーティー ページのフラッシュを順番どおりに行っていない場合、データ イメージ が破損している可能性があります。 クラスター相互接続で使用されるコンシステンシー グループに対して、このプロパティを true に設定します。この場合、優先ク ラスターは常にホストに接続されており、シーケンスのデリバリーを回避する
コンシステンシー グループの管理 メモ: コンシステンシー グループの作成および管理における重要なベスト プラクティスは、コンシステンシー グループとアプ リケーションの間に 1 対 1 の関係を構築することです。アプリケーションに必要なすべてのボリューム（それらのボリュームの み）を、単一のコンシステンシー グループに配置する必要があります。 コンシステンシー グループの作成 コンシステンシー グループを作成する前に、その使用方法について次の点を考慮してください。 このタスクについて ● 仮想ボリュームの基盤となるストレージが配置されているクラスターについて考慮してください。ボリュームが両方のクラスタ ーに存在している場合は、storage-at-cluster プロパティを cluster-1,cluster-2 に設定します。 ● 追加される仮想ボリュームの可視性について考慮してください。 仮想ボリュームやコンシステンシー グループのプロパティの中には、コンシステンシー グループに追加できるボリュームを制限する ものや、コンシステンシー グループのプロパティの変更を妨げるものがあります。 例えば、コン
注意: コンシステンシー グループの CLI コンテキストは、コンシステンシー グループに visibility があるクラスターでのみ 表示されます。visibility がクラスター 2 のみを含むようにクラスター 1 から設定されている場合、クラスター 1 では、コン システンシー グループの CLI コンテキストは表示されず、クラスター 2 からのみ表示できます。 コンシステンシー グループの visibility プロパティを両方のクラスターに対して設定するには、次のようにします。 VPlexcli:/clusters/cluster-1/consistency-groups> set TestCG::visibility cluster-1,cluster-2 コンシステンシー グループの visibility プロパティをクラスター 1 に対して設定するには、次のようにします。 VPlexcli:/clusters/cluster-1/consistency-groups> set TestCG::visibility cluster-1 コンシステンシー グループの visibility プロ
手順 1. 次のように、ターゲット コンシステンシー グループのコンテキストにアクセスします。 VPlexcli:/> cd clusters/cluster-1/consistency-groups/TestCG 2. 次のように consistency-group list-eligible-virtual-volumes コマンドを使用して、コンシステンシー グループに 追加できる仮想ボリュームを表示します。 VPlexcli:/clusters/cluster-1/consistency-groups/TestCG> consistency-group list-eligiblevirtual-volumes [TestDDevice-1_vol, TestDDevice-2_vol, TestDDevice-3_vol, TestDDevice-4_vol, TestDDevice-5_vol] 3.
単一のコマンドで複数の仮想ボリュームを削除するには、次のようにボリュームをコンマで区切ります。 VPlexcli:/> consistency-group remove-virtual-volumes /clusters/cluster-1/virtual-volumes/ TestDDevice-2_vol, /clusters/cluster-1/virtual-volumes/TestDDevice-3_vol --consistencygroup /clusters/cluster-1/consistency-groups/TestCG 次のように、ターゲットのコンシステンシー グループのコンテキストから仮想ボリュームを 2 個削除します。 VPlexcli:/clusters/cluster-1/consistency-groups/TestCG> remove-virtual-volumes TestDDevice-2_vol, TestDDevice-3_vol 3.
pattern. virtual-volumes visibility pattern. Read-only. Takes a list with each element being a 'cluster' context or a context プロパティの現在の設定を表示するには、次のようにします。 VPlexcli:/> set /clusters/cluster-1/consistency-groups/TestCG::cache-mode ターゲット コンシステンシー グループのデフォルト値を表示するには、次のようにします。 VPlexcli:/clusters/cluster-1/consistency-groups/TestCG> set --default attribute default-value -------------------- ----------------active-clusters No default value. cache-mode synchronous. detach-rule No default value.
手順 1. 次のように ll コマンドを使用して、コンシステンシー グループに適用されている現在のデタッチ ルール（ある場合）を表示し ます。 VPlexcli:/clusters/cluster-1/consistency-groups/TestCG2> ll Attributes: Name Value -------------------- ---------------------active-clusters [] cache-mode synchronous detach-rule . . . 2.
Context --------------------------------------------/clusters/cluster-1/consistency-groups/TestCG Do you wish to proceed? (Yes/No)Yes コンシステンシー グループのコンテキストからコンシステンシー グループを削除するには、次のようにします。 VPlexcli:/clusters/cluster-1/consistency-groups> destroy TestCG WARNING: The following items will be destroyed: Context --------------------------------------------/clusters/cluster-1/consistency-groups/TestCG Do you wish to proceed? (Yes/No)Yes コンシステンシー グループのプロパティの表示 コンシステンシー グループのプロパティを表示できます。 すべてのクラスター上のコンシステンシー グループの名前
winner . . .
recoverpoint-enabled false storage-at-clusters [cluster-1, cluster-2] virtual-volumes [dd1_vol, dd2_vol] visibility [cluster-1, cluster-2] Contexts: advanced recoverpoint ● ls コマンドは、コンシステンシー グループ cg1 が一時停止しており、クラスター間リンクのアウテージ中にクラスター 2 がリン クを停止しているクラスターだと認定された後、クラスター 2 が requires-resume-at-loser になっていることを示してい ます。 ● resume-at-loser コマンドでクラスター 2 の I/O を再開できます。 ● ls コマンドにより作動ステータスの変更が表示されます。 VPlexcli:/clusters/cluster-1/consistency-groups/cg1> ls Attributes: Name Value ------------------- ----------------------
表 11.
表 11.
クラスター間リンクが復元されると、クラスターは I/O が独立して行われたことを確認します。データ イメージを同期するための ソースとして使用される、優先クラスターを選択するまで、I/O は両方のクラスターで継続します。 次の例では、クラスター間リンクのアウテージ中に両方のクラスターで I/O が再開されます。クラスター間リンクを復元すると、2 個のクラスターが接触し、互いに接続されていないことを確認して I/O を実行します。 手順 1.
ロールバック後の I/O の再開 このタスクについて そのデータがない場合、優先クラスターのデータ イメージの整合性が失われます。この優先度で I/O を再開するには、優先するデー タ イメージを、クラスターが最後に同意した時点までロール バックする必要があります。 これにより、データ イメージが突然変化する可能性があります。 多くのアプリケーションでは、突然のデータ変更に対応できないため、I/O をロールバックして再開するには手動による操作が必要 です。 この遅延により、管理者は、データ イメージを変更する前にアプリケーションを停止する可能性があります。データ イメージは、 優先クラスターが選択されるとすぐにロール バックされます（手動で、またはデタッチ ルールに従って自動的に行われます）。 resume-after-rollback コマンドは、アプリケーションのリカバリーの準備ができていることを確認します（これには、アプリケーシ ョンの障害および/またはホストの再起動が含まれる場合があります）。 メモ: 影響を受けたアプリケーションのホストを再起動することをお勧めします。 手順 1.
リンクの停止しているクラスターでの I/O の再開 クラスター間リンクのアウテージ中に、優先クラスターである 2 個のクラスターのいずれかで I/O を再開できます。 このタスクについて 劣勢クラスターでは、I/O が一時停止したままになります。 クラスター間リンクがリストアされると、優先クラスターと劣勢クラスターが再接続されます。また、劣勢クラスターは、優先クラ スターがリンクなしで I/O を再開したことを検出します。 明示的に構成されていない限り、劣勢クラスター上では I/O は一時停止されたままです。これにより、劣勢クラスターのアプリケ ーションは、突然のデータ変更が発生するのを防ぎます。 遅延により、アプリケーションをシャット ダウンすることができます。 アプリケーションを停止した後、consistency-group resume-at-loser コマンドを使用して次の操作を実行します。 ● 劣勢クラスター上のデータ イメージを、優先クラスター上のデータ イメージに再同期する。 ● I/O 操作のサービスを再開する。 その後、劣勢クラスターでアプリケーションを安全に再開できます。 劣勢クラスタ
Contexts: advanced recoverpoint デバイスの再構築中に、作動ステータスに rebuilding-across-clusters が表示されることがあります。 読み取り専用属性の設定 SRDF R2 デバイス（レプリカ）は、アレイで管理されるビジネス継続性ボリューム（BCV）の一例です。これらのボリュームが含 まれているコンシステンシー グループでは、set コマンドを使用して、コンシステンシー グループを読み取り専用に設定できます。 このタスクについて 読み取り専用属性が true の場合は、システムによってコンシステンシー グループ内の仮想ボリュームへの書き込み操作が阻止され ます。読み取り専用コンシステンシー グループ内の仮想ボリュームはローカルである必要があります。また、各仮想ボリュームを単 一のストレージ ボリュームにマップする必要があります（例：スライシングのないローカル RAID 0）。 トポロジーが無効な仮想ボリュームを、読み取り専用コンシステンシー グループに追加することはできません。consistencygroup add-virtual-volumes コマ
10 パフォーマンスおよび監視 この章では、RPO/RTO と、パフォーマンス モニターを作成および操作する手順について説明します。 トピック： • • • • • • パフォーマンスの概要 パフォーマンス監視の概要 CLI を使用したパフォーマンス監視 ポートのモニタリング 統計情報 統計表 パフォーマンスの概要 この章では、メトロ ノード システムのパフォーマンスに関連した次のトピックについて説明します。 ● 構成：パフォーマンスを最大化し、目標リカバリー ポイント（RPO）と目標リカバリー時間（RTO）を管理するための変更可能 なパラメーター。 ● モニタリング：メトロ ノードのパフォーマンスを監視し、問題を特定して診断するためのツールと方法。 RPO と RTO 目標リカバリー ポイント（RPO）：RPO はストレージ システムの障害点と、ストレージ システムがお客様のデータをリカバリーで きると想定される過去の時点までの時間のインターバルです。 RPO は、障害後にアプリケーションに許容されるデータ ロス量の上限でもあります。RPO の値は、使用されるリカバリの手法によ って大きく異なります
メモ: メトロ ノード向けの Unisphere の場合、パフォーマンスの統計情報はクラスターごとに表示されます。Metro 構成内にあ る両方のクラスターの統計情報を表示するには、両方のクラスターに接続します。 カスタム モニター CLI を使用してカスタム モニターを作成すると、選択したターゲットの選択した統計情報を収集して表示できます。 「CLI を使用したパフォーマンス監視」参照してください。 永続モニター GeoSynchrony には、パフォーマンス統計情報の標準セットを 30 秒ごとに収集する永続モニターが含まれています。永続モニター は、メトロ ノードのダイレクターと仮想ボリュームのパフォーマンスに関連する統計情報を収集します。 永続モニター ファイルは collect-diagnostics の一環として収集されます。Collect-diagnostics はクラスターごとに行われる ため、Metro 構成では両方のメトロ ノード管理サーバーからコマンドを実行します。 永続モニターの出力は、ベースの collect-diagnostics zip ファイル内の smsDump_date.
図 9.
● ［仮想ボリューム帯域幅チャート］ ：仮想ボリュームの読み取りおよび書き込みの総帯域幅（KB/s または MB/s）を、時間ベース のビューで表示します。通常、帯域幅（KB/s または MB/s とも呼ばれる）は大きなブロックの I/O（64KB 以上の I/O 要求）に 関連付けられています。 ● ［フロントエンド ポート ダッシュボード］ ：すべてのメトロ ノード フロントエンド ポートのパフォーマンス メトリックを表示し ます。ダッシュボードは履歴データを提供しませんが、5 秒ごとに更新され、過去 5 秒間のデータを表示します。 メトロ ノード CLI を使用したパフォーマンス監視 パフォーマンスの問題を診断するのに役立つカスタム モニターを作成するには、CLI を使用します。 次の 2 個の CLI オブジェクトが、パフォーマンス統計を収集して表示します。 ● monitors：指定したターゲットから指定したインターバルで指定した統計を収集します。 ● monitor sinks：出力を希望のデスティネーションに送ります。モニター シンクにはコンソール、ファイル、またはその 2 つの組 み合わせが
モニターごとに指定するターゲットのタイプは 1 種類だけにします。例えば、ポートとストレージ ボリュームの両方をターゲッ トとして含むモニターを作成することはできません。 2. モニターで統計情報を収集する頻度を決定します。 3. monitor create コマンドを使用してモニターを作成します。 4. monitor add-sink コマンドを使用して、1 個または複数のシンクをモニターに追加します。 ● メトロ ノード管理コンソールにパフォーマンス データを送信するコンソール シンクを追加します。 ● 指定したファイルにパフォーマンス データを送信するファイル シンクを追加します。 5. 各ダイレクターに対して、手順 3 と 4 を繰り返します。 6.
特定のダイレクターのローカル COM のレイテンシーを監視するパフォーマンス モニターは、次のように作成します。 VPlexcli:/> monitor create --name local-cluster --stats "com-cluster-io.*" --director director-1-1-A --targets "/clusters/cluster-1" リモート クラスターへのレイテンシーを監視するパフォーマンス モニターは、次のように作成します。 VPlexcli:/> monitor create --name remote-cluster --stats "com-cluster-io.
ファイル シンクを追加して指定された場所に出力を送信するには、次のようにします。csvfile: VPlexcli:/monitoring/directors/director-1-1-A/monitors> monitor add-file-sink director-1-1-A_stats --file /var/log/VPlex/cli/director_1_1_A.
lu.write,fe-lu.write-lat,fe-lu.ops --targets /clusters/cluster-1/virtual-volumes/ polyvol_e4_extent_Symm0487_393 Successfully created 1 monitor(s) out of 1.
DR1_C1-C2_1gb_dev16_vol, DR1_C1-C2_1gb_dev17_vol, DR1_C1-C2_1gb_dev18_vol, DR1_C1-C2_1gb_dev19_vol, ... (1300 total) Contexts: Name Description ----- -----------------------------------------------------------------------sinks Contains all of the sinks set up to collect data from this performance monitor.
set コマンドを使用して、モニターの自動ポーリングを無効にするか、変更します。 次の例では、 ● set コマンドは period 属性を 0 に変更し、自動ポーリングを無効にします ● ll コマンドにより変更が表示されます。 VPlexcli:/monitoring/directors/director-2-1-B/monitors/director-2-1-B_TestMonitor> set period 0 VPlexcli:/monitoring/directors/director-2-1-B/monitors/director-2-1-B_TestMonitor> ll Attributes: Name Value --------------- -------------------------------------------------------------average-period bucket-count 64 bucket-max bucket-min bucket-width collecting-data false firmware-id 4 idle-for 5.
例： VPlexcli:/> monitor collect /monitoring/directors/director-2-1-B/monitors/director-2-1B_TestMonitor Source: Time: director.be-ops (counts/s): . . .
SMTP: x.x.x.x Local-only: False 2. 管理サーバーの再起動時または再開時にスクリプトが再開されるようにするには、この手順で示されているように、/var/log/ VPlex/cli directory にある VPlex-init ファイルに対し、 ［Starting the script］に戻るスクリプトを開始するために使用 するコマンドを追加して、データ保全を追加できます。vi エディターを使用して、スクリプトの開始コマンド ライン を/var/log/VPlex/cli/VPlexcli-init ファイルの末尾に追加します。 Sample output: service@ManagementServer:/var/log/VPlex/cli> vim VPlexcli-init #------------------------------------------------------------------------------#- (C) 2007-2010 EMC Corporation. All rights reserved.
"loss_of_sig": 45, "reset": 5 } d. config.json ファイルに変更を加えた後は、port-monitor スクリプトを再起動する必要があります。 VPlexcli:/> port-monitor restart VPlexcli:/> port-monitor status Status: running with the following parameters: Emails: joe@dell.com <<< this will only show e-mail addresses if configured SMTP: x.x.x.x Local-only: False Threshold config: {u'lr-remote': 5, u'crc-errors': 50, u'invalid-transmissionword': 500, u'link-failure': 10, u'loss-of-signal': 45, u'loss-of-sync': 60} ポート統計モニタリングの使用に関する情報 使用方法：6.2.
VPlexcli:/> port-monitor status Status: running with the following parameters: Emails: None SMTP: x.x.x.x Local-only: False Threshold config: None ### Restarting the monitor If you wish to restart a stopped monitor with the same parameters as before, run `portmonitor restart`. If you wish to use different options, use the `start` command documented above. ## Configuring the driver-specific thresholds The thresholds may be overridden by placing a JSON file at /var/log/VPlex/cli/port-stats-monitor/config.
スクリプトは、5 分経過したら（E メール サーバーをあふれさせないように）E メールを抑制するよう設計されています。この時点 では、1 時間に 1 回だけ報告が行われます。管理サーバーに接続するファームウェアには、E メールの送信が抑制された分を含むす べてのレポートが含まれています。 次の表には、監視対象となっている統計情報のリストを記載しています。監視対象は、ハードウェアのタイプ（VS2 または VS6） と GeoSynchrony のコード レベルによって異なります。スクリプトは、6.0 SP1（6.0.1.00.00.08）以降のコード レベルに適用できま すが、監視できるものは、基礎となる統計情報が利用できるかどうかに依存しています。次の添付（制限付き）セクションで、こ の表を拡大表示して参照してください。 ログ：ログ ファイル port-stats-monitor.log は、/var/log/VPlex/cli/ directory 内の管理サーバーにあります。この ログ ファイルは raw データを収集しています。grep コマンド[grep "back-end\|front-end\|
多くの統計情報では、ターゲットのポートまたはボリュームを指定する必要があります。monitor stat-list コマンドの出力に より、ターゲットの定義が必要な統計情報と、モニター作成時に必要なターゲットのタイプを特定できます。 図 10.
. . フロントエンドのパフォーマンス統計 メトロ ノードは、仮想ボリュームに細なパフォーマンス統計を収集します。これには主に、I/O サイズと LBA 情報を含む読み取り と書き込みの統計情報が含まれます。このデータを使用することで、メトロ ノードにおける I/O パフォーマンスのさまざまな問題 を特定し、解決することができます。 メトロ ノードでは、この機能がデフォルトで有効になっています。収集された統計情報は、/var/log/VPlex/cli/フォルダーの fe_perf_stats_.log ファイルで確認できます。このファイルには、次の詳細情報が含まれています。 表 13.
● XCOPY の統計情報 ● ホスト イニシエーターの統計情報 表 14. バックエンド Fibre Channel ポート（be-prt）の統計情報 統計情報 タイプ be-prt.read バックエンド ポートの読み 指定した FC ポート経由で読み取られたバイト数。 取り タイプ：カウンター、ユニット：バイト/ 秒、実引数：ポート番号 be-prt.write タイプ：カウンター、ユニット：バイト/ 秒、実引数：ポート番号 説明 バックエンド ポートの書き 指定した FC ポート経由で書き込まれたバイト数。 込み 表 15. ダイレクターの統計情報 統計情報 タイプ 説明 director.async-write バックエンドの書き込み 非同期書き込み数（KB/秒）。 director.be-aborts バックエンドの処理 ダイレクターのバックエンド ポートを経由して中止され た I/O 操作の数。 director.be-busies バックエンドの処理 このダイレクター上のビジー通知の数。 director.
表 15. ダイレクターの統計情報 （続き） 統計情報 タイプ 説明 director.
表 15. ダイレクターの統計情報 （続き） 統計情報 タイプ 説明 director.per-cpu-busy CPU のビジー状態 ダイレクター内の各 CPU を合計した使用率（ユーザーおよ びシステム）。 director.msg-send-ops 処理の数 このダイレクターから送信されたメッセージの総数。 director.msg-max-lat 最大レイテンシー このダイレクターから送信されたメッセージの最大レイ テンシー。 director.msg-min-lat 最小レイテンシー このダイレクターから送信されたメッセージの最小レイ テンシー。 director.msg-avg-lat 平均レイテンシー このダイレクターから送信されたメッセージの平均レイ テンシー。 タイプ：読み取り、ユニット：パーセンテ ージ、実引数：なし 表 16. フロントエンド ダイレクター（fe-director）の統計情報 統計情報 タイプ 説明 fe-director.
表 17.
表 18.
表 19. リモート RAID（ramf）の統計情報 （続き） 統計情報 タイプ 説明 インポートをした処理 リモート ターゲットに関係なく、特定のダイレクターによ って要求された処理の数。 タイプ：カウンター、ユニット：バイト/ 秒、実引数：なし ramf.imp-op タイプ：カウンター、ユニット：カウン ト/秒、実引数：なし ramf.imp-rd タイプ：カウンター、ユニット：バイト/ 秒、実引数：なし ramf.imp-wr タイプ：カウンター、ユニット：バイト/ 秒、実引数：なし ramf.imp-rd-avg-lat タイプ：期間平均、ユニット：マイクロ 秒、実引数：なし ramf.
表 21. 仮想ボリュームの統計情報 （続き） 統計情報 タイプ 説明 virtual-volume.ops ボリューム オペレーシ ョン 指定した仮想ボリュームの I/O 操作の総数。 ボリュームの読み取り 指定した仮想ボリュームの読み取りの数（バイト）。 ボリュームの書き込み 指定した仮想ボリュームの書き込みの数（バイト）。 タイプ：カウンター、ユニット：カウン ト/秒、実引数：ボリューム ID virtual-volume.read タイプ：カウンター、ユニット：バイト/ 秒、実引数：ボリューム ID virtual-volume.write タイプ：カウンター、ユニット：バイト/ 秒、実引数：ボリューム ID 表 22. IP WAN COM（ip-com-port）の統計情報 統計情報 タイプ ip-com-port.recv-pckts カウンター、ユニット： この IP WAN COM ポート上で UDP を使用して受信したパ カウント/秒、実引数：ポ ケット数。 ート名 ip-com-port.
表 23. IP 混雑状態制御の統計情報 統計情報 説明 ip-congestion-control.ip-wan-cc-rtt TCP により維持されているラウンド トリップ時間（マイクロ秒）。 ip-congestion-control.ip-wan-cc-rttvar 最も逸脱した RTT（マイクロ秒）。 ip-congestion-control.ip-wan-recv-bytes TCPCOM パス上で受信したバイトの総数。 ip-congestion-control.ip-wan-recv-cnt TCPCOM パス上で受信したパケットの総数。 ip-congestion-control.ip-wan-retx-cnt TCP 再転送の総数。 ip-congestion-control.ip-wan-send-bytes TCPCOM パス上で送信したバイトの総数。 ip-congestion-control.ip-wan-send-cnt TCPCOM パス上で送信したパケットの総数。 表 24.
表 26. COM パスの統計情報 統計情報 説明 com-path.ping-count 送信された ping パケットの数。これらはレイテンシーの計算をサポートする ために使用されます。 com-path.ping-late 非常に時間がかかった ping パケットの数。 com-path.ping-lost 喪失した ping パケットの数。 com-path.posted-bytes ポストされた転送バイト数（転送のためにキューに登録されているバイト 数）。 com-path.posted-send-ack ポストされた ACK バッファーの数（転送のためにキューに登録されている ACK バッファー）。 com-path.posted-send-ctl ポストされた制御バッファーの数（転送のためにキューに登録された制御バ ッファー）。 com-path.rtt-avg パスに沿って移動するデータの平均ラウンド トリップ時間。 com-path.rtt-max パスに沿って移動するデータの最大ラウンド トリップ時間。 com-path.
表 27. COM エンドポイントの統計情報 （続き） com-endpoint.rx-credits 受信クレジットの数。 com-endpoint.tx-posted-bytes ポストした転送済みバイト数（転送予定のキュー登録済みバイ ト数）。 表 28. XCOPY の統計情報 統計情報 説明 fe-director.xcopy-avg-lat 特定のダイレクターすべてのフロントエンドが受信した XCOPY の処理 における平均レイテンシー（マイクロ秒）。永続モニタリングの一環とし て自動収集されます。収集された値は、メトロ ノード管理サーバーにある 永続モニタリング ファイル（/var/log/VPlex/cli/director-[1|2]-[1|2]-[A| B]_PERPETUAL_vplex_sys_perf_mon.log）で確認できます fe-director.xcopy-ops 特定のダイレクターで完了した 1 秒あたりの XCOPY 操作の数。 fe-lu.
A アクティブ-パッシブ ストレージ アレイを使用 したメトロ ノード トピック： • • • • アクティブ-パッシブ アレイ ALUA モードが有効なアレイ 論理ユニットのフェールオーバーの実行 論理ユニットのフェールバック アクティブ-パッシブ アレイ 通常、アクティブ-パッシブ アレイには 2 個のコントローラーがあり、一連のターゲット ポート経由で論理ユニット（LU）へのアク ティブ-パッシブ アクセスを提供します。これらのポートのアクセス タイプは、アクティブ（ACT）またはパッシブ（PAS）です。 アクティブは I/O に使用されます。パッシブを I/O に使用することはできません。論理ユニットへのアクティブ パスが失われた 場合、イニシエーター（メトロ ノード）は、ベンダー固有の SCSI コマンドをアレイに送信することでパッシブ パスをアクティブ化 し、I/O を実行することができます。 特定の論理ユニットに対してアクティブなターゲット ポートがあるコントローラーは、その論理ユニットのアクティブ（ACT）コン トローラーと呼ばれます。特定の論理ユニットに対してパッシブなターゲット ポート
状態を変更することによって、論理ユニットのフェールオーバーを開始します。コマンドに対してターゲット デバイスから受信し た応答によって、論理ユニットのフェールオーバーの成功が左右されます。 アレイ上の特定の論理ユニットから、アクティブな特定のターゲット コントローラーへのフェールオーバーが開始されると、メトロ ノード ファームウェア イベント apf/3 が発生します。アレイ上の特定の論理ユニットからアクティブな特定のターゲット コント ローラーへのフェールオーバーが成功または失敗すると、メトロ ノード ファームウェア イベント apf/4 が生成されます。 例： apf/3 Failover initiated for logical unit VPD83T3:6006016015a0320061d7f2b300d3e211 on array EMC~CLARiiON~FNM00124500474 to target controller FNM00124500474.SPA as active.
索引 記号 ALUA モードが有効なアレイ 109 CAW：CompareAndWrite 17 CAW システムのデフォルト設定の表示 18 CAW：ストレージ ビューの設定の表示 18 CAW：ストレージ ビューに対する有効化/無効化 18 CAW：デフォルトで有効/無効 19 CAW：統計情報 19 CLI：ログしきい値の設定;ログしきい値、設定;設定：CLI のログ しきい値 7 CLI ワークスペース：ウィンドウ幅の設定 8 CLI ワークスペース：コンソール ログ 7 find 8 search 8 UNMAP 28 WAN ポート 53 WAN ポート：CLI コンテキスト 53 WAN ポート：Metro 構成ルール 53 WAN ポート：サブネット コンテキスト 55 WAN ポート：port-groups コンテキスト 54 WriteSame：システムのデフォルトとして有効/無効 21 WriteSame：ストレージ ビュー設定の表示 20 WriteSame：ストレージ ビューに対する有効化/無効化 20 WriteSame：ディスプレイ設定 20 WriteSame：統計情報 21
パフォーマンス監視：モニターの作成 86 パフォーマンス監視：モニターの表示 88 パフォーマンス監視：例：10 秒、ダイレクター 86 パフォーマンス監視：例：管理サーバーへの CAW 統計情報の送 信 86 パフォーマンス監視：例：デフォルト期間、ターゲットなし 86 パフォーマンス監視：例：ポートレベルの WAN 統計情報 86 パフォーマンス監視：例：リモート クラスターのレイテンシー 86 パフォーマンス監視：例：ローカル COM のレイテンシー 86 パフォーマンス モニター：作成 85 表示：モニター 88 ファイル ローテーション 85 フロントエンドのパフォーマンス統計 98 ポート グループ 53 port-groups コンテキスト 54 ボリュームセット 仮想ボリュームの追加 67 ボリュームの拡張：概要 32 ボリュームの拡張：仮想ボリュームの拡張 33 ボリュームの拡張：仮想ボリュームの拡張：ストレージボリュー ム拡張メソッド 34 ボリュームの拡張：制限 32 ボリュームの拡張：ボリューム拡張メソッドの判断 32 ボリュームの拡張：ボリューム拡張メソッドの判断：CLI の使用 3
