When implementing a virtual SAN, avoid “rip and replace," and watch out for extra overhead.
Momchil “Memo” Michailov, CEO of Sanbolic, tells users to keep it simple.
“Deployments requiring meta-data controllers, region ownership and any other ‘traffic cop’ approaches should be avoided, as these represent a single point of failure,” he said.
Michailov also recommends: Don’t implement a software-defined storage platform that requires a "net new" or "rip and replace" approach.
“Virtual storage platforms should augment an organization’s existing infrastructure,” he said.
Greg Schulz, an analyst with StorageIO Group, is of the mindset that a virtual SAN may not be right for everyone.
“Just because you can build, deploy, use or do something does not mean that you should or that it is the best fit for everything, and there is lots of potential for vSAN; however, also keep other options in mind,” said Schulz.
“Will you spend more time configuring, managing and troubleshooting your vSAN with lower-cost, off-the-shelf, white box hardware and tools vs. leveraging a right-sized storage system (or multiple for redundancy)? Keep in mind the extra workload that will be applied to a physical machine (PM) server in terms of memory, IO, CPU by having it also support a vSAN.”
Steve Houck, COO of DataCore Software, recommends that organizations take a close look at ongoing virtualization strategies and the general direction of IT as a first step.
“Don’t implement a virtual SAN solution without understanding how it fits into your broader storage virtualization strategy,” said Houck. “Otherwise, you could end up with mutually incompatible approaches for different parts of your infrastructure.”
Many begin implementation of a vSAN with the idea of keeping it wholly internal. However, it is quite possible that things won’t pan out that way.
“Consider the likelihood that the initial internal virtual SAN will grow into an external SAN when the number of host nodes increases,” said Houck. “Assess how the near term solution will accommodate your near-future expansion.”
Another important consideration is how your choice of a virtual SAN product applies to other hosts, which may be using a different hypervisor, or no hypervisor. After all, several of your existing applications may remain un-virtualized, or may be more economically served by a different server virtualization package. “Think about the hypervisor options and portability of data across them,” said Kate Davis, Product Marketing Manager, HP StoreVirtual. “Also watch out for emerging technologies and software-based technologies as they will be the first way to take advantage of new hardware as it comes to market.”
Regardless of the virtual SAN deployed, pay attention to making sure that the environment is resilient. This must include the fact that it is backed up, and also protected outside of the vSAN, advised Schulz.
In addition, Schulz raised concerns about larger environments where server CPU, memory and IO are already busy as a result of consolidation efforts. By adding storage virtualization on top, you will be placing more workload and demands on those systems.
“Leverage software IO caching solutions to help offset or offload performance bottlenecks along with SSD cards and drives, as well as look into enterprise class Solid State Hybrid Drives (SSHD) that can provide up to 3x the performance of a regular 15K HDD for those that need read boost,” said Schulz.
Some vSANs will mirror easily while others will exact a severe performance hit, particularly as the virtual SAN expands.
“Evaluate the performance impact of mirroring between nodes from the outset, especially as the cluster gets bigger and more replicas must be kept synchronized,” said Houck.
Some vSANs are wholly proprietary or are tied to one hypervisor or one set of tools. This may not work out well in a heterogeneous enterprise.
“Look for nuances in the virtual SAN implementation that preclude you from using 3rd party tools to supplement its native capabilities,” said Houck. “Also, does it behave like standard disks?”