この記事では、Azure で SAP ランドスケープ全体を設計するためのベスト プラクティスについて説明します。 SAP ランドスケープには、ハブ、運用、非運用、ディザスター リカバリーの各環境を対象とした複数の SAP システムが含まれています。 特定の SAP システムではなくネットワーク設計に重点を置いた推奨事項について説明します。 目標は、セキュリティで保護され、パフォーマンスが高く、回復性がある SAP ランドスケープを設計するための推奨事項を提供することです。
アーキテクチャ
アーキテクチャの Visio ファイルをダウンロードする
ワークフロー
- オンプレミス ネットワーク: オンプレミス ネットワークから接続された Azure リージョンへの ExpressRoute 接続。
- Azure サブスクリプションのリージョン ハブ: SAP だけでなく、エンタープライズ全体の中央のサービスを含む Azure サブスクリプション。 ハブ サブスクリプションは、SAP ワークロードを含むスポーク仮想ネットワークにピアリングすることで接続を提供します。
- ハブ仮想ネットワーク: プライマリ リージョンまたはリージョン A の中央のハブの仮想ネットワーク スポーク。
- ハブ ディザスター リカバリー (DR) 仮想ネットワーク: ディザスター リカバリー リージョン内の中央のハブの仮想ネットワーク スポーク。 プライマリ リージョンの運用仮想ネットワークのサブネット設計をミラーリングします。
- Azure サブスクリプション SAP 非運用環境: 非運用環境のすべての SAP ワークロード用の Azure サブスクリプション。 これには、運用前、品質保証、開発、サンドボックスの各環境が含まれます。
- SAP 非運用環境スポーク仮想ネットワーク: プライマリ リージョンの SAP 非運用ワークロード用に仮想ネットワークを分離します。 各 SAP 環境には、専用の仮想ネットワークとサブネットがあります。
- Azure サブスクリプション SAP 運用環境: 運用環境のすべての SAP ワークロード用の Azure サブスクリプション。
- SAP 運用スポーク仮想ネットワーク: 複数のサブネットを含む SAP 運用環境用の仮想ネットワーク。 この仮想ネットワークはプライマリ リージョンにあります。
- SAP 運用環境ディザスター リカバリー (DR) スポーク仮想ネットワーク: セカンダリ ディザスター リカバリー リージョンの SAP 運用環境用の仮想ネットワーク。 プライマリ リージョンの運用仮想ネットワークのサブネット設計をミラーリングします。
- Azure サービス: SAP ランドスケープに接続できる Azure サービスのサンプリング。
- SAP Business Technology Platform (BTP): SAP 環境は、Azure Private Link を介して SAP Business Technology Platform にアクセスします。
Azure サブスクリプション
ハブスポーク ネットワーク設計を使用することをお勧めします。 ハブスポーク設計では、SAP 環境を分割するために少なくとも 3 つのサブスクリプションが必要です。 (1) リージョン ハブ仮想ネットワーク、(2) 非運用環境仮想ネットワーク、(3) 運用環境仮想ネットワークのサブスクリプションが必要です。 サブスクリプションでは、課金、ポリシー、およびセキュリティの境界が提供されます。 サブスクリプションには正しい数はありません。 使用するサブスクリプションの数は、課金、ポリシー、およびセキュリティのニーズによって異なります。 一般的に、使用するサブスクリプションが多すぎないようにする必要があります。 サブスクリプションが多すぎると、不要な管理のオーバーヘッドが発生し、ネットワークがより複雑になる可能性があります。 たとえば、SAP システムごとのサブスクリプションは必要ありません。 このアーキテクチャでは、次の 3 つのサブスクリプションが使用されます。
リージョン ハブ: プライマリ リージョンとセカンダリ リージョンのハブ仮想ネットワークが存在する Azure 仮想ハブ サブスクリプション。 このサブスクリプションは、SAP だけでなく、すべての中央サービス用です。
SAP 非運用環境: サンドボックス、開発、品質保証、または運用前の各システムが存在する Azure SAP 非運用サブスクリプション。
SAP 運用環境: 運用とディザスター リカバリーのシステムを構成した Azure SAP 運用サブスクリプション。
詳細については、次を参照してください。
ネットワーク設計
ハブスポーク トポロジは、SAP ランドスケープに推奨されるネットワーク設計です。 このトポロジでは、運用ハブ仮想ネットワークが中央の接続ポイントとして機能します。 オンプレミス ネットワークとさまざまなスポーク仮想ネットワークに接続し、ユーザーとアプリケーションが SAP ワークロードにアクセスできるようにします。 このハブスポーク トポロジ内での SAP ネットワーク設計の推奨事項を次に示します。
オンプレミス接続には ExpressRoute を使用します。 SAP ワークロードの場合は、ExpressRoute を使用してオンプレミス ネットワークをハブ仮想ネットワークとハブ DR 仮想ネットワークに接続することをお勧めします。 グローバルな場所がある場合は、Azure Virtual WAN トポロジを使用できます。 Azure ExpressRoute のバックアップとして、またはサードパーティのルート要件に対して、サイト間 (S2S) VPN を設定することを検討してください。
詳細については、次を参照してください。
- SAP 移行のネットワーク トポロジと接続性
- ハブとスポークのアーキテクチャ
- Azure Virtual WAN:
- ExpressRoute プライベート ピアリングのバックアップとしてのサイト間 VPN
環境ごとに 1 つの仮想ネットワークを使用します。 環境ごとに 1 つの仮想ネットワーク (SAP デプロイ層) を使用することをお勧めします。 このアーキテクチャでは、運用環境、開発、品質保証、サンドボックスには、異なる仮想ネットワークを使用します。 このネットワーク設計は、大規模なエンタープライズ アーキテクチャに最適です。
中央のファイアウォールを使用します。 リモート関数呼び出し (RFC) 接続を含むスポーク仮想ネットワークへのすべてのネットワーク トラフィックは、ハブ仮想ネットワーク内の中央のファイアウォールを通過する必要があります。 スポーク仮想ネットワーク間のネットワーク通信 (スポーク間通信) は、ハブ仮想ネットワークの Azure Firewall サブネット内のハブ仮想ネットワーク ファイアウォールを通過します。 同様に、スポーク仮想ネットワークとオンプレミス ネットワークの間のネットワーク通信もハブ仮想ネットワーク ファイアウォールを通過します。 当社では、仮想ネットワーク ピアリングを使用して、さまざまなスポーク仮想ネットワークをハブ仮想ネットワークに接続しました。 スポークの仮想ネットワーク間のすべての通信は、ハブ仮想ネットワークのファイアウォールを通過します。 ファイアウォールの代わりにネットワーク仮想アプライアンスを使用することもできます。 詳細については、ネットワーク仮想アプライアンスに関するページをご覧ください。
仮想ネットワーク内に留まるネットワーク トラフィックがファイアウォールを通過しないようにする必要があります。 たとえば、SAP アプリケーション サブネットと SAP データベース サブネットの間にファイアウォールを配置しないでください。 SAP アプリケーションと SAP カーネルを実行している SAP システムのデータベース管理システム (DBMS) レイヤーの間にファイアウォールまたはネットワーク仮想アプライアンス (NVA) を配置することはできません。
スポーク仮想ネットワークのピアリングは行わないでください。 スポーク仮想ネットワーク間の仮想ネットワーク ピアリングは、可能な限り回避する必要があります。 スポーク間仮想ネットワーク ピアリングを使用すると、スポーク間の通信でハブ仮想ネットワークのファイアウォールをバイパスできます。 スポーク間仮想ネットワーク ピアリングは、たとえば SAP 環境間のデータベース レプリケーションなど、高帯域幅の要件がある場合にのみ構成してください。 他のすべてのネットワーク トラフィックは、ハブ仮想ネットワークとファイアウォールを通過するようにする必要があります。 詳細については、「SAP on Azure の受信および送信インターネット接続」を参照してください。
サブネット
各 SAP 環境 (運用、運用前、開発、サンドボックス) をサブネットに分割し、サブネットを使用して関連するサービスをグループ化することが推奨されます。 SAP ランドスケープをサブネット化するための推奨事項を次に示します。
サブネットの数
アーキテクチャ内の運用仮想ネットワークには、5 つのサブネットがあります。 この設計は、大規模なエンタープライズ ソリューションに最適です。 サブネットの数は、減らすことも増やすこともできます。 仮想ネットワーク内のリソースの数に応じて、仮想ネットワーク内のサブネットの数を決めます。
サブネットのサイズ設定
サブネットに十分なネットワーク アドレス空間があることを確認します。 SAP 仮想ホスト名を使用する場合は、SAP サブネットに、より多くのアドレス空間が必要です。 多くの場合、各 SAP インスタンスには 2 つまたは 3 つの IP アドレスが必要であり、これには仮想マシンのホスト名用の 1 つの IP アドレスが含まれます。 他の Azure サービスでは、SAP ワークロード仮想ネットワークにデプロイするときに、専用サブネットが必要になる場合があります。
アプリケーション サブネット
アプリケーション サブネットには、SAP アプリケーション サーバー、SAP Central Services (ASCS)、SAP Enqueue Replication Services (ERS)、および SAP Web Dispatcher インスタンスを実行する仮想マシンが含まれています。 サブネットには、Azure Files へのプライベート エンドポイントも含まれています。 この図では、仮想マシンをロール別にグループ化しました。 回復性のあるデプロイには、柔軟なオーケストレーション、可用性ゾーン、または可用性セットで仮想マシン スケール セットを使用することを推奨します。 詳細については、「次のステップ」を参照してください。
データベース サブネット
データベース サブネットには、データベースを実行している仮想マシンが保持されます。 この図では、同期レプリケーションを使用する仮想マシンのペアが、1 つの SAP 環境のすべてのデータベース仮想マシンを表しています。
境界サブネット
境界サブネットは、インターネットに接続され、SAP 境界サブネットと Application Gateway サブネットを含んでいます。 これら 2 つのサブネットを設計する場合の推奨事項を次に示します。
SAP 境界サブネット: SAP 境界サブネットは、SAProuter、SAP Cloud Connector、SAP Analytics Cloud Agent、Application Gateway などのインターネットに接続されたアプリケーションを含む境界ネットワークです。 これらのサービスには、SAP システムへの依存関係があり、SAP チームがそれらをデプロイ、管理、および構成する必要があります。 中央の IT チームが、SAP 境界サブネット内のサービスを管理しないようにしてください。 このため、これらのサービスは、ハブ仮想ネットワークではなく SAP スポーク仮想ネットワークに配置する必要があります。 アーキテクチャ図は、運用環境の SAP 境界ネットワークのみを示しています。 非運用環境の仮想ネットワークには SAP 境界サブネットがありません。 非運用 SAP サブスクリプションのワークロードでは、SAP 境界サブネット内のサービスが使用されます。
非運用サブスクリプションでは、SAP 境界サブネットの個別のセットを作成できます。 このアプローチは、重要なワークロードまたは頻繁に変更されるワークロードに対してのみお勧めします。 専用の非運用 SAP 境界は、テストおよび新機能のデプロイに役立ちます。 重要度の低いアプリケーションまたは時間が経過してもあまり変更されないアプリケーションには、個別の非運用 SAP 境界サブネットは必要ありません。
Application Gateway サブネット: Azure Application Gateway には専用のサブネットが必要です。 これを使用して、SAP Fiori などの SAP サービスが使用できるインターネットからのトラフィックを許可します。 推奨されるアーキテクチャでは、ハブ仮想ネットワーク内のフロントエンド パブリック IP アドレスと共に Azure Application Gateway を配置します。 Azure Application Gateway には、少なくとも /29 サイズのサブネットが必要です。 サイズ /27 以上をお勧めします。 同じサブネットで両方のバージョンの Application Gateway (v1 と v2) を使用することはできません。 詳しくは、Azure Application Gateway のサブネットに関するページを参照してください。
セキュリティを強化するために、境界サブネットを別の仮想ネットワークに配置する: セキュリティを強化するために、SAP 境界サブネットと Application Gateway サブネットを SAP 運用サブスクリプション内の別の仮想ネットワークに配置できます。 SAP 境界スポーク仮想ネットワークはハブ仮想ネットワークとピアリングされ、パブリック ネットワークへのすべてのネットワーク トラフィックは境界仮想ネットワークを経由して送信されます。 この代替アプローチでは、インバウンド接続用のパブリック IP アドレスを持つ Azure Application Gateway が、SAP 専用のスポーク仮想ネットワークに配置されていることを示しています。
この代替アーキテクチャを含む Visio ファイルをダウンロードします。
このネットワーク設計によって、より優れたインシデント対応機能ときめ細かいネットワーク アクセス制御が提供されます。 ただし、管理の複雑さ、ネットワーク待ち時間、デプロイのコストも増加します。 各ポイントについて説明しましょう。
インシデント対応の改善: SAP 境界スポーク仮想ネットワークを使用すると、侵害を検出した場合に、侵害されたサービスを迅速に分離することができます。 SAP 境界スポーク仮想ネットワークからハブへの仮想ネットワーク ピアリングを削除することで、SAP 境界ワークロードと SAP アプリケーション仮想ネットワーク アプリケーションをインターネットから素早く分離できます。 インシデント対応のためにネットワーク セキュリティ グループ (NSG)ルールの変更に依存したくはありません。 NSG ルールを変更または削除しても、新しい接続に影響するだけで、悪意のある既存の接続は切断されません。
詳細なネットワーク アクセス制御: SAP 境界仮想ネットワークは、SAP 運用スポーク仮想ネットワークとの間のより厳格なネットワーク アクセス制御を提供します。
複雑さ、待ち時間、コストの増加: このアーキテクチャにより、管理の複雑さ、コスト、待ち時間が増加します。 SAP 運用仮想ネットワークからのインターネットバインド通信は、2 回ピアリングされます。1 回目はハブ仮想ネットワークに、2 回目は SAP 境界仮想ネットワークにピアリングされて、インターネットに送信されます。 ハブ仮想ネットワーク内のファイアウォールは、待ち時間に最も大きな影響を与えます。 待ち間を測定して、ユース ケースでサポートできるかどうかを確認することをお勧めします。
詳しくは、「境界ネットワークのベスト プラクティス」をご覧ください。
Azure NetApp Files サブネット
NetApp Files を使用している場合は、さまざまな SAP on Azure シナリオでネットワーク ファイル システム (NFS) またはサーバー メッセージ ブロック (SMB) ファイル共有を提供するために委任されたサブネットが必要です。 NetApp Files サブネットの既定のサイズは /24 サブネットですが、ニーズに合わせてサイズを変更できます。 独自の要件を使用して、適切なサイズ設定を決定します。 詳細については、「委任されたサブネット」を参照してください。
サブネットのセキュリティ
サブネットを使用して、同じセキュリティ規則要件を持つ SAP リソースをグループ化すると、セキュリティの管理が容易になります。
ネットワーク セキュリティ グループ (NSG): サブネットを使用すると、サブネット レベルでネットワーク セキュリティ グループを実装できます。 同じサブネット内の異なるセキュリティ規則を必要とするリソースをグループ化するには、サブネット レベルとネットワーク インターフェイス レベルのネットワーク セキュリティ グループが必要です。 この 2 レベルのセットアップでは、セキュリティ規則の競合が発生しやすく、トラブルシューティングが困難な予期しない通信の問題を引き起こす可能性があります。 NSG ルールは、サブネット内のトラフィックにも影響します。 NSG の詳細については、「ネットワーク セキュリティ グループ」を参照してください。
アプリケーション セキュリティ グループ (ASG): アプリケーション セキュリティ グループを使用して仮想マシンのネットワーク インターフェイスをグループ化し、ネットワーク セキュリティ グループ規則でアプリケーション セキュリティ グループを参照することをお勧めします。 この構成により、SAP デプロイの規則の作成と管理が容易になります。 各ネットワーク インターフェイスは、異なるネットワーク セキュリティ グループ規則を持つ複数のアプリケーション セキュリティ グループに属することができます。 詳細については、「アプリケーション セキュリティ グループ」を参照してください。
Azure Private Link
ネットワーク通信のセキュリティを向上させるために、Azure Private Link を使用することをお勧めします。 Azure Private Link では、プライベート IP アドレスを持つプライベート エンドポイントを使用して Azure サービスと通信します。 Azure Private Links を使用すると、インターネット経由でパブリック エンドポイントにネットワーク通信を送信することを回避できます。 詳細については、Azure サービスのプライベート エンドポイントに関するページを参照してください。
アプリケーション サブネットでプライベート エンドポイントを使用する: プライベート エンドポイントを使用して、サポートされている Azure サービスにアプリケーション サブネットを接続することをお勧めします。 このアーキテクチャでは、各仮想ネットワークのアプリケーション サブネットに Azure Files 用のプライベート エンドポイントがあります。 この概念は、サポートされている任意の Azure サービスに拡張できます。
SAP Business Technology Platform (BTP) 用に Azure Private Linkを使用する: SAP Business Technology Platform (BTP) 用の Azure Private Link が一般提供されました。 SAP Private Link Service では、SAP BTP、Cloud Foundry ランタイム、およびその他のサービスからの接続がサポートされています。 シナリオの例としては、仮想マシンで実行されている SAP S/4HANA や SAP ERP などがあります。 それらは、Azure Database for MariaDB や Azure Database for MySQL などの Azure ネイティブ サービスに接続できます。
このアーキテクチャは、SAP BTP 環境からの SAP Private Link サービス接続を示しています。 SAP Private Link Service は、サービス プロバイダー アカウントとして、各ネットワーク内の特定の SAP BTP サービスと特定のサービスとの間にプライベート接続を確立します。 プライベート リンクを使用すると、BTP サービスはプライベート ネットワーク接続を介して SAP 環境にアクセスできます。 パブリック インターネットを使用して通信しないので、セキュリティ強化されます。
詳細については、次を参照してください。
ネットワーク ファイル システム (NFS) とサーバー メッセージ ブロック (SMB) ファイル共有
SAP システムは、多くの場合、ネットワーク ファイル システム ボリュームまたはサーバー メッセージ ブロック共有に依存します。 これらのファイル共有は、仮想マシン間でファイルを移動するか、他のアプリケーションとのファイル インターフェイスとして機能します。 Azure Premium Files や Azure NetApp Files などのネイティブ Azure サービスをネットワーク ファイル システム (NFS) およびサーバー メッセージ ブロック (SMB) ファイル共有として使用することをお勧めします。 Azure サービスは、オペレーティング システムベースのツールよりも優れた可用性、回復性、サービス レベル保証 (SLA) の組み合わせを備えています。
詳細については、次を参照してください。
SAP ソリューションを設計するときは、個々のファイル共有ボリュームのサイズを適切に設定し、どの SAP システム ファイル共有に接続するかを把握する必要があります。 計画を作成するときには、Azure サービスのスケーラビリティとパフォーマンスの目標に留意してください。 次の表は、一般的な SAP ファイル共有の概要と、SAP 環境全体での簡単な説明と推奨される使用方法を示しています。
| ファイル共有名 | 使用法 | 推奨 |
|---|---|---|
sapmnt |
分散 SAP システム、プロファイル、およびグローバル ディレクトリ | 各 SAP システム専用の共有、再利用なし |
cluster |
それぞれの設計ごとの ASCS、ERS、およびデータベースの高可用性共有 | 各 SAP システム専用の共有、再利用なし |
saptrans |
SAP トランスポート ディレクトリ | 1 つまたは複数の SAP ランドスケープに対して 1 つの共有 (ERP、Business Warehouse) |
interface |
SAP 以外のアプリケーションとのファイル交換 | お客様固有の要件、環境ごとに個別のファイル共有 (運用環境、非運用環境) |
saptrans は、異なる SAP 環境間でのみを共有できるので、その配置を慎重に検討する必要があります。 スケーラビリティとパフォーマンス上の理由から、多すぎる SAP システムを 1 つの saptrans 共有に統合しないようにしてください。
企業のセキュリティ ポリシーによって、アーキテクチャが改善され、環境間のボリュームの分離が促進されます。 環境または層ごとに分離されたトランスポート ディレクトリは、SAP トランスポート グループまたはトランスポート ドメイン リンクを許可するために、SAP 環境間の RFC 通信が必要です。 詳細については、次を参照してください。
データ サービス
このアーキテクチャには、SAP データ プラットフォームの拡張と改善に役立つ Azure データ サービスが含まれています。 ビジネス分析情報を把握するために、Azure Synapse Analytics、Azure Data Factory、Azure Data Lake Storage などのサービスを使用することをお勧めします。 これらのデータ サービスは、SAP データおよび SAP 以外のデータの分析と視覚化に役立ちます。
多くのデータ統合シナリオでは、統合ランタイムが必要です。 Azure 統合ランタイム は、Azure Data FactoryおよびAzure Synapse Analytics パイプラインがデータ統合機能を提供するために使用するコンピューティング インフラストラクチャです。 これらのサービスのランタイム仮想マシンは、環境ごとに個別にデプロイすることをお勧めします。 詳細については、次を参照してください。
- Azure 統合ランタイム
- SAP CDC ソリューションで使用するセルフホステッド統合ランタイムを設定する
- SAP HANA からデータをコピーする
- オープン ハブを介して SAP Business Warehouse からデータをコピーする
共有サービス
SAP ソリューションは共有サービスに依存しています。 複数の SAP システムで使用されるサービスの例として、ロード バランサーとアプリケーション ゲートウェイがあります。 しかしこのアーキテクチャでは、組織のニーズに応じて、共有サービスを設計する方法を決定する必要があります。 従う必要がある一般的なガイダンスを次に示します。
ロード バランサー: SAP システムごとに 1 つのロード バランサーをお勧めします。 この構成は、複雑さを最小限に抑えるのに役立ちます。 1 つのロード バランサーのプールとルールが多くなりすぎないようにする必要があります。 この構成により、名前付けと配置が SAP システムおよびリソース グループと一致することも保証されます。 クラスター化された高可用性 (HA) アーキテクチャを採用した各 SAP システムには、少なくとも 1 つのロード バランサーが必要です。 このアーキテクチャでは、ASCS 仮想マシン用に 1 つのロード バランサーを使用し、データベース仮想マシン用に 2 つ目のロード バランサーを使用します。 一部のデータベースでは、高可用性デプロイを作成するためにロード バランサーが必要ない場合があります。 SAP HANA がそうです。 詳細については、データベース固有のドキュメントを参照してください。
アプリケーション ゲートウェイ: 接続されたシステムの複雑さと数が過剰にならない限り、SAP 環境 (運用、非運用、サンドボックス) ごとに少なくとも 1 つのアプリケーション ゲートウェイを使用することをお勧めします。 環境内のすべての SAP システムがパブリック アクセスを必要とするわけではないため、複数の SAP システム用にアプリケーション ゲートウェイを使用して複雑さを軽減できます。 1 つのアプリケーション ゲートウェイで、1 つの SAP S/4HANA システムに複数の Web ディスパッチャー ポートを提供することも、異なる複数の SAP システムで使用することもできます。
SAP Web Dispatcher 仮想マシン: このアーキテクチャは、2 つ以上の SAP Web Dispatcher VM のプールを示しています。 異なる SAP システム間で SAP Web Dispatcher 仮想マシンを再利用しないことをお勧めします。 これらを個別に保持することで、各 SAP システムのニーズを満たすように Web Dispatcher 仮想マシンのサイズを設定できます。 小規模な SAP ソリューションの場合は、ASCS インスタンスに Web Dispatcher サービスを埋め込むことをおすすめします。
SAP サービス: SAProuter、Cloud Connector、Analytics Cloud Agent などの SAP サービスは、アプリケーションの要件に基づいて一元的にデプロイされるか、分割してデプロイされます。 お客様の要件は多様であるため、SAP システム間の再利用に関する推奨事項はありません。 非運用環境用の SAP 境界サブネットをどのような場合に使用する必要があるかに関する主な決定事項については、ネットワーク に関するセクションで説明します。 それ以外の場合は、SAP の運用環境境界サブネットだけを使用し、SAP 境界サービスは SAP ランドスケープ全体で使用されます。
障害復旧
ディザスター リカバリー (DR) は、プライマリ Azure リージョンが利用できない場合や侵害された場合のビジネス継続性の要件に対応します。 全体的な SAP ランドスケープの観点から、図に示すようなディザスター リカバリー設計に関する推奨事項を次に示します。
異なる IP アドレス範囲を使用する: 仮想ネットワークは、単一の Azure リージョンだけをカバーしています。 ディザスター リカバリー ソリューションでは、別のリージョンを使用する必要があります。 セカンダリ リージョンに別の仮想ネットワークを作成する必要があります。 DR 環境の仮想ネットワークには、データベース ネイティブ テクノロジによるデータベース同期を有効にするために、異なる IP アドレス範囲が必要です。
中央サービスとオンプレミスへの接続: ディザスター リカバリー リージョンでは、オンプレミスおよび主要な中央サービス (DNS またはファイアウォール) への接続を使用できる必要があります。 中央 IT サービスの可用性と変更の構成は、ディザスター リカバリー計画に含まれている必要があります。 中央 IT サービスは、機能している SAP 環境の主要なコンポーネントです。
Azure Site Recovery の使用: Azure Site Recovery は、アプリケーション サーバーのマネージド ディスクと仮想マシンの構成を DR リージョンにレプリケートして保護します。
ファイル共有の可用性を確保する: SAP は、主要なファイル共有の可用性に依存します。 DR シナリオで、データ損失を最小限に抑えながらこれらのファイル共有上のデータを提供するには、バックアップまたは継続的なファイル共有レプリケーションが必要です。
データベース レプリケーション: Azure Site Recovery では、変更率が高く、サービスによるデータベース サポートがないため、SAP データベース サーバーを保護できません。 ディザスター リカバリー リージョンへの継続的な非同期データベース レプリケーションを構成する必要があります。
詳細については、「SAP ワークロードのディザスター リカバリーの概要とインフラストラクチャ のガイドライン」を参照してください。
小規模な SAP アーキテクチャ
小規模な SAP ソリューションの場合は、シンプルなネットワーク設計を行う方が有益な場合があります。 その後で、各 SAP 環境の仮想ネットワークは、結合された仮想ネットワーク内のサブネットになります。 ネットワークとサブスクリプションの設計ニーズを簡素化すると、セキュリティに影響する可能性があります。 ネットワーク ルーティング、パブリック ネットワークとの間のアクセス、共有サービス (ファイル共有) へのアクセス、他の Azure サービスへのアクセスを再評価する必要があります。 組織のニーズをより適切に満たすためにアーキテクチャを縮小するためのオプションをいくつか次に示します。
SAP アプリケーションとデータベース サブネットを 1 つに結合します。 アプリケーションとデータベース サブネットを組み合わせて、1 つの大きな SAP ネットワークを作成できます。 このネットワーク設計は、多くのオンプレミス SAP ネットワークをミラーリングします。 これら 2 つのサブネットの組み合わせでは、サブネットのセキュリティとネットワーク セキュリティ グループの規則に特に注意する必要があります。 アプリケーション セキュリティ グループは、SAP アプリケーションとデータベース サブネット用に 1 つのサブネットを使用する場合に重要です。
SAP 境界サブネットとアプリケーション サブネットを組み合わせます。 境界サブネットと SAP アプリケーション サブネットを組み合わせることができます。 ネットワーク セキュリティ グループの規則とアプリケーション セキュリティ グループの使用に特に注意する必要があります。 この簡素化アプローチは、小規模な SAP 資産にのみお勧めします。
異なる SAP 環境間で SAP スポーク仮想ネットワークを結合する: このアーキテクチャでは、SAP 環境 (ハブ、運用、非運用、ディザスター リカバリー) ごとに異なる仮想ネットワークが使用されます。 SAP ランドスケープのサイズに応じて、SAP スポーク仮想ネットワークを組み合わせて、より少ない数または 1 つだけの SAP スポークを構成することができます。 その場合でも、運用環境と非運用環境の間で分割する必要があります。 各 SAP 運用環境は、1 つの SAP 運用仮想ネットワーク内のサブネットになります。 各 SAP 非運用環境は、1 つの SAP 非運用仮想ネットワーク内のサブネットになります。
共同作成者
Microsoft では、この記事を保持しています。 当初の寄稿者は以下のとおりです。
プリンシパルの作成者:
- Robert Biro |シニア アーキテクト
- Pankaj Meshram | プリンシパル プログラム マネージャー