SAPリソース設定とフェイルオーバー

LifeKeeper設定（アプリケーション） [2]

前回はOracleリソースの設定までご紹介しました。次はいよいよSAPリソースの設定となりますが、他のARKと同様で非常にシンプルに設定できます。

SAPリソースの設定

他のリソース設定とは異なる設定画面を使用しながらポイントを説明します。図1では、事前にインストールしているARKがリストされるので、Recovery Kitとして「SAP」を選択します。

図2では、SAP ASCSリソースのプライマリ側（例：lksap01）ホスト名を選択します。選択したホスト上でASCSインスタンスが起動していないと設定することができません。

図3では、（SAPシステムID）が自動入力されてくるので、それを確認します。

図4では、SAP ASCSインスタンス番号が図3と同様に自動入力されてくるので、それを確認します。

図5では、SAPリソースのスタンバイ側ホスト名用のエンキュー・レプリケーション・サーバー・プロファイルを選択します。もしJAVAインスタンスも構成している環境の場合は、図6でも同様の設定が必要となります。今回の検証ではABAPインスタンスのみだったため、「None」を選択しています。

最終的に設定が完了すると、図7のようにSAPリソースのステータスが表示されます。リソース作成中に、IPリソースやNFSリソースなど、SAP ASCSインスタンスに関連するリソースが自動的にSAPリソースの配下に設定されます。

後処理

SAPライセンスのインストール

ライセンスはSAP Service Marketplace（キー登録& 注文→ライセンスキー）から申請し、SAP社よりライセンス・ファイルが送付されます。これを受けてSAPシステム上でトランザクション・コードSLICENSEより、両ノードのハードウエア・キー分のライセンスをインストールします。この時、ASCSインスタンスを2ノードで切り替えながら実施します。

この他に、SAP社が公開しているインストール・ガイド内の後処理項目を実施する必要があります。以上で導入設定関連のポイントは終了です。次にフェール・オーバー検証についてご紹介します。

フェール・オーバー検証 [1]

ここでは、大きく2つの障害ケースに分類して検証結果を説明します。

想定A: リソース単位の障害

A-1. SAP ASCSインスタンスのフェール・オーバー

SAPリソース配下のファイル・システムやNFS等も含め、2分程度^*1で切り替わりました。また、エンキュー・レプリケーション・サーバーの設定前では、フェール・オーバー前に開始した処理をフェール・オーバー後に継続するとログイン後初期画面にリセットされましたが、エンキュー・レプリケーション・サーバーの設定後では、ロック・テーブルが保持され継続して処理を実行できました。当検証ではユーザー作成（トランザクション・コードSU01）中にASCSインスタンスを切り替えることで動作を検証しました。また、enqtコマンドによるフェール・オーバー中のロック・テーブルのモニタリングでも確認しています。

A-2. Oracle DBインスタンスのフェール・オーバー

Oracleリソース配下のファイル・システムやOracleリスナー等も含め、2分程度^*1で切り替わりました。ただし、検証環境のデータベース容量は、NetWeaver7.0 EHP1で約20GBなので、容量の大きいSAP ERPシステムの場合はもう少し時間かかるものと思われます。

引き続き次ページでは、サーバー単位の障害について説明します。

[備考]
LifeKeeperの動作として、障害を検知した場合にまずはローカル(自ノード)でリカバリーを試みます。例えば、ASCSをstopsapコマンドにより手動で停止する、またはエンキュー・レプリケーション・サーバーのプロセスをkillコマンドで停止すると、それぞれ自動検知(デフォルト120秒間隔でプロセス監視、変更可能)され、サーバーが再起動されました。
リソース単位でフェール・オーバーさせる想定では、このリカバリー機能が働きスタンバイ側へフェール・オーバーしません。よって当検証ではLifeKeeperでスタンバイ側をアクティブにすることで疑似的にフェール・オーバーを発生させて検証しています。

フェール・オーバー検証 [2]

想定B : サーバー単位の障害

B-1. SAP ASCSインスタンスが稼働するサーバー全体の障害

フェール・オーバー時間は2分程度^*2でした。
セントラル・インスタンス（CI）はASCSインスタンスと同一サーバーで稼働しているため、これにログインしている場合はセッションが切断されました。ダイアログ・インスタンス（DI）にログインしている場合は、何も処理をしていなければセッションは継続されました。

B-2. Oracle DBインスタンスが稼働するサーバー全体の障害

フェール・オーバー時間はSAP ASCS同様2分程度^*2でした。 ダイアログ・インスタンス（DI）にログインしている場合はセッションが切断され、セントラル・インスタンス（CI）にログインしている場合は、何も処理をしてなければセッションは継続されました。フェール・オーバー中の何らかの参照/更新処理を実行するとショートダンプが発生しました。この場合はフェール・オーバー完了後に再処理が必要となります。

[備考]
LifeKeeperでは、デフォルトでshutdownコマンド等正常な停止プロセスを経た場合は自動的にフェール・オーバーを行いません。当検証ではhalt -fコマンドを実行してシステムを即時強制終了させることで検証しました。

検証結果と考察

いずれのフェール・オーバー検証においても想定通り、SAPリソースやOracleリソースがスタンバイ側へ引き継がれました。さらに別途エンキュー・レプリケーション・サーバーを設定することによって、変更情報を失うことなく処理を継続できることを確認できました。

LifeKeeperにおける各リソースの設定は、GUIベースの操作であり、またウィザード形式でシンプルな選択項目により構成していく形で、操作が非常にシンプルかつ分かりやすいものでした。そして通常は実施しませんが、設定したリソースの削除も簡単に行え、迅速にLifeKeeper設定前の環境に復元できることも確認しました。

このように、LifeKeeperの設定そのものに関しては、スクリプトの作成は不要で、一般公開されているガイドのみで対応できるレベルなので、構築作業工数の削減に直結します。また、作業に複雑性がないことは、想定外のトラブルを招く可能性も低いとも言えます。

過去には、可用性の観点でLinuxが不安視され採用が見送られるケースも見受けられましたが、今回の検証結果から、OSがLinuxであっても、LifeKeeperさらにはSAPエンキュー・レプリケーション機能によって、高可用性を確保できることが実証されました。今後さらにSAPシステムへ採用されていくことを期待しています。

リファレンスサイトのご紹介

本連載に関連するWEBサイトをご紹介します。

＜協力：SAPジャパン株式会社、サイオステクノロジー株式会社＞

• 想定A：リソース単位の障害
• 想定B：サーバー単位の障害
  • [*1] 特定の環境下で取得されたものであり保証されるものではありません。他の操作環境で得られる結果とは異なる可能性があります。
• • [*2] 特定の環境下で取得されたものであり保証されるものではありません。他の操作環境で得られる結果とは異なる可能性があります。
  • IBM BladeCenter（アクセス：2010.12）
  • LifeKeeper（アクセス：2010.12）
  • SAP Help Portal （エンキュー・レプリケーションのインストール）（アクセス：2010.12）