Partager via

Utilisation d’Azure Premium Files NFS et SMB pour la charge de travail SAP

  • Article

Ce document concerne les partages de fichiers Azure Premium Files utilisés pour la charge de travail SAP. Les volumes NFS et les partages de fichiers SMB sont couverts. Pour plus d’informations sur Azure NetApp Files pour les volumes SMB ou NFS, consultez les deux documents suivants :

Important

Les suggestions relatives aux configurations de stockage dans ce document doivent être utilisées comme point de départ. Lors de l’exécution de la charge de travail et de l’analyse des modèles d’utilisation du stockage, vous pouvez constater que vous n’utilisez pas la bande passante de stockage ou les IOPS fournies. Dans ce cas, vous pouvez réduire le stockage. En revanche, votre charge de travail peut nécessiter plus de débit de stockage que ce que ces configurations vous recommandent. Par conséquent, vous devrez peut-être déployer davantage de capacité pour augmenter les IOPS ou le débit. Sur la question concernant la tension entre la capacité de stockage requise, la latence de stockage nécessaire, le débit de stockage et les IOPS requis et la configuration la moins onéreuse, Azure propose suffisamment de types de stockage différents avec des fonctionnalités différentes et divers tarifs pour trouver le bon compromis pour vous et votre charge de travail SAP.

Pour les charges de travail SAP, les utilisations prises en charge des partages Azure Files sont les suivantes :

  • volume sapmnt pour un système SAP distribué
  • répertoire de transport pour le paysage SAP
  • /hana/shared pour le scale-out HANA. Passez en revue attentivement les considérations relatives au dimensionnement /hana/shared, car la taille appropriée du volume /hana/shared contribue à la stabilité du système.
  • interface de fichier entre votre paysage SAP et d’autres applications

Remarque

Aucune charge de travail SGBD SAP n’est prise en charge sur les volumes Azure Premium Files, NFS ou SMB. Pour connaître les restrictions de prise en charge des types de stockage Azure pour SAP NetWeaver/la couche applicative de S/4HANA, consultez la Note de support SAP 2015553.

Considérations importantes pour les partages Azure Files avec SAP

Lorsque vous planifiez votre déploiement avec Azure Files, tenez compte des points importants suivants. Le partage de termes de cette section s’applique à la fois au partage SMB et au volume NFS.

  • La taille de partage minimale s’élève à 100 gibioctets (Gio). Avec Azure Premium Files, vous payez pour la capacité des partages provisionnés.
  • Dimensionnez vos partages de fichiers non seulement en fonction de vos besoins en capacité mais aussi de vos besoins en termes d’IOPS et de débit. Pour plus d’informations, consultez Cibles des partages de fichiers Azure.
  • Testez la charge de travail pour valider votre dimensionnement et vérifier que vos objectifs de performances sont atteints. Pour savoir comment résoudre les problèmes de performances avec NFS sur Azure Files, consultez Résoudre les problèmes de performances de partage de fichiers Azure.
  • Déployez un partage sapmnt distinct pour chaque système SAP.
  • N’utilisez pas le partage sapmnt pour une autre activité, comme des interfaces.
  • N’utilisez pas le partage saptrans pour une autre activité, comme des interfaces.
  • Si votre système SAP a une charge importante de programmes de traitement par lots, vous risquez d’avoir des millions de journaux de travaux. Si les journaux des programmes de traitement par lots SAP sont stockés dans le système de fichiers, portez une attention particulière au dimensionnement du partage sapmnt. Réorganisez régulièrement les fichiers journaux des travaux conformément à la Note SAP 16083. À partir de SAP_BASIS 7.52, le comportement par défaut des journaux des programmes de traitement par lots doit être stocké dans la base de données. Pour plus d’informations, consultez la Note SAP 2360818 | Journal des travaux dans la base de données.
  • Évitez de regrouper les partages d’un trop grand nombre de systèmes SAP dans un seul compte de stockage. Il existe également des objectifs de performance et de scalabilité pour les comptes de stockage. Veillez à ne pas dépasser les limites du compte de stockage, également.
  • En général, ne regroupez pas les partages de plus de cinq systèmes SAP dans un seul compte de stockage. Cette règle vous permet d’éviter de dépasser les limites de comptes de stockage et de simplifier l’analyse des performances.
  • En général, évitez de mélanger des partages tels que sapmnt pour les systèmes SAP hors production et de production dans le même compte de stockage.
  • Utilisez un point de terminaison privé avec Azure Files. Dans l’éventualité peu probable d’une défaillance zonale, vos sessions NFS sont automatiquement redirigées vers une zone saine. Vous n’avez pas besoin de remonter les partages NFS sur vos machines virtuelles. L’utilisation d’une liaison privée peut entraîner des frais supplémentaires pour les données traitées, consultez les détails sur la tarification des liaisons privées.
  • Si vous déployez vos machines virtuelles sur des zones de disponibilité, utilisez un compte de stockage avec ZRS dans les régions Azure qui prennent en charge ZRS.
  • Azure Premium Files ne prend actuellement pas en charge la réplication interrégionale automatique pour les scénarios de reprise d’activité après sinistre. Consultez les instructions sur la récupération d’urgence pour les applications SAP pour connaître les options disponibles.

Portez une attention particulière à la consolidation de plusieurs activités dans un ou plusieurs partages de fichiers dans un compte de stockage. La distribution de ces partages sur des comptes de stockage distincts améliore le débit et la résilience et simplifie l’analyse des performances. Si de nombreux SID et partages SAP sont regroupés sur un seul compte de stockage Azure Files et que les performances du compte de stockage sont médiocres en raison des limites de débit, il peut devenir difficile d’identifier quel SID ou volume est à l’origine du problème.

Considérations supplémentaires relatives au NFS

  • Nous vous recommandons de déployer le système sur SLES 15 SP2 ou une version ultérieure, RHEL 8.4 ou une version ultérieure pour tirer parti des améliorations apportées au client NFS.
  • Montez les partages NFS avec les options de montage documentées, avec des informations de Résolution des problèmes de montage ou de connexion disponibles.
  • Pour les systèmes SAP J2EE, placer /usr/sap/<SID>/J<nr> sur NFS sur Azure Files n’est pas pris en charge.

Considérations supplémentaires relatives au SMB

  • SAP Software Provisioning Manager (SWPM) version 1.0 SP32, SWPM 2.0 SP09 ou version ultérieure est nécessaire pour utiliser Azure Files SMB. Le correctif SAPInst 749.0.91 ou une version ultérieure est requis. Si SWPM/SAPInst n’accepte pas plus de 13 caractères pour le serveur de partage de fichiers, la version SWPM est trop ancienne.
  • Lors de l’installation de l’instance SAP PAS, SWPM/SAPInst demande de saisir le nom d’hôte de transport. Le nom de domaine complet du compte de stockage doit être entré <storage_account>.file.core.windows.net ou avec l’adresse IP/le nom d’hôte du point de terminaison privé, le cas échéant.
  • Lorsque vous intégrez le domaine Active Directory à Azure Files SMB pour le déploiement de haute disponibilité SAP, les utilisateurs et groupes SAP doivent être ajoutés au partage « sapmnt ». Les utilisateurs SAP doivent disposer d’autorisations Storage File Data SMB Share Elevated Contributor définies dans le Portail Azure.

Étapes suivantes

Pour plus d’informations, consultez l’article suivant :