carloscastilla - Fotolia
Six software-defined storage architecture mistakes to avoid
SDS architecture is beneficial for many companies, but organizations making the switch can miss important steps, such as capacity and migration planning.
Companies considering software-defined storage architecture position themselves to receive a number of economic and business benefits, including smarter interactions between workloads and storage, agile storage consumption and real-time scalability.
Yet, launching an SDS rollout also opens the door to a series of potential pitfalls that can delay or even fatally derail final adoption.
"SDS is philosophically a completely different approach to managing storage," said Shawn Smucker, product manager of the office of the CTO at data protection software provider Commvault. "It requires transforming one's mindset from hardware being an important key player in the enterprise to it only playing a supporting role."
Smucker said companies encountered similar challenges when they began transitioning from dedicated physical servers to a virtual infrastructure.
"While virtualization is now widely adopted, many were hesitant to implement it when it first entered the market," he said.
So, before setting any SDS strategy into motion, make sure you have considered and addressed these six important steps.
Anticipate possible internal opposition
All decisions have two sides, and choosing software-defined storage architecture is no exception.
"You're likely to get push back from your existing storage team, but most of it will be based on zealotry and bias rather than any real understanding," explained Andrew Hatfield, cloud storage and big data practice lead for open source software provider Red Hat. "You can't really blame them; they've built their entire career around one or two vendors, and now, the world is changing."
To stifle opposition, Hatfield suggested starting small by selecting a problem that software-defined storage architecture will easily solve and using an existing x86 Intel server vendor to achieve a small initial success.
"Disrupt from the edge, and slowly work your way in," Hatfield said. "Don't try and change the world overnight."
Consider an appliance
Depending on the level of in-house expertise, an SDS appliance that ships with prepackaged software and hardware may make the most sense.
"Appliance models not only simplify execution and minimize support complexity, they typically enable a higher level of uptime and performance since the vendor has 'tuned' for the configuration," said Bob Madaio, vice president of infrastructure products and solutions marketing for Hitachi Vantara.
"Organizations can run into trouble optimizing, scaling and repairing software-only solutions if they do not have a skilled IT storage team."
Pay attention to scalability
Software-defined storage architecture adopters should understand how individual volumes scale in capacity, performance and latency, especially if data is spread across nodes, Madaio said. Another factor to consider is the amount of media that can be added. For instance, if you're looking to build an all-flash platform based on nonvolatile memory express, how many NVMe slots does the platform have? Does it have enough CPU and memory available to support workload needs? Are there sufficient high-speed interfaces on hand to serve the NVMe devices?
"Missing these items can result in poor performance [and] limited future-proofing over time as workloads grow," Madaio said.
Plan for data migration
When implementing SDS, one thing adopters often neglect to check is data migration.
"This is an area where many SDS solutions can break down," Madaio said. "For new workloads, this is not an issue, but for customers trying to transition off of existing arrays, it has been known to create challenges both in 'time to execute' and in disruption to applications."
For companies migrating workloads over to a new software-defined storage architecture, it's important to verify that the vendor selected offers the tools and services needed to enable a smooth migration.
"Be very careful to understand how transparent the migration is and how long it takes," Madaio said. "Migration can take time, and if the process is not fully transparent to applications, then there can be issues."
Have realistic expectations
SDS is designed to mimic the benefits of public cloud services within an on-premises data center, but it's entirely possible that rapid innovation in the public cloud market will quickly render your software-defined storage architecture much less competitive in terms of scalability, cost economics or available services.
"Similarly, you may find that, within your own environment, SDS adoption isn't delivering on the anticipated benefits," said Kong Yang, head geek at SolarWinds, an enterprise IT infrastructure management software vendor. This is especially common when organizations achieve SDS by way of hyper-converged appliances, he noted. "Without proper planning and forethought, it's not uncommon for businesses to overinvest in hardware and end up with significant amounts of underutilized resources."
Understand integration issues
Although SDS brings great value, this benefit typically comes at the expense of easy integration.
"Users need to be prepared to evaluate/procure the underlying hardware and OS platforms that best fit their requirements and marry that to their SDS selection," said Charles Foley, senior vice president of Talon, an SDS provider. Often, this role is played by increasingly SDS-savvy integrators, as a service offering.
"While there is a charge, it's usually less than the 'proprietary margins' from legacy storage vendors and still carries the inherent flexibility of SDS," Foley noted.
The pitfalls of software-defined storage architecture depend on your readiness to move to a new operating model, observed Avinash Lakshman, CEO and founder of SDS vendor Hedvig.
"If you're expecting SDS to simply be a newer, faster mousetrap, then the pitfall is you won't see a proper ROI."
