Combinaison du parallélisme et TCP buffer

Les performances du Gridftp

Les conditions des tests de performances

Les études de performances se sont déroulées dans les conditions suivantes :
• utilisation des machines poste1.ucad.sn et poste2.ucad.sn de la grille mise en place avec Globus,
• ces deux machines sont aussi configurées comme étant des serveurs FTP (version wu-ftpd car c’est la version qui a permis d’implémenter Gridftp),
• utilisation de fichiers de taille variant de 100Mo à 450Mo (logiciel Split File Pro v 2.2 pour découper les fichiers),
• le temps de transfert est obtenu grâce à l’option de performance –vb. Avec cette option nous avons toutes les 5 secondes la taille de fichier transféré, le débit instantané, le débit moyen et le temps de transfert.

Gridftp vs ftp

Il s’agit de faire une étude comparative entre Gridftp et ftp.

Interprétation

Les protocoles Gridftp et FTP utilisent le mode de transfert bloc dans le cas de ce test.
Avec le protocole Gridftp les données sont envoyées par blocs de taille égale à 64Ko (dans le cas précis de ce test). De même, le protocole FTP utilise une taille de bloc égale à 64Ko. Ailleurs, les protocoles utilisent tous les deux le protocole TCP pour le transport des données. La taille du buffer d’émission et de réception est de 104Ko dans le cas du Gridftp et de 64Ko dans le cas de FTP.
Donc, le nombre de paquets transmis par seconde par TCP dans le cas du Gridftp est supérieur à celui transmis dans le cas de ftp. Par conséquent, le temps de transfert des données Gridftp est plus petit que celui du transfert des données ftp.

Impact du parallélisme sur le transfert

On voit bien que les meilleures performances sont obtenues pour un nombre de canaux compris entre 4 et 8. Ceci s’explique par le fait qu’entre 4 et 8 canaux il n’y a pas beaucoup d’échecs d’émission et que le débit dans les canaux ouverts est suffisant pour acheminer les données.
Par contre, au delà de 8 canaux on note une dégradation des performances et aussi des bouleversements. Il faut noter que la bande passante théorique utilisée pour le transfert est divisée par le nombre de canaux ouverts. Par conséquent, le débit utilisé devient plus faible favorisant. En le temps de retransmission des paquets TCP est fortement lié au RTT (Round Trip Time est le temps par un paquet pour faire un aller-retour) qui est petit (RTT inférieur à 1ms). Par conséquent, le RTO (Retransmission Time Out est le temps de retransmission des paquets TCP) est aussi petit d’où les retransmissions évoquées un peu plus haut.

Pourquoi Gridftp découpe les blocs de données supérieures a 64Ko ?

En réalité, au delà de 64Ko les blocs de données sont envoyés sous forme d’enregistrement de taille égale à 64Ko. Ceci est un bug du protocole Gridftp. Il est à l’image de Globus donc en phase de développement et par conséquent le paramétrage des blocs Gridftp n’est pas encore effectif dans son développement.
Pour un RTT très petit le paramétrage de la taille des blocs n’a pas beaucoup d’effet sur les performances du transfert des fichiers avec Gridftp.

Impact de la taille des buffers TCP

Interprétation

Plus la taille des buffers est grande alors plus le nombre de paquets transmis par seconde par le protocole TCP est grand et plus le temps mis pour transférer les fichiers est petit. Au-delà d’une certaine taille (104 Ko), le temps de transfert reste constant.
En effet, il a été trouvé que la meilleure taille de buffer est obtenue en appliquant la formule : Taille buffer= (Bande passante×RTT×1000) ÷8. Cependant, cette taille doit être supérieure ou égale à la taille du buffer par défaut (104Ko) sinon le système va considérer la taille par défaut. Dans le cas de notre test, la bande passante maximale =100 Mbps, RTT=0,317s d’où la taille de bloc optimale est 3963 octets. Donc, le système va considérer la taille par défaut d’où au delà de 104Ko le temps de transfert n’évolue pas.
Le paramétrage des buffers TCP n’a pas beaucoup d’influence sur les performances du Gridftp dans le cas où le RTT est faible.

Impact de la combinaison sur les performances

Parallélisme et blocs

Dans ce test nous avons fait varier la taille des blocs en fixant le nombre de canaux égal à 4.

Proposition d’optimisation du temps de transfert des fichiers

Dans la partie précédente, nous avons fait une étude de performance du Gridftp et nous avons pu dégager les apports en performances de différentes extensions. Cependant, nous avons noté que ces performances peuvent être dégradantes si celles-ci ne sont pas bien choisies. Dans cette partie, nous nous proposons donc d’apporter des solutions pour améliorer les performances du protocole.

Les problèmes du Gridftp

Parmi ces limites du protocole Gridftp, nous pouvons citer : le paramétrage des blocs, l’intégrité des données et le transfert séquentiel des fichiers.

Le paramétrage des blocs

Le protocole Gridftp ne permet pas d’envoyer des blocs de taille supérieure à 64Ko.
Donc, au-delà de 64Ko, tout bloc est envoyé sous forme de plusieurs blocs de 64Ko.

L’intégrité des données

L’intégrité des données n’est pas assurée au niveau du canal de données. Ainsi, les données peuvent être victimes de modification sans aucune possibilité de faire des vérifications.

Le transfert séquentiel

Avec le protocole Gridftp, il n’est pas possible de transférer plusieurs blocs de plusieurs fichiers sur un même canal de données de façon séquentielle.
Dans la suite de notre étude, nous nous focaliserons sur le troisième point cité c’est-àdire le transfert séquentiel afin d’apporter des améliorations sur le Gridftp.

Notre démarche

La démarche que nous comptons adopter dans cette étude repose sur les principaux points suivants : exploitation de la structure enregistrement, identification des enregistrements et automatisation des transferts.

Exploitation de la structure enregistrement

Gridftp peut envoyer les données sous forme d’enregistrements suivis de EOR (End Of Record). Hors le délai d’attente du Gridftp est du au fait que Gridftp envoie les fichiers les uns à la suite des autres en faisant une distinction entre eux. Donc, un moyen d’éviter ce délai est de faire en sorte que Gridftp considère les fichiers comme des enregistrements. Le choix porté sur la structure enregistrement s’explique par le fait que dans le protocole Gridftp cette structure est la mieux adaptée pour envoyer les données à travers plusieurs canaux. Donc, dans notre proposition nous allons considérer que tout fichier est un enregistrement suivi d’un EOR.

Identification des enregistrements

Le deuxième point à considérer est l’identification de ces enregistrements. De ce fait, on pourra reconnaître les fichiers lors de leur transfert mais aussi à leur réception. Ceci éviterait ainsi d’avoir des fichiers altérés ou illisibles à l’arrivée. L’idée serait donc de déclarer des identifiants d’enregistrement.

Automatisation des transferts

Une fois les identifiants des blocs définis il serait donc intéressant de voir comment les automatiser lors des transferts. En d’autres termes, il s’agit d’allouer les identifiants de blocs aux fichiers de façon automatique. Ceci évitera une gestion manuelle des identifiants de bloc.

Les paramètres

Les paramètres á tenir en considération dans notre proposition sont les suivantes : une file, un buffer, un compteur et un délai d’attente, un serveur de stockage.

Une file

Nous considérons que tous les fichiers candidats sont mis dans une file avant d’être acheminés vers les canaux. La file permettra de stocker les données sous forme d’enregistrement. Gridftp peut acheminer des données allant des centaines de Mégabits á des centaines de péta bits suivant les caractéristiques des réseaux. Dans le cas de notre mémoire, nous supposons que la taille maximale des données est de 2,5 gigabits correspondant à la taille maximale de la file. Il faut noter que 2,5 gigabits est la taille maximale des données utilisées dans le cadre de nos tests de performance.
Ainsi, pour rester dans le cadre de notre environnement de test nous travaillons toujours avec ces mêmes fichiers.

Un GASS(Globus Access to Secondary Storage)

Le GASS un serveur cache de Globus qui permet de stocker de façon temporaire les données devant être traitées et transférées. Nous supposons que dans notre proposition que le serveur GASS à une taille fixe égale à la taille de la file. Ce choix sur la taille du GASS s’explique par le fait que nous voulons toujours rester dans notre environnement de test.

Un buffer

Chaque fichier doit être stocké avec un EOF lors de sa réception par le système de stockage récepteur. Donc, le buffer permettra de stocker les EOF (blocs nuls) de chaque fichier (enregistrement) transféré. Il faut remarquer que même si le fichier est envoyé sous forme d’enregistrement avec un EOR à l’arrivée il doit être stocke avec un EOF. La taille maximale du buffer est égale à la taille d’un buffer d’émission multiplié par le nombre de buffer (nombre de canaux).Le buffer sera déclarée au niveau du GASS.
Taille buffer=nombre de canaux * taille d’un buffer d’émission.
Ainsi, lors de l’envoi des blocs nuls Gridftp pourra alors partager les blocs entre les différents buffers d’émission de façon très équitable (sans déficit ni excès).

Un compteur

L’idée du compteur est de contenir les valeurs des identifiants. Ce compteur sera incrémenté au fur et à mesure que les fichiers candidats arrivent et sa valeur sera affectée aux identifiants. Donc, à chaque fois qu’il y’a un fichier candidat Gridftp va lire la valeur du compteur et lui affecter l’identifiant de l’enregistrement avant de l’envoyer à TCP.