NetVault仮想クライアントでOracle SEHAに対応できるか？

（作業中）

１．Oracle SEHAと他のクラスタソフトとの違い

一般的なクラスタソフトウェアでは、
仮想IPやデータベースアプリケーションなどを
リソースグループとしてまとめ、本番サーバに障害が発生した場合に
待機サーバへリソースグループ単位でフェイルオーバーします。

Netvaultは、サポートされているフェイルオーバークラスタ構成では
クラスタの仮想IPに対してNetVault仮想クライアントを構成します。
NetVault仮想クライアントが実際に稼働しているのが本番サーバか待機サーバかをチェックし
稼働しているサーバ側のNetVaultクライアントとアプリケーションプラグインにより
バックアップを継続するような仕組みになります。

Oracle SEHAでは、
クラスタソフトウェアは、Grid Infrastructureの１コンポーネントのOracle ClusterWere（OCW）になります。
仮想IPは、Grid InfrastructureのVIPを利用しますが、Grid Infrastructureには２種類のVIP（ノードVIPとSCAN VIP）があります。
ノードVIPは各ノードに構成され、
SCAN（Single Client Access Name） VIPはクラスタのいずれかのノードで起動しデフォルトでは３つ構成します。

Oracle SEHAでは、
一般的なクラスタソフトとは異なり、リソースグループの概念がありません。
VIPとデータベースはリソースグループとしてまとめることはできません。
それぞれ独立してフェイルオーバー・移動します。
たとえば、srvctlコマンドインタフェースで、データベースだけ待機サーバへ移動することもできます。

NetVaultの仮想クライアントは、一般的なクラスタソフトのリソースグループ単位のフェイルオーバーを想定して設計されているため
Oracle SEHAの、VIPとデータベースが独立して移動するパターンに対応できません。
上述のOracle SEHAのVIP（各ノードのVIPとデフォルト３つのSCAN VIP）のどれかを仮想クライアントとして構成した場合、
そのVIPとバックアップ対象のデータベースが同一のノードで動作していればバックアップは可能ですが
VIPとデータベースが別のノードで動作している場合、バックアップは失敗します。

２．検証環境

・Grid Infrastructure の前提条件としてDNSサーバ必須
・SCAN VIPはデフォルト３、各ノードVIPも必要（本検証では、SCAN VIP(１)のみ使用）

３．検証内容

３－１　NetVault仮想クライアントの作成

	Oracle SEHAのSCAN VIPを、仮想クライアントとして登録します。
	評価キーをインストールできない警告が出ますが、無視して、仮想クライアントのインストールは正常終了します。
	バックアップジョブ作成で、セレクションを開くと、クライアントのリストにSCANVIPという仮想クライアントが表示されるので、 ドリルダウンして、Plugin for Oracleをクリックし、Oracle プラグインの設定を行います
	仮想クライアントでOracleインスタンスの各項目がバックアップ選択可能になります
	セレクションを保存して、残りのプラグインオプションやターゲットストレージを設定し、ジョブとして保存・実行可能にします。

３－２　本番サーバでバックアップジョブ実行

３－３　待機サーバにVIPとDBフェイルオーバーしてバックアップジョブ実行

３－４　待機サーバにVIP、本番サーバにDBフェイルオーバーしてバックアップジョブ実行

	３－３の状態からOracleインスタンスのみコマンド手動実行srvctl relocate [oracle@o83o198p ~]$ srvctl relocate database -db orcl -node o83o198p
	SCAN VIPは待機サーバ、Oracleインスタンスが本番サーバで稼働していることを確認
	[oracle@o83o198p ~]$ srvctl status scan -all SCAN VIP scan1 is enabled SCAN VIP scan1 is running on node o83o198s [oracle@o83o198p ~]$ srvctl status database -d orcl Instance orcl is running on node o83o198p
	バックアップジョブを実行すると、SCANVIPが待機サーバo83o198sで稼働していることを確認後、待機サーバo83o198sのNetVaultクライアントでジョブが実行されるが、 Oracleインスタンスは本番サーバに移動しているため、待機サーバではORA-01034 Oracle not Availableになり、ジョブが失敗する

４．暫定的な考察

以上により、

・Oracle SEHAのSCAN VIPでNetVault仮想クライアントを設定し
・本番サーバから仮想クライアントとしてOracleインスタンスをバックアップできました。
・本番サーバを停止し、待機サーバにOracleインスタンスとSCAN VIPがフェイルオーバーしている状態で
待機サーバから仮想クライアントとしてOracleインスタンスをバックアップできました。

これにより、本番サーバのノード障害発生時のフェイルオーバーに、NetVault仮想クライアントとして
バックアップが継続できることは確認できました。

しかし、

・SCAN VIPとOracleインスタンスがそれぞれ本番サーバと待機サーバに別個で動作している場合、
仮想クライアントとしてのバックアップジョブは失敗しました。

Oracle SEHAが他のクラスタソフトウェアと異なる点に注意が必要であり、
SCAN VIPとOracleインスタンスを、リソースグループとして紐付けできないため
SCAN VIPでNetVault仮想クライアントを設定した場合に、SCAN VIPと異なるサーバに
Oracleインスタンスのみを移動して動作させた場合は、バックアップできませんでした。

　
したがいまして、本番サーバで運用し、本番サーバ障害時に待機サーバにフェイルオーバーし、１０日間ルール範囲内に、本番サーバへフェイルバックする想定で
通常運用はバックアップ可能、
待機サーバへOracleインスタンスとSCAN VIPがフェイルオーバーできれば追跡してバックアップ可能
待機サーバから本番サーバに手動フェイルバックする際に、かならずOracleインスタンスとSCAN VIPを一緒に移動させるよう注意いただき、
NetVault仮想クライアントが設定しているOracleインスタンスとSCAN VIPが常に同一サーバで稼働するよう注意いただければ
運用は可能かと言えるのではないでしょうか。

• 本ドキュメントは、検証作業や検証結果についてまとめたものを紹介しているものであり、本ドキュメントに関する内容について、クエスト・ソフトウェア株式会社が動作を保証するものではありません。各ソフトウェアのバージョンおよび環境等の違いにより動作しない場合も想定されますので、導入の際には事前に検証をされることを推奨いたします。
• 記載されている会社名および製品名などは該当する各社の商標または登録商標です。
• 本手順で説明している他社製品の操作詳細については、各社のマニュアル等をご参照ください。 

作成：２０２１年１月