DNSSEC: Evaluation de performances

De Ensiwiki
Aller à : navigation, rechercher
DNSSEC: Problèmes de performance et ponts vers d'autres protocoles
Projet Projet de spécialité 2A
Sous-projet Communication et Réseaux
Étudiants Quentin LUC, Cyril LUPO, Thê-Minh TRINH
Promo 2012
Tuteur Martin Heusse (LIG)
Accueil projet: DNSSEC: Problèmes de performances et ponts vers d’autres protocoles

Les machines virtuelles se sont révélées très pratiques pour travailler tout seul et donc de paralléliser les tâches. Cependant, utiliser des machines virtuelles pour l'évaluation de performances, c'est prendre le risque de faire des mesures faussées (les processus de la machine hôte sollicitent eux aussi le processeur !). Cependant, si on a un processeur à deux cœurs et qu'on n'a attribué qu'un seul cœur pour chaque machine virtuelle, on peut simuler les communications entre un client et un serveur sans trop fausser les mesures (à condition d'avoir le moins de processus en cours sur la machine hôte).


Premiers pas

Nous avons passé beaucoup de temps à essayer de surcharger le serveur. Au départ, nous souhaitions utiliser les mêmes logiciels que ceux utilisés dans ce document : dnsperf, resperf et collectl. Faute d'avoir réussi à installer les deux premiers, nous avons écrit des scripts pour envoyer un maximum de requêtes au serveur. On observe le nombre max de requêtes par seconde (qps : queries per second) et la charge cpu du serveur grâce à collectl. Le nombre max de requêtes par seconde est donné à titre indicatif, susceptible de fortement changer selon les ordinateurs.

Voici la première architecture utilisée :

Architecure basique.png

  • Depuis un client, on lance un script faisant 10000 dig : 1800 qps et charge cpu max de 28%
  • On lance plusieurs fois le script : 2600 qps et charge cpu max de 40%
  • On ajoute un deuxième client et on lance plusieurs fois le script : 3000 qps et charge cpu max de 50%

Il semble étonnant que dans le premier cas, il y ait déjà saturation en terme de qps sans qu'aucun des cpu ne sature. Dans le deuxième cas, on constate que c'est le client qui sature (charge cpu du client à 100% !) : dig doit être très gourmand. Dans le dernier cas, on a trois machines virtuelles pour deux cœurs… ce n'est pas l'idéal !

Nous avons ensuite songé à utiliser deux ordinateurs, chacun avec une machine virtuelle. Les deux étaient de puissances comparables. Nous les avons connectés en ethernet et reproduit le second test : 300 qps. Pas concluant du tout ! La raison de cette diminution drastique du nombre de requêtes par secondes est sûrement à chercher du côté des limitations introduites par l'interaction entre la machine hôte et la machine virtuelle.

Heureusement, nous avons réalisé que Bind était livré avec queryperf. Apparemment, dnsperf et resperf seraient plus évolués, mais ça l'est sûrement plus que de simples scripts !

queryperf -s serveur -d fichier [-D pour DNSSEC]

Avec fichier contenant des enregistrements du type :

papa.projet A
serv.projet NS
mail.projet MX

Grâce à ce logiciel, on arrive à atteindre 7000 qps max et cette fois-ci, c'est le serveur qui sature le premier. Gardons bien entendu en tête que la puissance d'un serveur n'est pas du tout comparable à celle d'un ordinateur.

Introduction d'un serveur récursif

ArchitectureDNS 3machines.png

Cette fois-ci, nous avons introduit un serveur récursif entre le client et le serveur. Celui-ci est typiquement géré par le FAI (fournisseur d'accès à internet).

La prochaine étape pour l'évaluation de performances est de mettre en place un architecture à plusieurs ordinateurs, sans recours aux machines virtuelles, afin de se rapprocher de la réalité. Ainsi, on pourra faire des mesures plus intéressantes surtout sur les mesures de temps de réponse, bien que l'on reste assez loin des contraintes imposées par le vrai internet.

Pour ce faire, il faut impérativement vider le cache sur le serveur récursif, sinon on ne fait pas entrer en jeu le serveur autoritaire. En lançant collectl sur les deux serveurs et queryperf sur le client, on met en évidence la charge importante du serveur récursif.

Annexe : installations

collectl

Pour être honnête, je n'ai pas réussi à compiler les sources téléchargeables sur le site officiel de collectl. J'ai trouvé un paquet pour Debian et utilisé dpkg.

queryperf

Ce logiciel est fourni avec les sources de Bind, dans le dossier contrib/queryperf. D'après le README, il suffit de faire :

sh configure
make

Il se peut qu'il vous manque gcc et make. Un aptitude install <nom_du_logiciel> fera l'affaire. Il faut finir par :

cp queryperf /usr/local/sbin