NUTANIX(ニュータニックス?)というサーバ+ストレージ

NUTANIX(ニュータニックス?)というサーバ+ストレージという感じのシステムがあるらしい。

EMC Isilonみたいな感じの分散型のストレージ+HyperVisor。
EMCからは敵と見なされているようで、アメリカの方では、EMCからいろいろ言われてるらしい。
blogの「They (EMC) think you are stupid!」でEMCから言われてることはFUDだという反論記事を書いていた。

さて、そんなNUTANIXは、サーバブレードを4枚さした2U筐体を1単位として構成する、分散型でイーサネット接続のストレージ+vSphere実行環境。
はっきり書いてないけど、高性能なvSphere Storage Applianceとかみたいな印象を受ける。

日本では日商エレクトロニクスが取り扱っているみたいだが、あまり推進してはないのかな?。

さて、現状モデルは2つ。NX-2000とNX-3000。
スペックを比べる限りでは、単純にNX-2000が旧モデルで、NX-3000が新モデル、といった感じである。

NX-2000 starter kit NX-3000 starter kit
CPU (Xeon X5650*2)*4ブレード
 =48core 2.66GHz
(E5-2660*2)*4ブレード
 =64core 2.2GHz
ストレージ PCIe-SSD 1.5TB
+ SATA SDD 1.2TB
+ SATA HDD 20TB
PCIe-SSD 1.6TB
+ SATA SDD 1.2TB
+ SATA HDD 20TB
メモリ 192GB~768GB 512GB~1024GB
ネットワーク (10GbE*1,1GbE*2)*4 (10GbE*2,1GbE*2)*4
接続性 vSphere 5.x, KVM vSphere 5.x, KVM
電源 100~240V 1350W 200~240V 1400W

ストレージにところにある「PCIe-SSD」は、どうやら、Fusion-ioである模様。

SupermicroのSuperServer 2027TR-HTRF+みたいなハードウェアに、Fusion IO+2.5インチSSD+2.5インチSATA HDDという構成を取っているのだと思われる。
SYS-2027TR-H

Supermicroのだと仮定して調べてみると、2027TR-HTRF+で使われてるマザーボードだと、各ブレードあたり、SATA3/6Gbpsポートが2個とSATA2ポートが4個、が使えるらしい。
筐体前面にはディスクスロットが24個あるが、それらは4分割されており、それぞれのブレードに割り当てられており、共有されているわけではない。
おそらく、SATA3ポート側にSSDが2つ、SATA2ポート側にSATA HDDが4つ接続されており、1筐体全体としては、SSDが8個、SATA HDDが16個、計24スロット、という状態で使用しているのだと想定される。

PCIe SSD/SATA SSD/SATA HDDで構成されるハイブリッドファイルシステムは、VMware ESXi側からみると、接続形態はただのiSCSIディスク。
しかも、VMware Compatibility Guideによると、マルチパスが「NMP VMW_SATP_DEFAULT_AA VMW_PSP_FIXED」。
複数の筐体に分かれているが、特に分散処理とか考えられていないのだろうか?とちょっと心配になったりする設定に見える。
それとも、追加プラグインなどがあって、インストールすることによって、適切に分散してくれるとか?


2013/06/05追記

日本法人が設立されたそうで。
ascii「統合型仮想化インフラを手がけるニュータニックスが日本法人
impress「仮想環境向けアプライアンスを提供する米Nutanix、日本法人を設立

impressの記事には「ニュータニックス マネージングディレクターの岡田卓也氏」なる人が掲載されてて、なんか見たことある気が・・・と思ったら

Infoblox、Windows環境向けのDHCP/DNSサーバー集中管理アプライアンス」で「代表取締役の岡田卓也氏」と紹介されてた。

こういう業界の人の通例に伴い、転職してますねぇ・・・

ESXi5.1にすると起動しない仮想マシン

ESXi5.1にアップデートした後、NetApp simulatorがなぜか起動しない。

以下のエラーが出力される。

ディスク「/vmfs/volumes/~/~/DataONTAP.vmdk」、またはディスク「/vmfs/volumes/~/~/DataONTAP.vmdk」が依存しているスナップショット ディスクの 1 つを開くことができません。 
システムで指定されたファイルを見つかりません
VMware ESX は仮想ディスク「/vmfs/volumes/~/~/DataONTAP.vmdk」を検出できません。パスが有効であることを確認し、もう一度やり直してください。 

これに対する回答がNetApp comminityにあった。

OnTap Simulator 8.1.1 no longer running on ESXi 5.1 free

原因はESXi5.1以降、標準ではvmkernel multiextent moduleが読み込まれなくなったため。
このモジュールは、巨大な1つのvmdkではなく、そこそこの大きさの複数のファイルでvmdkを構成するときに使うもの。

対処方法はVMware KB:「 Powering on a virtual machine after upgrading to ESXi 5.1 fails with the error: File [VMFS volume] VM-name/VM-name.vmdk was not found」にあるとおりのことをする。

概要: multiextentモジュールを読み込んで、分割形式のvmdkから、単一ファイルのvmdkへ変換する。

2019/12/04 追記:ESXi 6.7ではmultiextentモジュールが無くなっているが、vmkfstoolコマンド自体に機能が追加されており、下記のその2の操作が不要となりました。

その1:状況確認

# ls
DataONTAP-cf-flat.vmdk  DataONTAP-s012.vmdk     DataONTAP.vmdk
DataONTAP-cf.vmdk       DataONTAP-s013.vmdk     DataONTAP.vmsd
DataONTAP-s001.vmdk     DataONTAP-s014.vmdk     DataONTAP.vmx
DataONTAP-s002.vmdk     DataONTAP-s015.vmdk     DataONTAP.vmxf
DataONTAP-s003.vmdk     DataONTAP-s016.vmdk     SimConsType
DataONTAP-s004.vmdk     DataONTAP-s017.vmdk     SimUpdateParameters
DataONTAP-s005.vmdk     DataONTAP-s018.vmdk     cfcard
DataONTAP-s006.vmdk     DataONTAP-s019.vmdk     mtoolsrc
DataONTAP-s007.vmdk     DataONTAP-s020.vmdk     nvram
DataONTAP-s008.vmdk     DataONTAP-s021.vmdk     vmware-1.log
DataONTAP-s009.vmdk     DataONTAP-s022.vmdk     vmware-2.log
DataONTAP-s010.vmdk     DataONTAP-s023.vmdk     vmware.log
DataONTAP-s011.vmdk     DataONTAP-s024.vmdk
#

その2: multiextentモジュール読み込み

この手順はvSphere 6.5とか6.7では不要です。

# vmkload_mod multiextent
Module multiextent loaded successfully
#

その3: 分割vmdkのDataONTAP.vmdkを、単一vmdkのDataONTAP-new.vmdkにコピー

下記はzerodthickにしていますが「thin」指定など他のフォーマットでも大丈夫です。

# vmkfstools -i DataONTAP.vmdk DataONTAP-new.vmdk -d zeroedthick
Destination disk format: VMFS zeroedthick
Cloning disk 'DataONTAP.vmdk'...
Clone: 100% done.
#

その4: DataONTAP.vmdkを削除

# vmkfstools -U DataONTAP.vmdk
#

その5: ファイル名の変更

# vmkfstools -E DataONTAP-new.vmdk DataONTAP.vmdk
#

その6: multiextentモジュールの読み込み解除

この手順はvSphere 6.5とか6.7では不要です。

# vmkload_mod  -u multiextent
Module multiextent successfully unloaded
#

その7: 状況確認

# ls
DataONTAP-cf-flat.vmdk  DataONTAP.vmxf          vmware-1.log
DataONTAP-cf.vmdk       SimConsType             vmware-2.log
DataONTAP-flat.vmdk     SimUpdateParameters     vmware-3.log
DataONTAP.vmdk          cfcard                  vmware.log
DataONTAP.vmsd          mtoolsrc
DataONTAP.vmx           nvram
# 

変換完了後、普通に起動できました。

なお、変換後、ついでに仮想マシンハードウェアバージョンを7から上げるか!と13にあげてみたところ、新しい仮想マシンハードウェアではサポートされないデバイスがあったようで起動できなくなりました・・・

ESXi5.1でIntel NICを認識するけど使えないという事象

SupermicroのマザーボードPDSM4+を使ってvSphere環境を構築中、悩んだ点が1つ。

ESXi5.0だと特に問題なく動くのに、ESXi5.1にすると、オンボードNICがvmnicとして認識するけれども通信ができない、という症状。
MACアドレス認識するし、IPアドレスも普通に設定できるのに通信ができない。

いろいろ調べたら解消するための事例を発見。
VMWare ESXi, SuperMicro X7SB4, Intel 82573, Network trouble, сетевая проблема」と、その元ネタ「VMWare community」を発見

曰く

・Intel NICのうち82573E/82573Lで認識されているもので発生する
・ESXi 5.1をインストールした後に、ESXi5.0からnet-e1000とnet-e1000eドライバを適用せよ
・ネットワークがつながらないのでUSBメモリでコピーする必要あり
 ・USBメモリはFAT32フォーマット不可。FAT16でフォーマットする必要あり
 ・ESXiにUSBメモリをさす前に「/etc/init.d/usbarbitrator stop」を実行せよ
・「esxcli software vib install -d /vmfs/volumes/datastore1/ESXi500-201207001.zip -n net-e1000e」というような形でファイルはフルパス指定でコマンド実行

で、実際にためした結果、上記以外に以下の注意点もありました。
・ESXiをUSBメモリにインストールしているんだったらLinuxにマウントして直接コピーしてもよい
・さらに新しいESXi5.0のパッチ「ESXi500-201209001.zip」でもokだった。

また、ESXi5.1に最新のパッチ「ESXi510-201212001.zip」を適用しても通信は不可でした。
パッチ適用後、再度、ESXi5.0のnet-e1000eを適用する必要がありました。


2013/03/08追記

正攻法の突破方法として、対応するドライバをコンパイルして使える様にした、という事例を発見しました。

環境さんぷる「ESXi5.1のドライバを作成してみる(intel 82579LM/82574L編)」と、その更新版の「ESXi5.1のドライバを作成してみる(intel I217/I218/82579LM/82574L編)

Intelで公開されているドライバソースから作成したとのこと。
こちらは、VMwareの署名が無いドライバのため、インストールにはESXiの設定変更が必要です。

ちなみに、ここの人、他にもドライバを公開していました。
ESXi5.1のドライバを作成してみる(VIA VT6130/VT6122編)
ESXi5.0のドライバを作成してみる(Silicon Image 3124/3132/3531編)

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)
#

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

3. 定義の変更
(1) 該当のデバイスに「VMW_SATP_LOCAL」として動作させる設定として、まず定義を設定。
先ほどの例の場合は以下の3デバイスがある。
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
#

クライアント端末にディスクイメージを配布するVMware MIRAGE

VMwareから新しい仮想デスクトップ向けのプロダクト「VMware MIRAGE」というのが登場。

・・・いや、詳細を見ていくと「仮想デスクトップ」と言えるかは、かなり微妙なんだけど、とりあえずVDIというくくりになるとは思う。

概要をみると、だいたいやりたい方向性としてはCitrix Xen Clientと似てる。
(Xen Clientは、ハードウェア制限が結構きびしいけど、これはどうなんだろうか?)

さて、とりあえず、ざらっと見た感じの特徴。

・VMware ViewはESXi上で実際のマシンが動いていたけど、これはクライアント端末上で動かす感じ
・クライアント上で仮想マシンを動かしているわけではない
 クライアント上でHypervisorを動かし、その上でクライアントOSを動作させている訳ではなく、ディスクイメージから直接Windows OSを起動している
・ディスクイメージ自体は仮想化技術の応用をしている
・クライアントとして使用できるのは以下のOS
 「XP SP2」「XP SP3」「Windows 7」
・Windowsライセンス上は各クライアントの物理マシンで直接Windowsが動作、という感じ

・各個別のクライアント端末上に存在するディスクイメージは以下に分割される
 ・ベースOS部分(Driver Library Layer/Base Layer/Departmental Application Layper)
 ・各ハードウェア固有差分(Machine Identify Layer)
 ・ユーザ固有のアプリケーション差分(User Application Layer)
 ・ユーザ固有の個人情報/デスクトップ情報など(User Data Settings Layer)
・上記のディスクイメージは、VMware Mirage Serverに転送され管理される
・OSパッチ/アプリケーション追加などはMirage Serverから行い、
 差分情報だけがクライアント端末に配布される。
・クライアント端末のハードウェアが複数あっても共通化可能

・Mirage ServerはWindows Server 2008R2上に立てる
 物理/仮想はどちらでも良い

不明な点
・クライアント端末のハードウェア制約
・導入によるクライアント端末のパフォーマンス低下の度合い
・プレインストールのクライアント端末が大量にある場合のMirage環境へのマイグレート手法