2016年8月18日木曜日

[Linux] DMMP Recovery Kit の動作概要



こんにちは。

LifeKeeperのユーザーサイトでは、LifeKeeperによるアプリケーションの保護に活用されるアプリケーションリカバリキット(ARK)についての記事など、HAクラスターの構築に役立つ情報を掲載しています。今日は、DMMPリカバリーキットの動作概要をご紹介する記事のご案内です。

DMMP ARK が提供する監視機能と起動処理、停止処理、リカバリ処理についてご説明します。>

対象製品:
DMMP Recovery Kit (LifeKeeper for Linux)

監視処理:

1)監視デーモンが 10秒間隔で保護対象のディスクのデバイス情報を取得。
2)デバイス情報を元に sg_persist を利用しリザーブの取得を確認。
3) 1),2)にて処理がエラー終了した場合、次回チェックにて lkdisktest コマンドを利用してディスク I/O を確認。

起動処理:

1) 対象ストレージデバイスの reservation key を確認
2) reservation key からデバイスのパスIDを取得し、デバイスへのリザーブを取得。
3) デバイスの状態をチェックし、問題が無ければ起動終了。

停止処理:

1) quickCheck が動作していたら停止。
2) 停止対象のデバイス名を取得。
3) 取得したデバイスを停止。

記事では、監視、起動、停止処理の詳細を記載しています。

記事の詳細はこちら ⇒ http://lk.sios.com/?p=5295

2016年8月1日月曜日

[Linux] DynamicDR(オンプレto AWS ディザスタリカバリ環境)の実現



こんにちは。SIOSの高田です。
本日81日にLifeKeeper for Linux v9.1がリリースされました。

今回はこの新しいLifeKeeper for Linux(以後LifeKeeper)を使って、オンプレミスで稼働しているシステムを障害発生時にパブリッククラウドのDisaster Recovery環境へ切り替える方法を検証してみました。他バージョンでも同様の構成が可能ですが、これまで検証していない構成でしたので新しいバージョンのリリースに合わせて検証しています。

まずは全体の構成から説明します。

















今回Disaster Recovery環境として利用するのはAmazon Web Service (以後AWS)です。

オンプレミスおよびAWSPublicのサブネットには、Webサーバーやアプリケーションサーバーを配置します。今回はWordPressを利用したWebサーバーを配置します。Webサーバーではクラスターソフトウェア(LifeKeeper)を利用しません。通常はオンプレミスのWebサーバーでサービスを提供しますが、その間AWS側にはWebサーバーは存在せず、Webサーバーをイメージ化したAmazon マシンイメージ(以後AMI)が存在する状態とします。障害が発生した際にAMIからサーバーを起動します。

オンプレミスおよびAWSPrivateのサブネットには、データベースサーバーを配置します。今回はMySQLを利用したデータベースサーバーを配置します。データベースサーバーはLifeKeeperを利用してクラスター構成とします。クラスター構成で利用する共有の領域は、DataKeeper for Linux (以後DataKeeper)を利用してミラーリングします。











オンプレミスとAWSprivateサブネット上に配置しているデータベースサーバー間の通信は、IPsecVPNを利用します。今回はオンプレミス側のルーターとしてYamahaRTX1200を利用します。AWSでは専用線接続(AWS Direct Connect)も利用できますが、既存のルーターを使用して検証することにしました。



各サブネットのCIDRやサーバーのIPアドレスは、以下のようにしています。





















作業開始時点では、オンプレミス側のサーバーが2台配置されているのみです。初めにAWSでのVPCおよび仮想プライベートゲートウェイの設定を行います。こちらの設定については、次回記事でご紹介します。

[Linux] Higher Availability DBを目指して、LifeKeeperのチューニングを試してみました。(第1回)



こんにちは
サイオステクノロジー 宇野です。

今回から“Higher Availability DB”について紹介してゆきたいと考えています。

HAクラスターのHAは、高可用性(High Availability)を実現するクラスターシステムのことですが、Higher Availabilityは、従来のHAクラスターで提供するHAより高い可用性を実現する事を指しています。今回はDBと限定しており、その中でもPostgreSQLを対象としたHAより高い可用性を目指す手法について試みてみたいと考えています。

HAより高い可用性を考える為に、従来のHAクラスターでのリカバリーについて見てゆきたいと考えています。HAクラスターソフトウェアであるLifeKeeper では、以下の様なリカバリー処理が行われます。
  • 一定間隔で行われる監視処理
  • 監視による障害検出
  • ローカルリカバリー(障害ノードでのサービス再起動によるリカバリ)
  • フェイルオーバーリカバリー(ノードを変更してサービスを起動する復旧)
HAより高い可用性を目指す場合、これらの処理を迅速に行う、もしくはリカバリーの望めない処理をスキップする等の方法を取ることで、より早いリカバリーを目指すことが可能です。
これらの処理を迅速にと紹介しましたが、短縮する事が可能な項目がいくつかあります。
  • 監視処理
  • フェイルオーバーリカバリー
LifeKeeper for Linux の監視処理は、デフォルトの120(LKCHECKINTERVAL=120)間隔で行うよう設定されています。この間隔を短縮する事で、より早く障害を検出できます。ただし短縮する場合は以下の点に気を付けて頂く必要があります。
  • LifeKeeper for LinuxLKCHECKINTERVALの間隔内で全てのリソースの監視処理を終える必要があります。その為、監視処理の間隔が短縮しすぎて、リソースの数やリソースの種類を考慮して監視間隔を設定する必要があります。
  • システム平常時とシステム高負荷時では監視処理に時間が変わる場合があります。
上記の事からサイオスからご案内する場合は、デフォルト値より短縮する設定について推奨する案内はしておりませんが、リソース数が少なく、高負荷状態にならないシステムという想定で設定値を短くすることで障害検出までの時間短縮を行えました。

各リソースの監視処理については通常ログ(/var/log/lifekeeper.log)に出力する事はありません。具体的に各リソースの監視処理にどのような処理を行い、その程度時間を要しているのか確認する為、各リソースのデバッグモードを有効にして頂くことで確認可能です。

例として、以下の様な構成であった場合、PostgreSQL, File system, Data Replication,IPリソースの監視処理をデバッグモードで確認する事で監視間隔を検討する情報が取得できます。



















1.     PostgreSQL リソースの場合は、以下のパラメータを/etc/default/LifeKeeperに追加し、LifeKeeperを再起動する事で監視処理に要する時間を測定しました。

LKPGSQLDEBUG=5

PostgreSQL リソースのデバッグモードを無効化する場合は、パラメータを削除して、LifeKeeperを再起動が必要です。

2.     File System, Data Replication, IPリソースを監視するために、それぞれ以下のコマンドでデバッグフラグを作成し、出力するログから処理時間を測定します。

# flg_create –f debug_filesys
# flg_create –f debug_dr
# flg_create –f debug_ip

  フラグ設定の状況については、以下のコマンドで確認可能です。

  # flg_list

    デバッグモードを無効にする場合は、以下のコマンドでフラグを削除します。

# flg_remove –f debug_filesys
# flg_remove –f debug_dr
# flg_remove –f debug_ip

デバッグモードは、調査を行う場合に詳細ログを出力して使用しますが、普段の運用では、ログの出力が冗長となり運用には向きません。その為、調査が終わりましたらデバッグモードは無効化してください。

次回は、実際の測定ログを確認してゆきたいと考えています。