OpenLSD

OpenLSD : logiciel de GEIDE : Open Legacy Storage Document (English Version is Here)

Ce projet est un framrwork de Gestion Electronique Informatisée de Documents de l'Entreprise (ou Existants pour GEIDE, ECM in English) a pour objet l’archivage numérique et se veut être générique, c’est à dire qu’il n’est ni dépendant des données archivées, ni de leur format, ni de leur indexation. Ce projet constitue donc non pas une solution complète en soi, mais un framework complet dont il ne reste plus qu’à spécifier le type d’indexation et de créer la ou les applications de consultation associées. C'est un framework pour archiver et accéder à de grands volumes de documents statiques.

Ce projet a les propriétés suivantes :

• En pur Java et s'appuyant notamment sur le framework MINA
• Permettant de gérer en théorie jusqu’à 2^192 documents répartis en 2^64 espaces logiques applicatifs (Legacy), eux-mêmes répartis en 2^64 espaces de stockage (Storage) chacun contenant jusqu’à 2^64 documents (Documents)
• Chaque espace de stockage (Storage) peut atteindre 2^64 octets (16 000 Peta octets, soit 16 millions de Tera octets ou 16 milliards de Go)

• En pratique, un serveur physique ne devrait pas avoir plus de 256 Storages (systèmes de fichiers) pour des raisons d'exploitabilité (parlez en à votre administrateur SAN ou Système pour voir ce qu'il en pense), soit chaque serveur physique peut gérer jusqu'à 2^72 docments (4 722 milliards de milliards de documents). Ce nombre de document dans chaque système de fichiers est limité environ par 2^54 octets et si vous considérez une moyenne de 256 ko par fichier, alors vous avez jusqu'à 2^36 documents dans chaque Storage / système de fichiers, soit jusqu'à 2^44 documents dans un serveur physique OpenLSD (17 592 milliards de documents). Maintenant la limite du nombre de serveurs physiques est la capacité financière à investir... Disons que si vous pouvez vous offrir 32 serveurs comme cela, alors vous pouvez avoir 2^49 documents (562 949 milliards de documents).

• Permettant de réaliser de multiples copies (de 1 à n) sur des sites distincts pour assurer tant la sécurité des données (réplication) que la rapidité d’accès aux documents en terme de délais réseaux (proximité)

• Dispose de fonction de cache (en écriture et en lecture) permettant d’accélérer l’accès en lecture aux documents pour un utilisateur final mais aussi d’accélérer le processus d’import des documents dans le système dans le cas où l’utilisateur (ou l’application) n’est pas située à proximité d’un des sites LSD

• Utilise une base de données (JDBC : MySQL pour de petite GEIDE jusqu’à quelques millions d’entrées, Oracle ou PostGreSQL pour des GEIDE imposant de grands nombres de documents ou d’accès)

• Permet l’usage d’un module Java dans Tomcat (ou équivalent) pour réaliser l’interface de lecture des documents présents dans le système de GED.

OpenLSD n’est pas en soi auto-suffisant. En effet, il ne prend pas en compte les spécificités fonctionnelles (données métiers) qui servent à indexer les documents, mais il donne les fonctions nécessaires pour les gérer avec quelques adaptations supplémentaires. OpenLSD est une brique qu’il convient d’étendre (un exemple est fourni) afin d’obtenir l’application attendue par l’utilisateur. Le travail consiste essentiellement à écrire une seule classe Java OpenLSD assure les fonctions suivantes :

• Instanciation des index et des données nécessaires à OpenLSD dans une base de données selon plusieurs tables (MySQL, PostGreSQL, Oracle : le portage vers un autre SGBD ne devrait pas prendre plus de 2 jours)

• Une fois le schéma de la table des index métiers fixés et les programmes externes adaptés (compter de 5 à 10 jours), le système est prêt

• Import de documents : depuis le serveur réalisant l’hébergement physique (plus rapide) ou depuis le réseau (la vitesse dépendra alors du débit réseau) ; cet import est sécurisé (contrôlé, dupliqué si en mode clone), validé (équivalent MD5), unique (identifiant) et optimisé (disques et réseau).

• Extraction de documents : depuis le serveur réalisant l’hébergement physique (pour servir par exemple d’export pour gravure sur média externe), depuis le réseau (client Java ou client J2EE tel que Tomcat permettant un accès Web encapsulé)

• Fonctions de contrôle d’intégrité et de réparation

• Fonctions statistiques

Pour plus d'information, allez ici (Concepts, Howto, API, Download) en anglais uniquement.

Tests de performances (le rapport actualisé des tests est disponible en Anglais ici)

En 2007, les tests réalisés ont permis d’obtenir les performances suivantes :

Tests d'Import

• Entre deux serveurs Intel bi processeurs avec JDK IBM 1.5, un débit de 80 Mbits sur un lien à 100 Mbits d’imports de documents en continu (100 Ko par document soit 100 documents par seconde ou 360 000 documents par heure) mais sans la persistence en base de données.

• Sur un serveur AIX, 8 processeurs avec JDK IBM 1.5 64 bits permettent d'obtenir un débit de   1420 documents de 10 Ko injectés dans le système par seconde en mode non crypté avec la persistence en base de données (115 Mbits). Un score de  1290 documents de 10 Ko injectés dans le système par seconde a été obtenu en mode crypté dans les mêmes conditions.

• Sur un serveur AIX, 2 processeurs avec JDK IBM 1.5 64 bits, un débit de 170 documents de 100 Ko injectés dans le système par seconde en mode non crypté est obtenu avec la persistence en base de données (136 Mbits) et autant avec 3 processeurs en mode crypté.

Tests de Consultation par le Web

• A partir d'un serveur Intel bi processeurs avec JDK IBM 1.5 64 bits et Tomcat 5.5, un débit de 120 documents (de 100 Ko) par seconde en consultation (restitution via le web) est obtenu avec des temps de réponse de 0,2 secondes par document en mode non crypté, avec un débit de mesuré de 96 Mbits sur un lien à 100 Mbits . Le serveur Intel était à 60% CPU, le serveur AIX à 20% sur 1 CPU.

• Un second test identique au précédent (accès en consultation) mais sur la base de documents de 10 Ko cryptés dans OpenLSD a permis d'obtenir les performances suivantes : 350 requêtes par secondes, 0,012 seconde par document, et un débit mesuré de 30 Mbits . Le serveur Intel était à 90% CPU, le serveur AIX à 40% sur 1 CPU.

• En mode fichiers non cryptés, les performances sont les suivantes :  350 requêtes par secondes, 0,012 seconde par documents et un débit mesuré de 32 Mbits . Le serveur Intel était à 90% CPU, le serveur AIX à 20%  sur 1 CPU.

• En mode fichiers non cryptés, avec 2 serveurs Tomcat identiques, les performances sont les suivantes : 700 requêtes par seconde, 0,012 seconde par document et un débit mesuré de 60 Mbits. Le serveur Intel était à 90% CPU, le serveur AIX à 40% sur 1 CPU.

• En mode fichiers non cryptés, avec 3 serveurs Tomcat identiques, les performances sont les suivantes : 1000 requêtes par seconde, 0,012 seconde par document et un débit mesuré de 88 Mbits. Le serveur Intel était à 90% CPU, le serveur AIX à 90% sur 1 CPU.

• En mode fichiers cryptés, avec 3 serveurs Tomcat identiques, les performances sont les suivantes : 1000 requêtes par seconde, 0,012 seconde par document et un débit mesuré de 88 Mbits. Le serveur Intel était à 90% CPU, le serveur AIX à 75% sur 2 CPU.

Tests Simultanés d'Import et de Consultation par le Web

• En injectant simultanément des fichiers de 10 Ko en mode crypté ou non crypté et avec une consultation de ces mêmes fichiers sur la base de 3 serveurs Tomcat identiques, les performances sont inchangées : 1000 requêtes de consultation par seconde avec un temps de 0,012 seconde par document et un débit mesuré de 88 Mbits ainsi que un débit de 285 documents de 10 Ko injectés dans le système par seconde avec la persistence en base de données . Le serveur AIX utilise alors 5 CPU.

Test de Validation de la cohérence

• Un benchmark sur la validation des données en base et dans le système a été réalisé avec un débit de 2400 fichiers validés par seconde, soit un débit de 470 Mbits de vérification en utilisant 4 CPU.