Storage Foundation Cluster File System High Availability 8.0.2 設定およびアップグレードガイド - Linux
- 第 I 部 SFCFSHA の概要
- 第 II 部 SFCFSHA の設定
- 設定の準備
- データ整合性のための SFCFSHA クラスタ設定の準備
- SFCFSHA の設定
- データ整合性のための SFCFSHA クラスタの設定
- 応答ファイルを使用した SFCFSHA 自動設定の実行
- 応答ファイルを使用した自動 I/O フェンシング設定の実行
- 応答ファイルを使用した CP サーバーの設定
- データ整合性のための SFCFSHA クラスタの手動設定
- 第 III 部 SFCFSHA のアップグレード
- SFCFSHA のアップグレード計画
- SFCFSHA のアップグレードの準備
- インストーラを使った SFCFSHA の完全アップグレードの実行
- SFCFSHA のローリングアップグレードの実行
- SFCFSHA の段階的アップグレードの実行
- 応答ファイルを使用した SFCFSHA 自動アップグレードの実行
- Volume Replicator のアップグレード
- VirtualStore のアップグレード
- アップグレード後のタスクの実行
- SFCFSHA のアップグレード計画
- 第 IV 部 設定後のタスク
- 第 V 部 ディザスタリカバリ環境の設定
- 第 VI 部 ノードの追加と削除
- 第 VII 部 設定およびアップグレードの参照
- 付録 A. インストールスクリプト
- 付録 B. 設定ファイル
- 付録 C. セキュアシェルまたはリモートシェルの通信用の設定
- 付録 D. 高可用性エージェントの情報
- 付録 E. CP サーバーベースの I/O フェンシングのためのサンプル SFCFSHA クラスタ設定図
- 付録 F. UDP 上での LLT の設定
- 付録 G. RDMA 上での LLT の使用
- RDMA 上の LLT の設定
- RDMA 上の LLT のトラブルシューティング
データ整合性のための SFCFSHA クラスタの設定について
ノードに障害が起きた場合、SFCFSHA は修正アクションを実行し、変更後のメンバーシップが反映されるように、そのコンポーネントを設定します。 実際のノードに障害が発生していないのに、障害があるノードと同じ現象が見られる場合、上記の修正アクションはスプリットブレインの状況を引き起こします。
そのようなスプリットブレインの状況の原因となるシナリオの例を次に示します。
プライベートネットワークの障害
2 ノードクラスタ内のシステムにノード障害が発生すると、システムはプライベート相互接続を介したノード間のハートビート送信を停止します。 次に、存在するノードが修正アクションを実行します。 実際のノードではなくプライベート相互接続に障害が起きた場合も同じ現象が起こり、これによって各ノードは自分の接続相手が切断されたと判断します。 このような場合は、両方のノードが無秩序にデータストレージを制御しようとするため、通常はデータの破損につながります。
ハングアップしたように見えるシステム
システムで処理が集中しているために応答していないように見える場合、他のノードからシステム停止を宣言される可能性があります。 この宣言は、「中断」および「再開」機能をサポートするハードウェアを使用しているノードにも発生する場合があります。 中断機能を使用してノードを PROM レベルに落としてから処理を再開すると、他のノードからシステム停止を宣言される場合があります。 そのシステムが後で復旧して書き込み処理を再開しても、他のノードからはシステム停止を宣言される場合があります。
I/O フェンシングは、クラスタ内で通信エラーが発生した場合にデータ破損を防止する機能です。 SFCFSHA は I/O フェンシングを使って、スプリットブレインに伴うリスクを除去します。 I/O フェンシングは、アクティブなクラスタのメンバーへの書き込みアクセスを許可します。 メンバー以外からのストレージへのアクセスはブロックするため、稼動中のノードでも障害の原因になることはありません。
Veritas InfoScale Enterprise をインストールし、SFCFSHA を設定した後で、データ整合性が確保されるように SFCFSHA の I/O フェンシングを設定する必要があります。
???を参照してください。
I/O フェンシング設定の計画についてを参照してください。