The Riverbed SteelFusion (aka Granite) impressed me the moment it was introduced to me 2 years ago. I remembered that genius light bulb moment well, in December 2012 to be exact, and it had left its mark on me. Like I said last week in my previous blog, the SteelFusion technology is unique in the industry so far and has differentiated itself from its WAN optimization competitors.
To further understand the ability of Riverbed SteelFusion, a deeper inspection of the technology is essential. I am fortunate to be given the opportunity to learn more about SteelFusion’s technology and here I am, sharing what I have learned.
What does the technology of SteelFusion do?
Riverbed SteelFusion takes SAN volumes from supported storage vendors in the central datacenter and projects the storage volumes (aka LUNs)to applications and hosts at the remote branches. The technology requires a paired relationship between SteelFusion Core (in the centralized datacenter) and SteelFusion Edge (at the branch). Both SteelFusion Core and Edge are fronted respectively by the Riverbed SteelHead WAN optimization device, to deliver the performance required.
The diagram below gives an overview of how the entire SteelFusion network architecture is like:
It is taken from the SteelFusion Product Guide, which I am using as my main reference. However, I much prefer this diagram here:
Just remember to substitute Granite with SteelFusion. 😉
The secret sauce to ensure the “local performance” experience at the branch is BlockStream. BlockStream is RiverBed patented technology that gels and integrates the data from the storage vendor’s iSCSI and Fibre Channel LUNs via SteelFusion Core, and projects a working data set to the SteelFusion Edge at the branch level.
SteelFusion Core is the storage delivery controller. Supported storage vendor platforms include EMC, NetApp, Dell, and IBM. They are also the storage vendors which have been tested with SteelFusion for their respective snapshot integration as well. The solution also can work with any other iSCSI or FC-SAN out there.
SteelFusion “wraps” the respective storage volumes and projects the data working set to SteelFusion Edge. Once the projected working data set is at the SteelFusion Edge, it is provisioned via the iSCSI protocol to various applications and hosts.
The centralized data in the form of LUNs are delivered to the SteelFusion Edge at the branch into BlockStore. BlockStore is an in-memory, persistent caching structure in the SteelFusion Edge device. It serves several key functions, most notably as the authoritative cache for local storage blocks. Frequently Read storage blocks are retrieved directly from the SSDs in the SteelFusion Edge, via its Advanced Tiering Cache technology. High Read IOPS applications benefit greatly from the SSDs performance.
All local applications writes are acknowledged at the BlockStore write cache, eliminating the need to have the writes responded from the data center. The writes changes are deduplicated and compressed, and then asynchronously delivered to the SteelFusion Core to the datacenter storage, riding on the very efficient BlockStream protocol with the help of the SteelHead appliances on both sides.
The “Read Ahead, Write Behind” philosophy is maintained beautifully even though there is a wide distance between the datacenter and the branch. This is absolutely crucial in delivering the performance and the experience to the branches applications.
BlockStream builds and maintains the branch experience. I cannot stress this enough because the deeper the adoption of this technology, the more successful the organization’s converged data strategy will be. And the SteelFusion technology has made it looked simple. It is not an easy task, and as Einstein would say, “Everything should be as simple as possible, but not simpler.“
In addition to that, BlockStore performs intelligent predictive block pre-fetching. By analyzing the patterns and the frequency of storage blocks requested, it identifies and retrieves these blocks in advance to the Edge device. This is further enhanced with the deduplication technology and optimization by the SteelHeads, reducing the amount of blocks transferred and increasing the performance and experience. With this technology combination, branch applications can boot off the WAN. Riverbed recommends their Turbo Boot software to be installed on Windows machine to deliver only the files required for WAN booting.
Another initiative greatly boosted by Riverbed SteelFusion is Business Continuity and Disaster Recovery. The question on everybody’s mind is often related to the failure of the WAN. The disruption of network communication between the datacenter and the branches would also stop the branch applications too, right? Well, NO!
Because of the various techniques and advanced configurations in the SteelFusion technology, branch applications continue perform as usual. Writes are continually acknowledged locally and reads are fast from the cached blocks in the SSDs of SteelFusion Edge. The “dirty blocks”, the blocks that have not synced with the storage LUNs at the datacenters are shored in the allocated transient memory segment of the Edge device, awaiting WAN continuity. Once the network service is resumed, all these “dirty blocks” are flushed back to the datacenter, closing the entire data cycle.
There are so much more SteelFusion advanced features to share and this entry simply cannot fit all of them. I urge you to go search the web for SteelFusion, and of course, they are always available at Riverbed’s own website.
It is important that data architects take the prerogative to delve deeper when considering a branch convergence data strategy. The data strategy must never be a hodgepodge solution, because the storage infrastructure is still pretty much a dark art domain. Any attempt to disturb how data is delivered from an enterprise storage architecture to the end applications could result in data corruption and affect the data integrity.
That is why Riverbed SteelFusion has delivered a masterclass technology that not only abstracted and virtualized the storage vendors’ unique logical storage structures, it has made it logically closer and seamless to the branch applications from a performance and experience perspective. Riverbed positions this as the solution that separates both compute and storage platform while enabling local performance and I/O response, regardless of location or distance.
We all know end users of applications are a difficult bunch to please, and any lag in applications delivered via a remote distance will ruin the user experience. As I have said in my previous blog, the technology adoption is inverse to the user experience. Riverbed SteelFusion breaks down the barriers of branch technology adoption and can only bring greater data convergence success in any organization’s inclusive data strategy.
This technology, the RiverBed SteelFusion, to me, is one true data convergence architecture.
I’m one of your silent followers and i totally agree. However what I’m missing is a real cloud storage gateway like functionality as it would allow for more options e.g. NFS and SMB protocol to be provided at the branch offices. By using local policies you can now move data to cloud storage incl. S3 etc,, backend NFS infrastructures or even use the existing central Block infrastructure. What is your opinion on Cloud Storage Gateways or Cloud Storage Controllers?
Thanks for your support. Which country are you based in? I am always interested to know.
I have looked at Cloud Storage Gateways for a while but I cannot claim to know much about it. One reason is there is little known implementation in my part of the world in Malaysia. CSGs tend to be part of the solution offerings out of Amazon S3 or Microsoft Azure, in which the well-known ones would be NetApp Private Storage, Microsoft StorSimple, Nasuni Global Filer, and probably HDS Hitachi Data Ingestor (HDI). I am sure there are plenty more out there.
The challenge to offer NAS via a CSG is the SMB and NFS protocols themselves. The ubiquitous versions NFSv3 and SMB 1.X are just not “cloud-friendly”, resulting in high latency and poor adoption. Solutions like Riverbed SteelFusion, which I have just blogged, could be further developed to support NAS protocols, but I feel that it could be a futile effort. The protocols aren’t just efficient.
However, I may be biased to say that SNIA’s CDMI (cloud data management interface) could be something to be considered. However, in its present design and specification, *performance* isn’t very high on the list of objectives. And I tend to link performance to adoption, together with ease of use. Technology adoption can only be successful if ease-of-use and performance are good.
Thanks for giving me the idea to research what is next! I will do some research (workload permitting) to learn more and share with you later.
Till then, I wish you all the best!
Pingback: Technology Short Take #45 - blog.scottlowe.org - The weblog of an IT pro specializing in virtualization, networking, cloud, servers, & Macs