拡張システムの構成の詳細

システム上の各ノードが物理的に異なるサイトにあるエンハンスト拡張システム構成を作成できます。ボリューム・ミラーリングやコピー・サービスなどのミラーリング・テクノロジーと併用することで、これらの構成を使用して、電源障害やサイト全体の障害が発生した場合にシステム上のデータに継続してアクセスできます。

注: ソリューション設計の目的が高可用性である場合、機能強化された拡張システム構成ではなく IBM® HyperSwap® トポロジーを使用することをお勧めします。ただし、その目的に災害復旧、複雑なコピー・サービス、最高のスケーラビリティーといったトピックが含まれる場合は、現行バージョンの HyperSwap の制約事項について検討してください。詳しくは、高可用性のための計画を参照してください。

ここでは、システムのトポロジー属性を拡張に設定した、機能強化された拡張システムを詳しく説明しています。拡張システムを構成するために以前使用されていた方法 (現在でもサポートされています) については、旧バージョンの IBM Knowledge Center に説明があります。ここに記載されている最終構成手順に従うことにより、処理を中断させることなく現行の機能強化された拡張システム構成に移行でき、より優れた可用性と災害復旧を実現できます。また、拡張システム構成から HyperSwap システム構成にスムーズに移行して、さらに可用性、パフォーマンス、および災害復旧を向上させることもできます。既存システムのトポロジーの変更に関するガイダンスについては、IBM Remote Technical Support Center にお問い合わせください。

拡張システム構成では、各サイトは独立した障害ドメインとして定義されます。一方のサイトで障害が発生しても、他方のサイトは中断することなく継続して稼働できます。また、主要な 2 つのサイト間で潜在的なリンク障害が発生した場合に、自動的に競合状態を提供するクォーラム・デバイスをホストするために、3 番目のサイトを構成する必要があります。メインサイトは、データ・センター内の同じ部屋あるいはデータ・センター内の複数の部屋に配置することができ、また、同じ構内にある複数の建物、あるいは別の市にある複数の建物に配置することもできます。異なる種類のサイトが存在することにより、さまざまなタイプの障害からの保護が可能です。

複数のサイトが単一ロケーションにある場合: 単一のロケーションあるいはデータ・センター内でそれぞれのサイトの電源フェーズが異なる場合、システムは 1 つの電源ドメインに障害が発生しても継続して稼働できます。例えば、1 つのノードをあるラックに取り付け、別のノードを別のラックに取り付けることができます。それぞれのラックは、独自の電源フェーズを持つ別のサイトと見なされます。この場合、いずれかのラックへの電源が失われたとき、もう一方のラックにあるパートナー・ノードが要求を処理できるように構成することができ、影響を受けたノードが電源が切断されたためにオフラインとなった時でも実際にはデータを使用できるようにすることができます。
各サイトが別のロケーションにある場合: それぞれのサイトの物理的な場所が異なる場合、システムは単一の場所に障害が発生しても継続して稼働できます。これらのサイトは、例えば同じ市内にある 2 つのサイトのように距離の短い範囲にまたがることができます。または、別の市内にある 2 つのサイトのような地理的に遠く離れた範囲に広がることもできます。あるサイトでそのサイト全体の災害が発生した場合でも、残りのサイトでは引き続き要求の処理を行える状態にすることができます。

1 つのサイトが失われた後でも、適切な構成を行っていればシステムは継続して稼働できます。主要な前提条件は、各サイトに、各ノード・ペアから 1 つのノードのみが含まれていることです。同じシステムのノード・ペアを拡張システム構成用に別のサイトに配置するだけでは、高可用性を提供することにはなりません。適切なミラーリング・テクノロジーを構成し、それらのテクノロジーのすべての構成要件を確実に正しく構成することも必要です。

注:

SAN ボリューム・コントローラー 2145-DH8、2145-CG8、または 2145-CF8 モデルでは、内部フラッシュ・ドライブを使用するノードは推奨されません。
拡張システムは、N_Port ID Virtualization (NPIV) と共に使用することができます。サイト損失では、リモート・サイト・ノード上のファイバー・チャネル・フェイルオーバー・ポートが開き、ローカル・ノードからのファイバー・チャネル・ホスト・ポートのワールド・ワイド・ポート名 (WWPN) にファブリックをファブリックに提示します。NPIV により、ホストはマルチパス・ドライバーからの再ルーティング不要で、これらのポートにログバックすることができます。この場合、物理的にリモート・サイトにあるポートへのデータの往復通過時間がかかるため、待ち時間がさらに長くなる可能性があります。
すべてのサイトで両方の外部ストレージ・システムに直接アクセスできるように、十分な接続を使用して、アクティブ/パッシブ・コントローラー (IBM DS5000™、IBM DS4000®、および IBM DS3000 システムなど) を使用する拡張システム・ファイバー・チャネル構成を構成する必要があります。Storwize® ファミリーシステムなどの複数のアクティブ/パッシブ・コントローラーを使用する iSCSI 構成では、システムは、すべてのサイトが両方の外部ストレージ・システムに直接アクセスできるように十分な数の接続を使用して構成されている必要があります。拡張システムのクォーラム・アクセスは、アクティブなクォーラム・ディスクとして使用されている MDisk の現行所有者を介してのみ可能です。

拡張システムは、以下の要件を満たすように構成する必要があります。

ファイバー・チャネル接続では、各ノードを、1 次サイトおよび 2 次サイトの複数の SAN ファブリック (2 個から 8 個のファブリックがサポートされます) に直接接続します。iSCSI 接続では、各ノードを、1 次サイトおよび 2 次サイトの複数のイーサネット・ファブリックに接続します。サイトは独立した障害ドメインとして定義されます。境界内の障害 (電源障害、火災、または洪水など) が境界内に留まり、障害がその境界の外側にある部分に伝搬したり影響を与えたりしないように、障害ドメインが境界内のシステムに含まれます。障害ドメインは、データ・センター内の同じ部屋あるいはデータ・センター内の複数の部屋にまたがって配置することができ、また、同じ構内にある複数の建物、あるいは別の町にある複数の建物に配置することができます。異なる種類の障害ドメインが存在することにより、さまざまなタイプの障害からの保護が可能です。
3 番目のサイトを使用してクォーラム・ディスクまたは IP クォーラム・アプリケーションを収める。クォーラム・ディスクは、iSCSI 接続ストレージ・システムに配置することはできません。したがって、iSCSI ストレージは第 3 のサイトに構成することはできません。
3 番目のサイトでストレージ・システムが使用されている場合、そのストレージ・システムは、拡張クォーラム・ディスクをサポートしている必要があります。詳しい情報は、以下の Web サイトで利用できるインターオペラビリティー・マトリックスに記載されています。
```
www.ibm.com/storage/support/2145
```
独立したストレージ・システムを 1 次サイトおよび 2 次サイトに配置し、ボリューム・ミラーリングを使用して、2 つのサイトのストレージ・システムの間でホスト・データをミラーリングする。可能であれば、各ボリュームの優先ノードを、そのボリュームがマップされるホストと同じサイト内にあるノードに設定します。
接続は、ファイバー・タイプおよび small form-factor pluggable (SFP) トランシーバー (長波と短波) によって異なる可能性があります。
同じ入出力グループ内にあり、100 メートル (109 ヤード) を超えて分離されているノードは、長波ファイバー・チャネルまたは iSCSI 接続を使用する必要がある。長波 small form-factor pluggable (SFP) トランシーバーは、オプション・コンポーネントとして購入可能であり、以下の Web サイトにリストされている長波 SFP トランシーバーのいずれかを使用する必要がある。
```
www.ibm.com/storage/support/2145
```
ノードと外部ストレージ・システムの間のパスでのスイッチ間リンク (ISL) の使用は避ける。これが避けられない場合は、ISL 間の大量のファイバー・チャネル・トラフィックによる ISL の定量オーバーが起きないようにしてください。大部分の構成で、トランキングが必要です。 ISL の問題は診断が難しいので、障害を検出するために、スイッチ・ポートのエラー統計を収集し、定期的にモニターする必要があります。
3 番目のサイトで単一スイッチを使用することは、2 つの独立で予備のファブリックではなく、単一ファブリックの作成につながる可能性がある。単一ファブリックは、サポートされていない構成です。
すべてのノード上のイーサネット・ポート 1 を、同じサブネット (複数可) に接続する必要があります。すべてのノードのイーサネット・ポート 2 (使用している場合) は、同じサブネットに接続されている必要があります (ポート 1 のサブネットとは別のサブネットでも構いません)。別のイーサネット・ポートにも同じ原則が適用されます。
ノードは、電源の供給元である 2145 UPS または 2145 UPS-1U と同じラックに配置する必要があります。
一部のサービス・アクションでは、システム内のすべてのノードに物理的にアクセスする必要がある。拡張システム内のノードが 100 メートルを超えて分離されている場合、サービス・アクションに複数のサービス担当員が必要な場合がある。複数サイトのサポートについてサービス担当員に連絡を取ってください。

拡張システムは、アクティブ・クォーラム・ディスクまたは IP クォーラム・アプリケーションを 3 番目のサイトに配置します。1 次サイトと 2 次サイトの間の通信が失われた場合、アクティブ・クォーラム・ディスクにアクセスできるサイトがトランザクションの処理を続行します。アクティブ・クォーラム・ディスクへの通信が失われた場合は、別のサイトの代わりのクォーラム・ディスクがアクティブ・クォーラム・ディスクになることができます。

ノードのシステムは、最大 3 つのクォーラム・ディスクを使用するように構成できますが、システムがサイズの等しい 2 組のノードに分割されている場合の状態を解決するためには、1 つのクォーラム・ディスクしか選択されません。それ以外のクォーラム・ディスクの目的は、システムが分割される前にクォーラム・ディスクに障害が起きた場合の冗長性を提供することです。

図 1 に、拡張システム構成の例を示します。この構成は、ボリューム・ミラーリングと一緒に使用されると、単一サイトでの障害に耐えることができる高可用性ソリューションを提供します。1 次サイトまたは 2 次サイトのどちらで障害が起きても、残りのサイトは入出力操作を引き続き実行できます。この構成では、システム内の SAN ボリューム・コントローラー・ノード間の接続は 100 メートルより長い距離があるので、長波ファイバー・チャネル接続でなければなりません。

図 1. クォーラム・ディスクが 3 番目のサイトにある拡張システム

図 1 では、3 番目のサイトのクォーラム・ディスクをホストするストレージ・システムが、1 次サイトおよび 2 次サイトの両方で、長波ファイバー・チャネル接続を使用して、スイッチに直接接続されています。1 次サイトまたは 2 次サイトのどちらに障害が起こった場合でも、残りのサイトが、クォーラム・ディスクをホストするストレージ・システムへの直接アクセスを保持するようにする必要があります。

制約事項: サイト内のストレージ・システムを別のサイトのスイッチ・ファブリックに直接接続しないでください。

これに代わる構成として、3 番目のサイトで追加のファイバー・チャネル・スイッチを使用し、そのスイッチから 1 次サイトと 2 次サイトに接続するようにできます。

拡張システム構成がサポートされるのは、クォーラム・ディスクをホストするストレージ・システムが拡張クォーラムをサポートする場合のみです。 SAN ボリューム・コントローラーは、他のタイプのストレージ・システムを使用してクォーラム・ディスクを提供できますが、これらのクォーラム・ディスクへのアクセスは常に、単一のパスを通じて行われます。

クォーラム・ディスク構成の要件については、「Guidance for Identifying and Changing Managed Disks Assigned as Quorum Disk Candidates」の技術情報を参照してください。

拡張システム構成でミラーリングされたボリュームをセットアップする際は、ミラーの書き込み優先順位を redundancy に設定して、完了した書き込みにおける一時的な遅延があっても、コピーの同期を維持します。詳しくは、ミラーリングされたボリュームに関する情報を参照してください。

拡張システムおよびメトロ・ミラーまたはグローバル・ミラー

拡張システムは、1 つの障害ドメインを失った後も継続して稼働するように設計されています。

拡張システムでは、2 つの障害ドメインに障害が発生した後の稼働は保証できません。機能強化された拡張システム機能が構成されている場合は、この状況に対して手動オーバーライドを有効にすることができます。また、2 番目の SAN ボリューム・コントローラー・システム上で、メトロ・ミラーまたはグローバル・ミラーを、機能強化された拡張システムまたは従来型の拡張システムのいずれかで拡張災害復旧に使用できます。拡張システムが含まれるメトロ・ミラーまたはグローバル・ミラーの協力関係を、他のリモート・コピー関係と同じ方法で構成および管理します。SAN ボリューム・コントローラーは、メトロ・ミラーまたはグローバル・ミラーを使用するシステム間接続用に、FCIP リンクを含む SAN ルーティング・テクノロジーをサポートします。

パートナーの SAN ボリューム・コントローラー拡張システムは、SAN ボリューム・コントローラー拡張システムの実動場所にあってはなりません。ただし、拡張システムのアクティブ・クォーラム・ディスクを提供しているストレージ・システムに連結することは可能です。

構成手順

これらの追加構成ステップは、コマンド・ライン・インターフェース (CLI) または管理 GUI を使用して実行できます。

システム内の各 SAN ボリューム・コントローラー・ノードを、サイトに割り当てる必要があります。chnode CLI コマンドを使用します。
各バックエンド・ストレージ・システムを、サイトに割り当てる必要があります。chcontroller CLI コマンドを使用します。
各ホストをサイトに割り当てる必要があります。chhost CLI コマンドを使用します。
すべてのノード、ホスト、およびストレージ・システムをサイトに割り当てた後、システム・トポロジーを stretched に変更することにより、機能強化モードを有効にする必要があります。
最良の結果を達成するために、少なくとも 2 つの入出力グループ (4 つのノード) を含むように機能強化された拡張システムを構成します。入出力グループを 1 つしか含まないシステムでは、ノード障害やシステム更新時にデータのミラーリングや中断を伴わないホスト・アクセスの継続は保証できません。

SAN ボリューム・コントローラーの拡張システムでは、2 つの障害ドメインに障害が発生した後の稼働は保証できません。機能強化された拡張システム機能が構成されている場合は、この状況に対して手動オーバーライドを有効にすることができます。また、2 番目の SAN ボリューム・コントローラー・システム上で、メトロ・ミラーまたはグローバル・ミラーを機能強化された拡張システムまたは従来型の拡張システムのいずれかで使用して、拡張災害復旧を行うことができます。拡張システムが含まれるメトロ・ミラーまたはグローバル・ミラーの協力関係を、他のリモート・コピー関係と同じ方法で構成および管理します。SAN ボリューム・コントローラーは、メトロ・ミラーまたはグローバル・ミラーを使用するシステム間接続に対して、SAN ルーティング・テクノロジー (FCIP リンクを含む) をサポートします。