SAP基幹システムの高可用性を低コストで第3回

後処理

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

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

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

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

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

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

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

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

図8: ASCSインスタンスがフェール・オーバーした状態のLifeKeeper管理画面

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）にログインしている場合は、何も処理をしていなければセッションは継続されました。

図9: サーバー全体がフェール・オーバーした状態のLifeKeeper管理画面

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システムへ採用されていくことを期待しています。