30分でRHEL6 High Availability Add-Onを超絶的に理解しよう!
Upcoming SlideShare
Loading in...5
×
 

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

on

  • 15,744 views

 

Statistics

Views

Total Views
15,744
Views on SlideShare
15,654
Embed Views
90

Actions

Likes
14
Downloads
277
Comments
0

7 Embeds 90

http://paper.li 61
http://yskwkzhr.blogspot.com 10
https://twitter.com 9
http://s.deeeki.com 5
http://twitter.com 3
http://a0.twimg.com 1
http://b.hatena.ne.jp 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

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

  • 第 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 クラスタ設計・構築支援サービスのご紹介 参考情報 Red Hat K.K. All rights reserved. 3
  • 基本情報Red Hat K.K. All rights reserved.
  • 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
  • サブスクリプション価格 レッドハット直販価格  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
  • アーキテクチャRed Hat K.K. All rights reserved.
  • 鉄板構成 特別な要件がない限りは、シンプルな 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
  • 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
  • 設定ファイル /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 デバイスを指定 --> </fence> </clusternode> <clusternode name="node02" nodeid="2" votes="1"> <fence> <!-- 適切な Fence デバイスを指定 --> </fence> </clusternode> </clusternodes> <totem token="20000"/> <quorumd interval="1" master_wins="1" tko="10" votes="1" label="qdisk01"/> <fencedevices> <!-- 適切な Fence デバイスを設定 --> </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
  • (参考) Quorum 計算とは? cman サービスは、ハードビートが切れたノードを発見すると管理ネットワーク経由で 強制再起動します。 ネットワーク障害でハートビートが切れた場合は、お互いに殺し合わないように「過半 数ルール」で生き残る島を決定します。 ● 1 ノードが 1Vote (投票数)を持ち、島全体の投票数が Quorum (過半数)に達すると生き 残る権利が得られます。 ノード障害でハートビートが切れると、 ネットワーク障害でハートビートが切れると、 障害ノードを強制再起動 ノード数が過半数の島が生き残る Votes=2 ハートビート・ネットワーク ハートビート・ネットワーク node01 node01 管理ネットワーク 管理ネットワーク node02 node02 node03 node03 Votes=1 強制再起動 強制再起動 Red Hat K.K. All rights reserved. 11
  • 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
  • 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
  • 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
  • デモンストレーション デモ環境の構築手順はこちらを参照 ● KVM で HA クラスタの機能検証環境を構築 http://bit.ly/qczRdX ● GlusterFS で HA クラスタ http://bit.ly/nRQNYY Red Hat K.K. All rights reserved. 15
  • HA クラスタ設計・構築支援サービスのご紹介 Red Hat K.K. All rights reserved.
  • High Availability Add-On 関連のサービス一覧 高度な専門知識を有するレッドハットのエンジニアが 各フェーズの作業の技術支援をご提供いたします 安定した HA クラスタの実現には、設計段階での問題を排除することが最重要ポイ ントになります。まずは、要件定義・クラスタ設計段階での「 HA クラスタ設計支援 サービス」のご利用をお勧めいたします。 お客様のご希望に応じて、後続のフェーズにおける 3 種類の支援サービスを追加 でご提供させていただきます。 HA クラスタ 監視スクリプト 構築支援サービス 作成支援サービス 要件定義 クラスタ設計 クラスタ構築 運用引き継ぎ HA クラスタ 運用資料作成 設計支援サービス 支援サービス Red Hat K.K. All rights reserved. 17
  • HA クラスタ構築ビジネス・スタートアップサービス HA クラスタ構築サービスの提供を検討される SI 事業者様に、レッドハットのエキスパートエンジニアが さまざまなノウハウをお伝えいたします High Availability Add-On を利用した HA クラスタ構築サービスの提供に不可欠な技 術スキルとノウハウを実案件を想定した形式でお伝えします。 本サービスのトレーニングを受講して、一定の要件をクリアされた SI 事業者様には トレーニング修了の認定証を発行いたします。 トレーニング期間とお見積もりについては、ご相談ください。 すべてのフェーズのノウハウを伝授 要件定義 クラスタ設計 クラスタ構築 運用引き継ぎ Red Hat K.K. All rights reserved. 18
  • 参考情報Red Hat K.K. All rights reserved.
  • 設計時に注意が必要な場合 特に次のような環境で使用する際は、環境に応じたパラメータのチューニング が必要な場合があります (*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
  • HA クラスタ設計時の心構え シンプルなアクティブ・スタンバイ構成がベストです。 ● HA クラスタは障害発生中の環境下で機能するため、障害の副作用を受けない ように、できるかぎり構成をシンプルにします。 ● 特別な要件がない限りは、 2 ノード + Quorum Disk によるアクティブ・スタンバイ 構成をおすすめします。 対応するべき障害の範囲を明確にします。 ● HA クラスタはあらゆる障害に対応する魔法のソフトウェアではありません。特 に、 2 重障害の発生には対応できない場合が多数あります。 ● HA クラスタで保護したい障害内容を洗い出しておき、各障害パターンに対する 障害テストを確実に実施してください。 運用を意識した設計を行います。 ● HA クラスタは複数のノードが密に連携するため、常にそれぞれのノードの状況を みながら操作を行う必要があります。 ● 運用手順が複雑になる設計は避けた上で、運用手順書の整備を怠らないように してください。 Red Hat K.K. All rights reserved. 21
  • 参考資料 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
  • WE CAN DO MOREWHEN WE WORK TOGETHERTHE OPEN SOURCE WAY Red Hat K.K. All rights reserved.