masakazu's Weblog » OS

Primary/Primary 構成の DRBD デバイス上に構築した Cluster Filesystem 上に構築した Xen 準仮想化仮想マシン上の Filesystem Benchmark

masakazu — Sun, 24 Feb 2008 14:18:48 +0000

以下の環境で iozone による Benchmark を実施してみました。

/dev/sdb1 上に作成した Ext3 Filesystem
/dev/drbd0 上に作成した Ext3 Filesystem
/dev/drbd0 上に作成した OCFS2 Filesystem
/dev/drbd0 上に作成した GFS Filesystem
/dev/sdb1 上に作成した Ext3 Filesystem 上に作成したファイルを Disk Image として構築した Xen 準仮想化仮想マシン上に作成した Ext3 Filesystem
/dev/drbd0 上に作成した Ext3 Filesystem 上に作成したファイルを Disk Image として構築した Xen 準仮想化仮想マシン上に作成した Ext3 Filesystem
/dev/drbd0 上に作成した OCFS2 Filesystem 上に作成したファイルを Disk Image として構築した Xen 準仮想化仮想マシン上に作成した Ext3 Filesystem
/dev/drbd0 上に作成した GFS Filesystem 上に作成したファイルを Disk Image として構築した Xen 準仮想化仮想マシン上に作成した Ext3 Filesystem

Benchmark 実行環境は以下の通り。

CPU	Intel(R) Pentium(R) D CPU 3.00GHz
メモリ	2GB(ただし Dom0 に 512MB のみ割り当て)
ディスク	FUJITSU MAX3073RC(容量:73.5GB/回転数:15000rpm/SAS 3Gbps)
NIC	Broadcom NetXtreme BCM5721 Gigabit Ethernet PCI Express

DRBD でミラー先として用いた環境は以下の通り。

CPU	Intel(R) Celeron(R) CPU 3.06GHz
メモリ	1GB(ただし Dom0 に 512MB のみ割り当て)
ディスク	FUJITSU MAX3073RC(容量:73.5GB/回転数:15000rpm/SAS 3Gbps)
NIC	Broadcom NetXtreme BCM5721 Gigabit Ethernet PCI Express

結果は以下の通り。念のため 3 回実行した平均値を求めています。

書き込み系の処理ではなぜか OCFS2/GFS の方がローカルディスクの Ext3 よりもスループットが高いことになってしまいました。なんでこんな結果になるのか理解できません。ひょっとしてライトバックでもしている？

あと Xen 上の Filesystem が全然遅くなっていない。本当か？

Xen の仮想マシン上はもっと性能が悪いのかと思っていたけど実際にはなかなかよさげです。

DRBD & Heartbeat – takeover/failback verification

masakazu — Wed, 12 Sep 2007 15:57:12 +0000

DRBD 上の ext3 filesystem を Heartbeat 配下に設定し、 Primary を落としたときと、落としてからあげたときの syslog。

何が起きているのかさっぱりですが、時間を作って追っかけたいと思います。

とりあえず、 Primary で mount されてた /var/lib/mysql という directory は、 Primary の shutdown 後、ちゃんと Secondary で mount されました。そして落とした Primary の復旧後、ちゃんと Secondary から Primary に戻りました。

以下の document が参考になるかも。

DRBD – Integrating with Heartbeat V1 [対訳]
- http://bougaidenpa.org/masakazu/entry/drbd_integrating_with_heartbeat_v1

以下は設定。

FILE: /etc/drbd.conf
--
resource r0 {
protocol C;
incon-degr-cmd "echo '!DRBD! pri on incon-degr' | wall ; sleep 60 ; halt -f";
startup {
degr-wfc-timeout 120;
}
disk {
on-io-error   detach;
}
net {
}
syncer {
rate 10M;
group 1;
al-extents 257;
}
on debiancluster1 {
device     /dev/drbd0;
disk       /dev/sdb1;
address    192.168.2.16:7788;
meta-disk  internal;
}
on debiancluster2 {
device    /dev/drbd0;
disk      /dev/sdb1;
address   192.168.2.17:7788;
meta-disk internal;
}
}

FILE: /etc/ha.d/ha.cf
--
logfacility     local0
ucast eth1 192.168.2.17
#ucast eth1 192.168.2.16
auto_failback on
node debiancluster1
node debiancluster2

FILE: /etc/ha.d/haresources
--
debiancluster1 drbddisk::r0 Filesystem::/dev/drbd0::/var/lib/mysql::ext3

以下は Primary 側を強制 shutdown させたときの Secondary 側の syslog。

Sep 13 00:08:38 debiancluster2 kernel: drbd0: PingAck did not arrive in time.
Sep 13 00:08:38 debiancluster2 kernel: drbd0: drbd0_asender [6652]: cstate Connected --> NetworkFailure
Sep 13 00:08:38 debiancluster2 kernel: drbd0: asender terminated
Sep 13 00:08:38 debiancluster2 kernel: drbd0: drbd0_receiver [3462]: cstate NetworkFailure --> BrokenPipe
Sep 13 00:08:38 debiancluster2 kernel: drbd0: short read expecting header on sock: r=-512
Sep 13 00:08:38 debiancluster2 kernel: drbd0: worker terminated
Sep 13 00:08:38 debiancluster2 kernel: drbd0: drbd0_receiver [3462]: cstate BrokenPipe --> Unconnected
Sep 13 00:08:38 debiancluster2 kernel: drbd0: Connection lost.
Sep 13 00:08:38 debiancluster2 kernel: drbd0: drbd0_receiver [3462]: cstate Unconnected --> WFConnection
Sep 13 00:08:56 debiancluster2 heartbeat: [6088]: WARN: node debiancluster1: is dead
Sep 13 00:08:56 debiancluster2 heartbeat: [6088]: WARN: No STONITH device configured.
Sep 13 00:08:56 debiancluster2 heartbeat: [6088]: WARN: Shared disks are not protected.
Sep 13 00:08:56 debiancluster2 heartbeat: [6088]: info: Resources being acquired from debiancluster1.
Sep 13 00:08:56 debiancluster2 heartbeat: [6088]: info: Link debiancluster1:eth1 dead.
Sep 13 00:08:56 debiancluster2 heartbeat: [6925]: debug: notify_world: setting SIGCHLD Handler to SIG_DFL
Sep 13 00:08:56 debiancluster2 harc[6925]: info: Running /etc/ha.d/rc.d/status status
Sep 13 00:08:56 debiancluster2 heartbeat: [6926]: info: No local resources [/usr/lib/heartbeat/ResourceManager listkeys debiancluster2] to acquire.
Sep 13 00:08:56 debiancluster2 heartbeat: [6088]: debug: StartNextRemoteRscReq(): child count 1
Sep 13 00:08:56 debiancluster2 mach_down[6945]: info: Taking over resource group drbddisk::r0
Sep 13 00:08:57 debiancluster2 ResourceManager[6965]: info: Acquiring resource group: debiancluster1 drbddisk::r0 Filesystem::/dev/drbd0::/var/lib/mysql::ext3
Sep 13 00:08:57 debiancluster2 ResourceManager[6965]: info: Running /etc/ha.d/resource.d/drbddisk r0 start
Sep 13 00:08:57 debiancluster2 ResourceManager[6965]: debug: Starting /etc/ha.d/resource.d/drbddisk r0 start
Sep 13 00:08:57 debiancluster2 kernel: drbd0: Secondary/Unknown --> Primary/Unknown
Sep 13 00:08:57 debiancluster2 ResourceManager[6965]: debug: /etc/ha.d/resource.d/drbddisk r0 start done. RC=0
Sep 13 00:08:57 debiancluster2 Filesystem[7101]: INFO: Running status for /dev/drbd0 on /var/lib/mysql
Sep 13 00:08:57 debiancluster2 Filesystem[7101]: INFO: /var/lib/mysql is unmounted (stopped)
Sep 13 00:08:57 debiancluster2 Filesystem[7037]: INFO: Filesystem Resource is stopped
Sep 13 00:08:57 debiancluster2 ResourceManager[6965]: info: Running /etc/ha.d/resource.d/Filesystem /dev/drbd0 /var/lib/mysql ext3 start
Sep 13 00:08:57 debiancluster2 ResourceManager[6965]: debug: Starting /etc/ha.d/resource.d/Filesystem /dev/drbd0 /var/lib/mysql ext3 start
Sep 13 00:08:57 debiancluster2 Filesystem[7210]: INFO: Running start for /dev/drbd0 on /var/lib/mysql
Sep 13 00:08:57 debiancluster2 kernel: kjournald starting.  Commit interval 5 seconds
Sep 13 00:08:57 debiancluster2 kernel: EXT3 FS on drbd0, internal journal
Sep 13 00:08:57 debiancluster2 kernel: EXT3-fs: recovery complete.
Sep 13 00:08:57 debiancluster2 kernel: EXT3-fs: mounted filesystem with ordered data mode.
Sep 13 00:08:57 debiancluster2 Filesystem[7146]: INFO: Filesystem Success
Sep 13 00:08:58 debiancluster2 ResourceManager[6965]: debug: /etc/ha.d/resource.d/Filesystem /dev/drbd0 /var/lib/mysql ext3 start done. RC=0
Sep 13 00:08:58 debiancluster2 mach_down[6945]: info: /usr/lib/heartbeat/mach_down: nice_failback: foreign resources acquired
Sep 13 00:08:58 debiancluster2 mach_down[6945]: info: mach_down takeover complete for node debiancluster1.
Sep 13 00:08:58 debiancluster2 heartbeat: [6088]: info: mach_down takeover complete.

以下は強制 shutdown した Primary を再起動したときの Primary 側の syslog。

Sep 13 09:11:24 debiancluster1 kernel: drbd: initialised. Version: 0.7.21 (api:79/proto:74)
Sep 13 09:11:24 debiancluster1 kernel: drbd: SVN Revision: 2326 build by root@debiancluster1, 2007-09-13 07:55:36
Sep 13 09:11:24 debiancluster1 kernel: drbd: registered as block device major 147
Sep 13 09:11:24 debiancluster1 kernel: drbd0: resync bitmap: bits=5208430 words=81382
Sep 13 09:11:24 debiancluster1 kernel: drbd0: size = 19 GB (20833720 KB)
Sep 13 09:11:24 debiancluster1 kernel: drbd0: 0 KB marked out-of-sync by on disk bit-map.
Sep 13 09:11:24 debiancluster1 kernel: drbd0: Found 6 transactions (267 active extents) in activity log.
Sep 13 09:11:24 debiancluster1 kernel: drbd0: Marked additional 809 MB as out-of-sync based on AL.
Sep 13 09:11:24 debiancluster1 kernel: drbd0: drbdsetup [2198]: cstate Unconfigured --> StandAlone
Sep 13 09:11:25 debiancluster1 kernel: drbd0: drbdsetup [2211]: cstate StandAlone --> Unconnected
Sep 13 09:11:25 debiancluster1 kernel: drbd0: drbd0_receiver [2212]: cstate Unconnected --> WFConnection
Sep 13 09:11:25 debiancluster1 kernel: drbd0: drbd0_receiver [2212]: cstate WFConnection --> WFReportParams
Sep 13 09:11:25 debiancluster1 kernel: drbd0: Handshake successful: DRBD Network Protocol version 74
Sep 13 09:11:25 debiancluster1 kernel: drbd0: Connection established.
Sep 13 09:11:25 debiancluster1 kernel: drbd0: I am(S): 1:00000002:00000001:00000003:00000002:10
Sep 13 09:11:25 debiancluster1 kernel: drbd0: Peer(P): 1:00000002:00000001:00000003:00000003:10
Sep 13 09:11:25 debiancluster1 kernel: drbd0: drbd0_receiver [2212]: cstate WFReportParams --> WFBitMapT
Sep 13 09:11:25 debiancluster1 kernel: drbd0: Secondary/Unknown --> Secondary/Primary
Sep 13 09:11:25 debiancluster1 kernel: drbd0: drbd0_receiver [2212]: cstate WFBitMapT --> SyncTarget
Sep 13 09:11:25 debiancluster1 kernel: drbd0: Resync started as SyncTarget (need to sync 828856 KB [207214 bits set]).
Sep 13 09:11:30 debiancluster1 heartbeat: [2278]: WARN: Core dumps could be lost if multiple dumps occur
Sep 13 09:11:30 debiancluster1 heartbeat: [2278]: WARN: Consider setting /proc/sys/kernel/core_uses_pid (or equivalent) to 1 for maximum supportability
Sep 13 09:11:31 debiancluster1 heartbeat: [2278]: WARN: Logging daemon is disabled --enabling logging daemon is recommended
Sep 13 09:11:31 debiancluster1 heartbeat: [2278]: info: **************************
Sep 13 09:11:31 debiancluster1 heartbeat: [2278]: info: Configuration validated. Starting heartbeat 2.0.7
Sep 13 09:11:31 debiancluster1 heartbeat: [2279]: info: heartbeat: version 2.0.7
Sep 13 09:11:31 debiancluster1 heartbeat: [2279]: info: Heartbeat generation: 4
Sep 13 09:11:31 debiancluster1 heartbeat: [2279]: info: G_main_add_TriggerHandler: Added signal manual handler
Sep 13 09:11:31 debiancluster1 heartbeat: [2279]: info: G_main_add_TriggerHandler: Added signal manual handler
Sep 13 09:11:31 debiancluster1 heartbeat: [2279]: info: Removing /var/run/heartbeat/rsctmp failed, recreating.
Sep 13 09:11:31 debiancluster1 heartbeat: [2279]: info: glib: ucast: write socket priority set to IPTOS_LOWDELAY on eth1
Sep 13 09:11:31 debiancluster1 heartbeat: [2279]: info: glib: ucast: bound send socket to device: eth1
Sep 13 09:11:31 debiancluster1 heartbeat: [2279]: info: glib: ucast: bound receive socket to device: eth1
Sep 13 09:11:31 debiancluster1 heartbeat: [2279]: info: glib: ucast: started on port 694 interface eth1 to 192.168.2.17
Sep 13 09:11:31 debiancluster1 heartbeat: [2279]: info: G_main_add_SignalHandler: Added signal handler for signal 17
Sep 13 00:11:42 debiancluster1 heartbeat: [2279]: info: Local status now set to: 'up'
Sep 13 00:11:42 debiancluster1 heartbeat: [2279]: info: Link debiancluster2:eth1 up.
Sep 13 00:11:42 debiancluster1 heartbeat: [2279]: info: Status update for node debiancluster2: status active
Sep 13 00:11:42 debiancluster1 heartbeat: [2343]: debug: notify_world: setting SIGCHLD Handler to SIG_DFL
Sep 13 00:11:42 debiancluster1 harc[2343]: info: Running /etc/ha.d/rc.d/status status
Sep 13 00:11:43 debiancluster1 heartbeat: [2279]: info: Comm_now_up(): updating status to active
Sep 13 00:11:43 debiancluster1 heartbeat: [2279]: info: Local status now set to: 'active'
Sep 13 00:11:43 debiancluster1 heartbeat: [2279]: WARN: G_CH_dispatch_int: Dispatch function for read child took too long to execute: 480 ms (> 50 ms) (GSource: 0x5dfeb8)
Sep 13 00:11:43 debiancluster1 heartbeat: [2279]: info: remote resource transition completed.
Sep 13 00:11:43 debiancluster1 heartbeat: [2279]: info: remote resource transition completed.
Sep 13 00:11:43 debiancluster1 heartbeat: [2279]: info: Local Resource acquisition completed. (none)
Sep 13 00:11:44 debiancluster1 heartbeat: [2279]: info: debiancluster2 wants to go standby [foreign]
Sep 13 00:11:46 debiancluster1 kernel: drbd0: Secondary/Primary --> Secondary/Secondary
Sep 13 00:11:46 debiancluster1 heartbeat: [2279]: info: standby: acquire [foreign] resources from debiancluster2
Sep 13 00:11:46 debiancluster1 heartbeat: [2354]: info: acquire local HA resources (standby).
Sep 13 00:11:46 debiancluster1 ResourceManager[2364]: info: Acquiring resource group: debiancluster1 drbddisk::r0 Filesystem::/dev/drbd0::/var/lib/mysql::ext3
Sep 13 00:11:46 debiancluster1 ResourceManager[2364]: info: Running /etc/ha.d/resource.d/drbddisk r0 start
Sep 13 00:11:46 debiancluster1 ResourceManager[2364]: debug: Starting /etc/ha.d/resource.d/drbddisk r0 start
Sep 13 00:11:46 debiancluster1 kernel: drbd0: Secondary/Secondary --> Primary/Secondary
Sep 13 00:11:46 debiancluster1 ResourceManager[2364]: debug: /etc/ha.d/resource.d/drbddisk r0 start done. RC=0
Sep 13 00:11:47 debiancluster1 Filesystem[2500]: INFO: Running status for /dev/drbd0 on /var/lib/mysql
Sep 13 00:11:47 debiancluster1 Filesystem[2500]: INFO: /var/lib/mysql is unmounted (stopped)
Sep 13 00:11:47 debiancluster1 Filesystem[2436]: INFO: Filesystem Resource is stopped
Sep 13 00:11:47 debiancluster1 ResourceManager[2364]: info: Running /etc/ha.d/resource.d/Filesystem /dev/drbd0 /var/lib/mysql ext3 start
Sep 13 00:11:47 debiancluster1 ResourceManager[2364]: debug: Starting /etc/ha.d/resource.d/Filesystem /dev/drbd0 /var/lib/mysql ext3 start
Sep 13 00:11:47 debiancluster1 Filesystem[2609]: INFO: Running start for /dev/drbd0 on /var/lib/mysql
Sep 13 00:11:49 debiancluster1 kernel: kjournald starting.  Commit interval 5 seconds
Sep 13 00:11:49 debiancluster1 kernel: EXT3 FS on drbd0, internal journal
Sep 13 00:11:49 debiancluster1 kernel: EXT3-fs: mounted filesystem with ordered data mode.
Sep 13 00:11:49 debiancluster1 Filesystem[2545]: INFO: Filesystem Success
Sep 13 00:11:49 debiancluster1 ResourceManager[2364]: debug: /etc/ha.d/resource.d/Filesystem /dev/drbd0 /var/lib/mysql ext3 start done. RC=0
Sep 13 00:11:49 debiancluster1 heartbeat: [2354]: info: local HA resource acquisition completed (standby).
Sep 13 00:11:49 debiancluster1 heartbeat: [2279]: info: Standby resource acquisition done [foreign].
Sep 13 00:11:49 debiancluster1 heartbeat: [2279]: info: Initial resource acquisition complete (auto_failback)
Sep 13 00:11:49 debiancluster1 heartbeat: [2279]: info: remote resource transition completed.
Sep 13 00:13:40 debiancluster1 kernel: drbd0: Resync done (total 127 sec; paused 0 sec; 6524 K/sec)
Sep 13 00:13:40 debiancluster1 kernel: drbd0: drbd0_worker [2199]: cstate SyncTarget --> Connected

以下は強制 shutdown した Primary を再起動したときの Secondary 側の syslog。

Sep 13 00:11:32 debiancluster2 kernel: drbd0: drbd0_receiver [3462]: cstate WFConnection --> WFReportParams
Sep 13 00:11:32 debiancluster2 kernel: drbd0: Handshake successful: DRBD Network Protocol version 74
Sep 13 00:11:32 debiancluster2 kernel: drbd0: Connection established.
Sep 13 00:11:32 debiancluster2 kernel: drbd0: I am(P): 1:00000002:00000001:00000003:00000003:10
Sep 13 00:11:32 debiancluster2 kernel: drbd0: Peer(S): 1:00000002:00000001:00000003:00000002:10
Sep 13 00:11:32 debiancluster2 kernel: drbd0: drbd0_receiver [3462]: cstate WFReportParams --> WFBitMapS
Sep 13 00:11:32 debiancluster2 kernel: drbd0: Primary/Unknown --> Primary/Secondary
Sep 13 00:11:32 debiancluster2 kernel: drbd0: drbd0_receiver [3462]: cstate WFBitMapS --> SyncSource
Sep 13 00:11:32 debiancluster2 kernel: drbd0: Resync started as SyncSource (need to sync 828856 KB [207214 bits set]).
Sep 13 00:11:42 debiancluster2 heartbeat: [6088]: info: Heartbeat restart on node debiancluster1
Sep 13 00:11:42 debiancluster2 heartbeat: [6088]: info: Link debiancluster1:eth1 up.
Sep 13 00:11:42 debiancluster2 heartbeat: [6088]: info: Status update for node debiancluster1: status init
Sep 13 00:11:42 debiancluster2 heartbeat: [6088]: info: Status update for node debiancluster1: status up
Sep 13 00:11:42 debiancluster2 heartbeat: [6088]: debug: StartNextRemoteRscReq(): child count 1
Sep 13 00:11:42 debiancluster2 heartbeat: [6088]: debug: get_delnodelist: delnodelist=
Sep 13 00:11:42 debiancluster2 heartbeat: [7260]: debug: notify_world: setting SIGCHLD Handler to SIG_DFL
Sep 13 00:11:42 debiancluster2 harc[7260]: info: Running /etc/ha.d/rc.d/status status
Sep 13 00:11:42 debiancluster2 heartbeat: [7270]: debug: notify_world: setting SIGCHLD Handler to SIG_DFL
Sep 13 00:11:42 debiancluster2 harc[7270]: info: Running /etc/ha.d/rc.d/status status
Sep 13 00:11:43 debiancluster2 heartbeat: [6088]: info: Status update for node debiancluster1: status active
Sep 13 00:11:43 debiancluster2 heartbeat: [7280]: debug: notify_world: setting SIGCHLD Handler to SIG_DFL
Sep 13 00:11:43 debiancluster2 harc[7280]: info: Running /etc/ha.d/rc.d/status status
Sep 13 00:11:43 debiancluster2 heartbeat: [6088]: info: remote resource transition completed.
Sep 13 00:11:43 debiancluster2 heartbeat: [6088]: info: debiancluster2 wants to go standby [foreign]
Sep 13 00:11:44 debiancluster2 heartbeat: [6088]: info: standby: debiancluster1 can take our foreign resources
Sep 13 00:11:44 debiancluster2 heartbeat: [7290]: info: give up foreign HA resources (standby).
Sep 13 00:11:44 debiancluster2 ResourceManager[7300]: info: Releasing resource group: debiancluster1 drbddisk::r0 Filesystem::/dev/drbd0::/var/lib/mysql::ext3
Sep 13 00:11:44 debiancluster2 ResourceManager[7300]: info: Running /etc/ha.d/resource.d/Filesystem /dev/drbd0 /var/lib/mysql ext3 stop
Sep 13 00:11:44 debiancluster2 ResourceManager[7300]: debug: Starting /etc/ha.d/resource.d/Filesystem /dev/drbd0 /var/lib/mysql ext3 stop
Sep 13 00:11:45 debiancluster2 Filesystem[7399]: INFO: Running stop for /dev/drbd0 on /var/lib/mysql
Sep 13 00:11:45 debiancluster2 Filesystem[7399]: INFO: Trying to unmount /var/lib/mysql
Sep 13 00:11:45 debiancluster2 Filesystem[7399]: INFO: unmounted /var/lib/mysql successfully
Sep 13 00:11:45 debiancluster2 Filesystem[7335]: INFO: Filesystem Success
Sep 13 00:11:45 debiancluster2 ResourceManager[7300]: debug: /etc/ha.d/resource.d/Filesystem /dev/drbd0 /var/lib/mysql ext3 stop done. RC=0
Sep 13 00:11:45 debiancluster2 ResourceManager[7300]: info: Running /etc/ha.d/resource.d/drbddisk r0 stop
Sep 13 00:11:45 debiancluster2 ResourceManager[7300]: debug: Starting /etc/ha.d/resource.d/drbddisk r0 stop
Sep 13 00:11:45 debiancluster2 kernel: drbd0: Primary/Secondary --> Secondary/Secondary
Sep 13 00:11:46 debiancluster2 ResourceManager[7300]: debug: /etc/ha.d/resource.d/drbddisk r0 stop done. RC=0
Sep 13 00:11:46 debiancluster2 heartbeat: [7290]: info: foreign HA resource release completed (standby).
Sep 13 00:11:46 debiancluster2 heartbeat: [6088]: info: Local standby process completed [foreign].
Sep 13 00:11:46 debiancluster2 kernel: drbd0: Secondary/Secondary --> Secondary/Primary
Sep 13 00:11:49 debiancluster2 heartbeat: [6088]: WARN: 1 lost packet(s) for [debiancluster1] [17:19]
Sep 13 00:11:49 debiancluster2 heartbeat: [6088]: info: remote resource transition completed.
Sep 13 00:11:49 debiancluster2 heartbeat: [6088]: info: No pkts missing from debiancluster1!
Sep 13 00:11:49 debiancluster2 heartbeat: [6088]: info: Other node completed standby takeover of foreign resources.
Sep 13 00:13:32 debiancluster2 kernel: drbd0: [drbd0_worker/6924] sock_sendmsg time expired, ko = 4294967295
Sep 13 00:13:40 debiancluster2 kernel: drbd0: Resync done (total 127 sec; paused 0 sec; 6524 K/sec)
Sep 13 00:13:40 debiancluster2 kernel: drbd0: drbd0_worker [6924]: cstate SyncSource --> Connected

DRBD – Integrating with Heartbeat V2 [対訳]

masakazu — Sun, 26 Aug 2007 17:39:08 +0000

DRBD – Integrating with Heartbeat V2(http://www.drbd.org/drbd8-howto2.html) の対訳。

誤訳がありましたらコメントにてご指摘ください。

前: DRBD – Integrating with Heartbeat V1 [対訳]

Getting and installing Heartbeat

Heartbeat の入手とインストール

As with Heartbeat V1, the preferred way of installing Heartbeat V2 is through your distribution’s package management frontend (yum, apt, rug, whatever). If you do want to build and install from source, the Linux-HA download area has the necessary archives.

Heartbeat V1 と同様、 Heartbeat V2 のお勧めのインストール方法はディストリビューションのパッケージ管理ツール(yum, apt, rug, など)を利用する方法である。もしソースからビルドとインストールを行いたいのであれば、 Linux-HA のダウンロードサイトに必要となるアーカイブがある。

On the Linux-HA site, you will also find the Getting Started V2 howto that will enable you to get an initial Heartbeat V2 configuration up and running.

Linux-HA サイトには、 Heartbeat V2 の初期設定と起動のための Getting Starget V2 howto も見つけられるだろう。

Prerequisites

前提条件

The same prerequisites apply for Heartbeat V2 as do for Heartbeat V1. In fact, you might run Heartbeat V2 just like V1, with unchanged configuration. If, however, you want to use Heartbeat’s new Cluster Resource Manager (CRM) introduced in V2, you need to include this line in your /etc/ha.d/ha.cf:

Heartbeat V1 と同様の前提条件が Heartbeat V2 でも適用される。実際、設定を変更せず Heartbeat V2 を V1 と同じように実行できるかもしれない。しかし、Heartbeat V2 で新しく導入されたクラスターリソースマネージャ(CRM)を利用したいのであれば、 /etc/ha.d/ha.cf に以下の行を追加する必要がある:

crm yes

Simple, isn’t it? Note that if you have that option enabled, Heartbeat will no longer read the haresources file on startup, and will issue a warning if that file exists.

単純だろう。このオプションを有効にすると、 Heartbeat はもう haresources ファイルを起動時に読み込まなくなり、もしこのファイルが存在した場合に警告するようになる。

Cluster Information Base (CIB) configuration

クラスター情報ベース(CIB) の設定

Heartbeat V2 resources are defined in the Cluster Information Base XML file, usually found in /var/lib/heartbeat/crm/cib.xml. This may be edited manually, see the Linux-HA site for more information (however, see the following paragraph if you prefer a more user-friendly approach).

Heartbeat V2 のリソースはクラスター情報ベースという XML ファイルで定義される。このファイルは普通 /var/lib/heartbeat/crm/cib.xml にある。このファイルは手動で編集される。詳細な情報は Linux-HA サイトを参照せよ。(ただしよりユーザーフレンドリーな方法を好むようであれば次の節を参照。)

Using the Heartbeat V2 GUI

Heartbeat V2 GUI を利用する

Heartbeat V2 includes a GUI for the cluster resource manager, which will manipulate the Cluster Information Base for you. It is written in Python and requires GTK+, Glade, and the associated Python bindings. It’s named ha_client.py, though some distributions rename it to hbgui or similar.

Heartbeat V2 はクラスターリソースマネージャのための GUI を含んでいる。これはクラスター情報ベースを操作する。これは Python で書かれ GTK+, Glade, そして関連する Python バインディングを必要とする。 ha_client.py という名前で、いくつかのディストリビューションはこれを hbgui などと名前を変更している。

Heartbeat V2 DRBD resources

Heartbeat V2 での DRBD リソース

With Heartbeat V2, you may address DRBD resources in one of two ways:

Heartbeat V2 では DRBD リソースを二つのうち一つの方法で示すことになる。

the drbddisk resource type, as in Heartbeat V1,

Heartbeat V1 で drbddisk リソースタイプ
the drbd resource type, using the Heartbeat V2/OCF interface.

Heartbeat V2/OCF インターフェースで drbd リソースタイプ

DRBD/Heartbeart V2 configuration check list

DRBD/Heartbeat V2 設定チェックリスト

In order to set up a working DRBD configuration with Heartbeat V2, follow these steps:

Heartbeat V2 と動作する DRBD の設定をするためには以下の手順に従う:

Set up your DRBD resource (using either the drbddisk or drbd resource type)

DRBD リソースを設定する(drbddisk か drbd リソースタイプを使って)
Set up your filesystem resource

ファイルシステムリソースを設定する
Set up your IP address resource

IP アドレスリソースを設定する
Set up your service resource

サービスリソースを設定する
Create an order constraint so the DRBD resource is activated before the filesystem resource (so Heartbeat doesn’t attempt to mount a file system on a node that’s still in secondary mode)

ファイルシステムの前に DRBD リソースが有効になるよう順序制約を作る(Heartbeat はまだセカンダリモードのノードのファイルシステムをマウントしようとしない)
Create a colocation constraint so the filesystem, IP address, and service resources always run on the same node

ファイルシステムと IP アドレスとサービスリソースが同じノードで実行されるよう位置制約を作る
(optional) Set a preferred node for the service resource.

(オプションで) そのサービスの優先ノードを設定する

前: DRBD – Integrating with Heartbeat V1 [対訳]

DRBD – Integrating with Heartbeat V1 [対訳]

masakazu — Sun, 26 Aug 2007 16:28:15 +0000

DRBD – Integrating with Heartbeat V1(http://www.drbd.org/drbd8-howto1.html) の対訳。

誤訳がありましたらコメントにてご指摘ください。

前: DRBD – Migrating DRBD resources [対訳]

次: DRBD – Integrating with Heartbeat V2 [対訳]

Note

ノート

DRBD is cluster manager agnostic. You may use any cluster manager for managing DRBD resources. Heartbeat (as described here) serves as the canonical example.

DRBD はクラスターマネージャ不可知論者である。あなたは DRBD のリソースを管理するために様々なクラスターマネージャを利用するかもしれない。(ここで説明する)Heartbeat は正規の例を提供する。

Getting and installing Heartbeat

Heartbeat の取得とインストール

The preferred way of installing Heartbeat is through your distribution’s package management frontend (yum, apt, rug, whatever). If you do want to build and install from source, the Linux-HA download area has the necessary archives.

Heartbeat をインストールする完全な方法はあたなが利用しているディストリビュージョンのパッケージ管理ツール(yum, apt, run, など)を利用することだ。もしソースコードからビルドしインストールしたいのであれば Linux-HA のダウンロードサイトに必要なアーカイブがある。

On the Linux-HA site, you will also find the Getting Started howto that will enable you to get an initial Heartbeat configuration up and running.

Linux-HA サイトには、 Heartbeat の初期設定と起動のための Getting Starget howto も見つけられるだろう。

Prerequisites

前提条件

In order to have your DRBD resources managed by Heartbeat, the following conditions must be met beforehand:

あなたの DRBD リソースを Heartbeat で管理するためには、次の条件を事前に満たさなければならない:

Heartbeat, the DRBD kernel module, and the DRBD userland tools must be installed on both cluster nodes (if you’re thinking “duh” now, that’s perfectly appropriate)

Heartbeat, DRBD kernel モジュール, そして DRBD のツールが両方のクラスターノードでインストールされていなければならない(あなたが現在 “duh” を考えているなら、それは完全に適切です)。
You must have your /etc/ha.d/ha.cf and /etc/ha.d/authkeys configured correctly

/etc/ha.d/ha.cf と /etc/ha.d/authkeys が適切に設定されていなければならない。
DBRD resources must be configured in /etc/drbd.conf, and that file must have been distributed cluster-wide

RDBD のリソースが /etc/drbd.conf で設定されていなければならない。そしてこのファイルはクラスター間で配布されていなければならない。
The DRBD kernel module must be loaded (the resource scripts won’t do that for you, your specific distribution will, however, offer a facility to automate this at system boot)

DRBD kernel モジュールがロードされていなければならない(リソーススクリプトはこの作業を行ってくれない、しかしながら、特定のディストリビューションは、システムリブートの時点でこの作業を自動で行ってくれる)。
Network connectivity must be established on the DRBD replication path and all Heartbeat communication paths

ネットワーク接続性が DRBD レプリケーション経路と Heartbeat 通信経路で確立されていなければならない。
Not required, but highly recommended: you should have tested and verified manual migration of your DRBD resources

必須ではないが強く勧める: DRBD リソースへのテストと手動でのマイグレーションをすでに行っている。

Configuring haresources

haresources の設定

The haresources file, /etc/ha.d/haresources, is where you’ll configure your managed DRBD as a cluster resource. Normally it makes little sense to have DRBD managed without an associated file system. An entry for DRBD in the haresources file might look like this:

haresources ファイル /etc/ha.d/haresources は、あなたの管理する DRBD をクラスターリソースとして設定する場所である。通常、ファイルシステムと関連しない DRBD を管理することには意味がない。DRBD に対する haresources ファイルの設定は以下のようになる:

joe drbddisk::r0 Filesystem::/dev/drbd0::/var/lib/mysql::ext3

This will instruct Heartbeat to manage the DRBD resource r0 concurrently with the ext3 filesystem /var/lib/mysql, which will be mounted from the corresponding block device /dev/drbd0. The preferred node for this resource is joe.

これは /dev/drbd0 というブロックデバイス上の ext3 ファイルシステムで /var/lib/mysql にマウントされている DRBD リソース r0 を管理するよう Heartbeat に指示する。このリソースの優先ノードは joe である。

Of course, the more typical (and complete) usage would be this:

もちろん、より典型的(かつ完全)な利用はこのようになる:

joe drbddisk::r0 Filesystem::/dev/drbd0::/var/lib/mysql::ext3 192.168.0.42 mysqld

… which in addition to the DRBD device and file system will also include a service IP address (192.168.0.42) and a MySQL RDBMS daemon (mysqld) in the same cluster resource.

… DRBD デバイスとファイルシステムに加え、同じクラスターリソース上のサービス IP アドレス(192.168.0.42) と MySQL RDBMS デーモン(mysqld) も設定している。

Note

ノート

Like /etc/drbd.conf, /etc/ha.d/haresources must be identical on both cluster nodes.

/etc/drbd.conf のように、 /etc/ha.d/haresources は両方のクラスターノードで一致していなければならない。

前: DRBD – Migrating DRBD resources [対訳]

次: DRBD – Integrating with Heartbeat V2 [対訳]

DRBD – Migrating DRBD resources [対訳]

masakazu — Thu, 23 Aug 2007 16:38:34 +0000

DRBD – Migrating DRBD resources(http://www.drbd.org/drbd8-howto0.html) の対訳。

誤訳がありましたらコメントにてご指摘ください。

前: DRBD – Getting started [対訳]

次: DRBD – Integrating with Heartbeat V1 [対訳]

Suppose we have our DRBD resource r0, corresponding to /dev/drbd0, mounted on /mnt on one cluster node (joe), and want to mount it on the other (jane). This page outlines the process of doing this manually.

以下を想定する。DRBD リソース r0 がある。r0 は /dev/drbd0 に該当する。r0 はクラスターノードの一方(joe) で /mnt にマウントされている。そしてもう一方のクラスターノード(jane) でマウントしたい。このページではこれを手動で行う方法について説明していく。

Notes

ノート

This walk-through demonstrates the steps in switching resources over manually, which is helpful if you want to test DRBD or see how it works. In any practical configuration, you would have the switch-over/fail-over process managed by a cluster manager.

このデモではリソースの切り替えを手動で行う。もし DRBD のテストをしたいとかどんな感じで動作するのか知りたいのであればとても参考になるだろう。実際の設定ではクラスターマネージャを用いたスイッチオーバ/フェイルオーバをすることになるだろう。

In either scenario, you need to ensure that /etc/drbd.conf is identical on both nodes.

いずれにせよ、確実に両方のノードの /etc/drbd.conf が同じ内容である必要がある。

Initial status

初期状態

At first, let’s have a look what the current DRBD status is from joe’s perspective:

最初に、 joe 側で DRBD の状態がどのようになっているかを確認する。

root@joe:~# cat /proc/drbd
version: 8.0.0 (api:86/proto:86)
SVN Revision: 2759 build by florian@sour, 2007-02-21 16:06:15
0: cs:Connected st:Primary/Secondary ds:UpToDate/UpToDate C r---
ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0
resync: used:0/31 hits:0 misses:0 starving:0 dirty:0 changed:0
act_log: used:0/257 hits:0 misses:0 starving:0 dirty:0 changed:0

Releasing the device

デバイスの解放

The first thing we do now is free /dev/drbd0 (if we don’t do this, DRBD will refuse to change that device’s status):

まず最初にすることは /dev/drbd0 を解放すること(こうしないと DRBD はデバイスの状態を変えようとしても拒否する)。

root@joe:~# umount /dev/drbd0

Demoting the resource

リソースを降格させる

Then we demote r0 on joe, so that the device is secondary on both nodes:

そしたら joe の r0 を降格させる。そうすると両方のノードでデバイスはセカンダリとなる。

root@joe:~# drbdadm secondary r0
root@joe:~# cat /proc/drbd
version: 8.0.0 (api:86/proto:86)
SVN Revision: 2759 build by florian@sour, 2007-02-21 16:06:15
0: cs:Connected st:Secondary/Secondary ds:UpToDate/UpToDate C r---
ns:0 nr:0 dw:0 dr:0 al:0 bm:81 lo:0 pe:0 ua:0 ap:0
resync: used:0/31 hits:0 misses:0 starving:0 dirty:0 changed:0
act_log: used:0/257 hits:0 misses:0 starving:0 dirty:0 changed:0

Promoting the resource

リソースを昇格させる

At this time we can promote jane to become the primary node for this resource:

この時点で jane をこのリソースに対するプライマリノードに昇格させることができる。

root@jane:~# drbdadm primary r0
root@jane:~# cat /proc/drbd
version: 8.0.0 (api:86/proto:86)
SVN Revision: 2759 build by florian@sour, 2007-02-21 16:06:15
0: cs:Connected st:Primary/Secondary ds:UpToDate/UpToDate C r---
ns:0 nr:0 dw:0 dr:0 al:0 bm:81 lo:0 pe:0 ua:0 ap:0
resync: used:0/31 hits:0 misses:0 starving:0 dirty:0 changed:0
act_log: used:0/257 hits:0 misses:0 starving:0 dirty:0 changed:0

Using the resource

リソースを利用する

Finally, we can mount the device on Jane:

最後に jane でデバイスをマウント出来る。

root@jane:~# mount /dev/drbd0 /mnt

Other things you might want to try

ほかに試してみたいこと

DRBD disallows a few things so as to keep you from shooting yourself in the foot. You might try the following things just to see what happens:

DRBD は自分で自分の足を撃ってしまわないよういくつかの制限を設けている。なにが起きるのかを確認するために次の事柄をためしてみたいかもしれない。

Demoting a primary device to secondary while it’s still mounted. This will fail with a “device held open by someone” error.

まだマウントされている状態でプライマリデバイスをセカンダリに降格させようとする。この場合 “device held open by someone” というエラーで失敗するだろう。
Making a device primary while the other one is primary too, unless this is explicitly allowed.

(明示的に許可されていない状態で)他方がプライマリの状態でデバイスをプライマリにしようとする。
Mounting the backing device directly, while being used by DRBD.

DRBD で利用されている状態でブロックデバイスを直接マウントしようとする。

前: DRBD – Getting started [対訳]

次: DRBD – Integrating with Heartbeat V1 [対訳]

DRBD – Getting started [対訳]

masakazu — Thu, 23 Aug 2007 15:18:45 +0000

DRBD – Getting started(http://www.drbd.org/drbd8-howto.html) の対訳。

誤訳がありましたらコメントにてご指摘ください。

次: DRBD – Migrating DRBD resources [対訳]

Installation

インストール

If you install via tarball, you want to read the README and INSTALL notes first.

もし tarball からインストールしたいのであれば、 README と INSTALL を最初に読んだ方がよい。

You want to also read the upgrade*.txt files in the drbd src directory, or online in the drbd subversion repository.

また、 drbd ソースディレクトリかオンラインの drbd subversion リポジトリに存在する upgrade*.txt ファイル群も読んだ方がよい。

Along with the DRBD tarball or your installed DRBD package, you should find a well commented example configuration file. In the tarball this is in ./scripts/drbd.conf, in installed binary packages it most likely ends up in /usr/share/doc/drbd, /usr/share/doc/packages/drbd, or similar.

DRBD の tarball もしくはインストールされた DRBD パッケージと一緒に、たくさんコメントが書かれた設定ファイル例を見つけられるだろう。 tarball の場合 ./scripts/drbd.conf に、バイナリパッケージでインストールした場合はたいてい /usr/share/doc/drbd とか /usr/share/doc/packages/drbd とかにある。

You edit that to your needs, copy it to /etc/drbd.conf on both nodes, and check that the meta-disk points to the right location.

必要に応じてそのファイルを編集し、両方のノードに /etc/drbd.conf としてコピーし、 meta-disk が正しい場所を向いているか確認する。

DRBD meta data

DRBD のメタデータ

DRBD allows you to either place its meta data on the same backing device where it puts the actual usable production data (internal meta data), or on a separate block device (external meta data). Before DRBD 8, the space required for DRBD meta data was fixed at 128MB, regardless of device size. Starting with DRBD 8, you may refer to this table for estimates of DRBD meta data sizes:

DRBD ではデータを格納するデバイス上にメタデータを同居させる方法(内部メタデータ)と、別のデバイスに分ける方法(外部メタデータ)のどちらかの方法でメタデータを格納出来る。 DRBD 8 以前では、DRBD メタデータに要求されるスペースはデバイスのサイズに関わらず 128MB に固定されていた。 DRBD 8 からは、DRBD メタデータのサイズは以下のテーブルから見積もることができる。

Block device size	DRBD meta data
1 GB	2 MB
100 GB	5 MB
1 TB	33 MB
4 TB	128 MB

Make sure you don’t direct DRBD to write its meta data to a place where you already have existing data you still need. Also, if you are using internal meta data on an existing block device with a file system on it, make sure you shrink that file system first!

まだ必要としているデータが存在している場所に対して DRBD がメタデータを書き込まないように注意しよう。また、すでにファイルシステムを持っているブロックデバイスで内部メタデータを使用する場合は、はじめにファイルシステムを圧縮している(縮めている)ことを確認すること。

Bringing up your DRBDs

DRBD を立ち上げる

Now that we have that drbd.conf, copy it to /etc/drbd.conf on both nodes. Then, on both nodes, do a drbdadm up all. It should come up as both nodes Secondary and Inconsistent.

drbd.conf が出来たら、両方のノードに /etc/drbd.conf としてコピーする。そしたら両方のノードで drbdadm up all を実行する。両方ともセカンダリかつ不整合として起動するはず。

The latter is because the underlying storage is not yet synchronized, and DRBD has no way of knowing whether you want the initial sync from left-to-right, or right-to-left. So you have to tell it. If you have no data in the underlying block devices, it does not matter. But if you have an existing filesystem on the lower level device, and now you sync in the wrong direction, you’d need to get your latest backup ready afterwards…

なんでそうなるか。それはストレージがまだ同期されていないからで、その上 DRBD は右から左に同期すべきなのか、それとも左から右なのか、あなたが最初の同期をどちらにしたいのか知る方法がないから。なのでそれを教えてあげなければならない。もしなにもデータを持っていないブロックデバイスで構成しているのであれば、それはどうでもいいことだろう。しかしすでに構成するデバイスがファイルシステムを持っていて、仮に間違った方向に同期してしまったなら、あなたは最新のバックアップデータの準備をしなければならなくなるだろう。

Performing the initial device synchronization

最初のデバイス同期の実行

You choose which node shall become Primary for the first time (the one with the good data, if you have some), then you do drbdadm — –overwrite-data-of-peer primary all. The result is a full synchronization of the underlying devices (we call this the initial full sync).

まず最初にプライマリになってほしいノード(もしデータがある状態なら条件の良いデータを持っている方)を選択する。そして drbdadm — -overwrite-data-of-peer primary all を実行する。結果としてデバイスの完全な同期がとられる(これを初期フル同期と呼ぶ)。

The device is usable right away, so if you have no file system already, you should create one now.

実行後すぐにデバイスは利用可能になる。もしファイルシステムがない状態なら作ることが出来る。

Change from versions prior to DRBD 8

DRBD 8 からの変更されたこと

Prior to DRBD 8, what is now the –overwrite-data-of-peer option used to be –do-what-I-say. We changed the option because we found out that people mistakenly believed –do-what-I-say could be used to force any drbdadm command, regardless of its implications.

DRBD 8 から –do-what-I-say のために –overwrite-data-of-peer が利用される。このオプションを変更した理由は、その実装にも関わらず –do-what-I-say がすべての drbdadm コマンドを強制することに使えると勘違いする人たちがいることに気づいたからだ。

次: DRBD – Migrating DRBD resources [対訳]

iSCSI Initiator – Solaris 10

masakazu — Thu, 23 Aug 2007 13:56:20 +0000

Solaris 10 で iSCSI Initiator を設定したときのメモ。

Solaris 10 で iSCSI Initiator を利用する場合、 Solaris 10 が 1/06 以降のリリースである必要があります。

以下の文書を参考にしています。

Solaris のシステム管理 (デバイスとファイルシステム) >> 15. Solaris iSCSI イニシエータの構成 (手順)
- http://docs.sun.com/app/docs/doc/819-0386/fmvcd?a=view

Solaris では iSCSI Initiator を設定するためのコマンドとして iscsiadm というモノが用意されています。

iSCSI Initiator が iSCSI Target を利用しようとした場合、 iSCSI Initiator はネットワーク上の iSCSI Target を何らかの方法で認識しなければならないわけですが、 iSCSI Initiator が iSCSI Target を発見するための方法として、以下の 3 つの方法が用意されています。

静的デバイス発見 – iSCSI Target を静的に構成する方法
SendTargets による動的デバイス発見 – iSCSI Target の IP アドレスとポートの組み合わせから iSCSI Target を発見する方法
iSNS による動的デバイス発見 – iSNS サーバの IP アドレスとポートの組み合わせから iSCSI Target を発見する方法

ここでは SendTargets による動的デバイス発見で iSCSI Target を認識させます。

なお、前回の例で iSCSI Target として利用した Solaris Express では iSNS は利用できませんが、将来的には iSNS も実装することになっているようです。Solaris Express の iSCSI Target で iSNS が利用できるようになったら評価してみようと思っています。

まずは iSCSI Target を SendTargets の発見アドレスとして登録します。以下で 192.168.1.15 は iSCSI Target の IP アドレスで、 3260 はポート番号です。

bash-3.00# iscsiadm add discovery-address 192.168.1.15:3260

そして SendTargets を有効化します。

bash-3.00# iscsiadm modify discovery --sendtargets enable

これで 192.168.1.15 に登録された iSCSI Target が利用できるようになります。

iscsiadm コマンドで現在認識している iSCSI Target の一覧を表示することができます。

bash-3.00# iscsiadm list target
Target: iqn.1986-03.com.sun:02:5185308e-59e1-efe5-dcac-b4ce033808ba.target01
Alias: target01
TPGT: 1
ISID: 4000002a0000
Connections: 1
Target: iqn.1986-03.com.sun:02:66dbbe37-13fa-6637-c597-cf1f57b3d85c.target02
Alias: target02
TPGT: 1
ISID: 4000002a0000
Connections: 1
Target: iqn.1986-03.com.sun:02:861c6552-3a19-43b8-ccff-91ef396f98de.target03
Alias: target03
TPGT: 1
ISID: 4000002a0000
Connections: 1

試しに format コマンドを実行してみると、以下のようにデバイスが増えています。

bash-3.00# format
Searching for disks...done
AVAILABLE DISK SELECTIONS:
0. c1t0d0 
/pci@0,0/pci1000,30@10/sd@0,0
1. c2t0100000C29AE111100002A0046CD8AAFd0 
/scsi_vhci/disk@g0100000c29ae111100002a0046cd8aaf
2. c2t0100000C29AE111100002A0046CD8C5Dd0 
/scsi_vhci/disk@g0100000c29ae111100002a0046cd8c5d
3. c2t0100000C29AE111100002A0046CD8C5Ed0 
/scsi_vhci/disk@g0100000c29ae111100002a0046cd8c5e
Specify disk (enter its number):

あとは普通の SCSI ディスクと同じように扱えます。

例えば上記 3 つで raidz pool を作りたければこんな感じです。

bash-3.00# zpool create tank raidz c2t0100000C29AE111100002A0046CD8AAFd0 \
> c2t0100000C29AE111100002A0046CD8C5Dd0 \
> c2t0100000C29AE111100002A0046CD8C5Ed0
bash-3.00# zpool status
pool: tank
state: ONLINE
scrub: none requested
config:
NAME                                       STATE     READ WRITE CKSUM
tank                                       ONLINE       0     0     0
raidz1                                   ONLINE       0     0     0
c2t0100000C29AE111100002A0046CD8AAFd0  ONLINE       0     0     0
c2t0100000C29AE111100002A0046CD8C5Dd0  ONLINE       0     0     0
c2t0100000C29AE111100002A0046CD8C5Ed0  ONLINE       0     0     0
errors: No known data errors
bash-3.00# df -k
Filesystem            kbytes    used   avail capacity  Mounted on
/dev/dsk/c1t0d0s0    20093023 3593070 16299023    19%    /
/devices                   0       0       0     0%    /devices
ctfs                       0       0       0     0%    /system/contract
proc                       0       0       0     0%    /proc
mnttab                     0       0       0     0%    /etc/mnttab
swap                  684520     724  683796     1%    /etc/svc/volatile
objfs                      0       0       0     0%    /system/object
/usr/lib/libc/libc_hwcap1.so.1
20093023 3593070 16299023    19%    /lib/libc.so.1
fd                         0       0       0     0%    /dev/fd
swap                  683832      36  683796     1%    /tmp
swap                  683824      28  683796     1%    /var/run
tank                  144552      32  144462     1%    /tank

iSCSI Target – Solaris Express

masakazu — Mon, 20 Aug 2007 11:39:02 +0000

Solaris Express で iSCSI Target を設定したときのメモ。

将来的には Solaris 10 でも iSCSI Target の設定が出来るようになるようですが、現時点では Solaris Express でないと iSCSI Target は設定できません。

ちなみに iSCSI Initiator は Solaris 10 でも利用可能です。この Entry に続いて Solaris 10 で iSCSI Initiator を設定するためのメモを書く予定でいます。

以下の文書を参考にしています。

Solaris Express では iSCSI Target を設定するためのコマンドとして iscsitadm というモノが用意されています。

iSCSI Target Daemon を起動するために、まずは base directory を設定します。 base directory には Target と LU を構成するためのデータが格納されます。もし利用可能な ZFS pool があるようであればそこに格納した方が望ましい、と上記 “Creating your first target” には書かれていますが、ここではめんどくさいので普通に UFS 上の directory を指定します。

以下の例では /export/iscsi という directory を作成し base directory として設定しています。

bash-3.00# mkdir /export/iscsi
bash-3.00# iscsitadm modify admin -d /export/iscsi

base directory の設定が終われば Target を作成できます。

以下の例では 1GB の Target を disk01, disk02, … という名前で 5 個作成しています。

bash-3.00# iscsitadm create target --size 1g disk01
bash-3.00# iscsitadm create target --size 1g disk02
bash-3.00# iscsitadm create target --size 1g disk03
bash-3.00# iscsitadm create target --size 1g disk04
bash-3.00# iscsitadm create target --size 1g disk05

ps コマンドで確認してみると iscsitgtd という Daemon が起動していることがわかります。

bash-3.00# ps -ef | grep scsi
root   644   566   0 19:46:49 pts/1       0:00 grep scsi
root   627     1   0 19:15:12 ?           1:28 /usr/sbin/iscsitgtd

また base directory には以下のような file と directory が作成されています。

bash-3.00# ls -l /export/iscsi
total 24
-rw-------   1 root     sys         1183 Aug 20 19:15 config.xml
lrwxrwxrwx   1 root     sys           80 Aug 20 19:15 disk01 -> /export/iscsi/iqn.1986-03.com.sun:02:ed52dc45-b3f1-e1be-cec0-9572450a2fff.disk01
lrwxrwxrwx   1 root     sys           80 Aug 20 19:15 disk02 -> /export/iscsi/iqn.1986-03.com.sun:02:66528f32-b1b9-6b0a-cfe9-c8c98f8578dc.disk02
lrwxrwxrwx   1 root     sys           80 Aug 20 19:15 disk03 -> /export/iscsi/iqn.1986-03.com.sun:02:fd06731d-42b9-c1c9-bf0e-e4b41ccd8d17.disk03
lrwxrwxrwx   1 root     sys           80 Aug 20 19:15 disk04 -> /export/iscsi/iqn.1986-03.com.sun:02:6a93da14-9ddb-4913-e502-fd4f846be66a.disk04
lrwxrwxrwx   1 root     sys           80 Aug 20 19:15 disk05 -> /export/iscsi/iqn.1986-03.com.sun:02:32e0173b-5155-6722-e3d1-ae1cf42a71d6.disk05
drwxr-xr-x   2 root     sys          512 Aug 20 19:15 iqn.1986-03.com.sun:02:32e0173b-5155-6722-e3d1-ae1cf42a71d6.disk05
drwxr-xr-x   2 root     sys          512 Aug 20 19:15 iqn.1986-03.com.sun:02:66528f32-b1b9-6b0a-cfe9-c8c98f8578dc.disk02
drwxr-xr-x   2 root     sys          512 Aug 20 19:15 iqn.1986-03.com.sun:02:6a93da14-9ddb-4913-e502-fd4f846be66a.disk04
drwxr-xr-x   2 root     sys          512 Aug 20 19:15 iqn.1986-03.com.sun:02:ed52dc45-b3f1-e1be-cec0-9572450a2fff.disk01
drwxr-xr-x   2 root     sys          512 Aug 20 19:15 iqn.1986-03.com.sun:02:fd06731d-42b9-c1c9-bf0e-e4b41ccd8d17.disk03

config.xml の中身は次のようになっています。



disk01

0x0


iqn.1986-03.com.sun:02:ed52dc45-b3f1-e1be-cec0-9572450a2fff.disk01


... 以下  が disk02, disk02 ... の分記述されている ...

disk01(実態は iqn.1986-03.com.sun… という長ったらしい名前の directory) の中身はこんな感じです。

bash-3.00# ls -l /export/iscsi/disk01/
total 2098194
-rw-------   1 root     sys      1073741824 Aug 20 19:20 lun.0
-rw-------   1 root     sys          345 Aug 20 19:20 params.0

恐らく file size から lun.0 は scsi device image だと思われます。

params.0 の中身はこんな感じで、こちらは LU の設定情報でしょう。


0x200000
online
1
512
16
32768
4
7200
disk
SUN
SOLARIS
0100000c29ae111100002a0046c969cc

The new Mac mini – Enabling VT-x

masakazu — Sun, 19 Aug 2007 09:26:56 +0000

disable 化されてた新しい Mac mini の VT-x オプションだけど、 Parallels の Support Forum にあった以下の方法で enable 化できました。

How To Enable VT (aka VTX or VT-x) with rEFIt and vmx-var-set.efi
- http://forum.parallels.com/showthread.php?t=3273

rEFIt のバージョンが違ったからか “14. In rEFIt menu, select Console.” の部分が微妙に違ってたけど、それ以外は書いてある通りに進んでいけば OK でした。

CentOS 4 と CentOS 5 の x86_64 版インストールしてみたけど、問題なく動作してるみたいです。

The new Mac mini

masakazu — Tue, 14 Aug 2007 14:49:57 +0000

かなりまえから Mac mini が Core 2 Duo になったら買おう、って思ってたんだけど、ようやく Core 2 Duo になって新登場、ということで買いました。同じタイミングでリニューアルの iMac の方が大々的に広告されているので Mac mini の方はひっそりとしてますけど。

VMware Fusion も買ったので、これで LVS やら MySQL やら Asterisk やら Ruby on Rails の deploy やらの評価環境を手軽に準備できるようになったわけです。恐ろしい。

てか Core 2 Duo になるの待ってたのは VMware で 64bit Guest OS 動かしたいからだったんだけど(Core Duo は EM64T 非サポート)、どうも Firmware で VT-x 殺しているらしく 64bit Guest OS はそのままでは動作しない。 Parallels のサポートには rEFI を使って VT-x を enable 化する方法が載ってるんだけど… Core 2 Duo 版の Mac mini でもそのまま使えるのか不安なのでとりあえず様子見(32bit Guest OS で我慢)とします。

でも Mac mini で VT-x が disable 化されてたのは Bug だったらしく、後から出たやつはちゃんと enable 化されてるらしいんだけどなぁ… 戻っちゃったのかな？