vSphere 5.1関連の追加点・変更点

VMwareのwhitepaper類をあさってピックアップしたvSphere 5.1での追加点・変更点から、個人的に注目するポイントのみを紹介。

なお、ここに記載した見解は誤っている可能性があります。
鵜呑みにせず、原本資料などを当たってみてください。


vMotion関連の機能拡張
「vMotionとStorage vMotionを同時実施」およびそれを拡張した「共有ディスク無しのvMotion」。
KVM,Xenなどでできる共有ディスク無しで稼働中のVMをについて物理サーバを移動させるということが可能となった。
vMotion/Storage vMotionが同時に利用できることを「“Unified” vMotion」と呼ぶようだ。

ネットワーク経由でディスクイメージを転送するためにかかる時間短縮のための拡張も入っている。
「VMFS5利用時にvMotion速度改善」
ディスクイメージの転送方法を見直し、1つのディスクイメージを複数に分割し、並列転送をさせることで、VMFS3利用時に対して7割程度の速度になる。

「vMotion利用時の複数枚NICのロードバランス」
2枚以上のNICをvMotionに割り当てた場合に、前項目の「並列転送」の処理をそれぞれのNICに割り当て負荷分散を図るようになった。

(2013/02/18追記:VMware Communityにて「PowerCLI 5.1で x-vMotion」という日本語解説が書かれていました。旧来のvSphere Clintからは実行できない、とのこと)


vSphere Replication

以前からVMware SRMというDR向けソリューションがある。
仮想ディスクイメージの同期を取り、災害時にDR先で継続できる、という仕組みである。
VMware SRMを利用する場合の利点というのは「DR先でIPなどが変わる場合に自動的に変更した上で起動させることができる仕組み」とか「本番環境に影響させないようにDR検証ができる」だと思っている。

このVMware SRM、最初はVMware SRMに対応した高級なストレージが必須となっていた。
vSphere 5.0になり、専用ストレージでなくとも、仮想アプライアンスとして提供される仕組みを利用して通常のストレージでもVMware SRMが可能となっていた。

この仮想アプライアンスとして提供された仕組みの部分を今回「vSphere Replication」として切り出したような形となっている。

VMware SRM相当のことを行うには、人間が手を動かす必要がある、という感じである。

というか、DRのことまで含まれてしまうと3rdパーティーの仕組みを提案しにくくなるのですが・・・・


vCenter Server関連の拡張点
vSphere 5.0ではWindowsライセンスを必要としないvCenter Serverとして、LinuxベースのvCenter Serverアプライアンスが提供され始めた。
vSphere 5.1では、それをさらに進め、Windowsを利用しないでも大丈夫なようになりつつある。

「vCenter Single Sign-On Server登場」
いままでvCenter Serverのユーザ認証はWindowsユーザ認証に依存していた。
それを「OpenLDAP」「Active Directory」「NIS」によるユーザ認証で行えるようにした。

「vSphere Clientの終息」
vCenter Serverの管理はWindows上で起動するvSphere Clientから行う、というものだったが、vSphere Clientソフトウェアの更新が終息気味となっている。(まだ使える)
代替としてはvSphere 5.0から登場した「vSphere Web Client」となる。
vCenter Single Sign-On Serverやいろんな新機能を使う場合に、vSphere Clientは利用できない。


仮想マシンに対する拡張
毎回、いろんな制限が拡張されていますが、もちろん今回もあります。

「64CPU,メモリ1TBの仮想マシンが作成可能に」
仮想マシンハードウェアversion9が登場し、64CPU/メモリ1TBをサポート。
3Dグラフィックアクセラレーション関連もサポート。

「VMware Toolsの大幅改変」
いままでVMware Toolsはカーネル系のモジュールやドライバをインストールしていたため、VMware toolsのバージョンアップ時にOSの再起動が必要となっていました。
それをOS再起動が不要な構造とした、とのことです。
(ただし、おそらくVMware Tools with vSphere 5.0からVMware Tools with vSphere 5.1へアップデートする際は、再起動が必要になりそう)


各種I/Oに関する強化
「Storage DRS強化、Storage I/Oコントロールも強化」
Storage DRS 2.0!とか謳うぐらいに強化している・・・ということなんだけど、いまいち使いどころが見えない。
大規模環境で負荷分散できるらしいが・・・

「VMware vSphere APIs Arrary Integration(VAAI) snapshot」
VAAIというVMwareからストレージの機能を制御する仕組みに機能追加。
仮想マシンのsnapshotを取る際に、VAAIを利用してストレージの持つsnapshot機能動作させ、ESXi側の処理を軽減させる。

「vSphere Distributed Switch(VDS)の機能強化」
各種limitの拡張、LACPサポートなど、細かい点はさておき、地味に重要な修正がありました。

「VDS関連設定情報のバックアップ/リストア手法を改善」
VDSに関する設定は、いままでSQL DBの中に入っていたのですが、それに関するバックアップ/リストアの仕組みがちゃんと用意されていませんでした。
それをちゃんと用意したようです。
とはいえ、バックアップを取っていないと、vCenter Serverが全損した際に、VDSを1から再作成する必要がある、という点は変わらないようです。

「Single-Root I/O仮想化(SR-IOV)サポート」
PCIeのNIC側で仮想マシンに関するI/O処理を委託する機能
CPUのオフロードがはかれますが・・・まぁ、基本的に10Gb-NIC向けですね。


vSphere Data Protection(VDP)の拡張
VMware純正のバックアップソリューションが少し機能強化。

「VDPの利用数制限を緩和」
1台のvCenter Serverで管理できるVDP総数が10台。
1台のVDPで扱えるバックアップ対象となる仮想VMが100台。

「バックアップの保存先ディスク制限緩和」
いままで1TBディスク*2=2TBが最大だったものが少し拡張された。
0.5TB*3=実効容量 850GB
1.0TB*3=実効容量1300GB
2.0TB*3=実効容量3100GB
なぜ、実効容量がこんなにも減るのかは説明がなかったので不明。

「VDPアプライアンスの要求スペック上昇」
ただ、マイナス点があって、VDPアプライアンスとして必要な仮想環境が4vCPU、4GBメモリを要求しているという点。


Auto Deploy強化
大規模環境ではいちいち各物理サーバに対してESXiをインストールするのがめんどいわけです。
それを簡略化するために、PXEブートでESXiを起動させる仕組みAuto Deployに機能強化が入りました。

vSphere 5.0では完全ディスクレスの「Stateless」のみだったものが、
「Stateless」「Stateless caching」「Stateful installs」の3種類の選択可能になりました。

「Stateless caching」
サーバローカルのUSB/HDD/SAN Diskにブートイメージとか設定情報を置くが、別に消えてもかまわない状態

「Stateful installs」
サーバローカルのUSB/HDD/SAN Diskに対してESXiを自動インストールする

まぁ、用途に応じて使い分ける、という感じになるのでしょうか?


細かい変更点

「ESXiのrootユーザの扱いが変更に」
サポート用などでshellログインする際にrootアカウントが使えなくなった。
一般ユーザでログインし、suでroot権限を取得する必要がある
まぁ、ESX4.0ではそうなってたので、前の仕様に戻した、という気もしますがね。

「VMware View向けの機能拡張」
VMware View環境向けにいろいろ機能が追加されている。
Win7/Win8上でWindows XP Modeを利用してWindows XPアプリを動作させる、という場合に、それを補助する仕組み、というのは、かなりアレなものだと思う。

また、VDIでは1つのディスクイメージから複数の仮想マシンを立ち上げユーザ毎に割り当てる、とかいう運用をする場合がある。
その場合は、VMごとに差分データがあり、増えていくことになるが、基本的に減ることはない。
それを利用していない領域については減らしたり、整理したりすることができるようになるらしい。


とりあえず、気になったところとしては、こんなところです。

vSphere 5.1が発表、ライセンス制限の変更

VMworld 2012が開催されています。
そこで、vSphere 5.1が発表されました。

vSphere 5.1は、2012/09/11提供開始。
ライセンスは1CPU単位という点は変更無し。
CPUコア数、vRAM容量、仮想マシン台数の制限は撤廃。
一番下は1ライセンス$83から。

VMware vSphere Essentialsは$495。
VMware vSphere Essentials Plusは$4495
EssentailsのESXiホスト3台までで合計CPU数は6、というのは引き続き。

上のエディションでの機能差については、詳しい資料待ちといったところ。

VMware公式のvSphere blogに各種リリースへのリンクあり:The Best Keep Getting Better – VMware vSphere 5.1 Performance


ライセンスについての詳細がありました。
VMware
vSphere 5 Licensing, Pricing and Packaging WhitePaper

新しいライセンスはvSphere 5.0およびvSphere 5.1の双方で有効とのこと。
つまりは、vRAM制限が撤廃です。

エディションは3種類+αです。
Compare vSphere Editions
「Standard」、「Standard with Operations Management」、「Enterprise」、「Enterprise Plus」
StandardにFault ToleranceおよびStorage vMotionとか、いままでEnterprise以上だったものがいろいろが含まれているのが注目点かもしれません。

なお、「Standard with Operations Management」という枠が出来ていますが、だからといってEnterprise/Enterprise plusにはOperations Managementが含まれて折らず、別売となっています。

Nimble Storage

2013/05/21追記

Nimble Storageについて 2013年版」にて最新情報を公開しています。
また、以下の記述には、間違った情報が含まれていますので、きちんとした情報を知りたい人は上記のURLにアクセスしてください。


Nimble Storageというプロダクトがあるらしい。

うたい文句をみるとTintri VMstoreと似てる感じがするなぁ・・・と思いつつ内容を確認。

コントローラヘッド筐体+SAS接続のディスクShelf、というのが基本形。
そこから性能を上げる選択肢がいくつかある。

・1セットの容量を増やすためには、ディスクShelf追加
・パフォーマンスアップのためにSSD追加
・さらパフォーマンスと容量を上げるには、別セットを用意し連携させる
Nimble Storage Technology & Features Primer」より

「Base Flash Capaticy」「x2 Flash Capacity」「x4 Flash Capacity」という感じの3種類があり、低ランクではBaseしかないし、高ランクだとx2/x4だけだし、という感じで、アクセス速度はここのSSDによるキャッシュに依存しているようだ。
(現状は2400GBが最大上限である模様)

で・・・ディスクShelfの方のスペックを見てみると、こちらにも「Flash Capacity」とある。
コントローラヘッド内にも(PCIeの)SSDがあるのか、それとも、ディスクShelf側にHDDの代わりにSSDを入れて高速化を図るのか、どちらなのかがよく分からない。

もし、ディスクShelf側にSSDを入れるとなると、全体容量が犠牲になるわけですし、評価が難しいところ。

サーバとNimble Storageの接続はiSCSIである模様。
VMware / Hyper-V / Citrixで使える、ということになっている。

以下は参考資料

BEST PRACTICES GUIDE: Nimble Storage Best Practices for Scale-Out

BEST PRACTICES GUIDE: VMware on Nimble Storage
BEST PRACTICES GUIDE: Nimble Storage Best Practices for Microsoft Hyper-V R2
BEST PRACTICE GUIDE: Nimble Storage for VMware View VDI

VMware ESX環境でWindows 8とWindows Server 2012を動かすには?

VMware ESX環境で、Windows 8とWindows Server 2012を動かすには、相応の設備がいる、という話。

元ネタ
ESXvirtualization の「Windows 8 and Windows Server 2012 Release Preview on ESXi 5 ? does it work?」より
VMware KB 2006859:Windows 8 operating system does not boot or install on ESXi or ESX

VMware環境編
・ESXi 5.0 + パッチ ESXi500-201112001以降が必須
・公式としてはTech Previewとしてではあるが、ESXi 5.0 Update 1以降
・ESXi 4.1など4.x台では動かない

仮想マシンのハードウェア設定編
・Virutal Machine Version 8を選択し「Windows 8」か「Windows Server 8」
・Virtual Machine Version 7の場合は「Windows 7」「Windows Server 2008R2」
・グラフィックの3D機能を有効にしてからOSインストールすること
・USB機能は動かない
・NICタイプのvmxnet3動かない。e1000eかe1000を選択すること

仮想マシン上のWindows設定編
・Windows OS上にVMwareのWDDM Videoドライバをインストールしない
 VMware Toolsインストール時に、WDDM Videoドライバをインストールしない
 OS標準のVESAドライバを使用すること

OSインストール後、再起動したら暗いまま、という場合
下記のKBにあるような設定変更を行う。

VMware KB 2021887:Windows 8 Release Preview and Windows Server 2012 Release Candidate fail when starting for the first time after the installation

VMware仮想マシンのバックアップに関する解説

VMwareで仮想マシンのバックアップを行う際に出てくる用語について、簡単にまとめてみた。

キーワード
・VMware Consolidated Backup (VCB)
・VMware vStorage APIs for Data Protection (VADP)
・VMware Virtual Disk Development Kit (VDDK)
・File-level Restore(FLR)

VMwareで仮想化を行っている場合、仮想マシンを丸ごと、動作させたままの状態でバックアップすることができる。
その際は、仮想マシン内のOS上で動作しているvmware-toolsと連携し、ファイルシステムに対してある程度の静止点を作成させ、その後にバックアップを行う、といったことが出来るようになっている。

バックアップ・リストアを行う仕組みとして、VMware Consolidated Backup(VCB)と、VMware vStorage APIs for Data Protection (VADP)の2種類がある。
VADPはvSphere4から登場した新しい仕組みで、基本的にはこっちの方が高機能である。
詳細についてはVMware KB1021175:vStorage APIs for Data Protection (VADP) FAQ に掲載されている。

VCBの場合はWindowsのみ、VADPの場合はWindows/Linuxのみであるが、仮想マシン丸ごとでバックアップしても、仮想マシン上のOS内のファイル単位でリストアすることができる。
この手法をFile-Level Restore(FLR)と呼んでいる。

FLRはどのように実現されているか、というあたりだが、実は結構アレなつくりをしている。
仮想ディスクとしてリストアした後、仮想ディスクを内部的にマウントしてリストアする。
というようなイメージでリストアが行われる。

こんな処理をまともに実装してたら、バックアップソフトベンダが死んでしまうので、VMware側で簡単にできるような開発向けのソフトウェアライブラリを用意している。
それが、VMware Virtual Disk Development Kit (VDDK)である。

VDDKは、いくつかバージョンが出ている。
VDDK 5.0
VDDK 1.2.1
VDDK 1.2
VDDK 1.1
VDDK 1.0.1

VDDKのバージョンが異なると何が変わってくるか、という点だが、基本的には新しいバージョンほど機能が増えている、ということになる。

vSphere5と共にリリースされたのがVDDK5.0ではあるが、これを使用したバックアップソフトウェアがvSphere4のバックアップに使用できないといったことは無い。

しかし、逆のVDDK 1.2.1を使用したバックアップソフトウェアをvSphere5環境で利用する場合には、いろいろ注意が必要な点が発生する。
この例の場合、VMFS-5が非サポートであるため、vSphere5環境ではSANストレージを旧来のVMFS-3(vSphere4仕様)で利用する必要が出てくる。

VDDKはバックアップソフトウェアの開発時に内部に組み込まれて使用される。
このため、あとからVDDKだけをバージョンアップするということはできず、バックアップソフトウェアベンダが新しいバージョンを開発するまで新機能は使用できない。
このため、VDDKおよび新しいvSphereリリース時は、バックアップソフトウェアによってできる機能が異なってくるという事態が発生する。

各バックアップソフトの対応については別途調べてください。