With the increased exposure of virtualization and the popularization of platform-level high availability solutions because of it the need and awareness of high availability storage has come to the forefront of all of IT and the SMB realm in particular. Storage has become, not surprisingly, the most challenging aspect of virtualization today.
Most people investigating high availability storage solutions are aware of replication between SAN or NAS devices but are not aware that local storage can be replicated synchronously as well allowing for the same high availability practices without the need for external storage devices. In fact, Replicated Local Storage (or RLS) is (and must logically be) the same technology used by a SAN or NAS to achieve high availability. RLS is the underpinning of all high availability storage solutions, it is simply that we only refer to it by this name when we are looking at a device as being “local.” If we were working on a SAN or a NAS then RLS would refer to its own replication technology. When looking at a server connected to a replicated SAN we think of that replication as being non-local. Local is a matter of current perspective. At a technical layer all replication is RLS at the end of the day.
RLS technologies are popular are certain operating systems such as Linux where DRBD is native and accepted into the kernel. The FreeBSD project has, in recent years, introduced its own native RLS technology known as HAST. Windows does not have a native RLS option today. Linux and FreeBSD lead the RLS charge in regards to common operating systems used in the SMB and are driving the industry forward with broader adoption of these technologies.
In virtualization we see many other approaches taken to provide RLS for virtualization platforms. KVM, which is built on Linux, and the Xen family (including Xen, XenServer and others) which relies on Linux leverage DRBD for their own RLS. The VMware ecosystem uses a replicated VSA approach with popular options being VMware’s own VSA product and HP’s VSA product. Both of which use a virtualized, replicated NAS appliance to provide RLS to the platform. On Microsoft’s HyperV the same is accomplished by the use of Starwind’s replicated SAN platform that behaves, essentials, the same as a VSA.
RLS is rapidly becoming more and more important as it scales well in small scale virtualization taking what has long been available as a niche clustering technology and pushing it into the mainstream. Before high availability for virtualization was popularized in the SMB world these technologies were almost exclusively used for small scale UNIX high availability clustering. They were important technologies and often used but received little industry attention as they were an “under the hood” detail of some UNIX systems. Today, with the rapid uptake of high availability for virtualization, RLS has gone from a niche technology to one of the most key and appropriate technologies for nearly any SMB wishing to achieve high availability for their virtualization platforms.
Good points, alas software based replication is not without its faults. If I’m only concerned with file level replication then it can tend to be a simple to deploy tool for a site to site level replication of specific user data, but if I need to replicate an entire workload, ie the virtual machine itself, then the available solutions out there are a bit wanting in terms of functionality.
Second, you can end up replicating data multiple times if the underlying solution doesnt support native deduplication and compression. That is simply a waste of bandwidth and makes the replication process much longer than it should be.
As solutions like DRBD are completely synchronous deduplication would not be needed as any deduplication at the source end would be replicated at the receiving end. The synchronous nature makes that not a factor since the two sides need to have their writes done at the same time. The nature of being needed on one end means that it is needed on the other.
Compression can be done, although I’ve never seen anyone try this, but the risk there is that you add latency and latency, more than throughput, is the key concern with synchronous storage replication. So even if there was a good option I think it would be very rare to want to implement it. Providing for GigE or even 10GigE between nodes is trivial in a two node replication model so it is pretty rare that throughput is of concern.
I’m pretty excited that one of the vExperts jumped in here! Thanks for commenting!!
Just found your site today, lots of good stuff there. I’d be curious about your feedback on what we are doing at SimpliVity. I think we offer an attractive platform for the SMB/MID markets that help address a lot of the pain points that the market segment. Not trying to be all “salesy” but its a pretty cool piece of technology.
http://www.simplivity.com/
Very helpful.. thanks alot for sharing knowledge.