rhel6 high availability add-on technical guide

Red Hat K.K. All rights reserved.

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

V1.5 2011.10.2

Red Hat K.K. All rights reserved. 2

はじめに

この資料では、 Red Hat Enterprise Linux 6 (RHEL6) で利用可能な HA クラスタ製品である High Availability Add-On （旧製品名称 RHCS ）について、設計・運用の前提となる基本事項を紹介しています。

この資料に記載の内容は、 RHEL6.1 に 2011/07 月末時点の最新のアップデートパッケージ群を適用した環境で検証しています。

この資料は、資料作成時における最新情報をご参考のために提供することを目的として記載されており、情報の正確性、完全性または有用性について何ら保証するものではありません。また、内容は予告なしに変更または更新されることがあります。

レッドハットのコンサルテーションサービスでは、 High Availability Add-On の設計、構築の技術支援サービスをご提供させていただいています。プロダクション環境への適用にあたっては、これら技術支援サービスのご利用もご検討ください。


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 一覧

RHEL4 RHEL5 RHEL6

IP ロードバランサ Red Hat Cluster Suite Red Hat Enterprise Linux Advanced Platform

Load Balancer Add-On

HA クラスタ High Availability Add-On

共有ファイルシステム

Red Hat Global File System Resilient Storage Add-On

(*1 ） Resilient Storage Add-On は High Availability Add-On の機能を含みます。 Resilient Storage のサブスクリプション　　　を購入する場合は、 High Availability Add-On のサブスクリプションは不要です。

HA クラスタクラスタ LVM共有ファイル

システムロードバランサ

High AvailabilityAdd-On ○ × × ×

Resilient StorageAdd-On(*1) ○ ○ ○ ×

Load BalancerAdd-On × × × ○

RHEL4/RHEL5/RHEL6 製品対応関係

各 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 サービスがあります。

Cluster Manager (cman サービス）

Fence デーモン(fenced)

Quorum Disk デーモン (qdiskd)

Cluster LVM デーモン(clvmd サービス )

GFS2(gfs2 サービス )

Resource Group Manager (rgmanager サービス )

クラスタ・ノードの死活監視と障害発生時の強制再起動

共有ディスクに対する LVM（論理ボリュームマネージャ）

共有ファイルシステム

HA リソースの監視と切り替え

Resilient Storage Add-On


一般的なハードウェア構成例

サービスネットワークの他に、管理ネットワーク、およびハートビート・ネットワークを用意します。ハートビート・ネットワークは、スプリットブレインを防止するために Bonding ドライバで冗長化します。

ハートビート・ネットワークとは独立した管理ネットワーク経由で、他のノードを強制再起動できる仕組みが必要です。下図の例では、 IPMI を利用して強制再起動を行います。

管理ネットワーク

サービスネットワーク

ハートビートパケット

Fence デーモンによる強制再起動に使用

Bonding ドライバによる NIC チーミング

NIC NIC NIC IPMI

HBA HBANIC NIC

NIC NIC NIC IPMI

HBA HBANIC NIC

NIC NIC NIC IPMI

HBA HBANIC NIC

ハートビート・ネットワーク

SAN共有ストレージ


典型的な「鉄板構成例」

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

管理ネットワーク

サービスネットワーク

ハートビート・ネットワーク

Quorum Disk(100MB 程度 )

アプリケーションデータ領域

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

FC または SAS 接続の共有ストレージ

NIC NIC NIC IPMI

HBA HBANIC NIC

NIC NIC NIC NIC IPMI

HBA HBANIC NIC

NIC


スプリットブレインと Quorum について

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

スプリットブレインとは、ネットワーク障害などでクラスタが複数の島に分断される状況のことを言います。

● 異なる島のノードは、共有リソースの稼働情報やロック情報を共有できませんので、異なる島のノードが同時に稼働を続けると、共有リソースが破壊される恐れがあります。

Quorum は、スプリットブレインが発生した際に、特定の島だけが稼働を継続する仕組みです。

● 各ノードは事前に定義された Votes （投票数）の値を提出します。その島に含まれるノードのVotes の合計値が、事前に決めた Quorum （定足数）の値を越えた島が稼働を継続します。

● 1 つの島だけが Quorum を満たすように Votesと Quorum の値を定義する必要があります。

● 単純な例では 1 ノードあたり 1Vote で、 Quorumを全ノード数の過半数以上とします（右図）。

node01

node02

node03

Votes=2

Votes=1

Quorum=2 の場合、上の島だけが稼働を継続する。

ハー

トビ

ート

・ネ

ット

ワー

ク


Fence デーモン (fenced) について

スプリットブレインが発生すると、 Quorum を満たすノードは、 Fence デーモンを利用して、 Quorum を満たさないノードを強制再起動します。

● 強制再起動には複数の方法が選択できます。標準的な方法としては、 IPMIなど、サーバ・ハードウェアが持つリモート管理機能を利用します。

● ハートビートパケットを流すネットワークが切断した状況で実施する必要がありますので、ハートビート・ネットワークとは独立した管理ネットワークを通じて、強制再起動が実施できる必要があります。

● 再起動したノードで Cluster Manager が勝手に起動しないように、クラスタ関連サービスは自動起動しないように設定します。

Fence デーモン、および強制再起動に使用する管理ネットワークの構成は、使用するサーバの種類に応じた適切な設計が必要です。

● 例えば、 IPMIで強制再起動を行う場合、 IPMIと通信する NIC が管理ネットワークに接続されて、各ノードから IPアクセスできるようにします。

● Fence デーモンが対応する強制再起動の方法についても事前にご確認ください (*1)。

ハー

トビ

ート

・ネ

ット

ワー

ク

管理

ネッ

トワ

ーク

node01

node02

node03

強制再起動(*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

http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Cluster_Administration/ap-fence-device-param-CA.html


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 タグに次のオプションを指定します。

● expected_votes は、本来は正常時の Votes の合計値ですが、特別に 1 にします。

この時、 Cluster Manager は次のような動作を行います。

● Quorum ( ノード数の過半数以上 ) の値は 2 になりますが、 1 ノードだけでもサービスの継続を許可します。

● スプリットブレインが発生すると、両方のノードがお互いに相手ノードの強制再起動を試みます。「早い者勝ち」で生き残ったノードがサービスを継続します。

<cman expected_votes="1" two_node="1"/>

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

● タイミングによっては、両方のノードが再起動してサービスが停止する可能性があります。

● (推奨される構成ではありませんが ) サービスネットワークとハートビート・ネットワークを兼用している場合、 NIC 障害でハートビートが切れた際に、 NIC障害ノードが生き残る可能性があります。ハ

ート

ビー

ト・ネ

ット

ワー

ク

管理

ネッ

トワ

ーク

node01

node02

相互に強制再起動（どちらが生き残るかは不定）

(*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で定義したヘルスチェックにより、どちらかのノードが自発的に再起動して、もう一方のノードがサービスを継続します。

<cman expected_votes="3" two_node="0"/>

管理

ネッ

トワ

ークnode01

node02

Heuristic （もしくは master_winsオプション）で自発的に再起動

● 前述のサービスネットワークとハートビート・ネットワークを兼用している例では、「サービスネットワーク上のゲートウェイに ping が通ることをチェックする」などが考えられます。

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

(*1) Quorum Diskは、特定の島だけに Votes を与えるわけではありません。

Quorum Disk

Votes=2

Votes=2ハ

ート

ビー

ト・ネ

ット

ワー

ク


Quorum Disk の補足情報

3ノード以上の構成で Quorum Diskを使用する場合は、サービスの継続を許可する最低ノード数に応じて、 Quorum Diskの Votes を定義します。

● 例えば、全ノード数の過半数を与えると、 1 ノードでもサービスを継続します。

Heuristicによるヘルスチェックの内容はシェルスクリプトで実装します。複数の Heuristicを定義することも可能です。

ストレージ接続障害で Quorum Diskへのアクセスができなくなったノードは、自発的に再起動して、クラスタを離脱します。

2 ノード構成では、 Heuristicを定義する代わりに、 master_wins オプションを指定すると、 ( 内部ロジックで決定される ) マスタノードが必ず生き残ります。

<quorumd interval="1" label="qdisk01" master_wins="1" tko="10" votes="1"/>

<quorumd interval="1" label="qdisk01" tko="10" votes="1"> <heuristic interval="2" program="/usr/local/bin/pingcheck.sh" score="1" tko="3"/></quorumd>

master_wins オプションを使用する定義の例 (*1)

Heuristic を使用する定義の例

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


Resource Group Manager のアーキテクチャ (1)

Resource Group Manager (rgmanager サービス ) は、 Cluster Manager (cmanサービス ) が管理するクラスタ上に、次のような仕組みで HA クラスタ機能を提供します。

● 複数のノードを含む「フェイルオーバ・ドメイン」を定義します。

● HA クラスタで保護されるサービスは、フェイルオーバ・ドメイン内のノードで引き継ぎが行われます。

● ノードの優先順位を設定して、優先的にアクティブになるノードを指定することができます。

● 任意のリソースを含む「サービス」を定義します。

● リソースの種類には、事前準備された「 IP Address 」「 File System 」「 PostgreSQL 8 」などがあります (*1)。

● リソースの親子関係を設定して、起動順序を指定することも可能です。

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

フェイルオーバ・ドメイン

node02 node03node01

クラスタ

IP Address

File System

PostgreSQL 8

リソース起動順序

サービス

割り当て


Resource Group Manager のアーキテクチャ (2)

● 独自のアプリケーションをリソース化する場合は、「 script 」リソースを使用するのが簡単です。これは、 start 、 stop 、 status オプションを受け付ける /etc/init.d/ スクリプトを利用して、アプリケーションを起動、停止、監視するリソースです。

● 独自のリソースをスクラッチから作成する場合は、既定の仕様にしたがったリソース・スクリプトを用意します。

● 定義したサービスをフェイルオーバードメインに割り当てます。

● Resource Group Managerからサービスを開始すると、フェイルオーバ・ドメイン内のノードで、サービス内のリソースが起動します。

クラスタ設定ファイルの例

2 ノードの「鉄板構成例」です。

<?xml version="1.0"?><cluster config_version="12" name="cluster01"> <cman expected_votes="3" two_node="0"/> <clusternodes> <clusternode name="node01" nodeid="1" votes="1"> <fence>  </fence> </clusternode> <clusternode name="node02" nodeid="2" votes="1"> <fence>  </fence> </clusternode> </clusternodes> <totem token="20000"/> <quorumd interval="1" master_wins="1" tko="10" votes="1" label="qdisk01"/> <fencedevices>  </fencedevices> <rm> <failoverdomains> <failoverdomain name="dom01" ordered="1" restricted="1"> <failoverdomainnode name="node01" priority="1"/> <failoverdomainnode name="node02" priority="2"/> </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>

votes=1 votes=1

votes=1

サービス NW

管理 NW

qdisk

/etc/cluster/cluster.conf


運用上の注意点


クラスタの起動手順について (1)

クラスタを起動する際は、 cman 、 clvmd 、 gfs2 、 rgmanager の各サービス ( クラスタサービス ) をこの順番に起動します。

● 基本的には、クラスタに参加するノードで一斉にこれらのサービスを起動します。 SSH などを利用して、同時に自動起動するスクリプトを用意することをおすすめします。

rgmanager サービスが起動した段階で、クラスタ上で提供する「サービス」の操作が可能になります。

#!/bin/shservice cman startservice clvmd startservice gfs2 startservice rgmanager start

#!/bin/shservice rgmanager stopservice gfs2 stopservice clvmd stopservice cman stop

/usr/local/bin/clstart

/usr/local/bin/clstop

#!/bin/shssh node01 /usr/local/bin/clstart &ssh node02 /usr/local/bin/clstart &ssh node03 /usr/local/bin/clstart &wait

#!/bin/shssh node01 /usr/local/bin/clstop &ssh node02 /usr/local/bin/clstop &ssh node03 /usr/local/bin/clstop &wait

/usr/local/bin/clstart_all

/usr/local/bin/clstop_all

自ノードのサービスを起動・停止するスクリプトの例

全ノードのサービスを起動・停止するスクリプトの例

CLVM/GFS2 を使用する場合のみ必要

CLVM/GFS2 を使用する場合のみ必要


クラスタの起動手順について (2)

各ノードのクラスタサービスを１ノードずつ起動すると Quorum の機能に関連して次のような問題が発生します。（ここでは 3ノードの例で説明します。）

● 1 つ目のノードでサービスが起動した際に、 Quorum が満たされない場合、 cmanサービスの起動が完了せず、他のノードのサービスの起動待ちになります。

● 2 つ目のノードのサービスが起動した段階で Quorum が満たされると、 2 ノードでクラスタの起動が完了します。

● ただし、 3つ目のノードのサービスが起動していないため、起動済みのノードはスプリットブレインと判断して、 3つ目のノードを強制再起動します。

● 例えば、 3つ目のノードでサービスが起動しているにも関わらず一時的に応答不能で、その後、回復して共有リソースへのアクセスを行ってしまうなどの可能性があるため、これはクラスタの挙動としては正しい動作です。

● 3つ目のノードが強制再起動された後に、 3つ目のノードでサービスを起動すると、正常にクラスタに参加します。

この問題を避けるには、次のどちらかの運用方法が必要です。

● すべてのノードで必ず同時にクラスタサービスを起動する。

● Quorum に達する最低数のノードのみ OS を起動した状態で、クラスタサービスを順次起動して、その後、残りのノードについて OS の起動とクラスタサービスの起動を 1 ノードずつ繰り返す。


サービスの操作について

サービスの稼働状態は、 clustat コマンドで確認します。サービスの開始、停止、禁止、手動での引き継ぎなどは clusvcadm コマンドを使用します。

サービスの状態 (State) には次のような種類があります。

状態説明

started サービスは開始しています。

stopped サービスは停止しています。フェイルオーバ・ドメイン内のノードで rgmanagerサービスが再起動すると、再開します。

disabled サービスは禁止されており、自動的に開始することはありません。

recoverable サービスは異常停止しており、引き継ぎ処理が開始する予定です。

failed サービスは異常停止しており、引き継ぎ処理もできない状態です。問題の原因を取り除いて、一旦、手動で disabled 状態に変更する必要があります。

# clustat Cluster Status for cluster01 @ Tue Aug 2 19:10:44 2011Member 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


サービスの操作と問題判別に使用するコマンド

サービスの操作に使用する主なコマンドです

設定ファイルの問題判別に使用する主なコマンドです。

コマンド説明

# 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"> <failoverdomainnode name="node01" priority="1"/> <failoverdomainnode name="node02" priority="2"/> </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 デーモンによる強制再起動の後に、待機系でサービスが開始します。

No

Yes

稼動系の障害発生

Fence デーモンが強制再起動を実施

待機系でサービス開始稼動系でサービス停止

サービス回復成功？

稼動系でサービス回復を実施

サービス停止成功？

failed 状態started 状態

サービス開始成功？

Cluster Manager は通信可能？Yes

Yes

Yes

No

No

No

● アプリケーション障害

● 稼動系でアプリケーションの再起動が試みられた後、失敗した場合は、稼動系でサービスを停止した後に、待機系でサービスが開始します。

● ディスク障害

● ディスク使用リソースのアプリケーション障害として動作 (*1)。

● Quorum Diskを使用している場合は、稼働系が自発的に再起動して、待機系でサービスが開始します。

(*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 クラスタ設計支援サービス

監視スクリプト作成支援サービス

運用資料作成支援サービス

高度な専門知識を有するレッドハットのエンジニアが各フェーズの作業の技術支援をご提供いたします

安定した HA クラスタの実現には、設計段階での問題を排除することが最重要ポイントになります。まずは、要件定義・クラスタ設計段階での「 HA クラスタ設計支援サービス」のご利用をお勧めいたします。

お客様のご希望に応じて、後続のフェーズにおける 3 種類の支援サービスを追加でご提供させていただきます。


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

High Availability Add-On を利用した HA クラスタ構築サービスの提供に不可欠な技術スキルとノウハウを実案件を想定した形式でお伝えします。

本サービスのトレーニングを受講して、一定の要件をクリアされた SI事業者様にはトレーニング修了の認定証を発行いたします。

トレーニング期間とお見積もりについては、ご相談ください。

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

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

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 MOREWHEN WE WORK TOGETHER

THE OPEN SOURCE WAY

rhel6 high availability add-on technical guide

Technology