Oracleのライセンス数を抑える方法
前回、Oracleライセンスについて簡単にまとめた。
今回はOracleライセンスを最も抑える方法を調べてみた。
前提としては仮想インスタンス単位ごとにOracle DBを扱うことを前提としました。
ゾーン集約など、ひとつのOSにDBを集約したりは考慮しません。
いきなり結論
Oracleライセンスを最も抑えることができるのは、
ハイパーバイザーにOracle VMを選択し、オンプレミスで構築すること
でした。
Oracle VMはOracleがリリースしているxenベースのハイパーバイザーです。
他のハイパーバイザーとはライセンスのカウント方法が違う。
Oracle VM以外のハイパーバイザーの場合
例としてvSphereを利用している場合、OracleDBが稼働しうるサーバの物理プロセッサーを見る。
SE2の場合・・・Active 2ソケット+Standby 2ソケット =合計4プロセッサーライセンス
EEの場合・・・Active 16コア×0.5(係数) + Standby 16コア×0.5(係数) = 合計16プロセッサーライセンス
EE高すぎるので、ちょっと現実的ではない。
Oracle VMがハイパーバイザーの場合
同様にOracle DBが稼働しうるサーバの物理プロセッサーを見るが、待機系はカウントしない。
SE2の場合・・・Active 2ソケット=合計2プロセッサーライセンス
EEの場合・・・Active16コア ×0.5(係数) = 8プロセッサーライセンス
仮にOracle DBが通常時動いている物理サーバが一台増えて合計3台になった場合は、増えた一台はActiveとしてそのサーバのプロセッサー分もライセンスが必要。
AzureやAWSと比較した場合(EEの場合)
話を簡単にするために2vCPU(コア)のOracle DBインスタンスを順次増やした場合の比較表は以下のような感じになる。
コア係数を0.5とし、物理サーバは一台あたり16コア搭載(オーバヘッド除外してます)。待機系を一台常備。物理サーバの全てのコアリソースを使い果たしたら物理サーバを一台追加してそれにかかるOracle EEライセンスを追加購入した場合。
16ごとにライセンス数はおいつきますが、基本的にAzure AWSよりはライセンス数を抑えられる。
Oracleのライセンスについてまとめてみる
Oracleのライセンスについてのおぼえがき
Oracleライセンスの種類
2017年3月時点で主に二種類
Standard Edition 2(SE2)とEnterprise Edition(EE)
機能の豊富さではSE2 < EEなので、EEはめちゃくちゃ価格が高い。
また、Oracle Databaseが稼働するサーバの物理プロセッサー(ソケット)数で必要なライセンス数が決まるプロセッサーライセンスとデータベースを利用するユーザー数でライセンス数が決まるNamed Userライセンスがある。
基本的にはプロセッサーライセンスを利用することが多い。
プロセッサーライセンスの考え方
プロセッサーライセンスは利用する基盤およびライセンス種類で数え方が変わってくる。
オンプレミスサーバの場合
オンプレミスサーバでSE2ライセンスを利用する場合、Oracle Databaseが稼働しうる全ての物理サーバ上のCPUソケット数をカウントする必要がある。
一方、EEライセンスを利用する場合、Oracle Databaseが稼働しうる全ての物理サーバ上のCPUコア数をカウントする必要がある。
ただし、CPUのメーカーなど種類によって最後に掛け算する係数たるものが存在し、多くのCPUは0.5という係数が当たっている。
最近の機器だと2ソケット、32コア、64スレッドなどなど。EEだとめちゃくちゃ高くなるが・・・
SE2であれば2ソケットなので2ライセンス、EEであれば32×0.5=16ライセンス、といった計算になる。
パブリッククラウドの場合
現在、Oracleが利用を許諾しているパブリッククラウドはAWSおよびAzureしかない。
これについて、2017年3月時点でのライセンス数の考え方はシンプルで、ハイパースレッドなど関係なくOracleが稼働する仮想インスタンスの仮想コア数(vCPU数)分のライセンスが必要となる。
なのでAWSではハイパースレッド有効にした方が同じvCPU数でも必要ライセンス数は半分か。
Named Userライセンスは滅多に出てこないからいいや。
WindowsによるOSベースの可用性と冗長性についてまとめてみる
Windowsの冗長性、可用性の機能についてまとめてみます。
用語の整理
MSFC、MSCS、WSFC、NLB・・・調べるといろいろあるけど代表サービスは結局は二つだけでした。
MSFC(Microsoft Failover Cluster)とMSCS(Microsoft Clustering Service)とWSFC(Windows Server Failover Cluster)は全て同じ機能を指していて、クラスタリングサービスの呼称。
MSCSはWindows Server 2003 R2までの呼び名。
現在はMSFCおよびWSFCのどちらかが用語として使われるらしい。
NLB(Network Load Balancing)は、負荷分散機能の名前。
MSFC
クラスタリングサービスは、Active-Passive構成を実現する。クライアント-サーバ-ディスク間の可用性を向上させる。
サーバが壊れた場合、Cluster IPの振り先とディスク認識をするサーバを切り替える。
※ディスクの可用性はディスク側の別機能で向上させる必要あり。
NLB
負荷分散サービスは、クライアントPC-サーバ間の可用性と負荷分散を実現する。あるサーバが壊れた場合はVIPから正常動作しているサーバへのみ振る。
下の画像のような構成の場合、複数のサーバが一つの共有ディスクにアクセスできるような構成には向いていないため、各サーバが独立したディスクを持つような場合には向いている。
データベースがいい例
Oracleがいい例のようです。
Oracleには主に3つの可用性、冗長性の向上方法がある。
Oracle RAC(Oracle Real Application Cluster)とは
NLBの機能とFC(Failover Cluster)の両方の機能を同時に実現する。すごい。
Failover Clusterの従来の実現方法は、共有ディスクへのアクセスを常に一つのサーバからのみに限定するものの、そのアクセス許可サーバをうまく切り替えることで実現していた。
しかしOracle RACの場合は、一つのディスク(Oracle Database)に複数のサーバが同時にアクセスをすることを許可し、ディスクへの操作がバッティングしても排他制御をうまく働かせることで整合性を維持することができる。
Oracle Fail Safeとは
Oracle DatabaseにMSFC対応をさせるもの。つまりは上述したクラスタリングサービスを指す。
Oracle Data Guardとは
データベースのREDOログとある時点でのバックアップを遠隔地保存するサービス。
REDOログとは過去のある時点から先に進める操作ログのこと。
UNDOはある時点から後ろへ戻す操作ログ。
ひとまずのまとめ。
