7.2. 基本的なクラスター設定ファイルの作成

クラスターハードウェア、Red Hat Enterprise Linux、および High Availability アドオンソフトウェアがインストールされていれば、クラスター設定ファイル (/etc/cluster/cluster.conf) を作成して High Availability アドオンの実行を開始することができます。このセクションでは、単に開始点として、フェンシング、フェイルオーバードメイン、および HA サービスのないスケルトンクラスター設定ファイルを作成する方法を説明します。これ以降のセクションでは、設定ファイルでのこれらの部分を設定する方法を説明しています。

重要

この手順は、クラスター設定ファイルを作成するための暫定的なステップにすぎません。得られるファイルにはフェンシングがなく、サポート対象の設定とは見なされません。
次の手順は、スケルトンクラスター設定ファイルを作成して設定する方法を説明しています。最終的には、使用しているクラスターの設定ファイルは、ノード数、フェンシングのタイプ、及び HA サービスのタイプと数、サイト特有の他の要件によって変化します。
  1. クラスター内のいずれかのノードで、例7.1「cluster.conf の例: 基本設定」 内のサンプルのテンプレートを使用して /etc/cluster/cluster.conf を作成します。
  2. (オプション) 2 ノードクラスターを設定している場合は、設定ファイルに以下の行を追加して単一ノードでも定足数を維持できるようにします (例えば、1 つのノードが失敗した場合など):
    <cman two_node="1" expected_votes="1"/>
    cluster.conf ファイルから two_node オプションを追加/削除した時に、設定を更新した場合は、変更を反映させるためにクラスターを再起動する必要があります。クラスターの設定を更新する詳細については、「設定の更新」 を参照してください。two_node オプションを指定する例は、例7.2「cluster.conf の例: 基本的な 2 ノード設定」 を参照してください。
  3. cluster 属性を使用してクラスター名と設定のバージョン番号である nameconfig_version を指定します。(例7.1「cluster.conf の例: 基本設定」 又は 例7.2「cluster.conf の例: 基本的な 2 ノード設定」 を参照)。
  4. clusternodes セクションで、clusternode 属性を使用して各ノードのノード名とノード ID である namenodeid を指定します。ノード名の長さは、最大 255 バイトまでになります。
  5. /etc/cluster/cluster.conf を保存します。
  6. ccs_config_validate コマンドを実行することで、クラスタースキーマ (cluster.rng) に対するファイルの妥当性を検証します。例えば、
    [root@example-01 ~]# ccs_config_validate 
    Configuration validates
    
  7. 設定ファイルを各クラスターノード内の /etc/cluster/ に伝播します。例えば、scp コマンドを使用するとファイルを他のクラスターノードへ伝播できます。

    注記

    クラスターの初回作成時には、この方法でクラスター設定ファイルを伝達する必要があります。クラスターがインストールされて稼働すると、クラスター設定ファイルは cman_tool version -r コマンドを使用して伝達できるようになります。更新した設定ファイルの伝達には scp コマンドを使用することもできますが、scp コマンドの使用中は、全てのノードでクラスターソフトウェアが停止する必要があります。さらに、scp で更新済みの設定ファイルを伝達する場合は、 ccs_config_validate を実行することをお勧めします。

    注記

    サンプルの設定ファイル内に他の要素と属性がありますが (例えば、fencefencedevices)、それらは今すぐ設定する必要はありません。本章の後半の手順では、他の要素と属性の指定に関する情報が提供されています。
  8. クラスターを開始します。各クラスターノードで以下のコマンドを実行します:
    service cman start
    例えば:
    [root@example-01 ~]# service cman start
    Starting cluster: 
       Checking Network Manager...                             [  OK  ]
       Global setup...                                         [  OK  ]
       Loading kernel modules...                               [  OK  ]
       Mounting configfs...                                    [  OK  ]
       Starting cman...                                        [  OK  ]
       Waiting for quorum...                                   [  OK  ]
       Starting fenced...                                      [  OK  ]
       Starting dlm_controld...                                [  OK  ]
       Starting gfs_controld...                                [  OK  ]
       Unfencing self...                                       [  OK  ]
       Joining fence domain...                                 [  OK  ]
    
  9. いずれかのクラスターノードで cman_tool nodes を実行して、ノード群がクラスター内でメンバーとして機能していることを確認します (ステータスカラム "Sts" で "M" として表示)。例えば:
    [root@example-01 ~]# cman_tool nodes
    Node  Sts   Inc   Joined               Name
       1   M    548   2010-09-28 10:52:21  node-01.example.com
       2   M    548   2010-09-28 10:52:21  node-02.example.com
       3   M    544   2010-09-28 10:52:21  node-03.example.com
    
  10. クラスターが稼働していれば、「フェンシングの設定」 に進みます。

基本設定の例

例7.1「cluster.conf の例: 基本設定」例7.2「cluster.conf の例: 基本的な 2 ノード設定」 (2 ノードクラスター用) はそれぞれ、開始点として非常に基本的なクラスター設定ファイルのサンプルを提供します。本章の後半にある手順には、フェンシングと HA サービスに関する情報が記載されています。

例7.1 cluster.conf の例: 基本設定


<cluster name="mycluster" config_version="2">
   <clusternodes>
     <clusternode name="node-01.example.com" nodeid="1">
         <fence>
         </fence>
     </clusternode>
     <clusternode name="node-02.example.com" nodeid="2">
         <fence>
         </fence>
     </clusternode>
     <clusternode name="node-03.example.com" nodeid="3">
         <fence>
         </fence>
     </clusternode>
   </clusternodes>
   <fencedevices>
   </fencedevices>
   <rm>
   </rm>
</cluster>

例7.2 cluster.conf の例: 基本的な 2 ノード設定


<cluster name="mycluster" config_version="2">
   <cman two_node="1" expected_votes="1"/>
   <clusternodes>
     <clusternode name="node-01.example.com" nodeid="1">
         <fence>
         </fence>
     </clusternode>
     <clusternode name="node-02.example.com" nodeid="2">
         <fence>
         </fence>
     </clusternode>
   </clusternodes>
   <fencedevices>
   </fencedevices>
   <rm>
   </rm>
</cluster>

2 ノードクラスター内の totemconsensus

2 ノードクラスターを作成して、後でそのクラスターにノードを追加する意図がない場合は、cluster.conf ファイル内にある totem タグの consensus 値を省略して、consensus 値が自動的に算出されるようにします。consensus 値が自動的に算出されると、以下のルールが適用されます:
  • 2 つ、又はそれ以下のノードしかない場合、consensus 値は 上限 2000 msec で 下限 200 msec を持つ (token * 0.2) となります。
  • 3 つ、又はそれ以上のノードがある場合、consensus 値は (token + 2000 msec) となります。
このようにして cman ユーティリティに consensus タイムアウトを設定させると、後で 2 ノードから 3 ノード (又はそれ以上) に移動するにはクラスターの再起動が必要になります。これは token タイムアウトを基にしてconsensus タイムアウトをより大きな値に変更する必要があるためです。
2 ノードクラスターを設定中であり、今後それ以上のノードにアップグレードする予定がある場合は、consensus タイムアウトを上書きできるため 2 つから 3 つ (又はそれ以上) のノードに移動する時にクラスターの再起動が不要になります。これは、cluster.conf 内で以下のように実行できます:

<totem token="X" consensus="X + 2000" />

設定パーサーは X + 2000 を自動的に算出しないことに注意して下さい。数式ではなく整数値を使用する必要があります。
2 ノードクラスターに対して最適化した consensus タイムアウトを使用する利点は、全体のフェイルオーバータイムが 2 ノードのケースでは短縮できる点です。これは consensus が token タイムアウトの関数ではないからです。
cman 内の 2 ノード検出機能の場合、重要な点は物理ノードの数であり、 cluster.conf ファイル内の two_node=1 指示文の存在ではないことに注意して下さい。