Google Cloud は、SAP HANA での SAP S/4HANA の実行に適した SAP 認定のインフラストラクチャを提供します。費用対効果と信頼性が高く、安全で高性能なプラットフォームを提供します。Google Cloud でサポートされている SAP ソリューションの詳細については、Google Cloud での SAP をご覧ください。
アーキテクチャ
次の図は、SAP S/4HANA の一般的なデプロイモデルである集中型、分散型、高可用性のある分散型の概要を示しています。
集中型デプロイ
集中型デプロイでは、S/4HANA と SAP HANA データベースを同じ Compute Engine VM インスタンスにインストールできます。サンドボックス環境や開発環境など、本番環境以外の環境では、この方法をおすすめします。
次の図は、集中型デプロイでの S/4HANA のリファレンス アーキテクチャを示しています。SAP ASCS、PAS、WD、HANA はすべて同じ VM インスタンスにインストールされています。
分散型デプロイ
分散型デプロイでは、コンポーネントを別々の Compute Engine インスタンスにインストールできます。本番環境や、トランザクション処理の負荷が高く、多くのコンピューティング能力を必要とする環境では、この方法をおすすめします。
次の図は、分散型デプロイでの S/4HANA のリファレンス アーキテクチャを示しています。SAP ASCS、PAS、WD、HANA はすべて別の VM インスタンスにインストールされています。
高可用性のある分散型デプロイ
高可用性のある分散型デプロイでは、特定のリージョンのコンポーネント障害から保護するために、ゾーンをまたがる Linux クラスタが設定されます。ゾーンをまたいで Linux クラスタをデプロイするには、アクティブ / パッシブ構成またはアクティブ / アクティブ構成を使用します。いずれの場合も、冗長性を最大限に高めるため、2 つの Compute Engine VM インスタンスを別々のゾーンに設定し、それぞれに独自の SAP HANA データベースを設定します。
次の図は、Linux クラスタを使用してアプリケーションと SAP HANA データベースの両方で高可用性を実現する S/4HANA アーキテクチャを示しています。
次の図は、通常のオペレーションと引き継ぎオペレーションの両方で高可用性を実現する SAP HANA データベースを示しています。
通常のオペレーション:
引き継ぎオペレーション:
データベースの高可用性と障害復旧の両方を組み合わせるには、SAP HANA System Replication を使用します。次の図は、この両方を組み合わせて最大限の可用性とフォールト トレランスを実現するアーキテクチャを示しています。
高可用性を管理するクラスタには、次の機能が含まれています。
- それぞれに SAP HANA のインスタンスが存在する 2 台のホスト VM。
- 同期 SAP HANA システム レプリケーション。
- Pacemaker 高可用性クラスタ リソース マネージャー。
- 障害が発生したノードを囲うフェンシング メカニズム。
- 障害が発生したインスタンスを新しいセカンダリ インスタンスとして自動的に再起動。
アプリケーション側のアーキテクチャも同様です。この場合、クラスタは ABAP SAP Central Services（ASCS）と、Enqueue Replication Server または Enqueue Replicator（ERS）を管理し、ASCS インスタンスと ERS インスタンスに問題が発生した場合に S/4HANA システムに高可用性を提供します。
S/4HANA システムで使用されている SAP S/4HANA のバージョンに応じて、Enqueue Server と Enqueue Replication Server、Enqueue Replicator が異なるバージョンで実行されます。
- S/4HANA 1709 以前: ENSA1 と ERS。
- S/4HANA 1809 以降: ENSA2 と ERS2。
高可用性システムのデプロイとゾーン間の Linux クラスタリングの詳細については、このドキュメントの後半で説明します。
ロード バランシングに関する注意事項
分散 S/4HANA 環境ではロード バランシングが必須です。SAP アプリケーション レイヤとネットワーク ロードバランサを組み合わせて、アプリケーション ロード バランシングを構成できます。詳細については、Google Cloud 上での SAP NetWeaver 向け高可用性のプランニング ガイドの内部パススルー ネットワーク ロードバランサ VIP の実装をご覧ください。
デプロイ コンポーネント
SAP S/4HANA は、次の技術コンポーネントで構成されています。
- SAP HANA データベース
- ASCS: ABAP SAP Central Services
- SAP ABAP システムで必要となる Message Server と Enqueue Server が含まれています。
- HA デプロイの独自の VM インスタンスにデプロイするか、PAS をホストする VM インスタンスにデプロイします。
- HA デプロイでは、ASCS リソースは Pacemaker などの Linux クラスタ リソース マネージャーによって管理されます。
- ERS: Enqueue Replication Server または Enqueue Replicator
- ASCS インスタンスに問題が発生した場合に備えてロックテーブルのレプリカを保持するために HA デプロイにデプロイされます。
- Pacemaker などの Linux クラスタ リソース マネージャーによって管理されます。
- PAS: Primary Application Server
- SAP システムの最初または唯一のアプリケーション サーバー。
- AAS: Additional Application Server
- 通常、アプリケーション レベルのロード バランシング用にデプロイされます。アプリケーション レイヤで高可用性を実現するため、複数の AAS インスタンスをインストールできます。いずれかのアプリケーション サーバーが停止した場合、そのアプリケーション サーバーに接続しているユーザー セッションはすべて終了しますが、ユーザーは環境内の他の AAS に再度ログインできます。
- SAP NetWeaver gateway
- スタンドアロン システムまたは S/4HANA システムの一部としてデプロイされます。
- Open Data Protocol（OData）を使用してデバイス、環境、プラットフォームを SAP システムに接続できるようにします。
- SAP Fiori フロントエンド サーバー
- スタンドアロン システムまたは S/4HANA システムの一部としてデプロイされます。
- SAP Netweaver ABAP システムは、SAP Fiori アプリケーションをホストするために使用されます。
- WD - Web Dispatcher（オプション）。
- アプリケーションの種類に基づいて、HTTP / HTTPS リクエストを PAS または AAS に分散するインテリジェントなソフトウェア ロードバランサ。
SAP S/4HANA のデプロイでは、次の Google Cloud サービスが使用されます。
| サービス | 説明 |
|---|---|
| VPC ネットワーキング |
VM インスタンスを相互に接続します。また、インスタンスをインターネットに接続します。 各 VM インスタンスは、1 つのグローバル IP 範囲を持つレガシー ネットワークのメンバー、または推奨されるサブネット ネットワークのメンバーです。後者の場合、VM インスタンスは、より大規模なネットワークを構成する単一サブネットワークのメンバーです。 Virtual Private Cloud（VPC）ネットワークを複数の Google Cloud プロジェクトにまたがるように構成するはできませんが、1 つの Google Cloud プロジェクトに複数の VPC ネットワークを作成することは可能です。 複数のプロジェクトのリソースを共通の VPC ネットワークに接続するには、共有 VPC を使用します。これにより、ネットワークの内部 IP アドレスを使用し、リソース間で安全かつ効率的に通信を行うことができます。要件、構成手順、使用方法など、共有 VPC のプロビジョニング方法については、共有 VPC のプロビジョニングをご覧ください。 |
| Compute Engine | 選択されたオペレーティング システムとソフトウェア スタックで VM を作成し、管理します。 |
| Persistent Disk と Hyperdisk |
Persistent Disk と Google Cloud Hyperdisk を使用できます。
|
| Google Cloud コンソール |
Compute Engine リソースを管理するブラウザベースのツール。 テンプレートを使って、必要な Compute Engine リソースとインスタンスをすべて定義できます。Google Cloud コンソールが自動的にリソースを作成し、依存関係を検出するので、リソースを個別に作成して構成する必要はありません。また、依存関係を指定する必要もありません。 |
| Cloud Storage | SAP データベースのバックアップを Cloud Storage に保存すると、レプリケーションによって耐久性と信頼性を高めることができます。 |
| Cloud Monitoring |
Compute Engine、ネットワーク、永続ストレージ ディスクのデプロイ状況、パフォーマンス、稼働時間、健全性を視覚的に確認できます。 Monitoring は、Google Cloud から指標、イベント、メタデータを収集し、これらの分析結果をダッシュボード、グラフ、アラートを通じて提供します。Monitoring で、コンピューティング指標を無料でモニタリングできます。 |
| IAM |
Google Cloud リソースの権限を一元管理できます。 IAM を使用すると、VM と永続ストレージ ディスクの作成、変更、削除、ネットワークの作成と変更など、VM に対するコントロール プレーンの処理を実行できるユーザーを制御できます。 |
| Filestore |
Google Cloud の高パフォーマンスのフルマネージド NFS ファイル ストレージ。 マルチゾーン高可用性デプロイでは、可用性の SLA が 99.99% の Filestore Enterprise を使用することをおすすめします。Filestore サービスティアの詳細については、サービスティアをご覧ください。 |
| NetApp Cloud Volumes ONTAP |
Compute Engine VM インスタンスにデプロイして管理する、多機能のスマート ストレージ ソリューション。 NetApp Cloud Volumes ONTAP の詳細については、Cloud Volumes ONTAP の概要をご覧ください。 |
| Google Cloud NetApp Volumes |
NetApp Cloud Volumes ONTAP を活用した、Google Cloud のフルマネージド NFS / SMB ファイル ストレージ ソリューション。 リージョンによっては、複数のサービスレベルから選択できる場合があります。詳細については、サービスレベルをご覧ください。 |
設計上の考慮事項
このセクションでは、このリファレンス アーキテクチャを使用して、セキュリティ、信頼性、運用効率、費用、パフォーマンスに関する特定の要件を満たすアーキテクチャを開発するためのガイダンスを示します。
ネットワーキング
ネットワーキングの点から見ると、SAP S/4HANA システムをデプロイする方法はいくつか考えられますが、ネットワークをどのようにデプロイするかによって、可用性、復元性、パフォーマンスが大きく変わる可能性があります。前述のように、Virtual Private Cloud（VPC）は、Google Cloud 内にホストされる安全で隔離されたプライベート ネットワークです。VPC は Google Cloud 内でグローバルであり、大規模な VPC では、インターネットを経由することなく複数のリージョンにまたがる通信を実現できます。
一般的な SAP デプロイでは、HA システムのインスタンスを同じリージョン内の異なるゾーンに配置し、レイテンシを低く抑えながら復元性を高めます。Google Cloud の機能により、サブネットが複数のゾーンにまたがる場合があります。また、これらの機能により、クラスタの仮想 IP（VIP）アドレスを HA システムのインスタンスと同じ範囲内にできるため、SAP のクラスタリングも簡素化されます。この構成は、内部アプリケーション ロードバランサを使用してフローティング IP を保護しており、アプリケーション レイヤ（ASCS と ERS）と SAP HANA データベース レイヤ（SAP HANA のプライマリとセカンダリ）の HA クラスタリングに適用できます。
ネットワークを構築して SAP S/4HANA システムをインフラストラクチャに接続する方法は複数あります。
VPC ネットワーク ピアリングは、2 つの VPC ネットワークを接続し、各ネットワークのリソースが相互通信できるようにするソリューションです。VPC ネットワークは、同じ Google Cloud プロジェクト、同じ組織の異なるプロジェクト、または異なる組織の異なるプロジェクトにホストできます。VPC ネットワーク ピアリングは、2 つの VPC ネットワーク間の直接接続を確立します。各 VPC ネットワークは独自のサブネットを使用し、ピアリングされた VPC 内のリソース間でプライベート通信を可能にします。
共有 VPC は、組織が複数のプロジェクトのリソースを共通の VPC ネットワークに接続できるようにする Google Cloud の機能です。共有 VPC を使用するシステムは、内部 IP アドレスを使用して効率的かつ安全に通信できます。サブネット、ルート、ファイアウォールなどのネットワーク リソースをホスト プロジェクトで一元管理しながら、個々のリソースの作成と管理に関する管理責任をサービス プロジェクトに委任できます。この懸念事項の分離により、ネットワーク管理が簡素化され、組織全体に一貫したセキュリティ ポリシーを適用できます。
SAP システムの場合、環境タイプごとにリソースをグループ化することが推奨されています。たとえば、本番環境では、適切な分離を行うため、本番環境以外の環境とコンピューティング リソースを共有しないようにする必要がありますが、プロジェクト間の接続の共通レイヤには共有 VPC を使用できます。独立した VPC で VPC ピアリングを使用してプロジェクトを接続することもできます。
ネットワークを設計するときは、まず 1 つ以上の共有 VPC ネットワークを含むホスト プロジェクトから始めます。ホスト プロジェクトに追加のサービス プロジェクトを接続することで、サービス プロジェクトが共有 VPC に参加できるようにします。必要に応じて、SAP S/4HANA を単一の共有 VPC または複数の共有 VPC にデプロイできます。この 2 つのシナリオは、ネットワーク コントロール、SAP 環境分離、ネットワーク検査の点で異なります。
- シナリオ 1: SAP S/4HANA を単一の共有 VPC にデプロイする。ネットワーク間の分離は低下しますが、デプロイが簡素化され、管理オーバーヘッドが削減されます。
- シナリオ 2: 複数の共有 VPC に SAP S/4HANA をデプロイする。ネットワークの分離が向上し、セキュリティが追加されますが、複雑さと管理オーバーヘッドが増加します。
ハイブリッドなアプローチも可能です。たとえば、本番環境に 1 つの共有 VPC を使用し、すべての非本番環境用システムに 1 つの共有 VPC を使用できます。詳細については、Google Cloud での SAP に関する一般的なチェックリストの「ネットワーキング」セクションをご覧ください。
単一障害点
SAP S/4HANA システムには、システムの可用性に影響を与える可能性のある一般的な単一障害点があります。
- Message Server や Enqueue Server などの SAP Central Services
- SAP Application Server
- SAP HANA データベース
- SAP Web Dispatcher（システムへの HTTP / HTTPS アクセスのフロントエンドとして使用する場合）
- 共有ストレージ（NFS など）
このような単一障害点の影響を軽減する方法は複数あります。たとえば、高可用性ソリューション、レプリケーション サービス、システムを障害から保護するその他の機能を使用してシステムをデプロイします。S/4HANA システムを計画する際は、このような単一障害点を調査し、それに応じて計画を立てることをおすすめします。単一障害点の管理に使用できる代替ソリューションの概要については、このガイドの次のセクションをご覧ください。
可用性と継続性
S/4HANA 実装の計画フェーズでは、システムの可用性と継続性を定義するために、次のデータポイントを特定する必要があります。
- サービスレベル目標（SLO）: サービスレベル指標（SLI）によって測定されるサービスレベルの目標値または値の範囲。たとえば、パフォーマンス、可用性、信頼性などです。
- サービスレベル指標（SLI）: サービスのパフォーマンスの測定に役立つレイテンシなどの指標。提供されるサービスレベルのいくつかの側面について慎重に定義された定量的な基準です。
- サービスレベル契約（SLA）: 2 者（プロバイダと顧客）間のサービス契約。サービスレベル目標（SLO）という測定可能な条件で提供サービスに関する契約を定義します。
- 目標復旧時間（RTO）: データ損失インシデントの発生から軽減までに許容される最大期間。
- 目標復旧時点（RPO）: 目標復旧時点（RPO）は、損害を発生させる前に許容できるデータ損失の最大量のことです。実際には、データ損失イベント後に、影響を受けたデータを復元すべき時点を指します。
データポイントとすべての関係者間で合意された値に応じて、S/4HANA システムは高可用性や障害復旧などの機能に依存します。
- 高可用性（HA）: ユーザーが必要に応じてデータとサービスを使用できるようにしながら、ビジネスの継続性をサポートするシステムの機能。通常、この機能を実現するために、ハードウェアの冗長性、ネットワークの冗長性、データセンターの冗長性などの冗長性を実現します。
- 障害復旧（DR）: 別のハードウェアや物理的な場所で信頼性の高い予測可能な復旧方法によって計画外の停止からシステムを保護する機能。
高可用性と障害復旧は共通点もありますが、それぞれ異なるケースや状況に対応しています。たとえば、HA ソリューションでは、システムの要素のいずれかで計画外のダウンタイムや停止が発生しても、ユーザーの作業を中断することなくオペレーションを続行できます。DR ソリューションについても同じことが言えます。ただし、停止が発生した瞬間から DR ソリューションが別のロケーションでシステムの障害要素を起動するまでに中断が発生します。
以降のセクションでは、Google Cloud で S/4HANA システムを計画してデプロイする際に使用できるさまざまなオプションについて説明します。
S/4HANA でサポートされているマシンタイプ
Google Cloud には、S/4HANA をデプロイするときにサイジング要件を満たすことが SAP によって認定されている Compute Engine VM インスタンス タイプが用意されています。Google Cloud のサイジングとサポートされているマシンタイプの詳細については、以下のページをご覧ください。
Google Cloud 上の SAP HANA にカスタム マシンタイプを使用することも SAP で認定されています。1:6.5 以上の vCPU / メモリ比を維持している限り、vCPU が 64 個未満の SAP HANA インスタンスを実行できます。
SAP アプリケーション用に認定されている Compute Engine 仮想マシンの SAPS 番号については、SAP Note 2456432 - SAP Applications on Google Cloud: Supported Products and Google Cloud machine types をご覧ください。
SAP のウェブサイトでは、SAP HANA の Google Cloud 構成の認定リストも提供されています。詳細については、認定済みおよびサポート対象の SAP HANA ハードウェア ディレクトリをご覧ください。
リージョンとゾーンを計画する
VM をデプロイするときに、リージョンとゾーンを選択する必要があります。リージョンとは、リソースを実行できる特定の地理的な場所で、比較的近接している 1 つ以上のデータセンターの場所に対応しています。各リージョンには、冗長接続、電源、冷却を備えた 1 つ以上のゾーンがあります。
事前に構成されたディスク イメージやディスク スナップショットなどのグローバル リソースは、リージョンやゾーンを越えてアクセスできます。リージョンの静的外部 IP アドレスなどのリージョン リソースには、同じリージョン内のリソースのみがアクセスできます。VM やディスクなどのゾーンリソースには、同じゾーン内のリソースのみがアクセスできます。詳細については、グローバル リソース、リージョン リソース、ゾーンリソースをご覧ください。
VM のリージョンとゾーンを選択する場合は、次の点を考慮してください。
- ユーザーとユーザーの内部リソースの場所（データセンターや企業ネットワークなど）。レイテンシを短縮するには、ユーザーやリソースに近いロケーションを選択します。
- 対象のリージョンとゾーンで使用可能な CPU プラットフォーム。たとえば、Intel の Broadwell、Haswell、Skylake、Ice Lake プロセッサは、Google Cloud 上の SAP NetWeaver のワークロードでサポートされています。
- 詳細については、SAP Note 2456432 - SAP Applications on Google Cloud: Supported Products and Google Cloud machine types をご覧ください。
- Haswell、Broadwell、Skylake、Ice Lake の各プロセッサを Compute Engine で使用できるリージョンの詳細については、利用可能なリージョンとゾーンをご覧ください。
- SAP アプリケーション サーバーとデータベースが同じリージョンにあることを確認します。
S/4HANA のストレージ オプション
以下では、S/4HANA と SAP HANA での使用を SAP が認定している Google Cloud のストレージ オプションについて説明します。
Google Cloud のストレージ オプションに関する一般的な情報については、ストレージ オプションをご覧ください。
Persistent Disk
- 標準永続ディスク（
pd-standard）: 順次読み取り / 書き込みオペレーションを処理するのに効率的かつ経済的な、標準ハードディスク ドライブ（HDD）を基盤とするブロック ストレージですが、1 秒あたりのランダム入出力オペレーション（IOPS）量が多い処理には不向きです。 - SSD 永続ディスク（
pd-ssd）: ソリッド ステート ドライブ（SSD）を基盤とする信頼性の高い、高性能なブロック ストレージを提供します。 - バランス永続ディスク（
pd-balanced）: 費用対効果と信頼性に優れた SSD ベースのブロック ストレージを提供します。 - エクストリーム永続ディスク（
pd-extreme）: SSD ベースで、大規模な Compute Engine マシンタイプに対して pd-ssd よりも高い最大 IOPS とスループット オプションを提供します。詳細については、エクストリーム永続ディスクをご覧ください。
Hyperdisk
Hyperdisk Extreme（
hyperdisk-extreme）は、SSD ベースの Persistent Disk ボリュームよりも高い最大 IOPS とスループットのオプションを提供します。IOPS をプロビジョニングして、必要なパフォーマンスを選択します。これによりスループットが決まります。これは、主に SAP HANA データベースの/hana/dataボリュームと/hana/logボリュームのホストに使用されます。詳細については、Google Cloud Hyperdisk についてをご覧ください。Hyperdisk Balanced（
hyperdisk-balanced）: ほとんどのワークロードに最適です。このオプションは、Hyperdisk Extreme のパフォーマンスを必要としないデータベースで使用することをおすすめします。Hyperdisk Balanced ボリュームには/hana/dataディレクトリと/hana/logディレクトリをホストできます。IOPS とスループットをプロビジョニングして必要なパフォーマンスを選択できます。詳細については、Google Cloud Hyperdisk についてをご覧ください。
Persistent Disk と Hyperdisk は、高い耐久性を実現するように設計されています。データの整合性を確保するため、データを冗長的に保存します。1 つの Persistent Disk ボリュームには最大で 64 TB まで保存できるため、ディスクアレイを管理しなくても、大きな論理ボリュームを作成できます。また、Hyperdisk ボリュームでは、使用するタイプに応じて最大 64 TB のストレージを使用できます。重要な機能の一つは、Persistent Disk ボリュームと Hyperdisk ボリュームが、データを保護するために自動的に暗号化されることです。
Compute Engine VM インスタンスを作成すると、オペレーティング システムを含む単一のルート Persistent Disk または Hyperdisk がデフォルトで割り当てられます。必要に応じて、VM インスタンスにストレージ オプションを追加できます。
SAP を実装する場合は、SAP ディレクトリ構造とストレージ オプションで推奨のストレージ オプションをご確認ください。
ファイル共有ソリューション
Google Cloud では、次のようなファイル共有ソリューションを使用できます。
- Filestore: リージョンの可用性を備えた Google Cloud の高パフォーマンスのフルマネージド NFS ファイル ストレージ。
- Google Cloud NetApp Volumes: Google Cloud のフルマネージド NFS / SMB ファイル ストレージ ソリューション。
- NetApp Cloud Volumes ONTAP: Compute Engine VM にデプロイして管理する、多機能のスマート ストレージ ソリューション。
Google Cloud 上の S/4HANA のファイル共有ソリューションの詳細については、Google Cloud 上の SAP のファイル共有ソリューションをご覧ください。
オブジェクト ストレージ用の Cloud Storage
Cloud Storage は、あらゆるタイプや形式のファイルを格納できるオブジェクト ストアです。容量は事実上無制限であり、プロビジョニングや容量の追加を気にする必要がありません。Cloud Storage 内のオブジェクトにはファイルデータとそれに関連付けられたメタデータが含まれています。最大許容サイズは 5 TB です。Cloud Storage バケットには、任意の数のオブジェクトを格納できます。
一般には、ほぼあらゆる目的で Cloud Storage を使用してバックアップ ファイルを保存します。たとえば、Cloud Storage は SAP HANA データベースのバックアップの保存に適しています。データベースのバックアップの計画については、データベースのバックアップと復元をご覧ください。また、移行プロセスの一環として Cloud Storage を使用することもできます。
さらに、バックアップと DR サービスは、バックアップと障害復旧オペレーションの一元化されたソリューションとして使用できます。このサービスは、SAP HANA を含む幅広いデータベースをサポートしています。詳細については、Google Cloud でのバックアップと障害復旧のソリューションをご覧ください。
データへのアクセスを必要とする頻度に基づいて Cloud Storage オプションを選択してください。月に複数回、頻繁にアクセスすることがある場合は、Standard Storage クラスを選択します。アクセスの頻度が低い場合は、Nearline Storage または Coldline Storage を選択します。アクセスが想定されないアーカイブ データの場合は、Archive Storage を選択します。
SAP ディレクトリ構造とストレージ オプション
次の表に、Google Cloud 上の SAP HANA データベースと SAP ABAP インスタンスの Linux ディレクトリ構造を示します。
SAP HANA の Linux ディレクトリ構造に推奨されるストレージ オプション:
SAP HANA ディレクトリ Google Cloud で推奨されるストレージ オプション /usr/sapバランス永続ディスク /hana/dataSSD ベースの Persistent Disk または Hyperdisk /hana/logSSD ベースの Persistent Disk または Hyperdisk /hana/shared*バランス永続ディスク /hanabackup*バランス永続ディスク 分散型デプロイでは、Filestore などの NFS ソリューションを使用して、ネットワーク ファイル システムとして
/hana/sharedと/hanabackupをマウントすることもできます。SAP が SAP HANA での使用を認定している永続ディスク ストレージについては、SAP HANA 用の永続ディスク ストレージをご覧ください。
SAP ABAP インスタンスの Linux ディレクトリ構造に推奨されるストレージ オプション:
ディレクトリ Google Cloud で推奨されるストレージ オプション /sapmnt†バランス永続ディスク /usr/sapバランス永続ディスク 分散型デプロイでは、Filestore などの NFS ソリューションを使用して、ネットワーク ファイル システムとして
/sapmntをマウントすることもできます。SAP が SAP ABAP インスタンスでの使用を認定している永続ディスク ストレージについては、SAP アプリケーション用の永続ディスク ストレージをご覧ください。
S/4HANA の OS サポート
Google Cloud 上での SAP NetWeaver 用オペレーティング システム（OS）を選択するときには、OS バージョンが SAP によって認定されていることを確認するだけでなく、SAP、OS ベンダー、Google Cloud がいずれもその OS バージョンを引き続きサポートしていることを確認することも必要です。
判断する際には、以下の点も考慮する必要があります。
- 該当の OS バージョンが Google Cloud で利用できるかどうか。Compute Engine で提供されている OS イメージは Google Cloud と連携するように構成されています。Google Cloud で OS を利用できない場合は、お客様所有の OS イメージ（BYOI）とライセンスを使用できます。BYOI OS イメージは、Compute Engine でカスタム イメージと呼ばれます。
- 該当の OS バージョンに関して利用可能なライセンス オプション。OS バージョンにオンデマンド ライセンス オプションがあるかどうか、また、OS ベンダーによる BYOS（お客様所有サブスクリプションの使用）が必要かどうかを確認します。
- 特定の OS バージョンの統合された高可用性機能が Google Cloud で有効になっているかどうか。
- SLES for SAP イメージと RHEL for SAP イメージの確約利用割引オプション。
Google Cloud での SAP NetWeaver との併用を SAP が認定しているオペレーティング システムは次のとおりです。
特定の OS バージョンと、S/4HANA および SAP HANA との互換性の詳細については、次のガイドをご覧ください。
SAP HANA 高速再起動オプション
SAP HANA 2.0 SP04 以降の場合は、SAP HANA 高速再起動オプションの使用を強くおすすめします。
このオプションは、Google Cloud が提供する Terraform モジュール（モジュール sap_hana または sap_hana_ha、バージョン 202309280828 以降）を使用して SAP HANA をデプロイすると、自動的に有効になります。SAP HANA 高速再起動を手動で有効にする方法については、SAP HANA 高速再起動の有効化をご覧ください。
SAP HANA 高速再起動により、SAP HANA の終了後もオペレーティング システムが稼働し続けている場合の再起動時間が短縮されます。再起動時間を短縮するため、SAP HANA は SAP HANA の永続メモリ機能を利用して、tmpfs ファイル システムにマッピングされた DRAM のカラムストア テーブルにある MAIN データ フラグメントを保持します。
さらに、Compute Engine メモリ最適化マシンタイプの M2 と M3 ファミリーの VM では、SAP HANA 高速再起動により、メモリに修正不能なエラーが発生した場合の回復時間が改善されます。詳細については、SAP HANA 高速再起動オプションをご覧ください。
SAP HANA のデプロイ アーキテクチャ
SAP HANA は、システムのデータベースとして機能するため、S/4HANA システムの重要なコンポーネントです。SAP HANA データベースのデプロイ時に使用できるアーキテクチャは、スケールアップとスケールアウトの 2 つです。
スケールアップ アーキテクチャ
次の図は、Google Cloud 上の SAP HANA のスケールアップ アーキテクチャを示しています。この図で、Google Cloud へのデプロイとディスク レイアウトの両方に注意してください。/hanabackup に配置されたローカル バックアップを、Cloud Storage を使用してバックアップできます。このマウントは、データマウント以上のサイズにする必要があります。
スケールアウト アーキテクチャ
SAP HANA のスケールアウト アーキテクチャは、1 つのマスターホスト、複数のワーカーホスト、必要に応じて 1 つ以上のスタンバイ ホストで構成されます。最大 32 Gbps のレート、または高帯域幅ネットワーキングを使用する目的のマシンタイプで最大 100 Gbps のレートで、ホスト間のデータ送信をサポートするネットワークを介してホストは相互接続されます。
特にオンライン分析処理（OLAP）の使用時にワークロードの需要が増加すると、マルチホストのスケールアウト アーキテクチャではすべてのホストに負荷を分散できます。
次の図は、Google Cloud 上の SAP HANA のスケールアウト アーキテクチャを示しています。
SAP S/4HANA のデプロイ アーキテクチャ
アーキテクチャ セクションで説明したように、Google Cloud に S/4HANA をデプロイする際に使用できるデプロイ アーキテクチャがいくつかあります。
2 層アーキテクチャ
このアーキテクチャについては、集中型デプロイのセクションで説明しています。次の図は、Compute Engine VM 上で実行される S/4HANA の 2 層アーキテクチャの詳細を示しています。
3 層アーキテクチャ
このアーキテクチャについては、分散型デプロイで説明しています。このアーキテクチャを使用して、高可用性の S/4HANA システムをデプロイできます。次の図は、Compute Engine VM 上で実行される S/4HANA の 3 層アーキテクチャの詳細を示しています。
このアーキテクチャでは、S/4HANA システムは複数の NetWeaver Application Server（AS）に作業を分散し、それぞれが別々の VM にホストされています。すべての NetWeaver AS ノードは同じデータベースを共有し、このデータベースは別の VM でホストされています。すべての NetWeaver AS ノードは、SAP NetWeaver プロファイルをホストする共有ファイル システムをマウントしてこのシステムにアクセスします。この共有ファイル システムは、すべてのノードで共有される Persistent Disk ボリュームまたはサポートされているファイル共有ソリューションにホストされます。
セキュリティ、プライバシー、コンプライアンス
このセクションでは、Google Cloud で S/4HANA を実行するためのセキュリティ、プライバシー、コンプライアンスについて説明します。
コンプライアンスと主権管理
データ所在地、アクセス制御、サポート担当者、規制要件に準拠して SAP ワークロードを実行する必要がある場合は、クラウド エクスペリエンスの質を損なうことなく、Google Cloud でセキュリティとコンプライアンスを確保したワークロードを実行できるサービスである、Assured Workloads の使用を計画する必要があります。詳細については、Google Cloud 上の SAP のコンプライアンスと主権管理をご覧ください。
ネットワーキングとネットワーク セキュリティ
ネットワーキングとネットワーク セキュリティを計画する際は、以降のセクションの情報を参考にしてください。
最小権限モデル
最前線の防御策としてまず行うべきことは、ネットワークと VM にアクセスできるユーザーを制限することです。これを行うには、VPC ファイアウォール ルールを使用します。デフォルトでは、アクセスを許可するルールを作成しない限り、VM へのトラフィックはすべてファイアウォールによってブロックされます。他の VM からのトラフィックについても同様です。例外は、各プロジェクトで自動的に作成され、デフォルトのファイアウォール ルールが設定されているデフォルト ネットワークです。
VPC ファイアウォール ルールを作成することで、特定のポートセットに対するアクセスを特定の送信元 IP アドレスからのトラフィックに制限できます。アクセスが必要な特定の IP アドレス、プロトコル、ポートへのアクセスを制限するには、最小権限モデルに従います。たとえば、踏み台インスタンスを常に設定し、そのインスタンスからのみ SAP NetWeaver システムへの SSH 通信を許可します。
カスタム ネットワークとファイアウォール ルール
ネットワークを使用して、ネットワークに接続している VM のゲートウェイ IP とネットワーク範囲を定義できます。すべての Compute Engine ネットワークは IPv4 プロトコルを使用します。すべての Google Cloud プロジェクトには、事前設定された構成とファイアウォール ルールを持つデフォルト ネットワークが用意されていますが、最小権限モデルに基づいてカスタム サブネットワークとファイアウォール ルールを追加する必要があります。デフォルトでは、新たに作成されたネットワークにはファイアウォール ルールがありません。つまり、このネットワークにはアクセスできません。
ネットワークの一部を分離する場合や、他の要件を満たす場合は、複数のサブネットワークを追加することをおすすめします。詳細については、ネットワークとサブネットをご覧ください。
ファイアウォール ルールは、ネットワーク全体とネットワーク内のすべての VM に適用されます。同じネットワーク内の VM 間またはサブネットワーク間のトラフィックを許可するファイアウォール ルールを追加できます。ネットワーク タグを使用して、特定のターゲット VM に適用されるようにファイアウォールを構成することもできます。
SAP は特定のポートへのアクセスを必要としているため、SAP が定義しているポートへのアクセスを許可するファイアウォール ルールを追加してください。
ルート
ルートは、1 つのネットワークに関連付けられるグローバル リソースです。ユーザーが作成したルートは、ネットワーク内のすべての VM に適用されます。つまり、外部 IP アドレスを使用せずに、同じネットワーク内の VM 間またはサブネットワーク間のトラフィックを転送するルートを追加できます。
インターネット リソースへの外部アクセスの場合、外部 IP アドレスを指定せずに VM を起動し、別の VM を NAT ゲートウェイとして構成します。この構成では、SAP インスタンスへのルートとして NAT ゲートウェイを追加する必要があります。
踏み台インスタンスと NAT ゲートウェイ
VM を完全に内部的なものにすることがセキュリティ ポリシーの要件となっている場合、ネットワーク上で NAT プロキシを手動で設定し、対応するルートを設定する必要があります。これにより、VM とインターネットとの接続が可能となります。SSH を使用して完全な内部 VM インスタンスに直接接続することはできません。
このような内部マシンに接続するには、外部 IP アドレスを持つ踏み台インスタンスを設定し、そのアドレスからトンネル接続を行う必要があります。外部 IP アドレスを持たない VM に他の VM から到達するには、その VM が同じネットワーク上にあるか、マネージド VPN ゲートウェイを経由する必要があります。ネットワーク内の VM を、インバウンド接続（踏み台インスタンス）または下りネットワーク（NAT ゲートウェイ）用の信頼できるリレーとしてプロビジョニングできます。このような接続の設定が不要な透過的な接続を行うには、マネージド VPN ゲートウェイ リソースを使用します。
インバウンド接続用の踏み台インスタンス
踏み台インスタンスは、ネットワーク（プライベート ネットワーク内に VM を含む）と外部とのエントリ ポイントを提供します。このインスタンスで要塞化や監査を一元的に行うことができます。また、インターネットからのインバウンド SSH 通信を有効または無効にするために、このインスタンスを起動または停止できます。
外部 IP アドレスを持たない VM への SSH アクセスは、最初に踏み台インスタンスに接続することで実現できます。踏み台インスタンスの完全な強化は、このドキュメントの範囲外ですが、実施する最初のステップには以下のものが挙げられます。
- 踏み台インスタンスと通信できるソース IP の CIDR 範囲を制限します。
- 踏み台インスタンスからのみプライベート VM への SSH トラフィックを許可するように、ファイアウォール ルールを構成します。
デフォルトで、VM 上の SSH が認証で秘密鍵を使用するように構成されます。踏み台インスタンスを使用する場合、まず踏み台インスタンスにログインし、次にターゲット プライベート VM にログインします。このように 2 段階でログインを行うため、ターゲット VM の秘密鍵を踏み台インスタンスに保存する代わりに、SSH エージェント転送を使用してターゲット VM に接続することをおすすめします。これは、踏み台インスタンスとターゲット VM に同じ Key-Value ペアを使用する場合でも必要です。踏み台インスタンスは、鍵ペアの公開鍵にしか直接アクセスできないためです。
アウトバウンド データ転送用の NAT ゲートウェイ
VM に外部 IP アドレスが割り当てられていない場合、他の Google Cloud サービスを含む外部サービスに直接接続することはできません。これらの VM がインターネット上のサービスに到達できるようにするには、NAT ゲートウェイをセットアップして構成します。NAT ゲートウェイは、ネットワーク上の他の VM の代わりにトラフィックをルーティングする VM です。ネットワークごとに 1 つの NAT ゲートウェイを使用します。1 つの VM の NAT ゲートウェイは高可用性を有するものではなく、複数の VM で高スループットのトラフィック処理を実現できません。NAT ゲートウェイとして機能するように VM を設定する方法については、ご使用のオペレーティング システムのデプロイガイドをご覧ください。
Cloud VPN
Cloud VPN を使用することで、IPsec を使用する VPN 接続を介して、既存のネットワークを Google Cloud に安全に接続できます。2 つのネットワーク間のトラフィックは、一方の VPN ゲートウェイで暗号化され、もう一方の VPN ゲートウェイで復号されます。これにより、インターネットでデータをやり取りする際もデータが保護されます。ルート上のインスタンス タグを使用すると、トラフィックを VPN に送信する VM を動的に制御できます。Cloud VPN トンネルは、固定の月額料金にアウトバウンド データ転送の標準料金が加算されて課金されます。同じプロジェクトで 2 つのネットワークを接続しても、アウトバウンド データ転送の標準料金が引き続き発生することに注意してください。詳しくは以下をご覧ください。
Cloud Storage バケットのセキュリティ
Cloud Storage を使用してデータとログボリュームのバックアップをホストする場合は、転送中のデータを保護するため、VM から Cloud Storage へのデータ送信に必ず TLS（HTTPS）を使用してください。
Cloud Storage は保存データを自動的に暗号化しますが、独自の鍵管理システムを使用している場合は、独自の暗号鍵を指定できます。
メール通知の上限
Google Cloud では、システムと Google を不正使用から保護するために、Compute Engine からのメール送信に制限を設けています。これは、オンプレミス システムと比較して特定の構成が必要になるため、SAP NetWeaver ABAP システムの SCOT トランザクションに影響します。
SCOT の構成に関する情報など、詳細については、インスタンスからのメールの送信をご覧ください。
関連のセキュリティ ドキュメント
Google Cloud 上の SAP 環境のセキュリティ リソースの詳細については、以下をご覧ください。
- VM インスタンスへの安全な接続
- セキュリティ センター
- Google Cloud のコンプライアンス
- Google セキュリティの概要
- Google インフラストラクチャのセキュリティ設計の概要 PDF
信頼性
このセクションでは、Google Cloud で S/4HANA を実行する際の信頼性について説明します。
高可用性と障害復旧
高可用性（HA）と障害復旧（DR）は、障害が発生した場合のビジネス継続性を実現する技術、エンジニアリング プラクティス、設計原則から構成されます。このアプローチでは、単一障害点を排除して、システムまたはコンポーネントの停止後に運用を迅速に再開し、ビジネスの中断を最小限に抑えます。障害復旧は、障害が発生したコンポーネントが原因で停止した後に、オペレーションを復元し、再開することを意味します。
たとえば、次のような HA および DR ツールがあります。
- ゾーン間での Linux クラスタリング: 詳細については、Google Cloud 上の SAP NetWeaver の高可用性プランニング ガイドと SAP HANA 高可用性プランニング ガイドをご覧ください。
- ライブ マイグレーション
- VM ホスト メンテナンス ポリシー
- サービスの自動再起動
- バックアップ
以下では、これらのツールの一部について詳しく説明します。
ゾーン間での Linux クラスタリング: ゾーン間で Linux クラスタを設定すると、特定のリージョンのコンポーネント障害からクラスタを保護できます。
SAP NetWeaver アプリケーション レイヤでは、ゾーン間で Linux クラスタをデプロイすることで、ASCS の障害の影響を軽減できます。また、異なるゾーンの両方のノードで高可用性を実現できます。プライマリ ノードに問題がある場合やメンテナンスが行われている場合は、Linux クラスタが ASCS をスタンバイ ノードに移動します。さらに、Enqueue Replication Server を使用してエンキュー テーブルのコンテンツを複製できます。これにより、プロセスがプライマリからスタンバイに切り替わったときに、Enqueue Server はスタンバイ ノードでエンキュー テーブルのコンテンツを維持できます。
SAP HANA データベース レイヤでは、アクティブ / パッシブ構成またはアクティブ / アクティブ構成を使用して、ゾーン間で Linux クラスタをデプロイできます。いずれの場合も、2 つの Compute Engine インスタンスを別々のゾーンに設定し、それぞれに独自の SAP HANA データベースを設定します。
- アクティブ / パッシブ構成: 一方のインスタンスをクラスタのプライマリ ノード（アクティブ）として構成し、もう一方をセカンダリ ノード（パッシブ）として構成します。SAP HANA システム レプリケーション（SR）を使用して、プライマリに障害が発生したときに処理を引き継ぐようにセカンダリ ノードを構成します。HANA SR の構成と設定の詳細については、HANA System Replication をご覧ください。
- アクティブ / アクティブ構成（読み取り可能）: 両方のインスタンスをアクティブに構成しますが、セカンダリ ノードは読み取り専用になります。この設定は、ログリプレイの継続をベースにしています。仮想 IP（VIP）は、現在の読み取り / 書き込みノードを参照するように構成されます。詳細については、アクティブ / アクティブ（読み取り可能）をご覧ください。
また、SAP HANA システム レプリケーションを障害復旧ソリューションとして使用することもできます。プライマリ データベースは、コンテンツをスタンバイ データベースに複製します。スタンバイ データベースは、プライマリがオフラインになった場合に使用できます。これにより、プライマリ データベースのサービスが復元されるまで SAP システムは動作を継続できます。この場合、セカンダリ ノードは自動的にプロモートされません。手動で行う必要があります。SAP HANA 側で HA と DR の両方を組み合わせて、耐障性と可用性を高めることもできます。詳しくは以下をご覧ください。
ライブ マイグレーション: Compute Engine は、ホストシステム イベント（ソフトウェアやハードウェアの更新など）が発生した場合でも、VM インスタンスの稼働が継続します。このようなイベントが発生した場合、Compute Engine は実行中のインスタンスを同じゾーン内の別のホストにライブ マイグレーションを実行します。実行中のインスタンスを再起動する必要はありません。このメカニズムは、元のインスタンスの VM 状態を複製するため、新しいインスタンスが起動すると、元のインスタンスのメモリが読み込まれています。
ライブ マイグレーションが行われなかった場合（これはまれなケースです）、障害の発生した仮想マシンは同じゾーン内の新しいハードウェアで自動的に再起動されます。詳細については、メンテナンス イベント中のライブ マイグレーション プロセスをご覧ください。
費用の最適化
このセクションでは、ライセンス、割引、ワークロード サイズの見積もりについて説明します。
ライセンス
SAP を利用している場合は、既存のライセンスを使用して、BYOL（お客様所有ライセンスの使用）モデルで Google Cloud に SAP Business Suite をデプロイできます。Google Cloud は、本番環境と非本番環境の両方のユースケースで BYOL モデルをサポートします。オペレーティング システムのライセンスは Compute Engine の料金に含まれています。
また、お客様所有の OS イメージとライセンスも使用できます。詳細については、カスタム OS イメージをご覧ください。
割引
Google Cloud の従量制課金モデルでは、使用したサービスに対してのみ料金が発生します。特定のサイズやサービスを確約する必要はありません。必要に応じて使用量を変更または停止できます。予測可能なワークロードに対しては、Compute Engine の確約利用割引（CUD）を利用できます。CUD では、契約を確約することで VM の使用料金に対して大幅な割引が適用されます。これにより、インフラストラクチャの費用を削減できます。
Google Cloud では、確約利用契約（コミットメントとも呼ばれる）を購入することで、これらの割引が提供されます。コミットメントを購入すると、指定された期間（1 年間または 3 年間）の最小リソース使用量または最小利用額について確約することになります。これらの割引により、SAP S/4HANA システムで使用されるリソースの月額料金を削減できます。詳しくは、確約利用割引（CUD）をご覧ください。
サイズの見積もり
以下のリソースでは、Google Cloud に移行する前に SAP システムのサイズを見積もる方法を説明しています。
業務の効率化
このセクションでは、Google Cloud で S/4HANA の運用効率を最適化する方法について説明します。
バックアップとリカバリ
システム クラッシュ、データ破損などの問題が発生した場合に復旧できるように、アプリケーション サーバーとデータベースのバックアップを定期的に作成する必要があります。
バックアップ
Google Cloud で SAP HANA データをバックアップする場合、次のような方法があります。
- Google のバックアップと DR サービスを使用してバックアップします。詳細については、検出された SAP HANA データベースとそのログをバックアップするをご覧ください。
- SAP に認定された Google Cloud の SAP 用エージェントの Backint 機能を使用して、Cloud Storage に直接バックアップします。
- ディスクにバックアップし、バックアップを Cloud Storage にアップロードします。
- スナップショットを使用してディスクをバックアップします。
Cloud Storage にバックアップする
バージョン 3.0 以降、Google Cloud の SAP 用エージェントは Backint 機能をサポートしています。これにより、SAP HANA で Cloud Storage から直接データベースのバックアップを作成し、復元することができます。この新機能は、Compute Engine VM インスタンス、Bare Metal Solution サーバー、オンプレミス サーバー、その他のクラウド プラットフォームで実行されている SAP HANA インスタンスで使用できます。バックアップ用の永続ディスク ストレージを用意することなく、Cloud Storage に直接バックアップを作成し、そこから復元することができます。詳しくは、SAP HANA 運用ガイドをご覧ください。
エージェントのこの機能に対する SAP 認定については、SAP Note 2031547 - Overview of SAP-certified 3rd party backup tools and associated support process をご覧ください。
次の図は、Google Cloud の SAP 用エージェントの Backint 機能を使用する場合のバックアップ フローを示しています。
ディスクにバックアップする
ネイティブの SAP HANA バックアップ / 復元機能と Compute Engine Persistent Disk ボリュームを使用すると、Cloud Storage バケットにバックアップを長期間保存しておくことができます。
通常のオペレーションでは、SAP HANA は定期的にメモリからディスクにデータを自動保存します。さらに、すべてのデータ変更は REDO ログエントリに取得されます。コミットされた各データベース トランザクションの後に、REDO ログエントリがディスクに書き込まれます。
SAP HANA 2.0 以降では、SAP HANA Cockpit を使用して SAP HANA のバックアップを作成します。
次の図は、SAP HANA のバックアップ機能のフローを示しています。
スナップショットを使用してディスクをバックアップする
バックアップ戦略に追加できる別のオプションとして、Compute Engine のディスク スナップショット機能を使用してディスク全体のスナップショットを作成する方法があります。たとえば、障害復旧シナリオで使用する /hanabackup ディレクトリをホストするディスクのスナップショットをスケジュールに従って作成できます。ディスクのスナップショットを使用して、SAP HANA データ ボリュームのバックアップと復元を行うこともできます。アプリケーションの整合性を保つため、ターゲット ボリュームに変更が加えられていないときにスナップショットを作成します。スナップショットはブロックレベルで発生します。
最初のスナップショットの後の各スナップショットは増分スナップショットとなり、次の図に示すように、増分ブロック変更のみが保存されます。
Google Cloud の SAP 用エージェント バージョン 3.0 以降を使用している場合は、エージェントのディスク スナップショット機能を使用して SAP HANA のバックアップと復元を実行できます。詳細については、SAP HANA のディスク スナップショット ベースのバックアップと復元をご覧ください。
復元
SAP HANA の復元ツールは、最新の時点または特定の時点まで復元でき、これらのツールを使用して新しいシステムに復元するか、データベースのコピーを作成できます。バックアップはデータベースの稼働中に実行できることと異なり、復元ツールはデータベースが停止している間のみ使用できます。以下から適切なオプションを選択できます。
- 次のいずれかのリソースを使用して、最新の状態に復元します。
- 完全バックアップまたはスナップショット
- ログのバックアップ
- まだ使用可能な REDO ログエントリ
- 過去のある時点に復元します。
- 指定したフル バックアップに復元します。
モニタリング
Google Cloud では、Compute Engine VM インスタンスと Bare Metal Solution サーバーで実行されている SAP ワークロードをモニタリングできるように、SAP 用エージェントが用意されています。
SAP が求めているように、SAP からのサポートを利用し、SAP がサービスレベル契約（SLA）を達成できるようにするには、すべての Compute Engine VM インスタンスと SAP システムを使用する Bare Metal Solution サーバーに Google Cloud の SAP 用エージェントをインストールする必要があります。サポートの前提条件の詳細については、SAP Note 2456406 - SAP on Google Cloud Platform: Support Prerequisites をご覧ください。
Linux では、SAP Host Agent 指標の収集に加えて、Google Cloud の SAP 用エージェントには Process Monitoring 指標、Workload Manager 評価指標、SAP HANA モニタリング指標の収集などのオプション機能が含まれています。こうした機能を有効にすると、SAP ワークロードのワークロード管理を行うプロダクトやサービスを利用できます。
パフォーマンスの最適化
このセクションでは、サイジングとネットワーク構成による S/4HANA ワークロードのパフォーマンスの最適化について説明します。
サイジング
実装タイプに基づいて、いくつかのサイジング オプションが利用可能です。新しい環境に実装する場合は、SAP Quick Sizer ツールの使用をおすすめします。詳細については、SAP の Sizing ページをご覧ください。SAP では、現在のオンプレミス ソリューションを Google Cloud に移行するための特定のソリューションとツールを用意しています。認定済みおよびサポート対象の SAP HANA ハードウェア ディレクトリと SAP Note 2456432 - SAP Applications on Google Cloud: Supported Products and Google Cloud machine types をご覧ください。SAP と Google Cloud では、IOPS（1 秒あたりの入出力オペレーション）を測定するために使用する単位が異なります。SAP のサイズ要件を Google Cloud インフラストラクチャに適切にサイジングするには、SI（システム インテグレータ）パートナーにご相談ください。
SAP では、既存のシステムを SAP ECC から S/4HANA に移行する前に、SAP Note 1872170 - ABAP on HANA sizing report (S/4HANA, Suite on HANA...) の説明に従って /SDF/HDB_SIZING レポートを実行することを推奨しています。このサイジング レポートは、ソースシステムの現在のメモリと処理の状況を分析し、S/4HANA への移行に必要な情報を提供します。
ネットワーク構成
Compute Engine VM ネットワークの機能は、ネットワーク インターフェース（NIC）や IP アドレスではなく、マシン ファミリーによって決まります。
マシンタイプに応じて、VM インスタンスは 2～32 Gbps のネットワーク スループットを実現できます。一部のマシンタイプでは、最大 100 Gbps のスループットがサポートされています。この場合、Tier_1 ネットワーク構成で Google Virtual NIC（gVNIC）インターフェース タイプを使用する必要があります。これらのスループット率を達成できるかどうかは、トラフィックの方向と宛先 IP アドレスの種類によって異なります。
Compute Engine VM ネットワーク インターフェースは、物理およびソフトウェア定義ネットワーク コンポーネントを使用した、冗長性と復元力に優れたネットワーク インフラストラクチャによって支えられています。これらのインターフェースは、基盤となるプラットフォームの冗長性と復元力を継承します。複数の仮想 NIC をトラフィックの分離に使用できますが、復元力が強化されることはなく、パフォーマンス上のメリットもありません。
単一の NIC で、Compute Engine 上の SAP HANA デプロイに必要なパフォーマンスが提供されます。特定のユースケース、セキュリティ要件、または設定によっては、インターネット トラフィック、内部 SAP HANA システム レプリケーション トラフィック、特定のネットワーク ポリシー ルールの影響を受ける可能性のあるフローなどのトラフィックを分離するために、追加のインターフェースが必要になる場合もあります。アプリケーションが提供するトラフィック暗号化を使用して、最小権限のファイアウォール ポリシーに従ってネットワーク アクセスを保護し、アクセスを制限することをおすすめします。
ネットワーク設計の一部として、トラフィック分離の必要性を早い段階から検討し、VM のデプロイ時に追加の NIC を割り当てます。各ネットワーク インターフェースは別々の VPC ネットワークに接続する必要があります。選択するネットワーク インターフェースの数は必要な分離レベルによって異なります。8 個以上の vCPU を搭載した VM には最大 8 個のインターフェースを割り当てることができます。
たとえば、SAP HANA SQL アプリケーション クライアント（SAP NetWeaver アプリケーション サーバー、カスタム アプリケーションなど）に VPC ネットワークを定義し、サーバー間トラフィックに別の VPC ネットワーク（SAP HANA System Replication など）を定義できます。セグメントが多すぎると、ネットワークの問題の管理やトラブルシューティングが複雑になる可能性があります。これは後から変更することもできます。その場合は、Compute Engine マシンイメージを使用して、関連するすべての構成、メタデータ、データを保持しながら VM インスタンスを再作成できます。
詳しくは以下をご覧ください。
デプロイ
このセクションでは、Google Cloud への S/4HANA のデプロイに関する情報を提供します。
デプロイ前に確認が必要な SAP Note
Google Cloud に SAP S/4HANA システムをデプロイする前に、次の SAP Note をご覧ください。また、SAP の実装を開始する前に、SAP Marketplace で製品の最新のインストール ガイドとリリースノートを確認してください。
- SAP Note 2456432 - SAP Applications on Google Cloud: Supported Products and Google Cloud machine types
- 2446441 - Linux on Google Cloud（IaaS）: Adaption of your SAP License
- 2456953 - Windows on Google Cloud（IaaS）: Adaption of your SAP License
- 1380654 - SAP support in public cloud environments
- SAP Note 2456406 - SAP on Google Cloud Platform: Support Prerequisites
デプロイの自動化
Google Cloud に S/4HANA をインストールするには、次のデプロイ オプションを使用できます。
- 分散デプロイまたは高可用性（HA）の分散デプロイでは、Workload Manager のガイド付きデプロイ自動化ツールを使用できます。このツールを使用すると、サポートされている SAP ワークロードを Google Cloud コンソールから直接構成してデプロイできます。また、同等の Terraform コードと Ansible コードを生成してダウンロードできます。詳細については、ガイド付きデプロイ自動化についてをご覧ください。
- 集中型デプロイまたは分散型デプロイでは、Google Cloud が提供する Terraform 構成を使用できます。詳細については、SAP HANA シナリオのデプロイガイドをご覧ください。