Dell EMC ストレージ システム metro ノード アプライアンス管理者ガイド 7.
メモ、注意、警告 メモ: 製品を使いやすくするための重要な情報を説明しています。 注意: ハードウェアの損傷やデータの損失の可能性を示し、その危険を回避するための方法を説明しています。 警告: 物的損害、けが、または死亡の原因となる可能性があることを示しています。 © 2021 Dell Inc. その関連会社。All rights reserved.（不許複製・禁無断転載）Dell、EMC、および Dell または EMC が提供する製品及びサービスにか かる商標は Dell Inc.
目次 章 1: はじめに..................................................................................................................................7 章 2: CLI ワークスペースとユーザー アカウント.................................................................................. 9 CLI ワークスペースの構成.................................................................................................................................................9 コンソール ログのしきい値の設定...............................................................................
章 6: ストレージのプロビジョニング................................................................................................ 33 プロビジョニングの概要................................................................................................................................................. 33 EZ プロビジョニングを使用したストレージ プロビジョニング............................................................................ 33 仮想ボリュームのシン特性の変更............................................................................................................
メトロ ノード ハードウェアおよび WAN ポート...................................................................................................... 56 Metro over IP WAN ポートの構成ルール......................................................................................................................56 ポート グループ........................................................................................................................................................... 56 CLI コンテキスト........................................................
モニターの作成............................................................................................................................................................ 89 モニター シンクの追加/削除.................................................................................................................................... 90 モニターの削除.............................................................................................................................................................91 ポーリングの有効化/無効化/変更............
1 はじめに 製品ラインを改善するための努力の一環として、Dell EMC ではソフトウェアおよびハードウェアのリビジョンを定期的にリリース しています。そのため、このドキュメントで説明されている機能の中には、現在お使いのソフトウェアまたはハードウェアのバー ジョンによっては、サポートされていないものもあります。製品のリリース ノートには、製品の機能に関する最新情報が掲載され ています。 製品が正常に機能しない、またはこのマニュアルの説明どおりに動作しない場合には、Dell EMC のテクニカル サポート プロフェ ッショナルにお問い合わせください。 メモ: このマニュアルには、発行時点で正確だった情報が記載されています。Dell EMC オンライン サポート https:// www.dell.
表 1. 表記規則 （続き） ● パス名、ファイル名、プロンプト、構文 ● コマンドおよびオプション モノスペース斜体 変数に使用します。 モノスペース太字 ユーザーによる入力値を示します。 [] 角括弧は、オプション値を示します。 | 縦棒は、選択肢を示し、"または"を意味します。 中括弧内は、ユーザーが指定する必要のある内容を示します （例：x、y、z） 。 {} 省略記号は、例の中で省略した必須ではない情報を示します。 ... 問い合わせ先 Dell EMC のサポート情報、製品情報、ライセンス情報は、次の場所で入手できます。 製品情報 Dell EMC 製品に関するドキュメント、リリース ノート、ソフトウェア アップデート、情報については、Dell EMC オンライン サポ ート https://www.dell.
2 CLI ワークスペースとユーザー アカウント この章では、コマンド ライン インターフェイス（CLI）を使用して CLI ワークスペースを構成し、ユーザー アカウントを管理する 方法について説明します。 トピック： • CLI ワークスペースの構成 CLI ワークスペースの構成 ワークスペースは、CLI セッションの表示と作動です。このセクションで説明する手順を使用して、コマンドの出力とコンソール に送信されるログ メッセージのレベルを制御し、現在の CLI セッションのコマンド履歴を検索できます。 メモ: VPlexcli を開始するために、ユーザー名とパスワードは必要なくなりました。自動スクリプトによってユーザー名または パスワードが入力されていないことを確認してください。 コンソール ログのしきい値の設定 コンソール ロガーには、コンソールのダイレクターから受信したメッセージが表示されます。 デフォルトでは、コンソールに緊急（レベル 0）メッセージのみが表示されます。 メッセージは 8 段階の重大度（0-7）に分類され、0 は最も重大です。 7：debug（デバッグレベルのメッセージ） 6：
ここで、n は 0-7 です。 メモ: しきい値は、重大度が高いまたは同等のメッセージをすべてフィルタリングします。 critical（2）以上（0 と 1）を表示するには、しきい値を 3 に設定します。 error（3）以上（0、1、2）を表示するには、しきい値を 4 に設定します。 ウィンドウ幅を 100 に設定 多くのコマンドから出力される列の幅は、80 を超えています。VPlexcli を実行しているコマンド ウィンドウを拡張し、幅を少なく とも 100 にしてください。 コンテキスト ツリーの検索 特定のパターンに一致するコンテキスト名とデータをコンテキスト ツリーで検索できます。 Find コマンドを使用したコンテキスト ツリーの検索 パターンに一致するすべてのコンテキストを検索するには、このコマンドを使用します。対話形式で呼び出すと、コマンドによっ てコンテキストが画面に出力されます。 パターンには、リテラル文字列またはワイルドカード文字を含む文字列を使用できます。対応している CLI ワイルドカード文字の リスト全体については、CLI 参照ガイドのトピック「ワイルドカード」を参照してくだ
3 メタ ボリューム この章では、VPlexcli を使用してメタデータとメタボリュームを管理する手順について説明します。 トピック： • • • • • • メタボリュームの概要 メタボリュームの移動 メタボリュームの名前の変更 メタボリュームの削除 メタボリュームの表示 メタボリュームの整合性の確認 メタボリュームの概要 metro ノードのメタデータには、仮想環境から物理環境へのマッピング、デバイスに関するデータ、仮想ボリューム、システム構 成の設定が含まれています。 メタデータは、キャッシュに保存され、メタ ボリュームと呼ばれる専用の外部ボリュームにバックアップされます。 メタボリュームは、システムのセットアップ中に作成されます。 クラスターの初回構成時には、メタボリュームをメトロ ノードに表示される最初のストレージにする必要があります。これによ り、メタボリュームが誤って上書きされるのを防ぐことができます。 メタボリュームが構成されると、メタデータへのアップデートは、メトロ ノード構成が変更される際に、キャッシュとメタボリュ ームの両方に書き込まれます。 バックアップ メタボリュームは、現在の
● 可能であれば、LUN0 上のデバイスを使用しないこと。LUN0 へのパスは、アレイが検出を通過するたびに削除および追加され ます。LUN0 が、デフォルトの LUN と、実際に使用するストレージがバックアップをした実際の LUN のどちらかになるためで す。 メタボリュームでは可用性が非常に重要です。メタボリュームはシステムのリカバリーに不可欠です。2 個以上のバックエンド アレイでメタボリュームのミラーリングをして、データ ロスが起こる可能性を排除することをお勧めします。メタボリュームのミ ラーリングを行うアレイを選択して、同時移行が必要ないようにしてください。 警告: 単一のストレージ アレイのボリュームを使用してメタボリュームを作成しないでください。単一のアレイのメタボリュ ームは高可用性構成ではなく、単一障害点となります。 すべてのメタボリュームへのアクセスが metro ノードから一時的に失われた場合、アクセスが回復すると、キャッシュ内の現在の メタデータがメタボリュームに自動で書き込まれます。 両方のメタボリュームへのアクセスが metro ノードから恒久的に失われた場合、メモリー内のメタデー
手順 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
表 2.
表 2.
4 システム管理 この章では、コールホーム通知の使用方法、イベント ログの場所、VAAI を使用したハードウェア アクセラレーションについて説 明します。 トピック： • • • • • • • コールホーム通知 イベント ログの場所 システム構成ログの場所 VAAI によるハードウェア アクセラレーション XCOPY を使用したコピー オーバーヘッドのオフロード メトロ ノード クラスターの名前の変更 LCD 前面パネルの設定 コールホーム通知 コールホーム通知の概要 コールホーム通知とは、重大な問題が発生した場合に、Dell EMC カスタマー サービスおよび/またはカスタマー サポートの担当者 に自動的に送信されるメッセージです。コールホーム通知により、Dell EMC では関連担当者がプロアクティブに連携し、構成済み の SRS ゲートウェイを使用して問題を解決できるようになります。 システム イベントには 4 個のレベルがあります。コールホーム通知が送信されるのは、次の 3 個のレベルに関してのみです。 表 3.
開始する前に コールホーム通知の構成を完了するには、次の情報が必要です。 ● Dell EMC へのコールホーム通知の転送に使用される SRS または SCG ゲートウェイの IP アドレス。SRS または SCG ゲートウ ェイをプライマリー接続アドレスとして使用します。 ● （オプション）プライマリー サーバー障害発生時に、Dell EMC へのコールホーム通知の転送に使用されるセカンダリーの SRS または SCG ゲートウェイ サーバーの IP アドレス（1 個以上）。これらのアドレスは、プライマリーの SRS または SCG ゲート ウェイ サーバーのアドレスとは別にする必要があります。 ● （オプション）コールホーム通知が配信された時に E メール メッセージを受信する必要のある担当者の E メール アドレス（1 個 以上）。 追加のドキュメント SupportAssist 構成コマンドの詳細については、「metro ノード アプライアンスの構成およびインストール ガイド」を参照してくだ さい。次の表に、各コマンドの役割を示しています。 コマンド 役割 vplex_system_config
Download of file(s) from MFT portal completed SHA256 checksum verification of downloaded file(s) in progress... File 'softwareWeekly.tar.gz' downloaded successfully from node '10.226.81.189' with checksum=47a08c12d4dddc30039fd0a86642b64c435e14f1d6a0c9ccfd83eff03ee7dfbd File 'log.txt' downloaded successfully from node '10.226.81.189' with checksum=0a9ee4b41f72f67c2abff8dce7a087e9ff270bd0ef0b1bb79b7c5e4855b6d8a3 File 'MFT_API_TEST/DummyFIle_test.docx' downloaded successfully from node '10.226.81.
2. メタデータ ファイル情報を使用して、ローカル ノードに存在するファイルを特定のノードにプッシュするには、次のコマンド を実行します。 service@director-1-1-a:~> ［/opt/dell/vplex/bin/supportassist_mft sync --metadata-file /home/service/mft/ metadata.json --nodes 10.226.81.190］ File 'softwareWeekly.tar.gz' with checksum 47a08c12d4dddc30039fd0a86642b64c435e14f1d6a0c9ccfd83eff03ee7dfbd copied to /home/ service/mft/ directory File 'log.
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）サポートも有効になります。 注意: Write Same（16）のデフォルトのテンプレートを無効にするには、すべての将来のビューで Write Same（16）が無 効になるように、すべての既存のビューに対する Write Same（16）を無効にして、Write Same（16）テンプレートを無 効にする必要があります。Write Same（16）のデフォルトのテンプレートを有効にするには、すべての将来のビューで Write Same（16）が有効になるように、すべての既存のビューに対する Write Same（16）を有効にして、Write Same （16）テンプレートを有効にする必要があります。 WriteSame（16）設定の表示 /clusters/cluster/exports/s
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 を使用したコピー オーバーヘッドのオフロード I/O のオーバーヘッドを最小化し、コピー処理のパフォーマンスを最大化するため、データ移動は（ホストベースのデータ コピー のような）サーバー レイヤーではなく、物理ストレージ レイヤーにできるだけ近い場所で行ってください。 メトロ ノードは VMware の X
XCOPY 統計情報の表示 メトロ ノードは、XCOPY 操作のパフォーマンスと頻度を追跡する統計情報を提供します。これらの統計情報は、フロントエンド で収集されます。 統計情報 、p. 99 を参照してください。 XCOPY モニターのセット アップ 永続モニタリングの一環として自動収集されないすべての統計情報については、モニターを手動で作成して、特定のメトロ ノード 仮想ボリューム上の XCOPY レイテンシーの統計情報を収集できます。 モニターを作成してファイル シンクを構成し、特定の fe-lu（メトロ ノード仮想ボリューム）の統計情報が、構成したファイルに 収集されるようにします。 次の例では、モニターの作成して、特定のボリューム（VAAI_Vol1_Device_vol）の fe-lu.
5 メトロ ノードにおけるシン サポート この章では、メトロ ノードによるシン対応機能のサポート方法について説明します。 トピック： • • • • メトロ ノードにおけるシン サポート シン プロビジョニング シン ストレージ管理 シンのミラーリングと移行 メトロ ノードにおけるシン サポート シン対応は、メトロ ノード仮想ボリュームをシン ボリュームとしてホストに提示する機能です。シン ボリュームにより、使用さ れるリソース量が割り当て済みの量よりもかなり少なくなるため、効率性が向上します。必要なリソースのみを提供することによ ってもたらされるこのメリットは、使用される仮想化テクノロジーのコストを上回るものです。シン サポートのあるストレージ ボリュームのストレージ ブロックを動的に解放できます。シン サポートにより、必要に応じて物理ブロックに 1 個以上の論理ブロ ックをマッピングすることができます。論理ブロックは、ストレージ アドレス スペース（論理ユニット容量）をホストに提供し ます。物理ストレージが論理ユニットに割り当てられるのは、論理ユニット使用時のみです。これにより、論理ユニットには、そ
シン移行 メトロ ノードは、シン デバイス上のデータ移動機能に対応しています。移行のソースまたはターゲットがシンでない場合や、ソ ースとターゲットが異なるストレージアレイ ファミリーに属している場合、メトロ ノード仮想ボリュームはシン プロパティを失 います。このような状況では、仮想ボリュームでシン ストレージ管理操作を行うことができません。移行が完了してコミットされ ると、仮想ボリュームはターゲット デバイスのシン機能を継承します。シン対応ストレージの移行に関する詳細については、「シ ン対応ストレージの移行」を参照してください。 次の表では、メトロ ノードによるシン対応機能のサポート方法について説明しています（メトロ ノードでアレイがシン対応であ るかどうかに基づいています）。 表 5.
○ 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 コマンドを発行したアドレスにマッピングを行うための使用可能ストレージ ブロックがない場 合に発生します。metro ノードは、このエラーに対し、ミラーリングをしたデバイスとミラーリングをしていないデバイスで異 なる処理を行います。 ミ
シン対応デバイスにシック ミラーを接続するために 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.
6 ストレージのプロビジョニング この章では、メトロ ノードの統合ストレージ プロビジョニングを使用したストレージのプロビジョニング方法を説明します。 トピック： • • • プロビジョニングの概要 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
7 ボリュームの拡張 この章では、仮想ボリュームを拡張する方法について説明します。 トピック： • • • 概要 ボリューム拡張メソッド 仮想ボリュームの拡張 概要 メトロ ノード仮想ボリュームはデバイスまたは分散デバイスに作成され、ストレージ ビューを通じてホストに提示されます。さ まざまな理由から、仮想ボリュームの容量拡張が必要になる場合があります。 ボリュームが拡張に対応している場合、メトロ ノードは拡張によって得られた容量を検出します。次に、使用できる拡張メソッ ド：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 度だけ再検出し、メトロ ノードにすべての拡張を強制
8 データ移行 この章では、データ移行と再構築について説明します。 トピック： • • • • • データ移行の概要 シン対応ストレージの移行 再構築の概要 1 回限りのデータ移行 バッチ移行 データ移行の概要 データ移行には次の 2 種類があります。 ● 1 回限りの移行：dm migration start コマンドが使用された時に、ただちにデバイスの移行を開始します。 ● バッチ移行：再使用できる移行計画ファイルを使用して、バッチ ジョブとして実行されます。単一のコマンドを使用して、デ バイスまたはエクステントの複数の移行を実行できます。 1 回限りの移行 1 回限りの移行には次の移行が含まれます。 ● デバイス移行：デバイスは 1 対 1 のマッピングが行われたデバイスか、エクステントまたは他のデバイスに構築された RAID 1 デバイスです。 デバイスの移行では、同じクラスター上のデバイス間、または異なるクラスター上のデバイス間でデータを移動します。デバ イス移行を使用すると、次の操作を実行できます。 ○ 異なる種類のアレイ間でデータを移行します。 ○ ホット ボリュームをより高速なアレイに
1. 2. 3. 4. 5. 移行計画の作成とチェックを行います（バッチ移行の場合のみ）。 移行を開始します。 移行の進行状況を監視します。 移行を中断、再開またはキャンセルします（オプション）。 移行をコミットします。コミットにより、ソース仮想ボリューム、デバイスがターゲットに転送されます。 システムによってデバイス上の仮想ボリュームにデフォルト名が割り当てられている場合、デバイス移行のコミットをすると、 仮想ボリュームの名前がターゲット デバイスにちなんだ名前に変更されます。 6.
表 6.
● シンからシック エクステントへの移行（対応仮想ボリュームなし）では、ソースが 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.
● シンからシック エクステントへの移行（対応仮想ボリュームなし）では、VPlexcli に、移行後にソースのシン機能が失われるこ とを示す警告が表示されます。 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 表 8.
このタスクについて アクティブな移行を一時停止して、ピーク トラフィック時にホスト 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 表 9. バッチ移行の概要 フィールド 説明 Processed....
バッチ移行のクリーニング デバイス移行のクリーニングでは、ソース デバイスのストレージ ボリュームまでが破棄されます。使用されなくなったストレー ジ ボリュームに対する要求は行われません。 このタスクについて デバイスの移行の場合のみ、オプションの--rename-target 引数を使用して、ターゲット デバイスの名前をソース デバイスに ちなんだ名前に変更します。ターゲット デバイスの名称変更時に、ターゲット デバイスにシステムの割り当てたデフォルト名が 付いていると、そのターゲット デバイスの上位にある仮想ボリュームの名前も変更されます。 名前を変更しないと、ターゲット デバイスはそのターゲット名を持ち続けるため、ボリュームとデバイス間の関係が明らかになら ない場合があります。 特定のバッチ移行のクリーニングを行うには、batch-migrate clean --file コマンドを使用します。 注意: このコマンドは、バッチ移行が削除されてしまう前に実行する必要があります。このコマンドでは、VPlexcli コンテキ スト ツリーにレコードのない移行のクリーニングを行うことはできません。 次の例では、
9 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
すべての port-groups には、member-port に関する各ダイレクターからの情報を提供する member-ports コンテキストが含まれて います。 IP port-groups には次のものが含まれます。 ● option-set コンテキストは、メンバー ポートに共通する構成オプションを記載しています。 ● subnet コンテキストは、IP ネットワーキングの構成オプションを記載しています。それぞれの役割に異なるネットワーキン グ ニーズがあるため、サブネット コンテキストにはさまざまなプロパティが含まれています。これらのサブネットは、関連付 けられている役割内で説明されています。 ● enabled ：個々のメンバー ポートの有効ステータスがまとめてあります。 メンバー ポート member-ports コンテキスト内のプロパティは、すべて読み取り専用です。 すべての port-groups には、ポート グループ内の各ダイレクターのポートをリスト表示する member-ports コンテキストが含まれて います。port-groups は、アクセス不可になったダイレクターの me
● ● ● ● ● mtu には 1024～9000 のバイト数を設定すること。 prefix には port-group のメンバー ポートの IP アドレスを含めること。 prefix にはクラスターアドレスを含めること。 prefix にはゲートウェイを含めること。 gateway はローカル クラスター上で一意のアドレスであること。 次の点に注意してください。 ● 削除されたアドレスはすべてのプレフィックスに含まれており、どのアドレスとも一致しません。 ● 削除されたプレフィックスには、すべてのアドレスが含まれています。 ● 特定のサブネット コンテキストに存在しないプロパティは、削除されたものと見なされます。 サブネットに変更を加えた場合は、その変更が検証され、このサブネットを使用するすべてのポートに適用されます。 port-group の再構成時には、複数の値で互いに整合性を持たせる必要があります。他の値を変更する前に、属性の一部の値を削除 または消去しなければならない場合があります。 VPlexcli:/clusters/cluster-1/connectivity/wan-com/port
/connectivity/local-com/ local ロール コンテキストには、現在のクラスター内のダイレクター間通信に関する構成情報が含まれています。 ローカルの役割には、関連づけられたプロパティはありません。 バックエンド ネットワークの管理とモニタリング 高可用性のために、各ダイレクターには各ストレージ ボリュームへのパスを複数割り当てる必要があります。ネットワークの混雑 状態やアレイの問題といった環境の問題は、これらのパスの可用性とパフォーマンスに影響を与える可能性があります。メトロ ノ ードは各バックエンド IT Nexus のレイテンシーを監視しますが、バックエンド パスのパフォーマンスを低下させる可能性がありま す。メトロ ノードには、パフォーマンス インパクトを制限するためのメカニズムがいくつかあります。 高レイテンシーによるバックエンド IT Nexus のサービス停止 ITL（IT Nexus 上のイニシエーター-ターゲット-LUN）における I/O の完了に 1 秒よりも時間がかかってしまう場合は、ITL と IT に より、ITL に許可されたコマンド制限を 5 から 1
ディレクトリ構造 ディレクトリーの組織は、ツリー構造になっています。ディレクトリー最上部のエントリーは、ルート エントリーと呼ばれていま す。通常、このエントリーはディレクトリーを所有する組織を表しています。 図 4. LDAP ディレクトリーの構造 LDAP の構成については、メトロ ノードの SolVe Desktop を参照してください。 例（ldapsearch コマンド） ディレクトリー サーバーの属性マッピングの値を確認するには、ldapsearch コマンドを使用します。 ● 特定の組織単位の下に存在するユーザーを決定するには、次のようにします。 service@ManagementServer:~> /usr/bin/ldapsearch -x -LLL -l 30 -H ldap://10.31.50.
objectClass: posixAccount uid: dev1 loginShell: /bin/bash homeDirectory: /u/v/x/y/dev1 uidNumber: 50000 gidNumber: 80000 62 WAN ネットワークの構成
10 Cluster Witness metro ノード ソリューションでは、Cluster Witness（CW）のサポートにより、2 個のプライマリー サイト間での純粋な通信障害 と、マルチサイト アーキテクチャでの実際のサイト障害を解決して、環境全体の可用性を向上できます。7.0.1 以降では、システム が metro ノード Witness と呼ばれるコンポーネントに依存できるようになりました。Witness はオプションのコンポーネントで、 サイト障害、metro ノード クラスター障害、クラスター間障害が発生した場合に、通常の優先ルール セットではシームレスなゼロ RTO またはほぼゼロの RTO というストレージ可用性を実現できないお客様の環境に導入するために設計されました。Cluster Witness（CW）の構成に関する詳細については、SolVe（https://solveonline.emc.
11 コンシステンシー グループ この章では、メトロ ノード コンシステンシー グループを管理および操作する方法について説明します。 トピック： • • • • メトロ ノード コンシステンシー グループの概要 コンシステンシー グループのプロパティ コンシステンシー グループの管理 コンシステンシー グループの操作 メトロ ノード コンシステンシー グループの概要 メトロ ノード コンシステンシー グループは、各ボリュームを集約します。これにより、グループ全体でプロパティの共通セット を適用できます。 図 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 は有効になっています。 クラスター相互接続で使用されるコンシステンシー グループに対して、このプロパティを true に設定します。この場合、優先ク ラスターは常にホストに接続されており、シーケンスのデリバリーを回避するため、データ ロスのリスクはありません。 true （デフォルト）：クラスター間リンクの復元後に、劣勢クラスター上で I/O を自動再開します。 劣勢クラスターが、Web ページのサービスなどの読み取り専用アプリケーションを処理している場合にのみ、auto-resume-atloser を true に設定します。 このプロパティを false に設定しておくことで、管理者はアプリケーションを停止して
コンシステンシー グループの管理 メモ: コンシステンシー グループの作成および管理における重要なベスト プラクティスは、コンシステンシー グループとアプ リケーションの間に 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.
● consistency-group set-detach-rule no-automatic-winner ● consistency-group set-detach-rule winner set コマンドを使用して、コンシステンシー グループの次のプロパティを変更します。 ● visibility ● Storage-at-clusters ● Local-read-override 変更可能（書き込み可能）な属性を表示するには、次のように set コマンドとそれらの有効な入力値を使用します。 VPlexcli:/clusters/cluster-1/consistency-groups/TestCG> set attribute input-description -----------------------------------------------------------------------------------------------------------------active-clusters Read-only. cache-mode Read-only.
ルート コンテキストから visibility プロパティを変更するには、次のようにします。 VPlexcli:/> set /clusters/cluster-1/consistency-groups/TestCG::visibility cluster-1,cluster-2 変更例：デタッチ ルールの適用 次の表に、コンシステンシー グループに適用可能なデタッチルールを示します。これには、visibility と storage-at-clusters のさまざ まな設定が含まれています。 このタスクについて 表 11.
コンシステンシー グループの削除 このタスクについて 空のコンシステンシー グループを破棄するには、次のようにします。 手順 1. ls -f コマンドを使用して、コンシステンシー グループに仮想ボリュームがないことを確認します（virtual volumes = [ ]）。 VPlexcli:/> ls clusters/cluster-1/consistency-groups/TestCG Attributes: Name Value -------------------- ---------------------active-clusters [] cache-mode synchronous detach-rule operational-status [ok] passive-clusters [] recoverpoint-enabled false storage-at-clusters [cluster-1, cluster-2] virtual-volumes [] visibility [cluster-1, cluster-2] . . . 2.
特定のクラスター上のコンシステンシー グループの名前のみを表示するには、/clusters/cluster-name/consistencygroups コンテキストで ls コマンドを使用します。 VPlexcli:/> ls /clusters/cluster-1/consistency-groups/ /clusters/cluster-1/consistency-groups: TestCG test10 test11 test12 test13 test14 test15 test8 test9 vs_RAM_c1wins vs_RAM_c2wins vs_oban005 vs_sun190 test16 test5 test6 test7 コンシステンシー グループの概要を表示するには、/clusters/cluster-name/consistency-groups コンテキストで ll コ マンドを使用します。 このコマンドを使用すると、コンシステンシー グループの全体的な正常性を監視し、構成に不備のあるルールを特定できます。 VPlexcli:/clusters/cluster-1
特定のコンシステンシー グループの詳細なプロパティを表示するには、そのコンシステンシー グループの/advanced コンテキス トで ll コマンドを使用します。 VPlexcli:/clusters/cluster-1/consistency-groups/TestCG/advanced> ls Name Value -------------------------- -------auto-resume-at-loser true current-queue-depth current-rollback-data default-closeout-time delta-size local-read-override true max-possible-rollback-data maximum-queue-depth potential-winner write-pacing disabled 次の例では、クラスター間リンクのアウテージ中に/clusters/cluster-name/ consistency-groups/consistencygroup コンテキストでの ls コマンドの出力を示
VPlexcli:/clusters/cluster-1/consistency-groups/cg1> ls Attributes: Name Value ------------------- ---------------------------------------------------------active-clusters [cluster-1, cluster-2] cache-mode synchronous detach-rule no-automatic-winner operational-status [(cluster-1,{ summary:: ok, details:: [] }), (cluster-2,{ summary:: ok, details:: [] })] passive-clusters [] recoverpoint-enabled false storage-at-clusters [cluster-1, cluster-2] virtual-volumes [dd1_vol, dd2_vol] visibility [cluster-1, cluste
表 12.
表 12.
2. resolve-conflicting-detach コマンドを使用して、優先クラスターとしてクラスター 1 を選択します。 VPlexcli:/clusters/cluster-1/consistency-groups/cg1> resolve-conflicting-detach -c cluster-1 This will cause I/O to suspend at clusters in conflict with cluster cluster-1, allowing you to stop applications at those clusters. Continue? (Yes/No) Yes リンクのアウテージが開始されてから行われた、コンシステンシー グループ内のボリューム上にあるデータに対してのクラス ター 2 による変更が破棄されます。 クラスター 2 のデータ イメージは、クラスター 1 のイメージと同期されます。 自動再開ポリシーが false の場合、クラスター 2 で I/O が一時停止します。 3.
手順 1.
2 個のプロパティに互換性がないため、コンシステンシー グループを同時に read-only と recoverpoint-enabled にすること はできません。 手順 コンシステンシー グループを読み取り専用に設定するには、set コマンドを使用します。 VPlexcli:/> cd/clusters/cluster-1/consistency-groups/test VPlexcli:/clusters/cluster-1/consistency-groups/test>set read-only true VPlexcli:/clusters/cluster-1/consistency-groups>ll Name Operational Active Passive Detach Rule Cache Mode Read ------ Status Clusters Clusters ---------- --------Only ------- ----------- ------- -------- ---------- --------- ---DB2_app (Hopkinton,{ wi
12 パフォーマンスおよび監視 この章では、RPO/RTO と、パフォーマンス モニターを作成および操作する手順について説明します。 トピック： • • • • • • • パフォーマンスの概要 パフォーマンス監視の概要 CLI を使用したパフォーマンス監視 ポートの有効化と無効化 ポートのモニタリング 統計情報 統計表 パフォーマンスの概要 この章では、メトロ ノード システムのパフォーマンスに関連した次のトピックについて説明します。 ● 構成：パフォーマンスを最大化し、目標リカバリー ポイント（RPO）と目標リカバリー時間（RTO）を管理するための変更可 能なパラメーター。 ● モニタリング：メトロ ノードのパフォーマンスを監視し、問題を特定して診断するためのツールと方法。 RPO と RTO 目標リカバリー ポイント（RPO）：RPO はストレージ システムの障害点と、ストレージ システムがお客様のデータをリカバリー できると想定される過去の時点までの時間のインターバルです。 RPO は、障害後にアプリケーションに許容されるデータ ロス量の上限でもあります。RPO の値は、使用されるリカバリの手
メモ: メトロ ノード向けの Unisphere の場合、パフォーマンスの統計情報はクラスターごとに表示されます。Metro 構成内にあ る両方のクラスターの統計情報を表示するには、両方のクラスターに接続します。 カスタム モニター CLI を使用してカスタム モニターを作成すると、選択したターゲットの選択した統計情報を収集して表示できます。 「CLI を使用したパフォーマンス監視」参照してください。 永続モニター GeoSynchrony には、パフォーマンス統計情報の標準セットを 30 秒ごとに収集する永続モニターが含まれています。永続モニター は、メトロ ノードのダイレクターと仮想ボリュームのパフォーマンスに関連する統計情報を収集します。 永続モニター ファイルは collect-diagnostics の一環として収集されます。collect-diagnostics はクラスターごとに行われる ため、Metro 構成では、各 metro ノード クラスターにある 1 個のノードからコマンドを実行します。 永続モニターの出力は、ベースの collect-diagnostics zip ファイル内の
図 9.
● ［仮想ボリューム帯域幅チャート］：仮想ボリュームの読み取りおよび書き込みの総帯域幅（KB/s または MB/s）を、時間ベー スのビューで表示します。通常、帯域幅（KB/s または MB/s とも呼ばれる）は大きなブロックの I/O（64KB 以上の I/O 要求） に関連付けられています。 ● ［フロントエンド ポート ダッシュボード］ ：すべてのメトロ ノード フロントエンド ポートのパフォーマンス メトリックを表示 します。ダッシュボードは履歴データを提供しませんが、5 秒ごとに更新され、過去 5 秒間のデータを表示します。 VPlexcli を使用したパフォーマンス監視 パフォーマンスの問題を診断するのに役立つカスタム モニターを作成するには、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 collecting-data false firmware-id 4 idle-for 5.78min ownership true period 0s . . .
Source: Time: director.be-ops (counts/s): . . . director-2-1-B_TestMonitor 2010-07-01 10:05:55 ポートの有効化と無効化 ポートを有効または無効にする前に、システム構成を完了する必要があります。ポートの有効化と無効化を使用して特定の構成パ ラメーターを変更する方法の詳細については、SolVe（https://solveonline.emc.
手順 1. スクリプト ステータスのチェックをして、スクリプトが実行されているかどうかを確認します。 VPlexcli:/> port-monitor status Status: running with the following parameters: Emails: joe@dell.com SMTP: x.x.x.x Local-only: False 2.
c. config.json ファイルのデフォルトのしきい値を変更します（オプション）。より良い結果を出すために（1 個または）複数 のデフォルト値を増やすことができる場合は、config.json ファイルを新しいしきい値に変更できます（VI エディターを使 用）。例えば、vim /var/log/VPlex/cli/port-stats-monitor/config.json です。 Sample Output: { "bad_CRC": 5, "Disc_frame": 40, "link_fail": 15, "Loss_of_sync": 45, "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.
### Stopping the monitor To stop the monitor, run `port-monitor stop`. ### Checking status To see whether or not the monitor is running, or to see if any unexpected errors were encountered, run the `port-monitor status` command: 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`.
注意事項 問題を報告しているポートの数とダイレクターの数を記録してください。例えば、ポートの半数が問題を報告している場合は、フ ァブリック全体のイベントを示している可能性があります。一方でエラーを報告しているポートが 1 個だけの場合は、その問題は 特定の I-T Nexus に関係しています。 スクリプトは、5 分経過したら（E メール サーバーをあふれさせないように）E メールを抑制するよう設計されています。この時 点では、1 時間に 1 回だけ報告が行われます。管理サーバーに接続するファームウェアには、E メールの送信が抑制された分を含む すべてのレポートが含まれています。 ログ：ログ ファイル port-stats-monitor.log は、/var/log/VPlex/cli/ directory 内の管理サーバーにあります。こ のログ ファイルは raw データを収集しています。grep コマンド[grep "back-end\|front-end\|wan-com" /var/log/ VPlex/cli/port-stats-monitor.log]で、port-stats-monitor.
使用できる統計情報の表示 統計情報はサブカテゴリーにグループ化されています。 monitor stat-list コマンドを使用した後に、<［Tab］>キーで統計情報のサブカテゴリーを表示します。例： VPlexcli:/> monitor stat-list cache, cg, ip-congestion-control, director, wrt-pacing, io-sequencer,,com-path,,com-io-group, be-prt virtual-volume, rp-spl-vol, host-init, directory, fe-director, com-endpoint, rp-splnode, fe-prt, com-cluster-o, io-sequencer-vol, storage-volume, fe-lu ramf, ip-com-port --categories categories オプションを使用して、指定したカテゴリーで使用可能な統計情報を表示します。例： VPlexcli:/monitoring> monitor stat-list --cate
● front-end-performance-stats stop ：実行中のパフォーマンス統計の収集を停止します。 ● front-end-performance-stats start ：パフォーマンス統計の収集を開始します。 ● front-end-performance-stats status ：フロントエンドのパフォーマンス統計収集のステータスを表示します。 メモ: コマンドの詳細については、メトロ ノード向けの CLI リファレンス ガイドを参照してください。 統計表 次の表は、各カテゴリーの統計情報をリスト表示しています。 ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● バックエンド Fibre Channel ポート（be-prt）の統計情報 キャッシュの統計情報 ダイレクターの統計情報 フロントエンド ダイレクター（fe-director）の統計情報 フロントエンド ボリューム（fe-lu）の統計情報 フロントエンド ポート（fe-prt）の統計情報 リモート RAID（ramf）の統計情報 ストレージボリュームの統計情報 仮想ボリュームの統計情報 IP WAN CO
表 16. ダイレクターの統計情報 （続き） 統計情報 タイプ 説明 director.be-ops-write バックエンドの書き込み ダイレクターのバックエンド ポートを経由した書き込み の数。 director.be-ops-ws バックエンドの処理 バックエンドの Write Same 処理の数 director.be-qfulls バック エンドの書き込み このバック エンド ポートのキューの通知数。 director.be-read バックエンドの読み取り ダイレクターのバックエンド ポートによって読み取られ たバイト数。 director.be-resets カウンター 1 秒あたりのバック エンド リセットの数 director.be-timeouts カウンター 1 秒あたりのバック エンド タイムアウトの数。 director.be-unitattns カウンター 1 秒あたりのバック エンド ユニット アテンションの数。 director.
表 16. ダイレクターの統計情報 （続き） 統計情報 タイプ 説明 director.fe-ops-act アクティブなフロントエ ンドの操作 ダイレクターのフロントエンド ポート上にあるアクティ ブな未処理の I/O 操作の数。 キューに登録されている フロントエンド操作 ダイレクターのフロントエンド ポート上にあるキューに 登録された未処理の I/O 操作の数。 フロントエンドの読み取 り ダイレクターのフロントエンド ポート上の読み取りの 数。 フロントエンドの書き込 み ダイレクターのフロントエンド ポート上の書き込みの 数。 フロントエンドの読み取 り ダイレクターのフロントエンド ポートから読み取られた バイト数。 フロントエンドの書き込 み ダイレクターのフロントエンド ポートに書き込まれたバ イト数。 メモリー ダイレクター上のメモリー使用率。 CPU のビジー状態 ダイレクター内の各 CPU を合計した使用率（ユーザーお よびシステム）。 director.
表 17. フロントエンド ダイレクター（fe-director）の統計情報 （続き） 統計情報 タイプ 説明 "タイプ：バケット、ユニット：マイク ロ秒、実引数：なし" フロントエンド ダイレ クターの書き込みレイ "タイプ：バケット、ユニット：マイク テンシー ロ秒、実引数：なし" ダイレクターのフロントエンド ポート上にある書き込み レイテンシーの分布（マイクロ秒）。 フロントエンド ダイレ クターの WriteSame の "タイプ：期間平均、ユニット：マイク 平均レイテンシー ロ秒、実引数：なし" ダイレクターのフロントエンド ポート上にある WriteSame 平均レイテンシーの分布。 fe-director.write-lat fe-director.ws16-avg-lat fe-director.
表 18. フロントエンド ボリューム（fe-lu）の統計情報 （続き） 統計情報 タイプ 説明 フロントエンド ボリュ ームの WriteSame の平 "タイプ：期間平均、ユニット：マイク 均レイテンシー ロ秒、実引数：仮想ボリューム" 指定したフロントエンド ボリューム上にある WriteSame の平均レイテンシーの分布。 フロントエンド ボリュ ームの WriteSame 処理 指定したフロントエンド ボリューム上の WriteSame 処理 の数。 フロントエンド ボリュ ームの UNMAP 処理 指定したフロントエンド ボリュームの 1 秒あたりの UNMAP 処理数。 fe-lu.ws16-avg-lat fe-lu.ws16-ops "タイプ：カウンター、ユニット：カウ ント/秒、実引数：仮想ボリューム" fe-lu.unmap-ops "タイプ：カウンター、ユニット：カウ ント/秒、実引数：仮想ボリューム" フロントエンド ボリュ ームの UNMAP の平均 "タイプ：期間平均、ユニット：マイク レイテンシー ロ秒、実引数：仮想ボリューム" fe-lu.
表 19. フロントエンド ポート（fe-prt）の統計情報 （続き） 統計情報 タイプ fe-prt.ws16-ops フロントエンド ポート 指定したフロントエンド FC ポート上の WriteSame 処理の の WriteSame 処理 数。 "タイプ：カウンター、ユニット：カウ ント/秒、実引数：フロントエンドポー ト" fe-prt.unmap-ops "タイプ：カウンター、ユニット：カウ ント/秒、実引数：フロントエンドポー ト" 説明 フロントエンド ポート 指定したポートで発生した 1 秒あたりの UNMAP 処理の数。 の UNMAP 処理 フロントエンド ポート 指定したフロントエンド ポートでの UNMAP 処理の平均レ の UNMAP の平均レイ イテンシー（マイクロ秒）。 "タイプ：期間平均、ユニット：マイク テンシー ロ秒、実引数：フロントエンドポート" fe-lu.unmap-avg-lat 表 20. リモート RAID（ramf）の統計情報 統計情報 タイプ 説明 ramf.
表 21. ストレージボリュームの統計情報 統計情報 タイプ 説明 storage-volume.per-storage-volume-readlatency ボリュームの読み取り レイテンシー 指定したストレージ ボリューム上の読み取りレイテンシー の分布（マイクロ秒）。 ボリュームの書き込み レイテンシー 指定したストレージ ボリューム上の書き込みレイテンシー の分布（マイクロ秒）。 ボリュームの平均読み 取りレイテンシー すべてのストレージ ボリューム上の平均読み取りレイテン シーの分布（マイクロ秒）。 ボリュームの平均書き 込みレイテンシー すべてのストレージ ボリューム上の平均書き込みレイテン シーの分布（マイクロ秒）。 "タイプ：バケット、ユニット：マイク ロ秒、実引数：ボリューム ID" storage-volume.per-storage-volume-writelatency "タイプ：バケット、ユニット：マイク ロ秒、実引数：ボリューム ID" storage-volume.
表 23. IP WAN COM（ip-com-port）の統計情報 （続き） 統計情報 タイプ ip-com-port.send-pckts カウンター、ユニット： この IP WAN COM ポート上で UDP を使用して送信した カウント/秒、実引数：ポ パケットの数。 ート名 ip-com-port.recv-errors IP WAN COM ポートの受 この WAN COM ポート上の受信エラーの数 信エラー ip-com-port.send-errors IP WAN COM ポートの送 この IP WAN COM ポート上の送信エラーの数 信エラー ip-com-port.recv-dropped IP WAN COM ポートのド この IP WAN COM ポート上にドロップされた受信パケッ ロップされた受信パケッ トの数 ト ip-com-port.send-dropped IP WAN COM ポートのド IP WAN COM ポート上にドロップされた送信パケットの ロップされた送信パケッ 数 ト ip-com-port.
表 25. COM クラスター I/O の統計情報 （続き） 統計情報 説明 com-cluster-io.send-ops クラスターへの I/O 送信操作の数。 "タイプ：読み取り、ユニット：なし、実引数： クラスター ID" com-cluster-io.ops-active サイトへの現在の未処理メッセージ。 com-cluster-io.bytes-active サイトへの現在の未処理バイト数。 com-cluster-io.bytes-queued サイトへの現在のキュー登録済みバイト数。 com-cluster-io.ops-queued サイトへの現在のキュー登録済みメッセージ。 表 26. COM I/O グループの統計情報 統計情報 説明 com-io-group.io-tm-avg 過去 5 秒間のこのチャネル グループの平均レイテンシー（5 秒ごとにアップ デート）。 com-io-group.io-tm-cnt 過去 5 秒間にこのチャネル グループ上で送信されたメッセージ（5 秒ごとに アップデート）。 com-io-group.
表 28. COM エンドポイントの統計情報 統計情報 説明 com-endpoint.ack-bytes-recv 受信した ACK バイト数。 com-endpoint.ack-bytes-sent 送信した ACK バイト数。 com-endpoint.ack-pckts-recv 受信した ACK パケットの数。 com-endpoint.ack-pckts-sent 送信した ACK パケットの数。 com-endpoint.cx-bad-ver 誤ったバージョンの制御パケットの数。 com-endpoint.cx-bytes-recv 受信した制御バイト数。 com-endpoint.cx-bytes-sent 送信した制御バイト数。 com-endpoint.cx-pckts-recv 受信した制御パケットの数。 com-endpoint.cx-pckts-routed ルーティングをした制御パケットの数。 com-endpoint.cx-pckts-sent 送信した制御パケットの数。 com-endpoint.
表 30. ホスト イニシエーターの統計情報 統計情報 説明 host-init.unmap-ops ホスト イニシエーターの UNMAP 処理。 "タイプ：カウンター、ユニット：カウント/秒、実 引数：なし" host-init.
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.
