複雑化するデータセンターのIT資産管理システム構築への挑戦

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

さて、第9回は、「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の制限に注意! 最大2CPUという上限が設定された条件は、物理的なサーバーに実装されるCPUが2CPUであるか、または、ハードパーティションで2CPUの設定である必要があります。VMWare で2CPUの割り当てになっていても、1物理サーバー上のCPU数が2CPU以上であればライセンス違反となります。1物理サーバー上のCPUが2CPUで、2CPUのブレードが3枚あり、合計が6CPUで、この2CPUx3=6CPUがクラスタ化されている場合で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を間接的に使用するユーザーとしてユーザーライセンスが必要となります。アクセスする間接システムは1ユーザーライセンスとして勘定していたとしても、そのシステムにアクセスする市場ユーザーが20万人いれば、実際のNUPライセンスは20万ユーザーライセンス必要となります。

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

以下に、IT資産管理システムのRFI/RFPのポイントをまとめた資料ダウンロードサイトをご紹介しますので参照してください。 再配布の際は出典を「国際IT資産管理者協会:IAITAMより」と明示して利用してください。

IT資産管理システム RFPたたき台 基本要求事項
http://files.iaitam.jp/2017ITAMAutomationSystemRequirement.pdf

IT資産管理システム RFP項目と機能項目概要
http://files.iaitam.jp/2017RFPItemAndDescription.xlsx

国際IT資産管理者協会 フォーラムサイト メール会員登録だけでフォーラムサイトのホワイトペーパー、プロセステンプレート、アセスメントシートなどダウンロードが可能!
http://jp.member.iaitam.jp/

連載一覧

コメント

筆者紹介

武内 烈(たけうち たけし)
1964年生まれ。
一般社団法人
日本ベンダーマネジメント協会
代表理事
ITIL Expert、IAITAM認定講師

IT業界では主に外資系ソフトウェアメーカにおいて約25年間の経験を持つ。
技術的な専門分野は、ネットワークオペレーティングシステム、ハードウェアダイアグノスティック システム、ITマネジメントと幅広い。大手外資系IT企業ではプロダクトマーケティングスペシャリストとして、ITマネジメントの分野で、エンタープライズJavaサーバー(WebLogic、WebSphere)、SAP、Oracle、ESB(Enterprise Service Bus)などからWeb Serviceテクノロジーまでの管理製品を手掛ける。
IT 資産ライフサイクル管理プロセス実装のためのAMDB・CMDB 製品開発プロジェクト、データセンターのCMDB およびワークフローの実装プロジェクト、IT資産管理(クライアント環境) MSP のサービスプロセスの開発・実装プロジェクト(CMS/サービスデスクを含む)、ライセンス管理のためのSAMプロセスおよび自動化テクノロジー (CMS/サービスデスク)の設計・実装プロジェクトなど多数のプロジェクト経験を持つ。
IT資産管理のポリシー、プロセスを、どのように自動化テクノロジーに結び、ITサービス管理戦略やロードマップとの整合性を取りながらIT資産管理プログラムを実行性の高いものにしていくのかのコンサルティングを得意とし、大手組織におけるIT資産管理プロセスとサービス管理プロセスの統合プロセス設計、自動化設計、実装プロジェクト、IT資産管理プログラムの運用教育の実績多数。

 

【ホームページ】
一般社団法人
日本ベンダーマネジメント協会
www.vmaj.or.jp/
【情報】
Twitter( @VMA_Japan)


バックナンバー