Amazon Web Services ブログ
AWS サービスで SAP バックアップを簡素化
AWS で SAP を実行しているお客様にとって、データベースと SAP アプリケーションの非データベースファイルシステムを保護するには、強固なバックアップ戦略を持つことが不可欠です。バックアップは、データが失われた場合でもシステムを復旧できるため、SAP ワークロードの実行において重要な役割を果たします。サードパーティ、データベースネイティブ、AWS ネイティブなどオプションが多数用意されているため、適切なバックアップツールと戦略を選択することは複雑なプロセスになる可能性があります。各オプションを慎重に評価し、ビジネスニーズ、予算、IT インフラストラクチャ全体に最適なオプションを選択することが不可欠です。バックアップとリカバリの手順を適切に計画、実装、テストすることで、停電や災害が発生した場合でも、事業継続性を確保し、ダウンタイムを最小限に抑えることができます。
このブログでは、SAP HANA、Oracle、Microsoft SQL Server、SAP ASE データベースなど、AWS 上で実行されている SAP ワークロードで利用できるさまざまなバックアップオプションの概要を包括的に説明します。また、SAP アプリケーション固有の非データベースファイルシステムのバックアップの詳細についても詳しく説明します。目的は、AWS のネイティブサービスを使用して利用できるさまざまなバックアップソリューションを読者に明確に理解してもらい、どのオプションが自分の SAP ワークロードに最も適しているかを判断できるようにすることです。このブログを読み終える頃には、SAP ワークロードを保護し、予期しない障害やデータ損失が発生した場合の事業継続性を確保するために AWS でバックアップを設定する方法についての理解が深まるでしょう。
アーキテクチャー設計
以下のアーキテクチャ設計は、AWS 上の SAP ワークロードのバックアップアプローチの概要を示しています。
データベースのバックアップから始めましょう
データベースのバックアップから始めましょう。データベースを任意の時点に復元できるバックアップをすることで、システム停止前の状態にできるだけ近い状態に復元できます。復元するには、次の 2 種類のバックアップを実行する必要があります。
- データベースのバックアップ: フルバックアップ、増分バックアップ、または差分バックアップ
- トランザクションログのバックアップ
アプリケーションレベルで実行されるデータベース全体のバックアップに加えて、トランザクションログのバックアップは、データベースを特定の時点に復元したり、コミットされたトランザクションが永続レベルで保存された後にディレクトリからログを空にしたりするために重要です。
Amazon S3 は、あらゆる規模や業界のお客様があらゆる量のデータを保存および保護できるため、データベースのバックアップを保存するための理想的なストレージソリューションを提供します。Amazon S3 のバックアップストレージと、Amazon S3 でデータベースを直接バックアップ/復元する方法の自動化によるデータベースの保護に重点を置きます。これにより、Amazon Elastic Block Storage (EBS) と Amazon Elastic File System (EFS) の中間ストレージにコストがかからないようになります。また、自動化されたAmazon S3 ライフサイクルポリシーにより、バックアップを Amazon S3-IA および Amazon Glacier ストレージに移動し、コストを削減することができます。これについては、このブログの後のセクションで説明します。また、バックアップは Amazon S3 バケットレプリケーションを使用して DR リージョンへレプリケートし、災害発生時に復旧することもできます。データ保護は、転送中のデータだけでなく保存中のデータに対しても提供されます。転送中のデータ保護は SSL 経由で、保存中のデータ保護は 256 ビットの高度暗号化標準 (AES-256) で提供されます。
SAP HANA データベース
- AWS チームは AWS Backint Agent for SAP HANAを開発しました。これは、データベースのバックアップ/復元操作を可能にする SAP 認定ソリューションです。AWS Backint Agent は SAP HANA データベースを Amazon S3 にバックアップし、SAP HANA Cockpit、SAP HANA Studio、SQL コマンドなどの SAP 管理ツールを使用して復元します。AWS Backint Agent は、Amazon S3 標準、S3 標準 – 低頻度アクセス (IA)、および S3 1 ゾーン – 低頻度アクセス (IA) へのバックアップをサポートしています。AWS Backint Agent を使用しても費用はかかりません。お支払いいただくのは、実際に使用した基盤となる AWS サービスに対してのみです。
- AWS Backup は AWS Backint Agent と統合されており、SAP HANA のバックアップとリストアを実行します。AWS Backup は、Amazon EC2 上で稼働する SAP HANA データベース向けに、シンプルで費用対効果が高く、アプリケーションと整合性のあるバックアップと復元ソリューションを提供します。AWS Backup for SAP HANA は、一元化されたコンソールベースのバックアップ管理を提供し、サポートされるすべての AWS リソースで一貫した操作を提供します。機能には、IAM ポリシーによるセキュリティの向上、専用のバックアップボールト、標準化された AWS の監視およびレポート機能へのアクセス、継続的なバックアップを最適化してポイントインタイムリカバリを行うインテリジェンスなどがあります。AWS Backup と AWS Organizations のシームレスな統合により、すべてのアカウントで SAP HANA データベースの不変なバックアップを作成して管理し、不注意や悪意のあるアクションからデータを保護し、データを復元できます。詳細については、こちらの AWS ドキュメントを参照してください。
Oracle データベース
- AWS 上の Oracle データベース で SAP を実行していて、Oracle データベースのバックアップアプローチにネイティブ AWS サービスを活用したいと考えているお客様もいます。Oracle Database 9i リリース 2 以降、Oracle は Oracle データベースのバックアップ媒体として Amazon S3 の機能を拡張するセキュアバックアップ クラウドモジュールを導入しました。Oracle Secure Backup (OSB) モジュールをサーバーにインストールすると、Amazon S3 バケットからデータベースのバックアップと復元の操作を直接実行できます。OSB を使用すると、バックアップ設定に使用される RMAN コマンドを少し変更するだけで、RMAN は Oracle データベースを Amazon S3 にバックアップできます。バックアップ実行に使用される RMAN コマンドは、テープではなく Amazon S3 を指す必要がある「destination」パラメータを除いて変更はありません。RMAN を使用すると、複数のバックアップチャネルを指定して並列処理を強化し、バックアップを高速化できます。ただし、この方法ではネットワーク帯域幅をより多く利用する可能性があります。このアプローチを使用すると、Oracle データベース バックアップを 30 分以内に構成し、5.5 TB サイズのデータベースのバックアップを 1 時間 45 分以内に実行できました。
- Oracle で SAP ワークロードを実行しているお客様は、AWS ネイティブ EBS のマルチボリューム クラッシュコンシステント スナップショットを利用して、Oracle データベースのバックアップとリカバリを行うことができます。スナップショットにはフルバックアップが 1 つしか保持されず、残りはデルタスナップショットになるため、この手順はストレージコストの節約に役立ちます。さらに、バックアップの即時復元が必要な場合は、Amazon EBS 高速スナップショット復元を適用して復元速度を向上させることができます。このアプローチの利点については、ケロッグのお客様事例をご覧ください。
Microsoft SQL Server データベース
- Microsoft Windows 上の Microsoft SQL Serverには、Amazon S3 で直接バックアップ/復元操作を実行するオプションもあります。この機能を利用するには、バックアップスクリプトの Amazon S3 バケット URL をバックアップターゲットとして使用するだけです。以下の内容でバックアップスクリプトを更新してください。詳細な手順については、このドキュメントを参照してください。
Set @FullName = ‘s3://<bucketname>.s3.<region-name>.amazonaws.com/<FolderName>/
BACKUP DATABASE <SID> to URL = @FullName - Microsoft Windows 上で実行されている Microsoft SQL Server は、VSS (ボリュームシャドウコピーサービス) 機能を使用して、整合性のとれた データベースのバックアップを実行することもできます。VSS は AWS Backup とも統合されているため、バックアップ/リストア操作の管理が容易になります。詳細な設定とテスト手順については、ブログを参照してください。
SAP ASE データベース
- SAP ASE (Adaptive Server Enterprise) データベースで SAP ワークロードを実行しているお客様は、バックアップストレージとして Amazon S3 を利用することもできます。このソリューションでは、AWS ファイルゲートウェイが HTTPS 接続を介してデータを Amazon S3 に非同期で転送する必要があります。さらに、SAP は詳細な分析を行い、この方法の設定手順を含むソリューションを共有しました。
- 他のデータベースと同様に、SAP ASE データベースでは、バックアップと復元操作に Amazon EBS スナップショットを利用することもできます。Amazon EBS スナップショットを使用して SAP ASE データベースでバックアップ/復元操作を実行および自動化する詳細な手順については、このブログを参照してください。
適切な S3 ストレージ階層でコンプライアンスを管理
バックアップストレージの保存期間に関しては、組織によってコンプライアンス要件が異なります。これらのコンプライアンス要件は、組織全体のポリシー、SAP システムの重要性、または監査上の要件によって導かれる場合があります。コンプライアンス要件によって、バックアップの種類 (フル/増分)、バックアップの保持期間、および復元にかかる許容時間が決まります。
Amazon S3 サービスはデータベースバックアップの保存に最適なストレージです。S3 にはさまざまなストレージクラスが用意されているため、ユーザーはデータアクセス速度、ストレージコスト、データ取り出しコストの優先順位に基づいてストレージクラスを選択できます。SAP データベースバックアップの保存に使用する適切な S3 ストレージクラスを決定する主な要因は、次の 3 つです。
- バックアップへのアクセスと復元に許可される最大時間
- バックアップにかかる費用
- バックアップの保存期間を規定する企業/業界の規制要件の遵守
ストレージクラス | アクセス/取り出しスピード | 最小ストレージ期間 | コスト要因 |
S3 標準 | ミリ秒 | 無し | ストレージ |
S3 標準 – IA | ミリ秒 | 30 日 | ストレージ + GB あたりの取り出しコスト |
S3 1 ゾーン – IA | ミリ秒 | 30 日 | ストレージ + GB あたりの取り出しコスト |
S3 Glacier Instant Retrieval | ミリ秒 | 90 日 | ストレージ + GB あたりの取り出しコスト |
S3 Glacier Flexible Retrieval | 分〜時間 | 90 日 | ストレージ + GB あたりの取り出しコスト |
S3 Glacier Deep Archive | 時間 | 180 日 | ストレージ + GB あたりの取り出しコスト |
バックアップストレージの最適なコストを決定する際には、SAP データベースバックアップの全体的なコストに影響を与える「最小ストレージ期間」の要素も考慮する必要があります。S3 標準 は他のクラスに比べてストレージコストが高くなりますが、最小ストレージ期間はありません。S3 標準は、バックアップ保持要件がなく、1 週間以内のリストアポイントで良いというお客様にとって、最も費用対効果の高いバックアップストレージクラスになります。
コンプライアンス要件が数週間にわたるお客様
数週間(30 日以内)のバックアップデータを維持する必要があるという規制要件があるお客様は、S3 標準と S3 -標準 IA を組み合わせてバックアップを保存できます。
- プライマリデータベースの障害/破損の場合に関連性の高い最新のバックアップは、S3 標準に保存できます (例:過去 7 日間のバックアップ)。これにより、「最小ストレージ期間」の要件によるストレージコストのオーバーヘッドなしに、バックアップからの復元が最短時間で行うことができます。
- 古いバックアップは、可用性要件に基づいて S3 標準- IA または S3 1 ゾーン – IA のいずれかに保存できるため、復元時間に影響を与えずに古いバックアップの全体的なストレージコストを最小限に抑えることができます。
数ヶ月にわたるコンプライアンス要件を持つお客様
コンプライアンス要件により、数か月間(3 か月以内)のデータバックアップを維持することが義務付けられているお客様は、S3 標準 と S3 Glacier を組み合わせてバックアップを保存できます。
- プライマリデータベースの障害/破損の場合に関連性の高い最新のバックアップは、S3 標準に保存できます (例:過去 7 日間のバックアップ)。これにより、「最小ストレージ期間」の要件によるストレージコストのオーバーヘッドなしに、バックアップからの復元時間を最短で行うことができます。
- 古いバックアップは、復元時間要件の柔軟性に応じて S3 Glacier Instant Retrievalまたは S3 Glacier Flexible Retrieval のいずれかに保存できます。
コンプライアンス要件が定義されていないお客様
コンプライアンス要件が明確に定義されていない、またはコンプライアンス要件が不明確なお客様は、S3 Intelligent – Tiering の使用を選択できます。S3 Intelligent – Tiering は、アクセスパターンに基づいてオブジェクトを適切な S3 ストレージ階層に保存することを決定することで、ストレージコストを最適化します。S3 Intelligent – Tiering はオブジェクトのアクセスパターンを監視し、30 日間連続してアクセスがなかった場合は、データを低頻度アクセス階層に自動的に移動します。連続90日を経過したオブジェクトは、アーカイブインスタントアクセス階層に移動されます。
ファイルシステムのバックアップ
前のセクションでデータベースバックアップオプションについて説明したので、次はデータベース部分以外のバックアップオプションに焦点を当てます。通常、SAP ワークロードの Amazon EC2 インスタンスには、Amazon EBS と Amazon EFS の 2 種類のボリュームがアタッチされています。このセクションでは、両方のタイプのボリュームのバックアップ方法について説明します。
データベース以外の EBS ボリュームバックアップ
SAP サーバーにはルートボリュームや SAP アプリケーション固有のボリュームなど、データベースの一部ではないいくつかの Amazon EBS ボリュームがアタッチされています。データが失われた場合に備えて、これらのボリュームをバックアップして復旧することが不可欠です。AWS Backup は、クラウド内の AWS サービス全体のデータをバックアップできる一元管理型サービスです。AWS Backup では、Amazon EBS ボリュームや Amazon EC2 インスタンスなど、さまざまな AWS リソースのバックアップ、復元、ポリシーベースの保持を 1 つのダッシュボードで行えます。AWS Backup は、以前はサービスごとに実行されていたバックアップタスクを自動化して統合するため、カスタムスクリプトや手動プロセスを作成する必要がありません。
SAP アプリケーションサーバーの場合、AWS Backup を使用して Amazon EC2 インスタンス全体をバックアップできます。または、ルートボリュームを含む個々の Amazon EBS ボリュームをバックアップして特定のファイルを復元する必要がある場合に、それぞれの Amazon EBS ボリュームを復元できるようにすることもできます。データベースサーバーでは、データベース固有のツールを使用してデータベースのバックアップがすでに行われているため、データボリュームとログボリュームを除くすべての Amazon EBS ボリュームをバックアップできます。Commvault などのサードパーティツールでも、特定のボリュームをスキップして Amazon EC2 インスタンスをバックアップできますので、 Amazon EC2 インスタンスをバックアップする代替オプションになり得ます。
共有ファイルシステムのバックアップ
/sapmnt、/usr/sap/trans、/interfaces などの共有ファイルシステムは、SAP アプリケーションに不可欠な部分です。AWS のお客様は、これらの共有ファイルシステムのために、 Linux ベースのシステムでは Amazon EFS を使用し、Microsoft Windows ベースのシステムでは Amazon FSx for Windows ファイルサーバーを使用しています。AWS Backup は、Amazon EFS と Amazon FSx のファイル共有の両方をバックアップするために使用できます。AWS Backupは Amazon EFS とネイティブに統合されているため、AWS Backupによって開始された I/O 操作は Amazon EFS バーストクレジットや汎用モードの制限にはカウントされません。AWS Backup には、Amazon EFS ファイルシステムのバックアップをウォームストレージから低コストのコールドストレージ階層に移行するオプションもあります。
まとめ
結論として、バックアップと復旧は、AWS 上で実行される SAP ワークロードの重要なコンポーネントです。さまざまなバックアップオプションが用意されているため、特定のワークロードに最適なものを判断するのは難しい場合があります。私たちのブログでは、SAP HANA、Oracle、Microsoft SQL Server、SAP ASE データベース、データベース以外のファイルシステムなど、利用可能なさまざまなバックアップソリューションの概要を紹介しています。各ソリューションの違いと機能を理解することで、読者はビジネスニーズと IT インフラストラクチャを満たす適切なバックアップ戦略を選択できるようになります。バックアップを正しく構成することは、災害発生時にデータを保護し、事業継続性を確保するために不可欠です。このブログが、読者が AWS 上で実行されている SAP ワークロードについて情報に基づいた意思決定を行い、バックアップと復旧の手順を最適化するのに役立つことを願っています。
何千ものお客様が SAP ワークロードの移行、最新化、革新において AWS を信頼している理由については、SAP on AWS ページをご覧ください。
翻訳は Specialist SA 菅谷が担当しました。原文はこちらです。