月: 2011年7月

Tweet

Check

VMwareのバックアップ仮想アプライアンス、VMware Data Recovery。
これも、てっきりvSphere Data Recovery的な名前に変わるのかと思いきや、登場してきたのは「VMware Data Recovery 2.0」

おやおや？と思って、スペックを調べてみると、ESXi5.0だけではなく、ESX(i)4.0/4.1でも動作するとのこと。

現行のVMware Data Recoveryはバックアップ格納領域として、1TB領域が2つしか設定できないという強烈な制限があるけど、それが撤廃もしくは緩和されるかなぁ、と期待していたのですが、どうもそれはないようです。

トピック
・メールレポートを送れるようになった
・ジョブの一時停止をサポートした
・重複排除の向上
・Maintenance Scheduleという設定が加わった・・・が既存のBackup Window設定と何が違うのかが理解できない

おまけ:VMware Data Recoveryの基本的な注意点
・バックアップスケジュール、という概念がない
　→ 指定時間帯のどこかでバックアップが実行されている。細かい時間は指定できない。
・フルバックアップ・差分バックアップという概念もない
　→ 合成バックアップ的な動きをしていくので、過去のバックアップを何個残すか、という設定になっている。
・リストア時は基本仮想マシン全体、と思っておいた方がよい
　→ Windows/Linuxでvmware-toolsがインストールされていればファイル単位でリストアできるが、面倒。
・バックアップ保存領域が小さい
　→ 「1TB仮想ディスク」か「500GB CIFS共有」が合計2個までしか設定できない
　　　それ以上をバックアップしたい場合には、使えない

— 2012/07/24 追記 —
VMware Data Recovery 2.0.1でも、ここらへんの事項は変わっていません。

Tweet

Check

vSphere 5でのHypervisor部分のアップデート内容について書いてなかった。

・ESXiのみになる
　Service ConsoleつきのESXは完全に消えました。

・仮想マシンが32CPU、1TBメモリに対応
　ただしEnterprise plusのみ。それ以外は8CPU。
　仮想マシンに割り当て可能なメモリ容量のエディションごとの制限はおそらくない
　(そもそも、物理マシン自体の方で利用可能なメモリ容量が定義されているから)

・Windows Aeroが表示できる程度の3Dグラフィック対応
　専用GPUなどは必要ないようだ。
・vSphere Client端末に接続したUSB3.0のデバイスを仮想マシン上で使用できる

・仮想マシンがBIOSではなくUEFIになった
　・Hardware version 8登場
　・ESXi5.0では Hardware version 3の仮想マシン非対応(アップデートは可能)
・仮想マシンとしての「Mac OS X server」をサポート

・VMFS5が登場
　・2TB以上のLUNに対応(64TB LUNまで利用可能)
・SSDに対するスワップ処理とかが改善
・汎用NICを使用してのFCoEに対応(ソフトウェアFCoE)

・ESXiを管理するコマンドが一部変更
　esxcfgは廃止。esxcliに変更。
　vicfg, vmware-cmd, vmkfstools, PowerCLIは継続。
・ESXiのインストールイメージ作成機能(ESXi Image Deployment)
　Image Builderというソフトを使って、ESXiのインストールテンプレート作成
・ESXiの自動インストール機能 Auto Deploy
　PXEブートさせてImage Builderで作ったカスタマイズESXiをインストールする機能
　Hotprofile適用まで行ってくれる。

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