Techniques de l'Ingénieur

· Méthodologie en matière de performance des systèmes 2002 (article)

1. Concept de modèle
1.1 Développement à partir d’une « feuille blanche »
1.2 Développement à partir d’un système existant
2. Stratégie de modélisation
3. Analyse opérationnelle
3.1 Définition
3.2 Exemple
4. Obtention de mesures
5. Règles empiriques de dimensionnement des systèmes
6. Prévision de la charge
7. Conclusion
Bibliographie

La performance des systèmes dépend d’un grand nombre de paramètres et n’est donc pas simple à appréhender. C’est certainement la raison pour laquelle l’aspect performance dans les projets est souvent traité comme un parent pauvre. L’on ne s’y intéresse qu’en dernier ressort et bien souvent lorsque des problèmes se posent. Il résulte souvent de ce traitement tardif et « à chaud » des résultats médiocres, voire désastreux, pour l’architecture du système. La recherche de meilleures performances conduit souvent à déstructurer le système : des niveaux de virtualisation, qui avaient été introduits pour assurer une certaine indépendance vis-à-vis du matériel ainsi qu’entre les modules logiciel, sont purement et simplement supprimés. Les solutions apportées ne sont que partielles, conduisent bien souvent à une augmentation des coûts et des délais et ont un impact négatif sur la maintenance du système.

L’absence de maîtrise des performances rend difficile la prévision du comportement du système face à des changements tant dans les missions qu’il doit remplir que dans les mutations technologiques qui lui seront apportées au cours de son existence (comme l’incidence d’un changement de processeur ou de réseau local sur le temps de réponse du système). Cette absence de maîtrise rend en outre difficile l’analyse des problèmes de performance rencontrés dans la vie du système.

Nous proposons une méthodologie permettant de traiter, dans le cadre de projets, la performance au moyen de techniques de modélisation.

La modélisation des systèmes informatiques permet d’étudier le comportement des systèmes sur des modèles et non sur le système lui-même. De cette façon, il est possible de prévoir le comportement du système vis-à-vis de changements dans ses missions ou dans les technologies utilisées pour sa réalisation. L’alimentation de tels modèles nécessite des données, qui sont fournies par des mesures ou des estimations. La modélisation et la mesure sont deux activités distinctes mais complémentaires. Elles sont nécessaires à l’activité de l’architecte système, et elles apportent l’aspect quantitatif à une activité qui a quelquefois tendance à se cantonner au qualitatif. La modélisation peut s’appliquer tout au long du cycle de vie du système : depuis la phase de conception jusqu’à la vie opérationnelle du système. En ce qui concerne la vie opérationnelle du système, on peut remarquer que celui-ci est soumis à des demandes de modification de mission (services qu’il doit rendre) ainsi qu’à des modifications de sa technologie (rajeunissement de certains composants rendu nécessaire par leur retrait du marché). Il est utile, pour maîtriser de tels changements, d’évaluer a priori et donc de valider l’impact des changements sur le comportement du système avant de les appliquer.

En résumé, on peut caractériser l’apport de la modélisation aux différentes phases de la vie d’un système de la façon suivante :

• phase de conception :
• choix entre différents types d’architecture,
• dimensionnement des différents composants du système,
• étude de la sensibilité du comportement du système à différents paramètres ;
• phase d’implémentation :
• analyse de l’impact de modifications d’architecture ou de dimensionnement de composants,
• analyse de l’impact de non-atteinte d’objectifs de performance sur la performance globale du système ;
• phase d’exploitation :
• analyse de l’impact de changements de mission ou de remplacement de composants,
• aide à l’analyse de problèmes de performance rencontrés.

On peut distinguer trois grandes approches méthodologiques dans le domaine de la performance :

• l’intuition ;
• les mesures ;
• la modélisation.

L’intuition se fonde sur l’expérience. Elle est peu coûteuse mais ses possibilités sont limitées tant en ce qui concerne la fiabilité que la complexité. En effet, malgré l’expérience, les erreurs sont possibles et, au-delà d’une certaine complexité, il n’est plus possible de répondre.

En revanche, les mesures ne souffrent pas de l’imprécision mais elles sont difficiles à mettre en œuvre et elles représentent un coût important. L’interprétation des mesures n’est pas aisée car on néglige souvent le fait qu’une bonne interprétation des résultats passe par la compréhension de la dynamique du système. L’inconvénient majeur de cette approche réside dans le fait que le système doit exister (ou du moins dans un état de développement suffisamment avancé pour que les mesures puissent être représentatives du comportement du système).

La modélisation peut être vue comme un compromis entre l’intuition et la mesure. Elle est plus fiable que l’intuition car elle se fonde sur la dynamique du système et elle permet de détecter des effets secondaires. Elle est plus souple que les mesures car l’étude de l’incidence de modifications ne nécessite que le changement du modèle et/ou de ses paramètres. Elle présente l’avantage majeur, par rapport aux mesures, de ne pas impliquer l’existence du système.

Notre exposé est concentré sur la modélisation de la performance des systèmes. Mentionnons que la démarche proposée s’applique aussi bien à la disponibilité des systèmes (estimation de l’impact d’une stratégie de réparation d’un système sur sa disponibilité, par exemple) qu’à l’estimation des coûts et des délais de développement. En matière de performance, l’ouvrage de référence est [2].

Un modèle permet d’étudier et de valider l’impact de modifications sur le modèle et non plus sur le système. La technique de modélisation présentée s’appuie sur les réseaux de files d’attente. Les stratégies de modélisation sont ensuite appliquées à deux cas extrêmes : le développement d’un système à partir d’une « feuille blanche » et à partir d’un système existant. La réalité se situe entre ces deux extrêmes et la démarche à mettre en œuvre s’inspire de celles présentées pour ces deux cas. Les critères de choix d’une stratégie de modélisation sont présentés. Nous introduisons ensuite l’analyse opérationnelle qui est une technique permettant, à partir de mesures, de dériver des conclusions fort utiles. Quelques indications sur les outils qui permettent, sur des systèmes d’exploitation standard, d’obtenir les chiffres nécessaires à la mise en œuvre de l’analyse opérationnelle sont données. Un certain nombre de règles empiriques ont été proposées pour le dimensionnement des systèmes. La méthodologie de prévision de la charge conclue l’exposé.

Nota : Cet article est repris quasi intégralement de l’un des chapitres de l’ouvrage « Serveurs multiprocesseurs, clusters et architectures parallèles » que l’auteur a publié chez Eyrolles en 2000 [1]. Par rapport au texte publié dans cet ouvrage, différents éléments, en provenance d’autres chapitres du même ouvrage ainsi que d’autres sources, ont été ajoutés pour donner le contexte nécessaire à un article indépendant d’une part et pour refléter les derniers développements d’autre part.

· Performance des processeurs et des systèmes 2001 (article)

1. Définitions
2. Niveau processeur
3. Serveurs
3.1 Bancs d’essai SPEC
3.1.1 SPEC SFS97
3.1.2 SPECweb99
3.1.3 SPECjvm98
3.1.4 SPEChpc96
3.1.5 SPEComp2001
3.1.6 SPECmail2001
3.2 TPC
3.2.1 TPC-C, banc d’essai transactionnel
3.2.2 TPC-H et TPC-R, bancs d’essai décisionnels
3.2.3 TPC-W, applications commerciales sur le web
3.2.4 Une tentative intéressante : le TPC-E
4. Stations de travail
4.1 BAPCo SYSmark 2000
4.2 BAPCo/MadOnion.com, WebMark 2001
4.3 Ziff-Davis
5. Conclusion concernant les bancs d’essai
Bibliographie

La performance des systèmes ne peut s’exprimer par la simple liste des performances élémentaires (processeur, mémoire, entrées-sorties, disques, etc.). Ces chiffres, pour utiles qu’ils soient, ne reflètent pas la performance des systèmes sur des applications concrètes et ne permettent pas des comparaisons entre différents systèmes. Devant le besoin exprimé par les utilisateurs d’effectuer ces comparaisons, les acteurs du domaine (constructeurs informatiques, fournisseurs de systèmes d’exploitation ou de middlewares, tels que systèmes de gestion de bases de données, moniteurs transactionnels ou serveurs web) ont défini en commun des bancs d’essai de performance (« benchmarks ») pour différents types d’applications des systèmes. Nous désignons sous les termes banc d’essai de performance (benchmark dans la littérature anglo-saxonne, que nous traduirions plus volontiers par étalon de performance), une spécification – qui peut être accompagnée de programmes en langage source – définissant de façon précise les conditions dans lesquels les mesures doivent être réalisées. Ils sont censés être représentatifs des cas d’utilisation concrets. Nous reviendrons à la fin de cet article sur la représentativité de ces bancs d’essai et sur les interprétations qu’il convient d’en faire.

Nous examinons ici successivement les performances au niveau processeur et au niveau système (serveurs et stations de travail, PC essentiellement). Nous ne traitons pas en détail les bancs d’essai relatifs aux applications de type traitement numérique intensif.

Par ailleurs [H 2 548], nous proposons une méthodologie pour aborder les aspects performance dans les projets, ainsi que l’analyse opérationnelle. C’est une technique simple qui permet de prédire, à partir de données pouvant être aisément obtenues, le comportement d’un système et ses limites. Puis nous abordons les techniques de gestion et de prévision de la charge des systèmes (« capacity planning »).

Nota : Cet article s’inspire étroitement de l’un des chapitres de l’ouvrage « Serveurs multiprocesseurs, clusters et architectures parallèles » que l’auteur a publié chez Eyrolles en 2000 [1]. Le contenu a toutefois été complété pour rendre compte des évolutions intervenues depuis la rédaction de l’ouvrage et intégrer les bancs d’essai de performances pour les PC.

· Serveurs multiprocesseurs et SGBD parallélisés 2001 (article)

1. Introduction aux applications des SGBD
2. Options d’architecture
2.1 Serveurs multiprocesseurs
2.2 Options d’architecture pour la liaison serveur/disques
3. Introduction au parallélisme et problématique des SGBD parallélisés
3.1 Éléments d’introduction au parallélisme
3.2 Définition des systèmes parallèles
3.3 Architectures de systèmes
4. Architecture des SGBD parallélisés
4.1 Exécution des requêtes
4.2 Partitionnement des données
5. IBM DB2 Universal Database Enterprise-Extended Edition
6. Oracle Parallel Server
6.1 Terminologie propre à Oracle
6.2 Description d’OPS
7. NCR WorldMark 5250
8. Comparaison des architectures
8.1 Comparaison de l’efficacité des SMP et des clusters
8.2 Comparaison des options d’architecture pour la liaison système/disque
9. Conclusion
Pour en savoir plus
De plus en plus d’applications s’appuient sur des systèmes de gestion de bases de données (SGBD). La performance des systèmes et leur disponibilité sont devenues des éléments clés pour le choix des systèmes et des SGBD, c’est la raison pour laquelle les SGBD cherchent à tirer le meilleur profit des ressources matérielles qui sont mises à leur disposition.

Cet article présente les différentes approches mises en œuvre au sein des SGBD actuellement commercialisés.

On examine les différentes options en matière d’architecture de système ainsi que la relation entre les SGBD et le stockage des données. Ces différentes options sont détaillées et leurs conditions d’utilisation sont analysées.

Nota : Cet article est repris quasi intégralement d’un des chapitres de l’ouvrage du même auteur « Serveurs multiprocesseurs, clusters et architectures parallèles » [4] :Différents éléments, en provenance d’autres chapitres du même ouvrage, ont été ajoutés pour donner le contexte nécessaire à un article indépendant. Par ailleurs, des mises à jour ont été faites pour refléter les derniers développements.La part de l’article consacrée à Oracle est plus importante que celle consacrée à DB2 Universal Database Enterprise-Extended Edition ce qui ne reflète pas une différence d’appréciation entre ces produits mais est simplement dû au fait que l’auteur a eu accès à plus d’informations sur Oracle.

· Microprocesseurs - Mise en oeuvre et exemples d'application 2000 (article)
Actualisé par Dominique HOUZET

1. Packaging
2. Méthodes et outils de développement
2.1 Matériel
2.2 Logiciel
2.3 Boundary scan (registre à décalage périphérique)
2.4 Capacité d"autotest
3. Critères de choix d"une architecture et évaluation
4. Perspectives
4.1 Utilisateurs
4.2 Producteurs
5. Exemples d"application
5.1 Station de travail d"entrée de gamme
5.2 Contrôleur d"imprimante laser
5.3 Applications dans le domaine de l"ATM
Pour en savoir plus

L"objectif de cet article est de permettre au lecteur d"apprécier l"intérêt des microprocesseurs en illustrant à l"aide d"exemples les aspects pratiques de leur utilisation.

Le premier point concerne leur mise en œuvre matérielle qui se traduit par la réalisation physique des composants, qui n"est pas abordée ici, et par leur mise en boîtier, présentée dans le premier paragraphe. La technologie des boîtiers de circuits intégrés est en évolution constante. Ce paragraphe se propose d"en présenter les différentes orientations.

La mise en œuvre pratique des microprocesseurs passe d"une part par l"utilisation d"outils de développement, et d"autre part par le choix du microprocesseur lui-même. Ce choix est guidé par de nombreux critères qui sont détaillés dans cet article. Les outils et méthodes de développement des microprocesseurs concernent à la fois la mise en œuvre matérielle de la carte électronique et celle du logiciel exécuté sur le microprocesseur choisi. Ces différents moyens de développement sont présentés dans le second paragraphe.

Les progrès sans cesse croissants de la technologie permettent aux concepteurs d"innover en termes d"architecture de microprocesseurs. L"évolution des caractéristiques des microprocesseurs est liée à de nombreux facteurs qui permettent d"anticiper et donc de mieux gérer les adaptations nécessaires des systèmes à base de microprocesseurs.

L"intérêt des microprocesseurs sera illustré grâce à plusieurs exemples d"applications architecturées autour d"un microprocesseur standard. Il s"agit en particulier d"une station de travail d"entrée de gamme, d"un contrôleur d"imprimante laser et d"un routeur de réseau ATM. Ces trois exemples sont significatifs des types d"applications nécessitant la mise en œuvre de microprocesseurs.

· Systèmes à haute disponibilité - Solutions 1999 (article)

1. Solutions de type matériel à la continuité de service
1.1 Pair and Spare de Stratus
1.2 Système Integrity S4000 de Tandem
1.3 Système NETRA ft 1800 de Sun Microsystem
1.4 Système Integrity S2 de Tandem à vote majoritaire
1.5 Sous-systèmes RAID
2. Solutions de type logiciel à la continuité de service
2.1 Système NonStop Himalaya S7000 de Tandem
2.2 Solutions de type Cluster (NT/UNIX)
2.2.1 Généralités
2.2.2 Exemple de cluster UNIX - IBM HACMP/Bull Power Cluster
2.2.3 Microsoft Cluster Server (MSCS)
2.3 SafeTech
3. Évaluation de la disponibilité des systèmes
3.1 Prévision des fautes : AMDEC et arbre de défaillances
3.1.1 AMDEC et AEEL
3.1.2 Arbre de défaillance
3.2 Évaluation quantitative de la disponibilité
3.2.1 Chaînes de Markov
3.2.2 Modèles de croissance de la fiabilité du logiciel
4. Recouvrement après catastrophe
5. Synthèse et perspectives
5.1 Synthèse
5.2 Perspectives
Pour en savoir plus

On a choisi dans cet article, après avoir rappelé les concepts de base dans [H 2 508], de se concentrer sur les solutions permettant de construire des systèmes à haute disponibilité.

L'exposé est volontairement limité aux solutions applicables à la plupart des systèmes informatiques des entreprises. Ainsi, les solutions pour les systèmes à très forte criticité tels les systèmes de pilotage de processus de production chimique, de contrôle du fonctionnement de centrales nucléaires, de pilotage d'avions ou de véhicules ne sont pas abordées dans cet article.

Dans les paragraphes 1. et 2. sont exposées les solutions proposées par les constructeurs de systèmes informatiques et les fournisseurs de systèmes d'exploitation. On a classé ces solutions en deux grandes catégories :

les solutions de type matériel à la continuité de service ;
les solutions de type logiciel à la continuité de service.
Comme on le verra, l'une des solutions proposées 2.1. allie les deux approches : solution de type matériel complétée par une solution de type logiciel.

En général, ces solutions ont en commun, au niveau de la plate-forme système, le recours systématique aux techniques de masquage telles que les codes détecteurs/correcteurs d'erreurs, les chemins doubles entre les ressources matérielles...

Les solutions de type matériel ont pour objectif la tolérance aux défaillances du matériel. Elles utilisent la redondance. Les défaillances au niveau du matériel ne sont pas visibles des applications (si ce n'est un temps de réponse sensiblement accru lors de l'occurrence d'une telle défaillance, ce temps de réponse redevient ensuite tout à fait normal). Ce type de solution ne permet pas de masquer les défaillances du logiciel.

Les solutions de type logiciel ont le double objectif de tolérer à la fois les défaillances du matériel et aussi les défaillances du logiciel. En ce qui concerne le logiciel, qu'il soit système ou d'application, la tolérance aux fautes concerne essentiellement les fautes de type Heisenbug (fautes transitoires).

Il convient de noter que toutes les marques citées dans cet article sont la propriété de leurs titulaires respectifs.

· Systèmes à haute disponibilité - Concepts 1999 (article)

1. Définitions et classement
2. Terminologie et concepts de base
2.1 Définitions
2.2 Concepts de base
2.3 Grandeurs caractéristiques de la disponibilité des systèmes
2.4 Mesures
2.4.1 Mesures liées au concept de service
2.4.2 Mesures liées au concept de défaillance
2.4.3 Mesures liées au concept de défaut
2.4.4 Mesures liées au concept de maintenabilité d'un système
2.4.5 Mesures liées au concept de disponibilité d'un système
2.5 Analyse des causes des défaillances
2.6 Modes de défaillance
2.7 Choix des composants à rendre disponibles
3. Principes de conception et introduction aux solutions
3.1 Concept d'état d'un système
3.2 Principes
3.2.1 Modularité
3.2.2 Fail Fast
3.2.3 Indépendance des modes de défaillance
3.2.4 Redondance et réparation
3.2.5 Elimination des points de défaillance uniques
3.3 Application au logiciel
3.4 Application au matériel
Pour en savoir plus

De plus en plus les activités sont dépendantes de ressources informatiques. La disponibilité de ces ressources informatiques, c'est-à-dire leur capacité à assurer le service spécifié et le degré de confiance que l'utilisateur peut accorder aux services rendus par les systèmes informatiques sont devenus des exigences des utilisateurs et donc des propriétés essentielles de ces systèmes.

Les systèmes informatiques étant sujets aux défaillances, les concepteurs de ces systèmes ont recherché les moyens de pallier ces défaillances.

Le concept de sûreté de fonctionnement est né au cours des années 1980 pour caractériser ce besoin. La sûreté de fonctionnement d'un système est la propriété qui permet à un utilisateur de placer une confiance justifiée dans le service que ce système délivre. C'est la propriété et les caractéristiques d'une entité ayant rapport au temps qui lui confère l'aptitude à satisfaire les besoins exprimés ou implicites pour un intervalle de temps donné et des conditions d'emploi fixées (X 50-125, norme de management de la qualité et de l'assurance de la qualité, standard ISO 8402). C'est l'ensemble des aptitudes d'un produit lui permettant de disposer des performances fonctionnelles spécifiées, au moment voulu, pendant la durée prévue, sans dommage pour lui-même et pour son environnement.

On appelle critique une fonction d'un système ou d'un sous-système pour laquelle la propriété de sûreté de fonctionnement est une contrainte stricte. En d'autres termes, un défaut de fonctionnement peut entraîner la perte de la mission ou des dommages inadmissibles sur le système ou son environnement.

Dans l'article [H 2 509] sont exposées les solutions proposées par les constructeurs de systèmes informatiques et les fournisseurs de systèmes d'exploitation.

Nota : Il convient de noter que toutes les marques citées dans cet article sont la propriété de leurs titulaires respectifs.

· Microprocesseurs 1998 (article)

· Microprocesseurs. Performances et méthodes de développement 1998 (article)

1. Indicateurs de performance
1.1 Performance au niveau des processeurs (SPEC)
1.2 Performance au niveau système
1.2.1 SPEC
1.2.2 TPC
2. Méthodes et outils de développement
2.1 Méthodes et outils de développement du matériel
2.2 Méthodes et outils de développement du logiciel
2.3 Boundary Scan (JTAG)
2.4 Capacité d’autotest
3. Critères de choix d’une architecture de microprocesseur
4. Perspectives
4.1 Utilisateurs de microprocesseurs
4.2 Producteurs de microprocesseurs
4.3 Point de vue économique
4.4 Point de vue de la technologie
4.5 Point de vue des concepteurs
Pour en savoir plus

Cet article présente les différents étalons permettant d’exprimer la performance, tant au niveau des microprocesseurs, qu’au niveau des systèmes. Sont ensuite donnés les méthodes et outils utilisés pour le développement et la mise au point de systèmes à base de microprocesseurs. Les critères de choix d’une architecture de microprocesseur vis-à-vis d’un besoin exprimé et une méthodologie sont ensuite présentés. L’article se termine par une perspective en ce qui concerne les microprocesseurs.

· Microprocesseurs - Exemples d'architectures 1998 (article)

1. Architecture Intel IA 32
1.1 Représentation des données
1.2 Instructions de l’IA-32
1.3 Description d’une implémentation de l’IA-32 : le Pentium II
1.4 Support multiprocesseur
2. Architecture du PowerPC
2.1 Représentation des données
2.2 Instructions du PowerPC
2.3 Description d’une implémentation du PowerPC : le 604e
2.4 Support multiprocesseur
Pour en savoir plus

Dans cet article, on a choisi d’illustrer notre propos avec les microprocesseurs des deux familles les plus importantes en termes de part de marché que sont IA-32 et PowerPC. Bien évidemment ce choix ne saurait constituer un jugement de valeur, en particulier vis-à-vis des qualités des autres familles de microprocesseurs.

· Microprocesseurs - Architectures et performances 1998 (article)

1. Architecture des microprocesseurs
1.1 Adressage
1.1.1 Structuration de l’espace d’adresse
1.1.2 Protection
1.1.3 Notions d’adressage et de mémoire virtuelle
1.1.4 Mécanismes de support de la mémoire virtuelle
1.1.5 Vision système de l’espace d’adressage
1.2 Architecture des répertoires d’instructions
1.2.1 Types de données manipulées
1.2.2 Représentation des données
1.2.3 Modes d’adressage
1.2.4 Instructions
1.3 Entrées-sorties
1.4 Concept de cache
1.5 Support des architectures multiprocesseurs
2. Techniques d’amélioration de la performance
2.1 Structures : pipeline et superscalaire
2.1.1 Machine de base avec pipeline
2.1.2 Machine superscalaire
2.1.3 Variations sur les principes pipeline et superscalaire
2.1.4 Comparaison des structures superscalaire et superpipeline
2.2 Machine VLIW
2.3 Exécution spéculative
2.4 Exécution dans le désordre
2.5 Prédiction de branchement
2.6 Renommage de registres
Pour en savoir plus

L’objectif de cet article est de donner une synthèse des éléments les plus importants en matière d’architecture des microprocesseurs. Si les ressources limitées de la technologie des microprocesseurs avaient conduit les concepteurs des premiers microprocesseurs à en limiter le niveau de fonctionnalité, les progrès de cette même technologie font que la progression en matière d’architecture de système a été bien plus importante au niveau des microprocesseurs que de toute autre implémentation des architectures. Ainsi, les microprocesseurs de haut de gamme actuels mettent en œuvre des techniques d’amélioration des performances qui avaient été introduites dans les super-ordinateurs des années 1960 (caches, pipeline, unités fonctionnelles multiples, exécution spéculative...).

Il convient aussi de souligner que les architectures de mainframes et de mini-ordinateurs ont été implémentées sous forme de microprocesseurs dans le but de réduire les coûts de fabrication de ces systèmes. Toutefois, les implémentations des architectures « propriétaires » sous forme de microprocesseur ne se sont pas traduites par une ouverture de ces architectures (nouvelles applications, élargissement de la base de clientèle...).

Cette introduction à l’architecture des microprocesseurs ne fait pas seulement référence aux seuls microprocesseurs, mais place ceux-ci dans le contexte plus général de l’évolution de l’architecture des processeurs.

Il convient de rappeler que la quasi-totalité des techniques d’amélioration de la performance utilisées dans les microprocesseurs ont été initialement introduites dans les machines de haut de gamme ! Cette simple remarque pour nous rappeler « qu’il n’a pas que du nouveau sous le soleil », mais que les progrès de la technologie rendent maintenant des techniques, autrefois réservées à des systèmes très coûteux, applicables à des objets s’approchant de la grande diffusion.

· Microprocesseurs - Classification des architectures 1998 (article)

1. Classification des architectures de microprocesseurs
1.1 Caractéristiques générales des microprocesseurs
1.2 Équation de base de la performance
1.3 Classification des architectures
1.3.1 Classification en fonction des caractéristiques de l’architecture
1.3.2 Classification en fonction de l’utilisation
1.4 Historique des architectures RISC
1.5 Concepts de IA-64 (EPIC)
2. Relation des architectures de microprocesseur avec le logiciel
2.1 Compilateurs
2.2 Systèmes d’exploitation
2.3 Niveaux de compatibilité
2.4 Migration d’architectures
Pour en savoir plus

Après une caractérisation des microprocesseurs, cet article présente une classification des architectures, tout d’abord en fonction de leur type d’architecture puis de leur usage. Les architectures de type RISC (Reduced Instruction Set Computer) (machines à jeu d’instructions réduit) ont été ces dernières années un facteur déterminant de l’augmentation de la performance des microprocesseurs, aussi il nous a semblé utile d’en rappeler ici l’histoire. Ce paragraphe se termine par une présentation des concepts de l’architecture IA-64 présentée par Intel et HP en octobre 1997.

On explicite ensuite les relations qui existent entre les architectures de microprocesseur et le logiciel de base : compilateurs et systèmes d’exploitation. Les différents niveaux de compatibilité et leurs implications sont ensuite discutés. L’article se termine par une description des techniques de migration d’architectures, c’est-à-dire des techniques qui permettent de supporter sur une architecture des programmes — au niveau binaire — qui fonctionnaient sur une autre architecture. Ce genre de technique permet d’exploiter le potentiel de performance des nouvelles architectures (et de leurs implémentations) pour « récupérer » l’existant.

· Microprocesseurs - Introduction 1998 (article)

1. Évolution technologique
2. Évolution des performances
3. Marché des microprocesseurs

Dans ces articles, les microprocesseurs sont abordés sous l’angle de leur architecture et de leur utilisation et non pas sous l’angle de la technologie et des processus industriels qui en permettent l’existence. En particulier, les relations avec le logiciel : systèmes d’exploitation et compilateurs y sont abordés.

Le terme architecture fait référence au répertoire d’instructions utilisable par les programmeurs : c’est l’interface entre le matériel et le logiciel. On parle, aussi d’implémentation d’une architecture : ce terme désigne une réalisation particulière d’une architecture, ici sous la forme d’un microprocesseur. Une même architecture est susceptible d’avoir plusieurs implémentations répondant par exemple à des objectifs différents en matière de performance, de consommation d’énergie… Du point de vue du logiciel d'application, ces différentes implémentations sont compatibles. Ainsi, des systèmes fondés sur des implémentations différentes peuvent exécuter les mêmes programmes.

Devant la variété des microprocesseurs disponibles et plutôt que de traiter superficiellement l’ensemble du sujet, après l’exposé général de chacun des aspects, sont développés les microprocesseurs de haut de gamme.

· Architecture des serveurs 1997 (article)

1. Analyse des besoins
2. Évolution des technologies
2.1 Performance
2.1.1 Processeurs
2.1.2 Mémoires
2.2 Hiérarchie de mémoire
2.3 Parallélisme
2.4 Contrainte de compatibilité binaire
2.5 Architecture 64 bits
2.6 Systèmes d’exploitation
2.7 Sous-systèmes de stockage
2.8 Sous-systèmes de communication
3. Options d’architecture
3.1 Multiprocesseurs symétriques (SMP)
3.2 Clusters
3.3 Machines massivement parallèles (MPP)
3.4 Synthèse des caractéristiques d’architecture
4. Relations entre les architectures de systèmes et de RDBMS
5. Comparaison des architectures SMP, cluster et MPP
5.1 Caractéristiques des SMP
5.2 Caractéristiques des clusters
5.3 Caractéristiques des MPP
5.4 Modèles de programmation
6. Performance des serveurs
6.1 Performance des processeurs
6.2 Performance au niveau système
6.2.1 SPEC
6.2.2 TPC
7. Perspectives
Pour en savoir plus

Les serveurs sont devenus l’un des éléments essentiels dans l’infrastructure informatique des sociétés. Dans le schéma traditionnel de l’informatique des entreprises tel qu’on l’a connu jusqu’au milieu de la décennie précédente, l’ordinateur de type « mainframe » centralisait l’information et les connections des stations de travail qui n’étaient autres que des terminaux sans intelligence. L’avènement des stations de travail intelligentes (PC), la diminution rapide des coûts du matériel, la mise en place progressive des architectures distribuées avec le client/serveur et l’évolution d’une informatique de production vers une informatique plus stratégique intégrant le support à la décision ont conduit au concept de serveur. Cette diminution des coûts du matériel a aussi entraîné le passage du serveur multifonction (un même système supportant plusieurs applications portant sur des données communes ou indépendantes) au serveur dédié.

Le propos de cet article est d’introduire et de commenter les différentes options en matière d’architecture de serveur. L’une des fonctions principales des serveurs est le support des bases de données d’une part pour les applications transactionnelles en ligne (On Line Transaction Processing OLTP) et d’autre part pour l’aide à la décision (Decision Support Systems DSS).

Les exigences de ces applications en matière de disponibilité et de performance ont conduit à des solutions adaptées tant au niveau du matériel que du logiciel. En particulier les gestionnaires de bases de données relationnelles (Relational Data Base Management Systems : RDBMS) sont capables d’exploiter le parallélisme. Cet article étudie donc les différentes options d’architecture de serveur en relation avec les architectures des gestionnaires de bases de données relationnelles et compare leurs avantages et inconvénients respectifs. Les architectures multiprocesseurs symétriques (Symmetric MultiProcessing : SMP), les clusters et les machines massivement parallèles (Massively Parallel Processing : MPP) sont examinés ainsi que leurs évolutions (exemple : architecture CC-NUMA pour les multiprocesseurs symétriques ; § 3.1.).

Caractéristiques comparées des systèmes transactionnels et des systèmes d’aide à la décision
Systèmes transactionnels	Systèmes d’aide à la décision
Partage : base de données partagée (lecture et mise à jour) par l’ensemble des utilisateurs.	Partage : bases de données en lecture essentiellement partagées par un petit nombre d’utilisateurs et souvent distinctes des bases de production. Des bases spécialisées peuvent être créées pour des populations particulières d’utilisateurs (datamarts).
Flux de requête irrégulier : les requêtes individuelles des utilisateurs ne peuvent pas être planifiées.	Flux de requête irrégulier : les requêtes individuelles des utilisateurs ne peuvent pas être planifiées.
Travail répétitif : les utilisateurs demandent au système l’exécution de fonctions appartenant à un ensemble prédéfini (typiquement de 100 à 1 000 fonctions).	Travail non répétitif : les utilisateurs demandent au système l’exécution de requêtes variées ne correspondant pas à un répertoire préétabli.
Fonctions simples : la plupart des fonctions sont peu complexes (typiquement de 105 à 107 instructions et environ 10 entrées/sorties).	Fonctions complexes : les requêtes sont souvent complexes et mettent en jeu un grand volume de données.
Transactions de type « batch » : il existe quelques transactions qui ont une durée égale à celle des travaux « batch », elles se distinguent de ces travaux par leurs propriétés ACID.	Transactions de type « batch » Certaines requêtes particulièrement longues peuvent être exécutées en « batch ».
Grand nombre de terminaux : pour les grands systèmes, de 1 000 à 10 000 terminaux.	Petit nombre de stations de travail.
Clients intelligents : stations de travail, PC, autres systèmes.	Clients intelligents : stations de travail et PC.
Haute disponibilité : exigence typique des systèmes transactionnels.	La haute disponibilité n’est pas une exigence des systèmes d’aide à la décision.
Recouvrement effectué par le système : l’intégrité des données doit être assuré automatiquement. Le recouvrement est fondé sur les propriétés ACID.
Taille des bases de données : proportionnelle à l’activité de la société.	Taille des bases de données : proportionnelle à l’historique de l’activité de la société.
Peu de données touchées par une transaction.	Beaucoup de données touchées par une requête.
Équilibrage de charge automatique : haut débit et temps de réponse garantis.	Recherche de la performance au moyen du parallélisme intra-requête.

 

http://www.techniques-ingenieur.fr