Modifier

Partager via

Exécuter SAP BW/4HANA avec des machines virtuelles Linux sur Azure

Azure Bastion
Azure Disques managés
Machines virtuelles Azure
Réseau virtuel Azure
SAP HANA sur Azure (grandes instances)

L’exemple suivant se concentre spécifiquement sur la couche application SAP BW/4HANA. Elle convient à un environnement de production à petite échelle de SAP BW/4HANA sur Azure où la haute disponibilité est une priorité.

Architecture

L’architecture de référence présente un ensemble de pratiques éprouvées pour l’exécution de SAP HANA dans un environnement de scale-up à haute disponibilité prenant en charge la reprise d’activité après sinistre sur Azure.

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

Composants

Cette architecture utilise les technologies suivantes :

  • réseau virtuel Azure connecte en toute sécurité les ressources Azure entre elles et à un environnement local. Dans cette architecture, plusieurs réseaux virtuels sont appairés.

  • Les machines virtuelles Linux sont utilisées pour la couche application, notamment :

    • Le pool de serveurs SAP BusinessObjects (BOBJ).
    • Le pool SAP Web Dispatcher.
    • Le pool de serveurs d’applications.
    • Le cluster des services centraux SAP.

  • Les équilibreurs de charge dirigent le trafic vers les machines virtuelles du sous-réseau d’application. Pour la haute disponibilité, cet exemple utilise SAP Web Dispatcher et Azure Standard Load Balancer. Ces deux services prennent également en charge l’extension de capacité par montée en charge. Vous pouvez aussi utiliser Azure Application Gateway ou d’autres produits partenaires, en fonction du type de trafic et des fonctionnalités dont vous avez besoin, comme la terminaison et le transfert SSL (Secure Sockets Layer).

  • Les Groupes de sécurité réseau (NSG) sont joints à un sous-réseau ou à des cartes d’interface réseau (NIC) sur une machine virtuelle. Les groupes de sécurité réseau (NSG) sont utilisés pour limiter le trafic entrant, sortant et intra-sous-réseau dans le réseau virtuel.

  • Azure Bastion fournit un accès sécurisé par le biais du portail Azure aux machines virtuelles qui s’exécutent dans Azure, sans utiliser de jumpbox ni son adresse IP publique associée. Ce mécanisme limite l’exposition accessible via Internet.

  • Les disques managés Azure Premium ou Ultra storage sont recommandés. Ces types de stockage assurent la persistance des données pour les machines virtuelles avec la charge de travail SAP.

  • Azure NetApp Files prend en charge le stockage partagé lors de l’utilisation d’un cluster. Il prend également en charge le stockage partagé lorsque vous avez besoin d’un stockage à hautes performances qui peut héberger des données et des fichiers journaux SAP HANA. Azure NetApp Files est entièrement managé et suffisamment scalable pour répondre aux besoins de la plupart des applications. La solution offre des performances complètes, une latence inférieure à la milliseconde et la gestion des données intégrées pour vos charges de travail d’entreprise complexes sur :

    • SAP HANA.
    • Calcul haute performance.
    • Applications métiers.
    • Partages de fichiers hautes performances.
    • Infrastructure de bureau virtuel.

  • Power BI permet aux utilisateurs d’accéder aux données SAP BW/4HANA et de les visualiser depuis leur bureau Windows. L’installation requiert le connecteur SAP BW (implémentation 2.0).

    Microsoft Power BI Desktop importe des données à partir de diverses sources SAP, telles que SAP BW/4HANA, à des fins d’analyse et de visualisation. Power BI complète également l’univers SAP BusinessObjects en apportant un contexte métier ou une couche sémantique sur les informations brutes.

  • Sauvegarde Azure est une solution de protection des données SAP certifiée Backint pour SAP HANA dans des déploiements à instance unique et avec montée en puissance parallèle. Sauvegarde Azure protège également les machines virtuelles Azure exécutant des charges de travail générales.

  • Azure Site Recovery est recommandé dans le cadre d’une solution de récupération d’urgence automatisée pour un déploiement d’applications SAP NetWeaver à plusieurs niveaux. La matrice de prise en charge détaille les fonctionnalités et les restrictions de cette solution.

Autres solutions

  • Pour aider à protéger les fichiers d’hôte global SAP des services centraux SAP et du répertoire de transport SAP, vous pouvez déployer des serveurs Network File System (NFS) dans une configuration de cluster de basculement.

  • SIOS Protection Suite, disponible dans la Place de marché Microsoft Azure, peut être utilisé pour protéger les fichiers d’hôte global des services centraux à la place de NFS ou Azure NetApp Files.

  • Azure Application Gateway est un équilibreur de charge de trafic web. Dans un service, il offre une terminaison SSL, un Web Application Firewall (WAF) et d’autres fonctionnalités pratiques de haute disponibilité et d’extensibilité. Certains déploiements SAP l’ont utilisé comme passerelle pour le frontal SAP Fiori dans leur environnement de production.

Détails du scénario

SAP BW/4HANA est une solution d’entrepôt de données d’entreprise conçue pour le cloud et optimisée pour la plateforme SAP HANA. L’exemple suivant se concentre spécifiquement sur la couche application SAP BW/4HANA. Elle convient à un environnement de production à petite échelle de SAP BW/4HANA sur Azure où la haute disponibilité est une priorité.

Cet exemple de charge de travail s’appuie également sur deux architectures de référence SAP sur Azure : SAP NetWeaver (Windows) pour AnyDB sur machines virtuelles et SAP S/4HANA pour les machines virtuelles Linux sur Azure. Une approche de déploiement similaire est utilisée pour les charges de travail SAP BW/4HANA. La couche application est déployée à l’aide de machines virtuelles pouvant être modifiées en fonction des besoins de votre organisation.

L’organisation du réseau a été simplifiée pour illustrer les principes architecturaux recommandés pour un déploiement Azure Enterprise basé sur une topologie hub-and-spoke.

Notes

De nombreuses considérations relatives au déploiement s’appliquent lors du déploiement de charges de travail SAP sur Azure. Pour plus d’informations et pour plus d’informations, consultez la liste de vérification relative à la planification et au déploiement de SAP sur Azure.

Pour plus d’informations sur la couche de persistance des données, consultez :

Cas d’usage potentiels

Ce scénario est approprié pour les cas d’usage suivants :

  • Déploiement de la couche Application SAP distinct de la couche SGBD

  • Scénarios de récupération d’urgence (DR)

  • Déploiements de la couche Application SAP

Recommandations

Cette architecture est conçue pour la haute disponibilité, la scalabilité et la résilience. Pour obtenir les meilleurs résultats sur Azure, tenez compte des recommandations de cette section. En outre, un grand nombre des recommandations relatives à l’exécution de SAP S/4HANA sur Azure s’appliquent également aux déploiements SAP BW/4HANA. Pour plus d’informations concernant SAP S/4HANA sur Azure, consultez l’architecture de référence.

Machines virtuelles

Pour plus d’informations sur la prise en charge SAP des types de machines virtuelles Azure et des métriques de débit (SAPS), consultez la note SAP 1928533, « SAP Applications on Azure: Supported Products and Azure Virtual Machine Types ». (Pour accéder à cette note et à d’autres notes SAP, vous devez avoir un compte SAP Service Marketplace.)

Pour savoir si un type de machine virtuelle est certifié pour les déploiements SAP HANA avec scale-out, consultez le répertoire de matériel SAP HANA.

Pool de serveurs d’applications

Dans les pools de serveurs d’applications, vous pouvez ajuster le nombre de machines virtuelles en fonction de vos besoins. Azure est certifié pour l’exécution de SAP BW/4HANA sur Red Hat Enterprise Linux et SUSE Linux Enterprise.

Pour gérer les groupes de connexion pour les serveurs d’applications ABAP, il est courant d’utiliser la transaction SMLG pour équilibrer la charge de différents groupes, tels que :

  • Les utilisateurs qui ouvrent une session.
  • SM61 pour les groupes de serveurs par lot.
  • RZ12 pour les groupes RFC.

Ces transactions utilisent la fonctionnalité d’équilibrage de charge au sein du serveur de messages des services centraux pour répartir les sessions entrantes ou la charge de travail entre le pool de serveurs d’applications SAP pour le trafic des clients SAP GUI et RFC.

Cluster des services centraux SAP

Cet exemple illustre un cluster hautement disponible qui utilise Azure NetApp Files comme solution de stockage de fichiers partagés. La haute disponibilité pour le cluster Services centraux requiert un stockage partagé. Azure NetApp Files offre une option hautement disponible simple qui vous évite de déployer une infrastructure de cluster Linux. Une alternative consiste à configurer un service NFS hautement disponible.

Vous pouvez également déployer les services centraux sur une même machine virtuelle avec des disques managés Premium et obtenir un contrat de niveau de service garantissant une disponibilité de 99,9 %.

Les machines virtuelles utilisées pour les serveurs d’applications prennent en charge plusieurs adresses IP par carte réseau. Cette fonctionnalité prend en charge la pratique recommandée par SAP consistant à utiliser des noms d’hôtes virtuels pour les installations, comme décrit dans la note SAP 962955. Les noms d’hôtes virtuels découplent les services SAP des noms d’hôtes physiques et facilitent la migration de services d’un hôte physique vers un autre. Ce principe s’applique également aux machines virtuelles dans le cloud.

Les serveurs d’applications sont connectés aux services centraux hautement disponibles sur Azure via les noms d’hôtes virtuels 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. Un équilibreur de charge prend en charge de nombreuses adresses IP frontales. Les adresses IP virtuelles (VIP) des services centraux et des services ERS peuvent être liés à un équilibreur de charge.

Installation multi-SID

Azure prend également en charge la haute disponibilité dans une installation multi-SID des clusters Linux et Windows hébergeant les services centraux (ASCS/SCS). Pour plus d’informations concernant un déploiement sur un cluster Pacemaker, consultez la documentation Azure multi-SID pour :

Groupes de placements de proximité

Cet exemple d’architecture utilise également un groupe de placement de proximité pour réduire la latence du réseau entre les machines virtuelles. Ce type de groupe place une contrainte d’emplacement sur les déploiements de machines virtuelles et réduit la distance physique qui les sépare. Cet article fournit des conseils mis à jour concernant l’utilisation des groupes de placement de proximité. Il est important d’avoir une bonne compréhension de ces conseils avant de déployer en production.

Base de données

SAP BW/4HANA est conçu pour la plateforme de base de données SAP HANA. Azure propose trois options de scalabilité et de déploiement :

Stockage

Cet exemple utilise des disques managés Premium pour le stockage non partagé de serveurs d’applications. Il utilise également Azure NetApp Files pour le stockage partagé de clusters.

Les disques Azure SSD Premium v2 sont conçus pour les charges de travail critiques en matière de performances telles que SAP. Pour connaître les avantages et les limitations actuelles de la solution de stockage, consultez Déployer un disque SSD Premium v2.

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

Les disques managés Standard ne sont pas pris en charge, comme indiqué dans la note SAP 1928533. L’utilisation du stockage standard n’est pas recommandée pour les installations SAP.

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.

Mise en réseau

Bien que cela ne soit pas obligatoire, il est courant de déployer une topologie hub-and-spoke pour fournir une isolation logique et des limites de sécurité dans un paysage SAP. Pour plus d’informations sur la mise en réseau, reportez-vous à l’architecture de référence SAP S/4HANA.

Le réseau virtuel hub agit comme un point central de connectivité à un réseau local. Les spokes sont des réseaux virtuels appairés avec le hub qui peuvent être utilisés pour isoler les charges de travail. Le trafic circule entre le centre de données local et le hub via une connexion de passerelle.

La plupart des implémentations de clients incluent un ou plusieurs circuits ExpressRoute connectant des réseaux locaux à Azure. Pour une demande moins importante en bande passante réseau, le VPN constitue une alternative à moindre coût.

Considérations

Ces considérations implémentent les piliers d’Azure Well-Architected Framework qui est un ensemble de principes directeurs qui permettent d’améliorer la qualité d’une charge de travail. Pour plus d'informations, consultez Microsoft Azure Well-Architected Framework.

Efficacité des performances

L’efficacité des performances est la capacité de votre charge de travail à mettre à l’échelle pour répondre aux demandes qu’elle lui impose par les utilisateurs de manière efficace. Pour plus d’informations, consultez principes de conception d’efficacité des performances.

SAP BW/4HANA est conçu pour les tâches d’entreposage de données en temps réel. Les serveurs d’applications SAP communiquent constamment avec les serveurs de base de données, ce qui contribue à améliorer les performances des applications en réduisant la latence entre les machines virtuelles d’application et la base de données. La mise en cache des disques et la sélection élective du serveur sont deux stratégies qui permettent de réduire la latence entre ces deux composants.

Pour les applications critiques pour les performances qui s’exécutent sur tout type de plateforme de base de données, y compris SAP HANA, utilisez des disques managés Premium et activez l’accélérateur d’écriture pour le volume du fichier journal. L’accélérateur d’écriture est disponible pour les machines virtuelles de la série M et améliore la latence d’écriture. Toutefois, lorsque cela est possible, utilisez des disques managés Ultra sans accélérateur d’écriture plutôt que des disques Premium. Les capacités des disques Ultra continuent d’évoluer. Pour voir si ces disques répondent à vos besoins, consultez les informations les plus récentes sur l’étendue du service des disques Ultra. Procédez à cette opération, d’autant plus si votre implémentation inclut des fonctions de résilience Azure, telles que des groupes à haute disponibilité, des zones de disponibilité et la réplication entre régions.

Pour améliorer les performances en réduisant la distance physique entre les applications et la base de données, utilisez un groupe de placement de proximité, comme mentionné précédemment. Des scripts et des utilitaires sont disponibles sur GitHub.

Pour optimiser les communications entre les serveurs, utilisez la mise en réseau accélérée, qui est disponible pour les machines virtuelles prises en charge, notamment D/DSv2, D/DSv3, E/ESv3, F/FS, FSv2 et Ms/Mms. La mise en réseau accélérée est nécessaire dans toutes les implémentations SAP, en particulier quand Azure NetApp Files est utilisé.

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

Extensibilité

Cet exemple d’architecture décrit un petit déploiement de niveau production capable de se mettre à l’échelle pour répondre à vos besoins.

Au niveau de la couche de l’application SAP, Azure propose un large éventail de tailles de machines virtuelles pour la montée en puissance ou la montée en charge. Pour obtenir une liste exhaustive, consultez la note SAP 1928533. À mesure que nous certifions des types de machines virtuelles supplémentaires, vous pouvez effectuer un scale-up ou un scale-down dans le même déploiement cloud.

Disponibilité

La redondance des ressources constitue le thème général dans les solutions d’infrastructure à haute disponibilité. Si votre organisation dispose d’un SLA moins strict, utilisez des machines virtuelles à instance unique associées à des disques Premium, qui offrent un SLA garantissant un certain temps de disponibilité.

Pour optimiser la disponibilité des applications, vous pouvez déployer des ressources redondantes dans un groupe à haute disponibilité ou sur des zones de disponibilité. Pour plus d’informations, reportez-vous à l’architecture de référence SAP S/4HANA.

Cette architecture place les machines virtuelles qui jouent le même rôle dans un groupe à haute disponibilité. Cette configuration permet de respecter les SLA en offrant une protection contre les temps d’arrêt causés par la maintenance de l’infrastructure Azure et les arrêts non planifiés. Il convient d’utiliser plusieurs machines virtuelles par groupe à haute disponibilité pour bénéficier d’un SLA supérieur.

Azure Load Balancer

Azure Load Balancer est un service de couche de transmission réseau (couche 4). Dans les configurations de cluster, Azure Load Balancer dirige 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 offre une implémentation de sécurité par conception et bloque le trafic sortant à partir du pool principal, sauf si vous activez la connectivité sortante vers les points de terminaison publics. En outre, vous pouvez également utiliser une passerelle Azure NAT Gateway pour obtenir une connectivité sortante.

En outre, si vous décidez de déployer des charges de travail SAP dans des zones de disponibilité Azure, le Standard Load Balancer tient compte des zones.

Web Dispatcher

Dans cet exemple de conception, SAP Web Dispatcher est utilisé comme simple mécanisme d’équilibrage de charge HTTP(s) pour le trafic SAP entre les serveurs d’applications SAP. Pour assurer la haute disponibilité du composant Web Dispatcher, Azure Load Balancer implémente le cluster de basculement ou l’installation parallèle de Web Dispatcher. Consultez SAP Web Dispatcher dans la documentation SAP.

En tant qu’équilibreur de charge logiciel, Web Dispatcher offre des services de couche supplémentaires qui peuvent effectuer une terminaison SSL, ainsi que d’autres fonctions de déchargement. Ces services de couche sont connus sous le nom de couche 7 dans le modèle de mise en réseau ISO.

Aucun autre équilibreur de charge n’est nécessaire pour le trafic des clients de l’interface graphique utilisateur SAP qui connectent un serveur SAP via le protocole DIAG ou les appels RFC (Remote Function Calls). Le serveur de messages des services centraux équilibre la charge via les groupes d’ouverture de session sur le serveur d’applications SAP.

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 le cluster de basculement ou l’installation parallèle de Web Dispatcher.

Pour les communications sur Internet, une solution autonome dans la zone DMZ est l’architecture recommandée pour répondre aux problèmes de sécurité.

Embedded Web Dispatcher sur ASCS est une option spéciale, et le dimensionnement approprié en raison d’une charge de travail supplémentaire sur ASCS doit être pris en compte.

Services centraux

Pour protéger la disponibilité des services centraux SAP (ASCS) sur des machines virtuelles Linux Azure, vous devez utiliser l’extension de haute disponibilité (HAE) appropriée pour la distribution Linux sélectionnée. L’extension HAE fournit des logiciels de clustering Linux et des composants d’intégration spécifiques au système d’exploitation pour l’implémentation.

Pour éviter un problème de fractionnement de cluster, vous pouvez configurer des délimitations de nœud de cluster à l’aide d’un périphérique iSCSI de traitement par blocs STONITH (SBD), comme le montre cet exemple. Vous pouvez également utiliser l’agent de délimitation Azure. La version améliorée de l’agent de délimitation Azure fournit un basculement de service beaucoup plus rapide que la version précédente pour les environnements Red Hat et SUSE.

Autres serveurs d’applications de la couche Serveurs d’applications

Pour assurer une haute disponibilité pour les serveurs d’applications SAP principaux et tout autre serveur d’applications, équilibrez la charge du trafic au sein du pool de serveurs d’applications.

Récupération d'urgence

Azure prend en charge un large éventail d’options de récupération d’urgence en fonction de vos besoins. Les serveurs d’applications SAP ne contiennent pas de données d’entreprise. vous pouvez donc créer des serveurs d’applications SAP dans une région secondaire avant de les arrêter. Les mises à jour logicielles et les modifications de configuration du serveur d’applications SAP doivent être répliquées sur le site de récupération d’urgence, manuellement ou selon une planification. Vous pouvez créer une machine virtuelle dans la région de récupération d’urgence pour exécuter le rôle Services centraux, qui ne conserve pas non plus les données métiers. Pour plus d’informations, reportez-vous à l’architecture de référence SAP S/4HANA.

Surveillance

Pour optimiser la disponibilité et les performances des applications et des services, utilisez Azure Monitor, qui inclut Azure Log Analytics et Azure Application Insights et fournit des outils sophistiqués pour la collecte et l’analyse des données de télémétrie. Cela peut vous aider à optimiser les performances et la disponibilité de vos ressources et applications cloud et locales. Vous pouvez utiliser Azure Monitor pour superviser les anomalies d’infrastructure et d’application, envoyer des alertes aux administrateurs et automatiser les réactions à des conditions prédéfinies.

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. Azure Monitor pour SAP fournit un ensemble initial complet de métriques et de données de télémétrie pour la surveillance. Les définitions métriques sont stockées comme des requêtes SQL dans JSON et elles peuvent être modifiées pour répondre à vos attentes. L’ensemble de départ des métriques est disponible sur GitHub ici.

Sauvegarde

Pour les serveurs d’applications et de SAP ASCS, nous recommandons d’utiliser le service Sauvegarde Azure pour protéger le contenu des machines virtuelles. Le service Sauvegarde Azure fournit des sauvegardes indépendantes et isolées pour éviter la destruction accidentelle des données d’origine. Les sauvegardes sont stockées dans un coffre Recovery Services qui offre une gestion intégrée des points de récupération. La configuration et la scalabilité sont simples : les sauvegardes sont optimisées, et vous pouvez facilement effectuer des restaurations en fonction des besoins.

La sauvegarde de la couche Base de données varie selon que SAP HANA est déployé sur des machines virtuelles ou des grandes instances Azure. Pour SAP HANA sur les machines virtuelles Linux, consultez les considérations relatives à la gestion et aux opérations.

Sécurité

La sécurité fournit des garanties contre les attaques délibérées, et contre l’utilisation abusive de vos données et systèmes importants. Pour plus d’informations, consultez Vue d’ensemble du pilier sécurité.

SAP possède son propre moteur de gestion des utilisateurs (UME) pour contrôler l’accès et les autorisations en fonction du rôle dans l’application et les bases de données SAP. Pour plus d’informations, consultez le guide de sécurité SAP BW∕4HANA.

L’architecture de référence SAP S/4HANA fournit des considérations supplémentaires sur la sécurité de l’infrastructure qui s’appliquent à SAP BW/4HANA.

Contributeurs

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

Auteur principal :

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

Étapes suivantes

En savoir plus sur les technologies des composants :

Explorer les architectures connexes :