Software Defined Anything–The Controller’s Role

In my previous Software Defined Anything post I explain that a “Software Defined Something” (SDx) differs from the non-SDx model in that the underlying physical devices are abstracted from the consuming systems by a layer of software called a controller. I was reading a great article about Software Defined Storage and got to thinking that I did not fully describe the scope of the controller’s role. The article encapsulates very nicely what a storage controller needs to provide so I’ve generalized this to cover the scope of SDx:

I’m taking credit for a new term here – Hardware abstracted in a Software Defined Data Center should be called Hideware. No?

• Automated, policy-based provisioning.
  • Given that you no longer see the physical device you need a way of programmatically creating a virtual instance and them communicating with it. In the non-SDx model you’d go and plug in a router, disk drive, blade, etc. and then use its proprietary interface. In the SDx model you need to be able to instruct the controller to create you an instance to utilize and then communicate with it via the controller's interface. Ideally, this should be done based on policy not explicitly. E.g. the consuming system says that they need a highly available storage device, the controller then translates that into a specific physical implementation which allows the actual implementation to be changed without needing to make changes to the consumer.
• Predictable quality of service.
  • The policy above is going to encapsulate a Quality of Service including levels of availability, speed, security, etc. If I select a policy that specifies five 9s uptime then the controller will have to select the most appropriate physical implementation (obviously the mainframe in this case). The real magic here is allowing the controller to understand the specifics of the QoS objectives stated by the consumer and know how to enforce them using the available resources.
• End-to-end monitoring.
  • In the SDx model I might end up with a blend of physical devices supporting my system. In theory, some of my data might reside on a local physical device and some might be out in the cloud. Implemented correctly, the SDx controller layer will hide this actual implementation from me but it must give me a way of monitoring the logical manifestation centrally. This is especially important in any one classification of device – e.g. I want to monitor all storage centrally or all networking centrally.
• Multi-site management.
  • Supporting multiple sites isn’t itself a prerequisite to claim to be a SDx system but the early customers of SDx are challenged with managing very large implementations and expect the controller to be able to manage, monitor and report on systems across physical locations.
• Converged hardware platform.
  • Typically converged hardware/platforms are systems where the storage, computer, network, etc. are combined into a single unit. In the context of Christos’ model I believe that he is more focused on the ability to use commodity devices under the controller. You have to be careful what you mean by “commodity” in this case. We all know that you can buy a 2TB drive from BestBuy for less than $100 but you probably don’t want to bet your business on it.
• Converged administrative model.
  • This is a harder one to generalize across SDx. No doubt you would want a single admin model for all storage, one for all networking, etc. but I am not sure that it is mandatory to unify admin across these devices although it would be a great benefit. The SDx model certainly makes it more likely that you’d be able to do it given that you no longer need to aggregate the administration functions across 12 storage, 4 networking and 8 compute vendors – just across 3 SDx controllers. 

Comments

[Nisha W]

This is one of the best article on software defined storage. You have explained every point in detail. I am a blogger works with clogeny http://clogeny.com/, Cloud Computing Service Providers