LifeKeeper for LinuxとRHEVとV7000連携

Transcription

1 文書番号 : OSSTS LifeKeeper による Linux KVM 環境 HA システム構築ガイド 第 1 版 サイオステクノロジー株式会社

2 目次 1 本ドキュメントの目的 仮想環境におけるシステムの保護 I/O フェンシング Quorum / Witness Server 方式の概要 RHEV の概要 構成方法 構成の前提 SCSI Reservation の無効化 Virtual STONITH の設定 Quorum / Witness Server Kit の設定 障害発生時の動作 お問い合わせ 免責事項 改版履歴 2012 年 11 月 2 日第 1 版 2

3 LifeKeeper による Linux KVM 環境 HA システム構築手順 1 本ドキュメントの目的 本ドキュメントは IBM Storwize V7000 ストレージを使用した Linux KVM 上の仮想ゲスト OS 上で LifeKeeper for Linux による HA システムを構築するためのガ ドです このガ ド で扱う構成は 日本 IBM 株式会社とサ オステクノロジー株式会社(以下弊社)とで協同で検証 を実施しております なお 仮想環境の管理として RHEV を使用しています また IBM Storwize V7000 ストレージの IO フェンシング機能として Quorum/Witness Server 方式を採用して います LifeKeeper で IBM Storwize V7000 を共有ストレージとして利用した 仮想ゲスト OS の HA システムを構築する手法について 各機能の解説を交えながらご説明します 2 仮想環境におけるシステムの保護 仮想環境においてシステムを保護する場合 仮想化プラットフォームが提供する保護範囲を認識 したうえで サービス ゕプリケーション 障害時の対応を考える必要があります このサービス障害時のシステム保護を可能にするのが LifeKeeper です 3

4 LifeKeeper による Linux KVM 環境 HA システム構築手順 3 I/O フェンシング I/O フェンシングは 共有データに対する入力に制限を設けることで 特定のノードからのみゕ クセス可能とする技術の総称です HA クラスタでは 複数のノードが物理的に同じデータを参照します これらのノードが同時に 同じデータに書き込みを行った場合 データの不整合が生じ データは破壊されます これはサ ービスの停止以上に重大な問題です このような状態を防ぐための仕組みが I/O フェンシングであり LifeKeeper では以下の種類の I/O フェンシング機能を提供しており システム環境に応じた適用が可能となっています 4

5 KVM 環境における I/O フェンシング適用の可否を以下に示します 4 Quorum / Witness Server 方式の概要 本項では 本検証の構成に適用した Quorum/Witness Server 方式について説明します Quorum/Witness Server 方式は ノード障害を検知した際のフェルオーバ先を多数決により決定する Quorum Check と 第三者サーバに問い合わせて 相手ノードの死活状態を再確認する Witness Check 機能によって構成されます この機能を利用するには LifeKeeper v7.3 以降で追加された Quorum/Witness Server Kit パッケージ (steeleye-lkqwk) をンストールする必要があります なお パッケージは Recovery Kit として製品メデゖゕに同梱されています Quorum Check のモードについて Quorum Check は ノードの監視機能として TCP_remote 方式と Majority 方式の 2 つのモードが用意されています TCP_remote 方式 Quorum Host に指定したホストのうち過半数に接続できるかどうかで 自ノードが多数派かどうかをチェックします 5

6 Majority 方式 Witness Server と呼ばれる役割を持つ第三のノードをクラスタに参加させることに よって 多数決を実現します どちらのモードを選択するかによって HA システムの構成が異なります 今回の検証では TCP_remote 方式で検証を実施いたしました TCP_remote 方式と Majority 方式の詳細については 下記のドキュメントを参照してください Quorum/Witness ncing/quorum_witness.htm STONITH の概要 STONITH は "Shoot The Other Node In The Head" の略語であり 他ノードの電源を強制的に遮断する動作を指します LifeKeeper においては v7.3 から STONITH がサポートされ 更に LifeKeeper v7.5 からは Virtual STONITH がサポートされました Virtual STONITH は 仮想環境上の各ゲスト OS に対して 電源を強制的に遮断する仕組みです 現在 VMware vsphere 上の仮想マシンのみが標準的にサポートされておりますが KVM (Kernel-based Virtual Machine) の仮想環境においても この仕組みを利用した電源操作が可能です この機能があることで ハートビート切断障害発生時のフェルオーバにおいてにフェルオーバ元ノード ( 仮想マシン ) の電源を強制的に遮断することが可能となり スプリットブレンの発生を確実に抑止出来ることを確認いたしました 6

7 上述の Quorum/Witness Server Kit では 障害ノードが自発的に電源断を行い スプリットブレンを回避します しかし カーネルのハングゕップなど 障害ノードが完全に応答を停止してしまった場合は OS による自発的な電源断は期待できません そのような場合においても Virtual STONITH を利用することで 仮想サーバーでも物理サーバー同様外部から強制的に電源を遮断した状態にすることができます この機能を使用することで スプリットブレンが発生する可能性を排除します 5 RHEV の概要 RHEV (Red Hat Enterprise Virtualization) 3.0 は レッドハット株式会社が提供している Linux カーネルに組み込まれたハパーバザー KVM(Kernel-based Virtual Machine) をベースとする仮想化製品です 本構成では RHEV-M(Red Hat Enterprise Virtualization Manager ) を使用して各 KVM のゲスト OS を管理しております RHEV 及び RHEV-M の詳細については 下記の URL を参照してください 7

8 6 構成方法 本構成では IBM Storwize V7000 ストレージを使用した Linux KVM 上の仮想ゲスト OS 上で LifeKeeper for Linux による PostgreSQL サーバの HA システムを環境を構築いたし ます 本項では 以下のような 2 ノード構成の Active/Standby クラスタを構築します KVM ホストサーバ KVM ホスト OS (KVM01,KVM02) KVM ゲスト OS (LK01,LK02) 管理 (RHEV) サーバ管理 (RHEV) OS (RHEV-M) IBM System x3690 X5 Red Hat Enterprise Linux 6.2 (x86_64) Red Hat Enterprise Linux 6.2 (x86_64) IBM System x3250 M4 Red Hat Enterprise Linux 6.2 (x86_64) RHEV Red Hat Enterprise Virtualization 3.0 LifeKeeper v7.5 共有ストレージ マルチパスドラバ IBM Storwize V7000(Software V6.3.0) device-mapper multipath PostgreSQL

9 LifeKeeper による Linux KVM 環境 HA システム構築手順 各サーバと IBM Storwize V7000 の間は FC ケーブルで以下のように結線しています マル チパス接続 各 KVM のゲスト OS と IBM Storwize V7000 の間は LAN ケーブルで以下のように結線して います 9

10 この環境で Quorum/Witness Server Kit および RHEV および KVM STONITH の設定を行い IBM Storwize V7000 を共有ストレージとして用いたクラスタを構成します なお 稼動系ノードを SIOS_Primary 待機系ノード名を SIOS_Standby として以降説明を行います また 上記の構成では Communication Path に使用しているネットワークスッチが 1 つとなっているため このスッチが SPOF( 単一障害点 ) となっています 実際の環境では それぞれの Communication Path 用に独立した経路をご用意ください 6.1 構成の前提 各ノード ( 各仮想 OS) に Red Hat Enterprise Linux 6.2 がンストールされている各ノード ( 各仮想 OS) に LifeKeeper v7.5 および DMMP ARK がンストールされている各ノード ( 各仮想 OS) に Quorum/Witness Server Kit がンストールされている各ノード ( 各仮想 OS) から iscsi 接続による IBM Storwize V7000 上の LU にゕクセス可能な状態である REHV-M から各ノード ( 各仮想 OS) の登録 管理が可能各ノード ( 各仮想 OS) から PostgreSQL がンストールされており 起動することができる 10

11 6.2 SCSI Reservation の無効化 各ノードの LifeKeeper 設定フゔル /etc/default/lifekeeper に以下のパラメータを追記し SCSI Reservation によるストレージ制御を無効にします RESERVATIONS=none この変更を有効にするために LifeKeeper を再起動してください # /opt/lifekeeper/bin/lkstop # /opt/lifekeeper/bin/lkstart 6.3 Virtual STONITH の設定 (1) ゲスト OS から RHEV-M へ接続するための証明書を取得します コマンド実行例 # curl -O rhevm.cer RHEV-M から証明書の取得方法については 以下を参照してください 3.0/html/REST_API_Guide/chap-REST_API_Guide-Authentication.html (2) RHEV-M へ接続し 仮想マシンの一覧から構成する各仮想マシン ID を取得します コマンド実行例 #curl -X GET -H "Accept: application/xml" -u [USER:PASS] --cacert [CERT] Host]:8443/api/vms 仮想マシン一覧表示については 以下を参照してください /REST_API_Guide/appe-REST_API_Guide-cURL_Integration.html 11

12 (3) RHEV-M の REST API を利用し シェルコマンドでお互いにノードの電源断を行えるこ とを確認します コマンド実行例 #curl -X POST H "Accept:application/xml" H "Content-type:application/xml" -u [USER:PASS]ad cacert[cert] -d "<action/>" Host]:8443/api/vms/[ 仮想マシン ID]/stop (4) stonith-install スクリプトを実行し LifeKeeper が各ノードに対して STONITH を実 行するための仕組みをンストールします # /opt/lifekeeper/samples/stonith/stonith-install (5) stonith.conf に 各ノードの電源断を実行する STONITH コマンドを記述します 各ノードからのフェルオーバ処理を実施する前に ここに記述した STONITH コマンドが実行されます フェイルオーバ元のノード名と そのノードに対して実行する STONITH コマンドをスペースで区切って記述します 今回の例では SIOS_Primary の stonith.conf には SIOS_Standby の電源断を実行す るコマンド SIOS_Standby の stonith.conf には SIOS_Primary の電源断を実行する コマンドをそれぞれ記述します # vi /opt/lifekeeper/config/stonith.conf 記述例 (SIOS_Primary の stonith.conf) SIOS_Standby curl -X POST -H "Accept: application/xml" -H "Content-type:application/xml" -u admin@internal:password --cacert /root/rhevm.cer -d "<action/>" ebf0/stop (SIOS_Standby の stonith.conf) SIOS_Primary curl -X POST -H "Accept: application/xml" -H "Content-type:application/xml" -u admin@internal:password --cacert /root/rhevm.cer -d "<action/>" cd956/stop 電源断の替わりに再起動するようコマンドを記述することもできます しかし 再起動後にハート ビート通信が復旧していない場合には 再起動したノードが STONITH を発動してしまい ピンポン 状態となる可能性があります そのため コマンドは電源断とすることを推奨します 12

13 6.4 Quorum / Witness Server Kit の設定 KVM ゲスト OS の 2 ノード構成を維持し TCP_Remote モードを 設定する 以下のようなネットワーク構成で RHEV-M を Quorum Host として指定します この構成のポントは コミュニケーションパスに使う経路が Quorum Host へのゕクセス経路と重なっていることです このことにより ネットワーク障害発生時に障害ノードから Quorum Host へのゕクセス経路が失われますので 両ノードが同時に多数派となってしまうことを回避できます 13

14 コミュニケーションパスの作成 各ノード間で コミュニケーションパスを作成します コミュニケーションパスの少なく とも一つが Quorum Host へのネットワーク経路と重なるよう考慮します SIOS_Primary と SIOS_Standby の間に ネットワークを利用したコミュニケーションパスを作成します ( Quorum Host への共通の経路です ) パラメータの設定 /etc/default/lifekeeper を編集し パラメータを以下のように設定します 原則的に この 設定は全てのノードで共通にしてください # vi /etc/default/lifekeeper QUORUM_MODE=tcp_remote WITNESS_MODE=none QUORUM_HOSTS=rhev.com:80 QUORUM_TIMEOUT_SECS=20 QUORUM_LOSS_ACTION=fastkill # Quorum Check のモード # Witness Check を行わない # 問合せ先ホスト : ポート # 問合せのタムゕウト # 少数派ノードの電源断動作 リソースの作成 (1) ファイルシステムリソースの作成 A) ファイルシステムのマウント 稼働系ノードである SIOS_Primary ノードで IBM Storwize V7000 の共有データ領域 から PostgreSQL のデータ領域に使用するフゔルシステムを作成し 任意のデゖレクト リにマウントします # fdisk /dev/mapper/mpath1 # mkfs.ext3 /dev/mapper/mpath1p1 # mount /dev/mapper/mpath1p1 /u01/ 14

15 B) ファイルシステムリソースの作成 LifeKeeper GUI 管理画面を起動します # /opt/lifekeeper/bin/lkguiapp > /dev/null 2>&1 & その後 管理ガドの手順に従って マウントした領域をフゔルシステムリソースとして保護します 管理ガドは以下のリンクより参照することができます Creating a File System Resource Hierarchy - SIOS Technology Corp Wiki (2) PostgreSQL リソースの作成両ノードで フゔルシステムリソースの共有領域に PostgreSQL のデータ領域に設定し PostgreSQL リソースを作成して下さい PostgreSQL リソースの作成方法の詳細は 下記の PostgreSQL の管理者ガドをご参照下さい PostgreSQL Recovery Kit v7.4 管理ガド 74_jp.pdf IP リソースなどの各リソースが必要な場合は 必要に応じて作成して下さい 6.5 障害発生時の動作 (1) ハートビート通信途絶時の動作 A) SIOS_Primary のネットワーク機能が異常停止した場合 ハートビート通信が途絶するシチュエーションはいくつか考えられますが ここでは SIOS_Primary にノード障害が発生し ネットワーク機能に問題が生じた場合を想定します SIOS_Primary は Quorum Host である RHEV-M への接続を試行します しかし ネットワーク機能に障害が発生しており通信が行えません そのため自ノードが少数派であると判断し 自発的な電源断を行います SIOS_Standby は ネットワークを経由して Quorum Host である RHEV-M への接続が可能です そのため 自ノードが多数派であると判断し サービスの起動を行います SIOS_Primary は電源断 SIOS_Standby がリソース起動 15

16 B) コミュニケーションパスのネットワークに障害発生した場合 ネットワークのすべてに障害が発生して ハートビート通信が途絶したケースです SIOS_Primary と SIOS_Standby はどちらも Quorum Host である RHEV-M への接続が行えません したがって両ノードとも少数派となります リソースが稼働している SIOS_Primary は自発的な電源断を行い リソースが稼働していない SIOS_Standby は リソースの起動は行いません SIOS_Primary が電源断 SIOS_Standby はリソースは 起動しない (2) Virtual STONITH による電源断が必要となるシチュエーション A) SIOS_Primary が完全に応答停止状態となった場合 SIOS_Primary の OS が完全に応答停止してしまったケースです この場合 Quorum Check による SIOS_Primary の自発的な電源断は期待できません SIOS_Standby は Quorum Check の結果多数派となり フェルオーバ処理を開始します フェルオーバ処理の開始前に Virtual STONITH が発動して SIOS_Primary の電源を強制的に遮断します そのため スプリットブレンが発生することなく リソースのフェルオーバを実施することができます SIOS_Primary は電源断 SIOS_Standby がリソース起動 B) ハートビート断にも関わらず両ノードが Quorum Host と通信できる場合今回の構成ではこのような事象は発生しませんが ハートビート通信の途絶時に両ノードとも Quorum Host と通信可能な状態であると 両ノードが多数派となり リソースの起動処理を開始してしまいます このような場合には 先にハートビートの途絶を検知し フェルオーバ処理を開始したノードが Virtual STONITH を発動することで 相手ノードの電源を遮断してスプリットブレンを回避します SIOS_Primary のリソースが起動した場合は SIOS_Standby が電源断または SIOS_Standby のリソースが起動した場合は SIOS_Primary が電源断 16

17 (3) リソース障害発生時の動作 A) SIOS_Primary の PostgreSQL リソースが障害発生時の場合 SIOS_Primary の PostgreSQL リソースのリカバリ処理に失敗した場合は PostgreSQL リソースが SIOS_Standby へフェールオーバを開始します SIOS_Primary の PostgreSQL リソースは停止 SIOS_Standby の PostgreSQL リソースが起動 上記の障害発生時 PostgreSQL リソースと依存関係があるリソースも SIOS_Primary で停止し SIOS_Standby で起動します 17

18 7 お問い合わせ 本ドキュメントの記載内容についてのお問い合わせ先 LifeKeeper 製品の導入を検討中のお客様 弊社パートナー営業部までお問い合わせください TEL: ( 受付時間 9:00~17:00 土日祝祭日および弊社休業日は除く ) お問い合わせメールフォーム LifeKeeper 製品をご購入済みのお客様 弊社 LifeKeeper 製品サポート窓口までお問い合わせください 購入後のお問い合わせ 8 免責事項 本書に記載された情報は予告なしに変更 削除される場合があります 最新のものをご確認 ください 本書に記載された情報は 全て慎重に作成され 記載されていますが 本書をもって その 妥当性や正確性についていかなる種類の保証もするものではありません 本書に含まれた誤りに起因して 本書の利用者に生じた損害については サオステクノロ ジー株式会社は一切の責任を負うものではありません 第三者による本書の記載事項の変更 削除 ホームページ及び本書等に対する不正なゕクセ ス その他第三者の行為により本書の利用者に生じた一切の損害について サオステクノ ロジー株式会社は一切の責任を負うものではありません 18

19 システム障害などの原因によりメールフォームからのお問い合せが届かず または延着する 場合がありますので あらかじめご了承ください お問い合せの不着及び延着に関し サ オステクノロジー株式会社は一切の責任を負うものではありません 著作権 本書に記載されているコンテンツ ( 情報 資料 画像等種類を問わず ) に関する知的財産権は サオステクノロジー株式会社に帰属します その全部 一部を問わず サオステクノロジー株式会社の許可なく本書を複製 転用 転載 引用 公衆への送信 販売 翻案その他の二次利用をすることはいずれも禁止されます またコンテンツの改変 削除についても一切認められません 本書では 製品名 ロゴなど 他社が保有する商標もしくは登録商標を使用しています サオステクノロジー株式会社 東京都港区虎ノ門 虎ノ門タワーズ 電話 : FAX: