La plupart des transferts de données entre les machines de l'Observatoire se font au travers du système de fichiers NFS [3]. Nous avons testé d'autres systèmes, notamment DFS et PIOUS.
Au niveau de notre première expérience de configuration,
DCE/DFS (version 1.3 IBM) [2] nous a paru être
un environnement assez lourd au niveau administration système.
La version actuelle est limitative sur des réseaux de stations comportant
plusieurs interfaces; dans notre cas, l'installation sur le
réseau FDDI qui était défini comme un réseau indépendant dédié
aux partages de données entre nos sites pour le calcul intensif, s'est
avérée difficile et contraignante. Ces limitations sont directement liées
aux aspects sécurité, particulièrement approfondis dans DCE.
Le système de fichiers DFS semble pour sa part très intéressant. NFS et DFS fournissent tous deux des mécanismes de ``read-ahead'' permettant d'anticiper des lectures et de réduire les côuts de transfert. Le mécanisme de DFS suit cependant une vraie logique de système de fichiers unique distribué. DFS permet des écritures asynchrones tout en intégrant la cohérence des données par un algorithme de jeton.
Figure 2: Entrées/sorties séquentielles avec les primitives read et write
entre deux 590 sur FDDI.
Le tableau 2 compare les performances en lecture et écriture
entre NFS et DFS entre deux 590 munis de 512 et 256 MO de mémoire centrale, et
sur des disques SEAGATE SD2400E, SCSI-I (les performances étant
dépendantes de la configuration, ces mesures sont à considérer
comme un ordre de grandeur de ce que l'on peut attendre sur ce type de
plateforme).
Les accès sont faits sur
des partitions JFS (version 3.2.5 d'AIX) exportées NFS et DFS ;
les lectures et écritures sont faites par blocs de 8 KO, et la taille
du ``chunk'' DFS est de 64 KO.
Dans le cas de la lecture de 100 MO, le fichier est caché en mémoire,
ce qui explique les débits supérieurs aux débits des disques. Par contre,
pour 500 MO, la limitation provient du débit des disques et non
du réseau.
Les écritures asynchrones de DFS donnent des débits supérieurs à NFS,
et comparables à ceux obtenus en JFS.
Figure 3: Entrées/sorties parallèlles avec les primitives read et write
entre deux 590 sur FDDI ;
les 2 disques sont ici rattachés à la même CPU
mais sur 2 contrôleurs SCSI 1 distincts.
Nous avons indiqué dans le tableau 3 les performances que l'on peut obtenir en faisant cette fois-ci des ``read'' ou des ``write'' alternés sur 2 fichiers, par bloc de 8 KO. En raison des mécanismes de read-ahead et de write-behind, les entrées sorties se font en parallèle ; les performances sont d'autant meilleures que les disques sont rattachés à des contrôleurs distincts.
DFS semble donc très bien adapté à des machines puissantes sur un réseau rapide. Il est capable d'exploiter les performances de la machine et du réseau en lecture mais également en écriture.
Les bonnes performances que nous obtenons sur les accès parallèles (cf table3) grâce au read-ahead et au write-behind d'une part, et les limites que nous imposait le système de fichiers AIX sur la taille des fichiers et des systèmes de fichiers nous ont amené à développer un outil : DIO. DIO permet de travailler sur un fichier de taille supérieure à 2 GO qui est physiquement distribué sur plusieurs disques (de façon bloc-cyclique) mais qui est vu et accèdé par l'utilisateur comme un seul fichier. Cet outil utilise le système de fichiers natif et le système de fichier NFS. Les performances mesurées lorsque l'on travaille en local sur deux partitions peuvent être doublés par rapport à un accès séquentiel si les partitions sont sur deux disques distincts rattachés à deux contrôleurs SCSI distincts. En NFS, l'intérêt du logiciel est moindre, surtout au niveau des écritures en raison de leur caractère synchrone.
Figure 4: Entrées/Sorties avec PIOUS
Nous avons par ailleurs testé l'outil PIOUS [1]
basé sur l'environnement PVM.
PIOUS est un système de fichiers parallèles
qui peut être utilisé sur un réseau de machines hétérogène.
Il permet en particulier de travailler en mode asynchrone sur un fichier
physiquement distribué sur plusieurs systèmes interconnectés et
donc d'additionner les débits (le fichier étant réparti de façon
bloc-cyclique sur plusieurs segments).
Le tableau 4 indique les débits mesurés
pour un fichier de 500 MO, la taille des blocs étant de 8 KO.
Les débits obtenus sont ici aussi bons en écriture qu'en lecture et
on tire parti des accès parallèles avec 2 et même 3 segments.