vCenter Server 5.0でLinuxにも対応!


まずは、Center Server 5.0でWeb管理画面登場!

ようやく、といっていいでしょうか
vCenter Serverの管理画面がLinuxにも対応しました。

正確にはHTML5を利用して、IEもしくはfirefoxからアクセスできる管理画面が用意されました。
サポートOSはWindowsかLinuxです。

いままでのWindows用vSphere Client相当の操作はできるようです。

そして、「vCenter Server Appliance」

vCenter ServerをSUSE Linux(SLES 11)をベースとした仮想マシンアプライアンス、という形で提供します。(既存のLinuxサーバにvCenter Server for Linuxをインストールする、というのは想定されていないようです)

もちろん、vCenter Server ApplianceにはDBが添付されており、それを使う範囲ではESXサーバ5台/仮想マシン50台までのサポート(これは、いままでのMSSQL Express 2008での制限と同じです)
Oracleを外部DBを使うことで、ESXサーバ300台以上/仮想マシン3000台以上をサポートする、とのこと。

なお、いままで通りのWindows上でvCenter Serverをたてることもサポートしてます。
このvCenter Sevrer Applianceの弱点としては、まだ足らない機能がある、という点。
・Linked Modeがない
・IPv6非対応
・Oracle以外のDBは、現状非サポート
・vCenter Heartbeat非サポート(vSphere HAを使ってね)

まぁ、ここらへんは、なければないで、なんとかなる範囲なので、どちらかというと、メリットが大きい感じです。

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」と実行。

~ # 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」コマンドを実行する。

~ # 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」を実行する。

~ # 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から変更することも可能ではありますが、ディスク数が多いと、全部に対して手動で変更する必要があるので非常に大変です。

なので、コマンドを実行して変更するようにしましょう。

とりあえず、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~」という感じの名前で認識される。
なので、対象となるデバイス名を取り出して、それに対してパスを設定する、ということを行う。
といったもの。

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

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でも同じです)