iSCSIを利用しようその2

というわけで、Ubuntu LinuxをiSCSIイニシエータ(使用する側)に仕立てあげよう。

まずはNAS側で、10GB程の新規LUN(Logical Unit Number:前回の図で言うところの、仮想HDDだ)を作成、併せてiSCSIターゲットを新規作成し、両者を結びつけておこう。
これは、NASの製品によって手順が違うので、各自NASのマニュアル等を参照して欲しい。

また、その時にiSCSIターゲットのIQNというのもメモしておこう。

IQNというのは、iSCSIターゲット、イニシエータ両方とも持つ特殊な名前で、iSCSIは相手の識別にこのIQNというのを使用する。
IQNという名前は決まったフォーマットで、iqn.YYYY-MM.com文字列:任意の文字列-文字列 みたいなちょっと面倒くさい名前だ。
これは大抵自動生成されるはず。一つのiSCSIネットワーク内でIQNが重複すると危険なので、自動生成されたものをそのまま使おう。

で、Ubuntu Linux側だ。
Ubuntu LinuxでiSCSIイニシエータを実現するパッケージはopen-iscsiというヤツだ。
こちらをインストールしてしまおう。
$ dpkg-query -l open-iscsi
なんと既に入ってたよ。

もしインストールされてなかったら、
$ sudo apt-get update
$ sudo apt-get --simulate install open-iscsi
$ sudo apt-get install open-iscsi
$ dpkg-query -l open-iscsi
でインストールしておこう。

インストール出来たら、自分自身(Ubuntu Linux自身)のiSCSIのIQNを確認しておきたい。
open-iscsiでは自分自身のIQNは、
/etc/iscsi/initiatorname.iscsi
というファイルが自動生成されて、そこに記録されるようだ。
中身を見ておこう。
$ sudo cat /etc/iscsi/initiatorname.iscsi

IQNが確認できたら、NAS側のiSCSIターゲットの設定で、そのIQNからのアクセスを許可しよう。(読み書き両方可能にしておこう)
これも、各NASのマニュアルを参考に。なお、私のNASでは「マスキング」という定義の名前だった。
また、NAS側で「CHAP認証」という機能が使えるかもしれないが、これは使わないようにする。
(ユーザ名・パスワードによるアクセス制御をかけるより、IQNのマスキングでアクセス制御を掛けた方が、遥かに楽だし、CHAPによるアクセス制御を掛けるメリットはほとんど無いはず。)

次は、iSCSIイニシエータ(Ubuntu Linux)側から、iSCSIターゲットを検出させる。
これはiscsiadmコマンドを使うらしい。
$ sudo iscsiadm -m discovery -t sendtargets -p (NASのIPアドレス)
これで、NASのiSCSIターゲットのIQNが表示されるはずだ。

そうしたら、iSCSIターゲットへログインする
$ sudo iscsiadm -m node --targetname (NASのIQN名) --login
これで、NAS側で定義した、10GBのディスクが見えてくるはずだ。

dmesgで確認してみよう。
$ dmesg

私の環境では、scsi 4:0:0:0、デバイスファイル名 /dev/sdb として見えてきた。
本当に /dev/sdb として見えているか確認してみよう。
$ lsblk /dev/sdb
設定した通りの10GBの容量で見えてきているだろうか？

これで、HDDを増設した時と同じように、/dev/sdb を操作することが出来るはずだ。

ちなみに、デバイス認識時にdmesgを実行することで、デバイスIDを確認することが出来る(先ほどの4:0:0:0)が、長期間使っていたらどうせド忘れしてしまうだろう。
その場合、/sys/blockを見ることで、ある程度分かる。
こちらの環境では、/sys/block/sdbというファイル(シンボリックリンク)が存在し、そちらの指し示す先で分かるようだ。
$ ls -l /sys/block/sdb
lrwxrwxrwx 1 root root 0  6月 12 17:46 /sys/block/sdb -> ../devices/platform/host4/session1/target4:0:0/4:0:0:0/block/sdb
これを見ると、4:0.0.0というパスが出てくる。これがデバイスIDのようだ。

とりあえず、iSCSIのディスクが見えるところまでは確認できた。
次回はコレをLVMでボリューム作成、ファイルシステム作成してマウントするところまでやってみたい。

--2016/06/13追記
NAS側で10GBのLUN(仮想HDD)を作っているが、この時「シンプロビジョニング」を指定していたら、後の方でmkfs.ext4が出来ないことが発覚。
恐らく、使っているNASが低価格モデルなので上手く動かなかったのかと。（同メーカーの上位モデルを使っている方は、シンプロビジョニングでも問題なく利用できている模様。）
そのため、私の方では、シンプロビジョニングを使用しない形で作りなおしている。

--2016/07/06追記
iSCSI LUNをシンプロビジョニングで作成したら、mkfs.ext4が上手く行かなかったと書いた。
具体的には、mkfs.ext4はすぐ終わるのだが、syslog(/var/log/syslog)にエラーが記録されていて、マウントしようとしたらエラーが出る、という状態だ。
どうやら、mkfs.ext4 に -D のオプション(direct I/Oのオプションらしい)を付けると、syslogにもエラーは記録されず、普通にマウント出来るようだ。
既に、iSCSI LUNをフルプロビジョニングで作成して利用してしまっているので、今回はこのまま続けていくけど、どこかのタイミングでシンプロビジョニングのLUNと入れ替えようと思う。

--2016/07/21追記
シンプロビジョニングのiSCSI LUNに対して、フォーマットはmkfs.ext4に-Dを付ければヨカッタんだけど、その後ファイルシステムに対してファイルの書き込みをやったらエラーになった。
どうも何かが違うなぁ…。

--2016/07/23追記
少しわかった。
コチラに記載しているけど、次からはLUNの作り方を少し変えることにする。