Pacemaker boothを使った自動フェイルオーバーDRシステムの構成

1件のコメント

チケット手動管理型の4ノードDRクラスタの課題

サードウェアではDRBD 8系を使った2ノードのHAクラスタを2拠点に設置したDR(ディザスタリカバリ)システム構成の手順書を公開しています。

チケット手動管理型4ノードディザスタリカバリクラスタ構築手順書

上記の構成では拠点間でのアクティブ/スタンバイ切り替えは「チケット」の付与によって行っています。

チケット：リソースと依存関係を持たせ、チケットの有無でリソースの起動・停止を制御することができます。このチケットを使用すると、通常の死活監視が行えないWAN環境でも、サービスの切り替えやフェイルオーバが可能になります。

しかし管理上、以下の2つの問題点がありました。

  1. チケットの管理は人間系の判断によって行うか、または独自にスクリプトを作成して管理する必要がある
  2. サイトの切り替えが起きるとIPアドレスが変更されるため、外部からサービスへアクセスするにはDNSサービスの切り替え等を行う必要がある

これらの問題点は、それぞれ次のように解決可能です！

  1. Pacemakerのアドオン機能であるBoothを使用しチケットの自動割り振りを行う
  2. マネージドDNSサービスを使用する(DynDNSの使用)

PacemakerのBoothアドオン

Pacemakerにはチケットの授与/取り消しを行うコンポーネントとしてのCTR(Cluster Ticket Registry)という概念があります。しかし、この機能はPacemaker自体には含まれておらず、使用するには別途アドオンとして導入する必要があります。この実装プログラムがboothです。
(boothはCentOSのBaseリポジトリにもありますし、LINBITクラスタスタックサポートでも標準でサポートしています。)

booth利用環境には通常のサイトに加えて、もう1つサイト(アービトレータ「調停役」と呼ばれる)を追加します。ネットワークやノード障害が発生した場合には、アービトレータによって生き残らせるサイトを判断します。

boothのデーモンであるboothdをアービトレータ含めた全ノードで稼働できるようインストールします。また、/etc/booth/boothd.confに以下のような設定ファイルを置きます。

transport="UDP"
# The port that booth daemons will use to talk to each other.
# ブースデーモンが使用するポート番号
port="9929"　　　　　

# The arbitrator IP. If you want to configure several arbitrators,
# you need to configure each arbitrator with a separate line.
# アービトレータのIPアドレス
arbitrator="192.168.129.195"

# The site IP. The cluster site uses this IP to talk to other sites.
# Like arbitrator, you need to configure each site with a separate line.
# 構成内にあるサイトが通信に使うIPアドレス
site="192.168.129.197"
site="192.168.129.198"

# The ticket name, which corresponds to a set of resources which can be
# fail-overed among different sites.
# boothが管理するチケット名やオプション
ticket="TIC"
expire = 120
timeout = 5
acquire-after = 120

上記のexpireには、タイムアウトした後のチケットの有効期限です。さらにacquire-afterの時間後にチケットが他のサイトに付与されます。

Boothを使うことで変わる点

大きく3つの点が変わります

1. チケットの操作にboothコマンドを使用する

CTRを使わない場合、チケットの操作にはcrm_ticketコマンドを使ってきました。しかしCTRにboothを使用する場合には、チケットに対する操作は全てboothコマンドを通じて行います。

boothコマンドを使ったチケットの付与の例

# booth grant TIC -s 192.168.129.197
Aug 07 13:28:56 3node2 booth: [3653]: info: grant request sent, waiting for the result ...
Aug 07 13:28:56 3node2 booth: [3653]: info: grant succeeded!

 

2. チケットの2重付与を避けられる

PacemakerでCTRを使っていない時、実はチケット情報はサイト間で共有されていません。チケットを一方のサイトでgrant(授与)しても、もう一方のサイトはその事を知りません。このため、両方のサイトにチケットを与える事ができてしまいます。

しかし、crm_ticketコマンドではなくてboothコマンドを使って操作することでチケット情報をサイト間で共有できるようになります。もし一方のサイトに既にチケットを与えているのに別のサイトにチケットを与えようとすると、以下のようなメッセージが表示されチケットを与えることができません。

root@3node2 ~]# booth grant TIC -s 192.168.129.198
Aug 07 13:50:53 3node2 booth: [3658]: info: You're granting a granted ticket. If you wanted to migrate a ticket, use revoke first, then use grant.

 

3. 障害時に自動フェイルオーバできる

これがboothを導入する主目的でしょう。ノードやネットワーク障害時にチケットを自動的にrevoke, grantしてくれます。

▼例えば以下の図のようにサイトAの経路に障害が発生した場合・・・

▼死活監視がタイムアウトしてから「expire」時間後に、サイトAのチケットが取り消されます。

▼そのさらにaquire-after時間後にサイトBにチケットが与えられます。

boothのデメリットは？

もう1サイトを用意しなければならないというコスト面での負担がかかることでしょう。

しかし、アービトレータ用のノードには、他のシステム用に複数のアービトレータを稼働させる事が可能です。もし複数のDRシステムがある場合には１ノードに２つのアービトレータ役を兼任させる事ができるのでコストを軽減させることも可能です。

その他、後述のQAで説明しますがboothの機能では対応できない状況があります。

 

フェイルオーバー時のIPアドレス問題の解決〜DynDNSの使用〜

4ノード構成のDRシステム構成を行う場合、サイト間のフェイルオーバー時にサービスへのトラフィックをリダイレクトする方法が未解決でした。

この問題はOracle DynのManaged DNSを使用することで解決ができます。

Dyn(ダイン)はDDNS(ダイナミックDNS)で15年以上の歴史のあるDNSサービスの企業です(現在はOracle傘下のビジネスユニット）。このDynが提供するManaged DNSというサービスはリアルタイムに対象となるサービス(VIP)を監視してトラフィックを切り分けることができ、DRBD HAを使用したDRシステムには最適な解決策となります。

英語版となりますが、BoothとDynDNSを使用したLINBITの自動フェイルオーバーDRシステムのホワイトペーパーがございます。ご興味のある方は是非ご覧ください。

自動化を考慮したDRシステムを検討の際にはぜひご一考いただければと思います。

参考：AWSのroute53を使っても同様の機能を実現できます。

 

boothについての懸念点QA

 

Q：boothが勝手にrevokeすることはスプリットブレインを招かないでしょうか？

以下の状況でアービトレータのサイトCと現在チケットのあるサイトAとの間のネットワークが不通になった場合、実際にはサイトAは正常に稼働している場合どうなるのでしょうか？

チケットはサイトAでrevokeされてからサイトBにgrantされる動作になりますが、サイトAにとっては自分がチケットをrevokeされた事を知らない事にならないでしょうか？結果としてサイトA、サイトBの両方にチケットが与えられDRBDはスプリットブレイン状態になるのではないでしょうか？

A: その質問に対してはNOです。しかしスプリットブレインになるケースもあります。

boothの設定にはexpireというオプションがあります。これは「チケットの有効期限」であり、この有効期限が更新されない時にチケットが期限切れになります。

サイトAとサイトC間のネットワークが途切れた場合には、サイトAのチケットはexpire時間が経過した時に更新されないため、「期限切れ」になってrevokeされます。

つまりネットワーク断後のrevoke動作はアービトレータが実行するのではなく、すべてのノードでタイマーによって行われます。このため、サイトAが自分がチケットをrevokeされた事を知らないという状況にはなりません。

しかし、別の観点での懸念点もあります。それはネットワーク断が起きてチケットがrevokeされる時にDRBD Proxyに未送信のバッファーがあった場合で、さらにもう一方のサイトにgrantしてアクティブ化して新たな書き込みがあった場合です。この場合、もう一方のサイトでは元のサイトの未送信バッファ分のデータは読むことはできず、また元のサイトの復帰後にDRBDはスプリットブレイン状態になってしまいます。(もっともこれはDRBDのプロトコルAの制約でもありますが・・・)

 

Q:boothがあれば完全に自動化できるのでしょうか？

A : boothを使用すればすべて自動化できるのかといえば、現状では完全に自動化できるとは言えない面が残ります。

上述の構成例ではサイトA、B、Cすべての間の通信が途切れた場合などはどのサイトもアクティブになることができなくなります。

また、前項のようにDRBDのスプリットブレインが発生した際、もちろん自動復旧も可能ではありますが、データの重要性が高くなるほど人間が判断する必要性も高まるのではないかと思います。

boothは優れたコンセプトですが、例外的なケースが起きた場合には手動介入して判断を行う必要があるケースもあるという点は、導入の際に認識しておくことが重要です。