basé sur l'environnement informatique multi-pipeline reconfigurable L-Net

L'une des tâches urgentes dans le domaine des systèmes de commande est le développement de logiciels pour les systèmes de commande distribués tolérants aux pannes. Les solutions existantes dans ce domaine aujourd'hui sont propriétaires, de ce fait, coûteuses et pas toujours efficaces.

Ces solutions ne prévoient pas l'utilisation efficace des ressources des bases redondantes, techniques et logicielles, ce qui affecte négativement à la fois la tolérance aux pannes et l'évolutivité de telles solutions. Si l'architecture du réseau est violée, il n'y a aucune possibilité de reconfiguration dynamique à la fois des processus de traitement de l'information et de la transmission des flux de données (à la fois de contrôle et d'information). L'utilisation de microcontrôleurs spécifiques, l'utilisation de DCS / SCADA complique le développement et le support des systèmes, l'extension de leurs fonctionnalités.

Architecture du système de contrôle distribué

L'architecture typique généralisée d'un système de contrôle distribué (DCS) comprend trois niveaux hiérarchiquement liés : le niveau opérateur, le niveau de contrôle et le niveau d'E/S (voir Fig. 1).

La tâche principale du niveau opérateur est de fournir une interface homme-machine (IHM) pour assurer la configuration et le contrôle du fonctionnement de l'ensemble du système. Le niveau de contrôle est responsable de la réception et du traitement des données des capteurs, de la transmission des données au niveau de l'opérateur et de la génération des actions de contrôle sur les actionneurs. Le niveau E/S représente les capteurs et actionneurs directement connectés à l'objet contrôlé.

La tâche du logiciel, dans le cadre de l'architecture généralisée du DCS, est d'assurer le fonctionnement du niveau opérateur et sa connexion avec le niveau contrôle du système. Par conséquent, le niveau fondamental dans la conception du logiciel et la résolution des problèmes d'interaction avec le matériel est celui de l'opérateur. Le logiciel doit tirer le meilleur parti des ressources matérielles disponibles du système tout en étant aussi indépendant que possible de l'architecture interne du matériel.

Le matériel fournit des ressources informatiques, de la mémoire et des supports de communication entre les nœuds d'un système. Lors de la conception de l'architecture générale du système, les nœuds spécifiques du niveau d'E/S qui lui seront connectés dans une implémentation spécifique ne sont pas pris en compte ; par conséquent, le niveau opérateur et le niveau de contrôle sont pris en compte dans l'architecture générale. Le matériel doit être répandu, être conforme aux normes modernes et posséder toutes les propriétés et capacités nécessaires à la mise en œuvre de l'architecture.

Exigences DCS

Les exigences du DCS s'appliquent non seulement au système dans son ensemble, mais également à ses composants matériels et logiciels séparément, car les approches spécifiques pour répondre à ces exigences pour ces composants peuvent être fondamentalement différentes. Le DCS doit avant tout être tolérant aux pannes. La méthode la plus simple pour augmenter la tolérance aux pannes est la redondance (duplication) des unités fonctionnelles ou de leur agrégat. La deuxième propriété importante est l'évolutivité. L'évolutivité est basée sur la mise en œuvre d'algorithmes spéciaux dans le logiciel et la capacité matérielle de remplacer et d'ajouter de nouveaux nœuds ou leurs composants. Dans le même temps, le système doit rester simple pour son fonctionnement, le développement de nouveaux nœuds ou modules et la modification de son architecture.

Présentation des architectures DCS

Pour la revue des architectures DCS, nous avons choisi Siemens SIMATIC PCS 7 DCS comme l'un des plus demandés sur le marché et RTS S3 comme DCS implémenté sur la base de QNX RTOS.

Siemens SIMATIC PCS 7

L'architecture du système possède toutes les propriétés d'une architecture DCS générique. Les stations opérateur sont des ordinateurs basés sur une architecture de processeur x86 avec un système d'exploitation Windows et un package Siemens WinCC, qui fournit une IHM. Il existe des serveurs avec des bases de données. Les stations opérateur, les stations d'ingénierie et les serveurs sont reliés par un réseau local basé sur Ethernet. Le niveau opérateur est lié au plan de contrôle du réseau Industrial Ethernet redondant. Au niveau du contrôle, il existe des automates programmables (PLC) avec possibilité de redondance en raison de la duplication des fonctionnalités. Il est possible de se connecter à des systèmes et réseaux externes et d'organiser un accès à distance au système.

RTS S3

Cette architecture est également constituée des couches de la structure généralisée du DCS. Les stations opérateur sont basées sur la même plate-forme matérielle que dans le SIMATIC DCS, mais peuvent être exploitées sous les systèmes d'exploitation Windows et Linux. Les stations d'ingénierie sont combinées avec des stations opérateur. Le système fournit un environnement de développement d'applications unifié. Un réseau Ethernet connecte les nœuds de la couche porteuse et le niveau opérateur lui-même au plan de contrôle à l'aide de la pile de protocoles TCP/IP. Au niveau du contrôle, il existe des ordinateurs industriels exécutant QNX OS avec leur propre base de données et la possibilité de redondance en dupliquant la fonctionnalité du nœud.

Inconvénients des systèmes décrits

Les systèmes décrits ci-dessus utilisent une plate-forme matérielle/logicielle différente pour le niveau opérateur et le plan de contrôle. Au niveau opérateur, une seule architecture de processeur peut être utilisée et une station d'ingénierie spéciale est nécessaire pour configurer et développer le niveau de contrôle. Ces DCS offrent uniquement une redondance matérielle avec duplication de la fonctionnalité du nœud redondant afin d'augmenter la tolérance aux pannes, ce qui est une utilisation irrationnelle du matériel redondant.

Caractéristiques et caractéristiques fonctionnelles du système L-Net

Lors du développement du système L-Net, la tâche consistait à créer un système de contrôle qui aurait les caractéristiques suivantes :

• Reconfiguration dynamique avec récupération complète avec une perte minimale en cas de panne de l'hôte ou de perturbation de la topologie du réseau.
• Répartition efficace des tâches entre les nœuds de réseau efficaces disponibles.
• Duplication des canaux de communication entre nœuds avec reconfiguration dynamique des flux de transmission de données.
• Facilité d'utilisation et évolutivité du système.
• Portabilité et performances du système sur n'importe quelle plate-forme matérielle conçue pour les systèmes de contrôle-commande et les systèmes embarqués.

Pour construire un système avec les caractéristiques ci-dessus, un système d'exploitation est nécessaire, qui est principalement destiné à créer des systèmes de contrôle et des systèmes embarqués. L'analyse des systèmes d'exploitation existants a montré que le système d'exploitation le plus approprié est QNX 6 (Neutrino), qui dispose d'une allocation de ressources et de capacités réseau très efficaces. De larges capacités de mise en réseau sont fournies par le protocole réseau Qnet. Il résout le problème de la fiabilité et de l'équilibrage de charge dynamique des canaux de communication, mais il ne résout pas le problème de la tolérance aux pannes du système dans son ensemble. En conséquence, un système de contrôle innovant a été développé sur la base d'un environnement informatique multi-pipeline reconfigurable distribué. Le système développé a une architecture peer-to-peer qui comprend trois blocs logiques : un bloc d'entrée-sortie, un bloc de commutation à usage général et un bloc d'environnement informatique reconfigurable (RCS) (voir Fig. 2).

Les principaux avantages de cette architecture sont :

• Type d'égal à égal
• Décentralisation
• Évolutivité
• Distribution spatiale

Caractéristiques fonctionnelles de cette architecture :

• Traitement de données en pipeline
• Redondance matérielle
• Répartition de la charge
• Reconfiguration à la volée

Au premier niveau de l'architecture, il existe une unité d'entrée-sortie (E/S), qui comprend : des nœuds d'entrée-sortie, un commutateur de nœuds d'entrée-sortie, une interface d'entrée-sortie, des capteurs et des actionneurs. L'unité est responsable des mécanismes de base pour générer des actions de contrôle sur la base des données des capteurs locaux et des données reçues des autres niveaux du système de contrôle. Les tâches attribuées sont réparties entre les nœuds d'E/S sains en fonction de leurs performances relatives actuelles ou manuellement par l'opérateur. Les capteurs et actionneurs sont connectés via un bus à tous les nœuds d'E/S du bloc, ce qui permet à n'importe quel nœud d'interroger n'importe quel capteur ou de générer un effet sur n'importe quel actionneur. Le commutateur de nœud d'E/S assure la communication entre tous les nœuds d'E/S pour échanger des données entre eux et d'autres niveaux de l'architecture du système pour obtenir des données de contrôle et d'information. Avec les capacités matérielles appropriées, les nœuds communiquent directement entre eux et avec des nœuds et des commutateurs à d'autres niveaux du système, ce qui réduit le temps de réponse dans le réseau. La communication directe entre les nœuds et une certaine charge de nœuds dans le mode de fonctionnement actuel du bloc d'E/S permet d'organiser les calculs de pipeline dans le bloc nécessaire au fonctionnement de ce bloc sans avoir recours à la puissance de calcul externe du système de contrôle (DCS), ce qui permet d'utiliser efficacement les ressources libres prévues pour les nœuds de redondance du bloc d'E/S au moment de la panne.

Le bloc de commutateurs à usage général, situé au deuxième niveau de l'architecture, organise les lignes de communication entre les blocs d'entrées-sorties et les DCS et les systèmes externes. Chaque commutateur peut interconnecter diverses liaisons et commutateurs dans l'ensemble du système de contrôle. Le nombre de lignes de communication est déterminé par les capacités matérielles des nœuds et des commutateurs inclus dans les blocs. Le réseau Qnet permettant de répartir dynamiquement les flux de données, la mise à l'échelle de ce bloc s'effectue par simple connexion de nouveaux appareils et ne nécessite aucune configuration, et si l'un des commutateurs tombe en panne, le transfert de données entre les nœuds ne sera pas interrompu si le un autre commutateur fournit une connexion similaire entre les nœuds ou ils sont directement liés. Dans le même temps, il est nécessaire de veiller à une bande passante réseau suffisante pour sauvegarder un commutateur défaillant.

Le bloc de réseau informatique reconfigurable (RCN), situé au troisième niveau de l'architecture, fournit un système de gestion de puissance de calcul élevée pour résoudre des problèmes complexes de traitement de l'information, de prise de décision, de reconnaissance, etc. Le bloc est responsable de l'initialisation de l'ensemble du système de contrôle : vérification du fonctionnement des commutateurs et des nœuds, de l'intégrité du réseau, de la création de graphiques de réseau de l'ensemble du système, définition des paramètres de départ pour le fonctionnement des blocs d'entrée-sortie. Les nœuds de ce bloc assurent l'archivage à la fois de leurs propres données et des données des blocs d'E/S. Chaque nœud de ce bloc peut jouer le rôle d'une machine d'opérateur conçue pour surveiller le fonctionnement du système et effectuer des ajustements aux programmes de travail de ce nœud et de tous les nœuds du système, et effectuer une reconfiguration à la demande.

Répartition de la charge

L'une des tâches principales du système L-Net est la répartition de la charge de calcul sur les nœuds du réseau. La solution à ce problème est basée sur la construction de pipelines de calcul. Pour construire un pipeline de calcul, un graphe de tâches est préalablement construit - un schéma pour échanger des flux de données d'une source à un récepteur. Les capteurs agissent comme une source et les actionneurs agissent comme un destinataire. Le pipeline de calcul lui-même est une cartographie du graphe des tâches (voir Fig. 3) sur le graphe du réseau informatique (voir Fig. 4), en tenant compte des exigences du problème aux ressources de calcul du système et de son état actuel.

La solution consiste à utiliser un service qui fournit au destinataire des informations complètes sur le matériel actuel, son état et les sources de données disponibles, qui effectue un travail avec des graphiques et des tâches de réseau. En conséquence, les performances sont augmentées en raison du pipeline de calculs et l'utilisation rationnelle de toutes les ressources de calcul disponibles pour le système est organisée.

tolérance aux pannes

Le principal problème du fonctionnement d'un tel système est une interruption complète des pipelines de calcul en cas de défaillance d'un nœud quelconque de ce convoyeur ou en cas de violation du transfert de données entre eux. Les moyens de base du protocole Qnet réalisent la restauration des connexions entre les nœuds en cas de leur violation partielle due aux lignes de secours fournies par l'architecture. Le système L-Net résout le problème du rétablissement de l'opérabilité en cas de panne complète de l'hôte du système informatique en reconfigurant dynamiquement le pipeline informatique, c'est-à-dire en utilisant des ressources de travail pour remplacer le bloc défectueux. Le système propose trois scénarios de récupération (reconfiguration), qui diffèrent par le temps de réponse au fait d'une panne, le temps de récupération et les ressources matérielles utilisées : en cas de panne, avec disponibilité passive, avec disponibilité active.

• Reconfiguration en cas d'échec- après détection d'une panne, la recherche du matériel disponible est effectuée et son inclusion dans le graphe des tâches.
• Reconfiguration avec préparation passive- le matériel redondant est déterminé à l'avance, un processus est lancé qui assure la mise en œuvre du sommet du graphe de tâches sur le nœud, des connexions sont établies, mais le processus ne traite les données que si le nœud principal échoue.
• Reconfiguration avec disponibilité active- le haut du graphe des tâches est implémenté sur plusieurs nœuds, qui effectuent le traitement des données en parallèle et transmettent le résultat.

En conséquence, le système offre une préparation flexible aux pannes tant au niveau logiciel que matériel, la possibilité de modifier la configuration des nœuds sans interrompre le travail et sans perte de performances quelle que soit la mise en œuvre du réseau, du pipeline de calcul et du nœud.

Conclusion

Le système L-Net développé, contrairement aux analogues existants, présuppose l'utilisation d'une large gamme de caractéristiques matérielles des nœuds DCS avec leur compatibilité logicielle totale. Lorsque les nœuds fonctionnent sous le contrôle d'un système d'exploitation (QNX Neutrino), il est possible de les construire sur différentes architectures de processeur (x86, ARM, MIPS, etc.) avec une variété d'interfaces et de périphériques. La mise en œuvre des nœuds est possible sous la forme de PC de bureau, de PC industriels, de PC portables et d'ordinateurs monocarte. Tous les composants du complexe logiciel du DCS développé peuvent être lancés sur n'importe lequel de ses nœuds avec le système d'exploitation QNX, tandis qu'il reste possible d'utiliser des nœuds avec un système d'exploitation différent. Cette approche permet à chaque nœud d'être utilisé pour résoudre à la fois des tâches au niveau de l'opérateur et au niveau du contrôle. Par conséquent, il existe un système flexible d'interaction entre pairs sans hiérarchie rigide de niveaux inhérente à l'architecture DCS généralisée et aux systèmes utilisant cette architecture comme base. Le réseau peer-to-peer simplifie les processus de déploiement, d'exploitation, de mise à l'échelle et de débogage d'un système.

Pour réaliser le potentiel de calcul du matériel redondant dans le système développé, des algorithmes de configuration et de reconfiguration dynamiques sont proposés sur la base du protocole réseau Qnet et du logiciel réseau L-Net. L'algorithme de configuration dynamique est basé sur la répartition de la charge de calcul sur tous les nœuds en mettant en pipeline et en parallélisant les tâches et en équilibrant dynamiquement la charge sur les canaux de transmission de données entre les nœuds. L'algorithme de reconfiguration du système suppose la présence de trois scénarios de restauration de l'opérabilité en cas de panne, en fonction du matériel disponible, des priorités et des tâches assignées au système : en cas de panne, avec une disponibilité passive (allocation des ressources) et avec une disponibilité active (utilisation des ressources) . Les algorithmes de configuration et de reconfiguration dynamiques améliorent les performances et la fiabilité en utilisant les réserves matérielles du système.

Un avantage important du système est la transparence maximale des technologies matérielles et logicielles utilisées, ce qui permet de simplifier sérieusement le support technique du système et le développement de nouveaux modules pour celui-ci.

Conclusion

Les solutions architecturales développées permettent d'améliorer des indicateurs de systèmes de contrôle distribués tels que la fiabilité, les performances, le coût, l'évolutivité et la simplicité grâce à la possibilité d'utiliser une large gamme de matériel, la mise en œuvre d'algorithmes de configuration dynamique et l'utilisation rationnelle des ressources système.

1. http://kazanets.narod.ru/DCSIntro.htm.
2. http://kazanets.narod.ru/PCS7Overview.htm.
3. http://www.rts.ua/rus/news/678/0/409.
4. Zyl S. QNX Momentics : Notions de base sur les applications. - SPb : BHV-Pétersbourg, 2005.
5. Krten R. Introduction à QNX Neutrino. Guide de développement d'applications temps réel. - SPb : BHV-Pétersbourg, 2011.

Mots clés: système de contrôle distribué, support d'information pour les systèmes de contrôle, systèmes reconfigurables distribués.

Architecture d'un système de contrôle distribué basé sur l'environnement informatique multi-pipeline reconfigurable L-Net

Sergueï Yu. Potomskiy, professeur adjoint à l'Université nationale de recherche "Higher School of Economics".

Nikita A. Poloyko, étudiante en cinquième année de l'Université nationale de recherche "Higher School of Economics". Assistante d'études. Programmeur. Domaine de formation : "Contrôle et informatique dans les systèmes techniques".

Abstrait. L'article est consacré à un système de contrôle distribué basé sur un environnement informatique multi-pipeline reconfigurable. L'architecture du système est donnée. En outre, les caractéristiques de base et les propriétés fonctionnelles du système sont également indiquées. L'article présente une justification du choix du système d'exploitation. Les avantages fondamentaux du système par rapport aux développements similaires existants sont présentés dans l'article.

Mots clés: système de contrôle distribué, support logiciel système, reconfigurable distribué.

En contact avec

Systèmes multi-ordinateurs hétérogènes

Le plus grand nombre de systèmes distribués actuellement existants sont construits selon le schéma des systèmes multi-ordinateurs hétérogènes. Cela signifie que les ordinateurs qui font partie de ce système peuvent être extrêmement divers, par exemple en ce qui concerne le type de processeur, la taille de la mémoire et les performances d'E/S. En pratique, le rôle de certains de ces calculateurs peut être joué par des systèmes parallèles performants, par exemple des systèmes multiprocesseurs ou multi-ordinateurs homogènes.

Le réseau qui les relie peut également être très hétérogène.

Un exemple d'hétérogénéité est la création de grands systèmes multi-ordinateurs utilisant les réseaux et canaux existants. Ainsi, par exemple, il n'est pas rare qu'il existe des systèmes distribués universitaires, constitués de réseaux locaux de diverses facultés, interconnectés par des canaux à haut débit. Dans les systèmes mondiaux, les différentes stations peuvent à leur tour être connectées par des réseaux publics, tels que les services de réseau offerts par les opérateurs de télécommunications commerciaux, tels que SMDS ou alors Relais de trame.

Contrairement aux systèmes discutés dans les paragraphes précédents, de nombreux systèmes multi-ordinateurs hétérogènes à grande échelle nécessitent une approche globale. Cela signifie qu'une application ne peut pas supposer que certaines performances ou certains services lui seront toujours disponibles.

Passant aux problèmes de mise à l'échelle inhérents aux systèmes hétérogènes, et compte tenu de la nécessité d'une approche globale inhérente à la plupart d'entre eux, nous constatons que la création d'applications pour des systèmes multi-ordinateurs hétérogènes nécessite des logiciels spécialisés. Ce problème est traité par des systèmes distribués. Pour que les développeurs d'applications n'aient pas à se soucier du matériel qu'ils utilisent, les systèmes distribués fournissent un shell logiciel qui protège les applications de ce qui se passe dans le matériel (c'est-à-dire qu'ils assurent la transparence).

L'architecture distribuée la plus ancienne et la plus fondamentale est client-serveur, dans laquelle l'une des parties (le client) initie l'échange de données en envoyant une requête à l'autre partie (le serveur). Le serveur traite la requête et, si nécessaire, envoie une réponse au client (Fig. 2.7).

Riz. 2.7. Modèle d'interaction client-serveur

L'interaction dans le cadre du modèle client-serveur peut être soit synchrone, lorsque le client attend que le serveur traite sa requête, soit asynchrone, dans laquelle le client envoie une requête au serveur et poursuit son exécution sans attendre la réponse. Le modèle client et serveur peut être utilisé comme base pour décrire diverses interactions. Considérez l'interaction des composants du logiciel qui forme un système distribué.

Riz. 2.8. Niveaux de logique applicative

Considérons une certaine application typique, qui, conformément aux concepts modernes, peut être divisée en les niveaux logiques suivants (Fig.2.8): interface utilisateur (UI), logique d'application (LP) et accès aux données (DD), travaillant avec une base de données (DB) ... L'utilisateur du système interagit avec celui-ci via l'interface utilisateur, la base de données stocke des données décrivant le domaine d'application et la couche logique d'application implémente tous les algorithmes liés au domaine.

Étant donné que, dans la pratique, différents utilisateurs du système sont généralement intéressés à accéder aux mêmes données, la séparation la plus simple des fonctions d'un tel système entre plusieurs ordinateurs sera la séparation des couches logiques de l'application entre une partie serveur de l'application. responsable de l'accès aux données et aux parties clientes situées sur plusieurs ordinateurs mettant en œuvre l'interface utilisateur. La logique d'application peut être attribuée au serveur, aux clients ou partagée entre eux (Figure 2.9).

Riz. 2.9. Architecture à deux niveaux

L'architecture des applications construites sur ce principe est appelée client-serveur ou à deux maillons... En pratique, de tels systèmes ne sont souvent pas classés comme distribués, mais formellement, ils peuvent être considérés comme les représentants les plus simples des systèmes distribués.

Le développement de l'architecture client-serveur est architecture à trois niveaux, dans lequel l'interface utilisateur, la logique d'application et l'accès aux données sont séparés en composants indépendants du système qui peuvent fonctionner sur des ordinateurs indépendants (Figure 2.10).

Riz. 2.10. Architecture à trois niveaux

La demande de l'utilisateur dans de tels systèmes est traitée séquentiellement par la partie cliente du système, le serveur logique d'application et le serveur de base de données. Cependant, un système distribué est généralement compris comme un système avec une architecture plus complexe qu'un système à trois niveaux.

Riz. 2.11. Système de vente au détail distribué

En ce qui concerne les applications d'automatisation des activités de l'entreprise, les systèmes distribués sont généralement appelés systèmes avec une logique d'application répartie entre plusieurs composants du système, chacun pouvant être exécuté sur un ordinateur distinct. Par exemple, la mise en œuvre de la logique applicative d'un système de vente au détail doit utiliser des requêtes vers la logique applicative de tiers, tels que les fournisseurs de biens, les systèmes de paiement électronique ou les banques qui fournissent des prêts à la consommation (Figure 2.11).

Un autre exemple de système distribué est celui des réseaux échange direct de données entre clients (réseaux peer-to-peer)... Si l'exemple précédent avait une architecture « arborescente », alors les réseaux d'échanges directs sont organisés de manière plus complexe, figure 2.12. De tels systèmes sont actuellement, probablement, l'un des plus grands systèmes distribués existants, réunissant des millions d'ordinateurs.

Riz. 2.12. Système d'échange direct de données entre clients

(Matériel du site http://se.math.spbu.ru)

Introduction.

De nos jours, pratiquement tous les grands systèmes logiciels sont distribués. Système distribué- un système dans lequel le traitement de l'information n'est pas concentré sur un seul ordinateur, mais est réparti entre plusieurs ordinateurs. Dans la conception de systèmes distribués, qui a beaucoup en commun avec la conception de logiciels en général, il y a encore quelques spécificités à considérer.

Il existe six caractéristiques principales des systèmes distribués.

1. Partage des ressources. Les systèmes distribués permettent le partage des ressources matérielles (disques durs, imprimantes) et logicielles (fichiers, compilateurs).
2. Ouverture.C'est la capacité d'étendre le système en ajoutant de nouvelles ressources.
3. Parallélisme.Dans les systèmes distribués, plusieurs processus peuvent s'exécuter simultanément sur différents ordinateurs du réseau. Ces processus peuvent interagir pendant leur exécution.
4. Évolutivité . Sous évolutivité la possibilité d'ajouter de nouvelles propriétés et méthodes est comprise.
5. Tolérance aux pannes. La présence de plusieurs ordinateurs permet la duplication des informations et la résistance à certaines erreurs matérielles et logicielles. Les systèmes distribués peuvent prendre en charge des fonctionnalités partielles en cas d'erreur. Une défaillance complète du système se produit uniquement avec des erreurs de réseau.
6. Transparence.Les utilisateurs bénéficient d'un accès complet aux ressources du système, tandis que les informations sur la répartition des ressources dans le système leur sont cachées.

Les systèmes distribués présentent également un certain nombre d'inconvénients.

1. Complexité... Il est beaucoup plus difficile de comprendre et d'évaluer les propriétés des systèmes distribués en général, et ils sont plus difficiles à concevoir, tester et maintenir. De plus, les performances du système dépendent de la vitesse du réseau, et non des processeurs individuels. La réaffectation des ressources peut modifier considérablement la vitesse du système.
2. Sécurité... En règle générale, le système est accessible à partir de plusieurs machines différentes, les messages sur le réseau peuvent être consultés et interceptés. Par conséquent, dans un système distribué, il est beaucoup plus difficile de maintenir la sécurité.
3. Contrôlabilité... Le système peut être constitué de différents types d'ordinateurs sur lesquels différentes versions de systèmes d'exploitation peuvent être installées. Les erreurs sur une machine peuvent se propager à d'autres machines de manière imprévisible.
4. Imprévisibilité ... La réaction des systèmes distribués à certains événements est imprévisible et dépend de la pleine charge du système, de son organisation et de la charge du réseau. Étant donné que ces paramètres peuvent changer constamment, le temps de réponse à la demande peut donc différer considérablement du temps.

À partir de ces lacunes, vous pouvez voir que lors de la conception de systèmes distribués, il existe un certain nombre de problèmes que les développeurs doivent prendre en compte.

1. Identification des ressources ... Les ressources dans les systèmes distribués sont situées sur différents ordinateurs, de sorte que le système de nommage des ressources doit être pensé pour que les utilisateurs puissent facilement accéder et se référer aux ressources dont ils ont besoin. Un exemple est le système URL (Uniform Resource Locator), qui définit les noms des pages Web.
2. la communication... L'opérabilité universelle d'Internet et la mise en œuvre efficace des protocoles TCP/IP sur Internet pour la plupart des systèmes distribués sont des exemples du moyen le plus efficace d'organiser la communication entre ordinateurs. Cependant, dans certains cas où des performances ou une fiabilité particulières sont requises, il est possible d'utiliser des outils spécialisés.
3. Qualité de service du système ... Ce paramètre reflète les performances, l'intégrité et la fiabilité. Un certain nombre de facteurs affectent la qualité de service : la répartition des processus, des ressources, du matériel et l'adaptabilité du système.
4. Architecture logicielle ... L'architecture logicielle décrit la répartition des fonctions du système entre les composants du système, ainsi que la répartition de ces composants entre les processeurs. Si vous devez maintenir un service système de haute qualité, le choix de la bonne architecture est essentiel.

Le défi pour les concepteurs de systèmes distribués est de concevoir des logiciels et du matériel pour fournir toutes les caractéristiques requises d'un système distribué. Cela nécessite de connaître les avantages et les inconvénients des différentes architectures de systèmes distribués. Il existe trois types d'architectures de systèmes distribués.

1. Architecture client/serveur ... Dans ce modèle, le système peut être considéré comme un ensemble de services fournis par les serveurs aux clients. Dans de tels systèmes, les serveurs et les clients diffèrent considérablement les uns des autres.
2. Architecture à trois niveaux ... Dans ce modèle, le serveur ne fournit pas de services aux clients directement, mais via le serveur de logique métier.

À propos des deux premiers modèles qui ont déjà été dits plus d'une fois, attardons-nous sur le troisième plus en détail.

1. Architecture d'objets distribués ... Dans ce cas, il n'y a pas de différences entre les serveurs et les clients, et le système peut être considéré comme un ensemble d'objets en interaction, dont l'emplacement n'a pas vraiment d'importance. Il n'y a pas de distinction entre le fournisseur de service et ses utilisateurs.

Cette architecture est largement utilisée aujourd'hui et est également appelée architecture de services Web. Un service Web est une application accessible sur Internet et fournissant certains services dont la forme est indépendante du fournisseur (puisque le format de données universel - XML ​​est utilisé) et de la plate-forme d'exploitation. Actuellement, il existe trois technologies différentes qui prennent en charge le concept de systèmes d'objets distribués. Il s'agit des technologies EJB, CORBA et DCOM.

Tout d'abord, quelques mots sur ce qu'est XML en général. XML est un format de données générique utilisé pour fournir des services Web. Les services Web sont basés sur des normes et protocoles ouverts : SOAP, UDDI et WSDL.

1. SAVON ( Le Simple Object Access Protocol, développé par le W3C, définit un format pour les requêtes aux services Web. Les messages entre un service Web et son utilisateur sont conditionnés dans des enveloppes dites SOAP (parfois aussi appelées enveloppes XML). Le message lui-même peut contenir soit une demande d'exécution d'une action, soit une réponse - le résultat de cette action.
2. WSDL (langage de description de services Web).L'interface de service Web est décrite dans les documents WSDL (et WSDL est un sous-ensemble de XML). Avant de déployer un service, le développeur compose sa description en langage WSDL, spécifie l'adresse du service Web, les protocoles pris en charge, une liste d'opérations autorisées et les formats de requête et de réponse.
3. UDDI (Description, Découverte et Intégration Universelle) - Protocole de recherche des services Web Internet ( http://www.uddi.org/). Il s'agit d'un registre d'entreprises où les fournisseurs de services Web enregistrent les services et les développeurs trouvent les services dont ils ont besoin pour inclure dans leurs applications.

D'après le rapport, il peut sembler que les services Web sont la solution la meilleure et incontestée, et la seule question est le choix des outils de développement. Cependant, ce n'est pas le cas. Il existe une alternative aux services Web, le Web sémantique, dont le créateur de WWW, Tim Berners-Lee, a parlé il y a cinq ans.

Si le but des services Web est de faciliter la communication entre les applications, alors le Web sémantique est conçu pour résoudre un problème beaucoup plus complexe - en utilisant des mécanismes de métadonnées pour augmenter l'efficacité de la valeur des informations qui peuvent être trouvées sur le Web. Cela peut être fait en abandonnant l'approche orientée document au profit de l'approche orientée objet.

Bibliographie

1. SomervilleI. Génie logiciel.
2. Dranitsa A. Java contre .NET. - "Computerra", n° 516.
3. Ressources Internet.

Dans le chapitre précédent, nous avons examiné des systèmes multiprocesseurs étroitement couplés avec une mémoire partagée, des structures de données de noyau partagées et un pool partagé à partir duquel les processus sont appelés. Souvent, cependant, il est souhaitable d'allouer les processeurs de manière à ce qu'ils soient autonomes vis-à-vis de l'environnement d'exploitation et des conditions d'exploitation à des fins de partage des ressources. Supposons, par exemple, qu'un utilisateur d'un ordinateur personnel ait besoin d'accéder à des fichiers situés sur une machine plus grande, tout en conservant le contrôle de l'ordinateur personnel. Bien que certains programmes, tels que uucp, prennent en charge le transfert de fichiers réseau et d'autres fonctions réseau, leur utilisation ne sera pas cachée à l'utilisateur, car l'utilisateur sait qu'il utilise le réseau. De plus, il convient de noter que les programmes tels que les éditeurs de texte ne fonctionnent pas avec les fichiers supprimés, comme avec les fichiers ordinaires. Les utilisateurs doivent disposer de l'ensemble standard des fonctions du système UNIX et, mis à part la dégradation potentielle des performances, ne doivent pas subir de dépassement des limites de la machine. Ainsi, par exemple, le travail des fonctions système ouvertes et lues avec des fichiers sur des machines distantes ne doit pas différer de leur travail avec des fichiers appartenant à des systèmes locaux.

L'architecture du système distribué est illustrée à la Figure 13.1. Chaque ordinateur illustré dans la figure est une unité autonome composée d'un processeur, d'une mémoire et de périphériques. Le modèle ne casse pas même si l'ordinateur n'a pas de système de fichiers local : il doit avoir des périphériques pour communiquer avec d'autres machines, et tous les fichiers qui lui appartiennent peuvent se trouver sur un autre ordinateur. La mémoire physique disponible pour chaque machine est indépendante des processus exécutés sur les autres machines. À cet égard, les systèmes distribués diffèrent des systèmes multiprocesseurs étroitement couplés discutés dans le chapitre précédent. En conséquence, le cœur du système sur chaque machine fonctionne indépendamment des conditions de fonctionnement externes de l'environnement distribué.

Graphique 13.1. Modèle de système d'architecture distribuée

Les systèmes distribués, bien décrits dans la littérature, entrent traditionnellement dans les catégories suivantes :

Les systèmes périphériques, qui sont des groupes de machines qui ont des points communs distincts et sont associés à une machine (généralement plus grande). Les processeurs périphériques partagent leur charge avec le processeur central et lui transfèrent tous les appels vers le système d'exploitation. L'objectif d'un système périphérique est d'augmenter les performances globales du réseau et de fournir la possibilité d'allouer un processeur à un seul processus dans un environnement d'exploitation UNIX. Le système démarre en tant que module séparé ; Contrairement à d'autres modèles de systèmes distribués, les systèmes périphériques ne disposent pas d'une réelle autonomie, sauf dans les cas liés à la répartition des processus et à l'allocation de mémoire locale.

Systèmes distribués tels que "Newcastle", permettant la communication à distance par les noms de fichiers distants dans la bibliothèque (le nom est tiré de l'article "The Newcastle Connection" - voir). Les fichiers supprimés ont une nomenclature (nom distinctif) qui, dans le chemin de recherche, contient des caractères spéciaux ou un composant de nom facultatif qui précède la racine du système de fichiers. L'implémentation de cette méthode n'implique pas de modifications du noyau du système, et par conséquent elle est plus simple que les autres méthodes discutées dans ce chapitre, mais moins flexible.

Les systèmes distribués sont complètement transparents, dans lesquels les noms distinctifs standard sont suffisants pour accéder aux fichiers situés sur d'autres machines ; c'est au noyau de reconnaître ces fichiers comme supprimés. Les chemins de recherche de fichiers spécifiés dans leurs noms composites traversent les frontières de la machine aux points de montage, quel que soit le nombre de ces points formés lorsque les systèmes de fichiers sont montés sur des disques.

Dans ce chapitre, nous examinerons l'architecture de chaque modèle ; toutes les informations fournies ne sont pas basées sur les résultats de développements spécifiques, mais sur des informations publiées dans divers articles techniques. Cela suppose que les modules de protocole et les pilotes de périphérique sont responsables de l'adressage, du routage, du contrôle de flux, de la détection et de la correction des erreurs, en d'autres termes, que chaque modèle est indépendant du réseau utilisé. Les exemples d'utilisation des fonctions système donnés dans la section suivante pour les systèmes périphériques fonctionnent de manière similaire pour des systèmes comme Newcastle et pour des systèmes complètement transparents, ce qui sera discuté plus tard ; par conséquent, nous les examinerons en détail une fois, et dans les sections consacrées aux autres types de systèmes, nous nous concentrerons principalement sur les caractéristiques qui distinguent ces modèles de tous les autres.

13.1 PROCESSEURS PÉRIPHÉRIQUES

L'architecture du système périphérique est illustrée à la figure 13.2. L'objectif de cette configuration est d'améliorer les performances globales du réseau en réaffectant les processus en cours d'exécution entre le CPU et les processeurs périphériques. Chacun des processeurs périphériques ne dispose pas d'autres périphériques locaux que ceux dont il a besoin pour communiquer avec l'unité centrale. Le système de fichiers et tous les périphériques sont à la disposition du processeur central. Supposons que tous les processus utilisateur soient exécutés sur le processeur périphérique et ne se déplacent pas entre les processeurs périphériques ; une fois transférés au processeur, ils y restent jusqu'à la fin. Le processeur périphérique contient une version allégée du système d'exploitation conçue pour gérer les appels locaux au système, la gestion des interruptions, l'allocation de mémoire, le travail avec les protocoles réseau et avec un pilote pour la communication avec le processeur central.

Lorsque le système est initialisé sur le processeur central, le cœur charge le système d'exploitation local sur chacun des processeurs périphériques via des lignes de communication. Tout processus s'exécutant en périphérie est associé à un processus satellite appartenant au processeur central (voir) ; lorsqu'un processus s'exécutant sur un processeur périphérique appelle une fonction système qui requiert uniquement les services du processeur central, le processus périphérique communique avec son satellite et la requête est envoyée au processeur central pour traitement. Le processus satellite exécute une fonction système et renvoie les résultats au processeur périphérique. La relation entre un processus périphérique et son compagnon est similaire à la relation client-serveur dont nous avons parlé en détail au chapitre 11 : le processus périphérique agit comme un client de son compagnon, qui prend en charge les fonctions de travail avec le système de fichiers. Dans ce cas, le processus serveur distant n'a qu'un seul client. Dans la section 13.4, nous examinerons les processus serveur avec plusieurs clients.

Graphique 13.2. Configuration du système périphérique

Graphique 13.3. Formats des messages

Lorsqu'un processus périphérique appelle une fonction système qui peut être traitée localement, le noyau n'a pas besoin d'envoyer une requête au processus satellite. Ainsi, par exemple, afin d'obtenir de la mémoire supplémentaire, un processus peut appeler la fonction sbrk pour une exécution locale. Cependant, si les services du processeur central sont requis, par exemple pour ouvrir un fichier, le noyau encode les informations sur les paramètres passés à la fonction appelée et les conditions d'exécution du processus dans un message envoyé au processus satellite (Figure 13.3). Le message comprend un signe dont il résulte que la fonction système est exécutée par le processus satellite pour le compte du client, des paramètres transmis à la fonction et des données sur l'environnement d'exécution du processus (par exemple, les codes d'identification d'utilisateur et de groupe), qui sont différent pour différentes fonctions. Le reste du message est constitué de données de longueur variable (par exemple, un nom de fichier composé ou des données à écrire par la fonction d'écriture).

Le processus satellite attend les requêtes du processus périphérique ; lorsqu'une requête est reçue, il décode le message, détermine le type de fonction système, l'exécute et convertit les résultats en une réponse envoyée au processus périphérique. La réponse, en plus des résultats de l'exécution de la fonction système, comprend le message d'erreur (le cas échéant), le numéro de signal et un tableau de données de longueur variable contenant, par exemple, des informations lues à partir d'un fichier. Le processus périphérique est suspendu jusqu'à réception d'une réponse, après l'avoir reçue, il décrypte et transmet les résultats à l'utilisateur. Il s'agit du schéma général de gestion des appels au système d'exploitation ; Passons maintenant à un examen plus détaillé des fonctions individuelles.

Pour expliquer le fonctionnement du système périphérique, considérez un certain nombre de fonctions : getppid, open, write, fork, exit et signal. La fonction getppid est assez simple car elle traite de simples formulaires de demande et de réponse qui sont échangés entre le périphérique et le CPU. Le cœur sur le processeur périphérique génère un message qui a un signe, d'où il suit que la fonction demandée est la fonction getppid, et envoie la requête au processeur central. Le processus satellite sur le processeur central lit le message du processeur périphérique, décrypte le type de fonction système, l'exécute et obtient l'identifiant de son parent. Il génère ensuite une réponse et la transmet à un processus périphérique en attente à l'autre extrémité de la ligne de communication. Lorsque le processeur périphérique reçoit une réponse, il la transmet au processus qui a appelé la fonction système getppid. Si le processus périphérique stocke des données (telles que l'ID de processus du parent) dans la mémoire locale, il n'a pas du tout besoin de communiquer avec son compagnon.

Si la fonction système ouvert est appelée, le processus périphérique envoie un message approprié à son compagnon, qui inclut le nom du fichier et d'autres paramètres. En cas de succès, le processus compagnon alloue un index et un point d'entrée à la table de fichiers, alloue une entrée dans la table de descripteurs de fichiers utilisateur dans son espace, et renvoie le descripteur de fichier au processus périphérique. Pendant tout ce temps, à l'autre bout de la ligne de communication, le processus périphérique attend une réponse. Il ne dispose d'aucune structure permettant de stocker des informations sur le dossier en cours d'ouverture ; le descripteur renvoyé par open est un pointeur vers une entrée dans la table de descripteur de fichier utilisateur qui appartient au processus compagnon. Les résultats de l'exécution de la fonction sont illustrés à la figure 13.4.

Graphique 13.4. Appel de la fonction open à partir d'un processus périphérique

Si un appel à la fonction système d'écriture est effectué, le processeur périphérique génère un message composé d'un signe de la fonction d'écriture, d'un descripteur de fichier et de la quantité de données à écrire. Puis, depuis l'espace du processus périphérique, il copie les données vers le processus satellite via la ligne de communication. Le processus satellite décrypte le message reçu, lit les données de la ligne de communication et les écrit dans le fichier correspondant (le descripteur contenu dans le message est utilisé comme pointeur vers l'index duquel et l'enregistrement sur lequel dans la table des fichiers est utilisé ); toutes ces actions sont effectuées sur le processeur central. A la fin du travail, le processus satellite envoie au processus périphérique un message qui confirme la réception du message et contient le nombre d'octets de données qui ont été copiés avec succès dans le fichier. L'opération de lecture est similaire ; le satellite informe le processus périphérique du nombre d'octets effectivement lus (en cas de lecture de données d'un terminal ou d'un canal, ce nombre ne coïncide pas toujours avec le nombre spécifié dans la requête). Pour exécuter l'une ou l'autre fonction, il peut être nécessaire d'envoyer plusieurs fois des messages d'information sur le réseau, ce qui est déterminé par la quantité de données envoyées et la taille des paquets réseau.

La seule fonction qui doit être modifiée lors de l'exécution sur le processeur est la fonction du système de fourche. Lorsqu'un processus exécute cette fonction sur le CPU, le noyau sélectionne un processeur périphérique pour lui et envoie un message à un processus spécial - le serveur, informant ce dernier qu'il va commencer à décharger le processus en cours. En supposant que le serveur a accepté la demande, le noyau utilise fork pour créer un nouveau processus périphérique, allouant une entrée de table de processus et un espace d'adressage. Le processeur central décharge une copie du processus qui a appelé la fonction de fourche au processeur périphérique, écrasant l'espace d'adressage nouvellement alloué, génère un satellite local pour communiquer avec le nouveau processus périphérique et envoie un message au périphérique pour initialiser le compteur de programme pour le nouveau processus. Le processus satellite (sur le CPU) est un descendant du processus appelé fork ; un processus périphérique est techniquement un descendant du processus serveur, mais logiquement c'est un descendant du processus qui a appelé la fonction fork. Le processus serveur n'a aucune connexion logique avec l'enfant lorsque le fork se termine ; le seul travail du serveur est d'aider à décharger l'enfant. Du fait du couplage fort entre les composants du système (les processeurs périphériques n'ont pas d'autonomie), le processus périphérique et le processus satellite ont le même code d'identification. La relation entre les processus est illustrée à la figure 13.5 : la ligne continue montre la relation parent-enfant et la ligne pointillée montre la relation entre les pairs.

Graphique 13.5. Exécution de la fonction fork sur le CPU

Lorsqu'un processus exécute la fonction fork sur le processeur périphérique, il envoie un message à son satellite sur le CPU, qui exécute alors toute la séquence d'actions décrite ci-dessus. Le satellite sélectionne un nouveau processeur périphérique et effectue les préparatifs nécessaires pour décharger l'image de l'ancien processus : il envoie au processus périphérique parent une demande de lecture de son image, en réponse à laquelle le transfert des données demandées commence à l'autre extrémité de le canal de communication. Le satellite lit l'image transmise et l'écrase sur le descendant périphérique. Lorsque le déchargement de l'image est terminé, le satellite traite un fork, créant son fils sur le CPU, et passe la valeur du compteur de programme au fils périphérique afin que ce dernier sache par où commencer l'exécution. Évidemment, il serait préférable que l'enfant du processus compagnon soit affecté à l'enfant périphérique en tant que parent, mais dans notre cas, les processus générés peuvent s'exécuter sur d'autres processeurs périphériques, pas seulement celui sur lequel ils sont créés. La relation entre les processus à la fin de la fonction fork est illustrée à la figure 13.6. Lorsque le processus périphérique a terminé son travail, il envoie un message correspondant au processus satellite, et cela se termine également. Un processus compagnon ne peut pas initier un arrêt.

Graphique 13.6. Exécuter une fonction fork sur un processeur périphérique

Dans les systèmes multiprocesseurs et monoprocesseurs, le processus doit répondre aux signaux de la même manière : soit le processus termine l'exécution de la fonction système avant de vérifier les signaux, soit, au contraire, à la réception du signal, sort immédiatement de l'état suspendu et interrompt brutalement le travail de la fonction système, si cela est conforme à la priorité avec laquelle il a été suspendu. Le processus satellite assurant des fonctions système pour le compte du processus périphérique, il doit répondre aux signaux en coordination avec ce dernier. Si, sur un système monoprocesseur, un signal provoque l'abandon de la fonction par un processus, le processus compagnon sur un système multiprocesseur doit se comporter de la même manière. La même chose peut être dite du cas où le signal invite le processus à terminer son travail à l'aide de la fonction de sortie : le processus périphérique se termine et envoie le message correspondant au processus satellite, qui, bien sûr, se termine également.

Lorsqu'un processus périphérique appelle la fonction de système de signal, il stocke les informations actuelles dans des tables locales et envoie un message à son satellite l'informant si le signal spécifié doit être reçu ou ignoré. Cela ne fait aucune différence pour le processus satellite, qu'il s'agisse d'intercepter le signal ou de l'action par défaut. La réaction d'un processus à un signal dépend de trois facteurs (Figure 13.7) : si un signal arrive pendant que le processus exécute une fonction système, si une indication est faite en utilisant la fonction de signal pour ignorer le signal, si le signal se produit sur le même processeur périphérique ou sur un autre. Passons à l'examen des différentes possibilités.

algorithme sighandle / * algorithme de traitement du signal * /

if (le processus actuel est le compagnon de quelqu'un ou a un prototype)

si (le signal est ignoré)

if (le signal est arrivé pendant l'exécution d'une fonction système)

mettre un signal devant le processus satellite;

envoyer un message de signal à un processus périphérique ;

else (/ * processus périphérique * /

/ * si un signal a été reçu pendant l'exécution d'une fonction système ou non * /

envoyer un signal au processus satellite ;

algorithme satellite_end_of_syscall / * terminaison d'une fonction système appelée par un processus périphérique * /

information d'entrée : absent

informations de sortie : aucune

if (une interruption a été reçue pendant l'exécution d'une fonction système)

envoyer un message d'interruption, signal au processus périphérique;

else / * l'exécution de la fonction système n'a pas été interrompue * /

envoyer une réponse : activer le drapeau indiquant l'arrivée du signal ;

Graphique 13.7. Traitement du signal dans le système périphérique

Supposons que le processus périphérique ait suspendu son travail tandis que le processus satellite exécute une fonction système pour son compte. Si le signal se produit ailleurs, le processus satellite le détecte plus tôt que le processus périphérique. Trois cas sont possibles.

1. Si, en attendant un événement, le processus satellite n'est pas entré dans l'état suspendu, dont il sortirait à la réception d'un signal, il exécute la fonction système jusqu'à la fin, envoie les résultats de l'exécution au processus périphérique et affiche quel signal il a reçu.

2. Si le processus demande d'ignorer ce type de signal, le satellite continue de suivre l'algorithme d'exécution de la fonction système sans quitter l'état suspendu par longjmp. Dans la réponse envoyée au processus périphérique, il n'y aura aucun message de réception de signal.

3. Si, à la réception d'un signal, le processus satellite interrompt l'exécution de la fonction système (par longjmp), il en informe le processus périphérique et lui communique le numéro du signal.

Le processus périphérique recherche dans la réponse reçue des informations sur la réception de signaux et, le cas échéant, traite les signaux avant de quitter la fonction système. Ainsi, le comportement d'un processus dans un système multiprocesseur correspond exactement à son comportement dans un système monoprocesseur : soit il sort sans quitter le mode noyau, soit il appelle une fonction de gestion de signal personnalisée, soit il ignore le signal et termine avec succès la fonction système.

Graphique 13.8. Interruption pendant l'exécution d'une fonction système

Supposons, par exemple, qu'un processus périphérique appelle une fonction de lecture à partir d'un terminal connecté à un processeur central et interrompe son travail pendant que le processus satellite exécute la fonction (figure 13.8). Si l'utilisateur appuie sur la touche pause, le cœur du processeur envoie un signal au processus satellite. Si le satellite était dans un état suspendu, en attente d'une partie des données du terminal, il sort immédiatement de cet état et termine la fonction de lecture. Dans sa réponse à une requête d'un processus périphérique, le satellite rapporte le code d'erreur et le numéro de signal correspondant à l'interruption. Le processus périphérique analyse la réponse et, puisque le message indique qu'une interruption est arrivée, s'envoie le signal. Avant de quitter la fonction de lecture, le noyau périphérique vérifie la signalisation, détecte un signal d'interruption du processus satellite et le traite comme d'habitude. Si, suite à la réception d'un signal d'interruption, le processus périphérique termine son travail en utilisant la fonction de sortie, cette fonction se charge de tuer le processus satellite. Si le processus périphérique intercepte des signaux d'interruption, il appelle la fonction de gestion des signaux définie par l'utilisateur et renvoie un code d'erreur à l'utilisateur lorsqu'il quitte la fonction de lecture. D'autre part, si le satellite exécute la fonction système stat pour le compte du processus périphérique, il n'interrompra pas son exécution lorsqu'il recevra un signal (la fonction stat est garantie de sortir de toute pause, car elle a un temps d'attente de ressource limité ). Le satellite termine l'exécution de la fonction et renvoie le numéro de signal au processus périphérique. Le processus périphérique s'envoie un signal et le reçoit en sortie de la fonction système.

Si un signal survient sur le processeur périphérique lors de l'exécution d'une fonction système, le processus périphérique ne saura pas s'il reprendra bientôt le contrôle du processus satellite ou ce dernier passera indéfiniment dans un état suspendu. Le processus périphérique envoie un message spécial au satellite l'informant de l'apparition d'un signal. Le noyau du CPU décrypte le message et envoie un signal au satellite, dont la réaction à la réception du signal est décrite dans les paragraphes précédents (arrêt anormal de l'exécution de la fonction ou arrêt de celle-ci). Le processus périphérique ne peut pas envoyer de message directement au satellite car le satellite est occupé à exécuter une fonction système et ne lit pas les données de la ligne de communication.

En se référant à l'exemple lu, il convient de noter que le processus périphérique n'a aucune idée si son compagnon attend une entrée du terminal ou exécute d'autres actions. Le processus périphérique envoie un message de signal au satellite : si le satellite est dans un état suspendu avec une priorité interruptible, il sort immédiatement de cet état et met fin à la fonction système ; sinon, la fonction est terminée avec succès.

Enfin, considérons le cas d'une arrivée de signal à un instant non lié à l'exécution d'une fonction système. Si un signal provient d'un autre processeur, le satellite le reçoit en premier et envoie un message de signal au processus périphérique, que le signal concerne le processus périphérique ou non. Le noyau périphérique décrypte le message et envoie un signal au processus, qui y réagit de la manière habituelle. Si le signal provient du processeur périphérique, le processus effectue des actions standards sans recourir aux services de son satellite.

Lorsqu'un processus périphérique envoie un signal à d'autres processus périphériques, il code un message kill call et l'envoie au processus satellite, qui exécute localement la fonction appelée. Si une partie des processus auxquels le signal est destiné se trouve sur d'autres processeurs périphériques, leurs satellites recevront le signal (et y réagiront comme décrit ci-dessus).

13.2 COMMUNICATION DE NEWCASTLE

Dans la section précédente, nous avons considéré un type de système étroitement couplé, caractérisé par l'envoi de tous les appels aux fonctions du sous-système de gestion de fichiers qui surviennent sur le processeur périphérique à un processeur distant (central). Passons maintenant à l'examen des systèmes avec une connexion plus faible, qui consistent en des machines qui font des appels à des fichiers situés sur d'autres machines. Dans un réseau d'ordinateurs personnels et de postes de travail, par exemple, les utilisateurs accèdent souvent à des fichiers situés sur une grande machine. Dans les deux sections suivantes, nous examinerons les configurations système dans lesquelles toutes les fonctions système sont exécutées dans des sous-systèmes locaux, mais en même temps, il est possible d'accéder aux fichiers (via les fonctions du sous-système de gestion de fichiers) situés sur d'autres machines.

Ces systèmes utilisent l'un des deux chemins suivants pour identifier les fichiers supprimés. Sur certains systèmes, un caractère spécial est ajouté au nom de fichier composé : le composant de nom qui précède ce caractère identifie la machine, le reste du nom est le fichier sur cette machine. Ainsi, par exemple, le nom distinctif

"sftig! / fs1 / mjb / rje"

identifie le fichier "/fs1/mjb/rje" sur la machine "sftig". Ce schéma d'identification de fichier suit la convention uucp pour le transfert de fichiers entre les systèmes UNIX. Dans un autre schéma, les fichiers supprimés sont identifiés en ajoutant un préfixe spécial au nom, par exemple :

/../sftig/fs1/mjb/rje

où "/../" est un préfixe indiquant que le fichier est supprimé ; le deuxième composant du nom de fichier est le nom de la machine distante. Ce schéma utilise la syntaxe de nom de fichier UNIX familière, donc contrairement au premier schéma, les programmes utilisateur n'ont pas besoin de s'adapter à l'utilisation de noms avec une construction inhabituelle (voir).

Graphique 13.9. Formuler des requêtes au serveur de fichiers (processeur)

Nous consacrerons le reste de cette section à un modèle de système utilisant un lien Newcastle, dans lequel le noyau ne se préoccupe pas de reconnaître les fichiers supprimés ; cette fonction est entièrement affectée aux sous-programmes de la bibliothèque C standard, qui jouent dans ce cas le rôle d'interface système. Ces routines analysent le premier composant du nom de fichier, qui dans les deux méthodes d'identification décrites contient un signe de l'éloignement du fichier. Il s'agit d'une dérogation à la routine dans laquelle les routines de bibliothèque n'analysent pas les noms de fichiers. La figure 13.9 montre comment les requêtes adressées à un serveur de fichiers sont formulées. Si le fichier est local, le noyau du système local traite la requête normalement. Considérons le cas inverse :

open ("/../ sftig / fs1 / mjb / rje / file", O_RDONLY);

Le sous-programme open de la bibliothèque C analyse les deux premiers composants du nom de fichier et sait rechercher le fichier sur la machine distante "sftig". Afin d'avoir des informations sur si le processus avait déjà eu une connexion avec une machine donnée, le sous-programme démarre une structure spéciale dans laquelle il se souvient de ce fait, et en cas de réponse négative, établit une connexion avec le serveur de fichiers s'exécutant sur le appareil distant. Lorsque le processus formule sa première demande de télétraitement, le serveur distant confirme la demande, enregistre dans les champs des codes d'identification d'utilisateur et de groupe et crée un processus satellite qui agira pour le compte du processus client.

Pour répondre aux demandes des clients, le satellite doit avoir les mêmes autorisations de fichier sur la machine distante que le client. En d'autres termes, l'utilisateur "mjb" doit avoir les mêmes droits d'accès aux fichiers distants et locaux. Malheureusement, il est possible que le code d'identification du client "mjb" coïncide avec le code d'identification d'un autre client sur la machine distante. Ainsi, les administrateurs système sur les machines fonctionnant sur un réseau doivent soit s'assurer que chaque utilisateur se voit attribuer un code d'identification unique à l'ensemble du réseau, soit effectuer une conversion de code au moment de la formulation d'une demande de service réseau. Si cela n'est pas fait, le processus compagnon aura les droits d'un autre client sur la machine distante.

Un problème plus délicat est d'obtenir les droits de superutilisateur pour travailler avec des fichiers distants. D'une part, le client superutilisateur ne doit pas avoir les mêmes droits sur le système distant afin de ne pas induire en erreur les contrôles de sécurité du système distant. D'un autre côté, certains programmes, s'ils ne disposent pas de droits de superutilisateur, ne pourront tout simplement pas fonctionner. Un exemple d'un tel programme est le programme mkdir (voir chapitre 7), qui crée un nouveau répertoire. Le système distant ne permettrait pas au client de créer un nouveau répertoire car les droits de superutilisateur ne sont pas en vigueur lors de la suppression. Le problème de la création de répertoires distants constitue une raison sérieuse pour réviser la fonction du système mkdir dans le sens d'étendre ses capacités à établir automatiquement toutes les connexions nécessaires à l'utilisateur. Cependant, c'est toujours un problème courant que les programmes setuid (tels que le programme mkdir) obtiennent des droits de superutilisateur sur les fichiers distants. La meilleure solution à ce problème serait peut-être de définir des caractéristiques supplémentaires pour les fichiers qui décrivent l'accès à ces derniers par les superutilisateurs distants ; Malheureusement, cela nécessiterait des modifications de la structure de l'index du disque (en termes d'ajout de nouveaux champs) et créerait trop de désordre dans les systèmes existants.

Si le sous-programme d'ouverture réussit, la bibliothèque locale laisse une note correspondante à ce sujet dans la structure accessible à l'utilisateur contenant l'adresse du nœud du réseau, l'ID de processus du compagnon, le descripteur de fichier et d'autres informations similaires. Les routines de lecture et d'écriture de la bibliothèque déterminent, sur la base du descripteur de fichier, si le fichier est supprimé et, le cas échéant, envoient un message au satellite. Le processus client interagit avec son compagnon dans tous les cas d'accès aux fonctions système qui nécessitent les services d'une machine distante. Si un processus accède à deux fichiers situés sur la même machine distante, il utilise un satellite, mais si les fichiers sont situés sur des machines différentes, deux satellites sont déjà utilisés : un sur chaque machine. Deux satellites sont également utilisés lorsque deux processus accèdent à un fichier sur une machine distante. En invoquant la fonction système via satellite, le processus génère un message qui comprend le numéro de la fonction, le nom du chemin de recherche et d'autres informations nécessaires, similaires à celles incluses dans la structure du message dans le système avec les processeurs périphériques.

Le mécanisme d'exécution des opérations sur le répertoire courant est plus complexe. Lorsque le processus sélectionne un répertoire distant comme répertoire courant, la routine de bibliothèque envoie un message au satellite, qui modifie le répertoire courant, et la routine se souvient que le répertoire est supprimé. Dans tous les cas où le nom du chemin de recherche commence par un caractère autre qu'une barre oblique (/), la sous-routine envoie le nom à la machine distante, où le processus satellite achemine depuis le répertoire courant. Si le répertoire courant est local, la routine passe simplement le nom du chemin de recherche au noyau du système local. La fonction chroot système sur un répertoire distant est similaire, mais elle passe inaperçue pour le noyau local ; à proprement parler, le processus peut ignorer cette opération, puisque seule la bibliothèque enregistre son exécution.

Lorsqu'un processus appelle fork, la routine de bibliothèque appropriée envoie des messages à chaque satellite. Les processus satellites se ramifient et envoient leurs identifiants enfants au client parent. Le processus client exécute la fonction système fork, qui transfère le contrôle à l'enfant qu'il génère ; l'enfant local est en dialogue avec l'enfant satellite distant dont les adresses ont été stockées par la routine de bibliothèque. Cette interprétation de la fonction fork permet aux processus satellites de contrôler plus facilement les fichiers ouverts et les répertoires en cours. Lorsque le processus travaillant avec les fichiers distants se termine (en appelant la fonction exit), le sous-programme envoie des messages à tous ses satellites distants afin qu'ils fassent de même lorsqu'ils reçoivent le message. Certains aspects de la mise en œuvre des fonctions du système d'exécution et de sortie sont abordés dans les exercices.

L'avantage d'un lien Newcastle est que l'accès d'un processus aux fichiers distants devient « transparent » (invisible pour l'utilisateur), et aucune modification n'est requise sur le noyau du système. Cependant, cette évolution présente un certain nombre d'inconvénients. Tout d'abord, lors de sa mise en œuvre, une diminution des performances du système est possible. En raison de l'utilisation de la bibliothèque C étendue, la taille de la mémoire utilisée par chaque processus augmente, même si le processus n'accède pas aux fichiers distants ; la bibliothèque duplique les fonctions du noyau et nécessite plus d'espace mémoire pour elle-même. L'augmentation de la taille des processus allonge la période de démarrage et peut créer plus de conflits pour les ressources mémoire, créant des conditions pour un déchargement et une pagination plus fréquents des tâches. Les requêtes locales seront exécutées plus lentement en raison de l'augmentation de la durée de chaque appel au noyau, et le traitement des requêtes distantes peut également être ralenti, les coûts de leur envoi sur le réseau augmentent. Le traitement supplémentaire des requêtes distantes au niveau de l'utilisateur augmente le nombre d'opérations de changement de contexte, de déchargement et d'échange. Enfin, pour accéder aux fichiers distants, les programmes doivent être recompilés à l'aide des nouvelles bibliothèques ; les anciens programmes et les modules objets livrés ne pourront pas travailler avec les fichiers distants sans cela. Tous ces inconvénients sont absents du système décrit dans la section suivante.

13.3 SYSTÈMES DE FICHIERS DISTRIBUÉS "TRANSPARENTS"

Le terme « allocation transparente » signifie que les utilisateurs sur une machine peuvent accéder aux fichiers sur une autre machine sans se rendre compte qu'ils traversent les limites de la machine, tout comme ils le sont sur leur machine lorsqu'ils passent d'un système de fichiers à un autre en traversant les points de montage. Les noms par lesquels les processus font référence aux fichiers situés sur les machines distantes sont similaires aux noms des fichiers locaux : ils ne contiennent aucun caractère distinctif. Dans la configuration illustrée à la figure 13.10, le répertoire "/usr/src" appartenant à la machine B est "monté" dans le répertoire "/usr/src" appartenant à la machine A. le même code source système, traditionnellement trouvé dans le "/ répertoire usr / src". Les utilisateurs s'exécutant sur la machine A peuvent accéder aux fichiers situés sur la machine B en utilisant la syntaxe habituelle d'écriture des noms de fichiers (par exemple : "/usr/src/cmd/login.c"), et le noyau lui-même décide si le fichier est distant ou local . Les utilisateurs fonctionnant sur la machine B ont accès à leurs fichiers locaux (ignorant que les utilisateurs de la machine A peuvent accéder aux mêmes fichiers), mais, à leur tour, n'ont pas accès aux fichiers situés sur la machine A. Bien sûr, d'autres options sont possibles, en en particulier, ceux dans lesquels tous les systèmes distants sont montés à la racine du système local, afin que les utilisateurs aient accès à tous les fichiers sur tous les systèmes.

Graphique 13.10. Systèmes de fichiers après le montage à distance

Les similitudes entre le montage de systèmes de fichiers locaux et l'autorisation d'accès aux systèmes de fichiers distants ont incité l'adaptation de la fonction de montage aux systèmes de fichiers distants. Dans ce cas, le noyau dispose d'une table de montage au format étendu. En exécutant la fonction mount, le noyau organise une connexion réseau avec une machine distante et stocke les informations caractérisant cette connexion dans la table de montage.

Un problème intéressant concerne les noms de chemin qui incluent "..". Si un processus crée le répertoire courant à partir d'un système de fichiers distant, l'utilisation des caractères ".." dans le nom renverra le processus au système de fichiers local plutôt que d'accéder aux fichiers situés au-dessus du répertoire courant. En revenant à nouveau à la Figure 13.10, notons que lorsqu'un processus appartenant à la machine A, ayant préalablement sélectionné le répertoire courant "/usr/src/cmd" situé dans le système de fichiers distant, va exécuter la commande

le répertoire courant sera le répertoire racine de la machine A, pas de la machine B. L'algorithme namei s'exécutant dans le noyau du système distant, après avoir reçu la séquence de caractères "..", vérifie si le processus appelant est un agent du client process, et si c'est le cas, définit si le client traite le répertoire de travail actuel comme la racine du système de fichiers distant.

La communication avec une machine distante prend l'une des deux formes suivantes : un appel de procédure distante ou un appel de fonction système distant. Dans la première forme, chaque procédure du noyau traitant des index vérifie si l'index pointe vers un fichier distant, et si c'est le cas, envoie une requête à la machine distante pour effectuer l'opération spécifiée. Ce schéma s'inscrit naturellement dans la structure abstraite de prise en charge des systèmes de fichiers de différents types, décrite dans la dernière partie du chapitre 5. Ainsi, l'accès à un fichier distant peut initier le transfert de plusieurs messages sur le réseau, dont le nombre est déterminé par le nombre d'opérations implicites sur le fichier, avec une augmentation correspondante du temps de réponse à la requête, compte tenu du temps d'attente accepté dans le réseau. Chaque ensemble d'opérations distantes comprend au moins des actions de verrouillage d'index, de comptage de références, etc. ).

13.11. Ouvrir un fichier distant

Considérez un processus qui ouvre un fichier distant "/usr/src/cmd/login.c", où "src" est le point de montage. En analysant le nom du fichier (en utilisant le schéma namei-iget), le noyau détecte que le fichier est supprimé et envoie une demande à la machine hôte pour obtenir l'index verrouillé. Ayant reçu la réponse souhaitée, le noyau local crée une copie de l'index en mémoire correspondant au fichier distant. Ensuite, le noyau vérifie les droits d'accès nécessaires au fichier (en lecture par exemple) en envoyant un autre message à la machine distante. L'algorithme ouvert se poursuit conformément au plan décrit au chapitre 5, en envoyant des messages à la machine distante selon les besoins, jusqu'à ce que l'algorithme soit terminé et que l'index soit libéré. La relation entre les structures de données du noyau à la fin de l'algorithme ouvert est illustrée à la Figure 13.11.

Si le client appelle la fonction read system, le noyau client verrouille l'index local, émet un verrou sur l'index distant, une requête de lecture, copie les données dans la mémoire locale, émet une requête pour libérer l'index distant et libère l'index local . Ce schéma est cohérent avec la sémantique du noyau monoprocesseur existant, mais la fréquence d'utilisation du réseau (appels multiples à chaque fonction système) réduit les performances de l'ensemble du système. Cependant, pour réduire le flux de messages sur le réseau, plusieurs opérations peuvent être combinées en une seule requête. Dans l'exemple avec la fonction read, le client peut envoyer au serveur une requête de "lecture" générale, et le serveur lui-même décide de récupérer et de libérer l'index lorsqu'il est exécuté. La réduction du trafic réseau peut également être obtenue en utilisant des tampons distants (comme nous l'avons vu ci-dessus), mais il faut veiller à ce que les fonctions du fichier système utilisant ces tampons soient exécutées correctement.

Dans la seconde forme de communication avec une machine distante (appel à une fonction système distante), le noyau local détecte que la fonction système est liée à un fichier distant et envoie les paramètres spécifiés dans son appel au système distant, qui exécute le fonction et renvoie les résultats au client. La machine cliente reçoit les résultats de l'exécution de la fonction et sort de l'état d'appel. La plupart des fonctions du système peuvent être exécutées en utilisant une seule requête réseau et en recevant une réponse après un délai raisonnable, mais toutes les fonctions ne rentrent pas dans ce modèle. Ainsi, par exemple, lors de la réception de certains signaux, le noyau crée un fichier pour le processus appelé "core" (Chapitre 7). La création de ce fichier n'est pas associée à une fonction système spécifique, mais finit par effectuer plusieurs opérations telles que la création d'un fichier, la vérification des autorisations et l'exécution d'une série d'écritures.

Dans le cas de la fonction système ouvert, la demande d'exécution de la fonction envoyée à la machine distante comprend la partie du nom de fichier laissée après avoir exclu les composants de nom de chemin de recherche qui distinguent le fichier distant, ainsi que divers indicateurs. Dans l'exemple précédent d'ouverture du fichier "/usr/src/cmd/login.c", le noyau envoie le nom "cmd/login.c" à la machine distante. Le message comprend également des informations d'identification telles que des codes d'identification d'utilisateur et de groupe, qui sont nécessaires pour vérifier les autorisations de fichier sur la machine distante. Si une réponse est reçue de la machine distante indiquant une fonction d'ouverture réussie, le noyau local récupère un index libre dans la mémoire de la machine locale et le marque comme index de fichier distant, stocke des informations sur la machine distante et l'index distant, et alloue systématiquement une nouvelle entrée dans la table des fichiers. Comparé à l'index réel sur la machine distante, l'index détenu par la machine locale est formel et ne viole pas la configuration du modèle, qui est globalement la même que la configuration utilisée lors de l'appel de la procédure distante (Figure 13.11). Si une fonction appelée par un processus accède à un fichier distant par son descripteur, le noyau local sait à partir de l'index (local) que le fichier est distant, formule une requête qui inclut la fonction appelée et l'envoie à la machine distante. La requête contient un pointeur vers l'index distant par lequel le processus satellite peut identifier le fichier distant lui-même.

Ayant reçu le résultat de l'exécution de n'importe quelle fonction système, le noyau peut recourir aux services d'un programme spécial pour le traiter (à la fin duquel le noyau finira de travailler avec la fonction), car le traitement local des résultats utilisé dans un système monoprocesseur n'est pas toujours adapté à un système à plusieurs processeurs. En conséquence, des changements dans la sémantique des algorithmes du système sont possibles, visant à fournir un support pour l'exécution des fonctions du système distant. Cependant, dans le même temps, un flux minimum de messages circule dans le réseau, assurant le temps de réponse minimum du système aux requêtes entrantes.

13.4 MODÈLE DISTRIBUÉ SANS PROCESSUS DE TRANSFERT

L'utilisation de processus de transfert (processus satellites) dans un système distribué transparent facilite le suivi des fichiers supprimés, mais la table de processus du système distant est surchargée de processus satellites qui sont inactifs la plupart du temps. Dans d'autres schémas, des processus serveur spéciaux sont utilisés pour traiter les requêtes distantes (voir et). Le système distant dispose d'un ensemble (pool) de processus serveur qu'il affecte de temps en temps pour traiter les demandes distantes entrantes. Après avoir traité la demande, le processus serveur retourne au pool et entre dans un état prêt à traiter d'autres demandes. Le serveur ne conserve pas le contexte utilisateur entre deux appels, car il peut traiter les requêtes de plusieurs processus à la fois. Ainsi, chaque message provenant d'un processus client doit comporter des informations sur son environnement d'exécution, à savoir : codes d'identification des utilisateurs, répertoire courant, signaux, etc. fonctions.

Lorsqu'un processus ouvre un fichier distant, le noyau distant attribue un index pour les liens ultérieurs vers le fichier. La machine locale gère une table de descripteurs de fichiers personnalisés, une table de fichiers et une table d'index avec un ensemble régulier d'enregistrements, avec une entrée de table d'index identifiant la machine distante et l'index distant. Dans les cas où une fonction système (par exemple, lire) utilise un descripteur de fichier, le noyau envoie un message pointant vers l'index distant précédemment attribué et transfère les informations relatives au processus : code d'identification de l'utilisateur, taille maximale du fichier, etc. la machine dispose d'un processus serveur à sa disposition, l'interaction avec le client prend la forme décrite précédemment, cependant, la connexion entre le client et le serveur n'est établie que pour la durée de la fonction système.

L'utilisation de serveurs au lieu de processus satellites peut rendre la gestion du trafic de données, des signaux et des appareils distants plus difficile. Un grand nombre de requêtes vers une machine distante en l'absence d'un nombre suffisant de serveurs doit être mis en file d'attente. Cela nécessite un protocole de couche supérieure à celui utilisé sur le réseau principal. Dans le modèle satellite, en revanche, la sursaturation est éliminée car toutes les demandes des clients sont traitées de manière synchrone. Un client peut avoir au plus une demande en attente.

Le traitement des signaux qui interrompent l'exécution d'une fonction système est également compliqué lors de l'utilisation de serveurs, car la machine distante doit rechercher le serveur approprié servant à l'exécution de la fonction. Il est même possible qu'en raison de l'occupation de tous les serveurs, une demande de fonction système soit dans un état d'attente de traitement. Des conditions d'émergence de la concurrence se présentent également lorsque le serveur renvoie le résultat de l'exécution de la fonction système au processus appelant et que la réponse du serveur comprend l'envoi d'un message de signalisation correspondant à travers le réseau. Chaque message doit être marqué afin que le système distant puisse le reconnaître et, si nécessaire, mettre fin aux processus du serveur. Lors de l'utilisation de satellites, le processus qui gère l'exécution de la demande du client est automatiquement identifié, et en cas d'arrivée d'un signal, il n'est pas difficile de vérifier si la demande est terminée ou non.

Enfin, si une fonction système appelée par le client provoque une pause indéfinie du serveur (par exemple, lors de la lecture de données depuis un terminal distant), le serveur ne peut pas traiter d'autres requêtes pour libérer le pool de serveurs. Si plusieurs processus accèdent à des équipements distants en même temps et si le nombre de serveurs est limité par le haut, il y a un goulot d'étranglement assez tangible. Cela ne se produit pas avec les satellites, puisqu'un satellite est alloué à chaque processus client. Un autre problème lié à l'utilisation de serveurs pour des périphériques distants sera traité dans l'exercice 13.14.

Malgré les avantages que procure l'utilisation de processus satellites, le besoin d'entrées libres dans la table de processus devient en pratique si aigu que dans la plupart des cas, les services de processus serveurs sont encore utilisés pour traiter des requêtes distantes.

Graphique 13.12. Schéma conceptuel de l'interaction avec les fichiers distants au niveau du noyau

13.5 CONCLUSION

Dans ce chapitre, nous avons considéré trois schémas pour travailler avec des fichiers situés sur des machines distantes, en traitant les systèmes de fichiers distants comme une extension du système local. Les différences architecturales entre ces dispositions sont illustrées à la figure 13.12. Tous, à leur tour, diffèrent des systèmes multiprocesseurs décrits dans le chapitre précédent en ce que les processeurs ici ne partagent pas de mémoire physique. Un système de processeur périphérique se compose d'un ensemble étroitement couplé de processeurs qui partagent les ressources de fichiers du processeur central. La connexion de type Newcastle fournit un accès caché ("transparent") aux fichiers distants, mais pas au moyen du noyau du système d'exploitation, mais via l'utilisation d'une bibliothèque C spéciale. Pour cette raison, tous les programmes qui ont l'intention d'utiliser ce type de lien doivent être recompilés, ce qui, en général, est un grave inconvénient de ce schéma. L'éloignement d'un fichier est indiqué par une séquence spéciale de caractères décrivant la machine sur laquelle se trouve le fichier, et c'est un autre facteur limitant la portabilité des programmes.

Dans les systèmes distribués transparents, une modification de la fonction de montage du système est utilisée pour accéder aux fichiers distants. Les index sur le système local sont marqués comme des fichiers distants et le noyau local envoie un message au système distant décrivant la fonction système demandée, ses paramètres et l'index distant. La communication dans un système distribué « transparent » est prise en charge sous deux formes : sous la forme d'un appel à une procédure distante (un message est envoyé à la machine distante contenant une liste d'opérations associées à l'index) et sous la forme d'un appel à une fonction système distante (le message décrit la fonction demandée). La dernière partie du chapitre aborde les problèmes liés au traitement des requêtes distantes à l'aide de processus et de serveurs satellites.

13.6 EXERCICES

*un. Décrire la mise en œuvre de la fonction de système de sortie dans un système avec des processeurs périphériques. Quelle est la différence entre ce cas et le moment où le processus se termine à la réception d'un signal non capté ? Comment le noyau doit-il vider le contenu de la mémoire ?

2. Les processus ne peuvent pas ignorer les signaux SIGKILL ; Expliquez ce qui se passe dans le système périphérique lorsque le processus reçoit un tel signal.

* 3. Décrire la mise en œuvre de la fonction système exec sur un système avec des processeurs périphériques.

*4. Comment le processeur central doit-il répartir les processus entre les processeurs périphériques afin d'équilibrer la charge globale ?

*cinq. Que se passe-t-il si le processeur périphérique n'a pas assez de mémoire pour accueillir tous les processus qui lui sont déchargés ? Comment procéder au déchargement et à l'échange de processus dans le réseau ?

6. Considérez un système dans lequel des demandes à un serveur de fichiers distant sont envoyées si un préfixe spécial est trouvé dans le nom de fichier. Laissez le processus appeler execl ("/../ sftig / bin / sh", "sh", 0); L'exécutable se trouve sur une machine distante, mais doit être exécuté sur le système local. Expliquez comment le module distant est migré vers le système local.

7. Si l'administrateur a besoin d'ajouter de nouvelles machines à un système existant avec une connexion comme Newcastle, alors quelle est la meilleure façon d'en informer les modules de la bibliothèque C ?

*huit. Lors de l'exécution de la fonction exec, le noyau écrase l'espace d'adressage du processus, y compris les tables de bibliothèque utilisées par le lien Newcastle pour suivre les liens vers les fichiers distants. Après l'exécution de la fonction, le processus doit conserver la possibilité d'accéder à ces fichiers par leurs anciens descripteurs. Décrivez la mise en œuvre de ce point.

*neuf. Comme indiqué à la Section 13.2, l'appel de la fonction exit system sur les systèmes avec une connexion Newcastle entraîne l'envoi d'un message au processus compagnon, forçant ce dernier à se terminer. Cela se fait au niveau des routines de la bibliothèque. Que se passe-t-il lorsqu'un processus local reçoit un signal lui indiquant de quitter le mode noyau ?

*dix. Dans un système avec un lien Newcastle, où les fichiers distants sont identifiés en préfixant le nom d'un préfixe spécial, comment un utilisateur, en spécifiant ".." (répertoire parent) comme composant de nom de fichier, peut-il traverser le point de montage distant ?

11. Nous savons depuis le chapitre 7 que divers signaux amènent un processus à vider le contenu de la mémoire dans le répertoire courant. Que se passe-t-il si le répertoire actuel provient du système de fichiers distant ? Quelle réponse donneriez-vous si le système utilisait une relation comme Newcastle ?

*12. Quelles sont les implications pour les processus locaux si tous les processus satellites ou serveurs sont supprimés du système ?

*13. Considérez comment implémenter l'algorithme de liaison dans un système distribué transparent, dont les paramètres peuvent être deux noms de fichiers distants, ainsi que l'algorithme exec, associé à l'exécution de plusieurs opérations de lecture interne. Considérons deux formes de communication : un appel de procédure distante et un appel de fonction système distant.

*Quatorze. Lors de l'accès au périphérique, le processus serveur peut entrer dans l'état suspendu, à partir duquel il sera retiré par le pilote de périphérique. Naturellement, si le nombre de serveurs est limité, le système ne pourra plus satisfaire les requêtes de la machine locale. Proposez un schéma fiable dans lequel tous les processus du serveur ne sont pas suspendus en attendant la fin des E/S liées au périphérique. La fonction système ne se terminera pas tant que tous les serveurs sont occupés.

Figure 13.13. Configuration du serveur de terminaux

*quinze. Lorsqu'un utilisateur se connecte au système, la discipline de ligne de terminal stocke l'information selon laquelle le terminal est un terminal d'opérateur dirigeant un groupe de processus. Pour cette raison, lorsque l'utilisateur appuie sur la touche "break" du clavier du terminal, tous les processus du groupe reçoivent le signal d'interruption. Considérons une configuration système dans laquelle tous les terminaux sont physiquement connectés à une machine, mais l'enregistrement de l'utilisateur est logiquement implémenté sur d'autres machines (Figure 13.13). Dans chaque cas, le système crée un processus getty pour le terminal distant. Si les demandes adressées à un système distant sont traitées par un ensemble de processus serveur, notez que lorsque la procédure d'ouverture est exécutée, le serveur arrête d'attendre une connexion. Lorsque la fonction d'ouverture est terminée, le serveur retourne dans le pool de serveurs, coupant sa connexion au terminal. Comment le signal d'interruption est-il envoyé en appuyant sur la touche "break" aux adresses des processus inclus dans le même groupe ?

*seize. Le partage de mémoire est une fonctionnalité inhérente aux machines locales. D'un point de vue logique, l'allocation d'une zone commune de mémoire physique (locale ou distante) peut être réalisée pour des processus appartenant à des machines différentes. Décrivez la mise en œuvre de ce point.

* 17. Le processus de pagination et les algorithmes de pagination discutés au chapitre 9 supposent l'utilisation d'un pager local. Quelles modifications doivent être apportées à ces algorithmes afin de pouvoir prendre en charge les dispositifs de déchargement à distance ?

*18. Supposons que la machine distante (ou le réseau) tombe en panne et que le protocole de couche réseau local enregistre ce fait. Développez un schéma de récupération pour un système local qui envoie des requêtes à un serveur distant. En outre, développez un schéma de récupération pour un système serveur qui a perdu le contact avec les clients.

*dix-neuf. Lorsqu'un processus accède à un fichier distant, il est possible que le processus traverse plusieurs machines à la recherche du fichier. Prenons le nom "/usr/src/uts/3b2/os" comme exemple, où "/usr" est le répertoire appartenant à la machine A, "/usr/src" est le point de montage de la racine de la machine B, " /usr/src/uts/3b2 "est le point de montage de la racine de la machine C. Parcourir plusieurs machines jusqu'à sa destination finale s'appelle un" multisaut ". Cependant, s'il existe une connexion réseau directe entre les machines A et C, l'envoi de données via la machine B serait inefficace. Décrire les caractéristiques de la mise en œuvre du "multishopping" dans un système avec une connexion Newcastle et dans un système distribué "transparent".

De nos jours, pratiquement tous les grands systèmes logiciels sont distribués. Un système distribué est un système dans lequel le traitement de l'information n'est pas concentré sur un ordinateur, mais est réparti entre plusieurs ordinateurs. Lors de la conception de systèmes distribués, qui a beaucoup en commun avec la conception de tout autre logiciel, il y a encore un certain nombre de caractéristiques spécifiques à prendre en compte. Certains d'entre eux ont déjà été mentionnés dans l'introduction du chapitre 10 lorsque nous avons examiné l'architecture client/serveur, et sont discutés plus en détail ici.

Étant donné que les systèmes distribués sont répandus de nos jours, les développeurs de logiciels doivent se familiariser avec les spécificités de leur conception. Jusqu'à récemment, tous les grands systèmes étaient en grande partie centralisés, s'exécutant sur un seul ordinateur hôte (mainframe) auquel étaient connectés des terminaux. Les terminaux ne traitaient pratiquement pas les informations - tous les calculs étaient effectués sur la machine hôte. Les développeurs de tels systèmes n'avaient pas à penser aux problèmes de l'informatique distribuée.

Tous les systèmes logiciels modernes peuvent être divisés en trois grandes classes.

1. Systèmes logiciels d'application conçus pour fonctionner uniquement sur un seul ordinateur personnel ou poste de travail. Ceux-ci incluent les traitements de texte, les tableurs, les systèmes graphiques, etc.

2. Systèmes embarqués conçus pour fonctionner sur un seul processeur ou sur un groupe intégré de processeurs. Il s'agit notamment des systèmes de contrôle pour les appareils ménagers, divers appareils, etc.

3. Systèmes distribués dans lesquels le logiciel s'exécute sur un groupe faiblement intégré de processeurs parallèles reliés via un réseau. Il s'agit notamment des systèmes ATM appartenant à une banque, des systèmes de publication, des systèmes logiciels partagés, etc.

Actuellement, il existe des frontières claires entre les classes de systèmes logiciels répertoriées, qui seront de plus en plus floues à l'avenir. Au fil du temps, à mesure que les réseaux sans fil à haut débit deviendront largement disponibles, il sera possible d'intégrer dynamiquement des appareils avec des systèmes logiciels intégrés, tels que des organisateurs électroniques avec des systèmes plus généraux.

Il existe six caractéristiques principales des systèmes distribués.

1. Partage des ressources. Les systèmes distribués permettent le partage de ressources matérielles et logicielles telles que des disques durs, des imprimantes, des fichiers, des compilateurs et autres qui sont liés via un réseau. Il est évident que le partage de ressources est également possible dans les systèmes multi-utilisateurs, mais dans ce cas, l'ordinateur central doit être responsable de la mise à disposition des ressources et de leur gestion.

2. Ouverture. Il s'agit de la possibilité d'étendre le système en ajoutant de nouvelles ressources. Les systèmes distribués sont des systèmes ouverts qui connectent du matériel et des logiciels de différents fabricants.

3. Parallélisme. Dans les systèmes distribués, plusieurs processus peuvent s'exécuter simultanément sur différents ordinateurs du réseau. Ces processus peuvent (mais pas nécessairement) interagir les uns avec les autres pendant leur exécution.

4. Évolutivité. En principe, tous les systèmes distribués sont évolutifs : afin de répondre aux nouvelles exigences, le système peut être étendu en ajoutant de nouvelles ressources de calcul. Mais en pratique, l'accumulation peut être limitée au réseau reliant les ordinateurs individuels du système. Si de nombreuses nouvelles machines sont connectées, la bande passante du réseau peut ne pas être suffisante.

5. Tolérance aux pannes. La présence de plusieurs ordinateurs et la possibilité de dupliquer les informations signifient que les systèmes distribués sont résistants à certaines erreurs matérielles et logicielles. La plupart des systèmes distribués, en cas d'erreur, peuvent généralement prendre en charge au moins une fonctionnalité partielle. Une défaillance complète du système ne se produit qu'en cas d'erreurs de réseau.

6. Transparence. Cette propriété signifie que les utilisateurs bénéficient d'un accès totalement transparent aux ressources et qu'en même temps, les informations sur la répartition des ressources dans le système leur sont cachées. Cependant, dans de nombreux cas, une connaissance spécifique de l'organisation du système aide l'utilisateur à mieux utiliser les ressources.

Bien entendu, les systèmes distribués présentent un certain nombre d'inconvénients.

Complexité. Les systèmes distribués sont plus complexes que les systèmes centralisés. Il est beaucoup plus difficile de comprendre et d'évaluer les propriétés des systèmes distribués en général, et aussi de tester ces systèmes. Par exemple, ici, les performances du système ne dépendent pas de la vitesse d'un processeur, mais de la bande passante du réseau et de la vitesse de différents processeurs. Le déplacement de ressources d'une partie du système à une autre peut affecter considérablement les performances du système.

Sécurité. En règle générale, le système est accessible à partir de plusieurs machines différentes, les messages sur le réseau peuvent être consultés ou interceptés. Par conséquent, dans un système distribué, il est beaucoup plus difficile de maintenir la sécurité.

Contrôlabilité. Le système peut être constitué de différents types d'ordinateurs sur lesquels différentes versions de systèmes d'exploitation peuvent être installées. Les erreurs sur une machine peuvent se propager à d'autres machines avec des conséquences imprévisibles. Par conséquent, beaucoup plus d'efforts sont nécessaires pour gérer et maintenir le système en état de fonctionnement.

Imprévisibilité. Comme tous les internautes le savent, la réponse des systèmes distribués à certains événements est imprévisible et dépend de la pleine charge du système, de son organisation et de la charge du réseau. Tous ces paramètres pouvant être en constante évolution, le temps consacré à l'exécution de la demande de l'utilisateur à un moment ou à un autre peut varier considérablement.

Lors de l'examen des avantages et des inconvénients des systèmes distribués, un certain nombre de problèmes de conception critiques pour de tels systèmes sont identifiés (tableau 9.1).

Tableau 9.1. Problèmes de conception de systèmes distribués

Problème de conception	La description
Identification des ressources	Les ressources d'un système distribué sont situées sur différents ordinateurs. Le système de nommage des ressources doit donc être pensé de manière à ce que les utilisateurs puissent facilement accéder aux ressources dont ils ont besoin et s'y référer. Un exemple est le système Uniform Resource Locator (URL), qui définit les adresses des pages Web. Sans un système d'identification facilement perceptible et universel, la plupart des ressources seront inaccessibles aux utilisateurs du système.
Communication	L'opérabilité universelle d'Internet et la mise en œuvre efficace des protocoles TCP/IP sur Internet pour la plupart des systèmes distribués sont des exemples du moyen le plus efficace d'organiser la communication entre ordinateurs. Cependant, lorsque des exigences spéciales sont imposées sur les performances, la fiabilité, etc., des méthodes alternatives de communication du système peuvent être utilisées.
Qualité de service du système	La qualité de service offerte par le système reflète sa performance, son opérabilité et sa fiabilité. La qualité de service est influencée par un certain nombre de facteurs : la répartition des processus du système, l'allocation des ressources, le matériel système et réseau et l'adaptabilité du système.
Architecture logicielle	L'architecture logicielle décrit la distribution des fonctions du système entre les composants du système, ainsi que la distribution de ces composants entre les processeurs. Si vous devez maintenir un service système de haute qualité, le choix de la bonne architecture s'avère être un facteur décisif.

Le défi pour les concepteurs de systèmes distribués est de concevoir des logiciels ou du matériel pour fournir toutes les caractéristiques requises d'un système distribué. Cela nécessite de connaître les avantages et les inconvénients des différentes architectures de systèmes distribués. Deux types apparentés d'architectures de systèmes distribués se distinguent ici.

1. Architecture client/serveur. Dans ce modèle, le système peut être considéré comme un ensemble de services fournis par les serveurs aux clients. Dans de tels systèmes, les serveurs et les clients diffèrent considérablement les uns des autres.

2. Architecture d'objets distribués. Dans ce cas, il n'y a pas de différences entre les serveurs et les clients, et le système peut être considéré comme un ensemble d'objets en interaction, dont l'emplacement n'a pas vraiment d'importance. Il n'y a pas de distinction entre le fournisseur de service et ses utilisateurs.

Dans un système distribué, différents composants du système peuvent être implémentés dans différents langages de programmation et exécutés sur différents types de processeurs. Les modèles de données, la présentation des informations et les protocoles de communication ne sont pas nécessairement tous du même type dans un système distribué. Par conséquent, les systèmes distribués nécessitent des logiciels capables de gérer ces parties hétérogènes et de garantir l'interaction et l'échange de données entre elles. Middleware fait précisément référence à cette classe de logiciels. Il est, pour ainsi dire, au milieu entre les différentes parties des composants distribués du système.

Les systèmes distribués sont généralement conçus avec une approche orientée objet. Ces systèmes sont créés à partir de parties faiblement intégrées, chacune pouvant interagir directement avec l'utilisateur et d'autres parties du système. Ces parties doivent, dans la mesure du possible, réagir à des événements indépendants. Les objets logiciels basés sur ces principes sont des composants naturels des systèmes distribués. Si vous n'êtes pas déjà familiarisé avec le concept d'objets.