PR

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

2010年12月20日(月)
菅野 博貴

LifeKeeper設定(アプリケーション) [2]

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

SAPリソースの設定

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

図1: 事前にインストールしているARKリストからRecovery Kitとして「SAP」を選択

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

図2: SAP ASCSリソースのプライマリ側(例:lksap01)ホスト名を選択

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

図3: 自動入力される(SAPシステムID)を確認

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

図4: SAP ASCSインスタンス番号を確認

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

図5: SAPリソースのスタンバイ側ホスト名用のエンキュー・レプリケーション・サーバー・プロファイルを選択

図6: JAVAインスタンスも構成している環境の場合は同様に選択する

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

図7: LifeKeeper管理画面で設定完了後の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コマンドによるフェール・オーバー中のロック・テーブルのモニタリングでも確認しています。

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

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

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

<協力:SAPジャパン株式会社、サイオステクノロジー株式会社>

  • 想定A:リソース単位の障害
  • 想定B:サーバー単位の障害
    • [*1] 特定の環境下で取得されたものであり保証されるものではありません。他の操作環境で得られる結果とは異なる可能性があります。
    • [*2] 特定の環境下で取得されたものであり保証されるものではありません。他の操作環境で得られる結果とは異なる可能性があります。
日本アイ・ビー・エム株式会社

2001年、日本アイ・ビー・エムに入社。入社当初よりSAP社製品関連テクニカルサポートに従事し、日々東奔西走中。グローバルISVソリューションズ所属。

連載バックナンバー

Think IT会員サービス無料登録受付中

Think ITでは、より付加価値の高いコンテンツを会員サービスとして提供しています。会員登録を済ませてThink ITのWebサイトにログインすることでさまざまな限定特典を入手できるようになります。

Think IT会員サービスの概要とメリットをチェック

他にもこの記事が読まれています