DRBD＋iSCSI夢の共演（後編）
　〜 OSの壁を越えたソリューション 〜

株式会社サードウェア
岩崎 登
2008/8/26

HDDが破損した場合の対処

　DRBDでミラーリングをしている2台のHDDのうち、プライマリ側のHDDが破損した場合には、当然iSCSIで公開しているボリュームへのアクセスが不可能となる。DRBDは、同期中の回線遮断については、回線復旧時に自動的に非同期のミラーリングを開始するが、ハードウェアの破損による交換の場合には、メタデータ領域が存在しないため、自動というわけにはいかない。

　こんなときには、プライマリサーバ用の新しいHDDを用意し、以下の手順で復旧作業を行う。

1.プライマリサーバのHDDを正常なものに交換する。

2.ミラーリングを行うパーティションを作成する。

3./etc/drbd.confに新しいパーティションを設定する。

4.DRBDのブロックデバイスをセカンダリサーバでプライマリモードにする。

drbdiscsi2 # drbdadm primary r0

5.プライマリサーバのDRBDを起動し、メタデータを作成する。

drbdiscsi1 # drbdadm create-md all

6.プライマリサーバのDRBDを再起動し、DRBDの同期が開始されたことを確認。

Drbdiscsi1 # cat /proc/drbd version: 8.2.6 (api:88/proto:86-88) GIT-hash: 3e69822d3bb4920a8c1bfdf7d647169eba7d2eb4 build by buildsvn@c5-i386- build, 2008-06-26 16:40:17 0: cs:SyncSource st:Primary/Secondary ds:UpToDate/Inconsistent C r--- ns:816476 nr:0 dw:0 dr:824448 al:0 bm:49 lo:1 pe:261 ua:250 ap:0 oos:1151672 [=======>............] sync'ed: 41.4% (1151672/1959800)K finish: 0:02:33 speed: 7,440 (6,464) K/sec

7.セカンダリサーバをセカンダリモードに変更する。

rbdiscsi2 # drbdadm secondary r0

8.プライマリサーバをプライマリモードに変更する。

rbdiscsi1 # drbdadm primary r0

9.tgtdを起動し、前編で解説したとおりにiSCSIターゲットを再設定する。

　この作業を行う際に最も重要なことは、セカンダリサーバ側のブロックデバイスをプライマリモードに変更することである。この作業を飛ばしてセカンダリモードで再同期を行うと、最悪の場合、新しく交換した空のHDDの内容をセカンダリサーバにミラーリングしてしまい、セカンダリサーバに残っていたデータすべてが消失してしまう恐れがある。再同期の作業は、細心の注意を払い慎重に行わなければならない。

再同期よりも作業の再開を優先したい場合は？

　HDD破損時にHDDを交換し、再同期をする手順は、通常のミラーリングRAIDの場合と変わらない。むしろ通常のミラーリングの方が早期復旧できる可能性が高いわけだが、サーバ本体が故障してしまった場合には、新しいサーバを別途用意しなくてはならない。またRAIDコントローラ自体が故障してしまった場合は、破損したデータがHDDに書き込まれてしまい、最悪ミラーリングされた2台のHDDのデータがともに復旧不能な状態となってしまうこともある。

　DRBDを使用する最大のメリットは、復旧方法に複数の選択肢が生まれることだ。さまざまな障害を想定し、プライマリサーバとセカンダリサーバとに同じ環境を構築しておくことで、HDDの障害だけではなく、プライマリサーバ本体に障害が起きた際、セカンダリサーバで同様のサービスを提供することにより、作業の停止時間を最小限に抑えることができる。

図1　システム復旧

　今回の環境ならば、プライマリ、セカンダリ双方にscsi target utilsをインストールしておき、プライマリサーバに障害が起きた場合、プライマリサーバの復旧作業を後回しにして、セカンダリサーバからiSCSIで公開して作業を進め、作業が落ち着いてからプライマリサーバの復旧と同期作業を行うということも可能になる。

OSの壁を越えたソリューション

　以上、前後編を通してDRBDとiSCSI環境の構築を行ってきた。最も重要なことは、これまでWindowsサーバ環境でのHAクラスタ環境を構築しようとすると、Windows用に提供されたソリューションを半強制的に選択せざるを得なかったのが、DRBDとiSCSIという技術を組み合わせることによって、オープンソースソフトウェアによるWindows環境向けのソリューションが提供できるということである。

　これは、オープンソースソフトウェアがOSの壁を乗り越えたと表現することもできるだろう。仮想化されたプラットフォーム上で複数のOSをサービスとして動作させる環境では、最も重要なことではないだろうか。

　今後も、ここで紹介したDRBDやiSCSIだけでなく、OSの壁を越えられるソリューションの出現に期待したい。

コラム■最強の敵「災害」からデータを守るには

「重要なデータはちゃんとバックアップを取ってます」なんて言葉を幾度となく聞いたことがあるが、このように宣言している人は、一体何からデータを守っているのか謎である。ただバックアップを取っているだけでは、自分に安心という自己暗示をかけているようなものであり、いざという時、復旧したいデータがバックアップされていなかったり、焼いたDVDが読めなかったりなど、いろいろ困ることになる。 　データの保護において最も重要なことは「何から、何のデータを、いかにして守るか」という明確な目的意識である。 　ただバックアップを取っているだけでは、自身の失敗からデータを守ることはできても、人類最大の敵、地震や火災のような災害からはデータを守ることはできないのだ。たとえミラーリングRAIDをしていても、火災でサーバごと燃えてしまったり、泥棒が金庫と間違えてサーバマシンをバールのようなものでボコボコにしていってしまったり、トイレでタバコを吸った怠慢社員によってスプリンクラーが誤作動してサーバごと水浸しになったりと、定点でのバックアップでは防ぎきれないデータの損失原因は数多くある。そして、失われたデータを復旧させるには、それなりのデータ復旧センターに助けを求める必要があり、目の飛び出すような高額な見積りを前に、自らの将来とリアルに向き合うことになる。 　もちろん上司だって、「バックアップがあるから大丈夫だ」と思っているところに、バックアップごとなくなったなんてことをいえば「バックアップの意味ないじゃん、それ」といわれるのは火を見るよりも明らかだ。 　では、どうすればこれらの災害からデータを守ることができたのだろうか。話は簡単、バックアップを別の場所に置いておけばよかったのだ。このような遠距離でのバックアップ／復旧体制を、「ディザスタリカバリ」（disaster recovery）という。 　高速通信環境が整備されている昨今では、定期的にネットワークを通じたバックアップを実施している環境も数多く見られるようになった。地震に対する備えへの関心が世間的にも高まっていることから、急速にその需要が増している。 　しかし、定期的なバックアップでは、しょせん、前回のバックアップまでのデータまでが復旧可能範囲。5分前のデータが復旧できるかというと、かなりの幸運の持ち主でない限り不可能に違いない。 　これを実現するのが、今回紹介したDRBDの商用版であるDRBD+（DRBDPlus）だ。LAN内だけではなく、インターネットを通じて遠隔地にもブロックデータを送信することができる。つまりLAN内に2台、遠隔地に1台のミラーリングが可能となり、同じデータを有したハードディスクが合計3台存在することになる。 　ここまでの環境を整えれば、自信を持って「最強の敵である地震や火災が来ても大丈夫です」と報告することができ、上司の機嫌も上々だろう。 　しかし、これで安心してはいけない。長年データの保存に関して議論されている背景には、隣のA氏から発せられる「あ……ファイル消しちゃった」という現象があるからである。ディザスタリカバリ環境によって最強の敵からデータを守れたとしても、「身近な敵」からデータを守るのは、なかなかどうして難しいものである。

3/3

Index DRBD＋iSCSI夢の共演（後編） 　OSの壁を越えたソリューション

Page 1 　Windows iSCSIイニシエータの準備 　管理ツール「tgtadm」 　 Page 2 　ボリュームの追加と削除 　パフォーマンスを考慮したDRBDの設定 Page 3 　HDDが破損した場合の対処 　再同期よりも作業の再開を優先したい場合は？ 　OSの壁を越えたソリューション 　コラム　最強の敵「災害」からデータを守るには

Linux Square全記事インデックス

---

Linux Squareフォーラム 仮想化技術関連記事

	連載：実践！ Xenで実現するサーバ統合 有力な仮想化技術として注目を集めるようになった「Xen」。このXenを活用してサーバ統合を実践していく手順を具体的に紹介します
	特集：サーバの仮想化技術とビジネス展開の可能性 jailからUML／VMwareまで 1台のマシンで複数のサーバを動かす「仮想化技術」。VMwareやUMLの登場により、WebサイトだけでなくOS自体を仮想化できるようになった
	特集：仮想化技術のアプローチと実装 VMwareから要注目技術Xenまで 1台のサーバで複数の仮想マシンを実行する仮想化技術は、空間コストを引き下げる可能性を持つ。最新の仮想化技術を概観してみよう
	特集：仮想OS「User Mode Linux」活用法 技術解説からカーネルカスタマイズまで Linux上で仮想的なLinuxを動かすUMLの仕組みからインストール／管理方法やIPv6などに対応させるカーネル構築までを徹底解説
	特集：仮想化技術の大本命「Xen」を使ってみよう インストール & Debian環境構築編 高いパフォーマンスで本命の1つとなった仮想マシンモニタ「Xen」。日本語による情報が少ないXenを、実際に動かしてみよう
	特集：仮想化技術の大本命「Xen」を使ってみよう Xen対応カスタムカーネル構築編 Xen環境およびその上で動作する仮想マシン用カーネルを自分で構築しよう。これにより、自由にカスタマイズしたカーネルを利用できる
	特集：IPv6、UML、セキュリティ機能の統合 全貌を現したLinuxカーネル2.6［第4章］ 今回は、これまでに紹介し切れなかった機能を一気に紹介する。これを読めば、カーネル2.6の正式リリースが楽しみになるだろう
	Linux Squareプロダクトレビュー　VMware Workstation 4 PC/AT互換機エミュレータとして不動の地位を築いたVMware。その新バージョンがリリースされた。新機能を早速試してみよう
	古くて新しい「サーバ仮想化技術」の行方 サーバ仮想化を実現するための技術がソフトウェア、ハードウェアの両面で出そろってきた。ハイパーバイザーのさらなる高速化に向けた動きを紹介する
	Linux Squareフォーラム全記事インデックス

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）