Abstract:
The system utilizes a plurality of layers to provide a robust storage solution. One layer is the RAID engine that provides parity RAID protection, disk management and striping for the RAID sets. The second layer is called the virtualization layer and it separates the physical disks and storage capacity into virtual disks that mirror the drives that a target system requires. A third layer is a LUN (logical unit number) layer that is disposed between the virtual disks and the host. By using this approach, the system can be used to represent any number, size, or capacity of disks that a host system requires while using any configuration of physical RAID storage.

Description:
CROSS-REFERENCES TO RELATED APPLICATIONS 
       [0001]    This application claims priority from U.S. application Ser. No. 13/908,873, filed Jun. 3, 2013, now U.S. Pat. No. 8,762,678, which is a continuation of U.S. application Ser. No. 12/107,689, filed Apr. 22, 2008, now U.S. Pat. No. 8,458,430, issued Jun. 4, 2013, which is a continuation of U.S. application Ser. No. 12/056,158, filed Mar. 26, 2008, now abandoned, which claims priority to U.S. Provisional Application No. 60/908,159, filed Mar. 26, 2007, which is incorporated herein in its entirety. 
     
    
     BACKGROUND 
       [0002]    A SAN (storage array network) is a storage system designed to attach mass storage units, such as disk drives or tape drives, to servers on a computer network. The SAN is sometimes referred to as a “fabric”. The storage device may sometimes be an array of disks known as a RAID array. RAID stands for Redundant Array of Inexpensive Disks, SAN is distinguished from Network-attached storage (NAS) which is the name given to dedicated data storage technology that can be connected directly to a computer network to provide centralized data access and storage to heterogeneous network clients. A SAN uses block level access so that it appears as locally attached storage to device drivers and application software. 
         [0003]    The growth of computer networks and the need for high capacity storage is growing with the rise of media applications and web 2.0 environments. It would be useful to take advantage of some of the features of storage systems such as SAN systems, file sharing systems, and others, in these and other emerging, high storage requirement environments. However, there are a number of disadvantages with applying this technology in current configurations. 
         [0004]    One current solution is a so called “turn-key” system where all aspects of the SAN and file sharing system are included in a single solution. These turn-key systems include all required hardware and software in the solution. A disadvantage of this system is that it is typically expensive, since there is no competition for individual components of the system. Another disadvantage is the difficulty in scaling the system. Again, with only a single source of equipment, scaling the system is expensive. 
         [0005]    Another current approach to providing a storage solution is to use generic file sharing software to control the hardware system. In this technique, the generic software is written to have the most basic storage protocols to maximize the potential compatibility with multiple hardware systems. This solution is typically done at the client/server and/or the OS level with whole file formats being written to provide a file sharing for whatever storage is attached. A disadvantage of the generic software approach is the difficulty of setting up and maintaining the system. There is no specific control or optimization for whatever hardware is being used. If a particular piece of hardware doesn&#39;t work with the system, the only solution is to use some other hardware or to revise the code of the generic software. The disadvantage is continuous revising, lack of optimization, compromised performance, and still with limitations on hardware choices. Another disadvantage is that scalability is not guaranteed. 
         [0006]    An alternate prior art approach is so-called “generic protocols”. This is the use of generic protocols such as SCSI to provide a file sharing layer so that the storage has to adapt to the protocol for compatibility. Another approach is the NAS system built into Ethernet. This approach has the disadvantage of not being optimized for performance with a particular hardware setup. It also lacks guaranteed scalability. Another problem is that block data needs to be translated into the generic protocol, adding a layer of complexity and lowering performance. 
       SUMMARY OF THE INVENTION 
       [0007]    The system utilizes a plurality of layers to provide a robust storage solution. One layer is the RAID engine that provides parity RAID protection, disk management and striping for the RAID sets. The second layer is called the virtualization layer and it separates the physical disks and storage capacity into virtual disks that mirror the drives that a target system requires. A third layer is a LUN (logical unit number) layer that is disposed between the virtual disks and the host. By using this approach, the system can be used to represent any number, size, or capacity of disks that a host system requires while using any configuration of physical RAID storage. In one embodiment the system provides dynamic configuration of the storage system depending on the requirements of the host system. When the system is connected to a host system or when a request is provided for certain parameters from a program, the system will retrieve the parameters and configure itself accordingly so that the requesting software has what it requires to use the storage it is requesting. The embodiment includes a feedback loop to be able to change the parameter controls between the virtualization layer and the LUN layer depending on information derived from the host system. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0008]      FIG. 1  is a flow diagram illustrating an embodiment of the invention. 
           [0009]      FIG. 2  is a flow diagram of the operation of an embodiment of the system. 
           [0010]      FIG. 3  is a flow diagram illustrating operation of an embodiment of the system. 
           [0011]      FIG. 4  is a flow diagram illustrating the feedback operation of the system in one embodiment. 
       
    
    
     DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 
       [0012]    The system provides a system that allows the logical creation of virtual disks that can be accessed by a host system. The system is disposed between a RAID array and a host computer and is implemented in the firmware of a RAID controller. The system is flexible and scalable. The system allows the entry of parameters in the firmware layers that are identical to whatever parameters are required by an application and/or operating system. In this manner, the system is always optimized for the configuration that it is in, but without extensive original programming required. The system can use pre-defined standard or custom parameters but mirrors them in the virtual disk environment to provide compatibility with any system. The system can provide custom block sizes, access times, sector size, scanning size, mode pages and any other parameters to simulate an actual real disk that a piece of software or application would need to see for optimized performance. 
         [0013]    The host system believes it is coupled to a block-level storage unit, either in fibre channel SCSI or some other protocol. The host system sees what to it is one or more individual hard drives. However, the actual drives may be RAID array drives in the system. 
         [0014]      FIG. 1  illustrates one embodiment of the system. The system is shown coupled to a host system  101 . The host system  101  has storage requirements and utilizes some set of parameters for storage read/write and control. The host system  101  may comprise an operating system and/or one or more applications that require storage. 
         [0015]    The storage system uses three layers, the LUN layer  102  that presents a plurality of virtual disk logical unit numbers  106  to the host system. The LUN layer  102  is coupled to the virtualization layer  103 . The LUN layer provides a level of control for compatibility. Each Vdisk can be directed to a LUN or a series of LUNs which are then directed to the appropriate port of the host system  101 . 
         [0016]    The virtualization layer  103  presents a set of virtual disks  107  to the LUN layer  102 . The virtual disks  107  are mapped to the virtual disk LUNs  106  of the LUN layer  102 . The virtualization layer  103  may represent a RAID array such as shown consisting of disks 1, 2, 3, 4 to disk n+1. The virtualization layer divides each RAID set into Vdisks that mirror the drives that the host system requires. All parameters, such as block size, firmware, mode pages, and other parameters are configurable or dynamic. 
         [0017]    Although shown as a RAID array, the virtualization layer  103  can be implemented in any manner, even as one or more volumes that may or may not be part of a RAID array. The virtualization layer can be dynamically reconfigured on the fly to provide the appropriate storage parameters of the requesting application or operating system. 
         [0018]    The virtual RAID array of virtualization layer  103  is coupled to the RAID engine  104  that includes a plurality of RAID sets  108  labeled 1-N/5 in the embodiment of  FIG. 1 . The RAID engine  104  provides XOR parity RAID protection, disk management, and striping of the physical RAID array  105 . In one embodiment, RAID level 5 is the minimum RAID level requirement for the RAID sets. Drives are striped in sets of 5. All standard RAID parameters are available and block size for striping is dynamic. 
         [0019]    The virtualization layer  103  is able to emulate any type of storage solution with the only constraint being the physical capabilities of the underlying RAID engine  104  and physical disks  105 . The available storage volume of the virtualization layer cannot exceed the total storage available in the RAID array  105 . Although illustrated as a RAID array, the physical storage layer may be implemented in any desired manner. In addition, even though the system is described in conjunction with the use of disk storage at the physical layer, the physical layer may be implemented as any suitable storage medium, including other moving media devices, or other schemes such as solid state memory devices, without departing from the scope and spirit of the system. 
         [0020]    The feedback/configuration layer  106  is used to configure the LUN layer  102 , virtualization layer  103 , RAID engine  104 , and physical disks  105  depending on the protocol and format requirements of the memory requester. 
         [0021]    The system is transparent to the host system. The host system sees LUN drives and block level access even though there are multiple layers between the host and the physical disks themselves. The system is also infinitely scalable, because the number of disks that the system sees or wants is completely configurable in the virtual and LUN layers. The only requirement is to add sufficient physical RAID storage to support the host requirements. Because the system uses parameters as required by each host or application, optimization is taken care of automatically. There is no generic software that is a compromise for most systems. Further, by not requiring a generic protocol, the system again can be optimized for the intended use. Finally, because the system is open and configurable, it is superior to turnkey systems because it can use any physical storage and is not locked in to a proprietary system. This allows users to scale in an economical fashion. 
         [0022]    All storage access from the host  101  to storage are made to the LUN layer  102  and virtualization layer  103 . Data is written by the host  101  to the LUN layer  102  and data is read by the host  101  from the LUN layer  102 . 
         [0023]    Operation 
         [0024]      FIG. 3  is a flow diagram illustrating operation of the system in one embodiment. At step  301 , a memory requester generates a memory access request (e.g. a read operation). At step  302  the requester specifies the location of the data to be retrieved and sends the request to the LUN layer  102 . At step  303  the LUN layer routes the request to the virtualization layer  103 . At step  304  the virtualization layer  103  translates the virtual address location to a physical address that it sends to the RAID engine  104 . 
         [0025]    The RAID engine  104  retrieves the requested data from the drives at step  305 . At step  306  the data is provided to the virtualization layer  103 . At step  307  the virtualization layer  103  formats the data as necessary to satisfy the storage parameters in use. This may include changing the block size, etc. At step  308  the data is provided by the virtualization layer  103  to the LUN layer  102  and ultimately, to the requester on host  101 . 
         [0026]    Dynamic Configuration 
         [0027]    One advantage of the system is the ability to configure the virtualization layer  103  depending on the requirements of the operating system and/or applications that are accessing storage. In one embodiment the system includes automatic parameter setting. When it is connected to a host system or when a request is provided for certain parameters from a program, application, or operating system, the system will retrieve the parameters and configure itself accordingly so that the requester has what it requires to use the storage it is requesting. 
         [0028]      FIG. 2  is a flow diagram illustrating the dynamic operation of one embodiment of the system. At step  201  a connection to a host is initiated and a storage request is made. The storage request includes the parameters required by the storage requester. The parameters may be based on a particular disk file system used by the requester, such disk file systems include FAT (FAT12, FAT16, FAT32), NTFS, HFS and HFS+, ext2, ext3, ISO 9660, ODS-5, and UDF. Some disk file systems are journaling file systems or versioning file systems. The parameters needed by the requester can sometimes be found in metadata accompanying the request. 
         [0029]    At step  202  the system identifies the parameters of the request and determines if any reconfiguration is required. This can be accomplished by reading any associated metadata for the block size, volumes, rootmap, etc. At step  203  the system configures the LUN layer pursuant to the necessary parameters. This could be in response to a request that has parameters for a fibre channel protocol, a SCSI protocol, APA protocol, or any other or future protocol that defines its needed parameters. At step  204  the system configures the virtualization layer if necessary to match up with the protocol request. At step  205 , the system responds to the host request appropriately so that the host can now use the storage as it prefers. 
         [0030]    In one embodiment the system is configured dynamically via a feedback system  109  where information about drive changes from the host is used to reset parameters in the system. For example, after the system responds to the host at step  205 , the system detects drive changes at block  206  and returns to step  202  where parameter settings are identified and changes to the parameters are made. 
         [0031]      FIG. 4  is a flow diagram illustrating the feedback operation of the system in one embodiment. At step  401  the system receives a memory access request. At step  402  the system checks the request to see the protocol format of the request. At step  403  the system determines if the storage is already configured in the manner requested. 
         [0032]    If not, the system proceeds to step  404  to determine if it is possible to configure the memory as requested (e.g. does not exceed block size limitations, total storage limitations, etc.). If not, the system notifies the user at step  405 . 
         [0033]    If the requested configuration is valid at step  404 , the system checks to see if the configuration will result in any conflicts with existing usage. For example, the host could have drives connected at LUNs zero and ten already, and the new request might conflict with that assignment. If there is a conflict, the system reconciles the conflict at step  407 . This could be the reassignment of LUN volumes temporarily to allow the desired access. 
         [0034]    If the system is already configured at step  403 , or if there is not conflict at step  406 , or after the reconciliation at step  407 , the system proceeds to step  408  and provides the requested memory access. 
         [0035]    Thus, a configurable and scalable memory system is provided.