ホワイト・ペーパー 要約 物理データセンターから仮想データセンターへの移行には、仮想化され たOracle データベースを導入するためのベスト・プラクティスに関する課 題が伴います。このホワイト・ペーパーでは、仮想化されたOracle データ ベースを導入するためのEMC IT のフレームワークを示します。EMC IT のOracle 仮想導入モデルは、「as–a-Service」クラウド導入モデルのため の基盤です。 2013 年 7 月
EMC IT の仮想 Oracle 導入フレームワーク
VCE Vblock、VMware vSphere、高可用性、Distributed Resource
Scheduler、vMotion、テンプレート
•
EMC の仮想データセンターへの移行の有効化
Copyright © 2013 EMC Corporation. All rights reserved. （不許複製・禁無断転載） EMC Corporation は、この資料に記載される情報が、発行日時点で正確である とみなしています。この情報は予告なく変更されることがあります。 この資料に記載される情報は、「現状有姿」の条件で提供されています。EMC Corporation は、この資料に記載される情報に関する、どのような内容について も表明保証条項を設けず、特に、商品性や特定の目的に対する適応性に対す る黙示の保証はいたしません。 この資料に記載される、いかなるEMC ソフトウェアの使用、複製、頒布も、当該 ソフトウェア・ライセンスが必要です。
最新のEMC 製品名については、EMC の Web サイトで EMC Corporation の商標 を参照してください。
VMware、ESX、ESXI、vSphere、および VMware vCenter は、VMware, Inc.の登 録商標または商標です。その他のすべての名称ならびに製品についての商標 は、それぞれの所有者の商標または登録商標です。
目次
エグゼクティブ・サマリー ... 5 対象読者 ... 5 EMC IT の Oracle データベース仮想化の移行 ... 6 EMC IT の概要 ... 6 EMC 仮想インフラストラクチャの進化 ... 6 EMC IT のデータベースの仮想化：段階的なアプローチ ... 7 アプリケーションの合理化 ... 7 EMC IT の仮想化のビジネス促進要因 ... 8 Oracle の仮想化の成功要因 ... 9 EMC IT の Oracle 仮想化インフラストラクチャの導入 ... 10 Oracle 仮想導入フレームワーク ... 11 モデルA：VMware のみのソリューション ... 13 モデルB：クラスタ・ソフトウェアを使用した VMware ソリューション ... 13モデルC：可用性のための Oracle RAC を使用した VMware ソリューション ... 13
モデルD：拡張性のための Oracle RAC を使用した VMware ソリューション ... 13
Oracle 仮想導入モデルの作成 ... 13
VMware Converter ツール ... 13
VM を作成してデータベースを移行する方法 ... 14
VMware テンプレート ... 14
EMC IT の Oracle 仮想導入モデル ... 15
レガシー：Oracle RAC Grid ... 15
レガシー・インフラストラクチャ ... 15 現在の導入モデル：BC（ビジネス・クリティカル）Oracle Grid ... 16 将来の導入の例：DB（Database）VM Cluster ... 16 DB（Database） VM Cluster のコンポーネント ... 17 モデルA：Oracle のシングル・インスタンス導入モデル：vSphere 5.0 ... 18 vSphere データベース・クラスタ ... 18 モデルB：Oracle のミッション・クリティカルなシングル・インスタンス導入モデル... 20 ミッション・クリティカルなシングル・インスタンスのSAP インフラストラクチャ ... 20 モデルC（可用性）とモデル D（拡張性）：Oracle のミッション・クリティカルな RAC マルチ・ ノード導入モデル：VMware 5.0 ... 23 Oracle 仮想導入モデルのメリット ... 26 Oracle のシングル・インスタンス ... 26 Oracle RAC ... 27
EMC IT の Oracle 仮想導入モデルについて学習したレッスン ... 28 NUMA と Oracle データベース ... 28 メモリ・アクセス ... 29 Linux のヒュージ・ページ ... 30 透過的ページ ... 30 動的な結合 ... 30 レーテンシー ... 30 BIOS 設定 ... 30 結論 ... 31 参考資料 ... 32
エグゼクティブ・サマリー
物理データセンターから仮想データセンターへの移行には、仮想化されたOracle データベースを 導入するためのベスト・プラクティスが必要です。このホワイト・ペーパーは、仮想化されたOracle データベースの導入（ビジネス・サポート・アプリケーションとミッション・クリティカル・アプリケー ションの両方を含む）のためのEMC IT のフレームワークについて説明しています。これは、 「as-a-Service」クラウド導入モデルの基盤となります。 このペーパーでは、Oracle 仮想導入フレームワークを示しながら、EMC IT の手法を紹介します。 このフレームワークは、いつ、何を導入するかという設問に対して、2 つの主要なビジネス・サービ ス・レベルである可用性（99.9～99.999%）と拡張性（1 個～N 個の CPU）に基づく Oracle 仮想導 入モデルによって回答しています。次に示すモデルにより、Oracle 仮想導入モデルが合理化され、 高速化されます。また、EMC IT の運用とインフラストラクチャのコスト削減、統合、効率化が実現さ れます。 Oracle 仮想導入フレームワークには、次のモデルがあります。 • モデル A：VMware テクノロジーのみを使用した VMware ソリューション • モデル B：クラスタ・ソフトウェアを使用した VMware ソリューション• モデル C：高可用性のために Oracle RAC を使用した VMware ソリューション • モデル D：拡張性のために Oracle RAC を使用した VMware ソリューション
EMC では、これらの仮想導入モデルを使用し、ミッション・クリティカルなアプリケーションを導入し ます。 EMC は次の仮想データベース・モデルを作成することにより、EMC のデータセンターの運用コスト （運用のためのコストである OPEX）と設備コスト（購入のためのコストである CAPEX）を削減します。 • モデル A：統合レベルの向上（物理サーバから仮想サーバへ）、CAPEX と OPEX の削減、 俊敏性の向上、数か月かかっていたOracle の導入が数分で完了
• モデル B：Oracle RAC モデルからの脱却、大幅な CAPEX 削減（Oracle RAC ライセンスが不 要）およびOPEX 削減（Oracle データベース管理の合理化、より少ない OS イメージ） • モデル C：高密度の統合、CAPEX と OPEX を削減 • モデル D：リソース使用率とハードウェアの独立性の向上 対象読者 このホワイト・ペーパーは、CIO、Oracle アーキテクト、仮想化アーキテクト、ストレージ・ アーキテクト、Oracle DBA（データベース管理者）、さらに仮想化管理者、サーバ管理者、 ネットワーク管理者を対象としています。
EMC IT の Oracle データベース仮想化の移行
EMC IT の概要 EMC は、IT サービスのユーザーが 50,000 人を超える企業です。5 か所のデータセンターで 10 PB を超えるストレージを使用し、400,000 人を超える顧客とパートナーをサポートしていま す。EMC IT が保持するポートフォリオには、500 を超えるビジネス・アプリケーションとツール、 6,000 を超える OS イメージが含まれています。また、80 か国（20 の言語）において全体の 80%を超えるサーバが仮想化されています。 EMC 仮想インフラストラクチャの進化EMC の Oracle データベースへの移行をよりよく理解するには、EMC が実施した仮想インフラ ストラクチャの移行（専用の「カスタム・ビルド」から「セルフ・サービス・クラウド」のアーキテク チャおよび導入モデルへ）について知ることが重要です。
次の図1 に示すように、EMC IT の仮想インフラストラクチャの移行は 4 段階で構成されます。
EMC IT の仮想化の移行の詳細な解説については、以下の URL を参照してください。
EMC and VMware Virtualizing Oracle Solutions with Confidence EMC IT's Journey to the Private Cloud：Server Virtualization EMC ITにおけるプライベート・クラウドへの移行：実践ガイド
EMC IT's Journey to the Private Cloud：Applications and Cloud Experience
EMC IT のデータベースの仮想化：段階的なアプローチ 仮想化されたデータセンターへの移行作業は、あらゆる組織（特にデータセンター）において、 スタッフ、プロセス、テクノロジーという3 つの主要な構成要素を、仮想化された Oracle 環境 の計画、構築、導入に組み込みむ、綿密な段階的アプローチの 1 つです。このセクションでは、 EMC の段階的アプローチに焦点を当てます。 アプリケーションの合理化 アプリケーションを仮想アプリケーションに移行させる前に、EMC IT はアプリケーションの合理 化プロセスを徹底的に行います。このプロセスでは、EMC のアプリケーション・ポートフォリオ を分析し、アプリケーションのニーズを合理化し、標準化して、EMC IT のアプリケーション環境 に統合することで、ビジネス戦略全体をサポートします。 EMC IT によるデータベースの仮想化の移行は、第 1 段階です。次に、大まかな図を示します。
第1 段階は、計画、構築、導入です。 物理サーバから仮想マシン（VM）への移行を計画します。仮想マシン（VM）のインフラスト ラクチャを構築します。仮想化されたすべての新しいビルドを導入します。次に、第1 段階 の例を示します。 • すべての新しいビルドを仮想としてコミット • アプリケーション層の開発とテスト • 初期の変換：VMware Converter を使用して物理 OS を仮想 OS に変換 第2 段階は仮想化です。 第1 段階で学習したすべてのレッスンは、すべての Oracle 導入で実質的に導入されま した。 • すべての新しい Oracle ビルド • すべての Oracle シングル・インスタンス • 可用性のための RAC • テストとミッション・クリティカルではない本番 • RAC からシングル・インスタンスへ 第3 段階は、最終確認です。 残りのOracle 導入は次のとおりです。 • ミッション・クリティカルなアプリケーション • 大量のアプリケーション EMC IT の仮想化のビジネス促進要因 仮想化のためのビジネス促進要因を次に示します。 1. 統合：データセンター内の削減 2. コスト削減：サーバ、ストレージ、使用されなくなったレガシー・プラットフォーム、ソ フトウェア・ライセンス 3. 運用の俊敏性：OS とデータベースの両方を含む、より迅速な導入 4. 標準化：コンピューティング・プラットフォームの x86 OS プラットフォーム Linux、仮 想化：VMware 5. 合理化：標準化によって可能な運用 このビジネス促進要因のうち、促進要因の1 と 2（統合、コスト削減）に該当するのが設備 コスト（CAPEX、購入コスト）です。運用コスト（OPEX、運用のためのコスト）は、促進要因の 3～5（運用の俊敏性、標準化と合理化）に該当します。
Oracle の仮想化の成功要因
EMC IT で Oracle を仮想化するための現在のテクノロジーを、次に示します。 • Intel の最新の CPU テクノロジー（Xeon/Nehalem）
メモリの密度の向上に伴う CPU の進歩により、ほとんどのシングル・インスタン ス・データベースで必要とされる量の何倍ものCPU とメモリが、単一のサーバ で利用可能になっています。そのため、多くの場合、サーバ・リソースの効率的 な使用を推進する手段は仮想化のみとなります。 • オープンなハードウェア/ソフトウェア・プラットフォームへの移行 次を参照してください。
EMC IT's "On-Ramp" to the Journey to the Private Cloud • VMware vSphere
vSphere 4 のリリースにより、EMC では 8 個の vCPU と 255 GB のメモリを備え たVM を作成できるようになり、大規模データベースのワークロードにも十分対 応できるようになりました。vSphere 5 ではさらに上限が 32 個の vCPU と 1 TB のメモリにまで拡大され、非常に大規模なデータベースのワークロードに対応 できるようになりました。 • 可用性とリソース・プーリング 次を参照してください。 http://www.vmware.com/products/high-availability/overview.html http://www.vmware.com/products/drs/overview.html • VMware の Oracle サポート・ポリシー Oracle の VMware オーナーシップに関する技術的な問題： http://www.vmware.com/support/policies/oracle-support.html
EMC IT の Oracle 仮想化インフラストラクチャの導入
次の図は、Oracle の各インスタンス・タイプで使用される導入の戦略を示しています。 図3：Oracle 仮想化導入モデルと Oracle インスタンス 次の図に示すように、1 個以上の ESX クラスタで、Oracle データベースは類似のグループに分割 されます。この操作は主にOracle ライセンスに準拠することを目的に行われますが、これにより リソースを類似の占有領域ごとにグループ化することもできます。これらのグループは、別個の ESX クラスタごとに物理的に分割するか、VMware の DRS ホスト親和性グループを使用して論理 的に分割します。DRS（Distributed Resource Scheduler）は、vSphere がリソース・プール内のすべての ESX サーバ で利用可能な処理能力を調整するための独自のテクノロジーです。その管理のために、より負荷 の高いESX サーバから負荷の低い ESX サーバまで、VM の vMotion を実行します。この方法に より、すべてのコンピューティング・リソースのピーク使用率が許容され、他の仮想化テクノロジー に比べて非常に高い統合比率を達成できます。VM を特定のリソース・プールに割り当てることに より、そのVM の起動またはプール外のサーバへの移動を防ぐことができます。
図4：ESX/ESXi クラスタ内の Oracle インスタンスの導入 EMC が定義した Oracle データベース・グループは次のとおりです。
• Oracle Enterprise Edition • Oracle Standard Edition • Oracle RAC
• Oracle Enterprise Edition：外部向け
これらのグループ内で、多数の異なるVM カテゴリーのタイプがあります。データベースが非常に 小さい場合、EMC では複数のアプリケーション・データベースを 1 個の VM に結合します。これは、 物理的に別個のデータベースか、1 個のデータベース内の複数のスキーマにすることができます。 もっと大規模なデータベースやミッション・クリティカル・データベースの場合、EMC では 1 個の VM をそれに割り当てます。この場合は、アプリケーション間で競合する要件がないので可用性が 向上します。この手法により、このようなデータベースで 99.99%のアップタイムを実現しています。 Oracle 仮想導入フレームワーク いつ、何を仮想化するかについてしばしば議論されますが、事実に基づかない討論になることが よくあります。たとえば、多くのインフラストラクチャ管理者は、すべてを仮想化できるならば仮想 化すべきだと考えます。一方、多くのDBA は仮想化に反対します。データベースは効率的に仮想 化できないから仮想化すべきでないと考えるのです。 現実的な対応は、双方の意見の中間にあります。仮想化には多くのメリットといくつかの制約が ありますが、一般的に、すべてのデータベースとアプリケーションは仮想化するだけで何らかの恩 恵を受けます。
EMC IT は、このメリットと制約に基づいてガイドラインを作成しました。図 5 を参照してください。 図5：EMC IT の仮想導入モデル・フレームワーク 促進要因の2 種類のビジネス・サービス・レベルである可用性と拡張性を使用して、EMC IT は仮想導入フレームワークを作成しました。EMC ビジネス・ユーザーのニーズに応じて、さま ざまなレベルの可用性を使用します。 次の表に、可用性の基準を示します。 可用性の比率 年間のダウンタイム 月あたりのダウンタイム 週あたりの ダウンタイム 99.9%（「スリー・ ナイン」） 8.76 時間 43.2 分 10.1 分 99.99%（「フォー・ ナイン」） 52.56 分 4.32 分 1.01 分 99.999%（「ファイブ・ ナイン」） 5.26 分 25.9 秒 6.05 秒 表1：可用性の分布 *月あたりの計算では 30 日間を使用しています。 拡張性の基準は、アプリケーションが必要とする物理CPU の数に基づいています。拡張性の 基準が、CPU 数 8 個から N 個（たとえば、32 個の物理 CPU）へと拡大し、対応する仮想 CPU （vCPU）にマッピングされます。
EMC の 4 種類の Oracle 仮想導入モデルについて、大まかな説明を次に示します。
モデルA：VMware のみのソリューション
このOracle 仮想導入モデルは、Oracle 仮想化インスタンスを導入する「純粋な」VMware ソ リューションを使用して導入されます。このソリューションは、VMware HA、DRS、SRM、新しい VMware Guest App Monitor のテクノロジーに完全に依存しています。
モデルB：クラスタ・ソフトウェアを使用した VMware ソリューション
このOracle 仮想導入モデルは、クラスタ・ソフトウェア（Oracle クラスタウェア（CRS）など）を追 加することでVMware ソフトウェアに導入されます。
モデルC：可用性のための Oracle RAC を使用した VMware ソリューション
このOracle 仮想導入モデルは、追加の Oracle RAC を追加することで VMware ソフトウェアに 導入されます。このモデルは、ファイブ・ナインつまり99.999%（計画外のダウンタイムが 1 年 あたり5.26 分未満）という可用性のビジネス・サービス・レベルを達成することが必要です。
モデルD：拡張性のための Oracle RAC を使用した VMware ソリューション
このOracle 仮想導入モデルは、追加の Oracle RAC を追加することで VMware ソフトウェアに 導入されます。このモデルは、最大級のOracle アプリケーションで必要とされる拡張性および 処理能力を達成する必要があります。
Oracle 仮想導入モデルの作成
Oracle 仮想環境を導入する 2 種類の方法があります。 VMware Converter ツール
VMware の vCenter Converter ツールは、物理マシン（Windows や Linux が動作している）、他 の仮想マシン形式、サード・パーティのイメージ形式からのVMware 仮想マシン作成プロセス を自動化する、使いやすいソリューションを実現します。 メリット • Windows または Linux オペレーティング・システムを実行している物理マシンを、 VMware 仮想マシンに迅速に変換します。停止やダウンタイムはほとんどありま せん。
• Parallels Desktop、Symantec Backup Exec System Recovery、Norton Ghost、 Acronis、StorageCraft、Microsoft Virtual Server、Virtual PC、Microsoft Hyper-V Server 仮想マシンなどサード・パーティのイメージ形式や仮想マシン形式を VMware 仮想マシンに変換します。 • 複数の物理サーバまたは仮想マシンを同時にリモート変換する操作を一元管理で きます。 • データ移行前に、ソース・マシン上のゲスト・オペレーティング・システムの停止ス ナップショットを作成することで、変換の信頼性を確保します。 • ホット・クローン作成により無停止での変換を実行でき、ソース・サーバでダウンタ
VM を作成してデータベースを移行する方法 2 番目の方法は、新しい VM を構築し、Oracle データベースを物理サーバから VM に移行 する方法です。これは、オペレーティング・システムのバージョンをさらに標準化する場合 に便利な方法です。物理サーバーに存在するバージョンと同じバージョンを保持する代わ りに、新しいバージョンを自由に開始できます。Oracle データベース（DB）とオペレーティン グ・システム（OS）の互換性を確保するために多少の労力が必要ですが、現在の物理環 境に標準化が不足している場合、その価値はあります。この移行方法では、データベース がインストールされているデバイスの物理レイアウトをより簡単に変更することもできます。 データベースの移行は、データファイルの物理ファイル・コピーやデータベース全体のエク スポート/インポートで行うことができます。また、vRDM（仮想 raw デバイス・マッピング）を 作成してイン・プレース移行にすることもできます。vRDM への移行では、実際のデータ ベース・ファイルの移動は不要です。また、必要に応じて、非常に迅速なカットオーバーと 撤回も可能です。RDM 方式の唯一のデメリットは、SRM で導入されたストレージの vMotion 機能および複雑性がないことです。 両方の移行方法にはそれぞれのメリットがあります。通常は、移行するデータベースに応 じて、両方の方法を組み合わせて使用すると便利です。 VMware テンプレート VMware テンプレートは、コピーして新しい VM（仮想マシン）を作成できる、VM のイメージ です。テンプレートを使用すると、新しいVM の作成プロセスで繰り返される手動の手順の 多くを省略できます。標準テンプレートには、基本OS（オペレーティング・システム）と、す べての標準ソフトウェア（通常はすべてのマシンにインストールされるウイルス対策、バッ クアップ・エージェント、監視エージェントなど）が含まれます。テンプレートを使用すると、 導入が迅速になるだけでなく、環境全体の整合性を確保した構成が可能になります。 VMware で動作しているデータベースの場合、テンプレートをさらに強化できます。Oracle ソフトウェアの基本インストールを追加することにより、導入時間を数時間短縮でき、ベス ト・プラクティスを含めることもできます（hugepage 構成、Oracle の必須カーネル・パラメー タ、標準化されたディレクトリの場所など）。テンプレートにスクリプトを少し追加することに より、プロセスで作成前のデータベースの名前を変更し、すべてのベスト・プラクティスを init.ora に組み込むことができます。さらに、データベース内部とリスナー構成内の両方に セキュリティのベスト・プラクティスも含めることができます。これらの追加により、テンプ レートのメリットがデータベースにも及び、データベースVM の新規作成プロセスから、手 動の手順がすべて削除されます。
EMC IT の Oracle 仮想導入モデル
このセクションでは、EMC IT の Oracle 仮想導入モデル A、B、C、D に焦点を当てます。以前のモ デルや既存のモデルについて説明した後で、固有の例を示して説明します。
レガシー：Oracle RAC Grid
EMC は、スタンドアロンのビジネス・サポート/ビジネス・クリティカル Oracle データベース・ サーバ48 個を、物理システム上の Oracle 2 ノード RAC の 2 セットに統合しました。 • 本番 • 開発とテスト 図6 を参照してください。 レガシー・インフラストラクチャ 統合の前には、51 個の Oracle データベースが、9 種類の Oracle バージョン、3 種類の OS（MS Windows、Linux、Solaris）、51 個の物理サーバで実行されていました。
統合されたビジネス・クリティカルなOracle Grid は、1 種類の Oracle バージョンと 1 種類 のRed Hat Linux OS バージョンで動作し、3 種類のデータベース（本番、テスト、開発）の みが実行されています。これらのデータベースは、38 個の別個のビジネス・クリティカル・ アプリケーションまたはビジネス・サポート・アプリケーションをホストします。4 個の物理 サーバのみが使用されます（本番用の2 ノード RAC、テストと開発用に共有される 2 ノード RAC）。 これにより、システム・メンテナンス・タスクが大幅に合理化され、データベース管理のオー バーヘッドが減少します。DBA は空いた時間を、よりプロアクティブなイニシアティブのた めに使うことができます。
達成されたデータベースの統合比率はおよそ13：1 で、アプリケーション対データベース の比率は38：1 です。実現されたコスト削減は、3 年間で約 250 万 US ドルでした。
図6：EMC のレガシー・ビジネス・クリティカルと現在の Oracle RAC Grid の導入
現在の導入モデル：BC（ビジネス・クリティカル）Oracle Grid
現在のBC（ビジネス・クリティカル） Oracle Grid は、x86-64 プラットフォームと Red Hat Linux Enterprise Edition 5.x でホストされています。また、データベース・ストレージ管理には Oracle ASM（Automatic Storage Management）が使用されています。
Oracle RAC（Real Applications Cluster）は、BC Oracle Grid で実行されているデータベースの 高可用性とロード・バランシングを提供します。Grid データベースは、マルチ・テナント・データ ベースです。個別のアプリケーションが単一のグリッド・データベースにスキーマを保持します。 各アプリケーションには、データベース接続用の別個のサービス名が割り当てられています。
将来の導入の例：DB（Database）VM Cluster
EMC では、DB（Database）VM Cluster の構築と導入を進めています。これは、クラスタ内のす べてのビジネス・クリティカル・データベースとビジネス・サポート・データベースをホストするこ とを目的としています。DB VM Cluster は、VMware vSphere 5.0 で導入され、99.9%のアップ タイムを提供するVMware HA のみをサポートしています。EMC で、99.99%超のアップタイム を必要とするのはミッション・クリティカルなデータベースのみです。EMC で、災害復旧サイトを 必要とするのはミッション・クリティカルなデータベースのみです。このESX クラスタではミッショ ン・クリティカルなデータベースがホストされないので、vSphere SRM（Site Recovery Manager） は必要ありません。
DB（Database） VM Cluster のコンポーネント
データベースVM は、専用の ESXi クラスタを保持し、次のデフォルト仕様を含む標準ビル ディング・ブロック（図7）です。
• 4 個の vCPU x 32 GB の RAM • Red Hat Enterprise Linux 5.6
• Oracle のバージョン：10.2.0.4、11.1.0.7、11.2.0.2 • VMFS • データ、REDO、一時、アーカイブ用の共有データストア • 階層型ストレージを含む FAST VP 図7 のマルチ・テナント VM は、現在の物理 BC Grid の本番データベース、テスト・データ ベース、開発データベースを置き換えて、データベース内で引き続き複数のアプリケーショ ンをスキーマとしてホストします。クラスタ内の他のVM は、ミッション・クリティカルではな いアプリケーションのための個別のデータベースをホストします。また、非常に低い使用パ ターンの小規模ビジネス・サポート・アプリケーションをホストするVM もあります。これらの VM では、複数のデータベースが動作しています。この方法を使用し、サポートが必要な OS イメージとデータベースを削減することにより、データベース層の外部で効率化を促進 します。 すべての新しいデータベースVM は、定義済みのテンプレートを使用して構築され、すぐ に導入に使用できるようになります。各データベースVM は、複数のデータベースをサ ポートすることができ、3 種類の Oracle バージョン（10.2.0.4、11.1.0.7、11.2.0.2）のいず れかをサポートします。データベース・ストレージは、事前にデータベースVM に割り当て られ、同じESXi クラスタ上のデータベースによって共有されます。
EMC DBA（データベース管理者）は、これらの Oracle データベース VM のビルディング・ブ ロックをすぐに使えるように準備することで、ビジネス・クリティカル・データベースやビジネ ス・サポート・データベースの俊敏な導入のためのアプリケーション・チームやアプリケー ション・プロジェクトのニーズを満たすことができます。データベースの構築リード・タイムが 数週間であるのに対し、Oracle データベース・リクエストのターンアラウンド時間は 2 日未 満に短縮されます。
図7：仮想化されたビジネス・クリティカル導入：モデル A モデルA：Oracle のシングル・インスタンス導入モデル：vSphere 5.0 DBaaS（Database-as-a-Service）については、クラウド全般の議論の中で多くの時間をかけて 話し合われてきましたが、その使用例が明らかでない場合がよくありました。EMC では、数年 間、この使用例を構築してきました。現在は使用例に基づいてデータセンターで導入し、実際 の問題を解決しています。 vSphere データベース・クラスタ
EMC IT は、特にデータベース VM のために VMware vSphere クラスタを開発してきました。 本番ワークロード用のクラスタと、本番以外のワークロード用のクラスタがあります。どちら のクラスタも同じVCE Vblock リファレンス・アーキテクチャ上に存在します。Vblock アーキ テクチャにより、どちらのクラスタも、要求の増大に応じて非常に簡単に拡張できます。 2 個の別個のクラスタを使用すると、本番環境に影響を与えることなく本番以外の環境で アップグレードをテストできます。 これらのクラスタでは、特定のワークロードのニーズに応じて、リソース・プールを使用して さまざまなレベルのサービスを提供します。重要でないワークロードがリソース・プールに 含まれており、リソースの競合が発生した場合は、重要性の高いワークロードにリソースが 提供されます。このリソース・プールの使用により、EMC IT では、重要な本番ワークロード に悪影響を与えずに、リソースのオーバー・プロビジョニングを安全に行うことができます。
図8：仮想化された導入モデル A：Oracle のシングル・インスタンスの導入 Oracle データベースの場合、ライセンス上の理由から、本番データベースはより小さい DRS グループのセットに論理的に隔離されますが、未使用の容量を使用してクラスタの残 りの部分を強化できます。このデータベース・クラスタにより、EMC IT は環境を迅速にプロ ビジョニングできます。 その結果、EMC IT は調達サイクルやビジネス・ジャスティフィケーションに関係なくプロジェ クトを進めることができます。また、仮想実習のためのリソースを用意できるようになります。 仮想実習では、DBA、開発者、システム管理者が空き領域を使用して POC、アップグレー ド・テスト、ツールのトライアルを実行できます。この方法で、下位の階層型データベース VM と上位の階層型 VM を組み合わせてサービス・レベルを保証することにより、統合比 率を大幅に高めることができます。 EMC IT では、データベースとアプリケーションの階層を導入するのに以前は数日かかって いましたが、今では数分から数時間で導入できるようになりました。この能力により、EMC は、以前よりも短期間でプロジェクトを完了させる俊敏性を獲得しました。また、EMC IT は、
モデルB：Oracle のミッション・クリティカルなシングル・インスタンス導入モデル
EMC の ERP インスタンスについては、EMC には非常に高い可用性へのニーズがあります。 以前は、EMC のフォー・ナイン（99.99%）の SLA をサポートするために多数の RAC（Real Application Cluster）物理データベースを実行する必要がありました。VMware のサーバー 仮想化テクノロジーの可用性により、この目標をほぼ達成できています。OS と RDBMS カーネルのためのパッチ実行に長時間かかるようになったため、EMC IT では、VMware HA 単独で規定のSLA を完全に達成することはできませんでした。この特定のインスタンスに ついては、EMC は Oracle Clusterware を追加することによって問題を解決しました。 Clusterware により、データベースやアプリケーションが他の VM にフェイルオーバーする 機能が追加されます。このフェイルオーバーは、計画的なイベントと予想外のイベントに対 して機能します。EMC IT では、データベースと SAP 中央インスタンスの両方のコンポーネ ントに対して、このテクノロジーをSAP ERP システムに導入します。 Clusterware は、この導入モデルで、いくつかの使用例に対してソリューションを提供します。 • ハードウェアの障害：Oracle CRS では、データベースをスタンバイ・モードにします。 ユーザーは、一時的に影響を受けます。 • データベース・リスナーの障害：CR はリスナーを再起動します。ユーザーへの影響 はありません。 • データベースの障害：CRS はデータベースを再起動します。ユーザーは一時的に 影響を受けます。 • OS またはデータベースのパッチ実行：ローリング・アップグレードを実行します。 ユーザーへの影響はありません。 ミッション・クリティカルなシングル・インスタンスのSAP インフラストラクチャ
この導入は、ミッション・クリティカルなSAP ランドスケープです。VMware vSphere と Oracle CRS を使用して複数のシングル・インスタンス・データベースと SAP アプリケーショ ン・コンポーネントをサポートします。
このインフラストラクチャを使用するSAP モジュールには以下が含まれます。 • ECC（Enterprise Central Component）
• BW（ビジネス・ウェアハウス） • PLM（製品ライフサイクル管理） • SRM（サプライヤ・リレーションシップ管理） • SCM（サプライ・チェーン・マネージメント） • BI（ビジネス・インテリジェンス） 基盤となるインフラストラクチャは、vSphere 4.1 からアップグレードされた VMware の vSphere 5.0 仮想化プラットフォームを実行する、Vblock リファレンス・アーキテクチャ上に あります。これにより、SAP スタック内の多数の要素をサポートする論理的に分離された Oracle CRS グリッドとともに、多数のミッション・クリティカルな VM が単一の ESXi クラスタ 内に提供されます。
このESXi クラスタでは、より大きな 8 個の VM が Oracle のシングル・インスタンス・データ ベースを格納します。次の図を参照してください。Oracle ライセンス要件があるので、これ らはクラスタの残りの部分から分離され、さらにOracle CRS で保護されています。SAP CI コンポーネントはCRS クラスタで実行され、CRS HA 機能の恩恵を受けています。 このクラスタ内でデータベースまたはデータベース・コンポーネントのいずれかがクラッ シュした場合、CRS は自動的にそのリソースをオンライン状態に戻します。クラッシュの原 因がOS のクラッシュまたはサーバの障害だった場合、データベースは即座に別の VM で 起動されます。障害が発生したVM では、バックアップが開始され、その後はその VM を フェイルオーバー・ターゲットとして使用できます。 図9：Clusterware を使用した、 仮想化された導入のOracle シングル・インスタンス導入：モデル B 残りのSAP アプリケーション・コンポーネントは、ESXi クラスタの残りの部分で実行され、 HA、vMotion、DRS など組み込み VMware vSphere の機能のメリットを活用します。 この導入には、通常のサーバ統合に比べて多くのメリットがあります。この環境では、ハー ドウェア・コストの削減、より簡単で高速なアップグレード・パス、データセンター・リソース の使用率の向上など、vSphere が持つすべてのメリットを得られます。この導入フレーム ワークにより、EMC は RAC（Real Application Cluster）導入と同様のアップタイムを達成す
高い統合比率モデル
EMC IT の Project Propel（SAP）では、現在、約 283 台の物理サーバが使用されていま す。代わりに、EMC IT は、これらを約 42 個の ESXi サーバという 100%仮想化されたイ ンフラストラクチャで置き換えます（およそ7：1 の統合比率になります）。これには、 SAP 環境のライフサイクル全体（本番、開発、テスト、パッチ、パフォーマンスなど）が含 まれます。
モデル・インフラストラクチャ
• SAP プログラムは、VCE Vblock リファレンス・アーキテクチャ（シリーズ 700）で 導入されました。これには、Cisco UCS の高密度なハーフ幅ブレード（Intel Xeon のNehalem プロセッサと Westmere プロセッサ、256 GB の RAM を搭載）が含 まれます。 • この環境では、Cisco UCS の設計に固有の統合ネットワーク・アーキテクチャも 使用されます。ケーブル接続とスイッチ構成に関する冗長コンポーネントとデー タセンターのベスト・プラクティスは、ハードウェア障害による影響を抑えるため に役立ちます。 • VMAX、Unified（VNX）、VPLEX など、EMC の優れたストレージ・インフラストラク チャが中心的なコンポーネントになっています。
• vSphere の pRDM（物理的な raw デバイス・マッピング）ストレージが、EMC アレ イ・ベースのレプリケーション・テクノロジー（TimeFinder、SRDF）と組み合わせて 使用されました。これにより、大規模データベース用の高速な環境クローン作 成、効率的な災害復旧、高速な無停止のバックアップを実現しています。 • VMware vSphere 5.0 は、標準的なデータセンターの「オペレーティング・システ ム」、つまりハイパーバイザであり、充実した可用性と管理機能が大規模VM のサポートとともに提供されます。
• Cisco UCS ブレード環境は、「サービス・プロファイル」と SAN ブートを使用して、 本当の意味でステータスや情報を持たないハードウェアVblock を実現します。 モデルVMware インフラストラクチャ
• 仮想マシン
標準テンプレートのセットを使用してインストールされます。それぞれ、固有 の VM クラス（データベース、SAP ダイアログ・インスタンスなど）を定義します。 VMware pRDM デバイスは、PowerPath/VE for VMware vSphere を使用し
て最適なパフォーマンスを得るために、3 個の SCSI コントローラで分割さ れます。 • オペレーティング・システム Redhat AS 5.6 Oracle は導入時に 6.x をサポートしていませんでした 内部サテライト・サーバでリリースを管理します Microsoft Windows 2008R2 NAS で提供される SAP コード
モデルのOracle コンポーネント
• Oracle CRS（Cluster Ready Services） 11.2 CRS は以下を保護します。 Oracle シングル・インスタンス・データベース Oracle リスナー SAP エンキュー・レプリケーション SAP 中央インスタンス アプリケーションの仮想 IP アドレス • Oracle ASM SAN ベースの障害復旧サイトへのストレージ・レプリケーションと、バック アップの分離のために、モジュールのECC と BW にはそれぞれ、固有の ディスク・グループのセットが含まれています。 ディスク・グループは、データ、REDO、アーカイブ、一時に分かれています。 • Oracle データベースのバージョン 11.2 • Asmlib：構成とトラブルシューティングを容易に行うため • RMAN：データベースのバックアップ用
• Oracle Enterprise Manager：データベースの監視と解決に使用
モデルC（可用性）とモデル D（拡張性）：Oracle のミッション・クリティカルな RAC マルチ・ノード導入モデル：VMware 5.0 EMC IT のミッション・クリティカルなデータベースは、収益に影響を与えるシステムなので、 99.999%（予想外のダウンタイムが 1 年あたり 5.26 分未満）の可用性が必要です。これらの データベースは、EMC IT の「四半期末」と「年度末」の処理要求に対応できるように拡張性が 高くなっています。このような可用性と拡張性の要件を達成するために、Oracle RAC を使用し てします。 このような可用性と拡張性の目標があるので、これらのデータベースにはモデルC と D が必 要です。
現在、EMCのミッション・クリティカルなCRMアプリケーションは、vSphere 5 への移行計画によ り、VCE Vblockリファレンス・アーキテクチャ 700 プラットフォーム上の物理的な 4 ノードRAC データベース（図10 を参照）で実行されています。中間層アプリケーション・サーバは、仮想 化されたプラットフォームですでに実行されています。（EMC ITのホワイト・ペーパー
「EMC IT's "On-Ramp" to the Journey to the Private Cloud」を参照してください。）
図10：EMC IT の現在の Oracle CRM 導入モデル 従来は、新しいノードをRAC データベースに追加する必要がある場合、DBA のほとんどの時 間が新しいサーバの調達と構築に費やされます。新しいノードを本番RAC データベースに追 加する準備が整うまで、何か月もかかる場合があります。vSphere では、テンプレートを使用 して数分から数時間で新しいVM を構築できます。その後で、この新しい VM を既存の RAC データベースに追加できます。ダウンタイムはありません。 さらに、ESX/ESXi クラスタにハードウェアの容量がある場合は、RAC データベースを数時間で 水平に拡張できます。これは、追加の処理能力が必要な場合に非常に便利です。Oracle RAC をvSphere で実行すると、新しいノードを追加するためのターンアラウンド時間が大幅に短縮 されます。 モデルA と B は、ワークロードを 1 個のサーバで実行した場合に効果的に機能します。ワー クロードを実行するリソースが1 個のサーバでは足りない場合は、データベースを水平に拡 張する必要があります。この場合は、Oracle RAC が役立ちます。Oracle RAC データベースを 複数のサーバに拡張し、ワークロードの要求を満たす十分な処理能力を提供します。 このミッション・クリティカルなデータベースは、VMware vSphere 5.0 で導入された、仮想化さ れた4 ノード RAC データベースで導入されます（図 11 を参照）。以前の vSphere 4.1 では、 VM ごとに 8 個の vCPU という制限があったため、これを実現できませんでした。vSphere 5.0 では、各VM で最大 32 個の vCPU と 1 TB のメモリを保持できます。これにより、EMC IT では、 追加の処理能力を必要とする、あらゆるミッション・クリティカルなデータベースを仮想化でき るようになりました。
今後、これは同じVblock リファレンス・アーキテクチャのインフラストラクチャ上で、専用の vSphere 5.0 クラスタを使用して導入される予定です。Oracle ライセンスの要件に基づき、この クラスタはRAC データベース用に予約されます。このデータベースをホストするために使用さ れた同じ物理ハードウェアに、他のRAC データベースを追加できます。
Oracle 仮想導入モデルのメリット
このセクションでは、仮想化されたOracle 導入モデル（RAC、シングル・インスタンス）のメリット と、Oracle Enterprise Edition から Standard Edition モデルに移行する機能について詳しく説明 します。
Oracle のシングル・インスタンス
Oracle のシングル・インスタンス（非 RAC）のデータベースは、VMware vSphere 環境に導入す ることで非常に大きなメリットが得られます。最も顕著なメリットは高可用性です。OS が物理 サーバにバインドされなくなるため、データベース自体もバインドされません。どのタイプの ハードウェア障害が発生しても、データベースが単純に別のノードで再起動されるだけです。 この機能はVMware HA と呼ばれ、あらゆるデータベースまたはアプリケーションに高可用性 が自動的に追加されます。 vSphere 5.0 では、別のレベルの HA 機能が追加されました。現在、vSphere にはサービスを 監視するVMware GuestAppMonitor という機能があります。この機能により、リスナーやデー タベースなどのサービスを監視できます。また、サービスが応答しなくなった場合、vSphere は VM を再起動して問題を解決できます。 Oracle データベース・サーバの使用率は、通常、非常に低い値です。VMware クラスタ内の仮 想化により、EMC では、より多くのデータベースをより少ない物理サーバに導入して、サーバ 上の未使用のリソースを効率的に使用することができます。また、VMware DRS テクノロジー を使用して、これらのデータベースの統合を強化することもできます。これらの両方の機能を 使用した結果、データベースを実行するためのハードウェア・コスト、ライセンス・コスト、サ ポート・コストが大幅に削減されます。
Distributed Resource Scheduler は、vMotion を使用し、DRS リソース・グループ内のすべての サーバにおけるリソースの使用を調整する機能です（デフォルトでクラスタ内のすべてのサー バが対象）。つまり、1 個以上のデータベース・サーバが、物理 ESX サーバで使用可能な量よ りも多くのリソースを必要としている場合、vSphere DRS は使用率の低い他の ESX サーバに 1 個以上の VM を無停止で移行します。管理者はこの vMotion テクノロジーを使用して、実行 中のVM を ESX サーバ間で移行することもできます。この vMotion による移行では、VM で実 行されているサービスに対するダウンタイムがありません。また、VM で発生しているトランザ クションでもオーバーヘッドがほとんど感じられません。
VMware vCenter SRM（Site Recovery Manager）は、別個にライセンスが付与されるアドオン機 能です。SRM は、SRDF や Recover Point テクノロジーのような EMC レプリケーションと連携し、 スクリプトがほとんど不要な、完全に自動化された災害復旧環境を実現する機能です。これ は、自己記述型で一元的に配置される、DR 実行計画のためのリポジトリを提供します。また、 この環境を実際の本番システムから隔離してフェイルオーバーのシミュレーションを実行する ことにより、本番システムに影響を与えずに完全なDR テストを実行することもできます。
Oracle RAC
vSphere での Oracle の仮想化の多数のメリットに加えて、RAC にはもう 1 点メリットがありま す。物理サーバでRAC を使用する場合は、サーバの障害に備えて、CRS クラスタには負荷に 対応するための追加ノードが少なくとも1 個は必要です。vSphere では、VM がクラスタ内の 別のESX サーバで即座に再起動されるので、この要件がありません。
Oracle RAC からシングル・インスタンスへの使用例
多くの場合、EMC IT は、可用性の要件をサポートするために Oracle RAC を導入してきました。 これは、特にミッション・クリティカルなデータベースの場合に適した手法でした。この方法では、 データベース管理が非常に複雑化し、EMC で発生する停止の根本原因となることもよくありま した。これらのデータベースをVMware の vSphere 製品に移行することにより、EMC IT では、 EMC の Oracle データベース・ランドスケープを大幅に合理化できます。ほとんどの場合、EMC でRAC を使用した場合に比べてアップタイムが向上すると予想されます。また、運用コスト（ラ イセンス、人件費、ハードウェアのコスト）も大幅に削減されます。 たとえば、ミッション・クリティカルなアプリケーションを小規模な2 ノード RAC でサポートしてい るとします。これをVM に移行すると、以下が排除または削除されます。 1. 1 個の Oracle フル・ライセンス 2. Oracle RAC ライセンス 3. Oracle サポート・コスト（削減される） 4. 完全な Oracle RAC サーバ
5. Oracle RAC 相互接続の専用 VLAN 6. 管理コストと複雑さ（削減される）
これらのコスト削減（1～6）を他の Oracle インスタンス環境（開発、テスト、パッチなど）に拡大 すると、経済的なメリットが非常に大きくなります。
Oracle Enterprise Edition から Standard Edition への使用例
多くの場合、RAC ライセンスによってデータベースの要件が Standard Edition（4 ソケット）から Enterprise Edition に引き上げられることになります。これは、RAC クラスタ内にノードの障害を サポートするためのリザーブ容量を保持する必要があるからです。RAC 要件を排除することで、 各マシンが別個に評価されるため、4 ソケットまたはそれ以下の単一サーバで多数の
EMC IT の Oracle 仮想導入モデルについて学習したレッスン
このセクションでは、この移行からOracle 仮想導入モデルに関することまで、Oracle に ついて学習したレッスンの重要な点をいくつか示します。 EMC IT は、これらの新しいテクノロジーを本番環境にプロモートする前に、EMC IT の実習で広範 なテストを実行しました。 この実習で、EMC IT は、EMC の理論、他のベスト・プラクティス、一般的なチューニングの機会を、 EMC の本番環境への導入前にすべてテストできます。EMC のテスト環境の中に、EMC IT の 8 TB の Oracle eBusiness Suite アプリケーションの本番コ ピーがあります。
このインスタンスはEMC の本番環境のコピーです。EMC IT は、ここでさまざまな vSphere のリ リース、さまざまなディスク・レイアウトとクローン作成の技術をテストし、無数のパフォーマンス・ チューニング・テストを行いました。
実習で学習し、その後でEMC の本番データベースでテストしたレッスンに基づき、EMC IT はいく つかのVMware vSphere の Oracle データベース用ベスト・プラクティスをまとめました。これらの ベスト・プラクティスの多くは、他のタイプのVM、他のデータベースにも活用できますが、以降で は、特にOracle データベースに関する、Oracle データベースに対してテストされた内容を説明し ます。
NUMA と Oracle データベース
Oracle Database 11g 以前では、NUMA をサポートするシステム上のメモリに対してローカル・ アクセスを利用しようとしていました。ただし、この実装は効率的ではなく、パフォーマンスは低 いことが多く、改善されませんでした。Linux では、デフォルト実装が NUMA 共有ライブラリに 正しくリンクしないので、NUMA の「最適化」は実際には機能しません。実習のテストでは、 NUMA を有効にした場合にパフォーマンスが低下するか、最善の結果でも変化が見られない ことが確認されました。Oracle NUMA が使用されないように設定するには、 _enable_NUMA_optimization=FALSE と_db_block_numa=1 を指定して明示的に無効にする 必要があります。 また、オペレーティング・システムをNUMA 対応にすることもできます。その場合、プロセスが 使用するメモリが保持されているソケット上のCPU に対して、OS がそのプロセスをスケジュー ル設定しようとします。データベース・プロセスの場合、必要とされているメモリと同じソケット 上のプロセスをOS が正常にスケジュール設定できないこともありますが、その際は即座に失 敗となり、データベース・プロセスはローカル・メモリにランダムにアクセスします。
OS を NUMA 対応にし、ローカルの NUMA ノード・メモリでプロセスをスケジュール設定するに は、ハードウェアBIOS で NUMA を有効にする必要があります。これは、ほとんどのシステム でデフォルトになっています。Linux では、コマンド numactl — hardware により NUMA ノードの 数と距離が表示されます。numactl — hardware の結果で、ノードが 1 個のみ表示された場合、 NUMA は有効になっていません。
プロセスがローカル・メモリにアクセスする機会を増やすために、データベースVM で使用する ソケット数を可能な限り少なくする必要があります。
たとえば、データベースVM が 20 個の vCPU を使用率 40%で使用し、Intel Nehalem ベース のESX サーバ（ソケットあたり 8 コア、4 ソケット）で動作しているとします。20 個の vCPU を使 用することにより、VM は 3 個のソケットに分散されます。16 個の vCPU でデータベースを実 行すると、使用するソケットを2 個に減らすことができます。ローカル・メモリへのアクセスの機 会が増えると、メモリにアクセスするスレッドの完了までの時間が大幅に高速化され（EMC の テストでは約20%）、CPU 要件全体が軽減されます。 vSphere 5.0 では、numa.vcpu.preferHT=TRUE パラメータを設定することにより、ローカル・メ モリにVM がアクセスする可能性に影響を与える機能を大幅に向上させることができます。こ れは.vmx ファイルで設定します。コアとそれに関連づけられたハイパースレッドの両方を使用 することにより、できる限り少ないソケット数でvCPU をスケジュールを設定するように、 vSphere に指示できます。パラメータの指定どおり、VM は、できる限り多くの物理コアを分散 させるよりも、ハイパースレッドの使用を優先します。前の例では、16 個の vCPU VM 全体を 1 個のソケットに含め、すべてのメモリ・アクセスがローカルになっています。 メモリ・アクセス vSphere 内の仮想メモリは、実際に使用される場合のみ VM に提供されます。メモリを必要と している他のVM に、未使用のメモリを割り当てることができる、非常に優れた機能です。 Oracle データベースの不利な点は、init.ora パラメータ PRE_PAGE_SGA=YES を設定しない限 り、データベースのすべてのメモリが起動時に割り当てられないことです。そのため、データ ベースのメモリ使用率の増加に応じて、DRS（Distributed Resource Scheduler）で VM を移動 する必要がある場合があります。最悪の場合、メモリ・リソースの制限が非常に厳しいと、 Oracle SGA メモリの一部がディスクにスワップされる可能性があります。 これを回避するには、データベースVM のメモリ予約に、データベースが通常の使用時に使 用する SGA、PGA、カーネルの合計サイズを設定します。通常と異なる負荷に対応するために、 より大きいサイズをVM に設定することもできます。メモリがデータベース VM に提供されるの は、必要な場合のみです。予約したメモリの量は、ESX サーバでその VM 用に確保されます。
Linux のヒュージ・ページ データベースで使用されるメモリをVMに効率的に割り当てるには、ヒュージ・ページを使用す る方法もあります。ヒュージ・ページの場合、Linux VMサーバは、起動時に実際にそのメモリ をVMに割り当てます。データベースのウォームアップ中に割り当てる必要はありません。 Oracleデータベースにヒュージ・ページを使用すると、ほかにも多くのメリットが得られます。そ れらについては、他のホワイト・ペーパーで詳細に説明しています。（EMC ITのホワイト・ペー パー「EMC IT's "On-Ramp" to the Journey to the Private Cloud」を参照してください。）
透過的ページ 透過的ページ共有も、VMware vSphere に固有の機能であり、各 VM のメモリ使用を非常に 効率的に最小化できます。基本的に、ESX サーバは、複数の VM が同じメモリ・ページを使用 していることを認識でき、両方のVM をマッピングして同じ物理メモリを使用することができま す。これにより、各VM の実際のメモリ消費が大幅に削減されます。データベースと他のいく つかのワークロードでは、実際にメモリが頻繁に変化する場合、パフォーマンスが低下する可 能性があります。バッファ・キャッシュなどのOracle メモリ領域の場合も同様です。 動的な結合 動的な結合は、vSphere がネットワーク使用率を向上させる目的で、ネットワーク・パケットを 転送先に送る前に非常に短い間、待機する機能です。一般的に、これはネットワーク・トラ フィックを軽減する優れた機能で、レーテンシーも削減できます。Oracle RAC の場合、この機 能は適していません。RAC データベースは特に相互接続レーテンシーの影響を受けやすく、 通常、ネットワークは分離され、結合のメリットを得られません。この場合、相互接続ネット ワーク・カードに対して、この機能を無効にする必要があります。そのためには、VMs .vmx ファイルで、EthernetX.coalesceScheme = ‘disabled’を設定します。 レーテンシー このレーテンシーをさらに削減するには、ネットワーク・アダプタのVM ネットワーク・アダプタ 設定で、割り込み速度を30K に設定します。これにより、実行する作業の有無を確認するた めのネットワーク・カードへのポーリング回数が、大幅に増大します。CPU 消費がわずかに増 えますが、オーバーヘッドがあってもパフォーマンス向上のために実施する価値はあります。 BIOS 設定 ハードウェアのBIOS 内の 2 つの追加のベスト・プラクティスは次のとおりです。 • BIOS の省電力の無効化 • ハイパースレッディングの有効化 • プロセッサとメモリの仮想化による負荷軽減の有効化
結論
このペーパーでは、データセンターでいつ、何を導入するかという設問に対して、EMC IT による 「Oracle 仮想導入フレームワーク」へのアプローチについて説明しました。このアプローチは、可 用性（99.9～99.999%）と拡張性（1 個～N 個の CPU）という 2 種類の主要なビジネス・サービス・ レベルに基づき、EMC IT の仮想導入モデルを使用して回答しています。 EMC では、これらの仮想導入モデルを使用し、ミッション・クリティカルなアプリケーションを導入し ます。 仮想導入モデルのメリットは次のとおりです。 • モデル A：VMware のみのソリューション：統合レベルの向上（物理サーバから仮想サーバ へ）、CAPEX と OPEX の削減、俊敏性の向上、数か月かかっていた Oracle の導入が数分 で完了• モデル B：Clusterware を使用した VMware：Oracle RAC モデルからの脱却、大幅な CAPEX の削減（Oracle RAC が不要）と OPEX の削減（Oracle データベース管理の合理化）
• モデル C：RAC を使用した VMware の可用性：高密度の統合、CAPEX/OPEX の削減 • モデル D：RAC を使用した VMware の拡張性：リソース使用率の向上、ハードウェアに依 存しない EMC IT の Oracle 仮想導入モデルには、仮想データセンターへの適切な移行に使用できる、学習 したレッスンと重要な情報が記録されています。次のトピックが含まれています。 • NUMA と Oracle • メモリ・アクセス • Linux のヒュージ・ページ • 透過的ページ • 動的な結合 • レーテンシー • ハードウェアの設定
参考資料
EMC IT：http://japan.emc.com/microsites/emc-it-proven/index.htm VMware 向けの EMC ソリューション：
http://japan.emc.com/solutions/application-environment/vmware/index.htm VCE Vblock：http://vce.com/
VMware：http://www.vmware.com/solutions/partners/alliances/oracle.html VMware Oracle導入のヒント：
http://www.vmware.com/files/pdf/Oracle_Databases_on_vSphere_Deployment_Tips.pdf
このホワイト・ペーパーの作成に対するEMC IT チームの支援に感謝いたします。 謝辞
