Topologie et connectivité du réseau pour une migration SAP

  • Article

Cet article s'appuie sur les considérations et recommandations définies dans le domaine de conception de la zone d'atterrissage Azure pour la topologie réseau et la connectivité. Les conseils fournis dans cet article couvrent les principales considérations de conception et les bonnes pratiques concernant la mise en réseau et la connectivité vers, depuis et au sein des déploiements Microsoft Azure et SAP. Étant donné que SAP est une plate-forme stratégique pour l'entreprise, votre conception doit également suivre les conseils concernant les domaines de conception de la zone d'atterrissage Azure.

Planifier l’adressage IP

Un plan pour l'adressage IP dans Azure est vital pour s'assurer que :

  • L'espace d'adressage IP ne chevauche pas les emplacements sur site et les régions Azure.
  • Le réseau virtuel contient l'espace d'adresse correct.
  • Les plans de configuration du sous-réseau se produisent à l'avance.

Le diagramme d'architecture suivant montre les considérations de mise en réseau dans SAP sur un accélérateur de zone d'atterrissage Azure :

A diagram of networking considerations in SAP on an Azure landing zone accelerator.

Considérations relatives à la conception de l’implémentation SAP :

Vous pouvez dédier et déléguer des sous-réseaux à certains services, puis créer des instances de ces services au sein de ces sous-réseaux. Bien qu'Azure vous aide à créer plusieurs sous-réseaux délégués dans un réseau virtuel, vous ne pouvez avoir qu'un seul sous-réseau délégué dans un réseau virtuel pour Azure NetApp Files. Si vous utilisez plus d'un sous-réseau délégué pour Azure NetApp Files, vous ne pourrez pas créer un nouveau volume.

Cas d’utilisation :

Vous avez besoin de sous-réseaux délégués pour mettre en œuvre Azure NetApp Files. Cette approche est populaire pour les déploiements SAP qui partagent des systèmes de fichiers. Vous avez besoin d'un sous-réseau délégué uniquement pour une passerelle d'application pendant l'équilibrage de charge ou pour SAP BusinessObjects Business Intelligence, qui est un serveur d'applications Web SAP d'équilibrage de charge.

Configurer le DNS et la résolution de noms pour les ressources locales et Azure

Le système de noms de domaine (DNS) est une partie critique de l'architecture de la zone d'atterrissage Azure. Certaines organisations peuvent préférer utiliser leurs investissements en DNS existants. D’autres peuvent considérer l’adoption du cloud comme une opportunité de moderniser leur infrastructure DNS interne et d’utiliser des fonctionnalités Azure natives.

Recommandations de conception pour l’implémentation SAP :

Consultez les recommandations de cas pratique suivantes lorsque le DNS d'une machine virtuelle ou le nom virtuel ne change pas pendant la migration.

Cas d’utilisation :

  • Le DNS en arrière-plan et les noms virtuels connectent de nombreuses interfaces système dans le paysage SAP, et les clients ne connaissent que les interfaces définies par les développeurs au fil du temps. Des problèmes de connexion surviennent entre les systèmes lorsque les noms virtuels ou DNS changent après les migrations. Pour simplifier, nous recommandons de conserver les alias DNS.

  • Utilisez différentes zones DNS pour distinguer chaque environnement les uns des autres, comme les environnements sandbox, de développement, de préproduction et de production. Une exception concerne les déploiements SAP qui ont leur propre réseau virtuel. Dans ce scénario, les zones DNS privées pourraient ne pas être nécessaires.

Définir une topologie de réseau Azure

Les zones d'atterrissage à l'échelle de l'entreprise prennent en charge deux topologies réseau. Une topologie est basée sur Azure Virtual WAN. L'autre est une topologie réseau traditionnelle basée sur une architecture hub-and-spoke. Cette section décrit les configurations et pratiques SAP recommandées pour les deux modèles de déploiement.

Utilisez une topologie de réseau basée sur Virtual WAN si votre organisation prévoit d’effectuer les opérations suivantes :

  • Déployez des ressources dans plusieurs régions Azure et connectez vos emplacements mondiaux à la fois à Azure et aux environnements locaux.
  • Intégrez entièrement les déploiements de réseaux étendus à définition logicielle avec Azure.
  • Déployez jusqu'à 2 000 charges de travail de machine virtuelle à travers tous les réseaux virtuels connectés à un hub Virtual WAN.

Les organisations utilisent Virtual WAN pour répondre aux besoins d’interconnexion à grande échelle. Microsoft gère ce service, ce qui aide à réduire la complexité globale du réseau et à moderniser le réseau de votre organisation.

Utilisez une topologie réseau Azure traditionnelle basée sur une architecture hub-and-spoke si votre organisation :

  • Prévoit de déployer des ressources dans les régions Azure sélectionnées uniquement.
  • N’a pas besoin d’un réseau interconnecté global.
  • A peu d'emplacements distants ou de succursales par région et a besoin de moins de 30 tunnels de sécurité Internet Protocol (IPSec).
  • Nécessite un contrôle total et une granularité pour configurer manuellement votre réseau Azure.

Recommandations de conception pour l’implémentation SAP :

  • Utilisez Virtual WAN pour les déploiements Azure dans les nouveaux réseaux de taille importante ou les réseaux internationaux dans lesquels vous avez besoin d'une connectivité de transit mondial à travers les régions Azure et les emplacements locaux. En adoptant cette approche, vous n'avez pas besoin de configurer manuellement le routage transitif pour la mise en réseau Azure, et vous pouvez suivre une norme pour les déploiements SAP sur Azure.

  • Envisagez de déployer des appareils virtuels de réseau (NVA) entre les régions uniquement si vous utilisez des NVA partenaires. Les NVA entre les régions ou les réseaux virtuels ne sont pas nécessaires si des NVA natifs sont présents. Lorsque vous déployez des technologies de mise en réseau partenaires et des NVA, suivez les conseils du fournisseur pour identifier les configurations conflictuelles avec la mise en réseau Azure.

  • Virtual WAN gère la connectivité entre les réseaux virtuels parlants pour les topologies basées sur Virtual WAN, vous n'avez donc pas besoin de configurer des itinéraires définis par l'utilisateur (UDR) ou des NVA. Le débit réseau maximal pour le trafic réseau à réseau dans le même hub virtuel est de 50 Gbps. Pour surmonter cette limitation de bande passante, les zones d'atterrissage SAP peuvent utiliser l'appariement de réseaux virtuels pour se connecter à d'autres zones d'atterrissage.

  • Ni la topologie ne prend en charge les déploiements NVA entre une application SAP et un serveur de base de données.

  • Le peering de réseaux virtuels locaux et internationaux fournit la connectivité et sont les approches privilégiées pour assurer la connectivité entre les zones d'atterrissage pour les déploiements SAP à travers plusieurs régions Azure.

Planifier la connectivité Internet entrante et sortante

Cette section décrit des modèles de connectivité recommandés pour la connectivité entrante et sortante à partir et en direction de l’Internet public. Les services de sécurité réseau natifs d'Azure tels que Azure Firewall, Azure Web Application Firewall sur Azure Application Gateway et Azure Front Door sont des services entièrement gérés, vous n'encourez donc pas les coûts opérationnels et de gestion associés aux déploiements d'infrastructure.

Recommandations de conception pour l’implémentation SAP :

  • Pour les clients ayant une empreinte internationale, Azure Front Door facilite les déploiements SAP en utilisant des politiques de pare-feu d'application Web pour livrer et protéger les applications HTTP et HTTPS mondiales à travers les régions Azure.

  • Profitez des politiques de pare-feu d'application Web dans Azure Front Door lorsque vous utilisez Azure Front Door et Application Gateway pour protéger les applications HTTP et HTTPS. Bloquez le trafic vers Application Gateway afin qu'il ne reçoive le trafic que d'Azure Front Door.

  • Application Gateway et Web Application Firewall ont des limitations lorsque Application Gateway sert de proxy inverse pour les applications Web SAP. Parce que le SAP Web Dispatcher et NetScaler sont plus intelligents que l'Application Gateway, il est nécessaire de réaliser des tests approfondis si vous envisagez de les remplacer par l'Application Gateway. Vérifiez le statut le plus récent et listez tous les scénarios pris en charge, non pris en charge, testés et non testés, si possible.

  • Utilisez un pare-feu d’applications web pour analyser votre trafic lorsqu’il est exposé à Internet. Une autre option consiste à l'utiliser avec votre équilibreur de charge ou avec des ressources, comme l'Application Gateway ou des solutions tierces, qui disposent de capacités de pare-feu intégrées.

  • Pour éviter la fuite de données, utilisez Azure Private Link pour accéder de manière sécurisée aux ressources Platform as a Service (PaaS) telles qu'Azure Blob Storage, Azure Files, Azure Data Lake Storage Gen2 et Azure Data Factory. Les points de terminaison privés peuvent également aider à sécuriser le trafic entre les réseaux virtuels et les services comme Azure Storage et Azure Backup. Le trafic entre votre réseau virtuel et le service activé par le point de terminaison privé voyage à travers le réseau mondial de Microsoft, ce qui empêche son exposition à l'internet public.

Implémentez Azure ExpressRoute avec une haute disponibilité

Azure ExpressRoute est conçu pour une haute disponibilité afin de fournir une connectivité de réseau privé de niveau opérateur aux ressources Microsoft. Il n'y a pas de point unique de défaillance dans le chemin ExpressRoute au sein du réseau Microsoft. Pour maximiser la disponibilité, la segment client et le segment fournisseur de services de votre circuit ExpressRoute doivent également être construits pour une haute disponibilité.

Recommandations de conception pour les implémentations SAP :

Définir des exigences de chiffrement de réseau

Cette section explore les recommandations clés pour le chiffrement des réseaux entre les environnements sur site et Azure et à travers les régions Azure.

Considérations relatives à la conception pour les implémentations SAP :

  • Le trafic n'est pas chiffré par défaut lorsque vous utilisez ExpressRoute pour configurer un peering privé.

  • Vous n'avez pas besoin de chiffrer le trafic sur ExpressRoute pour les déploiements SAP. Le trafic SAP consomme généralement beaucoup de bande passante et est sensible aux performances. Les tunnels IPSec chiffrent par défaut le trafic Internet, et le chiffrement ou déchiffrement pourrait affecter négativement la performance du trafic.

  • Le client détermine si le trafic SAP doit être chiffré. Pour en savoir plus sur les options de chiffrement réseau dans les zones d'atterrissage à l'échelle de l'entreprise, veuillez consulter la topologie réseau et la connectivité.

Séparer les systèmes

Il existe différents environnements, y compris les environnements de développement, de test, de qualité, de préproduction et de production, dans un scénario SAP, et les clients ont tendance à catégoriser ces systèmes en constructions logiques ou physiques pour maintenir les normes de sécurité et de conformité. L'idée est de gérer tous les systèmes ayant le même cycle de vie dans un groupe de ressources commun. Vous pouvez définir ces groupes à divers niveaux, comme au niveau de l'abonnement ou du groupe de ressources.

Votre organisation devrait également considérer la structure de sécurité et de politique lors du regroupement des ressources dans un paysage SAP. Cependant, pour que les transports SAP circulent entre les environnements de développement, de test, de qualité et de production, votre organisation pourrait avoir besoin :

  • Appairage de réseaux virtuels.
  • D'ouvertures de ports de pare-feu entre les réseaux virtuels.
  • De règles UDR et de groupe de sécurité réseau (NSG).

Nous ne recommandons pas d'héberger le système de gestion de base de données (DBMS) et les couches d'application des systèmes SAP dans différents réseaux virtuels et de les connecter en utilisant le peering de réseau virtuel. Un trafic réseau excessif entre les couches peut s'avérer très coûteux.

Recommandations supplémentaires pour les implémentations SAP :

  • Aucune topologie ne prend en charge le placement de la couche d'application SAP et du DBMS SAP dans différents réseaux virtuels Azure qui ne sont pas appariés.

  • Vous pouvez utiliser des règles de groupe de sécurité d’application (ASG) et de groupe de sécurité réseau (NSG) pour définir les listes de contrôle d’accès de sécurité réseau entre les couches Application SAP et SGBD SAP. Vous pouvez ajouter des machines virtuelles aux groupes de sécurité d'application (ASGs) pour aider à gérer leur sécurité.

  • Activez les performances réseau accélérées Azure sur les machines virtuelles que vous utilisez dans les couches d'application et de DBMS SAP. Les niveaux de système d'exploitation suivants prennent en charge les performances réseau accélérées dans Azure :

    • Windows Server 2012 R2 ou version ultérieure
    • SUSE Linux Enterprise Desktop 12 SP3 ou ultérieur.
    • Red Hat Enterprise Linux 7.4 ou version ultérieure
    • Oracle Linux 7.5
      • Le noyau compatible avec Red Hat Enterprise Linux nécessite la version 3.10.0-862.13.1.el7.
      • Le noyau Oracle Unbreakable Enterprise Kernel nécessite la version 5.

  • Assurez-vous de configurer les déploiements internes pour Azure Load Balancer afin d'utiliser la fonctionnalité de retour direct du serveur. Cette fonctionnalité réduit la latence lorsque vous utilisez des configurations d'équilibreur de charge interne pour des configurations haute disponibilité sur la couche DBMS.

  • Si vous utilisez Load Balancer avec des systèmes d'exploitation invités Linux, assurez-vous que le paramètre réseau Linux net.ipv4.tcp_timestamps est réglé sur 0.

  • Pour optimiser la latence du réseau avec les applications SAP, envisagez d’utiliser les groupes de placement de proximité Azure.

  • Pour les projets de migration, ajustez les paramètres réseau. Par exemple, vous pouvez améliorer les performances en désactivant les accusés de réception pendant la période de migration.

  • Explorez le portail de support SAP et la note SAP 2391465 pour en savoir plus sur l’implémentation de SAP.

Considérations de conception pour les implémentations RISE

Lorsque vous exécutez des déploiements SAP RISE dans Azure, l'intégration de l'environnement géré par SAP avec votre propre écosystème Azure est primordiale. Pour en savoir plus sur les bonnes pratiques et les consulter les recommandations, veuillez vous rendre dans la section Intégrer Azure avec les charges de travail gérées SAP RISE.

L'implémentation SAP RISE a généralement deux options, le VPN site à site ou le peering de réseau virtuel, pour la connectivité. Si vous n’avez pas de charges de travail Azure antérieures, il est possible que le VPN site à site soit l’option la plus simple. Toutefois, si vous envisagez d’adopter Azure comme plateforme stratégique, vous pouvez être intéressé par la configuration d’une zone d’atterrissage Azure appropriée et l’utilisation de l’appairage de réseaux virtuels pour le tenant (locataire) SAP RISE. Pour ces scénarios, une zone d'atterrissage simplifiée comme le la zone d'atterrissage de migration Cloud Adoption Framework pourrait être une bonne option. Vous pouvez facilement adapter ce modèle aux exigences du client, avec un focus spécifique sur les paramètres de réseau virtuel.

Déployer le peering de réseau virtuel inter-locataires vers le locataire SAP RISE nécessite également plus de travail. Vous devez planifier soigneusement l'architecture du réseau virtuel pour vous assurer qu'il n'y a pas de chevauchements de plages de routage inter-domaines sans classe (CIDR). Vous devez également correctement peer DNS au locataire SAP RISE.

Enfin, si vous décidez de mettre en place une solution Virtual WAN et que vous avez également besoin de connexions VPN site à site ou ExpressRoute, vous devriez prendre en compte les limites et limitations.