Cet ouvrage fait partie de la bibliothèque YouScribe
Obtenez un accès à la bibliothèque pour le lire en ligne
En savoir plus
ou
Achetez pour : 90,00 €

Lecture en ligne + Téléchargement

Format(s) : PDF

sans DRM

CMGF' 92 La gestion optimale des systèmes d'information. Vers la maîtrise des systèmes ouverts. Actes du 5e congrès

De
428 pages
...
Voir plus Voir moins

f
CMGF 92
Actes du
cinquième congrès
La gestion optimale
des systèmes
d'information
Vers la maîtrise des
systèmes ouverts
HERMES CMGF 92 CMG F 9 2
Actes du cinquième congrès
CMGF
La gestion optimale
des systèmes d'information
vers la maîtrise des systèmes ouverts
24 - 26 novembre 1992
Pullman Saint-Jacques
Paris
HERME S èm eLe V Congrès
est organisé
par l'Association CMGF
11, rue du Faubourg Poissonnière - 75009 PARIS
Tel: (1) 42 46 00 22 - Fax : (1) 42 46 00 14
CMGF
© CMGF 92, Editions Hermès, 1992
Editions Hermès
34, rue Eugène Flachat
75017 Paris
ISBN 2-86601-336-0 L'association CMGF
Au cours de ces dernières décennies, l'essentiel de l'activité informatique a consisté à
installer des matériels de plus en plus puissants et sophistiqués afin de suivre une
demande en rapide augmentation et diversification.
Dès maintenant et dans les années à venir, son impératif sera de gérer au mieux un parc
stabilisé. C'est pourquoi le CMGF, créé en 1988 autour du thème de la performance,
élargit maintenant son axe principal à la :
GESTION OPTIMALE DES SYSTÈMES INFORMATIQUES
Le CMGF se propose d'être un forum permanent et un fédérateur de la profession :
utilisateurs, fournisseurs de logiciels et de progiciels, constructeurs, prestataires de
services, enseignants et chercheurs.
Il développe ses activités selon trois objectifs complémentaires.
Evolution de l'état de l'art, de la technique et de la pratique dans tous les domaines de
la gestion optimale des systèmes informatiques : automatisation, gestion, contrôle et
mesure des réseaux, optimisation des ressources, contrats de service, stockage,
performance et modélisation, architecture, bases de données...
Echange d'expériences autour de l'utilisation et du développement des méthodes et des
techniques employées,
Identification des difficultés et préoccupations, constatation des solutions et des actions
préconisées.
Ces objectifs s'expriment à travers :
Le congrès annuel regroupant les principaux acteurs dont les fonctions impliquent les
problèmes de planification, de mesure, de contrôle et de pilotage des systèmes
d'information.
Les groupes de travail se réunissent tout au long de l'année. Quatre groupes sont
aujourd'hui très actifs : automatisation, mesure de la performance, gestion des réseaux
et bases de données.
Le fonds documentaire permet une large diffusion des informations et des expériences
par la mise à disposition d'articles et d'ouvrages et de management.
Le CMG dans le monde.
Le CMGF s'inscrit dans la ligne des autres CMG mondiaux : Australie, Bénélux, Brésil,
Canada, Centre Europe, Etats-Unis, Grande-Bretagne, Italie. L'ensemble des CMG
regroupe aujourd'hui quelques 6 000 professionnels de l'informatique avec lesquels des
relations privilégiées se sont instaurées. LE S PARTENAIRES DU Vème CONGRES
SYSTEMS FRANCE BGS as
SOFTWARE
Boole &. iCandle Babbage
Europe Unking your systems perform
(AOMPUTER EMC
ASSOCIATES
TH E STORAGE
Software superior by design ARCHITECT S
II///////// / / /
LEGENT M
SAS Institute s.a
STERLIME
SOFTWARE 'ôllQOô
SYSTA R L e Comité de programme
Président : Alain CASTILLON (EDF-DER)
• Nabil ABU EL ATA (EuroExpert SA) .
• Monique BECKER (Institut National des Télécoms),
• Gérard BORGET (EDF-DER).
• Alexandre BRANDWAJN (Pallas International).
• Serge FDIDA (Laboratoire Masi).
• Alain GUARDENTI (Altaïn.
• Pascal GL'ESNET (Dassault Electronique).
• Bernard ROBIN i Air Franco.
• Edouard WILLIAMSON I Boole & BabbageEurope i
L'associatio n CMGF
LeCMG F a pour axe principal la Gestion OptimaledesSystèmesd'Information. Depuis
le début de l'année 1992. il a intégré dans l'ensemble de ses travaux le thème des "Systèmes
Ouverts".
Le CMGF se propose d'être un Forum permanent et un Fédérateur de la profession :
utilisateurs.prestataires de services . constructeurs, enseignants et chercheurs.
TROI S OBJECTIFS COMPLÉMENTAIRES :
• Evolution de l'état de l'art, de la technique et de la pratique dans les domaines de la Gestion
Optimale des Systèmes d'Information : Automatisation. Administration. Gestion. Contrôle et
Mesure. Optimisation des Ressources. Stockage. Performance et Modélisation. Architecture.
Bases de Données....
• Echange d'expériences autour de l'utilisation et du développement de méthodes et techni­
ques employées.
• Identification des difficultés et préoccupations, constatation des solutions et des actions
préconisées.
LE S MOYENS :
• Le Congrès Annuel
• Les Groupes de Travail : Automatisation. Bases de Données Relationnelles,
Performances. Réseaux. UNIX -et Systèmes Ouverts
• Les Séminaires et Stages de formation
• Le Fonds Documentaire Table des matières
mardi 24 novembre
M. Dey, P. Maurice
Répartition des données et des traitements dans le cadre des systèmes
ouverts : les enjeux pour la gestion des sites 15
A. Cast il Ion
Présentation d'une démarche de classification automatique pour optimiser
les débits de travaux batch et du conversationnel 2
P. Marchini
Le traitement distribué avec le modèle client-serveur 39
/. Hugo
Gestion des systèmes unix dans les grandes entreprises 51
T. Cembrzynski
Maîtrise statistique du processus de peinture de la RENAULT Safrane 6
L. Jean
Une expérience de modélisation à EDF/DER 75
J.-A. Coucouroux
L'administration des systèmes ouverts 87
H. Dhelin
La gestion d'une informatique distribuée dans un complexe MVS 101
mercredi 25 novembre
P. Dangles
Une nouvelle approche du stockage online 113 10 Actes de CMGF 92
C. Zeilas
L'optimisation des performances du SGBD DB2 132
R. Petitfour, D. Kitay
DB2 Buffer Pool Management 151
F. Lebe
Automatisation, deuxième génération 162
E. D. Ho
Performance Management « open » systems 17
J.-L. Girard, S.L. Samson
La gestion des performances sous MVS ESA 4.2 189
S. J. Mellor
Large Systems Performance Measurement 198
J.-L. Gross
Les ateliers intelligents de la production de logiciels : concept AIGLE et
projet IRENA 214
T. Smith
Justification économique du projet d'automatisation de la production
informatique 221
jeudi 26 novembre
S. Fdida
Réseaux haut débit : architecture, enjeux et perspective 233
B. Traverson
Le modèle client-serveur dans les systèmes hétérogènes et répartis :
principes, normes et fiabilisation 246
B. Bouchaud
Enterprise Management Architecture : une architecture pour la gestion
d'un système d'information distribué hétérogène 26
H. Heurtaux
Protocoles d'administration des réseaux hétérogènes pour les années 1990 281
R. Stangret
Performance et gestion de TCP/IP IBM en environnement MVS 296 Actes de CMGF 92 11
R. Panossian
Le programme OSC (Operation Service Center) 309
T. Smith
L'architecture unifiée des systèmes ouverts 316
S. Rafenombolatiana
L'administration de systèmes et réseaux en environnement hétérogène :
approche et réalité 323
S. Fdida, KL. Thai, R. Alimi, P. Corvisier, G. Dupuy
Méthodologie pour l'environnement des performances des réseaux de
communication industriels des centrales à EDF-GDF 329
J.-C. Lafont, B. Bounabat
Méthode d'analyse et de conception orientée objet décisionnel pour
l'automatisation des systèmes de production 341
Q.A. Nghiem, A. Peronny
Conception du réseau des J.O. d'Albertville : performances et disponibilité 359
V. Douhairie
389 La gestion globale du système d'information d'entreprise
N. Abu el Ata
Benchmarking, outil efficace d'aide à la décision : « faire mieux et plus
sûr » 397
J. Charleux
Maîtrise d'un système d'information hétérogène distribué 411
A. Valade
Automatisation VAX/VMS : Optimex 419
Index des auteurs 423 mardi
24
novembre Répartition des données et des traitements
dans le cadre des systèmes ouverts
Les enjeux pour la gestion des sites
M. Dey, P. Maurice
SAS Institute S.A., Domaine de Grégy, 77166 Grégy-sur-Yerres
L'informatique est devenue l'un des moteurs principaux de la compétitivité des
entreprises. Optimisée dans ses performances et ses coûts, elle constitue l'un des
avantages concurrentiels qui démarque un fournisseur de biens ou de services sur son
marché.
Aujourd'hui, la majorité des grands sites informatiques s'intéressent à l'analyse et à la
gestion de leurs performances voire à la mise en place de contrats de service et de
facturation. Un certain nombre d'outils logiciels et d'applications répondent
actuellement parfaitement à cette demande.
Cependant le monde de l'exploitation informatique évolue; les centres informatiques
d'hier n'offrent plus tout à fait les mêmes services aujourd'hui : downsizing,
informatique départementale, infocentre, bases de données relationnelles, architectures
client-serveur, systèmes ouverts sont des concepts qui conditionnent désormais l'avenir
des centres informatiques et autant de paramètres (sinon de contraintes) à intégrer dans
la gestion et l'organisation des sites.
Passant d'une informatique centralisée à une informatique ouverte vers l'extérieur; les
centres informatiques doivent adapter leurs outils de gestion et leurs métiers à cette
nouvelle donne. Autrefois la gestion de centre c'était avant tout la gestion d'une
machine plus ou moins importante; aujourd'hui c'est avant tout la gestion d'un réseau et
de ses différentes composantes que le gestionnaire doit prendre en compte.
Les choix informatiques sont désormais des choix qui ne sont plus seulement des
engagements envers un constructeur mais plutôt envers des standards de fait ou de
droit. Et c'est là le véritable enjeu du développement des systèmes ouverts. 16 Actes de CMGF 92
Après un rappel historique illustré par un exemple nous essayerons de mettre en valeur
dans cette présentation les incidences des systèmes ouverts sur la gestion des sites
informatiques et les solutions à mettre en oeuvre.
Nous distinguerons principalement trois types de ressources informatiques :
- des ressources matérielles : unités centrales, unités de stockage, périphériques,
réseaux de télécommunication, etc....
- des ressources logicielles : environnements d'exploitation et environnements
applicatifs.
- des ressources humaines : personnel employé à gérer et maintenir les deux premiers
types des
Les poids respectifs de ces trois composantes ne sont plus aujourd'hui les mêmes : le
logiciel prend de plus en plus le pas sur le matériel non seulement du point de vue de la
demande des utilisateurs mais également du point de vue de l'offre des constructeurs.
En outre au sein même de chacune de ces grandes catégories de ressources la
composition évolue avec le temps : la départementalisation déporte une partie des
traitements et des utilisateurs vers des machines de moindre capacité (ce qui n'empêche
pas les mainframes de gagner en puissance au fil des années), de même le "downsizing"
engendre une informatique parrallèle à base de micro-ordinateurs et de stations de
travail plus proches de l'utilisateur et de ses besoins propres.
Cette transformation progressive des moyens informatiques utilisés se traduit de fait
par une place grandissante prise par les réseaux de télécommunication dans l'entreprise.
Autrefois réservés à la gestion des terminaux distants et aux échanges de fichiers entre
centres, ceux-ci font désormais partie du paysage quotidien de l'utilisateur et de
l'informaticien. Aujourd'hui ce n'est plus le centre informatique qui est l'élément vital de
l'entreprise, mais plutôt le réseau comme le confirme du reste la prise en compte dans
la construction même des bâtiments d'une entreprise d'un certain nombre de
composants réseaux (câblage notamment).
Essayons de comprendre pourquoi et comment le réseau devient lui même le nerf vital
de l'entreprise.
QUELQUES CONCEPTS
La plupart des programmes applicatifs incluent aujourd'hui les trois composantes ou
couches suivantes :
- une couche présentation : interface utilisateur
- une couche logique applicative : le traitement à réaliser
- une couche d'accès aux données : les données à traiter Actes de CMGF 92 17
Historiquement l'ensemble de ces couches étaient assurées au sein d'un même
environnement d'exploitation. Il n'en va plus de même aujourd'hui à l'heure de
l'informatique répartie.
Plus précisément nous constatons actuellement plusieurs forme de répartition ou de
distribution du Système d'Information.
- PRESENTATION REPARTIE
- TRAITEMENT REPARTI
- DONNEES REPARTIES
Ces trois couches sont clairement mises en évidence par IBM dans ses spécifications
SAA ainsi que dans les spécifications de SYSTEM VIEW
A y regarder de plus près on pourrait rajouter deux couches intermédiaires comme le
suggère le GARTNER GROUP dans certaines publications récentes ce qui nous
conduit au schéma 1 en annexe.
OPTIMISER QUOI ET COMMENT ?
Décider quelles ressources optimiser dans un environnement réparti devient dés lors un
problème complexe lié aux choix d'architectures effectués par l'entreprise, aux
applications et à leur mode de fonctionnement. Ce problème doit être évalué en
tenant compte de l'historique (système d'information en place) et des coûts associés à
chacun de ces nouveaux types d'architecture (coûts matériels, logiciels et humains).
Essayons de voir quels peuvent être les conséquences de chacun de ces choix possibles
d'architecture répartie ou coopérative.
PRESENTATION REPARTIE :
Elle consiste principalement à remplacer le terminal d'antan par un poste de travail
intelligent ; tout en préservant les anciennes applications on rajeunit l'interface
utilisateur mais on ne décharge pas vraiment les ordinateurs centraux du poids des
applications en fonctionnement. L'investissement matériel est important,
l'investissement logiciel minimal; l'investissement humain variable; ce dernier pouvant
avoir des effets induits non-négligables (adoption d'une nouvelle culture micro­
informatique dans l'entreprise, besoins de formation, etc..)
DONNEE S REPARTIES
Cette solution va un peu plus loin puisqu'elle permet de décharger sensiblement les
ordinateurs centraux du traitement logique de l'application, lui réservant la gestion des
données et l'accès aux données. L'investissement matériel est également très important 18 Actes de CMGF 92
puisque le besoin en traitement nécessite des postes de travail intelligents ayant des
capacités de traitement importantes; l'investissement logiciel devient ici très important
car il faut réécrire les applicatifs ou les adapter ce qui implique un investissement
humain non moins négligeable pour la réécriture et la maintenance de ces nouvelles
applications coopératives. En outre le coût des télécommunications devient ici plus
important car les données à traiter transitent forcément du processeur serveur de
données au processeur client assurant le traitement.
TRAITEMENT REPARTI
Une solution intermédiaire permet de minimiser les coûts de transfert d'information
entre processeurs à travers le réseau et de répartir les traitements de manière
coopérative entre les postes de travail intelligents et le processeur central. Cela se
traduit naturellement par la réécriture ou l'adaptation de ces traitements à ces
possibilités de traitement réparti.
EN CONCLUSION
La mise en oeuvre d'architecture coopérative ou d'architecture répartie on le voit n'est
pas une mince affaire elle doit être adaptée au cas par cas voire spécifiquement pour
chaque applicatif. Elle se traduit généralement par des coûts initiaux de mise en oeuvre
et d'adaptation des applications (et donc des coûts humains) parfois non négligeables.
Doit on cependant renoncer à la mise en oeuvre de telles architectures ? Certes non,
elles aboutissent à une spécialisation des tâches de chacun des composants du Système
d'Information qui contribue à une meilleure utilisation des ressources informatiques.
Cependant, cette mise en oeuvre doit être contrôlée et gérée comme telle et être mise
en oeuvre progressivement par l'utilisation d'outils permettant en particulier :
- la prise en compte du Système d'Information existant, accès aux données des
environnements de production et adaptation progressive des applications pour intégrer
les nouvelles technologies . Exemple : introduction d'un langage de développement de
Quatrième génération accédant de manière transparente aux données de
l'environnement de production
- le choix d'un mode de traitement coopératif au cas par cas en fonction de l'applicatif à
réaliser et non de manière globale pour l'ensemble du Système d'information de
l'entreprise. Ces choix permettront de gérer plus finement non seulement le trafic sur le
réseau mais également la puissance des processeurs devant réaliser chacune des tâches
en spécialisant certaines machines (ou certains processeurs) sur certaines tâches :
machine infocentre, machine de production par exemple.
- la portabilité des applications de manière quasi transparente entre les différents
processeurs du Système d'Information. Ceci dans une double perspective : d'une part le
poste de travail du développeur n'est pas forcément identique au poste de travail de
l'utilisateur, la portabilité d'une application entre les environnements permettra au
développeur de développer dans son environnement habituel et de porter l'application Actes de CMGF 92 19
finale sur l'environnement d'utilisation qui ne sera pas forcément le même; d'autre part
la pérennité d'un applicatif ne sera pas remise en cause par les changements
d'orientation et les facteurs commerciaux qui induisent l'évolution des matériels et des
environnements d'exploitation.
- la mesure effective des gains et/ou pertes engendrés par ces choix d'architectures
applicatifs par applicatifs avec une vision globale sur l'ensemble du Système
d'Information et pas seulement sur l'activité du site central ou des contrôleurs de
réseau.
UN CAS D'ECOLE
Une compagnie internationale de location de véhicules que nous nommerons STAR
Autos et dont le siège mondial se trouve à CHICAGO (Illinois) fournit un certain
nombre de services (marketing, traitements informatiques et achats de véhicules) à ses
filiales sous franchise à travers le monde. Ces dernières possèdent et maintiennent les
véhicules loués aux clients à travers un réseau d'agences franchisées.
Parmi les applications informatiques on trouve notamment un système centralisé de
réservation, un système de gestion des contrats, et un système de gestion des véhicules.
L'évolution de ces systèmes à travers le temps est assez révélatrice de l'évolution d'un
Système d'Information.
1985 - Bases de Données Centrales - Mainframe et terminaux passifs
Le système de réservation et de gestion des contrats est entièrement basé sur IMS
(Information Management System) fonctionnant sur un système central IBM et
accessible aux utilisateurs par le biais de terminaux 3270.
IMS/VS DB-DC a servi de base au Système de Réservation en particulier pour les
raisons suivantes :
- volume important de transactions à traiter
- sécurité en cas d'incident (data recovery)
- niveau de disponibilité : 24 heures sur 24, 7 jours sur 7.
En ce qui concerne le Système de Gestion des contrats, IMS a été également retenu
malgré un nombre de transactions un peu moins importants pour les raisons suivantes :
- certaines données proviennent du système de réservation
- l'entreprise souhaite rentabiliser son investissement en formation de programmeurs
IMS
En 1985 le système de gestion du parc de véhicules n'existait pas encore. Longtemps
demandé par les utilisateurs franchisés, il fait partie des nombreuses applications en
attente faute de temps et de ressources pour la Direction des études. 20 Actes de CMGF 92
1986-1989 - IiiTocentrc et Machines Départementales
Le Département Marketing estime à l'époque qu'il ne peut plus dépendre de la bonne
volonté du Département Informatique pour mener ses études de marché et ses
prévisions.
Les chargés d'études utilisent alors le Système Central pour conduire leurs études mais
sont limités à une utilisation en mode batch d'un outil d'infocentre car les ingénieurs
système craignent de perturber la disponibilité et les performances d'IMS par
l'utilisation d'outils plus interactifs (même si de fait le produit utilisé le permet). Les
ingénieurs système utilisent d'ailleurs à l'époque le même outil pour la mesure et
l'évaluation des performances du Système Central.
Pour pouvoir utiliser cet outil avec un confort plus important en interactif, le
département Marketing se dote alors d'une machine départementale (un VAX de
DIGITAL EQUIPMENT sous VMS). Des applications interactives sont alors
développées pour couvrir les besoins des chargés d'études dans cet environnement.
Bien évidemment les études sont alors menées sur des données extraites de
l'environnement de production chaque semaine et stockées sur bande magnétique pour
transfert vers la machine départementale, ce transfert par bandee sera
ensuite complété par des transferts directs au moyen du réseau.
En 1987 la capacité de réaction du Département Informatique aux nouvelles demandes
d'application sur site central commence à devenir critique et on crée alors une équipe
chargée de mettre en oeuvre l'outil de quatrième génération déjà utilisé par le
Département Marketing pour la mise en oeuvre du système de gestion des véhicules
dans l'environnement IBM après un upgrade effectif de sa capacité.
1990 - Des micro-ordinateurs dans les agences
A la fin des années 80, les agences franchisées ont commencé à s'équiper de postes de
travail de types (en lieu et place des terminaux 3270). Ces postes
équipés de logiciels d'émulation de terminaux 3270 permettaient non seulement
d'accéder au système central IBM mais également d'utiliser localement des logiciels
(comptabilité, tableurs etc..)
En 1990, la plupart des agences étaient donc équipées de micro-ordinateurs parfois
reliés entre eux au sein de reseaux locaux. De nouveaux besoins commencent à
apparaître nécessitant l'utilisation d'informations en provenance du site central pour des
traitements locaux aux fins de prévision notamment. De plus de nombreuses plaintes de
clients permettaient de conclure que les délais de prise en charge d'un véhicule en
agence étaient largement augmentés par des pannes ou des défaillances du Système
central.
Une étude menée à la Direction Informatique permettait de conclure à une disponibilité
à 98 % des bases IMS, la disponibilité globale du réseau étant elle estimée à 93%.
Une étude fut alors engagée pour : Actes de CMGF 92 21
- déterminer la faisabilité d'un déport des transactions contractuelles vers les micro­
ordinateurs
- recommander une solution standard pour l'accès aux données centrales depuis les
postes de travail micro.
L'étude montra qu'il paraissait difficile de déporter le système central de réservation sur
les postes locaux; en revanche le système de gestion des contrats apportait plus
d'espoir.
- Un contrat est en général mis à jour deux fois seulement : à la prise en charge du
véhicule et au retour du véhicule.
- Des accès en lecture sur la base contrats sont généralement requis par ailleurs pour
divers calculs statistiques.
- 85 % des contrats concernent des véhicules pris et retournés dans une seule et même
agence
- 70% des locations ont fait l'objet de réservations préalables et 10% seulment ont fait
l'objet de réservations le jour même de la prise en charge du véhicule.
Il apparaissait donc clairement que le système de gestion des contrats pouvait au moins
partiellement être réparti sur l'ensemble des agences et donc sur les postes de travail en
déportant les données contractuelles vers less concernées (pendant les heures
creuses de la journée ) .
Ce qui fut fait entre 1991 et 1992
A travers cet exemple on voit clairement l'évolution d'un système d'information d'une
informatique centralisée vers une informatique décentralisée où le réseau prend
d'année en année de plus en plus d'importance. Une constatation s'impose cependant :
la donnée reste le coeur de l'entreprise, le réseau devient simplement le vecteur de cette
information.
LES ENJEUX POUR LA GESTION DES SITES
Pour bon nombre de directions informatiques la gestion des sites passe par la gestion
des performances et il s'agit certes d'un composant inéluctable à prendre en compte.
Autrefois, la gestion des performances était réservée à l'analyse des données des
ordinateurs centraux ; elle doit être vécue désormais comme un problème plus global
d'entreprise et plus précisément comme un problème global de gestion et d'allocation
de ressources.
Historiquement cette discipline s'est développée dans diverses directions : 22 Actes de CMGF 92
- reporting sur la qualité de service (volumes de transactions, temps de réponse, etc..)
- caractérisation de la charge : mesure des ressources et affectation des ressources à
des groupes d'utilisateurs
- gestion des ressources : tuning; analyse des incidents
- facturation des ressources
- prévision de capacité
Ces directions existent toujours dans le cadre d'architectures ouvertes et hétérogènes
car non seulement le mainframe existe toujours (applications de production
notamment) mais il est le point de départ de l'activité de l'entreprise (en général le
gestionnaire des données de l'entreprise est associé à cette unité centrale).
On ne peut néanmoins se contenter d'analyser les données produites par les ordinateurs
centraux pour gérer au mieux les performances de l'informatique d'entreprise. La
gestion des performances devient elle même une discipline qui doit être basée sur les
spécificités des architectures retenues. Dans la mesure où une transaction peut
désormais impliquer plusieurs environnements différents, la mesure de cette transaction
doit elle même exploiter plusieurs sources d'information différentes qu'il faudra bien
évidemment mettre en relation.
Aujourd'hui la gestion des performances nécessite non seulement des outils fiables au
niveau des ordinateurs centraux mais également des outils comparables au niveau des
réseaux locaux, des machines départementales et de chaque noeud du réseau.
Plus encore, ces outils doivent offrir une certaine cohérence dans la collecte, la
réduction, l'analyse et la présentation de l'information en provenance de ces différentes
sources. L'idéal étant bien sûr qu'un même outil assure ces différentes fonctions quelles
que soient les plate-formes matérielles faisant partie du réseau et assure la circulation
de cette information vers les différentes catégories d'utilisateurs concernés : du
directeur général intéressé par la qualité globale du service informatique jusqu'au
développeur d'application s'intéressant aux performances de son algorithme.
Le schéma 2 en annexe reprend dans ce cadre le besoin principal en matière de gestion
de performances :
- collecter des données issues de diverses sources et désormais de diverses machines
- traiter et gérer ses données et produire différents niveaux de détail (base de
performance)
- analyser ces données de manière à en tirer de l'information
- présenter les résultats aux différents utilisateurs concernés Actes de CMGF 92 23
D'une manière générale, les moniteurs de performances présents sur chacun des
systèmes informatiques répertorient l'ensemble des données utiles à la gestion des
performances. Ces données sont souvent inexploitables en l'état, sauf pour des besoins
de tuning immédiat et de décision à très court terme. Spécialisés par sous-systèmes ils
ne permettent pas d'obtenir une information homogène sur l'ensemble du système
d'information de l'entreprise.
La constitution d'une base de performance consolidant les données de ces différents
systèmes et sous-systèmes en un ensemble unique permet d'avoir une vision cohérente
du système d'information, de sa capacité et de ses lacunes.
De plus, la gestion des sites ne doit pas seulement traiter l'activité des machines et des
processeurs mais plus globalement tirer parti d'autres sources d'informations
(ressources humaines, ressources logicielles), informations sur la configuration, etc..
Ces informations sont également stockées dans différents sous-systèmes, voire sur
différentes machines et il faut en toute logique les consolider au sein d'un unique
ensemble de manière à avoir une vision globale de l'état des ressources informatiques et
prévoir leur évolution.
CONCLUSION
La nouvelle donne qui caractérise l'informatique d'entreprise aujourd'hui implique une
prise en compte globale de la gestion des centres et des outils appropriés pour la
mettre en oeuvre. Ces outils doivent répondre à un quadruple enjeu :
- indépendance par rapport aux données : accès aux diverses sources de données
(moniteurs, logs...)
-e par rapport aux matériels : support d'architectures informatiques
hétérogènes (mainframes, minis, réseaux locaux...)
- indépendance par rapport aux utilisateurs : de l'opérateur au Directeur Informatique,
voire au Directeur général.
-e par rapport aux applications : de la collecte des données jusqu'au
tableau de bord de la Direction Informatique en passant par la facturation et la
prévision de capacité. 24 Actes de CMGF 92
ANNEXE
i i i i
Données Présentation Présentation Traitemen t SCHEMA / Données
Distantes Répartie Distante Réparti Réparties
Présentation Présentation Présentation Présentation Présentation
Applicatio n Applicatio n Applicatio n
(traitement) (traitement) (traitement)
Accès
Présentation Données
Applicatio n Applicatio n Applicatio n
(traitement) (traitement) (traitement)
Accès Accès Accès Accès Accès
Données Données Données Données Données
Schéma «?
Machin e 1
Machin e 2
Machin e 3
COLLECTE R TRAITE R ET REDUIR E ANALYSE R
PRESENTE R (Bas e de Performance) Présentation d'une démarche de classification
automatique pour optimiser les débits
de travaux batch et du conversationnel
A. Castillon
EDF, direction des études et recherches, 1 avenue du Général de Gaulle,
92141 Clamart cedex
I INTRODUCTION
\¡cs responsables des performances ou de la gestion de la capacité des centres informatiques
sont confrontes à des problèmes de plus en plus complexes et ont à traiter un nombre gigantesque
de données.
Il faut bien chercher à les réduire, les interpréter, puis bien souvent, essayer de les classcr.Cc
problèm e peut sembler ardu et complexe a priori; néanmoins les outils statistiques modernes sont
très puissants et d'une mise en oeuvre relativement facile, comm e nous allons tenter de le montrer
ici.
DOMAINR S D'APPLICATION
Pat ARTI S (Dib 1) a montré l'utilité des méthode s de classification pour les travaux batch, afin
de construire un système d'ordonnancement efficace cl réduire ainsi leur file d'attente.
Michae l I.RIÏ dans un séminaire de performance CANDI,H (Bib2) s'est intéressé au même
problèm e mais transposé aux transactions de type TSO.
I/implementatio n de DF-SMS pose aussi le problème de la classification si l'on veut réduire
le nombre de classe de sélection de fichier au minimum.
L'analyste réseau pourra ainsi mieux connaître le profil et les charges de ses lignes.
rinfin on verra que les résultats permettent de définir des profils pour des cas-lests
(benchmarks ) synthétiques et aborder ainsi les problèmes simulation.
Cett e liste n'est bien sûr pas exhaustive et l'on peut trouver d'autres domaines d'application à
la classification des données.! ,cs statisticiens utilisent couramment ces méthodes dans leur
dépouillemen t d'enquêtes.
Nou s donnerons une démarche générale d'étude de données sur deux exemples:
-U n jeu de données comptables concernant des process CRAY.
-U n jeu de données SM F de transactions TSO sur une machine du Centre de Calcul.
Nou s avons utilisé ici les logiciels SA S et nous commenterons les résultats. 26 Actes de CMGF 92
11 METHOD E UTILISEE
Nou s allons successivement étudier:
-L a distribution de ces données
-1,'analysc en composantes principales.
Cec i va nous permettre de voir si l'on peut réduire à quelques variables l'explication du
tablea u de données, comment elles interagissent entre elles, quelles sont leurs
corrélations .
-Exclur e éventuellement les observations qui perturbent l'analysc(outlicrs).
-Enfi n classer les données.
Pou r approfondir les méthodes de calcul employées et leur interprétation, on peut se
reporter au livre de G.SAPORTA(l)ib7) où l'on trouvera les démonstrations
mathématique s et des exemples, à celui de W TUKEY (Bib5) pour l'analyse
exploratoir e des données.
II1.ETUDE DES JOnS CRA Y
III. I Présentation des données
U n fichier comptable, édité jounialièrcmcnt contient en particulier les informations suivantes:
-\J C nom de l'utilisateur, les heures de soumission, de début et fin de traitement.
•\JCS temps CPU consommés:USF.RT temps cpu utilisateur, SYSTM temps cpu
système , CPUM E intégrale de l'occupation mémoire du job durant l'exécution cpu.
Celt e valeur sera divisée par le temps cpu pour avoir l'occupation mémoire moyenne
d u job.
-Ix:s Entrées-Sorties: IOREQ nombre de requêtes d'F./S, IODLK nombre de blocs lus
o u écrits, RIOR Q nombre d'E/S physiques sur les disques, IOWT temps d'attente dû
au x Il/S. IOMP/M intégrale de l'occupation mémoire durant les R/S.
Le s observations concernent une journée d'exploitation soit environ 5000 'process' exécutés.
III.2 Etude de la distribution des variables.
I.a procédure UNIVARIATE de SAS permet de tester la normalité des données et la distrib­
utio n des variables.
Pou r la variable USF.RT , par exemple, (CP Anncxcll.l) on note:
U n échantillon de 14.1.1 variables, la moyenne est de 98.6 S., cl l'écart-typc est 451.7 s. ce qui est
énorm e par rapport à la moyenne.
L'histogramm e montre qu'un grand nombre de variablcs( 1.178) se situe aux alentours de 250
s, et que l'on a des écarts énormes avec une observation à 9750 s.Ix graphique de la boite à
moustache s (Ilox plot) nous renseigne d'un seul cou p d'oeil sur cette distribution;cllc est tassée vers
le bas -clic n'a qu'une longue moustache supérieure et pas d'inférieure- cl l'on a de très fortes
valeurs en haul.Il en est de même pour les autres variablcs.il semble intéressant de passer aux
I .ogarithmes.
I« s Moyennes et écarts-types sont beaucoup plus proches, et l'on voit sur la boite à moustaches
qu e la médiane et la moyenne sont voisincs;la boite qui représente l'intervalle interquartile QI-Q.1
est mieux centrée sur les moustaches. Nous avons une loi I x>g-Normale.Cependant , on observe
u n encore nombre assez. élcvé( 108) d'observations avec des valeurs cpu très faiblcs(0.067s) ces petits
job s peuvent être éliminés car ils n'ont pas une incidence forte sur la charge de la machine.
U n troisième passage en supprimant les jobs de USERT< .Is (Annexe II.2) montre que l'on a
normalis é les donnécs.Ccci va nous permettre de les centrer et de les réduire.
\JI même transformation a été appliquée aux autres variables.
III..1 Analyse en composantes principales
Cett e analyse permet de donner une idée plus synthétique de notre tableau de donnécs.Ccla
revient à chercher des axes (dits axes principaux) pour lesquels l'inertie des variables observées va
être maximum.Mathématiquement, cela revient à diagonaliscr la matrice des observations et
cherche r ses valeurs propres (cf Hib7). Ces valeurs propres indiquent le pourcentage d'inertie
(d'explicatio n du tableau).Pour donner le même poids à chacune des variables observées, il est
intéressant de les centrer et les réduire (Transformation des variables qui donn e une moyenne nulle,
et un écart-type de I). Actes de CMGF 92 27
I es résultats figurent à l'Annexe III.
La matrice des corrélations Tait apparaître de fortes liaisons entre Uscrt et Systm (.77), Ioblk(.72)
et le groupe lorcq, Riorq lowt et lomem (63).l.a variable Cpumc lui est relativement peu corréléc
(.5);la taille mémoire doit être peu dépendante de la taille cpu. I.a variable Systm est très fortement
corréléc avec les P,/S physiqucs-lorcq(.85), Riorq(.87).Unc rapide étude avec SAS Insight a permis
de trouver une régression linéaire entre ces deux variables.
I J variable lowt est fortement corréléc avec Riorq et lomem les temps d'attente c/s sont dûs
essentiellement aux c/s physiques des disques.
Analysons maintenant les valeurs proprcs.lillcs sont au nombre de huit, comme le nombre de
variables.la première a une valeur énorme (6.1); c'est donc un axe explicatif extrêmement
important.La colonne proportion' indique que cet axe résume le tableau à près de 80%(.76). IJI
deuxième valeur propre est bien plus faiblc(.7) et contribue pour seulement 9 % à l'cxplic;ition du
nuage.On peut dire qu avec 3 AXPS principaux le tableau de données est expliqué à plus de 90
/Il .
II reste maintenant à caractériser ces .1 axes principaux avec les variables analysées.Il faut
regarder le paragraphe P.igcnvcctors'. Il nous donne les projections des variables sur chacun des
axes propres.
Sur le premier axe principal l'rinl', les 8 variables se projettent selon les mêmes coordonnées, en
gros 0..16.11 représente une combinaison des 8 variablcs.Cct axe va opposer les gros travaux cpu et
très fort taux d'F,/S, aux petits travaux.Cet axe est en général celui qui définit l'effet de taille des
observations.
Sur le deuxième axe, Prin2' on va avoir les jobs mémoire (.7) et c/s (.2) opposés aux jobs
Systm(-38), à fort lorcq(-.29) variables très eorrelées.
Ouant au Troisième axe, il oppose les jobs à profil cpu(.82) avec les les jobs à profil c/s.
Ixs projections des nuages de points sont en Annexe 111.2,3,4; on note des nuages très compacts
dans les 3 Plans.
I/observation du Plan principal 1-2 donne des gros jobs à profil cpu à droite du plan, les gros jobs
cpu et c/s en haut , les petits jobs en bas et enfin les jobs àl e/s à gauche.
Ix plan principal 1-3 va donner les mêmes corrélations.Sur les annexes III on a reporte sur chaque
axe les différentes variables discriminantes.
I.cs plans opposent en gros 2 profils de jobs -gros ("pu Gros I/O et petit CPU gros I/O-.
III.4 Classification des travaux
I a méthodes de classification ont pour but de construire des partitions d'un ensemble
d'observations dont on connaît leur distance deux à deux.Ces partitions doivent être les plus
homogènes cl elles doivent se différencier entre elles le plus possible.
Ici aussi cette analyse revient à minimiser la perte d'inertie interclasse lorsque l'on passe de n à n-l
classcs.Quand l'inertie intra-classc devient trop forte on arrête la création de classes (Cf Bib 7).
Nous avons effectué celte classification sur les variables CPUT et CPUMP, afin de voir si les
'initiators' sont bien adaptés au profil de la machine.
Ixs options prises dans la procédure PASTCI.US sont:
-MAXCLUSTER S = 255 Limite maximale du nombre de classes, afin que les obser­
vations Irop particulières ne soient pas agrégées dans des classes trop éloignées.
-RADUJS = 1.5 donne l'étendue maximum de la classe (l.5*ixart-typc)
le s résultats figurent à l'annexe IV. 1.
Ix chapitre 'Inital seeds' permet de voir les classes générées au départ par la procédure.
I.C paragraphe 'Cluster Summary' donne le nombre de classcs(8), leur population, 1 écart type de
la distance au centre de gravité (RMS sld Déviation), la distance maximale des individus dans la
classe, la classe la plus proche en distance, enfin la valeur de cette distance.
P.nfin on trouve les moyennes et les écarts-types des variables définissant chaque classe.
Sur notre exemple nous voyons que certaines classes sont assez, proches, 0.9 pour les classes 4 et
(y, les autres sont un peu plus distantes, l/cnscmblc des 1326 jobs peut être ansi regroupé en 8
classes.Ixs plus importantes sont la classe 3 (334 jobs) et 5 (312 jobs). Sur le graphique suivant,
nous avons fait figurer les observations, et trace le rayon de la classe. Nou s avons fait figurer la borne
supérieure de chacune de nos classes du crav:rapidm(l5s-30Mw), rapidt(60s-8Mw),
mini(3()s-l6mw), moycn(900s-2()Mw), monstr( l800s-20Mw), lcnt(72000s-30mw) , big(72000s-l 10
Mw).()n note une valeur trop forte des tailles mémoire par rapport aux tailles des travaux 2 8 Actes de CMGF 92
effectivemen t executes.Il faut aussi créer îles classes plus petites en temp s cpu si l'o n veu t avoir u n
débit optimal.I^i liste des classe s avec leur caractéristiques mémoire et cp u es t donné e à l'Annexe
IV.I.O n a calculé l'écart type des variables pour avoir ainsi la born e supérieure des valeurs. \jca
pourcentage s et le cumu l permettent de voir quelle est la proportion de job s qui représenterait un
cas-test s de débit avec leur caractéristiqucs.A partir de jobs artificiels paramétrables en temps
cpu,c/s,c t taille mémoire, on peut ainsi réaliser un benchmar k synthétique
II 1.5 Conclusion
Cett e procédure peut être exécutée en automatiqu e à partir des fichiers comptables journaliers
cl aboutir au graphique mettant en évidenc e le (dé)calagc des classe s par rappor t aux travaux.
.Simple de mis e en oeuvre , il faut toutefois l'affiner en faisant des tirage s aléatoires sur plusieurs
jour s pour avoir un échantillo n raisonnable cl être sur d e sa représentativité.
Il faut maintenant réajuster les classes , calculer les débit s des jobs , puis à partir de leur temps cp u
calculer le nombr e moyen de travaux dans chaque classe, en fonction de la vitesse et du nombre
d e processeurs, pour optimiser la file d'attente et les débits .
iv ETUDE DES TRANSACTIONS TSO
IV. I Présentation des donnée s
Pou r arriver à établir une classificatio n de ce s transactions , il faut d'abord avoir un découpage
asse z fin de ccllcs-ci.Cclui défini par le s 3 o u 4 traditionnelles périodes étant trop grossier, nous
avon s repris le fichier des IP S e t généré des période s successives de 50 0 Unité s de service chacune:
l'G N = 2,(DM N = 3,D P = E50.DU R = 500.OB.I = 61)
(DIVIN = 3,D P = P50.DU R = I000.OB.I = 61 ) N = 4,DP = P40.DUR = 1500,00.1 = 61 )
(DM N = =R = 2000,00. 1 = 61 )
(DM N = 4,1)1' = RO.DU R = 2000.OBJ = 61 )
( D M N = 4. D P = I -40.D U R = .1000,0B.I = 61)
(DM N = 5,I)P = M3.DU R = .1500,011.1 = 61 )
(DM N = 5.D P = R = 4000.OB. I = 61 )
(DM N = 5,1)1' = M3.DU R = 4500.OB. I = 61 )
(DM N = 5.D P = M.1.DU R = 5000.OB.I = 61 )
(DM N = 5,1)1» = M3.ISV = 5500.OBJ = 61 )
Nou s avons défini 8 périodes qui représentent, ainsi, l'étendue de no s transaclions.Cc t IPS a
tourn é plusieurs jours sur notr e machinc.C'est une machin e qui fait des transaction s très lourdes
sou s ispf et fortran.
Nou s avons utilisé le cod e MXCï de B. MERRII.I , pour générer les table s SA S de s donnée s
SM P ainsi recueillies.De ces tables , nous avons extrait les variable s suivantes:
-CPUTCBTM CPUSRBTM consommation s cpu utilisateur et système
-PGPEXC P Nombre d'E/S
-AVGMEMSZ Taille mémoire moyenne occuppcc par transaction
-CPUUNITS, IOUNITS, MSOUNITS, SRBUNITS, qui sont les équivalents des
variable s précédentes, mais exprimées par u n nombr e sans dimension et qu i serven t au
gestionnair e de ressources (SRM) à gérer les utilisateurs en fonction de leurs
consommations.C c sont des Unités de Service. Ces Unité s de service tiennent compte
d e la puissance de la machine sur laquelle s'exécutent les transactions. Pou r de plus
ample s détails voir la brochur e IBM (Bi b 8).
Nou s avons divise ces valeur s par l e nombr e de transactions pour avoir un profil moyen.
V.2 Etude de la distributio n des variables
Comm e dans le cas précédent, nous avons été amenés à faire une transformation
logarithmiqu e des variables. Actes de CMGF 92 29
V. 3 Analyse en composantes principales
Ici, aussi, les résultats sont assez voisins.Nous notons que les variables Cputcbtm cl Cpusrbtm
sont , par contre, plus corrélccs(.9) que dans l'étude CRAY , et que la variable mémoire est moins
corréléc(.7).
Cett e dernière variable est par contre corréléc avec la demand e en mémoirc.En effet, plus o n a d'E/S
et plus il faut de 'buffers'.
En ce qui concerne les vecteurs propres, le premier axe explique 92% des variables, et avec le
deuxièm e o n arrive à près de 100 % !
\c premier axe est là aussi une combinaison de toutes les variables, et le second oppose les trans­
action s consommatrices de mémoirc(.R), aux autres variables, en particulier la variable Cputcbtm.
I,c premier plan principal fait apparaître une nette coupure entre les toutes petites transactions et
le reste des observations.
V. 3 Classification des transactions
Comm e nous l'avons vu plus haut, il est nécessaire de revenir aux consommations en Unités
d e Service pour définir les durées de chaque période, seul paramètre que connaît le Gestionnaire
de ressources (SRM ) défini par la variable DU R (cf ex V.I).
Aprè s diverses transformations nous obtenons le récapitulatif de l'Annexe 7. Nous voyons que
nou s obtenons 6 classes, et que ce tableau réserve quelques surprises....
Nou s avons, successivement, le nO de cluster, le pourcentage de transactions dans la classe
(Percent) , puis ensuite, le nombre d'Unités de service cpu, srb I/O et mémoire.Ensuite figure le total
(sutol ) qui correspond au paramètre DUR des IPS, la consommatio n Cpu en secondes et enfin les
pourcentage s cumulés.
l a population maximale est en quatrième période avec une consommation de 20000 Unités
de scrvicc.Si, dans notre exploitation, nous voulons servir 90 % des transactions en première
période, il va falloir mettre des durées prohibitives, et perturber près de 60 % des utilisateurs. I a.
première période, quant à elle, ne satisfera que 12 % des transactions, mais nous garantirons un
service mieux adapté avec de fortes priorités.
Etant donnée l'étendue des cinquième et sixième périodes, il sera nécessaire de refaire des
découpage s supplémentaires.
V. 4 Conclusion
L'étape suivante est la mise en oeuvre de ces paramètres et mesurer les écart-lypcs.Avcc le
temp s cpu consommé, et les taux de transactions, nous avons avec les calculs de file d'attente la
possibilité de définir les taux de multiprogramation des différents domaines.
VI CONCLUSION
Nou s avons montré ici (du moins nous l'espérons !) toute la richesse et la puissance des outils
statistiques que nous avons à notre disposition.(a description pas à pas de la méthodologie
permettra à d'autres personnes qui pourraient être rebutées, a priori, de se lancer
Tou t comme l'étude des performances, ces techniques demandent du bon sens et de la
pratique.II ne faut surtout pas hésiter à les utiliser, d'autant plus que leur mise en oeuvre est très
rapide (une demi journée pour écrire le programme de lecture des données ).
Le s résultats nous permettent de mieux connaître notre exploitation et de contribuer à diminuer la
part d'empirisme (les fameuses Rules of Thum b ou ROTS) dans nos pratiques journalières
I,cs apports dans le domaine du benchmarking sont très intéressants.
Cette méthodologie n'est qu'un point de départ de notre analyse.Il faut maintenant mettre ces
résultats en oeuvre.Il faut ensuite passer aux théories des files d'attente.Grâce à des modèles
simplifiés, nous pouvons déduire les taux de multiprogrammation permettant d'optimiser les débits
de s travaux et des transactions.
Ves champ s d'investigation ne s'arrêtent pas là: toute personne qui doit caractériser ou classer
des données, que ce soit dans le domaine des réseaux, ou pour la mise en place de DE-SMS, doit
entreprendre de telles démarches. 30 Actes de CMGF 92
Nou s tenons à remercier: P. BPTOUT, G. BORGF.T, P. COLLOMB, liai BUI THF,
TIIUONG , pour leurs conseils.
ANNEXE I
BIBLIOGRAPHIE
Bibl : P. ARTIS - advanced mvs performance management workshop
(1990)
btb2 : M. LEE - designing a performance group for high performance tso
(1991)
Candie Performance Seminar
Bib 3 : S. SCHLOTZHAUER/R. LITTEL - SAS system for elementary
stastical analysis USE?)
Bib4 : SAS User's guide - SAS stat User's guide
bib5 : .1. VV. T U KEY - exploratory data analysis addison-wesley (1311)
Bib6 : SAS insight User's guide
bib7 : G. SAPORTA - probabilités analyse des données et statistiques Edi­
tions Tcchnip (1330.)
BibR : MVS/ESA System Programming Library : Initialization and Tuning
Guide Publication IBM Actes de CMGF 92 31
ANNEXE II.i
M«.MI (Kl L«*V«WA CFTTV
UMIWAAIAIT «aoCIOuaC
(•util :
•JII- »r,H 104* 0*1 HIBMRIR oa t
M« OJ j;.t*a > a.arrj i aa n
1ID O* » t•••!«.1 MO R.aaia a.arra i >*l 4a*r.i»i( •a » ira.»*] * I'SI
LA* AM. is •U«LD*I» 11 **.» «I i.»*i f a.arr x aat» nta.r»i i l «ai
j.a* i tft Cl*! ï.allat A • I HI M • •I» ) a.«a n a.ar m aia i «art.tan •at l
9F II »F 4M I I. a i t M a.arrs i r* n *«t).**i| H
• •A ITLLL ••••a i
MM > S
«J-OI
WTLIG'H o.aaa i • OOL
1¿« ««M.
HI IFUCMA* NOMMA L '•tmaaiLItV «LOI
•r»a»
I
I
1
11
!•
i l'a
• 4*T»**-,-.ML HP TO F* COUHII
ANNEX E 11.2
•Mill ! OIL IA***UI c«AI 0*1*Í LIMIM|, *«***•*•« i», 14*1 i l
•MITIF u-< mann e w» 0**1 IVANUTI e u > I »TF
**RLAKL*>ULF*T
• . F»***1 0*1 IH '
i. TARAI* i*ia.a * 1.4*0*»» itai i r.*«ttiiat t.uvoi ï
ita o». io«**> i . DM'» 10* *»* I. I1*11* m i a.iiouti irii *i: i.
• •NAM uni t.»*10* -0. 1 >*1 II= ii -f.»*a*(
I 1111.* 11» O T *I>1 -».*••* -i.**a*t tan a.amtif »•*>
ita o.04i»*r -/.**na<
10**1 l.lHIill
T «•»•>• 0 • R«*>TLL • L.ro m
IM> > 0 un at-si I.'RIO»
AILLA*! a.aoai -I.KFA**
I9» •A4>ML a. MOI
R
•MR Bat RRMMIIIII PLAT i '••NIAI
m t t
ma i 32 Actes de CMGF 92
ANNEXE III.I
ANALYSE OES TRAVAUX CRAY Int nan/cput 18:32 Thursday, October 1, 1*92 35
Principal Component Analysis
1329 <ji>s«rv«tlMi6
t Variables
Simple Statistics
SYSTM
USER ! I0RE1 IQ8LK RIORO IOWT CPUNE IOHEN
Mean 0.000000000 0.000000000 0.000000000 0.000000000 0.000000000 0.000000000 0.000000000 0.000000000
StO 1.000000000 1.000009000 1.000000000 1.000000000 1.000000000 1.000000000 1.000000000 1.000000000
Correlation Matrix
USER T SYsrH IIREO. IORLK
P.IOR Q IOMT CPUME IONEM
1.0000 0.7752
USE R I 0.6276 0.7173 0.6373 0.6278 0.4957 0.6392
SYSTN 0.7752 1.0000 0.8*89 0.7313 0.8776 0.780*
0.6972 0.7636
0.6276 0.9*89 1.0000 0.7857 0.9889 0.7271
0.5210 0.7175
0.7173 0.7313 0.7857 1.0000 O.B333 0.7509 0.7570 0.8427
RIORQ 0.6373 0.9776 0.8869 0.8333 1.0000 0.8198 0.3792 0.8076
0.72 71 0.7509 0.8198 1.0000
0.6278 0.780» 0.5*93 0.9215
0.5210 0.7570 0.5792 0.5*93
CPUNE 0.*9>7 0.6972
1.0000 0.7657
0.7175 0.8*27 0.8076 0.9219
IJMEM 0.6392 0.74)6
0.7657 1.0000
Eigenvalues of trie Correlation Matrix
Eigenvalue Difference Proportion Cumulative
MINI
6.10091 5.39272 0.762613 0.76261
PRIN2 0.70815 0.23623 0.088523 0.8511»
PRIN3 0.67195 0.11107 0.056993 0.91011
PRIN* 0.36084 0.19026 0.0*5109 0.9552*
0.17061 0.06792 0.021326 0.97696
0.10269 0.0*877 0.012837 0.999*0
PRIN6
0.05392 0.02 305 0.0067*0 0.9961*
PR IN7
0.03087 0.003858 1.00000
PRINS
E i genvectors
PKIN1 PRIN2 PR IN*
PR1N 3 PR IN5 PR IN6 PRIN7 PRINS
USER7 0.318762 -.21*889 0.82*383 -.228025 -.031923 0.11179* 0.31*636 -.0*5537
SYSTM 0.36*579 -.3B9172 0.079001 0.03762* 0.565260 -.2*5*13 -.57113» 0.015069
I3RE0 0.357106 -.29261* -.206387 0.501528 -.053615 0.6952*3 0.078993 -.0159*7
0.372*0* 0.207673 0.1123*2 0.223770 -.69*572 -.231299 -.653832 0.116619
0.176*11 -.190132 -.277107 0.231785 -.020561 -.992206 O.S73897 -.10*205
RI0R9
0.16067* -.0*1096 -.1*2980 -.61370» -.070193 0.137996 0.077706 0.586976
IOMT
0.295977 0.7*8873 0.150858 0.29*68» 0.627317 0.0*7698 0.13376* 0.2*7387
CPUME
0.37*019 0.273661 -.201655 -.366995 0.011921 0.136069 -.092379 -.792803
IOMEH Actes de CMGF 92 33
ANNEX E III.2
ANALYSE DES TRAVAUX CRAY in t mem/cput
PRIN2
ANNEX E 111.3
ANALYSE DES TRAVAUX CRAY in t mem/cput
PRIN3 34 Actes de CMGF 92
ANNEX E 111.4
ANALYSE DES TRAVAUX CRAY in t mem/cput
PRIN2 Actes de CMGF 92 35
ANNEX E IV.1
tUALYSf JéS TRAVAUX :a*r int mom/cput clisse cou'roem
cl i s s i f i cat i on des JODS cnu-men
FISTCLUb Procedura
K«p l ace-spJLl Rodius:1.5 M.IKCI ustars* 255 Maxiter*!
lniti.il ¿eeris
Cluster USFRT CPUMc
1 1.25700 1.76756
•> -3.4057 3 -2.27590
-0.79646 -0.56825 3
4 0.69355 1.77*41
5 1.17P47 -0.37207
4. -0.07392 2.11789
7 2.03220 -1.74024
1 -1.982S? -1. 52088.
Cluster Sunvnjry
.MS StJ Mrtximuii Distance from Nearest Centroid
Cluster Freijuuncy Deviation Seed to .Ibservjti on Cluster Distance
0.5263 1.3336 1 55 1.8033
2 0. 379"i 1.0258 1.0889 as
3 0.2361 1.0047 1.4085 334
4 0.3726 1.3756 0.8905 272
0.3907 1.1625 1.4112 112
.1. 390.1 0.8905 o 1.4164 «9
0.4907 1.5395 7 1.2557 26
0.3159 1.0889 5 0.d33J 128
Statistics for variables
Vtrijblu Totol SM rfitnin STU R-Squared *S0/<1-RSQ)
'J3FKT 1 . 30000.1 0.397266 0.B43057 5.371728
C?l)ri: 1.03000J 0.325907 0.894374 8.467401
UVER-ALL 1.000000 0.363343 0.868716 6.617049
Pseudo ? Statistic = 1194.45
Approxi.ii it • expected Over-All H-Squared « 0.87647
Cubic Clustering Criterion * -2.529
WAAN1MC: Tne two jbove values jre invalid for correlated variables.
Cluster Means
Cluster USER T CPUHE
2.02843 1.24772
-0.66926 -1.74906
-0.55753 -0.31641
0.21989 1.25310
0.83804 -0.10681
-0.66605 1.34340
1.97049 -1.14976
-1.62763 -1.23220
Cluster Standard Deviations
Cluster USERT CPUME
0.433089 0.605259
0.446360 0.29T908
0.33921u 0.220428
0.366981 0.378158
0.484754 0.265044
0.360379 0.419076
0.424290 0.549211
0.310627 0.321157 36 Actes de CMGF 92
ANNEX E IV.2
ANALYSE DES TRAVAUX CRAY int mem/cpu t classe cpu*mem
classificatio n des jobs cpu-mem
CS)
CP<J U3ERT -, ^ ««°
ronsu
noas n
+
a p i d ir.
i i i i i i | i , i
-1 0
0.1 -i-2.
CPUME
CLUSTER + + +1 + + +2 ---3 + + + 4
*f+ 5 6 + +7 x x x 8
ANNEXE IV.3
ANALYSE DES TRAVAUX CRAY 14:34 Monday,
classification des jobs CDU-fnem
CLUSTER _'RE0_ CPUT DCPU REG OREO PERCENT CUMPRCNT
1
3 334 3.7*7 21.4220 0.78900 1.64680 25.1506 25.1506
3 5 312 67.037 26.5920 1.01919 1.87123 23.4940 48.6446
4 272 13.684 25.6182 5.36514 1.83043 20.4819 69.1265 4 8 128 0.410 22.7865 0.25782 1.70801 9.6386 78.7651
2 85 2.974 25.9837 0.13714 1.84581 6.4006 85.1657 5
l 55 784.851 35.1937 5.33001 2.20827 4.1416 89.3072
5 6 49 2.994 26.6013 5.99075 1.87161 3.6898 92.9970
7 26 696.286 32.7025 0.28514 2.11452 1.9578 94.9548 Actes de CMGF 92 37
ANNEX E V . l
ANALYSE DES TRANSACTIONS TS O
Principal Component Analysis
903 Observations
4 Variables
Simple Statistics
CPUTCBTM CPUSRBTM PGPEXCP AVGHEHSZ
Mean 0.0000000059 O.0O0OO00055 -.0000000067 0.0000000215
StD 0.9999997912 0.9999997507 0.9999997761 0.9999997728
Correlation Matrix
CPUTC3TM CPUSRBTM PGPEXCP AVGHEHSZ
CPUTC8TM 1.0000 0.9766 0.9772 0.7655 TASK«CPU TCB»TIME
CPUSRBTM 0.9765 1.0000 0.9BB6 0.7836 TASK*CPU SRB»TIME
1.0000 0.8U7
PGPEXCP 0.9772 0.9866 EXCPS ISSUE0*BY THIS*PERF GROUP PERIOD
O. 8147 1.0000
AVCMEMSZ 0.7655 0.7836 AVG WORKING*SET(K)F GRPD
Eigenvalues of the Correlation Matrix
Eigenvalue Difference Proportion Cumulative
0.915394
PRIN1 3.66158 3.35817 0.91539
0.30320 0.27781 0.075801 0.99120 2
PRIN3 0.02540 0.01558 0.006349 0.99754
PR IN4 0.00982 0.002455 1.00000
E i genvector s
PRIN1 PRIN2 PR IN3 PRIN4
CPUTCÜTM 0.509808 -. 326640 0.791989 0.078456 TASK*CPU TCB»TIME
CPUSRBTM 0.513694 -.277135 -.507738 0.633554 U SRB*TIME
0.517668 -.183287 -.332382 -.766561 EXCPS ISSUE0*BY THIS*PERF GROUP PERIOD
PGPEXCP
AVGHEHSZ 0.456327 0.884821 0.064387 0.068640 AVG WORKING*SET(K)F GRPD 38 Actes de CMGF 92
ANNEXE V.2
ANALYSE DES TRANSACTIONS TSO
PRIN2
ANNEX E V.3
ANAL Y S E DE S TA AN S AC T I Iti S TSO SU/M *
classificatio n 4ms transactions tso p*r unit? d« servie* run
CLUSTE ? _F « E G_ PERCEN T CPUNI T SHUNI T Ioun f T *30UNIT SU TOT Cr»U CUHPUCNT
114 12.624 6 240.0 2 15.6 9 27 . 25 408.3 3 691.2 9 0.0119 5 12.62 5
23.094 3 1038.9 5 52.5 4 1 M . 30 2002.0 ? 0.09!3 1 35.65 9 208 3271.4 1
24.584 7 24«t.0 8 141.6 ? 527.8 6 5610.0 5 0.121t T 60.24 4 222 8T42.6 8
2T.796 2 9319.5 0 349.7 7 l 324.95 12447.0 4 0.2650 4 89.04 0 751 19841.2 5
9.523 8 19613.1 1 906.4 8 3192.2 2 T2445.0 1 0.9592 9 97.96 4 86 96376.8 2
2. 4 36 3 3469T.6 2 1T45.B 9 5885.8 0 138004.2 6 1.703T 3 100.00 0 22 100311.5 8 Le traitement distribué
avec le modèle client-serveur
P. Marchini
SUN Microsystems France
Traitement distribué
Les acheteurs de solutions de gestion d'informations des années 90
recherchent dess matérielles et logicielles qui permettront à leurs
sociétés d'être davantage compétitives grâce à un accès global à
l'information. Pour y parvenir, trois problèmes doivent être résolus :
• une intégration transparente de matériels muluconstructeurs
• l'intégration de données de différentes sources
• la productivité de l'utilisateur final
Le traitement distribué, ou l'informatique distribuée, qui utilise l'archi­
tecture client-serveur répond à ces défis et satisfait cette notion d'accès
global à l'information. Dans ce modèle, des "clients" consistant en de
puissants systèmes de bureau, interagissent via un réseau haute vitesse
avec des serveurs qui stockent et manipulent les informations. 40 Actes de CMGF 92
Environnements traditionnels Environnement Client-Serveur
Mainframe
Mainframe executant
Systèmes
les applications de base
SPARCstanon™
de données
et de l'utilisateur final
PC exécutant des applications
Les mêmes applications exécutées de type traitements
dans un environnement distribué de texte et tableurs
FIGURE 1
Avant que les ordinateurs de bureau ne deviennent si puissants,
l'environnement informatique de gestion de données se composait
généralement de mini-ordinateurs ou de mainframes auxquels se
connectaient des terminaux ASCII par des lignes série. Aujourd'hui, de
nouvelles applications sont développées ; elles nécessitent un environne­
ment multi-fenêtres et des frontaux graphiques. Les services informati­
ques prennent conscience que l'augmentation de productivité, consé­
quence directe de la convivialité de l'environnement de travail sur un
écran, justifie largement les investissements en nouveaux matérius, en
logiciels et en développement d'application.
Les stations de travail et serveurs SPARC® haute-performance de Sun et
les produits logiciels développés par les sociétés partenaires répondent
aux demandes les plus exigeantes en matière d'informatique distribuée.
Ce résultat repose sur des produits logiciels conçus selon une architecture
client-serveur et sur la gamme complète de serveurs et de stations de
travail SPARC de Sun, basées sur la technologie UNIX®.
Le modèle client-serveur
L'informatiquer emploie des serveurs haute performance et
des systèmes de bureau, permettant aux utilisateurs de répartir leur charge

Un pour Un
Permettre à tous d'accéder à la lecture
Pour chaque accès à la bibliothèque, YouScribe donne un accès à une personne dans le besoin