高可用性を実現する11g R2の接続、サービスのアーキテクチャ

1. ポリシー管理型データベースとSCAN

　11g R2のGrid Infrastructureでは、「ポリシー管理型データベース」という新しいRACデータベースの構成タイプが導入されています。 従来は、インスタンスが起動するサーバーは固定されており、インスタンスの起動数や配置先サーバーを柔軟に変更できませんでした。 「ポリシー管理型データベース」では、インスタンスとサーバーの関連付けはなくなり、インスタンスの起動数や配置先サーバーを柔軟に変更出来るようになっています。 なお、11g R2では、11g R1以前で使用されていた従来のRACデータベース構成タイプを「管理者管理型データベース」と呼ぶようになっており、「ポリシー管理型データベース」と区別しています。

　また、11g R2ではSCAN (Single Client Access Name) という新しい接続方式が導入されました。 SCANを使用すると、クラスタを構成するサーバーが増減したり、インスタンスの配置が変更されても、接続に関わる設定のメンテナンスが不要となります。従来は、これらに合わせて、クライアントとデータベースの接続に関わる設定をメンテナンスする必要がありました。

　本稿では、ポリシー管理型データベースの概要と管理者管理型データベースとの差異、 またSCANの概要とメリットについて説明します。

2. ポリシー管理型データベースとサーバープール

　クラスタ管理の柔軟性を高めるためには、データベース（インスタンス）が稼動するサーバー数を簡単に増減できる必要があります。また、インスタンスがどのサーバーで起動するかを変更できる必要もあります。 従来のRACデータベース、すなわち管理者管理型データベースでは、データベースを構成するインスタンスが特定のサーバーと密接に関連付けられているため、インスタンスが稼動するサーバー数を簡単に増減することができませんでした。また、インスタンスがどのサーバーで起動するかを簡単に変更できませんでした。

　一方、ポリシー管理型データベースは、インスタンスが特定のサーバーと密接に関連付けられておらず、追加したサーバーに自動的にインスタンスを構成できる機能があるため、データベースを稼動するサーバー数が簡単に増減できるようになっています。また、インスタンスがどのサーバーで起動するかを簡単に変更できます。

　インスタンスとサーバーの関連付けを排除するため、11g R2からはサーバープールという概念が用意されました。サーバープールは、概念的にはクラスタに含まれる複数のサーバーをグループ化して名前をつけたものです。サーバープールは柔軟な定義が可能になっており、サーバー名を指定せずに作成することもできます。この場合、Oracle Clusterwareが自動的にサーバープールにサーバーを割当てます。

　そして、ポリシー管理型データベースを作成する場合は、あらかじめ作成した1つ以上のサーバープールを指定します。インスタンスとサーバーの関連付けを排除するため、サーバー名は指定せず、サーバープールのみを指定します。すると、サーバープールに含まれる全てのサーバーで自動的にインスタンスが構成され、起動します。（データベースを構成するファイルの格納にASMを使用し、ファイル構成方法としてOMFを使用することが必要です）

　11g R2で提供されているサーバープールの種類は以下の通りです。

　ユーザー定義のサーバープール

　ポリシー管理型データベースを配置するために明示的に作成したサーバープール。 サーバー数の最小値と最大値、割り当ての重要度を指定します。サーバープールに含まれるサーバー名を指定することもできますが、必須ではありません。

　Genericサーバープール

　管理者管理型データベースや11g R1以前のデータベースリソースの配置に利用される特殊なサーバープール。 デフォルトで構成済みであり、削除できません。

　Freeサーバープール

　Oracle Clusterwareが動的に割り当て可能なサーバーを配置したサーバープール。 各ユーザー定義のサーバープールの優先度や最小値の値に応じて、Oracle ClusterwareがFreeサーバープールからサーバーを割り当てます。

　なお、1つのクラスタにポリシー管理型データベースと管理者管理型データベースを共存させることもできます。管理者管理型データベースを作成すると、インスタンスを構成したサーバーはGenericサーバープールと呼ばれる特殊なサーバープールに登録され、ポリシー管理型データベースでは使用されないようになります。

　Freeサーバープールはユーザー定義のサーバープールでサーバーが不足した場合に使用されます。 たとえば、図2のように、ユーザー定義のサーバープールに割当てられたあるサーバーに障害が発生した場合、Freeサーバープールに属するサーバーが追加されます。必要に応じて追加されたサーバーでインスタンスが起動され、起動インスタンス数を維持しようとします。

　このように、インスタンスの起動数やインスタンスが配置されるサーバーを柔軟に変更出来るようになっているため、クラスタ管理の柔軟性を高められます。