SAP ソリューションの実装を計画する
Azure インフラストラクチャ オプションにはさまざまなバリエーションがあるので、既存の SAP NetWeaver と S/4HANA システムのほぼすべてを Azure でホストすることができます。 Azure では、テラバイト単位のメモリや 200 を超える CPU を搭載した VM SKU をサポートしています。
ワークロードのデプロイ要件を確認する
SAP システムを Azure IaaS (または一般的な IaaS) に正常にデプロイするには、従来のアウトソーサーやホストのオファリングと IaaS オファリングの違いを理解することが重要です。 従来のホストまたはアウトソーサーでは、顧客がホストするワークロードにインフラストラクチャ (ネットワーク、ストレージ、サーバーの種類) を適合させます。 ワークロードの要件を特定し、IaaS デプロイ用に最適な VM、ストレージ、およびネットワークの Azure コンポーネントを選択するのは、お客様またはパートナーの責任です。
SAP でサポートされている製品と Azure VM の種類
最初の手順として、お客様は次の項目を確認する必要があります。
- SAP がサポートしている Azure の VM タイプ
- SAP がサポートしている Azure 上の製品/リリース
- Azure 内の特定の SAP リリースに対してサポートされている OS および DBMS のリリース
- 異なる Azure VM SKU によって提供される SAP のスループット
これらの質問に対する回答は、SAP Note #1928533 で確認できます。詳細については、他のページを参照してください。 そこで説明されているように、最初の計画の一環として、2 層アーキテクチャと 3 層アーキテクチャのいずれかを選択する必要もあります。 3 層アーキテクチャは、プレゼンテーション層、アプリケーション層、およびデータベース層に分かれています。 プレゼンテーション層は、SAP GUI、Fiori ユーザー エクスペリエンス、Web Dynpro などのユーザー インターフェイス コンポーネントをホストします。 アプリケーション層は、ABAP または Java スタックの一部である SAP Central Services インスタンスと、1 つのプライマリ インスタンスと 0 個以上のその他のインスタンスを含むアプリケーション サーバーで構成されます。 2 層構成では、ネットワークの競合を回避し、待機時間を最小限に抑えるために、データベースとすべての SAP コンポーネントを同じ VM にインストールします。 3 層構成では、データベースと SAP アプリケーション コンポーネントを分離することにより、複数の高可用性デプロイを容易にすることができます。
帯域幅の制限を確認する
2 番目の手順として、Azure IaaS のリソースと帯域幅の制限を、オンプレミス システムの実際のリソース消費と比較する必要があります。 そのため、お客様は次の項目について、SAP でサポートされている Azure VM のさまざまな機能をよく理解しておく必要があります。
- CPU およびメモリ リソース
- ストレージの IOPS とスループット
- ネットワークの帯域幅と待ち時間
関連情報については、「Azure の仮想マシンのサイズ」をご覧ください。
上記の参照リンクに記載されている Azure VM の制限が上限を形成していることに注意してください。 よって、すべての状況での実際のリソースの可用性を示しているわけではありません。 選択した VM の種類の CPU リソースとメモリ リソースは例外です。 SAP でサポートされている VM タイプについては、CPU とメモリのリソースが予約されるため、任意の時点で VM 内から消費できます。 ストレージやネットワークなどの他のリソースは、テナント間で共有されます。 インテリジェントな調整およびクォータ ロジックが使用されて、1 つのテナントが他のテナントのパフォーマンスに大きな影響を与えることがないようにされます。 Azure 内のロジックは、お客様に提供される帯域幅の変動を小規模に維持しようとしますが、共有性の高いプラットフォームでは、オンプレミス デプロイの場合よりも、リソース/帯域幅の可用性が大きく変動する傾向があります。 Azure の SAP システムはオンプレミス システムより変動が大きくなる可能性があることを考慮する必要があります。
注意
一部の Azure サブスクリプションの制限は、リージョン レベルで管理されます。 例としては、vCPU があります。 vCPU のサポートでのクォータ引き上げを要求するには、どのリージョンでいくつの vCPU を使用するかを決める必要があります。 その後、必要な数量とリージョンについて、vCPU クォータの増量に関する要求を行います。 特定のリージョンでの現在のクォータを確認する方法について詳しくは、「リソース クォータのエラーを解決する」を参照してください。 クォータの引き上げを依頼するには、ポータルに移動し、サポート案件を提出します。 サポート案件で、デプロイするリージョンのクォータの引き上げを依頼します。
回復性の要件とその他の考慮事項
次の手順では、回復性の要件を評価します。 計画メンテナンスやプラットフォーム関連の問題によりまれに発生する VM への影響を軽減したり、ゲスト OS や DBMS コンポーネントへのパッチ作業を支援したりするために、本稼働 SAP システムに向けて高可用性とディザスター リカバリーを設計する必要があります。
また、管理の容易性、データ保護とセキュリティ、認証、認可、アクセスの制御、監視、ライセンス、サポート、価格に関する事項も計画時に考慮する必要があります。
計画プロセスは、目的のデプロイのアーキテクチャとコンポーネントによって異なり、以下のデプロイ モデルのコンテキストで探究されます。
- Azure VM で AnyDB を使用した SAP NetWeaver
- Azure VM 上の SAP S/4HANA
Microsoft Well Architected Framework に基づくレビュー
SAP on Azure アーキテクチャ ガイドでは、Azure で実行されている SAP ワークロードの品質を保証するために使用される、一連の基本原則が説明されています。 このガイドは Microsoft Azure Well-Architected Framework に基づいていますが、推奨事項は SAP ソリューションのデプロイに固有のものです。 SAP on Azure アーキテクチャ ガイドには、5 つの重要な柱についての説明があります。コスト、DevOps、回復性、スケーラビリティ、およびセキュリティです。 ソリューションに必要なこれらの重要な柱については、Azure Well-Architected Review を使用して確認できます。