Anyone who manages or architects a virtualisation environment battles against storage performance at some stage or another. If you run into compute resource constraints, it is very easy and fairly cheap to add more memory or perhaps another host to your cluster.
Being able to add to compute incrementally makes it very simple and cost effective to scale. Networking is similar, it is very easy to patch in another 1GB port and with 10GB becoming far more common, network bandwidth constraints seem to be the least of your worries. It’s not the same with storage. This is mainly down to a cost issue and the fact that spinning hard drives haven’t got any faster. You can’t just swap out a slow drive for a faster one in a drive array and a new array shelf is a large incremental cost.
Sure, flash is revolutionising array storage but its going to take time to replace spinning rust with flash and again it often comes down to cost. Purchasing an all flash array or even just a shelf of flash for your existing array is expensive and a large incremental jump when perhaps you just need some more oomph during your month end job runs.
VDI environments have often borne the brunt of storage performance issues simply due to the number of VMs involved, poor client software that was never written to be careful with storage IO and latency along with operational update procedures used to mass updates of AV/patching etc. that simply kill any storage. VDI was often incorrectly justified with cost reduction as part of the benefit which meant you never had any money to spend on storage for what ultimately grew into a massive environment with annoyed users battling poor performance.
Large performance critical VMs are also affected by storage. Any IO that has to travel along a remote path to a storage array is going to be that little bit slower. Your big databases would benefit enormously by reducing this round trip time.
FVP
Along came PernixData at just the right time with what was such a simple solution called FVP. Install some flash SSD or PCIe into your ESXi host, cluster them as a pooled resource and then use software to offload IO from the storage array to the ESXi host. Even better, be able to cache writes as well and also protect them in the flash cluster. The best IO in the world is the IO you don’t have to do and you could give your storage array a little more breathing room. The benefit was you could use your existing array with its long update cycles and squeeze a little bit more life out of it without an expensive upgrade or even moving VM storage. FVP the name doesn’t stand for anything by the way, it doesn’t stand for Flash Virtualisation Platform if you were wondering which would be incorrect anyway as FVP accelerates more than flash.
Read more…
I’ve blogged before on how you can use PowerCLI to replicate some of the functionality of VMware’s SRM to easily recover VMs in a business recovery site with replicated storage.
In my previous post I had only looked at the VMware side of the automation and so it’s time for an update to include the important part of handling the underlying storage. I’m going to use NetApp storage as an example but any storage vendor that exposes their API to Powershell can be used if you can find the relevant commands.
This is where the awesomeness of Powershell really comes into its own when you can combine automation for both VMware and NetApp in a single script.
You will obviously need both PowerCLI and Netapp’s DataONTAP installed. See my previous post: Pimping your Powershell Profile for getting everything installed.
Read more…
Update: I’ve since found out that mattboren actually found out about this before me and posted something on the VMware communities which I missed. Well found Matt.
A fairly common request is to be able to register existing VMs in a datastore in the vCenter inventory.
This can be a life saver if you have had storage issues and have had to present a backup copy of a datastore which has a different name and need to add the VMs to the inventory, a very laborious process if done manually with right-click Add to Inventory.
This can also be useful in a business recovery process when you need to add VMs that have been mirrored by storage replication over to a secondary site and you need to add them into your inventory.
PowerCLI guru, Luc Dekens has developed a fantastic script called Raiders of the Lost VMX which searches a datastore for .VMX files, and adds them to the vCenter inventory. This script has been updated over the years with even more clever functionality.
Adding the VM to the inventory involved running the RegisterVM_Task Method against the VM Folder in VC.
By accident I discovered there’s actually an updated easier way to add existing VMs to the inventory if you have the .VMX file path. I’m not sure when this was added to PowerCLI but I found it when writing a script to add a new VM.
Read more…
Also see SRM for free with PowerCLI – Part 2: iSCSI
Working in an enterprise company DR, BR, BCP, whatever you want to call it, is everything. With potentially many thousands of people around the globe, being able to get people working again as soon as possible after a disaster can mean the difference between being in business and going bust.
The best way to do business recovery is to design it from the ground up and make it part of every architecture design you put together. Thinking about the what-if of a disaster after everything is up and running often means you have to start again.
One of the great things about virtual worlds is you can easily (not necessarily cheaply though!) have a separate virtual infrastructure in both locations with shared storage. Simply by mirroring the storage from Site A to Site B you can recover VMs from Site A in Site B very easily without having to have a separate VM in Site B that you need to keep up to date.
This is where VMware’s SRM comes into play. SRM is a fairly powerful piece of software for running and testing your BR. It talks to your back-end storage and can automate the different steps required such as breaking the storage mirror, presenting the storage to your ESX hosts, adding the VMs to your inventory and powering them on.
Sounds great but firstly it is a product you need to pay for and secondly when it came out it didn’t support NFS so PowerCLI (it wasn’t called PowerCLI when we did it) came to the rescue.
Read more…
Sure, flash is revolutionising array storage but its going to take time to replace spinning rust with flash and again it often comes down to cost. Purchasing an all flash array or even just a shelf of flash for your existing array is expensive and a large incremental jump when perhaps you just need some more oomph during your month end job runs.
Recent Comments