Comments
Description
Transcript
Oracle Exadata の代替ソリューションについて
技術資料 Oracle Exadata の 代替ソリューションについて Oracle Exadataの 代替ソリューションについて Oracle Exadata の代替ソリューションについて ⽬次 要約 ····································································································· 1 はじめに ······························································································· 1 Exadata のバックグラウンド ····································································· 2 Exadata のアーキテクチャー ····································································· 3 パフォーマンスに関するトラブルシューティング ········································· 4 I/O アーキテクチャー ·············································································· 4 ランダム I/O ·························································································· 5 リファレンスアーキテクチャー ································································· 6 ストレージ ···························································································· 7 サーバー ······························································································· 8 データベース ························································································· 8 ⾼可⽤性 ······························································································· 8 ディザスタリカバリ ················································································ 9 結論 ···································································································· 10 Oracle Exadata の代替ソリューションについて 要約 多くの企業にとってアプライアンスベースのアーキテクチャーは検討対象のひとつで す。この⽤途のハードウエアソリューションは⾼度な技術に⽀えられており、定めら れた IT サービスの提供に必要なすべてのインフラストラクチャーコンポーネントお よびソフトウェアコンポーネントを、単⼀のベンダーがカバーして供給するケースが しばしばあります。このようなソリューションには次のような利点があります。 ⼤幅な性能向上が可能である 設定のミスが引き起こすリスクを低減できると考えられる 顧客サポートの窓⼝が単⼀である 予算計画作業が単純化される このホワイトペーパーは、既存の組織規定に従いつつ⾮常に低コストで実効的に優れ た性能を実現する代替アプローチの詳細を説明するものです。 本ドキュメントではまた、シマンテックのソリューションが何故⾼い性能を実現でき、 かつワークロードの変動に対する柔軟性が⾼いのかという点について説明します。 さらに本ドキュメントは、シマンテックのソリューションが複雑性の低減に効果があ り、それにより IT サービスにおけるリスクを最⼩化できる理由も⽰します。 Oracle™向けのシマンテックのソリューションによって、総保有コストを低減しつつ、 オラクルベースのビジネスプロセスの迅速化と⾼信頼化が達成できます。 はじめに 2008 年の Exadata 製品化以降、オラクルは、個々のデータベースユーザーが専⽤の データベース装置を所有すべきであり、そのような専⽤機がデータベースの性能最適 化の唯⼀の⽅法であるとの考え⽅を指向したマーケティングに基づいて、データベー ス市場をターゲットとした事業を⾏ってきました。しかしこのアプローチには、3 つ の⼤きな問題があります。 1. 既存装置を Oracle Exadata データベース装置にアップグレードするためには多 額の費⽤⽀出を要すること 2. Exadata が必ずしもデータベース利⽤のすべてのケースにおいて最適とは限ら ないこと 3. インフラストラクチャーや作業⽅法、作業⼿順に⼤きな変更が必要なこと 今⽇、IT 部⾨に要請される業務は膨⼤なものになっています。システム管理者やスト レージ管理者、データベース管理者は⽇常的に多くの時間を拘束され多くの成果を求 められますが、通常であればそのような業務に対して⼿当てされるべき予算も割り当 てられないのが実情です。即ち IT 部⾨は、費⽤⽀出(ソフトウェア、ハードウェア) および運⽤コスト(時間、⽅法)の両⾯において企業の設備投資効率を最⼤化するため に、乏しい戦⼒での戦いを強いられるのです。その結果、IT 関係者の多くは、コスト 削減を追求すると同時に、過去に⾏ったアーキテクチャー関連の決定の⾒直しを⾏う ことになります。このトレンドの広がりに応えて、ハードウェアのメーカーと独⽴系 ソフトウェアベンダー(ISV)が、計算処理とストレージに関する広範なニーズに対応 した、⼀体型でブラックボックス・ターンキータイプのポートフォリオを開発、商品 1 Oracle Exadata の代替ソリューションについて 化し、それを強化しつつあります。しかし、リレーショナルデータベース管理の領域 では、特にオラクルと⽐較した場合、これらが普及しているとは⾔えません。 このドキュメントの⽬的は、Exadata が有するパフォーマンスを最⼤限に実現し、イ ンフラストラクチャーに対する過去の投資を活⽤し、既存の運⽤規定と統合できる実 際的なアプローチを解説することにあります。このドキュメントでは、既存の⼀般的 に広く利⽤可能な技術と⼀部の将来技術または実験段階の技術に基づくアップグレー ド⽅法を紹介します。ここで紹介するアーキテクチャーは、費⽤対性能指数を競争⼒ のある状態に維持したままでシステム・パフォーマンスを向上するための改良ロード マップとして利⽤することができます。 Exadata のバックグラウンド 2008 年、オラクルは、HP™との OEM 関連事業の⼀環として Exadata データウェア ハウス装置を初めて開発しました。以降、3 つのバージョンがリリースされています。 現在では Exadata はオラクルの Intel™ベースハードウェア(サーバーとしては Oracle Enterprise Linux™ [OEL] と Solaris®が利⽤可、Exadata ストレージセルと しては OEL のみ利⽤可)上にホストされています。現リリース(Exadata X3)は、⾼性 能な InfiniBand ネットワークに接続された、⼤容量のランダムアクセスメモリー、 フラッシュメモリー、ソリッドステートストレージ、シリアル接続された SCSI (SAS) ス ト レ ー ジ を 有 効 に 利 ⽤ し て い ま す 。 こ れ ら ハ ー ド ウ ェ ア に 加 え て 、 Hybrid Columnar Compression から Real Application Clusters に⾄る各種オラクルソフト ウェアが使われています。理論上、このソリューションは極めて⾼性能でコスト効率 に優れたデータベースプラットフォームを実現します。 この閉じたソリューションにより、いくつかのアプリケーションにおいては相当程度 の性能向上が期待できるものの、これにはオラクルのライセンスおよびハードウェア に対する多額の費⽤⽀出の増加が伴います。多くの顧客は、多額の費⽤⽀出や⼤掛か りなアップグレードによる⻑時間のシステム停⽌を発⽣させることなくオラクルデー タベースの性能を段階的に改善する⽅法を追求していて、結果としてオラクルのソ リューションを使い続けています。Exadata への移⾏はまた、インフラストラクチャー 管理、アプリケーション、スタッフの役割、作業⼿順、バックアップ⽅法等の⼤幅な 変更を必要とします。典型的なオラクルユーザーにおいてはオラクルが主張する Exadata の価値を実現できない結果になることも多く、そのような場合は完全に過剰 設備となってしまいます。しかしこのために今⽇のデータウェアハウス市場において Exadata ソリューションが受⼊れられていないわけではありません。オラクルの Exadata は、インスタンス・ケージング、データベース(DB)・リソース・マネージャー、 ⼊⼒/出⼒(I/O)リソース・マネージャー等の機能により、オンライン・トランザクショ ン処理(OLTP)やハイブリッド・ワークロード環境において強い製品となっています。 閉じたブラックボックス・ソリューションに⽐較して、汎⽤でオープンなアーキテク チャーの⽅が⼤きな技術⾰新が起こる可能性が⾼いということは、⼀般的な認識に なっています。⼤幅に低いコストで、かつ既存のインフラストラクチャーを⼤規模に ⼊れ替えることなく、性能、スケーラビリティ、運⽤の容易性を実現することができ ます。Symantec Storage and Availability Management ボートフォリオには、既 存のオラクルおよび Exadata アーキテクチャーに⽐較して性能向上を実現する各種 2 Oracle Exadata の代替ソリューションについて の技術が⽤いられています。スケーラブルな⾼性能ストレージ管理技術、Dynamic Multi-pathing (DMP)、Cluster File System (CFS)、Cached Oracle Disk Manager (CODM)、Database SmartTier 等のソリューションが、総合的に⾼い可⽤性とディ ザスタリカバリ(HA/DR)およびストレージ最適化プラットフォームの実現を⽀援し ています。 Exadata のアーキテクチャー アーサー・C・クラークは、「充分に発達した科学技術は魔法と⾒分けがつかない」 と語っています。例えば、公表されている Exadata の性能値は既存のハードドライブ 技術を以ってしては達成不可能に⾒えますが、実際それは正しい推測です。15,000 RPM のドライブは 1 秒間に 250 回転し、完全にランダムな⼊⼒/出⼒(I/O)の場合、1 秒間に可能な⼊⼒/出⼒動作回数(IOPS)は 180 です。ディスクの外周部トラックに データを配置し、ショートストローク読み出しを⾏い、I/O キューイングにより 1 を 超える回転あたり I/O 数を実現したとしても、ハードディスクが達成可能な IOPS の 最⼤値は 500 です。Exadata X2-2 において実現可能とされている 150 万 IOPS を達 成するためには少なくとも 3,000 台ものハードドライブが必要です。また、Exadata の⾼い公表 IOPS 値を実現するためにはフラッシュ・キャッシュやソリッドステート ディスク(SSD)も必要となります。 Exadata は、I/O 性能の向上のためにフラッシュ技術を利⽤しています。その結果 Exadata では I/O スループットの向上も必要となり、旧来の 4Gb/s Fiber Channel インターフェイスに代わって 40Gb/s の InfiniBand インターフェイスを⽤いていま す。Exadata X3 では、データベース全体をメモリーにキャッシュできる⼤容量 RAM を導⼊し、I/O に対する読み出し要求を⼤幅に低減しました。 Exadata のハードウェア能⼒は最先端のものですが、今⽇の既存技術を凌駕している 点はそれだけではありません。 I/O 読み出し回数低減のための⼤容量のランダムアク セスメモリーの導⼊、I/O パス速度向上のためのフラッシュ・キャッシュ、I/O スルー プット向上のための CPU・ストレージ間 I/O バスの⾼性能化、IOPS 向上のための SSD 導⼊によるハードディスクドライブ限界の打破等の技術を取り⼊れています。これら の性能向上技術は、Exadata のコスト上昇をもちらすという問題はあるものの、既存 の IT アーキテクチャーにより実装可能です。 ハードウェアの改善に加えて、オラクルは、ストレージサーバーにおけるオフロード 強化型 SQL 処理、ソリッドステートストレージを⽤いたデータキャッシング、Hybrid Columnar Compression 等のソフトウェアの改善も⾏っています。ただし、Hybrid Columnar Compression の OLTP ワークロードに対する効果は限定的なものです。 Exadata では OLTP とデータウェアハウスの両⽅のワークロードを処理することがで きますが、同⼀クラスター内で複数のオラクルシステムを動作させることはできませ ん。さらにオープンなソリューションと Exadata ソリューション間の移⾏のみならず、 Exadata の X1、X2、X3 間の移⾏も簡単にはできません。オープンソリューションで はこのような制限はありません。 オラクルは三重のデータミラーリング、 またはローカルなデータミラーリングと Data Guard を⽤いた第 3 のミラーとの⾃動同期の併⽤を推奨しています。三重のミラーリ 3 Oracle Exadata の代替ソリューションについて ングが必要であるということは、Exadata ストレージソリューションにおけるデータ 消失リスクが⾼いことを意味しています。Exadata では、ホストベースやアレイベー スの⾃動同期機能は備えておらず、バックアップの際は Oracle Recovery Manager を使⽤します。 性能障害の解明 性能障害を解明することは段階的に改善可能な部分を特定し、IT 投資効果を最⼤限に することに役⽴ちます。アプリケーションの性能は、ハードウェアかソフトウェアか を問わず最も遅いコンポーネントによって制約されます。 ハードウェアによる制約 (CPU、メモリー、I/O、ネットワーク容量、条件設定 等) ソフトウェアによる制約 (OS、アプリケーションコード、条件設定等) アプリケーションの性能向上は、ボトルネックの特定とその対策により実現されます。 これらには、条件設定のチューニング、コードの書き直し、ハードウェアの性能改善 等があります。システムには必ずボトルネックがあり、その対策の⽬的はアプリケー ションがビジネスに必要な性能を「⼗分に満⾜する」ことにあります。 ハードウェアにおけるボトルネックは条件設定の調整により改善できる場合がありま す。例えば、ストレージのスループット改善のために Dynamic Multi-Pathing を使⽤ して I/O パスを増やすケースです。性能を画期的に改善する(規模の拡⼤、速度の増 ⼤等)ためには費⽤⽀出が必要となる場合もあります。ソフトウェアのボトルネックは、 インフラストラクチャーに存在する場合やアプリケーションのコードに存在する場合 があります。これらはさらに、設計上の問題である場合、条件設定の問題である場合、 その両⽅である場合があります。⼀般的にはインフラストラクチャー設定のチューニ ングの効果は限定的で、ソフトウェアの変更の⽅が⼤きな性能向上に結びつく可能性 が⾼いと⾔えます。例えば、VxFS ファイルシステムにおけるリードアヘッド値を増 やすことによって期待できる性能向上は 15 パーセント程度ですが、特定の SQL ス テートメントをチューニングすることによって 200 パーセントもの性能向上がもた らされる場合があります。同様に、ハードウェアをアップグレードすることによって 効率の悪いソフトウェアであってもより早く実⾏させることができますが、この⽅法 では効率そのものを改善できるわけではありません。 性能障害の対策をハードウェアにしわ寄せすることは完全な解決法ではありません。 市場競争下においては、そのハードウェアをいかに使いこなすかが成功と失敗の分岐 点になります。ビジネスとして投資効率を最⼤にするために資源を集中すべき部分を ⾒抜くためには、ボトルネックの場所や既存のシステムにおける最も弱い箇所を発⾒ できる能⼒が必要になのです。 I/O アーキテクチャー 最新の CPU はナノ秒単位でデータ処理を⾏うことができ、これはメモリー(DRAM) より 1,000 倍も速い動作です。しかし、その DRAM も、15,000RPM の⾼性能 Fiber Channel ディスクドライブと⽐較すると約 8,000 倍速く動作します。近年、NVRAM 技術のコストが低下し、PCIe フラッシュ・ストレージおよびソリッドステートディス 4 Oracle Exadata の代替ソリューションについて クという 2 つの新技術製品が導⼊可能となりました。これらのアクセスタイムはそれ ぞれ 25 マイクロ秒と 3 ミリ秒です。下記の図は、これらの技術それぞれの容量とア クセスタイムの関係を対数⽬盛りで⽰したものです。 フラッシュ・ストレージは、今⽇のコンピューターシステムにおいて⼤幅な性能向上 をもたらしています。フラッシュ・ストレージと SSD が DRAM と既存のハードディ スクドライブ(HDD)と間のギャップの橋渡しをしています。CPU の能⼒はほぼ毎年倍 増していますが、HDD の I/O シークタイムはそうではありません。Exadata では、 フラッシュ・ストレージと 40 GB/秒の InfiniBand 接続を利⽤して I/O 性能を向上さ せています。フラッシュ・ストレージは、既存の HDD における回転待ち時間とシー クタイムをなくし、アクセスタイムを 25-200 マイクロ秒の領域にまで短縮します。 これは、ランダムな I/O 処理の多いワークロードにおいては⼤幅な性能向上をもたら します。 ランダム I/O IOPS (1 秒間に可能な I/O 数)は、ランダムな読み出し性能の評価指標として利⽤さ れます。メーカーはストレージシステムの性能を⽐較する指標として IOPS を⽤いて います。ランダムな読み出し動作が要求されると、正しい位置のトラックを探す時間 とプラッター上の正しい位置までディスクを回転させる時間が必要になります。IOPS の最⼤値は、ドライブの幾何学的形状等のハードドライブの物理特性によって制約さ れ、次の数式で表現されます。 IOPS = 1 秒 / (平均シークタイム + 平均回転待ち時間 + 平均アクセスタイム) 例えば、15,000RPM の⾼性能ドライブの場合、平均回転待ち時間は 2.0 ミリ秒(60 秒 / 15,000RPM / 2)であり、シークタイムを 3.8 ミリ秒、アクセスタイムを 20 マ イクロ秒とすると、IOPS は 172 となります。 1000 ms / (2.0 ms + 3.8 ms + 0.02 ms) = 172 IOPS I/O キューイングとショートストローキングはディスク 1 回転あたりの I/O 回数を 1 より増加させる⼿法であり、ハードドライブの IOPS 能⼒を 2 倍にすることも可能で す。 5 Oracle Exadata の代替ソリューションについて フラッシュ・ストレージの場合は、シークタイムと回転待ち時間は 0 であり、IOPS は次のような簡単な式となります。 IOPS = 1 秒 / 平均アクセスタイム 平均アクセスタイムが 20 マイクロ秒のフラッシュ・ストレージにおいては、IOPS は 50,000 となります。ランダム読み出し動作においてはフラッシュ・ストレージが IOPS の改善に極めて有効であり、既存のハードドライブを圧倒することは明らかで す。フラッシュ・ストレージでは、多数のフラッシュチップに同時にアクセスするこ とでアクセスタイムの更なる短縮を実現しています。 現在のストレージエリアネットワークの多くは 2GB、4GB、または 8GB の Fiber Channel (FC)を⽤いて実装されています。10GB、16GB も⼊⼿可能であり、20GB が開発段階にあります。Ethernet ネットワークの性能がギガビットから 10 ギガビッ トに向上するに伴い、Fiber Channel スイッチに⽐べて Ethernet スイッチのポート あたりのコストが安価なことから、 Fiber Channel over Ethernet (FCoE)のような 統合ソリューションが⼀般的になりつつあります。⾼速化技術の出現により、FCIP、 iSCSI、HyperSCSI のようなプロトコルが続けざまに開発されてきました。これらは すべて本質的には既存のプロトコルを Ethernet または IP 上で実⾏するものです。 InfiniBand は、CPU と⾼性能 I/O ノード間の通信回線として開発されました。 InfiniBand では複数の通信速度と複数の変調技術をサポートしており、2 GB/秒から 300 GB/秒に渡るデータレートに対応しています。InfiniBand スイッチは⼀般的にク ラスター間の接続や、⾼性能コンピューターシステムに⽤いられます。 リファレンスアーキテクチャー オラクルの Exadata は、⾼級スポーツカーに例えられます。⾞⾃体は時速 200 マイ ルでの⾛⾏が可能であっても、それを現実に達成するためには、その他のインフラス トラクチャー(道路の状態、他の⾞の有無)が適切な状態になければなりません。 Exadata はまさにこの状態にあり、既存のディスク SAN やネットワークインフラス トラクチャーを置き換えるものではあっても、その他のアプリケーションインフラス トラクチャーを置き換えるものではありません。 本ドキュメントにおいては、データセンターの I/O 性能を向上させるために、ストレー ジ、サーバー、データベース等、すべての部分を⾒直していくことを推奨します。性 能上のボトルネックが存在するコンポーネントに注⽬して、全体の性能向上を図るこ とが重要です。ボトルネックの存在しない部分に注⽬することも⻑期的に⾒れば何ら かの利益をもたらす可能性はあるので、インフラストラクチャーのアップグレード時 に検討対象とすることは必要と思われます。何が有⽤かということは時により変化す るものです。 ハードウェアのアップグレード計画は⼀般的に、償却スケジュールや契約上のサポー ト終了時期等の経営的条件によって決定されます。ハードウェアの⼀部を他の⽤途に 再使⽤できる場合は、ハードウェアのアップグレード時期は前倒しになり得ます。オー 6 Oracle Exadata の代替ソリューションについて プンソリューションの場合は⼀般論としては再利⽤が容易ですが、専⽤機によるソ リューションの場合、再利⽤価値は限定的です。⼀般的にハードウェアは新しければ 新しいほど既存のものに⽐べて⾼性能でかつ安価になるので、ハードウェアの購⼊時 期は遅ければ遅いほど有利になります。 ソフトウェアのアップグレードによる新機能の追加は⼀般的に理由付けが容易で、特 に新機能によって短期間で ROI が回収できてその後は毎⽉剰余利益を⽣ずるような 場合は容易です。例えば、Dynamic Multi-Pathing 機能によりストレージの帯域幅を 2 倍ないし 3 倍にすることにより、性能の画期的向上が期待でき、追加的なハードウェ アの購⼊時期も遅らせることができます。ただし、必要とされる IOPS または I/O ス ループットに、基盤となっている SAN ストレージが対応できない場合は、⽬標の性 能を得ることができない可能性があります。 シマンテックの Veritas Storage Foundation™を使⽤することにより、ホストの I/O 性能を解析することができます。SAN に I/O ボトルネックがあるか否かは、ストレー ジメーカーに問い合わせて確認することができます。また、Database Administrator (DBA)を使⽤することにより、データベースの動作遅延箇所を知ることができます。 全体の性能向上のために必要な措置に集中して⾏動を起こすためには、ユーザーが⾃ ⾝のアプリケーションの動作状況を知ることが重要です。 ストレージ HDD をフラッシュ・ストレージや SSD にアップグレードするためには多⼤なコスト を要します。ただし、SSD の価格は Fiber Channel ハードドライブの価格よりも急速 に低下しつつあります。SSD が消費する電⼒は格段に⼩さく、従って冷却も不要です。 IOPS の観点から⾒ても、電⼒消費や冷却に必要な運⽤コストを含めた場合、数年の 期間運⽤するならば、SSD は Fiber Channel よりもコスト効率が⾼いと⾔えます。 ストレージの性能向上にはいくつかの異なる戦略が考えられます。 ⾼い IOPS ワークロード能⼒を有する SSD への移⾏ ストレージへのホップ数の抑制(例えば、クリティカルなサーバーにおいてはコ ア・エッジ型アーキテクチャーを使⽤しないこと) ストレージにおけるマルチパスおよびホストにおける Dynamic Multi-Pathing の使⽤ SmartTier を使⽤して、最もクリティカルなデータを SSD に移⾏させ、⻑期保 存データは既存のストレージに保管するという使い分け ランダム読み出しのアクセス⽐率が 75 パーセントを超えるデータの SSD への 移⾏ PCIe フラッシュ・ストレージ I/O アクセラレーターカードの使⽤ SSD SAN への移⾏(例えば、Violin Memory) オラクルのファイルシステムにおける VxFS の使⽤。これにより、Raw デバイ スに近い I/O 性能を実現し、コンシステント・スナップショット・バックアップ を⾏うためのファイルシステム関連作業が容易になります。 7 Oracle Exadata の代替ソリューションについて サーバー ランダム・アクセス・メモリー(RAM)は、オラクルの性能向上を⽬的として追加可能 なコンポーネントの中で動作速度が最⼤です。最新の Exadata X3 モデルでは、この 事実を利⽤してデータベース全体をキャッシュするための⼤容量の RAM を装備して おり、読み出し I/O の回数を画期的に低減しています。RAM の最⼤の⽋点は揮発性 だという点です。メモリーの性能向上にはいくつかの異なる戦略が考えられます。 性能最⼤化のために、オラクルのシステムグローバル領域(SGA)に可能な限りの RAM を割り当てること 性能最⼤化のために、メモリーインターリーブを、設定可能な最⼤値とすること ランダム I/O の低減のために、オンラインで VxFS ファイルシステムのデフラグ を⾏うこと 広範囲のフラグメンテーションを防⽌するために VxFS の最⼩エクステントサイ ズを 32MB に設定すること データベース オラクル再実⾏ログを、最速のストレージに保存することによりデータベースの性能 が向上します。スタンドアローン環境においては、オラクル再実⾏ログを PCIe フラッ シュ・ストレージに保存することが、既存技術によって可能な最速ソリューションで す。クラスター環境においては再実⾏ログを共有ストレージに保存しなければならず、 SSD が最速のオプションです。Storage Foundation の新機能が開発中の段階にあり、 これが供⽤されると、SSD、HDD の両⽅に対応する共有ストレージ I/O アクセラレー ターとして PCIe フラッシュ・ストレージの利⽤が可能となります。 Storage Foundation は、データベース性能の向上のために、Cached ODM (Oracle Disk Manager)をサポートしています。ODM は、システムのページキャッシュおよ びオラクル SGA におけるデータの⼆重バッファリングを防⽌し、オラクルによるダ イレクト I/O を可能にします。ODM を有効にした場合、新たに使⽤可能となったメ モリーを有効利⽤するためにはオラクル SGA のチューニングが必要です。Cached ODM はこれを更に進めたもので、⼀層の性能向上のために、Storage Foundation が オラクルのデータを効率的にキャッシュします。 ⾼可⽤性 ビジネス上のニーズに対応するためにはデータベースを可能な限り⾼速で動作させる だけではなく、可⽤性が⾼くなければなりません。データベースがスタンドアローン アプリケーションであることはほとんどなく、通常は複層的マルチプラットフォーム アプリケーションの⼀部であるため、常に利⽤可能でなければなりません。⾼可⽤性 は、Cluster File System 向け Storage Foundation を実⾏して Fast Failover を有 効にすることにより達成可能です。シマンテックが提供する Veritas™ Cluster Server の Intelligent Monitoring Framework を使⽤することにより、オラクルのインスタ ンス障害の即時解析が最⼩限のオーバーヘッドで可能であり、直ちに回復プロシー ジャーが開始されます。このソリューションにより、コストや Oracle RAC (Real Application Cluster)の複雑性を増加させることなく、シングルインスタンス環境のオ ラクルの不稼動時間を最⼩にすることができます。 8 Oracle Exadata の代替ソリューションについて Oracle RAC は、データベースのインスタンス規模を拡⼤する唯⼀のソリューション です。データベースのインスタンスがサーバーの物理容量を超えた場合、RAC が必要 になります。RAC を有効活⽤するためには、アプリケーション側にも性能向上分を利 ⽤できるような修正が必要になります。オラクルデータベースインスタンスの RAC への変換のみを⾏った場合、複数のデータベースノードにおけるキャッシュのコンシ ステンシーを確保するために Cache Fusion を使⽤する必要があるため、性能向上は 25 パーセント程度です (この性能向上は⼤きく変わり得るものでアプリケーション のパーティション化の程度によっては 25 パーセントよりも相当⼤きな値となること もあります)。 Oracle RAC は、データベースインスタンスを複数のサーバーで並⾏して実⾏するこ とにより、可⽤性とデータベースインスタンスの性能の両⽅において最⾼のレベルを 達成する能⼒があります。Oracle RAC は、シングルインスタンスのオラクルクラス ターと⽐較して 1 桁上の複雑性を有しています。可⽤性の⾯では、Oracle RAC は、 制御可能なフェイルオーバー期間中に即時 SQL 接続をフェイルオーバーさせるよう に設定することも、あるいは設定とワークロードの状況によりある程度の秒数をかけ てフェイルオーバーさせることもできます。性能⾯では、既存サーバーにおける CPU やメモリーのアップグレードではなく、サーバーを追加することによるデータベース の規模の拡⼤が可能です。 ディザスタリカバリ ディザスタリカバリはすべてのビジネスにおいてその重要性が増⼤しています。 Oracle Exadata は、ディザスタリカバリに関しては Oracle Data Guard のみサポー トしています。オープンソリューションでは Data Guard に加えて以下をサポートし ています。 キャンパスクラスターをカバーする Oracle RAC キャンパスクラスタリング シマンテックが提供する Veritas™ Volume Replicator ハードウエアベースのレプリケーション(例えば、Hitachi™, EMC™, IBM™) キャンパスクラスターは、同期が可能な距離(通常 100KM 以下)にあり、少なくとも 2 つの独⽴の⾼速(10GB/秒)ネットワークで接続された 2 箇所のデータセンターの総称 です。キャンパスクラスターでは、2 箇所の SAN データをミラーリングします。2 箇 所のデータセンター間の同期または⾮同期のデータレプリケーションには、Veritas Volume Replicator やハードウエアベースのレプリケーションソリューションが利⽤ 可能です。Data Guard がオラクルのデータベースインスタンスのレプリケーション 専⽤であるのに対し、キャンパスクラスター、Veritas Volume Replicator、ハード ウエアベースのレプリケーションソリューションはあらゆるデータタイプに対応しま す。 9 Oracle Exadata の代替ソリューションについて 結論 最新で⾼速な技術に移⾏することには課題が伴います。オラクルの Exadata は、メモ リーの強化、⾼速な InfiniBand SAN 構造とフラッシュや SSD の導⼊、ディスク SAN やネットワークインフラストラクチャーの⼤掛かりなアップグレードの必要性等の理 由により、多額の費⽤⽀出が必要です。また、Exadata においては、オラクルによる サポート費⽤および管理コストも⼤きな負担となります。 Exadata はさらに、IT 部⾨のインフラストラクチャー、スタッフ、作業⽅法、作業⼿ 順にも⼤きな変更が必要です。賢明な顧客はこのことを認識しており、ビジネスに必 要なアプリケーション性能を達成するという⽬的に絞って段階的にインフラストラク チャーのアップグレードを⾏っています。インフラストラクチャーの段階的なアップ グレードにおいては常にオプションの選択が可能で、⽬的を絞ったアップグレードに よってデータベースやアプリケーションの性能向上が最⼩の費⽤⽀出で可能となり、 運⽤コストも少額にとどまります。 シマンテックは、⾼価で複雑な Oracle RAC の代替としての Fast Failover、クリティ カルデータを⾼速なストレージ上に保存する SmartTier、データベースの I/O 性能を 向上させる Cached ODM、I/O スループットを改善する DMP 等、性能改善のための ソフトウェアソリューションを提供すると共に、すべてのビジネスアプリケーション に対応した総合的な HA/DR ソリューションを提供しています。 10 Oracle Exadata の代替ソリューションについて 11 Oracle Exadata の代替ソリューションについて Copyright © 2012 Symantec Corporation. All rights reserved. Symantecと Symantecロゴは、Symantec Corporationまたはその関連会社の⽶国およびその他の国における登録商標です。その他の会社名、製品名は各社の登録商標または商標です。 製品の仕様と価格は、都合により予告なしに変更することがあります。本カタログの記載内容は、2012 年 12 ⽉現在のものです。 株式会社シマンテック 〒１０７-００５２ 東京都港区⾚坂１-１１-４４ ⾚坂インターシティ www.symantec.com/jp E1212WP0-IG-Exdata 12