2 システム要件と推奨事項 #
次のセクションでは、SUSE® Linux Enterprise High Availability Extensionのシステム要件と前提条件について説明します。また、クラスタセットアップの推奨事項についても説明します。
2.1 ハードウェア要件 #
次のリストは、SUSE® Linux Enterprise High Availability Extensionに基づくクラスタのハードウェア要件を指定しています。これらの要件は、最低のハードウェア設定を表しています。クラスタの使用方法によっては、ハードウェアを追加しなければならないこともあります。
- サーバ
2.2項 「ソフトウェアの必要条件」に指定されたソフトウェアを搭載した1～32台のLinuxサーバ。
サーバはベアメタルでも仮想マシンでも構いません。各サーバが同一のハードウェア設定(メモリ、ディスクスペースなど)になっている必要はありませんが、アーキテクチャは同じである必要があります。クロスプラットフォームのクラスタはサポートされていません。
pacemaker_remoteを使用すると、32ノード制限を超えて追加のLinuxサーバを含めるようにクラスタを拡張できます。- 通信チャネル
クラスタノードあたり、少なくとも2つのTCP/IP通信メディア。ネットワーク機器は、クラスタ通信に使用する通信手段(マルチキャストまたはユニキャスト)をサポートする必要があります。通信メディアは100Mbit/s以上のデータレートをサポートする必要があります。サポートされるクラスタセットアップでは、2つ以上の冗長通信パスが必要です。これは次のように実行できます。
ネットワークデバイスボンディング(推奨)。
Corosync内の2つ目の通信チャネル。
詳細については、第13章 「ネットワークデバイスボンディング」と手順4.3「冗長通信チャネルの定義」をそれぞれ参照してください。
- ノードフェンシング/STONITH
「スプリットブレイン」シナリオを回避するため、クラスタにはノードフェンシングメカニズムが必要です。スプリットブレインシナリオでは、クラスタノードは、お互いを認識していない2つ以上のグループに分割されます(ハードウェアまたはソフトウェアの障害か、ネットワーク接続の切断による)。フェンシングメカニズムにより、問題のあるノードを分離します(通常はノードをリセットするか、ノードの電源をオフにすることによって分離します)。これをSTONITH (「Shoot the other node in the head」)と呼びます。ノードフェンシングメカニズムは、物理デバイス(電源スイッチ)でも、SBD (ディスクによるSTONITH)のようなメカニズムとウォッチドッグを組み合わせたものでも構いません。SBDを使用するには共有ストレージが必要です。
SBDが使用される場合を除き、High Availabilityクラスタの各ノードには少なくとも1つのSTONITHデバイスが必要です。ノードごとに複数のSTONITHデバイスを使用することを強くお勧めします。
重要: STONITHがない場合はサポートなしクラスタにはノードフェンシングメカニズムが必要です。
グローバルクラスタオプション
stonith-enabledおよびstartup-fencingをtrueに設定する必要があります。これらを変更するとサポートされなくなります。
2.2 ソフトウェアの必要条件 #
クラスタの一部になるすべてのノードには、少なくとも次のモジュールと拡張機能が含まれている必要があります。
Base System Module 15 SP2
Server Applications Module 15 SP2
SUSE Linux Enterprise High Availability Extension 15 SP2
インストール中に選択したシステムの役割に応じて、デフォルトで次のソフトウェアパターンがインストールされます。
|
システムの役割 |
ソフトウェアパターン(YaST/Zypper) |
|---|---|
|
HAノード |
|
|
HA GEOノード |
|
これらのシステムの役割を介してインストールすると、最小限のインストールにのみ抑えられます。必要に応じて、パッケージを手動で追加しなければならない場合があります。
最初別のシステムの役割が割り当てられていたマシンの場合、sles_haまたはha_geoパターンとその他の必要なパッケージを手動でインストールする必要があります。
2.3 ストレージ要件 #
一部のサービスでは、共有ストレージが必要です。外部NFS共有を使用する場合は、冗長通信パスを介してすべてのクラスタノードから確実にアクセスできる必要があります。
クラスタでデータの可用性を高めたい場合は、共有ディスクシステム(SAN: Storage Area Network)の利用をお勧めします。共有ディスクシステムを使用する場合は、次の要件を満たしていることを確認してください。
メーカーの指示のに従い、共有ディスクシステムが適切に設定され、正しく動作していることを確認します。
共有ディスクシステム中のディスクを、ミラーリングまたはRAIDを使用して耐障害性が高められるように設定してください。
共有ディスクシステムのアクセスにiSCSIを使用している場合、iSCSIイニシエータとターゲットを正しく設定していることを確認します。
2台のマシンにデータを配分するミラーリングRAIDシステムを実装するためにDRBD*を使用する際、DRBDに提供されるデバイスにのみアクセスし、決してバッキングデバイスにはアクセスしないようにします。冗長性を確保するために、クラスタの残りの部分と同一のNICを利用できます。
SBDをSTONITHメカニズムとして使用する場合は、共有ストレージに対して追加の要件が適用されます。詳細については、11.3項 「要件」を参照してください。
2.4 その他の要件と推奨事項 #
サポートされていて、役に立つHigh Availabilityセットアップについては、次の推奨事項を検討してください。
- クラスタノード数
3つ以上のノードを持つクラスタに対して、奇数のクラスタノードを使用してクォーラムを持つようにすることを強くお勧めします。クォーラムの詳細については、6.2項 「クォーラムの判断」を参照してください。
- 時刻同期
クラスタノードはクラスタ外のNTPサーバに同期する必要があります。SUSE Linux Enterprise High Availability Extension 15以降、Chronyは、NTPでデフォルトで実装されるようになりました。詳細については、『SUSE Linux Enterprise Server 15 SP2の 管理ガイド』を参照してください。
ノードが同期されていない場合、クラスタが正常に動作しないことがあります。また、同期が行われていないと、ログファイルとクラスタレポートの分析が非常に困難になります。ブートストラップスクリプトを使用するときにNTPがまだ設定されていない場合、警告が表示されます。
- ネットワークインタフェースカード(NIC)名
すべてのノード上で同一である必要があります。
- ホスト名およびIPアドレス
静的IPアドレスを使用します。
/etc/hostsファイルにあるすべてのクラスタノードを、完全修飾ホスト名およびショートホスト名で一覧表示します。クラスタのメンバーが名前で互いを見つけられることが重要です。名前を使用できない場合、内部クラスタ通信は失敗します。Pacemakerがノード名を取得する方法の詳細については、http://clusterlabs.org/doc/en-US/Pacemaker/1.1/html/Pacemaker_Explained/s-node-name.htmlも参照してください。
- SSH
すべてのクラスタノードはSSHによって互いにアクセスできる必要があります。
crm report(トラブルシューティング用)などのツールおよびHawk2のは、ノード間でパスワード不要のSSHアクセスを必要とします。それがない場合、現在のノードからしかデータを収集できません。注記: 規定要件パスワード不要のSSHアクセスが規定要件に適合しない場合は、付録D
rootアクセスなしでのクラスタレポートの実行で説明されている次善策を使用してcrm reportを実行できます。については、現在のところ、パスワード不要のログインに代わる方法はありません。