Cluster management manages cluster quorum and cluster membership. CMAN (an abbreviation for cluster manager) performs cluster management in Red Hat Cluster Suite for Red Hat Enterprise Linux 5. CMAN is a distributed cluster manager and runs in each cluster node; cluster management is distributed across all nodes in the cluster (refer to 図1.2「CMAN/DLM Overview」).

CMAN keeps track of cluster quorum by monitoring the count of cluster nodes. If more than half the nodes are active, the cluster has quorum. If half the nodes (or fewer) are active, the cluster does not have quorum, and all cluster activity is stopped. Cluster quorum prevents the occurrence of a "split-brain" condition — a condition where two instances of the same cluster are running. A split-brain condition would allow each cluster instance to access cluster resources without knowledge of the other cluster instance, resulting in corrupted cluster integrity.

定員数は、イーサネットを通じてクラスタノード間のメッセージの交信により決定されます。 オプションとして、定員数は、イーサネット経由、及び 定員数ディスクを通じたメッセージの交信の組み合わせによって決定できます。イーサネット 経由の定員数では、定員数はノード投票数の50％ プラス１です。定員数ディスク経由の定員数では、 定員数はユーザー指定の条件で構成されます。

CMAN は、他のクラスタノードからのメッセージを監視することによりメンバーシップの 動きを追跡します。クラスタメンバーシップが変化すると、クラスタマネージャは、他の インフラストラクチャコンポーネントに通知を出します。これらのコンポーネントがその後 必要な処置をします。例えば、ノード A がクラスタに参加して、ノード B とノード C が既に マウントしている GFS ファイルシステムをマウントする場合、ノード A が GFS ファイルシステムを 使用するためには、追加のジャーナルとロック管理が必要となります。１つのクラスタノードが 指定時間以内にメッセージを送信しないと、クラスタマネージャはクラスタからそのノードを 削除し、そのノードがもうメンバーでないことを他のクラスタインフラストラクチャコンポーネントに 通達します。その後、他のクラスタインフラストラクチャコンポーネントは、そのノードがクラスタの メンバーでない通知に対して起こす行動を決定します。例えば、フェンシングがメンバーでなくなった ノードを フェンス（遮断）してしまいます。

Lock management is a common cluster-infrastructure service that provides a mechanism for other cluster infrastructure components to synchronize their access to shared resources. In a Red Hat cluster, DLM (Distributed Lock Manager) is the lock manager. As implied in its name, DLM is a distributed lock manager and runs in each cluster node; lock management is distributed across all nodes in the cluster (refer to 図1.2「CMAN/DLM Overview」). GFS and CLVM use locks from the lock manager. GFS uses locks from the lock manager to synchronize access to file system metadata (on shared storage). CLVM uses locks from the lock manager to synchronize updates to LVM volumes and volume groups (also on shared storage).

Fencing is the disconnection of a node from the cluster's shared storage. Fencing cuts off I/O from shared storage, thus ensuring data integrity. The cluster infrastructure performs fencing through the fence daemon, fenced.

CMAN がノードの１つが故障したと判定すると、CMAN はそのノードが故障したことを 他のクラスタインフラストラクチャコンポーネントに通達します。その故障の通達を受けた fenced はそのノードを フェンス（遮断）します。他のインフラストラクチャ コンポーネントはどんな行動を取るべきか判定します — 即ち、復元に必要となるすべてを実行します。 例えば、DLM と GFS はノード故障の通知を受けると、fenced が故障ノードの フェンスを完了したことを検知するまで活動を休止します。故障ノードが フェンスされたことを確認した時点で DLM と GFS はその復元を実行します。DLM は故障ノードのロックを解除し、GFS は故障ノードの ジャーナルを取り戻します。

フェンシング プログラムは、クラスタ設定ファイルからどの方法を使用すべきかを決定します。 クラスタ設定ファイル内の二つの主要素が フェンシング方法を定義します: フェンシングエージェントと フェンシングデバイスです。フェンシングプログラムはクラスタ設定ファイルに指定されているフェンシングエージェントを 呼び出します。その フェンシングエージェントは、そこで フェンシングデバイス を介してノードの フェンス を します。フェンシング が完了した時点で フェンシングプログラムはクラスタマネージャに通知を出します．

Red Hat Cluster Suite は各種の フェンシング 方法を提供します:

図1.3「Power Fencing Example」 shows an example of power fencing. In the example, the fencing program in node A causes the power controller to power off node D. 図1.4「Fibre Channel Switch Fencing Example」 shows an example of Fibre Channel switch fencing. In the example, the fencing program in node A causes the Fibre Channel switch to disable the port for node D, disconnecting node D from storage.

フェンシング 方法の指定はクラスタ設定ファイルを編集して、クラスタ内の各ノード用に フェンシング方法の名前、フェンシングエージェント、及び フェンシングデバイスを割り当てることで 構成されます。

The way in which a fencing method is specified depends on if a node has either dual power supplies or multiple paths to storage. If a node has dual power supplies, then the fencing method for the node must specify at least two fencing devices — one fencing device for each power supply (refer to 図1.5「Fencing a Node with Dual Power Supplies」). Similarly, if a node has multiple paths to Fibre Channel storage, then the fencing method for the node must specify one fencing device for each path to Fibre Channel storage. For example, if a node has two paths to Fibre Channel storage, the fencing method should specify two fencing devices — one for each path to Fibre Channel storage (refer to 図1.6「Fencing a Node with Dual Fibre Channel Connections」).

ノードは単独フェンシング 法か、又は複数フェンシング 法で設定することができます。 ノードを単独 フェンシング 法で設定する場合は、そのノードを フェンスするには, その フェンシング 法のみが使用できます。ノードを 複数 フェンシング 法で設定すると、 フェンシング 法は、クラスタ設定ファイル内に指定してある フェンシング 法の順に従って １つの フェンシング 法から次の フェンシング 法へと 順送り（cascaded） と なります。ノードが故障すると、そのノード用にクラスタ設定ファイル内に指定された最初の フェンシング 法でノードをフェンスします。最初の フェンシング 法が機能しない場合、そのノード用に指定してある 次の フェンシング 法が使用されます。全ての フェンシング 法が機能しない状態になると、最初の フェンシング 法に戻りそのノードがフェンスされるまで、クラスタ設定ファイル内に指定された順で フェンシング 法を繰り返します。

The Cluster Configuration System (CCS) manages the cluster configuration and provides configuration information to other cluster components in a Red Hat cluster. CCS runs in each cluster node and makes sure that the cluster configuration file in each cluster node is up to date. For example, if a cluster system administrator updates the configuration file in Node A, CCS propagates the update from Node A to the other nodes in the cluster (refer to 図1.7「CCS Overview」).

Other cluster components (for example, CMAN) access configuration information from the configuration file through CCS (refer to 図1.7「CCS Overview」).

クラスタ設定ファイル (/etc/cluster/cluster.conf) は、以下のようなクラスタ特性を説明する XML ファイルです。

You can obtain the highest shared-file performance when applications access storage directly. The GFS SAN configuration in 図1.11「GFS with a SAN」 provides superior file performance for shared files and file systems. Linux applications run directly on cluster nodes using GFS. Without file protocols or storage servers to slow data access, performance is similar to individual Linux servers with directly connected storage; yet, each GFS application node has equal access to all data files. GFS supports over 300 GFS nodes.

Multiple Linux client applications on a LAN can share the same SAN-based data as shown in 図1.12「GFS and GNBD with a SAN」. SAN block storage is presented to network clients as block storage devices by GNBD servers. From the perspective of a client application, storage is accessed as if it were directly attached to the server in which the application is running. Stored data is actually on the SAN. Storage devices and data can be equally shared by network client applications. File locking and sharing functions are handled by GFS for each network client.

図1.13「ストレージに直接接続の GFS と GNBD」 shows how Linux client applications can take advantage of an existing Ethernet topology to gain shared access to all block storage devices. Client data files and file systems can be shared with GFS on each client. Application failover can be fully automated with Red Hat Cluster Suite.

図1.20「Two-Tier LVS Topology」 shows a simple LVS configuration consisting of two tiers: LVS routers and real servers. The LVS-router tier consists of one active LVS router and one backup LVS router. The real-server tier consists of real servers connected to the private network. Each LVS router has two network interfaces: one connected to a public network (Internet) and one connected to a private network. A network interface connected to each network allows the LVS routers to regulate traffic between clients on the public network and the real servers on the private network. In 図1.20「Two-Tier LVS Topology」, the active LVS router uses Network Address Translation (NAT) to direct traffic from the public network to real servers on the private network, which in turn provide services as requested. The real servers pass all public traffic through the active LVS router. From the perspective of clients on the public network, the LVS router appears as one entity.

LVS router に到着するサービス要求は virtual IP、いわゆる VIP アドレスへ 届けられます。これは、サイトの管理者が www.example.com などの 完全修飾ドメイン名と関連づける公共的に巡回可能なアドレスで、１つ又は複数の 仮想サーバー^[1] に割り当てられます。VIP アドレスは フェイルオーバー中に １つの LVS router から他の LVS router に移行します。その方法で、浮動 IP アドレス と して知られる VIP アドレスの存在を維持することに注意して下さい。

VIP アドレスは LVS router を公共ネットワークに接続するのと同じデバイスにエイリアス名を付ける ことができます。例えば、eth0 がインターネットに接続されている場合、複数の仮想サーバーが eth0:1 にエイリアス化することができます。別の方法としては、各仮想サーバーは サービス毎に別のデバイスと関連付けすることが出来ます。例えば、HTTP トラフィックは eth0:1 上で、そして FTP トラフィックは eth0:2 上で処理することができます。

一度に１つの LVS router のみがアクティブになることができます。アクティブ LVS router の 役目は、仮想 IP アドレスから実サーバーへサービス要求を転送することです。この転送は八つの ロードバランシングアルゴリズムの１つを基にしています:

また、アクティブ LVS router は、簡単な send/expect スクリプト を通じて 実サーバー上の特定サービスの総合健全性を動的に監視します。HTTPS や SSL などの動的データを 必要とするサービスの健全性チェックを手助けするためには、外部の実行ファイルを呼び出すことも できます。実サーバー上のサービスが異常稼働している場合、アクティブ LVS router はそれが 正常稼働に戻るまでそのサーバーへのジョブ回送を停止します。

バックアップ LVS router はスタンバイシステムの役目を果たします。LVS router は定期的に 主要外部公共インターフェイスを通じて、又はフェイルオーバーの状態ではプライベート インターフェイスを通じてハートビートを交信します。バックアップ LVS router が指定時間内に ハートビートメッセージを受信しなかった場合は、フェイルオーバーを開始してアクティブ LVS router の 役割を受け持ちます。フェイルオーバーの期間中、バックアップ LVS router は、ARP spoofing として知られる技術を使用して故障した router によってサービスされていた VIP アドレスを引き受けます。ARP spoofing では、バックアップ LVS router が 故障ノード宛になっている IP パケット用の目的地であると自己宣言します。故障ノードがアクティブな サービスを回復すると、バックアップ LVS router は再度、バックアップの役割に戻ります。

The simple, two-tier configuration in 図1.20「Two-Tier LVS Topology」 is suited best for clusters serving data that does not change very frequently — such as static web pages — because the individual real servers do not automatically synchronize data among themselves.

図1.21「Three-Tier LVS Topology」 shows a typical three-tier LVS configuration. In the example, the active LVS router routes the requests from the public network (Internet) to the second tier — real servers. Each real server then accesses a shared data source of a Red Hat cluster in the third tier over the private network.

このトポロジーは、アクセス可能なデータが中心的なハイアベイラビリティがあるサーバーに保存されて、エキスポートされた NFS ディレクトリか Samba 共有を 経由して各実サーバーによってアクセスされるような多忙の FTP サーバーに よく適しています。このトポロジーはまた、トランザクション用の中心的なハイアベイラビリティデータベースにアクセスする ウェブサイトに推薦されるものです。更には、Red Hat クラスタのあるアクティブ・アクティブ設定を使用して、 それらの両方の役目を同時に果たす為の１つのハイアベイラビリティクラスタを設定することができます。

NAT （Network Address Translation）routing か、又は LVS のダイレクト routing を 使用することができます。以下のセクションでは、NAT routing と LVS のダイレクト routing に ついて簡単に説明しています

ある特定の状況では、クライアントにとっては LVS ロードバランシングアルゴリズムに その要求を利用可能な最善のサーバーに送信させるよりも、同じ実サーバーに何回も再接続することが 望ましいことがあります。そのような状況の例として、複数画面のウェブ形式、クッキー、SSL、FTP 接続などが あります。そのようなケースでは、クライアントは、コンテキストを維持するためにトランザクションが 同じサーバーで処理されない限りは正常に動作しない可能性があります。LVS はこれを取り扱う為に 二種類の異なる機能を提供します: 固執（persistence） と ファイアウォールマーク（firewall marks） です。

Conga とは、Red Hat クラスタとストレージ用の中央化した 設定と管理を提供するソフトウェアコンポーネントのセットです。Conga は 以下のような主要機能を提供します:

Conga 内の主要コンポーネントは、luci と ricci で、これらは別々にインストール出来ます。luci は １つのコンピュータ上で稼働して、ricci を介して複数のクラスタとコンピュータと 交信します。ricci はそれぞれのコンピュータ（クラスタのメンバーか、 単独のコンピュータ）上で稼働するエージェントであり、Conga により管理 されます。

luci は、ウェブブラウザを通じてアクセス可能で、以下のような タブを介してアクセスできる三つの機能を提供します:

クラスタあるいはストレージを管理するために、管理者はクラスタかコンピュータを luci サーバーに追加（あるいは 登録）します。 クラスタかコンピュータが luci に登録されると、各コンピュータの FQDN ホスト名 又は、 IP アドレスが luci データベース内に保存されます。

１つの luci インスタンスのデータベースは別の luci インスタンスから充填することができます。この機能が luci サーバー インスタンスの複製手段を提供して、パスの効率的なアップグレードとテストを提供します。luci インスタンスのインストールをした場合、そのデータベースは 空のままです。しかし新規の luci サーバーを導入する時に、 既存の luci サーバーから luci データベースの 一部又は全てをインポートすることができます。

各 luci インスタンスは初期インストール時に１人のユーザー— 「管理者」を持っています。管理者ユーザーのみがシステムを luci サーバーに 追加することができます。また、管理者ユーザーは追加のユーザーアカウントを作成して、どのユーザーが luci データベースに登録されているクラスタとコンピュータにアクセスできるかを 決定できます。クラスタとコンピュータをインポートできるのと同様に、新規の luci サーバー内でユーザーをバッチ操作としてインポートすることが可能です。

コンピュータが、管理対象の luci サーバーに追加される場合、 認証は一度だけなされます。その後は認証は必要ありません。（証明証が CA により剥奪されない限りは） その後は、luci インターフェイスを通じてクラスタとストレージを リモート的に設定と管理ができます。luci と ricci は互いに XML 経由で交信します。

以下の図では、三つの主要な luci タブである ホームベース タブ、クラスタ タブ、 ストレージ タブを示しています。

Conga に関する詳細情報については Red Hat クラスタの設定と管理 及び、オンラインで閲覧できる luci サーバーを参照してください。

This section provides an overview of the system-config-cluster cluster administration graphical user interface (GUI) available with Red Hat Cluster Suite. The GUI is for use with the cluster infrastructure and the high-availability service management components (refer to 「Cluster Infrastructure」 and 「ハイアベイラビリティサービス管理」). The GUI consists of two major functions: the Cluster Configuration Tool and the Cluster Status Tool. The Cluster Configuration Tool provides the capability to create, edit, and propagate the cluster configuration file (/etc/cluster/cluster.conf). The Cluster Status Tool provides the capability to manage high-availability services. The following sections summarize those functions.

In addition to Conga and the system-config-cluster Cluster Administration GUI, command line tools are available for administering the cluster infrastructure and the high-availability service management components. The command line tools are used by the Cluster Administration GUI and init scripts supplied by Red Hat. 表1.1「コマンドラインツール」 summarizes the command line tools.

制御/監視 パネルでは、ランタイムステータスを表示します。 これは、pulse デーモンのステータス、LVS routing 表、 及び、LVS 派生の nanny プロセスを表示します。

The GLOBAL SETTINGS panel is where the LVS administrator defines the networking details for the primary LVS router's public and private network interfaces.

The top half of this panel sets up the primary LVS router's public and private network interfaces.

The next three fields are specifically for the NAT router's virtual network interface connected the private network with the real servers.

冗長 パネルの使用で、バックアップ LVS router ノードの設定と 各種ハートビート監視オプションのセットアップをすることができます。

パネルの残りの部分はハートビートチャンネルの設定用で、主要ノードの故障を監視するためにバックアップノードにより使用されます。

仮想サーバー パネルは、現在定義されている仮想サーバーのそれぞれの 情報を提供します。表内の項目には、仮想サーバーのステータス、サーバー名、サーバーに 割り当てられた仮想 IP、仮想 IP のネットマスク、サービスの交信先のポート番号、使用するプロトコル、 及び、仮想デバイスインターフェイスがあります。

仮想サーバー パネル内に表示された各サーバーは、そこから出る 画面、すなわち サブセクション 上で設定することができます。

サービスを追加するには、追加 ボタンをクリックします。 サービスを削除するには、仮想サーバー横のラジオボタンをクリックしてサービスを選択し、 削除 ボタンをクリックします。

表内の仮想サーバーを有効/無効にするには、そのラジオボタンをクリックしてから、 有効/無効にする ボタンをクリックします。

仮想サーバーを追加した後は、左側にあるラジオボタンをクリックすることにより その設定が可能になり、編集 ボタンのクリックで 仮想サーバー サブセクションを表示することができます。