30分でrhel6 high availability add-onを超絶的に理解しよう!

Red Hat K.K. All rights reserved.

第 4 回 Linux-HA 勉強会

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

V1.3 2011.10.2中井悦司 / Etsuji Nakai

Senior Solution Architectand Cloud Evangelist

Red Hat K.K.

Red Hat K.K. All rights reserved. 2

自己紹介

好評発売中

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

日々の仕事

● Senior Solution Architect and

Cloud Evangelist at Red Hat K.K.

企業システムでオープンソースの活用を希望される

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

昔とった杵柄

● 素粒子論の研究（超弦理論とか）

● 予備校講師（物理担当）

● インフラエンジニア（ Unix/Linux 専門）


目次

基本情報

アーキテクチャ

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

参考情報


基本情報


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

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

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

ロードバランサ

High AvailabilityAdd-On ○ × × ×

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

Load BalancerAdd-On × × × ○

各 Add-On に含まれる機能

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


サブスクリプション価格

レッドハット直販価格　 http://red.ht/oyPbq1

クラスタの 1 ノードにつき 1 サブスクリプションご購入ください。

● RHEL 本体のサブスクリプションは別途必要です。

監視スクリプトの別販売はありません。

● 標準で含まれないものについては、スクリプトを自作して対応します。

→ /etc/init.d/ 以下に置くサービススクリプト (start/stop/status オプションを受け付けるもの）を作成します。

● OCF (Open Cluster Framework) 形式のリソーススクリプトも利用可能です。


アーキテクチャ


鉄板構成

特別な要件がない限りは、シンプルな 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


High Availability Add-On を構成するサービス

Cluster Manager (cman サービス）

● ハートビートでノードの死活監視

● 怪しいノードは、 Fence デーモンがネットワーク経由で強制再起動

● ハートビート・ネットワーク障害時は、 Quorum 計算、もしくは Quorum Disk で生き残るノードを決定する。（後ほど詳しく説明）

Resource Group Manager (rgmanager サービス )

● 事前定義されたサービスリソースの起動・停止と稼働監視

● ノード障害 or リソース障害の際は、新たなノードでサービスを再起動

qdisk デーモンfence デーモン

cman サービス

内部的には corosync を使用しています。

corosync

rgmanager サービス

設定ファイル

<?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>

/etc/cluster/cluster.conf に全てを記載します。


管理

ネッ

トワ

ーク

強制再起動

（参考） Quorum 計算とは？

cman サービスは、ハードビートが切れたノードを発見すると管理ネットワーク経由で強制再起動します。

ネットワーク障害でハートビートが切れた場合は、お互いに殺し合わないように「過半数ルール」で生き残る島を決定します。

● 1 ノードが 1Vote （投票数）を持ち、島全体の投票数が Quorum （過半数）に達すると生き残る権利が得られます。

node01

node02

node03

ハー

トビ

ート

・ネ

ット

ワー

ク

管理

ネッ

トワ

ーク

強制再起動

node01

node02

node03

Votes=2

Votes=1

ハー

トビ

ート

・ネ

ット

ワー

ク

ノード障害でハートビートが切れると、障害ノードを強制再起動

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


2 ノードクラスタの「相撃ち問題」

2 ノード構成では、ハートビート・ネットワークが切れるとどちらのノードも過半数にならないので、 Quorum の仕組みが利用できません。

（ Quorum Disk を使わない場合は） Quorum を無視して稼働を継続するオプションを指定します。

● 1 ノードだけでもサービスの継続が許可されます。

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

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

問題点

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

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

ハー

トビ

ート

・ネ

ット

ワー

ク

管理

ネッ

トワ

ーク

node01

node02

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


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

Quorum Disk に 1Vote を与えて、クラスタ全体の Vote 合計を 3 にします。

● Quorum Disk の Vote が追加されるので、 1ノードでも Quorum が満たされます。

● ハートビート・ネットワーク切断時に生き残るノードを決める方法は 2 種類から選択します。

●

master_wins オプションを使用する場合

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

管理

ネッ

トワ

ークnode01

node02

master_wins もしくは Heuristicで自発的に再起動

Quorum Disk

Votes=2

Votes=2

ハー

トビ

ート

・ネ

ット

ワー

ク

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

● Quorum Disk を通して内部的に決定されるマスタノードが生き残ります。

Heuristic を使用する場合

● ユーザが作成したシェルでヘルスチェックを行って、チェックに失敗したノードが自爆します。（サービスネットワークとハートビート・ネットワークを兼用する構成で、ゲートウェイへの ping疎通を確認するなど。）


Resource Group Manager の設定方法

サービスの引き継ぎ範囲を示す「フェイルオーバ・ドメイン」を定義します。

● 2 : 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

リソース起動順序

サービス

割り当て

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

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

● リソースの親子関係を設定すると、親から先に起動します。

サービスをフェイスオーバ・ドメインに割り当てます。

リソースの定義は /usr/share/cluster/ 以下の OCF スクリプト各リソースの詳細は、 meta-data オプションで確認できます


デモンストレーション

デモ環境の構築手順はこちらを参照

● KVMで HA クラスタの機能検証環境を構築 http://bit.ly/qczRdX

● GlusterFSで HA クラスタ http://bit.ly/nRQNYY


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


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

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

HA クラスタ構築支援サービス

HA クラスタ設計支援サービス

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

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

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

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

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


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

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

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

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

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

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

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/

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

● http://www.slideshare.net/enakai/rhel6-rhcs-guidepreview-8758112

KVMで HA クラスタの機能検証環境を構築

● http://d.hatena.ne.jp/enakai00/20110804/1312437111

まずはこの 2 つがお勧めまずはこの 2 つがお勧め


WE CAN DO MOREWHEN WE WORK TOGETHER

THE OPEN SOURCE WAY

30分でrhel6 high availability add-onを超絶的に理解しよう!

Technology