Retour d’expérience : SAP dans Azure

Publié le par

Je vous propose de partager mon retour d’expérience d’un projet d’implémentation (greenfield) et migration (lift & shift) de systèmes SAP dans Azure.

environnements :
greenfield : S/4HANA
lift & shift : BO/BI/HANA/SLT/FC

En plus de devoir respecter les contraintes des installations SAP à partir des notes OSS pour la configuration cible (OS/DB ; exemple S/4HANA sur SLES) il faudra respecter les spécifications de SAP dans Azure.

Par défaut, le monde du cloud est bridé pour que l’accès soit bon marché et donc on mutualise les infra, et il y a même du surbooking ! C’est donc un dé bridage dans les règles de l’art qu’il va falloir respecter pour bénéficier de performances satisfaisantes pour un système SAP. Ainsi lorsque l’on procédera à un lift & shift, le sizing en terme de SAPS ne sera pas suffisant, il faudra prendre en compte les IOPS .

Voici les premières étapes à envisager :

  • provisionning à constituer dans un fichier excel
  • Gabarit certifié à choisir

1928533 – SAP Applications on Azure: Supported Products and Azure VM types

  • Configuration de la VM Azure avec des options spécifiques
  • Configuration OS pour tirer parti des performances de la VM

Configurations du stockage des machines virtuelles SAP HANA Azure

  • 100% de disques Azure SSD Premium (autrement le SLA sera du disque le plus faible)
  • limite IOPS à identifier par environnement (par VM et disques)
  • Write Accelerator
  • Cache sur disque par usage
  • Network Accelerator
  • PPG (Proximity Placement Groups)
  • Azure availability set
  • split de disques (LVM Striping ; stripe sizes par partitions)
  • Gabarit D8s_v3 minimum en QUAL et PROD ; ne pas choisir un gabarit trop faible (ne pas regarder seulement les SAPS, mais aussi la bande passante I/O des disques)
  • SWAP sur le disque temporaire ( référence how-to )

une fois le sizing choisi, construire via Terraform dés le début de préférence pour documenter et industrialiser.

Vérifier les performances avec des stress test, ne pensez pas qu’au design

Réaliser des tests de KPI avec les outils de certifications SAP pour commencer ; puis dans la mesure du possible des tirs de performances pour vérifier que l’ensemble est homogène.

surveillance accrue des coûts

Suivi des coûts entre théorie et pratique ; le mode de facturation demande une période d’adaptation. en partie pour les facturations des réservations d’instance.

Quelques conseils :

  • le mode PAYG va revenir plus chère au delà de 12H / jour d’utilisation ; 5J / semaine ; l’arrêt de la VM ne suffit pas, il faut une action dans le portail Azure pour désallouer les ressources
  • la réservation d’instance 3 ans est à anticiper, les jetons ne sont pas affectés à une VM en particulier ; l’annulation est pénalisée de 12% jusqu’à 50K $
  • les OS SUSE pour Hana sont à réserver en plus ; avec un règlement en une fois pour 3 ans
  • plusieurs dérives ont été observées et aucune explication n’a pu être transmise à ce jour pour nos contacts chez Azure
  • la calculatrice Azure ( ici ) deviendra un raccourci dans votre navigateur : extraire les élèments que l’on recherche régulièrement et les garder dans un fichier Excel avec des formulaires (résumé des coûts par gabarits : ici )

Quelques épisodes intéressants :

  • Utilisation de la calculette Azure pour réaliser un prévisionnel
  • Changement de Gabarit Mseries 512GB > 1TB ; attention au surbooking dans le cloud
  • Le PAYG qui ne démarre pas (ex : DEV ; on image les développeurs au chômage)
  • Cluster et sizing (changement de gabarit impossible en période de crise)
  • Provisioning à communiquer et à anticiper
  • Réplication et maitrise de la bande passante des bases pour réaliser un Lift & Shift
  • Les mécanismes de réplications intégrés à la base de données seront à envisager au delà d’une certaine volumétrie pour le Lift & Shift
  • SAP HANA n’est pas compatible avec des outils de Lift & Shift ; il faudra utiliser la réplication standard du moteur DB