Check-list relative à la planification et au déploiement de la charge de travail SAP sur Azure
Article
Cette check-list s’adresse aux clients qui migrent des applications SAP vers l’IaaS (infrastructure as a service) Azure. Les applications SAP de ce document représentent les produits SAP exécutant le noyau SAP, y compris SAP NetWeaver, S/4HANA, BW et BW/4 et d’autres. Pendant toute la durée du projet, un client et/ou un partenaire SAP doit examiner la check-list. Il est important de noter que la plupart des vérifications doivent être effectuées en début de projet et durant la phase de planification. À l’issue du déploiement, toute modification apportée directement à l’infrastructure Azure déployée ou aux versions des logiciels SAP peut s’avérer complexe.
Passez en revue la check-list aux étapes les plus importantes de votre projet. Cela vous permet de détecter les problèmes avant qu’ils ne prennent de l’ampleur. Vous aurez également suffisamment de temps pour remanier et tester les modifications nécessaires. Cette check-list n’est pas exhaustive. Selon votre situation, vous devrez peut-être effectuer plus de vérifications.
La check-list proposée n’inclut pas les tâches réalisées indépendamment d’Azure. Par exemple, les interfaces des applications SAP changent lors d’un transfert vers la plateforme Azure ou vers un fournisseur d’hébergement. La documentation SAP et les notes de support contiennent également d’autres tâches, qui ne sont pas spécifiques à Azure, mais qui doivent faire partie de votre liste de contrôle de planification globale.
Cette check-list peut également être utilisée pour les systèmes déjà déployés. De nouvelles fonctionnalités ou des recommandations modifiées peuvent s’appliquer à votre environnement. Il est donc utile d’examiner régulièrement la check-list pour vous tenir informé des nouvelles fonctionnalités ajoutées à la plateforme Azure.
Le contenu principal de ce document est organisé sous forme d’onglets, dans l’ordre chronologique d’un projet classique. Consultez le contenu de chaque onglet et envisagez chaque onglet suivant pour vous appuyer sur les actions effectuées et les apprentissages obtenus dans la phase précédente. Pour la migration de production, le contenu de tous les onglets doit être pris en compte, et pas seulement l’onglet production. Pour vous aider à mapper les phases de projet classiques avec la définition de phase utilisée dans cet article, consultez le tableau ci-dessous.
Phases de liste de vérification du déploiement
Exemples de phases de projet ou de jalons
Phase de préparation et de planification
Phase de lancement/ conception et définition du projet
Phase pilote
Validation précoce / preuve de concept / pilote
Phase hors production
Fin de la phase de conception détaillée / builds d’environnement hors production / test
Phase de préparation de la production
Répétition générale / test d’acceptation par l’utilisateur / simulation de basculement / vérifications en direct
Phase de préparation et de planification du projet
Au cours de cette phase, vous planifiez la migration de votre charge de travail SAP vers la plateforme Azure. Des documents tels que le guide de planification de SAP dans Azure et Cloud Adoption Framework pour SAP couvrent de nombreux sujets et vous aident en tant qu’informations dans votre préparation. Au minimum, au cours de cette phase, vous devez créer les documents suivants et définir et aborder les éléments suivants de la migration :
Document de conception de haut niveau
Ce document doit contenir :
L’inventaire actuel des composants et applications SAP et un inventaire des applications cibles pour Azure.
Une matrice d’attribution des responsabilités (RACI) qui définit les responsabilités et les attributions des parties impliquées. Démarrez à un niveau élevé et évoluez vers des niveaux plus granulaires pour la planification et les premiers déploiements.
Une architecture de solution de haut niveau. Les meilleures pratiques et les exemples d’architecture du Centre des architectures Azure doivent être consultés.
Les principes de sécurité pour l’exécution des données à impact commercial élevé dans Azure. Pour en savoir plus sur la sécurité des données, commencez par la documentation sur la sécurité Azure.
Stratégie de stockage pour couvrir les périphériques de blocs (disque managé) et les systèmes de fichiers partagés (tels que les Azure Files ou les Azure NetApp Files) qui doivent être affinés en fonction des tailles et des dispositions du système de fichiers dans le document de conception technique.
Document de conception technique
Ce document doit contenir :
Diagramme de blocs pour la solution montrant les applications et services SAP et non SAP
Un projet SAP Quicksizer basé sur des volumes de documents métier. La sortie du Quicksizer est ensuite mappée aux composants de calcul, de stockage et de mise en réseau dans Azure. Alternativement à SAP Quicksizer, le dimensionnement diligent en fonction de la charge de travail actuelle des systèmes SAP sources. En tenant compte des informations disponibles, telles que les rapports de charge de travail SGBD, les rapports SAP EarlyWatch, les indicateurs de performances de calcul et de stockage.
L’architecture de continuité d’activité et de reprise d’activité.
Informations détaillées sur les versions des packs de support SE, DB, noyau et SAP. Toutes les versions de SE prises en charge par SAP NetWeaver ou S/4HANA ne sont pas nécessairement prises en charge sur les machines virtuelles Azure. Il en va de même pour les versions de SGBD. Vérifiez les sources suivantes pour aligner et, si nécessaire, mettre à niveau les versions de SAP, les versions de SGBD et les versions de SE afin de garantir le support SAP et Azure. Vous devez disposer de combinaisons de mises en production prises en charge par SAP et Azure pour bénéficier du support complet de SAP et Microsoft. Si nécessaire, planifiez la mise à niveau de certains composants logiciels. Vous trouverez plus d’informations sur les logiciels SAP, SYSTÈME d’exploitation et SGBD pris en charge ici :
Note SAP N° 2039619. Cette note définit la matrice de prise en charge Oracle pour Azure. Windows et Oracle Linux sont les seuls systèmes d’exploitation pris en charge par Oracle en tant que systèmes d’exploitation invités dans les charges de travail Azure pour SAP. Cette instruction de prise en charge s’applique également à la couche d’application SAP qui exécute des instances SAP, tant qu’elles contiennent le client Oracle.
Les machines virtuelles Azure prises en charge par SAP HANA sont répertoriées sur le site web de SAP. Les détails de chaque entrée contiennent des spécificités et des exigences, notamment la version du système d’exploitation prise en charge. Cela peut ne pas correspondre à la dernière version du système d’exploitation conformément à la note SAP 2235581.
Disques managés attachées à chaque machine virtuelle
Dispositions et dimensionnement du système de fichiers
Disposition et tailles de volume SMB et/ou NFS, points de montage, le cas échéant
Architecture de haute disponibilité, de sauvegarde et de récupération d’urgence
En fonction des objectifs RTO et RPO, définissez l’architecture de haute disponibilité et de récupération d’urgence.
Comprendre l’utilisation de différents types de déploiement pour une protection optimale.
Facteurs à prendre en compte pour le déploiement SGBD des machines virtuelles Azure pour la charge de travail SAP et documents associés. Dans Azure, utiliser une configuration de disque partagé pour la couche SGBD comme décrit pour SQL Server, par exemple, n’est pas prise en charge. Utilisez plutôt des solutions telles que :
Pour la récupération d’urgence dans les régions d’Azure, passez en revue les solutions offertes par les différents fournisseurs de SGBD. La plupart d’entre eux prennent en charge la réplication asynchrone ou la copie des journaux de transaction.
Pour la couche Application SAP, déterminez si vous souhaiterez exécuter vos systèmes de test de régression métier, qui sont idéalement des réplicas de vos déploiements de production, dans la même région Azure ou dans la région de votre récupération d’urgence. Dans le deuxième cas, vous pouvez désigner ce système de régression métier comme cible de la récupération d’urgence pour vos déploiements en production.
Pour les projets qui doivent rester dans une seule région pour des raisons de conformité, envisagez une configuration HADR combinée à l’aide de Zones de disponibilité Azure.
Inventaire de toutes les interfaces SAP et des systèmes connectés (SAP et non SAP).
Conception des services de base. Cette conception doit inclure les éléments suivants, dont la plupart sont couverts par l’accélérateur de zone d’atterrissage pour SAP :
Topologie de réseau dans Azure et affectation de différent environnement SAP
Conception Active Directory et DNS.
Solution de gestion des identités pour les utilisateurs finaux et l’administration
Opérations de sécurité pour les ressources et charges de travail Azure dans
Concept de sécurité pour la protection de votre charge de travail SAP. Cela doit inclure tous les aspects : la surveillance du réseau et du périmètre, la sécurité des applications et des bases de données, la sécurisation des systèmes d’exploitation et toutes les mesures d’infrastructure requises, telles que le chiffrement. Identifiez les exigences avec vos équipes de conformité et de sécurité.
Microsoft recommande un contrat Professional Direct, Premier ou Unified Support. Identifiez vos chemins d’escalade et vos contacts pour le support avec Microsoft. Pour connaître les exigences de support SAP, lisez la note SAP n° 2015553.
Plan de réduction et de migration des données pour la migration des données SAP vers Azure. Pour les systèmes SAP NetWeaver, SAP propose des directives afin de limiter les gros volumes de données. Consultez ce guide SAP consacré à la gestion des données dans les systèmes SAP ERP. Certains de ces contenus s’appliquent également aux systèmes NetWeaver et S/4HANA en général.
Une approche de type déploiement automatisé. De nombreux clients commencent par des scripts, à l’aide d’une combinaison de PowerShell, CLI, Ansible et Terraform.
Les solutions développées par Microsoft pour l’automatisation du déploiement SAP sont les suivantes :
Définissez une cadence régulière de révision de la conception et du déploiement entre vous, en tant que client, l’intégrateur système, Microsoft et les autres parties concernées.
Phase pilote (fortement recommandée)
Vous pouvez exécuter un pilote avant ou pendant la planification et la préparation du projet. Vous pouvez également utiliser la phase pilote pour tester les approches et la conception proposées durant la phase de planification et de préparation. Vous pouvez développer la phase pilote pour en faire une véritable preuve de concept.
Nous vous recommandons de configurer et de valider une solution complète HADR et une conception de sécurité lors d’un déploiement pilote. Certains clients effectuent des tests d’extensibilité au cours de cette phase. D’autres clients ont recours aux déploiements de systèmes « bac à sable » SAP pour une phase pilote. Nous supposons donc que vous avez identifié un système que vous souhaitez migrer vers Azure pour le pilote.
Optimisez le transfert de données vers Azure. Le choix optimal dépend étroitement du scénario. Si une connectivité privée est requise pour la réplication de base de données, Azure ExpressRoute est plus rapide si le circuit ExpressRoute a suffisamment de bande passante. Dans d’autres scénarios, le transfert via Internet est plus rapide. Si vous le souhaitez, utilisez un VPN de migration dédié pour la connectivité privée à Azure. Tout chemin de réseau de migration pendant le pilote doit refléter l’utilisation des systèmes de production futurs, ce qui élimine tout impact sur les charges de travail (SAP ou non SAP) déjà en cours d’exécution dans Azure.
Pour une migration SAP hétérogène qui implique l’exportation et l’importation des données, testez et optimisez les phases d’exportation et d’importation. Pour la migration de grands environnements SAP, passez en revue les meilleures pratiques disponibles. Utilisez l’outil approprié pour le scénario de migration, en fonction de vos versions SAP sources et cibles, du SGBD et de la combinaison de la migration avec d’autres tâches telles que la mise à niveau de mise en production ou même la conversion Unicode ou S/4HANA. SAP fournit le moniteur de migration/SWPM, SAP DMO ou DMO avec le déplacement du système, en plus d’autres approches pour réduire les temps d’arrêt disponibles en tant que service distinct de SAP. Dans les dernières versions de SAP DMO avec déplacement du système, l’utilisation d’azcopy pour le transfert de données sur Internet est également prise en charge, ce qui permet d’obtenir le chemin réseau le plus rapide en mode natif.
Migrer des bases de données très volumineuses (VLDB) vers Azure pour SAP
Validation technique
Calcul/ types de machines virtuelles
Passez en revue les ressources dans les notes de support SAP, dans le répertoire matériel SAP HANA et dans SAP PAM. Assurez-vous que cela correspond aux machines virtuelles prises en charge pour Azure, aux versions de système d’exploitation prises en charge pour ces types de machines virtuelles et aux versions SAP et de SGBD.
Validez à nouveau le dimensionnement de votre application et de l'infrastructure que vous déployez sur Azure. Si vous déplacez des applications existantes, vous pouvez souvent extraire le SAPS nécessaire de l’infrastructure utilisée et de la page web du benchmark SAP et le comparer avec les numéros de SAPS répertoriés sur la note SAP n° 1928533. Consultez également cet article sur les évaluations SAPS.
Évaluez et testez le dimensionnement de vos machines virtuelles Azure pour du stockage et débit réseau maximum des types de machines virtuelles que vous avez choisis durant la phase de planification. Les détails des limites de performances des machines virtuelles sont disponibles. Pour le stockage, il est important de prendre en compte la limite de débit maximal de disque non mis en cache pour le dimensionnement. Examinez attentivement le dimensionnement et les effets temporaires du bursting de disque et de la machine virtuelle.
Procédez aux tests et déterminez si vous souhaitez créer vos propres images du système d’exploitation pour vos machines virtuelles dans Azure ou utiliser une image à partir d’Azure Compute Gallery (anciennement Shared Image Gallery). Si vous utilisez une image d’Azure Compute Gallery, veillez à utiliser une image qui reflète le mieux le contrat de support souscrit auprès de votre fournisseur de SE. Pour certains fournisseurs de systèmes d’exploitation, Azure Compute Gallery vous permet d’intégrer vos images BYOL (apportez votre propre licence). Pour les autres images de SE, le support est compris dans le prix indiqué par Azure.
L’utilisation de propres images de système d’exploitation vous permet de stocker les dépendances d’entreprise requises, telles que les agents de sécurité, le renforcement et les personnalisations directement dans l’image. De cette façon, ils sont déployés immédiatement avec chaque machine virtuelle. Si vous décidez de créer vos propres images de système d’exploitation, vous trouverez de la documentation dans ces articles :
Si vous utilisez des images Linux à partir de la Azure compute galleryet que vous ajoutez un renforcement dans le cadre de votre pipeline de déploiement, vous devez utiliser les images appropriées pour SAP fournies par les fournisseurs Linux.
Le choix d’une image de système d’exploitation détermine le type de génération de machine virtuelle Azure. Azure prend en charge les machines virtuelles Hyper-V de génération 1 et 2. Certaines familles de machines virtuelles sont disponibles en tant que génération 2 uniquement, certaines familles de machines virtuelles sont certifiées pour une utilisation de SAP en tant que génération 2 uniquement (note SAP 1928533) même si Azure autorise les deux générations. Il est recommandé d’utiliser une machine virtuelle de génération 2 pour chaque machine virtuelle du paysage SAP.
Utilisez au minimum le stockage SSD Standard Azure pour les machines virtuelles représentant des couches Application SAP et pour un déploiement de SGBD non sensibles aux performances. Gardez à l’esprit que les différents types de stockage Azure influencent le contrat SLA de disponibilité de machine virtuelle unique.
En général, nous déconseillons l’utilisation de disques HDD Standard Azure pour SAP.
Pour les différents types de SGBD, consultez la documentation générique relative au SGBD lié à SAP et la documentation spécifique au SGBD auxquelles le premier document vous renvoie. Utilisez l’agrégation de disques sur plusieurs disques avec le stockage Premium (v1 ou v2) pour les données de base de données et la zone de journalisation. Vérifiez que l’entrelacement de disque lvm est actif et avec une taille de bande correcte avec la commande 'lvs -a -o+lv_layout,lv_role,stripes,stripe_size,devices' sur Linux, consultez propriétés des espaces de stockage sur Windows.
Utilisez LVM pour tous les disques sur les machines virtuelles Linux, car elle facilite la gestion et l’expansion en ligne. Cela inclut les volumes sur des disques uniques, par exemple /usr/sap.
Mise en réseau
Testez et évaluez votre infrastructure de réseau virtuel et la distribution de vos applications SAP sur les différents réseaux virtuels Azure.
Évaluez l’approche de l’architecture de réseau virtuel hub-and-spokes ou virtual WAN avec des spokes de réseaux virtuels discrets pour la charge de travail SAP. Pour une plus petite échelle, approche de micro-segmentation au sein d’un réseau virtuel Azure unique. Basez cette évaluation sur :
Avantages d’une déconnexion rapide de l’appairage entre les réseaux virtuels Azure par rapport à un changement de groupe de sécurité réseau pour isoler un sous-réseau dans un réseau virtuel. Cette évaluation concerne les cas où les applications ou les machines virtuelles hébergées dans un sous-réseau du réseau virtuel constituent un risque pour la sécurité.
Journalisation et audit centralisés du trafic réseau entre le site local, le monde extérieur et le centre de données virtuel que vous avez créé dans Azure.
Évaluez et testez le chemin des données entre la couche application SAP et la couche SGBD SAP.
Le placement d’appliances virtuelles réseau Azure sur le chemin de communication entre l’application SAP et la couche SGBD des systèmes SAP exécutant le noyau SAP n’est pas pris en charge.
Le placement des couches Application SAP et SGBD SAP sur différents réseaux virtuels Azure non appairés n’est pas pris en charge.
Assurez-vous que la mise en réseau accélérée est activée sur chaque machine virtuelle utilisée pour SAP.
Testez et évaluez la latence du réseau entre les machines virtuelles de la couche Application SAP et celles de la couche SGBD, conformément aux notes SAP n° 500235 et n° 1100926. En plus du niping de SAP, vous pouvez utiliser des outils tels que sockperf ou ethr pour la mesure de la latence tcp. Évaluez les résultats par rapport aux indications de latence du réseau de la note SAP n° 1100926. La latence du réseau doit être modérée ou bonne.
Optimisez le débit réseau sur les machines virtuelles à processeurs virtuels élevés, généralement utilisées pour les serveurs de base de données. Particulièrement important pour le scale-out HANA et tout système SAP volumineux. Suivez les recommandations de cet article pour l’optimisation.
Pour une latence réseau optimale, suivez les instructions des scénarios de placement de proximité de l’article. Aucune utilisation des groupes de placement de proximité pour les modèles de déploiement zonal ou interzone.
Vérifiez la disponibilité, le routage et l’accès sécurisé corrects du paysage SAP à tout point de terminaison Internet nécessaire, comme les référentiels de correctifs de système d’exploitation, les outils de déploiement ou le point de terminaison de service. De même, si votre environnement SAP fournit un service accessible au public, tel que SAP Fiori ou SAProuter, vérifiez qu’il est accessible et sécurisé.
Déploiements de haute disponibilité et de récupération d’urgence
Utilisez toujours l’équilibreur de charge standard pour les environnements cluster. L’équilibreur de charge de base sera mis hors service.
Sélectionnez les options de déploiement appropriées en fonction de votre configuration système préférée au sein d’une région Azure, qu’il s’agisse de couvrir les zones, de résider dans une seule zone ou de fonctionner dans une région sans zone.
Dans le déploiement régional, pour protéger les services centraux SAP et les couches SGBD pour la haute disponibilité à l’aide de la réplication passive, placez les deux nœuds pour les services centraux SAP dans un groupe à haute disponibilité distinct et les deux nœuds SGBD d’un autre groupe à haute disponibilité. Ne mélangez pas de rôles de machine virtuelle d’application à l’intérieur d’un groupe à haute disponibilité.
Pour le déploiement interzone, configurez le système à l’aide d’un groupe identique flexible avec FD=1 et déployez les nœuds de services centraux actifs et passifs et la couche SGBD dans deux zones de disponibilité différentes. Utilisez deux zones de disponibilité ayant la latence la plus faible entre elles.
Pour le déploiement interzonal, il est recommandé d’utiliser un groupe identique flexible avec FD=1 sur le déploiement de zone de disponibilité standard.
Si vous utilisez Azure Load Balancer avec des systèmes d’exploitation invité Linux, vérifiez que le paramètre réseau Linux net.ipv4.tcp_timestamps a la valeur 0. Cette suggestion est incompatible avec les suggestions des anciennes versions de la note SAP n° 2382421. La note SAP mise à jour indique que ce paramètre doit être défini sur 0 pour fonctionner avec les équilibreurs de charge Azure.
Paramètres de délai d’expiration
Consultez les rapports des développeurs de SAP NetWeaver pour les instances SAP pour vous assurer qu’aucune rupture de connexion n’existe entre le serveur de mise en file d’attente et les processus de travail SAP. Vous pouvez éviter ces sauts de connexion en définissant ces deux paramètres de Registre :
HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\KeepAliveTime = 120000. Pour plus d’informations, consultez KeepAliveTime.
HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\KeepAliveInterval = 120000. Pour plus d’informations, consultez KeepAliveInterval.
Pour éviter les délais d’expiration de l’interface utilisateur entre les interfaces graphiques SAP locales et les couches d’application SAP déployées dans Azure, case activée si ces paramètres sont définis dans le fichier default.pfl ou le profil d’instance :
rdisp/keepalive_timeout = 3600
rdisp/keepalive = 20
Pour éviter toute interruption des connexions établies entre le processus de mise en file d’attente SAP et les processus de travaux SAP, vous devez définir le paramètre enque/encni/set_so_keepalive sur true. Voir aussi la note SAP n° 2743751.
Si vous utilisez une configuration de cluster de basculement Windows, assurez-vous que le temps de réaction relatifs aux nœuds non réactifs est correctement défini pour Azure. L’article Réglage des seuils réseau des clusters de basculement répertorie les paramètres et leur effet sur la sensibilité de basculement. En supposant que les nœuds de cluster se trouvent dans le même sous-réseau, vous devez modifier ces paramètres :
SameSubNetDelay = 2000 (nombre de millisecondes entre les « pulsations »)
SameSubNetThreshold = 15 (nombre maximal de pulsations manquées consécutives)
Paramètres ou correctifs du système d’exploitation
Pour exécuter HANA sur SAP, lisez ces notes et documentations, en plus de la documentation spécifique à SAP et d’autres notes de support :
Notes SAP spécifiques à Azure liées aux composants de prise en charge DE SAP BC-OP-NT-AZR ou BC-OP-LNX-AZR. Parcourez les notes en détail, car elles contiennent des solutions mises à jour
Vérifications supplémentaires pour la phase pilote
Testez vos procédures de haute disponibilité et de récupération d’urgence
Simulez des situations de basculement à l’aide d’un outil tel que NotMyFault (Windows) ou en plaçant les systèmes d’exploitation en mode panique ou en désactivant l’interface réseau avec ifdown (Linux). Cette étape vous permet de déterminer si vos configurations de basculement fonctionnent comme prévu.
Mesurez le temps nécessaire à l’exécution d’un basculement. Si les délais sont trop longs, tenez compte des éléments suivants :
Pour SUSE Linux, utilisez des périphériques SBD plutôt que l’agent Azure Fence afin d’accélérer le basculement.
Pour SAP HANA, si le rechargement des données prend trop de temps, songez à augmenter la bande passante de stockage.
Testez votre séquence de sauvegarde/restauration et le minutage, et apportez les corrections adéquates si nécessaire. Vérifiez que les temps de sauvegarde sont suffisants. Vous devez également tester les activités de restauration et de restauration dans le temps. Vérifiez que les temps de restauration sont dans les objectifs RTO de vos contrats SLA, que votre RTO dépende d’une base de données ou d’un processus de restauration de machine virtuelle.
Testez l’architecture et la fonctionnalité de récupération d’urgence inter-régions, vérifiez que le RPO et le RTO correspondent à vos attentes
Vérifications de sécurité
Testez la validité de votre architecture de contrôle d’accès en fonction du rôle Azure (Azure RBAC). La répartition des tâches nécessite de séparer et de limiter l’accès et les autorisations des différentes équipes. Par exemple, les membres de l’équipe SAP Basis doivent pouvoir déployer des machines virtuelles et assigner des disques du Stockage Azure à une machine virtuelle Azure donnée. Cependant, l’équipe SAP Basis ne doit pas être en mesure de créer ses propres réseaux virtuels ou de modifier les paramètres des réseaux virtuels existants. Les membres de l’équipe réseau ne doivent pas être en mesure de déployer des machines virtuelles sur des réseaux virtuels dans lesquels des machines virtuelles sont exécutées sur les couches Application SAP et SGBD. Les membres de cette équipe ne doivent pas non plus être en mesure de modifier les attributs des machines virtuelles, ni même de supprimer des machines virtuelles ou des disques.
Assurez-vous que toutes les ressources qui doivent être chiffrées le sont. Définissez et implémentez des processus pour sauvegarder les certificats, les stocker, y accéder et restaurer les entités chiffrées.
Pour le chiffrement du stockage, le chiffrement côté serveur avec une clé managée de plateforme (SSE-PMK) est activé pour chaque service de stockage utilisé pour SAP dans Azure par défaut, y compris les disques managés, les Azure Files et les Azure NetApp Files. La gestion des clés avec des clés gérées par le client peut être prise en compte, si nécessaire pour la rotation des clés détenues par le client.
Le chiffrement natif de base de données est déployé par la plupart des clients SAP sur Azure pour protéger les données et les sauvegardes SGBD. Transparent Data Encryption (TDE) n’a généralement pas de surcharge de performances notable, augmente considérablement la sécurité et doit être pris en compte. La gestion et l’emplacement des clés de chiffrement doivent être sécurisés. Le chiffrement de base de données se produit à l’intérieur de la machine virtuelle et est indépendant de tout chiffrement de stockage tel que SSE.
Tests de performancesDans SAP, en fonction du suivi et des mesures SAP, effectuez les comparaisons suivantes :
Inventaire et base de référence du système local actuel.
Rapports SAR / perfmon.
STATISTIQUES trace top 10 rapports en ligne.
Collecter l’historique des travaux par lots.
Concentrez les tests pour vérifier les performances des processus métier. Ne comparez pas les indicateurs de performance clés matériels initialement et dans un vide, uniquement lors de la résolution des différences de performances.
Le cas échéant, comparez les 10 premiers rapports en ligne à votre implémentation actuelle.
Le cas échéant, comparez les 10 premiers traitements par lots à votre implémentation actuelle.
Comparez les transferts de données via des interfaces dans le système SAP. Concentrez-vous sur les interfaces pour lesquelles vous savez que le transfert s’effectue entre différents emplacements, par exemple d’un site local vers Azure.
Phase hors production
Lors de cette phase, nous supposons qu’après une preuve de concept ou une phase pilote réussie, vous commencez à déployer des systèmes SAP non destinés à la production vers Azure. Intégrez tout ce que vous avez appris et expérimenté pendant la preuve de concept à ce déploiement. Tous les critères et étapes répertoriés pour les preuves de concept s’appliquent également à ce déploiement.
Au cours de cette phase, vous déployez généralement des systèmes de développement, des systèmes de test unitaire et des systèmes de test de régression métier vers Azure. Nous vous recommandons qu’au moins un des systèmes hors production d’une ligne d’applications SAP dispose de la configuration haute disponibilité complète, comme ce sera le cas pour le futur système de production. Voici quelques tâches que vous devez effectuer lors de cette phase :
Avant de déplacer les systèmes de l’ancienne plateforme vers Azure, recueillez des données sur la consommation des ressources, comme l’utilisation de l’UC, le débit de stockage et les données IOPS. En particulier, collectez ces données non seulement à partir des unités de la couche SGBD, mais aussi à partir des unités de la couche Application. Mesurez également la latence du réseau et du stockage. Adaptez votre dimensionnement et votre conception avec les données capturées. Des outils tels que syststat, KSAR, nmon et nmon analyzer pour Excel doivent être utilisés pour capturer et présenter l’utilisation des ressources pendant les périodes de pointe.
Enregistrez les modèles de temps d’utilisation de la disponibilité de vos systèmes. L’objectif est de déterminer si les systèmes hors production doivent être disponibles 24 heures sur 24, 7 jours sur 7 ou si certains d’entre eux peuvent être arrêtés à certains moments de la semaine ou du mois.
Réévaluez votre choix d’image de système d’exploitation, la génération de machine virtuelle (génération 2 dans le paysage SAP) et la stratégie de correctif du système d’exploitation.
Assurez-vous de remplir les conditions de support requises par SAP en matière de contrats de support Microsoft. Consultez la note SAP 2015553.
Consultez les notes SAP relatives à Azure, comme la note n° 1928533 pour connaître les nouvelles références SKU de machines virtuelles et les nouvelles versions de SE et de SGBD prises en charge. Comparez les tarifs des anciens et nouveaux types de machines virtuelles afin de pouvoir déployer les machines virtuelles qui présentent le meilleur rapport qualité-prix.
Vérifiez à nouveau les notes de support SAP, le répertoire matériel SAP HANA et SAP PAM. Assurez-vous qu’aucune modification n’est apportée aux machines virtuelles prises en charge pour Azure, aux versions de système d’exploitation prises en charge pour ces machines virtuelles et aux versions SAP et de SGBD.
Consultez le site web SAP pour connaître les nouvelles références SKU certifiées HANA dans Azure. Comparez la tarification des nouvelles références SKU à celles que vous avez prévues. Enfin, apportez les modifications nécessaires pour utiliser celles qui ont le meilleur rapport prix/performances.
Adaptez votre automation de déploiement pour utiliser des nouveaux types de machines virtuelles et incorporer les nouvelles fonctionnalités Azure que vous souhaitez utiliser.
À l’issue du déploiement de l’infrastructure, testez et évaluez la latence du réseau entre les machine virtuelles de la couche Application SAP et celles de la couche SGBD, conformément aux notes SAP n° 500235. Évaluez les résultats par rapport aux indications de latence du réseau de la note SAP n° 1100926. La latence du réseau doit être modérée ou bonne. En plus d’utiliser des outils tels que niping, sockperf ou ethr, utilisez l’outil HCMT de SAP pour les mesures réseau entre machines virtuelles HANA pour le scale-out ou la réplication système.
Si vous voyez une latence plus élevée que prévu entre les machines virtuelles, envisagez de suivre les instructions des scénarios de placement de proximité de l’article.
Effectuez toutes les autres vérifications de la preuve de concept avant d’appliquer la charge de travail.
Au fur et à mesure que la charge de travail s’applique, enregistrez la consommation de ressources des systèmes dans Azure. Comparez cette consommation avec les enregistrements de votre ancienne plateforme. Ajustez le dimensionnement des machines virtuelles des futurs déploiements si vous constatez des différences importantes. Gardez à l’esprit que, quand vous réduisez la taille, le stockage et la bande passante réseau des machines virtuelles sont également réduits.
Expérimentez la fonctionnalité et les processus de copie du système. L’objectif est de faciliter la copie d’un système de développement ou d’un système de test afin que les équipes de projet bénéficient rapidement de nouveaux systèmes.
Vous pouvez optimiser et affiner les accès, les autorisations et les processus basés sur les rôles Azure de votre équipe afin d’être sûr de bénéficier de la séparation des tâches. En même temps, assurez-vous que toutes les équipes peuvent effectuer leurs tâches dans l’infrastructure Azure.
Testez les procédures de haute disponibilité et de récupération d’urgence pour permettre à votre personnel d’exécuter ces tâches. Identifiez les défauts et adaptez les nouvelles fonctionnalités Azure que vous intégrez à vos déploiements.
Phase de préparation de la production
Au cours de cette phase, recueillez ce que vous avez appris dans vos déploiements hors production et appliquez-le aux futurs déploiements de production.
Effectuez les mises à niveau nécessaires des versions SAP de vos systèmes de production avant de passer à Azure.
Contactez les membres de la direction pour planifier les tests de fonctionnement et les tests commerciaux à réaliser après la migration du système de production.
Veillez à ce que ces tests soient effectués à l’emplacement d’hébergement actuel, avec les systèmes source. Évitez d’effectuer des essais pour la première fois après que le système a été déplacé vers Azure.
Testez le processus de migration des systèmes de production vers Azure. Si vous ne déplacez pas tous les systèmes de production vers Azure dans le même laps de temps, créez des groupes de systèmes de production qui doivent se trouver au même emplacement d’hébergement. Testez la migration des données, y compris les interfaces et applications non SAP connectées.
Voici quelques méthodes courantes :
Utilisez des méthodes SGBD telles que la sauvegarde/restauration en combinaison avec SQL Server Always On, HANA System Replication ou la copie des journaux de transaction pour alimenter et synchroniser le contenu de la base de données dans Azure.
Utilisez la sauvegarde/restauration pour les bases de données de plus petite taille.
Utilisez le processus SAP DMO pour les scénarios pris en charge pour déplacer ou si vous devez combiner votre migration avec une mise à niveau de version SAP et/ou passer à HANA. N’oubliez pas que certaines combinaisons entre les SGBD source et cible ne sont pas prises en charge. Pour plus d’informations, reportez-vous aux notes de support SAP spécifiques aux différentes versions de DMO. Par exemple, Outil Database Migration Option (DMO) de SUM 2.0 SP15.
Vérifiez si le débit de transfert de données est meilleur via Internet ou via ExpressRoute, au cas où vous auriez besoin de déplacer des sauvegardes ou des fichiers d’exportation SAP. Si vous déplacez des données via Internet, vous devrez peut-être modifier certaines des règles de votre groupe de sécurité réseau/groupe de sécurité d’application à mettre en place pour les futurs systèmes de production.
Avant de migrer des systèmes de votre ancienne plateforme vers Azure, collectez les données de consommation des ressources. Les données utiles incluent l’utilisation du processeur, le débit de stockage et les données IOPS. En particulier, collectez ces données non seulement à partir des unités de la couche SGBD, mais aussi à partir des unités de la couche Application. Mesurez également la latence du réseau et du stockage.
Vérifiez à nouveau les notes SAP et les paramètres de système d’exploitation requis, le répertoire matériel SAP HANA et SAP PAM. Assurez-vous qu’aucune modification n’est apportée aux machines virtuelles prises en charge pour Azure, aux versions de système d’exploitation prises en charge dans ces machines virtuelles et aux versions SAP et de SGBD.
Mettez à jour votre automation de déploiement pour considérer les dernières décisions que vous avez prises sur les types de machines virtuelles et les fonctionnalités Azure.
Créez un playbook pour réagir aux événements de maintenance Azure planifiés. Déterminez l’ordre dans lequel les systèmes et les machines virtuelles doivent être redémarrés pour une maintenance planifiée.
Effectuez des exercices, testez et documentez les procédures de haute disponibilité et de récupération d’urgence pour permettre à votre personnel d’exécuter ces tâches pendant la migration et immédiatement après la décision de mise en service.
Phase de mise en production
Lors de la phase de mise en service, veillez à suivre les playbooks que vous avez développés au cours des phases précédentes. Exécutez les étapes que vous avez testées et expérimentées. N’acceptez pas les changements de dernière minute pour les configurations et processus. Effectuez également cette procédure :
Vérifiez que la supervision du portail Azure et les autres outils de supervision fonctionnent. Utilisez des outils Azure tels qu’Azure Monitor pour la supervision de l’infrastructure. Azure Monitor pour SAP pour une combinaison de KPI de système d’exploitation et d’application, ce qui vous permet d’intégrer tous dans un tableau de bord pour une visibilité pendant et après la mise en service.
Pour les indicateurs de performances clés du système d’exploitation :
Sur Linux, assurez-vous que l’outil sysstat est installé et qu’il capture les détails à intervalles réguliers
Après la migration des données, effectuez tous les tests de validation, comme convenu avec les membres de la direction. Acceptez uniquement les résultats des tests de validation lorsque vous disposez des résultats des systèmes source d’origine.
Vérifiez que les interfaces fonctionnent et que d’autres applications peuvent communiquer avec les systèmes de production nouvellement déployés.
Vérifiez le système de transport et de correction via la transaction SAP STMS.
Effectuez des sauvegardes des bases de données une fois le système mis en production.
Effectuez des sauvegardes des machines virtuelles de la couche Application SAP après que le système est mis en production.
Pour les systèmes SAP ne faisant pas partie de la phase de mise en service actuelle, mais qui communiquent avec les systèmes SAP que vous avez transférés vers Azure durant cette phase, vous devez réinitialiser le tampon de noms d’hôte dans SM51. Cela supprimera les anciennes adresses IP mises en cache associées aux noms des instances de l’application que vous avez déplacées vers Azure.
Post-production
Cette phase consiste à surveiller, exploiter et administrer le système. D’un point de vue SAP, les tâches que vous deviez habituellement exécuter avec votre ancien emplacement d’hébergement s’appliquent. Effectuez également ces tâches spécifiques à Azure :
Passez en revue les factures Azure pour les systèmes à facturation élevée. Installez une culture de finOps et créez une fonctionnalité d’optimisation des coûts Azure dans votre organisation.
Optimisez le rapport qualité-prix côté machines virtuelles et côté stockage.
Une fois votre SAP sur Azure stabilisé, vous devez vous concentrer sur une culture de dimensionnement continu et de révision de capacité. Contrairement au niveau local, où la taille est longue, le dimensionnement approprié est un avantage clé de l’exécution de la charge de travail SAP sur Azure, et une planification diligente de la capacité est essentielle.
Optimisez les moments où vous pouvez arrêter les systèmes.
Une fois votre solution stabilisée dans Azure, envisagez de vous éloigner d’un modèle commercial de paiement à l’utilisation et de tirer parti des instances réservées Azure.
Planifiez et exécutez des exercices de récupération d’urgence réguliers.
Définissez et implémentez votre stratégie autour de « l’Evergreening continu », afin d’aligner votre propre feuille de route avec la feuille de route SAP sur Azure de Microsoft afin de tirer parti de l’avancement de la technologie.
Liste de vérification de l’infrastructure SAP sur Azure
Après avoir déployé l’infrastructure et les applications et avant le début de chaque migration, vérifiez que :
Les types de machines virtuelles appropriés ont été déployés avec la configuration d’attributs et les tailles de stockage qui conviennent.
Les machines virtuelles sont sur une version et un correctif à jour du système d’exploitation, SGBD et noyau SAP, et l’uniforme du système d’exploitation, de la base de données et du noyau SAP dans tout le paysage
Les machines virtuelles sont sécurisées et renforcées selon les besoins et de manière uniforme dans l’environnement respectif.
Les machines virtuelles ont été déployées dans un groupe identique flexible avec FD=1 entre les zones de disponibilité ou dans un groupe à haute disponibilité.
Les machines virtuelles de génération 2 ont été déployées. Les machines virtuelles de génération 1 ne doivent pas être utilisées pour les nouveaux déploiements.
Assurez-vous que, dans les machines virtuelles, les espaces de stockage ou les jeux de bandes ont été correctement générés sur les systèmes de fichiers qui nécessitent plus que le disque, tels que les données SGBD et les zones de journalisation.
Une taille de bande correcte et une taille de bloc du système de fichiers sont utilisées, si elles sont indiquées dans les guides SGBD respectifs
Le stockage et la mise en cache des machines virtuelles Azure sont utilisés de manière appropriée
Assurez-vous que seuls les disques contenant les journaux en ligne SGBD sont mis en cache avec l’Accélérateur d'écriture None+.
D’autres disques avec le stockage Premium utilisent les paramètres de cache none ou ReadOnly, selon l’utilisation
Utilisation des services Azure (Azure Files ou Azure NetApp Files) pour tous les volumes ou partages SMB ou NFS. Les volumes NFS ou les partages SMB sont accessibles par l’environnement SAP respectif ou le ou les systèmes SAP individuels. Le routage réseau vers le serveur NFS/SMB passe par l’espace d’adressage du réseau privé, en utilisant un point de terminaison privé si nécessaire.
Aucune appliance virtuelle réseau ne réside dans le chemin de communication entre l’application SAP et la couche SGBD des systèmes SAP basés sur SAP NetWeaver, ou Plateforme ABAP.
Tous les équilibreurs de charge pour les composants à haute disponibilité SAP utilisent l’équilibreur de charge standard avec des ports IP et haute disponibilité flottants activés.
L’application SAP et les machines virtuelles SGBD sont placées dans des sous-réseaux identiques ou différents d’un réseau virtuel ou dans des réseaux virtuels directement appairés.
Les règles de groupe de sécurité d’application et de réseau permettent la communication souhaitée et planifiée, et bloquent celle-ci en cas de besoin.
Les paramètres liés au délai d’expiration ont été correctement définis, décrits précédemment.
Si vous utilisez des groupes de placement de proximité, vérifiez si les groupes à haute disponibilité et leurs machines virtuelles sont déployés sur le PPG approprié.
La latence du réseau entre les machines virtuelles de la couche Application SAP et les machines virtuelles de SGBD est testée et validée comme décrit dans les notes SAP n° 500235 et n° 1100926. Évaluez les résultats par rapport aux indications de latence du réseau de la note SAP n° 1100926. La latence du réseau doit être modérée ou bonne.
Le chiffrement a été mis en œuvre là où cela était nécessaire et avec la méthode de chiffrement appropriée.
Les propres clés de chiffrement sont protégées contre la perte, la destruction ou l’utilisation malveillante.
Les interfaces et autres applications sont en mesure de connecter l’infrastructure nouvellement déployée.
Vérifications et insights automatisés dans le paysage SAP
Plusieurs des vérifications ci-dessus sont vérifiées de manière automatisée avec SAP sur Azure Quality Check Tool. Ces vérifications peuvent être exécutées de manière automatisée avec le projet open source fourni. Bien qu’aucune correction automatique des problèmes détectés ne soit effectuée, l’outil met en garde contre la configuration contre Microsoft recommandations.
D’autres outils pour faciliter les vérifications de déploiement et documenter les résultats, planifier les étapes de correction suivantes et généralement optimiser votre paysage SAP sur Azure sont les suivants :
Révision de Azure Well-Architected Framework Une évaluation de votre charge de travail axée sur les cinq principaux piliers de la fiabilité, de la sécurité, de l’optimisation des coûts, de l’excellence des opérations et de l’efficacité des performances. Prend en charge les charges de travail SAP et recommande d’exécuter une révision au début et après chaque phase de projet.
Vérifications d’inventaire Azure pour SAP Un open source classeur Azure Monitor, qui montre votre inventaire Azure avec intelligence pour mettre en évidence la dérive de configuration et améliorer la qualité.