FR3012900A1 - Procede de protection de metadonnees - Google Patents

Procede de protection de metadonnees Download PDF

Info

Publication number
FR3012900A1
FR3012900A1 FR1360876A FR1360876A FR3012900A1 FR 3012900 A1 FR3012900 A1 FR 3012900A1 FR 1360876 A FR1360876 A FR 1360876A FR 1360876 A FR1360876 A FR 1360876A FR 3012900 A1 FR3012900 A1 FR 3012900A1
Authority
FR
France
Prior art keywords
metadata
server
client
file
data
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
FR1360876A
Other languages
English (en)
Other versions
FR3012900B1 (fr
Inventor
Liana Bozga
Sebastien Buisson
Jean-Olivier Gerphagnon
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Bull SAS
Original Assignee
Bull SAS
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Bull SAS filed Critical Bull SAS
Priority to FR1360876A priority Critical patent/FR3012900B1/fr
Priority to PCT/FR2014/052818 priority patent/WO2015067892A1/fr
Publication of FR3012900A1 publication Critical patent/FR3012900A1/fr
Application granted granted Critical
Publication of FR3012900B1 publication Critical patent/FR3012900B1/fr
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1097—Protocols in which an application is distributed across nodes in the network for distributed storage of data in networks, e.g. transport arrangements for network file system [NFS], storage area networks [SAN] or network attached storage [NAS]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
    • G06F11/2038—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant with a single idle spare processing component
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
    • G06F11/2048—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant where the redundant components share neither address space nor persistent storage
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10—File systems; File servers
    • G06F16/16—File or folder operations, e.g. details of user interfaces specifically adapted to file systems
    • G06F16/164—File meta data generation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1095—Replication or mirroring of data, e.g. scheduling or transport for data synchronisation between network nodes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/40—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass for recovering from a failure of a protocol instance or entity, e.g. service redundancy protocols, protocol state redundancy or protocol service redirection

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Quality & Reliability (AREA)
  • Computer Security & Cryptography (AREA)
  • Databases & Information Systems (AREA)
  • Data Mining & Analysis (AREA)
  • Human Computer Interaction (AREA)
  • Storage Device Security (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

L'invention concerne un procédé de protection de métadonnées (MD_f), les métadonnées décrivant un fichier (f) dans un système de stockage et étant enregistrées sur un serveur principal (S_MD1) et sur un serveur secondaire (S_MD2), le procédé comportant les étapes suivantes : - un client (C) obtient un identifiant du serveur principal (S_MD1) ; - le client (C) émet une requête vers le serveur principal (S_MD1) afin d'obtenir les métadonnées (MD_f), la requête comprenant un identifiant du fichier (f) ; - le serveur principal (S_MD1) émet une réponse vers le client (C), la réponse comportant les métadonnées (MD_f) ; - le client (C) émet un message (13) vers le serveur principal (S_MD1) pour la mise à jour des métadonnées sur le serveur principal, et le client (C) émet un message (14) vers le serveur secondaire (S_MD2) pour la mise à jour des métadonnées sur le serveur secondaire, le client ayant préalablement obtenu un identifiant du serveur secondaire.

Description

PROCEDE DE PROTECTION DE METADONNEES DOMAINE TECHNIQUE DE L'INVENTION Le domaine technique de l'invention est celui des procédés de protection de métadonnées. ARRIERE-PLAN TECHNOLOGIQUE DE L'INVENTION Dans un domaine de stockage, les données sont globalement divisées en deux 10 sous-ensembles : - les données en tant que telles, « réelles », par exemple le contenu binaire d'un fichier comme une image ou un texte. Ces données sont également appelées « data » dans le présent document ; - les métadonnées, qui définissent un certain nombre de caractéristiques 15 relatives aux données « data » du fichier, comme par exemple : o la date de création du fichier, o la date de dernière modification du fichier, o le nom « visuel » du fichier, o les droits - c'est-à-dire qui peut lire, écrire, modifier le fichier, 20 o ainsi que, à un niveau plus fin, l'endroit où le fichier se trouve physiquement sur un support de stockage, tel qu'un disque dur ou un serveur. Les métadonnées sont également appelées « metadata » dans le présent document. 25 La corruption des données au sens large est un problème connu. Pour s'en prémunir, l'état de l'art propose généralement l'utilisation d'une technique RAID (de l'anglais « Redundant Array of Independant Disks ») qui, en répartissant les données sur plusieurs espaces de stockage, permet d'en garantir l'intégrité par 30 rapport à un problème matériel. Cependant, ce type de technique ne couvre pas les risques de corruption, volontaire ou involontaire, liés par exemple à une attaque informatique. La modification des données et la détection de modification non désirées sont un sujet complexe. Concernant l'aspect « data », une première solution réellement plausible est de prendre une référence, c'est-à-dire réaliser une opération mathématique de type « somme » permettant d'identifier un contenu de manière non-répudiable. Des algorithmes de hashage cryptographique comme MD5 (« Message Digest 5 ») ou SHA (« Secure Hash Algorithm ») permettent de calculer à un instant TO, à partir d'une donnée initiale fournie en entrée, une somme servant à identifier rapidement la donnée initiale. On peut ainsi typiquement vérifier, à un instant T1>TO, si la somme est toujours similaire et donc si la donnée est toujours intègre. Une deuxième solution, complémentaire de la première, est la sauvegarde de manière régulière des données sur différents supports pour archivage.
Ces deux éléments de solution restent valables pour les « metadata ». La problématique est cependant différente, surtout dans le cadre d'un système de fichiers réparti/distribué, comme on peut en trouver dans un contexte de calcul haute performance. Dans un tel environnement, un ensemble de serveurs est chargé de fournir l'accès aux « data » : les serveurs E/S. Un ensemble d'autres serveurs est chargé de fournir les informations de type « metadata » : les serveurs de métadonnées. Une corruption physique, telle qu'un disque en panne, peut être gérée via des mécanismes de type RAID ou plus généralement via une redondance physique.
Cependant, si l'information stockée, « écrite », est remplacée par une valeur invalide, un système de redondance se contentera de « recopier » la valeur invalide, porteuse d'une mauvaise information. Ces systèmes s'avèrent donc notamment inutiles face à une attaque sur des métadonnées. En l'absence d'une attaque, les métadonnées - tout comme les données d'une manière générale - sont également susceptibles de subir une corruption silencieuse (« silent data corruption »), c'est-à-dire une corruption indétectée. Une telle corruption peut par exemple être liée à une erreur lors d'un processus d'écriture sur un disque de stockage. Dans le cas où l'information de métadonnée d'un fichier est corrompue, par exemple si l'information de taille ou de localisation physique dudit fichier est erronée, l'accès audit fichier peut être irrémédiablement perdu. En effet, sans les métadonnées, il est impossible pour les clients d'un système de fichiers réparti d'accéder aux données elles-mêmes. Les figures la à ld illustrent un procédé 100 d'accès à un système de fichiers distribué selon l'art antérieur. Le système de fichiers distribué comporte dans l'exemple représenté aux figures laàld: - un serveur de métadonnées S _MD et une baie de stockage B_MD du serveur de métadonnées S_MD ; - un premier serveur de données S_D1 et une première baie de stockage B _D1 du premier serveur de données S_D1 ; - un deuxième serveur de données S_D2 et une deuxième baie de stockage B _D2 du deuxième serveur de données S_D2 ; - un dispositif client C, le dispositif client C pouvant communiquer avec le serveur de métadonnées S _MD et les premier et deuxième serveurs de données S_D1 et S_D2 grâce à un réseau NWK.
Les figures la à ld montrent également un fichier f du système de fichiers distribué, le fichier f comportant : - des données, une première partie Df_l desdites données étant stockée sur la première baie de stockage B_D1 et une deuxième partie Df_2 desdites données étant stockée sur la deuxième baie de stockage B_D2 ; - des métadonnées MD_f stockées sur la baie de stockage B_MD du serveur de métadonnées S_MD. La figure 1 a montre une étape, dans le procédé 100, d'obtention des métadonnées MD_f du fichier f par le client C. Un utilisateur réalise par exemple une instruction de type : fd = open(MonFichier) ; « MonFichier » étant le nom du fichier f. Suite à cette instruction de l'utilisateur, le client C envoie un premier message 1 au serveur de métadonnées S_MD via le réseau NWK afin d'obtenir les métadonnées MD_f du fichier f, qui comportent notamment l'emplacement de stockage des 5 données du fichier f. Le serveur de métadonnées S MD envoie un deuxième _ message 2 au client C avec les métadonnées MD_f du fichier f dont l'emplacement de stockage des données du fichier f. En l'occurrence, l'emplacement de stockage des données du fichier f est le suivant : la première partie Df_l des données est stockée sur la première baie de stockage B_D1 du 10 premier serveur de données S_D1, et la deuxième partie Df_2 des données est stockée sur la deuxième baie de stockage B_D2 du deuxième serveur de données S D2. La figure 1 b montre une étape, dans le procédé 100, d'accès aux données du 15 fichier f. Le client C envoie, après réception du deuxième message 2 : - un troisième message 3 au premier serveur de données S_D1 via le réseau NWK pour l'accès à la première partie Df_l des données. Le premier serveur de données S_D1 va alors chercher la première partie Df_l des données sur la première baie de stockage B_D1 et transmet ladite première 20 partie Df _1 des données au client C ; - un quatrième message 4 au deuxième serveur de données S_D2 pour l'accès à la deuxième partie Df_2 des données. Le deuxième serveur de données S_D2 va alors chercher la deuxième partie Df_2 des données sur la deuxième baie de stockage B_D2 et transmet ladite deuxième partie 25 Df 2 des données au client C. _ Les données et les métadonnées du fichier f se trouvent désormais sur le client C, qui peut accéder effectivement aux données du fichier f et réaliser des opérations qui modifient le fichier f. Ces opérations peuvent modifier : - uniquement les métadonnées MDJ, par exemple dans le cas d'un accès 30 de type open(), où la date de dernier accès au fichier est mise à jour dans les métadonnées MDJ, ou - les données et les métadonnées MDJ, par exemple dans le cas d'un ajout de données. La figure 1c montre une étape, dans le procédé 100, de modification du fichier f par l'utilisateur du client C et de mise à jour des données du fichier f. L'utilisateur réalise par exemple les instructions suivantes : f cl = open(MonFichier); read(f cl, data, size); write (f cl, data, size); close(f cl); chmod(MonFichier, mode); Dans l'exemple considéré, le client C accède donc au fichier f, lit le fichier f, écrit dans le fichier f et ajoute donc des données supplémentaires dans le fichier f, ferme le fichier f et change les droits du fichier f. On se place dans le cas où l'opération d'écriture entraîne la création d'une troisième partie Df_3 des données du fichier f. Le client C envoie alors un cinquième message 5 au serveur de métadonnées S_MD via le réseau NWK afin de savoir où ajouter la troisième partie Df_3 des données du fichier f : le client C demande une allocation d'espace au serveur de métadonnées S_MD. Le serveur de métadonnées S_MD répond par un sixième message 6 au client C via le serveur NWK et indique par exemple au client C d'ajouter la troisième partie Df_3 des données du fichier f sur un troisième serveur de données S_D3. Le troisième serveur de données S_D3 est associé à une troisième baie de stockage B_D3. Le client C envoie alors un septième message 7 au troisième serveur de données S_D3 via le réseau NWK pour l'écriture de la troisième partie Df_3 des données du fichier f sur la troisième baie de stockage B_D3. Suite à cette mise à jour des données du fichier f, le système de fichiers distribué procède à la mise à jour des métadonnées MD_f du fichier f. La figure 1d montre une étape, dans le procédé 100, de mise à jour des métadonnées MD_f du fichier f. Le client C envoie un huitième message 8 au serveur de métadonnées S_MD via le réseau NWK pour la mise à jour des métadonnées MD _f afin de prendre en compte l'ajout de données, la nouvelle taille du fichier f, la localisation de chaque partie des données, les nouvelles permissions, l'heure de modification, l'heure d'accès, etc.
Ainsi, dans le procédé 100 d'accès au système de fichiers distribué selon l'art antérieur, si le serveur de métadonnées S_MD est corrompu, les métadonnées MD_f permettant d'accéder aux données du fichier f ne seront plus valides et l'accès au fichier f sera invalide, c'est-à-dire qu'on accèdera par exemple aux données d'un autre fichier que le fichier f, ou impossible, c'est-à-dire qu'on n'accèdera à aucune donnée. EXPOSE DE L'INVENTION L'invention offre une solution aux problèmes évoqués précédemment, en proposant un procédé de protection de métadonnées contre une corruption silencieuse ou contre une attaque malveillante. L'invention concerne donc essentiellement un procédé de protection de métadonnées, lesdites métadonnées décrivant un fichier dans un système de stockage et étant enregistrées sur un serveur principal, le procédé de protection étant caractérisé en ce que lesdites métadonnées sont enregistrées sur un serveur secondaire et en ce que le procédé comporte les étapes suivantes : - un client obtient un identifiant du serveur principal ; - le client émet une requête vers le serveur principal afin d'obtenir les métadonnées décrivant le fichier, la requête comprenant un identifiant du fichier ; - le serveur principal émet une réponse vers le client, la réponse comportant les métadonnées décrivant le fichier ; - le client émet un message vers le serveur principal pour la mise à jour des métadonnées sur le serveur principal, et le client émet un message vers le serveur secondaire pour la mise à jour des métadonnées sur le serveur secondaire, le client ayant préalablement obtenu un identifiant du serveur secondaire.
Grâce à l'invention, on assure, dans un système de stockage, une duplication sur un serveur principal et sur au moins un serveur secondaire des métadonnées de chaque fichier stocké dans le système de stockage. C'est le client, et non pas le serveur principal, qui envoie un message vers le serveur secondaire pour la mise à jour des métadonnées sur le serveur secondaire. Le procédé selon l'invention permet ainsi de s'affranchir d'une éventuelle défaillance ou corruption du serveur principal ou du serveur secondaire, en considérant que le client est fiable.
Outre les caractéristiques qui viennent d'être évoquées dans le paragraphe précédent, le procédé de protection de métadonnées selon l'invention peut présenter une ou plusieurs caractéristiques complémentaires parmi les suivantes, considérées individuellement ou selon toutes les combinaisons techniquement possibles : - Dans un premier mode de fonctionnement, le client obtient l'identifiant du serveur secondaire en même temps qu'il obtient l'identifiant du serveur principal. - Dans un deuxième mode de fonctionnement, la réponse émise par le serveur principal vers le client comporte : - les métadonnées décrivant le fichier, et - une liste comprenant l'identifiant du serveur secondaire. Le client obtient donc, dans ce deuxième mode de fonctionnement, l'identifiant du serveur secondaire après avoir interrogé le serveur principal. - Dans le deuxième mode de fonctionnement, la liste est avantageusement protégée par une technique de cryptage, l'accès à ladite liste nécessitant une clé de décryptage. Ainsi, on améliore la robustesse du dispositif de protection de métadonnées en sécurisant l'accès à l'identifiant du serveur secondaire, par exemple dans le cas où la réponse émise par le serveur principal vers le client est interceptée par un dispositif malveillant. - La clé de décryptage est avantageusement inconnue du serveur principal. Ainsi, on contribue à améliorer la robustesse du dispositif de protection de métadonnées en sécurisant l'accès à l'identifiant du serveur secondaire dans le cas où le serveur principal est corrompu. La clé de décryptage est avantageusement connue uniquement du client, le client étant réputé fiable. - Dans le premier ou dans le deuxième mode de fonctionnement, le client procède à la mise à jour des métadonnées sur le serveur principal et sur le serveur secondaire suivant un ordre de mise à jour prédéfini. - La mise à jour des métadonnées du fichier par le client est avantageusement validée lorsque tous les serveurs sont mis à jour. Ainsi, on maximise la sécurité et la protection des métadonnées. - Alternativement, la mise à jour des métadonnées du fichier par le client est avantageusement validée lorsqu'au moins un serveur est mis à jour. Ainsi, on améliore la rapidité d'exécution du procédé de protection de métadonnées du point de vue du client. - L'invention concerne également un procédé dans lequel les métadonnées sont enregistrées sur une pluralité de serveurs secondaires et comportant les étapes suivantes : - un client obtient un identifiant du serveur principal ; - le client émet une requête vers le serveur principal afin d'obtenir les métadonnées décrivant le fichier, la requête comprenant un identifiant du fichier ; - le serveur principal émet une réponse vers le client, la réponse comportant les métadonnées décrivant le fichier ; - le client émet un message vers le serveur principal pour la mise à jour des métadonnées sur le serveur principal, et le client émet un message vers chaque serveur secondaire de la pluralité de serveurs secondaires pour la mise à jour des métadonnées sur la pluralité de serveurs secondaires, le client ayant préalablement obtenu un identifiant de chaque serveur secondaire de la pluralité de serveurs secondaires.
L'invention et ses différentes applications seront mieux comprises à la lecture de la description qui suit et à l'examen des figures qui l'accompagnent.
BREVE DESCRIPTION DES FIGURES Les figures sont présentées à titre indicatif et nullement limitatif de l'invention. - La figure 1 a montre une étape d'obtention des métadonnées d'un fichier dans un procédé d'accès à un système de fichiers distribué de l'art antérieur. - La figure 1 b montre une étape d'accès aux données du fichier dans le procédé de la figure 1 a. - La figure 1 c montre une étape de modification du fichier et de mise à jour des données du fichier f dans le procédé de la figure 1 a. - La figure ld montre une étape de mise à jour des métadonnées du fichier dans le procédé de la figure 1 a. - La figure 2a montre une deuxième étape d'un procédé de protection de métadonnées selon un mode de réalisation de l'invention. - La figure 2b montre une troisième étape du procédé de protection de métadonnées de la figure 2a. - La figure 2c montre une quatrième étape du procédé de protection de métadonnées de la figure 2a. - La figure 3 est un diagramme de l'organisation des étapes du procédé de protection de métadonnées de la figure 2a.
DESCRIPTION DETAILLEE D'AU MOINS UN MODE DE REALISATION DE L'INVENTION Sauf précision contraire, un même élément apparaissant sur des figures différentes présente une référence unique.
Le procédé 200 de protection de métadonnées est mis en oeuvre dans une infrastructure de système de fichiers distribué représentée aux figures 2a à 2c et comportant les éléments suivants : - un serveur principal de métadonnées S_MD1 et une baie de stockage principale B_MD1 du serveur principal de métadonnées S_MD1 ; - un serveur secondaire de métadonnées S_MD2 et une baie de stockage secondaire B_MD2 du serveur secondaire de métadonnées S_MD2 ; - un premier serveur de données S_D1 et une première baie de stockage B _D1 du premier serveur de données S_D1 ; - un deuxième serveur de données S_D2 et une deuxième baie de stockage B_D2 du deuxième serveur de données S_D2 ; - un troisième serveur de données S _D3 et une troisième baie de stockage B_D3 du troisième serveur de données S_D3 ; - un dispositif client C pouvant communiquer avec le serveur principal de métadonnées S_MD1, le serveur secondaire de métadonnées S_MD2 et les premier, deuxième et troisième serveurs de données S_D1, S_D2 et S _D3 grâce à un réseau NWK. Les figures 2a à 2c montrent également un fichier f du système de fichiers distribué, le fichier f comportant : - des données, une première partie Df_1 desdites données étant stockée sur la première baie de stockage B_D1, une deuxième partie Df_2 desdites données étant stockée sur la deuxième baie de stockage B_D2 et une troisième partie Df_3 desdites données étant stockée sur la troisième baie de stockage B_D3 ; - des métadonnées MD_f stockées sur la baie de stockage principale B_MD1 du serveur principal de métadonnées S_MD1 et sur la baie de stockage secondaire B_MD2 du serveur secondaire de métadonnées S_MD2. Les métadonnées MD _f du fichier f sont ainsi dupliquées en deux endroits différents du système de fichiers distribué, sur la baie de stockage principale B_MD1 contrôlée par le serveur principal de métadonnées S_MD1 et sur la baie de stockage secondaire B_MD2 contrôlée par le serveur secondaire de métadonnées S_MD2. 3012 900 11 Le procédé 200 de protection de métadonnées intervient notamment lors de la mise à jour des métadonnées MD_f du fichier f, consécutive à une modification desdites métadonnées MD J. Une telle modification des métadonnées MDJ du 5 fichier f survient typiquement lorsque le client C accède au fichier f, par exemple suite à une instruction de l'utilisateur de type : f cl = open(MonFichier); « MonFichier » étant le nom du fichier f. 10 Lors d'une première étape 201 d'initialisation du procédé 200 de protection de métadonnées, le client C obtient, par exemple grâce à un fichier de configuration locale ou via un mécanisme similaire au protocole DHCP ou l'utilisation d'options spécifiques du protocole DHCP, l'adresse du serveur principal de métadonnées S_MD1 ainsi que, dans un premier mode de fonctionnement, l'adresse du serveur 15 secondaire de métadonnées S_MD2. La première étape 201 est représentée à la figure 3. La figure 2a montre une deuxième étape 202 du procédé 200 de protection de métadonnées. Selon cette deuxième étape 202, le client C émet une première 20 requête 11 vers le serveur principal de métadonnées S_MD1 par l'intermédiaire du réseau NWK afin d'obtenir les métadonnées MD_f du fichier f. La première requête 11 comprend pour ce faire un identifiant du fichier f. La figure 2b montre une troisième étape 203 du procédé 200 de protection de 25 métadonnées. Selon cette troisième étape 203, le serveur principal de métadonnées S_MD1 émet une réponse 12 vers le client C par l'intermédiaire du réseau NWK, la réponse 12 comportant les métadonnées MD_f du fichier f. Une fois les métadonnées MD_f du fichier f obtenues, le client C peut effectivement accéder au fichier f et, en fonction des instructions d'un utilisateur du 30 client C, réaliser une pluralité d'opérations sur le fichier f, comme par exemple lire le fichier f et/ou écrire dans le fichier f, puis fermer le fichier f et éventuellement changer les droits d'accès du fichier f. 3012 900 12 Lorsque le client C a terminé de réaliser cette pluralité d'opérations sur le fichier f, le client C procède à la mise à jour des données du fichier f et à la mise à jour des métadonnées du fichier f. Lors de la mise à jour des données du fichier f, une ou plusieurs parties Df_1 à Df_3 des données du fichier f peuvent être modifiées ou 5 supprimées, et de nouvelles parties des données du fichier f peuvent être ajoutées. Le client C demande une allocation d'espace au serveur principal de métadonnées S_MD1 afin de savoir où et comment stocker les données mises à jour du fichier f, c'est-à-dire comment découper les données mises à jour en plusieurs parties, et vers quel serveur de données envoyer chaque partie. Dans 10 l'exemple représenté à la figure 2b, on considère un cas où, à l'issue de la mise à jour des données du fichier f, on a toujours les première, deuxième et troisième parties Df_1, Df_2 et Df_3 des données respectivement stockées par les premier, deuxième et troisième serveurs de données S D1, S D2 et S D3. Ce cas _ S_D2 _ correspond par exemple à un accès au fichier f de type open(). Une fois les 15 données du fichier f mises à jour, le client C procède à la mise à jour des métadonnées MDJ du fichier f. La figure 2c montre une quatrième étape 204 du procédé 200 de protection de métadonnées. Selon cette quatrième étape 204, le client C émet un message 13 20 vers le serveur principal de métadonnées S_MD1 via le réseau NWK pour la mise à jour des métadonnées MD_f sur le serveur principal S_MD1, et le client C émet un message 14 vers le serveur secondaire de métadonnées S_MD2 pour la mise à jour des métadonnées MD_f sur le serveur secondaire de métadonnées S_MD2. Le serveur secondaire de métadonnées S_MD2 est préférentiellement intégré à 25 bas niveau via un protocole d'accès et de modification des métadonnées afin de diminuer le risque d'une attaque sur ledit serveur secondaire de métadonnées S_MD2. Grâce au procédé 200 de protection de métadonnées de l'invention, si le serveur principal de métadonnées S_MD1 subit une attaque et/ou une corruption de ses informations, le serveur secondaire de métadonnées S_MD2 pourra 30 prendre le relai, avec des informations valides.
On a précédemment décrit le premier mode de fonctionnement selon lequel le client C obtient l'identifiant du serveur secondaire de métadonnées S_MD2 simultanément à l'identifiant du serveur principal de métadonnées S_MD1 lors de la première étape 201, par exemple dans une phase d'initialisation du client C.
Selon un deuxième mode de fonctionnement, le client C peut obtenir uniquement l'identifiant du serveur principal de métadonnées S_MD1 lors de la première étape 201, et obtenir l'identifiant du serveur secondaire de métadonnées S_MD2 lors de la troisième étape 203. Dans ce deuxième mode de fonctionnement, la réponse 12 comporte, outre les métadonnées MD_f du fichier f, une liste comprenant un identifiant du serveur secondaire de métadonnées S_MD2. Le client C obtient donc l'identifiant du serveur secondaire de métadonnées S_MD2 après avoir interrogé le serveur principal de métadonnées S_MD1, dont il connaissait l'identifiant à l'issue de la première étape 201. Le deuxième mode de fonctionnement permet avantageusement que l'identifiant du serveur secondaire de métadonnées S_MD2 ne soit transmise au client C que lorsque le client C accède à des métadonnées. On a décrit en lien avec les figures 2a à 2c un mode de réalisation du procédé 200 de protection de métadonnées mettant en oeuvre un seul serveur secondaire de métadonnées. Néanmoins, le procédé 200 de protection de métadonnées pourrait tout à fait, dans un deuxième mode de réalisation, mettre en oeuvre une pluralité de serveurs secondaires de métadonnées. Les premier et deuxième modes de fonctionnement précédemment décrits sont compatibles avec le deuxième mode de réalisation. Ainsi, le client C peut obtenir l'identifiant de chaque serveur de la pluralité de serveurs secondaires de métadonnées : - soit, dans le premier mode de fonctionnement, lors de la première étape 201 durant laquelle le client C obtient également l'identifiant du serveur principal de métadonnées S_MD1, - soit, dans le deuxième mode de fonctionnement, lors de la troisième étape 203, après avoir interrogé le serveur principal de métadonnées S_MD1 à la deuxième étape 202. La liste de la réponse 12 envoyée par le serveur principal de métadonnées S_MD1 vers le client C à l'étape 203 comporte alors l'identifiant de chaque serveur de la pluralité de serveurs secondaires de métadonnées.5

Claims (9)

  1. REVENDICATIONS1. Procédé (200) de protection de métadonnées (MDJ), lesdites métadonnées (MD_f) décrivant un fichier (f) dans un système de stockage et étant enregistrées sur un serveur principal (S_MD1), le procédé de protection (200) étant caractérisé en ce que lesdites métadonnées (MD_f) sont enregistrées sur un serveur secondaire (S_MD2) et en ce que le procédé (200) comporte les étapes suivantes : - un client (C) obtient un identifiant du serveur principal (S_MD1) ; - le client (C) émet une requête (11) vers le serveur principal (S_MD1) afin d'obtenir les métadonnées (MD_f) décrivant le fichier (f), la requête (11) comprenant un identifiant du fichier (f) ; - le serveur principal (S_MD1) émet une réponse (12) vers le client (C), la réponse (12) comportant les métadonnées (MD_f) décrivant le fichier (f) ; - le client (C) émet un message (13) vers le serveur principal (S_MD1) pour la mise à jour des métadonnées (MD_f) sur le serveur principal (S_MD1), et le client (C) émet un message (14) vers le serveur secondaire (S_MD2) pour la mise à jour des métadonnées (MD_f) sur le serveur secondaire (S_MD2), le client (C) ayant préalablement obtenu un identifiant du serveur secondaire (S_MD2).
  2. 2. Procédé (200) selon la revendication précédente caractérisé en ce que le client (C) obtient l'identifiant du serveur secondaire (S_MD2) en même temps qu'il obtient l'identifiant du serveur principal (S_MD1).
  3. 3. Procédé (200) selon la revendication 1 caractérisé en ce que la réponse (12) émise par le serveur principal (S_MD1) vers le client (C) comporte : - les métadonnées (MD_f) décrivant le fichier (f), et - une liste comprenant l'identifiant du serveur secondaire (S_MD2).
  4. 4. Procédé (200) selon la revendication précédente caractérisé en ce que la liste est protégée par une technique de cryptage, l'accès à ladite liste nécessitant une clé de décryptage.
  5. 5. Procédé (200) selon la revendication précédente caractérisé en ce que la clé de décryptage est inconnue du serveur principal.
  6. 6. Procédé (200) selon l'une quelconque des revendications précédentes caractérisé en ce que le client (C) procède à la mise à jour des métadonnées (MD_f) sur le serveur principal (S_MD1) et sur le serveur secondaire (S_MD2) suivant un ordre de mise à jour prédéfini.
  7. 7. Procédé (200) selon l'une quelconque des revendications précédentes caractérisé en ce que la mise à jour des métadonnées (MD_f) du fichier (f) par le client (C) est validée lorsque tous les serveurs (S_MD1, S_MD2) sont mis à jour.
  8. 8. Procédé (200) selon l'une quelconque des revendications 1 à 6 caractérisé en ce que la mise à jour des métadonnées (MD_f) du fichier (f) par le client (C) est validée lorsqu'au moins un serveur (S_MD1, S_MD2) est mis à jour.
  9. 9. Procédé (200) selon l'une quelconque des revendications précédentes caractérisé en ce que les métadonnées (MD_f) sont enregistrées sur une pluralité de serveurs secondaires et en ce que le procédé (200) comporte les étapes suivantes : - un client (C) obtient un identifiant du serveur principal (S_MD1) ; - le client (C) émet une requête (11) vers le serveur principal (S_MD1) afin d'obtenir les métadonnées (MD_f) décrivant le fichier (f), la requête (11) comprenant un identifiant du fichier (f) ; - le serveur principal (S_MD1) émet une réponse (12) vers le client (C), la réponse (12) comportant les métadonnées (MD_f) décrivant le fichier (f) ; - le client (C) émet un message (13) vers le serveur principal (S_MD1) pour la mise à jour des métadonnées (MD_f) sur le serveur principal (S_MD1), et le client (C) émet un message vers chaque serveur secondaire de la pluralité de serveurs secondaires pour la mise à jour des métadonnées (MD_f) sur la pluralité de serveurs secondaires, le client (C) ayant préalablement obtenu un identifiant de chaque serveur secondaire de lapluralité de serveurs secondaires.
FR1360876A 2013-11-06 2013-11-06 Procede de protection de metadonnees Active FR3012900B1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
FR1360876A FR3012900B1 (fr) 2013-11-06 2013-11-06 Procede de protection de metadonnees
PCT/FR2014/052818 WO2015067892A1 (fr) 2013-11-06 2014-11-05 Procédé de protection de métadonnées

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
FR1360876A FR3012900B1 (fr) 2013-11-06 2013-11-06 Procede de protection de metadonnees

Publications (2)

Publication Number Publication Date
FR3012900A1 true FR3012900A1 (fr) 2015-05-08
FR3012900B1 FR3012900B1 (fr) 2015-10-30

Family

ID=50478518

Family Applications (1)

Application Number Title Priority Date Filing Date
FR1360876A Active FR3012900B1 (fr) 2013-11-06 2013-11-06 Procede de protection de metadonnees

Country Status (2)

Country Link
FR (1) FR3012900B1 (fr)
WO (1) WO2015067892A1 (fr)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112306421B (zh) * 2020-11-20 2021-04-30 昆易电子科技(上海)有限公司 一种用于存储分析测量数据格式mdf文件的方法和系统

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
"Clustered Metadata Design", 15 June 2009 (2009-06-15), XP055131549, Retrieved from the Internet <URL:http://wiki.lustre.org/images/d/db/HPCS_CMD_06_15_09.pdf> [retrieved on 20140724] *
ANONYMOUS: "Clustered Metadata", 30 September 2010 (2010-09-30), XP055131550, Retrieved from the Internet <URL:http://wiki.lustre.org/index.php/Clustered_Metadata> [retrieved on 20140724] *
JUNHO JANG ET AL: "A Content-Based Load Balancing Algorithm for Metadata Servers in Cluster File Systems", 5 November 2005, PARALLEL AND DISTRIBUTED PROCESSING AND APPLICATIONS LECTURE NOTES IN COMPUTER SCIENCE;;LNCS, SPRINGER, BERLIN, DE, PAGE(S) 49 - 57, ISBN: 978-3-540-29769-7, XP019023302 *
VILOBH MESHRAM ET AL: "Can a Decentralized Metadata Service Layer Benefit Parallel Filesystems?", CLUSTER COMPUTING (CLUSTER), 2011 IEEE INTERNATIONAL CONFERENCE ON, IEEE, 26 September 2011 (2011-09-26), pages 484 - 493, XP032066066, ISBN: 978-1-4577-1355-2, DOI: 10.1109/CLUSTER.2011.85 *

Also Published As

Publication number Publication date
WO2015067892A1 (fr) 2015-05-14
FR3012900B1 (fr) 2015-10-30

Similar Documents

Publication Publication Date Title
US12038878B2 (en) Methods and apparatus for controlling snapshot exports
US8843637B2 (en) Managed peer-to-peer content backup service system and method using dynamic content dispersal to plural storage nodes
US11636217B2 (en) Systems and methods for breach-proof, resilient, compliant data in a multi-vendor cloud environment and automatically self heals in the event of a ransomware attack
TWI387284B (zh) 用於以積點為基礎之對等式儲存之方法、系統、及記錄相關指令的電腦儲存媒體
EP3776208A1 (fr) Autocorrection d&#39;exécution pour registres de chaîne de blocs
US8930423B1 (en) Method and system for restoring encrypted files from a virtual machine image
US10693839B2 (en) Digital media content distribution blocking
Ali et al. Blockstack: A new decentralized internet
JP2009527824A (ja) 固定コンテンツ分散データ・ストレージにおける平均データ・ロス時間改善方法
Wani et al. File system anti-forensics–types, techniques and tools
US20110314245A1 (en) Secure media system
US10223545B1 (en) System and method for creating security slices with storage system resources and related operations relevant in software defined/as-a-service models, on a purpose built backup appliance (PBBA)/protection storage appliance natively
Ali et al. Blockstack technical whitepaper
US20060282631A1 (en) Discovering data storage for backup
EP4026016A1 (fr) Migration d&#39;une chaîne de blocs de données
FR3012900A1 (fr) Procede de protection de metadonnees
FR2932289A1 (fr) Procede et systeme de synchronisation de modules logiciels d&#39;un systeme informatique distribue en grappe de serveurs, application au stockage de donnees.
EP3970348B1 (fr) Procédé de sauvegarde de données dans un réseau pair-à-pair
US20210271554A1 (en) Method and system for a cloud backup service leveraging peer-to-peer data recovery
EP3543890B1 (fr) Procédés et système de gestion de données permettant un contrôle temporel des données
EP2531921B1 (fr) Gestion du lieu de stockage de donnees dans un systeme de stockage distribue
US11755503B2 (en) Persisting directory onto remote storage nodes and smart downloader/uploader based on speed of peers
US9064132B1 (en) Method for writing hardware encrypted backups on a per set basis
FR3100350A1 (fr) migration d’une chaîne de blocs de données
FR3100351A1 (fr) connexion à chaîne de blocs de données

Legal Events

Date Code Title Description
PLFP Fee payment

Year of fee payment: 3

PLFP Fee payment

Year of fee payment: 4

PLFP Fee payment

Year of fee payment: 5

PLFP Fee payment

Year of fee payment: 7

PLFP Fee payment

Year of fee payment: 8

PLFP Fee payment

Year of fee payment: 9

PLFP Fee payment

Year of fee payment: 10

PLFP Fee payment

Year of fee payment: 11