Connectivité avec SAP RISE

Avec votre paysage SAP géré dans RISE et exécuté dans un réseau virtuel distinct, dans cet article, nous fournissons des options de connectivité disponibles.

Peering de réseaux virtuels avec SAP RISE/ECS

Un peering de réseau virtuel (vnet) est le moyen le plus performant de se connecter en toute sécurité entre deux réseaux virtuels, dans un espace d’adressage de réseau privé. Les réseaux homologués s’affichent comme un seul point à des fins de connectivité, ce qui permet aux applications de communiquer entre elles. Les applications s’exécutant dans différents réseaux virtuels, abonnements, locataires Azure ou régions peuvent communiquer directement. Comme le trafic réseau sur un seul réseau virtuel, le trafic de peering reste dans un espace d’adressage privé et ne traverse pas Internet.

Pour les déploiements SAP RISE/ECS, le Peering virtuel est la méthode recommandée pour établir la connectivité avec l’environnement Azure existant du client. Les principaux avantages sont les suivants :

• Latence réseau réduite et débit maximal entre le paysage SAP RISE et les propres applications et services exécutés dans Azure.
• Aucune complexité et coût supplémentaires avec différents chemins de communication locaux pour SAP RISE, au lieu d’utiliser des hubs réseau Azure existants.

Le Peering de réseaux virtuels peut être configuré dans la même région que votre environnement managé SAP, mais également via lePeering de réseaux virtuels globaux entre deux régions Azure. Avec SAP RISE/ECS disponible dans de nombreuses régions Azure, la région doit correspondre à la charge de travail exécutée dans les réseaux virtuels clients en raison de la latence et des considérations relatives aux coûts de peering. Toutefois, certains scénarios (par exemple, le déploiement S/4HANA central pour une entreprise mondiale) nécessitent également d’homologuer des réseaux globalement. Pour ce paysage SAP distribué à l’échelle mondiale, nous vous recommandons d’utiliser l’architecture réseau multirégion au sein de votre propre environnement Azure, avec le peering SAP RISE localement dans chaque zone géographique de vos hubs réseau.

Ce diagramme montre les réseaux virtuels hub et spoke d’un client SAP standard. Le peering de réseaux virtuels entre locataires connecte SAP RISE et les réseaux virtuels hub du client.

Les réseaux virtuels SAP et client sont protégés par des groupes de sécurité réseau (NSG), ce qui autorise la communication sur les ports SAP et de base de données via le peering. La communication entre les réseaux virtuels appairés est sécurisée via ces groupes de sécurité réseau, ce qui limite la communication vers et depuis l’environnement SAP du client.

Étant donné que SAP RISE/ECS s’exécute dans les abonnements et le locataire Azure de SAP, configurez le peering de réseaux virtuels entre différents locataires. Vous effectuez cette configuration en configurant le peering avec l’ID de ressource Azure du réseau fourni par SAP et en autorisant SAP à approuver le peering. Ajoutez un utilisateur à partir du locataire Microsoft Entra opposé en tant qu’utilisateur invité, acceptez l’invitation de l’utilisateur invité et suivez le processus documenté à Créer un peering de réseaux virtuels - différents abonnements. Contactez votre représentant SAP pour connaître la procédure exacte requise. Encouragez la ou les équipes de votre organisation qui gèrent le réseau, l’administration des utilisateurs et l’architecture pour permettre l’exécution rapide de ce processus.

Réseau virtuel VPN à réseau virtuel

En guise d’alternative au peering de réseaux virtuels, la connexion de réseau privé virtuel (VPN) peut être établie entre les passerelles VPN, déployées à la fois dans l’abonnement SAP RISE/ECS et les clients. Vous pouvez établir une connexion de réseau virtuel à réseau virtuel entre ces deux passerelles VPN, ce qui permet une communication rapide entre les deux réseaux virtuels distincts. Les réseaux et passerelles respectifs peuvent résider dans différentes régions Azure.

Ce diagramme montre les réseaux virtuels hub et spoke d’un client SAP standard. La passerelle VPN située dans le réseau virtuel SAP RISE se connecte via une connexion de réseau virtuel à réseau virtuel dans la passerelle contenue dans le réseau virtuel hub du client.

Bien que le peering de réseaux virtuels soit le modèle de déploiement recommandé et plus classique, un réseau virtuel VPN à réseau virtuel peut potentiellement simplifier un peering virtuel complexe entre les réseaux virtuels SAP RISE/ECS et le client. La passerelle VPN fait office de point d’entrée unique sur le réseau du client et est gérée et sécurisée par une équipe centrale. Le débit réseau est limité par la référence SKU de passerelle choisie des deux côtés. Pour répondre aux exigences de résilience, assurez-vous que les passerelles de réseau virtuel redondantes interzone sont utilisées pour cette connexion.

Les groupes de sécurité réseau sont en vigueur sur les réseaux virtuels client et SAP, identiques à l’architecture de peering, ce qui permet la communication avec les ports SAP NetWeaver et HANA en fonction des besoins. Pour plus d’informations sur la configuration de la connexion VPN et sur les paramètres à utiliser, contactez votre représentant SAP.

Retour à la connectivité locale

Avec un déploiement Azure client existant, le réseau local est déjà connecté via ExpressRoute (ER) ou VPN. Le même chemin d’accès réseau local est généralement utilisé pour les charges de travail managées par SAP RICE/ECS. L’architecture préférée consiste à utiliser des passerelles ER/VPN existantes dans les clients à cet effet, avec un réseau virtuel SAP RISE connecté comme un réseau spoke connecté au hub de réseau virtuel du client.

Ce diagramme montre les réseaux virtuels hub et spoke d’un client SAP standard. Se connecte à l’environnement local avec une connexion. Le peering de réseaux virtuels entre locataires connecte le réseau virtuel SAP RISE au réseau hub du client. Le peering de réseaux virtuels a un transit de passerelle distant activé, ce qui permet au réseau virtuel SAP RISE d’être accessible à partir d’un emplacement local.

Avec cette architecture, les stratégies centrales et les règles de sécurité qui régissent la connectivité réseau aux charges de travail client s’appliquent également aux charges de travail managées SAP RISE/ECS. Le même chemin de réseau local est utilisé pour le réseau virtuel SAP RISE/ECS du client.

S’il n’existe actuellement aucune connectivité Azure locale, contactez votre représentant SAP pour plus d’informations sur les modèles de connexions possibles pour la charge de travail RISE. Si SAP RISE/ECS établit localement dans RISE directement, cette connexion locale est disponible pour atteindre le réseau virtuel managé SAP uniquement. Cette connexion ExpressRoute ou VPN dédiée au sein de SAP RISE ne peut pas être utilisée pour accéder aux propres réseaux virtuels Azure du client.

Remarque

Un réseau virtuel ne peut avoir qu’une seule passerelle, locale ou distante. Avec le peering de réseaux virtuels établi entre SAP RISE à l’aide du transit de passerelle distante, aucune passerelle ne peut être ajoutée dans le réseau virtuel SAP RISE/ECS. Une combinaison de peering de réseaux virtuels avec le transit de passerelle distante avec une autre passerelle de réseau virtuel dans le réseau virtuel SAP RISE/ECS n’est pas possible.

Virtual WAN avec des charges de travail managées SAP RISE

De même que l’utilisation d’une architecture réseau hub-and-spoke avec une connectivité au réseau virtuel SAP RISE/ECS et au hub local, Azure Virtual Wan (vWAN) peut être utilisé à des fins identiques. La charge de travail RISE est un réseau spoke connecté au hub de réseau vWAN. Les deux options de connexion à SAP RISE décrites précédemment, le peering de réseaux virtuels ainsi que le réseau virtuel vpn à réseau virtuel, sont disponibles avec vWAN.

Le hub réseau vWAN est déployé et géré par le client dans son propre abonnement. Le client gère également entièrement la connexion locale et le routage via le hub de réseau vWAN, avec accès au réseau virtuel spoke appairé SAP RISE.

Connectivité pendant la migration vers ECS/RISE

La migration de votre paysage SAP vers SAP RISE est effectuée en plusieurs phases sur plusieurs mois ou plus. Certains de vos environnements SAP sont déjà migrés et en cours d’utilisation, tandis que vous préparez d’autres systèmes SAP pour la migration. Dans la plupart des projets clients, les systèmes les plus importants et les plus critiques sont migrés au milieu ou à la fin du projet. Vous devez envisager d’avoir suffisamment de bande passante pour la migration de données ou la réplication de base de données, et n’a pas d’impact sur le chemin réseau de vos utilisateurs vers les environnements RISE déjà productifs. Les systèmes SAP déjà migrés peuvent également avoir besoin de communiquer avec le paysage SAP encore local ou qui se trouve chez un fournisseur de services existant.

Pendant votre planification de migration vers SAP RISE, planifiez la façon dont les systèmes SAP de chaque phase sont accessibles pour votre base d’utilisateurs et la façon dont le transfert de données vers le réseau virtuel RISE/ECS est routé. Souvent, plusieurs emplacements et parties sont impliqués, tels que le fournisseur de services et les centres de données existants avec une connexion propre à votre réseau d’entreprise. Assurez-vous qu’aucune solution temporaire avec des connexions VPN n’est créée sans tenir compte de la façon dont les données SAP de phases ultérieures sont migrées pour les systèmes les plus critiques pour l’entreprise.

Intégration de DNS avec les charges de travail managées SAP-RISE/ECS

L’intégration des réseaux clients à l’infrastructure cloud et la fourniture d’un concept de résolution de noms fluide constitue une partie essentielle d’une implémentation réussie du projet. Ce diagramme décrit l’un des scénarios d’intégration courants des abonnements SAP, des réseaux virtuels et de l’infrastructure DNS avec le réseau local et les services DNS du client. Dans ce type de configuration, Azure Hub ou les serveurs DNS locaux détiennent toutes les entrées DNS. L’infrastructure DNS est capable de résoudre les requêtes DNS provenant de toutes les sources (clients locaux, services Azure du client et environnements managés SAP).

Description et caractéristiques de conception :

• Configuration DNS personnalisée pour les réseaux virtuels appartenant à SAP

• Deux machines virtuelles à l’intérieur des serveurs DNS hôtes de réseau virtuel RISE/PCE Azure

• Les clients doivent fournir et déléguer à SAP un sous-domaine/zone (par exemple, ecs.contoso.com) pour attribuer des noms et créer des entrées DNS directes et inversées pour les machines virtuelles qui exécutent l’environnement managé SAP. Les serveurs DNS SAP détiennent un rôle DNS maître pour la zone déléguée

• Le transfert de zone DNS entre le serveur DNS SAP et les serveurs DNS du client est la méthode principale pour répliquer des entrées DNS à partir de l’environnement RISE/PCE.

• Les réseaux virtuels Azure du client utilisent également une configuration DNS personnalisée faisant référence aux serveurs DNS clients situés dans un réseau virtuel Azure Hub.

• Si vous le souhaitez, les clients peuvent configurer un redirecteur DNS privé au sein de leurs réseaux virtuels Azure. Ce redirecteur envoie ensuite des requêtes DNS provenant des services Azure vers des serveurs DNS SAP ciblés vers la zone déléguée (exemple ecs.contoso.com).

Le transfert de zone DNS s’applique aux conceptions lorsque les clients exploitent une solution DNS personnalisée (par exemple, des serveurs AD DS ou BIND) au sein de leur réseau virtuel hub.

Remarque

Les zones DNS fournies par Azure et les zones privées Azure ne prennent pas en charge la fonctionnalité de transfert de zone DNS, par conséquent, ne peuvent pas être utilisées pour accepter la réplication DNS à partir de serveurs DNS SAP RISE/PCE/ECS. En outre, SAP ne prend généralement pas en charge les fournisseurs de services DNS externes pour la zone déléguée.

SAP a publié un billet de blog sur l’implémentation DNS avec SAP RISE dans Azure, consultez ici pour plus d’informations.

Pour en savoir plus sur l’utilisation de Azure DNS pour SAP, en dehors de l’utilisation de SAP RISE/ECS, consultez les détails dans le billet de blog suivant.

Connexions Internet entrantes et sortantes avec SAP RISE/ECS

Les charges de travail SAP qui communiquent avec des applications externes et des interfaces peuvent nécessiter un chemin de sortie réseau vers Internet. De même, la base d’utilisateurs de votre entreprise (par exemple, SAP Fiori) a besoin d’une entrée Internet ou de connexions entrantes au paysage SAP. Pour les charges de travail managées SAP RISE, collaborez avec votre représentant SAP pour explorer les besoins de ce type https/RFC/autres chemins de communication. La communication réseau vers/depuis Internet n’est pas activée par défaut pour les clients SAP RISE/ECS et la mise en réseau par défaut utilise uniquement des plages d’adresses IP privées. La connectivité Internet nécessite une planification avec SAP, afin de protéger de manière optimale le paysage SAP du client.

Si vous activez le trafic internet lié ou entrant avec SAP RISE, la communication réseau est protégée par le biais de diverses technologies Azure telles que les groupes de sécurité réseau, les groupes de sécurité réseau, Application Gateway avec le pare-feu d’applications web (WAF), les serveurs proxy et d’autres en fonction de l’utilisation et des protocoles réseau. Ces services sont entièrement gérés via SAP au sein du réseau virtuel SAP RISE/ECS et de l’abonnement. Le chemin d’accès au réseau SAP RISE vers et à partir d’Internet reste généralement au sein du réseau virtuel SAP RISE/ECS uniquement et ne transite pas vers/depuis les propres réseaux virtuels du client.

Les applications au sein d’un client se connectent à Internet directement à partir d’un réseau virtuel respectif ou via des services gérés de manière centralisée par le client, tels que pare-feu Azure, Azure Application Gateway, NAT Gateway et d’autres. La connectivité à SAP BTP à partir d’applications non SAP RISE/ECS prend le même chemin lié à Internet réseau de votre côté. Si un connecteur SAP Cloud doit être nécessaire pour cette intégration, exécutez-le sur des machines virtuelles du client. En d’autres termes, SAP BTP ou toute communication de point de terminaison public se trouve sur un chemin réseau géré par les clients eux-mêmes si la charge de travail SAP RISE n’est pas impliquée.

Connectivité SAP BTP

SAP Business Technology Platform (BTP) fournit une multitude d’applications généralement accessibles via l’adresse IP publique/le nom d’hôte via Internet. Les services du client s’exécutant dans leurs abonnements Azure accèdent à BTP via la méthode d’accès sortante configurée , comme le pare-feu central ou les adresses IP publiques sortantes. Certains services SAP BTP, tels que SAP Data Intelligence, sont toutefois accessibles via un peering de réseaux virtuels distincts au lieu d’un point de terminaison public.

SAP propose un service de liaison privée aux clients qui utilisent SAP BTP sur Azure. Le service Private Link SAP connecte les services SAP BTP par le biais d’une plage d’adresses IP privées sur le réseau Azure du client et par conséquent, accessible en privé par le biais d’un service de liaison privée et non via Internet. Contactez SAP pour connaître la disponibilité de ce service pour les charges de travail SAP RISE/ECS.

Consultez la documentation SAP et une série de billets de blog sur l’architecture du service Private Link SAP BTP et des méthodes de connectivité privées, traitant du DNS et des certificats dans la série de blogs SAP suivante Démarrage du service Private Link BTP pour Azure.

Ports de communication réseau avec SAP RISE

Tout service Azure disposant d’un accès au réseau virtuel client peut communiquer avec le paysage SAP exécuté dans l’abonnement SAP RISE/ECS via les ports disponibles.

Diagramme des ports ouverts sur un système SAP RISE/ECS. Connexions RFC pour BAPI et IDoc, HTTPS pour OData et Rest/SOAP. ODBC/JDBC pour les connexions de base de données directes à SAP HANA. Toutes les connexions via le peering de réseaux virtuels privés. Application Gateway avec une adresse IP publique pour https comme option potentielle, gérée via SAP.

Votre système SAP dans SAP RISE est accessible via les ports réseau ouverts, tels que configurés et ouverts par SAP pour votre utilisation. Les protocoles https, RFC et JDBC/ODBC peuvent être utilisés via des plages d’adresses réseau privées. En outre, les applications peuvent accéder par https à une IP publiquement disponible, exposée par la passerelle d'application Azure gérée par SAP RISE. Pour plus d’informations et les paramètres de la passerelle d’application et du groupe de sécurité réseau, contactez SAP.

Consultez d’autres documents Intégrer des services Azure à SAP RISE comment la connectivité disponible vous permet d’étendre votre paysage SAP avec les services Azure.

Étapes suivantes

Consultez la documentation :

• Intégration d’Azure à SAP RISE
• Intégrer des services Azure à SAP RISE
• Identité et sécurité dans Azure avec SAP RISE
• Peering de réseau virtuel
• Intégration DNS à SAP RISE dans la série d’environnements multiclouds - Azure | Blogs SAP