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

Article
05/30/2023

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 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 : combinaison d’une couche de système de gestion de base de données (SGBD) et d’une couche 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é localement 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 bien démarrer avec 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 SGBD SAP pour différents 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 ressources Azure, consultez les limites, quotas et contraintes d’abonnement Azure et de service.

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 offre plus de 800 types d’UC et machines virtuelles qui ont de nombreux téraoctets de mémoire.

Pour obtenir des descriptions des scénarios pris en charge et certains scénarios qui ne sont pas pris en charge, consultez SAP sur les machines virtuelles Azure prises en charge. 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 correctement 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 clouds privés traditionnels et les offres IaaS. Un hôte ou un externaliseur 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 composants Azure appropriés des machines virtuelles, du stockage et du 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.
Déterminez si les versions du système d’exploitation que vous envisagez d’utiliser sont prises en charge avec les machines virtuelles Azure que vous choisissez pour vos produits SAP.
Déterminez les versions SGBD sur des machines virtuelles spécifiques prises en charge pour vos produits SAP.
Déterminez 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 SGBD pour obtenir une configuration prise en charge.
Déterminez si vous devez passer à différents systèmes d’exploitation à 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 de système d’exploitation associées et les versions SGBD sont expliqués dans les logiciels SAP pris en charge pour les déploiements Azure. La connaissance que vous obtenez de l’évaluation de la prise en charge et des dépendances entre les versions SAP, les versions du système d’exploitation et les versions SGBD a un impact considérable sur vos efforts pour déplacer 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 n’est pas de rechercher des machines virtuelles disponibles pour exécuter des applications SAP.

Les premières étapes de planification d’un déploiement sont de travailler avec les équipes de conformité et de sécurité de votre organisation pour déterminer quelles sont les conditions de limite pour le déploiement du type de charge de travail SAP ou du processus métier dans un cloud public. Le processus peut prendre du temps, mais il est essentiel de procéder.

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 les 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 la vue d’ensemble du chiffrement Azure et la sécurité de votre paysage 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 d’affectation de noms que vous utilisez pour chaque ressource Azure, par exemple pour les machines virtuelles 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 à l’échelle de l’entreprise d’Azure Policy 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 le Framework d’adoption du cloud Azure.

Ne sous-estimez pas la phase initiale du projet dans votre planification. Uniquement lorsque vous avez des accords et des règles en place pour la conformité, la sécurité et l’organisation des ressources Azure, si vous avancez votre planification du 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 les zones géographiques Azure. Pour obtenir une carte interactive, consultez l’infrastructure mondiale Azure.

Toutes les régions Azure n’offrent pas les mêmes services. Selon le produit SAP que vous souhaitez exécuter, vos exigences de dimensionnement et le système d’exploitation et le SGBD dont vous avez besoin, il est possible qu’une région particulière ne propose pas les types de machines virtuelles requis pour votre scénario. Par exemple, si vous exécutez SAP HANA, vous avez généralement besoin de machines virtuelles des différentes familles de machines virtuelles 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 primaire et éventuellement à la 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 des 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 Stockage redondance dans une région secondaire.

Les types de stockage qui prennent en charge la réplication des données de région jumelées sont des types de stockage qui ne conviennent pas aux composants SAP et à une charge de travail SGBD. La facilité d’utilisation de la réplication de stockage Azure est limitée à Stockage Blob Azure (à des fins de sauvegarde), aux partages de fichiers et aux volumes, ainsi qu’à d’autres scénarios de stockage à latence élevée.

Lorsque vous case activée pour 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 des zones de disponibilité pour séparer physiquement des emplacements 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 machines virtuelles dans deux zones de disponibilité distinctes dans Azure. Un autre exemple consiste à implémenter une infrastructure de haute disponibilité pour votre système SGBD SAP dans une zone de disponibilité et déployer SAP (A)SCS dans une autre zone de disponibilité, afin d’obtenir le meilleur contrat SLA dans Azure.

Pour plus d’informations sur les contrats SLA de machine virtuelle dans Azure, case activée la dernière version de Machines Virtuelles sla. É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 dans les configurations de charge de travail SAP avec des zones de disponibilité Azure lorsque vous choisissez une région avec 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 machines virtuelles dans le cadre d’un système SAP, vous pouvez influencer indirectement le contrôleur de structure Azure pour déployer vos machines virtuelles sur différents domaines d’erreur, afin que vous puissiez répondre aux exigences des contrats SLA de disponibilité. Toutefois, vous n’avez pas de contrôle direct de la distribution des domaines d’erreur sur une unité d’échelle Azure (collection de centaines de nœuds de calcul ou de nœuds de stockage et de mise en réseau) ou l’affectation de machines virtuelles à un domaine d’erreur spécifique. Pour manœuvrer le contrôleur de structure Azure pour déployer un ensemble de machines virtuelles sur différents domaines d’erreur, vous devez affecter un groupe à haute disponibilité Azure aux machines virtuelles 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 façon dont une machine virtuelle dans un système SAP constitué de plusieurs machines virtuelles 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 des machines virtuelles 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 pour déployer un ensemble de machines virtuelles sur différents domaines de mise à jour, vous devez affecter 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 machines virtuelles Azure au sein d’un groupe à haute disponibilité Azure sont distribuées par le contrôleur de structure Azure sur différents domaines d’erreur. La distribution sur différents domaines d’erreur consiste à empêcher l’arrêt de toutes les machines virtuelles d’un système SAP pendant la maintenance de l’infrastructure ou si une défaillance se produit dans un domaine d’erreur. Par défaut, les machines virtuelles 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 les groupes à haute disponibilité Azure.

Important

Les zones de disponibilité et les groupes à haute disponibilité dans Azure s’excluent mutuellement. Vous pouvez déployer plusieurs machines virtuelles 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 des groupes de placement de proximité.

Lorsque vous définissez des groupes à haute disponibilité et essayez de combiner différentes machines virtuelles de différentes familles de machines virtuelles au sein d’un 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 est que les machines virtuelles familiales Edsv5 ne s’exécutent pas sur le même matériel hôte que les machines virtuelles de la famille M.

Le même problème peut se produire si vous redimensionnez des machines virtuelles. 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 redimensionnez une famille de machines virtuelles qui ne peuvent pas être hébergées sur le même matériel hôte, vous devez arrêter toutes les machines virtuelles qui se trouvent dans votre groupe à haute disponibilité et les redimensionner pour pouvoir s’exécuter sur l’autre type d’ordinateur hôte. Pour plus d’informations sur les contrats SLA des machines virtuelles déployées dans un groupe à haute disponibilité, consultez Machines Virtuelles contrats SLA.

Groupes de machines virtuelles identiques avec orchestration flexible

Les groupes de machines virtuelles identiques avec 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, le 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. En revanche, la création du groupe identique flexible entre les zones de disponibilité avec platformFaultDomainCount=1 (FD=1) distribuerait des machines virtuelles sur une zone spécifiée et le groupe identique distribuerait également des machines virtuelles entre différents domaines d’erreur au sein de la zone.

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 charges de travail SAP avec un groupe identique, consultez le guide de déploiement de mise à l’échelle des 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 les options de déploiement à haute disponibilité pour la 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 groupe identique flexible avec FD=1. Un billet de blog vous montre comment modifier un système SAP haute disponibilité ou non-HA déployé dans un groupe à haute disponibilité ou une zone de disponibilité pour un groupe identique flexible avec FD=1.

Groupes de placement de proximité

La latence réseau entre des machines virtuelles SAP individuelles peut avoir des implications significatives pour les performances. Le temps d’aller-retour réseau entre les serveurs d’applications SAP et le SGBD peut particulièrement avoir un impact significatif sur les applications métier. De façon optimale, tous les éléments de calcul exécutant vos machines virtuelles SAP se trouvent aussi étroitement que possible. Cette option n’est pas possible dans chaque combinaison, et Azure peut ne pas savoir quelles machines virtuelles 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 de parcours aller-retour réseau au sein d’un système SAP, les 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 les scénarios de groupe de placement de proximité.

Les machines virtuelles qui n’utilisent pas de groupes de placement de proximité doivent être la méthode de déploiement par défaut dans la plupart des cas 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 entre les zones de disponibilité (machines virtuelles distribuées 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 machines virtuelles que les applications utilisent.
Accès direct aux machines virtuelles via Secure Shell (SSH) ou Rdp (Windows Remote Desktop) pour la gestion et l’administration.
Communication interne et résolution de noms entre les machines virtuelles 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 plus d’informations sur la mise en réseau, consultez Azure Réseau virtuel.

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 à utiliser, ou il peut être dédié à un service ou un objectif spécifique. Certains services Azure, comme Azure Réseau virtuel 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 de réseau virtuel pour les ressources telles que l’interface réseau carte s (cartes réseau) pour les machines virtuelles après le déploiement des machines virtuelles. Apporter une modification à 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, comme S/4HANA ou SAP NetWeaver.
Les restrictions de routage réseau sont appliquées par les groupes de sécurité réseau (NSG) au niveau du sous-réseau. Grouper des adresses IP de machines virtuelles dans des groupes de sécurité d’application (ASG) gérés dans les règles de groupe de sécurité réseau et fournir des rôles, des niveaux et des regroupements SID d’autorisations.
Les machines virtuelles d’application et de base de données SAP s’exécutent dans le même réseau virtuel, au sein des mêmes sous-réseaux ou différents d’un même réseau virtuel. Utilisez différents sous-réseaux pour les machines virtuelles d’application et de base de données. Vous pouvez également utiliser des asG DBMS et d’application dédiées pour regrouper des 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 tous les carte réseau de toutes les machines virtuelles pour les charges de travail SAP, si 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 qui ont leurs propres itinéraires et règles de groupe de sécurité réseau.

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 des appliances virtuelles réseau dans le chemin de communication entre la couche 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 SGBD doit être un chemin direct. La restriction n’inclut pas les règles ASG et NSG si les règles ASG et NSG autorisent un chemin de communication direct.

Les autres scénarios dans lesquels les appliances virtuelles réseau ne sont pas prises en charge sont les suivantes :
- Chemins de communication entre des machines virtuelles Azure qui représentent des nœuds de cluster Linux Pacemaker et des appareils SBD, comme décrit dans La haute disponibilité pour SAP NetWeaver sur des machines virtuelles 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 qui est configuré comme décrit dans 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 application SAP et de la couche SGBD dans différents réseaux virtuels Azure n’est pas prise en charge. Nous vous recommandons de séparer la couche application SAP et la couche SGBD à l’aide de sous-réseaux au sein du même réseau virtuel Azure au lieu d’utiliser différents réseaux virtuels Azure.

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

Le trafic réseau entre deux réseaux virtuels Azure appairés est soumis aux coûts de transfert. Chaque jour, un grand volume de données constitué de nombreux téraoctets est échangé entre la couche application SAP et la couche SGBD. Vous pouvez entraîner des coûts substantiels si la couche Application SAP et la couche SGBD 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 La 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 machines virtuelles ou 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 machine virtuelle. La règle s’applique à la fois à l’attribution 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 d’adresses IP dynamiques est publiée si la carte réseau est supprimée, si le sous-réseau change ou si la méthode d’allocation passe à statique.

Il est possible d’affecter des adresses IP fixes aux machines virtuelles 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 affectée, soit jusqu’à ce que la machine virtuelle et sa carte réseau soit supprimée, soit tant que l’adresse IP n’est pas attribuée. Vous devez tenir compte du nombre global de machines virtuelles (en cours d’exécution et arrêtées) lorsque vous définissez la plage d’adresses IP pour le 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 l’allocation d’adresses IP statiques et dynamiques pour les machines virtuelles Azure et leurs cartes réseau. Le système d’exploitation invité de la machine virtuelle obtient l’adresse IP affectée à la carte réseau lorsque la machine virtuelle démarre. Vous ne devez pas affecter d’adresses IP statiques dans le système d’exploitation invité à une carte réseau. Certains services Azure tels que Sauvegarde Azure s’appuient 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 des machines virtuelles Azure.

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

La carte réseau de chaque machine virtuelle Azure peut lui 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 affectée à la configuration IP de la carte réseau Azure. Une adresse IP secondaire doit également être configurée dans le système d’exploitation de manière statique, car les adresses IP secondaires ne sont souvent pas affectées via DHCP. Chaque adresse IP secondaire doit provenir du même sous-réseau auquel la carte réseau est liée. Une adresse IP secondaire peut être ajoutée et supprimée d’une carte réseau Azure sans arrêter ou déallouer la machine virtuelle. Pour ajouter ou supprimer l’adresse IP principale d’une carte réseau, la machine virtuelle doit être libérée.

Remarque

Sur les configurations IP secondaires, l’adresse IP flottante de l’équilibreur de charge Azure n’est pas prise en charge. 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 machines virtuelles 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 machine virtuelle est une alternative à l’utilisation d’une adresse IP secondaire sur une carte réseau ou à l’utilisation de plusieurs cartes réseau 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 machines virtuelles qui se trouvent derrière un équilibreur de charge standard peuvent ne plus être en mesure d’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 obtenir des options de connectivité sortante, consultez la 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 pas être utilisé avec une architecture SAP dans Azure. L’équilibreur de charge de base est planifié pour être mis hors service.

Plusieurs cartes réseau virtuelles par machine virtuelle

Vous pouvez définir plusieurs carte d’interface réseau virtuel pour une machine virtuelle Azure, chaque carte réseau virtuelle affectée à n’importe quel sous-réseau du même réseau virtuel que la carte réseau virtuelle principale. Avec la possibilité d’avoir plusieurs cartes réseau réseau, vous pouvez commencer à configurer la séparation du trafic réseau, si nécessaire. Par exemple, le trafic client est routé via la carte réseau virtuelle principale et un autre trafic administrateur ou principal est acheminé via une deuxième carte réseau virtuelle. Selon le système d’exploitation et l’image que vous utilisez, les itinéraires de trafic pour les cartes réseau à l’intérieur du système d’exploitation doivent peut-être être configurés pour un routage correct.

Le type et la taille d’une machine virtuelle déterminent le nombre de cartes réseau virtuelles qu’une machine virtuelle peut avoir affecté. Pour plus d’informations sur les fonctionnalités et les restrictions, consultez Affecter plusieurs adresses IP aux machines virtuelles à l’aide du Portail Azure.

L’ajout de cartes réseau virtuelles à 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 machines virtuelles doivent accéder aux sous-réseaux privés. Nous recommandons un modèle de conception qui s’appuie sur les fonctionnalités du groupe de sécurité réseau et qui simplifie la configuration requise pour le réseau et le sous-réseau. La conception doit utiliser autant d’interfaces réseau que possible, et de manière optimale. Une exception est HANA scale-out, dans laquelle une carte réseau virtuelle secondaire est requise pour le réseau interne HANA.

Avertissement

Si vous utilisez plusieurs cartes réseau virtuelles 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 utilisateur.

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

Pour réduire davantage la latence réseau entre les machines virtuelles 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 au déploiement case activée list, 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-la lorsque vous déployez des machines virtuelles Azure pour les charges de travail SAP sur toutes les machines virtuelles prises en charge, en particulier pour la couche Application SAP et la couche SGBD SAP. 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 de mise en réseau le plus souvent est 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 via Azure ExpressRoute. Pour les charges de travail SAP plus petites, les régions distantes ou les bureaux plus petits, la connectivité VPN locale est disponible. L’utilisation d’ExpressRoute avec une connexion de site à site VPN comme 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 pour toutes les demandes entrantes.

Sécurisez votre réseau virtuel à l’aide de règles de groupe de sécurité réseau, en utilisant des balises de service réseau pour les services connus et en établissant l’adressage IP et le routage vers votre pare-feu ou toute autre appliance virtuelle 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 chemins de communication avec Internet sont le focus 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 Ce que le logiciel SAP est pris en charge pour les déploiements Azure. En outre, la note SAP 1928533 répertorie toutes les machines virtuelles Azure certifiées et leurs fonctionnalités de performances mesurées par le benchmark SAP Application Performance Standard (SAPS) et les limitations, s’ils s’appliquent. Les types de machines virtuelles certifiés pour une charge de travail SAP n’utilisent pas de surapprovisionnement pour les ressources processeur et mémoire.

Au-delà de la sélection des types de machines virtuelles pris en charge, vous devez case activée si ces types de machines virtuelles sont disponibles dans une région spécifique en fonction des 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 tarifaires pour les machines virtuelles 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 la 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 Machines Virtuelles.

La tarification du même type de machine virtuelle peut varier entre 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 les 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 façon dont Microsoft gère et met à jour l’infrastructure Azure qui héberge des machines virtuelles, consultez Maintenance des machines virtuelles dans Azure.

Système d’exploitation pour les machines virtuelles

Lorsque vous déployez de nouvelles machines virtuelles pour un paysage SAP dans Azure, soit pour installer ou migrer un système SAP, il est important de choisir le système d’opération approprié pour 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 Place de marché Azure images à 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 de machine virtuelle.

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.

Machines virtuelles de génération 1 et de 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 machines virtuelles de génération 2 dans Azure répertorie les familles de machines virtuelles Azure que vous pouvez déployer en tant que génération 2. L’article répertorie également les différences fonctionnelles entre les machines virtuelles 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 machines virtuelles 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 machines virtuelles Azure pour SAP sont compatibles avec la génération 2 ou sont limitées à la seule génération 2. Certaines familles de machines virtuelles prennent actuellement en charge uniquement les machines virtuelles 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 de disque dur virtuel de base de la machine virtuelle et n’a aucun impact sur les disques de données ou les partages NFS (Network File System) ou Server Message Block (S Mo). Les disques de données, les partages NFS ou les partages S Mo 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 machines virtuelles, comme la série Mv2, prennent uniquement en charge 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 machines virtuelles 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. 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 machine virtuelle a un quota différent sur le débit du disque et du réseau, le nombre de disques pouvant être attachés, qu’il dispose d’un stockage temporaire local qui possède ses propres limites de débit et d’E/S par seconde, 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 E/S par seconde 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 obtenue avec des valeurs d’E/S volumineuses (par exemple, 1 Mo).

Comme les machines virtuelles, 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 des machines virtuelles à utiliser dans votre déploiement SAP, tenez compte des facteurs suivants :

Commencez par les besoins en mémoire et en uc. Séparez les exigences SAP pour l’alimentation de l’UC dans la partie SGBD et les parties d’application SAP. Pour les systèmes existants, le SAPS lié au matériel que vous utilisez souvent peut être déterminé ou estimé en fonction des benchmarks d’application STANDARD SAP 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 E/S par seconde sur le serveur SGBD doivent être mesurés. Pour les nouveaux systèmes, l’exercice de dimensionnement pour le nouveau système doit également vous donner une idée générale des exigences d’E/S du côté SGBD. Si vous n’êtes pas sûr, vous devez finalement effectuer une preuve de concept.
Comparez l’exigence SAPS pour le serveur SGBD avec le 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. Le focus doit d’abord être mis sur la machine virtuelle SGBD, car la couche de base de données est la couche d’un système SAP NetWeaver qui n’effectue pas un scale-out dans la plupart des déploiements. En revanche, la couche application SAP peut être mise à l’échelle. Les guides SGBD individuels décrivent les configurations de stockage recommandées.
Résumez vos résultats pour :
- Nombre de machines virtuelles Azure que vous prévoyez d’utiliser.
- Famille de machines virtuelles individuelles et références SKU de machine virtuelle pour chaque couche SAP : SGBD, (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 pour exécuter une base de données HANA de grande taille ou une montée en puissance parallèle sur une offre dédiée appelée SAP HANA sur les grandes instances Azure. Cette offre étend les machines virtuelles 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 machines virtuelles Azure utilisent différentes options de stockage pour la persistance. En termes simples, les machines virtuelles peuvent être divisées en types de stockage persistants et temporaires ou non persistants.

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 machines virtuelles

La plupart des machines virtuelles Azure pour SAP offrent 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 machines virtuelles 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 qui ont un disque temporaire, obtenez des informations sur la taille du disque temporaire et les limites d’IOPS et de débit pour chaque série de machines virtuelles dans Tailles pour les 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 disque de système d’exploitation instantané. Conservez tous les autres disques de données et l’interface réseau. Découvrez comment redimensionner une taille de machine virtuelle qui a un disque temporaire local à une taille de machine virtuelle qui ne le fait 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 :

Répertoire de transport SAP (/usr/sap/trans ou TRANSDIR).
Volumes SAP ou volumes sapmnt partagés ou 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 qu’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 consistent à fournir des partages de fichiers NFS ou S Mo à 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 sont souvent un point de défaillance unique dans une conception (pour la haute disponibilité) ou un processus (pour l’interface de fichier), nous vous recommandons de vous appuyer sur chaque service natif Azure pour sa propre disponibilité, sla et résilience. Dans la phase de planification, il est important de prendre en compte ces facteurs :

NFS ou S Mo conception de partage, 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 public ou privé pour Azure Files.

Pour plus d’informations sur les exigences et sur l’utilisation d’un partage NFS ou S Mo 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’avez pas besoin de remonter les partages NFS ou S Mo sur vos machines virtuelles.

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 groupes de sécurité réseau avec des groupes de sécurité réseau au sein des groupes de sécurité réseau pour autoriser la connectivité entrante et sortante. Lorsque vous concevez des ASG, chaque carte réseau sur 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 machines virtuelles SGBD, qui contient tous les serveurs de base de données dans votre paysage. Créez un autre ASG pour toutes les machines virtuelles (application et SGBD) d’un seul SID SAP. De cette façon, vous pouvez définir une règle de groupe de sécurité réseau pour l’ASG de base de données globale et une autre règle plus spécifique uniquement pour l’ASG spécifique au SID.

Les groupes de sécurité réseau ne limitent pas les performances avec les règles que vous définissez pour le groupe de sécurité réseau. Pour surveiller le flux de trafic, vous pouvez éventuellement activer la journalisation des 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 groupes de sécurité réseau puissent être activés au niveau du sous-réseau et de la carte réseau, l’activation sur les deux est très souvent un obstacle dans la résolution des problèmes lors de l’analyse des restrictions de trafic réseau. Utilisez des groupes de sécurité réseau au niveau de la carte réseau uniquement dans des situations exceptionnelles et quand 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. Les points de terminaison privés sont une interface réseau à l’intérieur de votre propre réseau virtuel privé. Via 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 les services Private Link disponibles. Pour NFS ou S Mo 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 engagés à l’aide du service, consultez la tarification du point de terminaison privé. 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

Selon vos stratégies d’entreprise, le chiffrement au-delà des options par défaut dans Azure peut être nécessaire 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). En outre, apportez votre propre chiffrement byOK (ByOK) pour les disques managés et le stockage d’objets blob est pris en charge pour les charges de travail SAP dans Azure. Pour le 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 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 s’exécutant à l’intérieur des machines virtuelles SAP à l’aide de clés CMK à partir 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.

Comme pour le chiffrement de disque managé, le chiffrement Azure Files au repos (S Mo et NFS) est disponible avec des clés PMK ou des clés CMK.

Pour les partages réseau S Mo, examinez attentivement les dépendances du système d’exploitation et azure Files avec les versions de S Mo, 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 :

Chiffrement SGBD
Chiffrement du transport

Pour le chiffrement SGBD, 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 le chiffrement SSE et la base de données en même temps. 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 les autres bases de données, les sauvegardes SGBD peuvent être chiffrées implicitement lorsque le chiffrement de 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 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 SGBD pour obtenir du support sur la façon d’activer, d’utiliser ou de résoudre les problèmes de 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 de transport ou de communication peut être appliqué aux connexions SQL Server entre les moteurs SAP et le SGBD. De même, vous pouvez chiffrer les connexions à partir de la couche de présentation SAP (connexion réseau sécurisée SAPGui ou SNC) ou d’une connexion HTTPS à un serveur 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 le cloud répond aux exigences de protection contre les menaces. Defender pour le cloud fait généralement partie d’un modèle de gouvernance global pour un déploiement Azure entier, 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 la sécurité (SOAR), consultez les solutions Microsoft Sentinel pour l’intégration de SAP.

Logiciel de sécurité à l’intérieur de machines virtuelles SAP

La note SAP 2808515 pour Linux et sap Note 106267 pour Windows décrivent les exigences et les meilleures pratiques lorsque vous utilisez des scanneurs antivirus ou des logiciels de sécurité sur des serveurs SAP. Nous vous recommandons 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 machines virtuelles, des services de réseau et de stockage Azure, ainsi que la façon dont ils peuvent augmenter la disponibilité des applications SAP.
Haute disponibilité de l’application SAP : comment elle peut être combinée avec la haute disponibilité de l’infrastructure Azure à l’aide de la réparation du service. 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 Les 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 la vue d’ensemble de la récupération d’urgence et les instructions 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 : machine virtuelle, système d’exploitation, couche Application SAP, couche SGBD et toute solution de stockage partagé. La sauvegarde pour les services Azure utilisés par votre charge de travail SAP et pour 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 bcDR.

Sauvegarde Azure propose 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 la machine virtuelle. Passez en revue la matrice de prise en charge pour vérifier que votre architecture peut utiliser cette solution.
Sauvegarde des données et des journaux de base 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 de partage de fichiers via Azure Files. Vérifiez la prise en charge de NFS ou S Mo et d’autres détails de configuration.

Sinon, si vous déployez Azure NetApp Files, les options de sauvegarde sont disponibles au niveau du volume, notamment l’intégration sap HANA et Oracle DBMS à une sauvegarde planifiée.

Sauvegarde Azure solutions offrent une option de suppression réversible pour empêcher la suppression malveillante ou accidentelle et pour empêcher 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.

Les options de sauvegarde sont disponibles pour une solution que vous créez et gérez vous-même, ou si vous utilisez des logiciels tiers. Une option consiste à utiliser les services avec Stockage Azure, notamment à l’aide d’un stockage immuable pour les données d’objet blob. Cette option auto-managée serait actuellement nécessaire en tant qu’option de sauvegarde SGBD pour certaines bases de données telles que SAP ASE ou IBM Db2.

Utilisez les recommandations dans les meilleures pratiques Azure pour protéger et valider contre les attaques par 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 version et de systèmes d’exploitation natifs et de technologies SGBD 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.

Testez 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 la prémigration et le runtime post-migration et 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.
Utilisez 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 comme Azure Migrate ou Azure Site Recovery, ou d’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 SGBD est pris en charge par le service de migration, le taux de modification ou d’attrition de 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 la réplication SGBD ou les outils 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 frameworks de déploiement automatisé comme Azure Center pour les solutions SAP et le framework d’automatisation du déploiement Azure permettent d’exécuter rapidement 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 SGBD telles que la réplication du système HANA, la sauvegarde et la restauration SGBD, ou les outils de migration SAP utilisent des connaissances techniques établies de votre système SAP.
Scale-up de l’infrastructure. Pendant une migration SAP, une capacité d’infrastructure plus importante peut vous aider à déployer plus rapidement. L’équipe de projet doit envisager de monter en puissance la taille de la machine virtuelle pour fournir davantage de processeur et de mémoire. L’équipe doit également envisager de mettre à l’échelle le stockage agrégé de machines virtuelles et le débit réseau. De même, au niveau de la machine virtuelle, envisagez d’utiliser des éléments de stockage tels que des disques individuels pour augmenter le débit avec des niveaux de bursting et de performances à la demande pour ssd Premium v1. Augmentez les E/S par seconde et les valeurs de débit si vous utilisez ssd Premium v2 au-dessus des valeurs configurées. Agrandissez les partages de fichiers NFS et S Mo pour augmenter les limites de performances. N’oubliez pas qu’Azure gère les disques ne peut pas être réduit en taille et que la réduction de la taille, des niveaux de performances et des indicateurs de performance clés de débit peut avoir plusieurs temps de refroidissement.
Optimisez la copie du réseau et 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

L’extension d’analyse Azure, la supervision améliorée et l’extension Azure pour 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 sur l’agent hôte SAP. Les notes SAP peuvent faire référence à l’extension en tant qu’extension de supervision ou surveillance améliorée. Dans Azure, il s’agit de l’extension Azure pour SAP. À des fins de support, l’extension doit être installée sur toutes les machines virtuelles Azure qui exécutent une charge de travail SAP. Pour en savoir plus, consultez l’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 pour obtenir un exemple d’implémentation de SAProuter dans Azure, consultez votre scénario d’architecture dans les connexions Internet entrantes et sortantes pour SAP sur Azure.

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 machines virtuelles exécutant SAP

Plusieurs cartes réseau virtuelles par machine virtuelle

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 tarifaires pour les machines virtuelles Azure

Système d’exploitation pour les machines virtuelles

Machines virtuelles de génération 1 et de génération 2

Limites de performances pour les machines virtuelles Azure

Service de grandes instances HANA

Stockage pour SAP sur Azure

Disque temporaire sur les machines virtuelles

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é à l’intérieur de machines virtuelles 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

Ressources supplémentaires