Implementing SDI

Software-defined infrastructure is one of the hottest topics in IT today. Most IT staff already have seen the benefits of automated management of virtual servers and their underlying platforms. Let’s face it, the cloud would not have happened without orchestration and the other tools that surround it.

Cloud service providers have already extended that automation to their network and storage infrastructure, though, of course, in proprietary and private ways. They aren’t sharing too much because it’s part of their secret sauce.

Even so, the broader automation approach has been taken up by the IT industry and labelled SDI, for software-defined infrastructure. We are still in the early rollout phase of SDI and it’s useful to separate SDN, the networking initiatives, from SDS in storage.

SDN is in part an effort to automate network management, allowing IT to use policy management approaches that delegate day-to-day VLAN control to their departmental-level users. Another factor is the sense that the market needs inexpensive alternatives to the big iron switches and routers seen from Cisco, F5 and the likes.

SDS has similar aims in reducing implementation costs, moving hardware platforms from proprietary, and highly marked-up, solutions to low-cost COTS-based appliances. In both cases, the value-add of data services software is envisaged as unbundled from the hardware and instantiated in virtual machines or containers to achieve agile and scalable solutions.

SDN is much further along than SDS and users of the approach are seeing the touted benefits turning into reality. Both the hardware and software ecosystems are evolving rapidly and solid, tested solutions already exist in production environments. It’s clear that the concept works well and that saving in acquisition costs and manpower is significant.

Mainstream support exists, though it pays to look beyond old-styled gear labelled as “SDN” to new barebones switch solutions that can support software from a variety of startup sources. A good rule of thumb is that, if the data services and features code is designed to only run on the vendor’s switch hardware, as opposed to in the server farm, it isn’t SDN.

Perhaps the most-advanced SDS product is open-source object storage leader Ceph. Ceph can be configured to run on virtual instances in the server farm, with simple storage nodes acting as the distributed storage. This has even been demonstrated with massive numbers of Ethernet disk drives by WDLabs

Other players are entering the market, while the expansion of storage tiers to include server-based non-volatile DIMMs and virtual SAN storage pools assures that interest and evolution will be strong and rapid.

One major focus of anyone implementing SDI is the choice of a good orchestrator and configuration management suite. This is crucial to a satisfying roll-out and the avoidance of a painful change of trajectory later. Because these tools are the focus of most of the policy-creation efforts and the training and operational processes that follow, having to change horses impacts operations both in IT and in at the departmental level.

The tool you choose should be capable of converting your hardware platforms into a normalized resource pool. This implies an easy method for the tool vendor to extend management to new platforms in what will be a rapidly evolving hardware space. It goes without saying that a vendor-agnostic tool is the optimal solution.

Additionally, the best practices knowledge base that the platform vendors and software companies have created is perhaps your most valuable resource, especially during installation. Having this knowledge built into the tool will dramatically reduce errors and optimize performance and reliability in operation.

Building out configurations should be in phases. There is no need to buy all the expected gear for several years of capacity in one shot, since SDN should make mix and match relatively easy. Certainly, though, for the first phase, the gear bought should be homogeneous … that will reduce the training and startup efforts a lot!

Look for an automation software vendor with a very open attitude to sharing information. This will make avoiding mistakes easier and speed up that crucial first phase. A cluster of documents that focus around your specific environment and challenges should be on the check list.

Finally, pick a software vendor that knows what they are talking about … what your likely issues are and how they can address them. In a very real way, you are giving them the keys to your success with your first SDI project.

SDI is real and imminent. Winning solutions are possible!

Posted in: