System i
Le serveur Application System/400 (plus connu sous le nom d'AS/400, puis de iSeries et enfin de System i5) est un mini-ordinateur de la gamme IBM.
Cet article ne s'appuie pas, ou pas assez, sur des sources secondaires ou tertiaires ().
Pour améliorer la vérifiabilité de l'article ainsi que son intérêt encyclopédique, il est nécessaire, quand des sources primaires sont citées, de les associer à des analyses faites par des sources secondaires.
L'AS/400 a été commercialisé le , il sera renommé eServer iSeries en 2000 puis System i5 en 2004 avec l'arrivée des modèles pourvus de processeurs POWER5. Qu'il s'agisse d'AS/400, de iSeries ou de System i5, l'ensemble des serveurs de cette famille a été nommé System i. Mais en , IBM a totalement fusionné les gammes System i et System p pour donner naissance aux IBM Power Systems[1].
Les serveurs System i intéressent principalement les PME et les sites atomisés des grands groupes.
Histoire modifier
L'histoire de l'AS/400 et du System i remonte à la fin des années 1960 avec Frank G. Soltis. Ce dernier travaille sur un système basé sur une technologie nouvelle. Il présente son projet à la direction d'IBM le . Cette nouvelle architecture devra remplacer l'actuel System/3. En 1972, sous le nom de Projet Future Systems, la conception du System/38 (S/38) débute avec à sa tête Frank G. Soltis, Dick Bains et Roy L. Hoffman. Ces derniers définissent les cinq concepts fondamentaux du S/38, qui deviendront plus tard ceux du System i (ex AS/400). En 1973, la direction d'IBM donne son accord pour la réalisation du System/38 avec l'annonce officielle le . Son système d'exploitation se nomme CPF (Control Program Facility). La première mouture du System/38, assez rudimentaire, sort en . Il faut attendre 1981 pour voir la version finale. Malgré des débuts prometteurs, le System/38 rencontre quelques problèmes de mise au point.
Entre-temps, le System/36 (S/36 [unité 5362]) est apparu (). Il s’agit d’un autre mini de la gamme IBM, mais avec une architecture beaucoup plus conventionnelle. L’équipe chargée de la mise au point du System/38, basée à Rochester dans le Minnesota, poursuit le développement de son système et décide d’y intégrer d'autres innovations. Avec l’accord de la direction, elle lance en , le projet Silverlake (du nom d’un lac de Rochester : Silver Lake). Il doit permettre à IBM de mettre sur le marché un serveur encore plus novateur que le System/38 et qui devra également remplacer le System/36. Le projet Silverlake est le début officiel de l'AS/400. Il découle directement du System/38, mais il sera plus fiable et sensiblement amélioré. Lors de sa sortie le , son système d'exploitation, l'OS/400 ou XPF (eXtended control Program Facility), sera une très forte évolution du CPF (système d'exploitation du System/38) auquel on aura agrégé l'équivalent de 3 versions.
Le nom du projet aurait dû être System/40 (S/40), mais la direction a préféré montrer qu'il s'agissait d'un serveur sensiblement plus évolué en le nommant Application System (AS). De plus, la branche PC d'IBM souhaitait réserver pour ses besoins, les chiffres inférieurs à 100. C'est pourquoi, il a été convenu d'ajouter un 0 au chiffre 40 et l'on a obtenu AS/400.
La naissance des AS/400 eServer puis iSeries verra apparaître la possibilité de « découper » plusieurs machines logiques (ou « machines virtuelles / LPAR (Logical Partitioning ») dans une machine physique. Puis, enchaînement logique, il est désormais possible de faire tourner d'autres systèmes que l'OS/400, ainsi que lui-même (permettant ainsi d'avoir plusieurs systèmes indépendants), sur ces machines logiques appelées partitions logiques. Ainsi aujourd'hui un « System i5 » peut supporter des partitions i5/OS, Linux, AIX ou Virtual IO Server grâce à son hyperviseur. Le serveur i5 est également capable d'héberger des serveurs x86 sous Linux, Windows ou VMWare ESX via les technologies IxS, IxA ou iSCSI. VMWare n'est supporté que sur iSCSI.
IBM a renommé ses machines iSeries puis System i5 mais la plupart des informaticiens, des utilisateurs et des SSII continuent à parler d'AS/400.
Le langage de développement rapide, d'origine issu de l'IBM 34, portait initialement le nom de GAP, pour Générateur automatique de programmes (RPG en anglais, pour Report Program Generator). Bien que concurrencé par la version iSeries du langage Cobol, le GAP était largement diffusé sur ce système OS/400. Considérablement amélioré sur AS/400, il y prit le nom de GAP/400 (RPG/400). Pour de plus amples renseignements sur le langage RPG, se reporter à l'article Générateur automatique de programmes. Avec l'apparition de la version V3R1M0 (1995), une nouvelle version du RPG est venue s'ajouter au RPG/400 (alias le RPG/III). Il s'agit du RPG/ILE (alias le RPG/IV) qui permet désormais la programmation orientée objet et la programmation visuelle. Le langage RPG est né en 1959 et se pratiquait sur les systèmes 3 (3/12 ; 3/15) ou sur IBM/360 (1965), un des premiers ordinateurs offrant une puissance de calcul importante pour une machine relativement petite (pour l'époque). Il était destiné aux entreprises et laboratoires.
Indépendance vis-à-vis de la technologie modifier
Le premier principe et peut-être le plus important est l’indépendance technologique. Le System i, contrairement aux autres systèmes, n’est pas défini par le matériel. Un programme ne parle pas directement au matériel, il dialogue à une interface machine indépendante de la technologie (TIMI = Technology Independent Machine Interface ou plus simplement MI). Entre cette interface et le matériel proprement dit se trouvent plusieurs millions de lignes de code ou plus exactement le microcode : SLIC (System Licenced Internal Code) sur les AS/400 ou iSeries et LIC (Licensed Internal Code) sur les System i5.
Cette couche logicielle isole les applications des caractéristiques du matériel sous-jacent. Un programme ignore totalement ce dernier. Par conséquent, quand la technologie processeur change, il suffit de réécrire le SLIC en fonction des changements technologiques et on préserve ainsi l’intégrité de l’interface machine. L’autre avantage de l’indépendance réside dans le fait que les programmes utilisateurs ignorent également les changements technologiques, ainsi, ils peuvent bénéficier des avantages sans les inconvénients. Lors du passage du processeur CISC 48-bits à RISC 64-bits, la plupart des clients n’ont eu qu’à transférer leurs programmes sur les nouveaux AS/400 pour les exécuter en 64 bits. Il ne s'agissait pas d'une émulation comme le font maintenant d'autres systèmes d'exploitation ou processeurs, la partie MI des applications a été remplacée automatiquement, elles sont devenues 64 bits en natif.
Conception basée objet modifier
Le System i (AS/400-iSeries-i5) est entièrement basé objet. Tous les éléments du système (programmes, fichiers, files de messages…) sont des objets. Chaque objet comporte deux parties inséparables : la partie descriptive, qui définit les modalités d’utilisation de ces données et la partie données, constituant l’aspect fonctionnel de l’objet. Si un objet est défini comme un programme, sa partie descriptive énonce que la partie de données sera traitée comme du code compilé, exécutable, en lecture seule. Les seules opérations admises sur cet objet sont celles « sensées » pour un programme. Ainsi, on peut écrire au milieu d’un fichier de données, mais pas au milieu de code compilé : le système s’y opposera. La conception en deux parties des objets du System i assure donc l’intégrité des données pour tous les objets du système.
Contrairement aux autres systèmes d’exploitation, qui manipulent des pointeurs, l’OS/400-i5/OS et le TIMI ne connaissent que des objets. Les pointeurs utilisés uniquement par le microcode ont une taille de 16 octets (8 pour l’adresse MI et 8 pour des informations relatives à l’objet et de l’espace réservé). Au-dessus du MI, les pointeurs sont encapsulés. Il existe également un mécanisme de détection, au moyen d'une balise, des pointeurs invalides et d’utilisation « illégale ».
La conception basée objet a d’importantes implications en matière de sécurité. En effet, les virus pénètrent souvent dans les systèmes déguisés en données. Une fois à l’intérieur, le virus essaie de devenir du code exécutable pour causer des ravages. Un tel changement de caractéristique est impossible sur System i. Si un flux entre en tant que données, il gardera toujours ces caractéristiques. C’est une des nombreuses raisons qui font la réputation en matière de sécurité et d’intégrité du System i.
Intégration Matérielle modifier
Alors que l’environnement informatique technique/scientifique privilégie le calcul (opérations complexes sur une quantité de données relativement petite), l’environnement informatique de gestion privilégie l’information (des opérations simples sur de gros volumes de données) ou plus exactement les entrées/sorties (I/O). Comme le System i est optimisé pour la gestion, il présente des caractéristiques matérielles lui permettant d’être très performant dans un environnement privilégiant l’information. Dans une transaction de gestion classique, un programme d’application est chargé en mémoire principale et le processeur commence à l’exécuter. Quand le processeur rencontre une demande de lecture de données sur disque, il délègue cette requête au processeur d’I/O (IOP) du disque. Après quoi, le processeur exécute un autre programme d’application et ne revient au programme original que lorsque les données demandées antérieurement sont disponibles en mémoire centrale.
Sur les plus gros System i, il est possible d'avoir des centaines de processeurs d'entrées/sorties (IOP) connectés aux bus haute vitesse, créant ainsi un débit de données extrêmement puissant.
La tendance actuelle est de faire disparaître l'intelligence de ces processeurs complémentaires en partie sur les cartes PCI traditionnelles.
Intégration Logicielle modifier
Aucun problème d’incompatibilité de version en raison de déphasage de programmes comme sur d’autres systèmes (avec les différentes versions de DLL par exemple). Tous les composants nécessaires sont entièrement intégrés dans le système d’exploitation standard. IBM teste tous ces composants mêlés aux autres, pour s’assurer que le système d’exploitation fonctionne comme une seule entité. De plus, quand IBM modifie l’OS/400-i5/OS, elle remet aux clients une nouvelle version de tout le système d’exploitation. Il n’y a donc jamais aucun conflit de version entre les divers composants de l’OS/400-i5/OS parce qu’IBM livre un système d’exploitation complet et entièrement testé à chaque nouvelle version. Les avantages de ce système d’exploitation hautement intégré sont évidents pour les clients : déploiement rapide des nouvelles solutions de gestion pour un coût remarquablement bas avec une sécurité maximum.
Espace Adressable Unique modifier
Il s'agit de la notion de mémoire virtuelle adaptée au System i.
Chaque octet de mémoire (principale et secondaire) possède une adresse. Le système considère l’ensemble comme unique. Un System i ne dit jamais « mémoire pleine » (sauf quand il ne dispose plus de mémoire secondaire), la seule conséquence étant les temps de réponse qui peuvent se dégrader à cause de la pagination. L’énorme espace d’adressage 64 bits du System i peut adresser 18 trillions d’octets de données (18 × 1018 soit 18 446 744 073 709 551 616 octets).
Notes et références modifier
- « Ibm as/400 quel avenir après la convergence avec la gamme Unix », sur zdnet.fr,
Voir aussi modifier
Bibliographie modifier
- Frank G. Soltis, Voyage à l'intérieur de l'AS/400 (titre original Inside the AS/400), D&S communications
- Frank G. Soltis Fortress Rochester — The inside story of the IBM iSeries
- Gary Mullen-Schulz, Blue Gene/L - “World's Fastest Supercomputer”
- Tuning IBM eServer xSeries Servers for Performances (SG24-5287)
- Bernard Coydon, AS/400, Éditions Eyrolles
- Dominique Gayte, Principes généraux et langage de contrôle, Éditions Eyrolles
- Dominique Gayte, DB2/400 - Gestion de la base de données AS/400, Éditions Eyrolles
