vSphere5でVMware HA(vSphere HA)が刷新


ESXサーバのActive/Standby的な冗長性を確保する機能 VMware HAは、vSphere HAという名称になった。

トピック
・仕組みを作り直した
・ESXサーバ間の死活監視をネットワークだけでなく共有ストレージも利用
・IPv6サポート

仕組みを作り直したという点が非常に大きい。

新しいHAの仕組みのトピック
・全ESXサーバでFDM(Fault Domain Manager)が動作
・どれか1つがマスタに選ばれる(マスタとスレーブに分かれる)
・マスタのESXサーバが、各ESX(スレーブ)と仮想マシンを監視する
・マスタが停止した場合、10~15秒でスレーブのうち1つがマスタに昇格する
・vCenter Serverは、基本的にマスタサーバにアクセスする

これにより、現状のPrimary/Standbyという考え方はなくなった。

・・・・・・いや、これ、Citrix XenServerの仕組みと類似ですよね。
あれはvCenter Server相当がそもそもなくて、構成しているCitrix XenServer間でマスタが1台選ばれて連携していく、という形式ですし。

よくわからない点としては、死活監視用の共有ストレージの取り扱いがある。
どうもは「Heartbeat Datastores」という名前で、自動的に2カ所のDatastoreが選ばれる、という記述がある。しかし、これが、空いているDatastoreが選択されHeartbeat専用になるのか、それとも普通のDatastoreを指定すれば共存できるのかがよくわからない。

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

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

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

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