[go: up one dir, main page]
More Web Proxy on the site http://driver.im/

WO2007134918A1 - Mémoire distribuée - Google Patents

Mémoire distribuée Download PDF

Info

Publication number
WO2007134918A1
WO2007134918A1 PCT/EP2007/053657 EP2007053657W WO2007134918A1 WO 2007134918 A1 WO2007134918 A1 WO 2007134918A1 EP 2007053657 W EP2007053657 W EP 2007053657W WO 2007134918 A1 WO2007134918 A1 WO 2007134918A1
Authority
WO
WIPO (PCT)
Prior art keywords
server
file
distributed storage
storage
distributed
Prior art date
Application number
PCT/EP2007/053657
Other languages
English (en)
Inventor
Samy Khalil Abushanab
Sami Hussain Salem Al-Attas
Muammer Mustafa Alireza
Original Assignee
Noryan Holding Corporation
Piotrowicz, Pawel
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
Priority claimed from US11/439,784 external-priority patent/US8255420B2/en
Priority claimed from EP06114443.2A external-priority patent/EP1860846B1/fr
Application filed by Noryan Holding Corporation, Piotrowicz, Pawel filed Critical Noryan Holding Corporation
Priority to CN2007800184107A priority Critical patent/CN101449559B/zh
Priority to JP2009511432A priority patent/JP5584910B2/ja
Priority to KR1020087028408A priority patent/KR101366220B1/ko
Publication of WO2007134918A1 publication Critical patent/WO2007134918A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • 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]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication

Definitions

  • the present invention relates to a distributed storage system, to a distributed storage management system and to a server for managing access to distributed storage.
  • data files such as digital photographs
  • a storage device such as a magnetic hard disk
  • users increasingly want to be able to access their data remotely and even on-the-move.
  • users may also want to share their data with other users.
  • Distributed storage comprising more than one storage device and which is managed using a virtual file system can offer solutions to these problems.
  • Storage devices can be added to provide additional capacity. Furthermore, to the user, it appears that their data is stored in a single, accessible "location", even though physically the data may be stored disparately across many storage devices, which may even change with time. Also, the user can grant access privileges to other users, such as friends or work colleagues, allowing them to read and even update his or her files. Conventional distributed storage systems using virtual file systems are known.
  • US-A-5873085 describes a system having a plurality of servers, each server managing a respective file system and at least one server operating a virtual file management system.
  • the virtual file management system includes a management table storing a virtual file identifier, a server name and a real file name for each virtual file. If a server receives a request from a client to read or modify a specified file and the server does not hold the file, then the server identifies which other server stores the file, modifies the request to instruct the other server to respond directly to the client and forwards the modified request to the other server.
  • This system suffers the drawback that the servers also store data. This can limit the amount of the storage that can be added to any one server. Adding further servers can provide additional storage, but this is more expensive than simply adding additional storage devices.
  • US-A-20050246393 describes a network storage system having a virtual file system and a storage cluster having a plurality of intelligent storage nodes and a plurality of control nodes (referred to also as “distributed object storage managers") for identifying and accessing an intelligent storage node storing a specified object file.
  • Each distributed object storage manager maintains a lookup table identifying the location of object files stored in intelligent storage nodes and a state table storing information regarding the overall capacity and health of intelligent storage nodes.
  • the state table is used to select an intelligent storage node to store a new object file.
  • a load balancing fabric selects one of the distributed object storage managers based on availability and forwards the request to the selected distributed object storage manager. In turn, the distributed object storage manager selects an intelligent storage node.
  • each distributed object storage manager is responsible for storing new object files. Thus, each distributed object storage manager only stores information about files for which they are responsible, at least initially. Thus, if a distributed object storage manager receives a request to access a given file for which they are not responsible, then they broadcast a request for the file to the intelligent storage nodes. Therefore, the intelligent storage nodes must be provided with sufficient processing capability to handle such requests. This makes it more difficult to add storage nodes.
  • the present invention seeks to provide an improved server for managing access to distributed storage and, thus, an improved distributed storage system.
  • a server for managing access to distributed storage comprising a plurality of storage devices, the server configured to communicate with at least one other server so as to determine which one of the servers selects a portion of distributed storage to be used when storing data.
  • a single server controls storing of data which helps to avoid the problem of concurrent allocation of storage and to permit information about the data to be stored orderly in a single metadata server.
  • the server may comprise a first controller for receiving a request to store data in the distributed storage from a client and a second controller for selecting the portion of the distributed storage to use when storing the data, the second controller configured to communicate with at least one other second controller so as to determine which one of the second controllers selects the portion of distributed storage to be used.
  • the server may be configured, in response to a determination that another server is to select the portion of distributed storage to be used, to receive identity of the portion of the distributed storage from the other server and, in response to a determination that it is to select the portion of distributed storage to be used, to select the portion of distributed storage.
  • the server may be configured to select one of the storage devices within the portion of the distributed storage.
  • the server may further comprise a third controller for selecting one of the storage devices within the portion of distributed storage in response to an instruction from the second controller.
  • the server may be configured, after the file has been stored in the one storage device, to cause the file to be replicated in other storage devices within the portion of the distributed storage.
  • the server may be configured, after the file has been stored, to transmit information relating to the file to a metadata server.
  • the server may be configured to receive a virtual file identifier corresponding to the file from the metadata server and to transmit the virtual file identifier to the client.
  • the server may be configured, in response to a request to read or update a file, to transmit a request for information relating to the file to any one of at least one metadata server.
  • At least one of the storage devices may be provided by a remote storage system, such as a storage access network.
  • a distributed storage management system comprising a plurality of access managing servers and a metadata server for storing information about files stored in the distributed storage.
  • the metadata server may be separate from the access-managing servers.
  • the distributed storage management system may further comprise at least one further metadata server, wherein the access-managing servers are each configured to send information relating to files to the metadata server, but not to the at least one further metadata server.
  • the access-managing servers may each be configured to send requests for information relating to files to any of the at least one further metadata server.
  • a distributed storage system comprising a distributed file management system and distributed storage comprising a plurality of storage device.
  • the storage devices may include plural types of storage device.
  • a method of operating a server for managing access to distributed storage comprising a plurality of storage devices, the method comprising communicating with at least one other server so as to determine which one of the servers selects the portion of distributed storage to be used when storing data.
  • the method may comprise receiving a request to store data in the distributed storage from a client.
  • the method may comprise a first controller receiving the request to store data in the distributed storage and a second controller communicating with at least one other second controller so as to determine which one of the second controllers selects the portion of distributed storage to be used.
  • the method may comprise determining that another server is to select the portion of distributed storage to be used and receiving identity of the portion of the distributed storage to be used from the other server.
  • the method may comprise determining that the server is to select a portion of distributed storage to be used and selecting a portion of the distributed storage to be used.
  • the method may comprise selecting one of the storage devices within the portion of the distributed storage to be used.
  • the method may comprise storing the data in a selected portion of the distributed storage.
  • the method may comprise, after the file has been stored in the one storage device, causing the file to be replicated in other storage devices within the portion of the distributed storage.
  • the method may comprise transmitting information relating to the file to a metadata server after the file has been stored.
  • the method may comprise receiving a virtual file identifier corresponding to the file from the metadata server and transmitting the virtual file identifier to the client.
  • the method may further comprise receiving a request to read or update a file and transmitting a request for information relating to the file to any one of at least one metadata server.
  • a computer program comprising instructions which, when executed by a computer, causes the computer to perform the method.
  • a computer- readable medium storing the computer program.
  • FIG. 1 is schematic diagram of a distributed storage system in accordance with the present invention
  • Figure 2 illustrates a computer system for the servers shown in Figure 1 ;
  • Figure 3 is a block diagram of a server for managing access to distributed storage
  • Figure 4 is a block diagram of the system shown in Figure 1 ;
  • Figures 5a and 5b illustrates a file writing process performed in the system shown in Figure 4;
  • Figure 6 is a process flow diagram of a method of operating an allocation manager
  • Figures 7a and 7b illustrates a file updating process performed in the system shown in Figure 4.
  • Figure 8 illustrates a file reading process performed in the system shown in Figure 4.
  • a distributed storage system 1 in accordance with the present invention is shown.
  • Clients 2, 3, in this example a desktop personal computer 2 and a mobile telephone handset 3, can access the distributed storage system 1 over a communications network 4, such as the Internet.
  • a communications network 4 such as the Internet.
  • the network 4 may include a plurality of wireless and wired networks, including a public land mobile network (not shown) or a wireless local area network (not shown).
  • the distributed storage system 1 includes first, second and third servers 5 l 3 5 2 , 5 3 for managing access to distributed storage (the servers 5 l 3 5 2 , 5 3 are hereinafter referred to as "file service providers").
  • the system 1 may have fewer, e.g. one or two, or a greater number of file service providers.
  • the file service providers 5 l3 5 2 , 5 3 communicate with storage devices 6 locally, such as a first storage device O 1 in the form of a hard disk drive provided by the third file service providers 5 3 , or remotely via the communications network 4 or via another communications network 7, such as an Intranet.
  • a storage area network (SAN) 8 may provide a second storage device 6 2
  • a network attached storage (NAS) 9 may provide a third storage device 6 3
  • a file server 6 3 may provide a fourth storage device 6 4 .
  • the number of storage devices 6 may differ.
  • SAN 8 or NAS 9 can provide more than one storage device and/or more than one SAN or NAS may be provided, each providing at least one storage device 6.
  • Other forms of systems providing storage devices 6 can be used, such as common internet file systems (CIFS) (not shown), optical disk (e.g. DVD) drives and USB drives may be used.
  • CIFS common internet file systems
  • DVD optical disk drives
  • USB drives may be used.
  • the number of storage devices 6 may change with time. For example, storage devices 6 may be added or removed. The arrangement of storage devices 6 may also change.
  • the storage devices 6 collectively provide a single storage volume 26 ( Figure 4) and are arranged into clusters 27 ( Figure 4).
  • the file service providers 5 communicate, via communications network 7, with a first metadata server H 1 and an optional second metadata server H 2 for mapping between a virtual file reference and a real file.
  • the file service providers 5 can read and write metadata to and from the first metadata server H 1 .
  • the file service providers 5 l 3 5 2 , 5 3 can only read metadata from the second metadata server H 2 .
  • the first and second metadata servers H 1 , H 2 are hereinafter referred to as "active" and “passive" metadata servers H 1 , H 2 respectively.
  • the active metadata server H 1 may copy metadata to the passive metadata server H 2 , for example periodically, on demand or in response to predetermined trigger. More than one passive metadata server H 2 may be provided.
  • each metadata server H 1 , H 2 may be distributed between two or more servers.
  • Each computer system 12 includes a processor 13, memory 14 and an input/output (I/O) interface 15 operatively connected by a bus 16.
  • a computer system 12 may include more than one processor.
  • the I/O interface 15 is operatively connected to a network interface 17, storage 18 in the form of a hard disc drive or drives and, optionally, removable storage 19.
  • Other elements, including peripheral devices such as keyboards (not shown) and displays (not shown), may be temporarily or permanently provided.
  • Computer program codes 2O 1 , 2O 2 which, when executed by a computer system 12, causes the computer system 12 to provide file service provider or metadata server processes are stored on the hard drive 18 and loaded into memory 14 for execution by the processor 13.
  • the computer program codes 2O 1 , 2O 2 may be stored on and transferred from removable storage 19 or through network interface 17 from a remote source (not shown).
  • each file service providers 5 includes a first service or controller 21 for interfacing with clients 2, 3, a second service or controller 22 for selecting a storage cluster 27 ( Figure 4), a third service or controller 23 for selecting a storage device 6 within a cluster 27 ( Figure 4), a fourth service or controller 24 for controlling replication of data within and between clusters 27 ( Figure 4) and a fifth service or controller 25 for interfacing with the metadata servers H 1 , H 2 .
  • the first service 21 manages requests to access files, such as to write and read files, received from the clients 2, 3 and also manages other components shown in Figure 3.
  • the first service 21 is herein referred to as a "file service manager".
  • the second service 22 selects a cluster 27 ( Figure 4) when writing data and is herein referred to as an "allocation manager". As will be described in more detail later, the allocation manager 22 communicates with other allocation managers 22.
  • One allocation manager 22 M ( Figure 4), referred to as the "master allocation manager”, is chosen to be responsible for selecting clusters 27 ( Figure 4), with the other allocations manager(s) 22 acting as proxies for the master allocation manager 22 M ( Figure 4).
  • the chosen allocation manager 22 M can change.
  • the third service 23 selects a storage device 6 and validates its availability.
  • the third service 22 is referred to as a "cluster manager".
  • the cluster manager 23 triggers replication of a filestream in one storage device 6 to other storage device(s) 6.
  • the cluster manager 23 also distributes a read process between storage devices 6 to increase throughput.
  • the cluster manager 23 also gathers data relating to client-to-storage device throughput. Throughput data can be used, during a writing or reading process, to select storage devices 6 having faster responses to clients 2, 3.
  • the fourth service 24 is herein referred to as a "replication service”. As explained earlier, the replication service 24 controls replication of data within, and between, clusters 27 ( Figure 4). The cluster manager 23 logs replication transactions in case any of the storage devices 6 are not available.
  • the fifth service 25 is herein referred to as a "metadata server interface".
  • the metadata server interface 25 sends metadata, e.g. information about files, to the active metadata server H 1 and retrieves metadata from the active or passive metadata servers H 1 , H 2 -
  • the storage devices 6 provide a single storage volume or storage space 26.
  • Storage devices 6 are arranged into clusters 27 in which each storage device 6 stores the same data as another storage device 6 in the same cluster 27, i.e. the storage devices 6 in one cluster 27 are mirrors of one another. Only two clusters 27 are illustrated for clarity. In one cluster 27, the storage devices 6 have different access configurations, for example network addresses.
  • Each file service provider 5 can access at least one storage device 6 in each cluster 27.
  • the metadata servers H 1 , H 2 store first, second, third, fourth and fifth metadata tables 28, 29, 30, 31, 32.
  • the metadata includes information for mapping virtual file references onto physical file references and attributes of files before filters (such as file compression and virus checks) are applied.
  • the metadata also includes other information such as folder trees, folder content data and also access control lists for each file and folder.
  • the first table 28 (hereinafter referred to as a "virtual file system entity table”) stores a virtual entity identifier 33, a cluster identifier 34, an entity type 35 for each entity, such as a file or directory, and a path in physical storage identifier 36.
  • the second table 29 (hereinafter referred to as a "virtual file system access control list”) stores a virtual entity identifier 37 and an access list 38 for each entity and defines security privileges of users, i.e. client users.
  • the virtual file system access control list 29 lists users who have access privilege to an entity, together with their set of access privileges in relation to the entity, such as read, write, create, delete and change privileges.
  • Each request to access an entity sent by a client 2, 3 specifies the identity of a user. Therefore, each time a file service provider 5 receives a request to access a given entity, it interrogates the virtual file system access control list 29, for example by retrieving a portion of the list 29 relating to the entity and the user, to verify the user's access privilege.
  • the third table 30 (hereinafter referred to as a "virtual file system entity sharing list”) stores a virtual entity identifier 39 and an access list 40 for each entity and defines access privileges for unregistered users (referred to as "share viewers") which are invited by registered users to share viewing of files.
  • the virtual file system access control list 30 is similar to the virtual file system access control list 29 except that access privileges are usually limited, for example, to read only.
  • Share viewers are identified and authenticated differently from registered users. Identification and authentication can be performed by external system(s) (not shown) having a trust relationship established with the distributed storage system 1.
  • the virtual file system access control list 30 may be omitted, for example, if share viewers are not permitted to access the distributed storage system 1.
  • the fourth table 31 (hereinafter referred to as a "logical cluster metadata table”) stores a (logical) cluster identifier 41 and (physical) storage device identifier 42 for each cluster 27.
  • the logical cluster metadata table 31 allows a cluster manager 23 to identify storage devices 6 in a cluster 27.
  • the fifth table 32 (hereinafter referred to as a "logical clusters relations table”) stores a first cluster identifier 43, a second cluster identifier 44 and a relationship type 45 for each cluster 27 and describes relationships between clusters 27.
  • the logical clusters relations table 32 may specify that a first cluster 27 A is a replica (i.e. a mirror) of a second cluster 27 B .
  • the logical clusters relations table 32 may specify that the first cluster 27 A is an archive for files stored in the second cluster 27 B , stored according to predefined criteria. An archive may contain rarely accessed files or files created before a specific date. Thus, a first cluster 27 A need not store files which are archived in a second cluster 27 B . Archived files may be stored in, for example, a tape storage system.
  • the system 1 can be used to provide a file service to clients 2, 3. Requests and responses are exchanged sessionlessly and so different file service providers 5 can handle different requests from the same client 2, 3. Thus, file service providers 5 need not store any information about the state of the client 2, 3. Instead, the client 2, 3 can store information about its state and supply this information when sending a request to a file service provider 5. For example, a request may include authentication information needed to validate a user against access privileges stored in the virtual file system access control list 29.
  • a client in this example the personal computer 2, sends a file write request 46 to the file service manager 21 of a file service provider 5 (step Wl).
  • the file service provider 5 is selected according to a routing mechanism or by load balancers (not shown) in the network 4 ( Figure 1).
  • the file write request 46 includes a file 47 to be written including file data 48 and file attributes 49, such as file type and file size.
  • the file service manager 21 forwards a cluster allocation request 50 to the allocation manager 22 (step W2).
  • the request 50 may include the file attributes 49 which may used to select a cluster 27.
  • the master allocation manager 22 M selects a cluster 27, for example based on the file attributes 49 and/or cluster attributes and state (not shown), such as available space and percentage of utilization, or on some other basis, such round robin (step
  • the allocation manager 22 determines whether it is the master allocation manager 22 M . If the allocation manager 22 is the master allocation manager 22 M , then it selects a cluster 27. If not, the allocation manager 22 forwards the request to the master allocation manager 22 M which allocates a cluster 27 and returns a cluster identifier.
  • the allocation manger 22 invokes the cluster manager 23 with an instruction 51 to select a storage device 6 within the selected cluster 27 (step W4).
  • the cluster manager 23 selects a storage device 6 (step W5).
  • the cluster manager 23 makes the selection based on highest network availability between the file service manager 21 and storage devices 6. Network availability can be determined using network state information collected at predetermined times, e.g. periodically, by the allocation manager 22 and by the cluster manager 23.
  • the cluster manager 23 sends an instruction 52 to the storage device 6 to create a filestream 53 having a given path in the storage device 6 (step W6).
  • the storage device 6 creates a filestream 53 (step W7).
  • a unique file handler is associated with the filestream 53 which points (with pointer P) to a first writable block in the filestream 53 in the storage device 6.
  • the identity 54 of the file handler (which identifies the filestream 53) is returned to the cluster manager 23 (step W8).
  • the cluster manager 23 returns the file handler identity 54, a path 55 and cluster identity 56 to the allocation manager 22 (step W9), which in turn returns the information to the file service manager 21 (step WlO).
  • the file service manager 21 applies writing filters, such as compression and/or virus checking, to the file data 48 (step WI l) and writes filtered file data 57 to the open filestream 53 (step Wl 2).
  • the filestream 53 is filled with filtered file data 57.
  • the storage device advances the pointer P to point to the next available free block.
  • the file service manager 21 sends an instruction 59 to the cluster manager 23 to close the filestream 53 (step Wl 3).
  • the cluster manager 23 sends an instruction 60 to the storage device 6 to close the filestream 53 (step Wl 4).
  • the storage device 6 writes an end of file (EOF) marker 61 to the filestream 52 (step Wl 5), frees the pointer and updates the storage system allocation table (not shown), such as a file allocation table provided by the storage device 6.
  • EEF end of file
  • the cluster manager 23 then triggers replication of the stored filestream 53 in other storage devices 6 in the same cluster 27 by sending an instruction (not shown) to the replication service 24 ( Figure 2) (step Wl 6).
  • the file service manager 21, via metadata server interface 25, sends an instruction 62 to the metadata server H 1 to write metadata into the virtual file system entity table 28, virtual file system access control list 29, virtual file system entity sharing list table 30, logical cluster metadata table 31 and logical clusters relations table 32, as necessary (step Wl 7).
  • the metadata server H 1 writes the file information (step Wl 8) and returns a virtual file identifier 63 to the file service manager 21 (step W19).
  • the file service manager 21 sends confirmation 64 to the client 2 that the file has been written including the virtual file identifier 63 (step W20).
  • the allocation manager 22 determines whether or not it is the master allocation manager 22 M . A process by which this is achieved will now be described in more detail.
  • the allocation manager 22 receives a request 48 ( Figure 5a) to allocate a cluster 27 (step Sl).
  • the allocation manager 22 checks whether the master allocation manager 22 M is known (step S2).
  • the allocation manager 22 determines whether it is the master allocation manager 22 M (step S3). If so, then the allocation manager 22 processes the request and selects a cluster 27 as described earlier (step S4). If not, then the allocation manager 22 forwards the request to the master allocation manager 22 M (step S5). The allocation manager 22 receives a cluster identifier from the master allocation manager 22 M .
  • the allocation manager 22 If the allocation manager 22 does not know the identity of the master allocation manager 22 M , then the allocation manager 22 sends a query 65 to the other allocation manager (s) 22 asking for the identity of the master (step S6).
  • the allocation manager 22 waits for replies (step S7) and checks whether the query "times out", i.e. whether a response is received before a predetermined period elapses (step S8). If the allocation manager 22 receives a reply 66 before the query times out, then it stores the identity of the master allocation manager 22 M (step S 9) and forwards the request to the master allocation manager 22 M (step S5).
  • step SI l If the allocation manager 22 does not receive any reply before the query times out, then it sends a message 67 asserting that it is the master (step SI l). The allocation manager 22 waits for objections (step SI l) and checks whether the message 67 times out (step S 12).
  • the allocation manager 22 If the allocation manager 22 does not receive any objection before the request times out, then it records itself as the master allocation manager 22 M (step S 13) and processes the request to select a cluster (step S4).
  • the allocation manager 22 If, however, the allocation manager 22 receives an objection 68, then it re-sends an identification query 65 to the other allocation managers 22 (step S6).
  • the allocation manager 22 continuously listens for queries 65 and messages 67.
  • a master allocation manager 22 M can be relegated if it receives a message 67 from another allocation manager 22 or if the file service provider 5 is de-activated, for example shut down.
  • the file update process is similar to the file writing process described earlier.
  • the allocation manager 22 frees space allocated to an older version of a file, allocates space to a newer version of the file and writes the newer version of the file, as if it were a newly created file.
  • the client 2 sends a file update request 69 to the file service manager 21 of a file service provider 5 (step Ul).
  • the file write request 69 includes an updated file 70, including a new file data 71 and new file attributes 72, and a virtual file identifier 73 for an old file, for example the previously stored file 47.
  • the file service manager 21 sends a query 74 to the active metadata server H 1 to find out which cluster 27 the old file is stored (step U2). Alternatively, the file server manager 21 may send the query 74 to the passive metadata server H 2 .
  • the active metadata server H 1 returns an old cluster identifier 75, a path 76 in the storage device 6 and old file attributes 77 (step U3).
  • step U4 to U22 proceeds in a similar way to steps W2 to W20 of the writing process described earlier.
  • the file service manager 21 forwards a cluster allocation request 78 to the allocation manager 22 (step U4) and the master allocation manager 22 M selects a cluster 27 (step U5).
  • the allocation manger 22 sends an instruction 79 to select a storage device 6 within the selected cluster 27 (step U6).
  • the cluster manager 23 selects a storage device 6
  • step U7 The cluster manager 23 sends an instruction 80 to the storage device 6 to create a new filestream 81 having a given path in the storage device 6 (step U8).
  • the storage device 6 creates a filestream 81 (step U9) and passes a new file handler identifier 82 to the cluster manager 23 (step UlO).
  • the cluster manager 23 returns the new filestream 81, a corresponding path 83 and cluster identity 84 to the allocation manager 22 (step UI l).
  • the allocation manager 22 forwards this information to the file service manager 21 (step U12).
  • the file service manager 21 applies writing filters to the new file data 71 (step U 13) and writes a new filtered file data 85 to the open filestream 81 (step U14).
  • the file service manager 21 sends an instruction 87 to the cluster manager 23 to close the filestream 81 (step Ul 5).
  • the cluster manager 23 sends an instruction 88 to the storage device 6 to close the filestream 81 (step U16).
  • the storage device 6 writes an end of file (EOF) marker
  • step U17 frees the pointer and updates the storage device file system allocation table (not shown).
  • the cluster manager 23 triggers replication of the filestream 81 in other storage devices 6 in the same cluster 27 by sending an instruction (not shown) to the replication service 24 (Figure 2) (step Ul 8).
  • the metadata server H 1 writes the updated file information (step U20) and returns a new virtual file identifier 91 to the file service manager 21 (step U21).
  • the file service manager 21 sends confirmation 92 to the client 2 that the file has been written (step U22).
  • the file service manager 21 sends an instruction 93 to the cluster manager 23 to delete the old file (step U23).
  • the cluster manager 22 finds the storage device 6 storing the old filestream (step U24) and sends an instruction 94 to the storage device 6 to delete the old filestream (step U25).
  • the cluster manager 23 triggers replication of the storage device 6 (step U26).
  • the client 2 sends a file read request 95 to the file service manager 21 of a file service provider 5 (step Rl).
  • the file read request 95 includes a virtual file identifier 96 for a file, for example the previously stored file 42 or the updated file 68.
  • the file service manager 21 sends a query 97 to the passive metadata server H 2 to find out which cluster 27 the file is stored (step R2).
  • the file server manager 21 may send the query 97 to the active metadata server H 1 .
  • the passive metadata server H 2 returns a cluster identifier 98, a path 99 in the storage device 6 and file attributes 100 (step R3).
  • the file service manager 21 sends a request 101 to the cluster manager 23 to select a storage device 6 (step R4).
  • the cluster manager 23 selects a storage device 6 within the cluster 27 identified by the cluster identifier 98 according to highest network availability (step R5) and sends and instruction 102 to the storage device 6 to open a filestream 103 (steps R6). If the cluster manager 23 fails to access the storage device 6, then it refers to the logical cluster relationship table 32 to determine if the cluster 27 is mirrored or archived. If so, the cluster manager 23 sends a new instruction (not shown) to another storage device 6.
  • the storage device 6 retrieves file data 104 from the filestream 99 and forwards it to the cluster manager 23 (step R7).
  • the cluster manager 23 passes the file data 104 to file service manager 21 (step R8).
  • the file service manager 21 applies reading filters to the file data 104 (step R9) and forwards a filtered filestream 105 to the client 2 (step RlO).
  • a user may grant access privileges to other users, referred to as "share viewers".
  • the user can grant access privileges to a share viewer and notify the share viewer of the location of a file or folder by e-mailing or texting a message to the share viewer which includes a link, for example in the form of a uniform resource locator (URL) which identifies a file service provider 5 and the virtual file, for accessing the file or folder.
  • the share viewer selects the link, thereby sending a request to the file service provider 5 to retrieve the file or folder.
  • URL uniform resource locator
  • the system 1 hereinbefore described can be used to provide a file service regardless of storage infrastructure. It can provide distributed file input and output over a consolidated storage space with pluggable stream handling over redundant sites.
  • the file service can be provided by mobile telephone network providers to users having mobile telephone handsets, by technology integrators and by companies.
  • the system 1 decouples file metadata from file data and unites real file systems, i.e. storage devices, so that they appear as a single storage unit. This can help to minimise or circumvent storage device limitations, such as storage capacity, storage device throughput and so on.
  • the system 1 can handle filestreams and need not divide filestreams into blocks for handling.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

Un serveur destiné à gérer l'accès à une mémoire distribuée comprenant une pluralité de dispositifs de stockage inclut un gestionnaire de services de fichiers destiné à recevoir une requête pour stocker un fichier dans la mémoire distribuée et un gestionnaire d'attribution des ressources destiné à sélectionner un groupe à l'intérieur de la mémoire distribuée devant être utilisé lors du stockage du fichier. Le gestionnaire d'attribution des ressources est configuré de manière à communiquer avec au moins un autre gestionnaire d'attribution des ressources dans un autre serveur de sorte à déterminer quel gestionnaire d'attribution des ressources sélectionne le groupe devant être utilisé.
PCT/EP2007/053657 2006-05-23 2007-04-13 Mémoire distribuée WO2007134918A1 (fr)

Priority Applications (3)

Application Number Priority Date Filing Date Title
CN2007800184107A CN101449559B (zh) 2006-05-23 2007-04-13 分布式存储器
JP2009511432A JP5584910B2 (ja) 2006-05-23 2007-04-13 分散ストレージ
KR1020087028408A KR101366220B1 (ko) 2006-05-23 2007-04-13 분산형 저장소

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US11/439,784 2006-05-23
EP06114443.2 2006-05-23
US11/439,784 US8255420B2 (en) 2006-05-23 2006-05-23 Distributed storage
EP06114443.2A EP1860846B1 (fr) 2006-05-23 2006-05-23 Procédé et dispositifs permettant la gestion de stockage distribué

Publications (1)

Publication Number Publication Date
WO2007134918A1 true WO2007134918A1 (fr) 2007-11-29

Family

ID=38269044

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2007/053657 WO2007134918A1 (fr) 2006-05-23 2007-04-13 Mémoire distribuée

Country Status (3)

Country Link
JP (1) JP5584910B2 (fr)
KR (1) KR101366220B1 (fr)
WO (1) WO2007134918A1 (fr)

Cited By (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2011528142A (ja) * 2008-07-09 2011-11-10 ザ・ボーイング・カンパニー 安全且つハイパフォーマンスの多重レベルセキュリティデータベースシステム及び方法
KR101092658B1 (ko) 2008-12-22 2011-12-13 한국전자통신연구원 분산 파일 시스템 및 그의 메타데이터 서버 선택 방법
WO2011110534A3 (fr) * 2010-03-08 2012-01-19 Universitat Politècnica De Catalunya Enveloppe virtuelle
US8688630B2 (en) 2008-10-24 2014-04-01 Compuverde Ab Distributed data storage
US8769138B2 (en) 2011-09-02 2014-07-01 Compuverde Ab Method for data retrieval from a distributed data storage system
US8843710B2 (en) 2011-09-02 2014-09-23 Compuverde Ab Method and device for maintaining data in a data storage system comprising a plurality of data storage nodes
US8997124B2 (en) 2011-09-02 2015-03-31 Compuverde Ab Method for updating data in a distributed data storage system
US9021053B2 (en) 2011-09-02 2015-04-28 Compuverde Ab Method and device for writing data to a data storage system comprising a plurality of data storage nodes
EP2718858A4 (fr) * 2011-06-09 2015-08-05 Cloudian Holdings Inc Système de gestion de données hybride et procédé destiné à la gestion de grands ensembles de données variables
US9305012B2 (en) 2011-09-02 2016-04-05 Compuverde Ab Method for data maintenance
US9503524B2 (en) 2010-04-23 2016-11-22 Compuverde Ab Distributed data storage
US9626378B2 (en) 2011-09-02 2017-04-18 Compuverde Ab Method for handling requests in a storage system and a storage node for a storage system

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101312573B1 (ko) * 2009-12-18 2013-09-30 한국전자통신연구원 메타데이터 접근 장치 및 방법

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5873085A (en) * 1995-11-20 1999-02-16 Matsushita Electric Industrial Co. Ltd. Virtual file management system
US20030018927A1 (en) * 2001-07-23 2003-01-23 Gadir Omar M.A. High-availability cluster virtual server system
EP1578088A2 (fr) * 2004-03-19 2005-09-21 Hitachi, Ltd. Méthode pour le transfert dynamique d'un serveur de fichier dynamique
US20050246393A1 (en) * 2000-03-03 2005-11-03 Intel Corporation Distributed storage cluster architecture

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH06332782A (ja) * 1993-03-22 1994-12-02 Hitachi Ltd ファイルサーバシステム及びそのファイルアクセス制御方法
JP2000207370A (ja) * 1999-01-20 2000-07-28 Matsushita Electric Ind Co Ltd 分散ファイル管理装置及び分散ファイル管理システム
JP4265245B2 (ja) * 2003-03-17 2009-05-20 株式会社日立製作所 計算機システム
JP2005266933A (ja) * 2004-03-16 2005-09-29 Fujitsu Ltd ストレージ管理システム及びストレージ管理方法
US7634566B2 (en) * 2004-06-03 2009-12-15 Cisco Technology, Inc. Arrangement in a network for passing control of distributed data between network nodes for optimized client access based on locality
JP2006113663A (ja) * 2004-10-12 2006-04-27 Nec Fielding Ltd データ保管システム、その方法、ファイルサーバ、端末およびプログラム

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5873085A (en) * 1995-11-20 1999-02-16 Matsushita Electric Industrial Co. Ltd. Virtual file management system
US20050246393A1 (en) * 2000-03-03 2005-11-03 Intel Corporation Distributed storage cluster architecture
US20030018927A1 (en) * 2001-07-23 2003-01-23 Gadir Omar M.A. High-availability cluster virtual server system
EP1578088A2 (fr) * 2004-03-19 2005-09-21 Hitachi, Ltd. Méthode pour le transfert dynamique d'un serveur de fichier dynamique

Cited By (27)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2011528142A (ja) * 2008-07-09 2011-11-10 ザ・ボーイング・カンパニー 安全且つハイパフォーマンスの多重レベルセキュリティデータベースシステム及び方法
US8688630B2 (en) 2008-10-24 2014-04-01 Compuverde Ab Distributed data storage
US9026559B2 (en) 2008-10-24 2015-05-05 Compuverde Ab Priority replication
US9495432B2 (en) 2008-10-24 2016-11-15 Compuverde Ab Distributed data storage
US11907256B2 (en) 2008-10-24 2024-02-20 Pure Storage, Inc. Query-based selection of storage nodes
US11468088B2 (en) 2008-10-24 2022-10-11 Pure Storage, Inc. Selection of storage nodes for storage of data
US9329955B2 (en) 2008-10-24 2016-05-03 Compuverde Ab System and method for detecting problematic data storage nodes
US10650022B2 (en) 2008-10-24 2020-05-12 Compuverde Ab Distributed data storage
KR101092658B1 (ko) 2008-12-22 2011-12-13 한국전자통신연구원 분산 파일 시스템 및 그의 메타데이터 서버 선택 방법
WO2011110534A3 (fr) * 2010-03-08 2012-01-19 Universitat Politècnica De Catalunya Enveloppe virtuelle
US9948716B2 (en) 2010-04-23 2018-04-17 Compuverde Ab Distributed data storage
US9503524B2 (en) 2010-04-23 2016-11-22 Compuverde Ab Distributed data storage
EP2718858A4 (fr) * 2011-06-09 2015-08-05 Cloudian Holdings Inc Système de gestion de données hybride et procédé destiné à la gestion de grands ensembles de données variables
US9396290B2 (en) 2011-06-09 2016-07-19 Cloudian Holdings, Inc. Hybrid data management system and method for managing large, varying datasets
US9672267B2 (en) 2011-06-09 2017-06-06 Cloudian Holdings, Inc. Hybrid data management system and method for managing large, varying datasets
US8997124B2 (en) 2011-09-02 2015-03-31 Compuverde Ab Method for updating data in a distributed data storage system
US9626378B2 (en) 2011-09-02 2017-04-18 Compuverde Ab Method for handling requests in a storage system and a storage node for a storage system
US9305012B2 (en) 2011-09-02 2016-04-05 Compuverde Ab Method for data maintenance
US9965542B2 (en) 2011-09-02 2018-05-08 Compuverde Ab Method for data maintenance
US10430443B2 (en) 2011-09-02 2019-10-01 Compuverde Ab Method for data maintenance
US10579615B2 (en) 2011-09-02 2020-03-03 Compuverde Ab Method for data retrieval from a distributed data storage system
US9021053B2 (en) 2011-09-02 2015-04-28 Compuverde Ab Method and device for writing data to a data storage system comprising a plurality of data storage nodes
US10769177B1 (en) 2011-09-02 2020-09-08 Pure Storage, Inc. Virtual file structure for data storage system
US10909110B1 (en) 2011-09-02 2021-02-02 Pure Storage, Inc. Data retrieval from a distributed data storage system
US11372897B1 (en) 2011-09-02 2022-06-28 Pure Storage, Inc. Writing of data to a storage system that implements a virtual file structure on an unstructured storage layer
US8843710B2 (en) 2011-09-02 2014-09-23 Compuverde Ab Method and device for maintaining data in a data storage system comprising a plurality of data storage nodes
US8769138B2 (en) 2011-09-02 2014-07-01 Compuverde Ab Method for data retrieval from a distributed data storage system

Also Published As

Publication number Publication date
JP2009537918A (ja) 2009-10-29
JP5584910B2 (ja) 2014-09-10
KR20090047393A (ko) 2009-05-12
KR101366220B1 (ko) 2014-02-21

Similar Documents

Publication Publication Date Title
US8255420B2 (en) Distributed storage
JP5584910B2 (ja) 分散ストレージ
US6826661B2 (en) Methods and systems for storage architectures
US7783737B2 (en) System and method for managing supply of digital content
JP5160408B2 (ja) サービス要求を満足するためのリソース・マネージャを選択するための方法、システム、およびコンピュータ・プログラム
US9413825B2 (en) Managing file objects in a data storage system
JP5727020B2 (ja) クラウドコンピューティングシステム及びそのデータ同期化方法
US9122397B2 (en) Exposing storage resources with differing capabilities
US20090112789A1 (en) Policy based file management
US20090112921A1 (en) Managing files using layout storage objects
KR20070011413A (ko) 네트워크를 통해 클라이언트로 액세스가능한 파일세트의네임스페이스를 유지하는 방법, 시스템 및 프로그램
US10579597B1 (en) Data-tiering service with multiple cold tier quality of service levels
US8627446B1 (en) Federating data between groups of servers
EP3296895B1 (fr) Stockage de fichiers
US11221993B2 (en) Limited deduplication scope for distributed file systems
CN102448077B (zh) 内容管理方法与内容管理系统
US20240223655A1 (en) Data processing system, data processing method, and related apparatus
EP1860846B1 (fr) Procédé et dispositifs permettant la gestion de stockage distribué
RU2656739C1 (ru) Способ и система хранения данных
CN109347896A (zh) 一种信息处理方法、设备和计算机可读存储介质
JPH09179771A (ja) ファイリングシステム及びファイリングシステムに適用するオブジェクト検索方法
CN117955701A (zh) 实现数据安全交换的方法、系统和电子设备及存储介质

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 200780018410.7

Country of ref document: CN

121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 07728122

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2009511432

Country of ref document: JP

WWE Wipo information: entry into national phase

Ref document number: 1020087028408

Country of ref document: KR

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 07728122

Country of ref document: EP

Kind code of ref document: A1