クラスタマネージャの動作

クラスタの構成

システム管理者は、クラスタの構成パラメータを設定して、クラスタの最初の起動を行います。その後、クラスタは通常の動作時に自動的に調整を行うので、人が介在して調整する必要はありません。クラスタの構成パラメータには、クラスタの名前、ノード、クラスタのハートビート用のネットワークパラメータ、クラスタのロック情報、タイミングパラメータがあります (詳しくは第4章 「HA クラスタのプランニングと文書化」を参照してください)。クラスタのパラメータを設定するには、Serviceguard Manager を使用するか、クラスタ構成ファイルを編集します (第5章 「HA クラスタの構成」を参照)。 入力したパラメータを使ってバイナリ構成ファイルが作成され、作成されたファイルはクラスタ内のすべてのノードへ配布されます。このファイルはクラスタ内のすべてのノードで同一でなければなりません。

ハートビートメッセージ

クラスタマネージャの主な作業は、クラスタ内のノード間のハートビートメッセージの送受信です。クラスタ内の各ノードは、ハートビートデバイスとして構成された監視対象の TCP/IP ネットワークを使って、クラスタコーディネータとハートビートメッセージを交換します (LAN の監視については、本章で後述する「LAN インタフェースの監視と障害の検出」の項を参照してください)。

1 台のクラスタノードが、規定時間内に他のすべてのクラスタノードからハートビートメッセージを受信しなかった場合、クラスタの再編成が開始されます。新しいノードセットでクラスタを形成する場合は、再編成の終了時にその情報がパッケージコーディネータへ渡されます (詳しくは、「パッケージマネージャの動作」を参照してください)。 新しいクラスタに属さないノード上でこれまで実行されていたフェイルオーバーパッケージは、引き継ぎノードへ移されます。ハートビートが一時的に失われた場合、クラスタは以前と同じノードを使って再編成を行う可能性があります。このような場合は、クラスタの再編成時にアプリケーションの性能が若干の影響を受ける場合がありますが、パッケージが中断したり切り替わることはありません。

ハートビートとデータが同じ LAN サブネットを通じて送信される場合、データ輻輳 (ふくそう) によってハートビートのタイムアウト時間内に Serviceguard がハートビートを見逃し、データ輻輳がなければ不要であったクラスタの再編成を開始する場合があります。このような状況を防止するには、ハートビート用に専用の LAN を使うと共に、データネットワーク上でハートビートを構成することをお勧めします。

	重要: 複数のハートビートが構成されていると、ハートビートは並行して送信されます。クラスタノードを相互接続するすべてのサブネットをハートビートネットワークとして構成することをお勧めします。これにより、コストを追加せずに複数の障害に対するデータ保護が強化されます。 ハートビート IP アドレスは、各ノードで同じサブネット上に存在しなければなりません。ハートビートの要件についての詳細は、「クラスタ構成のパラメータ」の「クラスタ構成のパラメータ」にある HEARTBEAT_IP のエントリーを参照してください。 Veritas Cluster Volume Manager (CVM) バージョン 3.5 を使用する場合 (システムがサポートしている場合)、使用できるのは単一のハートビートサブネットだけです。この場合、ハートビートは、予備の LAN と共に構成するか、各ノードでアグリゲーションポートのグループとして構成しなければなりません。「冗長ハートビートサブネットが必要」を参照してください。

	注記: シリアル (RS232) ライン、FDDI、または Token Ring ネットワークでは、ハートビートを送信できなくなりました。

各ノードは、クラスタのハートビート間隔ごとに、指定された速度でハートビートメッセージを送信します。クラスタのハートビート間隔は、クラスタ構成ファイルで設定します。このクラスタ構成ファイルは、クラスタ構成作業時に作成するものです。詳しくは、第5章 「HA クラスタの構成」を参照してください。

クラスタ全体の手動による起動

手動での起動により、クラスタ構成内の全ノードで 1 つのクラスタが形成されます。通常は、クラスタ全体の保守やアップグレードの後、または再構成後に、初めてクラスタを起動するときに手動で起動します。

起動前に、クラスタ内のすべてのノードに同じバイナリ形式クラスタ構成ファイルがなければなりません。システム管理者は、Serviceguard Manager を使用するか、いずれかのノードから cmruncl コマンドを実行することによりクラスタを起動します。cmruncl コマンドを使用できるのは、クラスタが実行されていない場合、つまりどのノードも cmcld デーモンを実行していない場合に限ります。

起動時に、クラスタマネージャソフトウェアは、起動コマンドで指定されているすべてのノードがクラスタの有効なメンバーかどうか、正常に起動して動作しているか、クラスタを形成しようとしているか、ノード間で互いにデータをやりとりできるか、などをチェックします。以上の項目を確認した後、クラスタマネージャはクラスタを形成します。

クラスタの自動起動

ノードがリブートしてクラスタへの結合が行われる場合は、いつでもクラスタが自動起動されます。このような状況は通常、各ノードのリブート後、または長期間の電源異常によりすべての SPU が停止したなど、クラスタ内のすべてのノードで障害が発生した場合に発生します。

クラスタの自動起動は、/etc/rc.config.d/cmcluster ファイルのフラグ AUTOSTART_CMCLD が 1 に設定されている場合に実行されます。いずれかのノードでこのパラメータを 1 に設定してリブートした場合、既存のクラスタに再結合するか、または既存のクラスタがない場合は、新しいクラスタを形成します。

動的クラスタ再編成

動的再編成は、実行中のクラスタにノードが結合したり、またはクラスタからノードが分離する際に発生する、クラスタのメンバー構成に関する一時的な変更です。したがって、再編成は、変更がその後も継続して保たれる再構成とは別個のものです。クラスタの再編成は以下の状況で行われます (すべての状況が記述されているわけではありません)。

通常のクラスタの再編成では、クラスタ構成が変更されます。新しいクラスタ構成では、以前の構成と比べてノード数が増減します。

スプリットブレインの問題を回避するクラスタ定足数

一般に、クラスタ再編成のアルゴリズムでは、クラスタ定足数 (cluster quorum) としてそれまで稼働していたノードの過半数を必要とします。それまで稼働していたクラスタのちょうど半数のメンバーでクラスタが 2 つ再編成された場合、同じクラスタの 2 つのインスタンスが稼働するというスプリットブレイン状態になります。スプリットブレイン状態では、アプリケーションの複数インスタンスが同じディスクに同時にアクセスすることになります。1 つのインスタンスが回復処理を起動し、もう一方のインスタンスがディスクの状態を変更するような状況が発生します。Serviceguard の定足数の要件は、スプリットブレイン状態を回避するように設計されています。

クラスタロック

通常、クラスタを再編成するためには 50% より多くのクラスタ定足数を必要としますが、それまで稼働していたノードのちょうど半数で再編成する場合、残りの半数のノードで再編成が実行されないことが保証されれば、ちょうど半数のノードで新しいクラスタとして再編成することができます。この保証は、タイブレーカを使って、2 つの同じサイズのノードグループのどちらかを選択することで可能になります。これにより 1 つのグループでクラスタを形成し、もう一方のグループはシャットダウンします。このタイブレーカは、クラスタロックとも呼ばれます。クラスタロックは、ロックディスク、ロック LUN、またはクォーラムサーバーにより実現されます。

クラスタロックがタイブレーカとして使用されるのは、実行中のクラスタに障害が発生し、Serviceguard が新しいクラスタを形成する際に、クラスタが同じサイズの 2 つのサブクラスタに分割される場合に限られます。各サブクラスタはどちらもクラスタロックを取得しようとします。クラスタロックを取得したサブクラスタが新しいクラスタを形成するので、2 つのサブクラスタが同時に稼働するのを防止できます。2 つのサブクラスタのサイズが異なる場合は、ノードの過半数を持つサブクラスタが新しいクラスタを形成し、クラスタロックは使用されません。

2 つのノードで構成されるクラスタの場合は、クラスタロックを構成する必要があります。この 2 つのノードの間の通信が切断された場合、クラスタロックを取得したノードがクラスタの機能を引き継ぎ、もう一方のノードは停止します (システムリセット)。クラスタロックがない場合には、クラスタ内のどちらかのノードで障害が発生すると、もう一方のノードも停止し、これによりクラスタ全体が停止します。

クラスタロックとしてのロック LUN または LVM ロックディスクの使用

ロックディスクまたはロック LUN は、ノードが 4 個までのクラスタで使うことができます。

クラスタロックディスクは、クラスタ内のすべてのノードが共有できるボリュームグループにある LVM ディスク上の特別な領域です。同様に、クラスタロック LUN は、クラスタ内のすべてのノードに接続され、ロック情報を持つ、小さな専用 LUN です。

LVM 構成では、ロックディスクとして使われるディスクは、クラスタロック専用ではありません。ユーザーデータが収められた通常のボリュームグループの一部をロックディスクとして使うこともできます。一方、ロック LUN はクラスタロック専用です。他のデータをそのディスク上に格納することはできません。

クラスタロックボリュームグループと物理ボリューム、またはクラスタロック LUN は、クラスタ構成ファイル内で指定します。

ノードがクラスタロックを取得すると、この領域にマークが付けられ、他のノードはそのロックが「取得されている」ことを認識できます。

ロックディスクやロック LUN の動作を、図 3-2 「ロックディスクまたはロック LUN の動作」に示します。

図 3-2 ロックディスクまたはロック LUN の動作

Serviceguard はロックディスクまたは LUN の状態を定期的にチェックし、デバイスに異常が見つかった場合には syslog ファイルにメッセージを書き込みます。ロックディスクの異常を早期に検出するためには、このファイルを監視する必要があります。

ロックディスクを使用する場合は、構築する高可用性システムの構成の種類に従って、2 種類のロックディスク (単一ロックディスクまたは二重ロックディスク) のどちらかを選択できます。可能な限り、単一ロックディスクを選択することをお勧めします。 ただしどちらの場合も、一方のノードへの電源系統に障害が発生しても、クラスタロックが使用不能にならないようにする必要があります。つまり、どちらのクラスタロック構成を選択するかは、使用できる電源系統の数によっても決まります。高可用性を維持するには、どちらのロック構成を選択するかに関係なく、クラスタ内のすべてのノードがクラスタロックへアクセスできなければなりません。

	重要: 二重ロックをロック LUN で使用することはできません。つまり、ロック LUN メカニズムを Extended Distance クラスタで使うことはできません。

二重ロックディスク

クラスタノードと同じキャビネット内に設置されているディスクを使用する場合、単一ロックディスクが単一点障害になります。これは、キャビネット内にロックディスクを持つノードへ電力が供給されなくなった場合、クラスタロックも使用できなくなるためです。同様に、キャンパスクラスタ (つまり、別々の 2 つのデータセンターで動作している複数のノードが 1 つのクラスタ内に含まれる) では、データセンターに災害による障害が発生した場合に、単一ロックディスクが単一点障害になります。

これらの 2 つの場合にのみ、二重クラスタロック (独立した電源を持つ 2 台のクラスタディスク) を使用して、ロックディスクが単一点障害になるのを回避します。

	注記: 二重クラスタロックでは、Fibre Channel 接続を使わなければなりません。二重クラスタロックを、パラレル SCSI 構成で実現することはできなくなりました。

二重クラスタロックでは、2 台のディスクで電源系統やノードのシャーシを共有させないでください。このようにすると、一方のノードとディスクに影響を与える電源障害が発生しても、もう一方のノードとディスクは使用可能な状態のため、このノード上でクラスタの再編成を行うことができます。キャンパスクラスタの場合、データセンターのそれぞれにロックディスクが 1 台必要になります。また、すべてのノードは両方のロックディスクにアクセスできなければなりません。一方のデータセンターで障害が発生した場合、もう一方のデータセンターにあるノードがローカルのロックディスクを取得することができるので、新しいクラスタを正常に再編成することができます。

	注記: 二重ロックディスクではクラスタロックの冗長性は確保できません。 実際、二重ロックは複式のロックになっています。これは、単一ロックディスクの場合と異なり、クラスタ形成時には 2 台のディスクが使用可能でなければならないことを意味します。このため二重クラスタロックは、障害時に、単一クラスタロックをちょうど半数のクラスタノードから切り離すことができない場合にのみ使用することをお勧めします。 二重ロックディスクの一方で障害が発生した場合、Serviceguard が定期的なチェックを実行するときにこれを検出し、メッセージを syslog ファイルに書き込みます。一方のロックディスクが障害になった後では、クラスタノードに障害が発生して、動作している残りのノードが正常に動作しているクラスタロックディスクにアクセスできなくなると、クラスタが停止する可能性があります。

クラスタロックとしてのクォーラムサーバーの使用

クォーラムサーバーは、任意の規模のクラスタで使用できます。クォーラムサーバープロセスは、クォーラムサービスを利用するクラスタに属していないマシン上で実行されます。クォーラムサーバーは、既知のポート上で、Serviceguard ノードからの接続要求を受信します。このサーバーは、クラスタごとに特別なメモリー領域を用意します。1 つのノードがクラスタロックを取得すると、「ロックが取得されている」ことを他のノードが認識できるように、この領域がマークされます。2 つの同サイズのノードグループ間で通信ができなくなった場合、クォーラムサーバーからロックを取得したグループがクラスタを引き継ぎ、他のノードはシステムリセットを実行します。クラスタロックがないと、どちらのグループのノードに障害が発生しても、他のグループ (つまりクラスタ) が停止します。また、クォーラムサーバーにアクセスしようとしたときにクォーラムサーバーが利用できないと、クラスタは停止します。

クォーラムサーバーの動作を、図 3-3 「クォーラムサーバーの動作」に示します。ノード 1 とノード 2 の間の通信ができなくなった場合、クォーラムサーバーはノードを 1 つ (この例ではノード 2) 選択してクラスタの動作を続けます。他のノードは停止します。

図 3-3 クォーラムサーバーの動作

クォーラムサーバーは、独立したシステム上で実行されます。また、複数のクラスタにクォーラムサービスを提供できます。

クラスタロックなし

通常は、ノード数が 3 つ以下のクラスタをクラスタロックなしで構成しないでください。ノード数が 2 つのクラスタでは、クラスタロックは必須です。ノード数が 3 つ以上のクラスタを構成する場合はクラスタロックを使用しなくても構いませんが、どのような構成のクラスタであってもタイブレーカが必要な状況になる可能性があることを考慮に入れた上で決定してください。たとえば、3 つのノードを持つクラスタで、保守のためにノードの 1 つを削除した場合、クラスタは、2 つのノードを持つクラスタとして再編成されます。この後ノード障害または通信障害によりタイブレーカを必要とする状況が発生すると、クラスタ全体が使用できなくなります。

ノード数が 5 つ以上のクラスタでは、クラスタが同じサイズで二分割される可能性は小さいので、クラスタロックは必要ありません。ただし、ちょうど半数のノードで障害が同時に発生しないようにクラスタを構成してください。たとえば、同数のノード間で単一 LAN などの単一点障害が発生する可能性がないこと、また 1 つの電源系統にちょうど半数のノードを接続していないことを確かめてください。