さて、第4回は、「Oracleライセンス管理のためのベースライン構築 その３」と題して、ベースライン構築に必要なOracleライセンス契約書や購入情報、インベントリ情報などライセンスのコンプライアンスを把握するために必要となる管理情報を関係者（ステークホルダー）から収集した後にどのようなポイントに注意してシステムに投入しベースラインを構築するのかを解説します。

目次

インスタンスに割り当てたライセンスがどのエディションなのか？

なぜ、ここまでの管理やコントロールが必要なのか？

まずは、基本となる「契約―保守契約―購入情報―割り当て」の関係性の管理について説明します。前回の「その２」で説明しましたが、サーバーの環境が仮想化される前は、物理サーバーに保守契約がひもづけられていれば、物理サーバーの廃棄のタイミングで保守契約を終了する作業で事足りていた時期がありました。しかし、今日の仮想環境においては、割り当てる対象が仮想マシン（VM）となり、Oracleインスタンスが使用する物理的なサーバーリソースがVMWare のようなハイパーバイザーによりダイナミックに変化したり、本番環境のインスタンスが物理サーバーを移動したり、待機系のインスタンスの設定によりライセンスの消費が大きく変わる可能性を持っているので、環境のコントロールとライセンス運用条件の交渉が重要になるということです。これらをコントロールし、できるだけシンプルな環境を運用することで運用管理の工数を極力下げて、運用負荷を最小化しながら、コンプライアンスを維持することが大切なのです。そのためには、以下の取り組みが必要となります。

• ① 契約はできるだけ数少なく
  エディションが異なる契約が分散していると、どのインスタンスにどの契約で購入した、どのエディションのライセンスを割り当てているのか管理が大変
• ② 割り当てたライセンスのエディションから条件を把握
  エディションによりサーバーのキャパシティ制限が異なるため、同じ物理サーバーに複数のエディションが存在する場合、異なるエディションでライセンス違反となるインスタンスとならないインスタンスが存在する
• ③ 変更管理には性能だけではなくライセンスの消費へのインパクトも考慮
  今までの変更管理はユーザーに直接影響する「性能」は考慮されていたが、「ライセンス消費」については責任の所在が明確ではなかったため、誰もコントロールしていなかった

コントロールするためには、以下の情報が求められます。

インスタンスに割り当てたライセンスがどのエディションなのか？

この情報は、購入情報の製品とエディションの情報から割り当て処理を行う際に引き継がれるようにします。この際にライセンスの契約および保守契約の両方の契約番号がひもづいている必要があるので以下のような契約番号と情報がひもづけられる必要があります。

例： 主契約番号－保守契約番号－発注書番号―購入製品名/エディション/ライセンス数

システムでは上記の関係性を管理するために、それぞれのエンティティと関係性が作成される必要があります。Oracle製品の場合はSKU（Stock Keeping Unit）番号がありませんので、製品名、バージョン、エディションなどが主契約の条件や保守契約の条件と一致していることを確認の上、購入形態として選択可能なフルキャパシティ、サブキャパシティ、NUPなどを選択してライセンスのエンティティを作成する必要があります。市販のSLO（Software License Optimization）ツールなどではOracle DB など主要製品に対してはライセンスエンティティを作成する際に参照でき、適用して必要であれば多少の変更を加えることで自社が契約した条件を作成することが可能です。しかし、ここで注意すべきは、「この作業は自動化できない」ということです。購入したライセンスがどのモデルで運用されるべきなのかは契約書で合意されたライセンスを理解して、ライセンスエンティティで指定する必要があります。運用者がライセンスエンティティを作成する際に、自社が選択したライセンスモデルを知っていてエンティティの条件を作成する必要があります。いったんライセンスエンティティが作成され、購入情報で入手された購入済みライセンス数を入力すれば、割当先のVMを選択し、割り当てるライセンス数をVMに割り当て、インベントリ情報が自動で突合された際にライセンス消費を計算しコンプライアンス状態を示してくれます。

ライセンスエンティティ＝ライセンスの条件：サブキャパシティモデル（コアファクタテーブルの条件などを含む）

ライセンスエンティティ（ライセンス条件）－ エンタイトルメント数＝ライセンス数

ライセンスエンティティが作成され、購入情報から購入済みライセンス数がわかるとエンタイトルメント数としてライセンス条件であるライセンスエンティティにひもづけられます。 ここでの注意は、ライセンスエンティティはライセンス条件なので、同じライセンス条件のライセンスエンティティを複数作成することは避ける、ということです。

例えば、Oracle DB Standardエディションの購入がプロジェクトや部門ごとに行われていると、同じライセンス条件のライセンスエンティティをいくつも作成してしまうことになります。主契約が異なる場合は、同じ条件のライセンスエンティティを複数作成して管理することが必要となりますが、これは非効率的ですし計算結果も不正確になります。なぜなら、異なるライセンスエンティティのライセンス消費は、それぞれライセンスエンティティごとに計算されてしまうからです。できるだけ契約を分散させず統合して、同じ条件のライセンスはひとつのライセンスエンティティで管理し、エンタイトルメント数だけを増やした方が効率的です。同じサーバー上に同じライセンス条件の異なるライセンスエンティティのエンタイトルメントを実装すると、ライセンス消費最適化のための条件を運用できなくなる可能性があるということを理解しておきましょう。

①と② の製品、エディション、ライセンス条件が同じであれば、ライセンスエンティティを複数作成せずに、一つにまとめて、エンタイトルメント数を増加させることで同じライセンスエンティティによるライセンス消費が計算されるので最適化が進みます。

前述の理由から、主契約となる契約を統合することがライセンス統合にもつながるので、契約は分散せずに統合することが効率化を促進します。

インベントリ情報は対象となる製品により必要な情報が異なります。いわゆるソフトウェアインベントリをインスタンスからインベントリエージェントで持ってくるというのは、インストールされ実行されているソフトウェアを把握するということでは有効ですが、製品によりライセンス条件が異なり、それにより管理メトリクスも異なり、必要となるインベントリ情報も異なるということを理解しておきましょう。

例えば、Oracle DB の場合だとDB Option はインストールする際に全てインストールされてしまいます。実際に使用したOption は課金対象となりTNS ファイルなどに記録されます。Oracle の監査ではこれらを対象とすることから複数のインベントリ収集ツールを用いてインベントリの提供が求められます。自社でコントロールしようとすると、これらの情報をOracle DBのインスタンスに対してSQLのポートなどに自動的にアクセスしTNSファイルを取得し、実際に実行されているOptionを特定する自動化システムが必要となります。多くのSLOツールがこれらに対応していますので、Oracle DBのOptionを使用する場合はこれらの機能を使った方が良いでしょう。Option の使用状態を把握し、本当にそのOption が必要で実行されているのかを評価することで、不要なOption の使用を停止し、無駄なライセンスの支払いを回避することが可能となります。 また、インスタンスにデプロイするサーバーエージェントによるソフトウェアインベントリの収集においても、製品名、バージョン、エディションなどの情報が必要となりますので、エディション情報まで収集しているサーバーエージェントなのかどうかを確認し、管理メトリクスを十分に収集しているかどうかの評価が必要です。 自社環境で使用するエディションが統一されていて Enterprise エディションしか使用していないのであれば、エディション情報を収集する必要はないかもしれませんが、複数のエディションが導入されていて、エディションを特定する必要がある場合は、インベントリ情報においてもエディションまで収集できた方が割り当て情報とインベントリ情報の突合の自動化が進むことからエディションまで収集してくれるサーバーエージェントでインベントリ収集した方が良いでしょう。

次に仮想環境における物理サーバーリソースの割り当て情報の取得です。サブキャパシティモデルのライセンスの場合は、OracleインスタンスがデプロイされているVMに割り当たっているリソースと、VMが実装されているサーバーの最大キャパシティなどはエディションにより制限が異なることから管理対象となります。VMWare であればvCenter にSOAP接続などを設定して定期的にリソースの割り当てに変化がないかを管理する必要があります。IBMのILMT（IBM License Metric Tool）の場合はインベントリ収集の設定が10分間隔など、ダイナミックな仮想環境でのサブキャパシティライセンスの管理における定期的に取得するインベントリ情報の頻度が高くなっています。これもライセンス契約交渉に必要となる重要な要素と考えられます。そこまで頻繁にインベントリを収集をしなくても常識的に環境の変化には変更管理プロセスが必須となりますので、自社の環境を変更する際の変更管理プロセスで定義される期間で明確に頻度が少ない場合は、交渉の可能性があります。しかし、一方でHA環境をダイナミックにコントロールできるようなVMWare/VCenter の環境では、製品自体がインテリジェンスを持ち、必要に応じて自動的に環境を変化させてしまう設定をしている可能性も否めません。これらのことから、Oracle は「Oracleインスタンスが稼働可能なプロセッサは全てライセンスを割り当てることが必要」と定義していますが、VMWareなどの環境での解釈によりライブマイグレーションや仮想データセンターなどでVMが自動的に最適な環境を選択して移動するような設定ですとデータセンターの設定スコープの全てのプロセッサでライセンスが必要、とされてしまうことがあります。これらを回避するためには、「Oracleを物理的なサーバーに閉じ込める」などの対応策などもありますが、これは時代と逆行し「なんのためにVMWareでダイナミックなHA環境を構築したのか？」ということにもなりますので、Oracleと交渉し、自社の環境をコントロールしているポイントを明らかにしてライセンスの消費対象となる環境を限定してライセンス消費をコントロールする方法に合意することが重要となります。

Oracle DB を対象としたインベントリ情報
• ① VMのソフトウェアインベントリ情報
• ② TNS ファイルなどOption情報
• ③ VMWare など仮想環境のリソース割り当て情報

これらのインベントリ情報はライセンスエンティティとVMに割り当てられたエンタイトルメント数に突合され、ライセンスエンティティで管理しているライセンス条件に基づいてライセンスの消費が計算され、割り当てられたエンタイトルメント数が必要十分かどうかを示してくれます。

なぜ、ここまでの管理やコントロールが必要なのか？

「コントロールして契約を統合し契約の管理工数を減らし、取得した情報を用いて契約交渉でコンプライアンスを定義し明文化する。それにより管理工数を減らし、コンプライアンスの維持を容易にする」ということが目的です。契約文書は書いた側のベンダーに有利に作成されています。さらに、複雑な文言の解釈は当然書いた本人の主張が裁判などでも有利です。

しかし、契約とは相互の利益となる条件の交渉による合意から生まれるものです。契約交渉に必要なデータがあれば、契約交渉は可能です。今日の複雑なIT環境では、ライセンスを運用する複雑な環境に対応してライセンス条件も非常に複雑になり、契約書を読んですぐに理解することは難しく、その条件を運用環境で管理することも困難を極めています。しかし、不可能ではないので、必要なデータを収集するためのプロセスの再設計や、必要なデータを持っているステークホルダーを巻き込んでデータをシステムに投入し、自動化ができる範囲はできる限り自動化して運用をシンプル化するために契約交渉を継続的に行い、複雑性をコントロールすることが重要なのです。もちろんVMO（Vendor Management Office）などの責任と役割を明確に定義し、これらのデータが有効活用されることが担保されることも重要です。

さて次回は、クライアント環境からサーバー環境まで幅広い製品と、最近のサーバー製品群のコアモデルへの移行で複雑化している「Microsoftライセンス管理のベースライン構築」について解説します。