Page suivante Page précédente Table des matières 13. Reflexions sur Linux Par mailto:jurgen.defurne@scc.beJurgen Defurne 13.1 Introduction Tout d'abord, je voudrais expliquer la génèse de ce document. Ma volonté de promouvoir Linux dans les entreprises repose sur plusieurs raisons. Bien que j'ai découvert Linux il y a cinq ans, je n'ai vraiment commencé à l'utiliser qu'il y a peu. J'utilisais déjà quelques outils GNU pour DOS et OS/2, mais seule une récente extension des capacités de stockage de ma machine m'a permis de franchir le pas. J'ai imprimé quelques manuels, me suis abonné au Linux Journal et ai essayé de lire la Linux Gazette régulièrement. Je me considère donc un peu comme un fan de la première heure. De plus, depuis début 1997 je travaille avec un environnement "classique" mini/COBOL/base-données dont j'ai remarqué qu'il offrait beaucoup à ceux qui l'utilisent: facilité de contrôle et d'action, un seul programmeur suffit, operations en tâche de fond, etc. Le revers de la médaille est que ces systèmes propriétaires sont coûteux. Vous devez payer cher pour souscrire le contrat de maintenance annuel et pour chaque réparation ou mise à jour. Enfin, la dernière raison, qui n'est pas des moindres, est que je n'ai aimé aucune des diverses incarnations de Windows depuis 1990. En 1990, Windows produisait déjà les fameux 'General Protection Failure' pour des raisons souvent inconnues et huit ans après, rien n'a changé. Window contraint les gens à acheter du matériel à prix d'or, dont ils ne peuvent ensuite pas tirer pleinement parti sous peine d'obtenir une erreur système. Ces trois raisons m'ont conduit à rédiger ces trois documents, que je publie dans la Linux Gazette, car je crois asvoir qu'elle est lue par des personnes qui connaissent d'autres systèmes d'exploitation que DOS et Linux, ce qui constitue un prérequis indispensable pour atteindre l'objectif que je me suis fixé. Cet objectif est en fait le même que celui que s'est fixé Linus Torvalds, à savoir La domination mondiale. Cependant, j'ai mes raisons de croire que cette hégémonie ne pourra pas être atteinte grâce aux seuls PC, stations de travail et applications internet. Je suis convaincu que Linux a les capacités requises pour se lancer dans la compétition des systèmes d'entreprises. Il reste cependant nombre de trous à combler avant que cela ne devienne réalité. Mais je pense aussi qu'il existe un potentiel suffisant au sein de la communauté Linux pour que nous puissions concrétiser ce rêve. Le texte qui suit se divise en trois parties dans lesquelles j'ai tenté d'organiser mes idées concernant les besoins que Linux devra combler pour atteindre cet objectif. Dans la première partie, je cherche à comparer Linux aux mini-ordinateurs et aux grand-systèmes que je connais et à leurs archietctures, lançant du même coup un appel à ceux qui voudraient aider au developpement de Linux pour de grand-systèmes. Je l'ai posté dans plusieurs forums de l'arborescence comp.os.linux.*, mais je n'ai reçu qu'une seule réponse positive. 13.2 Grand système Linux/ Linux Grand systèmes (mainframes) 0. Objectif Ce document devra être revu et restructuré. La principale raison pour l'avoir envoyé par l'Internet en l'état est que je veux connaitre le nombre de réponses qu'il provoque. Si finalement aucun intérêt n'est suscité, alors le projet sera annulé. Si vous êtes arrivés là, alors continuez. Toutes les idées qui feraient un bon titre ou quelque chose d'approchant, sont toujours les bienvenues. Ce document n'a pas le statut d'un HOWTO. Si je devais lui en affecter un, alors ce serait quelque chose comme un RFC, en moins officiel. Je m'excuse si ce n'est pas toujours clair. J'ai besoin de documenter certaines parties avec des dessins pour fournir une meilleure explication. Il devrait probablement être disponible en fichier sgml, pour être manipulable plus efficacement. Bien que ce document ait été envoyé à différents newsgroups linux, il serait préférable d'en choisir un seul afin d'en discuter. 1. Remarque préliminaire Ce document n'est en aucune manière complet. Il essaye de définir une base de travail pour développer et déployer Linux comme système d'exploitation pour Grand Système (mainframes). Si des idées dans ce document sont développées ailleurs dans la communauté de développement Linux, je serais heureux de le savoir, et ainsi Ils pourront être utilisés avec moins d'effort de développement Ils pourront être référencés dans (je l'espère) d'autres éditions de ce document 2. Limites et conditions Ce document est, pour le moment, de ma propre responsabilité et sous mon propre copyright. Il peut être distribué partout, mais je suis le seul à pouvoir le modifier. SVP, envoyez vos questions ainsi que vos suggestions à mon email jurgen.defurne@scc.be. Toutes marques déposées acceptées. J'ai l'intention d'investir du temps dans ce projet. J'ai un travail sympa, régulier, travaillant la journée comme programmeur COBOL, ainsi le temps ne devrait pas être un souci. 3. Rationalisation Les idées dans ce document sont le fruit d'une réflexion basée sur ma propre expérience des ordinateurs et toutes ces choses lues dans le bestiare des publications (journaux, livres, les RFC, les HOWTO, le web, compte rendus de colloques, etc.) Résultat : linux est extrêmement adaptable. Pour moi, il est prouvé qu'il est beaucoup plus adaptable qu'un produit MS. J'utilise Linux sur les systèmes suivants : ordinateur portable Toshiba 386sx/16MHz/3Mb/200 Mb 386sx/16MHz/16Mb/sans disque 386/33MHz/4Mb/200Mb 486/50MHz/32Mb/100Mb 6x86/P150+/16Mb/500Mb Certains sont interconnectés, d'autres pas (encore). En utilisant telnet, X et TCP/IP il est possible d'utiliser ces systèmes ensembles, pour exécuter des programmes sur les différentes machines, etc. Mais je veux plus. Ce que j'aimerais vraiment c'est que ces systèmes interconnectés soient vus comme un seul, avec un espace d'adresse commun, et que leurs ressources propres soient ajoutées ensemble pour former un ordinateur plus puissant. L'objectif principal serait de rendre possible l'introduction de Linux dans des environnements où les traditionnels mini-ordinateurs sont utilisés pour l'entrée de données et leur traitement. Cela peut sembler un but assez ambitueux. Je ne sais pas si c'est le cas. Ce que je sais c'est que des environnements de haute disponibilité sont une priorité majeure (Note 1). Une autre raison de faire ce projet est qu'au début de l'année Tandem a conçu un Grand Système utilisant un système 64 SMP 4-way, NT, leur propre logiciel d'interconnexion et un Serveur Parallèle Oracle. Pourquoi ne serions nous pas capable de faire quelque chose d'équivalent ? 5. Objectifs Ce document doit décrire non seulement le logiciel, mais aussi le matériel et les procédures systèmes. J'espère le réviser régulièrement. J'aimerais qu'il contienne des liens vers du code source, des schémas, plans de construction, toutes les sources utilisées et un historique et la plannification du projet. Il devrait permettre aux personnes qui veulent faire de l'argent avec Linux de le faire à un niveau professionnel. C'est à dire être capable d'aider les entreprises à répondre à leur besoin selon les traitements demandés, donner des conseils sur le matériel requis, installer et implanter le système et fournir du service, de la maintenance et de la formation. 6. Quelles sont les qualités d'un environnement sur mini/grand système ? Je n'ai pas eu une formation de programmeur conventionnelle. Je suis un ingénieur en électronique. Après l'école, j'ai utilisé les micro-ordinateurs et la programmation et j'ai approfondi mes connaissances en suivant des cours d'organisation d'entreprise et d'informatique industrielle. Mon expérience dans le monde des mini/grand systèmes est récente, elle ne date que de janvier 1997. Au début j'ai dû travailler dans un environnement WANG VS (Note 2), maintenant je suis toujours programmeur WANG, mais c'est comme frontal d'entrée à un grand système (Bull DPS8000/DPS9000) que travaille le WANG ainsi que pour le traitement de documents légaux. A mon premier travail, le mini-ordinateur WANG VS était plus utilisé comme Grand Système de production. Finalement, qu'ont en commun ces systèmes ? tolérance de panne, système de fichier hautement performant bases de données avec possibilité de transactionnel un simple compilateur pour le développement, avec support pour le système de fichier et la gestion de la base de donnée un langage de script polyvalent ou un langage de contrôle de travaux un système de développement intéractif un accès facile aux fonctions du système d'exploitation facilité, mais puissance d'accès pour gérer le système otionnel : des outils performants pour les non-programmeur pour accéder, extraire et traiter les données des bases de données (Rapports, requêtes, ...) La principale différence entre le mini et le grand système est dans les opérations du système. Les quatres principales tâches qui sont à effectuer sur un ordinateur sont l'administration, l'exploitation, la maintenance de la production et le développement. Sur un grand système ces tâches sont effectuées par différents personnes, sur un mini par une seule, ou partagées, mais vous n'avez pas besoin de personnel à temps complet pour les différentes tâches (à part la programmation). Les systèmes d'exploitation tournant sur les grand systèmes peuvent être suffisemment complexes pour que certaines tâches ou opérations ne puissent être faites que par du personnel de confiance. Gérer le système comprend les tâches suivantes : Gérer les imprimantes et les files d'attentes Gérer les travaux et les files de travaux Gérer les communications et les périphériques de communication Gérer les disques, bandes, stations de travail et les options du système 7. Quelles sont les qualités d'un ordinateur mini/grand système ? Fondamentalement, la capacité de prendre en charge efficacement et rapidement les tâches. Si vous voulez en apprendre plus sur le coeur des systèmes d'exploitation, il y a suffisemment de littérature disponible (voir la liste littérature). Le problème de base pour faire tourner un système sur un grand ordinateur est la différence entre le traitement par lots et les opérations intéractives et temps réel. Vous voulez d'une part que les traitements par lots soient exécutés aussi rapidement que possible et d'autre part que les temps de réponse soient faibles. Le problème de base pour les PCs contre les mini/grand sytèmes est que la structure d'E/S des PC est très primaire. Cela commence à changer, en premier avec VESA, maintenant avec PCI, mais cela ne s'approche toujours pas du domaine des mini-ordinateurs. De façon simple, ces systèmes ont toujours un processeur interne séparé (ou plus d'un) sur le bus des E/S pour prendre en charge le transport de données entre les périphériques et la mémoire. Avec I2O (Intelligent I/O), ce mécanisme devrait être disponible pour le monde PC, mais il est encore propriétaire et n'est pas disponible pour Linux et/ou les développeurs de logiciels libres (Open Source). Les tâches compilées pour les architectures x86 tendent aussi à utiliser plus de mémoire. Prenons quelques exemples pour des mini-ordinateurs et grand systèmes que je connais et dont j'ai accès à la documentation. Aperçu de quelques systèmes d'entreprise système Mémoire principale Horloge Taille du bus Nombre d'utilisateurs possibles WANG VS 6 4 Mb 16 Mhz 16 bits 32 WANG VS 6120 16 Mb 20 Mhz 32 bits 253 WANG VS 6250 64 Mb 50 MHz 32/64 bit 253 WANG VS 8000 32 Mb N.D. 32/64 bit 253 BULL DPS9000 2 x 64 Mb N.D. N.D. N.D. BULL DPS8000 2 x 32 Mb N.D. N.D. N.D. Ces systèmes sont plus petits que les PCs en terme de mémoire, mais déjà ils supportent plus d'utilisateurs et de tâches qu'un PC. Je n'utiliserais pas mon portable Toshiba avec 10 utilisateurs utilisant une base de données. Pourtant, c'est ce qu'un WANG VS 6 est (était) capable de faire, avec les mêmes caractéristiques. C'est pour le moment ma principale critique des PCs standards et de leur logiciel : ils sont particulièrement inefficace. La première source d'inefficacité provient de la méthode utilisée pour abaisser le prix des PCs : le CPU est responsable du transport de données entre les périphériques et la mémoire. Vous avez un DMA disponible (NdT: Direct Memory Access, composant qui prend en charge certains accès mémoire en lieu et place du processeur), mais il n'est pas très efficace. La deuxième raison provient des logiciels utilisés principalement sur PC : ils prennent beaucoup de place sur disque et en mémoire. Une troisième raison réside dans les logiciels eux-mêmes : ils ont beaucoup de fonctions, mais peu utilisées. Plus il y a de fonctions dans un logiciel, moins il est efficace. (Note 3). Il y a une autre chose à apprendre des mini/grand systèmes : garder les choses simples. Je ne pense pas que l'actuel environnement bureau/interface graphique utilisateur soit simple. Il n'a pas une courbe d'apprentissage rapide, mais fondamentalement ce que vous avez est une version gonflée de ce qui est essentiellement des programmes simples. Lors de l'écriture de programmes ou de conception système, on devrait garder à l'esprit qu'à un certain moment cela coûte plus d'effort d'ajouter une fonctionnalité à un programme que d'en écrire un nouveau et que cette fonctionnalité diminue l'efficacité globale. 8. Fonctionalité existante Dans le domaine des ordinateurs parallèles il y a le système Beowulf et les librairies associées. Leur premier objectif est le traitement parallèle dans un but scientifique, alors que mon objectif est le traitement de données d'entreprises commerciales. Comme je le voie, certains de leurs objectifs sont commun avec le mien, surtout dans le domaine des goulets d'étranglement : le réseau, l'accès distribués des fichiers, l'équilibre de charge etc. Cependant la manière dont sont conçues les applications d'entreprise diffère de l'informatique scientifique. MPP est plus une façon de concevoir un ordinateur pour des tâches vraiment lourdes, alors que pour une machine d'entreprise vous avez des comptes d'utilisateur pour des requêtes, du traitement transactionnel, du traitement par lot de données entrantes, la préparation de données sortantes, établir des communications avec d'autres systèmes. Dans ce sens, ce que nous cherchons n'est pas de distribuer une tâche sur plusieurs ordinateurs pour accélérer le traitement, mais de servir adéquatement une puissance de traitement, de faciliter la manipulation de données et de la bande passante pour un grand nombre d'utilisateurs. Ces objectifs demandent des systèmes d'exploitation différents de MPP. J'ai étudié la structure Beowulf (un HOWTO Beowulf est disponible sur l'Internet). La structure Beowulf fonctionne comme un système MPP dans lequel un seul ordinateur exécute effectivement l'application. Tous les autres noeuds dans le système sont esclave de ce seul CPU. C'est pourquoi le système Beowulf convient partiellement pour atteindre mon objectif. 9. Par où commençons-nous ? Nous avons besoin de commencer avec un ensemble définis d'ordinateurs linux, dorénavant appelés CPUs, qui sont d'une manière ou d'une autre connectés entre eux par une couche de communication ou CC. Cette CC peut être mise en oeuvre en utilisant des connections séries, Ethernet, SCSI ou n'importe quoi d'autre pour les combiner pour permettre aux CPU de se parler. Un CPU peut être un ordinateur single-way ou un ordinateur multi-way SMP (multi-processeur). 10. A quoi voulons nous arriver ? Je pense que le point final devrait être de voir le système comme une seule entité. Pour cela, les conditions requises sont : Tout processus devra voir le même système de fichier Les ressources (à travers les fichiers /dev) devront être partageables par tous les CPU Chaque CPU devrait avoir la même vision du système d'exploitation et de la mémoire Les informations des processus devraient être partagés pour tous les CPU Un des changements fondamental dans le système d'exploitation devraient être la façon dont exec() fonctionne. Quand exec() commence un nouveau processus, cela peut être sur n'importe quel CPU. Le lien d'origine doit être préservé et les processus devraient se terminer comme d'habitude. Les communications inter-processus sont directement transposables, je pense. Ce que je voudrais savoir, c'est si cela vaut le coup de faire des efforts pour une vue système où toute la mémoire est distribuée dans un seul espace d'adresse ? (L'idée derrière cela : fournir à chaque CPU la même vue du système : son système d'exploitation, suivi par les zones mémoires de tous les autres CPU distribués dans le même espace d'adresse). C'est l'objet de NUMA (accès mémoire non-uniforme). Est-ce que la communauté Linux peut atteindre ce sous-but, ou est-ce que cela nécessite trop de ressources spécialisées ? 11. Haute diponibilité Certaines parties clés de Linux devraient être réécrites ou remplacées par des parties à tolérance de panne. La plus grande partie venant à l'esprit est le système de fichier. Il y a quelques mois j'ai eu une expérience désagréable. Un connecteur de mon câble SCSI est devenu défectueux, avec comme conséquence le blocage soudain du système alors que j'utilsais X-window. Le souci avec e2fs dans ces occasions est que le système de fichier est totalement corrompu. Cela devrait être rendu plus robuste. L'autre partie est que le système ne devrait pas se bloquer en ces occasions. Il devrait être possible de fournir un minimum de fonctionalités, c'est à dire que le système reprenne le dessus et bascule en mode texte afin de fournir des informations de diagnostic ou essaye de créer un fichier core. Un autre problème que j'ai rencontré est le manque de fiabilité quand un disque dur présente des anomalies. Ce qui m'est arrivé est qu'en utilisant un vieux disque SCSI, le noyau et/ou e2fs ont commencé à afficher des messages étranges quand j'ai tenté d'utiliser le disque. Quand le système rencontre des problèmes avec des périphériques, les problèmes devraient être tracés, les opérations devraient être arrêtées et des messages explicites affichés. D'autres caractéristiques clés dans le domaine de la Haute Disponibilité devrait être la tolérance du système complet alors qu'un CPU est manquant. Un CPU pourrait être ajouté s'il passe complètement l'autotest et trouve que tout va bien. Si un CPU actif dans le système se retire, il devrait y avoir des possibilités de redémarrer les processus qui ont été interrompus. Pour cela on devra fournir au programmeur les caractéristiques pour résoudre ce problème : un système de fichier transactionnel, des fonctions de point de contrôle (autres ?). 12. Résumé Il y a deux objectifs. Le premier est la création d'une extension qui combine plusieurs PC Linux en un seul système. Les utilisateurs et les processus devront avoir la même vue du système complet comme un seul. Cela veut aussi dire que certaines corvées administratives devront seulement dépendre d'informations centralisées stockées et partagées. Le second est d'ajouter une meilleure/plus de tolérance aux pannes, de préférence gérée plus intéractivement. Voilà, nous y sommes. J'espère que des personnes auront des questions raisonnables, que je ne serais pas submergé d'insultes et que cela augmentera suffisement l'intérêt afin de faire avancer Linux à un niveau supérieur. Références Cette liste de référence est clairement incomplète. J'ai besoin d'obtenir plus de détails sur certains travaux. Le "Linux High Availability White Paper". Le HOWTO Beowulf Le Parallel Processing HOWTO (HOWTO Traitement parallèle) Andrew S. Tanenbaum, Design and Implementation of Operating Systems Notes Note 1. J'ai travaillé pendant 16 mois dans une petite compagnie de transport. Le coeur de l'entreprise était contenu dans un mini-ordinateur WANG VS. Si le système était déconnecté, alors personne ne pouvait faire son travail correctement. Le système était en grand une base de données stockant des opérations distribuées, les ... de toutes les opérations, le contrôle de coût et la comptabilité. Je pense qu'il y a plein de petites entreprises, qui ne peuvent se payer un grand système, mais qui ont besoin de plus de puissance de traitement que le PC moyen peut offrir, et où bon nombre de personnes ont besoin de vues différentes des données. Note 2. Le WANG VS est un très bon exemple de solution propriétaire qui fait un excellent travail, mais avec un prix très excessif. Ils sont très cher, tant pour le coût initial, que pour l'évolution du système et sa maintenance. Je crois que c'est la raison principale pour laquelle les personnes veulent se débarasser de leur système WANG. Vous pouvez acheter, faire évoluer et maintenir un système HP pour un dixième du prix que coûte un WANG VS. Note 3. Si vous vous demandez pourquoi j'insiste sur l'efficacité : je me suis intéressé aux microprocesseurs en 1980 lorsqu'il n'y avait pas beaucoup de microprocesseur et de mémoire. Mon premier ordinateur était un Sinclair ZX Spectrum avec 48 Kb de RAM. Je suis toujours encore surpris de ce que pouvait faire certains prgrammeurs avec si peu de mémoire. Il y a autre chose derrière cela : qu'est-ce que la puissance de traitement pourrait délivrer si vous pouviez utiliser tous ces cycles processeur perdus dans le classique ordinateur PC. Pour les petites entreprises, le PC est toujours cher. Combiner la puissance de leurs PC pourrait peut être leur donner plus de marge dans leur travail. ----------------------------------------------------------- Dans la seconde partie j'essaierais de développer une architecture pour étendre Linux à un système de traitement parallèle, pas pour du traitement numérique comme Beowulf mais pour du traitement de données administrative. 13.3 Description de la séquence de démarrage d'une architecture multi-processeur Le but de ce document est de définir les composants que devra comprendre le projet mentionné dans le document précédent (Les grand systèmes Linux). Pour cela, une description de la séquence de démarrage sera donnée, en même temps que les difficultés possible et les solutions. Cependant, avant de tenter cela, je voudrais donner un court résumé de conseils qui nous conduira vers des systèmes Linux qui pourront être déployés dans des environnements d'entreprise. Les mini-ordinateurs et les grand systèmes fournissent fiabilité et hautes performances. La fiabilité est grandement obtenu de deux manières. La première est la conception du système, la deuxième est l'existence d'un département support avec aide en ligne et des techniciens spécialisés. Ce qui ressort de ce document est l'aspect matériel du système. La puissance processeur est obtenue de plusieurs manières. Cela implique d'utiliser la mémoire cache, des transferts de données plus élevés, augmenter la fréquence d'horloge, des processeurs avec pipeline et des transferts de données plus efficace entre la mémoire et les entrées-sorties. Que peut-on faire pour la fiabilité ? Du côté de la fiabilité, les système est dépendant du matériel et du logiciel. Si nous utilisons des parties matérielles courantes (cartes mères et cartes) alors la seule chose que nous pouvons influencer est la façon d'assemblager les systèmes. Faire attention à l'électriticé statique, en utilisant des tapis et bracelets antistatiques. Du côté logiciel nous avons le système d'exploitation Linux qui est très fiable, des rapports indiquant des systèmes tournant depuis des mois sans aucun redémarrage. Cependant, le matériel peut tomber en panne et de ce point de vue, je pense qu'il y encore à faire avec Linux. Si l'erreur n'est pas dûe au processeur ou à la mémoire système, alors le système devrait être capable d'intercepter les erreurs matérielles et les traiter intelligemment. Si possible, des utilitaires systèmes devraient être disponible pour tester le processeur, la mémoire système, le cache et le système de translation d'adresse. Le document de travail (White Paper) Haute Disponibilité sous Linux décrit l'agrégation (clustering) de petits systèmes. Plus loin dans le document, quelques autres techniques seront proposées. Que peut on faire pour la puissance processeur ? La puissance processeur provient de différents niveaux. Au premier niveau, à savoir le processeur et la mémoire principale on ne peut pas faire grand chose. Les cartes mères courantes avec des vitesses de bus de 66, 75 et 100 Mhz nous avons des vitesses de transfert de données entre la mémoire et le processeur de 264 MB/s, 300 MB/s et 400 MB/s. Cela devrait être suffisant pour la plupart des applications. La mémoire est peu chère, des capacités de 64 à 128 MB devrait donner une place suffisante pour les applications gourmandes. Le plus grand problème avec les cartes mères classiques est que toutes les entrées/sorties doivent être gérées par le processeur ou alors par un système DMA lent. Cela signifie qu'une grande part du système d'exploitation est utilisé par du code de gestion de périphérique. Dans les mini/grand systèmes cela n'est pas le cas. Toutes les entrées sorties (E/S) sont gérées par un processeur d'E/S séparé. Ces processeurs d'E/S implémente le gestionnaire de périphérique et comme tel libère une grande partie du temps au CPU principal. Je pense que deux autres solutions devraient être possible. La première, et probablement la plus facile, est d'utiliser des cartes mères multi-processeur (SMP) et de programmer le système d'exploitation pour qu'un seul processeur soit complètement responsable des E/S, et le reste des CPU font réellement le travail. Une autre idée en l'abscence de SMP, utiliser deux cartes mères, en utiliser une avec une version adaptée de Linux pour prendre en charge les E/S et utiliser l'autre pour exécuter les applications. Le seul problème est de trouver le système pour interconnecter les deux cartes mères. Spécialement dans le cas de périphériques de stockage de masse, vous voulez accélérer le flot de donées du périphérique vers la mémoire de l'application. Actuellement, cela veut dire utiliser le bus PCI d'une manière ou d'une autre. Résumé Depuis que nous, comme utilisateur Linux, n'avons pas à donner d'avis sur la conception des cartes mères, la fiabilité devrait être obtenue à travers de bons standars d'assemblage et en implémentant de la redondance. Pour obtenir plus de puissance processeur, le CPU devra être libéré autant que possible des E/S. Cela peut être implémenté en utilisant unsystème multi-processeur ou en interconnectant des cartes mères. Une proposition pour une architecture Linux mini/grand système En se basant sur les idées précédentes, utiliser plusieurs cartes mères interconnectées par un réseau haut débit peut nous donner les bénéfices qui suivent : Redondance pour augmenter la fiabilité Décharger les tâches d'E/S à un ou plusieurs noeuds spécialement désignés. Augmenter la puissance processeur Pour obtenir ces bénéfices lorsque le système est assemblé, quelques changements du S.E. (système d'exploitation) devront être effectués. Il est possible d'interconnecter des ordinateurs et les faire fonctionner en parallèle, mais toute l'administration devra être manuelle. Ainsi, ce que nous avons besoin lorsque le système est démarré, n'est pas une vue de plusieurs systèmes séparés mais d'un seul système. Description de la séquence de démarrage Lorsque le système démarre, tous les noeuds commencent de la même façon : le matériel installé est identifié, les gestionnaires nécessaires sont exécutés, une connection au réseau devra être effectuée, les répertoires NFS devront être montés, le système de fichier local devra être vérifié et monté. Dans le cas d'un système normal, tous les processus en tâche de fond devront être exécutés et les utilisateurs capables de se connecter au système. Puisque le système doit être vu comme un seul système complet, la séquence de démarrage devra être modifiée à ce niveau. Les ressources qui sont normalement accessible à un noeud, devront être partageable pour le système. Pour construire une vue commune, chaque noeud devra accéder à système de fichier commun. Dans ce système de fichier les répertoires /dev, /etc et /proc seront accessible par chaque noeud. Le répertoire /dev contient tous les périphériques partagés. Le répertoire /proc fourni l'accès à la structure du système qui devra être partagé pour tous les noeud. Le répertoire /etc contient les fichiers nécessaires pour contrôler le système : les utilisateurs les groups fstab inittab ... Chaque système d'exploitation sur chaque noeud doit être adapté pour travailler avec ces répertoires partagés. Pour contrôler la création de ces partages systèmes, un noeud sera désigné comme 'maître'. Après la séquence de démarrage initiale, chaque noeud attendra le maître pour initialiser le réseau. L'initialisation peut procéder de la manière suivante : créer /proc créer une table de processus système (accessible à travers proc) créer /dev regrouper tous les périphériques partagés sur le réseau exécuter fstab, inittab et les autres scripts pour initialiser le système complètement Les processus exécutés sont de deux natures. Les processus locaux s'exécutent sur un noeud qui contient les ressources dont le processus a besoin comme par exemple getty, les gestionnaires de fax, etc. Les processus globaux sont indépendants du matériel et devraient pouvoir être exécutés sur n'importe quel noeud du système. N'importe quel noeud devrait être capable d'exécuter de nouveau processus sur le système. En utilisant un système de répartition de charge, tous les processus lancés devraient également divisés sur tous les noeuds. Apporter la fiabilité au système Les système, comme proposé ci-dessus, pourrait présenter quelques problèmes. Le premier est sa dépendance vis à vis d'un seul ordinateur maître. Si ce maître défaille, tout le système est à terre. Pour se prémunir contre ce risque, il faudrait pouvoir définir plusieurs maîtres. Lorsqu'on allume l'alimentation électrique et que le système démarre, le premier noeud maître à prendre le contrôle du réseau doit agir en tant que coordinateur. Si un maître défaille, la seule conséquence doit être que ses ressources partagées ne sont plus accessibles au reste du système. Si un maître défaille alors que le système est en fonctionnement, le mécanisme de base assurant la coordination de l'ensemble n'est plus assuré. Pour résoudre ce problème, un maître de secours doit être désigné. Ce dernier devra conserver une copie de toutes les informations concernant le système détenues par le maître. Lorsque le maitre défaille, tous les autres noeuds doivent suspendre leur exécution en attendant que le maitre de secours prenne la relève. Le système doit offrir une gestion dynamique des noeuds. Ce qui veut dire que les noeuds doivent pouvoir être raccordés par des appels système, redirigés vers le maitre qui gèrera l'adjonction du nouveau noeud. Pour qu'un noeud puisse être détaché, il faut que ses ressources ne soient pas utilisées. Si un noeud défaille alors qu'il est utilisé, cela va nécessairement poser problème. Le défaut peut provenir du réseau (problème d'interface réseau, erreur du processeur) ou être local. Pour utiliser un périphérique distant, un processus devra communiquer avec le noeud qui le gère par envoi de messages. En cas de défaut, ce noeud sera incapable de répondre, le système d'exploitation devra alors bloquer ce processus jusqu'à ce que le défaut soit résorbé. Si des problèmes apparaissent dans des parties critiques du système, les gestionnaires de périphériques et les processus systèmes ne doivent pas entrainer dans leur chute le système tout entier ou les processus utilisateurs, mais plutôt annoncer le problème apparu et bloquer le processus qui nécessitait ces ressources. Lors d'un dysfonctionnement d'un périphérique, par exemple, le gestionnaire de périphérique doit renvoyer un message décrivant le dysfonctionnement. La partie la plus importante de ce système est le réseau d'interconnexion. Il devra être testé et adapté en fonction des besoins du système. Si possible, un protocol rapide sera utilisé en remplacement de TCP/IP. Résumé La vue que chaque noeud a du système global devra éecirc;tre la même. Les périphériques doivent pouvoir ecirc;tre partagés par le réseau. Le système d'exploitation devra être étendue de manière à ce que la fonction exec(), qui est élémentaire pour démarrer des processus, travaille au niveau global. La fiabilité doit être incluse dans le système lui-ême et être configurable à plusieurs niveaux. Un protocol d'envoi de messages spécifique sera nécessaire au partage des périphériques entre les différents neouds. Propositions pour l'interconnexion Schématiquement, deux moyens peuvent être utilisés tels-quels pour interconnecter notre système. Le premier est Ethernet. Suivant votre budget, vous pourrez construire un réseau de 10 Mbit, 100 Mbit ou 1 Gbit. Accroître la bande passante signifie accroître la puissance de calcul. Pour tirer le meilleur parti de cette bande passante, l'idéal est d'utiliser une carte mère multi-processeurs sur laquelle un processeur se charge de tous les transferts de données entre le réseau et la mémoire. Le second, qui attire l'intérêt de la communauté Linux, est l'interface SCSI. En utilisant des cartes SCSI modernes, on peut raccorder 16 cartes mères en parallèle. --------------------------------------------------- Dans cette troisième partie, j'ai réuni des exemples de cas pour lesquels j'ai contribué à montrer les carences de Linux. Quelques cas où Linux pourrait être utilisé, mais où il ne l'est pas. Par le biais de nombreuses améliorations (Beowulf, Coda FS, Andrew FS), Linux devient de plus en plus puissant. Mais à quel point "puissant" est-il effectivement "puissant" ? Des annonces et des utilisations de Linux naissent dans des endroits de plus en plus nombreux, mais nous manquons sérieusement de nombres sur les capacités de Linux dans des environnements et des configurations variées. C'est pourtant un point crucial. Dans de nombreux environnements, Linux est introduit à travers la réutilisation de PC (ce qui est en soi un point positif). Il existe cependant d'autres environnements où l'introduction de nouveaux matériels ou logiciels dépend de l'apport de nombres réalistes pour l'acquisition, le déploiement, la formation, la maintenance, l'infrastructure et la dépréciation des systèmes. Cela peut aller d'un petit bureau qui n'a réellement besoin que de sortir l'argent nécessaire à un institut financier qui a d'importants besoins en traitement de données et communications. Dans certains de ces domaines, Linux n'a probablement même pas touché quoi que ce soit car ces gens utilisent les ordinateurs comme un moyen pour parvenir à leur fin. L'ordinateur en lui-même n'éveille pas leur imagination. Ils ont des tâches à effectuer et l'ordinateyr est leur instrument pour accomplir ces tâches plus vite et plus précisément. Ce sont les environnements qui sont attiré par les sirènes de MS. Je connais cependant de nombreuses personnes qui travaillent dans des environnements Wintel très différents, et aucune d'elles n'est satisfaite. Quelques plaintes: Des blocages, bien entendu: les utilisateurs les plus demandeurs bloquent plus facilement leur PC, car ils utilisent tout un tas d'applications en même temps. Changements de configuration inexplicables: vous entrez dans votre bureau et votre application ne démarre pas. Raison: un fichier texte quelque part a été ramené à un état antérieur (j'ai eu ce cas de nombreuses fois avec le fichier services de TCP/IP). MS Office pour Windows 95: Word semble inutilisable pour des documents importants (c'est une plainte d'un utilisateur dans une société importante). Windows NT: ne peut pas être déployé dans des situations où les applications nécessitent des accès à du matériel ancien ou propriétaire. Je suis certain que quiconque a déjà utilisé le système connaît ses défauts. Je pense que l'une des raisons pour lesquels Linux n'est pas plus employé dans ces environnements est qu'il est principalement déployé en utilisant un seul type de configuration: processeur Intel 32 bits, architecture PC-AT, sous-système disque IDE ou SCSI, interface réseau Ethernet et périphériques série standards. Cela en fait un système très facile à utiliser dans les cas suivants: courrier électronique news (nntp) web (http) systèmes de fichiers impression MPP (Beowulf) systèmes embarqués stations de travail télécommunications systèmes en réseau et distribués Ce sont des solutions techniques pour des problèmes techniques, implémentées par des techniciens. Par contre, dans certains cas, des pièces manquent et il existe des cas où Linux pourrait être utilisé, mais où il n'y est pas. Le degré d'utilisation de Linux dépend encore beaucoup trop du niveau de compétences techniques de l'utilisateur. Cela ne devrait pas être nécessaire. Des sociétés devraient être capables de déployer Linux rapidement, efficacement et sans rencontrer de défauts. Des formations d'introduction à Linux devraient être fournies. Cela signifie essentiellement passer d'une connaissance Windows à une connaissance Linux. Les gens devraient être amenés à comprendre qu'il existe trois coussins dans l'utilisation d'un systême informatique et/ou d'un programme: l'utilisation l'administration la maintenance Au niveau du système, ceux-ci devraient être intégrés de façon transparente et étroite. Un utilisateur ne devrait pas avoir à chercher dans des tas de papier et de manuels pour trouver quelque chose rapidement, donc l'approche par menus est certainement la meilleure réponse à ce point, accompagnée d'une bonne aide sensible au contexte. Je pense même que du point de vue de l'utilisateur, les choses devraient être accessibles depuis un entête 'Applications', où tous ses programmes de production devraient résider, et un entête 'Maintenance' où se trouvent les programmes opérationnels, administratifs, de maintenance système ou de diagnostic. Si nous voulons que les systèmes Linux soient plus utilisés dans des environnements où les gens gens ne sont pas concernés par leur ordinateurs en soi, mais comme un moyen de faire leur travail, alors le support devra grandir à plusieurs niveaux. Afin de montrer ces niveaux, je vais présenter des études de cas plus ou moins détaillées. Ces cas présentent des environnements où j'ai travaillé, des clients qui avaient besoin de support, ou des gens que je connais. Cas 1: L'environnement SOHO (Small Office/ Home Office) Par là je pense à la société de la taille d'une famille, qui fournit des service de base (épicier, plombier, tapissier, etc.). Au moins deux personnes sont en charge de l'administration. Celle-ci consiste essentiellement de deux parties: comptabilité et prise en charge des messages entrants ou sortants. La première partie du problème est de fournir à cet environnement un paquetage de comptabilité approprié qui est utilisable dans le pays où la société est établie. La deuxième partie du problème est de prendre en charge tous les messages entrant et sortant. Ceci nécessite l'accès à trois canaux: le téléphone, le fax, et le courrier électronique (s'il existe d'autres options elles sont certainement hors de prix pour cet environnement). Suivant la situation, il peut y avoir des contraintes sur l'utilisation des canaux (par exemple aucun canal ne doit bloquer un autre canal, lorsque l'on répond au téléphone le fax et le courrier électronique ne doivent pas être gênés et/ou se gêner l'un l'autre). La configuration pourrait certainement être étendues en utilisant une carte autocom dans le système, pour fournir des services de téléphonie étendues par l'intermédiaire de Linux. Que cela vous plaise ou nous, ces gens se sont habitués à utiliser des traitements de texte et des tableurs WYSIWYG, donc le moins qui puisse être fait est de leur fournir cette fonctionnalité. Il existe au moins deux bons paquetage disponibles sous Linux pour cela. Une autre chose qui doit être fournie est une base de données de la clientèle qui est étroitement liée avec le paquetage précédent. Créer de nouveaux documents et utiliser des documents avec des champs provenant d'une saisie d'utilisateur serait un must. La création et l'insertion de graphiques simples devrait être une option disponible, aussi. Si nous considérons deux personnes au plus, le système devrait être configuré avec deux stations de travail de la même capacité, où certaines tâches sont distribuées entre chacune d'elle, ou avec un système plus puissant, qui fournit tous les services, et une station de travail PC bon marché, configurée en tant que serveur X (c'est-à-dire limitée à l'affichage, NDT). Cas 2 : Une société de taille moyenne I (10 utilisateurs) Services de fichiers et d'impression, comptabilité, inventaire La compagnie où j'ai travaillé pour la première fois de 1990 à 1991 avait un système Novell Netware. Nous utilisions le système pour fournir des services d'impression aux systèmes Mac et PC, comme zone de stockage pour toutes sortes de pilotes et de logiciels de diagnostic et comme base de données partagées par le programme de contrôle de la comptabilité et de l'inventaire. Toute personne qui avait besoin d'avoir accès au réseau avait son propre PC ou Mac. Nous utilisions majoritairement le DOS à cette époque, quoiqu'avec l'introduction de Win 3.0 un petit nombre ait migré vers cette version. Tout le monde avait accès à un téléphone et il y avait un fax central dans le service administratif. Nous installions et maintenions des PC et des Mac pour des applications graphiques. Ces applications fournissaient des sorties pour des imprimantes à mise en page (essentiellement via PostScript) ou des traceurs. Les applications supportées étaient Adobe Photoshop, Aldus Pagemaker et AutoCad. Nous étions également revendeurs du paquetage de comptabilité utilisé sur le réseau. Les impressions pouvaient être spoulées vers plusieurs imprimantes laser de grande capacité, une imprimante matricielle à grande vitesse et une lynotype. Les services de partage de fichiers sous Linux constituent probablement le plus simple des problèmes. J'ai installé en réseau, recompilé, lié et démarré un petit réseau TCP/IP utilisant deux ordinateurs en moins d'une heure. NFS est très complet, comme le sont telnet et les autres services TCP/IP. Si vous n'avez besoin que de fournir un serveur central, les points suivants doivent être accomplis: affecter des numéros de réseaux distincts à vos cartes réseaux, configurer le serveur et les stations de travail pour NFS, configure le fichier exports. Pour les stations de travail des utilisateurs, les points suivants doivent être accomplis: affecter des numéros de poste différents à chaque poste de travail, configurer NFS ajouter votre répertoire réseau au fichier fstab. La principale différence entre Novell et NFS se situe dans l'administration. Dans un serveur Novell, toute l'administration est centralisée dans le serveur. La seule opération nécessaire sur une station de travail est de charger un pilote IPX au démarrage. Sur une station TCP/IP, une partie de l'administration est centralisée et une autre partie de l'administration est délocalisée. Cela rend le processus de maintenance et de mise-à-jour dy réseau plus laborieux. Installer des services d'impression sous Linux est généralement plus difficile que sous Netware. Ceci vient du fait que tous les paramètres doivent être ajoutés à la main dans le fichier printcap en utilisant un éditeur de texte. Mais, puisqu'il s'agit d'un fichier très structuré, avec un jeu de commande relativement réduit, pourquoi personne n'a-t'il jamais écrit un système interactif qui lirait printcap, présente à l'utilisateur une vue d'ensemble des imprimantes disponibles et la possibilité d'ajouter et de modifier des imprimantes et leurs paramètres? Cela constituerait un grand pas en avant pour l'installation des imprimantes. Des filtres pour les différents types d'imprimantes pourraient aussi être présentés, de façon à ce que la configuration sur le réseau soit simplifiée (RedHat fournit un tel système). L'autre partie de la gestion des impressions est la manipulation des files d'attente. Le système lpd ne fournit un contrôle que par une interface en ligne de commande. Mais puisque ce système est aussi compris de façon précise, pourquoi n'y a-t'il pas eu d'essai pour réécrire le système lpd pour une manipulation via des menus? Après tout, saisir une commande ou enfoncer une touche de fonction peuvent entraîner le même comportement. Toutes les files d'attente et les imprimantes peuvent être présentées à l'utilisateur, avec la possibilité de fournir plus de détails. Le programme de comptabilité était écrit en Clipper et n'utilisait pas Btrieve. Cela signifie que tous les accès aux données dans les fichiers généraient un traffic important sur le réseau. Celui-ci était allégé en segmentant le réseau en trois parties de façon à ce que le service de comptabilité n'interfère pas avec les autres services. Le paquetage entier fonctionnait sous DOS. Au fil des ans, la compagnie qui avait programmé le paquetage a réalisé la transition de Clipper vers FoxPro en 1994, et ce n'est qu'en 1997 qu'ils ont réalisé la transition de DOS vers Windows (la version DOS étant toujours vendue et supportée). Cela nous présente un cas où l'on peut fournir du support pour la migration des dialectes xBase vers Linux, tout en ajoutant de la valeur à ces langages par l'apport transparent du client/serveur. Il devrait également exister du support pour les gens qui migrent de ces systèmes basés sur le DOS vers Linux. Il existe un nombre important de programmeurs indépendants, isolés, qui vivent en écrivant et maintenant de petites applications de base de données pour les utilisateurs SOHO (en utilisant xBase et de nombreux outils 4GL qui tournent sous DOS). Fournir des incitations et du support pour que ces personnes migrent, et aider leurs clients à migrer, pourrait fournir un double bénéfice à Linux. La clé réside bien entendu dans le fait que le support pour ces outils ou que des outils de conversion, deviennent disponibles sous Linux. Imprimer sous Un*x, et donc sous Linux, a toujouts été fortement orienté vers la mise en page. Fournir un support Postscript ne devrait pas être un problème sous Linux. Ajouter une lynotype devrait être aussi simpe que d'installer une imprimante sur un serveur ou sur le réseau via un serveur d'impression. Il existe d'ores et déjà des paquetages graphiques puissants disponibles sous Linux. Dans ce cas, la migration est une question d'être capable d'importer et/ou de convertir des fichiers graphiques et de montrer à l'utilisateur comment réaliser les tâches qu'il effectue habituellement sous la nouvelle application. Le tracé graphique et/ou la découpe devrait être la même chose que l'impression. Le logiciel applicatif est responsable de la traduction de sa propre base de données interne de dessin vers un format qui puisse être compris par le périphérique destinataire. Cas 3: Le bureau d'étude Stations de dessin, base de donnée centrale, verrou de dessin, statistiques d'utilisation Les bureaux d'étude constituent un cas où le réseau et le stockage central d'informations sont réellement mis à l'épreuve. Un tel service consiste en une base de données de dessin, qui est une application d'interface vers les programmes de dessin. Les utilisateurs doivent être capables de regarder des dessins, créer, éditer, supprimer et imprimer des dessins et obtenir des statistiques sur les dessins. De plus, un seul utilisateur doit être capable d'éditer un dessin ou partie d'un dessin à un instant donné, et l'on doit être capable de voir qui est en train d'éditer quoi. Si tout ceci ressemble à l'utilisation d'un système de fichier, vous êtes en plein dans le mille. La différence est que vous n'utilisez qu'un seul type de fichier. J'ai travaillé sur un système dans ce cas. Il était écrit en utilisant Clipper comme interface pour la base de donnée. Je connais d'autres systèmes où AutoCad est utilisé, mais sous un réseau Windows NT, et il existe des sociétés qui fournissent des solutions clefs-en-main complètes, composées de minis puissants et de stations de travail propriétaires pour les travaux de dessins de très haute qualité. Fournir des incitations à migrer vers Linux consiste à fournir un serveur puissant avec une capacité de stockage importante pour pouvoir contenir tous les dessins, et un réseau rapide pour fournir ces documents aux stations de travail. Celles-ci doivent toutes être ajustées au maximum pour fournir ce qu'il y a de mieux en matière d'affichage et de manipulation. Bien entendu, des utilitaires sont nécessaires pour convertir la base de donnée originelle et tous les dessins. La mise en réseau doit être sans faille, et le programme qui charge les dessins doit fournir une indication du temps nécessaire pour obtenir le fichier et quel est son état d'avancement. Cas 4: Une société de taille moyenne II (20 utilisateurs) Système à base mini, saisie de données et interrogation, service commercial Ceci correspond à mon emploi précédent: une petite société de transports, qui avait décidé il y a dix ans d'implémenter un système informatique afin d'automatiser de nombreuses tâches et de conserver une base de données de tous les transports effectués. Ils avaient pris WANG VS, qui était alors un système qui avait du succès, avec de nombreuses fonctionnalité avancées. Des logiciels spécifiques avaient été développés par une société extérieure dans un premier temps, et plus tard par un programmeur en interne. Le système contient un paquetage de fax très complet, qui peut être utilisé par n'importe qui, mais avec des fonctions de sécurité puissantes. Tous les messages sortants sont placés dans une file d'attente, où l'opérateur peut changer leur heure ou leur priorité d'émission. Tous les communications avec le mini s'effectuent par des terminaux ou par des cartes d'émulation dans les PC. La comptabilité est aussi effectuée par le mini, mais les deux systèmes ne sont pas liés entre eux. Le système est aussi équipé avec une tâche de fond qui contrôle les traitements par lots dans une file d'attente. Il existe encore de nombreuses sociétés de taille moyenne qui utilisent des minis et qui ont un problème pour s'en débaraseer, dû à leurs logiciels hautement spécialisés. La migration d'un système Un*x vers un système Linux ne devrait pas poser autant de problèmes que la migration d'un système entièrement propriétaire vers Linux. Le problème principal avec ces systèmes à base de minis est leur coût de maintenance élevé. Cela devrait constituer la raison la plus importante pour migrer, quoique Y2K (le bug de l'an 2000) puisse aussi constituer une incitation (ce n'est pas le cas avec WANG VS, qui est entièrement compatible an-2000). Pour fournir les mêmes fonctionnalités, un paquetage DBMS devrait être disponible, comprenant un dictionnaire de données, un paquetage de dessin d'écran, et un compilateur COBOL 74 avec un préprocesseur permettant de traduire des requètes SELECT simples depuis SQL. Il existe plusieurs paquetages de ce type. Un paquetage aide à migrer depuis WANG PACE (le système de base de données relationnelles de WANG) vers ORACLE (pour l'instant Oracle n'a fait qu'annoncer le portage d'Oracle vers Linux), tandis que Software AG a des outils pour porter les applications WANG PACE et leurs écrans vers ADABAS. Pour la partie compilateur, là où je travaille actuellement le portage est effectué de WANG vers HP-UX en utilisant le Cobol de Microfocus. Les fonctions de sécurité de la base de donnée devraient au moins comprendre la récupération de données par rollback (en rejouant les transactions effectuées depuis la dernière sauvegarde saine, NDT). Le système de fichiers fourni ne devrait absolument pas être e2fs. La sécurité devrait primer sur la rapidité. Lorsque le courant est coupé le système de fichier lui-même peut être abîmé, mais ces dégats devraient être simples à réparer. Les dégats dans les fichiers de transaction devraient être réparés avec l'option de rollback. Du point de vue du matériel, j'ai noté que SCSI-2 fournit suffisamment de vitesse pour supporter environ 20 utilisateurs, mais... ceci était vrai sur un système avec un processeur d'E/S spécialisé pour effectuer tous les transferts de données entre la mémoire principale et tous les périphériques. Pour savoir comment Linux se comporte sur ce point, des tests devraient être effectués, et les résultats publiés. Dans notre dernière configuration (processeur à 50MHz avec 64Mo de mémoire vive), sous une charge importante, le temps de réponse était inférieur à 10s. Le support du fax doit être fourni non seulement pour les applications interactives, mais aussi pour les applications de traitement par lot. Le traitement par lots de toutes les tâches doit être fourni. Certains programmes peuvent être démarrés, utilisés pour entrer des données de sélection, puis lancés à volonté en tâche de fond ou de premier plan à une heure et un jour que l'utilisateur peut saisir. cron est bien pour les gens à haut niveau de compétences, mais pas pour l'employé chargé de la saisie de données, donc vous avez besoin d'une interface qui demande la date, l'heure, et le taux de répétition du programme. L'application elle-même devrait être capable de fournir les paramètres requis. Cas 5: OEM Caisses enregistreuses, contrôle d'inventaire, matériel propriétaire Cette société construit des systèmes de caisses enregistreuses en utilisant essentiellement du matériel classique pour PC et une pièce propriétaire qui s'interface avec un lecteur de carte magnétique, un lecteur de codes à barres, un tiroir-caisse et un clavier/afficheur/imprimante de prix. La caisse enregistreuse est connectée via un réseau à un serveur qui fournit un inventaire et une liste de prix. Au démarrage, la caisse-enregistreuse se connecte au réseau et charge son système d'exploitation depuis le serveur. Chaque serveur a la possibilité de se connecter la nuit à une base de données centrale pour mettre à jour ses listes de prix et pour commander les produits qui sont à cours de stock. Pour la caisse-enregitreuse, un système d'exploitation multi-utilisateur, multi-tâches est clairement bien plus qu'il ne faut; elle pourrait bénéficier du multi-thread, néanmoins. En ce qui concerne le serveur, de nombreuses caisses-enregistreuses peuvent s'y connecter via le réseau. Le développement logiciel pour les serveurs et les systèmes intra-services est généralement fait avec des outils 4GL, en utilisant un langage de haut-niveau que pour les parties que 4GL ne supporte pas. Cas 6: Compagnie financière (environ 1000 utilisateurs, plusieursagences) Minis, mainframes, terminaux, stations de travail, TCP/IP L'environnement de production de cette compagnie est constitué de cinq minis WANG VS utilisés pour la saisie de données, le traitement de données et pour la connexion distante des agences à travers des lignes téléphoniques. Il comprend aussi un mainframe Bull avec deux processeurs, 128Mo de mémoire, 240Go de capacité de stockage en ligne, un système de gestion transactionnel comprenant une base de données mise en réseau, et un programme d'édition d'écrans et de routines. Tout ceci est contrôlé en utilisant JCL et COBOL-74. TCP/IP est implémenté entre tous les systèmes. Remplacer les minis par des systèmes Linux devrait être relativement simple. Puisqu'aucun PACE de WANG n'est implémenté sur ceux-ci, seule la migration des programmes en COBOL-74 derva être réalisée. La saisie des données et la connexion distante peut être réalisée en utilisant telnet et/ou des connexions séries. Transférer des données entre le mainframe et les autres système ne constitue pas un problème. Tout ceci est réalisé en utilisant FTP. Maintenant, pensons très GRAND! Pouvons-nous réaliser un système utilisant Linux qui puisse remplacer un mainframe, étant données les spécifications ci-dessus? Comme dit plus haut, plus de données et de tests sont nécessaires sur Linux et ses implémentations pour savoir à quel point il peut être réellement puissant. Cas 7: Logiciels pour personnes à haut degré de compétence, non-techniques Médecins, dentistes, avocats, chimistes, ... Ces cas ressemblent au SOHO, mais nécessitent des logiciels très spécialisés pour aider ces personnes dans leur travail. Ces logiciels sont pour la plupart écrits par des sociétés très spécialisées (logiciels de niche). De quoi auraient-elles besoin en terme de logiciel et maintenance pour être convaincues de migrer vers Linux? Une des réponses est sûrement qu'elle puissent migrer leurs applications existantes facilement et que la conversion de leur code source est assistée par des outils et des environnement de programmation qui fournissent les mêmes (ou de meilleures) fonctionnalités que leurs anciens outils. La configuration de ces systèmes devrait être plus spécialisée. Normalement l'utilisateur ne fera qu'utiliser son système (entrer des clients, interroger le système). Toutes les corvées administratives et de configuration doivent être laissées à l'implémenteur. Les applications elles-mêmes sont déjà aussi conviviales qu'elles puissent l'être, en raison de leur nature spécialisée. Conclusion J'ai présenté plusieurs cas du monde réel, où Linux pourrait à mon humble avis être utilisé. Dans la plupart de ces cas l'on trouve deux thèmes qui reviennent. Le premier est le besoin pour le support de migration d'autres plateformes vers Linux. Ce support peut être extrèmement varié, allant des compilateurs multi-plateformes pour migrations de bases de données, au remplacement d'applications écrites par les utilisateurs. Le second est le besoin de fournir une administration et une utilisation plus conviviale. Cela peut être fourni aussi bien à travers des boîtes de dialogue en mode caractères que par des systèmes à interface graphique. Dans tous les cas, leur accès devrait être plus centralisé. D'autres thèmes qui surgissent sont les suivants: Support amélioré des télécommunications à travers des paquetages plus complets pour le fax, et un support des autocommutateurs; Fiabilité améliorée (cas des bases de données, NDT); Données et tests de vitesse sur les applications et les configurations de Linux; Paquetages internationalisés pour la comptabilité; Système pour la gestion d'une base de clients, intégrée avec d'autres applications Copyright (C) 1998, Jurgen Defurne Adaptation française de Stéphane Alnet / Frédéric Gacquer / Nicolas Chauvat Page suivante Page précédente Table des matières