Google Cloud 上の SAP デプロイの復元性

このドキュメントでは、Google Cloud で復元性と信頼性の高い SAP システムを実行する際に役立つ設計上の考慮事項について説明します。

インフラストラクチャとソフトウェアについては障害が発生する可能性があります。このような障害の原因と範囲により、Google Cloud インフラストラクチャを最大限に活用するには、SAP システムのデプロイで特定の原則に従う必要があります。インフラストラクチャ オプションと、復元性のある SAP ソフトウェアのデプロイ アーキテクチャを組み合わせることで、データの完全性と、データ損失やシステムが利用できない状態に対する保護を実現します。

復元性と信頼性のオプション

インフラストラクチャ レイヤとアプリケーション レイヤの両方の機能を活用して障害を吸収するか、障害からの復旧を可能にすることで、復元性と堅牢性に優れたシステムをデプロイできます。Google Cloud での SAP システムのデプロイにおける復元性と信頼性を確保するには、次のオプションを検討することをおすすめします。

  • プラットフォームの復元性: Google Cloud のサービスとプロダクトは、復元性を念頭に設計されており、公開されているサービスレベル契約を達成するために冗長性が組み込まれています。Google Cloud のガイドラインとベスト プラクティスに従って SAP システムをデプロイすると、基盤となるプラットフォーム メカニズムによって SAP システムの復元性が向上します。これにより、エラーや障害が発生した場合でも、ビジネス オペレーションを継続できます。
  • 高可用性（HA）: HA をサポートするインフラストラクチャとソフトウェアの構成を使用すると、中断を最小限に抑えてシステムの自動復元を有効にできます。また、基盤となるインフラストラクチャやアプリケーション ソフトウェアの一部で障害が発生した場合に、最小限の介入で済むようになります。HA は、システム コンポーネントに冗長性を付与することで、単一コンポーネントの障害や劣化からシステムを保護することを目的としています。
  • 障害復旧（DR）: DR は、障害によるエラーが発生した場合に、ビジネス オペレーションの復旧を可能にします。DR では、サービスとアプリケーションを物理的に分離させており、オペレーションを継続可能なセカンダリ ロケーションに移動します。DR システムは、単一のコンポーネントまたはサービスの障害の範囲を超えて、発生頻度は低いものの影響がより大きなイベントを軽減します。これには、自然災害、電力網の喪失などの地域的な事象や、火災や人為的ミスなどの局所的な事象が含まれます。DR プロビジョニングには次の内容が含まれます。
    • データ レプリケーション: ソフトウェア レプリケーションまたはストレージ レベルのレプリケーションを使用して、データ損失の可能性を最小限に抑えながら、データをセカンダリ ロケーションに転送できます。
    • バックアップ: プライマリ データ ストレージとは別に保存されているバックアップを使用して、システムまたはデータベースを復元できます。これには、Cloud Storage にアップロードされたスナップショットやバックアップの使用が含まれます。ただし、スナップショットまたはバックアップがシステムがデプロイされているリージョン以外に保存されている必要があります。

これらのオプションは補完的であるため、各オプションの要素を組み合わせて、SAP デプロイメント内の復元性を高めることができます。選択したオプションは、デプロイの目標復旧時間（RTO）と目標復旧時点（RPO）に影響します。したがって、システムの復元性とビジネスの継続性に与える影響と比較した場合のこれらのオプションの費用も評価する必要があります。利用可能なすべてのオプションを慎重に検討し、障害復旧の目標に合わせて実装することをおすすめします。

次のセクションでは、SAP デプロイの例と、さまざまな HA と DR の構成が復元性と信頼性に与えることが考えられる影響について説明します。

サンプル事例

Google Cloud での SAP S/4HANA のスケールアップ デプロイを検討します。次の表に、このデプロイに適用できる HA と DR の構成例と、可用性、RTO、RPO などのシステムの復元性と信頼性のディメンションへの考えられる影響を示します。

HA または DR 構成 復元性または信頼性のディメンション 予定
HA 構成。次の点を考慮してください。
  • us-central1 はプライマリ リージョンです。
  • X4 インスタンスが 2 つの異なるゾーン（例: us-central1-a と us-central1-b）にデプロイされています。
 対象
  • システム全体で 99.99% 以上。
  • 個別のインスタンスで 99.9% 以上。
完全にメモリ常駐型の DR システムに非同期 SAP HANA システム レプリケーションを使用する DR 構成。次の点を考慮してください。
  • us-central1 はプライマリ ロケーションです。
  • us-east4 は DR ロケーションであり、プライマリ ロケーションと同じサイズの X4 インスタンスを実行します。
  • データは、DR ロケーションで SAP HANA を実行している X4 インスタンスにプリロードされます。
  • DR ロケーションでは、アプリケーション サーバーがプロビジョニングされているか、アプリケーション サーバーの予約を購入しています。注 1
 復旧までの時間 数時間（DNS がクライアント システムに伝播するのに必要な時間が含まれる場合があります）。
復元ポイント 最後の非同期レプリケーションからの経過時間（分単位）。
事前プロビジョニングされたインフラストラクチャでバックアップを使用する DR 構成 注 1。Backint ベースのバックアップと復元を使用するシステムについて考えてみましょう。 復旧までの時間 バックアップからデータベースを復元するのに要する時間 注 2。
復元ポイント SAP HANA ログのバックアップまたはスナップショットの最後の時点。
インフラストラクチャが事前プロビジョニングされていないバックアップを使用する DR 構成 注 3。Backint ベースのバックアップと復元を使用するシステムについて考えてみましょう。 復旧までの時間 インフラストラクチャ 注 4 をプロビジョニングし、バックアップ 注 3 からデータを復元するまでに数日要します。
復元ポイント SAP HANA ログのバックアップまたはスナップショットの最後の時点。

表の注記:

  1. 必要なリソースを事前に予約することで、必要なインフラストラクチャを事前プロビジョニングせずに DR ソリューションをデプロイできます。これは、プライマリのロケーションで障害が発生したために DR ソリューションを有効にする必要がある場合に、必要なリソースの可用性を確保する方法です。詳細については、Compute Engine ゾーンリソースの予約をご覧ください。

  2. 復元オペレーションの実行時間は、使用しているバックアップ ソリューションとバックアップ ファイルのサイズによって大きく異なります。データベースのサイズと変更率に対して予測される時間を正確に把握するには、使用するバックアップ ソリューション（例: Backint、ディスク スナップショット）の復元速度を評価する必要があります。

  3. 必要なリソースを事前プロビジョニングまたは予約せずに DR ソリューションをデプロイすると、必要なリソースを使用できない状態になる可能性があります。これにより、デプロイの復元に要する時間が長くなり、ビジネス オペレーションに影響する可能性があります。

  4. X4 などのマシンタイプはオンデマンドで利用できず、注文する必要があります。事前に容量を予約していない場合は、数週間のリードタイムが必要になる可能性があります。

上記の表に記載されている情報は、業界ガイドラインから導き出された既存の設計と障害復旧計画の補足としてご検討ください。詳しくは、次のリソースをご覧ください。

復元性に優れたデプロイに関する推奨事項

以下の各セクションでは、Google Cloud に復元性と信頼性の高い SAP ワークロードをデプロイするために推奨される HA 構成と DR 構成の概要について説明します。

ビジネスに不可欠な本番環境オペレーションをホストする SAP ワークロードにこれらの推奨事項を実装することを強くおすすめしますが、長時間のサービス停止がビジネス オペレーションに悪影響を及ぼす可能性がある非本番環境の SAP システムにも実装できます。

推奨事項については、次のセクションをご覧ください。

高可用性に関する推奨事項

  • インスタンスのデプロイには、同じリージョン内の少なくとも 2 つの異なるゾーンを使用します。
  • 単一障害点を排除します。これを実現するには、障害が発生した場合に障害のあるサービスやアプリケーション コンポーネントに復元性と冗長性を持たせるリソースを追加します。
  • 冗長性が組み込まれているリージョン サービスを使用します。たとえば、共有ファイルのホスティングには Filestore Enterprise を使用し、Cloud Load Balancing が提供するロードバランサを使用します。
  • フェイルオーバーに自動化を使用します。自動化により、障害が発生した場合の手動介入の必要性が軽減され、ビジネス オペレーションへの影響が緩和されます。たとえば、Pacemaker などの Linux クラスタ マネージャーを使用できます。

  • 冗長なネットワーク パスを使用します。プライマリ リージョンへの冗長接続があることを確認します。接続要件に応じて、さまざまなオプションを利用できます。詳細については、Google Cloud への接続をご覧ください。

    Google Cloud リージョンへの接続で 99.99% の可用性を実現するには、複数の接続を構成することをおすすめします。詳細については、Dedicated Interconnect で 99.99% の可用性を実現するをご覧ください。

  • Compute Engine リソースでライブ マイグレーションと自動再起動ポリシーを有効にします。

    • Google が開始したメンテナンス イベント中にコンピューティング インスタンスをオンラインに維持するには、MIGRATE（デフォルト）オプションを使用して onHostMaintenance プロパティを設定することで、ライブ マイグレーションを使用できます。ライブ マイグレーションをサポートしていないコンピューティング インスタンスの場合は、automaticRestart プロパティを true（デフォルト）に設定します。これにより、Google は応答しなくなったインスタンスを再起動できます。詳細については、ホストイベントについてをご覧ください。
    • ライブ マイグレーションまたは計画的なメンテナンスをサポートしていないコンピューティング インスタンスの場合は、高度なメンテナンス コントロールを使用できます。詳細については、単一テナントノードへの高度なメンテナンス管理を有効にするをご覧ください。

  • 本番環境に移行する前に、環境でフェイルオーバーをテストします。

障害復旧に関する推奨事項

  • DR ソリューションをプライマリ ロケーション以外のロケーションにホストします。DR ソリューションがプライマリ システムと同じイベントの影響を受けないようにするには、それら 2 つが異なるロケーションでホストされていることを確認します。

    理想的には、DR のロケーションは別のリージョンにする必要があります。ただし、データの所在地または主権に関する懸念から、2 つ目のリージョンを使用することが適切な選択でない場合は、Google Cloud 営業担当者にお問い合わせのうえ、利用可能な他のオプションについてご相談ください。

    次の図は、次の HA と DR のプロビジョニングを含む Google Cloud 上の SAP HANA デプロイのアーキテクチャの概要を示しています。

    • HA を実現するために、プライマリ システムには同じリージョン内の異なるゾーンにデプロイされた 2 つのノードがあります。
    • 復元性を実現するため、プライマリ システムと DR システムは異なるリージョンにホストされ、非同期レプリケーションが使用されます。

    高可用性と障害復旧を実現する Google Cloud 上の SAP HANA のアーキテクチャの概要図。

  • DR ロケーションに十分な容量があることを確認します。

    • DR システムをプライマリ システムと同じ容量で実行する必要がある、または容量を削減して実行する必要があるかを決定します。SAP HANA などのデータベースの場合、DR ロケーションには、SAP ワークロードを効率的に運用するのに十分なリソースが必要です。
    • また、DR ロケーションで必要なリソースが使用可能であることを事前に確認します。リソースの可用性を確保するには、DR ロケーションでリソースをプロビジョニングするか、事前に予約を購入します。予約を購入すると、障害が発生した後、他の Google Cloud のお客様に割り当てられているためにリソースを使用できないという状況を回避できます。これは、M2 や X4 などの大規模なコンピューティング インスタンス タイプでは特に重要です。予約については、Compute Engine ゾーンリソースの予約をご覧ください。

    コスト効率を高めるために、DR ロケーションのインフラストラクチャを非本番環境のワークロードに使用し、DR イベント中に本番環境のワークロードにサービス提供を行う状態に切り替えることができます。ただし、復元に要する時間が増加するという代償を伴います。

  • DR ロケーションへの接続を検証します。プライマリ ロケーションへの冗長ネットワーク パスの場合と同様に、Cloud VPN などのフォールバック オプションを追加することを検討してください。

  • 障害の特定に使用できるシグナルを特定します。これらのシグナルは、DR ソリューションをトリガーするタイミングを判断するのに活用できます。このようなシグナルの例を次に示します。

    • Google Cloud Service Health から取得した Google Cloud サービスの状態に関する情報。
    • Google Cloud プロジェクト用に構成された Cloud Monitoring によって報告されたインスタンスの可用性の完全な喪失。
    • Google Cloud カスタマーケアまたは Google Cloud アカウントの担当者からの連絡。サービス停止と解決に要する可能性がある時間について情報を提供します。
    • SAP システムのユーザーまたは管理者によって特定されたデータベースの論理的な破損。HA メカニズムでは解決できません。

  • DR ソリューションを定期的にテストします。障害発生時にソリューションが効果を発揮することを確認します。これにより、日々の業務に影響が生じる可能性があります。運用で許可されている場合は、プライマリとセカンダリの両方のロケーションで対称的に運用し、3～6 か月ごとに両方のロケーション間で運用をローテーションすることを検討してください。

  • レプリケーションを使用して最適な復元ポイントを実現します。レプリケーションにより、DR サイトにプライマリ サイトのほぼリアルタイムのバージョンが提供されます。SAP ワークロードの設計に応じて、次のレプリケーション オプションを使用できます。

    • SAP HANA システム レプリケーションなどのメカニズムを利用したデータベース レベルのレプリケーション。プライマリ サイトと DR サイト間において論理レベルでレプリケートされます。
    • ブロック ストレージ レベルでレプリケーションを行う PD 非同期レプリケーションなどのメカニズムを利用したストレージ レベルのレプリケーション。SAP ワークロードで使用されるストレージ オプションに応じて、使用可能なストレージ レベルのレプリケーション オプションは異なります。

    SAP HANA Cockpit などの適切なツールを使用して、レプリケーションをモニタリングしてください。これにより、DR イベントが発生した場合に DR ソリューションがトリガーされる前に、SAP ワークロードが完全に複製されていることを確認できます。

  • データのバックアップを使用して、ポイントインタイム リカバリを実現します。

    • 冗長性を作成するには、複数のストレージ ロケーションを使用してバックアップを保存します。例:
    • 増分バックアップまたは差分バックアップを使用します。これには、Google Cloud にスナップショットを保存することも含まれます。
    • バックアップをモニタリングして、バックアップ戦略に沿って正しく作成されていることを確認します。完全なデータ保護を実現するソリューションについては、Google Cloud の Backup & DR サービスの使用を検討してください。
    • バックアップを定期的にテストして、障害が発生した場合に復元できることを確認し、システムまたはデータベースの復元に要する時間を確認します。通常 28 日間のバックアップ サイクルごとに 1 回、復元をテストすることをおすすめします。
    • ストレージの保持設定や暗号鍵を使用するなど、プライマリ システムを保護する場合と同様にバックアップを保護します。

その他の推奨事項

  • HA 構成と DR 構成の費用を、ビジネスの次の側面に与える影響と比較して評価します。
    • 運用とビジネス取引のダウンタイムの可能性。
    • データ損失により、販売、顧客、ベンダーの信頼を失う、またはコンプライアンス違反につながる可能性があります。
  • あらゆるビジネスに固有の考慮事項が存在します。特定の状況でよりカスタマイズされたソリューションが必要である場合は、お気軽に Google Cloud セールスまでお問い合わせください。

次のステップ