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 ソフトウェアの必要条件 #
クラスタに参加するすべてのノードに次のソフトウェアがインストールされている必要があります。
SUSE® Linux Enterprise Server 12 SP5 (利用可能なすべてのオンラインアップデートが適用されていること)
SUSE Linux Enterprise High Availability Extension 12 SP5 (利用可能なすべてのオンラインアップデートが適用されていること)
(オプション)Geoクラスタの場合: Geo Clustering for SUSE Linux Enterprise High Availability Extension 12 SP5 (利用可能なすべてのオンラインアップデートが適用されていること)
2.3 ストレージ要件 #
一部のサービスでは、共有ストレージが必要です。外部NFS共有を使用する場合は、冗長通信パスを介してすべてのクラスタノードから確実にアクセスできる必要があります。
クラスタでデータの可用性を高めたい場合は、共有ディスクシステム(SAN: Storage Area Network)の利用をお勧めします。共有ディスクシステムを使用する場合は、次の要件を満たしていることを確認してください。
メーカーの指示のに従い、共有ディスクシステムが適切に設定され、正しく動作していることを確認します。
共有ディスクシステム中のディスクを、ミラーリングまたはRAIDを使用して耐障害性が高められるように設定してください。
共有ディスクシステムのアクセスにiSCSIを使用している場合、iSCSIイニシエータとターゲットを正しく設定していることを確認します。
2台のマシンにデータを配分するミラーリングRAIDシステムを実装するためにDRBD*を使用する際、DRBDに提供されるデバイスにのみアクセスし、決してバッキングデバイスにはアクセスしないようにします。ボンディングNICを使用します。冗長性を確保するために、クラスタの残りの部分と同一のNICを利用できます。
SBDをSTONITHメカニズムとして使用する場合は、共有ストレージに対して追加の要件が適用されます。詳細については、11.3項 「要件」を参照してください。
2.4 その他の要件と推奨事項 #
サポートされていて、役に立つHigh Availabilityセットアップについては、次の推奨事項を検討してください。
- クラスタノード数
3つ以上のノードを持つクラスタに対して、奇数のクラスタノードを使用してクォーラムを持つようにすることを強くお勧めします。クォーラムの詳細については、6.2項 「クォーラムの判断」を参照してください。
- 時刻同期
クラスタノードはクラスタ外のNTPサーバに同期する必要があります。詳細については、https://documentation.suse.com/sles-12/html/SLES-all/cha-netz-xntp.htmlを参照してください。
ノードが同期されていない場合、クラスタが正常に動作しないことがあります。また、同期が行われていないと、ログファイルとクラスタレポートの分析が非常に困難になります。ブートストラップスクリプトを使用するときに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を実行できます。については、現在のところ、パスワード不要のログインに代わる方法はありません。