Oracle19c以降のOracleDB冗長化方式の選択肢

### はじめに


　Oracle19cが発表されしばらくたちますが **[Oracle SE RACの非サポート](https://support.oracle.com/knowledge/Oracle%20Database%20Products/2561913_1.html)**、**[Oracle Faile Safe（OFS）の非推奨化](https://docs.oracle.com/cd/F19136_01/ntqrf/deprecation-of-oracle-fail-safe.html)** とOracleDB冗長化の実現方法にインパクトのある情報も多くありました。若干いまさらですがOracle19cにおけるＤＢ冗長化パターンを比較してみました。
　また、独断と偏見で、コスト、可用性、将来性、構築容易性について★で評価をつけてみたので、皆さんのご参考になれば幸いです。


## １．OS仮想化(Soft Partitioning)を活用した冗長化
##### コスト★☆☆、可用性★★☆、将来性★★★、構築容易性★★★、Active/Standby


VMWare やHyper-V等による冗長化です。

　Oracleの構築としてはシングルインスタンスを構築するだけなので非常に容易に構築が可能ですが、プロセス障害などの復旧には対応しておらず、HW故障時にはOS再起動による復旧になるため可用性は若干落ちます。
また、Oracle DataBaseの **[ライセンスは物理サーバ台数分](https://faq.oracle.co.jp/app/answers/detail/a_id/2673/~/%E3%82%B5%E3%83%BC%E3%83%90%E3%83%BC%E4%BB%AE%E6%83%B3%E5%8C%96%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2%EF%BC%88-oracle-vm-%E3%80%81vmware%E3%80%81hyper-v%E3%81%AA%E3%81%A9%EF%BC%89%E3%82%92%E4%BD%BF%E7%94%A8%E3%81%97%E3%81%9F%E5%A0%B4%E5%90%88%E3%81%AE%E3%83%A9%E3%82%A4%E3%82%BB%E3%83%B3%E3%82%B9%E3%82%AB%E3%82%A6%E3%83%B3%E3%83%88%E3%81%AF%E3%81%A9%E3%81%AE%E3%82%88%E3%81%86%E3%81%AB%E3%81%AA%E3%82%8A%E3%81%BE%E3%81%99%E3%81%8B%EF%BC%9F)** かかるのでOracleライセンスにかかるコストは比較的高くなります。


## ２．OS仮想化(Hard Partitioning)を活用した冗長化
##### コスト★☆☆、可用性★★☆、将来性★★★、構築容易性★★★、Active/Standby

　基本的には１とのSoft Partitioningと同じです。

　Oracleの構築としてはシングルインスタンスを構築するだけなので非常に容易に構築が可能ですが、プロセス障害などの復旧には対応しておらず、HW故障時にはOS再起動による復旧になるため可用性は若干落ちます。
また、Soft Partitioning のOS冗長化と異なり **[Oracle DataBaseのライセンスは仮想OS分しか必要ありません](https://faq.oracle.co.jp/app/answers/detail/a_id/2673/~/%E3%82%B5%E3%83%BC%E3%83%90%E3%83%BC%E4%BB%AE%E6%83%B3%E5%8C%96%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2%EF%BC%88-oracle-vm-%E3%80%81vmware%E3%80%81hyper-v%E3%81%AA%E3%81%A9%EF%BC%89%E3%82%92%E4%BD%BF%E7%94%A8%E3%81%97%E3%81%9F%E5%A0%B4%E5%90%88%E3%81%AE%E3%83%A9%E3%82%A4%E3%82%BB%E3%83%B3%E3%82%B9%E3%82%AB%E3%82%A6%E3%83%B3%E3%83%88%E3%81%AF%E3%81%A9%E3%81%AE%E3%82%88%E3%81%86%E3%81%AB%E3%81%AA%E3%82%8A%E3%81%BE%E3%81%99%E3%81%8B%EF%BC%9F)** が、Hard PartitioningができるHardWareは比較的高価なのでコストはそれなりにかかります。

## ３．Oracle19c Oracle Fail Safe(OFS)
##### コスト★★☆、可用性★★☆、将来性☆☆☆、構築容易性★★☆、Active/Standby

　2つのサーバにOracleDataBaseをインストールしOracle ClusterWareのインストールおよび設定が必要なので構築難易度はやや高めです。プロセス障害などの復旧にも対応していますが、フェールオーバー時にはOracleインスタンスの再起動が発生するためダウンタイムがあり、可用性は100%ではありません。Oracle Database Standard Editionでも構築が可能で **[フェイルオーバー構成になるため待機サーバ分のライセンスは不要](https://faq.oracle.co.jp/app/answers/detail/a_id/2637/~/ha%E6%A7%8B%E6%88%90%E3%81%AB%E3%81%8A%E3%81%91%E3%82%8B%E3%83%A9%E3%82%A4%E3%82%BB%E3%83%B3%E3%82%B9%E3%82%AB%E3%82%A6%E3%83%B3%E3%83%88%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6)** なためOracle Data Baseライセンスは安価ですみますが、サーバー2台とiSCSI等の共有ディスクが必要になるためHWコストは若干かかります。
　また、Oracle社より **[Oracle19cではOFSは非推奨](https://docs.oracle.com/cd/F19136_01/ntqrf/deprecation-of-oracle-fail-safe.html)** と案内が出ており将来性に不安があるため、同一サーバ構成でOracleのバージョンアップを考えている場合は採用を控えたほうが良いと思われます。


## ４．Oracle Real Application Cluster  (RAC)
##### コスト☆☆☆、可用性★★★、将来性★★★、構築容易性★☆☆、Active/Active
　これまで紹介した構成に比べると、複数サーバへのOracleインストール、複数IPアドレスの準備、ASM共有ディスクの準備など、DBの構築難易度は最も高いです。プロセス障害にも対応しており、フェールオーバー時にもDBのダウンタイムがないため可用性はピカイチと言えます。
　冒頭で案内した通り、Oracle 19cからはSE RACがサポート対象外になりRACを組む場合はEnterPriseEditionが必須になったためOracleDataBaseのライセンス費用は最も高くなりますし、iSCSI等の共有ディスクが必要になるためHWコストもかかります。
　
私見ですが、これまでの冗長化機能のサポート打ち切りの方針を見ているとRACに力を入れているように見えるので、将来性については問題ないと思われます。

## ５．Oracle19c Standard Edtion High Availavility（SEHA)
##### コスト★★☆、可用性★★☆、将来性★★★、構築容易性☆☆☆、Active/Standby

　Oracle19cからサポートされた構成ですが、RACのアーキテクチャを利用したActive/Stanby構成。RACとOFSを足して2で割った感じという印象です。

　構築では複数サーバへのOracleインストール、複数IPアドレスの準備、ASM共有ディスクの準備等、DBの構築難易度は最も高く、また情報や実績もまだ少ないため個人的にRACよりも難易度を高く設定しました。
　プロセス障害にも対応していますが、フェールオーバー時にはインスタンスの再起動が発生するため可用性はOFSとほぼ同じと考えてよいでしょう。コスト面ではこちらも **[フェイルオーバー構成となるためOFSと同じく待機サーバのOracleライセンスは不要](https://faq.oracle.co.jp/app/answers/detail/a_id/2637/~/ha%E6%A7%8B%E6%88%90%E3%81%AB%E3%81%8A%E3%81%91%E3%82%8B%E3%83%A9%E3%82%A4%E3%82%BB%E3%83%B3%E3%82%B9%E3%82%AB%E3%82%A6%E3%83%B3%E3%83%88%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6)**  、HW構成もほぼ同じ条件になるためOFSと同じと言えます。Oracle19cからサポートされだした構成なので将来性もしばらくは問題ないでしょう。

## ６．Oracle19 CDB/PDBホットクローン
##### コスト★★☆、可用性★☆☆、将来性★★★、構築容易性★☆☆、Active/Standby

　こちらは若干トリッキーな構成になります。**[テスト環境利用で使うことを想定されたPDBクローン機能](https://docs.oracle.com/cd/E96517_01/multi/cloning-a-pdb.html#GUID-05702CEB-A43C-452C-8081-4CA68DDA8007)** を使って、手動フェールオーバーによる半冗長化を実現します。

　構築では複数サーバへのOracleインストール、PDBクローンの設定、アーカイブログモード運用の実施など比較的構築難易度は高いです。プロセス障害にも対応していますが、フェールオーバー時にはインスタンスの再起動やインスタンスの切替などのオペレーションが発生し、自動フェールオーバーはされないため可用性はやや低めです。
　OracleDataBaseライセンスは複数サーバ分必要ですが、HWに共有ディスクが必要ないため全体的なコストはOFSやSEHAと同じぐらいでしょう。

## ７．サードベンダー（ClusterPro、LifeKeeper等）の冗長化ソフト
##### コスト　？、可用性　？、将来性　？、構築容易性　？

　サードベンダーの冗長化製品の技術者がいれば現実的な選択肢になります。
　一方で冗長化の仕組みも共有ディスク方式、データレプリケーション方式など複数の構成が取れるため、コスト、可用性、構築容易性も一概に説明しずらいため。ここでの説明は割愛させてください。

## ８．コールドスタンバイ、DMPデータコピー方式
##### コスト★★★、可用性☆☆☆、将来性★★★、構築容易性★★★、Active/Standby

　ダウンタイムが長いためこれを冗長化に含めることに否定的な意見もあるかと思いますが、要件によっては検討の余地があると思っているため、最後の候補としてリストアップしました。

　構築ではサーバーを2台準備してOracleDataBaseサーバを2台分インストールしアクティブサーバではDMPを定期的にバックアップ取得しておきます。スタンバイサーバは通常時はサーバーを停止しておき、アクティブサーバに障害が発生した際に、コピーしておいたDMPをインポートして復旧します。手動リカバリーが必要になりインポート時間もかかるため可用性は低いですが、ライセンスも1台分ですみ、共有ディスクも不要なため低コストです。

　HW故障によりシステムが２～３日停止したら困るが、1日程度だったら問題ないという要件なら採用の余地ありでしょう。特別な技術や機能を使っていないため将来性にも全く問題ありませんし、構築も容易です。

## まとめ
　Oracle12c以前でSE RACやOFSを採用していた場合、Oracle19cにおいての最有力候補はSEHAではないでしょうか。

　しかし、システムにおける可用性要件とかけられるコストやインフラエンジニアの運用エンジニアのスキル等様々な条件があるので、どの構成が一概に良いとは言えないので自分たちのシステムに求める可用性要件等を考慮して、冗長化を検討していただければと思います。