Guide

Sélectionner une machine virtuelle pour une base de données SAP HANA de production.

→Utiliser des machines virtuelles de série Mv2 ou M pour les grandes bases de données (>4 To). Utiliser des machines virtuelles de série Edsv5 certifiées SAP pour les bases de données HANA de production plus petites (<4 To).

Pourquoi: Les séries M/Mv2 sont certifiées SAP pour les charges de travail nécessitant une grande quantité de mémoire. La série Edsv5 offre une option certifiée rentable pour les instances HANA plus petites. D'autres séries (D, F, L) ne sont pas certifiées pour les bases de données HANA de production.

Référence↗

Sélectionner une machine virtuelle pour un serveur d'applications SAP NetWeaver.

→Utiliser des machines virtuelles de série Edsv5 ou Ddsv5. Dimensionner en fonction des exigences SAPS des rapports SAP EarlyWatch Alert ou de SAP Quick Sizer.

Pourquoi: Les machines virtuelles des séries E et D offrent un rapport CPU/mémoire équilibré, adapté aux charges de travail des serveurs d'applications SAP, et sont certifiées SAP pour NetWeaver.

Assurer une latence réseau minimale entre les serveurs d'applications SAP et le serveur de base de données.

→Déployer toutes les machines virtuelles associées (serveurs d'applications, ASCS/ERS, base de données) au sein d'un seul groupe de placement de proximité (PPG).

Pourquoi: Les PPG co-localisent physiquement les machines virtuelles dans le même centre de données, minimisant le temps d'aller-retour réseau pour répondre aux exigences de latence sub-milliseconde de SAP entre les couches application et base de données.

Fournir un système de fichiers partagé pour le volume /hana/shared dans un déploiement SAP HANA scale-out.

→Utiliser Azure NetApp Files (ANF) avec le protocole NFS.

Pourquoi: ANF est la solution de stockage NFS partagé, haute performance et certifiée SAP requise pour les configurations HANA scale-out. Le stockage par blocs comme les disques gérés ne peut pas être utilisé à cette fin.

Fournir un système de fichiers partagé hautement disponible pour /sapmnt et le répertoire de transport global (/usr/sap/trans).

→Utiliser Azure NetApp Files (NFS) ou Azure Files Premium (NFS). Pour Windows, utiliser Azure Files Premium (SMB) ou un cluster SOFS.

Pourquoi: Ces services fournissent des partages de fichiers gérés et hautement disponibles avec les performances et le support de protocole requis (NFS pour Linux, SMB pour Windows), éliminant le besoin de construire et de gérer un cluster de serveurs de fichiers séparé.

Concevoir le stockage pour les volumes /hana/data et /hana/log de SAP HANA de production nécessitant des IOPS élevés et une latence inférieure à la milliseconde.

→Utiliser des disques gérés Azure Ultra Disk ou Premium SSD v2. Pour /hana/log sur les machines virtuelles de série M, le Premium SSD avec Write Accelerator est également une option valide.

Pourquoi: Ultra Disk et Premium SSD v2 répondent aux KPI stricts en matière d'IOPS, de débit et de latence sub-milliseconde définis par SAP pour les charges de travail HANA de production. Les niveaux de stockage standard ne sont pas pris en charge.

Concevoir une architecture réseau sécurisée pour les charges de travail SAP, isolant la production des environnements de non-production.

→Utiliser une topologie hub-spoke. Déployer les systèmes SAP dans des réseaux virtuels (VNet) spokes dédiés pour chaque environnement (Prod, QA, Dev). Utiliser des groupes de sécurité réseau (NSG) pour appliquer des règles de trafic strictes entre les sous-réseaux.

Pourquoi: Ceci offre une isolation réseau forte au niveau du VNet et un contrôle granulaire du trafic avec les NSG, en suivant les meilleures pratiques de sécurité et le concept d'Azure Landing Zone.

Déployer des paysages SAP sur Azure en utilisant une approche Infrastructure as Code (IaC) pour la cohérence et l'automatisation.

→Utiliser le framework officiel d'automatisation du déploiement SAP sur Azure, qui s'appuie sur Terraform et Ansible. Alternativement, construire des modules Bicep ou Terraform personnalisés.

Pourquoi: Le framework fournit des modèles pré-construits et validés par SAP pour le déploiement de l'ensemble du paysage (plan de contrôle, zones de charge de travail, systèmes SAP), réduisant l'effort manuel et assurant le respect des meilleures pratiques.

Publier en toute sécurité SAP Fiori ou d'autres applications SAP basées sur le web à des utilisateurs externes via Internet.

→Utiliser Azure Application Gateway avec le pare-feu d'applications web (WAF) activé.

Pourquoi: App Gateway fournit l'équilibrage de charge de couche 7, la terminaison SSL et la protection WAF contre les vulnérabilités web courantes, ce qui en fait le point d'entrée idéal et sécurisé pour les applications SAP basées sur le web.

Déployer une base de données SAP HANA extrêmement grande (>12 To de mémoire) qui dépasse la capacité des machines virtuelles Azure.

→Utiliser SAP HANA sur Azure Large Instances (HLI). La connectivité nécessite un circuit ExpressRoute connectant le bloc HLI à un VNet Azure via une passerelle ExpressRoute.

Pourquoi: Les HLI sont des serveurs bare-metal conçus spécifiquement, offrant la mémoire et les performances massives nécessaires aux plus grandes charges de travail HANA, qui dépassent l'échelle de l'infrastructure virtualisée actuelle.

Déployer un système SAP sur plusieurs zones de disponibilité tout en minimisant la latence au sein de chaque zone.

→Créer un groupe de placement de proximité (PPG) distinct pour les ressources de chaque zone de disponibilité. Épingler chaque PPG à sa zone respective.

Pourquoi: Un seul PPG ne peut pas s'étendre sur plusieurs zones. Cette approche garantit une co-localisation à faible latence des ressources *au sein* d'une zone, tout en atteignant une haute disponibilité *entre* les zones.

Créer et distribuer des images de machines virtuelles standardisées, corrigées et préconfigurées pour les déploiements SAP dans plusieurs régions.

→Utiliser Azure Image Builder pour définir un processus de création d'image reproductible. Stocker et répliquer les images gérées résultantes à l'aide d'Azure Compute Gallery.

Pourquoi: Cela fournit une usine d'"images d'or" automatisée et versionnée, assurant la cohérence et réduisant le temps de déploiement par rapport à la configuration manuelle de chaque nouvelle machine virtuelle.

Fournir un accès administratif RDP/SSH sécurisé aux machines virtuelles SAP sans les exposer à Internet public.

→Déployer Azure Bastion (SKU Standard) dans un sous-réseau dédié au sein du réseau virtuel SAP. Utiliser Bastion pour se connecter aux machines virtuelles via le portail Azure ou des clients natifs.

Pourquoi: Bastion agit comme une boîte de saut sécurisée et gérée, éliminant le besoin d'adresses IP publiques sur les machines virtuelles SAP ou de configurations VPN complexes pour l'accès administratif, réduisant ainsi la surface d'attaque.

Chiffrer les volumes de données SAP à l'aide de clés de chiffrement gérées par le client.

→Utiliser Azure Disk Encryption avec une clé gérée par le client (CMK) stockée dans Azure Key Vault. Ceci peut être combiné avec le chiffrement natif de SAP HANA pour une défense en profondeur.

Pourquoi: Cette configuration donne au client un contrôle total sur les clés de chiffrement des données, répondant aux exigences strictes de conformité et de sécurité pour la gestion du cycle de vie des clés.

Migrer un système SAP sur site avec une base de données non-HANA (par exemple, Oracle, Db2) vers SAP HANA sur Azure.

→Utiliser SAP Software Update Manager (SUM) avec l'option de migration de base de données (DMO). Pour un temps d'arrêt minimal, utiliser les options "DMO with System Move" ou "près de zéro temps d'arrêt" (nZDT).

Pourquoi: DMO combine la conversion de la base de données, la mise à niveau du système et la migration des données en un processus unique et optimisé. C'est l'outil SAP standard pour cette tâche, minimisant les temps d'arrêt par rapport à l'export/import classique.

Migrer un système SAP HANA sur site vers Azure avec le temps d'arrêt le plus faible possible.

→Utiliser la réplication de système SAP HANA (HSR) pour répliquer en continu les données vers la machine virtuelle Azure cible. Effectuer une bascule finale et brève (takeover) pendant la fenêtre de maintenance.

Pourquoi: HSR minimise la fenêtre de temps d'arrêt à quelques minutes, car seule la synchronisation finale et la bascule sont nécessaires. Les méthodes de sauvegarde/restauration ou d'export/import entraînent des heures de temps d'arrêt pour les grandes bases de données.

Transférer un grand volume de données SAP (>10 To) depuis un environnement sur site vers Azure pour la charge de migration initiale lorsque la bande passante réseau est insuffisante.

→Utiliser Azure Data Box pour le transfert initial de données en vrac. Utiliser ExpressRoute ou VPN pour la synchronisation delta ultérieure.

Pourquoi: Data Box offre une méthode de transfert hors ligne plus rapide que les transferts basés sur le réseau avec une bande passante limitée, réduisant considérablement le temps de chargement initial.

Déployer et gérer des systèmes SAP S/4HANA sur Azure en utilisant une expérience simplifiée et guidée.

→Utiliser Azure Center for SAP solutions (ACSS). Les prérequis incluent l'enregistrement du fournisseur `Microsoft.Workloads` et la création d'une identité gérée attribuée par l'utilisateur avec les permissions requises.

Pourquoi: ACSS simplifie le déploiement en regroupant les meilleures pratiques et offre un tableau de bord unique dans le portail Azure pour la gestion de base (démarrage/arrêt, surveillance) et les contrôles de qualité.

Déterminer les tailles de machine virtuelle Azure correctes pour un système SAP nouveau ou migré.

→Utiliser l'outil SAP Quick Sizer pour les nouvelles implémentations. Pour les migrations, analyser les rapports SAP EarlyWatch Alert du système existant pour obtenir l'utilisation actuelle des SAPS et de la mémoire. Mappez-les aux machines virtuelles Azure certifiées SAP.

Pourquoi: Ces outils natifs de SAP fournissent la caractérisation la plus précise de la charge de travail (SAPS, mémoire, E/S), ce qui est essentiel pour sélectionner correctement les ressources Azure et garantir les performances et la supportabilité.

Intégrer un environnement Azure géré par le client avec un système SAP S/4HANA déployé via RISE with SAP.

→SAP gère l'infrastructure Azure sous-jacente dans un abonnement séparé. Établir la connectivité de votre VNet Azure au VNet géré par SAP en utilisant le Peering de VNet.

Pourquoi: RISE est une offre de service géré de SAP. Le Peering de VNet fournit le chemin d'intégration réseau standard, sécurisé et privé entre l'environnement RISE et d'autres charges de travail client dans Azure.

Appliquer les normes d'entreprise et les meilleures pratiques de sécurité à tous les déploiements SAP dans Azure.

→Utiliser Azure Policy pour appliquer des règles, telles que l'exigence de SKU de VM spécifiques, le chiffrement de disques gérés, l'association de NSG ou le marquage obligatoire. Utiliser l'effet `DeployIfNotExists` pour installer automatiquement l'extension de machine virtuelle pour SAP.

Pourquoi: Azure Policy offre une gouvernance automatisée à grande échelle, garantissant que tous les déploiements sont conformes sans dépendre de vérifications manuelles ou de configurations de modèles individuelles.

Valider que l'infrastructure Azure déployée est correctement configurée et répond aux exigences de support SAP avant la mise en production.

→Installer et activer l'Extension de machine virtuelle Azure pour SAP (Enhanced Monitoring). Exécuter l'outil SAP on Azure Quality Check depuis GitHub.

Pourquoi: L'extension de machine virtuelle est obligatoire pour le support SAP. L'outil Quality Check valide de manière proactive les configurations (stockage, réseau, paramètres OS) par rapport à une liste de bonnes pratiques et d'exigences connues.

Implémenter une solution de sauvegarde automatisée et cohérente avec l'application pour les bases de données SAP HANA sur les machines virtuelles Azure.

→Utiliser Azure Backup pour SAP HANA, qui s'intègre via l'interface Backint certifiée SAP. Configurer une politique avec des sauvegardes complètes/différentielles et des sauvegardes fréquentes des journaux pour une récupération à un point dans le temps.

Pourquoi: Azure Backup fournit une solution native, intégrée et certifiée qui automatise la planification, la rétention et la gestion des sauvegardes sans nécessiter de scripts personnalisés ou d'infrastructure de sauvegarde séparée.

Implémenter une surveillance complète et centralisée pour un paysage SAP fonctionnant sur Azure.

→Déployer Azure Monitor for SAP Solutions. Configurer des fournisseurs pour la télémétrie de SAP HANA, NetWeaver, OS (Linux) et des clusters à haute disponibilité.

Pourquoi: Il s'agit d'un service Azure natif conçu pour SAP. Il fournit une télémétrie et des visualisations riches, spécifiques à SAP, centralisant la surveillance de l'ensemble de la pile SAP, de l'infrastructure à l'application.

Appliquer des correctifs de système d'exploitation ou de noyau SAP à un cluster SAP à haute disponibilité avec un temps d'arrêt minimal.

→Utiliser une approche de mise à jour progressive. Mettre le nœud secondaire en mode maintenance, appliquer les correctifs, puis redémarrer. Effectuer un basculement de cluster contrôlé pour faire du nœud corrigé le nœud principal. Enfin, appliquer les correctifs à l'ancien nœud principal.

Pourquoi: Cette approche progressive garantit que le service SAP reste disponible sur un nœud pendant tout le processus de maintenance, minimisant l'interruption du service commercial.

Automatiser le processus de création de copies ou de rafraîchissement de systèmes SAP (par exemple, rafraîchir un système QAS à partir de PRD).

→Utiliser SAP Landscape Management (LaMa) avec le connecteur Azure.

Pourquoi: LaMa orchestre le processus de bout en bout, y compris les tâches d'infrastructure Azure (arrêt/démarrage de VM, instantanés de disques) et l'automatisation post-copie spécifique à SAP (BDLS), réduisant considérablement l'effort manuel.

Valider le plan de reprise après sinistre SAP sans impacter l'environnement de production.

→Utiliser la fonction "Test Failover" d'Azure Site Recovery qui démarre des machines virtuelles répliquées dans un VNet isolé. Pour HSR, utiliser des restaurations basées sur des instantanés vers un système isolé ou une cible de réplication tertiaire dédiée.

Pourquoi: Les tests dans un réseau isolé préviennent les conflits d'IP et toute interférence avec les systèmes de production ou la réplication en cours, permettant une validation sûre et approfondie du manuel de DR.

Planifier les besoins futurs en ressources (CPU, mémoire, stockage) pour un système SAP en croissance sur Azure.

→Utiliser les métriques d'Azure Monitor et Log Analytics pour analyser les tendances d'utilisation historiques. Utiliser ces données pour la prévision. Pour le stockage, tirer parti de la capacité à redimensionner dynamiquement les disques gérés Azure en ligne.

Pourquoi: La gestion proactive de la capacité basée sur les données historiques prévient la dégradation des performances et permet un provisionnement juste-à-temps, optimisant les coûts par rapport à un surprovisionnement initial significatif.

Minimiser les coûts Azure pour l'exécution d'un paysage SAP complet.

→Pour les charges de travail de production, utiliser des instances réservées Azure de 1 ou 3 ans. Pour les systèmes non-production, implémenter des planifications de démarrage/arrêt automatisées via Azure Automation. Utiliser Azure Hybrid Benefit pour les licences éligibles.

Pourquoi: Les instances réservées offrent d'importantes réductions pour les charges de travail prévisibles et 24h/24 et 7j/7. L'arrêt automatique élimine les coûts de calcul pendant les périodes d'inactivité pour les systèmes non-production. Cette combinaison aborde les deux principaux moteurs de coûts.

Suivre et allouer les coûts Azure pour les charges de travail SAP à des unités commerciales, projets ou systèmes SAP (SIDs) spécifiques.

→Implémenter une stratégie de marquage obligatoire pour toutes les ressources Azure. Utiliser des balises comme `CostCenter`, `Environment`, `SAP-SID` et `BusinessOwner`. Analyser les coûts à l'aide d'Azure Cost Management.

Pourquoi: Le marquage est le mécanisme natif d'Azure pour catégoriser les ressources. Un marquage cohérent permet une analyse détaillée des coûts et une refacturation, offrant une visibilité financière essentielle.

Diagnostiquer les problèmes intermittents de connectivité réseau ou de latence entre les machines virtuelles SAP dans Azure.

→Utiliser les outils Azure Network Watcher, spécifiquement Connection Monitor pour tester les chemins et la latence, et les journaux de flux NSG pour analyser et identifier le trafic bloqué.

Pourquoi: Network Watcher fournit des outils proactifs et réactifs pour identifier les problèmes réseau au niveau de la plateforme Azure, ce qui est souvent difficile à diagnostiquer uniquement depuis le système d'exploitation invité.

Automatiser l'application de correctifs OS pour les machines virtuelles SAP tout en garantissant l'arrêt en douceur des applications.

→Utiliser Azure Update Manager avec des scripts pré/post. Le script pré-exécution arrête l'application SAP et la base de données, et le script post-exécution les redémarre une fois l'application des correctifs terminée.

Pourquoi: Ceci combine l'automatisation de la gestion des correctifs Azure avec la connaissance de l'application requise pour SAP, prévenant les incohérences de données qui pourraient survenir lors de l'application de correctifs à un système en cours d'exécution.

Implémenter la haute disponibilité pour les services centraux SAP (ASCS/ERS) ou SAP HANA sur des machines virtuelles Linux SUSE/RHEL.

→Configurer un cluster Pacemaker. Utiliser l'agent `fence_azure_arm` pour STONITH (fencing) afin de prévenir les scénarios de split-brain, authentifié via une identité gérée.

Pourquoi: Pacemaker est la solution de clustering prise en charge par SAP sur Linux. `fence_azure_arm` est le mécanisme natif d'Azure pour isoler de manière fiable un nœud défaillant via les API Azure, ce qui est obligatoire pour un cluster stable.

Implémenter la haute disponibilité pour les services centraux SAP (ASCS/ERS) sur des machines virtuelles Windows Server.

→Configurer un cluster de basculement Windows Server (WSFC). Pour le stockage partagé du cluster, utiliser soit des disques partagés Azure, soit une solution de réplication tierce comme SIOS DataKeeper.

Pourquoi: WSFC est la norme pour le clustering Windows. Les disques partagés Azure fournissent un stockage par blocs partagé natif, tandis que SIOS crée un cluster "shared-nothing", les deux remplaçant le besoin de SAN traditionnels dans le cloud.

Concevoir une stratégie de haute disponibilité (HA) et de reprise après sinistre (DR) pour SAP HANA.

→Pour la HA (dans la région), déployer des machines virtuelles sur plusieurs zones de disponibilité et utiliser la réplication de système SAP HANA (HSR) synchrone (SYNC). Pour la DR (interrégionale), utiliser la HSR asynchrone (ASYNC).

Pourquoi: La réplication synchrone offre un RPO nul mais nécessite une faible latence (<2 ms), ce qui la rend idéale pour la HA entre les zones. La réplication asynchrone tolère une latence interrégionale plus élevée, ce qui en fait le choix pour la DR.

Configurer un équilibreur de charge Azure pour gérer l'adresse IP virtuelle d'un cluster SAP HA (ASCS/ERS ou HANA).

→Utiliser un équilibreur de charge Azure Standard. Activer l'adresse IP flottante (Direct Server Return) sur la règle d'équilibrage de charge. Configurer une sonde d'intégrité sur le port spécifique surveillé par le cluster (par exemple, 620xx pour ASCS).

Pourquoi: Le SKU Standard est requis pour la redondance de zone. L'adresse IP flottante est nécessaire pour que l'adresse IP virtuelle du cluster fonctionne correctement. La sonde d'intégrité spécifique garantit que le trafic n'est envoyé qu'au nœud actif.

Comprendre le rôle de l'Enqueue Replication Server (ERS) dans un cluster SAP ASCS à haute disponibilité.

→L'instance ERS maintient une réplique de la table de verrous SAP de l'instance ASCS active.

Pourquoi: Si l'instance ASCS bascule, la nouvelle instance ASCS démarrée récupère la table de verrous répliquée de l'ERS. Cela préserve les verrous de transaction et permet aux utilisateurs de continuer à travailler sans interruption.

Concevoir une solution complète de reprise après sinistre pour un paysage SAP multi-niveaux.

→Utiliser la réplication native de la base de données pour la couche base de données (par exemple, HSR asynchrone pour HANA). Utiliser Azure Site Recovery (ASR) pour la couche application (ASCS/ERS et serveurs d'applications).

Pourquoi: Cette approche "best-of-breed" assure la cohérence des applications pour la base de données via sa réplication native, tandis qu'ASR offre un moyen rentable et automatisé de répliquer et de basculer les machines virtuelles du serveur d'applications.

Implémenter la haute disponibilité pour une base de données SAP fonctionnant sur Microsoft SQL Server dans des machines virtuelles Azure.

→Utiliser les groupes de disponibilité Always On de SQL Server, généralement en mode de validation synchrone pour la HA au sein d'une région, combinés à un WSFC.

Pourquoi: Always On AG est la solution HA/DR recommandée et entièrement prise en charge pour SQL Server, offrant des capacités de réplication au niveau de la base de données et de basculement automatique.

Implémenter SBD (STONITH Block Device) comme mécanisme de quorum pour un cluster Pacemaker à deux nœuds.

→Configurer un petit disque partagé Azure et l'attacher aux deux nœuds du cluster. Alternativement, configurer un serveur cible iSCSI dédié sur une troisième machine virtuelle.

Pourquoi: Bien que `fence_azure_arm` soit l'agent de fencing principal, SBD fournit un mécanisme de témoin/quorum supplémentaire pour prévenir le split-brain, en particulier dans les clusters sans troisième nœud votant.