Partager via

SAP S/4HANA sur Linux dans Azure

Ce guide présente un ensemble de pratiques éprouvées pour l’exécution de S/4HANA et Suite sur HANA dans un environnement haute disponibilité (HA) qui prend en charge la récupération d’urgence (DR) sur Azure. Les informations concernant Fiori ne s’appliquent qu’aux applications S/4HANA.

Architecture

Diagramme d’architecture montrant SAP S/4HANA pour machines virtuelles Linux dans un groupe à haute disponibilité Azure.

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

Remarque

Pour déployer cette architecture, vérifiez que vous disposez des licences nécessaires pour les produits SAP et toutes les autres technologies non-Microsoft.

Ce guide décrit un système de production classique. Cette architecture utilise différentes tailles de machine virtuelle. Pour répondre aux besoins de votre organisation, vous pouvez ajuster les tailles ou réduire cette configuration en une seule machine virtuelle.

Dans ce guide, la disposition du réseau est simplifiée pour illustrer les principes architecturaux. Il ne représente pas un réseau d’entreprise complet.

L’architecture utilise les composants suivants : Certains services partagés sont facultatifs.

Réseau virtuel Azure. Le service de réseau virtuel connecte les ressources Azure entre elles avec une sécurité renforcée. Dans cette architecture, un réseau virtuel se connecte à un environnement local via une passerelle 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.

Peering de réseaux virtuels. Cette architecture utilise plusieurs réseaux virtuels jumelés. Cette topologie assure la segmentation et l’isolement réseau des services déployés sur Azure. Le peering connecte les réseaux de manière transparente via le réseau principal Microsoft et n’entraîne pas de pénalité de performances s’il est implémenté dans une seule région. Des sous-réseaux distincts sont utilisés pour chaque niveau, y compris la couche Application (SAP NetWeaver) et la couche Base de données, et pour les composants partagés tels que la zone de rebond et Windows Server Active Directory.

Les machines virtuelles. Cette architecture organise les machines virtuelles qui exécutent Linux dans des groupes pour la couche Application et la couche Base de données de la manière suivante :

  • Niveau d'application. Cette couche architecturale inclut le pool de serveurs front-end Fiori, le pool SAP Web Dispatcher, le pool de serveurs d’applications et le cluster des services centraux SAP. Pour la haute disponibilité des services centraux sur Azure qui s’exécutent dans des machines virtuelles Linux, un service de partage de fichiers réseau hautement disponible est requis, comme les partages de fichiers NFS (Network File System) dans Azure Files, Azure NetApp Files, les serveurs NFS en cluster ou SIOS Protection Suite pour Linux. Pour configurer un partage de fichiers hautement disponible pour le cluster des services centraux sur Red Hat Enterprise Linux (RHEL), vous pouvez configurer GlusterFS sur les machines virtuelles Azure exécutant RHEL Sur SUSE Linux Enterprise Server (SLES) 15 SP1 et versions ultérieures ou SLES pour les applications SAP, vous pouvez utiliser des disques partagés Azure sur un cluster Pacemaker en tant qu’appareil de clôture pour obtenir la haute disponibilité.

  • SAP HANA. La couche de base de données utilise deux machines virtuelles Linux ou plus dans un cluster pour garantir une haute disponibilité dans un déploiement de scale-up. La réplication de système HANA (HSR) est utilisée pour répliquer du contenu entre les systèmes HANA principal et secondaire. Le clustering Linux est utilisé pour détecter les défaillances du système et faciliter le basculement automatique. Vous devez utiliser un mécanisme de clôture basé sur le stockage ou basé sur le cloud pour vous assurer que le système défaillant est isolé ou arrêté pour éviter un cluster partitionné. Dans les déploiements HANA en extension horizontale, vous pouvez obtenir la haute disponibilité de la base de données en utilisant l'une des options suivantes :

    • Configurez les nœuds de secours HANA à l’aide d’Azure NetApp Files sans le composant de clustering Linux.

    • Scale-out sans nœuds de secours à l’aide du stockage Premium Azure. Utilisez le clustering Linux pour le basculement.

  • Azure Bastion. Ce service vous permet de vous connecter à une machine virtuelle à l’aide de votre navigateur et du portail Azure ou à l’aide du client SSH (Native Secure Shell) ou RDP (Remote Desktop Protocol) installé sur votre ordinateur local. Si seuls RDP et SSH sont utilisés pour l’administration, envisagez d’utiliser Azure Bastion. 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. Le DNS privé Azure 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 distribuer le trafic vers des machines virtuelles dans le sous-réseau de la couche Application SAP afin d’augmenter la disponibilité, utilisez Azure Standard Load Balancer. Standard Load Balancer fournit une couche de sécurité par défaut. Les machines virtuelles qui se trouvent derrière Standard Load Balancer n’ont pas de connectivité internet sortante. Pour activer la connectivité Internet sortante sur les machines virtuelles, vous devez mettre à jour votre configuration Standard Load Balancer. Vous pouvez également utiliser une passerelle Azure NAT Gateway pour obtenir une connectivité sortante. Pour l’application web SAP HA, utilisez le SAP Web Dispatcher intégré ou un autre équilibreur de charge disponible commercialement. Basez votre sélection sur ce qui suit :

  • Votre type de trafic, tel que le trafic d’interface utilisateur graphique HTTP ou SAP.
  • Les fonctionnalités réseau dont vous avez besoin, telles que la terminaison SSL (Secure Sockets Layer).

Standard Load Balancer prend en charge plusieurs adresses IP virtuelles frontales. Cette prise en charge est idéale pour les implémentations de cluster qui incluent les composants suivants :

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

Ces deux composants peuvent partager un équilibreur de charge pour simplifier la solution.

Standard Load Balancer prend également en charge les clusters SAP multi-système (multi-SID). Cette fonctionnalité permet à plusieurs systèmes SAP sur SLES ou RHEL de partager une infrastructure haute disponibilité commune pour réduire les coûts. Nous vous recommandons d’évaluer les économies de coûts et d’éviter de placer un nombre excessif de systèmes dans un cluster. Azure prend en charge jusqu’à 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 opèrent au niveau de la couche de transport, appelé OSI (Open Systems Interconnexion) couche 4, à l’aide du protocole de contrôle de transmission et du protocole de datagramme utilisateur. 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 en fonction d’attributs supplémentaires d’une requête HTTP, telles que le chemin d’accès de l’identificateur de ressource uniforme ou les en-têtes d’hôte. Ce type de routage est appelé couche Application ou OSI layer 7, équilibrage de charge. S/4HANA fournit des services d’application web via Fiori. Vous pouvez équilibrer la charge de ce front-end Fiori, qui se compose d’applications web, en utilisant Application Gateway. Si vous utilisez des adresses IP publiques, assurez-vous qu’elles utilisent la référence SKU d’adresse IP standard. Évitez le SKU d’adresse IP de base, car son retrait est prévu pour le 30 septembre 2025.

Passerelle. Une passerelle connecte différents réseaux et étend votre réseau local sur un réseau virtuel Azure. Azure ExpressRoute est le service Azure recommandé pour créer des connexions privées qui ne passent pas par l’Internet public. Vous pouvez aussi utiliser une connexion de site à site. Pour réduire la latence, utilisez ExpressRoute Global Reach ou ExpressRoute FastPath.

Passerelle redondante interzone. Vous pouvez déployer des passerelles ExpressRoute ou VPN sur plusieurs zones pour assurer une protection en cas de défaillances de zone. Cette architecture utilise des passerelles de réseau virtuel redondant interzone pour la résilience au lieu d’un déploiement zonal basé sur la même zone de disponibilité.

Groupe de placement de proximité. Ce groupe logique place une contrainte sur les machines virtuelles déployées dans un groupe à haute disponibilité ou un groupe de machines virtuelles identiques. Un groupe de placement de proximité permet d’appliquer la colocalisation en veillant à ce que les machines virtuelles soient déployées dans le même centre de données. Cette configuration réduit la distance physique entre les ressources pour réduire la latence de l’application.

Remarque

Pour obtenir une stratégie de configuration mise à jour, consultez les options de configuration pour réduire la latence réseau avec les applications SAP. Cet article décrit les compromis potentiels en matière de flexibilité de déploiement lorsque vous optimisez un système SAP pour la latence du réseau.

Groupes de sécurité réseau (NSG). Pour restreindre le trafic entrant, sortant et intra-sous-réseaux dans un réseau virtuel, vous pouvez créer des NSGs.

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, il est préférable d’utiliser des groupes de sécurité d’application plutôt que des adresses IP explicites. Vous pouvez 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.

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

Recommandations

Cette architecture décrit un petit déploiement de niveau production. Les déploiements varient selon les besoins 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 plus d’informations sur l’exécution de SAP NetWeaver sur des machines virtuelles, consultez le guide de planification et d’implémentation des machines virtuelles Azure. Le guide s’applique également aux déploiements SAP S/4HANA.

Pour plus d’informations sur la prise en charge de SAP pour les types de machines virtuelles Azure et pour les métriques de débit, consultez la note SAP 1928533. Pour accéder aux notes SAP, vous devez disposer d’un compte SAP Service Marketplace. Pour obtenir la liste des machines virtuelles Azure certifiées pour la base de données HANA, consultez le répertoire matériel SAP certifié et pris en charge par SAP HANA.

SAP Web Dispatcher

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, Azure Load Balancer implémente un cluster de basculement ou l’installation parallèle de Web Dispatcher. Pour les communications accessibles sur Internet, une solution autonome dans le réseau de périmètre est l’architecture recommandée pour répondre aux exigences de sécurité. Embedded Web Dispatcher sur ASCS est une configuration avancée. Si vous utilisez cette configuration, envisagez un dimensionnement approprié en raison de la charge de travail supplémentaire sur ASCS.

Fiori Front-end Server (FES)

Cette architecture répond à plusieurs exigences et suppose que vous utilisez le modèle Fiori FES incorporé. Tous les composants technologiques sont installés directement sur le système S/4, de sorte que chaque système S/4 possède son propre launchpad Fiori. Le système S/4 gère la configuration de haute disponibilité pour ce modèle de déploiement. Cette approche supprime la nécessité d’un clustering ou d’une machine virtuelle supplémentaire. Pour cette raison, le diagramme d’architecture n’inclut pas le composant FES.

Pour plus d’informations sur les options de déploiement, consultez les options de déploiement SAP Fiori et les recommandations relatives au paysage du système. Pour des raisons de simplification et de performances, les versions logicielles entre les composants de la technologie Fiori et les applications S/4 sont étroitement liées. Cette configuration rend un déploiement hub adapté uniquement à quelques cas d’usage spécifiques.

Si vous choisissez de déployer FES sous forme de hub, FES est un composant additionnel de la pile ABAP SAP NetWeaver classique. Configurez la haute disponibilité de la même façon que vous protégez une pile d’applications ABAP à trois niveaux qui a une fonctionnalité cluster ou multi-hôte. Utilisez une couche de base de données de serveur de secours, une couche ASCS en cluster avec ha NFS pour le stockage partagé et au moins deux serveurs d’applications. Le trafic est équilibré via une paire d’instances Web Dispatcher pouvant être mises en cluster ou être parallèles. Pour les applications Fiori accessibles sur Internet, nous vous recommandons de déployer un hub FES dans le réseau de périmètre. Utilisez le pare-feu d’applications web Azure sur Application Gateway comme composant essentiel pour dévier les menaces. Utilisez l’ID Microsoft Entra avec Security Assertion Markup Language pour l’authentification utilisateur et l’authentification unique pour SAP Fiori.

Diagramme d’architecture montrant le flux de données entre Internet et deux réseaux virtuels, un avec SAP Fiori et un avec SAP S/4HANA.

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

Pour plus d’informations, consultez Connexions Internet entrantes et sortantes pour SAP sur Azure.

Pool de serveurs d’applications

Pour gérer les groupes d’ouverture de session pour les serveurs d’applications ABAP, utilisez les codes de transaction suivants :

  • SMLG : équilibrage de la charge des utilisateurs de connexion.
  • SM61 : Gérer les groupes de serveurs batch.
  • RZ12 : Gérer les groupes DFC (Remote Function Call).

Ces transactions s’appuient sur la fonctionnalité d’équilibrage de charge dans le serveur de messages services centraux pour distribuer les sessions et charges de travail entrantes dans le pool de serveurs d’applications SAP qui gèrent le trafic de l’interface utilisateur utilisateur SAP et du trafic RFC.

Cluster de services centraux SAP

Les services centraux SAP contiennent une seule instance du serveur de messages et du service de réplication en file d’attente. Contrairement aux processus de travail des serveurs d’applications, ces composants sont des points de défaillance uniques dans la pile des applications SAP. Vous pouvez déployer des services centraux sur une seule machine virtuelle lorsque le contrat de niveau de service de disponibilité de machine virtuelle unique Azure répond à vos besoins. Si votre contrat SLA nécessite une disponibilité plus élevée, vous devez déployer ces services sur un cluster haute disponibilité. Pour plus d’informations, consultez Services centraux dans la couche Serveurs d’applications.

Réseautage

Cette architecture utilise une topologie hub-spoke où le réseau virtuel hub sert de point central de connectivité à un réseau local. Les Spokes sont des réseaux virtuels appairés avec le hub. Vous pouvez utiliser les spokes pour isoler les charges de travail. Le trafic circule entre le centre de données local et le hub via une connexion de passerelle.

Cartes d’interface réseau

Les déploiements SAP locaux traditionnels implémentent plusieurs cartes d’interface réseau par machine pour séparer le trafic administratif du trafic métier. Sur Azure, le réseau virtuel est un réseau défini par logiciel qui route tout le trafic via une seule infrastructure réseau. Par conséquent, vous n’avez pas besoin de plusieurs cartes réseau pour des raisons de performances. Si votre organisation doit séparer le trafic, vous pouvez déployer plusieurs cartes réseau pour chaque machine virtuelle, connecter chaque carte réseau à un autre sous-réseau, puis utiliser des groupes de sécurité réseau pour appliquer différentes stratégies de contrôle d’accès.

Les cartes réseau Azure prennent en charge plusieurs adresses IP. Cette prise en charge s’aligne sur la pratique que SAP recommande d’utiliser des noms d’hôtes virtuels pour les installations dans la note SAP 962955.

Sous-réseaux et NSG

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 le sous-réseau. Placez les serveurs d’applications sur un sous-réseau distinct. Cette approche facilite la sécurisation des serveurs d’applications en gérant les stratégies de sécurité de sous-réseau au lieu des serveurs individuels.

Lorsque vous associez un groupe de sécurité réseau à un sous-réseau, le groupe de sécurité réseau s’applique à tous les serveurs au sein du sous-réseau et fournit un contrôle précis sur les serveurs. Configurez des groupes de sécurité réseau à l’aide du portail Azure, d’Azure PowerShell ou d’Azure CLI.

ExpressRoute Global Reach

Si votre environnement réseau comprend deux circuits ExpressRoute ou plus, ExpressRoute Global Reach peut vous aider à réduire les tronçons réseau et à réduire la latence. Cette technologie désigne un peering de routes Border Gateway Protocol configuré entre plusieurs itinéraires ExpressRoute pour relier deux domaines de routage ExpressRoute. Global Reach réduit la latence lorsque le trafic réseau traverse plusieurs circuits ExpressRoute. Elle est disponible uniquement pour le peering privé sur les circuits ExpressRoute.

Global Reach ne prend pas en charge les modifications apportées aux listes de contrôle d’accès réseau ou à d’autres attributs. Tous les itinéraires appris par un circuit ExpressRoute, en local ou dans Azure, sont publiés sur l’ensemble du peering du circuit vers les autres circuits ExpressRoute. Nous vous recommandons de configurer le filtrage du trafic réseau en local pour restreindre l’accès aux ressources.

FastPath

FastPath implémente les échanges Microsoft Edge au point d’entrée du réseau Azure. FastPath permet de réduire le nombre de tronçons réseau pour la plupart des paquets de données. Par conséquent, FastPath réduit la latence du réseau, améliore les performances des applications et est la configuration par défaut pour 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 un réseau virtuel connecté à ExpressRoute est appairé avec d'autres réseaux virtuels, le trafic de votre réseau local vers les autres réseaux virtuels spoke est acheminé par le biais de la passerelle du réseau virtuelle. Pour résoudre ce problème, connectez tous les réseaux virtuels directement au circuit ExpressRoute.

Équilibreurs de charge

SAP Web Dispatcher gère l’équilibrage de charge du trafic HTTP et HTTPS vers un pool de serveurs d’applications SAP. Cet équilibreur de charge logiciel fournit des services de couche application, appelés couche 7 dans le modèle de mise en réseau ISO, capables d’arrêter 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 une adresse IP source, un port source, une adresse IP de destination, un port de destination et un type de protocole. Load Balancer est utilisé dans les configurations de cluster pour diriger le trafic vers l’instance de service principale ou le nœud sain en cas de défaillance. Nous vous recommandons d’utiliser Standard Load Balancer pour tous les scénarios SAP. Standard Load Balancer est sécurisé par défaut et aucune machine virtuelle derrière Standard Load Balancer n’a une connectivité Internet sortante. Pour activer la connectivité Internet sortante sur les machines virtuelles, vous devez ajuster votre configuration Standard Load Balancer.

Pour le trafic provenant de clients de l'interface utilisateur SAP qui se connectent à un serveur SAP via le protocole DIAG (Dynamic Information and Action Gateway) ou RFC, le serveur de messages des services centraux équilibre la charge via les groupes de connexion du serveur d’applications SAP. Aucun équilibreur de charge supplémentaire n’est nécessaire.

Stockage

Certains clients utilisent le stockage standard pour leurs serveurs d’applications. Étant donné que les disques managés standard ne sont pas pris en charge, nous vous recommandons d’utiliser azure Premium SSD ou Azure NetApp Files dans tous les scénarios. Une mise à jour récente de la note SAP 2015553 exclut l’utilisation du stockage HDD Standard Azure et du stockage SSD Standard Azure pour quelques cas d’usage spécifiques.

Dans la mesure où les serveurs d’applications n’hébergent pas de données métier, vous pouvez également utiliser les disques premium P4 et P6 de moins grande capacité pour gérer les coûts. Pour les applications SAP, nous vous recommandons vivement d’utiliser azure SSD v1, SSD v2 ou Ultra Disks. Pour comprendre comment le type de stockage affecte le contrat SLA de disponibilité des machines virtuelles, consultez les contrats SLA pour les services en ligne. Pour les scénarios de haute disponibilité, les fonctionnalités des disques partagés Azure sont disponibles sur les disques SSD Premium Azure et les disques de stockage Ultra. Pour plus d’informations, consultez disques managés Azure et types de disques managés Azure.

Vous pouvez utiliser des disques partagés Azure avec Windows Server, SLES 15 SP1 et versions ultérieures ou SLES pour SAP. Lorsque vous utilisez un disque partagé Azure dans des clusters Linux, le disque partagé Azure sert à isoler un appareil de bloc de nœuds défaillants. Il offre un vote de quorum dans un scénario de partitionnement de réseau de cluster. Ce disque partagé ne possède pas de système de fichiers et ne prend pas en charge les écritures simultanées à partir de plusieurs machines virtuelles membres du cluster.

Azure NetApp Files dispose de fonctionnalités intégrées de partage de fichiers pour NFS et SMB.

Pour les scénarios de partage NFS, Azure NetApp Files propose des partages haute disponibilité pour NFS qui peuvent être utilisés pour les volumes /hana/shared, /hana/data et /hana/log. Pour obtenir la garantie de disponibilité, consultez les contrats SLA pour les services en ligne. Si vous utilisez des partages NFS basés sur Azure NetApp Files pour les volumes /hana/data et /hana/log, vous devez utiliser le protocole NFS v4.1. Pour le volume /hana/shared, le protocole NFS v3 est pris en charge.

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 des moyens économiques de stocker les données durables rarement sollicitées. Envisagez également d’utiliser le niveau Azure NetApp Files Standard comme cible de sauvegarde ou l’option de sauvegarde Azure NetApp Files. Pour les disques managés, la couche de données de sauvegarde recommandée est le niveau d’accès froid ou d’archive d’Azure.

Le stockage sur disque Ultra et le niveau Ultra Azure NetApp Files réduisent considérablement la latence des disques et améliorent les performances des applications critiques et des serveurs de base de données SAP.

Ssd Premium v2 est conçu pour les charges de travail critiques en matière de performances telles que SAP. Pour plus d’informations sur les avantages et les limitations de cette solution de stockage, consultez Déployer un SSD Premium v2.

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 une plateforme de base de données de tout type, y compris SAP HANA, activez l’Accélérateur d’écriture pour le volume du fichier journal si vous utilisez un disque SSD Premium v1. Cette approche peut améliorer la latence d’écritures des journaux. Les disques SSD Premium v2 n’utilisent pas l’Accélérateur d’écriture. 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’hyper-threading, les instances de machines virtuelles comptant au minimum quatre processeurs virtuels prennent en charge Performances réseau accélérées.

Vous devez optimiser la pile TCP/IP Linux et les mémoires tampons dans l’interface réseau pour obtenir des performances cohérentes. Suivez les paramètres recommandés par Microsoft. Par exemple, vous allez ajuster les éléments tels que :

  • Paramètres du noyau pour optimiser les mémoires tampons de lecture et d’écriture
  • Contrôle de congestion de la bande passante du goulot d’étranglement et de la durée de propagation aller-retour (BBR)
  • Ajuster les paramètres TCP pour améliorer la cohérence et le débit
  • Mémoires tampons en anneau de carte d’interface réseau pour TX/RX

Pour plus d’informations sur les exigences de performances SAP HANA, consultez la note SAP 1943937.

Pour obtenir des opérations d’entrée/sortie élevées par seconde (IOPS) et un débit de bande passante de disque, suivez les pratiques courantes pour l’optimisation des performances du volume de stockage. Par exemple, la combinaison de plusieurs disques pour créer un volume de disque à bandes peut améliorer vos performances d’entrée/sortie (E/S). L’activation du cache de lecture sur le contenu de stockage qui change rarement peut également accélérer la récupération de vos données. Pour plus d’informations, consultez Configurations du stockage des machines virtuelles SAP HANA Azure.

Ssd Premium v2 est conçu pour les charges de travail critiques en matière de performances telles que SAP. Pour plus d’informations sur ses avantages, ses limitations et ses scénarios d’utilisation optimale, consultez les types de disques managés Azure.

Nouvelle génération de stockage, les disques de stockage Ultra sont conçus pour prendre en charge les opérations d’E/S par seconde intensives et les demandes de bande passante de transfert des applications telles que SAP HANA. Vous pouvez modifier dynamiquement les performances des disques Ultra et configurer indépendamment des métriques telles que les IOPS et les MBits/s sans redémarrer votre machine virtuelle. Nous vous recommandons d’utiliser le stockage sur disque Ultra au lieu de l’accélérateur d’écriture si possible.

Certaines applications SAP ont besoin de communiquer régulièrement avec la base de données. En raison de la distance, la latence réseau entre les couches d’application et de base de données peut affecter négativement les performances de l’application. Les groupes de placement de proximité Azure définissent une contrainte de placement pour les machines virtuelles déployées dans des groupes à haute disponibilité. Dans la construction logique d’un groupe, la colocalisation et les performances sont privilégiées par rapport à l’extensibilité, à la disponibilité et au coût. Les groupes de placement de proximité peuvent grandement améliorer l’expérience utilisateur pour la plupart des applications SAP.

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. L’appliance virtuelle réseau nécessite un temps important pour traiter les paquets de données. Il en résulte un ralentissement inacceptable des performances des applications.

Nous vous recommandons également de prendre en compte les performances lorsque vous déployez des ressources avec des zones de disponibilité, ce qui peut améliorer la disponibilité du service. Envisagez de créer un profil de latence réseau clair entre toutes les zones d’une région cible. Cette approche vous aidera à décider du placement des ressources pour une latence minimale entre les zones. Pour créer ce profil, exécutez un test en déployant de petites machines virtuelles dans chaque zone. Nous vous recommandons d’utiliser les outils PsPing et Iperf. Une fois le test terminé, supprimez ces machines virtuelles. Pour un outil de test de latence de réseau de domaine public que vous pouvez utiliser à la place, consultez le test de latence de zone de disponibilité.

Azure NetApp Files offre des fonctionnalités de performances uniques qui permettent le réglage en temps réel pour répondre aux besoins des environnements SAP les plus exigeants. Pour plus d’informations sur les performances lorsque vous utilisez Azure NetApp Files, consultez Dimensionnement pour la base de données HANA sur Azure NetApp Files.

Considérations relatives à l’extensibilité

Au niveau de la couche application SAP, Azure fournit un large éventail de tailles de machine virtuelle pour effectuer un scale-up et un scale-out. Pour obtenir une liste inclusive, consultez les applications SAP sur Azure : produits pris en charge et types de machines virtuelles Azure dans la note SAP 1928533. D’autres types de machines virtuelles sont continuellement certifiés. Vous pouvez donc effectuer un scale-up ou un scale-down dans le même déploiement cloud.

Sur la couche de base de données, cette architecture exécute des applications SAP S/4HANA sur des machines virtuelles Azure pouvant atteindre 24 téraoctets (To) dans une instance. Si votre charge de travail dépasse la taille maximale de la machine virtuelle, vous pouvez utiliser une configuration à plusieurs nœuds pour jusqu’à 96 TB (quatre instances de 24 To) pour les applications de traitement des transactions en ligne. Pour plus d’informations, consultez répertoire matériel SAP HANA certifié et pris en charge.

Considérations relatives à la disponibilité

La redondance des ressources constitue le thème général dans les solutions d’infrastructure à haute disponibilité. Pour connaître les contrats SLA de disponibilité de machine virtuelle à instance unique pour différents types de stockage, consultez les contrats SLA pour les services en ligne. Pour augmenter la disponibilité du service sur Azure, déployez des ressources de machine virtuelle à l’aide de Virtual Machine Scale Sets Azure, qui fournissent une orchestration flexible, des zones de disponibilité et des groupes à haute disponibilité.

Le modèle de déploiement des groupes à haute disponibilité régionaux Azure est une option prise en charge. Toutefois, nous vous recommandons d’adopter les ensembles de machines virtuelles avec le modèle avec zones de disponibilité pour les nouveaux déploiements SAP, afin d’améliorer la disponibilité et d’augmenter la flexibilité du déploiement.

Dans cette installation distribuée de l’application SAP, l’installation de base est répliquée pour obtenir la haute disponibilité. Pour chaque couche de l’architecture, la conception haute disponibilité varie.

Approches de déploiement

Sur 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 (une configuration de domaine d'erreur), les zones de disponibilité et les groupes à haute disponibilité, pour améliorer la disponibilité des ressources.

À mesure que les déploiements de clients sur Azure ont augmenté au fil des années, Microsoft a amélioré les modèles de déploiement de machines virtuelles Azure pour inclure des groupes de machines virtuelles identiques afin de garantir l’élasticité et la résilience du cloud. Compte tenu des options de déploiement disponibles, nous vous recommandons vivement d'utiliser le déploiement zonal avec des groupes identiques flexibles Azure pour tous les nouveaux déploiements. Pour plus d’informations sur le déploiement entre les zones, au sein d’une seule zone et dans les régions sans zones, consultez l’architecture et les scénarios de haute disponibilité pour SAP NetWeaver.

Web Dispatcher dans la couche Serveurs d’applications

Vous pouvez obtenir de la haute disponibilité à l’aide d’instances Web Dispatcher redondantes. Pour plus d’informations, consultez SAP Web Dispatcher. Le niveau de disponibilité dépend de la taille de l’application derrière Web Dispatcher. Dans les petits déploiements qui ont peu de problèmes d’extensibilité, vous pouvez colocaliser Web Dispatcher avec les machines virtuelles ASCS. Cette approche vous permet d’économiser sur une maintenance indépendante du système d’exploitation et d’obtenir de la haute disponibilité en même temps.

Services centraux dans la couche Serveurs d’applications

Pour la haute disponibilité des services centraux sur des machines virtuelles Linux Azure, utilisez l’extension haute disponibilité appropriée pour la distribution Linux sélectionnée. Il est habituel de placer les systèmes de fichiers partagés sur un stockage NFS hautement disponible à l’aide de l’appareil de bloc répliqué distribué SUSE ou de Red Hat GlusterFS. Pour fournir un NFS hautement disponible et éliminer la nécessité d’un cluster NFS, vous pouvez utiliser d’autres solutions rentables ou robustes comme NFS sur Azure Files ou Azure NetApp Files. Notez que les partages Azure NetApp Files peuvent héberger les données et fichiers journaux SAP HANA. Cette configuration permet au modèle de déploiement scale-out HANA avec des nœuds de secours, tandis que NFS sur Azure Files est approprié pour le partage de fichiers autres que de base de données hautement disponible.

NFS sur Azure Files prend désormais en charge les partages de fichiers hautement disponibles pour SLES et RHEL. Cette solution fonctionne bien pour les partages de fichiers hautement disponibles comme /sapmnt et /saptrans dans les installations SAP.

Azure NetApp Files prend en charge la haute disponibilité de ASCS sur SLES. Pour plus d’informations sur ASCS sur RHEL HA, consultez SIOS Protection Suite pour Linux.

L’agent de clôture Azure amélioré est disponible pour SUSE et Red Hat et fournit un basculement de service beaucoup plus rapide que la version précédente de l’agent.

Une autre option d’escrime consiste à utiliser des disques partagés Azure pour l’appareil d’escrime. Sur SLES 15 SP1 ou SLES pour SAP 15 SP1 et versions ultérieures, vous pouvez configurer un cluster Pacemaker à l’aide de disques partagés Azure. Cette option est simple et ne nécessite pas de port réseau ouvert comme l’agent de clôture Azure.

Une configuration Pacemaker récemment prise en charge et plus simple sur SLES 15 et versions ultérieures est HA SAP NetWeaver avec montage simple et NFS sur SLES pour les machines virtuelles applications SAP. Dans cette configuration, les partages de fichiers SAP sont retirés de la gestion du cluster, ce qui simplifie son fonctionnement. Utilisez cette configuration de haute disponibilité pour tous les nouveaux déploiements.

Pour gérer davantage les coûts d’un grand paysage SAP, le cluster Linux prend en charge l’installation multi-SID ASCS sur Azure. Le partage d’un cluster de disponibilité entre plusieurs systèmes SAP simplifie le paysage SAP et réduit les coûts d’exploitation.

Sur Standard Load Balancer, vous pouvez activer le port haute disponibilité et éviter d’avoir à configurer des règles d’équilibrage de charge pour de nombreux ports SAP. En général, si vous activez la fonctionnalité de retour de serveur direct (DSR) lorsque vous configurez un équilibreur de charge, les réponses du serveur aux demandes clientes peuvent contourner l’équilibreur de charge. Cette fonctionnalité est également connue sous le nom d’adresse IP flottante. L’équilibreur de charge peut être local ou résider sur Azure. Cette connexion directe empêche l’équilibreur de charge de devenir le goulot d’étranglement dans le chemin de transmission des données. Pour les clusters de base de données ASCS et HANA, nous vous recommandons d’activer DSR. Si les machines virtuelles du pool principal nécessitent une connectivité sortante publique, une configuration supplémentaire est requise.

Pour le trafic en provenance de clients SAP GUI se connectant à un serveur SAP via le protocole DIAG ou RFC, le serveur de messages des services centraux équilibre la charge en utilisant des groupes de connexion des serveurs d’applications SAP. Aucun équilibreur de charge supplémentaire n’est nécessaire.

Serveurs d’applications dans la couche Serveurs d’applications

Vous pouvez obtenir la haute disponibilité en équilibrant le trafic au sein d’un pool de serveurs d’applications.

Couche base de données

L’architecture de ce guide décrit un système de base de données SAP HANA hautement disponible qui se compose de deux machines virtuelles Azure. La fonctionnalité de réplication du système natif de la couche Base de données assure un basculement manuel ou automatique entre les nœuds répliqués.

  • Pour le basculement manuel, déployez plusieurs instances HANA et utilisez la fonctionnalité HSR.

  • Pour le basculement automatique, utilisez les fonctionnalités HSR et Linux HA (extension de haute disponibilité) pour votre distribution Linux. Linux HAE fournit des services de cluster pour les ressources HANA, détecte les événements d’échec et orchestre le basculement des services défectueux vers un nœud sain.

Déployer des machines virtuelles entre plusieurs zones de disponibilité

Les zones de disponibilité peuvent améliorer la disponibilité du service. Les zones font référence à des emplacements physiquement séparés au sein d’une région Azure spécifique. Elles améliorent la disponibilité des charges de travail et protègent les services d’applications et machines virtuelles en cas de pannes du centre de données. Les machines virtuelles d’une seule zone sont traitées comme si elles se trouvent dans un domaine de mise à jour ou d’erreur unique. 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 et de mise à niveau de manière optimale.

Dans les régions Azure qui prennent en charge cette fonctionnalité, un minimum de trois zones sont disponibles. La distance maximale entre les centres de données de ces zones n’est pas garantie. Pour déployer un système SAP à plusieurs niveaux sur plusieurs zones, vous devez connaître la latence du réseau au sein d’une zone et entre les zones ciblées et la sensibilité de vos applications déployées à la latence 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 ;
  • Disponibilité des mêmes services Azure ou types de machines virtuelles dans les zones choisies

Remarque

Les zones de disponibilité sont déconseillées pour la reprise d'activité. Un site de récupération d’urgence doit être d’au moins 100 km du site principal pour tenir compte des catastrophes naturelles. La distance exacte entre les centres de données ne peut pas être garantie.

Exemple de déploiement actif/passif

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é. Elles sont activées uniquement si nécessaire.

Les clusters à deux nœuds pour les services centraux et la 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. Avec tous les composants de ce système SAP colocalisés dans la même zone, la latence 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 sont actifs. En conséquence, il existe des serveurs d’applications actifs dans les deux zones dans le cadre des opérations normales.

Les services ASCS et de base de données sont exécutés dans la zone 1. Les serveurs d’applications de la zone 2 peuvent avoir une latence réseau plus longue lorsqu’ils se connectent aux services ASCS et de base de données en raison de la distance physique entre les zones.

Si la zone 1 est mise hors connexion, les services ASCS et 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 obtenir des informations sur les stratégies de récupération d’urgence et l’implémentation, consultez la vue d’ensemble de la récupération d’urgence et les instructions d’infrastructure pour les charges de travail SAP et les instructions de récupération d’urgence pour les applications SAP.

Remarque

S’il existe une catastrophe régionale qui provoque un événement de basculement en masse pour de nombreux clients Azure dans une région, la capacité de ressource de la région cible n’est pas garantie. Comme tous les services Azure, Site Recovery continue à ajouter des fonctionnalités. Pour obtenir les informations les plus récentes sur la réplication Azure vers Azure, consultez la matrice de prise en charge.

Afin de garantir la capacité de ressource disponible pour une région de reprise d'activité, utilisez une réservation de capacité à la demande. Azure vous permet de combiner votre réduction sur les instances réservées et votre réservation de capacité pour réduire les coûts.

Considérations relatives aux coûts

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

Pour plus d’informations, consultez l’optimisation des coûts d’Azure Well-Architected Framework.

Machines virtuelles

Cette architecture utilise des machines virtuelles qui exécutent Linux pour la gestion, l’application SAP et les couches Base de données.

Il existe plusieurs options de paiement pour les machines virtuelles :

  • Pour les charges de travail qui n’ont pas de temps prédictible d’achèvement ou de consommation de ressources, envisagez l’option paiement à l’utilisation.

  • Envisagez d’utiliser des réservations Azure si vous pouvez vous engager à utiliser une machine virtuelle sur une période d’un an ou de trois ans. Les réservations de machines virtuelles peuvent réduire considérablement les coûts. Vous pouvez économiser jusqu'à 72% par rapport aux options de paiement à l’utilisation.

  • Utilisez des machines virtuelles Spot Azure pour exécuter des charges de travail qui peuvent être interrompues et ne nécessitent pas d’achèvement dans un délai prédéterminé ou 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 des machines virtuelles Spot sont inférieurs aux 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.

Pour obtenir une vue d’ensemble de la tarification, consultez la tarification des machines virtuelles Linux.

Équilibreur de charge

Dans ce scénario, les équilibreurs de charge Azure servent à distribuer le trafic vers les machines virtuelles du sous-réseau de la couche Application.

Vous n'êtes facturé que pour le nombre de règles de trafic sortant et d'équilibrage de la charge configurées. Les règles de 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 le Tarification ExpressRoute.

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. L’expérience de déploiement guidée des solutions Azure Center pour SAP crée les composants de calcul, de stockage et de mise en réseau nécessaires pour exécuter votre système SAP. Vous pouvez ensuite automatiser l’installation du logiciel SAP en fonction des 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.

Backup (Sauvegarder)

Vous pouvez sauvegarder des données SAP HANA de plusieurs façons. Après avoir migré vers Azure, continuez à utiliser les solutions de sauvegarde existantes dont vous disposez. Azure fournit deux approches natives de la sauvegarde. Vous pouvez sauvegarder SAP HANA sur des machines virtuelles ou utiliser Sauvegarde Azure au niveau du fichier. Sauvegarde Azure est certifiée Backint par SAP. Pour plus d’informations, consultez la FAQ sur le service Sauvegarde Azure et Matrice de prise en charge pour la sauvegarde des bases de données SAP HANA sur des machines virtuelles Azure.

Remarque

Seuls les déploiements de type conteneur unique ou en montée en charge HANA prennent en charge les captures instantanées de stockage Azure.

Gestion des identités

Utilisez un système de gestion des identités centralisé pour contrôler l’accès aux ressources à tous les niveaux.

Supervision

Pour optimiser la disponibilité et les performances des applications et des services sur Azure, utilisez Azure Monitor. Le service Azure Monitor est une solution complète pour la collecte, l’analyse et l’exploitation de 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 dispose de son propre moteur de gestion des utilisateurs pour contrôler l’accès et l’autorisation en fonction du rôle au sein de l’application et des bases de données SAP. Pour plus d’informations, consultez la vue d’ensemble de la sécurité SAP HANA.

Pour renforcer la sécurité réseau, songez à utiliser un réseau de périmètre, qui tire parti d’une appliance virtuelle réseau (NVA) pour créer un pare-feu devant le sous-réseau de Web Dispatcher. Pour réduire les coûts de transfert de données, déployez des serveurs frontaux actifs qui hébergent des applications Fiori au sein du même réseau virtuel que les systèmes S/4. Vous pouvez également configurer ces serveurs frontaux dans le réseau de périmètre, qui tirent parti du peering de réseaux virtuels pour établir la connectivité avec les systèmes S/4.

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 qui s’applique à S/4HANA, consultez Sécurité pour votre paysage SAP.

Pour chiffrer les disques de machines virtuelles Linux, vous avez plusieurs options. Pour le chiffrement de données au repos SAP HANA, nous vous recommandons d’utiliser la technologie de chiffrement native SAP HANA. Pour la prise en charge du chiffrement de disque Azure sur des distributions, versions et images Linux spécifiques, consultez Azure Disk Encryption pour machines virtuelles Linux.

Remarque

N’utilisez pas le chiffrement de données au repos HANA et Azure Disk Encryption sur le même volume de stockage. Pour HANA, utilisez le chiffrement des données HANA plutôt que le chiffrement côté serveur du stockage de disque Azure. L’utilisation de clés gérées par le client peut affecter le débit d’E/S.

Communautés

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

Contributeurs

Microsoft gère cet article. Les contributeurs suivants ont écrit cet article.

Auteur 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 des mêmes technologies que cette architecture, consultez les articles suivants :