VPLEX Metro Witnessテクノロジーと高可用性ƒ‘ーツ番号H7113.2. EMC VPLEX Metro Witness テクノロジーと高可用性 3

EMC VPLEX Metro Witness テクノロジーと高可用性

バージョン 2.1

• EMC VPLEX Witness

• VPLEX Metroによる高可用性• Metro HA導入のシナリオ

Jennifer AspesiOliver Shorey

EMC VPLEX Metro Witnessテクノロジーと高可用性2

Copyright © 2010 - 2012 EMC Corporation. All rights reserved.

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

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

この資料に記載される、いかなる EMCソフトウェアの使用、複製、頒布も、当該ソフトウェアライセンスが必要です。

製品ラインの最新の規制文書は、EMC Powerlinkの［テクニカルドキュメントおよびアドバイザリ］セクションを参照してください。

最新の EMC製品名については、http://japan.emc.com で EMC Corporationの商標を参照してください。

他のすべての名称ならびに製品についての商標は、それぞれの所有者の商標または登録商標です。

パーツ番号 H7113.2

目次

はじめに

第 1章 VPLEXファミリおよび使用例の概要はじめに ............................................................................................. 18VPLEXの価値の概要 ....................................................................... 19VPLEX製品 ....................................................................................... 23

VPLEX Local、VPLEX Metro、VPLEX Geo ..........................24アーキテクチャのハイライト ...................................................25

Metro高可用性設計の考慮事項...................................................... 29計画されたアプリケーション移動と災害後の業務再開との比較 .......................................................................................30

第 2章ハードウェア /ソフトウェアはじめに ............................................................................................. 34

VPLEX I/O ..................................................................................34高レベルの VPLEX I/Oフロー ................................................34一貫性のある分散キャッシュ ...................................................35VPLEXファミリのクラスタリングアーキテクチャ ............35VPLEXシングル、デュアル、クワッドエンジン ................37VPLEXサイジングツール ........................................................38アップグレードパス ..................................................................38ハードウェアのアップグレード ...............................................38ソフトウェアアップグレード ..................................................39

VPLEXの管理インタフェース ....................................................... 40Webベースの GUI......................................................................40VPLEX CLI...................................................................................40パフォーマンスの統計のための SNMPサポート .................41LDAP/ADサポート ..................................................................41

EMC VPLEX Metro Witnessテクノロジーと高可用性 3

目次

VPLEX Element Manager API.................................................. 41効率化されたストレージ管理 ......................................................... 42マネージメントサーバのユーザーアカウント ........................... 43マネージメントサーバソフトウェア ........................................... 44管理コンソール ........................................................................... 44コマンドラインインタフェース ............................................. 47システムレポート ...................................................................... 47

ダイレクタソフトウェア ................................................................ 48構成の概要 ......................................................................................... 49シングルエンジン構成 .............................................................. 49デュアル構成 ............................................................................... 50クワッド構成 ............................................................................... 51

I/Oの実装 ......................................................................................... 53キャッシュ一貫性 ....................................................................... 53メタディレクトリ ....................................................................... 53読み取り処理の流れ ................................................................... 54書き込み処理の流れ ................................................................... 55

第 3章システムとコンポーネントの整合性概要 ..................................................................................................... 58クラスタ ............................................................................................. 59複数のポートの使用によるパスの冗長性 ..................................... 60複数のダイレクタの使用によるパスの冗長性 ............................. 61複数のエンジンの使用によるパスの冗長性 ................................. 62サイト分散によるパスの冗長性 ..................................................... 63保守性 ................................................................................................. 64

第 4章 VPLEXの高可用性の基盤VPLEXの高可用性の基盤 ............................................................... 66VPLEX Witnessなしでの障害処理（静的な選択）...................... 74

第 5章 VPLEX Witnessの概要VPLEX Witnessの全体像とアーキテクチャ ................................ 86VPLEX Witnessのターゲットソリューション、ルール、ベストプラクティス ........................................................................ 89VPLEX Witnessの障害セマンティクス ........................................ 91CLIの出力例...................................................................................... 97

VPLEX Witness：第 3の障害ドメインの重要性 ................. 101


目次

第 6章 VPLEX Metro HA

VPLEX Metro HAの概要............................................................... 104VPLEX Metro HAキャンパス（クロス接続あり）..................... 105VPLEX Metro HA（クラスタ間接続なし）.................................. 115

第 7章結論結論.................................................................................................... 124ストレージ関連の障害に対するより優れた保護 .................125起こりうる障害の連鎖に対する保護 .....................................125全体的なリソース使用率の向上 .............................................126

用語集

5EMC VPLEX Metro Witnessテクノロジーと高可用性

目次


タイトルページ

図

1 アプリケーションおよびデータ移動の例................................................... 202 HAインフラストラクチャの例 ................................................................... 213 分散データコラボレーションの例.............................................................. 224 VPLEX製品 ..................................................................................................... 245 アーキテクチャのハイライト....................................................................... 266 VPLEXクラスタの例 ..................................................................................... 367 VPLEX管理コンソール ................................................................................. 458 管理コンソールの初期スクリーン............................................................... 469 VPLEXシングルエンジン構成 .................................................................... 5010 VPLEXデュアルエンジン構成 .................................................................... 5111 VPLEXクワッドエンジン構成 .................................................................... 5212 ポートの冗長性............................................................................................... 6013 ダイレクタの冗長性....................................................................................... 6114 エンジンの冗長性........................................................................................... 6215 サイトの冗長性............................................................................................... 6316 高レベルで見た通信可能な稼動サイト....................................................... 6617 高レベルで見たサイト Aの障害.................................................................. 6718 高レベルで見たサイト間のリンク障害....................................................... 6719 VPLEXが 2サイト間でアクティブかつ稼動中 ......................................... 6820 サイト Aで障害が発生した状態の VPLEX概念図................................... 6921 サイト Aでボリューム障害が発生した後の適切な解決策...................... 7022 VPLEXが 2サイト間でアクティブかつ稼動中 ......................................... 7123 サイト間のリンク障害とクラスタパーティション.................................. 7224 クラスタパーティションに対する適切な処理.......................................... 7325 VPLEXの静的デタッチルール .................................................................... 7526 典型的なデタッチルールセットアップ..................................................... 7627 非優先サイトの障害....................................................................................... 7728 ボリュームはクラスタ 1で引き続きアクティブ....................................... 7829 リンク障害前の典型的なデタッチルールセットアップ......................... 7930 サイト間のリンク障害とクラスタパーティション.................................. 80


図

31 サイト間リンク障害後の中断とクラスタパーティション...................... 8132 クラスタ 2が優先........................................................................................... 8233 優先サイトの障害でデータが全面的に使用不可に................................... 8334 高レベルで見た VPLEX Witnessアーキテクチャ..................................... 8735 高レベルで見た VPLEX Witnessの導入..................................................... 8836 VPLEX Witness対応の VPLEXバージョン............................................... 9037 ボリュームタイプとルールの VPLEX Witnessによるサポート状況.... 9038 典型的な VPLEX Witness構成..................................................................... 9139 VPLEX Witnessとクラスタ間リンク障害.................................................. 9240 クラスタパーティション後の VPLEX Witnessと静的な選択................ 9341 VPLEX Witnessの典型的なクラスタ 2デタッチ用構成.......................... 9442 クラスタ 2で障害が発生したときの VPLEX Witnessの図..................... 9543 VPLEX Witnessと静的な選択のオーバーライド...................................... 9644 二重障害によるクラスタ分離が起こりうるシナリオ............................... 9945 手動介入を要する、きわめて起こりにくい二重障害シナリオ............. 10046 手動介入を要する 2つのさらなる二重障害シナリオ............................. 10147 VMware向けMetro HAキャンパスソリューションの高レベル図 ... 10548 障害ドメインに分割されたMetro HAキャンパスの図 ........................ 10849 ゾーン A1で障害が発生したMetro HAキャンパスの図 ..................... 10950 ゾーン A2で障害が発生したMetro HAキャンパスの図 ..................... 11051 ゾーン A3または B3で障害が発生したMetro HAキャンパスの図... 11152 ゾーン C1で障害が発生したMetro HAキャンパスの図 ..................... 11253 サイト間リンク障害が発生したMetro HAキャンパスの図 ................ 11354 標準的なMetro HAの高レベル図 ............................................................ 11555 障害ドメインのあるMetro HAの高レベル図 ........................................ 11756 ドメイン A2に障害のあるMetro HAの高レベル図 ............................. 11857 サイト間リンク障害が発生したMetro HAの高レベル図 .................... 120


タイトルページ

表

1 VPLEXの機能とメリットの概要 .................................................................. 272 構成の概要........................................................................................................ 373 マネージメントサーバのユーザーアカウント.......................................... 43


表


はじめに

この EMCエンジニアリング TechBookでは、VPLEXを実装することで可用性が高まる仕組みについて、洞察に富む説明を行っています。

製品ラインのパフォーマンスと機能を継続的に改善および強化するための努力の一環として、EMCではハードウェアおよびソフトウェアの新規バージョンを定期的にリリースしています。そのため、本書で説明されている機能の中には、現在お使いのソフトウェアまたはハードウェアのバージョンによっては、サポートされていないものもあります。製品機能の最新情報については、お使いの製品のリリースノートを参照してください。製品が正常に機能しない、またはこのマニュアルの説明どおりに動作しない場合には、EMCの担当者にお問い合わせください。

対象読者本書は EMC VPLEXファミリマニュアルセットの一部で、ストレージおよびシステム管理者が対象です。

本書は、読者が次の事項についてよく知っていることを前提としています。

◆ ストレージエリアネットワーク◆ ストレージ仮想化テクノロジー◆ EMC Symmetrix、VNXシリーズ、CLARiX製品

関連ドキュメント EMC Powerlink Webサイト（http://powerlink.emc.com）を参照してください。［サポート］＞［テクニカルドキュメントおよびアドバイザリ］＞［ハードウェア /プラットフォーム］＞［VPLEXファミリ］に次のドキュメントの多くが用意されています。◆ EMC VPLEX Architecture Guide


12

はじめに

◆ EMC VPLEX Installation and Setup Guide

◆ EMC VPLEX Site Preparation Guide

◆ EMC VPLEXの実装およびプランニングのベストプラクティスに関するテクニカルノート

◆ VMware仮想化プラットフォームと EMC VPLEXの使用：ベストプラクティスのプランニング

◆ VMware KB： Using VPLEX Metro with VMware HA

◆ Implementing EMC VPLEX Metro with Microsoft Hyper-V, Exchange Server 2010 with Enhanced Failover Clustering Support

◆ ホワイトペーパー： Using VMware vSphere with EMC VPLEX：Best Practices Planning

◆ Oracle Extended RAC with EMC VPLEX Metro：Best Practices Planning

◆ ホワイトペーパー： EMC VPLEX with IBM AIX Virtualization and Clustering

◆ ホワイトペーパー： Conditions for Stretched Hosts Cluster Support on EMC VPLEX Metro

◆ ホワイトペーパー：フェイルオーバークラスタリングのサポートを強化した EMC VPLEX、Microsoft Hyper-V、SQL Serverの実装：高度なテクノロジー

このガイドの構成本書は、以下のセクションに分かれています。

◆ 第 1章「VPLEXファミリおよび使用例の概要」、では、VPLEXファミリの概要について説明します。また、VPLEXファミリのシステム主要機能、アーキテクチャ、および用途についても一部取り上げます。

◆ 第 2章「ハードウェア /ソフトウェア」、では、VPLEXシステムのハードウェア、ソフトウェア、ネットワークコンポーネントについて、その概要を説明します。また、管理者が VPLEXシステムのあらゆる側面を管理するのに使用できるソフトウェアインタフェースも取り上げます。

◆ 第 3章「システムとコンポーネントの整合性」、では、ストレージクラスタ内のどのサブシステムでハードウェア障害が発生しても VPLEXクラスタが対処できる仕組みをまとめます。

EMC VPLEX Metro Witnessテクノロジーと高可用性

はじめに

◆ 第 4章「VPLEXの高可用性の基盤」、では、正真正銘の HA環境の構築に関して業界全体が抱えているジレンマの内容と、VPLEX Metro機能がこのかねてからの難題に手動で対処する仕組みについて、その概要を説明します。

◆ 第 6章「VPLEX Metro HA」、では、クラスタ間環境に「witness（目撃者、証人の意）」を導入することで、VPLEX機能により正真正銘の HA機能が実現される仕組みについて説明します。

◆ 第 7章「結論」、では、VPLEXテクノロジーを使用することの利点を VPLEX Witnessおよび高可用性と絡めてまとめます。

◆ 付録 A「vSphere 5.0アップデート 1の追加設定」、では、vSphere 5.0アップデート 1を使用する際に必要な追加設定について説明します。

著者この TechBookの著者は、米国マサチューセッツ州ホプキントンにある EMC本社を本拠とする VPLEXビジネスユニットの、エンタープライズストレージ部門所属の次の両名です。

Jennifer Aspesiは、SAN（Storage Area Network）、WAN（Wide Area Network）、ネットワーク /ストレージのセキュリティテクノロジーに関し、EMCにおいて 10年以上の実務経験があります。現在は、VPLEXビジネスユニットのコーポレートシステムエンジニアリングチームを統括しています。マサチューセッツ州にあるウスター理科大学でマーケティングおよびテクノロジカルイノベーションの修士号を取得しています。

Oliver Shoreyは、ビジネス継続性の分野で 11年以上の実務経験があり、そのうち 7年を、EMCでハイエンドのレプリケーションと地理的に分散したクラスタリングテクノロジーのエンジニアリング、設計、文書化に携わっています。現在は、VPLEXビジネスユニットの主席コーポレートシステムエンジニアを務めています。

その他の貢献者本書には他にも以下が貢献しています。

Colin Durocherは、旧バージョンおよび現状の EMC VPLEX製品向けソフトウェアの開発、テスト、お客様による実装の支援に 8年の経験があります。現在は、VPLEXビジネスユニットの製品管理チームに属しています。アルバータ大学でコンピュータエンジニアリングの学士を取得しており、現在はMBAを目指してジョンモルソンスクールオブビジネスに通学中です。

Gene Ortenbergは、フォルトトレラントな分散システムおよびアプリケーションの構築に 15年以上の経験があります。ここ 8年は、EMCで高可用性ストレージ仮想化ソリューションの設計と開発に携


14

はじめに

わっています。現在は、EMCエンタープライズストレージ部門のVPLEXビジネスユニットでソフトウェアアーキテクトを務めています。

Fernanda Torresは、コンシューマ製品業界で 10年以上のマーケティング経験があり、最近まで家電製品に関わっていました。Fernandaは EMCエンタープライズストレージ部門の VPLEX担当プロダクトマーケティングマネージャです。彼女はノートルダム大学から学士号を、スペインのバルセロナにある IESEからバイリンガル学士（英語とスペイン語）を取得しています。

表記規則本書では、以下の表記規則を使用します。

Normal 処理手順を除く本文で、以下の場合に使用：• インタフェース要素の名前（ウィンドウ、ダイアログボックス、ボタン、フィールド、メニューの名前）

• リソース、属性、プール、論理式、ボタン、DQLステートメント、キーワード、節、環境変数、関数、ユーティリティの名前

• URL、パス名、ファイル名、ディレクトリ名、コンピュータ名、ファイル名、リンク、グループ、サービスキー、ファイルシステム、通知

太字処理手順を除く本文で、以下の場合に使用：• コマンド、デーモン、オプション、プログラム、プロセス、サービス、アプリケーション、ユーティリティ、カーネル、通知、システムコール、マニュアルページの名前

処理手順で、以下の場合に使用：• インタフェース要素の名前（ウィンドウ、ダイアログボックス、ボタン、フィールド、メニューの名前）

• 具体的にユーザーが選択する、クリックする、押す、または入力するもの

斜体処理手順を含むすべてのテキストで、以下の場合に使用：• 本文内で参照される出版物の完全なタイトル• 強調（新規用語など）• 変数

クーリエ以下の場合に使用：• エラーメッセージやスクリプトなどのシステム出力

• 本文以外で使用される、URL、完全なパス、ファイル名、プロンプト、構文


はじめに

コメントをお待ちしております !

TechBookに関するフィードバックをお寄せください !弊社ではできるだけ役に立つ TechBookをお届けしたいと考えております。本書や他の TechBookに関するご意見やご感想を次のアドレスまでお寄せください。[email protected]

クーリエ、太字以下の場合に使用：• 特定のユーザー入力（コマンドなど）

クーリエ、斜体処理手順で、以下の場合に使用：• コマンドラインの変数• ユーザーが入力する変数

< > 山括弧内はユーザーが入力するパラメータまたは変数を示す

［］オプション値

| 縦棒は、選択肢を示し、「または」を意味します。

{ } 中括弧は、指定する必要のある内容を示す（例：x、y、z）

... 省略記号は、例の中で省略した重要でない情報を示す


[email protected]

16

はじめに


1

この章では、EMC VPLEXファミリの主な使用例と高可用性を目指す設計における考慮事項の概要について説明します。また、VPLEXファミリのシステムの主要機能についても一部取り上げます。トピックは次のとおりです。

◆ はじめに................................................................................................................................. 18◆ VPLEXの価値の概要................................................................................................... 19◆ VPLEX製品......................................................................................................................... 23◆ Metro高可用性設計の考慮事項........................................................................... 29

VPLEXファミリおよび使用例の概要

VPLEXファミリおよび使用例の概要 17

18


はじめにこの TechBookの目的は、EMC® VPLEX™高可用性と VPLEX Witnessの導入です。一般に、アーキテクチャはお客様のストレージ管理者と EMCソリューションアーキテクトによって概念設計されます。VPLEX Witnessを導入し、VPLEX Metro環境にしかるべく配置することで、正真正銘の物理 /論理ファブリックとキャッシュ一貫性のある冗長性がお客様にもたらされます。

この TechBookでは、VPLEX Metro構成に関連する諸機能と、今日の進んだホストアプリケーションのためのアクティブ /アクティブデータ堅牢性の大切さについて、その概要を説明します。



VPLEXの価値の概要VPLEXには、既存のデータセンターを拡張する際にストレージ管理者から重視され求められる、非常に価値の高い独特の機能があります。分散された動的かつスマートな機能が既存のデータセンターや新しいデータセンターに提供され、遠距離間でのストレージ仮想化が実現します。

◆ VPLEXは分散型です。単一のインタフェースでマルチベンダーストレージに対応します。また、動的データ移動を実現しており、システム停止を要さず、アプリケーションとデータをリアルタイムで移動できます。

◆ VPLEXは動的です。データの可用性と柔軟性をもたらすほか、従来ならシステム停止や手動リストア手順を要する障害中も業務を継続できます。

◆ VPLEXはスマートです。独自のAccessAnywhereテクノロジーにより、サイト内やサイト間で同じデータの整合性を実現して維持できるほか、分散データコラボレーションを可能にします。

これらの機能により、VPLEXはターゲットとなるお客様の IT環境に対して 3つのまったく異なる要件を満たす、ユニークで差別化された価値をもたらしています。

◆ VPLEXファミリ製品には同じデータセンター内、キャンパス内、地理的な地域内に設置された別のコンピュータやストレージに、アプリケーションとデータを動的に移動できる機能が備わっていますが、新たな VPLEX Geoの登場で、さらに遠距離にも対応できるようになりました。

◆ 優れたリカバリ性により、前述した多様なサイト間で高可用性ストレージおよびコンピューティングインフラストラクチャを構築できます。

◆ ビデオ、地理学 /海洋学調査などの「ビッグデータ」アプリケーション向けに、遠距離間で効率的なリアルタイムのデータコラボレーションを実現できます。

EMC VPLEXテクノロジーは、無停止でマルチプラットフォームのデータ移動およびボリューム管理機能を提供する、拡張性の高い分散ストレージフェデレーションソリューションです。

VPLEXテクノロジーを SAN（ストレージエリアネットワーク）内のホストやストレージの間に導入すると、データセンター内、データセンター間、データセンター全体でデータを拡張できるようになります。

VPLEXの価値の概要 19

20


VPLEXアーキテクチャは、次のような多様な導入戦略に対応する高可用性ソリューションを提供します。

◆ アプリケーションおよびデータの移動：ダウンタイムなしの VM（仮想マシン）の移動です。例を図 1に示します。

図 1 アプリケーションおよびデータ移動の例

VPLEXを使用すると、ストレージ管理者は各クラスタの場所にあるストレージリソースとコンピューティングリソースを使用して、自動的にロードバランシングを実行できます。VPLEXをサーバ仮想化と組み合わせることで、ユーザーは仮想マシンおよびそれに対応するアプリケーションとデータを離れた場所に透過的に移動および再配置できます。これにより、サイト間でインフラストラクチャリソースを再配置、共有、バランシングできるという、独自の機能がもたらされます。ここで言う「サイト間」とはキャンパス内やデータセンター間のことで、VPLEX Metroを使用すれば 5 ms以内で、VPLEX Geoを使用すればさらに離れた（50 ms RTT）非同期距離内で可能です。

注： VPLEX Metroで 10 ms以内が求められている場合は、RPQをご提出ください。または、サポートマトリックスで最新のサポートレーテンシーをご確認ください。



• HAインフラストラクチャ：RTO（Recovery Time Objective：目標復旧時間）を短縮します。例を図 2に示します。

図 2 HAインフラストラクチャの例

「高可用性」がうたわれている製品は他にもあります。高可用性ソリューションは、究極的にはアプリケーションを障害から保護して常時オンラインの状態に保つためのものです。ストレージ管理者は、これにより重要なアプリケーションのアップタイムをほとんど中断せずに継続でき、障害が発生した場合には人間による操作をできるだけ少なくしてアプリケーションの使用を自動的に再開することができます。

従来のソリューションを使用しているお客様の場合、普通はRPO（Recovery Point Objective：目標復旧時点）と RTO（Recovery Time Objective：目標復旧時間）を設定する必要があります。ソリューションには RTOや RPOが短いものもありますが、それでもダウンタイムは生じ、大多数のお客様にとってはいかなるダウンタイムも大きな損害になり得ます。

VPLEXの価値の概要 21

22


• 分散データコラボレーション：パッシブな DR（データリカバリ）資産の使用率を向上し、データへ同時にアクセスできるようにします。例を図 3に示します。

図 3 分散データコラボレーションの例

• 複数の従業員ユーザーがそれぞれ異なるサイトにいて、同じデータに対して作業を行い、変更が発生した場合でも、整合性が維持されます。使用例には、複数のチームが異なる場所で開発を行う、ソフトウェアの共同開発や、エンジニアリング、グラフィックアート、動画、教育プログラム、デザイン、研究レポートなどのコラボレーション用ワークフローがあります。

• 従来のソリューションを使用して離れたサイト間でコラボレーションを実現する場合、通常は 1か所のファイルをすべて保存してから、FTPを使用して別のサイトに送信しなければなりません。これは時間がかかるだけでなく、大きなファイルを送信すると帯域幅を大量に消費します。たとえ小さいファイルであっても頻繁に移動させていると、他のサイトから送信される最新データを受信するために、もう一方のサイトはアイドル状態で待つことになるため、生産性に望ましくない影響を与えます。互いのチームが他のチームの都合を配慮せずに独自に作業した場合、複数の人がデータセットを同時に使用し、他人の加えた最新の変更に気づかないため、データセットの整合性はすぐに失われてしまいます。すべての変更を最後に一括して反映させるのは、時間とコストがかかるうえ、データセットが大きくなるほど複雑な作業になります。



VPLEX製品 VPLEXは、まず、高可用性とデータ移動の要件を満たしますが、その後、フロントエンドアプリケーションとバックエンドストレージで必要とされる I/Oスループットに合わせて拡張することも可能です。

高可用性とデータ移動の機能は、VPLEX Local、VPLEX Metro、および VPLEX Geoの特徴です。

VPLEXクラスタは、エンジン 1、2、または 4台（それぞれダイレクタ 2個を持つ）とマネージメントサーバ 1台で構成されています。デュアルエンジンまたはクワッドエンジンクラスタには、ダイレクタ間の通信のため、1対のファイバチャネルスイッチのペアも存在します。

各エンジンは SPS（予備電源ユニット）で保護され、各ファイバチャネルスイッチへの給電は UPS（無停電電源装置）から行われます（デュアルエンジンまたはクワッドエンジンクラスタでは、マネージメントサーバの給電も UPSから行われます）。

マネージメントサーバにはパブリック Ethernetポートがあり、お客様のネットワークに接続されると、クラスタ管理サービスが実行されます。

このセクションでは、次の項目について説明します。

◆ 24ページの「VPLEX Local、VPLEX Metro、VPLEX Geo」◆ 25ページの「アーキテクチャのハイライト」

VPLEX製品 23

24


VPLEX Local、VPLEX Metro、VPLEX GeoEMCは、高可用性とデータ移動に関するお客様のニーズに対応するため、次の 3構成の VPLEXを提供しています。◆ VPLEX Local

◆ VPLEX Metro

◆ VPLEX Geo

図 4にそれぞれの例を示します。

図 4 VPLEX製品

VPLEX Local

VPLEX Localにより、シームレスで無停止のデータ移動が実現し、データセンター内で 1つのインタフェースから複数の異機種混在アレイを管理できるようになります。

VPLEX Localを使用すると、可用性が強化されて管理は合理化され、複数のアレイにわたって使用率を向上できます。



EMC VPLEX Metroと AccessAnywhere VPLEX Metroと AccessAnywhereを使用すると、同期対応距離内にある 2つのサイト間でアクティブ /アクティブなブロックレベルのデータアクセスが実現します。その距離は同期動作が可能な範囲に制限され、ホストアプリケーションの安定性とMANトラフィックについても考慮されます。アプリケーションに応じて、Metroの場合は 5 ms1 RTT以内が推奨されます。

また、VPLEX Metroによるバーチャルストレージと仮想サーバを組み合わせることで、遠距離間で仮想マシンを透過的に移動できます。このテクノロジーにより、異機種混在アレイや複数のサイトにわたる使用率が向上します。

VPLEX Geoと AccessAnywhereVPLEX Geoと AccessAnywhereを使用すると、非同期対応距離内にある 2つのサイト間でアクティブ /アクティブなブロックレベルのデータアクセスが実現します。VPLEX Geoでは、リソースや電源をよりコストパフォーマンスに優れた方法で利用できるようになります。GeoでもMetroと同じ分散デバイスの柔軟性がもたらされますが、距離を 50 ms RTTまで延ばすことができます。あらゆる非同期転送メディアと同様、最適な動作やリンクでのアプリケーション共有について考慮する場合は、帯域幅も重要です。

注：本書の目的に鑑み、この TechBookでテクノロジーについてはMetro構成だけをもとに議論します。VPLEX Witnessは VPLEX Geoとの組み合わせでもサポートされていますが、この TechBookでは扱いません。

アーキテクチャのハイライトVPLEXのサポートは、オープンで異機種混在環境に対応しており、EMCストレージと、HDS、HP、IBMなどの他のストレージベンダー製の一般的なアレイの両方をサポートします。VPLEXは、ゾーニングに使用可能な実証済みのWWN（World Wide Name）ガイドラインに準拠しています。

1. VPLEXと各ベンダーのホワイトペーバーを参照し、レーテンシーの制限について確認してください。

VPLEX製品 25

26


VPLEXは、VMware ESXとMicrosoft Hyper-Vによる物理サーバ環境と仮想サーバ環境の両方を含むオペレーティングシステムをサポートしています。また、レガシーMcData SANを含む BrocadeとCisco製のネットワークファブリックをサポートしています。

注：サポートされているホストタイプについては ESSM（EMC Simple Support Matrix）で、ファブリックサポートと Extended Fabricサポートについては ESMで、最新情報をご確認ください。

アーキテクチャの例を図 5に示します。

図 5 アーキテクチャのハイライト



表 1に、VPLEXの機能の概要とそのメリットを示します。

アプライアンスベースの VPLEXテクノロジーは、VPLEXの全製品に次の機能をもたらします。

◆ バックエンドアレイの SAN（ストレージエリアネットワーク）ボリュームを VPLEXエンジンに認識させる

◆ ユーザー定義の構成と保護レベルに基づいて、SANボリュームを数セットの VPLEX仮想ボリュームにパッケージ化する

◆ 仮想ボリュームをVPLEXフロントエンド経由でSAN内の本番ホストに認識させる

◆ VPLEX Metroと VPLEX Geoは、分散キャッシュと I/Oのグローバルなブロックレベルディレクトリを VPLEXクラスタ間で認識させます。

高可用性とデータ移動の要件は、場所と距離によって決まります。たとえば、すべてのストレージアレイが 1か所のデータセンターにある場合、VPLEX Localはデータセンター内のバックエンドストレージアレイの連携を行います。

表 1 VPLEXの機能とメリットの概要

機能メリット

モビリティユーザーに影響を与えずにデータとアプリケーションを移動。

復元性ホストに影響を与えることなく異機種アレイ間のミラーリングを実行し、重要なアプリケーションの高可用性を向上。

分散キャッシュの一貫性クラスタ全体およびクラスタ間で I/Oの共有、分散、フェイルオーバーを自動化。

高度なデータキャッシュ I/Oパフォーマンスを向上させ、ストレージアレイの競合を軽減。

ローカルストレージフェデレーション

データセンター内およびデータセンター間で情報の透過的な移動とアクセスを実現。

スケールアウトクラスタアーキテクチャ

小規模な構成から開始し、予測可能なサービスレベルを維持しながら拡張。

VPLEX製品 27

28


バックエンドストレージアレイが 2か所のデータセンターに分散している場合、VPLEX Metroまたは VPLEX Geoの AccessAnywhere機能が、VPLEXクラスタ間でアクティブ -アクティブ構成を使用してストレージを連携します。VPLEX Metroと VPLEX Geoのどちらを選択するかは、距離とデータ同期の要件によります。

各 VPLEXクラスタのエンジン数は、アプリケーションとバックエンドストレージの I/Oスループットによって判断します。VPLEXクラスタの高可用性機能により、I/Oスループットの増大に伴い、ソフトウェアのアップグレードと拡張を無停止で行うことができます。



Metro高可用性設計の考慮事項VPLEX Metro 5.0（以上）では、従来のいわゆる「物理高可用性」を超える高可用性の概念が導入されています。「VPLEX Witness」を高可用性環境に導入すると、VPLEXソリューションは、2か所のプライマリサイト間の純粋な通信障害とマルチサイトアーキテクチャ内で発生した本当のサイトの障害との違いを見極めることを通じて、環境の全体的な高可用性を向上させることができます。EMC VPLEXは VPLEX Witnessが実現する機能を市場にもたらす初の製品であり、障害を防ぎ、マルチサイトアーキテクチャにおけるクラスタ間のアクティビティを明確にします。

管理者やお客様はこの TechBookを通じて、VPLEXにより次のような機能がもたらされる高可用性ソリューションについて理解を深めることができます。

◆ データセンター間のロードバランシングの実現◆ 両データセンターのアクティブ /アクティブの使用◆ アプリケーションの可用性の向上（単一点ストレージ障害なし、自動再開）

◆ 完全に自動化された障害処理◆ 優れたリソース使用率◆ 結果としてもたらされる資本支出と運営コストの削減従来の環境と言えば、個々のデータセンター内で「きわめて」可用性の高い設計が実装され、データセンター間では災害復旧型の機能が導入されている、というのが一般的です。

このようになっている主な理由の 1つとして、データセンター内ではコンポーネントが概してアクティブ /アクティブで（または自動フェイルオーバー機能を使用してアクティブ /パッシブで）運用されている一方、データセンター間では従来のレプリケーションテクノロジーでアクティブ /パッシブ技術が採用されており、パッシブコンポーネントの使用に手動フェイルオーバーが必要とされていることが挙げられます。

VPLEX Metroアクティブ /アクティブレプリケーションテクノロジーと、VPLEX Witnessサーバ（85ページの「VPLEX Witnessの概要」を参照）などの新機能を組み合わせて使用すると、データセンターの境界を越えて HAを拡張できることから、ローカルの高可用性と遠距離の災害復旧の境目があいまいになります。「レプリケーション」は連携分散ストレージの災害回避の副産物であり、地理的に分散している HA環境内でも実現可能です。

Metro高可用性設計の考慮事項 29

30


計画されたアプリケーション移動と災害後の業務再開との比較このセクションでは、計画されたアプリケーション移動と災害後の業務再開とを比較します。

計画されたアプリケーション移動

計画されたイベントにおいて、アプリケーションは概念上、完全にオンラインのままで（システム停止なしに）ある場所から別の場所へ移動できるはずですが（移動先が同じデータセンター内にあってもリモートデータセンターにあっても）、現実問題としてそれが可能なのは、移動に関わるすべてのコンポーネントが使用可能で、アプリケーションの実行状態が揮発性メモリ上に存在し、どちらの場所でもリード /ライトアクティビティができるメカニズムと揮発性メモリデータをシステム間で移行できるメカニズムとが存在する場合に限られます。このタイプの移動では、アクティブ /アクティブの基盤レプリケーションソリューション（本書の発行時点ではVPLEX Metroのみ）を使用することが前提条件となります。

このようなオンラインアプリケーション移動の一例が VMware vMotionで、仮想マシンがフル稼働していないと移動させることができません。当たり前のことに思えるかもしれませんが、VMがオフラインになっていると、移動をオンラインでは実行できません（これは理解しておくべき重要な点で、アプリケーションの再開との主な違いです）。

vMotionが実行されると、VMを機能させるために必要なすべてのライブコンポーネントがバックグラウンドで別の場所にコピーされてから、VMの切り替えが行われます。

このタイプの移動タスクはユーザーから見て完全にシームレスなので、関連する使用例には、実行状態が使用可能であることを活かしてアプリケーションまたは VMを災害に先だって移動できる状況（台風や津波など）での災害回避や、複数のシステムやデータセンター全体にわたってロードバランシングを調整する機能の実現などがあります。

こうしたタイプの再配置では実行状態が使用可能である必要があり、そうした移動は常に、計画されたアクティビティと見なされます。

災害後の業務再開災害後の業務再開の場合、普通は、アプリケーションまたはサービスは障害発生後に別の場所で再開され（別のサーバまたはデータセンターで）、フェイルオーバー中はサービス /アプリケーションが中断されます。



このテクノロジーの好例が、VPLEX Metroを使用して地理的に離れた 2か所のサイトにわたって構成された VMware HA Clusterで、単一のクラスタが複数の ESXサーバにわたって形成され、クラスタに属する任意の ESXサーバ上で単一または複数の仮想マシンを実行できます。

何らかの理由でアクティブな ESXサーバで障害が発生した場合でも（サイトの障害などで）、リモートサイトに存在してそのクラスタに属する正常な ESXサーバ上で VMを再開できます。なぜなら、VMが VPLEX Metro分散ボリューム上に構成されており、実行されていたデータストアが 2か所に展開されているからです。これは計画外のフェイルオーバーと見なすことができます。このケースでは小規模のアプリケーション停止が伴いますが、それは ESXサーバに障害が発生すると、VMが別の場所で再開されるまでサービスが使用不可になり、VMの実行状態が失われるからです。

計画されたアプリケーション移動イベントでも計画外の災害後の業務再開でも同じ結果（サービスが別の場所へ移動する）になりますが、こうして比べると大きな違いの存在がわかります。それは、計画された移動ジョブでは移動中にアプリケーションのオンライン状態が保たれる一方、災害後の業務再開では再開が伴い、アプリケーションが移動中にオフラインになることです。

アクティブ /アクティブテクノロジーの場合とは違って、従来のアクティブ /パッシブタイプのソリューションをこうした再開シナリオで使用するには、一般に標準的なアプリケーションフェイルオーバーより一手間余計にかかり、その理由はストレージのフェイルオーバーも必要になるからです（ライト禁止のリモートコピーのステータスを読み取り /書き込みに変更し、レプリケーションの向きを逆転させる）。ここで VPLEXが大きな支援となります。というのも、VPLEXはアクティブ /アクティブであるため、ほとんどの場合、ストレージレイヤーでの手動介入は不要で、そのため DRフェイルオーバーソリューションの複雑さが大きく軽減されるからです。物理高可用性と冗長ハードウェア接続性のベストプラクティスに従えば、VPLEX Witnessのもたらす価値によって「正真正銘の」可用性がもたらされるのです !

Metro高可用性設計の考慮事項 31

32



2

この章では、管理者が VPLEXシステムのあらゆる側面を管理するのに使用できるハードウェアおよびソフトウェアインタフェースに関する洞察を紹介します。また、内部システムソフトウェアの概要についても説明します。トピックは次のとおりです。

◆ はじめに................................................................................................................................. 34◆ VPLEXの管理インタフェース............................................................................. 40◆ 効率化されたストレージ管理................................................................................ 42◆ マネージメントサーバのユーザーアカウント....................................... 43◆ マネージメントサーバソフトウェア............................................................. 44◆ ダイレクタソフトウェア......................................................................................... 48◆ 構成の概要........................................................................................................................... 49◆ I/Oの実装........................................................................................................................... 53

ハードウェア /ソフトウェア

ハードウェア /ソフトウェア 33

34


はじめにこのセクションでは、次の基本項目について説明します。

◆ 34ページの「VPLEX I/O」◆ 34ページの「高レベルの VPLEX I/Oフロー」◆ 35ページの「一貫性のある分散キャッシュ」◆ 35ページの「VPLEXファミリのクラスタリングアーキテクチャ」

VPLEX I/O

VPLEXはストレージ I/Oのキャッシュ一貫性を維持する軽量プロトコルを土台に構築されており、VPLEXクラスタは高可用性キャッシュ、処理能力、フロントエンドおよびバックエンドファイバチャネルインタフェースを備えています。

EMCハードウェアが VPLEXクラスタ設計にパワーを与えており、すべてのデバイスが常時使用可能で、どこからクラスタに入力された I/Oでもクラスタ内のどれかのノードで処理可能です。

VPLEX Metroおよび VPLEX Geo製品の AccessAnywhere機能は、離れているデータセンター間のキャッシュ一貫性を拡張します。

高レベルの VPLEX I/OフローVPLEXは、ブロックレベルの所有モデルを、きわめてよく整理された階層ディレクトリ構造に抽象化します。ディレクトリ構造は各I/Oで更新され、全エンジン間で共有されます。ディレクトリは少量のメタデータを使用し、どのデータブロックがどのエンジンによっていつ所有されているかを、クラスタ内の他のすべてのエンジンに 4,000ブロック単位の転送で通知します。

書き込みが完了し、所有がディレクトリに反映されると、VPLEXは完了した書き込みの読み取り要求をできるだけ効率の良い方法で動的に管理します。

読み取り要求を受信すると、VPLEXはディレクトリの所有者をチェックします。VPLEXが所有者を特定すると、読み取り要求は該当するエンジンに直接送られます。



他のエンジンからの読み取り時、VPLEXはディレクトリをチェックし、読み取り I/Oをエンジンキャッシュから直接引き出そうとします。これは、読み取り要求を満たすのに物理アレイにアクセスすることを避けるためです。

このモデルで VPLEXはクラスタ間やサイト間でディレクトリを分散させることから、VPLEXがクラスタを拡張できるようになります。VPLEXディレクトリは階層構造なので、オーバーヘッドが最小限になって効率が良く、遠く離れての I/O通信が可能です。

一貫性のある分散キャッシュVPLEXエンジンには 2つのダイレクタがあり、それぞれ合計 36 GB（バージョン 5ハードウェア、VS2とも呼ばれる）のローカルキャッシュがあります。キャッシュページはボリュームごとにキーづけされており、ステージング、可視、ドレインというライフサイクルを経ます。

グローバルキャッシュは、すべてのクラスタに展開されている全ダイレクタキャッシュの組み合わせです。キャッシュページホルダー情報は、ディレクトリと呼ばれるメモリデータ構造で管理されます。

ディレクトリがチャンクに分割され、所有を管理する VPLEXダイレクタやローカリティコントロール間で分散されます。

メタディレクトリは、グローバルディレクトリ内のどのダイレクタがどのディレクトリチャンクを所有しているかを示します。

VPLEXファミリのクラスタリングアーキテクチャ VPLEXファミリは、独自のクラスタリングアーキテクチャを使用しています。このため、お客様はデータセンターの制約を排除して、複数のデータセンターに設置されているサーバから、共有ブロックとして構成されたストレージデバイスに対する読み取り /書き込みアクセスが可能になります。VPLEXクラスタは、36ページの図 6 に示すように、エンジンを追加することで拡張できます。また、クラスタを EMC VPLEX Metro（都市圏レベルの距離で接続された 2台の VPLEX Metroクラスタ）として接続することでスケールアウトできます。

はじめに 35

36


図 6 VPLEXクラスタの例

VPLEX Metroは、各種アプリケーション、VM、データベース、クラスタファイルシステムのワークロードを透過的に移動および共有します。VPLEX Metroはデータセンターを統合し、データセンター全体としてのリソース使用率を最適化します。さらに、無停止のデータ移動、異機種混在ストレージ管理、アプリケーションの可用性の向上が実現されます。VPLEX Metroはクラスタを 2台までサポートします。これらのクラスタは、同一のデータセンター内か、同期環境内にある 2か所の異なるサイトに配置できます。また、この TechBookにアーキテクチャを示したこれらのソリューションとともに導入された遠距離間の Geoクラスタは、Metroの非同期版に当たります。VPLEX Geo機能の分析については、本書では扱いません。



VPLEXシングル、デュアル、クワッドエンジンVPLEXエンジンにより、冗長ダイレクタにキャッシュと処理能力がもたらされます。各冗長ダイレクタにはそれぞれ I/Oモジュールが2個とオプションのWAN COM I/Oモジュールが 1個あり、VPLEX Metroおよび VPLEX Geo構成で使用できます。

ラック取り付け可能なハードウェアコンポーネントが、NEMA標準ラックに取り付けられて出荷されるか、オプションでフィールドでラックに取り付け可能な製品として供給されます。表 2に構成の一覧を示します。

表 2 構成の概要

コンポーネントシングルエンジン

デュアルエンジン

クワッドエンジン

ダイレクタ 2 4 8

冗長エンジン SPS はいはいはい

FEファイバチャネルポート（VS1）

16 32 64

FEファイバチャネルポート（VS2）

8 16 32

BEファイバチャネルポート（VS1）

16 32 64

BEファイバチャネルポート（VS2）

8 16 32

キャッシュサイズ（VS1ハードウェア）

64 GB 128 GB 256 GB

キャッシュサイズ（VS2ハードウェア）

72 GB 144 GB 288 GB

管理サーバ 1 1 1

内蔵ファイバチャネルスイッチ（ローカル通信）

なし 2 2

UPS（無停電電源装置）なし 2 2

はじめに 37

38


VPLEXサイジングツールEMCグローバルサービスソフトウェア開発部門が提供する EMC VPLEXサイジングツールを使用すると、適切な VPLEXクラスタ構成を設定できます。

このサイジングツールは、インストールされたアプリケーション（メール交換、OLTP、データウェアハウス、ビデオストリーミングなど）の I/Oスループット要件と、仮想ボリュームやストレージボリュームのサイズと容量やイニシエータなどのバックエンド構成を専門に扱います。

アップグレードパスVPLEXでは、VPLEXテクノロジー全体で本番ワークロードをシフトできる柔軟性を活かして、サービスウィンドウなしでアプリケーションやストレージをアップグレードできます。

また、VPLEXクラスタの高可用性機能により、VPLEXハードウェアおよびソフトウェアを無停止でアップグレードできます。

この柔軟性により VPLEXは常に I/Oを処理でき、完全にシャットダウンする必要はありません。

ハードウェアのアップグレードシングルエンジンの VPLEXシステムからデュアルまたはクワッドエンジンシステムへのアップグレードがサポートされています。

新しいリモート VPLEXクラスタを追加すると、シングル VPLEXローカルシステムを再構成して VPLEX Metroまたは VPLEX Geoとして機能させることができます。

また、VPLEX VS1クラスタ（ハードウェア）全体を無停止で VS2ハードウェアに完全アップグレードできます。

VPLEXハードウェアアップグレードに関する情報は、EMC PowerLinkの Procedure Generatorに用意されています。



ソフトウェアアップグレードVPLEXでは、優れた NDU（無停止アップグレード）テクノロジーを使用して、VPLEXエンジンや VPLEX Witnessサーバ上のソフトウェアをアップグレードできます。NDUを実行する前に、マネージメントサーバソフトウェアをアップグレードする必要があります。

VPLEXでは一貫性のある分散キャッシュを採用しているので、アップグレード中は他の VPLEXインストールのダイレクタが I/Oをサービスします。これにより、サービスウィンドウの必要性がなくなり、RTOが低減されます。

NDUは次の手順で行われます。

◆ NDUを行う VPLEXシステムの準備◆ NDUの開始◆ アップグレードされるダイレクタへの I/Oの転送◆ NDUの完了

はじめに 39

40


VPLEXの管理インタフェースVPLEXクラスタ内では、TCP/IPベースの管理トラフィックが、プライベートネットワークサブネット経由で、単一または複数のクラスタに含まれるコンポーネントへ送られます。VPLEX MetroとVPLEX Geoでは、VPLEXが両クラスタのマネージメントサーバ間で VPNトンネルを確立します。VPLEX Witnessが導入されると、VPNトンネルはマネージメントサーバと VPLEX Witnessをどちらも含む 3方向トンネルに拡張されます。

Webベースの GUIVPLEXには管理用にWebベースの GUI（グラフィカルユーザーインタフェース）が備わっています。このインタフェースの使用の詳細については、EMC VPLEX管理コンソールのヘルプを参照してください。

GUIで実行できない他の VPLEX操作の実行方法については、CLIを参照してください。CLIは全機能をサポートしています。「EMC VPLEX CLI Guide」には、VPLEXコマンドの総合リストと各コマンドの詳しい使用方法が記載されています。

EMC VPLEX管理コンソールの主な機能は次のとおりです。

◆ ストレージアレイの検出とプロビジョニングのサポート◆ ローカルプロビジョニング◆ 分散プロビジョニング◆ Mobility Central

◆ オンラインヘルプ

VPLEX CLI

VPlexcliは、VPLEXシステムを構成および操作するための CLI（コマンドラインインタフェース）です。また、EZ Wizard Setupプロセスを生成して、VPLEXのインストールを簡単迅速にします。

CLIはコマンドコンテキストに分かれています。一部のコマンドはあらゆるコンテキストでアクセスでき、「グローバルコマンド」と呼ばれます。



それ以外のコマンドは階層コンテキストツリーに配置されており、該当するコンテキストツリー内の適切なロケーションでのみ実行できます。

VPlexcliには、管理ステーションが使用不可になった場合に備えて、あらゆる機能が取り込まれています。すぐに運用可能で、包括的で、あらゆる構成、プロビジョニング、高度なシステム管理機能をサポートしています。

パフォーマンスの統計のための SNMPサポートVPLEX snmpv2c SNMPエージェントは：

◆ VPLEX-MIB.mibに公開されているパフォーマンス関連の統計情報の取得をサポートしています。

◆ マネージメントサーバ上で稼動し、パフォーマンス関連データをファームウェア固有のインタフェースを使用して個々のダイレクタから取得します。

◆ ローカルクラスタの場合にのみ、ダイレクタの SNMP MIBデータを提供します。

LDAP/ADサポートVPLEXは、認証ディレクトリサービスとして LDAP（Lightweight Directory Access Protocol）または Active Directoryをサポートします。

VPLEX Element Manager API

VPLEX Element Manager APIでは、World Wide Webなどの分散システム用に REST（Representational State Transfer）ソフトウェアアーキテクチャを採用しています。また、ソフトウェア開発者などのユーザーは、APIを使用して VPLEX CLIコマンドを実行するスクリプトを作成できます。

VPLEX Element Manager APIは、ダイレクタ上でルートコンテキストから実行できるすべての VPLEX CLIコマンドをサポートしています。

VPLEXの管理インタフェース 41

42


効率化されたストレージ管理 VPLEXは、さまざまなベンダー製の各種アレイをサポートしており、アクティブ /アクティブとアクティブ /パッシブの両タイプのアレイにも対応しています。VPLEXでは、ストレージ管理を簡素化するため、各種アレイからプロビジョニングされたシンプルな LUNを、使いやすくて直感的な一元管理インタフェースで管理できるようになっています。また、VPLEX Metroや VPLEX Geo環境を両方のデータセンターに展開することで、ストレージ管理者は両方の場所を、どちらかにある単一のインタフェースにローカルサイトからログインして管理できます。



マネージメントサーバのユーザーアカウントマネージメントサーバでは、所定のタスクへのアクセス用にユーザーアカウントをセットアップする必要があります。表 3に、マネージメントサーバに用意されているユーザーアカウントのタイプを示します。

一部のサービスおよび管理者タスクには root権限を要する OSコマンドが必要です。マネージメントサーバは、sudoプログラムを使用してコマンドの実行中だけ root権限を提供するよう構成されています。sudoは、root権限でコマンドを実行できるようにするための、安全で確立された UNIXプログラムです。

VPLEXマニュアルには、どのコマンドの前に sudoを付加して必要な権限を獲得しなければいけないかが示されています。sudoコマンドは、ユーザーが自分のアカウントのパスワードを知っていることを確認するため、初回実行時にユーザーパスワードの入力を求めます。そうすることで、不正ユーザーが開いたままの認証済み SSHログインを見つけても特権コマンドを実行できないようにしています。

表 3 マネージメントサーバのユーザーアカウント

アカウントタイプ目的

admin（お客様） • ユーザー管理などの管理操作の実行• Linux CLIアカウントの作成と削除• 全 Linux CLIユーザーのパスワードリセット• パブリック Ethernet設定の変更

service（EMCサービス）

• 必要な OSおよび VPLEXサービスの開始と停止• ユーザーアカウントの変更は不可• （お客様にこのアカウントへのアクセスあり）

Linux CLIアカウント • VPlexcliを使用した連携ストレージの管理

全アカウントタイプ • VPlexcliの使用• 自分のパスワードの変更• マネージメントサーバへの SSHまたは VNCアクセス

• マネージメントサーバのファイルをディレクトリから自分のアクセスできる場所へ SCP

マネージメントサーバのユーザーアカウント 43

44


マネージメントサーバソフトウェアマネージメントサーバソフトウェアは、製造時にインストールされ、フィールドで完全アップグレード可能です。ソフトウェアには以下が付属しています：

◆ VPLEX管理コンソール◆ VPlexcli

◆ Server Base Image Updates（必要に応じて）◆ オートコールソフトウェアこのセクションではそれぞれについて簡単に説明します。

管理コンソールVPLEX管理コンソールには、VPLEXクラスタを管理するためのGUI（グラフィカルユーザーインタフェース）が用意されています。この GUIを使用して、ストレージのプロビジョニングやシステムパフォーマンスの管理と監視ができます。

45ページの図 7 に示す VPLEX管理コンソールのウィンドウでは、クラスタツリーが展開され、フロントエンドストレージ、バックエンドストレージ、連携ストレージから管理できるオブジェクトが表示されています。



図 7 VPLEX管理コンソール

VPLEX管理コンソールには使用可能な機能すべてのオンラインヘルプが用意されています。オンラインヘルプには以下の方法でアクセスできます。

◆ メインスクリーンの右上隅にある［ヘルプ］アイコンをクリックしてオンラインヘルプシステムを開くか、個々のスクリーンで現在のタスクに関するトピックを開きます。

◆ タスクバーの［ヘルプ］ボタンをクリックして、他の VPLEXマニュアルなどの情報源へのリンク一覧を表示します。

マネージメントサーバソフトウェア 45

46


図 8は VPLEX管理コンソール GUIの初期スクリーンで、ブラウザの Secure HTTP接続を使用しています。インタフェースには Flashテクノロジーを使用し、素早い応答とユニークなルック &フィールを実現しています。

図 8 管理コンソールの初期スクリーン



コマンドラインインタフェースVPlexcliは CLI（コマンドラインインタフェース）で、VPLEXシステムの構成や実行、システムのハードウェアやサイト間リンクのセットアップと監視、グローバルなサイト間 I/Oコストやリンク障害復旧の構成に使用します。この CLIは VPLEXマネージメントサーバのサービスとして実行され、SSH（Secure Shell）を使用してアクセスできます。

VPlexcliの詳細については、「EMC VPLEX CLI Guide」を参照してください。

システムレポートVPLEXシステムレポートソフトウェアは、各クラスタおよび各エンジンから構成情報を収集します。生成される構成ファイル（XML）は zipで圧縮され、マネージメントサーバ上にローカルに保存されるか、オートコール経由で EMCの SYRシステムに提示されます。

週次ジョブをスケジュールして SYRデータを自動収集するか（VPlexcliコマンド scheduleSYR）、必要に応じて随時手動で収集することができます（VPlexcliコマンド syrcollect）。

マネージメントサーバソフトウェア 47

48


ダイレクタソフトウェアダイレクタソフトウェアの機能は次のとおりです。

◆ BIOS（基本 I/Oシステム）：オペレーティングシステムに低レベルハードウェアサポートを提供し、ブート構成を管理します。

◆ POST（電源投入自己診断テスト）：電源投入時にシステムハードウェアを自動でテストします。

◆ Linux：ダイレクタ上で実行される VPlexcliソフトウェアスタックに基本オペレーティングシステムサービスを提供します。

◆ ZPEM（VPLEX Power and Environmental Monitoring）：システムハードウェアステータスの監視 /レポート作成を行います。

◆ ECOM（EMC Common Object Model）：システムの内部コンポーネントに管理ロジックおよびインタフェースを提供します。

◆ ログサーバ：ダイレクタプロセスからログメッセージを収集し、SMSへ送信します。

◆ EMC GeoSynchrony™（I/Oスタック）：ホストからの I/Oを処理し、すべてのキャッシュ処理、レプリケーション、および仮想化ロジックを実行し、要求や I/Oのためにアレイとのインタフェースを取ります。



構成の概要VPLEXの構成は、キャビネットに収まっているエンジンの数が基になります。基本構成はシングル、デュアル、およびクワッドです（従来は小規模、中規模、大規模）。

構成サイズとは、VPLEXキャビネットに収まっているエンジンの数のことです。このセクションのここからは、各構成サイズについて説明します。

シングルエンジン構成VPLEXシングルエンジン構成には以下が含まれます。

◆ ダイレクタ ×2

◆ 1台のエンジン◆ 冗長エンジン SPS

◆ フロントエンドファイバチャネルポート ×8（VS1ハードウェアでは 16）

◆ バックエンドファイバチャネルポート ×8（VS1ハードウェアでは 16）

◆ マネージメントサーバ ×1

50ページの図 9 で、エンジン 1とマネージメントサーバの間にある未使用スペースは意図的に空けてあります。

構成の概要 49

50


図 9 VPLEXシングルエンジン構成

デュアル構成VPLEXデュアルエンジン構成には以下が含まれます。


◆ 2台のエンジン◆ 冗長エンジン SPS






◆ ローカル COM用冗長ファイバチャネル COMスイッチ、各ファイバチャネルスイッチ用 UPS

図 10に、中規模構成の例を示します。

図 10 VPLEXデュアルエンジン構成

クワッド構成VPLEXクワッドエンジン構成には以下が含まれます。


◆ 4台のエンジン

構成の概要 51

52


◆ 冗長エンジン SPS




◆ ローカル COM用冗長ファイバチャネル COMスイッチ、各ファイバチャネルスイッチ用 UPS

図 11に、クワッド構成の例を示します。

図 11 VPLEXクワッドエンジン構成



I/Oの実装VPLEXクラスタは、VPLEX LocalまたはMetroのどちらか向けとして構成された場合にライトスルーモードを使用します。これにより、すべての書き込みがキャッシュ経由でバックエンドストレージに書き込まれます。データの整合性を維持するため、ホスト書き込みに ACKが返されるのは、（VPLEX Localの場合は 1台のクラスタ内の、VPLEX Metroの場合は 2台のクラスタ内の）バックエンドアレイが該当する書き込みに対して ACKを返した後になります。

このセクションでは、VPLEXクラスタのキャッシュレイヤー、およびその役割と相互作用について、概要を説明します。その中で、VPLEXクラスタによる読み取りや書き込みの処理方法と、分散キャッシュ一貫性の仕組みについて、その概要を説明します。これは高可用性関連の概念を理解するうえで重要です。

キャッシュ一貫性キャッシュ一貫性は、ボリュームに対して一貫性のあるグローバルビューを作り上げます。

分散キャッシュ一貫性は、ディレクトリを使用して管理されます。仮想ボリュームごとにディレクトリが 1つあり、各ディレクトリはチャンクに分割されます（それぞれに 4,096件のディレクトリエントリーがあります）。チャンクは、それが使用中の場合のみ存在します。ディレクトリエントリーはグローバルキャッシュページにつき 1件で、次の役割があります。

◆ ページの所有者（複数の場合あり）の追跡と最終書き込み者の記憶

◆ ロックとキューの処理

メタディレクトリディレクトリチャンクはメタディレクトリによって管理されます。メタディレクトリはチャンクの所有を割り当て、記憶します。チャンクは LCDM（Locality-Conscious Directory Migration）を使用して移行できます。このメタディレクトリナレッジは、効率を上げるために共有グループ（つまり、与えられた仮想ボリュームをエクスポートしている、クラスタ内にある複数のダイレクタからなるグループ）にわたってキャッシュされます。

I/Oの実装 53

54


読み取り処理の流れホストが読み取り要求を出すと、VPLEXはまずローカルキャッシュを検索します。そこでデータが見つかった場合は、見つかったデータがホストへ返されます。

データがローカルキャッシュで見つからなかった場合、VPLEXはグローバルキャッシュを検索します。グローバルキャッシュには、VPLEX Localの場合は単一 VPLEXクラスタ内で互いに接続されている全ダイレクタが含まれ、VPLEX Metroと VPLEX Geoの場合はすべての VPLEXクラスタ内で互いに接続されている全ダイレクタが含まれます。読み取りがグローバルキャッシュで処理されると、そのコピーも要求元ダイレクタのローカルキャッシュに格納されます。

読み取りがローカルキャッシュでもグローバルキャッシュでも処理できなかった場合は、バックエンドストレージからの直接読み取りが実行されます。その場合、グローバルキャッシュとローカルキャッシュがどちらも更新されます。

ローカル読み取りヒットの I/Oフロー1. 読み取り要求がホストから仮想ボリュームへ発行されます。

2. 入力ダイレクタのローカルキャッシュを検索します。

3. ヒットした場合、データがローカルキャッシュからホストに返されます。

グローバル読み取りヒットの I/Oフロー1. 読み取り要求がホストから仮想ボリュームへ発行されます。


3. ミスした場合、グローバルキャッシュを検索します。

4. ヒットした場合、データが所有者ダイレクタからローカルキャッシュにコピーされます。

5. データがローカルキャッシュからホストに返されます。

読み取りミスの I/Oフロー1. 読み取り要求がホストから仮想ボリュームへ発行されます。


3. ミスした場合、グローバルキャッシュを検索します。



4. ミスした場合、ストレージボリュームのデータがローカルキャッシュに読み取られます。

5. データがローカルキャッシュからホストに返されます。

6. データを返したダイレクタがチャンク所有者になります。

書き込み処理の流れVPLEX LocalとMetroはどちらでも、すべての書き込みがキャッシュ経由でバックエンドストレージに書き込まれます。ホストへの書き込みが完了するのは、バックエンドアレイへの書き込みが完了した後です。VPLEX Metroの場合、各書き込みは書き込まれたクラスタで複製されます。複製された片方はローカルバックエンドディスクへライトスルーされ、もう片方はリモート VPLEXに書き込まれ、それがリモートバックエンドディスクにライトスルーされます。バックエンドストレージへの両方の書き込み ACKが返されてから、ホスト ACKが返されます。

書き込みミスの I/Oフロー1. 書き込み要求がホストから仮想ボリュームへ発行されます。

2. 以前のデータをローカルキャッシュで検索します。

3. 以前のデータをグローバルキャッシュで検索します。

4. データをローカルキャッシュに転送します。

5. データはバックエンドストレージにライトスルーされます。

6. ホストに書き込み ACKを返します。

書き込みヒットの I/Oフロー1. 書き込み要求がホストから仮想ボリュームへ発行されます。

2. 以前のデータをローカルキャッシュで検索します。

3. 以前のデータをグローバルキャッシュで検索します。

4. 前のデータを無効化します。

5. データをローカルキャッシュに転送します。

6. データはバックエンドストレージにライトスルーされます。

7. ホストに書き込み ACKを返します。

I/Oの実装 55

56



3

この章では、VPLEXクラスタがストレージクラスタ内のどのサブシステムで発生したハードウェア障害にも対処できる仕組みについて説明します。トピックは次のとおりです。

◆ 概要........................................................................................................................................... 58◆ クラスタ................................................................................................................................. 59◆ 複数のポートの使用によるパスの冗長性..................................................... 60◆ 複数のダイレクタの使用によるパスの冗長性.......................................... 61◆ 複数のエンジンの使用によるパスの冗長性............................................... 62◆ サイト分散によるパスの冗長性.......................................................................... 63◆ 保守性...................................................................................................................................... 64

システムとコンポーネントの整合性

システムとコンポーネントの整合性 57

58


概要VPLEXクラスタは、ストレージクラスタ全体の中でどのサブシステムで単一のハードウェア障害が起こってもダウンしません。ホスト接続サブシステムやメモリサブシステムもダウンしません。どのサブシステムで起こった単一の障害も、データの可用性や整合性に影響しません。単一のサブシステムで複数の障害が起こったり、複数のサブシステムで単一の障害が特定の組み合わせで起こった場合は、データの可用性や整合性に影響することがあります。

高可用性のためには、ホスト接続が冗長であることと、ホストにマルチパスドライバが用意されていることが求められます。フロントエンドポート障害やダイレクタ障害が起こった場合、VPLEXクラスタへの冗長な物理接続がなかったりマルチパスソフトウェアがインストールされていなかったりすると、データの可用性が失われやすくなります。



クラスタクラスタとは、1台の物理キャビネットにエンジンが 1台、2台、または 4台集められたものです。クラスタは、単一のストレージドメインの I/Oを処理し、単一のストレージクラスタとして管理されます。

ハードウェアリソース（CPUサイクル、I/Oポート、キャッシュメモリ）はすべてプールされます。

◆ すべてのダイレクタのフロントエンドポートは、クラスタによってエクスポートされる仮想ボリュームへのアクティブ /アクティブアクセスを提供します。

◆ 可用性を最大にするため、仮想ボリュームをすべてのダイレクタ経由で提示しており、1個を残してすべてのダイレクタで障害が発生してもデータや可用性は失われません。この動作をバージョン 5.0.1以下のコードで実現するためには、ダイレクタをすべてのストレージに接続することが必要です。

注：デュアルまたはクワッドエンジンシステムの場合は、瞬間的にでも 1個を残してすべてのダイレクタで障害が発生すると、残った最後のダイレクタはクォーラムを失い、やはり障害が発生します。よって、前述が成り立つのは障害の発生したダイレクタが一度に 1個の場合に限られます。

クラスタ 59

60


複数のポートの使用によるパスの冗長性すべてのパスが重複していることから、あるダイレクタポートが何らかの理由でダウンしても、データは他のダイレクタのポート経由でシームレスに処理されます。この様子を図 12に示します（適切なマルチパスソフトウェアがインストールされていることが前提）。

図 12 ポートの冗長性

マルチパスソフトウェアを導入し、冗長ボリュームを用意することで、ポートに障害が発生しても継続的なデータ可用性がもたらされます。



複数のダイレクタの使用によるパスの冗長性ダイレクタがダウンした場合、もう一方のダイレクタがホストからI/O処理を完全に引き継ぐことができます。この様子を図 13に示します。

図 13 ダイレクタの冗長性

マルチパスソフトウェアを導入し、複数のダイレクタでボリュームを提示することで、ダイレクタに障害が発生しても継続的なデータ可用性がもたらされます。

複数のダイレクタの使用によるパスの冗長性 61

62


複数のエンジンの使用によるパスの冗長性クラスタ環境では、片方のエンジンがダウンしても、もう片方のエンジンがホスト I/O処理を完了させます。この様子を図 14に示します。

図 14 エンジンの冗長性

マルチパスソフトウェアを導入し、複数のエンジンでボリュームを提示することで、エンジンに障害が発生しても継続的なデータ可用性がもたらされます。



サイト分散によるパスの冗長性分散サイト冗長性が VPLEX Metro HA（VPLEX Witnessを含む）を通じて実現されると、サイトがダウンしても、サイトへのリンクがダウンした場合でも、もう一方のサイトは引き続きシームレスにホスト I/Oを処理できます。その様子を図 15に示します。図に示されているように、サイト Bでサイトの障害が発生しても、I/Oは引き続きサイト Aで支障なく処理されます。

図 15 サイトの冗長性

サイト分散によるパスの冗長性 63

64


保守性VPLEXクラスタは、冗長性フェイルセーフ機能に加えて、ESRS（EMC Secure Remote Support）を通じたイベントログとオートコールの機能を備えています。


4

この章では、VPLEXのアーキテクチャと運用について説明します。

◆ VPLEXの高可用性の基盤........................................................................................ 66◆ VPLEX Witnessなしでの障害処理（静的な選択）................................. 74

VPLEXの高可用性の基盤

VPLEXの高可用性の基盤 65

66


VPLEXの高可用性の基盤ここでは、VPLEX Witnessなしの複数サイト VPLEX Metro構成に対する停止シナリオをいくつか高レベルで見ていきます。このセクションの目的は、お客様やソリューションアーキテクトが、サイトの障害のセマンティクスや本書で概要を説明している関連ソリューションを VPLEX Witnessの導入前に理解することです。VPLEX Witnessなしの場合における、基本的な VPLEXベストプラクティスをふまえて導入された高可用性アーキテクチャの欠点を取り上げるためではありません。Metroアクティブ /アクティブ状態に導入されているどのソリューションも、VPLEXであろうとなかろうと、独立しているオブザーバや「witness（目撃者、証人の意）」（VPLEX Witnessのような）の導入なしには同じ問題に直面します。VPLEX Witness機能を適用するか、またはMetro HA Cross-Cluster Connectソリューションを使用してデータセンターどうしの接続パスを拡張するか、アーキテクトがどちらを選ぶかは、基本的なフェイルオーバーのニーズに応じて決まります。

注：このセクションでは、この件に関する説明を高レベルで行うために、主要オブジェクト（サイト A、サイト B、リンク）を単位に図示しています。各サイト内に VPLEXクラスタが存在するとお考えください。したがって、サイトの障害が示されていたら、そのサイト内で VPLEXクラスタで全面的な障害が発生しているという意味になります。また、サイト間のリンクオブジェクトは、どちらのサイトでも各 VPLEXクラスタに接続されているメインのクラスタ間データネットワークを表していることも想定できます。加えて、各サイトが同じ障害ドメインを共有することが前提とされています。サイトの障害は、VPLEXクラスタを含めてこの障害ドメイン内のすべてのコンポーネントに影響します。

先ほど説明したとおり、図 16のような描き方は、3つのコンポーネントすべてがフル稼動している標準運用を示しています（注：緑色は標準運用、赤色は障害）。

図 16 高レベルで見た通信可能な稼動サイト



図 17は、サイト Aで障害が発生していることを示しています。

図 17 高レベルで見たサイト Aの障害

このインシデントの時点でアプリケーションまたは VMがサイト Aだけで実行されていた場合、正常なサイト Bで再開する必要があります。このことは本書の読者には一目瞭然ですが、それは図全体を見渡せる外からの視点があるからです。ところが、純粋にサイト Bからの視点で見ると、サイト Aとの通信が失われたということしかわかりません。外部の独立しているオブザーバのようなものがないと、全面的なサイト A障害とクラスタ間のリンク障害とを区別できません。

図 18で赤い矢印で示されているリンク障害は、クラスタ間のリンク障害を表しています。

図 18 高レベルで見たサイト間のリンク障害

前の例と同様、全体を俯瞰すると、障害が発生しているのはリンクだとわかります。ところが、同じことをサイト Aまたはサイト Bの視点で見ると、もう片方のサイトへの通信が失われたことしかわからず（前の例とまったく同じ）、リンクとサイトのどちらに障害が発生したかは区別できません。


68


次のセクションでは、障害によって VPLEX分散ボリュームへの影響がどう違ってくるかを示し、それぞれのケースで必要となるさまざまな解決策をサイトの障害シナリオから始めて説明します。高レベルで見た図 19では、VPLEX分散ボリュームが 2か所のサイトに展開されています。

図 19 VPLEXが 2サイト間でアクティブかつ稼動中

図に示されているとおり、分散ボリュームは各サイトのミラー（M1とM2）からなっています。VPLEX GeoSynchronyが提供する分散キャッシュ一貫性セマンティクスにより、論理ボリュームの一貫したデータ提供が両クラスタにわたって実現されています。さらに、キャッシュ一貫性により、2か所のサイトからのアクティブ /アクティブデータアクセス（読み取り /書き込みの両方）が可能です。この例では他にも、ユーザーがどちらのサイトにアクセスしても真の完全なアクティブ /アクティブ環境である分散ネットワークが示されています。



図 20では、片方のサイトで全面的な障害が発生しています（図ではサイト Aで障害発生）。この場合、分散ボリュームは縮退します。該当するミラーボリュームをサポートするためにサイト Aで必要とされるハードウェアが使用できなくなるからです。この例に対する解決策では、ボリュームをサイト Bでアクティブにし、アプリケーションをそちらで再開できるようにします。

図 20 サイト Aで障害が発生した状態の VPLEX概念図


70


図 21は、サイト Aで障害が発生した場合の望ましい解決策を示しています。先ほど説明したように、この適切な結果はボリュームのオンライン状態をサイト Bで維持することです。

図 21 サイト Aでボリューム障害が発生した後の適切な解決策

74ページの「VPLEX Witnessなしでの障害処理（静的な選択）」で、クラスタ間リンクパーティション /障害後の結果について説明しています。



図 22に、障害前の構成を示します。

図 22 VPLEXが 2サイト間でアクティブかつ稼動中

サイト A/サイト Bのシンプルな障害シナリオからわかるように、リンクに障害が発生すると、どちらのサイトから見ても実際に何の障害なのかがわかりません。アクティブ /アクティブ分散ボリュームの場合、リンク障害により分散ボリュームが縮退します。これはどちらのサイトでも書き込み I/Oによるリモートサイトへの反映ができなくなるからです。


72


図 23は、このシナリオにおいて片方のサイトで I/Oを中断するメカニズムがない場合にどうなるかを示しています。

図 23 サイト間のリンク障害とクラスタパーティション

図に示されているように、これによりスプリットブレインが発生します（VPLEX用語では「接続解除の競合」）。書き込みがどちらのサイトでも受け付けられ、不一致の存在するデータが 2つできる可能性があるからです。データ破損を避けるため、この状況を回避する必要があります。それには、VPLEXがアクションを起こし、片方のクラスタ上の分散ボリュームへのアクセスを中断させる必要があります。



図 24は、リンクパーティションに対して有効で許容される状態を示しており、ここではサイト Aが中断されています。この優先動作（クラスタごとに選択可能）は VPLEX分散ボリュームのデフォルトの自動動作であり、データ破損やスプリットブレインのシナリオからの保護になります。次のセクションでは、この機能の仕組みについて詳しく説明します。

図 24 クラスタパーティションに対する適切な処理


74


VPLEX Witnessなしでの障害処理（静的な選択）先に示したとおり、VPLEXアクティブ /アクティブ分散ソリューションで障害が発生した際には、障害のタイプに応じて異なる解決策を必要とします。しかし、VPLEXバージョン 4.0では外部調停を行う手段がなく、サイトの障害とリンク障害を区別する「メカニズム」がありませんでした。この状況を克服するため、「静的な選択」（従来は「静的なバイアス（Static Bias）」）と呼ばれる機能を使用して、スプリットブレインシナリオが起こらないようにします。

静的な選択では、2台の VPLEXクラスタに展開されている各分散ボリューム（または分散ボリュームのグループ）に対し、障害が起こる前にデタッチルールのセットを設定する前提になっており、実質的に、どちらを優先クラスタと宣言してボリュームへのアクセスを維持し、どちらを非優先クラスタと宣言するか、言い換えるとアクセスの中断によってどちらの VPLEXクラスタが相手との通信を失うかを定義しています（サイトの障害もリンク障害もこの概念の対象）。つまり、デタッチルールにより、片方のサイトは一方的に他のクラスタをデタッチし、デタッチされたクラスタを使用不可であると想定するか、使用可能かもしれないが中断されていると想定することになります。

注： VPLEX Metroでは「自動優先クラスタなし」ルールセットもサポートされています。コンシステンシグループがこの設定で構成されると、リンクがパーティションされるか VPLEXクラスタが全体として障害に陥るかした場合に、IOは両方の VPLEXクラスタで中断されます。その場合は、必要に応じて手動介入により正常なクラスタで IOを再開できます。このポリシーを設定する際は注意が必要です。というのも、これにより両方のVPLEXクラスタが常に同じままになりますが、それと引き換えに本番環境が停止するからです。この動作は、VPLEXフェイルオーバーセマンティクスをアプリケーション駆動のフェイルオーバー動作と統合したい場合に便利です（アプリケーションに独自の witnessがある場合など）。その場合、アプリケーションは、選択した VPLEXクラスタで CLIコマンド resumeを呼び出すスクリプトを提供できます。



図 25に、静的な選択を各分散ボリューム（DR1：分散 RAID 1とも呼ばれる）にどのように設定できるかを示します。

図 25 VPLEXの静的デタッチルール

このデタッチルールは VPLEX GUIまたは VPLEX CLIを使用して設定できます。

各ボリュームは、クラスタ 1デタッチ、クラスタ 2デタッチ、自動優先クラスタなしのどれかに設定できます。

DR1（分散 RAID 1）デバイスがクラスタ 1デタッチに設定されると、どの障害シナリオでも該当ボリュームに対して選択されるクラスタはクラスタ 1であると宣言され、DR1デタッチルールがクラスタ 2デタッチに設定されると、どの障害シナリオでも該当ボリュームに対して選択されるクラスタはクラスタ 2であると宣言されます。

注：この説明を聞くと「デタッチする」を「選択する」や「勝つ」に言い換えたくなるかもしれませんが、そうしてまったく問題なく、その方が理解しやすいかもしれません。

VPLEX Witnessなしでの障害処理（静的な選択） 75

76


ボリュームをクラスタ 1デタッチにするルールセットを設定すると、そのボリュームについてはクラスタ 1が優先サイトになります（「そのボリュームにはクラスタ 1へのバイアスがある」という言い方もできます）。

このルールが設定されると、障害に関係なく（リンクでもサイトでも）、このルールが必ず呼び出されます。

注：ここで、優先クラスタでの BE状態が期限切れの場合（BE障害、不完全な再構築、などの問題により）、選択に関係なく優先クラスタが I/Oを中断することに注意してください。

以降の図に、さまざまな障害で実際に機能しているルールセットの例をいくつか示します。最初は、単一の DR1がクラスタ 1デタッチに設定されているサイト Bが停止した場合です。

図 26に、構成の初期実行セットアップを示します。ボリュームはクラスタ 1デタッチに設定されています。

図 26 典型的なデタッチルールセットアップ



サイト Bで問題が発生すると、図 27のように、DR1が縮退します。

図 27 非優先サイトの障害


78


選択ルールがクラスタ 1デタッチに設定されているので、図 28のように、分散ボリュームはサイト Aで引き続きアクティブです。

図 28 ボリュームはクラスタ 1で引き続きアクティブ

したがって、このシナリオでは、サイト A（優先サイト）でのみ実行されていたサービス、アプリケーション、VMは、再起動を要さず中断なしに動作を継続します。一方、アプリケーションが分散ボリュームのサイト Bでだけ実行されていた場合、サイト Aでの再起動が必要になりますが、この場合 VPLEXはアクティブ /アクティブソリューションなので、ストレージレイヤーでの手動介入は要りません。



次の例では、リンク障害の状況下で機能する静的な選択を示します。

図 29の構成では、前の構成と同様に分散ボリュームがクラスタ 1デタッチに設定されています。

図 29 リンク障害前の典型的なデタッチルールセットアップ


80


この状態からリンクが失われると、図 30のように、分散ボリュームはやはり縮退します。

図 30 サイト間のリンク障害とクラスタパーティション

このタイプの障害が発生した後にスプリットブレインが起こらないようにするため、この場合静的な選択ルールを適用し、クラスタ 2で I/Oを中断します（ルールがクラスタ 1デタッチに設定されているため）。



これを図 31に示します。

図 31 サイト間リンク障害後の中断とクラスタパーティション

したがって、このシナリオにおいて、サイト Aでのみ実行中だったサービス、アプリケーション、VMは、再開を要さず無停止で動作を継続できます。一方、アプリケーションがサイト Bでのみ実行中だった場合はサイト Aでの再開が必要です。それは選択ルールセットに従ってクラスタ 2上の所定の分散ボリュームへのアクセスが中断されるからです。クラスタ 1のボリュームは自動的に使用可能な状態が保たれるので、この場合、やはりストレージレベルでの手動介入は要りません。

このように、静的な選択はスプリットブレインを防ぐ非常に効果的な方法です。ただし、静的な選択の機能だけを使用する場合に、手動介入が必要となる特定のシナリオがあります。それは、VPLEXクラスタまたはサイトの障害が「優先クラスタ」（所定の分散ボリュームに対して事前に定義された優先クラスタなど）に発生した場合です。


82


これを示したのが図 32で、クラスタ 2デタッチが設定されている分散ボリュームが DR1に存在しています。

図 32 クラスタ 2が優先



この例においてサイト Bで全面的な障害が発生すると、図 33に示すように、サイト Aでもシステム停止が発生します。

図 33 優先サイトの障害でデータが全面的に使用不可に

図からわかるように、優先サイトで障害が発生したため選択ルールが使用されていますが、このルールは「静的」であり、リンク障害とリモートサイトの障害を区別できないため、この例では正常なサイトが中断されています。したがって、サイト Aでボリュームをオンラインにするために手動介入が必要になります。

静的な選択は非常に強力なルールです。なにしろ、非優先クラスタの障害やクラスタ間パーティションのシナリオにゼロ RPOかつゼロRTOをもたらす上、スプリットブレインを完全に防ぎます。しかし、優先クラスタで障害が発生すると、RTOがゼロではなくなります。それでも、VPLEX Witness構成（次章で説明します）が使用不可の場合、またはお客様のインフラストラクチャに第 3の障害ドメインがなく融通が利かない場合に、この機能は自動化なしで使用でき、貴重な代替措置となります。


84


VPLEX Witnessはこの非ゼロ RTOシナリオに対処するために設計されており、静的な選択をオーバーライドし、非優先サイトをアクティブなままにすることで、スプリットブレインシナリオを常に回避します。

注： VPLEX Metroを VPLEX Witnessなしで導入して使用しているケースで優先クラスタが失われた場合、IOは正常な（非優先）VPLEXクラスタでCLIを使用して手動で再開できます。ただし、接続解除の競合またはスプリットブレインのシナリオを回避するよう注意が必要です（もちろん、VPLEX Witnessならこの問題を自動的に解決します）。


5


◆ VPLEX Witnessの全体像とアーキテクチャ.............................................. 86◆ VPLEX Witnessのターゲットソリューション、ルール、ベストプラクティス ...................................................................................... 89

◆ VPLEX Witnessの障害セマンティクス......................................................... 91◆ CLIの出力例...................................................................................................................... 97

VPLEX Witnessの概要

VPLEX Witnessの概要 85

86


VPLEX Witnessの全体像とアーキテクチャVPLEX Metro v5.0（以上）のシステムで、VPLEX Witnessという新コンポーネントを使用できるようになりました。VPLEX Witnessはオプションのコンポーネントで、サイト災害、VPLEXクラスタ障害およびクラスタ間障害の発生時にシームレスなゼロまたはゼロに近い RTOストレージ可用性を実現するのに標準的な選択ルールセットでは不十分なお客様の環境に導入できるよう設計されています。

前のセクションで説明したように、VPLEX Witnessなしの場合、クラスタのパーティションやクラスタ /サイトの障害の発生時に、すべての分散ボリュームが構成済みのルールセットに頼って優先クラスタを特定します。ところが、設定されている優先クラスタに障害が発生すると（災害などで）、影響を受けた分散ボリュームへの I/Oを正常な方のクラスタが引き続き自動的に受け継ぐことを VPLEXが許可しません。VPLEX Witnessはこのケースに対処するために設計されました。

単一の障害がクラスタと VPLEX Witnessの両方に影響する可能性を排除するために、どちらの VPLEXクラスタでもない障害ドメインにお客様が用意した VMware ESXホスト上で実行されている仮想マシンとして、外部 VPLEX Witnessサーバが導入されます。VPLEX Witnessは両方の VPLEXクラスタに管理 IPネットワーク経由で接続します。VPLEX Witnessは、クラスタから定期的に報告される情報と独自の観察結果を照合することで、クラスタ間のネットワークパーティション障害とクラスタの障害を区別し、これらの状況に陥っている I/Oを、クラスタが自動的に再開できるようにします。

87ページの図 34 に、高レベルで見た VPLEX Witnessの導入と、それにより既存の静的な選択のソリューションが強化される様子を示します。VPLEX Witnessサーバは、VPLEXクラスタ 1およびクラスタ 2とは別個のフォルトドメインに存在します。



図 34 高レベルで見た VPLEX Witnessアーキテクチャ

VPLEX Witnessサーバはどちらの本番ロケーションに対しても外部にあるので、個々の障害の種類をより広い視野で見て適切なアクションを起こすことができます。前にも説明したとおり、この視野の広さがサイトの停止とリンクの停止を見分けるのに重要で、どちらの障害かに応じて必要なアクションも違ってきます。

VPLEX Witnessの全体像とアーキテクチャ 87

88


図 35に、VPLEX Witnessサーバをどのように接続すべきかに関する高レベルの回路図を示します。

図 35 高レベルで見た VPLEX Witnessの導入

VPLEX Witnessサーバは、第 3の障害ドメインにある VPLEX管理IPネットワーク経由で接続されます。

対策の対象となるシナリオに応じて、この第 3のフォルトドメインは VPLEXクラスタ 1やクラスタ 2と同じビル内の異なる階に配置できます。また、他国の場合も含めて地理的にまったく離れたデータセンター内に配置することもできます。

注： VPLEX Witnessサーバは、管理 IPネットワークで最大 1秒のネットワークレーテンシーをサポートします。

言うまでもなく、同じビルの 3階の例は、ビル全体に影響を及ぼす災害への備えにならないので、要件に応じてこのような第 3の障害ドメインを選択する場合は入念な検討が必要です。



VPLEX Witnessのターゲットソリューション、ルール、ベストプラクティス

VPLEX Witnessのアーキテクチャは VPLEX Metroクラスタ向けに設計されています。VPLEX Localを使用する予定の場合、VPLEX Witness機能は要りません。

また、VPLEX Witnessが適しているのは、第 3の障害ドメインが 2つの物理ネットワークで各データセンターと接続されており、データセンターで VPLEXクラスタが各 VPLEX管理ステーションのEthernetポートに接続されている場合に限られます。

VPLEX Witnessが有効の場合に VPLEX Witnessの障害処理セマンティクスが適用されるのは、VPLEX v5.xクラスタのペア上に存在するあらゆる同期（Metroなど）コンシステンシグループ内の分散ボリュームのみです。

VPLEX Witnessの障害処理セマンティクスは以下には適用されません。

◆ IBM上の

◆ コンシステンシグループ外にある分散ボリューム◆ VPLEX Witnessが無効の場合は、コンシステンシグループ内にある分散ボリューム

◆ 選択ルールが自動優先クラスタなしに設定されている場合は、コンシステンシグループ内にある分散ボリューム

本書の執筆時点では、所定のMetroシステムに構成できる VPLEX Witnessサーバは 1つだけで、それが構成され有効にされると、障害セマンティクスはすべての構成済みコンシステンシグループに適用されます。

また、単一の VPLEX Witnessサーバ（仮想マシン）がサポートできるのは単一の VPLEX Metroシステムだけです（ただし、単一の物理 ESXホスト上で複数の VPLEX Witnessサーバを構成できます）。

VPLEX Witnessのターゲットソリューション、ルール、ベストプラクティス 89

90


図 36に、VPLEX Witnessに対応しているバージョン（本書の執筆時点）を示します。

図 36 VPLEX Witness対応の VPLEXバージョン

図 36に示されているように、ソリューションによっては、VPLEXと静的な選択だけでも VPLEX Witnessなしで用が足るケースもあります。図 37に、VPLEX Witnessがサポートしているボリュームタイプとルールを示します。

図 37 ボリュームタイプとルールの VPLEX Witnessによるサポート状況

VPLEX Witnessサーバの物理ホスト要件やサイト認定の詳細については、https://elabnavigator.emc.comの［Simple Support Matrix］タブにある最新の VPLEX ESSM（EMC Simple Support Matrix）を参照してください。



VPLEX Witnessの障害セマンティクス前のセクションで見たように、VPLEX Witnessは分散デバイスからなるグループに対してはコンシステンシグループレベルで動作し、そのコンシステンシグループ内のデタッチルールセットと連携して機能します。

ここからは、クラスタ間リンクのパーティションから始めて、前のセクションで提起した（サイトとリンクの両方の）障害シナリオの場合について説明し、VPLEX Witnessを使用した場合の障害セマンティクスが静的な選択だけを使用した場合とどう違うかを示します。

図 38に、コンシステンシグループ内に構成された単一の分散ボリュームを使用する VPLEX 5.xに対する典型的なセットアップを示します。このコンシステンシグループは、クラスタ 2デタッチ用に構成されている（クラスタ 2が優先される、などの）ルールセットを持っています。また、示されているように、VPLEX Witnessサーバが第 3の障害ドメインから管理ネットワーク経由で接続されています。

図 38 典型的な VPLEX Witness構成

VPLEX Witnessの障害セマンティクス 91

92


このシナリオでクラスタ間リンクに障害が発生しても、VPLEX Witnessは引き続き両方の VPLEXクラスタと通信できます。VPLEX Witnessサーバからどちらの VPLEXクラスタへの管理ネットワーク接続も依然として稼動しているからです。両方の VPLEXクラスタと通信することで、VPLEX Witnessは障害の発生場所がクラスタ間リンクだと判断します。どちらの VPLEXクラスタもVPLEX Witnessサーバに対してリモートの VPLEXクラスタとの接続が失われたと報告してくるからです（クラスタ 1がクラスタ 2は使用不可だと報告し、逆も同じ、など）。これを図 39に示します。

図 39 VPLEX Witnessとクラスタ間リンク障害

この場合、VPLEX Witnessは両クラスタに対し、事前構成された静的な選択のルールに従うよう指示し、ルールセットでクラスタ 2デタッチが構成されていることからクラスタ 1のボリュームアクセスが中断されます。



図 40は、この障害後の最終状態を示します。

図 40 クラスタパーティション後の VPLEX Witnessと静的な選択

次の例は、優先サイトでサイトの障害が発生した場合の VPLEX Witnessによる支援を示します。前に説明したように、VPLEX Witnessなしでこのタイプの障害が起こると、正常なサイトのボリュームがオフラインになります。これこそ、VPLEX Witnessによって対処が大きく改善され、手動介入の必要性が排除されるケースです。


94


図 41に、コンシステンシグループ内に構成された単一の分散ボリュームを使用する VPLEX v5.xに対する典型的なセットアップを示します。このコンシステンシグループは、クラスタ 2デタッチ用に構成されている（クラスタ 2が優先される、などの）ルールセットを持っています。

図 41 VPLEX Witnessの典型的なクラスタ 2デタッチ用構成



図 42では、サイト Bに障害が発生しています。

図 42 クラスタ 2で障害が発生したときの VPLEX Witnessの図

前のセクションで説明したように、サイトで障害が発生すると、分散ボリュームが縮退します。ただし、サイトの障害が発生したのが優先サイトで、静的な選択のルールが使用されてクラスタ 1のボリュームが強制的に中断された場合は、前の例とは違って、VPLEX Witnessはクラスタ 1との通信が引き続き可能（しかしクラスタ 2とは不可能）と判断します。また、クラスタ 1がクラスタ 2と通信できないため、VPLEX Witnessは情報に基づいて判断を下し、クラスタ 1に対して、静的なルールセットをオーバーライドして I/Oを処理するよう指示します。


96


図 43にその結果を示します。

図 43 VPLEX Witnessと静的な選択のオーバーライド

静的な選択のルールセットだけを使用し、VPLEX Witnessを使用しない場合の結果と比べて、これは明らかに大きな改善になっています。前の例では、クラスタ 1のボリュームを中断しなければならなかったため、サイトの障害とリンク障害を区別できませんでした。



CLIの出力例VPLEX Witnessが導入され構成されているシステムでは、VPLEX Witness CLIコンテキストが rootコンテキストの下に「cluster-witness」として表示されます。デフォルトでこのコンテキストは非表示で、cluster-Witness configureコマンドを実行してVPLEX Witnessが導入されるまで表示されません。VPLEX Witnessが導入されると、VPLEX Witness CLIコンテキストが表示されます。

CLIコンテキストには通常、以下のような情報が表示されます。VPlexcli:/> cd cluster-witness/ VPlexcli:/cluster-witness> ls 属性 :Name Value------------- -------------admin-state enabledprivate-ip-address 128.221.254.3public-ip-address 10.31.25.45

Contexts:コンポーネント [Replication Manager:こんぽーねんと ]

VPlexcli:/cluster-witness> ll components/ /cluster-Witness/components:

Name ID Admin State Operational State Mgmt Connectivity---------- -- ----------- ------------------- -----------------cluster-1 1 enabled in-contact okcluster-2 2 enabled in-contact okserver - enabled clusters-in-contact ok

VPlexcli:/cluster-Witness> ll components/* /cluster-Witness/components/cluster-1:Name Value----------------------- ------------------------------------------------------admin-state enableddiagnostic INFO:Current state of cluster-1 is in-contact (last state change:0 days, 13056 secs ago; last message from server:0 days, 0 secs ago.)id 1management-connectivity okoperational-state in-contact

/cluster-witness/components/cluster-2:Name Value----------------------- ------------------------------------------------------admin-state enableddiagnostic INFO:Current state of cluster-2 is in-contact (last

CLIの出力例 97

98


state change:0 days, 13056 secs ago; last message from server:0 days, 0 secs ago.)id 2management-connectivity okoperational-state in-contact

/cluster-Witness/components/server:Name Value----------------------- ------------------------------------------------------admin-state enableddiagnostic INFO:Current state is clusters-in-contact (last state change:0 days, 13056 secs ago.) (last time of communication with cluster-2:0 days, 0 secs ago.) (last time of communication with cluster-1:0 days, 0 secs ago.)id -management-connectivity okoperational-state clusters-in-contact

VPLEX Witness CLIの詳細については、PowerLinkに用意されている「VPLEX CLI Guide」を参照してください。

VPLEX Witnessのクラスタ分離セマンティク

スと二重障害

前のセクションで議論したように、VPLEX Witnessを使用するVPLEXソリューションでは、サイトの障害かクラスタ間リンク障害かに関係なく、ストレージボリュームに継続的な可用性がもたらされます。こうしたタイプの障害は単一コンポーネント障害と見なされます。そして VPLEX Witnessを使用する場合、単一障害点によってデータ使用不能に陥ることはありません。

ただし、まれに障害やコンポーネント停止が複数起こりうることに注意が必要です。特にクラスタ間通信リンクの場合、一度に 2つで障害が発生すると、該当サイトで VPLEXクラスタが分離されます。

たとえば、VPLEX Witnessを使用する典型的な VPLEXセットアップを検討する場合、障害ドメインの数は自動的に 3つに決まります（この例では Aと Bと Cを使用し、VPLEXクラスタ 1は Aに、VPLEXクラスタ 2は Bに、VPLEX Witnessサーバは Cにあります）。この場合、Aと B（クラスタ 1と 2）の間にクラスタ間リンクが、Aと Cの間に管理 IPリンクが、Bと Cの間に管理 IPリンクがあり、実質的に三角形のトポロジーになります。

まれではありますが、Aと Bの間でリンク障害が発生し、続いて Aと Cまたは Bと Cの間でリンク障害が発生した場合は、どちらかのサイトが分離（切断）されます。

VPLEX Witnessの特性により、このタイプの分離も手動介入を要さず効果的に対処できます。



この動作を実現できるのは、サイトの分離が技術的な振る舞いの点でサイトの全面的な停止にたいへんよく似ているからで、大きな違いは、分離されたサイトは引き続きフル稼動中で電源がオンなのに対し（I/Oの中断を強制する必要がありますが）、サイトの障害では障害の発生したサイトが稼動していないことです。

このようなケースでは、障害セマンティクスと VPLEX Witnessは実質的に同じです。ただし、分離されたサイトでは次に挙げるもう 2つのアクションが起こされます。

◆ 分離されたサイトの I/Oが停止 /中断される。◆ VPLEXクラスタがオートコールを試行する。図 44に、ここまで説明した 3つのシナリオを示します。

図 44 二重障害によるクラスタ分離が起こりうるシナリオ

先に説明したように、二重障害が起こるのはきわめてまれで、図 44は VPLEXが自動的に分離シナリオに対応する様子を示しています。ただし、二重障害が起こり、VPLEX Witnessが実際の障害を特定できず、片方の VPLEXクラスタでの手動介入が必要になる可能性は他にもあります。

注：ベストプラクティスに従っていれば、そうしたシナリオが起こる可能性は先に議論したまれな分離インシデントが起こる確率よりも著しく低くなります。その主な理由は、遠く離れた場所のまったく異なる障害ドメイン内にあるコンポーネントの稼動が障害により中断されなければならないからです。

CLIの出力例 99

100


図 45に、二重障害の発生で正常なコンポーネントのオンライン化に手動介入を要する 3つのシナリオを示します。手動介入が必要なのは、VPLEX Witnessが障害の重大さを判定できないからです。

図 45 手動介入を要する、きわめて起こりにくい二重障害シナリオ

前述のシナリオの注意点としては、示されているとおりの結果になるのは障害が決まった順序で起こった場合、すなわち VPLEX Witnessへのリンク（またはWitnessそのもの）に障害が発生してから、クラスタ間リンクまたは VPLEXクラスタに障害が発生した場合であることです。これに対し、障害の発生順序が逆になると、3つのケースすべてにおいて結果が変わってきます。なぜなら、該当する分散ボリュームに対して VPLEXクラスタのどちらかはオンラインのままになり、手動介入が不要になるからです。

このようになるのは、障害が発生すると VPLEX Witnessが VPLEXクラスタに指示を出すからです。この指示には「持続性」があり、ひとたび出されると、システムがフル稼動状態に戻るまで（つまり、全面的に復旧し、両クラスタと VPLEX Witnessの接続性が完全にリストアされるまで）、その後の障害中に別の指示は仰がれません。



VPLEX Witness：第 3の障害ドメインの重要性前のセクションで説明したように、二重障害は起こりえますがきわめてまれです。また、この TechBookで繰り返し述べているとおり、VPLEX Witnessを導入するのであれば、VPLEX Witnessサーバコンポーネントは 2台の VPLEXクラスタのどちらでもない別の障害ドメイン内にインストールする必要があります。

図 46に、二重障害シナリオをもう 2つ、片方の VPLEXクラスタとVPLEX Witnessサーバで障害が発生した場合を示します。

図 46 手動介入を要する 2つのさらなる二重障害シナリオ

ここでも、ベストプラクティスに従って各コンポーネントが専用のフォルトドメイン内に存在していれば、この 2つの状況は手動介入を要する前述の 3つのシナリオと同じくらいまれになります。しかしここで、VPLEX Witnessサーバが第 3の障害ドメインにではなくVPLEXクラスタのどちらかに導入されていたらどうなるかを検討してみましょう。

その状況では、単一のドメイン障害で二重障害が起こる可能性があります。なぜなら、2つのコンポーネントが同じ障害ドメイン内に存在する可能性があるからです。これにより実質的に、まれなシナリオがもっと可能性の高い単一障害シナリオとなるので、このようなやり方は避けるべきです。

CLIの出力例 101

102


VPLEX Witnessサーバを第 3の障害ドメインに導入することで、二重障害のリスクは著しく低下し、そのため手動介入は不要になります。単一の障害で、障害ドメインの枠を超えて数百キロも離れたところにあるような複数の異なるコンポーネントを無効化する事態でなければならないからです。

注： VPLEX Witnessを使用する場合は、ESRSとアラートをフル構成しておくことが常にベストプラクティスと見なされます。そうすることで、VPLEXクラスタがWitnessサーバとの通信を失ったとしても、VPLEXクラスタはオートコールでアラートを通知できます。加えて、両方の VPLEXクラスタがWitnessとの通信を失ったうえ、Witnessの通信またはシステム停止が長時間続くことが予想される場合に、Witnessの機能を手動で無効にできるようになります。そのため、VPLEXクラスタ障害またはWANパーティションが追加発生した場合でも、データ使用不可のリスクが低減されます。


6


◆ VPLEX Metro HAの概要...................................................................................... 104◆ VPLEX Metro HAキャンパス（クロス接続あり）.............................. 105◆ VPLEX Metro HA（クラスタ間接続なし）............................................... 115

VPLEX Metro HA

VPLEX Metro HA 103

104

VPLEX Metro HA

VPLEX Metro HAの概要技術的な観点で見ると、VPLEX Metro HAソリューションとは実質的に、2種類の新しいリファレンスアーキテクチャだと言えます。VPLEX Witnessという新機能を VPLEX v5.0で使用することで、コンポーネントの障害に対抗するソリューション全体としての能力が大きく強化され、システム停止が従来のソリューションより減るかなくなり、キャンパス間や都市間のような距離でも手動介入をほとんどあるいはまったく要らなくなります。

VPLEX Witnessによって実現されるその 2種類の主なアーキテクチャは次のとおりです。

◆ VPLEX Metro HAキャンパス：キャンパス間距離（通常は RTT 1 ms未満）内にあるクラスタと定義されます（RTTは Round Trip Timeの略で、「往復時間」のこと）。このソリューションでは、クロス接続されたフロントエンドホストパス構成を使用して、各ホストに VPLEX Metro分散ボリュームへの代替パスをリモート VPLEXクラスタ経由で提供します。

◆ VPLEX Metro HA：キャンパス間よりは遠いが同期距離内と定義され（通常は RTTが 1 msより長くて 5 ms以下）、VPLEX Metro分散ボリュームが VPLEX Witnessを使用して 2台のVPLEXクラスタにわたって展開されますが、クロス接続のホストパス構成は使用しません。

このセクションでは、これらのソリューションをそれぞれ見ていき、システムのアップタイムが最大化される仕組みを説明します。その中で、さまざまな障害シナリオを細かく追って、VPLEXとホストHAクラスタの両方の視点から、テクノロジーがそれぞれの障害にどう対処しているかを示します。示されるどのシナリオでも、VPLEXによって少なくとも 1台の VPLEXクラスタでデータ消失なく IO処理を自動継続できるようになり、その結果、ホスト HAクラスタ内のアプリケーションまたはサービスは、まったく中断なくオンライン状態を継続するか、別のホストクラスタで自動的に再開されます。


VPLEX Metro HA

VPLEX Metro HAキャンパス（クロス接続あり）VPLEX Metro HAキャンパス接続は、2か所のサイトが互いにキャンパス距離（往復レーテンシー 1 msまで）内にある場合に導入できます。この場合、クロス接続フロントエンド構成と、別のフォルトドメイン内にインストールされた VPLEX Witnessサーバとを使用することで、VPLEX Metro分散ボリュームを 2か所のサイトにわたって導入できます。

図 47に、VMware向けMetro HAキャンパスソリューションの高レベル図を示します。

図 47 VMware向けMetro HAキャンパスソリューションの高レベル図

図からわかるように、各サイトに単一の VPLEXクラスタが導入され、クラスタ間リンクで接続されています。

VPLEX Metro HAキャンパス（クロス接続あり） 105

106

VPLEX Metro HA

VPLEX分散ボリュームが両方の場所にわたって作成されており、vSphere HAクラスタインスタンスも、基盤となる VPLEX分散ボリュームを使用して両方の場所にわたって拡張されています。

これも 105ページの図 47 に示されていますが、物理 ESXホストは、それらが物理的に存在しているローカル VPLEXクラスタに接続されているだけでなく、リモート VPLEXクラスタへの代替パスも持っています。代替パスは、両 VPLEXクラスタを結ぶ VPLEXクラスタ間リンク接続とは物理的に別の、追加のクロス接続ネットワーク経由になっています。

このソリューションの主な利点は、コンポーネントで障害が発生した場合（VPLEXクラスタ全体の障害も含みますが、VPLEXエンジン内の単一点障害はないので考えにくい状況です）の復旧時間を最小限に抑えられる、または排除できることです。というのも、物理ホストにはリモート VPLEXクラスタによってアクティブに処理されている同じストレージへの代替パスがあり、そのリモート VPLEXクラスタのオンライン状態がルールセットに関係なく VPLEX Witnessの指示で自動的に保たれるからです。

クロス接続構成に関する高レベルの導入のベストプラクティスは次のとおりです。

◆ クラスタ間ネットワークレーテンシーが VPLEXクラスタ間で 1 ms RTT（本書の執筆時点）を超えないようにしてください。

◆ クロス接続キャンパス構成を使用する場合は、VPLEX Witnessを（第 3の障害ドメインに）導入する必要があります。

◆ EMCベストプラクティスに従ってすべてのリモートVPLEX接続をローカルホストにゾーニングし、ローカルホストイニシエータをリモート VPLEXに登録する必要があります。そうすることで、分散ボリュームは両方の VPLEXクラスタから同じホストに公開されます。ホストパス選択にローカルパス選択を設定し、リモートパスが使用されるのをプライマリパスで障害が発生した場合に限定し、レーテンシーが増えないようにします。

注：本書の執筆時点で、（クラスタ間接続なしの標準 VPLEX Metro HAをではなく）追加の VPLEX Metro HAキャンパスを使用して構成可能な認定ホストクラスタソリューションは、vSphereバージョン 4.1または 5.0とWindows 2008と IBM Power HA 5.4の 2つだけです。https://elabnavigator.emc.com の［Simple Support Matrix］タブでVPLEX Simple Support Matrixを見て最新のサポート情報を確認するか、RPQをご提出ください。


VPLEX Metro HA

障害のシナリオ以下の障害シナリオでは、DRSを使用する拡張された HAトポロジーに vSphere 5.0アップデート 1以上が構成されており、すべての物理ホスト（ESXサーバ）が同じ HAクラスタ内にあることを前提としています。前述のとおり、このタイプの構成により仮想マシンを遠い距離間でテレポートできるようになり、災害回避、ロードバランシング、クラウドインフラストラクチャといった使用例でたいへん有効です。こうした使用例はどれも標準装備の機能を使用して実現できますが、VPLEX Metro HAキャンパスソリューションの導入には付加価値があり、計画されたイベントと予想外のイベントのどちらにも対処する可用性がもたらされます。

VPLEX Metroと連携して使用する場合に vSphere HAを拡張するための高レベルの推奨事項と前提条件は次のとおりです。

◆ 単一のvCenterインスタンスがVPLEX Metroクラスタペアを含む両方の場所に展開されていることが必要です（注：これを仮想化して vSphereハートビートで保護することで、障害発生時に再開できるようにすることをお勧めします）。

◆ 拡張されたレイヤー 2ネットワークと連携させて使用して、VMの移動先が引き続き同じ論理ネットワーク上になるようにする必要があります。

◆ vSphere HAは vSphereクラスタ内で実現できますが、vSphereフォルトトレランスはサポートされていません（本書の執筆時点において。ただし、2012年末にサポート予定）。

◆ vSphere DRSと組み合わせて使用できます。ただし、5.0アップデート 1より前の vSphereバージョンでは、この機能に関して慎重な検討が必要です。というのも、VMが「非優先サイト」で実行されている障害状況では、ESXサーバがストレージの「PDL（Persistent Device Loss）」状態を検出しないという問題があり、障害後に VMフェイルオーバーが実行されない可能性があるからです。そうなっても VMはオンライン状態を維持しますが、応答が断続的に途絶えます（別名「ゾンビ VM」）。このシナリオでは手動介入が必要です。

注：これを回避するには、別個の物理ネットワーク上に VPLEXクラスタ間リンクへのクラスタ間接続を持つ VPLEX HAキャンパスソリューションを使用します。そうすることで、VMがどこで実行されていようとも、ストレージへのアクティブなパスが常に存在します。回避する方法としては他にも、ホスト親和性グループの使用も考えられます（サポートされている場合）。前述の状況を回避するには、最新の ESXおよび vSphereバージョン（5.0アップデート 1以上）にアップグレードすることをお勧めします。


108

VPLEX Metro HA

拡張された HA vSphere環境の設定手順やベストプラクティスプランニングについては、ホワイトペーパー「 Using VMware vSphere with EMC VPLEX — Best Practices Planning」を参照してください。http://powerlink.emc.comの［サポート］＞［テクニカルドキュメントおよびアドバイザリ］＞［ハードウェア /プラットフォーム］＞［VPLEXファミリ］＞［ホワイトペーパー］からアクセスできます。図 48に、論理フォルトドメインに分割されたMetro HAキャンパス環境のトポロジーを示します。

図 48 障害ドメインに分割されたMetro HAキャンパスの図

以降のセクションでは、いずれかのドメイン内で起こった単一の障害に対する復旧の自動化についてと、どのドメインで単一の障害が発生してもシステム全体がダウンするには至らず、ほとんどの場合にサービスが中断されない仕組みについて説明します。

物理ホスト障害がドメイン A1または B1で起こると、VMware HAクラスタは影響を受けた仮想マシンを正常な ESXサーバ上で再開します。


VPLEX Metro HA

例 1 図 49に、ドメイン A1のすべての物理 ESXホストで障害が発生した場合を示します。

図 49 ゾーン A1で障害が発生したMetro HAキャンパスの図

ドメイン B1にあるすべての物理ホストが VPLEX Metro分散デバイス経由で同じデータストアに接続されているので、VMware HAはドメイン B1の物理 ESXホストをどれでも使って仮想マシンを再開できます。

例 2 次の例では、ドメイン A2または B2のいずれかで VPLEXクラスタに障害が発生するという可能性の低いイベントが起こった場合について説明します。

注：この障害が起こる可能性が低いと見なされるのは、VPLEXクラスタに単一障害点のない二重障害だからです。

このケースでは、どの仮想マシンに対するサービスも中断されません。


110

VPLEX Metro HA

図 50では、ドメイン A2で VPLEXクラスタが全面的に停止しています。

図 50 ゾーン A2で障害が発生したMetro HAキャンパスの図

ESXサーバはどちらのサイトにある VPLEXクラスタともクロス接続されているので、ESXは単純に I/Oの経路指定を代替パスに変更します。代替パスが引き続き使用可能なのは、VPLEX Witnessで保護された分散ボリュームにより VPLEXが構成されているからです。分散ボリュームはドメイン B2でオンライン状態を維持します。VPLEX Witnessサーバは、A2にある VPLEXクラスタと通信できないことを検出し、B2にある VPLEXクラスタも A2と通信できないことと合わせて、A2が分離されたか A2で障害が発生したかのどちらかであると判断し、B2にある VPLEXクラスタに対してオンライン状態を維持するよう指示します。

注：同じように、A2が完全に分離された場合、A2は VPLEX Witnessサーバとも B2にある VPLEXクラスタとも通信不能になるため、分散ボリュームは単純に A2を中断します。その場合の結果は vSphereの観点で見ると同じになり、中断は起こりません。I/Oはドメイン B2へのクロス接続経由で経路変更され、ドメイン B2で分散ボリュームはオンライン状態を維持してI/Oサービスを継続できるからです。


VPLEX Metro HA

例 3 次の例では、ドメイン A3と B3のどちらかにあるバックエンドストレージアレイのどれか（またはすべて）で障害が発生した場合について説明します。やはり、どの仮想マシンにも中断は起こりません。

図 51では、ドメイン A3に存在するすべてのストレージアレイで障害が発生しています。キャッシュ一貫性のある VPLEX Metro分散ボリュームがドメイン A2と B2にわたって構成されているため、ローカルバックエンドストレージで障害が発生しているにもかかわらず、IOの処理は A2の VPLEXでアクティブに継続されます。その原動力は VPLEXに組み込まれているキャッシュ一貫性で、それにより効率的に、A2ドメインへのあらゆる読み取りはキャッシュされ、書き込みはドメイン B3のバックエンドストレージにサイト B2のリモート VPLEXクラスタ経由で伝達されます。

図 51 ゾーン A3または B3で障害が発生したMetro HAキャンパスの図


112

VPLEX Metro HA

例 4 次の例では、ドメイン C1で VPLEX Witnessサーバに障害が発生した場合について説明します。

やはり、どの仮想マシンまたは VPLEXクラスタも中断されません。図 52では、VPLEX Witnessサーバのあるドメイン C1で全面的な障害が発生しています。VPLEX Witnessは I/Oパス内になく、クラスタ間リンクは引き続き使用可能なので、オプションのコンポーネント I/Oだけがドメイン A2と B2にあるすべての分散ボリュームに対して引き続きアクティブで、キャッシュ一貫性が VPLEXクラスタドメイン間で維持されます。

サービスは中断されませんが、どちらの VPLEXクラスタもオートコールを実行して、VPLEX Witnessサーバとの通信が失われたことを通知します。現状に加えて、ドメイン A2または B2にあるVPLEXクラスタのどちらか、またはクラスタ間リンクに障害が発生すると、データが使用不可能になるからです。そうなるリスクは、VPLEX Witnessサーバのオフライン時間が長引くほど高まります。このリスクを排除するには、Witnessの機能を手動で無効にして、VPLEXクラスタが静的な選択のルールに従うようにします。

図 52 ゾーン C1で障害が発生したMetro HAキャンパスの図


VPLEX Metro HA

例 5 次の例では、ドメイン A2と B2間のクラスタ間リンクで障害が発生した場合について説明します。

やはり、どの仮想マシンまたは VPLEXクラスタも中断しません。

図 53では、ドメイン A2と B2間のクラスタ間リンクに障害が発生しています。この場合、事前に定義しておいた静的な選択のルールセットが呼び出されます。これは、どちらの VPLEXクラスタも相手の VPLEXクラスタと通信できないからです（一方、VPLEX Witnessサーバはどちらの VPLEXクラスタとも通信できます）。したがって、ドメイン A2または B2のどちらかにある所定の分散ボリュームへのアクセスが中断されます。この例ではクロス接続ネットワークがクラスタ間リンクとは物理的に別個であるため、ボリュームのオンライン状態が維持されているリモート VPLEXクラスタへの代替パスは引き続き使用可能です。そのため、ESXは単純に代替 VPLEXクラスタへのトラフィックの経路指定を変更します。つまり、仮想マシンはどのサイトで実行されていてもオンライン状態を維持し、影響を受けません。

図 53 サイト間リンク障害が発生したMetro HAキャンパスの図


114

VPLEX Metro HA

注：この例の場合、代替パスは障害が発生したのと同じ ISLを物理的に通っていると見なされます。このケースでは、仮想マシンが A1で実行されていた場合に短時間の中断が起こりえます。なぜなら、代替パスもダウンしているため、B1で（ホストクラスタによって）再開されることになるからです。一方、5.0アップデート 1より前のバージョンの vSphereでは、ゲストOSが単純に異常停止し、vSphere HAが再開を要求しない可能性もあります。この TechBookではそのような状況を扱いませんが、どのホストクラスタ環境におけるわずかな中断も防ぐために、クラスタ間接続に使用するネットワークを VPLEXクラスタ間リンクと物理的に別個のネットワークにして、この問題が起こる可能性を回避することをお勧めします。全面的なクラスタパーティションの詳細については次のセクションの VPLEX Metro HA（非キャンパス、すなわちクロス接続なし）シナリオを、この問題を回避するためにバージョン 5.0アップデート 1より前の ESX実装に適用できる適切な vSphere HA構成設定については付録 A「vSphere 5.0アップデート 1の追加設定」、を、それぞれ参照してください。


VPLEX Metro HA

VPLEX Metro HA（クラスタ間接続なし）VPLEX Metro HA（クラスタ間接続なし）の導入は、前のセクションで説明したように、Metro HAキャンパスの導入と似ています。しかし、このソリューションは、キャンパス間の距離より遠い、都市間の距離に対応するため設計されており、往復レーテンシーは 1 msより長く 5 msまでを想定しています。このソリューションにより、2か所のサイトにわたる VPLEX Metro分散ボリュームを導入できるほか、VPLEX Witnessサーバを別個の第 3の障害 /フォルトドメイン内に導入することができます。

図 54は、クラスタ間導入のない vSphere用Metro HAソリューションの高レベル図です。

図 54 標準的なMetro HAの高レベル図

図からわかるように、各サイトに単一の VPLEXクラスタが導入され、クラスタ間リンクで接続されています。

VPLEX Metro HA（クラスタ間接続なし） 115

116

VPLEX Metro HA

VPLEX分散ボリュームが両方の場所にわたって作成されており、vSphere HAクラスタインスタンスも、基盤となる VPLEX分散ボリュームを使用して両方の場所にわたって拡張されています。

また、115ページの図 54 からわかるようにクロス接続がないので、物理 ESXホストの接続先はそれらが存在しているローカル VPLEXクラスタだけになっています。

このソリューションの主な利点は、コンポーネントに障害が発生した場合の復旧時間を最小限に抑えられる、または排除できることです。なぜなら、ホストクラスタは VPLEX分散ボリュームに接続されており、それが同じブロックデータを両方の VPLEXクラスタ経由でアクティブに処理しており、採用されているルールセットにかかわらず、VPLEX Witnessの指示のもと、どのような単一障害イベント下で少なくとも 1台の VPLEXクラスタがオンライン状態を維持するからです。

注：本書の執筆時点で、ホストベースのクラスタソリューションの多くが、VPLEX Metro HAキャンパス（クロス接続あり）ではなく VPLEX Metro HAでサポートされています。次のセクションでは vSphereと VPLEX Metro HAの組み合わせだけを取り上げますが、サポートされているホストクラスタには他にもMicrosoft HyperV、Oracle RAC、Power HA、Serviceguardなどがあります。最新のサポート情報については、https://elabnavigator.emc.com の［Simple Support Matrix］タブでVPLEXのシンプルサポートマトリックスを確認してください。

障害のシナリオ前のセクションと同様、拡張された vSphere構成を VPLEX Metro HAと組み合わせて導入する場合は、長距離の vMotion（仮想マシンのテレポーテーション）も実現できます。ESXデータストアがVPLEX Metro分散ボリューム上にあり、したがって前のセクションで説明したように同時に 2か所に存在しているからです。

以降の障害シナリオでもやはり、拡張された HAトポロジーにvSphere 5.0アップデート 1以上が構成されており、どちらのサイトでもすべての物理ホスト（ESXサーバ）が同じ HAクラスタ内にあることを前提としています。

障害シナリオの大半がクロス接続構成ではまったく同じように振る舞うので、このセクションでは前のセクションでの説明と結果が少しだけ違ってくる 2つの障害シナリオだけを取り上げます。


VPLEX Metro HA

注：拡張されたHA vSphere環境の設定手順やベストプラクティスプランニングについては、ホワイトペーパー「 Using VMware vSphere with EMC VPLEX — Best Practices Planning」を参照してください。PowerLink（http://powerlink.emc.com）の［ホーム］＞［サポート］＞［テクニカルドキュメントおよびアドバイザリ］＞［ハードウェア /プラットフォームに関するドキュメンテーション］＞［VPLEXファミリ］＞［ホワイトペーパー］からアクセスできます。

図 55に、論理フォルトドメインに分割されたMetro HA環境のトポロジーを示します。以降のセクションでは、どれかのドメイン内で発生した単一障害での復旧の自動化について説明します。

図 55 障害ドメインのあるMetro HAの高レベル図

例 1 次の例では、ドメイン A2で VPLEXクラスタに障害が発生するという可能性の低いイベントが起こった場合について説明します。このケースでは、ドメイン B1で実行されているどの仮想マシンに対するサービスも中断されません。一方、仮想マシンが B1で再開されるので、ドメイン A1で実行されていたどの仮想マシンも短い中断を経ます。


118

VPLEX Metro HA

図 56では、ドメイン A2で VPLEXクラスタが全面的に停止しています。

図 56 ドメイン A2に障害のあるMetro HAの高レベル図

注：この障害が起こる可能性が低いと見なされるのは、VPLEXクラスタに単一障害点のない二重障害だからです。

図からわかるように、ESXサーバがリモート VPLEXクラスタにクロス接続されていないため、ESXサーバはストレージへのアクセスを失い、HAホストクラスタ（この例では vSphere）がドメイン A2内の仮想マシンの HA再開を実行します。これを実行できるのは分散ボリュームが B2で引き続きアクティブだからなのですが、それは VPLEXの構成に VPLEX Witnessで保護された分散ボリュームが使用されており、この分散ボリュームがドメイン A2にある VPLEXを使用不可と判断するからです（VPLEX Witnessサーバも B2にある VPLEXクラスタも、A2にある VPLEXクラスタと通信できず、それをふまえて VPLEX Witnessが B2の VPLEXクラスタに対してオンライン状態を維持するよう指示します）。


VPLEX Metro HA

注： * 理解しておいていただきたい重要なことがあります。この障害は二重障害と見なされます。なぜなら、本書の執筆時点では、vSphere（5.0アップデート 1を含むすべてのバージョン）を使用する場合、サイト Aにあるゲスト VMが単純にハングし（「ゾンビ」と呼ばれます）、VMware HAが再開を要求しないからです（サポートされているそれ以外の HAクラスタは同じ状況下でこの障害を検出して再開を実行します）。この状況についてはこの TechBookでは扱いませんが、ルールセットに関係なく VPLEX Witnessの指示で自動的にオンライン状態を維持するリモート VPLEXクラスタの VMにおいて、手動介入が必要になることがあります。その理由は、VPLEXクラスタがホストから完全に切断されると、ホストは VPLEX経由で発行される PDL（Persistent Device Loss）ステータスを受け取れなくなるため、vSphereにこの状況が APD（All Paths Down）状態としか見えなくなり、ほとんどの場合、VMの障害なしにデバイスがオンラインに戻るのを待機するからです。

例 2 次の例では、ドメイン A2と B2間のクラスタ間リンクで障害が発生した場合について説明します。

このシナリオでは次のどちらかの結果になります。

◆ VMが優先サイトで実行されている場合 - 分散ボリュームの静的な選択がクラスタ 1デタッチに設定されており（クラスタ 1がドメイン A2にあると想定）、ボリュームがオンライン状態を維持しているのと同じサイト（いわゆる「優先サイト」）で仮想マシンが実行されている場合、サービスは中断されません。

◆ VMが非優先サイトで実行されている場合 - 分散ボリュームの静的な選択がクラスタ 1デタッチに設定されており（クラスタ 1がドメイン A2にあると想定）、リモートサイト（ドメイン B1）で仮想マシンが実行されている場合、VMのストレージは中断状態（PDL）になります。その場合、ゲストオペレーティングシステムで障害が発生し、仮想マシンが自動的にドメイン A1で再開されます。


120

VPLEX Metro HA

図 57では、ドメイン A2と B2間のリンクに障害が発生しています。

図 57 サイト間リンク障害が発生したMetro HAの高レベル図

この場合、事前にクラスタ 1デタッチと定義されている静的な選択のルールセットが呼び出されます。なぜなら、どちらの VPLEXクラスタも相手の VPLEXクラスタと通信できず（ただし、VPLEX Witnessサーバは両方の VPLEXクラスタと通信できます）、したがって分散ボリュームへのアクセスはドメイン B2にある分については中断される一方、A2にある分はアクティブなままになります。

A1で実行されていた仮想マシンは中断されず、B1で実行されていた仮想マシンが A1で再開されます。


VPLEX Metro HA

注：前述の注や議論と同様、この状況についてこの TechBookでは扱いませんが、5.0アップデート 1より前のバージョンの vSphere HAはこの状況を検出できず、非優先サイトで実行されていた VMを再開しません。したがって、このタイプの構成（5.0アップデート 1より前のバージョン）でvSphereを使用しつつあらゆるシステム停止を防ぐためには、VMware DRSホスト親和性ルールを使用して（サポートされている場合）、仮想マシンが常に優先場所（依存しているストレージにとっての優先場所）で実行されるようにします。このシナリオを避ける別の方法は、DRSを全面的に無効にして vSphere HAだけを使用するか、前のセクションで説明したように別個の物理ネットワークにわたるクロス接続構成を導入することです。この問題を避けるためにバージョン 5.0アップデート 1より前の ESX実装に適用できる適切な vSphere HA構成設定の詳細については、「付録 A」を参照してください。

このソリューションの対象となる他の障害シナリオは、前に説明した VPLEX Metro HAキャンパスソリューションの場合と同じです。ドメイン A1、B1、A3、B3、または Cでの障害の処理については、105ページの「VPLEX Metro HAキャンパス（クロス接続あり）」を参照してください。


122

VPLEX Metro HA


7

この章では、この TechBookで概要を説明した VPLEXソリューションに関する結論を述べます。

◆ 結論........................................................................................................................................ 124

結論

結論 123

124

結論

結論本書で説明してきたように、VPLEX AccessAnywhereTMテクノロジーを HAや VPLEX Witnessと組み合わせることで、ストレージ管理者やデータセンター管理者は、組織のミッションクリティカルなアプリケーションのために正真正銘の物理 /論理高可用性を実現しつつ、リソースオーバーヘッドや手動介入の必要性を減らすことができます。ミッションクリティカルなアプリケーションでは仮想化が進んでおり、たいていは VMware vSphereかMicrosoft Hyper-Vの「仮想マシン」テクノロジーが使用されています。VPLEXのお客様は、HA/VPLEX Witnessソリューションを使用してアプリケーション固有のクラスタリングや仮想化のテクノロジーをいくつか統合することで、ミッションクリティカルなターゲットアプリケーションで HAの利点を活かしていくことでしょう。

これまで説明してきたように、ストレージ管理者には高可用性を軸とする 2種類の具体的な VPLEX Metroベースソリューションが用意されており、本書では VMware ESX 4.1以上が VPLEX Metro HAキャンパス（クラスタ間接続あり）環境や標準の（非キャンパスの）Metro環境と統合されているケースを取り上げました。VPLEX Metro HAキャンパスは、クラスタ間接続のない VPLEX Metro HA導入より HAのレベルが高くなります。ただし、データセンター内での使用や、データセンター間でのネットワークレーテンシーが無視できる場合に限られます。

どちらのソリューションも、仮想化の度合いを現在高めているかこれから高める予定があるだけでなく、次のようなニーズのあるお客様に理想的です。

◆ 「夜勤」ストレージおよびサーバ管理者という職の廃止。この実現のためには、アプリケーションが夜間に起こるどのような障害にも対処できるという自信が管理担当者にないといけません。

◆ アクティブ /パッシブデータセンターレプリケーションモデルから全面的にアクティブで可用性の高いデータセンターモデルへの移行による、設備投資の削減。

◆ データセンター全体に影響しうる洪水や火事などの災害から保護することによる、アプリケーションの可用性の向上。


結論

両タイプのソリューションをふまえた総合的な観点と、ストレージ管理者に提供される機能を考えると、少々の差はあれ、共通して以下の利点がもたらされます。EMC VPLEXテクノロジーをWitnessと組み合わせることでお客様にもたらされる以下の利点について、それぞれ簡単に説明します。

◆ 125ページの「ストレージ関連の障害に対するより優れた保護」◆ 125ページの「起こりうる障害の連鎖に対する保護」◆ 126ページの「全体的なリソース使用率の向上」

ストレージ関連の障害に対するより優れた保護データセンター内では、アプリケーションをストレージ関連の障害から保護するのに、通常、EMC PowerPath™などのマルチパスソフトウェアが使用されています。この場合、アプリケーションは HBA障害、スイッチの故障、ケーブルの破損、ストレージアレイコントローラの故障などに対処するため、障害の発生場所を回避するようI/Oをルーティングします。VPLEX Metro HAクラスタ間接続ソリューションは、独立している障害ドメイン内の VPLEXクラスタ間をマルチパスにすることで、この保護をラックやデータセンターのレベルに拡張します。さらに、VPLEX Metro HAソリューションにより、I/Oへの代替ルートが現在のデータセンターにない場合にアプリケーションを他のデータセンターで再開する機能が加わります。一例を挙げると、VPLEXラック全体に影響を与える火事が発生した場合は、アプリケーションを自動的にバックアップのデータセンターで再開できます。これにより、可用性が大幅に高まり、リスクレベルが下がります。

起こりうる障害の連鎖に対する保護VPLEX Witness機能の利点を確かめるため、VMware HAの動作をおさらいしましょう。

VMware HAなどの製品では、仮想マシンに何らかの理由（サーバの障害、ストレージ接続の障害など）で障害が発生したときに、仮想マシン（アプリケーション）を自動的に再開できます。この再開には、仮想マシンのゲストオペレーティングシステムやアプリケーションの完全なブートが伴います。VMの障害でシステムは停止に至りますが、この障害からの復旧はたいてい自動的です。

これをMetro HA構成において VPLEXと組み合わせることで、同じレベルの保護をデータセンタースケールの災害シナリオに提供できます。

結論 125

126

結論

全体的なリソース使用率の向上サーバ仮想化ベースの製品とその復旧機能という同じ観点で、目を使用率に転じると、VMware DRS（Distributed Resource Scheduler）は、使用できる全サーバにわたって計算やメモリの負荷のバランスを取ることを目的として、自動的にサーバ間でアプリケーションを移動させることができます。データセンター内ではこれによりサーバ使用率が向上します。というのも、実行するアプリケーションに合わせて管理者が個々のサーバの規模を変更する必要がなくなるからです。その代わりに、データセンター内で実行するアプリケーションの組み合わせに合わせてデータセンター全体の規模を調整すればよくなります。

HA構成（Metroおよびキャンパス）を追加すると、サーバリソースの使用可能なプールをプライマリとバックアップのどちらのデータセンターでも使用できるようになります。どちらもアクティブに使用され、片方のデータセンターの余剰計算能力をもう片方の新しい需要を満たすために使用できます。

代替ベンダーソリューション：

◆ Microsoft Hyper-V Server 2008 R2と PRO（Performance and Resource Optimization）

概して、データセンターが予想どおりの成長を続ける中で容量と統合の両立に苦労するストレージ管理者は、EMC VPLEXを導入することで懸念をいくつか解消できます。向上が見込まれる領域は次のとおりです。

◆ ハードウェアやコンポーネントの障害によるデータの整合性への影響

◆ システムの整合性

◆ 手動介入なしの高可用性

◆ 高可用性システム全体を保護するWitness

具体的には、災害復旧におけるサイト間のオーバーヘッドや依存関係を減らすことで、VPLEXを活かしてデータの可用性を確保でき、ポケットベルや携帯電話が鳴らなくなります。


A

この付録では、vSphere 5.0アップデート 1に必要な追加設定について説明します。

◆ vSphere 5.0アップデート 1 ............................................................ 128

vSphere 5.0アップデート 1の追加設定

vSphere 5.0アップデート 1の追加設定 127

128

vSphere 5.0アップデート 1の追加設定

vSphere 5.0アップデート 1前のセクションで説明したとおり、vSphere HAは、SCSI PDL（Persistent Device Loss）状態が VMに HAフェイルオーバーを開始させるべき状態であることを自動認識できません。

拡張されたクラスタ構成で vSphere HAを VPLEXと組み合わせて使用している場合、これは明らかに望ましくありません。そのため、VMがたまたま非優先サイトで実行されていた（つまり、ストレージデバイスが PDL状態にされていた）ときに VPLEX WANがパーティションされた場合に、VMがこの状態を認識し、HAフェイルオーバーを実行するのに必要な手順を呼び出すよう、vSphereを構成することが重要です。

ESXと vSphereの 5.0アップデート 1より前のバージョンには SCSI PDLステータスに対応する機能がなく、したがって普通は異常停止します（つまり、電源はオンだが応答しない状態）。

一方、vSphere 5.0アップデート 1以降には SCSI PDL状態に対処する機能が備わっており、VMがオフになるので、それにより HAフェイルオーバーが開始されます。

VMをこのように動作させるためには、vSphereクラスタに追加設定が必要です。本書の執筆時点で該当する設定は次のとおりです。

1. vSphere Clientで目的のクラスタを選択して右クリックし、［設定の編集］を選択します。ポップアップメニューで［vSphere HA］をクリックして選択し、［詳細オプション］をクリックします。次のオプションを定義して保存します。das.maskCleanShutdownEnabled=true

2. すべての ESXiサーバで、viを使用して /etc/vmware/settingsを編集して次の内容を指定し、ESXiサーバを再起動します。

次の出力は、正しい設定がファイルに適用された状態を示しています。

~ # cat /etc/vmware/settingsdisk.terminateVMOnPDLDefault=TRUE

詳細については、ESXのマニュアルを参照してください。


用語集

この用語集では、VPLEX統合ストレージシステム関連の用語について説明します。これらの用語の多くは、このマニュアルで使用されています。

AAccessAnywhere VPLEXクラスタによる遠く離れたクラスタ間での情報アクセス提供

を実現している画期的なテクノロジー。

Array ユーザーデータやパリティデータを格納できるディスクドライブの集合。デバイスは、アレイに含まれる一部またはすべてのドライブからなっています。

CCOM クラスタ内通信（ファイバチャネル）。キャッシュ一貫性やレプリ

ケーショントラフィックで使用される通信です。

controller（コントローラ）

コンピュータと周辺機器とのデータ転送を制御するデバイス。

COOP（業務の継続性）障害の前後でデータを処理、格納、転送する機能など、緊急時に使用するポリシーや手順を確立するのは、これを目指してのことです。


130

用語集

Ddevice 特定の RAIDプロパティに追加する単一または複数のエクステント

の組み合わせ。デバイスはどちらかのクラスタのストレージしか使用しません。分散デバイスはマルチクラスタプレックス内の両方のクラスタのストレージを使用します。「分散デバイス」も参照。

DFS（分散ファイルシステム）

ファイルやリソースの共有をネットワーク経由で永続ストレージという形でサポートします。

director（ダイレクタ） VPLEXのコアソフトウェアである GeoSynchronyを実行する CPUモジュール。ダイレクタは各エンジンに 2個あり、それぞれが専用リソースを持ち、独立して機能できます。

DR（災害復旧）エラー後にシステム動作を再開してデータ消失を防ぐ機能。

DR1（分散 RAID1デバイス）

2台の VPLEXクラスタに分散している、キャッシュ一貫性のあるVPLEX Metroまたは Geoボリューム。

EEthernet LAN（ローカルエリアネットワーク）プロトコル。Ethernetでは

バストポロジーを使用します。具体的には、すべてのデバイスが 1本のケーブルに接続され、10 Mbps～ 10 Gbpsのデータ転送速度をサポートします。たとえば、100 Base-Tは 100 Mbpsのデータ転送速度をサポートします。

FFC（ファイバチャ

ネル）コンピュータデバイス間のデータ転送プロトコル。距離が長くなるほど光ファイバの使用が求められますが、FCは同軸ケーブルや通常の電話線に使用されているツイストペアメディアでも機能します。ファイバチャネルには、ポイントツーポイント、スイッチ、ループの各インタフェースがあります。SAN内で SCSIトラフィックを送るために使用されます。

firmware VPLEXダイレクタ上のフラッシュ ROMから読み込まれて実行されるソフトウェア。

FRU（フィールド交換可能装置）

システムをメーカーに返却して修理するのではなくサイトで交換できるような、システムのユニットまたはコンポーネント。


用語集

GGbまたは Gbit（ギガ

ビット）1,073,741,824（2の 30乗）ビット。一般に 10の 9乗に丸められます。

Geoplex VPLEX Geo向けに構成された DR1デバイス。

GFS（グローバルファイルシステム）

共有ストレージクラスタまたは分散ファイルシステム。

gigabyte (GB)（ギガバイト）

1,073,741,824（2の 30乗）バイト。一般に 10の 9乗に丸められます。

HHBA（ホストバスアダ

プタ）ホストコンピュータバスとメモリシステムの間の情報転送を管理する I/Oアダプタ。数多くの下位レベルインタフェース機能を自動的に実行するか、またはプロセッサの使用を最小限に抑えて実行することで、ホストプロセッサのパフォーマンスへの影響を最小限に抑えます。

II/O（入出力）コンピュータからまたはコンピュータへのデータ転送。

iFCP（インターネットファイバチャネルプロ

トコル）

地理的に分散しているシステム内でファイバチャネルストレージデバイスを SANまたはインターネットに TCPを使用して接続します。

iSCSI（Internet SmallComputer System

Interface）

コマンドを IPネットワーク経由で送れるプロトコル。ストレージユニットからコンピュータネットワーク内の任意の場所にあるサーバへデータを転送します。

KKBまたは K（キロバ

イト）1,024（2の 10乗）バイト。一般に 10の 3乗に丸められます。


132

用語集

MMb（メガビット） 1,048,576（2の 20乗）ビット。一般に 10の 6乗に丸められます。

megabyte (MB)（メガバイト）

1,048,576（2の 20乗）バイト。一般に 10の 6乗に丸められます。

Metro-Plex 約 100 kmという都市間（同期）距離内で接続された 2台の VPLEX Metroクラスタ。

miss キャッシュを検索したがデータが見つからなかった処理。代わりにデータをディスクからアクセスする必要があります。

RRAID パフォーマンス、エラーリカバリ、フォルトトレランスの向上を目

指した、2つ以上のストレージボリュームの使用。

RAID 0 パフォーマンス指向の、ストライピングまたは分散によるデータマッピング技術。同じ大きさのストレージブロックが、決まったシーケンスですべてのアレイディスクに割り当てられます。低い固有費用で高い I/Oパフォーマンスが得られます。追加ディスクは必要ありません。RAID 0の利点は、設計がきわめてシンプルで、実装が簡単なことです。

RAID 1 ミラーリングとも呼ばれ、他のどの RAID形態より長きにわたって使用されています。依然として人気がある理由は、シンプルさとデータ可用性の高さです。ミラーされるアレイは複数のディスクで構成されます。ミラーされるアレイに含まれる各ディスクはユーザーデータのまったく同じイメージを保持します。RAID 1にストライピングはありません。読み取りパフォーマンスが向上しているのは、両方のディスクの同時読み取りが可能だからです。ライトパフォーマンスは単体のディスクストレージの場合より低下します。書き込みは、RAID 1に含まれるすべてのディスク、すなわちミラーに対して実行する必要があります。RAID 1は、読み取りの多いアプリケーションで優れたデータ信頼性を発揮します。

RAIDレッグユーザーの現在の場所にあるデータコピー、すなわちミラー。

RDMA（Remote DirectMemory Access）

ネットワーク内のコンピュータが、それぞれのメインメモリを使用し、どのコンピュータのプロセッサ、キャッシュ、オペレーティングシステムも使用しないで、データをやりとりする機能。


用語集

RPO（目標復旧時点）障害イベントからさかのぼって消失する可能性があるデータ量。

RTO（目標復旧時間）障害発生後の完全復旧までにかかるサービス時間。

SSCSI（Small

Computer SystemInterface）

パーソナルコンピュータがディスクドライブ、テープドライブ、CD-ROMドライブ、プリンタ、スキャナーなどの周辺機器と、それまでのインタフェースより高速かつ柔軟に通信できるようにした、いまだ進化を続ける ANSI規格の電子インタフェースセット。

SNMP（SimpleNetwork

ManagementProtocol）

ネットワーク内のシステムやデバイスを監視します。

storage area network(SAN)（ストレージエリアネットワーク）

大規模なユーザーネットワークのために各種データストレージデバイスを関連データサーバに相互接続する、高速の専用ネットワークまたはサブネットワーク。

TTCL（Tool Command

Language）迅速なプロトタイプやスクリプトアプリケーションでよく使用されるスクリプト言語。

TCP/IP（TransmissionControl

Protocol/InternetProtocol）

プライベートネットワークやインターネット上のトラフィックで使用される基本通信言語またはプロトコル。

UUPS（無停電電源装置）電源障害時に電源を維持するための、バッテリを備えた電源。

UUID（UniversalUnique IDentifier）

各 VPLEXダイレクタをユニークに識別するために使用される 64ビットの数。各ダイレクタに割り当てられているハードウェアシリアル番号をもとに生成されます。

Vvirtual volume（仮想ボ

リューム）仮想ボリュームは一続きのボリュームに見えますが、複数のストレージボリュームに分散しています。仮想ボリュームはホストに提示されます。


134

用語集

VPLEX Cluster Witness 静的な選択による障害処理セマンティクスを強化および向上させることのできる、VPLEX V5.xの新機能。

WWWN（World Wide

Name）世界中においてユニークで、64ビットの符号なしバイナリ値で表される、具体的なファイバチャネルネーム識別子。

あアクティブ /アクティブ

すべてのサーバでアプリケーションを実行でき、相互にバックアップの役割を果たせることから、プライマリまたはスタンバイサーバというものがないクラスタ。

アクティブ /パッシブプライマリコンポーネントで障害が発生したときに稼動する用意のできている、給電されているコンポーネント。

いイベントユーザーまたはシステムによって開始された重要なアクションがも

とで生成されるログメッセージ。

イントラネット World Wide Webのように動作するが、許可されたユーザーからなる限られたグループにアクセスが制限されているネットワーク。

えエクステントストレージボリュームのスライス（ブロックの範囲）。

エンジンダイレクタ 2個と管理モジュールと冗長電源を備えたエンクロージャ。

か拡張性システムの規模または構成を変えることで状況の変化に対応し、

ニーズの発展に合わせる能力。

仮想化使用可能な物理ストレージをストレージボリュームや仮想ボリュームに分割するためにサーバが使用する、ソフトウェアに実装された抽象化のレイヤー。


用語集

きギガビット Ethernet 1 Gbpsのデータ転送速度をサポートする Ethernetバージョン。

キャッシュ直近の書き込みや直近にアクセスされたデータのための一時的なストレージ。ディスクデータはキャッシュ経由で読み取られ、その後の読み取り参照はキャッシュ内で検索されます。

キャッシュ一貫性データの消失、破損、上書きを防ぐようなキャッシュ管理。プロセッサが複数ある場合はデータブロックのコピーが複数存在し、1つはメインメモリ上に、それ以外が各キャッシュメモリ上に置かれます。キャッシュ一貫性により、複数ユーザーのブロックがタイミングよくシステム全体に反映され、プロセッサキャッシュそれぞれにあるデータブロックで一貫性が失われないようになっています。

キロビット（Kb） 1,024（2の 10乗）ビット。一般に 10の 3乗に丸められます。

くクラスタ複数の VPLEXダイレクタが単一のフォルトトレラントクラスタを

形成して、1～ 4台のエンジンとして導入されたもの。

クラスタ ID マルチクラスタ導入における各クラスタの識別子。IDはインストール時に割り当てられます。

クラスタ導入 ID 1台の VPLEXクラスタの中で固有の、数字によるクラスタ識別子。デフォルトで、VPLEXクラスタにはクラスタ導入 IDとして 1が割り当てられます。マルチクラスタ導入では、1台を除いてすべてのクラスタが別のクラスタ導入 IDを持つよう再構成される必要があります。

クラスタリン複数のコンピュータを合わせて 1つのエンティティとして機能させること。フォルトトレランスやロードバランシングに関する利点があり、信頼性やアップタイムが向上します。

こコマンドラインインタ

フェース（CLI）コマンドを入力して特定のタスクを実行するために、コンピュータオペレーティングシステムまたはソフトウェアと対話する手法。


136

用語集

さ再構築ドライブ障害後に、スペアまたは交換用ドライブ上にデータを再構

築するプロセス。データは、ミラーリングが採用されていることを前提に、正常なディスク上のデータから再構築されます。

サイト ID マルチクラスタプレックス内の各クラスタの識別子。デフォルトでは、地理的に分散していないシステムの場合、IDは 0です。地理的に分散しているシステムの場合、クラスタ 1の IDが 1で、次が 2、のようになり、各番号が物理的に別個のクラスタを示します。サイト IDはインストール時に割り当てられます。

し冗長性ハードウェアおよびソフトウェアコンポーネントが重複しているこ

と。冗長システムでは、コンポーネントで障害が発生すると、冗長コンポーネントが引き継ぎ、処理が中断なく継続されます。

信頼性システムが消失データをリカバリする能力。

すストライピング複数のディスクドライブにデータを分散させる手法。ディスクのス

トライピングにより、データをディスクストレージから取得する処理が高速になります。データはユニット単位に分割され、使用可能な複数のディスクにわたって分散されます。RAID 0にはディスクのストライピング機能があります。

ストライプ深度 RAID 0デバイス内の各ストレージボリューム上に連続的に格納されるデータのブロック数。

ストレージ RTO 障害イベント後にストレージが使用可能になるまでにかかる時間（ストレージは前提条件なので、すべてのケースで RTOより短い時間になります）。

ストレージビューホストによるストレージへのアクセスを制御するために使用される、登録済みイニシエータ（ホスト）、フロントエンドポート、および仮想ボリュームの組み合わせ。

ストレージボリュームアレイからエクスポートされた LUN。


用語集

スプリットブレインパーティションされた DR1が両方のクラスタからの書き込みを受け入れる状況。「デタッチ競合」とも呼ばれます。

スループット 1. データ通信システムまたはそのシステムの一部分を通過するビット数、文字数、またはブロック数。

2. 通信チャネルまたはシステムの最大容量。

3. 決まった時間内にシステムによって実行される作業量の尺度。1日に処理される I/Oの数など。

せ選択（または優先）与えられた DR1に対してクラスタが選択（優先）されている場合、

そのクラスタはリモートクラスタとの接続が失われてもオンライン状態を維持します（VPLEX Cluster Witnessによって覆されることがあります）。従来は「バイアス」という表現が使用されていました。

たダーティデータキャッシュメモリに格納されていてディスクにまだ書き込まれてい

ない、書き込み特有のデータ。

帯域幅ネットワークが対応できる転送周波数の範囲。1回の転送サイクルにおける最高と最低の周波数の差で表されます。帯域幅が広いほど、高速または大容量の転送ができます。

ち地理的に分散している

システム2か所以上の地理的に離れたサイトにわたって物理的に分散しているシステム。分散の度合いは、同じキャンパス内や同じ都市内から異なる大陸間までさまざまです。

てデータ共有時間と場所に関係なく複数のサーバで同じデータへのアクセスを共

有する機能。

ディスクキャッシュディスクと CPUの間にキャッシュを提供する RAM部分。RAMアクセス時間はディスクアクセス時間よりきわめて速いので、ディスクキャッシュプログラムを使用して、最近アクセスしたデータをディスクキャッシュに配置すると、コンピュータの処理が高速になります。


138

用語集

デタッチルール障害発生時に優先されるクラスタおよび失われるクラスタを決定するために DR1に適用されるルールセット。

と同期オブジェクトまたはイベントでタイミングの一致が図られているこ

とを表す表現。処理を開始すると、それが完了してからでないと他のタスクを開始できません。

たとえば銀行業務において、同じ口座からの引き落としが 2件同時に始まったとしても、同時進行で処理するわけにはいきません。そのため、この 2件は同期で処理されます。「非同期」も参照。

に入出力（I/O）コンピュータから、またはコンピュータへデータを転送するあらゆ

る操作、プログラム、デバイス。

ねネームスペースファイルシステムによって認識される名前のセット。すべての名前

が固有であることが必要です。

ネットワークアーキテクチャ

ハードウェア、ソフトウェア、接続方式、使用プロトコルなどの、ネットワークの設計。

ネットワークパーティション

片方のサイトがもう片方のサイトとの接続または通信を失ったこと。

ネットワーク通信回線で接続されたコンピュータ、端末、データベースからなるシステム。

ネットワーク接続型ストレージ（NAS）

ネットワークに直接接続されているストレージエレメント。

はパーティション物理または仮想ディスクの一部。デバイスには見えず、エンドユー

ザーだけに見える論理エンティティです。

バイアス DR1にあるクラスタへのバイアスがある場合、そのクラスタはリモートクラスタとの接続が失われてもオンライン状態を維持します（VPLEX Cluster Witnessによって覆されることがあります）。本書では「選択」や「優先」という表現を採用しています。


用語集

バイト 8ビットのデータを格納するために使用されるメモリスペース。

パリティバイナリコードに含まれる 0または 1の数の奇偶性。

パリティチェックバイナリデータに含まれるエラーの確認。バイトに含まれるビット数が奇数か偶数かに応じて、パリティビットと呼ばれる 0または 1のビットが転送時に各バイトに付加されます。送信側と受信側で、奇数パリティ、偶数パリティ、パリティなしのどれかで合意しておきます。偶数パリティで合意した場合、パリティビットは各バイトに含まれる 1の数が偶数になるように付加されます。奇数パリティで合意した場合、パリティビットは各バイトに含まれる 1の数が奇数になるように付加されます。データが正しく転送されないとパリティが合意と合わなくなり、エラーがわかります。

ひビット情報の単位。0または 1という 1桁のバイナリ値のどちらかをとり

ます。

非同期オブジェクトまたはイベントでタイミングの一致が図られていないことを表す表現。非同期処理は他の処理と独立して行われ、開始されると ACKを受け取る前に他のタスク待ちになります。

たとえば、ホストはブレードにデータを書き込むと他の処理を始めますが、そのデータは非同期でローカルディスクに転送されたりWANに送り出されたりします。「同期」も参照。

ふフェイルオーバー現在アクティブなデバイス、システム、データパスの障害または異

常終了時に冗長またはスタンバイのデバイス、システム、データパスに自動的に切り替えること。

フォルトトレランスハードウェアまたはソフトウェア障害時にシステムが機能し続ける能力。通常は主要なシステムコンポーネントを複数持つことで達成されます。

フォルトドメイン HAソリューションの各コンポーネントを論理的または物理的な枠で分離して、片方のドメインで障害が発生しても影響がもう片方に伝わらないようにする、という概念。この枠には障害が発生しうる任意のアイテムがなりえます（たとえば、電源ドメインが別個に存在する場合なら、第 1ドメインで電源に障害が発生しても、第 2ドメインの電源は正常に供給されます）。


140

用語集

ブロック SCSI規格に従って転送できるデータの最小量。伝統的に 512バイトとされています。仮想ボリュームは、ブロックからなる連続リストとしてユーザーに提示されます。

ブロック長デバイス上におけるブロックの実サイズ。

プレックス VPLEXシングルクラスタ。

分散デバイスミラーが地理的に違う場所に存在している RAID 1デバイス。

みミラーリング複数のディスクへの同時データ書き込み。ディスクドライブのどれ

かが故障しても、システムはすぐさま他のディスクに切り替えるので、データやサービスの消失は起こりません。RAID 1ではミラーリングを行います。

めメタデータデータの品質、内容、条件のような、データに関するデータ。

メタボリュームシステムによって使用されるストレージボリューム。そのシステムが管理するすべての仮想ボリュームのメタデータが含まれます。メタデータストレージボリュームはクラスタあたり 1つです。

メトロプレックス VPLEX Metro向けに構成された DR1デバイス。

らライトスルーモードデータがディスクに書き込まれてはじめて書き込み要求完了のやり

とりがなされるキャッシュ技術。キャッシュなしのシステムとほとんど等価ですが、データが保護されます。

れレーテンシー I/O要求を満たすのに必要な時間。

ろローカルエリアネット

ワーク (ＬAN)同じ通信回線を共有し、一般には狭い地理的範囲内で単一のプロセッサまたはサーバのリソースを共有する、コンピュータと関連デバイスからなるグループ。


用語集

ロードバランシング処理や通信のアクティビティをシステムやネットワークを超えて均等に分散させることで、過負荷のデバイスが存在しないようにすること。ロードバランシングは、発行される I/O要求の数が予測不能の場合にとりわけ重要です。

論理ユニット番号（LUN）

1台のコンピュータに接続されている外部ハードドライブなどのSCSIデバイスを識別するために使用する番号。デバイスにはそれぞれ LUN番号が割り当てられ、そのデバイス固有のアドレスの役割を果たします。

わワイドエリアネット

ワーク（WAN）地理的に分散している通信ネットワーク。広域通信構造を LAN（Local Area Network）と区別する場合にこの用語を使用します。


142

用語集


VPLEX Metro Witnessテクノロジーと高可用性ƒ‘ーツ番号H7113.2. EMC VPLEX Metro Witness テクノロジーと高可用性 3

Documents