前回までに、LifeKeeperでのOracleインスタンスの保護が完了しました。またアクティブなサーバーに障害が発生した際にもスタンバイサーバーでサービスが再起動し、クライアントから仮想IPに対して接続が出来ることを確認できれば、これで問題ないと思います。
これで作業は終わりと思われたかともしれませんが、細かい設定事項をいくつかお知らせします。
26.アンチアフィフィニティの設定
今回アクティブのサーバーとスタンバイのサーバー2台の仮想マシンを作成しましたが、2台の仮想マシンが、同一のNutanix上で稼動するホストで動作していた場合、物理ホストに障害が発生すると、ハイパーバイザーのHAが稼動し別のホストで仮想マシンが再起動します。別にこれであっても問題があるわけではありませんが、2台のサーバーが同時に落ちてしまい、ハイパーバイザーのHAでOSから再起動する時間を考えると、2台の仮想マシンは別のホストで稼働し、仮にアクティブなサーバーが稼動する物理ホストが落ちてもすぐに他の物理ホストで稼動していたスタンバイサーバーに切り替わる方が、より早くサービス復旧が可能となります。
このような、2台のサーバーを同じ物理ホストで稼働させない設定を行うことが出来ます。
vSphereの場合、Enterprise Plusに搭載されるDRSの中にある機能で、AHVの場合は、ADSの機能でそれぞれアンチアフィニティールールで設定を行います。
今回は、AHVでの設定をご紹介します。
まず、CVMにSSHで接続します。
SSHでacliコマンドレットに入り、以下のコマンドを入力します。
#保護対象の「ORACLE19C-LK01」と「ORACLE19C-LK02」をグループに入れる
これで、「ORACLE19C-LK01」と「ORACLE19C-LK02」が同一のサーバーで稼動しない設定が完了しました。
Prismを見ると2台の仮想マシンが別のホストで稼動していることが分ります。
なお、意図的にライブマイグレーションを行い、アフィニティールール違反を起こすと、一時的に同一物理ホストで2台の仮想マシンが稼働しますが、しばらくするとADSが発動し自動的に別々の物理ホストに仮想マシンがライブマイグレーションされます。
27.サービス起動順序の制御
スタンバイのサーバーを再起動すると、環境によっては本来アクティブなホストしかアクセスできない共有ドライブにアクセスが出来てしまう事象があります。
スタンバイのサーバーで共有ドライブ自体は、読み取り専用になっておりファイルを書き込むことは出来ませんが、中身がのぞけてしまうのは些か気持ちが悪いところがあります。
▼スタンバイサーバーで共有ディスクの中を開きファイルをコピーしたらアクセス権がないと言われる
これは、LifeKeeperのサービスが共有ストレージが見えるタイミングに問題があります。イベントログを見てみるとNutanixからiSCSIで提供される共有ボリュームである、Oドライブのアクセスに失敗しているのが分ります。
これは、WindowsのiSCISイニシエーターである「Microsoft iSCSI Initiator Service」が、LifeKeeperのサービスよりも後に起動することにより、LifeKeeperのサービスが共有ストレージの制御に失敗していることを表しています。
LifeKeeperの古いドキュメントを読んでいると、LifeKeeperのサービスをiSCSIイニシエーターサービスとの依存関係を作成するような手順も紹介されていますが、私が確認する限り依存関係を作ってもこの事象は、解決しませんでした。
そのため以下のようなバッチファイルを作成し、これをスタートアップスクリプトとして設定することで対処を行います。
この作業は、2台ある仮想マシンそれぞれ両方で行います。
バッチファイルは、「c:\admin\lkstart.bat」とします。
timeout /t 10 /nobreak > nul
net start "LifeKeeper External Interface"
timeput /t 5 /nobreak > nul
net start "LifeKeeper"
サーバー側にバッチファイルを作成する
次に、ローカルグループポリシーエディタを開き、スタートアップスクリプトを設定します。
まず、ファイル名を指定して実行から「gpedit.msc」開き、ポリシーエディターを開きます。
コンピューターの構成→Windows の設定→スクリプトから、スタートアップで、先程作成したスクリプトを登録します。
0 件のコメント:
コメントを投稿