test

Sun Cluster 2.2 ソフトウェアのインストール

Sun Cluster 環境について

この章では、Sun Cluster 製品の概要を説明します。

Sun Cluster の概要

Sun Cluster システムは、クラスタ化されたサーバー (Sun Cluster サーバー) 上でデータサービスに対する高可用性 (HA) サポートを提供し、並列データベースへのアクセスを可能にするソフトウェア環境です。Sun Cluster サーバーは、Solaris 2.6、Solaris 7、または Solaris 8 オペレーティング環境、Sun Cluster フレームワークソフトウェア、ディスクボリューム管理ソフトウェア、高可用性データサービスまたは並列データベースアプリケーション (OPS または XPS) を実行します。

Sun Cluster フレームワークソフトウェアは、ハードウェアとソフトウェアの障害検出機能、Sun Cluster システム管理、システムフェイルオーバー、障害発生時のデータサービスの自動再起動機能を提供します。Sun Cluster ソフトウェアには、HA データサービスとアプリケーションプログラミングインタフェース (API) のセットが付属します。この API を使用して、Sun Cluster フレームワークと提供されている HA データサービスを統合することによって、別の HA データサービスを作成することができます。

Sun Cluster の並列データベースで使用される共有ディスクアーキテクチャは、複数のクラスタノード経由で 1 つのデータベースへの同時アクセスを可能にすることによって、データベースの高可用性を実現しています。1 つのノードで問題が発生しても、大きな遅延なしに、別のノードを使用して引き続きデータを利用できます。

Sun Cluster は、Solstice DiskSuite、VERITAS Volume Manager (VxVM) のいずれかのボリューム管理ソフトウェアを使用して、多重ホストディスク (複数の Sun Cluster サーバーからアクセス可能なディスク) を管理します。3 つのボリューム管理ソフトウェアはすべて、ディスクのミラー化、結合、ストライプ化、ホットスペア機能を提供します。VxVM は、RAID5 機能も提供します。ボリューム管理と Sun Cluster の詳細は、「ボリュームマネージャ」と 「ボリューム管理」を参照してください。

Sun Cluster システムの目的は、システムが使用できなくなることを障害を管理することによって回避することにあります。これは、ハードウェアの冗長性とソフトウェアの監視、再起動機能を追加することによって実現されています。これらの対策によって、システム上のシングルポイント障害が減少します。シングルポイント障害とは、クライアントアプリケーションからのシステム全体へのアクセスを不可能にするハードウェアまたはソフトウェアコンポーネントの障害です。

冗長ハードウェアでは、ハードウェアコンポーネントごとに、障害コンポーネントの後をテイクオーバーできるバックアップコンポーネントが存在します。障害モニターは、Sun Cluster フレームワークと HA データサービスを定期的に調査し、素早く障害を検出します。HA データサービスの場合、HA 障害モニターは、障害ノードで動作していたデータサービスを別のノードに移すことによって障害に対処します。ノードに障害がなかった場合は、同じノードでのデータサービスの再起動を図ります。

Sun Cluster 構成では、次のようなシングルポイント障害に対応できます。

ハードウェア構成

HA および並列データベース構成は、類似のハードウェアとソフトウェアコンポーネントで構成されます。ハードウェアコンポーネントとしては、以下があります。

この後の節では、これらのコンポーネントについて詳しく説明します。

クラスタノード

クラスタノードは、データサービスと並列データベースアプリケーションを実行する Sun EnterpriseTM サーバーです。Sun Cluster は、2 つから 4 つのノードのクラスタをサポートします。

クラスタインターコネクト

クラスタインターコネクトは、重要なロック情報とハートビート情報に使用される信頼性の高いノード間通信チャネルを提供します。インターコネクトは、クラスタの高可用性や同期、完全性の管理に使用されます。クラスタインターコネクトは、2 つのプライベートリンクで構成されます。これらのリンクは冗長な構成であり、クラスタの動作に必要なのは 1 つだけです。すべてのノードが動作していて、1 つのプライベートインターコネクトが失われても、クラスタ動作は継続します。ただし、ノードがクラスタを結合する場合、結合が正しく行われるには、両方のプライベートインターコネクトが動作可能である必要があります。

クラスタは、プライベートインターコネクト媒体として SCI (Scalable Coherent Interface) または Fast Ethernet のいずれかを使用できます。ただし、これらの媒体を混在させる、つまり、同じクラスタ内で SCI と Fast Ethernet の両方を使用することはできません。

注 -

このマニュアルでは、ネットワークアダプタインタフェースの hme1 と hme2 をクラスタインターコネクトとしています。実際には、このインタフェースは、ハードウェアプラットフォームとプライベートネットワーク構成によって異なることがあります。前提として求められるのは、2 つのプライベートインターコネクトが同じコントローラを共有しないことです。このことにより、シングルポイント障害が原因でインターコネクトが動作を中断することがなくなります。

スイッチ管理エージェント

スイッチ管理エージェント (SMA) は、プライベートインターコネクト上の通信チャネルを保守するクラスタモジュールです。SMA はプライベートインターコネクトを監視し、障害を検出した場合は、残っているプライベートネットワークに対して論理アダプタのフェイルオーバーを行います。複数の障害を検出した場合は、クラスタメンバーシップを変更するために必要な作業を行うクラスタメンバーシップモニターにそのことを通知します。

クラスタ化された環境に求められる通信条件は、その環境でサポートするデータサービスの種類によって異なります。HA データサービスだけ提供するクラスタは、プライベートインターコネクト上でハートビートと最低限のクラスタ構成トラフィックを必要とするだけであり、そうした構成では、Fast Ethernet で十分です。並列データベースサービスを提供するクラスタは、プライベートインターコネクト上で大量のトラフィックを送信します。このため、そうしたアプリケーションでは、スループットの大きい SCI の方に利点があります。

SCI クラスタに対する SMA

SCI (Scalable Coherent Interface) は、クラスタノード間のメモリー共有を可能にする、メモリーを使用した高速のインターコネクトです。SCI プライベートインターコネクトは、SCI に基づく伝送制御プロトコル/インターネットプロトコル (TCP/IP) ネットワークインタフェースで構成されます。

スイッチまたはハブによって、どのような規模のクラスタでも相互接続できます。ただし、ポイントツーポイント接続できるのは 2 ノードのクラスタだけです。SCI リンクとスイッチに対するセッションは、システム管理エージェント (SMA) ソフトウェアコンポーネントによって管理されます。

Sun Cluster では、基本的な SCI トポロジとして、次の 3 つをサポートしています (図 1-1 と 図 1-2 を参照)。

図 1-1 4 ノードの SCI クラスタトポロジ

Graphic

図 1-2 2 ノード の SCI クラスタトポロジ

Graphic

Ethernet クラスタに対する SMA

スイッチまたはハブによって、どのような規模のクラスタでも相互接続できます。ただし、ポイントツーポイント接続できるのは 2 ノードのクラスタだけです。Ethernet スイッチまたはハブ上の通信は、システム管理エージェント (SMA) ソフトウェアコンポーネントによって管理されます。

Sun Cluster では、基本的な Ethernet トポロジとして、次の 3 つをサポートしています (図 1-3 と 図 1-4 を参照)。

図 1-3 4 ノードの Ethernet クラスタトポロジ

Graphic

図 1-4 2 ノードの Ethernet クラスタトポロジ

Graphic

/etc/nsswitch.conf ファイルのエントリ

/etc/nsswitch.conf ファイルを編集して、「サービス」、「グループ」、「ホスト」が常に /etc 内のファイルで検索されるようにする必要があります。この編集作業は、第 3 章「Sun Cluster ソフトウェアのインストールと構成」で説明する Sun Cluster のインストール作業の一環として行われます。

次は、ネームサービスとして NIS+ を使用する /etc/nsswitch.conf ファイルの例です。

services: files nisplus

このエントリは、別のサービスのエントリより前に置く必要があります。詳細は、nsswitch.conf(4) のマニュアルページを参照してください。

/etc/nsswitch.conf ファイルの編集は手作業で行う必要がありますが、クラスタコンソールを使ってすべてのノードを一度に更新することができます。クラスタコンソールについての詳細は、『Sun Cluster 2.2 のシステム管理』の Sun Cluster の管理ツールの説明を参照してください。

パブリックネットワーク

Sun Cluster へのアクセスは、クラスタのノードをパブリックネットワークに接続することによって実現されます。クラスタのノードには、パブリックネットワークをいくつでも接続できますが、クラスタのトポロジに関係なく、それらパブリックネットワークはクラスタ内のすべてのノードに接続する必要があります。図 1-5 は、ノード 4 つのクラスタを 1 つのパブリックネットワーク (192.9.200) に接続した構成です。パブリックネットワーク上の各物理ホストは、IP アドレスを持ちます。

パブリックネットワークの 1 つは主パブリックネットワークと定義され、残りのパブリックネットワークは二次パブリックネットワークと定義されます。各ネットワークはまた、サブネットワークあるいはサブネットともいいます。図 1-5 には、物理ネットワークアダプタ (hme0) も示されています。このマニュアルでは、hme0 を主パブリックネットワークのインタフェースとしています。実際には、このインタフェースは、ハードウェアプラットフォームとパブリックネットワーク構成によって異なることがあります。

図 1-5 1 つのパブリックネットワークに接続されたノード 4 つのクラスタ

Graphic

図 1-6 は、上図と同じノード構成ですが、2 つ目のパブリックネットワーク (192.9.201) が追加されています。パブリックネットワークを追加するごとに、すべての Sun Cluster サーバーに対して物理ホスト名と IP アドレスを割り当てる必要があります。

主物理ホスト名は、主パブリックネットワーク上で物理ホストが識別される名前です。二次物理ホスト名は、二次パブリックネットワーク上で物理ホストが識別される名前です。図 1-6 では、主物理ホスト名は phys-hahost1〜4、二次物理ホスト名は phys-hahost1〜4-201 です。接尾辞の -201 は、二次パブリックネットワークを表します。物理ホストの命名規則については、第 2 章「構成の計画」で詳しく説明します。

図 1-6 では、ネットワークアダプタの hme3 が、二次パブリックネットワークへのインタフェースとしてすべてのノードに使用されるようになっています。このアダプタは、インタフェースとして適切なものであれば、どのようなものでもかまいません。hme3 は一つの例にすぎません。

図 1-6 2 つのパブリックネットワークに接続されたノード 4 つのクラスタ

Graphic

ローカルディスク

Sun Cluster サーバーにはそれぞれ、そのサーバーからのみアクセス可能なディスクが存在します。そうしたディスクをローカルディスクと呼びます。ローカルディスクには、Sun Cluster ソフトウェア環境と Solaris オペレーティング環境が含まれます。

図 1-7 は、ローカルディスクを持つ 2 ノードのクラスタ構成を示しています。

ローカルディスクはミラー化できますが、必ずしもミラー化する必要はありません。ローカルディスクのミラー化についての詳細は、第 2 章「構成の計画」を参照してください。

多重ホストディスク

どのような Sun Cluster 構成でも、少なくとも 2 つのノードには、1 組の共有ディスク (または多重ホストディスク) が物理接続されます。共有ディスクは、複数のディスク拡張装置にまたがってグループを構成します。ディスク拡張装置は、物理的なディスク格納装置です。Sun Cluster は、Sun StorEdgeTM MultiPack、Sun StorEdge A3000、Sun StorEdge A5000 などの、さまざまなディスク拡張装置をサポートしています。図 1-7 は、それぞれに 1 組のディスク拡張装置が物理接続されている 2 つのホストを示しています。クラスタのすべてのノードをすべてのディスク拡張装置に物理接続する必要はありません。

HA 構成では、多重ホストディスクに HA データサービス用のデータが格納されます。サーバーは、多重ホストディスクをマスターしているときに、そのディスク上のデータを利用できます。Sun Cluster サーバーの 1 つに障害が発生した場合、データサービスは同じクラスタ内の別のサーバーにフェイルオーバーします。すなわち、フェイルオーバー時、故障したノード上で動作していたデータサービスは、ユーザーの介入なしに、わずかなサービスの中断があるだけで別のノードから起動されます。システム管理者は、手動でいつでも別の Sun Cluster サーバーにデータサービスを切り替える (スイッチオーバー) ことができます。フェイルオーバーとスイッチオーバーについての詳細は、「システムフェイルオーバーとスイッチオーバー」を参照してください。

並列データベース構成では、多重ホストディスクに、リレーショナルデータベースアプリケーションの使用するデータが格納されます。この多重ホストディスクには、複数のサーバーが同時にアクセスします。Oracle UNIX DLM (Dynamic Lock Manager) によって、ユーザープロセスによる共有データの破壊が防止されます。

Sun StorEdge A3000 (RAID5 機能を持つ) を除き、多重ホストディスクは必ずミラー化する必要があります。図 1-7 は、多重ホストディスク構成を表しています。

図 1-7 ローカルディスクと多重ホストディスク

Graphic

端末集配信装置またはシステムサービスプロセッサ (SSP) と管理ワークステーション

端末集配信装置は、クラスタノードのすべてのコンソール用シリアルポートを 1 つのワークステーションに接続するために使用される装置です。端末集配信装置は、クラスタノード上のコンソール用シリアルポートを telnet でアクセス可能なデバイスに変えます。端末集配信装置のアドレスに telnet 接続して、boot-PROM-prompt 対応のコンソールウィンドウを表示することができます。

システムサービスプロセッサ (SSP) は、Sun Enterprise 10000 サーバーにコンソールアクセス機能を提供します。SSP は、Sun Enterprise 10000 のサポート用として特に設定された、Ethernet ネットワーク上の Solaris ワークステーションです。SSP は、Sun Enterprise 10000 を使用した Sun Cluster 構成用の管理ワークステーションとして使用されます。 Sun Enterprise 10000 のネットワークコンソール (netcon) 機能を使用することにより、ネットワーク上のどのワークステーションからでも、ホストコンソールセッションを開くことができます。

クラスタコンソールは SSP に telnet(1M) 接続するため、SSP にログインして、netcon セッションを開始し、ドメインを制御できます。SSP についての詳細は、Sun Enterprise 10000 のマニュアルを参照してください。

端末集配信装置とシステムサービスプロセッサは、障害防護プロセスの一環として、いくつかの障害発生状況でノードを停止するために使用されます。詳細は、「障害防護 (VxVM)」を参照してください。

管理ワークステーションは、クラスタを構成するあらゆるノードからコンソールインタフェースを提供するために使用されます。管理ワークステーションは、クラスタコンソールセッションを実行する能力を持つワークステーションであれば、どのようなものでもかまいません。

詳細は、『Sun Cluster 2.2 のシステム管理』と『Sun Cluster 2.2 Hardware Site Preparation, Planning, and Installtion Guide』の端末集配信装置に関する各章と端末集配信装置のマニュアルを参照してください。

図 1-8 端末集配信装置と管理ワークステーション

Graphic

定足数、定足数デバイス、障害防護

分散システムでは、定足数という概念がしばしば使用されます。基本的には、定足数とは半数を超える一致であり、あいまいな状況において最善の解決策を決定するために使用されます。必要な定足数を表す実際の数は状況によって異なります。つまり、単純に過半数の一致であればよい場合もあれば、3 分の 2 の一致が必要な場合もあります。分散システムでは、定足数のメンバーとして、通信しているプロセス群が使用されることがあります。システムを効果的に動作させるには、またシステムの動作について重要な決定を下すには、それらプロセスが、求められる定足数に合意する必要があります。そして、定足数が得られるまでメッセージをやりとりすることによって、内在する問題に関して合意を得るように努めます。

Sun Cluster では、2 種類の定足数が使用されます。

CMM 定足数

Sun Cluster および Solstice HA クラスタ製品は、異なる方法で CMM 定足数を決定していました。2.0 および 2.1 を含む以前のリリースの Sun Cluster では、クラスタフレームワークによって CMM 定足数が決定され、Solstice HA では、Solstice DiskSuite ボリュームマネージャによって定足数が決定されていました。Sun Cluster 2.2 は、Sun Cluster 2.1 と Solstice HA 1.3 の両方に基づいています。Sun Cluster 2.2 では、CMM 定足数の決定は、ボリュームマネージャの Solstice DiskSuite または VxVM に依存します。ボリュームマネージャが Solstice DiskSuite の場合、CMM 定足数は、Solstice DiskSuite が管理する、定足数のメタデバイス状態データベースの複製によって決定されます。使用されているボリュームマネージャーが VxVM の場合は、クラスタネットワークによって決定されます。

Sun Cluster 2.2 では、CMM 定足数は次のようにして決定されます。

ノードがクラスタに結合したり、クラスタから切り離されたとき、あるいはクラスタインターコネクトで問題が発生した場合は、クラスタ定足数を決定する必要があります。Solstice HA 1.3 では、クラスタインターコネクトの障害は二重障害とみなされていました。二重障害の場合、ソフトウェアによってデータの完全性は保証されますが、ユーザーの介入なしにクラスタが動作を継続できる保証はありません。システム設計では、二重障害に対して手動介入が行われるようになっていました。これは、手動介入がデータの完全性を保証する最も安全な手段と判断されたためです。

Sun Cluster 2.2 ソフトウェアは、データの完全性の維持とともに、ユーザーの介入なしにクラスタの可用性を維持するように設計されています。クラスタの可用性を維持するため、Sun Cluster 2.2 は、いくつかの新しいプロセスを実装しています。たとえば、定足数デバイスや端末集配信装置、あるいはシステムサービスプロセッサがそうです。Solstice HA 1.3 は Solstice DiskSuite を使用して、クラスタ定足数を決定するため、Sun Cluster 2.2 では、ボリュームマネージャーがクラスタ定足数を決定し、またはクラスタインターコネクトで問題が発生したときのクラスタの動作を決定する最大の要因であることに注意してください。クラスタインターコネクトの障害が及ぼす影響については、「定足数デバイス (VxVM)」で説明します。

CCD 定足数

クラスタ構成データベース (CCD) は、有効で整合性のとられた CCD コピーを選出するにあたって定足数を得る必要があります。CCD の概要については、「クラスタ構成データベース」を参照してください。

Sun Cluster には、どのような構成でも、クラスタの各ノードから実際の記憶装置に直接アクセスすることを保証する記憶装置のトポロジはありません。そうすることによって、1 つの論理ボリュームを使用して CCD データベースが格納される可能性を排除し、クラスタフレームワークの再起動を終えるまで正しく更新が伝達されるようにしています。CCD は、クラスタインターコネクト経由でそのピア (代理) と通信します。クラスタのメンバーではないノードから、この論理リンクを利用することはできません。次に、簡単な例を使用して、CCD 定足数に求められる条件を説明します。

A、B、C の 3 つのノードで構成されるクラスタがあると仮定します。ノード A がクラスタから切り離され、クラスタのメンバーとして B と C が残ります。CCD が更新され、その更新がノード B と C に伝達されます。その後、ノード B と C がクラスタから切り離され、ノード A が再起動されたとします。しかし、ノード B と C 上で発生した更新を知る手段はないので、ノード A には、CCD データベースの最新コピーは存在しません。実際、どのノードが先に起動された場合でも、CCD データベースの最新コピーがどのノードに存在するのかを、明確な方法で判断することは不可能です。CCD データベースの最新コピーを確定するために必要な情報が得られるのは、3 つのノードがすべて再起動されたときだけです。 有効な CCD を選出できなかった場合、CCD に対する照会あるいは更新操作はすべて不正な CCD エラーとなって失敗します。

実際問題として、有効な CCD コピーを確定する前にクラスタのすべてのノードを起動するというのは、条件として厳しすぎます。

この条件は、更新操作に制限を設けることによって緩めることができます。クラスタにおいて現在構成済みのノード数を n とすると、更新を伝達するには、少なくとも floor (n) [n が奇数の場合、floor(n) = 1 + ((n-1)/2)。n が偶数の場合、floor(n) = 1 + ((n)/2)] で表される数のノードが動作している必要があります。クラスタの再起動時に有効なデータベースを選出するには、同じ内容のコピーが ceiling (n) [n が奇数の場合、ceiling(n) = (n+1)/2。n が偶数の場合、floor(n) = (n/2)] 個存在していれば十分です。その場合、有効な CCD が存在していないすべてのクラスタノードに有効な CCD が伝達されます。

CCD が無効であっても、ノードのクラスタへの結合は許可されることに注意してください。ただし、この状態で、CCD を更新したり、CCD に照会を行ったりすることはできません。このことは、クラスタフレームワークの、CCD に依存する全コンポーネントが機能不全の状態に留まることを意味します。具体的には、論理ホストをマスターしたり、データサービスを起動したりできなくなります。CCD を使用できるようになるのは、定足数に達するために必要な数のノードがクラスタに結合した後だけです。これに代わる方法として、管理者が最高の CCD 生成番号を持つ CCD データベースを回復することもできます。

CCD 定足数の問題は、再構成中に少なくとも 1 つのノードを動作したままにしておくことによって回避できます。この場合は、いずれかのノード上の有効なコピーが新たに結合するノードに伝達されます。また、最新の CCD コピーを持つノードからクラスタが起動されるようにするという方法もあります。それでも、データベースの更新中にシステムがクラッシュした後で、回復アルゴリズムが CCD コピー間の不整合を検出する可能性はかなりあります。そうした場合は、管理者が復元オプションの ccdadm(1M) コマンド (詳細はマニュアルページを参照) を使用してデータベースを復元する必要があります。CCD にはまた、データベースの現在の内容のバックアップを可能にするチェックポイント機能もあります。システム構成に変更を加えた場合は、CCD データベースのバックアップコピーを作成してください。バックアップコピーを作成しておくことによって、後でデータベースを復元することができます。従来のリレーショナルデータベースに比べて CCD データベースのサイズはかなり小さく、バックアップおよび復元操作は、ほんのわずかな時間で完了します。

2 ノードのクラスタの CCD 定足数

2 ノードのクラスタの場合、前述の定足数過半数の規則で更新が正しく行われるには、両方のノードがクラスタのメンバーである必要があり、この条件は厳しすぎます。また、この構成で一方のノードだけ動作しているときに更新を許可した場合は、クラスタを再起動する前にデータベースを手動で整合させる必要があります。この整合は、最新のコピーを持つノードを先に再起動するか、両方のノードがクラスタに結合した後に ccdadm(1M) の復元操作でデータベースを復元することによって行うことができます。後者の場合、両方のノードがクラスタに結合できるとしても、復元操作が完了するまで CCD は無効な状態に置かれます。

この問題は、共有ディスクデバイスにデータベース用の恒久的な記憶装置を設定することによって解決します。共有コピーが使用されるのは、1 つのノードがアクティブなときだけです。2 つ目のノードが結合すると、共有 CCD の内容がそれぞれのノードにコピーされます。

ノードの 1 つがクラスタから切り離されると、ローカル CCD の内容を共有コピーにコピーすることによって再び共有コピーがアクティブになります。これにより、1 つのノードがクラスタに存在するときにだけ更新が可能になり、クラスタの再起動にまたがって信頼性の高い更新の伝達が行われるようになります。

CCD の共有コピー用に共有記憶装置を利用することの欠点は、この目的のためにだけ 2 つのディスクを確保する必要があることです。ボリュームマネージャは、これらのディスクが別の目的に使用されないようにします。2 つのディスクの利用は、アプリケーションの停止時間を了解し、実際の環境で許される場合は、回避できます。

Sun Cluster 2.2 の CMM 定足数の問題と同様に、共有 CCD は、あらゆる Sun Cluster 構成でサポートされるわけではありません。ボリュームマネージャが Solstice DiskSuite の場合、共有 CCD はサポートされません。共有 CCD が使用されるのはノードの 1 つがアクティブなときだけであるため、共有 CCD によって障害に対処するのは一般的ではありません。

定足数デバイス (VxVM)

いくつかの状況では (たとえば、2 ノードのクラスタで、両方のクラスタインターコネクトで問題が発生し、両方のノードがまだクラスタのメンバーとして残っている場合)、クラスタ定足数の問題を解決するにあたって、Sun Cluster はハードウェアデバイスの助けを必要とします。定足数デバイスとは、そうしたデバイスのことです。

VERITAS Volume Manager (VxVM) を使用しているクラスタでは、定足数デバイスを使用する必要があります。Solstice DiskSuite は、専用のメタデバイス状態データベースの複製を使用することによってクラスタ定足数を確保するので、定足数デバイスを必要としません。つまり、Solstice DiskSuite 構成では、定足数デバイスは必須ではなく、サポートもされません。Solstice DiskSuite を使用するクラスタのインストールでは、scinstall(1M) プログラムによって定足数デバイスが求められたり、受け付けられたりすることはありません。

定足数デバイスは、scinstall(1M) コマンドを使用したクラスタのインストール作業で指定する単なるディスクまたはコントローラです。定足数デバイスは論理的な概念であり、定足数デバイスとして選択された 1 つの具体的なハードウェアに関して、特別な意味はありません。VxVM で、ディスクの一部を独立したディスクグループのメンバーにすることはできないので、定足数デバイスにはディスク全体とそのプレックス (ミラー) が必要になります。

定足数デバイスは、ノード間で共有される多重ホストディスクの更新が、いつでも 1 つのノードによってだけ行われるようにします。定足数デバイスは、ノード間のクラスタインターコネクトが失われた場合に使用されます。ノード (ノード 3 つ以上のクラスタの場合は複数のノード) が、過半数の定足数の一部であることを証明できない場合は、そのノードは共有データの更新を試みてはなりません。すべてのノードが採決を行なって、どのノードがクラスタに留まるかを決定します。各ノードは、自身が通信できるノード数を判断します。クラスタの半数以上のノードと通信できる場合、そのノードは過半数の定足数の構成員となり、クラスタのメンバーに留まることが許可されます。ノードが過半数の定足数の一部でない場合、そのノードは終了し、クラスタから切り離されます。

定足数デバイスは「第 3 の投票」として働き、同じ得票数になるのを防ぎます。たとえば、ノード 2 つのクラスでクラスタインターコネクトが失われた場合、それぞれのノードは、定足数デバイスを確保しようとして競合します。図 1-9 は、多重ホストディスク格納装置の 1 つに定足数デバイスが存在する 2 ノードのクラスタ構成を表しています。

図 1-9 定足数デバイスを持つ、2 ノードのクラスタ

Graphic

定足数デバイスを確保したノードは 2 票の定足数を獲得し、残りのノードは 1 票だけになります。定足数を得たノードは専用のクラスタを起動して、多重ホストディスクをマスターし、もう一方のノードは終了します。

クラスタの再構成では、新しいシステム構成を承認するにあたって、一群のノードと定足数デバイスが投票を行います。再構成は、過半数の定足数に達した場合にだけ行われます。再構成後、ノードがクラスタに留まるのは、そのノードが過半数の定足数を構成する場合だけです。

注 -

3 ノード以上のクラスタでは、多重ホストディスクに対するアクセス権を共有する各ノードセットに対して、定足数デバイスを使用するように構成する必要があります。

3 ノード以上のクラスタでは、定足数デバイスの概念が少し異なります。定足数デバイスを共有しないノードで同数の票割れが発生した場合 (この状態を「票割れ (split-brain)」パーティションという) は、どのノードセットが新しいクラスタになり、どのセットが終了するかを決定する必要があります。定足数デバイスがこの状況に対処することはありません。インストール作業の一貫として定足数デバイスを設定するときに、そうしたパーティションが発生したときにどのようなことを行わせるかを決定する問い合わせがあります。票割れパーティションが発生した場合は、クラスタソフトウェアに自動的に新しいクラスタメンバーシップを選択させるようにしたか、あるいは手動介入を指定したかによって、2 つあるイベントのいずれかが発生します。

たとえば、4 ノードのクラスタがあり (全ノードが同じ記憶装置を共有していても、共有していなくてもよい)、ネットワーク障害が発生して、ノード 0 と 1、ノード 2 と 3 がそれぞれ互いに通信していると仮定します。この状況では、定足数の自動または手動決定のどちらでも使用されます。クラスタ監視ソフトウェアは、どのノードをクラスタのメンバーとすべきで、どのノードをメンバーとすべきでないかを独力で判断しようとします。最後の手段として、定足数デバイスに頼って同じ得票数にならないようにするか、あるいはクラスタドメインの手動および自動選択に頼ります (極端な状況の場合のみ)。

注 -

定足数デバイスで障害が発生するということは、2 ノードのクラスタでノードの 1 つに障害が発生することと似ています。定足数デバイスで障害が発生してもサービスのフェイルオーバーは起こりませんが、それ以上のノードの障害は許されないという意味で 2 ノードのクラスタの高可用性が低下します。障害が発生した定足数デバイスは、クラスタの動作中に再構成したり、交換したりすることができます。定足数デバイスの修理や交換が行われている間に他の構成要素で障害が発生しない限り、クラスタは動作を続けることができます。

定足数デバイス単独で、クラスタメンバーシップに関する決定が必要になるあらゆる状況に対応できるわけではありません。たとえば、完全に動作可能な 3 ノードのクラスタがあり、それらノードのすべてが、Sun StorEdge A5000 のような多重ホストディスクのアクセス権を共有していると仮定します。ノードの 1 つが終了するか、両方のクラスタインターコネクトを失い、残る 2 つのノードが引き続き互いに通信できる場合、残り 2 つのノードが、同じ得票数になるのを回避するために定足数デバイスを確保する必要はありません。代わりに、過半数の得票 (3 票のうちの 2 票) は、互いに通信できる 2 つのノードがクラスタを形成できるかどうかを決定します。クラスタを構成する 2 つのノードは、クラッシュまたは停止したノードがオンラインになって共有データが破壊されないようにする必要があります。このために、2 つのノードは、「障害防護」で説明する手法を使用します。

障害防護

どのようなクラスタシステムであれ、ノードがクラスタのメンバーでなくなった場合は、そのノードが多重ホストディスクに引き続き書き込みを行えないようにする必要があります。そのようにしなかった場合、データが破壊される可能性があるためです。クラスタの残りのノードは、多重ホストディスクに対する読み取りと書き込みを開始できる必要があります。クラスタのメンバーでなくなったノードが引き続き多重ホストディスクに書き込みを行うと、残りのノードが行なっている更新内容に混乱が生じ、最終的には破壊されることになります。

クラスタのメンバーでなくなったノードがディスクに書き込みを行うのを防止することを、障害防護といいます。障害防護は、実際のクラスタが異なるパーティションに存在するときに、隔離されたノードがその専用のパーティションに独立したクラスタとして現れるのを防ぐことによって、データの完全性を保証する上で非常に重要です。

注意 - 注意 -

一方のノードに障害が発生した場合、2 つのクラスタノードは非常に異なるビューを持つことになるため、障害ノードが入出力を行えないようにすることは非常に大切です。障害ノードのクラスタビューには両方のクラスタメンバーが含まれるのに対し (再構成されていないため)、残りのノードのクラスタビューはノード 1 つ (残ったノード自体) のクラスタで構成されます。

2 ノードのクラスタで 1 つのノードが停止するか、1 つのノードで問題が発生した場合、もう一方のノードは、障害ノードからのハートビートを検出して、唯一のクラスタメンバーになるように自身を再構成します。この再構成には、共有デバイスを防護して、障害のあるノードで多重ホストディスクに対する入出力が行われないようにするという処理も含まれます。ノード 2 つだけのあらゆる Sun Cluster 構成において、この防護は、多重ホストディスクに対する SCSI-2 予約機能を利用することによって行われます。残りのノードはディスクを予約し、障害ノードが予約ディスクに入出力を行うのを防ぎます。SCSI-2 予約は本質的に不可分の処理であり、2 つのノードが同じデバイスを同時に予約しようとすると、必ず一方が成功し、もう一方が失敗します。

障害防護 (VxVM)

障害防護は、クラスタのトポロジによって異なります。最も単純なのは、2 ノードのクラスタの場合です。

2 ノードのクラスタの障害防護

2 ノードのクラスタでは、定足数デバイスによって、クラスタに残るノードが決定されます。障害ノードが定足数デバイスを予約することはできないため、障害ノードはその専用クラスタを起動できなくなります。SCSI-2 予約機能を使用して、障害ノードに防護がはられ、障害ノードによる多重ホストディスクの更新が防がれます。

3 ノード以上のクラスタの障害防護

2 ノードのクラスタで使用される SCSI-2 予約モデルで問題なのは、SCSI 予約がホストに固有であるという点です。共有デバイスに予約要求を発行した場合、事実上、ホストは、障害があるかどうかに関係なく、そのデバイスにアクセスできる別のすべてのノードを締め出します。その結果、OPS などの共有ディスク環境で 3 つ以上のノードが多重ホストディスクに接続されていると、この予約モデルは破綻します。

たとえば、3 ノードのクラスタでノードの 1 つが停止すると、残り 2 つのノードは再構成します。しかし、残りのノードは SCSI 予約要求を発行して、障害ノードから土台の共有デバイスを保護することはできません。これは、SCSI 予約要求を発行すると、一方の残りのノードも締め出されるためです。しかし、予約をしないと、障害ノードが稼動し、そのクラスタビューが最新でなくなっているにもかかわらず、共有デバイスに入出力要求を発行する可能性があります。

すべてのクラスタノードから直接、アクセス可能な記憶装置を持つ 4 ノードのクラスタを考えてみます。ノードの 1 つが停止し、残り 3 つのノードが再構成しても、残りのノードは SCSI 予約要求を発行して、障害ノードから実際の共有デバイスを保護することはできません。これは、予約することによって、正当なクラスタメンバーの一部もデバイスに対して入出力要求を発行できなくなるためです。しかし、予約をしないと、障害ノードが稼動し、そのクラスタビューが最新でなくなっているにもかかわらず、共有デバイスに入出力要求を発行するという危険性があります。

次に、票割れが発生したときの問題を考えてみます。4 ノードのクラスタでは、さまざまなインターコネクト障害が考えられます。ここでは、パーティションの内部の各メンバーは互いに通信でき、パーティションの外部のクラスタノードとは通信できない、一群のクラスタノード全体を 1 つのパーティションと定義します。インターコネクト障害が発生すると、それぞれが 2 ノードで構成される 2 つのパーティション、あるいは 3 ノードと 1 ノードの 2 つのパーティションが形成される状況が考えられます。あるいは、4 ノードのクラスタが、ノードが 1 つずつの 4 つのパーティションになる可能性もあります。このどの状況でも、Sun Cluster は、残すパーティションと終了するパーティションについて、矛盾のない合意を得ようとします。

例 1: それぞれが 2 ノードで構成される 2 つのパーティションが形成された場合。2 ノードのクラスタにおける 1 対 1 の票割れのときと同様、どちらのパーティションの CMM も、残すパーティションと終了するパーティションを決定するための定足数は得られません。データの完全性と高可用性を実現するには、両方のパーティションを残すか、両方のパーティションを停止します。ノード 2 つのクラスタのときと同様、この問題は外部のデバイス (定足数ディスク) によって決定される可能性があります。それぞれのパーティション内の指名されたノードは、指定された定足数デバイスの予約を争うことができ、いずれかのパーティションが予約に成功します。そして、SCSI-2 予約の性質上、定足数デバイスの予約に成功したノードは同じパーティション内のもう一方のノードがデバイスにアクセスできないようにします。定足数デバイスには両方のノードに有用なデータが含まれており、このモデルは理想的ではありません。

例 2: 3 ノードと 1 ノードの 2 つのパーティションが形成された場合。過半数のパーティションが十分な定足数を得ているとしても、ここで最も重要な問題は、単独で分離されたノードには別の 3 つのノードに何が起きたのか分からないということです。3 つのノードが有効なクラスタを形成している場合は、この単独ノードは停止できます。しかし、3 つのノードが実際に障害を起こしていることも考えられます。この場合、単独で切り離されたノードは動作し続け、可用性を維持する必要があります。完全に通信手段が失われていて、調停する外部デバイスが存在しない場合は、決定することは不可能です。構成済みの外部定足数デバイスの予約を争うと、結果的に例 1 よりもさらに悪い状況になります。過半数パーティションのノードの 1 つが定足数デバイスを予約した場合、そのノードは、同じパーティション内の別の 2 つのノードがその定足数デバイスにアクセスできないようにします。しかし、さらに悪いことに、単独で分離されたノードが予約に成功した場合は、正常な可能性のある 3 つのノードがクラスタから失われる可能性があります。ここでもまた、ディスク予約による解決は適切に機能しません。

ディスク予約手法を利用できない場合もまた、インターコネクト障害や操作エラーが発生したときに、それぞれが分離された専用のパーティション内に複数の独立したクラスタが形成されやすくなります。上記の例 2 を考えてください。CMM または外部エンティティが何らかの方法で、過半数パーティションの 3 つのノードが留まり、単独で分離されたノードが終了するよう決定し、後で管理者が、インターコネクトを修復することなく終了されたノードを起動しようとしたと仮定します。単独ノードは依然として、どの残りのメンバーとも通信できないため、クラスタ内の唯一のノードと考えて、定足数デバイスを予約しようとします。事実上、低速デバイスの予約はないので、この試みは成功し、単独のノードは、自身を唯一のメンバーとする独立したクラスタを形成します。

つまり、すべてのノードから直接、アクセス可能な記憶装置を持つ 3 ノードまたは 4 ノードのクラスタに対して、単純な定足数予約手法は利用できません。次の 3 つの問題を解決するには、新しい手法が必要です。

  1. 3 ノードまたは 4 ノードのクラスタにおける票割れ状態をすべて解決する方法

  2. 障害ノードから共有デバイスを障害防護する方法

  3. 分離されたパーティションが複数の独立したクラスタを形成するのを防ぐ方法

3 ノードまたは 4 ノードのクラスタにおける票割れ状態を解決するには、 手動介入段階の操作エラーによってクラスタの完全性が損なわれる可能性があることに注意しながら、発見的な手法と手動介入を組み合わせます。「定足数デバイス (VxVM)」では、3 ノード以上のクラスタについて、クラスタパーティションが発生した場合の処置を決定するために指定できるポリシーについて説明しました。干渉主義のポリシーを選択した場合、すべてのパーティションの CMM は、各パーティションのすべてのクラスタ動作を一時停止して、有効なクラスタを形成し続けるパーティションと終了するパーティションについて、オペレータからの入力を待ちます。この場合、特定の 1 つのパーティションを残して、別のすべてのパーティションを終了させる作業は管理者が行います。複数のパーティションが有効なクラスタを形成できるようにすると、データ破壊が発生する可能性があります。

事前決定的なポリシーを選択した場合は、優先するノード (クラスタ内の最大または最小のノード ID を持つノード) が要求され、票割れ状態が発生すると、優先ノードを含むパーティションが自動的に新しいクラスタになります (可能な場合のみ)。この場合、別のすべてのパーティションは、手動で終了する必要があります。2 ノードのクラスタの場合、選択された定足数デバイスは、票割れが発生したときに同数になるのを防ぐ目的にのみ使用されます。票割れ状態は、4 ノードのクラスタでも発生することがあります。4 ノードのクラスタで票割れが発生すると、2 つのクラスタメンバーだけアクティブになります。ここでも定足数デバイスは 1 つの役割を果たしますが、その働きは限られたものです。

パーティションを残すように選択した後で問題になるのは、終了しているはずの別のパーティションからどのようにデータを効果的に保護するかということです。別のすべてのパーティションを終了しようとしても、パーティションを終了するコマンドがすぐには正しく実行されない可能性があります。効果的な障害防護機能がないと、終了要求を処理する前に、停止したノードが再稼動し、共有デバイスに保留中の入出力要求を発行する危険性が常に伴います。この場合、障害ノードは、パーティション内に有効なクラスタが形成される前にリセットされます。

障害ノードが再稼動して、多重ホストディスクに入出力要求を発行するのを防ぐには、残りのノードの 1 つが障害ノードを強制的に終了させ、端末集配信装置またはシステムサービスプロセッサ (Sun Enterprise 10000 システムの場合) によって、そのノードを OpenBoot PROM モードにして、オペレーティングシステムの停止イメージを終了します。OpenBoot PROM のプロンプトに対して go と入力することによって、誤ってシステムの動作が再開されるのを防止します。残りのクラスタメンバーは、クラスタの再構成プロセスに進む前に終了処理からの肯定応答を待ちます。

終了コマンドに対する応答がない場合は、パワーシーケンサ (存在する場合) が動作して、障害ノードの電源が入れ直されます。この動作に失敗した場合、システムは次のメッセージを表示して、クラスタの再構成を続行するための情報の入力を求めます。

/opt/SUNWcluster/bin/scadmin continuepartition localnode clustername
¥007*** ISSUE ABORTPARTITION OR CONTINUEPARTITION ***
You must ensure that the unreachable node no longer has access to the 
shared data. You may allow the proposed cluster to form after you have 
ensured that the unreachable node has aborted or is down.
Proposed cluster partition:
注 -

残りのノード上で scadmin continuepartition コマンドを発行する前に、必ず、障害ノードを正しく終了させてください。

パーティション化されて、分離され、終了されたノードは、最終的には起動します。何らかの誤りで、管理者がインターコネクトを修復することなくそのノードをクラスタに結合させようとした場合は、そのノードが既存のクラスタと通信できないときに、独自の有効なクラスタパーティションを形成するのを防ぐ必要があります。

3 ノードと 1 ノードの 2 つのパーティションが形成されていると仮定します。この場合は、過半数パーティションの指定されたノードは分離されたノードを終了し、3 つのノードはそれら専用のパーティション内に有効なクラスタを形成します。その後、管理者が startcluster(1M) コマンドを実行して、確認を求められたときに肯定的な応答をすると、分離されたノードは、起動後に独自のクラスタを形成しようとします。分離されたノードは自身がクラスタ内の唯一のノードであると判断するため、定足数デバイスの予約を試み、実際にその試みに成功します。これは、有効なパーティション内に 3 つのノードがあり、そのどれも、別のノードを締め出すことなしに定足数デバイスを予約できないためです。

この問題を解決するために、Sun Cluster 2.2 はノードロックを使用します。この場合、クラスタメンバーシップ内の指定されたクラスタは、クラスタの再構成の一環として、端末集配信装置の未使用ポートに対する telnet(1) セッションを開き、クラスタのメンバーである間、そのセッションを継続します。このノードがメンバーシップから切り離されようとすると、ノードロックは、残りのクラスタメンバーの 1 つに渡されます。上記の例で、分離されたノードが独自のクラスタを形成しようとする場合、そのノードはノードロックの取得を試み、失敗します。これは、別のパーティション内のメンバーシップノードの 1 つがノードロックを保持しているためです。有効なクラスタメンバーの 1 つが何らかの理由でノードロックを取得できなかった場合、そのことが重大なエラーとはみなされることはありませんが、ただちに対応する必要があるエラーとして記録されます。ロック機能は、クラスタの運用に不可欠な機能ではなく、安全上の機能とみなされ、ロック機能に問題が発生しても、危機的なエラーとはみなされません。ロックにおける障害を素早く検出するために、Sun Cluster フレームワーク内のプロセスは、端末集配信装置がクラスタノードからアクセスできるかどうかを監視します。

障害防護 (Solstice DiskSuite)

ボリュームマネージャとして Solstice DiskSuite を使用する Sun Cluster 構成では、Solstice DiskSuite 自体がクラスタの定足数を決定し、障害防護機能を提供します。障害防護について、クラスタのトポロジによる明確な違いはありません。すなわち、2 ノードのクラスタも、3 ノード以上のクラスタも同様に扱われます。これが可能なのは、次の 2 つの理由によります。

ディスクの防護は、次の手順で実現されます。

  1. クラスタからノードが削除されると、残りのノード 1 つがディスクを SCSI 予約します。この後、ディスクそのものによってクラスタのメンバーでなくなったノードをはじめとする別のノードが、ディスクに対する読み取りや書き込みを行うことが防止されます。ディスクは、読み取りあるいは書き込みコマンドに対して Reservation_Conflict エラーを返します。 Solstice DiskSuite の構成では、SCSI 予約は、Sun の多重ホストに対する ioctl の MHIOCTKOWN を発行することによって行われます。

  2. クラスタ内のメンバーは、アクセスしているディスクに対して連続的に MHIOCENFAILFAST ioctl を有効にします。この ioctl はディスクドライバに対する命令であり、別のノードによって予約されていて、ディスクにアクセスできない場合に、ノードが自身をパニック状態にできるようにします。MHIOCENFAILFAST ioctl によって、ドライバは、このノードがディスクに対して発行するすべての読み取りおよび書き込みコマンドについて、返されたエラーに Reservation_Conflict エラーコードがないかどうかを調べ、またバックグラウンドで定期的に、ディスクにテストを行なって、Reservation_Conflict が発生していないかどうかを検査します。Reservation_Conflict が返された場合は、フォアグラウンドとバックグラウンド両方の制御フローパスがパニックになります。

  3. MHIOCENFAILFAST は、デュアルホストのディスク専用の ioctl ではありません。ディスクに対して MHIOCENFAILFAST を有効にしたノードが、別のノードが予約 (SCSI-2 排他予約) しているためにそのディスクにアクセスできなくなった場合、ノードはパニックになります。

ディスク防護のためのこの解決策は、SCSI-2 のディスク予約の概念に依存しています。SCSI-2 ディスク予約では、1 つのノードだけがディスクを予約することができます。

Solstice DiskSuite の構成の場合、インストールプログラムの scinstall(1M) は、VxVM の構成のときのように、定足数デバイスの指定やノードの設定を求めたり、障害防護ポリシーの選択を求めたりしません。

クラスタのパーティション化の防止 (VxVM)

2 ノードのクラスタ

2 ノードのクラスタでインターコネクト接続が失われた場合、両方のノードは、相手からのハートビートが得られなくなったことにより、クラスタメンバーシップ内のローカルノードだけでクラスタ再構成プロセスを開始しようとします。構成済み定足数デバイスの予約に最初に成功したノードが、クラスタの唯一の残りのメンバーとして留まります。定足数デバイスの予約に失敗したノードは、終了します。

障害が発生したインターコネクトを修復することなく、終了したノードを起動しようとすると、残りのノードと通信できず、そのノードは自身をクラスタの唯一のノードとみなすため、定足数デバイスを予約しようとします。定足数デバイスは、すでにもう一方のノードによって予約されているため、この試みは失敗します。結果的に、この動作は、パーティション化されたノードが独自のクラスタを形成するのを防ぎます。

3 ノードまたは 4 ノードのクラスタ

端末集配信装置 (TC) によってリセット要求が発行された結果、4 ノードのクラスタから 1 つのノードが切り離された場合、残りのクラスタノードの中には、定足数デバイスを予約できないものが出てきます。これは、残りのノードのいずれか１つが予約することによって、残りの 2 つの正常なノードが定足数デバイスにアクセスできなくなるためです。パーティション化されたノード上で誤って scadmin startcluster コマンドを実行した場合、そのノードは別のノードと通信できないため、独自のクラスタを形成してしまいます。事実上、パーティション化されたノードが独自のクラスタを形成するのを防ぐ定足数デバイスの予約はありません。

3 ノードまたは 4 ノードのクラスタ構成では、Sun Cluster は、定足数方式ではなく、クラスタ全体のロック (ノードロック) 機能に助けを求めます。この機構では、クラスタの TC または SSP の未使用ポートが利用されます (構内全体のクラスタには、複数の TC が使用される)。インストールでは、このノードロック機能用に TC または SSP を選択してください。この情報は、CCD に格納されます。クラスタがアクティブな間、すなわち、最初のノードが正しく新しいクラスタを形成してから、最後のノードがクラスタから切り離されるまで、このロックは、常にクラスタメンバーの 1 つが保持します。ロックを保持しているノードで問題が発生した場合、ロックは自動的に別のノードに移されます。

ノードロックの働きはただ 1 つ、票割れ状態のときに、管理者のエラーによって新しいクラスタが起動されるのを防ぐことです。

注 -

クラスタに最初に結合するノードがノードロックを取得できない場合、そのノードは終了します。クラスタの 2 つ目以降のノードがノードロックを取得できなくても、ノードの障害やノードの終了が発生することはありません。

ノードロックは、次のように機能します。

Sun Clusterがサポートする構成

クラスタは、一群の物理ホスト (ノード) で構成されます。Sun Cluster のマニュアルでは、クラスタのノードは Sun Cluster サーバーとも呼びます。

このリリースの Sun Cluster では、ハードウェア構成として、対称、非対称、クラスタ化ペア、リング、N+1 (星型)、N to N (スケーラブル) トポロジをサポートしています。以降、この章では、これらのトポロジをそれぞれ詳しく説明します。

注 -

リングトポロジは Solaris 2.6 と Solaris 7 だけでサポートされます。Solaris 8 ではサポートされません。

対称構成では、ノードは 2 つだけです。両方のサーバーは同じ構成であり、一般に、通常の運用では両方がデータサービスを提供します。図 1-12 を参照してください。

一方のサーバーがもう一方のサーバーのホットスタンバイサーバーとして動作する 2 ノードの構成は、非対称構成といいます。この構成は、N+1 (N=1) 構成として扱われます。

クラスタ化ペアは、1 つのクラスタ管理フレームワークの下で動作する 2 つの Sun Cluster ノードペアです。

リング構成では、データサービスの 1 つのセットごとに主サーバーとバックアップサーバーを 1 つずつ指定できます。すべてのディスク記憶装置が二重ホスト化され、正確に 2 つのクラスタノードに物理接続されます。ノードおよび記憶装置は、リング内に交互に接続されます。リング構成は、オンラインの複数の高可用性データサービスを構成するのに理想的です。図 1-14 を参照してください。

N+1 (星型) 構成は、2 つ以上のノードで構成されます。N+1 構成内のノード (+1 のノード) は、別のノードで障害が発生しない限り、アクティブにならないよう構成することができます。この構成では、+1 のノードは、「ホットスタンバイ」として機能します。通常の運用では、残りのノードはアクティブです。この章の例では、通常の運用では、ホットスタンバイノードはデータサービスを実行しないことを前提にしています。しかし、通常の運用で +1 のノードがデータサービスを実行しないことが必須というわけではありません。図 1-15 を参照してください。

N to N (スケーラブル) 構成では、すべてのサーバーが 1 組の共有ディスクに直接、接続されます。データサービスが別のどのサーバーにでもフェイルオーバーできるため、これは最も柔軟性がある構成です。図 1-16 を参照してください。

高可用性と並列データベースの構成

Sun Cluster は、HA データサービスと並列データベースの構成をサポートしています。いくつかの制限がありますが、HA および 並列データベースを 1 つのクラスタ内で組み合わせることもできます。

HA 構成内のデータサービスは、複数のホストを同じ物理ディスク格納装置に接続することによって高可用性になります。各ホストの状態は、プライベートインターコネクトを介して監視されます。ホストの 1 つで問題が発生すると、同じ共有記憶装置に接続されている別のホストが、障害ホストの行なっていたデータサービス業務を引き継ぐことができます。図 1-10 は、高可用性データサービス構成の例です。

図 1-10 高可用性データサービス構成

Graphic

Oracle Parallel Server (OPS) は、複数のホストが共有記憶装置上の同じデータにアクセスすることを可能にすることによってリレーショナルデータベースを高可用性にします。共有ディスク格納装置へのトラフィックは、2 つのプロセスが同時に同じデータにアクセスすることを防止する DLM によって制御されます。高可用性は、データベースへのアクセストラフィックを障害ホストから残りのノードの 1 つにリダイレクトすることによって実現されます。図 1-11 は、高可用性 OPS 構成の例です。プライベートインターコネクトは SCI (Scalable Coherent Interface) または Fast Ethernet のどちらでもかまいません。

図 1-11 OPS データベース構成

Graphic

Informix-Online XPS 並列データベースは、複数の共有記憶装置にまたがってリレーショナルデータベースをパーティション分割することによって並列アクセスを可能にします。複数のホストプロセスは、同じパーティションに格納されているデータにアクセスするのでなければ、同じデータベースに同時にアクセスできます。特定の 1 つのパーティションへのアクセスは 1 つのホストによって行われるため、そのホストで問題が発生すると、そのパーティションのデータは利用できなくなります。このため、Informix-Online XPS は並列データベースではありますが、Sun Cluster 内で高可用性の構成にすることはできません。

対称構成と非対称構成

定義では、対称および非対称 HA 構成は、正確に 2 つのノードで構成されます。高可用性データサービスは、そのうちの 1 つまたは両方のノードで動作します。図 1-12 は、2 ノードの構成を表しています。この構成例では、兄弟と呼ばれる 2 つのアクティブなノード (phys-hahost1 と phys-hahost2) で構成されます。

両方のノードとも、1 組の多重ホストディスクに物理接続されます。

図 1-12 2 ノードの構成

Graphic

クラスタ化ペア構成

クラスタ化ペア構成は、対称構成の変形です。クラスタ化ペア構成では、2 つのサーバーのペアがあり、それぞれのペアが独立して動作します。しかし、サーバーのすべてはプライベートインターコネクトによって接続され、Sun Cluster ソフトウェアの制御下に置かれます。

図 1-13 クラスタ化ペア構成

Graphic

クラスタ化ペアは、一方のペアで並列データベースアプリケーション、もう一方のペアで HA データサービスを実行できるように構成できます。フェイルオーバーは、1 つのペア上でのみ可能です。

リング構成

リング構成では、データサービスの 1 セットごとに主サーバーとバックアップサーバーを 1 つずつ指定できます。特定のデータサービスについて、主サーバーに隣接するノードがバックアップです。すべてのディスク記憶装置が二重ホスト化され、正確に 2 つのクラスタノードに物理接続されます。リング内には、ノードおよび記憶装置が交互に接続されます。すべてのノードがアプリケーションを実行できます。1 つのノードが 1 つのデータサービスセット用の主サーバーであると同時に、別のデータサービスセットのバックアップになります。図 1-14 は、4 ノードのリング構成を表しています。

注 -

リング構成には、同じノード上で複数の RDBMS データサービスを実行できないという制限があります。

注 -

リングトポロジは Solaris 2.6 と Solaris 7 ではサポートされますが、Solaris 8 ではサポートされません。

図 1-14 リング構成

Graphic

N+1 (星型) 構成

N+1 (星型) 構成は、複数のアクティブサーバーと 1 つのホットスタンバイサーバーで構成されます。アクティブサーバーとホットスタンバイサーバーを同じ構成にする必要はありません。図 1-15 は、N+1 構成を表しています。アクティブサーバーはデータサービスを提供し、ホットスタンバイサーバーはアクティブサーバーの障害に備えて待機します。ホットスタンバイサーバーは、構成内において、すべてのディスク拡張装置に対する物理的なディスク接続を持つ唯一のサーバーです。

アクティブなサーバーの 1 つで障害が発生した場合、障害サーバーが提供していたデータサービスはホットスタンバイサーバーにフェイルオーバーされます。その後、ホットスタンバイサーバーは、データサービスが元のアクティブサーバーに手動でスイッチオーバーされるまでデータサービスを提供し続けます。

別の Sun Cluster サーバーの障害に備えて待機している間、ホットスタンバイサーバーがアイドル状態になっている必要はありません。しかし、ホットスタンバイサーバーには、常に、アクティブサーバーの 1 つで問題が発生したときの負荷を処理するために必要十分な CPU 能力を残しておいてください。

図 1-15 N+1 構成

Graphic

N to N (スケーラブル) 構成

N to N (スケーラブル) 構成では、すべてのサーバーがすべての多重ホストディスクに物理接続されます。1 つのノードが提供していたデータサービスは、1 つまたは複数のバックアップにフェイルオーバーできます (階層式フェイルオーバー)。

N to N 構成は、データサービスが最高 3 つの別のノードにフェイルオーバーできるため、最も冗長な構成です。

図 1-16 N to N 構成

Graphic

構内クラスタ化

Sun Cluster は、構内クラスタ化をサポートしています。これは、サイトを地理的に隔てて、特定の種類の障害からの回復を可能にするクラスタ構成です。そうした障害は、構内の一部に局所化されます。

すべてのサーバーと記憶装置を、物理的に 1 つのサーバールームに集中することも、地理的に複数のサイトに分散させることもできます。地理的に分散すると、火災などの大惨事からデータを保護することができ、このため全体のデータサービスの可用性が向上します。

構内クラスタ化についての詳細は、ご購入先にお問い合わせください。

ソフトウェア構成

Sun Cluster には、次のソフトウェアコンポーネントが含まれています。

これらのソフトウェアコンポーネントに関係する論理コンポーネントは、次のとおりです。

以下の節では、これらのコンポーネントについて説明します。

クラスタフレームワーク

図 1-17 は、Sun Cluster で HA データサービスをサポートするために必要なフレームワークを構成するさまざまなコンポーネントの適切な階層構造を表しています。ただし、この図には、Sun Cluster のさまざまなコンポーネント間の関係は示されていません。最も内側のコアは、現在のクラスタメンバーシップの記録を取るクラスタメンバーシップモニター(CMM) で構成されます。ノードがクラスタから切り離されるか、再結合するたびに、そのクラスタノード上の CMM は、分散メンバーシッププロトコルを経由して、新しいクラスタメンバーシップの合意を図ります。新しいメンバーシップが確定すると、CMM は、Sun Cluster フレームワークを使用して別のクラスタコンポーネントの再構成を調整します。

図 1-17 Sun Cluster のソフトウェアコンポーネント

Graphic

Sun Cluster 構成では、ハードウェアやソフトウェアに問題が発生した場合に、メンバーシップモニター、障害モニター、関係するプログラムによって、障害が発生した Cluster サーバーから別の Cluster サーバーに、すべてのデータサービス処理を引き継ぐことを可能にします。これは、障害の発生した Cluster サーバーに関連付けられている論理ホストをマスターする権利を、クラスタサーバーに引き継ぐことによって実現されます。一部の種類の障害では、フェイルオーバーは発生しません。一般に、ディスクドライブ障害では、フェイルオーバーは行われず、ミラー化によって対処されます。同様に、障害モニターによってソフトウェア障害が検出された場合は、別のノードへのフェイルオーバーは行われずに、同じ物理ノード上でデータサービスが再開されます。

障害モニター層

障害モニター層は、障害デーモン 1 つと、データサービスのさまざまな部分を検証するためのプログラムで構成されます。サービスの障害を検出した場合、障害モニターは、データサービスがどのように構成されているかによって、同じノード上でのサービスの再開または論理ホストのフェイルオーバーを試みることができます。

いくつかの環境では、サービスの中断があっても、データサービス障害モニターは、フェイルオーバーを開始しません。これに対する例外は、次の場合です。

データサービス層

Sun Cluster には、サンによって高可用性が実現された一群のデータサービスが付属しています。Sun Cluster は、データサービス層で障害モニターを提供します。この障害モニターが提供する障害検出レベルは、個々のデータサービスによって異なります。障害検出レベルは、いくつかの要因に依存します。Sun Cluster データサービスに対する障害モニターの働きについての詳細は、『Sun Cluster 2.2 のシステム管理』を参照してください。

サーバーを検証するときに、障害モニターは local7 メッセージ機能を利用します。この機能が生成するメッセージは、サーバー上のメッセージの設定に従って、メッセージファイルに記録するか、コンソールに表示できます。メッセージの設定についての詳細は、syslog.conf(4) のマニュアルページを参照してください。

Sun Cluster がサポートするデータサービス

Sun Cluster は、リレーショナルデータベースや並列データベース、インターネットサービス、資源管理データサービスなどのいろいろなアプリケーションに HA サポートを提供します。今回の Sun Cluster のリリースでは、次のデータサービスがサポートされています (データサービスとサポートされているバージョンの最新の情報については、『Sun Cluster 2.2 ご使用にあたって』を参照するか、ご購入先にお問い合わせください)。

データサービス API

Sun Cluster ソフトウェアには、Sun Cluster HA フレームワーク下で、既存のデータサービスを高可用性にすることを可能にするアプリケーションプログラミングインタフェース (API) が付属しています。データサービスは、クラスタの再構成のいくつかの重要なポイントで HA フレームワークによってコールバックされるメソッド (プログラム) を登録します。Sun Cluster には、データサービスのメソッドが Sun Cluster 構成の状態を照会したり、テイクオーバーを開始したりすることを可能にするユーティリティも付属しています。そのほか、データサービスのメソッドによるファイルロック保持中のプログラムの実行や、タイムアウト値を設定したプログラムの実行、プログラムが終了した場合の自動再起動を簡単に行えるようにするユーティリティもあります。

データサービス API についての詳細は、『Sun Cluster 2.2 API 開発ガイド』を参照してください。

スイッチ管理エージェント

スイッチ管理エージェント (SMA) ソフトウェアコンポーネントは、SCI リンクおよびスイッチに対するセッションを管理します。同様に、Ethernet リンクおよびスイッチ上のセッションも管理します。また、SMA は個別リンク障害からアプリケーションを切り離し、すべてのアプリケーションに対して論理リンクの概念を提供します。

クラスタ SNMP エージェント

Sun Cluster には、クラスタ用に MIB (Management Information Base) とともに SNMP (Simple Network Management Protocol) エージェントが付属します。このエージェントファイルの名前は snmpd (SNMP デーモン)、MIB の名前は sun.mib です。

Sun Cluster の SNMP エージェントは、同時に複数のクラスタ (最高 32 個) を監視できます。通常の Sun Cluster 構成では、クラスタは、管理ワークステーションまたはシステムサービスプロセッサ (Sun Enterprise 10000 の場合) から管理できます。クラスタは、管理ワークステーション (またはシステムサービスプロセッサ) に Sun Cluster の SNMP エージェントをインストールすることによって、SNMP パケットの送信時に、ネットワークトラフィックが規制され、ノードの CPU パワーが浪費されなくなります。

クラスタ構成データベース

クラスタ構成データベース (CCD) は、Sun Cluster 構成に合わせて内部構成情報を格納するための、可用性の高い複製データベースです。CCD は、Sun Cluster が内部で利用するデータベースです。パブリックインタフェースではないため、直接、CCD を更新しないでください。

CCD は、クラスタメンバーシップモニター (CMM) サービスに基づいて、現在のクラスタメンバーシップと、整合性ドメイン、すなわち、整合性のとられたデータベースコピーを保持して、更新を伝達するノード群を特定します。CCD データベースは、初期データベースと動的データベースの 2 つに分かれます。

初期 CCD データベースの目的は、scinstall による CCD パッケージのインストール中に値が設定される、変更不可能な起動寺構成パラメータを格納することにあります。動的 CCD には、残りのデータベースエントリが含まれます。初期 CCD と異なり、動的 CCD 内のエントリは、CCD データベースが回復されていること (すなわち、クラスタが動作していること)、そして CCD が定足数を得ていることという制限付きで、いつでも更新できます (定足数の定義については、「CCD の動作」を参照)。

初期 CCD (/etc/opt/SUNWcluster/conf/ccd.database.init) はまた、CCD が動作する前に起動されるコンポーネントに関する情報の格納にも使用されます。このことは、CCD データベースが回復し、広域的な整合性が検査される前に初期 CCD への照会を行えることを意味します。

動的 CCD (/etc/opt/SUNWcluster/conf/ccd.database) には、そのほかのデータベースエントリが含まれます。CCD は、その整合性ドメインの全ノードにまたがって動的 CCD の整合性のとられた複製が作成されるようにします。

ノード障害が発生したときでも確実に利用できるよう、CCD データベースは、すべてのノード上に複製が作成されます。CCD デーモンは互いの間で通信を確立して、CCD 整合性ドメイン内でのデータベース処理の同期と直列化を図ります。データベースの更新および照会要求は、どのノードからでも発行できます。CCD には、シングルポイント制御はありません。

また、CCD は以下を提供します。

CCD の動作

CCD は、選出された整合性ドメインの全ノードで整合性のとれたデータベースの複製が存在するようにします。有効な CCD のコピーが検出されたノードだけが、クラスタへの結合を許可されます。整合性の検査は、局所的と広域的の 2 つのレベルで行われます。局所的には、それぞれのデータベースコピーは、データベースの検査合計と長さを保持した整合性レコードを内蔵しています。この整合性レコードは、データベースの更新または回復が行われたときのローカルのデータベースコピーの妥当性を検査します。整合性レコードは、データベースの最終更新日時を記録します。

CCD はまた、広域的な整合性検査を行なって、すべてのノードに存在するデータベースのコピーが同じであることを確認します。CCD デーモンは整合性レコードを交換して、その妥当性の検査をします。クラスタの再起動中、データベースの回復には定足数投票方式が使用されます。回復プロセスによって、CCD の有効なコピーが存在するノード数 (整合性レコードを使用して、局所的な整合性が検査される) と、同一内容 (検査合計と長さが同じ) のコピー数が求められます。

過半数のノードが動作しているときに、CCD コピーを最新にするには、デフォルトの整合性ドメイン内に定足数の過半数が検出される必要があります。

注 -

CCD を更新するには、定足数の過半数が必要です。

式 Q= [Na/2]+1 は、CCD を更新するために必要なノード数を規定します。Na は、クラスタ内に物理的に存在するノード数です。ノードは物理的に存在しますが、クラスタソフトウェアを実行していないこともあります。

VERITAS Volume Manager を使用した 2 ノードのクラスタの場合、定足数は、共有 CCD ボリュームを使用し、ノード数が 1 つだけ上回ることによって維持されることがあります。共有 CCD 構成では、CCD のコピーが各ノードのローカルディスクに保持され、別のコピーが、ノード間で共有可能な特殊なディスクグループに保持されます。通常の運用では、ローカルディスク上のコピーだけが利用されますが、ノードの 1 つで問題が発生した場合は、共有 CCD が使用されて、クラスタ内にノード 1 つだけで CCD 定足数が維持されます。障害ノードがクラスタに再結合した場合、そのノードは、共有 CCD の現在のコピーを使用して更新されます。2 ノードのクラスタにおける共有 CCD ボリュームの設定についての詳細は、第 3 章「Sun Cluster ソフトウェアのインストールと構成」を参照してください。

ノードの 1 つが動作し続けている場合は、そのノードの有効な CCD を新たに結合するノードに伝達できます。CCD 回復アルゴリズムは、有効なコピーが検出され、すべてのノード上に正しくその複製が作成されている場合にだけ CCD データベースが動作するようにします。回復に失敗した場合は、ユーザーが介入して、どの CCD コピーが有効であるかを決定する必要があります。こうして選出されたコピーを使用して、データベースを復元できます。このデータベースの復元には、ccdadm -r コマンドを使用します。CCD を管理する手順については、『Sun Cluster 2.2 のシステム管理』を参照してください。

注 -

CCD には、データベースの現在の内容を記憶するバックアップ機能 (ccdadm(1M) を使用) があります。データベースの現在の内容を記憶することにより、バックアップコピーを使用して、データベースを復元することができます。詳細は、ccdadm(1M) のマニュアルページを参照してください。

ボリュームマネージャ

Sun Cluster は、Solstice DiskSuite および VERITAS Volume Manager (VxVM) のボリュームマネージャをサポートしています。これらのボリュームマネージャは、Sun Cluster にミラー化、連結、ストライプ化機能を提供します。 ボリュームマネージャは、複数のディスクを、1 つの単位として管理できるディスクグループ (VxVM) またはディスクセット (Solstice DiskSuite) に編成します。

Sun StorEdge A3000 ディスク拡張装置には、Sun StorEdge A3000 ハードウェア内のディスクすべてをミラー化、結合、ストライプ化する機能もあります。詳細は、Sun StorEdge A3x00 のマニュアルを参照してください。

Solstice DiskSuite と VERITAS Volume Manager を同時に使用できるのは、Solstice DiskSuite でローカルディスクを管理し、VERITAS Volume Manager で多重ホストディスクを制御する場合に限ります。このような構成では、物理ディスクの必要量を構成に応じて増加する必要があります。たとえば、VERITAS Volume Manager の場合、ルートディスクグループ用に追加のディスクが必要になることがあります。詳細は、ボリュームマネージャのマニュアルを参照してください。

ボリュームマネージャについての詳細は、使用しているボリュームマネージャのマニュアルおよび 「ボリューム管理」 を参照してください。

ディスクグループおよびディスクセット

ディスクグループ (VxVM の用語) やディスクセット (Solstice DiskSuite の用語) は、ボリュームマネージャの制御下にある一連のディスクを意味する用語です。ボリュームマネージャでは、RAID-0、RAID-1、または RAID-5 構成の共用ディスクがサポートされます。あらゆるデータサービスおよび並列データベースデータは、共有ディスク上のディスクグループまたはディスクセットに格納されます。一般に、ディスクグループ内のミラーは、物理的にミラーの半分がそれぞれ異なるディスク拡張装置内に置かれ、異なるコントローラまたはホストアダプタに接続されるように編成されます。こうすることによって、1 つのディスクまたはディスク拡張装置の障害をシングルポイント障害として排除します。

ディスクグループまたはディスクセットは、raw データ記憶装置かファイルシステム、またはその両方に使用できます。

論理ホスト

Sun Cluster の論理ホストは、1 つの単位として Sun Cluster サーバー間を移動可能な資源の集まりです。Sun Cluster では、資源は、ネットワークホスト名とそのホストに関連付けられた IP アドレスのコレクションに 1 つ以上のディスクグループを加えたものです。OPS 構成などの HA 以外のクラスタ環境では、IP アドレスは特定のホストシステムに固定的に対応付けられます。クライアントアプリケーションは、サーバーアプリケーションを実行するホストの IP アドレスを指定することによって、サーバー上のデータにアクセスします。

Sun Cluster では、IP アドレスは論理ホストに割り当てられ、どのようなホストシステムでも、アプリケーションサーバーが現在動作しているホストシステムに一時的に関連付けられます。こうした IP アドレスは再配置可能なため、ノード間を移動できます。Sun Cluster 環境では、クライアントは、物理ホストシステムの IP アドレスではなく、論理ホストの再配置可能 IP アドレスを指定して、アプリケーションに接続します。

次の図 1-18 の論理ホスト hahost1 は、ネットワークホスト名 hahost1、再配置可能 IP アドレス 192.9.200.1、ディスクグループ diskgroup1 と定義されます。論理ホスト名とディスクグループ名が同じである必要はないことに注意してください。

図 1-18 論理ホスト

Graphic

論理ホストは、パブリックネットワークごとに 1 つの論理ホスト名と 1 つの再配置可能 IP アドレスを持ちます。主論理ホスト名は、主パブリックネットワーク上で論理ホストが認識される名前です。二次論理ホスト名は、二次パブリックネットワーク上で論理ホストが認識される名前です。図 1-19 は、hahost1 と hahost2 という主論理ホスト名を持つ 2 つの論理ホストのホスト名と再配置可能 IP アドレスを表しています。この図の二次論理ホスト名の接尾辞には、ネットワーク番号の最後の要素 (201) が使用されています。たとえば、hahost1-201 は、論理ホスト hahost1 の二次論理ホスト名です。

図 1-19 複数のパブリックネットワーク上の論理ホスト

Graphic

論理ホストは、物理ホストによってマスターされます。論理ホストを現在マスターしている物理ホストだけが、その論理ホストのディスクグループにアクセスできます。物理ホストは複数の論理ホストをマスターできますが、各論理ホストは、一度に 1 つの物理ホストだけしかマスターできません。特定の論理ホストをマスターする能力をもつ物理ホストを、その論理ホストの潜在的マスターといいます。

データサービスは、物理ホストに関連付けられている既知の論理ホスト名を知らせることによって、ネットワーク上のクライアントがそのサービスを利用できるようにします。論理ホスト名はサイトの IP 名前空間の一部ですが、特定の物理ホスト名が割り当てられているわけではありません。クライアントは論理ホスト名を使用して、データサービスが提供するサービスを利用します。

図 1-20 は、複数のデータサービスが 1 つの論理ホストのディスクグループに置かれている構成を表しています。この例では、論理ホスト hahost2 が現在 phys-hahost2 によってマスターされていると仮定します。この構成で phys-hahost2 に問題が発生すると、両方の Sun Cluster HA for Netscape データサービス (dg2-http と dg2-news) が phys-hahost1 にフェイルオーバーされます。

図 1-20 論理ホストとデータサービスとデータサービスファイル

Graphic

論理ホスト上にデータサービスを構成する方法を決定するにあたっての考慮事項については、第 2 章「構成の計画」を参照してください。

パブリックネットワーク管理 (PNM)

発生した障害の種類によっては、障害の発生したノード上に置かれていたすべての論理ホストが別のノードに転送されます。ノードとパブリックネットワーク間のネットワークアダプタカード、コネクタ、ケーブルの障害では、結果的にノードのフェイルオーバーは必要ありません。Sun Cluster フレームワークのパブリックネットワーク管理 (PNM) ソフトウェアは、ネットワークアダプタの 1 つで問題が発生した場合に、同じグループの別のアダプタがネットワーク要求の処理サービスを引き継げるようネットワークアダプタをグループに編成することを可能にします。エラー検出とフェイルオーバー機能が動作している間の遅延はごくわずかなものです。

PNM を使用した構成では、同じサブネット上に複数のネットワークインタフェースが存在します。これらインタフェースによって、バックアップグループが構成されます。常に、1 つのネットワークアダプタは 1 つのバックアップグループにだけ所属でき、バックアップグループ内の 1 つのアダプタだけがアクティブになります。アクティブなアダプタで問題が発生すると、PNM ソフトウェアは、同じバックアップグループ内の別のアダプタを使用するようにネットワークサービスを切り替えます。パブリックネットワーク用に使用するすべてのアダプタは、1 つのバックアップグループにまとめてください。

注 -

バックアップグループはまた、同一ノードのフェイルオーバーアダプタが存在しないときでもパブリックネットの監視に使用されます。

図 1-21 ネットワークアダプタのフェイルオーバー構成

Graphic

PNM の構成と管理については、『Sun Cluster 2.2 のシステム管理』を参照してください。

システムフェイルオーバーとスイッチオーバー

Sun Cluster HA 構成でノードに問題が発生すると、そのノード上で動作していたデータサービスは、同じサーバーセット内の正常なノードに自動的に移動されます。フェイルオーバーソフトウェアは、論理ホストの IP アドレスを障害ホストから正常なノードに移動します。障害ホストによってマスターされていた論理ホスト上で動作していたすべてのデータサービスも移動されます。

システム管理者は、手動で論理ホストのスイッチオーバーを行うことができます。フェイルオーバーとスイッチオーバーの違いは、前者が、ノードに問題が発生したとき Sun Cluster ソフトウェアによって自動的に処理されるのに対し、後者はシステム管理者が手動で行うという点です。スイッチオーバーは、クラスタノードの定期的な保守またはソフトウェアのアップグレードを行うときに行います。

図 1-22 は、正常に稼働している 2 ノードの構成を表しています。それぞれの物理ホストが 1 つの論理ホストをマスターしていることに注意してください (実線で示しています)。2 つのクライアントが、この 2 つの論理ホスト上の異なるデータサービスを利用しています。

図 1-22 フェイルオーバーまたはスイッチオーバー前の対称構成

Graphic

phys-hahost1 で問題が発生した場合、論理ホスト hahost1 は、phys-hahost2 に移動されます。hahost1 の再配置可能 IP アドレスは phys-hahost2 に移動し、データサービス要求は phys-hahost2 に送信されます。クラスタの再構成が行われている間、hahost1 上のデータを利用するクライアントでは短時間の遅延が発生します。図 1-23 は、上図の、フェイルオーバーまたはスイッチオーバー後の新しい構成です。

(物理ホスト phys-hahost2 になった) phys-hahost1 上の論理ホスト hahost1 にアクセスしていたクライアントシステムが、引き続き物理ホスト phys-hahost2 上の同じ論理ホストにアクセスすることに注意してください。フェイルオーバーの場合、この引き継ぎは、クラスタの再構成によって自動的に行われます。フェイルオーバーの結果、phys-hahost2 は、hahost1 と hahost2 の両方の論理ホストをマスターするようになっています。関連付けられているディスクセットは、phys-hahost2 経由でのみアクセスできます。

図 1-23 フェイルオーバーまたはスイッチオーバー後の対称構成

Graphic

部分的フェイルオーバー

1 つの物理ホストが複数の論理ホストをマスターできるということは、データサービスの部分的フェイルオーバーが可能であるということです。図 1-24 は、物理ホスト 3 つと論理ホスト 5 つの星型構成を表しています。この図では、物理ホストと論理ホストを結ぶ線によって、どの物理ホストがどの論理ホスト (およびディスクグループ) を現在マスターしているかを示しています。

phys-hahost1 によってマスターされている 4 つの論理ホスト (実線で示されています) は、個別にホットスタンバイサーバーにフェイルオーバーできます。図 1-24 のホストスタンバイサーバーは、全多重ホストディスクに物理接続されていますが、どの論理ホストもマスターしていないことに注意してください。

図 1-24 複数論理ホスト構成の部分的フェイルオーバー以前

Graphic

図 1-25 は、hahost5 だけがホットスタンバイサーバーにフェイルオーバー (部分的フェイルオーバー) した後の構成を表しています。

部分的フェイルオーバーでは、phys-hahost1 が論理ホスト hahost5 をマスターする権利を放棄し、phys-hahost3 (ホットスタンバイサーバー) がその権利を引き継ぎます。

図 1-25 複数論理ホスト構成の部分的フェイルオーバー後

Graphic

同じ論理ホスト上にデータサービスを配置することによって、どのデータサービスを一緒にフェイルオーバーさせるかを制御できます。論理ホスト上のデータサービスの結合または分離に関係する問題については、第 2 章「構成の計画」を参照してください。

並列データベースに対するフェイルオーバー

並列データベース環境には、論理ホストの概念はありません。しかし、ノードで障害が発生した場合にノード間を移動できる再配置可能 IP アドレスの概念はあります。再配置可能 IP アドレスとフェイルオーバーについては 「論理ホスト」および 「システムフェイルオーバーとスイッチオーバー」を参照してください。