Solaris/SPARCプラットフォームでOracleのライセンス費用を低減させる提言。

オープンソース慣れしている人はもちろん、ソフトウェア設備の見積もりを(社内外向けいずれかを問わず)作る人々にとって、Oracleのライセンス費用の高さは頭抜けて見えるものである。なにしろお安くない。だからといって、Oracleをやめられるかというと、レガシーとの関連, 安定性や機能などの要件, 開発者のスキルの都合や上司の無理解など諸々の理由からMySQLやPostgreSQLなどのオープンソースなデータベースに移行できないことが少なくなかったりする。

とりわけSolaris/SPARCなプラットフォームでは、これが莫迦みたいに高くなりがちで、これは何故かといえばCPUのマルチコア化が一つの要因。Oracleのライセンスの考え方(2009.06.16現在)では:

Oracle Price 2003

Processor定義によるライセンスカウント方法

ライセンスが必要なプロセッサ数をカウントする場合、オラクル製品がインストール、若しくは稼動する全ての「物理的」なプロセッサをカウントします。但し、ひとつのチップ上に複数のコアをもつ「マルチコア・プロセッサ」が搭載されているハードウェアでご利用いただく場合には、総コア数に係数を乗じた数（小数点以下端数切り上げ）が必要ライセンス数となります。

但し、各製品のStandard Edition、Standard Edition One*に関しては上記に関わらず、常にプロセッサが搭載されたソケット数が必要ライセンス数となります。

尚、これらの計算を適用できるライセンス単位はProcessor/プロセッサ/Named User Plusとなります。

• 更にコアの適用係数の詳細は「マルチコアプロセッサ利用時の必要ライセンス例、Oracle Processor Core Factor Table」をご覧ください。

ここで指示されているOracle Processor Core Factor Tableを見見るると、現在流通しているSPARCプロセッサの大半の係数が0.75換算。x86/x64系の大半は0.5という次第。しかも、SPARCプロセッサは2009年06月現在流通しているもので最低2コアから, これから先は4コア以上になるそうな。

従ってx86/x64アーキテクチャのCPUと比べるとどうしても割高になる。中小規模のMaterialized View Siteがいっぱいある環境だったりすると、もう大打撃。実はボク自身、ここ一年くらいこれですっかり頭を痛めていた……んだけど。

ここでSun Microsystemsから朗報、Best Practices for Running Oracle Databases in Solaris Containersというホワイトペーパーがリリースされた。この内容が、システム要件によっては劇的にライセンス費用を低減してくれる提言になっているので、嬉々としてご紹介。

つまりは:

Best Practices for Running Oracle Databases in Solaris Containers Page.7

Oracle License Model for Solaris Containers

Oracle now recognizes capped Solaris 10 Containers as licensable entities, known as hard partitions. Oracle customers running an Oracle database in a Solaris 10 OS environment can now license only the CPUs or cores that are in a capped Solaris container.

Oracle licensing policy defines hard partitioning as “a physical subset of a server that acts like a self-contained server” (for more details see reference [2]). The following example (Figure 2) illustrates how an 8-processor system can be partitioned into a 3- processor sub-system using Solaris Containers technology in the Solaris 10 OS.

(Figure 2は割愛)

Solaris system administrator needs to create a resource pool with the desired number of CPUs or cores and bind a zone to this resource pool. Alternatively, the administrator may set up a zone to use dynamic pool with specified CPU maximum limit. The license is driven by the number of CPUs or cores in this pool.

ざっくりと、ボクなりに訳すと次のような次第。(誤訳もあるかもしれないので、見つけたらそっと優しく教えていただければ幸いである)

Solaris Containers向けのOracleライセンスモデル

OracleはSolaris 10 Containers上でハードパーティショニングされたエンティティに対するライセンス対象に上限を認めた。OracleデータベースをSolaris 10 OS環境で動かしている顧客は、Solaris Containerに上限として定めたCPUもしくはコア数に応じただけのライセンスでOracleを稼働させることができる。

Oracle licensing policyはself-containedなサーバが稼働する物理的なサーバのサブネットとして、ハードパーティショニングを定義する。(より詳しくは、Reference 2を参照のこと) 例えば図表 2のケースでは、Solaris 10 OS上で、8プロセッサのシステムを、Solaris Containerにより3プロセッサのサブシステムとして分割している。

(Figure 2は割愛)

Solarisシステム管理者は、resource poolを作成し要求されるCPUもしくはコア数をそのresource poolに対して結びつける。あるいは、管理者は最大CPU数が指示された動的なプールにzoneを作成してもかまわない。ライセンスは、このプールに割り当てられたCPUもしくはコア数から決まる。

つまり、ここで挙げられている例の場合、従来であれば8プロセッサ分のOracleライセンスを購入しなければならなかったけれど、Soalris Containerであえて3プロセッサに制限したresource pool上で動かす限りにおいて3プロセッサ分のライセンスで大手を振ってOracleを動かすことができる、ってわけ。当然、余らせたCPUの分の性能は無駄になるわけだけど、そのあたりは他に転用してもいいわけだしね。とりあえずハードウェアの性能が無駄に高いせいで、余分にライセンスを購入しなければならない、なんてナンセンスな状態はこれで解消される。

このホワイトペーパーでは、具体的にSolaris Containerを作って、CPU/コアの割当を実際に行って……という実例もコマンドラインまで含めて掲載/解説してくれている様子。(まだそのあたりはちゃんと目を通していないのだけど)

そんなわけで、Solaris 10の管理者はぜひとも一読をオススメしたい次第なんである。

……Oracleの営業さんは、正直、いい顔しないかもしれないけどさ。