投稿者: osakanataro

Tweet

Check

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

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

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

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

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

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

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

Tweet

Check

まずは、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を使ってね)

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

Tweet

Check

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)
・さらに一律の上限ではなく１年間の平均を取ったメモリ容量がベースとなる

— 以下は 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とのこと)

[送料ˆ～]上海問屋オリジナル microSDHC(マイクロSDHC)カード 16GB (Class10)：上海問屋オリ… 価格：2,899円（税込、送料別）

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

サーバ: 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を組まずにひたすら上に仮想マシンを載せるような設定をしている場合は、甚大な影響を受けてしまう変更と言えます。