Oracle Database 11g R2の新機能とOracle VMで構築する次世代基盤解説

2009年9月にリリースされたOracle Database 11g Release2 (R2)によって、サーバー統合や仮想化はどのように実現できるのでしょうか。このセッションでは、さまざまな要件がある中でどのようにサーバーを統合すべきかを検討し、その先のオラクルが考える次世代基盤について紹介します。

目次

• Oracle Database 11g R2の機能とサーバー仮想化は適材適所で使いわける
• コストを抑えた多ノード構成で耐障害性を高める
• 高性能ストレージをコモディティ・ハードウェアで実現

Oracle Database 11g R2の機能とサーバー仮想化は適材適所で使いわける

オラクルでは、Oracle Databaseの以前のバージョンからサーバー統合やデータベース統合を提案してきました。サーバー統合を考える場合にはいくつかのレベルがあり、それを示したものが図1になります。

図1 サーバー仮想化とOracle Database 11g R2による仮想化

Oracle Database 11g R2では、従来は「クラスタウェア」と呼ばれていた層を「Grid Infrastructure」として強化し、これによって複数のハードウェアを束ねて1つの大きなリソースプールとして扱うというコンセプトを実現しています。
これまでのオラクルが行ってきたデータベース統合の提案は、データベースを1つに集約しつつ「 サービス」という形で各システムのQoSを確保するというものでした。確かにデータベースを1つにすることによって管理の手間を軽減させることはできますが、現実的には困難な場合があります。たとえば、文字コードの異なるデータベースを1つにする場合は、どちらかの文字コードを変更しなければなりません。このように、データベース統合のために何らかの変更を加えなければならないということが、統合の障壁となっていました。Oracle Database 11g R2では、Oracle RAC環境でデータベースインスタンスを統合する際にデータベースを独立して保持することができるようになりました。これにより、データベース統合へのハードルが下がったと言えます。次に考えたいのは、Oracle Database 11g R2ではデータベースから上を集約し、サーバー仮想化はOSから上を集約しているという違いです。これは、どちらがよいということではなく、仮想化の目的や環境によってどちらが適しているかを考える必要があります。 独立性のレベルを最大限に高くして専有空間をつくりたい場合は、サーバー仮想化を用いたOSレベルでの集約を。独立性よりもより統合された運用管理性を求める場合は、Oracle Real Application Clusters (Oracle RAC)を用いたQoSを管理するサービスレベルでの集約や、データベースレベルでの集約をお勧めします。
独立性と一元性は表裏一体となっているもので、たとえばデータベースのアップデートを行う場合、100台のデータベースを1つに集約しておけばアップデートは1回で済みます。しかし、逆にいえばそのアップデートですべてのサービスが影響を受けることになります。サーバーの統合は独立性と一元性のどちらを尊重するかによって選択してください。オラクルでは、独立性を高めたい場合は、サーバー仮想化によってOSごと分離。一元管理を行いたい場合は、Oracle Database 11g R2の機能によってサービスから、またはデータベースから分離。このような選択肢を用意しています。

図2-1 集約ポイントによるメリット／デメリット（Oracle Database 11g R2）

図2は、集約する層によって考えられるメリットとデメリットを示すものです。図2-1のOracle Database 11g R2を使った仮想化では、OSとGrid Infrastructureが1つになり、その上に複数のデータベースを置くという構成になっています。

図2-2 集約ポイントによるメリット／デメリット（Oracle VM）

また、図2-2のOracle VMを使った仮想化では、ハードウェア上の「Hypervisor」によってOSが分離されることになります。そして、それぞれのOSの上で独立してGrid Infrastructureやデータベースを走らせることになります。
データベースレイヤでの集約の最大のメリットは、OSとGrid Infrastructureを1つにすることによる統合管理です。しかし、誰かが間違ってOSをリブートしてしまえばすべてのサービスが影響を受けます。また、H/Wはデータベース専用のリソースになってしまうこともデメリットです。
一方でOSからの集約の場合は、複数のOSやGrid Infrastructureが存在するため、これらの管理負荷を低減できません。しかし、ミスオペレーション時の影響範囲は限られています。また、余剰リソースをWebアプリケーションや、検証環境等さまざまな目的に使うことができます。
これらのメリットとデメリットを考え、 独立性を高めるならサーバー仮想化を。一元性を求めるならデータベースから上の仮想化を行うことが重要なのです。

▲ ページTOPに戻る

コストを抑えた多ノード構成で耐障害性を高める

続いて、オラクルが考える次世代基盤の実装について説明します。
たとえば、4台の物理サーバーをOracle VMで仮想化し、それぞれの物理サーバーごとに2つの仮想マシンをつくったとします。それをアプリケーション層とデータベース層に分け、たとえば4台のOracle WebLogic Serverと4台のデータベース・サーバーを構築し、Oracle RACで多ノードのクラスタ構成をつくります。ここではOracle WebLogic Serverを例にあげていますが、オラクルのソフトウェアの大きな特徴の1つは“常にグリッド構成にできる”ということです。たとえば、Oracle CoherenceやOracle TimesTen In-Memory Databaseなど、オラクルが提供する基盤部分のミドルウェアはすべてグリッド化、つまり「並べて連結する」ことが可能です。
オラクルでは、 障害時の縮退率という観点から多ノード構成のクラスタをお勧めしています。たとえば、2ノード構成では片方の物理サーバーに障害が発生すると50％のリソースで運用を継続することになりますので、そもそも50％の性能をベースにサイジングしておく必要があります。これでは半分のリソースが無駄になってしまい、せっかくのActive-Active型クラスタを活かしきれません。一方、4ノード構成であれば、1台に障害が発生しても75％のリソースで運用できます。クラウド的な運用を考えるのであれば、多ノード構成は欠かすことができません。
しかし、多ノード構成にしてしまうと、ハードウェア・コストに加えてソフトウェア・ライセンス費用も増大してしまうことになります。実は、 Oracle VMにはCPU Partitioningに対応したライセンスが提供されているため、ソフトウェア・ライセンス費用をコントロールすることができます。たとえば8コアの物理サーバーを4台使った場合、通常は32CPU分のソフトウェア・ライセンスが発生しますが、1つの仮想マシンに対して割り当てるCPU数を2つに制限すれば、物理的に32CPUあっても合計8CPU分のソフトウェア・ライセンスで利用できます。つまり、Oracle VMによって最終的に8コアのサーバー1台と同じライセンス費用で4ノードのRACを利用できるのです。このようにOracle VMでライセンス費用をコントロールすることによって、 コストを抑えながら耐障害性を高めることをオラクルは提案しています。

図3 CPU Partitioning : アプリケーションサーバーとデータベースで8CPUずつ利用

▲ ページTOPに戻る

高性能ストレージをコモディティ・ハードウェアで実現

仮想化はサーバーの話だけで終わってしまいがちですが、重要なのはストレージで、ボトルネックになりやすいのもストレージです。前述のようにCPUの性能は高くなる一方ですが、ストレージI/Oの性能はそれほど高くなってはいません。そのため、多くの仮想マシンを稼動させるための拡張可能でハイパフォーマンスなストレージが必要とされがちですが、オラクルでは必ずしもそのような構成は推奨していません。 サーバーと同様に、コモディティでローエンドなストレージを複数台並べて性能と可用性を確保する「Storage GRID構成」をお勧めしています。
通常このような構成にすると、管理者がどのストレージに何を格納するかを設計しなければなりませんが、Grid Infrastructureがインストールされた環境ではASM（Automatic Storage Management）によって複数のストレージを連結して束ねることができ、データを自動分散配置させることができます。これによって各ストレージに対するI/Oの負荷も分散させることが可能です。また、ストレージの追加もオンラインで行うことができ、追加されたストレージは自動的にStorage GRIDに組み込まれて既存のデータは再配置（リバランス）されます。リバランスによってサーバーから発行されるI/O要求は次第にすべてのストレージに均等にまたがって処理されることになります。つまり、ストレージを追加した分、I/O性能が上がるということです。
ここまでをまとめると、 オラクルの考える次世代基盤とは「並べる。そして性能の可用性を確保する」ということになります。それはアプケーションレイヤ、データベースレイヤ、そしてストレ−ジレイヤに共通する考え方であり、驚くべきことにそれぞれがすでに製品として実装されています。

そして重要なのは、このGRID構成がいかにコストを抑えて実現できるかです。GRIDの考え方では、H/Wはコモディティでローエンドな機種を採用することでコストダウンし、S/WはOracle VMのCPU Partitioningで性能要件に対して供給するリソースを最適化してコストダウンを図ることができます。

図4 Storage GRID

▲ ページTOPに戻る