VMware vSphere5発表でライセンスの実質値上げ!?


2013/07/26追記

いまでも、時々、検索でこのページに来る人がいるので注意書きを追加します。

vSphere 5.1において、メモリの容量制限は撤廃されました。
同時にvSphere 5.0 Update2についても容量制限撤廃です。

ただ、vSphere5.0Update2も、5.1も、どちらも、Free版は32GBまでのハードウェアにしか載りません。


2011/08/16現在、後述の制限が緩和されています。
・ベースの考え方は同じ
・容量制限量が増えた
 32GB: Standard
 64GB: Enterprise
 98GB: Enterprise plus
 総計192GB: Essential, Essential plus(32GB*6)
・さらに一律の上限ではなく1年間の平均を取ったメモリ容量がベースとなる

— 以下は 2011/07/13 に記載した内容 —
本日、VMware vSphere 5の発表がありました。
一番のトピックはやっぱり、ライセンス形態変更でしょう。

新しいライセンスの要点

変わらない点
・物理CPU単位でライセンスを購入

制限解除になった点
・1CPUあたりのcore数制限撤廃
・物理メモリの制限撤廃

新しい制限
・仮想マシンとして利用可能なメモリ(vRAM)という概念導入
・1ライセンスあたりの利用可能メモリ(vRAM)が決まっている
 24GB: Essential, Essential plus, Standard
 32GB: Enterprise
 48GB: Enterprise plus
・同じvCenterに登録しているESX間であれば未使用分のvRAMの融通可能

(ちなみにフリーのvSphere Hypervisorは8GBとのこと)

さて・・・具体的な話にしましょう

サーバ: 2CPU 4coreで、合計8core。メモリは48GB

という環境を考えます。
vSphere4であれば、ESXのライセンスが2つです。
vSphere5でも、ESXのライセンスが2つです。

サーバ: 2CPU 4coreで、合計8core。メモリは96GB

という環境の場合はどうでしょうか?
vSphere4であれば、ESXのライセンスが2つのままです。
vSphere5では、違います。
同じようにライセンスを2つ買うだけでは、48GB(Standardの場合)/64GB(Enterpriseの場合)までしか使えません。
メモリをフルで使うには、以下の様になります。
Standardの場合: 4つ
Enterpriseの場合: 3つ
Enterprise plusの場合: 2つ

サーバ: 2CPU 4coreで、合計8core。メモリは128GBでは、以下の様になります。
Standardの場合: 6つ
Enterpriseの場合: 4つ
Enterprise plusの場合: 2つ

ただ、若干、救いはあります。
それは、VMware HAやVMware DRSを使用している場合です。
ESXサーバが1台とか停止しても、運用ができるようメモリに余力があるように構成しているはずです。

このような場合、仮想マシン用に使用されていないメモリ、というのは、vRAM容量にカウントされません。

例えば、VMware HAの極端な構成例として

・サーバ 2台
・各サーバ 2CPU 4coreで、合計8core。メモリは128GB
・上で動かす仮想マシンの合計メモリ容量は110GB

このような場合、必要なライセンス数は以下の様になります。
Standardの場合: 最低限必要数4つ(24GB*4=96GB) + 足らない分 1つ(24GB)= 計5つ
Enterpriseの場合: 4つ(32GB*4=128GB)
Enterprise plusの場合: 4つ(48GB*4=192GB)

なので、VMware HA前提で、さらに各ESXごとに余裕をもって設計をしていれば、影響は薄いでしょうが、VMware HAを組まずにひたすら上に仮想マシンを載せるような設定をしている場合は、甚大な影響を受けてしまう変更と言えます。

vSphere ESXのパス選択方法の変更


IBM SVCなるものを導入し、VMware vSphere ESX/ESXiで使用することになったわけだが、設定に微妙な点を発見した。

それは、ESX/ESXi側でマルチパスの設定変更が必要だと言うこと。

まず、現状、どんな設定になっているのかを確認するために、ESX/ESXiにsshでログインして「esxcli nmp device list」と実行した。 (ESXi 6.xでは esxcli storage nmp device list )

~ # esxcli nmp device list

naa.xxxxxxxxxxxxxxe9d80000000000002d
    Device Display Name: IBM Fibre Channel Disk (naa.xxxxxxxxxxxxxxe9d80000000000002d)
    Storage Array Type: VMW_SATP_SVC
    Storage Array Type Device Config: SATP VMW_SATP_SVC does not support device configuration.
    Path Selection Policy: VMW_PSP_FIXED
    Path Selection Policy Device Config: {preferred=vmhba2:C0:T3:L11;current=vmhba2:C0:T3:L11}
    Working Paths: vmhba2:C0:T3:L11

ずらずら~
~ # 

マルチパスに関する設定は「Path Selection Policy」がソレになる。

現状は「VMW_PSP_FIXED」となっている。

これは、とりあえずアクセスできたパスをずっと使い続け、そのパスが死んだ時に初めて違うパスを使ってみよう、という「固定」の方法となる。

次に、ESX/ESXiで設定できるマルチパスの方式としてどんなものがあるのか?というのを確認するため、「esxcli nmp psp list」コマンドを実行する。 (ESXi 6.xでは esxcli storage nmp psp list )

~ # esxcli nmp psp list
Name              Description
VMW_PSP_FIXED_AP  Fixed Path Selection with Array Preference
VMW_PSP_MRU       Most Recently Used Path Selection
VMW_PSP_RR        Round Robin Path Selection
VMW_PSP_FIXED     Fixed Path Selection
~ # 

方式としては4種類あることが分かる。

それぞれについて簡単に解説をすると・・・


「VMW_PSP_MRU / 最近の使用」

最近使ったパスを優先して使う。

Active/Passive型RAIDの場合の標準設定。

LSI Logic OEM系のRAIDだとコレ。IBM DS3xxx、DS4xxxx、DS5xxxが該当になるはず。

「VMW_PSP_FIXED / 固定」

最初にアクセスできたパスをずっと使い続け、そのパスが死んだ時に初めて違うパスを使ってみようかな。という感じの使い方。

そして、最初にアクセスしたパスが復旧したら、まだ戻る。

Active/Active型RAIDの場合の標準設定。

「VMW_PSP_FIXED_AP」

基本はVMW_PSP_FIXEDと同じだが、Active/Passive型RAIDや、ALUAモード対応RAIDにも対応させた形式。

ちなみにALUAとは非対称論理ユニットアクセス(Asymmetric Logical Unit Access)で、SCSI SPC-3の使用として規定されたI/Oパス決定の仕組みです。詳しく知りたい人はEMC CLARiX 非対称アクティブ/アクティブ機能(ALUA)詳細レビューで解説されているので、参考にしてください。

「VMW_PSP_RR / ラウンド ロビン」

複数あるパス間で、バランスを取りながら使用していく形式。

Active/Active型のRAIDでないと使えない形式。


以前のIBM SVCはマルチパスの仕組みがちょっといけてないところがあったようですが、現在のIBM SVCではかなり改善されているようで、「VMW_PSP_RR」が使用できるようになっています。

しかし、設定の現状をみると「VMW_PSP_FIXED」。

まず、システムに登録されているストレージごとのパス利用方法の既定値(デフォルト)を確認するために「esxcli nmp satp list」を実行します。 (ESXi 6.xでは esxcli storage nmp satp list ) 

~ # esxcli nmp satp list
Name                 Default PSP       Description
VMW_SATP_SVC         VMW_PSP_FIXED     Supports IBM SVC
VMW_SATP_SYMM        VMW_PSP_FIXED     Placeholder (plugin not loaded)
VMW_SATP_MSA         VMW_PSP_MRU       Placeholder (plugin not loaded)
VMW_SATP_LSI         VMW_PSP_MRU       Placeholder (plugin not loaded)
<略>
~ # 

SVCの場合、「VMW_PSP_FIXED」と定義されているのがわかる。

調べてみると、IBM SVCの以前のバージョンでは固定だったらしい。

仕方が無いので手動で変更。

GUIから変更することも可能ではありますが、ディスク数が多いと、全部に対して手動で変更する必要があるので非常に大変なので、コマンドで変更した方がいいでしょう。

「esxcli nmp device setpolicy –psp VMW_PSP_RR –device デバイス名」で変更できます。(ESXi 6.xでは esxcli storage nmp device set –psp=VMW_PSP_RR –device=デバイス名)

とりあえず、ESXiでsshログインを有効にしてから、sshでログインして、SANで認識されているディスクはすべてRound Robinに設定、というものすごくおおざっぱなコマンドを実行する感じになります。

for device in `esxcli nmp path list|grep "Device: "|awk '{ print $2 }' | grep naa`
do
	esxcli nmp device setpolicy --psp VMW_PSP_RR --device $device
done

上記のスクリプトは

現行のVMware ESX/ESXi 4.0/4.1に置いて、SANのディスクは「naa.xxxxxxx~」という感じの名前で認識される。
なので、対象となるデバイス名を取り出して、それに対してパスを設定する、ということを行う。
といったもの。

エラー処理とかは一切考えていないので、ちゃんと設定できたかどうかは別途確認してください。

Proxmox Virtual EnvironmentでOpenVZのテンプレートが出てこない



Proxmox Virtual Environment(PVE) 1.7を使用中。

PVEはDebianベースでOpenVZとKVMによる仮想化を実現するアプライアンスを作るディストリビューション。
管理はCLIもしくはWeb。
複数のPVEサーバをある程度統合管理が可能。

最初はCitrix XenServerでやろうかな?と思っていたんだけど、フル仮想化だとメモリを食うので、たくさんたてられるOpenVZを使えるこいつに目をつけてみた。

で、OpenVZ用のテンプレートが使えるかな?と思って、「/var/lib/vz/template/cache」にSabayonからダウンロードしたテンプレートファイル “Sabayon_Linux_SpinBase_5.4_x86_openvz.tar.gz”を配置してみた。
が、ProxmoxのWeb GUIの仮想マシン作成メニューで表示されない。

う~ん・・・とファイルを見比べてみる。

# ls /var/lib/vz/template/cache
Sabayon_Linux_SpinBase_5.4_x86_openvz.tar.gz
centos-4-default_4.8-20100922_i386.tar.gz
centos-5-standard_5.2-1_i386.tar.gz
debian-5.0-wordpress_2.9-1_i386.tar.gz
ubuntu-10.04-lamp_10.04_i386.tar.gz
#

ファイル名の法則が違う?

というわけで、ファイル名を「sabayon-5-SpinBase_5.4-1_i386.tar.gz」に変更してみた。
無事認識。

で、Sabayon 5.4のOpenVZを作成して起動してみたんですが・・・ネットワークインタフェースを認識していない・・・
なんでかなぁ???う~ん・・・・

# vzctl start マシンID
Warning: configuration file for distribution sabayon-5-SpinBase_5.4-1_i386 not found, using defaults from /etc/vz/dists/default
Starting container ...
Container is unmounted
Container is mounted
Adding IP address(es): IPアドレス
/bin/bash: line 394: /etc/network/interfaces: No such file or directory
grep: /etc/network/interfaces: No such file or directory
/bin/bash: line 407: /etc/network/interfaces: No such file or directory
/bin/bash: line 429: /etc/network/interfaces: No such file or directory
cp: cannot stat `/etc/network/interfaces': No such file or directory
/bin/bash: line 458: /etc/network/interfaces.bak: No such file or directory
mv: cannot stat `/etc/network/interfaces.bak': No such file or directory
Setting CPU units: 1000
Setting CPUs: 1
Set hostname: ホスト名
File resolv.conf was modified
Setting quota ugidlimit: 0
Container start in progress...
#

なるほど、起動時に読み込むテンプレートが適切じゃないせいなのね。

OpenVZのフォーラムで参考記事を発見。

/etc/vz/conf/各マシンID.conf 内の「OSTEMPLATE=”sabayon-5-SpinBase_5.4-1_i386″」が関係してると。
テンプレート自体は/etc/vz/distsにあるので、Sabayonに近いものは?と見てみると、ありました「gentoo.conf」(SabayonはGentooベースなのです)
てっとりばやく「ln gentoo.conf sabayon-5-SpinBase_5.4-1_i386.conf」を実行してから、起動!

# ln gentoo.conf sabayon-5-SpinBase_5.4-1_i386.conf
# vzctl start マシンID
Starting container ...
Container is mounted
Adding IP address(es): IPアドレス
Setting CPU units: 1000
Setting CPUs: 1
Set hostname: ホスト名
File resolv.conf was modified
Setting quota ugidlimit: 0
Container start in progress...
# 

これで、無事、ネットワーク接続も完了です。

VMware Data Recoveryで延々とWindowsアカウントが要求される



VMware Date Recovery ver 1.2を評価してみようとしてはまった。

現象
1. Windows 2008R2 でvCenter Server 4.1を立てる
2. そのWindows 2008R2にvSphere ClientとData Recovery pluginを入れる
3. vSphere ClientからData Recoveryの構成をしようとしてみる
4. Windowsのアカウント名が表示され、そのパスワード入力欄が出る
5. 入力する
6. また、パスワード入力欄がでる
7. 延々繰り返し

DNSの正引き、逆引き関連だ、という話があったので、専用にDNSを立ててみても現象変わらず。

もしや、と思い、同じネットワークのほかのマシンにvSphere ClientとData Recovery pluginを入れてみた。

1発成功。
Windowsファイヤーウォール無効化とかも必要なかったよ

で、1回構成しちゃうと、いままでだめだったvCenter Server自身で起動したvSphere Clientからも接続可能に。

今回、何がわからんかったかというと、Data Recovery pluginの動作に関するログがどこに出力されるのか?ということ。
あと、Data Recovery VMでのログも
Collecting diagnostic information for VMware Data Recoveryで取得できるログを見てみたけど、今回の現象に役立つメッセージらしきものはなし。

いったい、どこを見ればよかったんだろうなぁ?

参考:VMware Data Recoveryの仮想マシンにログインしたい場合、そのデフォルトパスワードはver 1.2のマニュアルの24ページにあるように「vmw@re」です。(ver 2.0でも同じです)

RAMCloud



現在、目下開発中で、あまり安定していなそうですが、今後期待できそうなものの紹介

・John Ousterhout project: RAMCloud

サーバに搭載されているRAMを利用して、それらを統合し、1つのストレージとして使うためのソフトウェアを開発中。

RAMCloud wiki

RAMCloud Presentationsにある「RAMCloud overview (Feb. 2010)」を見るのがわかりやすいと思う

サーバ間連携はInfiniband。
Cluster Intro より画像引用

現状はgitツリーでの配布のみっぽく、開発対象Ubuntu
ちなみに、General Information for Developersのページには「Debian (and probably Ubuntu)」とあるけど、取得したREADME.txtを見ると「1.1 Pre-requisites (Ubuntu)」とある。(2012/01/06の段階でも)

(2012/01/06 リンク先のページ構成が変わった点を修正)