データベースサーバー統合の流れ

統合方式を選択するポイント

　ここまでで、目的の明確化や現状把握ができましたので、次は統合の方式を検討・選択します。統合方式はグルーピングしたグループごとに検討します。データベースサーバーの統合方式としては、大きく2つの方法があります。簡単にそれぞれの方式で利用する技術的特徴をお話します。

・データベースクラスタリング（Oracle Real Application Clusters）
　Oracle独自のActive-Active型のクラスタリング機能である Oracle Real Application Clusters（以下、RAC）は、高い可用性と拡張性を同時に実現できます。
　複数のサーバーから1つのデータベースにアクセス可能なことから、複数システムのデータベースを統合する方法として、かなり以前から利用されています。

　RACの詳細については、オンライン・セミナーや技術資料をご覧ください（http://blogs.oracle.com/directjp/oracle_database/oracle_database_options/oracle_real_application_clusters/#material）。

・サーバー仮想化ソフト（Oracle VM）
　大規模クラウド環境での豊富な実績を持つXenをベースに、Oracleが独自拡張を行い、サポート・サービスを提供している仮想化ソフトウエアです。
　エンタープライズ環境で必要な機能を備えており、そのすべての機能を無償でご利用いただけます。

　Oracle VMの詳細については、オンライン・セミナーや技術資料をご覧ください（http://www.oracle.com/lang/jp/technologies/virtualization/index.html）。

　これら2つの統合方式を「データベースサーバー統合」という観点で比較したのが、図3-1です。

比較のポイントをいくつか解説します。

・可用性
　RACの方が高い可用性を実現できます。RACが優れるポイントとしては、主に以下が挙げられます。
（1）迅速な障害からの復旧
（2）対応可能な障害範囲の広さ
（3）障害発生時点の処理を引き継げる

・拡張性
　RACの方が高い拡張性を実現できます。RACはサーバーを追加するごとに処理能力を向上させることができます。一方、Oracle VMでは、1つのサーバーを分割する仕組みのため、最大の能力はサーバー1台分に限定されます。なお、次の章でお話する技術を使えばこの点も解決できます。

・導入の工数
　一般的には、Oracle VMの方が導入の敷居は低くなります。RACの場合には、従来バラバラに存在していたデータベースを1つに統合する必要がありますので、場合によっては、バージョンアップなどの作業が発生します。なお、この点については、「Oracle Database 11g Release2」で機能拡張され、統合の敷居は低くなります。こちらについては、今後の連載でお話したいと思います。

・統合後の運用管理
　従来どの部分の運用管理にコストがかかっていたかによりますが、一般的にはデータベースの数が減る＝管理対象のシステム数が減るので、RACの方が、工数を下げられる可能性があります。Oracle VMの場合には、物理的なサーバーの数は減りますが、管理しなければならないデータベースの数は統合前と変わりません。

　各方式には、ここで挙げたような特徴がありますので、こうした点を踏まえ、グループごとの要件に合致する統合方式を選択していきます。

Oracleでしかできないもう1つの選択

　上記でお話したように、各方式にはそれぞれ優れている点があり、捨てがたいところです。こうしたご希望にお答えするのが、両方の方式を利用した統合方法です。つまり、RACかOracle VMという選択ではなく、RACとOracle VMを同時に活用しようというお話です。言葉でご説明するのは少々難しいので、図3-2をご覧ください。

　つまり、Oracle VMで物理サーバー（Host1、2、3）を複数の仮想サーバーに分割した上で、その仮想サーバーの間でクラスタリング（RAC）構成をとることができます（Cluster1、2、3）。これにより、双方の利点を同時に享受することができます。Oracle VMの持つ導入の容易性＋RACの持つ高い可用性・拡張性が実現できる理想的な構成になります。この構成を1つの選択肢として構築されるお客さまも増えてきています。

　このように統合の選択肢は技術の進歩によってどんどん増えてきますが、現時点で目的達成とシステムの属性に最適な統合方式を選択してください。

　この後は、統合効果のシミュレーションを行い、第一の目的が達成できるか*1を検討し、具体的な実行フェーズに移っていくことになります。
（*1：例「これまで150台あったサーバーを30台に統合できそうなので、データセンターに支払うコストが年間xx万円削減できそう！」）

■今回のまとめ

（1）データベースサーバー統合の流れ
　目的を考える→現状を把握する→システムをグルーピングする→統合方式を選択する→サーバー統合へ

（2）データベースサーバー統合ではRACも選択肢になる
　データベースサーバー統合というと、仮想化という選択肢のみを考える方が多いのが実態です。確かに、初期のRACでは、1つのシステムで利用するデータベースの可用性・拡張性を高めるという利用方法でした。しかし、「Oracle Database 10g」や「Oracle Database 11g」で拡張されたRACでは、複数のアプリケーションで利用するデータベースの統合としても活用可能になっています（図3-3）。
　また、「Oracle Database Standard Edition」でもRACが利用できるようになったことで、統合対象となるシステム規模も広い範囲をカバーすることができます（http://www.oracle.co.jp/campaign/mb_tech/products/serac01.html）。

（3）当初に設定した目標が達成できるかを考える
　今回は、ページの都合で割愛させていただきましたが、統合効果のシミュレーションも非常に重要です。基本的には、机上シミュレーションとなりますが、実行に移る前に必ず行います。

　以上で第1回「データベースサーバー統合」は終わりです。今回は、お客さまにお話させていただいている内容を簡単にまとめさせていただきました。今後のシステム構想・構築に少しでもお役立ていただければ幸いです。