High Availability Cluster Multi-Processing for AIXpublic.dhe.ibm.com/systems/power/docs/powerha/61/nl/ja/...本書について本書は、High Availability Cluster Multi-Processing

High Availability Cluster Multi-Processingfor AIX

プランニング・ガイド

��

High Availability Cluster Multi-Processingfor AIX

プランニング・ガイド

��

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

本書は、HACMP 6.1 for AIX および新しい版で明記されていない限り、以降のすべてのリリースおよびモディフィケーションに適用されます。

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

　

原典： High Availability Cluster Multi-Processing for AIX

Planning guide

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

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

© Copyright IBM Corporation 1998, 2014.

目次本書について . . . . . . . . . . . . . v強調表示 . . . . . . . . . . . . . . . . vAIX での大/小文字の区別 . . . . . . . . . . vISO 9000 . . . . . . . . . . . . . . . vHACMP の資料 . . . . . . . . . . . . . vHACMP/XD の資料 . . . . . . . . . . . . viHACMP Smart Assist の資料 . . . . . . . . . vi

計画 . . . . . . . . . . . . . . . . 1「HACMP プランニング」の新規情報 . . . . . . 1計画プロセス目標の概説 . . . . . . . . . . 1計画のガイドライン . . . . . . . . . . . 2単一障害点の除去: HACMP でサポートされる冗長コンポーネントの構成 . . . . . . . . . . 3計画ツールの概説 . . . . . . . . . . . . 4計画プロセスの概説 . . . . . . . . . . . 4

クラスターの初期計画 . . . . . . . . . . . 6概説 . . . . . . . . . . . . . . . . 6クラスター・ノードの計画 . . . . . . . . . 7クラスター・サイトの計画 . . . . . . . . . 8クラスター・セキュリティーの計画 . . . . . 11アプリケーションの計画 . . . . . . . . . 12アプリケーションとアプリケーション・サーバーの計画 . . . . . . . . . . . . . . . 16AIX Fast Connect の計画 . . . . . . . . . 22高可用性通信リンクの計画 . . . . . . . . 24クラスター・ダイアグラムの作図 . . . . . . 27

クラスター・ネットワーク接続の計画 . . . . . 28概説 . . . . . . . . . . . . . . . . 29HACMP の一般的なネットワーク考慮事項 . . . 30HACMP でのハートビート . . . . . . . . 35IP エイリアスを使用するハートビート . . . . 36ディスクを使用するハートビート . . . . . . 40ネットワーク・トポロジーの設計 . . . . . . 41IP エイリアスによる IP アドレス・テークオーバーの計画 . . . . . . . . . . . . . . 50IP 交換による IP アドレス・テークオーバーの計画 . . . . . . . . . . . . . . . . 54他のネットワーク条件の計画 . . . . . . . 55ネットワーク・ワークシートの記入 . . . . . 65ハードウェア・アドレスの定義 . . . . . . . 69クラスター・ダイアグラムへのネットワーク・トポロジーの追加 . . . . . . . . . . . . 72

共用ディスクおよびテープ・デバイスの計画 . . . 73共用ディスクおよびテープ・デバイスの概説 . . 73共用ディスク・テクノロジーの選択 . . . . . 74ディスク電源装置の考慮事項 . . . . . . . 81非共用ディスク・ストレージの計画 . . . . . 82共用 SCSI ディスクのインストール計画 . . . . 83共用 IBM SSA ディスク・サブシステムのインストール計画 . . . . . . . . . . . . . 86

ディスク・ワークシートの記入 . . . . . . . 92クラスター・ダイアグラムへのディスク構成の追加 . . . . . . . . . . . . . . . . 94クラスター・リソースとしてのテープ・ドライブに関する計画 . . . . . . . . . . . . . 94

共用 LVM コンポーネントの計画 . . . . . . . 96概説 . . . . . . . . . . . . . . . . 97LVM コンポーネントの計画 . . . . . . . . 97LVM ミラーリングの計画 . . . . . . . . 99ディスク・アクセスの計画 . . . . . . . . 102高速ディスク・テークオーバーの使用 . . . . 104クォーラムおよび varyon を使用してデータの可用性を高める . . . . . . . . . . . . 106HACMP による NFS の使用 . . . . . . . 109共用 LVM コンポーネント・ワークシートの記入 . . . . . . . . . . . . . . . . 118クラスター・ダイアグラムへの LVM 情報の追加 . . . . . . . . . . . . . . . . 123

リソース・グループの計画 . . . . . . . . . 123リソース・グループの概説 . . . . . . . . 124リソースおよびリソース・グループの一般的な規則 . . . . . . . . . . . . . . . . 1242 つのタイプのリソース・グループ: コンカレントおよび非コンカレント . . . . . . . . . 125始動、フォールオーバー、およびフォールバックのリソース・グループ・ポリシー . . . . . . 126リソース・グループ属性 . . . . . . . . . 127別のノードへのリソース・グループの移動 . . . 134クラスター・ネットワークとリソース・グループの計画 . . . . . . . . . . . . . . . 136リソース・グループの並列処理順序または順次処理順序の計画 . . . . . . . . . . . . 138サイトを持つクラスター内のリソース・グループの計画 . . . . . . . . . . . . . . . 139複製リソースの計画 . . . . . . . . . . 146ノード始動時のリソース・グループの回復 . . . 147ワークロード・マネージャーの計画 . . . . . 147リソース・グループ・ワークシートの記入 . . . 150

クラスター・イベントの計画 . . . . . . . . 154サイトおよびノード・イベントの計画 . . . . 155node_up および node_down イベントの順序 . . 156ネットワーク・イベント . . . . . . . . . 160ネットワーク・インターフェース・イベント . . 161クラスター全体のステータス・イベント . . . 163リソース・グループのイベント処理と回復 . . . 163クラスター・イベント処理のカスタマイズ . . . 166イベントのカスタム・リモート通知 . . . . . 171警告までのイベント期間のカスタマイズ . . . 172ユーザー定義イベント . . . . . . . . . 173イベントの要約とプリアンブル . . . . . . 176クラスター・イベント・ワークシート . . . . 176

© Copyright IBM Corp. 1998, 2014 iii

HACMP クライアントの計画 . . . . . . . . 177HACMP クライアントの概説 . . . . . . . 177Clinfo を実行しているクライアント . . . . . 178Clinfo を実行していないクライアント . . . . 178ネットワーク・コンポーネント . . . . . . 179

オンライン・プランニング・ワークシートの使用 179オンライン・プランニング・ワークシート・アプリケーションの概説 . . . . . . . . . . 180オンライン・プランニング・ワークシート・アプリケーションのインストール . . . . . . . 181アプリケーションの始動および停止 . . . . . 183オンライン・プランニング・ワークシート・アプリケーションの使用 . . . . . . . . . . 183クラスターの計画 . . . . . . . . . . . 192クラスター定義ファイルの理解 . . . . . . 199HACMP クラスター構成の OLPW への変換 . . 201HACMP クラスターへのワークシート・データの適用 . . . . . . . . . . . . . . . 203

プランニング・ワークシート . . . . . . . . 2042 ノード・クラスター構成ワークシート . . . 204TCP/IP ネットワーク・ワークシート . . . . 205TCP/IP ネットワーク・インターフェース・ワークシート . . . . . . . . . . . . . . 206Point-to-Point ネットワーク・ワークシート . . 207シリアル・ネットワーク・インターフェース・ワークシート . . . . . . . . . . . . . 208ファイバー・チャネル・ディスク・ワークシート 209共用 SCSI ディスク・ワークシート . . . . . 210共用 IBM SCSI ディスク・アレイ・ワークシート . . . . . . . . . . . . . . . . 210共用 IBM SCSI 磁気テープ・ドライブ・ワークシート . . . . . . . . . . . . . . . 211共用 IBM Fibre 磁気テープ・ドライブ・ワークシート . . . . . . . . . . . . . . . 212共用 IBM シリアル・ストレージ・アーキテクチャー・ディスク・サブシステム・ワークシート . 213非共用ボリューム・グループ・ワークシート (非コンカレント・アクセス) . . . . . . . . 214共用ボリューム・グループおよびファイルシステム・ワークシート (非コンカレント・アクセス) . 215

NFS エクスポートされるファイルシステムまたはディレクトリー・ワークシート (非コンカレント・アクセス) . . . . . . . . . . . . 217非共用ボリューム・グループ・ワークシート (コンカレント・アクセス) . . . . . . . . . 218共用ボリューム・グループおよびファイルシステム・ワークシート (コンカレント・アクセス) . . 219アプリケーション・ワークシート . . . . . . 220Fast Connect ワークシート . . . . . . . . 221通信リンク (SNA-over-LAN) ワークシート . . 222通信リンク (X.25) ワークシート . . . . . . 222通信リンク (SNA-Over-X.25) ワークシート . . 223アプリケーション・サーバー・ワークシート . . 224アプリケーション・モニター・ワークシート (プロセス・モニター). . . . . . . . . . . 225アプリケーション・モニター・ワークシート (ユーザー定義モニター) . . . . . . . . . . 226リソース・グループ・ワークシート . . . . . 227クラスター・イベント・ワークシート . . . . 228クラスター・サイト・ワークシート . . . . . 230HACMP ファイル・コレクション・ワークシート . . . . . . . . . . . . . . . . 231WebSMIT ユーザー・プランニング・ワークシート . . . . . . . . . . . . . . . . 231WebSMIT クラスター・プランニング・ワークシート . . . . . . . . . . . . . . . 232

アプリケーションと HACMP . . . . . . . . 233アプリケーションと HACMP の概説 . . . . 233アプリケーションの自動化: 手操作による介入を最小限に抑える . . . . . . . . . . . . 234アプリケーションの依存関係 . . . . . . . 237アプリケーションの干渉 . . . . . . . . . 238アプリケーションの堅固性 . . . . . . . . 239アプリケーションのインプリメンテーション方針 239

特記事項. . . . . . . . . . . . . . 243プライバシー・ポリシーに関する考慮事項 . . . . 245商標 . . . . . . . . . . . . . . . . 245

索引 . . . . . . . . . . . . . . . 247

iv High Availability Cluster Multi-Processing for AIX: プランニング・ガイド

本書について

本書は、High Availability Cluster Multi-Processing for AIX (HACMP) ソフトウェアについて記載されています。この情報は、オペレーティング・システム付属の文書 CD にも収録されています。

強調表示本書では、以下の強調表示の規則を使用しています。

項目説明

太字システムによって名前が事前に定義されているコマンド、サブルーチン、キーワード、ファイル、構造、ディレクトリー、およびその他の項目を示します。また、ユーザーが選択するボタン、ラベル、アイコンなどのグラフィカル・オブジェクトも示します。

イタリック実際の名前または値をユーザーが指定する必要があるパラメーターを示します。

モノスペース特定のデータ値の例、画面に表示されるものと同様のテキスト例、プログラマーが作成するものと同様のプログラム・コード部分の例、システムからのメッセージ、実際に入力する必要がある情報などを示します。

AIX での大/小文字の区別AIX® オペレーティング・システムは、すべてケース・センシティブとなっています。これは、英大文字と小文字が区別されるということです。例えば、ls コマンドを使用するとファイルをリスト表示できます。LS と入力した場合、そのようなコマンドはないという応答がシステムから返ってきます。同様に、FILEA、FiLea、および filea は、同じディレクトリーにある場合でも、3 つの異なるファイル名です。予期しない処理が実行されないように、常に正しい大/小文字を使用するようにしてください。

ISO 9000当製品の開発および製造には、ISO 9000 登録品質システムが使用されました。

HACMP の資料HACMP ソフトウェアの資料は次のとおりです。

v 「HACMP for AIX Release Notes」(場所: /usr/es/sbin/cluster/release_notes) では、AIX プラットフォーム上の HACMP に関する問題を説明しています。これには、ハードウェアとソフトウェアの要件、インストールに関する最新情報、製品の使用法、および既知の問題が含まれます。

v 「HACMP for AIX 管理ガイド」(SD88-8551)

v 「HACMP for AIX 概念および機能のガイド」(SD88-8552)

v 「HACMP for AIX インストール・ガイド」(SC88-4201)

v 「HACMP for AIX HACMP 用語集」(SD88-8553)

v 「HACMP for AIX プランニング・ガイド」(SD88-8550)

v 「HACMP for AIX Programming Client Applications」(SC23-4865)

v 「HACMP for AIX トラブルシューティング・ガイド」(SD88-8641)

v 「HACMP on Linux インストールおよび管理ガイド」(SC88-4202)

v 「HACMP for AIX: Smart Assist Developer's Guide」(SC23-5210)

© Copyright IBM Corp. 1998, 2014 v

v プログラムのご使用条件

HACMP/XD の資料災害復旧用の HACMP Extended Distance (HACMP/XD) ソフトウェア・ソリューションを基本 HACMP ソフトウェアに追加すると、遠距離にある 2 つのサイト間でクラスターを運用できます。HACMP/XD の資料には次の資料が含まれます。

v 「HACMP/XD for Geographic LVM (GLVM) プランニングおよび管理ガイド」(SA88-4160)

v 「HACMP/XD for Metro Mirror プランニングおよび管理ガイド」(SC88-8050)

HACMP Smart Assist の資料HACMP Smart Assist ソフトウェアを使用すると、特定アプリケーションのインスタンスを HACMP 構成に短時間で追加するのに役立ち、HACMP でこれらの可用性を管理できるようになります。HACMP Smart

Assist の資料には次の資料が含まれます。

v 「HACMP Smart Assist for DB2 User's Guide」(SC23-5179)

v 「HACMP Smart Assist for Oracle User's Guide」(SC23-5178)

v 「HACMP Smart Assist for WebSphere User's Guide」(SC23-4877)

v 「HACMP for AIX: Smart Assist Developer's Guide」(SC23-5210)

v HACMP Smart Assist Release Notes (/usr/es/sbin/cluster/release_notes_assist)

vi High Availability Cluster Multi-Processing for AIX: プランニング・ガイド

計画

本書には、High Availability Cluster Multi-Processing for AIX (HACMP) ソフトウェアの計画に必要な情報が記載されています。

注: Power HA for AIX は、HACMP™ の新しい名前です。本書では引き続き HACMP という用語を使用します。

「HACMP プランニング」の新規情報「HACMP プランニング」トピック集の新規または大幅に変更された情報を見ます。

新規情報または変更情報の参照方法

この PDF ファイルでは、左マージンに新規および変更情報を示すリビジョン・バー (|) が表示される場合があります。

2014 年 6 月

61ページの『netmon.cf ファイルの作成』のトピックで、統合仮想イーサネット (IVE) に関する情報が追加されました。

2013 年 3 月

Network File System (NFS) クロスマウントの構成に関する追加情報については、 112ページの『HACMP

での NFS クロスマウント』を参照してください。

2012 年 2 月

次の更新は、HACMP 6.1 以降に適用されます。

v 使用されなくなった情報を削除しました。

計画プロセス目標の概説計画プロセスにおける主要な目標は、Single Point of Failure を除去することです。single point of failure

は、重要なクラスター機能が、単一のコンポーネントによって提供されている場合に発生します。該当するコンポーネントに障害が発生した場合、クラスター機能を提供する他の手段が存在しないため、該当するコンポーネントに依存するアプリケーションおよびサービスが利用できなくなります。

例えば、基幹アプリケーションのデータがすべて単一のディスクに存在しており、そのディスクに障害が発生した場合、そのディスクはクラスター全体の Single Point of Failure となります。ディスク上のデータが復元されるまで、クライアントはアプリケーションにアクセスできません。同様に、動的なアプリケーション・データが外部ディスクではなく内部ディスクに格納されている場合、別のクラスター・ノードにこれらのディスクをテークオーバーさせてもアプリケーションを回復することはできません。したがって、アプリケーションに必要なファイルシステムやディレクトリーなどの論理コンポーネント (アプリケーション・データ、構成変数なども含まれます) の特定が、クラスターの計画を成功させるための重要な前提条件となります。

© Copyright IBM Corp. 1998, 2014 1

目標は Single Point of Failure をすべて除去することですが、ある程度の妥協は必要です。一般に、Single

Point of Failure の解消にはコストがかかります。例えば、1 次デバイスのバックアップ用として機能するハードウェア・デバイスを追加購入すると、コストが増大します。したがって、Single Point of Failure を解消するためのコストと、コンポーネントに障害が発生した場合のサービス停止により発生するコストとを比較する必要があります。繰り返しますが、HACMP の目的は、費用対効果と可用性が高く、将来的に要求される処理能力を満たす拡張が可能なコンピューティング・プラットフォームを提供することです。

注: クラスター・コンポーネントの障害は、できるだけ早く修復することが重要です。構成によっては、リソース不足が原因で HACMP が 2 次障害に対応できない場合があります。

計画のガイドライン組織にとって最良のソリューションとなるクラスターを設計するには、細心の注意と周到な計画が必要です。実際、適切な計画は、HACMP クラスターの構築を成功させるための鍵となります。綿密に計画されたクラスターは、計画が不十分なクラスターに比べてインストールしやすく、アプリケーションの高可用性を提供し、パフォーマンスが優れ、保守の必要性も減少します。

基幹アプリケーションの可用性を高めるには、関連するリソースが Single Point of Failure とならないようにする必要があります。HACMP クラスターを設計するときの目標は、潜在的な Single Point of Failure をすべて特定し、それに対処することです。設計に際しては、以下の点に留意します。

v 可用性を高める必要があるアプリケーション・サービスの特定。これらのアプリケーション・サービスの優先順位の決定。

v 障害が発生した場合のコストと、障害の可能性を取り除くために必要なハードウェアのコストの比較。

v HACMP がサポートできる冗長ハードウェアおよびソフトウェア・コンポーネントの最大数(『単一障害点の除去: HACMP でサポートされる冗長コンポーネントの構成』を参照してください)。

v これらのサービスに関して必要とされる可用性。1 日 24 時間×週 7 日の可用性が要求されるのか、1

日 8 時間×週 5 日で十分なのか。

v これらのサービスの可用性が損なわれる原因。

v 障害が発生したリソースを交換するために割り当てられる時間の長さ。障害発生直後の運用時に、パフォーマンスの低下をどの程度容認できるか。

v クラスター・イベントとして自動的に検出される障害。障害を検出しクラスター・イベントをトリガーするためのユーザー定義コードを作成する必要がある障害の決定。

v クラスターをインプリメントするグループのスキル・レベル。クラスターを保守するグループのスキル・レベル。

HACMP クラスターの計画、インプリメント、保守を成功させるには、組織内のグループ間で常に連絡を取り合うことが必要です。理想としては、HACMP の計画セッションを支援するため、以下に示す (該当する) 担当者を招集します。

v ネットワーク管理者

v システム管理者

v データベース管理者

v アプリケーション・プログラミング

v サポート担当者

v エンド・ユーザー

2 High Availability Cluster Multi-Processing for AIX: プランニング・ガイド

HACMP は、さまざまな構成をサポートすることで高い柔軟性を提供します。最高レベルの可用性のクラスターを設計するための詳細については、IBM® ホワイトペーパー「High Availability Cluster

Multiprocessing Best Practices」を参照してください。

関連資料:

『単一障害点の除去: HACMP でサポートされる冗長コンポーネントの構成』HACMP ソフトウェアには、Single Point of Failure を防ぐための数多くのオプションがあります。

関連情報:

High Availability Cluster Multiprocessing Best Practices

単一障害点の除去: HACMP でサポートされる冗長コンポーネントの構成HACMP ソフトウェアには、Single Point of Failure を防ぐための数多くのオプションがあります。

次の表では、潜在的な Single Point of Failure と、冗長ハードウェア/ソフトウェア・クラスター・コンポーネントを構成してこれらを解消する方法を示します。

クラスター・コンポーネント Single Point of Failure を解消する方法 HACMP サポート

ノード複数のノードを使用する 32 まで電源複数の回路または無停電電源装置を使用する必要なだけネットワーク複数のネットワークを使用してノードを接続する 48 までネットワーク・インターフェース、デバイス、およびラベル

冗長ネットワーク・アダプターを使用する 256 まで

TCP/IP サブシステムネットワークを使用して隣接するノードおよびクライアントを接続する

必要なだけ

ディスク・アダプター冗長ディスク・アダプターを使用する必要なだけコントローラー冗長ディスク・コントローラーを使用する必要なだけディスク冗長ハードウェアとディスク・ミラーリングおよ

び (または) ストライピングを使用する必要なだけ

アプリケーションアプリケーションのテークオーバーのためにノードを割り当て、アプリケーション・モニターを構成し、複数のサイトのノードからなるクラスターを構成する

必要なだけ

サイト災害復旧のために複数のサイトを使用する 2

リソース・グループリソース・グループを使用して、一連のエンティティーの動作を指定する

クラスターごとに 64 まで

クラスター・リソース複数のクラスター・リソースを使用する Clinfo の場合は最大 128 (クラスター内にはさらに多く存在できる)

VIO サーバー冗長 VIO サーバーを使用する必要なだけHMC 冗長 HMC を使用する 2

クラスター・ノードをホスティングする管理対象システム

クラスター・ノードをホスティングする管理対象システム

できるだけ多くの別個の管理対象システム

関連資料:

2ページの『計画のガイドライン』組織にとって最良のソリューションとなるクラスターを設計するには、細心の注意と周到な計画が必要です。実際、適切な計画は、HACMP クラスターの構築を成功させるための鍵となります。綿密に計画されたクラスターは、計画が不十分なクラスターに比べてインストールしやすく、アプリケーションの高可用性を提供し、パフォーマンスが優れ、保守の必要性も減少します。

計画 3

http://www.ibm.com/servers/eserver/clusters/whitepapers/hacmp_bestpractices.html

計画ツールの概説このセクションでは、HACMP の計画ツール (ワークシート) について説明します。

このツールは、『計画プロセスの概説』に説明されている手順に従って使用してください。計画プロセスを支援するため、クラスター計画プロセスの各段階について、計画作業に対応したワークシートが用意されています。

ワークシート用紙

手書きで記入し、手元に置いてクラスターの構成時に参照するワークシート用紙が『プランニング・ワークシート』にあります。

オンライン・プランニング・ワークシート・アプリケーション

オンライン・プランニング・ワークシート・アプリケーションとは、ワークシート用紙のオンライン・バージョンです。このアプリケーションは次の利点を提供します。

v クラスターの計画時にワークシートにデータを入力して、ワークシートをオンラインで保存できます。

v HACMP では、計画プロセスの最後の段階で、計画データを実際の HACMP クラスター構成に変換できます。詳しくは、『オンライン・プランニング・ワークシートの使用』を参照してください。

関連概念:

204ページの『プランニング・ワークシート』本書 PDF 版からプランニング・ワークシートを印刷してご利用ください。PDF 版では、それぞれのワークシートがページのトップから始まるように調整されています。ワークシートのコピーが 2 部以上必要になる場合もあります。

関連資料:

『計画プロセスの概説』このセクションでは、HACMP クラスターを計画する際のステップについて説明します。

179ページの『オンライン・プランニング・ワークシートの使用』本トピックでは、オンライン・プランニング・ワークシート (OLPW) アプリケーションを使用して、クラスター定義ファイル (ワークシート・ファイルとも呼ばれる) を作成する方法について説明します。本トピックではまた、クラスター定義ファイルと、ファイルを使用して既存の HACMP クラスターを定義する方法について説明します。

計画プロセスの概説このセクションでは、HACMP クラスターを計画する際のステップについて説明します。

ステップ 1: 高可用性アプリケーションの計画

このステップでは、クラスターの中心部分、すなわち、可用性を高める対象のアプリケーション、これらのアプリケーションで必要とされるリソースのタイプ、ノードの数、共用 IP アドレス、およびディスク共用のモード (非コンカレント・アクセスまたはコンカレント・アクセス) について計画します。このステップの目標は、クラスター設計の開始点となる、システムの概要を策定することです。これらの初期決定を行った後、それらの決定事項を『アプリケーション・ワークシート』に記録して、クラスターのダイアグラムの作成を開始します。『クラスターの初期計画』では、計画プロセスのこのステップについて説明します。


ステップ 2: クラスター・トポロジーの計画

このステップでは、クラスターとノードの名前を決定します。必要に応じて、サイト名、およびノードとサイトの従属関係についても決定します。『クラスターの初期計画』では、計画プロセスのこのステップについて説明します。

ステップ 3: クラスター・ネットワーク接続の計画

このステップでは、システム内のノード同士を接続するネットワークについて計画します。最初に、HACMP 環境内の TCP/IP ネットワークおよび Point-to-Point ネットワークに関する問題を調査します。次に、使用するネットワークを決定し、その決定内容をネットワークのワークシートに記録して、ネットワークをクラスター・ダイアグラムに追加します。『クラスター・ネットワーク接続の計画』では、計画プロセスのこのステップについて説明します。

ステップ 4: 共用ディスク・デバイスの計画

このステップでは、クラスターの共用ディスク・デバイスについて計画します。クラスターで使用するディスク・ストレージ・テクノロジーを決定し、HACMP 環境における問題点を調査します。ディスク・ワークシートに情報を記入し、ダイアグラムに共用ディスク構成を追加します。『共用ディスクおよびテープ・デバイスの計画』では、計画プロセスのこのステップについて説明します。

また、非コンカレント・リソース・グループにおいて、拡張コンカレント・モード・ボリューム・グループを使用するかどうかについても決定します。HACMP では、これらのボリューム・グループに対して、より高速なディスク・テークオーバー・メカニズムを使用します。詳しくは、『共用 LVM コンポーネントの計画』を参照してください。

ステップ 5: 共用 LVM コンポーネントの計画

このステップでは、クラスターの共用ボリューム・グループについて計画します。最初に、HACMP 環境における LVM コンポーネントに関する問題点を調査し、次に物理ストレージと論理ストレージを記述するワークシートに必要事項を記入します。このステップで、サイト間 LVM ミラーリングによる災害復旧の計画を盛り込むことをお勧めします。『共用 LVM コンポーネントの計画』では、計画プロセスのこのステップについて説明します。

ステップ 6: リソース・グループの計画

リソース・グループの計画では、これまでの各ステップで作成したすべての情報をまとめます。さらに、同じノード、別のノード、または同じサイト上のある特定の関連リソース・グループを維持する上で、従属リソース・グループまたは特定のランタイム・ポリシーのどちらを使用するのかを決定する必要があります。『リソース・グループの計画』では、計画プロセスのこの作業について説明します。

ステップ 7: クラスター・イベント処理の計画

このステップでは、クラスターのイベント処理について計画します。『クラスター・イベントの計画』では、計画プロセスのこのステップについて説明します。

ステップ 8: HACMP クライアントの計画

このステップでは、HACMP クライアントに関する問題点を調査します。『HACMP クライアントの計画』では、計画プロセスのこのステップについて説明します。

関連資料:

計画 5

『クラスターの初期計画』このトピックでは、アプリケーションの可用性を高めるように HACMP クラスターを計画する際の初期ステップについて説明します。このステップには、初期プランニング・ワークシートの記入も含まれます。

220ページの『アプリケーション・ワークシート』このワークシートは、クラスター内のアプリケーションに関する情報を記録するために使用します。

28ページの『クラスター・ネットワーク接続の計画』このトピックでは、HACMP クラスターのネットワーク・サポートの計画方法について説明します。

123ページの『リソース・グループの計画』本トピックでは、HACMP クラスター内のリソース・グループの計画方法を説明します。

96ページの『共用 LVM コンポーネントの計画』このトピックでは、HACMP クラスター用の共用ボリューム・グループの計画方法について説明します。

73ページの『共用ディスクおよびテープ・デバイスの計画』この章では、HACMP クラスター内に共用外部ディスクを構成する前に考慮すべき事項について説明します。また、磁気テープ・ドライブをクラスター・リソースとして使用する場合の計画と構成についても説明します。

154ページの『クラスター・イベントの計画』このトピックでは、HACMP クラスター・イベントについて説明します。

177ページの『HACMP クライアントの計画』このトピックでは、HACMP クライアントの計画の考慮事項について説明します。これは、HACMP ソフトウェアのインストールに先行する最後のステップです。

関連情報:

クラスター・イベント時のリソース・グループの動作

クラスターの初期計画このトピックでは、アプリケーションの可用性を高めるように HACMP クラスターを計画する際の初期ステップについて説明します。このステップには、初期プランニング・ワークシートの記入も含まれます。

前提条件

HACMP 計画を開始する前に、HACMP に関する概念および用語を理解しておいてください。

関連情報:

概念および機能のガイド

概説HACMP クラスターは、基幹アプリケーションのための高可用性環境を実現します。多くの企業では、基幹アプリケーションを常時使用可能にしておく必要があります。例えば、HACMP クラスターで、クライアント・アプリケーションにサービスを提供するデータベース・サーバー・プログラムを実行することにより、このサーバー・プログラムにクエリーを送信するクライアントに対して、このプログラムの高い可用性を維持できます。

効果的なクラスターを作成するには、『プランニング・ワークシート』で提供されているプランニング・ワークシートに必要な情報を記入します。このワークシートを使用すれば、必要なコンポーネントをクラスターに設定でき、また今後の参照資料としても活用できます。


クラスター計画プロセスでは、オンライン・プランニング・ワークシート・アプリケーションを使用して構成データを入力し、このデータをクラスター定義ファイルに保存できます。計画プロセスの最後の段階で、クラスター定義ファイルを使用して、即座にクラスターを構成できます。

関連概念:


関連資料:

179ページの『オンライン・プランニング・ワークシートの使用』本トピックでは、オンライン・プランニング・ワークシート (OLPW) アプリケーションを使用して、クラスター定義ファイル (ワークシート・ファイルとも呼ばれる) を作成する方法について説明します。本トピックではまた、クラスター定義ファイルと、ファイルを使用して既存の HACMP クラスターを定義する方法について説明します。

クラスター・ノードの計画基幹アプリケーションごとに、そのアプリケーションで必要なリソース (処理要件やデータ・ストレージ要件など) に注意する必要があります。

例えば、クラスターのサイズを計画する場合には、1 つのノードに障害が発生してもアプリケーションの処理要件に対応できるだけの数のノードを用意します。

最高 32 のノードを含む HACMP クラスターを作成できます。このタスクには、クラスター・サイト・ワークシートが役に立ちます。

クラスター・ノードの数を決定する際には、次の考慮事項に留意してください。

v HACMP クラスターは、IBM System p® ワークステーション、System i® LPAR、ブレード・システム、および LPAR を任意に組み合わせて構成できます。すべてのクラスター・ノードにおいて、Single Point

of Failure となる可能性のあるコンポーネント (電源装置など) を共用しないようにしてください。同様に、単一のラックに複数のノードを配置しないようにしてください。

v 類似した機能を実行するノード、またはリソースを共用するノードで構成される小さなクラスターをいくつか作成します。クラスターの規模を小さく単純にすることで、クラスターの設計、インプリメント、および保守が容易になります。

v パフォーマンス上の理由から、複数のノードで同じアプリケーションをサポートすることが望ましい場合もあります。相互テークオーバー・サービスを提供するためには、アプリケーションの複数のインスタンスを同一ノードで実行できるようにアプリケーションを設計する必要があります。

例えば、アプリケーションで動的データを /data というディレクトリーに格納する必要がある場合、そのアプリケーションは同一プロセッサー上で複数のインスタンスをサポートできない可能性があります。このような (非コンカレント環境で実行される) アプリケーションについては、複数のアプリケーション・インスタンスを実行し、それぞれのインスタンスが固有のデータベースにアクセスするように、データを区画に分割します。

また、アプリケーションがサポートする構成ファイルにおいて、管理者がアプリケーションの instance1

の動的データを data1 ディレクトリー、instance2 のデータを data2 ディレクトリー (以下、同様) に格納するように指定できる場合、アプリケーションの複数インスタンスがサポートされます。

計画 7

v ある種の構成においては、クラスター設計にノードを追加することにより、そのクラスターによって提供される可用性のレベルが高まり、ノードのフォールオーバーや再統合を計画する際の柔軟性も高まるものもあります。

最も信頼性の高いクラスター・ノード構成は、1 つ以上のスタンバイ・ノードが含まれているものです。

v 冗長ネットワーク・インターフェース・カードおよび冗長ディスク・アダプターをサポートするための十分な入出力スロットのあるクラスター・ノードを選択してください。

複数のノードで構成されたクラスターは単一ノードの場合より高価ですが、冗長ハードウェア (ネットワーク・アダプターやディスク・アダプター用の十分な入出力スロットなど) をサポートするよう計画しない限り、クラスターの可用性は向上しないという点に留意してください。

v 処理速度がほぼ同じノードを使用します。

v ピーク負荷時にも実動アプリケーションを実行できる十分な CPU サイクルと入出力帯域幅を持つノードを使用してください。ノードが、HACMP を動作させることのできる十分な能力を有している必要がある点に留意してください。

このように計画するには、ご使用の実動アプリケーションのベンチマーク試験またはモデル化を行って、予想される最大の負荷のパラメーターをリストします。次に、実動アプリケーションの実行時にビジー率が 85% を超えないものを、HACMP クラスターのノードとして選択します。

クラスターを作成するときに、クラスターに名前を割り当てます。この名前は、HACMP が割り当てるクラスター ID に関連付けられます。

関連資料:

230ページの『クラスター・サイト・ワークシート』このワークシートは、計画済みのクラスターのサイトを記録するために使用します。

クラスター・サイトの計画通常、クラスター構成で使用されるサイトは 1 つですが、クラスター構成には複数のサイトを含めることができます。

HACMP 以外のサイトが複数ある場合は、災害復旧のために次の HACMP/XD 機能のいずれかを使用します。

v HACMP/XD for AIX for Metro Mirror

v HACMP/XD for AIX for GLVM

サイト間 LVM ミラーリングを使用する場合は、サイトについても計画します。

クラスター構成プロセスの一環として、サイトを構成します。

リソースおよびサイト・ポリシーの計画HACMP では、リソース・グループの 1 次インスタンスを一方のサイトでオンライン状態に維持し、2 次インスタンスをもう一方のサイトでオンライン状態に維持するようにします。どのノードをどのサイトで構成するのか、およびどこでアクティブ・アプリケーションを実行するかを計画してください。これらを計画することにより、その内容に応じてリソース・グループ・ポリシーを計画できます。

サイトを使用する構成でリソース・グループを計画する方法について詳しくは、セクション『サイトを持つクラスター内のリソース・グループの計画』を参照してください。


HACMP に定義されるすべてのリソースは、SMIT で必須であるように、固有の名前を持つ必要があります。サービス IP ラベル、ボリューム・グループ、およびリソース・グループの名前は、クラスター内で一意であるととともに、相互に異なる必要があります。リソース名は、そのリソースがサービスを提供するアプリケーションや、対応するデバイスに関連した名前 (websphere_service_address など) にしてください。

関連資料:

139ページの『サイトを持つクラスター内のリソース・グループの計画』リソース・グループの始動動作、フォールオーバー動作、フォールバック動作は、選択したサイト間管理ポリシーと、ノードの始動、フォールオーバー、フォールバックの各ポリシーの組み合わせによって決まります。

関連情報:

管理ガイド

HACMP/XD for GLVM のミラーリングの概要High Availability Cluster Multi-Processing Extended Distance (HACMP/XD) for Geographic Logical Volume

Manager (GLVM) は、地理的に離れたサイト間でのデータの災害復旧機能およびデータ・ミラーリング機能を備えています。リモート・ミラーリングによってサイト全体での障害からデータを保護し、また参加サイト間の無制限の距離をサポートします。

HACMP/XD for GLVM は、計画的または予期しないハードウェアまたはソフトウェア (あるいはその両方) の停止時に、IP ベース・ネットワークを介し、無制限の距離間で、ミラーリングされたボリューム・グループに順次アクセスする 2 サイト・クラスターにサービスを継続的に提供することによって、データの可用性を向上させます。

HACMP/XD for GLVM は、次の 2 つの主な機能を提供します。

v リモート・データ・ミラーリング。 HACMP/XD for GLVM は、アプリケーションがローカル・サイトおよびリモート・サイトの両方でアクセスできるデータのリモート・ミラー・コピーを作成します。

このソフトウェアは、アプリケーションが入出力要求を送信する非コンカレント・ボリューム・グループをミラーリングすることによって、重要なデータを保護します。ローカル・サイトとリモート・サイトのいずれでアプリケーションが実行されているかどうかにかかわらず、アプリケーションは同じデータにアクセスできます。

データ・ミラーリング機能は、AIX 論理ボリューム・マネージャーのミラーリング機能を、HACMP/XD

for GLVM ソフトウェアの Geographic Logical Volume Manager のミラーリング機能とともに使用します。

v HACMP との統合。 HACMP との統合により、HACMP/XD for GLVM は、災害発生時でも基幹システムおよびアプリケーションを作動可能な状態に維持します。HACMP/XD for GLVM は、アプリケーションを含むリソース・グループのフォールオーバーおよびフォールバックを管理します。

ノード、ネットワーク・インターフェース、またはサイトで障害が発生した場合、HACMP/XD for

GLVM はリソース・グループを別のノードへ移動します。ノードは、同じサイトまたはリモートのサイトのいずれかに属します。この操作を行うと、ボリューム・グループのデータの完全な最新コピーを、アプリケーションが同一サイトまたは別のサイトのノード上で引き続き使用できます。

アプリケーションをリモート・サイトに移動すると、HACMP/XD for GLVM はデータのミラーリングを続行します。

関連情報:

Geographic LVM プランニングおよび管理

計画 9

HACMP/XD for Metro Mirror の概要IBM HACMP/XD for Metro Mirror を使用すると、災害復旧に備えるためにピアツーピア・リモート・コピー (PPRC) を使用してリモート・サイトにデータをコピーする IBM TotalStorage Enterprise Storage Server®

(ESS) ボリューム、DS600 ボリューム、および DS8000 ボリュームのデータ可用性が向上します。HACMP/XD for Metro Mirror は、PPRC のフォールオーバー/フォールバック機能と HACMP クラスター管理を利用して、災害復旧時のダウン時間と復旧時間を短縮します。

HACMP/XD Metro Mirror for SVC は、完全に自動化された高可用性の災害復旧管理ソリューションを提供します。このソリューションでは、SAN Volume Controller の機能を利用して、さまざまなディスク・サブシステムから派生した仮想ディスクが提供されます。HACMP インターフェースは、基本 SVC 環境が構成されると PPRC 関係が自動的に作成されるように設計されています。このため、SVC インターフェースへの追加のアクセスは不要です。

関連情報:

PPRC プランニングおよび管理

サイト間 LVM 概説サイト間 LVM ミラーリングは、災害復旧に備え、各サイトでディスク・サブシステム間のデータを複製します。2 つの異なるサイトに配置されているディスクをリモート・ミラーリング用にセットアップできます。

Storage Area Network (SAN) は、ファイバー・チャネルでサポートされる距離内で、ストレージ・デバイスとプロセッサー (サーバー) 間の直接接続を確立できる高速ネットワークです。したがって、異なるサイトに配置された 2 つ以上のサーバー (ノード) が、共通の SAN を介して、複数の同じ物理ディスクにアクセスできます。これらのサーバーも、同様に一定の距離まで離すことができます。

これらのリモート・ディスクは、AIX Logical Volume Manager を介してボリューム・グループに結合できます。このボリューム・グループは、異なるサイトに配置されたノードにインポートできます。このボリューム・グループの論理ボリュームには、最大で 3 つのミラーを設定できます。各サイトでミラーをセットアップできます。この論理ボリュームに格納される情報については、高可用性が維持されます。何らかの障害が発生しても、もう一方のサイトのリモート・ミラーに最新情報が保存されているため、一方のサイトで操作を継続できます。

HACMP は、ディスクまたはノードの障害が発生し、その後に再統合が実行されてから、ミラーを自動的に同期化します。HACMP は、ディスクのいずれかが PVREMOVED または PVMISSING 状態であっても、自動的にミラーを同期化します。自動同期化はすべてのケースで実行できるとは限りませんが、ディスクまたはサイトで障害が発生し、それに伴う再統合が行われた後で、C-SPOC を使用して、障害の発生していないミラーから不整合な状態のミラーにデータを同期化できます。

クラスター・サイト・ワークシートの記入サイト間 LVM ミラーリングまたはいずれかの HACMP/XD コンポーネントを使用する場合は、HACMP

サイトを使用します。

HACMP サイトは、クラスター・サイト・ワークシートを使用して計画します。関連サイト情報については、『リソース・グループ・ワークシート』を参照してください。

クラスター・サイト・ワークシートに記入するには、次の手順を実行します。

1. サイト名を記録します。32 文字以内の英数字と下線を使用してください。


2. 「Cluster Nodes in Site (サイトのクラスター・ノード)」リストに、サイトに属するクラスター・ノードの名前を記録します。各ノードの名前は、HACMP クラスターに定義する名前と同じにする必要があります。1 つのノードは、1 つのサイトにしか所属できません。

HACMP/XD for GLVM または HACMP/XD for Metro Mirror 用に構成されたサイトでは、1 つのクラスターに、HACMP でサポートされているのと同じ数のノードを含めることができます。

3. サイト・バックアップの通信方法を選択し、「Site Backup Communication Method (サイト・バックアップの通信方式)」フィールドに記録します(使用する HACMP/XD コンポーネントの資料を参照してください)。

4. サイト間管理ポリシーをリソース・グループ・ワークシートに記録します。デフォルトは「Ignore (無視)」です。「Online on Either Site (一方のサイトでオンライン)」、「Online on Both Sites (両方のサイトでオンライン)」、または「Prefer Primary Site (1 次サイトを選択)」も選択できます。

関連資料:


230ページの『クラスター・サイト・ワークシート』このワークシートは、計画済みのクラスターのサイトを記録するために使用します。

227ページの『リソース・グループ・ワークシート』このワークシートは、クラスターのリソース・グループを記録するために使用します。

クラスター・セキュリティーの計画HACMP にはクラスター・セキュリティーが備わっていて、HACMP へのユーザー・アクセスが制御され、ノード間通信にセキュリティーが使用されます。

ユーザー・アカウント・セキュリティーの管理

ユーザー・アカウント・セキュリティーを管理することは、クラスター・セキュリティーを計画するときの重要なステップです。

接続認証

HACMP には、クラスター・ノード間の HACMP 通信を保護する接続認証が用意されています。これは、標準認証と呼ばれます。標準認証には、IP アドレスによる確認接続が含まれ、root 権限で実行可能なコマンドを制限します。このモードでは、リモート・コマンドの実行に対して最小権限の原則が採用され、root

権限が設定されているリモート・ノード上で、コマンドを任意に実行できないようにします。選択したHACMP コマンドのセットだけがトラステッドと解釈され、root として実行できます。その他のコマンドは、nobody ユーザーとして実行されます。ノード間通信の /.rhosts 依存関係は除去されました。

ノード間通信用に仮想プライベート・ネットワーク (VPN) を構成することもできます。VPN を使用する場合は、VPN トンネルに永続ラベルを使用します。

メッセージの認証と暗号化

HACMP は、クラスター・ノード間で送信される HACMP メッセージを次のようにセキュリティーで保護します。

v メッセージ認証により、メッセージの起点と完全性が保証されます。

v メッセージの暗号化によって、メッセージ送信時にデータの形式を変更し、メッセージを認証するノードで受信時に元の形式に戻します。

計画 11

HACMP では、メッセージの認証および暗号化において、次のタイプの暗号キーがサポートされています。

v データ暗号化規格 (DES) を使用するメッセージ・ダイジェスト 5(MD5)

v トリプル DES を使用する MD5

v Advanced Encryption Standard (AES) を使用する MD5

組織で採用されているセキュリティー手法と互換性のある暗号化アルゴリズムを選択してください。

アプリケーションの計画アプリケーションの計画を開始する前に、アプリケーション用のデータ・リソース、およびクラスター内でのこれらのリソースの場所について十分に理解しておく必要があります。これにより、ノードに障害が発生しても、データ・リソースを正しく処理できるソリューションを提供できます。

障害発生を防止するには、シングルノード環境およびマルチノード環境におけるアプリケーションの動作を十分に理解しておく必要があります。悪条件下でのアプリケーションのパフォーマンスについては想定しないでください。

ピーク負荷時にも実動アプリケーションを実行できる十分な CPU サイクルと入出力帯域幅を持つノードを使用してください。ノードが、HACMP を動作させることのできる十分な能力を有している必要がある点に留意してください。

このように計画するには、ご使用の実動アプリケーションのベンチマーク試験またはモデル化を行って、予想される最大の負荷のパラメーターをリストします。次に、実動アプリケーションの実行時にビジー率が85% を超えないものを、HACMP クラスターのノードとして選択します。

1 つのアプリケーションに対して複数のアプリケーション・モニターを構成し、HACMP に対して次の両方を指示することをお勧めします。

v プロセスの終了や、アプリケーションに影響を与えているより微妙な問題をモニターする。

v 自動的にアプリケーションを再始動し、再始動が失敗した場合は適切なアクション (通知やフォールオーバー) を実行する。

このセクションでは、アプリケーションに関するすべての重要情報をアプリケーション・ワークシートに記録してクラスター・ダイアグラムの作図を開始する方法について説明します。

以下のガイドラインに従い、HACMP クラスター環境においてアプリケーションへのサービス提供が適切に行われるようにしてください。

v アプリケーションとそのデータを配置し、共用外部ディスクにはデータだけが格納されるようにします。このように配置することで、ソフトウェア・ライセンス違反を防止できるだけでなく、障害復旧も簡素化されます。

v クラスターの親/子従属リソース・グループに多層アプリケーションを含める予定の場合は、セクション『多層アプリケーションの計画に関する注意事項』を参照してください。同じノード、または異なるノード上で特定のアプリケーションを保持するために、ロケーション依存関係を使用する予定の場合は、セクション『リソース・グループ依存関係』を参照してください。

v クラスター・ノードでアプリケーションの起動と停止を行うための、堅牢なスクリプトを作成します。特に起動スクリプトは、電源障害などによる異常終了からアプリケーションを回復できるものでなければなりません。HACMP ソフトウェアを組み込む前に、スクリプトがシングル・ノード環境で正しく動作することを確認します。開始リソースおよび停止リソースをアプリケーション・ワークシートとアプリケーション・サーバー・ワークシートの両方に必ず含めます。


v アプリケーション・ライセンスの要件を確認します。一部のベンダーは、アプリケーションを実行するプロセッサーごとに固有のライセンスを取得することを義務付けています。したがって、アプリケーションのインストール時にプロセッサー固有情報をアプリケーションへ組み込むことによって、アプリケーションをライセンス保護する必要があります。その結果、クラスター内で使用できる当該アプリケーションのライセンス数が制限されるため、HACMP ソフトウェアがノード障害を正しく処理してもフォールオーバー・ノード上のアプリケーションを再始動できない場合があります。この問題を回避するために、アプリケーションを実行する可能性のあるクラスター内のシステム・ユニットごとに、ライセンスを取得しておきます。

v アプリケーションがシングル・ノード環境で正常に実行されるかどうかを確認します。クラスターでのアプリケーションのデバッグは、シングル・プロセッサー上でのデバッグよりも困難です。

v コンカレント・アクセスを必要とする場合は、アプリケーションが独自のロック機構を使用していることを確認します。

関連資料:


224ページの『アプリケーション・サーバー・ワークシート』このワークシートは、クラスター内のアプリケーション・サーバーに関する情報を記録するために使用します。

15ページの『多層アプリケーションの計画に関する注意事項』多層アプリケーションを使用するビジネス構成では、親/子従属リソース・グループを利用できます。例えば、データベースは、アプリケーション・サーバーより先にオンラインにする必要があります。このケースでは、データベースが停止して別のノードに移行した場合、アプリケーション・サーバーを含むリソース・グループを停止して、クラスターの任意のノードでバックアップする必要があります。

130ページの『リソース・グループ依存関係』HACMP には、始動時、フォールオーバー時、フォールバック時に維持したいリソース・グループ間の関係を指定できるさまざまな構成があります。

キャパシティー・アップグレード・オンデマンドの計画キャパシティー・アップグレード・オンデマンド (CUoD) はいくつかの System p IBM サーバーでのDLPAR (動的論理区画) の機能の 1 つです。この機能を使用して、プリインストールされているがまだ活動化していない (未購入) プロセッサーを、リソース要件の変更に応じて活動化できます。

追加の CPU およびメモリーは物理的には存在しますが、必要な追加容量の購入をユーザーが決定するまでは使用されません。この機能を使用することで、迅速かつ容易に容量をアップグレードして、ピーク時や予期せぬ負荷に対応できます。

HACMP は、DLPAR 機能および CUoD 機能と統合します。最小のリソースを割り当てられた論理区画がスタンバイ・ノードとして機能し、スタンバイ・ノードよりも多くのリソースを持つ別の LPAR ノード上にアプリケーションが存在するよう、クラスター・リソースを構成できます。

スタンバイ・ノードでアプリケーションを実行する必要がある場合、HACMP はスタンバイ・ノードがアプリケーションを正常に実行するのに十分なリソースを持っているかを確認し、必要なリソースを割り当てます。リソースは次の 2 つのソースから割り当てることができます。

v 空きプール。DLPAR 機能は、フレーム上の空きプール内の使用可能なリソースを割り当てることにより、スタンバイ・ノードにリソースを提供します。

計画 13

v CUoD プロビジョン・リソースアプリケーションで追加のメモリーまたは CPU が必要となった際に、DLPAR が割り当てに使用できる十分な量のリソースが空きプール内にない場合は、CUoD 機能によって追加リソースがスタンバイ・ノードに提供されます。

DLPAR および CUoD により提供されるリソースを使用するように HACMP を構成した場合、クラスター内の LPAR ノードは、アプリケーションがリソースを必要とするまで、いかなる追加リソースも使用しません。

HACMP は、各ノードが、最小限のコストかつ適正なパフォーマンスでアプリケーションを確実にサポートできるようにします。このように、ご使用のアプリケーションにさらにリソースが必要になったときに論理区画の容量をアップグレードできるため、実際に必要になるまでは使用されていない容量に対してコストを支払う必要はありません。

注: DLPAR 機能は専用 LPAR の場合のみサポートされ、共有 LPAR の場合はサポートされません。

関連情報:

管理ガイド

アプリケーション・サーバーアプリケーションを HACMP で管理するには、ユーザー定義名と、アプリケーションの起動および停止のために特別に作成されたスクリプトの名前を関連付けるアプリケーション・サーバー・リソースを作成します。アプリケーション・サーバーを定義することにより、HACMP はフォールオーバー発生時に、テークオーバー・ノードでアプリケーションの別のインスタンスを起動できます。これにより、アプリケーションは、単一障害点にならないように保護されます。

アプリケーション・サーバーは、アプリケーション・モニター機能および Application Availability Analysis

ツールでモニターすることもできます。

定義したアプリケーション・サーバーは、リソース・グループに追加できます。リソース・グループは、HACMP ソフトウェアで 1 つの単位として処理できるように定義された、リソースのセットです。

関連資料:


HACMP に統合されたアプリケーションFast Connect サービスやワークロード・マネージャーなどの特定のアプリケーションは、アプリケーション・サーバーや追加スクリプトがなくても、高可用性リソースとして直接構成できます。さらに、HACMP

クラスター検証で、Fast Connect サービスおよびワークロード・マネージャーの構成の正確性と整合性を検証できます。

HACMP Smart Assist プログラム

HACMP では、これらのアプリケーションを HACMP クラスターに簡単に統合するための、次の 3 つのHACMP Smart Assist アプリケーションが用意されています。

v Smart Assist for WebSphere® 既存の HACMP 構成を拡張して、さまざまな WebSphere コンポーネントのモニターおよび回復のサポートを追加します。

v Smart Assist for DB2® 既存の HACMP 構成を拡張して、DB2 Universal Database™ (UDB) Enterprise

Server Edition のモニターおよび回復のサポートを追加します。

v Smart Assist for Oracle。 Oracle Application Server 10g (9.0.4) (AS10g) Cold Failover Cluster (CFC) ソリューションの IBM AIX (5200) オペレーティング・システムへのインストールを支援します。


HACMP Smart Assist についての詳細は、『資料へのアクセス』のセクションを参照してください。

アプリケーション・モニターHACMP では、アプリケーション・サーバーに定義されたアプリケーションをモニターできます。

HACMP では、次の 2 つの方法のいずれかで実行できます。

v プロセス・モニター。RSCT Resource Monitoring and Control (RMC) 機能を使用して、プロセスの終了を検出します。

v ユーザー定義モニター。定義したモニター・メソッドを使用して、アプリケーションの正常性をモニターします。

複数のアプリケーション・モニターを構成して、1 つ以上のアプリケーション・サーバーに関連付けることができます。SMIT で、各モニターに固有の名前を割り当てることができます。HACMP では、アプリケーションごとに複数のモニターをサポートすることで、より複雑な構成をサポートできます。例えば、使用中の Oracle 並列サーバーのインスタンスごとに、1 つのモニターを構成できます。または、データベース・プロセスの終了を即時に検出するプロセス終了モニターとともに、データベースの正常性をチェックするユーザー定義モニターを構成できます。

Application Availability Analysis ツールを使用すると、HACMP に定義されたアプリケーションが使用可能である合計時間を正確に測定できます。HACMP ソフトウェアは次の情報を収集し、タイム・スタンプを取り、ログに記録します。

v アプリケーション・モニターの定義、変更、削除

v アプリケーションの起動、停止、障害

v ノードの障害、シャットダウン、起動

v リソース・グループのオフライン化、移動

v 複数モニターによるアプリケーション・モニターの一時停止、再開

関連情報:

HACMP クラスター・トポロジーとリソースの構成 (拡張)

HACMP クラスターのモニター

多層アプリケーションの計画に関する注意事項多層アプリケーションを使用するビジネス構成では、親/子従属リソース・グループを利用できます。例えば、データベースは、アプリケーション・サーバーより先にオンラインにする必要があります。このケースでは、データベースが停止して別のノードに移行した場合、アプリケーション・サーバーを含むリソース・グループを停止して、クラスターの任意のノードでバックアップする必要があります。

SAP などの環境では、データベースに障害が発生した場合は常に、アプリケーションを一度停止してから再始動する必要があります。SAP などの環境では多数のアプリケーション・サービスが提供されるため、多くの場合、個々のアプリケーション・コンポーネントを特定の順序で管理する必要があります。

アプリケーション環境をサポートするためにシステム・サービスが必要な場合は、リソース・グループ間の相互依存性を確立しておくと便利です。ログ・ファイルを整理したりバックアップを開始したりするためのcron ジョブなどのサービスは、アプリケーションと一緒にノード間を移動する必要がありますが、これらのサービスは通常、そのアプリケーションが確立されるまでは開始されません。これらのサービスは、アプリケーション・サーバーの起動スクリプトおよび停止スクリプトに組み込むことができ、イベント前処理お

計画 15

よびイベント後処理を通じて管理できます。ただし、従属リソース・グループを使用すれば、リソース・グループが使用されるアプリケーションに依存するようにシステム・サービスを構成する方法を簡素化できます。

注: アプリケーションの停止および再起動プロセスにおけるデータ損失の可能性を最小限にするには、アプリケーション・サーバー・スクリプトをカスタマイズして、アプリケーションの停止プロセス時は、コミットされていないデータを共用ディスクに一時的に格納し、アプリケーションの再起動プロセス時にアプリケーションに読み込み直すようにします。アプリケーションは停止したノードとは別のノード上で再始動される場合があるため、共用ディスクを使用することが重要です。

特定のリソース・グループが、同じサイトの同じノード上、または始動、フォールオーバー、およびフォールバック時に異なるノード上でオンラインのまま維持されるよう、ロケーション依存関係を使用してリソース・グループを構成することもできます。リソース・グループ間のロケーション依存関係については、『リソース・グループの計画』を参照してください。

このコマンドはコピー処理を行います。

関連資料:


アプリケーションとアプリケーション・サーバーの計画このセクションには、アプリケーションおよびアプリケーション・サーバーの計画に関するトピックが含まれています。

アプリケーション・ワークシートの記入アプリケーション・ワークシートは、クラスター内のアプリケーションに関する情報を記録するために使用します。

アプリケーション・ワークシートを印刷し、このセクションの情報を使用して内容を記入します。クラスター内で高可用性を維持する必要があるアプリケーションごとに、コピーを印刷します。

アプリケーション・ワークシートを記入するには、以下の手順を実行します。

1. アプリケーションに名前を割り当て、「Application Name (アプリケーション名)」フィールドに記録します。

2. アプリケーションの実行可能ファイルと構成ファイルに関する情報を「Directory/Path (ディレクトリー/パス)」、「File System (ファイルシステム)」、「Location (ロケーション)」、および「Sharingcolumns (列の共用)」に入力します。各ファイルの絶対パス名を記入してください。実行可能ファイルと構成ファイルのファイルシステムは、内部ディスク・デバイスまたは外部ディスク・デバイスのいずれかに格納できます。状況によっては、どちらのデバイスに格納するかを指定する必要があります。ファイルシステムを内部デバイスに格納した場合、リソース・テークオーバー時に他のノードからはそのデバイスにアクセスできなくなります。

3. アプリケーションのデータ・ファイルおよびログ・ファイルの情報を、ステップ 2 で説明した該当する欄に入力します。データ・ファイルとログ・ファイルは、ファイルシステム (または論理デバイス) に格納できますが、リソース・テークオーバーを正常に実行するためには、外部デバイスに格納する必要があります。

4. 「Normal Start Command/Procedures (通常の始動コマンドおよび手順)」フィールドに、リソース・テークオーバー後にアプリケーションを起動するために作成した起動スクリプトの名前を入力します。


5. 「Verification Commands/Procedures (検証コマンドおよび手順)」フィールドに、通常の起動スクリプトが正常に実行されたことを検証するために使用されるコマンドまたは手順の名前を入力します。

関連資料:


アプリケーション・サーバー・ワークシートの記入アプリケーション・サーバー・ワークシートは、クラスター内のアプリケーション・サーバーに関する情報を記録するために使用します。

アプリケーション・サーバー・ワークシートを印刷し、このセクションの情報を使用して内容を記入します。クラスター内のアプリケーションごとに、シートを 1 部ずつ印刷します。

アプリケーション・サーバー・ワークシートを記入するには、以下の手順を実行します。

「Cluster Name (クラスター名)」フィールドにクラスター名を入力します。クラスター名は、ワークシートの記入中に決定します。定義する各アプリケーション・サーバーについて、以下のフィールドにデータを記入します。

v アプリケーションの名前を割り当て、「Application (アプリケーション)」フィールドにこの名前を記録します。

v サーバーを識別するシンボル名を割り当て、「Server Name (サーバー名)」フィールドに記録します。例えば、カスタマー・データベース・アプリケーションのアプリケーション・サーバーには、custdata という名前を付けます。名前は最大 64 文字で、使用できる文字は英数字と下線 (_) のみです。「StartScript (起動スクリプト)」フィールドに、アプリケーション・サーバーを起動するユーザー定義スクリプトの絶対パス名を記録します(最大 256 文字です)。この情報は、アプリケーション・ワークシートに記録されています。必要な場合は、スクリプトの引数を指定します。このスクリプトは、クラスター・イベント・スクリプトによって呼び出されます。例えば、起動スクリプトに名前を付け、custdata アプリケーション・サーバーを起動する引数を指定する場合は、次のように入力します。

/usr/start_custdata -d mydir -a jim_svc

-d オプションは、イメージを格納するディレクトリーの名前を指定します。-a オプションは、デモを実行するサーバーのサービス IP アドレス (ラベル) を指定します。

v 「Stop Script (停止スクリプト)」フィールドに、アプリケーションを停止するユーザー定義スクリプトの絶対パス名を記録します (最大 256 文字です)。このスクリプトはクラスター・イベント・スクリプトにより呼び出されます。例えば、custdata アプリケーション・サーバーの停止スクリプトに、/usr/stop_custdata という名前を付けます。

関連資料:


224ページの『アプリケーション・サーバー・ワークシート』このワークシートは、クラスター内のアプリケーション・サーバーに関する情報を記録するために使用します。

アプリケーション・モニター・ワークシートの記入このセクションでは、アプリケーション・モニター・プロセス・ワークシートおよびアプリケーション・モニター・カスタム・ワークシートの記入方法について説明します。

計画 17

HACMP のアプリケーション・モニターを使用すると、HACMP がアプリケーションを再始動します。システム・リソース・コントローラー (SRC) では、アプリケーションを再始動できません。

モニター対象のアプリケーションが SRC によって制御されている場合、action:multi が次のように設定されていることを確認します。

項目説明

-O サブシステムが異常終了した場合に再始動されないように指定します。

-Q サブシステムの複数のインスタンスを同時に実行することを許可しないよう指定します。

これらの設定を確認するには、次のコマンドを使用します。

lssrc -Ss Subsystem | cut -d : -f 10,11

値が -O でも -Q でもない場合、chssys コマンドで値を変更します。

アプリケーション・モニター (プロセス) ワークシートの記入:

アプリケーション・モニター (プロセス) ワークシートは、アプリケーションに対するプロセス・モニターの構成についての情報を記録するために使用します。

アプリケーション・モニター・ワークシート (プロセス・モニター) を印刷し、このセクションの情報を使用して内容を記入します。必要な枚数のシートを印刷します。複数のアプリケーション・モニターを構成して、1 つ以上のアプリケーション・サーバーに関連付けることができます。SMIT で、各モニターに固有の名前を割り当てることができます。

アプリケーション・モニター (プロセス) ワークシートを記入するには、以下の手順を実行します。

1. 「Cluster Name (クラスター名)」フィールドにクラスター名を入力します。

2. プロセス・モニターの構成対象となるアプリケーション・サーバー名を指定します。

3. このアプリケーションをプロセス・モニターでモニターできるかどうかを確認します。

例えば、シェル・スクリプトはモニターできません。

アプリケーションをモニターできない場合は、『アプリケーション・モニター・ワークシート (ユーザー定義モニター)』の手順に進みます。

アプリケーションをモニターできる場合は、ステップ 4 に進みます。

4. モニターする 1 つ以上のプロセスの名前を指定します。プロセス名は慎重に指定してください。アプリケーション・モニターを構成するために SMIT にプロセス名を入力する場合、プロセス名が正確であることが非常に重要です。

5. ステップ 4 で指定したプロセスの所有者のユーザー ID を指定します (例えば、root)。プロセスの所有者は、モニターするすべてのプロセスを所有している必要があります。

6. モニターするアプリケーション・インスタンスの数を指定します。デフォルトのインスタンス数は 1(1 個) です。モニターするプロセスを複数指定した場合は、この値を 1 にする必要があります。

7. モニターを開始するまでの待ち時間を (秒単位で) 指定します。例えば、データベース・アプリケーションの場合は、起動スクリプトと初期データベース検索の完了を待ってからモニターを開始できます。パフォーマンスと信頼性のバランスを取るために、この値のテストが必要な場合もあります。ほとんどの場合、この値は 0 にしないでください。


アプリケーション・モニターを開始する前に HACMP とユーザー・アプリケーションが停止するまでの時間を見込んで、少なくとも 2 秒から 3 秒と指定することを推奨します。

8. 再始動カウントを指定します。これは、他のアクションを実行する前にアプリケーションの再始動を試みる回数です。デフォルトは 3 です。「Restart Count (再始動カウント)」の値が 0 以外の場合は、「Restart Method (再始動メソッド)」を入力してください (ステップ 13 参照)。

9. 再始動カウントをリセットするまでにアプリケーションの安定状態が継続する間隔を (秒単位で) 指定します。一定期間に障害が何度も発生する場合、この間隔が重要になります。適切な時にカウントをゼロにリセットすると、新しい障害が以前の問題に起因する障害としてカウントされることなく、新たな問題による最初の障害としてカウントされます。

この値は、(再始動カウント)×(安定化間隔) の値よりも短く設定しないでください。デフォルトは、この値よりも 10% 長い値です。この値が短すぎると、カウントが繰り返しゼロにリセットされるため、指定した障害アクションが実行されなくなります。

10. アプリケーションを再始動カウント内で再始動できない場合に実行するアクションを指定します。デフォルト選択項目は「notify (通知)」で、クラスターに障害を通知するイベントを実行します。「fallover(フォールオーバー)」を指定することもできます。この場合は、障害の発生したアプリケーションを含むリソース・グループが、次に優先順位の高いクラスター・ノードに移されます。

アプリケーション・モニターの「fallover (フォールオーバー)」オプションを選択すると、リソース・グループが元の所有者ノードから移行され、最も優先順位の高いノードが稼働していてもリソース・グループが停止状態のままとなる可能性があります。この状況は、rg_move イベントがリソース・グループを最も優先順位の高いノードからそれより優先順位の低いノードに移動したあと、管理者がこの優先順位の低いノード上のクラスター・サービスを停止して、リソース・グループをオフライン状態にした場合に発生します。

リソース・グループを手動で開始しなければ、非アクティブ状態が続きます。

11. (オプション) アプリケーションに障害が発生した場合に実行する通知メソッドを定義します。このユーザー定義メソッド (一般的にはシェル・スクリプト) は、再始動プロセス実行時や通知アクティビティー時に実行します。

12. (オプション) アプリケーションの障害が検出されたときに、再始動メソッドを呼び出す前に実行するアプリケーションのクリーンアップ・スクリプトを指定します。デフォルトは、アプリケーション・サーバーのセットアップ時に定義するアプリケーション・サーバー停止スクリプトです。

このスクリプトが呼び出される時点でアプリケーションがすでに停止されているため、サーバー停止スクリプトが失敗する場合があります。正確な停止スクリプトの作成について詳しくは、『アプリケーションと HACMP』を参照してください。

13. (再始動カウントがゼロ以外の場合に必要) デフォルトの再始動メソッドは、アプリケーション・サーバーのセットアップ時に定義するアプリケーション・サーバー起動スクリプトです。必要な場合は、別の再始動メソッドを指定します。

関連概念:

233ページの『アプリケーションと HACMP』このトピックでは、HACMP 環境でアプリケーションの高可用性を維持するために、注意すべき主要な問題について説明します。

関連資料:

225ページの『アプリケーション・モニター・ワークシート (プロセス・モニター)』このワークシートは、アプリケーションに対するプロセス・モニターの構成についての情報を記録するために使用します。

計画 19

関連情報:


アプリケーション・モニター (ユーザー定義) ワークシートの記入:

アプリケーション・モニター (ユーザー定義) ワークシートは、アプリケーションに対するユーザー定義モニター・メソッドの構成についての情報を記録するために使用します。

アプリケーション・モニター・ワークシート (ユーザー定義モニター) を印刷し、このセクションの情報を使用して内容を記入します。ユーザー定義モニター・メソッドを設定する場合は、構成するユーザー定義アプリケーション・モニターごとに、このワークシートに情報を記入します。複数のアプリケーション・モニターを構成して、1 つ以上のアプリケーション・サーバーに関連付けることができます。SMIT で、各モニターに固有の名前を割り当てることができます。

アプリケーション・モニター・ワークシート (ユーザー定義モニター) を記入するには、以下の手順を実行します。


2. アプリケーション・サーバーの名前を入力します。

3. 指定したアプリケーションの正常性について、ユーザー定義モニターを行うスクリプトまたは実行可能ファイルを指定します。SMIT でモニターを構成する場合には、このフィールドを空欄のままにしないでください。モニター・メソッドは、アプリケーションが正常であれば値 0 を戻し、問題が検出された場合にはゼロ以外の値を戻す必要があります。モニター・メソッドの定義方法については、ステップ6 の「注」を参照してください。

4. モニター・メソッドを実行する頻度を示す、ポーリング間隔を (秒単位で) 指定します。この間隔内にモニターが応答しなかった場合、モニターは「ハングした」と解釈されます。

5. ユーザー定義モニター・メソッドがモニター間隔内で処理を終了できなかった場合に、そのモニター・メソッドを強制終了するためのシグナルを指定します。デフォルトのシグナルは kill -9 です。

6. モニターを開始するまでの待ち時間を (秒単位で) 指定します。例えば、データベース・アプリケーションの場合は、起動スクリプトと初期データベース検索の完了を待ってからモニターを開始できます。パフォーマンスと信頼性のバランスを取るために、この値のテストが必要な場合もあります。

ほとんどの場合、この値は 0 にしません。アプリケーション・モニターを開始する前に HACMP とユーザー・アプリケーションが停止するまでの時間を見込んで、少なくとも 2 秒から 3 秒と指定することを推奨します。

7. 再始動カウントを指定します。他のアクションを実行する前にアプリケーションの再始動を試みる回数です。デフォルトは 3 です。

8. 再起動カウントをリセットする前に、アプリケーションの安定状態が続かなければならない間隔を (秒単位で) 指定します。一定期間に障害が何度も発生する場合、この間隔が重要になります。適切な時にカウントをゼロにリセットすると、新しい障害が以前の問題に起因する障害としてカウントされることなく、新たな問題による最初の障害としてカウントされます。

この値は、(再始動カウント)×(安定化間隔 + モニター間隔) の値よりも短く設定しないでください。デフォルトは、この値よりも 10% 長い値です。この値が短すぎると、カウントが繰り返しゼロにリセットされるため、指定した障害アクションが実行されなくなります。

9. アプリケーションを再始動カウント内で再始動できない場合に実行するアクションを指定します。デフォルト選択項目の「notify (通知)」を使用すると、クラスターに障害を通知するイベントが実行されます。「fallover (フォールオーバー)」を選択すると、障害の発生したアプリケーションを含むリソース・グループが、次に優先順位の高いクラスター・ノードに移されます。


アプリケーション・モニターの「fallover (フォールオーバー)」オプションを選択すると、リソース・グループが元の所有者ノードから移行され、最も優先順位の高いノードが稼働していてもリソース・グループが停止状態のままとなる可能性があります。この状況は、rg_move イベントがリソース・グループを最も優先順位の高いノードからそれより優先順位の低いノードに移動したあと、管理者がこの優先順位の低いノード上のクラスター・サービスを停止して、リソース・グループをオフライン状態にした場合に発生します。

リソース・グループを手動で開始しなければ、非アクティブ状態が続きます。

10. (オプション) アプリケーションに障害が発生した場合に実行する通知メソッドを定義します。このユーザー定義メソッドは、再始動処理中と、server_down イベント中に実行されます。

11. (オプション) アプリケーションの障害が検出されたときに、再始動メソッドを呼び出す前に実行するアプリケーションのクリーンアップ・スクリプトを指定します。デフォルトは、アプリケーション・サーバーのセットアップ時に定義したアプリケーション・サーバー停止スクリプトです。

このスクリプトが呼び出される時点でアプリケーションがすでに停止されている可能性があり、サーバー停止スクリプトが失敗する場合があります。正確な停止スクリプトの作成について詳しくは、『アプリケーションと HACMP』を参照してください。

12. (再始動カウントがゼロ以外の場合に必要) デフォルトの再始動メソッドは、アプリケーション・サーバーのセットアップ時に定義するアプリケーション・サーバー起動スクリプトです。必要な場合は、別の再始動メソッドを指定します。

ユーザー定義モニター・メソッドの定義に関する注意

ユーザー定義モニター・メソッドを作成する際には、以下の点に注意してください。

v 複数のアプリケーション・モニターを構成して、1 つ以上のアプリケーション・サーバーに関連付けることができます。SMIT で、各モニターに固有の名前を割り当てることができます。

v モニター・メソッドは、アプリケーションをテストして終了し、アプリケーションの状況を示す整数値を戻す実行可能プログラムでなければなりません (シェル・スクリプトでも構いません)。戻り値は、アプリケーションが正常な場合にはゼロ、アプリケーションに障害が発生した場合はゼロ以外の値です。

v HACMP は、引数をモニター・メソッドに渡しません。

v このメソッドは、メッセージを標準出力の stdout ファイルに印刷することによりメッセージをログに記録することができます。長時間実行されるモニターの場合、出力は /var/hacmp/log/clappmond.applicationmonitor name.resource group name.monitor.log ファイルに保管されます。起動モニターの場合、この出力は /var/hacmp/log/clappmond.application server name.resource group name.monitor.log ファイルに保管されます。モニター・ログ・ファイルは、アプリケーション・モニターが実行されるたびに上書きされます。

v あまり複雑なメソッドを作成しないようにしてください。モニター・メソッドは、指定したポーリング間隔内に終了しない場合は強制終了されます。さまざまなワークロードでモニター・メソッドをテストして、ポーリング間隔の最適値を決定する必要があります。

v アプリケーションを再始動するようにシステム・リソース・コントローラー (SRC) が構成されているかどうかを確認し、適切にステップを実行します。

関連概念:


16ページの『アプリケーションとアプリケーション・サーバーの計画』このセクションには、アプリケーションおよびアプリケーション・サーバーの計画に関するトピックが含ま

計画 21

れています。

関連資料:

226ページの『アプリケーション・モニター・ワークシート (ユーザー定義モニター)』このワークシートは、アプリケーションに対するユーザー定義モニター・メソッドの構成についての情報を記録するために使用します。

関連情報:


AIX Fast Connect の計画AIX Fast Connect などの一部のアプリケーションは、すでに HACMP に統合されているため、アプリケーション・サーバーを必要としません。HACMP 環境下では、これらのアプリケーションの可用性を高めるために追加スクリプトを作成したり、アプリケーション・サーバーを作成したりする必要はありません。

AIX Fast Connect を使用すると、Windows、DOS、および OS/2 オペレーティング・システムを実行しているクライアント PC から、AIX サーバーのファイル・サービスや印刷サービスを要求できます。Fast

Connect は、NetBIOS over TCP/IP 転送プロトコルをサポートします。AIX Fast Connect リソースは、SMIT を使用して構成できます。

Fast Connect アプリケーションは、HACMP に統合されています。SMIT を使用して、Fast Connect サービスを高可用性リソースとしてリソース・グループ内に構成できます。その後、フォールオーバー、回復、および動的リソース・グループの移行が発生したとき、HACMP で Fast Connect リソースの停止と始動を行うことができます。このアプリケーションをアプリケーション・サーバーまたは特殊スクリプトに関連付ける必要はありません。

また、HACMP クラスター検証プロセスが、AIX Fast Connect 構成の正確性と整合性を検証します。

AIX Fast Connect の計画に関する注意事項HACMP でクラスター・リソースとして Fast Connect を構成することを計画する場合、さまざまな側面について計画する必要があります。

その側面とは、以下のようなものです。

v Fast Connect サーバーをクラスター内のすべてのノードにインストールします。

v Fast Connect プリント共有の可用性を高める場合は、AIX 印刷キューの名前をクラスターのすべてのノードで一致させます。

v 非コンカレント・グループについては、Fast Connect サーバーをインストールする際に、各ノードに同一の NetBIOS 名を割り当てます。

これにより、フォールオーバー後にクライアントをサーバーに接続するために必要なステップを最小限に抑えることができます。

注: 複数の NetBIOS 名のインスタンスを同時にアクティブにすることはできません。この理由から、HACMP の管理下にある複数の Fast Connect サーバーをアクティブにしないでください。

v コンカレント構成のリソース・グループの場合、ノード間で異なる NetBIOS 名を割り当てます。

v コンカレント構成では、Fast Connect ノードが利用できるファイルシステムを制御するために、非コンカレント・リソース・グループをもう 1 つ定義します。


コンカレント・クラスター内にもう 1 つのリソース・グループを構成することにより、ノード障害の場合に Fast Connect が使用する AIX ファイルシステムのクロスマウント可能性と高可用性が維持されます。

v 相互テークオーバー構成で Fast Connect を構成しないでください。

1 つのノードが同時に 2 つの Fast Connect リソース・グループに所属することはできません。

高可用性リソースとしての Fast ConnectAIX Fast Connect リソースがリソース・グループの一部として構成されている場合、HACMP は、いくつかある方法のいずれかを使用して、そのリソースを処理します。

これらの方法には、以下のものがあります。

v Fast Connect の始動と停止。 Fast Connect サーバーのリソースが HACMP に構成されている場合、HACMP はフォールオーバー、回復、およびリソース・グループの再構成時または移行時に、サーバーの始動および停止を行います。

注: クラスターの始動時には、すべてのノードで Fast Connect サーバーを停止する必要があります。これによって、HACMP が確実に Fast Connect サーバーを始動し、そのリソースを正しく処理できます。

v ノード障害。Fast Connect のリソースを所有しているノードに障害が発生した場合、それらのリソースはテークオーバー・ノードで使用できるようになります。障害ノードがクラスターに再結合すると、リソースは再び元のノードで使用できるようになります (障害ノードがリソースを再取得するリソース・ポリシーである場合)。

IP およびハードウェア・アドレス・テークオーバー (HWAT) が構成および実行され、ユーザーがすべてのノードで同じ NetBIOS 名を使用するように Fast Connect サーバーを構成している場合は、クライアントがフォールオーバー後に Fast Connect サーバーにアクセスするための接続を再確立する必要はありません。

交換網や、Clinfo を実行していないクライアントについては、フォールオーバー後に確実にクライアント接続するための追加ステップが必要になることがあります。Clinfo を実行していないクライアントの構成に関する注意事項については、『HACMP クライアントの計画』を参照してください。

v アダプター障害。Fast Connect サーバーで必要とされる転送プロトコルを実行しているサービス・アダプターまたはネットワーク・インターフェース・カードに障害が発生した場合、HACMP は通常どおりにアダプター・スワップを実行し、Fast Connect は新しいアダプターで接続を確立します。アダプター障害の発生後、クライアントは一時的に、ファイルやプリンタなどの共用リソースにアクセスできなくなります。アダプター・スワップが完了すると、クライアントは再びこれらのリソースにアクセスできるようになります。

関連資料:

177ページの『HACMP クライアントの計画』このトピックでは、HACMP クライアントの計画の考慮事項について説明します。これは、HACMP ソフトウェアのインストールに先行する最後のステップです。

Fast Connect ワークシートの記入Fast Connect ワークシートは、Fast Connect リソースを記録するために使用します。

Fast Connect リソースとして構成するリソースを特定するために、Fast Connect ワークシートに情報を記入します。

Fast Connect ワークシートを記入するには、以下の手順を実行します。

計画 23


2. Fast Connect のリソースが含まれるリソース・グループの名前を記録します。

3. リソース・グループに参加するノードを記録します。

4. 高可用性を維持する Fast Connect リソースを記録します。これらのリソースは、SMIT からリソースを構成する時に、ピック・リストから選択することになります。

5. Fast Connect で共用するファイルまたはディレクトリーを含むファイルシステムを記入します。これらのファイルシステムは、リソース・グループの構成時に SMIT の「File Systems (ファイルシステム)」フィールドで指定します。

関連資料:

221ページの『Fast Connect ワークシート』このワークシートは、Fast Connect リソースを記録するために使用します。

関連情報:


高可用性通信リンクの計画HACMP では、異なるタイプの通信リンクの高可用性を実現できます。

このような通信リンクには、以下のものがあります。

v LAN ネットワーク・インターフェース・カードを介して構成される SNA

v SNA over X.25

v Pure X.25

LAN インターフェース・カードには、イーサネット、トークンリング、FDDI があります。これらのカードは、HACMP クラスター・トポロジーの一部として構成されます。

X.25 カードは通常、WAN 接続に使用されます (例外もあります)。これらのアダプターは、異種マシン(メインフレームからダム端末まで) を接続するメカニズムを備えています。X.25 ネットワークの一般的な使用方法では、これらのカードは、クラスター・トポロジーに含まれず、標準 HACMP トポロジー管理メソッドで制御されない異なるクラスのデバイスとなります。つまり、X.25 カードの状況をモニターするためにハートビートは使用されず、また、管理者は HACMP 内に X.25 固有のネットワークを定義しません。

HACMP リソース・グループに定義された通信リンクは、他の HACMP リソースと同様に保護されます。LAN カードや X.25 リンクに障害が発生した場合、あるいは一般的なノードやネットワークの障害が発生した場合、高可用性通信リンクは、同じノード上またはテークオーバー・ノード上で使用可能な別のカードにフォールオーバーします。

高可用性通信リンクが構成されているクラスターの場合、適切なファイルセットがインストールされているかどうかが検査され、次の状況に該当する場合にエラーが報告されます。

v SNA HA 通信リンクがリソース・グループの一部として構成されており、sna.rte ファイルセット・バージョン 6.1.0.0 以降が、このリソース・グループの一部であるノードで欠落している場合

v X.25 HA 通信リンクがリソース・グループの一部として構成されており、sx25.rte ファイルセット・バージョン 2.0.0.0 以降が、このリソース・グループの一部であるノードで欠落している場合

v SNA X.25 以降で、HA 通信リンクがリソース・グループの一部として構成されており、sx25.rte ファイルセットのバージョン 6.1.0.0 および 2.0.0.0 以降の両方が、このリソース・グループの一部であるノードで欠落している場合


SNA リンクおよび X.25 リンクのソフトウェアおよびハードウェアの要件SNA リンクおよび X.25 リンクの場合、HACMP で可用性の高い通信リンクを構成するには、HACMP の外部に構成を追加する必要があります。

SNA リンクの要件は次の通りです。

v CS/AIX バージョン 6.1 またはそれ以降が必要です。

v SNA-over-LAN リンクは、イーサネット・アダプター、トークンリング・アダプター、および FDDI アダプターでサポートされます。

X.25 リンクの要件は次の通りです。

v AIXlink/X.25 バージョン 2 またはそれ以降が必要です。

v X.25 リンクは、次のアダプターでサポートされます。

– IBM 2 ポート・マルチプロトコル・アダプター (DPMP)

– IBM Artic960Hx PCI アダプター (Arctic)

関連情報:

www.ibm.com

www.redbooks.ibm.com

通信リンク・ワークシートの記入このセクションでは、通信リンク・ワークシートへの情報の記入方法について説明します。

通信リンク (SNA-over-LAN) ワークシートの記入:

通信リンク (SNA-over-LAN) ワークシートは、クラスター内の SNA-over-LAN 通信リンクに関する情報を記録するために使用します。

通信リンク (SNA-over-LAN) ワークシートを印刷し、このセクションの情報を使用して内容を記入します。クラスター内の SNA-over-LAN 通信リンクごとに、1 つのワークシートに情報を記入します。

SNA リンクは、HACMP に定義する前に、別途 AIX に構成しておく必要があります。ここで入力する情報の大半は、AIX 構成情報から取得します。

通信リンク (SNA-over-LAN) ワークシートを記入するには、以下の手順を実行します。


2. 「Resource Group (リソース・グループ)」フィールドに、通信リンクを定義するリソース・グループを記入します。

3. 「Nodes (ノード)」フィールドに、リソース・グループに参加させるノードを入力します。

4. 「Name (名前)」フィールドにリンク名を入力します。

5. 「DLC Name (DLC 名)」フィールドに DLC 名を入力します。これは、高可用として構成する既存のDLC プロファイルの名前です。

6. 「Port(s) (ポート)」フィールドに、自動的に起動するポートの名前を入力します。

7. 「Link Station(s) (リンク・ステーション)」フィールドに、リンク・ステーションの名前を入力します。

8. リンクの始動または停止時に、カスタマイズした操作を実行するためにこのリンクが使用するアプリケーション・サービス・ファイルの名前を記入します。

計画 25

http://www.ibm.com

http://www.redbooks.ibm.com

関連資料:

222ページの『通信リンク (SNA-over-LAN) ワークシート』このワークシートは、クラスター内の SNA-over-LAN 通信リンクに関する情報を記録するために使用します。

関連情報:


通信リンク (X.25) ワークシートの記入:

通信リンク (X.25) ワークシートは、クラスター内の X.25 通信リンクに関する情報を記録するために使用します。

通信リンク (X.25) ワークシートを印刷し、このセクションの情報を使用して内容を記入します。クラスター内の X.25 通信リンクごとに、1 つのワークシートに情報を記入します。

この X.25 ワークシートは、HACMP 内でのリンク構成用ワークシートです。X.25 アダプターおよびリンクは、リンクを HACMP 用に定義する前に、別途 AIX に構成しておく必要があります。ここで入力する情報の大半は、AIX 構成情報から取得します。

通信リンク (SNA-over-LAN) ワークシートを記入するには、以下の手順を実行します。





5. このリンクで使用する X.25 ポート (例えば、sx25a0) を入力します。ポート名は、クラスター内で重複してはなりません。この名前は「sx25a」で始まる必要がありますが、最後の数字の部分はユーザーが選択できます。ポート名の長さは最大で 8 文字です。したがって、末尾に最大 3 桁までの数字を指定できます。

6. 「Address/NUA (アドレス/NUA)」フィールドに、このリンクで使用する X.25 アドレス (ローカルNUA) を入力します。

7. 「Network ID (ネットワーク ID)」のデフォルト値は 5 です。必要に応じて、他の値を記入します。

8. 「X.25 Country Code (X.25 国別コード)」を記入します。空欄のままの場合は、システムのデフォルト値が使用されます。

9. 「Adapter Name(s) (アダプター名)」フィールドに、このリンクで使用可能にする通信アダプターを指定します。デバイス名ではなく、HACMP 名を入力します。 SMIT で、ピック・リストからこのフィールドの項目を選択します。


関連資料:

222ページの『通信リンク (X.25) ワークシート』このワークシートは、クラスター内の X.25 通信リンクに関する情報を記録するために使用します。

通信リンク (SNA-over-X.25) ワークシートの記入:

通信リンク (SNA-over-X.25) ワークシートは、クラスター内の SNA-Over-X.25 通信リンクに関する情報を記録するために使用します。


通信リンク (SNA-Over-X.25) ワークシートを印刷し、このセクションの情報を使用して内容を記入します。クラスター内の SNA-over-X.25 通信リンクごとに、1 つのワークシートに情報を入力します。このSNA-Over-X.25 ワークシートは、HACMP 内でのリンク構成用ワークシートです。SNA リンク、X.25 アダプターおよび X.25 リンクは、SNA-over-X.25 リンクを HACMP 用に定義する前に、別途 AIX に構成しておく必要があります。ここで入力する情報の大半は、AIX 構成情報から取得します。

通信リンク (SNA-over-X.25) ワークシートを記入するには、以下の手順を実行します。





5. このリンクで使用する X.25 ポート (例えば、sx25a0) を記入します。ポート名は、クラスター内で重複してはなりません。この名前は「sx25a」で始まる必要がありますが、最後の数字の部分はユーザーが選択できます。ポート名の長さは最大で 8 文字です。したがって、末尾に最大 3 桁までの数字を指定できます。

6. 「X.25 Address/NUA (X.25 アドレス/NUA)」フィールドに、このリンクで使用する X.25 アドレス(ローカル NUA) を入力します。

7. 「X.25 Network ID (X.25 ネットワーク ID)」のデフォルト値は 5 です。ここでは、必要に応じて、別の値を入力します。

8. 「X.25 Country Code (X.25 国別コード)」を記入します。空欄のままの場合は、システムのデフォルト値が使用されます。

9. 「X.25 Adapter Name(s) (X.25 アダプター名)」フィールドに、このリンクで使用可能にする通信アダプターを指定します。デバイス名ではなく、HACMP 名を入力します。 SMIT で、ピック・リストからこのフィールドの項目を選択します。

10. SNA DLC を入力します。これは、高可用として構成する既存の DLC プロファイルの名前です。SMIT で、ピック・リストからこのフィールドの項目を選択します。

11. 「SNA Port(s) (SNA ポート)」フィールドに、自動的に起動する SNA ポートの名前を入力します。

12. 「SNA Link Station(s) (SNA リンク・ステーション)」フィールドに、SNA リンク・ステーションの名前を入力します。


関連資料:

223ページの『通信リンク (SNA-Over-X.25) ワークシート』このワークシートは、クラスター内の SNA-Over-X.25 通信リンクに関する情報を記録するために使用します。

クラスター・ダイアグラムの作図クラスター・ダイアグラムは、計画プロセスの各ステップで作成した情報を集めて、クラスターの機能と構造を示す 1 つの図面にまとめたものです。

次の図は、ラック・マウント・システムとスタンドアロン・システムが含まれている混在型クラスターを示したものです。ダイアグラムでは、各ノードがサポートするスロットを長方形の枠で示します。クラスターがシン・ノードを使用する場合、ノードの輪郭を太くして、2 つのノードを 1 つのドロワーに入れます。

計画 27

ワイド・ノードの場合は、ドロワー全体を使用します。ハイ・ノードの場合は、ワイド・ノード 2 つ分のドロワーを使用します。それぞれのシン・ノードにはイーサネット接続が組み込まれています。

このダイアグラムの作成は、クラスター名と、高可用性にするアプリケーションを指定する作業から始めます。次に、クラスターを構成する各ノードの輪郭を太くします。各ノードの名前を入れます。以降の各章では、ネットワークやディスク・ストレージ・サブシステムに関する情報をダイアグラムに加えていきます。

n16

n14

n12

n10

n15

n13

n11

n09

n07

n05

n01

11ノード・クラスター

クライアント

n16

n14

n12

n15

n13

n11

8ノード・クラスター

クライアント

c_clu

ste

r_ty

pes

n07 n05

クラスター・ネットワーク接続の計画このトピックでは、HACMP クラスターのネットワーク・サポートの計画方法について説明します。


前提条件

『クラスターの初期計画』では、クラスターの計画を開始し、ノードの数と、高可用性にする主要アプリケーションを特定しました。次に、クラスター・ダイアグラムの作成を開始しました。このダイアグラムは、このセクションで行う計画の出発点になります。

また、この段階までには、IP アドレス・テークオーバー (IPAT) を使用してクラスターに特定のサービスIP アドレスを保持させるかどうかも決定しておく必要があります。

関連資料:

6ページの『クラスターの初期計画』このトピックでは、アプリケーションの可用性を高めるように HACMP クラスターを計画する際の初期ステップについて説明します。このステップには、初期プランニング・ワークシートの記入も含まれます。

概説この章では、クラスターのネットワーク・サポートを計画する方法を説明します。第一の目的は、ネットワーク・コンポーネントが潜在的な Single Point of Failure とならないように、冗長性を採り入れたクラスター・トポロジーを設計することです。

次の表は、こうしたネットワーク・コンポーネントと、ソリューションをリストしたものです。

クラスター・ネットワーク・オブジェクト Single Point of Failure を除去する方法

ネットワーク複数のネットワークを使用してノードを接続する

TCP/IP サブシステム非 IP ネットワークを使用して TCP/IP をバックアップする

ネットワーク・インターフェース・カード (NIC)

各ネットワーク上で冗長 NIC を使用する

このセクションでは、以下の計画作業を実行します。

v クラスター・ネットワーク・トポロジー (つまり、クラスター・ノードを接続する IP ネットワークと非IP (Point-to-Point) ネットワークの組み合わせ)、および各ノードがそれぞれのネットワークに対して確保する接続の数を設計する。

注: クラスターの区分化を回避するために、HACMP クラスターで冗長ネットワークを構成して、IP ネットワークと非 IP ネットワークの両方を使用することを強くお勧めします。これらのネットワークのうちの一部が、ハートビート用に使用されます。ハートビート・ネットワークの計画については、『HACMP でのハートビート』を参照してください。

v サービス IP ラベルの可用性を高めるために、IP エイリアスによる IP アドレス・テークオーバー(IPAT)、または IP 交換による IPAT (代替ハードウェア・アドレス・テークオーバーを使用する、または使用しない) のどちらを使用するかを決定する。

v ネットワークおよびネットワーク・インターフェースのプランニング・ワークシートに情報を記入する。

v クラスター・ダイアグラムへネットワークを追加する。

このセクションでは、IP 交換による IPAT を、代替ハードウェア・アドレスを介したハードウェア・アドレス・テークオーバー (HWAT) とともにセットアップする方法についても詳しく解説します。

関連資料:

35ページの『HACMP でのハートビート』HACMP の主な役割は、障害を認識して対応することです。HACMP は、ハートビートを使用してネット

計画 29

ワーク・インターフェース、デバイス、および IP ラベルの活動をモニターします。

HACMP の一般的なネットワーク考慮事項このセクションでは、HACMP を適切に運用するために必要なネットワーキングのタイプについて、一般的なガイドラインを示します。

注: 複数のサイトを持つクラスター用のネットワークを計画している場合は、対応する災害復旧ソリューション (HACMP/XD for Metro Mirror または HACMP/XD for GLVM) の資料を参照してください。

サポートされるネットワーク・タイプHACMP では、異なる TCP/IP ベースのネットワークを使用してノード間通信を実行できます。

これらのネットワーク・タイプは以下のとおりです。

v イーサネット

v トークンリング

v 光ファイバー分散データ・インターフェース (FDDI)

v ATM および ATM LAN エミュレーション

v イーサチャネル

v Infiniband

v 仮想イーサネット

v ホスト・イーサネット・アダプター/統合仮想イーサネット

IP エイリアスIP エイリアスは、NIC で通常構成される IP ラベル/アドレスに加えて、NIC に追加構成される IP ラベル/アドレスです。IP エイリアスの使用は、HACMP がサポートしている AIX 機能です。AIX では、NIC

上で複数 IP エイリアスがサポートされます。NIC 上の IP エイリアスはそれぞれ、個別のサブネットに設定することができます。また AIX では、1 つのインターフェースに対して複数の異なるサブネット・マスクを持つ IP エイリアスを構成できます。この機能は、HACMP ではまだサポートされていません。

IP エイリアスは、ハートビートのネットワーク構成用に加え、IP アドレス・テークオーバー (IPAT) のサービス・アドレスとブート・アドレスの両方として HACMP で使用されます。

関連資料:

136ページの『リソース・グループ内のサービス IP ラベルの計画』HACMP で管理されるブートおよびサービス IP ラベル/アドレスのサブネット要件は、いくつかの変数によって異なります。

ネットワーク接続HACMP では、クラスター内の各ノードが、他の各ノードとの間に直接的な、経路指定されていないネットワーク接続を少なくとも 1 つは確保する必要があります。このソフトウェアは、これらのネットワーク接続を使用してクラスター・ノード間でハートビート・メッセージの受け渡しを行い、すべてのクラスター・ノード、ネットワークおよびネットワーク・インターフェースの状態を調べます。

HACMP では、特定のクラスター・ネットワーク用の通信インターフェースをすべて同じ物理ネットワーク上に定義し、それらの各通信インターフェースが相互にパケット (ブロードキャスト・パケットも含む)

の経路を定める必要があります。また、各通信インターフェースは、ネットワーク装置による干渉なしに相互に応答を受信できなければなりません。


クラスター・ノード間には、UDP ブロードキャストやその他のパケットをすべてのクラスター・ノードに透過的にパススルーするインテリジェント・スイッチ、ルーター、およびその他のネットワーク機器だけを配置してください。これは、UDP ブロードキャストやその他のパケットをすべてのクラスター・ノードに透過的にパススルーしないインテリジェント・スイッチ、ルーター、およびその他のネットワーク機器をクラスター・ノード間に配置しないということです。この禁止事項は、プロトコルを次のように最適化する装置にも適用されます。

v プロキシー ARP および MAC アドレス・キャッシュ

v マルチキャストおよびブロードキャスト・プロトコル要求をユニキャスト要求に変換

v ICMP 最適化

v ルーティング・プロトコル操作

v その他のインターネット・プロトコルの操作または最適化

これらの装置がクラスター・ノードとクライアント間のパスに設置されている場合は、$PING_CLIENT_LIST 変数 (clinfo.rc 内) を使用して、クライアントに IP アドレスの移動を通知します。特定のネットワーク・トポロジーでは、他のソリューションが必要となる場合もあります。

パケットの流れを変更しないブリッジやハブなどの受動デバイスは、クラスター・ノード間、およびノードとクライアントの間に設置しても安全です。

ARP キャッシュの更新各 NIC には、製造時に固有のハードウェア・アドレスが設定されます。このアドレスは、メディア・アクセス制御 (MAC) アドレスと呼ばれます。MAC アドレスは、ローカル・ネットワーク上の NIC 間でパケットを送信するためにネットワーク・ドライバーが使用するアドレスです。MAC アドレスは IP アドレスではありません。

ほとんどの TCP/IP システムでは、最近使用した IP アドレスと、対応する MAC アドレスのリストが保持されます。このリストは、アドレス解決プロトコル (ARP) キャッシュと呼ばれます。

NIC に障害が発生した場合に、その NIC 上の IP ラベルを別の NIC に移動するように、HACMP を構成することができます。また、元のノードに障害が発生した場合、IP ラベルを別のノード上の NIC に移動させることもできます。IP ラベルが移動すると、その ARP キャッシュ・エントリーは不正確になります。クラスター・イベントのあと、HACMP ノード、および無差別 listen をサポートするネットワーク・デバイスは、ARP キャッシュを自動的に更新します。無差別 listen をサポートしていないクライアントおよびネットワーク装置は、不正確なエントリーを保持し続けます。これらのアドレッシングの更新は、次のどちらかの方法で管理できます。

v 代替ハードウェア・アドレスを使用する。HACMP のこの機能によって、移動可能な IP ラベルが設定された NIC に代替 MAC アドレスが割り当てられます。IP ラベルが移動すると、HACMP は MAC アドレスも移動させます。この場合、ARP キャッシュは正確なままです。

v ARP キャッシュを更新する。clinfo.rc は、clinfo の PING_CLIENT_LIST エントリーを使用して、ルーターなどのネットワーク・デバイスとクライアントの ARP キャッシュを更新できます。

関連資料:

クライアント・ノードへの HACMP のインストール

IP ラベル非 HACMP 環境では、通常ホスト名はシステムを特定し、そのホスト名はシステム内にある 1 つのネットワーク・インターフェースの IP ラベルになっています。したがって、システムのホスト名を接続用 IP

ラベルとして使用すれば、そのシステムへのアクセスが可能になります。

計画 31

ホスト名とノード名

通常、ホスト名はノード名と同じにできます。HACMP で標準構成パスを使用する場合、クラスターにノードを追加するときに通信パスとして IP アドレス、関連する IP ラベル、または完全修飾ドメイン名(FQDN) を入力すると、HACMP はノードからホスト名を取得します。また、ノード名が明示的に指定されていない場合は、ホスト名をノード名として使用します。拡張構成パスでは、常にノード名を指定します。

ノード名とホスト名が異なる場合もあります。例えば、接続に使用するインターフェースが、システムのホスト名に対応する IP ラベルを持つことを必要とするアプリケーションがあります。

フォールオーバー時にアプリケーションとともに AIX の「hostname attribute (ホスト名属性)」が別のノードに移動することがアプリケーションで必要となる場合は、このアプリケーションを含むリソース・グループが別のノードにフォールオーバーするときに、サービス IP ラベルに対応するように HACMP でノード・ホスト名を変更してください。イベント前処理スクリプトまたはイベント後処理スクリプトを使用して、ホスト名を変更してください。

TCP/IP ネットワークの IP ラベル

TCP/IP ネットワークでは、IP ラベルおよび関連する IP アドレスを /etc/hosts ファイルに記述する必要があります。

サービス IP ラベル/アドレスの名前は、クラスター内で一意であるとともに、ボリューム・グループ名やリソース・グループ名とは異なる必要があります。また、それらのサービス IP ラベル/アドレスが使用されるアプリケーションや対応するデバイスに関連した名前 (websphere_service_address など) にしてください。

サービス IP ラベルをインターフェースに割り当てる場合は、クラスターでのインターフェースの役割を識別する命名規則を使用してください。 /etc/hosts ファイルの関連エントリーは、次のようになります。

100.100.50.1 net1_en0100.100.60.1 net2_en1

関連する AIX マニュアルの説明に従って、NIC を構成します。NIC の構成時に、AIX によってインターフェース名が割り当てられます。インターフェース名は、NIC のタイプを表す 2 または 3 文字と、AIX

がアダプターのタイプ別に順番に割り当てる数字から構成されます。例えば、AIX は、構成する最初のイーサネット NIC には en0 などのインターフェース名を割り当て、2 番目の NIC には en1 を割り当てます。3 番目以降の NIC にも、同様にインターフェース名を割り当てます。

関連情報:

クラスター・イベントの構成

クラスターの区分化区分化はノード分離とも呼ばれ、ネットワークまたは NIC の障害により、クラスター・ノードが他のノードから分離されたときに発生します。

ある HACMP ノードが別のノードからのネットワーク・トラフィックを受信しなくなった場合、このHACMP ノードは相手のノードに障害が発生したと解釈します。ご使用の HACMP 構成に応じて、HACMP では、「障害が発生した」ノードからのディスクの獲得を開始し、そのノードのアプリケーションおよび IP ラベルを使用可能にしようとする可能性があります。「障害が発生した」ノードが実際には動作している場合、そのノードからディスクを取得したときに、データが破壊される可能性があります。ネットワークが再び使用可能になった場合、HACMP はいずれかのノードを停止して、ディスクの競合がさらに発生するのを防ぎ、ネットワーク上に IP アドレスを複製します。


追加のネットワークを次のように構成して、クラスターの区分化を回避できます。

v ネットワーク・トポロジーに Point-to-Point ネットワークを追加する。

v 各ノードで HACMP ネットワーク・モジュールのパラメーターを調整する。

IP リンク上を流れる HACMP のハートビートは、UDP データグラムとして送信されます。したがって、ネットワークまたはノードが輻輳すると、IP サブシステムはハートビートを通知することなく破棄する場合があります。

調整パラメーターの設定方法については、セクション『クラスターのモニター』を参照してください。

関連資料:

43ページの『Point-to-Point ネットワークの計画』クラスター・ノードを直接リンクする非 Point-to-Point 接続を構成することによって、可用性を高めることもできます。

56ページの『クラスターのモニター』サポートされている各クラスター・ネットワークには、それぞれ対応するクラスター・ネットワーク・モジュールがあります。これらのモジュールは、そのクラスター・ネットワークへのすべての入出力をモニターします。クラスター内では、ネットワーク・モジュールが相互に接続を維持しています。各クラスター・ノード上のクラスター・マネージャーは、これらの接続を介して相互にメッセージを送信します。

一般的なネットワーク接続例適正な HACMP ネットワーキングとして、2 つの独立したイーサネット・ネットワークで構成され、それぞれのネットワークの各ノードが 2 つのネットワーク・インターフェースを持つ例が挙げられます。

2 つのルーターがネットワークを接続し、2 つのネットワーク間ではなく、クラスターとクライアント間でパケットを経路指定します。クラスターの各ノードに clinfo.rc ファイルがインストールされ、このファイルには複数のクライアント・マシンの IP アドレスが指定されています。

スイッチ・ネットワークの HACMP 構成スイッチ・ネットワークを使用した HACMP 構成では、ネットワークやスイッチが正しく定義および構成されていないと、予期しないネットワーク・インターフェース障害イベントが発生する可能性があります。

スイッチ・ネットワークを構成する場合は、次のガイドラインに従ってください。

v VLAN。VLAN を使用する場合、特定のネットワーク上で HACMP に定義されているインターフェースがすべて、同じ VLAN 上に構成されていなければなりません (各 VLAN に 1 ネットワークが対応)。

v 自動ネゴシエーション設定。イーサネット NIC によっては、速度や半二重、全二重などの特性を自動ネゴシエーションする機能を持つものがあります。自動ネゴシエーションを使用せずに、目的の速度と二重値の設定で NIC が動作するように構成します。NIC を接続するスイッチ・ポートは、同じ速度と二重値に固定して設定する必要があります。

v ARP 設定。ネットワーク・スイッチによっては、ARP 応答を遅らせたり、正しくないプロキシー ARP

応答を提供して、ARP 応答に影響を与える場合があります。こうした動作のいずれかが、予期しないネットワーク・イベントを引き起こす可能性があります。この状況に対処するには、スイッチが ARP 要求に適時に応答できるように、可能であれば問題の原因となっている設定を変更してください。

多くのスイッチ製品で、これは spanning tree algorithm、portfast、uplinkfast、および backbonefast をオフにすることを意味します。スパンニング・ツリーをオンにする必要がある場合は、portfast もオンにしてください。

計画 33

HACMP および仮想イーサネットHACMP は、適用できる APAR がインストールされた VIOS または IVE ファシリティーによって提供される仮想イーサネットをサポートします。HACMP サポートは、VIOS および IVE と同一のものです。

仮想イーサネット上のインターフェースを使用している場合は、HACMP の PCI Hot Plug ユーティリティーは利用できません。このユーティリティーは、物理インターフェース・カードにのみ対応します。仮想イーサネットは仮想入出力アダプターを使用するので、このユーティリティーを使用することはできません。

次のリストには、仮想イーサネットを使用した HACMP に関する追加の考慮事項が示されています。

v VIOS が同じネットワーク上で定義された複数の物理インターフェースを有している場合、または同じフレーム内の VIOS を使用している複数の HACMP ノードがある場合、HACMP は、単一の物理インターフェースの障害について通知されず、その結果、この障害に対処しません。この場合、VIOS がこのような障害を迂回してトラフィックを経路指定するため、クラスター全体の可用性は制限されません。この点において、VIOS のサポートはイーサチャネルと類似しています。個別の物理インターフェースの障害を通知するためには、VIOS に基づかない方法を使用してください。

v VIOS がネットワーク上で単一の物理インターフェースしか有していない場合、HACMP はその物理インターフェースの障害を検出します。ただし、この障害によってそのノードがネットワークから隔離されます。

仮想イーサネット接続のトラブルシューティング

HACMP に対して定義された仮想イーサネット・インターフェースをトラブルシューティングして、インターフェース障害を検出するには、これらのインターフェースを単一アダプター・ネットワーク上で定義されたインターフェースとして考えてください。

具体的には、VLAN に属しているネットワーク・インターフェースを etc/cluster/ping_client_list に列記するか、/usr/es/sbin/cluster/etc/clinfo.rc スクリプト内の PING_CLIENT_LIST 変数に列記して、clinfo プログラムを実行してください。これにより、クラスター・イベントが発生するたびに、clinfo プログラムは、列記されたネットワーク・インターフェースの障害をモニターして検出します。 VLAN の特性上、ネットワーク・インターフェースの障害を検出するための他の手段は無効です。

関連資料:

53ページの『サービス IP ラベル・エイリアスの配布のタイプ』サービス IP ラベル・エイリアスの配置は、SMIT で異なる配布設定を指定することができます。

59ページの『2 ノード・クラスターのサービス・アダプター障害の識別』特定の条件下で単一アダプター・ネットワークになる可能性があるクラスター構成では、HACMP によってアダプター障害を正確に判断することが難しい場合があります。これは、RSCT トポロジー・サービスが、パケット・トラフィックを単一アダプターを介して強制的に送信し、そのアダプターの正常な動作を確認することができないためです

エイリアスによる IPAT の考慮事項一部のネットワーク構成では、サービス IP ラベルが使用中かどうかに関係なく、エイリアスによる IPAT

のデフォルト・ネットワーク・タイプがハートビートとうまく連携しないことがあります。このような構成タイプは、異なるサイト上のノードが共通の IP サブネットを共有できない XD ネットワークで多く見られます。また、XD 以外の環境でも、意図的にそのようにしてあれば、このネットワーク問題が発生する可能性があります。

ご使用のネットワークで以下のような構成が使用されている場合、ハートビートが正常に機能しないことがあります。


v クラスター内の 2 つ以上のノードが、ネットワーク内で少なくとも 2 つのアダプターを使用している。

v ネットワーク内の多くのアダプターが、異なるノード間のサブネットを含め、完全に異なるサブネット上にある。

ハートビートが機能しない可能性のあるネットワーク構成の例を以下に示します。

Network net_XD_data_01 (Netmask for all adapters: 255.255.255.0)NODE host01:host01_en0 5.10.1.101host01_en1 5.20.2.102NODE host02:host02_en0 6.10.1.111host02_en1 6.20.2.112

この例では、ノード host01 および host02 がネットワーク net_XD_data_01 で 2 つのアダプターを使用しています。アダプターはすべて、この例に示されたネットマスクに基づく別々のサブネット上にあります。このタイプのネットワークでは、特定のターゲットに対して複数の経路が存在します。システム全体で、次に使用される経路を示す単一のレコードが保持されます。

例えば、target X に対して 2 つの経路 (route1 および route2) があり、プロセス A が target X への経路を要求すると、プロセス A に route1 が与えられます。別のプロセス B が target X への経路を要求すると、プロセス B に route2 が与えられます。 route1 が使用不可の場合、プロセス A は、target

X への新規経路をシステムに要求しますが、プロセス A は以前に route1 を使用していたという事実にもかかわらず、プロセス A には route1 が再度与えられます。このような経路再割り当て処理が行われるのは、システムで route1 が次に使用可能なネットワークとなっているためです。この結果、パケットが失われる可能性があります。そのため、2 つのネットワーク・ルーターにわたるハートビートは正常に機能しなくなります。さらに、この 1 つのアダプターの障害がネットワーク全体の障害につながる可能性があります。

ご使用のネットワークで、高可用性を維持するためのサービス・アドレスが使用されていない場合、同一ネットワーク内で 1 つのノードに複数のアダプターを指定する必要はありません。この場合、ネットワークを 2 つの異なるネットワークに分割し、ネットワークごとにアダプターを 1 つのみ指定します。

ご使用のネットワーク構成で複数のアダプターが指定されていて、1 つ以上の IP アドレスの高可用性が維持されていて、アダプターを別々のネットワークに分割できない場合、ノード・バインド・サービス・アドレスとともに「IP 交換による IPAT」を使用する必要があります。サービス・アドレスがノード・バインドではない従来の「IP 交換による IPAT」も使用できる可能性がありますが、この場合には役に立ちません (ネットワーク構成に、複数のノード上で共通のサブネットがないため)。例えば、XD 環境で別々のサイトに複数のノードが存在する場合、あるサイトのサービス・アドレスを他のサイトで使用することはできません。

関連情報:

IP 交換による IP アドレス・テークオーバーの構成

ノード・バインド・サービス IP ラベルの構成

HACMP でのハートビートHACMP の主な役割は、障害を認識して対応することです。HACMP は、ハートビートを使用してネットワーク・インターフェース、デバイス、および IP ラベルの活動をモニターします。

クラスター・ノード間のハートビート接続は、HACMP がネットワーク障害とノード障害の違いを認識できるようにするために必要です。例えば、HACMP ネットワーク (このネットワークの IP ラベルはリソー

計画 35

ス・グループで使用されます) 上の接続が失われた場合に、それらのノード間で別の TCP/IP ベース・ネットワークおよび非 IP ネットワークが構成されていれば、HACMP は、そのクラスター・ネットワークの障害を認識して、クラスターの区分化を回避するための回復アクションを実行します。

クラスターの区分化を回避するために、HACMP クラスターで冗長ネットワークを構成して、IP ネットワークと非 IP ネットワークの両方を使用することを強くお勧めします。これらのネットワークのうちの一部が、ハートビート用に使用されます。

一般に、HACMP のハートビートは次のネットワークを介して送信できます。

v TCP/IP ネットワーク

v シリアル (非 IP) ・ネットワーク (RS232、TMSCSI、TMSSA、およびディスク・ハートビート)

RSCT のトポロジー・サービス・コンポーネントは、HACMP のハートビート機能を実行します。

トポロジー・サービスとハートビート・リング

HACMP は、ネットワークおよびネットワーク・インターフェースのモニター用に、RSCT のトポロジー・サービス・コンポーネントを使用します。トポロジー・サービスは、トポロジーにあるすべてのインターフェースを複数の異なるハートビート・リングにまとめます。現行バージョンの RSCT トポロジー・サービスでは、ハートビート・リングの上限数は 48 個です。これは、通常は、ネットワークおよびネットワーク・インターフェースのモニターには十分な数です。

ハートビート・リングは、RSCT によって動的に作成され、内部で使用されます。ハートビート・リングは、HACMP ネットワーク、またはネットワーク・インターフェース数と直接的な 1 対 1 の相関関係を持ちません。インターフェースおよびネットワークをハートビート・リングに割り当てるアルゴリズムは複雑ですが、一般的には以下の規則に従っています。

v HACMP ネットワークには、サービス・インターフェースをモニターするためのハートビート・リングが 1 つ存在し、同じサブネット上にある一連の非サービス・インターフェースごとに、1 つずつハートビート・リングが存在します。非サービス・インターフェースのハートビート・リング数は、最多数のインターフェースを持つノード内の非サービス・インターフェースの数に従って決定されます。

v ハートビート・リングの数は、クラスター内の任意の 1 ノード上のインターフェースの最大数とほぼ等しくなります。

クラスター検証中に、HACMP が RSCT 検証 API を呼び出すことに注意してください。この API は、ハートビート・リング計算の検査を含む一連の検査を実行し、上限値を超えている場合にエラーを発行します。

IP エイリアスを使用するハートビートこのセクションは IP エイリアスを使用するハートビートについての情報が含まれています。

概説同じノードの同じネットワーク上に複数のインターフェースがある場合は、サブネットおよび経路指定を慎重に計画する必要があります。複数のインターフェースが同じサブネットへの経路を持つシナリオは避ける必要があります。この状態では、ハートビート (およびその結果として、障害検出) が信頼できないものにされ、アプリケーション・ネットワーク・トラフィックを妨げる可能性があります。

IP エイリアスを使用するハートビートの利点は、次の通りです。

v 自動生成された IP エイリアスを使用してハートビートを実行します。


IP エイリアスを使用するハートビートでは、基本 NIC または他のあらゆるサービス・アドレスに使用される範囲以外のサブネット範囲で、ハートビート用のアドレスを HACMP によって自動的に構成できるというオプションが提供されます。

IP エイリアスを使用するハートビートでは、ハートビート用の適切なエイリアスが自動的に構成されますが、この場合でも、すべてのブート IP アドレスおよびサービス IP アドレスについて、サブネット・ルーティングへの影響に注意する必要があります。すなわち、サブネットを適切に計画しないと、HACMP で検出できないアプリケーション障害が発生する可能性があります。ただし、信頼性の高いHACMP クラスター通信を行う場合は、単一ネットワーク上のインターフェースがそのネットワーク上の他のノードと通信できる必要があります。

v ブート時アドレスと /etc/hosts の再構成を回避できます。

RSCT は、ハートビート・リングをセットアップして、独立した範囲の IP エイリアスを調べます。この結果、ハートビート・リングに対しては経路制御不能な範囲で指定のサブネットを使用し、その他のサブネットを経路制御可能なトラフィック用に保持することができます。また、ブート時アドレスと/etc/hosts のエントリーを再構成する必要がなくなります。

v HACMP のトポロジー構成をわかりやすくします。

v ネットワーク管理者からルーティング可能なサブネットを追加で取得する必要がありません。

例えば、ネットワーク・システム管理上の制約のために、ブート時にシステムで使用できる IP アドレスが同じサブネット上に存在する必要がある場合は、HACMP でエイリアスを使用するハートビートを使用できます。(一般に、システム管理上の制約がない場合は、ブート時にシステムで使用できる IP アドレスは、同じサブネット上または異なるサブネット上のどちらに存在していてもかまいません)。

IP エイリアスを使用するハートビートのセットアップIP エイリアスを使用するハートビートでは、ハートビート用の適切なエイリアスが自動的に構成されますが、この場合でも、すべてのブート IP アドレスおよびサービス IP アドレスについて、サブネット・ルーティングへの影響に注意する必要があります。すなわち、サブネットを適切に計画しないと、HACMP で検出できないアプリケーション障害が発生する可能性があります。

サブネット要件を十分に理解していて、IP エイリアスを使用するハートビートの利用が適切であると判断した場合に、IP エイリアスを使用するハートビートをセットアップしてください。

IP エイリアスを使用するハートビートを設定するには、SMIT を使用して、「IP Address Offset forHeartbeating over IP Aliases (IP エイリアスを使用するハートビートの IP アドレス・オフセット)」をネットワーク構成の一部として設定します。

IP エイリアスを使用するハートビートの IP アドレス・オフセットには次の特性があります。

v HACMP は、このオフセットを開始アドレスとして使用して、クラスター・ネットワーク内のすべてのインターフェース上の複数のサブネットで IP エイリアスの範囲を設定します。このサブネット・マスクは、ネットワーク用に使用されるものと同じです。

v IP エイリアスの範囲は、このネットワーク上ですでに使用されているどのアドレスとも重複しないようにする必要があります。

つまり、選択する開始アドレスは、物理ネットワーク・セットアップ内の他のネットワークによって使用されていないサブネット上に存在する必要があります。また、入力したネットワーク上には、使用する N 個のネットワーク用に、十分な数の使用可能なサブネットが存在する必要があります。ここで、N

はそれぞれのノードがネットワーク上に持つインターフェースの数です。HACMP は、これをクラスター検証プロセス時に確認します。

計画 37

v この範囲内の IP エイリアス・アドレスは、ハートビート用として HACMP でのみ使用されます。このアドレスは、経路指定が不要であり、他のトラフィックには使用できません。

v HACMP 構成データベースは、クラスターの始動時、検証時、および同期時に、その IP エイリアスをネットワーク・インターフェースに追加します。

v また、HACMP は、ハートビート用のアドレスを RSCT に提供します。シャットダウン時に、HACMP

はこれらのエイリアスをインターフェースから削除します。

HACMP で IP エイリアスを使用するハートビートをアクティブにするには、次の手順を実行します。

1. SMIT で拡張構成パスを使用して HACMP ネットワークを追加し、また、このネットワークに対してIP エイリアスを使用するハートビートの IP アドレス・オフセットを指定します。

2. 拡張 HACMP 構成パスを使用して IP アドレス・オフセットを既存のネットワークに追加します。IP

エイリアス・アドレス用に使用されるネットマスクは、基盤インターフェースのネットマスクと同じになります。

エイリアスを使用するハートビートを非アクティブにするには、IP アドレス・オフセットをネットワークから削除します。

関連情報:

管理ガイド

HACMP によるハートビート・リングの割り当て方法このセクションでは、IP エイリアスを使用するハートビートで使用されるサービス・ラベルと IP エイリアスが、HACMP によってどのように管理されるのかを説明します。

エイリアスを使用するハートビートは、IP エイリアスによる IPAT、または IP 交換による IPAT のいずれかと組み合わせて使用できます。

v IP 交換による IPAT の場合、フォールオーバー時に、サービス IP ラベルは、ハートビート・エイリアス IP アドレスではなくブート時アドレスとスワップされます。

v エイリアスによる IPAT の場合は、フォールオーバー時に、ハートビート・エイリアスとともにサービス IP ラベルのエイリアスがブート・インターフェース上に作成されます。

HACMP は、次のようにインターフェース・アドレスに基づいてハートビート・エイリアスを割り当てます。

v ノード上のネットワーク内の各インターフェースごとに、HACMP はサブネット・アドレスの値を増分します。

v ネットワーク内の各ノードごとに、HACMP はホスト・アドレスの値を増分します。

ハートビート・リングの例例えば、SMIT で 192.168.1.1 という IP アドレス・オフセットを指定した場合、HACMP はこの IP アドレス・オフセットに基づいたハートビート・リングを構築します。

構築されるハートビート・リングは以下のとおりです。

192.168.1.1 <――――-> 192.168.1.2

192.168.2.1 <――――-> 192.168.2.2

次の図は、これらのハートビート・リングを示しています。


次の表は、構成された IP アドレスの例を示しています。

IP アドレスの例 HACMP での役割 HACMP によるアクション

1.1.1.1 サービス IP エイリアス HACMP によってモニターされる

192.168.1.1. ハートビート用の IP エイリアス

HACMP によってモニターされる

2.2.2.1 ブート時に使用される IP

アドレスHACMP によってモニターされない

IP アドレスの例 HACMP での役割 HACMP によるアクション

1.1.1.2 サービス IP エイリアス HACMP によってモニターされる

192.168.2.1. ハートビート用の IP エイリアス

HACMP によってモニターされる

2.2.2.2 ブート時に使用される IP

アドレスHACMP によってモニターされない

注: 前の表では、ベース・アドレス (2.2.2.1 など) はハートビート・トラフィック用には使用されませんが、基盤 NIC の正常性は、IP エイリアス・アドレスによるハートビートを使用してモニターされます。NIC で何らかの障害が発生すると、その NIC 上に現在構成されているサービス・ラベルや永続ラベルを回復するように HACMP に警告されます。

もう 1 つの例として、IP アドレス・オフセット (開始アドレス) として 10.10.10.1 を使用できます。ネットワークの各ノードに 2 つの NIC があり、サブネット・マスクが 255.255.255.0 である場合、HACMP は次のハートビート IP エイリアスを割り当てます。

ノード A:ネットワーク en0, boot_label = nodeA_boot の場合

hb_IP_alias_label1 = 10.10.10.1

ネットワーク en1, boot_label = nodeA_boot2 の場合

hb_IP_alias_label2 = 10.10.11.1

同様に、ノード B:hb_IP_alias_label1 = 10.10.10.2hb_IP_alias_label2 = 10.10.11.2

HACMP のクラスター検証ユーティリティーは、このアドレス範囲の有効な構成があることを確認します。HACMP は次のことを確認します。

v すべてのインターフェースのネットマスクとタイプが同じであること。

v IP オフセット・アドレスが十分な数のアドレスとサブネットに対応していること。

計画 39

注: Verification は、IP エイリアスを使用するハートビートの構成でインターフェースやサブネットの要件を検査しません。これは、独立したアドレス範囲が使用されているためです。

IP エイリアスを使用するハートビート用に HACMP によって割り当てられた IP アドレスの表示ハートビート用の IP エイリアスは、netstat などの AIX コマンドを実行したときに表示されます。

ディスクを使用するハートビート拡張コンカレント・モード・ボリューム・グループの任意の共用ディスクを利用して、非 IP Point-to-Point

ハートビート・ネットワーク (ディスク・ハートビート・ネットワーク) が構成できます。ディスクを使用するハートビートでは、障害検出用に別のタイプの非 IP Point-to-Point ネットワークが提供されます。

ディスク・ハートビート・ネットワークは、ケーブル長の制限がある RS232 や、専用のディスク・アダプター・ハードウェアとケーブルが必要な TMSSA などの他の Point-to-Point ネットワークの代わりとして使用できます。ディスクを使用するハートビートでは、追加や専用のハードウェア、ケーブル、マイクロコードを必要としません。このハートビートでは、データ用にも使用されているディスクや、ボリューム・グループおよびファイルシステムが HACMP リソース・グループに含まれているディスクを使用できます。

ディスク・ハートビート・ネットワークでは、ディスクに接続された 2 つのノードがディスクのわずかな非データ部に対して、定期的にハートビート・メッセージを書き込み、他のノードによって書き込まれたメッセージを読み取ります。ディスク・ハートビート・ネットワークは、他の非 IP ハートビート・ネットワークと同様、2 つのノードのみを接続します。クラスター内に 3 つ以上のノードが存在する場合は、ハートビート用に複数のディスクを使用します。各ノードは、少なくとも 1 つの他のノードへの非 IP ハートビート・パスを持つ必要があります。ディスク・ハートビート・パスが切断された場合、少なくとも 1 つのノードが共用ディスクにアクセスできません。

クラスター内でディスク・ハートビート・ネットワークを構成するには、次の 2 つの方法があります。

v クラスター内の複数のノードで共用される拡張コンカレント・ボリューム・グループを作成します。次に、HACMP の拡張構成 SMIT パスを使用して、検出された通信デバイスの Point-to-Point ペアを構成します。

または

v クラスター・ディスク・ハートビート・ネットワークを作成してから、SMIT の「Add Pre-DefinedCommunication Interfaces and Devices (事前定義済み通信インターフェースおよびデバイスの追加)」パネルを使用して、このネットワークにデバイスを追加します。

HACMP のクラスター検証ユーティリティーは、ディスク・ハートビート・ネットワークが正しく構成されていることを確認します。

ディスクを使用するハートビートおよび迅速なノード障害検出方法

HACMP では、ノード障害がクラスター全体で認識されるまでに要する時間を短縮できます。ディスク・ハートビート・ネットワークが構成されており、ディスク・ハートビート NIM のパラメーターを指定している場合、ノード障害が発生すると、HACMP は、ディスク・ハートビート・ネットワークを使用して切断メッセージを共用ディスク上に配置します。これにより、隣接ノードは 1 ハートビート期間内にそのノード障害を認識できます。

関連資料:

58ページの『ノード・フォールオーバー時間の短縮』HACMP では、ノード障害が確実に検出されるとともに、ノード障害がクラスター全体にわたって認識さ


れるまでに要する時間が短縮されます。

関連情報:

トラブルシューティング・ガイド

HACMP ネットワーク・モジュールの構成

ネットワーク・トポロジーの設計クラスター・ノードとクライアントをリンクする IP および非 IP (Point-to-Point) ネットワークの組み合わせは、ネットワーク・トポロジーと呼ばれます。HACMP ソフトウェアは、各ノード上で多数の IP デバイスおよび Point-to-Point デバイスをサポートするため、ネットワーク構成を柔軟に設計できます。

ネットワーク・トポロジーの設計時には、クライアントにおいて、アプリケーションに対するネットワーク・アクセスの可用性が高くなるように設計する必要があります。このためには、次のいずれもが Single

Point of Failure とならないようにする必要があります。

v IP サブシステム

v 単一ネットワーク

v 単一の NIC

Single Point of Failure となる IP サブシステムの除去ノード上の IP ソフトウェアに障害が発生した場合、そのノードとの間で IP 通信がすべて失われます。クラスター・ノードを直接リンクする非 Point-to-Point 接続を構成することによって可用性を高めることができます。この結果、クラスター用に代替のハートビート・パスが提供され、IP ソフトウェアが Single

Point of Failure となることが回避されます。

非 IP ネットワーク・ハートビート・リングは、ネットワーク競合問題が起きた場合に、クラスターが無効な状態にならないように保護します。ハートビートが発生する回線で大量のネットワーク競合がある場合、IP ネットワーク上でハートビート・パケットを運ぶ UDP パケットはドロップされます。

非 IP Point-to-Point ネットワークの使用については、この章のセクション『Point-to-Point ネットワークの計画』を参照してください。

関連資料:


Single Point of Failure となるネットワークの除去単一ネットワーク設定では、クラスターの各ノードが 1 つのネットワークにのみ接続され、クライアントから利用可能なサービス・インターフェースは各ノードに 1 つずつ設定されます。この設定では、ネットワークがクラスター全体の Single Point of Failure になるほか、各サービス・インターフェースも Single

Point of Failure になります。

次の図は、単一ネットワーク構成を示したものです。

計画 41

ネットワークが Single Point of Failure となるのを回避するには、HACMP がクラスター・ノード間に複数のパスを確保できるように複数ネットワーク設定を構成します。1 つのネットワークのみにクライアントが接続されている場合、クライアントにとってそのネットワークが Single Point of Failure になるという点に留意してください。複数ネットワーク設定では、1 つのネットワークに障害が発生しても残りのネットワークは、ノードを接続してクライアントにアクセスを提供するために引き続き動作可能です。

クラスター・ノード間でハートビートやその他の情報を運ぶために構成できるネットワークの数が多くなればなるほど、システムの可用性の度合いは高まります。非 IP Point-to-Point ネットワークは、多くの場合、代替ハートビート・パスとして使用されます。

次の図は、各クラスター・ノードへ複数のパスがあるデュアル・ネットワーク設定を示したものです。

注: 1 つの HACMP IP ネットワーク用の 2 つのインターフェースを構成するために使用されるデュアル・ポート・イーサネット・アダプターのホット・リプレースは、現在サポートされていません。

関連資料:



Point-to-Point ネットワークの計画クラスター・ノードを直接リンクする非 Point-to-Point 接続を構成することによって、可用性を高めることもできます。

この接続では、以下が提供されます。

v 単一の TCP/IP ベース・ネットワークを使用するクラスターの代替ハートビート・パス。これにより、TCP/IP ソフトウェアが Single Point of Failure となるのを防ぐことができます。

v クラスターの区分化に対する保護。

クラスター区分化について詳しくは、セクション『クラスターの区分化』を参照してください。

ハートビート・パスは、以下のタイプのネットワークで構成できます。

v 非 IP (RS232)

v ディスク・ハートビート (拡張コンカレント・モード・ディスク上)

v ターゲット・モード SSA

v ターゲット・モード SCSI

関連資料:

32ページの『クラスターの区分化』区分化はノード分離とも呼ばれ、ネットワークまたは NIC の障害により、クラスター・ノードが他のノードから分離されたときに発生します。

Point-to-Point ネットワークの配置の選択:

Point-to-Point ネットワークは、ネットワークの高可用性を保証する上で重要な役割を果たすため、2 つ以上のノードを含むクラスターで適切なパスを作成する接続を選択してください。

構成のタイプとそれぞれの利点および欠点について、次の表で簡単に説明します。

タイプ説明注意すべき考慮事項

メッシュクラスター内の各ノードを、クラスター内の他のすべてのノードと接続します。

最も堅固で信頼性の高い構成です。

リングまたはループ

各ノードを隣接しているノードと接続します。

同時に複数の障害が発生した場合は、クラスターが区分化される可能性があります。

スター 1 つのノードを他のすべてのノードに接続します。

同時に複数の障害が発生した場合は、クラスターが区分化される可能性があります。

ネットワーク・トポロジーで使用する Point-to-Point ネットワークのタイプは、利用可能なハードウェアや、クラスターの要件によって決定します。

シリアル Point-to-Point ネットワークの計画:

シリアル (RS232) ネットワークを計画するときは、いくつかの点に留意する必要があります。

以下に例を示します。

v 使用可能なシリアル・ポートが存在せず、ノードに対して計画した HACMP 構成で RS232 ネットワークを使用する場合は、構成にシリアル NIC カードが必要です。

v RSCT により、HACMP に対して定義された RS232 ネットワークはすべて、デフォルトの 38400 bps

で稼働します。tty ポートは 38400 bps で稼働するように AIX に対して定義する必要があります。

計画 43

RSCT でサポートされるボー・レートは、38400、19200、9600 bps です。

次の要件を満たす任意のシリアル・ポートを、ハートビートに使用できます。

v モデム接続用として、そのシリアル・ポートの使用がハードウェアでサポートされている。

v HACMP でそのシリアル・ポートを排他的に使用できる。

これらの条件を満たさないネイティブ・シリアル・ポートを備えたプロセッサーの例として、S70、S7A、および S80 と、F50、H50、および H70 のシリアル・ポート 1 および 2 があります。

一部の RS/6000® システムでは、ネイティブ・シリアル・ポートの使用がサポートされません。

注: HACMP は、ハードウェアおよびシステム・ソフトウェアがアプリケーションで利用可能にするシリアル・ポートをサポートしています。ポート間のモデムまたはエクステンダーを管理するのは、管理者の責任です。

シリアル・ポートが要件を満たしているかどうかを確認するには、ハードウェアの資料および HACMP のサポート情報を参照してください。

次の図は、リング構成の 4 つの RS232 ネットワークを示しています。4 つのノードを接続して、完全なクラスター非 IP 接続を提供しています。

IBM��ディスク

ノード A

シリアル・ネットワーク 1

c_serialn

et_

ring

ノード B ノード C


ノード D



ディスク・ハートビート・ネットワークの計画:

拡張コンカレント・モード・ボリューム・グループ内の共用ディスクはいずれも、Point-to-Point ハートビート接続をサポートしています。各ディスクは、2 つのノード間の 1 つの接続をサポートすることができます。この接続には、共用ディスク・ハードウェアが通信パスとして使用されます。

クラスター内のディスク・ハートビート・ネットワークには、以下が含まれます。

v 2 つのノード

ノードは、任意の数の 1 ディスク・ハートビート・ネットワークのメンバーになることができます。クラスターには、最大 256 の通信デバイスを含めることができます。

v 1 つのハートビート・ネットワークのみに関与する拡張コンカレント・モードのディスク

ディスク・ハートビートで使用するディスクを選択する際は、以下の点に留意してください。


ディスク・ハートビートの送受信に使用されるディスクは、拡張コンカレント・モード・ボリューム・グループのメンバーでなければなりません。ただし、ディスク・ハートビートに使用されるディスクに関連するボリューム・グループは、HACMP リソース・グループ内のリソースとして定義される必要はありません。つまり、ハートビートを使用可能にするディスクに関連する拡張コンカレント・ボリューム・グループは、HACMP のリソース・グループに属する必要はありません。

既存のボリューム・グループは、拡張コンカレント・モードに変換することができます。

v ディスクのピーク負荷時でのシークは毎秒 60 未満でなければなりません(ディスク・ハートビートは、一定間隔以内での書き込み/読み取りに依存します)。

AIX filemon コマンドを使用して、シーク・アクティビティーと物理ディスクの入出力負荷を決定します。

一般的に、書き込みキャッシュを備えていないディスク・ドライブの多くは、1 秒間に 100 回のシークを実行します。ディスク・ハートビートでは、2 から 4 シークを使用します。

RAID アレイ、または RAID アレイのサブネットのディスクでは、下限がさらに低くなる場合があります。ディスクまたはディスク・サブシステムがサポートする 1 秒あたりのシークの回数を確認するには、ディスクまたはディスク・サブシステムの製造元に問い合わせてください。

ただし、入出力負荷が著しく大きいディスクを使用する場合は、ディスク・ハートビート・ネットワークのタイムアウト・パラメーター値を大きくしてください。

v SDD がインストールされ、拡張コンカレント・モード・ボリューム・グループがアクティブ vpath デバイスに関連付けられているとき、ディスク・ハートビート通信デバイスは (関連 /dev/hdisk デバイスではなく) /dev/vpath デバイスを使用するよう定義されます。

v 共用ボリューム・グループをミラーリングする場合は、ディスク・ハートビート送受信用に少なくとも1 つのディスクを各ミラーに使用する必要があります。

リソース・グループに強制 varyon オプションを設定する場合は、この方法でハートビートをセットアップしてください。

関連資料:

106ページの『クォーラムおよび varyon を使用してデータの可用性を高める』クォーラムの構成とボリューム・グループの varyon により、ミラーリングされたデータの可用性を高めることができます。

関連情報:

コンカレント・アクセス環境における共用 LVM コンポーネントの管理

ターゲット・モード・ネットワークの計画:

Point-to-Point ハートビート通信では、ターゲット・モード SCSI およびターゲット・モード SSA もサポートされています。これらのタイプのネットワークにはそれぞれ、2 つのノード、共用ディスク、および(ディスク・タイプに応じて適切な) SCSI 通信または SSA 通信が含まれます。

Point-to-Point ネットワークの距離の拡張:

エクステンダー技術を使用することによって、HACMP Point-to-Point ネットワークをより長い距離に拡張することができます。

このようなテクノロジーには、以下のものがあります。

計画 45

ネットワーク・タイプ拡張メカニズム

SCSI SCSI バス・エクステンダー

SSA SSA 光エクステンダー

RS232v 光回線ドライバー

v 短距離モデム

v PTT 提供の RS232 回線

長距離 Point-to-Point ネットワーク・デバイスを計画するときは、運用許容範囲内でファイバー配線や銅配線などの接続を選択してください。

RS232 リンクを拡張するときは、デバイスについて次の点を確認してください。

v RS232 プロトコル (すべてのピン) を完全にサポートしていること。

v 最小の回線速度の 9600 bps (デフォルトは 38400 bps) で、必要な距離をサポートできること。

長距離に延長可能な一部の RS232 ネットワークでは、ボー・レートがデフォルトの 38400 bps 未満である必要があります。

障害検出率は、調整が必要になる場合があります。

関連資料:

57ページの『障害検出パラメーターの設定』ネットワーク・モジュールの重要な調整パラメーターの 1 つに、障害検出率があります。このパラメーターによって、接続の失敗が認識される速さが決定されます。

関連情報:

クラスター・トポロジーの管理

グローバル・ネットワークの構成:

同じタイプの物理ネットワークが複数あり、それぞれがクラスターの一部にのみまたがっている場合、これらのネットワークを 1 つのグローバル HACMP ネットワークにグループ化することができます。HACMP

は、異種ネットワーク間でハートビート・パケットを経路指定して、別のレベルのネットワーク冗長性を提供することにより、クラスターが区分化される確率を低減させます。

注: IP アドレス・テークオーバーを何らかの形式で使用するように構成されたネットワークは、グローバル・ネットワークに追加できません。

単一障害点となるネットワーク・インターフェース・カードの取り外しネットワーク・インターフェース・カード (NIC) は、ノードをネットワークに物理的に接続するものです。

ネットワークごとに NIC が 1 つしか構成されていない場合、その NIC は Single Point of Failure になる可能性があります。この問題を解決するには、接続先となるネットワークごとに最低 2 つの NIC を備えたノードを構成します。次の図では、各クラスター・ノードがそれぞれのネットワークへの接続を 2 つ持っています。


注: 1 つの HACMP IP ネットワーク用の 2 つのインターフェースを構成するために使用されるデュアル・ポート・イーサネット・アダプターのホット・リプレースは、現在サポートされていません。

関連情報:

クラスター・イベント時のリソース・グループの動作

ネットワーク・インターフェース機能:

単一のネットワークに対して複数の接続を使用するようにノードが構成されている場合、ネットワーク・インターフェースは HACMP で異なる機能を提供します。

これらの機能には、以下のものがあります。

v サービス・インターフェース

v ブート・インターフェース

クラスター・ネットワークへの IP エイリアスとして、ノード上に永続ノード IP インターフェースを定義することもできます。

サービス・インターフェース

サービス・インターフェースは、HACMP サービス IP ラベルを使用して構成された通信インターフェースです。このインターフェースは、各ネットワークに対する各ノードの 1 次 HACMP 接続として機能します。サービス IP ラベルは、以下のように使用されます。

v クライアントからアプリケーション・プログラムへのアクセス

v HACMP ハートビート・トラフィック

ブート・インターフェース

ブート・インターフェースは、サービス・インターフェースをバックアップする、HACMP ブート IP ラベルを使用した通信インターフェースです。クライアント・トラフィックはすべて、サービス・インターフェースを介して搬送されます。ブート・インターフェースはクライアント・アプリケーションから隠蔽され、内部の HACMP トラフィックのみが搬送されます。サービス・インターフェースに障害が発生した場合、

計画 47

HACMP は、サービス IP ラベルをブート・インターフェースに移動することができます。ブート・インターフェースを使用することで、Single Point of Failure となるネットワーク・インターフェースを除去します。

さらに、ノードに障害が発生した場合、リソース・グループのフォールオーバーを実行するときに、クラスターはそのサービス IP ラベル用のロケーションとして別のクラスター・ノード上のブート・インターフェースを使用できます。

ノードには、接続先のネットワークごとに 0 から 7 個のブート・インターフェースを設定できます。ノードが実際にサポートすることのできるブート・インターフェースの数は、使用するソフトウェア構成およびハードウェアの制約によって決まります。

永続ノード IP ラベル

永続ノード IP ラベルは、クラスター・ネットワーク上の特定のノードに割り当てることのできる IP エイリアスです。永続ノード IP ラベルには、次のような特徴があります。

v 常に同じノードに存在する (ノード・バインドである)。

v サービス IP ラベルまたはブート IP ラベルがすでに定義されている NIC に共存する。

v 対象ノードに対して追加の物理 NIC を取り付ける必要はない。

v いずれのリソース・グループにも属さない。

永続ノード IP ラベルを割り当てると、管理目的に使用できるノード・バインド・アドレスが提供されます。これは、永続ノード IP ラベルへの接続は、常にクラスター内の特定のノードに対して行われるためです。永続ノード IP ラベルは、各ノードの各ネットワークあたり 1 つずつ持つことができます。

HACMP のベスト・プラクティスの 1 つとして、各クラスター・ノードごとに 1 つの永続 IP ラベルを構成することをお勧めします。これは、レポート作成や診断のために HACMP クラスター内の特定のノードにアクセスする必要がある場合などに役立ちます。永続 IP ラベルを構成しておくと、個別の NIC 障害とは無関係に、HACMP がノード上のその永続 IP ラベルにアクセスできるという利点が得られます (ただし、ネットワーク上に予備の NIC があることが条件です)。

特定のネットワーク・ノードで構成した永続ノード IP ラベルは、ブート時に使用可能になり、そのノードで HACMP がシャットダウンされても構成を維持します。

永続ノード IP ラベルは、次のタイプの IP ベース・ネットワーク上に作成することができます。



v FDDI

v ATM LAN エミュレーター

v Infiniband

永続ノード IP ラベルは、ATM Classical IP またはシリアル・クラスター・ネットワーク上には構成できません。

永続ノード IP ラベルが構成されている場合に、HACMP が障害にどのように応答するかを、次に示します。

v サービス IP ラベルが構成されている NIC に障害が発生した場合、この NIC 上に永続ラベルも定義されているときは、この永続ラベルはサービス IP ラベルがフォールオーバーするのと同じブート・インターフェースにフォールオーバーします。


v 特定のノード上でクラスター・ネットワーク上のすべての NIC 障害が発生した場合は、永続ノード IP

ラベルを使用できなくなります。永続ノード IP ラベルは、常に同じネットワークおよび同じノードに維持され、クラスターのノード間で移動することはありません。

関連情報:


IP エイリアスによる IP アドレス・テークオーバー:

HACMP は、IP エイリアスによる IPAT を使用して、サービス IP アドレスの高可用性を維持します。

ノード上で HACMP を始動すると、HACMP に定義されているいずれかのブート・インターフェース上にサービス IP ラベルのエイリアスが作成されます。そのインターフェースに障害が発生した場合、同じネットワーク上で別のインターフェースが使用可能であれば、そのインターフェースにサービス IP ラベルのエイリアスが作成されます。この構成では、ハードウェア・アドレス・テークオーバー (HWAT) は不可能です。IP エイリアスによる IPAT を使用するには、ネットワークが無償 ARP をサポートしていなければなりません。

永続ノード IP ラベルに対するサブネットの考慮事項

クラスター・ネットワークで永続ノード IP ラベルを構成する場合、永続 IP ラベルが関連付けられているIP アドレスは、インターフェースを共有するサービス・アドレス以外のサブネットに存在している必要があります。ノードごとにインターフェースを 1 つだけ持つネットワークは、別個のサブネットが不要です。

場合によっては、サービス IP ラベルと同じサブネット上に永続 IP ラベルを構成する必要があります。この場合、いずれかのアドレスから送信されるネットワーク・パケットでの障害を回避するには、サービスIP エイリアスの配布設定の構成を考慮します。この設定により、VPN ファイアウォール外部接続要件に適した配布設定のタイプを構成できます。

注: NFS ファイルシステムを構成する計画を立てる場合、サブネット考慮事項は異なります。詳しくは、『NFS クロス・マウントおよび IP ラベル』を参照してください。

関連資料:

114ページの『NFS クロス・マウントおよび IP ラベル』NFS クロスマウントを使用可能にするため、各クラスター・ノードは NFS クライアントとして動作することができます。これらの各ノードは、NFS サーバー・ノードのサービス IP ラベルに対する有効な経路を持っている必要があります。つまり、NFS クロスマウントを使用可能にするためには、IP ラベルがクライアント・ノード上に存在する必要があり、またこの IP ラベルは、NFS サーバー・ノードのサービス IP

ラベルと同じサブネット上に構成されている必要があります。


50ページの『IP エイリアスによる IP アドレス・テークオーバーの計画』AIX でサポートされている IP エイリアスを使用するネットワーク機能を使用すると、IP アドレス・テークオーバーを特定のタイプのネットワーク上に構成できます。NIC に IP エイリアスを割り当てると、同じネットワーク・インターフェースに複数の IP ラベルを作成できます。

IP 交換による IP アドレス・テークオーバー:

IP アドレス・テークオーバーは、IP 交換を使用するように設定できます (これを行うには、SMIT で、IP

エイリアスによる IPAT のオプションを無効にします)。

計画 49

この構成では、あるノードに障害が発生した場合は、サービス IP ラベルをリソース・グループのテークオーバーの一部として別のノードがテークオーバーします。このサービス IP ラベルは、(該当ネットワーク上にある) テークオーバー・ノードのいずれかの非サービス・インターフェースに、非サービス IP ラベルの代わりに構成されます。

ハードウェア・アドレス・テークオーバー (HWAT) および IP 交換による IPAT

この構成では、代替ハードウェア・アドレスを使用してハードウェア・アドレス・テークオーバー(HWAT) がサポートされます。HWAT を使用しない場合は、必要に応じて IPAT 後およびフォールバック後に、クライアントおよびネットワーク機器によって ARP キャッシュが更新されることを確認してください。

永続ノード IP ラベルに対するサブネットの考慮事項

IP 交換による IP アドレス・テークオーバーを実行するように構成されているクラスター・ネットワークで永続ノード IP ラベルを構成する際には、使用するサブネットが、サービス IP ラベルで使用されるサブネットか、またはそのノード上のネットワークに固有なサブネットのどちらかでなければなりません。

IP エイリアスによる IP アドレス・テークオーバーの計画AIX でサポートされている IP エイリアスを使用するネットワーク機能を使用すると、IP アドレス・テークオーバーを特定のタイプのネットワーク上に構成できます。NIC に IP エイリアスを割り当てると、同じネットワーク・インターフェースに複数の IP ラベルを作成できます。

HACMP では、AIX の無償 ARP をサポートする次のネットワーク・タイプを使用すれば、IP エイリアスによる IPAT を使用できます。



v FDDI

v Infiniband

注: IP エイリアスによる IPAT は、ATM ネットワークではサポートされていません。

IP エイリアスによる IP アドレス・テークオーバー中に、NIC 間で IP ラベルが移動された場合、ターゲット NIC は新しい IP ラベルを IP エイリアスとして受け取り、元の IP ラベルとハードウェア・アドレスを維持します。

IP エイリアスによる IPAT 用にネットワークを構成すると、HACMP のネットワーク構成が簡略化されます。NIC 用にサービス・アドレス、および 1 つ以上のブート・アドレスを構成します。

IP エイリアスによる IPAT での IP ラベルの割り当てIP エイリアスによる IP アドレス・テークオーバーは、IP アドレスの高可用性を維持するための代替方式です。IP エイリアスによる IP アドレス・テークオーバーは、古いテークオーバー・テクノロジーより高速であり、かつ中断頻度が少ない方式です。また、この方式はデフォルト・モードです。

IP エイリアスによる IP アドレス・テークオーバーの計画を立てる際は、以下の情報を検討してください。

v 各ネットワーク・インターフェースでは、ブート IP ラベルを HACMP に対して定義する必要があります。HACMP に対して定義されたインターフェースを使用して、サービス IP アドレスの高可用性を維持します。


v ハードウェア・アドレス・テークオーバー (HWAT) は、IP エイリアスによる IP アドレス・テークオーバーを使用したネットワークでは構成できません。

v 以下のサブネット要件は、同じネットワークに接続されている 1 つのノードに複数のインターフェースがある場合に適用されます。

– すべてのブート・アドレスが、異なるサブネット毎に定義される必要があります。

– サービス・アドレスは、定義されたすべてのブート・アドレスおよび永続アドレスとは異なるサブネットに存在する必要があります。

注: これらの要件により、同一サブネットへの複数の経路を許可するためにアプリケーション・トラフィックが障害のあるインターフェースに送信されてしまう、AIX オペレーティング・システムの IP 経路ストライピング機能を回避することができます。これらの要件は、イーサネット集約またはイーサチャネルを使用する単一論理インターフェースに結合された複数のインターフェースの場合には適用されません。

v IP エイリアスによる IP アドレス・テークオーバー用に構成されたサービス・アドレス・ラベルは、すべての非コンカレント・リソース・グループに含めることができます。

v 複数のサービス・ラベルは、1 つのインターフェース上にエイリアスとして共存できます。

v HACMP ネットワークでは、すべての IP ラベル用のネットマスクが同じでなければなりません。

v エイリアスを使用するサービス IP ラベルとエイリアスを使用しないサービス IP ラベルを、同一のリソース・グループ内に混在させることはできません。

v 複数のサービス・ラベルと永続ラベルがある場合、HACMP は、すべての使用可能なネットワーク・インターフェースにまたがりこれらのラベルの均等な配布を試みます。永続エイリアスとサービス・エイリアスが同じインターフェースに常にマップされるように、ロケーション設定を指定することができます。サービス・ラベルの詳細については、サービス IP ラベル・エイリアスの配布設定を参照してください。

ノード上のブート時アドレス (システムのリブートから HACMP ソフトウェアの始動までの間に AIX によって割り当てられるベース・アドレス) は、ブート時アドレスとして HACMP に対して定義されます。HACMP は、ユーザーが最初にクラスターを構成するときに、ブート時アドレスを自動的にディスカバーおよび構成します。HACMP ソフトウェアがノードで開始されると、ノードのサービス IP ラベルは、ブート時アドレスとして定義される NIC の 1 つにエイリアスとして追加されます。サービス IP をホストする NIC に障害が起こった場合、HACMP は、同じノード上の別のアクティブ・ブート NIC へのサービスIP の移動を試みます。

ノードのフォールオーバー・イベント時に、移動されるサービス IP ラベルは、ターゲット・ノードのNIC に、その NIC にすでに構成されている可能性がある他のすべてのサービス・ラベルに加えて、エイリアスとして配置されます。

例えば、ノード A で障害が発生した場合、HACMP は、ノード B へのすべてのリソース・グループの移動を試みます。リソース・グループにサービス IP アドレスが含まれている場合、HACMP は、サービスIP アドレスをノード B の適切な NIC にエイリアスとして配置します。ノード B の NIC にある他のすべての既存のラベルには影響がありません。したがって、ノード B の NIC は、ノード A にあったサービス・アドレスに送信するために使用したクライアント・トラフィックを受信できるようになります。あとで、ノード A は再始動時に、そのブート時アドレスで始動し、ノード B に障害が起こった場合にサービス IP をホストすることが可能です。要求されたサービス IP ラベルをノード B が解放すると、そのサービス IP ラベルのエイリアスがノード B から削除されます。ノード A は、適切なネットワークのブート時アドレス・インターフェースの 1 つに、そのサービス IP ラベルをエイリアスとして再び配置します。

計画 51

IP エイリアスによる IPAT を使用する場合は、使用可能なすべてのブート・インターフェースを使用してサービス IP ラベルが獲得されます。サービス IP ラベルをホストできる複数のインターフェースが存在している場合は、インターフェースに現在ある IP ラベルの数に従って、インターフェースが選択されます。サービス IP ラベルが複数獲得されていて、使用可能なインターフェースが複数存在している場合は、使用可能なすべてのインターフェースにサービス IP ラベルが配布されます。

ifconfig delete コマンドを使用してブート時アドレスを除去すると、インターフェースに動作中のエイリアス・サービス IP ラベルがある場合でも、トポロジー・サービスはローカル NIC の障害を検出します。これは、ハートビート用にモニターされているブート時アドレスを利用できなくなるためです。 ifconfig コマンドを使用して、アクティブ・クラスター内でアドレスを操作してはなりません。

注: クラスターで NFS ファイルシステムを設定し、「IP エイリアスによる IPAT」を使用する予定の場合は、セクション『NFS クロス・マウントおよび IP ラベル』を参照してください。

関連資料:

112ページの『HACMP での NFS クロスマウント』NFS クロスマウントは HACMP 固有の NFS 構成であり、この構成では、クラスターの各ノードが、NFS

サーバーおよび NFS クライアントの両方の役割を果たすことができます。ノードからファイルシステムをエクスポートしている間は、エクスポートしているノードを含むすべてのノード上のファイルシステムはNFS マウントされている状態になります。他のノードから別のファイルシステムをエクスポートし、そのファイルシステムを全ノード上でマウントすることも可能です。

サービス IP ラベル・エイリアス配置の計画IP エイリアスによる IPAT を使用する場合は、HACMP に構成されるサービス IP ラベルの配置に関する配布設定を構成できます。

HACMP では、サービス IP ラベル・エイリアスの配布設定を指定できます。これらは、HACMP リソース・グループの一部であるサービス IP ラベルであり、IP エイリアスによる IPAT ネットワークに属しています。

サービス IP ラベル・エイリアスの配布設定は、クラスターのノード上の物理ネットワーク・インターフェース・カードでサービス IP ラベル・エイリアスの配置を制御するのに使用されるネットワーク全体の属性です。

次のクラスター要件に対応するには、IP エイリアスの配布設定を使用する必要があります。

v ファイアウォールの考慮事項

v VLAN を使用するクラスター構成 (アプリケーションが特定のネットワーク・インターフェースからパケットを受信する必要がある場合)

v クラスター内の IP ラベルの配置に関する特定の要件

サービス IP ラベル・エイリアスの配布設定の仕組み

サービス IP ラベル・エイリアスの配布設定を構成すると、以下のようになります。

v ノード上ですでに割り当てられた永続 IP ラベルを考慮に入れながら、クラスターのサービス IP ラベルのロード・バランシングをカスタマイズできます。

v 指定した設定に従って、HACMP がエイリアス・サービス IP ラベルを再配布できるようにします。

v VPN ファイアウォール外部接続要件に適した配布設定のタイプを構成できます。

v サービス IP ラベルが別のネットワーク・インターフェースに移行しても、HACMP では、指定した配布設定に従って、ラベルが継続して割り当てられます。つまり、配布設定は、始動時、フォールオーバ


ーやフォールバックなどの後続クラスター・イベント時、または同じノード上のインターフェースの変更時でも維持管理されます。例えば、ラベルが同じインターフェースにマップされるよう指定すると、最初に構成されたサービス IP ラベルが別のノードに移行しても、ラベルは同じインターフェース上にマップされたままです。

v 受け入れ可能なネットワーク・インターフェースが使用可能である限り、配布設定はクラスター内で適用されます。HACMP は、設定を満たすことができない場合でも、サービス IP ラベルを常にアクティブ状態に維持します。

サービス IP ラベル・エイリアスの配布のタイプサービス IP ラベル・エイリアスの配置は、SMIT で異なる配布設定を指定することができます。

このようなタイプには、以下のものがあります。

配布設定のタイプ説明

アンチコロケーションこれはデフォルトです。HACMP は、「最小にロードされる」選択プロセスを使用して、すべてのブート IP ラベルに対しすべてのサービス IP ラベル・エイリアスを配布します。

コロケーション HACMP は、すべてのサービス IP ラベル・エイリアスを同じネットワーク・インターフェース・カード (NIC) に割り当てます。

永続アンチ・コロケーション HACMP は、永続 IP ラベルをホスティングしていないすべてのアクティブな物理インターフェースに対し、すべてのサービス IP ラベル・エイリアスを配布します。HACMP は、他のネットワーク・インターフェースが使用可能でない場合のみ、永続ラベルをホスティングしているインターフェースにサービス IP ラベル・エイリアスを配置します。

永続 IP ラベルを構成していない場合、HACMP では永続配布設定付きのアンチ・コロケーションを選択できますが、警告が発行され、デフォルトで通常のアンチ・コロケーション設定が使用されます。

永続コロケーションすべてのサービス IP ラベル・エイリアスは、永続 IP ラベルをホストしている同じ NIC に割り当てられます。このオプションは、1 つのインターフェースのみが外部接続に承認されている VPN

ファイアウォール構成で有効であり、すべての IP ラベル (永続ラベルおよびサービス・ラベル) が同じインターフェース・カードに割り当てられる必要があります。

永続 IP ラベルを構成していない場合、HACMP では永続配布設定付きのコロケーションを選択できますが、警告が発行され、デフォルトで通常のコロケーション設定が使用されます。

次の規則が、配布設定に適用されます。

v 設定を満たすために使用可能なインターフェースが不十分である場合、HACMP は、サービス IP ラベル・エイリアスおよび永続 IP ラベルを既存のアクティブなネットワーク・インターフェース・カードに割り当てる。

v 永続 IP ラベルを構成していない場合、HACMP では永続コロケーションおよび永続配布設定付きのアンチ・コロケーションを選択できるが、警告が発行され、デフォルトで通常のコロケーションまたはアンチ・コロケーション設定が使用される。

v IP ラベルの配布設定は動的に変更できる。新しい選択内容は、後続のクラスター・イベント時にアクティブになる。HACMP は、設定が変更された時点では、現在アクティブなサービス IP ラベルを再配置することによって処理に割り込むことはない。

1 つのサービス IP ラベルに障害が発生し、別のサービス IP ラベルが同じノード上で使用可能な場合、HACMP は、同じノード上の別のネットワーク・インターフェース・カードにサービス IP ラベル・エイリアスを移行することによって、サービス IP ラベル・エイリアスを回復します。このイベント中、指定した配布設定は有効のままです。

関連情報:

計画 53

管理ガイド

サイト固有のサービス IP ラベルの計画ノードやサイト間を移動できるリソース・グループに関連付けられた、複数のノード上で構成可能なサービス IP ラベルを使用できます。

あるサイトで有効な IP アドレスが、サブネットの問題のために他のサイトでは有効ではない可能性があるため、複数のノード上で構成可能なサービス IP ラベルを特定のサイトに関連付けることができます。サイト固有のサービス IP ラベルは HACMP で構成され、XD タイプ・ネットワークの有無にかかわらず使用できます。このラベルは、リソース・グループと関連付けられており、関連付けられたサイトでそのリソース・グループがオンライン・プライマリー状態の場合のみアクティブになります。

IP 交換による IP アドレス・テークオーバーの計画デフォルト・オプションを無効にして、IP エイリアスによる IP アドレス・テークオーバーを使用するネットワークを構成すると、IP 交換による IP アドレス・テークオーバーを使用できます。この方法では、特定のネットワークの 1 つのノードにつき、1 つのサービス IP ラベルと 1 つ以上の非サービス IP ラベルが使用されます。

ブート時に、AIX は各 NIC に構成された IP アドレスを提供します。HACMP は始動時に、オンラインにするリソース・グループ用の非サービス IP ラベルをサービス IP ラベルで置き換えます。

サービス IP ラベルをホストしている NIC に障害が発生し、ノード上のそのネットワーク用に別の非サービス・インターフェースがある場合、HACMP はサービス IP ラベルを維持するために、その非サービスIP ラベルをサービス IP ラベルで置き換えます。

ネットワーク上の各ノード (クライアント・ノードを含む) は、各 IP アドレスを特定のハードウェア(MAC) アドレスにマップする ARP キャッシュを保持しています。HACMP がサービス IP ラベルとそれに関連付けられたアドレスを別の NIC に移したあとは、サービス・アドレスをターゲット NIC のハードウェア・アドレスと正確に一致させるために、これらの ARP キャッシュ・エントリーを更新する必要があります。

この再構成が行われた場合、AIX は無償 ARP を実行します。これにより、promiscuous listen モードをサポートするクライアントおよびネットワーク・デバイスは、自分の ARP キャッシュを更新できるようになります。クライアントが promiscuous listen モードをサポートしていない場合は、clinfo を使用してクライアントの ARP キャッシュを更新するか、またはハードウェア・アドレス・テークオーバー (HWAT)

を使用します。

すべての非コンカレント・リソース・グループを、IP 交換による IPAT ネットワークの IP ラベルを使用して構成できます。

IP 交換による IPAT ネットワークを使用していて、非コンカレント・リソース・グループの構成を計画している場合は、リソース・グループの始動に関するノード配布ポリシーの使用についても考慮してください。

IP 交換による IPAT を使用するハードウェア・アドレス・テークオーバー

ネットワークのタイプによっては、ARP キャッシュの更新を処理できません。また、クライアントおよびネットワーク・デバイスには、promiscuous listen をサポートしていないものもあります。こうした ARP

キャッシュに関する問題を解消するために、HACMP は AIX のハードウェア・アドレス・テークオーバー(HWAT) 機能を使用します。HWAT は、サービス IP ラベルだけではなく、ターゲット NIC の基本ハー


ドウェア (MAC) アドレスも移動することで、基本ハードウェア・アドレスがサービス IP ラベルと常に同じ場所に存在するようにします。このように IP アドレスとハードウェア・アドレスの両方が移動されるので、ノード上の ARP キャッシュの正確性は維持されます。

注: ギガビット・イーサネット・アダプターのフロー制御をオフにしてください。HACMP のフォールオーバー後にネットワークに関する問題が発生する可能性があります。

関連資料:

128ページの『ノード配布ポリシー』始動時にノード配布ポリシーを使用するように、リソース・グループの始動動作を構成できます。このポリシーにより、このポリシーが有効になっている 1 つのリソース・グループのみがノード上で始動時に獲得されるようになります。

70ページの『代替ハードウェア・アドレスの選択』このセクションでは、イーサネット、トークンリング、および FDDI のネットワーク・インターフェース・カードのハードウェア・アドレッシングに関する情報を説明します。NIC に定義する代替ハードウェア・アドレスは、製造元がその NIC に割り当てているデフォルトのハードウェア・アドレスと同じ形式にする必要があります。

関連情報:


他のネットワーク条件の計画ほとんど通常のネットワーク計画の考慮事項には、HACMP 環境でのネーム・サービスの構成と、クラスター・モニターおよび障害検出のセットアップが含まれます。

NIS および DNS とともに HACMP を使用障害の発生後に、ネットワークおよびインターフェースに関する問題のトラブルシューティングに使用する特定のコマンドを実行するには、IP 検索により、特定の IP ラベルに関連付けられている IP アドレスを判別する必要があります。

NIS または DNS が動作中の場合、IP 検索では、名前およびアドレス解決用のネーム・サーバー・システムがデフォルトとして使用されます。ただし、障害が発生したインターフェースからネーム・サーバーにアクセスした場合は、要求が完了せず、最終的にタイムアウトします。このため、HACMP のイベント処理速度が著しく低下する可能性があります。

クラスター・イベントが正常に素早く完了するように、HACMP は、サービス IP ラベルのスワップ中に次の AIX 環境変数を設定して、NIS または DNS によるホスト名解決を無効にします。

NSORDER = local

このため、各クラスター・ノードの /etc/hosts ファイルには、すべてのクラスター・ノードに関してHACMP で定義されたすべての IP ラベルが記述されている必要があります。

非 HACMP プロセスから送信された DNS 要求

NIS または DNS ホスト名解決の無効化は、HACMP イベント・スクリプト環境のみで行います。HACMP

は、サービス IP ラベルを割り当てるとき、およびインターフェースの IP ラベルをスワップするときに、NSORDER 変数を local に設定します。

その他のプロセス (例えば、DNS IP アドレス解決を必要とする HACMP 外部のアプリケーション) では、デフォルトのネーム・レゾリューションに関するシステム設定を引き続き使用します。これらのプロセ

計画 55

スが IP 検索を要求した場合、HACMP のネットワーク・インターフェース再構成イベント中は、プロセスが外部のネーム・サーバーに接続できないことがあります。HACMP のネットワーク・インターフェース再構成イベントの完了後は、DNS への要求は成功します。

クラスターのモニターサポートされている各クラスター・ネットワークには、それぞれ対応するクラスター・ネットワーク・モジュールがあります。これらのモジュールは、そのクラスター・ネットワークへのすべての入出力をモニターします。クラスター内では、ネットワーク・モジュールが相互に接続を維持しています。各クラスター・ノード上のクラスター・マネージャーは、これらの接続を介して相互にメッセージを送信します。

各ネットワーク・モジュールは、クラスター内の他のネットワーク・モジュールとの間で、周期的ハートビート・メッセージを送受信します。これらのハートビート・メッセージの送受信は、以下の目的で実行されます。

v インターフェースのモニター

v クラスター・ピアへの接続の確認

v 接続に障害が発生した場合の報告

現在、HACMP のネットワーク・モジュールは、以下のタイプのネットワークによる通信をサポートしています。

v シリアル (RS232)

v ディスク・ハートビート (拡張コンカレント・モード・ディスクを使用)

v ターゲット・モード SCSI

v ターゲット・モード SSA



v FDDI

v ATM

v Infiniband

HACMP での VPN ファイアウォール・ネットワーク構成の計画HACMP では、サービス IP ラベル・エイリアスの配布設定を指定できます。これらは、HACMP リソース・グループの一部であるサービス IP ラベルであり、IP エイリアスによる IPAT ネットワークに属しています。

一部の VPN ファイアウォール構成では、一度に 1 つの NIC に対してのみ、外部接続を許可します。ご使用のファイアウォールがこのように構成されている場合は、HACMP のすべてのサービス IP ラベルおよび永続 IP ラベルを同じインターフェースに割り当ててください。

HACMP で IP ラベルを管理してこのような VPN ファイアウォールの要件を満たすには、次のようにしてください。

v クラスターの各ノードに永続 IP ラベルを指定します。永続 IP ラベルは、選択されたネットワークで使用可能なインターフェースにマッピングされます。

v サービス IP ラベルを含むネットワークで IP エイリアスによる IPAT を使用します (デフォルト)。サービス IP ラベルをリソース・グループのリソースとして構成する場合、「Configure HACMP


Networks (HACMP ネットワークの構成)」SMIT パネルで「Enable IP Address Takeover via IPAliases (IP エイリアスによる IP アドレス・テークオーバーを使用可能にする)」フィールドを「Yes(はい)」に設定します。

v サービス IP ラベルを含むネットワークに永続配布設定付きのコロケーションを指定します。これにより、すべてのサービス IP ラベル・エイリアスが、永続 IP ラベルをホストしている同一物理インターフェースに割り当てられます。

関連資料:


関連情報:

管理ガイド

障害検出パラメーターの設定ネットワーク・モジュールの重要な調整パラメーターの 1 つに、障害検出率があります。このパラメーターによって、接続の失敗が認識される速さが決定されます。

障害検出率は、次の 2 つの要素で構成されます。

v 障害サイクル (cycle)。障害検出の前に喪失したハートビートの数です。

v ハートビート・レート (hbrate)。ハートビート間隔 (単位: 秒) です。

障害の検出に必要な時間は、次の公式で計算できます。

(ハートビート・レート) X (障害サイクル) X 2

障害検出率は、ネットワーク・モジュールに応じて変更することが可能です。次の 2 つの変更方法があります。

v 事前設定レートを「slow (低速)」、「normal (通常)」、「fast (高速)」から選択する。

v 実際の要素である cycle または hbrate を変更する。

ネットワークのタイプごとに事前設定値を計算すると、適切な結果を得られます。障害検出率を変更する場合は、事前設定値 (「Slow (低速)」、「Normal (通常)」または「Fast (高速)」) を使用します。障害検出率の要素のカスタマイズについては、この章のセクション『障害検出率の変更』を参照してください。

以下の場合は、障害検出率の変更を検討する必要があります。

v フォールオーバー時間を短縮する。

v ノードの CPU 飽和状態により、誤ったテークオーバーが発生しないようにする。

関連資料:

59ページの『障害検出率の変更』ネットワーク・モジュールの障害検出率を変更する場合は、いくつかの考慮事項に留意してください。

フォールオーバー時間の短縮:

障害検出率のデフォルト設定には、最適値が取られるのが一般的です。障害検出を迅速化すれば、フォールオーバーを若干速めることができます。しかし、イベント処理に追加するカスタマイズの量およびタイプは、フォールオーバーの合計時間に対してはるかに大きな影響を及ぼします。ネットワーク・モジュールの障害検出速度を変更するかどうかを決定する前に、システムをテストする必要があります。

計画 57

ノード・フォールオーバー時間の短縮:

HACMP では、ノード障害が確実に検出されるとともに、ノード障害がクラスター全体にわたって認識されるまでに要する時間が短縮されます。

HACMP は、ディスク・ハートビートを使用して切断メッセージを共用ディスク上に配置します。これにより、隣接ノードは障害の発生したノードを 1 ハートビート期間 (hbrate) 内に認識できます。このディスクを共用するリモート・ノードはこのメッセージを受信し、ノードに障害が発生したことをブロードキャストします。ノード障害イベントを直接ブロードキャストすることで、喪失したハートビートを待つ場合よりも、クラスター全体で障害が認識されるまでの所要時間が大幅に短縮されます。その結果、HACMP はクリティカル・リソースをより迅速にテークオーバーできます。

障害検出率「Fast (高速)」、「Normal (通常)」、「Slow (低速)」には、それぞれ 1 秒、2 秒、3 秒という hbrate が含まれています。したがって、ディスク・ハートビートを使用している場合は、ノードがダウンしているかどうかを隣接ノードが判断するのに要する時間は最長で 1 秒、2 秒、または 3 秒になり、その後ただちに他のクラスター・ノードがその障害を認識します。

例えば、障害の検出に要する時間を計算するために、次の式を使用するとします。

(ハートビート・レート) X (障害サイクル) X 2

ハートビート・レートが 2 秒で障害サイクルが 12 の場合、アダプター障害検出時間は 48 秒となりますが、これに対して迅速なノード障害検出方法の場合の所要時間は 4 秒です。

関連情報:

ネットワーク・モジュールの障害検出率の変更

誤ったテークオーバーの回避:

HACMP が IP ネットワークおよび Point-to-Point ネットワークでハートビートを送信するのに十分なCPU リソースを取得できない場合、同じクラスター内の他のノードは、そのノードに障害が発生したと見なして、そのノードのリソースのテークオーバーを開始します。このテークオーバー・プロセスが開始された後は、この障害ノードがアクティブ状態に復帰してこれらのリソースの使用を再開しないことが重要です。

正常なテークオーバーを確実に実施するために、HACMP ではデッドマン・スイッチが用意されています。これは、他のノードがノード障害イベントの処理を開始する 1 秒前に、応答しないノードを停止するように構成されています。デッドマン・スイッチは、最も低速なネットワークの障害検出パラメーターを使用して、ノードを停止するポイントを決定します。したがって、障害検出までの時間を増やすことにより、HACMP に CPU サイクルを提供するための時間を、ノードに対してより多く与えることができます。ノードが時折飽和状態となる場合、このことは重要となります。

ノードが飽和状態になるのを回避するには、AIX 調整パラメーターを変更します。

障害検出パラメーターは、これらの他の手段をインプリメントしてから変更してください。

関連情報:

ネットワーク・モジュールの障害検出率の変更

クラスター・パフォーマンス調整の構成


障害検出率の変更:

ネットワーク・モジュールの障害検出率を変更する場合は、いくつかの考慮事項に留意してください。

これらの考慮事項には、以下のものがあります。

v 障害検出は、2 つのノードをリンクする最も高速なネットワークに依存します。

v ネットワークの障害検出率は、それぞれのネットワークの特性によって異なります。

v ネットワーク・モジュールを変更する前に、実際のノード障害が他のノードによって検出され、それによるテークオーバーを開始するまでの経過時間を考慮しておく必要があります。

v ハートビート・レートを速くすると、特に、ビジーなネットワークで誤った障害検出が起きやすくなります。例えば、高ネットワーク・トラフィックのバーストによってハートビートが遅れることがあるため、正常に動作しているノードがクラスターから誤って排除される恐れがあります。また、ハートビート・レートが高くなると、ネットワークの負荷も大きくなります。ネットワークが非常にビジーで、障害検出のエラーが発生する場合は、ネットワーク・モジュールの障害検出率を低速に変更して、エラーが起きないようにします。

v 障害検出率をカスタマイズする前に、「Failure Detection Rate (障害検出率)」を「normal (通常)」から「slow (低速)」(または「fast (高速)」) に変更します。カスタマイズするには、hbrate をユーザー定義値に変更し、cycle 値を調整します。調整パラメーターをユーザー定義値に変更するには、SMIT パネルを使用します。

v 個々のネットワークの障害検出率は、所定のネットワークに対してクラスター全体で等しく設定する必要があります。変更は、クラスター・ノード間で同期させる必要があります。新しい値は、動的再構成(DARE) 中に有効になります。

v 障害検出時間に影響する値 (障害サイクル (FC)、ハートビート・レート (HB)、また障害検出率) を変更した場合、これらのパラメーターに対する新しい値は、次のような出力メッセージとして画面に送信されます。

v SUCCESS: Adapter Failure Detection time is now FC * HB * 2 or SS seconds (成功: アダプター障害検出時間は現在 FC * HB * 2 または SS 秒です)

ネットワーク猶予時間の設定ネットワーク猶予期間とは、IP アドレス・テークオーバー (IPAT) 操作中に、ネットワークについてノードの到達可能性が計算されない時間枠です。

これは、ノードの NIC が IPAT を実行中に、そのノードがダウンしたと解釈されないようにするために使用します。猶予期間値には、インターフェースが新規アドレスで再構成されるためにかかる時間、およびそのインターフェース・メンバーシップ・グループに再結合するために要する時間を含める必要があります。IPAT を HWAT と共に使用すると、通常、操作の完了に要する時間が長くなるため、十分に大きな猶予期間値を使用する必要があります。

関連情報:

調整パラメーターの事前定義値への変更

2 ノード・クラスターのサービス・アダプター障害の識別特定の条件下で単一アダプター・ネットワークになる可能性があるクラスター構成では、HACMP によってアダプター障害を正確に判断することが難しい場合があります。これは、RSCT トポロジー・サービスが、パケット・トラフィックを単一アダプターを介して強制的に送信し、そのアダプターの正常な動作を確認することができないためです

計画 59

そのネットワーク・アダプターの使用率が高い場合は、この欠点はあまり影響はありません。この場合、RSCT トポロジー・サービスからの働きかけがないと、到着パケット・カウントはサービス・アダプター上で増加し続けます。

RSCT トポロジー・サービスのネットワーク・モニター部分である netmon の拡張を使用すると、サービス・アダプター障害をより正確に判断できます。この機能は、ネットワークごとにサービス・アダプターを1 つ必要とする構成で使用できます。

netmon.cf 構成ファイルを作成して、ICMP ECHO 要求を送信できるネットワーク・アドレスを追加できます。

このファイルは、クラスター始動時に必要です。RSCT トポロジー・サービスは、初期化中に netmon.cf構成ファイルをスキャンします。アダプター機能を確認するために、netmon からネットワークにアクセスする必要がある場合は、ICMP ECHO 要求が各 IP アドレスに送信されます。各アドレスに要求を送信したあと、netmon は、到着パケット・カウントを確認したうえで、アダプターで障害が発生しているかどうかを判断します。

netmon の機能について詳しくは、「IZ01331: NEW NETMON FUNCTIONALITY TO SUPPORT HACMP

ON VIO at Fix Central」を参照してください。

関連資料:

61ページの『netmon.cf ファイルの作成』netmon.cf ファイルは、すべてのクラスター・ノードの /usr/es/sbin/cluster ディレクトリーに置く必要があります。

netmon.cf ファイルに記述する IP アドレスの選択netmon.cf ファイルに記述する IP アドレスを選択するためのガイドラインは、ローカル・インターフェースがサービス・インターフェースと非サービス・インターフェースのどちらであるかで異なります。

ローカル・インターフェースがサービス・インターフェースの場合は、次のインターフェースとのPoint-to-Point 通信を通じて、そのインターフェースが作動可能であることが確認されます。

v 同じ論理ネットワーク上にある既存のリモート・サービス・インターフェース

v 同じ論理ネットワーク上にある既存のローカル非サービス・インターフェースの 1 つ

v netmon.cf ファイルの IP アドレス/ホスト名

ローカル・インターフェースが非サービス・インターフェースの場合は、次のインターフェースとのPoint-to-Point 通信を通じて、そのインターフェースが作動可能であることが確認されます。

v 同じ論理ネットワーク上にある既存のリモート非サービス・インターフェース

v 同じ論理ネットワーク上にある既存のローカル・インターフェースの 1 つ

v netmon.cf ファイルの IP アドレス/ホスト名

netmon.cf ファイルには、クラスター構成に含まれていないリモート IP ラベル/アドレスのうち、HACMP

インターフェースからアクセス可能なものを指定する必要があります。ルーターを使用することもできます。

RSCT netmon が netmon.cf で指定されているアドレス全てに PING できるように、コマンドラインから発行された次の PING に対して応答する必要があります。

注: 以下のコマンドは、「IP エイリアスを使用するハートビート」機能を使用する (Boot IP address はsmit chinet でインターフェース上に構成された IP アドレスである) 場合には適用されません。


# ping -S Boot IP address IP addr in netmon.cf

netmon.cf ファイルの作成netmon.cf ファイルは、すべてのクラスター・ノードの /usr/es/sbin/cluster ディレクトリーに置く必要があります。

ファイルの作成に関する要件は、次のとおりです。

v netmon.cf ファイルでは、1 ケーブルに 1 つの IP アドレスまたは IP ラベルを記述する。

v 各 IP アドレスと、アドレスに対応する /etc/hosts ファイルのラベルは、netmon.cf ファイルで定義する。

v netmon.cf ファイルの IP アドレス (またはホスト名) を選択する際には、インターフェースがいずれかの時点で保持する可能性のあるすべての IP アドレス (HACMP および他のインターフェースによって使用されるブート IP アドレス、サービス IP アドレス) を考慮する。また、ノード上の各インターフェースごとに、これらのアドレスによってアクセスできる 1 つ以上のターゲットが netmon.cf ファイルに含まれていることを確認する。

例えば、サービス・アドレスを保持していないときにブート・アダプターとして機能するノード上のアダプターは、そのブート・アドレスを使用して netmon.cf ファイル内のいくつかのターゲットに PING

できる必要があります。

注: netmon.cf ファイル内の名前が /etc/hosts ファイルに含まれていることを確認してください。含まれていない場合、NIM プロセス (RSCT トポロジー・サービス・サブシステムの一部) が、ローカル・アダプターの状態を判別しようとする際に、ホスト名解決を実行しようとすることがあります。ネーム・レゾリューションに使用されるネットワークが到達不可能であるとき、ホスト名解決によって、プロセスがブロックされることがあります。このブロックによって、アダプター障害検出時間が長くなり、フォールオーバー操作が遅くなることがあります。

v netmon.cf では、最大 30 個の IP アドレス/ラベルを定義できる。

次に、/usr/es/sbin/cluster/netmon.cf 構成ファイルの例を示します。

180.146.181.119steamerchowder180.146.181.121mussel

HACMP を仮想ネットワークでサポートするための netmon 機能

仮想ネットワークを使用する場合は、サービス・アダプター障害の検出のために追加の netmon.cf 機能が必要です。

HACMP では、アダプターの状態を長期間モニターするための確実な手段としてハートビートが使用されます。ローカル・アダプターでインターフェースの到着バイト数からネットワーク・トラフィックを確認できる場合、そのアダプターは正しく機能しているとみなされます。ただし、クラスター内で仮想ネットワークを使用している場合、管理対象システム全体がネットワークから切断されても、仮想ネットワーク・クライアント間で受け渡しされているトラフィックは通常の外部トラフィックのように見えるため、HACMP

ノードがローカル・アダプターのダウン・イベントを検出していない可能性があります。インバウンド・トラフィックが外部ネットワークからのものか、単に近隣の LPAR からのものかを区別する方法はありません。

この問題に対処するため、特定のアダプターが一連の指定ターゲットに ping できる場合にのみ、そのアダプターが動作しているとみなすことを宣言できます。インターフェースごとに最大 32 個の異なるターゲッ

計画 61

トを指定できます。特定のターゲットが ping 可能であれば、そのアダプターは動作しているとみなされます。ターゲットは、既存の netmon.cf 構成ファイルを使用して指定されます。

注:

v 仮想ネットワーク環境および統合仮想イーサネット (IVE) ネットワークの外にあるターゲットを選択する必要があります。IVE ネットワークでは、同じ物理システムにある IVE ネットワークのメンバーであるターゲットを使用することはできません。

v ターゲットを選択するときは、単一障害点規則を考慮してください。すべてが同じ物理マシン上にあるターゲットを使用しないでください。また、すべてのターゲットを同じ HACMP クラスターのアダプターにしないでください (そうでなければ、そのクラスター内にある特定のノードの電源のみがオンになっているとき、そのノードはアダプターを動作中状態に保つことができません)。

v ターゲットには、ネーム・サーバーとゲートウェイを選択するか、または ping に応答する、信頼できる外部 IP アドレスを選択してください。これらのターゲットは、企業ネットワーク・インフラストラクチャー内の変更を通じて保守する必要があります。

指定のターゲットをセットアップするには、次のフォーマットを使用します。

!REQD <owner> <target>

項目説明

!REQD 明示的な文字列。行の先頭に記述する必要があります (先行スペースなし)。

<owner> この行を使用するインターフェース。つまり、ここで指定されたアダプターをモニターするコードは、この行で指定されたいずれかのターゲット (下記参照) に ping できるかどうかによって、そのアダプター自体の動作中/ダウン状況を判別します。 owner

は、ホスト名、IP アドレス、またはインターフェース名として指定できます。ホスト名または IP アドレスの場合、owner はブート名/IP (サービス・エイリアスなし) を指す必要があります。ホスト名の場合、owner は、IP アドレスに解決できるものでなければなりません。そうでなければ、その行は無視されます。すべてのアダプターを指定する場合は、文字列 "!ALL" を使用します。

<target> IP アドレスまたはホスト名。この IP アドレスまたはホスト名に対して owner が ping を試みるようにさせます。通常のnetmon.cf エントリーと同様に、ホスト名ターゲットを使用可能にするには、ホスト名ターゲットを IP アドレスに対して解決可能にする必要があります。

netmon.cf ファイルの従来のフォーマットは変更されていません。 1 行に 1 つのホスト名または IP アドレスを記述します。アダプターは、いずれの「!REQD」行にも一致しなくても、これまでどおりに従来の行を (インターフェースの到着バイト数を増やすために、既知のローカル・アダプターや定義済みのアダプターのほかに、ping 用の追加ターゲットとして) 使用します。アダプターは、1 つ以上の「!REQD」行に(owner として) 一致する場合、従来の行を無視します。

行の順序は重要ではありません。「!REQD」行を従来の行とどのように混用してもかまいません。ただし、32 行の従来の行をフルに使用する場合、それらの行をすべてファイルの先頭に置くことはしないでください。そうでなければ、各アダプターがその従来の行をすべて読み込み (これらの行がデフォルトですべてのアダプターに適用されるため)、32 行目でファイルの読み取りを終了します。逆の場合、特定のアダプターに適用されない「!REQD」行はスキップされ、最大数 32 に含まれないため、同じ問題は発生しません。


|

|

|

コメント (先頭が「#」の行) は行の上または行の間で使用できます。コメントは無視されます。

同じ owner に対して 32 行より多くの「!REQD」行が指定された場合、余分な行は無視されるだけです(従来の行と同様)。

例

例 1

9.12.4.11!REQD en2 100.12.7.99.12.4.13!REQD en2 100.12.7.10

v 多くのアダプターは、従来の方法で netmon を使用し、他のローカル・アダプターまたは既知のリモート・アダプターで 9.12.4.11 および 9.12.4.13 に ping し、結果についてはインターフェースの到着バイト数のみを対象とします。

v インターフェース en2 は、100.12.7.9 または 100.12.7.10 に ping できる場合にのみ動作中とみなされます。

例 2

!REQD host1.ibm 100.12.7.9!REQD host1.ibm host4.ibm!REQD 100.12.7.20 100.12.7.10!REQD 100.12.7.20 host5.ibm

v 「host1.ibm」を持つアダプターは、100.12.7.9 に ping できる場合、または host4.ibm が解決される場合にのみ動作中とみなされます。

v 100.12.7.20 を持つアダプターは、100.12.7.10 に ping できる場合、または host5.ibm が解決される場合にのみ動作中とみなされます。

v 100.12.7.20 は「host1.ibm」の IP アドレスである可能性があります (この例からはわかりません)。その場合、4 つのターゲットはすべてそのアダプターに属しています。

例 3

!REQD !ALL 100.12.7.9!REQD !ALL 110.12.7.9!REQD !ALL 111.100.1.10!REQD en1 9.12.11.10

v すべてのアダプターは、100.12.7.9、110.12.7.9、または 111.100.1.10 に ping できる場合にのみ動作中とみなされます。

v en1 には追加のターゲット 9.12.11.10 があります。

v この例では、すべてのアダプターが新しい方式を使用するように定義されているため、従来の行を使用することは無意味です。

いずれかの「!REQD」netmon.cf 行の「owner」として含まれないインターフェースは、この新しい機能を他のインターフェースに対して使用している場合でも、従来の方法で引き続き動作します。

この修正によってハートビートの動作そのものが変わることはありません。ローカル・アダプターが動作中かダウン状態なのかについて判別方法が変わるだけです。そのため、この新しいロジックは、ハートビート障害時 (近隣との通信が最初に失われたとき) またはハートビートが使用不可の間 (あるノードのみがクラスター内で動作中の場合など)、始動時 (ハートビート・リングが形成される前) に使用されます。

この機能は、仮想ネットワーク環境が原因で必要となる場合にのみ使用してください。この修正を起動すると、「適切な」アダプターの定義が「ネットワーク・トラフィックを受信できるかどうか」から「特定のア

計画 63

ドレスに正常に ping できるかどうか」に (確認できるトラフィックの量に関係なく) 変わります。この事実だけでも、2 番目の定義がより限定的であるため、アダプターがダウンしていると誤ってみなされる傾向が本質的に高くなります。

同じ理由から、この新しい機能を利用する場合、インターフェースごとに指定するターゲット数をできるだけ多くしてください (上限まで)。

RS232 TTY ボー・レートの設定デフォルトのボー・レートは 38400 bps ですが、一部のモデムやデバイスはボー・レート 38400 bps をサポートしていません。これに該当する場合、RS232 ネットワーク・モジュールをカスタマイズしてデフォルトを変更し、必要なボー・レート (9600 bps、19200 bps、38400 bps) を読み取るようにすることができます。

関連情報:

RS232 ネットワーク・モジュール・ボー・レートの変更

Oracle とのノード内通信のネットワーク計画Oracle では、専用ネットワーク属性の設定を使用して、Oracle ノード間通信用のネットワークを選択します。この属性は HACMP では使用されず、HACMP に影響を及ぼしません。デフォルトの属性は「public(共用)」です。

ネットワーク属性を「private (専用)」に変更すると、(HACMP ネットワークで属性を変更するのと同様に)

すべてのインターフェースをサービスに変更することによって、ネットワークが Oracle 互換ネットワークになります。

クラスター・ネットワークを手動またはディスカバリーを使用して作成した後、次の SMIT パスに従ってネットワーク属性を変更することができます。

「Extended Configuration (拡張構成)」>「Extended Topology Configuration (拡張トポロジー構成)」>「Configure HACMP Networks (HACMP ネットワークの構成)」>「Change/Show a Network in theHACMP Cluster (HACMP クラスター内のネットワークの変更/表示)」

変更するネットワークを選択して、ネットワーク属性設定を「private (専用)」に変更してください。この変更を行った後、クラスターを同期させてください。

プライベート・ネットワークの構成規則

次のステップに従って、Oracle が使用する専用ネットワークを構成します。

1. ネットワークを構成し、すべてのインターフェースを追加します。ネットワークにインターフェースがない場合は属性を変更できません。

2. ネットワーク属性を「private (専用)」に変更します。

3. 専用ネットワークにはすべてのブート・インターフェースまたはすべてのサービス・インターフェースが必要です。ネットワークがすべてのブート・インターフェース (ディスカバリー使用時はデフォルト)

を持つ場合、HACMP は、これらのインターフェースをサービスに変換します (Oracle のみがサービス・インターフェースを使用します)。

4. 属性が変更された後、クラスターを同期します。

注: ネットワーク属性を「private (専用)」で定義した後に「public (共用)」に戻すことはできません。ネットワークを削除し、HACMP に対してネットワークを再定義する必要があります (デフォルトでは、「public (共用)」に設定されます)。


関連情報:

HACMP クラスターの検証と同期化

ネットワーク・ワークシートの記入このセクションでは、ネットワーク・ワークシートへの記入方法について説明します。

TCP/IP ネットワーク・ワークシートの記入TCP/IP ネットワーク・ワークシートは、HACMP クラスターのネットワークを編成する際に役立ちます。

TCP/IP ネットワーク・ワークシートを印刷し、このセクションの情報を使用して内容を記入します。必要な枚数のシートを印刷します。

ICP/IP ネットワーク・ワークシートを記入するには、以下の手順を実行します。

1. 「Network Name (ネットワーク名)」フィールドに、各ネットワークのシンボル名を記入します。

クラスターを構成するときに、インストール・プロセスでこの値を使用します。ネットワーク名は最大32 文字で、英数字と下線を使用できます。ただし、名前の先頭には数字を使用しないでください。HACMP ネットワーク・タイプを単独で名前として使用しないでください。ただし、ネットワーク・タイプに数字を付加したものは使用できます。例えば、Ether の代わりに Ether1 を使用します。

「Network Name (ネットワーク名)」は、HACMP 環境のネットワークを識別するシンボル値です。クラスター・プロセスは、この情報を使用して、どのアダプターが同じ物理ネットワークに接続されているかを判別します。任意の命名規則を使用できますが、矛盾がないように指定する必要があります。複数のインターフェースが同じ物理ネットワークを共用している場合は、これらのアダプターを定義する際に、同じネットワーク名が使用されていることを確認してください。

2. 「Network Type (ネットワーク・タイプ)」フィールドに、ネットワーク・タイプ (イーサネットやトークンリングなど) を指定します。

3. 「Netmask (ネットマスク)」フィールドに各ネットワークのネットワーク・マスクを指定します。ネットワーク・マスクはサイトによって異なります。

HACMP ソフトウェアは、単一の物理ネットワークを複数の独立した論理サブネットに区分化するために、TCP/IP のサブネット機能を使用します。サブネットを使用するには、システムにネットワーク・マスクを定義します。

IP アドレスは 32 ビットで構成されます。これらのビットの一部がネットワーク・アドレスを形成し、残りがホスト・アドレスを形成します。ネットワーク・マスク (ネットマスク) は、IP アドレスのうちネットワークを表すビットと、ホストを表すビットを決定します。以下に例を示します。

上の図では、ネットマスクを小数点付き 10 進形式と 2 進数形式の両方で示しています。2 進数の 1

は、ビットがネットワーク・アドレスの一部であることを示します。2 進数の 0 は、ビットがホスト・アドレスの一部であることを示します。「IP アドレスの例」の図では、アドレスのネットワーク部分が24 ビットを占め、ホスト部分が 8 ビットを占めています。したがって、10.10.10.1 と 10.10.10.2 のア

アドレスのネットワーク�� ホスト

f_ip

_addre

ss255.255.255.0

11111111 11111111 11111111 00000000

計画 65

ドレスは同じサブネット上にありますが、10.10.20.1 のアドレスは、アドレスのネットワーク部分が異なるため、別のサブネットに存在します。オクテットの境界にサブネットを定義すると便利ですが、(必須ではありません)。

サブネットは、ローカル・サイトにのみ関係します。リモート・サイトには、IP アドレスのネットワーク部分がネットワークのクラス別に表示されます。

HACMP ソフトウェアの SMIT パネルで、UNIX の標準サブネット構文 (例えば、192.9.200.0/24) を使用して、ネットワークでサブネットを追加または削除できます。

アドレス・クラスの詳細については、「IBM AIX Communication Concepts and Procedures」を参照してください。また、各自のサイトのクラスおよびサブネットについては、ネットワーク管理者に問い合わせてください。

4. 「Node Names (ノード名)」フィールドに、各ネットワークに接続されたノードの名前を記入します。クラスター・ダイアグラムを参照してください。

5. 「IP Address Takeover via IP Aliases (IP エイリアスによる IP アドレス・テークオーバー)」フィールドのデフォルトは「YES (はい)」です。この機能を使用する予定がない場合は、このオプションを無効にしてください。

6. 「IP Address Offset for Heartbeating over IP Aliases (IP エイリアスを使用するハートビートの IPアドレス・オフセット)」フィールドに、ハートビート・エイリアス・アドレスの作成に使用する、HACMP の開始アドレスを記入します。

関連概念:

36ページの『IP エイリアスを使用するハートビート』このセクションは IP エイリアスを使用するハートビートについての情報が含まれています。

関連資料:

205ページの『TCP/IP ネットワーク・ワークシート』このワークシートは、クラスターの TCP/IP ネットワーク・トポロジーを記録するために使用します。クラスターごとに 1 枚のワークシートに情報を記入してください。

49ページの『IP エイリアスによる IP アドレス・テークオーバー』HACMP は、IP エイリアスによる IPAT を使用して、サービス IP アドレスの高可用性を維持します。

TCP/IP ネットワーク・インターフェース・ワークシートの記入TCP/IP ネットワーク・インターフェース・ワークシートでは、クラスターの各ノードに接続される NIC

の定義に役立ちます。

TCP/IP ネットワーク・インターフェース・ワークシートを印刷し、このセクションの情報を使用して内容を記入します。それぞれのノードごとにシートを印刷します。

ICP/IP ネットワーク・インターフェース・ワークシートを記入するには、以下の手順を実行します。

1. 「Node Name (ノード名)」フィールドにノード名を入力します。この名前は、『クラスターの初期計画』で割り当てた名前です。各ノードで構成するネットワーク・アダプターごとに、以下の作業を行います。

2. 各インターフェースに IP ラベルを割り当て、「IP Label/Address (IP ラベル/アドレス)」フィールドに記録します。この名前は最大 32 文字で、英数字 (先頭は数字以外)、ハイフン、および下線を使用できます。

システムのホスト名がインターフェース・ラベルと同じである場合は、下線を使用しないでください。これは、BIND のレベルによっては、ホスト名に下線を使用することができないためです。


IP ラベルについて詳しくは、この章のセクション『TCP/IP ネットワークの IP ラベル』を参照してください。

3. 「Network Interface (ネットワーク・インターフェース)」フィールドに、このインターフェースを接続するネットワークの名前を記入します。

4. 「Interface Function (インターフェース機能)」フィールドに、インターフェースの機能をサービス、ブート、または永続のいずれかとして指定します。

5. 「IP Address (IP アドレス)」フィールドに、各インターフェースの IP アドレスを記録します。

1 つのネットワークのサービス IP アドレスはすべて、同じサブネットを共用できます。ご使用のネットワークが、IP エイリアスによるハートビートを使用している場合は、サービス IP アドレスおよびブート IP アドレスをすべて同じサブネット上に配置することも、また、別のサブネット上に配置することもできます。

ご使用のネットワークで、IP エイリアスによるハートビートを使用していない場合:

v 各ノードについて、所定のネットワークのブート IP アドレスはすべて、別のサブネットに存在する必要があります。各ノード上には、一連の同じサブネットを使用できます。

v 使用しているリソース・グループで、始動ポリシーの「Online on Highest Available Node (可用性の最も高いノードでオンライン)」または「Online Using Node Distribution Policy (ノード配布ポリシーを使用してオンライン)」、フォールオーバー・ポリシーの「Fallover to the Next Priority Node in the

List (リスト中の次の優先順位のノードにフォールオーバー)」、およびフォールバック・ポリシーの「Never Fallback (フォールバックしない)」が設定されている場合、サービス IP アドレスは、ブート IP アドレスのいずれかと同じサブネット上に配置してください。

v 使用しているリソース・グループで、始動ポリシーの「Online on Home Node (ホーム・ノードでオンライン)」、フォールオーバー・ポリシーの「Fallover to the Next Priority Node (次の優先順位のノードにフォールオーバー)」、およびフォールバック・ポリシーの「Fallback to Highest Priority Node

(優先順位の最も高いノードにフォールバック)」が設定されている場合、サービス IP アドレスは、すべてのブート IP アドレスと異なるサブネット上に存在する必要があります。

6. NIC のハードウェア・アドレスを記入します。

ハードウェア・アドレス・スワップを使用している場合は、「NIC HW Address (NIC ハードウェア・アドレス)」フィールドに、各サービス IP ラベルの代替ハードウェア・アドレスを記入します。ハードウェア・アドレスは、12 または 14 桁の 16 進値です。わかりやすくするために、16 進数値の前に「0x」を付けるのが一般的です。読みやすくするために、ハードウェア・アドレスの中の数値をコロンで区切るのが一般的です。コロンは実アドレスの一部ではないため、構成時に SMIT パネルで入力しないでください。

注: ハードウェア・アドレス・スワッピングは、ATM ネットワークではサポートされていません。

関連資料:

206ページの『TCP/IP ネットワーク・インターフェース・ワークシート』このワークシートは、各ノードに接続された TCP/IP ネットワーク・インターフェース・カードを記録するために使用します。クラスターで定義されたノードごとに、個別のワークシートが必要です。ノードごとにワークシートを 1 枚ずつ印刷して、それぞれにノード名を記入してください。


計画 67

69ページの『ハードウェア・アドレスの定義』ハードウェア・アドレスのスワップ機能は、IP 交換による IP アドレス・テークオーバーと連携して機能します。ハードウェア・アドレス・スワップでは、IP アドレスとハードウェア・アドレスとの間のバインディングが維持されます。これにより、IP アドレスのテークオーバー後にクライアントおよびネットワーク・デバイスの ARP キャッシュを更新する必要がなくなります。この機能は、イーサネット・アダプター、トークンリング・アダプター、および FDDI アダプターでサポートされます。

31ページの『IP ラベル』非 HACMP 環境では、通常ホスト名はシステムを特定し、そのホスト名はシステム内にある 1 つのネットワーク・インターフェースの IP ラベルになっています。したがって、システムのホスト名を接続用 IP

ラベルとして使用すれば、そのシステムへのアクセスが可能になります。

関連情報:

クラスター・トポロジーの管理

Point-to-Point ネットワーク・ワークシートの記入Point-to-Point ネットワーク・ワークシートは、クラスターの Point-to-Point ネットワークを編成する際に役立ちます。

Point-to-Point ネットワーク・ワークシートを印刷し、このセクションの情報を使用して内容を記入します。

Point-to-point ワークシートを記入するには、以下の手順を実行します。


2. 「Network Name (ネットワーク名)」フィールドで各ネットワークにシンボル名を割り当てます。指定できる名前は最大 32 文字で、英数字と下線を使用できます。ただし、名前の先頭には数字を使用しないでください。

「Network Name (ネットワーク名)」は、HACMP 環境のネットワークを識別するシンボル値です。クラスター・プロセスは、この情報を使用して、どのインターフェースが同じ物理ネットワークに接続されているかを判別します。任意の命名規則を使用できますが、矛盾がないように指定する必要があります。2 つのインターフェースが同じ物理ネットワークを共用している場合は、これらのインターフェースを定義する際に、同じネットワーク名が使用されていることを確認してください。

3. 「Network Type (ネットワーク・タイプ)」フィールドに、ネットワーク・タイプを指定します。Point-to-Point ネットワークの場合は、RS232、ディスク・ハートビート (diskhb)、ターゲット・モードSCSI (tmscsi)、またはターゲット・モード SSA (tmssa) を指定できます。

「Network Attribute (ネットワーク属性)」フィールドには、値が事前に割り当てられています。

4. 「Node Names (ノード名)」フィールドに、各ネットワークに接続されたノードの名前を記入します。クラスター・ダイアグラムを参照してください。

5. (diskhb の場合) 「Hdisk」フィールドに、diskhb ネットワークで使用されるディスクを指定します。

6. 「Miscellaneous Data (その他のデータ)」フィールドに、Point-to-Point リンクの拡張に使用するデバイスについての、その他の情報 (モデム番号やエクステンダー情報など) を記録します。

関連資料:

207ページの『Point-to-Point ネットワーク・ワークシート』このワークシートは、クラスターの Point-to-Point ネットワーク・トポロジーを記録するために使用します。クラスターごとに 1 枚のワークシートに情報を記入してください。


シリアル・ネットワーク・インターフェース・ワークシートの記入シリアル・ネットワーク・インターフェース・ワークシートでは、クラスター内の各ノードに接続されるネットワーク・インターフェースを定義できます。

ノードごとにワークシートを用意して、次のステップを実行します。

シリアル・ネットワーク・インターフェース・ワークシートに記入するには、次の手順を実行します。

1. 「Node Name (ノード名)」フィールドにノード名を入力します。この名前は、この章の『TCP/IP ネットワーク・ワークシートの記入』でワークシートに記入した際に割り当てた名前です。ノード上に構成する各シリアル・ネットワークごとに、以下の情報を記録します。

2. 「Slot Number (スロット番号)」フィールドに、シリアル・インターフェースが配置されているスロット番号を記入します。

関連する AIX 資料の説明に従ってアダプターを構成した後、「Interface Name (インターフェース名)」フィールドに値を記入します。インターフェースの構成時に、AIX によってインターフェース名が割り当てられます。インターフェース名は、インターフェースのタイプを表す 2 または 3 文字と、それに続く AIX がインターフェースのタイプ別に順番に割り当てる数字で構成されます。例えば、AIX は、最初の tty に対して、tty0 などのインターフェース名を割り当てます。

3. 各インターフェースにシンボル名を割り当て、「Interface Label (インターフェース・ラベル)」フィールドに記録します。

クラスターにおけるインターフェースの役割を判別しやすい命名規則を使用してください。例えば、nodea-tty1 などです。

4. 「Network Name (ネットワーク名)」フィールドに、Point-to-Point ネットワーク・ワークシートでネットワークに割り当てた名前を記入します。

5. 適切な値が「Interface Function (インターフェース機能)」フィールドに表示されます。

関連資料:

205ページの『TCP/IP ネットワーク・ワークシート』このワークシートは、クラスターの TCP/IP ネットワーク・トポロジーを記録するために使用します。クラスターごとに 1 枚のワークシートに情報を記入してください。

ハードウェア・アドレスの定義ハードウェア・アドレスのスワップ機能は、IP 交換による IP アドレス・テークオーバーと連携して機能します。ハードウェア・アドレス・スワップでは、IP アドレスとハードウェア・アドレスとの間のバインディングが維持されます。これにより、IP アドレスのテークオーバー後にクライアントおよびネットワーク・デバイスの ARP キャッシュを更新する必要がなくなります。この機能は、イーサネット・アダプター、トークンリング・アダプター、および FDDI アダプターでサポートされます。

注: ネットワークで IP エイリアスによる IP アドレス・テークオーバーを構成している場合、ハードウェア・アドレス・スワップは使用できません。ハードウェア・アドレス・スワッピングは、ATM ネットワークではサポートされていません。

ハードウェア・アドレス・スワップが完了するまでには、トークンリング・ネットワークでは約 60 秒、FDDI ネットワークでは最大 120 秒の時間がかかります。これらの所要時間は、クラスター・マネージャーが障害を検出して処置を実行するまでの時間より一般に長いため、場合によってはこれらのネットワークの調整パラメーターを調整する必要があります。

関連資料:

計画 69

57ページの『障害検出パラメーターの設定』ネットワーク・モジュールの重要な調整パラメーターの 1 つに、障害検出率があります。このパラメーターによって、接続の失敗が認識される速さが決定されます。

代替ハードウェア・アドレスの選択このセクションでは、イーサネット、トークンリング、および FDDI のネットワーク・インターフェース・カードのハードウェア・アドレッシングに関する情報を説明します。NIC に定義する代替ハードウェア・アドレスは、製造元がその NIC に割り当てているデフォルトのハードウェア・アドレスと同じ形式にする必要があります。

アダプターのデフォルトのハードウェア・アドレスを調べるには、(ネットワークがアクティブなときに)

netstat -i コマンドを使用します。

netstat の使用方法:

netstat -i コマンドを使用すれば、ハードウェア・アドレスを取得できます。

以下のように入力します。

netstat -i | grep link

コマンドから、次のような出力が戻されます。

lo016896 link#1 186303018630900

en01500 link#2 2.60.8c.2f.bb.93 29250104700

tr01492 link#3 10.0.5a.a8.b5.7b 1045440 9215800

tr11492 link#4 10.0.5a.a8.8d.79795170 3913000

fi04352 link#5 10.0.5a.b8.89.4f402210110

fi14352 link#6 10.0.5a.b8.8b.f4403380610

arp コマンドの使用:

arp コマンドを使用して、ホストの ARP キャッシュにあるノード、IP アドレス、および関連するハードウェア (MAC) アドレスのリストを表示します。

以下に例を示します。

arp -a

flounder (100.50.81.133) at 8:0:4c:0:12:34 [ethernet]

cod (100.50.81.195) at 8:0:5a:7a:2c:85 [ethernet]

seahorse (100.50.161.6) at 42:c:2:4:0:0 [token ring]

pollock (100.50.81.147) at 10:0:5a:5c:36:b9 [ethernet]

この出力は、ホスト・ノードが現在認識している flounder ノード、cod ノード、seahorse ノード、およびpollock ノードの IP アドレスと MAC アドレスを示しています (ハードウェア・アドレス・テークオーバー (HWAT) を使用せずに IP アドレス・テークオーバーが実行されると、ホストの ARP キャッシュにある、IP アドレスに関連付けられた MAC アドレスが古くなる場合があります。これを修正するには、ホストの ARP キャッシュを更新します)。

詳しくは、arp のマニュアル・ページを参照してください。


代替イーサネット・ハードウェア・アドレスの指定:

イーサネット・インターフェースの代替ハードウェア・アドレスを指定するには、まず、現在のハードウェア・アドレスを構成している英数字ペアのうち、最初の 5 つの英数字ペアを使用します。次に、最後のペアの文字を、異なる値で置き換えます。同じ物理ネットワーク上の他のアダプターに指定していない文字を使用してください。

例えば、ノード A とノード B に、それぞれ 10 と 20 という値を使用するとします。各ノードにハードウェア・アドレス・スワップ用のアダプターが複数ある場合、ノード A では「11」と「12」に、ノード B

では「21」と「22」に拡張できます。

上記の出力にあるアダプター・インターフェース en0 に代替ハードウェア・アドレスを指定すると、次のような値が得られます。

項目説明

元のアドレス 02608c2fbb93

新しいアドレス 02608c2fbb10

関連情報:

サービス IP ラベル/アドレスの構成

代替トークンリング・ハードウェア・アドレスの指定:

トークンリング・インターフェースの代替ハードウェア・アドレスを指定するには、最初の 2 桁を 42 に設定して、アドレスがローカルに設定されていることを表します。

上記の出力にあるアダプター・インターフェース tr0 に代替ハードウェア・アドレスを指定すると、次のような値が得られます。

項目説明

元のアドレス 10005aa8b57b

新しいアドレス 42005aa8b57b

関連情報:

サービス IP ラベル/アドレスの構成

代替 FDDI ハードウェア・アドレスの指定 (サービス・ラベル):

代替 FDDI ハードウェア・アドレスを指定するには、「Adapter Hardware Address (アダプター・ハードウェア・アドレス)」フィールドに新しいアドレスを次のように入力します。小数点は使用しません。

新しいアドレスの最初の桁 (先頭バイトの最初のニブル) には、数字の 4、5、6、または 7 を使用します。

製造元で設定されたデフォルト・アドレスの下位 6 オクテットを、新しいアドレスの下位 6 桁として使用します。

有効なアドレスのリストの例を、読みやすくするために小数点を付けて示します。

40.00.00.b8.10.89

40.00.01.b8.10.89

50.00.00.b8.10.89

計画 71

60.00.00.b8.10.89

7f.ff.ff.b8.10.89

ネットワークの競合の回避ハードウェアと IP アドレスに関するネットワーク競合は回避できます。

以下の項目に関するネットワーク競合を回避します。

v ハードウェア・アドレス。それぞれのネットワーク・アダプターには製造時に固有のハードウェア・アドレスが割り当てられているため、2 つのアダプターに同じネットワーク・アドレスが設定されていることはありません。ネットワーク・アダプターのハードウェア・アドレスを定義するときは、定義したアドレスが同じネットワーク内の別のネットワーク・アダプターのハードウェア・アドレスと競合しないように注意してください。2 つのネットワーク・アダプターのハードウェア・アドレスが同一である場合、ネットワーク内で予想外の動作が発生する可能性があります。

v IP アドレス。IP アドレスが重複している場合には、検証によりその旨通知されます。アドレスが重複している場合は、それを訂正し、クラスターを再同期化してください。

クラスター・ダイアグラムへのネットワーク・トポロジーの追加クラスター・ダイアグラムにネットワーク・トポロジーを追加できます。

すべての TCP/IP ネットワーク (TCP/IP Point-to-Point 接続も含む) が組み込まれたネットワーク、および非 IP Point-to-Point ネットワークをスケッチします。各ネットワークを名前と属性で識別します。各ノードにあるスロットを示す枠に、インターフェース・ラベルを記入します。

この時点で、『計画プロセスの概説』で開始したサンプル・クラスター・ダイアグラムにネットワークを追加できます。

サンプル・ネットワークのセットアップでは、次の 5 つのネットワークが使用されます。

v トークンリング・ネットワーク clus1_TR。カスタマー・データベースの「フロントエンド」アプリケーションを実行している 10 個のクラスター・ノードに、クライアントを接続するために使用されます。このトークンリング・ネットワークではクライアント・アクセスが許可されます。

v イーサネット・ネットワーク db_net。データベース・アプリケーションを実行する 4 つのクラスター・ノードを接続するために使用されます。このアプリケーションは、実際のデータベース・レコードの更新を処理します。イーサネット・ネットワーク db_net は、クライアント用ではありません。

v 重要なデータベース・ストレージの破損を防ぐため、db_net ノードは一連の Point-to-Point ネットワークにも接続されます。これらのネットワークにより、IP ハートビート・パケットが破棄される競合状況に対する保護が強化されます。

RSCT ソフトウェアは、ネットワーク全体にハートビートを送信することで、定義されている全インターフェースの状況をモニターします。

関連資料:

4ページの『計画プロセスの概説』このセクションでは、HACMP クラスターを計画する際のステップについて説明します。


共用ディスクおよびテープ・デバイスの計画この章では、HACMP クラスター内に共用外部ディスクを構成する前に考慮すべき事項について説明します。また、磁気テープ・ドライブをクラスター・リソースとして使用する場合の計画と構成についても説明します。

前提条件

以下に示す前出の章の計画ステップを完了している必要があります。

ディスク・デバイスとテープ・デバイスにおけるハードウェアとソフトウェアの一般的な設定については、AIX の資料を参照してください。

共用ディスクおよびテープ・デバイスの概説HACMP クラスターでは、共用ディスクとは複数のクラスター・ノードに接続された外部ディスクです。非コンカレント構成では、一度に 1 つのノードのみがディスクを所有できます。所有者ノードに障害が発生した場合、リソース・グループのノード・リストで次に優先順位の高いクラスター・ノードが共用ディスクの所有権を獲得し、アプリケーションを再始動してクライアントへの重要なサービスを復元します。これにより、クライアント・アプリケーションは、共用ディスクに格納されているデータに引き続きアクセスできます。

テークオーバーは一般的に 30 から 300 秒以内に行われます。ただし、この時間範囲は使用されているディスクの数と種類、ボリューム・グループの数、ファイルシステム (共用であるか、NFS クロスマウントであるか)、およびクラスター構成内の重要なアプリケーションの数によって異なります。

クラスターに対する共用外部ディスクを計画する際の目的は、ディスク・ストレージ・サブシステムのSingle Points of Failure を除去することです。以下の表に、ディスク・ストレージ・サブシステムのコンポーネントと、それらの Single Points of Failure として除去するための推奨方法を示します。

クラスター・オブジェクト Single Point of Failure として除去する方法

ディスク・アダプター

冗長ディスク・アダプターを使用する

コントローラー

冗長ディスク・コントローラーを使用する

ディスク冗長ハードウェア、LVM ディスク・ミラーリングまたは RAID ミラーリングを使用する

この章では、次の計画作業を実行します。

v 共用ディスク・テクノロジーの選択。

v 共用ディスク・ストレージのインストールの計画。次の作業が含まれます。

– 計画された記憶容量に対応するために必要なディスク数の決定。ミラーリングされた論理ボリュームを配置する複数の物理ディスクが必要です。ミラーリングされた論理ボリュームのコピーを同じ物理デバイスに配置すると、コピーを作成する意味がありません。ミラーリングされた論理ボリュームの作成について詳しくは、『共用 LVM コンポーネントの計画』を参照してください。

– 各ノードがディスクまたはディスク・サブシステムに接続するために保持するディスク・アダプター数の決定。

論理ボリュームのコピーが入っている物理ディスクは、それぞれ別々のアダプターに接続してください。論理ボリュームのコピーすべてが単一のアダプターに接続されている場合、そのアダプターは潜

計画 73

在的な Single Point of Failure になります。この単一のアダプターに障害が発生した場合、HACMP

はボリューム・グループを代替ノードに移動します。個別のアダプターに接続することで、この移動が不要になります。

– 各種のディスク・テクノロジーの配線要件の理解

v ディスク・ストレージのプランニング・ワークシートへの記入

v クラスター・ダイアグラムへの選択したディスク構成の追加

v SCSI ストリーミング磁気テープ・ドライブ、または Direct Fibre Channel テープ装置接続機構をクラスター・リソースとして構成する計画

関連資料:


共用ディスク・テクノロジーの選択HACMP ソフトウェアは、高可用性クラスター内の共用外部ディスクとして、ディスク・テクノロジーをサポートしています。

本書発行時点でのサポート対象ハードウェア (ディスクやディスク・アダプターなど) の完全なリストについては、次の URL を参照してください。

http://www.ibm.com/common/ssi

国と言語を選択した後、「Search (検索)」の「Specific Information (特定のタイプ)」で「HW and SW Desc

(Sales Manual, RPQ) (HW および SW に関する情報 (含むセールス・マニュアル、RPQ))」を選択してください。

HACMP ソフトウェアは、高可用性クラスター内の共用外部ディスクとして、次のディスク・テクノロジーをサポートしています。

v RAID サブシステムを含む SCSI ドライブ

v IBM SSA アダプターおよび SSA ディスク・サブシステム

v ファイバー・チャネル・アダプターおよびディスク・サブシステム

v データ・パス・デバイス (VPATH)―SDD 1.6.2.0 以降

これらのテクノロジーをクラスターに結合できます。ディスク・テクノロジーを選択する前に、このセクションの説明に従って各テクノロジーの構成に関する考慮事項を検討してください。

HACMP はまた、ファイバー・チャネル・デバイスの動的トラッキングもサポートします。

関連情報:


OEM ディスク、ボリューム・グループ、およびファイルシステムの統合

「Adapters, Devices, and Cable Information for Multiple Bus Systems」ガイド

HACMP APAR の取得APAR (Authorized Program Analysis Report) には、変更されていない現行のプログラム・リリースにおいて、存在する疑いのある欠陥により引き起こされた問題の記録が含まれています。




http://publibfp.boulder.ibm.com/epubs/pdf/38051616.pdf

ハードウェアに関する HACMP の APAR およびアップデートのリストを取得するには、以下の手順に従ってください。

1. IBM サポート Web サイトにアクセスします。

2. 「HACMP +APAR」というキーワードを指定して検索します。

3. 検索結果を日付の新しい順に並べ替えます。

関連情報:

Support & downloads

ディスク計画の考慮事項このセクションでは、次の SCSI ディスク・デバイスおよびディスク・アレイを、クラスター構成内で共用外部ディスク・ストレージとして使用する方法について説明します。

SCSI ディスク・デバイス:

HACMP クラスターでは、共用 SCSI ディスクは、そのデバイスを共用するノードと同じ SCSI バスに接続されます。この共用ディスクは、コンカレントおよび非コンカレントのどちらのアクセス・モードででも使用できます。非コンカレントのアクセス環境では、ディスクは一度に 1 つのノードのみが所有します。所有者ノードに障害が発生すると、リソース・グループのノード・リストの中で次に優先順位の高いクラスター・ノードが、フォールオーバー処理の一環として、共用ディスクの所有権を獲得します。これにより、クライアント・アプリケーションは、共用ディスクに格納されているデータに引き続きアクセスできます。

クラスター構成で共用 SCSI ディスクを使用する際は以下の制約事項が適用されます。

v 異なるタイプの SCSI バスを HACMP クラスター内に構成できます。特に、複数の SCSI 装置を最大 4

つのノードからなるクラスターに構成し、すべてのノードを同一の SCSI バスに接続して、そこから異なる複数のデバイス・タイプに接続できます。

v 最大で 16 のデバイスを SCSI バスに接続できます。各 SCSI アダプターおよび各ディスクは、それぞれ固有の SCSI ID を持つ個別のデバイスとみなされます。ほとんどの SCSI 装置の最大バス長は、ほとんどのクラスター構成において SCSI 標準で許容されている 16 デバイスの接続に十分対応できる長さです。

v 他の SCSI 装置 (CD-ROM など) を共用 SCSI バスに接続しないでください。

v 論理ボリュームを 2 つ以上の物理ディスクでミラーリングする場合、各ディスクを同一の電源装置に接続しないでください。同一の電源装置に接続すると、単一電源が失われた場合に、すべてのコピーにアクセスできなくなる可能性があります。2 つ以上のディスク・サブシステム・ドロワーやデスクサイド装置を使用するよう計画し、単一の電源装置に依存しないようにしてください。

v クォーラムを使用可能に設定すると、2 ディスク構成のボリューム・グループでは、クォーラムを満たすことができず、データ・アクセスが失われる危険性があります。強制 varyon を使用すれば、データの可用性を確実に提供できます。

IBM 2104 Expandable Storage Plus:

IBM 2104 Expandable Storage Plus (EXP Plus) システムによって、柔軟かつスケーラブルな低価格のディスク・ストレージ (RS/6000 サーバーおよび System p サーバー用) がコンパクトなパッケージで提供されます。このシステムは、2 つのノードからなる小規模なクラスターに適しています。

EXP Plus:

v ドロワーあたり、またはタワーあたりの最大容量 2055 GB から、ラック当たりの容量 28 TB 超まで拡張します。

計画 75

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

v 単一バスまたはスプリット・バス構成をサポートし、1 台または 2 台のサーバーに対応できる柔軟性を備えています。

v 160 MB/秒のスループットを実現する高性能 Ultra3 SCSI ディスク・ストレージを搭載しています。

v 最大 14 台の 10,000 RPM ディスク・ドライブ (容量 9.1 GB、18.2GB、36.4 GB、73.4GB および146.8GB) を搭載可能です。

v Low Voltage Differential SE (LVD/SE) SCSI 接続 (6205 Dual Channel Ultra2 SCSI アダプターなど) が必要です。

v 2 つのノードにのみ接続できます。

v 2 つの個別の SCSI バスを備えています。

各ノードは、EXP Plus への固有の SCSI 接続を持ちます。このため、アダプター ID を変更する必要はありません。

v 内部で終端されています。

HACMP は、次のアダプターを使用した 2104 Expandable Storage Plus をサポートします。

v 2494

v 6203

v 6205

v 6206

v 6208

HACMP では、2498 アダプターを使用した 2104 Expandable Storage Plus のテストは行っていません。

関連情報:

Support for 2104 Expandable Storage Plus

IBM 2105 Enterprise Storage Server:

IBM 2105 Enterprise Storage Server (ESS) は、さまざまなオープン・システム・サーバーに対応したディスク・ストレージの多重コンカレント接続および共用機能を提供します。IBM System p プロセッサーだけではなく、他の UNIX や UNIX 以外のプラットフォームも接続できます。

これらのシステムは IBM SSA ディスク・テクノロジーを内部で使用します。実際の ESS システムのセットアップに応じて、ファイバー・チャネル接続または SCSI 接続を使用して ESS にアクセスできます。どちらのアクセス・メカニズムを使用するノードでもボリュームを共用できます。つまり、一方のノードでファイバー・チャネル接続を使用し、もう一方のノードで SCSI 接続を使用できます。

ESS では、すべてのストレージが RAID テクノロジーによって保護されています。RAID-5 の技法を使用すれば、アレイ内のすべてのディスクにパリティーを配分できます。フェイルオーバー保護では、データ・アクセスを継続できるようにするため、ESS の 1 区画 (ストレージ・クラスター) が、他の区画をテークオーバーできます。

HACMP および IBM 2105 Enterprise Storage Server では、ファイバー・チャネル接続用に以下のアダプターをサポートしています。

v PCI バス用ギガビット・ファイバー・チャネル・アダプター: ファームウェア 3.22 A1 を備えたアダプター 6227

v 64 ビット PCI バス用 2 ギガビット・ファイバー・チャネル・アダプター: ファームウェア 3.82 A1 を備えたアダプター 6228


http://www.ibm.com/servers/storage/support/disk/2104/

ESS は、Web ベースの管理インターフェース、動的ストレージ割り振り、リモート・サービス・サポートなどを備えています。

IBM TotalStorage DS4000 ストレージ・サーバー:

DS4000® シリーズ (旧名 FAStT シリーズ) は、エントリー・ディスク・システム製品およびエンタープライズ・ディスク・システム製品を補完するために拡張されました。

このような拡張には、以下のものがあります。

v DS4000 Storage Manager V9.10、拡張リモート・ミラー・オプション

v 大容量構成向け DS4100 ミッドレンジ・ディスク・システム (旧名 TotalStorage FAStT100 ストレージ・サーバー、モデル 1724-100)

v DS4400 接続 EXP100 シリアル ATA 拡張ユニット

DS4000 ストレージ・サーバーは、1 つの FC アダプター上でノードあたり 1 つまたは 2 つの接続をサポートしています。2 つのアダプターを使用します。DS4000 ストレージ・サーバーは、以下のアダプターをサポートしています。

v PCI バス用ギガビット・ファイバー・チャネル・アダプター: ファームウェア 3.22 A1 を備えたアダプター 6227

v 64 ビット PCI バス用 2 ギガビット・ファイバー・チャネル・アダプター: ファームウェア 3.82 A1 を備えたアダプター 6228

IBM DS4400 (旧名 FAStT700) は、2 Gbps ファイバー・チャネル・テクノロジーにより、卓越したパフォーマンスを提供します。DS4400 は、先進的かつ柔軟な機能による保護を実現します。増え続けるストレージ要件に対応するため容量を 36GB から 32TB 以上にまで拡大可能であり、また、先進的な複製サービスを備えています。

HACMP は、IBM Total Storage DS4000 を備えた BladeCenter® JS20 をサポートしています。

IBM TotalStorage DS4300 (旧名 FAStT600) は、ミッドレベルのディスク・システムであり、3 台のEXP700 を使用した 8 テラバイト以上のファイバー・チャネル・ディスク、および 7 台の EXP700 を使用した 16 テラバイト以上のターボ機能付きファイバー・チャネル・ディスクまで拡張できます。最新のストレージ・ネットワーキング・テクノロジーを使用し、エンドツーエンド 2 Gbps ファイバー・チャネル・ソリューションを提供します。

IBM DS4500 (旧名 FAStT900) は、16 台の EXP700 または 16 台の EXP710 を使用して、最大で 67.2

TB のファイバー・チャネル・ディスク・ストレージ容量を提供します。DS4500 は先進的な複製サービスを備えており、ビジネス継続性と災害復旧をサポートします。

IBM System Storage® DS4800 は 4 ギガビット/秒のファイバー・チャネル・インターフェース・テクノロジーに基づいて設計されており、IBM System Storage EXP810、EXP710、EXP700、または EXP100 ディスク装置で最大 224 台のディスク・ドライブをサポートできます。さらに DS4800 は、高性能のファイバー・チャネル・ディスク・ドライブと、大容量のシリアル ATA (SATA) ディスク・ドライブをサポートしています。

関連情報:

IBM System Storage および TotalStorage

計画 77

http://www.storage.ibm.com


HACMP は、適用可能な APAR がインストールされた IBM TotalStorage DS6000™ シリーズ・ディスク・ストレージ・デバイスをサポートしています。

HACMP/XD は、DS8000® および DS6000 シリーズ・ディスク・ストレージ・デバイスの組み合わせに加えて、DS6000 を使用した IBM TotalStorage DSCLI Metro Mirror をサポートしています。

DS6000 シリーズは、IBM および IBM 以外の広範なサーバー・プラットフォームと稼働環境をサポートする、ファイバー・チャネル・ベースのストレージ・システムです。オープン・システム、zSeries、およびiSeries® サーバーもサポートします。


HACMP は、適用可能な APAR がインストールされた IBM TotalStorage DS8000 シリーズ・ディスク・ストレージ・デバイスをサポートしています。

HACMP/XD v5 では Metro Mirror のサポートが拡張され、IBM TotalStorage DS8000 シリーズ・ディスク・ストレージ・デバイスが含まれるようになりました。

IBM TotalStorage DS8000 は、連続稼働をサポートするように設計された、高性能かつ大容量のディスク・ストレージ・シリーズです。DS8000 シリーズのモデルは、ストレージ装置と 1 つまたは 2 つ (推奨構成)

の管理コンソールで構成されます。高可用性を実現するため、ハードウェア・コンポーネントは冗長化されています。

IBM System pクラスター構成において外部ディスク・ストレージとしてサポートされるディスク・システムがいくつかあります。

HACMP では IBM System p の以下の機能がサポートされています。

v POWER5 システムの AIX 5.3 でのマイクロ・パーティショニング

v IBM 2 ギガビット・ファイバー・チャネル PCI-X ストレージ・アダプター

IBM System p p5 モデル 510、520、550 および 570:

HACMP では、適用可能な APAR がインストールされた、System p p5 モデル 510、520、550、570、および 575 がサポートされています。

System p p5 Express ファミリーでは、IBM POWER5 マイクロプロセッサーが使用されます。 POWER5

プロセッサーは、32 ビット・アプリケーションと 64 ビット・アプリケーションを同時に実行できます。動的論理区画 (DLPAR) により、システム・リソース (プロセッサー、メモリー、入出力) の割り当てが支援され、変動するワークロード要件へ迅速かつスムーズに対応できます。これにより、区画間の処理能力を自動的かつスムーズに平衡化することが可能になり、その結果スループットが向上し、応答時間が安定します。

サポートされる構成には一部制限がある点に注意してください。

v 仮想 SCSI (VSCSI) では、拡張コンカレント・モードを使用する必要があります。詳しくは、次のサイトを参照してください。

http://www.ibm.com/support/techdocs/atsmastr.nsf/Web/TechDocs



v HMC ポートがハードウェア管理コンソールに接続されている場合、p5 520、p5 550、p5 570、およびp5 575 統合シリアル・ポートは使用できません。HMC ポートと統合シリアル・ポートのいずれかを使用できますが、両方は使用できません。さらに、統合シリアル・ポートは、モデム接続と非同期ターミナル接続でのみサポートされています。HACMP をはじめ、シリアル・ポートを使用するその他のアプリケーションでは、独立したシリアル・ポート・アダプターを PCI スロットに取り付ける必要があります。

v p5 575 には統合シリアル・ポートがないため、HACMP は、非同期入出力アダプターを介した非 IP ハートビートとディスク・ハートビートに代替手法を使用できます。HACMP では、アプリケーション用に指定された 4 つの統合イーサネット・ポートを使用できます。

v HACMP での仮想化 (VLAN、VSCSI) のサポートの詳細については、次のサイトを参照してください。http://www.ibm.com/support/techdocs/atsmastr.nsf/Web/TechDocs

v HACMP で DLPAR をサポートするには、Apar IY69525 が必要です。

IBM System p p5 モデル 575:

HACMP では、適用可能な APAR がインストールされた IBM p5 575 (9118-575) 高帯域幅クラスター・ノードをサポートしています。

p5 575 は、数多くの高性能コンピューティング・アプリケーションにとって理想的な 8-Way 1.9 GHz

POWER5 高帯域幅クラスター・ノードを実現します。p5 575 は、高密度の 2U サイズのフォーム・ファクターにパッケージされており、高さ 42U、幅 24 インチのラックに最大 12 ノードを格納できます。p5

575 ノードの複数ラックを組み合わせることで、広範かつ強力なクラスター・ソリューションを提供できます。最大 16 の p5 575 ノードをクラスターを構成し、合計 128 プロセッサーとすることができます。

以下にサポートされる System p p5 モデル 575 の制約事項をリストします。

v p5575 には統合シリアル・ポートがありません。HACMP は、非同期入出力アダプターを介した非 IP

ハートビートとディスク・ハートビートに代替手法を使用できます。

v HACMP では、アプリケーション用に指定された 4 つの統合イーサネット・ポートを使用できます。

v 現時点では、HACMP は p5 575 上の DLPAR や仮想 LAN (VLAN) をサポートしていません。

v HACMP で仮想 SCSI (VSCSI) をサポートするには、拡張コンカレント・モードを使用する必要があります。これにはいくつかの制限を伴いますが、お客様によっては有効なソリューションとなります。

IBM System p p5 モデル 590 および 595:

HACMP は、IBM System p p5-590 および IBM System p p5 595 をサポートしています。

p5 590 および IBM p5 595 サーバーは、IBM 64 ビット Power Architecture® マイクロプロセッサー(IBM POWER5 マイクロプロセッサー) を搭載し、同時マルチスレッド化機能を備えています。同時マルチスレッド化機能により、オペレーティング・システムに対し各プロセッサーが 2 つのプロセッサーとして機能します。p5 595 は、IBM の最速 POWER5 プロセッサー (1.90 GHz または 1.65 GHz のいずれかを選択可能) を採用しています。p5-590 は 165 GHz プロセッサーを搭載しています。

これらのサーバーは、メインフレームから引き継いだ信頼性 (Reliability)、可用性 (Availability)、保守性(Serviceability) の RAS 機能と Micro-Partitioning® (マイクロ・パーティショニング) を備えた IBM

Virtualization Engine システム・テクノロジーを標準で装備しています。Micro-Partitioning (マイクロ・パーティショニング) では、プロセッサーあたり最大 10 の論理区画 (LPAR) を定義できます。いずれのシステムも最大 254 の仮想サーバーで構成可能であり、サーバーごとにオペレーティング・システムとしてAIX、Linux、および i5/OS™ のオペレーティング・システムを選択できます。これにより、大幅なコスト削減につながる統合の機会を提供します。

計画 79


VSCSI を利用するには、拡張コンカレント・モードを使用する必要があります。この場合、制限がいくつかありますが、お客様によっては満足できるソリューションとなります。 VSCSI 環境における拡張コンカレント・モードの機能と使用方法が記載されたホワイト・ペーパーは、IBM Web サイトから入手できます。

HACMP では、ファイバー・チャネル接続用に以下のアダプターをサポートしています。

v FC 6239 または FC 5716 2 ギガビット・ファイバー・チャネル - PCI-X

IBM System p i5 モデル 520、550 および 570 iSeries と System p の集中化:

HACMP は、IBM System p i5 をサポートしています。これは、System i および System p を集中化するハードウェア・プラットフォームです。このハードウェア・プラットフォームでは、LPAR 区画に独自のカーネル (現在の PASE の SLIC カーネルではない) を持つネイティブの AIX を実行できます。これにより、個別の System p ボックスまたはその他の UNIX ボックス内で稼働する AIX アプリケーションおよびその他の UNIX ベース・アプリケーションを、単一の i5 プラットフォームに統合する優れた代替手法が提案されます。

HACMP では、適用可能な APAR がインストールされた、新しい POWER5 ベースの IBM i5

520、550、570 サーバーをサポートしています。

HACMP では、ファイバー・チャネル接続用に以下のアダプターをサポートしています。

v FC 6239 または FC 5716 2 ギガビット・ファイバー・チャネル - PCI-X

iSeries i5 システムでサポートされる HACMP/AIX の構成では、次に示す制限事項について考慮する必要があります。

v i5 ハードウェアにおいて、HACMP は、サポートされている AIX リリースを実行している LPAR でのみ動作します。さらに、入出力 (LAN とディスク接続) は、HACMP を実行する LPAR に直接接続する必要があります。HACMP で使用する入出力は、「HACMP Sale Manual 5765-F62」でサポート対象としてリストされているものに限定されます。

v HACMP では、i5 サーバー上で HACMP を実行する AIX 区画に専用入出力がある場合に、その AIX

区画もサポートします。

v 現時点では、HACMP は i5 モデル上でのマイクロ・パーティショニング、仮想 SCSI (VSCSI) および仮想 LAN (VLAN) はサポートしていません。

HMC ポートがハードウェア管理コンソールに接続されている場合、i5 520、550、および 570 の統合シリアル・ポートは使用できません。HMC ポートと統合シリアル・ポートのいずれかを使用できますが、両方は使用できません。さらに、統合シリアル・ポートは、モデム接続と非同期ターミナル接続でのみサポートされています。HACMP をはじめ、シリアル・ポートを使用するその他のアプリケーションでは、独立したシリアル・ポート・アダプターを PCI スロットに取り付ける必要があります。

RS/6000 SP システム:

SP は、2 から 128 個のプロセッサーを高性能スイッチで接続した並列処理マシンです。

SP は、その設計に数多くの標準 RS/6000 ハードウェア・コンポーネントを採り入れることによって、RS/6000 シリーズの優れた信頼性を活用しています。SP のアーキテクチャーでは、特定のコンポーネントに故障が発生しても処理を継続できるため、こうした信頼性がさらに強化されています。このアーキテクチャーでは、正常なノードで処理を続けながら、障害の発生したノードを修復できます。あるノードに対するハードウェアおよびソフトウェアの変更を、他のノードで処理を続けながら計画、実施することもできます。


IBM シリアル・ストレージ・アーキテクチャー・ディスク・サブシステムシリアル・ストレージ・アーキテクチャー (SSA) は、Single Point of Failure を最小限に抑え、HACMP 環境で高い可用性を実現します。

IBM 7133 および 7131-405 SSA ディスク・サブシステムを共用外部ディスク・ストレージ・デバイスとして使用し、HACMP クラスター構成でコンカレント・アクセスを提供できます。

AIX V5.2 の MPIO 機能を使用すると、複数のパスを介してディスク・サブシステムにアクセスできます。複数のパスを使用することで、単一のパスを使用する場合よりもスループットと可用性の両方が向上します。具体的には、複数のパスを使用している場合は、アダプター、ケーブル、またはスイッチの障害が原因で 1 つのパスを使用できなくなった場合でも、アプリケーションは引き続きデータにアクセスできます。HACMP は、ボリューム・グループへのアクセスが完全に失われた状態から回復しようとしますが、その状態自体は一時的な中断となります。AIX の MPIO 機能は、単一のコンポーネント障害に起因するアプリケーションの停止を防止できます。

コンカレント・アクセスを達成することができます。この場合、HACMP は、以下の方法で MPIO アクセス・ディスクを必要とします。

v ご使用のディスクが、ボリューム・グループを開くときに予約が要求されない拡張コンカレント・ボリューム・グループの一部である。

v RESERVE_POLICY が NO_RESERVE になるように装置特性を変更できる。このような特性をサポートするデバイスの場合、通常のオープンではディスクには予約が設定されません。上記のように装置特性が変更される場合は、ボリューム・グループが拡張コンカレント・ボリューム・グループではない場合でも予約は設定されず、HACMP は容易にテークオーバーを行うことができます。

SSA はホット・プラグ可能です。LVM ミラーリングを使用するボリューム・グループに SSA ディスクを組み込んでおくと、システム全体の電源をオフにすることなく、障害の発生したディスク・ドライブを交換できます。

次の図は、基本的な SSA ループ構成を示したものです。

ディスク

c_ssa_lo

op

SSAアダプター

SSAアダプター

ディスク電源装置の考慮事項信頼性の高い電源は、高可用性クラスターにとって必要不可欠のものです。クラスター内のミラーリングされたディスク・チェーンはそれぞれ別個の電源を持つ必要があります。クラスターの計画を立てる際は、いずれかの電源 (PDU、電源装置、または構内回線) が故障しても複数のノードやミラーリングされたチェーンが使用不可にならないようにしてください。

計画 81

SCSI デバイス電源の考慮事項

クラスター・サイトに多層電源装置がある場合は、クラスター・ノードを同じ電源層に接続する必要があります。このように接続しないと、SCSI バスを介して接地電流がシステム間を移動し、書き込みエラーの原因となります。

ノード間で共用されるバスおよびデバイスの運用上の電源サージ制限は、標準の SCSI システムと同じです。データの損失を防ぐために、無停電電源装置 (UPS) が必要です。電力が最初に SCSI 装置に供給されたときに、接続バスから動的にデータが渡されている場合、データが壊れる可能性があります。このようなエラーを防ぐには、デバイス (ディスクまたはアダプター) に電源投入する間、バス上のデータ転送操作を一時的に停止します。例えば、クラスター・ノードが 2 つの異なる電源回路に接続されている場合、片方のノードに電源サージが発生してリブートされると、残りのノードは、データ転送がアクティブになっていた場合にはデータを失う可能性があります。

IBM DS4000 シリーズ (旧名 FAStT シリーズ)、IBM 2104 Expandable Storage Plus、および IBM 2105

Enterprise Storage Server は、冗長化された電源装置を備えているため、電源に関する問題は発生しにくくなっています。

IBM SSA ディスク・サブシステム電源の考慮事項

IBM SSA ディスク・サブシステムを備えたクラスターには冗長化された電源装置が付属しているため、電源装置に関する問題が発生する可能性は低くなります。

非共用ディスク・ストレージの計画非共用ディスク装置について、いくつかの考慮事項に注意してください。


v 内部ディスク。クラスター内の個々のノードにある内部ディスクには、次のソフトウェアのための十分なスペースが必要です。

– AIX ソフトウェア (約 500 MB)

– HACMP ソフトウェア (サーバー・ノードあたり約 50 MB)

– 高可用性アプリケーションの実行可能モジュール

v ルート・ボリューム・グループ。各ノードのルート・ボリューム・グループは共用 SCSI バス上に配置してはいけません。

v AIX エラー通知機能。AIX エラー通知機能を使用して、各ノード上の rootvg をモニターします。ルート・ボリューム・グループに生じた問題は、ノード障害に発展する場合があります。

v ディスク・アダプターの使用。共用ディスクには専用アダプターが必要なため、同じアダプターを共用ディスクと非共用ディスクの両方に使用することはできません。各ノードの内部ディスクには、クラスター内の他のすべてのアダプターとは別に、SCSI アダプターが 1 つ必要です。

v ボリューム・グループの使用。内部ディスクは、外部共用ディスクと異なるボリューム・グループに属している必要があります。

高可用性アプリケーションの実行可能モジュールは、次の理由から、共用外部ディスクではなく内部ディスクに格納されている必要があります。

v ライセンス交付

v アプリケーションの始動

関連情報:


AIX for HACMP の構成

ライセンス交付ベンダーによっては、アプリケーションを実行するプロセッサーまたはマルチプロセッサーごとに、各アプリケーションのコピーを別個に購入するようユーザーに求めることがあります。このようなベンダーは、アプリケーションのインストール時にプロセッサー固有の情報をアプリケーションへ組み込むことにより、アプリケーションを保護しています。

そのため、アプリケーション実行可能ファイルを共有ディスクから実行している場合は、新しいノード上のプロセッサー ID が、アプリケーションがインストールされたノード上の ID と一致しないなどの理由から、フォールオーバー後に HACMP が別のノード上のアプリケーションを再始動できない可能性があります。

アプリケーションを使用するには、ノード・バインド・ライセンス、つまり、ノード固有の情報を含む各ノード上のライセンス・ファイルを購入することが必要な場合もあります。

そのアプリケーションのクラスター内で使用可能なフローティング・ライセンス (どのクラスター・ノードにも使用可能) の数に制限がある場合もあります。この問題を回避するには、クラスター内のプロセッサーのうち、アプリケーションを同時に実行する可能性のあるプロセッサーすべてに対して十分な数のライセンスを取得してください。

アプリケーションの始動アプリケーションにはインストール時にカスタマイズしてアプリケーション・ファイルとともに保管できる構成ファイルが含まれています。これらの構成ファイルには通常、アプリケーションの始動時に使用される、パス名やログ・ファイルなどの情報が保管されます。

ご使用の構成で以下の両方の条件が該当する場合は、構成ファイルをカスタマイズする必要があります。

v 構成ファイルを共用ファイルシステムに保管する予定である。

v アプリケーションは、すべてのフォールオーバー・ノード上で同じ構成を使用できるわけではありません。

これは、アプリケーションが通常、構成が異なる複数のノードで実行される場合に一般的な状況です。例えば、2 ノードの相互テークオーバー構成では、同一アプリケーションの異なるインスタンスを両方のノードが実行していて、互いにスタンバイになる場合があります。各ノードは、アプリケーションの両方のインスタンス用の構成ファイルの位置を認識したうえで、フォールオーバー後に構成ファイルにアクセスできなければなりません。構成ファイルにアクセスできない場合、フォールオーバーが失敗し、重要なアプリケーションをクライアントが使用できなくなります。

構成ファイルのカスタマイズの作業を軽減するには、重要なアプリケーションのスタートアップ・ファイルとして、内容がわずかに異なる始動ファイルを両方のノードのローカル・ファイルシステムに配置します。これによりアプリケーションの初期パラメーターを静的な状態で維持するため、アプリケーションが呼び出されるたびにパラメーターを再計算する必要がなくなります。

共用 SCSI ディスクのインストール計画以降のセクションでは、HACMP クラスターのセットアップに必要な、基本的なハードウェア・コンポーネントについて簡単に説明します。

計画 83

クラスターの要件は、指定する構成によって異なります。必要なすべてのコンポーネントを含めるため、ご使用のシステムのダイアグラムを作成してください。また、構成する特定のデバイスの配線および接続についての詳細を、ハードウェアのマニュアルを参照してください。

HACMP および仮想 SCSIHACMP は、適切な APAR がインストールされた VIO (仮想入出力) SCSI をサポートしています。

クラスター構成で仮想 SCSI (VSCSI) ディスクを使用する場合は、以下の制約事項が適用されます。

v ボリューム・グループは、「拡張コンカレント・モード」として定義される必要があります。拡張コンカレント・モードでは、複数の HACMP ノードからボリュームにアクセス可能になり、その結果としてノード障害発生時のフェイルオーバーが迅速化されるため、一般にこのモードは、HACMP クラスターでボリューム・グループを共用するための推奨モードです。

v スタンバイ・ノードでファイルシステムを使用している場合は、これらのファイルシステムはフォールオーバー時点までマウントされないため、スタンバイ・ノード上のデータが誤って使用されることはありません。

v 拡張コンカレント・モードで共用ボリュームに直接 (ファイルシステムを使用せずに) アクセスする場合は、これらのボリュームには複数のノードからアクセスできるため、データベースなどの高位層でアクセスを制御する必要があります。

v いずれかのクラスター・ノードが VSCSI を介して共用ボリュームにアクセスする場合は、すべてのノードが同じようにアクセスする必要があります。これは、VSCSI を使用する LPAR とディスクに直接アクセスするノードの間では、ディスクを共用できないためです。

v VIO サーバーの視点から見た場合、論理ボリュームやボリューム・グループではなく、物理ディスク(hdisk) が共用されます。

v これらの共用ディスク上でのボリューム・グループの構築とメンテナンスはすべて、VIO サーバーからではなく HACMP ノードから実行されます。

ディスク・アダプターアダプター・カードからすべての SCSI ターミネーターを外します。HACMP クラスターでは、外部ターミネーターを使用します。共用 SCSI バスをアダプターで終端させると、そのアダプターを含むクラスター・ノードに障害が発生した場合に、終端機能が失われます。

サポートされるディスク・アダプターの全リストは、Web サイト http://www.ibm.com/common/ssi を参照してください。

国と言語を選択した後、「Search (検索)」の「Specific Information (特定のタイプ)」で「HW and SW Desc

(Sales Manual, RPQ) (HW および SW に関する情報 (含むセールス・マニュアル、RPQ))」を選択してください。

関連情報:


ケーブルクラスター内のノードを接続するために必要なケーブルは、構成する SCSI バスのタイプに応じて決まります。ディスク・アダプターおよびコントローラーと互換性のあるケーブルを選択してください。必要なSCSI ケーブルの種類と長さについては、SCSI バスを組み込む各デバイスに付属するハードウェアの資料を参照してください。



IBM 2104 Expandable Storage Plus の構成例この例は、2104 Expandable Storage Plus システムを使用した 2 ノード構成の例を示しています。

注: 他のストレージ・システムからの SCSI 接続の構成も、この例に似たものになります。

IBM DS4000 ストレージ・サーバーの構成例この例は、HACMP 環境において DS4000 ストレージ・サーバー (旧名 FAStT) を使用して高可用性を実現するための推奨構成を示しています。

以下の図を参照してください。

ノード A

Low Voltage Differential/SCSIシングル・エンドアダプター

ノード B

Low Voltage Differential/SCSIシングル・エンドアダプター

2104Expandable Storage Plus

c_2104

ノード A

ファイバー・チャネル・ホスト・バス・アダプター

DS4000

c_fa

stt

ノード B


ノード C


ファイバー・チャネル・スイッチ

ファイバー・チャネル・スイッチ

計画 85

IBM 2105 Enterprise Storage Server の構成例IBM Web サイトの情報には、IBM 2105 Enterprise Storage Server のダイアグラムがいくつか含まれています。

このモデルに関する資料は、ストレージ・ソリューションの Web サイトから検索します。

ESS 機能の使用による高可用性の実現

HACMP 環境で ESS を使用する場合は、次のようにします。

v スペアリング機能を使用して予備ディスクを割り当て、データ喪失の可能性を減らします。ESS は、ディスクで障害が発生していることを検出すると、データをそのディスクから予備デバイスへ転送します。ドロワーあたり 1 つ以上のディスクを予備ディスクとして指定する必要がありますが、可用性を強化するために 1 つのドロワーに 2 つの予備ディスクを指定することもできます。

v 1 つのベイにある 2 つのホスト・インターフェース・カードを、同じベイにあるデバイス・インターフェース・カードに対して構成します。

v 同じインターフェース・カード上の SCSI ポートを ESS の同じ区画に構成します。

スイッチド・ファブリックを使用した場合:

v ファイバー・チャネル・スイッチは、ホストの World Wide Node Name (WWN) を使用して構成する必要があります。

v スイッチ内でゾーニング (経路指定に類似) を構成する必要があります。

関連情報:

ストレージ・ソリューション

共用 IBM SSA ディスク・サブシステムのインストール計画このセクションでは、HACMP での SSA ディスクの使用について説明します。このセクションは、ご使用の特定 SSA ディスク・サブシステム・ハードウェアを解説している IBM マニュアルの補足となっています。

AIX と HACMP レベル以前のバージョンの HACMP からアップグレードする場合は、SSA コンカレント・モードで既存のボリューム・グループを使用できますが、C-SPOC は、このタイプのグループを新規に作成することはできません。このボリューム・グループは拡張コンカレント・モードに変換できます。または、このボリューム・グループは、最初の varyon 時に HACMP が自動的に変換します。

ディスク・アダプターさまざまなタイプのディスク・アダプターについて計画を立てることができます。

SSA ディスク・サブシステムとノードの接続方法については、ご使用のハードウェアの IBM マニュアルを参照してください。

注: SSA 4 ポート・アダプター (フィーチャー・コード 6218、タイプ 4-J) は、ループあたり 1 つのアダプターしかサポートしていないため、HACMP での使用には適していません。

Advanced SerialRAID アダプター (フィーチャー・コード 6225、タイプ 4-P)

6225 SSA アダプター (8 ウェイ・アダプターとも呼ばれる) は、ループあたり最大 8 つの 8 ウェイ・アダプターを備えた SSA ループをサポートします。ほとんどのマルチノード構成で Single Point of Failure


http://www.storage.ibm.com/solutions/index.html

を最小限に抑えるには、8 ウェイ・アダプターが必要です。ループ内のドライブがいずれも RAID 5 用に構成されている場合でも、ループ内で使用できるアダプターは 2 つだけに限られます。

これらのアダプターはマイクロコード・レベル 1801 以降である必要があります。

SSA Multi-Initiator RAID/EL アダプター (フィーチャー・コード 6215 タイプ 6-N)

アダプターの高速書き込みキャッシュまたは RAID 機能が使用されているときは、SSA ループ内の他のアダプターをこのアダプターに接続することはできません。これらの機能が使用されている場合は、2 次SSA Multi-Initiator RAID/EL アダプターをループ内に接続できます。

ディスク・アダプターの識別

2 ウェイ・ディスク・アダプターと 8 ウェイ・ディスク・アダプターは同じように見えますが、それぞれのマイクロコードは異なります。これらのアダプターを識別する最も簡単な方法は、アダプターをマシンにインストールし、以下のいずれかのコマンドを実行することです。

lsdev -Cc adapter

または

lscfg -vl ssaX

ここで X はアダプター番号です。

これらのコマンドにより、マイクロコードの識別情報が表示されます。

バイパス・カード

7133 モデル T40 および D40 ディスク・サブシステムには 4 つのバイパス・カードが組み込まれています。各バイパス・カードは 2 つの外部 SSA コネクターを備えています。これらのコネクターを使用して、バイパス・カード、したがって一連のディスク・ドライブ・モジュールを相互に接続するか、ノードに接続します。

バイパス・カードは、バイパス・モードまたは強制インライン・モードで動作します。

バイパス・モード

バイパス・カードがバイパス・モードで動作するようにジャンパーを設定すると、外部接続が両方ともモニターされます。いずれかのコネクターが電源の入った SSA アダプターまたはデバイスに接続されていることが検出されると、自動的にインライン・モードに切り替えられます。つまり、内部 SSA リンクが外部コネクターに接続されます。これにより、SSA ループの切断が大幅に緩和されます。

バイパス・カードによっていずれのコネクターも電源の入った SSA アダプターまたはデバイスに接続されていないことが検出されると、バイパス状態に切り替えられます。つまり、内部の一連のディスクを接続し、これを外部コネクターから切断します。

強制インライン・モード

バイパス・カードが強制インライン・モードで動作するようにジャンパーを設定すると、永続的に、モデル010 および 500 のシグナル・カードのように振る舞います。つまり、電子交換回路はいずれも使用されなくなります。内部 SSA リンクは外部コネクターに接続し、内部バイパス接続を確立することは不可能になります。

計画 87

SSA 機能の使用による高可用性の実現このセクションでは、SSA 機能を使用してシステムの高可用性を実現する方法について説明します。

SSA ループ

すべての SSA デバイスを単に 1 列に接続するのではなく、ループ構成にします。SSA デバイスは 1 列に接続された状態でも機能しますが、ループでは各デバイスに対して 2 つの通信経路が提供されるため、冗長性が強化されます。アダプターは、ディスクへの最短経路を選択します。

SSA 光ファイバー・エクステンダー

SSA 光ファイバー・エクステンダーは、単一 SSA ケーブルの代わりに最長 2.4 Km のケーブルを使用します。SSA 光ファイバー・エクステンダー (フィーチャー・コード 5500) は、すべてのモデル 7133 ディスク・サブシステムで使用できます。

光ファイバー・エクステンダーを使用すると、ディスク間の距離を LAN で可能な距離よりもさらに拡張できます。この場合、ルーターおよびゲートウェイを使用できません。したがって、この条件下では、2 つの LAN にまたがる HACMP クラスターは形成できません。

アダプターのデイジー・チェーン接続

各ノードで、そのノードを含むループごとに、すべてのアダプターをデイジー・チェーン接続します。SSAR ルーター・デバイスは、1 つのアダプターで障害が発生したことを検出すると別のアダプターを使用します。ノード内のアダプターのデイジー・チェーン全体を 1 つのバイパス・スイッチだけで処理できるため、アダプターごとにバイパス・スイッチを用意する必要はありません。

7133 モデル D40 および T40 ディスク・サブシステムのバイパス・カード

バイパス・カードは、ノードでの障害発生時、ノードの電源オフ時、あるいはノード内のアダプターでの障害発生時にも、高可用性を維持します。1 つのバイパス・カードの両ポートを、1 つのノードをはさむループに接続します。つまり、バイパス・カードを 1 つのノードだけに接続します。1 つのノードで複数のアダプターを使用する場合は、アダプターをデイジー・チェーン接続してください。

バイパス・カードがバイパス・モードに切り替わるときには、次の 2 つの状況が発生しないようにしてください。

v 2 つの独立したループをバイパス・カードで接続しないでください。バイパス・カードがバイパス・モードに切り替わったときに、2 つの独立したループを接続するのではなく、バイパス・カードを 7133

ディスク・サブシステム内のループに再び接続するようにします。このため、バイパス・カードの両方のポートは同じループに存在する必要があります。

v ダミー・ディスクは、SSA ループが切断されずに継続するように 7133 ディスク・サブシステム内のディスク・ドライブ・スロットを埋めるためのコネクターです。バイパス・カードがバイパス・モードに切り替わるときに、バイパス・カードが同じループ内で連続して接続するダミー・ディスクが必ず 3 つ以下になるようにしてください。ディスクをバイパス・カードの隣に配置し、ダミー・ディスクを実ディスクの間に配置します。

単一障害点を最小限に抑える構成単一障害点を最小限に抑えるには、構成におけるさまざまな点を考慮してください。



v 論理ボリューム・ミラーを使用し、別々のアダプターを使用して論理ボリューム・ミラー・コピーを独立したディスク、および独立したループに配置します。さらに、前列のディスクと後列のディスクの間、またはディスク・サブシステム間でミラーリングを行うことをお勧めします。

– バイパス・カード自体が Single Point of Failure になるのを回避するには、以下のいずれかのメカニズムを使用します。

- 1 つのループの使用。2 つのバイパス・カードが、ノードを接続している 1 つのループの中に含まれるようにします。

- 2 つのループの使用。2 つ目のループでディスクに論理ボリューム・ミラーリングを行うように設定します。それぞれのループが個別のバイパス・カードを介して各ノードに至るように設定します。

以下の構成では、バイパス・カードを強制インライン・モードに設定してください。

v 複数の 7133 ディスク・サブシステムを接続する場合。

v 1 つの 7133 モデル D40 またはモデル T40 に組み込まれている複数のディスク・ドライブがすべて同じ SSA ループに接続されていない場合。このタイプの構成では、強制インライン・モードに設定すると障害状態になる危険性が取り除かれます。すなわち、バイパス・モードにシフトすることにより、別のループのディスク・ドライブが接続される可能性が生じます。

最適なパフォーマンスの構成最適なパフォーマンスを得られるようにシステムを構成するとき、役立つと考えられるガイドラインがいくつかあります。

これらのガイドラインには、以下のものがあります。

v 複数のノードと SSA ドメインの検討

– 1 つのノードと、このノードがアクセスする複数のディスクが 1 つの SSA ドメインを形成します。共用ディスク・ドライブと複数のノードを含む構成の場合、各ノードからノードがアクセスするディスク・ドライブへのパス長を最小に抑えます。パス上のディスク・ドライブとアダプターの数に基づいて、パスの長さを見積もります。各デバイスはデータ・パケットを受信し、転送する必要があります。

– ループ内に複数のアダプターがある場合は、ディスクを最も近いアダプターに隣接させ、そのアダプターをディスクにアクセスさせます。実際には、入出力トラフィックを SSA ドメイン内にとどめるようにしてください。ホストはいずれも任意のディスクにアクセスできますが、他のドメインにわたる入出力トラフィックは最小限に抑えることをお勧めします。

– 複数のホストが 1 つのループ内に存在する場合は、ノードが最も近いディスクを使用するようにボリューム・グループをセットアップします。これにより、1 つのノードの入出力によって別のノードの入出力が妨げられることがなくなります。

v 読み取り / 書き取り操作をループ全体で均等に分散します。

v ディスクをループ間で均等に分散します。

v ハードウェア交換時にマイクロコードをダウンロードします。

すべてが適切に機能するようにするため、ディスク・サブシステムの最新のファイルセット、修正プログラム、マイクロコードをインストールします。

ループのテストいくつかの方法でループをテストします。

ループをテストするには、以下の手順を実行します。

計画 89

v すべてのループ・シナリオ (特に複数ノード・ループ) を綿密にテストします。ループの切断 (1 つまたは複数のアダプターの障害) がないかどうかをテストします。

v アダプターおよびノードの電源損失の際に使用するバイパス・カードをテストし、構成ガイドラインに準拠しているかどうかを確認します。

コンカレント・アクセス・クラスターの SSA ディスク・フェンシングTCP/IP ネットワーク通信の喪失が原因で発生する可能性があるデータ保全性の問題を防ぐことは、複数のノードが同時に共用ディスクにアクセスするコンカレント・アクセス構成の場合は特に重要です。

『クラスター・ネットワーク接続の計画』で、HACMP 固有の Point-to-Point ネットワークで区分クラスターを防止する方法について説明しています。

SSA ディスク・サブシステムを使用したコンカレント・アクセス構成では、区分クラスターで発生する可能性があるデータ保全性の問題を、ディスク・フェンシング機能を使用して防止することもできます。ディスク・フェンシングは、拡張コンカレント・モードで使用できます。

SSA ディスク・サブシステムにはディスクごとに 1 つのフェンス・レジスターが組み込まれ、予想される32 の各接続についてアクセスを許可、または禁止できます。フェンシングにより、1 つ以上のノードが協調性のない動作でディスクにアクセスすることを防止できます。

SSA のハードウェアには、フェンス・レジスターを自動的に更新するためのフェンシング・コマンドがあります。このコマンドによって、複数のノードがそれぞれ同じフェンス・レジスターを更新しようとした場合に、コントローラー内で競合の調停機能が提供されます。フェンシング・コマンドの比較交換プロトコルによって、各ノードに対し、フェンス・レジスターの現行内容と要求内容の両方を提供することが要求されます。競合するノードがほぼ同時にレジスターを更新しようとした場合、1 番目のノードは更新に成功しますが、2 番目のノードは改訂された内容を認識していないため更新に失敗します。

ディスク・フェンシングの利点

ディスク・フェンシングは、コンカレント・アクセス・クラスターに次のような利点を示します。

v ディスク・フェンシングは、クラスターのアクティブ・メンバーではないノードが共用ディスク上のデータを変更できないようにすることにより、データ・セキュリティーを強化します。HACMP ソフトウェアは、フェンス・レジスターを管理することによって、クラスター内の指定されたノードだけに共用SSA ディスクへのアクセスを可能とすることができます。

v ディスク・フェンシングは、競合するノードによって共用データの整合性が失われないようにすることで、データの信頼性を高めます。HACMP は、フェンス・レジスターを管理することによって、区分クラスターによる協調性のないディスク管理を防止できます。区分クラスター内では、通信障害が発生すると、複数のクラスター・ノード・セットがそれぞれ、自身がクラスター内で唯一のアクティブ・ノード群であると認識してしまいます。個々のノード・セットが、共用ディスクをテークオーバーしようとして競合状態になります。ディスク・フェンシングの競合時の調停機構は競争状態を調停し、1 つのノード・セットのみがディスクへのアクセス権を獲得するようにします。

関連資料:


SSA ディスク・フェンシングのインプリメンテーション:

HACMP ソフトウェアはフェンス・レジスターの内容を管理します。


クラスター構成時に、各共用ディスクのフェンス・レジスターは、指定されたノードにアクセスを許可するように設定されます。ノードがクラスターに結合またはクラスターから分離されることでクラスター・メンバーシップが変更されると、イベント・スクリプトが cl_ssa_fence ユーティリティーを呼び出し、フェンス・レジスターの内容を更新します。フェンシング・コマンドが正常に終了した場合、スクリプトは処理を続行します。操作が失敗すると、スクリプトは失敗して終了します。これが原因で、クラスターが再構成されます。

関連情報:

JOB_TYPE= SSA_FENCE

SSA ディスクをコンカレント・モードで使用するディスク・フェンシング:

SSA ディスク・フェンシングの目的は、1 つまたは 2 つ以上のクラスター・ノードが残りのクラスターから分離された場合に、共用 SSA ディスク・リソースを保護するための安全なロックアウト・メカニズムを提供することです。

SSA ディスク・フェンシングは、次の条件の下でのみ使用できます。

v コンカレント・モードのボリューム・グループに含まれているディスクのみが隔離されます。

v クラスターの全ノードがこれらのディスクにアクセスでき、ディスク・フェンシングを使用するように構成します。

v ディスク・フェンシング属性が使用可能に設定されたすべてのリソース・グループは、コンカレント・アクセス・リソース・グループである必要があります。

v コンカレント・アクセス・リソース・グループには、クラスター内のすべてのノードを含める必要があります。ディスク・フェンシングがアクティブになっており、システムがコンカレント・リソース・グループに含まれていないノードを検出すると、検証ユーティリティーはエラーを発行します。

コンカレント・モードのディスク・フェンシングは、次のように機能します。

v クラスター内で最初に稼働状態になったノードは、そのクラスターにある他のすべてのノードを、フェンシングが有効化されているコンカレント・アクセス・ボリューム・グループのディスクにアクセスできないよう隔離するために、それらのディスクのフェンス・レジスターを変更します。

v ノードがクラスターに結合すると、そのクラスター内のアクティブ・ノードは、結合するノードにアクセスを許可するために、そのノードとともにフェンシングに参加しているすべてのディスクのフェンス・レジスターを変更します。

v ノードがクラスターから分離されると、その分離方法に関係なく、切り離されたノードとディスクへのアクセスを共用する残りのノードは、可能な限り早く、分離されたノードを隔離する必要があります。

v クラスター・サービスの停止時にリソース・グループがオフライン状態になるか UNMANAGED 状態に設定されるかにかわらず、最後にクラスターから分離されるノードは、フェンス・レジスターをクリアしてすべてのノードによるアクセスを許可します。当然ながら、最後のノードが予期せず停止 (電源オフやクラッシュなど) した場合、ノードはフェンス・レジスターをクリアしません。この場合は、適切なSMIT オプションを使用して手動でフェンス・レジスターをクリアする必要があります。

関連情報:

HACMP クラスターのトラブルシューティング

SSA ディスク・フェンシングの使用可能化:

コンカレント・リソース・グループの SSA ディスク・フェンシングを使用可能にするプロセスでは、クラスター・リソースの同期時に、クラスター・ノード上の SSA ディスクを含むすべてのボリューム・グループがオフに変更されていて、クラスターがダウンしている必要があります。

計画 91

したがって、クラスター・リソースの同期時に、ディスク・フェンシングを使用可能にするプロセスを正常に実行するには、コンカレントか非コンカレントか、および、クラスターの一部として構成されているかどうかに関係なく、SSA ディスクを含んでいるすべてのボリューム・グループをオフに変更しておく必要があります。これらの条件が満たされていない場合は、ノードをリブートしてフェンシングを使用可能にする必要があります。

注: ディスク・フェンシングが使用可能になっており、コンカレント・アクセス・リソース・グループにすべてのノードが含まれていない場合は、クラスター・リソースの検証時にエラーが発生します。

ディスク・フェンシングを使用可能にする処理は、各クラスター・ノードで次のように実行します。

HACMP 構成内のノードの node_id に一致する ssar に node_number を割り当てます。ノード番号を割り当てるには、次の手順を実行してください。

1. 次のコマンドを発行します。

chdev -l ssar -a node_number=x

x は、対象ノードに割り当てる番号です。

ディスク・フェンシングを使用可能にする前に、ドライブまたは C-SPOC コンカレント LVM 機能を置き換える目的で設定されたすべての node_numbers は、ディスク・フェンシング操作用に変更されます。この node_number の変更により、他の操作が影響を受けることはありません。

2. ノードによって認識される SSA ディスク・サブシステムのすべての hdisk、pdisk、ssa アダプター、および tmssa デバイスをまず除去してから再構築して、各ディスクのフェンス・レジスターで使用するための node_number を選択します。

3. システムをリブートします。

ディスク・フェンシングと動的再構成:

クラスター・ノードが稼働状態の間に、動的再構成によってクラスターにノードを追加した場合、ディスク・フェンシングの使用可能化プロセスは、トポロジーの同期化時に、追加されたノード上でのみ行われます。

ディスク・フェンシングを使用可能にする前に (ドライブまたは C-SPOC コンカレント LVM 機能を置き換える目的で) 設定されたすべての node_numbers は、ディスク・フェンシング操作用に変更されます。したがって、最初にリソース・グループ内に SSA ディスク・フェンシングを設定する場合は、クラスターがダウン状態の間にリソースを同期化する必要があります。この node_number の変更により、他の操作が影響を受けることはありません。

ディスク・ワークシートの記入クラスターに組み込むディスク・ストレージ・テクノロジーを決定したあと、該当するすべてのワークシートに情報を記入します。

共用 SCSI ディスク・ワークシートの記入それぞれの共用 SCSI ディスク・アレイごとに、共用 SCSI ディスク・ワークシートに情報を記入します。

共用 SCSI ディスク・ワークシートに記入するには、次の手順を実行します。

1. 該当するフィールドにクラスター名を入力します。この情報は、『クラスターの初期計画』で決めた情報です。


2. SCSI バスのタイプの該当するフィールドを確認します。

3. ノード名、ディスク・アダプターが装着されているスロットの数、scsi0 などのアダプターの論理名を含む、ホストおよびアダプター情報を記入します。AIX は、アダプターの構成時に、この論理名を割り当てます。

4. SCSI バスに接続するすべてのデバイスの SCSI ID を判別します。

5. このバス上で使用可能なディスク・ドライブに関する、各ノード上のディスクの論理デバイス名などの情報を記録します。(この hdisk 名は、デバイスの構成時に AIX によって割り当てられ、ノードごとに異なる可能性があります。)

関連資料:

210ページの『共用 SCSI ディスク・ワークシート』このワークシートは、クラスターの共用 SCSI ディスク構成を記録するために使用します。共用バスごとに個別のワークシートに記入してください。


共用 SCSI ディスク・アレイ・ワークシートの記入それぞれの共用 SCSI ディスク・アレイごとに、共用 SCSI ディスク・アレイ・ワークシートに情報を記入します。

共用 IBM SCSI ディスク・アレイ・ワークシートに記入するには、次の手順を実行します。


2. ノード名、ディスク・アダプターが装着されているスロットの数、scsi0 などのアダプターの論理名を含む、ホストおよびアダプター情報を記入します。AIX は、アダプターの構成時に、この論理名を割り当てます。

3. SCSI バスに接続されたすべてのデバイスに SCSI ID を割り当てます。ディスク・アレイの場合は、ディスク・アレイ上のコントローラーに SCSI ID が割り当てられます。

4. ディスク・アレイ上に構成されている LUN に関する情報を記録します。

5. AIX によりアレイ・コントローラーに割り当てられた論理デバイス名を記入します。

関連資料:

210ページの『共用 IBM SCSI ディスク・アレイ・ワークシート』このワークシートは、クラスターの共用 IBM SCSI ディスク・アレイ構成を記録するために使用します。共用 SCSI バスごとに個別のワークシートに記入してください。


IBM SSA ディスク・サブシステム・ワークシートの記入それぞれの共用 SSA 構成ごとに、IBM SSA ディスク・サブシステム・ワークシートを作成します。

共用 IBM シリアル・ストレージ・アーキテクチャー・ディスク・サブシステム・ワークシートに記入するには、次の手順を実行します。


計画 93

2. ノード名、SSA アダプター・ラベル、ディスク・アダプターが装着されているスロットの数を含む、ホストおよびアダプター情報を記入します。接続のデュアル・ポート番号も記入します。これは、ループ接続を明確にするために必要となります。

関連資料:


213ページの『共用 IBM シリアル・ストレージ・アーキテクチャー・ディスク・サブシステム・ワークシート』このワークシートは、クラスターの IBM 7131-405 または 7133 SSA 共用ディスク構成を記録するために使用します。

クラスター・ダイアグラムへのディスク構成の追加ディスク・テクノロジーを選択した後、『クラスターの初期計画』で開始したクラスター・ダイアグラムにディスク構成を追加します。

クラスター・ダイアグラムでは、各共用ディスクを表すボックスを描きます。各ボックスに、共用ディスク名を追加します。

関連資料:


クラスター・リソースとしてのテープ・ドライブに関する計画磁気テープ・ドライブをクラスター・リソースとして構成し、クラスター内の複数のノードでの可用性を高めることができます。

SCSI ストリーミング磁気テープ・ドライブと Direct Fibre Channel テープ装置接続機構がサポートされています。次の HACMP 機能によって、共用磁気テープ・ドライブの管理が簡単になります。

v SMIT を使用した磁気テープ・ドライブの構成

v 磁気テープ・ドライブの適切な構成の検証

v リソース・グループの始動操作時および停止操作時の磁気テープ・ドライブの自動管理

v ノード障害時およびノード回復時の磁気テープ・ドライブの再割り当て

v クラスター・シャットダウン時の磁気テープ・ドライブ再割り当て制御

v 動的再構成時の磁気テープ・ドライブ再割り当て制御

制限

磁気テープ・ドライブをクラスター・リソースとして組み込む場合は、次の点に注意してください。

v サポートされるドライブは、ハードウェア予約機能とハードウェア・リセット/解放機能を備えた、SCSI

磁気テープ・ドライブまたは Direct Fibre Channel 磁気テープ・ドライブのみです。

v HACMP では、テープ・ローダー/スタッカーが単純な磁気テープ・ドライブと同様に扱われます。

v テープ・リソースを共用できるクラスター・ノードは 2 つまでです。

v テープ・リソースをコンカレント・リソース・グループに含めることはできません。


v 磁気テープ・ドライブの名前 (/dev/rmt0 など) は、テープ・デバイスを共用する両方のノード上で同一である必要があります。

v テープ特殊ファイルをクローズする際のデフォルトのアクションは、磁気テープ・ドライブを解放することです。HACMP は、アプリケーションがテープをオープンした後は、磁気テープ・ドライブの状態を管理しません。

v テープ操作とアプリケーション・サーバーの同期化は行われません。テープの予約/解放を非同期で実行する必要がある場合は、アプリケーション・サーバーに待機命令を出し、予約/解放が完了するまで処理を中断させる仕組みを作成します。

v 複数の SCSI インターフェースを備えた磁気テープ・ドライブはサポートされません。したがって、ノードと磁気テープ・ドライブの接続は 1 つだけになります。通常のアダプター・フォールオーバーの機能は適用されません。

関連情報:

共用磁気テープ・ドライブの取り付けおよび構成

共用磁気テープ・ドライブの予約および解放テープ・リソースが含まれているリソース・グループがアクティブになると、磁気テープ・ドライブの排他使用を許可するため、磁気テープ・ドライブが予約されます。

この予約は、アプリケーションがその磁気テープ・ドライブを解放するまで、あるいは、そのノードがクラスターから除去されるまで保持されます。

v テープの特殊ファイルをクローズする際のデフォルトのアクションは、磁気テープ・ドライブを解放することです。アプリケーションは、「クローズ時に解放しない」ことを示すフラグを使用して磁気テープ・ドライブをオープンできます。HACMP は、アプリケーションの始動後はこの予約を管理しません。

v ノード上のクラスター・サービスを停止してリソース・グループをオフライン状態にすると、磁気テープ・ドライブが解放されて、他のノードがそのドライブにアクセスできるようになります。

v 予期せぬノード障害が発生すると、テークオーバー・ノード上で強制解放が実行されます。その後、この磁気テープ・ドライブは、リソース・グループ活動化の一環として予約されます。

磁気テープ・ドライブの同期操作または非同期操作の設定

テープの予約または解放が開始され、テープ操作が進行中になると、予約または解放操作が終了するまで時間がかかることがあります。HACMP では、同期および非同期の予約操作と解放操作を実行できます。同期および非同期の操作は、予約と解放それぞれに指定します。

同期操作

同期操作 (デフォルト値) では、HACMP は、予約操作または解放操作 (ユーザー定義の回復手順の実行を含む) が完了するまで、処理が中断されます。

非同期操作

非同期操作では、HACMP は予約または解放操作を実行する子プロセス (ユーザー定義の回復手順の実行を含む) を作成し、すぐに処理を継続します。

回復手順回復手順は、磁気テープ・ドライブにアクセスするアプリケーションに大きく左右されます。

計画 95

HACMP では、発生する可能性のあるシナリオを予測して HACMP 自体が回復手順を作成するのではなく、次の操作のユーザー定義回復スクリプトが実行されます。

v テープ始動

v テープ停止

テープの始動スクリプトおよび停止スクリプト

テープの始動と停止は、ノードの始動と停止、ノードのフォールオーバーと再統合、および動的再構成中に発生します。これらのスクリプトは、リソース・グループがアクティブになった際 (テープの始動) またはリソース・グループが非アクティブになった際 (テープの停止) に呼び出されます。サンプルの起動スクリプトと停止スクリプトは、/usr/es/sbin/cluster/samples/tape ディレクトリーに格納されています。

tape_resource_stop_example

v HACMP は、テープの始動時に磁気テープ・ドライブを予約し、必要であれば強制解放してから、ユーザー提供のテープ起動スクリプトを呼び出します。

v テープの停止時には、HACMP はユーザー提供のテープ停止スクリプトを呼び出してから、磁気テープ・ドライブを解放します。

注: これらのスクリプト内での、テープの正しい位置設定、磁気テープ・ドライブに書き込みを行うプロセスまたはアプリケーションの終了、テープの終わりマークの書き込みなどは、ユーザー側で行ってください。

その他のアプリケーション固有の手順は、サーバー起動スクリプトおよびサーバー停止スクリプトの一部として組み込みます。

アダプターのフォールオーバーと回復

複数の SCSI インターフェースを備えた磁気テープ・ドライブはサポートされません。したがって、ノードと磁気テープ・ドライブの接続は 1 つだけになります。通常のアダプターのフォールオーバーの概念は適用されません。

ノードのフォールオーバーと回復

HACMP のリソース・グループに属するテープ・リソースを持つノードで障害が発生すると、テークオーバー・ノードが磁気テープ・ドライブを予約し、必要であれば強制的に解放してから、ユーザー提供のテープ起動スクリプトを呼び出します。

ノードの再統合時には、テークオーバー・ノードがテープ停止スクリプトを実行した後で、磁気テープ・ドライブを解放します。再統合中のノードは、磁気テープ・ドライブを予約してから、ユーザー提供のテープ起動スクリプトを呼び出します。

ネットワークのフォールオーバーと回復

HACMP には、ネットワーク障害に対するテープ・フォールオーバー/回復手順は用意されていません。

共用 LVM コンポーネントの計画このトピックでは、HACMP クラスター用の共用ボリューム・グループの計画方法について説明します。


前提条件

この時点で、以下に示す前出のセクションの計画ステップを完了している必要があります。

また、論理ボリューム・マネージャー (LVM) の使用方法について十分理解している必要があります。

関連情報:

OEM ディスク、ボリューム・グループ、およびファイルシステムの統合

GPFS クラスター構成

オペレーティング・システムおよびデバイスのマネージ

概説HACMP クラスターの共用 LVM コンポーネントの計画は、共用ディスク・デバイスのタイプ、および共用ディスク・アクセスの方法によって異なります。

データ・ストレージの Single Point of Failure を回避するには、LVM またはご使用のストレージ・システムでサポートされるデータ冗長度を使用してください。

LVM コンポーネントの計画LVM は、物理ストレージと論理ストレージの間でデータをマッピングすることにより、ディスク・リソースを制御します。

物理ストレージとは、ディスク上のデータの実際のロケーションを指します。論理ストレージは、ユーザーがデータを使用する方法を制御します。論理ストレージは隣接していなくてもよく、拡張、複製することが可能なほか、複数の物理ディスクにわたって構成できます。これらの機能によってデータの可用性が向上します。

物理ボリューム物理ボリュームとは、ストレージ・アレイによって提供される、単一の物理ディスクまたは論理ユニットのことです。

物理ボリュームは、ボリュームへのデータのマッピング方法を管理するための方法を AIX に提供するために、区画に分割されます。次の図は、物理ボリューム内にある物理区画の標準的な使用法を示したものです。

&'()

&'ボリューム f_dis

kpart

1

共有物理ボリュームを計画する場合は、以下の点を確認してください。

v ボリューム・グループの PVID のリストが、共有物理ボリュームにアクセス可能なすべてのクラスター・ノードで同じである。

v ボリューム・グループのコンカレント属性の設定が、すべての関連するクラスター・ノードで一貫している。

計画 97

ボリューム・グループボリューム・グループは、AIX が連続したアドレス可能ディスク領域として扱う物理ボリュームのセットです。複数の物理ボリュームを同じボリューム・グループに含めることができます。実際の数は、ボリューム・グループがどのように作成されるかによって異なります。詳しくは、mkvg を参照してください。

次の図は、3 つの物理ボリュームからなるボリューム・グループを示しています。

HACMP 環境では、共用ボリューム・グループは、クラスター・ノードが共用する外部ディスク上にグループ全体が存在するボリューム・グループです。非コンカレント共用ボリューム・グループは、一度に 1

つのノードのみでオンに変更できます。

共用ボリューム・グループで作業する場合には、以下の点に注意してください。

v 他のノードから内部ディスクへはアクセスできないので、内部ディスクを共用ボリューム・グループに組み込まないようにする。内部ディスクを共用ボリューム・グループに組み込むと、varyonvg コマンドが失敗します。

v システム・ブート時に HACMP クラスター内の共用ボリューム・グループを手動で活動化 (オンに変更)

しないようにする。この活動化を行うには、クラスター・イベント・スクリプトを使用してください。

v リソース・グループ内にリストされた共有ボリューム・グループに対し、AIX ODM の自動 varyon 属性が「No (いいえ)」に設定されていることを確認する。HACMP のクラスター検証ユーティリティーは、クラスター・リソースの検証時にこの属性を自動的に修正して、自動 varyon 属性を「No (いいえ)」に設定します。

v HACMP にボリューム・グループを定義する場合、HACMP が他のノード上で実行している間は、HACMP の外側のノードで手動でボリューム・グループを管理しないようにする。これを行った場合、予期しない結果が生じる可能性があります。HACMP には関係なくボリューム・グループに対してアクションを実行する場合は、クラスター・サービスを停止し、ボリューム・グループの手動管理タスクを実行して、ボリューム・グループをオフにしてから、HACMP を再始動してください。HACMP での物理ボリュームの使用を簡単に計画できるよう、検証ユーティリティーは以下の内容をチェックします。

– ボリューム・グループの整合性

– ディスクの可用性

論理ボリューム論理ボリュームとは、AIX が単一の記憶装置として使用可能にする論理区画の集合、つまりディスクの論理ビューを指します。

論理区画は物理区画の論理ビューです。論理区画は、ミラーリングをインプリメントするために、1 つ、2

つ、または 3 つの物理区画にマッピングできます。

HACMP 環境では、論理ボリュームはジャーナル・ファイルシステムまたはロー・デバイスをサポートできます。


ファイルシステムファイルシステムは、単一の論理ボリュームに書き込まれます。

通常は、データの管理を容易、かつ高速化するためにファイルの集合をファイルシステムとして編成します。

HACMP システムにおいて、共用ファイルシステムとは、全体が共用論理ボリュームに存在するジャーナル・ファイルシステムを指します。

クラスター・ノードによって共用される外部ディスク上に共用ファイルシステムを配置するよう計画します。これらの外部共用ディスクのファイルシステムにデータを常駐させるのは、その可用性を高めるためです。

ファイルシステムをマウントする順番は、通常は重要ではありません。ただし、順番がクラスターに影響を与える場合は、考慮する必要があります。

v 単一のリソース・グループ上に存在するファイルシステムは、リソース・グループがオンラインで始動した際に英数字順にマウントされます。また、リソース・グループがオフラインになると、ファイルシステムは英数字の逆の順番でアンマウントされます。

v ファイルシステムの共有またはネストを行っている場合には、それらを考慮する必要があります。単一リソース・グループでファイルシステムの共有またはネストを行っている場合には、リソース・グループの「Filesystems Recovery Method (ファイルシステムの回復メソッド)」に「sequential (順次)」を指定して、適切なマウント順序を確立してください。

v 異なるリソース・グループでファイルシステムをネストしている場合、適切なマウント順序を確立するために、リソース・グループの親子関係も設定する必要があります。

LVM ミラーリングの計画LVM ミラーリングでは、物理区画のコピーを複数割り当てることができるため、データの可用性を向上できます。あるディスクに障害が発生してその物理区画が使用不能になっても、使用可能なディスク上のミラーリング・データにアクセスすることができます。LVM は、論理ボリューム内部でミラーリングを実行します。

HACMP クラスター内では、次のものをミラーリングできます。

v 共用ボリューム・グループの論理ボリューム・データ

v ファイルシステムを持つ各共用ボリューム・グループのログ論理ボリューム

注: LVM ミラーリングは、IBM 2105 Enterprise Storage Server、TotalStorage DS4000、6000、8000、および RAID を使用する他のディスク・デバイスなど、独自のデータ冗長度を備えているものには適用されません。

物理区画のミラーリング論理ボリュームの可用性を向上するには、区画に含まれるデータをミラーリングするために、1 つ、2 つ、または 3 つの物理区画のコピーを割り当てます。

エラーによりコピーの 1 つが失われても、影響を受けなかった他のコピーにアクセスでき、AIX はエラーのないコピーを使用して処理を続行します。障害が発生した物理区画へのアクセスが復元されると、AIX

は物理区画の内容 (データ) を整合性のあるミラー・コピーの内容 (データ) と再同期させます。

次の図は、3 つのミラー・コピーを備えた 2 つの論理区画で構成される論理ボリュームを示しています。この図では、各論理区画が 3 つの物理区画にマッピングされています。各物理区画は、単一のボリュー

計画 99

ム・グループ内にある個別の物理ボリュームに常駐するように指定する必要があります。この構成によって、ミラー・コピーへの最大数の代替パスが提供されるため、可用性を最大限に向上させることができます。

-'()

-'()

-'ボリューム

f_dis

km

irro

r

ミラー・コピーは透過的です。つまり、これらのコピーの 1 つをユーザーが分離することはできません。例えば、複数のコピーを持つ論理ボリュームからあるファイルを削除した場合、削除されたファイルはその論理ボリュームのすべてのコピーから除去されます。

データの可用性を向上させる構成を以下に示します。

v 論理区画のコピーを 1 つまたは 2 つではなく、3 つ割り当てる。

v 論理区画のコピーを、同じ物理ボリュームに割り当てるのではなく、別々の物理ボリュームに割り当てる。

v 可能であれば、論理区画のコピーを、同じ格納装置ではなく、異なる複数の物理ディスク格納装置に割り当てる。

v 論理区画のコピーを、単一のディスク・アダプターではなく、異なる複数のアダプターに割り当てる。

複数の (個別の電源装置に接続されている) ディスクにまたがるミラー・コピーを複数のディスク・アダプターと共に使用すると、ディスクがクラスターの Single Point of Failure になることはなくなりますが、これらの構成では、書き込み操作の所要時間が増大する可能性があります。

強制 varyon が指定されるボリューム・グループの論理ボリュームには、非常に厳密なディスク割り振りポリシーを指定してください。この構成により、以下の結果を実現できます。

v 論理ボリュームのコピーが常に別のディスク上に配置されることが保証される。

v 1 つ以上のディスクで障害が発生した後の強制 varyon が成功する可能性が高くなる。

論理ボリュームに強制 varyon を使用する場合は、クラスターのディスク格納装置に非常に厳密なディスク割り振りポリシーを適用してください。

強制 varyon について詳しくは、セクション『クォーラムおよび varyon を使用してデータの可用性を高める』を参照してください。

関連資料:


106ページの『クォーラムおよび varyon を使用してデータの可用性を高める』クォーラムの構成とボリューム・グループの varyon により、ミラーリングされたデータの可用性を高めることができます。

ジャーナル・ログのミラーリング非コンカレント・アクセス構成では、ジャーナル・ファイルシステムおよび拡張ジャーナル・ファイルシステムがサポートされています。

AIX は、ファイルシステムのジャーナリングを使用します。通常、これはファイルシステムの始動時の内部状態 (ブロック・リストおよびフリー・リストから見た状態) がシャットダウン時と同じ状態であることを意味します。実際には、これは AIX が起動したときのファイル破壊の程度 (破壊されている場合) がシャットダウン時より悪化することはないということを意味します。

各ボリューム・グループには、それ自身が論理ボリュームである jfslog または jfs2log が含まれています。このログは通常、ボリューム・グループ内の、ジャーナル・ファイルシステムとは別の物理ディスクに常駐しています。ただし、そのディスクへのアクセスが失われた場合は、その時点以降にファイルシステムに加えられた変更は危険にさらされます。

物理ディスクが Single Point of Failure となる可能性を回避するには、各 jfslog または jfs2log のミラー・コピーを指定します。これらのコピーは、別の物理ボリュームに配置するようにしてください。

サイト間のミラーリング例えば、Storage Area Network (SAN) を使用して、異なる 2 箇所のサイトにあるディスクをリモートLVM のミラーリング用に設定できます。サイト間 LVM ミラーリングは、災害復旧に備え、各サイトでディスク・サブシステム間のデータを複製します。

SAN は、ストレージ・デバイスとプロセッサー (サーバー) との間に直接接続を確立できる高速ネットワークです。したがって、異なるサイトに配置された 2 つ以上のサーバー (ノード) が、共通の SAN を介して、複数の同じ物理ディスクにアクセスできます。これらのサーバーも、同様に一定の距離まで離すことができます。これらのリモート・ディスクは、AIX 論理ボリューム・マネージャーを使用して 1 つのボリューム・グループに結合でき、そのボリューム・グループを異なるサイトに配置されたノードにインポートできます。このボリューム・グループの論理ボリュームには、最大で 3 つのミラーを設定できます。したがって、少なくとも 1 つのミラーを各サイトに設定できます。この論理ボリュームに格納される情報については、高可用性が維持されます。何らかの障害が発生しても、もう一方のサイトのリモート・ミラーに最新情報が保存されているため、一方のサイトで操作を継続できます。

HACMP は、ディスクまたはノードの障害が発生し、その後に再統合が実行されてから、ミラーを自動的に同期化します。HACMP は、ディスクのいずれかが PVREMOVED または PVMISSING 状態であっても、自動的にミラーを同期化します。自動同期化はすべてのケースで実行できるとは限りませんが、ディスクまたはサイトで障害が発生し、それに伴う再統合が行われた後で、C-SPOC を使用して、障害の発生していないミラーから不整合な状態のミラーにデータを同期化できます。

あらかじめサイトおよびノードを計画しておき、この情報を共用ボリューム・グループ/ファイルシステム・ワークシートに記入します。

注: HACMP/XD では、地理的論理ボリューム・マネージャー (GLVM) のミラーリング機能を使用した、2

つのサイトにまたがるクラスターでのミラーリングも使用できます。

関連概念:

管理ガイド

計画 101

HACMP/XD for Geographic LVM: プランニングおよび管理ガイド

関連資料:

8ページの『クラスター・サイトの計画』通常、クラスター構成で使用されるサイトは 1 つですが、クラスター構成には複数のサイトを含めることができます。

ディスク・アクセスの計画拡張コンカレント・アクセスまたは非コンカレント・アクセスのいずれかを使用するようにディスクを構成できます。

v 拡張コンカレント・アクセス。ディスク上のデータは接続されたすべてのノードで同時に使用可能であり、すべてのノードはディスク上のメタデータにアクセス可能である。このアクセス・モードでは、メタデータが読み込まれる前にボリューム・グループをオンラインにできるため、高速ディスク・テークオーバーを行うことができる。

通常は、ボリューム・グループをすべて、拡張コンカレント・モード用に構成する必要があります。拡張コンカレント・モードは、コンカレント・ボリューム・グループを作成する場合のみのオプションです。移行したボリューム・グループを拡張コンカレント・モードに変換することもできます。

コンカレント・アクセス構成では、ジャーナル・ファイルシステムはサポートされません。 IBM

7131-405 および 7133 SSA シリアル・ディスク・サブシステムを使用するコンカレント・アクセス構成では、LVM ミラーリングを使用する必要があります。

IBM TotalStorage DS シリーズまたは IBM 2105 Enterprise Storage Server を使用するコンカレント・アクセス構成は、LVM ミラーリングを使用しません。代わりに、これらのシステムは独自のデータ冗長度を備えています。

新しいストレージ・デバイスに関する発表や情報については、IBM Web サイトを参照してください。

v 非コンカレント・アクセス。一度に 1 つのノードしかディスク上の情報にアクセスできない。

それらのディスクが含まれているリソース・グループが別のノードに移動した場合、新しいノードはディスクにアクセスし、メタデータ (ボリューム・グループおよび他のコンポーネントの、現在の状況に関する情報) を読み取り、そのボリューム・グループをオンに変更して、関連するファイルシステムをすべてマウントします。

非コンカレント・アクセス構成では通常、ジャーナル・ファイルシステムを使用します(場合によっては、非コンカレント環境で実行されるデータベース・アプリケーションがジャーナル・ファイルシステムをバイパスし、ロー論理ボリュームに直接アクセスすることもあります)。

関連資料:

103ページの『拡張コンカレント・アクセス』HACMP でサポートされる、複数のノードへの接続に対応したディスクはすべて、拡張コンカレント・モード・ボリューム・グループになることができ、コンカレント環境、非コンカレント環境のいずれかで (リソース・グループのタイプで指定されたとおりに) 使用できます。

104ページの『非コンカレント・アクセス』ジャーナル・ファイルシステムは、非コンカレント・アクセスのみをサポートしています。


拡張コンカレント・アクセスHACMP でサポートされる、複数のノードへの接続に対応したディスクはすべて、拡張コンカレント・モード・ボリューム・グループになることができ、コンカレント環境、非コンカレント環境のいずれかで (リソース・グループのタイプで指定されたとおりに) 使用できます。

v コンカレント。アプリケーションは、アクティブなすべてのクラスター・ノード上で同時に実行される。

こうしたアプリケーションが自身のデータにアクセスできるように、すべてのアクティブ・クラスター・ノード上のコンカレント・ボリューム・グループがオンに変更されます。アプリケーションは、一貫したデータ・アクセスを保証する必要があります。

v 非コンカレント。アプリケーションは同時に 1 つのノード上でしか実行されない。

ボリューム・グループは同時にアクセスされず、常に 1 つのノードによってのみアクセスされます。

拡張コンカレント・モードでは、クラスター内でリソース・グループを所有する全ノード上でボリューム・グループをオンにすると、LVM によって全ノード上でボリューム・グループへのアクセスが許可されます。ただし、高レベル接続 (例えば NFS マウントや JFS マウント) は全ノード上で制限され、現在HACMP 内のボリューム・グループを所有しているノード上でのみ高レベル接続が許可されます。

高速ディスク・テークオーバーが使用されている場合は、SCSI ディスク予約機能は使用されません。クラスターが区分化されると、各区画のノードがボリューム・グループを誤ってアクティブ状態でオンに変更する可能性があります。ボリューム・グループのアクティブ状態 varyon では、ファイルシステムのマウント、および物理ボリュームに対する変更が許可されるため、同じボリューム・グループについて異なるコピーが作成される可能性があります。高速ディスク・テークオーバーについて、および複数のネットワークの使用について詳しくは、セクション『高速ディスク・テークオーバーの使用』を参照してください。

拡張コンカレント・モードについて

すべてのコンカレント・ボリューム・グループが、デフォルトで拡張コンカレント・モード・ボリューム・グループとして作成されます。拡張コンカレント・ボリューム・グループでは、コンカレント論理ボリューム・マネージャー (CLVM) が AIX の RSCT (Reliable Scalable Cluster Technology) 機能のグループ・サービス・コンポーネントを介して、ノード間の変更を調整します。グループ・サービス・プロトコルは、クラスター・ノード間の通信リンク上を流れます。

拡張コンカレント・モードは、SSA のコンカレント・モードで提供される特殊な機能に代わるものです。

新しい SSA コンカレント・モード・ボリューム・グループを作成できません。HACMP は自動的にこれらのボリューム・グループを拡張コンカレント・モードに変換します。

SSA および RAID コンカレント・ボリューム・グループを拡張コンカレント・モードに変換するには、C-SPOC を使用します。

関連タスク:

ボリューム・グループの拡張コンカレント・モードへの変換

関連資料:

104ページの『高速ディスク・テークオーバーの使用』HACMP は障害が発生したボリューム・グループを自動的に検出し、非コンカレント・リソース・グループのリソースとして含まれる拡張コンカレント・モード・ボリューム・グループの高速ディスク・テークオーバーを開始します。

計画 103

非コンカレント・アクセスジャーナル・ファイルシステムは、非コンカレント・アクセスのみをサポートしています。

JFS ファイルシステムと JFS2 ファイルシステムでは、ノード間のアクセスが調整されません。したがって、JFS ファイルシステムまたは JFS2 ファイルシステムが同時に 2 つ以上のノードにマウントされると、同一のブロックが、2 つのノードによって異なるファイルに割り当てられることがあります。

高速ディスク・テークオーバーの使用HACMP は障害が発生したボリューム・グループを自動的に検出し、非コンカレント・リソース・グループのリソースとして含まれる拡張コンカレント・モード・ボリューム・グループの高速ディスク・テークオーバーを開始します。

高速ディスク・テークオーバーは、多数のディスクから構成される拡張コンカレント・ボリューム・グループのフォールオーバーの際に特に役立ちます。このディスク・テークオーバー・メカニズムは、非コンカレント・リソース・グループに含まれる標準ボリューム・グループで使用されるディスク・テークオーバーより高速です。高速ディスク・テークオーバー時に、HACMP はディスク予約の解除に必要とされる追加の処理がスキップされるか、レイジー更新の実行によって LVM 情報が更新および同期化します。

2 つのディスクを備えたボリューム・グループについては、高速ディスク・テークオーバーが 10 秒以内となることが確認されています。この所要時間は、ディスクおよびボリューム・グループの数が増加した場合には、極めて徐々に増加することが予期されます。任意の構成において観測される実際の時間は、HACMP

の制御の範囲外の要素 (例えば、ノードの処理能力やフォールオーバー時における無関係なアクティビティー量) に左右されます。フォールオーバー処理の完了について要する実際の時間は、さらに他の要素 (ファイルシステムの検査が必要かどうか、および、アプリケーションの再始動に要する時間など) に応じて変化します。

注: 拡張コンカレント・モード・ボリューム・グループは、同時にアクセスされることはなく、一度に 1

つのノードによってのみアクセスされます。高速ディスク・テークオーバー・メカニズムは、ボリューム・グループ・レベルで機能するものであって、使用されているディスク数には左右されません。

高速ディスク・テークオーバーとアクティブおよびパッシブの varyon拡張コンカレント・ボリューム・グループは、アクティブまたはパッシブのいずれかの状態として、ノード上で活動化 (つまり varyon) できます。

高速ディスク・テークオーバーを使用可能にするために、HACMP は、アクティブまたはパッシブな状態にある拡張コンカレント・ボリューム・グループを活動化します。

アクティブ varyon

アクティブ varyon は、通常の varyon と同様に動作し、論理ボリュームを使用可能にします。ノード上で拡張コンカレント・ボリューム・グループをアクティブ状態でオンにすると、以下が許可されます。

v ファイルシステムに対する操作 (ファイルシステムのマウントなど)

v アプリケーションに対する操作

v 論理ボリュームに対する操作 (論理ボリュームの作成など)

v ボリューム・グループの同期化


パッシブ varyon

拡張コンカレント・ボリューム・グループがパッシブ状態でオンに変更されると、LVM は、ボリューム・グループのディスク・フェンシングに相当する機能を LVM レベルで提供します。

パッシブ状態 varyon では、以下に示す、限られた数の読み取り専用操作のみがボリューム・グループに対して許可されます。

v ボリューム・グループの特殊ファイルへの LVM 読み取り専用アクセス

v ボリューム・グループにより所有されているすべての論理ボリュームの先頭 4K への LVM 読み取り専用アクセス

ボリューム・グループがパッシブ状態でオンに変更された場合、以下の操作は実行できなくなります。

v ファイルシステムに対する操作 (ファイルシステムのマウントなど)

v 論理ボリュームの操作 (論理ボリュームを開いた状態にしておく操作など)

v ボリューム・グループの同期化

HACMP とアクティブおよびパッシブ varyon

HACMP は、リソース・グループを所有するノード上のボリューム・グループをアクティブ状態で正しくオンに変更します。また、リソース・グループの状態および位置が変わった場合、アクティブ状態およびパッシブ状態を正しく変更します。

v クラスター始動時

– HACMP は、リソース・グループを所有するノード上で、ボリューム・グループをアクティブ状態で活動化する。HACMP は一度に 1 つのノード上でのみ、ボリューム・グループをアクティブ状態で活動化します。

– HACMP は、クラスター内のその他のすべてのノードでボリューム・グループをパッシブ状態で活動化する。

v フォールオーバー時

– あるノードがリソース・グループを解放した場合や、リソース・グループが他の何らかの理由で別のノードに移動したりすると、HACMP はリソース・グループを解放したノード上でボリューム・グループの varyon 状態をアクティブからパッシブに切り替え、当該リソース・グループを獲得したノード上で、ボリューム・グループをアクティブ状態で活動化する。

– クラスター内のその他のすべてのノードでは、ボリューム・グループはパッシブ状態のまま変化しない。

v ノードの再統合時に、HACMP は以下の処理を実行します。

– リソース・グループを解放したノード上でボリューム・グループの varyon 状態をアクティブからパッシブに変更する。

– 結合するノード上で、ボリューム・グループをアクティブ状態でオンに変更する。

– クラスター内のその他のすべてのノードでボリューム・グループをパッシブ状態で活動化する。

注: 同時に複数のノードでファイルシステムがマウントされることを防ぐために、アクティブ状態とパッシブ状態の切り換えが必要です。

ディスク予約の解除を伴うディスク・テークオーバー通常のディスク・テークオーバーの処理は、(高速ディスク・テークオーバーとは対照的に、) 一部のケースで実行されます。

計画 105

これらのケースには、以下のものがあります。

v 「すべての使用可能なノードでオンライン (Online On All Available Node)」始動ポリシー付きのリソース・グループがあります。

v 非コンカレント・リソース・グループ内に組み込まれたボリューム・グループが、拡張コンカレント・モードに変換されていない場合

通常のディスク・テークオーバー処理を実行するには、ディスク予約を解除し、論理区画を検査して、ボリューム・グループに加えられた変更を確認しておく必要があります。また、フォールオーバーに先立ち、HACMP はレイジー更新を使用してクラスター・ノード上の LVM 情報を更新します。レイジー更新が行われると、フォールオーバーに先立って、HACMP はボリューム・グループに加えられた変更を処理し、クラスター・ノード上の LVM 情報を同期化します。

クォーラムおよび varyon を使用してデータの可用性を高めるクォーラムの構成とボリューム・グループの varyon により、ミラーリングされたデータの可用性を高めることができます。

クォーラムの使用クォーラムにより、ボリューム・グループ内の物理ディスクの半数以上が確実に使用可能になります。

ただし、論理ボリューム・ミラーの記録はとられないため、データの可用性を保証するための有効な手段にはなりません。データがすべて保持されていても、クォーラムが失われる場合があります。逆に、一部のデータへのアクセスが失われても、クォーラムは失われない場合もあります。

クォーラムは、RAID アレイ (例えば、ESS や IBM TotalStorage DS シリーズ) 上のボリューム・グループに役立ちます。RAID デバイスによって、データの可用性が実現し、単一ディスク消失からの回復が可能になります。ミラーリングは、通常、単一の RAID デバイス内に全体が含まれるボリューム・グループでは使用されません。ボリューム・グループが RAID デバイス間でミラーリングされると、RAID デバイスのいずれかが消失しても、強制 varyon によってボリューム・グループをオンラインにすることができます。

各ボリューム・グループごとに、クォーラムを使用可能にするか使用不可にするかを決定してください。次の表は、ボリューム・グループのオンに変更/オフに変更される際に、クォーラムにどのように影響するかを示しています。

オンに変更されるボリューム・グループの状態オフに変更されるボリューム・グループの状態

クォーラムが使用可能ボリューム・グループ内の 50% 以上のディスクが使用可能

50% 以上のディスクへのアクセスが失われる

クォーラムが使用不可ボリューム・グループ内のすべてのディスクが使用可能

すべてのディスクへのアクセスが失われる

クォーラム検査は、デフォルトでは使用可能となっています。クォーラムを使用不可にするには、chvg-Qn vgname コマンドを使用するか、smit chvg 高速パスを使用します。

コンカレント・アクセス構成のクォーラム:

HACMP コンカレント・アクセス構成では、クォーラムを使用可能にする必要があります。クォーラムを使用不可にすると、データ破壊が発生する結果になります。複数の障害が発生するとクラスター・ノード間に共通の共用ディスクがなくなる可能性があるコンカレント・アクセス構成では、データの破壊や矛盾が生じる恐れがあります。


以下の図に、IBM SSA ディスク・サブシステムを 2 つ構成して Single Point of Failure を排除したクラスターを示します。論理ボリュームはサブシステム間でミラーリングされ、各ディスク・サブシステムは個別の NIC で各ノードに接続されています。

複数の障害によって各ノードと 1 つのディスク・セット間の通信が切断された (例えば、ノード A はサブシステム 1 にアクセスできるがサブシステム 2 にアクセスできず、ノード B はサブシステム 2 にアクセスできるがサブシステム 1 にアクセスできない) 場合、両方のノードは、アクセス可能なミラー・コピーからの、同じベースラインのデータに基づいて動作を継続します。ただし、各ノードは、別のノードがディスク上のデータに加えた変更を認識できません。この結果、ノード間でデータに矛盾が生じます。

クォーラム保護機能を使用可能にした場合、通信障害が発生すると、一方または両方のノードがボリューム・グループをオフに変更します。アプリケーションは、オフに変更されたボリューム・グループ上のデータにアクセスできませんが、データの整合性は保持されます。

クォーラム損失により起動される選択フォールオーバー:

HACMP では、特定のリソースの障害によって影響を受ける非コンカレント・リソース・グループ (始動ポリシーが「Online on All Available Nodes (使用可能なすべてのノードでオンライン)」以外のリソース・グループ) に対して、回復方法を選択的に提供します。HACMP では、クラスター・ノード上でオフラインに切り替わるボリューム・グループに関連する「loss of quorum (クォーラムの損失)」(LVM_SA_QUORCLOSE) エラーに対して、自動的に対処します。このエラーが発生すると、エラーが発生したノード上で非コンカレント・リソース・グループがオフラインになります。

ノード上のボリューム・グループのクォーラム損失が原因で AIX 論理ボリューム・マネージャーがリソース・グループ内のボリューム・グループをオフラインにした場合、HACMP は、このリソース・グループを選択的に他のノードに移動します。フォールオーバーの代わりに通知メソッドが使用されるようにリソース回復をカスタマイズすることで、このデフォルトの動作を変更できます。

HACMP は、LVM_SA_QUORCLOSE エラーに応答して、選択的なフェイルオーバーを起動し、影響を受けたリソース・グループを復旧します。ボリューム・グループでクォーラムが使用可能であると定義されていない場合であっても、このエラーは特定のエラー条件について AIX LVM によって生成されます。AIX

LVM は他のタイプのエラー通知も生成する場合がありますが、HACMP はデフォルトではこれらの通知に反応しません。このような場合には、ユーザー定義のエラー通知メソッドを構成するか、または AIX 自動エラー通知メソッドを使用してボリューム・グループ障害に対処する必要があります。

LVM_SA_QUORCLOSE エラーについて詳しくは、『ボリューム・グループの欠落に使用されるエラー通知メソッド』を参照してください。

計画 107

ノード上のボリューム・グループのクォーラムが失われることでトリガーされる選択フォールオーバーについて詳しくは、『リソース・グループの処理に対する選択的フォールオーバー』を参照してください。

関連概念:


強制 varyon の使用HACMP には、AIX 自動エラー通知メソッドとあわせて使用する強制 varyon 機能があります。強制varyon 機能により、最大のデータ可用性を実現できます。使用可能なデータの有効なコピーが 1 つ存在する限り、ボリューム・グループに対して varyon を強制実行すれば、ボリューム・グループをオンライン状態に維持できます。強制 varyon は、ミラーリングされた論理ボリュームを持つボリューム・グループに対してのみ使用してください。

注: この機能を区分クラスターの作成を回避するために使用する場合は注意が必要です。

クォーラムの損失が原因で、ボリューム・グループ上で通常の varyon コマンドが失敗しても、使用可能なデータの有効なコピーが 1 つあれば、SMIT を使用してノード上でボリューム・グループの varyon を強制実行できます。2 つのディスク格納装置間でデータをミラーリングしていて、ディスク格納装置の 1 つが使用不能になった場合は、SMIT を使用した varyon を強制実行が、ローカルな災害復旧に役立ちます。

注: 強制 varyon 属性は、LVM ミラーリングを使用する SSA ディスクまたは SCSI ディスク上のボリューム・グループと、個別の RAID デバイスまたは ESS デバイス間でミラーリングされるボリューム・グループに指定できます。

ディスクが使用不可のときにボリューム・グループを強制的にオンに変更したい場合は、varyonvg -f を使用してください。これは、データのコピーが存在するかどうかにかかわらず、ボリューム・グループを強制的にオンに変更します。リソース・グループのボリューム・グループに対しては、SMIT で強制 varyon を指定できます。

強制 varyon とクラスターの区分化

HACMP の強制 varyon 機能を使用可能にしている場合は、ハートビート・ネットワークが存在するかどうかを確認してください。ハートビート・ネットワークでは、ネットワークで障害が発生しても各ノードには常に他のノードへの通信パスが確保されます。これにより、クラスターが区分化されることを防ぎます。これが行われないと、ネットワーク障害が発生した場合、他のノード上で依然としてアクティブになっているリソース・グループに対して、ノードがテークオーバーを試みる可能性があります。この状況で強制varyon が設定されていると、データの損失や相違が発生する可能性があります。

varyon を強制実行するその他の方法

ボリューム・グループの強制 varyon を実行するために、以下のいずれかの方法を使用できます。

v イベント前処理またはイベント後処理スクリプト

v ノード上のロー物理ボリュームおよびボリューム・グループの活動化および獲得の失敗に対応するイベント回復ルーチン

HACMP の強制 varyon を使用すると、クォーラム・バスター・ディスクが不要になります。これは、クォーラムの損失に関連する問題を回避するためにクラスターに追加されたものです。クォーラム・バスター・ディスクとは、データのいずれのミラーからも独立した電源および現場交換可能ユニット (FRU) 上にある、ボリューム・グループに追加された単一の追加ディスクです。このディスクにはデータは存在せず、クォーラム・バスターとしての役割のみを果たすものであり、格納装置のいずれかが故障したり、格納装


置への接続が失われた場合にクォーラムが保持され、他のディスクの格納装置のデータを使用可能なままに維持することができました。

HACMP による NFS の使用HACMP ソフトウェアは、NFS 処理に対して可用性の拡張を提供します。

このような拡張には、以下のものがあります。

v 1 次 NFS サーバーに障害が発生しても、現行 NFS アクティビティーをバックアップ・プロセッサーによって回復し、NFS ファイルシステムに対するロックおよび重複要求キャッシュを保持できる信頼性の高い NFS サーバー機能。この機能性は、NFS v2 または NFS v3 を含むリソース・グループの場合は、2 ノード構成のものに限定されています。リソース・グループが NFS v4 のみを含む場合は、32 ノード構成のものまでサポート可能です。

v セットアップおよび設定をサポートする NFS 構成アシスタント

v NFSv4 のエクスポートと NFS デーモンをモニターする事前構成されたアプリケーション・サーバーとアプリケーション・モニター (clam_nfsv4)。

v NFS マウント用ネットワークを指定する機能。

v NFS のエクスポートとマウントをディレクトリー・レベルで定義する機能。

v NFS でエクスポートされるディレクトリーおよびファイルシステムに関するエクスポート・オプションを指定する機能。

HACMP クラスター上で NFS を予期した通りに機能させるためには、固有の構成要件があります。計画を立てる際には、以下に示すこれらの構成要件に従う必要があります。

v 共用ボリューム・グループの作成

v NFS ファイルシステムのエクスポート

v NFS マウントおよびフォールオーバー

HACMP スクリプトは、デフォルトの NFS 動作を指定します。ご使用の個々の構成を扱うには、スクリプトの変更が必要になることがあります。以降のセクションでは、さまざまな状況に合わせて計画を立てるための案を示します。

非コンカレントとして動作する (つまり、「Online on All Available Nodes (使用可能なすべてのノードでオンライン)」の始動ポリシーを持たない) すべてのリソース・グループに NFS を構成できます。

HACMP クラスター内での NFS ファイルシステムの制御権の譲渡NFS ファイルシステムが含まれたリソース・グループを構成したら、NFS ファイルシステムに対する制御権を HACMP に解放してください。

NFS ファイルシステムがアクティブな HACMP クラスターに属するリソース・グループの一部になった後は、HACMP が、クラスター・イベント時 (ファイルシステムが含まれたリソース・グループをクラスター内の別のノードにフォールオーバーする際など) にこれらのファイルシステムのクロスマウントとアンマウントを実行します。

何らかの理由でクラスター・サービスを停止して、NFS ファイルシステムを手動で管理することが必要になった場合は、クラスター・サービスを再始動する前に、これらのファイルシステムがアンマウントされる必要があります。これにより、ノードがクラスターに参加した後に、HACMP によって NFS ファイルシステムを管理できるようになります。

計画 109

高信頼性 NFS サーバー機能HACMP クラスターでは、標準 NFS 機能に対する AIX 拡張機能を利用できます。この機能を使用すると、クラスターが重複した要求を適切に処理することができ、NFS サーバーのフォールオーバーと再統合時に、ロック状態を復元できます。

NFS クライアントが NFS ロック機能を使用して共用 NFS ファイルシステムへのアクセスを調停する際は、リソース・グループあたり 2 つのノードという制限があります。すなわち、高信頼性 NFS を使用する各リソース・グループには 1 つの HACMP ノード・ペアが含まれます。

クラスター内の独立したノード・ペアは、高信頼性 NFS サービスを提供できます。例えば、4 ノード・クラスターでは、2 つの NFS クライアント/サーバー・ペアを設定できます (例えば、ノード A/ノード B

が 1 つの高信頼性 NFS サービス・セットを提供して、ノード C/ノード D がもう 1 つの高信頼性 NFS

サービス・セットを提供できます)。1 つ目のペアは、1 つの NFS ファイルシステム・セットに対して高信頼性 NFS サービスを提供でき、2 つ目のペアは、もう 1 つの NFS ファイルシステム・セットに対して高信頼性 NFS サービスを提供できます。NFS クロス・マウントが構成されているかどうかは関係ありません。ソース・グループに参加しているノードが上記の制約事項に従っている限り、HACMP では、リソース・グループや NFS ファイルシステムの数は制限されません。

NFS の IP アドレスの指定HACMP はホスト名には依存しませんが、ホスト名は、常にノード上に存在し常にインターフェース上でアクティブである IP アドレスに解決できる必要があります。例えば、ホスト名は他のノードに移動する可能性のあるサービス IP アドレスにはできません。

NFS に使用される IP アドレスが常にノード上に存在するようにするには、以下の方法があります。

v 永続ラベルに関連付けられた IP アドレスを使用する

v エイリアスによる IPAT 構成の場合は、ブート時に使用される IP アドレスを使用する

v HACMP で制御されないインターフェース上に存在する IP アドレスを使用する

共用ボリューム・グループ共用ボリューム・グループを作成するときは、通常、「Major Number (メジャー番号)」フィールドをブランクのままにすることができます。この場合、システムによってデフォルト値が提供されます。ただし、NFS ではエクスポートしたファイルシステムを一意に識別できるように、ボリューム・グループのメジャー番号が使用されます。したがって、NFS エクスポートされたファイルシステムが含まれているリソース・グループに含まれるノードはすべて、ファイルシステムの配置されているボリューム・グループに対応する、同一のメジャー番号を持つ必要があります。

ノードに障害が発生した場合、HACMP クラスターに接続された NFS クライアントは、標準の NFS サーバーが障害を起こしてリブートしたときと同じように動作します。つまり、ファイルシステムへのアクセスはハングし、その後ファイルシステムが再び使用可能になると回復します。ただし、メジャー番号が同一ではない場合は、別のクラスター・ノードがファイルシステムを引き継いでそのファイルシステムを再度エクスポートしても、クライアント・アプリケーションは回復しません。これは、そのノードによってエクスポートされたファイルシステムが、障害の発生したノードによってエクスポートしたファイルシステムとは違うものと認識されるからです。

ファイルシステムおよびディレクトリーの NFS エクスポートHACMP でファイルシステムとディレクトリーを NFS エクスポートするプロセスは、AIX の場合とは異なります。

HACMP での NFS エクスポートについて計画するときは、次の点に留意してください。


v NFS エクスポート対象のファイルシステムおよびディレクトリー

AIX では、smit mknfsexp コマンド (/etc/exports ファイルを作成する) を使用して、NFS エクスポート対象のファイルシステムおよびディレクトリーを指定します。HACMP では、NFS エクスポート対象のファイルシステムおよびディレクトリーを HACMP のリソース・グループ内に含めることによって指定します。詳しくは、『HACMP の NFS クロス・マウント』セクションを参照してください。

v NFS エクスポートされるファイルシステムおよびディレクトリーに関するエクスポート・オプション

HACMP で NFS エクスポート用の特殊なオプションを指定する場合は、/usr/es/sbin/cluster/etc/exportsファイルを作成します。このファイルの形式は、通常の AIX の /etc/exports ファイルと同じです。

注: この代替エクスポート・ファイルの使用はオプションです。HACMP は、ファイルシステムまたはディレクトリーの NFS エクスポート時に /usr/es/sbin/cluster/etc/exports ファイルを検査します。このファイルにファイルシステムまたはディレクトリーのエントリーがあると、HACMP はリストされているオプションを使用します。 NFS エクスポートされるファイルシステムまたはディレクトリーがファイルにリストされていない場合、または代替ファイルが存在しない場合、ファイルシステムまたはディレクトリーは、すべてのクラスター・ノードに対しする root アクセスのデフォルト・オプションで NFS エクスポートされます。

v エクスポートするファイルシステムを指定するリソース・グループ

SMIT でリソース・グループの「Filesystems Mounted before IP Configured (IP 構成の前にファイルシステムをマウントする)」フィールドを「true (はい)」に設定します。これにより、IP アドレス・テークオーバーは、ファイルシステムをエクスポートした後に行われます。IP アドレスが最初に処理される場合、NFS サーバーは、ファイルシステムのエクスポートが終了するまでクライアント要求を拒否します。

v NFSv4 エクスポートの安定ストレージ

NFSv4 のエクスポートには、安定ストレージが使用され、リソース・グループ内の参加ノードからアクセスできる状態が推奨されています。NFSv4 は、このファイルシステムを NFS クライアントのトランザクションに関する状態情報の保存に使用します。この安定ストレージ内の状態情報は、NFSv4 クライアントの状態に影響を与えずにノード間のリソース・グループのスムーズなフォールオーバー、フォールバック、移動を処理するにあたって重要です。

リソース・グループがオンライン状態の間は、安定ストレージの位置を変更することはできません。

関連資料:

112ページの『HACMP での NFS クロスマウント』NFS クロスマウントは HACMP 固有の NFS 構成であり、この構成では、クラスターの各ノードが、NFS


NFS とフォールオーバーHACMP と NFS が正しく連携するには、NFS サーバーの IP アドレスは、高可用性を目的としてリソース・グループ内のリソースとして構成する必要があります。

NFS のパフォーマンスを最適化にするには、HACMP で使用される NFS ファイルシステムの/etc/filesystems ファイルの「options」フィールドに vers = <バージョン番号> というエントリーが含まれている必要があります。

計画 111

関連資料:



HACMP での NFS クロスマウントNFS クロスマウントは HACMP 固有の NFS 構成であり、この構成では、クラスターの各ノードが、NFS


リソース・グループ内での NFSv2/v3 エクスポートの実行中は、このクロスマウント機能は 2 つのノードのリソース・グループまでに制限されます。リソース・グループ内のエクスポートがすべて NFSv4 の場合、クロスマウント機能は 32 ノードのリソース・グループまでの拡張が可能です。

原則的には、リソース・グループ内の各ノードは相互テークオーバー (もしくはアクティブ対アクティブ)

のクラスター構成の一部であり、NFS ファイルシステムの提供およびマウントが可能です。

デフォルトでは、NFS エクスポートしたファイルシステムが含まれているリソース・グループは、以下のようにしてこれらのファイルシステムを自動的にクロスマウントします (エクスポートとインポートの両方が構成されている場合)。

v このリソース・グループが現在ホスティングされているノード上で、リソース・グループ内の NFS ファイルシステムがすべて NFS エクスポートされる。

v このリソース・グループをホスティングする可能性のある各ノードは、リソース・グループ内のすべての NFS ファイルシステムを NFS マウントする。

これにより、アプリケーションは、このリソース・グループに含まれているあらゆるノード上の NFS ファイルシステムにアクセスできます。

リソース・グループに対して IP アドレス・テークオーバーが構成されている場合は、フォールオーバー時に以下が実行されます。

v NFS ファイルシステムは、テークオーバー・ノードによってローカルにマウントされ、再エクスポートされる。

v リソース・グループ内の他のノードがすべて、自身の NFS マウントを維持する。

NFS クロスマウント構成では、リソース・グループに定義される NFS マウントには、リソース・グループに対応する NFS エクスポートがある必要があります。定義された NFS クロスマウントが、この構成に従っていない場合は、次のメッセージが表示されます。

claddres: WARNING: NFS mounts were specified for the resource group’<RG name>’;however no NFS exports have been specified.

NFS クロスマウントのフィールドに値が含まれる場合は、対応する NFS エクスポート・ファイルシステムにも値が含まれる必要があります。


2 ノード NFS クロス・マウントの例

以下の図について説明します。

v 現在、ノード A は、非コンカレント・リソース・グループ RG1 をホスティングしている。 RG1 には、NFS エクスポート・ファイルシステムとして /fs1、サービス IP ラベルとして service1 が含まれる。

v 現在、ノード B は、非コンカレント・リソース・グループ RG2 をホスティングしている。 RG2 には、NFS エクスポート・ファイルシステムとして /fs2、サービス IP ラベルとして service2 が含まれる。

再統合時に、/fs1 は NodeA に戻され、ローカルにマウントされてからエクスポートされます。NodeB

は、NFS を介してこれを再マウントします。

この 2 つのリソース・グループは、SMIT で次のように定義されます。

リソース・グループ RG1 RG2

参加ノード名 NodeA NodeB NodeB NodeA

ファイルシステムリソース・グループを現在所有しているノードによってローカルにマウントされるファイルシステム。

/fs1 /fs2

エクスポートするファイルシステム

リソース・グループを現在所有しているノードによってNFS エクスポートされるファイルシステム。このファイルシステムは、上でリストされたファイルシステムのサブセットになります。

/fs1 /fs2

NFS マウントするファイルシステム

リソース・グループのすべてのノードによって NFS マウントされるファイルシステム/ディレクトリー。最初の値は、NFS マウント・ポイントです。2 番目の値は、ローカル・マウント・ポイントです。

/mnt1;/fs1 /mnt2;/fs2

/fs2

/fs1

c_nfs

1

ノード A

/fs1 NFS(NFS )

/fs2 NFS(NFS )

エクスポート

マウント

ノード A

/fs2 NFS(NFS )

/fs1 NFS(NFS )

エクスポート

マウント

service1 service2

クライアントとマウント

/fs1 /fs2(NFS )

計画 113

リソース・グループ RG1 RG2

IP 構成の前にファイルシステムをマウントするはいはい

このシナリオでは、以下を実行します。

v ノード A は、/fs1 をローカルにマウントしてエクスポートし、/mnt1 に上書きマウントします。

v ノード B はノード A から /mnt1 上に /fs1 を NFS マウントします。

このようにリソース・グループを設定すると、ノード対ノードの NFS は予想どおりのデフォルト動作であることが保証されます。

NodeA に障害が発生すると、NodeB は NodeA: /fs1 内のオープン・ファイルをすべて閉じてアンマウントし、このファイルをローカルにマウントしてから待機中のクライアントに再エクスポートします。

テークオーバー後、NodeB には以下が含まれます。

v /fs2 (ローカル・マウント)

v /fs2 (NFS エクスポート)

v /fs1 (ローカル・マウント)

v /fs1 (NFS エクスポート)

v service1:/fs1 (/mnt1 に対する上書き NFS マウント)

v service2:/fs2 (/mnt2b に対する上書き NFS マウント)

両方のリソース・グループには、リソース・グループの潜在的な所有者として両方のノードが含まれています。

NFS クロス・マウントおよび IP ラベル:

NFS クロスマウントを使用可能にするため、各クラスター・ノードは NFS クライアントとして動作することができます。これらの各ノードは、NFS サーバー・ノードのサービス IP ラベルに対する有効な経路を持っている必要があります。つまり、NFS クロスマウントを使用可能にするためには、IP ラベルがクライアント・ノード上に存在する必要があり、またこの IP ラベルは、NFS サーバー・ノードのサービス IP


NFS クライアント・ノードが同じネットワーク上のサービス IP ラベルを持つ場合は、そのような経路を持っていなくても問題ありません。しかし、特定のクラスター構成では、有効な経路を作成する必要があります。

以下のセクションでは、これらのクラスター構成について説明し、また有効な経路を構成する 2 つの方法を示します。

有効な経路の作成に必要なクラスター構成:

以下のクラスター構成では、NFS サーバー・ノード上の IP ラベルに対する経路が存在しない可能性があります。

以下のクラスター構成では、NFS サーバー・ノード上の IP ラベルに対する経路が存在しない可能性があります。


IP エイリアスを使用したハートビートの送受信が構成されていない場合、ブート IP ラベルは、サービスIP ラベルとは異なるサブネット上に配置されている必要があります。このため、ファイルシステムの NFS

エクスポートに使用されるサブネット上に、NFS クライアント・ノードがインターフェースを構成していないという状況が起こる場合があります。

IP エイリアスによる IPAT を使用する非コンカレント・リソース・グループで NFS クロスマウントをサポートするには、NFS クライアント・ノードと、ファイルシステムをエクスポートするノードの間に経路を作成する必要があります。以下のセクションでは、有効な経路を作成するためのオプションを示します。

NFS サーバーへの経路を作成する方法:

NFS サーバーへのアクセスを保証するには、NFS サーバーが、NFS サーバー・ノードのサービス IP ラベルと同じサブネット上にある IP ラベルをクライアント・ノードに配置するのが最も簡単な方法です。

NFS クライアント・ノードと、ファイルシステムをエクスポートするノードの間に有効な経路を作成するには、以下のいずれかの構成を使用できます。

v サービス IP ネットワークおよびサブネット上に IP ラベルが構成された個別の NIC を構成する

または

v サービス IP ネットワークおよびサブネット上に永続的なノード IP ラベルを構成する

注: サービス IP ネットワーク上でクライアント・ノードが非サービス IP ラベルを持っている場合は、IP

エイリアスを使用したハートビートを構成しておくと、サービス IP ラベルと同じサブネット上に非サービス IP ラベルを配置できます。セクション『IP エイリアスを使用するハートビート』を参照してください。

上記の解決方法を使用しても、HACMP にデフォルトで設定されている NFS ファイルシステム用のエクスポート・オプションのために、ファイルシステムに対する root 許可が自動的に提供されることはありません。

クライアント・ノード上の NFS マウントされたファイルシステムに対して root レベルのアクセスを使用可能にするには、クラスターの exports ファイル /usr/es/sbin/cluster/etc/exports の root = オプションにすべてのノードの IP ラベルまたはアドレスを追加してください。この追加操作は、1 つのノード上で行うことができます。クラスター・リソースを同期化すれば、この情報が他のクラスター・ノードに伝搬されます。 /usr/es/sbin/cluster/etc/exports ファイルについての詳細は、『ファイルシステムおよびディレクトリーの NFS エクスポート』を参照してください。

関連概念:

36ページの『IP エイリアスを使用するハートビート』このセクションは IP エイリアスを使用するハートビートについての情報が含まれています。

関連資料:

110ページの『ファイルシステムおよびディレクトリーの NFS エクスポート』HACMP でファイルシステムとディレクトリーを NFS エクスポートするプロセスは、AIX の場合とは異なります。

NFSv4 エクスポート用安定ストレージの作成と構成:

安定ストレージは、NFSv4 サーバーによる状況情報の保存に使用されるファイルシステムです。NFSv4 クライアントの状況情報を維持して、ノード間のリソース・グループのフォールオーバー、フォールバック、移動をスムーズかつ透過的に処理するにあたって重要です。

計画 115

安定ストレージ要件

v 推奨サイズは 512 MB です。

v 専用のファイルシステムの使用が推奨されていますが、既存ファイルシステムのサブディレクトリーも使用可能です。

v 安定ストレージの配置されたファイルシステムおよびボリューム・グループは、リソース・グループの一部であるべきです。

v HACMP は、安定ストレージに指定されたパスがリソース・グループ内のファイルシステムにあることの検証を、ベストエフォートで試みます。ただし、検証時にファイルシステムがローカル・マウントされていない可能性があるため、このチェックはシンボリック・リンクを考慮に入れていません。HACMP

による検証の妨げになるシンボリック・リンクは使用しないでください。

v リソース・グループへの追加の前に、安定ストレージが空の (いかなるデータも含まない) 状態であることを確認してください。

v 安定ストレージはリソース・グループが管理するファイルシステム上に存在しなければなりませんが、リソース・グループによって NFS エクスポートされるディレクトリーには指定しないでください。

v 構成アシストには AUTO_SELECT オプションが用意されています。このオプションを選択した場合は、HACMP は特定のリソース・グループ内の VG のリストから、VG を選択します。HACMP は論理区画とファイルシステムを作成し、安定ストレージのロケーションとして使用します。

クロス・マウントされた NFS ファイルシステムを使用したリソース・グループ・テークオーバーこのセクションでは、テークオーバーおよび再統合時に NFS ファイルシステムが正しく処理されるように、クロスマウントされた NFS ファイルシステムが含まれる非コンカレント・リソース・グループをセットアップする方法について説明します。さらに、非コンカレント・リソース・グループは、フォールオーバー時のサーバー間自動 NFS マウントをサポートしています。

ローカル・マウント・ポイントとは異なる NFS マウント・ポイントのセットアップ:

HACMP は、非コンカレント・リソース・グループでの NFS マウントをいくつかの方法で処理します。

サポートされるファイルシステムのタイプを次に示します。

v 現在リソース・グループを所有するノードが、ファイルシステムのローカル・マウント・ポイントを介してファイルシステムをマウントし、このノードがファイルシステムを NFS エクスポートする。

v リソース・グループ内のすべてのノード (グループの現在の所有者を含む) は、別のマウント・ポイントを介してファイルシステムを NFS マウントする。

その結果、グループの所有者は、2 回 (ローカル・マウントで 1 回、NFS マウントで 1 回) ファイルシステムをマウントします。

注: NFS マウント・ポイントは、ローカル・マウント・ポイントのディレクトリー・ツリーの外部になければなりません。

NFS マウントしたファイルシステムが含まれているリソース・グループでは IPAT が使用されているので、各ノードはフォールオーバー時に、NFS ファイルシステムのアンマウントと再マウントを行いません。リソース・グループが新しいノードにフォールオーバーすると、獲得側ノードはファイルシステムをローカルにマウントして NFS エクスポートします(フォールオーバーの中、NFS マウントされたファイルシステムは、一時的にクラスター・ノードで使用できなくなります)。新しいノードが IPAT ラベルを獲得すると同時に、NFS ファイルシステムへのアクセスが復元されます。


すべてのアプリケーションは、NFS マウントを通じてファイルシステムを参照する必要があります。使用するアプリケーションが、常に同じマウント・ポイント名でファイルシステムを参照する必要がある場合は、ローカル・ファイルシステム・マウントのマウント・ポイントを変更できます (例えば、point_local をマウントするように変更し、直前のローカル・マウント・ポイントを新しい NFS マウント・ポイントとして使用できる)。

HACMP のデフォルト NFS マウント・オプション:

NFS マウントを実行するときに HACMP で使用されるデフォルト・オプションは、「hard、intr」です。

NFS マウントに対して soft マウントなどの任意のオプションを設定するには、以下のようにします。

1. smit mknfsmnt と入力します。

2. 「MOUNT now, add entry to /etc/filesystems or both? (マウントする時期 (即時、/etc/filesystems にのみエントリーを追加、または両方))」フィールドで「file systems (ファイルシステム)」オプションを選択します。

3. 「/etc/filesystems entry will mount the directory on system RESTART (/etc/filesystems のエントリーはシステム再始動時にディレクトリーをマウントする)」フィールドで、デフォルト値の「no (いいえ)」を受け入れます。

この手順により、作成された /etc/filesystems エントリーに選択したオプションが追加されます。その後、HACMP スクリプトがこのエントリーを読み込み、選択したオプションを取得します。

クライアントでの NFS マウント・ポイントの作成および構成:

NFS を介してファイルシステムをマウントするには、NFS マウント・ポイントが必要です。非コンカレント・リソース・グループでは、リソース・グループ内のすべてのノードがファイルシステムを NFS マウントします。NFS マウント・ポイントは、リソース・グループ内の各ノード上に作成します。NFS マウント・ポイントは、ローカル・マウント・ポイントのディレクトリー・ツリーの外部になければなりません。

リソース・グループ内のすべてのノード上で NFS マウント・ポイントが作成されたら、リソース・グループに「(NFS Filesystem to NFS Mount (NFS マウントする NFS ファイルシステム)」属性を構成してください。

NFS マウント・ポイントを作成して NFS マウント用にリソース・グループを構成するには、以下の手順を実行します。

1. リソース・グループ内の各ノード上で、以下のコマンドを実行して NFS マウント・ポイントを作成します。

mkdir /mountpoint

ここで、mountpoint は、リモート・ファイルシステムがマウントされるローカル NFS マウント・ポイントの名前です。

2. SMIT の「Change/Show Resources and Attributes for a Resource Group (リソース・グループのリソースおよび属性の変更/表示)」パネルの「Filesystem to NFS Mount (NFS マウントするファイルシステム)」フィールドには、両方のマウント・ポイントを指定する必要があります。

NFS マウント・ポイントを指定してから、セミコロンで区切って、ローカル・マウント・ポイントを指定します。例えば、次のように入力します。

/nfspoint;/localpoint

追加のエントリーがある場合は、これらのエントリーを次のようにスペースで区切ります。

計画 117

/nfspoint1/;local1 /nfspoint2;/local2

3. (オプション) ネストされたマウント・ポイントがある場合は、ローカル・マウント・ポイントの場合と同様の方法で、正確に一致するように NFS マウント・ポイントをネストします。

4. (オプション) NFS ファイルシステムをクロス・マウントする場合は、SMIT でリソース・グループの「Filesystems Mounted before IP Configured (IP 構成の前にファイルシステムをマウントする)」フィールドを「true (はい)」に設定します。

共用 LVM コンポーネント・ワークシートの記入クラスターに含める物理ストレージおよび論理ストレージのコンポーネントを確認したら、該当するすべてのワークシートに情報を記入してください。

このリストには、以下のものが含まれます。

v 非共用ボリューム・グループ・ワークシート

v 共用ボリューム・グループ/ファイルシステム・ワークシート

v NFS エクスポートされるファイルシステム/ディレクトリー・ワークシート

LVM コンポーネントの計画

共用 LVM コンポーネントを計画するときは、以下のガイドラインを考慮してください。

v 一般に、論理ボリュームの計画はデータの可用性に関係します。ただし、論理ボリュームのコピーを作成することは、定期的なバックアップの代わりにはなりません。バックアップは、原因に関係なく、データの消失に対する保護となります。論理ボリューム・コピーは、物理的なアクセス障害が発生した場合にデータの消失に対する保護となります。

v すべてのオペレーティング・システム・ファイルはルート・ボリューム・グループ (rootvg) にあり、すべてのユーザー・データはルート・ボリューム・グループ以外に存在する必要があります。これにより、オペレーティング・システムの更新や再インストール、およびデータのバックアップが容易になります。

v ミラーリングを実装する場合は、最低 3 つの物理ボリュームを含むボリューム・グループを構成すると、最大の可用性を実現できます。

v ボリューム・グループに対して、SMIT で「Use Forced Varyon of Volume Groups, if Necessary (必要な場合、ボリューム・グループの強制 varyon を使用する)」属性を指定する場合は、ミラーリングされた物理ボリュームに非常に厳密なディスク割り振りポリシーを使用してください。

v コピーを使用する場合、コピーを含む各物理ボリュームはそれぞれ別の電源から電力を受けるようにする必要があります。1 つの電源に障害が発生した場合、別の電源によって「Single Point of Failure」の発生が回避されます。

v ボリューム・グループをレイアウトするときは、クォーラムに関する問題を考慮してください。クォーラムを使用可能に設定すると、2 ディスク構成のボリューム・グループでは、クォーラムを満たすことができず、データ・アクセスが失われる危険性があります。3 ディスク構成のボリューム・グループを構築するか、またはクォーラムを使用不可にしてください。

v NFS マウントされるファイルシステムおよびディレクトリーを計画してください。

v 設計したクラスター構成を常に念頭におく必要があります。リソースがテークオーバーされないノードでは、重大なボリューム・グループを使用しないようにします。

非共用ボリューム・グループ・ワークシートの記入クラスターの各ノードについて、ローカル (非共用) ディスクに配置されるそれぞれのボリューム・グループごとに非共用ボリューム・グループ・ワークシートを完成させます。


ワークシートを記入するには、以下の手順を実行します。

1. 「Node Name (ノード名)」フィールドにノードの名前を記入します。

2. 「Volume Group Name (ボリューム・グループ名)」フィールドにボリューム・グループの名前を記入します。

3. 「Physical Volumes (物理ボリューム)」フィールドに、ボリューム・グループを構成する物理ボリュームのデバイス名をリストします。

ワークシートの残りのセクションには、ボリューム・グループ内のそれぞれの論理ボリュームごとに、次の情報を記入します。必要な場合は、シートを追加してください。

4. 「Logical Volume Name (論理ボリューム名)」フィールドに論理ボリュームの名前を記入します。

5. LVM ミラーリングを使用している場合は、「Number Of Copies Of Logical Partition (論理区画のコピー数)」フィールドに論理区画のコピー (ミラー) の数を指定します。コピーを 1 つにするか 2 つにするか (オリジナルの論理区画を加えて、合計 3 つになります) を指定できます。

6. LVM ミラーリングを使用している場合は、「別の物理ボリュームに配置」フィールドに、各コピーを別の物理ボリュームに配置するかどうかを指定します。

7. 「Filesystem Mount Point (ファイルシステムのマウント・ポイント)」フィールドに、ファイルシステムのマウント・ポイントの絶対パスを記録します。

8. 「Size (サイズ)」フィールドに、ファイルシステムのサイズを 512 バイト・ブロック単位で記録します。

共用ボリューム・グループ/ファイルシステム・ワークシートの記入共用ディスクに配置されているボリューム・グループごとに、ローカル (非共用) ディスクに配置される各ボリューム・グループについて、個別の共用ボリューム・グループ/ファイルシステム・ワークシートに情報を記入します。

グループとファイルシステムのワークシートに記入するには、次の手順を実行します。

1. 「Node Names (ノード名)」フィールドに、クラスターの各ノードの名前を記入します。ノード名は、『クラスターの初期計画』で決めた名前です。ディスク・フェンシングが使用可能な場合は、コンカレント・リソース・グループに全ノードが参加する必要があります。ディスク・フェンシングが使用可能となっていない場合は、ノードのサブセットをリソース・グループに含めることができます。

2. 共用ボリューム・グループに名前を割り当て、それを「Shared Volume Group Name (共用ボリューム・グループ名)」フィールドに記録します。共用ボリューム・グループの名前は、クラスター内で一意であるとともに、サービス IP ラベル/アドレスやリソース・グループ名とは異なる必要があります。また、それらの共用ボリューム・グループが使用されるアプリケーションや対応するデバイスに関連した名前 (websphere_service_address など) にしてください。

3. 現時点では、「Major Number (メジャー番号)」フィールドは、ブランクのままにしておきます。このフィールドに値を記入するのは、以下の『リソース・グループの計画』に示す NFS に関する問題に対応する場合です。

4. 「Log Logical Volume Name (ログ論理ボリューム名)」フィールドに、ログ論理ボリュームの名前(jfslog または jfs2log) を記録します。

5. 「Physical Volumes (物理ボリューム)」フィールドに、計画した物理ボリュームを記入します。このフィールドには、『インストール済みハードウェアの構成』の手順に従って、ディスクをインストールした後で正確な値を記入します。

計画 119

AIX オペレーティング・システムでは、物理ボリュームは、システム・ブート時に割り当てられる、連続した hdisk 番号で認識されます。例えば、/dev/hdisk0 はシステム内の最初の物理ボリュームを示し、/dev/hdisk1 はシステム内の 2 番目の物理ボリュームを示すというようになります。

HACMP クラスターでディスクを共用する際、ディスクを共用するノードはそれぞれ、そのディスクに hdisk 番号を割り当てます。この hdisk 番号は一致しない場合がありますが、同じ物理ボリュームを指しています。例えば、各ノードで内部ディスク数が異なる場合や、AIX のインストール後にディスクが変更されている場合などがあります。

HACMP ソフトウェアでは、hdisk 番号がノード全体で一致する必要はありません (ただし、一致している方がシステムを管理しやすくなります)。 hdisk 番号を異なるものにする必要がある場合は、それぞれのノードの共用ディスクのビューを理解しておいてください。各ノードが共用ディスクに割り当てる hdisk 番号を示すダイアグラムを作成し、『プランニング・ワークシート』の該当するボリューム・グループ・ワークシートにこの番号を記入します。番号が不確かな場合は、その hdisk の物理ボリューム ID (PVID) を使用して、共用バス上での ID を確認してください。

ワークシートの残りのセクションには、ボリューム・グループ内のそれぞれの論理ボリュームごとに、次の情報を記入します。必要に応じてシートを追加してください。

6. 論理ボリュームに名前を割り当て、それを「Logical Volume Name (論理ボリューム名)」フィールドに記録します。

共用論理ボリュームは、HACMP クラスター内で固有の名前を持っている必要があります。デフォルトでは、AIX はジャーナル・ファイルシステムの一部として作成される論理ボリュームに名前を割り当てます (lv01 など)。システム生成の論理ボリューム名を使用している場合、論理ボリュームを含むボリューム・グループを別のノードの ODM 構造にインポートしようとした際に、特にそのボリューム・グループがすでに存在していると、この名前が原因でインポートが失敗する場合があります。論理ボリュームの名前を変更する方法については、『共有 LVM コンポーネントの定義』を参照してください。

7. LVM ミラーリングを使用している場合は、「Number Of Copies of Logical Partition (論理区画のコピー数)」フィールドに論理区画のコピー (ミラー) の数を指定します。コピーを 1 つにするか 2 つにするか (オリジナルの論理区画を加えて、合計 3 つになります) を指定できます。

8. LVM ミラーリングを使用している場合は、「別の物理ボリュームに配置」フィールドに、各コピーを別の物理ボリュームに配置するかどうかを指定します。ボリューム・グループに対して強制 varyon オプションを使用する計画の場合は、各コピーがそれぞれ個別の物理ボリューム上にミラーリングされるようにしてください。

9. 「File System Mount Point (ファイルシステムのマウント・ポイント)」フィールドに、ファイルシステムのマウント・ポイントの絶対パスを記録します。


11. このボリューム・グループでサイト間 LVM ミラーリングを使用可能にするかどうかを記録します。ボリューム・グループでサイト間 LVM ミラーリングが使用可能な場合、クラスター検証によって、ボリューム・グループおよび論理ボリューム構成の整合性と、各サイトに各論理ボリュームのコピーが少なくとも 1 つ存在することが保証されます。

ボリューム・グループは、リソース・グループにリソースとして構成されている必要もあります。サイト間LVM ミラーリングは、2 サイト・クラスターをサポートしています。このクラスターでは LVM ミラーリングが Storage Area Network (SAN) を介して、地理的に離れたサイトのディスク・サブシステム間でデータを複製します。


関連概念:


関連資料:



NFS エクスポートされるファイルシステム・ワークシートの記入NFS エクスポートされるファイルシステムまたはディレクトリー・ワークシート (非コンカレント・アクセス) を印刷し、このセクションの情報を使用して内容を記入します。クラスター内で高可用性を維持する必要があるアプリケーションごとに、コピーを印刷します。

ノードから NFS エクスポートするファイルシステムまたはディレクトリーについて、NFS エクスポートされるファイルシステムまたはディレクトリー・ワークシートを記入してください。記入した情報を使用して、/usr/es/sbin/cluster/etc/exports ファイルを更新します。

NFS エクスポートされるファイルシステムまたはディレクトリー・ワークシートに情報を記入するには、以下の手順に従ってください。

1. 「Resource Group (リソース・グループ)」フィールドに、ファイルシステムまたはディレクトリーがNFS エクスポートされるエクスポート元のリソース・グループの名前を記録します。

2. 「Network for NFS Mount (NFS マウント用ネットワーク)」フィールドに、ファイルシステムまたはディレクトリーを NFS マウントする優先ネットワークを記録します。

3. IP アドレスのテークオーバーの前にファイルシステムのテークオーバーを実行させたい場合は、「FileSystem Mounted Before IP Configured (IP 構成の前にファイルシステムをマウントする)」フィールドに、「true (はい)」を指定します。先に IP アドレスをテークオーバーする場合は、「false (いいえ)」を指定します。

4. 「Exported Directory (NFSv2/3) (エクスポート・ディレクトリー (NFSv2/3))」フィールドに、エクスポートされるファイルシステムまたはディレクトリーの絶対パス名を記録します。

5. 「Exported Directory (NFSv4) (エクスポート・ディレクトリー (NFSv4))」フィールドに、エクスポートされるファイルシステムまたはディレクトリーの絶対パス名を記録します。

6. (オプション) NFS エクスポートされるディレクトリーやファイルシステムを割り当てるエクスポート・オプションを記録します。完全なエクスポート・オプション・リストについては、exports マニュアル・ページを参照してください。

7. エクスポートするファイルシステムまたはディレクトリーごとに、ステップ 4 と 5 を繰り返します。

8. 「Exported Directory (NFSv4) (エクスポート・ディレクトリー (NFSv4))」が空ではない場合、安定ストレージのパスを記録してください。

関連資料:

計画 121

217ページの『NFS エクスポートされるファイルシステムまたはディレクトリー・ワークシート (非コンカレント・アクセス)』このワークシートは、非コンカレント・アクセス構成のノード単位で NFS によりエクスポートされるファイルシステムとディレクトリーを記録するために使用します。クラスターで定義されたノードごとに、個別のワークシートが必要です。ノードごとにワークシートを 1 枚ずつ印刷して、それぞれにノード名を記入してください。

非共用ボリューム・グループ・ワークシート (コンカレント・アクセス) の記入各ノードごとに、ローカル (非共用) ディスクに配置されているそれぞれのボリューム・グループについて、非共用ボリューム・グループ・ワークシート (コンカレント・アクセス) に情報を記入します。

1. 「Node Name (ノード名)」フィールドにノード名を入力します。

2. 「Volume Group Name (ボリューム・グループ名)」フィールドにボリューム・グループの名前を記入します。


4. 「Physical Volumes (物理ボリューム)」フィールドに、ボリューム・グループを構成する物理ボリュームのデバイス名をリストします。

ワークシートの残りのセクションには、ボリューム・グループ内のそれぞれの論理ボリュームごとに、次の情報を記入します。必要な場合は、シートを追加してください。


6. LVM ミラーリングを使用している場合は、「Number Of Copies Of Logical Partition (論理区画のコピー数)」フィールドに論理区画のコピー (ミラー) の数を指定します。コピーを 1 つにするか 2 つにするか (オリジナルの論理ボリュームを加えて、合計 3 つになります) を指定できます。

7. LVM ミラーリングを使用している場合は、「別の物理ボリュームに配置」フィールドに、各コピーを別の物理ボリュームに配置するかどうかを指定します。ボリューム・グループの varyon を強制実行する計画を立てていて、クォーラム不足が原因で通常の varyon 操作が失敗する場合は特に、このオプションを指定することが重要となります。

8. 「File System Mount Point (ファイルシステムのマウント・ポイント)」フィールドに、ファイルシステムのマウント・ポイントの絶対パスを記録します。


関連資料:

218ページの『非共用ボリューム・グループ・ワークシート (コンカレント・アクセス)』このワークシートは、コンカレント・アクセス構成でノードの内部ディスク上にあるボリューム・グループとファイルシステムを記録するために使用します。ボリューム・グループごとに、個別のワークシートが必要です。各ボリューム・グループ用のワークシートを印刷して、それぞれにノード名を記入してください。

共用ボリューム・グループ・ワークシート (コンカレント・アクセス) の記入共用ディスクに配置されるボリューム・グループごとに、個別の共用ボリューム・グループおよびファイルシステム・ワークシートを完成させます。

SSA ディスク・サブシステム上にコンカレント・ボリューム・グループを作成する計画の場合は、各クラスター・ノード上に ssar の付いた固有のノード番号 (ゼロ以外) を割り当てます。


コンカレント・リソース・グループで SSA ディスク・フェンシングを使用するよう指定した場合、HACMP は、リソースを同期化する際に、リソース・グループ内にノードがすべて含まれていることを確認してノード番号を割り当てます。

コンカレント・リソース・グループで SSA ディスク・フェンシングを使用するよう指定しない場合は、以下のコマンドを使用してノード番号を割り当てます。

chdev -l ssar -a node_number=x

x は、対象ノードに割り当てる番号です。その後、システムをリブートしてください。

共用ボリューム・グループおよびファイルシステム・ワークシート (コンカレント・アクセス) を記入するには、以下の手順を実行します。

1. 「Node Names (ノード名)」フィールドに、クラスターの各ノードの名前を記入します。

2. 「Shared Volume Group Name (共用ボリューム・グループ名)」フィールドに共用ボリューム・グループの名前を記入します。

3. 「Physical Volumes (物理ボリューム)」フィールドに、計画した物理ボリュームを記入します。このフィールドには、『Installing HACMP on Server Nodes』の手順に従って、ディスクをインストールした後で正確な値を記入します。

ワークシートの残りのセクションには、ボリューム・グループ内のそれぞれの論理ボリュームごとに、次の情報を記入します。必要に応じてシートを追加してください。


5. 「Number Of Copies Of Logical Partition (論理区画のコピー数)」フィールドに、論理区画のコピー(ミラー) の数を記入します。コピーを 1 つにするか 2 つにするか (オリジナルの論理区画を加えて、合計 3 つになります) を指定できます。

6. 「別の物理ボリュームに配置」に、各コピーを別の物理ボリュームに配置するかどうかを指定します。ボリューム・グループの varyon を強制実行する計画を立てていて、クォーラム不足が原因で通常のvaryon 操作が失敗する場合は特に、このオプションを指定することが重要となります。

関連資料:

219ページの『共用ボリューム・グループおよびファイルシステム・ワークシート (コンカレント・アクセス)』このワークシートは、コンカレント・アクセス構成での共用ボリューム・グループおよびファイルシステムを記録するために使用します。共用ボリューム・グループごとに、個別のワークシートが必要です。各ボリューム・グループ用のワークシートを印刷して、それぞれにボリューム・グループを共用するノードの名前を記入してください。

クラスター・ダイアグラムへの LVM 情報の追加LVM 情報をクラスター・ダイアグラムに追加します (ボリューム・グループおよび論理ボリューム定義を含む)。サイト間 LVM ミラーリングを使用している場合は、サイト情報を追加してください。

リソース・グループの計画本トピックでは、HACMP クラスター内のリソース・グループの計画方法を説明します。

前提条件

以下に示す前出の章の計画ステップを完了している必要があります。

計画 123

リソース・グループの概説HACMP では、リソースをリソース・グループに編成します。各リソース・グループは、IP ラベル、アプリケーション、ファイルシステム、ボリューム・グループなどの共用リソースを含む 1 つの単位として扱われます。各リソース・グループに対して、そのグループの獲得または解放を行うタイミングと方法を定めるポリシーを定義します。

『クラスターの初期計画』では、リソース・グループ・ノード・リスト内の各ノードに対してリソース・グループ・ポリシーとテークオーバー優先順位を事前に選択しました。この章では、次の作業を行います。

v 各リソース・グループを構成する個々のリソースを確認します。

v 各リソース・グループごとに、コンカレントまたは非コンカレントのどちらのタイプのグループであるのかを指定します。

v リソース・グループの参加ノード・リストを定義します。ノード・リストには、所定のリソース・グループのテークオーバーに参加するように割り当てられたノードが示されます。

v リソース・グループの始動ポリシー、フォールオーバー・ポリシー、およびフォールバック・ポリシーを指定します。

v ロケーション依存関係や親/子依存関係を設定するアプリケーションとそのリソース・グループを指定します。

v リソース・グループのサイト間管理ポリシーを指定します。そのグループはサイト対応であるのか、検討すべき複製リソースが存在するのかを確認します。

v リソース・グループの動作を調整するための他の属性とランタイム・ポリシーを指定します。

このセクションでは、次の定義を使用します。

v 参加ノード・リスト。 (SMIT でリソース・グループの参加ノード名に定義された、特定のリソース・グループをホストできるノード・リスト)。異なるリソース・グループ・ポリシーの組み合わせ、および現在のクラスター状況も、クラスター内のノード上のリソース・グループの配置に影響を与えることに注意してください。

v ホーム・ノード (またはこのリソース・グループに関して最も優先順位の高いノード)。非コンカレント・リソース・グループの参加ノード・リストに含まれる最初のノード。

HACMP リソース・グループは、NFS ファイルシステムをサポートします。

関連資料:




リソースおよびリソース・グループの一般的な規則リソースおよびリソース・グループには一般的な規則と制限がいくつかあります。

以下の規則と制限がリソースとリソース・グループに適用されます。


v HACMP でクラスター・リソースの高可用性を維持するためには、各クラスター・リソースをリソース・グループに含める必要があります。個別に扱いたいリソースがある場合は、そのリソース専用のグループを定義します。リソース・グループに定義するリソースは、1 つでも複数でもかまいません。

v 1 つのリソースを複数のリソース・グループに含めることはできません。

v リソース・グループのコンポーネントは固有である必要があります。同じリソース・グループに入れる必要があるアプリケーションをリソースと同じ場所に配置します。

v サービス IP ラベル、ボリューム・グループ、およびリソース・グループの名前は、クラスター内で一意であるととともに、相互に異なる必要があります。リソース名は、そのリソースが使用されるアプリケーションや対応するデバイスに関連した名前 (websphere_service_address など) にすることをお勧めします。

v 同じノードを複数のリソース・グループの参加ノード・リストに組み込む場合は、そのノードが、すべてのリソース・グループを同時に管理するために必要なメモリーやネットワーク・インターフェースなどを備えていることを確認してください。

2 つのタイプのリソース・グループ: コンカレントおよび非コンカレントリソース・グループの動作を分類して説明するために、リソース・グループをコンカレントと非コンカレントという 2 つのカテゴリーに分けます。

コンカレント・リソース・グループ

コンカレント・リソース・グループは複数のノードでオンラインにできます。リソース・グループのノード・リストのすべてのノードが、クラスターへの結合時にそのリソース・グループを獲得します。ノード間に優先順位はありません。コンカレント・リソース・グループは、最大で 32 のノードからなるクラスターでサポートされます。

コンカレント・リソース・グループに含まれるリソースは、ロー論理ボリュームが含まれているボリューム・グループ、ロー・ディスク、およびディスクを使用するアプリケーション・サーバーのみです。これらの論理ストレージ・エンティティーが定義されたデバイスは、コンカレント・アクセスをサポートする必要があります。

コンカレント・リソース・グループは、「Online on All Available Nodes (使用可能なすべてのノードでオンライン)」という始動ポリシーが設定されており、あるノードから別のノードへのフォールオーバーやフォールバックは行いません。

非コンカレント・リソース・グループ

非コンカレント・リソース・グループは、複数のノード上でオンラインにすることはできません。これらのリソース・グループに対しては、さまざまな始動ポリシー、フォールオーバー・ポリシー、およびフォールバック・ポリシーを定義できます。

ノードの始動時、ノードでの障害にともないリソース・グループが別のノードへフォールオーバーする時点、またはリソース・グループが再統合ノードへフォールバックする時点での、ノード設定の非コンカレント・リソース・グループの動作を調整できます。詳しくは、『始動、フォールオーバー、およびフォールバックのリソース・グループ・ポリシー』を参照してください。

関連資料:

127ページの『リソース・グループ属性と始動、フォールオーバー、フォールバックとの関係』それぞれの属性は、リソース・グループの始動、ノード障害時における別のノードへのリソース・グループのフォールオーバー、または再統合されたノードへのリソース・グループのフォールバックに影響を与えま

計画 125

す。

始動、フォールオーバー、およびフォールバックのリソース・グループ・ポリシーリソース・グループの動作は、次の 3 種類のノード・ポリシーに分類されます。

そのポリシーとは、以下のものです。

v 始動ポリシーでは、ノードがクラスターに結合され、リソース・グループがまだどのノード上でもアクティブでない場合に、どのノードでリソース・グループが活動化されるのかを定義します。

v フォールオーバー・ポリシーでは、現在リソース・グループがオンラインになっているノードで障害が発生したために、そのノードからリソース・グループを分離する必要がある場合 (または、フォールオーバー・オプションを使用してノード上のクラスター・サービスを停止した場合) に、リソース・グループがどのノードにフォールオーバーするのかを定義します。

v フォールバック・ポリシーでは、ノードがクラスターに結合して、リソース・グループが別のノード上ですでにアクティブである場合に、リソース・グループがどのノードにフォールバックするのかを定義します。

HACMP では、リソース・グループの始動動作、フォールオーバー動作、フォールバック動作の有効な組み合わせのみを構成できます。次の表は、HACMP で構成可能なリソース・グループの基本的な始動動作、フォールオーバー動作、フォールバック動作の概要を示します。

始動動作フォールオーバー動作フォールバック動作

ホーム・ノード上でのみオンラインになる (ノード・リストの最初のノード)

v リスト内で次に優先順位の高いノードにフォールオーバーする

または

v 動的ノード優先順位を使用してフォールオーバーする

v フォールバックしない

または

v リスト内で最も優先順位の高いノードにフォールバックする

ノード配布ポリシーを使用してオンライン


または


フォールバックしない

最初に使用可能なノードでオンライン

以下のいずれか



v フォールバックしない

または

v リスト内で最も優先順位の高いノードにフォールバックする

使用可能なすべてのノード上でオンライン

オフラインにする (エラー・ノード上でのみ) フォールバックしない

前の表で説明したノード・ポリシーに加えて、他の問題によってもノードの獲得するリソース・グループが決定される可能性があります。

関連タスク:

150ページの『リソース・グループ・ワークシートの記入』リソース・グループ・ワークシートはクラスターのリソース・グループを計画する際に役立ちます。リソース・グループごとに 1 枚のワークシートに記入します。


関連資料:


リソース・グループ属性このセクションでは、リソース・グループの始動、フォールオーバー、およびフォールバック・ポリシーの調整に使用できる、リソース・グループ属性について概説します。

リソース・グループ属性と始動、フォールオーバー、フォールバックとの関係それぞれの属性は、リソース・グループの始動、ノード障害時における別のノードへのリソース・グループのフォールオーバー、または再統合されたノードへのリソース・グループのフォールバックに影響を与えます。

次の表では、リソース・グループの始動ポリシー、フォールオーバー・ポリシー、またはフォールバック・ポリシーが、どの属性またはランタイム・ポリシーによる影響を受けるのかを示しています。

属性始動ポリシーフォールオーバー・ポリシーフォールバック・ポリシー

整定時間X

ノード配布ポリシーX

動的ノード優先順位X

遅延フォールバック・タイマーX

リソース・グループの親/子依存関係X X X

リソース・グループのロケーション依存関係 X X X

ガイドラインについては、『親および子従属リソース・グループ』および『リソース・グループのロケーション依存関係』を参照してください。

関連資料:

131ページの『親および子従属リソース・グループ』異なるリソース・グループ内の関連するアプリケーションが、論理的な順序で処理されるように構成されます。

132ページの『リソース・グループのロケーション依存関係』異なるリソース・グループの特定のアプリケーションが、同一のノードまたはサイトでオンラインのままになるか、または異なるノードでオンラインのままになります。

始動の整定時間リソース・グループの始動動作を変更するには、現在オフラインのリソース・グループの整定時間を指定します。整定時間を指定すると、この時間内に、リソース・グループのより優先順位の高いノードがクラスターに結合できるため、リソース・グループが最初の使用可能なノード上で活動化されることを防止できます。

整定時間を指定すると、クラスター・マネージャーは指定された時間だけ待機した後で、リソース・グループを活動化するようになります。リソース・グループに対して優先順位が高くなるノードがオンラインになった際に、リソース・グループがノード間でバウンスしないようにするため、この属性を使用します。

計画 127

始動するノードが、このリソース・グループのノード・リスト内の最初のノードである場合、整定時間がスキップされ、HACMP はただちにこのノード上でリソース・グループを獲得しようとします。

整定時間には次の特性があります。

v 現在オフラインであり、始動ポリシーを「Online on First Available Node (最初に使用可能なノードでオンライン)」に指定したリソース・グループにのみ適用されます。そのようなすべてのリソース・グループに対して、単一の整定時間を構成します。

v リソース・グループを獲得できる最初のノードがクラスターに結合する際に活動化します。ただし、これがノード・リスト内の最初のノードである場合は除きます (この場合は整定時間が無視されて、このグループが獲得されます)。

クラスターに結合されて、リソース・グループを獲得できる可能性のある最初のノードに障害が発生した場合は、整定時間が取り消しまたはリセットされます。

v 優先順位の高いノードがクラスターに結合されると、node_up イベント時にグループの活動化が遅延されます。

v リソース・グループに整定時間が指定されており、リソース・グループが現在エラー状態にある場合、クラスター・マネージャーは node_up イベント時に、指定された整定時間の間待機した後で、そのリソース・グループをオンラインに切り替えようとします。

整定時間が構成されているノードの再統合

通常は、ノードがクラスターに結合されると、そのノードはリソース・グループを獲得できます。以下にこのプロセスにおける整定時間の役割を示します。

v ノードが特定のリソース・グループの最高優先順位ノードである場合、ノードは即時にそのリソース・グループを獲得し、整定時間は無視されます。(HACMP が設定を無視するのはこの場合だけです。)

v ノードがいくつかのリソース・グループを獲得できるものの、それらのグループの最高優先順位のノードではない場合、リソース・グループはそのノード上では獲得されません。代わりに、リソース・グループは整定時間のインターバルの間待機して、より優先順位の高いノードがクラスターに結合されるかどうかを確認します。

整定時間間隔が経過すると、HACMP は、現在使用可能でリソース・グループを獲得できる最高優先順位ノードに、リソース・グループを移動します。HACMP が適切なノードを検出できない場合は、リソース・グループはオフラインのままになります。

ノード配布ポリシー始動時にノード配布ポリシーを使用するように、リソース・グループの始動動作を構成できます。このポリシーにより、このポリシーが有効になっている 1 つのリソース・グループのみがノード上で始動時に獲得されるようになります。

クラスター始動のノード配布ポリシーを使用することで、HACMP が、このポリシーが有効になっている1 つのリソース・グループのみを各ノード上で活動化するように設定できます。このポリシーを使用すると、CPU 集中型のアプリケーションを、異なる複数のノードに配布できます。

ノード配布ポリシーの特性は次の通りです。

v 交換による IPAT を使用して構成される単一のアダプター・ネットワークを使用する場合は、リソース・グループの始動ポリシーを「Online using Distribution Policy (配布ポリシーを使用してオンライン)」に設定する必要があります。


v 特定のノードが結合する際に、このポリシーが有効になっている 2 つのリソース・グループがオフラインである場合は、いずれかのリソース・グループのみがノード上で獲得されます。HACMP は、ノード・リストに含まれるノードが少ないリソース・グループを優先した上で、リソース・グループのリストをアルファベット順にソートします。

v リソース・グループの 1 つが親リソース・グループ (子リソース・グループを持つ) である場合、HACMP は親リソース・グループを優先するため、親リソース・グループがノード上で活動化されます。

v リソース・グループを始動時だけではなく、回復イベント (フォールオーバー、フォールバック) でも配布するには、ロケーション依存関係を使用します。『リソース・グループ依存関係』を参照してください。

関連資料:


動的ノード優先順位ポリシー動的ノード優先順位を使用するように、リソース・グループのフォールオーバー動作を構成できます。この構成により、「lowest CPU load (最小の CPU 負荷)」などの定義済み RSCT リソース変数を使用して、テークオーバー・ノードを選択できます。

動的ノード優先順位ポリシーを設定することにより、「lowest CPU load (最小の CPU 負荷)」などの定義済み RMC リソース変数を使用して、テークオーバー・ノードを選択できます。動的優先順位ポリシーを有効にすると、テークオーバー・ノード・リストの順序は、イベント発生時のクラスターの状態によって決定されます。クラスターの状態は、選択した RMC リソース変数から判断されます。異なるグループにさまざまなポリシーを設定したり、複数のグループに同じポリシーを設定したりできます。

RMC リソース変数を使用して動的ノード優先順位ポリシーを定義し、リソース・グループのフォールオーバー・ノードを決定する場合は、次の点を考慮してください。

v 動的ノード優先順位ポリシーは、すべてのノードが同じ処理能力とメモリーを備えているクラスターで最も効果を発揮します。

v 動的ノード優先順位ポリシーは、ノード数が 3 未満のクラスターでは適切ではありません。

v 動的ノード優先順位ポリシーは、コンカレント・リソース・グループでは適切ではありません。

テークオーバー・ノードの選択は、そのノード上でのネットワーク・インターフェースの可用性などの条件にも左右されることに注意してください。

遅延フォールバック・タイマー遅延フォールバック・タイマーを指定して割り当てることで、事前に定義した定期的な時点 (日次、週次、月次、年次、または特定の日時) のいずれかでリソース・グループのフォールバック動作が実行されるように構成できます。

遅延フォールバック・タイマーを使用すると、リソース・グループがより優先順位の高いノードにフォールバックする時間を設定できます。事前に定義した定期的な時点 (日次、週次、月次、または特定の日付)

のいずれかでリソース・グループのフォールバック動作が実行されるように構成できます。

遅延フォールバック・タイマーには次の特性があります。

v ホーム・ノード以外のノードや優先順位の低いノードに配置されたオンラインのリソース・グループが、ホーム・ノードやより優先順位の高いノードにフォールバックするタイミングを指定します。

計画 129

v 他のノードへのリソース・グループの移動に影響を与えます。例えば、リソース・グループ管理ユーティリティー (clRGmove) を使用して、非コンカレント・リソース・グループ (フォールバック・タイマー属性を持つもの) を別のノードに移動した場合、そのグループは移動先ノード上にとどまります (クラスターをリブートした場合は除きますが、これはまれなケースです)。移動先ノードがダウンして再統合された場合、リソース・グループも指定されたタイミングでこのノードにフォールバックします。

遅延フォールバック・タイマーの設定されたノードの再統合

リソース・グループは、次の条件下では、即座に優先順位の高いノードにフォールバックしません。

v リソース・グループに遅延フォールバック・タイマーを構成している

v 優先順位の高いノードがクラスターに結合される

遅延フォールバック・タイマー属性で指定した時点になると、次のいずれかのシナリオが実行されます。

v より高い優先順位のノードが見つかった場合。リソース・グループで使用可能なより優先順位の高いノードがある場合、HACMP はフォールバック・タイマーの満了時にそのノードにリソース・グループを移動しようとします。獲得が成功すると、リソース・グループはそのノード上で獲得されます。

ただし、移動先のノード上でリソース・グループの獲得に失敗すると、HACMP はグループのノード・リスト内で次に優先順位の高いノードにリソース・グループを移動しようとします (以降同様に処理されます)。使用可能な最後のノード上でリソース・グループの獲得に失敗すると、リソース・グループはエラー状態になります。この場合は、そのエラーを修復するための操作を実行して、このようなリソース・グループをオンラインに戻す必要があります。

v より高い優先順位のノードが見つからない。リソース・グループに対して優先順位の高いノードが無い場合、フォールバック・タイマーが再び満了するまでリソース・グループはオンライン状態を維持します。例えば、日次フォールバック・タイマーが午後 11:00 に満了するように指定されており、リソース・グループに対してフォールバック可能な優先順位の高いノードが無い場合は、フォールバック・タイマーは次の夜の 11:00 に再発します。

特定の日付に設定されたフォールバック・タイマーは再実行されません。

リソース・グループ依存関係HACMP には、始動時、フォールオーバー時、フォールバック時に維持したいリソース・グループ間の関係を指定できるさまざまな構成があります。

以下の構成が可能です。

v 親および子従属リソース・グループ。異なるリソース・グループの関連するアプリケーションおよび他のリソースが、適切な順序で処理されるように構成されます。

v リソース・グループのロケーション依存関係異なるリソース・グループの特定のアプリケーションが、同一のノードまたはサイトでオンラインのままになるか、または異なるノードでオンラインのままになります。

依存関係の構成について計画するときは、以下の点に留意してください。

v デフォルトではすべてのリソース・グループが同時に処理されますが、HACMP では、必ずしも同時にではなく、依存関係によって定められた順序に従って従属リソース・グループが処理されます。リソース・グループの依存関係はクラスター全体で順守されます。依存関係に含まれるリソース・グループの順次処理の順序がカスタマイズされている場合、その内容は依存関係によって無効化されます。詳しくは、『従属リソース・グループと並列/順次処理順序』を参照してください。


v リソース・グループ間の依存関係により、多層アプリケーションを使用してクラスターを構築する、予測可能な信頼性の高い方法が得られます。

依存関係を組み合わせる構成には、次の制限事項が適用されます。これらのガイドラインに従わない場合、検証は失敗します。

v 「Online on Same Node (同じノードでオンライン)」依存関係セットと「Online On Different Nodes (異なるノードでオンライン)」依存関係セットには、同時に 1 つのリソース・グループだけが所属できます。

v 「Online On Different Nodes (異なるノードでオンライン)」依存関係セット内で同じ優先順位が設定されているリソース・グループだけが、「Online on Same Site (同じサイトでオンライン)」依存関係セットに所属できます。

関連資料:

138ページの『リソース・グループの並列処理順序または順次処理順序の計画』デフォルトでは、HACMP はクラスター内で構成されているすべての個別リソースを同時に獲得および解放します。ただし、個々のリソース・グループの一部またはすべてを獲得、解放する順次処理の順序を指定できます。

親および子従属リソース・グループ:

異なるリソース・グループ内の関連するアプリケーションが、論理的な順序で処理されるように構成されます。

リソース・グループの依存関係を構成することにより、多層アプリケーションが含まれたクラスターをより適切に制御できるようになります。このようなクラスターでは、1 つのアプリケーションが別のアプリケーションの正常な起動に依存し、また両方のアプリケーションが HACMP によって高可用性を維持される必要があります。詳しくは、『多層アプリケーションの計画に関する注意事項』を参照してください。

以下の例で、親/子依存関係の動作を説明します。

v リソース・グループ A がリソース・グループ B に従属する場合、リソース・グループ B はリソース・グループ A がクラスター内のいずれかのノード上で獲得される前にオンラインにならなければなりません。リソース・グループ A は子リソース・グループとして、リソース・グループ B は親リソース・グループとして定義されることに注意してください。

v 子リソース・グループ A が親リソース・グループ B に従属する場合、ノードの始動時またはノードの再統合時に、親リソース・グループ B がオンラインになる前に子リソース・グループ A がオンラインになることはできません。親リソース・グループ B をオフラインにする場合、子リソース・グループ A

はリソース・グループ B に従属するため、子リソース・グループ A が最初にオフラインになります。

多層アプリケーションを使用するビジネス構成では、親/子従属リソース・グループを利用できます。例えば、データベースは、アプリケーション・サーバーより先にオンラインにする必要があります。この場合、データベースが別のノードに移動されると、アプリケーション・サーバーが含まれたリソース・グループは、いったん停止されてからクラスター内の任意のノード上でバックアップされる必要があります。

子リソース・グループに、親リソース・グループのリソースに依存するアプリケーションが含まれている場合に、親リソース・グループが別のノードにフォールオーバーすると、子リソース・グループは一時的に停止し、自動的に再始動されます。同様に、子リソース・グループがコンカレントの場合も、HACMP は、子リソース・グループをすべてのノード上で一時的にオフラインにして、使用可能なすべてのノード上でオンラインに戻します。親リソース・グループのフォールオーバーが失敗すると、親リソース・グループと子リソース・グループは両方ともエラー状態になります。

計画 131

親/子従属リソース・グループを計画する際には、以下の事項を検討してください。

v 高可用性を維持する必要のあるアプリケーションを計画し、ビジネス環境において、あるアプリケーションを開始する前に別のアプリケーションが実行中となっている必要があるかどうかを検討します。

v 順序付けを必要とするアプリケーションが異なるリソース・グループに含まれるようにします。これにより、リソース・グループ間の依存関係を設定できます。

v 子リソース・グループまたは親リソース・グループに組み込む予定の各アプリケーションごとに、アプリケーション・モニターについて計画します。親リソース・グループ内のアプリケーションに対して、モニター始動モードでモニターを構成します。

アプリケーションの停止および再起動プロセスにおけるデータ損失の可能性を最小限にするには、アプリケーション・サーバー・スクリプトをカスタマイズして、アプリケーションの停止プロセス時は、コミットされていないデータを共用ディスクに一時的に格納し、アプリケーションの再起動プロセス時にアプリケーションに読み込み直すようにします。アプリケーションは停止したノードとは別のノード上で再始動される場合があるため、共用ディスクを使用することが重要です。

関連資料:


リソース・グループのロケーション依存関係:

異なるリソース・グループの特定のアプリケーションが、同一のノードまたはサイトでオンラインのままになるか、または異なるノードでオンラインのままになります。

時間の経過に伴い障害が発生すると、HACMP がリソース・グループを配布するため、リソース・グループが引き続き使用可能になりますが、これらのリソース・グループのホーム・ノードとフォールオーバー・ポリシーおよびフォールバック・ポリシーが同じである場合を除いて、これらのリソース・グループは、最初に指定したノードで使用可能になるとは限りません。

リソース・グループのロケーション依存関係を使用すると、特定の複数のリソース・グループが常に同じノード上でオンラインになるように、または特定の複数のリソース・グループが常に異なるノード上でオンラインになるように、明示的に指定できます。これらのロケーション・ポリシーを親/子依存関係と組み合わせて使用することで、すべての子リソース・グループを同じノードでオンラインにする一方で親を異なるノードでオンラインにすることや、すべての子リソース・グループを異なるノードでオンラインにしてパフォーマンスを向上させることなどができます。

複製リソースがある場合は、複数のリソース・グループを 1 つのサイト依存関係にまとめて、これらのリソース・グループを常に同じサイトでオンライン状態に保つことができます。詳しくは、セクション『サイトの使用に関する特殊な考慮事項』を参照してください。

HACMP では、リソース・グループ間で次の 3 種類のリソース・グループ・ロケーション依存関係をサポートしています。

v 同じノードでオンライン

「Online on Same Node (同じノードでオンライン)」依存関係のリソース・グループ・セットには、以下の規則と制限が適用されます。これらのガイドラインに従わない場合、検証は失敗します。


– 同じノードの依存関係セットの一部として構成されるすべてのリソース・グループでは、ノード・リストが同一である (同じノードが同一順序でリストされている) 必要があります。

– 同じノードの依存関係セットのすべての非コンカレント・リソース・グループでは、始動ポリシー、フォールオーバー・ポリシー、フォールバック・ポリシーが同一である必要があります。

– 「Online Using Node Distribution Policy (ノード配布ポリシーを使用してオンライン)」は、始動では使用できません。

– 動的ノード優先ポリシーをフォールオーバー・ポリシーとして構成する場合は、セット内のすべてのリソース・グループのポリシーが同一である必要があります。

– 1 つのリソース・グループでフォールバック・タイマーが構成されている場合、そのフォールバック・タイマーはリソース・グループのセットに適用されます。セット内のすべてのリソース・グループのフォールバック・タイマー設定が同一である必要があります。

– コンカレントと非コンカレントの両方のリソース・グループを含めることができます。

– クラスター内に複数の同じノードの依存関係セットを設定できます。

– HACMP は、アクティブ (ONLINE) な同じノードの依存関係セットにあるすべてのリソース・グループは同一ノードで ONLINE でなければならない、という条件を施行します。セット内の一部のリソース・グループが OFFLINE か ERROR 状態になることがあります。

– 同じノードの依存関係セットにある 1 つ以上のリソース・グループで障害が発生すると、HACMP はセット内のすべてのリソース・グループを、現在 ONLINE (引き続きアクティブ) であるすべてのリソース・グループと 1 つ以上の障害発生リソース・グループをホストできるノードに配置しようとします。

v 同じサイトでオンライン

「Online on Same Site (同じサイトでオンライン)」依存関係のリソース・グループ・セットには、以下の規則と制限が適用されます。これらのガイドラインに従わない場合、検証は失敗します。

– 同じサイトの依存関係のセットにあるすべてのリソース・グループでは、サイト間管理ポリシーが同一である必要がありますが、始動、フォールオーバー、フォールバックのポリシーは異なってもかまいません。フォールバック・タイマーが使用されている場合は、セット内のすべてのリソース・グループにタイマーが適用されます。

– フォールバック・タイマーは、サイト境界を越えるリソース・グループの移動には適用されません。

– 同じサイトの依存関係のセットのすべてのリソース・グループでは、リソース・グループを所有できるノードが同一の 1 次サイトおよび 2 次サイトに割り当てられるように構成する必要があります。

– 「Online Using Node Distribution Policy (ノード配布ポリシーを使用してオンライン)」始動ポリシーがサポートされています。

– コンカレントと非コンカレントの両方のリソース・グループを含めることができます。

– クラスター内に複数の同じサイトの依存関係のセットを配置できます。

– 同じサイトの依存関係セットのすべてのアクティブ (ONLINE) なリソース・グループは、同一サイトで ONLINE である必要があります。ただしこの場合、同じサイトの依存関係セット内の一部のリソース・グループが OFFLINE または ERROR 状態になる可能性があります。

– 同じノードの依存関係セットに含まれる 1 つのリソース・グループを同じサイトの依存関係セットに追加する場合、同じノードの依存関係セットに含まれる他のすべてのリソース・グループを同じサイトの依存関係セットに追加する必要があります。

v 異なるノードでオンライン

リソース・グループの「Online On Different Nodes (異なるノードでオンライン)」依存関係セットには、以下の規則と制限が適用されます。これらのガイドラインに従わない場合、検証は失敗します。

計画 133

– 「Online On Different Nodes (異なるノードでオンライン)」依存関係セットは、各クラスターあたり1 つだけ設定できます。

– セット内の各リソース・グループが異なるノードで始動するように始動ポリシーを計画します。

– 親/子依存関係が指定されている場合、子リソース・グループには、親リソース・グループよりも高い優先順位を設定できません。

このようなグループ構成でクラスターを実行する場合は、以下の点に留意してください。

– 優先順位が高いリソース・グループがノード上で ONLINE になっている場合は、「Online On

Different Nodes (異なるノードでオンライン)」依存関係セット内のその他の優先順位の低いリソース・グループは、そのノードでは ONLINE になることができません。

– 優先順位の高いリソース・グループが特定のノードにフォールオーバーまたはフォールバックした場合、この優先順位の高いリソース・グループは ONLINE になり、クラスター・マネージャーは優先順位の低いリソース・グループを OFFLINE にして、別のノードに移動します (可能な場合)。

– 同じ優先順位の複数のリソース・グループが、同一ノードで ONLINE (始動) になることはできません。同じ優先順位レベル内にあるノードのリソース・グループの優先順位は、そのセットにおけるグループのアルファベット順によって決まります。

– 同じ優先順位のリソース・グループ同士が、フォールオーバーやフォールバックの後で互いをノードから移動することはありません。

– 同じサイトと同じ/異なるノードのロケーション依存関係の組み合わせ

– 「Online on Same Node (同じノードでオンライン)」と「Online on Same Site (同じサイトでオンライン)」の両方のポリシーに属するリソース・グループを構成できます。また、「Online on Same Site

(同じサイトでオンライン)」と「Online On Different Nodes (異なるノードでオンライン)」の両方のポリシーに属するリソース・グループを構成することもできます。

関連資料:

141ページの『サイトの使用に関する特殊な考慮事項』このセクションでは、リソース・グループに始動ポリシー「Online using node distribution policy (ノード配布ポリシーを使用してオンライン)」または依存関係が指定されている場合の考慮事項について説明します。


別のノードへのリソース・グループの移動HACMP にリソース・グループを別のノードに移動するように指示する際、いくつかのオプションが使用できます。

これらのオプションには、以下のものがあります。

v リソース・グループが移動された先のノード上にとどまります。

「Never Fallback (フォールバックしない)」ポリシーが設定されたリソース・グループを別のノードに移動できます。その際に、リソース・グループを再び移動することを決定するまで、そのグループを移動先ノードに残すように HACMP に指示できます。

v RG_move でリソース・グループを移動すると、そのグループは、無期限に (別のノードに移動するように HACMP に指示するまで)、またはクラスターをリブートするまで、移動先のノード上にとどまります。


クラスター・サービスを停止した場合に (その必要はほとんどありませんが)、リソース・グループのノード・リストと最高優先順位のノードを永続的に変更するには、リソース・グループの属性を変更してクラスターを再始動してください。

v いずれかのノード上でリソース・グループをオンラインまたはオフラインにした場合は、次回のクラスターのリブート時まで、またはクラスター内の別の場所でそのグループを手動でオンライン状態にするまで、そのリソース・グループはオンラインまたはオフラインのままになります。

v リソース・グループに「Fallback to Highest Priority Node (最高の優先順位のノードにフォールバック)」ポリシーが設定されている場合、そのグループは、移動されたあとに移動先ノードにフォールバックします。

例えば、グループの最高優先順位ノードとしてノード A が構成されている場合に、このグループをノード B に移動すると、このグループはノード B 上にとどまり、このノードを新たな最高優先順位ノードとして扱います。SMIT を使用してこの操作を実行すると、「元の」最高優先順位ノード (ノード A) で現在そのグループをホストできるかどうかが HACMP から通知されます。

clRGinfo -p コマンドを使用すると、手動で移動されたすべてのリソース・グループの状況をトラッキングできます。

clRGmove によるリソース・グループの移動clRGmove コマンドを使用すると、リソース・グループを別のノードまたは別のサイトに移動したり、リソース・グループをオンライン状態やオフライン状態にしたりできます。リソース・グループは、クラスターがリブートされるまでそのノード上にとどまります。clRGmove コマンドは SMIT またはコマンド行から実行できます。

「Never Fallback (フォールバックしない)」フォールバック・ポリシーが設定されたリソース・グループに対して clRGmove を使用した場合、そのリソース・グループは別の場所に移動されるまでそのノード上にとどまります。

clRGmove による親/子依存関係があるリソース・グループの移動

親/子の依存関係を持つリソース・グループには、次の規則が適用されます。

v clRGmove を介して発行した要求を受けて親リソース・グループがオフラインになっている場合、これらの親リソース・グループに依存する子リソース・グループを手動でオンラインに切り替えようとしても HACMP によって拒否されます。エラー・メッセージに、最初にオンラインにする必要がある親リソース・グループがリストされます。

v 親リソース・グループと子リソース・グループがオンラインになっている場合、親リソース・グループを別のノードに移動しようとしたり、オフラインにしようとしても、子リソース・グループをオフラインにするまでは HACMP によって拒否されます。

clRGmove を使用したロケーション依存リソース・グループの移動

ロケーション依存関係を持つリソース・グループには、次の規則が適用されます。

v 同じサイトに依存するリソース・グループを他のサイトに移動する場合は、依存関係にあるリソース・グループのセット全体が他のサイトに移動されます。

v 同じノードに依存するリソース・グループを他のノードに移動する場合は、依存関係にあるリソース・グループのセット全体が移動されます。

v 別のノード依存関係の一部であるオンラインのリソース・グループをホストするノードには、リソース・グループを移動できません。まず、選択したノード上で、別のノード依存関係に含まれている当該リソース・グループをオフラインにする必要があります。

計画 135

クラスター・ネットワークとリソース・グループの計画IP 交換による IPAT と IP エイリアスによる IPAT のラベルを同じリソース・グループ内で併用することはできません。この制約は、クラスター・リソースの検査時に施行されます。

いかなるタイプの IPAT も、コンカレント・リソース・グループには適用されません。

エイリアスを使用するネットワークとリソース・グループリソース・グループには、複数のサービス IP ラベルが含まれる場合があります。IP エイリアスによるIPAT を使用して構成されたリソース・グループを、エイリアスを使用するネットワークに移動すると、HACMP 内のリソース・グループ管理ポリシーに従って、リソース・グループ内のすべてのサービス・ラベルが、使用可能なネットワーク・インターフェースにエイリアスとして移動されます。

「IP エイリアスによる IPAT」の計画については、『IP エイリアスによる IP アドレス・テークオーバー』を参照してください。

エイリアスを使用するネットワークをクラスター内で構成する場合は、『クラスター・イベント時のリソース・グループの動作』を参照して、クラスター始動時およびフォールオーバー時にサービス IP ラベルがどのように移動されるのかを確認してください。

関連資料:

49ページの『IP エイリアスによる IP アドレス・テークオーバー』HACMP は、IP エイリアスによる IPAT を使用して、サービス IP アドレスの高可用性を維持します。

IP 交換による IPAT ネットワークとリソース・グループすべての非コンカレント・リソース・グループは、サービス IP ラベルを IP 交換による IPAT ネットワークで構成できます。

さらに、IP 交換による IPAT ネットワーク上にサービス・レベルを持つリソース・グループを構成する計画の場合は、計画に関する次の考慮事項が適用されます。

v 交換による IPAT を使用して構成される単一のアダプター・ネットワークを使用する計画の場合は、リソース・グループの始動ポリシーを「Online using Distribution Policy (配布ポリシーを使用してオンライン)」に設定する必要があります。

v IP 交換による IPAT ネットワークごとに、サービス IP ラベルも構成された 1 つの非コンカレント・リソース・グループのみに対して最高優先順位ノードとして機能するノードを 1 つ構成できます。

このようなリソース・グループには、「Online on First Available Node (最初に使用可能なノードでオンライン)」または「Online on Home Node Only (ホーム・ノードのみでオンライン)」のいずれかの始動ポリシーを設定する必要があります。これらのリソース・グループには、「Online using Distribution Policy

(配布ポリシーを使用してオンライン)」始動ポリシーは設定できません。

v 同じ IP 交換による IPAT ネットワーク上で構成されたサービス IP ラベルを、異なる複数のリソース・グループに配置してください。HACMP は、IP 交換による IPAT ネットワーク上の複数のサービスIP ラベルが構成されていることを検出すると、エラーを発行します。

v リソース・グループは、IP 交換による IPAT ネットワークからの複数のサービス IP ラベルを含むことはできません。

リソース・グループ内のサービス IP ラベルの計画HACMP で管理されるブートおよびサービス IP ラベル/アドレスのサブネット要件は、いくつかの変数によって異なります。


これらの変数に含まれるものは、次のとおりです。

v 選択した IP ラベル/アドレスの回復メソッド: IP エイリアスによる IPAT、またはハードウェア・アドレス・テークオーバー (HWAT) を伴う (または伴わない) IP 交換による IPAT

v IP ラベルが含まれるリソース・グループのタイプ

注: ブート IP ラベル/アドレスは、ブート時に使用される初期 IP ラベル/アドレスです。このセクションでは、「ブート」という用語は、異なる IP ラベル (ブートとサービス) が構成されるサブネットに関する HACMP 要件の説明として使用されています。

ノードごとにネットワーク・インターフェースが 1 つしかない場合 (例えば、仮想ネットワーク環境では)、1 つのサブネット経路しかないため、ブート IP アドレスとサービス IP アドレスは同じサブネット上に存在することがあります。

HACMP がネットワーク・インターフェースの正常性をモニターし、フォールオーバーおよびフォールバック時に正しくサブネット・ルーティングを維持できるようにするために、次の要件がクラスター構成に適用されます。

構成サービス IP ラベルに対するサブネット要件

構成の内容

v IP エイリアスを使用するハートビート

v IPAT

v 任意のタイプの非コンカレント・リソース・グループ

この場合、HACMP はいずれのブートまたはサービス IP ラベル/アドレスに対してもサブネット要件を適用しません。ブート・アドレスとサービス・アドレスは同じサブネットに共存させることも、別のサブネットに配置することもできます。HACMP はハートビートに必要な適切なアドレスを自動的に生成するため、その他のすべてのアドレスに対しては制約が課されることはありません。

IP エイリアスを使用するハートビートは、すべてのタイプの IPAT、IP エイリアスによる IPAT、IP 交換による IPAT、HWAT を伴う IP 交換による IPAT で機能します。

リソース・グループ管理ポリシーによって IP ラベルに制約事項が追加されることはありません。サービス・ラベルはすべてグループの動作に応じて処理され、サブネットによって影響されることはありません。

ハートビートに IP エイリアスを使用すると、ブートおよびサービス IP アドレスの構成の際に最大限の柔軟性が得られますが、特にハートビートを送信する場合に固有のIP アドレスとサブネット範囲を予約できなくなります。

構成の内容

v IP インターフェースを使用するハートビート

v IP エイリアスによる IPAT

v 任意のタイプの非コンカレント・リソース・グループ

IP エイリアスによる IPAT を使用する場合、リソース・グループのタイプにかかわらず、HACMP には以下の要件があります。

v ノード上のすべてのブート・インターフェースを別々のサブネットに構成しなければならない。これはハートビート操作を正常に実行するために必要です(この要件に対応しない場合、つまり同じサブネットに複数のインターフェースが存在する場合は、複数のサブネット経路が生成されます。その結果、ハートビートの信頼性が低下して障害検出が困難になります)。

v すべてのサービス IP アドレスを、どのブート・アドレスとも異なるサブネットに構成しなければならない。この要件によって、同じサブネットに対して多重経路が生成されることがなくなります。この要件は、単一のアダプターのネットワークに対しては、すべての経路が同じインターフェースにあるので、必要ありません。

v 複数のサービス IP ラベルを同じサブネットに構成できる。これは、HACMP ではブート IP アドレスを介してのみハートビートが送信されるためです。

次の表は、各リソース・グループおよびネットワーク構成に関するサブネット要件の概要を示しています。

計画 137

構成サービス IP ラベルに対するサブネット要件

構成の内容


v IP 交換による IPAT

v 始動ポリシーが「Online on Home Node

Only (ホーム・ノードのみでオンライン)」、フォールオーバー・ポリシーが「Fallover to Next Priority Node in the List

(リスト中の次の優先順位のノードにフォールオーバー)」、フォールバック・ポリシーが「Fallback to Highest Priority Node (最高の優先順位のノードにフォールバック)」のリソース・グループ

リソース・グループ内で最高の優先順位のノードは、ブート IP ラベル/アドレスを含むノードでなければなりません。ブート IP アドレスが、リソース・グループで使用されるサービス IP アドレスと同じサブネット上に存在するように、選択します。

最高の優先順位のノード上にある他のすべてのネットワーク・インターフェースは、ブート/サービス IP アドレスにより使用されるサブネットとは異なるサブネット上に配置する必要があります。

HACMP がこれらの要件を検証します。

構成の内容


v IP 交換による IPAT

v 始動ポリシーが「Online on First Available

Node (最初に使用可能なノードでオンライン)」または「Online Using Node

Distribution Policy (ノード配布ポリシーを使用してオンライン)」、フォールオーバー・ポリシーが「Fallover to Next Priority

Node in the List (リスト中の次の優先順位のノードにフォールオーバー)」、フォールバック・ポリシーが「Never Fallback (フォールバックしない)」のリソース・グループ

すべてのノードで、ブート/サービス IP アドレスに 1 つのサブネットを使用し、スタンバイに別のサブネットを使用するようにネットワーク・インターフェースを構成する必要があります。

また、交換による IPAT を使用して構成される単一のアダプター・ネットワークを使用する計画の場合は、リソース・グループの始動ポリシーを「Online using

Distribution Policy (配布ポリシーを使用してオンライン)」に設定する必要があります。

HACMP がこれらの要件を検証します。

リソース・グループの並列処理順序または順次処理順序の計画デフォルトでは、HACMP はクラスター内で構成されているすべての個別リソースを同時に獲得および解放します。ただし、個々のリソース・グループの一部またはすべてを獲得、解放する順次処理の順序を指定できます。

この場合、獲得処理では以下のことが行われます。

1. HACMP が、リストに指定された順序でリソース・グループを順次取得します。

2. HACMP が、残りのリソース・グループを同時に取得します。

注: リソース・グループでの並行処理と順次処理の順序の構成は、将来的には廃止される可能性があります。このオプションを使用する代わりに、リソース・グループの依存関係を構成して適切な処理の順序を設定してください。

解放時には、逆の処理が実行されます。

1. HACMP が、特定の順次処理順序が定義されなかったリソース・グループを同時に解放します。

2. クラスター内の残りのリソース・グループは、リストでこれらのリソース・グループに指定した順序で処理されます。

3. 以前のバージョンの HACMP からクラスターをアップグレードした場合は、このケースで使用される処理順序の詳細について、HACMP クラスターのアップグレードに関する章を参照してください。


4. 注: 単一ノード上のリソース・グループの処理順序を指定しても、リソース・グループの実際のフォールオーバーは別のポリシーによって起動される場合があります。したがって、リソース・グループのカスタマイズされた順次処理の順序は特定のノード上の処理にのみ適用されるため、クラスター全体でリソース・グループが指定した順序で処理されることは保証されません。

5. リソース・グループの並列処理時には、クラスター内で発生するクラスター・イベントの数が減少します。特に、node_up_local や get_disk_vg_fs などのイベントは、リソース・グループが並列処理される場合は発生しません。

6. この結果、並列処理を使用すると、カスタマイズしてイベント前処理/後処理スクリプトを作成できる特定のクラスター・イベントの数が少なくなります。構成内のリソース・グループの一部に対して並列処理の使用を開始する場合、既存のイベント前処理またはイベント後処理スクリプトがこれらのリソース・グループに対して機能しなくなることがある点に注意してください。リソース・グループの並列処理について、およびイベント・スクリプトの使用について詳しくは、『クラスター・イベントの計画』を参照してください。

7. リソース・グループの並列処理および順次処理は、hacmp.out ファイルにあるイベント要約に反映されます。

カスタマイズされたリソース・グループ順次取得/解放順序を構成する方法について詳しくは、『リソース・グループの処理順序の構成』を参照してください。

従属リソース・グループと並列/順次処理順序

デフォルトでは、HACMP はリソース・グループを並列処理しますが、クラスター内の一部のリソース・グループ間で依存関係を確立すると、依存関係を持つリソース・グループがない場合よりも処理に時間がかかることがあります。これは、1 つ以上の rg_move イベントの処理のために、処理が増える可能性があるためです。

獲得の際には、最初に親リソース・グループまたは優先順位が高いリソース・グループが獲得された後、子リソース・グループが獲得されます。解放時には、逆の順序で処理されます。クラスター内のその他のリソース・グループ (依存関係を持たないリソース・グループ) は、並列処理されます。

また、順次処理の順序を指定し、依存関係を持つリソース・グループを構成している場合は、順次処理の順序が、指定した依存関係と矛盾しないように注意してください。リソース・グループの依存関係は、クラスター内の順序をオーバーライドします。

関連資料:


サイトを持つクラスター内のリソース・グループの計画リソース・グループの始動動作、フォールオーバー動作、フォールバック動作は、選択したサイト間管理ポリシーと、ノードの始動、フォールオーバー、フォールバックの各ポリシーの組み合わせによって決まります。

HACMP でのサイトのサポートにより、さまざまなリソース・グループの構成が可能になります。

コンカレント・リソース・グループとサイト

コンカレント・リソース・グループには次のポリシーを使用できます。

計画 139

項目説明

サイト間管理ポリシー Online on Both Sites (両方のサイトでオンライン)

Online on Either Site (一方のサイトでオンライン)

Prefer Primary Site (1 次サイトを選択)

Ignore (無視)

始動ポリシー Online on All Available Nodes (使用可能なすべてのノードでオンライン)

フォールオーバー・ポリシー

Bring Offline (on Error node only) (オフラインにする (エラー・ノード上でのみ))

フォールバック・ポリシー Never Fallback (フォールバックしない)

非コンカレント・リソース・グループとサイト

非コンカレント・リソース・グループには、次のポリシーを使用できます。

項目説明

サイト間管理ポリシー Online on Either Site (一方のサイトでオンライン)

Prefer Primary Site (1 次サイトを選択)

Ignore (無視)

始動ポリシー Online on Home Node (ホーム・ノードのみでオンライン)

Online on First Available Node (最初に使用可能なノードでオンライン)

Online using Node Distribution Policy (ノード配布ポリシーを使用してオンライン)


Fallover to Next Priority Node (in the nodelist) ((リスト中の) 次の優先順位のノードにフォールオーバー)

フォールバック・ポリシー Fallback to higher priority node (in the nodelist) ((リスト中の) より高い優先順位のノードにフォールバック)

Never Fallback (フォールバックしない)

サイトを持つクラスター内のリソース・グループの一般的な動作サイト間管理ポリシー「Prefer Primary Site (1 次サイトを選択)」または「Online on Either Site (一方のサイトでオンライン)」が定義されている非コンカレント・リソース・グループには、クラスター実行時に次の 2 つのインスタンスが存在します。

そのインスタンスとは、以下のものです。

v 1 次サイトのノードの 1 次インスタンス

v 2 次サイトのノードの 2 次インスタンス

clRGinfo コマンドは、これらのインスタンスを以下のように示します。

v ONLINE

v ONLINE SECONDARY

サイト間管理ポリシー「Online on Both Sites (両方のサイトでオンライン)」が設定されたコンカレント・リソース・グループ (すべてのノードでオンライン) では、両方のロケーションでのクラスター実行時に複数の ONLINE インスタンスが存在し、ONLINE SECONDARY インスタンスが存在しません。


サイト間管理ポリシーに「Prefer Primary Site (1 次サイトを選択)」または「Online on Either Site (一方のサイトでオンライン)」が設定されているコンカレント・リソース・グループには、1 次サイトの各ノードに 1 次インスタンスが、2 次サイトのノードに 2 次インスタンスが存在します。

複製リソースが含まれているリソース・グループは、サイト管理ポリシーとノード始動ポリシーに従い、すべての依存関係を反映し、node_up で並列処理されます。サイト間でリソース・グループがフォールオーバーすると、新しいバックアップ・サイトで使用可能な最も優先順位が高いノードで 2 次インスタンスが獲得され、ONLINE SECONDARY になります(同じノードに複数の 2 次インスタンスを持つことができます)。その後、最も優先順位が高い使用可能なノードでリソース・グループの 1 次インスタンスが獲得され、ONLINE になり、新しい「アクティブな」サイトでこのリソース・グループがホストされます。この処理順序により、1 次インスタンスが始動するとただちにバックアップ・サイトがバックアップ・データを受け取ることができる状態になります。

2 次インスタンスがなんらかの理由で ONLINE_SECONDARY 状態になることができない場合、可能であれば 1 次インスタンスが引き続き ONLINE になります。

サイトの使用に関する特殊な考慮事項このセクションでは、リソース・グループに始動ポリシー「Online using node distribution policy (ノード配布ポリシーを使用してオンライン)」または依存関係が指定されている場合の考慮事項について説明します。

従属リソース・グループとサイト

異なるサイトのノード上に存在する 2 つ以上のリソース・グループ間に依存関係を指定できます。この場合、親または子のいずれかが他のサイトに移動すると、従属グループも移動します。なんらかの理由で親グループがフォールオーバー・サイトでオンラインになることができない場合は、子リソース・グループもアクティブになりません。

依存関係は、リソース・グループの 1 次インスタンスの状態のみに適用されることに注意してください。ノード上で、親グループの 1 次インスタンスが OFFLINE で 2 次インスタンスが ONLINE SECONDARY

の場合、子グループの 1 次インスタンスは OFFLINE になります。

リソース・グループの回復の場合、リソース・グループはいずれかのサイトのノードにフォールオーバーできます。従属リソース・グループの獲得順序は、サイトを持たないクラスターの場合と同様に、親リソース・グループが最初に獲得された後、子リソース・グループが獲得されます。解放のロジックは逆になります。親リソース・グループが解放される前に、子リソース・グループが解放されます。

「同じノード」依存関係を持つリソース・グループでは、始動時にリソース・グループ・ノード配布ポリシーを使用できないことに注意してください。同じサイト依存関係を持つリソース・グループに対して、このポリシーを使用できます。

サイトを定義した場合も、サイトを持たないクラスターと同様に、依存関係を持つリソース・グループに含まれているアプリケーションに対してアプリケーション・モニターを構成します。

サイトを持つクラスター内のリソース・グループ動作の例フォールバック・ポリシーは、リソース・グループの ONLINE インスタンスと ONLINE SECONDARY

インスタンスに適用されます。

リソース・グループのサイト間管理ポリシーにより、リソース・グループの ONLINE インスタンスの、サイト間のフォールバック動作が決定します。つまり、この管理ポリシーは 2 次インスタンスの位置を制御します。

計画 141

ONLINE SECONDARY インスタンスは、ONLINE インスタンスを持たないサイトに配置されます。次の表は、始動ポリシーおよびサイト間管理ポリシーに基づいて、サイト・イベント時に予想されるリソース・グループの動作を示しています。

注: 次の表に示す多くの制限は、同じネットワーク上の各ノードに複数のインターフェースがある場合にのみ適用されます。ネットワーク上の各ノードにインターフェースが 1 つしかない場合 (このような状況は、イーサチャネルや仮想イーサネットを使用しているときは一般的です)、これらの制限の多くは適用されません。

ノード始動ポリシー(サイト内で適用) サイト間管理ポリシー始動/フォールバック/フォールバック動作

ホーム・ノードのみでオンライン

1 次サイトを選択クラスター始動

1 次サイト: ホーム・ノードは、ONLINE 状態のリソース・グループを獲得します。非ホーム・ノードはリソース・グループをそのままにしておきます。

2 次サイト: このサイトで最初に結合されたノードが、ONLINE_SECONDARY

状態のリソース・グループを獲得します。

サイト間フォールオーバー ONLINE インスタンスは、ローカル・サイトにあるすべてのノードがリソース・グループを獲得できない場合に、サイト間でフォールオーバーします。可能な場合は、2 次インスタンスが他のサイトに移動し、使用可能な最も優先順位の高いノードで ONLINE SECONDARY になります。

サイト間フォールバック ONLINE インスタンスは、1 次サイトのノードが結合されたときに、1 次サイトにフォールバックします。可能な場合は、2 次インスタンスが他のサイトに移動し、使用可能な最も優先順位の高いノードでONLINE SECONDARY になります。


または



1 次サイト: 1 次サイトから最初に結合され、かつ条件に一致するノードが、ONLINE 状態のリソース・グループを獲得します。1 次サイトの他のすべてのノードではリソース・グループは OFFLINE です。

ノード配布ポリシーは、リソース・グループの 1 次インスタンスにのみ適用されることに注意してください。 2 次サイト: このサイトで最初にクラスターに結合されたノードが、始動ポリシーが設定されている ONLINE_SECONDARY

状態 (未配布) のリソース・グループのすべての 2 次インスタンスを獲得します。

サイト間フォールオーバー ONLINE インスタンスは、ローカル・サイトにあるすべてのノードがリソース・グループを獲得できない場合に、サイト間でフォールオーバーします。可能な場合は、2 次インスタンスが他のサイトに移動し、使用可能な最も優先順位の高いノードで ONLINE SECONDARY になります。

サイト間フォールバック 1 次サイトのノードが結合される時点で、ONLINE

インスタンスが 1 次サイトにフォールバックします。可能な場合は、2 次インスタンスが他のサイトに移動し、使用可能な最も優先順位の高いノードでONLINE SECONDARY になります。



使用可能なすべてのノードでオンライン


1 次サイト: すべてのノードが、ONLINE 状態のリソース・グループを獲得します。

2 次サイト: すべてのノードが、ONLINE_SECONDARY 状態のリソース・グループを獲得します。

サイト間フォールオーバー

ローカル・サイトのすべてのノードが OFFLINE になるか、またはリソース・グループを開始できない場合に、ONLINE インスタンスがサイト間でフォールオーバーします。可能な場合は、2 次インスタンスが他のサイトに移動し、ONLINE SECONDARY になります。

サイト間フォールバック

1 次サイトのノードが再結合される時点で、ONLINE インスタンスが 1 次サイトにフォールバックします。2 次サイトのノードは、ONLINE_SECONDARY

状態のリソース・グループを獲得します。

ホーム・ノードのみでオンライン

一方のサイトでオンライン

クラスター始動

いずれかのサイトからクラスターに結合されたホーム・ノードが、ONLINE 状態のリソース・グループを獲得します。非ホーム・ノードはリソース・グループを OFFLINE のままにします。

2 次サイト: 他のサイトから最初に結合されたノードが、ONLINE_SECONDARY 状態のリソース・グループを獲得します。


ONLINE インスタンスは、ローカル・サイトにあるすべてのノードがリソース・グループを獲得できない場合に、サイト間でフォールオーバーします。可能な場合は、2 次インスタンスが他のサイトに移動し、使用可能な最も優先順位の高いノードで ONLINE SECONDARY になります。


ONLINE インスタンスは、1 次サイトのノードが再結合されるときに 1 次サイトにフォールバックしません。最も優先順位の高い再結合ノードが、ONLINE_SECONDARY 状態のリソース・グループを獲得します。

計画 143



または




いずれかのサイトから最初に結合されたノードで、配布条件に一致するものが、ONLINE 状態のリソース・グループを獲得します。

2 次サイト: リソース・グループが ONLINE になると、他のサイトから最初に結合されたノードが、ONLINE_SECONDARY 状態のリソース・グループを獲得します。


ONLINE インスタンスは、ローカル・サイトにあるすべてのノードがリソース・グループを獲得できない場合に、サイト間でフォールオーバーします。


ONLINE インスタンスは、1 次サイトが結合されるときに 1 次サイトにフォールバックしません。再結合ノードは、ONLINE_SECONDARY 状態のリソース・グループを獲得します。




いずれかのサイトから最初に結合されたノードが、ONLINE 状態のリソース・グループを獲得します。グループのインスタンスがアクティブになると、同じサイトの残りのノードも ONLINE 状態のグループを活動化します。

2 次サイト: すべてのノードが、ONLINE_SECONDARY 状態のリソース・グループを獲得します。


ローカル・サイトにあるすべてのノードが OFFLINE になるか、またはリソース・グループを始動できない場合、ONLINE インスタンスはサイト間でフォールオーバーします。


ONLINE インスタンスは、1 次サイトが結合されるときに 1 次サイトにフォールバックしません。再結合ノードは、ONLINE_SECONDARY 状態のリソース・グループを獲得します。


両方のサイトでオンライン


すべてのノードは、ONLINE 状態のリソース・グループをアクティブにします。


フォールオーバーは行われません。リソース・グループは、OFFLINE またはERROR 状態になります。


フォールバックは行われません。

サイト間リソース・グループ回復のカスタマイズHACMP の新規インストールでは、サイト間リソース・グループの回復は、デフォルトで使用可能です。


HACMP バージョン 5.3 未満のリリースから HACMP にアップグレードした場合、サイト間でのリソース・グループのフォールオーバーは、デフォルトでは無効になっています。この動作は、以前のリリースの「Ignore (無視)」以外のサイト管理ポリシーにおけるデフォルトでした。リソース・グループの特定のインスタンスが 1 つのサイト内でフォールオーバーすることはありますが、サイト間を移動することはありません。該当するインスタンスがあるサイト上で使用可能なノードがない場合、このインスタンスの状態はERROR または ERROR_SECONDARY になります。インスタンスは、失敗したノード上にはとどまりません。この動作は 1 次インスタンスと 2 次インスタンスの両方で発生します。

node_down イベントまたは node_up イベントが発生した場合、サイト間のフォールオーバーが無効になっていても、クラスター・マネージャーはリソース・グループを移動します。サイト間でリソース・グループを手動で移動することができます。

サイト間のフォールオーバーの有効化または無効化

以前のリリースの HACMP から移行した場合は、リソース・グループ回復ポリシーを変更して、クラスター・マネージャーがリソース・グループを他のサイトに移動できるようにすることで、リソース・グループが ERROR 状態になることを防止できます。

サイト間での複製リソース・グループの 1 次インスタンスの回復

サイト間のフォールオーバーを使用可能にすると、サイト間ネットワークに接続しているインターフェースで障害が発生するか、またはこのインターフェースが使用可能になった場合に、HACMP はリソース・グループの 1 次インスタンスを回復しようとします。

サイト間での複製リソース・グループの 2 次インスタンスの回復

サイト間のフォールオーバーを使用可能にすると、以下の状況で、HACMP はリソース・グループの 1 次インスタンスと 2 次インスタンスを回復しようとします。

v リソース・グループの 2 次インスタンスの獲得中に獲得が失敗した場合、クラスター・マネージャーは、リソース・グループの 1 次インスタンスと同様に 2 次インスタンスを回復しようとします。獲得に使用できるノードがない場合は、リソース・グループの 2 次インスタンスは、グローバルERROR_SECONDARY の状態になります。

v クォーラム損失が発生し、その影響を受けるノードでリソース・グループの 2 次インスタンスがオンラインである場合、HACMP は他の使用可能なノードで 2 次インスタンスを回復しようとします。

v すべての XD_data ネットワークで障害が起きる場合、HACMP は GLVM リソース付きのすべてのONLINE リソース・グループを、そのサイトの別の使用可能なノードに移動します。 2 次インスタンスが選択フォールオーバーで回復できるよう、1 次インスタンスのこの機能が 2 次インスタンスにミラーリングされます。

SMIT を使用したサイト間リソース・グループ回復の有効化または無効化

サイト間のリソース・グループ回復を使用可能/使用不可にするには、HACMP SMIT のパス (「ExtendedConfiguration (拡張構成) > Extended Resource Configuration (拡張リソース構成) > HACMP ExtendedResources Configuration (HACMP 拡張リソース構成) > Customize Resource Group and ResourceRecovery (リソース・グループ回復とリソース回復のカスタマイズ) > Customize Inter-site ResourceGroup Recovery (サイト間リソース・グループ回復のカスタマイズ)」) を使用してください。

計画 145

複製リソースの計画HACMP では、複製リソースの構成と処理が向上し、複製リソースのサポートが強化されました。

HACMP では、以下の作業を実行できます。

v HACMP/XD および HACMP サイト構成で複製リソースを含むリソース・グループを動的に再構成できます。

v インストールされている XD 製品の検証ユーティリティーを自動的に検出して呼び出し、HACMP/XD

の検証を標準のクラスター検証に統合します。

関連資料:


複製リソースの構成HACMP/XD 製品をインストールした場合は、いくつかの異なる構成がサポートされます。

これらの構成には、以下のものがあります。

v コンカレント・ノード・ポリシーが設定されたリソース・グループに、非コンカレント・サイト管理ポリシーを設定できます。

v HACMP の新規インストールでは、HACMP/XD 複製リソースが含まれているリソース・グループのサイト間回復がデフォルトで許可されています。以前のリリースからアップグレードおよび移行した構成では、既存の動作が維持されます。この動作を、クラスターによって開始されるリソース・グループ移動で「fallover (フォールオーバー)」または「notify (通知)」になるように構成できます。「notify (通知)」オプションを選択する場合は、イベント前処理スクリプトまたはイベント後処理スクリプト、あるいはリモート通知メソッドを構成する必要があります。

v 複製リソース・グループでの親/子依存関係およびロケーション依存関係の構成

v HACMP サイトを持つリソース・グループに対するノード・ベースのリソース・グループ配布始動ポリシー(ネットワーク・ベースのリソース・グループの配布は、使用可能なオプションではなくなりました)

リソース・グループが非コンカレント・ノード・ポリシーとコンカレント・サイト間管理ポリシーを使用するように構成することはできません。

注: Metro Mirror、または GLVM のリソースとリソース・グループの構成についての詳細は、『HACMP/XD の資料』を参照してください。

複製リソースの処理HACMP には、複製リソースを処理するための機能が用意されています。

この機能では、以下のことが行われます。

v デフォルトでは、HACMP は可能な限りイベントを並列で処理します。イベントは動的かつ段階的に実行されるので、HACMP は、リソース・グループの 1 次インスタンスおよび 2 次インスタンスを適切な順序 (release_primary、release_secondary、acquire_secondary、acquire_primary) で処理します。

v 現行の HACMP は、他のノードやネットワークが使用可能な場合でも、ボリューム・グループの損失、獲得の失敗、および local_network_down イベントの発生時に、複製リソース・グループの 2 次インスタンス (および 1 次インスタンス) を回復します。


v HACMP は、サイトのフォールオーバーでリソース・グループの 2 次インスタンスを獲得しやすくなりました。1 次インスタンスをホストしていたノードのみがターゲットとして見なされていた以前のバージョンの HACMP とは異なり、現行の HACMP では、2 次サイトのすべてのノードがターゲットとして見なされます。

関連資料:


関連情報:

HACMP/XD の資料

複製リソースが含まれているリソース・グループの移動複製リソースが含まれているリソース・グループの 1 次インスタンスを別のサイトに移動できます。

クラスター・マネージャーは動的なイベント・フェーズ処理を使用し、他のサイトで 2 次インスタンスをホストできるノードがある場合には、最初に 2 次インスタンスをそのサイトに移動します。2 次インスタンスを SECONDARY ONLINE の状態に維持するよう試行されます。特定のサイトのノードが複数の 1 次インスタンスをホストできないように構成されている場合でも、すべての 2 次インスタンスをSECONDARY ONLINE として維持するために、ノードで複数の 2 次インスタンスがホストされます。

ノード始動時のリソース・グループの回復従来、ノードは、クラスターに結合されたときに、他のノード上で以前に ERROR 状態になったリソース・グループを取得しようとしませんでした。このようなリソース・グループは ERROR 状態のままであるため、リソース・グループ管理ユーティリティー clRGmove を使用して手動でオンラインに戻す必要がありました。

ただし、HACMP では、リソース・グループの回復が強化されました。現在 ERROR 状態になっているリソース・グループを自動的にオンラインに戻す操作が試行されます。これにより、アプリケーションがオンラインに戻される可能性も高くなります。リソース・グループがクラスター内のいずれかのノード上でERROR 状態にある場合、そのノードは node_up イベント時にそのリソース・グループを獲得しようとします。ノードはリソース・グループのノード・リストに含まれている必要があります。

ノード始動時のリソース・グループの回復は、非コンカレント・リソース・グループの場合とコンカレント・リソース・グループの場合とで異なります。

v 始動するノードが、ERROR 状態にある非コンカレント・リソース・グループの活動化に失敗すると、そのリソース・グループは引き続きノード・リスト内の別のノードに (ノードが使用可能な場合) フォールオーバーします。フォールオーバー・アクションは、ノード・リスト内の使用可能なすべてのノードが試されるまで続行します。すべてのノードを試してもリソース・グループが獲得されなかった場合、そのリソース・グループは ERROR 状態になります。

v 始動するノードが ERROR 状態にあるコンカレント・リソース・グループの活動化に失敗すると、そのコンカレント・リソース・グループは ERROR 状態のままになります。

ワークロード・マネージャーの計画IBM は、AIX ワークロード・マネージャー (WLM) を AIX 4.3.3 以上に付属のシステム管理リソースとして提供しています。

計画 147

http://www.ibm.com/servers/eserver/pseries/library/hacmp_docs.html

WLM により、ユーザーは、各種のプロセスおよびアプリケーションについて、CPU、物理メモリー使用量、およびディスク入出力帯域幅の制限およびターゲットを設定できます。これによりピーク・ロード時の重要システム・リソースの使用の制御が向上します。HACMP では、WLM クラスを HACMP リソース・グループとして構成できるため、WLM の始動と停止やアクティブな WLM の構成をクラスターで制御できます。

HACMP は、WLM 構成のすべての側面を検証するわけではありません。したがって、WLM 構成ファイルの整合性については、ユーザー側で確認する必要があります。WLM クラスを HACMP のリソース・グループに追加した後、検証ユーティリティーは、必要な WLM クラスが存在するかどうかのみを確認します。したがって、WLM の機能について十分に理解し、慎重に WLM を構成する必要があります。正しい構成パラメーターでも、誤って使用すると、システムの生産性と可用性が低下する恐れがあります。

ワークロード・マネージャーの設定および使用方法の詳細については、IBM Redbook「AIX Workload

Manager (WLM)」を参照してください。

ワークロード・マネージャーは、プロセスが属するクラスに従って、システム・リソースを要求するプロセス間でシステム・リソースを配布します。プロセスは、クラス割り当て規則に従って特定のクラスに割り当てられます。WLM を HACMP に統合するには、次の 2 つの基本ステップを実行する必要があります。

1. AIX SMIT パネルを使用して、高可用性アプリケーションに関連する WLM クラスとクラス割り当て規則を定義します。

2. HACMP SMIT パネルを使用して、WLM 構成と HACMP リソース・グループとの間の関連付けを作成します。

関連情報:

AIX Workload Manager (WLM)

ワークロード・マネージャークラスについてワークロード・マネージャーは、プロセスから要求があれば、そのプロセスが割り当てられているクラスに従って、プロセスにシステム・リソースを配布します。

クラスのプロパティーには、次のものが含まれます。

v クラスの名前。16 文字以下の固有の英数字文字列です。

v クラス層。0 から 9 の数字。この数字は、クラスの相対的な重要度を判別します。最も重要度が高いのは層 0 で、最も重要度が低いのは層 9 です。

v CPU および物理メモリーの「共用」数。各クラスに割り当てられるリソースの実際の総数は、すべてのクラス内の共用の総数によって決まります (したがって、システムに 2 つのクラスが定義されており、一方のクラスのターゲット CPU 使用量の共用数が 2、もう一方のクラスの共用数が 3 の場合は、1 番目のクラスが CPU 時間の 2/5、2 番目のクラスが 3/5 を受け取ります)。

v 構成の制限。プロセスが使用可能な CPU 時間、物理メモリー、およびディスク入出力帯域幅の最小値と最大値 (パーセント)。

(WLM 始動時にすでに実行されているプロセスだけではなく) すべての新しいプロセスを gid、uid、および絶対パス名に従って分類する方法を WLM に通知するために、クラス割り当て規則を設定します。

ワークロード・マネージャーの再構成、始動、およびシャットダウンこのセクションでは、WLM を HACMP の制御下に置いた後での WLM を再構成、始動、または停止方法について説明します。


http://www.redbooks.ibm.com/abstracts/sg245977.html

ワークロード・マネージャーの再構成

WLM クラスが HACMP リソース・グループに追加された後、ノード上でのクラスターの同期化時に、HACMP が WLM を再構成して、そのノードに関連付けられているクラスで必要な規則を WLM が使用するようにします。ノード上での動的リソース再構成イベントでは、リソース・グループに関連付けられている WLM クラスへの変更に従って WLM が再構成されます。

ワークロード・マネージャーの始動

WLM は、ノードがクラスターに結合した際、または WLM 構成の動的再構成が行われた際に始動します。

構成はノード固有であり、そのノードが参加しているリソース・グループによって異なります。WLM クラスに関連したリソース・グループをノードが獲得できない場合、WLM は始動されません。

「Online Using Node Distribution Policy (ノード配布ポリシーを使用してオンライン)」始動ポリシーが設定されていないすべての非コンカレント・リソース・グループについては、起動スクリプトによって、そのリソース・グループが 1 次ノードと 2 次ノードのどちらで実行されているのかが特定されて、対応するWLM クラス割り当て規則が WLM 構成に追加されます。ノードが獲得可能なその他のすべての非コンカレント・リソース・グループとコンカレント・アクセス・リソース・グループに対して、各リソース・グループに関連付けられている 1 次 WLM クラスが WLM 構成に配置され、対応する規則が規則表に追加されます。

最後に、WLM が現在実行中であるが、HACMP 以外によって始動された場合、起動スクリプトはユーザー指定の構成から WLM を再始動して、前の構成を保管します。HACMP が停止すると、WLM は前の構成に戻されます。

WLM の始動に失敗すると、エラー・メッセージが生成されて hacmp.out ログ・ファイルに記録されますが、ノードの始動とリソースの再構成は続行されます。

ワークロード・マネージャーのシャットダウン

WLM は、ノードがクラスターから分離した際、またはクラスターの動的再構成時にシャットダウンされます。WLM が現在実行中の場合、シャットダウン・スクリプトは、WLM が HACMP によって始動される前にすでに実行中であったかどうか、および WLM がどのような構成を使用していたのかを確認します。その後、シャットダウン・スクリプトは、何もしない (WLM が現在実行中ではない場合) か、WLM を停止する (HACMP による始動前に WLM が実行されていなかった場合) か、または WLM を停止してから前の構成で再始動 (WLM が前に実行中であった場合) します。

制限と考慮事項ワークロード・マネージャー構成を計画する際は、いくつかの制限と考慮事項に注意してください。

これらの制限と考慮事項には、以下のものがあります。

v 一部の WLM 構成は HACMP のパフォーマンスを低下させることがあります。クラスと規則は慎重に設計し、それらが HACMP に及ぼす影響についても注意してください。

v クラスター全体で所有できる非デフォルトの WLM クラスは 27 個までです。これは、1 つの構成がクラスター・ノード全体で共用されているためです。

計画 149

v WLM ではサブクラスを使用できますが、HACMP のワークロード・マネージャー構成ではサブクラスはサポートされていません。リソース・グループ内に配置された WLM クラスのサブクラスを構成する場合は、クラスター検証時に警告が出され、同期化の際にこのサブクラスは他のノードに伝搬されません。

v どのノードにおいても、そのノード上でアクティブになる規則は、ノードが獲得可能なリソース・グループに関連付けられているクラスの規則のみです。

WLM クラスの HACMP リソース・グループへの割り当て以前に構成された WLM クラスをクラスター・リソース・グループに割り当てる方法を計画する場合と同様、最初に各リソース・グループに関して、リソース・グループ・ワークシートの「Primary WorkloadManager Class (1 次ワークロード・マネージャー・クラス)」および「Secondary Workload ManagerClass (2 次ワークロード・マネージャー・クラス)」フィールドに記入します。

WLM クラスをリソース・グループ内のリソースとして追加する手順については、『ワークロード・マネージャーの構成』を参照してください。

関連タスク:

『リソース・グループ・ワークシートの記入』リソース・グループ・ワークシートはクラスターのリソース・グループを計画する際に役立ちます。リソース・グループごとに 1 枚のワークシートに記入します。

リソース・グループ・ワークシートの記入リソース・グループ・ワークシートはクラスターのリソース・グループを計画する際に役立ちます。リソース・グループごとに 1 枚のワークシートに記入します。

注: ロケーション依存関係とリソース・グループの動作の例については、『クラスター・イベント時のリソース・グループの動作』を参照してください。

プランニング・ワークシートには、リソース・グループ・ワークシートの空のコピーが含まれています。ワークシートをコピーして構成情報を記録してください。

リソース・グループ・ワークシートに記入するには、次の手順を実行します。

1. 「Cluster Name (クラスター名)」フィールドにクラスター名を記録します。この値は、最初に『クラスターの初期計画』で割り当てた値です。

2. リソース・グループに名前を割り当て、「Resource Group Name (リソース・グループ名)」フィールドに記録します。32 文字以内で指定してください。英字、数字、および下線を使用できますが、先頭には数字を使用しないでください。重複エントリーは許可されません。

3. このリソース・グループのリソース・グループ・ノード・リストにメンバーとして加えたいノードの名前を「Participating Nodes/Default Node Priority (参加ノード名/デフォルトのノード優先順位)」フィールドに記録します。優先順位の高い順にノード名を列記します (これは、コンカレント・リソース・グループには適用されません)。

4. (オプション) サイト間管理ポリシーを記録します。この項目は、拡張構成パスを使用している場合にのみ使用できます。HACMP/XD をインストールする場合を除き、通常、複数サイトを使用するクラスター構成のセットアップは行われません。 HACMP/XD をインストールしている場合は、サイト操作を処理する適切なメソッドまたはカスタマイズが提供されない限り、「Inter-Site Management Policy(サイト間管理ポリシー)」フィールドには「Ignore (無視)」を記入します。

Ignore (無視) (デフォルト)。クラスターでサイトが使用されない場合には、このオプションを使用します。このオプションは、XD/Metro Mirror 構成でも使用できます。


Prefer Primary Site (1 次サイトを選択)。リソース・グループの 1 次インスタンスはこのサイトのノード上で ONLINE になり、フォールオーバー後にクラスターに再結合するときに、このサイトにフォールバックします。2 次インスタンスは他のサイトで保持されます。

Online on Either Site (一方のサイトでオンライン)。リソース・グループ・ノード・ポリシーにより、リソース・グループの 1 次インスタンスが始動、フォールオーバー、フォールバックする場所が決定されます。2 次インスタンスは他のサイトで保持されます。

Online on Both Sites (両方のサイトでオンライン)。すべてのサイトから複製リソースにアクセスできるようにする場合は、このオプションを選択します。サイト関係が「Online on Both Sites (両方のサイトでオンライン)」の場合、ノード・ポリシーは、「Available on All Nodes (すべてのノードで使用可能)」になります。

5. 始動ポリシー、フォールオーバー・ポリシー、およびフォールバック・ポリシーを指定します。

6. (オプション) 遅延フォールバック・タイマーおよび整定時間も指定できます。

これらの設定について詳しくは、セクション『始動、フォールオーバー、およびフォールバックのリソース・グループ・ポリシー』を参照してください。

7. (オプション) リソース・グループのランタイム・ポリシーを記録します。ランタイム・ポリシーは拡張構成パスでのみ使用できます。ランタイム・ポリシーには以下のものが含まれます。

v 動的ノード優先順位ポリシー

v リソース・グループ間の依存関係

v ワークロード・マネージャー

v リソース・グループ処理順序

8. (オプション) このリソース・グループで使用する動的ノード優先順位ポリシーを記録します(このフィールドは、「Extended Configuration (拡張構成)」パスの「Change/Show a Resource/Attribute (リソース/属性の変更/表示)」フィールドに表示されます。) デフォルトはブランクです。デフォルト・ポリシーは順次ノード・リストです。コンカレント・リソース・グループの場合は、これが唯一選択できる項目です。動的ノード優先順位ポリシーを使用するには、事前定義された動的ノード優先順位ポリシーのいずれかを選択します。

9. (オプション) このリソース・グループで使用する依存関係 (親/子またはロケーション) を記録します。この構成についてガイドラインを確認するには、『リソース・グループ依存関係』の当該セクションを参照してください。

10. (オプション) リソース・グループの処理順序を記録します。「Processing Order: Parallel, Customizedor Serial (処理順序: 「並列」、「ユーザー定義」または「順次」)」フィールドで、HACMP がこのリソース・グループの獲得および解放を同時に行う (デフォルト) か、順次行うかを指定します。

詳しくは、『リソース・グループの並列処理順序または順次処理順序の計画』を参照してください。

11. リソース・グループに含めるリソースをリストします。このリソースは、前のセクションで指定したものです。このセクションでは、リソース・グループ・ワークシートに次のリソース/属性を記録します。

v クラスターで IP アドレス・テークオーバーが使用されている場合は、「Service IP Label (サービス IP ラベル)」フィールドに値を入力します。

v このフィールドは、非コンカレント・リソース・グループにのみ関連します。デフォルトで、指定したボリューム・グループに含まれるすべてのファイルシステムを、このボリューム・グループを含むリソース・グループがオンラインになったときにマウントする場合は、「Filesystems (default isAll) (ファイルシステム (デフォルトは「すべて」))」フィールドを空のままにします。

計画 151

注: 「Filesystems (default is All) (ファイルシステム (デフォルトは「すべて」))」フィールドを空白のままにし、かつ「Volume Groups (ボリューム・グループ)」フィールドで共用ボリューム・グループを指定すると、そのボリューム・グループ内のすべてのファイルシステムがマウントされます。「Filesystems (ファイルシステム)」フィールドを空白のままにし、「Volume Groups (ボリューム・グループ)」フィールドでボリューム・グループを指定しなかった場合は、どのファイルシステムもマウントされません。

このリソース・グループに含める個々のファイルシステムを「Filesystems (default is All) (ファイルシステム (デフォルトは「すべて」))」フィールドに列記します。この場合、リソース・グループがオンラインになったとき、指定されたファイルシステムだけがマウントされます。

v 「Filesystems Consistency Check (ファイルシステムの整合性検査)」フィールドで「fsck」または「logredo」を指定します。「logredo」を選択した場合、logredo が失敗すると、代わりに fsck が実行されます。

v 「Filesystems Recovery Method (ファイルシステムの回復メソッド)」フィールドで「parallel (並列)」または「sequential (順次)」を指定します。

v 「Filesystems to Export (NFSv2/3) (エクスポートするファイルシステム (NFSv2/3))」フィールドに、ファイルシステムのマウント・ポイント、またはリソース・グループを最初に獲得するときにNFSv2/3 プロトコルを使って、リソース・グループのノード・リスト内のすべてのノードにエクスポートするディレクトリーのいずれか、または両方を記入します。

v 「Filesystems to Export (NFSv4) (エクスポートするファイルシステム (NFSv4))」フィールドに、ファイルシステムのマウント・ポイント、またはリソース・グループを最初に獲得するときに NFSv4

プロトコルを使って、リソース・グループのノード・リスト内のすべてのノードにエクスポートするディレクトリーのいずれか、または両方を記入します。ファイルシステムは、「Filesystems to

Export (NFSv2/3) (エクスポートするファイルシステム (NFSv2/3))」と「Filesystems to Export

(NFSv4) (エクスポートするファイルシステム (NFSv4))」フィールドの両方に記入することが可能です。このシナリオでは、ファイルシステムまたはディレクトリーは NFSv2/3 および NFSv4 プロトコルを使用してエクスポートされます。

v 「Stable Storage Path (NFSv4) (安定ストレージのパス (NFSv4))」フィールドに、NFSv4 サーバーが状況情報を保存するパスを指定してください。

v 現在リソースを保持していないリソース・グループのノード・リスト内のノードによって NFS マウントされる必要のあるファイルシステムを、「Filesystems to NFS Mount (NFS マウントするファイルシステムまたはディレクトリー)」フィールドに列記します。現在リソースを保持していないリソース・グループのノード・リスト内のノードはすべて、これらのファイルシステムを NFS マウントしようとします。

v 「Network for NFS Mount (NFS マウント用ネットワーク)」フィールドに、指定されたファイルシステムを NFS マウントするネットワークを記入します。

v 「Volume Groups (ボリューム・グループ)」フィールドに、リソースを最初に獲得するときにオンに変更されるロー論理ボリュームまたはロー・ボリューム・グループを含むボリューム・グループの名前をリストします。

「Filesystems (default is All) (ファイルシステム (デフォルトは「すべて」))」フィールドを空白のままにし、かつボリューム・グループにあるすべてのファイルシステムをマウントする場合は、「Volume Groups (ボリューム・グループ)」フィールドに共用ボリューム・グループを指定します。このフィールドに複数のボリューム・グループを指定した場合は、これらのうちの特定のボリューム・グループ内のすべてのファイルシステムをマウントしつつ、別のボリューム・グループ内のファイルシステムをマウントしないように選択することはできません。すなわち、指定されたすべてのボリューム・グループ内のすべてのファイルシステムがマウントされます。


例えば、vg1 および vg2 の 2 つのボリューム・グループを持つリソース・グループで、「Filesystems (default is All) (ファイルシステム (デフォルトは「すべて」))」を空のままにすると、リソース・グループがオンラインになったときに、vg1 および vg2 にあるすべてのファイルシステムがマウントされます。ただし、「Filesystems (default is All) (ファイルシステム (デフォルトは「すべて」))」に vg1 ボリューム・グループに含まれるファイルシステムだけが指定されている場合は、vg2 内のどのファイルシステムもマウントされません。これは、vg2 のファイルシステムが、「Filesystems (default is All) (ファイルシステム (デフォルトは「すべて」))」フィールドにvg1 のファイルシステムとともに入力されていないためです。

ロー論理ボリュームを使用する場合、それをリソース・グループに含めるには、ロー論理ボリュームが存在しているボリューム・グループを指定するだけでかまいません。

v 「Concurrent Volume Groups (コンカレント・ボリューム・グループ)」フィールドに、所有者ノードによりオンに変更されるコンカレント・ボリューム・グループの名前を記入します。

v ロー・ディスクに直接アクセスするアプリケーションの使用を計画する場合、ロー・ディスクの物理ボリューム ID を「Raw Disk PVIDs (ロー・ディスク PVID」フィールドにリストします。

v Fast Connect サービスを使用する場合は、「Fast Connect Services (Fast Connect サービス)」フィールドにリソースを定義します。

v テープ・リソースを使用する場合は、「Tape Resources (テープ・リソース)」フィールドにテープ・リソースの名前を入力します。

v リソース・グループに組み込むアプリケーション・サーバーの名前を「Application Servers (アプリケーション・サーバー)」フィールドにリストします。

v SNA-over-LAN、SNA-over-X.25、または X.25 の通信リンクをリストします。

v 「Primary Workload Manager Class (1 次ワークロード・マネージャー・クラス)」および「Secondary Workload Manager Class (2 次ワークロード・マネージャー・クラス)」フィールドに、このリソース・グループに追加する HACMP WLM 構成に関連するクラスの名前を入力します。

「Online Using Node Distribution Policy (ノード配布ポリシーを使用してオンライン)」始動ポリシーが設定されていない非コンカレント・リソース・グループでは、2 次 WLM クラスが指定されていない場合、すべてのノードが 1 次 WLM クラスを使用します。2 次クラスも指定すると、1 次ノードのみが 1 次 WLM クラスを使用します。始動ポリシーが「Online Using Node Distribution

Policy (ノード配布ポリシーを使用してオンライン)」の非コンカレント・リソース・グループとコンカレント・リソース・グループには、2 次クラスを割り当てることはできません。これらのリソース・グループ・タイプの場合、リソース・グループ内のノードはすべて、1 次 WLM クラスを使用します。

注: WLM クラスをリソース・グループに追加する前に、WLM 構成を「Change/Show HACMPWLM runtime Parameters (HACMP ワークロード・マネージャーの実行時パラメーターの変更/表示)」SMIT パネルに指定します。1 次/2 次 WLM クラスのピック・リストには、指定した WLM

構成用に定義されたクラスが表示されます。

v 「Miscellaneous Data (その他のデータ)」は、リソース・グループ情報とともに環境に組み込まれ、スクリプトからアクセスできる文字列です。

v 「Automatically Import Volume Groups (ボリューム・グループを自動的にインポートする)」フィールドは、デフォルトで「false (いいえ)」に設定されます。「インポートに使用可能なボリューム・グループ」の定義は、「Discover Current Volume Group (現行ボリューム・グループ構成のディスカバー)」メニューから最後に情報が収集された際に作成されたファイルからここに表示されます。ボリューム・グループ情報の更新は、自動的に実行されません。

計画 153

「true (はい)」にリセットすると、「Volume Groups (ボリューム・グループ)」フィールドまたは「Concurrent Volume Groups (コンカレント・ボリューム・グループ)」フィールドに入力されたボリューム・グループの定義が、まだその定義を持っていないリソース・グループ・ノードにインポートされます。

「Automatically Import Volume Groups (ボリューム・グループの自動インポート)」を「true (はい)」に設定すると、ボリューム・グループの最終状態は、ボリューム・グループの初期状態(varyon または varyoff) と、ボリューム・グループが追加されるリソース・グループの状態 (オンラインまたはオフライン) に基づいて決定されます。

v 「Disk Fencing Activated (ディスク・フェンシングをアクティブにする)」フィールドを「true (はい)」に設定して、リソース・グループ内のディスクの SSA ディスク・フェンシングをアクティブにします。使用不可にする場合は、「false (いいえ)」に設定します。 SSA ディスク・フェンシングを使用すると、リソースの不適切なテークオーバーが、区分クラスターによって実行されないようになります。

v 「Filesystems Mounted before IP Configured (IP 構成の前にファイルシステムをマウントする)」。 HACMP では、障害ノードの IP アドレスをテークオーバーし、次にそのファイルシステムをテークオーバーして、ノードの障害に対処します。これは「ファイルまたはファイルシステムがない」という旨のエラーが NFS クライアントで発生する原因となります。これは、クライアントは、ファイルシステムが使用可能になる前に、バックアップ・サーバーと通信できるためです。「true (はい)」に設定すると、IP アドレスをテークオーバーする前にファイルシステムをテークオーバーするので、このエラーを防止できます。デフォルトの順序を保持する場合は、「false (いいえ)」に設定します。

関連資料:


138ページの『リソース・グループの並列処理順序または順次処理順序の計画』デフォルトでは、HACMP はクラスター内で構成されているすべての個別リソースを同時に獲得および解放します。ただし、個々のリソース・グループの一部またはすべてを獲得、解放する順次処理の順序を指定できます。

227ページの『リソース・グループ・ワークシート』このワークシートは、クラスターのリソース・グループを記録するために使用します。


126ページの『始動、フォールオーバー、およびフォールバックのリソース・グループ・ポリシー』リソース・グループの動作は、次の 3 種類のノード・ポリシーに分類されます。

クラスター・イベントの計画このトピックでは、HACMP クラスター・イベントについて説明します。

前提条件

以下に示す前出のセクションの計画ステップを完了している必要があります。


概説

HACMP でのイベント処理の管理には次の 2 つの方法があります。

v 定義済みイベントのカスタマイズ

v 新しいイベントの定義

HACMP では、クラスター内のすべてまたは一部のリソース・グループにカスタマイズした順序処理の順序を指定しない限り、リソース・グループは可能な場合、デフォルトで並列処理されます。

例で説明しているイベントのロジックおよび順序には、すべてのイベントがリストされているわけではありません。

以下の項目については、『クラスター・サービスの開始および停止』を参照してください。

v クラスター・サービスを始動および停止するための手順

v AIX の shutdown コマンドの操作、および HACMP クラスター・サービスと RSCT の相互作用

サイトおよびノード・イベントの計画HACMP/XD がインストールされているか、サイト間ミラーリングを使用している場合を除いて、サイトの定義はオプションです。HACMP/XD には HACMP/XD for Metro Mirror または HACMP/XD for GLVM

のいずれかが組み込まれています。いずれの機能も複製されたリソース用にサイトを使用します。

サイト・イベント・スクリプトは、HACMP ソフトウェアに組み込まれています。サイトが定義されていない場合は、サイト・イベントは生成されません。サイトが定義されている場合、HACMP site_event スクリプトは次のように実行されます。

v サイト内の最初のノードが、site_up を実行して、その後に node_up イベント処理を完了します。site_up_complete イベントは node_up_complete の後に実行します。

v サイト内の最終ノードが停止すると、node_down イベントの前に site_down が実行され、node_down_complete の後に site_down_complete が実行されます。

HACMP/XD をインストールしていい場合でも、サイトの状態が変化した際に実行する前処理イベントと後処理イベントを定義できます。この場合、サイトに関連するすべてのプロセスを定義します。

サイト・イベント (check_for_site_up および check_for_site_down を含む) は、hacmp.out ログ・ファイルに記録されます。その他のサイト・イベント (site_isolation や site_merge など) は、サイトのあるクラスターで発生する場合があります。HACMP はイベント・スクリプトを実行しません。また、これらのイベントのために他のイベントが開始されることもありません。これらのイベントについては、サイトに合わせてアクションをカスタマイズする必要があります。

サイトが定義されている場合、サイトの最初のノードが起動したときに site_up が、またサイトの最終ノードが停止したときに site_down が、それぞれ実行されます。リソース・グループを処理するために実行されるイベント・スクリプトの一般的な順序は次の通りです。

site_upsite_up_remote

node_uprg_move イベントでリソース・グループのアクションを処理

node_up_complete

計画 155

site_up_completesite_up_remote_complete

―――――――――――――――――――

site_downsite_down_remote

node_downrg_move イベントでリソース・グループのアクションを処理

node_down_complete

site_downsite_down_remote_complete

node_up および node_down イベントの順序node_up イベントは、クラスターの起動時にクラスターに結合されるノードによって開始されます。また、後でクラスターに再結合した場合にも開始されます。

初期クラスター・メンバーシップの設定このセクションでは、クラスターが始動してクラスターの初期メンバーシップが設定される際に、各ノードでクラスター・マネージャーが実行するステップについて説明します。クラスター・マネージャーがメンバー・ノード間の通信をどのように確立するか、またクラスターのメンバーシップが増えるにつれて、クラスター・リソースがどのように分配されるかについて説明します。

最初のノードがクラスターに結合

1. HACMP クラスター・サービスは、ノード A で始動します。RSCT サブシステムは、ネットワーク・インターフェースの状態を調べて、他のクラスター・ノード上の RSCT サブシステムとの通信を開始します。ノード A のクラスター・マネージャーは、初期状態情報を累積した後、接続しているすべての構成済みネットワークでクラスターに結合できる状態であるという旨のメッセージをブロードキャストします (node_up)。

2. ノード A は、応答がないことを、そのノードがクラスター内の最初のノードであることを意味する、と解釈します。

3. その後、ノード A は process_resources スクリプトを開始して、ノードのリソース構成情報を処理します。

4. イベント処理が完了すると、ノード A はクラスターのメンバーになります。HACMP はnode_up_complete を実行します。

ノード A について定義されたすべてのリソース・グループは、この時点ではクライアントにとって使用可能です。

リソース・グループの始動時の動作として、「Online on First Available Node (最初に使用可能なノードでオンライン)」が指定されている場合、ノード A はこれらすべてのリソース・グループを制御します。

ノード A が「Online Using Node Distribution Policy (ノード配信ポリシーを使用してオンライン)」で始動する非コンカレント・リソース・グループの一部として定義されている場合、このノードは、ノード環境にリストされる最初のリソース・グループを制御します。


ノード A がコンカレント・アクセス・リソース構成の一部として定義されている場合、ノード A はそれらのコンカレント・リソースを使用可能にします。

「Online on First Available Node (最初に使用可能なノードでオンライン)」始動ポリシーと整定時間が構成されているリソース・グループでは、ノード A は整定時間間隔が経過してからこのリソース・グループを獲得します。整定時間を設定することにより、優先順位の高いノードがクラスターに結合されるまで待機できるようになります。

2 番目のノードがクラスターに結合

5. HACMP クラスター・サービスがノード B で始動します。ノード B は、接続しているすべての構成済みネットワークでクラスターに結合できる状態であるという旨のメッセージをブロードキャストします (node_up)。

6. ノード A は、このメッセージを受信し、肯定応答を送信します。

7. ノード A はノード B をアクティブ・ノードのリストに追加して、ノード B とのキープアライブ通信を開始します。

8. ノード B は、肯定応答をノード A から受信します。このメッセージには、ノード A がクラスター内で他に存在する唯一のメンバーであることを示す情報が入っています。(他にメンバーがいる場合、ノード B はメンバーのリストを受信します。)

9. ノード B は process_resources スクリプトを処理し、完了時には他のノードにメッセージを送信して通知します。

ノード A とノード B の両方が 1 つ以上のリソース・グループのノード・リストにあって、その内 1

つ以上のリソースに対してノード B がより高い優先順位を持っている場合、process_resources スクリプトを処理すると、ノード A が現在獲得しているリソースが解放される場合があります。これは、フォールバックをサポートするリソース・グループについてのみ該当します。

遅延フォールバック・タイマーが構成されている場合、ノード A でオンラインでありノード B がより高い優先順位を持つリソース・グループは遅延フォールバック・タイマーによって指定した時刻にノード B にフォールバックされます。

10. 一方、ノード B は、モニターとキープアライブ・メッセージの送信を実行し続け、クラスター・メンバーシップの変更に関するメッセージを受信するまで待機しています。ノード B は、自ノードのprocess_resources スクリプトを完了すると、ノード A に通知します。

node_up の処理中、ノード B は自身に構成されているすべてのリソース・グループを要求します (ステップ 3 を参照してください)。遅延フォールバック・タイマーが構成されている場合、リソース・グループは遅延フォールバック・タイマーによって指定した時刻に、より高い優先順位を持つノードにフォールバックされます。

11. 両方のノードが node_up_complete イベントを同時に処理します。

この時点で、ノード B はメンバー・ノード・リストとキープアライブ・リストの中にノード A を含めます。

12. ノード B は「new member (新規メンバー)」メッセージをクラスターのすべてのノードに送信します。

13. ノード A は、このメッセージを受信すると、そのアクティブ・ノード・リストからメンバー・ノード・リストへノード B を移動します。

この時点では、ノード A とノード B 用に構成されたすべてのリソース・グループがクラスターのクライアントで使用可能です。

計画 157

残りのノードがクラスターに結合

14. HACMP クラスター・サービスが残りの各クラスター・ノードで始動すると、ステップ 4 から 9 が繰り返されます。各メンバー・ノードは制御メッセージの送受信を行い、イベントの処理を前述の順序で実行します。イベントの処理を完了し、新しいノードをクラスター・メンバー・リストに移動する前に、すべてのノードが node_up_complete イベントを確認する必要があることに特に注意してください。

新規ノードが結合すると、各ノードの RSCT サブシステムは通信を確立し、ハートビートの送信を開始します。ノードとアダプターは、HACMP 構成内の定義に基づいて形成される RSCT ハートビート・リングに結合します。NIC またはノードの状況が変更されると、クラスター・マネージャーは、状態変更の通知を受信し、該当するイベントを生成します。

クラスターとの再結合ノードがクラスターと再結合する際、既存のノードで実行中のクラスター・マネージャーは、node_up イベントを開始し、戻ってくるノードが作動中であると応答します。これらのノードが process_resources スクリプトの処理を完了すると、新しいノードは node_up イベントを処理して、クラスター・サービスを再開できるようにします。

この処理は、クラスター・リソースの適切なバランスを確実に取るために必要です。既存のクラスター・マネージャーがクラスターへ再結合されるノードに最初に応答するのであれば、既存のクラスター・マネージャーは再結合されたノードに属するリソース・グループを、必要に応じて解放できます。この状況でリソース・グループの解放が実際に行われるかどうかは、それぞれのリソース・グループでテークオーバー (または依存関係) がどのように構成されているかによって決まります。その後、新しいノードはそのオペレーションを開始できます。

node_up イベントの順序

以下のリストで、node_up イベントの順序を説明します。

node_upノードがクラスターに結合または再結合するとき、このイベントが発生します。

process_resourcesこのスクリプトは、ノードがサービス・アドレス (または共用アドレス) を獲得するために必要なサブイベントを呼び出し、そのアドレスに所属している (または共用の) リソースを取得して、リソースを引き継ぎます。この処理には、ディスクの使用可能化、ボリューム・グループのオンへの変更、ファイルシステムのマウント、ファイルシステムのエクスポート、ファイルシステムの NFS

マウント、およびコンカレント・アクセス・ボリューム・グループのオンへの変更が含まれます。

このスクリプトは、リソース・タイプ構成によっては、Fast Connect の取得などのその他の処理を実行する場合があります。

process_resources_completeリソースの処理が完了すると、各ノードでこのスクリプトが実行されます。

node_up_completeこのイベントは、リソースが処理され、node_up イベントが正常に完了された後に発生します。ノードの種類 (ローカル・ノードかリモート・ノードか) によって、このイベントは start_server スクリプトを呼び出してローカル・ノードでアプリケーション・サーバーを起動するか、またはリモート・ノードの起動が完了した後にローカル・ノードで NFS をマウントします。


node_up イベントと従属リソース・グループまたはサイトサイトまたはリソース・グループ間の依存関係がクラスターで構成されている場合、HACMP はクラスター内のリソース・グループに関連したすべてのイベントを、すべてのリソース・グループ用に起動したrg_move イベントを使用して node_up イベントの発生時に処理します。

クラスター・マネージャーはすべてのノード・ポリシーとサイト・ポリシー (特にリソース・グループの依存関係とサイトの構成) およびすべてのノードにあるリソース・グループの現在の配布と状態を読み込むことにより、node_up_complete を実行する前にリソース・グループの獲得、解放、オンラインとオフラインの切り替えを正常に実行できるようになります。

リソース・グループ間の親子依存関係またはロケーション依存関係により、多層アプリケーションを使用するクラスターを構築する、予測可能で信頼性の高い方法が得られます。ただし、依存関係のあるクラスターでの node_up の処理には、リソース・グループの依存関係がないクラスターでの並列処理よりも時間がかかる場合があります。node_up の config_too_long 警告タイマーは調整が必要な場合があります。

node_down イベントクラスター・ノードは、RSCT サブシステムを介してキープアライブをピア・ノードと交換し、クラスター・マネージャーがクラスター内のノードの状況を追跡できるようにします。障害が発生したノードや、意図的に停止されたノードはキープアライブを送信しなくなります。RSCT がすべてのネットワーク・インターフェースが停止していることを示している場合、またはノードがハートビートに応答しない場合、クラスター・マネージャーは node_down イベントを実行します。クラスターの構成によっては、その後ピア・ノードが必要なアクションをとることによって、基幹アプリケーションの起動と実行を継続させ、データを引き続き使用できるようにします。

node_down イベントは、次のノードで開始できます。

v クラスター・サービスを停止してリソース・グループをオフラインに切り替えている

v クラスター・サービスを停止してリソース・グループを別のノードに移動している

v クラスター・サービスを停止してリソース・グループを UNMANAGED 状態に設定している

v 障害が起こった

クラスター・サービスを停止してリソース・グループをオフラインに切り替えている

クラスター・サービスを停止してリソース・グループをオフライン状態にすると、node_down_complete イベントによって停止したノードのリソースが解放された後に、HACMP がローカル・ノード上で停止します。他のノードは、node_down_complete イベントを実行し、停止したノードのリソースをテークオーバーしません。

クラスター・サービスを停止してリソース・グループを移動している

クラスター・サービスを停止してリソース・グループを別のノードに移動すると、ローカル・ノード上のnode_down_complete イベントによってこのノードのリソース・グループが解放された後に、HACMP が停止します。リソース・グループのノード・リストにある残りのノードは、解放されたリソース・グループを引き継ぎます。

クラスター・サービスを停止してリソース・グループを UNMANAGED 状態に設定している

クラスター・サービスを停止してリソース・グループを UNMANAGED 状態に設定すると、HACMP ソフトウェアがローカル・ノード上でただちに停止します。停止したノード上で Node_down_complete が実行されます。リモート・ノードのクラスター・マネージャーは、node_down イベントを処理しますが、どの

計画 159

リソース・グループもテークオーバーしません。停止したノードはリソース・グループを解放しません。

ノード障害

ノードに障害が発生すると、そのノード上のクラスター・マネージャーには、node_down イベントを生成する時間がありません。この場合、残りのノードのクラスター・マネージャーは、node_down イベントが発生したこと (障害が発生したノードは通信不能になったこと) を認識し、node_down イベントをトリガーします。

これにより、クラスターを再構成する一連のサブイベントが起動され、障害の発生したノードを処理します。リソース・グループにあるノード・リストの残りのノードは、クラスターの構成に基づいてリソース・グループを引き継ぎます。

node_down イベントの順序

以下のリストで、node_down イベントのデフォルトの並行順序を説明します。

node_down

ノードが意図的にクラスターから離脱するかまたはノードに障害が発生すると、このイベントが発生します。

node_down イベントは forced パラメーターを受け取る場合があります。

すべてのノードで node_down イベントが実行されます。

すべてのノードで process_resources スクリプトを実行します。クラスター・マネージャーは影響を受けるリソース・グループの状態と構成内容を評価すると、一連のサブイベントを実行して、フォールオーバーまたはフォールバック用の構成に従いリソースを再配布します。

すべてのノードで process_resources_complete スクリプトを実行します。

node_down_complete

ネットワーク・イベントHACMP は、ローカルとグローバルという 2 つのタイプのネットワーク障害を見分け、それぞれのタイプの障害に対して、異なるネットワーク障害イベントを使用します。ネットワーク障害イベントのスクリプトは、メールを送信するためにカスタマイズされることがよくあります。

ネットワーク・イベントの順序

次のリストはネットワーク・イベントを示しています。


項目説明

network_down (ローカル) このイベントは、特定のノードのみがネットワークとの接続を失ったときに発生します。このイベントの形式は次の通りです。

network_down node_name network_name

サービス IP がリソース・グループの一部として構成されている場合、クラスター・マネージャーは、選択的復旧アクションを取り、影響を受けたリソース・グループを他のノードに移動します。回復処置の結果は、hacmp.out に記録されます。

network_down (グローバル) このイベントは、ネットワークに接続しているすべてのノードが、ネットワークとの接続を失ったときに発生します。この場合、ノードに関連する障害ではなく、ネットワークに関連する障害が発生したと想定されます。このイベントの形式は次の通りです。

network_down -1 network_name

注: -1 引数の部分は必ず -1 にします。この引数は、network_down イベントがグローバルであることを示します。

グローバル・ネットワーク障害イベントはシステム管理者にメールで通知を送信しますが、適用すべきアクションはローカル・ネットワーク構成によって異なるため、それ以外のアクションは行いません。

network_down_complete (ローカル)

このイベントは、ローカル・ネットワーク障害イベントの完了後に発生します。このイベントの形式は次の通りです。

network_down_complete node_name network_name

ローカル・ネットワーク障害イベントが発生すると、クラスター・マネージャーは、そのネットワークに接続しているサービス NIC を含むリソース・グループに対して、選択的回復処置を実行します。

network_down_complete (グローバル)

このイベントは、グローバル・ネットワーク障害イベントの完了後に発生します。このイベントの形式は次の通りです。

network_down_complete -1 network_name

適用すべきアクションはネットワーク構成によって異なるため、デフォルトのイベント処理は何のアクションも実行しません。

network_up このイベントは、ネットワークが使用可能になったことをクラスター・マネージャーが検出すると発生します。ネットワークが再び使用可能になると、HACMP は、ネットワーク上のサービス IP ラベルがあるリソース・グループを再度オンラインにしようとします。

network_up_complete このイベントは、network_up イベントが問題なく完了した後にのみ発生します。手操作による介入がイベントで要求されていることをシステム管理者に通知するために、このイベントはカスタマイズされることがよくあります。ネットワークが再び使用可能になると、HACMP は、ネットワーク上のサービス IP ラベルがあるリソース・グループを再度オンラインにしようとします。

ネットワーク・インターフェース・イベントクラスター・マネージャーは、イベントを開始することによって、ネットワーク・インターフェースの結合、および障害の発生ならびに使用不可状態に対応します。

このようなイベントには、以下のものがあります。

計画 161

項目説明

swap_adapter このイベントは、ノード上のサービス IP ラベルをホスティングするインターフェースに障害が起きたときに発生します。swap_adapter イベントは、サービス IP ラベルを同一 HACMP

ネットワーク上の非サービス・インターフェースに移動し、ルーティング・テーブルを再構築します。サービス IP ラベルが IP エイリアスである場合は、追加 IP ラベルとして非サービス・インターフェースに配置されます。それ以外の場合は、非サービス IP ラベルはインターフェースから除去され、障害が発生したインターフェースに配置されます。現在サービス IP

ラベルを保持しているインターフェースに後で障害が発生した場合、別の非サービス・インターフェースが存在すれば、swap_adapter は、その非サービス・インターフェースに切り替えることができます。永続ノード IP ラベルが障害の発生したインターフェースに割り当てられていた場合、その永続ノード IP ラベルは、サービス・ラベルと共に非サービス・インターフェースに移されます。注: HACMP は、シャットダウン時に IP エイリアスをインターフェースから除去します。ネットワークが作動可能になると、エイリアスを再度作成します。これらの変更は、hacmp.out ファイルに記録されます。

swap_adapter_complete このイベントは、swap_adapter イベントが問題なく完了した後でのみ発生します。swap_adapter_complete イベントは、エントリーを削除し、クラスター IP アドレスを PING

することで、ローカル ARP キャッシュが更新されたことを確認します。

fail_standby このイベントは、非サービス・インターフェースに障害が発生した場合や、非サービス・インターフェースが IP アドレス・テークオーバーの結果として使用不可になった場合に発生します。fail_standby イベントは、非サービス・インターフェースに障害が発生した、または使用不可になったことを示すコンソール・メッセージを表示します。

join_standby このイベントは、非サービス・インターフェースが使用可能になると発生します。join_standby イベントは、非サービス・インターフェースが使用可能になったことを示すコンソール・メッセージを表示します。HACMP では、ネットワーク・インターフェースが使用可能になると、HACMP は、リソース・グループを再度オンラインにしようとします。

fail_interface このイベントは、インターフェースに障害が起きたときに、サービス・アドレスを回復するために使用可能な非サービス・インターフェースがない場合に発生します。テークオーバー・サービス・アドレスがモニターされます。インターフェースに障害が発生し、さらに回復に使用可能なインターフェースがない一方で、同一ネットワーク上で別のインターフェースが動作中であるという可能性もあります。このイベントは、回復に IP エイリアスを使用するネットワークを含むすべてのネットワークに適用されます。IP エイリアスによる IPAT 用に構成されたネットワーク上で非サービス NIC に障害が発生すると、fail_interface イベントが実行されることに注意してください。障害が発生したインターフェースがサービス・ラベルであった場合、rg_move イベントがトリガーされます。

join_interface このイベントは、非サービス・インターフェースが使用可能になるか、または回復すると発生します。このイベントは、IP エイリアスによる IPAT を回復に使用するネットワークを含む、すべてのネットワークに適用されます。IP エイリアスを使用するよう定義されたネットワークでは、非サービス・インターフェースが定義されていないため、この場合に実行されるjoin_interface イベントでは、非サービス・インターフェースがクラスターに結合することだけが示されます。

単一ネットワーク・インターフェースの障害ではイベントが生成されない

ネットワーク上でアクティブなネットワーク・インターフェースが 1 つしかない場合、クラスター・マネージャーはそのネットワーク・インターフェースについて障害イベントを生成できません。これは、インターフェースの正常性を判別するための通信を行うピアがないためです。ネットワーク・インターフェースが1 つしかない状況には、次のようなものがあります。

v 単一ノード・クラスターの場合

v 1 つのノードだけがアクティブなマルチノード・クラスターの場合

v 仮想イーサネット・インターフェースのあるマルチノード・クラスターの場合

v 1 つのインターフェースを除く、ネットワーク上の残りのすべてのインターフェースに、1 つずつ順番に障害が発生した場合


例えば、すべてのサービス・インターフェースまたは非サービス・インターフェースが切断されているクラスターを始動すると、以下のような結果となります。

最初のノード稼働: 障害イベントは生成されない。

v 2 番目のノード稼働: 1 つの障害イベントが生成される。

v 3 番目のノード稼働: 1 つの障害イベントが生成される。

v 以下同じ。

v この状態の処理については、『2 ノード・クラスターのサービス・アダプター障害の識別』を参照してください。

関連資料:

59ページの『2 ノード・クラスターのサービス・アダプター障害の識別』特定の条件下で単一アダプター・ネットワークになる可能性があるクラスター構成では、HACMP によってアダプター障害を正確に判断することが難しい場合があります。これは、RSCT トポロジー・サービスが、パケット・トラフィックを単一アダプターを介して強制的に送信し、そのアダプターの正常な動作を確認することができないためです

クラスター全体のステータス・イベントデフォルトで、クラスター・マネージャーは、クラスターの再構成とトポロジー変更の処理のための時間制限を認識します。時間制限に達すると、クラスター・マネージャーは config_too_long イベントを始動します。

すべてのクラスター・ステータス・イベントを次に示します。

項目説明

config_too_long このシステム警告は、クラスター・イベントの処理時間が指定したタイムアウト時間より長い場合に発生します。このメッセージは、hacmp.out ファイルに記録されます。デフォルトでは、すべてのイベントについてタイムアウト時間が 360 秒に設定されています。SMIT

を使用して、クラスター・イベントの実行中に HACMP で config_too_long 警告が発生するまでの時間をカスタマイズできます。

reconfig_topology_start このイベントはクラスター・トポロジーの動的再構成の開始を示します。

reconfig_topology_complete このイベントは、クラスター・トポロジーの動的再構成が完了したことを示します。

reconfig_resource_acquire このイベントは、動的再構成の影響を受けたクラスター・リソースが該当のノードによって獲得されていることを示します。

reconfig_resource_release このイベントは、動的再構成の影響を受けたクラスター・リソースが、該当のノードによって解放されていることを示します。

reconfig_resource_complete このイベントは、クラスター・リソースの動的再構成が正常終了したことを示します。

cluster_notify このイベントは、自動クラスター構成モニターがクラスター構成内にエラーを検出したとき、検証によってトリガーされます。このイベントの出力は、クラスター内でクラスター・サービスを実行しているすべてのノード上で hacmp.out に記録されます。

event_error いずれかのノードで致命的エラーが発生すると、すべてのクラスター・ノードがevent_error イベントを実行します。すべてのノードはエラーを記録し、障害の発生しているノード名を hacmp.out ログ・ファイルから呼び出します。

リソース・グループのイベント処理と回復クラスター・マネージャーは、必要なトポロジー情報やリソース・グループの状態だけでなく、リソース・グループ・ノードの優先順位ポリシー、サイト・ポリシー、構成されたすべての依存関係も追跡します。これによりさまざまな回復処置がとれるようになり、多くの場合はユーザーの介入も不要になります。イベン

計画 163

ト・ログには、それぞれの高水準イベントごとに詳細な要約が含まれ、障害の処理中に各リソース・グループについて行われたアクションを正確に理解するのに役立ちます。

HACMP でのリソース・グループの処理方法について詳しくは、『クラスター・イベント時のリソース・グループの動作』を参照してください。このトピックには、次の HACMP 機能の説明が記載されています。

v リソース・グループの処理に対する選択的フォールオーバー

v リソース・グループ獲得障害の処理

v IP エイリアスによる IPAT で構成されたリソース・グループの処理

v HACMP/XD リソース・グループの処理

注:

v 1. リソース・グループまたはサイト間の依存関係が指定されている場合、HACMP は通常と異なる順序でイベントを処理します。詳細については、後出の resource_state_change イベントに関するセクションを参照してください。

v 2. このセクションのリストには、可能性のあるリソース・グループの状態がすべて含まれているわけではありません。サイトが定義されている場合、リソース・グループの 1 次インスタンスと 2 次インスタンスは、オンライン、オフライン、エラー状態、または UNMANAGED 状態になる可能性があります。また、リソース・グループ・インスタンスは、獲得または解放の途中であることも考えられます。対応するリソース・グループの状態はここにリストされていませんが、どのアクションを実行するかを説明する記述名が付けられています。

リソース・グループ・イベントクラスター・マネージャーは、ノード停止のようなイベントの処理中に行われた回復処置の結果として、リソース・グループを移動する場合があります。

項目説明

rg_move このイベントは、指定したリソース・グループをあるノードから別のノードへと移動します。

rg_move_complete このアクションは、rg_move イベントが正常に完了したことを示します。

resource_state_change リソース・グループの依存関係またはサイトがクラスター内で構成されている場合、このトリガー・イベントはリソース・グループの回復に使用します。このアクションは、クラスター・マネージャーが 1 つ以上のリソース・グループの状態を変更する必要があるか、またはクラスター・マネージャーの管理するリソースの状態が変更されていることを示します。このイベントは、次のいずれかの状況が発生した場合に、すべてのノードで実行されます。

v アプリケーション・モニターの障害

v ボリューム・グループの損失による選択フォールオーバー

v ローカル・ネットワークの停止

v WAN の障害

v リソース・グループ獲得の失敗

v IP インターフェース可用性でのリソース・グループ回復

v リソース・グループの整定タイマーの終了

v リソース・グループのフォールバック・タイマーの終了。イベント実行時に、リソース・グループの状態が TEMP_ERROR に変わります。この内容はすべてのノードにブロードキャストされます。


項目説明

resource_state_ change_complete このイベントは、resource_state_change イベントが正常に完了すると実行されます。必要に応じて、前処理イベントまたは後処理イベントを追加できます。例えば、リソースの状態の変更について通知が必要な場合などです。

external_resource_state_ change このイベントは、リソース・グループの依存関係またはサイトがクラスターで構成された後に、ユーザーがリソース・グループを移動して、HACMP が動的処理パスを使用して要求を処理する場合に実行されます。

external_resource_state_ change_complete このイベントは、external_esource_state_change イベントが正常に完了すると実行されます。

リソース・グループ・サブイベントイベントの処理中に個々のリソースを取り扱うとき、以下のアクションが行われる場合があります。例えば、ファイルシステムのアンマウントおよびマウントが進行中である場合、ファイルシステムは、あるノードでオフラインにされて解放されます。その後、ファイルシステムは別のノードに獲得され、オンラインになります。

このリストには、想定されるリソース・グループの状態が、すべてではありませんが、含まれています。

項目説明

releasing このアクションは、リソース・グループをオフラインにするか、または別のノード上で獲得するために、リソース・グループが解放中であることを示します。

acquiring このアクションは、あるノード上でリソース・グループを獲得中の場合に使用されます。

rg_up このアクションは、リソース・グループがオンラインになっていることを示します。

rg_down このアクションは、リソース・グループがオフラインになっていることを示します。

rg_error このアクションは、リソース・グループがエラー状態であることを示します。

rg_temp_error_ state このアクションは、リソース・グループが一時的にエラー状態になっていることを示します。例えば、ローカル・ネットワーク障害やアプリケーション障害などの場合に発生します。この状態は、このリソース・グループの rg_move イベントを開始するよう、クラスター・マネージャーに知らせます。クラスターが安定していれば、リソース・グループはこの状態になりません。

rg_acquiring _secondary リソース・グループがターゲット・サイトでオンラインになります (複製リソースのみがオンラインになります)。

rg_up_secondary リソース・グループがターゲット・サイトの 2 次ロール内でオンラインになります (複製リソースのみがオンラインになります)。

rg_error_ secondary ミラー・データを受け取っているサイトのリソース・グループがエラー状態にあります。

rg_temp_error_ secondary ミラー・データを受け取っているサイトのリソース・グループが一時的にエラー状態になっています。

イベントが完了したあと、クラスター・マネージャーは、そのイベントに関連したリソースおよびリソース・グループの状態を取得しています。クラスター・マネージャーは、次に、内部的に保持しているリソース・グループ情報を分析し、リソース・グループのいずれかに関して回復イベントをキューに入れる必要があるかどうかを判断します。また、クラスター・マネージャーは、リソース・グループ内の個別のリソースの状況を使用して、hacmp.out ログ・ファイルに包括的なイベント要約を出力します。

それぞれのリソース・グループごとに、クラスター・マネージャーは、リソース・グループがオンラインになろうとして失敗したノードの記録を取ります。この情報は、回復イベントが処理されると更新されます。クラスター・マネージャーは、リソース・グループがオンラインまたはエラー状態になると、ただちにリソース・グループのノード・リストをリセットします。

計画 165

HACMP では、以下のように、リソース・グループのエラー状態が従来のバージョンよりも詳細に表示されます。

リソース・グループがエラー状態である原因 HACMP で表示されるメッセージ

親グループがオンラインではないため、子リソース・グループが使用できない

親がオフラインのためオフライン (OFFLINE due to parent offline)

より高い優先順位の別ノード依存関係グループがオンラインである

使用できるノードがないためオフライン (OFFLINE due to lack of

available node)

配布されている他のグループが獲得されたオフライン (OFFLINE)

グループがフォールオーバーして、一時的にオフライン状態である

オフライン (OFFLINE)

手動での介入が必要になるのは、イベント処理終了後もリソース・グループがエラー状態である場合のみです。

リソース・グループの移動処理中は、アプリケーションのモニターは中断され、適宜再開されます。アプリケーション・モニターは、イベントが処理されている間はアプリケーションが「回復」状態であることを認識します。

項目説明

resume_appmon このアクションは、アプリケーションのモニターを再開するためにアプリケーション・モニターによって使用されます。

suspend_appmon このアクションは、アプリケーションのモニターを中断するためにアプリケーション・モニターによって使用されます。

HACMP でのリソース・グループの処理方法について詳しくは、『クラスター・イベント時のリソース・グループの動作』を参照してください。この付録では、リソース・グループの処理を行うための選択フォールオーバー、リソース・グループ獲得失敗の処理、IP エイリアスによる IPAT が構成されたリソース・グループの処理、および HACMP/XD リソース・グループについて説明しています。

クラスター・イベント処理のカスタマイズクラスター・マネージャーは、特定の一連のイベントおよびサブイベントを認識できるので、きわめて柔軟なカスタマイズ方式が可能になります。HACMP イベント・カスタマイズ機能を使用すると、クラスター・イベント処理をサイトに合わせてカスタマイズできます。イベント処理をカスタマイズすると、障害が発生した場合に最も重要なリソースへの効率の高いパスを提供できるようになります。ただし、構成内容によって効率は異なります。

計画プロセスの一環として、イベント処理をカスタマイズするかどうかについて決定する必要があります。デフォルト・スクリプトによって実行されるアクションで目的が達成できる場合は、構成プロセスでさらにイベントを構成する必要はありません。

ご使用の環境に合わせてイベント処理をカスタマイズすることを決定した場合は、この章で説明しているHACMP イベント・カスタマイズ機能を使用してください。イベント処理をカスタマイズする場合は、これらのユーザー定義のスクリプトを、構成プロセスの間に HACMP に登録します。

必要に応じて、デフォルトのイベント・スクリプトを変更するか、またはユーザー独自のイベント・スクリプトを作成できます。デフォルトのイベント・スクリプトの変更や、独自のスクリプトとの置き換えは、絶対に行わないでください。これを行った場合、HACMP クラスターの保守、アップグレード、およびトラブルシューティングが非常に困難になります。また、ユーザー独自のイベント・カスタマイズ・スクリプトを作成した場合は、そのスクリプトを使用するよう HACMP ソフトウェアを構成する必要があります。


イベント・カスタマイズ機能には、以下の機能が含まれます。

v イベント通知

v 前処理イベントおよび後処理イベントの処理

v イベントの回復および再試行

イベントの完全なカスタマイズには、次の例に示すように、システム管理者への (イベント処理の前後の)

通知と、イベント処理の前後に実行されるユーザー定義コマンドまたはスクリプトが含まれます。

Notify sysadmin of event to be processedPre-event script or commandHACMP event scriptPost-event script or commandNotify sysadmin that event processing is complete

イベント通知電子メールを送信する notify コマンドを指定すれば、イベントが発生しようとしている (またはたった今発生した) こと、またイベント・スクリプトが成功または失敗したことを通知できます。

クラスター・イベントの通知メソッドの構成は、SMIT の「Change/Show a Custom Cluster Events (ユーザー定義クラスター・イベントの変更/表示)」パネルで行います。例えば、トラフィックの経路を指定し直さなければならない可能性があることをシステム管理者に知らせるために、サイトでネットワーク障害の通知イベントを使用することが必要な場合があります。その後、network_up 通知イベントを使用して、復元されたネットワークを介してトラフィックのサービスが再開されたことをシステム管理者に知らせます。

HACMP クラスターでのイベント通知は、イベント前処理スクリプトとイベント後処理スクリプトを使用して行うこともできます。

イベントに応答するユーザー定義リモート通知を構成することもできます。

関連資料:

171ページの『イベントのカスタム・リモート通知』SMIT インターフェースを使用して、クラスター・イベントに呼応してカスタマイズされたページを発行するための通知メソッドを定義できます。携帯電話を含む任意の電話番号にテキスト・メッセージ通知を送信したり、任意の電子メール・アドレスにメールを送信したりできます。

イベント前処理および後処理スクリプトクラスター・マネージャーがイベント・スクリプトを呼び出す前後に実行されるコマンドまたは複数のユーザー定義スクリプトを指定できます。

例えば、node_down イベント・スクリプトの処理の前に実行されるイベント前処理スクリプトを 1 つ以上指定できます。クラスター・マネージャーは、リモート・ノードが停止していることを認識すると、まず、そのユーザー定義スクリプトを処理します。このようなスクリプトの 1 つで、パフォーマンスに影響が出る可能性がある (アダプターがスワップされる間やアプリケーション・サーバーが停止されてから再始動される間) という旨のメッセージを、すべてのユーザーに送信するように指定できます。 node_down イベント・スクリプトに続き、network_up 通知のイベント・スクリプト後処理を組み込むことで、特定のシステムが別のネットワーク・アドレスで現在使用可能であることを知らせるメッセージを、すべてのユーザーに対してブロードキャストできます。

イベントの前後の処理が有用な場合のその他のシナリオとして、以下のような例があります。

v node_down イベントが発生した場合に、サイト固有のアクションで、start_server サブイベント・スクリプトのイベント前処理スクリプトが使用されるように指示できます。このスクリプトは、停止したア

計画 167

プリケーション・サーバーをテークオーバーしようとしているサーバーのユーザーに、パフォーマンスが変化する可能性があること、または特定のアプリケーション用に代替システムを求める必要があることを通知できます。

v ネットワークが停止しているという理由で、ユーザー定義インストールにより、新規 IP 経路を作成することで他のマシンを介してトラフィックの経路を再指定できる場合があります。network_up およびnetwork_up_complete イベント・スクリプトでは、順序を逆にすることが可能であり、すべてのネットワークが機能した後で適切な経路が存在することを確認できます。

v ローカル・ノード上でネットワークに障害が発生した (ただし、そのノード以外ではネットワークは機能している) 場合、サイトでは後処理イベントとして、クラスター・サービスを停止してリソース・グループを別のノードに移動することが必要な場合があります。

HACMP 前処理イベントおよび後処理イベントを作成する際、/etc/environment で定義されているシェル環境変数はいずれも、プログラムでは使用できません。これらの変数のいずれかを使用する必要がある場合は、スクリプトに次の行を組み込むことによって、明示的にソースを示す必要があります。

". /etc/environment"

クラスター用にイベント前処理スクリプトまたはイベント後処理スクリプトを作成しようとする場合、ユーザー・スクリプトには、指定する HACMP イベント・スクリプトで使用されるのと同じパラメーターが渡されるという点に注意してください。イベント前処理スクリプトとイベント後処理スクリプトの場合、イベント・コマンドに渡される引数は、イベント名、イベント終了状況、イベント・コマンドに渡されている後続の引数です。

すべての HACMP イベント・スクリプトは、/usr/es/sbin/cluster/events ディレクトリーに保持されます。ユーザー・スクリプトに渡されるパラメーターは、イベント・スクリプトのヘッダーにリストされます。

注意:ユーザー・スクリプト内で HACMP プロセスを強制終了しないように注意してください。ps コマンドの出力から、grep を使用して特定のパターンを検索する場合は、HACMP または RSCT プロセスにパターンが一致しないようにします。

イベント前処理およびイベント後処理のスクリプトが不要になることがある以前のバージョンの HACMP から移行する場合、既存のイベント前処理スクリプトやイベント後処理スクリプトの一部が不要になる場合があります。HACMP 自体がより多くの状況を処理します。

イベント前処理スクリプトまたはイベント後処理スクリプトの代わりに強制 varyon 属性を使用する

ボリューム・グループに対して強制 varyon 属性を指定した場合は、varyon 操作を強制実行するための特殊スクリプトは不要になります。

リモート・ノードで障害を示すようになった event_error

従来、回復不能なイベント・スクリプト障害が発生すると、障害発生クラスター・ノードで event_errorイベントが実行されました。残りのクラスター・ノードは障害を示しませんでした。 HACMP では、いずれかのノードで致命的エラーが発生すると、すべてのクラスター・ノードが event_error イベントを実行します。すべてのノードはエラーを記録し、障害の発生しているノード名を hacmp.out ログ・ファイルから呼び出します。


event_error イベントの前処理または後処理イベントを追加した場合、これらのイベント・メソッドが、障害の発生しているノードだけでなく、すべてのノードでこれらのイベント・メソッドが呼び出されることに注意します。

Korn シェル環境変数は、イベント・スクリプトが失敗したノードを示します。EVENT_FAILED_NODE

は、イベントが失敗したノードの名前に設定されます。イベント前処理スクリプトまたはイベント後処理スクリプトでこの変数を使用して、障害が発生した場所を判別します。

変数 LOCALNODENAME は、ローカル・ノードを識別します。したがって、LOCALNODENAME がEVENT_FAILED_NODE と一致しない場合は、リモート・ノードで障害が発生しています。

並列処理されるリソース・グループ、およびイベント前処理/後処理スクリプトの使用

リソース・グループは、クラスター内のすべてまたは一部のリソース・グループに対して、カスタマイズされた順次処理の順序を指定しない限り、HACMP ではデフォルトで並列処理されます。

リソース・グループの並列処理時には、クラスター内で発生してイベント要約に表示されるクラスター・イベントの数が減少します。

並列処理を使用すると、カスタマイズしてイベント前処理スクリプトやイベント後処理スクリプトを作成できる特定のクラスター・イベントの数が少なくなります。構成内のリソース・グループのリストに対して並列処理の使用を開始する場合は、既存のイベント前処理/後処理スクリプトの一部がこれらのリソース・グループに対して機能しない可能性がある点に注意してください。

特に、リソース・グループの並列処理中には以下のイベントのみが発生します。

node_up

node_down

acquire_svc_addr

acquire_takeover_addr

release_svc_addr

release_takeover_addr

start_server

stop_server

注: 並列処理では、上記のイベントが、並列に処理されているリソース・グループのリスト全体に適用されます。順次処理の場合のように単一のリソース・グループに適用されるのではありません。上記のイベントに対してイベント前処理スクリプトやイベント後処理スクリプトを構成していた場合、移行後はこれらのイベント・スクリプトが単一のリソース・グループではなくリソース・グループのリスト全体に対して起動され、予期した通りに動作しない場合があります。

以下のイベントは、リソース・グループの並列処理では発生しません。

get_disk_vg_fs

release_vg_fs

node_up_ local

node_up_remote

node_down_local

node_down_remote

計画 169

node_up_local_complete

node_up_remote_complete

node_down_local_complete

node_down_remote_complete

イベント前処理/後処理スクリプトを使用しており、現行バージョンへのアップグレードを予定している場合は、並列処理で発生しないこれらのイベントについて考慮してください。

イベント前処理/後処理スクリプトを引き続き使用する必要がある場合としては、以下のいずれかのケースが考えられます。

シナリオ実行する処置

新規に追加されたリソース・グループに対してイベント前処理/後処理スクリプトを使用する場合

新規に追加されたリソース・グループはすべて並列に処理されます。このため、クラスター・イベントの数が減少します。したがって、イベント前処理/後処理スクリプトの作成対象となるイベントは限定されています。

このケースで、特定のクラスター・イベント用に作成されたイベント前処理/後処理スクリプトによって処理される必要のあるリソースがリソース・グループ内にある場合、これらのリソース・グループを SMIT で順次処理リストに組み込み、これらのリソースに特定のイベント前処理/後処理スクリプトが使用されるようにします。

リソース・グループの順次処理または並列処理の指定については、セクション『リソース・グループの処理順序の構成』を参照してください。

HACMP 4.5 以降にアップグレードして、構成内の既存のリソース・グループの一部に対して並列処理を選択する場合

移行前に、カスタマイズしたイベント前処理スクリプトまたはイベント後処理スクリプトをクラスター内で構成していた場合、移行後はこれらのリソース・グループが並列処理されるため、一部のイベント用のイベント・スクリプトをこれらのリソース・グループに対して使用できなくなります。これは、並列処理ではこれらのイベントが発生しないためです。

既存のイベント・スクリプトを引き続きリソース・グループに動作させたい場合は、これらのリソース・グループを SMIT で順次順序リストに組み込み、これらのリソースに対してイベント前処理/後処理スクリプトを使用できるようにします。

リソース・グループの順次処理または並列処理の指定については、セクション『リソース・グループの処理順序の構成』を参照してください。

関連資料:

108ページの『強制 varyon の使用』HACMP には、AIX 自動エラー通知メソッドとあわせて使用する強制 varyon 機能があります。強制varyon 機能により、最大のデータ可用性を実現できます。使用可能なデータの有効なコピーが 1 つ存在する限り、ボリューム・グループに対して varyon を強制実行すれば、ボリューム・グループをオンライン状態に維持できます。強制 varyon は、ミラーリングされた論理ボリュームを持つボリューム・グループに対してのみ使用してください。

従属リソース・グループとイベント前処理/後処理スクリプト従来、システム管理者は、リソース・グループおよびアプリケーションの順序付けを行うために、イベント前処理およびイベント後処理の処理スクリプト内にアプリケーション回復ロジックを作成する必要がありました。各クラスターは、すべてのクラスター・イベントのイベント前処理スクリプト、およびすべてのクラスター・イベントのイベント後処理スクリプトで構成されていました。


こうしたスクリプトは、全体を網羅する case ステートメントとすることができました。例えば、特定のノード上の特定のイベントにアクションを起こす場合、個々のケースを編集し、イベント前処理および後処理スクリプトの必須コードを追加し、さらにスクリプトがすべてのノードで同じになっていることを確認する必要もあります。

要約すると、そのようなスクリプトのロジックは、クラスターの希望する動作をキャプチャーするものの、クラスター構成が変化すると、カスタマイズしにくく、後の保守はさらに難しくなります。

イベント前処理スクリプトやイベント後処理スクリプトを使用している場合や、クラスターでサポートされるアプリケーションの依存関係を確立するためにリソース・グループの処理順序を決定するなどの方法を使用している場合、これらの方法は不要であるか、かなり単純化できます。代わりに、クラスターのリソース・グループ間の依存関係を指定できます。従属リソース・グループの計画について詳しくは、『リソース・グループ依存関係』を参照してください。

従属リソース・グループに組み込まれたアプリケーションがあり、依存関係に加えてイベント前処理/後処理スクリプトを使用することを引き続き計画している場合、イベント前処理/後処理スクリプトに追加のカスタマイズが必要になることがあります。アプリケーションの停止および再起動プロセスにおけるデータ損失の可能性を最小限にするには、アプリケーション・サーバー・スクリプトをカスタマイズして、アプリケーションの停止プロセス時は、コミットされていないデータを共用ディスクに一時的に格納し、アプリケーションの再起動プロセス時にアプリケーションに読み込み直すようにします。アプリケーションは停止したノードとは別のノード上で再始動される場合があるため、共用ディスクを使用することが重要です。

関連資料:


イベントの回復および再試行イベント・スクリプトの失敗から回復しようとするコマンドを指定できます。回復コマンドが成功し、イベント・スクリプトの再試行カウントが 0 より大きければ、イベント・スクリプトは再試行されます。回復コマンドの実行を試みる回数も指定できます。

例えば、ユーザーをログオフした後でファイルシステムをアンマウントし、ファイルシステムに現在アクセス中のユーザーがいないことを確認するという操作の再試行を、回復コマンドに含めることができます。

時間的問題など、クラスター上の特定のイベントの処理に影響する条件が識別される場合、問題に確実に対処するのに十分な再試行カウントを持った回復コマンドを挿入できます。

イベントのカスタム・リモート通知SMIT インターフェースを使用して、クラスター・イベントに呼応してカスタマイズされたページを発行するための通知メソッドを定義できます。携帯電話を含む任意の電話番号にテキスト・メッセージ通知を送信したり、任意の電子メール・アドレスにメールを送信したりできます。

検証自動モニター cluster_notify イベントを使用すると、クラスター構成でエラーが検出された場合にメッセージを送信する HACMP リモート通知メソッドを構成できます。このイベントの出力は、クラスター内でクラスター・サービスを実行しているすべてのノード上で hacmp.out に記録されます。

計画 171

各種イベント用に、さまざまなテキストや数字によるメッセージとダイヤル先電話番号を伴った通知メソッドを、任意の数だけ構成できます。関連付けられたテキスト・メッセージが、通知をトリガーする可能性のある全イベントに対して応答するための十分な情報を伝達できるのであれば、異なる複数のイベントに対して同一の通知メソッドを使用できます。

通知メソッドの構成後、テスト・メッセージを送信すると、すべて正常に構成されたかどうか、および特定のイベントに対して所定のメッセージが送信されるかどうかを確認できます。

カスタム・リモート通知の計画

リモート通知では、以下の条件を満たす必要があります。

v ページングに使用される tty ポートは、ハートビート・トラフィックに使用することはできません。

v 指定したすべての tty ポートが AIX に対して定義され、使用可能であることが必要です。

v ページまたはテキスト・メッセージを送信するすべてのノードに対して、所定のモデムをインストールして使用可能にする必要があります。

注: HACMP は、通知メソッドの構成時、およびページの発行前に、tty ポートの可用性を検査します。モデムの状況は検査されません。

v 電子メール・メッセージを SMIT パネルから AIX メールで送信するすべてのノードに対して、TCP/IP

によるインターネット接続を設定する必要があります。

v テキスト・メッセージを携帯電話に送信するすべてのノードに対して、所定の Hayes 互換モデムをインストールして使用可能にする必要があります。

v SMS メッセージを無線送信するすべてのノードに対して、Falcom 互換 GSM モデムを RS232 ポートに取り付けて、パスワードを無効にする必要があります。モデムが携帯電話に接続されていることを確認してください。

警告までのイベント期間のカスタマイズクラスターの構成、クラスター・ノードの速度、およびクラスター・イベント中に移動する必要のあるリソースの数とタイプにもよりますが、イベントによっては、完了に要する時間間隔が他のイベントと異なるものがあります。そうしたイベントでは、config_too_long 警告メッセージを発行する前に、HACMP がイベントの完了を待機する時間をカスタマイズできます。

リソース・グループを獲得または解放するようなクラスター・イベントは、完了するまでに長い時間がかかります。このようなイベントは、低速イベントとみなされます。これには、次のようなものがあります。

v node_up

v node_down

v reconfig_resource

v rg_move

v site_up

v site_down.

低速クラスター・イベントのイベント期間をカスタマイズすると、通常のクラスター操作の間に不要なシステム警告を受け取ることを回避できます。

その他のクラスター・イベントはすべて高速イベントと見なされます。これらのイベントは通常、リソースの獲得や解放を伴わないため、完了までの時間が短くなります。高速イベントの例には、次のものがあります。


v swap_adapter

v リソース・グループを処理しないイベント

高速イベントの場合、警告までのイベント期間をカスタマイズすると、訂正アクションが高速になります。

低速クラスター・イベントでは、HACMP が警告メッセージをかなり頻繁に発行する場合、または高速イベントでは、問題の可能性があるイベントの検出を迅速化する場合、警告までのイベント期間のカスタマイズを検討します。

注: リソース・グループ間の依存関係は、マルチティア・アプリケーションによるクラスター構築に予測可能で信頼性のある方法を提供します。ただし、依存関係を持つクラスターでの一部のクラスター・イベント(node_up など) の処理には、すべてのリソース・グループが並列処理されるようなイベントの処理よりも長く時間がかかることがあります。リソース・グループの依存関係が許すのであれば、HACMP は複数の非コンカレント・リソース・グループを並列で処理し、同時に複数のコンカレント・リソース・グループをすべてのノードで処理します。ただし、他のリソース・グループに従属するリソース・グループは、他のリソース・グループが最初に始動されるまで始動できません。node_up イベントの config_too_long 警告タイマーに、この処理を完了できる十分な時間を設定する必要があります。

ユーザー定義イベントHACMP が指定の回復プログラムを実行できるよう、ユーザー独自のイベントを定義できます。これにより、定義済み HACMP のイベント前処理/後処理スクリプト・カスタマイズ機能に、新しい特性が追加されます。

定義するイベントと、イベント回復処置を定義している回復プログラムとの間のマッピングを、SMIT インターフェースを使用して指定します。これにより、各回復処置の有効範囲、およびすべてのノードにわたって同期するイベント・ステップの数の両方を制御できるようになります。

イベントの登録についての詳細は、IBM RSCT の資料を参照してください。

RMC リソースは、システムの他のコンポーネントにサービスを提供する物理または論理エンティティーのインスタンスを表します。リソースという用語は、非常に広範囲に使用され、ハードウェア・エンティティーだけでなくソフトウェア・エンティティーも表します。例えば、リソースは特定のファイルシステムを指すときもあれば、特定のホスト・マシンを指すときもあります。リソース・クラスは、プロセッサーまたはホスト・マシンなど、同じタイプのすべてのリソースを表します。

リソース・マネージャー (デーモン) は、実際のエンティティーを RMC の抽象概念にマップします。各リソース・マネージャーは、固有の管理タスクのセットまたはシステム機能を表します。リソース・マネージャーは、管理タスクのセットまたはシステム機能に関連する重要な物理または論理エンティティー・タイプを識別し、これらのエンティティー・タイプを表すリソース・クラスを定義します。

例えば、ホスト・リソース・マネージャーは、個々のホスト・マシンのさまざまな側面を表すリソース・クラスのセットを含みます。ここでは以下のものを表すリソース・クラスが定義されます。

v 個々のマシン (IBM.Host)

v ページング装置 (IBM.PagingDevice)

v 物理ボリューム (IBM.PhysicalVolume)

v プロセッサー (IBM.Processor)

v ホストの ID トークン (IBM.HostPublic)

v ホストで実行中のプログラム (IBM.Program)

計画 173

v ホストでサポートされる各種アダプター。ATM アダプター (IBM.ATMDevice)、イーサネット・アダプター (IBM.EthernetDevice)、FDDI アダプター (IBM.FDDIDevice)、トークンリング・アダプター(IBM.TokenRingDevice) など。

AIX リソース・モニターは、使用されていない CPU のパーセント (IBM.Host.PctTotalTimeIdle) や使用中のディスク・スペースのパーセント (IBM.PhysicalVolume.PctBusy) などの OS 関連のリソース条件に対するイベントを生成します。プログラム・リソース・モニターは、プロセスの予期せぬ終了など、プロセス関連の出来事に対してイベントを生成します。リソース属性 IBM.Program.ProgramName が使用されます。

回復プログラムの作成回復プログラムには、回復コマンドが連続して指定されています。場合によっては、barrier コマンドも所々に指定されます。

これらの仕様のフォーマットは以下の通りです。

:node_set recovery_command expected_status NULL

ここで、

v node_set は、回復プログラムが実行されるノードのセットです。

v recovery_command は、実行可能プログラムへの絶対パスを指定する、引用符で区切られている文字列です。コマンドには、引数を含めることはできません。引数を必要とする実行可能プログラムは、別のスクリプトにする必要があります。回復プログラムは、クラスター内のすべてのノード上で、このパスに入っていなければなりません。プログラムでは、終了ステータスを指定する必要があります。

v expected_status は、回復コマンドが問題なく完了したときに戻される整数のステータスです。クラスター・マネージャーは、戻された実際のステータスと予想したステータスとを比較します。この 2 つのステータスが同じでない場合は、回復が失敗したことがわかります。expected_status フィールドに文字 X

を指定すると、クラスター・マネージャーは比較を省略します。

v NULL は現在使用されていませんが、将来の機能のために組み込まれています。

動的関係により、ノード・セットを指定します。HACMP は、次の動的関係をサポートしています。

v すべて - 回復コマンドは、現在のメンバーシップの全ノード上で実行されます。

v イベント - イベントが発生したノードです。

v その他 - イベントが発生したノードを除くすべてのノードです。

指定した動的関係は、元のコマンドと同じ回復コマンドのセットを生成します。ただし、各コマンド・セットでノード ID が node_set に置き換わっているところが違います。

ユーザー定義のイベント・コマンドのコマンド・ストリングは、スラッシュ (/) で始まる必要があります。clcallev コマンドは、スラッシュで開始されないコマンドを実行します。

RMC について役立つコマンドおよび参照資料

IBM.Host RMC リソースの永続属性定義をすべてリストするには、以下のようにします (「selection string

(選択文字列)」フィールド)。

lsrsrcdef -e -A p IBM.Host

IBM.Host RMC リソースの動的属性定義をすべてリストするには、以下のようにします (「Expression

(式)」フィールド)。

lsrsrcdef -e -A d IBM.Host


ユーザー定義イベント選択文字列を構成するときに使用する SQL に似た式については、「IBM RSCT for

AIX and Linux Administration Guide」の『第 3 章 RMC およびリソース・マネージャーを使用したリソースの管理およびモニター』を参照してください。

回復プログラムの例

イベントが発生したノードのページング・スペースが少ないという旨のメッセージを /tmp/r1.out に送信するサンプル・プログラムを示します。回復プログラム r1.rp の場合、SMIT のフィールドは、次のように埋められます。

項目説明

イベント名 E_page_space (ユーザー定義名)

回復プログラムのパス /r1.rp

リソース名 IBM.Host (クラスター・ノード)

選択文字列 Name = ?" (name of node)

Expression (式) TotalPgSpFree < 256000(VMM is within 200 MB of paging space warning level).

リソース属性にフラグを立てる条件を加えたもの。リアーム式 TotalPgSpFree >256000

リソース属性に調整済み条件を加えたもの。

この場合、回復プログラム r1.rp は、以下のようになります。

#format:#relationship >command to run >expected status NULL#event “/tmp/checkpagingspace” 0 NULL

回復プログラムでは、引数を指定したコマンド自体を実行しないことに注意してください。代わりに、シェル・スクリプト /tmp/checkpagingspace を指します。ここには以下が含まれます。

#!/bin/ksh/usr/bin/echo “Paging Space LOW!” > /tmp/r1.outexit 0

node_up イベントの回復プログラムの例

以下は、node_up イベントの回復プログラムの例です。

#format:#relationshipcommand to run expected status NULL#other “node_up” 0 NULL#barrier#event “node_up” 0 NULL#barrier#all “node_up_complete” X NULL

barrier コマンド

回復プログラムには、任意の数の barrier コマンドを挿入できます。barrier より前の回復コマンドは、すべて並列に開始されます。ノードが barrier コマンドを検出した場合は、回復プログラムを継続する前に、すべてのノードがそのコマンドに到達する必要があります。

計画 175

barrier コマンドの構文は barrier です。

イベント・ロールアップ

未処理のイベントが同時に複数存在する場合は、最高優先順位のイベントのみが表示されます。ノード・イベントは、ネットワーク・イベントよりも高い優先順位を持っています。しかし、優先順位が最低であるユーザー定義イベントは、まったくロールアップされないため、それらのイベントはすべて表示されます。

イベントの要約とプリアンブルイベントがノードの hacmp.out ログ・ファイルに記録される際、イベント詳細を記した多数の行が含まれる詳細な出力のあとに、簡潔なイベント要約が続きます。このイベント要約を使用すると、重要なクラスター・イベントのログを容易にチェックできます。

「Problem Determination Tools (問題判別ツール)」SMIT パネルの「View Event Summaries (イベント要約の表示)」オプションを使用すると、過去 7 日間の hacmp.out ファイルにあるイベント要約部分だけのコンパイルを表示できます。イベント要約は hacmp.out ファイルをデフォルトではない場所にリダイレクトした場合でもコンパイルできます。また、「Display Event Summaries (イベント要約の表示)」レポートにも、clRGinfo コマンドで生成されたリソース・グループ情報が含まれています。また、イベント要約をSMIT で表示する代わりに、選択したファイルに保管することもできます。

イベントが依存関係またはサイトのあるリソース・グループを処理する場合、プリアンブルが hacmp.outログ・ファイルに書き込まれ、リソース・グループの処理を行うサブイベントの計画リストが作成されます。

クラスター・イベント・ワークシートクラスター・イベント・ワークシートを使用すれば、クラスターのイベント処理を簡単に計画できます。

プランニング・ワークシートには、以下の手順で参照されるワークシートが含まれます。

クラスターのそれぞれのノードごとに、個別のワークシートで以下の手順のステップを繰り返します。特定のクラスター・イベントに対するカスタマイズ処理を計画する場合は、必要なフィールドにのみ値を入力してください。

1. 「Cluster Name (クラスター名)」フィールドにクラスター名を記録します。

2. 「Cluster Event Description (クラスター・イベントの説明)」フィールドに、ユーザー定義クラスター・イベントの説明を記録します。

3. 「Cluster Event Method (クラスター・イベント・メソッド)」フィールドに、クラスター・イベント・メソッドの絶対パス名を記録します。

4. 「Cluster Event Name (クラスター・イベント名)」フィールドに、クラスター・イベントの名前を入力します。

5. 「Event Command (イベント・コマンド)」フィールドに、イベント・スクリプトの絶対パス名を入力します。

6. 「Notify Command (通知コマンド)」フィールドに、イベント通知スクリプトの絶対パス名を記録します。

7. 「Remote Notification Message Text (リモート通知メッセージのテキスト)」に、リモート通知メソッドの完全なテキストを記録します。

8. 「Remote Notification Message Location (リモート通知メッセージの位置)」に、リモート通知メソッドのテキストが保存されているファイルの絶対パス名を記録します。


9. 「Pre-Event Command (イベント前処理コマンド)」フィールドに、イベント前処理スクリプトの名前を記録します。

10. 「Post-Event Command (イベント後処理コマンド)」フィールドに、イベント後処理スクリプトの名前を記録します。

11. 「Event Recovery Command (イベント回復コマンド)」フィールドに、イベント再試行スクリプトの絶対パス名を記録します。

12. 「Recovery Command Retry (回復コマンド再試行)」フィールドに再試行回数を示します。

13. 「Time Until Warning (警告までの時間)」フィールドに、リソース・グループのイベント処理に割り当てる、警告が表示されるまでの時間を記録します。

カスタマイズを計画している各イベントごとにステップ 3 から 13 を繰り返します。

HACMP クライアントの計画このトピックでは、HACMP クライアントの計画の考慮事項について説明します。これは、HACMP ソフトウェアのインストールに先行する最後のステップです。

前提条件

上記のセクションの手順を実行します。

HACMP クライアントの概説HACMP クライアントは、HACMP クラスター内のノードにアクセス可能なエンド・ユーザー装置です。計画プロセスのこのステップでは、クライアントの視点からクラスターを評価します。

HACMP クライアントにはさまざまなベンダーのハードウェアやソフトウェアが組み込まれている場合があります。HACMP クラスターとの接続を維持するには、以下のセクションで説明する問題を考慮してください。

クライアント・アプリケーション・システム

可能な場合、すべてのクライアントで Clinfo を実行してください。IBM System p ノード以外のハードウェアが構成に含まれている場合は、それらのプラットフォームに Clinfo を移植することをお勧めします。Clinfo のソース・コードは、HACMP の一部として提供されています。

これらのクライアントでどのようなアプリケーションが実行されているかについて考慮する必要があります。ユーザーは誰か。クラスター・イベントがユーザーのシステムに影響を与える場合にユーザーはメッセージを受け取る必要があるか (または受け取ることが妥当か)、という点を検討してください。

NFS サーバー

NFS 関連の問題については、セクション『HACMP による NFS の使用』を参照してください。

端末サーバー

ローカル・エリア・ネットワークで端末サーバーの使用を計画している場合は、ハードウェアを選択する際に次の点を考慮に入れてください。

v 端末サーバーの ARP キャッシュを更新できるか。端末サーバーは、Telnet も含め、TCP/IP プロトコルに準拠している必要があります。

計画 177

v 端末サーバーはプログラムの組み込みが可能か、それともクラスター・イベントが発生した場合、手動による介入を必要とするか。

v クライアントに対するクラスター・イベントの影響を更新または処理する制御ファイルを、クラスター・ノードから端末サーバーにダウンロードできるか。

使用する端末サーバーがこれらの動作要件を満たしていない場合は、クラスター環境を構成する際に、ハードウェア・アドレス・スワップ・オプションを選択してください。

関連資料:

109ページの『HACMP による NFS の使用』HACMP ソフトウェアは、NFS 処理に対して可用性の拡張を提供します。

Clinfo を実行しているクライアントClinfo プログラムは、ネットワーク・イベントまたはノード・イベントが発生するたびに/usr/es/sbin/cluster/etc/clinfo.rc スクリプトを呼び出します。デフォルトでは、このアクションがシステムのARP キャッシュを更新して、ネットワーク・アドレスへの変更を反映します。さらに他のアクションが必要な場合は、このスクリプトをカスタマイズできます。

クラスターへの再接続

Clinfo デーモンを実行しているクライアントは、クラスター・イベントの後で、クラスターに迅速に再接続できます。クラスターとクライアントの間に IBM System p 以外のハードウェアがある場合は、クラスター・イベントの発生後にこれらのネットワーク・コンポーネントの ARP キャッシュを更新できることを確認してください。

クラスターの構成時に、IP アドレスと同様にハードウェア・アドレスもスワップするように設定しておくと、ARP キャッシュの更新について考慮する必要がなくなります。ただし、このオプションを使用すると、ユーザーにとって引き継ぎにかかる時間が長くなることを知っておく必要があります。

IP エイリアスによる IPAT を使用する場合は、すべてのクライアントが TCP/IP Gratuitous ARP をサポートしていることを確認してください。

clinfo.rc スクリプトのカスタマイズ

Clinfo を実行するクライアントでは、クラスター・イベントが発生したときに ARP キャッシュの更新だけでなく、より多くのことを実行するように /usr/es/sbin/cluster/etc/clinfo.rc スクリプトをカスタマイズするかどうかを決定する必要があります。

Clinfo を実行していないクライアントClinfo を実行していないクライアントについては、クラスター・ノードからクライアントを PING することによってローカル ARP キャッシュを間接的に更新する必要があります。

clinfo.rc スクリプトの PING_CLIENT_LIST 変数に通知したいクライアント・ホストの名前またはアドレスをクラスター・ノード上で追加します。クラスター・イベントが発生すると、clinfo.rc は、PING_CLIENT_LIST で指定されている各ホストに以下のコマンドを実行します。

ping -c1 $host

クライアントが、クラスター・ネットワークの 1 つと直接接続されていることが前提です。


ネットワーク・コンポーネントネットワークの構成時に、クライアントをクラスターのローカル・ネットワークに接続させず、ルーター、ブリッジ、またはゲートウェイの反対側にあるネットワークに接続させた場合は、クラスター・イベントの発生時にそれらのネットワーク・コンポーネントの ARP キャッシュを必ず更新できるようにしておきます。

これが不可能な場合は、クラスター環境の構成時にハードウェア・アドレス・スワップを必ず使用するようにしてください。

オンライン・プランニング・ワークシートの使用本トピックでは、オンライン・プランニング・ワークシート (OLPW) アプリケーションを使用して、クラスター定義ファイル (ワークシート・ファイルとも呼ばれる) を作成する方法について説明します。本トピックではまた、クラスター定義ファイルと、ファイルを使用して既存の HACMP クラスターを定義する方法について説明します。

クラスター定義ファイルには、クラスターに適用して、HACMP のために構成できる計画情報が含まれます。クラスターの状態により、クラスター定義ファイルの作成方法は複数あります。

v オンライン・プランニング・ワークシートを使用して、最初から、または既存のファイルから新規定義ファイルを作成できます。

v クラスター定義ファイルを手動で編集する場合は、XML エディターまたは、普通のテキスト・エディターを使用して編集できます。

v すでに HACMP スナップショットがある場合、本章のセクション『クラスター定義ファイルへのスナップショットの変換』の説明に従って SMIT を使用すれば、スナップショット情報をクラスター定義ファイルに変換できます。

v すでに HACMP がインストールされている場合、本章のセクション『動作中のクラスターからのプランニング・ワークシートの復元: 定義ファイルのエクスポート』の説明に従って SMIT を使用すれば、構成をクラスター定義ファイルとしてエクスポートできます。この方法は、他の担当者によってセットアップされた構成済みのクラスターについて作業する場合に役立ちます。多くの場合、このようなクラスターをサポートする必要があり、クラスターを最初に構成した際のベースとなったプランニング・ワークシートは存在しません。この機能を使用すると、プランニング・ワークシートを復元して、当該クラスターの説明を、判読可能なオンライン形式または印刷形式で得ることができます。

v すでに HACMP がインストールされており、中間ファイルを作成しない場合は、クラスター構成情報を直接 OLPW に入力できます。

クラスター定義に特定の構成情報の保存が終了した後、クラスター定義ファイルをクラスターに適用します。

前提条件

オンライン・プランニング・ワークシート・アプリケーションを使用する前に、HACMP に関連する概念および用語について理解しておく必要があります。また、計画プロセスにも精通している必要があります。アプリケーションを使用するときには、クラスターの各コンポーネントの計画方法について、本書のこれまでの各セクションを参照してください。また、開始する前に、計画した構成のダイアグラムを作成してください。

関連タスク:

計画 179

202ページの『スナップショットのクラスター定義ファイルへの変換』クラスター・スナップショットをクラスター定義ファイルへ変換することにより、オンライン・プランニング・ワークシート・アプリケーションまたは cl_opsconfig ユーティリティーでスナップショット情報の読み込みが可能になります。

201ページの『動作中のクラスターからのプランニング・ワークシートの復元 : 定義ファイルのエクスポート』SMIT を使用して、アクティブな HACMP クラスターからクラスター定義ファイルを作成できます。次に、オンライン・プランニング・ワークシート・アプリケーションでこのファイルをオープンできます。

187ページの『新規クラスター定義ファイルの作成』クラスターの計画を開始するとき、すべての情報を手動で入力でき、OLPW がクラスター構成情報を読み込むことができます。HACMP 定義をインポートするには、クラスター・ノードから OLPW を実行してください。アクティブな HACMP クラスターからクラスター定義ファイルを作成することもできます。

関連資料:

203ページの『HACMP クラスターへのワークシート・データの適用』アプリケーションの構成パネルを指定したら、ファイルを保管し、そのファイルをクラスター・ノードに適用します。Windows システムでオンライン・プランニング・ワークシート・アプリケーションを使用する場合は、初めに構成ファイルをクラスター・ノードにコピーしてから適用します。


オンライン・プランニング・ワークシート・アプリケーションの概説オンライン・プランニング・ワークシートは、HACMP クラスター構成を計画することが可能な Java ベースのアプリケーションです。このアプリケーションを使用して、HACMP 構成情報をインポートし、必要に応じて編集できます。また、すべての構成情報を手動で入力することもできます。このアプリケーションにより、クラスターへ適用できるクラスター定義ファイルとして情報を保存します。次に、HACMP により、この情報に基づいてクラスターが自動的に構成されます。また、このアプリケーションにより、データが検証され、すべての必須情報が入力されていることが確認されます。

構成を文書化するために、HTML レポートを作成できます。これには、計画の完了部分と、未完部分が示されています。

制限

オンライン・プランニング・ワークシート・アプリケーションは、以下の項目をサポートしていません。

v HACMP ディスカバリー

v 各国語サポート

v HACMP/XD

v カスタム・リソース回復

v GPFS™ と HACMP の統合

v Smart Assists for WebSphere/DB2/Oracle

また、このアプリケーションは、以下について構成することはできません。

v 次の実行時パラメーター

– RSCT 最大ログ長

– HACMP 実行時パラメーター


– 拡張パフォーマンス調整パラメーター

v HACMP の構成前に大幅な AIX の構成を必要とする、以下の複雑な構成

– サービス IP ラベル・エイリアス用の配布設定のカスタマイズ

– NIM 構成への追加または変更

– WAN サポート、SNA、または X25 用 HA 通信リンク

– ユーザー定義検証メソッド

– ユーザー定義イベント

v 動的ノード優先順位設定用のカスタマイズ・ポリシー

v クラスター接続を必要とする機能 (C-SPOC を必要とする機能など)

2 つのリソース・グループの親/子関係を構成し、リソース・グループのロケーション依存関係を「Online

on the same node Dependency (同じノード依存関係でオンライン)」で構成した後は、OLPW は 2 つのリソース・グループの設定、親/子関係とリソース・グループのロケーション依存関係を表示しません。「Resource Group Runtime Policies (リソース・グループのランタイム・ポリシー)」を選択すると、右のボックスとウィンドウでは次の値のみが表示されます。

v 獲得/開放順序

v RG 配布ポリシー

v ユーザー定義リソース・グループ回復

オンライン・プランニング・ワークシート・アプリケーションのインストールオンライン・プランニング・ワークシート・アプリケーションは、Microsoft Windows または IBM AIX システムにインストールし実行できます。また、アプリケーションを IBM Web サイトから直接実行することもできます。

インストールの前提条件

オンライン・プランニング・ワークシート・アプリケーションを実行するには、Java™ ランタイム環境(JRE) バージョン 1.3.0 以上が必要です。

オンライン・プランニング・ワークシート・アプリケーションは以下のオペレーティング・システムでサポートされています。

v 以下の IBM AIX バージョン (デフォルトで JRE が含まれます)

v Microsoft Windows 2000

オンライン・プランニング・ワークシート・アプリケーションは適切な JRE がインストールされている他のシステムでも動作します。アプリケーションのフォント表示は、使用可能なシステム・フォントによって異なることに注意してください。

ユーザー許可要件

一般に、Windows 2000 システムや AIX システムからオンライン・プランニング・ワークシート・アプリケーションを実行できます。ただし、Java 仮想マシン (JVM) で、ユーザーが Java アプリケーションからディスクへデータを保存できる必要があります。

AIX システムでは、ユーザーには、以下の権限も必要です。

計画 181

v ファイルを AIX システムにコピーする権限 (構成ファイルが Windows などの別のシステムで作成された場合)

v 構成ファイルを適用する root 権限

cluster.es.worksheets ファイルセットのインストール

cluster.es.worksheets ファイルセットをインストールすると、以下のファイルが /usr/es/sbin/cluster/worksheets

に作成されます。

ワークシートアプリケーションを呼び出す AIX スクリプト

worksheets.jarアプリケーションが含まれている Java アーカイブ

worksheets.batアプリケーションを呼び出す Windows スクリプト

Readme.txtアプリケーションのインストールおよび実行の説明

オンライン・プランニング・ワークシート・アプリケーションを呼び出すには、次のファイルを実行します。

/usr/es/sbin/cluster/worksheets/worksheets

注:

v worksheets.jar ファイルを /usr/es/sbin/cluster/worksheets ディレクトリーから移動する場合、/usr/es/sbin/cluster/worksheets/worksheets ファイルを編集し、WORKSHEETS 変数に、worksheets.jar ファイルの正確な絶対パスを指定します。

v /usr/es/sbin/cluster/worksheets/worksheets ファイルを別の場所に移動する場合、WORKSHEETS 変数を変更する必要はありません。

v オンライン・プランニング・ワークシート・アプリケーションは、使用先のシステムになければ、cluster.es.worksheets ファイルセットからインストールできます。

オンライン・プランニング・ワークシート・アプリケーションの実行については、『アプリケーションの始動および停止』を参照してください。

Windows システムへのアプリケーションのインストール

オンライン・プランニング・ワークシート・アプリケーションを Microsoft Windows システムにインストールするには、AIX システムにオンライン・プランニング・ワークシートをダウンロードおよびインストールします。

ダウンロードするファイルの名前は次の通りです。

worksheets.jar

v worksheets.bat および worksheets.jar ファイルを、Windows システム上で選択したディレクトリーにコピーします。FTP でファイルをコピーする場合は、必ずバイナリー・モードを指定してください。

v worksheets.bat と worksheets.jar ファイルが同一ディレクトリーにない場合は、worksheets.bat ファイルを編集して WORKSHEETS 変数に worksheets.jar ファイルの絶対パスを指定します。

注: オンライン・プランニング・ワークシート・アプリケーションを実行するために、CLASSPATH 環境変数を編集する必要はありません。


オンライン・プランニング・ワークシート・アプリケーションの実行については、『アプリケーションの始動および停止』を参照してください。

関連資料:

『アプリケーションの始動および停止』このセクションはアプリケーションの実行についての情報が含まれています。

アプリケーションの始動および停止このセクションはアプリケーションの実行についての情報が含まれています。

AIX インストールからのアプリケーションの実行

AIX システムでアプリケーションを実行するには、次のコマンドを実行します。

/usr/es/sbin/cluster/worksheets/worksheets

アプリケーションは、適切なバージョンの JRE がインストールされているかどうかを検査してから、バックグラウンドでアプリケーションを実行します。

Windows インストールからのアプリケーションの実行

アプリケーションを実行するには、コマンド行から worksheets.bat コマンドを実行します。

IBM Web サイトからのアプリケーションの実行

オンライン・プランニング・ワークシート・アプリケーションは直接実行できます。

ダウンロードするファイルの名前は次の通りです。

worksheets.jar

使用許諾契約書に同意した後、オンライン・プランニング・ワークシートの worksheets.jar ファイルを探してクリックするか、AIX のコマンド行で次のコマンドを実行します。

java -jar worksheets.jar

アプリケーションの停止

アプリケーションを停止するには、「File (ファイル)」>「Exit (終了)」を選択します。

関連資料:

181ページの『オンライン・プランニング・ワークシート・アプリケーションのインストール』オンライン・プランニング・ワークシート・アプリケーションは、Microsoft Windows または IBM AIX システムにインストールし実行できます。また、アプリケーションを IBM Web サイトから直接実行することもできます。

オンライン・プランニング・ワークシート・アプリケーションの使用このセクションでは、オンライン・プランニング・ワークシートのタスクについて説明します。

メインウィンドウの理解メインウィンドウは、左側のペインと右側のペインで構成されています。

v 左側のペインでは、クラスター・コンポーネントへナビゲーションできます。

v 右側のペインには、左側のペインで選択したアイコンに関連したパネルが表示されます。これらのパネルに構成情報を入力します。

計画 183

オンライン・プランニング・ワークシート・アプリケーションを開くと、以下のようにメインウィンドウが表示されます。

クラスター構成のナビゲート左側のペインでは、以下の 3 つのタブ表示でクラスター構成にナビゲーションできます。

その表示とは、以下のものです。

v 必要条件。この表示を使用して、クラスター情報を入力します。この表示の項目は、推奨されるクラスター・コンポーネントの構成順序で名前がリストされます。項目は、一部の構成項目間の依存性を示す論理的な順序で表示されます。例えば、クラスター内のノードは組み込み先リソース・グループの定義前に識別するため、ノードはリソース・グループの前に表示されます。

v 階層。これを使用して、クラスター構成を論理的にグループ化して表示します。

v ヘルプ。この表示を使用して、ヘルプ・トピックがリストされます。

ナビゲーション・ペインでアイコンの横にアスタリスク (*) が付いている場合は、その項目の下位にナビゲーション可能な項目が含まれています。その項目の構成パネルは表示されません。

「Requisite (必要条件)」表示と「Hierarchical (階層)」表示での項目の編成方法の違いを次の図に示します。


左側ペイン下部のタブをクリックして、表示を変更した場合でも、左側ペインで同じ項目が選択されたままになっています。このため、選択した項目のコンテキストを容易に切り換えることができます (オンライン・ヘルプの参照など)。

標準/拡張構成パネルの表示標準の構成パネルのセットを表示させることも、拡張 (完全な) 構成パネルのセットを表示させることもできます。これらの設定は、SMIT の標準構成オプションや拡張構成オプションに類似しています。

表示するパネルのセットは、「Settings (設定)」メニューから選択します。

標準の構成パネルのセットでは、基本的な HACMP 構成をセットアップできます。次の図に、標準および拡張「Requisite (必要条件)」表示を示します。

計画 185

構成パネルへのデータ入力構成パネルには、フィールドのグループがあり、クラスターについての情報を入力します。すぐにデータ入力を開始できます。

データを入力するのと同時に、入力された情報の構文がアプリケーションによって検証されます。計画段階でクラスター接続が存在しない場合は、入力した情報の正確性の検証が制限されることに注意してください。例えば、インターフェースに割り当てられた IP ラベルの値が正確かどうかは検証されません。

また、ドキュメンテーション用の目的で HACMP クラスターに関する情報を入力するためのパネルがいくつか用意されています。

v ディスク

v ボリューム・グループ

v 論理ボリューム


v ネットワーク・ファイルシステム・エクスポート

v アプリケーション

これらのパネルに入力した情報は、別のパネルからも使用できます。例えば、アプリケーション・サーバーを構成する前にアプリケーションを指定する場合です。この情報は生成するすべてのレポートに組み込まれますが、構成ファイルでは使用されません。

必須およびオプション・フィールドへのデータ入力

構成パネルのフィールドには必須フィールドとオプション・フィールドがあります。

v 必須フィールド。これらのフィールドに値を指定してから、構成をクラスターに適用する必要があります。必須フィールドは、太字で表示されます。

ファイルを保存するときに必須フィールドが空の場合は、値を入力する必要のある残りの必須フィールドを示すメッセージが表示されます。この検証メッセージはログ・ファイルとして保存できます。

v オプション・フィールド。これらのフィールドの値は HACMP の実行には必須ではありませんが、これらのデータは、オンライン・プランニング・ワークシートのレポートに組み込まれます。オプション・フィールドは通常の文字で表示されます。

オンライン・ヘルプの利用構成パネルに情報を入力しているときに、「Help (ヘルプ)」タブから使用可能なオンライン・ヘルプを参照してください。

以下の情報については、オンライン・ヘルプを参照してください。

v 現在のパネルの説明

v ボタン・アクション

「Help (ヘルプ)」表示には、「Requisite (必要条件)」表示または「Hierarchical (階層)」表示で選択されたパネルに関する情報が表示されます。

各「Help (ヘルプ)」パネルの上にある索引リンクからは、以下のトピックを表示できます。

v オンライン・プランニング・ワークシートについて

v メニュー

v ナビゲーション

新規クラスター定義ファイルの作成クラスターの計画を開始するとき、すべての情報を手動で入力でき、OLPW がクラスター構成情報を読み込むことができます。HACMP 定義をインポートするには、クラスター・ノードから OLPW を実行してください。アクティブな HACMP クラスターからクラスター定義ファイルを作成することもできます。

注: HACMP 定義のインポートは、Windows 2000 マシンではサポートされていないので、メニュー・オプションは使用不可になります。

クラスター定義ファイルを作成するには、次の手順を実行します。

1. 『クラスターの計画』のセクションに記載された通りに、すべてのデータを手動で入力します。

または

2. 以下のように HACMP クラスターから直接構成情報を読み込みます。

a. 「File (ファイル)」>「Import HACMP Definition (HACMP 定義のインポート)」を選択します。

計画 187

「Import Validation (インポートの検証)」ダイアログ・ボックスが表示されます。検証エラーについての情報を表示したり、HACMP 定義ファイルの検証が正常に終了したことを示す通知を受信できます。

b. 『クラスターの計画』のセクションに記載された通りに、追加データを手動で入力します。

3. アクティブな HACMP クラスターからクラスター定義ファイルを作成するには、セクション『動作中のクラスターからのプランニング・ワークシートの復元: 定義ファイルのエクスポート』を参照してください。クラスター定義ファイルをオープンするには、セクション『既存クラスター定義ファイルのオープン時』を参照してください。

関連概念:

192ページの『クラスターの計画』クラスターを計画する場合、「Requisite (必要条件)」表示を使用します。この表示では、論理的な順序に従って計画パネルが提示されます。あるパネルにデータを入力すると、後続のパネルのフィールドに入力済みの情報が表示される場合があります。

関連タスク:

201ページの『動作中のクラスターからのプランニング・ワークシートの復元 : 定義ファイルのエクスポート』SMIT を使用して、アクティブな HACMP クラスターからクラスター定義ファイルを作成できます。次に、オンライン・プランニング・ワークシート・アプリケーションでこのファイルをオープンできます。

関連資料:

『既存クラスター定義ファイルのオープン時』クラスター定義ファイルは、オンライン・プランニング・ワークシート・アプリケーションでオープンできます。

既存クラスター定義ファイルのオープン時クラスター定義ファイルは、オンライン・プランニング・ワークシート・アプリケーションでオープンできます。

注: クラスター定義ファイルは、オンライン・プランニング・ワークシート・アプリケーションが動作している同じノード上になければなりません。

クラスター定義ファイルをオープンするには、「File (ファイル)」>「Open (オープン)」を選択します。

一度にオープンできるのは、1 つのクラスター定義ファイルだけです。クラスター定義ファイルがオープンされ、新規ファイルを開始する場合、「File (ファイル)」>「New (新規)」を選択します。変更を加えたかどうかにかかわらず、現在のファイルを保存するようにプロンプトが出され、構成情報なしのメインウィンドウが表示されます。

関連タスク:

189ページの『クラスター定義ファイルの保管時』クラスター定義ファイルは、作成後や変更後に保存する必要があります。

クラスター情報の追加、変更、および削除情報を入力し、「Add (追加)」を選択すると、パネル下部のリストに情報が表示されます。この後、別の項目の情報を入力できます。


ダイアログ・ボックスの下のリストから項目を選択し、その項目の情報を変更したり行を削除したりすることができます。変更内容は、その情報を使用する他のパネルのエントリーに影響を及ぼす場合があります。例えば、リソース・グループを削除すると、そのリソース・グループを参照する他のパネルで、削除したリソース・グループの名前が表示されなくなります。

「Add (追加)」または「Modify (変更)」を選択すると、フィールドに入力された情報の構文がアプリケーションによって検証されます。構文エラーがある場合は、エラーに関する情報を示すメッセージが表示されます。

クラスター情報についての注の追加構成を計画する際に、後で参考になるように注を追加して情報を保管できます。

クラスターの注を追加するには、次の操作を行います。

1. 「Requisite (必要条件)」表示または「Hierarchical (階層)」表示の左側で、「Cluster Notes (クラスターの注)」を選択します。

2. 「Cluster Notes (クラスターの注)」パネルで、保管する情報を入力します。

3. 「Apply (適用)」を選択します。

クラスター定義の妥当性検査妥当性検査では、指定された情報の入力が完了し、名前が 32 文字までに制限されるなどのパラメーターの基準が満たされていることを確認します。

デフォルトでは、オンライン・プランニング・ワークシートは次の場合に妥当性検査を実行します。

v アクティブなクラスターのクラスター定義のインポート時

v クラスター定義ファイルのオープン時

v クラスター定義ファイルの保管時

クラスターの計画段階では、妥当性検査をオフにすると、ファイルを保管するたびにクラスター定義の妥当性検査を行うよう指示するプロンプトが表示されなくなります。

クラスター定義ファイルに保管されたクラスター定義の自動妥当性検査をオフにするには、「Settings (設定)」>「Validate When Saving (保存時に検証)」を選択して、メニュー項目の横のチェック・マークをクリアします。

クラスター定義ファイルの妥当性検査はいつでも実行できます。

クラスター定義ファイルの情報の妥当性検査を行うには、「File (ファイル)」>「Validate HACMPDefinition (HACMP 定義の検証)」を選択します。

クラスター定義ファイルの保管時クラスター定義ファイルは、作成後や変更後に保存する必要があります。

クラスター定義ファイルを保管するには、次の手順を実行します。

1. 「File (ファイル)」>「Save (保存)」を選択して、ファイル名としてクラスター名を使用します。

または

2. 「File (ファイル)」>「Save As (別名保存)」を選択して、別のファイル名を入力します。

計画 189

「Save (保存)」ダイアログ・ボックスで、クラスター定義ファイルの名前と場所を入力します。ファイル名の拡張子が .haw (または .xml) であることを確認し、「Save (保存)」をクリックします。オンライン・プランニング・ワークシートでは、クラスター定義ファイルを保管します。

ファイルを保管すると、自動妥当性検査がオフになっていない限り、OLPW によって自動的にクラスター定義の妥当性検査が行われます。

クラスター定義ファイルを保管するとき、OLPW により、サポートされていないコンポーネントの情報は保管されません。例えば、X.25 と SNA リンクはサポートされていないため、これらに関する情報は保管されません。

関連資料:

189ページの『クラスター定義の妥当性検査』妥当性検査では、指定された情報の入力が完了し、名前が 32 文字までに制限されるなどのパラメーターの基準が満たされていることを確認します。

HTML 構成レポートの作成構成レポートにより、クラスター構成の状態についての情報を HTML ファイルに記録できます。

構成を評価しやくするために、空のパネル上のフィールドや、他のパネル上で値の入力されていない必須フィールドが、Undefined としてマークされます。Undefined としてマークされます。

計画プロセス時に、レポートを作成できます。構成定義ファイルを適用してから、レポートを生成し、HACMP の初期構成を記録します。

レポートには、以下のような要約情報が示されます。

v レポートで使用したイメージを格納するディレクトリーの名前

v オンライン・プランニング・ワークシート・アプリケーションのバージョン


v 「Cluster Configuration (クラスター構成)」パネルで指定された作成者および会社名

v 「Cluster Notes (クラスターの注)」パネルから追加されたクラスターの注

v オンライン・プランニング・ワークシートによりクラスター定義ファイルが最後に保管された日時

レポートには、以下のそれぞれのセクションも含まれています。

項目説明

v ノードおよび通信パス v アプリケーション

v ネットワーク v NFS エクスポート

v IP ラベル v アプリケーション・サーバー

v グローバル・ネットワーク v アプリケーション・モニター

v サイト v ページャーまたは携帯電話

v ディスク v リモート通知

v リソース・グループ v テープ・リソース

v ボリューム・グループ v リソース・グループのランタイム・ポリシー

v 論理ボリューム v ノードの要約

v ファイル・コレクション v クラスターの検証

v サイト間 LVM ミラーリング

注: リストされるボリューム・グループ、論理ボリュームおよび NFS エクスポート・リソースは、OLPW

を使ってこれらのセクションに記入されたものだけです。他のリソースは、OLPW またはクラスター定義ファイルのエクスポートでの追加が可能です。

構成定義レポートを作成するには、次の手順を実行します。

1. 「File (ファイル)」>「Create Report (レポートの作成)」を選択します。

2. 「Save (保存)」ダイアログ・ボックスで、レポート・ファイルの名前と位置を入力します。

レポートが生成されると、olpwimages というディレクトリーが、レポートを保管するディレクトリー内に作成されます。例えば、レポート・ファイルをディレクトリー /home/pat/reports に保管すると、グラフィックス・ディレクトリーは /home/pat/reports/olpwimages になります。olpwimages ディレクトリーには、レポートに関連したグラフィックス・ファイルが入っています。

イメージ・ディレクトリーのレポートとファイルは、レポートを生成するごとに上書きされます。

注: 生成されたレポート・ファイルと関連する olpwimages ファイルは、システム上に残ります。これらのファイルは手動で管理する必要があります。

以下の図に、4 ノード・クラスターについてのレポートの一部を示します。

計画 191

クラスターの計画クラスターを計画する場合、「Requisite (必要条件)」表示を使用します。この表示では、論理的な順序に従って計画パネルが提示されます。あるパネルにデータを入力すると、後続のパネルのフィールドに入力済みの情報が表示される場合があります。

計画プロセスの概説HACMP 構成のクラスターを計画する場合、必要なステップがいくつかあります。

HACMP 構成を計画するには、次の操作を行います。

1. 「Requisite (必要条件)」表示から「Cluster (クラスター)」を選択します。

2. 「Cluster Configuration (クラスター構成)」パネルで「Cluster Name (クラスター名)」などの値を指定し、「Apply (適用)」を押します。

3. 「Nodes and Communication Paths (ノードおよび通信パス)」を選択し、対応するパネルで構成情報を入力します。

4. 「Requisite (必要条件)」表示で項目の選択を続け、関連する右側のパネルに構成情報を入力します。


5. 計画と構成情報を定期的に保管します。

計画プロセスが完了したら、次の操作を行います。

1. 構成ファイルを保管します。セクション『クラスター定義ファイルの保存』を参照してください。

2. クラスターへ適用します。セクション『HACMP クラスターへのワークシート・データの適用』を参照してください。

3. レポートを作成し、初期クラスター構成に関する情報を保管します。セクション『HTML 構成レポートの作成』を参照してください。

以下のセクションの順序は、「Requisite (必要条件)」表示での項目のリスト順序と同じです。これらのセクションでは、入力した構成情報のタイプについて簡潔に説明し、構成オプションの詳細が記載されている本書の他のセクションへの参照を示します。本文には、拡張構成表示で使用可能なパネルを示します。

関連タスク:

189ページの『クラスター定義ファイルの保管時』クラスター定義ファイルは、作成後や変更後に保存する必要があります。

190ページの『HTML 構成レポートの作成』構成レポートにより、クラスター構成の状態についての情報を HTML ファイルに記録できます。

関連資料:


クラスターの定義最初のステップは、クラスターを定義することです。

「Cluster Configuration (クラスター構成)」パネルでクラスターの名前を指定します。作成者名を含めることをお勧めします。アプリケーションでは、クラスター定義ファイルの最終更新日が表示されます。

クラスター・セキュリティーの定義クラスターを定義したら、クラスター・セキュリティーを定義する必要があります。

「Cluster Security (クラスター・セキュリティー)」パネルで、HACMP クラスター内の通信で使用する接続認証モードとメッセージ認証モードおよびキー管理を選択します。

関連概念:

11ページの『クラスター・セキュリティーの計画』HACMP にはクラスター・セキュリティーが備わっていて、HACMP へのユーザー・アクセスが制御され、ノード間通信にセキュリティーが使用されます。

クラスターへのノードの追加クラスターを定義したら、ノードを追加する必要があります。

「Nodes and Communication Paths (ノードおよび通信パス)」パネルで、HACMP クラスターに追加するノード、およびそのノードに接続するための通信パスを指定します。通信パスには IP ラベル/アドレス、または完全修飾ドメイン名を指定できます。

計画 193

サイト構成の計画複数サイト構成について計画する必要があります。

「Site Configuration (サイト構成)」パネルで、複数サイト構成に関する情報を指定します。 HACMP/XD

をサポートする構成には、複数の HACMP サイトが必要です。

関連資料:


リソース・グループの作成リソース・グループは、クラスターごとに作成します。

「Resource Groups (リソース・グループ)」パネルでリソース・グループに名前を割り当て、リソース・グループごとに管理ポリシーを指定します。

「Site Configuration (サイト構成)」パネル (「Display Extended Config (拡張構成の表示)」パネル) への入力が完了した後で、リソース・グループにサイト関係を定義して、ノードをサイトに割り当てることができます。1 つのノードは、1 つのサイトにのみ割り当てることができます。

次の図は、新規リソース・グループに対して進行中の構成を示します。

リソース・グループについては、『リソース・グループの計画』を参照してください。


「Settings (設定)」メニューでは、「Standard RG Config Options (標準 RG 構成オプション)」または「Extended RG Config Options (拡張 RG 構成オプション)」を選択できます。「Resource Associations

(リソース関連)」パネルでは、「Resource Type (リソース・タイプ)」にリストされるリソースのタイプがそれぞれの表示で異なります。「Extended RG Config Options (拡張 RG 構成オプション)」からリストされたリソース・タイプには、拡張構成パネルから表示できるリソースのすべてのタイプが表示されます。それ以外の点では 2 つの表示は同じです。

関連資料:


ディスク・リソースの定義クラスターを定義した後、ディスク・リソースを定義します。

「Resources (リソース)」の下の一連のパネルで、クラスターに組み込むディスクおよびファイルシステムに関する情報を指定します。これらのパネルは「Display Extended Config (拡張構成の表示)」パネルで使用可能です。

ディスク「Disks (ディスク)」パネルで、クラスターで使用するディスクについての情報を入力します。

ボリューム・グループ

(「Display Extended Config (拡張構成の表示)」パネル)「Volume Groups (ボリューム・グループ)」パネルで、クラスターで使用するボリューム・グループを指定します。

論理ボリューム

(「Display Extended Config (拡張構成の表示)」パネル)「Logical Volumes (論理ボリューム)」パネルで、クラスターで使用する論理ボリュームとこれらに関連するボリューム・グループを指定します。

Cross-site LVM mirroring (サイト間 LVM ミラーリング)

(「Display Extended Config (拡張構成の表示)」パネル)「Cross-Site LVM Mirroring (サイト間 LVM ミラーリング)」パネルで、クラスター・ノードに関連付けられた hdisk のうち、どの hdisk を HAMCP サイトに割り当てるのかを定義します。このパネルを使用する前に、「Nodes and Communication Paths (ノードおよび通信パス)」パネルでノードを定義し、「Site Configuration (サイト構成)」パネルでサイトを定義します。

サイト間 LVM ミラーリングについて詳しくは、『共用 LVM コンポーネントの計画』を参照してください。

NFS exports (NFS エクスポート)

(「Display Extended Config (拡張構成の表示)」パネル)「NFS Exports (NFS エクスポート)」パネルで、他のノードによって NFS マウント用にエクスポートされるファイルシステムがある場合は指定します。

関連資料:


計画 195


テープ・リソースの追加ここでテープ・リソースを定義すると、「Resource Associations (リソース関連)」パネルで使用できます。

(「Display Extended Config (拡張構成の表示)」パネル)「Tape Resources (テープ・リソース)」パネルで、リソース・グループに含めるテープ・リソースを指定し、デバイスの開始および停止スクリプトを指定します。

注: テープ・リソースは、2 ノード・リソース・グループにのみ組み込むことができます。リソース・グループに組み込むことができるテープ・リソースは 1 つだけです。

関連資料:


リソース関連の追加「Resource Associations (リソース関連)」パネルで、各リソース・グループの一部とするファイルシステム、サービス IP ラベル、ボリューム・グループ、アプリケーション・サーバー、hdisk などの個々のリソースを指定します。

リソース・グループのリソース関連を指定する前に、「Resource Groups (リソース・グループ)」パネルでリソース・グループを作成してください。リソース・グループを削除する場合は、先に対応するリソース関連を削除する必要があります。

リソース・グループ属性

「Resource Group Attributes (リソース・グループ属性)」パネルで、ファイルシステム、ワークロード・マネージャー、動的ノード優先順位、および強制 varyon などの一般属性についての情報を指定します。リソース・グループのリソース・グループ属性を指定する前に、「Resource Groups (リソース・グループ)」パネルでリソース・グループを作成してください。

リソース・グループ依存関係

(「Display Extended Configuration (拡張構成の表示)」パネル)「Resource Group Dependencies (リソース・グループ依存関係)」パネルで、親/子の依存関係を指定して、ペアの入力後に「Add (追加)」ボタンをクリックします。

リソース・グループのロケーション依存関係

(「Display Extended Configuration (拡張構成の表示)」パネル)「Resource Group Location Dependencies (リソース・グループのロケーション依存関係)」パネルで、リソース・グループの依存関係のタイプを指定して、リソース・グループを選択します。


Resource Group Runtime Policies (リソース・グループのランタイム・ポリシー)

(「Display Extended Configuration (拡張構成の表示)」パネル)「Resource Group Runtime Policies (リソース・グループのランタイム・ポリシー)」パネルで、リソース・グループの処理順序と設定時間、およびリソース・グループ配布ポリシーを指定します。

関連資料:

194ページの『リソース・グループの作成』リソース・グループは、クラスターごとに作成します。



132ページの『リソース・グループのロケーション依存関係』異なるリソース・グループの特定のアプリケーションが、同一のノードまたはサイトでオンラインのままになるか、または異なるノードでオンラインのままになります。

ネットワークの定義「Networks (ネットワーク)」パネルで、ネットワーク名やタイプなど、クラスターのネットワークを定義します。ネットワークに関して入力する情報は、選択したネットワーク・タイプに固有です。ディスク・ハートビート・ネットワークの場合は、どのディスクをハートビートに使用するのかも計画します。

「Networks (ネットワーク)」セクションには、IP ラベルとインターフェース名の構成パネルも含まれており、また「Display Extended Config (拡張構成の表示)」パネルには、「Global Networks (グローバル・ネットワーク)」の構成パネルが含まれています。

次の図は、「Networks (ネットワーク)」パネルで入力する情報のタイプを示します。

注: IP ラベルまたはインターフェースを含むノードまたはネットワークを削除する場合は、その IP ラベルやインターフェースをそれぞれのパネルから削除してから、関連するノードやネットワークを削除してください。

計画 197

IP ラベル

「IP Labels (IP ラベル)」パネルで、インターフェースのサービス IP ラベルおよび永続ラベルを指定します。

インターフェース名

「Interface Names (インターフェース名)」パネルで、ノード上の各インターフェースの名前を指定します。

グローバル・ネットワーク

(「Display Extended Config (拡張構成の表示)」パネル)「Global Networks (グローバル・ネットワーク)」パネルで、グローバル・ネットワークを構成するネットワーク・セットについての情報を指定します。

関連資料:


アプリケーションの追加「Application (アプリケーション)」パネルで、可用性を高めるアプリケーションを指定します。「Application (アプリケーション)」セクションには、アプリケーション・サーバーおよびアプリケーション・モニター (拡張構成パネルの場合) のための構成パネルもあります。

アプリケーション・サーバー

「Application Servers (アプリケーション・サーバー)」パネルで、アプリケーションについての情報、始動および停止スクリプト、およびアプリケーション・モニターの情報を指定します。アプリケーションを構成しなければ、アプリケーション・サーバーを構成することはできません。

アプリケーション・モニター

(「Display Extended Configuration (拡張構成の表示)」パネル)「Application Monitors (アプリケーション・モニター)」パネルで、アプリケーション・モニターの名前 (アプリケーション・サーバー名と同じ場合があります) を指定し、アプリケーションが失敗した場合に実行するアクションを定義します。アプリケーション・モニターをセットアップする前に、少なくとも 1 つのアプリケーション・サーバーを構成してください。1 つのアプリケーション・サーバーには複数のアプリケーション・モニターを割り当てることができます。

注: アプリケーション・モニターを作成した後、「Application Server (アプリケーション・サーバー)」パネルから各モニターをアプリケーション・サーバーに関連付けてください。

関連資料:


TTY ノード/ポートのペアの指定(「Display Extended Configuration (拡張構成の表示)」パネル)「Configure a Node/Port Pair (ノード/ポートのペアの構成)」パネルで、クラスター・イベントに応答してカスタマイズされたページを発行するために通知メソッドが使用できる TTY 接続についての情報を指定します。


カスタム・リモート通知

(「Display Extended Configuration (拡張構成の表示)」パネル)「Configure Remote Notification (リモート通知の構成)」パネルで、クラスター・イベントに応答してカスタマイズされたメッセージを発行するための通知メソッドについての情報を指定します。ユーザー定義のページャー通知をセットアップする前に、「TTY Node/Port Pairs (TTY ノード/ポートのペア)」パネルで TTY ノードを指定してください。ユーザー定義のページャー通知についての詳細は、『クラスター・イベントの計画』を参照してください。

関連資料:



クラスター・イベントの指定(「Display Extended Configuration (拡張構成の表示)」パネル) このパネルでは、必要に応じて HACMP イベントのイベント前処理およびイベント後処理スクリプトを指定します。

関連資料:


ファイル・コレクションの定義(「Display Extended Configuration (拡張構成の表示)」パネル)「File Collections (ファイル・コレクション)」パネルで、HACMP の正常な動作のために同期する必要のある、各クラスター・ノードに配置されているファイルを指定します。ファイルをデフォルトのファイル・リストに追加またはリストから削除できます。

ファイル・コレクションのグローバル設定(「Display Extended Configuration (拡張構成の表示)」パネル) このパネルで、自動的に同期化するファイルが同一かどうかを確認する頻度を指定します。

検証オプションの指定「Automatic Cluster Verification (自動クラスター検証)」パネルで、クラスターの検証のモニターの設定を指定します。1 つのクラスター・ノードと、そのノードの検証を実行する時間を選択します。

クラスター定義ファイルの理解クラスター定義ファイルには、クラスターについての計画情報が保管されます。これにより、最初クラスターを定義し、クラスター定義ファイルをクラスター定義にインポートし、クラスター構成を動作させることができます。

クラスター定義ファイルには、クラスター・コンポーネントに関する次の情報を含めることができますが、この情報は HACMP 構成用ではなく通知目的でのみ保管されます。他の AIX システム・コンポーネントは、以下のコンポーネントの構成データを管理します。

v アプリケーション

v ディスク

v ボリューム・グループ

v 論理ボリューム

計画 199

v NFS がマウントされたファイルシステム

オンライン・プランニング・ワークシート・アプリケーションでは、クラスターについての定義情報がXML ファイルに保管されます。XML ファイルは構造化されたフォーマットを持ち、テキスト・エディターまたは XML エディターで簡単に手動で編集できます。このセクションでは、HACMP クラスター定義XML ファイルに関連した概念について説明します。XML の概念については説明していません。

クラスター定義ファイル・フォーマットクラスター定義ファイルは、クラスター構成のデータを含む要素の構造化された XML テンプレートです。XML ファイルの要素はすべて、関連する DTD および XSD スキーマ・ファイル内で指定された順序と同じである必要があります。

注: XML ファイルでは、データが含まれていない要素を <VALIDATED/> のように省略表記することはできません。開始タグと終了タグの両方を使用する必要があります。例えば、<tag/> のようなエンティティーは <tag></tag> と表記してください。これは <VALIDATED/> などのいくつかの要素にのみ当てはまります。

次の要素は、必須です。他のすべての要素は、オプションです。

v CONFIG

v VERSION

v NODES

v NETWORKS

v INTERFACES

次の例は、必須要素のみを使用したクラスター定義ファイルの内容を示しています。

<?xml version="1.0" encoding="ISO-8859-1"standalone="yes"?><CONFIG><VERSION>5300</VERSION><CLUSTER>

<CLUSTERNAME>cluster</CLUSTERNAME><AUTHOR></AUTHOR><COMPANY></COMPANY><DATE>Sun Sep 12 18:08:52 EDT 2004</DATE>

</CLUSTER><NODES>

<NODE><NODENAME>node1</NODENAME>

</NODE></NODES><NETWORKS>

<NETWORK><NETWORKNAME>network1</NETWORKNAME><NETWORKTYPE>ether</NETWORKTYPE><IPALIASING>yes</IPALIASING><NETMASK>255.255.255.0</NETMASK></NETWORK>

</NETWORKS><INTERFACES>

<INTERFACE><INTERFACETYPE>ether</INTERFACETYPE><NETWORKNAME>network1</NETWORKNAME><NODENAME>node1</NODENAME><IPLABELNAME>ip_label1</IPLABELNAME>

</INTERFACE></INTERFACES>

</CONFIG>


クラスター定義ファイルの例2 ノード・クラスターのサンプル・クラスター定義ファイルを表示、または変更できます。

表示または変更するには、以下を参照してください。

/usr/es/sbin/cluster/worksheets/cluster-sample.haw

このファイルは、XML エディターで編集できます。クラスター定義ファイルを保管する際は、任意のファイル名を使用できますが、拡張子には、.haw (または .xml) を使用します。

クラスター定義スキーマ・ファイルクラスター定義ファイルには、2 つのスキーマ・ファイル (XSD と DTD) が付属しています。これらのファイルは、XML 構成ファイルを手動で作成する際に、従わなければならないフォーマットを定義します。XSD と DTD ファイルにより、構成ファイルの妥当性検査が可能になります。

DTD ファイルは、ドキュメント構造に対してのみ妥当性検査を実行します。XSD スキーマではさらに、ドキュメント構造だけではなく、タイプ、順番、およびデータの構成についても妥当性検査が可能です。適切な方を選択して使用します。

デフォルトでは、XSD と DTD ファイルは、全ユーザーが読み取り可能で、root ユーザーのみが読み取りと書き込みの権限を持っています (644)。これらのファイルは、以下の場所にあります。

v /usr/es/sbin/cluster/worksheets/hacmp-v5300.xsd

v /usr/es/sbin/cluster/worksheets/hacmp-v5300.dtd

HACMP クラスター構成の OLPW への変換クラスター情報の作成に加えて、異なる方法を使って、既存の HACMP クラスター情報をオンライン・プランニング・ワークシートで読むことができるフォーマットへ変換できます。

サポートされるファイルシステムのタイプを次に示します。

v 動作中のクラスターからのプランニング・ワークシートの復元 : 定義ファイルのエクスポート

v クラスター定義ファイルへのスナップショットの変換

注: クラスター定義をインポートして保管することはできますが、一部のデータは通知のみになります。クラスター定義ファイルの通知要素については、セクション『構成パネルへのデータ入力』を参照してください。

関連資料:

186ページの『構成パネルへのデータ入力』構成パネルには、フィールドのグループがあり、クラスターについての情報を入力します。すぐにデータ入力を開始できます。

動作中のクラスターからのプランニング・ワークシートの復元 : 定義ファイルのエクスポートSMIT を使用して、アクティブな HACMP クラスターからクラスター定義ファイルを作成できます。次に、オンライン・プランニング・ワークシート・アプリケーションでこのファイルをオープンできます。

この方法は、他の担当者によってセットアップされた構成済みのクラスターについて作業する場合に、非常に役立ちます。多くの場合、このようなクラスターをサポートする必要があり、クラスターを最初に構成し

計画 201

た際のベースとなったプランニング・ワークシートは存在しません。この機能を使用すると、プランニング・ワークシートを復元して、当該クラスターの説明を、判読可能なオンライン形式または印刷形式で得ることができます。

アクティブな HACMP クラスターからクラスター定義ファイルを作成するには (またはプランニング・ワークシートを復元するには)、次の手順を実行します。

1. smit hacmp と入力します。

2. SMIT で、「Extended Configuration (拡張構成)」>「Export Definition File for Online PlanningWorksheets (オンライン・プランニング・ワークシート用に定義ファイルをエクスポート)」を選択し、Enter を押します。

3. 各フィールドに次のように値を入力して、Enter を押します。

項目説明

File Name

(ファイル名)

クラスター定義ファイルの絶対パス名。デフォルトのパス名は /var/hacmp/log/config.haw です。

Cluster Notes

(クラスターの注)

クラスターに関連した追加コメント。ここに入力した情報は、オンライン・プランニング・ワークシート内の「Cluster Notes (クラスターの注)」パネルに表示されます。

4. 「Import Validation (インポートの検証)」ダイアログ・ボックスが表示されて、エクスポート時にHACMP 定義ファイルの検証が正常に行われたかどうかが示されます。

5. オンライン・プランニング・ワークシートでクラスター定義ファイルをオープンします。

クラスター定義ファイルのオープンについては、セクション『既存クラスター定義ファイルのオープン時』を参照してください。

関連資料:

188ページの『既存クラスター定義ファイルのオープン時』クラスター定義ファイルは、オンライン・プランニング・ワークシート・アプリケーションでオープンできます。

スナップショットのクラスター定義ファイルへの変換クラスター・スナップショットをクラスター定義ファイルへ変換することにより、オンライン・プランニング・ワークシート・アプリケーションまたは cl_opsconfig ユーティリティーでスナップショット情報の読み込みが可能になります。

スナップショットがクラスター定義ファイルに変換される際、スキーマで指定されたすべてのクラスター情報が変換されます。これには、オンライン・プランニング・ワークシートがサポートしていない情報も含まれます。

クラスター・スナップショットを作成するには、次の手順を実行します。

1. smit hacmp と入力します。

2. SMIT で、「Extended Configuration (拡張構成)」>「Snapshot Configuration (スナップショットの構成)」>「Convert Existing Snapshot for Online Planning Worksheets (オンライン・プランニング・ワークシート用に既存のスナップショットを変換)」を選択し、Enter を押します。

3. 各フィールドに次のように値を入力して、Enter を押します。


項目説明

クラスター・スナップショット名

変換するクラスター・スナップショットの名前。

ファイル名クラスター定義ファイルを書き込むパス。相対パス名を入力する場合、/var/hacmp/log ディレクトリーをルートとしてファイルが保存されます。最大長は 128 文字です。

説明クラスターに関連した追加コメント。ここに入力した情報は、オンライン・プランニング・ワークシート内の「Cluster Notes (クラスターの注)」パネルに表示されます。

4. オンライン・プランニング・ワークシートでクラスター定義ファイルをオープンします。

関連資料:

188ページの『既存クラスター定義ファイルのオープン時』クラスター定義ファイルは、オンライン・プランニング・ワークシート・アプリケーションでオープンできます。

HACMP クラスターへのワークシート・データの適用アプリケーションの構成パネルを指定したら、ファイルを保管し、そのファイルをクラスター・ノードに適用します。Windows システムでオンライン・プランニング・ワークシート・アプリケーションを使用する場合は、初めに構成ファイルをクラスター・ノードにコピーしてから適用します。

前提条件

クラスター定義ファイルをクラスターへ適用する前に、以下の条件が満たされているか確認します。

v HACMP ソフトウェアがすべてのクラスター・ノードにインストールされている。

v クラスター構成に指定したすべてのハードウェア・デバイスの準備が整っている。

v 既存の構成を置き換える場合は、HACMP 構成データベース内の現在のクラスター情報がすべてスナップショットに保存されていること。

v すべてのノードでクラスター・サービスが停止している。

v 有効な /usr/es/sbin/cluster/etc/rhosts ファイルがすべてのクラスター・ノードにある。これは、cl_opsconfig ユーティリティーを実行するために必要です。

クラスター構成ファイルの適用

クラスター定義ファイルを適用するには、次の手順を実行します。

1. セクション『クラスター定義の妥当性検査』の説明に従って、オンライン・プランニング・ワークシート・アプリケーションからクラスター定義ファイルを検証します。

2. セクション『HTML 構成レポートの作成』の説明に従って、レポートを作成してクラスター構成を文書化します。

3. ファイルを保管し、アプリケーションを終了します。クラスター構成ファイルが Windows システムにある場合、ファイルを HACMP ノードにコピーします。

4. クラスター・ノードから、次のように cl_opsconfig コマンドを実行します。

/usr/es/sbin/cluster/utilities/cl_opsconfig your_config_file

ここで、your_config_file は、ノード上の構成ファイルの名前です。

計画 203

cl_opsconfig ユーティリティーは、ファイルの妥当性検査を実行し (オンライン・プランニング・ワークシート・アプリケーションがローカルにインストールされている場合)、クラスターへ情報を適用し、検証します。検証中に、発生しているイベント、警告、エラーなどを示すメッセージが画面に表示されます。

cl_opsconfig エラー・メッセージを画面に表示したり、エラー・メッセージをログ・ファイルにリダイレクトすることができます。korn シェルの場合、以下のように標準エラー出力へリダイレクトできます (別のシェルでは異なる場合があります)。

/usr/es/sbin/cluster/utilities/cl_opsconfig your_config_file 2> output_file

一部の出力 (標準出力および標準エラー) はリダイレクトしないでください。

クラスター定義ファイル問題のトラブルシューティング

検証では最初に <VALIDATED> 要素の有無が判別されます。この要素が存在しておらず、オンライン・プランニング・ワークシートがインストールされている場合は、OLPW により、XML 構成ファイルの妥当性検査が実行され、処理が継続します。OLPW がインストールされていない場合は、エラー・メッセージが表示されて、オンライン・プランニング・ワークシートがインストールされていないためにファイルの妥当性検査ガ中止されたことが通知されます。

エラー・メッセージが表示される場合は、オンライン・プランニング・ワークシート・アプリケーションを使用して問題を解決し、『HACMP クラスターへのワークシート・データの適用』の説明にある手順を繰り返します。以前のクラスター定義ファイルが存在する場合、cl_opsconfig により、削除する前に確認するよう求めるプロンプトが表示されます。

代わりに、HACMP SMIT でもエラーを訂正できます。この場合、オンライン・プランニング・ワークシート・アプリケーションから生成された最終レポートには、初期構成が正確に示されません。

関連タスク:

190ページの『HTML 構成レポートの作成』構成レポートにより、クラスター構成の状態についての情報を HTML ファイルに記録できます。

関連資料:

189ページの『クラスター定義の妥当性検査』妥当性検査では、指定された情報の入力が完了し、名前が 32 文字までに制限されるなどのパラメーターの基準が満たされていることを確認します。


プランニング・ワークシート本書 PDF 版からプランニング・ワークシートを印刷してご利用ください。PDF 版では、それぞれのワークシートがページのトップから始まるように調整されています。ワークシートのコピーが 2 部以上必要になる場合もあります。

2 ノード・クラスター構成ワークシートこのワークシートは、2 ノード・クラスター構成アシスタントの入力を完了する目的で、必要な情報を記録するために使用します。


項目説明

ローカル・ノード

テークオーバー (リモート) ノード

テークオーバー・ノードへの通信パス


アプリケーション起動スクリプト

アプリケーション停止スクリプト

サービス IP ラベル

2 ノード・クラスター構成ワークシートの記入例

項目説明

ローカル・ノード nodea

テークオーバー (リモート) ノード nodeb

テークオーバー・ノードへの通信パス 10.11.12.13

アプリケーション・サーバー appsrv1

アプリケーション起動スクリプト /usr/es/sbin/cluster/utils/start_app1

アプリケーション停止スクリプト /usr/es/sbin/cluster/utils/stop_app1

サービス IP ラベル app1_svc

TCP/IP ネットワーク・ワークシートこのワークシートは、クラスターの TCP/IP ネットワーク・トポロジーを記録するために使用します。クラスターごとに 1 枚のワークシートに情報を記入してください。

ネットワーク名ネットワーク・タイプネットマスクノード名

IP エイリアスによる IPAT

IP エイリアスを使用するハートビートの IP アドレス・オフセット

TCP/IP ネットワーク・ワークシートの記入例

計画 205

ネットワーク名ネットワーク・タイプネットマスクノード名

IP エイリアスによる IPAT

IP エイリアスを使用するハートビートの IP アドレス・オフセット

ether1 イーサネット 255.255.255.0 clam、mussel、oyster 使用可能

token1 トークンリング 255.255.255.0 clam、mussel、oyster 使用可能

fddi1 FDDI 255.255.255.0 clam、mussel 使用不可

atm1 ATM 255.255.255.0 clam、mussel 非サポート

関連タスク:

69ページの『シリアル・ネットワーク・インターフェース・ワークシートの記入』シリアル・ネットワーク・インターフェース・ワークシートでは、クラスター内の各ノードに接続されるネットワーク・インターフェースを定義できます。

TCP/IP ネットワーク・インターフェース・ワークシートこのワークシートは、各ノードに接続された TCP/IP ネットワーク・インターフェース・カードを記録するために使用します。クラスターで定義されたノードごとに、個別のワークシートが必要です。ノードごとにワークシートを 1 枚ずつ印刷して、それぞれにノード名を記入してください。

IP ラベル/アドレス IP エイリアス

ネットワーク・インターフェース

ネットワーク名

インターフェースの機能 IP アドレスネットマスク

ハードウェア・アドレス

TCP/IP ネットワーク・インターフェース・ワークシートの記入例

IP ラベル/

アドレスIP エイリアス





nodea-en0 アンチ・コロケーション

(デフォルト)

len0 ether1 サービス 100.10.1.10 255.255.255.0 0x08005a7a7610

nodea-nsvc1 アンチ・コロケーション

(デフォルト)

en0 ether1 ブート 100.10.1.74 255.255.255.0


IP ラベル/

アドレスIP エイリアス





nodea-en1 アンチ・コロケーション

(デフォルト)

en1 ether1 ブート 100.10.11.11 255.255.255.0

nodea-tr0 コロケーション

tr0 token1 サービス 100.10.2.20 255.255.255.0 0x42005aa8b57b


(デフォルト)

tr0 token1 ブート 100.10.2.84 255.255.255.0

nodea-fi0 コロケーション

fi0 fddi1 サービス 100.10.3.30 255.255.255.0

nodea-svc コロケーション

css0 hps1 サービス


(デフォルト)

css0 hps1 ブート

nodea-at0 コロケーション

at0 atm1 サービス 100.10.7.10 255.255.255.0 0x0020481a396500


(デフォルト)

at0 atm1 ブート 100.10.7.74 255.255.255.0

Point-to-Point ネットワーク・ワークシートこのワークシートは、クラスターの Point-to-Point ネットワーク・トポロジーを記録するために使用します。クラスターごとに 1 枚のワークシートに情報を記入してください。

ネットワーク名ネットワーク・タイプノード名 Hdisk

RS232、ターゲット・モード SCSI、ターゲット・モード SSA、およびディスク・ハートビート・リンクは、TCP/IP プロトコルを使用しないため、ネットマスクや IP アドレスを必要としません。

計画 207

その他のデータ

Point-to-Point リンクの拡張に使用するデバイス (例えば、モデム番号やエクステンダー情報) のその他の情報を記録します。

_________________________________________________________________________

_________________________________________________________________________

_________________________________________________________________________

_________________________________________________________________________

Point-to-Point ネットワーク・ワークシートの記入例

ネットワーク名ネットワーク・タイプノード名 Hdisk

diskhb1 diskhb nodeb、nodec hdisk2

tmscsi1 ターゲット・モード SCSI nodea、nodeb ―

tmssa1 ターゲット・モード SSA nodea、nodeb ―

RS232、ターゲット・モード SCSI、ターゲット・モード SSA、およびディスク・ハートビート・リンクは、TCP/IP プロトコルを使用しないため、ネットマスクや IP アドレスを必要としません。


シリアル・リンクの拡張に使用するデバイス (例えば、モデム番号やエクステンダー情報) のその他の情報を記録します。

_________________________________________________________________________

_________________________________________________________________________

_________________________________________________________________________

_________________________________________________________________________

シリアル・ネットワーク・インターフェース・ワークシートこのワークシートは、各ノードに接続されたシリアル・ネットワーク・インターフェース・カードを記録するために使用します。クラスターで定義されたノードごとに、個別のワークシートが必要です。ノードごとに 1 枚のワークシートを印刷して、それぞれにノード名を記入してください。

スロット番号インターフェース名アダプター・ラベルネットワーク名ネットワーク属性アダプターの機能


シリアルサービス











非 IP ネットワークでは TCP/IP トラフィックは使用されません。したがって、ノード間でキープアライブおよび制御メッセージを維持するために、非サービス・アドレス、識別子 (IP アドレス)、およびインターフェース・ハードウェア・アドレスは必要ありません。

シリアル・ネットワーク・インターフェース・ワークシートの記入例


SS2 /dev/tty1 nodea_tty1 rs232a シリアルサービス

08 scsi2 nodea_tmscsi2 tmscsi1 シリアルサービス

01 tmssa1 nodea_tmssa1 tmssa1 シリアルサービス

ファイバー・チャネル・ディスク・ワークシートこのワークシートは、クラスターに含まれるファイバー・チャネル・ディスクに関する情報を記録するために使用します。それぞれのノードごとのワークシートに記入します。

ファイバー・チャネル・アダプターアダプターに関連付けられたディスク

ファイバー・チャネル・ディスク・ワークシートの記入例

計画 209

ファイバー・チャネル・アダプターアダプターに関連付けられたディスク

fcs0 hdisk2

hdisk3

hdisk4

hdisk5

hdisk6

共用 SCSI ディスク・ワークシートこのワークシートは、クラスターの共用 SCSI ディスク構成を記録するために使用します。共用バスごとに個別のワークシートに記入してください。

項目ノード A ノード B ノード C ノード D

クラスター名

ノード名

スロット番号

論理名

アダプター

第 1 共用ドライブ






共用ドライブ

項目説明ノード A ノード B ノード C ノード D

ディスク

第 1

第 2

第 3

第 4

第 5

第 6

関連タスク:

92ページの『共用 SCSI ディスク・ワークシートの記入』それぞれの共用 SCSI ディスク・アレイごとに、共用 SCSI ディスク・ワークシートに情報を記入します。

共用 IBM SCSI ディスク・アレイ・ワークシートこのワークシートは、クラスターの共用 IBM SCSI ディスク・アレイ構成を記録するために使用します。共用 SCSI バスごとに個別のワークシートに記入してください。


表 1. 共用 IBM SCSI ディスク・アレイ・ワークシート項目ノード A ノード B ノード C ノード D

ノード名

スロット番号

論理名

アダプター

共用ドライブ

サイズ

共用 IBM SCSI ディスク・アレイ・ワークシートの記入例

共用 SCSI ディスク・アレイにごとに、個別のワークシートに記入してください。

表 2. 共用 IBM SCSI ディスク・アレイ・ワークシートの記入例項目ノード A ノード B ノード C ノード D

ノード名 nodea nodeb

スロット番号 2 2

論理名 scsi1 scsi1

アダプター 14 15

共用ドライブ

サイズ RAID レベル

2GB 5

2GB 3

2GB 5

2GB 5

関連タスク:

93ページの『共用 SCSI ディスク・アレイ・ワークシートの記入』それぞれの共用 SCSI ディスク・アレイごとに、共用 SCSI ディスク・アレイ・ワークシートに情報を記入します。

共用 IBM SCSI 磁気テープ・ドライブ・ワークシートこのワークシートは、クラスターの共用 IBM SCSI ディスク・アレイ構成を記録するために使用します。共用 SCSI バスごとに個別のワークシートに記入してください。

注: 共用 SCSI 磁気テープ・ドライブごとに個別のワークシートに記入してください。

計画 211

項目説明説明

ホストおよびアダプターの情報

ノード A ノード B

ノード名

スロット番号

論理名

共用バスの SCSI 磁気テープ・ドライブ ID


アダプター

磁気テープ・ドライブ

共用ドライブ論理デバイス名


共用 IBM SCSI 磁気テープ・ドライブ・ワークシートの記入例

このワークシートの記入例は、共用 SCSI 磁気テープ・ドライブ構成を示しています。

項目説明説明




スロット番号 2 2

論理名 scsi1 scsi1

共用バスの SCSI 磁気テープ・ドライブ ID


アダプター 5 6

磁気テープ・ドライブ 2



5.0 GB 8mm 磁気テープ・ドライブ 10 GB /dev/rmt0 /dev/rmt0

共用 IBM Fibre 磁気テープ・ドライブ・ワークシートこのワークシートは、クラスターの共用 IBM Fibre 磁気テープ・ドライブ構成を記録するために使用します。共用テープ・ドライブごとに個別のワークシートに記入してください。


項目説明説明



ノード名

スロット番号

論理名

共用バスのファイバー・デバイス ID


SCSI ID

LUN ID

World Wide Name


磁気テープ・ドライブ名ノード A ノード B

共用 IBM Fibre 磁気テープ・ドライブ・ワークシートの記入例

このワークシートの記入例は、共用 Fibre 磁気テープ・ドライブの構成を示しています (磁気テープ・ドライブ構成の完了後に記録されています)。

項目説明説明




スロット番号 1P-18 04-02

論理名 fcs0 fcs0

共用バスのファイバー・デバイス ID


SCSI ID scsi_id 0x26 scsi_id 0x26

LUN ID lun_id 0x0 lun_id 0x0

World Wide Name ww_name 0x5005076300404576 ww_name 0x5005076300404576


磁気テープ・ドライブ名ノード A ノード B

IBM 3590 /dev/rmt0 /dev/rmt0

共用 IBM シリアル・ストレージ・アーキテクチャー・ディスク・サブシステム・ワークシートこのワークシートは、クラスターの IBM 7131-405 または 7133 SSA 共用ディスク構成を記録するために使用します。

計画 213


ノード名

SSA アダプター・ラベル

スロット番号

デュアル・ポート番号

SSA 論理ディスク・ドライブ

論理デバイス名



共用 IBM シリアル・ストレージ・アーキテクチャー・ディスク・サブシステム・ワークシートの記入例


ノード名 clam mussel

SSA アダプター・ラベル

ha1、ha2 ha1、ha2

スロット番号 2, 4 2, 4

デュアル・ポート番号 a1、a2 a1、a2

SSA 論理ディスク・ドライブ ________________________________________________________________


ノード A ノード B ノード C ノード D ノード A

hdisk2 hdisk2

hdisk3 hdisk3

hdisk4 hdisk4

hdisk5 hdisk5



ノード A ノード B ノード C ノード D ノード A

hdisk2 hdisk2

hdisk3 hdisk3

hdisk4 hdisk4

hdisk5 hdisk5

非共用ボリューム・グループ・ワークシート (非コンカレント・アクセス)このワークシートは、非コンカレント・アクセス構成でノードの内部ディスク上にあるボリューム・グループとファイルシステムを記録するために使用します。ボリューム・グループごとに、個別のワークシートが必要です。各ボリューム・グループ用のワークシートを印刷して、それぞれにノード名を記入してください。


項目説明

ノード名

ボリューム・グループ名

物理ボリューム

論理ボリューム名

論理区画のコピー数

別の物理ボリュームに配置

ファイルシステム・マウント・ポイント

サイズ (512 バイト・ブロック単位)






非共用ボリューム・グループ・ワークシートの記入例 (非コンカレント・アクセス)

項目説明

ノード名 clam

ボリューム・グループ名 localvg

物理ボリューム hdisk1

論理ボリューム名 locallv

論理区画のコピー数 1

別の物理ボリュームに配置いいえ

ファイルシステム・マウント・ポイント localfs

サイズ (512 バイト・ブロック単位) 100000






共用ボリューム・グループおよびファイルシステム・ワークシート (非コンカレント・アクセス)このワークシートは、非コンカレント・アクセス構成での共用ボリューム・グループおよびファイルシステムを記録するために使用します。共用ボリューム・グループごとに、個別のワークシートが必要です。各ボリューム・グループ用のワークシートを印刷して、それぞれにボリューム・グループを共用するノードの名前を記入してください。

計画 215


ノード名

共用ボリューム・グループ名

メジャー番号

ログ論理ボリューム名


サイト間 LVM ミラーリング






サイト間 LVM ミラーリングが使用可能







共用ボリューム・グループおよびファイルシステム・ワークシート (非コンカレント・アクセス) の記入例


ノード名 trout guppy

共用ボリューム・グループ名 bassvg

メジャー番号 24 24

ログ論理ボリューム名 bassloglv

物理ボリューム hdisk6 hdisk6

hdisk7 hdisk7

hdisk13 hdisk16

サイト間 LVM ミラーリング site1 site2

論理ボリューム名 basslv


別の物理ボリュームに配置はい

ファイルシステム・マウント・ポイント /bassfs


サイト間 LVM ミラーリングが使用可能はい








NFS エクスポートされるファイルシステムまたはディレクトリー・ワークシート (非コンカレント・アクセス)このワークシートは、非コンカレント・アクセス構成のノード単位で NFS によりエクスポートされるファイルシステムとディレクトリーを記録するために使用します。クラスターで定義されたノードごとに、個別のワークシートが必要です。ノードごとにワークシートを 1 枚ずつ印刷して、それぞれにノード名を記入してください。

リソース・グループ

NFS マウント用ネットワーク

IP 構成の前にファイルシステムをマウントする

注: エクスポート・オプションには、読み取り専用、root アクセスなどがあります。すべてのエクスポート・オプションのリストについては、exports マニュアル・ページを参照してください。

エクスポートするファイルシステムまたはディレクトリー (NFSv2/3)

エクスポート・オプション

エクスポートするファイルシステムまたはディレクトリー (NFSv4)






安定ストレージのパス (NFSv4)

NFS エクスポートされるファイルシステムまたはディレクトリー・ワークシート (非コンカレント・アクセス) の記入例

リソース・グループ rg1

NFS マウント用ネットワーク tr1


はい

注: エクスポート・オプションには、読み取り専用、root アクセスなどがあります。すべてのエクスポート・オプションのリストについては、exports マニュアル・ページを参照してください。


/fs1 /fs5


計画 217


クライアント・アクセス: client1

root アクセス: ノード 1、ノード 2

モード: 読み取り/書き込み


/fs5 /fs6


クライアント・アクセス: client 2

root アクセス: ノード 1、ノード 2

モード: 読み取り専用

安定ストレージのパス (NFSv4): /mnt_ss/

非共用ボリューム・グループ・ワークシート (コンカレント・アクセス)このワークシートは、コンカレント・アクセス構成でノードの内部ディスク上にあるボリューム・グループとファイルシステムを記録するために使用します。ボリューム・グループごとに、個別のワークシートが必要です。各ボリューム・グループ用のワークシートを印刷して、それぞれにノード名を記入してください。

項目説明

ノード名

ボリューム・グループ名












非共用ボリューム・グループ・ワークシートの記入例 (コンカレント・アクセス)


項目説明

ノード名 clam

ボリューム・グループ名 localvg

物理ボリューム hdisk1

論理ボリューム名 locallv


別の物理ボリュームに配置いいえ

ファイルシステム・マウント・ポイント /localfs







関連タスク:

122ページの『非共用ボリューム・グループ・ワークシート (コンカレント・アクセス) の記入』各ノードごとに、ローカル (非共用) ディスクに配置されているそれぞれのボリューム・グループについて、非共用ボリューム・グループ・ワークシート (コンカレント・アクセス) に情報を記入します。

共用ボリューム・グループおよびファイルシステム・ワークシート (コンカレント・アクセス)このワークシートは、コンカレント・アクセス構成での共用ボリューム・グループおよびファイルシステムを記録するために使用します。共用ボリューム・グループごとに、個別のワークシートが必要です。各ボリューム・グループ用のワークシートを印刷して、それぞれにボリューム・グループを共用するノードの名前を記入してください。


ノード名

共用ボリューム・グループ名









計画 219







共用ボリューム・グループおよびファイルシステム・ワークシート (コンカレント・アクセス) の記入例


ノード名 trout guppy

共用ボリューム・グループ名 bassvg

物理ボリューム hdisk6 hdisk6

hdisk7 hdisk7

hdisk13 hdisk16

論理ボリューム名 basslv


別の物理ボリュームに配置はい

サイズ (512 バイト・ブロック単位) /bassfs









アプリケーション・ワークシートこのワークシートは、クラスター内のアプリケーションに関する情報を記録するために使用します。

表 3. アプリケーション・ワークシート

項目説明ディレクトリーまたはパスファイルシステムロケーション共用

アプリケーション名

実行可能ファイル

構成ファイル

データ・ファイルまたはデバイス

ログ・ファイルまたはデバイス


表 3. アプリケーション・ワークシート (続き)

項目説明ディレクトリーまたはパスファイルシステムロケーション共用

クラスター名

フォールオーバー方針 (P = 1 次、T =

テークオーバー)

ノード

方針

通常の始動コマンドおよび手順

検証コマンドおよび手順

ノード

通常の停止コマンドおよび手順

検証コマンドおよび手順

Fast Connect ワークシートこのワークシートは、Fast Connect リソースを記録するために使用します。

リソース・グループノード Fast Connect リソース

Fast Connect ワークシートの記入例

計画 221

リソース・グループノード Fast Connect リソース

rg1 ノード A、ノード C FS1%f%/smbtest/fs1

LPT1%p%printq

通信リンク (SNA-over-LAN) ワークシートこのワークシートは、クラスター内の SNA-over-LAN 通信リンクに関する情報を記録するために使用します。

項目説明

クラスター名


ノード

通信リンク名

DLC 名

ポート

リンク・ステーション

アプリケーション・サービス・ファイル


ノード

通信リンク名

DLC 名

ポート



通信リンク (SNA-Over-LAN) ワークシートの記入例

項目説明

クラスター名 cluster1


ノード nodeA、nodeB

通信リンク名 snalink1

DLC 名 snaprofile1

ポート snaport1

リンク・ステーション snastation1

アプリケーション・サービス・ファイル /tmp/service1.sh


ノード

通信リンク名

DLC 名

ポート



通信リンク (X.25) ワークシートこのワークシートは、クラスター内の X.25 通信リンクに関する情報を記録するために使用します。


項目説明


ノード

通信リンク名

ポート

アドレスまたは NUA

ネットワーク ID

国別コード

アダプター名


通信リンク (X.25) ワークシートの記入例

項目説明

リソース・グループ cascrg1

ノード nodeA、nodeB

通信リンク名 x25link1

ポート sx25a2

アドレスまたは NUA 241

ネットワーク ID 5 (空欄でもかまいません)

国別コード (ローカル国別コードには、システム・デフォルトが自動的に使用されます)

アダプター名 adapterAsx25a2、adapterBsx25a2


/tmp/startx25.sh

通信リンク (SNA-Over-X.25) ワークシートこのワークシートは、クラスター内の SNA-Over-X.25 通信リンクに関する情報を記録するために使用します。

項目説明


ノード

通信リンク名

X.25 ポート

X.25 アドレスまたは NUA

X.25 ネットワーク ID

X.25 国別コード

X.25 アダプター名

SNA DLC

SNA ポート

SNA リンク・ステーション


通信リンク (SNA-Over-X.25) ワークシートの記入例

計画 223

項目説明

リソース・グループ casc_rg2

ノード nodeA、nodeB、nodeC

通信リンク名 snax25link1

X.25 ポート sx25a0

X.25 アドレスまたは NUA 241

X.25 ネットワーク ID 5 (空欄でもかまいません)

X.25 国別コード (ローカル国別コードには、システム・デフォルトが自動的に使用されます)

X.25 アダプター名 adapterAsx25a0、adapterBsx25a0、adapterCsx25a0

SNA DLC dlcprofile2

SNA ポート snaport2

SNA リンク・ステーション snastation2


/tmp/snax25start.sh

アプリケーション・サーバー・ワークシートこのワークシートは、クラスター内のアプリケーション・サーバーに関する情報を記録するために使用します。

項目説明

クラスター名

注: ユーザー定義スクリプトには、すべて絶対パス名を使用します。

サーバー名

起動スクリプト

停止スクリプト

サーバー名



サーバー名



サーバー名



アプリケーション・サーバー・ワークシートの記入例


項目説明


注: ユーザー定義スクリプトには、すべて絶対パス名を使用します。

サーバー名 mydemo

起動スクリプト /usr/es/sbin/cluster/utils/start_mydemo

停止スクリプト /usr/es/sbin/cluster/utils/stop_mydemo

サーバー名



サーバー名



サーバー名



アプリケーション・モニター・ワークシート (プロセス・モニター)このワークシートは、アプリケーションに対するプロセス・モニターの構成についての情報を記録するために使用します。

項目説明

クラスター名

アプリケーション・サーバー名

アプリケーションをプロセス・モニターでモニターできますか?* はい / いいえ (「いいえ」の場合、カスタム・ワークシートに進みます)

モニターするプロセス

プロセス所有者

インスタンス・カウント

安定化間隔

再始動カウント

再始動間隔

アプリケーション障害時のアクション

通知メソッド

クリーンアップ・メソッド

再始動メソッド

アプリケーション・モニター・ワークシートの記入例 (プロセス・モニター)

計画 225

項目説明


アプリケーション・サーバー名 mydemo

アプリケーションをプロセス・モニターでモニターできますか?* はい

モニターするプロセス demo

プロセス所有者 root

インスタンス・カウント 1

安定化間隔 30

再始動カウント 3

再始動間隔 95

アプリケーション障害時のアクションフォールオーバー

通知メソッド /usr/es/sbin/cluster/events/notify_demo

クリーンアップ・メソッド /usr/es/sbin/cluster/utils//events/stop_demo

再始動メソッド /usr/es/sbin/cluster/utils/events/start_demo

アプリケーション・モニター・ワークシート (ユーザー定義モニター)このワークシートは、アプリケーションに対するユーザー定義モニター・メソッドの構成についての情報を記録するために使用します。

項目説明

クラスター名

アプリケーション・サーバー名

モニター・メソッド

モニター間隔

モニターを停止するシグナル

安定化間隔

再始動カウント

再始動間隔

アプリケーション障害時のアクション

通知メソッド

クリーンアップ・メソッド

再始動メソッド

アプリケーション・モニター・ワークシートの記入例 (ユーザー定義モニター)

項目説明


アプリケーション・サーバー名 mydemo

モニター・メソッド /usr/es/sbin/cluster/events/utils/monitor_mydemo

モニター間隔 60

モニターを停止するシグナル 9

安定化間隔 30

再始動カウント 3

再始動間隔 280

アプリケーション障害時のアクション通知

通知メソッド /usr/es/sbin/cluster/events/utils/notify_mydemo


項目説明

クリーンアップ・メソッド /usr/es/sbin/cluster/events/utils/stop_mydemo

再始動メソッド /usr/es/sbin/cluster/events/utils/start_mydemo

リソース・グループ・ワークシートこのワークシートは、クラスターのリソース・グループを記録するために使用します。

項目説明

リソース・グループ名

参加ノード名

サイト間管理ポリシー

始動ポリシー


フォールバック・ポリシー

遅延フォールバック・タイマー

整定時間

ランタイム・ポリシー

動的ノード優先順位ポリシー

処理順序 (並列、順次、またはカスタマイズ)

サービス IP ラベル

ファイルシステム

ファイルシステムの整合性検査

ファイルシステムの回復メソッド

エクスポートするファイルシステムまたはディレクトリー

NFS マウントするファイルシステムまたはディレクトリー(NFSv2/3)

NFS マウントするファイルシステムまたはディレクトリー(NFSv4)

安定ストレージのパス (NFSv4)

NFS マウント用ネットワーク

ボリューム・グループ

コンカレント・ボリューム・グループ

ロー・ディスク PVID

Fast Connect サービス

テープ・リソース


高可用性通信リンク

1 次ワークロード・マネージャー・クラス

2 次 WLM クラス (始動ポリシー「Online Using Node

Distribution Policy (ノード配布ポリシーを使用してオンライン)」がない非コンカレント・リソース・グループのみ)


ボリューム・グループの自動インポート

ディスク・フェンシングをアクティブにする


リソース・グループ・ワークシートの記入例

計画 227

項目説明

リソース・グループ名 rotgrp1

参加ノード名無視

サイト間管理ポリシー clam、mussel、oyster

始動ポリシーノード配布ポリシーを使用してオンライン

フォールオーバー・ポリシー次の優先順位のノードにフォールオーバー

フォールバック・ポリシーフォールバックしない

遅延フォールバック・タイマー

整定時間

ランタイム・ポリシー

動的ノード優先順位ポリシー

処理順序 (並列、順次、またはカスタマイズ)

サービス IP ラベル myname_svc

ファイルシステム /sharedfs1 /sharedvg2 /myfs

ファイルシステムの整合性検査 fsck

ファイルシステムの回復メソッド順次

エクスポートするファイルシステムまたはディレクトリー

NFS マウントするファイルシステムまたはディレクトリー(NFSv2/3)

/sharedvg1

NFS マウントするファイルシステムまたはディレクトリー(NFSv4)

/sharedvg1 /sharedvg2

安定ストレージのパス (NFSv4) /myfs/stable_storage/

NFS マウント用ネットワーク ether1

ボリューム・グループ sharedvg

コンカレント・ボリューム・グループ

ロー・ディスク PVID

Fast Connect サービス

テープ・リソース

アプリケーション・サーバー mydemo

高可用性通信リンク

1 次ワークロード・マネージャー・クラス

2 次 WLM クラス (始動ポリシー「Online Using Node

Distribution Policy (ノード配布ポリシーを使用してオンライン)」がない非コンカレント・リソース・グループのみ)


ボリューム・グループの自動インポートいいえ

ディスク・フェンシングをアクティブにするいいえ

IP 構成の前にファイルシステムをマウントするいいえ

クラスター・イベント・ワークシートこのワークシートは、HACMP クラスター・イベント用に計画されているカスタマイズを記録するために使用します。

クラスター・イベント・メソッド、通知コマンド、および回復コマンドには、すべて絶対パス名を使用します。


項目説明

クラスター名

クラスター・イベントの説明

クラスター・イベント・メソッド

クラスター・イベント名

イベント・コマンド

通知コマンド

Remote Notification Message Text (リモート通知メッセージのテキスト)

Remote Notification Message Location (リモート通知メッセージの位置)

イベント前処理コマンド

イベント後処理コマンド

イベント回復コマンド

回復カウンター

警告までの時間



通知コマンド








クラスター・イベント・ワークシートの記入例

ユーザー定義スクリプトには、すべて絶対パス名を使用します。

項目説明

クラスター名 bivalves

クラスター・イベントの説明

クラスター・イベント・メソッド

クラスター・イベント名 node_down_complete


通知コマンド




イベント後処理コマンド /usr/local/wakeup



計画 229

項目説明




通知コマンド








クラスター・サイト・ワークシートこのワークシートは、計画済みのクラスターのサイトを記録するために使用します。

項目説明

サイト名

サイトのクラスター・ノード

For Sites (サイト情報)

サイトの優位性

Site Backup Communication Method (サイト・バックアップ通信方式)

クラスター・サイト・ワークシートの記入例

項目説明

サイト名 Site_1

サイトのクラスター・ノード

nodea

nodeb

For Sites (サイト情報)

サイトの優位性


項目説明

Site Backup Communication Method (サイト・バックアップ通信方式)

HACMP ファイル・コレクション・ワークシートこのワークシートは、計画済みの HACMP クラスター・ファイル・コレクションを記録するために使用します。

項目説明

クラスター名

ファイル・コレクション名

ファイル・コレクションの説明

Propagate Files before verification (検証前にファイルを伝搬する)

ファイルを自動的に伝搬する

Files to include in this collection (このコレクションに含めるファイル)

Automatic check time limit (自動検査の制限時間)

HACMP ファイル・コレクション・ワークシートの記入例

項目説明

クラスター名 MyCluster

ファイル・コレクション名 Apache_Files

ファイル・コレクションの説明 Apache 構成ファイル

Propagate Files before verification (検証前にファイルを伝搬する)

はい

ファイルを自動的に伝搬するはい

Files to include in this collection (このコレクションに含めるファイル)

/usr/local/apache/conf/httpd.conf /usr/local/apache/conf/ss/.conf

/usr/local/apache/conf/mime_types

Automatic check time limit (自動検査の制限時間) 30 分

WebSMIT ユーザー・プランニング・ワークシートこのワークシートは、WebSMIT 環境でユーザーを計画する場合に使用します。インストールしたWebSMIT サーバーごとにワークシートを印刷し、それぞれのワークシートにクラスター名を入力します。

User Login

(ユーザー・ログイン)

Access Groups(s)

(アクセス・グループ)

Cluster Label(s)

(クラスター・ラベル)

Cluster ID(s)

(クラスター ID)

計画 231

User Login


Access Groups(s)


Cluster Label(s)


Cluster ID(s)


WebSMIT ユーザー・プランニング・ワークシートの記入例

User Login


Access Groups(s)


Cluster Label(s)


Cluster ID(s)


websmit_1 access1

access2

cluster1

cluster2

2334234986

2334234987

websmit_2 access1 cluster1 2334234986


websmit_4 access1

access2

access3

access5

cluster1

cluster2

cluster3

cluster4

cluster5

cluster6

2334234986

2334234987

2334234988

2334234989

2334234990

2334234991

websmit_5 access1

access2

cluster1

cluster2

2334234986

2334234987


WebSMIT クラスター・プランニング・ワークシートこのワークシートは、WebSMIT 環境でクラスターを計画する場合に使用します。インスタンスごとにワークシートを印刷し、それぞれのワークシートにクラスター名を入力します。

Cluster Label


Cluster ID


Cluster Host

(クラスター・ホスト)

Access Group(s)



Cluster Label


Cluster ID


Cluster Host


Access Group(s)


WebSMIT クラスター・プランニング・ワークシートの記入例

Cluster Label


Cluster ID


Cluster Host


Access Group(s)


cluster1 2334234986 [email protected] access1



cluster4 2334234989 [email protected]


cluster6 2334234991 [email protected]

アプリケーションと HACMPこのトピックでは、HACMP 環境でアプリケーションの高可用性を維持するために、注意すべき主要な問題について説明します。

HACMP では、異なるアプリケーションを含むリソース・グループ間の依存関係を設定して、多層アプリケーションを使用するクラスターを構成できます。このトピックでは、リソース・グループの依存関係と、この依存関係を利用して依存アプリケーションの高可用性を維持する方法について説明します。

関連資料:


アプリケーションと HACMP の概説クラスターの高可用性を維持するには、必要なハードウェアとソフトウェアについて理解するだけでなく、HACMP 環境を計画する際にアプリケーションについても考慮する必要があります。クラスター化の最終目標は、どのような Single Point of Failure があっても、重要なアプリケーションを使用可能にしておくことです。この目標を達成するには、HACMP 環境下で回復可能にするアプリケーションの各側面について考慮することが重要です。

HACMP 環境で適切な回復を実現するために、アプリケーションで満たす必要がある厳しい要件はほとんどありません。多くの場合、潜在的な問題を回避できる、単純で適切な方法があります。ここでは、いくつかの必須の特性とヒントを示しておきます。これらの特性やヒントは、すべての HACMP 環境で対処すべきキー・ポイントに従ってまとめています。このトピックでは、アプリケーションに関する次の考慮事項について説明します。

v 自動化ユーザーの操作を必要とせずに、アプリケーションを起動および停止できるようにします。

v 依存関係アプリケーションに影響を与える、HACMP 外部の要素について理解します。

v 干渉アプリケーション自体が HACMP の機能を妨害する可能性があることを理解します。

計画 233

v 堅固性強力で安定したアプリケーションを選択します。

v インプリメンテーション適切なスクリプト、ファイル・ロケーション、および cron スケジュールを使用します。

アプリケーション・モニターを追加して、アプリケーションの始動に関する問題を検出してください。「Startup Monitoring (始動時にモニター)」モードのアプリケーション・モニターは、指定された安定化間隔内でアプリケーション・サーバーが正常に始動することを確認し、安定化期間が経過したあとに終了します。

SMIT パネルから「Manage HACMP Services (HACMP サービスの管理)」>「Start Cluster Services (クラスター・サービスの始動)」のオプションを選択することで、アプリケーションを停止することなくノード上で HACMP クラスター・サービスを開始できます。HACMP は、開始時にアプリケーション始動スクリプトと構成済みアプリケーション・モニターを使用して、実行中のアプリケーションに関する情報を取得するとともに、別のアプリケーション・インスタンスを開始しないようにします。

同様に、HACMP クラスター・サービスを停止する一方で、アプリケーションをノード上で引き続き実行することができます。停止されて UNMANAGED 状態に設定されたノードがクラスターに再結合された場合は、ユーザーが HACMP リソース・グループ・コマンドを実行してリソース・グループを別の状態 (例えば、アクティブ・ノード上でオンライン) に切り替えた場合を除いて、リソースの状態は同じであると想定されます。

アプリケーションの自動化: 手操作による介入を最小限に抑えるアプリケーションを HACMP 環境で適切に機能させるために重要な要件は、手動による操作を必要とせずにアプリケーションを始動および停止できることです。

アプリケーション起動スクリプト

アプリケーションを始動する起動スクリプトを作成します。この起動スクリプトは、アプリケーションを適切に始動するために必要な「クリーンアップ」や「準備」の処理を実行する必要があるとともに、始動する必要のあるアプリケーション・インスタンスの数を適切に管理する必要があります。アプリケーション・サーバーがリソース・グループに追加されると、HACMP はこのスクリプトを呼び出して、リソース・グループの処理の一部としてこのアプリケーションをオンライン状態にします。起動スクリプトはクラスター・デーモンによって呼び出されるので、対話のためのオプションは存在しません。また、HACMP のフォールオーバーが発生すると、回復プロセスではこのスクリプトが呼び出され、スタンバイ・ノード上でアプリケーションをオンライン状態にします。このことは、完全に自動化された回復を可能にするとともに、必要なクリーンアップや準備の処理をこのスクリプトに組み込む必要がある理由でもあります。

HACMP は、この起動スクリプトを「root」ユーザーとして呼び出します。アプリケーションを始動するために、別のユーザーに変更しなければならない場合もあります。これは、su コマンドで実行できます。また、バックグラウンドで開始するコマンドや、シェルの終了時に停止する可能性のあるコマンドでは、nohup の実行が必要となる場合があります。

例えば、HACMP クラスター・ノードが、Network Information Service (NIS) 環境のクライアントとなる場合があります。このとき、su コマンドを使用してユーザー ID を変更する必要がある場合は、常に NIS

マスターへの経路が必要です。経路が存在しないときに su を実行すると、アプリケーション・スクリプトはハングします。これを回避するには、HACMP クラスター・ノードが NIS スレーブになれるようにします。これにより、クラスター・ノードは独自の NIS マップ・ファイルにアクセスして、ユーザー ID の妥当性を検査できます。


起動スクリプトでは、必要なリソースやプロセスの存在も確認するようにします。これによって、アプリケーションを正しく始動できます。必要なリソースを使用できない場合は、管理チームへメッセージを送信し、問題を修正してアプリケーションを再始動できます。

起動スクリプトは、アプリケーションの 1 つ目のインスタンスがすでに実行されているかどうかを確認して、複数のインスタンスが必要な場合を除いて、2 つ目のインスタンスを始動しないような内容で作成する必要があります。1 次ノードで障害が発生した後に起動スクリプトが実行されることがあります。アプリケーションを再始動するには、バックアップ・ノード上で回復アクションが必要となる場合があります。これは、データベース・アプリケーションでは一般的です。この場合も、管理者による操作を必要とせずに回復を実行できなければなりません。

アプリケーション停止スクリプト

アプリケーション停止スクリプトで最も重要な点は、アプリケーションを完全に停止することです。アプリケーションの停止に失敗すると、HACMP がバックアップ・ノードによるリソースのテークオーバーを正しく完了できなくなる場合があります。停止中は、NIS や su コマンドなど、起動スクリプトの場合と同じ注意事項を考慮する必要があります。

アプリケーション停止スクリプトでは、処理を段階的に実行します。第 1 段階では、クラスター・サービスの停止とリソース・グループのオフライン化を試行する必要があります。プロセスが終了しない場合は、第 2 段階として、すべての処理が強制的に停止されるようにします。最後の第 3 段階では、アプリケーションを完全に終了させるために必要なステップをループで繰り返します。

アプリケーションが正常に停止したときに、アプリケーション停止スクリプトが必ず値 0 で終了するようにしてください。特に、アプリケーションがすでに停止しているときに停止スクリプトを実行するとどのようなことが起きるか調べてください。この場合にも、スクリプトは 0 で終了する必要があります。停止スクリプトが別の値で終了した場合は、アプリケーションは障害状態の可能性はあるがまだ稼働していることが HACMP に通知されます。そのため、event_error イベントが実行され、クラスターはエラー状態になります。この検査は、クラスターが正しく機能していないことを管理者に警告します。

デフォルトでは、HACMP はイベントの処理が完了するのを 360 秒待機します。クラスターが再構成に長時間を要したことを示すメッセージは、クラスターが再構成を完了して安定状態に戻るまで表示されます。この警告は、スクリプトがハングし、手動による介入を必要とすることを示している場合もあります。その可能性がある場合は、HACMP を停止する前に、手動でアプリケーションを停止できます。

config_too_long イベントが呼び出されるまでの時間を変更できます。

アプリケーション開始/停止スクリプトおよび従属リソース・グループ

HACMP では従属リソース・グループがサポートされているので、次の依存関係を構成できます。

v リソース・グループ間の 3 つのレベルの依存関係。例えば、ノード A がノード B に依存し、ノードB がノード C に依存するような構成です。HACMP では、循環した依存関係は構成できません。

v 子 (依存) リソース・グループをノードでアクティブ化する前に、クラスターの任意のノードで親リソース・グループをオンラインにする必要がある依存関係。

2 つのアプリケーションを同じノードで実行する必要がある場合は、どちらのアプリケーションも同じリソース・グループに存在している必要があります。

子リソース・グループに、親リソース・グループのリソースに依存するアプリケーションが含まれている場合、フォールオーバー条件が発生して親リソース・グループが別のノードにフォールオーバーすると、子リソース・グループは一時的に停止し、自動的に再始動されます。同様に、子リソース・グループがコンカレ

計画 235

ントの場合も、HACMP は、子リソース・グループをすべてのノード上で一時的にオフラインにして、使用可能なすべてのノード上でオンラインに戻します。親リソース・グループのフォールオーバーが失敗すると、親リソース・グループと子リソース・グループは両方ともエラー状態になります。

子リソース・グループが一時的に停止して再始動されるとき、このリソース・グループに属しているアプリケーションも停止および再始動される点に注意してください。したがって、アプリケーションの停止および再始動プロセスで、データ損失の可能性を最小限に抑えるには、アプリケーション・サーバー・スクリプトをカスタマイズして、アプリケーションの停止プロセス中はコミットされていないデータを一時的に共用ディスクに格納し、再始動プロセス中にアプリケーションに読み込み直すようにします。アプリケーションは停止したノードとは別のノード上で再始動される場合があるため、共用ディスクを使用することが重要です。

アプリケーション層に関する問題

多くの場合、アプリケーションは多層アーキテクチャーになっています (例えば、データベース層、アプリケーション層、およびクライアント層)。HACMP を使用して 1 つ以上の層の可用性を高める場合、アーキテクチャーのすべての層を考慮してください。

例えば、データベースで高い可用性が維持されているときにフォールオーバーが発生した場合は、アプリケーションのサービスを自動的に回復するために、より上位の層でアクションを実行するかどうかを検討します。そのような場合は、アプリケーション層またはクライアント層の停止と再始動が必要になります。これは、次の 2 つの方法のいずれかで簡単に実行できます。1 つは各層で clinfo を実行する方法で、もう 1

つはリモート実行コマンド (rsh、rexec、ssh など) を使用する方法です。

注: 方法によっては (~/.rhosts ファイルを使用する場合など)、セキュリティーに関するリスクが発生します。

従属リソース・グループの使用

多層アプリケーションを使用する複雑なクラスターを構成するために、親/子従属リソース・グループを使用できます。また、ロケーション依存関係の使用を考慮することもお勧めします。

Clinfo API の使用

clinfo は、クラスター情報デーモンです。 Clinfo API を使用してプログラムを作成し、フォールオーバーが正常に完了した後で、アプリケーションを停止および再始動する任意の層でこのプログラムを実行できます。この意味で、層 (アプリケーション) は「クラスター感知型」になり、クラスター内で発生するイベントに応答します。

イベント前処理および後処理スクリプトの使用

多層アーキテクチャーに関する問題を処理する別の方法として、クラスター・イベントに対してイベント前処理およびイベント後処理スクリプトを使用できます。これらのスクリプトは、リモート実行コマンド(rsh、rexec、ssh など) を呼び出して、アプリケーションを停止および再始動します。

関連概念:


関連資料:


240ページの『有効なスクリプトの作成』適切なアプリケーション起動スクリプトを作成することで、アプリケーションをオンラインにする際に問題が発生する可能性を低くすることもできます。


『アプリケーションの依存関係』従来、システム管理者は、リソース・グループおよびアプリケーションの順序付けを行うために、イベント前処理およびイベント後処理の処理スクリプト内にアプリケーション回復ロジックを作成する必要がありました。各クラスターは、すべてのクラスター・イベントのイベント前処理スクリプト、およびすべてのクラスター・イベントのイベント後処理スクリプトで構成されていました。

アプリケーションの依存関係従来、システム管理者は、リソース・グループおよびアプリケーションの順序付けを行うために、イベント前処理およびイベント後処理の処理スクリプト内にアプリケーション回復ロジックを作成する必要がありました。各クラスターは、すべてのクラスター・イベントのイベント前処理スクリプト、およびすべてのクラスター・イベントのイベント後処理スクリプトで構成されていました。

こうしたスクリプトは、全体を網羅する case ステートメントとすることができました。例えば、特定のノード上で特定のイベントにアクションを起こす場合、個々の case を編集し、イベント前処理スクリプトおよびイベント後処理スクリプトの必須コードを追加し、さらにスクリプトがすべてのノードで同じになっていることを確認する必要もあります。

要約すると、そのようなスクリプトのロジックは、クラスターの希望する動作をキャプチャーするものの、クラスター構成が変化すると、カスタマイズしにくく、後の保守はさらに難しくなります。

イベント前処理スクリプトやイベント後処理スクリプトを使用している場合や、クラスターでサポートされるアプリケーションの依存関係を確立するためにリソース・グループの処理順序を決定するなどの方法を使用している場合、これらの方法は不要であるか、かなり単純化できます。代わりに、クラスターのリソース・グループ間の依存関係を指定できます。

注: 多くの場合、アプリケーションはデータや IP アドレス以外にも依存します。HACMP 環境下でアプリケーションを正常に動作させるには、アプリケーションが正しく機能するために依存すべきでない要素を把握することが重要です。ここでは、依存関係に関する多数の主要事項について概説します。これらの依存関係は、HACMP とアプリケーション環境の外部からもたらされることがあります。それらは、互換性のない製品や、外部リソースの競合の場合もあります。アプリケーションだけでなく、企業内の潜在的な問題も配慮してください。

ローカルに接続されたデバイス

ローカルに接続されたデバイスにより、明らかな依存関係の問題が発生することがあります。フォールオーバー時に、これらのデバイスがスタンバイ・ノードに接続されておらず、スタンバイ・ノードからアクセス不能な場合は、アプリケーションは正しく実行されない可能性があります。これらの装置は、CD-ROM デバイス、磁気テープ装置、光ディスク・ジュークボックスなどです。アプリケーションが、これらのデバイスのいずれかに依存しているかどうか、およびこれらをクラスター・ノード間で共用できるかどうかを考慮します。

ハードコーディング

アプリケーションが特定のロケーションの特定のデバイスにハードコーディングされている場合は、潜在的な依存関係の問題が発生する可能性があります。例えば、コンソールは一般的に /dev/tty0 に割り当てられ

計画 237

ます。これは一般的ではありますが、決して保証されたものではありません。使用するアプリケーションがこれを想定している場合は、すべてのスタンバイ・ノードが同じ構成になるようにしてください。

ホスト名の依存関係

一部のアプリケーションは、AIX ホスト名に依存するように作成されています。それらのアプリケーションは、ライセンスの妥当性を検査し、ファイルシステムに名前を付けるためにコマンドを発行します。ホスト名は IP アドレス・ラベルではありません。ホスト名はノード固有のものであり、HACMP によってフェイルオーバーされません。アプリケーションに感知されないように、ホスト名を操作したりホスト名のエイリアスを使用することもできますが、HACMP によって制御されていない別のアプリケーションがそのホスト名に依存している場合は、問題が発生する可能性があります。

ソフトウェア・ライセンス

ソフトウェア・ライセンスに関する問題もあります。ソフトウェアが、特定の CPU ID に対してライセンス交付されている場合があります。そのようなアプリケーションを使用している場合は、ソフトウェアのフォールオーバーが正常に再始動しないことを認識することが重要です。この問題は、すべてのクラスター・ノードにソフトウェアのコピーを常駐させておくことによって回避できます。ご使用のアプリケーションが、特定の CPU ID に対してライセンス交付されたソフトウェアを使用しているかどうかを確認してください。

関連資料:


アプリケーションの干渉アプリケーションまたはアプリケーションの環境が、HACMP の正常な動作に干渉する場合があります。あるアプリケーションが 1 次ノードとスタンバイ・ノードの両方で正しく実行されているとします。ここで HACMP を始動すると、アプリケーションまたは環境との競合が発生し、それによって HACMP が正しく機能しなくなる場合があります。

IPX/SPX プロトコルを使用するソフトウェア

HACMP と、ネットワーク・インターフェースでソケットをバインドするソフトウェアの間で、競合が発生する場合があります。その一例が IPX/SPX プロトコルです。このプロトコルは、アクティブの場合、インターフェースをバインドし、HACMP がインターフェースを正しく管理できないようにします。特に、イーサネットとトークンリングの場合、このプロトコルはハードウェア・アドレス・テークオーバーが正しく完了するのを妨げます。HACMP ログに「device busy (デバイスを使用中)」という旨のメッセージが記録されます。ハードウェア・アドレス・テークオーバーを機能させるには、IPX/SPX を使用するソフトウェアを完全に停止するか、これらのソフトウェアの使用を中止する必要があります。

ネットワーク経路を操作する製品

また、ネットワーク経路を操作する製品も、HACMP が設計どおりに機能するのを妨げる可能性があります。それらの製品は、初期障害が発生したネットワークを介して 2 次パスを検出する可能性があります。これにより、HACMP が障害を正しく診断できず、適切な回復アクションを実行できなくなります。


AIX Fast Connect

AIX Fast Connect を使用してリソースを共用している場合は、特定のプロトコルとの競合の問題を低減し、手動での介入の必要性を軽減できます。このアプリケーションによって処理されるプロトコルでは、HACMP との統合により、簡単に可用性を高めることができます。

AIX Fast Connect ソフトウェアも同じように HACMP に統合されるので、高可用性リソースとして構成できます。AIX Fast Connect を使用すると、AIX ワークステーションと、Windows、DOS、および OS/2 の各オペレーティング・システムを実行している PC との間で、リソースを共用できます。 Fast Connect

は、NetBIOS over TCP/IP プロトコルをサポートしています。

関連概念:


関連資料:


アプリケーションの堅固性アプリケーションを正常に動作させる上で最も重要なことは、アプリケーションの健全性、または堅固さです。アプリケーションが断続的に不安定になったりクラッシュしたりする場合は、アプリケーションを高可用性環境に配置する前に、必ずそれらの問題を解決しておいてください。

HACMP 環境で使用されるアプリケーションは、基本的な安定性のほかに、その他の堅固性の特性を備えている必要があります。

ハードウェア障害後の正常な始動

HACMP で使用されるアプリケーションは、ハードウェア障害後に正常に再始動できる必要があります。HACMP に組み込む前に、アプリケーションのテストを実行してください。アプリケーションを高い負荷の下で実行し、ノードに障害を発生させてみます。ノードが使用可能になったあとに、アプリケーションが回復する方法を確認します。また、回復を完全に自動化できるかどうかも確認します。回復を完全に自動化できない場合、このアプリケーションは高可用性には適していない可能性があります。

実メモリー内容損失の回復

HACMP 環境下でアプリケーションを適切に機能させるためには、そのアプリケーションが実メモリーの内容の損失に対応できる必要があります。カーネルやプロセッサーの状態が失われても、回復できなければなりません。ノードに障害が発生すると、それらは失われます。また、アプリケーションは定期的に、ディスクにデータのチェックポイントを作成しなければなりません。このようにすることで、障害が発生した場合、アプリケーションは最初からすべてやり直すのではなく、最後にデータのチェックポイントを作成した場所を検出することができます。

アプリケーションのインプリメンテーション方針HACMP 環境にアプリケーションをインプリメントする計画では、アプリケーションのさまざまな面を考慮します。

計画 239

すなわち、始動する時間、障害後に再始動する時間、停止する時間などの特性を考慮してください。このセクションで説明するさまざまな領域 (スクリプト作成、ファイル・ストレージ、/etc/inittab ファイル、cron

スケジュールの問題など) に関する決定事項により、アプリケーションを正常にインプリメントできる確率が向上します。

有効なスクリプトの作成適切なアプリケーション起動スクリプトを作成することで、アプリケーションをオンラインにする際に問題が発生する可能性を低くすることもできます。

アプリケーションを始動する前に、起動スクリプトで前提条件を確認することが適切です。前提条件には、ファイルシステムへのアクセス、十分なページング・スペース、および空きファイルシステム・スペースが含まれます。これらの要件が満たされていない場合は、起動スクリプトを終了して、システム管理者に通知するコマンドを実行します。

データベースを始動するときに、同じクラスターに複数のインスタンスがあるかどうかを考慮することも重要です。存在する場合は、各ノードに適用できるインスタンスのみを始動します。特定のデータベース始動コマンドは、構成ファイルを読み取り、既知のすべてのデータベースを同時に始動します。これは、一部の環境では望ましい構成ではない場合があります。

ユーザー・スクリプト内で HACMP プロセスを強制終了しないように注意してください。ps コマンドの出力から、grep を使用して特定のパターンを検索する場合は、HACMP または RSCT プロセスにパターンが一致しないようにします。

ファイルの保管場所に関する考慮事項構成ファイルの配置場所を検討してください。構成ファイルは、共用ディスク上または各ノードの内部ディスク上に配置できます。共用ディスクに配置した場合は、ボリューム・グループがオンに変更されている任意のノードから構成ファイルにアクセス可能になります。これは、アプリケーションのすべての局面について該当します。特定のファイルは、共用ドライブに置く必要があります。これらのファイルには、データ、ログ、およびアプリケーションの実行で更新されるファイルすべてが含まれます。構成ファイルやアプリケーション・バイナリーなどのファイルは、どちらの場所に置いても構いません。

オプショナル・ファイルをどちらの場所に保管する場合でも、利点と欠点があります。各ノードの内部ディスクにファイルを保管すると、アプリケーションの複数のコピーを持つことになり、潜在的にアプリケーションの複数のライセンスが必要となります。また、それらのファイルを同期させておくために追加のコストと保守が必要になります。ただし、アプリケーションをアップグレードする必要がある場合に、クラスター全体の稼働を停止させる必要はありません。1 つのノードをアップグレードしている間、別のノードを稼働させておくことができます。その環境で最も適切に機能する方法が、「最良」の解決策です。

/etc/inittab および cron テーブルの問題に関する考慮事項/etc/inittab ファイルまたは cron テーブルから開始されたアプリケーション、またはアプリケーションで必要なリソースについても考慮します。

inittab は、システムのブート時にアプリケーションを開始します。アプリケーションを機能させるためにクラスター・リソースが必要な場合、それらのリソースは HACMP が始動するまで使用可能になりません。適切な方法は、すべての従属リソースがオンラインになってからアプリケーションを始動できるように、HACMP アプリケーション・サーバー機能を使用することです。この機能では、アプリケーションをリソースとして定義できます。

注: /etc/inittab では以下の条件が満たされていることが非常に重要です。

hacmp:2:once:/usr/es/sbin/cluster/etc/re.init "a"


v clinit エントリーおよび pst_clinit エントリーは実行レベル「2」の最後のエントリーでなければならない。

v clinit エントリーは pst_clinit エントリーの前になければならない。

v いずれの tty エントリーも「on」や「respawn」であってはならない。

これらのエントリーが適切でない場合は、HACMP を始動できません。

cron テーブルでは、テーブルに設定されたスケジュールとノードの日付設定に従って、ジョブが開始されます。その情報は、内部ディスク上で保守されているので、スタンバイ・ノードはその情報を共有できません。スタンバイ・ノードが必要なアクションを適切なタイミングで実行できるように、これらの cron テーブルを同期してください。また、1 次ノードとそのすべてのスタンバイ・ノードで、日付の設定を同じ値にする必要があります。

例: Oracle Database および SAP R/3ここでは 2 つの例から、Oracle Database と SAP R/3 アプリケーションを HACMP 環境で適切に動作させるための考慮事項について説明します。

例 1: Oracle Database

Oracle Database は、多くのデータベースと同様、HACMP でも適切に動作します。このアプリケーションは、障害を適切に処理する堅固なアプリケーションです。このアプリケーションは、フォールオーバーのあと、コミットされていないトランザクションをロールバックし、適時にサービスに復帰できます。ただし、HACMP で Oracle Database を使用する場合は、いくつかの注意点があります。

Oracle の始動

Oracle は、Oracle ユーザー ID によって始動される必要があります。したがって、起動スクリプトには「su - oracleuser」が含まれている必要があります。su を使用して、Oracle ユーザーのすべての特性を引き継ぎ、Oracle ユーザーのホーム・ディレクトリーで作業する必要があるため、ダッシュ (-) の指定が重要です。コマンドは、次のようになります。

su - oracleuser -c â€œ/apps/oracle/startup/dbstartâ€

dbstart や dbshut などのコマンドは、データベース・インスタンスを識別して始動する命令を /etc/oratabsファイルから読み込みます。場合によっては、インスタンスが別のノードに所有されているために、すべてのインスタンスを始動するのが適切でないときもあります。これは、2 つの Oracle インスタンスによる相互テークオーバーに見られます。oratabs ファイルは、通常は内部ディスクに配置されているため共用できません。適切な場合は、別の Oracle インスタンスを始動するほかの方法を検討してください。

Oracle の停止

Oracle の停止は、特に注意が必要なプロセスです。Oracle を完全に停止させるには、複数の方法があります。推奨される手順では、最初に正常終了でのシャットダウンをインプリメントし、次に少し強制的な即時シャットダウンを呼び出します。最後に、プロセス・テーブルをチェックするループを作成して、すべてのOracle プロセスを終了させます。

Oracle ファイルの保管場所

Oracle 製品のデータベースには、データ以外にもさまざまなファイルが含まれています。データと REDO

ログは、共用ディスク上に保管し、両方のノードが情報にアクセスできるようにする必要があります。ただし、Oracle のバイナリーと構成ファイルは、内部ディスクと共用ディスクのどちらに配置しても構いません。どの解決策が最良であるかは、使用している環境に合わせて考慮してください。

計画 241

例 2: SAP R/3、多層アプリケーション

SAP R/3 は、3 層アプリケーションです。このアプリケーションは、データベース層、アプリケーション層、およびクライアント層を備えています。多くの場合、高可用性を備えているのはデータベース層です。この場合、フォールオーバーが発生してデータベースが再始動されたときには、SAP アプリケーション層を停止してから再始動する必要があります。これは、次の 2 つの方法のいずれかで実行できます。

v リモート実行コマンドの使用 (rsh、rexec、ssh など)


v アプリケーション層のノードを「クラスター対応」にする。

リモート実行コマンドの使用

SAP アプリケーション層を停止してから始動する 1 番目の方法は、アプリケーション・ノードでリモート・コマンドを実行するスクリプトを作成する方法です。SAP のアプリケーション層は、いったん停止してから再始動します。これは、アプリケーション層内にあるすべてのノードについて行われます。リモート実行コマンドを使用するには、データベース・ノードがアプリケーション・ノードにアクセスする方法が必要になります。


アプリケーション層のノードを「クラスター対応」にする

アプリケーション層を停止および始動する 2 番目の方法は、アプリケーション層ノードを「クラスター対応」にすることです。つまり、アプリケーション層ノードは、クラスター化されたデータベースを認識して、フォールオーバーの発生時にこれを検知します。この機能は、アプリケーション層ノードを HACMP

のサーバーまたはクライアントにすることによってインプリメントできます。アプリケーション・ノードがサーバーの場合、そのノードは障害を示すため、データベース・ノードと同じクラスター・イベントを実行します。したがって、SAP アプリケーション層の停止と再始動を行うイベント前処理およびイベント後処理スクリプトを作成できます。アプリケーション・ノードが HACMP クライアントである場合は、クラスター情報デーモン (clinfo) により、データベースのフォールオーバーを SNMP で通知します。Clinfo API

を使用して SAP アプリケーション層を停止してから再始動するプログラムを作成できます。

clinfo の API について詳しくは、マニュアル「Programming Client Applications」を参照してください。


特記事項

本書は米国 IBM が提供する製品およびサービスについて作成したものです。この資料は IBM から他の言語で入手できる場合があります。ただし、その資料にアクセスするには、その言語の製品または製品バージョンを所有していなければならない場合があります。

本書に記載の製品、サービス、または機能が日本においては提供されていない場合があります。日本で利用可能な製品、サービス、および機能については、日本 IBM の営業担当員にお尋ねください。本書でIBM 製品、プログラム、またはサービスに言及していても、その IBM 製品、プログラム、またはサービスのみが使用可能であることを意味するものではありません。これらに代えて、IBM の知的所有権を侵害することのない、機能的に同等の製品、プログラム、またはサービスを使用することができます。ただし、IBM 以外の製品とプログラムの操作またはサービスの評価および検証は、お客様の責任で行っていただきます。

IBM は、本書に記載されている内容に関して特許権 (特許出願中のものを含む) を保有している場合があります。本書の提供は、お客様にこれらの特許権について実施権を許諾することを意味するものではありません。実施権についてのお問い合わせは、書面にて下記宛先にお送りください。

〒103-8510

東京都中央区日本橋箱崎町19番21号日本アイ・ビー・エム株式会社法務・知的財産知的財産権ライセンス渉外

以下の保証は、国または地域の法律に沿わない場合は、適用されません。IBM およびその直接または間接の子会社は、本書を特定物として現存するままの状態で提供し、商品性の保証、特定目的適合性の保証および法律上の瑕疵担保責任を含むすべての明示もしくは黙示の保証責任を負わないものとします。国または地域によっては、法律の強行規定により、保証責任の制限が禁じられる場合、強行規定の制限を受けるものとします。

この情報には、技術的に不適切な記述や誤植を含む場合があります。本書は定期的に見直され、必要な変更は本書の次版に組み込まれます。 IBM は予告なしに、随時、この文書に記載されている製品またはプログラムに対して、改良または変更を行うことがあります。

本書において IBM 以外の Web サイトに言及している場合がありますが、便宜のため記載しただけであり、決してそれらの Web サイトを推奨するものではありません。それらの Web サイトにある資料は、この IBM 製品の資料の一部ではありません。それらの Web サイトは、お客様の責任でご使用ください。

IBM は、お客様が提供するいかなる情報も、お客様に対してなんら義務も負うことのない、自ら適切と信ずる方法で、使用もしくは配布することができるものとします。

本プログラムのライセンス保持者で、(i) 独自に作成したプログラムとその他のプログラム (本プログラムを含む) との間での情報交換、および (ii) 交換された情報の相互利用を可能にすることを目的として、本プログラムに関する情報を必要とする方は、下記に連絡してください。

IBM Corporation


Dept. LRAS/Bldg. 903

11501 Burnet Road

Austin, TX 78758-3400

U.S.A.

本プログラムに関する上記の情報は、適切な使用条件の下で使用することができますが、有償の場合もあります。

本書で説明されているライセンス・プログラムまたはその他のライセンス資料は、IBM 所定のプログラム契約の契約条項、IBM プログラムのご使用条件、またはそれと同等の条項に基づいて、IBM より提供されます。

この文書に含まれるいかなるパフォーマンス・データも、管理環境下で決定されたものです。そのため、他の操作環境で得られた結果は、異なる可能性があります。一部の測定が、開発レベルのシステムで行われた可能性がありますが、その測定値が、一般に利用可能なシステムのものと同じである保証はありません。さらに、一部の測定値が、推定値である可能性があります。実際の結果は、異なる可能性があります。お客様は、お客様の特定の環境に適したデータを確かめる必要があります。

IBM 以外の製品に関する情報は、その製品の供給者、出版物、もしくはその他の公に利用可能なソースから入手したものです。 IBM は、それらの製品のテストは行っておりません。したがって、他社製品に関する実行性、互換性、またはその他の要求については確証できません。 IBM 以外の製品の性能に関する質問は、それらの製品の供給者にお願いします。

IBM の将来の方向または意向に関する記述については、予告なしに変更または撤回される場合があり、単に目標を示しているものです。

表示されている IBM の価格は IBM が小売り価格として提示しているもので、現行価格であり、通知なしに変更されるものです。卸価格は、異なる場合があります。

本書はプランニング目的としてのみ記述されています。記述内容は製品が使用可能になる前に変更になる場合があります。

本書には、日常の業務処理で用いられるデータや報告書の例が含まれています。より具体性を与えるために、それらの例には、個人、企業、ブランド、あるいは製品などの名前が含まれている場合があります。これらの名称はすべて架空のものであり、名称や住所が類似する企業が実在しているとしても、それは偶然にすぎません。

著作権使用許諾:

本書には、様々なオペレーティング・プラットフォームでのプログラミング手法を例示するサンプル・アプリケーション・プログラムがソース言語で掲載されています。お客様は、サンプル・プログラムが書かれているオペレーティング・プラットフォームのアプリケーション・プログラミング・インターフェースに準拠したアプリケーション・プログラムの開発、使用、販売、配布を目的として、いかなる形式においても、IBM に対価を支払うことなくこれを複製し、改変し、配布することができます。このサンプル・プログラムは、あらゆる条件下における完全なテストを経ていません。従って IBM は、これらのサンプル・プログラムについて信頼性、利便性もしくは機能性があることをほのめかしたり、保証することはできません。サンプル・プログラムは、いかなる種類の保証なしに、現存するままの状態で提供されます。 IBM は、お客様の当該サンプル・プログラムの使用から生ずるいかなる損害に対しても一切の責任を負いません。


それぞれの複製物、サンプル・プログラムのいかなる部分、またはすべての派生的創作物にも、次のように、著作権表示を入れていただく必要があります。

© (お客様の会社名) (西暦年). このコードの一部は、IBM Corp. のサンプル・プログラムから取られています。 © Copyright IBM Corp. _年を入れる_.

この情報をソフトコピーでご覧になっている場合は、写真やカラーの図表は表示されない場合があります。

プライバシー・ポリシーに関する考慮事項サービス・ソリューションとしてのソフトウェアも含めた IBM ソフトウェア製品 (「ソフトウェア・オファリング」) では、製品の使用に関する情報の収集、エンド・ユーザーの使用感の向上、エンド・ユーザーとの対話またはその他の目的のために、Cookie はじめさまざまなテクノロジーを使用することがあります。多くの場合、ソフトウェア・オファリングにより個人情報が収集されることはありません。 IBM の「ソフトウェア・オファリング」の一部には、個人情報を収集できる機能を持つものがあります。ご使用の「ソフトウェア・オファリング」が、これらのCookie およびそれに類するテクノロジーを通じてお客様による個人情報の収集を可能にする場合、以下の具体的事項を確認ください。

この「ソフトウェア・オファリング」は、Cookie もしくはその他のテクノロジーを使用して個人情報を収集することはありません。

この「ソフトウェア・オファリング」が Cookie およびさまざまなテクノロジーを使用してエンド・ユーザーから個人を特定できる情報を収集する機能を提供する場合、お客様は、このような情報を収集するにあたって適用される法律、ガイドライン等を遵守する必要があります。これには、エンドユーザーへの通知や同意の要求も含まれますがそれらには限られません。

このような目的での Cookie などの各種テクノロジーの使用について詳しくは、『IBM オンラインでのプライバシー・ステートメントのハイライト』(http://www.ibm.com/privacy/jp/ja/)、『IBM オンラインでのプライバシー・ステートメント』(http://www.ibm.com/privacy/details/jp/ja/) の『クッキー、ウェブ・ビーコン、その他のテクノロジー』というタイトルのセクション、および『IBM Software Products and

Software-as-a-Service Privacy Statement』(http://www.ibm.com/software/info/product-privacy) を参照してください。

商標IBM、IBM ロゴおよび ibm.com は、世界の多くの国で登録された International Business Machines Corp.

の商標です。他の製品名およびサービス名等は、それぞれ IBM または各社の商標である場合があります。現時点での IBM の商標リストについては、http://www.ibm.com/legal/copytrade.shtml の「Copyright

and trademark information」をご覧ください。

Adobe、Adobe ロゴ、PostScript、および PostScript ロゴは、Adobe Systems Incorporated の米国およびその他の国における登録商標または商標です。

Java およびすべての Java 関連の商標およびロゴは、Oracle やその関連会社の米国およびその他の国における商標または登録商標です。

Linux は、Linus Torvalds の米国およびその他の国における商標です。

UNIX は、The Open Group の米国およびその他の国における登録商標です。.

特記事項 245

http://www.ibm.com/privacy

http://www.ibm.com/privacy/details

http://www.ibm.com/software/info/product-privacy

http://www.ibm.com/legal/us/en/copytrade.shtml

http://www.ibm.com/legal/us/en/copytrade.shtml


索引日本語, 数字, 英字, 特殊文字の順に配列されています。なお, 濁音と半濁音は清音と同等に扱われています。

［ア行］アドレス解決プロトコル参照： ARP

アプリケーション 12, 233

依存関係 237

概説 233

干渉 238

スクリプトの作成 240

多層 15

アプリケーション・サーバー 14

アプリケーション・サーバー・ワークシート 224

アプリケーション・モニター 15

アプリケーション・モニター・ワークシート (プロセス・モニター) 225

アプリケーション・モニター・ワークシート (ユーザー定義モニター) 226

アプリケーション・ワークシート 220

移動リソース・グループ 134

イベントイベント前処理および後処理スクリプト 167

概説 154

クラスター全体の状況 163

サイト 155

通知 167

ネットワーク 160

ネットワーク・インターフェース 161

ノード 155

ユーザー定義 173

要約 176

リソース・グループ 164

インストールオンライン・プランニング・ワークシート 181

オープン既存のクラスター定義ファイル 188

オンライン・プランニング・ワークシートアプリケーション・サーバー・ワークシート 224




インストール 181

オンライン・ヘルプの利用 187

開始 183

オンライン・プランニング・ワークシート (続き)

概説 180

既存のオープン 188

共用 IBM Fibre 磁気テープ・ドライブ・ワークシート 212

共用 IBM SCSI 磁気テープ・ドライブ・ワークシート 211

共用 IBM SCSI ディスク・アレイ・ワークシート 210

共用 IBM シリアル・ストレージ・アーキテクチャー・ディスク・サブシステム・ワークシート 213

共用 SCSI ディスク・ワークシート 210

共用ボリューム・グループおよびファイルシステム・ワークシート (コンカレント・アクセス) 219

共用ボリューム・グループおよびファイルシステム・ワークシート (非コンカレント・アクセス) 216

クラスター定義ファイル 199

クラスターの計画 192

クラスター・イベント・ワークシート 228

クラスター・サイト・ワークシート 230

シリアル・ネットワーク・インターフェース・ワークシート208

新規作成 187

妥当性検査 189

通信リンク (SNA-over-LAN) ワークシート 222

通信リンク (SNA-Over-X.25) ワークシート 223

通信リンク (X.25) ワークシート 223

非共用ボリューム・グループ・ワークシート (コンカレント・アクセス) 218

非共用ボリューム・グループ・ワークシート (非コンカレント・アクセス) 214

ファイバー・チャネル・ディスク・ワークシート 209

変更 189

保管 189

リソース・グループ・ワークシート 227

2 ノード・クラスター構成ワークシート 205

Fast Connect ワークシート 221

HACMP ファイル・コレクション・ワークシート 231

NFS エクスポートされるファイルシステムまたはディレクトリー・ワークシート (非コンカレント・アクセス) 217

Point-to-Point ネットワーク・ワークシート 207

TCP/IP ネットワーク・インターフェース・ワークシート206

TCP/IP ネットワーク・ワークシート 205

WebSMIT クラスター・プランニング・ワークシート 232

WebSMIT ユーザー・プランニング・ワークシート 231

参照：クラスター定義ファイル

［カ行］開始オンライン・プランニング・ワークシート 183

概説アプリケーション 233


概説 (続き)

オンライン・プランニング・ワークシート 180

共用 LVM コンポーネント 97

クライアント 177

クラスターの初期計画 6

クラスター・イベント 154

計画ツール 4

計画プロセス 4

ディスク 73


AIX ワークロード・マネージャー 148

仮想 SCSI 84

仮想イーサネット 34

キャパシティー・アップグレード・オンデマンド参照： CUoD




共用 IBM SSA ディスク・サブシステムインストール 86


共用 LVM コンポーネント 97

概説 97

共用 SCSI ディスクインストール 84


共用ディスク 73



クォーラム 106


概説 177

ネットワーク・コンポーネント 179

clinfo 178

clinfo を実行していない 178

クラスター区分化 32

ダイアグラム 27

クラスター定義ファイル 179, 199


クラスター構成の変換 201

サンプル 201

新規作成 187, 192

妥当性検査 189

フォーマット 200

変更 189

保管 189

クラスターの初期計画 6

概説 6

クラスター・イベント参照：イベント



計画クラスター定義ファイルの使用 192

計画ツール概説 4

計画プロセス概説 4

高速ディスク・テークオーバー 104

コンカレントリソース・グループ 125

［サ行］サイト 8

イベント 155

ミラーリング 101


作成新規クラスター定義ファイル 187

サンプルクラスター定義ファイル 201

IBM 2104 Expandable Storage Plus 85

IBM 2105 Enterprise Storage Server 86

IBM DS4000 Storage Server 85

Oracle Database および SAP R/3 241

磁気テープ・ドライブ 94

識別サービス・アダプター障害 60

指針 2

ジャーナル・ログミラーリング 101

処理順序リソース・グループ 138


スクリプトイベント前処理および後処理 167

書き出し 240

ステータスイベント 163

セキュリティー 11

設定障害検出パラメーター 57

ネットワーク猶予期間の値 59

［タ行］妥当性検査クラスター定義ファイル 189

追加ディスク構成 94

ネットワーク・トポロジー 72

通信リンク 24





テープ・デバイス 73

定義代替 70

代替 FDDI ハードウェア・アドレス 71

代替イーサネット・ハードウェア・アドレス 71

代替トークンリング・ハードウェア・アドレス 71

ハードウェア・アドレス 69, 70

ディスクアダプター 84, 86

概説 73

仮想 SCSI 84

共用 IBM SSA ディスク・サブシステムのインストール86

共用 SCSI ディスクのインストール 84

共用ディスク・テクノロジー 74

ケーブル 85

計画の考慮事項 75

電源装置の考慮事項 82

非共用ディスク・ストレージ 82

IBM 2104 Expandable Storage Plus 75

サンプル 85


サンプル 86

IBM DS4000 Storage Server

サンプル 85

IBM System p i5 モデル 520、550 および 570 iSeries とSystem p の集中化 80

IBM System p p5 モデル 510、520、550 および 570 78

IBM System p p5 モデル 575 79

IBM System p p5 モデル 590 および 595 79

IBM TotalStorage DS4000 ストレージ・サーバー 77



IBM シリアル・ストレージ・アーキテクチャー・ディスク・サブシステム 81

SCSI ディスク・デバイス 75

SSA 機能 88

ディスク構成追加 94

ディスク・アクセス 102

拡張コンカレント 103

非コンカレント 104

テストループ 89

［ナ行］ネットワークイベント 160

概説ネットワーク接続 29

仮想イーサネット 34

競合の回避 72


クラスターの区分化 32

クラスターのモニター 56

ネットワーク (続き)

サービス・アダプター障害の識別 60

サポートされるタイプ 30

障害検出パラメーターの設定 57

スイッチ・ネットワーク 33

接続 29, 30

概説 29

代替 FDDI ハードウェア・アドレスの定義 71

代替イーサネット・ハードウェア・アドレスの定義 71

代替トークンリング・ハードウェア・アドレスの定義 71

代替ハードウェア・アドレスの選択 70

ディスクを使用するハートビート 40

トポロジーの追加 72

ネットワーク猶予期間 59

ハードウェア・アドレスの定義 69

ハートビート 35


例 33

ARP キャッシュ 31

DIS 55

IP エイリアス 30

IP エイリアスによる IP アドレス・テークオーバー 50

IP エイリアスを使用するハートビート 36

IP 交換による IP アドレス・テークオーバー 54

IP ラベル 32

netmon.cf ファイルに記述する IP アドレスの選択 60

NIS 55

Oracle 64

RS232 TTY ボー・レートの設定 64

topology 41

VPN ファイアウォール 56

ネットワーク・インターフェースイベント 161

ノード 7

イベント 155

node_down イベント 156

node_up イベント 156

ノード分離 32

［ハ行］ハードウェア・アドレス代替 FDDI の定義 71

代替イーサネットの定義 71

代替トークンリングの定義 71

代替の選択 70

定義 69

arp 70

netstat 70

ハートビート 35

ディスク 40




索引 249

非コンカレントリソース・グループ 125


ファイルシステム 99

複製リソース 146

物理区画ミラーリング 99

物理ボリューム 97

変換クラスター定義ファイル 201

変更クラスター定義ファイル 189

保管クラスター定義ファイル 189

ボリューム・グループ 98

［マ行］ミラーリングサイト 101

ジャーナル・ログ 101

物理区画 99

モニタークラスター 56

［ラ行］リカバリーリソース・グループ 147


移動 134

イベント 164

概説 124

サイト 139

処理順序 138

属性 127

タイプ 125


複製リソース 146

ポリシー 126

リカバリー 147

clRGmove を使用した移動 135


例ネットワーク接続 33

論理ボリューム 98

［ワ行］ワークシート 179

アプリケーション・サーバー・ワークシート 224



ワークシート (続き)


インストール 181

オンライン・ヘルプの利用 187

開始 183

概説 180









クラスター定義ファイル 199

クラスターの計画 192




新規作成 187

妥当性検査 189







変更 189

保管 189


2 ノード・クラスター構成ワークシート 205

Fast Connect ワークシート 221

HACMP ファイル・コレクション・ワークシート 231


Point-to-Point ネットワーク・ワークシート 207

TCP/IP ネットワーク・インターフェース・ワークシート206


WebSMIT クラスター・プランニング・ワークシート 232


［数字］2 ノード・クラスター構成ワークシート 205

AAIX Fast Connect 22


AIX ワークロード・マネージャー概説 148

arp

ハードウェア・アドレス 70

ARP キャッシュ 31

Cclinfo 178

実行していない 178

clRGmove


CUoD 13

DDIS 55

FFast Connect ワークシート 221

HHACMP ファイル・コレクション・ワークシート 231

hacmp.out 176

IIBM 2104 Expandable Storage Plus 75

サンプル 85


サンプル 86

IBM DS4000 Storage Server

サンプル 85

IBM System p i5 モデル 520、550 および 570 iSeries とSystem p の集中化 80

IBM System p p5 モデル 510、520、550 および 570 78

IBM System p p5 モデル 575 79

IBM System p p5 モデル 590 および 595 79


IBM TotalStorage DS6000 ストレージ・デバイス 78

IBM TotalStorage DS8000 ストレージ・デバイス 78

IBM シリアル・ストレージ・アーキテクチャー・ディスク・サブシステム 81

IP アドレス・テークオーバーIP エイリアス 50

IP 交換 54


IP ラベル 32

LLVM コンポーネント 97

LVM ミラーリング 99

Nnetmon.cf ファイル

IP アドレスの選択 60

netstat 70

NFS 109


NIS 55

OOLPW

参照：オンライン・プランニング・ワークシートOracle

ネットワーク計画 64

PPoint-to-Point ネットワーク・ワークシート 207

RRS232 TTY ボー・レート 64

SSCSI ディスク・デバイス 75

SSA

ディスク・フェンシング 90

SSA 機能 88

TTCP/IP ネットワーク・インターフェース・ワークシート 206


topology


Vvaryon 106

強制 108

VPN ファイアウォール 56

WWebSMIT クラスター・プランニング・ワークシート 232


索引 251

WLM

参照： AIX ワークロード・マネージャー


��

Printed in Japan

Documents

High Availability Cluster Multi-Processing for AIXpublic.dhe.ibm.com/systems/power/docs/powerha/61/nl/ja/...本書について 本書は、High Availability Cluster Multi-Processing

High Availability Cluster Multi-Processing for AIXpublic.dhe.ibm.com/systems/power/docs/powerha/61/nl/ja/...本書について本書は、High Availability Cluster Multi-Processing