Jump to content 日本-日本語
日本HPホーム 製品 & サービス サポート & ドライバー ソリューション ご購入方法
≫  お問い合わせ

製品とサービス  >  ソフトウェアとOS  >  HP-UX   >  Knowledge-on-Demand  >  特集

さらなる高可用性を実現する
Serviceguard Extension for SAP

HP-UX/Integrityサーバー お問い合せ
コンテンツに進む
さらなる高可用性を実現するServiceguard Extension for SAP

Replicationサービスの可用性を高めるAuto enqueue Replication

業務全体を統合するSAPでは、通常のデータベースで使用されているロック機能よりも広範囲のロックが必要になる。たとえば、一般的なデータベースでは、あるレコードにトランザクションが発生したときに他のトランザクションからデータが変更されないようレコードをロックし、トランザクションが終了するとロックが削除される。
さらなる高可用性を実現するServiceguard Extension for SAP
SAP環境のクラスター化を支援するSGeSAP
Replicationサービスの可用性を高めるAuto enqueue Replication
ページ:  戻る   |   1   2

しかし、SAPではロックの範囲や期間を複数のアプリケーションサーバーが操作するといった、一般的なデータベースではサポートされないロックが必要だ。

そこで、SAPでは「Enqueueサービス」が使用されている。Enqueueサービスは内部にロック情報を管理するEnqueueテーブルを持ち、そのテーブルを下にデータベースのロックが行われるという仕組みだ。

このようにSAPにおけるEnqueueサービスは、いわば全体を支える骨組みの1つといえるが、一方、SPOF(単一障害点)にもなってしまっている、そこでSAPではEnqueueサービスの可用性を高めるために、またフェイルオーバーを高速に行うために、Replicationサービスを提供・推奨している。

  Enqueue Replicationの動作イメージ
図2:Enqueue Replicationの動作イメージ

ReplicationサービスはEnqueueサービスの持つEnqueueテーブルのレプリケーション(Replicationテーブル)を保持している。ホストAで動作しているEnqueueサービスに障害が発生すると、クラスターシステムがReplicationサービスが搭載されているホスト上にEnqueueサービスを起動。Replicationサービスが保持しているReplicationテーブルからEnqueueテーブルを構築する、という形でフェイルオーバーが行われる。

以上のようにEnqueueサーバーとReplicationサーバーという2つのサーバーで可用性が実現されるわけだが、いろいろな障害のパターンが考えられるだろう。たとえば、Enqueueサーバーに障害が発生してReplicationサーバー上でEnqueueサーバーが起動された場合、ReplicationとEnqueueという2つのサービスが同じホスト上で動作することになるが、これでは可用性が保てない。Enqueue、Replicationのどちらかを他のホストに移すべきだろう。また、Replicationサーバーが動作しているホストに障害が発生したなら、他のホストにReplicationサーバーを起動してReplicationテーブルを引き継ぐ必要がある。

Auto enqueue Replicationは、障害発生時にEnqueueとReplicationを自動的に、適切な形で再配置する機能だ。Enqueueサーバーに障害が発生し、Replicationサーバー上でフェイルオーバーが行われたなら、テーブル内容のコピー後Replicationサーバーを別のホストに移す(プッシュ)。また、Replicationサーバーに障害が発生した場合は自動的に別のホストにReplicationサーバーを移し、Enqueueサーバーの参照先を追随させる、といった一連の動作をAuto enqueue Replicationが自動化する。

  EnqueueとReplicationを自動的に配置するAuto enqueue Replication
図3:EnqueueとReplicationを自動的に配置するAuto enqueue Replication

この一連の動作はSGeSAPの新バージョンに含まれるenqordというデーモンによって行われている。ホスト上で動作するenqordがEnqueueサーバーおよびReplicationサーバーの動作を互いに監視、障害を検出するとenqordがEnqueueサーバーとReplicationサーバーを適切に配置し直してくれる。したがって、原理的にはEnqueueサービスが停止する可能性はほぼゼロに押さえることが可能で、高い可用性が実現できるわけである。

クラスター化が可能になったMaster Data Management 5.5

SAPにおいてマスターデータの統合を担う中核コンポーネントであるMaster Data Management(以下、MDM)の現在のバージョンは5.5だ。MDM5.5は非常に高いパフォーマンスを持ち、使いやすいユーザーインタフェースを備えるが、他のSAP NetWeaverコンポーネントと異なるアーキテクチャーが使用されている。

そのため、MDM5.5のクラスター化は困難だったが、SGeSAPの新バージョンにはクラスター化のためのテンプレートが用意された。この新しいテンプレートとスクリプトは、既存のSGeSAPのテンプレートと同じように扱うことができる。また、従来のSGeSAP NetWeaverクラスターリングと同じ操作性が提供されているので、MDM5.5を容易にクラスター環境に移行させることができる。

  クラスター化を実現したMDM
図4:クラスター化を実現したMDM

MDM5.5の高可用性クラスター化が実現できているシステムはいまのところHP-UX+SGeSAPのみだ。SAPの導入に多くの導入実績を持つHPならではの機能といえるだろう。

仮想環境の応用でSAPのさらなる高可用性を実現

以上、SGeSAPの新機能を中心に紹介してきたが、最後にSGeSAPと仮想化を組み合わせ、さらに高い可用性を実現する例を紹介しておくことにしよう。

近年、災害対応ということが重視されるようになってきた。システムを集約してしまうと、万が一の災害時にシステムが完全に停止、業務の再開が困難になる。そこで、システムを遠隔地に分散させ、いざという災害発生時にも短時間での復旧を可能にしようという動きだ。

SGeSAPはすでに都市間クラスターや大陸間クラスターをサポートしており、システムを中央と地方に分散させることで災害発生時の可用性を高めることが可能だ。中央に置くシステムと地方に置くシステムが同一であれば、たとえば中央で災害が発生しても即座に地方のシステムにフェイルオーバーできる。

ただ、同一のシステムを複数用意するのはコスト的に、また人的にも容易ではない。そこで仮想化を利用することで、コストを抑えた災害対応のシステム構築が可能となる。

  仮想化を利用した対災害システムの例
図5:仮想化を利用した対災害システムの例

図5の例では、SAPの開発システムを地方に置き、その中で論理的に開発システム用パーティション(vPar0)と、中央システムの待機用パーティション(vPar1)の2つを構成しておき、中央のシステムと待機用パーティション間をクラスターで結んでおく。地方のシステムは普段は開発システム(vPar0)にリソースを多く割り当てて利用するが、中央で災害が発生したときには、開発システムに割り当て済みのリソースを、待機用パーティション(vPar1)に再配分し、中央システムの業務を継続運用させるために十分なリソースを確保する。この仕組みを利用すれば、地方システムのハードウェアリソースを有効活用しながら、有事の際の完全な業務停止という最悪の事態から逃れる事ができ、かつ性能的な縮退も防ぐことができる。

このようなシステムは実際に企業にすでに導入されており、稼働実績を上げていると聞く。SGeSAPと仮想化の組み合わせは、AP環境の堅牢性をより高める技術として今後も注目されることになるに違いない。

トップへ 戻る ページ:  戻る   |   1   2

その他のコラム(特集)もお読み下さい

 
 

本ページの内容は執筆時の情報に基づいており、異なる場合があります。

お問い合わせ

ご購入前のお問い合わせ


ご購入後のお問い合わせ

オンラインサポート
製品の標準保証でご利用いただける無償のサービスです。

ショールーム

ショールーム 導入をご検討のお客様へ
業務アプリケーションの継続・標準化・開発性とシステム担当者様、システム開発者様が抱える悩み・疑問に対する解決策実体験して頂けます。
印刷用画面へ
プライバシー ご利用条件・免責事項 ウェブマスターに連絡