ディレクトリ構造

データベースのディレクトリ構造は、SAP システムと合わせて使用する各データベース管理システムによって異なります。使用するデータベースのディレクトリ構造の詳細については、データベース管理システム固有の SAP Installation Guide を参照してください。データベース向け LifeKeeper Recovery Kit で保護するには、すべてのデータベースファイルを共有ディスク上に配置する必要があります。データベースの保護に関する詳細については、データベースごとの Recovery Kit ドキュメンテーションを参照してください。

このセクションで説明する SAP ディレクトリの図解については、下のディレクトリ構造図を参照してください。

インストール中に作成されるディレクトリの種類は、次の通りです。

物理的に共有されたディレクトリ (グローバルホスト上にあり、NFS で共有される)

/<sapmnt>/<SAPSID> - 1 つの SAP システム用のソフトウェアとデータ (同一の SAP システムに属するすべてのホストにマウントする必要がある)

/usr/sap/trans - グローバルトランスポートディレクトリ (エクスポートポイントを持つ必要がある)

以下のローカルディレクトリを持つ /usr/sap などのノードにバインディングされている 論理的に共有されたディレクトリ (ローカルホスト上にあり、グローバルホストへのシンボリックリンクを持つ)

/usr/sap/<SAPSID>

/usr/sap/<SAPSID>/SYS

/usr/sap/hostctrl

以下のような SAP インスタンスを含む ローカルディレクトリ (ローカルホスト上にあり、共有されている)

/usr/sap/<SAPSID>/DVEBMGS<No.> — プライマリアプリケーションサーバインスタンスのディレクトリ

/usr/sap/<SAPSID>/D<No.> — プライマリアプリケーションサーバインスタンスのディレクトリ

/usr/sap/<SAPSID>/ASCS<No.> — ABAP セントラルサービスインスタンス (ASCS) のディレクトリ

/usr/sap/<SAPSID>/SCS<No.> — Java セントラルサービスインスタンス (SCS) のディレクトリ

/usr/sap/<SAPSID>/ERS<No.> — ASCS および SCS 向けエンキューレプリケーションサーバインスタンス (ERS) のディレクトリ

SAP ディレクトリ /sapmnt/<SAPSID> および /usr/sap/trans は、NFS からマウントされます。ただし、SAP インスタンスディレクトリ (/usr/sap/<SAPSID>/<INSTTYPE><No.>) は、常に、現在インスタンスを実行しているクラスタノード上にマウントする必要があります。このようなディレクトリを NFS でマウントしないでください。必要なディレクトリ構造は、選択された構成によって変わります。必要なディレクトリ構造を決める問題はいくつかあります。

NFS マウントポイントと inode

LifeKeeper は、inode を使用して NFS 共有情報を管理するため、各 NFS 共有は固有の inode を持つ必要があります。すべてのファイルシステムのルートディレクトリは同じ inode を持つため、NFS 共有を LifeKeeper で保護するためには、ルートから少なくとも 1つ下のディレクトリ階層にある必要があります。例えば、上記の情報に留意して、 /usr/sap/trans ディレクトリを SAP サーバ上で NFS 共有する場合、共有ストレージデバイス上に /trans ディレクトリが作成されます。これには、共有ストレージデバイスを /usr/sap としてマウントする必要があります。しかしながら、この配置で要求されるように、すべてのファイルを共有ストレージ上の /usr/sap 配下に置くことは必ずしも望ましくありません。この問題を回避するため、NFS 共有されているディレクトリを含むすべての共有ファイルシステムをマウントするための /exports ディレクトリツリーを作成し、その後で SAP ディレクトリと /exports ディレクトリ間にソフトリンクを作成するか、この NFS 共有ディレクトリをローカルに NFS マウントすることを推奨します。(注記: ここで /exports と呼ぶディレクトリの名前は、ユーザの好みによって変更できますが、説明を分かりやすくするため、このドキュメンテーションではこのディレクトリを /exports と呼びます。)例えば、この SAP プライマリサーバの例に関する次のディレクトリとリンク / マウントは、以下のようになります。

/usr/sap/trans 共有の場合
ディレクトリ	備考
/trans	共有ファイルシステム上に作成され、NFS で共有
/exports/usr/sap	/ (共有ファイルシステム上) にマウント
/usr/sap/trans	/exports/usr/sap/trans にソフトリンク

同様に、 <sapmnt>/<SAPSID> 共有に対するディレクトリとリンクは、次のようになります。

<sapmnt>/<SAPSID> 共有の場合
ディレクトリ	備考
/<SAPSID>	共有ファイルシステム上に作成され、NFS で共有
/exports/sapmnt	/ (共有ファイルシステム上) にマウント
<sapmnt>/<SAPSID>	<virtual SAP server>:/exports/sapmnt/<SAPSID>に NFS マウント

すべてのディレクトリ構造とリンクを作成するための詳細な手順を、本ドキュメンテーションの設定手順で後述します。inode 競合の詳細と、NFSv4 の新機能を使用するための情報については、NFS Server Recovery Kit ドキュメンテーションを参照してください。

ローカル NFS マウント

LifeKeeper 環境の SAP に推奨されるディレクトリ構造では、1 つまたは複数の SAP システムディレクトリについてローカルにマウントされた NFS 共有が要求されます。いずれかのローカルにマウントされた NFS 共有の NFS エクスポートポイントが使用不可になると、エクスポートポイントが使用可能になるのを待機する間、システムがハングすることがあります。システムの再起動を含め、多くのシステム操作が正しく動作しません。SAP クラスタの NFS サーバを LifeKeeper で保護する必要があり、ローカルマウントポイントが存在する間は手動でサービス休止状態にしてはならないことに注意してください。

不注意で NFS サーバを停止してクラスタをハングさせないように、NFS の考慮事項トピックに記載した推奨事項に従ってください。また、すべての NFS 共有を「intr」マウントオプションを使用してマウントすると、アクセス不可の NFS 共有に起因するプロセスを kill することができるため役立ちます。

NFS 共有にアクセスできない場合、アンマウントが失敗することがあります。LifeKeeper は、ファイルシステムのアンマウントを複数回試行します。複数回試行することにより、通常、最終的にリソースを Out of service にすることに成功します。ただし、リソースを Out of service にする際に遅延が発生します。再試行を回避するには、マウントオプション「nfsvers=3, proto=udp 」を使用します。

NFS マウントと su

LifeKeeper は、多くのデータベース作業および SAP 作業を、su - <admin name> -c <command> コマンド構文を使用してデータベース処理および SAP 処理を実行することで実現します。このような方法で呼び出された場合、su コマンドにより、管理者のホームディレクトリにあるログインスクリプトが実行されます。これらのログインスクリプトは、環境変数をさまざまな SAP パスに設定します。その一部は、NFS マウントされた共有に存在する可能性があります。これらの NFS 共有が何らかの理由で利用できない場合、su 呼び出しは、NFS 共有が利用可能になるまで待機してハングします。

ハングスクリプトは LifeKeeper の正常実行を妨げる可能性があるため、この潜在的な問題に対処するよう、サーバを設定することが望まれます。SAP リソースの削除、リストア、監視処理を行う LifeKeeper スクリプトは、これらのスクリプトがいつまでもハングし続けることを防止するタイマを内蔵しています。そのため、SAP Application Recovery Kit では、NFS ハングに対処するための設定作業は必要ありません。

それでも、利用不可能な NFS 共有によって影響を受ける手動の処理は数多く存在することに注意してください。手動で LifeKeeper 処理を実行する前に、必ず、すべての NFS 共有が利用可能であることを確認する必要があります。

< INST > ディレクトリの場所

/usr/sap/<SAPSID> パスは NFS 共有ではないため、ファイルシステムのルートディレクトリにマウントできます。 /usr/sap/<SAPSID> パスには、サーバ上で実行可能な SAP インスタンスごとに、 SYS サブディレクトリと < INST > サブディレクトリが含まれています。構成によっては、< INST > ディレクトリは 1 つしかないため、共有ファイルシステム上の /usr/sap/<SAPSID> 配下に置くことができます。ただし、他の構成では、バックアップサーバもローカル AS インスタンスを含む可能性があり、その < INST > ディレクトリは常に利用できるわけではないため、共有ファイルシステム上に置くことはできません。この問題を解決するため、特定の構成では、PAS、ASCS、または SCS の /usr/sap/<SAPSID>/<INST> 、 /usr/sap/<SAPSID>/<ASCS-INST> 、または /usr/sap/<SAPSID>/<SCS-INST> ディレクトリを /usr/sap/<SAPSID> ではなく共有ファイルシステムにマウントし、AS の /usr/sap/<SAPSID>/SYS および /usr/sap/<SAPSID>/<AS-INST> をローカルサーバ上に置いてください。

例えば、ABAP+Java 構成では、次のディレクトリとマウントポイントを作成する必要があります。

ディレクトリ	注記
/usr/sap/<SAPSID>/DVEBMGS< No.* >*	/(共有ファイルシステム上) にマウント
/usr/sap/<SAPSID>/SCS< No.* >*	/(共有ファイルシステム上) にマウント
/usr/sap/<SAPSID>/ERS< No.* >* (SCS インスタンス用)	すべてのクラスタノード上にローカルでマウントするか、NAS 共有からマウントする必要がある ( 共有ストレージ上にマウントしてはならない )
/usr/sap/<SAPSID>/ASCS< Instance No.* >*	/(共有ファイルシステム上) にマウント
/usr/sap/<SAPSID>/ERS< No.* >* (ASCS インスタンス用)	すべてのクラスタノード上にローカルでマウントするか、NAS 共有からマウントする必要がある ( 共有ストレージ上にマウントしてはならない )
/usr/sap/<SAPSID>/AS< Instance No.* >*	バックアップサーバ上の AS に作成

注記: エンキューレプリケーションサーバ (ERS) リソースは、クラスタのプライマリノードで In Service (ISP) になります。ただし、ERS のアーキテクチャと機能は、インスタンスの実際のプロセスがバックアップノード上で実行される必要があります。これによって、スタンバイサーバはプライマリサーバおよびプライマリエンキューサーバインスタンスのロックテーブル情報の完全なコピーを保持することができます。エンキューサーバを実行するプライマリサーバに障害が発生した場合、ERS プロセスが現在実行されているバックアップサーバ上の SIOS Protection Suite によって再起動されます。ERS 上に保存されているロックテーブル (レプリケーションテーブル) が復旧中のエンキューサーバプロセスに転送され、それを基に新しいロックテーブルが作成されます。このプロセスが完了すると、アクティブなレプリケーションサーバは非アクティブになります (このサーバはエンキューサーバとの接続を閉じ、レプリケーションテーブルを削除します)。これまで非アクティブだった新しい現在のバックアップノード (元のプライマリ) 上で、SIOS Protection Suite によって ERS プロセスが再起動されます。ERS プロセスがアクティブになると、エンキューサーバに接続され、レプリケーションテーブルが作成されます。ERS プロセスと SAP アーキテクチャの機能の詳細については、http://help.sap.com にアクセスして、 エンキューレプリケーションサービス で検索してください。

レプリケーションサーバはバックアップノードで常にアクティブであるため、ファイルシステムはプライマリノードでアクティブになり、レプリケーションサーバプロセスはバックアップノードでアクティブになります。このため、レプリケーションサーバはSIOS Protection Suiteで保護されたファイルシステムには常駐できません。したがって、ERSが使用するファイルシステムは、すべてのクラスタノードでローカルにマウントするか、NAS共有からマウントする必要があります。