medamaの日記

技術的な事をメインにしてみる。

GFSフォーマットする前に。 (6) Fencingについて

ＧＦＳ

前回触れたFencingの設定をしましょう。

RedHatのサポートを受ける場合は必須の設定です。

Fencingの設定をしない、もしくは、Manual Fencingを選択してしまった場合、RedHatのサポートは受けられなくなってしまいます。

注意してください。

で、Fencingとはなにするものよ、です。
Clusterを構成しているNodeが何らかの原因で障害を起こしたとします。
この状態でこのノードは動作を続けるべきでしょうか？
恐らく答えはNoだと思います。
速やかにこのnodeは動作をやめるべきです。
他のnodeも参照しているGFSデータを破壊してしまうような動作を起こしてしまうかもしれないからです。
障害を起こしてしまった場合、恐らくCluster Memberとしてハートビートを返しませんので、その他のnodeはこのサーバを殺す処理を自動的に実行してくれます。
この動作をfencingといいます。

正常なClusterグループの一番若いIDを持つnodeがこのfencingという動作を実行します。

ですので、集団リンチが発生するということはありません。

これを実行せずスキップした場合、どうなるかというと。
fencing動作完了後、GFSジャーナルの修復を行います。
ダウンしたnodeが中途半端なデータを書き込みしっぱなしの可能性があるためです。
fencingしない場合、ジャーナル修復後ダウンしたと思われたnodeが復活して書き込みを再開したとします。

そうです。
データは矛盾したり破壊されてしまいます。
この矛盾動作を防ぐためにfencingを行う必要があるのです。
fencing動作に求められることは

確実かつ迅速に障害発生中のサーバの電源をOFF（もしくはリセット）することです。

とにもかくにもDISKに書き込もうとしている情報（memory）を確実に消し去ることが目的です。

その為、OSに依存しないハードウェアによる電源OFF、ON出来る機材が別途必要になる、という事です。
（障害発生中のnodeなのでrebootが実行できる、できないという議論はここでは無意味。)
SANを移用している場合、データの書き込みを防げばよいので、SAN Switchに対してPortを強制Downさせて書き込みをさせない、というfencing方法も選択可能です。
この方法のみをfencingに採用した場合は自動的にPortをUPして良いかどうかまでの判断はfencing methodでは出来ないので障害を取り除いた後、手動でportをupする手間が必要になると思います。
そういうこともあり自動的に復旧可能である電源OFF、ONできる機材を用意しておいたほうが楽でしょう。
この場合は、リモート操作可能なPDUを利用する、IPMI(またはiLOなど）といったリモートマネージメントコンソールを利用する事になります。
どのような機材がサポートされているかを手っ取り早く調べるにはCluster Memberにログインして

ls /sbin/fence_*

するのが良いと思います。
CentOS5.2では以下の通りです。

/sbin/fence_apc
/sbin/fence_apc_snmp
/sbin/fence_bladecenter
/sbin/fence_brocade
/sbin/fence_bullpap
/sbin/fence_drac
/sbin/fence_egenera
/sbin/fence_ilo
/sbin/fence_ipmilan
/sbin/fence_manual
/sbin/fence_mcdata
/sbin/fence_node
/sbin/fence_rps10
/sbin/fence_rsa
/sbin/fence_rsb
/sbin/fence_sanbox2
/sbin/fence_scsi
/sbin/fence_scsi_test
/sbin/fence_tool
/sbin/fence_vixel
/sbin/fence_wti
/sbin/fence_xvm
/sbin/fence_xvmd

SAN Siwtchを利用している場合はfence_sanbox2やfence_brocadeを利用、リモートPDUであればfence_apcというコマンドにてfeincing methodがRedHatから提供されています。
これらが利用できる環境であり、適切に設定されているのであればきちんとサポートが受けられる、ということです。
（設定が適切でなくても適切な方法を教えてください、というサポートしてもらえると思います。）
なお、上記fencingコマンドに対応した機材が無いけど、fencing出来そうな機材はある、という場合は、/sbinにスクリプトを作成してcluster.confで呼び出すという方法もあります。
この場合は恐らくfencingの部分に関してはサポートは受けられなくなると思います。
（他人が作ったスクリプトですからね・・・。）

私の場合、やはり標準でfencing methodが用意されていない環境ですので自作してしまいました。
自作する場合、perlで記述されている/sbin/fence_sanbox2を参考にしてみてください。
作成する際はperlでもCでもshellスクリプトでも何でも構いません。
別にサポートいらないし、ただどのタイミングでfencingが実行されるのかをチェックしたい、という場合は、fencing方法にmanualがありますので、こちらを利用します。
fencing manualを使えば実際に各nodeがfencingするところを確認できますのでテスト段階では有用です。

くどいですが、fencing manualやそもそもfencingを設定しない環境はサポートされません。

サポートされない、という事は安定した動作環境ではないよ、という事なのでサポートが必要、不必要にかかわらず本番利用時には必ずきちんとfencing可能な機材を導入しておきましょう。
これこれの障害が想定されている、それに対応するための方法がfencingだよ、とわざわざ教えてくれているのでこれを採用しないのはちょっとどうかと思います。
リモートPDUなんて復旧の手間を考えれば余裕でお釣りがくるほど安価なものです。
方法的にいきなり電源OFF、ONには抵抗感があるかもしれませんが、そうせざるを得ないケースがある事もまぎれも無い事実です。

なお、きちんとfencingに対応した機材を購入、設置、設定、テストも完了したけど実際にfencing出来なかったという場合。
まさかその機材が1つのセッションしか受け付けず、fencingしたときに誰か他の人がその機材に対してアクセスしていた為、fencing要求がブロックされた事が原因でした、という間抜けな自体は起こさないように注意してください。
この手の機材は1セッションしか受け付けない、という事は多いです。
私もfencingではないですが、某ストレージに定期的にsnapshot命令を発行するというスクリプトを作った時にこの手の罠にはまったことがありました・・・。
事前に想定できるしょうもない罠なので先に書いておきます。

最後にさりげなく書いておきます。

grub等に意味も無く長いboot waitを設定している場合。
少なくとも標準の5秒に戻しましょう。（もしくはそれ以下。）
それが推奨なので。

(fencingは別途もう少し深く取り下げようと思います。）