Many businesses hold off implementing a new feature in vSphere until a few updates have passed to reduce the potential for problems. VMware Virtual SAN has only been available since March of 2014, but some companies whose lifeblood depends on reliable data stores for production VMs are already implementing VMware's first foray in software-defined storage.
Pea Soup Hosting is a fledgling cloud services provider based in England. The company started in April and runs its hosting platform on vCloud Suite 5.5 to offer DR as a service and backup as a service.
Harold Buter, CTO and co-founder at Pea Soup, has been working with VMware products for more than 10 years and saw VSAN as a way to add flexibility while reducing capital expenses.
SearchVMware spoke with Buter about his experience running a cloud business on VMware Virtual SAN.
Are you using the self-service portal functionality in vCloud Suite?
Buter: Yes. We are developing a portal that not only has the vCloud portal, but also has integration with our monitoring software, backup requests and the support desk to deliver a single view for our customer. We want to simplify the cloud and not only have that single pane of glass on the desktop, but also on a tablet, so customers can provision virtual machines, do backups and restores -- whatever they need to do from any device.
The cloud services market is getting crowded. VMware has vCloud Air. You're running on a VMware platform. How do you distinguish your company?
Buter: One of the differentiators is we work with VMware so customers can have their services run in vCloud Air and have services [in our data center] -- or vice versa.
Not everyone is using only VMware products, which means our customers can use a disaster recovery product like Zerto. Zerto is an absolutely fantastic tool with very good DR features with low RTOs and RPOs. With vCloud Air, you have to stick with Site Recovery Manager [for DR] or VDP [for VM backup]. We're a bit more bespoke than VMware.
Was the option to use VSAN a factor in how you decided to develop your storage environment?
Buter: Yes, for us, VSAN was the kick-starter. When we were working at another provider, we spent a lot of money on shared storage. If you want to have a proper cloud service with lots of I/O, then you have to spend serious money. Using VSAN, it enabled us to start small and grow when we need it. We can still deliver the same kind of performance and scalability.
How confident were you using a relatively new feature as the foundation of your production environment?
Buter: I've seen a lot of products come out from VMware. I know they have good quality assurance and do a lot of testing. I've also been following the key people within VMware who were testing it. VMware won't release something that is not good.
I've burned my hands with different storage products before. VMware cannot afford to release a critical data center product that does not work. I trust them enough to boot their product in my primary production environment.
There are things missing in the VSAN product set, but nothing critical I need at this stage. For instance, the metrics. How many IOPs is that data store using? But I can get that information elsewhere.
A Reddit user described a situation where the VSAN cluster in a production environment went down. Was that something that concerned you?
Buter: I saw the article. They were using Dell servers and were using [Dell] H310 [raid] controllers, which have a very low queue depth.
The queue depths are very important, because if you have a lot of traffic going through different components, then the queue depth will actually increase constantly. If you hit that limit, then suddenly you get massive latency and your system will start to fall down.
We did check our queue depth when we saw the article. That user had a queue depth of 25. I have a queue depth of 956 per controller.
What are your overall impressions of VSAN?
Buter: As a storage geek, I find it too simple. [Laughs.] It is very easy to use.
I had a physical disk failure a few months ago, and we replaced disk without an issue. VSphere and my other monitoring software notified me we had a disk failure, so we replaced the disk and had no issues.
VSAN is so simple to use. I remember when I used to work with six or seven different products to manage one SAN. Now we can just check a box and that's it.
For me, it's great because I'm running a new company and I can save money on people and other things just because VSAN gives me an infrastructure that is easy to understand. I don't need a degree in storage.
It appears VMware will release VSAN 2.0 in the next vSphere. Is there any functionality you would like to see in future versions?
Buter: The most important feature for me is seeing performance metrics. It just makes my life easier. That's what I'm missing. Also, the integration inside vCenter Operations Manager (vCOPS) -- so when I open up vCOPs I can see the details of my VSAN: how it is performing, how the VMs are performing. Those figures are what I'm missing today.
I'm not missing any functionality with what I'm used to in a normal data store. At the end of the day, it is just a data store for me.
What lessons have you learned with VSAN that other companies should keep in mind?
Buter: Make sure you have a build document. Do your due diligence on everything. As we saw with the user on Reddit, he could have prevented that situation with a larger queue depth.
Just make sure you always check VMware's HCL before acquiring any hardware. Use the [VMware] support when you need [it].
While there is a lot of talk about cloud, many companies are hesitant to move workloads out of their data center. Why is that?
Buter: The resistance comes from too much marketing fluffiness. You need to be open and clear what your cloud provides. Where is your data center located? What kind of regulations do you provide?
I think the big problem is when people talk about cloud, they're thinking about the Amazons of the world. The customer never knows where their data is and what the rules of engagement are.
When I talk to technical people, we tell them we build the infrastructure, but it's up to them to manage this virtual data center. So there [are] no worries about job loss. We just take away the task of maintaining the hardware of the infrastructure.
The cost of using the cloud will come down significantly in the future. Once the price gets low enough, it will be easier for companies to decide to go there. Why keep hardware in own data center and spend a lot of money on it when you can have that infrastructure in the cloud? You just pay a monthly fee.
Another thing that is very important for cloud computing is transparency and being able to migrate the user to another provider. I'm more than happy to take on a customer and have them replicate to the VMware cloud or to another cloud provider to cover a worst-case scenario. We've seen it too many times that customers have to deal with downtime when running on Amazon.
Some of the bigger cloud providers had highly publicized downtimes recently to patch vulnerabilities. Isn't virtualization supposed to prevent these issues?
Buter: I find it wrong that a cloud provider has to have this global downtime to patch their systems. I've patched my systems for Shellshock, and no one had to know. If you architect your cloud safely, there's no need to notify your customers.
Luckily, with the VMware side of things, ESXi was not vulnerable. We just had to reboot a few VMs, not our whole infrastructure.