Exécuter SAP NetWeaver dans Windows sur Azure

Ce guide présente un ensemble de pratiques éprouvées pour l’exécution de SAP NetWeaver dans un environnement Windows sur Azure avec une haute disponibilité. La base de données est AnyDB, le terme SAP désignant tout système de gestion de base de données (SGBD) pris en charge en plus de SAP HANA.

Architecture

Le diagramme suivant montre SAP NetWeaver dans un environnement Windows.

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

Ce guide décrit un système de production. Ce système est déployé avec des tailles de machine virtuelle spécifiques que vous pouvez modifier en fonction des besoins de votre organisation. Le système peut être réduit à une seule machine virtuelle. Dans ce guide, la disposition du réseau est considérablement simplifiée pour illustrer les principes architecturaux. Elle n’est pas destinée à décrire un réseau d’entreprise complet.

Workflow

Réseaux virtuels. Le service Réseau virtuel Azure connecte les ressources Azure entre elles, avec une sécurité améliorée. Dans cette architecture, le réseau virtuel se connecte à un réseau local par le biais d’une passerelle Azure ExpressRoute déployée dans le hub d’une topologie hub-and-spoke. Le spoke est le réseau virtuel utilisé pour les applications SAP et les niveaux de base de données. Le réseau virtuel hub est utilisé pour les services partagés tels qu’Azure Bastion et la sauvegarde.

Peering de réseaux virtuels. Cette architecture utilise une topologie de réseau hub-and-spoke avec plusieurs réseaux virtuels appairés. Cette topologie assure la segmentation et l’isolement réseau des services déployés sur Azure. Le peering permet une connectivité transparente entre les réseaux virtuels homologués via le réseau principal Microsoft. Elle n’entraîne pas de perte de performances si elle est déployée dans une seule région. Le réseau virtuel est divisé en sous-réseaux distincts pour chaque couche : l’application (SAP NetWeaver), la base de données et les services partagés, comme Bastion et une solution de sauvegarde tierce.

Les machines virtuelles. Cette architecture utilise des machines virtuelles pour Linux pour le niveau application et la couche base de données, regroupés de la manière suivante :

• SAP NetWeaver. La couche Application utilise des machines virtuelles Windows pour exécuter les services centraux SAP et les serveurs d’applications SAP. Pour la haute disponibilité, les machines virtuelles qui exécutent les services centraux sont configurées dans un cluster de basculement Windows Server. Elles sont prises en charge par des partages de fichiers Azure ou les disques partagés Azure.

• AnyDB. La couche Base de données utilise AnyDB comme base de données, qui peut être Microsoft SQL Server, Oracle ou IBM Db2.

• Service Bastion. Les administrateurs utilisent une machine virtuelle de sécurité améliorée appelée hôte bastion pour se connecter à d’autres machines virtuelles. Il s’agit généralement d’une partie des services partagés, tels que les services de sauvegarde. Si SSH (Secure Shell Protocol) et RDP (Remote Desktop Protocol) sont les seuls services utilisés pour l’administration du serveur, un hôte Azure Bastion constitue une excellente solution. Si vous utilisez d’autres outils de gestion, comme SQL Server Management Studio ou le serveur front-end SAP, utilisez un serveur de rebond classique et auto-déployé.

Service DNS privé.Azure Private DNS fournit un service DNS fiable et sécurisé pour votre réseau virtuel. Azure Private DNS gère et résout les noms de domaine dans le réseau virtuel sans nécessiter la configuration d’une solution DNS personnalisée.

Équilibreurs de charge. Pour répartir le trafic sur des machines virtuelles dans le sous-réseau de la couche Application SAP à des fins de haute disponibilité, nous vous recommandons d’utiliser un équilibreur de charge standard Azure. Veuillez noter que l’équilibreur de charge standard fournit un haut niveau de sécurité par défaut. Les machines virtuelles qui se trouvent derrière l’équilibreur de charge standard n’ont pas de connectivité internet sortante. Pour activer la connectivité Internet sortante sur les machines virtuelles, vous devez mettre à jour la configuration de votre équilibreur de charge standard. Pour la haute disponibilité de l’application web SAP, utilisez SAP Web Dispatcher intégré ou un autre équilibreur de charge disponible sur le marché. Basez votre sélection sur ce qui suit :

• Votre type de trafic, tel que HTTP ou SAP GUI.
• Les services réseau dont vous avez besoin, tels qu’une terminaison SSL (Secure Sockets Layer).

Pour obtenir des exemples de conception entrante/sortante accessibles à Internet, consultez Connexions Internet entrantes et sortantes pour SAP sur Azure.

Standard Load Balancer prend en charge plusieurs adresses IP virtuelles front-end. Cette prise en charge est idéale pour les implémentations de cluster qui impliquent ces composants :

• Advanced Business Application Programming (ABAP) SAP Central Service (ASCS)
• Serveur de réplication en file d’attente (ERS)

La référence SKU standard prend également en charge les clusters SAP à identificateurs multi-systèmes (multi-SID). En d’autres termes, plusieurs systèmes SAP sur Windows peuvent partager une infrastructure de haute disponibilité commune en vue de réduire les coûts. Évaluez les économies de coûts et évitez de placer trop de systèmes dans un cluster. Azure ne prend pas en charge plus de cinq SID par cluster.

Passerelle applicative. Azure Application Gateway est un équilibreur de charge de trafic web que vous pouvez utiliser pour gérer le trafic vers vos applications web. Les équilibreurs de charge traditionnels fonctionnent sur la couche transport (couche OSI 4 - TCP et UDP). Ils acheminent le trafic en fonction de l’adresse IP et du port source vers une adresse IP et un port de destination. Application Gateway peut prendre des décisions de routage basées sur des attributs supplémentaires d’une requête HTTP, comme les chemins d’URI ou les en-têtes d’hôte. Ce type de routage est connu comme l’équilibrage de charge de la couche d’application (couche OSI 7).

Groupes de sécurité réseau. Pour limiter le trafic entrant, sortant et intra-sous-réseau dans un réseau virtuel, créez des groupes de sécurité réseau.

Groupes de sécurité d’application. Pour définir des stratégies de sécurité réseau affinées basées sur les charges de travail et centrées sur les applications, utilisez des groupes de sécurité d’application plutôt que des adresses IP explicites. Les groupes de sécurité d’application vous permettent de regrouper les machines virtuelles par nom et de sécuriser les applications en filtrant le trafic provenant des segments approuvés de votre réseau.

Passerelle. Une passerelle connecte différents réseaux et étend votre réseau local sur le réseau virtuel Azure. Nous vous recommandons d’utiliser ExpressRoute pour créer des connexions privées qui ne passent pas par l’Internet public, mais vous pouvez également utiliser une connexion de site à site . Pour réduire la latence ou augmenter le débit, envisagez d’utiliser ExpressRoute Global Reach et ExpressRoute FastPath, comme décrit plus loin dans cet article.

Stockage Azure. Stockage assure la persistance des données pour une machine virtuelle sous la forme d’un disque dur virtuel. Nous recommandons les disques managés Azure.

Recommandations

Cette architecture décrit un petit déploiement de niveau production. Votre déploiement varie en fonction des exigences de votre entreprise. Vous pouvez donc utiliser ces recommandations comme point de départ.

Machines virtuelles

Dans les pools et les clusters de serveurs d’applications, ajustez le nombre de machines virtuelles en fonction de vos besoins. Pour obtenir des informations détaillées sur l’exécution de SAP NetWeaver sur des machines virtuelles, consultez Planification et implémentation de machines virtuelles Azure pour SAP NetWeaver.

Pour plus d’informations sur la prise en charge SAP en fonction des types de machines virtuelles Azure et des mesures de débit (SAPS), consultez la note SAP 1928533. Pour accéder aux notes SAP, vous devez disposer d’un compte SAP Service Marketplace.

SAP Web Dispatcher

Le composant Web Dispatcher sert à équilibrer le trafic SAP entre les serveurs d’applications SAP. Pour assurer la haute disponibilité du composant Web Dispatcher, Azure Load Balancer implémente le cluster de basculement des instances Web Dispatcher ou l’installation parallèle de Web Dispatcher. Pour une description détaillée de la solution, consultez l’article High Availability of the SAP Web Dispatcher (Haute disponibilité de SAP Web Dispatcher).

Pool de serveurs d’applications

La transaction SAP SMLG est couramment utilisée pour gérer les groupes de connexion pour les serveurs d’applications ABAP et pour équilibrer la charge des utilisateurs de connexion. D’autres transactions, telles que SM61 pour les groupes de serveurs par lots et RZ12 pour les groupes d’appel de fonction distante (RFC), équilibrent également la charge des utilisateurs de connexion. Ces transactions s’appuient sur la fonction d’équilibrage de charge au sein du serveur de messages des services centraux SAP pour répartir les sessions entrantes ou les charges de travail entre le pool de serveurs d’applications SAP pour le trafic des clients SAP GUI et RFC.

Cluster des services centraux SAP

Cette architecture exécute les services centraux sur les machines virtuelles de la couche application. Les services centraux constituent un potentiel point de défaillance unique (SPOF) lorsqu’ils sont déployés dans une seule machine virtuelle. Pour implémenter une solution hautement disponible, utilisez un cluster de partage de fichiers ou un cluster de disque partagé.

Pour les partages de fichiers à haute disponibilité, il existe plusieurs options. Nous vous recommandons d’utiliser des partages Azure Files en tant que partages SMB (Server Message Block) ou NFS (Network File System). Azure NetApp Files est une alternative à Azure Files et offre des partages NFS et SMB haute performance.

Vous pouvez également implémenter les partages de fichiers hautement disponibles sur les instances des services centraux à l’aide d’un cluster de basculement Windows Server avec Azure Files. Cette solution prend également en charge un cluster Windows avec des disques partagés en utilisant un disque partagé Azure comme volume partagé de cluster. Si vous préférez utiliser des disques partagés, nous vous recommandons d’utiliser des disques partagés Azure pour configurer un cluster de basculement Windows Server pour le cluster de services centraux SAP.

Il existe également des produits partenaires tels que SIOS DataKeeper Cluster Edition de SIOS Technology Corp. Ce module complémentaire réplique le contenu à partir de disques indépendants attachés aux nœuds de cluster ASCS, puis présente les disques comme un volume partagé de cluster au logiciel de cluster.

Si vous utilisez le partitionnement du réseau de clusters, le logiciel de cluster utilise des votes de quorum pour sélectionner un segment du réseau (et ses services associés) servant de cerveau pour le cluster fragmenté. Windows offre de nombreux modèles de quorum. Cette solution utilise le Témoin cloud, car elle est plus simple et offre plus de disponibilité qu’un témoin de nœud de calcul. Le témoin de partage de fichiers Azure peut aussi être utilisé pour fournir un vote de quorum de cluster.

Sur un déploiement Azure, les serveurs d’applications se connectent aux services centraux hautement disponibles en utilisant les noms d’hôtes virtuels des services ASCS ou ERS. Ces noms d’hôtes sont attribués à la configuration d’adresse IP frontale de cluster de l’équilibreur de charge. Load Balancer prend en charge plusieurs adresses IP frontales, de telle sorte que les adresses IP virtuelles ASCS et ERS peuvent être liées à un équilibreur de charge.

Mise en réseau

Cette architecture utilise une topologie hub-and-spoke. Le réseau virtuel hub joue un rôle de point de connectivité central au réseau local. Les spokes sont des réseaux virtuels qui s’appairent avec le hub et isolent les charges de travail SAP. Le trafic circule entre le centre de données local et le hub via une connexion de passerelle.

Cartes d’interface réseau

Les cartes réseau permettent toutes les communications entre machines virtuelles sur un réseau virtuel. Les déploiements SAP locaux traditionnels implémentent plusieurs cartes réseau par machine pour séparer le trafic administratif du trafic opérationnel.

Sur Azure, le réseau virtuel est un réseau à définition logicielle qui envoie tout le trafic via la même structure réseau. Il n’est donc pas nécessaire d’utiliser plusieurs cartes réseau pour des raisons de performances. Toutefois, si votre organisation a besoin de séparer le trafic, vous pouvez déployer plusieurs cartes réseau par machine virtuelle et connecter chaque carte réseau à un sous-réseau différent. Vous pouvez ensuite utiliser des groupes de sécurité réseau pour appliquer différentes stratégies de contrôle d’accès.

Les cartes d’interface réseau Azure prennent en charge plusieurs adresses IP. Cette prise en charge est conforme à la pratique recommandée par SAP, qui consiste à utiliser des noms d’hôtes virtuels pour les installations. Pour obtenir un plan complet, consultez la note SAP 962955. Pour accéder aux notes SAP, vous devez disposer d’un compte SAP Service Marketplace.

Sous-réseaux et groupes de sécurité réseau

Cette architecture divise l’espace d’adressage du réseau virtuel en sous-réseaux. Vous pouvez associer chaque sous-réseau à un groupe de sécurité réseau qui définit les stratégies d’accès pour ce sous-réseau. Placez les serveurs d’applications sur un sous-réseau distinct. Pour ce faire, vous pouvez sécuriser plus facilement en gérant les stratégies de sécurité du sous-réseau plutôt que les serveurs individuels.

Lorsque vous associez un groupe de sécurité réseau à un sous-réseau, celui-ci s’applique à tous les serveurs du sous-réseau et offre un contrôle affiné des serveurs. Configurez les groupes de sécurité réseau à l’aide du Portail Azure, de PowerShell ou de l’interface de ligne de commande Azure.

Service Global Reach d’ExpressRoute

Si votre environnement réseau inclut plusieurs connexions ExpressRoute, ExpressRoute Global Reach peut vous permettre de diminuer le nombre de tronçons du réseau et réduire la latence. Cette technologie désigne un peering de routes BGP (Border Gateway Protocol) configuré entre plusieurs connexions ExpressRoute pour relier deux domaines de routage ExpressRoute. Global Reach réduit la latence lorsque le trafic réseau traverse plus d’une connexion ExpressRoute. Global Reachest est actuellement disponible uniquement pour le peering privé sur les circuits ExpressRoute.

Pour l’instant, il n’existe pas de listes de contrôle d’accès réseau ou d’autres attributs pouvant être modifiés dans Global Reach. Ce faisant, tous les itinéraires appris par un circuit ExpressRoute donné (en local et dans Azure) sont publiés sur l’ensemble du peering du circuit vers l’autre circuit ExpressRoute. Nous vous recommandons d’établir le trafic réseau localement afin de restreindre l’accès aux ressources.

ExpressRoute FastPath

FastPath est conçu pour améliorer les performances du chemin d’accès aux données entre votre réseau local et votre réseau virtuel. Lorsqu’il est activé, FastPath envoie le trafic réseau directement vers les machines virtuelles du réseau virtuel, en contournant la passerelle.

FastPath est la configuration par défaut pour toutes les nouvelles connexions ExpressRoute à Azure. Pour les circuits ExpressRoute existants, contactez le support Azure pour activer FastPath.

FastPath ne prend pas en charge l’appairage de réseaux virtuels. Si d’autres réseaux virtuels sont appairés avec un réseau connecté à ExpressRoute, le trafic de votre réseau local vers les autres réseaux virtuels spoke est envoyé vers la passerelle du réseau virtuelle. La solution de contournement consiste à connecter tous les réseaux virtuels directement au circuit ExpressRoute. Cette fonctionnalité est actuellement disponible en préversion publique.

Équilibreurs de charge

SAP Web Dispatcher gère l’équilibrage de charge du trafic HTTP(S) à destination d’un pool de serveurs d’applications SAP. Cet équilibreur de charge logiciel fournit des services de couche Application (appelée couche 7 dans le modèle de mise en réseau ISO) comprenant un processus de terminaison SSL et d’autres fonctions de déchargement.

Azure Load Balancer est un service de couche de transmission réseau (couche 4) qui équilibre le trafic en utilisant un hachage à cinq tuples à partir des flux de données. Le hachage est basé sur l’adresse IP source, le port source, l’adresse IP de destination, le port de destination et le type de protocole. Dans les déploiements SAP sur Azure, Load Balancer est utilisé dans les configurations de cluster pour diriger le trafic vers l’instance de service principale ou vers le nœud sain en cas d’erreur.

Nous vous recommandons d’utiliser Standard Load Balancer pour tous les scénarios SAP. Si les machines virtuelles du pool principal nécessitent une connectivité sortante publique ou si elles sont utilisées dans un déploiement de zone Azure, Standard Load Balancer nécessite des configurations supplémentaires car celles-ci sont sécurisées par défaut. Elles n’autorisent pas la connectivité sortante, sauf configuration explicite contraire.

Pour le trafic en provenance de clients SAP GUI qui se connectent à un serveur SAP via le protocole DIAG ou RFC, le serveur de messages des services centraux équilibre la charge par l’intermédiaire des groupes de connexion des serveurs d’applications SAP. Pour ce type de configuration, vous n’avez pas besoin d’un autre équilibreur de charge.

Stockage

Certaines organisations utilisent le stockage standard pour leurs serveurs d’applications. Les disques non managés standard ne sont pas pris en charge. Consultez la note SAP 1928533. Pour accéder aux notes SAP, vous devez disposer d’un compte SAP Service Marketplace. Nous vous recommandons d’utiliser des disques managés Azure Premium dans tous les cas. Une mise à jour récente de la note SAP 2015553 exclut l’utilisation d’un stockage HDD Standard et d’un stockage SSD Standard pour quelques cas d’usage spécifiques.

Les serveurs d’applications n’hébergent pas de données d’entreprise. Vous pouvez également utiliser les disques Premium P4 et P6 plus petits pour réduire les coûts. De cette façon, vous pouvez bénéficier du contrat de niveau de service d’une machine virtuelle à instance unique si vous disposez d’une installation de la pile SAP centrale.

Pour les scénarios de haute disponibilité, vous pouvez utiliser des partages de fichiers Azure et des disques partagés Azure. Les disques managés SSD Premium et les disques de stockage Ultra sont disponibles pour les disques partagés azure, et SSD Premium est disponible pour les partages de fichiers Azure.

Le service Stockage est également utilisé par le témoin de cloud pour maintenir le quorum avec un appareil dans une région Azure distante en dehors de la région principale où réside le cluster.

Pour le magasin de données de sauvegarde, nous vous recommandons d’utiliser les niveaux d’accès froid et archive d’Azure. Ces niveaux de stockage offrent un moyen économique de stocker les données durables rarement sollicitées.

Le stockage sur disque SSD Premium v2 Azure est conçu pour les charges de travail exigeant des performances élevées telles que les systèmes de traitement transactionnel en ligne qui ont constamment besoin d’une latence inférieure à la milliseconde associée à des IOPS et à un débit élevés.

Les disques de stockage Ultra réduisent considérablement la latence de disque. Par conséquent, ils sont utiles pour les applications critiques en termes de performances, comme les serveurs de base de données SAP. Pour comparer les options de stockage de niveau bloc dans Azure, consultez Types de disques managés Azure.

Pour une banque de données partagée hautement performante et hautement disponible, utilisez Azure NetApp Files. Cette technologie est particulièrement utile pour le niveau de base de données lorsque vous utilisez Oracle et lorsque vous hébergez des données d’application.

Considérations relatives aux performances

Les serveurs d’applications SAP communiquent constamment avec les serveurs de base de données. Pour les applications exigeant des performances élevées qui s’exécutent sur des plateformes de base de données, activez l’Accélérateur d’écriture pour le volume du fichier journal si vous utilisez un disque SSD Premium v1. Cela peut améliorer la latence d’écritures des journaux. L’Accélérateur d’écriture est disponible pour les machines virtuelles de la série M.

Pour optimiser les communications entre les serveurs, utilisez la mise en réseau accélérée. La plupart des tailles d’instances de machines virtuelles d’usage général et optimisées pour le calcul qui disposent d’au moins deux processeurs virtuels prennent en charge les performances réseau accélérées. Dans des instances qui acceptent l’hyperthreading, les instances de machines virtuelles comptant au minimum quatre processeurs virtuels prennent en charge Performances réseau accélérées.

Pour obtenir un débit élevé d’IOPS et de disque, suivez les pratiques courantes en termes d’optimisation des performances du volume de stockage qui s’appliquent à la disposition du stockage Azure. Par exemple, vous pouvez positionner plusieurs disques pour créer un volume de disque agrégé par bandes afin d’améliorer les performances d’E/S. L’activation du cache de lecture sur un contenu de stockage qui change rarement améliore la vitesse de récupération des données.

Les disques SSD Premium v2 offrent des performances supérieures à celles des disques SSD Premium et sont généralement moins coûteux. Vous pouvez définir un disque SSD Premium v2 sur la taille prise en charge de votre choix, puis apporter des ajustements précis aux performances sans temps d’arrêt.

Les disques de stockage Ultra sont désormais disponibles pour les applications gourmandes en E/S. Là où ces disques sont disponibles, nous vous recommandons de les utiliser sur le stockage premium de l’Accélérateur d’écriture. Vous pouvez augmenter ou diminuer individuellement les métriques de performances, comme les IOPS et les Mbits/s, sans devoir redémarrer.

Pour obtenir de l’aide sur l’optimisation du stockage Azure pour les charges de travail SAP sur SQL Server, consultez l’article Planification et implémentation de machines virtuelles Azure pour SAP NetWeaver.

Le placement d’une appliance virtuelle réseau (NVA) entre les couches Application et Base de données de n’importe quelle pile d’applications SAP n’est pas pris en charge. Cette pratique introduit un temps de traitement significatif des paquets de données, qui entraîne des performances d’applications inacceptables.

Groupes de placements de proximité

Certaines applications SAP ont besoin de communiquer régulièrement avec la base de données. La proximité physique des couches Application et Base de données affecte la latence du réseau, ce qui peut nuire aux performances des applications.

Pour optimiser la latence du réseau, vous pouvez utiliser les groupes de placement de proximité, qui définissent une contrainte logique sur les machines virtuelles déployées dans des groupes à haute disponibilité. Les groupes de placement de proximité favorisent la colocation et les performances par rapport à l’évolutivité, la disponibilité ou les coûts. Ils peuvent grandement améliorer l’expérience utilisateur pour la plupart des applications SAP. Pour connaître les scripts disponibles sur GitHub auprès de l’équipe de déploiement SAP, consultez Scripts.

Zones de disponibilité

Les zones de disponibilité vous permettent de déployer des machines virtuelles entre des centres de données, qui sont des emplacements physiquement séparés au sein d’une région Azure spécifique. Leur but est d’améliorer la disponibilité du service. Toutefois, comme le déploiement de ressources entre les zones peut augmenter la latence, il faut donc garder à l’esprit les considérations de performance.

Les administrateurs ont besoin d’un profil de latence réseau clair entre toutes les zones d’une région cible pour pouvoir déterminer le positionnement des ressources avec une latence interzones minimale. Pour créer ce profil, déployez de petites machines virtuelles dans chaque zone à des fins de test. Nous vous recommandons d’utiliser les outils PsPing et Iperf. Une fois les tests terminés, supprimez les ordinateurs virtuels que vous avez utilisés pour le test. En guise d’alternative, vous pouvez utiliser un outil de vérification de la latence interzone Azure.

Considérations relatives à l’extensibilité

Au niveau de la couche de l’application SAP, Azure propose un large éventail de tailles de machines virtuelles pour la montée en puissance ou la montée en charge. Pour obtenir une liste exhaustive, consultez la note SAP 1928533, SAP Applications on Azure: Supported Products and Azure VM Types (Applications SAP sur Azure : produits et types de machines virtuelles pris en charge). Pour accéder aux notes SAP, vous devez disposer d’un compte SAP Service Marketplace.

Vous pouvez effectuer un scale-up ou un scale-down des clusters des services centraux. Vous pouvez également les mettre à l’échelle ou en modifiant le nombre d’instances que vous utilisez. La base de données AnyDB peut effectuer un scale-up et un scale-down, mais pas un scale-out. Le conteneur de base de données SAP pour AnyDB ne prend pas en charge le partitionnement.

Considérations relatives à la disponibilité

La redondance des ressources constitue le thème général dans les solutions d’infrastructure à haute disponibilité. Pour les SLA de disponibilité de machines virtuelles à instance unique des différents types de stockage, consultez SLA pour les machines virtuelles. Pour augmenter la disponibilité du service sur Azure, déployez des ressources de machine virtuelle à l’aide de Virtual Machine Scale Sets avec une orchestration flexible, des zones de disponibilité ou des groupes à haute disponibilité.

Avec Azure, le déploiement de la charge de travail SAP peut être régional ou zonal, selon les exigences de disponibilité et de résilience des applications SAP. Azure fournit différentes options de déploiement, comme Virtual Machine Scale Sets avec orchestration flexible (FD=1), les zones de disponibilité et les groupes à haute disponibilité, pour améliorer la disponibilité des ressources. Pour obtenir une compréhension complète des options de déploiement disponibles et de leur applicabilité dans différentes régions Azure (y compris entre les zones, au sein d’une seule zone ou dans une région sans zones), consultez Architecture et scénarios de haute disponibilité pour SAP NetWeaver.

Dans cette installation distribuée de l’application SAP, l’installation de base est répliquée pour assurer une haute disponibilité. Pour chaque couche de l’architecture, la conception mise en œuvre à des fins de haute disponibilité varie.

Web Dispatcher dans la couche Serveurs d’applications

Le composant Web Dispatcher sert d’équilibreur de charge pour le trafic SAP entre les serveurs d’applications SAP. Pour assurer la haute disponibilité du composant SAP Web Dispatcher, Load Balancer implémente le cluster de basculement ou l’installation parallèle de Web Dispatcher.

Pour les communications sur Internet, nous recommandons une solution autonome dans le réseau de périmètre (également appelé DMZ) pour répondre aux problèmes de sécurité.

Le répartiteur Web incorporé sur ASCS est une option spéciale. Si vous utilisez cette option, tenez compte du dimensionnement approprié en raison de la charge de travail supplémentaire sur ASCS.

Services centraux dans la couche Serveurs d’applications

La haute disponibilité des services centraux est implémentée à l’aide du cluster de basculement Windows Server. Lorsque le stockage de cluster pour le cluster de basculement est déployé sur Azure, vous pouvez le configurer de deux manières : en tant que disque partagé en cluster ou en tant que partage de fichiers en cluster.

• Nous vous recommandons d’utiliser des Azure Files en tant que partages SMB ou NFS entièrement managés et natifs du cloud. Une autre façon est d’utiliser Azure NetApp Files, qui fournit des partages NFS et SMB hautes performances de niveau entreprise.

• Il existe deux façons de configurer un cluster avec des disques partagés sur Azure. Tout d’abord, nous vous recommandons d’utiliser des disques partagés Azure pour configurer un cluster de basculement Windows Server pour les services centraux SAP. Pour avoir un exemple d’implémentation, consultez Cluster SAP ASCS utilisant des disques partagés Azure. Une autre façon d’implémenter un disque partagé en cluster consiste à utiliser SIOS DataKeeper pour effectuer les tâches suivantes :

  • Répliquer le contenu de disques indépendants qui sont attachés aux nœuds du cluster.
  • Résumez les lecteurs en tant que volume partagé de cluster pour le gestionnaire de cluster.

  Pour obtenir des informations relatives à l’implémentation, consultez Clustering de SAP ASCS sur Azure avec SIOS.

Si vous utilisez Standard Load Balancer, vous pouvez activer le port à haute disponibilité. Cela vous évite ainsi de configurer des règles d’équilibrage de charge pour plusieurs ports SAP. En outre, lorsque vous configurez des équilibreurs de charge Azure, activez le retour direct du serveur (DSR), qui est également appelé IP flottante. Cela permet aux réponses du serveur de contourner l’équilibreur de charge. Cette connexion directe empêche l’équilibreur de charge de devenir un goulot d’étranglement dans le chemin de transmission des données. Nous vous recommandons d’activer DSR pour les clusters ASCS et base de données.

Services d’applications dans la couche Serveurs d’applications

Pour les serveurs d’applications SAP, la haute disponibilité est assurée en équilibrant la charge du trafic au sein d’un pool de serveurs d’applications. Vous n’avez pas besoin d’un logiciel de cluster, de SAP Web Dispatcher ou de l’équilibreur de charge Azure. Le serveur de messages SAP peut équilibrer la charge du trafic client vers les serveurs d’applications définis dans un groupe d’ouverture de session ABAP par la transaction SMLG.

Couche base de données

Dans cette architecture, la base de données source s’exécute sur AnyDB: un SGBD comme SQL Server, SAP ASE, IBM Db2 ou Oracle. La fonctionnalité de réplication native de la couche Base de données assure un basculement manuel ou automatique entre les nœuds répliqués.

Pour plus d’informations sur l’implémentation de systèmes de base de données spécifiques, consultez Déploiement SGBD de machines virtuelles Azure pour SAP.

Machines virtuelles déployées dans des zones de disponibilité

Une zone de disponibilité se compose d’un ou plusieurs centres de données. Elle est conçue pour améliorer la disponibilité des charges de travail et protéger les services d’applications et machines virtuelles en cas de pannes du centre de données. Les machines virtuelles d’une même zone sont traitées comme si elles se trouvaient dans le même domaine d’erreur. Lorsque le déploiement zonal est sélectionné, les machines virtuelles de la même zone sont réparties auprès des domaines d’erreur de manière optimale.

Dans les régions Azure qui prennent en charge plusieurs zones, au moins trois zones sont disponibles. La distance maximale entre les centres de données dans ces zones n’est toutefois pas garantie. Pour déployer un système SAP multiniveaux sur plusieurs zones, vous devez connaître la latence au sein d’une zone et sur l’ensemble des zones ciblées. Vous devez également connaître la sensibilité de vos applications déployées à la latence du réseau.

Tenez compte de ces considérations lorsque vous décidez de déployer des ressources sur des zones de disponibilité :

• la latence entre les machines virtuelles d’une zone ;
• la latence entre les machines virtuelles sur les zones choisies ;
• la disponibilité des mêmes services Azure (types de machines virtuelles) dans les zones choisies.

Exemple de déploiement actif/inactif

Dans cet exemple de déploiement, l’état actif/passif fait référence à l’état du service d’application dans les zones. Dans la couche Application, les quatre serveurs d’applications actifs du système SAP sont dans la zone 1. Un autre ensemble de quatre serveurs d’applications passifs est intégré à la zone 2, mais celui-ci est arrêté. Ils sont activés uniquement quand ils sont nécessaires.

Les clusters à deux nœuds des services centraux et des services de base de données sont étendus sur deux zones. En cas de défaillance de la zone 1, les services centraux et les services de base de données sont exécutés dans la zone 2. Les serveurs d’applications passifs de la zone 2 sont activés. Tous les composants de ce système SAP étant à présent colocalisés dans la même zone, la latence du réseau est réduite.

Exemple de déploiement actif/actif

Dans un déploiement actif/actif, deux ensembles de serveurs d’applications sont créés sur deux zones. Dans chaque zone, deux serveurs d’applications dans chaque ensemble de serveurs sont inactifs, car ils sont à l’arrêt. En conséquence, il existe des serveurs d’applications actifs dans les deux zones pendant des opérations normales.

Les services centraux et les services de base de données sont exécutés dans la zone 1. Les serveurs d’applications de la zone 2 peuvent présenter une latence réseau plus longue lors de la connexion aux services centraux et aux services de base de données en raison de la distance physique entre les zones.

Si la zone 1 est mise hors connexion, les services centraux et les services de base de données basculent vers la zone 2. Les serveurs d’applications dormants peuvent être mis en ligne pour fournir une capacité maximale pour le traitement des applications.

Considérations relatives à la récupération d’urgence

Chaque niveau de la pile d’applications SAP utilise une approche différente pour assurer une récupération d’urgence. Pour plus d’informations sur les stratégies et l’implémentation de la récupération d’urgence, consultez Vue d’ensemble de la récupération d’urgence et instructions d’infrastructure pour la charge de travail SAP et Instructions de récupération d’urgence pour l’application SAP.

Considérations relatives à la gestion et aux opérations

Pour aider à maintenir l’exécution de votre système en production, tenez compte des points suivants.

Centre Azure pour les solutions SAP

Le Centre Azure pour les solutions SAP est une solution de bout en bout qui vous permet de créer et d’exécuter des systèmes SAP en tant que charge de travail unifiée sur Azure et fournit une base plus transparente pour l’innovation. En outre, l’expérience de déploiement guidé par le Centre Azure pour les solutions SAP crée les composants de calcul, de stockage et de mise en réseau nécessaires à l’exécution de votre système SAP. Cela vous permet ensuite d’automatiser l’installation du logiciel SAP conformément aux meilleures pratiques de Microsoft. Vous pouvez tirer parti des fonctionnalités de gestion pour les systèmes SAP nouveaux et existants basés sur Azure. Pour plus d’informations, consultez Centre Azure pour les solutions SAP.

S’il vous faut mieux contrôler les événements de maintenance ou l’isolation matérielle, pour des raisons de performances ou de conformité, envisagez de déployer vos machines virtuelles sur des hôtes dédiés.

Sauvegarde

Les bases de données sont des charges de travail critiques nécessitant un faible objectif de point de récupération (RPO) et une conservation à long terme.

• Pour SAP sur SQL Server, une approche consiste à utiliser le service Sauvegarde Azure pour sauvegarder les bases de données SQL Server qui s’exécutent sur des machines virtuelles. Une autre option consiste à utiliser des instantanés de fichiers Azure pour sauvegarder les fichiers des bases de données SQL Server.

• Pour SAP sur Oracle/Windows, reportez-vous à la section « sauvegarde/restauration » de l’article Facteurs à prendre en compte pour le déploiement SGBD des machines virtuelles Azure pour la charge de travail SAP.

• Pour les autres bases de données, consultez les recommandations en matière de sauvegarde correspondant à votre fournisseur de base de données. Si la base de données prend en charge le service VSS, utilisez des instantanés VSS pour effectuer des sauvegardes cohérentes avec les applications.

Gestion des identités

Utilisez un système de gestion des identités centralisé comme Microsoft Entra ID et Active Directory Domain Services (AD DS) pour contrôler l’accès aux ressources à tous les niveaux :

• Fournissez l’accès aux ressources Azure par le biais du contrôle d’accès en fonction du rôle Azure (RBAC Azure).

• Accordez l’accès aux machines virtuelles Azure en utilisant le protocole LDAP (Lightweight Directory Access Protocol), Microsoft Entra ID, Kerberos ou un autre système.

Permettez l’accès dans les applications elles-mêmes en utilisant les services fournis par SAP. Vous pouvez également utiliser OAuth 2.0 et Microsoft Entra ID.

Supervision

Pour optimiser la disponibilité et les performances de vos applications et services sur Azure, utilisez Azure Monitor, une solution complète pour collecter, analyser et utiliser la télémétrie de vos environnements cloud et locaux. Azure Monitor vous permet de mieux comprendre les performances des applications et identifie de façon proactive les problèmes qui les affectent et les ressources dont elles dépendent. Pour les applications SAP qui s’exécutent sur SAP HANA et d’autres solutions de base de données majeures, voir Azure Monitor pour les solutions SAP pour savoir comment Azure Monitor pour SAP peut vous aider à gérer la disponibilité et les performances des services SAP.

Considérations relatives à la sécurité

SAP possède son propre moteur de gestion des utilisateurs (UME) pour contrôler l’accès et les autorisations en fonction du rôle dans l’application et les bases de données SAP. Pour obtenir des conseils détaillés sur la sécurité des applications, reportez-vous au Guide de sécurité SAP NetWeaver.

Pour renforcer la sécurité réseau, songez à utiliser un réseau de périmètre, qui utilise une NVA pour créer un pare-feu devant le sous-réseau de Web Dispatcher.

Vous pouvez déployer une appliance virtuelle réseau pour filtrer le trafic entre les réseaux virtuels, mais ne la placez pas entre l’application SAP et la base de données. Vérifiez également les règles d’acheminement qui sont configurées sur le sous-réseau et évitez de diriger le trafic vers une appliance virtuelle réseau à instance unique. Cela peut entraîner des interruptions de maintenance et des défaillances du réseau ou des nœuds en cluster.

Afin de garantir la sécurité de l’infrastructure, les données sont chiffrées en transit et au repos. Pour plus d’informations sur la sécurité réseau, consultez la section « Recommandations de sécurité » de la rubrique Planification et implémentation de machines virtuelles Azure pour SAP NetWeaver. L’article spécifie également les ports réseau, que vous devez ouvrir sur les pare-feu pour autoriser la communication de l’application.

Azure Disk Encryption permet de chiffrer des disques de machines virtuelles Windows. Ce service exploite la fonctionnalité BitLocker de Windows pour assurer le chiffrement de volume du système d’exploitation et des disques de données. La solution fonctionne également avec Azure Key Vault, ce qui vous permet de contrôler et de gérer les clés et les secrets de chiffrement de disque dans votre abonnement Key Vault. Les données sur les disques des machines virtuelles sont chiffrées au repos dans votre stockage Azure.

Pour le chiffrement des données au repos, SQL Server Transparent Data Encryption (TDE) chiffre les fichiers de données SQL Server, Azure SQL Database et Azure Synapse Analytics. Pour plus d’informations, consultez l’article Déploiement SGBD de machines virtuelles Azure pour SAP NetWeaver.

Pour surveiller les menaces à l’intérieur et à l’extérieur du pare-feu, envisagez de déployer Microsoft Sentinel (préversion). La solution assure la détection et l’analyse continues des menaces pour les systèmes SAP qui sont déployés sur Azure, dans d’autres Clouds ou localement. Pour obtenir des conseils de déploiement, consultez Déployer Threat Monitoring for SAP dans Microsoft Sentinel.

Comme toujours, gérez les mises à jour de sécurité et les correctifs, pour protéger vos ressources d’informations. Envisagez une approche d’automatisation de bout en bout pour cette tâche.

Considérations relatives au coût

Utiliser la calculatrice de prix Azure pour estimer les coûts.

Pour plus d’informations, consultez la section sur les coûts dans Microsoft Azure Well-Architected Framework.

Si votre charge de travail requiert plus de mémoire supplémentaire et moins de processeurs, envisagez d’utiliser l’une des tailles de machines virtuelles avec processeurs virtuels restreints pour réduire les coûts de licences logicielles facturés par processeur virtuel.

Machines virtuelles

Cette architecture utilise des machines virtuelles regroupées pour les couches Application et Base de données. La couche SAP NetWeaver utilise des machines virtuelles Windows pour exécuter des applications et services SAP. Le niveau Base de données exécute AnyDB en tant que base de données, comme SQL Server, Oracle ou IBM DB2. Les machines virtuelles sont également utilisées comme serveurs de rebond pour la gestion.

Il existe plusieurs options de paiement pour les machines virtuelles :

• Pour les charges de travail sans temps de réalisation prévisible ou la consommation des ressources, envisagez l’option Paiement à l’utilisation.

• Vous pouvez opter pour Azure Reservations si vous pouvez vous engager à utiliser une machine virtuelle sur une période de 1 ou 3 ans. Les réservations de machines virtuelles peuvent réduire considérablement les coûts. Vous pouvez payer jusqu’à 72 % du coût d’un service de paiement à l’utilisation.

Utilisez les machines virtuelles spot Azure pour exécuter des charges de travail pouvant être interrompues et ne nécessitant pas d’achèvement dans une période prédéterminée ou dans un contrat SLA. Azure déploie des machines virtuelles spot lorsqu’il y a de la capacité disponible et les supprime lorsque la capacité est de nouveau disponible. Les coûts associés aux machines virtuelles spot sont inférieurs à ceux des autres machines virtuelles. Vous pouvez opter pour les machines virtuelles Spot pour ces charges de travail :

• Scénarios de calcul haute performance, travaux de traitement par lots ou applications de rendu visuel
• Environnements de test, y compris les charges de travail d’intégration continue et de livraison continue
• applications sans état à grande échelle ;

Azure Reserved Virtual Machine Instances peut réduire votre coût total de possession en combinant les tarifs Azure Reserved Virtual Machine Instances avec un abonnement de paiement à l’utilisation afin que vous puissiez gérer les coûts sur des charges de travail prévisibles et variables. Pour plus d’informations, consultez Azure Reserved Virtual Machine Instances.

Load Balancer

Dans ce scénario, Load Balancer sert à distribuer le trafic vers les machines virtuelles du sous-réseau de la couche Application.

Seules vous sont facturées les règles d’équilibrage de charge et de trafic sortant configurées, et les données traitées par le biais de l’équilibrage de charge. Les règles NAT (traduction d’adresses réseau) entrantes sont gratuites. Il n’y a pas de frais horaires pour l’équilibreur de charge Standard Load Balancer lorsqu’aucune règle n’est configurée.

ExpressRoute

Dans cette architecture, ExpressRoute est le service de mise en réseau recommandé pour la création de connexions privées entre un réseau local et des réseaux virtuels Azure.

Le transfert de toutes les données entrantes est gratuit. Tous les transferts de données sortants sont facturés sur la base d'un tarif prédéterminé. Pour plus d'informations, consultez Tarification d'Azure ExpressRoute.

Communautés

Les communautés peuvent répondre aux questions et vous aider à paramétrer un déploiement réussi. Prenez en compte les ressources suivantes :

• Blog Running SAP Applications on the Microsoft Platform (Exécution d’applications SAP sur la plateforme Microsoft)
• Support de la communauté Azure
• Communauté SAP
• Stack Overflow pour SAP

Contributeurs

Cet article est géré par Microsoft. Il a été écrit à l’origine par les contributeurs suivants.

Auteur principal :

• Ben Trinh | Architecte principal

Pour afficher les profils LinkedIn non publics, connectez-vous à LinkedIn.

Étapes suivantes

Pour plus d’informations et des exemples de charges de travail SAP qui utilisent certaines technologies semblables à cette architecture, reportez-vous aux articles suivants :

• Planification et implémentation de machines virtuelles Azure pour SAP NetWeaver
• Utiliser Azure pour héberger et exécuter des scénarios de charge de travail SAP

Ressources associées

• Exécuter les charges de travail de production SAP à l’aide d’Oracle Database sur Azure