Planifier et mettre en œuvre un déploiement SAP sur Azure

Article
06/25/2024

Dans Azure, les organisations peuvent obtenir les ressources et services cloud dont elles ont besoin sans effectuer un long cycle d’approvisionnement. Toutefois, l’exécution de votre charge de travail SAP dans Azure nécessite des connaissances sur les options disponibles et une planification minutieuse pour choisir les composants et l’architecture Azure pour alimenter votre solution.

Azure offre une plateforme complète pour l’exécution de vos applications SAP. Les offres IaaS (Infrastructure as a Service) Et PaaS (Platform as a Service) Azure combinent pour vous offrir des choix optimaux pour un déploiement réussi de l’ensemble de votre paysage d’entreprise SAP.

Cet article complète la documentation SAP et les notes SAP, les sources principales pour plus d’informations sur l’installation et le déploiement de logiciels SAP sur Azure et d’autres plateformes.

Définitions

Tout au long de cet article, nous utilisons les termes suivants :

Composant SAP: application SAP individuelle telle que SAP S/4HANA, SAP ECC, SAP BW ou SAP Solution Manager. Un composant SAP peut être basé sur des technologies ABAP (Advanced Business Application Programming) ou Java traditionnelles, ou il peut s’agir d’une application qui n’est pas basée sur SAP NetWeaver, comme SAP BusinessObjects.
Environnement SAP: plusieurs composants SAP qui sont regroupés logiquement pour effectuer une fonction métier, comme le développement, l’assurance qualité, la formation, la récupération d’urgence ou la production.
Paysage SAP: ensemble complet de ressources SAP dans le paysage informatique d’une organisation. Le paysage SAP comprend tous les environnements de production et hors production.
Système SAP : La combinaison d'une couche de système de gestion de base de données (DBMS) et d'une couche d'application. Deux exemples sont un système de développement SAP ERP et un système de test SAP BW. Dans un déploiement Azure, ces deux couches ne peuvent pas être distribuées entre l’environnement local et Azure. Un système SAP doit être déployé sur site ou déployé dans Azure. Toutefois, vous pouvez utiliser différents systèmes au sein d’un paysage SAP dans Azure ou localement.

Ressources

Le point d’entrée de la documentation qui décrit comment héberger et exécuter une charge de travail SAP sur Azure est Prise en main de SAP sur une machine virtuelle Azure. Dans l’article, vous trouverez des liens vers d’autres articles qui couvrent :

Spécificités de la charge de travail SAP pour les options de stockage, de mise en réseau et prises en charge.
Guides SAP DBMS pour divers systèmes SGBD sur Azure.
Guides de déploiement SAP, manuels et automatisés.
Détails de haute disponibilité et de récupération d’urgence pour une charge de travail SAP sur Azure.
Intégration à SAP sur Azure avec d’autres services et applications tierces.

Important

Pour les prérequis, le processus d’installation et les détails sur les fonctionnalités SAP spécifiques, il est important de lire attentivement la documentation et les guides SAP. Cet article traite uniquement des tâches spécifiques pour les logiciels SAP installés et gérés sur une machine virtuelle Azure.

Les notes SAP suivantes constituent la base des instructions Azure pour les déploiements SAP :

Numéro de la note	Intitulé
1928533	Applications SAP sur Azure : Produits et tailles pris en charge
2015553	SAP sur Azure : Conditions préalables au support
2039619	Applications SAP sur Azure à l’aide d’Oracle Database
2233094	DB6 : Applications SAP sur Azure à l’aide d’IBM Db2 pour Linux, UNIX et Windows
1999351	Résolution des problèmes de surveillance Azure améliorée pour SAP
1409604	Virtualisation sur Windows : supervision améliorée
2191498	SAP sur Linux avec Azure : supervision améliorée
2731110	Prise en charge des appliances virtuelles réseau (NVA) pour SAP sur Azure

Pour connaître les limitations générales par défaut et maximale des abonnements et des ressources Azure, consultez limites, quotas et contraintes d’abonnement Azure, de quotas et de contraintes.

Scénarios

Les services SAP sont souvent considérés parmi les applications les plus stratégiques d’une entreprise. L’architecture et les opérations des applications sont complexes et il est important de s’assurer que toutes les exigences en matière de disponibilité et de performances sont remplies. Une entreprise pense généralement soigneusement à quel fournisseur de cloud choisir d’exécuter ces processus métier critiques.

Azure est la plateforme de cloud public idéale pour les applications SAP critiques et les processus métier. La plupart des logiciels SAP actuels, y compris les systèmes SAP NetWeaver et SAP S/4HANA, peuvent être hébergés dans l’infrastructure Azure aujourd’hui. Azure propose plus de 800 types de processeurs et de VMs dotés de plusieurs téraoctets de mémoire.

Pour obtenir une description des scénarios pris en charge et de certains scénarios qui ne sont pas pris en charge, consultez Scénarios pris en charge par SAP sur les machines virtuelles Azure. Vérifiez ces scénarios et les conditions indiquées comme non prises en charge lorsque vous planifiez l’architecture que vous souhaitez déployer sur Azure.

Pour déployer avec succès des systèmes SAP sur Azure IaaS ou sur IaaS en général, il est important de comprendre les différences significatives entre les offres de cloud privé traditionnel et les offres IaaS. Un hébergeur ou un sous-traitant traditionnel adapte l'infrastructure (réseau, stockage et type de serveur) à la charge de travail qu'un client souhaite héberger. Dans un déploiement IaaS, il incombe au client ou au partenaire d’évaluer sa charge de travail potentielle et de choisir les bons composants Azure de VMs, de stockage et de réseau.

Pour collecter des données pour la planification de votre déploiement sur Azure, il est important de :

Déterminez les produits et versions SAP pris en charge dans Azure.
Évaluez si les versions du système d’exploitation que vous prévoyez d’utiliser sont prises en charge avec les VMs Azure que vous choisiriez pour vos produits SAP.
Déterminez quelles versions du DBMS sur des VMs spécifiques sont prises en charge pour vos produits SAP.
Évaluez si la mise à niveau ou la mise à jour de votre paysage SAP est nécessaire pour s'aligner sur les versions requises du système d'exploitation et du DBMS afin d'obtenir une configuration prise en charge.
Évaluez si vous devez migrer vers différents systèmes d’exploitation pour déployer dans Azure.

Les détails sur les composants SAP pris en charge sur Azure, les unités d'infrastructure Azure et les versions du système d'exploitation et des DBMS associées sont expliqués dans le logiciel SAP pris en charge pour les déploiements Azure. Les connaissances que vous acquérez en évaluant la prise en charge et les dépendances entre les versions SAP, les versions du système d’exploitation et les versions du DBMS ont un impact substantiel sur vos efforts pour migrer vos systèmes SAP vers Azure. Vous découvrez si des efforts de préparation importants sont impliqués, par exemple, si vous devez mettre à niveau votre version SAP ou basculer vers un autre système d’exploitation.

Premières étapes pour planifier un déploiement

La première étape de la planification du déploiement ne consiste pas à rechercher des VMs disponibles pour exécuter des applications SAP.

Les premières étapes pour planifier un déploiement consistent à travailler avec les équipes de conformité et de sécurité de votre organisation pour déterminer quelles sont les conditions limites pour déployer quel type de charge de travail SAP ou de processus métier dans un cloud public. Le processus peut prendre du temps, mais il constitue un travail de base essentiel à réaliser.

Si votre organisation a déjà déployé des logiciels dans Azure, le processus peut être facile. Si votre entreprise est plus au début du parcours, des discussions plus importantes peuvent être nécessaires pour déterminer les conditions limites, les conditions de sécurité et l’architecture d’entreprise qui permettent à certaines données SAP et processus métier SAP d’être hébergés dans un cloud public.

Planifier pour la conformité

Pour obtenir la liste des offres de conformité Microsoft qui peuvent vous aider à planifier vos besoins en matière de conformité, consultez offres de conformité Microsoft.

Planifier la sécurié

Pour plus d’informations sur les problèmes de sécurité spécifiques à SAP, tels que le chiffrement des données pour les données au repos ou un autre chiffrement dans un service Azure, consultez vue d’ensemble du chiffrement Azure et Sécurité pour votre environnement SAP.

Organiser les ressources Azure

Avec la révision de sécurité et de conformité, si vous n’avez pas encore effectué cette tâche, planifiez la façon dont vous organisez vos ressources Azure. Le processus comprend la prise de décisions sur les éléments suivants :

Convention de dénomination que vous utilisez pour chaque ressource Azure, par exemple pour les VMs et les groupes de ressources.
Conception d’abonnement et de groupe d’administration pour votre charge de travail SAP, par exemple si plusieurs abonnements doivent être créés par charge de travail, par niveau de déploiement ou pour chaque unité commerciale.
Utilisation d’Azure Policy à l’échelle de l’entreprise pour les abonnements et les groupes d’administration.

Pour vous aider à prendre les bonnes décisions, de nombreux détails de l’architecture d’entreprise sont décrits dans la Azure Cloud Adoption Framework.

Ne sous-estimez pas la phase initiale du projet dans votre planification. Ce n’est que lorsque vous aurez mis en place des accords et des règles en matière de conformité, de sécurité et d’organisation des ressources Azure que vous pourrez avancer dans la planification de votre déploiement.

Les étapes suivantes planifient l’emplacement géographique et l’architecture réseau que vous déployez dans Azure.

Zones géographiques et régions Azure

Les services Azure sont disponibles dans des régions Azure distinctes. Une région Azure est une collection de centres de données. Les centres de données contiennent le matériel et l’infrastructure qui hébergent et exécutent les services Azure disponibles dans la région. L’infrastructure comprend un grand nombre de nœuds qui fonctionnent en tant que nœuds de calcul ou nœuds de stockage, ou qui exécutent des fonctionnalités réseau.

Pour obtenir la liste des régions Azure, consultez Géographies Azure. Pour une carte interactive, consultez Infrastructure globale Azure.

Toutes les régions Azure n’offrent pas les mêmes services. En fonction du produit SAP que vous souhaitez exécuter, de vos exigences de dimensionnement, ainsi que du système d'exploitation et du SGBD dont vous avez besoin, il est possible qu'une région particulière n'offre pas les types de VMs requis pour votre scénario. Par exemple, si vous exécutez SAP HANA, vous avez généralement besoin de VMs des différentes familles de VMs de la série M. Ces familles de machines virtuelles sont déployées uniquement dans un sous-ensemble de régions Azure.

Lorsque vous commencez à planifier et à réfléchir aux régions à choisir comme région principale et éventuellement comme région secondaire, vous devez déterminer si les services dont vous avez besoin pour vos scénarios sont disponibles dans les régions que vous envisagez. Vous pouvez apprendre exactement quels types de machines virtuelles, les types de stockage Azure et d’autres services Azure sont disponibles dans chaque région dans Produits disponibles par région.

Régions Azure appairées

Dans une région jumelée Azure, la réplication de certaines données est activée par défaut entre les deux régions. Pour plus d’informations, consultez Réplication inter-région dans Azure : continuité d’activité et reprise d’activité.

La réplication des données dans une paire de régions est liée aux types de stockage Azure que vous pouvez configurer pour répliquer dans une région jumelée. Pour plus d’informations, consultez redondance du stockage dans une région secondaire.

Les types de stockage qui prennent en charge la réplication des données de régions appariées sont des types de stockage qui ne conviennent pas aux composants SAP et à une charge de travail DBMS. La convivialité de la réplication du stockage Azure est limitée au Stockage Blob Azure (à des fins de sauvegarde), aux partages de fichiers et aux volumes, ainsi qu'à d'autres scénarios de stockage à haute latence.

Lorsque vous recherchez les régions jumelées et les services que vous souhaitez utiliser dans vos régions primaires ou secondaires, il est possible que les types de machines virtuelles ou de services Azure que vous envisagez d’utiliser dans votre région primaire ne sont pas disponibles dans la région jumelée que vous souhaitez utiliser comme région secondaire. Vous pouvez également déterminer qu’une région jumelée Azure n’est pas acceptable pour votre scénario en raison de raisons de conformité des données. Pour ces scénarios, vous devez utiliser une région non souhaitée comme région secondaire ou de récupération d’urgence, et vous devez configurer vous-même une partie de la réplication des données.

Zones de disponibilité

De nombreuses régions Azure utilisent zones de disponibilité à des emplacements physiquement distincts au sein d’une région Azure. Chaque zone de disponibilité est constituée d’un ou plusieurs centres de données équipés d’une alimentation indépendante, d’un refroidissement et d’un réseau. Un exemple d’utilisation d’une zone de disponibilité pour améliorer la résilience consiste à déployer deux VMs dans deux zones de disponibilité distinctes dans Azure. Un autre exemple consiste à implémenter un cadre de haute disponibilité pour votre système SAP DBMS dans une zone de disponibilité et à déployer SAP (A)SCS dans une autre zone de disponibilité, afin d'obtenir le meilleur SLA dans Azure.

Pour plus d’informations sur les contrats SLA de machine virtuelle dans Azure, consultez la dernière version de contrats SLA de machines virtuelles. Étant donné que les régions Azure développent et étendent rapidement, la topologie des régions Azure, le nombre de centres de données physiques, la distance entre les centres de données et la distance entre les zones de disponibilité Azure évolue. La latence du réseau change à mesure que l’infrastructure change.

Suivez les instructions de configurations de charge de travail SAP avec des zones de disponibilité Azure lorsque vous choisissez une région qui possède des zones de disponibilité. Déterminez également quel modèle de déploiement zonal convient le mieux à vos besoins, à la région que vous choisissez et à votre charge de travail.

Domaines d’erreur

Les domaines d’erreur représentent une unité physique de défaillance. Un domaine d’erreur est étroitement lié à l’infrastructure physique contenue dans les centres de données. Bien qu’un panneau physique ou un rack puisse être considéré comme un domaine d’erreur, il n’existe pas de mappage direct un-à-un entre un élément de calcul physique et un domaine d’erreur.

Lorsque vous déployez plusieurs VMs dans le cadre d'un système SAP, vous pouvez influencer indirectement le contrôleur de structure Azure pour déployer vos VMs sur différents domaines de pannes, afin de pouvoir répondre aux exigences en matière de SLA de disponibilité. Toutefois, vous n’avez pas de contrôle direct sur la distribution des domaines de pannes sur une unité d’échelle Azure (un ensemble de centaines de nœuds de calcul ou de nœuds de stockage et de mise en réseau) ni sur l’attribution de VMs à un domaine de pannes spécifique. Pour manœuvrer le contrôleur de structure Azure afin de déployer un ensemble de machines virtuelles sur différents domaines de pannes, vous devez attribuer un groupe à haute disponibilité Azure aux VMs au moment du déploiement. Pour plus d’informations, consultez groupes à haute disponibilité.

Domaines de mise à jour

Les domaines de mise à jour représentent une unité logique qui définit la manière dont une machine virtuelle dans un système SAP composé de plusieurs VMs est mise à jour. Lorsqu’une mise à jour de plateforme se produit, Azure passe par le processus de mise à jour de ces domaines de mise à jour un par un. En répartissant les VMs au moment du déploiement sur différents domaines de mise à jour, vous pouvez protéger votre système SAP contre les temps d'arrêt potentiels. Comme pour les domaines d’erreur, une unité d’échelle Azure est divisée en plusieurs domaines de mise à jour. Pour manœuvrer le contrôleur de structure Azure afin de déployer un ensemble de VMs sur différents domaines de mise à jour, vous devez attribuer un groupe à haute disponibilité Azure aux machines virtuelles au moment du déploiement. Pour plus d’informations, consultez groupes à haute disponibilité.

Groupes à haute disponibilité

Les VMs Azure au sein d’un groupe à haute disponibilité Azure sont distribuées par le contrôleur de structure Azure sur différents domaines de pannes. La répartition sur différents domaines de pannes vise à empêcher l'arrêt de toutes les VMs d'un système SAP pendant la maintenance de l'infrastructure ou si une panne se produit dans un domaine de pannes. Par défaut, les VMs ne font pas partie d’un groupe à haute disponibilité. Vous pouvez ajouter une machine virtuelle dans un groupe à haute disponibilité uniquement au moment du déploiement ou lorsqu’une machine virtuelle est redéployée.

Pour en savoir plus sur les groupes à haute disponibilité Azure et sur la relation entre les groupes à haute disponibilité et les domaines d’erreur, consultez groupes à haute disponibilité Azure.

Important

Les zones de disponibilité et les groupes à haute disponibilité dans Azure s’excluent mutuellement. Vous pouvez déployer plusieurs VMs dans une zone de disponibilité spécifique ou dans un groupe à haute disponibilité. Mais pas à la fois la zone de disponibilité et le groupe à haute disponibilité peuvent être attribués à une machine virtuelle.

Vous pouvez combiner des groupes à haute disponibilité et des zones de disponibilité si vous utilisez groupes de placement de proximité.

Lorsque vous définissez des groupes à haute disponibilité et essayez de mélanger plusieurs machines virtuelles de différentes familles de VMs au sein d'un même groupe à haute disponibilité, vous pouvez rencontrer des problèmes qui vous empêchent d'inclure un type de machine virtuelle spécifique dans un groupe à haute disponibilité. La raison est que le groupe à haute disponibilité est lié à une unité d’échelle qui contient un type spécifique d’hôte de calcul. Un type spécifique d’hôte de calcul ne peut s’exécuter que sur certains types de familles de machines virtuelles.

Par exemple, vous créez un groupe à haute disponibilité et vous déployez la première machine virtuelle dans le groupe à haute disponibilité. La première machine virtuelle que vous ajoutez au groupe à haute disponibilité se trouve dans la famille de machines virtuelles Edsv5. Lorsque vous essayez de déployer une deuxième machine virtuelle, une machine virtuelle qui se trouve dans la famille M échoue. La raison en est que les VMs de la famille Edsv5 ne fonctionnent pas sur le même matériel hôte que les VMs de la famille M.

Le même problème peut survenir si vous redimensionnez les VMs. Si vous essayez de déplacer une machine virtuelle hors de la famille Edsv5 et dans un type de machine virtuelle qui se trouve dans la famille M, le déploiement échoue. Si vous effectuez un redimensionnement vers une famille de VMs qui ne peut pas être hébergée sur le même matériel hôte, vous devez arrêter toutes les VMs qui se trouvent dans votre groupe à haute disponibilité et les redimensionner toutes pour pouvoir s'exécuter sur l'autre type de machine hôte. Pour plus d'informations sur les SLA des machines virtuelles déployées dans un groupe à haute disponibilité, consultez SLA des VMs.

Groupes de machines virtuelles identiques avec orchestration flexible

Groupes de machines virtuelles identiques avec l’orchestration flexible fournissent un regroupement logique de machines virtuelles gérées par la plateforme. Vous avez la possibilité de créer un groupe identique dans une région ou de l’étendre dans les zones de disponibilité. Lors de la création d’un groupe identique flexible au sein d’une région avec platformFaultDomainCount>1 (FD>1), les machines virtuelles déployées dans le groupe identique sont réparties entre le nombre spécifié de domaines d’erreur dans la même région. D’un autre côté, la création du groupe identique flexible dans les zones de disponibilité avec platformFaultDomainCount=1 (FD=1) distribuerait les VMs dans la zone spécifiée et le groupe identique distribuerait également les VMs entre différents domaines de pannes au sein de la zone dans la mesure du possible.

Pour la charge de travail SAP, seul un groupe identique flexible avec FD=1 est pris en charge. L’avantage d’utiliser des groupes identiques flexibles avec FD=1 pour le déploiement interzone au lieu du déploiement traditionnel de zone de disponibilité, est que les machines virtuelles déployées avec le groupe identique seraient réparties entre différents domaines d’erreur au sein de la zone de manière optimale. Pour en savoir plus sur le déploiement de charge de travail SAP avec un groupe identique, consultez guide de déploiement de mise à l’échelle de machines virtuelles flexibles.

Lors du déploiement d’une charge de travail SAP à haute disponibilité sur Azure, il est important de tenir compte des différents types de déploiement disponibles et de la façon dont ils peuvent être appliqués dans différentes régions Azure (par exemple, entre les zones, dans une seule zone ou dans une région sans zone). Pour plus d’informations, consultez options de déploiement de haute disponibilité pour lesde charge de travail SAP.

Conseil

Actuellement, il n’existe aucun moyen direct de migrer la charge de travail SAP déployée dans des groupes à haute disponibilité ou des zones de disponibilité pour une mise à l’échelle flexible avec FD=1. Pour effectuer le changement, vous devez recréer la machine virtuelle et le disque avec des contraintes de zone à partir des ressources existantes en place. Un projet open source inclut des fonctions PowerShell que vous pouvez utiliser comme exemple pour modifier une machine virtuelle déployée dans un groupe à haute disponibilité ou une zone de disponibilité en un groupe identique flexible avec FD=1. Un article de blog vous montre comment modifier un système SAP HA ou non HA déployé dans un groupe à haute disponibilité ou une zone de disponibilité en un groupe identique flexible avec FD=1.

Groupes de placement de proximité

La latence du réseau entre les VMs SAP individuelles peut avoir des implications significatives sur les performances. Le temps d'aller-retour du réseau entre les serveurs d'applications SAP et le DBMS peut notamment avoir un impact significatif sur les applications métiers. Idéalement, tous les éléments de calcul exécutant vos VMs SAP sont situés aussi près que possible. Cette option n’est pas possible dans toutes les combinaisons et Azure peut ne pas savoir quelles VMs conserver ensemble. Dans la plupart des situations et régions, le placement par défaut répond aux exigences de latence de parcours aller-retour réseau.

Lorsque le placement par défaut ne répond pas aux exigences du réseau au sein d’un système SAP, groupes de placement de proximité peuvent répondre à ce besoin. Vous pouvez utiliser des groupes de placement de proximité avec les contraintes d’emplacement de la région Azure, de la zone de disponibilité et du groupe à haute disponibilité pour augmenter la résilience. Avec un groupe de placement de proximité, la combinaison à la fois de la zone de disponibilité et du groupe à haute disponibilité lors de la définition de différents domaines de mise à jour et d’échec est possible. Un groupe de placement de proximité ne doit contenir qu’un seul système SAP.

Bien que le déploiement dans un groupe de placement de proximité puisse entraîner un positionnement optimisé pour la latence, le déploiement à l’aide d’un groupe de placement de proximité présente également des inconvénients. Certaines familles de machines virtuelles ne peuvent pas être combinées dans un groupe de placement de proximité, ou vous risquez de rencontrer des problèmes si vous redimensionnez entre les familles de machines virtuelles. Les contraintes des familles de machines virtuelles, des régions et des zones de disponibilité peuvent ne pas prendre en charge la colocalisation. Pour plus d’informations et pour en savoir plus sur les avantages et les défis potentiels liés à l’utilisation d’un groupe de placement de proximité, consultez scénarios de groupe de placement de proximité.

Les VMs qui n'utilisent pas de groupes de placement de proximité doivent constituer la méthode de déploiement par défaut dans la plupart des situations pour les systèmes SAP. Cette valeur par défaut est particulièrement vraie pour les déploiements zonaux (une seule zone de disponibilité) et interzonaux (VMs réparties entre deux zones de disponibilité) d'un système SAP. L’utilisation de groupes de placement de proximité doit être limitée aux systèmes SAP et aux régions Azure si nécessaire uniquement pour des raisons de performances.

Mise en réseau Azure

Azure dispose d’une infrastructure réseau qui est mappée à tous les scénarios que vous pouvez implémenter dans un déploiement SAP. Dans Azure, vous disposez des fonctionnalités suivantes :

Accès aux services Azure et accès à des ports spécifiques dans les VMs utilisées par les applications.
Accès direct aux VMs via Secure Shell (SSH) ou Windows Remote Desktop (RDP) pour la gestion et l'administration.
Communication interne et résolution de noms entre les VMs et par les services Azure.
Connectivité locale entre un réseau local et des réseaux Azure.
Communication entre les services déployés dans différentes régions Azure.

Pour des informations détaillées sur la mise en réseau, consultez Réseau virtuel Azure.

La conception de la mise en réseau est généralement la première activité technique que vous effectuez lors du déploiement sur Azure. La prise en charge d’une architecture d’entreprise centrale comme SAP fait souvent partie des exigences globales en matière de mise en réseau. Au cours de la phase de planification, vous devez documenter l’architecture réseau proposée autant que possible. Si vous apportez une modification ultérieurement, comme la modification d’une adresse réseau de sous-réseau, vous devrez peut-être déplacer ou supprimer des ressources déployées.

Réseaux virtuels Azure

Un réseau virtuel est un bloc de construction fondamental pour votre réseau privé dans Azure. Vous pouvez définir la plage d’adresses du réseau et séparer la plage en sous-réseaux réseau. Un sous-réseau réseau peut être disponible pour une machine virtuelle SAP ou il peut être dédié à un service ou à un objectif spécifique. Certains services Azure, comme Azure Virtual Network et Azure Application Gateway, nécessitent un sous-réseau dédié.

Un réseau virtuel agit comme une limite de réseau. Une partie de la conception requise lorsque vous planifiez votre déploiement consiste à définir les plages d’adresses réseau virtuel, sous-réseaux et réseau privé. Vous ne pouvez pas modifier l'attribution du réseau virtuel pour les ressources telles que les cartes d'interface réseau (NIC) pour les VMs après le déploiement des VMs. Toute modification apportée à un réseau virtuel ou à une plage d'adresses de sous-réseau peut nécessiter le déplacement de toutes les ressources déployées vers un autre sous-réseau.

Votre conception réseau doit répondre à plusieurs exigences pour le déploiement SAP :

Aucune appliance virtuelle réseau, telle qu'un pare-feu, n'est placée dans le chemin de communication entre l'application SAP et la couche SGBD des produits SAP via le noyau SAP, tel que S/4HANA ou SAP NetWeaver.
Les restrictions de routage réseau sont appliquées par groupes de sécurité réseau (NSG) au niveau du sous-réseau. Regroupez les adresses IP des VMs dans des groupes de sécurité d'application (ASG) qui sont gérés dans les règles NSG et fournissez des regroupements d'autorisations par rôle, niveau et SID.
Les VMs des applications et des bases de données SAP s'exécutent sur le même réseau virtuel, dans le même sous-réseau ou dans des sous-réseaux différents d'un seul réseau virtuel. Utilisez différents sous-réseaux pour les VMs d’application et de base de données. Vous pouvez également utiliser une application dédiée et des ASG de DBMS pour regrouper les règles applicables à chaque type de charge de travail au sein du même sous-réseau.
La mise en réseau accélérée est activée sur toutes les cartes réseau de toutes les VMs pour les charges de travail SAP lorsque cela est techniquement possible.
Assurez-vous que l’accès sécurisé pour les dépendances vis-à-vis des services centraux, notamment pour la résolution de noms (DNS), la gestion des identités (domaines Windows Server Active Directory/Microsoft Entra ID) et l’accès administratif.
Fournissez l’accès aux points de terminaison publics et par les points de terminaison publics, selon les besoins. Par exemple, la gestion Azure pour les opérations ClusterLabs Pacemaker dans la haute disponibilité ou pour les services Azure comme Sauvegarde Azure.
Utilisez plusieurs cartes réseau uniquement si elles sont nécessaires pour créer des sous-réseaux désignés dotés de leurs propres routes et règles NSG.

Pour obtenir des exemples d’architecture réseau pour le déploiement SAP, consultez les articles suivants :

Considérations relatives au réseau virtuel

Certaines configurations de mise en réseau virtuelle ont des considérations spécifiques à prendre en compte.

La configuration d'appliances virtuelles réseau dans le chemin de communication entre la couche d'application SAP et la couche SGBD des composants SAP à l'aide du noyau SAP, tel que S/4HANA ou SAP NetWeaver, n'est pas prise en charge.

Les appliances réseau virtuelles dans les chemins de communication peuvent facilement doubler la latence du réseau entre deux partenaires de communication. Elles peuvent également limiter le débit dans les chemins critiques entre la couche Application SAP et la couche SGBD. Dans certains scénarios, les appliances virtuelles réseau peuvent entraîner l'échec des clusters Pacemaker Linux.

Le chemin de communication entre la couche application SAP et la couche DBMS doit être un chemin direct. La restriction n’inclut pas règles ASG et NSG si les règles ASG et NSG autorisent un chemin de communication direct.

D'autres scénarios dans lesquels les appareils virtuels réseau ne sont pas pris en charge sont :
- Chemins de communication entre les machines virtuelles Azure qui représentent les nœuds de cluster Pacemaker Linux et les appareils SBD, comme décrit dans Haute disponibilité pour SAP NetWeaver sur les VMs Azure sur SUSE Linux Enterprise Server pour les applications SAP.
- Chemins de communication entre les machines virtuelles Azure et un partage de fichiers avec montée en puissance parallèle Windows Server configuré comme décrit dans Mettre en cluster une instance SAP ASCS/SCS sur un cluster de basculement Windows à l'aide d'un partage de fichiers dans Azure.
La séparation de la couche d'application SAP et de la couche SGBD en différents réseaux virtuels Azure n'est pas prise en charge. Nous vous recommandons de séparer la couche d'application SAP et la couche DBMS en utilisant des sous-réseaux au sein du même réseau virtuel Azure plutôt qu'en utilisant des réseaux virtuels Azure différents.

Si vous configurez un scénario non pris en charge qui sépare deux couches du système SAP dans différents réseaux virtuels, les deux réseaux virtuels doivent êtreappairés.

Le trafic réseau entre deux appairés réseaux virtuels Azure est soumis aux coûts de transfert. Chaque jour, un énorme volume de données, composé de plusieurs téraoctets, est échangé entre la couche application SAP et la couche DBMS. Vous pouvez encourir des coûts substantiels si la couche d’application SAP et la couche DBMS sont séparées entre deux réseaux virtuels Azure appairés.

Résolution de noms et services de domaine

La résolution du nom d’hôte en adresse IP via DNS est souvent un élément crucial pour la mise en réseau SAP. Vous avez de nombreuses options pour configurer la résolution de noms et d’adresses IP dans Azure.

Souvent, une entreprise a une solution DNS centrale qui fait partie de l’architecture globale. Plusieurs options d’implémentation de la résolution de noms dans Azure en mode natif, au lieu de configurer vos propres serveurs DNS, sont décrites dans résolution de noms pour les ressources dans les réseaux virtuels Azure.

Comme pour les services DNS, il peut être nécessaire que Windows Server Active Directory soit accessible par les VMs ou les services SAP.

Affectation d’adresses IP

Une adresse IP pour une carte réseau reste revendiquée et utilisée tout au long de l'existence de la carte réseau d'une VM. La règle s’applique à affectation d’adresses IP dynamiques et statiques. Il reste vrai si la machine virtuelle est en cours d’exécution ou est arrêtée. L'attribution IP dynamique est libérée si la carte réseau est supprimée, si le sous-réseau change ou si la méthode d'allocation devient statique.

Il est possible d'attribuer des adresses IP fixes aux VMs au sein d'un réseau virtuel Azure. Les adresses IP sont souvent réaffectées pour les systèmes SAP qui dépendent de serveurs DNS externes et d’entrées statiques. L'adresse IP reste attribuée, soit jusqu'à ce que la machine virtuelle et sa carte réseau soient supprimées, soit jusqu'à ce que l'adresse IP ne soit plus attribuée. Vous devez prendre en compte le nombre total de VMs (en cours d'exécution et arrêtées) lorsque vous définissez la plage d'adresses IP du réseau virtuel.

Pour plus d’informations, consultez Créer une machine virtuelle qui a une adresse IP privée statique.

Remarque

Vous devez choisir entre une allocation d’adresses IP statique et dynamique pour les VMs Azure et leurs cartes réseau. Le système d'exploitation invité de la VM obtiendra l'adresse IP attribuée à la carte réseau au démarrage de la VM. Vous ne devez pas attribuer d'adresses IP statiques du système d'exploitation invité à NIC. Certains services Azure comme Azure Backup reposent sur le fait qu'au moins la carte réseau principale est définie sur DHCP et non sur des adresses IP statiques à l'intérieur du système d'exploitation. Pour plus d’informations, consultez Résoudre les problèmes de sauvegarde de machine virtuelle Azure.

Adresses IP secondaires pour la virtualisation du nom d’hôte SAP

La carte réseau de chaque machine virtuelle Azure peut se voir attribuer plusieurs adresses IP. Une adresse IP secondaire peut être utilisée pour un nom d’hôte virtuel SAP, qui est mappé à un enregistrement DNS A ou à un enregistrement DNS PTR. Une adresse IP secondaire doit être attribuée à la configuration IP de la carte réseau Azure. Une adresse IP secondaire doit également être configurée de manière statique dans le système d'exploitation, car les adresses IP secondaires ne sont souvent pas attribuées via DHCP. Chaque adresse IP secondaire doit provenir du même sous-réseau auquel NIC est liée. Une adresse IP secondaire peut être ajoutée et supprimée de NIC Azure sans arrêter ni désallouer la machine virtuelle. Pour ajouter ou supprimer l'adresse IP principale de NIC, la VM doit être libérée.

L’équilibreur de charge Azure est utilisé par les architectures de haute disponibilité SAP avec des clusters Pacemaker. Dans ce scénario, l’équilibreur de charge active les noms d’hôtes virtuels SAP. Pour obtenir des conseils généraux sur l’utilisation des noms d’hôtes virtuels, consultez la note SAP 962955.

Azure Load Balancer avec des VMs exécutant SAP

Un équilibreur de charge est généralement utilisé dans les architectures à haute disponibilité pour fournir des adresses IP flottantes entre des nœuds de cluster actifs et passifs. Vous pouvez également utiliser un équilibreur de charge pour une seule machine virtuelle pour contenir une adresse IP virtuelle pour un nom d’hôte virtuel SAP. L'utilisation d'un équilibreur de charge pour une seule VM est une alternative à l'utilisation d'une adresse IP secondaire sur une carte réseau ou à l'utilisation de plusieurs NIC dans le même sous-réseau.

L'équilibreur de charge standard modifie le chemin d'accès sortant par défaut car son architecture est sécurisée par défaut. Les VMs situées derrière un équilibreur de charge standard risquent de ne plus pouvoir atteindre les mêmes points de terminaison publics. Voici quelques exemples de point de terminaison pour un référentiel de mises à jour du système d’exploitation ou un point de terminaison public des services Azure. Pour connaître les options permettant de fournir une connectivité sortante, consultez Connectivité de point de terminaison public pour les machines virtuelles à l'aide de l'équilibreur de charge standard Azure.

Conseil

L’équilibreur de charge de base ne doit être utilisé avec aucune architecture SAP dans Azure. L'équilibreur de charge de base devrait être retiré.

Plusieurs vNIC par VM

Vous pouvez définir plusieurs cartes d'interface réseau virtuelle (vNIC) pour une machine virtuelle Azure, chaque vNIC étant attribuée à n'importe quel sous-réseau du même réseau virtuel que la vNIC principale. Avec la possibilité de disposer de plusieurs vNIC, vous pouvez commencer à configurer la séparation du trafic réseau, si nécessaire. Par exemple, le trafic client est acheminé via la vNIC principale et une partie du trafic administrateur ou back-end est acheminée via une deuxième vNIC. En fonction du système d'exploitation et de l'image que vous utilisez, il peut être nécessaire de configurer des itinéraires de trafic pour les cartes réseau à l'intérieur du système d'exploitation pour assurer un routage correct.

Le type et la taille d'une VM déterminent le nombre de vNIC qu'une VM peut se voir attribuer. Pour plus d'informations sur les fonctionnalités et les restrictions, consultez Attribuer plusieurs adresses IP aux machines virtuelles à l'aide du portail Azure.

L'ajout de vNIC à une machine virtuelle n'augmente pas la bande passante réseau disponible. Toutes les interfaces réseau partagent la même bande passante. Nous vous recommandons d'utiliser plusieurs cartes réseau uniquement si les VMs doivent accéder à des sous-réseaux privés. Nous recommandons un modèle de conception qui s'appuie sur la fonctionnalité NSG et qui simplifie les exigences en matière de réseau et de sous-réseau. La conception doit utiliser autant d’interfaces réseau que possible, et de manière optimale. Une exception est la mise à l'échelle horizontale de HANA, dans laquelle une vNIC secondaire est requise pour le réseau interne de HANA.

Avertissement

Si vous utilisez plusieurs vNIC sur une machine virtuelle, nous vous recommandons d'utiliser le sous-réseau d'une carte réseau principale pour gérer le trafic réseau des utilisateurs.

Mise en réseau accélérée

Pour réduire davantage la latence du réseau entre les VMs Azure, nous vous recommandons de confirmer que la mise en réseau accélérée Azure est activée sur chaque machine virtuelle qui exécute une charge de travail SAP. Bien que la mise en réseau accélérée soit activée par défaut pour les nouvelles machines virtuelles, conformément à la liste de contrôle de déploiement, vous devez vérifier l'état. Les avantages de la mise en réseau accélérée sont considérablement améliorés en matière de performances réseau et de latences. Utilisez-le lorsque vous déployez des VMs Azure pour les charges de travail SAP sur toutes les machines virtuelles prises en charge, en particulier pour la couche d'application SAP et la couche SAP DBMS. La documentation liée contient des dépendances de prise en charge sur les versions du système d’exploitation et les instances de machine virtuelle.

Connectivité locale

Le déploiement SAP dans Azure suppose qu’une architecture réseau centralisée et à l’échelle de l’entreprise et un hub de communication sont en place pour activer la connectivité locale. La connectivité réseau locale est essentielle pour permettre aux utilisateurs et aux applications d’accéder au paysage SAP dans Azure d’accéder à d’autres services d’organisation centraux, tels que le DNS central, le domaine et l’infrastructure de gestion des correctifs et de la sécurité.

Vous avez de nombreuses options pour fournir une connectivité locale pour votre déploiement SAP sur Azure. Le déploiement réseau est le plus souvent une topologie de réseau hub-spoke, ou une extension de la topologie hub-spoke, un WAN virtuel global.

Pour les déploiements SAP locaux, nous vous recommandons d'utiliser une connexion privée sur Azure ExpressRoute. Pour les petites charges de travail SAP, les régions éloignées ou les petits bureaux, une connectivité VPN sur site est disponible. L’utilisation de ExpressRoute avec une connexion VPN site à site en tant que chemin de basculement est une combinaison possible des deux services.

Connectivité Internet sortante et entrante

Votre paysage SAP nécessite une connectivité à Internet, qu’il s’agisse de recevoir des mises à jour de référentiel de système d’exploitation, d’établir une connexion aux applications SAP SaaS sur leurs points de terminaison publics ou d’accéder à un service Azure via son point de terminaison public. De même, vous devrez peut-être fournir l’accès à vos clients aux applications SAP Fiori, avec des utilisateurs Internet accédant aux services fournis par votre paysage SAP. Votre architecture réseau SAP vous oblige à planifier le chemin vers Internet et toutes les demandes entrantes.

Sécurisez votre réseau virtuel à l'aide des règles NSG, en utilisant des balises de service réseau pour les services connus et en établissant le routage et l'adressage IP vers votre pare-feu ou autre appareil virtuel réseau. Toutes ces tâches ou considérations font partie de l’architecture. Les ressources des réseaux privés doivent être protégées par des pare-feu de couche 4 et de couche 7.

Les voies de communication avec Internet font l'objet d'une architecture de bonnes pratiques.

Machines virtuelles Azure pour les charges de travail SAP

Certaines familles de machines virtuelles Azure conviennent particulièrement aux charges de travail SAP, et plus précisément à une charge de travail SAP HANA. La façon de trouver le type de machine virtuelle approprié et sa capacité à prendre en charge votre charge de travail SAP est décrite dans Quel logiciel SAP est pris en charge pour les déploiements Azure. En outre, la note SAP 1928533 répertorie toutes les VMs Azure certifiées et leurs capacités de performances telles que mesurées par le benchmark SAP Application Performance Standard (SAPS) et les limitations, le cas échéant. Les types de machines virtuelles certifiés pour une charge de travail SAP n'utilisent pas de surprovisionnement des CPU et de mémoire.

Au-delà de la sélection des types de machines virtuelles pris en charge, vous devez vérifier si ces types de machines virtuelles sont disponibles dans une région spécifique en fonction de Produits disponibles par région. Au moins aussi important est de déterminer si les fonctionnalités suivantes pour une machine virtuelle correspondent à votre scénario :

Ressources processeur et mémoire
Opérations d’entrée/sortie par seconde (IOPS)
Fonctionnalités réseau
Le nombre de disques pouvant être connectés
Possibilité d’utiliser certains types de stockage Azure

Pour obtenir ces informations pour une famille et un type FM spécifiques, consultez Tailles des machines virtuelles dans Azure.

Modèles de tarification pour les VMs Azure

Pour un modèle tarifaire de machine virtuelle, vous pouvez choisir l’option que vous préférez utiliser :

Modèle tarifaire de paiement à l’utilisation
Un plan réservé ou d’épargne d’un an
Un plan réservé ou d’épargne de trois ans
Modèle de tarification spot

Pour obtenir des informations détaillées sur la tarification des machines virtuelles pour différents services, systèmes d’exploitation et régions Azure, consultez tarification des machines virtuelles.

Pour en savoir plus sur la tarification et la flexibilité des plans d’épargne d’un an et trois ans et des instances réservées, consultez les articles suivants :

Pour plus d’informations sur la tarification spot, consultez azure Spot Virtual Machines.

Le prix pour le même type de machine virtuelle peut varier selon les régions Azure. Certains clients bénéficient du déploiement dans une région Azure moins coûteuse. Par conséquent, les informations sur la tarification par région peuvent être utiles à mesure que vous planifiez.

Azure offre également la possibilité d’utiliser un hôte dédié. L’utilisation d’un hôte dédié vous permet de contrôler davantage les cycles de mise à jour corrective pour les services Azure. Vous pouvez planifier la mise à jour corrective pour prendre en charge vos propres planifications et cycles. Cette offre est spécifiquement destinée aux clients qui ont une charge de travail qui ne suit pas le cycle normal d’une charge de travail. Pour plus d’informations, consultez Hôtes dédiés Azure.

L’utilisation d’un hôte dédié Azure est prise en charge pour une charge de travail SAP. Plusieurs clients SAP qui souhaitent contrôler davantage les correctifs d’infrastructure et les plans de maintenance utilisent des hôtes dédiés Azure. Pour plus d'informations sur la manière dont Microsoft gère et corrige l'infrastructure Azure qui héberge les machines virtuelles, consultez Maintenance des VMs dans Azure.

Système d'exploitation pour les VMs

Lorsque vous déployez de nouvelles VMs pour un paysage SAP dans Azure, que ce soit pour installer ou migrer un système SAP, il est important de choisir le système d'exploitation adapté à votre charge de travail. Azure offre une grande sélection d’images de système d’exploitation pour Linux et Windows et de nombreuses options appropriées pour les systèmes SAP. Vous pouvez également créer ou charger des images personnalisées à partir de votre environnement local, ou vous pouvez consommer ou généraliser à partir de galeries d’images.

Pour plus d’informations sur les options disponibles :

Recherchez des images Azure Marketplace à l’aide d’Azure CLI ou d’Azure PowerShell.
Créez des images personnalisées pour Linux ou Windows.
Utilisez le générateur d'images VM.

Planifiez une infrastructure de mise à jour du système d’exploitation et ses dépendances pour votre charge de travail SAP, si nécessaire. Envisagez d’utiliser un environnement intermédiaire de référentiel pour conserver tous les niveaux d’un paysage SAP (bac à sable, développement, préproduction et production) synchronisés à l’aide des mêmes versions de correctifs et de mises à jour pendant votre période de mise à jour.

VM de génération 1 et génération 2

Dans Azure, vous pouvez déployer une machine virtuelle en tant que génération 1 ou génération 2. La prise en charge des VMs de génération 2 dans Azure répertorie les familles de VMs Azure que vous pouvez déployer en tant que génération 2. L’article répertorie également les différences fonctionnelles entre les VMs de génération 1 et de génération 2 dans Azure.

Lorsque vous déployez une machine virtuelle, l’image du système d’exploitation que vous choisissez détermine si la machine virtuelle sera une machine virtuelle de génération 1 ou une machine virtuelle de génération 2. Les dernières versions de toutes les images de système d’exploitation pour SAP disponibles dans Azure (Red Hat Enterprise Linux, SuSE Enterprise Linux et Windows ou Oracle Enterprise Linux) sont disponibles à la fois dans la génération 1 et la génération 2. Il est important de sélectionner soigneusement une image en fonction de la description de l’image pour déployer la génération correcte de machine virtuelle. De même, vous pouvez créer des images de système d’exploitation personnalisées en tant que génération 1 ou 2, et elles affectent la génération de la machine virtuelle lors du déploiement de la machine virtuelle.

Remarque

Nous vous recommandons d'utiliser des VMs de génération 2 dans tous vos déploiements SAP dans Azure, quelle que soit la taille de la machine virtuelle. Toutes les dernières VMs Azure pour SAP sont compatibles avec la génération 2 ou sont limitées à la seule génération 2. Certaines familles de VM ne prennent actuellement en charge que les VM de génération 2. Certaines familles de machines virtuelles qui seront bientôt disponibles peuvent prendre en charge uniquement la génération 2.

Vous pouvez déterminer si une machine virtuelle est de génération 1 ou seulement de génération 2 en fonction de l’image de système d’exploitation sélectionnée. Vous ne pouvez pas modifier une machine virtuelle existante d’une génération à une autre génération.

La modification d’une machine virtuelle déployée de la génération 1 à la génération 2 n’est pas possible dans Azure. Pour modifier la génération de machine virtuelle, vous devez déployer une nouvelle machine virtuelle qui est la génération souhaitée et réinstaller votre logiciel sur la nouvelle génération de machine virtuelle. Cette modification affecte uniquement l'image VHD de base de la machine virtuelle et n'a aucun impact sur les disques de données ou les partages Network File System (NFS) ou Server Message Block (SMB) attachés. Les disques de données, les partages NFS ou les partages SMB qui ont été attribués à une machine virtuelle de génération 1 peuvent être attachés à une nouvelle machine virtuelle de génération 2.

Certaines familles de VMs, comme Mv2-series, ne prennent en charge que la génération 2. La même exigence peut être vraie pour les nouvelles familles de machines virtuelles à l’avenir. Dans ce scénario, une machine virtuelle de génération 1 existante ne peut pas être redimensionnée pour fonctionner avec la nouvelle famille de machines virtuelles. En plus des exigences de génération 2 de la plateforme Azure, vos composants SAP peuvent avoir des exigences liées à la génération d’une machine virtuelle. Pour en savoir plus sur les exigences de génération 2 pour la famille de machines virtuelles que vous choisissez, consultez la note SAP 1928533.

Limites de performances pour les VMs Azure

En tant que cloud public, Azure dépend de l’infrastructure de partage de manière sécurisée tout au long de sa base de clients. Pour activer la mise à l’échelle et la capacité, les limites de performances sont définies pour chaque ressource et service. Du côté calcul de l’infrastructure Azure, il est important de prendre en compte les limites définies pour chaque taille de machine virtuelle.

Chaque VM a un quota différent sur le débit du disque et du réseau, le nombre de disques pouvant être connectés, si elle dispose d'un stockage temporaire local doté de ses propres limites de débit et d'IOPS, la taille de la mémoire et le nombre de processeurs virtuels disponibles.

Remarque

Lorsque vous prenez des décisions sur la taille de machine virtuelle pour une solution SAP sur Azure, vous devez prendre en compte les limites de performances pour chaque taille de machine virtuelle. Les quotas décrits dans la documentation représentent les valeurs théoriques pouvant être atteintes. La limite de performances des IOPS par disque peut être atteinte avec de petites valeurs d'entrée/sortie (E/S) (par exemple, 8 Ko), mais elle peut ne pas être atteinte avec des valeurs d'E/S élevées (par exemple, 1 Mo).

Comme pour les VMs, les mêmes limites de performances existent pour chaque type de stockage pour une charge de travail SAP et pour tous les autres services Azure.

Lorsque vous planifiez et choisissez les VMs à utiliser dans votre déploiement SAP, tenez compte des facteurs suivants :

Commencez par les exigences en matière de mémoire et de CPU. Séparez les exigences SAPS en matière de puissance CPU entre la partie DBMS et les parties d'application SAP. Pour les systèmes existants, les SAPS liés au matériel que vous utilisez souvent peuvent être déterminés ou estimés sur la base des SAP Standard Application Benchmarks existants. Pour les systèmes SAP nouvellement déployés, effectuez un exercice de dimensionnement pour déterminer la configuration requise SAPS pour le système.
Pour les systèmes existants, le débit d'E/S et les IOPS sur le serveur DBMS doivent être mesurés. Pour les nouveaux systèmes, l'exercice de dimensionnement du nouveau système devrait également vous donner une idée générale des exigences d'E/S du côté du DBMS. Si vous n’êtes pas sûr, vous devez finalement effectuer une preuve de concept.
Comparez les exigences SAPS pour le serveur DBMS avec les SAPS que les différents types de machines virtuelles d'Azure peuvent fournir. Les informations relatives au SAPS des différents types de machines virtuelles Azure sont documentées dans la note SAP 1928533. L'accent doit d'abord être mis sur la machine virtuelle du DBMS, car la couche de base de données est la couche d'un système SAP NetWeaver qui n'évolue pas dans la plupart des déploiements. En revanche, la taille des instances pour la couche d’application SAP peut être augmentée. Les guides DBMS individuels décrivent les configurations de stockage recommandées.
Résumez vos résultats pour :
- Nombre de VMs Azure que vous comptez utiliser.
- Famille de VM individuelle et SKU de VM pour chaque couche SAP : DBMS, (A)SCS et serveur d'applications.
- Mesures de débit d’E/S ou exigences de capacité de stockage calculées.

Service de grandes instances HANA

Azure offre des fonctionnalités de calcul permettant d'exécuter une grande base de données HANA évolutive ou évolutive sur une offre dédiée appelée SAP HANA sur Azure Large Instances. Cette offre étend les VMs disponibles dans Azure.

Remarque

Le service de grandes instances HANA est en mode coucher de soleil et n’accepte pas de nouveaux clients. La fourniture d’unités pour les clients de grandes instances HANA existantes est toujours possible.

Stockage pour SAP sur Azure

Les VMs Azure utilisent diverses options de stockage pour la persistance. En termes simples, les VMs peuvent être divisées en types de stockage persistant et temporaire ou non persistant.

Vous pouvez choisir parmi plusieurs options de stockage pour les charges de travail SAP et pour des composants SAP spécifiques. Pour plus d’informations, consultez stockage Azure pour les charges de travail SAP. L’article décrit l’architecture de stockage pour chaque partie de SAP : système d’exploitation, fichiers binaires d’applications, fichiers de configuration, données de base de données, fichiers journaux et fichiers de trace, et interfaces de fichiers avec d’autres applications, qu’elles soient stockées sur disque ou accessibles sur des partages de fichiers.

Disque temporaire sur les VMs

La plupart des VMs Azure pour SAP proposent un disque temporaire qui n'est pas un disque managé. Utilisez un disque temporaire uniquement pour les données utilisables. Les données sur un disque temporaire peuvent être perdues pendant des événements de maintenance imprévus ou pendant le redéploiement de machine virtuelle. Les caractéristiques de performances du disque temporaire les rendent idéales pour les fichiers d’échange/page du système d’exploitation.

Aucune application ou aucune donnée de système d’exploitation fiable ne doit être stockée sur un disque temporaire. Dans les environnements Windows, le lecteur temporaire est généralement accessible en tant que lecteur D. Dans les systèmes Linux, le point de montage est souvent /dev/sdb device, /mnt ou /mnt/resource.

Certaines VMs ne proposent pas de lecteur temporaire. Si vous envisagez d’utiliser ces tailles de machine virtuelle pour SAP, vous devrez peut-être augmenter la taille du disque du système d’exploitation. Pour plus d’informations, consultez la note SAP 1928533. Pour les machines virtuelles disposant d’un disque temporaire, obtenez des informations sur la taille du disque temporaire ainsi que sur les limites d’IOPS et de débit pour chaque série de VMs dans Tailles des machines virtuelles dans Azure.

Vous ne pouvez pas redimensionner directement entre une série de machines virtuelles qui a des disques temporaires et une série de machines virtuelles qui n’ont pas de disques temporaires. Actuellement, un redimensionnement entre deux familles de machines virtuelles échoue. Une résolution consiste à recréer la machine virtuelle qui n’a pas de disque temporaire dans la nouvelle taille à l’aide d’un instantané de disque du système d’exploitation. Conservez tous les autres disques de données et l’interface réseau. Découvrez comment redimensionner une taille de machine virtuelle dotée d'un disque temporaire local vers une taille de machine virtuelle qui n'en a pas.

Partages réseau et volumes pour SAP

Les systèmes SAP nécessitent généralement un ou plusieurs partages de fichiers réseau. Les partages de fichiers sont généralement l’une des options suivantes :

Un répertoire de transport SAP (/usr/sap/trans or TRANSDIR).
Volumes SAP ou volumes partagés sapmnt ou volumes saploc pour déployer plusieurs serveurs d’applications.
Volumes d'architecture haute disponibilité pour SAP (A)SCS, SAP ERS ou une base de données (/hana/shared).
Interfaces de fichiers qui exécutent des applications tierces pour l’importation et l’exportation de fichiers.

Dans ces scénarios, nous vous recommandons d’utiliser un service Azure, tel que Azure Files ou Azure NetApp Files. Si ces services ne sont pas disponibles dans les régions que vous choisissez, ou s’ils ne sont pas disponibles pour votre architecture de solution, les alternatives sont de fournir des partages de fichiers NFS ou SMB à partir d’applications auto-gérées, basées sur des machines virtuelles ou à partir de services tiers. Consultez la note SAP 2015553 sur les limitations de la prise en charge de SAP si vous utilisez des services tiers pour les couches de stockage dans un système SAP dans Azure.

En raison de la nature souvent critique des partages réseau et parce qu’ils constituent souvent un point de défaillance unique dans une conception (pour la haute disponibilité) ou un processus (pour l’interface de fichiers), nous vous recommandons de vous appuyer sur chaque service natif Azure pour son propre compte. disponibilité, SLA et résilience. Dans la phase de planification, il est important de prendre en compte ces facteurs :

Conception de partage NFS ou SMB, y compris les partages à utiliser par ID système SAP (SID), par paysage et par région.
Dimensionnement de sous-réseau, y compris l’exigence IP pour les points de terminaison privés ou les sous-réseaux dédiés pour les services tels qu’Azure NetApp Files.
Routage réseau vers les systèmes SAP et les applications connectées.
Utilisation d'un point de terminaison privé ou public pour Azure Files.

Pour plus d'informations sur la configuration requise et sur l'utilisation d'un partage NFS ou SMB dans un scénario de haute disponibilité, consultez Haute disponibilité.

Remarque

Si vous utilisez Azure Files pour vos partages réseau, nous vous recommandons d’utiliser un point de terminaison privé. En cas de défaillance zonale peu probable, votre client NFS redirige automatiquement vers une zone saine. Vous n'êtes pas obligé de remonter les partages NFS ou SMB sur vos VM.

Sécurité pour votre paysage SAP

Pour protéger votre charge de travail SAP sur Azure, vous devez planifier plusieurs aspects de la sécurité :

Segmentation du réseau et sécurité de chaque sous-réseau et interface réseau.
Chiffrement sur chaque couche dans le paysage SAP.
Solution d’identité pour les services d’authentification unique et d’accès administratif et d’utilisateur final.
Surveillance des menaces et des opérations.

Les rubriques de ce chapitre ne sont pas une liste exhaustive de tous les services, options et alternatives disponibles. Il répertorie plusieurs bonnes pratiques qui doivent être prises en compte pour tous les déploiements SAP dans Azure. Il existe d’autres aspects à couvrir en fonction des exigences de votre entreprise ou de votre charge de travail. Pour plus d’informations sur la conception de la sécurité, consultez les ressources suivantes pour obtenir des conseils généraux sur Azure :

Sécuriser des réseaux virtuels à l’aide de groupes de sécurité

La planification de votre paysage SAP dans Azure doit inclure un certain degré de segmentation du réseau, avec des réseaux virtuels et des sous-réseaux dédiés uniquement aux charges de travail SAP. Les meilleures pratiques pour la définition de sous-réseau sont décrites dans Mise en réseau et dans d’autres guides d’architecture Azure. Nous vous recommandons d'utiliser des NSG avec des ASG au sein des NSG pour permettre la connectivité entrante et sortante. Lorsque vous concevez des ASG, chaque NIC d'une machine virtuelle peut être associée à plusieurs ASG, ce qui vous permet de créer différents groupes. Par exemple, créez un ASG pour les VMs DBMS, qui contient tous les serveurs de base de données de votre paysage. Créez un autre ASG pour toutes les machines virtuelles (application et DBMS) d'un seul SAP SID. De cette façon, vous pouvez définir une règle NSG pour l’ASG global de la base de données et une autre règle plus spécifique uniquement pour l’ASG spécifique au SID.

Les NSG ne limitent pas les performances avec les règles que vous définissez pour le NSG. Pour surveiller le flux de trafic, vous pouvez éventuellement activer journalisation de flux NSG avec les journaux évalués par une gestion des événements d’information (SIEM) ou un système de détection d’intrusion (IDS) de votre choix pour surveiller et agir sur l’activité réseau suspecte.

Conseil

Activez les groupes de sécurité réseau uniquement au niveau du sous-réseau. Bien que les NSG puissent être activés à la fois au niveau du sous-réseau et au niveau de NIC, l'activation sur les deux constitue très souvent un obstacle dans les situations de dépannage lors de l'analyse des restrictions de trafic réseau. Utilisez les NSG au niveau de NIC uniquement dans des situations exceptionnelles et lorsque cela est nécessaire.

Points de terminaison privés pour les services

De nombreux services PaaS Azure sont accessibles par défaut via un point de terminaison public. Bien que le point de terminaison de communication se trouve sur le réseau principal Azure, le point de terminaison est exposé à l’Internet public. points de terminaison privés sont une interface réseau à l’intérieur de votre propre réseau virtuel privé. Grâce à Azure Private Link, le point de terminaison privé projette le service dans votre réseau virtuel. Les services PaaS sélectionnés sont ensuite accessibles en privé via l’adresse IP à l’intérieur de votre réseau. En fonction de la configuration, le service peut potentiellement être défini pour communiquer via un point de terminaison privé uniquement.

L’utilisation d’un point de terminaison privé augmente la protection contre les fuites de données et simplifie souvent l’accès à partir de réseaux locaux et appairés. Dans de nombreuses situations, le routage réseau et le processus d’ouverture des ports de pare-feu, souvent nécessaires pour les points de terminaison publics, sont simplifiés. Les ressources se trouvent déjà dans votre réseau, car elles sont accessibles par un point de terminaison privé.

Pour savoir quels services Azure offrent la possibilité d’utiliser un point de terminaison privé, consultez Services disponibles Private Link. Pour NFS ou SMB avec Azure Files, nous vous recommandons d’utiliser toujours des points de terminaison privés pour les charges de travail SAP. Pour en savoir plus sur les frais encourus lors de l'utilisation du service, consultez Tarification des points de terminaison privés. Certains services Azure peuvent éventuellement inclure le coût avec le service. Ces informations sont incluses dans les informations de tarification d’un service.

Chiffrement

En fonction des politiques de votre entreprise, un chiffrement au-delà des options par défaut dans Azure peut être requis pour vos charges de travail SAP.

Chiffrement des ressources d’infrastructure

Par défaut, les disques managés et le stockage d’objets blob dans Azure sont chiffrés avec une clé gérée par la plateforme (PMK). De plus, le chiffrement BYOK (apportez votre propre clé) pour les disques managés et le stockage Blob est pris en charge pour les charges de travail SAP dans Azure. Pour chiffrement de disque managé, vous pouvez choisir parmi différentes options, en fonction des exigences de sécurité de votre entreprise. Les options de chiffrement Azure sont les suivantes :

Chiffrement côté stockage (SSE) PMK (SSE-PMK)
Clé gérée par le client SSE (SSE-CMK)
Double chiffrement des données au repos
Chiffrement basé sur l’hôte

Pour plus d’informations, notamment une description d’Azure Disk Encryption, consultez une comparaison des options de chiffrement Azure.

Remarque

Actuellement, n’utilisez pas le chiffrement basé sur l’hôte sur une machine virtuelle qui se trouve dans la famille de machines virtuelles de la série M lors de l’exécution avec Linux en raison d’une limitation potentielle des performances. L’utilisation du chiffrement SSE-CMK pour les disques managés n’est pas affectée par cette limitation.

Pour les déploiements SAP sur les systèmes Linux, n’utilisez pas Azure Disk Encryption. Azure Disk Encryption implique le chiffrement exécuté dans les VMs SAP à l’aide des clés CMK d’Azure Key Vault. Pour Linux, Azure Disk Encryption ne prend pas en charge les images du système d'exploitation utilisées pour les charges de travail SAP. Azure Disk Encryption peut être utilisé sur les systèmes Windows avec des charges de travail SAP, mais ne combinez pas Azure Disk Encryption avec le chiffrement natif de base de données. Nous vous recommandons d’utiliser le chiffrement natif de base de données au lieu d’Azure Disk Encryption. Pour plus d'informations, consultez la section suivante.

Semblable au chiffrement de disque managé, le chiffrement Azure Files au repos (SMB et NFS) est disponible avec des PMK ou des CMK.

Pour les partages réseau SMB, examinez attentivement Azure Files et les dépendances du système d’exploitation avec les versions SMB, car la configuration affecte la prise en charge du chiffrement en transit.

Important

L’importance d’un plan prudent pour stocker et protéger les clés de chiffrement si vous utilisez le chiffrement géré par le client ne peut pas être surévalué. Sans clés de chiffrement, les ressources chiffrées telles que les disques sont inaccessibles et peuvent entraîner une perte de données. Envisagez soigneusement de protéger les clés et d’accéder aux clés aux seuls utilisateurs ou services privilégiés.

Chiffrement pour les composants SAP

Le chiffrement au niveau SAP peut être séparé en deux couches :

Cryptage du DBMS
Chiffrement du transport

Pour le chiffrement DBMS, chaque base de données prise en charge pour un déploiement SAP NetWeaver ou SAP S/4HANA prend en charge le chiffrement natif. Le chiffrement transparent de base de données est entièrement indépendant de tout chiffrement d’infrastructure en place dans Azure. Vous pouvez utiliser simultanément SSE et le chiffrement de base de données. Lorsque vous utilisez le chiffrement, l’emplacement, le stockage et la conservation sécurisée des clés de chiffrement sont extrêmement importants. Toute perte de clés de chiffrement entraîne une perte de données, car vous ne pourrez pas démarrer ou récupérer votre base de données.

Certaines bases de données peuvent ne pas avoir de méthode de chiffrement de base de données ou ne pas nécessiter un paramètre dédié à activer. Pour d'autres bases de données, les sauvegardes du DBMS peuvent être chiffrées implicitement lorsque le chiffrement de la base de données est activé. Consultez la documentation SAP suivante pour savoir comment activer et utiliser le chiffrement transparent de base de données :

Chiffrement des données et des volumes de journaux SAP HANA
SQL Server : note SAP 1380493
Oracle : Note SAP 974876
IBM Db2 : Note SAP 1555903
SAP ASE : note SAP 1972360

Contactez SAP ou votre fournisseur de DBMS pour obtenir de l'aide sur la manière d'activer, d'utiliser ou de dépanner le chiffrement logiciel.

Important

Il ne peut pas être trop important d’avoir un plan prudent pour stocker et protéger vos clés de chiffrement. Sans clés de chiffrement, la base de données ou le logiciel SAP peut être inaccessible et vous risquez de perdre des données. Réfléchissez soigneusement à la façon de protéger les clés. Autorisez l’accès aux clés uniquement par les utilisateurs ou services privilégiés.

Le chiffrement du transport ou des communications peut être appliqué aux connexions SQL Server entre les moteurs SAP et le SGBD. De même, vous pouvez chiffrer les connexions depuis la couche de présentation SAP (connexion réseau sécurisée SAPGui ou SNC) ou une connexion HTTPS vers un frontal Web. Consultez la documentation du fournisseur d’applications pour activer et gérer le chiffrement en transit.

Surveillance des menaces et alertes

Pour déployer et utiliser des solutions de surveillance et d’alerte des menaces, commencez par utiliser l’architecture de votre organisation. Les services Azure fournissent une protection contre les menaces et une vue de sécurité que vous pouvez incorporer dans votre plan de déploiement SAP global. Microsoft Defender pour Cloud répond aux exigences de protection contre les menaces. Microsoft Defender pour le cloud fait généralement partie d’un modèle de gouvernance global pour l’ensemble d’un déploiement Azure, et pas seulement pour les composants SAP.

Pour plus d’informations sur la gestion des événements d’information de sécurité (SIEM) et les solutions de réponse automatisée de l’orchestration de sécurité (SOAR), consultez solutions Microsoft Sentinel pour l’intégration SAP.

Logiciel de sécurité dans les VMs SAP

La note SAP 2808515 pour Linux et la note SAP 106267 pour Windows décrivent les exigences et les meilleures pratiques lorsque vous utilisez des antivirus ou des logiciels de sécurité sur des serveurs SAP. Nous vous suggestions de suivre les recommandations SAP lorsque vous déployez des composants SAP dans Azure.

Haute disponibilité

La haute disponibilité SAP dans Azure comprend deux composants :

Haute disponibilité de l’infrastructure Azure : Haute disponibilité des services de calcul (VM), de réseau et de stockage Azure, et comment ils peuvent augmenter la disponibilité des applications SAP.
Haute disponibilité de l'application SAP : comment la combiner avec la haute disponibilité de l'infrastructure Azure en utilisant la guérison des services. Exemple qui utilise la haute disponibilité dans les composants logiciels SAP :
- Instance SAP (A)SCS et SAP ERS
- Serveur de base de données

Pour plus d’informations sur la haute disponibilité pour SAP dans Azure, consultez les articles suivants :

Pacemaker sur Linux et le clustering de basculement Windows Server sont les seuls frameworks de haute disponibilité pour les charges de travail SAP qui sont directement prises en charge par Microsoft sur Azure. Toute autre infrastructure de haute disponibilité n’est pas prise en charge par Microsoft et nécessite la conception, les détails de l’implémentation et la prise en charge des opérations du fournisseur. Pour plus d’informations, consultez scénarios pris en charge pour SAP dans Azure.

Récupération d’urgence

Souvent, les applications SAP font partie des processus les plus critiques pour l’entreprise. En fonction de leur importance et du temps nécessaire pour être à nouveau opérationnel après une interruption imprévue, les scénarios de continuité d’activité et de reprise d’activité (BCDR) doivent être soigneusement planifiés.

Pour savoir comment répondre à cette exigence, consultez Présentation de la reprise après sinistre et directives d'infrastructure pour la charge de travail SAP.

Sauvegarde

Dans le cadre de votre stratégie BCDR, la sauvegarde de votre charge de travail SAP doit faire partie intégrante de tout déploiement planifié. La solution de sauvegarde doit couvrir toutes les couches d'une pile de solutions SAP : VM, système d'exploitation, couche d'application SAP, couche DBMS et toute solution de stockage partagé. La sauvegarde des services Azure utilisés par votre charge de travail SAP et d'autres ressources cruciales telles que le chiffrement et les clés d'accès doivent également faire partie de votre conception de sauvegarde et de BCDR.

Sauvegarde Azure offre des solutions PaaS pour la sauvegarde :

Configuration des machines virtuelles, système d’exploitation et couche Application SAP (redimensionnement des données sur des disques managés) via Sauvegarde Azure pour machine virtuelle. Consultez la matrice de support pour vérifier que votre architecture peut utiliser cette solution.
Sauvegarde des données et des journaux des bases de données SQL Server et SAP HANA. Il inclut la prise en charge des technologies de réplication de base de données, telles que la réplication du système HANA ou SQL Always On, et la prise en charge inter-régions pour les régions jumelées.
Sauvegarde du partage de fichiers via Azure Files. Vérifiez la prise en charge de NFS ou SMB et d'autres détails de configuration.

Sinon, si vous déployez Azure NetApp Files, options de sauvegarde sont disponibles au niveau du volume, y compris SAP HANA et Oracle DBMS intégration à une sauvegarde planifiée.

Les solutions Azure Backup offrent une option de suppression logicielle pour empêcher toute suppression malveillante ou accidentelle et pour éviter la perte de données. La suppression réversible est également disponible pour les partages de fichiers que vous déployez à l’aide d’Azure Files.

Des options de sauvegarde sont disponibles pour une solution que vous créez et gérez vous-même, ou si vous utilisez un logiciel tiers. Une option consiste à utiliser les services avec Azure Storage, notamment en utilisant un stockage immuable pour les données blob. Cette option autogérée serait actuellement requise comme option de sauvegarde de DBMS pour certaines bases de données comme SAP ASE ou IBM Db2.

Utilisez les recommandations des bonnes pratiques Azure pour vous protéger et valider contre les attaques de ransomware.

Conseil

Assurez-vous que votre stratégie de sauvegarde inclut la protection de l’automatisation du déploiement, des clés de chiffrement pour les ressources Azure et le chiffrement transparent de la base de données si elle est utilisée.

Sauvegarde interrégion

Pour toute exigence de sauvegarde inter-régions, déterminez l’objectif de temps de récupération (RTO) et l’objectif de point de récupération (RPO) proposés par la solution et s’il correspond à votre conception et besoins BCDR.

Migration SAP vers Azure

Il n'est pas possible de décrire toutes les approches et options de migration pour la grande variété de produits SAP, de dépendances de versions et de technologies natives de système d'exploitation et de DBMS disponibles. L’équipe de projet pour votre organisation et les représentants de votre fournisseur de services doivent prendre en compte plusieurs techniques pour une migration SAP fluide vers Azure.

Tester les performances pendant la migration. Une partie importante de la planification de la migration SAP est le test de performances techniques. L’équipe de migration doit autoriser suffisamment de temps et de disponibilité pour que le personnel clé exécute les applications et les tests techniques du système SAP migré, y compris les interfaces connectées et les applications. Pour une migration SAP réussie, il est essentiel de comparer le temps d'exécution avant et après la migration ainsi que la précision des processus métier clés dans un environnement de test. Utilisez les informations pour optimiser les processus avant de migrer l’environnement de production.
Utiliser les services Azure pour la migration SAP. Certaines charges de travail basées sur des machines virtuelles sont migrées sans modification vers Azure à l’aide de services tels que Azure Migrate ou Azure Site Recovery, ou un outil tiers. Vérifiez avec diligence que la version du système d’exploitation et la charge de travail SAP qu’elle exécute sont prises en charge par le service.

Souvent, toute charge de travail de base de données n’est intentionnellement pas prise en charge, car un service ne peut pas garantir la cohérence de la base de données. Si le type de DBMS est pris en charge par le service de migration, le taux de modification ou de désabonnement de la base de données est souvent trop élevé. Les systèmes SAP les plus occupés ne répondent pas au taux de modification autorisé par les outils de migration. Les problèmes peuvent ne pas être vus ou découverts tant que la migration de production n’est pas possible. Dans de nombreuses situations, certains services Azure ne conviennent pas à la migration de systèmes SAP. Azure Site Recovery et Azure Migrate n’ont pas de validation pour une migration SAP à grande échelle. Une méthodologie de migration SAP éprouvée consiste à s'appuyer sur des outils de réplication de DBMS ou de migration SAP.

Un déploiement dans Azure au lieu d’une migration de machine virtuelle de base est préférable et plus facile à accomplir qu’une migration locale. Les cadres de déploiement automatisés tels que Azure Center pour les solutions SAP et le cadre d'automatisation du déploiement Azure permettent une exécution rapide des tâches automatisées. Pour migrer votre paysage SAP vers une nouvelle infrastructure déployée à l'aide de technologies de réplication natives de DBMS telles que la réplication du système HANA, la sauvegarde et la restauration de SGBD ou les outils de migration SAP, vous utilisez des connaissances techniques établies de votre système SAP.
Mise à l’échelle des infrastructures. Pendant une migration SAP, une capacité d’infrastructure plus importante peut vous aider à déployer plus rapidement. L'équipe du projet devrait envisager d'augmenter la taille de la VM pour fournir plus de CPU et de mémoire. L’équipe devrait également envisager d’augmenter le stockage agrégé des VMs et le débit du réseau. De même, au niveau de la VM, envisagez des éléments de stockage tels que des disques individuels pour augmenter le débit avec des niveaux de performances et de rafale à la demande pour Premium SSD v1. Augmentez les valeurs d'IOPS et de débit si vous utilisez Premium SSD v2 au-dessus des valeurs configurées. Agrandissez les partages de fichiers NFS et SMB pour augmenter les limites de performances. Gardez à l’esprit que la taille des disques de gestion Azure ne peut pas être réduite, et que la réduction de la taille, des niveaux de performances et des KPI de débit peut entraîner différents temps de refroidissement.
Optimisez le réseau et la copie des données. La migration d’un système SAP vers Azure implique toujours le déplacement d’une grande quantité de données. Les données peuvent être des sauvegardes de base de données et de fichiers ou une réplication, un transfert de données d’application à application ou une exportation de migration SAP. Selon le processus de migration que vous utilisez, vous devez choisir le chemin d’accès réseau approprié pour déplacer les données. Pour de nombreuses opérations de déplacement de données, l’utilisation d’Internet au lieu d’un réseau privé est le chemin le plus rapide pour copier des données en toute sécurité dans le stockage Azure.

L'utilisation d'ExpressRoute ou d'un VPN peut entraîner des goulots d'étranglement :
- Les données de migration utilisent trop de bande passante et interfèrent avec l’accès utilisateur aux charges de travail qui s’exécutent dans Azure.
- Les goulots d’étranglement réseau locaux, comme un pare-feu ou une limitation de débit, sont souvent détectés uniquement pendant la migration.
Quelle que soit la connexion réseau utilisée, les performances réseau à flux unique pour un déplacement de données sont souvent faibles. Pour augmenter la vitesse de transfert de données sur plusieurs flux TCP, utilisez des outils qui peuvent prendre en charge plusieurs flux. Appliquez des techniques d’optimisation décrites dans la documentation SAP et dans de nombreux billets de blog sur cette rubrique.

Conseil

Au cours de la phase de planification, il est important de prendre en compte tous les réseaux de migration dédiés que vous utiliserez pour les transferts de données volumineux vers Azure. Par exemple, les sauvegardes ou la réplication de base de données ou l’utilisation d’un point de terminaison public pour les transferts de données vers le stockage Azure. L’impact de la migration sur les chemins réseau de vos utilisateurs et applications doit être attendu et atténué. Dans le cadre de la planification de votre réseau, tenez compte de toutes les phases de la migration et du coût d’une charge de travail partiellement productive dans Azure pendant la migration.

Prise en charge et opérations pour SAP

Quelques autres domaines sont importants à prendre en compte avant et pendant le déploiement SAP dans Azure.

Extension Azure VM pour SAP

Azure Monitoring Extension, Enhanced Monitoring et Azure Extension for SAP font tous référence à une extension de machine virtuelle que vous devez déployer pour fournir des données de base sur l'infrastructure Azure à l'agent hôte SAP. Les notes SAP peuvent faire référence à l'extension sous le nom de Monitoring Extension ou Enhanced monitoring. Dans Azure, cela s'appelle Azure Extension for SAP. À des fins de support, l'extension doit être installée sur toutes les VMs Azure qui exécutent une charge de travail SAP. Pour en savoir plus, consultez Extension de machine virtuelle Azure pour SAP.

Prise en charge DE SAProuter pour SAP

L’exploitation d’un paysage SAP dans Azure nécessite une connectivité à et depuis SAP à des fins de support. En règle générale, la connectivité se présente sous la forme d’une connexion SAProuter, soit via un canal réseau de chiffrement via Internet, soit via une connexion VPN privée à SAP. Pour obtenir les meilleures pratiques et un exemple d’implémentation de SAProuter dans Azure, consultez votre scénario d’architecture dans Connexions Internet entrantes et sortantes pour SAP sur Azure.

Partage via

Planifier et mettre en œuvre un déploiement SAP sur Azure

Définitions

Ressources

Scénarios

Premières étapes pour planifier un déploiement

Planifier pour la conformité

Planifier la sécurié

Organiser les ressources Azure

Zones géographiques et régions Azure

Régions Azure appairées

Zones de disponibilité

Domaines d’erreur

Domaines de mise à jour

Groupes à haute disponibilité

Groupes de machines virtuelles identiques avec orchestration flexible

Groupes de placement de proximité

Mise en réseau Azure

Réseaux virtuels Azure

Considérations relatives au réseau virtuel

Résolution de noms et services de domaine

Affectation d’adresses IP

Adresses IP secondaires pour la virtualisation du nom d’hôte SAP

Azure Load Balancer avec des VMs exécutant SAP

Plusieurs vNIC par VM

Mise en réseau accélérée

Connectivité locale

Connectivité Internet sortante et entrante

Machines virtuelles Azure pour les charges de travail SAP

Modèles de tarification pour les VMs Azure

Système d'exploitation pour les VMs

VM de génération 1 et génération 2

Limites de performances pour les VMs Azure

Service de grandes instances HANA

Stockage pour SAP sur Azure

Disque temporaire sur les VMs

Partages réseau et volumes pour SAP

Sécurité pour votre paysage SAP

Sécuriser des réseaux virtuels à l’aide de groupes de sécurité

Points de terminaison privés pour les services

Chiffrement

Chiffrement des ressources d’infrastructure

Chiffrement pour les composants SAP

Surveillance des menaces et alertes

Logiciel de sécurité dans les VMs SAP

Haute disponibilité

Récupération d’urgence

Sauvegarde

Sauvegarde interrégion

Migration SAP vers Azure

Prise en charge et opérations pour SAP

Extension Azure VM pour SAP

Prise en charge DE SAProuter pour SAP

Étapes suivantes

Commentaires

Commentaires

Ressources supplémentaires