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

SAP HANAの高可用性の概要

03/20/2025 共同作成者

この章では、アプリケーションレイヤでのレプリケーションとストレージレプリケーションを比較した、SAP HANAの高可用性オプションの概要を説明します。

SAP HANAシステムレプリケーション（HSR）

SAP HANAシステムレプリケーションでは、データが同期的にレプリケートされ、メモリにプリロードされ、セカンダリホストで継続的に更新される処理モードが提供されます。このモードでは、RTO値は約1分以下と非常に低くなりますが、ソースシステムからのレプリケーションデータの受信にのみ使用される専用サーバも必要です。フェイルオーバー時間が短いため、SAP HANAシステムのレプリケーションは、HANAソフトウェアのアップグレードなど、ダウンタイムがほぼゼロのメンテナンス処理にもよく使用されます。通常、Linux Pacemakerクラスタソリューションは、フェイルオーバー処理の自動化に使用されます。

プライマリサイト、ストレージ、ホスト、または完全なサイトで障害が発生した場合、HANAシステムはLinux Pacemakerクラスタで制御されているセカンダリサイトに自動的にフェイルオーバーします。

すべての設定オプションとレプリケーションシナリオの詳細については、を参照してください "SAP HANAシステムレプリケーション| SAPヘルプポータル"。

NetApp SnapMirrorアクティブ同期

SnapMirror Active Syncを使用すると、サイト全体に障害が発生してもビジネスサービスの運用を継続できるため、アプリケーションがセカンダリコピーを使用して透過的にフェイルオーバーできるようになります。SnapMirrorアクティブ同期でフェイルオーバーをトリガーするための手動操作やカスタムスクリプトは必要ありません。SnapMirrorアクティブ同期は、AFFクラスタ、オールフラッシュSANアレイ（ASA）クラスタ、およびCシリーズ（AFFまたはASA）でサポートされます。SnapMirrorアクティブ同期は、iSCSI LUNまたはFCP LUNを使用してアプリケーションを保護します。

ONTAP 9.15.1以降では、SnapMirrorアクティブ同期で対称アクティブ/アクティブ機能がサポートされます。対称アクティブ/アクティブ：双方向同期レプリケーションにより、保護されたLUNの両方のコピーからの読み取りおよび書き込みI/O処理を有効にし、両方のLUNコピーがローカルでI/O処理を処理できるようにします。

詳細については、を参照してください "ONTAPでのSnapMirrorアクティブ同期の概要"。

HANAベアメタル

ベアメタルサーバでSAP HANAを実行している場合は、SnapMirrorアクティブ同期を使用して可用性の高いストレージソリューションを提供できます。データは同期的にレプリケートされるため、RPO=0になります。

ストレージ障害が発生した場合、HANAシステムは2つ目のFCPパスを使用してセカンダリサイトのミラーコピーに透過的にアクセスし、RTO = 0を実現します。

ホストまたはサイト全体に障害が発生した場合は、障害が発生したホストのデータにアクセスするために、セカンダリサイトに新しいサーバを用意する必要があります。これは通常、本番システムと同じサイズのテストシステムまたはQAシステムで、シャットダウンして本番システムの実行に使用します。セカンダリサイトのLUNを新しいホストに接続したら、HANAデータベースを起動する必要があります。そのため、合計RTOは、ホストのプロビジョニングに必要な時間とHANAデータベースの起動時間に左右されます。

vSphere Metro Storage Cluster（vMSC）

FCPに接続されたデータストアを使用するVMware環境でSAP HANAを実行している場合は、SnapMirrorのアクティブ同期を使用してVMware Metroストレージクラスタを構築できます。このようなセットアップでは、HANAシステムで使用されるデータストアがセカンダリサイトに同期的にレプリケートされます。

ストレージに障害が発生した場合、ESXホストはセカンダリサイトのミラーコピーに自動的にアクセスし、RTO = 0を実現します。

ホストまたはサイト全体に障害が発生した場合は、vSphere HAを使用してセカンダリESXホストでHANA VMを起動します。HANA VMを実行したら、HANAデータベースを起動する必要があります。そのため、総RTOは主にHANAデータベースの起動時間に依存します。

ソリューションの比較

次の表は、上記のソリューションの主な特徴をまとめたものです。

	HANA システムレプリケーション	SnapMirrorアクティブ同期–ベアメタル	SnapMirrorアクティブ同期–VMware vMSC
障害発生時のRPO	RPO = 0 +同期レプリケーション
ストレージ障害時のRTO	RTO <1分	RTO = 0 +透過的なストレージフェイルオーバー
サイトまたはホストの障害が発生した場合のRTO +	RTO <1分	RTO：サーバの準備とHANAデータベースの起動に必要な時間によって異なります。	RTO：HANAデータベースの起動に必要な時間によって異なります。
フェイルオーバーの自動化	はい、セカンダリHSRホストへの自動フェイルオーバー Pacemakerクラスタによって制御されます。	○（ストレージ障害の場合）いいえ（ホストまたはサイトの障害）（ホストのプロビジョニング、ストレージリソースの接続、HANAデータベースの起動）	○（ストレージ障害の場合） ○（ホストまたはサイトの障害時）（他のサイトへのVMのフェイルオーバーは、vSphere HAとHANAデータベースの起動によって自動化されます）
セカンダリサイトに専用サーバが必要	はい、データをメモリにプリロードし、データベースの起動なしで高速フェイルオーバーを実現するために必要です。	いいえ、サーバは、フェールオーバーの場合にのみ必要です。通常、QAに使用されるサーバは本番環境に使用されます。	いいえ、 ESXホストのリソースは、フェイルオーバーの場合にのみ必要です。通常、QAリソースは本番環境に使用されます。

HANA システムレプリケーション

SnapMirrorアクティブ同期–ベアメタル

SnapMirrorアクティブ同期–VMware vMSC

障害発生時のRPO

RPO = 0 +同期レプリケーション

ストレージ障害時のRTO

RTO <1分

RTO = 0 +透過的なストレージフェイルオーバー

サイトまたはホストの障害が発生した場合のRTO +

RTO <1分

RTO：サーバの準備とHANAデータベースの起動に必要な時間によって異なります。

RTO：HANAデータベースの起動に必要な時間によって異なります。

フェイルオーバーの自動化

はい、

セカンダリHSRホストへの自動フェイルオーバー

Pacemakerクラスタによって制御されます。

○（ストレージ障害の場合）

いいえ（ホストまたはサイトの障害）

（ホストのプロビジョニング、ストレージリソースの接続、HANAデータベースの起動）

○（ストレージ障害の場合）

○（ホストまたはサイトの障害時）

（他のサイトへのVMのフェイルオーバーは、vSphere HAとHANAデータベースの起動によって自動化されます）

セカンダリサイトに専用サーバが必要

はい、

データをメモリにプリロードし、データベースの起動なしで高速フェイルオーバーを実現するために必要です。

いいえ、

サーバは、フェールオーバーの場合にのみ必要です。通常、QAに使用されるサーバは本番環境に使用されます。