Appelez nous
06 37 24 45 79
07 60 46 31 69

AS/400

L’optimisation de performances AS/400 en 2017

L’optimisation de performances AS/400 en 2017

L’âge de pierre

Le sujet des performances AS/400(*) a évolué avec le temps. A l’âge de pierre de ce serveur (début des années 90), la problématique des performances était essentiellement centrée autour du tuning système. Les AS/400 n’étaient pas très puissant et optimiser les performances de ces serveurs consistait a optimiser le « tuning » du système. Immanquablement, la CPU n’était pas assez puissante, la mémoire était trop petite et les disques chauffaient !!!

On passait son temps à déshabiller Paul pour habiller Jacques…. Le moindre traitement non planifié comme un Query lancé en pleine journée pouvait mettre à genoux la machine.

On jouait avec les trois fameuses commandes :

  • WRKACTJOB pour savoir qui monopolisait la CPU.
  • WRKSYSSTS pour savoir comment la mémoire paginait.
  • WRKDSKSTS pour savoir comment travaillaient les bras de disques.


IBM nous fournissait des seuils à ne pas dépasser et si c’était le cas on devait organiser différemment l’ordonnancement des travaux ou bien demander au DSI de lancer un (coûteux) upgrade. Quelquefois, on était à la limite de puissance du serveur et l’upgrade était impossible….

Bien sur, les experts utilisaient le Performance Tool, outil qui collectait des données plus précises, mais l’interprétation des résultats était complexe. De plus le niveau de finesse de Performance Tools s’arrêtait au niveau Job. Ces derniers étaient essentiellement de deux types : 5250 pour les interactifs et Batchs pour les traitements de nuits ou de jour.

Les programmeurs utilisaient des techniques précises dans leur programme RPG, pour ne pas trop charger la machine (affichage de sous fichier dynamiques par exemple).

Les exploitants avaient toujours un œil sur le serveur et déclenchaient des alertes dès que le temps de réponse se dégradait.

L’architecture AS/400 bâtie par Frank SOLTIS permettait toutefois qu’un programme utilise toutes les ressources du système s’il était seul à s’exécuter.

Les performances AS/400 aujourd’hui

Des machines plus puissantes

Depuis 20 ans, la puissance des serveurs a considérablement augmenté. Les systèmes sont virtualisés en partitions. Chacune de celle-ci utilisent plusieurs CPUs. En cas de besoin, une partition peut prendre des cycles CPU à une autre. La mémoire réelle fait plusieurs Giga octets. L’espace disque fait souvent plusieurs Tera octets. Les caches mémoire et disques réduisent les accès disques.

Des applications plus complexes

Les connexions à ces serveurs sont de différents types : 5250, WEB, Client-serveur. Le système de fichier natif (PF et LF) est devenu une vraie base de données DB2 avec des contraintes, des triggers, un optimiseur, etc …

Des programmes anciens

Par contre, ce qui n’a pas ou peu changé, ce sont les programmes applicatifs métiers qui s’exécutent sur ces serveurs. Quand bien même on ait 8 CPU sur un serveur AS/400, si le traitement qui s’exécute est un programme batch

monolithique non parallélisé, celui sera long et peu performant.

En effet, au lieu d’utiliser l’ensemble des ressources du serveur, il n’en utilise qu’une infime partie souvent à cause d’une conception ancienne et non adaptée aux ressources d’aujourd’hui.

Ceux-ci ont souvent été développés sur des plates-formes ancêtres de l’AS/400 (S36 ou S38). Les personnes qui ont développé ces programmes sont souvent devenus soit chefs de projets ou bien sont partis à la retraite.

Des applications sensibles

A l’époque, documenter ses développements ne paraissait pas une nécessité et les réécrire aujourd’hui parait compliqué. D’autant plus que ces applications gèrent souvent les parties cruciales d’une entreprise, à savoir celles qui sont source de revenu : Gestion Commerciale, Compta, Facturation, Paie, Gestion des crédits etc…

Des informaticiens vieillissants

A ce constat il convient d’ajouter le phénomène suivant : Les programmeurs RPG ont vieillis et disparus en partie. Les nouveaux programmeurs utilisent des AGL de type ADELIA par exemple et codent leurs accès à la base en SQL. Au lieu de suivre une démarche algorithmique classique, le niveau de performance d’un programme devient complètement dépendant du niveau en SQL du programmeur. Bon niveau : Pas de problème. Niveau moyen : Aie Aie Aie ….dans ce cas l’optimiseur DB2 de l’AS/400 fait de son mieux mais quand la requête est tellement mal codée qu’elle passe son temps par exemple à scanner une table de plusieurs millions d’enregistrements, le temps de réponse peut-être de plusieurs dizaines de secondes.

Des équipes structurées à l’ancienne

Enfin les équipes d’informaticiens AS/400 sont souvent structurées à l’ancienne : Peu ou pas d’Ingénieur systèmes (IBM vendait l’AS/400 comme une machine tournant toute seule), une exploitation pilotée en partie par des programmeurs dont très peu savent vraiment comment fonctionne le serveur, une quasi absence de DBA, des intervenant techniques (sur Websphere par exemple) qui n’ont qu’une vision très partielle du serveur…
La conséquence de ceci, c’est que peu de personnes savent utiliser les outils qui pourtant ont été développés et perfectionnés par IBM pour faire du diagnostic de performance (System Director, iSeries Navigator, Performance Tool, iDoctor-Job Watcher, iDoctor PEX Analyzer, Trace SQL DBMON, SQL Plan Caches, Visual Explain, Heap Analyzer ….).

Une méconnaissance des outils

Et lorsque quand bien ces outils sont utilisés, ils sont utilisés comme outil statistique mais pas comme d’outil d’analyse. Qui n’a pas vu ces merveilleuses courbes de charge CPU, très jolies dans des présentations mais complètement inexploitables pour expliquer pourquoi la CPU est chargée à une certaine heure ? Au mieux, il est possible d’incriminer un traitement (donc souvent un programmeur) mais personne n’est capable de lui expliquer ce qui ne va pas.
De leurs cotés, les équipes de développement tentent bien d’optimiser leurs traitements mais sont souvent inefficaces. En effet elles optimisent une partie du code qui marchait bien et peuvent gagner 3 dixièmes de secondes là ou il aurait fallu gagner 10 secondes. Des précisions techniques sont demandées aux exploitants mais ceux-ci sont bien incapables de les donner.

Un aveu d’impuissance

En réunion sur ces sujets, tout le monde s’exprime en ayant une idée sur la question, mais la réunion se termine souvent , non pas par un plan d’action précis, mais par un aveu d’impuissance.

Le chaînon manquant

Ce qui manque aux deux équipes pour traiter efficacement ce type de problème a un nom : Le diagnostic.

Avant de bâtir une solution il faut d’abord diagnostiquer avec méthode et précision ce qui se passe.

Il faut savoir par exemple répondre en détail aux questions suivantes :

  • Pourquoi le temps de traitement est long ?
  • Ou perd-on du temps ?
  • Quelle partie du code charge la CPU ?
  • Pourquoi l’optimiseur DB2 a -t il décidé de reconstruire un index dynamiquement ?
  • Pourquoi le programme X balaie t il la table Y séquentiellement, etc. ….

Le choix du bon outil

Avec les outils standards IBM listés plus haut, il est possible de faire un diagnostic précis de ce qui se passe dans le système ou dans un traitement. Il faut par contre utiliser les bons outils en fonction de la problématique à résoudre : Trace SQL si on veut optimiser les accès DB2, Trace PEX si on veut décomposer le temps de traitement d’un job et le ventiler par programme ou sous programmes, IDoctor Job Watcher si on veut isoler les problèmes de verrouillages, System Director si on veut diagnostiquer des problèmes de configuration de partitions…..

Conclusion

Aujourd’hui, c’est autour des applications qu’il faut travailler l’optimisation, plutôt que le tuning du système comme par le passé…

Méthodologie EFFSYS

L’approche générale doit être de type Top / Down.

Identification

Face à un problème de performance identifié, il convient d’abord de comprendre le problème tel qu’il est exposé par l’exploitant, l’utilisateur ou parfois le programmeur. S’il y en a plusieurs, il faut les prioriser.

Analyse Setup Système

Il faut ensuite reproduire (ou essayer de tracker) le problème tout en se mettant en mode surveillance.

Au moment du problème, il convient de vérifier la charge générale du serveur (charge CPU, mémoire, disques, jobs) et en contrôler son setup (Taille des partitions, Puissance CPU, taille Mémoire, Nombre de disques, Espace disponible, valeurs Systèmes, Job Descriptions, Sub-System Description etc. …. ).

Trace

En parallèle, il faut choisir l’outil qui va bien en fonction de la problématique à traiter (voir ci-dessus).

Ensuite il s’agit de lancer le/les outils de collection avec un paramétrage adapté. Ainsi par exemple on peut ne tracer que les requêtes SQL d’un job précis, ou bien on peut ventiler le temps d’exécution que sur un seul job.

Analyse des résultats

Cette phase est la plus complexe. Elle consiste pour l’expert performance, sur la base des données collectées, à comprendre ce qui se passe et surtout à traduire ce qu’il voit dans les collectes en quelque chose qui soit compréhensible par les exploitants, les développeurs ou le DSI.

Par exemple : Le temps de traitement est long car lorsque que telle requête SQL démarre, l’optimiseur DB2 ne trouvant pas en base d’index pour l’aider, décide de recréer un index dynamiquement.

Une fois que le diagnostic précis est fait sur la compréhension d’un temps trop long , alors seulement on peut entrer dans la phase de recherche de solutions techniques pour remédier au problème.

Recherche et proposition de solution

L’expert EFFSYS propose des solutions techniques qui sont validées ou pas (en fonction d’autres critères parfois comme la sécurité ou l’intégrité des données) par l’équipe client. Parfois, le diagnostic précis étant fait, les équipes du client proposent elles mêmes des solutions. Il nous est arrivé qu’un programmeur nous dise : On perd du temps dans une partie du traitement dans un module qui ne sert plus à rien aujourd’hui par exemple.

Idéalement, l’expert EFFSYS doit pouvoir aussi estimer le temps qui sera gagné par telle ou telle optimisation.

Contrôle de l’impact de l’optimisation

La dernière phase, et pas de la moindre importante, consiste, une fois l’optimisation mise en place à mesurer le traitement à optimiser (toujours avec les outils IBM standards listés lus haut), pour valider que l’optimisation proposée est bien positive.

En général ce type de mission se déroule en 2 ou 3 semaines, en fonction du nombre de problèmes de performance à traiter.

On emploiera dans ce document le terme générique AS/400 pour parler des : AS/400, iSeries, i5 et « IBM i ».
Virtualisation sur système iSeries

INTRODUCTION

L’AS/400 est né il ya plus de 20 ans déjà !!! Il a ensuite été remplacé par l’iSeries puis par le System i5 en 2004. En 2008, IBM a rationalisé sa gamme en produisant une nouvelle gamme de hardware : Les Power Systems qui permettait un support des System i (ex AS/400) et des System p (ex RS/6000).Tous les serveurs de cette nouvelle famille étaient pourvus de processeurs POWER6 et maintenant des processeurs POWER. Ce serveur peut héberger différents systèmes d’exploitation et notamment le nouveau système d’exploitation de l’AS/400 est le « IBM i operating system ».Une des principales fonctionnalités apportées par le nouveau système « IBM i » est le support de la virtualisation.

UN PEU D’HISTOIRE

La virtualisation n’est pas une nouveauté chez IBM. Dès la fin des années 70 , IBM à distribué le système d’exploitation VM (comme Virtual Machine) qui tournait sur les plate-forme Mainframe de type 308x.IBM a développé VM/CMS, un operating système qui d’un coté gérait le hardware, et de l’autre permettait de définir plusieurs machines virtuelles de type DOS/VSE ou MVS. L’idée de base était de faciliter les migrations de ses clients de DOS/VSE (moyen systèmes) vers MVS (grands systèmes).Ayant vite compris la puissance et la souplesse de ce nouveau concept de nombreux clients gardèrent VM/CMS installé en Production une fois la migration terminée. Au début des années 80 il n’était pas rare de trouver VM/CMS utilisé en production avec différentes machines virtuelles de type DOS/VSE ou MVS attachées. Ceci leur permettait notamment de ne pas avoir à migrer certaines vielles application de VSE vers MVS. On parlait déjà à l’époque de partitions VSE ou de partition MVS tournant sous VM.

LA VIRTUALISATION SUR L’AS/400

Sur AS/400, la virtualisation est apparue au milieu des années 90, avec tout d’abord la virtualisation des environnements Windows et OS/2 sous forme de serveurs intégrés, puis avec l’apparition du partitionnement logique (LPAR).Au fur et à mesure des versions, de nouvelles fonctions de virtualisation sont venues enrichir la plateforme :

  • intégration d’un hyperviseur- virtualisation du processeur et de la mémoire
  • virtualisation des cartes PCI
  • virtualisation des environnements Linux- virtualisation des environnements AIX
  • intégration de l’espace de stockage sur des baies de disque IBM / SAN (ESS800, DS6800 et DS8x00)
  • cartes réseaux et fonctions TCP/IP virtuelles

Toutes ces fonctions, largement utilisées depuis de nombreuses années sur la plateforme System i, contribuent d’une part à l’amélioration des performances et de la disponibilité des serveurs et d’autre part à la réduction des coûts des environnements.Avant avril 2008, la virtualisation IBM sur processeur POWER n’avait pas de nom particulier malgré l’étendue de ses possibilités et son extrême sophistication. Le service marketing d’IBM a probablement considéré qu’il y avait un manque de ce côté. Désormais, le composant de virtualisation sur plateforme POWER se nomme : PowerVM.Il contient de nombreux composants, offrant ainsi aux systèmes d’exploitation supportés (AIX, Linux et IBM i), des fonctions de virtualisation extrêmement poussées. IBM i, dans sa version 6.1, a largement bénéficié des capacités de PowerVM, proposant ainsi à ses utilisateurs une palette de nouvelles fonctions très souple à mettre en œuvre.

AUJOURD’HUI

Héritière des AS/400, la gamme de solutions IBM i profite de la forte fidélité des clients envers cette plateforme. Les banques, la grande distribution, les assurances, les opérateurs de télécom, les métiers du transport et de la logistique, continuent notamment d’afficher leur confiance en la sécurité, la fiabilité, la robustesse ainsi que la facilité d’administration et d’exploitation de ce système.Les DSI, qui exploitent historiquement leur informatique sous IBM i, continuent de soutenir et de conserver cette plateforme parce qu’ils en comprennent l’intelligence, l’intégration et la puissance. Certains de ces clients maintiennent ainsi un historique de plusieurs dizaines de milliers de programmes utilisés en production.Aujourd’hui, la majorité des grandes entreprises a virtualisé son infrastructure. Celles de moindre taille commencent à le faire ou l’ont également déjà fait. Le taux de pénétration de la virtualisation tourne autour des 30%. La phase suivante consistera à augmenter ce taux pour aller vers le « cloud computing ». Le PowerVM offre aujourd’hui toutes les possibilités de virtualiser l’ensemble des plateformes iSeries sous forme de partitions.

LES COMPOSANTS DE POWER/VM

Power/VM contient tous les dispositifs permettant une virtualisation complète et efficace des systèmes i :

  • POWER Hypervisor : L’hyperviseur en charge de la répartition des ressources matérielles. Il gère et répartit les ressources processeur, mémoire et cartes PCI sur les différentes partitions hébergées par le serveur POWER.
  • Micro-Partitioning (Micro-Partitionnement) : Cette fonction permet de partager un processeur et donc créer des partitions sur des portions de processeur. Le minimum supporté est de 1/10ème de processeur, ce qui permet de créer jusqu’à 10 partitions par processeur avec une granularité au 1/100ème de processeur au dessus du minimum.
  • Uncapped Processor (Processeur débridé) : Possibilité de « débrider » la capacité processeur allouée à une partition en exploitant les cycles processeurs non utilisés par les autres partitions.
  • Dynamic Logical Partitioning : Fonction permettant de déplacer dynamiquement les processeurs, la mémoire, la capacité interactive et les ressources I/O (cartes PCI contrôleur bande, Ethernet, communication …) entre les différentes partitions.- Multiple Shared Processor Pools:Possibilité de créer plusieurs groupes de processeurs partagés afin de les « dédier » à des environnements particuliers. Cette fonction permet également de réduire les coûts des licences nécessaires aux différents Operating Systems en restreignant leur champ d’action.
  • Virtual I/O Server : VIOS est un Operating System basé sur AIX, offrant des capacités de virtualisation à d’autres partitions. Une partition Virtual I/O Server peut virtualiser les environnements AIX et Linux POWER mais également IBM i. VIOS fournit des ressources I/O virtuelles (disques, adaptateurs réseau, lecteurs de bandes et lecteurs optiques) pour des partitions dites clientes.
  • Integrated Virtualization Manager (IVM) : Il s’agit d’une interface de gestion des partitions et des ressources virtuelles disponible via un navigateur Web, fournie par Virtual I/O Server. IVM permet de créer des partitions intégralement virtualisées sans console HMC.
  • PowerVM Lx86 (Lx86) : Lx86 est un logiciel de translation binaire x86 permettant d’exécuter des applications Linux x86 32-bit sur des processeurs d’architecture POWER sans recompilation.
  • Live Partition Mobility (LPM) : Cette fonction permet de déplacer à chaud, c’est à dire sans interruption de production, une partition d’un système vers un autre système physique.
  • N_Port ID Virtualization (NPIV) : Fonction permettant de virtualiser les cartes Fibre Channel

LA PARTICULARITE DU MARCHE iSERIES

Une énorme inertie de la base installée :

La principale caractéristique du System i est qu’il s’appuie sur une base installée très importante.

La facilité de mise en œuvre et la fiabilité du System i sont jugées réelles mais ne sont plus déterminantes pour le choix de conserver ou non cette solution.

La principale raison pour laquelle les clients conservent leur System i est que les applications métiers résultent de développements spécifiques et volumineux. A 90%, les applications sont écrites en RPG, ce qui veut dire qu’un changement de plateforme peut conduire à la réécriture de dizaine de milliers de programmes, et représentent donc un cout de projet tellement élevé, que celui-ci est en général vite enterré.La solution de virtualisation permet donc d’évoluer vers une architecture d’infrastructure moderne, puissante et souple tout en évitant des couts de migration trop élevés.

Arcad Software

Arcad Software propose une suite logiciel unique et originale pour les équipes de développement, avec notamment une gestion du changement puissante et riche de fonctionnalités.

Effsys sign up form


Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur excepteur sint occaecat cupidatat non

Effsyslogin form