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

タグ別アーカイブ: vCenter Server

【SE必見】最新版 vSphere を使おう!~簡単バージョンアップのご案内~vCenter Server 編

皆様、こんにちは。VMware山口です。

正常に動いている仮想環境に手を入れる(バージョンアップ)のはあまり気が進まないと思います。しかし新機能は使ってみたい。
今回は、そんな旧バージョン VMware vSphere (以降vSphere)をお使いの方が、vSphere の最新バージョンに移行するための簡単移行方法をご紹介します。
あまりに簡単で拍子抜けしてしまうかもしれませんが、それもまたサーバ仮想化の恩恵の一つです。
最新バーションを利用するメリットは第1回のこちらをご覧下さい。

公式のアップグレードの方法は、こちらをご参照ください。
公式のアップグレード方式は基本的にインプレースアップグレード(既存環境そのものをアップグレード)になります。

今回ご紹介するのは、名付けて” 頭据え替え移行 ”とでも呼びますでしょうか。
弊社のKBでも紹介されている方式を活用した移行方法となっています。
詳しくはこちらをご参照ください。

この移行のメリットは、新旧環境の平行稼働が可能で、仮想マシンを自分のタイミングで移行してみて、
問題があれば、簡単に戻せる点です。

逆にデメリットは、旧 VMware vCenter Server(以降vCenter)の リソースプールや HAなどの設定情報が引き継げない点ですがメリットにもある通り平行稼働できますので、前を参考にし、動きを確認しながら引き継げます。
また、同様にこれまで蓄積したパフォーマンスなどの統計情報が持ち運べないという点です。
まさに割り切りタイプの移行と言えますので、これを了承頂ける方のみで実施をお願いいたします。

早速ですが、図の仮想環境例を使って、手順概要を確認していきます。

★既存仮想環境例★
・vCenter 4.1U1
・ESXi 4.1 U1
・ホスト3台
・共有ストレージ (iSCSI)
スクリーンショット 2014-11-27 16.23.31

図1:vSphere 4.1U1 の仮想環境の例
<ステップ1>
①VMware ESXi 5.5 (以降ESXi)をインストールします。
この例では3ホストあるので、旧環境を縮退させて、1ホストに新しくインストールします。
注1)お持ちの ESXi ホストが vSphere の最新バージョンに対応しているかは、こちらで確認してください。
注2)新しくインストールする前に、ESXiは元に戻せるよう、バックアップを取得して実施をお勧めします。
ESXiホストのバックアップ・リストアはこちらを参考にしてください。

②新しくインストールしたホスト上に vCenter 5.5 アプライアンスをインストールします。
なお、新環境では、vCenter アプライアンスを強くお勧めします。
Linux ベースの仮想アプライアンスなのでインストールもあっと言う間に終わります。それでいて大規模環境にも対応するスペックを持っています。
詳しくはこちらをご参照ください。
スクリーンショット 2014-11-27 16.23.59

図2:vSphere 最新バージョンのインストール
<ステップ2>
③新vCenter 配下に新ESXiを所属させたら、旧環境のデータストア(仮想マシンが格納されている)を
新環境に参照させます。
④新vCenterより、データストアブラウザを利用して、移行対象の仮想マシンをインベントリ登録します。
わずかこれだけで、新環境へ仮想マシンを移行したことになります。
再度、戻したい場合は、旧vCenterで再度インベントリ登録をしてあげればOKです。

スクリーンショット 2014-11-27 16.24.27

図3:新旧環境のデータストア共有とインベントリ登録
<ステップ3>
⑤最新バージョンの機能をフルに使う為には、仮想マシンバージョンをアップグレードする必要があります。
この例ですと、仮想マシンバージョン7−>10にします。
注3)この操作で旧環境に戻すことが出来なくなるので、旧環境でクローンなどで一時的にバックアップしておくことをお勧めします。

⑥最後にデータストアのファイルシステムをアップグレード(VMFS3ー>5)します。
注4)これも旧環境では参照できなくなりますので必ず仮想マシンの移行がすべて終わってから実施してください。
スクリーンショット 2014-11-27 16.24.40

図4:仮想マシンバージョンとVMFSのアップグレード
最後に、ライセンスですが、お試し頂く場合は、評価ライセンス版の60日で対応お願いします。
本格的に移行する際、お持ちのライセンスが最新バージョンに対応していない場合は、アップグレードする必要があります。
こちらを参照ください。

★★おまけ★★
実際の移行オペレーションで重要なポイントを解説動画でご案内します。

ステップ1:②vCenterアプライアンスインストール時のポイント
★初期セットアップ時のIPアドレス設定
初回アクセスの為に設定するIPアドレスにテクニックが必要です。
vCenterアプライアンスは初回起動時、IPアドレスが設定されていない為、DHCPクライアントの状態です。
デプロイされたVM NetworkにDHCPサーバが存在しない場合は、IPアドレスが付与されない状態で起動しますので
手動設定が必要です。詳しくは、こちらの動画をご覧下さい。

★デフォルトパスワード変更
必ずデフォルトパスワードを変更してください。また、デフォルトですと90日でパスワードが失効するように
設定されています。失効してしまうと復旧させるのがとても大変なので必要な方はこれを無効にしてください。
vCenterアプライアンスの管理画面にて、Adminタブ>Administrator password expiresをNoに変更し、Submitをクリック
詳しくは、こちらの動画をご覧下さい。

ステップ2:③、④の手順で特にははまりポイントはありませんが、こちらの動画をご覧下さい。
★移行後、仮想マシンを初回起動する際に、コピーしたか移動したかの設問があります。

ステップ3:⑤、⑥のアップグレードはもとに戻せなくなるので注意しながら実施してください。
⑤対象の仮想マシンを右クリック>すべてのvCenterアクション>互換性>仮想マシン互換性のアップグレード
⑥対象のデータストアを右クリック>すべてのvCenterアクション>VMFS-5へアップグレード
★VMware toolsも最新版にあげておくことをお勧めします。

いかがでしたでしょうか?
既存環境をさわるのは、ちょっと気がすすまないけど、新しいvSphereの機能は使ってみないなぁー
という皆様、ご覧の通り平行稼働できますので是非お試しください。

〜本シリーズの流れ〜
第1回 最新版 vSphere を使おう!~簡単バージョンアップのご案内~メリット編
-第2回 最新版 vSphere を使おう!~簡単バージョンアップのご案内~vCenter Server 編 本記事
-第3回 最新版 vSphere を使おう!~簡単バージョンアップのご案内~便利ツール vSphere Update Manager 編 Coming soon!

SSO の構成とアップグレード方法について

今回はvCenter Server Single-Sign-On (以下SSO と記載します。)の構成とvSphere 5.0 以前の環境からのvCenter Server (以下vCenter )のアップグレード方法について概要をご説明します。vSphere 5.5 より実装されるSSO2 については今後記載させていただきますが、本エントリではあくまでvSphere 5.1 で実装されたSSO について記載させていただきます。
SSO は下記の3つの構成でデプロイすることができます。

1.シングルモード (基本デプロイ)

シンプルな構成ですが、冗長性はありません。

図1. シングルモード

2.高可用性モード (高可用性デプロイ)

複数のSSO インスタンスでクラスタを構成しますが、SSO 用のDB は共有します。
この構成では、フロントにロードバランサを配置する必要があります。

図2. 高可用性モード

3.マルチサイトモード (マルチサイトデプロイ)

複数のSSO クラスタ (またはSSO 単体)をマルチサイトに配置する構成です。
SSO 用のDB は各サイト毎に配置しますが、SSO 用のDBは手動でレプリケーションを行う必要があります。
この構成では、高可用性モードと同様にフロントにロードバランサを配置する必要があります。

図3. マルチサイトモード
 vSphere 5.0 以前の環境からアップグレードする際はこれらの構成のうち、シングルモード(基本デプロイ)の構成となります。
もし、これまでの情報(ユーザ情報、クラスタ構成情報、パフォーマンスなど)を引き継がないで新規でvCenter を構築する場合はシングルモード以外の構成をとることができます。
vSphere 5.0 以前の環境からアップグレードする場合、アップグレード前の条件にもよりますが、大きく2つの方法があります。

方法1. SSO をvCenter と同じシステム上にインストールし、vCenter をin-place upgradeする方法

in-place upgrade とは既存のvCenter をインストールしたままアップグレードする方法のことです。vCenter のユーザとしてローカルOSアカウントを使用している場合には、この方法では、異なるシステム上のローカルアカウントはSSOサーバでは認証できないので、vCenter のインストールされているサーバ上にSSO をインストールします。

図4. 方法1 ローカルOS認証からのアップグレード概要

図5. 方法1 Active Directory認証からのアップグレード概要

方法2. SSO とvCenter を異なるシステムにインストールし、vCenter をin-place upgrade する方法

vCenter のユーザとしてローカルOSアカウントを使用している場合には、この方法では、ローカルOS もしくは SSO DB 上にユーザを作り直します。このため、vCenter 上でパーミッションを再設定することになり、旧ローカルユーザはvCenter から削除されます。削除されたユーザ情報はtempディレクトリ上に保存されます。(%TEMP%\deleted_vc_users.txt)

図6. 方法2 ローカルOS認証からのアップグレード概要
 vCenter のユーザとしてActive Directory のユーザアカウントを使用している場合は、SSO はActive Directory アカウントを常に認証できるので、vCenter と異なるシステム上にSSO を構築することができます。vCenter とSSO は異なる方が可用性が向上します。

図7. 方法2 Active Directory認証からのアップグレード概要
 アップグレードを作業行う前に、既存環境のバックアップを取得します。次に既存の環境がvCenter 5.1のインストール前提を満たしているかどうかを確認します。vCenter 5.1のインストーラに含まれているユーティリティ VMware vCenter Host Agent Pre-Upgrade Checker を使用しても良いのですが、Flings で公開されているvCenter 5.1 Pre-Install Check Script が問題のある箇所の詳細も表示されて便利です。

具体的なアップグレードの手順については、マニュアル vSphereのアップグレード をご参照ください。Knowledge Base に記載の情報も事前にチェックされることをお薦め致します。

なお、日本語環境で vCenter 5.1 から vCenter 5.1.0b へのアップグレードは、コマンドラインからSSO をインストールする必要があります。(http://kb.vmware.com/kb/2037976

vCenter Single Sign On (SSO)とは

vCenter Server 5.1から新しく追加されたvCenter Single Sign On(以下SSOと記述します)についてご存知でしょうか?
本ブログでは、何回かに分けてSSO のご紹介と技術情報について公開します。まず、初回となるこのエントリではSSO とはどういうものなのかをご紹介させていただきます。

SSO が新しく生まれた背景としては、下記3つのポイントがあります。
・vCenterとそのほかの運用管理ツールを一括で認証することにより運用の統合をはかる
・Active Directory やWindows のローカル認証以外の認証基盤に対応し、より多くのプラットフォームで運用管理ツールを利用可能とする

これまでは製品毎に個別に行っていたため、運用管理者にとってはIDやパスワードの管理が煩雑でした。また、Windows ベースの認証基盤であったため、異なるプラットフォームから運用管理を行うことは実質困難でした。その「不便」を解消するためにSSO は生まれました。

SSO は、vCenter Server のコンポーネントの一部としてvCenter Server のユーザーとグループの認証サービスです。vCenter Server 5.1よりも以前のバージョンでは、vCenter Server にアクセスする際はActive Directory ドメインまたはvCenter Server のローカルOS ユーザーのリストに対して認証していました。また、Active Directory 配下の場合にリンクモードを使用して複数のvCenter Server 間においてユーザやグループを一元的に使用することができました。

SSO では、これまでのActive Directory ドメインやローカルOSユーザーだけではなく、Open LDAP などの複数の認証サービスに対応しています。SSO という名前のとおりvCenter Server だけではなく、vCloud Director やvCenter Operations Manager といった他のソリューションの認証もSAML 2.0を使用したセキュアなトークン交換で行うことが可能です。

では、SSO はどのように動作するのでしょうか。

vSphere Web Clinet からvCenter Server にログインする場合に、SSO は次のように動作します。

①ユーザはvSphere Web Client サービスに自身のユーザID、パスワードを入力します。(vCenter Server はリダイレクト先のSSO サーバーをvSphere Web Client に返します。)

②vSphere Web Client はユーザ認証情報をSSO サーバーに送信します。

③SSO サーバは接続されているアイデンティティ・ソース(Active Directory ドメイン、 LDAP など)のいずれかで有効なユーザであるかどうか確認します。

④ユーザが有効である場合、SSO サーバはユーザ認証に成功したことを記述するトークンを生成し、vSphere Web Client に送信します。(トークンはSAML 2.0形式で記述され、デジタル署名されることにより改竄を防止しています。)

⑤vSphere Web Client は受け取ったトークンをvCenter Server に送信します。vCenter Server は登録済みのSSO サーバが発行したトークンであることを確認し、ログインを許可(認証)します。

次回からは、実際の環境からのアップデート方法についてご説明していきます。

 

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