LifeKeeper for LinuxとRHEVとV7000連携

(1)

LifeKeeper による Linux KVM 環境

HA システム構築ガイド

(2)

2

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)

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)

6

©2012 SIOS Technology, Inc. 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_fe 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）の仮想環境においても、この仕組みを利用した電源操作が可能です。この機能があることで、ハートビート切断障害発生時のフェ゗ルオーバにおいてにフェ゗ルオーバ元ノード(仮想マシン)の電源を強制的に遮断することが可能となり、スプリットブレ゗ンの発生を確実に抑止出来ることを確認いたしました。

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

(8)

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

(9)

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

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

(10)

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)

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-ab 175044ebf0/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-7c3 8141cd956/stop ※電源断の替わりに再起動するようコマンドを記述することもできます。しかし、再起動後にハートビート通信が復旧していない場合には、再起動したノードが STONITH を発動してしまい、ピンポン状態となる可能性があります。そのため、コマンドは電源断とすることを推奨します。

(13)

6.4 Quorum / Witness Server Kit の設定

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

設定する。

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

この構成のポ゗ントは、コミュニケーションパスに使う経路が Quorum Host へのゕクセス経路と重なっていることです。このことにより、ネットワーク障害発生時に障害ノードから Quorum Host へのゕクセス経路が失われますので、両ノードが同時に多数派となってしまうことを回避できます。

(14)

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 への接続が可能です。そのため、自ノードが多数派であると判断し、サービスの起動を行います。

(16)

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)

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

(19)

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