Oracle VM上でRACを利用する（1）

　RAC on VMへの2つの入り口

　RAC on VMには2つの考え方があります。「RACを仮想化する」という考え方と、「仮想化したDBをRAC化する」という考え方です。おそらくこれだけ聞いても違いはよく分からないと思います。実際、最終的にたどりつくシステム構成は同じものになりますが、この2つは入り口が異なり、RAC on VMを導入する目的が異なります。これらを分けて考えることでRAC on VMという技術のメリットが整理できます。

■RACを仮想化する

　おそらく、「RAC on VM」と聞いて直感的に連想するのはこのタイプでしょう。いままでRACを構成するRACノードの最小単位は物理マシン（サーバ）でした。RAC on VMという構成をとることによって、この最小単位が物理マシンから仮想マシンになります。つまり、同じ台数の物理マシンでより多くのRACを構築できることになります。可用性は妥協できないが、それほど性能が必要なわけではないといったシチュエーションで、採用が検討されるパターンがこれに該当します。小規模だが高信頼性が求められるデータベースを、RACを駆使しながらより安価に構築したいといった要件に効果的なソリューションです。

　いままで3つのRACを構築しようと思えば、2ノードRACだと想定しても最低6台の物理マシンが必要でした。

図2　これまでは3つのRAC構成に最低6台のサーバが必要

　それがRAC on VMでは、2台の物理マシンがあれば事足ります。

図3　Oracle VMを使えば2台で3つのRAC構成を組める

　小規模サイトにRACを適用するのはこれまでコストが見合わなかったという場合でも、RAC on VMであればためらわずにRACを適用することができます。なにしろRACノードは仮想マシンですから、必要なくなれば仮想マシンを削除して、新しいシステム用に新しい仮想マシンを作成すれば良いのです。

　RAC on VMは、必要なハードウェア数を削減できるとともにソフトウェアライセンスにもインパクトがあります。先ほどの例でいえば、3つの2ノードRACを構築する際にベアメタルで構成したとすると、必要なOracle Databaseのライセンスは6台分となります。しかしRAC on VMで2台の物理マシン上に3つの2ノードRACを構築した場合は必要なOracle Databaseのライセンスは2台分で済みます。これはOracle Databaseのライセンスは仮想マシンではなく、物理マシンにのみ課金されるというシンプルなライセンス体系となっているからです。

　もし、RACの適用が理想的と考えられるシステムが3つあった場合、前者の構成だと必要なコストは物理マシン x 6台 + Oracle Databaseライセンス x 6台分となり、実質性能的には6台もの物理マシンが必要ないケースでは多くの投資は無駄になってしまいます。当然全てのシステムにRACを適用することは「理想論」となってしまい、代替案の検討をせざるを得ません。

　しかし、これがRAC on VMだと話は変わります。必要なコストは（物理マシン x 2台）+（Oracle Databaseライセンス x 2台分）となります。ハードウェアとソフトウェアのすべての費用を合わせて3分の1の費用で導入可能です。しかもこれは3つのRACを集約した場合です。集約率を上げた場合には、比例して費用対効果が上がっていきます。実際、クアッドコアのCPUを2つ搭載した2ソケットのサーバを調達すれば，その上に最大16RACまで構築することができます。

＊これは2009年5月現在のRAC on VMに関する設定上の制約に依ります。

　これは，より小規模なシステムにもRACを適用するという選択肢が用意されたということです。企業は物理マシン2台からなる信頼性の高い、いわば「プチ・データベースクラウド」を構築することができ、その中からRACというリソースを柔軟にちぎって使うことができるようになります。リソースは要らなくなれば、またクラウドに返すことができ、リソースはすぐさま別の用途に再利用することができます。

　1つ疑問が残るかもしれません。それは、RACだけでもデータベースの「集約」はできるのに、なぜVMを入れる必要があるのかということです。つまりそれぞれのシステムを別のRACとして構築しなくても、同一のRAC上に「サービス」という形で分離して稼働させれば、VMがなくても集約できるではないかという問いです。

図4　同一のRAC上に3つのRAC構成をサービスとして設定してもいい？

　これに対する答えは2つあります。その1つは「独立性」です。1つのRACプラットフォーム上に複数のサービスを載せていくことは効率的なデータベースの集約方法であり、理想的な姿です。しかしながら実際の環境ですべからくこの手法が適用できるとは限りません。いままで別々の事業部で管理されていた、まったく用途も運用ポリシーも異なるシステムを共通の、RACプラットフォームにすべて集約するのは場合によっては非常に難しい移行作業です。各プロジェクトはそれぞれ独自にOSをカスタマイズし、管理用のエージェントを導入したり、必要なデーモンを起動したりしているかもしれません。セキュリティも大きな考慮事項です。ある脆弱点からクラックを受けた場合、その被害は特定のプロジェクトだけでなくそのOS全体、つまり集約したすべてのプロジェクトに及ぶ可能性があります。

　サーバ統合を進めるにあたり、企業組織全体で共通の強固なセキュリティポリシーを構築し、各事業部やプロジェクトが歩調を合わせてシステムを構築できるようなケースであれば、純粋にRACですべてを集約できるでしょう。しかし、現実的にそれが難しい場合は、サービスレベルではなく、OSレベルで空間を分離してより独立性を高めることができればサーバ統合作業の障壁の1つを乗り越え、よりスムーズに環境を移行することができます。そのオプションを提供するのがRAC on VMです。RAC on VMであれば各プロジェクトは独立したセキュリティレベルを確保しながら、それぞれの環境を柔軟にカスタマイズできます。

図5　仮想化でRACを構成すれば独立性が高められる

　もう1つの答えはリソース管理です。VM環境では各VMに割り当てるCPU個数、CPU利用率、メモリ容量、ネットワークポート、ネットワーク帯域幅、ディスクI/O帯域幅のそれぞれをきめ細かく制御することができます。したがってあるプロジェクトが使えるリソースはこのくらいに制限したい、一方、もう1つのプロジェクトが使えるリソースは常に最低でもこのくらいは確保したいといった場合、RAC on VMでは各RACを構成するRACノード（つまりは仮想マシン）に対してこのリソース制御を行うことで、ある一定のサービスレベルをコミットすることができます。

　このようにRAC on VMではこれまでのRACを小規模なサイトにも適用するという選択肢を提供します。そしてそれぞれのRACはOracle VMの仮想化技術によって完全に分離され、高い独立性／カスタマイズ性を確保することができます。

2/3

Index
Oracle VM上でRACを利用する（1）
	Page1 RAC on VMを利用するメリット
	Page2 RAC on VMへの2つの入り口 　　RACを仮想化する
	Page3 　　仮想化したDBのRAC化