Dec 30, 2006

VMware on AMD Athlon 64 X2のブリッジ接続時の通信性能

そうこうするうちにAMD Athlon 64 X2マシン上では、VMware Serverが安定稼動し、開発環境やWebサーバとして活躍しているわけだが、Hostからブリッジ接続しているGuest(VM)への通信性能が異常に悪いことに気がついた。一方でGuestからHost、GuestからGuest、Hostから他のHost(とその逆)、Guestから他のHost(とその逆)はまったく問題のない性能を示す。

NetperfでTCP STREAMのスループットを計測すると、Guest→Hostは427.37Mbpsに対して、Host→Guestは0.52Mbps。ざっとみて1000倍遅い。

調べたところ、Host NICにNVIDIA nForce Ethernet NICを使っている場合にはTCP Segmentation Offload(TSO)がenabledになっていると遅くなることがあるようだ。TSO機能はTCPやUDPのチェックサム計算、セグメンテーション処理などをNIC上で実行させることでCPUの負荷を削減するもの。Host上で、

# /sbin/ethtool -K eth0 tso off

しておけばTSOはdisableされるので速度は大幅に改善する。

Host(FC-6-x86_64)→Guest(FC-6-x86_64):

TSO on0.52Mbps
TSO off94.20Mbps

ちなみに「Guest→Host」の結果とIntelマシンでの結果も書いておく。これらの場合にはTSO offの場合の方が微妙に良い結果が得られているが、測定誤差の範囲内か、TSOによるCPU負荷の軽減効果を選択した方がよい程度のアドバンテージしかない。

Guest(FC-6-x86_64)→Host(FC-6-x86_64):

TSO on427.37Mbps
TSO off435.70Mbps

Host(CentOS-4.4-i386)→Guest(CentOS-4.4-i386):

TSO on90.96Mbps
TSO off94.69Mbps

Guest(CentOS-4.4-i386)→Host(CentOS-4.4-i386):

TSO on414.99Mbps
TSO off455.05Mbps

ところで、Guest→Hostが400Mbps以上出ているのにHost→Guestは90Mbps強しかスコアが出ていない。これにはVMwareのブリッジ接続の構造に由来する、ちゃんとした理由がある。

ブリッジ接続の様子は下の図のように書ける。Hostのeth0は外部スイッチに接続するとともにVMwareの仮想スイッチvmnet0にも接続しているのに対して、ゲストのeth0はvmnet0にのみ接続している。

このとき、Guest→Hostはvmnet0を介して直接に通信できる(赤字の経路)が、Host→Guestは一旦外部スイッチを経由し、Host eth0、vmnet0、Guest eth0を順次経由してしか通信できない(緑字の経路)。なぜそうなるかと言えば、(1)Guestがvmnet0に接続していても外部スイッチに接続していても、Hostのarp tableではeth0にGuestが繋がっているとしか表現しようがなく、(2)eth0にエミットされたパケットはプライマリーには外部スイッチに送出されるため、だ。Guestあてのパケットは、外部スイッチを経由して、promiscuous modeで動作するHost eth0にキャプチャされ、無事にvmnet0経由でGuest eth0に到達する。

したがってHost→Guestの通信速度は外部スイッチのスループットに制限される。上記の計測でHost→Guestが90Mbps強しか出ていなかったのは、つまりは外部スイッチが100Base-TXだったため。Gigabit Ethernet Switchを使えば、Guest→Hostと同程度まで高速化される見込みがある。

Dec 24, 2006

AMD Athlon 64 X2 5000+でちと遊ぶ。

年の瀬なのだが、パソコン工房に注文していたAMD Athlon 64 X2 5000+ PCが木曜日に届いたので暇を見つけていじっている。

Athlon64X2が更にパワーアップ!! パソコン工房BTO PC

↑をベースにメモリーを4GBに増設、大容量電源に換装した以外は標準構成のまま。

XenExpressで遊ぶ

まずは、XenSourceが最近公開したXenEnterpriseの無償版XenExpressを試してみた。Pacifica/SVM付きのAthlon 64 X2なので、Para-virtualizationとFull-virtualization (HVM)の両方が使えるはずなのでやってみた。配布されているインストールイメージを使ってまっさらなマシンにインストールするだけで、Xen 3.03のVMM + Dom0 Kernelが起動した状態まで一気にセットアップしてくれるという代物だ。あとは適当なコンソールマシンにAdministrator ConsoleをインストールしておけばXenマシンをリモートからモニター&コントロールできる。Administrator Consoleはなかなかイカス!モニタリングできるだけでもVMware Serverに比べて嬉しい。

Windows Server 2003用かWindows XP SP2用のXGT (XenSource Guest Template)を使えば、XenのFull-virtualizationを使ってCentOSでもFedora Core 6(以降、FC6)でも何でもインストールできる。ちょうどVMware Serverと大差ない手順になる。ただし、XenSource XenExpressではHVMをサスペンドすることができないようになっている(Xen 3.03に共通なのかもしれないがよく分からない)。試しにコマンドラインからxm saveしてみたらxm restoreできなくなってしまった…。

追求してみても良かったのだが、そもそもXenExpressはi386用のものしか提供されていないので、Athlon 64 X2的には無意義なのである。なぜならi386用のXen VMM上ではPara-でもFull-でも32bit OSのGuest OSしか動作できないようになっているようだからだ。この点、VMwareではHost OSがi386 OS、x86_64 OSのどちらであっても、Guest OSとして32bit OSと64bit OSの両方が(同時に)動かせるはずである。

お金を出しても買えないメインメモリ

冒頭のパソコン工房のページには以下のような記載がある。

DDR2規格で最大搭載可能4GBデュアルチャンネルメモリに対応

従来のDDRをさらに高速化したDDR2規格のメモリーを搭載。(中略)メモリー4GB搭載時にはマザーボードの仕様により、使用可能容量は3.2GB~3.5GBとなります。(グラフィックカードのご選択によって上下いたします)

だが、釈然としない。ASUSのM2N-SLI Deluxeのスペックページ(ASUSTeK Computer Inc.)を見ると8GBまで積めると書いてある(実際には2GB DDR2はコストパフォーマンスが悪すぎるが)。使用可能容量が3.2GB~3.5GBとなるのはi386 OSを使ったときに限られるのではないのか、と。そういう半端な話は許さんぞ、と。

…試してみる。

まず、FC6 (i386)でfree -m。

             total       used       free     shared    buffers     cached
Mem:          3545        181       3363          0         14        131
-/+ buffers/cache:         35       3509
Swap:         1983          0       1983

確かに3.5GBしか認識していない。パソコン工房の言うとおりだね。次にFC6 (x86_64)でfree -m。

             total       used       free     shared    buffers     cached
Mem:          3947        338       3609          0         30        233
-/+ buffers/cache:         74       3873
Swap:         1983          0       1983

402MBほど増えた、やっぱりね。ちなみにFC6 (i386)でkernel-xenを使い、そのDomain-0に全メモリーを割り当てた場合は以下の通り。

             total       used       free     shared    buffers     cached
Mem:          3920        939       2980          0        176        557
-/+ buffers/cache:        206       3714
Swap:         1983          0       1983

なぜ4GB使えてしまうのかはよく分からないが、こう表示される。x86_64の場合より小さいのはXen VMMが使っている分のメモリがあるからだろう。

…というわけで「お金を出しても買えないメインメモリ」を手に入れるには、迷わずx86_64環境を選択しなくてはならない。

FC6 (x86_64)にVMware Serverをインストールする

配布されているVMware ServerのRPMが、VMware-server-1.0.1-29996.i386.rpmしかないのでx86_64環境でちゃんと動作するのかどうかが少し心配だった。

結論から言えば何の問題もなかった。一部のx86_64 Linux Distributionでは嵌っている記事を割と見かけるが、少なくともFC6でもCentOS 4.4では何の問題も発生せず。拍子抜け。もちろん、VMware Server自体はi386 userlandで動作するのでVMの使用するメモリに関しては4GBないし3.5GBの制限がある。だが、用途として単体のVMに3.5GB以上のメモリを割り当てることはまずないので、この制限自体は問題とならない。

vmware-config.plに失敗するたびに/etc/vmware/locationsがどんどん長くなっていくのははなはだ不快なので、実行する前に↓くらいはやっておくのが常識。

# yum -y install xinetd
# touch /usr/src/kernels/2.6.18-1.????.fc6-x86_64/include/linux/config.h

おまけ

CentOS 4.4にするかFC6にするかはちょっと悩むところ。CentOSのstableさは魅力だが、(たまにとは言え)Xen遊びをするならRHEL5/CentOS5がリリースされるまではFC6にせざるを得ない。

AMD64上のVMwareで、2つ以上のCPUを有するVMを作ると、時計が狂いまくる問題はどうなったのか。
→勘違い。Athlon 64 X2でDual CPU VMを動作させることはできるがエミュレーション動作になる。実際にはSingle CPUしかないのでTSCがちゃんとカウントアップされないために時刻が大幅に遅れるようだ。これでは使い物にならないのでSingle CPU VMで動作させるのが正しい。

Dec 22, 2006

ブログバトラー、始めてみた。

流行っているみたいなので、ブログバトラーを始めてみた。

これだけだとなんなのでバトラーをリストするページを用意してみた。

BLOGBATTLERS COLOSSEUM

対戦相手を見つけるのが楽になるんじゃないか…っていう本当に本当の小ネタ。

Dec 18, 2006

マグロのある寿司以前に

大間の漁師のドキュメンタリーは面白いけどさ、いつから日本人はこんなにも(外国人に指摘されるほど)マグロへの信仰が篤くなってしまったのだろうか。

マグロのない寿司は考えられませんか【コラム】 ビジネス-最新ニュース:IT-PLUS

近海ものの獲れ獲れの魚料理を食べさせる店で、(付け合わせに)あまりにも味気ないマグロを出されたときほど落胆するものはないが、一度でもそういう経験をしたことがあるのならば、とうにマグロという偶像は崩壊している、しつくしていることに気が付くだろう。美味しく食べられるマグロはすでに十分高額なものになり、寿司屋でマグロを注文するという行為自体が躊躇われる(つまりはまともなマグロは高価に過ぎ、手頃な値段のマグロの味は保証できない)という状況にある。

翻って考えるに、そもそも日本人が「寿司」を日常的に食べるようになったこと自体が伝統的な大衆食文化の破壊である。生魚を食べるというのは伝統的に一部の階級・地域の人々の特権でしかなく、多くの人は野菜や穀類を中心に干した魚を食べてきた(干すことで旨みが増し、かつ保存に耐えるという単純かつ合理的な手法の恩恵を受けて)。実のところ西洋や中国でも大差はなく、ギリシャ悲劇にすらソーセージの原型らしきものが窺えるとは言え、大多数を占める庶民の食文化としての獣肉の常食はそれほど古くない時代に始まったことだ。無論、食を狩猟・採集に拠っていた時代の話をしているのではない。

食文化の破壊ははるか昔から緩やかに続いていて、とりわけ19世紀以降はそれが顕著になったであろうことは…あらゆる周辺状況に照らして…想像に難くない。70年代生まれの私にとってはすでに朝食の味噌汁・白米がトーストに取って代わられつつある段階にあったが、少し注意深い人ならその味噌汁ですら本来は味噌によって味付けされた一種の鍋物だったものが大幅に簡略化・形式化された一形態に過ぎないのだと容易に推定できるだろう。また一方で、まともな鰹節で出汁を摂ったおいしい味噌汁と出すと評判の料理屋だったとしても、魚を醤油と砂糖で甘辛く煮て酒膳に供するという、食の伝統を気ままに取捨選択する「折衷主義」が観測できないことの方がむしろ珍しい。

つまりは我々は好むと好まざるとに関わらず食文化の持続的な破壊の過程と折衷主義のただなかに自分の身を置いている。寿司にマグロを含めることに固執することもマグロを失うことを忌避することも意味のないことではないが、それ以外にここ数十年で失ったものの方がはるかに大きいのだということにも思いを馳せてよいのではないか。

例えば、鰹節は日本独特の水産加工品で今でも存在しているが、家庭で鰹節を削るという習慣はほとんど失われた。だから今や鰹節削り器を持っている家庭の方が少ないし、スーパーに行っても鰹節を丸ごと売っているのを探すのが難しいくらいだし、もし見つけたにせよどの産地のどんな鰹節がうまいのか見分けが付かない体たらくだ。それどころか、鰹節に背節・本節・亀節の三種があるとかいった基本的な知識も失われた。

また、いったいこのブログの読者でちりめんじゃこや小女子を常食している人はどれくらいいるだろうか。スーパーに行っても少量パックしか手に入らないのでは常食は無理というものか。しかしこれらは魚を容易に丸ごと食べられ、しかも佃煮のように過度の加熱を経ていない食品という点であらゆる魚食に勝ると言える。ほうれん草のおひたしに山盛りかけて食べればビタミン・鉄・マグネシウムに加え、カルシウムと蛋白質も効率良く摂取できるというほとんど完全食になるのだが、「あるある」で教えてくれない限りそれを励行する人はあまりいない。なぜそうなのかと言えば、これらを常食とする習慣が失われたからだ。

他にもいくらでも例は挙げられるだろうが、マグロに固執する前にやるべきこと、少なくとも日本の伝統食としてマグロの寿司を標榜するのならそれ以前に知識としてだけでも知っているべきこと、があるように思う。


って書いてきたけど私は全然LOHASな人ではない。破壊の過程と折衷主義のただなかで、伝統食の復権に向けてささやかな抵抗を示してもよいし、流行に身をやつして牛丼屋・回転寿司屋に通ったり肉じゃがのような伝統的でも何でもない料理を家庭の味と勘違いしてありがたがったりするのもよい。それは自由だと思っている。私はどちらかと言えば前者にシンパシーを覚えつつも、カップ焼きそばやハンバーガーを口にしないわけではない、一現代人である。

でも何だか最近痛切に意識するのだ、文明の傷跡のようなものを。結局は「老い」を認識し始めただけのことかもしれないのだが、予め失われるということと、失われたことに気がつかないということに恐怖を感じる。今まで目を背けてきた途方もない暗闇にうっかり目を向けてしまったような…。

Dec 11, 2006

Gmailの Mail Fetcher機能

さすがTechCrunch様は常人の斜め下を行くなあ。

TechCrunch Japanese アーカイブ » おお、Gmailはこれで完璧になった

Gmail以外のPOP3アカウントにアクセスできるという、たいていのWebメールでは実装されている機能を実現した、ということ。なぜ今まで実装されていなかったかと言えば、それは明らかに優先順位が低い機能だからに尽きるだろう。

そもそもこの機能を利用するメールアカウントとは、

  • 外部メールアドレス(Gmail)にフォワードする機能がなく、
  • 外部ネットワーク(Google)からアクセスできるPOP3サーバを持ち、
  • (定期的にしかPOP3アクセスしないために生じる)メッセージの到着遅延が容認でき、
  • 第三者(Google)にユーザIDとパスワードを躊躇なく委ねられる

というメールアカウントである必要がある。そんなメールアカウントがあるか?あったとしても重要か?

TechCrunchの中の人が既存のデスクトップアプリケーションを置き換えるGmailをご所望なことは分かる。当然、過去のメールをどこかのPOP3サーバに格納しておいてMail Fetcherで読み込ませれば、Gmail以前のメールもGmailに取り込むためのツールとしても利用できるのも分かる(もちろん、3GB弱程度では容量的に
全然足りない)。

分かるけど、私は一Google Accountにメッセージングをすべて集約できるという可能性を提示し、多くの人がそれで割と満足だということを認識したのが、Googleと我々にとっての重要な(しかし唯一の)スタディーだったのだと認識している。それ以外の点では徐々に完成に近づいてはいるものの決して満足できるものではない。だいたい今回の機能が実装されたからと言って、Gmailが
「完璧からはほど遠いもの」
であることには変わりない。例を挙げてみようか。Gmailの振り分け規則は厳密に言えばまともなルール一つ書けないpoorなものに留まっている。Gmailの振り分け後のアクションは制限され過ぎていてせいぜいラベルの付け替えくらいしかできないものに留まっている。Gmailの添付機能は伝統的なWeb UIに留まっているため、ファイルをひとつひとつブラウザのファイラー機能を使って指定する必要がある。Gmailのスレッド機能は(以下略)。

この機能の実装を最後の最後まで引っ張ったGoogleの判断は正しい、今回の仕事もgoodだ、...が完璧なんてものではない。こんなもので満足してはいけない。Googleにはあくまで「おかわり」を要求し続けよう。そのことがGoogleの力になり、我々の幸福にもつながる。TechCrunchの中の人の思い込みの激しさからも目が離せない。

Dec 8, 2006

貧乏人のためのboot-from-SAN (3) iSCSI InitiatorとVM編

このエントリーでは、VMware Serverが動作するホストマシン上にiSCSI Initiatorを設定し、iSCSIディスクをVMのPhysical Diskとして利用する方法について述べます。

以降の説明では、ホストマシンにはCentOS 4.4とVMware Server 1.01がインストールされているものとします。

なぜCentOSなのかといえば、RedHat Enterprise Linuxとバイナリ互換性があるので、VMware Serverのインストール時にカーネルモジュールのコンパイルが不要なので楽である(という理由でVMware Serverホストに使うことを私が好んでいる)からです。

iSCSI Initiatorのインストールと設定

まず、iscsi-initiator-utilsをインストールしておきます。

# yum -y install iscsi-initiator-utils
# /sbin/chkconfig iscsi on

次いで/etc/iscsi.confを編集します。iSCSI Targetのホスト名が「iscsi.as-is.net」、iSCSI Qualified Nameが「iqn.2006-12.net.as-is.iscsi:test」とすると、以下のように設定します。

DiscoveryAddress=iscsi.as-is.net:3260
Enabled=no
TargetName=iqn.2006-12.net.as-is.iscsi:test
  Enabled=yes

上の設定は、iSCSI Targetとして「iscsi.as-is.net」を参照し、iSCSI Qualified Nameが「iqn.2006-12.net.as-is.iscsi:test」のドライブのみをアタッチするという意味になります。DiscoveryAddressはIPアドレスで指定しても構いません。

この設定が済んだら/etc/init.d/iscsiを起動します。

# /etc/init.d/iscsi start

うまくアタッチできれば、以下のようなコンソールメッセージが表示されます。

iscsi-sfnet: Loading iscsi_sfnet version 4:0.1.11-3
iscsi-sfnet: Control device major number 254
iscsi-sfnet:host1: Session established
scsi1 : SFNet iSCSI driver
  Vendor: IET       Model: VIRTUAL-DISK      Rev: 0
  Type:   Direct-Access                      ANSI SCSI revision: 04
SCSI device sdb: 20971520 512-byte hdwr sectors (10737 MB)
SCSI device sdb: drive cache: write through
SCSI device sdb: 20971520 512-byte hdwr sectors (10737 MB)
SCSI device sdb: drive cache: write through
 sdb: unknown partition table
Attached scsi disk sdb at scsi1, channel 0, id 0, lun 0

iscsi-lsコマンドで確認することもできます。

# /sbin/iscsi-ls -l
*******************************************************************************
SFNet iSCSI Driver Version ...4:0.1.11-3(02-May-2006)
*******************************************************************************
TARGET NAME             : iqn.2006-12.net.as-is.iscsi:test
TARGET ALIAS            :
HOST ID                 : 1
BUS ID                  : 0
TARGET ID               : 0
TARGET ADDRESS          : 192.168.0.1:3260,1
SESSION STATUS          : ESTABLISHED AT Fri Dec  8 17:17:06 JST 2006
SESSION ID              : ISID 00023d000001 TSIH 700
*******************************************************************************
 
DEVICE DETAILS:
---------------
LUN ID : 0
  Vendor: IET      Model: VIRTUAL-DISK     Rev: 0
  Type:   Direct-Access                    ANSI SCSI revision: 04
  page83 type1: 494554000000000000000000650000008733000010000000
  page80: 0a
  Device: /dev/sdb
*******************************************************************************

/dev/sdbとしてアタッチされたことが分かりました。

iSCSIドライブのPhysical Diskとしての利用

VMware Serverでは(WorkstationやPlayerでも)VMはユーザ権限で動作します(Windows版の場合はAdministrator権限を持ったユーザで実行している場合が多いために意識しないかもしれませんが)。VMの仮想ディスクファイルがユーザ権限で作られているのはそのためです。

Physical Diskを利用する場合も同様で、/dev/sdbがVMオーナーのユーザ権限で読み書きできる必要があります。

# ls -l /dev/sdb
brw-rw----  1 root disk 8, 16 Dec  8 17:17 /dev/sdb

となっていることからdiskグループにVMオーナーを加えればよいことが分かります。

# /usr/sbin/usermod -a -G disk ogawa

それが済んだら、おもむろにVMware Server Consoleを起動し、File > New > Virtual MachineでNew Virtual Machine Wizardを開きます。

ほとんどの部分はデフォルトで問題ありませんが、以下の設定が必要です。

  1. Select The Appropriate Configuration
    → 「Custom」を選択。
  2. Select I/O adapter Types
    → 「LSI Logic」を選択(Fedora Core 5や6のインストーラではBuslogicのSCSIドライバが読み込まれないため、LSI Logicを選択する必要があります)。
  3. Select a Disk
    → 「Use a physical disk (for advanced users)」を選択。
  4. Select a Physical Disk
    → DeviceはiSCSIでアタッチしたドライブ「/dev/sdb」を設定。Usageは「Use entire disk」を選択。

あとは通常通り、VMの仮想CD-ROMドライブにインストールCDのISO imageをマウントして、VMを起動してインストールを開始するだけです。


貧乏人のためのboot-from-SAN (2) iSCSI Target編

貧乏人のためのboot-from-SAN (1) 導入編の続きです。このエントリーではソフトウェアiSCSI Targetの設定方法について説明しています。すでにiSCSI Targetを設定してあるという場合は省略できます。

iSCSI Target用マシンのインストール

ここではTarget用マシンにFedora Core 6をインストールして使うことにします。なぜなら、iSCSI Enterprise Targetの最新のstable版(0.4.14)や開発版を使うためにはKernel 2.6.14以降でなくてはならないからです。カーネルバージョンさえ保証できるなら他のディストリビューションでもまったく問題ありません。

iSCSI用に提供するための空き容量が必要です。すでに動作しているTarget用マシンがある場合にはiSCSI用にディスクを追加しても構いませんが、説明の都合上一個のディスクにFC6を新規インストールすることを前提に話を進めます。

標準ではFC6インストール時にHDDの大半がVolGroup00に割り当てられ、VolGroup00はLogVol00(/パーティション)とLogVol01(swap)にすべて割り当てられてしまいます。LogVol00のサイズを数10GB程度に修正してください。こうしておくと、VolGroup00のうち使われていない部分を後からiSCSI用のLogical Volumeとして簡単に切り出すことができます。パーティションの設定が済んだらそのままインストールを継続してください。

さてそうやって無事にインストールが済み、最低限の設定は済んだものとします。

iSCSI Enterprise Targetのインストール

SourceForge.net: iSCSI Enterprise Targetから最新のstable版をダウンロードするか、以下のように開発版をcheckoutします。

# svn co svn://svn.berlios.de/iscsitarget/trunk iscsitarget

ビルドやインストールはよくある手順どおり実施してください。注意点は、make install時にdepmodするので/sbinにパスが通っている必要がある点くらいです。

# make; make install
# /sbin/chkconfig --add iscsi-target
# /sbin/chkconfig iscsi-target on
# /etc/init.d/iscsi-target start

psコマンドでietdが動いていることが確認できれば問題ありません。

# ps -C ietd
  PID TTY          TIME CMD
 2691 ?        00:00:00 ietd

iptablesによるファイアウォールを導入している場合には、ietdが使うポートに穴を開けておく必要があります。/etc/sysconfig/iptablesに以下を追加して、/etc/init.d/iptables restartすればひとまずはよいでしょう。

-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 3260 -j ACCEPT

Logical Volumeの切り出しとTargetの設定

10GB分のLogical Volume(名前はtest)をVolGroup00から切り出すには、以下のようにlvcreateコマンドを実行します。

# lvcreate -n test -L 10G VolGroup00

正常に切り出せれば、lvdisplayコマンドで以下のように表示されるはずです。切り出したLogical Volumeは/dev/VolGroup00/testというブロックデバイスとして見えるわけですね。

# lvdisplay VolGroup00
(snipped)
  --- Logical volume ---
  LV Name                /dev/VolGroup00/test
  VG Name                VolGroup00
  LV UUID                AN1Q8q-h0Ty-GORO-0lJB-2s0a-4Ev2-GyjLng
  LV Write Access        read/write
  LV Status              available
  # open                 1
  LV Size                10.00 GB
  Current LE             320
  Segments               1
  Allocation             inherit
  Read ahead sectors     0
  Block device           253:2

次にTargetの設定を行います。

まず、TargetのIDとiSCSI Qualified Nameを決める必要あります。IDはそのiSCSIサーバでユニークな1以上の整数値です。ここでは「100」とします。iSCSI Qualified Nameは、グローバルにユニークである必要があるため、タイプ識別子「iqn.」、ドメイン取得日、ドメイン名、ドメイン取得者が付けた文字列を付けることになっています(RFC 3720 - Internet Small Computer Systems Interface (iSCSI) (IETF/rfc3720))。ここでは「iqn.2006-12.net.as-is.iscsi:test」にしておきます。

新しいTargetを作るにはietadmコマンドを使って以下のように実行します。

# ietadm --op new --tid=100 --params Name=iqn.2006-12.net.as-is.iscsi:test
# ietadm --op new --tid=100 --lun=0 --params Path=/dev/VolGroup00/test

/etc/ietd.confに書く方法もありますが、とりあえずテストということで。ユーザ認証を追加することもできますが、とりあえずテストということで。

ietadmコマンドで行った設定は/proc/net/iet/volumeを参照することで確認できます。

# cat /proc/net/iet/volume
tid:100 name:iqn.2006-12.net.as-is.iscsi:test
        lun:0 state:0 iotype:fileio iomode:wt path:/dev/VolGroup00/test

複数のiSCSIドライブが必要な場合には、好きなだけlvcreateとietadmを繰り返すことになります。

これでiSCSI Targetに関する作業は終了です。


Dec 7, 2006

貧乏人のためのboot-from-SAN (1) 導入編

かなり前にこんなことを書いたのですが、もう実現された方はいるでしょうか。

ホストにiSCSI initiatorを設定してVMのディスクイメージをやっすくでっち上げたiSCSIストレージサーバ上に置いて、general public向け"Boot from SAN"を実現するのとかどうよ、と思っている。
Ogawa::Buzz: VMware Server 1.0.1で遊んでみる

VMware Server、Workstation、PlayerのVMのディスクイメージの保持の仕方にはいくつかバリエーションがあり得ます。

  1. ホストマシンのローカルディスクにVirtual Diskを作成する(最も一般的な構成)
  2. ホストマシンのローカルディスクのパーティションをVMがPhysical Diskとして利用する
  3. NFSサーバ、iSCSIサーバなどが提供するパーティションをホストマシンがアタッチ(マウント)し、その中にVirtual Diskを作成する
  4. iSCSIサーバが提供するパーティションをホストマシンがアタッチし、そのディスクをVMがPhysical Diskとして利用する

1.と3.はVirtual Diskを利用するため、ディスクI/Oの操作自体のオーバーヘッドがあります。また、1.と2.はローカルドライブへのアクセスで済みますが、多数のホストマシンがある環境ではオペレーション自体の(人的)コストが大きくなり得ます。これに対し、3.と4.はネットワークごしのアクセスによるオーバーヘッドがありますが、ネットワークの高速化の恩恵を享受できますし、オペレーションコストは小さく抑えられます。また、ローカルのI/Oリソース競合による性能低下がリモートアクセスのオーバーヘッドによる性能低下を上回るという現象も、デスクトップPC環境の例を挙げるまでもなく、よく見かける現象だと言えます。

総合的に考えると、4.がそれなりにリーズナブルな解だと言えるでしょう。

さて、1.~3.の実現方法は比較的自明ですが、4.はそうでもありません。実際にやってみたら案外簡単にできてしまったので、ここではその方法について説明します。ちょっと長いので2,3回に分けて書きます。


はじめに

ここでは、VMware ServerのVirtual Machine(以降、VM)をiSCSI bootすることを考えます。

そもそもVMware ESX ServerではネイティブにVMのiSCSI bootに対応していますが、VMware Server、Workstation、Playerは対応していません。単体サーバで少数のVMをサービスしている従来の構成から考えれば、VMがiSCSI Initiatorになるというのが安直で自然な拡張と言えますが、ストレージの一部をストレージサーバ上にオフロードできてもブートイメージを含めてオフロードすることはできません。

しかし、ちょっとだけ見方を変えて、VMのホストマシン(VMware Serverの動作するマシン)がiSCSI Initiatorとして機能すれば、iSCSI bootに準じた構成を採ることができ、しかも直感的には思いがけず効率が良さそうな印象があります。印象が…というのは定性的な議論だけでは本当に効率が良いのかどうかは判別できないからです。

論より証拠、試してみました。

いろいろな構成があり得ますが、ここでは試しに、

  1. ストレージサーバ上のハードディスクのスライスもしくはLogical Volumeを切り出して、ソフトウェアiSCSI Targetを使ってiSCSIデバイスとしてサービスする
  2. VMware ServerホストはInitiatorとなり、iSCSIデバイスをローカルSCSIデバイスとしてアタッチする
  3. VMware Server上のVMはローカルSCSIデバイスをPhysical Diskとして利用する

という構成を考えます(下図参照)。

この構成の利点を挙げてみると、

  • VMwareの使うストレージがストレージサーバ上で集中管理される。ストレージサーバのLVMの機能を使ってミラーリングやバックアップを行える。
  • VMware ServerホストのディスクI/Oによるボトルネックが解消される。
  • VMware ServerのVirtual Diskのオーバーヘッドがほとんどなくなる。
  • VMのプロビジョニングが容易になる。例えば、負荷に応じて一方のVMware Serverホストから他方のホストにVMの動作イメージを移動するとか、LVMミラーリングで作られたLogical Volumeコピーを他のVMが利用するとか、いろいろ夢が広がる。

といった点になります。

もちろん、単体サーバでVMをサービスするのに比べて構成が複雑になるとか、民生用にはGigabit Ethernetしか使えないのでストレージネットワークとしての性能がしょぼいだとか、ストレージサーバの負荷はどうすんのとか、問題点もないわけではありません。そうした定性的な議論はさておき、単に面白そうというだけでもやってみる価値があります。


Dec 5, 2006

AddToHatenaBookmark Plugin 0.03公開

エントリーを公開したときに、そのエントリーをはてなブックマークに自動的にポストするAddToHatenaBookmark Pluginを久しぶりにアップデートしました。

AddToHatenaBookmark - ogawa - Google Code

このプラグインは、公開状態のエントリーを更新したり、新規に公開状態のエントリーを追加したときに、そのエントリーを、はてなの提供するAtom APIを用いて、自分のはてなブックマークに追加するものです。Movable Type 3.2以降(日本語版)でしか動作しません。また、もちろんはてなのアカウントが必要です。

0.03では、Movable Type 3.3以降で導入されたエントリー「タグ」をブックマークへのタグとして設定するようになっています。従来のキーワード欄を用いたタグ表記も継続して利用できます。両方設定した場合には両方とも設定されるという安心設計。

詳しくは上記URL、またはMOVABLETYPE PLUGINS DIRECTORY本を参照してください。

Dec 4, 2006

Movable Type Plugin Directory

Movable Typeのプラグインを紹介している「Movable Type Plugins Directory」という本をいただきました。私の作ったプラグインも何点か紹介していただいています。作者本人も説明しづらい微妙な機能をコンパクトに分かりやすく説明していただいています(と大人のコメント)。

About Me

My Photo

つくばで働く研究者

Total Pageviews

Amazon

Copyright 2012 Ogawa::Buzz | Powered by Blogger
Design by Web2feel | Blogger Template by NewBloggerThemes.com