When I recently attended VMworld 2008, I had the opportunity to get a closer look at NEC’s latest HYDRAstor release, the HS8-2000, and some of its features. Of course at a trade show all you generally have the time and opportunity to do is take a quick look at some of the product’s hardware and software features. But in this case there was a feature on the HYDRAstor that struck me just from the short time I spent evaluating it: the ability to create a 256 petabyte (PB) or larger file system.
For those of you unfamiliar with the HYDRAstor, it is not a virtual tape library (VTL) but a networked attached storage (NAS) system that is primarily intended for use as a disk-based backup target. Configured as NAS, it presents a file system (CIFS or NFS) to backup servers that use it as a disk-based backup target. Now normally using NAS as a disk-based backup target may be a concern in enterprise shops for one major reason: file systems have limited capacity that creates an upper limit in terms of how large they can grow.
While VTLs also have upper limits in terms of storage capacity, VTLs appear as physical tape libraries to the backup software. Since backup software knows how to manage physical tape libraries by recognizing out of space conditions on a tape cartridge, it also knows how to recognize out-of-space conditions on virtual tape cartridges on a VTL. So when a virtual tape cartridge fills up, the backup software understands that it needs to start writing to the next virtual tape cartridge, which avoids the out of space condition that can cause backup jobs to hang or fail.
However if a file system fills up backup software may suspend operations or hang since it does not know how to manage out-of-space conditions on file systems. As a result, backup jobs may fail or pause until a backup administrator manually intervenes by either deleting some of the data from the existing file system or re-directing the backup job to a new file system target with more capacity.
HYDRAstor’s support of a 256 PB file system helps to negate this specific concern about using NAS as a disk-based target. By providing a disk-based target that can contain 256 PB or more of data, companies can have confidence that directing backup jobs to a HYDRAstor file system will not result in backup jobs hanging because of an out-of-space condition.
Of course, just because administrators can create and present a 256 PB file system as a backup target to corporate backup servers does not mean that the HYDRAstor actually contains 256 PB (or more) of storage capacity. (If fact, I am quite sure the 256 PB file system I created on the HYDRAstor while at VMworld had nowhere near 256 PB of storage capacity behind it.) But because HYDRAstor supports the creation of multiple such file systems, it increases the overall virtual capacity supported on the HYDRAstor (at least from a file system perspective), from petabytes to Exabytes or even larger.
In this respect, the HYDRAstor is like some other storage systems in that it also uses its own form of thin provisioning to present a file system to the backup host so it appears to have more storage capacity than it actually has. The main differentiator is that HYDRAstor does not require any actual provisioning of resources. Using its grid architecture, all capacity across the entire HYDRAstor is available for all file systems and applications as a shared pool of storage. This improves the efficiency of the utilization of the available capacity by the file systems and applications that need it while permitting the addition of more capacity over time.
HYDRAstor’s support of a 256 PB (or larger) file system addresses a concern of enterprise shops that often goes unaddressed by current disk-based backup systems that use NAS – unlimited storage capacity. By giving each and every file system on the HYDRAstor the ability to grow to 256 PB and beyond, companies no longer need to worry about managing and extending file systems manually. Instead they only need to set this up at the beginning when they configure the file systems, regularly monitor the HYDRAstor and how close it is getting to capacity (as opposed to individual file systems) and then add new Storage Nodes to the HYDRAstor when it starts to run short on capacity. HYDRAstor then takes it from there and automatically assigns the capacity on as-needed basis to specific file systems which can then be extended on-the-fly to whatever size file system is needed.