Thrinath Seelam commented on my last post on Cloud Optimized VSP G Series With Built In NAS, saying that he thought it was “really cool” to have HNAS management integrated in SVOS and managed through the Service Processor (SVP) management interface to the VSP G Series. Thank you Thrinath for your kind words and for pointing out the advantages of our integrated NAS approach.
Besides eliminating the need for a clustered HNAS gateway and the need for a separate management console, all the HNAS functions are now embedded in the VSP G Series. This embedded approach opens up more possibilities for Unified storage.
Here is a diagram of the HNAS architecture when it is implemented as a gate way.
At the top you can see a management board (System Management Unit) with CPU and Memory and two GbE ports which connected to an external management console. In the Unified VSP G Series that management board function now runs as software in a logical partition in the SVOS of the G series. This eliminates the need for a separate HNAS console. The management interface is now provided through the service processor for the G Series.
SVOS is essentially a storage hypervisor that manages multiple virtual storage machines, like the VMware hypervisor manages multiple virtual compute machines. Now one of these storage machines is an HNAS storage machine.
One of the functions that HNAS provides is non-disruptive file dedupe. Data blocks are streamed in through the FPGAs to the disk interface with no performance impact from the user perspective. Then the data block is read back in, hashed, and routed to the management board for dedupe before being asynchronously posted to the file system. No other file system architecture can provide dedupe without impact to performance. While this is an HNAS gateway diagram you can imagine this being done by the SVOS interacting with the HNAS FPGAs.
The VSP-G embedded HNAS management (System Management Unit -SMU) leverages some unique aspects of the hardware and certain aspects of its implementation are a bit different. For example, the embedded SMU functions in an active/standby fashion across both controllers and the cluster quorum functionality is provided through an internal method that leverage features within the block microcode.
The cloud optimization that I mentioned in my previous post, which provides the movement of data through the 10GbE ports over HTTP/HTTPs to cloud, is enabled by the software in SVOS. The new Hitachi Storage Advisor code that runs in the SVOS provides full integration with VMware VVols, and VASA to simplify storage operations and automate delivery of storage and data services for block and file. For more information on VMware integration see Greg Bucyk’s post here.
You can imagine additional functions, running as virtual machines, in this type of architecture as we see advancements in processor cores, memory systems, and containers. In the future it may be difficult to see a clear line between compute and storage. This will really be “way cool”