I am an Oracle TME at Nimble Storage but by no means an expert on Windows or VMware. From what you said, I would suggest setting up your Oracle database server as followed:
1. Use VMDK for boot volume only
2. Use guest direct attached storage for Oracle volumes
3. Use multipath for Oracle volumes
4. Create a striped NTFS volume for Oracle if possible
You don't need to use ASM if you don't have a dedicated DBA. Please let me know if you have any further questions.
Thanks for the reply Tom. I'll stick to direct attached storage from the guest then. One question though. Why stripe the direct attached NTFS volumes? I can see where this would be a benefit if the underlying storage was 2 separate LUNS, but it seems odd to do this with two separate volumes from the Nimble array. I'm sure you know your array better than I do, so I'm just curious why you suggested this route.
I cant see any reason you'd want to strip it. you cant do it from the nimble side and if you do it from the windows side you'll just add overhead with no value.
I actually do a similar thing. We have our VM env on some HP chassis with Virtual Connect so its a tad more complex (with little advantage)
I am sorry, but there is almost no perceptible difference between RDMs and VMDK based storage that is DEDICATED. (see here: vSphere 5.1 – VMDK versus RDM | VMware vSphere Blog - VMware Blogs) What I would suggest is this:
- Can use a SHARED Datastore for the boot drive.
- Use DEDICATED datastores and create a single VMDK volume on the datastore for the Oracle volumes.
- Multi-path is always better, generally speaking.
This will give you the benefits of the VMDK Encapsulation for easy management, movement, re-sizing, etc. and will also give you the only real benefit of RDM; dedicated disk.
No. That is actually a good point. The performance policies could have an impact here. Generally speaking, the difference would be imperceptible on like for like disk. I have a Nimble in the lab that I can take a look at later to see what the performance policy differences are for Oracle vs. VMWare to be sure, but my thinking is that you could probably set the performance policy for those dedicated datastores to match the Oracle policy you would use for the RDM to take advantage of it as long as they did not change the block sizes, etc. Good point.
I had the same discussing with Nimble but on Exchange. We have Exchange volumes in a dedicated VMFS volume. As long as you ONLY put that VMDK in that volume, it is indeed recommended to set the Performance Policy to Exchange/Oracle/SQL/... and NOT to VMware.
Make sure to put other stuff like your boot VMDK on a datastore with the ESX performance policy!