目次にジャンプページナビゲーションにジャンプ: 前のページ[アクセスキーp]/次のページ[アクセスキーn]
documentation.suse.com / SUSE Linux Enterprise High Availabilityのドキュメント / 管理ガイド / インストールおよびセットアップ / システム要件と推奨事項
適用項目 SUSE Linux Enterprise High Availability 15 SP6

2 システム要件と推奨事項

 

次のセクションでは、SUSE® Linux Enterprise High Availabilityのシステム要件と前提条件について説明します。また、クラスタセットアップの推奨事項についても説明します。

2.1 ハードウェア要件

 

次のリストは、SUSE® Linux Enterprise High Availabilityに基づくクラスタのハードウェア要件を指定しています。これらの要件は、最低のハードウェア設定を表しています。クラスタの使用方法によっては、ハードウェアを追加しなければならないこともあります。

サーバ

2.2項 「ソフトウェアの必要条件」に指定されたソフトウェアを搭載した1～32台のLinuxサーバ。

サーバはベアメタルでも仮想マシンでも構いません。各サーバが同一のハードウェア設定(メモリ、ディスクスペースなど)になっている必要はありませんが、アーキテクチャは同じである必要があります。クロスプラットフォームのクラスタはサポートされていません。

pacemaker_remoteを使用すると、32ノード制限を超えて追加のLinuxサーバを含めるようにクラスタを拡張できます。

通信チャネル

クラスタノードあたり、少なくとも2つのTCP/IP通信メディア。ネットワーク機器は、クラスタ通信に使用する通信手段(マルチキャストまたはユニキャスト)をサポートする必要があります。通信メディアは100Mbit/s以上のデータレートをサポートする必要があります。サポートされるクラスタセットアップでは、2つ以上の冗長通信パスが必要です。これは次のように実行できます。

  • ネットワークデバイスボンディング(推奨)

  • Corosync内の2つ目の通信チャネル。

詳細については、第16章 「ネットワークデバイスボンディング」と手順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 ソフトウェアの必要条件

 

すべてのノードは、少なくとも次のモジュールおよび拡張機能が必要です。

  • Basesystem Module 15 SP6

  • Server Applications Module 15 SP6

  • SUSE Linux Enterprise High Availability 15 SP6

インストール中に選択したシステムの役割に応じて、デフォルトで次のソフトウェアパターンがインストールされます。

HAノードシステムの役割

高可用性 (sles_ha)

強化された基本システム (enhanced_base)

HA GEOノードシステムの役割

Geo Clustering for High Availability (ha_geo)

強化された基本システム (enhanced_base)

注記
注記: 最小インストール

これらのシステムの役割を介してインストールすると、最小限のインストールにのみ抑えられます。必要に応じて、パッケージを手動で追加しなければならない場合があります。

最初に別のシステムの役割が割り当てられていたマシンの場合、sles_haパターンまたはha_geoパターンとその他の必要なパッケージを手動でインストールする必要があります。

2.3 ストレージ要件

 

一部のサービスでは、共有ストレージが必要です。外部NFS共有を使用する場合は、冗長通信パスを介してすべてのクラスタノードから確実にアクセスできる必要があります。

クラスタでデータの可用性を高めたい場合は、共有ディスクシステム(SAN: Storage Area Network)の利用をお勧めします。共有ディスクシステムを使用する場合は、次の要件を満たしていることを確認してください。

  • メーカーの指示のに従い、共有ディスクシステムが適切に設定され、正しく動作していることを確認します。

  • 共有ディスクシステム中のディスクを、ミラーリングまたはRAIDを使用して耐障害性が高められるように設定してください。

  • 共有ディスクシステムのアクセスにiSCSIを使用している場合、iSCSIイニシエータとターゲットを正しく設定していることを確認します。

  • 2台のマシンにデータを配分するミラーリングRAIDシステムを実装するためにDRBD*を使用する際、DRBDに提供されるデバイスにのみアクセスし、決してバッキングデバイスにはアクセスしないようにします。冗長性を確保するために、クラスタの残りの部分と同一のNICを利用できます。

SBDをSTONITHメカニズムとして使用する場合は、共有ストレージに対して追加の要件が適用されます。詳細については、13.3項 「要件と制約」を参照してください。

2.4 その他の要件と推奨事項

 

サポートされていて、役に立つHigh Availabilityセットアップについては、次の推奨事項を検討してください。

クラスタノード数

3つ以上のノードを持つクラスタに対して、奇数のクラスタノードを使用してクォーラムを持つようにすることを強くお勧めします。クォーラムの詳細については、5.2項 「クォーラムの判断」を参照してください。通常のクラスタには最大32ノードを含めることができます。pacemaker_remoteサービスを使用すると、高可用性クラスタを拡張して、この制限を超えて追加のノードを含めることができます。詳細については、『Pacemaker Remote Quick Start』を参照してください。

時刻同期

クラスタノードはクラスタ外のNTPサーバに同期する必要があります。SUSE Linux Enterprise High Availability 15以降、Chronyは、NTPでデフォルトで実装されるようになりました。詳細については、 Administration Guide for SUSE Linux Enterprise Server 15 SP6を参照してください。

ノードが同期されていない場合、または同期されていても異なるタイムゾーンが設定されている場合、クラスタが正しく動作しない場合があります。また、同期が行われていないと、ログファイルとクラスタレポートの分析が非常に困難になります。ブートストラップスクリプトを使用するときにNTPがまだ設定されていない場合、警告が表示されます。

ネットワークインタフェースカード(NIC)名

すべてのノード上で同一である必要があります。

ホスト名およびIPアドレス

  • 静的IPアドレスを使用します。

  • プライマリIPアドレスのみがサポートされます。

  • ファイル/etc/hostsにあるすべてのクラスタノードを、完全修飾ホスト名およびショートホスト名で一覧表示します。クラスタのメンバーが名前で互いを見つけられることが重要です。名前を使用できない場合、内部クラスタ通信は失敗します。

    Pacemakerがノード名を取得する方法の詳細については、https://clusterlabs.org/doc/en-US/Pacemaker/1.1/html/Pacemaker_Explained/s-node-name.htmlも参照してください。

SSH

すべてのクラスタノードはSSHによって互いにアクセスできる必要があります。crm report (トラブルシューティング用)などのツールおよびHawk2の履歴エクスプローラーは、ノード間でパスワード不要のSSHアクセスを必要とします。それがない場合、現在のノードからしかデータを収集できません。

ブートストラップスクリプトを使用してクラスタを設定した場合、SSHキーは自動的に作成され、コピーされます。YaSTクラスタモジュールを使用してクラスタを設定した場合、SSHキーを自分自身で設定する必要があります。

注記
注記: 規定要件

デフォルトでは、クラスタはrootユーザとして操作を実行します。パスワード不要のroot SSHアクセスが規定要件に準拠していない場合、代わりにsudo特権を持つユーザとしてクラスタを設定できます。このユーザは、crm reportなどのクラスタ操作を実行できます。

また、SSHキーをノードに直接保存できない場合、5.5.1項 「ログイン」で説明されているように、代わりにSSHエージェントを転送してローカルSSHキーを使用できます。

さらに厳密なセキュリティポリシーが必要な場合、D.1項 「非rootユーザに限定的なsudo特権を設定する」で説明されているように、crm reportに特化した限定的なsudo特権のみを持つ非rootユーザを設定できます。

履歴エクスプローラーについては、現在のところ、パスワード不要のログインに代わる方法はありません。