Looking for breakthrough ideas for innovation challenges? Try Patsnap Eureka!

Directory aggregation for files distributed over a plurality of servers in a switched file system

a file system and server technology, applied in the field of storage networks, can solve the problems of changing the rules of the game, inability to adequately handle and difficulty in creating storage and network systems capable of adequately handling such amounts of information and usage load

Inactive Publication Date: 2004-07-08
RPX CORP
View PDF6 Cites 195 Cited by
  • Summary
  • Abstract
  • Description
  • Claims
  • Application Information

AI Technical Summary

Benefits of technology

[0072] File Switch. A "file switch" performs file aggregation, transaction aggregation and directory aggregation functions, and is logically positioned between a client and a set of file servers. To client devices, the file switch appears to be a file server having enormous storage capabilities and high throughput. To the file servers, the file switch appears to be a client. The file switch directs the storage of individual user files over multiple file servers, using striping to improve throughput and using mirroring to improve fault tolerance as well as throughput. The aggregation functions of the file switch are done in a manner that is transparent to client devices.
[0456] At block 2604, the RMC selects a primary metaserver. The primary metaserver is selected based on the name of the metafile. In one embodiment, the RMC selects the primary metaserver by computing a sum S of all character values of the metafile name and then computer S modulo M, where M is the number of metaservers. The resultant number is used by the file switch as the ordinal number of the primary metaserver. In another embodiment of the present invention, the primary metaserver is selected by computing a hash function of the name of the metafile. The resultant number of the hash function is the ordinal number of the selected primary metaserver. Both of these methods distribute the primary metafiles evenly across the available metaservers, and hence improve the performance of the overall system. In yet another implementation, the primary metaserver is a predefined one of the metaservers, such as the metaserver having the lowest ordinal number.

Problems solved by technology

Despite the importance of storage applications in networks, their usefulness has, until recently, been greatly limited by the insufficient bandwidth provided by networks.
The introduction of gigabit and multi-gigabit network technology, however, is changing the rules of the game.
At the same time, creating storage and network systems capable of adequately handling such amounts of information and usage loads is not a simple task.
The flip side is that file systems are complex and very processing-intensive, which increases substantially the performance requirements to any computer that provides file services over a fast network.
To serve files to hundreds and thousands of users simultaneously requires tremendous amounts of processing power, memory and bus bandwidth.
The result of this approach is that high-end file servers are essentially massively multiprocessing supercomputers, with all the associated costs and complexity.
However, high-performance multiprocessing file servers quickly run into the performance limits of their storage subsystems.
Single-box solutions are subject to several serious problems.
First, because of the extremely high complexity and the need to develop custom silicon in order to satisfy performance requirements, single box solutions are very expensive.
Second, their development cycles are exceedingly long, virtually guaranteeing that they will be "behind the curve" in many important aspects, such as software technologies, protocols, etc., by the time they are generally commercially available.
Since storage requirements effectively double every year or so, these boxes often become obsolete long before the customers manage to depreciate their high cost.
The main challenge in the above-mentioned file system comes from the need to frequently synchronize and coordinate access to the storage among all members of the cluster.
These components quickly become a major bottleneck that prevents the scaling of cluster file systems beyond about sixteen nodes.
The reliance on centralized resource coordination is the primary weak point of cluster file systems that limits severely their scalability.
Solutions that partially relieve this problem introduce other problems, including custom functionality in storage subsystems and specialized client-side software.
If any of these approaches is commercialized, the requirement for using proprietary storage subsystems will have substantial negative effect on both adoption and price, while the need to rely on proprietary client-side software that has to be installed in every client accessing the system make the system fragile, prone to security breaches and hard to deploy and support.
Both single box solutions and cluster file systems are tightly coupled systems that exhibit serious scalability limitations.
The main problem with available distributed file systems is that they do not scale in performance nearly as well as they scale in storage capacity.
Thus, the performance the distributed file system can deliver to a single client (workstation or application server) is limited by the performance of the utilized individual file servers, which, considering the large number of servers involved, is not likely to be a very high performance machine.
Another problem that has great impact in commercial environments is the fact that most distributed file systems require specialized client-side software that has to be installed and configured properly on each and every client that is to access the file system.
This tends to create massive versioning and support problems.
Moreover, distributed file systems are very prone to "hotspotting".
Hotspotting occurs when the demand for an individual file or a small set of files residing on a single server increases dramatically over short period of time, resulting in severe degradation of performance experienced by a large number of users.
Yet another problem with distributed file systems is in their low manageability.
Although most aspects of the distributed file systems can be managed while the system is on-line, the heterogeneous and distributed nature of these systems effectively precludes any serious automation of the management tasks.
As a result, managing distributed file systems requires large amount of highly qualified labor.
Although many approaches to scaling network file systems have been taken over the last fifteen years, none has succeeded in delivering on the high performance, high scalability and simple management promise of storage networking.
1. One file, one server. The inability to utilize multiple file servers in handling requests for a single file limits severely the throughput available to any single client and does not allow the system to balance the load across all available processing resources.
2. Centralized arbitration and metadata management. The need to arbitrate access to storage and the shared data structures used to manage it creates a bottleneck that severely limits the scalability of the system.
3. Proprietary client-side software. The need to buy, install, configure and support a non-trivial piece of software across all client machines running multiple different operating systems creates serious barrier for adoption.
However, there is no currently available system that can deliver all characteristics needed for storage networking to achieve its promise.
It is well known that the effectiveness of striping, mirroring and other data aggregation techniques when applied to block devices, such as in RAID or parallel file systems, can be greatly diminished by the fact that no single solution can fit all types of files and access patterns.
On the opposite side of the spectrum, HTML files are typically only a few kilobytes large and not a good target for striping.
However, this technique alone may not be sufficient to aggregate seamlessly the storage capacity of multiple file servers.
For example, with namespace aggregation alone it may not be possible to tell how much free disk-space is available on the aggregated file system.
Thus, even when the system as a whole has plenty of available storage space, particular file operations in particular places in the namespace may not be able to execute successfully without extensive human intervention.
However, in the event that there is an insufficient number of file servers to store each mirrored stripe of the user file, multiple stripes (i.e., stripe instances) can be stored in a single file server.
While aggregating files to multiple devices, over time some of the device's storage capacity may become exhausted.
As a result, the file aggregation may fail and cause disruptions in the systems network.

Method used

the structure of the environmentally friendly knitted fabric provided by the present invention; figure 2 Flow chart of the yarn wrapping machine for environmentally friendly knitted fabrics and storage devices; image 3 Is the parameter map of the yarn covering machine
View more

Image

Smart Image Click on the blue labels to locate them in the text.
Viewing Examples
Smart Image
  • Directory aggregation for files distributed over a plurality of servers in a switched file system
  • Directory aggregation for files distributed over a plurality of servers in a switched file system
  • Directory aggregation for files distributed over a plurality of servers in a switched file system

Examples

Experimental program
Comparison scheme
Effect test

Embodiment Construction

[0313] The following example illustrates how the directory structure for the user file is determined. This example assumes the following:

[0314] One file aggregator (i.e., file switch) and 2 different NAS arrays NAS1 and NAS2. Each NAS array contains 8 file servers. The names of the file servers in NAS1 are NAS1_SRV1, NAS1_SRV2, NAS1_SRV3, etc. The names of the file servers in NAS2 are NAS2_SRV1, NAS2_SRV2, NAS2_SRV3, etc.

[0315] The following namespace rules are defined:

1 Rule 1: ZFENGDOC*.* .fwdarw. NAS1DOC_DIR Rule 2: ZFENGDESIGN*.* .fwdarw. NAS2DESIGN_DIR Rule 3: ZFENGTRAINING*.MPG .fwdarw. NAS2MOVIES

[0316] The following aggregation rules are defined for NAS1:

2 Rule 1: DOC_DIR*.* .fwdarw. { stripe (4, 8192), mirror (1) }

[0317] The following aggregation rules are defined for NAS2:

3 Rule 1: DESIGN_DIR*.* .fwdarw. { stripe (4, 8192), mirror (1) } Rule 2: MOVIES*.* .fwdarw. { stripe (8, 16384), mirror (0) }

[0318] Assuming the client requests to access the file ".backslash.ZF.backslash...

the structure of the environmentally friendly knitted fabric provided by the present invention; figure 2 Flow chart of the yarn wrapping machine for environmentally friendly knitted fabrics and storage devices; image 3 Is the parameter map of the yarn covering machine
Login to View More

PUM

No PUM Login to View More

Abstract

A file switch, logically positioned between client computers and file servers in a computer network, distributes user files among multiple file servers using an aggregated directory mechanism. A hierarchical directory structure is created on the file servers and used to store metadata files, which store metadata for each user file to indicate where data files, containing portions of the user file, are stored. The file switch automatically spreads the data files and metadata files over a large number of distinct directories on multiple file servers, preventing large number of data files from being stored in a single directory on a single file server. In response to a directory enumeration request from a client computer, one or more directories of metadata files on one or more of the file servers is enumerated, instead of enumerating the data file that store the user file portions.

Description

[0001] This application claims priority from U.S. patent application Ser. No. 10 / 043,413, entitled File Switch and Switched File System, filed Jan. 10, 2002, and U.S. Provisional Patent Application No. 60 / 261,153, entitled FILE SWITCH AND SWITCHED FILE SYSTEM and filed Jan. 11, 2001, both of which are incorporated herein by reference. This application is furthermore related to the following applications, each of which is filed on the same date as this application and is hereby incorporated by reference in its entirety: Transaction Aggregation in a Switched File System, attorney docket 11187-0004-999; Metadata Based File Switch And Switched File, attorney docket 11187-0006-999; Rule Based Aggregation of Files and Transactions in a Switched File System, attorney docket 11187-007-999; Aggregated Lock Management for Locking Aggregated Files in a Switched File System, attorney docket 11187-008-999; and Aggregated Opportunistic Lock and Aggregated Implicit Lock Management for Locking Aggr...

Claims

the structure of the environmentally friendly knitted fabric provided by the present invention; figure 2 Flow chart of the yarn wrapping machine for environmentally friendly knitted fabrics and storage devices; image 3 Is the parameter map of the yarn covering machine
Login to View More

Application Information

Patent Timeline
no application Login to View More
Patent Type & Authority Applications(United States)
IPC IPC(8): G06F17/30H04L29/06H04L29/08H04L29/12
CPCG06F17/30091G06F17/30197H04L29/06H04L29/12009H04L67/1097H04L61/15H04L67/06H04L67/1095H04L29/12047G06F16/1824G06F16/13H04L61/45H04L61/00H04L9/40
Inventor MILOUSHEV, VLADIMIRNICKOLOV, PETER
Owner RPX CORP
Who we serve
  • R&D Engineer
  • R&D Manager
  • IP Professional
Why Patsnap Eureka
  • Industry Leading Data Capabilities
  • Powerful AI technology
  • Patent DNA Extraction
Social media
Patsnap Eureka Blog
Learn More
PatSnap group products