カテゴリー: ストレージ

投稿日:

ESXi5.xでテープ装置を使う

仮想環境において、ゲストOSからFC接続されているテープ装置を使おうとしたら、認識してないようだったので調べてみた。

結論からいうと、VMware KB2013670:「ESX/ESXi でテープデバイスが間違って ALUA デバイスとして認識されてしまう」が該当していた。
2015/12/18追記:現在は「ESXi/ESX ホストでテープ デバイスが間違って ALUA デバイスとして検出される (2090103)」で公開されている。
2020/09/28追記:「ESXi/ESX ホストでテープ デバイスが間違って ALUA デバイスとして検出される (1026157)」

対処方法も、上記KBそのままで大丈夫だった。

実際に実行した例について、以下に紹介する。

1. まず認識しているかどうかを確認する
(1)「esxcli storage core path list」を実行する。

# esxcli storage core path list

＜略＞
fc.XXXXXXXXXXXX35:XXXXXXXXXXXX34-fc.XXXXXXXXXXXX0e:XXXXXXXXXXXX0f-
UID: fc.XXXXXXXXXXXX35:XXXXXXXXXXXX34-fc.XXXXXXXXXXXX0e:XXXXXXXXXXXX0f-
Runtime Name: vmhba1:C0:T4:L0
Device: No associated device
Device Display Name: No associated device
Adapter: vmhba1
Channel: 0
Target: 4
LUN: 0
Plugin: (unclaimed)
State: dead
Transport: fc
Adapter Identifier: fc.XXXXXXXXXXXX35:XXXXXXXXXXXX34
Target Identifier: fc.XXXXXXXXXXXX0e:XXXXXXXXXXXX0f
Adapter Transport Details: Unavailable or path is unclaimed
Target Transport Details: Unavailable or path is unclaimed
＜略＞
fc.XXXXXXXXXXXX35:XXXXXXXXXXXX34-fc.XXXXXXXXXXXXc8:XXXXXXXXXXXXc9-
UID: fc.XXXXXXXXXXXX35:XXXXXXXXXXXX34-fc.XXXXXXXXXXXXc8:XXXXXXXXXXXXc9-
Runtime Name: vmhba1:C0:T5:L0
Device: No associated device
Device Display Name: No associated device
Adapter: vmhba1
Channel: 0
Target: 5
LUN: 0
Plugin: (unclaimed)
State: dead
Transport: fc
Adapter Identifier: fc.XXXXXXXXXXXX35:XXXXXXXXXXXX34
Target Identifier: fc.XXXXXXXXXXXXc8:XXXXXXXXXXXXc9
Adapter Transport Details: Unavailable or path is unclaimed
Target Transport Details: Unavailable or path is unclaimed
＜略＞
#

というような感じで「Plugin: (unclaimed)」というデバイスが認識されいている。

(2) VMware上で使える認識になっているか確認する
「esxcli storage nmp device list」を実行する。

# esxcli storage nmp device list
＜略＞
#


こちらの出力結果には出てこない。

2. 該当デバイスのSCSI inquryを調査
(1) SCSIデバイスのスキャンを実行
「esxcfg-rescan vmhba？」を実行。
今回の場合、「vmhba1」で認識されているので「esxcfg-rescan vmhba1」を実行。

(2) ログに出力されたScsiScanを確認。

# grep "ScsiScan" /var/log/vmkernel.log
＜略＞
2012-09-21T12:52:46.210Z cpu0:2635)ScsiScan: 1098: Path 'vmhba1:C0:T0:L0': Vendor: 'HP ' Model: 'D2DBS Diagnostic' Rev: 'DIAG'
2012-09-21T12:52:46.210Z cpu0:2635)ScsiScan: 1101: Path 'vmhba1:C0:T0:L0': Type: 0x1f, ANSI rev: 3, TPGS: 1 (implicit only)
2012-09-21T12:52:46.210Z cpu3:2641)ScsiScan: 1098: Path 'vmhba1:C0:T1:L0': Vendor: 'HP ' Model: 'Ultrium 4-SCSI ' Rev: 'ED41'
2012-09-21T12:52:46.210Z cpu3:2641)ScsiScan: 1101: Path 'vmhba1:C0:T1:L0': Type: 0x1, ANSI rev: 3, TPGS: 1 (implicit only)
2012-09-21T12:52:46.211Z cpu3:2641)ScsiScan: 1582: Add path: vmhba1:C0:T1:L0
2012-09-21T12:52:46.211Z cpu3:2641)ScsiScan: 1098: Path 'vmhba1:C0:T2:L0': Vendor: 'HP ' Model: 'Ultrium 4-SCSI ' Rev: 'ED41'
2012-09-21T12:52:46.211Z cpu3:2641)ScsiScan: 1101: Path 'vmhba1:C0:T2:L0': Type: 0x1, ANSI rev: 3, TPGS: 1 (implicit only)
2012-09-21T12:52:46.212Z cpu2:2641)ScsiScan: 1582: Add path: vmhba1:C0:T2:L0
2012-09-21T12:52:46.212Z cpu1:2641)ScsiScan: 1098: Path 'vmhba1:C0:T3:L0': Vendor: 'HP ' Model: 'Ultrium 4-SCSI ' Rev: 'ED41'
2012-09-21T12:52:46.212Z cpu1:2641)ScsiScan: 1101: Path 'vmhba1:C0:T3:L0': Type: 0x1, ANSI rev: 3, TPGS: 1 (implicit only)
2012-09-21T12:52:46.213Z cpu2:2641)ScsiScan: 1582: Add path: vmhba1:C0:T3:L0
2012-09-21T12:52:46.213Z cpu3:2641)ScsiScan: 1098: Path 'vmhba1:C0:T4:L0': Vendor: 'HP ' Model: 'Ultrium 4-SCSI ' Rev: 'ED41'
2012-09-21T12:52:46.213Z cpu3:2641)ScsiScan: 1101: Path 'vmhba1:C0:T4:L0': Type: 0x1, ANSI rev: 3, TPGS: 1 (implicit only)
2012-09-21T12:52:46.213Z cpu2:2641)ScsiScan: 1582: Add path: vmhba1:C0:T4:L0
2012-09-21T12:52:46.214Z cpu1:2641)ScsiScan: 1098: Path 'vmhba1:C0:T5:L0': Vendor: 'HP ' Model: 'D2DBS ' Rev: 'EL01'
2012-09-21T12:52:46.214Z cpu1:2641)ScsiScan: 1101: Path 'vmhba1:C0:T5:L0': Type: 0x8, ANSI rev: 3, TPGS: 1 (implicit only)
2012-09-21T12:52:46.214Z cpu2:2641)ScsiScan: 1582: Add path: vmhba1:C0:T5:L0
2012-09-21T12:53:33.684Z cpu2:2745)ScsiScan: 1098: Path 'vmhba1:C0:T0:L0': Vendor: 'HP ' Model: 'D2DBS Diagnostic' Rev: 'DIAG'
2012-09-21T12:53:33.684Z cpu2:2745)ScsiScan: 1101: Path 'vmhba1:C0:T0:L0': Type: 0x1f, ANSI rev: 3, TPGS: 1 (implicit only)
#

こんな感じで出力されている。
該当するものとしては、以下の３種類となる。
Vendor:「HP」、Model:「Ultrium 4-SCSI」
Vendor:「HP」、Model:「D2DBS」
Vendor:「HP」、Model:「D2DBS Diagnostic」

3. 定義の変更
(1) 該当のデバイスに「VMW_SATP_LOCAL」として動作させる設定として、まず定義を設定。
先ほどの例の場合は以下の３デバイスがある。
Vendor:「HP」、Model:「Ultrium 4-SCSI」
Vendor:「HP」、Model:「D2DBS」
Vendor:「HP」、Model:「D2DBS Diagnostic」

今回の場合は、以下のコマンドを実行した。

# esxcli storage nmp satp rule add --satp="VMW_SATP_LOCAL" --vendor="HP" --model="^Ultrium 4-SCSI*"
# esxcli storage nmp satp rule add --satp="VMW_SATP_LOCAL" --vendor="HP" --model="^D2DBS*"
#

なお、SCSI inquryでは文字列末尾につくスペースも重要であるが、このコマンドでは末尾のスペースは無視してくれるようである。

(2) 次に、各デバイスに対して現状、設定されている定義を解除

# esxcli storage core claiming unclaim -t location -A vmhba1 -C 0 -T 0 -L 0
# esxcli storage core claiming unclaim -t location -A vmhba1 -C 0 -T 1 -L 0
# esxcli storage core claiming unclaim -t location -A vmhba1 -C 0 -T 2 -L 0
# esxcli storage core claiming unclaim -t location -A vmhba1 -C 0 -T 3 -L 0
# esxcli storage core claiming unclaim -t location -A vmhba1 -C 0 -T 4 -L 0
# esxcli storage core claiming unclaim -t location -A vmhba1 -C 0 -T 5 -L 0
#

(3) 再スキャンを行い、設定した定義を適用
「esxcfg-rescan vmhba？」を実行する。

# esxcfg-rescan vmhba1
#


4. 認識が変わったことを確認
「esxcli storage nmp device list」を実行

# esxcli storage nmp device list
naa.XXXXXXXXXXXXc8
Device Display Name: HP Fibre Channel Medium Changer (naa.XXXXXXXXXXXXc8)
Storage Array Type: VMW_SATP_LOCAL
Storage Array Type Device Config: SATP VMW_SATP_LOCAL does not support device configuration.
Path Selection Policy: VMW_PSP_FIXED
Path Selection Policy Device Config: {preferred=vmhba1:C0:T5:L0;current=vmhba1:C0:T5:L0}
Path Selection Policy Device Custom Config:
Working Paths: vmhba1:C0:T5:L0

naa.XXXXXXXXXXXX0a
Device Display Name: HP Fibre Channel Tape (naa.XXXXXXXXXXXX0a)
Storage Array Type: VMW_SATP_LOCAL
Storage Array Type Device Config: SATP VMW_SATP_LOCAL does not support device configuration.
Path Selection Policy: VMW_PSP_FIXED
Path Selection Policy Device Config: {preferred=vmhba1:C0:T2:L0;current=vmhba1:C0:T2:L0}
Path Selection Policy Device Custom Config:
Working Paths: vmhba1:C0:T2:L0

naa.XXXXXXXXXXXX0c
Device Display Name: HP Fibre Channel Tape (naa.XXXXXXXXXXXX0c)
Storage Array Type: VMW_SATP_LOCAL
Storage Array Type Device Config: SATP VMW_SATP_LOCAL does not support device configuration.
Path Selection Policy: VMW_PSP_FIXED
Path Selection Policy Device Config: {preferred=vmhba1:C0:T3:L0;current=vmhba1:C0:T3:L0}
Path Selection Policy Device Custom Config:
Working Paths: vmhba1:C0:T3:L0

naa.XXXXXXXXXXXX0e
Device Display Name: HP Fibre Channel Tape (naa.XXXXXXXXXXXX0e)
Storage Array Type: VMW_SATP_LOCAL
Storage Array Type Device Config: SATP VMW_SATP_LOCAL does not support device configuration.
Path Selection Policy: VMW_PSP_FIXED
Path Selection Policy Device Config: {preferred=vmhba1:C0:T4:L0;current=vmhba1:C0:T4:L0}
Path Selection Policy Device Custom Config:
Working Paths: vmhba1:C0:T4:L0

＜略＞

naa.XXXXXXXXXXXX08
Device Display Name: HP Fibre Channel Tape (naa.XXXXXXXXXXXX08)
Storage Array Type: VMW_SATP_LOCAL
Storage Array Type Device Config: SATP VMW_SATP_LOCAL does not support device configuration.
Path Selection Policy: VMW_PSP_FIXED
Path Selection Policy Device Config: {preferred=vmhba1:C0:T1:L0;current=vmhba1:C0:T1:L0}
Path Selection Policy Device Custom Config:
Working Paths: vmhba1:C0:T1:L0
#
投稿日:

NetAppの仮想ストレージData ONTAP Edge

NetAppから「Data ONTAP Edge」というプロダクトが出てきた。

vSphere5環境で動作する仮想マシンとしてNetAppを動かして、NAS共有ストレージとして利用する、というもの。

ぶっちゃけ、これまでず～っとあった、検証用に提供されていたData ONTAP Simulatorを製品化しちゃったようなもの。
使い続けるためには有償となるようだが、コストに関しての記述が無かったので詳細不明。

利用可能ストレージサイズの最大が「5TB」なので、利用用途は大規模環境ではない感じ。

Data ONTAP Edgeを要求要件
・仮想マシンに2CPU以上割り当て（可能な限り占有させること）
・メモリは4GB以上（可能な限り占有させること）
・OS領域は57.5GB必要
・仮想ディスクを置く領域はキャッシュがバッテリーバックアップされたRAID上のVMFS3/VMFS5であること
・１本の仮想ディスクサイズは50GB～2TBまでを選択できる。
(何本まで増加できるか明記は無し）

特色
・Data ONTAP的にはクラスタモード(旧来の7-Modeではない)
・標準ライセンスに重複排除/SnapVault/SnapRestore/FlexCloneが含まれている
→ 小規模リモートオフィスにEdgeを置いて、中央のNetAppでバックアップ、的な感じ

いままでのSimulatorでもいい感じで使えてたので、Edgeになったからといって、特段かわりそうもないですが、とりあえず評価版の入手が可能です。

評価版はData ONTAP Edge Evaluationから入手できますが、NetApp Nowのアカウントが必要です。

また、NetAppのコミュニティーにData ONTAP Edgeに関する掲示板も出来ています。
Welcome to the Data ONTAP Edge CommunityにていろんなQ&Aを確認することができます。

投稿日:

Windows用NFSサーバ「FreeNFS」

2020/10/23追記

自分でコンパイルする必要があるのだが、User-space NFSv3 Server(unfs3)というものがあり、「Windows向け手順」を参考にMinGW環境でunfsd.exeを作成できるようだ。

FreeNFSというWindows用のNFSサーバソフトウェアが出た。

NFS v3対応、ということで、試してみたんだけど、Linuxサーバからうまく接続ができない・・・ 

# rpcinfo -p 172.17.44.21
   プログラム バージョン プロトコル ポート
    100000    2   tcp    111  portmapper
    100000    2   udp    111  portmapper
    100005    3   tcp    635  mountd
    100005    3   udp    635  mountd
    100003    3   tcp   2049  nfs
    100003    3   udp   2049  nfs
# mount 172.17.44.21:/ /mnt
mount: mount to NFS server '172.17.44.21' failed: RPC Error: Authentication error.
# mount -v -t nfs 172.17.44.21:/ /mnt
mount: trying 172.17.44.21 prog 100003 vers 3 prot tcp port 2049
mount: mount to NFS server '172.17.44.21' failed: RPC Error: Authentication error.
#

Windowsファイアウォールの設定を解除しても同じ状況。
どこらの問題かなぁ・・・

2019/06/27追記

いまも時々このページにアクセスがあるので、そういえばどうなってるんだろ？と再チャレンジ

現在はFreeNFSと、セキュリティ関連を甘くしているぽいFreeNFSEの２種類があるようだ。

ただ、どちらで試しても同じようにエラーとなっている。

# rpcinfo -p 172.17.44.74
   program vers proto   port  service
    100000    2   tcp    111  portmapper
    100000    2   udp    111  portmapper
    100005    3   tcp    635  mountd
    100005    3   udp    635  mountd
    100003    3   tcp   2049  nfs
    100003    3   udp   2049  nfs
# mount -v 172.17.44.74:/ /mnt
mount.nfs: timeout set for Thu Jun 27 11:07:24 2019
mount.nfs: trying text-based options 'vers=4.1,addr=172.17.44.74,clientaddr=172.17.44.73'
mount.nfs: mount(2): Permission denied
mount.nfs: trying text-based options 'vers=4.0,addr=172.17.44.74,clientaddr=172.17.44.73'
mount.nfs: mount(2): Permission denied
mount.nfs: trying text-based options 'addr=172.17.44.74'
mount.nfs: prog 100003, trying vers=3, prot=6
mount.nfs: trying 172.17.44.74 prog 100003 vers 3 prot TCP port 2049
mount.nfs: portmap query failed: RPC: Authentication error
mount.nfs: access denied by server while mounting 172.17.44.74:/
# showmount -e 172.17.44.74
rpc mount export: RPC: Procedure unavailable
#

ぐぐってみても、FreeNFSに関する事例はどれも解決していない。

だ～か～ら～「sec=nosec」とか「vers指定」とかやっても駄目だったというとるのに、なんでまた試せとかいうん？とという展開になっている。

で、「haneWIN NFS Server for Windows」という似たようなNFSサーバに逃げているようだ

投稿日:

Nimble Storage

2013/05/21追記

「Nimble Storageについて 2013年版」にて最新情報を公開しています。
また、以下の記述には、間違った情報が含まれていますので、きちんとした情報を知りたい人は上記のURLにアクセスしてください。

Nimble Storageというプロダクトがあるらしい。

うたい文句をみるとTintri VMstoreと似てる感じがするなぁ・・・と思いつつ内容を確認。

コントローラヘッド筐体＋SAS接続のディスクShelf、というのが基本形。
そこから性能を上げる選択肢がいくつかある。

・１セットの容量を増やすためには、ディスクShelf追加
・パフォーマンスアップのためにSSD追加
・さらパフォーマンスと容量を上げるには、別セットを用意し連携させる
「Nimble Storage Technology & Features Primer」より

「Base Flash Capaticy」「x2 Flash Capacity」「x4 Flash Capacity」という感じの３種類があり、低ランクではBaseしかないし、高ランクだとx2/x4だけだし、という感じで、アクセス速度はここのSSDによるキャッシュに依存しているようだ。
（現状は2400GBが最大上限である模様）

で・・・ディスクShelfの方のスペックを見てみると、こちらにも「Flash Capacity」とある。
コントローラヘッド内にも(PCIeの)SSDがあるのか、それとも、ディスクShelf側にHDDの代わりにSSDを入れて高速化を図るのか、どちらなのかがよく分からない。

もし、ディスクShelf側にSSDを入れるとなると、全体容量が犠牲になるわけですし、評価が難しいところ。

サーバとNimble Storageの接続はiSCSIである模様。
VMware / Hyper-V / Citrixで使える、ということになっている。

以下は参考資料

BEST PRACTICES GUIDE: Nimble Storage Best Practices for Scale-Out

BEST PRACTICES GUIDE: VMware on Nimble Storage
BEST PRACTICES GUIDE: Nimble Storage Best Practices for Microsoft Hyper-V R2
BEST PRACTICE GUIDE: Nimble Storage for VMware View VDI

投稿日:

Windows Server 2012とInfinibandによる高速転送について

Interrop 2012でマイクロソフトがWindows Server 2012 Betaを使ったデモンストレーションを展示しているらしい。
Microsoftのtechnet blogのJose’s Briefings, Diagrams and Annotationsより「Windows Server 2012 Beta with SMB 3.0 – Demo at Interop shows SMB Direct at 5.8 Gbytes/sec over Mellanox ConnectX-3 network adapters」

内容は、SMB3.0を使用したネットワーク越しでの高速転送技術について。

SMBサーバ側はFusionIO ioDrive2(単独で1.5Gbytes/sec)を4枚並べてストライプ。
そこに、高速ネットワークを使って別のサーバからアクセスして、どれくらいの速度がでるか、というもの。

上記の様な状態で、IO benchmarkを測定すると、以下の様な感じとなる。

テスト内容 サーバ ローカル 10Gbps Ethernet 32Gbps Infiniband 54Gbps Infiniband
512KB IO/8スレッド/8 outstanding
バンド幅 5808MB/sec 1129MB/sec 3754MB/sec 5792MB/sec
IOPS(512KB/sec IOs/sec 11616 IOPS 2259 IOPS 3754 IOPS 11565 IOPS
CPU負荷 ～6.6% ～9.8% ～3.5% ～4.8%
8KB IO/16スレッド/16 outstanding
バンド幅 5103MB/sec 571MB/sec 2620MB/sec 2683MB/sec
IOPS(512KB/sec IOs/sec 525225 IOPS 73160 IOPS 335446 IOPS 343388 IOPS
CPU負荷 ～90.4% ～21.0%
(転送できてないので暇)		 ～85.9% ～84.7%

( 検証環境の構築手順: Deploying Windows Server 2012 Beta with SMB Direct (SMB over RDMA) and the Mellanox ConnectX-2/ConnectX-3 using InfiniBand – Step by Step )

ま、単純に10Gbps < 32Gbps < 54Gbpsの差、と見ることもできるけど、 512KB IO時のCPU負荷が10Gbpsより低い、というのは、注目ポイントかもしれない。 なぜ、その様なことが発生するのか？ それは、Infinibandを使用するSMB 3.0では、RDMAという技術を利用しているから、である。 RDMAは「Remote Direct Memory Access Protocol」の略で、Infiniband環境下では当たり前のように使用されている技術である。 参考文献1:SMB Advanced Networking for Fault Tolerance and Performance
これの5ページ～10ページに詳細が書かれているが、ようはプロトコルオーバーヘッドが少ないから、ということになるのだが、ちょっとここの説明だと理解しづらい。

参考文献2:SMB 2.2. over RDMA

参考文献2を見ると、SMB over RDMA自体はSMB 2.2からサポートしているらしい。
RDMAがなぜ早いのか？という仕組みの説明としてはこちらの19ページと20ページの図がわかりやすい。
実際のデータ転送部分に関しては、直接サーバ上のメモリを参照してもらう、ということで、高速化を図っている、という感じである。

SMB3.0での改善点は他にもあり、上記の参考文献1の11ページ～18ページでは、「SMB Multichannel」という技術の話がされている。
これは、高速転送時、いままでのSMB実装では、１つの転送に対して使用できるCPU coreは１つしかなかったので、CPU coreが頭打ちになると、それ以上は帯域や他のCPU coreが空いていてもそれ以上は早くならない、という問題がある。(参考文献1 13ページ)
それを複数のCPU coreで処理を担当できるようにする、というのがSMB Multichannel。
SMB Multichannelにより複数NICを使った場合の分散処理もかなり改善される。

(訂正: 参考文献3 SMB 2.2: Bigger, Faster, Scalier (Part 1)を見るとSMB 2.2からあるようだ)

参考文献4 The basics of SMB Multichannel, a feature of Windows Server 2012 and SMB 3.0
という記事があがり、Multichannelとかの機能について解説されている。