アクティブ機のデータディスクが壊れたら遅滞なくフェイルオーバさせる方法


disk_crasher

DRBDでディスク故障を検出する方法

DRBDを使ったクラスタシステムは、2台のサーバに同一データが同時に保存されるため、ディスクが故障してもデータを失わないというメリットがあります (シェアードナッシングと呼びます)。もしディスクが故障してもサービスは継続可能ですが、しかしアクティブ機側のディスクが壊れたことに気づかないまま運用を続けていくわけにはいきません。

DRBDとPacemakerの設定を調整すると、アクティブ機側のディスクが故障したら自動的にフェイルオーバして管理者にメール通知するというアクションを自動化することができます。

以下に、アクティブ側データディスク故障時の自動フェイルオーバを実現するための設定を紹介します。

DRBDとPacemakerの合わせ技

必要な設定の要点は、以下の3つだけです。

DRBDのon-io-errorをdetachにする
まず、drbd.confのdiskセクションにあるon-io-errorパラメータ の値をdetachに設定します。この値を指定しておくと、DRBDが管理しているディスクが壊れたときにDRBDはそのディスクを切り離します。ネットワーク接続は持続するので、プライマリ側ディスクが壊れた場合、すべてのディスクI/Oの対象はセカンダリ側のディスクになります。
Pacemakerのdefault-resource-stickinessを200にする
ここがもっとも大切なポイントです。Pacemakerのdefault-resource-stickinessプロパティは、INFINITYを設定している方が多いですが、今回の目的を達成するには200にしてください。INFINITYのままでは自動フェイルオーバが起こりません。
MailToリソースエージェントを追加する
DRBDならびにPacemakerは、フェイルオーバ発生時にログに記録を残しますが、メールなどで通知してくれません。クラスタ設定の中にMailToリソースエージェントを追加しておくと、フェイルオーバが起きたときにメールを自動送信できるようになります。

なぜdefault-resource-stickiness=INFINITYではいけないのか

default-resource-stickinessは、「動作しているリソースとそのリソースが動作しているノードの結びつきの強さ」を示すスコアです。これをINFINITYに設定してしまうと、アクティブ機上で動作しているリソースは、ノード自体のダウンやオペレータによる切り替え操作以外の要因でフェイルオーバしなくなってしまいます。もちろん、この動き自体に問題はありませんが、効果が強すぎます。

drbdリソースエージェント(drbd RA)は、モニタを行うタイミングで「プライマリになるべきスコア」をPacemakerに伝えます。Pacemakerはこの値を考慮してリソースの配置を決定します。ここで、default-resource-stickinessがINFINITYになっていると、プライマリになるべきスコア値は「INTINITY+値=プライマリ」という Pacemakerの判断ルールにおいて無意味になってしまいます。200を設定すると、drbd RAが返した値もプライマリの位置決めに反映されるようになります。

設定例と動作確認方法

DRBDを使ったHAクラスタシステムがあれば、紹介した設定の効果をただちに確認できます。動作確認に使った環境の設定例を示しますので、ご参考ください。もちろんホスト名、IPアドレス、デバイス名などは適宜置き換えてください。

drbd.conf

DRBDバージョン8.3用の設定になっています。8.4用構文になっていませんが、(互換性があるので)8.4でもこのままで動くはずです。最低限のパラメータしか指定していません。on-io-error detach; がキーポイントです。

Pacemaker設定

WebサーバのHAクラスタを想定しています。もっとシンプルにしたければ、apache、Filesystem、IPaddr2などを省略してもいいと思います。ここでのポイントは、default-resource-stickiness="200" とMailToリソースエージェントの活用です。なおHeartbeatのためのha.cfは省略します。

クラスタの起動

cluster1とcluster2の両サーバでheartbeatを起動すると、cluster1がアクティブ機となってクラスタが起動します。crm_monコマンドで動作状態を表示させると、以下のような動作状態が表示されます。

アクティブ機であるcluster1側でcat /proc/drbdを実行すると、以下のような動作状態が表示されます。

ローカルディスクの故障をシミュレートする方法

アクティブ機のローカルディスクが壊れた状況をシミュレートするには、cluster1側で次のコマンドを実行します。

cat /proc/drbdの実行結果は以下のように変化します。

ds:フィールドの値が UpToDate/ から Diskless/ に変わっていればOKです。

フェイルオーバすることを確認

今回の設定では、drbd RAのモニタは10秒間隔で実行されるため、約10秒以内にフェイルオーバが始まるはずです。crm_monの表示が変化してcluster2が新たなアクティブ機になることを確認してください。また、通知メールがroot宛に送信されることもご確認ください。

元に戻す

drbdadm attach を実行すると、ディスクが故障した状態を元に戻せます。default-resource-stickiness=INFINITY に書き換えて同様にディスクを切り離し、フェイルオーバしないこともご確認ください。

まとめ

DRBDを使うと、2台のサーバのDRBDデータ領域が同時故障しない限り、データを完全に喪失することを避けられます。しかしながら、片方のディスクだけが故障した場合でも、できるだけ早くそのことを知って修理する必要があります。

drbd.confの on-io-error detach と Pacemaker の default-resource- stickiness=200 を組み合わせると、稼働系サーバのDRBDデータ領域の故障をPacemakerが検出できるようになります。そしてフェールオーバが起こり、パフォーマンス低下を避けられます。

さらにMailToリソースエージェントを組み込んでおくことによって、管理者は障害発生をメールで知ることができます。

ただし、待機系サーバのDRBDデータ領域が故障しても、フェールオーバは起こりません。したがって、実際のクラスタ運用にあたっては、DRBDの動作状態に関する何らかの外部監視と組み合わせることをお勧めいたします。

コメントを残す

名前 *
メールアドレス *
ウェブサイト

*