• Aucun résultat trouvé

Nous présentons ici les principes du modèle permettant de capturer le comportement des

services multi-étagés soumis à des charges variables. Le modèle est basé sur la théorie des

files d’attente. Nous choisissons de modéliser le service comme un réseau de files d’attente.

En effet, ce type de modélisation permet de capturer de manière précise les phénomènes de

contention pouvant apparaître sur les différents serveurs composant le système multi-étagé.

Les bases théoriques des modèles à file d’attente ont été définies dans les années 1980 [47,18].

5.2.1 Files d’attente

Une file d’attente représente à la fois une ressource critique en terme de performance,

ainsi que la file de requêtes en attente pour accéder à cette ressource [38]. Il existe plusieurs

façon d’ordonnancer les requêtes à l’intérieur de la file. Les files les plus courantes sont les

files FIFO, pourfirst in, first out(premier entré, premier sorti). Dans ce type de file, chaque

re-quête est assurée d’être traitée après la rere-quête qui la précède dans la file, et avant la rere-quête

qui la suit dans cette même file. Nous considérons par la suite les files d’attente comme étant

des files FIFO, comme c’est le cas dans la plupart des serveurs composant les services

Inter-net. A chaque file d’attente et à chaque type de charge est associée untemps de service. Ce

temps correspond au temps moyen incompressible nécessaire au traitement d’une requête

de ce type de charge par la ressource critique (c-à-d le serveur). Dans notre cadre applicatif,

le temps de service sur les ressources est indépendant de la quantité de charge. En effet, le

temps de traitement reste constant même si la latence augmente. Cette augmentation de

la-tence est due au temps passé en attente de traitement dans la file, et non à la modification

du temps de service.

Le choix du niveau de granularité pour les ressources représentées par les files d’attente

influence la précision du modèle, mais aussi sa facilité d’utilisation. Une granularité fine

permet d’obtenir un modèle avec une vue plus riche du système. Son utilisation est

cepen-dant rendue difficile par le nombre plus important de paramètres du modèle, ces derniers

dépendant entre autres du nombre de files d’attente dans le système. Inversement, une

gra-nularité importante permet une utilisation plus facile du modèle en limitant la complexité

du paramétrage de ce dernier. Le modèle peut cependant perdre en précision dans certains

cas. Dans notre cadre applicatif, nous modélisons chaque serveur par une file d’attente.

5.2.2 Files d’attente pour services multi-étagés dupliqués

FIGURE5.2 – Réseau ouvert de files d’attente

FIGURE5.3 – Réseau fermé de files d’attente

Un service multi-étagé dupliqué est modélisé par un réseau de files d’attente. Les réseaux

de files d’attente sont divisés en deux catégories, les réseaux ouverts (boucles ouvertes) et les

réseaux fermés (boucles fermées). Dans lesréseaux ouverts, les requêtes sont envoyées vers le

système indépendamment de la vitesse de traitement de ce dernier. Les clients n’attendent

donc pas la réponse à leur requête pour envoyer une nouvelle requête. La figure5.2présente

un exemple de réseau ouvert. Dans lesréseaux fermés, les clients attendent la réponse à leur

requête avant d’en envoyer une autre. Nous supposons que toute requête admise dans le

service sera traitée sans erreur, quel que soit le niveau de qualité de service fourni par le

service. Les éventuelles erreurs applicatives pouvant résulter d’une surcharge du service

Internet ne font pas l’objet de cette étude. Dans les réseaux fermés, les clients marquent

un temps de réflexion entre la réception d’une réponse et l’émission de la requête suivante

(temps d’attente, outhink time). Dans les réseaux fermés, les clients sont donc vus comme

un délai supplémentaire dans la boucle de traitement. La figure 5.3 présente un exemple

de réseau fermé. Dans le cadre des services Internet, la modélisation se base sur un réseau

fermé de files d’attente. En effet, dans les applications considérées les clients attendent la

réponse à une requête avant d’en émettre une suivante. La figure5.4 présente un exemple

de modélisation de service Internet multi-étagé dupliqué.

FIGURE5.4 – Modélisation d’une application multi-étagée

La figure5.5présente un exemple de service Internet à 3 étages ayant une configuration

κ(3, AC < 1,1,2 >, LC < 20,15,3 >), une quantité de charge de 30 clients et un type de

charge caractérisé entre autres par des ratios de visiteV < 1,0.5,2 >. Cet exemple illustre

le comportement des 30 requêtes clients tentant d’accéder aux différents étages et files

d’at-tente. Ainsi, parmis lesN t1 = 30 clients tentant d’accéder à l’étageT1,N r1 = 10sont

re-jetés à cause de la configuration locale (c’est-à-dire le contrôle d’admission) sur cet étage et

N a

1

= 20 clients sont admis sur le serveur deT

1

. Ensuite, les 20 requêtes clients traitées

parT1 génèrentN t2 = 10sous-requêtes vers l’étageT2 (du fait du ratio de visiteV2 = 0.5).

L’ensemble des 10 requêtes sont admises sur le serveur deT

2

, car ce nombre est inférieur à

la configuration locale deT

2

(N a2 = 10). Enfin, les 10 requêtes surT

2

induisent au total

40 requêtes surT3 (avec un ratio de visiteV3 = 2). Cependant, à cause de la

communica-tion synchrone entre les étages d’un service Internet, une requête surT

2

induit à un instant

donné au plus une requête versT

3

, et en moyenne 4 requêtes successives vers T

3

. Parmis

ces 10 requêtes,N r3 = 4requêtes sont rejetées par la configuration locale deT3, etN a3 = 6

requêtes sont admises et réparties sur les deux serveurs composant cet étage. En résumé, sur

les 30 requêtes client tentant d’accéder au service multi-étagé, un total de 14 sont rejetées et

16 sont traitées, ce qui donne un taux de rejet de 47%.

Na1= 20 Nr1= 10 Nt1= 30 Na2= 10 Nr2= 0 Nr3= 4 Nt3= 10 Nt2= 10 AC3= 2; LC3= 3 V3= 2 AC2= 1; LC2= 15 V2= 0.5 AC1= 1; LC1= 20 V1= 1

Tier T

1

Tier T

2

Tier T

3

Na3= 6

FIGURE5.5 – Modélisation d’une application multi-étagée - prise en compte de la

5.3 Algorithme de prédiction de performance, de disponibilité et