Home > Blogs > Japan Cloud Infrastructure Blog > 月別アーカイブ: 2013年5月

月別アーカイブ: 2013年5月

2013年度vExpert受賞者の発表

速報! 2013年度vExpert受賞者の発表
http://blogs.vmware.com/vmtn/2013/05/vexpert-2013-awardees-announced.html
受賞者の皆様。おめでとうございます。

vExpert は下記3つのカテゴリからノミネーションされた方の中から2012年度の功績を元に表彰されるアワードです。

Evangelist(エバンジェリスト)
書籍の著者、ブロガー、ツールの開発者、講演者、VMTN(コミュニティのスレッドです)の貢献者などで、ITプロフェッショナルとして製品のナレッジや製品に対する情熱を広く伝えた方です。

Customer(顧客)
VMwareの顧客企業のリーダー。社内でのチャンピオンとしてVMwareとサクセスストーリーを築くために貢献し、インタビューやカンファレンス、VMUGのリーダーの中でのスピーカーなどとして広く事例紹介された方です。

VPN (VMware Partner Network)(VPN)
パートナー企業の社員で情熱をもってリードする方。たとえば絶え間ない努力を惜しまずに認定を受けるために技術修得し続け、技術的な知識と経験に基づいていろいろな プロジェクトに対して助言できる立場の人。イベント参加や、ビデオ等の作成と共に公の場での講演を行った方です。

大規模環境のための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 )をご覧ください。

 

仮想化基盤の運用管理の課題を解決する

みなさん初めまして。クラウド製品担当スペシャリストの西田和弘と申します。私の担当は、vSphereのような仮想化プラットフォームだけでなく、vCloud Suiteのようなクラウド基盤およびvCenter Operations Suiteのような運用管理までと、幅広い製品をカバーしています。
業務上多くのお客様とお会いする機会がありますが、仮想化基盤導入後の運用管理フェーズの状況をお聞きするたびに、多くのお客様に共有した課題があるということが分かってきました。
そのような共通の運用管理の課題の例を4つほど挙げてみます。

  1. パフォーマンスの劣化を防止したい
    仮想化基盤では、同一サーバーハードウェア(VMwareではホストと呼ぶことが多いです)上で多数の仮想マシン(以下VM)が同時に稼働しますので、特定のVMがホストのリソースを独占して利用することができず、他のVMとリソースを共有します。したがって個々の仮想マシンが常に最大のパフォーマンスを発揮できるとは限らないので、仮想化基盤では特にパフォーマンスの監視には注意が必要となります。
  2. 統合率を向上させたい
    仮想化基盤導入のもっとも大きく、目に見えるメリットは「コストの削減」です。ホスト1台あたりのVM数が多い、つまり統合率が高いほど、ホストの台数を削減でき、より大きなコストを削減することが可能です。
    もちろん無限にVMを搭載できるわけでないので、「どの程度まで搭載できるか」が問題になります。これはなかなかむずかしい問題で、1.のようにパフォーマンスの劣化を防止つつ統合率を上げるためには、微妙なバランスが必要となります。
  3. リソースの無駄遣いをなくしたい
    これは2.とも関連しますが、仮想化基盤上では、個々のVMにたいし必要な仮想CPU数(以下vCPU)、メモリサイズ(vMEM)を設定した上で展開します。したがってvCPU数、vMEMサイズが大きいほど物理リソースを多く消費することになり、結果として統合率が低下し、コストが増大してしまいます。
    個々のVMにたいして、vCPU数、vMEMサイズの設定値は、仮想化基盤の管理者が一律に決めるのではなく、VMサービスの利用を管理者に申請する人が指定するケースがほとんどです。基盤管理者としては不必要に大きなサイズを設定してリソースの無駄遣いをすることは避けたいと考えていますが、「申請されたサイズ」が本当に必要かどうか不明であるため、しかたなく申請値のまま設定しなければならないことが多いようです。
  4. 将来のリソース使用状況を予測し、ハードウェアを計画的に導入したい
    仮想化基盤はとても便利なので、コスト以外にも多くのメリットがあることに気がつく管理者は多いと思います。便利になり簡単にシステムを追加できるために、すぐにハードウェアリソースが足りなくなってしまうという副作用があります。これは便利さのコインの裏表のような関係ですが、足りなくなることを前提に、程度増加量を予測して計画的にハードウェアリソースの増強を行いたいという声を多く聞きます。

上に挙げた例の他にも共通の課題はありますが、実はこれらの課題そのものにも共通性があります。それはいずれも「VMware vCenter Operations Management Suiteで解決することが可能」ということなのです。
vCenter Operations Suite(以下vCOps)については、仮想環境の運用管理ツールということでご存じ方もいらっしゃると思いますが、「運用管理ツール」というとらえ方はあまり正確でありません。一般的な運用管理ツールというと、システムのイベントやログを監視しアラート発生して管理者に通知するという機能を想像しますが、vCOpsの主要機能はそれだけではないからです。
vCOpsの主要機能は、まさに前述したように、「仮想化基盤における運用管理上の課題を解決できる」ということなのです。
次回以降のブログにて、vCOpsにて解決可能な課題とその方法について、順次紹介していきます。

  1. 仮想化基盤のパフォーマンスを監視し、性能の劣化を防止する
  2. パフォーマンスを犠牲にしないで、統合度を向上させる
  3. リソースの無駄遣い状況を調べ節約する
  4. 基盤の効果的な監視を行い、過剰なアラートを防ぎ、本当に必要な場合のみを知らせる
  5. ハードウェアの増強を計画的に行う
  6. トラブルが発生する前に、未然に防止する
  7. システム構成管理台帳のメンテナンスを自動化し、不測の事態に対応する
  8. 過去にさかのぼってパフォーマンスをレポートを作成する