Le dimensionnement initial de HANA pour un système S/4HANA est réalisé avant que l’on sache à quoi ressemblera réellement la charge de travail. Le document de dimensionnement produit pendant un projet de migration est une estimation éclairée : volume de données du système source converti en besoins projetés pour le column store HANA, projections du nombre d’utilisateurs multipliées par des facteurs mémoire par utilisateur, estimations de charge batch basées sur les temps d’exécution des jobs ECC. La méthodologie est solide. Les données d’entrée sont incomplètes, car il est impossible de modéliser précisément le comportement de production avant que la production existe.
Certaines hypothèses de dimensionnement se révèlent prudentes et le système fonctionne avec une marge confortable. D’autres se révèlent trop optimistes et la trajectoire mémoire après la mise en production se rapproche de la limite d’allocation plus vite que prévu. Dans les deux cas, le document de dimensionnement devient obsolète dès le démarrage de la production, car le système génère désormais des données réelles qui remplacent chaque estimation du document par une mesure.
Cet article explique ce qu’il faut mesurer après la mise en production pour vérifier si le dimensionnement tient sous charge réelle, comment projeter les besoins futurs en mémoire et en stockage à partir des données post-production plutôt qu’à partir d’estimations pré-migration, quand des ajustements de dimensionnement deviennent nécessaires et comment construire une planification continue de la capacité à partir des données de monitoring produites en permanence par le système.
Pourquoi la validation du dimensionnement après mise en production est différente du dimensionnement pré-migration
Ce que le dimensionnement initial a bien anticipé, et ce qu’il ne pouvait pas savoir
Les estimations de dimensionnement HANA avant migration reposent sur trois entrées : le volume de données source ECC, la charge transactionnelle attendue et un ensemble de multiplicateurs et d’hypothèses de croissance issus de la méthodologie de dimensionnement SAP. Le volume de données source est généralement fiable. La charge transactionnelle est souvent une approximation raisonnable. Les hypothèses de croissance sont des estimations calibrées sur des moyennes sectorielles.
Ce que la méthodologie de dimensionnement ne peut pas prendre en compte, c’est le comportement spécifique des programmes ABAP personnalisés qui ne faisaient pas partie de l’analyse, le profil de consommation mémoire des vues de calcul personnalisées créées pendant le projet, la fréquence réelle des delta merges sous les volumes d’écriture de production et la consommation du row store par des tables que l’équipe projet n’avait pas identifiées comme significatives pour la mémoire. Il ne s’agit pas de négligence. Ce sont des éléments réellement impossibles à connaître avant le démarrage de la production.
Il existe aussi une catégorie de croissance mémoire post-production qui n’a rien à voir avec les hypothèses de dimensionnement : la croissance des données liée aux opérations métier. Un système S/4HANA mis en production avec 1,2 To de données migrées génère de nouvelles données à un rythme déterminé par le volume transactionnel. Après 18 mois de production, la base de données a grossi. Si ce taux de croissance a été sous-estimé dans le dimensionnement, la trajectoire mémoire dépassera les capacités prévues plus tôt que prévu.
Les 90 premiers jours : quand le vrai profil mémoire apparaît
Le comportement mémoire d’un système HANA pendant les 90 premiers jours de production n’est pas stable. Il évolue au fur et à mesure que le jeu de données de travail se charge en mémoire, que de nouvelles données s’accumulent et que les structures internes du column store s’optimisent via les cycles de delta merge.
Le premier jour après la mise en production, le système est dans un état froid. Les partitions du column store qui existent sur disque ne sont pas toutes chargées en mémoire. Lorsque les utilisateurs et les jobs batch accèdent aux données, HANA charge les partitions nécessaires. La consommation mémoire augmente donc pendant les premiers jours, à mesure que le jeu de données de travail se réchauffe. Cette hausse est attendue et n’indique pas un problème de dimensionnement. Ce qui signale un problème potentiel, c’est une consommation mémoire qui continue d’augmenter au-delà de l’état stable attendu.
L’état stable d’un système bien dimensionné correspond à une utilisation mémoire qui se stabilise entre 50 % et 70 % de la limite d’allocation sous charge quotidienne normale, avec des pics plus élevés pendant les traitements batch de clôture mensuelle. Si le système atteint 75 % dès la première semaine avant même qu’une clôture mensuelle ait eu lieu, le dimensionnement doit probablement être réévalué. S’il se stabilise à 60 % pendant le premier mois, clôture mensuelle incluse, le dimensionnement conserve une marge pour le modèle de croissance.
C’est pourquoi un monitoring post mise en production qui capture chaque jour la trajectoire mémoire pendant les 90 premiers jours est plus utile qu’un contrôle ponctuel au jour 30. La trajectoire montre si le système se stabilise ou s’il continue de croître, ce qui permet de déterminer si le dimensionnement actuel tiendra pour les 12 à 24 prochains mois ou s’il nécessite une attention plus rapide.
Validation du dimensionnement mémoire : les métriques essentielles
Pic de mémoire utilisée par rapport à la limite d’allocation
La limite d’allocation est le plafond que HANA ne dépassera pas. Elle est configurée dans le fichier global.ini via le paramètre global_allocation_limit, généralement défini à 90 % ou 95 % de la RAM physique afin de conserver une marge pour le système d’exploitation. C’est cette valeur qui détermine si votre dimensionnement est adapté.
La validation du dimensionnement après mise en production nécessite de suivre le pic de mémoire utilisée en pourcentage de la limite d’allocation, avec une granularité centrée sur les événements de charge maximale en production : pic en heures ouvrées, pic de traitement batch en clôture mensuelle et pic de clôture annuelle si applicable. Pas les moyennes quotidiennes. Les pics.
Les seuils qui permettent de qualifier le dimensionnement sont les suivants : une utilisation de pic constamment inférieure à 70 % de la limite d’allocation signifie que le système est bien dimensionné et dispose d’une marge de croissance. Une utilisation de pic atteignant régulièrement 80 % à 85 % signifie que le dimensionnement est suffisant aujourd’hui, mais que la planification de capacité doit explicitement modéliser les 12 prochains mois. Une utilisation de pic qui touche 90 % signifie qu’une revue de dimensionnement est déjà en retard. Le passage d’un pic à 85 % à un arrêt pour manque de mémoire est plus rapide que beaucoup d’équipes ne l’imaginent lorsqu’il se produit pendant un événement à forte charge comme une clôture mensuelle.
Bien lire M_MEMORY_OVERVIEW
La vue M_MEMORY_OVERVIEW dans HANA fournit une vision consolidée de la mémoire. Les champs importants pour valider le dimensionnement sont USED_PHYSICAL_MEMORY, ALLOCATED_PHYSICAL_MEMORY et FREE_PHYSICAL_MEMORY au niveau service, combinés à la limite d’allocation au niveau instance issue de M_CONFIGURATION.
La valeur la plus souvent mal interprétée est USED_PHYSICAL_MEMORY. Elle représente la consommation mémoire active au moment de la lecture. Elle n’inclut pas la mémoire allouée par HANA mais qui n’est pas activement occupée par des données à cet instant : fragmentation mémoire, buffers préalloués et espace réservé. La valeur la plus utile pour évaluer le dimensionnement est ALLOCATED_PHYSICAL_MEMORY, qui reflète la quantité de mémoire que HANA a réclamée au système d’exploitation. L’écart entre ALLOCATED et USED représente une surcharge qui ne diminue pas même lorsque des données sont déchargées.
Un système où ALLOCATED atteint 85 % de la limite d’allocation alors que USED est à 65 % peut sembler disposer d’une marge confortable si l’on regarde uniquement la mémoire utilisée. Mais la contrainte opérationnelle est ALLOCATED, pas USED. Si ALLOCATED continue d’augmenter et se rapproche de la limite, HANA déclenchera des déchargements agressifs du column store pour libérer de l’espace, ce qui dégradera les performances. Il faut donc surveiller ALLOCATED, pas seulement USED.
Données chargées dans le column store : ce qui consomme réellement la mémoire
Dans un environnement S/4HANA, le principal contributeur à la consommation mémoire HANA est constitué par les données de tables du column store. La vue M_CS_TABLES montre la consommation mémoire par table column store, avec la répartition entre main store, compressé et optimisé pour la lecture, et delta store, optimisé pour l’écriture et non compressé.
La validation du dimensionnement après mise en production doit inclure une analyse des 20 premières tables par consommation mémoire au jour 30 et au jour 90. Deux éléments doivent être observés. Premièrement, les tables qui ont fortement augmenté entre le jour 30 et le jour 90, car elles identifient les zones de données à plus forte croissance et permettent une projection plus fiable. Deuxièmement, les tables dont le delta store est important par rapport au main store, ce qui indique que les delta merges ne suivent pas le volume d’écriture sur ces tables et que la consommation mémoire effective est plus élevée que nécessaire.
Un delta store qui représente plus de 20 % de la consommation mémoire totale d’une table mérite une investigation. Ajuster le seuil de merge ou déclencher un merge manuel pour les plus grandes tables peut réduire la consommation mémoire sans changer l’infrastructure. Ce type d’optimisation interne au système est souvent disponible avant qu’une décision de redimensionnement ne soit nécessaire. Il n’est visible que lorsque la mémoire du column store est surveillée au niveau table, et pas seulement au niveau agrégé.
Note : M_CS_TABLES peut retourner des milliers de lignes dans un grand système S/4HANA. Interrogez-la avec un filtre sur MEMORY_SIZE_IN_TOTAL > 1000000000, soit 1 Go, afin de vous concentrer sur les tables qui influencent réellement la situation mémoire. Les 50 premières tables par taille mémoire représentent généralement 60 % à 70 % de la consommation mémoire totale du column store.
Projeter les besoins mémoire futurs à partir des données post mise en production
Le calcul du taux de croissance et pourquoi il exige plus de 30 jours de données
Un taux de croissance mémoire calculé à partir de 30 jours de données post-production n’est pas fiable comme base de planification. Les 30 premiers jours incluent la phase de chargement à froid, qui gonfle le taux de croissance par rapport à l’état stable. Ils peuvent inclure ou non une clôture mensuelle, qui est l’événement le plus chargé et celui qui influence le plus la consommation mémoire de pic. Et 30 jours ne suffisent pas pour distinguer une tendance linéaire d’une tendance logarithmique, dont les implications sont très différentes pour déterminer quand le système devra être redimensionné.
Quatre-vingt-dix jours donnent un taux de croissance utilisable pour une projection linéaire. Six mois donnent un taux de croissance permettant de distinguer une tendance linéaire d’une tendance accélérée. L’approche pratique consiste à commencer des projections prudentes à partir des données des 90 jours, puis à les affiner au fur et à mesure que davantage de données sont collectées.
Le calcul est simple : prenez la consommation mémoire au jour 90 moins la consommation mémoire au jour 30, en excluant la phase de démarrage à froid, puis divisez par 60 jours pour obtenir un taux de croissance quotidien. Projetez ensuite ce taux vers l’avant. Appliquez-le à la marge actuelle entre la mémoire ALLOCATED de pic et la limite d’allocation. Le résultat indique le nombre de jours restants, au taux de croissance actuel, avant que le pic atteigne le seuil d’alerte de 85 %.
Si ce nombre est inférieur à 6 mois, une revue de dimensionnement doit être lancée immédiatement. S’il est de 12 à 18 mois, une revue de dimensionnement lors du prochain cycle de planification trimestriel est appropriée. S’il est de 24 mois ou plus, le dimensionnement actuel est confortable et un suivi mensuel de la croissance suffit.
Quand redimensionner : les critères de décision à définir à l’avance
Redimensionner un système HANA, que ce soit on-premise ou dans un environnement cloud, demande un délai de préparation. Chez un hyperscaler, changer le type d’instance pour un système HANA de production nécessite une fenêtre de maintenance planifiée et implique généralement un bref redémarrage. Le processus est plus rapide qu’une mise à niveau matérielle on-premise, mais il n’est pas immédiat. La décision doit être prise 4 à 6 semaines avant que la contrainte ne devienne critique, pas lorsque le système est déjà à 88 % d’utilisation mémoire sous charge de production.
Définir des critères de décision à l’avance plutôt que réagir à la pression mémoire sert deux objectifs. Cela retire l’urgence de la décision, ce qui améliore la qualité de l’analyse. Et cela crée un déclencheur clair que le monitoring opérationnel peut faire remonter : lorsque les données de monitoring montrent que l’utilisation mémoire de pic a atteint X % pendant trois cycles consécutifs de clôture mensuelle, lancer le processus de revue de dimensionnement.
Un ensemble de critères pragmatique : lancer une revue de dimensionnement lorsque l’utilisation de pic pendant un cycle de clôture mensuelle dépasse 82 % de la limite d’allocation. Démarrer le processus de redimensionnement lorsque la projection de croissance à 6 mois indique que le système atteindra 85 % de pic au cours du prochain trimestre. Ce sont des indicateurs avancés dans leur usage opérationnel, pas seulement des constats après coup, ce qui laisse du temps pour agir avant que la contrainte ne devienne un problème de production.
En pratique : dans les environnements RISE with SAP, les demandes de redimensionnement mémoire passent par SAP plutôt que directement par l’hyperscaler. Le processus implique une revue formelle de dimensionnement avec SAP et une demande de changement. Prévoyez un délai de 6 à 8 semaines plutôt que les 2 à 3 semaines typiques d’un changement direct de type d’instance chez un hyperscaler. Intégrez ce délai dans le calendrier des déclencheurs de décision.
CPU et stockage : les dimensions de dimensionnement souvent moins surveillées
Utilisation des threads CPU sous charge de pic
Le dimensionnement CPU de HANA est souvent considéré comme secondaire par rapport à la mémoire, car HANA est principalement limité par la mémoire pour la majorité des workloads. C’est globalement vrai. Le CPU devient une contrainte dans les opérations à fort parallélisme : grandes requêtes analytiques qui lancent des dizaines de threads d’exécution, opérations de delta merge exécutées en parallèle des heures ouvrées de forte activité et traitements batch de clôture annuelle qui exécutent plusieurs jobs de reporting concurrents.
Valider le dimensionnement CPU après mise en production signifie observer l’utilisation des threads CPU pendant les événements de pic, pas les moyennes quotidiennes. M_SERVICE_THREADS affiche le nombre de threads actifs et leurs états pendant une requête ou une opération batch. Un système où tous les threads CPU disponibles sont simultanément en état actif pendant la clôture mensuelle n’a aucune marge pour une charge concurrente. L’expérience utilisateur pendant cette fenêtre se dégrade, car chaque requête supplémentaire entre en concurrence avec des threads déjà totalement occupés.
Le scénario spécifique à surveiller est celui d’un système qui semble correct sur les métriques CPU quotidiennes, mais qui montre une saturation des threads CPU exactement pendant la fenêtre de 3 à 4 heures du batch de clôture mensuelle. Ce schéma n’apparaît pas dans les moyennes quotidiennes. Il n’est visible que dans les données d’utilisation de pic pendant ces événements précis. C’est pourquoi le monitoring CPU sur les pics, et pas seulement sur la moyenne quotidienne, est essentiel pour valider le dimensionnement.
Taux de croissance du volume de données et configuration du volume de logs
La croissance du volume de données après mise en production est alimentée par le rythme de création de nouvelles données : nouveaux documents comptabilisés, nouveaux mouvements enregistrés, nouveaux agrégats analytiques calculés. Le taux de croissance des 90 premiers jours constitue la meilleure base disponible pour la planification de capacité de stockage, car il reflète le volume transactionnel réel de cet environnement de production spécifique.
Calculez la croissance du volume de données en interrogeant M_DISK_USAGE chaque semaine pendant les 12 premières semaines après la mise en production et en enregistrant à chaque fois la taille du composant DATA. Le delta hebdomadaire donne le taux de croissance. Projetez-le ensuite sur 24 mois. Si le volume de données projeté au mois 24 dépasse 80 % du stockage alloué, une extension de stockage ou une stratégie de data lifecycle management doit être planifiée au cours de la première année.
Le dimensionnement du volume de logs est un problème différent. Le volume de logs ne croît pas de la même manière que le volume de données. Il accumule les redo logs jusqu’à l’exécution des sauvegardes de logs, après quoi les segments sauvegardés peuvent être réécrits. Le risque n’est pas une croissance progressive jusqu’à une limite, mais une saturation soudaine si les sauvegardes de logs cessent de fonctionner. Le contrôle post mise en production du volume de logs ne consiste donc pas à calculer un taux de croissance, mais à confirmer que l’intervalle de sauvegarde est calibré sur le débit d’écriture en production et que le volume de logs dispose d’un tampon suffisant pour absorber au moins 2 heures d’échec de fenêtre de sauvegarde sans atteindre 100 % d’utilisation.
Cycle de vie des données et effet sur la trajectoire de dimensionnement
Comment l’archivage modifie la situation mémoire
Les données du column store HANA consomment de la mémoire proportionnellement au volume de données chargé. Le moyen le plus direct de réduire la croissance de la consommation mémoire, au-delà du redimensionnement matériel, consiste à retirer de la base les données auxquelles l’entreprise n’a plus besoin d’accéder dans les opérations de production. C’est l’archivage des données, et son effet sur la mémoire est direct : les données archivées qui ne résident plus dans HANA ne consomment plus de mémoire.
La plupart des projets S/4HANA prévoient l’archivage comme une activité future. Il est rare qu’il soit mis en place pendant la première année de production. L’implication pratique pour le dimensionnement est que la trajectoire de croissance mémoire de la première année n’inclut pas l’effet compensatoire de l’archivage qui avait été supposé dans l’estimation initiale. Le dimensionnement a peut-être été calculé avec une hypothèse de cycle d’archivage sur 3 ans. Les trois premières années réelles peuvent pourtant se dérouler sans aucun archivage, ce qui rend la trajectoire de croissance plus abrupte que celle prévue dans le document de dimensionnement.
Un monitoring post-production qui suit la croissance des données par domaine fonctionnel, par exemple documents financiers, mouvements de stock, commandes d’achat, fournit le contexte métier nécessaire pour discuter de manière informée des zones de données qui croissent le plus vite et des programmes d’archivage qui auraient le plus fort impact sur le dimensionnement. Sans ces données, les décisions d’archivage sont prises selon des exigences de conformité ou des contraintes de projet, plutôt que selon leur impact mémoire.
Données froides dans HANA qui ne devraient pas y être
Après 12 à 18 mois de production, la plupart des systèmes S/4HANA contiennent un volume important de données qui étaient actives la première année, mais qui sont désormais rarement, voire jamais, consultées. Documents financiers historiques de périodes clôturées, ordres de production terminés, commandes clients expédiées deux ans auparavant. Ces données sont stockées dans le column store, occupent de la mémoire et sont chargées lors de scans de tables même lorsque la requête ne concerne que des données récentes.
La capacité native de partitionnement de tables de HANA permet de séparer les données historiques dans des partitions marquées comme déchargées, ce qui signifie qu’elles ne consomment pas de mémoire sauf lorsqu’elles sont explicitement consultées. Mettre en place un partitionnement par plage sur des champs de date pour les grandes tables transactionnelles permet de garder les données courantes au chaud en mémoire tout en laissant les données historiques sur disque jusqu’à ce qu’elles soient nécessaires.
Le signal de monitoring indiquant que des données froides consomment une quantité significative de mémoire est un ratio élevé entre la taille totale des données du column store et le volume de données réellement consulté par les requêtes de production au cours des 30 derniers jours. Si une table contient 200 Go de données et que le monitoring montre que seuls 15 Go ont été consultés au cours du dernier mois, 185 Go de son empreinte mémoire correspondent à des données froides que le partitionnement pourrait retirer du jeu de données actif en mémoire. M_CS_UNLOADS montre quelles parties de tables ont été déchargées sous pression mémoire puis rechargées ensuite, ce qui sert d’indicateur indirect pour identifier les structures de données les moins consultées.
De la validation du dimensionnement à la planification continue de capacité
La cadence mensuelle de revue de capacité
La validation du dimensionnement est un livrable projet. La planification de capacité est une discipline opérationnelle. Le passage de l’un à l’autre se fait autour du jour 90, lorsque le profil mémoire post mise en production s’est suffisamment stabilisé pour soutenir des projections fiables.
Une revue mensuelle de capacité ne nécessite ni longue réunion ni rapport complexe. Elle nécessite quatre chiffres, mis à jour chaque mois : l’utilisation mémoire de pic actuelle en pourcentage de la limite d’allocation, le taux actuel de croissance du volume de données en Go par mois, la date projetée à laquelle l’utilisation mémoire de pic atteindra 82 % selon le taux de croissance actuel, et la date projetée à laquelle le volume de données nécessitera une extension de stockage. Avec ces quatre chiffres mis à jour chaque mois, l’équipe dispose de 60 à 90 jours d’alerte en amont pour toute contrainte de capacité avant qu’elle n’affecte les opérations de production.
La revue devient déterminante lorsqu’un de ces chiffres évolue sensiblement. Un taux de croissance passé de 15 Go par mois à 35 Go par mois pendant trois mois consécutifs n’est pas du bruit. C’est le signal qu’un élément a changé dans le modèle de création de données, qu’il s’agisse de croissance métier, d’une nouvelle intégration générant plus d’enregistrements ou d’un job de housekeeping qui ne fonctionne plus. La revue mensuelle est le mécanisme qui détecte ce changement alors que la marge d’action se compte encore en mois, et non en semaines.
Que reporter, et à qui ?
L’équipe opérations a besoin des métriques brutes : tendance d’utilisation mémoire HANA, croissance du volume de données, santé des delta merges, statut du volume de logs. Ces éléments alimentent les dashboards de monitoring que l’équipe Basis peut consulter en continu.
La direction IT et les responsables métier ont besoin d’autre chose : un signal simple indiquant si le dimensionnement actuel couvre les 12 prochains mois et quel est l’horizon de planification pour la prochaine décision de dimensionnement. Pas les chiffres bruts de mémoire HANA, mais la conclusion que ces chiffres permettent de formuler. Un résumé mensuel de capacité en trois lignes, marge actuelle, date projetée du prochain point de décision et action recommandée si nécessaire, est plus utile pour un décideur qu’un graphique de lectures M_MEMORY_OVERVIEW.
Cette distinction est importante, car les décisions de dimensionnement impliquent budget, achat et délais de planification. Les personnes qui approuvent ces décisions doivent comprendre quand une décision est nécessaire, pas comment fonctionne la gestion mémoire de HANA. Traduire les données de monitoring en signaux de capacité pertinents pour l’entreprise fait partie de la planification de capacité, ce n’est pas une simple tâche de communication séparée.
Le document de dimensionnement est un point de départ, pas une destination
Tout document de dimensionnement produit pour une migration S/4HANA a une date d’expiration : il est valable jusqu’au démarrage de la production. Ensuite, la mesure réelle remplace l’estimation comme base de toute décision de capacité.
Les équipes qui réussissent le dimensionnement après mise en production sont celles qui traitent le passage de l’estimation à la mesure comme un processus volontaire. Elles commencent à surveiller la trajectoire mémoire dès le premier jour, elles établissent les métriques de référence aux jours 30 et 90, elles définissent les critères de décision pour déclencher une revue de dimensionnement et elles reportent chaque mois l’état de capacité avant que le sujet ne devienne urgent.
Les équipes qui échouent sont celles qui considèrent le document de dimensionnement comme correct jusqu’à ce que quelque chose casse. Elles découvrent que le dimensionnement était optimiste lors de la première clôture mensuelle, lorsque l’utilisation mémoire grimpe à 91 % pendant le batch de clôture, sans délai suffisant pour obtenir de la capacité supplémentaire avant la clôture suivante quatre semaines plus tard.
Le monitoring après mise en production ne change pas le matériel. Il change le temps disponible pour prendre des décisions éclairées sur le matériel. Ce temps est soit utilisé de manière proactive, soit absorbé dans une gestion de crise réactive. La différence entre les deux tient à la mesure continue.
