FR3096156A1

FR3096156A1 - Plafonnement du rythme de transactions entrantes dans des échanges avec état entrants établis dans un environnement informatique distribué

Info

Publication number: FR3096156A1
Application number: FR1905027A
Authority: FR
Inventors: Aurélie Mahiné ALLAIN-GRANDVALET; Daniel Camille Bernard LEVY; Julien DELACROIX; Laurent STACUL
Original assignee: Amadeus SAS
Current assignee: Amadeus SAS
Priority date: 2019-05-14
Filing date: 2019-05-14
Publication date: 2020-11-20
Anticipated expiration: 2039-05-14
Also published as: FR3096204B3; FR3096204A3; US20200365156A1; US11763822B2; US20220005479A1; US11127404B2; FR3096156B1

Abstract

La présente invention concerne un procédé et un système pour plafonner des transactions entrantes d’échange avec état établis entre un client et une pluralité de serveurs d’échange d’un intégrateur de services. Pour chaque client, un groupe de serveurs d’échange est affecté pour prendre en charge les échanges avec état entrants qui ont été initiés. Chaque serveur d’échange dans le groupe diffuse périodiquement une valeur locale de trafic aux autres serveurs d’échange dans le groupe. Chaque serveur d’échange dans le groupe calcule une limite de plafonnement de transaction basée sur une limite globale de plafonnement de transaction de client et les valeurs locales de trafic diffusées par les autres serveurs d’échange dans le groupe. Chaque serveur d’échange limite le rythme de transactions entrantes reçues par le client lorsque la limite locale de plafonnement de transactions est dépassée. Figure pour l’abrégé : Fig. 3

Description

Plafonnement du rythme de transactions entrantes dans des échanges avec état entrants établis dans un environnement informatique distribué

La présente invention concerne un procédé et un système pour plafonner le rythme de transactions dans des échanges avec état établis entre au moins un client et au moins une application logicielle en cours d’exécution dans un environnement informatique distribué.

Au cours des quelques dernières années, la distribution des services/applications via une plateforme informatique en nuage est devenue chose ordinaire. L’avantage principal de l’informatique en nuage est qu’elle ne rencontre pas la plupart des soucis liés au matériel physique et/ou aux ressources logicielles, permettant ainsi aux utilisateurs de se concentrer sur le cœur de leur activité plutôt que de se préoccuper de la maintenance et du déploiement de centres de données. Le modèle d’informatique en nuage est basé sur l’octroi, à un utilisateur, d’un accès à des ressources informatiques physiques sur une base de facturation à l’utilisation selon laquelle l’utilisateur paie les ressources informatiques attribuées pour faire fonctionner les services/applications requis sur la plateforme informatique en nuage. Au fur et à mesure que la demande pour les applications/services gérés en nuage évolue, les ressources spécifiques sous-jacentes peuvent être dimensionnées de façon dynamique pour satisfaire les besoins informatiques des services/applications en nuage à tout moment donné.

De façon générale, l’accès à une application logicielle sur une plateforme informatique en nuage nécessite l’établissement d’un échange entre au moins un client et au moins un serveur d’applications. L’échange peut être facilité au moyen d’un module de gestion de trafic, p. ex. un intégrateur de services (SI) ou un bus de services d’entreprise (ESB) qui peut être responsable du traitement des interrogations de clients entrantes, du routage de messages entre le client et au moins un serveur d’applications et de plusieurs autres fonctions de communication en sous-couche. Le module de gestion de trafic permet aux messages d’être échangés entre au moins un client et au moins un serveur d’applications dans une série de transactions organisées via un protocole de communication préféré. Le protocole de communication utilisé par le module de gestion de trafic peut être de type sans état ou avec état. Dans un protocole sans état, le module de gestion de trafic n’est pas requis pour retenir l’information de session ou le statut de chaque partie en communication pendant la durée de l’échange établi. Des exemples de protocoles sans état peuvent inclure le protocole Internet (IP) qui est la fondation de l’Internet et le protocole de transfert hypertexte (HTTP) qui est la fondation de la communication de données du Web.

D’autre part, dans un protocole avec état, le module de gestion de trafic est requis pour maintenir l’information de session et le statut de chaque partie en communication pendant la durée de l’échange établi. Dans un échange avec état, une pluralité de serveurs d’échange peut être utilisée pour mapper les échanges entrants, établis entre le client et les serveurs d’échange en utilisant le protocole du client, sur des échanges sortants, établis entre les serveurs d’échange et au moins une application qui peut utiliser un protocole de communication différent. Par conséquent, le maintien du mappage entre des échanges entrants et sortants nécessite le maintien et le stockage de l’information relevant des interactions entre les parties en communication pendant la durée de chaque conversation.

Bien que des échanges avec état puissent être facilement équilibrés entre les serveurs d’échange p. ex. en distribuant de façon égale le nombre d’échange entrants établis par chaque client entre la pluralité des serveurs d’échange, il peut être extrêmement complexe d’équilibrer les transactions entrantes reçues pour chaque échange avec état entre la pluralité des serveurs. Le rythme des transactions entrantes, également appelé trafic entrant, pour chaque échange avec état est inhomogène, donc il est extrêmement difficile d’anticiper avec précision le volume de trafic entrant qui sera généré dans chaque échange avec état entrant. Il en résulte que des serveurs d’échange peuvent être requis pour gérer plus de transactions entrantes que d’autres serveurs d’échange, ce qui peut affecter la stabilité du module de gestion de trafic et impacter la qualité du service (QoS) attendue par d’autres clients conformément à leur accord de niveau de service (SLA). Par exemple, un client engagé dans un échange avec état peut surcharger le module de gestion de trafic avec un grand nombre de transactions entrantes qui surpasse les niveaux contractuels de leur SLA et affecte donc les ressources informatiques disponibles par le module de gestion de trafic pour gérer le trafic entrant d’autres clients.

Un objectif de la présente invention est de fournir un procédé et un système pour plafonner le rythme des transactions entrantes prises en charge par les serveurs d’échange d’un intégrateur de services dans des échanges avec état entrants établis par un client. Le procédé et le système de la présente invention peuvent augmenter la précision d’anticipation du trafic entrant attendu à chaque serveur d’échange qui prend en charge des transactions entrantes d’échange avec état entrants, ce qui peut améliorer la vitesse avec laquelle le plafonnement est déclenché à chaque serveur d’échange.

L’objectif de la présente invention est accompli conformément à l’invention avec le système et le procédé montrant les caractéristiques techniques des aspects ci-dessous.

Selon un premier aspect de la présente invention, un procédé peut être fourni pour plafonner un rythme de transactions entrantes dans des échanges avec état entrants établis entre un client et une pluralité de serveurs d’échange d’un intégrateur de services. Chaque serveur d’échange étant configuré pour mapper au moins un échange avec état entrant sur au moins un échange avec état sortant qui est établi entre les serveurs d’échange et au moins un serveur d’applications, le procédé comprenant :
l’affectation, au moyen d’un moteur d’affectation de serveur, d’un groupe de serveurs d’échange pour gérer les échanges avec état entrants établis par le client, le groupe de serveurs d’échange étant sélectionné à partir de la pluralité des serveurs d’échange ; et
pour chaque serveur d’échange sélectionné dans le groupe
la détermination au moyen d’un moteur de veille d’une valeur locale de trafic entrant associée au rythme des transactions entrantes prises en charge par le serveur d’échange sélectionné ;
la diffusion au moyen d’un moteur de diffusion d’une valeur locale de trafic à chacun des autres serveurs d’échange sélectionnés dans le groupe, la valeur locale de trafic étant calculée sur la base de la valeur locale de trafic entrant du serveur d’échange sélectionné ;
le calcul par un moteur de calcul de limite d’une limite locale de plafonnement de transactions, basée sur une limite globale de plafonnement de transactions de client et les valeurs locales de trafic diffusées reçues des autres serveurs d’échange sélectionnés, en définissant le volume maximum de transactions entrantes devant être pris en charge par le serveur d’échange sélectionné ; et
le plafonnement, au moyen d’un moteur de plafonnement de transactions, du rythme de transactions entrantes lorsque la limite locale de plafonnement de transactions a été dépassée.

Il a été constaté que le plafonnement du rythme de transactions entrantes en utilisant une limite locale de plafonnement de transactions calculée à chaque serveur d’échange peut assurer la stabilité de l’intégrateur de service en empêchant la surcharge de ses ressources informatiques. Chaque serveur d’échange impliqué dans des échanges avec état initiés par un client calcule indépendamment une limite locale de plafonnement de transactions, assurant ainsi que les échanges avec état avec un rythme de transactions entrantes dépassant la limite de plafonnement de transactions sont limités à un seuil prédéterminé. La limite locale de plafonnement de transactions peut définir le nombre maximum de transactions entrantes devant être gérées par le serveur d’échange sur la base d’une limite globale de plafonnement de transactions de clients et des valeurs locales de trafic diffusées par les autres serveurs d’échange. La présente invention, tient compte du comportement global d’un client dans tous les échanges avec état initiés et par conséquent détermine comment plafonner le mieux possible la totalité du trafic entrant généré par le client sans impacter la QoS attendue qui peut avoir été définie dans le SLA du client et la QoS attendue par d’autres clients partageant les mêmes ressources informatiques. En fournissant une limite locale de plafonnement de transactions, il est possible d’assurer qu’au fur et à mesure que le trafic entrant généré par un client augmente, la somme de toutes les transactions entrantes impliquées dans tous les échanges avec état de clients pris en charge par un groupe de serveurs d’échange affectés converge vers une limite globale de plafonnement de transactions prédéfinie. Par conséquent, avec le présent procédé suffisamment de capacité informatique est fournie à chaque client pour satisfaire la QoS définie dans le SLA du client tout en minimisant le risque que le client surcharge des ressources informatiques de l’intégrateur de services. On remarquera que la présente invention peut également être appliquée à un bus de services d’entreprise (ESB) ou à toute autre ressource informatique ayant une fonctionnalité similaire à celle de l’intégrateur de services (SI).

Selon des modes de réalisation, la valeur locale de trafic définit une valeur minimale de trafic entrant attendue calculée à partir de la valeur locale de trafic entrant.

Il a été constaté qu’en calculant le trafic entrant minimal sur chaque serveur d’échange dans le groupe, il est possible de prévoir le trafic total qui serait généré par le client, ce qui peut être utilisé pour déterminer le nombre de serveurs d’échange requis dans le groupe pour servir le client. Par exemple, si le trafic minimum attendu par serveur est en dessous d’une certaine valeur p. ex. en dessous de 200 transactions par seconde (TPS), il peut être avantageux de réduire le nombre de serveurs d’échange dans le groupe et de concentrer les échanges avec état entrants de sorte que chaque serveur d’échange reçoive un volume désiré de trafic. Par ailleurs, le calcul de la limite locale de plafonnement de transaction basée sur le trafic attendu minimal estimé qui serait géré par chaque serveur dans le groupe, peut assurer que la limite locale de plafonnement de transactions est maintenue à, ou au-dessus, du trafic minimum accepté défini dans le SLA.

Selon des modes de réalisation, le calcul d’une limite locale de plafonnement de transactions sur un serveur d’échange donné « s » comprend les étapes suivantes :

le calcul d’une première valeur représentant une première limite locale de plafonnement de transactions obtenue à partir de
[Math. 1] ;
le calcul d’une deuxième valeur représentant une deuxième limite locale de plafonnement de transactions obtenue de
G – (L – ls) ; et
la sélection de la plus élevée de la première et seconde valeur comme limite locale de plafonnement de transactions ;
où, pour le client :
ls représente pour le serveur « s » la valeur locale minimale attendue de trafic entrant,
[Math. 2] ,
represente la somme du trafic minimal attendu sur tous les serveurs d’échange dans le groupe,
G = la limite globale de plafonnement de transactions.

Il a été constaté que les étapes ci-dessus assurent avec une probabilité élevée que le trafic total entrant géré par tous les serveurs d’échange, sur la base de leur limite locale de plafonnement de transactions, est égal ou supérieur à la limite globale de plafonnement de transactions du client. Par conséquent, la QoS attendue par le client est préservée tout en empêchant le client de surcharger les ressources informatiques de l’intégrateur de services. La première valeur peut représenter la limite globale de transactions pour chaque client proportionnellement au trafic minimal local entrant attendu à chaque serveur d’échange divisé par la somme de trafic attendu sur tous les serveurs d’échange dans le groupe. La deuxième valeur peut définir la capacité disponible des serveurs d’échange dans le groupe qui peut être représentée comme trafic manquant. En prenant la valeur la plus élevée de la première et deuxième valeur comme limite locale de plafonnement de transactions à chaque serveur d’échange, on peut assurer que le nombre maximum de requêtes de clients entrantes pouvant être gérées par tous les serveurs d’échange dans un échange avec état, est maintenu au-dessus de la valeur définie par la limite globale de plafonnement de transaction définie dans le SLA du client.

Selon des modes de réalisation, la valeur minimale de trafic entrant attendue est calculée à partir d’une analyse 3-sigma de la limite inférieure de la valeur de trafic entrant de chaque serveur d’échange dans le groupe.

Il a été constaté qu’en utilisant une analyse 3-sigma de la limite inférieure du trafic local entrant de chaque serveur d’échange, on assure que le trafic entrant minimal attendu est calculé avec plus de précision. Par conséquent, il est possible de prévoir plus précisément sur le trafic entrant qui serait géré par chaque serveur d’échange sélectionné et donc, le cas échéant, d’ajuster le nombre de serveurs d’échange dans le groupe. De cette façon, il est possible d’ajuster de façon dynamique le nombre de serveurs d’échange dans le groupe de sorte qu’en moyenne chacun d’eux gère un volume prédéterminé de transactions entrantes.

Selon des modes de réalisation, l’étape de calcul de la limite locale de plafonnement de transactions est déclenchée de façon dynamique lors de la réception d’une nouvelle valeur locale de trafic provenant d’au moins un autre serveur d’échange dans le groupe.

En calculant la limite locale de transactions chaque fois qu’il y a un changement dans le trafic entrant minimal attendu de chaque serveur d’échange dans le groupe de serveurs d’échange, on assure que la limite locale de plafonnement de transactions est ajustée de façon dynamique en fonction de la demande. Par conséquent, au fur et à mesure que la demande pour le service augmente, le plafonnement de transactions, également appelé limitation, pour chaque client peut devenir plus agressif. Au fur et à mesure que le trafic entrant à chaque serveur augmente, la précision de l’analyse 3-sigma de la limite inférieure devient plus précise, permettant ainsi de déterminer une limite locale de transactions à chaque serveur qui est proche ou égale à un seuil prédéterminé, p. ex. la limite globale de transactions de client indiquée dans le SLA.

Selon des modes de réalisation, l’étape de calcul de la limite locale de transaction est déclenchée de façon dynamique lors de la réception d’une notification concernant un changement d’état d’un serveur d’échange.

Le nombre de serveurs d’échange disponibles dans le groupe peut changer pour un nombre de raisons au cours de la durée des échanges avec état établis par le client, p. ex. un serveur est à l’arrêt ou en pause. Par conséquent, la limite locale de plafonnement de transactions aurait besoin d’être recalculée chaque fois qu’il y a un changement dans l’état d’un serveur d’échange dans le groupe. De cette façon, on assure que la limite locale de plafonnement de transactions de tous les serveurs d’échange disponibles dans le groupe est maintenue au-dessus de la limite globale de plafonnement de transactions de clients afin de maintenir la QoS attendue par le client.

Selon des modes de réalisation, la valeur locale de trafic de chaque serveur d’échange sélectionné est diffusée périodiquement à chacun des autres serveurs d’échange dans le groupe.

Il a été constaté qu’en diffusant périodiquement la valeur locale de trafic de chaque serveur d’échange dans le groupe, on augmente la précision du trafic minimal entrant attendu qui a été calculé. Par conséquent, la limite locale de plafonnement de transactions à chaque serveur d’échange peut être plus précisément ajustée pour refléter le trafic minimal entrant attendu, déterminé pour chaque serveur d’échange dans le groupe.

Selon des modes de réalisation, la somme des limites locales de plafonnement de transactions sur tous les serveurs d’échange dans le groupe est égale ou supérieure à la limite globale de transactions de client.

Il a été constaté que lorsque la somme des limites locales de plafonnement de transactions sur tous les serveurs d’échange est égale à, ou supérieure à, la limite globale de plafonnement de transactions de client, le client fait l’expérience d’une qualité de service (QoS) conforme au SLA, tout en maintenant le rythme de transactions entrantes reçues par chaque client plafonné à un seuil prédéterminé qui peut être égal ou supérieur à la valeur correspondante dans le SLA du client, assurant ainsi que l’expérience de QoS d’autres clients n’est pas affectée.

Selon des modes de réalisation, l’étape de plafonnement du rythme de transactions comprend de vérifier si la limite locale de plafonnement de chaque serveur d’échange dans le groupe a été atteinte afin de déterminer si une transaction de client peut être traitée par les serveurs d’échange dans le groupe. Par exemple, l’étape de plafonnement peut être effectuée en utilisant un algorithme de corbeille de jetons.

Il a été constaté que le fait de vérifier si un serveur d’échange a atteint sa limite locale de plafonnement de transactions avant d’envoyer une transaction, garantit que le client sera notifié rapidement que la limite a été atteinte et peut aider à réduire le volume du trafic transmis sur le réseau.

Conformément à des modes de réalisation, l’étape d’affectation d’un groupe de serveurs d’échange pour gérer les échanges avec état entrants établis par le client comprend :
l’établissement, pour chaque échange avec état entrant, d’au moins une connexion entre le client et une pluralité de multiplexeurs de l’intégrateur de services ;
la sélection, au moyen de la pluralité des multiplexeurs, d’un groupe de serveurs d’échange de la pluralité des serveurs d’échange pour prendre en charge les transactions entrantes de tous les échanges avec état entrants établis par le client ; et
la distribution, par une pluralité de multiplexeurs, de chaque échange avec état entrant correspondant à des serveurs d’échange sélectionnés dans le groupe.

Il a été constaté que l’utilisation de multiplexeurs pour le routage d’échanges avec état entrants présente l’avantage que le routage des transactions entrantes vers les serveurs d’échange peut être adapté aux changements rencontrés dans le volume de trafic entrant géré par les serveurs d’échange sélectionnés dans le groupe. Par exemple, les multiplexeurs peuvent ajuster le nombre de serveurs d’échange dans le groupe pour accommoder les changements détectés dans le trafic entrant attendu déterminé pour chaque serveur d’échange.

Selon des modes de réalisation, l’étape d’établissement d’au moins une connexion pour chaque échange avec état entrant comprend :
la réception des connexions par un module d’équilibrage de charge interposé entre le client et l’intégrateur de services, et
l’affectation desdites connexions à la pluralité des multiplexeurs de sorte que la charge est également distribuée.

Selon des modes de réalisation, l’étape de sélection d’un groupe de serveurs d’échange comprend une étape de détermination, basée sur la limite globale de transactions de client, du nombre de serveurs d’échange requis dans le groupe pour prendre en charge les transactions de clients entrantes.

Il a été constaté que le fait de déterminer le nombre de serveurs d’échange dans le groupe basé sur la limite globale de transactions de client permet avantageusement que le client reçoive toujours la QoS attendue, tout en empêchant la surcharge des serveurs d’échange avec des transactions entrantes, assurant ainsi que la QoS de services attendue par d’autres clients n’est pas affectée.

Selon des modes de réalisation, le nombre de serveurs d’échange dans le groupe est ajusté de façon dynamique en utilisant un algorithme hash-ring basé sur des changements de la valeur locale de trafic déterminée de chaque serveur d’échange.

Le nombre de serveurs d’échange dans le groupe peut être ajusté au fur et à mesure que la valeur locale de trafic de chaque serveur d’échange évolue dans le temps. Le nombre de serveurs d’échange dans le groupe peut être ajusté de sorte que chaque serveur d’échange reçoive un volume prédéterminé de trafic entrant pour assurer le calcul précis du trafic minimal entrant attendu en utilisant l’analyse 3-sigma ou une autre méthode statistique. Par exemple, le nombre de serveurs d’échange dans le groupe peut être adapté en utilisant un algorithme hash-ring, ou un autre algorithme. Par exemple, l’algorithme hash-ring peut être utilisé pour concentrer des échanges avec état sur des serveurs d’échange dans le groupe dans le cadre de faibles volumes de trafic entrant afin que chaque serveur d’échange dans le groupe reçoive au moins un volume désiré de trafic entrant, p. ex. 200 transactions par seconde (TPS).

Selon un deuxième aspect de la présente invention, un moteur de limitation peut être fourni pour plafonner les transactions entrantes dans des échanges entrants avec état établis entre un client et une pluralité de serveurs d’échange d’un intégrateur de services (SI). Chaque serveur d’échange étant configuré pour mapper au moins un échange avec état entrant sur au moins un échange avec état sortant qui est établi entre les serveurs d’échange et au moins un serveur d’applications, le moteur de limitation comprenant :
un moteur d’affection de serveur configuré pour affecter un groupe de serveurs d’échange pour gérer les échanges avec état entrants établis par le client, le groupe de serveurs d’échange étant sélectionné à partir de la pluralité des serveurs d’échange ; et pour chaque serveur d’échange sélectionné dans le groupe.
un moteur de veille configuré pour déterminer une valeur locale de trafic entrant associée au rythme des transactions entrantes prises en charge par le serveur d’échange sélectionné ;
un moteur de diffusion configuré pour diffuser une valeur locale de trafic à chacun des autres serveurs d’échange sélectionnés dans le groupe, la valeur locale de trafic étant calculée sur la base de la valeur locale de trafic entrant du serveur d’échange sélectionné ;
le calcul, par un moteur de calcul de limite, d’une limite locale de plafonnement de transactions basée sur une limite globale de plafonnement de transactions de client et les valeurs locales de trafic diffusées reçues des autres serveurs d’échange sélectionnés, en définissant le volume maximum de transactions entrantes devant être pris en charge par le serveur d’échange sélectionné ; et
un moteur de plafonnement de transactions configuré pour limiter le rythme de transactions entrantes lorsque la limite locale de plafonnement de transactions a été dépassée.

Selon des modes de réalisation du deuxième aspect, la valeur locale de trafic définit une valeur minimale de trafic entrant attendu calculée à partir de la valeur locale de trafic entrant.

Selon des modes de réalisation du deuxième aspect, le moteur de calcul de limite est configuré pour calculer la limite locale de plafonnement de transactions sur un serveur d’échange donné « s » en :
calculant une première valeur qui représente une première limite locale de plafonnement de transactions obtenue à partir de [Math. 3] ;
en calculant une deuxième valeur qui représente une deuxième limite locale de plafonnement de transactions obtenue à partir deG – (L – ls) ; et
en sélectionnant la plus élevée de la première et de la deuxième valeurs comme limite locale de plafonnement de transactions ;
où, pour le client :
ls représente pour le serveur « s » la valeur minimale locale attendue de trafic entrant, , represente la somme du trafic minimal attendu sur tous les serveurs d’échange dans le groupe,
G= la limite globale de plafonnement de transactions.

Selon des modes de réalisation de la présente invention la valeur minimale de trafic entrant attendue est calculée à partir d’une analyse 3-sigma de la limite inférieure de la valeur de trafic entrant de chaque serveur d’échange dans le groupe.

Selon des modes de réalisation du deuxième aspect, le moteur de calcul de limite est configuré pour calculer de façon dynamique la limite locale de plafonnement de transactions lors de la réception d’une nouvelle valeur locale de trafic provenant d’au moins un autre serveur d’échange dans le groupe.

Selon des modes de réalisation du deuxième aspect, le moteur de calcul de limite est configuré pour calculer de façon dynamique la limite locale de plafonnement de transactions lors de la réception d’une notification concernant un changement d’état d’un serveur d’échange.

Selon des modes de réalisation du deuxième aspect, le module de diffusion est configuré pour diffuser périodiquement la valeur locale de trafic de chaque serveur d’échange sélectionné à chacun des autres serveurs d’échange dans le groupe.

Selon des modes de réalisation du deuxième aspect, la somme des limites locales de plafonnement de transactions sur les serveurs d’échange dans le groupe est égale ou supérieure à la limite globale de transactions de client.

Selon des modes de réalisation du deuxième aspect, la limite globale de transactions de clients est obtenue au moins partiellement d’un accord de niveau de service (SLA) et/ou définie par un utilisateur.

Selon des modes de réalisation du deuxième aspect, le moteur de plafonnement de transactions est configuré pour vérifier si la limite locale de plafonnement de chaque serveur d’échange dans le groupe a été atteinte afin de déterminer si une transaction de client peut être traitée par les serveurs d’échange dans le groupe.

Selon des modes de réalisation du deuxième aspect, le moteur de plafonnement de transactions est configuré pour plafonner le rythme de transactions entrantes sur la base d’un algorithme de corbeille de jetons.

Selon des modes de réalisation du deuxième aspect, le moteur d’affectation de serveur est configuré pour affecter un groupe de serveurs d’échange pour gérer les échanges avec état entrants établis par le client en :
établissant, pour chaque échange avec état entrant, au moins une connexion entre le client et une pluralité de multiplexeurs de l’intégrateur de services ;
sélectionnant, au moyen de la pluralité des multiplexeurs, un groupe de serveurs d’échange à partir de la pluralité des serveurs d’échange pour gérer les transactions entrantes de tous les échanges avec état entrants établis par le client ; et
distribuant, par une pluralité de multiplexeurs, chaque échange avec état entrant correspondant à des serveurs d’échange sélectionnés dans le groupe.

Conformément à des modes de réalisation du deuxième aspect, l’établissement d’au moins une connexion à chaque échange avec état entrant est effectué par :
la réception des connexions par un module d’équilibrage de charge interposé entre le client et l’intégrateur de services, et
l’affectation desdites connexions à la pluralité des multiplexeurs de sorte que la charge est également distribuée.

Conformément à des modes de réalisation du deuxième aspect, le moteur d’affectation est configuré pour déterminer sur la base de la limite globale de transaction du client, le nombre de serveurs d’échange requis dans le groupe pour gérer les transactions entrantes de client.

Selon des modes de réalisation du deuxième aspect, le moteur d’affectation de serveur est configuré pour ajuster de façon dynamique le nombre de serveurs d’échange dans le groupe en utilisant un algorithme hash-ring basé sur des changements dans la valeur locale de trafic de chaque serveur d’échange.

La [Fig. 1] montre un exemple d’architecture pour connecter les clients à des plateformes en nuage via un intégrateur de services conformément à des modes de réalisation de la présente invention.

La montre un exemple d’un intégrateur de services conforme à des modes de réalisation de la présente invention.

La montre un exemple d’un moteur de limitation conforme à des modes de réalisation de la présente invention.

La [Fig. 5] montre un exemple d’une limite inférieure 3-sigma de trafic minimal entrant attendu conformément à des modes de réalisation de la présente invention.

La [Fig. 6] illustre un exemple montrant comment le nombre de serveurs (n) pour une limite globale de transactions donnée (G) dans le pire des scénarios, où le trafic entrant est également réparti entre les serveurs d’échange, affecte le plafonnement du trafic entrant.

La [Fig. 7] illustre un exemple montrant comment le nombre de serveurs (n) pour une limite globale de transactions donnée (G) dans le pire des scénarios, où le trafic entrant est également réparti entre les serveurs des chambres, affecte le plafonnement du trafic entrant.

La [Fig. 8] illustre un exemple montrant comment la précision de plafonnement dépend du ratio entre la limite globale de transactions et le nombre de serveurs.

La présente invention sera illustrée en utilisant les modes de réalisation exemplaires montrés dans les figures 1 à 8 qui seront décrits de façon plus détaillée ci-dessous. Il faut noter que toutes références faites aux dimensions sont seulement indicatives et ne limitent d’aucune façon l’invention. Alors que l’invention a été montrée et décrite en faisant référence à certains modes de réalisation, l’homme de métier comprendra que diverses modifications dans la forme et les détails peuvent y être apportées sans pour autant s’éloigner du champ d’application de l’invention. Par ailleurs, alors que l’invention a été décrite en faisant référence à un système et/ou à un procédé particulier pour plafonner le rythme de transactions entrantes dans des échanges avec état entrants établis entre un client et une pluralité de serveurs d’échange d’un intégrateur de services, les hommes de métier comprendront que des changements dans la forme et les détails peuvent être apportés pour faciliter d’autres types de procédés et/ou de systèmes sans s’éloigner du champ d’application de l’invention.

La figure 1 montre un exemple d’une architecture permettant aux clients 100 de se connecter à au moins un serveur d’une plateforme en nuage 500 via un intégrateur de services 300. L’intégrateur de services (SI) 300 est configuré pour recevoir des échanges avec état entrants provenant de clients via un réseau de communication 200, lesquels sont ensuite mappés sur des échanges sortants établis entre le SI 300 et au moins un serveur d’applications de la plateforme en nuage 500 via un deuxième réseau de communication 400. De cette façon, les clients 100 peuvent échanger des messages avec un serveur d’applications d’une plateforme en nuage 500 en utilisant un protocole avec état qui exige que l’information appartenant à la communication de chaque client 100 ainsi que ledit au moins un serveur d’application soient maintenus pendant la durée de l’échange. Les échanges avec état entrants peuvent être établis entre chaque client 100 et le SI 300 en utilisant le protocole du client via le réseau de communication 200 alors que les échanges sortants peuvent être établis entre le SI 300 et au moins un serveur d’applications de la plateforme en nuage 500 via un deuxième réseau de communication 400 qui peut utiliser un protocole de communication différent. Par conséquent, le maintien du mappage entre des échanges entrants et sortants nécessite le maintien et le stockage de l’information relevant des interactions entre les parties en communication pendant la durée de chaque échange.

La Figure 2 montre un exemple d’un intégrateur de services 300 conforme à des modes de réalisation de la présente invention. Un module d’équilibrage de charge (LB) 310 peut être associé à l’intégrateur de services 300, interposé entre le client et l’intégrateur de services 300. Le module d’équilibrage de charge 310 peut être configuré pour recevoir les connexions des clients et distribuer conformément lesdites connexions à une pluralité de multiplexeurs 320 de l’intégrateur de services (SI) 300. Le LB 310 peut être configuré pour distribuer les connexions des clients de sorte que la charge est équilibrée entre les multiplexeurs SI 320. Les multiplexeurs 320 sont configurés pour sélectionner un groupe de serveurs d’échange 330 du SI 300 pour gérer des transactions entrantes reçues via la connexion établie entre chaque client 100 et les multiplexeurs 320. Chaque client 100 peut ouvrir un nombre d’échanges avec état entrants, chacun étant établi entre le client 100 et le groupe de serveurs d’échange 330 du SI 300. Les multiplexeurs (SI MUX) 320 peuvent être configurés pour équilibrer les échanges avec état entrants sur les divers serveurs d’échange (SI SRV) 330 dans le groupe lors de la réception d’un message du client 100 commençant un nouvel échange. Le SI SRV 330 dans le groupe sélectionné pour chaque client 100 peut être configuré pour mapper les échanges avec état entrants sur un plusieurs échanges avec état sortants établis entre le SI SRV 330 et un plusieurs serveurs d’applications afin d’assurer la communication de messages entre le client 100 et au moins un serveur d’applications de la plateforme en nuage 500. Chaque échange avec état entrant peut comprendre une pluralité de transactions entrantes qui peut comprendre une requête de client et une réponse provenant des serveurs d’échange 330. Afin d’assurer que le nombre total de transactions entrantes initiées par chaque client dans tous les échanges avec état entrants ouverts n’affecte pas la QoS d’autres clients ou entraîne une surcharge des ressources informatiques SI, p. ex. en raison de l’utilisation d’un grand nombre de serveurs d’échange 330 requis pour gérer le volume de transactions entrantes, un moteur de limitation 340 peut être fourni, tel qu’illustré dans la figure 3. Le moteur de limitation 340 peut être configuré pour plafonner ou ramener le rythme de transactions entrantes dans des échanges avec état entrants conformément à une limite locale de plafonnement de transactions. La limite de plafonnement de transactions est calculée pour chaque serveur d’échange sélectionné 330 dans le groupe affecté pour prendre en charge le trafic entrant d’un client 100. La mise en œuvre de la limite locale de plafonnement de transaction calculée à chaque serveur d’échange peut empêcher la surcharge des ressources informatiques de l’intégrateur de services assurant ainsi sa stabilité, ce qui est un élément clé pour maintenir la QoS attendue par chaque client 100. Chaque serveur d’échange 330 impliqué dans des échanges avec état initié par un client 100 peut indépendamment calculer une limite locale de plafonnement de transactions, assurant ainsi que les échanges avec état avec un rythme élevé de transactions entrantes sont limités à un seuil prédéterminé.

La figure 4 montre un exemple d’un moteur de limitation 340 conforme à des modes de réalisation de la présente invention. Selon des modes de réalisation de la présente convention, un moteur de limitation est fourni à chaque client pour assurer le plafonnement des échanges entrants conformément à la limite globale de plafonnement de transactions établie pour chaque client. Chaque moteur de limitation 340 peut être fourni avec au moins un moteur d’affectation de serveur 341, au moins un moteur de veille 342 au moins un moteur de diffusion 343, au moins un moteur de calcul de limite 344 et au moins un moteur de plafonnement 345. Les composants du moteur de limitation peuvent être distribués entre les multiplexeurs 320 et les serveurs d’échange 330 du SI 300 comme illustré par la figure 3. Par exemple, chaque multiplexeur 320 peut être fourni avec un moteur d’affectation de serveur 341 alors que chaque serveur d’échange 330 peut être fourni avec un moteur de veille 342, un moteur de diffusion 343 et un moteur de calcul de limite 344. Une distribution différente des composants du moteur de limitation dans le SI 300 est aussi possible. Par ailleurs, le moteur de limitation 340 peut être fourni comme composant séparé qui peut faire partie de l’intégrateur de services (SI) 300 et peut être configuré pour communiquer avec les multiplexeurs 320 et les serveurs d’échange 330. Le moteur d’affectation de serveur 341 peut être configuré pour sélectionner pour un client un groupe de serveurs d’échange 330 à partir de la pluralité des serveurs d’échange 330 pour gérer les transactions entrantes d’échanges avec état entrants générés par le client. Par exemple, le moteur d’affectation de serveur 341 peut être configuré pour calculer, pour un client 100, sur la base de cette limite globale de transactions de client, le nombre de serveurs d’échange 330 requis pour prendre en charge le nombre de transactions entrantes définies dans le SLA de ce client. Le moteur d’affectation de serveur 341 peut être configuré pour distribuer le trafic entrant reçu du client 100 aux serveurs d’échange sélectionnés 330 dans le groupe. Le moteur d’affectation de serveur 341 peut être configuré pour ajuster de façon dynamique le nombre de serveurs d’échange 330 dans le groupe sur la base de changements du trafic moyen entrant reçu du client. Par exemple, le moteur d’affectation de serveur 341 peut augmenter ou réduire le nombre de serveurs d’échange 330 dans le groupe sur la base de la valeur locale de trafic diffusée par chaque serveur d’échange sélectionné 330. Dans le cas de faibles volumes de trafic entrant, p. ex. en dessous d’un certain seuil, le moteur d’affectation de serveur 341 peut utiliser un algorithme hash-ring pour concentrer les échanges avec état d’un client dans un nombre réduit de serveurs d’échange 330. Par exemple, le moteur d’affectation de serveur 341 peut être configuré pour utiliser l’algorithme hash-ring afin de concentrer des échanges avec état de sorte que chaque serveur d’échange 330 dans le groupe reçoive au moins un volume souhaité de trafic entrant, p. ex. 200 transactions par seconde (TPS). Le module de veille 342 peut être configuré pour déterminer, pour chaque serveur d’échange 330 dans le groupe, une valeur locale de trafic entrant associée au rythme de transactions entrantes prises en charge par chacun des serveurs d’échange 330 au cours d’une durée prédéterminée. Le moteur de diffusion 343 peut être configuré pour diffuser une valeur locale de trafic de chaque serveur d’échange sélectionné 330 à chacun des autres serveurs d’échange sélectionnés dans le groupe. La valeur locale de trafic peut être calculée sur la base de la valeur locale de trafic entrant reçue du module de veille 342 du serveur d’échange sélectionné. De cette façon, chaque serveur d’échange 330 dans le groupe a connaissance de la valeur de trafic entrant géré par chacun des serveurs d’échange 330 dans le groupe. Le moteur de diffusion 343 peut diffuser périodiquement la valeur locale de trafic de chaque serveur. Le moteur de calcul de limite 344 peut être configuré pour calculer, à chaque serveur d’échange 330, sur la base d’une limite globale de plafonnement de transactions d’un client 100 et de la valeur locale de trafic diffusée reçue des autres serveurs d’échange sélectionnés 330 dans le groupe, une limite locale de plafonnement de transactions définissant le volume maximum de transactions entrantes devant être pris en charge par le serveur d’échange sélectionné 330. Par exemple, le moteur de calcul de limite 344 peut calculer la limite locale de plafonnement de transactions sur un serveur d’échange donné « s » en calculant une première limite de plafonnement de transactions basée sur le ratio de la valeur locale minimale de trafic entrant attendue sur le serveur « s » (ls) et la somme du trafic minimal attendu sur tous les serveurs d’échange 330 dans le groupe (L), le ratio étant multiplié par la limite globale de plafonnement de transactions de client (G), c.-à-d. [Math. 5] .

Pour assurer la précision et pour maintenir la limite de plafonnement au même niveau ou au-dessus de la limite globale de calcul de client, le moteur de calcul de limite 344 peut calculer une deuxième valeur locale de plafonnement de transactions. La deuxième valeur locale de plafonnement de transaction peut être calculée comme étant la différence entre la limite globale de transactions de client et la somme du trafic minimal entrant attendu dans tous les serveurs d’échange 330 moins le trafic minimal entrant attendu sur le serveur d’échange donné « s », c.-à-d. G -(L-ls), qui peuvent être envisagés comme étant le trafic entrant manquant qui doit être accepté par les serveurs d’échange 330 dans le groupe pour assurer que le SLA n’est pas contrevenu. Afin de garantir la QoS attendue pour le client, le moteur de calcul de limite 344 peut sélectionner la limite locale de plafonnement de transactions pour le serveur d’échange « s » la valeur la plus élevée de la première et de la deuxième valeur de plafonnement de transactions calculées précédemment, c.-à-d. [Math. 6] ., .

Le moteur de calcul de limite 344 peut calculer la limite locale de plafonnement de transactions dans chaque serveur d’échange 330 dans le groupe en suivant les mêmes étapes que pour le serveur d’échange « s ». Le calcul de la limite locale de plafonnement de transactions peut être déclenché lors de la réception au moteur de calcul de limite 344 d’une nouvelle valeur locale de trafic entrant provenant d’au moins un autre serveur d’échange 330 dans le groupe et/ou lors de la notification que l’état d’un serveur d’échange 330 dans le groupe a changé, p. ex. le serveur d’échange est en pause, arrêté, ou autre. Le moteur de calcul de limite 344 peut calculer la valeur minimale de trafic entrant attendue en utilisant une analyse 3-sigma de la limite inférieure sur le trafic entrant moyen dans chaque serveur d’échange. L’analyse 3-sigma assure que le trafic minimal entrant attendu serait calculé avec une précision élevée, permettant ainsi un calcul précis de la limite locale de plafonnement de transactions sur chaque serveur d’échange. De cette façon, le plafonnement, également appelé limitation, des transactions entrantes d’un client peut être déclenché uniquement lorsque la limite de plafonnement de transactions a été dépassée. La figure 5 illustre un exemple montrant comment le calcul du trafic minimal entrant attendu, en utilisant l’analyse 3-sigma comparativement au trafic actuel entrant. Ainsi qu’illustré, le trafic minimal attendu 700 prévu à chaque serveur d’échange 330 pendant la durée d’un échange est plus bas que le trafic entrant actuel. Par conséquent, la somme des limites de plafonnement de transactions calculée pour les serveurs d’échange 330 serait plus élevée que la limite globale de transactions de client. De cette façon, la QoS attendue par les clients est maintenue tout en empêchant les clients de surcharger les ressources informatiques du SI 300. La précision de l’analyse 3-sigma augmente au fur et à mesure que le volume de trafic entrant augmente comme le montre l’exemple du tableau ci-dessous :

Le tableau 1 ci-dessous montre un exemple d’une analyse 3-sigma de la limite inférieure pour calculer le trafic minimal entrant attendu, avec le trafic modelé sur le processus de Poisson :

Le trafic moyen sur chaque serveur d’échange dans les transactions par seconde (TPS)	Le trafic minimal entrant attendu de la limite inférieure 3-sigma sur chaque serveur d’échange dans les transactions par seconde (TPS)
10
100
1000

Tableau 1 : analyse de limite inférieure 3-sigma pour calculer le trafic minimal entrant attendu, avec le trafic modelé sur le processus de Poisson

Sur le tableau ci-dessus, on peut constater que le trafic moyen entrant augmente, le trafic minimal entrant attendu calculé se rapproche du niveau actuel de trafic entrant pris en charge par chaque serveur d’échange 330. Sur la base de ce qui précède, le moteur d’affectation de serveur 341 peut décider, lorsque le trafic entrant moyen est faible, de grouper les échanges entrants, de sorte que le trafic entrant reçu à chaque serveur d’échange 330 est suffisamment élevé pour qu’une analyse 3-sigma significative puisse être effectuée par le moteur de calcul de limite 344 afin de déterminer avec une grande confiance la valeur minimale de trafic entrant attendu pour chaque serveur d’échange 330. Le moteur de plafonnement de transactions 345 peut être configuré pour limiter le rythme de transactions entrantes à chaque serveur d’échange 330 lorsque le trafic entrant reçu dépasse la limite locale de plafonnement de transactions. De cette façon, on empêche un client de surcharger les serveurs d’échange 330 du SI 300, ce qui pourrait affecter la stabilité du SI 300 et la QoS d’autres clients 100. Le moteur de plafonnement de transactions 345 peut être configuré pour vérifier si la limite locale de plafonnement de chaque serveur d’échange dans le groupe a été atteinte afin de déterminer si une transaction de client peut être traitée par les serveurs d’échange 330 dans le groupe. Le moteur de plafonnement 345 peut plafonner, ou limiter, les transactions entrantes en utilisant un algorithme de corbeille de jetons qui est continuellement mis à jour chaque fois qu’une nouvelle limite locale de plafonnement de transactions est calculée. Par conséquent, le niveau de limitation peut être ajusté au fur et à mesure que le volume de trafic entrant change dans le temps. Par exemple, lorsque le trafic entrant augmente le plafonnement peut devenir plus sévère.

Les figures 6 et 7 montrent des exemples de scénarios différents de plafonnement de transactions en utilisant le procédé de plafonnement et le moteur de limitation de la présente invention. La figure 6 montre un exemple où la limite globale de transactions de client (G) est égale à 1000 transactions par seconde (TPS) et le nombre (n) de serveurs d’échange 330 dans le groupe est égal à deux. La limite globale de transaction (G) définit le trafic maximum accepté 900 qui peut être géré par les deux serveurs d’échange 330 dans le groupe. Dans le scénario de la figure 6, le trafic total entrant de clients 800 est réparti de façon égale entre les deux serveurs d’échange 330 dans le groupe. Chaque serveur d’échange 330 dans le groupe est configuré pour gérer approximativement 500 TPS, p. ex. G/n= 1000/2=500 TPS. Dans ce cas, que l’on peut considérer comme le pire scénario, le plafonnement du trafic entrant de client 800 commencerait dès lors que le trafic accepté 900 dépasserait 1100 TPS plutôt que la limite globale de transaction de 1000 TPS. Au fur et à mesure que le trafic de clients entrant 800 augmente, le plafonnement peut devenir plus agressif jusqu’à ce que le trafic accepté 900 soit égal ou proche de la limite globale de plafonnement de transactions de 1000 TPS. Le trafic accepté 900 définit le volume de trafic maximum entrant qui est permis pour le traitement par le groupe de serveurs d’échange 330 et il est égal à la somme des limites de plafonnement de transactions calculée à chaque serveur d’échange 330 sur la base du trafic minimal entrant attendu, ainsi que défini précédemment. La raison pour le retard du plafonnement des transactions de clients entrantes 800 peut être associée à l’utilisation d’une méthode statistique, p. ex. l’analyse 3-sigma de la limite inférieure pour prévoir le trafic minimal entrant attendu à chaque serveur d’échange 330, comme décrit ci-dessus. Afin de prévoir avec grande confiance la valeur de trafic minimal entrant attendu de chaque serveur d’échange 330, la méthode statistique utilisée nécessite un volume prédéterminé de trafic entrant. Par exemple, comme l’illustre le tableau 1 ci-dessus, plus le trafic moyen entrant est élevé à chaque serveur d’échange 330, plus le trafic minimal entrant attendu prévu est proche de la valeur actuelle en utilisant l’analyse 3-sigma de la limite inférieure. Par conséquent dans le cas présenté dans la figure 6, un trafic entrant d’environ 1100 TPS était nécessaire pour calculer avec grande confiance le trafic minimal attendu de chaque serveur d’échange 330 dans le groupe, assurant ainsi que le trafic accepté 900 est limité à une valeur égale à, ou supérieure de peu, à la limite globale de plafonnement de transactions de 1000 TPS. La figure 7 présente un scénario similaire en utilisant la même limite globale de transactions de 1000 TPS, mais avec dix serveurs d’échange 330 dans le groupe, chacun étant configuré pour prendre en charge approximativement 100 TPS, p. ex. G/n= 1000/10=100 TPS. Dans le cas montré dans la figure 7, le retard du plafonnement de trafic entrant total de client 800 serait plus important en raison du nombre de serveurs d’échange, c.-à-d. dix serveurs d’échange 330 au lieu de deux dans la figure 6. Le résultat du volume plus faible de trafic entrant de client géré par chaque serveur d’échange 330 dans le groupe est que le plafonnement serait déclenché lorsque le trafic accepté dépasserait 1300 TPS et il deviendrait plus agressif au fur et à mesure de l’augmentation de trafic entrant de client 800 jusqu’à ce que le trafic accepté 900 converge à la limite globale de plafonnement de transactions de 1000 TPS. Comme on peut le constater, le volume de trafic entrant pris en charge par chaque serveur d’échange 330 dans le groupe pour une limite globale de transactions de clients spécifiée peut avoir un impact sur le volume de trafic entrant requis pour déclencher le processus de plafonnement avec grande confiance. Par conséquent, afin d’augmenter le volume de trafic entrant pris en charge par chaque serveur d’échange 330 dans le groupe, il peut être nécessaire d’ajuster le nombre de serveurs d’échange 330 dans le groupe, p. ex. en diminuant le nombre de serveurs d’échange de sorte que chaque serveur d’échange gère plus de trafic entrant.

Par conséquent, dans chaque cas il peut être important d’identifier le nombre optimal de serveurs d’échange 330 dans le groupe qui produirait les meilleurs résultats. La figure 8 fournit une analyse montrant comment le volume de trafic entrant accepté sur chaque serveur d’échange 330 dans le pire scénario, p. ex. dans lequel le trafic entrant de clients est réparti de façon égale entre les serveurs d’échange, impacte le volume de trafic entrant pour que le trafic accepté soit limité à la limite globale de transactions de client, ce qui nécessite le calcul du trafic minimal attendu, p. ex. en utilisant l’analyse 3-sigma de la limite inférieure comme illustré dans le tableau 1. G/n est le ratio entre la limite globale de plafonnement de transactions « G », p. ex. 1000 TPS et le nombre de serveurs « n » et Af/G est le ratio entre le volume de trafic entrant qui est nécessaire pour que le trafic accepté soit égal à la limite globale « G ». L’analyse indique que pour des valeurs de trafic accepté à chaque serveur d’échange 330 dans le groupe en dessous de 200 TPS, la valeur Af/G augmente exponentiellement, p. ex. pour 130 TPS, Af/G = 1,3 alors que pour 54 TPS, Af/G= 1.5. L’analyse montre par ailleurs que pour des valeurs au-dessus de 200 TPS, le ratio Af/G diminue à un rythme plus lent, p. ex. pour 270 TPS Af/G = 1,2, alors que pour 990 TPS Af/G= 1,1. Comme expliqué précédemment, au fur et à mesure que le volume de trafic entrant reçu à chaque serveur d’échange augmente, plus le calcul de la limite locale de plafonnement de transactions pour chaque serveur gagnerait en précision, p. ex. en utilisant l’analyse 3-sigma de la limite inférieure montrée dans le tableau 1. Cependant après un certain point, p. ex. 200 TPS, les améliorations Af/G ralentiraient considérablement. Par conséquent on peut considérer qu’une valeur de trafic accepté pour chaque serveur d’environ 200 TPS peut offrir les meilleurs résultats.

Sur la base de l’analyse montrée dans la figure 8, le moteur d’affectation de serveur 341 peut être configuré pour grouper des échanges entrants de sorte que chaque serveur d’échange 330 dans le groupe reçoive un volume adéquat de trafic entrant, p. ex. environ de 200 TPS.

En général, les routines exécutées pour mettre en œuvre les modes de réalisation de l’invention, qu’elles soient implémentées dans le cadre d’un système d’exploitation ou d’une application spécifique, d’un composant, d’un programme, d’un objet, d’un module ou d’une séquence d’instructions, ou même un sous-ensemble de ceux-là, peuvent être désignées dans les présentes comme « code de programme informatique » ou simplement « code de programme ». Le code de programme comprend typiquement des instructions lisibles par ordinateur qui résident à divers moments dans des dispositifs divers de mémoire et de stockage dans un ordinateur, et qui lorsqu’il est lu et exécuté par un ou plusieurs processeurs dans un ordinateur, amène cet ordinateur à mettre en œuvre les opérations et/ou des éléments propres aux divers aspects des modes de réalisation de l’invention. Les instructions d’un programme informatique lisibles par ordinateur pour accomplir les opérations des modes de réalisation de l’invention peuvent être, par exemple, le langage d’assemblage ou, soit un code source ou un code objet, écrit en combinaison avec un ou plusieurs langages de programmation.

Le code de programme mis en œuvre dans une/un quelconque des applications/modules décrit(e)s dans les présentes peut être distribué individuellement ou collectivement comme un produit-programme d’ordinateur, sous une variété de formes. En particulier, le code de programme peut-être distribué en utilisant un support de stockage lisible par ordinateur ayant en lui-même des instructions de programme lisibles par ordinateur pour amener un processeur à mettre en œuvre des aspects des modes de réalisation de l’invention.

Les supports de stockage de données lisibles par ordinateur qui sont intrinsèquement non transitoires, peuvent inclure des médias tangibles volatiles et non volatiles, amovibles et non amovibles, implémentés dans tout procédé ou technologie de stockage de données, tels que des instructions de programme lisibles par ordinateur, des structures de donnée, des modules de programme, ou autres données. Les supports de stockage lisibles par ordinateur peuvent par ailleurs inclure la mémoire vive aléatoire (RAM), la mémoire morte à lecture seule (ROM), la mémoire à lecture seule, programmable et effaçable (EPROM), la mémoire à lecture seule, programmable et effaçable électriquement (EEPROM), une mémoire flash, ou toute technologie de support solide de mémoire, disque compact portable doté d’une mémoire à lecture seule (CD-ROM), ou tout autre stockage optique, des cassettes magnétiques, des bandes d’enregistrement magnétiques, des mémoires de disque magnétique ou tout autre médium pouvant être utilisé pour stocker l’information désirée et apte à être déchiffré par un ordinateur. Un support de stockage lisible par ordinateur ne peut être interprété comme étant en soi des signaux transitoires (par exemple, des ondes radio ou toutes autres ondes électromagnétiques se propageant, des ondes électromagnétiques se propageant à travers un support de transmission telle qu’un guide d’ondes, ou des signaux électriques transmis par câble). Les instructions de programme lisibles par ordinateur peuvent être téléchargées sur un ordinateur, un autre type d’appareil de traitement de données programmable ou sur tout autre dispositif de support de stockage lisible par machine, ou vers un ordinateur externe ou vers un dispositif de stockage externe via un réseau.

Les instructions de programme lisibles par ordinateur, stockées sur un support lisible par ordinateur, peuvent être utilisées pour instruire un ordinateur, d’autres types d’appareils programmables de traitement ou d’autres dispositifs pour fonctionner d’une façon particulière, de sorte que les instructions stockées sur un support lisible par ordinateur produisent un article de fabrication comprenant les instructions qui implémentent les fonctions/actions spécifiées dans les organigrammes, diagrammes de séquence, et/ou diagrammes blocs. Les instructions de programme informatique peuvent être fournies à un ou plusieurs processeurs d’un ordinateur à usage général, un ordinateur dédié ou un autre appareil programmable de traitement de données pour produire une machine, de sorte que les instructions, lorsqu’elles sont exécutées via un ou plusieurs processeurs, accomplissent une série de calculs pour mettre en œuvre les fonctions, actions, et/ou les actions spécifiées dans les organigrammes, diagrammes séquentiels et/ou diagrammes blocs.

Dans certains autres modes de réalisation, les fonctions, les actions et/ou des opérations spécifiées dans les organigrammes, diagrammes de séquence, et/ou des diagrammes blocs peuvent être réorganisées à nouveau, traitées en série et/ou traitées en même temps conformément aux modes de réalisation de l’invention. De plus, un quelconque des organigrammes, diagrammes séquentiels, et/ou diagrammes bloc peut inclure plus ou moins de blocs que ceux qui sont illustrés conformément à des modes de réalisation de l’invention.

La terminologie utilisée dans les présentes a pour but de décrire uniquement des modes de réalisation particuliers et n’est pas destinée à limiter les modes de réalisation de l’invention. On comprendra par ailleurs que les termes « comprendre », « comprend » et/ou « comprenant », lorsqu’ils sont utilisés dans cette spécification, précisent la présence de caractéristiques, de nombres entiers, d’étapes, d’opérations, d’éléments, et/ou de composants, mais n’excluent pas la présence ou l’ajout d’une ou de plusieurs caractéristiques, de nombres entiers, d’étapes, d’éléments, de composants et/ou de groupes, en cela. De plus, dans la mesure où les termes « inclut », « ayant », « a », « avec » « compris de » ou des variantes de ceux-ci, sont utilisés dans la description détaillée des revendications, ces termes sont censés être inclusifs de façon similaire au terme « comprendre ».

Bien que l’invention ait été illustrée par une description de modes de réalisation divers et bien que ces modes de réalisation aient été décrits de façon considérablement détaillée, les demandeurs n’ont pas l’intention de restreindre ou de limiter en aucune façon le champ d’application à ces détails. Des avantages supplémentaires et des modifications possibles apparaîtront aisément aux hommes de métier. L’invention sous ses aspects plus larges n’est donc pas limitée aux détails spécifiques, aux appareils représentatifs et aux procédés, ainsi qu’aux exemples illustratifs montrés et décrits. Par conséquent, il est possible de s’éloigner de ces détails sans s’éloigner de la portée du concept inventif général des demandeurs.

Claims

Un procédé pour plafonner un rythme de transactions entrantes dans des échanges avec état entrants établis entre un client et une pluralité de serveurs d’échange d’un intégrateur de services, chaque serveur d’échange étant configuré pour mapper au moins un échange avec état entrant sur au moins un échange avec état sortant, lequel est établi entre les serveurs d’échange et au moins un serveur d’applications, le procédé comprenant :
l’affectation, au moyen d’un moteur d’affection de serveur, d’un groupe de serveurs d’échange pour gérer les échanges avec état entrants établis par le client, le groupe de serveurs d’échange étant sélectionné à partir de la pluralité des serveurs d’échange ; et
pour chaque serveur d’échange sélectionné dans le groupe
la détermination au moyen d’un moteur de veille d’une valeur locale de trafic entrant associée au rythme des transactions entrantes prises en charge par le serveur d’échange sélectionné ;
la diffusion au moyen d’un moteur de diffusion d’une valeur locale de trafic à chacun des autres serveurs d’échange sélectionnés dans le groupe, la valeur locale de trafic étant calculée sur la base de la valeur locale de trafic entrant du serveur d’échange sélectionné ;
le calcul par un moteur de calcul de limite d’une limite locale de plafonnement de transactions, basée sur une limite globale de plafonnement de transactions de client et les valeurs locales de trafic diffusées reçues des autres serveurs d’échange sélectionnés dans le groupe, en définissant le volume maximum de transactions entrantes devant être prises en charge par le serveur d’échange sélectionné ; et
le plafonnement, au moyen d’un moteur de plafonnement de transactions, du rythme de transactions entrantes lorsque la limite locale de plafonnement de transactions a été dépassée.
Le procédé de la revendication 1, dans lequel la valeur locale de trafic définit une valeur minimum de trafic entrant attendu calculée à partir de la valeur locale de trafic entrant.
Le procédé selon la revendication 2, dans lequel l’étape de calcul d’une limite locale de plafonnement de transactions sur un serveur d’échange donné « s » comprend :
le calcul d’une première valeur représentant une première limite locale de plafonnement de transactions obtenue à partir de [Math. 7] ;
le calcul d’une deuxième valeur représentant une deuxième limite locale de plafonnement de transactions obtenue deG – (L – ls) ;
et
la sélection de la plus élevée de la première et deuxième valeur comme limite locale de plafonnement de transactions ;
où, pour le client :
lsreprésente pour le serveur « s » la valeur locale minimale attendue de trafic entrant, [Math. 8]
, represente la somme de trafic minimal attendu sur tous les serveurs d’échange dans le groupe,
G= la limite globale de plafonnement de transactions de clients.
Le procédé selon la revendication 2 ou 3, dans lequel la valeur minimale de trafic entrant attendue est calculée à partir d’une analyse 3-sigma de la limite inférieure de la valeur de trafic entrant de chaque serveur d’échange dans le groupe.
Le procédé selon l’une quelconque des revendications précédentes, dans lequel l’étape de calcul de la limite locale de plafonnement de transactions est déclenchée de façon dynamique lors de la réception d’une nouvelle valeur locale de trafic provenant d’au moins un autre serveur d’échange dans le groupe.
Le procédé selon l’une quelconque des revendications précédentes, dans lequel l’étape de calcul de la limite locale de plafonnement de transactions est déclenchée de façon dynamique lors de la réception d’une notification concernant un changement d’état d’un serveur d’échange.
Le procédé selon l’une quelconque des revendications précédentes, dans lequel la valeur locale de trafic de chaque serveur d’échange sélectionné est diffusée périodiquement à chacun des autres serveurs d’échange dans le groupe.
Le procédé selon l’une quelconques des revendications précédentes, dans lequel la somme des limites locales de plafonnement de transactions sur tous les serveurs d’échange dans le groupe est égale ou supérieure à la limite globale de transactions de client.
Le procédé selon l’une quelconque des revendications précédentes, dans lequel l’étape de plafonnement du rythme de transactions comprend de vérifier si la limite locale de plafonnement de chaque serveur d’échange dans le groupe a été atteinte afin de déterminer si une transaction de client peut être traitée par les serveurs d’échange dans le groupe.
Le procédé selon la revendication 9, dans lequel l’étape de plafonnement du rythme de transactions entrantes est effectuée en utilisant un algorithme de corbeille de jetons.
Le procédé selon l’une quelconque des revendications précédentes, dans lequel l’étape d’affection d’un groupe de serveurs d’échange pour gérer les échanges avec état entrant établis par le client comprend :
l’établissement, pour chaque échange avec état entrant, d’au moins une connexion entre le client et une pluralité de multiplexeurs de l’intégrateur de service ;
la sélection, au moyen de la pluralité des multiplexeurs, d’un groupe de serveurs d’échange de la pluralité des serveurs d’échange pour gérer les transactions entrantes de tous les échanges avec état entrants établis par le client ; et
la distribution par une pluralité de multiplexeurs, de chaque échange avec état entrant correspondant à des serveurs d’échange sélectionnés dans le groupe.
Le procédé de la revendication 11, dans lequel l’étape d’établissement d’au moins une connexion pour chaque échange avec état entrant comprend :
la réception des connexions par un module d’équilibrage de charge interposé entre le client et l’intégrateur de services, et
l’affectation desdites connexions à la pluralité des multiplexeurs de sorte que la charge est également répartie.
Le procédé de la revendication 11 ou 12, dans lequel l’étape de sélection d’un groupe de serveurs d’échange comprend une étape de détermination, basée sur au moins la limite globale de transactions de client, le nombre de serveurs d’échange requis pour prendre en charge les échanges avec état entrants établis par le client.
Le procédé selon la revendication 13, dans lequel le nombre de serveurs d’échange dans le groupe est ajusté de façon dynamique en utilisant un algorithme hash-ring basé sur des changements de la valeur locale de trafic de chaque serveur d’échange.
Un procédé pour plafonner un rythme de transactions entrantes dans des échanges avec état entrants établis entre un client et une pluralité de serveurs d’échange d’un intégrateur de services, chaque serveur d’échange étant configuré pour mapper au moins un échange avec état entrant sur au moins un échange avec état sortant, lequel est établi entre les serveurs d’échange et au moins un serveur d’applications, le procédé comprenant :
un moteur d’affection de serveur configuré pour affecter un groupe de serveurs d’échange pour prendre en charge les échanges avec état entrants établis par le client, le groupe de serveurs d’échange étant sélectionné à partir de la pluralité des serveurs d’échange ; et pour chaque serveur d’échange sélectionné dans le groupe
un moteur de veille configuré pour déterminer une valeur locale de trafic entrant associée au rythme des transactions entrantes prises en charge par le serveur d’échange sélectionné ;
un moteur de diffusion configuré pour diffuser une valeur locale de trafic à chacun des autres serveurs d’échange sélectionnés dans le groupe, la valeur locale de trafic étant calculée sur la base de la valeur locale de trafic entrant du serveur d’échange sélectionné ;
le calcul, par un moteur de calcul de limite, d’une limite locale de plafonnement de transactions basée sur une limite globale de plafonnement de transactions de client et les valeurs locales de trafic diffusées reçues des autres serveurs d’échange sélectionnés, en définissant le volume maximum de transactions entrantes devant être pris en charge par le serveur d’échange sélectionné ; et
un moteur de plafonnement de transactions configuré pour limiter le rythme de transactions entrantes lorsque la limite locale de plafonnement de transactions a été dépassée.