このリファレンス アーキテクチャは、SAP Business Suite アプリケーションを SAP ASE または IBM Db2 にデプロイするプラットフォームとして Google Cloud を検討している方を対象としています。ここでは、計画フェーズでの考慮事項、デプロイモデルと自動化、バックアップと DR タスクなどの一般的な運用手順について説明します。
Google Cloud は、SAP ASE または IBM Db2 上で SAP Business Suite を実行するための、費用対効果と信頼性が高く、安全で高性能な SAP 認定インフラストラクチャを提供します。Google Cloud でサポートされている SAP ソリューションの詳細については、Google Cloud での SAP をご覧ください。
アーキテクチャ
次の図は、SAP Business Suite の一般的なデプロイモデルである集中型、分散型、高可用性のある分散型の 3 種類について概要を示しています。
集中型デプロイ
集中型デプロイでは、SAP Business Suite と SAP ASE または IBM Db2 データベースを同じ Compute Engine VM インスタンスにインストールできます。サンドボックス環境や開発環境など、本番環境以外の環境では、この方法をおすすめします。
次のセクションでは、SAP ASE や IBM Db2 に集中型デプロイされた SAP Business Suite のリファレンス アーキテクチャについて説明します。SAP ASE を使用する SAP Business Suite の集中型デプロイ
次の図は、SAP ASE に対する SAP Business Suite の集中型デプロイに関するリファレンス アーキテクチャを示しています。SAP ASCS、PAS、WD、データベースはすべて同じ VM インスタンスにインストールされています。
IBM Db2 を使用する SAP Business Suite の集中型デプロイ
次の図は、IBM Db2 に対する SAP Business Suite の集中型デプロイに関するリファレンス アーキテクチャを示しています。SAP ASCS、PAS、WD、データベースはすべて同じ VM インスタンスにインストールされています。
分散型デプロイ
分散型デプロイでは、コンポーネントを別々の Compute Engine インスタンスにインストールできます。本番環境や、トランザクション処理の負荷が高く、多くのコンピューティング能力を必要とする環境では、この方法をおすすめします。
SAP ASE を使用する SAP Business Suite の分散型デプロイ
次の図は、SAP ASE に分散型デプロイされた SAP Business Suite に関するリファレンス アーキテクチャを示しています。SAP ASCS、PAS、WD、ASE はすべて別々の VM インスタンスにインストールされています。
IBM Db2 を使用する SAP Business Suite の分散型デプロイ
次の図は、IBM Db2 に分散型デプロイされた SAP Business Suite に関するリファレンス アーキテクチャを示しています。SAP ASCS、PAS、WD、IBM Db2 はすべて別々の VM インスタンスにインストールされています。
高可用性のある分散型デプロイ
高可用性のある分散型デプロイでは、特定のリージョンのコンポーネント障害から保護するために、ゾーンをまたがる Linux クラスタが設定されます。アクティブ / パッシブ構成を使用して、ゾーンをまたいで Linux クラスタをデプロイできます。いずれの場合も、冗長性を最大限に高めるため、2 つの Compute Engine VM インスタンスを別々のゾーンに設定し、それぞれに独自の SAP ASE または IBM Db2 データベースを設定します。高可用性のある SAP ASE の分散型デプロイ: SAP でサポートされている高可用性と障害復旧（HADR）を備えた SAP ASE データベースを Google Cloud 上でデプロイできます。詳細については、SAP ASE プランニング ガイドをご覧ください。
次の図は、Linux クラスタを使用してアプリケーション側とデータベース側の両方で高可用性を実現する SAP ASE で動作する SAP Business Suite のアーキテクチャを示しています。
高可用性を管理するクラスタには、次の機能が含まれています。
- 3 台のホスト VM。2 台のホストはそれぞれデータベース インスタンスを備えており、1 台のホストは Fault Manager を備えています。
- 同期型 SAP ASE レプリケーション。
- Pacemaker 高可用性クラスタ リソース マネージャー。
- 障害が発生したまたは発生中のリソースを Fault Manager を使用して隔離するフェンシング メカニズム。
- 障害が発生したインスタンスを新しいセカンダリ インスタンスとして自動的に再起動し、SAP ASE レプリケーションに自動的に再登録します。
高可用性のある IBM Db2 の分散型デプロイ: SAP でサポートされている高可用性と障害復旧（HADR）を備えた IBM Db2 データベースを Google Cloud 上でデプロイできます。詳細については、IBM Db2 for SAP プランニング ガイドをご覧ください。
IBM for Db2 が提供するクラスタリング ソリューションを使用して、ホスト 2 台からなる HADR Pacemaker クラスタを構成できます。詳細については、SAP PDF Linux、Unix、Windows 用 SAP on IBM Db2 向けデータベース管理ガイドをご覧ください。
次の図は、Linux クラスタを使用してアプリケーション側とデータベース側の両方で高可用性を実現する IBM Db2 で動作する SAP Business Suite のアーキテクチャを示しています。
高可用性を管理するクラスタには、次の機能が含まれています。
- それぞれに IBM Db2 のインスタンスが存在する 2 台のホスト VM。
- 同期型 IBM Db2 HADR レプリケーション。
- Linux 高可用性クラスタ リソース マネージャー（Pacemaker など）。
- 障害が発生したノードを囲うフェンシング メカニズム。
- VIP をアクティブ ノードにルーティングする内部アプリケーション ロードバランサ。
- 障害が発生したインスタンスを新しいセカンダリ インスタンスとして自動的に再起動し、IBM Db2 HADR を自動的に再登録します。
アプリケーション側のアーキテクチャも同様です。この場合、クラスタは ABAP SAP Central Services（ASCS）と、Enqueue Replication Server または Enqueue Replicator（ERS）を管理し、ASCS インスタンスと ERS インスタンスに問題が発生した場合に SAP Business Suite システムに高可用性を提供します。
SAP Business Suite システムで使用されている SAP NetWeaver のバージョンに応じて、Enqueue Server と Enqueue Replication Server、Enqueue Replicator が異なるバージョンで実行されます。
次の図は、Pacemaker クラスタを使用して Message Server と Enqueue Server の両方の単一障害点を制限する SAP Business Suite システムを示しています。
高可用性システムのデプロイとゾーン間の Linux クラスタリングの詳細については、このドキュメントの後半で説明します。
ロード バランシングに関する注意事項
SAP ASE または IBM Db2 環境で動作する分散型 SAP Business Suite では、ロード バランシングが必須です。SAP アプリケーション レイヤとネットワーク ロードバランサを組み合わせて、アプリケーション ロード バランシングを構成できます。詳細については、Google Cloud 上での SAP NetWeaver 向け高可用性のプランニング ガイドの内部パススルー ネットワーク ロードバランサ VIP の実装をご覧ください。
デプロイ コンポーネント
SAP ASE または IBM Db2 で動作する SAP Business Suite は、以下の技術コンポーネントから構成されています。
- SAP ASE または IBM Db2 データベース
- Fault Manager（SAP ASE のみ）
- 独自のホストサーバーがあり、プライマリ サーバーとスタンバイ サーバーをモニタリングします。Fault Manager は、自動フェイルオーバーを開始することで SAP ASE の高可用性を維持します。レプリケーション管理エージェント、レプリケーション サーバー、アプリケーション、データベース、オペレーティング システムをモニタリングします。また、データベースの状態を確認し、必要に応じてデータベースを再起動できるようにします。
- 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
- スタンドアロン システムまたは SAP Business Suite システムの一部としてデプロイされます。
- Open Data Protocol（OData）を使用してデバイス、環境、プラットフォームを SAP システムに接続できるようにします。
- SAP Fiori フロントエンド サーバー
- スタンドアロン システムまたは SAP Business Suite システムの一部としてデプロイされます。
- SAP Netweaver ABAP システムは、SAP Fiori アプリケーションをホストするために使用されます。
- WD - Web Dispatcher（オプション）
- アプリケーションの種類に基づいて、HTTP / HTTPS リクエストを PAS または AAS に分散するインテリジェントなソフトウェア ロードバランサ。
SAP ASE または IBM Db2 に対する SAP Business Suite のデプロイでは、次の 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 Business Suite システムをデプロイする方法はいくつか考えられますが、ネットワークをどのようにデプロイするかによって、可用性、復元性、パフォーマンスが大きく変わる可能性があります。前述のように、Virtual Private Cloud（VPC）は、Google Cloud 内にホストされる安全で隔離されたプライベート ネットワークです。VPC は Google Cloud 内でグローバルであり、単一の VPC が、インターネットを経由することなく複数のリージョンにまたがった通信を実現できます。
一般的な SAP デプロイでは、HA システムのインスタンスを同じリージョン内の異なるゾーンに配置し、レイテンシを低く抑えながら復元性を高めます。Google Cloud の機能により、サブネットが複数のゾーンにまたがる場合があります。また、これらの機能により、クラスタの仮想 IP（VIP）アドレスを HA システムのインスタンスと同じ範囲内にできるため、SAP のクラスタリングも簡素化されます。この構成は、内部アプリケーション ロードバランサを使用してフローティング IP を保護しており、アプリケーション レイヤ（ASCS と ERS）と SAP ASE または IBM Db2 データベース レイヤ（プライマリとセカンダリ）の HA クラスタリングに適用できます。
ネットワークを構築して SAP Business Suite システムをインフラストラクチャに接続する方法は複数あります。
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 Business Suite を単一または複数の共有 VPC にデプロイできます。これらの 2 つのシナリオは、ネットワーク コントロール、SAP 環境分離、ネットワーク検査において異なります。
- シナリオ 1: SAP Business Suite を単一の共有 VPC にデプロイする。ネットワーク間の分離は低下しますが、デプロイが簡素化され、管理オーバーヘッドが削減されます。
- シナリオ 2: 複数の共有 VPC に SAP Business Suite をデプロイする。ネットワークの分離が向上し、セキュリティが追加されますが、複雑さと管理オーバーヘッドが増加します。
ハイブリッドなアプローチも可能です。たとえば、本番環境に 1 つの共有 VPC を使用し、すべての非本番環境用システムに 1 つの共有 VPC を使用できます。詳細については、Google Cloud での SAP に関する一般的なチェックリストの「ネットワーキング」セクションをご覧ください。
単一障害点
SAP ASE または IBM Db2 で動作する SAP Business Suite システムには、システムの可用性に影響する可能性がある一般的な単一障害点があります。
- Message Server や Enqueue Server などの SAP Central Services
- SAP Application Server
- SAP ASE または IBM Db2 データベース
- SAP Web Dispatcher（システムへの HTTP / HTTPS アクセスのフロントエンドとして使用する場合）
- 共有ストレージ（NFS など）
このような単一障害点の影響を軽減する方法は複数あります。たとえば、高可用性ソリューション、レプリケーション サービス、システムを障害から保護するその他の機能を使用してシステムをデプロイします。SAP ASE または IBM Db2 で動作する SAP Business Suite システムを計画する際は、このような単一障害点を調査し、それに応じて計画を立てることをおすすめします。単一障害点の管理に使用できる代替ソリューションの概要については、このガイドの次のセクションをご覧ください。
可用性と継続性
SAP ASE または IBM Db2 で動作する SAP Business Suite の実装計画フェーズでは、システムの可用性と継続性を定義するために、次のデータポイントを特定する必要があります。
- サービスレベル目標（SLO）: サービスレベル指標（SLI）によって測定されるサービスレベルの目標値または値の範囲。たとえば、パフォーマンス、可用性、信頼性などです。
- サービスレベル指標（SLI）: サービスのパフォーマンスの測定に役立つレイテンシなどの指標。提供されるサービスレベルのいくつかの側面について慎重に定義された定量的な基準です。
- サービスレベル契約（SLA）: 2 者（プロバイダと顧客）間のサービス契約。サービスレベル目標（SLO）という測定可能な条件で提供サービスに関する契約を定義します。
- 目標復旧時間（RTO）: データ損失インシデントの発生から軽減までに許容される最大期間。
- 目標復旧時点（RPO）: 目標復旧時点（RPO）は、損害を発生させる前に許容できるデータ損失の最大量のことです。実際には、データ損失イベント後に、影響を受けたデータを復元すべき時点を指します。
データポイントとすべての関係者間で合意された値に応じて、SAP Business Suite システムは高可用性や障害復旧などの機能に依存します。
- 高可用性（HA）: ユーザーが必要に応じてデータとサービスを使用できるようにしながら、ビジネスの継続性をサポートするシステムの機能。通常、この機能を実現するために、ハードウェアの冗長性、ネットワークの冗長性、データセンターの冗長性などの冗長性を実現します。
- 障害復旧（DR）: 別のハードウェアや物理的な場所で信頼性の高い予測可能な復旧方法によって計画外の停止からシステムを保護する機能。
高可用性と障害復旧は共通点もありますが、それぞれ異なるケースや状況に対応しています。たとえば、HA ソリューションでは、システムの要素のいずれかで計画外のダウンタイムや停止が発生しても、ユーザーの作業を中断することなくオペレーションを続行できます。DR ソリューションについても同じことが言えます。ただし、停止が発生した瞬間から DR ソリューションが別のロケーションでシステムの障害要素を起動するまでに中断が発生します。
以降のセクションでは、Google Cloud 上の SAP ASE または IBM Db2 で動作する SAP Business Suite システムを計画してデプロイする際に使用できるさまざまなオプションについて概要を説明します。
SAP Business Suite インスタンスでサポートされているマシンタイプ
Google Cloud には、SAP ASE または IBM Db2 を使用する SAP Business Suite をデプロイするときにサイジング要件を満たすことが SAP によって認定されている Compute Engine VM インスタンス タイプが用意されています。Google Cloud のサイジングとサポートされているマシンタイプの詳細については、以下のドキュメントをご覧ください。
- SAP ASE については、SAP ASE プランニング ガイドの「VM 構成」セクションをご覧ください。Google Cloud で SAP ASE を使用する場合にサポートされているオペレーティング システムのバージョンについては、次の SAP ノートを参照してください。
- IBM Db2 については、IBM Db2 for SAP プランニング ガイドの「VM 構成」セクションをご覧ください。
リージョンとゾーンを計画する
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 アプリケーション サーバーとデータベースが同じリージョンにあることを確認します。
SAP Business Suite のストレージ オプション
以下では、SAP Business Suite と SAP ASE または IBM Db2 での使用を 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 をプロビジョニングして、必要なパフォーマンスを選択します。これによりスループットが決まります。詳細については、Google Cloud Hyperdisk についてをご覧ください。Hyperdisk Balanced（
hyperdisk-balanced）: ほとんどのワークロードに最適です。このオプションは、Hyperdisk Extreme のパフォーマンスを必要としないデータベースで使用することをおすすめします。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 にデプロイして管理する、多機能のスマート ストレージ ソリューション。
- NetApp Cloud Volumes Service for Google Cloud: NetApp の高性能なフルマネージド ファイル ストレージ ソリューション。Google Cloud コンソールからデプロイできます。
Google Cloud 上の SAP Business Suite のファイル共有ソリューションの詳細については、Google Cloud 上の SAP のファイル共有ソリューションをご覧ください。
オブジェクト ストレージ用の Cloud Storage
Cloud Storage は、あらゆるタイプや形式のファイルを格納できるオブジェクト ストアです。容量は事実上無制限であり、プロビジョニングや容量の追加を気にする必要がありません。Cloud Storage 内のオブジェクトにはファイルデータとそれに関連付けられたメタデータが含まれています。最大許容サイズは 5 TB です。Cloud Storage バケットには、任意の数のオブジェクトを格納できます。
一般には、ほぼあらゆる目的で Cloud Storage を使用してバックアップ ファイルを保存します。たとえば、Cloud Storage は SAP ASE または IBM Db2 データベースのバックアップの保存に適しています。データベースのバックアップの計画については、データベースのバックアップと復元をご覧ください。また、移行プロセスの一環として Cloud Storage を使用することもできます。
さらに、Backup and DR サービスは、バックアップと障害復旧オペレーションの一元化されたソリューションとして使用できます。このサービスは、SAP ASE や IBM Db2 を含む幅広いデータベースをサポートしています。詳細については、Google Cloud でのバックアップと障害復旧のソリューションをご覧ください。
データへのアクセスを必要とする頻度に基づいて Cloud Storage オプションを選択してください。月に複数回、頻繁にアクセスすることがある場合は、Standard Storage クラスを選択します。アクセスの頻度が低い場合は、Nearline Storage または Coldline Storage を選択します。アクセスが想定されないアーカイブ データの場合は、Archive Storage を選択します。
SAP ASE ディレクトリ構造とストレージ オプション
次の表に、Google Cloud 上の SAP ASE データベースで動作する SAP Business Suite システムのディレクトリ構造を示します。
一般的な SAP ABAP インスタンスに推奨の Linux ディレクトリ構造
Linux ディレクトリ Google Cloud で推奨されるストレージ オプション /sapmnt*バランス永続ディスク /usr/sapバランス永続ディスク 分散型デプロイでは、Filestore などの NFS ソリューションを使用して、ネットワーク ファイル システムとして
/sapmntをマウントすることもできます。以下は、Google Cloud 上の SAP ASE で動作する SAP Business Suite に推奨される Linux ディレクトリ構造です。
SAP ASE データベースのすべてのデータファイルとログファイルは、
/sybase/SAP_SIDディレクトリの下に配置する必要があります。SAP_SIDは、データベースのインストール時に使用した SAP インスタンス番号である SAP システム ID（SID）に置き換えます。SAP ASE ディレクトリ Google Cloud で推奨されるストレージ オプション /usr/sapバランス永続ディスク /sybase/SAP_SID/sapdata1SSD ベースの Persistent Disk または Hyperdisk /sybase/SAP_SID/log_dirSSD ベースの Persistent Disk または Hyperdisk /sybase/SAP_SID/saptempバランス永続ディスク /sybase/SAP_SID/sapdiagバランス永続ディスク SAP ASE の実行に関する SAP の情報については、SAP Applications on SAP Adaptive Server Enterprise - Best Practices for Migration and Runtime をご覧ください。
以下は、Google Cloud 上の SAP ASE で動作する SAP Business Suite に推奨される Windows ディレクトリ構造です。次のディレクトリ構造は、中央サーバーのインストールに適用されます。
ドライブ 説明 Google Cloud で推奨されるストレージ オプション C:\ブート バランス永続ディスク D:\データベース バイナリ バランス永続ディスク E:\データベース データファイル SSD ベースの Persistent Disk または Hyperdisk L:\データベース ログファイル SSD ベースの Persistent Disk または Hyperdisk P:\ページファイル バランス永続ディスク S:\/usr/sapと/sapmntディレクトリバランス永続ディスク T:\tempとsaptempディレクトリバランス永続ディスク X:\バックアップ バランス永続ディスク SAP ASE の実行に関する SAP の情報については、SAP Applications on SAP Adaptive Server Enterprise - Best Practices for Migration and Runtime をご覧ください。
IBM Db2 ディレクトリ構造とストレージ オプション
次の表に、Google Cloud 上の IBM Db2 データベースで動作する SAP Business Suite システムのディレクトリ構造を示します。
Google Cloud 上の IBM Db2 で動作する SAP Business Suite に推奨の Linux ディレクトリ構造:
IBM Db2 のディレクトリ構造 Google Cloud で推奨されるストレージ オプション /sapmntバランス永続ディスク /usr/sapバランス永続ディスク /db2/DB_SIDバランス永続ディスク /db2/DB_SID/db2dumpバランス永続ディスク /db2/DB_SID/sapdata1SSD ベースの Persistent Disk または Hyperdisk /db2/DB_SID/log_dirSSD ベースの Persistent Disk または Hyperdisk /db2/DB_SID/saptmp1バランス永続ディスク /db2backupバランス永続ディスク IBM Db2 上での SAP システムの実行に関する SAP の情報については、SAP on IBM Db2 for Linux, UNIX, and Windows をご覧ください。
以下は、Google Cloud 上の IBM Db2 で動作する SAP Business Suite に推奨される Windows ディレクトリ構造です。このディレクトリ構造は、中央サーバーのインストールに適用されます。
ドライブ 説明 Google Cloud で推奨されるストレージ オプション C:\ブート バランス永続ディスク D:\データベース バイナリ バランス永続ディスク E:\データベース データファイル SSD ベースの Persistent Disk または Hyperdisk L:\データベース ログファイル SSD ベースの Persistent Disk または Hyperdisk P:\ページファイル バランス永続ディスク S:\/usr/sapと/sapmntディレクトリバランス永続ディスク T:\tempとsaptempディレクトリバランス永続ディスク X:\バックアップ バランス永続ディスク ディレクトリ構造の詳細については、SAP NetWeaver プランニング ガイドをご覧ください。ページファイル サイズの計算については、SAP ノート 1518419: Page file and virtual memory required by the SAP system をご覧ください。
SAP Business Suite の 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 バージョンと、SAP Business Suite および SAP ASE または IBM Db2 との互換性の詳細については、次のガイドをご覧ください。
- Google Cloud 上での SAP NetWeaver 向け OS サポート
- SAP ASE プランニング ガイドの「サポートされているオペレーティング システム」セクション
- IBM Db2 for SAP プランニング ガイドの「サポートされているオペレーティング システム」のセクション
SAP ASE のデプロイ アーキテクチャ
SAP ASE は、システムで使用可能なデータベース タイプの 1 つとして機能するため、SAP Business Suite システムの重要なコンポーネントです。
次の図は、Google Cloud 上の SAP ASE に関するデプロイ アーキテクチャを示しています。この図では、Google Cloud へのデプロイとディスク レイアウトの両方に注意してください。/sybasebackup に配置されたローカル バックアップを、Cloud Storage を使用してバックアップできます。このマウントは、データマウント以上のサイズにする必要があります。
IBM Db2 のデプロイ アーキテクチャ
IBM Db2 は、システムで使用可能なデータベース タイプの 1 つとして機能するため、SAP Business Suite システムの重要なコンポーネントです。
次の図は、Google Cloud 上での IBM Db2 のデプロイ アーキテクチャを示しています。この図では、Google Cloud 上でのデプロイとディスク レイアウトの両方に注意してください。/db2backup に配置されたローカル バックアップを、Cloud Storage を使用してバックアップできます。このマウントは、データマウント以上のサイズにする必要があります。
SAP Business Suite のデプロイ アーキテクチャ
アーキテクチャ セクションで説明したように、Google Cloud 上の SAP ASE または IBM Db2 に SAP Business Suite をデプロイする際に使用できるデプロイ アーキテクチャがいくつかあります。
2 層アーキテクチャ
このアーキテクチャについては、集中型デプロイのセクションで説明しています。次の図は、Compute Engine VM 上で実行される SAP Business Suite の 2 層アーキテクチャの詳細を示しています。
3 層アーキテクチャ
このアーキテクチャについては、分散型デプロイで説明しています。このアーキテクチャを使用して、高可用性の SAP Business Suite システムをデプロイできます。次の図は、Compute Engine VM 上で実行される SAP Business Suite の 3 層アーキテクチャの詳細を示しています。
このアーキテクチャでは、SAP Business Suite システムは別の VM でホストされている複数の NetWeaver Application Server（AS）に作業を分散します。すべての NetWeaver AS ノードは同じデータベースを共有し、このデータベースは別の VM でホストされています。すべての NetWeaver AS ノードは、SAP NetWeaver プロファイルをホストする共有ファイル システムをマウントしてこのシステムにアクセスします。この共有ファイル システムは、すべてのノードで共有される Persistent Disk ボリュームまたはサポートされているファイル共有ソリューションにホストされます。
セキュリティ、プライバシー、コンプライアンス
このセクションでは、Google Cloud 上の SAP ASE または IBM Db2 で SAP Business Suite を実行する際のセキュリティ、プライバシー、コンプライアンスについて説明します。
コンプライアンスと主権管理
データ所在地、アクセス制御、サポート担当者、規制要件に準拠して 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 上の SAP ASE また IBM Db2 で SAP Business Suite を実行する際の信頼性に関わる特徴の情報を提供します。
高可用性と障害復旧
高可用性（HA）と障害復旧（DR）は、障害が発生した場合のビジネス継続性を実現する技術、エンジニアリング プラクティス、設計原則から構成されます。このアプローチでは、単一障害点を排除して、システムまたはコンポーネントの停止後に運用を迅速に再開し、ビジネスの中断を最小限に抑えます。障害復旧は、障害が発生したコンポーネントが原因で停止した後に、オペレーションを復元し、再開することを意味します。
たとえば、次のような HA および DR ツールがあります。
- ゾーン間での Linux クラスタリング: 詳細については、Google Cloud 上の SAP NetWeaver の高可用性プランニング ガイドをご覧ください。
- ライブ マイグレーション
- VM ホスト メンテナンス ポリシー
- サービスの自動再起動
- バックアップ
SAP ASE の高可用性
Google Cloud で SAP ASE データベースの高可用性を実現するには、プライマリ サーバーとスタンバイ サーバーの間で同期レプリケーションを構成します。これにより、2 台のサーバーを常に同期させ、データ損失を回避できます。Google Cloud では、高可用性と障害復旧（HADR）システムである SAP ASE の常時オンのオプションがサポートされています。詳細については、SAP ASE プランニング ガイドをご覧ください。
プライマリ サーバーとスタンバイ サーバーをホストする VM インスタンスには、次のコンポーネントが必要です。
- SAP ASE
- SAP Host Agent。サーバーによる CPU、メモリ、その他のリソースの使用状況をモニタリングします。
- レプリケーション管理エージェント（RMA）
- SAP ASE Cockpit。データベース アクティビティを実行します。
- Fault Manager。独自のホストサーバーがあります。プライマリとスタンバイの SAP ASE サーバーをモニタリングします。Fault Manager は、自動フェイルオーバーを開始することで SAP ASE の高可用性を維持します。RMA、レプリケーション サーバー、アプリケーション、データベース、オペレーティング システムをモニタリングします。また、データベースの状態を確認し、必要に応じてデータベースを再起動できるようにします。
システムの可用性を向上させるために SAP ASE クラスタを使用すると、プライマリ ノードの障害をモニタリングして、ワークロードをセカンダリ ノードに移動できます。次の図は、Google Cloud に SAP ASE コンポーネントをインストールする方法を示すリファレンス アーキテクチャの概要です。
SAP ASE の障害復旧
障害復旧（DR）ノードシステム備えた SAP ASE HADR システムは、次の 3 種類の SAP ASE サーバーで構成されます。
- プライマリ サーバー: すべてのトランザクション処理を処理します。
- スタンバイ ノード: このサーバーはプライマリ サーバーのウォーム スタンバイとして機能し、プライマリ サーバーから指定されたデータベースのコピーを保持します。
- DR ノード: 地理的に離れた場所にあるサーバーであり、指定されたデータベースをプライマリ サーバーからバックアップします。
次の図は、SAP ASE の障害復旧のフローを示しています。
IBM Db2 の高可用性と障害復旧
IBM Db2 データベースの高可用性と障害復旧（HADR）を実現するには、次のようにします。
IBM Db2 データベースの 2 つのインスタンスをデプロイする必要があります。1 つはプライマリ、もう 1 つはスタンバイです。これらを同期状態に維持する必要があります。プライマリ インスタンスに障害が発生した場合、スタンバイ インスタンスがワークロードを引き継ぎます。
プライマリ インスタンスは、クライアント接続とトランザクションを処理し、ログに記録します。これらのログは TCP/IP を介してスタンバイ サーバーに送信され、スタンバイ サーバーはこれらのログを使用してデータベースを更新し、プライマリ インスタンスと同期を維持します。
HADR 自体には障害検出と自動化がないため、Pacemaker もデプロイする必要があります。Pacemaker は両方のインスタンスをモニタリングし、プライマリ インスタンスがクラッシュした場合、スタンバイ インスタンスによる HADR 引き継ぎをトリガーして、新しいプライマリ インスタンスにフローティング IP アドレスが割り当てられるようにします。
Pacemaker はクラスタ管理を処理し、VIP は内部アプリケーション ロードバランサとともに使用されて、アプリケーション リクエストをプライマリ インスタンスに転送します。
費用の最適化
このセクションでは、ライセンス、割引、ワークロード サイズの見積もりについて説明します。
ライセンス
SAP を利用している場合は、既存のライセンスを使用して、BYOL（お客様所有ライセンスの使用）モデルで Google Cloud に SAP Business Suite をデプロイできます。Google Cloud は、本番環境と非本番環境の両方のユースケースで BYOL モデルをサポートします。オペレーティング システムのライセンスは Compute Engine の料金に含まれています。
また、お客様所有の OS イメージとライセンスも使用できます。詳細については、カスタム OS イメージをご覧ください。
Google Cloud での SAP ASE のライセンスについては、SAP ASE プランニング ガイドの「SAP ライセンス」セクションをご覧ください。Google Cloud 上で IBM Db2 for SAP をデプロイするには、ご自身で所有されているライセンスの使用が必要です。ライセンスは SAP または IBM から入手できます。ライセンスとサポートの詳細については、SAP ノート 1168456 - DB6: Support Process and End of Support Dates for IBM Db2 LUW をご覧ください。
割引
Google Cloud の従量制課金モデルでは、使用したサービスに対してのみ料金が発生します。特定のサイズやサービスを確約する必要はありません。必要に応じて使用量を変更または停止できます。予測可能なワークロードに対しては、Compute Engine の確約利用割引（CUD）を利用できます。CUD では、契約を確約することで VM の使用料金に対して大幅な割引が適用されます。これにより、インフラストラクチャの費用を削減できます。
Google Cloud では、確約利用契約（コミットメントとも呼ばれる）を購入することで、これらの割引が提供されます。コミットメントを購入すると、指定された期間（1 年間または 3 年間）の最小リソース使用量または最小利用額について確約することになります。これらの割引により、SAP Business Suite システムで使用されるリソースの月額料金を削減できます。詳しくは、確約利用割引（CUD）をご覧ください。
サイズの見積もり
以下のリソースでは、Google Cloud に移行する前に SAP システムのサイズを見積もる方法を説明しています。
運用効率
このセクションでは、Google Cloud 上の SAP ASE または IBM Db2 で動作する SAP Business Suite の運用効率を最適化する方法について説明します。
バックアップとリカバリ
システム クラッシュ、データ破損などの問題が発生した場合に復旧できるように、アプリケーション サーバーとデータベースのバックアップを定期的に作成する必要があります。
Google Cloud 上で SAP ASE または IBM Db2 データをバックアップするには、次のような方法があります。
- Google の Backup and DR サービスを使用してバックアップします。詳細については、データベースまたはインスタンスとそのログを保護するをご覧ください。
- Persistent Disk または Hyperdisk にバックアップし、そのバックアップを Cloud Storage にアップロードします。
- SAP ASE の
/sybasebackupディレクトリまたは IBM Db2 の/db2backupディレクトリをホストするディスクのスナップショットを作成します。
SAP ASE のバックアップと復元
Google Cloud 上で IBM Db2 データベースをバックアップして復元するには、次のオプションを使用します。
ディスクを使用したバックアップと復元: Compute Engine が提供する Persistent Disk と Hyperdisk のタイプと組み合わせて、SAP ASE の柔軟なバックアップと復元のメカニズムを使用できます。バックアップを長期間保存するには、Cloud Storage を使用します。
次の図は、ディスクと Cloud Storage を使用して SAP ASE データベースのバックアップを保存する方法を示しています。
ディスク スナップショットによるバックアップと復元: バックアップ戦略に追加できるもう 1 つのオプションとして、Compute Engine のディスク スナップショット機能を使用してディスク全体のスナップショットを作成できます。たとえば、障害復旧シナリオで使用する
/sybasebackupディレクトリをホストするディスクのスナップショットをスケジュールに従って作成できます。ディスクのスナップショットを使用して、SAP ASE データ ボリュームのバックアップと復元を行うこともできます。アプリケーションの整合性を保つため、ターゲット ボリュームに変更が加えられていないときにスナップショットを作成します。スナップショットはブロックレベルで発生します。最初のスナップショットの後の各スナップショットは増分スナップショットとなり、次の図に示すように、増分ブロック変更のみが保存されます。
IBM Db2 データベースをバックアップする
IBM Db2 データベースは、次のいずれかのオプションを使用してバックアップできます。
- IBM が提供するオンライン モードとオフライン モードを使用する:
- オンライン モード: このモードでは、データベースのバックアップの作成中にユーザーは作業を継続できます。
- オフライン モード: このモードでは、データベースは完全にシャットダウンされます。バックアップの作成中、ユーザーはデータベースを使用できません。
ディスク スナップショットを使用して IBM Db2 データベースをバックアップして復元する: バックアップ戦略に追加できるもう 1 つのオプションとして、Compute Engine のディスク スナップショット機能を使用してディスク全体のスナップショットを作成できます。たとえば、障害復旧シナリオで使用する
/db2backupディレクトリをホストするディスクのスナップショットをスケジュールに従って作成できます。ディスク スナップショットを使用して、IBM Db2 データ ボリュームのバックアップと復元を行うこともできます。アプリケーションの整合性を保つため、ターゲット ボリュームに変更が加えられていないときにスナップショットを作成します。スナップショットはブロックレベルで発生します。最初のスナップショットの後の各スナップショットは増分スナップショットとなり、次の図に示すように、増分ブロック変更のみが保存されます。
データベースのバックアップを作成するプロセスは、IBM Db2 データベースのパーティション数によって異なります。
単一パーティション データベース: この構成では、次の手順でバックアップを作成できます。
db2DB_SIDユーザーとしてデータベース サーバーにログインします。次のコマンドを実行します。
db2 backup db DB_SID
DB_SIDをデータベース システム ID（SID）に置き換えます。
マルチパーティション データベース: この構成では、次の手順でバックアップを作成できます。
db2DB_SIDユーザーとしてデータベース サーバーにログインします。次のコマンドを実行します。
db2 "backup db DB_SID on ALL DBPARTITIONNUMS..."
DB_SIDをデータベース システム ID（SID）に置き換えます。
また、IBM 提供の DBA Cockpit ツールを使用して、データベースのバックアップを作成することもできます。IBM Db2 データベースのバックアップの詳細については、SAP のドキュメント Performing a database backup をご覧ください。
IBM Db2 データベースを復元する
正常なバックアップから IBM Db2 データベースを復元できます。バックアップ イメージとログファイルに関するすべての情報は履歴ファイルに含まれているため、データベースの復元は最新の履歴ファイルにアクセスできるかどうかによって決まります。
バックアップから IBM Db2 データベースを復元するには、次の手順を行います。
db2DB_SIDユーザーまたはSAP_SIDadmユーザーとしてデータベース サーバーにログインします。次のコマンドを実行します。
db2 RECOVER DB DB_SID
DB_SIDをデータベース システム ID（SID）に置き換えます。
IBM Db2 データベースを特定の時点に復元する手順は次のとおりです。
db2DB_SIDユーザーまたはSAP_SIDadmユーザーとしてデータベース サーバーにログインします。次のコマンドを実行します。
db2 RECOVER DB DB_SID to LOCAL_TIME_ON_DB_SERVER
次のように置き換えます。
DB_SID: データベース システム ID（SID）LOCAL_TIME_ON_DB_SERVER: データベース サーバーのローカル時間
IBM Db2 データベースの復元の詳細については、SAP のドキュメント Database recovery using the
RECOVERcommand をご覧ください。
モニタリング
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 ワークロードのワークロード管理を行うプロダクトやサービスを利用できます。
パフォーマンスの最適化
このセクションでは、サイジングとネットワーク構成による SAP Business Suite ワークロードのパフォーマンスの最適化について説明します。
サイズ設定
実装タイプに基づいて、いくつかのサイジング オプションが利用可能です。新しい環境に実装する場合は、SAP Quick Sizer ツールの使用をおすすめします。詳細については、SAP の Sizing ページをご覧ください。SAP では、現在のオンプレミス ソリューションを Google Cloud に移行するための特定のソリューションとツールを用意しています。詳細については、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 ASE データベースのサイズを調整するには、SAP ドキュメントの SAP ASE sizing をご覧ください。IBM Db2 データベースのサイズを調整するには、SAP sizing benchmark をご覧ください。
さまざまなオペレーティング システムと SAP NetWeaver バージョンで SAP ASE または IBM Db2 を実行するためのハードウェア要件については、SAP ドキュメントの Guide Finder for SAP NetWeaver and ABAP Platform をご覧ください。
ネットワーク構成
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 ASE または IBM Db2 デプロイに必要なパフォーマンスが得られます。特定のユースケース、セキュリティ要件、または設定によっては、インターネット トラフィック、内部 SAP ASE または IBM Db2 HADR レプリケーション トラフィック、特定のネットワーク ポリシー ルールの影響を受ける可能性のあるフローなどのトラフィックを分離するために、追加のインターフェースが必要になる場合もあります。アプリケーションが提供するトラフィック暗号化を使用して、最小権限のファイアウォール ポリシーに従ってネットワーク アクセスを保護し、アクセスを制限することをおすすめします。
ネットワーク設計の一部として、トラフィック分離の必要性を早い段階から検討し、VM のデプロイ時に追加の NIC を割り当てます。各ネットワーク インターフェースは別々の VPC ネットワークに接続する必要があります。選択するネットワーク インターフェースの数は必要な分離レベルによって異なります。8 個以上の vCPU を搭載した VM には最大 8 個のインターフェースを割り当てることができます。
詳しくは以下をご覧ください。
デプロイ
このセクションでは、Google Cloud 上の SAP ASE または IBM Db2 に対する SAP Business Suite のデプロイに関する情報を提供します。
デプロイ前に確認が必要な SAP Note
Google Cloud に SAP Business Suite システムをデプロイする前に、次の 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
- 2537664 - SAP Adaptive Server Enterprise (ASE) 16.0 Certification Report for Google Cloud Platform
- 1554717 - SYB: Planning information for SAP on ASE
- 1707361 - Inst. Systems Based on NW 7.1 and Higher: UNIX Db2 for LUW
- 101809 - DB6: Supported Db2 Versions and Fix Pack Levels
SAP ASE または IBM Db2 のインストールの詳細については、以下をご覧ください。
デプロイの自動化
SAP ASE のデプロイを自動化する
Google Cloud で Linux 上の SAP ASE や SAP NetWeaver を実行するために必要なインフラストラクチャのデプロイを自動化するには、Google Cloud が提供する Terraform 構成を使用します。詳細については、シナリオに応じたデプロイガイドをご覧ください。
SAP ASE のデプロイの計画については、以下をご覧ください。
IBM Db2 デプロイの自動化
Google Cloud で Linux 上の IBM Db2 や SAP NetWeaver を実行するために必要なインフラストラクチャのデプロイを自動化するには、Google Cloud が提供する Terraform 構成を使用します。詳細については、シナリオに応じたデプロイガイドをご覧ください。
SAP ASE のデプロイの計画については、以下をご覧ください。
次のステップ
- このガイドで使用する Google Cloud サービスの詳細を確認する。
- VPC ネットワーク
- Compute Engine
- ストレージ オプション: Persistent Disk、Hyperdisk、Cloud Storage
- Google Cloud コンソール
- Cloud Monitoring
- Identity and Access Management
- Filestore
- NetApp Cloud Volumes ONTAP
- Google Cloud NetApp Volumes
- バックアップおよび DR サービス
- Cloud アーキテクチャ センターで、その他のリファレンス アーキテクチャ、設計ガイド、ベスト プラクティスを確認する。