カテゴリー: ITめいたこと (30ページ目 (31ページ中))

最近、CrystalMark DiskInfoでHDDの温度を見たときに、結構高めになっているマシン(ケースはATXで、CPUは古めのAthron XP)があった。搭載しているHDDは2台で、いずれも古めのIDEドライブ(MaxtorのDiamondMax16と、HGSTのDeskstar 7K250)ということもあったが、それぞれ43度と44度になっており、多少暖房が効いている部屋といえども、ほとんどアイドルしているだけなので、これは温度高めかなと思っていた。

で、筐体を調べてみたら…安いBTOなPCだったせいか、ケースファンが付いてなくて、結局、ファンといえば、CPUファンと電源のファンだけが回っている状態で、CPUやチップセットの熱が筐体に溜まっているんだろうなぁと想像して、余ってたケースファン(2000rpm/9cm)を装着してみた。

取り付け作業を終えて、しばらくして測ってみたところ、それぞれ31度、37度まで温度が下がっていることが確認できた。

HDDの温度とMTBFの関係については、HDDベンダーは相関関係があると言っていたような気がするが、大規模にHDDを使っているGoogleは相関関係が見られなかったと言っていたような気がする。そんな対立はあるが、とりあえず、温度を下げておいて悪いことはなさそうだと思っている。

HDD自体にファンを付けるパーツも売っているが、ケースファンでがんばるのも手だなと思った。

雑用に使うためにWindowsサーバを構築することにした。社内に転がってるパーツをかき集めてたら、ITE製IT8211を搭載したATAカードが落ちてたので、流用することにした。

Windowsをインストールした後、IT8211のカードのドライバを探しにITEのサイト(http://www.ite.com.tw)に行ってみたが、さっぱりドライバをダウンロードできそうなページが見つからず。。。ダメもとで、ITEのページにある検索窓に「IT8211」とか入れてみたら、製品紹介が出てきて…そのページからドライバへのリンクが張られてた。てか、わかりにくすぎるんじゃないか、このナビゲーション(汗)

で、ドライバを入手して適用してみたら、デバイスマネージャに「SCSIとRAIDコントローラ」ってのが出現し、その中に「ITE IT8211 ATA/ATAPI Controller」ってのが追加されてた。SCSIでもRAIDコントローラでもないんですけど、これ…。

ちょっと調べてみたところ、IT8211にRAID機能を載せたとおぼしきIT8212ってチップがあるようなので(IT8211がIT8212からRAID機能を省いたサブセット版なのかもなぁ)、その辺とドライバを共通化してるのかもしれないなぁと思いつつ、ま、実用上は関係ないかと思いきや、早速、CrystalDiskInfoでSMART情報が見られなくて…後悔。

とあるサーバが応答しなくなったので、某所のデータセンターに行ってみた。すると、サーバのコンソールは一連のブートシーケンスらしきものが表示されていて、ファイルシステムがおかしいぞー的なエラーメッセージが出力された状態で止まっていた。

止まっていたサーバは、かなり前に構築されたサーバであるため、カーネルが古いせいか、kernel panicを起こすことがある。おそらくは、kernel panicして自動的に再起動して、再起動時のfsckで、修復が必要なエラーが検出されて止まっていたといった感じだろうか(…よくわからん…)

そんなわけで、、、冷や汗をかきながら、fsckをやってみた。といっても、fsckからinodeを見せられて、「修復しますか？」って聞かれたところで、「y」を押す以外のことはできるはずもなく、ただ、ひたすら「y」を連射。すると、リペアが完了した、みたいなメッセージが出力されて再起動。

…起動した。

DRBDを使っていて、うっかりスプリットブレインになっちゃった時に、リカバリー方法を間違えるとややこしいことになるような気がした(どっちをマスターにするかを間違えると、スレーブでマスターを上書きしてデータのロストとか起きたりしそう)ので、ちょっと試しにスプリットブレイン状態を作ってリカバリーしてみた。

使ったDRBDは8.3.0。インターネットを探してみると、DRBDが動いている状態でネットワークを引っこ抜くとスプリットブレインが発生すると書いてあるサイトもあったので、試しにL2スイッチの電源を落としてみた。そしたら、お互いに「WFConnection」(接続待ち)状態に遷移した。一方、マスター側は「Primary」状態なので、そのままマウントして、アプリケーションからいじってたりしたけれど影響はなかったみたいだ。で、ネットワークを再接続すれば、切断前のPrimary/Secondaryの関係性を維持したまま、「Primary」から「Secondary」への同期が始まった。で、同期が完了すると、「Connection」状態に戻った。

結局、ネットワークがダウンするだけでは、スプリットブレインは発生しないようだ。とりあえず、運用中にLANケーブルが引っこ抜ける的な障害が起こった場合は、LANケーブルを刺し直せば自動で対応してくれそうだ。

次に、意図的にスプリットブレインを作ることにした。L2スイッチを落とすところまでは同じだが、ネットワークが切れていることをいいことに、スレーブ側のマシンを「Primary」状態にしてみた。その後、L2スイッチの電源を入れる。これによって、お互いが「Primary」になっていることを検出するので、スプリットブレインとして、お互いが「StandAlone」に落ちる。ただ、もともと「Primary」になっていたマスター側は、StandAloneになっても「Primary」なので、マウントは可能っぽい。ただ、同期が取られないだけのようだ。dmesgでログを確認すると、以下のようなログが出力されていた。

drbd0: drbd_sync_handshake:

drbd0: self 6ABCC0B39EEBC9D5:03B0E55FA3B63131:38D5407DCCBC17FE:1C2D0C92A346572F

drbd0: peer 705B58F4947E0C9C:03B0E55FA3B63130:38D5407DCCBC17FE:1C2D0C92A346572F

drbd0: uuid_compare()=100 by rule 9

drbd0: Split-Brain detected, manually solved. Sync from this node

さて、両方のノードが「StandAlone」になったときにどう復旧するか。「drbdadm」にはいくつもコマンドオプションがあるので、いろいろ試してみたが、同期を取ってくれない。。。

そんなわけで、DRBDのマニュアルを探してみたら、「Manual split brain recovery」って項目があった。

DRBD detects split brain at the time connectivity becomes available again and the peer nodes exchange the initial DRBD protocol handshake. If DRBD detects that both nodes are (or were at some point, while disconnected) in the primary role, it immediately tears down the replication connection.

DRBDは、コネクティビティが復活した時や、同期相手とDRBD Protocolによるハンドシェイクを行う時にスプリットブレインを検出する。DRBDが両方のノードがPrimary(role)になっている(もしくは、接続が切れている、どこかの時点でPrimaryになっていた)場合、レプリケーションの接続をすぐに切断する。

After split brain has been detected, one node will always have the resource in a StandAlone connection state. The other might either also be in the StandAlone state (if both nodes detected the split brain simultaneously), or in WFConnection (if the peer tore down the connection before the other node had a chance to detect split brain).

スプリットブレインを検出した後では、一方のノードはずっと「StandAlone」になっていて、両方のノードが同時にスプリットブレインを検出していれば、もう一方のノードも「StandAlone」になっているかもしれないし、もう一つのノードがスプリットブレインを検出する前にコネクションを落としていれば、「WFConnection」になっているかもしれない。

At this point, unless you configured DRBD to automatically recover from split brain, you must manually intervene by selecting one node whose modifications will be discarded (this node is referred to as the split brain victim). This intervention is made with the following commands:

DRBDを自動的にスプリットブレインから復旧するように設定していなければ、こうなった時に、どっちのノードの変更を破棄するかを選択して、手動で介入する必要がある。この介入は、このコマンドで行われる。

と。

マスターとなる側では以下のコマンドを実行するらしい。

drbdadm connect resource

スレーブとなる側(つまり、変更点があっても破棄される側)では、以下のコマンドを実行するらしい。

drbdadm secondary resource

drbdadm — –discard-my-data connect resource

…というわけで、やってみたら、無事にConnection状態に戻った。

DRBDをマスターとなるマシンとスレーブの両方にインストールし終わっただけでは、両方とも「Secondary」状態になっているので、マスター側を「Primary」状態にする必要がある。そのためには、2つのマシン間でデータの同期を行う必要がある。

そのマスターを「Primary」にして、最初の同期を取るコマンドが、DRBD7までは「–do-what-I-say」ってオプションが有効だったけれど、それがDRBD8からは「-overwrite-data-of-peer」に変更になったそうだ。というわけで、

drbdadm — -overwrite-data-of-peer primary all

をマスターとなるマシンで実行する。確かに「do what I say」よりは「overwrite data of peer」の方がわかりやすいオプションではあるけども。で、同期が始まった後で、/proc/drbdを覗いてみると、同期の進捗などが見える。

$ cat /proc/drbd

version: 8.3.0 (api:88/proto:86-89)

GIT-hash: 9ba8b93e24d842f0dd3fb1f9b90e8348ddb95829 build by root@localhost.localdomain, 2008-12-22 17:52:35

0: cs:SyncTarget ro:Secondary/Primary ds:Inconsistent/UpToDate C r—

ns:0 nr:28678656 dw:28670464 dr:0 al:0 bm:1749 lo:257 pe:1560 ua:256 ap:0 ep:1 wo:b oos:13271260

[============>…….] sync’ed: 68.4% (12960/40958)M

finish: 0:07:24 speed: 29,796 (29,676) K/sec

ただ、speedのところに書いてある、この約30M/secってのは、単位は何だろうってことで、調べてみた。で、DRBDのドキュメント(no title)を見てみると、speedの単位としては書かれていなかったけど、随所で「KiByte」って書いてあるから、きっと「30MByte/sec」ってことなんだろう。ってことは、だいたい240Mbpsくらいか。ギガビットなイーサネットを使っておいてよかった。

DRBDのマスターとスレーブの通信方式は、3つの中から選べる。

drbd-8.3.0.tar.gzのサンプルのdrbd.confより

C: write IO is reported as completed, if we know it has reached _both_ local and remote DISK.

* for critical transactional data.

B: write IO is reported as completed, if it has reached local DISK and remote buffer cache.

* for most cases.

A: write IO is reported as completed, if it has reached local DISK and local tcp send buffer. (see also sndbuf-size)

*for high latency networks

DRBDを扱ったblogとかに載ってるdrbd.confを見ると、「C」になってることが多いけど、このサンプルファイルでは、「B」が「for most cases」となっている。サンプルのdrbd.confの続きにはこうも書いてあった。

uhm, benchmarks have shown that C is actually better than B. this note shall disappear, when we are convinced that B is the right choice “for most cases”. Until then, always use C unless you have a reason not to.

ベンチマーク的には「B」よりも「C」が優れているらしい。しかし、「B」の「remote buffer cache」って何を指しているんだろうか。Aがわざわざ「tcp」send bufferって書いてあるわけだから、tcpが付いてない=ネットワーク関連じゃないキャッシュなんだろう。そうなると、ディスクの書き込みキャッシュが思いついたりするが…そうなのか(汗)

でも、なんとなーく「C」の方が安心なプロトコルで、それって性能を犠牲にして実現されている方が、なんとなーく納得いくんだけどなぁ。まして、drbd.confを書いた人が、多くの場合、「B」が正しい選択って言う理由も気になるけども、、、書いてないか。

…でも、まぁ、とりあえず、「C」にしとく(汗)