30分でRHEL6 High Availability Add-Onを超絶的に理解しよう!

第 4 回 Linux-HA 勉強会

30 分で
RHEL6 High Availability Add-On を
超絶的に理解しよう！

V1.3 2011.10.2
中井悦司 / Etsuji Nakai
Senior Solution Architect
and Cloud Evangelist
Red Hat K.K.

Red Hat K.K. All rights reserved.

自己紹介


中井悦司（なかいえつじ）
●
Twitter @enakai00


日々の仕事
●
Senior Solution Architect and
Cloud Evangelist at Red Hat K.K.
企業システムでオープンソースの活用を希望される好評発売中

お客様を全力でご支援させていただきます。


昔とった杵柄
●
素粒子論の研究（超弦理論とか）
●
予備校講師（物理担当）
●
インフラエンジニア（ Unix/Linux 専門）

Red Hat K.K. All rights reserved. 2

目次

基本情報

アーキテクチャ
 HA クラスタ設計・構築支援サービスのご紹介
 参考情報


基本情報


RHEL6 のクラスタ関連 Add-On 一覧

いわゆる HA クラスタが必要な方は、
HA Add-On を選択

各 Add-On に含まれる機能
HA クラスタクラスタ LVM 共有ファイルロードバランサ
システム
High Availability
Add-On ○ × × ×
Resilient Storage
Add-On(*1) ○ ○ ○ ×
Load Balancer
Add-On × × × ○

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


サブスクリプション価格

レッドハット直販価格　 http://red.ht/oyPbq1


クラスタの 1 ノードにつき 1 サブスクリプションご購入ください。
●
RHEL 本体のサブスクリプションは別途必要です。

監視スクリプトの別販売はありません。
●
標準で含まれないものについては、スクリプトを自作して対応します。
→ /etc/init.d/ 以下に置くサービススクリプト (start/stop/status オプションを
受け付けるもの）を作成します。
●
OCF (Open Cluster Framework) 形式のリソーススクリプトも利用可能です。


アーキテクチャ


鉄板構成

特別な要件がない限りは、シンプルな 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 程度 ) データ領域


High Availability Add-On を構成するサービス

Cluster Manager (cman サービス）内部的には corosync を
使用しています。
●
ハートビートでノードの死活監視
●
怪しいノードは、 Fence デーモンがネットワーク経由で強制再起動
●
ハートビート・ネットワーク障害時は、 Quorum 計算、もしくは Quorum Disk で生き
残るノードを決定する。（後ほど詳しく説明）

 Resource Group Manager (rgmanager サービス )
●
事前定義されたサービスリソースの起動・停止と稼働監視
●
ノード障害 or リソース障害の際は、新たなノードでサービスを再起動
rgmanager サービス

cman サービス

fence デーモン qdisk デーモン

corosync


設定ファイル

/etc/cluster/cluster.conf に全てを記載します。
<?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="0" 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" self_fence="1">
<script file="/etc/init.d/myappl" name="myappl"/>
</fs>
</service>
</rm>
</cluster>

（参考） Quorum 計算とは？

cman サービスは、ハードビートが切れたノードを発見すると管理ネットワーク経由で
強制再起動します。
 ネットワーク障害でハートビートが切れた場合は、お互いに殺し合わないように「過半
数ルール」で生き残る島を決定します。
●
1 ノードが 1Vote （投票数）を持ち、島全体の投票数が Quorum （過半数）に達すると生き
残る権利が得られます。

ノード障害でハートビートが切れると、ネットワーク障害でハートビートが切れると、
障害ノードを強制再起動ノード数が過半数の島が生き残る

Votes=2

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

node01
node01


node02
node02

node03
node03
Votes=1 強制再起動
強制再起動

2 ノードクラスタの「相撃ち問題」

2 ノード構成では、ハートビート・ネットワークが切れるとどちらのノードも過半
数にならないので、 Quorum の仕組みが利用できません。

（ Quorum Disk を使わない場合は） Quorum を無視して稼働を継続するオプ
ションを指定します。
<cman expected_votes="1" two_node="1"/>

●
1 ノードだけでもサービスの継続が許可されます。
● ハートビート・ネットワークが切れると、お互いに相手ノードの強制再起動を試み
ます。「早い者勝ち」で生き残ったノードがサービスを継続します。


問題点


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


Quorum Disk による「相撃ち問題」の回避
Votes=2


Quorum Disk に 1Vote を与えて、クラスタ全体 node01

の Vote 合計を 3 にします。
<cman expected_votes="3" two_node="0"/> Quorum
Disk
●
Quorum Disk の Vote が追加されるので、 1
ノードでも Quorum が満たされます。 node02
●
ハートビート・ネットワーク切断時に生き残る
ノードを決める方法は 2 種類から選択します。 Votes=2
●
master_wins もしくは Heuristic
で自発的に再起動

master_wins オプションを使用する場合
<quorumd interval="1" label="qdisk01" master_wins="1" tko="10" votes="1"/>
●
Quorum Disk を通して内部的に決定されるマスタノードが生き残ります。


Heuristic を使用する場合
<quorumd interval="1" label="qdisk01" tko="10" votes="1">
<heuristic interval="2" program="/usr/local/bin/pingcheck.sh" score="1" tko="3"/>
</quorumd>
●
ユーザが作成したシェルでヘルスチェックを行って、チェックに失敗したノードが自
爆します。（サービスネットワークとハートビート・ネットワークを兼用する構成で、
ゲートウェイへの ping 疎通を確認するなど。）

Resource Group Manager の設定方法

サービスの引き継ぎ範囲を示す「フェイルオーバ・ドメイン」を定義します。
●
2 : 1 の引き継ぎ構成などは、複数のフェイルオーバ・ドメインを定義します。

クラスタ
リソースの定義は /usr/share/cluster/ 以下の OCF スクリプト
各リソースの詳細は、 meta-data オプションで確認できますフェイルオーバ・ドメイン

node01 node02 node03

任意のリソースを含む「サービス」を定義します。
●
リソースの種類には、事前準備された「 IP Address 」
割り当て
「 File System 」「 PostgreSQL 8 」などがあります (*1) 。
●
リソースの親子関係を設定すると、親から先に起動しサービス
ます。
IP Address
リソース起動順序

サービスをフェイスオーバ・ドメインに割り当てます。
File System

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

デモンストレーション

デモ環境の構築手順はこちらを参照
● KVM で HA クラスタの機能検証環境を構築 http://bit.ly/qczRdX
● GlusterFS で HA クラスタ http://bit.ly/nRQNYY


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


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

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

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

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

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

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

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

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


参考情報


設計時に注意が必要な場合

特に次のような環境で使用する際は、環境に応じたパラメータのチューニング
が必要な場合があります (*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 クラスタは複数のノードが密に連携するため、常にそれぞれのノードの状況を
みながら操作を行う必要があります。
●
運用手順が複雑になる設計は避けた上で、運用手順書の整備を怠らないように
してください。


参考資料

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://sites.google.com/site/haaddon/
まずはこの 2 つがお勧め

High Availability Add-On 設計・運用入門
●
http://www.slideshare.net/enakai/rhel6-rhcs-guidepreview-8758112


KVM で HA クラスタの機能検証環境を構築
●
http://d.hatena.ne.jp/enakai00/20110804/1312437111


WE CAN DO MORE
WHEN WE WORK TOGETHER

THE OPEN SOURCE WAY


30分でRHEL6 High Availability Add-Onを超絶的に理解しよう!

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a 30分でRHEL6 High Availability Add-Onを超絶的に理解しよう!

Similar a 30分でRHEL6 High Availability Add-Onを超絶的に理解しよう! (20)

Más de Etsuji Nakai

Más de Etsuji Nakai (20)

Último

Último (9)

30分でRHEL6 High Availability Add-Onを超絶的に理解しよう!