ERSリソースタイプの設計と実装は、SPS-L 9.4.0で変更されました。このページでは、バージョン9.4.0より前の実装とバージョン9.4.0以降の実装の違い、システムに存在するバージョンの判別方法、および新しいリソースタイプへのアップグレード方法について説明します。
SPS-L 9.4.0より前（9.3.2以前）のERSリソース
9.4.0より前（9.3.2以前）のバージョンのSPS-Lでは、ERSリソースは、ロックテーブルの冗長性を提供するセントラルサービス（ASCS/SCS）リソースに依存するSAP階層の最上位に位置するように設計されていました。
このリソースの動作は、バックアップノード（ERSリソースがLifeKeeper GUIでスタンバイとしてリストされていた場所）でERSインスタンスを開始するように設計されていました。SAP階層のスイッチオーバーまたはフェールオーバー時にASCS/SCSインスタンスがバックアップノードで起動され、そのシステムの共有メモリからロックテーブル（レプリケーションテーブル）のバックアップコピーを取得します。エンキューサーバーがロックテーブルを正常に取得すると、ERSインスタンスに自分自身を終了するよう通知する信号を送信します。
ERSリソースがバックアップノードのLifeKeeperでアクティブ（ISP）になると、ERSインスタンスは、利用可能になったときに元のプライマリノードで起動します。その時点で、レプリケーションサーバーはエンキューサーバーに再接続し、ロックテーブルのレプリケーションを再開します。ERSインスタンスがバックアップノードで実行されている場合、LifeKeeper GUIのステータスは「StandBy」から「ERS Running」に変わります。
SPS-L 9.4.0以降のERSリソース
SPS-L 9.4.0以降では、ERSリソースは独自の独立した階層で動作するように再設計されました。
独立階層のERSv1リソース
仮想IPと高可用性依存ファイルシステムを備えた独立階層のERSv2リソース
この新しいERSリソース設計は、2ノードクラスターのERSv1インスタンスと、任意の数のノードを持つクラスターのERSv2インスタンスをサポートします。このリソースタイプを使用すると、ERSインスタンスは、LifeKeeperが現在Active（ISP）になっているノードと同じノードで開始されます。ERSv2階層（依存する仮想IPおよびファイルシステムリソースを含む）が対応するセントラルサービスリソース階層とは独立してフェールオーバーできるようにするために、設計を変更しました。
対応するセントラルサービスリソースと同じノードでERSリソースがActive（ISP）にならないようにするために、この新しいERSリソースタイプは、各quickCheck間隔（デフォルト：2分）で次のことを確認します。
- ERSリソースが、対応するセントラルサービスリソースと同じノードでActiveになっている
- ロックテーブルのレプリケーションは、エンキューサーバーとレプリケーションサーバーの間で同期している
- ERS階層内のすべてのリソースを正常に再配置できるクラスター内に、使用可能な別のノードが存在する
これら3つの条件がすべて満たされている場合、クラスターノード間でエンキューサーバーのロックテーブルデータの冗長性を提供するために、LifeKeeperはERS階層を別のクラスターノードに自動的に再配置します。LifeKeeperでフラグ「sap_no_ers_relocation_<ERSタグ>」を設定すると、この自動再配置動作を無効にできます。これは、次のコマンドで実行できます（SAP-EXM_ERS12はERSリソースのタグの例です）。
/opt/LifeKeeper/bin/flg_create -f "sap_no_ers_relocation_SAP-EXM_ERS12"
このフラグを作成しても、ERSインスタンスのローカルリカバリーの失敗によるフェールオーバーは無効になりません。
NFSを使用する場合の注意点： この設計により、sapmntファイルシステム上のERSリソースのLifeKeeper依存関係が削除されるため、調整可能な値SAP_NFS_CHECK_DIRSを適切に使用して、sapmnt NFS共有にアクセスできないことに起因するアクションスクリプトのハングを防止する必要があります。詳細については、NFSの考慮事項へのリンク を参照してください。
階層に存在するERSリソースタイプの確認方法
既存のERSリソースがLifeKeeperのどのバージョンで作成されたかわからない場合は、次のコマンドを実行します（<ERSタグ>をERSリソースのタグ名に置き換えてください）。
/opt/LifeKeeper/bin/ins_list -f: -t <ERS Tag> | cut -d: -f6
このコマンドの出力は次のようになります。
EXMERS12sap2/sapmntFULLFULL5
- 出力の最後の桁が2の場合、このリソースはSPS-L 9.3.2以前で作成されています。このタイプのリソースは、2ノードクラスターのERSv1インスタンスを表すためにのみ使用でき、SAP階層の最上位に位置し、その下の対応する中央サービス（ASCS/SCS）インスタンスと依存関係を持つ必要があります。独立した階層で動作する新しい設計に切り替える方法については、以下の ERSリソースタイプのアップグレード セクションを参照してください。
- 出力の最後の桁が5の場合、このリソースはSPS-L 9.4.0以降で作成されています。このタイプのリソースを使用して、2ノードクラスターのERSv1インスタンスまたは任意の数のノードを持つクラスターのERSv2インスタンスを表すことができます。これは、対応するセントラルサービスリソースから独立した階層で動作する必要があります。
ERSリソースタイプのアップグレード
SPS-L 9.4.0以降で新しいERSリソースタイプにアップグレードするには、次の手順を実行してください。
- アップグレードプロセスを試行する前に、次のコマンドを実行して、すべてのクラスターノードでLifeKeeper階層のバックアップを作成します。
- 作成中に何か間違えた場合は、すべてのノードでLifeKeeperを停止して次のコマンドを実行することにより、保存された階層構成を復元できます。
- LifeKeeper階層パネルでERSリソースを右クリックし、 [Delete Dependency…] を選択します。
- ERSリソースのすべての依存関係を削除します。すべての依存関係を削除するには、 [Delete Dependency…] を何度か選択する必要がある場合があります。依存関係を削除すると、次の図に示すように、ERSリソースは子の依存関係やそれに依存する他のリソースを持たず、単独の階層に存在するようになります。
- LifeKeeperの階層パネルでERSリソースを右クリックし、 [Delete Resource Hierarchy…] を選択します。 ターゲットサーバー として任意のサーバーを選択し、 [Next] をクリックします。 [Delete] をクリックし、すべてのノードのERSリソースを削除します。 警告: 前のステップでERSリソースとSAP階層内の他のリソース間のすべての依存関係が正常に削除できなかった場合、 このステップによってSAP階層全体が削除される可能性があります。
- ERSリソースをすべてのノードで正常に削除したら、「SAPのインストール → SAP階層の作成 」の「ERSリソースの作成」セクションの指示に従って、新しいERSリソースを作成し、目的のクラスターノードに拡張します。
このトピックへフィードバック