Systèmes répartis

L'architecture d'un réseau local classique reste simple. Il y a un serveur et un certain nombre de postes clients qui y sont tous connectés par un câble pouvant transporter au minimum quelques mégabits par seconde. Le serveur n'apparaît en fait pour les clients que comme un disque dur supplémentaire qu'ils partageraient et un programme lancé sur l'un d'eux ne peut être exécuté que par cette machine même. En d'autres termes les possibilités sont assez limitées mis à part la concentration de fichiers pour éviter leur duplication à n exemplaires.

Le principe d'un système d'exploitation réparti est tout autre. Le groupe d'ordinateurs reliés à l'aide du câble apparaît alors comme une seule machine. Cela signifie qu'une application ou une information donnée peut être stockée à un seul endroit sur l'un quelconque des postes et être disponible pour tout le monde. Il y a donc encore économie de l'espace disque. Mais à part l'utiliser comme un micro-ordinateur normal, l'idée est de pouvoir aussi exécuter des programmes ou processus sur l'un des autres ordinateurs de façon transparente (s'il à du temps CPU disponible). Pour cela il faut bien sûr que chacun d'eux fonctionne en vrai multitâche pour que son utilisateur ne risque pas d'être perturbé par cette arrivée imprévue. C'est un moyen d'économiser une machine plus puissante pour le calcul si on n'en a pas un besoin régulier.

Si le système est prévu pour diviser chaque disque dur en une partie utilisateur et une partie globale gérée automatiquement, cela apporte des fonctionnalités touchant à la sécurité et aux performances du réseau : possibilité de sauvegarder automatiquement dans un format compressé des fichiers sur un autre disque et ainsi de pouvoir les restaurer très vite, d'avoir des caches (éphémères) ou des miroirs pour des données qui sont régulièrement recherchées… Mais dans le commerce il est peu question de systèmes répartis, probablement parce qu'ils soulèvent des problèmes particuliers : décalages (les ordinateurs ont des horloges différentes), panne inopinée d'un des postes ne devant pas arrêter tout le système… Il pourrait être utile d'en limiter les objectifs afin d'avoir les avantages en minimisant les difficultés de conception, en généralisant une notion de tolérances ayant des degrés de 0 à n : un programme sans contrainte particulière comme une tâche de fond aurait la tolérance la plus large et pourrait donc être traité dans n'importe quel cas tandis qu'un autre devant réagir en temps réel aurait la plus stricte et son fonctionnement suivrait des conditions précises.