Home > Blogs > Japan Cloud Infrastructure Blog > 作成者別アーカイブ: Hiroshi Okano

作成者別アーカイブ: Hiroshi Okano

vSphere 5.5 の新機能紹介 vSphere Flash Read Cache (vFRC)

このBlogは、製品出荷前のバイナリ及びマニュアルをベースに記載しています。出来る限り正確な情報をお伝えするよう努めておりますが、実際に製品に搭載される機能や表示とは異なる可能性があります。あらかじめご了承の上、ご利用下さい。

今回は、vSphere 5.5の新機能である、vSphere Flash Read Cacheをご紹介します。

NAND型のフラッシュメモリを利用した高速なストレージデバイスであるSSDは、既にコンシューマー用途からデータセンター用途まで幅広く利用されています。既存のvSphere5.1では、以下の2つの用途でSSDを利用することが可能でした。

1. 通常のデータストアやRDM (主に仮想マシンファイルを配置)
2. ESXホストのvmkernel swap領域 (ホストメモリ不足の際の待避場所として利用)

一言にSSDと言ってもSANやNAS、iSCSI等のリモートストレージに搭載されたSSDと、個々のServerに搭載されたLocal SSD がありますが、前者は1の目的で利用され、後者は共有ストレージとしての利用が難しいことから主に2の目的で利用されてきました。

vSphere5.5ではこの2つに加え、個々のServerに搭載されたLocal SSDを、仮想マシンのRead Cacheとして利用することが出来るようになります。これが、今回ご紹介するvSphere Flash Read Cache (vFRC)です。これまで限定されていたServer本体に搭載されたSSDの利用が、vSphere5.5からは仮想マシンのパフォーマンス向上のため、より簡単に利用できるようになります。

vFRC概要

vFRCは、仮想ディスク(VMDKファイル)のリードキャッシュとして、Localサーバに搭載したSSDを利用する仕組みを提供します。この機能を利用することにより、下記2つの効果が期待できます。

・仮想ディスクの読み込み速度の向上
・vmdkファイルが配置されたストレージ負荷の軽減

この機能を提供するため、ESXiホストは、自身に搭載されたSSD上にvFlash File System (VFFS)を作成します。このVFFSは仮想マシンへのキャッシュアクセスを提供する専用のDiskリソースで、通常のVMFS領域と異なりデータストアとしては見えません。VFFSが構成されたESXiホスト上の仮想マシンはvFRCの利用が可能となります。

vFRCの特徴

・Localサーバに搭載されたSSDを利用(リモートSSDは利用不可)
・仮想ディスクに対するリードキャッシュ、ライトスルーキャッシュとして機能
・ESXi 5.5以降及び、仮想マシンバージョン 10 以降が必要
・操作はvSphere Web Client でのみ可能(従来のc# 版での操作は不可)
・ホストに搭載したLocalのSSDのみ利用可能
指定可能なデバイスは最大8台
デバイス 1台の最大容量は4TB
ホストあたり最大32TB (4TB x 8台)*
・VFFSに指定したデバイスは、VMFS領域やvSAN領域として利用することは出来ない
・VFFSはホスト毎に1個作成される
・仮想Disk毎にvFRC利用の有無と容量の設定が可能(初期設定はDisable)
ブロックサイズは4KB~1024KBで設定が可能
・各仮想マシンに設定されたvFRC領域はパワーオン時にVFFS領域に対して予約される(VFFS領域のオーバーコミットは不可)
VFFSの容量が足りないと仮想マシンのパワーオンが出来ない
・VFFS はホスト固有であり、ホスト間でのシェアはされない
vMotion時、vFRC領域の同時移行も可能(破棄することも可能)
・vFRCをEnableに設定した仮想マシンは、vFRCがEnable化されたホストでのみ稼働可能
vFRC がDisableとなっているホストへのvMotionやHAは不可
・DRSのリソース管理においてはvFRCのアンバランスは考慮されない
・vFRC設定をされた仮想マシンは、DRSではホストとのSoft Affinity設定(可能な限り移行しない)となる

*ホストあたり管理可能なフラッシュの最大量です。うちvFRCで利用可能な領域は最大2TBとなります。
最新の情報は、構成の上限をご確認下さい。

vFRCの設定方法

vFRCの設定は極めて簡単です。ホスト側にVFFSを定義し、仮想マシン側でvFRCの利用設定を行います。

ホスト側の設定:VFFSの定義

1. vSphere Web Clientに接続
2. 設定を行うホストを選択し、”管理”タブ → ”設定” → ”仮想フラッシュリソース管理” を選択
3. 容量の追加をクリック

4. ホストに搭載されたSSDデバイスのリストが表示されますので、vFRCで利用するデバイスを選択します。

※ホスト側にこの設定を施すことにより、VFFS領域が作成されます。

次は仮想マシンに対する設定です。

仮想マシン側の設定:vFRCの設定

5. vFRC設定を行う仮想マシンを右クリックして”設定の編集”を選択
6. vFRC設定を行う仮想ディスクを展開し、”仮想フラッシュ”の詳細をクリック

7. 仮想フラッシュの有効化にチェックを入れ、キャッシュ容量とブロックサイズを指定します。

以上で完了です。

手順6、7を繰り返す事により、複数の仮想ディスクに対して設定を行うことも可能です。

また、この手順は仮想マシンがパワーオンの状態でも行うことが出来ます。

vFRCとvMotion

VFFSはホスト毎の管理となるため、仮想マシンがvMotionで移行してしまうと旧ホスト上のリードキャッシュは利用できなくなります。このためvSphere5.5のvMotionでは、vFRC設定が施された仮想マシンを移行する際、vFRC領域も同時にコピーを行う仕組みが提供されています。技術的には、vSphere5.1で実装された、XvMotion(Storage vMotionとvMotionの同時実行)の仕組みを利用しています。

リードキャッシュですので、vMotion時にドロップすることも可能です。この際は、移行先のホストで自動的に再作成されます。XvMotionの仕組みを使ってvFRCをコピーするか、ドロップするかは、vMotionウィザードの中で選択可能です。

コピーを選択すると、移行先でも蓄えたリードキャッシュをそのまま利用することが可能ですが、移行時にはvFRCのコピーにまつわる時間と負荷がかかります。

統計情報

vFRCに関する統計情報は、vSphere Web Clientやesxcliコマンドを利用して取得することが可能です。

1. vSphere Web Clientでは、該当する仮想ディスクに対し、以下のパラメータが新たに追加されました。

・vFRCキャッシュIOPs
・vFRCキャッシュスループット
・vFRCキャッシュ遅延

2. esxcliでは、”esxcli storage”に vflash というNamespaceが新たに追加され、例えば、esxcli storage vflash cache list コマンドでは作成されているvFRCのキャッシュファイルリスト、esxcli storage vflash cache stats get -c <Cache File Name> コマンドでは、特定のvFRCに対するキャッシュのヒット率やキャッシュIO数などの統計情報の確認が可能となりました。

まとめ

仮想ディスクへの読み込み速度の高速化とストレージ負荷の削減を実現するvFRC。以下のような環境に利用すると特に効果的です。

・読み込みの多いアプリケーションを仮想マシン上で稼働させる場合
・vmdkファイルを配置するStorageの性能よりも、VFFSを構成するSSDの性能が大幅に高い場合
・vmdkを配置したStorageの読み込み負荷が大きく、この負荷を軽減したい場合

是非ご利用下さい!

また、vFRCのパフォーマンスに関するTechPaperも公開されました。こちらも是非ご一読下さい。

http://www.vmware.com/files/pdf/techpaper/vfrc-perf-vsphere55.pdf

 

VMware ESXi イメージ管理ベストプラクティス その2

イメージプロファイルの操作

前回、その1でVMware ESXiのイメージをカスタマイズすることの意義や、イメージプロファイル等についてご説明致しました。
今回は、そのイメージプロファイルを操作する手法についてご説明します。

イメージプロファイルの操作にはImage Builderを使います。Image Builderは、vSphere PowerCLIで提供されるコマンドレットの1つで、以下の様な機能を提供します。

 ・既存のイメージプロファイルへのVIBの追加や削除
 ・イメージプロファイルの新規作成
 ・イメージプロファイルを指定したISOイメージ、オフラインバンドルのエクスポート

イメージプロファイルへのVIBの追加

追加作業にはImage Builderのコマンドレットを利用しますが、vSphere PowerCLIをご利用いただいている方であれば特にImage Builderを意識する必要はありません。例えば、既存のイメージプロファイルにダウンロードしてきたドライバ等のVIBを追加するための手順は以下の通りです。

 1. VIBの入手
VMware、サーバベンダー、デバイスベンダー、アプリケーション(vCD/vShieldManager)等からオフラインバンドルに含まれる形で提供
 2. ベースとなるイメージプロファイルとVIBをImage Builderに登録
3. 既存のイメージプロファイルにVIBを追加
4. オフラインバンドルやISOとして書き出す

具体的に、手順2以降は、

2-1. vSphere Power CLIを起動して、VIBを含むオフラインバンドルをImage Builderに登録

 > Add-EsxSoftwareDepot c:\filepath\xxxx-offline_bundle-xxxx.zip

2-2. VIBに定義された名前を確認

 > Get-EsxSoftwarePackage

※Nameの欄に記述されています、この例では、”net-ixgbe” です。

2-3. ベースとなるイメージプロファイルを含むオフラインバンドルをImage Builderに登録

 > Add-EsxSoftwareDepot c:\filepath\VMware-ESXi-5.1.0-xxxxxx-depot.zip
 > $ip = Get-EsxImageProfile

※イメージプロファイルを操作するため、変数に代入しておく。


※イメ-ジプロファイルは通常複数(vmware-toolsを含む物、含まない物の二つ)存在します。上記例では、

 $ip[0]・・・no-tools
 $ip[1]・・・standard (vmware-tools込みのイメージプロファイル)

です。どちらかを選択してVIBを追加することになります。

3-1. 既存のイメージプロファイルを指定して、新しいイメージプロファイルをクローンにて作成

 > New-EsxImageProfile -CloneProfile ($ip[0] or $ip[1]) -Name (New_Profile_name) -v (Vendor_Name)

3-2. 新プロファイル名を指定してVIBを追加

 > Add-EsxSoftwarePackage -ImageProfile (New_Profile_name) -SoftwarePackage (VIB-name)
※VIB-nameは、Get-EsxSoftwarePackageで調べた名前です。


※この例では、net-ixgbeを追加しています

4. 作成したイメージプロファイルを指定して、ISOファイルもしくはオフラインバンドルとしてエクスポート

  ISOファイルとしてエクスポート
    > Export-EsxImageProfile -ImageProfile (New_Profile_name) -ExportToIso -FilePath (Filename)

  オフラインバンドルとしてエクスポート
    > Export-EsxImageProfile -ImageProfile (New_Profile_name) -ExportToBundle -FilePath (Filename)

エクスポートしたISOファイル、オフラインバンドルには追加したVIBが含まれており、ダウンロードした物同様、AutoDeploy起動用のイメージやESXiのインストーラーとして利用することが可能です。

イメージ同士の結合

上記の応用編となりますが、複数のESXiイメージから新しいVIBのみを抽出して新しいイメージプロファイルを作成することも可能です。
この知識は、OEMカスタムイメージを利用している方に、特に有用です。

例えば、青い波線のイメージを作成する際、VMwareのパッチに含まれる最新のvmkernelやvmware-toolsのVIBと、旧OEMカスタムイメージに含まれるより新しいデバイスドライバやCIMプロバイダ等でイメージプロファイルを作成する事が可能です。

この場合は、以下のように行います。

・利用する複数のESXiのイメージプロファイルをImage Builderに登録

 > Add-EsxSoftwareDepot C:\filepath\VMware-ESXi-5.1.0-xxxxxx-depot.zip.zip
 > Add-EsxSoftwareDepot C:\filepath\VMware-ESXi-5.1.0-yyyyyy-depot.zip.zip

・新しいイメージプロファイルを選択して変数へ代入

 > $sp = Get-EsxSoftwarePackage -newest

・$spを指定してイメージプロファイルを新規作成

 > New-EsxImageProfile -NewProfile -SoftwarePackage $sp -Vendor -AcceptanceLevel

あとは、上記4.同様、ISOやオフラインバンドルとしてエクスポートが可能です。

まとめ

今回は、ESXiイメージ管理に関するベストプラクティスについてご紹介いたしました。
この知識を活用することにより、以下のことが可能となります。

 ・最新のドライバを含んだインストールイメージの作成が可能
・ESXi導入時間や障害時のリカバリ時間の短縮
・ドライバが無いことによるインストールの不具合を解消
・Auto Deploy環境におけるイメージ作成・管理が可能

是非ご利用下さい!

VMware ESXi イメージ管理ベストプラクティス その1

ESXi 5.xのイメージを管理する!

※この記事は、VMware ESXi 5.x、及び2013年6月時点の情報を前提に記載しています。
将来、変わる可能性がありますので、あらかじめご了承の上ご利用下さい。

まだ一般的にはあまり知られていないようですが、VMware ESXiは起動に必要なモジュール(VIB)を選択して起動(インストール)することが出来る、非常にユニークなHypervisorです。このユニークさが隠れたESXiの凄いところなのですが、この ”選択されるVIB” は必要に応じてカスタマイズすることが可能で、カスタマイズにより以下の様なメリットが得られます。

・最新のドライバを含んだインストールイメージの作成が可能

・ドライバが無いことによるインストールの不具合を解消
最新のサーバへの対応が容易

・ESXi導入時間や障害時のリカバリ時間の短縮
追加のパッチ当てやドライバのインストール作業が不要に

・Auto Deploy環境におけるイメージ作成・管理が可能
追加インストールが事実上不可能なステートレス環境ではこの知識が非常に役に立ちます

ここでは2回に分けて、最適なESXiのイメージ管理手法について具体的な例を挙げながらご説明します。

2種類あるESXi 5.xのイメージ
ESXiのイメージには、ISO、ZIPの2種類があり、以下のような特徴があります。

ISO
・CDに焼くことによりBootableとなり、ESXiのインストールが可能
・オフラインバンドルから作成することも可能

ZIP
・オフラインバンドルの1つであり、ESXi独自のユニークなバイナリ提供方法
・ESXiを起動・インストールするために必要な複数のVIBやイメージプロファイルなどで構成される
・様々なカスタマイズや、 ISOファイルへの書き出しが可能

ESXiのイメージ管理にはISOファイルではなく、ZIPファイル(オフラインバンドル)を利用します。

※オフラインバンドルはESXiイメージ全体の提供だけではなく、デバイスドライバやエージェント類の提供方法としても利用されています。
この場合は、単一のVIBかつイメージプロファイルを含まない形が主となっています。


※VMwareダウンロードサイトより

オフラインバンドルの主な構成要素
オフラインバンドルの構成要素は以下の通りです。

・VIB・・・VMware Infrastructure Bundle
ESXiの構成上必要なパーツで、以下のような物があります
・ESXiベースイメージ(ESXi Kernel)
・デバイスドライバ
・CIMプロバイダ

・イメージプロファイル
起動(インストール)に利用する複数のVIBを選択・定義した物
上記VIBの内、ここで定義された物が起動(インストール)時に読み込まれる
インストーラー(ISOファイル)を書き出す事が可能
カスタマイズが可能

VIB・イメージプロファイルの提供方法


1. vmkernelや一般的なデバイスドライバ等は、VMwareから提供されるオフラインバンドルの中に含まれます。
2. サーバ固有のCIMプロバイダや最新ドライバ等は、1.に追加する形で各OEMベンダー用のカスタムイメージとして
提供されます。
3. VMwareから定期的に提供されるパッチの構成は基本的には1.と同じで、インストールに必要な全てのモジュール
が含まれます。但し、2.は含まれません。
4. デバイスドライバで、元々1.に含まれない物や、Updateされた最新ドライバ類です。
5. VIBには、アプリケーションからESXiにプッシュインストールされる物もあります。
代表的な物が、vSphere HAを構成する際にvCenter ServerからインストールされるFDM Agentです。

必要に応じて、柔軟に青や赤の波線で囲った様なイメージを作成することが今回の目的です。

1.のイメージの中に必要なドライバが含まれているかどうかは、VMwareのCompatibilityGuideのサイトで確認が出来ます。

一例を挙げます。ここのTypeで、

inbox・・・含まれる
async・・・含まれない

事を示します。

次回、その2では、実際のカスタマイズの方法に関してご説明します。

大規模環境のためのvCenter Server 5.1データベースのパフォーマンス改善とベストプラクティス その3

大規模環境でのvCenterサーバデータベースベストプラクティス

ここでは、vSphere 5.1で強化ポイントを最大限利用するためのデータベース設計のベストプラクティスをご紹介します。この中には、Oracle Database(以下 Oracle)やSQL Serverのディスクのレイアウトや、様々なテーブルに存在する統計情報の整理の方法、パフォーマンス向上のためのテーブルやインデックスの分離方法、OracleやSQL Serverのパラメータのチューニング方法、例えばSQL Serverのcost threshold for parallelismに関する内容が含まれます。その他一般的なvCenter Serverのベストプラクティスは、Performance Best Practices Guide for VMware vSphere 5.1をご確認ください。

 Oracle、SQL Serverのディスクレイアウト
vCenter Serverはデータベースサーバに多くのDisk I/Oを発生させる可能性があります。これらのI/Oは複数のLUN及びディスクスピンドルに分散させることが推奨です。次に示すのがそのガイドラインです。

 Oracle
以下の7個に分散させることが推奨です。
・ /u01 – system01.dbf, undotbs01.dbf
・ /u02 – sysaux01, temp01.dbf
・ /u03 – vpxdata01.dbf
・ /u04 – vpxindx01.dbf
・ /oralog – redo01a.log, redo02a.log, redo03a.log
・ /oralog_mirror – redo01b.log, redo02b.log, redo03b.log
・ /oraarch – archive destination.

SQL Server
以下の4個に分散させることが推奨です。
・mssql01 – master and msdb databases(.mdf, .ldf)
・mssql02 – tempdb(.mdf, .ldf), also set the initial size to 10GB
・mssql03 – VCDB(.mdf, .ldf)
・mssql04 – VCDB Backup location
 

更新量の多いテーブルに対するインデックス統計情報の更新

SQL Server
SQL Serverにおけるコストベースオプティマイザーは、SQL文の効率的な実行計画を作成する際、テーブルとインデックスに関する統計情報を利用します。コストとは、処理に必要なCPU、メモリ、Disk I/O等のリソース消費量のことで、統計情報とはテーブルのレコード数などが該当します。SQL Serverでは、AUTO_UPDATE_STATISTICSオプションの定義に従い、統計情報のインデックスが自動的にアップデートされます。この設定はデフォルトで有効となっています。この統計情報の自動更新は、最後の自動更新以降に実行されたインサート、アップデート、デリートの数がしきい値に達した際に実行されます。このしきい値はテーブル内のレコード数に依存しますが、例えば、100万を超えるような大きなテーブルを持っている場合、自動更新は数千から場合によっては100万のインサート、アップデート、デリート処理の実施後ということになり、SQL Serverの動作に影響を与える可能性が出てきます。

vCenter Serverによって、vCenter Serverスキーマの中のいくつかのテーブルが非常に速いペースで更新され、これらのテーブル上のインデックス統計情報はどんどん古くなっていきます。これが原因で、データベースのパフォーマンスが落ちてしまいます。例えば、VPX_PROPERTY_BULLETIN、 VPX_ALARM、 VPX_EVENT、 VPX_EVENT_ARGは、vCenter Serverのデータベーススキーマの中で最も変化の激しいテーブルですが、先のテーブルサイズの問題により、これらの自動更新が適切なタイミングで実行されない可能性があります。この問題に対処するため、これらの更新の激しいテーブル上のインデックス統計情報を以下の方法で手動更新することも可能です。

データベースの統計情報更新:sp_updatestats VCDB;

テーブルの統計情報更新:UPDATE STATISTICS “table_name”;

例えば、UPDATE STATISTICS VPX_PROPERTY_BULLETIN

となります。

Oracle
コストベースオプティマイザーはデータアクセスに対する最適な方法を提供しますが、先のSQL Server同様、最新の統計データであるかどうかに依存します。古い統計情報はデータベースのレスポンスに悪い影響を及ぼす可能性があります。Oracle Database 10g/11gのデフォルト設定では、データベースは自動的に統計情報を収集します。この統計情報の自動収集機能は、それほど頻繁な更新を行わない多くのデータベースオブジェクトにおいては十分機能しますが、統計情報の収集がメンテナンス時間に行われ、かつ非常に大きなテーブルが頻繁に更新される様な環境では適切には動作しない可能性があります。このようなテーブル上の統計情報はすぐに古くなってしまいます。

vCenter Serverの動作により、データベースの内容は短時間で書き換わります。このため、統計情報がデータベースオブジェクトの特性を正確に表す事の出来る間隔で統計情報の収集を行うことが推奨となります。

テーブル、インデックス、テーブル内の個別コラム上の統計情報を収集するために、OracleのDBMS_STATSパッケージを利用することが可能です。

テーブルやインデックス上の統計情報が更新される間、OracleはテーブルやインデックスにアクセスしているSQL状態も無効にしますが、次に同じようなSQL実行された場合には、利用可能となった新しい統計情報に基づき自動的に新しい実行プランを自動的に選択、実行します。Oracle Database 10g以降でテーブルやインデックス統計情報を更新するためには、OracelパッケージのDBMS_STATSを使います。スキーマレベルで統計情報を集めるためには、GATHER_SCHEMA_STATSプロシジャを使います。以下をご参照ください。

exec.dbms_stats.gather_schema_stats
(ownname = ‘VCDB’,
estimate_percent = 20,
method_opt = ‘for all columns size auto’,
options = ‘gather’,
cascade = true);

パフォーマンス向上のための、テーブルおよびインデックスの分割方法

SQL Server
サイズが大きく、高いトランザクションデータベースのために、非クラスタ化インデックス、tempdbを独自のファイルグループ内に移動する事も出来ます。これはVMwareとしてはテストを行っていませんが問題なく動作可能です。しかしながら、この方法は試験的な手法かつ、データベースファイルの変更を伴いますので、ご了承の上ご利用いただくのと同時に、実施前に必ずデータベースのバックアップを取得いただくようお願いいたします。

Oracle
上記した推奨のDisk配置に加え、/U03 (data file)からインデックスを分けることも可能です。

SQL Serverエンタープライズエディションの機能を利用する方法
SQL ServerはマルチCPU上のパフォーマンスを最大限利用するため、クエリの並列処理を行います。この方法では、マルチプロセッサで複数のスレッドを処理することにより、クエリとインデックスの処理を改善することが可能です。パラレル実行は、一つ以上のスレッドの利用が可能で、シリアル実行は一つのスレッドのみの実行が可能です。

SQL Serverでは、’max degree of parallelism’値で、並列処理の最大値を指定し、並列実行の数を制限することが出来ます。この値によりクエリの並列実行のためのスレッドリソースの指定を行います。

’cost threshold of parallelism’オプションは、クエリの並列プランが実行される際の閾値をしています。シーケンシャルにクエリを実行したときのコストがこの値よりも大きい場合にクエリの並列実行を実施します。

SQL Serverエンタープライズディションの機能
1.max degree of parallelism値の設定例
sp_configure ‘max degree of parallelism’, ((n-1)/2) -1;
※”n” はプロセス数

2. cost threshold of parallelism値の設定例
sp_configure ‘cost threshold for parallelism’, 15;
※推奨値は15ですが、これ以上の値(最大25まで)に設定することも可能です。

まとめ
3回に渡ってvCenter Serverのデータベースのベストプラクティスに関してご説明させていただきました。このような最適化を行うことにより、以下が可能となります。

・より大きな環境への対応
・データベース上のリソースのオーバーヘッドの削減
・効率的で高い能力を持った統計情報の収集、処理

御拝読、誠にありがとうございました!

関連記事はこちら(その1その2)をご覧ください。