SAP RISE との接続
この記事では、SAP ランドスケープが RISE 内で運用され、個別の仮想ネットワークで実行されている場合の使用可能な接続オプションについて説明します。
SAP RISE/ECS による仮想ネットワーク ピアリング
仮想ネットワーク (vnet) ピアリングは、プライベート ネットワーク アドレス空間にある 2 つの仮想ネットワーク間で安全に接続するための最もパフォーマンスの高い方法です。 ピアリングされたネットワークは、接続のために 1 つのネットワークとして表示され、アプリケーションが互いに通信できるようにします。 異なる仮想ネットワーク、サブスクリプション、Azure テナント、またはリージョンで実行されているアプリケーションが直接通信できるようになります。 単一の仮想ネットワーク上のネットワーク トラフィックと同様に、ピアリング トラフィックはプライベート アドレス スペースに残り、インターネットを経由しません。
SAP RISE/ECS デプロイの場合、仮想ピアリングは、お客様の既存の Azure 環境との接続を確立するための推奨される方法です。 主な利点は以下のとおりです。
- SAP RISE ランドスケープと Azure で実行されている独自のアプリケーションとサービスの間のネットワーク待機時間を最小化し、スループットを最大化します。
- 既存の Azure ネットワーク ハブを使用せずに、SAP RISE 用の異なるオンプレミス通信パスを使用することで、複雑さとコストが追加されません。
仮想ネットワーク ピアリングは、SAP マネージド環境と同じリージョン内に設定できるだけでなく、任意の 2 つの Azure リージョン間のグローバル仮想ネットワーク ピアリングを使用して設定できます。 SAP RISE/ECS は多くの Azure リージョンで使用できるため、待ち時間とピアリングのコストを考慮し、リージョンでは顧客の仮想ネットワークで実行されているものと同じワークロードが必要です。 ただし、一部のシナリオ (たとえば、グローバルに展開している会社の中央 S/4HANA デプロイ) では、ネットワークをグローバルにピアリングする必要もあります。 このようなグローバルに分散された SAP ランドスケープの場合は、独自の Azure 環境内で複数リージョンのネットワーク アーキテクチャを使用し、SAP RISE が各地域でネットワーク ハブにローカルにピアリングするようにすることをお勧めします。
この図は、一般的な SAP 顧客のハブとスポークの仮想ネットワークを示しています。 テナント間仮想ネットワーク ピアリングは、SAP RISE と顧客のハブ仮想ネットワークを接続します。
SAP と顧客の仮想ネットワークの両方がネットワーク セキュリティ グループ (NSG) で保護され、SAP とデータベース の各ポートでピアリングを介した通信が可能になります。 ピアリングされた仮想ネットワーク間の通信は、これらの NSG を介してセキュリティで保護され、顧客の SAP 環境との間の通信が制限されます。
SAP RISE/ECS は、SAP の Azure テナントとサブスクリプションで実行されるので、異なるテナント間で仮想ネットワーク ピアリングを設定してください。 この構成は、SAP が提供するネットワークの Azure リソース ID を使用してピアリングを設定し、SAP にピアリングの承認を得ることで実現できます。 反対の Microsoft Entra テナントのユーザーをゲスト ユーザーとして追加し、ゲスト ユーザーの招待を受け入れ、仮想ネットワーク ピアリングの作成 - さまざまなサブスクリプションに関するページに記載されているプロセスに従います。 必要な正確な手順については、SAP 担当者にお問い合わせください。 ネットワーク、ユーザー管理、アーキテクチャを扱う組織内の各チームと関わり、このプロセスを迅速に完了します。
vnet 間 VPN
仮想ネットワーク ピアリングの代わりに、仮想プライベート ネットワーク (VPN) 接続を VPN ゲートウェイ間で確立し、SAP RISE/ECS サブスクリプションと顧客所有の両方にデプロイできます。 これら 2 つの VPN ゲートウェイ間に vnet 間接続を確立すると、2 つの異なる仮想ネットワーク間で高速通信が可能になります。 それぞれのネットワークとゲートウェイは、異なる Azure リージョンに存在できます。
この図は、一般的な SAP 顧客のハブとスポークの仮想ネットワークを示しています。 SAP RISE 仮想ネットワークにある VPN ゲートウェイは、vnet 間接続を介して、顧客のハブ仮想ネットワークに含まれるゲートウェイに接続します。
仮想ネットワーク ピアリングはより一般的で推奨されるデプロイ モデルですが、VNet 間 VPN は、顧客と SAP RISE/ECS の仮想ネットワーク間の複雑な仮想ピアリングを簡略化できる可能性があります。 この VPN Gateway は、顧客のネットワークへの入り口としてのみ機能し、中央チームによって管理およびセキュリティで保護されています。 ネットワーク スループットは、両側で選択したゲートウェイ SKU によって制限されます。 回復性の要件に対処するには、ゾーン冗長仮想ネットワーク ゲートウェイ がこのような接続に使用されていることを確認します。
ネットワーク セキュリティ グループは、顧客と SAP 仮想ネットワークの両方で有効であり、必要に応じて SAP NetWeaver および HANA ポートへの通信を可能にするピアリング アーキテクチャと同じです。 VPN 接続を設定する方法と使用する設定の詳細については、SAP 担当者にお問い合わせください。
オンプレミスへの接続
既存の顧客の Azure デプロイでは、オンプレミス ネットワークは既に ExpressRoute (ER) または VPN 経由で接続されています。 通常、SAP RISE/ECS で管理されるワークロードには、同じオンプレミス ネットワーク パスが使用されます。 推奨されるアーキテクチャは、この目的のために顧客の既存の ER/VPN ゲートウェイを使用し、接続された SAP RISE 仮想ネットワークを、顧客の仮想ネットワーク ハブに接続されたスポーク ネットワークと見なすことです。
この図は、一般的な SAP 顧客のハブとスポークの仮想ネットワークを示しています。 接続を使用してオンプレミスに接続します。 テナント間仮想ネットワーク ピアリングは、SAP RISE 仮想ネットワークを顧客のハブ ネットワークに接続します。 仮想ネットワーク ピアリングではリモート ゲートウェイ転送が有効になっているため、SAP RISE 仮想ネットワークにオンプレミスからアクセスできます。
このアーキテクチャでは、顧客のワークロードへのネットワーク接続を管理する中央ポリシーとセキュリティ規則も、SAP RISE/ECS で管理されるワークロードに適用されます。 顧客と SAP RISE/ECS の両方の仮想ネットワークに同じオンプレミス ネットワーク パスが使用されます。
現在、Azure からオンプレミスへの接続がない場合は、RISE のワークロードで可能な接続モデルの詳細について、SAP の担当者にお問い合わせください。 SAP RISE/ECS が RISE 内で直接オンプレミスを確立する場合、そのようなオンプレミス接続は SAP マネージド仮想ネットワークに到達するためにのみ使用できます。 SAP RISE 内のこのような専用 ExpressRoute または VPN 接続を使用して、顧客独自の Azure 仮想ネットワークにアクセスすることはできません。
Note
仮想ネットワークは、ローカルまたはリモートのゲートウェイを 1 つだけ持つことができます。 リモート ゲートウェイ転送を使用して SAP RISE 間で仮想ネットワーク ピアリングを確立すると、SAP RISE/ECS 仮想ネットワークにゲートウェイを追加できません。 リモート ゲートウェイ転送を使用した仮想ネットワーク ピアリングと、SAP RISE/ECS 仮想ネットワーク内の別の仮想ネットワーク ゲートウェイを組み合わせることはできません。
SAP RISE マネージド ワークロードを使用した Virtual WAN
SAP RISE/ECS 仮想ネットワークとオンプレミスの両方に接続されたハブ アンド スポーク ネットワーク アーキテクチャを使用する場合と同様に、Azure Virtual Wan (vWAN) ハブを同じ目的で使用できます。 RISE ワークロードは、vWAN ネットワーク ハブに接続されているスポーク ネットワークです。 前に説明した SAP RISE への接続オプション (仮想ネットワーク ピアリングと vnet 間 VPN) は、どちらも vWAN で利用できます。
vWAN ネットワーク ハブは、お客様によって独自のサブスクリプションでデプロイおよび管理されます。 また、お客様は、SAP RISE のピアリングされたスポーク仮想ネットワークへのアクセスにより、vWAN ネットワーク ハブを介したオンプレミス接続とルーティングを完全に管理します。
SAP RISE への移行中の接続
SAP ランドスケープの SAP RISE への移行は、数か月以上にわたる複数のフェーズで実施されます。 一部の SAP 環境は既に移行され、有効に使用されている一方で、移行の準備が行われている SAP システムもあります。 ほとんどの顧客プロジェクトでは、最大かつ最も重要なシステムは、プロジェクトの中盤または最後に移行されます。 データの移行またはデータベースのレプリケーションに十分な帯域幅があり、既に有効な RISE 環境に対するユーザーのネットワーク パスに影響しないようにする必要があります。 また、既に移行されている SAP システムが、まだオンプレミスまたは既存のサービス プロバイダーにある SAP ランドスケープと通信する必要がある場合もあります。
SAP RISE への移行の計画時には、各フェーズで SAP システムがユーザー ベースにどのように到達できるか、また RISE/ECS 仮想ネットワークへのデータ転送がどのようにルーティングされるかを計画してください。 既存のサービス プロバイダーや、企業ネットワークに対し独自の接続を持つデータ センターなど、しばしば複数の場所と関係者が関係します。 最もビジネス クリティカルなシステムの SAP データが後のフェーズで移行される方法について考慮せずに、VPN 接続を使用した一時的なソリューションを作成しないようにしてください。
SAP RISE/ECS マネージド ワークロードとの DNS 統合
顧客所有のネットワークとクラウドベースのインフラストラクチャの統合およびシームレスな名前解決の概念の提供は、プロジェクト実装の成功の重要な部分です。 この図は、SAP が所有するサブスクリプション、仮想ネットワーク、DNS インフラストラクチャと、顧客のローカル ネットワークおよび DNS サービスを統合する一般的なシナリオの 1 つを示しています。 このようなセットアップでは、Azure ハブまたはオンプレミスの DNS サーバーがすべての DNS エントリを保持しています。 DNS インフラストラクチャは、すべてのソース (オンプレミス クライアント、顧客の Azure サービス、SAP マネージド環境) からの DNS 要求を解決できます。
設計の説明と詳細:
SAP 所有の仮想ネットワークにおけるカスタム DNS 構成
RISE/PCE Azure 仮想ネットワーク ホスト DNS サーバー内の 2 つの VM
お客様は、SAP マネージド環境を実行する仮想マシンに、名前を割り当て、前方および逆引き DNS エントリを作成するために、サブドメイン/ゾーン (たとえば、example ecs.contoso.com など) を SAP に提供および委任する必要があります。 SAP DNS サーバーが委任されたゾーンのマスター DNS ロールを保持している
SAP DNS サーバーから顧客の DNS サーバーへの DNS ゾーン転送は、RISE/PCE 環境から DNS エントリをレプリケートする主な方法です。
顧客の Azure 仮想ネットワークでは、Azure ハブ仮想ネットワーク内にある顧客の DNS サーバーを参照するカスタム DNS 構成も使用しています。
必要に応じて、お客様は Azure 仮想ネットワーク内にプライベート DNS フォワーダーを設定できます。 その後、このフォワーダーは、Azure サービスから送信された DNS 要求を、委任されたゾーン (example ecs.contoso.com) を対象とする SAP DNS サーバーにプッシュします。
DNS ゾーン転送は、お客様がハブ仮想ネットワーク内でカスタム DNS ソリューション (たとえば、AD DS や BIND サーバーなど) を運用する場合の設計に適用できます。
Note
Azure で提供される DNS と Azure プライベート ゾーンは両方とも、DNS ゾーン転送機能に対応していないため、SAP RISE/PCE/ECS DNS サーバーからの DNS レプリケーションを受け入れるために使用できません。 さらに、SAP は通常、委任されたゾーンの外部 DNS サービス プロバイダーをサポートしていません。
SAP は、Azure で SAP RISE を使用した DNS 実装に関するブログ投稿を公開しました。詳細についてはこちらを参照してください。
SAP 用の Azure DNS の使用方法については、SAP RISE/ECS での使用状況以外の詳細については、次のブログ記事を参照してください。
SAP RISE/ECS を使用したインターネットの送信および受信接続
外部のアプリケーションやインターフェイスと通信する SAP ワークロードには、インターネットへのネットワーク エグレス パスが必要になる場合があります。 同様に、会社のユーザー ベース (SAP Fiori など) には、SAP ランドスケープへのインターネット イングレスまたは受信接続が必要です。 SAP RISE マネージド ワークロードについて、SAP の担当者と協力して、このような https/RFC/その他の通信パスのニーズを確認してください。 インターネットとの間のネットワーク通信は、SAP RISE/ECS の顧客に対して既定では有効になっておらず、既定のネットワークではプライベート IP 範囲のみが使用されます。 インターネット接続には、お客様の SAP ランドスケープを最適に保護するために、SAP を使用した計画が必要です。
SAP RISE とのインターネットに接続されたトラフィックまたは着信トラフィックを有効にした場合、ネットワーク通信は、NSG、ASG、Application Gateway with Web Application Firewall (WAF)、プロキシ サーバーなど、用途やネットワーク プロトコルに応じてさまざまな Azure テクノロジを通じて保護されます。 これらのサービスは、SAP RISE/ECS 仮想ネットワークとサブスクリプション内で SAP を通じて完全に管理されます。 インターネットとの間の SAP RISE のネットワーク パスは通常、SAP RISE/ECS 仮想ネットワーク内にのみ留まり、顧客独自の vnet との間で転送されることはありません。
顧客独自の仮想ネットワーク内のアプリケーションは、それぞれの仮想ネットワークから直接、または Azure Firewall、Azure Application Gateway、NAT Gateway などの集中管理された顧客のサービスを介してインターネットに接続します。 SAP RISE/ECS 以外のアプリケーションから SAP BTP への接続は、ユーザー側で同じネットワーク インターネット バインド パスを使用します。 このような統合に SAP Cloud Connecter が必要な場合は、顧客の VM 上で実行します。 つまり、SAP RISE ワークロードが関係していない場合、SAP BTP またはパブリック エンドポイント通信は、顧客自身が管理するネットワーク パス上にあります。
SAP BTP 接続
SAP Business Technology Platform (BTP) は、通常はパブリック IP/ホスト名によってインターネット経由でアクセスされる多くのアプリケーションを提供します。 Azure サブスクリプションで実行されている顧客のサービスは、中央のファイアウォールや送信パブリック IP など、構成された 送信アクセス方法を介して BTP にアクセスします。 ただし、SAP Data Intelligence など、いくつかの SAP BTP サービスは、パブリック エンドポイントではなく、個別の仮想ネットワーク ピアリングを介してアクセスされるように設計されています。
SAP は、Azure 上で SAP BTP を使用するお客様向けの Private Link Service を提供しています。 SAP Private Link Service は、プライベート IP 範囲を介して SAP BTP サービスを顧客の Azure ネットワークに接続するため、インターネット経由ではなく、プライベート リンク サービスを介してプライベートにアクセスできます。 SAP RISE/ECS ワークロードでこのサービスを利用できるかどうかについては、SAP にお問い合わせください。
SAP のドキュメント、SAP BTP Private Link Service とプライベート接続方法のアーキテクチャに関する一連のブログ記事、SAP のブログ シリーズ「Getting Started with BTP Private Link Service for Azure」の DNS と証明書の処理をご覧ください。
SAP RISE を使用したネットワーク通信ポート
顧客の仮想ネットワークにアクセスできるすべての Azure サービスは、SAP RISE/ECS サブスクリプション内で実行されている SAP ランドスケープと使用可能なポートを介して通信できます。
SAP RISE/ECS システムのオープン ポートの図。 BAPI と IDoc は RFC 接続、OData と Rest/SOAP は https。 SAP HANA データベースへの直接接続には ODBC/JDBC。 すべての接続はプライベート仮想ネットワーク ピアリング経由。 潜在的なオプションとして https でパブリック IP を使用する Application Gateway、SAP を通じて管理される。
SAP RISE の SAP システムには、SAP によって構成され、ユーザーが使用できるように開かれたオープン ネットワーク ポートを介してアクセスできます。 https、RFC、JDBC/ODBC プロトコルは、プライベート ネットワーク アドレス範囲を通じて使用できます。 さらに、アプリケーションは、SAP RISE マネージド Azure アプリケーション ゲートウェイによって公開されている、一般に利用可能な IP 上の https 経由でアクセスできます。 アプリケーション ゲートウェイと NSG のオープン ポートの詳細と設定については、SAP にお問い合わせください。
また、「Azure サービスと SAP RISE の統合」のドキュメントを参照し、使用可能な接続を使用して Azure サービスで SAP ランドスケープを拡張する方法についてご確認ください。
次のステップ
次のドキュメントを参照してください。