Hatena::ブログ(Diary)

tokuhy’s fraction このページをアンテナに追加 RSSフィード

2010-01-08

OpenSolaris自作ストレージサーバでシン・プロビジョニングを試す

OpenSolarisiSCSIストレージの自作にあたって、シン・プロビジョニングについて調べてみました。今回の社内案件ではシン・プロビジョニングの必要がない案件ではあるんですが、将来的にサーバストレージで使う上で必要になります。

というか現在のエンタープライズ向けの仮想化のiSCSIストレージなら当たり前にもっている機能です。

シン・プロビジョニング(Thin Provisioning)については以下の記事がわかりやすいと思います。

というわけで実際に試してみたのでその記録です。iSCSIで検証しています。

ついでにファイルでプールを作ってみる

HDDで作ることもできる環境ですが、手軽にZFSを試す例も兼ねてファイルを使ったプールで実験してみます。

100MBのサイズのファイルを作成します。

# mkfile 100m /tmp/01
# mkfile 100m /tmp/02
# mkfile 100m /tmp/03

次にこれを使ってプールを作ります。

# zpool create osol raidz2 /tmp/01 /tmp/02 /tmp/03
# zpool status osol
  pool: osol
 state: ONLINE
 scrub: none requested
config:

        NAME         STATE     READ WRITE CKSUM
        osol         ONLINE       0     0     0
          raidz2     ONLINE       0     0     0
            /tmp/01  ONLINE       0     0     0
            /tmp/02  ONLINE       0     0     0
            /tmp/03  ONLINE       0     0     0

errors: No known data errors
# zfs list osol
NAME   USED  AVAIL  REFER  MOUNTPOINT
osol  69.7K  62.9M  18.9K  /osol

これでプールができました。

このストレージプールでは実際に使える容量が62.9Mしかありません(ここ重要)。要件として1Gの容量が必要なものとします。

ではこのストレージプールを使って以下の検証を進めていきます。

・・・のまえに環境の準備も一応書いておく

OpenSolarisiSCSIを使う環境を一応書いておきます。

# pkg install SUNWiscsitgt
  • COMSTARで設定する場合。
# pfexec pkg install storage-server SUNWiscsit

stmfを起動するには一度OS再起動する必要があるので注意。

詳細は以前のエントリを参照してください。

OpenSolaris 2009.06でCOMSTARを試す


ZFSのshareiscsiプロパティを使用したiSCSIの場合

ボリュームの作成

試しにまず普通に容量を割り当ててボリュームを作成します。

# zfs create -V 50m osol/test
# zfs list
NAME                               USED  AVAIL  REFER  MOUNTPOINT
osol                              50.1M  12.9M  18.9K  /osol
osol/test                           50M  62.9M  15.9K  -

osol/testのUSEDが割り当てた50Mになり、osolのAVAILが12.9Mになっています。

プロパティも確認。

# zfs get all osol/test
NAME       PROPERTY              VALUE                    SOURCE
osol/test  type                  volume                   -
osol/test  creation              金  1月  8 21:45 2010  -
osol/test  used                  50M                      -
osol/test  available             62.9M                    -
osol/test  referenced            15.9K                    -
osol/test  compressratio         1.00x                    -
osol/test  reservation           none                     default
osol/test  volsize               50M                      -
osol/test  volblocksize          8K                       -
osol/test  checksum              on                       default
osol/test  compression           off                      default
osol/test  readonly              off                      default
osol/test  shareiscsi            off                      default
osol/test  copies                1                        default
osol/test  refreservation        50M                      local
osol/test  primarycache          all                      default
osol/test  secondarycache        all                      default
osol/test  usedbysnapshots       0                        -
osol/test  usedbydataset         15.9K                    -
osol/test  usedbychildren        0                        -
osol/test  usedbyrefreservation  50.0M                    -

ボリュームサイズ(volsize)を見ると50Mになってます。

普通の状況が確認できたところで破棄。

# zfs destroy osol/test

では本題のiSCSI用のボリュームを作成に。1Gが要件なので1Gで作成します。

# zfs create -V 1g osol/shareiscsi
cannot create 'osol/shareiscsi': out of space

当然怒られます。実際の容量を遥かにオーバしています。そこでシン・プロビジョニングです。-sを付加します。

# zfs create -V 1g -s osol/shareiscsi

コマンドが通りました。確認します。

# zfs list
NAME                               USED  AVAIL  REFER  MOUNTPOINT
osol                              99.1K  62.9M  18.9K  /osol
osol/shareiscsi                   15.9K  62.9M  15.9K  -

さっきと違ってosolのAVAILが62.9Mのままです。osol/shareiscsiのUSEDも15.9kとなっています。

プロパティを見てみます。

# zfs get all osol/shareiscsi
NAME             PROPERTY              VALUE                    SOURCE
osol/shareiscsi  type                  volume                   -
osol/shareiscsi  creation              金  1月  8 21:46 2010  -
osol/shareiscsi  used                  15.9K                    -
osol/shareiscsi  available             62.9M                    -
osol/shareiscsi  referenced            15.9K                    -
osol/shareiscsi  compressratio         1.00x                    -
osol/shareiscsi  reservation           none                     default
osol/shareiscsi  volsize               1G                       -
osol/shareiscsi  volblocksize          8K                       -
osol/shareiscsi  checksum              on                       default
osol/shareiscsi  compression           off                      default
osol/shareiscsi  readonly              off                      default
osol/shareiscsi  shareiscsi            off                      default
osol/shareiscsi  copies                1                        default
osol/shareiscsi  refreservation        none                     default
osol/shareiscsi  primarycache          all                      default
osol/shareiscsi  secondarycache        all                      default
osol/shareiscsi  usedbysnapshots       0                        -
osol/shareiscsi  usedbydataset         15.9K                    -
osol/shareiscsi  usedbychildren        0                        -
osol/shareiscsi  usedbyrefreservation  0                        -

ボリュームサイズ(volsize)を見るとちゃんと1Gになっています。ではこれをiSCSIとして使えるようにします。

まずサービスの起動してからプロパティを設定します。

# svcadm enable iscsitgt
# zfs set shareiscsi=on osol/shareiscsi

これだけでボリュームの公開が可能になります。確認します。

# iscsitadm list target -v
Target: osol/shareiscsi
    iSCSI Name: iqn.1986-03.com.sun:02:a16b1b66-94b2-e755-9760-b8512d7d4e25
    Alias: osol/shareiscsi
    Connections: 0
    ACL list:
    TPGT list:
    LUN information:
        LUN: 0
            GUID: 0
            VID: SUN
            PID: SOLARIS
            Type: disk
            Size: 1.0G
            Backing store: /dev/zvol/rdsk/osol/shareiscsi
            Status: online
Windows XPから接続

WindowsでのiSCSIのイニシエータは先述の過去のCOMSTARの記事を参照。

接続結果は以下の画像で。

f:id:tokuhy:20100108220958p:image

どうでしょう。1Gのボリュームが見えています。

実際のストレージ側では使用可能領域が62.9Mなのに接続する側にはちゃんと1Gで見えちゃってます。

しかし、実際には1Gの容量は使えないので試しに大きなサイズのファイルを書き込もうとするとエラーになります。

実際はそんなに容量がないから当たり前です。これぞこれぞシン・プロビジョニング!

おまけ

ちなみにzfsプロパティrefreservationを比較すると、普通の場合とシン・プロビジョニングの場合では値が違います。普通に割り当てるとそのボリュームサイズがそのままここの値になってますが、シン・プロビジョニングの場合はnoneになってます。

なのでこのプロパティの設定を変えることでシン・プロビジョニングの状態から普通の状態に変えられるです。

軽く試した感じだとシン・プロビジョニングのボリュームを普通のサイズを持ったボリュームにすることができました。

ただここは突っ込んで調べてないので自分の推測の範疇です。

そのうち調べます。

COMSTARの場合

ボリュームの作成

では次にCOMSTARでシン・プロビジョニングを試してみます。

まずサービスとしてshareiscsiプロパティiSCSIとは共存できないので無効にしてからCOMSTAR用のサービスを立ち上げます。

# svcadm disable iscsitgt
# svcadm enable stmf
# svcadm enable target

前回のボリュームを削除して追加してみます。

# zfs destroy osol/shareiscsi
# zfs create -V 1g -s osol/comstar

確認

# zfs list
NAME                               USED  AVAIL  REFER  MOUNTPOINT
osol                               295K  62.7M  18.9K  /osol
osol/comstar                      15.9K  62.7M  15.9K  -

# zfs get all osol/comstar
NAME          PROPERTY              VALUE                    SOURCE
osol/comstar  type                  volume                   -
osol/comstar  creation              金  1月  8 22:26 2010  -
osol/comstar  used                  15.9K                    -
osol/comstar  available             62.7M                    -
osol/comstar  referenced            15.9K                    -
osol/comstar  compressratio         1.00x                    -
osol/comstar  reservation           none                     default
osol/comstar  volsize               1G                       -
osol/comstar  volblocksize          8K                       -
osol/comstar  checksum              on                       default
osol/comstar  compression           off                      default
osol/comstar  readonly              off                      default
osol/comstar  shareiscsi            off                      default
osol/comstar  copies                1                        default
osol/comstar  refreservation        none                     default
osol/comstar  primarycache          all                      default
osol/comstar  secondarycache        all                      default
osol/comstar  usedbysnapshots       0                        -
osol/comstar  usedbydataset         15.9K                    -
osol/comstar  usedbychildren        0                        -
osol/comstar  usedbyrefreservation  0                        -

引き続き設定

# sbdadm create-lu /dev/zvol/rdsk/osol/comstar 

Created the following LU:

              GUID                    DATA SIZE           SOURCE
 --------------------------------  -------------------  ----------------
600144f0b8eb0a0000004b47330b0009      1073676288       /dev/zvol/rdsk/osol/comstar

# stmfadm add-view 600144f0b8eb0a0000004b47330b0009
# stmfadm list-view -l 600144f0b8eb0a0000004b47330b0009
View Entry: 0
    Host group   : All
    Target group : All
    LUN          : 0

iSCSIターゲットがない場合はターゲットも作成します。

# itadm create-target
Target iqn.1986-03.com.sun:02:f5ea47bd-6042-cc32-a674-abbbc4c7b057 successfully created

これで設定は完了です。

Windows XPから接続

f:id:tokuhy:20100108220958p:image

shareiscsiプロパティの場合と同じように1Gの領域が見えています。


おまけ

COMSTARの場合、sbdadmで論理ユニットを作るわけですがこれのサイズを変更できることをこの検証中に気づいた。

今回の例だとsbdadmでLUを作った際の出力でDATA SIZEの項目の1073676288がサイズになるんですが、ここのサイズもzfsのボリュームとは違った値を設定できます。

なので、疎ボリュ-ムを作らずに普通にこのLUのサイズだけ変更すればシン・プロビジョニングできるんじゃ?とか思っちゃったわけですがこれはできない。

具体的に言うと、普通に50Mのボリュームを作ってLUのサイズだけ1Gにしてみるということ。以下の感じです。

# zfs create -V 50m osol/comstar
# sbdadm create-lu -s 1073676288 /dev/zvol/rdsk/osol/comstar 

Created the following LU:

              GUID                    DATA SIZE           SOURCE
 --------------------------------  -------------------  ----------------
600144f0b8eb0a0000004b473845000a      1073676288       /dev/zvol/rdsk/osol/comstar
# stmfadm add-view 600144f0b8eb0a0000004b473845000a

とかで公開すると、確かに接続した段階では1Gに見えます。で、ディスクの初期化をしてフォーマットしようとするんですが、そこで失敗します。

なのでこの方法ではできないようです。まあ当たり前なのかな・・・。

まとめ

こんな感じOpenSolarisZFSでもシン・プロビジョニング機能が使えます。zfsコマンドのマニュアルを見ると-sでのシン・プロビジョニングは推奨されていませんみたいなことが書かれていますけど・・・。

これは実戦で使える機能なので、実際に投入して運用テストなどもしていきたいと思います。

OpenSolarisやっぱいい!

スパム対策のためのダミーです。もし見えても何も入力しないでください
ゲスト


画像認証

トラックバック - http://d.hatena.ne.jp/tokuhy/20100108/1262959376
リンク元