Microsoft Cluster Serviceを使用して、Essbaseでアクティブ-パッシブ・クラスタを設定します。
まず、Essbaseを構成してから、Microsoft Cluster Serviceを構成します。
外部のフェイルオーバー・メカニズムによりフェイルオーバーを管理できるようにEssbaseを構成するには:
最初のマシン(Node1)で、EPM Systemコンフィグレータを使用して、クラスタで最初のEssbaseインスタンスを設定します:
「Essbaseクラスタ名」にはクラスタの名前を指定します。
2番目のマシン(Node2)で、EPM Systemコンフィグレータを使用して、最初のマシンで作成したクラスタにこのEssbaseサーバーを含めます。
「Essbaseサーバーの構成」ページの「アプリケーションの場所へのフル・パス(ARBORPATH)」の場所は、クラスタ内の最初のマシンで指定した場所と一致する必要があります。
「既存のクラスタへの割当て」をクリックし、「OK」をクリックして、最初のマシンで作成したクラスタにこのEssbaseサーバーを含めます。
2番目のマシンでのクラスタ設定時、EPM SystemコンフィグレータによってARBORPATH/binにあるessbase.cfgが更新され、failovermode=trueと指定されます。
共有ドライブでABRORPATH/bin/essbase.cfgを開き、次のことを確認します:
FAILOVERMODEがTRUEに設定されています
ESSBASESERVERHOSTNAMEが仮想ホスト名に設定されています
Microsoft Cluster Serviceを使用するには、フェイルオーバー・プロセスへのバインドのために、仮想IPがハードウェア・クラスタで構成されていることが必要です。EssbaseではVIPバインディングを直接サポートしていないため、間接的に実行する必要があります。
Essbase HOSTプロパティがVIPを指すように、Shared Servicesレジストリを更新します。次のコマンドを3回(各Essbaseインスタンスに1回とクラスタに1回)実行します:
epmsys_registry.bat updateproperty #<guid>/@host<Virtual hostname>
GUIDはクラスタでの各Essbaseインスタンスの一意のID(essbasecluster-inst1およびessbasecluster-inst2など)、および定義したクラスタの一意のID(EssbaseCluster-1など)。
hostsファイルを更新して、VIPホスト名が、マシンでの名前解決に出現する最初の名前であること、または別名がボックスのプライマリ物理IPに適切に設定されていることを確認します。
クラスタの両方のノードで、このタスクを実行します。
OPMNをMicrosoft Cluster Serviceによって管理されるサービスとして設定します。Microsoft Cluster Serviceの構成を参照してください。
Essbaseは、Microsoft Cluster Serviceにより直接管理されません; ローカル・ノードのEssbaseエージェント・プロセスを起動、停止および再起動するOPMNにより、すでに管理されています。Essbaseアプリケーション・プロセスは、OPMNにより管理されていないため、自動的に起動および停止されません。これらのサーバー・プロセスは、Essbaseエージェントにより管理されています。
オプションで、Essbaseプロセスの起動、停止およびステータス・チェックのスクリプトを作成します。
EssbaseはMicrosoft Cluster Serviceによって直接管理されるのではなく、OPMNによって管理されているため、わずかな時間遅延が生じる可能性があり、その間OPMNではEssbaseを正常に停止できません。
OPMNにはロジックが組み込まれていて、Essbaseエージェントを正常に停止できないと、OPMNにより強制的に停止されます。Essbaseエージェントが終了すると、Essbaseサーバーにもロジックがあり、フェイルオーバー・モードで実行中に、リース有効期限ウィンドウ内で自動的に終了します(デフォルトで、<= 20秒)。
Microsoft Cluster ServiceによりOPMNが停止すると、それの結果Essbaseエージェントが停止するが、それでも実行中のEssbaseアプリケーションが残るという可能性があるため、これは知っておく必要があります。ただし、クラスタ・サービスの観点から、フェイルオーバーが発生し、OPMNがスタンドバイ・ノードで起動する可能性あります。OPMNによりスタンバイ・ノードでEssbaseエージェントが起動する可能性もありますが、ソース・ノードですべてが停止していなければ起動しないサーバー・プロセスがある可能性があります。
この問題を軽減するために、カスタム・ステータス・チェック・スクリプトを作成できます。たとえば、OPMNのSTOP後の操作として実行し、一定の時間(たとえば、20秒)後にEssbaseサーバー・プロセスが実行していることを確認できるカスタム・ステータス・チェック・スクリプトを作成できます。
クライアント側で必要な変更はありません。
EssbaseサーバーはFAILOVERMODEで構成されているため、アクティブ・ノード情報をShared Services Registryデータベースに対して公開し、ここにEssbase高可用性状態管理テーブルが格納されます。
Provider ServicesおよびShared Services Registry APIの両方に組込みロジックがあり、Essbase高可用性状態管理テーブルに問い合せることにより、アクティブなEssbaseサーバーを確認します。