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

NetApp 解決策の略

寄稿者

Azure NetApp Files の NetApp Snapshot テクノロジを使用すれば、データベースのバックアップを数秒で作成できます。Snapshot コピーではストレージプラットフォーム上の物理データブロックは移動されないため、 Snapshot コピーの作成に要する時間はデータベースのサイズに左右されません。また、 Snapshot テクノロジを使用しても、稼働中の SAP システムのパフォーマンスには影響しません。そのため、対話形式またはバッチでのアクティビティのピーク期間を考慮せずに、 Snapshot コピーの作成をスケジュールできます。Azure NetApp Files を使用する SAP のお客様は、通常、複数のオンライン Snapshot バックアップを毎日実行するようにスケジュールを設定します。たとえば、一般的には 4 時間おきにバックアップを実行します。作成された Snapshot バックアップをプライマリストレージシステムに 3~5 日間保持しています。

Snapshot コピーは、リストア処理とリカバリ処理にも大きなメリットがあります。ボリュームのリバート処理を使用すると、使用可能な Snapshot コピーに基づいて、任意の時点までのデータベース全体をリストアできます。このようなリストアプロセスは、データベースのサイズに関係なく数秒で完了します。オンラインの Snapshot バックアップは 1 日に数回作成されるため、従来のバックアップ方式に比べて、リカバリプロセスに要する時間が大幅に短縮されます。24 時間以内ではなく数時間前の Snapshot コピーを使用してリストア処理を実行できるため、適用するトランザクションログの数を少なくする必要があります。そのため、従来のシングルサイクルバックアップでは数時間かかっていた RTO が数分に短縮されます。

Snapshot コピーバックアップは、アクティブなオンラインデータと同じディスクシステムに格納されます。セカンダリストレージへのバックアップに代わる手段としてではなく、補助的な用途で使用することを推奨します。リストアとリカバリのほとんどはプライマリストレージシステムでボリュームリバート処理を使用して実行されます。セカンダリストレージからのリストアが必要になるのは、 Snapshot コピーが格納されているプライマリストレージシステムが損傷している場合のみです。セカンダリストレージは、 Snapshot コピーから削除したバックアップをリストアする必要がある場合に使用できます。

HANA の追加のファイルベースのバックアップを使用して、セカンダリサイトにバックアップできます。このようなファイルベースのバックアップは、実行頻度を大幅に低くしてスケジュールを設定できるため、本番用システムのパフォーマンスへの影響も少なくなります。

ディザスタリカバリに Azure NetApp Files のクロスリージョンレプリケーションを使用すると、すべての Snapshot バックアップがディザスタリカバリサイトにもレプリケートされ、その後、オフロードされたセカンダリバックアップとしても使用できるようになります。も参照してください "TR-4891 :『 SAP HANA disaster recovery with Azure NetApp Files 』"

Azure AzCopy ツールを使用して、長期保持用の Snapshot コピーを Azure BLOB ストレージにオフロードすることもできます。これには、 SnapCenter サービス外で追加のスクリプトを作成する必要があります。

次の図に、 Snapshot バックアップとファイルベースのバックアップを使用したデータ保護構成の例を示します。

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

Snapshot バックアップの実行時間

次の図は、ネットアップストレージ上で SAP HANA を実行しているお客様の HANA Studio のスクリーンショットです。お客様が、 NetApp Snapshot コピーを使用して HANA データベースをバックアップしている。この図に示すように、 Snapshot バックアップテクノロジを使用して、 HANA データベース(約 2.3TB )を 2 分 11 秒でバックアップしています。

全体的なバックアップワークフローランタイムの最大の部分は、 HANA のバックアップセーブポイント処理の実行に必要な時間です。この手順は、 HANA データベースの負荷によって異なります。ストレージ Snapshot バックアップ自体は、数秒で完了します。

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

目標復旧時間の比較

このセクションでは、ファイルベースとストレージベースの Snapshot バックアップの RTO 比較を示します。RTO は、データベースのリストアに必要な時間と、データベースの起動およびリカバリに必要な時間の合計によって定義されます。

データベースのリストアに必要な時間

ファイルベースのバックアップでは、リストアに要する時間はデータベースのサイズとバックアップインフラによって異なり、リストアにかかる時間は 1 秒あたりのメガバイト数( MBps )で定義されます。たとえば、インフラで 250MBps の高速なリストア処理がサポートされている場合、データベースのサイズが 1TB にリストアされるまでに約 1 時間 10 分かかります。

ストレージ Snapshot コピーバックアップでは、リストア時間はデータベースのサイズに左右されず、プライマリストレージからのリストアを実行できる数秒の範囲になります。ファイルベースのバックアップからのリストアが必要になるのは、プライマリストレージが使用できなくなったときに災害が発生した場合だけです。

データベースの起動に必要な時間

データベースの開始時間は、行および列ストアのサイズによって異なります。列ストアの場合、開始時間は、データベースの起動時にプリロードされるデータの量によっても異なります。次の例では、開始時間は 30 分であると想定しています。開始時刻は、ファイルベースのリストアとリカバリ、および Snapshot コピーに基づくリストアとリカバリで同じです。

データベースのリカバリに要する時間

リカバリ時間は、リストア後に適用する必要があるログの数によって異なります。この数は、データバックアップを実行する頻度によって決まります。

ファイルベースのデータバックアップでは、通常、バックアップスケジュールは 1 日に 1 回となります。バックアップによって本番環境のパフォーマンスが低下するため、通常はバックアップ頻度を高くすることはできません。したがって、最悪の場合は、フォワードリカバリ時に 1 日中に書き込まれたすべてのログを適用する必要があります。

ストレージ Snapshot コピーのデータバックアップは、通常、 SAP HANA データベースのパフォーマンスに影響しないため、頻繁にスケジュールされます。たとえば、 Snapshot コピーのバックアップが 6 時間ごとにスケジュールされている場合、最悪の場合、ファイルベースのバックアップに関しては、リカバリ時間の 4 分の 1 ( 6 時間 /24 時間 = 1/4 )になります。

次の図に、ファイルベースのデータバックアップを使用する場合の 1TB データベースの RTO の例を示します。この例では、バックアップが 1 日に 1 回作成されます。RTO は、リストアとリカバリの実行タイミングによって異なります。バックアップの作成直後にリストアとリカバリを実行した場合の RTO は、主にリストア時間に基づきます。この例では、 1 時間 10 分です。リカバリ時間は、次のバックアップが作成される直前にリストアとリカバリが実行され、最大 RTO は 4 時間 30 分になりました。

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

次の図に、 Snapshot バックアップの使用時の 1TB データベースの RTO の例を示します。ストレージベースの Snapshot バックアップでは、データベースのサイズに関係なく数秒でリストアが完了するため、 RTO はデータベースの開始時間と転送リカバリ時間にのみ左右されます。また、リストアとリカバリの実行時間によってもフォワードリカバリの時間が長くなりますが、バックアップの頻度が高いため(この例では 6 時間ごと)、転送リカバリの時間は最大 43 分です。この例では、最大 RTO は 1 時間 13 分です。

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

次の図に、データベースサイズや Snapshot バックアップの頻度に応じた、ファイルベースとストレージベースの Snapshot バックアップの RTO 比較を示します。緑のバーは、ファイルベースのバックアップを示しています。その他のバーには、バックアップ頻度が異なる Snapshot コピーのバックアップが表示されます。

1 日に 1 回の Snapshot コピーでデータをバックアップする RTO は、ファイルベースのデータバックアップに比べてすでに 40% 短縮されています。1 日に 4 つの Snapshot バックアップを作成すると、削減率は 70% になります。また、 Snapshot のバックアップ頻度を 1 日あたり 4~6 個の Snapshot バックアップに増やすと、この図ではフラットな状態になります。したがって、お客様は通常、 1 日に 4~6 個の Snapshot バックアップを作成します。

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

このグラフには、 HANA サーバの RAM サイズが表示されます。メモリ内のデータベースサイズは、サーバの RAM サイズの半分になるように計算されます。

リストアとリカバリの時間は、次の前提に基づいて計算されます。データベースは 250MBps でリストアできます。 1 日にリストアできるログファイルの数は、データベースサイズの 50% です(たとえば、 1TB のデータベースで 1 日に 500MB のログファイルが作成されます)。 リカバリは 100Mbps で実行できます。