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

2. 自己紹介  中井悦司（なかいえつじ） ● Twitter @enakai00  日々の仕事 ● Senior Solution Architect and Cloud Evangelist at Red Hat K.K. 企業システムでオープンソースの活用を希望される好評発売中お客様を全力でご支援させていただきます。  昔とった杵柄 ● 素粒子論の研究（超弦理論とか） ● 予備校講師（物理担当） ● インフラエンジニア（ Unix/Linux 専門） Red Hat K.K. All rights reserved. 2

5. 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 のサブスクリプションは不要です。 Red Hat K.K. All rights reserved. 5

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

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

9. High Availability Add-On を構成するサービス  Cluster Manager (cman サービス）内部的には corosync を使用しています。 ● ハートビートでノードの死活監視 ● 怪しいノードは、 Fence デーモンがネットワーク経由で強制再起動 ● ハートビート・ネットワーク障害時は、 Quorum 計算、もしくは Quorum Disk で生き残るノードを決定する。（後ほど詳しく説明）  Resource Group Manager (rgmanager サービス ) ● 事前定義されたサービスリソースの起動・停止と稼働監視 ● ノード障害 or リソース障害の際は、新たなノードでサービスを再起動 rgmanager サービス cman サービス fence デーモン qdisk デーモン corosync Red Hat K.K. All rights reserved. 9

10. 設定ファイル  /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> Red Hat K.K. All rights reserved. 10

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

12. 2 ノードクラスタの「相撃ち問題」  2 ノード構成では、ハートビート・ネットワークが切れるとどちらのノードも過半数にならないので、 Quorum の仕組みが利用できません。  （ Quorum Disk を使わない場合は） Quorum を無視して稼働を継続するオプションを指定します。 <cman expected_votes="1" two_node="1"/> ● 1 ノードだけでもサービスの継続が許可されます。 ● ハートビート・ネットワークが切れると、お互いに相手ノードの強制再起動を試みます。「早い者勝ち」で生き残ったノードがサービスを継続します。  問題点ハートビート・ネットワーク管理ネットワーク ● タイミングによっては、両方のノードが再起動して node01 サービスが停止する可能性があります。 ● ( 推奨される構成ではありませんが ) サービスネットワークとハートビート・ネットワークを兼用している node02 場合、 NIC 障害でハートビートが切れた際に、 NIC 障害ノードが生き残る可能性があります。相互に強制再起動（どちらが生き残るかは不定） Red Hat K.K. All rights reserved. 12

13. 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 疎通を確認するなど。） Red Hat K.K. All rights reserved. 13

14. 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 Red Hat K.K. All rights reserved. 14

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

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

20. 設計時に注意が必要な場合  特に次のような環境で使用する際は、環境に応じたパラメータのチューニングが必要な場合があります (*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 を利用する際は、レッドハットのコンサルテーションサービスのご利用をおすすめします。 Red Hat K.K. All rights reserved. 20

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

22. 参考資料  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 Red Hat K.K. All rights reserved. 22

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

You are reading a preview.

Check these out next

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

More Related Content

Slideshows for you (20)

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

More from Etsuji Nakai (20)

Recently uploaded (20)