FR 3041788 A1 20170331 FR 1559255 A 20150930 - 1 - Procédé de contrôle de la capacité d'utilisation d'un système partitionné de traitement de données Domaine de l'invention La présente invention concerne le domaine des serveurs informatique de haute capacité de traitement et de haute disponibilité, généralement partagés entre plusieurs systèmes d'informations désignées par le terme de partitions logiques (LPAR). Ces serveurs comportent des ressources physiques telles que de la mémoire, des processeurs. Ces serveurs sont paramétrés pour optimiser le partage de ces ressources entre les différentes partitions logiques et atteindre un niveau de performance attendu pour chacune de ces partitions. L'administrateur système affecte des portions de la mémoire à chaque partition logique (LPAR). Un algorithme d'équilibrage de charge interne assure la répartition de l'affectation des processeurs aux différentes partitions logiques. Etat de la technique le plus proche On connaît dans l'état de la technique le brevet américain US7752415 décrivant un procédé et un système pour commander l'utilisation de la capacité d'un système de traitement de données partitionné logiquement, comprenant des ressources physiques qui sont partagées entre plusieurs partitions logiques, dans lequel la capacité des partitions logiques est gérée pour contrôler la consommation des ressources physiques de traitement de données. On connaît aussi le brevet US7096469 décrivant un procédé pour faire imposer des plafonnements de capacité telles que celles imposées par les accords de licence de logiciels dans un système de traitement de l'information dans lequel une machine physique est divisée en une pluralité de partitions logiques, dont chacune se voit attribuer une portion définie de 3041788 - 2 ressources du processeur par un gestionnaire de partition logique. Un gestionnaire de licence logicielle spécifie une consommation maximale autorisée des ressources du processeur 5 par un programme s'exécutant dans l'une des partitions logiques. Un gestionnaire de charge de travail s'exécutant également dans la partition mesure la consommation réelle de ressources processeur par la partition logique sur un intervalle de 10 calcul de moyenne spécifié et la compare avec la consommation maximale autorisée. Si la consommation réelle dépasse la consommation maximale autorisée, le gestionnaire de charge de travail calcule une limite supérieure (« soft capping » en anglais) et interagit 15 avec le gestionnaire de partitions logiques pour plafonner la consommation réelle des ressources du processeur par la partition en conformité avec la limite calculée. Pour fournir une flexibilité supplémentaire, les partitions se voient assigner un poids fantômes que le gestionnaire de 20 partitions logiques ajoute au poids total de la partition pour déterminer si la partition a dépassé sa part autorisée de ressources processeur dans le contexte de plafonnement des ressources. Pour les logiciels sous licence, la partition logique devient 25 ainsi un "conteneur" ayant une capacité de traitement inférieure à celle de l'ensemble de la machine. On connaît encore le brevet US8015335 décrivant un système d'ordinateur hôte partitionné logiquement comprenant processeurs hôte (CPU hôte) divisée en une pluralité de 30 processeurs hôtes (CPU d'hôtes) d'une configuration d'hôtes, un effectuer topologie fonction instruction est exécuté par un 3041788 - 3 processeur d'hôtes spécifiant un changement de topologie de la configuration d'invité. Le changement de topologie change préférence la polarisation de processeurs d'hôtes, la polarisation liée à la quantité 5 d'une ressource CPU hôte est fournie à un processeur hôte. On connaît enfin le brevet US8904405 concernant un serveur dont le système de traitement de données partitionné est divisé en plusieurs partitions logiques. Dans un système et un procédé comme la gestion d'un système 10 informatique, chaque tâche en cours d'exécution de charge de travail qui peuvent être classés sur la base de la criticité du temps, et les groupes de partitions logiques peuvent être définis librement. Les limites de capacité de traitement pour les partitions 15 logiques dans un groupe de partitions logiques basées sur des seuils de capacité de traitement définis et sur une détermination itérative de la capacité nécessaire pour les tâches de la charge de travail à durée critique. La charge de travail peut être équilibrée entre les partitions 20 logiques au sein d'un groupe, pour empêcher la capacité de traitement de surplus étant utilisée pour exécuter la charge de travail critique pas le temps sur une partition logique quand une autre partition logique uniquement les tâches de la charge de travail à durée critique face à un déficit de 25 traitement. Inconvénients de l'art antérieur Dans les solutions de l'art antérieur, le partage des ressources de entre chacune des partitions ne permet pas d'assurer des performances satisfaisantes dans toutes les 30 conditions d'utilisation. Par exemple pour satisfaire un 3041788 - 4 - besoin exceptionnel très important et transitoire de ressources, le serveur doit être paramétré en fonction du pic de consommation induit, ce qui conduit à sur dimensionner le serveur et donc à augmenter la complexité des moyens 5 matériels, la consommation et l'échauffement produit par le serveur, jusqu'à dégrader gravement le fonctionnement du serveur. La solution proposée par le brevet US8904405 met en oeuvre un procédé de limitation des ressources à l'intérieur de chacune 10 des partitions, fonction de paramètres prenant en compte la priorisation et la classification des charges de travail qui sont déterminées par des traitements automatiques exécutés par le programme de gestion des tâches de travail. Ces données ainsi calculées ne sont pas totalement pertinentes pour 15 assurer une optimisation de la consommation des ressources. Par exemple, si la partition est limitée à une capacité déterminée en fonction d'informations collectées auprès du gestionnaire de tâches, dans une situation où beaucoup de tâches sont classées comme « non prioritaires », l'affectation 20 des ressources sera faussée. En effet, le gestionnaire de tâches se base sur les ressources disponibles et sur l'ensemble des tâches dont il doit assurer l'exécution (quel que soit leur priorité) pour assurer la bonne exécution et la priorisation de ces tâches. Dans les solutions de l'état de la 25 technique, la politique de gestion des ressources est déterminée automatiquement par le seul gestionnaire de tâches (WLM) qui commande l'exécution de tâches non prioritaires en fonction des ressources disponibles, compte tenu du plafonnement global de la consommation des ressources 30 déterminé pour la totalité des tâches de travail de la partition. 3041788 - 5 - Solution apportée par l'invention Afin de répondre à ces inconvénients, l'invention concerne selon son acception la plus générale un procédé de contrôle de la capacité d'utilisation d'un système partitionné de 5 traitement de données, ledit système étant configuré pour présenter une pluralité de partitions logiques partageant des ressources physiques communes, le procédé consistant à limiter l'accès aux ressources processeurs desdites partitions Pi en fonction de la valeur de paramètres DC_Pi(t) de plafonnement de 10 la capacité de chacune des partitions Pi variables dans le temps, caractérisé en ce que lesdites valeurs DC_Pi(t) sont recalculées périodiquement en fonction: du résultat NICRP(t)de mesure du niveau instantané de consommation des ressources 15 processeur de l'ensemble des partitions Pi du résultat NICTi(t) de mesure du niveau instantané des charges de travail de chacune des partitions Pi, de l'état de plafonnement de chacune des 20 partitions Pi - d'au moins un paramètre « Kuser » déterminé par l'utilisateur. Ce nouveau mode de détermination des variables DC_Pi(t) permet de fixer un plafonnement aux partitions tout en réduisant les 25 contraintes imposées à la consommation de ressources de ces partitions. L'invention permet d'optimiser le partage des ressources informatiques dans un environnement de gros serveurs (« mainframe » en anglais). 30 Avantageusement, ledit calcul des valeurs DC_Pi(t) est en outre fonction de la valeur antérieure DC_Pi(t-n).Selon une variante, 3041788 - 6 - ledit calcul des valeurs DC_Pi(t) est en outre fonction de l'évolution de N valeurs NICRP(t). Selon une autre variante, ledit calcul des valeurs DC_Pi(t) est en outre fonction de l'évolution de P valeurs moyennes 5 antérieures de NICTi(t) calculées chacune sur une fenêtre temporelle d'une durée D prédéterminée. Selon une autre variante, ledit calcul des valeurs DC_Pi(t) est en outre fonction de l'évolution de M valeurs antérieures du résultat NICRP(t). 10 Selon une autre variante, ledit calcul des valeurs DC_Pi(t) est en outre fonction de l'évolution de P valeurs moyennes antérieures de NICRP(t) calculées chacune sur une fenêtre temporelle d'une durée D prédéterminée. Avantageusement, ledit calcul des valeurs DC_Pi(t) est en outre 15 fonction du nombre et de l'état de polarisation verticale VProc_Pi représentatif de l'état des processeurs affectés à chacune des partitions Pi. On entend par « polarisation » au sens du présent brevet le paramètre décrit dans le brevet US8015335 et se référant an au 20 nombre et à l'état des processeurs affectés à une ressources. Selon un premier mode de réalisation, ledit calcul est effectué pour les seules ressources et partitions d'un même serveur. Selon un deuxième mode de réalisation, ledit calcul est 25 effectué pour les ressources et partitions d'une pluralité de serveurs. 3041788 - 7 - Description d'un exemple non limitatif de réalisation de l'invention La présente invention sera mieux comprise à la lecture de la description qui suit, concernant un exemple non limitatif de 5 réalisation illustré par les dessins annexés où : - la figure 1 représente une vue schématique de l'architecture matérielle d'un serveur selon l'invention - la figure 2 représente une vue schématique de l'architecture fonctionnelle d'un serveur selon l'invention 10 - la figure 3 représente l'architecture d'une partition et des procédés de collecte des informations - la figure 4 représente une vue fonctionnelle schématique d'un moniteur. Architecture matérielle 15 Dans les systèmes informatiques « gros serveur » (par exemple mainframe d'IBM 390) le nombre de partitions est limité, par exemple 15 partitions logiques. Dans des systèmes plus récents utilisant une architecture de type Z (marque déposée), on prévoit un plafonnement de taille de la mémoire, des 20 interfaces entrée/sortie et de la disponibilité, et la puissance de traitement disponible peut être limitée à un niveau inférieur à ce plafonnement. La figure 1 représente une vue schématique de l'architecture matérielle d'un système selon l'invention 25 constitué de deux serveurs (1, 2). Bien entendu, le nombre de serveurs peut être supérieur à deux. Chaque serveur (1, 2) est partitionné en une pluralité de partitions logiques qui se partagent les ressources matérielles, notamment les ressources processeurs. 3041788 -8 Chaque processeur est caractérisé par un état de polarisation verticale ou horizontale. Chaque serveur (1, 2) comporte plusieurs processeurs (11, 12, 13 ; 21, 22, 23) ainsi qu'un gestionnaire 5 de processeur (14, 24) de type PR/SM (« Processor Resource/System Manager ») gérant la répartition de la puissance de calcul entre les partitions logiques. Chaque serveur (1, 2) comporte également une unité de supervision « support element » (15, 25) qui gère la 10 configuration du serveur en particulier le nombre de processeurs disponibles, la taille de la mémoire et plus généralement l'état physique et l'administration du serveur par l'intermédiaire de consoles (19, 29). Chaque serveur (1, 2) comporte également des cartes 15 de communication (16, 26) avec des mémoires externes (18, 28) et des cartes réseau (17, 27) pour la communication avec des terminaux clients (10, 20). Architecture fonctionnelle La figure 2 représente un exemple d'architecture 20 fonctionnelle. Chaque serveur (1, 2) héberge une pluralité de partitions logiques (101 à 104 ; 201 à 204). Chaque partition logique (101 à 104 ; 201 à 204) comprend un collecteur (111 à 114 ; 211 à 214) qui collecte des informations « métriques » 25 comprenant : - la valeur de paramètres DC_Pi(t) de plafonnement de la capacité de chacune des partitions Pi variables dans le temps et recalculée périodiquement, 3041788 - 9 - le résultat NICRP(t) mesurant le niveau instantané de consommation des ressources processeur de l'ensemble des partitions Pi le résultat NICTi (t) mesurant le niveau 5 instantané des charges de travail de chacune des partitions Pi, l'état de plafonnement de chacune des partitions Pi. Ces informations sont calculées à partir des données 10 disponibles via le système d'exploitation par des traitements implémentés dans chaque partition. Ces informations sont, par exemple, enregistrées dans les blocs de contrôle de l'architecture Z d'IBM (noms commerciaux) comme illustré par la figure 3 représentant l'architecture 15 d'une partition (101) et les procédés de collecte des informations. Chaque partition (101) est associée à un collecteur (301). Le collecteur (301) est constitué par un programme d'ordinateur procédant à la lecture des informations dans les 20 blocs de contrôle (302 à 304) concernant le serveur dans sa globalité, la partition logique (101), la caractérisation de l'affectation des ressources processeurs, en particulier dans les blocs de contrôle (305 à 307) intitulée « z/OS Workload Management (WLM) » dans l'architecture Z d'IBM (noms 25 commerciaux). Ces données sont enregistrées périodiquement et historisées dans une mémoire (308) du collecteur (301). Le système comprend soit un seul moniteur (400), ou plusieurs, généralement un par serveur (1, 2). 30 Le moniteur (400) représenté en figure 4 procède à la lecture périodique des données enregistrées dans la mémoire (308) des 3041788 - 10 - collecteurs (301), via un réseau et un protocole TCP/IP. Ces données font l'objet de traitements pour calculer périodiquement, pour chacune des partitions Pi les paramètres DC_Pi(t) de plafonnement de la capacité de chacune des 5 partitions Pi. Ce moniteur (400) comporte un module d'interfaçage (401) éventuellement distinct, générant les instructions numériques pour commander l'application de ces paramètres de plafonnement via l'hyperviseur PR/SM (14, 24) (Processor Resource/System 10 Manager) et les éléments de supervision (15, 25), afin de modifier périodiquement la puissance allouée à chacune des partitions pour lesquelles les données ont été collectées, et, suivant la configuration du système, le nombre de processeurs actifs. 15 L'application de ces paramètres peut avoir pour conséquence la modification de la configuration processeur du serveur (1, 2). Cette commande est envoyée à l'hyperviseur (14, 24) selon deux modes possibles : - le premier mode utilise l'application (240) 20 BCPii (« Base Control Program Internal Interface » (nom commercial)) pour communiquer avec les éléments de supervision (15, 25) - un deuxième mode utilise le réseau HMC « hardware management consol » (250) pour 25 communiquer avec les éléments de supervision (15, 25). Ces données et les identifiants des modifications sont également exploitées pour construire des représentations graphiques ou textuelles représentatives de l'évolution du 30 système. Elles peuvent aussi être exploitées pour générer des messages électroniques, ou des informations de performances, 3041788 par exemple selon un format universel SMF (« system measurement facility »). Optionnellement, l'invention peut également prévoir des moyens de changement automatique ou par commande de paramètres de 5 fonctionnement par exemple en fonction d'un gestionnaire d'évènements ou de calendrier. Elle peut également prévoir des moyens de générations d'alertes, par exemple sous forme de messages électroniques. Traitement des données 10 Les données collectées et/ou calculées comprennent : - des données relatives aux serveurs (1, 2) telles que le nom, l'identifiant technique, le type de serveur, la capacité du serveur, le nombre de processeurs physiques et 15 logiques, le nombre de partitions configurées, la somme des poids relatifs des partitions, la somme des plafonnements, la somme des consommations instantanées, la somme des moyennes sur une période temporelle D prédéterminée, le ratio nombre de processeurs physiques / nombre de processeurs logiques,... 20 - des données relatives aux partitions (101 à 104 ; 201 à 204) telles que le nom, le nom du complexe (au sens « syplex » tel qu'exposé dans la notice http://www.redbooks.ibm.com/redbooks/pdfs/sg244356.pdf) auquel la partition appartient, son poids relatif, son plafonnement 25 ainsi que l'état de son plafonnement, sa consommation instantanée, la moyenne sur une période temporelle D prédéterminée, le nombre de processeurs logiques, la tendance d'évolution de sa consommation, ... - des données relatives aux composants 30 gestionnaires de charge de travail de chacune des partitions 3041788 - 12 - (WLM) destinées à optimiser la charge de la machine et du réseau, telles que les classes de service, la consommation par classe de service et par période,... - des données relatives au nombre et au type de 5 polarisation (moyen, haut, bas) des processeurs, pour chacune des partitions logiques. Par ailleurs, le traitement met en oeuvre des paramètres personnalisables Kuser tels que : - des paramètres généraux tels que l'intervalle temporel de collecte, les coefficients modérateurs fixant un seuil minimal de variation de la capacité de chaque partition, les seuils haut et bas de plafonnement autorisé du serveur (CPC MAX, CPC MIN,) _ _ _ - des paramètres d'alerte tels que des seuils de déclenchement de l'envoi d'un message électronique ou d'une action - des paramètres relatifs aux partitions logiques, tels que des seuils haut et bas de plafonnement autorisé de chaque partition (MSU _MAX, MSU MIN,), les critères de priorité, la marge de sécurité, une valeur de réactivité, un attribut de protection de chaque partition destinée à contrecarrer le plafonnement en fonction de circonstances définies par l'utilisateur ou calculées automatiquement, l'appartenance à un groupe de partitions logiques,... - des clés de sécurité. Ces données susvisées font l'objet d'un traitement 30 périodique pour le calcul du plafonnement de chaque partition logique, consistant à : 10 15 20 25 3041788 - 13 - - réallouer les capacités entre les partitions logiques disponibles - en cas de surcapacité, réallouer les capacités entre les partitions logiques réelles et une partition logique 5 virtuelle ('fantôme') afin de réduire le plafonnement global des serveurs (1, 2). A cet effet, on fixe une limite du plafonnement pour chaque partition logique, calculée en fonction des seuils susvisés haut et bas des partitions (101 à 104 ; 201 à 204) et 10 des serveurs (1, 2), en fonction des paramètres K., susvisés définis par l'utilisateur et des données collectées. 15 REVENDICATIONS1 - Procédé de contrôle de la capacité d'utilisation d'un système partitionné de traitement de données, ledit système étant configuré pour présenter une pluralité de partitions 5 logiques partageant des ressources physiques communes, le procédé consistant à limiter l'accès aux ressources processeurs desdites partitions Pi en fonction de la valeur de paramètres DC_Pi(t) de plafonnement de la capacité de chacune des partitions Pi variables, dans le temps et recalculée 10 périodiquement, caractérisé en ce que lesdites valeurs DC_Pi(t) sont recalculées périodiquement en fonction : du résultat NICRP(t) de mesure du niveau instantané de consommation des ressources 15 processeur de l'ensemble des partitions Pi du résultat NICTi (t) de mesure du niveau instantané des charges de travail de chacune des partitions Pi, de l'état de plafonnement de chacune des 20 partitions Pi - d'au moins un paramètre « Ruser » déterminé par l'utilisateur. 2 - Procédé de contrôle de la capacité d'utilisation d'un système partitionné de traitement de données selon la 25 revendication 1 caractérisé en ce que ledit calcul des valeurs DC_Pi(t) est en outre fonction de la valeur antérieure DC_Pi(tn) 3 - Procédé de contrôle de la capacité d'utilisation d'un système partitionné de traitement de données selon la 30 revendication 1 ou 2 caractérisé en ce que ledit calcul des valeurs DC_Pi(t) est en outre fonction de l'évolution de N valeurs NICRP(t) antérieures. 3041788 - 15 - 4 - Procédé de contrôle de la capacité d'utilisation d'un système partitionné de traitement de données selon la revendication 1 ou 2 caractérisé en ce que ledit calcul des valeurs DC_Pi(t) est en outre fonction de l'évolution de P valeurs moyennes antérieures de NICTi(t) calculées chacune sur une fenêtre temporelle d'une durée D prédéterminée. 5 - Procédé de contrôle de la capacité d'utilisation d'un système partitionné de traitement de données selon la revendication 1 ou 2 caractérisé en ce que ledit calcul des valeurs DC_Pi(t) est en outre fonction de l'évolution de M valeurs antérieures du résultat NICRP(t). 6 - Procédé de contrôle de la capacité d'utilisation d'un système partitionné de traitement de données selon la revendication 3 ou 4 caractérisé en ce que ledit calcul des valeurs DC_Pi(t) est en outre fonction de l'évolution de P valeurs moyennes antérieures de NICRP(t) calculées chacune sur une fenêtre temporelle d'une durée D prédéterminée. 7 - Procédé de contrôle de la capacité d'utilisation d'un système partitionné de traitement de données selon l'une au moins des revendications précédentes caractérisé en ce que ledit calcul des valeurs DC_Pi(t) est en outre fonction du nombre et de l'état de polarisation verticale VProc_Pi représentatif de l'état des processeurs affectés à chacune des partitions Pi. 8 - Procédé de contrôle de la capacité d'utilisation d'un système partitionné de traitement de données, selon la revendication 1 caractérisé en ce que ledit calcul est effectué pour les seules ressources et partitions d'un même serveur. 3041788 - 16 - 9 - Procédé de contrôle de la capacité d'utilisation d'un système partitionné de traitement de données, selon la revendication 1 caractérisé en ce que ledit calcul est effectué pour les ressources et partitions d'une pluralité de 5 serveurs.