Exécution de SAP HANA sur Azure (grandes instances)

Cette architecture de référence présente un ensemble de pratiques éprouvées pour l’exécution de SAP HANA sur Azure (grandes instances) dans un environnement à haute disponibilité (HA) et à récupération d’urgence (DR). Appelée Grandes instances HANA (HLI), cette offre est déployée sur des serveurs physiques dans des régions Azure. Cette solution décrit un scénario simple de montée en puissance pour illustrer les concepts de base du déploiement et du fonctionnement d’un système SAP HANA sur Azure. Pour plus d’options, consultez d’autres scénarios d’installation pour les grandes instances HANA.

Architecture

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

Workflow

Cette architecture est constituée des composants d’infrastructure suivants.

• Réseau virtuel. Le service Réseau virtuel Azure connecte en toute sécurité les ressources Azure entre elles et est subdivisé en sous-réseaux distincts pour chaque couche. Les couches d’application SAP sont déployées sur des machines virtuelles (VM) Azure pour établir la connexion à la couche de base de données HANA résidant sur de grandes instances.

• Réseau Révision 4.5 HLI. Depuis juillet 2021, la révision mise à jour HLI Rev 4 est disponible. Cette implémentation mise à jour [rev4.5] inclut de nombreuses améliorations d’infrastructure, telles que la mise en réseau de 100 Go/s pour le stockage NFS et une meilleure redondance réseau du serveur de base de données. Dans cette conception, les serveurs HLI sont déployés dans des centres de données Azure à proximité physique des machines virtuelles Azure où s'exécutent les serveurs d'application SAP. Lorsqu’elle est utilisée conjointement avec une configuration [ExpressRoute FastPath][fastpath], Rev 4.5 élève les performances de l’application. Ces fonctionnalités de mise en réseau prennent également en charge les déploiements de Rev 3 et Rev 4.

• Machines virtuelles (VM) . Les machines virtuelles sont utilisées dans la couche Application SAP et la couche de services partagés. Cette dernière inclut un serveur de rebond (jumpbox) utilisé par les administrateurs pour configurer les grandes instances HANA et pour fournir l’accès à d’autres machines virtuelles. Pour colocaliser les serveurs d’applications SAP dans le même centre de données avec les unités de grande instance HANA, utilisez les groupes de placement de proximité.

• Grande instance SAP HANA. Ce serveur physique est certifié conforme aux normes de SAP HANA TDI (Tailored Datacenter Integration) pour l’exécution de SAP HANA. Cette architecture utilise deux grandes instances HANA : une unité Compute principale et une secondaire. Au niveau de la couche de données, la haute disponibilité est fournie par la Réplication de système HANA (HSR).

• Paire haute disponibilité. Des lames de grandes instances HANA sont gérées ensemble pour assurer la redondance et la fiabilité de la base de données.

• Microsoft Enterprise Edge (MSEE) . MSEE est un point de connexion à partir d’un fournisseur de connectivité ou de la périphérie du réseau via un circuit ExpressRoute.

• Cartes d’interface réseau. Pour activer la communication, le serveur grande instance HANA fournit quatre cartes réseau virtuels par défaut. Cette architecture requiert une carte réseau pour la communication client, une deuxième carte réseau pour la connectivité nœud à nœud exigée par HSR, une troisième carte réseau pour le stockage de la grande instance HANA et une quatrième pour iSCSI utilisé dans le clustering à haute disponibilité.

• Stockage NFS (Network File System) . Le serveur NFS prend en charge le partage de fichiers réseau qui assure la persistance sécurisée des données de la grande instance HANA.

• ExpressRoute. ExpressRoute est le service réseau Azure recommandé pour la création de connexions privées entre un réseau local et les réseaux virtuels Azure non accessibles via le réseau Internet public. Les machines virtuelles Azure se connectent aux grandes instances HANA à l’aide d’une autre connexion ExpressRoute. La connexion ExpressRoute entre le réseau virtuel Azure et les grandes instances HANA est configurée dans le cadre de l’offre Microsoft.

• Passerelle. La passerelle ExpressRoute est utilisée pour connecter le réseau virtuel Azure utilisé pour la couche Application SAP au réseau hébergeant la grande instance HANA. Utilisez la référence SKU Hautes performances ou ultra-performance.

• Récupération d’urgence. Les options de DR incluent la réplication de système HANA (HSR), la sauvegarde et la restauration de fichiers HANA, ou la réplication de stockage. À la demande, l’équipe de management des services Microsoft peut configurer les serveurs et les volumes de stockage. Vous êtes responsable de la planification de la capture instantanée de stockage, du test du système et du processus de récupération. D’autres considérations s’appliquent à la couche Application pour SAP NetWeaver et SAP S/4HANA sur Azure.

Recommandations

Les exigences pouvant varier, utilisez ces suggestions comme point de départ.

Calcul des grandes instances HANA

Les grandes instances HANA sont des serveurs physiques basés sur l’architecture de processeur Broadwell et Cascade Lake et configurés dans un tampon de grande instance, c’est-à-dire un ensemble spécifique de serveurs ou de lames. Une unité Compute équivaut à un serveur ou une lame et un tampon est constitué de plusieurs serveurs ou lames. Dans un tampon de grande instance, les serveurs ne sont pas partagés et sont dédiés à l’exécution du déploiement SAP HANA d’un client.

Différentes références SKU sont disponibles pour les grandes instances HANA, prenant en charge une instance unique jusqu’à 24 To (scale-out de 120 To) de mémoire pour BW/4HANA ou d’autres charges de travail SAP HANA.

Choisissez une référence SKU conforme aux exigences de dimensionnement déterminées lors de vos sessions d’architecture et de conception. Vérifiez toujours que le dimensionnement s’applique à la référence SKU correcte. Les capacités et les exigences de déploiement varient par type, et la disponibilité varie par région. Vous pouvez également changer de configuration et passer d’une référence SKU à une autre référence plus grande.

Microsoft vous aide à mettre en place la configuration de la grande instance, mais il vous incombe de vérifier les paramètres de configuration du système d’exploitation. Relisez bien les Notes SAP les plus récentes pour votre version Linux.

Stockage

La disposition de stockage est implémentée conformément à la recommandation de la norme TDI pour SAP HANA. Les grandes instances HANA sont livrées avec une configuration de stockage spécifique pour les spécifications TDI standard. Toutefois, vous pouvez acheter du stockage supplémentaire par incréments de 1 To.

Pour prendre en charge les exigences des environnements critiques, y compris la récupération rapide, NFS est utilisé plutôt que le stockage en attachement direct. Le serveur de stockage NFS pour les grandes instances HANA est hébergé dans un environnement mutualisé, où les locataires sont séparés et sécurisés à l’aide de l’isolation du calcul, du réseau et du stockage.

Pour prendre en charge la haute disponibilité sur le site principal, utilisez des dispositions de stockage différentes. Par exemple, dans un environnement scale-out multi-hôte, le stockage est partagé. La réplication basée sur l’application (HSR, par exemple) est une autre option de haute disponibilité. Toutefois, pour la récupération d’urgence, une réplication de stockage basée sur un instantané est utilisée.

Mise en réseau

Cette architecture utilise des réseaux virtuels et physiques. Le réseau virtuel fait partie d’Azure IaaS (infrastructure as a service) et se connecte à un réseau physique distinct de grandes instances HANA via des circuits ExpressRoute. Une passerelle intersite connecte vos charges travail dans le réseau virtuel Azure à vos sites locaux.

Tous les déploiements de grande instance HANA depuis juillet 2019 utilisent des tampons Rev 4, qui sont déployés à proximité des hôtes de machine virtuelle Azure utilisés pour les serveurs d’applications SAP. Par conséquent, le déploiement Rev 4 minimise la latence du réseau entre les couches Application et Base de données.

Les réseaux hébergeant les grandes instances HANA sont isolés les uns des autres pour assurer la sécurité. Les instances résidant dans des régions différentes ne communiquent pas les unes avec les autres, sauf pour la réplication de stockage dédiée. Toutefois, pour utiliser HSR, les communications entre régions sont requises. [Azure Global Reach][globalreach], les tables de routage IP ou les proxys peuvent être utilisés pour activer la fonction HSR entre les régions.

Tous les réseaux virtuels Azure qui se connectent à des grandes instances HANA dans une région peuvent être interconnectés via ExpressRoute aux grandes instances HANA d’une deuxième région.

Le circuit ExpressRoute pour les grandes instances HANA est inclus par défaut lors de l’approvisionnement. Pour la configuration, une disposition de réseau spécifique est nécessaire, notamment les plages d’adresses de routage CIDR requises et le routage de domaine. Pour en savoir plus, consultez Infrastructure et connectivité à SAP HANA sur Azure (grandes instances).

Pour réduire la latence du réseau et améliorer les performances, envisagez d’activer FastPath (également appelé MSEE v2). Cette configuration réseau autorise le trafic en provenance d’un site local vers le réseau virtuel Azure, et du réseau virtuel vers de grandes instances HANA pour contourner la passerelle Azure.

Considérations

Scalabilité

Pour augmenter ou réduire l’échelle, vous avez le choix entre différentes tailles de serveurs disponibles pour les grandes instances HANA. Ils sont classés Type I ou Type II et adaptés aux différentes charges de travail. Choisissez une taille pouvant croître avec votre charge de travail au cours des trois prochaines années. Des engagements d’un an sont également disponibles.

Un déploiement scale-out multi-hôte est généralement utilisé pour les déploiements BW/4HANA comme stratégie de partitionnement de base de données. À compter de cet article, BW/4HANA sur les grandes instances HANA peut effectuer un scale-out jusqu’à 120 To. Pour effectuer un scale-out, planifiez le positionnement des tables HANA avant l’installation. À partir d’un point hôtes sont connectés à un volume de stockage partagé, permettant la prise de contrôle rapide par les hôtes de secours en cas de défaillance d’un des nœuds de travail du système HANA.

Sur une lame unique, la taille des instances S/4HANA et SAP Business Suite sur HANA peut être augmentée jusqu’à 24 To avec un nœud à une seule instance. Les grandes instances HANA et l’infrastructure de stockage Azure prennent également en charge les déploiements de scale-out S/4HANA et BW/4HANA. Pour obtenir des références SKU spécifiques certifiées pour le scale-out, consultez le [répertoire matériel certifié SAP][répertoire].

La mémoire requise pour HANA augmente à mesure que le volume de données augmente. Utilisez la consommation de mémoire actuelle de votre système comme base pour prévoir la consommation future, puis mappez votre demande à l’une des tailles de grandes instances HANA.

Si vous avez déjà des déploiements SAP, SAP fournit des rapports que vous pouvez utiliser pour vérifier les données utilisées par les systèmes existants et calculer la configuration mémoire requises pour une instance HANA. Par exemple, consultez les notes SAP suivantes (l’accès requiert un compte SAP Service Marketplace) :

• Note SAP 1793345 - Sizing for SAP Suite on HANA (Redimensionnement de SAP Suite sur HANA)
• Note SAP 1872170 - Suite on HANA and S/4 HANA sizing report (Rapport de redimensionnement de Suite sur HANA et S/4 HANA)
• Note SAP 2121330 - FAQ : SAP BW on HANA Sizing Report (FAQ : rapport de redimensionnement SAP BW sur HANA)
• Note SAP 1736976 - Sizing Report for BW on HANA (Rapport de redimensionnement pour BW sur HANA)
• Note SAP 2296290 - New Sizing Report for BW on HANA (Nouveau rapport de redimensionnement de BW sur HANA)

Disponibilité

La redondance des ressources constitue le thème général dans les solutions d’infrastructure à haute disponibilité. Collaborez avec SAP, votre intégrateur de systèmes ou Microsoft pour concevoir et implémenter efficacement une stratégie de haute disponibilité et récupération d’urgence. Cette architecture suit le contrat de niveau de service (SLA) pour HANA sur Azure (grandes instances). Pour évaluer vos besoins de disponibilité, tenez compte des points de défaillance uniques, du niveau souhaité de disponibilité des services et de ces mesures courantes :

• L’objectif de délai de récupération (RTO) est la durée pendant laquelle le serveur de grandes instances HANA n’est pas disponible.

• L’objectif de point de récupération (RPO) est la période maximale acceptable pendant laquelle les données clients risquent d’être perdues en raison d’une défaillance.

Pour la haute disponibilité, déployez plusieurs instances dans une paire HA et utilisez HSR en mode synchrone pour réduire la perte de données et les temps d’arrêt. Outre une installation locale haute disponibilité à deux nœuds, HSR prend en charge la réplication à plusieurs niveaux, où un troisième nœud d’une région Azure distincte s’enregistre sur le réplica secondaire de la paire HSR en cluster en tant que cible de réplication. Il en résulte une configuration en chaîne de la réplication.

Le basculement vers le nœud DR est un processus manuel sans clustering Linux. Pour la détection automatique des erreurs et le basculement, vous pouvez configurer Pacemaker de manière à réduire encore les temps d’arrêt causés par une défaillance matérielle ou logicielle. À partir d’HANA 2.0 SPS 04, HSR prend également en charge la réplication à plusieurs cibles. Au lieu d’une chaîne, cette forme de réplication a un abonné principal et plusieurs abonnés secondaires.

Lorsque vous configurez la fonction HSR sur les grandes instances HANA avec le basculement automatique, vous pouvez demander à l’équipe de management des services Microsoft de configurer un appareil STONITH pour vos serveurs de grandes instances HANA.

Récupération d'urgence

Cette architecture prend en charge la récupération d’urgence entre les grandes instances HANA dans différentes régions Azure. Il existe deux façons de prendre en charge la récupération d’urgence avec les grandes instances HANA :

• Réplication de stockage. Le contenu du stockage principal est répliqué en permanence vers les systèmes de stockage de récupération d’urgence à distance qui sont disponibles sur le serveur de récupération d’urgence des grandes instances HANA désigné. Pour la réplication du stockage, la base de données HANA n’est pas chargée en mémoire. Cette option de récupération d’urgence est plus simple d’un point de vue administratif. Pour déterminer s’il s’agit d’une stratégie appropriée, comparez le temps de chargement de la base de données au contrat SLA de disponibilité. La réplication du stockage vous permet également d’effectuer une récupération jusqu’à une date et une heure. Si la récupération d’urgence polyvalente (au coût optimisé) est configurée, vous devez acheter un stockage supplémentaire de la même taille sur le site de récupération d’urgence. Microsoft fournit une capture instantanée de stockage et des scripts de basculement en libre-service dans le cadre de l’offre des grandes instances HANA.

• HSR à plusieurs niveaux ou à plusieurs cibles avec un troisième réplica dans la région DR (où la base de données HANA est chargée dans la mémoire). Cette option prend en charge un temps de récupération plus rapide, mais ne prend pas en charge la récupération jusqu’à une date et heure. HSR nécessite un système secondaire. Le trafic de réplication du système HANA destiné au site DR peut être géré via des proxys, tels que les tables nginx ou IP. Vous pouvez également utiliser Global Reach pour lier les circuits ExpressRoute en permettant aux utilisateurs autorisés de se connecter directement à l’unité de grandes instances HANA.

Optimisation des coûts

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.

Les références SKU peuvent affecter le modèle de facturation. Voici quelques éléments de coût à prendre en compte.

Machines virtuelles

Dans cette architecture de référence, les machines virtuelles sont utilisées pour l’hébergement d’applications SAP, de services SAP et de services partagés, tels que les serveurs de rebond (jumpbox) de gestion. Il s’agit de certaines références SKU certifiées SAP des grandes instances HANA. Les configurations dépendent de la charge de travail, des ressources du processeur, de la mémoire souhaitée et du budget.

Les références SKU des grandes instances HANA sont disponibles sous forme d’instances de machines virtuelles réservées. Les réservations Azure peuvent réduire vos coûts si vous pouvez vous engager sur une période de 1 ou 3 ans. Les réservations de machines virtuelles peuvent réduire les coûts jusqu’à 72 pour cent par rapport aux tarifs du paiement à l’utilisation. Vous bénéficiez d’une infrastructure de SAP HANA spécialement conçue avec le calcul, le stockage et le réseau. Les grandes instances HANA sont associées au stockage et à la mise en réseau NFS, et offrent une prise en charge intégrée des sauvegardes via des captures instantanées de stockage, une haute disponibilité, une récupération d’urgence et des configurations de scale-out. Si votre charge de travail n’a pas de temps de réalisation prévisible ni de consommation des ressources, envisagez l’option de paiement à l’utilisation.

Utilisez le plan d’économies Azure et combinez-le avec les réservations Azure. Le plan d’économies Azure est un plan d’économies flexible qui permet de réaliser des économies significatives sur les tarifs du paiement à l’utilisation. Vous souscrivez à un contrat d’un ou trois ans et bénéficiez de remises sur les services de calcul éligibles. Les économies s’appliquent à ces services de calcul, quelle que soit la région, la taille des instances ou le système d’exploitation. Pour plus d’informations, consultez la documentation sur le plan d’économies Azure.

Utilisez les machines virtuelles Azure Spot 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.

Pour plus d’informations, consultez la section « SAP HANA sur Azure (grandes instances) » dans Tarification de HLI pour les machines virtuelles SAP HANA.

Azure ExpressRoute

Pour cette architecture, Azure ExpressRoute est le service de mise en réseau recommandé pour la création de connexions privées entre un réseau local et les réseaux virtuels Azure. Les machines virtuelles Azure se connectent aux grandes instances HANA à l’aide d’une autre connexion ExpressRoute et d’une passerelle ExpressRoute. La référence SKU Hautes performances ou ultra-performance est la référence recommandée.

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.

Sauvegarde

En fonction de vos exigences professionnelles, choisissez parmi plusieurs options disponibles.

Pour plus d’informations sur une approche de sauvegarde personnalisée et d’autres options fournies avec les grandes instances HANA, consultez l’article [Sauvegarde et restauration] [sauvegarde-restauration].

Simplicité de gestion

Surveillez les ressources des grandes instances HANA, telles que l’UC, la mémoire, la bande passante réseau et l’espace de stockage, à l’aide de SAP HANA Studio, SAP HANA Cockpit, SAP Solution Manager et d’autres outils Linux natifs. Les références SKU de type I des grandes instances HANA ne sont pas fournies avec des outils de surveillance intégrés. Les références SKU de type II offrent des outils de diagnostic prédéfinis pour la journalisation des activités et la résolution des problèmes du système.

Microsoft propose des outils et des ressources de base pour vous aider à surveiller les grandes instances HANA sur Azure. L’équipe du support technique de Microsoft peut également vous aider à résoudre des problèmes techniques.

Sécurité

• Depuis la fin de 2018, le stockage des grandes instances HANA est chiffré par défaut.

• Les données en transit entre les grandes instances HANA et les machines virtuelles ne sont pas chiffrées. Pour chiffrer le transfert de données, activez le chiffrement spécifique à l’application. Voir la note SAP 2159014 - FAQ : SAP HANA Security (Sécurité de SAP HANA).

• L’isolation assure la sécurité entre les locataires dans l’environnement de grande instance HANA multi-locataire. Les locataires sont isolés à l’aide de leur propre réseau local virtuel.

• Les meilleures pratiques en matière de sécurité réseau Azure fournissent des instructions utiles.

• Comme pour tout déploiement, le renforcement de la sécurité des systèmes d’exploitation est recommandé, notamment le renforcement de la sécurité de l’image SUSE Linux pour SAP sur Azure.

• Pour la sécurité physique, l’accès aux centres de données Azure est limité au personnel autorisé uniquement. Aucun client ne peut accéder aux serveurs physiques.

Pour plus d’informations, consultez SAP HANA Security - An Overview (Sécurité SAP HANA - Vue d'ensemble). (l’accès requiert un compte SAP Service Marketplace.)

Communautés

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

• Blog Running SAP Applications on the Microsoft Platform (Exécution d’applications SAP sur la plateforme Microsoft)
• 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.

Ressources associées

Vous pouvez consulter les exemples de scénarios Azure suivants, qui décrivent des solutions spécifiques utilisant certaines de ces technologies :

• Exécution des charges de travail de production SAP à l’aide d’Oracle Database sur Azure
• Environnements de développement/test pour les charges de travail SAP sur Azure