Ce premier groupe de tests a été mené afin d’investiguer le coût des phases de composition virtuelle et de mapping physique, qui composent le processus de compilation des politiques virtuelles. Le tableau3donne un premier aperçu sur les résultats d’exécution de différents cas d’étude et où chacun d’entre eux implémente une fonctionnalité spécifique d’AirNet. Notez que la figure60illustre la topologie physique sur laquelle tous les cas d’étude du tableau3ont été testés, et qui sont les suivants :
• twoFab : cas d’étude simple qui intègre deux fabrics et qui n’utilise aucune fonction réseau.
Chapitre 7 : Mesures de performances S2 S3 S7 S5 S6 S4 S8 S9 S11 S10 S1 H3: 10.13.0.13 H4: 10.14.0.14 H3: 10.11.0.11 H4: 10.12.0.12 VM Click: 10.15.0.15
FIGURE60. Topologie physique pour les tests de performances TABLE3. Nombre de politiques et de règles pour chaque cas d’étude
Use case Virtual Physical Composition Physical
policies rules generated time (ms) mapping time (ms)
twoFab 12 42 101 20
dynLB 9 31 94 16
bwCap 6 27 89 11
dataFct (control plane) 6 25 95 14
dataFct (data plane) 6 26 99 13
• dynLB : cas d’étude de répartition de charge qui utilise une fonction de contrôle dynamique pour remonter le premier paquet de chaque flux.
• bwCap : cas d’étude qui surveille le débit maximum des hôtes d’un réseau, notamment en utilisant une fonction de contrôle dynamique qui remonte des statistiques pour ses prises de décision.
• dataFct (control plane) : cas d’étude qui définit un chemin de données qui passe par une fonction data qui est exécutée au niveau du plan de contrôle (sur l’hyperviseur). • dataFct (data plane) : cas d’étude qui définit un chemin de données qui passe par une
fonction data qui est exécutée au niveau du plan de données à travers l’utilisation d’un routeur programmable Click.
A partir des résultats obtenus et listés dans le tableau3, nous pouvons confirmer que le nombre de règles OpenFlow généré par l’hyperviseur est fortement dépendant du nombre de politiques virtuelles d’un programme de contrôle. En effet, chaque politique virtuelle est transformée en une ou plusieurs règles physiques. Ainsi, plus un programme de contrôle contient des politiques de haut niveau, plus l’hyperviseur générera de règles OpenFlow. Par exemple pour le cas d’étude twoFab, qui inclut 12 politiques, l’hyperviseur a généré 42 règles physiques, alors que pour le cas d’étude dynLB qui lui n’inclut que 9 politiques, l’hyperviseur n’a généré que 31 règles physiques, sachant que ces deux cas d’étude ont été exécutés sur la même topologie physique.
6 v.pol
(27 rules) (39 rules)11 v.pol (62 rules)20 v.pol (85 rules)29 v.pol (108 rules)38 v.pol 0
50 100 150
Time (ms)
Same physical topology with different virtual policies
Virtual composition time Physical mapping time
FIGURE61. Temps de compilation en fonction du nombre de politiques
permet d’avoir une première indication quant au coût de ces deux phases de compilation. En effet, nous pouvons constater que pour tous les cas d’étude, ces temps restent largement acceptables et se mesurent en centaines de millisecondes. Néanmoins, pour avoir des statistiques plus précises qui renseignent sur les facteurs qui impactent le plus ces deux phases de compilation, nous avons effectué les tests suivants :
• Impact du nombre de politiques virtuelles (figure 61) : nous exécutons plusieurs cas d’utilisation sur la même topologie physique. Ces cas d’utilisation incluent des politiques de contrôle statiques, mais en nombres différents.
• Impact de la taille de l’infrastructure physique (figure62) : nous exécutons le même cas d’utilisation sur plusieurs topologies physiques de tailles différentes.
7.2.1 Impact du nombre de politiques virtuelles
La figure 61 affiche l’histogramme qui représente les temps de compilation (axe des ordonnées) par rapport au nombre de politiques virtuelles (axe des abscisses). Dans cet histogramme, la classe bleue représente le temps de la phase composition virtuelle, alors que la classe rouge représente le temps de la phase de mapping physique.
Ainsi, nous pouvons constater que le nombre de politiques virtuelles a effectivement un impact direct sur les deux phases de compilation. Concernant la phase de composition virtuelle, les résultats obtenus sont prévisibles, étant donné que plus un programme de contrôle contient de politiques virtuelles, plus l’hyperviseur aura besoin d’effectuer des compositions entre ces dernières afin de résoudre les problèmes d’intersection (cf. section
5.4).
D’autre part, comme cela a été présenté dans la section5.7.1.2, pour installer les règles des fabrics, l’hyperviseur a besoin d’effectuer des intersections entre les règles ingress et les règles egress, puis de calculer des chemins à travers les commutateurs de chaque fabric. Ainsi, plus un programme de contrôle contient de politiques, plus l’hyperviseur aura besoin d’effectuer des intersections, de calculer des chemins et d’installer des règles OpenFlow sur les commutateurs physiques (nombre de règles indiqué entre parenthèse sur l’axe des abscisses), menant ainsi à des temps de mapping physique plus importants.
Chapitre 7 : Mesures de performances
7.2.2 Impact de la taille de l’infrastructure physique
Les résultats d’exécution du deuxième groupe de tests sont montrés à la figure62. Avec cet histogramme nous investiguons l’impact de la taille de la topologie physique (axe des abscisses) sur les temps de compilation (axe des ordonnées). Au contraire du nombre de politiques virtuelles, nous pouvons constater que la phase de composition virtuelle (classe bleue) est complètement indépendante de la taille et de la complexité de l’infrastructure physique. En effet, lors de l’exécution de cette phase, aucun traitement n’est dépendant des informations qui proviennent de l’infrastructure physique. Ainsi, nous pouvons clairement voir que le coût de la phase de composition virtuelle reste stable à 100 millisecondes malgré l’évolution conséquente du nombre de commutateurs de l’infrastructure physique qui est passé de 7 à 127 commutateurs.
À l’inverse, les résultats qui concernent la phase de mapping physique (classe rouge) montrent que la taille de l’infrastructure physique a un impact important. En effet, plus la topologie physique est grande et complexe, plus l’hyperviseur aura besoin de parcourir de chemins afin d’en trouver les plus courts, puis d’installer les règles OpenFlow sur tous les commutateurs des chemins selectionnés (pour 127 commutateurs, l’hyperviseur a installé 347 règles OpenFlow), menant inexorablement à des temps de mapping physique plus importants.
Par ailleurs, il est important de souligner le fait que l’indépendance de la phase de composition virtuelle vis-à-vis de l’infrastructure physique est particulièrement intéressante pendant la phase d’exécution réactive (fonctions de contrôle dynamiques ou mise à jour de l’infrastructure physique). En effet, dans ce cas, l’hyperviseur n’a pas besoin de réexécuter la phase de composition virtuelle, mais réutilise ses résultats et réexecute uniquement la phase de mapping physique.
7 sw
(31 rules) (45 rules)15 sw (99 rules)31 sw (183 rules)63 sw (347 rules)127 sw
0 50 100 150 200 250
Same use case with different physical topologies
Virtual composition time Physical mapping time
FIGURE62. Temps de compilation en fonction du nombre de commutateurs physiques