Hatena::ブログ(Diary)

Procrastination Log

16 November 2010 (Tue) OpenIndiana (旧OpenSolaris) で iSCSI のボリュームを複数公開する

OpenIndiana (旧OpenSolaris) で iSCSI のボリュームを複数公開する

 OpenIndiana (旧OpenSolaris) で iSCSI のボリュームを複数公開するを含むブックマーク  OpenIndiana (旧OpenSolaris) で iSCSI のボリュームを複数公開するのブックマークコメント

はまったので備忘メモ.

(11/18: stmfadm への sbdadm の機能統合についての追記と,view 関係の記述を整理)

  • OpenIndiana に OpenSolaris (snv_134 以前) からアップグレードすると,古い iSCSI フレームワーク (shareiscsi) は使えなくなります.
  • OpenSolaris で iSCSI を使っている人は,OpenIndiana へのアップグレード前に (新 iSCSI フレームワークである) COMSTAR について調べておきましょう.
  • COMSTAR を使って複数のボリュームを iSCSI で公開するときは,それぞれを別ターゲットにするのではなく,それぞれのボリュームに対して LUN (logical unit number, 論理ユニット番号) を振って,1 つのターゲットにぶらさげる方法が楽なようです.この方法の概要はこの記事に示します.
  • なんらかの理由でターゲットを分けたい場合は,COMSTAR の target group という概念と戦ってください,ということになるらしいです.私は試していないので詳しくは語れません.

OpenSolaris と OpenIndiana

自宅のデータ倉庫のサーバーには,OpenSolaris を使っている.なんといっても ZFS が幸せすぎるため.

ディストリビューションとしての OpenSolaris は,Oracle による Sun 買収のごたごたでアップデートが止まってしまっていたけど,実質的な後継ディストリビューションとして ”OpenIndiana” が開始された.

しばらく OpenSolaris のままで使っていたけれど,ちょっと興味があって OpenIndiana にアップグレードしてみることにした.ZFS のご利益で,もし何か問題があってもすぐにアップグレード前の状態に戻せるし.

あっけないくらいにアップグレードはなんのトラブルもなく成功.したようにみえた.

iSCSI ではまる

上記のサーバーは,VirtualBox の仮想マシン用の仮想 Disk を iSCSI で 2 台分公開していた.

なお,OpenSolaris の (古くからある) iSCSI ターゲット機能 (shareiscsi) は,1 つの iSCSI ディスクに 1 つの iSCSI ターゲット (リモートから見える名前) を割り当てるポリシーだった (たぶん) ので,そのように運用していた.つまり,2 つのターゲットを公開して,それぞれ別の iSCSI ディスクが割り当てられている状態.

ちなみに,この (古い iSCSI の) iSCSI ターゲットの作り方はとても簡単.ZFS の pool から iSCSI の領域を切り出して,その領域の shareiscsi というプロパティを on にするだけ.

つまり,元からある ZFS の pool 名を tank とすると,

  1. zfs create -V 20g tank/iscsi1 (20g は切り出すサイズ.この場合 20GB)
  2. zfs set shareiscsi=on tank/iscsi1 (切り出した iscsi1 を公開)

これだけ.同じことを tank/iscsi2 に対して実行すると,iscsi1, iscsi2 がそれぞれ iSCSI target として公開されることになる.

ところが,アップグレード後,VirtualBox から仮想マシンを起動しようとして,上記の iSCSI target がまったく見えない状態になっていることに気がついた.shareiscsi プロパティの値がリセットされてしまったかと,zfs set shareiscsi=on tank/iscsi1 ともう一度実行してみたところ,

cannot set property for 'tank/iscsi1': invalid property 'shareiscsi'

"invalid property" ですか….orz

新 iSCSI フレームワーク COMSTAR

どうやら,OpenIndiana では,Solaris 用に開発が進められていた新しい iSCSI フレームワークである COMSTAR (Common Multiprotocol SCSI TARget) というものに完全移行してしまい,shareiscsi は捨てられてしまったらしい.

ひょっとして,何かほげればまだ shareiscsi も使えるのかもしれないけれど,どうせ自宅のお遊びだし COMSTAR に挑戦してみることにした.

ただ,COMSTAR はいろいろと柔軟なことができるようになっているかわりに手順が多少面倒くさい.

こちらの記事によると,以下の手順が必要 (説明上,最後の 2 つの手順の順番は入れかえてあります).

  1. 必要なパッケージのインストール
  2. iSCSI 用のボリュームの作成
  3. ストレージプールにLU (論理ユニット) の作成
  4. iSCSIターゲットの作成
  5. viewの追加

パッケージのインストールと,ボリュームの作成,ターゲットの作成は良いとして,LU とか view って何?と戸惑いつつ,COMSTAR に挑戦.

ボリュームの作成

これは shareiscsi と変わらず.すでに作成ずみなのでパス.

LU の作成

COMSTAR で公開するボリュームは LU (logical unit) として COMSTAR に登録してあげる必要がある.LU の登録は,sbdadm create-lu コマンドを用い,

sbdadm create-lu /dev/zvol/rdsk/tank/iscsi1

のように行う.これにより,LU の識別子として GUID が割り当てられる.tank/iscsi2 も同様に LU として登録する.それぞれ,以下の GUID が割り当てられたとする.

tank/iscsi1
600144F00800270450CA4CE1B9780001
tank/iscsi2
600144F00800270450CA4CE28D7D0002

LU による抽象化のご利益は謎.こういう多段の抽象化って,多用するとシステムの見通しがとても悪くなると思うんだけど.

ターゲットの作成

LU を作っただけでは当然リモートから見えないので,iSCSI のターゲットを作成する必要がある.複数ターゲットの使い分けとかアクセス制御とかの COMSTAR の高度な機能を使おうとしなければ,これは簡単.以下の単純なコマンドで作成できる.

itadm create-target

すると,たとえば以下のようなターゲット名 (iSCSI name) が割り当てられる.

Target
iqn.1986-03.com.sun:02:b0673d37-14b2-ec55-cec4-cd169d404b93

ところで,このあたりを触っているといつも思うんだけど,この IQN だか DQN だかの命名規則を考えた人って,とても頭が (自粛) だと思う.

なお,ここでターゲットは 1 つしか作らないのが「簡単に複数ボリュームを iSCSI で公開する」ミソになる.理由は後述.

view の追加

上記の「ターゲットの作成」のところで,「単純なコマンド,って単純すぎない?ターゲットへの LU の割り当てとかはどうするの?」と疑問に思った人は鋭い.ここで本来は view という概念 (と target group という概念) が出てくる.ただ,ターゲットを 1 つしか公開しない (注:後述のように,ターゲットが 1 つでも複数の LU を公開できます) のであれば,何も考えずに以下のコマンドを実行すればよい.

stmfadm add-view 600144F00800270450CA4CE1B9780001 (tank/iscsi1 の GUID)

stmfadm add-view 600144F00800270450CA4CE28D7D0002 (tank/iscsi2 の GUID)

これで,どちらの LU も「すべてのターゲットから」見えるようになる.これで作業は終わり.どちらのボリュームも「ターゲットの作成」で作った iSCSI ターゲット経由で使えるようになる.

それにしても,sbdadm だとか itadm だとか stmfadm だとか,なんでコマンド名がこうもばらばらなんだろう (11/18: id:tokuhy さんに,現在では stmfadm に sbdadm の機能が統合されている旨を教えていただきました).

どうやって 2 つの LU を見わけるの? (確認)

実は stmfadm add-view のとき,(実行結果では何も言ってくれないけれど) それぞれの LU に対して LUN (logical unit number, 論理ユニット番号) が割り当てられている.これは,stmfadm list-view で確認できる…のだけど,全部の LU の LUN を一括して参照する手段がなくて不便.

stmfadm list-view -l 600144F00800270450CA4CE1B9780001

View Entry: 0
    Host group   : All
    Target group : All
    LUN          : 1

stmfadm list-view -l 600144F00800270450CA4CE28D7D0002

View Entry: 0
    Host group   : All
    Target group : All
    LUN          : 2

それぞれ,LUN=1, LUN=2 が割り当てられていることを確認できた.

ターゲットを 2 つ作ろうとすると (余談)

ここまでで目的は達成したのだけど,ちょっと余談.

shareiscsi と同じような環境を作ろうとすると,2 つターゲットを作ってそれぞれに LU を 1つずつ割り当てたくなる.しかし,これをやろうとして itadm で 2 つターゲットを作成してしまうと,2 つのターゲットそれぞれに LU が 2 つずつ割り当てられているように見えるという,かなり直感的な理解が困難な状態になる.

これは,stmfadm add-view のデフォルトの振る舞いによる.期待したようなふるまいをさせるには,view の概念をきちんと理解する必要がある.

いろいろ調べてなんとかわかったつもりなところによると,view というのは,「ある LU が,どの target group に属する target (ないし host group という別の概念のモノ) から見えるか」を制御するための概念 (LU をターゲットに割り当てる概念でないことに注意) になる.ということで,target group というまた別の概念を理解できないと view もきちんとは理解できないのだけど,そこまで説明する気力も試す動機もない (私の環境では target は 1 つで困らないし) ので,target group の説明はパスします.

ついでにもう一つ愚痴.難しいことを柔軟に実現できるフレームワークってすごいと思うけど,簡単なことは簡単にできるようにするような設計も大事だと思うんだけどなぁ.

おまけ:VirtualBox から使う

VirtualBox からこれらの iSCSI ボリュームを利用するためには,VBoxManage addiscsidisk コマンドを使う."--lun" オプションで陽に LUN を指定する.こんなかんじ.

VBoxManage addiscsidisk --server x.x.x.x --target iqn.1986-03.com.sun:02:b0673d37-14b2-ec55-cec4-cd169d404b93 --lun 1

VBoxManage addiscsidisk --server x.x.x.x --target iqn.1986-03.com.sun:02:b0673d37-14b2-ec55-cec4-cd169d404b93 --lun 2

仮想メディアマネージャーから addiscsi した iSCSI ボリュームが見えるようになる.

説得力ないかもしれませんが

つい COMSTAR の体系に対する文句がいろいろ出てしまいましたが,それはともかくとして iSCSI + ZFS on OpenSolaris (OpenIndiana) の環境はとても快適です.また,COMSTAR になって iSCSI の処理が軽くなった?ようでもあるので,CPU が非力になりがちなデータ倉庫にはうれしいところです.本記事が,試してみようかな,と思われた方の参考に少しでもなれば幸いです.

tokuhytokuhy 2010/11/17 23:25 正確なビルド番号はわかりませんが、sbdadmコマンドはstmfadmコマンドに統合されています。
OpenIndianaであればsbdadmコマンドを使わなくても全て設定できるようになっています。OpenSolais b134でも同様でした。
書式もsbdadmがstmfadmに変わるだけでそのままでいけるはずです。
ご参考までに。。。

tera-ptera-p 2010/11/18 23:55 tokuhyさん,上記の試行錯誤の際には,とても参考にさせていただきました.この場を借りて感謝いたします.
また,sbdadm が不要になった旨の情報ありがとうございます.man stmfadm で stmfadm に sbdadm 相当のコマンドが用意されているのは気付いていたのですが,COMSTAR Administration の解説が sbdadm を使っていたので,変な不確定要因をまぜたくなくて sbdadm のまま通してしまいました.一つ混乱の要因がなくなってよかったです.ただ,どうせなら itadm も統合してしまって良いような気もしますが (個人的には,こういう「コマンドを持つコマンド」ってそもそも好きではないのですが,どうせやるならフレームワークが提供する機能すべてを一つのコマンドで統一的に扱ってほしい;中途半端が一番困る).
なお,ご指摘を頂いてあらためて調べてみたところ,統合されたのは Kazuyuki Sato さんの「前回の COMSTAR ネタに刺激されてしまったので、オレも COMSTAR を使ってみた。」(http://www.slideshare.net/satokaz/comstar-comstar) によると b115 からのようです.けっこう前なんですね….