次のセクションでは、クラスタシステムで使用されるハードウェアの設定についての 補足情報を説明しています。
このセクションでは電源コントローラについて説明しています。 電源コントローラについての詳細、及びクラスタ環境での電源コントローラの役割については、 項1.1.3を参照してください。
クラスタ電源コントローラ用にRed Hat, Inc.で検査された、 またはRed Hat, Inc.がサポートしているシリアル接続の電源スイッチと ネットワーク接続の電源スイッチの一覧は、 次のURLにあるRed Hat ハードウェアの互換性一覧を参照してください。
クラスタのデータ整合性を保証する手段としてWatchdogタイマーを使用する方法については、項1.1.3を参照してください。ここで説明しているように、Watchdogタイマーには、ハードウェアベースとソフトウェアベースの2つのタイプがあります。
ここでは、クラスタハードウェア構成でWatchdogタイマーを設定するのに必要な設定タスクについて説明します。
どちらのタイプを使用するかにかかわらず、そのWatchdogタイマーに適切なデバイス特殊ファイルを作成する必要があります。このファイルを作成するには、以下のコマンドを入力してください。
cd /dev ./MAKEDEV watchdog |
クラスタ設定ツールを使用する際に、 クラスタに追加した新しい各メンバはデフォルトでソフトウェア watchdog 機能が有効になっています。
専用のハードウェアコンポーネントが不要であるため、あらゆるクラスタシステムがソフトウェアWatchdogタイマーをデータ整合性保証手段として使用できます。クラスタソフトウェアは、対応するロード可能なカーネルモジュールsoftdog を自動的にロードします。
ソフトウェアWatchdogタイマーを使用するようにクラスタが設定されている場合、クラスタメンバーシップデーモン(clumembd)がタイマーを定期的にリセットします。clumembdがタイマーをリセットできなかった場合、障害が発生したクラスタメンバーは自分自身を再起動します。
ソフトウェアWatchdogタイマーを使用している場合、ソフトウェアWatchdogスレッドが実行されず、システムがハングする可能性が一部あります。この稀なケースでは、 他のクラスタメンバが、ハングしていると思われるクラスタメンバーのサービスを 引き継ぎます。一般的にこれは安全な機能ですが、ハングしたクラスタメンバーが 再開した場合にはデータが破損する恐れがあります。ソフトウェアWatchdogタイマーを 使用しているときに、この問題の発生率を減らすには、管理者は外部スイッチ(ある場合) の他に NMI Watchdog タイマーも設定する必要があります。
ソフトウェアWatchdogタイマーをデータ整合性保証手段として使用している場合は、NMI(Non-Maskable Interrupt)Watchdogタイマーも有効にして、データ整合性保証機能を強化することをお勧めします。NMI Watchdog タイマーは、割り込みがブロックされているときにシステムがハングした場合にシステムを再起動するためのメカニズムです。このNMI Watchdogは、ソフトウェアWatchdogタイマーとともに使用できます。
クラスタquorum処理デーモン(cluquorumd)でリセットされるソフトウェアWatchdogタイマーとは異なり、NMI Watchdogタイマーはシステム割り込みをカウントします。通常、正常なシステムは1秒間に数百ものデバイスおよびタイマー割り込みを受信します。5秒以内に割り込みを受信しなかった場合、システムはハングしていて、NMI Watchdogタイマーがタイムアウトになり、システムが再起動されます。
ソフトウェアWatchdogタイマーによるクラスタquorum処理デーモンの状態のモニターと、NMI Watchdogによる下位レベルのシステムステータスチェックを組み合わせることで、強力なデータ整合性ソリューションを実装できます。
NMI watchdog タイマーのメカニズムを正しく作動させるには、 クラスタメンバが APIC チップをメインシステムボードに格納している必要があります。
NMI Watchdogは、サポートしているシステムでカーネルのコマンドラインにnmi_watchdog=1を追加することで有効になります。/etc/grub.confの例を以下に示します。
![]() | 注記: |
---|---|
次の GRUB のブートローダ設定と LILO のブートローダ設定は、 Red Hat Enterprise Linux の x86 アーキテクチャのみの適用になります。 |
# grub.conf default=0 timeout=10 splashimage=(hd0,0)/grub/splash.xpm.gz title HA Test Kernel (2.4.9-10smp) root (hd0,0) # This is the kernel's command line. kernel /vmlinuz-2.4.9-10smp ro root=/dev/hda2 nmi_watchdog=1 # end of grub.conf |
LILO を使用しているシステムでは、/etc/lilo.conf のappendセクションに "nmi_watchdog=1"を追加してください。 例えば、
# lilo.conf prompt timeout=50 default=linux boot=/dev/hda map=/boot/map install=/boot/boot.b lba32 image=/boot/vmlinuz-2.4.9-10smp label=linux read-only root=/dev/hda2 append="nmi_watchdog=1" # end of lilo.conf |
変更を反映させるために/etc/lilo.conf を変更した後、/sbin/liloを実行します。
サーバがNMI Watchdogタイマーをサポートしているかどうかを確認するには、 まず、前述したようにカーネルのコマンドラインに"nmi_watchdog=1" を追加してみてください。システムが再起動したら、 rootとしてログインし、以下を入力します。
cat /proc/interrupts |
以下のような出力が表示されます。
CPU0 0: 5623100 XT-PIC timer 1: 13 XT-PIC keyboard 2: 0 XT-PIC cascade 7: 0 XT-PIC usb-ohci 8: 1 XT-PIC rtc 9: 794332 XT-PIC aic7xxx, aic7xxx 10: 569498 XT-PIC eth0 12: 24 XT-PIC PS/2 Mouse 14: 0 XT-PIC ide0 NMI: 5620998 LOC: 5623358 ERR: 0 MIS: 0 |
上記の出力で重要な部分は、左側にNMIid が表示されている のを確認することです。 NMIの値が0(0)以上の場合、 サーバはNMI Watchdogをサポートしています。
この手順が失敗した場合、つまり、NMIが0の場合は、前述した手順に従ってカーネルにnmi_watchdog=1の代わりにnmi_watchdog=2を渡してみてください。 そして、システムが起動したら、再度/proc/interrupts をチェックしてください。NMIが0以上の場合、 NMI Watchdogは正しく設定されています。 NMIが0の場合、 システムはNMI Watchdogタイマーをサポートしていません。
カーネルは、さまざまな種類のハードウェアWatchdogタイマーのドライバをサポートしています。これらのタイマーのいくつかは、システムボードに直接実装されています。それ以外のものは、PCIカードなどの個別のハードウェアコンポーネントです。 ハードウェアベースのWatchdogタイマーは、システムプロセッサとは独立して動作し、ハングしたシステムを再起動する際に完全に機能するため、非常に優れたデータ整合性保証機能をクラスタで提供します。
下位レベルのハードウェアWatchdogコンポーネントは完全に統一されていないため、それらのコンポーネントがシステムに含まれているかどうかを確認する方法をコンポーネントごとに異なります。下位レベルのハードウェアWatchdogコンポーネントの多くは、自己識別機能を持っていません。
カーネルでサポートされている対応Watchdogタイマーの設定をする際は、 対応するエントリを/etc/modules.confファイルに入れる必要があります。 たとえば、Intel-810ベースのTCO watchdog タイマーが使用される場合は、 /etc/modules.confに以下の行を入れる必要があります。
alias wdt i810-tco |