emc xtremio high-performance consolidation … · ホワイトペーパー. emc xtremio...

ホワイトペーパー

EMC XTREMIO HIGH-PERFORMANCE CONSOLIDATION SOLUTION FOR ORACLE EMC XtremIO、VMware vSphere、Oracle Database、Oracle RAC

• OLTP およびスループットの高い OLAP/DW ワークロード向けにスト

レージサービスの速度を最適化

• データベースインスタンスを仮想化および統合して優れたパフォー

マンスを実現

• コピー数を削減し、開発/テスト環境を合理化して IT の効率性を向上

EMC ソリューション

要約

このホワイトペーパーでは、EMC® XtremIO™オールフラッシュアレイに

VMware vSphere を導入して仮想化した Oracle Database のパフォーマンスお

よび運用面でのメリットを紹介します。また、Oracle Database 環境の統合およ

び仮想化をソリューションで強化する方法についても説明します。

2014 年 7 月

EMC XtremIO High Performance Consolidation Solution for Oracle EMC XtremIO、VMware vSphere、Oracle Database、Oracle RAC

2

Copyright © 2014 EMC Corporation. All rights reserved.（不許複製・禁無断転載）

2014 年 7 月発行

EMC Corporation は、この資料に記載される情報が、発行日時点で正確であ

るとみなしています。また情報は予告なく変更されることがあります。

この資料に記載される情報は、現状有姿の条件で提供されています。EMC Corporation は、この資料に記載される情報に関する、どのような内容につい

ても表明保証条項を設けず、特に、商品性や特定の目的に対する適応性に

対する黙示の保証はいたしません。

この資料に記載される、いかなる EMC ソフトウェアの使用、複製、頒布も、当

該ソフトウェアライセンスが必要です。

EMC2、EMC、および EMC ロゴは、EMC Corporation の登録商標または商標で

す。その他のすべての名称ならびに製品についての商標は、それぞれの所

有者の商標または登録商標です。

最新の EMC 製品名については、EMC の Web サイトで EMC Corporation の商

標を参照してください。

本書に記載されているすべての商標は、それぞれの所有者に帰属します。

パーツ番号 H12117.1-J

3 EMC XtremIO High Performance Consolidation Solution for Oracle EMC XtremIO、VMware vSphere、Oracle Database、Oracle RAC

目次

エグゼクティブサマリー .................................................................................................................. 6

ビジネスケース ................................................................................................................................ 6

ソリューションの概要 ........................................................................................................................ 6

主要な成果 ...................................................................................................................................... 7

はじめに ............................................................................................................................................ 8

目的 ................................................................................................................................................. 8

対象範囲 ......................................................................................................................................... 8

対象読者 ......................................................................................................................................... 8

技術概要 ............................................................................................................................................ 9

概要 ................................................................................................................................................. 9

EMC XtremIO .................................................................................................................................... 9

XtremIO の主要な機能は次のとおりです。 ................................................................................. 11

拡張性の高いパフォーマンス ..................................................................................................... 11

高可用性 ................................................................................................................................... 11

インラインデータ削減 ................................................................................................................ 11

XtremIO スナップショット ............................................................................................................. 11

VMware VAAI サポート ............................................................................................................... 12

VMware vSphere ............................................................................................................................ 13

VMware vCenter ............................................................................................................................. 13

EMC PowerPath/VE ........................................................................................................................ 13

Oracle Database 11g Enterprise Edition ......................................................................................... 13

Oracle RAC 11g R2 ......................................................................................................................... 13

Oracle ASM ............................................................................................................................... 13

Oracle Clusterware .................................................................................................................... 14

ソリューションのアーキテクチャ .................................................................................................. 15

概要 ............................................................................................................................................... 15

アーキテクチャ図 ............................................................................................................................ 15

ハードウェアリソース ..................................................................................................................... 16

ソフトウェアリソース ....................................................................................................................... 16

ストレージレイヤー：EMC XtremIO ............................................................................................... 17

クラスター設計 ............................................................................................................................... 17

インラインデータ削減 ..................................................................................................................... 17

シンプロビジョニング ...................................................................................................................... 18

障害保護 ....................................................................................................................................... 18

拡張性 ........................................................................................................................................... 18


4

メモリ内メタデータ動作 ................................................................................................................... 18

XtremIO Management Server .......................................................................................................... 19

ストレージ構成 ............................................................................................................................... 19

ストレージ設計 ............................................................................................................................... 20

LUN のプロビジョニング .................................................................................................................. 21

ネットワークレイヤー .................................................................................................................... 24

概要 ............................................................................................................................................... 24

SAN のベストプラクティス ............................................................................................................... 24

IP ネットワークのベストプラクティス ................................................................................................ 24

vSphere ネットワークのベストプラクティス ...................................................................................... 24

コンピューティングレイヤー ......................................................................................................... 26

概要 ............................................................................................................................................... 26

コンピューティングリソースとストレージリソース ............................................................................. 26

仮想化 ........................................................................................................................................... 27

ネットワーク仮想化 .................................................................................................................... 27

仮想マシンのテンプレート構成 ................................................................................................... 27

ストレージデバイスへのアクセスの有効化................................................................................. 28

Oracle データベース ........................................................................................................................ 30

概要 ............................................................................................................................................... 30

OLTP データベースストレージの設計 .............................................................................................. 30

OLTP データベースの Oracle ASM ディスクグループレイアウト ....................................................... 30

OLTP データベースとワークロードのプロファイル ............................................................................. 31

DW データベース用の ASM ディスクグループの構成 ...................................................................... 31

DW データベースとワークロードのプロファイル ............................................................................... 31

パフォーマンステストと検証 ......................................................................................................... 33

概要 ............................................................................................................................................... 33

結果に関する注 ............................................................................................................................. 33

テストの目的 .................................................................................................................................. 33

テストシナリオ ............................................................................................................................... 34

SLOB ランダムシングルブロック読み取り/書き込みワークロードテスト .......................................... 34

クエリー100%の OLTP テスト：SLOB ランダムシングルブロッククエリー専用テスト ..................... 34

更新 100%の OLTP テスト：SLOB ランダムシングルブロック読み取り/書き込みテスト ................ 36

クエリー/更新の割合が 75%/25%の OLTP テスト：SLOB ランダムシングルブロックテスト ......... 39

DW クエリーワークロードテスト ...................................................................................................... 41

テスト方法論 ............................................................................................................................. 42

テストプロシージャ .................................................................................................................... 42

テスト結果 ................................................................................................................................. 42


DW データ読み込みテスト ............................................................................................................... 42

テスト方法論 ............................................................................................................................. 42

テストプロシージャ .................................................................................................................... 43

テスト結果 ................................................................................................................................. 43

結論 ................................................................................................................................................. 44

サマリー ......................................................................................................................................... 44

評価結果 ....................................................................................................................................... 44

参考資料 .......................................................................................................................................... 45

ホワイトペーパー ........................................................................................................................... 45

VMware ドキュメント ........................................................................................................................ 45

Oracle ドキュメント .......................................................................................................................... 45

その他のドキュメント ...................................................................................................................... 45


6

エグゼクティブサマリー

ビジネスニーズにより、データの収集は容量の点でも速度の点でも厳しさを増して

います。同時に、このデータを速やかに情報に変えて、オポチュニティとリスクに対

する洞察力を得たいという要求も増しています。

ビジネスクリティカルなアプリケーションのサポートには Oracle Database 11g など

のデータベースが使用されています。そのような種類のアプリケーション全般でレス

ポンスタイムを短縮するために、これらのデータベースでは、低レーテンシーのトラ

ンザクション I/O と高スループットの分析ワークロードの両方を実現するよう設計さ

れたストレージが求められています。

仮想化を利用すれば、各種データベースワークロードの統合性が向上します。一般

に、統合により、OLTP（オンライントランザクション処理）と OLAP（オンライン分析処

理）の両方が同じサーバーとストレージを共有できるようになります。そのため、最

適なパフォーマンスを確保するには、統合インフラストラクチャでさまざまなワーク

ロードを処理するように、基盤となるストレージインフラストラクチャを設計することも

必要です。

EMC® XtremIO™オールフラッシュアレイは、優れたランダム I/O パフォーマンスと

一貫して極めて低いレーテンシーにより、I/O の多いデータベースワークロードで仮

想化の効果を有効に発揮します。このことは、OLTP と OLAP のワークロードはもちろ

ん、共通ストレージプラットフォーム上での複数のワークロードの統合でも同じです。

また、XtremIO は、VAAI（VMware vStorage APIs for Array Integration）によって領域

の使用効率に優れたスナップショット、インラインコピー重複排除、シンプロビジョニ

ング、高速プロビジョニングを実現することで、仮想化環境に新たなレベルのスピー

ドとプロビジョニングの俊敏性ももたらします。結果的に、ストレージとデータベース

のライセンス数を削減し、ストレージの管理とプロビジョニングを大幅に簡素化でき

る上、リアルタイムの分析および開発/テストサイクル向けの新しい機能を利用でき

るようになります。

データベースサーバーの仮想化は、データベース統合の戦略として実績があるも

のの、特有の問題が生じることもあります。複数のアプリケーションの統合に利用す

る物理ホストの数が少ないと、仮想マシンは HBA（ホストバスアダプター）などの物

理リソースを共有するため、I/O ワークロードがバックエンドストレージに対し非常に

ランダムになる可能性があります。XtremIO オールフラッシュストレージアレイは、

データベースあたりのコストを最小限に抑えながら、常に非常に高いランダムな I/Oパフォーマンスが求められる、こうした要件の厳しい仮想化環境でパフォーマンスを

発揮するように構築されています。

このソリューションでは、XtremIO ストレージを使用して VMware vSphere に Oracle Database 11g を導入する場合のメリットを紹介します。

このソリューションのメリットは次のとおりです。

• 仮想化された Oracle データベースとその他のアプリケーションを同じ物理ホ

ストとストレージ上で統合

• アプリケーション SLA（サービスレベル契約）を満たす一貫性のあるパ

フォーマンスとアップタイムを提供

ビジネスケース

ソリューションの概要


• XtremIO で使いやすさと拡張計画の合理化を実現

• 本番コピー、テスト/開発用コピーをすべて含めたデータベース環境全体の

ストレージ占有領域を最適化

このソリューションで、XtremIO によってもたらされるメリットは次のとおりです。

• ストレージ調整がほとんど（またはまったく）必要なく、セットアップが短時間

で簡単に完了

• 同時に複数のユーザーが利用する大規模なデータウェアハウスでラージブロックのランダム I/O と広帯域幅を提供

• OLTP ワークロードの拡張に合わせて IOPS を増加させる一方で、常に低い

レーテンシーを維持

• 高いランダム I/O により、統合化された仮想化データベース環境で安定した

パフォーマンスを確保

• XtremIO のインライン重複排除機能を使用することでストレージ占有領域を

大幅に削減

• Oracle RAC（Real Application Cluster）、VMware vSphere HA（High Availability）など、高可用性のクラスターシステムでフォールトトレランス/保護を向上

主要な成果


8

はじめに

このホワイトペーパーでは、XtremIO ストレージを使用して Oracle Database 11g を

仮想化された vSphere 環境に導入する場合の可用性が高く拡張性に優れたソ

リューションについて説明します。

このホワイトペーパーの範囲は次のとおりです。

• ソリューションを実現する主要なテクノロジーの紹介

• ソリューションのアーキテクチャと設計の説明

• 主要なコンポーネントとプロセスの説明と妥当性検査

• このソリューションのビジネス上の主なメリットの説明

このホワイトペーパーは、Oracle Database やインフラストラクチャ、データセンター

の設計、構築、管理を担当する Oracle DBA（データベース管理者）、VMware 管理者、

ストレージ管理者、IT アーキテクト、テクニカルマネージャーを対象としています。

目的

対象範囲

対象読者


技術概要

このソリューションで使用されている主要なテクノロジーコンポーネントは次のとおり

です。

• EMC XtremIO（VAAI 対応）

• VMware vSphere

• VMware vCenter

• EMC PowerPath®/VE

• Oracle Database 11g R2 Enterprise Edition

• Oracle RAC 11g R2

EMC XtremIO ストレージアレイは、スケールアウトアーキテクチャに基づいた、オー

ルフラッシュシステムです。システムは、X-Brick と呼ばれるビルディングブロックを

使用します。これをクラスター化することで、必要に応じてパフォーマンスや容量を

増やすことができます。このソリューションでは、2 台の X-Brick を使用しています。

XtremIO を利用することで主に次の点が向上します。

• パフォーマンス：システムの混雑状況やストレージ容量の使用状況にかか

わらず、レーテンシーとスループットを一貫した、予測可能な、一定した状態

に保ちます。アレイ内の I/O 要求に関するレーテンシーは、通常 1 ms（ミリ秒）よりはるかに少なくなります。図 1 に、パフォーマンスの監視に使用する

XtremIO ダッシュボードの例を示します。

図1. XtremIO ストレージ管理アプリケーションのダッシュボード

• 拡張性：XtremIO ストレージシステムは、スケールアウトアーキテクチャに

基づいています。X-Brick は初期設定では 1 台で、パフォーマンスや容量の

追加の必要に応じて、X-Brick を追加してスケールアウトします。パフォーマ

概要

EMC XtremIO


10

ンスは直線的に拡張するので、単一の X-Brick 構成に比べて、X-Brick が 2台あれば 2 倍の IOPS が、X-Brick が 4 台あれば 4 倍の IOPS が実現します。

システムをスケールアウトしても、常に低いレーテンシーが保たれます。図 2に示すように、XtremIO アレイは、必要なレベルのパフォーマンスや容量に

スケールアウトできます。

図2. X-Brick の増加

• データ保護：XtremIO は独自のフラッシュ最適化データ保護アルゴリズム、

XDP（XtremIO のデータ保護）を使用しています。これにより、あらゆる既存

の RAID アルゴリズムを上回るパフォーマンスを実現しながらデータの保護

を実現します。また、XDP の最適化によって、データ保護目的でのフラッシュメディアへの書き込みも減ります。

• データ管理：XtremIO では、高パフォーマンス、領域の使用効率に優れたス

ナップショット、インラインデータ削減、シンプロビジョニング、完全な

VMware vSphere VAAI をサポートするほか、FC（ファイバーチャネル）と

iSCSI プロトコルもサポートします。

• シンプルさ：ストレージプロビジョニングは、LUN のサイズを指定するだけで

簡単に実行できます。RAID グループを作成したり、LUN を作成する具体的

な SSD を選択したり、シンプロビジョニングを有効/無効にしたり、重複排除

を有効/無効にしたりする必要はありません。詳細については、「LUN のプロ

ビジョニング」のセクションを参照してください。

• 本質的にバランスの取れたアーキテクチャ：XtremIO はスケールアウト型設

計を採用しています。つまり、複数のコントローラーを利用することでアレイ

内の容量の増加に応じて直線的にパフォーマンスを向上させることができま

す。XtremIO の基本的な設計目標の 1 つが「バランスの取れたアーキテク

チャを維持する」ことです。このためには、アレイがすべてのリソースを常に

均等に利用する必要があります。XtremIO は、アレイのワークロードをコント

ローラーすべてに分散させてホットスポット（負荷の高い部分）やバックエン

ドの再配分処理を回避することでこれを実現しています。


XtremIO の主要な機能は次のとおりです。

拡張性の高いパフォーマンス

XtremIO は、新しいアプリケーションだけでなく、すでに導入されているアプリケー

ションについても、将来的なパフォーマンスや容量のニーズに対応するためスケー

ルアウトできるよう設計されています。XtremIO のアーキテクチャでは、管理の一元

化を維持しシステム全体でリソースのバランスを取りながら、ビルディングブロック

（X-Brick）を追加することでパフォーマンスの向上や容量の増加に対応できます。

高可用性

複数の障害が発生してもデータの消失を防ぎサービスを維持できることは、XtremIOのアーキテクチャのコアとなる機能の 1 つです。ハードウェアの観点から言うと、単

一障害点となるコンポーネントは存在しません。各 X-Brick はデュアル電源を搭載し

ています。また、システムもデュアルバッテリバックアップユニットと、デュアルネッ

トワークおよびデータポートを搭載しています。電力入力ラインやさまざまなデータパスは常時監視され、何らかの障害が生じた場合には、リカバリまたはフェイル

オーバーが試行されます。

ソフトウェアアーキテクチャも同様の方法で構築されています。SSD にコミットされて

いないすべての情報は、ジャーナルと呼ばれる複数のロケーションに格納されます。

それぞれのソフトウェアモジュールは、ストレージコントローラーとは別の場所に独

自のジャーナルを持っているため、不測の障害が起きた場合にも、これを使用して

データを復元できます。

インラインデータ削減

XtremIO はデータがシステムに到達したとき、自動的かつ全体的に、データの重複

排除を行います。これはフラッシュに書き込まれるデータの量を削減するため、メ

ディアの寿命を延ばすとともに、コストの削減に役立ちます。データ削減は後処理で

はなく、リアルタイムで実行されます。つまり、XtremIO ではリソースを消費するバッ

クグラウンドプロセスや後処理の重複排除に関連する追加の読み取り/書き込みが

ありません。そのため、パフォーマンスを向上させ、ホスト I/O に割り振られた利用

可能なリソースを効率よく利用し、フラッシュの耐久性を強化することができます。

XtremIO スナップショット

XtremIO のスナップショットは、XtremIO のアレイアーキテクチャに密接に統合され

ます。XtremIO のスナップショットの実装は完全にメタデータ中心で行われ、アレイの

データ削減機能を活用するため、データがアレイ内にコピーされることはありません。

XtremIO のスナップショットでは、メモリ内メタデータとデュアルステージメタデータだ

けでなく、効率的なデータ構造というもう 1 つのメリットも有効に活用することで、ス

ナップショットのツリーのスパンや深さにかかわらず、読み取りと書き込みの両方で、

本番ボリュームと同じパフォーマンスを提供するスナップショットを短時間で作成す

ることができます。

XtremIO のスナップショットが役立つデータベースの用途は次のとおりです。

• データベースバックアップ – データベース LUN のスナップショットを作成し、

そのスナップショットを専用のバックアップサーバーにマウントすることで、

本番サーバーをバックアップ操作から解放し、リソースをビジネス処理に効

率よく使用することができます。


12

• 論理データの破損に対する保護 – 複数のスナップショットを短い間隔で作成

することで、論理データをこれらのスナップショットからリカバリすることがで

きます。スナップショットを作成しておけば、一意のゼロ以外のデータがこれ

らのスナップショットに書き込まれない限り、フラッシュやメタデータを無駄に

消費することがありません。これにより、ユーザーは、より高い頻繁で、より

効率よく、スナップショットを作成できます。

• テスト/開発環境の高速プロビジョニング – 本番データベース LUN のスナッ

プショットを作成してテスト/開発サーバーにマウントすれば、テスト/開発用

やその他の目的用の本番データベースのまったく同じコピーを短時間でプロ

ビジョニングできます。

• オフロード処理 - ETL（抽出、変換、ロード）、リアルタイムに近い分析など、

データウェアハウス関連の操作でも、データベース LUN のスナップショット

を作成して本番以外のサーバーにマウントする処理は役立ちます。XtremIOのスナップショットがあれば、本番データの最新のコピーにすぐにアクセスで

きます。

注：このソリューションは Oracle データベース用に設計されたものですが、スナップ

ショット機能は、Oracle 以外のデータベースやデータベース以外のアプリケーションに

も同じように役立ちます。

VMware VAAI サポート

XtremIO は、仮想マシンのプロビジョニングとクローン作成、VMDK（仮想マシンディ

スク）のプロビジョニング、大規模な仮想環境の導入向けの vSphere VAAI を介して

vSphere に完全に統合されています。XtremIO は、VMDK レベルで、どのストレージプロビジョニングを選択しても、高パフォーマンス、低レーテンシーのレスポンスタイ

ム、短時間のプロビジョニングを実現します。XtremIO は VAAI の block-zero プリミ

ティブをサポートしており、仮想ディスクの EZT（eager-zero-thick）ボリュームをプロビ

ジョニングする場合にパフォーマンスが低下しないようブロックにゼロを書き込みま

す。block-zero プリミティブだけでなく、XtremIO は、XCOPY、ATS、UNMAP、シンプロ

ビジョニングなど、VAAI のその他のプリミティブもサポートしています。その結果、

XtremIO システムは一般的な VMware ストレージ管理タスクの負荷を軽減し、データ

センターにこれまでにないほどの俊敏性をもたらします。

• 任意のサイズの VMFS ボリュームを構成して、短時間でフォーマット。

• 大容量のデータストアを活用して、管理を合理化。

• 新しいデータストアを迅速に作成。

• 仮想マシンと vApp のクローンを瞬時に作成し、数百もの新しい仮想マシン

を分単位で大量に導入。

こうした機能をサポートしているのは XtremIO だけです。これは、インライン重複排

除、メモリ内メタデータ、VAAI サポートの強力な組み合わせによるものです。

• XtremIO の機能の詳細については、ホワイトペーパー「EMC XtremIO ストレージアレイの概要」を参照してください。


仮想化レイヤーにより、基盤となる物理リソースからアプリケーションが切り離され

ます。これにより、保守のためのハードウェアダウンタイムをなくすことでアプリケー

ションレイヤーの柔軟性を高め、ホストしているアプリケーションに影響を与えること

なく物理システムを変更できます。サーバー仮想化のユースケースでは、このレイ

ヤーを使用することで、複数の独立した仮想マシンが同じ物理ハードウェアを共有

できるようになります。

VMware vSphere は完成度の高い優れた仮想化プラットフォームであり、動的なリ

ソースプールを使用してビジネスクリティカルなアプリケーションを仮想化すること

で、従来にない柔軟性と信頼性を実現します。CPU、RAM、ハードディスク、ネット

ワークコントローラーを仮想化することで、コンピューターの物理リソースを変換しま

す。この変換により、独立しカプセル化されたオペレーティングシステムとアプリ

ケーションを実行する、高い機能性を備えた仮想マシンが実現します。

VMware vCenter は、VMware 仮想インフラストラクチャのための一元管理システム

です。このシステムにより、仮想インフラストラクチャの監視、管理、維持のすべての

側面に対応する、複数のデバイスからアクセス可能な、単一のインターフェイスが提

供されます。

また、vCenter では、vSphere HA、VMware vSphere DRS（分散リソーススケジュー

ラ）、VMware vMotion、VMware Update Manager など、VMware 仮想インフラストラ

クチャの一部の高度な機能も管理できます。

EMC PowerPath/VE（Virtual Edition）for vSphere には、vSphere 仮想環境を最適化

するマルチパス機能があります。PowerPath/VE は、カーネルモジュールとして

VMware ESXi ホスト上にインストールされ、ESXi ホストに強力なパス管理機能とロー

ドバランシング機能を提供する MPP（マルチパスプラグイン）として機能します。

Oracle Database 11g Enterprise Edition は、パフォーマンス、拡張性、セキュリティ、

信頼性を提供するだけでなく、クラスターサーバーまたは単一サーバーのどちらで

Windows、Linux、UNIX のいずれを実行環境にするかも選択できます。Oracle Database 11g Enterprise Edition は、Oracle Database 11g R2 Standard Edition で

は利用できない高度な機能（付属機能および有償オプション）をサポートします。こ

れには、仮想プライベートデータベースなどのセキュリティ機能と、パーティショニン

グや高度な分析などのデータウェアハウジングオプションが含まれます。

Oracle RAC 11g R2 では、Oracle グリッドインストラクチャにより、Oracle ASM（Automatic Storage Management）と Oracle Clusterware が 1 つのバイナリセットに

統合され、データベースソフトウェアから切り離されています。このインフラストラク

チャにより、Oracle RAC 対応データベースの運用に必要なクラスターサービスとスト

レージサービスをすべて利用できるようになりました。

Oracle ASM

Oracle ASM は、統合されたクラスター対応データベースファイルシステムおよび

ディスクマネージャーです。ASM のファイルシステムとボリューム管理機能は、

Oracle データベースカーネルに統合されています。Oracle RAC 11g R2 では、ASMも拡張され、OCR（Oracle Cluster Registry）のサポートと、ASM ディスクグループに

配置する投票ファイルのサポートが追加されています。

VMware vSphere

VMware vCenter

EMC PowerPath/VE

Oracle Database 11g Enterprise Edition

Oracle RAC 11g R2


14

Oracle Clusterware

Oracle Clusterware は、Oracle データベースに統合された移植性の高いクラスター

管理ソリューションです。クラスター管理サービスや高可用性サービスなど、Oracle RAC の実行に必要なインフラストラクチャを提供します。また、Oracle Clusterware を

使用してクラスター環境で Oracle 以外のアプリケーションの可用性を高めることもで

きます。


ソリューションのアーキテクチャ

このセクションでは、ソリューションのアーキテクチャについて説明します。

このソリューションは、Oracle のミッションクリティカルなアプリケーション環境に最適

なコストパフォーマンスを提供します。Oracle Database は、仮想化された 4 ノード

の RAC データベースとして、2 台の XtremIO X-Brick からなる XtremIO ストレージアレイに導入されます。

図 3 に、ソリューションのレイアウトを示します。

図3. ソリューションのアーキテクチャ

アーキテクチャは次のレイヤーで構成されます。

• コンピューティングレイヤー：合計 32 コアと 2.9 GHz のプロセッサおよび合

計 2 TB の RAM を使用する 4 台のサーバーで構成されます。ラックマウントサーバーにより、Oracle インフラストラクチャに対して高パフォーマンスを実

現する統合型の仮想化アプローチが可能となり、アプリケーションを変更す

る必要なく導入時に柔軟に対応できます。

• ネットワークレイヤー：2 つのIPスイッチと 2 つのダイレクタークラスのSANスイッチで構成されます。ここでは 1、108 GB/秒のアクティブな帯域幅を創

出するよう構成しています。SANスイッチは、仮想化データセンターとエン

1 このホワイトペーパーの説明の中の操作は、ソリューションを検証した EMC ソリューションエンジニアリングチームが行ったものです。

概要

アーキテクチャ図


16

タープライズクラウドをサポートするストレージネットワークへの導入を想定

して設計されています。

• ストレージレイヤー：2 台の X-Brick アレイ（12U）と 14.94 TB の使用可能な

物理容量で構成されます。

サーバーは vSphere とともにインストールされ、VMware ESXi クラスターとして構成

されます。

この ESXi クラスター上には 4 台の仮想マシンが作成されます。このクラスターが 4ノードの Oracle RAC データベースの実行環境になります。パフォーマンスは、OLTPと DW（データウェアハウス）のワークロードを Oracle RAC データベースと切り離して

実行することで調査しました。

表 1 に、このソリューションで使用したハードウェアリソースを示します。

表1. ハードウェアリソース

ハードウェア個数構成

ストレージアレイ 1 XtremIO アレイ（2 台の X-Brick で構成）

サーバー 4 8 コア、2.9 GHz のプロセッサ、512 GB の RAM（以下を含む）：

• 1 GbE（Gb Ethernet）NIC（ネットワークインターフェイスカード）1 個

• 10 GbE NIC 1 個

LAN スイッチ 2 10 GbE

SAN スイッチ 2 FC

表 2 に、このソリューションで使用したソフトウェアリソースを示します。

表2. ソフトウェアリソース

ソフトウェアバージョン注

VMware vSphere 5.0 すべての仮想マシンをホストするハイ

パーバイザー

VMware vCenter 5.1 vSphere マネージャー

Red Hat Enterprise Linux 6.3 データベースサーバーのオペレーティン

グシステム

Oracle Database 11g Release 2 Enterprise Edition 11.2.0.3

データベース

Oracle Grid Infrastructure 11g Release 2

Enterprise Edition 11.2.0.3

ボリューム管理に Clusterware と ASM を

採用

SLOB（Silly Little Oracle Benchmark）

2 OLTP ベンチマークツール

XIOS 2.2 SP3 XtremIO オペレーティングシステム

ハードウェアリソース

ソフトウェアリソース


ストレージレイヤー：EMC XtremIO

EMC XtremIO はフラッシュ最適化スケールアウトクラスター設計をベースとし、容量

とパフォーマンスを直線的に拡張することでどのようなストレージ要件にも対応する

ことができます。X-Brick ごとに可用性が高く完全にアクティブ/アクティブのストレー

ジコントローラーがあるため、単一障害点はありません。既存のシステムに X-Brickを追加することもできます。X-Brick を追加することで、冗長性、高可用性が向上し、

ネットワークでの極めて低いレーテンシーを実現します。このようなシステムで、パ

フォーマンスを直線的に拡張する一方で、レーテンシーを常に低い状態に維持する

ことができます。

XIOS（XtremIO オペレーティングシステム）は、ストレージクラスターを管理するほか、

次のような機能を提供します。

• クラスター内の SSD（ソリッドステートドライブ）すべてを均等にロードするこ

とで、アレイの使用期間全体を通して、需要が高いワークロードに求められ

る可能な限り最高のパフォーマンスと耐久性が実現されます。

• 従来のアレイに使用していた複雑な構成ステップを実行する必要がありま

せん。RAID レベルの設定、ドライブグループサイズの決定、ストライプ幅の

設定、キャッシュポリシーの設定、集約のビルドなど、手動による構成を行

う必要がありません。

• 最適なボリュームを自動的に構成し、クラスターのスケールアウトに応じて

既存のボリュームやデータセットの I/O パフォーマンスを自動的に拡張する

ことができます。

XtremIO のオールフラッシュアレイはインラインデータ重複排除を実行します。この

ベースとなるのが、アレイに格納するデータブロックが既存のコンテンツと重ならな

いようチェックするアルゴリズムです。その結果、フラッシュストレージに書き込まれ

た一意のブロックのみを取り込むことで、すべてのストレージ I/O に対しリアルタイ

ムで重複排除が行われます。さらに、SSD I/O サイクルが重複ブロックの書き込み

や重複排除されていないデータの処理に使用されることがないため、XtremIO での

重複排除はパフォーマンスの向上にもつながります。これにより、ホストリクエストに

対応するために最大限の I/O 処理能力を保持できます。

アーカイブログモードに対応している場合は、オンライン REDO ログファイルが満

杯であると、アーカイバープロセスによってオンライン REDO ログファイルからアー

カイブログファイルの宛先に REDO データがコピーされます。アーカイブ処理が完

了するまで、ログライタープロセスは満杯になった REDO ログに書き込むことができ

ません。アーカイブログはオンライン REDO ログの正確なコピーなので、アレイは

バックエンド SSD に対して物理書き込み I/O を実行せず、代わりにメモリ内ポイン

ターに更新を送信するので、書き込み操作はすぐに完了します。

LGWR（ログライター）がアーカイブ対象のオンライン REDO ログファイルに新しい

REDO データを書き込むと、オンライン REDO ログファイルのメモリ内ポインターが更

新され、新たに書き込まれた REDO データが格納されている、新しく割り振られた物

理 REDO ブロックが参照されます。アーカイブされる REDO ログファイルのメモリ内

ポインターは変わりません。これは、アーカイブされる REDO ログファイルが使用す

る物理ログブロックがアーカイブログの保存先に存在する限り、そのログファイル

がサポートされることを意味します。

クラスター設計

インラインデータ削減


18

また、XtremIO は重複排除対応キャッシュ機能も提供します。これにより、キャッシュ

に格納されているブロックは、そのブロックへのどのような論理的な参照にも応える

ことができます。重複排除対応キャッシュ機能とインライン重複排除機能を組み合

わせることで、複数の仮想マシンを同時起動するなどの難しい状況への対応でレー

テンシーを大幅に短縮し、常にわずか数ミリ秒のデータアクセスを実現できます。

XtremIO は、高パフォーマンスを実現するだけでなく、シンプロビジョニング機能も提

供します。これにより、アプリケーションの必要に応じてオンデマンドで容量が割り

当てられるため、再利用後の操作は必要なく、アレイストレージの I/O パフォーマン

スに影響することもありません。また、XtremIO のシンプロビジョニングは細分性が

高く、容量がブロック単位で割り当てられるため、フラッシュ容量ストレージを無駄な

く使用できます。これは、vSphere が I/O ブロックサイズを使用する方法と整合して

います。

XtremIO は、完全な冗長コンポーネントにより信頼性と可用性を実現し、データを損

失することなく、どのようなコンポーネント障害にも耐えることができます。XtremIOには次の障害保護機能が搭載されています。

• コントローラーと DAE（ディスクアレイエンクロージャ）にデュアル電源を搭

載し、1 つの電源を失ってもコントローラー/DAE の稼働を確保

• 冗長なアクティブ/アクティブコントローラーでコントローラーの障害に対応

• DAE に冗長な SAS（シリアル接続 SCSI）相互接続モジュールを搭載

• 冗長なコントローラー間通信リンク

• 複数のホスト接続とマルチパス機能でパスの障害に対応

• XDP で複数の SSD 障害に対応

• 初期データと継続的なデータの整合性を確保するための各種技術

このフォールトトレラントな設計は、Oracle RAC 11g などの高可用性クラスターシス

テムの導入に最適です。

XtremIO ストレージクラスターは完全分散型のスケールアウト設計をサポートしてい

ます。この設計により、容量とパフォーマンスの両方を直線的に拡大でき、インフラ

ストラクチャの俊敏性が向上します。XtremIO ではビルディングブロック方式を使用

し、X-Brick を追加してアレイを拡張します。

XtremIO は N-way のアクティブ/アクティブコントローラーを使用してホストアクセス

を提供し、パフォーマンスと容量を直線的に拡張することで、拡大し続ける仮想化環

境を合理的にサポートします。その結果、アレイの容量の増加に応じて、ストレージコントローラーを追加することでパフォーマンスを向上させる一方、常に低いレーテ

ンシーを維持できます。

XtremIO クラスターでは、すべてのストレージコントローラー間でメタデータが均等に

分散され、実行時にはメタデータがメモリに保持されます。アレイが障害や電源損失

に耐えられるように、メタデータは SSD に書き込まれますが、通常運用中のメタデー

タの検索はすべてメモリで行われます。これは、メタデータテーブルをセグメント化し

てすべてのストレージコントローラー間で均等に分散させることによってのみ実現さ

れます。一方で、デュアルコントローラー設計には、メモリにすべてのデータを格納

シンプロビジョニング

障害保護

拡張性

メモリ内メタデータ動作


できるだけの十分な RAM がない可能性があるため、大容量のメタデータをフラッ

シュにデステージする必要があり、これにはパフォーマンスの低下を伴います。

XtremIO はメモリ内メタデータと一意のインライン重複排除モデルを組み合わせるこ

とで、これまでにない機能を仮想化データセンターにもたらします。

XMS（XtremIO Management Server）では、システムを制御および管理できます。

XMS の機能は次のとおりです。

• 新しいシステムの初期化とフォーマット

• システムの稼働状態とイベントのモニタリング

• システムパフォーマンスのモニタリング

• パフォーマンス統計履歴データベースの管理

• クライアントへの GUI サービスと CLI サービスの提供

• ボリューム管理およびデータ保護操作の実装

• システムの管理（停止、開始、リスタート）

XMS は、XSMA（XtremIO Storage Management Application）という使いやすい GUIとともにインストールされ、アクセスにはこの GUI が使用されます。X-Brick のスト

レージコントローラー上の管理ポートには TCP/IP を介して接続します。XMS が切断

されても、XtremIO クラスターからのストレージの提供には影響ありません。

XMS は、VMware HA クラスターをベースとするシステムの管理環境に仮想マシンと

して導入されます。つまり、XMS 仮想マシンは障害が発生しても速やかにリスタート

できます。仮想化されていない環境では、物理サーバーが XMS として機能すること

ができます。

このソリューションでは、XtremIO アレイを 2 台の X-Brick とともに導入します。X-Brick は、組み込みの冗長な 40 Gb/秒の QDR InfiniBand スイッチで相互接続され、

ストレージコントローラー間のバックエンド接続を提供します。これで、可用性が高く、

レーテンシーが極めて低いネットワークが実現されます。

このテストに含まれる XtremIO アレイには、XDP 構成の 400 GB の SSD が 50 台あ

り、物理容量は 14.94 TB です（図 4 を参照）。

XtremIO Management Server

ストレージ構成


20

図4. XtremIO GUI – ストレージパネル

Oracle Database 向けの従来のストレージ設計では、ドライブの種類が異なる複数

の RAID グループが作成され、それぞれ保護レベルが異なり、複数のコントローラー

間に分散されていました。

XtremIO では、ドライブはすべて XDP の保護対象となり、アレイ内のデータは X-Brick 間に自動的に分散されて、一貫したパフォーマンスと同等のフラッシュウェアレベルが確保されます。

通常、データベースでは、ランダム I/O とシーケンシャル I/O の 2 種類の I/O が発

生します。XtremIO では、これらを同等に扱い、データはランダム化され、アレイ全体

に均等に分散されます。

このソリューションでは、ボリュームサイズはデータの用途に応じて標準化されます

（表 3 を参照）。

表3. XtremIO X-Brick 上の Oracle ストレージ設計

ボリュームの用途サイズ

（GB）

データファイル用の Oracle ASM ディスク 700

REDO ログ用の Oracle ASM ディスク 40

Cluster Ready Service ファイル用の Oracle ASM ディスク

（Oracle Cluster Registry および投票ディスクファイル）

10

ファイルのデータロード向けの Oracle ACFS（Automatic Storage Management Cluster File System）用の Oracle ASM ディスク

200

ストレージ設計


OLTP データベースでは、ボリュームは、Oracle Database 11g で使用できるように

ESXi サーバーに対して作成され提供されています（表 4 を参照）。

表4. OLTP データベースのボリューム/LUN 割り当て

フォル

ダー名ボリュームサイズ（GB）

ボリュー

ムの数

ASM ディ

スクグループ

ASM ディスク

グループの冗

長性

イニシエーターグループの数

データ 700 8 +DATA 外部 4

ログ 40 4 +REDO 外部 4

CRS 10 2 +CRS 外部 4

XtremIO での LUN のプロビジョニングはシンプルで簡単です。XtremIO アレイ管理コ

ンソールで数回クリックするだけで LUN を作成しサーバーに提供することができま

す。次の手順で、LUN を作成しイニシエーターに割り当てる方法を説明します。

1. XtremIO アレイ管理コンソールで、［Configuration］タグに切り替え、［Add］をクリックし、ポップアップボックスに LUN の名前とサイズを指定して、［Next］をクリックします（図 5 を参照）。

図5. LUN の作成を初期化して LUN の名前とサイズを指定する

2. LUN の親フォルダーを選択して［Finish］をクリックします（図 6 を参照）。

LUN のプロビジョニング


22

図6. LUN のフォルダーを指定する

3. 新たに作成した LUN とイニシエーターグループを選択し、［Map All］をクリッ

クします（図 7 を参照）。

図7. LUN をイニシエーターグループに割り当てる

4. ［Apply］をクリックします。作成したすべての LUN がイニシエーターグルー

プに割り当てられます（図 8 を参照）。

図8. LUN 割り当て構成を適用する

5. 新たに作成した LUN をイニシエーターに割り当てたら、ESXi ホストのスト

レージアダプターを再スキャンして LUN が認識されるようにします。


図 9 に、Data フォルダー下でのボリューム Data11～Data18 のグループ分けを示し

ます。これらのボリュームには、OLTP データベースの ASM ディスクグループ+DATAが含まれています。このソリューションでは、1 つのイニシエーターグループは 1 つ

の物理サーバーとその FC ポートで構成されています。ボリューム Data11 は LUN と

して提供され、4 つのイニシエーターグループすべてに割り当てられます。

図9. XtremIO GUI ボリューム/LUN のサーバーへの割り当て

DW データベースでは、表 5 に示すようにボリュームが作成されてフォルダーに分類

されます。各ボリュームは LUN としてイニシエーターグループに示されます（図 9 を

参照）。

表5. DW データベースの ASM ディスクグループ設計

フォルダー名ボリュームサイズ

（GB）

ボリュー

ムの数

ASM ディ

スクグループ

ASM ディスクグループの

冗長性

イニシエー

ターグループ

の数

DWDATA 700 8 +DATA 外部 4

DWLog 40 4 +REDO 外部 4

DWCRS 10 2 +CRS 外部 4

DWACFS 200 1 +CSV 外部 4


24

ネットワークレイヤー

このセクションでは、このソリューションで SAN および IP のネットワーク構成と ESXiサーバーのネットワーク構成に使用する各ベストプラクティスについて説明します。

Oracle RAC などの仮想化クラスターソリューションを導入する場合、EMC では、

フォールトトレランスに適したネットワークを設定する際にコンピューティングとネット

ワークの両方の冗長性を検討することを推奨しています。

SAN では次のようなベストプラクティスを実装することを推奨します。

• ESXi サーバーの複数の HBA を 2 つの SAN スイッチと組み合わせて使用し

て、ホストと XtremIO クラスター間に複数のパスを設定する。

• データベースサーバーの各 FC ポートを XtremIO X-Brick のポートにゾーニ

ングして、高可用性と高パフォーマンスを実現する。

• 代替パスへのフェイルオーバー処理を有効化し、ロードバランシングを提供

するため、PowerPath/VE などのパス管理および動的マルチパスソフトウェ

アを、ホストで使用する。

• パス管理および動的マルチパスソフトウェアを使用しない場合は、ESXi ホス

トで、パス選択ポリシーをラウンドロビン方式とするアクティブ/アクティブの

マルチパスを構成することを推奨します。

IP ネットワークでは次のようなベストプラクティスを実装することを推奨します。

• ネットワークの冗長性を得るため、複数のネットワークカードとスイッチを使

用する。

• ネットワーク接続に 10 GbE を使用する（利用可能な場合）。

• VLAN（仮想ローカルエリアネットワーク）を使用して、さまざまなネットワークセグメントまたはサブネットワークに存在するデバイスを論理的にグループ

分けする。

• 10 GbEネットワークの物理スタックまたは仮想スタック全体でジャンボフレーム 2を有効化して構成する。

仮想環境と物理環境のネットワーキングで同じ概念を使用します。多くのベストプラ

クティスはどちらの環境にも当てはまりますが、仮想化の場合はトラフィックのセグメ

ント化、可用性、スループットについての追加の検討事項が適用されます。

このソリューションは、複数のネットワークと ESXi ホスト上のネットワークアダプター

の冗長性を効率的に管理するように設計されています。重要なベストプラクティス

のガイドラインは次のとおりです。

• セキュリティのために、インフラストラクチャトラフィックを仮想マシントラフィックから分離する。

• 準仮想化ネットワークアダプターの VMXNET3 ファミリーを使用する。

2 1,500 バイトを超える MTU（最大転送単位）サイズのことをジャンボフレームと呼びます。

ジャンボフレームは、サーバー、スイッチ、データベースサーバーを含む、ネットワーク全体

のインフラストラクチャでギガビット Ethernet が必要になります。

概要

SAN のベストプラクティス

IP ネットワークのベストプラクティス

vSphere ネットワークのベストプラクティス


• ネットワークの冗長性とパフォーマンスのために物理ネットワークカードを集

約する。たとえば、サーバー/vSwitch ごとに 2 つ 1 組の物理 NIC を使用し、

各物理 NIC を別々の物理スイッチにアップリンクします。

vSphere とのネットワーク接続については、「VMware vSphere Networking」の手順

を参照してください。


26

コンピューティングレイヤー

仮想化インフラストラクチャのサーバープラットフォームは、プラットフォームのサ

ポート性と環境の技術的な要件に基づいて選択します。本番環境でのサーバーの

要件は次のとおりです。

• 必要な数とワークロードの仮想マシンをサポートするのに十分なコアとメモリ

• IP スイッチとストレージネットワークスイッチへの冗長な接続を実現するの

に十分な接続性（Ethernet と FC の両方）

• サーバー障害や仮想マシンのフェイルオーバーに対応するのに十分な容量

このテスト環境では、4 台の物理サーバーを使用して vSphere HA クラスターを構成

し、各サーバーで vSphere ESXi サーバーを運用しました。また、4 ノードの仮想化

Oracle RAC データベースの導入を作成するように 4 台の仮想マシンを構成しました。

vSphere ESXiテクノロジー3上に導入する場合は、Oracle Database 11g R2 以降の

バージョンが完全にサポートされます。これには、Oracle RAC構成の導入も含まれま

す。

EMC では、「Oracle Databases on VMware Best Practices Guide」で説明されている

ように、次の VMware コンピューティングリソースのベストプラクティスを実装するこ

とを推奨しています。

• ESXi サーバーで NUMA（Non-Uniform Memory Access）を使用する。NUMAは、特定のプロセッサから遠い位置にあるメモリよりも、そのプロセッサに近

い位置にあるメモリに短い待ち時間でアクセスできるコンピューターアーキ

テクチャです。

• 仮想マシンの仮想マシンメモリ（vRAM）を、NUMA ノード（プロセッサ）がアク

セスするローカルメモリ以下になるように割り当てる。

• 仮想マシンのゲストオペレーティングシステムのパフォーマンスを向上する

ユーティリティや仮想マシンの管理能力を改善するユーティリティを含む各

種 VMware ツールをインストールする。

• vRAM を Oracle SGA（システムグローバル領域）の 2 倍以上のサイズにな

るように割り当てる。

• 仮想マシンのメモリ予約を、Oracle SGA やオペレーティングシステムオー

バーヘッドのサイズ以上になるように構成する。

• データベース仮想マシンに複数の PVSCSI（準仮想化 SCSI）コントローラーを

使用する。複数の仮想 SCSI コントローラーを使用することで、ゲストオペ

レーティングシステムの内側で複数の I/O 操作を並列で実行できるように

する。データベースデータファイルの格納に使用するディスク用の PVSCSIコントローラーを構成する。

3 Oracle の VMware サポートポリシーは My Oracle Support のドキュメント ID 249212.1 で

定義されています。

概要

コンピューティングリソースとストレージリソース


• 別々の仮想 SCSI コントローラーを使用することで Oracle の REDO ログ I/Oトラフィックをデータファイルの I/O トラフィックから分離する。ベストプラク

ティスとして、オペレーティングシステムとスワップファイルの LUN 用に 1 台

のコントローラー、データベースの REDO ログファイルの LUN 用にもう 1 台

のコントローラー、さらにデータベースのデータファイルの LUN 用に 1 台以

上のコントローラーを使用することができます。

• ゲストオペレーティングシステムに HugePages を構成する。HugePages を使用すると、メモリ管理のオーバーヘッドが軽減され、ハイパーバイザーの

パフォーマンスが向上します。

• HBA と SCSI コントローラーの両方のキューを深くすることで、ストレージアレ

イへの並列 I/O の数を増やす。キューの深さを調整する方法の詳細につい

ては、VMware ナレッジベースの記事 2053145 を参照してください。

ネットワーク仮想化

ESXi サーバーごとに、表 6 に示す一般的な構成の標準 vSwitch を 2 つ作成しました。

表6. vSwitch の構成

名前目的

vSwitch0 管理およびパブリック仮想マシントラフィック

vSwitch1 Oracle RAC 相互接続のフォールトトレラント構成

高性能 VMXNET3 ドライバーを使用して各仮想マシンに 2 つの vNIC（1 GbE および

10 GbE）を割り当てました。1 GbE の vNIC は vSwitch0 に割り当ててパブリックトラフィックを提供し、10 GbE の vNIC は vSwitch1 に割り当てて Oracle RAC 相互接続ト

ラフィックを提供しています。

仮想マシンのテンプレート構成

VMware のテンプレートは、導入時間を最小限に抑え、必要な仮想マシンごとに繰り

返すインストールタスクと構成タスクを自動化します。テンプレートを使用すれば、

仮想マシンを、オペレーティングシステムやアプリケーションユーザーが構成済み

の状態で導入できます。また、ソフトウェアも構成して、最小限のユーザー操作です

ぐに使えるようにしておくことができます。

vCenter に格納されたカスタマイズ仕様により、仮想マシンの展開を合理化できます。

これらのテンプレートを導入ウィザード、自動化ツール、スクリプトで使用すると、新

しい仮想マシンを構築する前にサーバー設定（サーバー名、タイムゾーン、ネット

ワーク構成など）を自動的に作成または変更できます。

仮想マシンのテンプレートは、表 7 に示すように、Oracle ソフトウェアの要件と動作

条件に沿って vSphere クライアントで構成します。

表7. 仮想マシンのテンプレート構成

パーツ説明

CPU OLTP ワークロード向けの 8 vCPU

メモリ 128 GB

オペレーティングシステム Red Hat Enterprise Linux Server リリース 6.3

仮想化


28

パーツ説明

カーネル 2.6.32-279.el6

仮想ネットワークインターフェイ

ス Eth0：パブリック/管理 IP ネットワーク

Eth1：クラスター相互接続専用

OS ユーザー

（ユーザーの作成とパスワード

の設定）

ユーザー名：oracle

ユーザーID：1101

OS グループグループ：oinstall

グループ ID：1000

グループ：dba

グループ ID：1031

プリインストールソフトウェア Oracle グリッドインフラストラクチャ（スタンドアロンサーバー用）Oracle Database

インストール済み RPM パッケー

ジ（Oracle の動作条件として） Oracle のインストールガイドを参照

ディスク構成ルート、/tmp、スワップ領域、Oracle 11g R2 Database バイナリ用の 128 GB 仮想ディスク

仮想マシンの導入後、データベースストレージ用のディスクを RDM（raw デバイスマッピング）として追加しました。

ストレージデバイスへのアクセスの有効化

仮想マシンごとに、データベースストレージ用の LUN を XtremIO アレイから RDM と

して追加し、4 台の PVSCSI コントローラー間に分散させて I/O のバランスを調整し

ています（図 10 を参照）。

図10. 仮想マシンのディスク構成


SCSI コントローラーで［SCSI Bus Sharing］を［Physical］に設定し、仮想マシンに ESXiサーバー全体の Raw LUN への直接アクセス権および共有アクセス権を割り当てる

ようにします（図 11 を参照）。

図11. ［SCSI Bus Sharing］の設定


30

Oracle データベース

このソリューションでは、Oracle ASM と Oracle ACFS の両方を使用して、vSphere に

仮想化された 4 ノードの Oracle OLTP RAC および DW データベースを作成しました。

Oracle Database11g では、Oracle ASM と Oracle Clusterware が Oracle グリッドインフラストラクチャに統合されています。ACFS は ASM を拡張したもので、優れた汎

用のエクステントベースのジャーナリングファイルシステムを提供します。このソ

リューションでは、ASM を使用してデータベースファイルを格納し、ACFS を使用して

データロードテスト用の CSV（コンマ区切り値）ファイルを格納しました。

図 12 に、Oracle OLTP RAC ASM のインスタンスを示します。

図12. Oracle ASM のインスタンス

注：OLTP または DW テストに使用するデータベースの構成では、最適なパフォーマンスを

実現するためアーカイブログを無効にしました。

表 4（21 ページ）に示すように、3 つの ASM ディスクグループを使用して、データファイル、制御ファイル、オンライン REDO ログファイル、投票ディスクファイル、CRSファイル、一時ファイルなどの関連データベースファイルを格納しました。

ASM ディスクグループには外部冗長性を使用し、その他の ASM ディスクグループ

属性にはデフォルトの設定を使用しました。DATA と REDO の各ディスクグループの

作成では、XtremIO ストレージの I/O パフォーマンスを最大化するためにセクターサイズ属性を 4 KB に設定しました。また、オンライン REDO ログファイルのブロック長

も、REDO ディスクグループのセクターサイズと一致するように 4 KB に設定しました。

この構成では、冗長性が外部にある複数の ASM ディスクグループを使用しました。

• +CRS には、OCR と投票ファイルのインストールロケーションが含まれる。

• +DATA には、データファイル、制御ファイル、一時ファイルが含まれる。

• +REDO には、オンライン REDO ログファイルが格納される。

概要

OLTP データベースストレージの設計

OLTP データベースの Oracle ASMディスクグループレイアウト


表 8 に、ソリューションの各 OLTP データベースワークロードプロファイルを示します。

表8. 各 OLTP データベースのデータベースワークロードプロファイル

プロファイルの特徴詳細

データベースのタイプ OLTP

データベースのサイズ 4 TB

Oracle Database 11g R2 RAC（ASM 上）

インスタンス構成 sga_max_size=16 GB

注：データベースキャッシュのサイズが大きいほどバッファー

内のデータも多くなることを考慮し、非常に小さいバッファーキャッシュを構成して、一定の高い物理 I/O ワークロードが生

成されるようにしました。

ワークロードプロファイル SLOB でシミュレートされる OLTP ワークロード

データブロック長 8 KB

表 9 に、DW データベースに使用する ASM ディスクグループ設計の詳細を示します。

OLTP ASM ディスクグループレイアウトと同じように、+DATA と+REDO を作成しまし

た。さらに、+CSV という追加の ASM ディスクグループも作成しました。これは

Oracle ACFS ファイルシステムを使用してネットワーク共有として機能します。フラッ

トデータファイルはこの ACFS 共有に格納してデータベースに読み込みます。

表9. DW データベース環境の ASM ディスクグループマッピングに対するストレー

ジ設計

フォルダー名ボリュームサイズ

（GB）ボリューム数 ASM ディスクグループ名

DATA 700 8 +DATA

REDO 40 4 +REDO

CSV 200 1 +CSV

CRS 10 2 +CRS

表 10 に、このソリューションのデータベースとワークロードのプロファイルの詳細を

示します。DW ワークロードジェネレーターを使用して DW データベースを作成し、ソ

リューションに必要なクエリーやデータロードワークロードといった DW ワークロード

を提供しています。

表10. 各 DW データベースのデータベースとワークロードのプロファイル


データベースのタイプデータウェアハウス

データベースのサイズ 8 TB

Oracle Database 11g R2 RAC（ASM 上）

OLTP データベースとワークロードのプロファイル

DW データベース用の ASM ディスクグループの構成

DW データベースとワークロードのプロファイル


32


インスタンス構成 • sga_target=60 G

• pga_aggregate_target=40 G

• db_file_multiblock_read_count=16

ワークロードプロファイル DW ワークロード

データロードソース Oracle ACFS 上の外部フラットファイル

データブロック長 16 KB


パフォーマンステストと検証

OLTP システムと DW システムの両方の特徴を示すために、ソリューションテスト環

境は 2 つの主要なワークロードで構成しました。OLTP ワークロード用に Oracle RACデータベースを実行する仮想マシンを 4 台作成し、統合型 VMware 環境の DWワークロード用に Oracle RAC データベースを実行する仮想マシンをさらに 4 台作成

しました。

ここでは、データベースに対する SLOB で生成された OLTP ワークロードを実行して

実際の OLTP ワークロードをシミュレートしました。DW ワークロードの生成には DWワークロードジェネレーターを使用しました。

システム I/O のパフォーマンスメトリック（IOPS、MBPS、レーテンシー）は主に

Oracle AWR（Automatic Workload Repository）レポートから収集しました。このほか、

サーバー/データベースやストレージレベルでの I/O スループットのメトリックも収集

しました。

注：ストレージレイヤーとデータベースレイヤー間の追加の I/O パスとコードパスのため、

アレイ側で観測した I/O レーテンシーは実際には AWR レポートの値よりも低くなりました。

ベンチマークの結果は、ワークロード、特定のアプリケーション要件、システムの設

計と実装に大きく左右されます。これらの要因やその他の要因によって、相対的な

システムパフォーマンスが変動します。そのため、重要なキャパシティプランニング

や製品評価を検討する際には、このワークロードを特定のカスタマーアプリケーショ

ンベンチマークの代替として使用しないでください。

このレポートに含まれるすべてのパフォーマンスデータは、厳密に管理された環境

で取得されたデータです。他の動作環境で取得された結果と大きく異なる可能性が

あります。

EMC Corporation は、1 分あたりのトランザクション数で表される同様のパフォーマン

スをユーザーが達成できることの保証も表明も行いません。

テスト全体の目的は次のとおりです。

• 仮想化された Oracle データベースを XtremIO で実行したときに達成した高

パフォーマンスを示す。

• Oracle RAC クラスターのストレージ操作が XtremIO によってどのように大幅

に合理化されたかを知ってもらう。

• Oracle の 4 ノードの RAC データベース上での OLTP ワークロードに対する持

続的なストレージアレイ IOPS を示す。

• Oracle の 4 ノードの RAC データベース上での DW/OLTP ワークロードに対す

る持続的なストレージアレイ I/O 帯域幅を示す。

• 本番ボリュームのクローンをテスト/開発環境用に作成する場合に XtremIOのインラインデータ削減を使用して

概要

結果に関する注

テストの目的


34

• ストレージ領域を大幅に削減できることを知ってもらう。

ソリューションで実施したテストシナリオは次のとおりです。テストシナリオの詳細に

ついては、以降のセクションを参照してください。

表11. テストシナリオ

テストシナリオ同時ユーザー数注

クエリー100%の OLTP テ

スト 32 中程度のワークロード

48 大きいワークロード

更新トランザクション

100%の OLTP テスト 32 中程度のワークロード


クエリー/更新の割合が

75%/25%の OLTP テスト 64 中程度のワークロード


DW クエリー 128 4 ノードの RAC でのスループットの妥当性

検査を行う

DW データ読み込み 4 4 ノードの RAC でのデータ読み込みス

ループットの妥当性検査を行う

このソリューションでは、XtremIO アレイでの Oracle OLTP システムのパフォーマンス

の特性を明確にします。統合型の VMware 仮想化環境で 4 ノードの Oracle RACデータベースを作成しました。

ワークロードの生成には SLOB を使用しました。これが、データベースプラットフォー

ムからの物理的なランダム I/O を最大化するのに最適な SQL ワークロードです。

SLOB は、統合 I/O ジェネレーターに代わる、I/O 集中型の SQL ジェネレーターで、

次のような特性があります。

• 物理的なランダムシングルブロック読み取り（データベースファイルシーケ

ンシャル読み取り/データベースファイル並列読み取り）のテストをサポート

• ランダムシングルブロック書き込み（データベースファイル並列書き込み）

のテストをサポート

• 極めて大きい REDO ログ I/O のテストをサポート

• 単純な PL/SQL により構成

• あらゆるアプリケーション競合の影響を受けない

クエリー100%の OLTP テスト：SLOB ランダムシングルブロッククエリー専

用テスト

このテストを使用して、コンカレント SLOB「待ち時間ゼロ」セッション（同時ユーザー

のシミュレーション）で RAC データベースに対しクエリーを実行したときのパフォーマ

ンスを測定しました。

テストシナリオ

SLOB ランダムシングルブロック読み取り/書き込みワークロードテスト


各ユーザーが同様のクエリーを実行するセッションを SLOB ツールキットで生成し、

読み取り IOPS の妥当性検査を行いました。

テスト方法論各ユーザーが同様の OLTP クエリーを 4 ノードの RAC データベースに対して同時に

実行するコンカレントセッションを一定数実行して、パフォーマンス統計を測定しまし

た。

テストプロシージャこのテストでは、最初に中程度のワークロードを実行し、4 ノードの RAC データベー

スでノードごとに 8 セッションとして 32 のコンカレントセッションを実行しました。セッ

ションごとに、クラスターデータベースに対して OLTP クエリーのワークロードを実行

しました。次に、大きいワークロードを実行し、4 ノードの RAC データベースでノード

ごとに 12 セッションとして 48 のコンカレントセッションを実行しました。ワークロード

間で大きな違いがないことを確認するためと、さらに重要なこととして、XtremIO アレ

イが同じワークロードで一貫性のあるパフォーマンスを発揮することを実証するため

に、各ワークロードを 3 回ずつ実行しました。

テスト結果パフォーマンス統計の収集には、AWR RAC レポートを使用しました。AWR レポートの

「physical read IO requests」の値を見て、読み取り IOPS の統計を評価しました。

フォアグラウンドプロセスのクエリー平均レスポンスタイムは、AWR レポートの「Top Timed Events」にある「db file parallel read」と「db file sequential read」から計算し

ました（図 13 を参照）。

図13. クエリーのみの平均レスポンスタイムの測定 - AWR レポート

注：フォアグラウンドプロセスで SQL ステートメントを実行して、バッファーキャッシュに格

納できないインデックス、表、Undo セグメント、データファイルヘッダーなどに対するシン

グルブロック読み取り操作を実行すると、プロセスは OS に I/O リクエストを発行し、リクエ

ストしたブロックが OS から返されるまで「db file sequential read」イベントを待機します。こ

のテストではフォアグラウンドプロセスが「db file parallel read」イベントを待機している間

に、Oracle カーネルによって複数のシングルブロック読み取りリクエストがバッチに統合さ

れ、I/O リクエストは並列で OS に発行されます。フォアグラウンドプロセスはリクエストを発

行すると、そのリクエストバッチ内の最後のブロックが返されるまで待機し続けます。これ

らの 2 つの待機イベントを使用して、フォアグラウンドプロセスの平均読み取りレーテン

シーの平均レスポンスタイムを計算します。

Oracle データベースの観点から XtremIO アレイの平均 I/O レスポンスタイムを示す

ために、次の式を使用しました。

• db file sequential read の場合：


36

合計待機時間は T1 で、1,060.18 秒。

合計待機回数は N1 で、986,577 回。

• db file parallel read の場合：

合計待機時間は T2 で、1,450.58 秒。

合計待機回数は N2 で、568,066 回。

• 平均読み取りレスポンスタイムは、（T1+T2）/（N1+N2）、つまり（1,060.18 + 1,450.58）* 1,000/（986,577 + 568,066）であるため、平均レスポンスタイ

ムは 1.615 ミリ秒。

表 12 に、テストでの IOPS および対応する I/O レーテンシーを示します。

表12. テストで達成された読み取り IOPS および対応するレスポンスタイム（セッショ

ン数別）

パフォーマンスメトリック

パフォーマンスデータ

32 セッション 48 セッション

1 回目 2 回目 3 回目 1 回目 2 回目 3 回目

IOPS 197,288

197,601 197,128

228,092

228,011

228,599

db file sequential read（ミリ秒） 1.071

1.075

1.078

1.377

1.379

1.378

db file parallel read（ミリ秒） 2.558

2.554

2.567

3.420

3.421

3.430

平均 I/O レーテンシー（ミリ秒） 1.613 1.615 1.623 2.109 2.111 2.114

注：表内の IOPS の数値は、AWR レポートの「 physical write IO requests」値から取得した

ものです。I/O レーテンシーの値（ミリ秒）は、「db file sequential read」イベントと「db file parallel read」イベントの統計値に基づいて計算したものです。

4 ノードの RAC での合計 197,601 の読み取り IOPS と平均レーテンシー1.615 ミリ

秒は、4 ノードで 32 回のリーダーセッションを実行した場合に獲得した値です。リー

ダーセッションを追加してワークロードを増やすと、読み取り IOPS は 228,599 に、

IO レスポンスタイムは 2.114 ミリ秒に増加しました。

更新 100%の OLTP テスト：SLOB ランダムシングルブロック読み取り/書き

込みテスト

このテストを使用して、コンカレント SLOB「待ち時間ゼロ」セッション（同時ユーザー

のシミュレーション）で RAC データベースに対し UPDATE トランザクションを実行した

ときのパフォーマンスを測定しました。

各ユーザーが同様の UPDATE トランザクションを実行するセッションを SLOB ツール

キットで生成し、読み取り/書き込み IOPS の妥当性検査を行いました。


テスト方法論各ユーザーが 4 ノードの RAC データベースに対し同様の SLOB UPDATE SQL ステー

トメントを同時に実行するコンカレントセッションをさまざまな回数実行して、パフォー

マンス統計を測定しました。

データベースインスタンスごとにバッファーキャッシュを使用し（64 MB のみで、サー

バーにキャッシュされたデータブロックはほとんどありませんでした）、一貫した物理

書き込み I/O ワークロードをバックエンドストレージにプッシュしました。書き込み

ワークロードは UPDATE SQL ステートメントによって生成されたものですが、このス

テートメントでは一般に次の操作が行われます。

1. 更新対象のデータブロックをバッファーキャッシュに読み取る。

2. データブロックの行を更新する。

3. 更新した行をコミットして、LGWR によるオンラインログファイルへの REDOエントリーのフラッシュをトリガーする。

UPDATE ワークロードの実行中、バックグラウンドのデータベース書き込みプロセス

により「ダーティ」ブロックがバッファーキャッシュからデータファイルへとフラッシュさ

れます。非常に小さいバッファーキャッシュを使用したことを考慮すると、データブロックはバッファーキャッシュに読み込まれ、行が更新されるとすぐにバッファーキャッシュから書き出されました。その結果、UPDATE 操作を実行するたびに、バック

エンドアレイとの間で物理読み取りと物理書き込みの両方が発生しました。

テストプロシージャこのテストでは、最初に中程度のワークロードを実行しました。このワークロードは、

4 ノードの RAC データベースでノードごとに 8 セッションとして 32 のコンカレントセッ

ションで構成しました。セッションごとに、クラスターデータベースに対し同様の

UPDATE SQL ワークロードを実行しました。

その後、大きいワークロードを実行しました。このワークロードは、4 ノードの RACデータベースでノードごとに 32 セッションとして 128 のコンカレントセッションで構成

しました。ワークロード間で大きな違いがないことを確認するためと、さらに重要なこ

ととして、XtremIO アレイが同じワークロードで一貫性のあるパフォーマンスを発揮

することを実証するために、各ワークロードを 3 回ずつ実行しました。

テスト結果ワークロードを計算するために AWR レポートから次のパフォーマンス統計を使用し

ました（図 14 を参照）。

図14. UPDATE のみの書き込み平均レスポンスタイムの測定 - AWR レポート


38

• 物理書き込み IOPS には、「physical write IO requests」を使用しました（表 12では「読み取り IOPS」として示されています）。

• UPDATE トランザクションで発生した物理書き込み IOPS には、「physical read IO requests」を使用しました（表 13 では「書き込み IOPS」として示され

ています）。平均読み取りレスポンスタイムは、「db file sequential read」待機イベントから取得しました（図 14 の AWR 例では 0.96 ミリ秒でした）。

• REDO 書き込み I/O 帯域幅の計算には、「redo size」を使用しました（表 12では「REDO スループット（MB/秒）」で示されています）。

• 「log file parallel write」待機イベントの統計は、LGWR バックグラウンドプロ

セスの平均レーテンシーとして使用しました（表 12 では「LGWR レスポンスタイム（ミリ秒）」として示されています）。

• 「db file sequential read 」待機イベントの統計はデータベースフォアグラウン

ドプロセスの平均物理読み取りレスポンスタイムとして使用しました（表 12では「フォアグラウンドプロセス読み取りレスポンスタイム（ミリ秒）」として示

されています）。

• 「db file parallel write 」待機イベントの統計は、データベース書き込みバック

グラウンドプロセスの平均物理書き込みレスポンスタイムとして使用しまし

た（表 12 では「データベースライター書き込みレスポンスタイム（ミリ秒）」と

して示されています）。

表 13 に、テストのパフォーマンス統計を示します。

表13. テストで達成され読み取り/書き込み IOPS および対応するレスポンスタイム

（セッション数別）





読み取り IOPS 31,624 31,496 31,646 63,387 63,524 63,691

書き込み IOPS 33,118 32,973 33,136 66,787 66,975 67,112

合計 IOPS（書き込み+読み取り） 64,742 64,469 64,782 130,174 130,499 130,803

REDOスループット（MB/秒） 26 26 26 51 51 51

LGWRレスポンスタイム（ミリ秒） 1.849 1.831 1.860 4.128 4.135 4.117

データベースライター書き込み

レスポンスタイム（ミリ秒） 0.535 0.531 0.535 0.643 0.642 0.637

フォアグラウンドプロセス読み

取りレスポンスタイム（ミリ秒） 0.956 0.961 0.955 1.954 1.951 1.948

表 13 に示すように、ノードごとに 32 のコンカレントセッションを実行すると、合計

IOPS は、UPDATE トランザクションの構成要素である、33,136 の書き込み IOPS と

31,646 の読み取り IOPS からなる 64,782 に達しました。さらにコンカレントセッショ

ンを追加してワークロードを増加すると、合計 IOPS は、63,691 の読み取り IOPS と

67,112 の書き込み IOPS からなる 130,803 に増加しました。読み取り I/O レスポン


スタイムは 1.948 ミリ秒に、書き込み I/O レスポンスタイムは 0.637 ミリ秒にそれ

ぞれ増加しました。

つまり、セッション数を 4 倍にすると、次のような結果になりました。

• 合計 IOPS が 2 倍になった

• REDO MB/秒がほぼ 2 倍になった

• LGWR レスポンスタイムが 2 倍になった

• データベースライターレスポンスタイムにはほとんど影響がなかった

• フォアグラウンド読み取り時間が 2 倍になった

クエリー/更新の割合が 75%/25%の OLTP テスト：SLOB ランダムシングルブ

ロックテスト

このテストを使用して、コンカレント SLOB「待機時間ゼロ」セッション（コンカレントユーザーのシミュレーション）で、セッションの 75 パーセントを RAC データベースに

対するクエリーの実行に適用し、セッションの 25 パーセントを RAC データベースに

対する UPDATE トランザクションの実行に適用した場合のパフォーマンスを測定しま

した。このテストでは、実際の環境でのワークロードをシミュレートして XtremIO スト

レージのパフォーマンスの妥当性検査を行いました。

テスト方法論 4 ノードの RAC データベースに対してセッションの 75 パーセントを OLTP クエリーの

実行に、セッションの残りの 25 パーセントを同様の UPDATE トランザクションの実行

に同時に適用するさまざまな回数のコンカレントセッションを実行して、パフォーマン

ス統計を測定しました。

テストプロシージャ最初に中程度のワークロードを実行しました。このワークロードは、RAC データベー

スでの 64 のコンカレントセッションで構成し、クラスターデータベースに対してセッ

ションの 75 パーセントを同様のクエリーの実行に適用し、セッションの 25 パーセン

トを同様の UPDATE SQL ステートメントの実行に適用しました。次に、大きいワーク

ロードを実行しました。このワークロードでは、4 ノードの RAC データベースでノード

ごとに 32 セッションとして 128 のコンカレントセッションを実行しました。ワークロー

ド間で大きな違いがないことを確認するためと、さらに重要なこととして、XtremIO ア

レイが同じワークロードで一貫性のあるパフォーマンスを発揮することを実証するた

めに、各ワークロードを 3 回ずつ実行しました。

テスト結果ワークロードを計算するため、UPDATE トランザクション 100 パーセントのテストと

まったく同じように、AWR レポートのパフォーマンス統計を使用しました（図 15 を

参照）。


40

図15. 平均レスポンスタイム - クエリー/更新の割合が 75/25 のテスト - AWR レポート

表 14 に、テストでの XtremIO アレイの IOPS および対応する I/O レスポンスタイム

を示します。表 13 の数値は、UPDATE 100%のテストの場合と同様に、AWR レポー

トから抜粋したものです。


表14. テストで達成され読み取り/書き込み IOPS および対応するレスポンスタイム

（セッション数別）





読み取り IOPS 111,797 111,886 112,124 144,911 144,977

145,205

書き込み IOPS 28,773 28,738 28,830 37,130 37,164

37,194

合計 IOPS（書き込み+読み

取り） 140,570 140,624 140,954 182,041 182,141 182,399

REDO スループット（MB/秒） 21 21 21 28 28 28

LGWR レスポンスタイム（ミ

リ秒） 1.045 1.037 1.042 2.119 2.101 2,121

データベースライター

（DBWR）レスポンスタイム

（ミリ秒）

0.591 0.584 0.584 0.691 0.685 0.690

db file sequential read（ミリ秒）

1.138 1.136 1.133 1.747 1.748 1.746

db file parallel read（ミリ秒） 2.585 2.583 2.579 4.298 4.302 4.300

平均フォアグラウンドプロセ

ス読み取りレスポンスタイ

ム（ミリ秒）

1.304 1.303 1.299 2.039 2.040 2.039

注：この表に示すパフォーマンスメトリックの出典元については、前述のセクションを参照し

てください。

クエリーと UPDATE トランザクションを含む混合ワークロードでのテスト結果から、

XtremIO ストレージは高いレベルの IOPS を維持できることがわかります。クエリー

/UPDATE の割合が 75/25 のテストで 64 のコンカレントセッションを実行したところ、

読み取り IOPS は 112,124 に達し、書き込み IOPS は 28,830 でした。また、読み取

り I/O レーテンシーは約 1 ミリ秒に、書き込み I/O レーテンシーは約 0.59 ミリ秒に

維持されました。ワークロードを 128 のコンカレントセッションに増加すると、合計

IOPS は 182,399 に増えました（このうち、145,205 は読み取り IOPS、37,194 は書

き込み IOPS です）。読み取りレスポンスタイムは 2.039 ミリ秒に、DBWR レスポンスタイムは 0.69 ミリ秒にそれぞれ増加しました。

DW ワークロードジェネレーターで Oracle DW のテストワークロードを生成して、

XtremIO ストレージプラットフォームでの標準的な Oracle DW ワークロードをテストし、

その妥当性検査を行いました。

キットのスキーマには、sales と returns の 2 つのファクト表を含む 12 の表がありま

した。その他の表はディメンション表として機能しています。ファクト表では、日付単

位の範囲のパーティションが設定され、join キーのハッシュでサブパーティションが

設定されています。データベースのサイズは 3.8 TB でした。複数の同時ユーザーが

DW クエリーワークロードテスト


42

データに対して一連の標準クエリーを実行しました。このテストではスループットを測

定しました。

テスト方法論

このテストを使用して、一定数の同時ユーザーを実行し、ユーザーごとに同様のクエ

リーを実行した場合のパフォーマンスを測定しました。同時ユーザーは DW ワーク

ロードジェネレーターで生成しました。このテストではシリアルな表フルスキャンす

べてで、実行時に直接パス読み込みを選択しました。

テストプロシージャ

このテストには、ノードごとに実行中の同時ユーザーが 32 人含まれ、4 ノードの

RAC データベースでは実行中の同時ユーザーは合計 128 人となり、各セッションで

は DW ワークロードジェネレーターのスクリプトを使用して同様の DW クエリーワー

クロードを実行しました。

テスト結果

クエリーのスループット（GB/秒）を評価するために、AWR レポートの「physical read bytes」を使用しました（図 16 を参照）。

図16. クエリーのスループット – DW クエリーワークロードテスト - AWR レポート

AWR レポートから、テスト中、4 ノードの RAC データベースで DW ワークロードを実

行したときにスループットが 5 GB/秒に達したことがわかります。

最新のエンタープライズ DW では、頻繁な大量のデータ読み込みを 1 日中定期的

に行う必要があります。DW の 24 時間 365 日体制の性質から、DBA はデータ読み

込みに多くの時間をかける必要がなくなりました。このため、データの ETL（抽出、変

換、ロード）プロセスがデータベースのパフォーマンスに与える影響をシミュレートす

ることが重要です。

このテストシナリオでは、本番データベースでの ETL プロセスのデモンストレーショ

ンを行って、ETL ロード時のパフォーマンスデータ、特にスループット（物理書き込み

の合計 MB/秒）を記録します。

ここでは、Oracle の外部表を使用し、この外部表で ORACLE_LOADER アクセスドライバーを使用して、外部表から内部表にデータを読み込みました。データのソース

はフラットデータファイルです。

このテストシナリオから、データを Oracle ACFS ファイルシステムにある外部表から

データベースに読み込んだときのスループットの拡張性がわかります。

テスト方法論

このテストでは、このソリューションで使用したディスクストレージ構成による

XtremIO アレイのスループットがわかります。サーバーごとに 1 つのセッションとし

（合計 4 つ）、これらのセッションで 4 ノードの RAC データベースに対してデータ読み

DW データ読み込みテスト


込みを実行しました。セッションごとに CSV フラットファイルをデータベースに読み込

むことで同様の ETL ワークロードを実行しました。

テストプロシージャ

このテストでは、外部表からデータを読み込んで X-Brick のパフォーマンスを示しま

した。このテストには、4 ノードの RAC データベースでノードごとに実行中のユーザー

が 1 人含まれ、1 つの外部表からデータを読み込みました。つまり、同時に 4 つの

セッションでデータを読み込んでいることになります。

各セッションでは、サイズが 120 GB の 1 つの CSV ファイルを読み込みました。CSVファイルは Oracle ACFS ファイルシステムにあります。外部表は次にように作成しま

した。

create table sales_ext ( id integer, …) organization external( type oracle_loader default directory EXT_DIR access parameters (fields terminated by "|") location ('sales.csv')) parallel reject limit unlimited;

データは外部表から次のように読み込みました。

alter session enable parallel dml; alter table sales parallel; alter table sales_ext parallel; insert into /*+ append */ sales select * from sales_ext;

注：sales 表の構造は sales_ext 表と同じです。データは append ヒントを使って直接読み

込みます。データの読み込みには複数の並列スレーブが使用されています。

テスト結果

スループット（TB/時間）を評価するため、AWR レポートの「physical write bytes」を使

用しました（図 18 を参照）。

図17. データ読み込みのスループット – DW データ読み込みテスト - AWR レポート

AWR レポートから、データ読み込みのテスト時に、4 ノードの RAC データベースで

データ読み込みワークロードを実行したときのスループットが約 1.023 GB/秒、つま

り 3.59 TB/時間に達したことがわかります。


44

結論

Oracle Database 11g を EMC XtremIO および VMware vSphere と組み合わせたソ

リューションにより、複数のワークロードにわたって、統合型の仮想化 Oracle インス

タンスに真の拡張性が提供されます。このソリューションをシステムの基盤として使

用することで、柔軟性があり、予測可能で、ほぼ直線的な拡張が可能になります。

このソリューションがもたらす拡張性の高いインフラストラクチャによって、アプリケー

ションは拡大し続けるワークロードに一貫性のあるパフォーマンスで対処できるよう

になります。サーバー側では、CPU、メモリ、HBA ポート、フロントエンドポートなど、

追加のコンピューティングリソースに対応するようにソリューションを拡張できます。

ストレージ側では、XtremIO アレイのアクティブ/アクティブのスケールアウトアーキ

テクチャにより、容量とスループット（IOPS と MBPS の両方）を直線的に拡張できる

一方で、非常に優れた一貫性のあるレーテンシーを維持することができます。こうし

た要因を見れば、このソリューションが OLTP と DW のデータベース環境に最適であ

ることは明らかです。

また、このソリューションでは、仮想化による効率的なリソースの利用も実現され、

データベースとアプリケーションの統合ももたらされます。さらに、単一用途のアプラ

イアンスによる制約を受けることなく、独立した形で容量と処理能力を拡張できます。

アプリケーション、データベースソフトウェア、データベース以外のソフトウェアなど、

あらゆるレベルから変化を進めながら、ソリューションスタックはビジネスニーズで

強いられる需要の変動に対応することができます。その結果、本番インスタンスとレ

ポートインスタンスの統合を通して、リアルタイム分析などの新しいワークロードアプローチが利用できるようになりました。

このソリューションによって、次のことが実現します。

• ストレージを調整する必要がない、迅速でシンプルな XtremIO セットアップ

• 広帯域幅の DW で複数のコンカレントユーザーや大規模ブロックのランダ

ムワークロードに対応

• レーテンシーの縮小と IOPS の拡張でパフォーマンスと柔軟性を向上

• Oracle RAC など、I/O が高い仮想化されたクラスターデータベース

• XtremIO のインライン重複排除機能を使用することでストレージ占有領域を

大幅に削減

• Oracle RAC、vSphere HA などの可用性の高いクラスターシステムでフォー

ルトトレランス/保護を向上

サマリー

評価結果


参考資料

補足情報については、次の EMC ドキュメントを参照してください。これらのドキュメン

トにアクセスできるかどうかは、お使いのログイン認証情報によって決まります。アク

セスできないドキュメントがある場合は、EMC 担当者までお問い合わせください。

• 高パフォーマンス Microsoft および Oracle データベースシステム向け EMCインフラストラクチャ

• EMC XtremIO ストレージアレイの概要

補足情報については、次の VMware ドキュメントを参照してください。

• Windows XP Deployment Guide

• Oracle Databases on VMware Best Practices Guide

• VMware ナレッジベース：Large-scale workloads with intensive I/O patterns might require queue depths significantly greater than Paravirtual SCSI default values（2053145）

詳細については、「Oracle Database Client Installation Guide 11g Release 2 (11.2) for Linux」を参照してください。

XtremIO スナップショットの詳細については、次の Web リンクを参照してください。

• Introduction to XtremIO Snapshots White Paper

http://www.xtremio.com/introduction-to-xtremio-snapshots-white-paper

• XtremIO の概要：Snapshot Technologies for Oracle Database

https://community.emc.com/docs/DOC-30738

ホワイトペーパー

VMware ドキュメント

Oracle ドキュメント

その他のドキュメント

http://www.xtremio.com/introduction-to-xtremio-snapshots-white-paper

https://community.emc.com/docs/DOC-30738

emc xtremio high-performance consolidation … · ホワイト ペーパー. emc xtremio...

Documents

emc xtremio high-performance consolidation … · ホワイトペーパー. emc xtremio...