Modifier

Partager via

Architecture de paysage SAP

Machines virtuelles Azure
Réseau virtuel Azure
Azure Files
Azure Load Balancer

Cet article explique les bonnes pratiques pour l’architecture d’un paysage SAP entier dans Azure. Le paysage SAP comprend plusieurs systèmes SAP dans les environnements de hub, de production, de non-production et de reprise d’activité. Nous fournissons des recommandations portant essentiellement sur la conception du réseau et non pas sur des systèmes SAP spécifiques. L’objectif est de fournir nos recommandations pour l’architecture d’un paysage SAP sécurisé, à hautes performances et résilient.

Architecture

Diagramme montrant un exemple de paysage SAP global dans Azure.

Téléchargez un fichier Visio de l’architecture.

Workflow

  1. Réseau local : connexion ExpressRoute du réseau local aux régions Azure connectées.
  2. Hubs régionaux d’abonnement Azure : abonnement Azure contenant des services centraux pour l’ensemble de l’entreprise, et pas seulement pour SAP. L’abonnement hub fournit une connectivité par peering aux réseaux virtuels de branche contenant des charges de travail SAP.
  3. Réseau virtuel hub : un réseau virtuel de branche pour le hub central dans la région primaire ou la région A.
  4. Réseau virtuel de reprise d’activité du hub : un réseau virtuel de branche pour le hub central dans la région de reprise d’activité. Il reflète la conception du sous-réseau du réseau virtuel de production dans la région primaire.
  5. Abonnement Azure SAP hors production : un abonnement Azure pour toutes les charges de travail SAP hors production. Il inclut des environnements de préproduction, d’assurance qualité, de développement et de bac à sable.
  6. Réseaux virtuels de branche SAP hors production : réseaux virtuels distincts pour les charges de travail SAP hors production dans la région primaire. Chaque environnement SAP a son propre réseau virtuel et ses propres sous-réseaux.
  7. Abonnement Azure SAP de production : un abonnement Azure pour toutes les charges de travail SAP de production.
  8. Réseau virtuel de branche de production SAP : un réseau virtuel pour l’environnement de production SAP avec plusieurs sous-réseaux. Ce réseau virtuel se trouve dans la région primaire.
  9. Réseau virtuel de branche de reprise d’activité SAP de production : un réseau virtuel pour la production SAP dans la région de reprise d’activité secondaire. Il reflète la conception du sous-réseau du réseau virtuel de production dans la région primaire.
  10. Services Azure : un échantillon de services Azure que vous pouvez connecter au paysage SAP.
  11. SAP Business Technology Platform (BTP) : l’environnement SAP accède à SAP Business Technology Platform via Azure Private Link.

Abonnements Azure

Nous vous recommandons d’utiliser une conception réseau hub-and-spoke. Avec une conception hub-and-spoke, vous avez besoin d’au moins trois abonnements pour diviser vos environnements SAP. Vous devez disposer d’un abonnement pour (1) les réseaux virtuels du hub régional, (2) les réseaux virtuels hors production et (3) les réseaux virtuels de production. Les abonnements fournissent des limites de facturation, de stratégie et de sécurité. Il n’y a pas un nombre défini d’abonnements. Le nombre d’abonnements que vous utilisez dépend de vos besoins en matière de facturation, de stratégie et de sécurité. En général, vous voulez éviter d’utiliser un trop grand nombre d’abonnements. Un trop grand nombre d’abonnements peut ajouter une surcharge de gestion inutile et une complexité du réseau. Par exemple, vous n’avez pas besoin d’un abonnement pour chaque système SAP. Notre architecture utilise trois abonnements :

  • Hubs régionaux : un abonnement de hub virtuel Azure où se trouve le réseau virtuel hub pour les régions primaires et secondaires. Cet abonnement est pour tous les services centraux et pas seulement pour SAP.

  • SAP hors production : un abonnement Azure SAP hors production où se trouvent des systèmes hors production, y compris des systèmes de bac à sable, de développement, d’assurance qualité ou de préproduction.

  • SAP en production : un abonnement de production Azure SAP où nous avons configuré les systèmes de production et de reprise d’activité.

Pour plus d'informations, consultez les pages suivantes :

Conception du réseau

Une topologie hub-and-spoke est la conception réseau recommandée pour un paysage SAP. Dans cette topologie, le réseau virtuel hub de production agit comme point central de connectivité. Il se connecte au réseau local et aux différents réseaux virtuels de branche, et permet aux utilisateurs et aux applications d’accéder à la charge de travail SAP. Dans cette topologie hub-and-spoke, voici nos recommandations pour la conception du réseau SAP.

Utilisez ExpressRoute pour la connexion locale. Pour les charges de travail SAP, nous vous recommandons d’utiliser ExpressRoute pour connecter le réseau local au réseau virtuel hub et au réseau virtuel de reprise d’activité du hub. Vous pouvez utiliser une topologie Azure Virtual WAN si vous avez des emplacements à l’échelle mondiale. Envisagez de configurer un VPN de site à site (S2S) comme solution de secours d’Azure ExpressRoute ou pour les exigences de routage de tiers.

Pour plus d'informations, consultez les pages suivantes :

Utilisez un réseau virtuel par environnement. Nous recommandons d’utiliser un réseau virtuel par environnement (niveau de déploiement SAP). L’architecture utilise un réseau virtuel différent pour la production, le développement, l’assurance qualité et le bac à sable. Cette conception réseau est idéale pour les architectures dans les grandes entreprises.

Utilisez un pare-feu central. Tout le trafic réseau vers les réseaux virtuels de branche, y compris les connexions d’appel de fonction distant (RFC), doit passer par un pare-feu central dans le réseau virtuel hub. La communication réseau entre les réseaux virtuels de branche (communication de branche à branche) passe par le pare-feu de réseau virtuel hub dans le sous-réseau Pare-feu Azure du réseau virtuel hub. De même, la communication réseau entre les réseaux virtuels de branche et le réseau local passe également par le pare-feu du réseau virtuel hub. Nous avons utilisé le peering de réseaux virtuels pour connecter les différents réseaux virtuels de branche au réseau virtuel hub. Toutes les communications entre les réseaux virtuels rayons passent par le pare-feu du réseau virtuel hub. Vous pouvez aussi utiliser une appliance virtuelle réseau au lieu d’un pare-feu. Pour plus d’informations, consultez Appliances virtuelles réseau.

Le trafic réseau qui reste dans un réseau virtuel ne doit pas passer par un pare-feu. Par exemple, ne placez pas de pare-feu entre le sous-réseau d’application SAP et le sous-réseau de base de données SAP. Vous ne pouvez pas placer un pare-feu ou des appliances virtuelles réseau entre l’application SAP et la couche Système de gestion de base de données (SGBD) des systèmes SAP exécutant le noyau SAP.

Évitez le peering de réseaux virtuels de branche. Le peering de réseaux virtuels entre les réseaux virtuels de branche doit si possible être évité. Le peering de réseaux virtuels rayon à rayon permet à la communication rayon à rayon de contourner le pare-feu du réseau virtuel hub. Vous devez configurer le peering de réseaux virtuels rayon à rayon uniquement quand vous avez besoin d’une grande bande passante, par exemple, pour la réplication de base de données entre environnements SAP. Tout le reste du trafic réseau doit passer par le réseau virtuel hub et le pare-feu du hub. Pour plus d’informations, consultez Connexions Internet entrantes et sortantes pour SAP sur Azure.

Sous-réseaux

Conformément aux bonnes pratiques, divisez chaque environnement SAP (production, préproduction, développement, bac à sable) en sous-réseaux et utilisez des sous-réseaux pour regrouper les services associés. Voici nos recommandations pour diviser un paysage SAP en sous-réseaux.

Nombre de sous-réseaux

Le réseau virtuel de production de l’architecture a cinq sous-réseaux. Cette conception est idéale pour les solutions dans les grandes entreprises. Le nombre de sous-réseaux peut être inférieur ou supérieur. Le nombre de ressources dans le réseau virtuel doit déterminer le nombre de sous-réseaux dans le réseau virtuel.

Dimensionnement des sous-réseaux

Vérifiez que les sous-réseaux disposent d’un espace d’adressage réseau suffisant. Si vous utilisez des noms d’hôtes virtuels SAP, vous avez besoin d’un espace d’adressage supplémentaire dans vos sous-réseaux SAP. Souvent, chaque instance SAP nécessite 2 à 3 adresses IP et inclut une adresse IP pour le nom d’hôte de la machine virtuelle. D’autres services Azure peuvent nécessiter leur propre sous-réseau dédié quand ils sont déployés dans les réseaux virtuels de la charge de travail SAP.

Sous-réseau d’application

Le sous-réseau d’application contient des machines virtuelles exécutant des serveurs d’applications SAP, des services centraux SAP (ASCS), des services de réplication en file d’attente SAP (ERS) et des instances SAP Web Dispatcher. Le sous-réseau contient également un point de terminaison privé pour Azure Files. Dans le diagramme, nous avons regroupé les machines virtuelles par rôle. Nous vous recommandons d’utiliser des groupes de machines virtuelles identiques avec une orchestration flexible, des zones de disponibilité ou des groupes à haute disponibilité pour un déploiement résilient. Pour plus d’informations, consultez Étapes suivantes.

Sous-réseau de base de données

Le sous-réseau de base de données contient les machines virtuelles exécutant des bases de données. Dans le diagramme, une paire de machines virtuelles avec réplication synchrone représente toutes les machines virtuelles de base de données d’un environnement SAP.

Sous-réseaux de périmètre

Les sous-réseaux de périmètre sont accessibles sur Internet et incluent un sous-réseau de périmètre SAP et un sous-réseau Application Gateway. Voici nos recommandations pour la conception de ces deux sous-réseaux.

Sous-réseau de périmètre SAP : le sous-réseau de périmètre SAP est un réseau de périmètre qui contient des applications accessible sur Internet, comme SAProuter, SAP Cloud Connector, SAP Analytics Cloud Agent et Application Gateway. Ces services ont des dépendances vis-à-vis des systèmes SAP qu’une équipe SAP doit déployer, gérer et configurer. Une équipe informatique centrale ne doit pas gérer les services dans le sous-réseau de périmètre SAP. Pour cette raison, vous devez placer ces services dans le réseau virtuel de branche SAP et non pas dans le réseau virtuel hub. Le diagramme de l’architecture montre seulement un réseau de périmètre SAP de production. Il ne contient pas de sous-réseau de périmètre SAP dans les réseaux virtuels hors production. Les charges de travail de l’abonnement SAP hors production utilisent les services dans le sous-réseau de périmètre SAP.

Vous pouvez créer un sous-réseau de périmètre SAP distinct dans l’abonnement hors production. Nous recommandons cette approche seulement pour les charges de travail critiques ou les charges de travail qui changent fréquemment. Un périmètre SAP dédié hors production est utile pour le test et le déploiement de nouvelles fonctionnalités. Les applications moins critiques ou les applications qui ne subiront que peu de modifications au fil du temps n’ont pas besoin d’un sous-réseau de périmètre SAP hors production distinct.

Sous-réseau Application Gateway : Azure Application Gateway nécessite son propre sous-réseau. Utilisez-le pour autoriser le trafic depuis Internet que des services SAP comme SAP Fiori peuvent utiliser. L’architecture recommandée place Azure Application Gateway avec son adresse IP publique frontale dans le réseau virtuel Hub. Azure Application Gateway nécessite au moins un sous-réseau de taille /29. Nous vous recommandons d’utiliser un sous-réseau d’une taille /27 ou supérieure. Vous ne pouvez pas utiliser les deux versions d’Application Gateway (v1 et v2) dans le même sous-réseau. Pour plus d’informations, consultez Sous-réseau pour Azure Application Gateway.

Placez les sous-réseaux de périmètre dans un réseau virtuel distinct pour une sécurité accrue : pour plus de sécurité, vous pouvez placer le sous-réseau de périmètre SAP et le sous-réseau Application Gateway dans un réseau virtuel distinct au sein de l’abonnement de production SAP. Le réseau virtuel de branche de périmètre SAP est appairé avec le réseau virtuel hub, et tout le trafic réseau vers les réseaux publics transite par le réseau virtuel de périmètre. Cette autre approche montre Azure Application Gateway avec son adresse IP publique pour les connexions entrantes placé dans un réseau virtuel spoke pour l’utilisation exclusive de SAP.

Diagramme montrant le flux réseau entre des branches de réseau virtuel via le réseau virtuel hub.

Téléchargez un fichier Visio comprenant cette autre architecture.

Cette conception réseau offre de meilleures fonctionnalités de réponse aux incidents et un contrôle précis de l’accès réseau. Cependant, cela augmente également la complexité de la gestion, la latence du réseau et le coût du déploiement. Voyons chacun de ces points.

Meilleure réponse aux incidents : le réseau virtuel de branche de périmètre SAP permet une isolation rapide des services compromis si vous détectez une violation. Vous pouvez supprimer l’appairage de réseaux virtuels du réseau virtuel de branche de périmètre SAP avec le hub, et isoler immédiatement d’Internet les charges de travail de périmètre SAP et les applications du réseau virtuel d’application SAP. Vous ne voulez pas dépendre des modifications des règles de groupe de sécurité réseau pour la réponse aux incidents. La modification ou la suppression d’une règle de groupe de sécurité réseau affecte seulement les nouvelles connexions et ne va pas mettre fin aux connexions malveillantes existantes.

Contrôle précis de l’accès réseau : le réseau virtuel de périmètre SAP fournit un contrôle plus strict de l’accès réseau vers et depuis le réseau virtuel de branche de production SAP.

Complexité, latence et coût accrus : l’architecture augmente la complexité de la gestion, le coût et la latence. Les communications liées à Internet provenant du réseau virtuel de production SAP sont appairées deux fois : une fois au réseau virtuel hub et à nouveau au réseau virtuel de périmètre SAP vers Internet. Le pare-feu du réseau virtuel hub a l’effet le plus important sur la latence. Nous recommandons de mesurer la latence pour voir si votre cas d’usage peut s’en accommoder.

Pour plus d’informations, consultez les bonnes pratiques pour les réseaux de périmètre.

Sous-réseau Azure NetApp Files

Si vous utilisez NetApp Files, vous devez avoir un sous-réseau délégué pour fournir des partages de fichiers NFS (Network File System) ou SMB (Server Message Block) pour différents scénarios SAP sur Azure. Un sous-réseau /24 est la taille par défaut d’un sous-réseau NetApp Files, mais vous pouvez changer la taille pour l’adapter à vos besoins. Utilisez vos propres spécifications pour déterminer le dimensionnement approprié. Pour plus d’informations, consultez Sous-réseau délégué.

Sécurité des sous-réseaux

L’utilisation de sous-réseaux pour regrouper des ressources SAP qui ont les mêmes exigences en matière de règles de sécurité facilite la gestion de la sécurité.

Groupes de sécurité réseau (NSG) : les sous-réseaux vous permettent d’implémenter des groupes de sécurité réseau au niveau du sous-réseau. Le regroupement de ressources dans le même sous-réseau qui nécessitent des règles de sécurité différentes nécessite des groupes de sécurité réseau au niveau du sous-réseau et de l’interface réseau. Avec cette configuration à deux niveaux, les règles de sécurité sont facilement en conflit et peuvent provoquer des problèmes de communication inattendus difficiles à résoudre. Les règles de groupe de sécurité réseau affectent également le trafic au sein du sous-réseau. Pour plus d’informations sur les groupes de sécurité réseau, consultez Groupes de sécurité réseau.

Groupes de sécurité d’application (ASG) : nous recommandons d’utiliser des groupes de sécurité d’application pour regrouper des interfaces réseau de machine virtuelle et de référencer les groupes de sécurité d’application dans les règles de groupe de sécurité réseau. Cette configuration facilite la création et la gestion des règles pour les déploiements SAP. Chaque interface réseau peut appartenir à plusieurs groupes de sécurité d’application avec des règles de groupe de sécurité réseau différentes. Pour plus d’informations, consultez Groupes de sécurité d’application.

Nous recommandons d’utiliser Azure Private Link pour améliorer la sécurité des communications réseau. Azure Private Link utilise des points de terminaison privés avec des adresses IP privées pour communiquer avec les services Azure. Azure Private Links évite d’envoyer des communications réseau sur Internet vers des points de terminaison publics. Pour plus d’informations, consultez Points de terminaison privés sur les services Azure.

Utiliser des points de terminaison privés dans le sous-réseau d’application : nous recommandons d’utiliser des points de terminaison privés pour connecter le sous-réseau d’application aux services Azure pris en charge. Dans l’architecture, il existe un point de terminaison privé pour Azure Files dans le sous-réseau d’application de chaque réseau virtuel. Vous pouvez étendre ce concept à n’importe quel service Azure pris en charge.

Utiliser Azure Private Link pour SAP Business Technology Platform (BTP) : Azure Private Link pour SAP Business Technology Platform (BTP) est désormais en disponibilité générale. SAP Private Link Service prend en charge les connexions depuis SAP BTP, le runtime Cloud Foundry et d’autres services. SAP S/4HANA ou SAP ERP s’exécutant sur la machine virtuelle sont des exemples de scénarios. Ils peuvent se connecter à des services natifs Azure comme Azure Database for MariaDB et Azure Database pour MySQL.

L’architecture illustre une connexion SAP Private Link Service depuis des environnements SAP BTP. SAP Private Link Service établit une connexion privée entre des services SAP BTP spécifiques et des services spécifiques dans chaque service en tant que comptes de fournisseur de services. La liaison privée permet aux services BTP d’accéder à votre environnement SAP via des connexions réseau privées. Elle améliore la sécurité en n’utilisant pas l’Internet public pour communiquer.

Pour plus d'informations, consultez les pages suivantes :

Partages de fichiers NFS (Network File System) et SMB (Server Message Block)

Les systèmes SAP dépendent souvent de volumes NFS ou de partages SMB. Ces partages de fichiers déplacent des fichiers entre des machines virtuelles ou fonctionnent comme une interface de fichiers avec d’autres applications. Nous recommandons d’utiliser des services Azure natifs tels qu’Azure Premium Files et Azure NetApp Files comme partages de fichiers NFS et SMB. Les services Azure offrent de meilleures combinaisons de disponibilité, de résilience et de contrat SLA que les outils basés sur le système d’exploitation.

Pour plus d'informations, consultez les pages suivantes :

Lors de la conception de l’architecture de votre solution SAP, vous devez dimensionner correctement les volumes de partage de fichiers individuels et savoir à quel partage de fichiers système SAP se connecte. Gardez à l’esprit les objectifs de scalabilité et de performances du service Azure pendant la planification. Le tableau suivant présente les partages de fichiers SAP courants, et fournit une brève description et l’utilisation recommandée dans un environnement SAP global.

Nom du partage de fichiers Usage Recommandation
sapmnt Systèmes, profils et annuaires mondiaux SAP distribués Partage dédié pour chaque système SAP, pas de réutilisation
cluster Partages à haute disponibilité pour ASCS, ERS et les bases de données, selon leur conception respective Partage dédié pour chaque système SAP, pas de réutilisation
saptrans Annuaire de transport SAP Un partage pour un ou plusieurs paysages SAP (ERP, Business Warehouse)
interface Échange de fichiers avec des applications non-SAP Exigences spécifiques au client, partages de fichiers distincts par environnement (production, hors production)

Vous pouvez partager saptrans seulement entre différents environnements SAP et par conséquent, vous devez réfléchir soigneusement à son emplacement. Pour des raisons de scalabilité et de performances, évitez de regrouper un trop grand nombre de systèmes SAP en un seul partage saptrans.

Les stratégies de sécurité d’entreprise vont déterminer l’architecture et la séparation des volumes entre les environnements. Un répertoire de transport avec une séparation par environnement ou par niveau a besoin d’une communication RFC entre les environnements SAP pour permettre les groupes de transport ou les liaisons de domaine de transport SAP. Pour plus d'informations, consultez les pages suivantes :

Services de données

L’architecture contient des services de données Azure qui vous aident à étendre et à améliorer votre plateforme de données SAP. Pour faciliter la découverte d’insights métier, nous recommandons d’utiliser des services comme Azure Synapse Analytics, Azure Data Factory et Azure Data Lake Storage. Ces services de données vous aident à analyser et à visualiser les données SAP et non-SAP.

Pour de nombreux scénarios d’intégration de données, un runtime d’intégration est nécessaire. Le runtime d’intégration Azure représente l’infrastructure de calcul utilisée par les pipelines Azure Data Factory et Azure Synapse Analytics pour fournir des capacités d’intégration de données. Nous recommandons de déployer les machines virtuelles du runtime pour ces services séparément pour chaque environnement. Pour plus d'informations, consultez les pages suivantes :

Services partagés

Les solutions SAP s’appuient sur des services partagés. L’équilibreur de charge et les passerelles d’application sont des exemples de services utilisés par plusieurs systèmes SAP. L’architecture mais aussi les besoins de votre organisation doivent déterminer la façon dont vous concevez vos services partagés. Voici des conseils généraux à suivre.

Équilibreurs de charge : nous recommandons un équilibreur de charge par système SAP. Cette configuration permet de réduire la complexité. Vous voulez éviter un trop grand nombre de pools et de règles sur un même équilibreur de charge. Cette configuration garantit également que le nommage et le placement s’alignent sur le système et le groupe de ressources SAP. Chaque système SAP avec une architecture de haute disponibilité en cluster doit avoir au moins un équilibreur de charge. L’architecture utilise un équilibreur de charge pour les machines virtuelles ASCS et un deuxième équilibreur de charge pour les machines virtuelles de base de données. Certaines bases de données peuvent ne pas nécessiter d’équilibreurs de charge pour créer un déploiement à haute disponibilité. SAP HANA nécessite ces équilibreurs de charge. Pour plus d’informations, consultez la documentation spécifique à la base de données.

Application Gateway : nous recommandons au moins une passerelle d’application par environnement SAP (production, hors production et bac à sable), sauf si la complexité et le nombre de systèmes connectés deviennent trop grands. Vous pouvez utiliser une passerelle d’application pour plusieurs systèmes SAP afin de réduire la complexité, car tous les systèmes SAP de l’environnement ne nécessitent pas un accès public. Une seule passerelle d’application peut servir plusieurs ports de répartiteur web pour un même système SAP S/4HANA ou être utilisée par différents systèmes SAP.

Machines virtuelles SAP Web Dispatcher : l’architecture montre un pool de deux machines virtuelles SAP Web Dispatcher ou plus. Nous vous recommandons de ne pas réutiliser les machines virtuelles SAP Web Dispatcher entre différents systèmes SAP. Le fait de les séparer vous permet de dimensionner les machines virtuelles Web Dispatcher pour répondre aux besoins de chaque système SAP. Pour les solutions SAP plus petites, nous vous recommandons d’incorporer les services Web Dispatcher dans l’instance ASCS.

Services SAP : les services SAP comme SAProuter, Cloud Connector et Analytics Cloud Agent, sont déployés en fonction des exigences des applications, de manière centralisée ou fractionnée. Pas de recommandation sur la réutilisation entre les systèmes SAP, en raison des exigences différentes selon les clients. La principale décision à prendre est mentionnée dans la section Mise en réseau, si et quand le sous-réseau de périmètre SAP pour la non-production doit être utilisé. Sinon, avec seulement un sous-réseau de périmètre de production pour SAP, les services de périmètre SAP sont consommés par l’ensemble du paysage SAP.

Récupération d'urgence

La reprise d’activité répond à la nécessité de continuité de l’activité si la région Azure primaire est indisponible ou compromise. Du point de vue du paysage SAP global illustré dans le diagramme, voici nos recommandations pour la conception de la reprise d’activité.

Utiliser différentes plages d’adresses IP : les réseaux virtuels s’étendent sur une seule région Azure. Les solutions de reprise d’activité doivent utiliser une autre région. Vous devez créer un autre réseau virtuel dans la région secondaire. Le réseau virtuel dans l’environnement de reprise d’activité a besoin d’une plage d’adresses IP différente pour activer la synchronisation de base de données via une technologie native de base de données.

Services centraux et connectivité à un environnement local : la connectivité aux services centraux locaux importants (DNS ou pare-feu) doit être disponible dans la région de reprise d’activité. La disponibilité et la configuration des modifications des services informatiques centraux doivent faire partie de votre plan de reprise d’activité. Les services informatiques centraux sont des composants importants pour un environnement SAP fonctionnel.

Utilisez Azure Site Recovery : Azure Site Recovery réplique et protège les disques managés et les configurations de machines virtuelles pour les serveurs d’applications dans la région de reprise d’activité.

Garantir la disponibilité des partages de fichiers : SAP dépend de la disponibilité des partages de fichiers clés. La sauvegarde ou la réplication continue des partages de fichiers est nécessaire pour fournir des données sur ces partages de fichiers avec une perte de données minimale dans les scénarios de reprise d’activité.

Réplication de base de données : Azure Site Recovery ne peut pas protéger les serveurs de base de données SAP en raison du taux de modification élevé et de l’absence de prise en charge des bases de données par le service. Vous devez configurer la réplication de base de données continue et asynchrone dans la région de reprise d’activité.

Pour plus d’informations, consultez Vue d’ensemble de la reprise d’activité et conseils sur l’infrastructure pour la charge de travail SAP.

Architecture SAP plus petite

Pour les solutions SAP plus petites, il peut être bénéfique de simplifier la conception du réseau. Le réseau virtuel de chaque environnement SAP serait alors un sous-réseau à l’intérieur de ce réseau virtuel combiné. Toute simplification des besoins en matière de conception du réseau et des abonnements peut affecter la sécurité. Vous devez réévaluer le routage réseau, l’accès vers et depuis les réseaux publics, l’accès aux services partagés (partages de fichiers) et l’accès aux autres services Azure. Voici quelques options pour réduire l’architecture afin de mieux répondre aux besoins de l’organisation.

Combiner les sous-réseaux d’application et de base de données SAP en un seul sous-réseau. Vous pouvez combiner les sous-réseaux d’application et de base de données pour créer un seul grand réseau SAP. Cette conception du réseau correspond à de nombreux réseaux SAP locaux. La combinaison de ces deux sous-réseaux nécessite une plus grande attention apportée à la sécurité du sous-réseau et aux règles de groupe de sécurité réseau. Les groupes de sécurité d’application sont importants lors de l’utilisation d’un seul sous-réseau pour les sous-réseaux d’application et de base de données SAP.

Combiner le sous-réseau de périmètre SAP et le sous-réseau d’application. Vous pouvez combiner le sous-réseau de périmètre et le sous-réseau d’application SAP. Une attention accrue doit être apportée aux règles de groupe de sécurité réseau et à l’utilisation des groupes de sécurité d’application. Nous recommandons cette approche de simplification seulement pour les petits environnements SAP.

Combiner des réseaux virtuels de branche SAP entre différents environnements SAP : l’architecture utilise différents réseaux virtuels pour chaque environnement SAP (hub, production, hors production et reprise d’activité). Selon la taille de votre paysage SAP, vous pouvez combiner les réseaux virtuels de branche SAP en moins de branches, voire en une seule. Vous devez néanmoins toujours séparer les environnements de production des environnements hors production. Chaque environnement de production SAP devient un sous-réseau dans un même réseau virtuel de production SAP. Chaque environnement hors production SAP devient un sous-réseau dans un même réseau virtuel hors production SAP.

Contributeurs

Microsoft gère cet article. Il a été écrit à l’origine par les contributeurs suivants.

Auteurs principaux :

Étapes suivantes