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 リソースを作成し、目的のクラスターノードに拡張します。
このトピックへフィードバック