第9回：VMWare環境における Oracleライセンス監査の実態と対策（前編）

さて、第９回は、「VMWare 環境における Oracle ライセンス監査の実態と対策（前編）」と題して、前後編2回に分けてデータセンター環境におけるライセンス監査で大きな課題となるVMWareで構築された仮想サーバー環境を対象とした監査の実態と対策について代表的なOracleライセンス監査を例に解説します。

最初になぜ、Oracle DBとVMWareを組み合わせたライセンス管理が困難なのか、そして、監査対象としてターゲットになりやすいのかを簡単に説明します。

第一のポイントは、Oracle のライセンス契約にあります。 Oracle社はVMWareを正式にソフトパーティショニング技術の対応として定義していません。つまり、契約書の文中にある文言を理解し、解釈を適用しなければならないのです。具体的には、同社の契約書にある「インスタンスが稼働する範囲のCPUをライセンスしなければならない」を理解し、VMWareの環境を理解した上で、解釈としてライセンスが必要となる範囲を自ら判断して管理する必要があるということです。

第二のポイントは、VMWareのバージョンの違いによるインスタンスの稼働可能範囲の違いです。 これは第一のポイントの「インスタンスが稼働する範囲のCPUをライセンスしなければならない」をVMWareのバージョンの違いを考慮したうえで解釈しなければなりません。

第三のポイントは、Oracleのライセンスモデルです。 エディションには、スタンダードとエンタープライズの種別があり、スタンダードエディションには使用するサーバーの物理的なキャパシティの制限があります。プロセッサライセンスを利用する際に、サブキャパシティモデルのつもりでいても、VMWareを使用するとフルキャパシティで課金されます。

第四のポイントは、特にライセンス管理がIT運用チームにとって困難な理由ですが、Oracleの契約情報や購買情報が手元にないこと。 さらには、これらの情報の所有者が協力的でない場合もあること。そして、これらの情報を取得しても有効な管理システムを構築するために必要となる十分なインベントリ情報の取得が困難であることがあげられます。

次に、第二のポイントであるVMWareのバージョンの違いによるインスタンスの稼働可能範囲の違いをより具体的に説明します。

① VMWare 5.0
クラスタ内でインスタンスが動的に移動し消費リソースを変更できることから、オラクルのインスタンスはクラスタ内の全てのCPUをライセンスする必要がある。

② VMWare 5.1以降
ひとつのvCenter下で管理される全てのクラスタにおいて、インスタンスがクラスタをまたいで動的に移動し、消費リソースを変更できることから、オラクルのインスタンスは、当該vCenter下でコントロールされる全てのCPUをライセンスする必要がある。

③ VMWare 6.0
複数のvCenter下で管理される全てのクラスタにおいて、インスタンスがクラスタおよびvCenterをまたいで動的に移動し、消費リソースを変更できることから、オラクルのインスタンスは、全てのvCenterで管理される全てのCPUをライセンスする必要がある。

そして、これに第三のポイントであるライセンスモデルの考慮を加えます。

① スタンダードエディションのキャパシティモデル
物理的な最大CPUの制限に注意！ 最大２CPUという上限が設定された条件は、物理的なサーバーに実装されるCPUが２CPUであるか、または、ハードパーティションで２CPUの設定である必要があります。VMWare で２CPUの割り当てになっていても、１物理サーバー上のCPU数が２CPU以上であればライセンス違反となります。１物理サーバー上のCPUが２CPUで、２CPUのブレードが3枚あり、合計が６CPUで、この２CPUｘ３＝６CPUがクラスタ化されている場合でVMWareが5.0であれば、クラスタ内の3サーバーがライセンスされていればスタンダードエディションの使用は可能です。しかし、一般的に考えればスタンダードエディションはVMWare環境で使えないと考えた方が良いでしょう。

② エンタープライズエディションのキャパシティモデル
VMWareの環境でエンタープライズエディションを使用する場合に、キャパシティモデルかNUPいずれかのモデルに統一されていなければなりません。スタンダードエディションなどは物理サーバーに閉じ込めるなどして、仮想環境から分離させておくことも注意すべきポイントです。また、一般的にVMWareの環境であれば前述のバージョンの違いにより各バージョンのフルキャパシティで課金される可能性が高いので、サブキャパシティで運用するためには、ライセンスの運用環境を正確に把握し、契約交渉の際に、ライセンスの消費・運用条件などで合意することが大切です。つまりVMWare 6.0などで運用する場合は、「すべての仮想環境のCPUをライセンスしてください」とならないようにDRS Hostアフィニティルールなどで待機系などの移動利用範囲を制限することで対象となるライセンス消費のCPUの範囲を制限し、合意することが必要です。それをするためには正確なライセンスの割り当て情報とライセンスの消費を測定するインスタンスに割り当てられたリソースの情報などが不可欠となります。

③ NUP の間接ユーザー
最初に注意するべきはシステムとしてアクセスしてくるシステムのエンドユーザーの範囲です。つまり、Oracle DBにアクセスする直接ユーザーではないが、Oracle DBを使っているシステムにアクセスする間接ユーザーを指します。最近は、Webシステムなど自社組織外のエンドユーザーなどに開いたシステムなどが増えています。そのシステムがOracle DBなどを使用している場合、システムにアクセスする間接ユーザーは全てOracle DBを間接的に使用するユーザーとしてユーザーライセンスが必要となります。アクセスする間接システムは１ユーザーライセンスとして勘定していたとしても、そのシステムにアクセスする市場ユーザーが20万人いれば、実際のNUPライセンスは20万ユーザーライセンス必要となります。

次回の後編では、「ライセンス契約」がコントロールできない要因や、ライセンス監査が戦略的に来る理由と対策を解説します。