Hello all I'm trying to establish the optimal disk layout for a VMware MS SQL 2016 2 node guest failover cluster that will have a single SQL instance hosting multiple small to medium sized databases. Unfortunately we don't really have the funds for licensing to do the recommended approach of creating lot of small VMs to host these databases, so we need to consolidate where possible. I've been reading though the Nutanix SQL 2016 best practice guide and it's raised a few questions. I've decided to allocate multiple vdisks specifically for database files, so I'd have a few database files to each vdisk instead of one vdisk with all the database files on it. I'm assuming this approach might be better due to each vdisk having a 6GB Oplog allocation and so more vdisks would prevent a single oplog from quickly over filling? Is there any there real a benefit here to having more vdisks to spread the databases across or does this only really come into play when you split individual database files across disks? I know spitting the log files into multiple files isn't worth while but is there any benefit to allocating more drives for the database log files too? Thanks

Couple things here. How are you planning to cluster? Failover clustering is not supported on NFS per Microsoft. Unless I'm reading what you're stating wrong. (Single VM on a two node Nutanix cluster?) How many databases and how busy will they be? My DBA is one of the best of the best Microsoft MVPs so we've gotten some great recommendations from him (Brad McGehee) as well as the Nutanix engineers.He recommends 64k allocation formatting and separate disk for databases. For logs, and temp there's little benefit for seperation.It's not so much about size as it is storage reads/writes that should determine if a database should require it's own VMDK. Most instances where it's a lot of reads but a smaller DB, you can cache most of it in RAM and it's fine. But the more DB's and the busier they are, the better off you are splitting it off. So you're right on the money with planning to do that. AHV would be optimal for this since you can now take advantage of AHVTurbo on windows, regardless though, having multiple VMDKs for your databases means dedicated storage streams per VMDK. Don't be surprised though if you're seeing an increased amount of CPU as a result of more storage IO availability. Make sure that you have RSS enabled on your NIC so you're not overwhelming your CPUs, and the traffic balances across your CPUs evenly. If you put all your DB's on a single VMDK, they're contending for one another and you'll see increased read latencies. especially if your cluster is a hybrid where most of your data will live in HDD's if it's not overly busy or sequencially being read or written to. For your more strenuous workloads, you can even look at pinning the VMDKs to SSD inside of your prism element. Take your SSD sizes into consideration though as you don't want it to contend with your OpLog storage.As always you can engage support if you want to verify any of this and get assistance with a design.