Par Jurgen Defurne.
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.
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.
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.
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.
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 :
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).
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.
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...
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.
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.
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.
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é.
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.
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é.
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 :
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.
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.
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 :
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.
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.
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.
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.
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.
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 ?).
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).
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 |
|_________________________________|____________________________________|
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