RAC One Node の検証その１

＜RAC One Node の検証その１＞
ペンネーム : ダーリン

さてさて、長らくの関西遠征から帰ってきました。
今回のテーマは RAC One Node 。

その名前の通り、RAC なんだけどアクティブノードはひとつだけと
いうデータベースです。

ご存知の方も多いかもしれませんが、まずはどんな特徴があるかを
簡単に整理しておきます。まずは、RAC から。

RAC の特徴：

- 単一のデータベースに対して、複数のインスタンスがある。
これらのインスタンスは同一のデータにアクセスできる。
- RAC を構成しているノードは通常すべてアクティブである。
- 万一特定のノードで障害が発生しても、影響はそのノードに接続
しているセッションのみに限定され、しかも通常は再接続するだ
けで正常稼働しているノードに再接続されるため、ダウンタイム
はごく短時間。
(他のノードはダウンしないためサービス停止にはならない。)
- どちらかというと CPU ボトルネックになりがちなシステムに向
いている。(各ノードで処理を分散できるという意味です)
- Enterprise Edition の場合、ノード数分の RAC オプションが必
要。
- Standard Edition の場合は制限があるが、 RAC オプションは不
要。

RAC One Node の特徴：

- 単一のデータベースに対して、1 インスタンスの構成。
- RAC One Node を構成しているノードはその名の通り、1ノードだ
け。
- ノードを複数立ち上げてそれぞれに RAC One Node のデータベー
スを立ち上げることは可能。
- ひとつのノード内に複数の RAC One Node のデータベースを立ち
上げることも可能
- 稼働中のノードで障害が発生した場合は、当然そのノード上のサー
ビスは停止する。スタンバイ側ですぐに起動させることは可能。
- Enterprise Edition 版のオプション。Standard Editionでは使え
ない。
- Enterprise Edition のライセンスと、RAC One Node ライセンス
が必要。
- スタンバイ用のノードが必要。
ただし、スタンバイ側のライセンスは制限内であれば無償。

RAC 以外のサーバ構成を含めて比較すると以下のようになります。
※ ダーリン基準

               EE RAC SE RAC RAC ON   HA   Single
-------------- ------ ------ ------ ------ -------
パフォーマンス   ◎     ○     △     △     △
ダウンタイム     ◎     ◎     ○     △     ×
HWコスト         △     △     △     △     ○
SWコスト         ×     ○     △     ○     ◎
運用コスト       △     △     ○     △     ◎
拡張性           ◎     △     ◎     ×     ×
-------------- ------ ------ ------ ------ -------
※ RAC ON = RAC One Node

◎：いい感じ ○：おおむねＯＫ △：まあまあ.... ×：いまいち

総じて RAC One Node には下記のような特徴があります。

・RAC ほど パフォーマンスアップやダウンタイムの極小化に貢献
するわけでもないが、 HA やシングルインスタンスのサーバより
も可用性は高い。
・RAC のように処理を分散できるような複数ノード構成ではないが、
今後の拡張性は高い。

上記からは、よく言えば中庸、悪く言えばどっちつかずのような感
じがします。たとえば「これぞ RAC One Node だっ !! 」というよ
うな目立った点が見当たりません。

ただ、別の視点で見た場合に非常に大きな可能性を感じるのも事実
です。

……..

昨今のITインフラの大きな話題のひとつは、やはりコスト削減を背
景としたサーバ統合でしょうか。RAC One Node はそのサーバ統合
にひとつの方向性を提供してくれています。サーバー統合について
簡単に振り返ってみます。

サーバ統合に関する詳細な解説は別に譲るとして、さまざまなデー
タベースを統合するというプロジェクトはそれなりにハードルが高
いのが現状です。

データベースサーバに着目すると以下のようなことが言えるのでは
ないでしょうか。

1) 物理サーバを論理サーバに置き換えて統合する、いわゆる
「仮想化」
2) 単一の物理サーバ内に複数のデータベースを共存させる、
「データベース共存」
3) 複数のデータベースを単一のデータベース内に納めてしまう、
「データベース統合」

通常、これらの統合のレベルは上から順に下に向けて難易度が上が
ってきます。

最後の「データベース統合」に至っては、作業コスト、スケジュー
ル、リスクの大きさ、いずれをとっても安易に着手できる類のもの
ではないでしょう。セキュリティーを考慮すればむしろ逆に分割し
たいデータベースも存在します。

とはいえ、運用コスト削減も至上命題となっている今、サーバの統
合を避けることもできません。となると、いわゆる「仮想化」が非
常に魅力的な解決策に見えて来るのですが、しかしこれでは物理サー
バ数自体が減少するものの、管理対象のサーバが減るわけではあり
ません。
つまり、運用にまつわるもろもろ（パッチ適用、ユーザアカウント
管理、リソース監視、障害対応 etc.）は付いて回るわけです。
サーバ統合は HW や OS を減らすだけではなく、さらに、それにま
つわる運用コストも削減するのが狙いです。
よって、、、「可能な限りサーバ数自体も減らしたい。」

となると次のステップへとレベルが上がっていきます。
次は「データベース共存」です。

具体的には ORACLE_HOME を複数用意し、それぞれを使ってデータ
ベースを立ち上げる方法や、ORACLE_HOME も共有してデータベース
を構築する（インスタンスを分ける）方法があります。
この構成はいわゆるシングルインスタンス構成のデータベースが統
合サーバ内に集約された状態です。

これには少しシビアな問題も付いてきます。可用性です。

統合したデータベースの重要度によっては、可用性を確保する必要
があります。統合によってこれまで分散されていたリスクが集まっ
ていますので万一障害が発生した場合のインパクトは、それはそれ
はもう……

これに対するソリューションとして、ダウンタイムなしを謳ってい
る RAC 程ではないが、HA よりも短時間でサービス復旧させること
ができ、しかも、必要とあらば今後の拡張性に魅力を残した RAC
One Node のよい意味で中庸な性格がピタッとはまるのではないで
しょうか。

というわけで、このシリーズでは RAC One Node はどんなふうに使
えるのかを見ていきたいと思います。

まずは、RAC One Node が手元にあったらまず試したくなる、
Omotion から。

$ Omotion
ERROR: Grid Infrastructure doesn't appear to be running on this machine.
Contact your clusterware administrator.
Exiting...

っとっと。あわてない、あわてない。

次回からゆっくりと検証していきましょう。

RAC One Node の検証 その１