日本語は機械翻訳による参考訳です。内容に矛盾や不一致があった場合には、英語の内容が優先されます。

TR-4891 :『 SAP HANA disaster recovery with Azure NetApp Files 』

Nils Bauer 、 NetApp Ralf Klahr 、 Microsoft

調査によると、ビジネスアプリケーションのダウンタイムは企業のビジネスに大きな悪影響を与えることがわかっています。財務面での影響に加えて、ダウンタイムは企業の評判、スタッフの士気、顧客ロイヤルティを損なう可能性もあります。驚くべきことに、すべての企業が包括的なディザスタリカバリポリシーを持っているわけではありません。

SAP HANA on Azure NetApp Files ( ANF )を実行すると、 SAP HANA に組み込まれているデータ保護機能やディザスタリカバリ機能を拡張、向上させる追加機能を利用できます。この概要セクションでは、お客様がビジネスニーズをサポートするオプションを選択できるように、これらのオプションについて説明します。

包括的なディザスタリカバリポリシーを作成するには、データ保護とディザスタリカバリに必要なビジネスアプリケーションの要件と技術的な機能を理解する必要があります。次の図に、データ保護の概要を示します。

エラー:グラフィックイメージがありません

ビジネスアプリケーションの要件

ビジネスアプリケーションの主要な指標として、次の 2 つがあります。

  • Recovery Point Objective ( RPO ;目標復旧時点)、またはデータ損失の許容量の上限

  • Recovery Time Objective ( RTO ;目標復旧時間)、またはビジネスアプリケーションの最大許容ダウンタイム

これらの要件は、使用するアプリケーションの種類とビジネスデータの性質によって定義されます。1 つの Azure リージョンで障害から保護する場合は、 RPO と RTO が異なることがあります。また、 Azure リージョン全体の損失など、災害による災害に備える場合にも同じように、災害によって異なることがあります。RPO と RTO は、利用可能な技術的オプションに大きく影響するため、これらの要件によって定義されるビジネス要件を評価することが重要です。

高可用性

仮想マシン、ネットワーク、ストレージなど、 SAP HANA 用のインフラには、単一点障害がないように冗長コンポーネントが必要です。MS Azure は、さまざまなインフラコンポーネントに対して冗長性を提供します。

コンピューティング側とアプリケーション側で高可用性を実現するために、スタンバイの SAP HANA ホストは、 SAP HANA マルチホストシステムを使用して、組み込みの高可用性を実現するように構成できます。サーバまたは SAP HANA サービスに障害が発生すると、 SAP HANA サービスがスタンバイホストにフェイルオーバーするため、アプリケーションのダウンタイムが発生します。

サーバやアプリケーションの障害時にアプリケーションのダウンタイムが許容されない場合は、 SAP HANA システムのレプリケーションをハイアベイラビリティ解決策として使用して、非常に短時間でフェイルオーバーを実現することもできます。SAP のお客様は、 HANA システムレプリケーションを使用して、計画外障害に対する高可用性を実現できるだけでなく、 HANA ソフトウェアのアップグレードなどの計画的運用のダウンタイムを最小限に抑えることができます。

論理的破損

論理的破損は、ソフトウェアエラー、人為的エラー、破壊行為などが原因で発生する可能性があります。残念ながら、論理的破損は、標準的な高可用性ソリューションやディザスタリカバリソリューションでは対処できないことがよくあります。そのため、論理的破損が発生したレイヤ、アプリケーション、ファイルシステム、またはストレージによっては、 RTO と RPO の要件が満たされないことがあります。

最悪のケースは、 SAP アプリケーションが論理的に破損した場合です。SAP アプリケーションは多くの場合、異なるアプリケーションが相互に通信してデータを交換する環境で動作します。このため、論理的な破損が発生した SAP システムはリストアとリカバリを実行しないことを推奨します。システムを破損前の特定の時点にリストアするとデータが失われるため、 RPO はゼロより大きくなります。また、 SAP ランドスケープは同期されず、さらにポストプロセスが必要になります。

SAP システムをリストアする代わりに、別の修復システムで問題を分析して、システム内の論理エラーを修正する方法を推奨します。ルート原因分析には、ビジネスプロセスやアプリケーション所有者の関与が必要です。このシナリオでは、論理的破損が発生する前に格納されたデータに基づいて、修復システム(本番用システムのクローン)を作成します。リペアシステム内では、必要なデータをエクスポートし、本番システムにインポートできます。このアプローチでは、生産性の高いシステムを停止する必要はありません。また、最良のシナリオでは、データが失われたり、データの一部しか失われたりすることはありません。

注記 修復システムのセットアップに必要な手順は、このドキュメントで説明するディザスタリカバリのテストシナリオと同じです。そのため、説明したディザスタリカバリ解決策を拡張して、論理的な破損にも簡単に対処できます。

バックアップ

さまざまなポイントインタイムデータセットからリストアとリカバリを実行できるようにバックアップが作成されている。通常、これらのバックアップは数日から数週間保持されます。

破損の種類に応じて、データを損失するかどうかに関係なく、リストアとリカバリを実行できます。RPO をゼロにする必要がある場合は、プライマリストレージとバックアップストレージが失われた場合でも、バックアップを同期データレプリケーションと組み合わせる必要があります。

リストアとリカバリの RTO は、必要なリストア時間、リカバリ時間(データベースの起動を含む)、およびデータをメモリにロードすることによって定義されます。大規模なデータベースや従来のバックアップ方法では、 RTO が数時間に及ぶことがありますが、これは許容されない場合があります。RTO を大幅に短縮するには、バックアップを、データをメモリにプリロードすることを含むホットスタンバイ解決策と組み合わせる必要があります。

一方、バックアップ解決策は、データレプリケーションソリューションがあらゆる種類の論理的破損に対応できないため、論理的破損に対処する必要があります。

同期または非同期のデータレプリケーション

RPO は、主に、使用するデータレプリケーション方法を決定します。RPO をゼロにする必要がある場合は、プライマリストレージとバックアップストレージが失われた場合でも、データを同期的にレプリケートする必要があります。ただし、同期レプリケーションについては、 2 つの Azure リージョン間の距離などの技術的な制限があります。ほとんどの場合、同期レプリケーションは 100km を超えるレイテンシから受ける距離には適していないため、 Azure リージョン間でのデータレプリケーションには対応できません。

RPO を大きくすることが許容される場合は、長距離間で非同期レプリケーションを使用できます。この場合の RPO は、レプリケーションの頻度によって定義されます。

HANA システムのレプリケーションでデータプリロードを設定するかどうか

SAP HANA データベースの起動時間は、従来のデータベースよりもはるかに長くなります。これは、データベースが期待されるパフォーマンスを提供するためには、大量のデータをメモリにロードする必要があるためです。そのため、 RTO の大部分はデータベースの起動に必要な時間です。ストレージベースのレプリケーションに加えて、 HANA システムレプリケーションを事前ロードなしで実行する場合、ディザスタリカバリサイトにフェイルオーバーするためには、 SAP HANA データベースを起動する必要があります。

SAP HANA システムレプリケーションでは、データがプリロードされ、セカンダリホストで継続的に更新される動作モードが提供されます。このモードでは、 RTO の値が非常に低くなりますが、ソースシステムからのレプリケーションデータの受信にのみ使用される専用のサーバが必要になります。