FR 2867869 A1 20050923 FR 0402771 A 20040316 La présente invention concerne un procédé pour l'émulation logicielle de disques durs d'une plate-forme informatique au niveau du système d'exploitation, avec gestion paramétrable à la volée des requêtes d'écriture et de lecture. Elle permet notamment l'émulation complète d'un ou plusieurs disques durs émulés, vus comme de véritables disques durs par le système d'exploitation d'une plate-forme informatique, telle un ordinateur personnel (PC) ; les données contenues dans un disque dur émulé peuvent être stockées sur tout type de support, tel un serveur sur un réseau, un CD-R, un DVD-ROM, une mémoire flash, un disque dur externe. L'invention permet ainsi l'émulation complète d'un disque dur système, c'est-à-dire un disque dur permettant l'amorçage de l'ordinateur et subséquemment le chargement complet du système d'exploitation dont les composants sont stockés dans ledit disque dur émulé. D'une manière générale, on sait que dans les micro-ordinateurs utilisés à l'heure actuelle, le système d'exploitation, les programmes applicatifs ainsi que les données propres aux utilisateurs, sont stockés dans un disque dur accessible par l'unité centrale de l'ordinateur. 2867869 -2- Les disques durs se présentent comme des empilements de plusieurs plateaux dont les différentes faces sont accessibles par des peignes de têtes; sur chaque piste sont inscrits des secteurs. Par exemple, pour les micro-ordinateurs compatibles "IBM PC", le "BIOS" (système de base d'entrées/sorties) lit ou écrit les informations venant ou allant au disque dur à l'aide d'une boucle de programme. Les programmes applicatifs peuvent utiliser le BIOS pour lire ou écrire sur le disque dur, soit directement au niveau des secteurs via l'interruption logicielle "int 13h", soit plus fréquemment au travers du système de fichiers via l'interruption logicielle "int 21h". Le premier secteur du disque dur contient un programme spécial chargé en mémoire et lancé par le "BIOS" au démarrage de l'ordinateur. Ce programme, nommé "MBR" (Master Boot Record) gère un éventuel partitionnement du disque en plusieurs sous-espaces, appelés "partitions". Ces "partitions" peuvent être attribuées à des systèmes d'exploitation différents que l'utilisateur peut choisir au démarrage de l'ordinateur. Une fois que ce choix est réalisé, un programme (appelé "BOOT") contenu dans les premiers secteurs de chaque partition est chargé à son tour et lancé. Son rôle est de charger le système d'exploitation stocké sur la partition correspondante du disque dur et de le lancer. Les secteurs suivants servent à gérer l'espace réservé aux fichiers. Ainsi, lors de la mise en route, le micro-ordinateur procède au chargement dans sa mémoire vive (RAM) du système d'exploitation contenu dans le disque dur, puis les logiciels applicatifs ainsi que les données utilisateurs. Il s'avère que lors de ces opérations de mise en route, la moindre anomalie 30 provoque fréquemment une déstabilisation engendrant un blocage du micro-ordinateur. 2867869 -3- Par ailleurs, dans un but de sécurisation, dans de nombreux cas, l'accès au système d'exploitation et/ou à certains fichiers contenus dans le disque dur n'est possible que par certains utilisateurs identifiés après saisie et reconnaissance d'un mot de passe (identifiant). On constate, en pratique, que dans un système en réseau exploité par de nombreux utilisateurs, ce type de sécurité pose de plus en plus de problèmes en raison de la complexité de sa gestion. L'invention a donc plus particulièrement pour but de supprimer ces inconvénients, grâce à un procédé mettant en oeuvre l'émulation logicielle totale de disques durs au niveau des blocs de données, aussi appelés secteurs, ou au niveau du système de fichier, permettant ainsi d'utiliser dans les disques durs émulés tout type de systèmes de fichiers acceptés par le système d'exploitation. Selon l'invention, ce procédé est plus particulièrement caractérisé en ce qu'il consiste à créer dans une première étape une représentation d'un disque dur réel dans laquelle peuvent être adaptés les ordres de chargement et d'exécution de certains des composants du système d'exploitation d'une plate-forme informatique, puis de charger sur ladite plate-forme informatique au cours d'une deuxième étape un ou plusieurs pilotes de périphérique parmi lesquels au moins un des pilotes de périphérique permet le dialogue réel avec un support de stockage de données contenant les données du disque dur émulé, puis à simuler dans une troisième étape le comportement d'un véritable disque dur pour le système d'exploitation. En ce qui concerne le terme "support", on entend ici et dans le reste de la description, tout système permettant de conserver de façon volatile ou non volatile des données informatiques; ce terme désigne aussi bien un disque dur, un CD-ROM, une bande magnétique, ou un service de données accessibles par un réseau informatique. 2867869 -4- Par ailleurs, l'invention prévoie un traitement spécifique des opérations d'écriture effectuées dans le disque dur émulé. Par exemple, si le support de stockage de données dudit disque dur émulé est un média non réinscriptible à la volée (un CD-R par exemple), les données écrites pourront être stockées en mémoire vive ou sur un support acceptant les écritures à la volée, tel un véritable disque dur local. Le traitement spécifique des écritures permet de proposer des disques durs émulés volatils , c'est à dire ne retenant pas les modifications effectués dans le disque dur émulé après un redémarrage de l'émulation, des émulations standards, où le disque dur émulé se comporte exactement comme un disque dur normal. D'autres types de gestion des écritures sont prévus et permettent d'autres utilisations de l'invention. L'invention prévoit également que, si le support de stockage de données contenant les données du disque dur émulé le permet, par exemple si le support est un fichier stocké sur un serveur d'un réseau, plusieurs ordinateurs puissent accéder simultanément au disque dur émulé à travers ladite émulation. Dans ce cas, une méthode de diffusion dite "multicast" pourra être utilisée, de façon à réduire significativement la bande passante utilisée pour les lectures quasi-simultanées, demandées par plusieurs ordinateurs clients , qui s'effectueraient sur les mêmes parties du disque dur émulé. Grâce à ces dispositions, l'invention permet de résoudre les problèmes de déstabilisation lors de la mise en route de la plateforme informatique et les problèmes de sécurité précédemment évoqués et de simplifier grandement l'administration des plates-formes informatiques. Par ailleurs, dans le cas d'un système à réseau exploité par plusieurs utilisateurs, chaque poste n'est plus lié aux applications chargées localement ni aux utilisateurs habituels de la plate-forme. Par ailleurs, les erreurs effectuées par les utilisateurs n'ont plus d'incidence sur le fonctionnement global du système à réseau. 2867869 5 Ainsi, d'une façon plus précise, le procédé selon l'invention permet le dialogue entre le disque dur émulé et le système d'exploitation à la manière d'un véritable disque dur grâce au truchement d'un des pilotes de périphériques ci-dessus mentionnés, en simulant le comportement d'un véritable disque dur pour le système d'exploitation, à toutes les phases du processus d'amorçage, aussi bien pendant la phase dévolue traditionnellement au micro logiciel (BIOS par exemple) que pendant les phases prises en charges par le système d'exploitation lui- même, et en particulier par les composants de gestion des disques durs du système d'exploitation. Cette émulation totale, comprenant la possibilité d'amorçage, peut nécessiter des adaptations des ordres de chargement et d'exécution de certains des composants du système d'exploitation. Une gestion des requêtes d'écritures que le système d'exploitation émet vers le disque dur émulé, est effectuée au niveau des pilotes de périphériques et/ou au niveau d'un éventuel service serveur de disque dur sur le réseau. Cette gestion permet que les données écrites soient stockées, selon le paramétrage desdits pilotes de périphériques et/ou dudit service serveur de disque dur sur le réseau: ^ ou bien directement dans le support contenant le disque dur émulé, ^ ou bien dans la mémoire, vive ou virtuelle, accessible au système d'exploitation utilisant le disque dur émulé, ^ ou bien dans un espace de stockage volatil accessible au système d'exploitation utilisant le disque dur émulé, ^ ou bien dans un espace de stockage non volatil accessible au système d'exploitation utilisant le disque dur émulé, ^ ou bien dans un espace de stockage volatil accessible au service serveur de disques durs émulés sur un réseau informatique, ou bien dans un espace de stockage non volatil accessible au service 30 serveur de disques durs émulés sur un réseau informatique. 2867869 -6- Une gestion des requêtes de lecture que le système d'exploitation émet vers le disque dur émulé est effectuée au niveau des pilotes de périphériques et/ou au niveau d'un éventuel service serveur de disque dur sur le réseau de façon à ce que, pour un poste client, les lectures des données écrites précédemment soient effectuées dans l'espace de stockage idoine, c'est à dire: ^ ou bien directement dans le support contenant le disque dur émulé, ^ ou bien dans la mémoire, vive ou virtuelle, accessible au système d'exploitation utilisant le disque dur émulé, ^ ou bien dans un espace de stockage volatil accessible au système 10 d'exploitation utilisant le disque dur émulé, ^ ou bien dans un espace de stockage non volatil accessible au système d'exploitation utilisant le disque dur émulé, ^ ou bien dans un espace de stockage volatil accessible au service serveur de disques durs émulés sur un réseau informatique, ^ ou bien dans un espace de stockage non volatil accessible au service serveur de disques durs émulés sur un réseau informatique. Dans le cas où les données du ou des disque(s) dur(s) émulé(s) sont accessibles aux postes clients via un réseau informatique, un programme spécifique, appelé logiciel serveur , est en charge, sur un des postes du réseau informatique, d'une part des communications via le réseau avec les postes clients qui accèdent aux disques durs émulés, et d'autre part d'accéder au support des données contenant les données des disques durs émulés. Si le disque dur émulé doit être amorcé, un module micro logiciel bas niveau est responsable de l'accès aux données contenues dans le disque dur émulé. Ledit module logiciel fournit une interface de type micro logiciel (BIOS par exemple) afin de permettre la bonne exécution des fonctions de chargement des composants du système d'exploitation chargés traditionnellement par le micro logiciel lors de l'amorçage du système d'exploitation depuis un disque dur réel. Ce micro logiciel pourra, dans le cas d'ordinateurs de type compatible PC, utiliser un gestionnaire d'interruption 13h fournissant au système d'exploitation l'interface utilisée par ce dernier. Le micro logiciel pourra, dans le cas d'ordinateurs utilisant des programmes mémoires de démarrage de type "PXE" (PROM de démarrage PXE), utiliser les fonctions rendues disponibles par ces "PROMS" pour gérer les communications via le réseau informatique de façon indépendante du modèle d'interface réseau utilisée. Le micro logiciel bas niveau est chargé dans la mémoire du poste client puis exécuté en utilisant les fonctions rendues disponibles par une "PROM" de démarrage comme une puce d'amorçage "PXE" par exemple. Le micro logiciel bas niveau peut également être chargé dans la mémoire du poste client puis exécuté en tant que composant du micro logiciel basique (BIOS par exemple) du poste client. En particulier, ledit micro logiciel bas niveau fournit les mêmes fonctions que les services d'accès aux véritables disques durs fournis habituellement par le micro logiciel basique standard. Par exemple, dans le cas où les données contenues dans le disque dur émulé sont stockées sur un disque optique comme un CD ou un DVD, le micro logiciel bas niveau pourra être fourni par le constructeur du poste client en tant que partie du BIOS fournissant les fonctions d'amorçage BIOS depuis un disque optique. Le micro logiciel bas niveau peut enfin être chargé dans la mémoire du poste client depuis un support de données tiers supporté en tant que périphérique d'amorçage par le poste client, comme une disquette, un disque dur réel ou un disque optique, puis exécuté par le poste client. 2867869 -8- A noter que si certaines des données contenues dans le disque dur émulé sont accédées par un poste client via un réseau informatique, au moins un pilote de périphérique, chargé et exécuté par le système d'exploitation du poste client, fournit les fonctions de communication via le réseau informatique avec le logiciel serveur, lequel est chargé de fournir les services d'émulation du disque dur. Si le support de données contenant les données du ou des disque(s) dur(s) émulé(s) est un support ne supportant pas les écritures en temps réel, par exemple un disque optique CD-ROM, ou que le système d'émulation de disque dur selon l'invention est paramétré pour ne pas accepter les écritures de données directement dans le support contenant les données du disque dur émulé, par exemple, un disque dur émulé utilisé simultanément par plusieurs postes clients, les pilotes de périphériques et/ou un logiciel serveur exécuté par un poste d'un réseau informatique fournissant l'émulation de disque dur aux postes clients peuvent traiter les requêtes d'écritures de données émises par le système d'exploitation vers le(s) disque(s) dur(s) émulé(s) de façon à ce que les données écrites soient stockées dans un espace de stockage différent du support de données contenant les données du ou des disque(s) dur(s) émulé(s). Par exemple, les requêtes d'écritures de données émises par le système d'exploitation du poste client vers le(s) disque(s) dur(s) émulé(s) sont traitées de façon à ce que les données écrites soient stockées dans la mémoire vive du poste client. Les requêtes d'écritures de données émises par le système d'exploitation du poste client vers le(s) disque(s) dur(s) émulé(s) peuvent être, soit traitées de façon à ce que les données écrites soient stockées dans la mémoire virtuelle du poste client, c'est à dire dans un fichier de données, accessible au système d'exploitation du poste client, et servant d'espace mémoire additionnel, soit traitées de façon à ce que les données écrites soient stockées dans un fichier de données, accessible au système d'exploitation du poste client. Les requêtes d'écriture de données émises par le système d'exploitation vers le(s) disque(s) dur(s) émulé(s) sont, à un instant donné, redirigées dans un et un seul espace de stockage. L'espace de stockage dans lequel sont redirigées les écritures, peut être changé à la volée durant une session d'exécution du système d'exploitation d'un poste client. L'espace de stockage utilisé pour le stockage des écritures peut être volatil, c'est à dire être vidé des données qui y sont stockées à chaque nouvelle session d'exécution du système d'exploitation d'un poste client, ou bien non volatil de façon à permettre la persistance des données écrites d'une session d'exécution du système d'exploitation d'un poste client à une autre. La volatilité ou la persistance de l'espace de stockage utilisé pour le stockage des écritures est paramétrable quand cela a du sens. Le caractère volatil des redirections d'écriture est déterminé à l'initialisation de la session d'exécution du système d'exploitation d'un poste client et, s'il est modifié à la volée, il n'aura d'effet pour le poste client qu'après un démarrage ou un redémarrage de ce dernier. Les requêtes de lecture de données émises par le système d'exploitation peuvent être effectuées dans différents espaces de stockage lors d'une session d'exécution du système d'exploitation. Dans ce cas, les requêtes de lecture de données émises par le système d'exploitation vers un disque dur émulé, effectuées dans différents espaces de stockage, le sont en suivant un ordre de priorité qui découle de l'ordre précédent des différentes redirections des requêtes d'écriture. Lesdits ordres de priorité dépendent de la séquence précédemment effectuée pour les redirections des requêtes d'écriture. On s'assure ainsi que, du point de vue du poste client, le disque dur émulé est toujours cohérent; en particulier, si une donnée particulière Dl (un secteur d'un disque dur émulé ou un fichier d'un système de fichier) a été écrite dans un espace de données El à un moment donné, puis que les requêtes d'écriture ont été redirigées dans un autre espace E2, puis que la même donnée Dl (le même secteur ou le même 2867869 -10- fichier) a été modifiée et subséquemment écrite dans l'espace E2, les requêtes de lectures sur Dl se feront dans l'espace E2 (qui a la plus grande priorité), de façon à lire la version de D 1 la plus récemment écrite. Par exemple: 1. Les données à lire se trouvent-elles dans la mémoire vive ou virtuelle du poste client, à cause de précédentes requêtes d'écriture redirigées dans cet espace de stockage ? Si oui les y lire, si non, 2. Les données à lire se trouvent-elles dans un espace de stockage tampon (un fichier par exemple) accessible aux pilotes de périphériques qui sont parties de l'invention du poste client, à cause de précédentes requêtes d'écriture redirigées dans cet espace de stockage ? Si oui les y lire, si non, 3. Les données du disque dur émulé sont elles stockées sur un serveur dans un réseau informatique ? si oui traiter le point 4, si non traiter le point 5, 4. Les données à lire se trouvent-elle dans un espace de stockage tampon (un fichier par exemple) accessible d'un module serveur, à cause de précédentes requêtes d'écriture redirigées dans cet espace de stockage ? Si oui les y lire, si non, 5. Lire les données directement dans le support contenant les données non modifiées du disque dur émulé. Avantageusement, si le système d'émulation de disque dur est paramétré de façon à ce que les requêtes d'écritures reçues par le logiciel serveur à destination d'un disque dur émulé particulier ne sont pas redirigées mais stockées directement dans support contenant les données du disque dur émulé lui-même, un seul poste client peut accéder audit disque dur émulé à un instant donné. On évite ainsi les problèmes d'accès concurrent en écriture à un même 30 ensemble de données. 2867869 -11- Le paramétrage pour lequel les requêtes d'écritures ne sont pas redirigés est, par exemple, le paramétrage à utiliser pour mettre à disposition des postes clients, un nouveau composant logiciel (un nouvel applicatif logiciel par exemple) : É Le paramétrage d'accès au disque dur émulé est positionné de façon à ce que les requêtes d'écritures ne soient pas redirigées, É Le composant nouveau logiciel est installé comme s'il était installé sur un disque dur réel, É Le poste client depuis lequel l'installation a été effectuée est éteint, É Le paramétrage d'accès au disque dur émulé est modifié de façon à ce que les requêtes d'écriture émanant des postes clients soient redirigées, É Tous les postes client qui utilisent le disque dur émulé en question ont désormais accès au nouveau composant logiciel sans qu'il ait été nécessaire de le mettre explicitement à la disposition de chaque poste client. Pour permettre à plusieurs postes clients l'accès simultané à un même disque dur émulé, le logiciel serveur est capable de rediriger spécifiquement les requêtes d'écriture émises par un poste client A dans un espace de stockage donné, par exemple un fichier dans l'espace de stockage accessible au poste serveur, et de rediriger les requêtes d'écriture émises par un autre poste client B dans un autre espace de stockage donné, par exemple un autre fichier dans l'espace de stockage accessible au poste serveur. Afin d'accélérer l'accès simultané par plusieurs postes client au même disque dur émulé dont les données sont contenues dans un support de données accessible au poste serveur, les données envoyées par le poste serveur aux postes clients dans le cadre de l'émulation de disque dur peuvent être envoyées globalement et en une seule fois en utilisant des mécanismes de "broadcast" ou de "multicast" au lieu de mécanismes dits "unicast". 2867869 - 12 - Les données envoyées en "broadcast" ou en "multicast" par le poste serveur sont stockées par les postes clients qui les acceptent dans un cache local, situé dans la mémoire (réelle ou virtuelle) desdits postes clients. Avantageusement, les postes clients peuvent effacer du cache les données qui y sont depuis plus d'un temps donné et paramétrable (TimeOut). En effet, ces données pourraient, si elles ne sont pas pertinentes et si elles ne sont jamais lues, engorger inutilement le cache "multicast" des postes clients. Une requête de lecture de données dans le disque dur émulé émise par le système d'exploitation d'un poste client génère une demande explicite de lecture émise vers le poste serveur uniquement si lesdites données ne sont pas déjà présentes dans ledit cache local. Si lesdites données sont effectivement déjà présentes dans ledit cache local, elles y sont lues et transmises au système d'exploitation du poste client. Les données lues dans le cache local en sont retirées dès qu'elles sont lues par le poste client, de façon à libérer de la place dans ledit cache local. La décision d'envoyer, dans le cadre de l'émulation de disques durs selon l'invention, des données en "multicast/broadcast" ou en "unicast" est effectuée au niveau du module serveur qui fournit les fonctionnalités nécessaires à l'émulation de disques durs aux postes clients. Les postes clients peuvent modifier leur souscription à la réception de données envoyées via "broadcast/multicast" par le poste serveur dans le cadre de l'émulation de disques durs selon l'invention. Par exemple, les postes clients, une fois qu'ils ont été amorcés depuis un disque dur émulé et que l'interface homme/machine permettant à un ou plusieurs utilisateurs d'exploiter le poste client est utilisable, la souscription à la réception de données via "broadcast/multicast" peut être résiliée, par exemple par un mécanisme de 2867869 - 13 - désabonnement à un groupe d'adresses "multicast", de façon à ce que les postes clients complètement amorcés n'aient plus à traiter les flots de données "multicast/broadcast" ; cela peut s'avérer très utile si les données envoyées par le poste serveur via "multicast/broadcast" ne sont destinées qu'à permettre l'accès aux portions du disque système émulé nécessaire à l'amorçage complet du système d'exploitation du poste client, et plus du tout utile aux postes clients déjà amorcés. Ainsi, un poste client déjà amorcé depuis un disque dur émulé n'est pas pollué par les données envoyées en "broadcast/multicast" à des postes clients en cours d'amorçage. Selon l'invention, afin de permettre l'amorçage depuis et/ou des accès simultanés au même disque dur émulé ou à des copies 100% identiques d'un même disque dur émulé, certains composants constituant l'invention chargés et exécutés par les postes clients, par exemple un ou plusieurs pilotes de périphériques, ou par un logiciel serveur, sont capables de modifier, à la volée ou avant leur utilisation effective par le système d'exploitation, certaines données contenues dans le disque dur émulé, par exemple l'identifiant unique d'un poste client sur le réseau (nom d'ordinateur ou adresse "IP" par exemple) ou le mot de passe du compte du poste client dans un domaine d'authentification (domaine "active directory" par exemple), des numéros de séries de logiciels, ou encore des données d'authentification telles que les données nécessaires à l'activation de certains produits "Microsoft". L'émulation elle-même peut être effectuée, pour le système d'exploitation du poste client, au niveau de la classe de périphériques virtuels de type système de fichier (file system), comme dans les produits "Qualystem LiteNET PC 1.x et Qualystem LAN PC 2.x" (file system CIFS ou SMB) ou "Qualystem Rescue 1.x" (file system IS09660/Joliet, CDFS ou UDF). L'émulation peut être également effectuée, pour le système d'exploitation du poste client, au niveau de la classe de périphériques disques ellemême et non 2867869 -14- pas au niveau du système de fichier. Ce type d'émulation est mis en oeuvre par exemple dans les produits "Qualystem LAN PC 3.x" (Support de données des disques durs émulés résidant sur un serveur d'un réseau informatique) ou "Qualystem Rescue 2.x et 3.x" (Support de données des disques durs émulés résidant dans la partie d'amorçage, dite "El Torito", d'un disque optique, CD ou DVD). Les données significatives contenues dans le disque dur émulé y sont copiées par un outil logiciel exécuté sur un poste de référence depuis un disque dur réel dit disque dur de référence, accessible au système d'exploitation dudit poste de référence. L'outil logiciel crée un fichier ou un répertoire image (fichier image pour l'émulation au niveau disque dur, répertoire image pour l'émulation au niveau du système de fichier) qui contient les données du disque dur émulé. Ledit fichier image ou répertoire image est créé en effectuant une copie de chaque fichier contenu dans le disque dur réel, utilisé comme référence pour créer le fichier image ou le répertoire image. Dans le cas du fichier image, ce dernier est une représentation bit à bit d'un véritable disque dur considéré comme un tableau de bits. C'est la représentation logique d'un disque dur sous forme de tableau de bits qui est utilisée. Le fichier image contient ainsi les informations nécessaires à la représentation de la structure logique d'un véritable disque dur, comme le secteur de "BOOT" primaire (MBR, Master Boot Record) et la table des partitions. Il contient aussi le ou les secteurs d'amorçage des partitions contenues dans le disque dur émulé. Le logiciel qui crée le fichier image à partir d'un disque dur réel peut être amené, si le disque dur émulé doit être amorcé, à modifier dans les données stockées dans le fichier image, certaines des informations utilisées par le système d'exploitation chargé depuis le disque dur émulé, afin de rendre opérationnel et effectif l'amorçage dudit système d'exploitation depuis ledit disque dur émulé. 2867869 -15 Afin de permettre l'amorçage depuis un disque dur émulé, la séquence de chargement des composants du système d'exploitation peut nécessiter une adaptation de façon à ce que tous les composants du système d'exploitation dont dépendent les pilotes de périphérique permettant l'accès au disque dur émulé selon l'invention soient chargés et utilisables au moment ou le système d'exploitation a besoin d'accéder au disque dur émulé en utilisant les pilotes de périphériques et non plus en utilisant les fonctions du "firmware" (BIOS). Par exemple, si les données contenues dans le disque dur émulé utilisé pour l'amorçage du système d'exploitation d'un micro ordinateur sont stockées dans un fichier sur un serveur d'un réseau informatique, les pilotes permettant au système d'exploitation du poste client d'utiliser àl'interface réseau dudit poste client doivent être chargés et utilisables avant que le système d'exploitation n'ait besoin d'accéder au disque dur émulé via les pilotes de périphérique, pour continuer son chargement; de même, à ce moment, les pilotes des protocoles réseau utilisés par les pilotes de périphériques permettant d'accéder au disque dur émulé devront être chargés et utilisables. Un autre exemple est celui où les données contenues dans le disque dur émulé utilisé pour l'amorçage du système d'exploitation d'un micro ordinateur sont stockées dans la partie d'amorçage d'un disque optique (CD ou DVD). Dans un tel cas, les pilotes de périphériques permettant au système d'exploitation d'accéder audit lecteur de disque optique doivent être chargés et utilisables avant que le système d'exploitation ait besoin d'accéder au disque dur émulé, via les pilotes de périphérique, pour continuer son chargement. Il se peut donc que l'ordre de chargement des composants dont dépendent les pilotes de périphériques permettant d'accéder au disque dur émulé doive être adapté. 2867869 - 16- Dans le cas où les données d'un disque dur émulé sont accédées par un client via un réseau informatique, le(s) éventuel(s) module(s) serveur peut(peuvent) mettre à disposition sur le réseau des disques durs émulés en utilisant un protocole propriétaire, comme celui utilisé actuellement dans "Qualystem LAN PC 3" ou en utilisant un protocole tiers idoine, par exemple un protocole 'standard' afin d'exporter des disques durs ou des systèmes de fichiers distants, par exemple le protocole "iSCSI" (disque dur distant) ou les protocoles "SMB/CIFS" ou "NFS" (systèmes de fichiers distants). L'éventuel module serveur est alors un service auquel les clients qui parlent le protocole utilisé peuvent se connecter et ainsi accéder aux ressources de données mises à disposition par ledit service. Il existe bien sûr la possibilité, au niveau dudit service, de gérer les écritures de façon paramétrable, et de pouvoir, en particulier, les effectuer dans un espace de stockage spécifique au couple poste client/disque dur virtuel, espace de stockage qui n'est pas l'espace de stockage commun à tous les clients. Les clients qui peuvent se connecter aux disques durs émulés mis à disposition par le module serveur sur le réseau peuvent ainsi être des clients "standard", par exemple des clients "iSCSI" standard, ou des clients "SMB/CIFS" standards, et non pas forcément des clients "QualystemTM LAN-PC 3", par exemple. De même, les programmes exécutés par les postes clients, module logiciel bas niveau ou pilotes de périphériques, peuvent utiliser, pour accéder aux données contenues dans les disques durs émulés, un protocole réseau propriétaire, tel le protocole "NVD" de "Qualystem LAN PC 3", ou un protocole tiers, par exemple standard tel "iSCSI" ou "SMB/CIFS". Selon que l'implémentation, au niveau des modules serveurs ou clients, implémente les fonctions de la présente invention, la redirection des requêtes d'écriture pourra alors être effective ou bien au niveau des modules clients, ou bien au niveau des modules serveurs, ou bien pour ces deux types de modules, avec les avantages décrits précédemment. 2867869 - 17- Ainsi, la sécurisation de l'accès au système d'exploitation et/ou à certains fichiers contenus dans le disque dur, et notamment dans un système en réseau exploité par de nombreux utilisateurs, est assurée grâce au procédé selon l'invention, qui met en oeuvre une émulation logicielle totale des disques durs au niveau des blocs de données ou du système fichier, permettant ainsi d'utiliser dans des disques durs émulés tout type de systèmes de fichiers acceptés par le système d'exploitation. -18-Revendications 1. Procédé pour l'émulation logicielle de disques durs d'une plate-forme informatique au niveau du système d'exploitation, avec gestion 5 paramétrable à la volée des requêtes d'écriture et de lecture, caractérisé en ce qu'il consiste à créer dans une première étape une représentation d'un disque dur réel dans laquelle peuvent être adaptés les ordres de chargement et d'exécution de certains des composants du système d'exploitation de la plate-forme informatique, puis de charger sur ladite plate- forme informatique au cours d'une deuxième étape un ou plusieurs pilotes de périphérique parmi lesquels au moins un des pilotes de périphérique permet le dialogue réel avec un support de stockage de données contenant les données du disque dur émulé, puis à simuler dans une troisième étape le comportement d'un véritable disque dur pour le système d'exploitation. 2. Procédé selon la revendication 1, caractérisé en ce que la gestion des susdites requêtes d'écriture que le système d'exploitation émet vers le disque dur émulé est effectuée au niveau des pilotes de périphériques et/ou au niveau d'un éventuel service serveur de disque dur sur le réseau, les données écrites étant stockées, selon le paramétrage desdits pilotes de périphériques et/ou dudit service serveur de disque dur sur le réseau: ^ ou bien directement dans le support contenant le disque dur émulé, ^ ou bien dans la mémoire, vive ou virtuelle, accessible au système 25 d'exploitation utilisant le disque dur émulé, ^ ou bien dans un espace de stockage volatil accessible au système d'exploitation utilisant le disque dur émulé, ^ ou bien dans un espace de stockage non volatil accessible au système d'exploitation utilisant le disque dur émulé, ^ ou bien dans un espace de stockage volatil accessible au service serveur de disques durs émulés sur un réseau informatique, 2867869 - 19- ^ ou bien dans un espace de stockage non volatil accessible au service serveur de disques durs émulés sur un réseau informatique. 3. Procédé selon la revendication 1, caractérisé en ce que la gestion des susdites requêtes de lecture que le système d'exploitation émet vers le disque dur émulé est effectuée au niveau des pilotes de périphériques et/ou au niveau d'un éventuel service serveur de disque dur sur le réseau, les lectures des données écrites précédemment étant effectuées dans un espace de stockage: ^ ou bien directement dans le support contenant le disque dur émulé, ^ ou bien dans la mémoire, vive ou virtuelle, accessible au système d'exploitation utilisant le disque dur émulé, ^ ou bien dans un espace de stockage volatil accessible au système d'exploitation utilisant le disque dur émulé, ^ ou bien dans un espace de stockage non volatil accessible au système d'exploitation utilisant le disque dur émulé, ^ ou bien dans un espace de stockage volatil accessible au service serveur de disques durs émulés sur un réseau informatique, ^ ou bien dans un espace de stockage non volatil accessible au service 20 serveur de disques durs émulés sur un réseau informatique. 4. Procédé selon la revendication 1, caractérisé en ce que l'émulation de disque dur fournie au système d'exploitation d'un poste client peut être effectuée par le biais d'un seul pilote de périphérique monolithique, qui communique avec le système d'exploitation à la façon d'un disque dur et qui communique avec le support contenant les données dudit disque dur émulé de manière spécifique à ce support. 5. Procédé selon la revendication 1, 30 caractérisé en ce que les données du ou des disque(s) dur(s) émulé(s) sont accessibles aux postes clients via un réseau informatique. 2867869 - 20 - 6. Procédé selon la revendication 1, caractérisé en ce que si un disque dur émulé doit être amorcé, un module micro logiciel bas niveau est responsable de l'accès aux données contenues dans ledit disque dur émulé, en fournissant une interface de type de celle fournie par le micro logiciel chargé de l'accès aux données de véritables disques durs par le système d'exploitation amorcé sur le poste client. 7. Procédé selon les revendications 5 et 6, caractérisé en ce que le micro logiciel pourra, dans le cas d'ordinateurs utilisant des programmes mémoires de démarrage de type "PXE" (PROM de démarrage PXE), utiliser les fonctions rendues disponibles par ces "PROMS" pour gérer les communications via le réseau informatique de façon indépendante du modèle d'interface réseau utilisée. 8. Procédé selon la revendication 7, caractérisé en ce que le micro logiciel bas niveau est chargé dans la mémoire du poste client puis exécuté en utilisant les fonctions rendues disponibles par une "PROM" de démarrage. 9. Procédé selon la revendication 6, caractérisé en ce que le micro logiciel bas niveau est chargé dans la mémoire du poste client puis exécuté en tant que composant du micro logiciel basique standard (BIOS par exemple) du poste client, ledit micro logiciel bas niveau fournissant les mêmes fonctions que les services d'accès aux véritables disques durs fournis habituellement par le micro logiciel basique standard 10. Procédé selon la revendication 6, caractérisé en ce que le micro logiciel bas niveau est chargé dans la mémoire 30 du poste client depuis un support de données tiers supporté en tant que périphérique d'amorçage par le poste client. 2867869 -21- 11. Procédé selon la revendication 5, caractérisé en ce qu'au moins un pilote de périphérique chargé et exécuté par le système d'exploitation du poste client fournit les fonctions d'accès, via le 5 réseau informatique, aux données contenues dans les disques durs émulés. 12. Procédé selon la revendication 1, caractérisé en ce que si le support de données contenant les données du ou des disque(s) dur(s) émulé(s) est un support ne supportant pas les écritures en temps réel, ou que le système d'émulation de disque dur selon l'invention est paramétré pour ne pas accepter les écritures de données directement dans le support contenant les données du disque dur émulé, les pilotes de périphériques fournissant l'émulation de disque dur aux postes clients traitent les requêtes d'écritures de données émises par le système d'exploitation vers le(s) disque(s) dur(s) émulé(s) de façon à ce que les données écrites soient stockées dans un espace de stockage différent du support de données contenant les données du ou des disque(s) dur(s) émulé(s). 13. Procédé selon la revendication 12, caractérisé en ce que les requêtes d'écritures de données émises par le système d'exploitation du poste client vers le(s) disque(s) dur(s) émulé(s) sont traitées de façon à ce que les données écrites soient stockées dans la mémoire vive du poste client. 14. Procédé selon la revendication 12, caractérisé en ce que les requêtes d'écritures de données émises par le système d'exploitation du poste client vers le(s) disque(s) dur(s) émulé(s) sont traitées de façon à ce, que les données écrites soient stockées dans la mémoire virtuelle du poste client. 2867869 - 22 - 15. Procédé selon la revendication 12, caractérisé en ce que les requêtes d'écriture de données émises par le système d'exploitation du poste client vers le(s) disque(s) dur(s) émulé(s) sont traitées de façon à ce que les données écrites soient stockées dans un fichier de données, accessible au système d'exploitation du poste client. 16. Procédé selon la revendication 1, caractérisé en ce que les requêtes d'écriture de données émises par le système d'exploitation vers le(s) disque(s) dur(s) émulé(s) sont, à un instant donné, redirigées dans un et un seul espace de stockage; l'espace de stockage dans lequel sont redirigées les écritures peut être changé à la volée durant une session d'exécution du système d'exploitation d'un poste client. 17. Procédé selon la revendication 12, caractérisé en ce que l'espace de stockage utilisé pour le stockage des écritures peut être volatil, c'est à dire être vidé des données qui y sont stockées à chaque nouvelle session d'exécution du système d'exploitation d'un poste client, ou bien non volatil de façon à permettre la persistance des données écrites d'une session d'exécution du système d'exploitation d'un poste client à une autre. 18. Procédé selon les revendications 16 et 17, caractérisé en ce que le caractère volatil des redirections d'écriture est déterminé à l'initialisation de la session d'exécution du système d'exploitation d'un poste client. 19. Procédé selon la revendication 1, caractérisé en ce que les requêtes de lecture de données émises par le système d'exploitation peuvent être effectuées dans différents espaces de stockage lors d'une session d'exécution du système d'exploitation d'un poste client. 2867869 - 23 - 20. Procédé selon la revendication 19, caractérisé en ce que les requêtes de lecture de données émises par le système d'exploitation vers un disque dur émulé, effectuées dans différents espaces de stockage, le sont en suivant un ordre de priorité. 21. Procédé selon la revendication 5, caractérisé en ce qu'un programme spécifique, appelé logiciel serveur , est en charge, sur un des postes du réseau informatique, d'une part des communications via le réseau avec les postes clients qui accèdent aux disques durs émulés, et d'autre part d'accéder au support de données contenant les données des disques durs émulés. 22. Procédé selon la revendication 21, caractérisé en ce que si le système d'émulation de disque dur est paramétré de façon à ce que les requêtes d'écritures reçues par le logiciel serveur à destination d'un disque dur émulé particulier ne sont pas redirigées mais stockées directement dans support contenant les données du disque dur émulé lui- même, un seul poste client peut accéder audit disque dur émulé à un instant donné. 23. Procédé selon la revendication 21, caractérisé en ce que pour permettre à plusieurs postes clients l'accès simultané à un même disque dur émulé, le logiciel serveur est capable de rediriger spécifiquement les requêtes d'écriture émises par un poste client A dans un espace de stockage donné, et de rediriger les requêtes d'écriture émises par un autre poste client B dans un autre espace de stockage donné. 24. Procédé selon la revendication 1, caractérisé en ce qu'afin de permettre l'amorçage depuis et/ou des accès simultanés au même disque dur émulé ou à des copies 100% identiques d'un même disque dur émulé, certains composants constituant l'invention chargés 2867869 -24- et exécutés par les postes clients ou par un logiciel serveur, sont capables de modifier, à la volée ou avant leur utilisation effective par le système d'exploitation, certaines données contenues dans le disque dur émulé. 25. Procédé selon la revendication 1, caractérisé en ce que l'émulation elle même est effectuée, pour le système d'exploitation du poste client, au niveau de la classe de périphériques virtuels de type système de fichier comme dans les produits "Qualystem LiteNET PC 1.x" et "Qualystem LAN PC 2.x" (file system CIFS ou SMB) ou "Qualystem Rescue l.x" (file system ISO9660/Joliet, CDFS ou UDF). 26. Procédé selon la revendication 1, caractérisé en ce que l'émulation est effectuée, pour le système d'exploitation du poste client, au niveau de la classe de périphériques disques elle-même et non pas au niveau du système de fichier. Ce type d'émulation est mis en oeuvre par exemple dans les produits "Qualystem LAN PC 3.x" (Support de données des disques durs émulés résidant sur un serveur d'un réseau informatique) ou "Qualystem Rescue 2.x et 3.x" (Support de données des disques durs émulés résidant dans la partie d'amorçage, dite "El Torito", d'un disque optique, CD ou DVD). 27. Procédé selon la revendication 1, caractérisé en ce que les données significatives contenues dans le disque dur émulé y sont copiées par un outil logiciel exécuté sur un poste de référence depuis un disque dur réel dit disque dur de référence, accessible au système d'exploitation dudit poste de référence. 28. Procédé selon les revendications 25 et 27, caractérisé en ce que l'outil logiciel crée un répertoire image qui contient les 30 données du disque dur émulé. 2867869 - 25 - 29. Procédé selon les revendications 26 et 27, caractérisé en ce que l'outil logiciel crée un fichier image qui contient les données du disque dur émulé. 30. Procédé selon la revendication 1, caractérisé en ce qu'afin de permettre l'amorçage depuis un disque dur émulé, la séquence de chargement des composants du système d'exploitation nécessite une adaptation de façon à ce que tous les composants du système d'exploitation dont dépendent les pilotes de périphérique permettant l'accès au disque dur émulé selon l'invention soient chargés et utilisables au moment où le système d'exploitation a besoin d'accéder au disque dur émulé en utilisant les pilotes de périphériques et non plus en utilisant les fonctions du "firmware" (BIOS). 31. Procédé selon la revendication 21, caractérisé en ce que pour accélérer l'accès simultané par plusieurs postes client au même disque dur émulé dont les données sont contenues dans un support de données accessible au poste serveur, les données sont envoyées par le logiciel serveur aux postes clients dans le cadre de l'émulation de disque dur, globalement et en une seule fois en utilisant des mécanismes de "broadcast" ou de "multicast" au lieu de mécanismes dit "unicast". 32. Procédé selon la revendication 31, caractérisé en ce que les données envoyées en "broadcast" ou "multicast" par 25 le poste serveur sont stockées par les postes clients qui les acceptent dans un cache local, situé dans la mémoire (réelle ou virtuelle) desdits postes clients. 33. Procédé selon la revendication 31, caractérisé en ce qu'une requête de lecture de données dans le disque dur 30 émulé émise par le système d'exploitation d'un poste client génère une 2867869 - 26 - demande explicite de lecture émise vers le poste serveur uniquement si lesdites données ne sont pas déjà présentes dans ledit cache local. 34. Procédé selon la revendication 33, caractérisé en ce que les données lues dans le cache local en sont retirées dès qu'elle sont lues par le poste client, de façon à libérer de la place dans ledit cache local. 35. Procédé selon la revendication 31, caractérisé en ce que la décision d'envoyer, dans le cadre de l'émulation de disques durs selon l'invention, des données en "multicast/broadcast" ou en "unicast" est effectuée au niveau du logiciel serveur qui fournit les fonctionnalités nécessaires à l'émulation de disques durs aux postes clients. 36. Procédé selon la revendication 31, caractérisé en ce que les postes clients peuvent modifier leur souscription à la réception de données envoyées via "broadcast/multicast" par le poste serveur dans le cadre de l'émulation de disques durs selon l'invention. 37. Procédé selon la revendication 32, caractérisé en ce que les postes clients peuvent effacer du cache local, les données qui y sont depuis plus d'un temps donné et paramétrable. 38. Procédé selon la revendication 5 caractérisé en ce que le module serveur mettant à disposition des postes clients les données contenues dans les disques durs émulés peut utiliser n'importe quel protocole réseau idoine. 2867869 - 27 - 39. Procédé selon les revendications 5 et 6 caractérisé en ce que le programme logiciel bas niveau, exécuté par les postes clients et permettant l'accès aux données contenues dans les disques durs émulés peut utiliser n'importe quel protocole réseau idoine. 40. Procédé selon la revendication 11 caractérisé en ce que le(s) pilote(s) de périphérique selon l'invention exécuté(s) par les postes clients et permettant l'accès aux données contenues dans les disques durs émulés peuvent utiliser n'importe quel protocole réseau idoine. 41. Procédé selon la revendication 21 caractérisé en ce que si le support de données contenant les données du ou des disque(s) dur(s) émulé(s) est un support ne supportant pas les écritures en temps réel, ou que le système d'émulation de disque dur selon l'invention est paramétré pour ne pas accepter les écritures de données directement dans le support contenant les données du disque dur émulé, le logiciel serveur fournissant l'émulation de disque dur aux postes clients traite les requêtes d'écritures de données émises par le système d'exploitation des postes clients vers le(s) disque(s) dur(s) émulé(s) de façon à ce que les données écrites soient stockées dans un espace de stockage différent du support de données contenant les données du ou des disque(s) dur(s) émulé(s). 42. Procédé selon la revendication 21, caractérisé en ce que les requêtes d'écritures de données émises par le système d'exploitation des postes clients vers le(s) disque(s) dur(s) émulé(s) sont traitées de façon à ce que les données écrites soient stockées dans la mémoire vive du poste serveur. 2867869 -28- 43. Procédé selon la revendication 21, caractérisé en ce que les requêtes d'écritures de données émises par le système d'exploitation des postes clients vers le(s) disque(s) dur(s) émulé(s) sont traitées de façon à ce que les données écrites soient stockées dans la mémoire virtuelle du poste serveur. 44. Procédé selon la revendication 21, caractérisé en ce que les requêtes d'écriture de données émises par le système d'exploitation des postes clients vers le(s) disque(s) dur(s) émulé(s) sont traitées de façon à ce que les données écrites soient stockées dans un fichier de données, accessible au logiciel serveur. 45. Procédé selon la revendication 21, caractérisé en ce que l'espace de stockage utilisé pour le stockage des écritures peut être volatil, c'est à dire être vidé des données qui y sont stockées à chaque nouvelle session d'exécution du système d'exploitation d'un poste client, ou bien non volatil de façon à permettre la persistance des données écrites d'une session d'exécution du système d'exploitation d'un poste client à une autre. 46. Procédé selon les revendications 16 et 21, caractérisé en ce que le caractère volatil des redirections d'écriture est déterminé à l'initialisation de la session d'exécution du système d'exploitation d'un poste client.