LifeKeeper による Linux KVM - sios.jp · 6.2 SCSI Reservationの無効化 ... RHEV (Red Hat Enterprise Virtualization) 3.0 ... RESERVATIONS=none

文書番号: OSSTS20120618-009-002

サイオステクノロジー株式会社

LifeKeeper による Linux KVM 環境

HA システム構築ガイド

第１版

LifeKeeper による Linux KVM環境HAシステム構築手順

2

©2012 SIOS Technology, Inc.

目次

1 本ドキュメントの目的 ............................................................................................................ 3

2 仮想環境におけるシステムの保護 .......................................................................................... 3

3 I/O フェンシング .................................................................................................................. 4

4 Quorum / Witness Server 方式の概要 ......................................................................... 5

5 RHEV の概要 ......................................................................................................................... 7

6 構成方法 .................................................................................................................................. 8

6.1 構成の前提 ..................................................................................................................... 10

6.2 SCSI Reservation の無効化 .................................................................................... 11

6.3 Virtual STONITH の設定 .......................................................................................... 11

6.4 Quorum / Witness Server Kit の設定 ............................................................... 13

6.5 障害発生時の動作 .......................................................................................................... 15

7 お問い合わせ ......................................................................................................................... 18

8 免責事項 ................................................................................................................................ 18

改版履歴

2012 年 11月２日第１版


3


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

。


4


3 I/O フェンシング

I/O フェンシングは、共有データに対する入力に制限を設けることで、特定のノードからのみゕ

クセス可能とする技術の総称です。

HA クラスタでは、複数のノードが物理的に同じデータを参照します。これらのノードが同時に

同じデータに書き込みを行った場合、データの不整合が生じ、データは破壊されます。これはサ

ービスの停止以上に重大な問題です。

このような状態を防ぐための仕組みが I/O フェンシングであり LifeKeeper では以下の種類の

I/O フェンシング機能を提供しており、システム環境に応じた適用が可能となっています。


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 に指定したホストのうち過半数に接続できるかどうかで、自ノードが多数

派かどうかをチェックします。


6


Majority 方式

Witness Server と呼ばれる役割を持つ第三のノードをクラスタに参加させることに

よって、多数決を実現します。

どちらのモードを選択するかによって、HA システムの構成が異なります。今回の検証では、

TCP_remote 方式で検証を実施いたしました。

※TCP_remote 方式と Majority 方式の詳細については、下記のドキュメントを参照してください。

Quorum/Witness http://docs.us.sios.com/Linux/7.5/LK4L/TechDoc/Content/configuration/lifekeeper_io_fencing/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）の仮想環境においても、この仕組みを利用した電源操作

が可能です。この機能があることで、ハートビート切断障害発生時のフェルオーバにおいて

にフェルオーバ元ノード(仮想マシン)の電源を強制的に遮断することが可能となり、スプリ

ットブレンの発生を確実に抑止出来ることを確認いたしました。

http://docs.us.sios.com/Linux/7.5/LK4L/TechDoc/Content/configuration/lifekeeper_io_fencing/quorum_witness.htm

http://docs.us.sios.com/Linux/7.5/LK4L/TechDoc/Content/configuration/lifekeeper_io_fencing/quorum_witness.htm


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 を参照してください。

http://docs.redhat.com/docs/ja-JP/Red_Hat_Enterprise_Virtualization/3.0/

http://docs.redhat.com/docs/ja-JP/Red_Hat_Enterprise_Virtualization/3.0/


8


6 構成方法

本構成では、IBM Storwize V7000 ストレージを使用した Linux KVM 上の仮想ゲスト OS

上で、LifeKeeper for Linux による PostgreSQL サーバの HA システムを環境を構築いたし

ます。

本項では、以下のような 2 ノード構成の Active/Standbyクラスタを構築します。

KVM ホストサーバ IBM System x3690 X5

KVM ホスト OS (KVM01,KVM02) Red Hat Enterprise Linux 6.2 (x86_64)

KVM ゲスト OS (LK01,LK02) Red Hat Enterprise Linux 6.2 (x86_64)

管理(RHEV) サーバ IBM System x3250 M4

管理(RHEV) OS (RHEV-M) 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 8.4.9-1


9


各サーバと IBM Storwize V7000 の間は FCケーブルで以下のように結線しています（マル

チパス接続）。

各 KVM のゲスト OS と IBM Storwize V7000 の間は LAN ケーブルで以下のように結線して

います。


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 がンストールされており、起動することがで

きる


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 http://[rhevm-server]:8080/ca.crt

※RHEV-M から証明書の取得方法については、以下を参照してください。

http://docs.redhat.com/docs/ja-JP/Red_Hat_Enterprise_Virtualization/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] https://[RHEVM Host]:8443/api/vms

※仮想マシン一覧表示については、以下を参照してください。

http://docs.redhat.com/docs/ja-JP/Red_Hat_Enterprise_Virtualization/3.0/html/REST_API_Guide/appe-REST_API_Guide-cURL_Integration.html






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/>" https://[RHEVM 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/>" https://rhevm.iscoc.ibm.com:8443/api/vms/a444ba12-5001-4081-b9d2-ab175044ebf0/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/>" https://rhevm.iscoc.ibm.com:8443/api/vms/feb91595-6af7-4bd5-b8dc-7c38141cd956/stop

※電源断の替わりに再起動するようコマンドを記述することもできます。しかし、再起動後にハート

ビート通信が復旧していない場合には、再起動したノードが STONITH を発動してしまい、ピンポン

状態となる可能性があります。そのため、コマンドは電源断とすることを推奨します。


13


6.4 Quorum / Witness Server Kit の設定

KVM ゲスト OS の 2 ノード構成を維持し、TCP_Remote モードを

設定する。

以下のようなネットワーク構成で、RHEV-Mを Quorum Host として指定します。

この構成のポントは、コミュニケーションパスに使う経路が Quorum Host へのゕクセス経路

と重なっていることです。このことにより、ネットワーク障害発生時に障害ノードから Quorum

Host へのゕクセス経路が失われますので、両ノードが同時に多数派となってしまうことを回避で

きます。


14


コミュニケーションパスの作成

各ノード間で、コミュニケーションパスを作成します。コミュニケーションパスの少なく

とも一つが Quorum Host へのネットワーク経路と重なるよう考慮します。

SIOS_Primary と SIOS_Standby の間に、172.16.70.0、172.16.71.0 ネットワーク

を利用したコミュニケーションパスを作成します(172.16.71.0 Quorum Host への共

通の経路です)。

パラメータの設定

/etc/default/LifeKeeper を編集し、パラメータを以下のように設定します。原則的に、この

設定は全てのノードで共通にしてください。

# vi /etc/default/LifeKeeper QUORUM_MODE=tcp_remote # Quorum Check のモード

WITNESS_MODE=none # Witness Check を行わない

QUORUM_HOSTS=rhev.com:80 # 問合せ先ホスト:ポート

QUORUM_TIMEOUT_SECS=20 # 問合せのタムゕウト

QUORUM_LOSS_ACTION=fastkill # 少数派ノードの電源断動作

リソースの作成

(1) ファイルシステムリソースの作成

A) ファイルシステムのマウント

稼働系ノードである SIOS_Primary ノードで、IBM Storwize V7000 の共有データ領域

から PostgreSQL のデータ領域に使用するフゔルシステムを作成し、任意のデゖレクト

リにマウントします。

# fdisk /dev/mapper/mpath1 # mkfs.ext3 /dev/mapper/mpath1p1 # mount /dev/mapper/mpath1p1 /u01/


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 管理ガド

http://jpdocs.us.sios.com/LK4L/Previous/content/resources/pdfs/lkpgsql

74_jp.pdf

※IPリソースなどの各リソースが必要な場合は、必要に応じて作成して下さい。

6.5 障害発生時の動作

(1)ハートビート通信途絶時の動作

A) SIOS_Primary のネットワーク機能が異常停止した場合

ハートビート通信が途絶するシチュエーションはいくつか考えられますが、ここでは

SIOS_Primary にノード障害が発生し、ネットワーク機能に問題が生じた場合を想定しま

す。

SIOS_Primary は Quorum Host である RHEV-M への接続を試行します。しかし、ネ

ットワーク機能に障害が発生しており通信が行えません。そのため自ノードが少数派で

あると判断し、自発的な電源断を行います。

SIOS_Standby は 172.16.71.0 ネットワークを経由して Quorum Host である

RHEV-M への接続が可能です。そのため、自ノードが多数派であると判断し、サービ

スの起動を行います。

SIOS_Primary は電源断、SIOS_Standby がリソース起動

http://wiki.us.sios.com/jp/Documentation/LifeKeeper_for_Linux/LifeKeeper_for_Linux_Technical_Documentation/Administration/Administrator_Tasks/Creating_Resource_Hierarchies/Creating_A_File_System_Resource_Hierarchy

http://jpdocs.us.sios.com/LK4L/Previous/content/resources/pdfs/lkpgsql74_jp.pdf

http://jpdocs.us.sios.com/LK4L/Previous/content/resources/pdfs/lkpgsql74_jp.pdf


16


B) コミュニケーションパスのネットワークに障害発生した場合

172.16.70.0、172.16.71.0 ネットワークのすべてに障害が発生して、ハートビート通信

が途絶したケースです。

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 が電源断


17


(3) リソース障害発生時の動作

A) SIOS_Primary の PostgreSQL リソースが障害発生時の場合

SIOS_Primary の PostgreSQL リソースのリカバリ処理に失敗した場合は、PostgreSQL

リソースが SIOS_Standby へフェールオーバを開始します。

SIOS_Primary の PostgreSQL リソースは停止、

SIOS_Standby の PostgreSQL リソースが起動

※上記の障害発生時、PostgreSQL リソースと依存関係があるリソースも

SIOS_Primary で停止し、SIOS_Standby で起動します。


18


7 お問い合わせ

本ドキュメントの記載内容についてのお問い合わせ先

LifeKeeper 製品の導入を検討中のお客様

LifeKeeper 製品をご購入済みのお客様

8 免責事項

本書に記載された情報は予告なしに変更、削除される場合があります。最新のものをご確認

ください。

本書に記載された情報は、全て慎重に作成され、記載されていますが、本書をもって、その

妥当性や正確性についていかなる種類の保証もするものではありません。

本書に含まれた誤りに起因して、本書の利用者に生じた損害については、サオステクノロ

ジー株式会社は一切の責任を負うものではありません。

第三者による本書の記載事項の変更、削除、ホームページ及び本書等に対する不正なゕクセ

ス、その他第三者の行為により本書の利用者に生じた一切の損害について、サオステクノ

ロジー株式会社は一切の責任を負うものではありません。

弊社パートナー営業部までお問い合わせください。

TEL:03-6860-5111 (受付時間 9:00～17:00 土日祝祭日および弊社休業日は除く）

お問い合わせメールフォーム

https://www.sios.com/products/bcp/lkdk/contact/

弊社 LifeKeeper製品サポート窓口までお問い合わせください。

購入後のお問い合わせ

https://www.sios.com/products/bcp/lkdk/contact/support_lk.html

TEL:03-6860-5111

https://www.sios.com/products/bcp/lkdk/contact/

https://www.sios.com/products/bcp/lkdk/contact/support_lk.html


19


システム障害などの原因によりメールフォームからのお問い合せが届かず、または延着する

場合がありますので、あらかじめご了承ください。お問い合せの不着及び延着に関し、サ

オステクノロジー株式会社は一切の責任を負うものではありません。

【著作権】

本書に記載されているコンテンツ（情報・資料・画像等種類を問わず）に関する知的財産権は、

サオステクノロジー株式会社に帰属します。その全部、一部を問わず、サオステクノロジー

株式会社の許可なく本書を複製、転用、転載、引用、公衆への送信、販売、翻案その他の二次利

用をすることはいずれも禁止されます。またコンテンツの改変、削除についても一切認められま

せん。

本書では、製品名、ロゴなど、他社が保有する商標もしくは登録商標を使用しています。

サオステクノロジー株式会社

〒105-0001 東京都港区虎ノ門 4-1-28 虎ノ門タワーズ

電話:03-6860-5105

FAX:03-6860-5133 http://www.sios.com

http://www.sios.com/

Documents

LifeKeeper による Linux KVM - sios.jp · 6.2 SCSI Reservationの無効化 ... RHEV (Red Hat Enterprise Virtualization) 3.0 ... RESERVATIONS=none