Azure への SAP デプロイを計画して実装する

  • [アーティクル]

Azure では、組織は、長い調達サイクルを完了することなく、必要なクラウド リソースとサービスを取得できます。 ただし、Azure で SAP ワークロードを実行するには、使用可能なオプションに関する知識と、ソリューションを有効にするために Azure コンポーネントとアーキテクチャを選択するための慎重な計画が必要です。

Azure には、SAP アプリケーションを実行するための包括的なプラットフォームが用意されています。 サービスとしての Azure インフラストラクチャ (IaaS) とサービスとしてのプラットフォーム (PaaS) オファリングが組み合わさり、SAP エンタープライズ環境全体のデプロイを成功させるために最適な選択肢が提供されます。

この記事では、SAP ドキュメントと SAP Notes を補完します。これは、Azure やその他のプラットフォームに SAP ソフトウェアをインストールしてデプロイする方法に関する情報の主要なソースです。

定義

この記事では、次の用語を使用します:

  • SAP コンポーネント: SAP S/4HANA、SAP ECC、SAP BW、SAP Solution Manager などの個々の SAP アプリケーション。 SAP コンポーネントは、従来の高度なビジネス アプリケーション プログラミング (ABAP) または Java テクノロジに基づいているか、SAP BusinessObjects などの SAP NetWeaver に基づいていないアプリケーションにすることができます。
  • SAP 環境: 開発、品質保証、トレーニング、ディザスター リカバリー、運用など、ビジネス機能を実行するために論理的にグループ化された複数の SAP コンポーネント。
  • SAP ランドスケープ: 組織の IT ランドスケープ内の SAP 資産のセット全体。 SAP ランドスケープには、運用環境と非運用環境のすべてが含まれます。
  • SAP システム: データベース管理システム (DBMS) レイヤーとアプリケーション レイヤーの組み合わせ。 SAP ERP 開発システムと SAP BW テスト システムの 2 つの例があります。 Azure デプロイでは、これら 2 つのレイヤーをオンプレミスと Azure の間で分散することはできません。 SAP システムは、オンプレミスまたは Azure のいずれかにデプロイする必要があります。 ただし、Azure またはオンプレミスの SAP ランドスケープ内で異なるシステムを運用できます。

リソース

Azure で SAP ワークロードをホストして実行する方法を説明したドキュメントのエントリ ポイントは、Azure 仮想マシンでの SAP の使用を開始することです。 この記事では、以下に関するその他の記事へのリンクがあります:

  • ストレージ、ネットワーク、サポートされているオプションに関する SAP ワークロードの詳細。
  • Azure 上のさまざまな DBMS システム向けの SAP DBMS ガイド。
  • SAP デプロイ ガイド (手動と自動化の両方)。
  • SAP on Azure のワークロードのための高可用性とディザスター リカバリーの詳細。
  • SAP on Azure と他のサービスやサードパーティアプリケーションとの統合。

重要

前提条件、インストール プロセス、および特定の SAP 機能の詳細については、SAP のドキュメントとガイドを注意深くお読みください。 この記事では、Azure 仮想マシン (VM) にインストールおよび運用されている SAP ソフトウェアの特定のタスクについてのみを取り扱っています。

次の SAP ノートは、SAP デプロイに関する Azure ガイダンスのベースとなります:

Note 番号 タイトル
1928533 SAP Applications on Azure:Supported Products and Sizing (Azure 上の SAP アプリケーション: サポートされている製品とサイズ)
2015553 SAP on Azure: サポートの前提条件
2039619 Oracle Database を使用した Azure 上の SAP アプリケーション
2233094 DB6: IBM Db2 for Linux、UNIX、および Windows を使用した Azure 上の SAP アプリケーション
1999351 Troubleshooting Enhanced Azure Monitoring for SAP (強化された Azure Monitoring for SAP のトラブルシューティング)
1409604 Virtualization on Windows:Enhanced Monitoring (Azure を使用した Linux での仮想化: 拡張された監視機能)
2191498 SAP on Linux with Azure:Enhanced Monitoring (Azure を使用した Linux での仮想化: 拡張された監視機能)
2731110 SAP on Azure のネットワーク仮想アプライアンス (NVA) のサポート

Azure サブスクリプションとリソースの一般的な既定の制限と最大制限については、「Azure サブスクリプションとサービスの制限、クォータ、制約」を参照してください。

シナリオ

SAP サービスは、多くの場合、企業で最もミッション クリティカルなアプリケーションの 1 つと見なされます。 アプリケーションのアーキテクチャと操作は複雑であり、可用性とパフォーマンスのすべての要件が満たされていることを確認することが重要です。 企業は通常、このようなビジネスクリティカルなビジネス プロセスの実行を選択するクラウド プロバイダーについて慎重に検討します。

Azure は、ビジネスクリティカルな SAP アプリケーションとビジネス プロセスに理想的なパブリック クラウド プラットフォームです。 SAP NetWeaver や SAP S/4HANA システムを含む現行の SAP ソフトウェアのほとんどは、現在 Azure インフラストラクチャでホストできます。 Azure では、800 を超える CPU の種類と、数テラバイトのメモリを持つ VM が提供されています。

サポートされているシナリオとサポートされていない一部のシナリオの説明については、「SAP on Azure VM でサポートされているシナリオ」を参照してください。 これらのシナリオと、Azure にデプロイするアーキテクチャを計画する際に、サポート外と示されている条件を確認します。

SAP システムを Azure IaaS または一般的な IaaS に正常にデプロイするには、従来のプライベート クラウドと IaaS オファリングのオファリングの大きな違いを理解することが重要です。 従来のホストまたはアウトソーサーは、顧客がホストするワークロードにインフラストラクチャ (ネットワーク、ストレージ、サーバーの種類) を適応させます。 IaaS デプロイでは、潜在的なワークロードを評価し、VM、ストレージ、ネットワークの適切な Azure コンポーネントを選択するのは、お客様またはパートナーの責任です。

Azure へのデプロイを計画するためのデータを収集するには、次の点が重要です:

  • Azure でサポートされている SAP 製品とバージョンを決定します。
  • 使用する予定のオペレーティング システム リリースが、SAP 製品に対して選択する Azure VM でサポートされているかどうかを評価します。
  • SAP 製品でサポートされている特定の VM 上の DBMS リリースを確認します。
  • サポートされている構成を実現するために、必要なオペレーティング システムと DBMS リリースに合わせて SAP ランドスケープをアップグレードまたは更新する必要があるかどうかを評価します。
  • Azure にデプロイするために異なるオペレーティング システムに移行する必要があるかどうかを評価します。

Azure、Azure インフラストラクチャ ユニット、および関連するオペレーティング システム リリースおよび DBMS リリースでサポートされている ｢SAP コンポーネントの詳細については、Azure デプロイでサポートされている SAP ソフトウェア」で説明されています。 SAP リリース、オペレーティング システム リリース、DBMS リリース間のサポートと依存関係を評価することで得られる知識は、SAP システムを Azure に移行する作業に大きな影響を与えます。 たとえば、SAP リリースをアップグレードするか、別のオペレーティング システムに切り替える必要があるかなど、重要な準備作業が関係しているかどうかを学習します。

デプロイを計画するための最初の手順

デプロイ計画の最初の手順は、SAP アプリケーションの実行に使用できる VM を探すことではありません。

デプロイを計画する最初の手順は、組織内のコンプライアンス チームとセキュリティ チームと協力して、パブリック クラウドに SAP ワークロードまたはビジネス プロセスの種類をデプロイするための境界条件を決定することです。 このプロセスには時間がかかる場合がありますが、完了することが重要な基礎となります。

組織が既に Azure にソフトウェアをデプロイしている場合、プロセスは簡単な場合があります。 会社が SAP 導入の初期段階であれば、境界条件、セキュリティ条件、特定の SAP データと SAP ビジネス プロセスをパブリック クラウドでホストするための企業アーキテクチャを把握するために、より大規模な議論が必要になる可能性があります。

コンプライアンスの計画

コンプライアンス ニーズの計画に役立つ Microsoft コンプライアンス オファーの一覧については、「Microsoft コンプライアンス オファリング」を参照してください。

セキュリティの計画

保存データのデータ暗号化や Azure サービス内の他の暗号化など、SAP 固有のセキュリティの問題については、｢Azure 暗号化の概要」と｢SAP ランドスケープのセキュリティ」を参照してください。

Azure リソースの整理

セキュリティとコンプライアンスのレビューと共に、このタスクをまだ行っていない場合は、Azure リソースを整理する方法を計画します。 このプロセスには、次に関する決定が含まれます:

  • VM やリソース グループなど、各 Azure リソースに使用する名前付け規則。
  • ワークロードごと、デプロイ層ごと、または各部署に対して複数のサブスクリプションを作成する必要があるかどうかなど、SAP ワークロードのサブスクリプションと管理グループの設計。
  • サブスクリプションと管理グループに対する Azure Policy のエンタープライズ全体の使用。

適切な意思決定を行うために、エンタープライズ アーキテクチャの詳細については、「Azure クラウド導入フレームワーク」で説明されています。

プロジェクトのこの段階で計画を甘く見てはいけません。 コンプライアンス、セキュリティ、および Azure リソース組織に関する契約と規則が整ってから初めてデプロイ計画を進める必要があります。

次の手順では、地理的配置と、Azure にデプロイするネットワーク アーキテクチャを計画します。

Azure の地域とリージョン

Azure サービスは、別の Azure リージョン内で利用できます。 Azure リージョンは、データセンターのコレクションです。 これらのデータセンターには、リージョンで利用可能な Azure サービスをホストして実行するハードウェアとインフラストラクチャが含まれています。 このインフラストラクチャには多数のノードが含まれており、それぞれのノードは、コンピューティング ノードやストレージ ノードとして機能したり、ネットワーク機能を実行したりします。

Azure リージョンのリストについては、「Azure の地域」を参照してください。 対話型マップについては、「Azure グローバル インフラストラクチャ」を参照してください。

すべての Azure リージョンで同一サービスがオファーされるわけではありません。 実行する SAP 製品、サイズ要件、必要なオペレーティング システムと DBMS によっては、シナリオに必要な VM の種類が特定のリージョンで提供されていない可能性があります。 たとえば、SAP HANA を実行している場合は、通常、さまざまな M シリーズ VM ファミリの VM が必要です。 これらの VM ファミリは、Azure リージョンのサブセットにのみデプロイされます。

プライマリ リージョンと最終的にセカンダリ リージョンとして選択するリージョンを計画して検討し始めると、シナリオに必要なサービスが、検討しているリージョンで利用できるかどうかを調査する必要があります。 「リージョン別に利用可能な製品」の各リージョンで使用できる VM の種類、Azure ストレージの種類、およびその他の Azure サービスを正確に学習できます。

Azure のペアになっているリージョン

Azure のペアになっているリージョンでは、2 つのリージョン間で特定のデータのレプリケーションが既定で有効になります。 詳しくは、「Azure でのリージョン間レプリケーション: 事業継続とディザスター リカバリー」を参照してください。

リージョン ペアのデータ レプリケーションは、ペアになっているリージョンにレプリケートするように構成できる Azure ストレージの種類に関連付けられています。 詳細については、「セカンダリ リージョンでのストレージの冗長性」を参照してください。

ペアになっているリージョン データ レプリケーションをサポートするストレージの種類は、SAP コンポーネントと DBMS ワークロードには適さないストレージの種類です。 Azure ストレージ レプリケーションの使いやすさは、Azure Blob Storage (バックアップ目的)、ファイル共有とボリューム、およびその他の待機時間の長いストレージ シナリオに限定されます。

ペアになっているリージョンと、プライマリ リージョンまたはセカンダリ リージョンで使用するサービスを確認すると、プライマリ リージョンで使用する予定の Azure サービスまたは VM の種類が、セカンダリ リージョンとして使用するペアのリージョンで使用できない可能性があります。 または、データ コンプライアンス上の理由から、Azure のペアのリージョンがシナリオで受け入れられないと判断する場合もあるでしょう。 このようなシナリオでは、ペアになっていないリージョンをセカンダリ リージョンまたはディザスター リカバリー リージョンとして使用し、データ レプリケーションの一部を自分で設定する必要があります。

可用性ゾーン

多くの Azure リージョンでは、可用性ゾーンを使用して、Azure リージョン内の場所を物理的に分離します。 それぞれの可用性ゾーンは、独立した電源、冷却手段、ネットワークを備えた 1 つまたは複数のデータセンターで構成されています。 可用性ゾーンを使用して回復性を高める例は、Azure の 2 つの異なる可用性ゾーンに 2 つの VM をデプロイすることです。 もう 1 つの例は、ある可用性ゾーンに SAP DBMS システムの高可用性フレームワークを実装し、別の可用性ゾーンに SAP (A)SCS をデプロイして、Azure で最高の SLA を得る方法です。

Azure の VM SLA の詳細については、最新バージョンの Virtual Machines SLA を確認してください。 Azure リージョンは急速に開発および拡張されるため、Azure リージョンのトポロジ、物理データセンターの数、データセンター間の距離、および Azure 可用性ゾーン間の距離も進化しています。 インフラストラクチャの変化に伴ってネットワーク待機時間が変化します。

可用性ゾーンを持つリージョンを選択するときは、Azure 可用性ゾーンを使用した SAP ワークロード構成のガイダンスに従います。 また、要件、選択したリージョン、ワークロードに最適なゾーン デプロイ モデルを決定します。

障害ドメイン

障害ドメインは、障害の物理単位を表します。 障害ドメインは、データセンターに含まれる物理インフラストラクチャと密接に関連しています。 物理ブレードまたはラックは障害ドメインと見なすことができますが、物理コンピューティング要素と障害ドメインの間に直接 1 対 1 のマッピングはありません。

1 つの SAP システムの一部として複数の VM をデプロイする場合、可用性 SLA の要件を満たすことができるように、Azure ファブリック コントローラーに間接的に影響を与えて VM を異なる障害ドメインにデプロイできます。 ただし、Azure スケール ユニット (数百のコンピューティング ノードまたはストレージ ノードとネットワークのコレクション) を介した障害ドメインの分散や、特定の障害ドメインへの VM の割り当てを直接制御することはできません。 Azure ファブリック コントローラーを通じて一連の VM を複数の障害ドメインにデプロイするには、デプロイ時に、VM に Azure 可用性セットを割り当てる必要があります。 詳細については、「可用性セット」を参照してください。

更新ドメイン

更新ドメインは、複数の VM で構成される SAP システム内の VM の更新方法を設定する論理ユニットを表します。 プラットフォームの更新が発生すると、Azure は、これらの更新ドメインを 1 つずつ更新するプロセスを経ます。 デプロイ時に VM をさまざまな更新ドメインに分散することで、潜在的なダウンタイムから SAP システムを保護できます。 障害ドメイン同様、Azure スケール ユニットは複数の更新ドメインに分割されます。 Azure ファブリック コントローラーを通じて一連の VM を複数の更新ドメインにデプロイするには、デプロイ時に、VM に Azure 可用性セットを割り当てる必要があります。 詳細については、「可用性セット」を参照してください。

Diagram that depicts update domains and failure domains.

可用性セット

1 つの Azure 可用性セット内の Azure Virtual Machines は、Azure ファブリック コントローラーによって複数の障害ドメインと更新ドメインに分散されます。 異なる障害ドメインに分散させるのは、インフラストラクチャのメンテナンス中または障害が 1 つの障害ドメインで発生した場合に、SAP システムのすべての VM がシャットダウンされないようにするためです。 既定では、VM は可用性セットの一部ではありません。 VM は、デプロイ時または VM の再デプロイ時にのみ可用性セットに追加できます。

Azure 可用性セットと可用性セットと障害ドメインの関係の詳細については、「Azure 可用性セット」を参照してください。

重要

Azure の可用性ゾーンと可用性セットは相互に排他的です。 複数の VM を特定の可用性ゾーンまたは可用性セットにデプロイできます。 ただし、可用性ゾーンと可用性セットの両方を VM に割り当てることができるわけではありません。

近接配置グループを使用する場合は、可用性セットと可用性ゾーンを組み合わせることができます。

可用性セットを定義し、1 つの可用性セット内に異なる VM ファミリのさまざまな VM を混在させようとすると、可用性セットに特定の VM の種類を含めなくなる問題が発生する可能性があります。 その理由は、可用性セットが特定の種類のコンピューティング ホストを含むスケール ユニットにバインドされるためです。 特定の種類のコンピューティング ホストは、特定の種類の VM ファミリでのみ実行できます。

たとえば、可用性セットを作成し、可用性セットに最初の VM をデプロイします。 可用性セットに追加する最初の VM は、Edsv5 VM ファミリにあります。 M ファミリ内の VM である 2 つ目の VM をデプロイしようとすると、このデプロイは失敗します。 その理由は、Edsv5 ファミリの VM が M ファミリの VM と同じホスト ハードウェア上で実行されないためです。

VM のサイズを変更する場合も、同じ問題が発生する可能性があります。 VM を Edsv5 ファミリから M ファミリ内の VM の種類に移動しようとすると、デプロイは失敗します。 同じホスト ハードウェアでホストできない VM ファミリにサイズ変更する場合は、可用性セット内のすべての VM をシャットダウンし、他のホスト コンピューターの種類で実行できるようにサイズを変更する必要があります。 可用性セットにデプロイされている VM の SLA については、「Virtual Machines SLA」を参照してください。

仮想マシン スケール セットとフレキシブル オーケストレーション

柔軟なオーケストレーションを備えた仮想マシン スケール セットは、プラットフォームで管理される仮想マシンの論理的なグループ化を提供します。 リージョン内にスケール セットを作成するか、可用性ゾーン間でスケール セットを作成するかのオプションがあります。 platformFaultDomainCount>1 (FD>1) を使用するリージョン内で柔軟なスケール セットを作成すると、スケール セットにデプロイされた VM は、同じリージョン内の指定された数の障害ドメインに分散されます。 一方、platformFaultDomainCount=1 (FD=1) を使用して可用性ゾーン間で柔軟なスケール セットを作成すると、指定されたゾーン間で VM が分散され、スケール セットによって、ベスト エフォートベースでゾーン内のさまざまな障害ドメインに VM が分散されます。

SAP ワークロードでは、FD=1 の柔軟なスケール セットのみがサポートされます。 従来の可用性ゾーンデプロイではなく、FD=1 で柔軟なスケール セットを使用する利点は、スケール セットでデプロイされた VM がベスト エフォート方式でゾーン内のさまざまな障害ドメインに分散されることです。 スケール セットを使用した SAP ワークロードのデプロイの詳細については、「柔軟な仮想マシン スケールデプロイ ガイド」を参照してください。

高可用性 SAP ワークロードを Azure にデプロイする場合は、使用可能なさまざまなデプロイの種類と、それを異なる Azure リージョン (ゾーン間、単一のゾーン、ゾーンのないリージョンなど) に適用する方法を考慮することが重要です。 詳細については、「SAP ワークロードの高可用性デプロイ オプション」を参照してください。

ヒント

現時点では、可用性セットまたは可用性ゾーンにデプロイされた SAP ワークロードを FD=1 を使用して柔軟なスケールに移行する直接の方法はありません。 スイッチを作成するには、既存のリソースからのゾーン制約が適用された VM とディスクを再作成する必要があります。 オープン ソース プロジェクトには、可用性セットまたは可用性ゾーンにデプロイされた VM を FD=1 で柔軟なスケール セットに変更するためのサンプルとして使用できる PowerShell 関数が含まれています。 ブログ記事では、可用性セットまたは可用性ゾーンにデプロイされた HA または非 HA SAP システムを FD=1 で柔軟なスケール セットに変更する方法について説明します。

近接配置グループ

個々の SAP VM 間のネットワーク待機時間は、パフォーマンスに大きな影響を与える可能性があります。 SAP アプリケーション サーバーと DBMS の間のネットワーク ラウンドトリップ時間は、特にビジネス アプリケーションに大きな影響を与える可能性があります。 最適には、SAP VM を実行するすべてのコンピュート・エレメントは、可能な限り近接して配置されます。 このオプションはすべての組み合わせで実行できるわけではありません。また、どの VM を一緒に保持するかを Azure で認識できない場合があります。 ほとんどの状況とリージョンでは、既定の配置によってネットワーク ラウンドトリップ待機時間の要件が満たされます。

既定の配置が SAP システム内のネットワーク ラウンドトリップ要件を満さない場合、近接配置グループがこのニーズに対応できます。 近接配置グループは、Azure リージョン、可用性ゾーン、可用性セットの場所の制約と共に使用して、回復性を高めることができます。 近接配置グループを使用すると、異なる更新ドメインと障害ドメインを設定しながら、可用性ゾーンと可用性セットの両方を組み合わせることが可能です。 近接配置グループには、1 つの SAP システムのみを含める必要があります。

近接配置グループに配置すると、最も待機時間が最適化された配置になることがありますが、近接配置グループを使用してデプロイする場合にも欠点があります。 一部の VM ファミリを 1 つの近接配置グループに結合できない場合や、VM ファミリ間でサイズを変更すると問題が発生する可能性があります。 VM ファミリ、リージョン、および可用性ゾーンの制約では、コロケーションがサポートされない場合があります。 詳細、および近接配置グループを使用する利点と潜在的な課題については、「近接配置グループのシナリオ」を参照してください。

近接配置グループを使用しない VM は、SAP システムのほとんどの状況で既定のデプロイ方法にする必要があります。 この既定値は、SAP システムのゾーン (単一の可用性ゾーン) およびゾーン間 (2 つの可用性ゾーン間に分散される VM) のデプロイに特に当てはまります。 近接配置グループの使用は、パフォーマンス上の理由から必要な場合にのみ、SAP システムと Azure リージョンに限定する必要があります。

Azure のネットワーク

Azure には、SAP デプロイに実装するすべてのシナリオにマップされるネットワーク インフラストラクチャがあります。 Azure には、次の機能があります:

  • Azure サービスへのアクセスと、アプリケーションが使用する VM 内の特定のポートへのアクセス。
  • 管理用に、Secure Shell (SSH) または Windows リモート デスクトップ (RDP) 経由で VM に直接アクセスします。
  • VM と Azure サービス間の内部通信と名前解決。
  • オンプレミス ネットワークと Azure ネットワーク間のオンプレミス接続。
  • 異なる Azure リージョンにデプロイされているサービス間の通信。

ネットワークの詳細については、「Azure Virtual Network」を参照してください。

通常、ネットワークの設計は、Azure にデプロイするときに実行する最初の技術的なアクティビティです。 SAP などの中央エンタープライズ アーキテクチャを頻繁にサポートすることは、全体的なネットワーク要件の一部です。 計画段階では、提案されたネットワーク アーキテクチャを可能な限り詳細に文書化する必要があります。 サブネット ネットワーク アドレスの変更など、後で変更を加えると、デプロイされたリソースの移動または削除が必要になる場合があります。

Azure 仮想ネットワーク

仮想ネットワークは、Azure 内のプライベート ネットワークの基本的な構成要素です。 ネットワークのアドレス範囲を定義し、その範囲をネットワーク サブネットに分割できます。 SAP VM で使用できるネットワーク サブネットや、特定のサービスまたは目的専用のネットワーク サブネットを使用できます。 Azure Virtual Network や Azure Application Gateway などの一部の Azure サービスには、専用サブネットが必要です。

仮想ネットワークは、ネットワーク境界として機能します。 デプロイを計画するときに必要な設計の一部は、仮想ネットワーク、サブネット、プライベート ネットワーク アドレス範囲を定義することです。 VM のデプロイ後に、VM のネットワーク インターフェイス カード (NIC) などのリソースの仮想ネットワーク割り当てを変更することはできません。 仮想ネットワークまたはサブネットのアドレス範囲を変更するには、デプロイされたすべてのリソースを別のサブネットに移動する必要がある場合があります。

ネットワーク設計では、SAP デプロイのいくつかの要件に対応する必要があります:

  • ファイアウォールなどのネットワーク仮想アプライアンスは、SAP カーネル (S/4HANA や SAP NetWeaver など) を介して SAP アプリケーションと SAP 製品の DBMS レイヤー間の通信パスに配置されません。
  • ネットワーク ルーティングの制限は、サブネット レベルのネットワーク セキュリティ グループ (NSG) によって適用されます。 VM の IP を NSG 規則で保持されるアプリケーション セキュリティ グループ (ASG) にグループ化し、アクセス許可のロール、レベル、SID グループを提供します。
  • SAP アプリケーションとデータベース VM は、1 つの仮想ネットワークの同じサブネットまたは異なるサブネット内で、同じ仮想ネットワーク内で実行されます。 アプリケーション VM とデータベース VM に異なるサブネットを使用します。 または、専用アプリケーションと DBMS ASG を使用して、同じサブネット内の各ワークロードの種類に適用できる規則をグループ化します。
  • 高速ネットワークは、技術的に可能な限り、SAP ワークロードのすべての VM のすべてのネットワーク カードで有効になります。
  • 名前解決 (DNS)、ID 管理 (Windows Server Active Directory ドメイン/Microsoft Entra ID)、管理アクセスなど、中央サービスへの依存関係のセキュリティで保護されたアクセスを確保します。
  • 必要に応じて、パブリック エンドポイントへのアクセスとパブリック エンドポイントによるアクセスを提供します。 たとえば、高可用性での ClusterLabs Pacemaker 操作や Azure Backup などの Azure サービスの Azure 管理などです。
  • 複数の NIC は、独自のルートと NSG 規則を持つ指定されたサブネットを作成する必要がある場合にのみ使用します。

SAP デプロイのネットワーク アーキテクチャの例については、次の記事を参照してください:

仮想ネットワークに関する考慮事項

一部の仮想ネットワーク構成には、注意すべき特定の考慮事項があります。

  • S/4HANA や SAP NetWeaver などの SAP カーネルを使用した SAP アプリケーション 層と SAP コンポーネントの DBMS レイヤー間の通信パスでのネットワーク仮想アプライアンスの構成はサポートされていません。

    通信パスにネットワーク仮想アプライアンスがあると、2 つの通信パートナー間のネットワーク待ち時間が容易に倍増する可能性があります。 また、SAP アプリケーション レイヤーと DBMS レイヤーの間のクリティカル パスのスループットが制限される場合もあります。 一部のシナリオでは、ネットワーク仮想アプライアンスが原因で Pacemaker Linux クラスターに障害が発生することがあります。

    SAP アプリケーション レイヤーと DBMS レイヤー間の通信パスは、直接的なものである必要があります。 ASG 規則と NSG 規則で直接通信パスが許可されている場合、この制限には ASG および NSG 規則は含まれません。

    ネットワーク仮想アプライアンスがサポートされないその他のシナリオは次のとおりです:

  • SAP アプリケーション レイヤーと DBMS レイヤーを異なる Azure 仮想ネットワークに分離することはサポートされていません。 異なる Azure 仮想ネットワークを使用するのではなく、Azure 仮想ネットワーク内のサブネットを使用して SAP アプリケーション レイヤーと DBMS レイヤーを分離することをおすすめします。

    異なる仮想ネットワーク内の 2 つの SAP システム レイヤーを分離するサポートされていないシナリオを設定する場合は、2 つの仮想ネットワークをピアリングする必要があります。

    2 つのピアリングされた Azure 仮想ネットワーク間のネットワーク トラフィックは転送コストの影響を受けるます。 毎日のように SAP アプリケーション レイヤーと DBMS レイヤー間で、数テラバイトもの膨大な量のデータが交換されます。 SAP アプリケーション レイヤーと DBMS レイヤーが 2 つのピアリングされた Azure 仮想ネットワーク間で分離されている場合、相当なコストがかかる可能性があります。

名前解決とドメイン サービス

多くの場合、DNS を使用してホスト名を IP アドレスに解決することは、SAP ネットワークにとって重要な要素です。 Azure で名前と IP 解決を構成するには、多くのオプションがあります。

多くの場合、企業には、アーキテクチャ全体の一部である中央 DNS ソリューションがあります。 独自の DNS サーバーを設定する代わりに、Azure でネイティブに名前解決を実装するためのいくつかのオプションについては、「Azure 仮想ネットワーク内のリソースの名前解決」で説明されています。

DNS サービスと同様に、Windows Server Active Directory に SAP VM またはサービスからアクセスできるようにする必要がある場合があります。

IP アドレスの割り当て

NIC の IP アドレスは、VM の NIC が存在する間、要求され使用され続けます。 この規則は、動的 IP 割り当てと静的 IP 割り当ての両方に適用されます。 VM が実行されているか、シャットダウンされているかに関係なく、true のままです。 動的 IP 割り当ては、NIC が削除された場合、サブネットが変更された場合、または割り当て方法が静的に変更された場合に解放されます。

Azure Virtual Network 内の VM には、固定 IP アドレスを割り当てることができます。 多くの場合、IP アドレスは、外部 DNS サーバーと静的エントリに依存する SAP システムに再割り当てされます。 VM とその NIC が削除されるまで、または IP アドレスが割り当て解除されるまで、IP アドレスは割り当てられたままになります。 仮想ネットワークの IP アドレスの範囲を定義するときは、VM の全体的な数 (実行中と停止) を考慮する必要があります。

詳細については、「静的プライベート IP アドレスを持つ VM を作成する」を参照してください。

Note

Azure VM とその NIC に対する静的 IP アドレスと動的 IP アドレスの割り当てを決定する必要があります。 VM のゲスト オペレーティング システムは、VM の起動時に NIC に割り当てられている IP を取得します。 ゲスト オペレーティング システムの静的 IP アドレスを NIC に割り当てることはできません。 Azure Backup のような一部の Azure サービスは、少なくともプライマリ NIC がオペレーシング システム内の静的 IP アドレスではなく DHCP に設定されているという事実に依存します。 詳細については、「Azure VM バックアップのトラブルシューティング」を参照してください。

SAP ホスト名仮想化のセカンダリ IP アドレス

各 Azure VM の NIC には、複数の IP アドレスを割り当てることができます。 セカンダリ IP は、DNS A レコードまたは DNS PTR レコードにマップされる SAP 仮想ホスト名に使用できます。 セカンダリ IP アドレスは、Azure NIC の IP 構成に割り当てる必要があります。 セカンダリ IP は DHCP を介して割り当てられないことが多いため、オペレーティング システム内でもセカンダリ IP を静的に構成する必要があります。 各セカンダリ IP は、NIC のバインド先と同じサブネットからのものである必要があります。 セカンダリ IP は、VM を停止または割り当て解除することなく、Azure NIC に追加および削除できます。 NIC のプライマリ IP を追加または削除するには、VM の割り当てを解除する必要があります。

Note

セカンダリ IP 構成では、Azure ロード バランサーのフローティング IP アドレスはサポートされていません。 Azure ロード バランサーは、Pacemaker クラスターを備えた SAP 高可用性アーキテクチャによって使用されます。 このシナリオでは、ロード バランサーによって SAP 仮想ホスト名が有効になります。 仮想ホスト名の使用に関する一般的なガイダンスについては、SAP Note 962955を参照してください。

SAP を実行している VM のある Azure Load Balancer

ロード バランサーは、通常、アクティブクラスターノードとパッシブクラスターノード間のフローティング IP アドレスを提供するために高可用性アーキテクチャで使用されます。 また、1 つの VM のロード バランサーを使用して、SAP 仮想ホスト名の仮想 IP アドレスを保持することもできます。 NIC でセカンダリ IP アドレスを使用したり、同じサブネット内で複数の NIC を使用したりする代わりに 1 つの VM にロード バランサーを使用することができます。

標準ロード バランサーは、そのアーキテクチャが既定でセキュリティで保護されているため、既定の送信アクセス パスを変更します。 Standard ロード バランサーの背後にある VM は、同じパブリック エンドポイントに到達できなくなる可能性があります。 たとえば、オペレーティング システムの更新リポジトリのエンドポイントや Azure サービスのパブリック エンドポイントなどです。 送信接続を提供するオプションについては、「Azure Standard Load Balancer を使用した VM のパブリック エンドポイント接続」を参照してください。

ヒント

Basic ロード バランサーは、Azure の SAP アーキテクチャでは使用しないでください。 Basic ロード バランサーは廃止される予定です。

VM あたり複数の vNIC

1 つの Azure VM に対して複数の仮想ネットワーク インターフェイス カード (vNIC) を定義できます。各 vNIC は、プライマリ vNIC と同じ仮想ネットワーク内の任意のサブネットに割り当てられます。 複数の vNIC を使用できるため、必要に応じてネットワーク トラフィックの分離の設定を開始できます。 たとえば、クライアント トラフィックはプライマリ vNIC 経由でルーティングされ、一部の管理者またはバックエンド トラフィックは 2 つ目の vNIC 経由でルーティングされます。 使用するオペレーティング システムとイメージによっては、オペレーティング システム内の NIC のトラフィック ルートを正しいルーティング用に設定する必要がある場合があります。

VM の種類とサイズによって、VM に割り当てることができる vNIC の数が決まります。 機能と制限については、「Azure portal を使用して VM に複数の IP アドレスを割り当てる」を参照してください。

VM に vNIC を追加しても、使用可能なネットワーク帯域幅は増加しません。 すべてのネットワーク インターフェイスが同じ帯域幅を共有します。 VM がプライベート サブネットにアクセスする必要がある場合にのみ、複数の NIC を使用することをお勧めします。 NSG 機能に依存し、ネットワークとサブネットの要件を簡素化する設計パターンをお勧めします。 この設計では、可能な限り少数のネットワーク インターフェイスを使用する必要がありますが、1 つだけ使用するのが最適です。 例外は HANA スケールアウトであり、HANA 内部ネットワークにはセカンダリ vNIC が必要です。

警告

VM で複数の vNIC を使用する場合は、プライマリ NIC のサブネットを使用してユーザー ネットワーク トラフィックを処理することをおすすめします。

Accelerated Networking

Azure VM 間のネットワーク待ち時間をさらに短縮するために、SAP ワークロードを実行するすべての VM で Azure 高速ネットワークが有効になっていることを確認することをお勧めします。 新しい VM では高速ネットワークが既定で有効になっていますが、デプロイ チェックリストに従って、状態を確認する必要があります。 高速ネットワークの利点は、ネットワークのパフォーマンスと待機時間が大幅に向上することです。 これは、サポートされているすべての VM (特に SAP アプリケーション レイヤーと SAP DBMS レイヤー) に SAP ワークロード用の Azure VM をデプロイするときに使用します。 リンク先のドキュメントには、オペレーティング システムのバージョンと VM インスタンスに対するサポートの依存関係が記載されています。

オンプレミスの接続

Azure での SAP デプロイでは、オンプレミス接続を有効にするために、エンタープライズ全体の中央ネットワーク アーキテクチャと通信ハブが配置されていることを前提としています。 オンプレミスのネットワーク接続は、ユーザーとアプリケーションが Azure の SAP ランドスケープにアクセスして、中央 DNS、ドメイン、セキュリティおよびパッチ管理インフラストラクチャなどの他の中央組織サービスにアクセスできるようにするために不可欠です。

SAP on Azure デプロイにオンプレミス接続を提供するオプションは多数あります。 ほとんどの場合、ネットワークのデプロイは、ハブスポーク ネットワーク トポロジ、またはハブスポーク トポロジの拡張機能であるグローバル仮想 WAN です。

オンプレミスの SAP デプロイでは、Azure ExpressRoute 経由でプライベート接続を使用することをおすすめします。 小規模な SAP ワークロード、リモート リージョン、または小規模なオフィスでは、VPN オンプレミス接続を使用できます。 両サービスの組み合わせとして、VPN との ExpressRoute のサイト間接続をフェールオーバー パスとして使用することが考えられます。

送信および受信のインターネット接続

SAP ランドスケープでは、オペレーティング システム リポジトリの更新プログラムの受信、パブリック エンドポイントでの SAP SaaS アプリケーションへの接続の確立、またはパブリック エンドポイント経由での Azure サービスへのアクセスに関係なく、インターネットへの接続が必要です。 同様に、SAP ランドスケープによって提供されるサービスにインターネット ユーザーがアクセスできるように、クライアントに SAP Fiori アプリケーションへのアクセスを提供することが必要になる場合があります。 SAP ネットワーク アーキテクチャでは、インターネットへのパスと受信要求を計画する必要があります。

NSG 規則を使用し、既知のサービスのネットワーク サービス タグを使用し、ファイアウォールまたはその他のネットワーク仮想アプライアンスへのルーティングと IP アドレス指定を確立することで、仮想ネットワークをセキュリティで保護します。 これらのタスクまたは考慮事項はすべてアーキテクチャの一部です。 プライベート ネットワーク内のリソースは、ネットワーク レイヤー 4 とレイヤー 7 のファイアウォールで保護する必要があります。

ベスト プラクティス アーキテクチャの焦点となるのは、インターネットとの通信パスです。

SAP ワークロード用の Azure VM

一部の Azure VM ファミリは、特に SAP ワークロードに適しています。さらに具体的に言うと、SAP HANA ワークロードに適しています。 適切な VM の種類とその SAP ワークロードをサポートする機能を見つける方法については、「Azure デプロイでサポートされる SAP ソフトウェア」を参照してください。 また、SAP Note 1928533 では、SAP Application Performance Standard (SAPS) ベンチマークと制限事項 (該当する場合) によって測定されたすべての認定済み Azure VM とそのパフォーマンス機能のリストがあります。 SAP ワークロードに対して認定されている VM の種類では、CPU リソースとメモリ リソースの過剰プロビジョニングは使用されません。

サポートされている VM の種類の選択の他にも、それらの VM の種類が特定のリージョンで使用できるかどうかを、「リージョン別の利用可能な製品」のサイトで確認する必要があります。 少なくとも重要なのは、VM の次の機能がシナリオに適合するかどうかを判断することです:

  • CPU およびメモリ リソース
  • 1 秒あたりの入出力操作 (IOPS) 帯域幅
  • ネットワーク機能
  • 接続できるディスクの数
  • 特定の Azure ストレージの種類を使用する機能

特定の FM ファミリと種類に関するこの情報を取得するには、「Azure の仮想マシンのサイズ」を参照してください。

Azure VM の価格モデル

VM の価格モデルでは、使用するオプションを選択できます:

  • 従量課金制の価格モデル
  • 1 年間の予約プランまたは割引プラン
  • 3 年間の予約プランまたは節約プラン
  • スポット価格モデル

さまざまな Azure サービス、オペレーティング システム、リージョンの VM 価格の詳細については、「仮想マシンの価格」を参照してください。

1 年間および 3 年間の節約プランと予約インスタンスの価格と柔軟性については、次の記事を参照してください:

スポット価格の詳細については、「Azure Spot Virtual Machines」を参照してください。

種類が同じ VM でも、Azure リージョンによって価格が異なる場合があります。 一部のお客様は、コストの低い Azure リージョンにデプロイすることでメリットが得られるので、リージョン別の価格に関する情報が計画に役立ちます。

Azure には、専用ホストを使用するオプションも用意されています。 専用ホストを使用すると、Azure サービスのパッチ適用サイクルをより詳細に制御できます。 パッチ適用をスケジュールして、独自のスケジュールとサイクルをサポートできます。 このオファーは、ワークロードの通常のサイクルとは異なるワークロードをお持ちのお客様を対象としています。 詳細については、「Azure 専用ホストの価格」をご覧ください。

SAP ワークロードでは、Azure 専用ホストの使用がサポートされています。 インフラストラクチャの修正プログラムの適用とメンテナンス計画をより詳細に制御したい SAP のお客様の中には、Azure 専用ホストを使用する場合があります。 VM をホストする Azure インフラストラクチャを Microsoft が管理および修正する方法の詳細については、「Azure での仮想マシンのメンテナンス」を参照してください。

VM 用のオペレーティング システム

SAP システムをインストールまたは移行するために、Azure で SAP ランドスケープ用に新しい VM をデプロイする場合は、ワークロードに適したオペレーティング システムを選択することが重要です。 Azure には、Linux および Windows 用のオペレーティング システム イメージと、SAP システムに適した多数のオプションが用意されています。 オンプレミス環境からカスタム イメージを作成またはアップロードしたり、イメージ ギャラリーから使用または一般化したりすることもできます。

使用可能なオプションの詳細と情報については、以下を参照してください:

必要に応じて、オペレーティング システムの更新インフラストラクチャとその SAP ワークロードの依存関係を計画します。 リポジトリ ステージング環境を使用して、更新期間中に同じバージョンのパッチと更新プログラムを使用して、SAP ランドスケープのすべての階層 (サンドボックス、開発、運用前、運用) を同期状態に保つことを検討してください。

第 1 世代と第 2 世代の VM

Azure では、VM を第 1 世代または第 2 世代としてデプロイできます。 Azure での第 2 世代 VM のサポートには、第 2 世代としてデプロイできる Azure VM ファミリが一覧表示されます。 この記事では、Azure の第 1 世代と第 2 世代の VM の機能的な違いについても説明します。

VM をデプロイすると、選択したオペレーティング システム イメージによって、VM が第 1 世代 VM と第 2 世代 VM のどちらになるかが決まります。 Azure (Red Hat Enterprise Linux、SuSE Enterprise Linux、Windows または Oracle Enterprise Linux) で使用できる SAP 用のすべてのオペレーティング システム イメージの最新バージョンは、第 1 世代と第 2 世代の両方で使用できます。 正しい世代の VM をデプロイするには、イメージの説明に基づいてイメージを慎重に選択することが重要です。 同様に、カスタム オペレーティング システム イメージを第 1 世代または第 2 世代として作成でき、VM のデプロイ時に VM の世代に影響を与えます。

Note

VM サイズに関係なく、Azure のすべての SAP デプロイで 第 2 世代 VM を使用することをお勧めします。 SAP 用の最新の Azure VM はすべて、第 2 世代対応であるか、第 2 世代のみに制限されています。 一部の VM ファミリでは、現在、第 2 世代 VM のみがサポートされています。 間もなく利用可能になる一部の VM ファミリでは、第 2 世代のみがサポートされる場合があります。

選択したオペレーティング システム イメージに基づいて、VM が第 1 世代か第 2 世代かを判断できます。 既存の VM をある世代から別の世代に変更することはできません。

デプロイされた VM を第 1 世代から第 2 世代に変更することはできません。 VM の世代を変更するには、希望する世代である新しい VM をデプロイし、新しい世代の VM にソフトウェアを再インストールする必要があります。 この変更は VM のベース VHD イメージにのみ影響し、データ ディスクまたは接続されているネットワーク ファイル システム (NFS) またはサーバー メッセージ ブロック (SMB) 共有には影響しません。 最初に第 1 世代 VM に割り当てられたデータ ディスク、NFS 共有、または SMB 共有は、新しい第 2 世代 VM に接続できます。

Mv2 シリーズのような一部の VM ファミリでは、第 2 世代のみがサポートされています。 今後、新しい VM ファミリについても同じ要件が当てはまる可能性があります。 このシナリオでは、既存の第 1 世代 VM のサイズを変更して、新しい VM ファミリを操作することはできません。 Azure プラットフォームの第 2 世代の要件に加えて、SAP コンポーネントには VM の世代に関連する要件がある場合があります。 選択する VM ファミリの第 2 世代要件については、SAP Note 1928533を参照してください。

Azure VM のパフォーマンス制限

パブリック クラウドとして、Azure は顧客ベース全体でセキュリティで保護された方法でインフラストラクチャを共有することに依存しています。 スケーリングと容量を有効にするために、リソースとサービスごとにパフォーマンス制限が定義されます。 Azure インフラストラクチャのコンピューティング側では、VM サイズごとに定義されている制限を考慮することが重要です。

各 VM には、ディスクとネットワークのスループット、接続できるディスクの数、独自のスループットと IOPS の制限があるローカル一時ストレージがあるかどうか、メモリ サイズ、使用可能な vCPU の数が異なります。

Note

Azure 上の SAP ソリューションの VM サイズに関する決定を行う場合は、各 VM サイズのパフォーマンス制限を考慮する必要があります。 ドキュメントに記載されているクォータは、理論上の達成可能な最大値を表します。 ディスクあたりの IOPS のパフォーマンス制限は、小さな入出力 (I/O) 値 (8 KB など) で実現できますが、大きな I/O 値 (1 MB など) では実現できない場合があります。

VM と同様に、SAP ワークロードの各ストレージの種類と他のすべての Azure サービスには同じパフォーマンス制限が存在します。

SAP デプロイで使用する VM を計画して選択する場合は、次の要因を考慮してください:

  • メモリと CPU の要件から始めます。 CPU パワーの SAPS 要件を DBMS パーツと SAP アプリケーション パーツに分離します。 既存のシステムについては、多くの場合、使用しているハードウェアの関連 SAPS を、既存の SAP Standard アプリケーション ベンチマークに基づいて決定または推定できます。 新しくデプロイされた SAP システムの場合は、サイズ設定の演習を完了して、システムの SAPS 要件を決定します。

  • 既存のシステムでは、DBMS サーバーの I/O スループットと IOPS を測定する必要があります。 新しいシステムの場合、新しいシステムのサイズ設定の演習では、DBMS 側の I/O 要件の一般的な概念も示す必要があります。 わからない場合は、最終的に概念実証を実施する必要があります。

  • DBMS サーバーの SAPS 要件を、Azure のさまざまな VM の種類で提供できる SAPS と比較します。 さまざまな Azure VM タイプの SAPS に関する情報は、SAP ノート 1928533に記載されています。 データベース レイヤーは、ほとんどのデプロイでスケールアウトされない SAP NetWeaver システムのレイヤーであるため、最初に DBMS VM に焦点を当てる必要があります。 これに対し、SAP アプリケーション層はスケール アウトが可能です。個々の DBMS ガイドでは、推奨されるストレージ構成について説明します。

  • 次の結果を要約します:

    • 使用する予定の Azure VM の数。
    • 各 SAP レイヤーの個々の VM ファミリと VM SKU: DBMS、(A)SCS、アプリケーション サーバー。
    • I/O スループットの測定値または計算されたストレージ容量の要件。

HANA Large Instances サービス

Azure には、SAP HANA on Azure Large Instances と呼ばれる専用オファリングで大規模な HANA データベースをスケールアップまたはスケールアウトするコンピューティング機能が用意されています。 このオファリングは、Azure で使用できる VM を拡張します。

Note

HANA Large Instances サービスはサンセット モード段階であり、新しいお客様を受け付けていません。 HANA Large Instance の既存のお客様には、引き続きユニットを提供することが可能です。

SAP on Azure のストレージ

Azure VM では、永続化のためにさまざまなストレージ オプションが使用されます。 簡単に言うと、VM は永続的ストレージタイプと一時ストレージタイプまたは非永続ストレージタイプに分けられます。

SAP ワークロードと特定の SAP コンポーネントに対して、複数のストレージ オプションから選択できます。 詳細については、「SAP ワークロード用の Azure Storage」を参照してください。 この記事では、オペレーティング システム、アプリケーション バイナリ、構成ファイル、データベース データ、ログ ファイルとトレース ファイル、ディスクに格納されているか、ファイル共有にアクセスされているかにかかわらず他のアプリケーションとのファイル インターフェイスなど、SAP のすべての部分のストレージ アーキテクチャについて説明します。

VM 上の一時ディスク

ほとんどの Azure VM for SAP では、マネージド ディスクではない一時ディスクが提供されます。 一時ディスクは、消費可能なデータにのみ使用してください。 一時ディスク上のデータは、予期しないメンテナンス イベント中または VM の再デプロイ中に失われる可能性があります。 一時ディスクのパフォーマンス特性により、オペレーティング システムのスワップ/ページ ファイルに最適です。

アプリケーションまたは期限切れのないオペレーティング システムのデータは、一時ディスクに格納しないでください。 Windows 環境では、一時ドライブは通常、ドライブ D としてアクセスされます。Linux システムでは、マウント ポイントは、多くの場合、/dev/sdb デバイス、/mnt、または /mnt/resource です。

一部の VM では 一時ドライブは提供されません。 これらの VM サイズを SAP に使用する予定の場合は、オペレーティング システム ディスクのサイズを増やす必要がある場合があります。 詳細については、SAP Note 1928533 をご覧ください。 一時ディスクを持つ VM の場合は、Azure の仮想マシンのサイズに関する各 VM シリーズの一時ディスク サイズと IOPS とスループットの制限に関する情報を取得します。

一時ディスクを持つ VM シリーズと、一時ディスクを持たない VM シリーズの間で直接サイズを変更することはできません。 現在、このような 2 つの VM ファミリ間のサイズ変更をすると失敗します。 解決策は、オペレーティング システムのディスク スナップショットを使用して、新しいサイズの一時ディスクがない VM を再作成することです。 他のすべてのデータ ディスクとネットワーク インターフェイスを保持します。 ローカルの一時ディスクを持つ VM サイズのサイズを、そうでない VM サイズに変更する方法について説明します。

SAP のネットワーク共有とボリューム

通常、SAP システムには 1 つ以上のネットワーク ファイル共有が必要です。 通常、ファイル共有は次のいずれかのオプションです:

  • SAP トランスポート ディレクトリ (/usr/sap/trans または TRANSDIR)。
  • 複数のアプリケーション サーバーをデプロイするための SAP ボリュームまたは共有 sapmnt または saploc ボリューム。
  • SAP (A)SCS、SAP ERS、またはデータベース (/hana/shared) の高可用性アーキテクチャ ボリューム。
  • ファイルのインポートとエクスポートのためにサードパーティ製アプリケーションを実行するファイル インターフェイス。

これらのシナリオでは、Azure Files や Azure NetApp Files などの Azure サービスを使用することをお勧めします。 選択したリージョンでこれらのサービスを利用できない場合、またはソリューション アーキテクチャで使用できない場合は、代替手段として、自己管理型、VM ベースのアプリケーション、またはサード パーティのサービスから NFS または SMB ファイル共有を提供します。 Azure の SAP システムのストレージ レイヤーにサードパーティのサービスを使用する場合の SAP サポートの制限事項については、SAP Note 2015553 を参照してください。

ネットワーク共有の重要な性質が多く、設計 (高可用性のため) またはプロセス (ファイル インターフェイスの場合) の単一障害点であることが多いため、それぞれの Azure ネイティブ サービスに依存して、独自の可用性、SLA、回復性を確保することをお勧めします。 計画フェーズでは、3 つの要因を考慮することが重要です:

  • NFS または SMB 共有の設計。SAP システム ID (SID)、ランドスケープごと、リージョンごとに使用する共有を含みます。
  • プライベート エンドポイントの IP 要件や、Azure NetApp Files などのサービスの専用サブネットなど、サブネットのサイズ設定。
  • SAP システムと接続されたアプリケーションへのネットワーク ルーティング。
  • Azure Files のパブリック エンドポイントまたは プライベート エンドポイント の使用。

要件と、高可用性シナリオで NFS または SMB 共有を使用する方法については、「高可用性」を参照してください。

Note

ネットワーク共有に Azure Files を使用する場合は、プライベート エンドポイントを使用することをお勧めします。 万が一ゾーン障害が発生した場合、NFS クライアントは自動的に正常なゾーンにリダイレクトされます。 VM で NFS 共有または SMB 共有を再マウントする必要はありません。

SAP ランドスケープのセキュリティ

Azure で SAP ワークロードを保護するには、セキュリティの複数の側面を計画する必要があります:

  • ネットワークのセグメント化と各サブネットとネットワーク インターフェイスのセキュリティ。
  • SAP ランドスケープ内の各レイヤーでの暗号化。
  • エンド ユーザーと管理アクセスとシングル サインオン サービス用の ID ソリューション。
  • 脅威と操作の監視。

この章のトピックは、利用可能なすべてのサービス、オプション、および代替手段を網羅したリストを提供することではありません。 ここでは、Azure のすべての SAP デプロイについて考慮する必要があるいくつかのベスト プラクティスを示します。 エンタープライズまたはワークロードの要件に応じて、他にも対応する側面があります。 セキュリティ設計の詳細については、一般的な Azure ガイダンスについては、次のリソースを参照してください:

セキュリティ グループを使用して仮想ネットワークをセキュリティで保護する

Azure での SAP ランドスケープの計画には、SAP ワークロード専用の仮想ネットワークとサブネットを使用して、ある程度のネットワーク セグメント化を含める必要があります。 サブネット定義のベスト プラクティスについては、ネットワークおよびその他の Azure アーキテクチャ ガイドを参照してください。 NSG 内の ASG と共に NSG を使用して、受信と送信の接続を許可することをお勧めします。 ASG を設計する場合、VM 上の各 NIC を複数の ASG に関連付けることができるため、異なるグループを作成できます。 たとえば、ランドスケープ全体のすべてのデータベース サーバーを含む DBMS VM 用の ASG を作成します。 1 つの SAP SID のすべての VM (アプリケーションと DBMS) に対して別の ASG を作成します。 これにより、データベース全体の ASG に対して 1 つの NSG 規則を定義し、SID 固有の ASG に対してのみより具体的な規則を定義できます。

NSG では、NSG に対して定義した規則を使用してパフォーマンスが制限されることはありません。 トラフィック フローを監視するために、必要に応じて、情報イベント管理 (SIEM) または任意の侵入検出システム (IDS) によって評価されたログを使用して NSG フロー ログをアクティブ化し、疑わしいネットワーク アクティビティを監視および操作できます。

ヒント

NSG はサブネット レベルでのみアクティブ化します。 NSG はサブネット レベルと NIC レベルの両方でアクティブ化できますが、ネットワーク トラフィックの制限を分析する際のトラブルシューティングの妨げとなることがよくあります。 NIC レベルで NSG を使用するのは、例外的な状況と必要な場合のみです。

サービス用のプライベート エンドポイント

多くの Azure PaaS サービスは、既定でパブリック エンドポイント経由でアクセスされます。 通信エンドポイントは Azure バックエンド ネットワーク上にありますが、エンドポイントはパブリック インターネットに公開されます。 プライベート エンドポイントは、独自のプライベート仮想ネットワーク内のネットワーク インターフェイスです。 Azure Private Link を使用して、プライベート エンドポイントはサービスを仮想ネットワークに投影します。 選択した PaaS サービスは、ネットワーク内の IP 経由でプライベートにアクセスされます。 構成によっては、プライベート エンドポイント経由でのみ通信するようにサービスを設定できます。

プライベート エンドポイントを使用すると、データ漏えいに対する保護が強化され、多くの場合、オンプレミスおよびピアリングされたネットワークからのアクセスが簡略化されます。 多くの場合、パブリック エンドポイントに必要なファイアウォール ポートを開くネットワーク ルーティングとプロセスが簡略化されます。 リソースはプライベート エンドポイントによってアクセスされるため、既にネットワーク内にあります。

プライベート エンドポイントを使用するオプションを提供する Azure サービスについては、「Private Link の使用可能なサービス」を参照してください。 Azure Files を使用する NFS または SMB の場合は、SAP ワークロードに対して常にプライベート エンドポイントを使用することをお勧めします。 サービスを使用して発生する料金については、｢プライベート エンドポイントの価格」を参照してください。 一部の Azure サービスには、必要に応じてサービスのコストが含まれる場合があります。 この情報は、サービスの価格情報に含まれています。

暗号化

企業ポリシーによっては、SAP ワークロードに Azure の既定のオプションを超える暗号化が必要になる場合があります。

インフラストラクチャ リソースの暗号化

既定では、Azure のマネージド ディスクと BLOB ストレージは、プラットフォーム マネージド キー (PMK) を使用して暗号化されます。 さらに、マネージド ディスクと BLOB ストレージの Bring Your Own Key (BYOK) 暗号化は、Azure の SAP ワークロードでサポートされています。 マネージド ディスク暗号化の場合は、企業のセキュリティ要件に応じて、さまざまなオプションから選択できます。 Azure 暗号化オプションには、次のものがあります:

  • ストレージ側暗号化 (SSE) PMK (SSE-PMK)
  • SSE カスタマー マネージド キー (SSE-CMK)
  • 保存時の二重暗号化
  • ホストベースの暗号化

Azure Disk Encryption の説明など、詳細については、「Azure 暗号化オプションの比較」を参照してください。

Note

現時点では、パフォーマンス制限の可能性があるため、Linux で実行する場合は、M シリーズ VM ファミリ内の VM でホストベースの暗号化を使用しないでください。 マネージド ディスクに対する SSE-CMK 暗号化の使用は、この制限の影響を受けません。

Linux システム上の SAP デプロイでは、Azure Disk Encryption を使用しないでください。 Azure Disk Encryption では、Azure Key Vault の CMK を使用して SAP VM 内で暗号化を実行する必要があります。 Linux の場合、Azure Disk Encryption は SAP ワークロードに使用されるオペレーティング システム イメージをサポートしていません。 Azure Disk Encryption は、SAP ワークロードを持つ Windows システムで使用できますが、Azure Disk Encryption とデータベース ネイティブ暗号化を組み合わせることはできません。 Azure Disk Encryption の代わりにデータベース ネイティブ暗号化を使用することをおすすめします。 詳細については、次のセクションを参照してください。

マネージド ディスク暗号化と同様に、保存時の Azure Files 暗号化 (SMB と NFS) は、PMK または CMK で使用できます。

SMB ネットワーク共有の場合は、構成が転送中の暗号化のサポートに影響するため、Azure Files と SMB バージョンとのオペレーティング システムの依存関係とを慎重に確認してください。

重要

カスタマー マネージド暗号化を使用する場合の暗号化キーの保存と保護に関する慎重な計画の重要性は、いくら強調してもし過ぎることはありません。 暗号化キーがないと、ディスクなどの暗号化されたリソースにアクセスできなくなり、データが失われる可能性があります。 キーの保護と、特権ユーザーまたはサービスのみに対するキーへのアクセスを慎重に検討してください。

SAP コンポーネントの暗号化

SAP レベルでの暗号化は、次の 2 つのレイヤーに分けることができます:

  • DBMS 暗号化
  • 転送の暗号化

DBMS 暗号化の場合、SAP NetWeaver または SAP S/4HANA デプロイでサポートされている各データベースでは、ネイティブ暗号化がサポートされます。 透過的なデータベース暗号化は、Azure に配置されているインフラストラクチャ暗号化とは完全に独立しています。 SSE とデータベース暗号化は同時に使用できます。 暗号化を使用する場合、暗号化キーの場所、ストレージ、保管は非常に重要です。 暗号化キーが失われると、データベースを起動または復旧できないため、データが失われます。

一部のデータベースには、データベース暗号化方法がない場合や、有効にするために専用の設定が必要でない場合があります。 他のデータベースでは、データベース暗号化がアクティブ化されるときに、DBMS バックアップが暗黙的に暗号化される場合があります。 透過的なデータベース暗号化を有効にして使用する方法については、次の SAP ドキュメントを参照してください:

ソフトウェア暗号化の有効化、使用、またはトラブルシューティングの方法については、SAP または DBMS ベンダーにお問い合わせください。

重要

暗号化キーを格納して保護するための慎重な立案がいかに大切かは強調してもし過ぎることはありません。 暗号化キーがないと、データベースまたは SAP ソフトウェアにアクセスできない可能性があり、データが失われる可能性があります。 キーを保護する方法を慎重に検討してください。 特権ユーザーまたはサービスによってのみがキーへのアクセスが許可されるようにします。

トランスポート、すなわち通信の暗号化は、SAP エンジンと DBMS 間の SQL Server 接続にも適用されます。 同様に、SAP プレゼンテーション レイヤー (SAPGui セキュア ネットワーク接続または SNC) または Web フロントエンドへの HTTPS 接続からの接続を暗号化できます。 転送中の暗号化を有効にして管理するには、アプリケーション ベンダーのドキュメントを参照してください。

脅威の監視とアラート

脅威の監視とアラート ソリューションを展開して使用するには、まず組織のアーキテクチャを使用します。 Azure サービスは、脅威の防止とセキュリティ ビューを提供し、SAP デプロイ計画全体に組み込むことができます。 Microsoft Defender for Cloud は、脅威保護の要件に対処します。 Defender for Cloud は通常、SAP コンポーネントだけでなく、Azure デプロイ全体の全体的なガバナンス モデルの一部です。

セキュリティ情報イベント管理 (SIEM) とセキュリティ オーケストレーション自動応答 (SOAR) ソリューションの詳細については、「SAP 統合用の Microsoft Sentinel ソリューション」を参照してください。

SAP VM 内のセキュリティ ソフトウェア

Sap Note 2808515 for Linux および SAP Note 106267 for Windows では、SAP サーバーでウイルス スキャナーまたはセキュリティ ソフトウェアを使用する場合の要件とベスト プラクティスが説明されています。 SAP コンポーネントを Azure にデプロイするときは、SAP の推奨事項に従うことをお勧めします。

高可用性

Azure の SAP 高可用性には、次の 2 つのコンポーネントがあります:

  • Azure インフラストラクチャの高可用性: Azure コンピューティング (VM)、ネットワーク、ストレージ サービスの高可用性、および SAP アプリケーションの可用性を向上させる方法。

  • SAP アプリケーションの高可用性: サービス復旧を使用して Azure インフラストラクチャの高可用性と組み合わせる方法。 SAP ソフトウェア コンポーネントで高可用性を使用する例を次に示します:

    • SAP (A)SCS および SAP ERS インスタンス
    • データベース サーバー

Azure での SAP の高可用性の詳細については、次の記事を参照してください:

Linux 上の Pacemaker と Windows Server フェールオーバー クラスターは、Azure で Microsoft が直接サポートしている SAP ワークロード用の唯一の高可用性フレームワークです。 その他の高可用性フレームワークは Microsoft ではサポートされていないため、設計、実装の詳細、およびベンダーからの運用サポートが必要になります。 詳細については、「Azure での SAP でサポートされるシナリオ」を参照してください。

障害復旧

多くの場合、SAP アプリケーションは企業内で最もビジネスクリティカルなプロセスの 1 つです。 その重要性と、予期しない中断後に再び運用するために必要な時間に基づいて、事業継続とディザスター リカバリー (BCDR) シナリオを慎重に計画する必要があります。

この要件に対処する方法については、「SAP ワークロードのディザスター リカバリーの概要とインフラストラクチャのガイドライン」を参照してください。

バックアップ

BCDR 戦略の一環として、SAP ワークロードのバックアップは、計画されたデプロイの不可欠な部分である必要があります。 バックアップ ソリューションは、SAP ソリューション スタックのすべてのレイヤー (VM、オペレーティング システム、SAP アプリケーション レイヤー、DBMS レイヤー、および共有ストレージ ソリューション) をカバーする必要があります。 SAP ワークロードで使用される Azure サービスのバックアップや、暗号化やアクセス キーなどの他の重要なリソースのバックアップも、バックアップと BCDR の設計の一部として含める必要があります。

Azure Backup には、バックアップ用の PaaS ソリューションが用意されています:

  • VM の Azure Backup を使用した VM 構成、オペレーティング システム、SAP アプリケーション レイヤー (マネージド ディスク上のデータのサイズ変更)。 サポート マトリックスを確認して、アーキテクチャでこのソリューションを使用できることを確認します。
  • SQL Server と SAP HANA データベースのデータとログ バックアップ。 これには、HANA システム レプリケーションや SQL Always On などのデータベース レプリケーション テクノロジのサポートと、ペアになっているリージョンのリージョン間サポートが含まれます。
  • Azure Files を使用したファイル共有のバックアップ。 NFS または SMB とその他の構成の詳細のサポートを確認します。

または、Azure NetApp Files をデプロイする場合は、SAP HANA と Oracle DBMS の統合とスケジュールされたバックアップの統合など、ボリューム レベルでバックアップ オプションを使用できます。

Azure Backup ソリューションには、悪意のある削除や偶発的な削除を防ぎ、データの損失を防ぐための論理的な削除オプションが用意されています。 論理的な削除は、Azure Files を使用してデプロイするファイル共有でも使用できます。

バックアップ オプションは、自分で作成して管理するソリューション、またはサード パーティ製ソフトウェアを使用している場合に使用できます。 BLOB データに不変ストレージを使用するなど、Azure Storage でサービスを使用することもできます。 現在、この自己管理オプションは、SAP ASE や IBM Db2 などの一部のデータベースの DBMS バックアップ オプションとして必要です。

ランサムウェア攻撃から保護および検証するには、Azure のベスト プラクティスの推奨事項を使用します。

ヒント

バックアップ戦略に、デプロイの自動化の保護、Azure リソースの暗号化キー、使用した場合の透過的なデータベース暗号化が含まれるようにします。

リージョン間バックアップ

リージョンをまたがるバックアップ要件の場合は、回復時間の目標 (RTO) とソリューションによって提供される回復ポイントの目標 (RPO) と、それが BCDR の設計とニーズに一致するかどうかを判断します。

Azure への SAP 移行

さまざまな SAP 製品、バージョンの依存関係、使用可能なネイティブ オペレーティング システムと DBMS テクノロジに対するすべての移行アプローチとオプションを記述しきることはできません。 組織のプロジェクト チームと、サービス プロバイダー側の担当者は、Azure への SAP 移行をスムーズにするために、いくつかの手法を検討する必要があります。

  • 移行中のパフォーマンスをテストします。 SAP 移行計画の重要な部分は、技術的なパフォーマンス テストです。 移行チームは、主要な担当者が、接続されたインターフェイスやアプリケーションを含む、移行された SAP システムのアプリケーションと技術テストを実行するための十分な時間と可用性を確保する必要があります。 SAP の移行を成功させるには、移行前と移行後のランタイムと、テスト環境の主要なビジネス プロセスの精度を比較することが重要です。 この情報を使用して、運用環境を移行する前にプロセスを最適化します。

  • SAP 移行には Azure サービスを使用します。 一部の VM ベースのワークロードは、Azure Migrate や Azure Site Recovery などのサービス、またはサードパーティ製ツールを使用して、Azure に変更なしで移行されます。 オペレーティング システムのバージョンと実行する SAP ワークロードがサービスによってサポートされていることを慎重に確認します。

    多くの場合、サービスではデータベースの一貫性を保証できないため、データベース ワークロードは意図的にサポートされません。 移行サービスで DBMS の種類がサポートされている場合、多くの場合、データベースの変更またはチャーンが高すぎます。 ビジー状態の SAP システムのほとんどは、移行ツールで許可される変更率を満たしていません。 運用環境の移行まで、問題が発見または検出されない場合があります。 多くの場合、一部の Azure サービスは SAP システムの移行に適していません。 Azure Site Recovery と Azure Migrate には、大規模な SAP 移行の検証はありません。 実証済みの SAP 移行手法は、DBMS レプリケーションまたは SAP 移行ツールに依存することです。

    オンプレミスの移行よりも、基本的な VM 移行ではなく Azure でのデプロイが望ましく、より簡単に実行できます。 Azure Center for SAP solutions や Azure デプロイ自動化フレームワークなどの自動化されたデプロイ フレームワークを使用すると、自動化されたタスクをすばやく実行できます。 HANA システム レプリケーション、DBMS のバックアップと復元、SAP 移行ツールなどの DBMS ネイティブ レプリケーション テクノロジを使用して、SAP ランドスケープを新しくデプロイされたインフラストラクチャに移行するには、SAP システムに関する確立された技術的知識が必要です。

  • インフラストラクチャのスケールアップ。 SAP の移行中に、インフラストラクチャの容量を増やすと、より迅速にデプロイできます。 プロジェクト チームは、より多くの CPU とメモリを提供するために、VM サイズのスケールアップを検討する必要があります。 また、VM 集計ストレージとネットワーク スループットのスケールアップも検討する必要があります。 同様に、VM レベルでは、Premium SSD v1 のオンデマンド バーストとパフォーマンス レベルでスループットを向上させるために、個々のディスクなどのストレージ要素を検討します。 構成された値より上の Premium SSD v2 を使用する場合は、IOPS とスループットの値を増やします。 NFS ファイル共有と SMB ファイル共有を拡大して、パフォーマンスの制限を高めます。 Azure 管理ディスクのサイズを小さくすることはできないこと、またサイズ、パフォーマンス レベル、スループットの KPI の削減には、さまざまなクールダウン時間が発生する可能性があることに注意してください。

  • ネットワークとデータのコピーを最適化します。 SAP システムを Azure に移行するには、常に大量のデータを移動する必要があります。 データは、データベースとファイルのバックアップまたはレプリケーション、アプリケーション間のデータ転送、SAP 移行のエクスポートなどです。 使用する移行プロセスに応じて、データを移動するための適切なネットワーク パスを選択する必要があります。 多くのデータ移動操作では、プライベート ネットワークではなくインターネットを使用することが、Azure Storage に安全にデータをコピーするための最も簡単なパスです。

    ExpressRoute または VPN を使用すると、ボトルネックが発生する可能性があります:

    • 移行データで使用される帯域幅が多すぎると、Azure で実行されているワークロードへのユーザー アクセスが妨げられます。
    • ファイアウォールやスループット制限などのオンプレミスのネットワーク ボトルネックは、多くの場合、移行中にのみ検出されます。

    使用されているネットワーク接続に関係なく、多くの場合、データ移動の単一ストリーム ネットワーク パフォーマンスは低くなります。 複数の TCP ストリームでデータ転送速度を上げるには、複数のストリームをサポートできるツールを使用します。 SAP ドキュメントおよびこのトピックに関する多くのブログ記事で説明されている最適化手法を適用します。

ヒント

計画段階では、Azure への大規模なデータ転送に使用する専用の移行ネットワークを検討することが重要です。 たとえば、バックアップやデータベース レプリケーションをすることや、Azure Storage へのデータ転送にパブリック エンドポイントを使用することなどです。 ユーザーとアプリケーションのネットワーク パスに対する移行の影響を想定し、軽減する必要があります。 ネットワーク計画の一環として、移行のすべてのフェーズと、移行中の Azure での部分的に生産性の高いワークロードのコストを検討します。

SAP のサポートと運用

Azure での SAP デプロイの前と実行中に考慮する必要があるその他の領域がいくつかあります。

SAP 用 Azure VM 拡張機能

Azure Monitoring Extension、Enhanced Monitoring、Azure Extension for SAP はすべて、Azure インフラストラクチャに関する基本的なデータを SAP ホスト エージェントに提供するためにデプロイする必要がある VM 拡張機能を参照します。 SAP ノートでは、拡張機能を監視拡張機能 または拡張監視と呼んでいる場合があります。 Azure では、Azure Extension for SAP (SAP 用 Azure 拡張機能) と呼ばれます。 サポート目的で、SAP ワークロードを実行するすべての Azure VM に拡張機能をインストールする必要があります。 詳細については、SAP 用 Azure VM 拡張機能に関するページを参照してください。

SAP サポート用 SAProuter

Azure で SAP ランドスケープを運用するには、サポート目的で SAP との間の接続が必要です。 通常、接続は SAProuter 接続の形で行われ、インターネット上の暗号化ネットワーク チャネルを経由するか、SAP へのプライベート VPN 接続を経由します。 ベスト プラクティスと Azure での SAProuter の実装例については、「SAP on Azure の受信および送信インターネット接続」のアーキテクチャ シナリオを参照してください。

次のステップ