SAP HANA環境の障害/災害対策に加えて、コストパフォーマンスの付加価値をもたらすシステムレプリケーション

作成者:花木 敏久投稿日:2013年10月22日

  • このエントリーをはてなブックマークに追加

こんにちは。SAPジャパンの花木です。今回は前回に引き続き、「SAP HANAが提供する耐障害/耐災害機能」というテーマの中で、特にHA/DRの詳細とシステムレプリケーション提供機能について、ご紹介させていただこうと思います。

HA(高可用性)/DR(ディザスタリカバリー)に向けたSAP HANAの施策

Financial trader with screens

最初に前回のおさらいになりますが、SAP HANAを導入した企業の皆様が、障害や災害対策として実施できる施策としては、SAP HANA 1サイト(単独)の環境で実現するバックアップ&リカバリー、およびSAP HANA Host Auto-Failoverと、複数のSAP HANAサイト間で実現するSAP HANA Storage ReplicationによるDR(ディザスタリカバリー)、およびSAP HANA System ReplicationによるHA(高可用性)およびDRがあります。

現実的な耐障害/耐災害対策という意味では、後者のストレージレプリケーションおよびシステムレプリケーションがより重要と思われます。ここでは、この2つのソリューションについて、より詳細な内容をご紹介させていただきます。

障害/災害対策に向けた3つのシナリオ

SAP HANA(および他のベンダーの提供機能)の障害/災害対策シナリオは、大きく以下の3種類に分かれます。

Picture1

  • ストレージミラーリング

インメモリータベースであるSAP HANAは、メモリー上のデータをストレージに格納することで「永続化」を行っていますが、このストレージのデータをプライマリーからセカンダリーにコピーする形態が、ストレージミラーリングです。基本的にストレージ製品側の機能を使用するため、サイト間でミラーリングを行うことが可能な距離などについては、これらの製品に依存します。

現時点(2013年9月)で本機能を提供するSAP HANAアプライアンスベンダーとしては、HP、IBM、Cisco、日立、富士通があります。ミラーリングには、同期/非同期がありますが、その選択にあたっては、サイト間の距離を考慮する必要があります。

プライマリーサイトで障害が発生した場合、セカンダリーへフェールオーバーが発生し、(セカンダリー側のサーバーが稼動しているか、停止しているかに限らず)ストレージからデータを読み出すためにリブートが発生します。SAP HANAでは、立ち上がる際、または最初にアクセスした際、ディスクからテーブル単位でデータベースをメモリー上に読み込み、稼動を開始する必要があるからです。このため、ストレージミラーリングは瞬時にセカンダリーに切り替わるシナリオではありません。

  • WARMスタンバイ

WARMスタンバイは、SAP HANAのシステムレプリケーション機能を使って、メモリー間でデータの複製を行います。通常、プライマリーサイト内のSAP HANAでデータの更新が発生すると、プラマリーサイト内のストレージに書き込みが行われます。システムレプリケーション機能を使えば、この書き込みに加え、セカンダリーサイトへのデータおよびログに関する差分を転送し、複製を行うことができます。複製については、さらに2つのバリエーションがあり、セカンダリー側のメモリーに書き込んで終了する方法と、メモリーだけでなく、ストレージまで書き込んで終了する方法があります。

いずれの場合でも、セカンダリー上のデータベースにデータを反映させるため、セカンダリー側のデータベースは使っていない場合でも、常に立ち上がっている状態となります。アプリケーションがデータベースを更新するのではなくて、プライマリーのデータベースが、同期をとるためにセカンダリーのデータベースを更新する形態になります。前述の2つのバリエーションを用途で分ければ、“スピードを重視”する場合には、メモリー書き込みまでで完了する方法を、“データの保全・永続性を重視”する場合には、さらにストレージまで書き込んで完了する方法を選択します。

Picture1

  • HOTスタンバイ

HOTスタンバイは、現在まだサポートされておらず、今後(SP7以降で)サポートされる予定の機能になります。フェールオーバーの際の切り替え時間が、限りなくゼロに近いのがHOTスタンバイのシナリオとなります。WARMスタンバイの場合には、プライマリーからセカンダリーへデータとログを送りますが、HOTスタンバイの場合には、初回データロードの際だけデータを転送し、以降はログだけを転送します。稼動系(プライマリー)で発生したトランザクションをセカンダリーサイト上で再現させることで同期をとる形になります。

WARMスタンバイ、HOTスタンバイともに、同期/非同期の2つのモードがありますが、サイト間が離れている場合には、基本的に非同期モードを選択します。

よりコストパフォーマンスに優れたSAP HANA環境の実現:システムレプリケーションの活用

システムレプリケーション機能は、障害/災害対策だけでなく、よりコストパフォーマンスに優れたSAP HANA環境の実現という用途でも活用することができます。

Picture2

災害対策用にセカンダリー環境を持つ場合、そちらの環境についてもコストが発生します。もちろん、データ保全や業務継続という意味でこの対応は重要ですが、もしこのセカンダリー環境を他の用途でも使用できれば、よりコストパフォーマンスに優れたSAP HANA環境を実現できます。

このような要件に最適なのが、上の図に示す「QA(テスト)・DEV(開発)サイトと災害対策用のセカンダリーサイトの共用」という形態です。プライマリーサイトであるデータセンター1のSAP HANAシステムデータは、システムレプリケーションの機能で継続的にセカンダリーとなる災害対策用のデータセンター2にコピーされますが、通常運用ではこれを使用せず、データセンター2のSAP HANAは、QAおよびDEVサイトとしての用途で使用します。データセンター1で障害が発生した場合には、QA、DEV環境としての利用を停止して、本番環境をデータセンター2上のSAP HANAに切り替え、業務を継続できるようにします。通常時にはQA、DEV環境として活用できるため、別途災害対策用のセカンダリー環境を購入するよりもコストパフォーマンスを向上することができます。

SAP HANA運用における(他社ソリューションを含めた)耐障害/耐災害機能について、2回にわたってご紹介してきましたが、いかがだったでしょうか? 今回のブログが、障害・災害対策を検討する読者の皆様の参考となれば幸いです。

ご質問はチャットWebからも受け付けております。お気軽にお問い合わせください。

●お問い合わせ先
チャットで質問する
Web問い合わせフォーム
電話: 0120-554-881(受付時間:平日 9:00~18:00)

  • このエントリーをはてなブックマークに追加

連記事

SAPからのご案内

SAPジャパンブログ通信

ブログ記事の最新情報をメール配信しています。

以下のフォームより情報を入力し登録すると、メール配信が開始されます。

登録はこちら