<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Natz&#039;s Digital 漂流記 &#187; DRBD</title>
	<atom:link href="http://www.natzworks.com/digital/servers/drbd/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.natzworks.com/digital</link>
	<description>Natz の PC/サーバー/デジタル機器に翻弄される日々</description>
	<lastBuildDate>Wed, 28 Dec 2011 05:33:35 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
			<item>
		<title>DRBD リソース・サイズを拡張</title>
		<link>http://www.natzworks.com/digital/2010/425.html</link>
		<comments>http://www.natzworks.com/digital/2010/425.html#comments</comments>
		<pubDate>Sun, 11 Jul 2010 14:25:46 +0000</pubDate>
		<dc:creator>Natz</dc:creator>
				<category><![CDATA[DRBD]]></category>
		<category><![CDATA[サーバー]]></category>

		<guid isPermaLink="false">http://www.natzworks.com/digital/2010/425.html</guid>
		<description><![CDATA[先日、我が家で稼動するメール・サーバーのスプール領域を拡張した。このメール・サーバーはDRBD + Heartbeat による高可用性クラスター構成を採る仮想マシン 2台のペアで、スプール領域は DRBD の下地に LVM を利用している。
ディスク領域の拡張・縮小に LVM が威力を発揮するのは言うまでもないが、その上に DRBD が乗った場合は、DRBD リソースのサイズも変更しなければいけない。その作業で少々混乱したので (情報量少ない？)、記録に残しておく。

まず最近リニューアルされた日本語サイトの ユーザーズ・ガイド を見ると、DRBD リソースをオンラインで拡張する際の条件として、次のように書かれている。


影響を受けるリソースの下位デバイスが、 LVMやEVMSなどの論理ボリューム管理サブシステムによって管理されている。
リソースの接続状態が Connected になっている。


この条件を満たしていれば、ユーザーズ・ガイドの記述どおりにオンラインで拡張が可能だ。例えばボリューム・グループ vg01 内の論理ボリューム test01 を利用した DRBD リソース r0 (resource: r0, device: /dev/drbd0, meta-disk: 任意, disk: /dev/vg01/test01) を 1GB 拡張する場合は、次のようにする。


・LV を拡張 (Primary &#038; Secondary)
# lvextend -L +1G /dev/vg01/test01

・DRBD リソースを拡張 (Primary)
# drbdadm resize r0

・ファイル・システムを拡張 (Primary) (※ ファイル・システムが [...]]]></description>
		<wfw:commentRss>http://www.natzworks.com/digital/2010/425.html/feed/</wfw:commentRss>
		<slash:comments>2</slash:comments>
		</item>
		<item>
		<title>DRBD 再考 (バックアップの効率化)</title>
		<link>http://www.natzworks.com/digital/entries/2009/000209.html</link>
		<comments>http://www.natzworks.com/digital/entries/2009/000209.html#comments</comments>
		<pubDate>Sat, 05 Sep 2009 02:03:10 +0000</pubDate>
		<dc:creator>Natz</dc:creator>
				<category><![CDATA[DRBD]]></category>
		<category><![CDATA[サーバー]]></category>

		<guid isPermaLink="false">http://www.natzworks.com/wpd/174.html</guid>
		<description><![CDATA[月刊 Software Design 誌のバックナンバーを眺めていたとき、2009年 6月号の DRBD
特集に目が留まった。そう言えばこの号の発売当時は仕事に忙殺されていたせいであまり真剣に記事を読んでおらず、何が書いてあったかほとんど記憶にない。ちょうど先日アップグレードしたばかりで個人的に盛り上がっている DRBD の特集に改めて目を通してみると、実に興味深い運用方法が紹介されていた。

DRBD を使った HA クラスタリングは、ファイルシステム・レベルで複数ノードからの同時マウントがサポートされていない限り、基本的にアクティブ／スタンバイ方式となる。我が家でも 「なるべく止めたくない」 サービスのストレージとして、LVM から切り出した LV を DRBD でミラーリングしているが、このストレージ領域のファイルシステムは通常の ext3 で 「マウントは Primary 側」 と言う固定観念があったため、バックアップは Primary 側で LVM のスナップショットを利用して行っていた。
ところが 「DRBD と LVM2 によるバックアップの効率化」 と題する記事には、「LVM のスナップショットを使うなら、バックアップは Secondary 側でやっちまえ」 と (言う内容が丁寧に書いて) あるではないか。
言われてみれば確かに、DRBD の Primary 側は 「任意のブロックデバイスをマウントして読み書きできる」 側だが、複数ノードからの同時マウントがサポートされていないファイルシステム上では、Secondary 側は 「マウントして読み書き」 ができないだけだ。DRBD の下地が LVM で構築されて DRBD が正常に機能していれば、「マウントできさえすれば正常に利用可能」 なデータが Primary/Secondary 双方に等しく保存されているわけで、バックアップは遊んでいることが多い [...]]]></description>
		<wfw:commentRss>http://www.natzworks.com/digital/entries/2009/000209.html/feed/</wfw:commentRss>
		<slash:comments>2</slash:comments>
		</item>
		<item>
		<title>DRBD 8.2 → 8.3 アップグレード</title>
		<link>http://www.natzworks.com/digital/entries/2009/000208.html</link>
		<comments>http://www.natzworks.com/digital/entries/2009/000208.html#comments</comments>
		<pubDate>Wed, 02 Sep 2009 19:36:15 +0000</pubDate>
		<dc:creator>Natz</dc:creator>
				<category><![CDATA[DRBD]]></category>
		<category><![CDATA[サーバー]]></category>

		<guid isPermaLink="false">http://www.natzworks.com/wpd/173.html</guid>
		<description><![CDATA[自宅サーバーの CentOS 5.3 で yum update を実行したところ、DRBD 8.3 がリリースされていた。DRBD はネットワーク越しの RAID 1 よろしくマシン間でブロックデバイスをミラーリングする画期的なソフトウェアで、クリティカルな部分で運用されるケースも多い。我が家のサーバー環境でも定番通り Heartbeat と組み合わせ、HA クラスタリングの要になっている。
DRBD はファイルシステムより下のレイヤーでブロックデバイスを操作し、動作にはカーネルモジュールが必要になる。かつて DRBD 0.7 時代にはソースからコンパイルしてインストールしていたが、今は CentOS 5 用リポジトリの "extras" にあるパッケージをインストールしてあり、drbd82 が DRBD 本体、kmod-drbd82 がカーネルモジュールだ。
ところが yum update で更新ありと表示されたのは drbd83 のみ。現行の DRBD 8.2 からのマイナーアップグレードになるが、モノがモノだけに気軽に更新できる代物ではない。経験上この手のソフトウェアを何も考えずにアップグレードすると痛い目に遭う可能性は少なくないので、yum update はいったん中止して、心身ともに準備を整えて出直すことにした。

まず当該サーバーをシャットダウンし、万が一に備えてスナップショットを作成しておく。幸い我が家で DRBD を利用するサーバーは全て VMware Server による仮想マシンなので、これで面倒な事態になっても「なかったこと」にできる。
当該サーバーを起動して改めて yum update を実行すると、DRBD のアップグレード自体はすんなり終了した。すかさず cat /proc/drbd を確認してみると DRBD が動作しておらず、スタンバイ側でも Primary を見失っている。また自動起動設定も無効になっている [...]]]></description>
		<wfw:commentRss>http://www.natzworks.com/digital/entries/2009/000208.html/feed/</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
	</channel>
</rss>

