Conception d’applications de charge de travail SAP
Les applications SAP doivent respecter les principes de conception. Les conseils ici se concentrent sur l’optimisation des coûts et la fiabilité.
Optimisation des coûts des applications SAP
Impact : Optimisation des coûts
L’optimisation de votre application SAP peut réduire le coût total de possession sans réduire les fonctionnalités. L’objectif est de générer le retour sur investissement (ROI) maximal. Voici des façons d’optimiser une application SAP.
Identifier la responsabilité de l’application. L’optimisation d’une application SAP doit être la responsabilité de l’équipe d’application métier cliente. Le fait qu’une personne ou un groupe soit responsable des coûts vous aidera à prendre des décisions qui optimisent les coûts tout au long du cycle de vie de la charge de travail SAP.
Rationalisez et réarchitectez. Vous devez envisager de rationaliser ou de réarchitecturer l’application SAP, en particulier pendant les migrations. S4 HANA remplace souvent les anciennes applications SAP qui peuvent être ajoutées en tant que système hérité. L’évaluation DU WAF SAP peut aider à valider les efforts de réarchitecture et doit être effectuée régulièrement. Pour plus d’informations, consultez Révision d’Azure Well-Architected.
Réduisez les investissements dans les systèmes hérités. Vous devez héberger une application SAP héritée sur une architecture prise en charge minimale pour réduire les coûts. Une application héritée est plus lente et moins performante. Tous les systèmes hérités qui restent après la rationalisation et la réarchitecture doivent recevoir la dépense minimale possible et être mis hors service le cas échéant. Pour plus d’informations, consultez Azure Cost Management.
Fiabilité des applications SAP
Impact : Fiabilité
Utilisez une architecture multiniveau. La création d’une architecture multiniveau pour prendre en charge une charge de travail SAP est essentielle pour la fiabilité. Le nombre de niveaux et d’architecture varie pour chaque application SAP. Veillez à isoler les composants d’application les uns des autres et à créer une redondance pour obtenir une haute disponibilité. Le cas échéant, vous devez isoler SAP Web Dispatcher, SAP Central Services, SAP App Server, LE partage SAPMNT et la base de données. Nous avons des exemples d’architectures pour plusieurs applications SAP différentes que vous pouvez utiliser pour informer votre conception.
Pour plus d'informations, consultez les pages suivantes :
Configurez la fiabilité des services centraux SAP. Les services centraux SAP (SCS) ou ABAP SAP Central Services (ASCS) sont la base de la communication des applications SAP. Il se compose du serveur de messages et du serveur de mise en file d’attente. La couche des services centraux est souvent un point de défaillance unique et doit être configurée pour une haute disponibilité afin d’obtenir la résilience des applications SAP. Pour ajouter une redondance, créez un cluster de services centraux SAP avec une technologie de stockage partagé compatible prenant en charge le cluster. Selon le système d’exploitation et la technologie de stockage partagé disponible en disponibilité générale ou en préversion privée/publique, différentes options sont disponibles. Les zones de disponibilité offrent la possibilité de créer une architecture ASCS hautement disponible.
Pour plus d'informations, consultez les pages suivantes :
- Configurations de la charge de travail SAP avec des zones de disponibilité Azure
- Architecture de haute disponibilité pour une instance SAP ASCS/SCS sur Windows
- Architecture de haute disponibilité pour une instance SAP ASCS/SCS sur Linux