次の方法で共有

SAP 移行のネットワーク トポロジと接続性

  • [アーティクル]

この記事は、ネットワーク トポロジと接続性に関する Azure ランディング ゾーンの設計領域で定義されている考慮事項と推奨事項に基づいています。 この記事のガイダンスは、Microsoft Azure と SAP デプロイの間や、その内部でのネットワークと接続性に関する主要な設計上の考慮事項とベスト プラクティスについて検証するのに役立ちます。 SAP はミッション クリティカルなプラットフォームであるため、設計は Azure ランディング ゾーンの設計領域に関するガイダンスにも従う必要があります。

IP アドレス指定を計画する。

Azure で IP アドレス指定を計画することは、次のことを保証するために重要です。

  • IP アドレス空間は、オンプレミスの場所と Azure リージョン間で重複しません。
  • 仮想ネットワークには、正しいアドレス空間が含まれています。
  • サブネット構成計画は事前に作成されます。

次のアーキテクチャの図は、Azure ランディング ゾーン アクセラレータでの SAP のネットワークに関する考慮事項を示しています。

Azure ランディング ゾーン アクセラレータ上の SAP におけるネットワークの考慮事項を示す図。

SAP 実装の設計に関する考慮事項:

サブネットを特定のサービスに 専用 に委任してから、それらのサービスのインスタンスをサブネット内に作成することができます。 Azure では、仮想ネットワークに委任された複数のサブネットを作成できますが、Azure NetApp Files の仮想ネットワークに配置できる委任されたサブネットは 1 つだけです。 Azure NetApp Files 用に委任されたサブネットを複数使用している場合、新しいボリュームを作成できません。

ユース ケース:

Azure NetApp Files を実装するには、委任されたサブネットが必要です。 このアプローチは、ファイル システムを共有する SAP デプロイでは一般的なアプローチです。 負荷分散中のアプリケーション ゲートウェイの場合、または負荷分散を行う SAP Web アプリケーション サーバーである SAP BusinessObjects Business Intelligence の場合のみ、委任されたサブネットが必要になります。

オンプレミスと Azure のリソースに対して DNS と名前解決を構成する

ドメイン ネーム システム (DNS) は、Azure ランディング ゾーン アーキテクチャの重要な部分です。 DNS への既存の投資を使用することを望む組織があります。 または、クラウドの導入を、内部 DNS インフラストラクチャを最新化し、Azure のネイティブ機能を使用する機会と考える組織もあります。

SAP 実装の設計に関する推奨事項:

移行中に仮想マシンの DNS または仮想名が変更されない場合、次の推奨事項を使用します。

ユース ケース:

  • バックグラウンド DNS と仮想名は、SAP ランドスケープで多くのシステム インターフェイスを接続します。顧客は、開発者が時間の経過と共に定義するインターフェイスを認識するだけである場合があります。 移行後に仮想名または DNS 名が変更されると、システム間で接続の問題が発生します。 わかりやすくするために、DNS エイリアスを保持することをお勧めします。

  • さまざまな DNS ゾーンを使用して、 サンドボックス、開発、運用前、および運用環境などの各環境を相互に区別します。 1 つの例外は、独自の仮想ネットワークを持つ SAP デプロイの場合です。 このシナリオでは、プライベート DNS ゾーンは必要ない場合があります。

Azure のネットワーク トポロジを定義する

エンタープライズ規模のランディング ゾーンでは、2 つのネットワーク トポロジをサポートします。 1 つのトポロジは、Azure Virtual WAN に基づいたものです。 もう 1 つは、ハブアンドスポークのアーキテクチャに基づいた従来の Azure ネットワーク トポロジです。 このセクションでは、推奨事項の両方のデプロイ モデルの SAP の構成と方法を説明します。

組織で次のことを計画している場合は、仮想 WAN に基づくネットワーク トポロジを使用します。

  • 複数の Azure リージョンにリソースをデプロイし、Azure とオンプレミス環境の両方にグローバルな場所から接続します。
  • ソフトウェアで定義された WAN デプロイを Azure と完全に統合します。
  • 1 つの Azure Virtual WAN ハブに接続されたすべての仮想ネットで最大 2,000 の仮想マシン ワークロードをデプロイすることを予定しています。

大規模な相互接続の要件を満たすために Virtual WAN を使用します。 Microsoft はこのサービスを管理しており、全体的なネットワークの複雑さを軽減し、組織のネットワークを最新化するのに役立ちます。

ハブとスポークのアーキテクチャに基づいた従来の Azure ネットワーク トポロジは、次のような組織で使用します。

  • 選択した Azure リージョンでのみリソースをデプロイする計画をしています。
  • グローバルに相互接続されたネットワークは不要です。
  • リージョンごとにいくつかのリモートまたはブランチの場所があり、30 未満のインターネット プロトコル セキュリティ (IPsec) トンネルが必要です。
  • Azure ネットワークを手動で構成するには、完全な制御と粒度が必要です。

SAP 実装の設計に関する推奨事項:

  • Azure リージョンとオンプレミスの場所にわたってグローバルなトランジット接続を必要とする、新しく大規模な、またはグローバルなネットワークで Azure をデプロイする際に Virtual WAN を使用します。 この方法では、Azure ネットワーク用に手動で推移的なルーティングを設定する必要はなく、SAP on Azure デプロイの標準に従うことができます。

  • パートナー NVA が使用されている場合にのみ、リージョン間にネットワーク仮想アプライアンス (NVA) をデプロイすることを検討してください。 ネイティブの NVA が存在する場合、リージョン間または仮想ネットワーク間の NVA は必要ありません。 パートナーのネットワーク テクノロジと NVA をデプロイするときは、ベンダーのガイダンスに従って、Azure ネットワークと競合する構成を特定します。

  • Virtual WAN は、Virtual WAN ベースのトポロジのスポーク仮想ネットワーク間の接続を管理するため、ユーザー定義ルート (UDR) や NVA を設定する必要はありません。 同じ仮想ハブ内のネットワーク間トラフィックの最大ネットワーク スループットは 50 Gbps です。 この帯域幅制限を克服するには、SAP ランディング ゾーンで仮想ネットワーク ピアリングを使用して他のランディング ゾーンに接続します。

  • どちらのトポロジも、SAP アプリケーションとデータベース サーバー間の NVA デプロイをサポートしません。

  • ローカル仮想ネットワークとグローバル 仮想ネットワークのピアリングにより接続が得られ、これは、複数の Azure リージョンにまたがる SAP デプロイのためのランディング ゾーン間の接続を確保するために推奨されるアプローチです。

受信と送信のインターネット接続を計画する

このセクションでは、パブリック インターネットに対する受信接続と送信接続に対して推奨される接続モデルについて説明します。 Azure Firewall、 Azure Application Gateway 上の Azure Web Application Firewall (WAF)、Azure Front Door などの Azure ネイティブのネットワーク セキュリティ サービスはフル マネージド サービスであるため、大規模な場合は複雑になりかねない、インフラストラクチャのデプロイに関連する運用コストと管理コストが発生することはありません。

SAP 実装の設計に関する推奨事項:

  • グローバルなフットプリントを使用しているお客様の場合、Azure Front Door は、Azure Web Application Firewall ポリシーを使用して Azure リージョン全体でグローバルな HTTP と HTTPS アプリケーションを提供および保護することにより、SAP のデプロイを支援します。

  • このサービスと Application Gateway を使用して　HTTPS と HTTPS のアプリケーションを保護している場合は、Azure Front Door の Web アプリケーションファイアウォール ポリシーを活用してください。 Application Gateway へのトラフィックをブロックして、Azure Front Door からのトラフィックのみを受信するようにします。

  • Application Gateway と Web Application Firewall には、Application Gateway が SAP Web アプリのリバース プロキシとして機能する場合に制限があります。 SAP Web Dispatcher と NetScaler は Application Gateway よりもインテリジェントであるため、Application Gateway に置き換える場合は、広範なテストを行う必要があります。 可能であれば、最新の状態を確認し、サポートされている、サポートされていないまたはテストされていないシナリオをすべて一覧表示します。

  • Web アプリケーション ファイアウォールを使用して、インターネットに公開されたときのトラフィックをスキャンします。 別の方法として、ロードバランサー、または Application Gateway やサードパーティのソリューションなどの組み込みのファイアウォール機能を備えたリソースを使用することもできます。

  • データ漏えいを防ぐには、Azure Private Link を使用して、Azure Blob Storage、Azure Files、Azure Data Lake Storage Gen2、およびAzure Data Factory のサービス (PaaS) リソースとしてプラットフォームに安全にアクセスします。 プライベート エンドポイントは、仮想ネットワークと Azure Storage、Azure Backup などのサービス間のトラフィックをセキュリティで保護するのにも役立ちます。 仮想ネットワークとプライベート エンドポイントに対応したサービス間のトラフィックは、Microsoft グローバル ネットワークを経由して送信されるため、パブリック インターネット上に公開されることはありません。

高可用性を備えた Azure ExpressRoute の実装

Azure ExpressRoute は、Microsoft リソースへのキャリアグレード プライベート ネットワーク接続を提供する高可用性のために設計されています。 Microsoft ネットワーク内の ExpressRoute パスには単一障害点はありません。 可用性を最大化するには、ExpressRoute 回線の顧客およびサービス プロバイダー セグメントも高可用性のために構築する必要があります。

SAP 実装の設計に関する推奨事項:

ネットワーク暗号化の要件を定義する

このセクションでは、オンプレミスと Azure 環境の間、および Azure リージョン間でネットワークを暗号化するための主な推奨事項について説明します。

SAP 実装の設計に関する考慮事項:

  • ExpressRoute を使用してプライベート ピアリングを構成する際、トラフィックは規定で暗号化されていません。

  • SAP デプロイで ExpressRoute 経由のトラフィックを暗号化する必要はありません。 SAP トラフィックは、通常、大量の帯域幅を消費し、パフォーマンスに影響します。 IPSec トンネルは、既定でインターネット トラフィックを暗号化します。暗号化または復号化は、トラフィックのパフォーマンスに悪影響を及ぼす可能性があります。

  • SAP トラフィックを暗号化する必要があるかどうかは、お客様が決定します。 ネットワークトポロジと接続を探索して、エンタープライズ規模のランディング ゾーンでのネットワーク暗号化オプションを理解するには、「ネットワーク トポロジと接続性」を参照してください。

システムを分離する

SAP シナリオでは、開発、テスト、品質、実稼働前、運用環境を含むさまざまな環境が存在するため、これらのシステムは、セキュリティとコンプライアンスの標準に準拠するように論理/物理構造に分類される傾向があります。 狙いは、同じライフサイクルを持つすべてのシステムを 1 つの共通リソース グループで管理することです。 これらのグループは、サブスクリプションやリソースグループ レベルなど、さまざまなレベルで定義することができます。

また、SAP ランドスケープのリソースをグループ化するときに、セキュリティとポリシーの構造も考慮する必要があります。 ただし、開発、テスト、品質、運用環境の間で SAP トランスポートをフローさせるには、次のものが必要になることがあります。

  • 仮想ネットワーク ピアリング。
  • 仮想ネットワーク間のファイアウォール ポートの開放。
  • UDR とネットワーク セキュリティ グループ (NSG) のルール。

異なる仮想ネットワークで SAP システムのデータベース管理システム (DBMS) やアプリケーション レイヤーをホストし、仮想ネットワーク ピアリングによって接続することはお勧めしません。 レイヤー間の過剰なネットワーク トラフィックは、かなりのコストが発生する可能性があります。

SAP 実装に関する詳細な推奨事項:

  • どちらのトポロジでも、ピアリングされていない別々の Azure 仮想ネットワークに SAP アプリケーション レイヤーと SAP DBMS を配置することは、サポートされていません。

  • アプリケーション セキュリティ グループ (ASG) と NSG ルールを使用して、SAP アプリケーション層と DBMS 層の間にネットワーク セキュリティ アクセス制御リストを定義できます。 仮想マシンをASG に追加して、セキュリティの管理に役立てることができます。

  • SAP アプリケーションと DBMS レイヤーで使用する仮想マシンで Azure 高速ネットワークを有効にします。 次のオペレーティング システム レベルは Azure の高速ネットワークをサポートします。

    • Windows Server 2012 R2 以降
    • SUSE Linux Enterprise Desktop 12 SP3 以降
    • Red Hat Enterprise Linux 7.4 以降
    • Oracle Linux 7.5
      • Red Hat Enterprise Linux と互換性のあるカーネルには、Oracle Linux 7.5 リリース 3.10.0-862.13.1.el7 が必要です。
      • Oracle の分割されていないエンタープライズ カーネルには、リリース 5 が必要です。

  • Azure Load Balancer の内部デプロイが Direct Server Return を使用するように設定されていることを確認します。 DBMS レイヤーでの高可用性構成用に内部ロード バランサー構成 が使用されている場合、この機能により待機時間が短縮されます。

  • ロード バランサーを Linux ゲスト オペレーティング システムと共に使用している場合、Linux ネットワーク パラメーター net.ipv4.tcp_timestamps が 0 に設定されていることを確認します。

  • SAP アプリケーションで最適なネットワーク大気時間を実現するには、Azure 近接配置グループの使用を検討してください。

  • 移行プロジェクトでは、ネットワーク パラメーターのチューニングを検討してください。 たとえば、移行期間中に確認応答を無効にすることで、パフォーマンスを向上させることができます。

  • SAP の実装の詳細については、SAP サポートポータル と SAP Note 2391465 に関するページを参照してください。

RISE 実装の設計に関する考慮事項

Azure で SAP RISE デプロイを実行する場合は、SAP マネージド環境と独自の Azure エコシステムの統合が最も重要です。 ベスト プラクティスとガイダンスの詳細については、「Azure と SAP RISE マネージド ワークロードの統合」を参照してください。

SAP RISE の実装には通常、サイト間 VPN または仮想ネットワーク ピアリングという 2 つの接続オプションがあります。 これまでに Azure ワークロードを何も使用していない場合は、サイト間 VPN がより簡単なオプションになる場合があります。 ただし、戦略的プラットフォームとして Azure を採用したい場合は、適切な Azure ランディング ゾーンを設定し、SAP RISE テナントへの仮想ネットワーク ピアリングを使用できます。 このようなシナリオでは、Azure ランディング ゾーンのような単純化されたランディング ゾーンが良い選択肢となる可能性があります。 この既製のデプロイ エクスペリエンスは、要件 、特に仮想ネットワーク パラメーターに簡単に適応できます。

クロステナント仮想ネットワーク ピアリングを SAP RISE テナントにデプロイする場合も、さらに多くの作業が必要となります。 クラスレス インタードメイン ルーティング範囲が重複しないように、仮想ネットワーク アーキテクチャを慎重に計画する必要があります。 また、DNS を SAP RISE テナントに適切にピアリングする必要があります。

Virtual WAN ソリューションをセットアップすることを決定し、サイト間 VPN または ExpressRoute 接続が必要な場合は、限界と制限を考慮してください。