Home > Blogs > Japan Cloud Infrastructure Blog > タグ別アーカイブ: Best Practices

タグ別アーカイブ: Best Practices

仮想化への移行

皆さん、こんにちはVMwareの北村です。

昨今、企業のITインフラにおいて仮想化技術を使用したサーバ統合は欠かせない選択肢の1つとなっており、既存インフラの延命や新規インフラの整備において仮想化基盤を構築するケースも珍しい事ではなくなってきています。また、既に仮想化基盤を運用してはいるものの何かしらの理由で他社製仮想化基盤への移行を余儀なくされたり、現在の仮想化基盤とパブリック・クラウドの併用を行う必要が出てきた、など、単なる仮想化基盤の構築だけにとどまらず、仮想化への移行に以前と比べ選択肢が増えてきたのも事実です。この際に、既存の物理サーバ環境をどの様に仮想環境へ移行していくか、また、既に構築済みの仮想環境を他社製仮想化基盤へ移行するか、はたまた、オンプレミスの仮想化基盤からいかにクラウドへ移行するか、という点は移行を検討する上で重要なポイントだと言えます。

そこで、“仮想化への移行” として、次回以降、実機検証の結果を元に次のテーマでブログをご紹介していく予定です。

• V2V (Virtual to Virtual)
  – VMware vCenter Converter Standalone を利用した他の仮想化製品フォーマットから VMware vSphere 環境への移行
• P2V (Physical to Virtual)
  – VMware vCenter Converter Standalone を利用した物理サーバ (Linux) から VMware vSphere 環境への移行
• I2V (3rd Party Image/Backup Tool to Virtual)
  – 3rd Party Image/Backup Tool から VMware vSphere 環境への移行
• V2C (Virtual to Cloud)
  – VMware vSphere 環境から VMware vCloud Air への移行

補足:
“仮想化への移行” としては、2つのブログ ”VMware vCenter Converter で P2V, V2V ~ 第1回 仮想環境におけるサーバ移行 (P2V, V2V) の基本“ と ”VMware vCenter Converter のインストールと Windows 2003 のP2V“ を投稿してきていますが、期間がしばらく空いてしまった事もあり、内容を再考し、年内に上記のポイントでご紹介していく予定です。

 

今回は仮想化への移行全般に関わる次の各フェーズについて、ポイント (ベストプラクティス、および、TIPS) をご紹介します (以下のポイントは、VMware vCenter Server Converter Standalone を使用した P2V、V2V、および、サードパーティ製ツールを使用した I2V を前提としていますが、仮想化への移行を検討される際のヒントとして活用して頂ければ幸いです)。
step0

 

移行計画:
step1
• 計画段階で検討すべき項目
  – 対象台数は何台
  – いつまでに移行させるか
  – 移行対象の OS の種類
  – 移行方法は何を使うのか
  – P2V できなかった場合の対応 (サードパーティ / 移行しない / 新規構築)
  – 移行対象のデータ容量
  – サービス(業務)停止許容時間
  – 使用アプリケーションの仮想環境上でのサポート有無
  – 使用アプリケーションのライセンス認証方法 (MACアドレスやドングル等)
  – 使用している周辺デバイスの有無と物理マシンへの接続方法
  – 既存物理環境でのパフォーマンスやスローダウンなどの問題があるか
  – 移行先の仮想環境のキャパシティ
  – 移行後の管理手法 (監視・バックアップ)

 

事前テスト:
step2
• 事前に物理マシンのタイプをグルーピングし、グループ単位でテストを行い確認する
  – ハードウェア構成ごと
  – オペレーティングシステムの種類ごと
• テストで確認すべき項目
  – 作業手順の流れの確認
  – 移行作業にかかる時間
  – P2V 時に使用されるポートでの通信可否確認
  – 停止するサービスの確認
  – 物理ハードウエア監視ツールによる P2V への影響確認
  – 既存ネットワークを使用する場合、P2V 時のネットワークへの影響確認
  – P2V 作業後の確認 (削除するデバイス、アプリケーション、ドライバ等)
  – 正常性を確認する手順
 など

正常性確認のためのヒント:
• インフラ側では OS レベルの正常性確認までの確認が一般的
  – OS の正常起動
  – イベントログ確認 (エラーが出ていないこと)
  – 通信確認 (仮想マシン外部ネットワーク)
• アプリケーションはアプリ担当やアプリベンダでの対応が必要
  – アプリケーションとしての動作確認
  – 業務システム視点での動作確認
• 異常と言われることが多いもの
  – 遅くなった⇒物理環境でも同様のことが発生していないか確認
   – 物理で起きていることは仮想にしても発生する
   – 物理で発生していることで仮想マシンリソースを増やせば改善することが予測される場合、
    その場で対処せず P2V 完了後に対策を行う

 

移行準備:
step3
• 事前実施 (万が一の場合の復旧のために行うことを推奨)
  – 移行元のバックアップ
  – バックアップ後のイベントログ/Syslog を確認し再起動を実施
  – 再起動後のイベントログ/Syslog を確認し、P2V 後の問題切り分けの情報とすると共に、P2V自体によって発生した
   メッセージかどうかを見極めることで P2V 作業による責任範囲を明確にする
• 事前準備
  – VMware vCenter Converter Standalone
  – Windows の場合、移行予定の OS のメディアとライセンスキー (物理サーバ付属の OEM ライセンスは、当該サーバ上で
   仮想化する場合にのみ使用できるものなので、他の物理サーバに移行させる場合は別途ライセンスが必要)
  – 作業手順書
  – 既存マシン設定パラメータシート (IPアドレス、ホスト名、ライセンスキー等)
  – 作業チェックシート
  – 既存ネットワークから独立させて作業をする場合、ネットワークケーブルとスイッチ

 

移行作業:
step4
• 移行作業に入る前に
  – 既存環境の情報収集
   – ネットワーク設定を既存マシン設定パラメータシートに転記 (P2V 後はアドレスがクリアされる)
   – イベントログ / syslog 取得 (再起動して起動時に発生するエラーも事前に確認しておく)
    – 事前状態の保存
    – 元々出ていたエラーの切り分け
    – 古い物理マシンの場合、再起動できなくなるリスクもあることも注意する
• 移行作業の実行
  – 以下のツールなどを利用した移行の実行
   – VMware vCenter Converter Standalone
   – 3rd Party Image/Backup Tool
• 移行作業後に始めて仮想マシンを起動する前に行う作業
  – 仮想マシンスナップショットを取得 (セーブポイントの作成)
  – 仮想マシンハードウェアから必要ないデバイスを削除 (USB コントローラ、シリアルポート、パラレルポート、フロッピードライブ)
  – SCSI コントローラを確認・変更 (LSI Logic にする)
  – ネットワーク接続を「起動時に接続」オプションをはずす (コンフリクト防止)
  – ハードウエアベンダによっては、ハードウエア監視ツールが仮想化後に残っていると仮想マシンの起動に時間が掛かるなどの
   問題が発生することがあるので、可能であれば外す
  – P2V 作業時に不要なサービスを停止する
   – エージェントの導入後に再起動が入る可能性があるので、可能であればサービスを手動に変更して起動しないようにする
   – 変更したサービスは既存マシン設定パラメータシートに記入し、P2V作業後にサービス設定変更漏れが出ないようにする

 

移行完了後のクリーンナップ作業:
step5
• 仮想マシンを起動してから行う作業
  – 不要なアプリ・デバイス・ドライバを削除 (H/W 監視ツール、RAID 管理ツール、チーミングドライバ、H/W ベンダーのその他
   ツール・ユーティリティ、バックアップソフト、ビデオカードドライバ、サウンドカードドライバ、その他不要なデバイスなど)
  – 上記はクリーンインストールした仮想マシンと比較するとわかりやすい
  – VMware Tools のインストール
  – 既存マシン設定パラメータシートを参照しネットワークの設定を行う
  – 既存マシン設定パラメータシートを参照しサービスの設定の復旧を行う
  – ログの確認とスナップショットの削除で完了 (スナップショット取得以降に発生した変更差分の領域が想定外のディスク容量が
   消費されてしまい、システムに影響を与える可能性があるため、スナップショットを取得した際には忘れずに削除する事)

 

まとめ:
• 事前に移行部門と調整し、停止時間の調整から移行後の確認検証なども協力を得られるようにしておく
• 移行作業手順をあらかじめ作成し、漏れやミスが無いように対策する
• 移行作業時間はトラブルも考慮し余裕を持って計画する
• 移行を行う物理マシンの情報を事前にしっかり把握し、対策をしておく
• いくつかの物理マシンのコンバートを平行作業で行う場合、移行先ホスト及びストレージの I/O 負荷も考慮する
• 使用するネットワークの帯域や負荷などによる作業への影響も考慮する
• 移行トラブル時にどうするかをしっかり決めておく (別手段、P2V 除外など)
• 可能であれば事前にテスト移行を実施しておく
• 移行対象物理サーバは、移行作業実行前に必ずバックアップを取っておく
• 移行対象物理マシンでは、全てのサービスは提供しない状態で実施する
• ハードウエアに依存した監視ツールは事前に削除しておくか、コンバート後に起動しないようサービスの設定を変更する
• 仮想マシンに移行できたら、設定変更した部分は元に戻すのを忘れない

 

今回は仮想化への移行全般に関わる各フェーズと各フェーズにおけるポイント (ベストプラクティス、および、TIPS) をご紹介しました。次回以降は実機検証の結果を元にブログをご紹介していく予定ですので、是非、お楽しみに!

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)をご覧ください。

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

データベースパフォーマンスの改善

このセクションではその1 に引き続き、vCenter Server 5.1 の統計情報管理に関する主要な改善点を説明します。vCenter Server は、大量のデータを収集保持しており、データベースのパフォーマンスに大きな影響を受けます。

vSphere5.1 では、主要な2つの改善点があります。
・データベースのストアドプロシージャ改善による、ロールアップとTopN プロシージャ部分のリソースオーバヘッドの削減
・効率的なハイレベル統計情報のサポート

具体的には下記3つの最適化により、上記の改善を実現しています。
・ステージングテーブルの除去
・統計テーブルのパーティション
・ストアドプロシージャの再構成

 

ステージングテーブルの除去
vSphere4.1 とvSphere5.0 では、ステージングテーブルを用い、大規模環境でバースト的に生じる統計情報を収容していました。ステージングテーブルには3つの種類があります。1つ目のステージングテーブルは、5分間の統計としてvCenter Server に使用されるものです。一定間隔の後、このテーブルは2つ目のステージングテーブルに切り替わります。平行して、いっぱいになった2つ目のステージングテーブルは解析され、全ての5分間の統計情報は、過去1日間のテーブルに取り込まれます。3つ目のステージングテーブルは、ステージングテーブル間の移動をスムーズにするためのバッファーとして使用します。
しかしvSphere5.1 でサポートする大規模なインベントリー管理のためには、よりスケーラブルなソリューションが必要となります。vSphere5.1 ではこれらのステージングテーブルを除去し、代わりに統計テーブルをパーティションすることでこの問題を解決しています。この変更により、vCenter Sever は5分間の統計を、過去1日間のテーブルに直接取り込むことで、統計情報の収集プロセスを大幅に改善しました。ステージングテーブルの除去により、より堅牢に統計情報を保持することが可能となります。VMware ナレッジベース(KB2011523, KB1003878)でより多くの関連情報をご確認いただけます。

表2は、1時間あたりに取り込まれる統計情報を収集レベル毎に表した物です。例えば収集レベル4の場合、付記に記載のある1000台のホスト(32CPU, 2000Datastore, 4NIC)と、10000台の起動したVM(1vCPU, 1disk, 1NIC)環境で、1時間あたり8000万の統計情報が収集されます。環境によっては異なる数の統計情報が収集されるかもしれません。この表は、統計レベル毎のI/Oアクティビティ(KBps)も表しています。

表2. テスト環境でvCenter Server が収集し、データベースにプッシュするレベル毎の統計情報数

ステージングテーブルの除去は、統計情報の取り込みロジックを再設計することを可能にし、データベースのリソースオーバヘッドを削減し、1回にデータベースに保存できる統計情報の数を増やすことで、vCenter Server のスケーラビリティを拡張しました。

 

統計テーブルのパーティション
vCenter Server の統計テーブルには3つのI/O ソースが関係してきます。統計情報の取り込み、異なる統計情報間隔の間でのロールアップ、期限が切れた統計情報の削除です。これらのI/O は統計テーブルの競合を起こし、オペレーションに長時間でゆらぎのある遅延をもたらします。もともと日次、週次、月次、年次の統計情報毎に1つのテーブルがあり、このテーブルは非常に大きな規模のインベントリーになる可能性があります。vSphere5.1 は統計テーブルを再設計しパーティションすることで競合を削減し、パフォーマンスを改善します。

表3. 統計テーブルを小さなサブテーブルに分割し、それぞれが短い時間間隔の統計を保持します。例えば日次の統計情報テーブルはサブテーブルにパーティションされ、それぞれのサブテーブルは30分の統計情報のみ保持します。

vSphere5.1 はこれらの変更により
・テーブルへの取り込みが大幅に改善されました。
・ロールアップの性能が大きく改善されました。ロールアッププロセスは適切に調整され、ロールアップ手順のパフォーマンスは向上し、表4が示す通りの時間となりました。
・データ削除時のパフォーマンスが大幅に改善され、事実上ディスクへの全てのI/O が排除されました。期限の切れた統計情報の削除はデータの期限が切れた際の簡単な処理になり、削除時間を数秒にまで削減しました。
・高い統計レベルが以前に比べてより効率的にサポートされるようになりました。

表4. SQL サーバで異なるレベルの統計情報を収集した際のロールアップ平均時間

 

ストアドプロシージャの再構成
ここまで述べてきた変更に加えて、vSphere5.1 には過去のリリースに比べ効率化されたストアドプロシージャが含まれています。例えばデータセンターとクラスターのグラフでは、CPU 使用率Top10 の仮想マシンを表示することが可能です。このグラフは、 CPU 使用率、メモリーといった、TopN の仮想マシンを決めるため統計に数学的手法を使用するTopN クエリーから計算され、TopN の日次のテーブルに格納されます。これら日次のTopN 統計情報は、定期的に週次、月次、年次のテーブルにロールアップされます。これらTopN の手順は、より効率的に書き換えられています。かつては10分かかっていたかもしれない処理が、今では完了まで1分未満となります。これらの変更により、ページをロードするUI のパフォーマンスを改善し、データベースのI/O を削減します。

 

このセクションでは、vCenter Server データベースの具体的な改善内容を説明しました。引き続きその3 では、データベースパフォーマンスのためのベストプラクティスをご紹介していきます。

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

 

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

vCenter Server バージョン5.1 では、より高いパフォーマンス、低いレイテンシを実現し、かつ統計情報を合理的に処理する改善が行われています。以下URL のTechnical Paper では、これらの改善点の解説と、vCenter Server デー タベースのパフォーマンスと大規模環境におけるベストプラクティスが提供されております。こちらのベストプラクティスの内容を3 回に渡り、ご紹介していきます。
http://www.vmware.com/resources/techresources/10302

エグゼクティブサマリ

VMware vCenter Server 5.1 では、統計サブシステムに対するいくつかの重要な改善が行われております。
統計データは、vCenter Server データベースのストレージに大きな影響を与えるため、vSphere のパフォーマンスが妨げられないようにデータを取り扱う必要があります。
vCenter Server 5.1 では、データベースのストアドプロシージャ、特にロールアップとTopN 手順に関する改善を通して、データベースのリソースオーバーヘッドを削減しています。

本ドキュメントでは、改善点と、改善点を利用するためのデータベースのベストプラクティスを提供します。
・Oracle Database とSQL Server のためのディスクを配置する方法
・非常に変わりやすいテーブルのインデックス統計を更新する方法
・パフォーマンス向上のためにテーブルとインデックスを切り離す方法
・SQL Server のEnterprise Edition の機能を利用する方法
・Oracle Database とSQL Server の特定のパラメータを調整する方法(例えばSQL Server のための同時実行閾値)

vCenter Server が管理することができるインベントリ(仮想マシン、ホスト、クラスタ、データストア、クラスタ)の最大値に近い環境でvCenter Server を導入を検討する場合、5.1 での改善は非常に重要です。

イントロダクション

vCenter Server では、リレーショナルデータベースに重要なデータが保持し続けられ、データベースはvCenter Server パフォーマンスの重要なコンポーネントとなります。
このデータは1) インベントリと構成データ、2) タスクとイベントデータ、3) アラームデータ、4) 統計データの4つのカテゴリに分類されております。

この中でも統計データがデータベースのかなりの部分を消費するため、適切な統計機能はデータベース全体のパフォーマンスの重要な考慮点となります。
統計情報の収集と処理は、vCenter Server パフォーマンスのための重要な構成要素となります。

図1.vCenter Server における統計サブシステムの概要
vCenter Server には、統計サブシステムのために保存期間と統計レベルの2 つのキーとなるセッティングがあります。
vCenter Server は定期的に各々のESXi ホストから統計情報を集めて、リレーショナルデータベースへデータが保持し続けられます。データベースは、いろいろな間隔でこのデータをまとめるためのいくつかのストアドプロシージャを順番に実行します。

各ESXi ホストは、20 秒ごとに統計情報を集め、vCenter Server では、これらはリアルタイム統計と呼ばれています。vSphere Client のパフォーマンスタブで詳細ボタンを選ぶことによって、リアルタイム統計を見ることができます。クライアントでは、直接ESXi ホストからリアルタイム統計を受け取っているため、データのタイムリーさを確実にして、データベースにストレスを与えません。

これらの20 秒の統計情報は定期的に5 分の統計情報にまとめられ、vCenter Server はこれらの5 分の統計情報を過去1 日のテーブルに保管します。15 個の20 秒のリアルタイム統計を一つの5 分の統計情報に変える手順は、ロールアップと呼ばれています。

またvCenter Server データベースに保管される統計情報には、いくつかの収集頻度があり、5 分の統計情報にロールアップするのと同じように、バックグラウンドでより大きな収集頻度の統計情報にロールアップするために、定期的にストアドプロシージャを実行します。

・過去1 日の統計ロールアップ手順は、5 分の統計情報を30分の統計情報に集約するために、30 分毎に動作します。
・過去1 週間統計ロールアップ手順は、30 分の統計情報を2時間の統計情報に集約するために、2 時間毎に動作します。
・過去1 ヶ月統計ロールアップ手順は、2 時間の統計情報を1日の統計情報に集約するために、1 日毎に動作します。

vSphere Client のパフォーマンスタブで詳細ボタンを選択し、チャートオプションを変更することにより、過去の統計情報を見ることができます。この場合、データベースから統計データを受け取ることになります。

vCenter Server には、統計サブシステムのために保存期間と統計レベルの2つのキーとなるセッティングがあります。

・保存期間: これは、統計情報をデータベースに保存する期間を指定します。データは保存期間よりも古い場合には、期限切れとみなされ、データベースから削除されます。

-1 日:5 分毎の統計情報は、1 から5 日保存されます。
-1 週間:30 分毎の統計情報は、1 週間保存されます。
-1 ヶ月:2 時間毎の統計情報は、1 ヶ月保存されます。
-1 年:1 日毎の統計情報は、1 から5 年間保存されます。

・統計レベル: 一般的には、レベルが高いほど、より詳細な統計情報の取得が可能であり、データベースに保存される容量が大きくなります。

-レベル1:最小限の詳細統計レベルであり、CPU 、メモリ、ネットワークの使用率のような最も重要な統計情報が含まれます。
-レベル2 :レベル1に比べ、より詳細な統計情報が含まれます。
-レベル3 :インスタンスごとの統計情報が含まれます。例えば、CPU 毎のホストのCPU 使用率
-レベル4 :最も詳細であり、他のすべての統計レベルが含まれます。

null
図2. 各統計レベルの保存期間を指定するダイアログボックス
今回はvCenter Server データベースの改善ポイントの概要をご紹介させていただきました。その2 では、より具体的な改善内容、その3では、データベースパフォーマンスのためのベストプラクティスを引き続きご紹介していきます。
関連記事はこちら(その2 その3 )をご覧ください。