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 on HANA dans un environnement à haute disponibilité prenant en charge la récupération d’urgence (DR) sur Azure. Les informations concernant Fiori ne s’appliquent qu’aux applications S/4HANA.

Architecture

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

Ce guide décrit un système de production courant. Cette architecture est déployée avec des tailles de machine virtuelle que vous pouvez modifier en fonction des besoins de votre organisation. Pour répondre aux besoins de votre entreprise, vous pouvez réduire cette configuration à 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.

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

Réseau virtuel Azure. Le service Réseau virtuel connecte en toute sécurité les ressources Azure entre elles. 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 appairé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 façon transparente via le réseau principal Microsoft et n’affecte pas les performances s’il est implémenté dans une seule région. Des sous-réseaux distincts sont utilisés pour chaque couche : Application (SAP NetWeaver), Base de données et Services partagés (tels que le serveur de rebond et Windows Server Active Directory).

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

• Couche 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 assurer la haute disponibilité des services centraux sur Azure s’exécutant dans des machines virtuelles Linux, un service de partage de fichiers en réseau hautement disponible est nécessaire, tels que les partages de fichiers NFS dans Azure Files, Azure NetApp Files, les serveurs Network File System (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 sur SLES pour applications SAP, vous pouvez utiliser des disques partagés Azuresur un cluster Pacemaker afin d’obtenir une haute disponibilité.

• SAP HANA. La couche Base de données utilise au moins deux machines virtuelles Linux dans un cluster pour assurer la haute disponibilité dans un déploiement avec montée en puissance parallèle. 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. Un mécanisme d’isolation basé sur le stockage ou sur le cloud doit être utilisé pour s’assurer que le système défaillant est isolé ou arrêté pour éviter la condition de division (Split-Brain) du cluster. Dans les déploiements de scale-out HANA, vous pouvez obtenir une haute disponibilité de base de données à l’aide de 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 via le client SSH ou RDP natif déjà installé sur votre ordinateur local. Si seuls les clients RDP et SSH sont utilisés à des fins d’administration, 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 Azure Standard Load Balancer. Veuillez noter que Standard Load Balancer fournit un haut niveau 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 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.
• Services réseau dont vous avez besoin, tels qu’une terminaison SSL (Secure Sockets Layer).

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 incluent ces composants :

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

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

Standard Load Balancer prend également en charge les clusters SAP à identificateurs multi-systèmes (multi-SID). En d’autres termes, plusieurs systèmes SAP sur SLES ou RHEL peuvent partager une infrastructure de 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 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). S/4HANA offre 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.

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 la création de connexions privées qui ne passent pas par l’Internet public. Vous pouvez également utiliser une connexion site à site. Les options de connectivité ExpressRoute Global Reach et ExpressRoute FastPath décrites plus loin dans cet article permettent de réduire la latence.

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 VNet redondantes interzone à des fins de résilience plutôt qu’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é privilégie la colocation, car elle place les machines virtuelles dans le même centre de données afin de réduire la latence des applications.

Groupes de sécurité réseau. Pour limiter le trafic entrant, sortant et intra-sous-réseau dans un réseau virtuel, vous pouvez créer 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, 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 recommandons les 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 obtenir des informations détaillées sur l’exécution de SAP NetWeaver sur des machines virtuelles, consultez le guide de planification et d’implémentation de machines virtuelles Azure. Le guide s’applique également aux déploiements SAP S/4HANA.

Pour plus d’informations sur la prise en charge SAP en fonction des types de machines virtuelles Azure et les 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. Pour obtenir la liste des machines virtuelles Azure certifiées pour la base de données HANA, consultez le répertoire SAP Certified and Supported SAP HANA Hardware (Matériel SAP HANA certifié et pris en charge par SAP).

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 sur Internet, une solution autonome dans le réseau de périmètre est l’architecture recommandée 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.

Fiori Front-end Server (FES)

Cette architecture répond à de nombreuses exigences et suppose l’utilisation du modèle Fiori FES incorporé. Tous les composants technologiques étant installés sur le système S/4 lui-même, chaque système S/4 dispose de son propre Fiori Launchpad. La haute disponibilité pour ce modèle de déploiement est assurée par le système S/4 : aucun clustering ni aucune machine virtuelle supplémentaire n’est requis. Pour cette raison, le diagramme d’architecture n’affiche pas le composant FES.

Pour obtenir une description des options de déploiement principales (incorporé ou sous forme de hub), consultez SAP Fiori Deployment Options and System Landscape Recommendations (Options de déploiement de SAP Fiori et recommandations relatives à l’infrastructure 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. Il en résulte que les déploiements sous forme de hub ne sont adaptés qu’à quelques cas d’usage restreints.

Si vous choisissez de déployer FES sous forme de hub, FES est un composant additionnel de la pile ABAP SAP NetWeaver classique. Vous configurez la haute disponibilité de la même façon que vous protégez une pile d’applications ABAP à trois niveaux avec des fonctionnalités en cluster ou multi-hôtes : utilisez une couche Base de données de type serveur de secours, une couche ASCS en cluster avec un NFS à haute disponibilité 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 Azure Web Application Firewall sur Application Gateway comme composant essentiel contre les menaces. Utilisez Microsoft Entra ID avec SAML pour l’authentification utilisateur et l’authentification unique pour SAP Fiori.

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

Pool de serveurs d’applications

Pour gérer les groupes de connexion des serveurs d’application ABAP, il est courant d’utiliser la transaction SMLG pour la répartition de la charge des utilisateurs connectés, d’utiliser SM61 pour les groupes de serveurs par lots, d’utiliser RZ12 pour les groupes d’appels de fonction à distance (RFC), etc. Ces transactions utilisent la capacité d’équilibrage des charges du serveur de messages des services centraux pour répartir les sessions ou les charges de travail entrantes entre les serveurs d’applications SAP qui traitent les interfaces graphiques SAP et le trafic RFC.

Cluster des services centraux 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. Dans ce cas, la machine virtuelle devient toutefois un point de défaillance unique (SPOF) potentiel pour l’environnement SAP. Pour déployer des services centraux hautement disponibles, utilisez NFS sur Azure Files ou le service Azure NetApp Files et un cluster de services centraux.

Pour obtenir une haute disponibilité, vous pouvez également utiliser des disques partagés Azure. Sur SLES 15 SP1 et versions ultérieures, ou sur SLES pour applications SAP, vous pouvez configurer un cluster Pacemaker à l’aide de disques partagés Azure pour Linux.

Vous pouvez également utiliser un partage de fichiers NFS pour le stockage partagé du cluster Linux.

Sur un déploiement Azure, les serveurs d’applications se connectent aux services centraux hautement disponibles via les noms d’hôte virtuel des services centraux ou des services 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 services centraux et les adresses IP ERS peuvent être configurés à un équilibreur de charge.

Les installations multi-SID ASCS dans les clusters Linux sur Azure sont désormais en disponibilité générale. Le partage d’un cluster de disponibilité entre plusieurs systèmes SAP simplifie le paysage SAP.

Mise en réseau

Cette architecture utilise une topologie hub-and-spoke, où le hub du réseau virtuel centralise la 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 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. Par conséquent, il est inutile d’utiliser plusieurs cartes réseau dans une optique d’optimisation des performances. Toutefois, si votre organisation a besoin de séparer le trafic, vous pouvez déployer plusieurs cartes réseau par machine virtuelle, connecter chaque carte réseau à un sous-réseau différent, puis utiliser des groupes de sécurité réseau pour appliquer des stratégies de contrôle d’accès distinctes.

Les cartes d’interface réseau Azure prennent en charge plusieurs adresses IP. Ce support est conforme à la pratique recommandée par SAP consistant à utiliser des noms d’hôtes virtuels pour les installations, comme indiqué dans 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 itinéraires ExpressRoute, ExpressRoute Global Reach peut vous permettre de diminuer le nombre de tronçons du réseau et de réduire la latence. Cette technologie désigne un peering de routes BGP (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 plus d’un itinéraire ExpressRoute. Global Reachest est actuellement disponible uniquement pour le peering privé sur les circuits ExpressRoute.

Pour le moment, 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 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 et améliore les performances de l’application. Il s’agit de 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 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 toujours envoyé vers la passerelle du réseau virtuelle. La solution de contournement consiste à connecter tous les réseaux virtuels directement au circuit ExpressRoute.

É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 offre 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. 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 Azure Standard Load Balancer pour tous les scénarios SAP. Il est important de préciser que Standard Load Balancer est sécurisé par défaut et aucune machine virtuelle située derrière celui-ci n’a de connectivité Internet sortante. Pour activer la connectivité Internet sortante sur les machines virtuelles, vous devez ajuster votre configuration Standard Load Balancer.

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. Aucun équilibreur de charge supplémentaire n’est nécessaire.

Stockage

Certains clients utilisent le stockage standard pour leurs serveurs d’applications. Les disques managés standard n’étant pas pris en charge (comme stipulé dans la note SAP 1928533), nous vous recommandons d’utiliser dans tous les cas des disques managés Azure premium ou Azure NetApp Files. 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.

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 comprendre comment le type de stockage affecte le contrat SLA de disponibilité de machine virtuelle, consultez Contrat de niveau de service pour Machines Virtuelles. Pour les scénarios 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.

Vous pouvez utiliser des disques partagés Azure avec Windows Server, SLES 15 SP 1 et versions ultérieures ou SLES pour SAP. Lorsque vous utilisez un disque partagé Azure dans des clusters Linux, le disque partagé Azure sert d’appareil de bloc STONITH (SBD). Il offre un vote de quorum dans une situation 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 NFS qui peuvent être utilisés pour les volumes /hana/shared, /hana/data et /hana/log. Pour connaître la garantie de disponibilité, consultez le contrat SLA pour Azure NetApp Files. 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. Vous pouvez aussi envisager d’utiliser Azure NetApp Files - niveau standard comme cible de sauvegarde ou Azure NetApp Files - option de sauvegarde. 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.

Les disques de stockage Ultra et le niveau de performance ultra d’Azure NetApp Files réduisent de façon considérable la latence des disques, et bénéficient aux applications critiques pour les performances et aux serveurs de base de données SAP.

Les disques Azure SSD Premium v2 sont conçus pour les charges de travail critiques en matière de performances telles que SAP. Consultez Déployer un disque SSD Premium v2 pour plus d’informations sur les avantages et les limitations actuelles de cette solution de stockage.

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. Cela 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’hyperthreading, les instances de machines virtuelles comptant au minimum quatre processeurs virtuels prennent en charge Performances réseau accélérées.

Pour plus d’informations sur les exigences en termes de performances de SAP HANA, consultez la note SAP 1943937, « Hardware Configuration Check Tool » (Outil de vérification de la configuration matérielle). Pour accéder aux notes SAP, vous devez disposer d’un compte SAP Service Marketplace.

Pour obtenir un débit de bande passante de disque et d’ES/S élevé, les pratiques courantes en termes d’optimisation des performances du volume de stockage s’appliquent à la disposition de votre espace de stockage Azure. Par exemple, si vous associez plusieurs disques pour créer un volume de disque agrégé par bandes, vous pouvez améliorer les performances d’E/S. En activant le cache de lecture sur un contenu de stockage qui change rarement, vous pouvez améliorer la vitesse d’extraction de données. Pour obtenir des recommandations sur les configurations de stockage de différentes tailles de machine virtuelle lorsque vous exécutez SAP HANA, consultez Configurations de stockage des machines virtuelles Azure SAP HANA.

Les disques Azure SSD Premium v2 sont conçus pour les charges de travail critiques en matière de performances telles que SAP. Consultez Types de disques managés Azure pour en savoir plus sur leurs avantages et leurs limitations, ainsi que sur les scénarios d’utilisation optimale.

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 les métriques comme les E/S par seconde et les Mo/s sans redémarrer votre machine virtuelle. Lorsque des disques de stockage Ultra sont disponibles, nous vous recommandons de les préférer à Accélérateur d’écriture.

Certaines applications SAP ont besoin de communiquer régulièrement avec la base de données. La latence du réseau entre les couches Application et Base de données, en raison de la distance, peut nuire aux 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é. Au sein de la construction logique d’un groupe, la colocation et les performances sont privilégiées par rapport à l’évolutivité, la disponibilité et le coût. Les groupes de placement de proximité peuvent grandement améliorer l’expérience utilisateur pour la plupart des applications SAP. Pour les scripts et les utilitaires disponibles sur GitHub pour les groupes de placement de proximité, consultez Groupes de placement de proximité Azure.

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 tenir compte des performances lorsque vous déployez des ressources avec des zones de disponibilité, lequel peut améliorer la disponibilité du service, comme décrit plus loin dans cet article. Vous pouvez envisager de créer un profil de latence du 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 obtenir un outil de test de latence réseau du domaine public que vous pouvez utiliser à la place, consultez Test de latence de zone de disponibilité.

Azure NetApp Files offre des fonctionnalités de performances uniques rendant possible une optimisation en temps réel qui répond aux besoins des environnements SAP les plus exigeants. Pour connaître les considérations relatives aux performances à garder à l’esprit lorsque vous utilisez Azure NetApp Files, consultez Dimensionnement de la base de données HANA sur Azure NetApp Files.

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 « SAP Applications on Azure: Supported Products and Azure VM Types » (Applications SAP sur Azure : produits et types de machines virtuelles pris en charge) dans la note SAP 1928533. Pour accéder aux notes SAP, vous devez disposer d’un compte SAP Service Marketplace. 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.

Dans la couche Base de données, cette architecture exécute les applications SAP HANA S/4 sur des machines virtuelles Azure pouvant effectuer un scale-up à 24 To dans une instance. Si votre charge de travail dépasse la taille maximale des machines virtuelles, vous pouvez utiliser une configuration à plusieurs nœuds pour atteindre 96 To (4 x 24) pour les applications OLTP (Online Transaction Processing, traitement transactionnel en ligne). Pour plus d’informations, consultez le répertoire Certified and Supported SAP HANA Hardware (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 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é.

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.

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 (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.

Web Dispatcher dans la couche Serveurs d’applications

Vous pouvez obtenir une haute disponibilité à l’aide d’instances Web Dispatcher redondantes. Pour plus d’informations, consultez SAP Web Dispatcher dans la documentation SAP. Le niveau de disponibilité dépend de la taille de l’application derrière Web Dispatcher. Dans les petits déploiements avec peu de problèmes d’extensibilité, vous pouvez mutualiser Web Dispatcher avec les machines virtuelles ASCS. De cette façon, vous économisez sur la maintenance indépendante du système d’exploitation et vous bénéficiez de la haute disponibilité simultanément.

Services centraux dans la couche Serveurs d’applications

Pour bénéficier de la haute disponibilité des services centraux sur des machines virtuelles Linux Azure, utilisez l’extension de 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 SUSE DRBD ou 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 à la place. Par ailleurs, 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 ceux de /sapmnt et /saptrans dans les installations SAP.

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

La version améliorée de l’agent de délimitation Azure est disponible pour SUSE et Red Hat, et fournit un basculement de service beaucoup plus rapide que la version précédente.

Pour obtenir une haute disponibilité, vous pouvez également utiliser des disques partagés Azure. Sur SLES 15 SP 1 et ultérieur ou SLES pour SAP, vous pouvez configurer un cluster Pacemaker à l’aide de disques partagés Azure pour bénéficier de la haute disponibilité.

Sur Standard Load Balancer, vous pouvez activer le port haute disponibilité sans avoir à configurer des règles d’équilibrage de charge pour plusieurs 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 appelée 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 SAP ASCS et base de données, nous vous recommandons d’activer DSR (retour direct du serveur). Si les machines virtuelles du pool back-end 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 la charge du trafic au sein d’un pool de serveurs d’applications.

Niveau ASCS

Comme avec la couche Serveurs d’applications, la solution à haute disponibilité HANA couramment déployée pour Linux est Pacemaker.

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 HAE (extension de haute disponibilité) pour votre distribution Linux. Linux HAE fournit des services de cluster aux ressources HANA, détectant les événements d’échec et orchestrant le basculement des services errants vers le 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 même zone sont traitées comme si elles se trouvaient dans le même domaine de mise à jour ou 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 et de mise à niveau de manière optimale.

Dans les régions Azure qui prennent en charge cette fonctionnalité, 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 à plusieurs niveaux dans plusieurs zones, vous devez connaître la latence du réseau dans une zone et dans les zones ciblées, ainsi que la sensibilité de vos applications déployées en lien avec 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/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é. Ils sont activés uniquement quand ils sont nécessaires.

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. Tous les composants de ce système SAP étant 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 groupe de serveurs sont inactifs (à l’arrêt). 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 présenter 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 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 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.

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 en général :

• Pour les charges de travail sans temps de réalisation prévisible ou la consommation des ressources, envisagez l’option de 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 sur cette offre, consultez Azure Reserved Virtual Machine Instances.

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

Load Balancer

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 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.

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.

Sauvegarde

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 que vous possédez. 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 bénéficie de la certification 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.

Gestion des identités

Utilisez un système centralisé de gestion des identités 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 via le protocole LDAP (Lightweight Directory Access Protocol), Microsoft Entra ID, Kerberos ou un autre système.

• Prenez en charge l’accès dans les applications elles-mêmes via les services fournis par SAP ou utilisez 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 l’autorisation en fonction du rôle dans les applications et bases de données SAP. Pour plus d’informations, consultez SAP HANA Security: An Overview (Sécurité SAP HANA - Présentation).

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. Le coût du transfert des données est une raison de placer les serveurs frontaux actifs qui exécutent les applications Fiori dans le même réseau virtuel que les systèmes S/4. L’alternative consiste à les placer dans le réseau de périmètre et à les connecter à S/4 via un appairage de réseaux virtuels.

Afin de garantir la sécurité de l’infrastructure, les données sont chiffrées en transit et au repos. La section « Considérations de sécurité » du guide SAP NetWeaver on Azure Virtual Machines0 – Planning and Implementation Guide (SAP NetWeaver sur les machines virtuelles Azure - Guide de planification et d’implémentation) aborde la question de la sécurité réseau appliquée à S/4HANA. Ce guide spécifie également les ports réseau à ouvrir sur les pare-feu pour autoriser la communication de l’application.

Pour chiffrer les disques de machines virtuelles Linux, vous avez le choix entre plusieurs options, comme décrit dans Vue d’ensemble du chiffrement de disque. Pour le chiffrement des données SAP HANA au repos, 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 Chiffrement de disque Azure pour les machines virtuelles Linux.

Pour le chiffrement des données SAP HANA au repos, nous vous recommandons d’utiliser la technologie de chiffrement native SAP HANA.

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 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 :

• Déploiement de SAP S/4HANA ou BW/4HANA sur Azure
• 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