I have been discussing Software Defined Storage for a couple of months now and I have noticed that many of you are passionate about this topic as well. One thing that stood out to me during these discussion is that the focus is on the “storage system” itself. What about the network in between your storage system and your hosts? Where does that come in to play? Is there something like a Software Defined Storage Network? Do we need it, or is that just part of Software Defined Networking?
When thinking about it, I could see some clear advantages of a Software Defined Storage Network, I think the answer to all of these is: YES.
- Wouldn’t it be nice to have end-to-end QoS? Yes from the VM up to the array and including the network sitting in between your host and your storage system!
- Wouldn’t it be nice to have Storage DRS and DRS be aware of the storage latency, so that the placement engine can factor that in? It is nice to have improved CPU/Memory performance, but when your slowest component (storage+network) is the bottleneck?
- Wouldn’t it be nice to have a flexible/agile but also secure zoning solution which is aware of your virtual infrastructure? I am talking VM mobility here from a storage perspective!
- Wouldn’t it be nice to have a flexible/agile but also secure masking solution which is VM-aware?
I can imagine that some of you are iSCSI or NFS users and are less concerned with things like zoning for instance but QoS end-to-end could be very useful right? For everyone a tighter integration between the three different layers (compute->network<-storage) from a VM Mobility would be useful, not just from a performance perspective but also from an operational complexity perspective. Which datastore is connected to which cluster? Where does VM-A reside? If there is something wrong with a specific zone, which workloads does it impact? There are so many different use cases for a tighter integration, I am guessing that most of you can see the common one: storage administrator making zoning/masking changes leading to a permanent device loss and ultimately your VMs hopelessly crashing. Yes that could be prevented when all three layers are aware of each other and integration would warn both sides about the impact of changes. (You could also try communicating to each-other of course, but I can understand you want to keep that to a bare minimum ;-))
I don’t hear too many vendors talking about this yet to be honest. Recently I saw Jeda Networks making an announcement around Software Defined Storage Networks, or at least a bunch of statements and a high level white paper. Brocade is working with EMC to provide some more insight/integration and automation through ViPR… and maybe others are working on something similar, so far I haven’t see too much to be honest.
Wondering, what you guys would be looking for and what you would expect? Please chip in!
Just wondering, haven’t solutions like Xsigo (Oracle) and Next I/O (now Samsung) been very close to achieving this? Or are you talinking about something else entirely?
How well do they integrate with the existing storage systems and with platforms Willem? On top of that, it requires, Xsigo as I don’t not Next, specific hardware right and is just 1 vendor… I am talking more generic. What about the others?
Depends on your vision of the future. For me, with hyper-converged solutions, the storage array is a dying breed for production data. They will remain for archive and large pool storage, but primary compute is going to have localized and replicated storage without the need for a dedicated storage network nor array.
Of course, the end goal is to define an instance with compute, storage, and network policy and have all components orchestrated. However, this level of automation can only be achieved by extremely well planned infrastructures with defined units of capacity. We may well get there, but that day is not now.
For SDS to truly become effective, the storage arrays will almost have to become self aware. We will need an API that can receive parameters like logical object (VMDK or block), performance criteria, segmentation requirement, ha requirement, prioritization, and much more. These metrics will be parsed by the array logic to establish disk groups, carve storage allocations, and maintain performance while monitoring for SLA violations.
I agree with Willem to a degree. We missed a significant opportunity for the next generation. If someone would integrate Nutanix/Simplivity/Scale with a Xsigo or similar interconnect and develop a single manager… I have checks to cash and SDDC to deliver!
I agree that converged definitely has a future, but I wouldn’t expect everyone to head in to the same direction and it is going to take years before many of us can head down that path. Simply too many have invested in expensive storage systems already.
By the way, with regards to those types of APIs. I believe that with VVOLs we are at least heading in to that direction. Allowing for granular SLOs.