Page suivante Page précédente Table des matières 2. Définition d'un système de gestion utilisable en production basé sur Linux Par Jurgen Defurne. 2.1 Introduction Dans un précédent article, j'ai traité de plusieurs sujets concernant l'utilisation de Linux dans la vie économique, non seulement pour des applications réseaux ou télécommunications, mais également dans des systèmes concrets utilisés en production. Un certain nombre de conditions doivent être remplies, mais il doit être possible de définir un système de gestion de base pouvant être rapidement mis en place et possédant toutes les fonctionnalités indispensables à un tel système. Ces deux derniers mois, j'ai approfondi ma connaissance de Linux et des outils disponibles sous Linux. Certains points demandent encore à mûrir, mais j'ai une idée tout-à-fait bonne de ce qu'il faut. 2.2 Objectif Mon objectif est de passer en revue les éléments nécessaires pour réaliser un système de gestion fiable, utilisable dans des conditions réelles de production, et les outils indispensables pour effectuer des développements (rapides et sur place). Tout ceci, pour un coût bien inférieur à celui repuis sur des plates-formes traditionnelles. Il doît être fiable au sens que toutes les procédures nécessaires pour avoir un temps d'indisponibilité minimum existent, en insistant sur le fait qu'un temps d'indisponibilité réduit est acceptable. Ici, je dois faire une remarque. J'ai travaillé sur plusieurs projets où les gens ont essayé d'économiser du temps en demandant un développement rapide ou ont essayé d'économiser de l'argent en réutilisant des morceaux par-ci par-là ou en modifiant des systèmes. Dans tous les cas, il en est résulté une perte de temps et d'argent, la raison principale venant du fait que tous les aspects du problème n'avaient pas été bien appréhendés. C'est une erreur que je ne veux pas commettre. Je pense que j'ai maintenant suffisamment d'expérience pour indiquer la voie à suivre pour atteindre l'objectif défini ci-dessus en décrivant une plate-forme Linux de production ayant des coût de déploiement et d'exploitation inférieurs. 2.3 Recommandations de base Voici des lignes de conduite générales. Le premier facteur dans la création et l'exploitation réussies d'un système de gestion réside dans la sélection rigoureuse du nombre d'outils présents sur la plate-forme. Le deuxième facteur de succès reposant sur la compréhension et la connaissance de ces outils. L'expérience est encore l'outil le plus valable, mais, selon le nombre et la complexité des outils, on peut perdre beaucoup de temps en essayant de connaître tous les outils que l'on a à sa disposition. De bons manuels, avec des exemples clairs et des références croisées complètes, sont d'un grand secours, comme le sont les cours sur les sujets pertinents. 2.4 Matériel Pour l'instant , je ne m'étendrai pas sur le matériel. La plate-forme de base devrait être constituée d'un PC standard avec un disque dur IDE doté d'un contrôleur PCI rapide. J'ai testé le débit de base d'un Compaq Despro (166 MHz, jeu de composants Triton II) et ai obtenu une valeur brute de 2.5 MB (megabytes)/s (sans tampon, en utilisant des write()). Je pense que pour une petite machine d'entrée, c'est tout-à-fait raisonnable. Des tests complémentaires devraient etre effectués pour analyser la charge de la machine dans des conditions de production. Le point le plus important, cependant, est que toutes les machines sous Linux, dans des conditions de production, doivent être équipées d'alimentations secourues. Car le système de fichiers e2fs (comme tous les systèmes de fichiers Un*x) est très sensible aux coupures intempestives d'alimentaion. Pour cette raison, il est indispensable d'avoir une unité de bandes avec de bonnes procédures de sauvegarde et de restauration qu'il faut mettre en place dès le jour 0. 2.5 Outils de production Le système de gestion de base de données constitue l'outil principal. Pour une utilisation en production, on doit disposer des fonctionnalités suivantes  : capacité de recherche rapide, traitement en lots, impression, télécommunications, suivi des transactions, enregistrement des opérations, interface utilisateur conviviale. Capacité de recherche rapide Cette fonctionnalité est particulièrement indispensable pour des applications interactives. Vos clients ne doivent pas attendre une demi minute avant que l'opération demandée ne soit terminée. On peut améliorer cette rapidité en utilisant des tampons ainsi que des CPU, des unités de disques, des bus système plus rapides et un système RAID (Réseau de disques redondants). Traitement en lots C'est un outil de productivité particulièrement valable. De nombreux travaux dépendent de modifications effectuées dans la journée, mais nécessitent des temps de traitement importants ultérieurs. On les fait tourner la plupart du temps la nuit, de façon répétitive, quotidiennement, à la semaine, mensuellement ou annuellement. Impression L'impression constitue une part importante du travail de tout système de production et doit être considéré dès la phase de conception. En effet, de nombreuses compagnies utilisent de nombreux documents officiels. Il faut pouvoir utiliser non seuelement des imprimantes laser ou à jet d'encre, mais également envisager le cas des impressions lourdes pour les factures, le papier multi-feuilles etc... Télécommunications Cela ne concerne pas seulement Internet. Il existe encore de nombreux systèmes connnectés entre eux par des lignes directes. La principale raison vient du fait que cela apporte un plus grand pouvoir de contrôle des accès aux personnes chargées de ces services. Le support de X25 doit être une option supplémentaire à TCP/IP, e_mail et fax. Les gens doivent également pouvoir contrôler les messages et/ou les fax qu'ils envoient. Une file d'attente des messages doit être disponibles, où chacun peut voir la liste globale de tous les messages (destinataire, heure, etc. ) et peut accéder à ses propres messages. Suivi des transactions Par suivi des transactions, je veux parler de la possibilité d'annuler les mises à jour en attente sur les tables de la base de données. Cette possibilité est particulièrement utile lorsqu'une modification concerne plusieurs tables. Les modifications doivent pouvoir être effectuées toutes au même moment ou annulées pour revenir à l'état précédent. Enregistrement des opérations Cette fonctionnalité est nécessaire pour pouvoir réparer des fichiers ou des systèmes de fichiers endommagés par une panne du système. Après redémarrage, un programme spécial doit annuler toutes les modifications qui n'ont pas pu être menées à terme. Dans ce sens, l'enregistrement des opérations est quelque chose de très proche du suivi des transactions. Interface utilisateur conviviale C'est la partie la plus délicate, car cela concerne à la fois le développement et la production. Pour ce qui concerne la production, l'interface doit donner aux utilisateurs un accès rapides à leur applications et séparer les applications par département. Sur la plupart des systèmes j'ai vu cela réalisé par l'intermédiaire de menus. Il y a plusieurs raisons à cela. La principale vient de ce que la plupart des systèmes utilisés fonctionnent encore avec des applications de type «orientées caractères». Il existe de nombreuses interfaces utilisateur graphiques, mais les systèmes de production seront encore uniquement de type caractère (sauf pour le graphique et l'impression, mais je les considère comme des niches du marché) même s'ils possèdent une interface utilisateur graphique. La deuxième raison vient du fait que les systèmes de prodution utilisent habituellement des tas et des tas de petits et de grands programmes. Il n'est pas possible de les mettre tous en icônes et de les présenter sur un écran, et vous auriez tout simplement un menu graphique, avec toutes les icônes apportant plus de confusion que de clarté. Qu'y a-t-il de disponible ? Note :lorsque je nomme ou spécifie des produits, je ne parle que de ceux qui me sont familiers. Je pense que chacun d'entre vous aura ses propres préférences. Ce ne sont que des exemples et ils n'impliquent pas de préférence de ma part. PostgreSQL est le seul système de gestion de base de données que je connaisse actuellement sous Linux. Il supporte SQL et le suivi des transactions. Est-il rapide ?, je n'en sais rien. Il faudrait disposer d'une base de données complète, avec des transactions en interactif ainsi que des travaux en cours d'exécution en tâches de fond et en traitement par lots, pour le tester en grandeur nature. Pour les traitements par lots, il faut toujours lancer crond. De plus, les commandes at et batch peuvent être utilisées pour obtenir une réalisation plus structurée des procédures de travail. Pour l'impression, je connais (et utilise) les outils standards de Linux lpd, Ghostscript et TeTex. Il peut cependant exister un blocage. Quelquefois, il faut fusionner documents et données. Un paquetage de traitement de texte offre un meilleur contrôle sur le format et le contenu du document qu'une simple application de génération de rapport. Sur mon lieu de travail actuel, une migration vers HP est en cours. WordPerfect constitue la solution utilisée. Dans le passé, j'ai utilisé cette solution sous DOS, pour lancer automatiquement WP et produire le document fusionné. Peut-on également le faire avec StarOffice ?. Existe-t-il d'autres solutions pour avoir un contrôle interactif meilleur sur l'impression que l'utilisation de lpd ?. Les utilisateurs doivent avoir un accès plus simple à leurs travaux et aux processus d'impression. Les télécommunications constituent le vrai point fort de Linux. Je ne vais pas tout énumérer. Même s'il ne supporte pas X25, il est toujours possible d'utiliser les lignes directes commutées en utilisant SLIP ou PPP. L'enregistrement des opérations est le point faible de Linux. J'ai travaillé avec les systèmes de fichiers suivants  : FAT, HPFS, NTFS, e2fs, le système de fichier Novell et celui des mini-ordinateurs WANG VS. Avec tous ces systèmes, j'ai eu des pannes d'alimentation ou des crashs, mais e2fs est le seul système qui m'a posé des problémes ensuite. Dans tous les autres cas, un test du système de fichiers répare tous les dommages et l'ordinateur fonctionne à nouveau. Sur WANG VS, des fichiers séquentiels indexés existent. Lors d'un crash, l'intégrité physique du fichier d'index peut être compromise. Pour y remédier, il y a deux solutions. La première consiste à réorganiser le fichier principal, ce qui se fait en copiant le fichier enregistrement par enregistrement. On reconstruit ainsi entièrement le fichier et les index, les insertions ou suppressions non validées étant rejetées. La seconde option consiste à utiliser le système de transaction intégré. On peut marquer un fichier comme appartenant à une base de données. Chaque modification dans ce fichier est enregistrée jusqu'à ce que la transaction soit terminée. À la suite d'une panne, les fichiers peuvent être restaurés dans leur état initial en utilisant les enregistrements (journaux) existants. C'est une affaire de minutes. Je pense que le système de fichiers Novell est le seul système de fichiers sur PC offrant de telles fonctionnalités. La fonction de test du système de fichiers e2fs fonctionne, mais elle n'est pas assez explicite dans ses diagnostics. Lors d'un vrai crash, le système de fichiers est vraiment dans les choux. 2.6 Outils de développement Je vais décrire ici les outils dont j'ai eu besoin alors que j'étais chargé de la maintenance d'une base de données dans un emploi précédant. Le thème principal ici concerne la productivité des programmeurs dans un environnement de production. Cela signifie qu'ils doivent disposer d'un paquetage complet, avec tous les outils et la documentation nécessaire pour démarrer immédiatement (ou en un temps très bref). Cela entraîne que pour chaque paquetage on puisse disposer d'un didacticiel court et pratique. Je diviserai cette section en deux parties, la première concernant les outils nécessaires, la seconde les outils optionnels. Pour effectuer du développement, il faut également avoir une méthodologie. Cette méthododlogie doit être la même pour tous les outils fournis. La manière la plus simple de disposer de cela consiste à utiliser un environnement de développement intégré. 2.7 Outils de développement obligatoires Quels sont les outils dont ils faut au minimum disposer pour commencer à programmer sans trop d'embêtements ?. Les outils suivants me semblent indispensables sur plusieurs plates-formes  : un environnement de développement intégré, un éditeur de texte puissant, un paquetage de développement d'écrans interactifs, un dictionnaire de données, un langage de haut niveau ayant un pré-processeur pour un système de gestion de base de données (SGBD), un langage de script. Environnement de développement intégré. Votre environnement de développement intégré (IDE) doit vous permettre d'accéder à tous vos outils de manière simple et cohérente. Il doit être largement configurable, mais fourni avec une configuration qui donne accès à tous les outils installés. Éditeur de texte. Si vous avez un éditeur vraiment bon, il peut se comporter comme environnement de développement intégré. Les fonctionnalités de "Recherche/Remplacement" et la possibilité de définir des macros commandes sont des éléments qui augmentent beaucoup la productivité. La mise en relief de la syntaxe par coloration du texte est intéressante, mais on peut vivre facilement sans elle. La vérification de la syntaxe peut être intéressante, mais il vous faudra apprendre à vivre avec. De plus, l'éditeur ne peut pas savoir de quelle partie d'un instruction vous n'avez pas besoin, et, comme résultat, vous aurez plus de pagaille dans votre source ou vous perdrez votre temps à effacer le code source inutile. Développement d'écrans. C'est un domaine dans lequel on peut faire de grandes économies. Pour disposer d'un système de développement d'écran puissant, il faut que le paquetage dispose des éléments suivants  : écrans standards construits à partir des informations disponibles dans le dictionnaire de données. échange facile des variables entre les écrans et les applications, méthode standard d'activation des écrans dans une application. Les gains obtenus sont à plusieurs niveaux. Si vous créez de nouveaux écrans, vous disposez immédiatement d'un écran par défaut qui contient tous les champs de la table concernée. Ensuite, il n'y a plus qu'à les repositionner et à les reformater pour s'adapter aux nécessités locales. J'ai travaillé avec deux systèmes, FoxPro et WANG PAGE, ayant de telles fonctionnalités et les gains ont été impressionnants dans tous les cycles de production du logiciel ( réalisation du prototype, implémentation et maintenance). Dictionnaire de données. Un dictionnaire de données constitue un outil puissant, à partir duquel on peut extraire de nombreuses informations pour tous les domaines du processus de développement. Le constructeur d'écran et le pré-processeur du langage de haut niveau doivent pouvoir extraire leurs informations du dictionnaire de données. La possibilité de définir des fonctions de vérification de champs et d'enregistrements au niveau du dictionnaire de données plutôt que dans le programme d'application, supprime la nécessité de modifier tous les programmes source en cas de changement. En utilisant des rapports appropriés, on doit pouvoir être capable de visualiser, sous différents angles, la structure de la base de données. Langage de haut niveau avec pré-processeur pour système de gestion de base de données. Vous ne pouvez pas faire de développement sans langage de haut niveau. Il y a toujours des fonctions qui ne peuvent pas être réalisées directement à partir du système de gestion de base de données. Pour faciliter le développement, on doit pouvoir intégrer des instructions de contrôle de la base de données dans le programme source. On doit pouvoir invoquer le compilateur automatiquement. Langage de script. Un langage de script est très utile pour plusieurs raisons. La préparation de travaux à exécuter en lots l'utilise. J'ai également constaté qu'un système est constitué de plusieurs parties réutilisables, que l'on peut facilement enchaîner en utilisant un langage de script. De plus, ce langage peut largement faciliter la gestion et la maintenance du système. 2.8 Outils de développement optionnels. Ce sont des outils qui sont disponibles sur plusieurs plates-formes, qui peuvent se révéler pratiques, mais qui ne sont pas nécessairement à fournir pour des applications dans un environnement de production. J'ai trouvé que l'on ne les utilisait qu'assez peu. système de requête interactif, éditeur de rapport. Système de requête interactif. Ce système est conçu pour des utilisateurs qui ne sont pas programmeurs. L'expérience m'a cependant enseigné que les gens qui ne sont pas programmeurs n'ont pas le temps de se former à ces outils. C'est un outil utile pour le programmeur qui peut tester ses requêtes et ses vues, mais il n'est pas vraiment utile comme outil de production. Dans quelques cas seulement, pour du travail rapide et grossier, on peut avoir à l'utiliser. Éditeur de rapport. C'est un outil surestimé. J'ai confronté mon point de vue à celui d'autres programmeurs et notre conclusion est que les patrons réclament toujours des rapports qui sont beaucoup plus compliqués que ceux qu'un simple éditeur de rapport peut fournir. Il vaudrait mieux, et de loin, utiliser un langage de programmation spécifique à l'édition de rapports (quelqu'un en connaît-il un ? Y a-t-il des expériences d'extraction de données et d'édition de rapport avec Perl ?). Qu'y a-t-il de disponible ? Note  : je me concentrerai uniquement sur les outils de développement indispensables. Le reste de l'environnement tournera autour des fonctionnalités de PostgreSQL. Quand on parle d'environnement de développement, Emacs est probablement le premier qui vient à l'esprit. Il intègre même le deuxième point concernant l'éditeur puissant. On peut même lier les deux. EMACS est-il un éditeur puissant que l'on peut utiliser en environnement de développement ou est-il un environnement de développement dans lequel l'éditeur est étroitement intégré ?. Le dictionnaire de données, le paquetage de développement d'écran et le pré-processeur de SGBD (Système de Gestion de Base de Données) sont plus étroitement liés que toutes les autres parties du paquetage. L'éditeur d'écran et le pré-processeur de SGBD doivent prendre leurs informations dans le dictionnaire de données, et les instructions de haut niveau du SGBD doivent également interagir avec les écrans. Il doit être possible de développer des écrans à la fois pour X-Window et pour des terminaux orientés caractères. Dans le domaine des langages de haut niveau, il y a plusieurs options, mais il manque toujours un langage orienté gestion. Oui, ici, je parle de COBOL, bien qu'un dialecte de xBase soit également parfait pour de telles applications. J'ai programmé dans différents langages pendant huit ans et seulement les deux dernières années en COBOL. C'est un meilleur langage pour écrire des programmes de gestion que C/C++. Si quelqu'un me demandait maintenant d'écrire des programmes de gestion en C/C++, je pense que la première chose que je ferais serait d'écrire un pré-processeur pour pouvoir rédiger mes programmes avec une syntaxe ressemblant à celle de COBOL. Je ne sais pas ce que vaut ADA pour des programmes de gestion, mais une combinaison de GNAT, avec la possibilité d'avoir des instructions SQL intégrées dans le source C résultant, traité par un pré-processeur SQL peut peut-être fonctionner. J'ai eu seulement un petit aperçu de Perl, et je ne connais absolument rien de Tcl et de Python, mais, alors que des langages interactifs sont parfaits pour des programmes interactifs, vous devez aussi avoir à l'esprit que certains programmes doivent traiter beaucoup de données et que, dans ce cas, l'accès à un compilateur de code natif est essentiel. Il y a d'autres domaines dans lequel COBOL est parfait, c'est dans les domaines financier et mathématique. Ceci est dû à l'utilisation de nombres décimaux condensés ayant jusqu'à 18 chiffres de long où la virgule peut se trouver n'importe où. Vous devez avoir un compilateur qui traite également cela. Sur les plate-formes x86, cette possibilité existe dans le processeur numérique qui est capable de charger et de stocker des nombres décimaux condensés de 18 chiffres de long. les calculs sont effectués dans l'unité virgule flottante interne sur 80 bits du co-processeur. Si vous avez un système linux, le premier langage de script que vous allez rencontrer sera probablement l'interpréteur de commandes bash. Il sera suffisant pour la plupart des besoins, bien que mes expériences concernant les langages de script montrent qu'ils bénéficient grandement d'instructions pour des interactions simples (affichage de messages et saisie de champs simples). 2.9 Que faut-il fournir ? Comme je l'ai dit plus haut, cette liste ne constitue pas un quelconque soutien de ma part à l'un de ces produits ou programmes. Cette liste doit s'enrichir de tous les produits qui entrent dans l'une quelconque de ces catégories et donc, toutes les informations seront les bienvenues. Un aure point faible dans certains domaines de linux concerne la documentation. Dans un environnement de production, le projet de documentation de Linux (LDP) constitue sûrement un must, imprimé à partir des fichiers Postscript. Pour les produits commerciaux, disposer d'une bonne documentation ne constitue pas un problème. Pour les autres parties des outils Linux, les livres de O'Reilly & Associates sont très valables. Les HOWTO ne sont PAS adaptés à un environnement de production, mais puisqu'ils concernent plus l'implémentation, ils seront utiles aux gens qui intègrent le système. La règle est  : quand un système est livré, toute la documentation nécessaire doit être prête et livrée également. J'ai travaillé avec plusieurs systèmes disposant d'une documentation en ligne, mais dans un environnement de production, rien ne surpasse une documentation imprimée. ________________________________________________________________________ | Système de production | |______________________________________________________________________| | | PostgreSql | | SGBD | mySQL | | - Requête/mise à jour rapide | mSQL | | - traitement des transactions | Adabas | | - enregistrement des opérations | c-tree Plus/Faircom server | | | ... | |_________________________________|____________________________________| | Communication | ppp | | | slip | | | efax | | | ... | |_________________________________|____________________________________| | Traitement par lots | crond | | | at | | | batch | |_________________________________|____________________________________| | Impression | lpd | |_________________________________|____________________________________| | Interface utilisateur | ? | |_________________________________|____________________________________| | Système de développement | |______________________________________________________________________| | Environnement de développement | EMACS | | intégré | | |_________________________________|____________________________________| | Éditeur | EMACS | | | vi | |_________________________________|____________________________________| | Développement d'écrans | Dépend du SGBD | |_________________________________|____________________________________| | Dictionnaire de données | Dépend du SGBD | |_________________________________|____________________________________| | | C | | Langages de développement | C++ | | d'applications | Cobol ? | | | Perl | | | Tcl(Tk) | | | Python | | | Java | |_________________________________|____________________________________| | Langage de script | bash | |_________________________________|____________________________________| 2.10 Résumé Je suis toujours en train d'essayer d'imposer Linux en gestion. Si vous voulez faire de la gestion en utilisant Linux, vous devez pouvoir fournir un système complet au client. Dans cet article j'ai indiqué les composants d'un tel système et quelques unes des faiblesses qu'il faut surmonter. Enfin, j'ai dressé un tableau qui énumère les omposants nécessaires pour un tel système. Ce tableau n'est absolument pas définitif. Toutes les références aux programmes et aux produits me permettant de mettre à jour ce tableau seront les bien venus. Il devrait être possible de publier une mise à jour tous les mois. Il faudrait aussi que j'étende ce tableau avec des références aux documentations disponibles. Le développement de tests pour vérifier la puissance du système de gestion de base de données, i.e. ce que l'on peut attendre en matière de rapidité de traitement et de réponse pour différents scénarios de charge du système, constitue un autre point sur lequel il faudrait porter plus d'attention _______________________________________________________________________________ Copyright © 1999, Jurgen Defurne - Publié dans le n°36 de la Linux Gazette. Adaptation française de Albert-Paul Bouillot Page suivante Page précédente Table des matières