VMware DRS および EMC Navisphere QoS を使用した VMware 仮想マシンのエンド ツー エンド サービス レベルの維持 高度なテクノロジー US ホワイトペーパー翻訳版 要約 このホワイト ペーパーは EMC CLARiX ストレージ システムを使用した VMware ESX 仮想環境での Navisphere QoS Manager および VMware の Distributed Resource Scheduler の稼働テストについて説明します このテストを通して QoS Manager および Distributed Resource Scheduler によって VMware ESX 仮想マシンで稼働する複数のアプリーケーションが CLARiX ストレージ システムを共有しながら ミッション クリティカルで優れたパフォーマンスを持続することを 分かりやすく示します 2008 年 3 月
Copyright 2007 EMC Corporation. 不許複製 EMC Corporation は この資料に記載される情報が 発効日時点で正確であるとみなしています この情報は 予告なく変更されることがあります この資料に記載される情報は 現状有姿 の条件で提供されています EMC Corporation は この資料に記載される情報に関する どのような内容についても表明保証条項を設けず 特に 商品性や特定の目的に対する適応性に対する黙示の保証はいたしません この資料に記載される いかなる EMC ソフトウェアの使用 複製 頒布も 当該ソフトウェア ライセンスが必要です 最新の EMC 製品名については EMC.com で EMC Corporation の商標を参照してください 他のすべての名称ならびに製品についての商標は それぞれの所有者の商標または登録商標です パーツ番号 H4089-J VMware DRS および EMC Navisphere QoS を使用した VMware 仮想マシンのエンド ツー エンド サービス レベルの維持高度なテクノロジー 2
目次 高度なテクノロジー...0 エグゼクティブ サマリー...4 はじめに...4 対象読者... 4 用語... 5 概要...5 VMware 環境で NQM を展開する際のベスト プラクティス... 6 VMware ESX サーバにおける DRS と NQM のテスト...7 環境... 7 CLARiX ストレージ構成... 7 ESX サーバの構成... 8 仮想マシンの構成... 9 VirtualCenter の構成... 9 方法論... 12 テスト 1:NQM の Cruise Control 機能の使用... 12 帯域幅を安定させる NQM の Cruise Control オプションの設定... 12 スループットを安定させる NQM の Cruise Control オプションの設定... 14 VM1 における Cruise Control テストの結果... 15 テスト 2:NQM の Limit 機能の使用... 15 帯域幅における NQM の Limit 機能の設定... 15 スループットにおける NQM の Limit 機能の設定... 16 NQM の Limit 制御の削除... 17 VM1 における Limit テストの結果... 17 結論...18 参考...18 関連資料... 18 VMware DRS および EMC Navisphere QoS を使用した VMware 仮想マシンのエンド ツー エンド サービス レベルの維持高度なテクノロジー 3
エグゼクティブ サマリー ミッション クリティカルなアプリケーションへの VMware ESX サーバの展開が増加するにつれ 仮想マシン内のアプリケーションに対するパフォーマンスの維持はますます重要になります サーバとストレージ リソースが複数コンポーネントで共有される場合など 仮想化が複雑になると 管理者がパフォーマンスの問題を検出して解決することが一層難しくなります CLARiX の Navisphere Quality of Service Manager(NQM) および VMware の Distributed Resource Scheduler を使用することで 仮想マシン内のアプリケーション サービス レベルを維持できます これにより パフォーマンスの問題を管理したり修正したりするために必要な 時間とリソースが大幅に縮小されます はじめに 複数のアプリケーションによるサーバとストレージ システムの共用によって リソースの統合と使用率の向上が可能になります しかし サーバとストレージ リソースの共有によって ミッション クリティカルなアプリケーションに対するワークロードの競合が発生したり 継続的にパフォーマンスを維持するための対応が必要になることもあります 共有インフラストラクチャにあるワークロードの競合のインパクトを最小限にするために VMware は VirtualCenter 2.0 で Distributed Resource Scheduler(DRS) を導入しました DRS は 仮想マシン上の CPU やメモリ リソースをモニターして アプリケーション サービス レベルを保証します EMC Navisphere Management Suite には CLARiX リリース 24 から Navisphere QoS Manager (NQM) があります NQM によって 仮想マシンで稼働する重要なアプリケーションのストレージ I/O パフォーマンスを コスト面で効果的に維持することができます NQM( アプリケーション I/O パフォーマンスの測定 モニタリング 制御を行う ) および DRS (CPU とメモリ リソースに優先順位を付ける ) は 仮想マシンのアプリケーションに優れたサービス レベルの保証を提供します このホワイト ペーパーでは DRS とともに NQM を使用する際のメリットを明らかにします また ストレージとサーバ コンポーネントで優れたサービス レベルを実現する方法を示す ( アプリケーションに Oracle を使用した ) テストについても説明します 対象読者 このホワイト ペーパーは EMC のすべてのお客様 パートナー また Oracle データベースの展開時に NQM を使用する方法についての情報を望む EMC スタッフを対象としています 読者には Oracle のパフォーマンス特性 CLARiX のストレージ システムの基礎 NQM の機能についての知識があることが前提となります NQM 機能の情報は EMC.comおよび EMC Powerlink Web サイトにあるホワイト ペーパー Navisphere Quality of Service Manager(NQM) 高度なテクノロジー にも記載されています また 読者には VMware インフラストラクチャ 3 についての高度な理解が必要です VMware の詳細については www.vmware.comを参照してください VMware DRS および EMC Navisphere QoS を使用した VMware 仮想マシンのエンド ツー エンド サービス レベルの維持高度なテクノロジー 4
用語 帯域幅 :1 秒間にストレージ システムを通過する読み取り / 書き込みデータの平均量 ( メガバイト ) ゲスト オペレーティング システム : 仮想マシンで稼働するオペレーティング システム 論理ユニット番号 (LUN): ストレージ システムで 論理ストレージ オブジェクトを区分けするために使用する一意の識別子 Oracle Automated Stress Testing (OAST):Oracle データベースを使用するシステムの OLTP 型ワークロードを再現するために設計された自動テスト スイート OAST はテーブルを作成し 負荷テストの実行を行い トランザクションに関するパフォーマンス データを出力します キューの深度 : ストレージによるサービスを待機している ポーリング インターバル内のリクエストの平均回数 現在サービス中のリクエストも含まれます Raw デバイス マッピング (RDM):Raw デバイス マッピング ボリュームは vmdk ファイルおよび物理 raw デバイスにあるポインタで構成されます vmdk のポインタは 物理 raw デバイスにポイントします vmdk ファイルは VMFS ボリュームに存在します VMFS ボリュームは共有ストレージに存在する必要があります Redundant Array of Independent Disks(RAID): 複数のハード ディスク上の複数の場所に同じデータを格納する方法 I/O 動作がバランスよくオーバーラップされるのでパフォーマンスが向上します 複数ディスクの使用により 平均故障間隔が増加します またデータを重複して格納するとフォールト トレランスも増加します RAID ストレージ システムはオペレーティング システムからは 1 個の論理ハード ディスク デバイスとして認識されます レスポンス タイム : ストレージ システムを通過する 1 リクエストにかかる平均時間 ( ミリ秒 ) 待機時間も含まれます スループット :1 秒間にストレージ システムを通過する I/O の読み取り / 書き込みリクエストの平均回数 使用率 : ストレージ システムが リクエストを処理している時間の割合 仮想マシン : ゲスト オペレーティング システムおよび関連するアプリケーション ソフトウェアが稼働できる仮想 x86 PC 環境 複数の仮想マシンは 同時に 1 台の物理マシンで動作します VMFS: 仮想ディスクおよび仮想マシンによって使用される他のファイルを格納するクラスタ ファイル システム 概要 VMware 環境における ESX サーバで稼働する仮想マシン (VM) には さまざまなサービス レベル要件があります 2 つのツール DRS と NQM はこれらの要件を満たすために役立ちます DRS は リソース プール にある VM の予約と共有を設定することによって CPU とメモリ リソースを維持します NQM は ストレージ システム I/O の管理に役立ちます ストレージ システムの多くは 同一優先度で各 VM の I/O を処理します その結果 アプリケーションの I/O がミッション クリティカルなアプリケーションのパフォーマンスを停止させる場合があります VMware DRS および EMC Navisphere QoS を使用した VMware 仮想マシンのエンド ツー エンド サービス レベルの維持高度なテクノロジー 5
しかし NQM は ストレージ システムの I/O 特性を測定し 優先順位を付けることができます この機能は 3 種類の制御方式で実装されます 各メソッドには異なるアルゴリズムとアプローチが使用され 要求されたサービス レベルの目標を達成します 制御方式を以下に示します Cruise Control: ミッション クリティカルなアプリケーションに対して 特定のパフォーマンスのターゲットを定義します NQM は指定した許容範囲内で アプリケーションのパフォーマンスが 定義したターゲットを満たすように I/O を優先順位付けします ターゲットは 帯域幅 スループット レスポンス タイムに設定できます Limit: この方式は LUN グループのパフォーマンスを特定レベルまでに制限します NQM は LUN グループの I/O リクエストをキューイングして 定義した制限内にパフォーマンスを維持します Limit は 帯域幅 スループット レスポンス タイムに設定できます Fixed Queue Depth: アレイは LUN セットに対して 指定したキューの深度をアクティブに維持します この機能は 適切に設定しないと ストレージ システムのリソースの十分な利用を妨げる場合があるので 上級ユーザーのみが使用すべきです NQM 制御方式は LUN 単位で運用されます したがって NQM を通じて LUN を適切にプロビジョニングすることが重要です また NQM は LUN 単位で運用されるので サービスが 1 個のアプリケーションに制限されることはありません すなわち NQM ポリシーはさまざまな設定によって断続的に複数のアプリケーション (LUN) に定義できます たとえば ある仮想マシンのスループットの最適化や制限を行う NQM ポリシーをスケジュールしながら 別の仮想マシンの帯域幅の最適化や制限を行う NQM ポリシーをスケジュールすることができます このホワイト ペーパーで後述するテストでは ( VMware ESX サーバにおける DRS と NQM のテスト を参照 ) DRS を NQM とともに設定する方法を説明します この例では Oracle OAST RMAN ORION を VM で稼働して 安定した高パフォーマンスのワークロードを生成しました NQM の Cruise Control 方式と Limit 方式は アプリケーションのパフォーマンスの最適化と制限に使用されました VMware 環境で NQM を展開する際のベスト プラクティス NQM は LUN レベルで稼働するため LUN に存在するすべての仮想マシンは NQM 制御オプションによる影響を受けます したがって VMware 環境で NQM を使用する場合 ESX サーバと仮想マシンに割り当てられた CLARiX LUN を適切にプロビジョニングすることが重要です EMC では アプリケーションに NQM 制御を適用するために 以下のベスト プラクティスをお薦めします 1. RDM または VMware ファイル システム (VMFS) として LUN 全体を設定します 2. LUN 全体をアプリケーションが存在する仮想マシンに割り当てます 3. NQM 制御を LUN に適用します これが実現できない場合は 仮想マシンで稼働する I/O 集約型アプリケーションが 他の仮想マシンで稼働する非 I/O 集約型アプリケーションと LUN を共有しないようにします これらのアプリケーションは CLARiX RAID グループ内で同じディスクを共有できます ただし NQM からメリットを得るには別々の LUN に存在する必要があります ESX サーバで稼働する特定の仮想マシンに完全なサービス レベルを保証するために NQM の I/O パラメータが VMware DRS CPU およびメモリ パラメータと確実に一致することも重要です VMware DRS および EMC Navisphere QoS を使用した VMware 仮想マシンのエンド ツー エンド サービス レベルの維持高度なテクノロジー 6
たとえば 1 個 ( または複数 ) の VM にリソース プールを設定して一定数の CPU またはメモリ予約を保持することを想定し VM が存在する LUN で NQM クラスを定義し NQM Cruise Control ポリシーを設定して特定の I/O プロファイルを維持します CPU またはメモリ予約を任意の ESX サーバで満たすことができない場合 VM は別の ESX サーバに移動されて CPU やメモリ リソースのバランスを調整します しかし VM は NQM で設定された特定の I/O プロファイルを維持し続けます VMware ESX サーバにおける DRS と NQM のテスト 以下のテストで EMC は 仮想マシンで稼働する Oracle データベースの使用例を調査しました この仮想マシンは 異なる仮想マシンで稼働する他の 2 個のアプリケーションとともに 1 個のスピンドル セットを共有しています Oracle Automated Stress Testing(OAST) は OLTP データベース アプリケーションとして使用され 一定時間継続して複数ユーザーのオンライン トランザクションを作成しました OAST は仮想マシン 1(VM1) で稼働しました 2 番目のアプリケーションは Oracle の Recovery Manager(RMAN) で Oracle データベースをバックアップ / リカバリします 2 番目のデータベースは 仮想マシン 2(VM2) に作成され RMAN を使用してバックアップされました RMAN もまた VM2 にインストールされ 別の ESX サーバにホスト接続されました 3 番目のアプリケーションは ORION です このベンチマーク ツールは ユーザーが Oracle データベースを使用したときに ディスクの異なる階層やタイプに対して パフォーマンスやスループットを比較するのに役立つ I/O ロードを生成します ORION は仮想マシン 3(VM3) で稼働します 環境 このセクションでは VMware ESX サーバで NQM をテストするために使用するストレージおよびサーバ コンポーネントを説明します CLARiX ストレージ構成 EMC CLARiX CX3-20f プロセッサ 2 メモリ サイズ SP につき 2 GB ディスク数 30 FC 73 GB @ 15k rpm ベース ソフトウェア FLARE 26 CLARiX RAID グループ レイアウト 2 個の RAID 5(4+1) 2 個の RAID 1/0(2+2) CLARiX LUN レイアウト 2 個の RAID 5(4 +1) グループにわたる 3 個の metalun VM 起動用の 1 個の metalun:200 GB Oracle データ用の 1 個の metalun:200 GB APP2( アプリケーション 2) 用の 1 個の metalun:100 GB 2 個の RAID 1/0(2 +2) グループにわたって作成された 2 個の metalun Oracle Log 用の 1 個の metalun:100 GB VMware DRS および EMC Navisphere QoS を使用した VMware 仮想マシンのエンド ツー エンド サービス レベルの維持高度なテクノロジー 7
APP1( アプリケーション 1) 用の 1 個の metalun:100 GB CLARiX ストレージ グループ レイアウトどちらの ESX サーバも 1 個のクラスタにあるので 図 1 に示すように 2 台のサーバにわたって共有された 5 個の LUN すべてで 1 個のストレージ グループが作成されました 図 1:VMware ESX サーバのストレージ グループ構成 ESX サーバの構成 2 台の ESX サーバ Dell 2950 ESX バージョン 3.0.2 メモリ 16 GB CPU の数 8 CPU x Xeon 1.862 GHz(2 x Quad Core Xeon 1.862 GHz) 2 個のファイバ チャネル HBA QLA2432 図 2 に示すように ESX サーバに割り当てられた LUN は VMFS-3 ボリュームとして設定されました VMware DRS および EMC Navisphere QoS を使用した VMware 仮想マシンのエンド ツー エンド サービス レベルの維持高度なテクノロジー 8
図 2:ESX サーバ レベルで VMFS-3 ボリュームとして設定された LUN 仮想マシンの構成 3 個の Linux 仮想マシン (VM1 VM2 VM3) ESX サーバ 1 にある VM1 ESX サーバ 2 にある VM2 および VM3 表 1: 仮想マシンの構成 仮想マシン CPU\ メモリ構成 仮想ディスク レイア ウト アプリケーション VM1 OS RHEL 5 AS メモリ 16 GB CPU の数 4 VM2 OS RHEL 5 AS メモリ 16 GB CPU の数 2 VM3 OS RHEL 5 AS メモリ 16 GB CPU の数 4 20GB Boot LUN:sda 95GB Data LUN:sdb 95GB Data LUN:sdc 10GB Log LUN:sdd 10GB Log LUN:sde 20GB Boot LUN:sda 45GB APP1 LUN:sdb 45GB APP2 LUN:sdc 20GB Boot LUN:sda 45GB APP2 LUN:sdb 45GB APP1 LUN:sdc Oracle OAST RMAN ORION VirtualCenter の構成 VMware Distributed Resource Scheduler(DRS) は 完全に自動化されるよう設定されました VM1 と VM3 を分離するために DRS にルールが作成されました ( つまり VM1 と VM3 は別々の ESX サーバに設置される必要があります ) これによって 1 個のクラスタにある 2 台の ESX サーバにわたる CPU とメモリ リソースのロード バランシングが実行されました 13 GB の予約を VM1 に供給するリソース プールが作成され メモリ リソースへのアクセスが保証されました VMware DRS および EMC Navisphere QoS を使用した VMware 仮想マシンのエンド ツー エンド サービス レベルの維持高度なテクノロジー 9
VMware DRS および EMC Navisphere QoS を使用した VMware 仮想マシンのエンド ツー エンド サービス レベルの維持高度なテクノロジー 10
図 3 に すべてのコンポーネントを含む構成全体のレイアウトを示します DRS configured across ESX servers to ensure VM memory and CPU service levels ESX 1 ESX 2 (VM 1) OAST (VM 2) RMAN (VM 3) ORION HBA 1 HBA 2 HBA 1 HBA 2 CLARiiON NQM policy applied to certain MetaLUNs to ensure I/O service levels for VMs RAID 5 Groups - MetaLUN 1 (Boot) - VM1, VM2, VM3 - MetaLUN 2 (APP2) - VM2 and VM3 - MetaLUN 3 (Data) - VM1 RAID 10 Groups - MetaLUN 1 (Log) - VM1 - MetaLUN 2 (APP1) - VM2 and VM3 図 3: テストの構成 VMware DRS および EMC Navisphere QoS を使用した VMware 仮想マシンのエンド ツー エンド サービス レベルの維持高度なテクノロジー 11
方法論 以下にこのテストの主要な 2 つの事例を示します 1. 帯域幅とスループットの Cruise Control オプションをテストします VM1 で OAST を起動します VM2 で RMAN を起動することによって VM1 への競合を発生させます VM1 の Data および Log LUN で NQM の Cruise Control オプションを適用します NQM でテスト結果を分析します 2. 帯域幅とスループットの Limit 制御オプションをテストします VM1 で OAST VM2 で RMAN VM3 で ORION を起動します Data および Log LUN で NQM の Limit 制御オプションを適用して RMAN バックアップに特定のサービス レベルを供給します NQM でテスト結果を分析します RMAN バックアップの完了後 VM1 の Limit 制御オプションを削除します NQM 制御が削除された後 テスト結果を分析します これによって NQM の Cruise Control 機能および Limit 機能がテストされました テストは整合性を保障するため ( 同一設定で )3~4 回繰り返されました テストごとに すべての LUN に対するデータが集められました 帯域幅 (MB/s) スループット (IO/s) レスポンス タイム (ms) 使用率 (%) キューの長さです テスト 1:NQM の Cruise Control 機能の使用 このテストでは VM1 の帯域幅とスループットを安定させるために VM1(OAST を稼働 ) に供給された LUN に NQM の Cruise Control 機能を適用しました 特定の時間が経過した後 VM2 で稼働する RMAN アプリケーションのフォームに競合が発生しました 競合の原因は VM1 と VM2 の両方に供給された LUN が CLARiX ストレージ システムで同じディスク セットを使用していたためでした VMware DRS は VM1 と VM2 にわたる CPU とメモリ リソースでロード バランシングを調整するために ESX サーバ クラスタに 完全自動 ポリシーを使用するように設定されました この使用例の目的は 同じディスク セットを使用するバックアップ (VM2) アプリケーションを取り込んだ場合でも NQM とともに稼働する DRS が VM1 に必要なパフォーマンスを提供する方法の紹介でした 帯域幅を安定させる NQM の Cruise Control オプションの設定図 4に示すように 2 個の NQM I/O クラスが Navisphere 内に作成されました DATABASE クラスは VM1 にある OAST の帯域幅を示し Background Class は VM2 にある RMAN の帯 VMware DRS および EMC Navisphere QoS を使用した VMware 仮想マシンのエンド ツー エンド サービス レベルの維持高度なテクノロジー 12
域幅を示します VM1 にある OAST が先に起動し 次に VM2 に RMAN が取り込まれます グラフに示したように RMAN とデータベース LUN がリソースで競合した場合 データベースのパフォーマンスは下降しました RMAN の取り込み後 データベースの帯域幅は約 14 MB/s から 2 MB/s に減少しました VM1 で DATABASE の帯域幅を約 15 MB/s に安定させるために 10 時 50 分に NQM Cruise Control オプションが適用されました 約 10 分後 1 ( 正確には 11 時 1 分 ) Cruise Control オプションの結果が分かりました Background Class の帯域幅が減少し データベースは帯域幅を回復しました 図 4:CLARiX ストレージ システムからのデータが示す 帯域幅における NQM Cruise Control 機能の効果 図 5 および図 6 では 3~5 分間隔で RMAN を取り込むことによる 分ごとのトランザクション (TPM) およびレスポンス タイムの減少を示します NQM Cruise Control 帯域幅オプションが VM1 に供給された LUN に適用された後 TPM の数値とレスポンス タイムが安定しました Oracle (Transactions per minute) for VM1 TPM 12000 10000 8000 6000 4000 2000 0 0 5 10 15 20 25 30 35 40 Time TPM 図 5:VM1 における Oracle OAST の分ごとのトランザクション 1 目標に到達するために 制限機能より長い時間 Cruise Control 機能を使用することができます VMware DRS および EMC Navisphere QoS を使用した VMware 仮想マシンのエンド ツー エンド サービス レベルの維持高度なテクノロジー 13
Response Time 1.6 1.4 1.2 1 0.8 0.6 0.4 0.2 0 Response Time for VM1 0 5 10 15 20 25 30 35 40 Time 図 6:(Oracle OAST を稼働する )VM1 のレスポンス タイム スループットを安定させる NQM の Cruise Control オプションの設定 同じラインで VM2 にある RMAN を稼働することによって競合が発生した後 VM1 のスループットを安定させるために Cruise Control オプションを適用したテストが実行されました 以下の DATABASE オプションは VM1 にある OAST のスループットを示し Background Class は VM2 にある RMAN のスループットを示します 図 7 に示すように 競合によって VM1 のスループットは毎秒約 2000 I/O から約 300 I/O に減少します 毎秒 1000 I/O の Cruise Control オプションが 13 時 50 分に VM1 にプロビジョニングされた LUN に適用されました この結果 競合があったにもかかわらず 一定時間後 VM1 のスループットは安定しました 図 7:CLARiX ストレージ システムのスループットにおける NQM Cruise Control の効果 図 8 は RMAN を取り込んだ際に 8~10 分間隔で発生する TPM の不安定な減少を示します VM1 に供給された LUN に NQM Cruise Control スループット オプションが適用された数分後 (10 分の手前 ) TPM の数値は徐々に増加しました VMware DRS および EMC Navisphere QoS を使用した VMware 仮想マシンのエンド ツー エンド サービス レベルの維持高度なテクノロジー 14
Oracle (Trasactions per minute) for VM1 TPM 12000 10000 8000 6000 4000 2000 0 0 10 20 30 40 50 60 Time 図 8:VM1 にある Oracle OAST の分ごとのトランザクション VM1 における Cruise Control テストの結果 2 つのテストで示したように Cruise Control オプションは一度トリガーされると VM1 の特定のサービス レベルを保証しました ユーザーはアプリケーションの要件によって NQM で帯域幅とスループットを調整できます このテスト結果は他のアプリケーションを使用するとリソースで競合する すべてのアプリケーションに適用できます したがって Cruise Control オプションは VM2 で稼働する RMAN アプリケーションにも適用可能です テスト 2:NQM の Limit 機能の使用 このテストでは NQM の Limit 機能は (VM1 で )OAST アプリケーションが稼働する LUN に適用され VM2 で稼働する RMAN バックアップ オペレーションに十分な帯域幅とスループットが供給されました VM3 で稼働する ORION アプリケーションへのリソース要求の増加も このテスト中に示されました この使用例では バックアップを特定のタイム ウィンドウ内に完了させる必要がある場合に バックアップ アプリケーションの帯域幅とスループットを増加させるために NQM が使用されました 帯域幅における NQM の Limit 機能の設定図 9に示すように 2 個の NQM I/O クラスが Navisphere 内に作成されました DATABASE クラスは VM1 でのデータベースの稼働でした Background Class は VM2 および VM3 で稼働する RMAN バックアップと ORION ベンチマーク アプリケーションで それぞれが同じ LUN セットで設定されました Background Class にパフォーマンスの下降が見られた後 15 時 53 分に VM1 の DATABASE I/O クラスで 2 MB/s の帯域幅 Limit が適用されました Background Class (VM2 に RMAN および VM3 に ORION で構成 ) オペレーションで スループットとともに帯域幅が向上しました Limit の目標は 2 分以内に達しました グラフに示されるように RMAN と ORION の帯域幅は NQM 制御を適用した後 増加しました VMware DRS および EMC Navisphere QoS を使用した VMware 仮想マシンのエンド ツー エンド サービス レベルの維持高度なテクノロジー 15
図 9: 帯域幅における NQMLimit 機能の効果 スループットにおける NQM の Limit 機能の設定 さらに VM1 に供給された LUN に対するスループットに Limit 機能を適用するテストが実行されました 図 10 に示すように 16 時 11 分に DATABASE I/O クラス (VM1) で 毎秒 100 I/O の Limit が適用されました 数分後 RMAN ワークロード (VM2) および ORION ワークロード (VM3) で構成される Background Class のスループットが増加しました 図 10:CLARiX ストレージ システムのデータが示す スループットにおける NQMLimit の効果 図 11 に示すように VM1 のレスポンス タイムは VM1 に供給された LUN への Limit 機能を持つアプリケーションによって増加し RMAN(VM2) および ORION(VM3) アプリケーションのレスポンス タイムは減少しました VMware DRS および EMC Navisphere QoS を使用した VMware 仮想マシンのエンド ツー エンド サービス レベルの維持高度なテクノロジー 16
Response Time graph Response Time 250 200 150 100 50 0 15:49:49 15:50:49 15:51:50 15:52:50 15:53:58 15:54:58 15:55:59 15:56:59 Time 15:58:00 15:59:00 16:00:01 16:01:01 16:02:01 16:03:02 図 11:VM1 VM2 VM3 を比較したレスポンス タイム グラフ VM2 and VM3 VM1 NQM の Limit 制御の削除 図 12 に示すように RMAN バックアップ オペレーションが Background Class で終了した後 16 時 25 分に DATABASE で Limit 制御オプションは無効化されました DATABASE オペレーションは通常のパフォーマンス レベルに戻りました 図 12:NQMLimit を適用して削除した場合の VM1 VM2 VM3 のスループットの比較 VM1 における Limit テストの結果これらのテスト結果が示すように Limit 制御オプションは特定のアプリケーションの帯域幅 スループット レスポンス タイムを制限できます Limit 制御オプションはオペレーションが完了すると削除できます このテスト結果は他のアプリケーションを使用するとリソースで競合する すべてのアプリケーションに適用できます したがって 同じ LUN セットに存在する RMAN(VM2) および ORION(VM3) アプリケーションに Limit 機能を適用して VM1 のパフォーマンスを向上させることも可能です Limit の目標は Cruise Control の場合よりかなり速く到達できます VMware DRS および EMC Navisphere QoS を使用した VMware 仮想マシンのエンド ツー エンド サービス レベルの維持高度なテクノロジー 17
結論 NQM は VMware ESX 環境で ストレージの使用率を高め ユーザー満足度を向上させるのに役立つアプリケーションです DRS とともに NQM を使用することで ストレージおよびサーバのリソースは Oracle データベースなどの重要なアプリケーションのエンド ツー エンド サービス レベルを維持できます その結果 重要なアプリケーションのパフォーマンスが 同じサーバやストレージのリソースを共有する重要ではないアプリケーションによって 阻害されることがなくなります サーバおよびストレージ システム全体の使用率は向上し データ レイアウトやプランニングの複雑さは軽減されます 参考 詳細については http://www.emc.com/products/systems/clariion.jsp を参照してください 関連資料 Navisphere Quality of Service Manager(NQM) 高度なテクノロジー ホワイト ペーパーは EMC.comおよび EMC Powerlink Web サイトに掲載されています CLARiiON Integration with VMware ESX Server Applied Technology ホワイト ペーパーは EMC.comおよび EMC Powerlink Web サイトに掲載されています SAN Configuration Guide は VMware.com に掲載されています Resource Management Guide は VMware.com に掲載されています SAN System Design and Deployment Guide は VMware.com に掲載されています VMware DRS および EMC Navisphere QoS を使用した VMware 仮想マシンのエンド ツー エンド サービス レベルの維持高度なテクノロジー 18