RHEL6 High Availability Add-On Technical Guide

High Availability Add-On 設計・運用入門

V1.5 2011.10.2

Red Hat K.K. All rights reserved.

はじめに

この資料では、 Red Hat Enterprise Linux 6 (RHEL6) で利用可能な HA クラス
タ製品である High Availability Add-On （旧製品名称 RHCS ）について、設計・
運用の前提となる基本事項を紹介しています。

この資料に記載の内容は、 RHEL6.1 に 2011/07 月末時点の最新のアップ
デートパッケージ群を適用した環境で検証しています。

この資料は、資料作成時における最新情報をご参考のために提供することを
目的として記載されており、情報の正確性、完全性または有用性について何
ら保証するものではありません。また、内容は予告なしに変更または更新さ
れることがあります。
 レッドハットのコンサルテーションサービスでは、 High Availability Add-On の
設計、構築の技術支援サービスをご提供させていただいています。プロダク
ション環境への適用にあたっては、これら技術支援サービスのご利用もご検
討ください。

Red Hat K.K. All rights reserved. 2

Contents


High Availability Add-On の概要とアーキテクチャ

運用上の注意点

設計上の注意点

（参考） HA クラスタ関連サービスのご紹介

参考資料


High Availability Add-On の概要とアーキテクチャ


High Availability Add-On とは

High Availability Add-On は、 Red Hat Enterprise Linux 6 (RHEL6) で利用可
能な HA クラスタ機能を提供するアドオン製品です。
●
RHEL6 では、「 High Availability Add-On 」のサブスクリプションを追加購入するこ
とで利用できます。

 クラスタ環境における共有ファイルシステム機能を提供する GFS2 (Global
File System 2) と組み合わせて利用することも可能です。
●
RHEL6 では、「 Resilient Storage Add-On 」のサブスクリプションを追加購入する
ことで GFS2 を利用できます。また、 Resilient Storage Add-On のサブスクリプ
ションには、 High Availability Add-On が含まれています。
●
GFS2 は、 High Availability Add-On が提供するクラスタ管理機能を使用するた
め、 HA クラスタ機能を使用しない場合でも、 GFS2 の利用には High Availability
Add-On の機能が必要となります。


RHEL6 のクラスタ関連 Add-On 一覧
各 Add-On に含まれる機能
共有ファイル
HA クラスタクラスタ LVM ロードバランサ
システム
High Availability
Add-On ○ × × ×
Resilient Storage
Add-On(*1) ○ ○ ○ ×
Load Balancer
Add-On × × × ○
(*1 ） Resilient Storage Add-On は High Availability Add-On の機能を含みます。 Resilient Storage のサブスクリプション
　　　を購入する場合は、 High Availability Add-On のサブスクリプションは不要です。

RHEL4/RHEL5/RHEL6 製品対応関係
RHEL4 RHEL5 RHEL6
IP ロードバランサ Red Hat Cluster Suite Red Hat Enterprise Linux Load Balancer Add-On
Advanced Platform
HA クラスタ High Availability Add-On
共有 Red Hat Global File System Resilient Storage Add-On
ファイルシステム


High Availability Add-On を構成するサービス

大きくは、下図の 4 種類のサービスを利用します。
●
Cluster Manager (cman サービス ) と Resource Group Manager (rgmanager サー
ビス ) は、 High Availability Add-On で提供されます。
●
Cluster LVM デーモン (clvmd サービス ) と GFS2 (gfs2 サービス ) は、 Resilient
Storage Add-On で提供されます。
●
この他にリモート管理機能を提供する ricci 、および luci サービスがあります。

HA リソースの監視と切り替え Resource Group Manager (rgmanager サービス )

GFS2
共有ファイルシステム (gfs2 サービス )
Resilient Storage Add-On
共有ディスクに対する LVM Cluster LVM デーモン
（論理ボリュームマネージャ） (clvmd サービス )
Cluster Manager
クラスタ・ノードの死活監視と (cman サービス）
障害発生時の強制再起動
Fence デーモン Quorum Disk
(fenced) デーモン (qdiskd)


一般的なハードウェア構成例
 サービスネットワークの他に、管理ネットワーク、およびハートビート・ネットワークを用意します。ハートビー
ト・ネットワークは、スプリットブレインを防止するために Bonding ドライバで冗長化します。

ハートビート・ネットワークとは独立した管理ネットワーク経由で、他のノードを強制再起動できる仕組みが
必要です。下図の例では、 IPMI を利用して強制再起動を行います。

Bonding ドライバに Fence デーモンによる
よる NIC チーミング強制再起動に使用
サービスネットワーク

管理ネットワーク

NIC NIC NIC IPMI NIC NIC NIC IPMI NIC NIC NIC IPMI

NIC NIC HBA HBA NIC NIC HBA HBA NIC NIC HBA HBA

ハートビート・
ハートビートパケットネットワーク
SAN
共有ストレージ


典型的な「鉄板構成例」

特別な要件がない限りは、最もシンプルな 2 ノードのアクティブ・スタンバイ構成をお勧めしま
す。 2 ノード構成に特有のスプリットブレインに伴う問題を回避する際は、 Quorum Disk が必要
です。
サービスネットワーク


アクティブノードスタンバイノード

NIC NIC NIC NIC IPMI NIC NIC NIC NIC IPMI

NIC NIC HBA HBA NIC NIC HBA HBA

ハートビート・
ネットワーク
FC または SAS 接続
の共有ストレージ
Quorum Disk アプリケーション
(100MB 程度 ) データ領域


スプリットブレインと Quorum について

スプリットブレインと Quorum （クォラム）は、 High Availability Add-On に限ら
ず、一般のクラスタシステムで用いられる用語です。


スプリットブレインとは、ネットワーク障害などでクラスタが複数の島に分断さ
れる状況のことを言います。
●
異なる島のノードは、共有リソースの稼働情報やロック情報を共有できませんの
で、異なる島のノードが同時に稼働を続けると、共有リソースが破壊される恐れ
があります。

Quorum は、スプリットブレインが発生した際に、

ハートビート・ネットワーク
Votes=2
特定の島だけが稼働を継続する仕組みです。 node01

●
各ノードは事前に定義された Votes （投票数）の
値を提出します。その島に含まれるノードの node02
Votes の合計値が、事前に決めた Quorum （定
足数）の値を越えた島が稼働を継続します。
Votes=1
●
1 つの島だけが Quorum を満たすように Votes node03
と Quorum の値を定義する必要があります。
●
単純な例では 1 ノードあたり 1Vote で、 Quorum Quorum=2 の場合、
を全ノード数の過半数以上とします（右図）。上の島だけが稼働を継続する。


Fence デーモン (fenced) について

スプリットブレインが発生すると、 Quorum を満たすノードは、 Fence デーモン
を利用して、 Quorum を満たさないノードを強制再起動します。
●
強制再起動には複数の方法が選択できます。標準的な方法としては、 IPMI な
ど、サーバ・ハードウェアが持つリモート管理機能を利用します。
●
ハートビートパケットを流すネットワークが切断した状況で実施する必要がありま
すので、ハートビート・ネットワークとは独立した管理ネットワークを通じて、強制
再起動が実施できる必要があります。
●
再起動したノードで Cluster Manager が勝手に起動しないように、クラスタ関連
サービスは自動起動しないように設定します。
Fence デーモン、および強制再起動に使用する


node01
管理ネットワークの構成は、使用するサーバの

種類に応じた適切な設計が必要です。
●
例えば、 IPMI で強制再起動を行う場合、 IPMI と node02
通信する NIC が管理ネットワークに接続され
て、各ノードから IP アクセスできるようにします。
●
Fence デーモンが対応する強制再起動の方法 node03
についても事前にご確認ください (*1) 。強制再起動
(*1) 対応デバイスの説明 http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Cluster_Administration/ap-fence-device-param-CA.html　　
　レッドハットサポート対象の確認 https://access.redhat.com/kb/docs/DOC-30003

Quorum Disk デーモン (qdiskd) について

前述の Quorum は、基本的には「多数決」で稼働を継続する島を決定する方
式ですが、 HA クラスタで利用するには不都合な場合があります。
●
ノード数が偶数で同数の島に分かれると、両方の島が Quorum を満たすことがで
きず、サービスが停止します。特に、典型的な 2 ノード構成に対応できません。
●
2 ノード構成の場合は後述の専用オプション (two_node="1") を指定する方法もありま
すが、それでも問題点が残ります。
●
特殊なケースでは、特定の条件を満たす島でサービスを継続したい場合や、過
半数以上のノードが障害で停止してもサービスを継続したい場合があります。

 Quorum Disk デーモンを使用すると、「多数決」以外の条件でサービスを継続
する島を決定することができるので、上記の問題を回避できます。
●
共有ディスクの一部を Quorum Disk として定義します。 Quorum Disk にも Votes
を持たせることで、ノード数が少ない島でも Quorum を満たすことができます。
●
各ノードで Heuristic ( ヒューリスティック ) と呼ばれるヘルスチェックを実施して、
これを満たさないノードは自発的に再起動します。
●
2 ノード構成の場合は、 Heuristic の代わりに、 master_wins オプションも使用できます
（後で説明）。
●
Heuristic の内容はユーザが定義します。複数の島が同時に Quorum を満たすことが
ないように、 Heuristic の定義を工夫する必要があります。

2 ノード構成クラスタの動作について
(Quorum Disk を使用しない場合 )

2 ノード構成で Quorum Disk を使用しない場合は、設定ファイル cluster.conf
の cman タグに次のオプションを指定します。
<cman expected_votes="1" two_node="1"/>
●
expected_votes は、本来は正常時の Votes の合計値ですが、特別に 1 にします。
 この時、 Cluster Manager は次のような動作を行います。
●
Quorum ( ノード数の過半数以上 ) の値は 2 になりますが、 1 ノードだけでもサー
ビスの継続を許可します。
● スプリットブレインが発生すると、両方のノードがお互いに相手ノードの強制再起
動を試みます。「早い者勝ち」で生き残ったノードがサービスを継続します。


この構成には、次のような問題があります (*1) 。

node01
● タイミングによっては、両方のノードが再起動して
サービスが停止する可能性があります。
●
( 推奨される構成ではありませんが ) サービスネッ node02
トワークとハートビート・ネットワークを兼用している
場合、 NIC 障害でハートビートが切れた際に、 NIC 相互に強制再起動
障害ノードが生き残る可能性があります。（どちらが生き残るかは不定）
(*1) したがって、 2 ノード構成では Quorum Disk の使用を推奨します。 Quorum Disk を使用しない場合は、　　　　　
　　　ハートビート・ネットワークの冗長化を確実に行い、できる限りハートビートの切断が発生しないようにします。

2 ノード構成クラスタの動作について
(Quorum Disk を使用する場合 )

2 ノード構成で Quorum Disk を使用する場合は、 Quorum Disk の Votes に 1
を与えた上で、 cluster.conf の cman タグに次のオプションを指定します。


この時、 Cluster Manager は次のような動作を行います。
●
Quorum ( 全 Votes の過半数以上 ) の値は 2 になりますが、 Qurum Disk の
Votes が追加されるので、 1 ノードだけでも Quorum が満たされます (*1) 。
●
スプリットブレインが発生すると、 Heuristic で定義したヘルスチェックにより、どち
らかのノードが自発的に再起動して、もう一方のノードがサービスを継続します。
●
前述のサービスネットワークとハートビート・ネット Votes=2

ワークを兼用している例では、「サービスネット
ワーク上のゲートウェイに ping が通ることをチェッ

node01
クする」などが考えられます。
●
ハートビート・ネットワークが独立している場合は、 Quorum
ヘルスチェックの代わりに、後述の master_wins オ Disk
プションを使用します。
node02

Votes=2
Heuristic （もしくは master_wins
(*1) Quorum Disk は、特定の島だけに Votes を与えるわけではありません。オプション）で自発的に再起動

Quorum Disk の補足情報

3 ノード以上の構成で Quorum Disk を使用する場合は、サービスの継続を許
可する最低ノード数に応じて、 Quorum Disk の Votes を定義します。
●
例えば、全ノード数の過半数を与えると、 1 ノードでもサービスを継続します。


Heuristic によるヘルスチェックの内容はシェルスクリプトで実装します。複数
の Heuristic を定義することも可能です。
 ストレージ接続障害で Quorum Disk へのアクセスができなくなったノードは、
自発的に再起動して、クラスタを離脱します。
 2 ノード構成では、 Heuristic を定義する代わりに、 master_wins オプションを
指定すると、 ( 内部ロジックで決定される ) マスタノードが必ず生き残ります。
master_wins オプションを使用する定義の例 (*1)
<quorumd interval="1" label="qdisk01" master_wins="1" tko="10" votes="1"/>

Heuristic を使用する定義の例
<quorumd interval="1" label="qdisk01" tko="10" votes="1">
<heuristic interval="2" program="/usr/local/bin/pingcheck.sh" score="1" tko="3"/>
</quorumd>

(*1) master_wins と Heuristic の併用はできません。また、 master_wins は 2 ノード構成のみで使用できます。

Resource Group Manager のアーキテクチャ (1)

Resource Group Manager (rgmanager サービス ) は、 Cluster Manager (cman
サービス ) が管理するクラスタ上に、次のような仕組みで HA クラスタ機能を
提供します。
●
複数のノードを含む「フェイルオーバ・ドメクラスタ
イン」を定義します。
フェイルオーバ・ドメイン
●
HA クラスタで保護されるサービスは、フェ
イルオーバ・ドメイン内のノードで引き継ぎ node01 node02 node03
が行われます。
●
ノードの優先順位を設定して、優先的にア
クティブになるノードを指定することができ割り当て
ます。サービス
●
任意のリソースを含む「サービス」を定義
します。 IP Address
リソース起動順序
●
リソースの種類には、事前準備された「 IP
Address 」「 File System 」「 PostgreSQL File System
8 」などがあります (*1) 。
●
リソースの親子関係を設定して、起動順 PostgreSQL 8
序を指定することも可能です。

(*1) 事前に用意されたリソースについては下記の URL を参照 http://docs.redhat.com/docs/en-
US/Red_Hat_Enterprise_Linux/6/html/Cluster_Administration/ap-ha-resource-params-CA.html

Resource Group Manager のアーキテクチャ (2)
●
独自のアプリケーションをリソース化する場合は、「 script 」リソースを使用するのが
簡単です。これは、 start 、 stop 、 status オプションを受け付ける /etc/init.d/ スクリプ
トを利用して、アプリケーションを起動、停止、監視するリソースです。
●
独自のリソースをスクラッチから作成する場合は、既定の仕様にしたがったリソース・
スクリプトを用意します。
●
定義したサービスをフェイルオーバードメインに割り当てます。
●
Resource Group Manager からサービスを開始すると、フェイルオーバ・ドメイン内の
ノードで、サービス内のリソースが起動します。


クラスタ設定ファイルの例

2 ノードの「鉄板構成例」です。
/etc/cluster/cluster.conf
<?xml version="1.0"?>
<cluster config_version="12" name="cluster01">
<clusternodes>
<clusternode name="node01" nodeid="1" votes="1">
<fence>
サービス NW 
</fence>
管理 NW </clusternode>
<clusternode name="node02" nodeid="2" votes="1">
<fence>

</fence>
</clusternode>
</clusternodes>
<totem token="20000"/>
votes=1 votes=1 <quorumd interval="1" master_wins="1" tko="10" votes="1" label="qdisk01"/>
<fencedevices>

qdisk </fencedevices>
<rm>
<failoverdomains>
votes=1 <failoverdomain name="dom01" ordered="1" restricted="1">
<failoverdomainnode name="node01" priority="1"/>
</failoverdomain>
</failoverdomains>
<service autostart="0" domain="dom01" name="service01">
<ip address="192.168.7.99" monitor_link="on"/>
<fs device="/dev/sdb" fstype="ext4" mountpoint="/data01" name="data_fs">
<script file="/etc/init.d/myappl" name="myappl"/>
</fs>
</service>
</rm>
</cluster>

運用上の注意点


クラスタの起動手順について (1)

クラスタを起動する際は、 cman 、 clvmd 、 gfs2 、 rgmanager の各サービス ( ク
ラスタサービス ) をこの順番に起動します。
●
基本的には、クラスタに参加するノードで一斉にこれらのサービスを起動しま
す。 SSH などを利用して、同時に自動起動するスクリプトを用意することをおす
すめします。

rgmanager サービスが起動した段階で、クラスタ上で提供する「サービス」の操作が
可能になります。
自ノードのサービスを全ノードのサービスを
起動・停止するスクリプトの例起動・停止するスクリプトの例
/usr/local/bin/clstart /usr/local/bin/clstart_all
#!/bin/sh #!/bin/sh
service cman start ssh node01 /usr/local/bin/clstart &
CLVM/GFS2 を使用する service clvmd start ssh node02 /usr/local/bin/clstart &
場合のみ必要 service gfs2 start ssh node03 /usr/local/bin/clstart &
service rgmanager start wait

/usr/local/bin/clstop /usr/local/bin/clstop_all
#!/bin/sh #!/bin/sh
service rgmanager stop ssh node01 /usr/local/bin/clstop &
CLVM/GFS2 を使用する service gfs2 stop ssh node02 /usr/local/bin/clstop &
場合のみ必要 service clvmd stop ssh node03 /usr/local/bin/clstop &
service cman stop wait


クラスタの起動手順について (2)

各ノードのクラスタサービスを１ノードずつ起動すると Quorum の機能に関連
して次のような問題が発生します。（ここでは 3 ノードの例で説明します。）
●
1 つ目のノードでサービスが起動した際に、 Quorum が満たされない場合、 cman
サービスの起動が完了せず、他のノードのサービスの起動待ちになります。
●
2 つ目のノードのサービスが起動した段階で Quorum が満たされると、 2 ノードで
クラスタの起動が完了します。
● ただし、 3 つ目のノードのサービスが起動していないため、起動済みのノードは
スプリットブレインと判断して、 3 つ目のノードを強制再起動します。
●
例えば、 3 つ目のノードでサービスが起動しているにも関わらず一時的に応答不能
で、その後、回復して共有リソースへのアクセスを行ってしまうなどの可能性があるた
め、これはクラスタの挙動としては正しい動作です。
●
3 つ目のノードが強制再起動された後に、 3 つ目のノードでサービスを起動すると、正
常にクラスタに参加します。

この問題を避けるには、次のどちらかの運用方法が必要です。
●
すべてのノードで必ず同時にクラスタサービスを起動する。
●
Quorum に達する最低数のノードのみ OS を起動した状態で、クラスタサービスを
順次起動して、その後、残りのノードについて OS の起動とクラスタサービスの起
動を 1 ノードずつ繰り返す。

サービスの操作について

サービスの稼働状態は、 clustat コマンドで確認します。サービスの開始、停
止、禁止、手動での引き継ぎなどは clusvcadm コマンドを使用します。
# clustat
Cluster Status for cluster01 @ Tue Aug 2 19:10:44 2011
Member Status: Quorate

Member Name ID Status
------ ---- ---- ------
node01 1 Online, Local, rgmanager
node02 2 Online, rgmanager
node03 3 Online, rgmanager

Service Name Owner (Last) State
------- ---- ----- ------ -----
service:service01 node01 started


サービスの状態 (State) には次のような種類があります。
状態説明
started サービスは開始しています。
stopped サービスは停止しています。フェイルオーバ・ドメイン内のノードで rgmanager
サービスが再起動すると、再開します。
disabled サービスは禁止されており、自動的に開始することはありません。
recoverable サービスは異常停止しており、引き継ぎ処理が開始する予定です。
failed サービスは異常停止しており、引き継ぎ処理もできない状態です。問題の原
因を取り除いて、一旦、手動で disabled 状態に変更する必要があります。

サービスの操作と問題判別に使用するコマンド

サービスの操作に使用する主なコマンドです
コマンド説明
# clusvcadm -e <service> -m <node> サービスを指定ノードで開始 (enable) します。
（ノード指定省略時はコマンドを実行したノード）
# clusvcadm -r <service> -m <node> サービスを指定ノードに引き継ぎ (relocate) します。
（ノード指定省略時は自動的に決定）
# clusvcadm -d <service> サービスを停止 (disable) します。

 設定ファイルの問題判別に使用する主なコマンドです。
コマンド説明
# ccs_config_validate /etc/cluster/cluster.conf の内容に問題がないか
チェックします。
# ccs_config_dump 起動中のノードが認識している設定ファイルの内容を
出力します。
# rg_test test /etc/cluster/cluster.conf サービスリソースの設定の解釈を表示します。
# rg_test noop /etc/cluster/cluster.conf サービスリソースの起動順序を表示します。
start service <service>
# rg_test noop /etc/cluster/cluster.conf サービスリソースの停止順序を表示します。
stop service <service>
# cman_tool kill -n <node> 指定ノードを強制停止して、 Fence デーモンの動作
確認を行います。

サービス起動ノードの優先順位

ordered="1" は、「自動引き戻し」を有効にする指定です。
●
priority が高い（値が小さい）ノードが停止・再起動するとサービスが移動します。
●
autostart="1" で自動起動する際は、 priority が高いノードで起動します。
 ordered="0" の場合は、 priority の値は無視されます。
●
autostart="1" で自動起動する際にサービスが起動するノードは不定です。

clusvcadm コマンドでサービスを手動起動する場合は、 ordered の指定に関係なく、
コマンドを実行したノード、もしくは明示的に指定したノードでサービスが起動します。
●
ordered="0", autostart="0" で、ノード指定でのサービスの手動起動がお勧め。
<rm>
<failoverdomains>
<failoverdomain name="dom01" ordered="1" restricted="1">
</failoverdomain>
</failoverdomains>
<service autostart="0" domain="dom01" name="service01">
<ip address="192.168.7.99" monitor_link="on"/>
<fs device="/dev/sdb" fstype="ext4" mountpoint="/data01" name="data_fs">
<script file="/etc/init.d/myappl" name="myappl"/>
</fs>
</service>
</rm>


障害発生時の引き継ぎフロー

図は稼動系で障害が発生した場合の引継ぎ処理のフローです。主な障害の
パターンに対する処理の流れは次のようになります。
●
ノード障害、ネットワーク障害
●
Cluster Manager が通信不能となるため、 Fence デーモンによる強制再起動の後に、
待機系でサービスが開始します。
稼動系の障害発生
●
アプリケーション障害
Yes
●
稼動系でアプリケーションの再 Cluster Manager は通信可能？稼動系でサービス回復を実施
起動が試みられた後、失敗した
場合は、稼動系でサービスを停 No
止した後に、待機系でサービスサービス回復成功？
Fence デーモンが強制再起動を実施
が開始します。
No
● ディスク障害 Yes
待機系でサービス開始稼動系でサービス停止
●
ディスク使用リソースのアプリ
ケーション障害として動作 (*1) 。 No
サービス開始成功？サービス停止成功？
●
Quorum Disk を使用している場
合は、稼働系が自発的に再起 Yes No
動して、待機系でサービスが開 Yes
始します。 started 状態 failed 状態

(*1) ファイルシステムリソース（ fs タグ）では、オプション self_fence="1" を指定することをお勧めします。ファイルシステム
リソースの停止（アンマウント）に失敗すると自発的に再起動して、サービスが failed 状態になることを防ぎます。

クラスタの停止手順について

クラスタ全体を停止する際は、クラスタ上のサービスを停止（もしくは禁止）し
た後に、各ノードのクラスタサービスを停止します。
●
クラスタ上のサービスが開始した状態でクラスタサービスを停止すると、意図しな
いサービスの引き継ぎが発生する可能性がありますので、安全のためにサービ
スは停止しておきます。

メンテナンスなどの目的でスタンバイノードだけを停止する際は、 1 ノードだけ
で停止してもスプリットブレインと判断されることはありません。
●
cman サービスが停止する際に、他のノードに停止情報を通知します。
●
3 ノード以上の構成の場合は、残りのノードが Quorum を満たすように注意して停
止してください。


設計上の注意点


一般的な注意事項 (1)

High Availability Add-On の設計を行う際は、最低限、次の点は確認してくだ
さい。
●
フェンスデバイスは適切に構成されているか。
●
手動での再起動を前提とした manual_fence は、評価環境用のオプションです。プロダ
クション環境ではサポートされません。
●
そもそもフェンスデバイスを使用しない環境もサポートされません。
●
ディスク I/O を停止するフェンス方法も提供されていますが、強制再起動を行うフェン
スと併用する必要があります。
●
Quorum と Votes の設定は適切かどうか。
●
2 ノード構成では Quorum Disk を使用することを推奨します。
●
3 ノード以上の構成では Quorum Disk は使用しないことを推奨します。（ Heuristic の
設定が複雑になりがちなため。）奇数ノードの構成にして、多数決ルールを採用しま
す。


一般的な注意事項 (2)
●
Quorum Disk を使用する際は、 Heuristic の実装は適切かどうか。
●
スプリットブレイン発生時に、特定の島だけが Heuristic のヘルスチェックをパスする
必要あります。
●
2 ノード構成でハートビート専用ネットワークがある場合は、ヘルスチェックの代わりに
master_wins オプションを使用することをお勧めします。
●
サービスネットワークとハートビートネットワークを兼用する場合は、ゲートウェイへの
ping アクセスを確認するのがシンプルです。
●
アプリケーションの起動スクリプトは適切に実装できるか。
●
「 script 」リソースから使用する /etc/init.d/ スクリプトは、 LSB の仕様に沿ったオプ
ション (start, stop, restart, status ）を実装してください。
●
stop オプションでアプリケーションを強制停止できるようにしてください。
●
start/stop に失敗した際にはエラーコードを返してください。
●
start 、もしくは stop を 2 回続けて実行した際にエラーにならないようにしてください。
●
クラスタで保護される障害の範囲を適切に把握しているか。
●
HA クラスタは、複数の障害が同時に発生した場合、必ずしもサービスの継続を保証
するわけではありません。 HA クラスタで保護するべき障害の範囲を要件定義した上
で、それらの要件を満たす設計を実施してください。


特に注意が必要な場合

特に次のような環境で使用する際は、環境に応じたパラメータのチューニング
が必要な場合があります (*1) 。
●
サービスネットワークとハートビート・ネットワークを兼用している環境で、ネット
ワークの高負荷が予想される場合
●
ハートビートパケットの遅延により、障害の誤検知が発生する可能性があります。
● ディスク I/O の高負荷が予想される環境で Quorum Disk を使用する場合
●
Quorum Disk へのアクセスの遅延により、障害の誤検知が発生する可能性がありま
す。 I/O スケジューラを deadline スケジューラに変更するなどで回避します。
●
特に iSCSI ディスクは高負荷時に遅延が発生しやすいので注意が必要です。
●
DMMP などのマルチパス構成ストレージに Quorum Disk を配置する場合
●
I/O パスの切替時間、 Quorum Disk による障害検知時間、ハートビートによる障害検
知時間の依存関係を適切に設定する必要があります。
●
I/O パス切替時間＜ qdisk 障害検知時間＜ハートビート検知時間（ qdisk 障害検知時
間の 2 倍以上）が原則

(*1) このようなプロダクション環境で High Availability Add-On を利用する際は、レッドハットのコンサルテーションサービス
のご利用をおすすめします。

HA クラスタ設計時の心構え

シンプルなアクティブ・スタンバイ構成がベストです。
●
HA クラスタは障害発生中の環境下で機能するため、障害の副作用を受けない
ように、できるかぎり構成をシンプルにします。
●
特別な要件がない限りは、 2 ノード + Quorum Disk によるアクティブ・スタンバイ
構成をおすすめします。

対応するべき障害の範囲を明確にします。
●
HA クラスタはあらゆる障害に対応する魔法のソフトウェアではありません。特
に、 2 重障害の発生には対応できない場合が多数あります。
●
HA クラスタで保護したい障害内容を洗い出しておき、各障害パターンに対する
障害テストを確実に実施してください。

運用を意識した設計を行います。
●
HA クラスタは複数のノードが密に連携するため、常にそれぞれのノードの状況を
みながら操作を行う必要があります。
●
運用手順が複雑になる設計は避けた上で、運用手順書の整備を怠らないように
してください。


（参考） HA クラスタ設計・構築支援サービスのご紹介


High Availability Add-On 関連のサービス一覧

高度な専門知識を有するレッドハットのエンジニアが
各フェーズの作業の技術支援をご提供いたします
 安定した HA クラスタの実現には、設計段階での問題を排除することが最重要ポイ
ントになります。まずは、要件定義・クラスタ設計段階での「 HA クラスタ設計支援
サービス」のご利用をお勧めいたします。

お客様のご希望に応じて、後続のフェーズにおける 3 種類の支援サービスを追加
でご提供させていただきます。
HA クラスタ監視スクリプト
構築支援サービス作成支援サービス

要件定義クラスタ設計クラスタ構築運用引き継ぎ

HA クラスタ運用資料作成
設計支援サービス支援サービス

HA クラスタ構築ビジネス・スタートアップサービス

HA クラスタ構築サービスの提供を検討される
SI 事業者様に、レッドハットのエキスパートエンジニアが
さまざまなノウハウをお伝えいたします

High Availability Add-On を利用した HA クラスタ構築サービスの提供に不可欠な技
術スキルとノウハウを実案件を想定した形式でお伝えします。
 本サービスのトレーニングを受講して、一定の要件をクリアされた SI 事業者様には
トレーニング修了の認定証を発行いたします。

トレーニング期間とお見積もりについては、ご相談ください。

すべてのフェーズのノウハウを伝授

要件定義クラスタ設計クラスタ構築運用引き継ぎ


参考資料


参考資料

High Availability Add-On の製品マニュアル
●
「 High Availability Add-On Overview 」および「 Cluster Administration 」を参照
http://docs.redhat.com/docs/ja-JP/Red_Hat_Enterprise_Linux/index.html


High Availability Add-On のサブスクリプション価格
http://www.jp.redhat.com/rhel/purchasing_guide.html


変更履歴

2011/08/08 Version 1.0 公開版

2011/08/08 Version 1.1 two_node="1" に対応する expected_votes を修正

2011/08/18 Version 1.2 各種説明を補足

2011/08/22 Version 1.3 Fence デバイスのサポート URL 追記

2011/08/27 Version 1.4 微修正

2011/10/02 Version 1.5 微修正


WE CAN DO MORE
WHEN WE WORK TOGETHER

THE OPEN SOURCE WAY


RHEL6 High Availability Add-On Technical Guide

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to RHEL6 High Availability Add-On Technical Guide

Similar to RHEL6 High Availability Add-On Technical Guide (20)

More from Etsuji Nakai

More from Etsuji Nakai (20)

Recently uploaded

Recently uploaded (9)

RHEL6 High Availability Add-On Technical Guide