Who needs Cloud Storage – Violin delivers pay as you grow Flash

One of the challenges that every IT planner is trying to figure out is what size, both in terms of capacity and performance, storage system they should invest in. They need to make sure that the storage system will not only meet their upfront but long term capacity needs as well. An incorrect calculation can lead to the purchase of an additional storage system and all the management overhead and costs that comes along with it.

To avoid this situation, many data centers are looking to scale-out storage or cloud storage to meet the challenge of business unpredictability. The problem is that both of these solutions have their downsides. Scale-out storage creates some initial sizing concerns of its own, and it can have per workload performance limitations. Cloud storage can start at almost any size, but there is a latency concern, as well as the ongoing cost of paying for the same storage capacity over and over again.

Windows Focused All-Flash

Violin’s Microsoft Windows focused solution is the Windows Flash Array. Introduced this past April, this system places a Windows Server directly inside a Violin Memory Flash Array. It provides SMB Direct for Microsoft Applications, supports RDMA to act as a storage super highway and enables native file server functions. Remote Direct Memory Access (RDMA) capability. Network adapters that have RDMA can function at full speed with very low latency, while using very little CPU. For workloads such as Hyper-V or Microsoft SQL Server, this enables a remote file server to resemble local storage.

The Windows Flash Array also leverages additional features of Windows Server such as encryption, deduplication, live migration, mirroring and the ability to create a scale-out architecture. The net is an incredible speed boost for Windows applications and the system positions Hyper-V to be a legitimate enterprise play.

Updated Already

In just a few months after its initial implementation, Violin claims they are already seeing excellent market traction and capturing revenue customers. To keep the momentum going, Violin has already announced an update that features pay as you grow pricing, 4 new capacity models, InfiniBand connectivity and NFS 3.0/4.1 support.

Pay As You Grow – An All-Flash First?

While each of these new capabilities has value, pay as you grow pricing is going to get the most attention. It allows the system to be delivered at a much higher capacity level than what is needed initially and then have that capacity turned on and paid for as it is needed. This matches how customers tend to consume flash solutions. Flash is first brought in to solve a particular performance problem for a specific application. Then when that problem is addressed, the IT team starts to look for other use cases. But the challenge is, they may not have enough capacity to bring those other use cases into the all-flash fold. With Violin, they can simply turn on a license and they are ready to go.

The other capabilities introduced with their April announcement, of course, will also have appeal. Infiniband provides another high performance networking option and NFS potentially allows mixed hypervisor environments to leverage the Windows Flash Array.

Storage Swiss Take

Violin is doing more than taking the Windows Server market seriously, they are expanding the use case for Windows Server while at the same time changing the performance perception of applications based on what the platform can deliver. This latest round of announcements positions Violin to enter into a broader section of the Windows market with a solution that presents a viable alternative to scale-out and cloud based storage solutions.

Violin is not a client of Storage Switzerland

Click Here To Sign Up For Our Newsletter

George Crump is the Chief Marketing Officer of StorONE. Prior to StorONE, George spent almost 14 years as the founder and lead analyst at Storage Switzerland, which StorONE acquired in March of 2020. In his spare time, he continues to write blogs on Storage Switzerland to educate IT professionals on all aspects of data center storage. He is the primary contributor to Storage Switzerland and is a heavily sought-after public speaker. With over 30 years of experience designing storage solutions for data centers across the US, he has seen the birth of such technologies as RAID, NAS, SAN, Virtualization, Cloud, and Enterprise Flash. Prior to founding Storage Switzerland, he was CTO at one of the nation's largest storage integrators where he was in charge of technology testing, integration, and product selection.

Tagged with: , , , , , , , , , , ,
Posted in Briefing Note
One comment on “Who needs Cloud Storage – Violin delivers pay as you grow Flash
  1. It’s unclear to me that the pay-as-you-go strategy changes anything for those purchasing flash storage for clouds. In fact I would suggest it could turn out to be more expensive (if you turn on the additional capacity) and less efficient. What you describe is useful for smaller discrete use-cases that grow. A database, or some other application utilizing a single array and even there growth ends up making this solution much more expensive than existing approaches. Those building out clouds do not benefit from array pay-as-you-go. One example is of a cloud provider aims at delivering storage to customers. From that perspective you can look at it differently – they want to inexpensively grow their clouds and they *typically* would not want array-based pay-as-you-go… they want a cloud-oriented pay-as-you-go. The Violin Memory array-based pay-as-you-go model doesn’t fit this need. Few cloud providers or enterprise cloud builders are going to buy multiple lightly loaded arrays. Buying a fully loaded scale-out array is (a)much less expensive and (b)fits the cloud provider model better. I think for small efforts and smaller companies the *array* pay-as-you-go model may be attractive. For cloud providers and those building enterprise clouds, incremental, inexpensive growth makes better sense. Which means ideally smaller form factors with denser amounts of flash storage. In that sense, WFA makes less sense and clustered arrays with large scale-out potential may make better sense. Four WFAs with 70 TB get you 280 TB in about 12 RU. But the scale-out stops there at only 4 arrays (See : http://www.enterprisetech.com/2014/04/22/violin-scales-back-windows-flash-array-now/ ) Another example, the new Concerto 7000 provides 280 TB in 18RU – again scale-out is limited. Comparing to other companies such as Kaminario and SolidFire this looks remarkably unattractive. Compare that 280 TB in 18RU with a SolidFire SF9010 which offers 623 TB of flash storage in 18RU. In fact to get almost the same amount of flash – 277 TB of flash storage in the SoldFire SF9010 only requires 8 RU. And SolidFire can scale upwards toward 100 nodes. Consider the SolidFire approach a *cloud* pay-as-you-go model. When you need incremental growth you can buy an extra 1RU node with roughly 35 TB. Unlike the array-oriented pay-as-you-go it is not scale-out limited nor do your costs escalate for the same amount of flash if you *turn on licensing* for the additional capacity in Violin Memory’s array-based pay-as-you-go model (see: http://searchsolidstatestorage.techtarget.com/news/2240224595/Violin-storage-adds-WFA-models-pay-as-you-grow-option ). The reality is if I’m building out a cloud then a cloud-oriented pay-as-you-go model seems more focused on building out clouds around nodes and care much less about whether the array has 15 TB of unused capacity that I can turn on. In fact that becomes a cloud inefficiency. Each RU becomes less dense in flash storage. Reality is if I’m building a cloud it is more efficient for me to have each scale-out node maxed-out because I’m already paying for the rack space, power & cooling, management of the unit, etc. Especially in the case of 6000 class arrays which have healthy power consumption demands and each have larger 3RU space footprints. There are obviously going to be some exceptions but in general if I’m building out a cloud, cloud-based pay-as-you-go (meaning incremental growth by adding nodes) is going to be much more useful and efficient than array-based pay-as-you-go and I won’t get hammered later by paying much higher costs for the same amount of flash if I choose to turn on that extra capacity.

Comments are closed.

Enter your email address to follow this blog and receive notifications of new posts by email.

Join 21,787 other followers
Blog Stats
%d bloggers like this: