Ogawa::Buzz: iSCSI

ラベル iSCSI の投稿を表示しています。すべての投稿を表示

2007/05/11

PXE + iSCSIブートするための試行錯誤に費やされた GW前半のメモ

連休中に書いたメモ・その2。編集せずにManchesterからお送りします。

PXEブートしたカーネルからNFS rootやiSCSIデバイスをroot mountすることでディスクレスブートマシンを実現できることは知られているし、枯れた技術でもある。重要なのは、特殊な機材がなくても、PXE compliantなネットワークインタフェースを持つマシンなら何であっても(それが実マシンであっても仮想マシンであっても)「擬似的に」iSCSIブートできるということである。

Stateless Linuxは、この技術をコアにディスクレスクライアントのディスクイメージやプロファイルを中央集中的に管理するマネージャ機能などを提供するもののようだ。が、どの記事を見ても全貌はさっぱり分からない。Component-wiseに「できたもの」からStateless Linuxという名前を付けていくだけなのかもしれない。正式にFedora CoreやRHELのリリースに包含されるようになればもう少し分かりやすくなるだろうが。

それはさておき、StatelessLinuxiSCSIRoot - Fedora Project Wikiには、iSCSIブート用のinitrd.imgを作る方法が書かれているのだが、私が試した限りではちっともうまくいかなかった。

おおまかに言って三つの問題があった。

一つは、StatelessLinuxiSCSIRootにあるとおりに、mkinitrd --net-dev eth0して作ったinitrd.imgに含まれるinitスクリプトに、

network  --device eth0 --bootproto dhcp

と書かれていることだ。この部分はDHCPサーバからIPアドレスなど取得して、ifconfig upしてくれたり、route addしてくれたりするのだと思うのだが、Fedora Core 6ではこれがまったく動かない。dhcpdが動作しているマシン上でtcpdump port dhcpcしていると、PXEのブートシーケンス(dhcpによってIPアドレスなどを確定してカーネルやRAMディスクのイメージをダウンロードする必要がある)ではパケットダンプが観測されるが、initスクリプトの実行部分ではまったく観測できない。なんなんだこれは。

もう一つは、StatelessLinuxiSCSIRootの方法だと、initスクリプトに/sbin/iscsistartを実行する部分が生成されなければならないはずなのだが、実際にはうまく生成されない。いくつか思い付く理由も対策もあるのだが、mkinitrdを改造する必要があるのでとても面倒くさい。

もう一つの問題は、上ができたとしてもiscsistartへの引数がinitrd.img内にスタティックに書き込まれてしまうことである。これだとホストごとに同じ手続きでmkinitrdしなくてはならない。NFS rootの場合と同様に、カーネル引数に渡したオプションを解釈してiscsistartしてくれればよいのだが。

ちょっとNFS rootの補足をすると、rootファイルシステムはread-only mountする(つまり複数のNFS rootクライアントが同じrootを共有する)のに加え、設定を同じくするホスト群のinitrd.img/vmlinuzは共通化して、カーネル引数で渡した情報に基づいてクライアントは各自の設定を行うようになっている。iSCSIブートの場合には、クライアントごとにrootに使用するiSCSIデバイスが異なるのでread-write mountする点に注意することを除けば、NFS rootの場合とほとんど同じようにできるはずだ(むしろ簡単なはず)。

こうした状況にめげずに何とか便利なツールはないものかと探していたわけなのだが、あまりいいツールがない。

iSCSI-initは、カーネル引数を解釈してiSCSIデバイスをアタッチしてくれるカーネルモジュールだが、Open-iSCSI以前のLinux-iSCSIにしか対応していない。CentOS 4.xの場合には使える。

Diskless / remote boot with Open-iSCSI - WPKG - Windows software deployment toolは、initスクリプトそのものを自作のものに置き換えるものでOpen-iSCSIに対応している。その自作スクリプトが難ありで、カーネル引数でホストのIPアドレスなどを指定しなければならないという困った仕様。

正常動作し、カーネル引数を使ってiSCSIの設定を行うinitrdを生成するツールを作るだけでGWの前半を潰してしまった。不慣れなもので。暇があれば続編を書く。

2007/01/09

貧乏人のためのboot-from-SANの後日談

Ogawa::Buzz: 貧乏人のためのboot-from-SAN (1) 導入編の続きで、「(4) 性能比較編」を書くつもりだったのだが、その前にもうちょっとpreciseな測定を行って共著で論文を出しておこうということになり、昨年末あたりDownload VMware Server - EULAを読んでみていたら大変なことが分かってしまった。

3.3 Restrictionsの後半に、

You may use the Software to conduct internal performance testing and benchmarking studies, the results of which you (and not unauthorized third parties) may publish or publicly disseminate; provided that VMware has reviewed and approved of the methodology, assumptions and other parameters of the study. Please contact VMware at benchmark@vmware.com to request such review.

と書いてある。簡単に訳すと、

あなたはこのソフトウェア(VMware Server)を使って内部的に性能試験やベンチマーク調査を行うことができます。また、あなた（と許可されたサードパーティ）は、その調査結果を、出版・公表することができます。ただし、VMwareがその調査の方法・前提条件・その他パラメータをレビューし承認した場合に限ります。このレビューを要求するにはVMware(benchmark@vmware.com)にコンタクトしてください。

今から言うよ！死語言うよ！

がびーん。

ま、まあブログにベンチマーク結果を載せるくらいなら(後から削除できるので)大目に見てもらえるだろうけど、論文だとか雑誌の記事だとか書籍だとかでは正規の手続きを踏まないとまずい。明らかにまずい。

そういうわけで同僚が調査の方法・前提条件・その他パラメータなどを添付した測定データを添付してVMwareに問い合わせてみたところによると、final manuscriptを送ってくれとか言われてしまった始末。

け、けどね、日本語の論文の場合VMwareはレビューできるのかいな。できないから英訳しろって言われたらやるけど、それって日本語のfinal manuscriptとは逐一異なるものになるわけで正確にはレビューを受けたことにはならないと思われる。一方で仮に日本語のfinal manuscriptを渡すことができたとして、VMwareがそれを日本語のエキスパートに翻訳させてレビューするのだとすると、3日でやれって言っても無理な話だよね。じゃあ最初から英語で書いとけってことなんだけど、

面倒くさい。

ていうか、英語にしろ日本語にしろ一本書くたびにレビューしてもらわなきゃならないかと思うと頭痛い。こういうときどうしたらいいの？
＞同業者(特にこういうことがありがちっぽい中央林間にある外資系企業の研究所の中の人とか)

2006/12/08

貧乏人のための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を開きます。

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

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

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

貧乏人のためのboot-from-SAN (1) 導入編
貧乏人のためのboot-from-SAN (2) iSCSI Target編
貧乏人のためのboot-from-SAN (3) iSCSI InitiatorとVM編 (このエントリー)
貧乏人のためのboot-from-SAN (4) 性能比較編 (気が向いたら書く予定のエントリー)

貧乏人のための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に関する作業は終了です。

貧乏人のためのboot-from-SAN (1) 導入編
貧乏人のためのboot-from-SAN (2) iSCSI Target編 (このエントリー)
貧乏人のためのboot-from-SAN (3) iSCSI InitiatorとVM編
貧乏人のためのboot-from-SAN (4) 性能比較編 (気が向いたら書く予定のエントリー)

2006/12/07

貧乏人のための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のディスクイメージの保持の仕方にはいくつかバリエーションがあり得ます。

ホストマシンのローカルディスクにVirtual Diskを作成する(最も一般的な構成)
ホストマシンのローカルディスクのパーティションをVMがPhysical Diskとして利用する
NFSサーバ、iSCSIサーバなどが提供するパーティションをホストマシンがアタッチ(マウント)し、その中にVirtual Diskを作成する
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に準じた構成を採ることができ、しかも直感的には思いがけず効率が良さそうな印象があります。印象が…というのは定性的な議論だけでは本当に効率が良いのかどうかは判別できないからです。

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

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

ストレージサーバ上のハードディスクのスライスもしくはLogical Volumeを切り出して、ソフトウェアiSCSI Targetを使ってiSCSIデバイスとしてサービスする
VMware ServerホストはInitiatorとなり、iSCSIデバイスをローカルSCSIデバイスとしてアタッチする
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しか使えないのでストレージネットワークとしての性能がしょぼいだとか、ストレージサーバの負荷はどうすんのとか、問題点もないわけではありません。そうした定性的な議論はさておき、単に面白そうというだけでもやってみる価値があります。

貧乏人のためのboot-from-SAN (1) 導入編 (このエントリー)
貧乏人のためのboot-from-SAN (2) iSCSI Target編
貧乏人のためのboot-from-SAN (3) iSCSI InitiatorとVM編
貧乏人のためのboot-from-SAN (4) 性能比較編 (気が向いたら書く予定のエントリー)

登録: 投稿 (Atom)