VMware SQL 2016访客群集的磁盘布局

\r\n
1. 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?)
   \r\n
2. How many databases and how busy will they be?
   \r\n<\/ol>
   \r\nMy 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.
   
   \r\nHe recommends 64k allocation formatting and separate disk for databases. For logs, and temp there's little benefit for seperation.
   
   \r\nIt'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.
   
   \r\n
   
   \r\nAHV 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.
   
   \r\n
   
   \r\nFor 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.
   
   \r\n
   
   \r\nAs always you can engage support if you want to verify any of this and get assistance with a design.","quoteUsername":"ddubuque","translations":{"Common":{"like":"Like","unlike":"Unlike"},"Forum":{"Quote":"Quote","Share":"Share"}}}">
   • 喜欢
   • 引用

Couple things here.<\/p>

1. 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?)<\/li>
2. How many databases and how busy will they be?<\/li> <\/ol>

   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.<\/p> <\/content-quote>

   
   Hiya and thanks!
   
   We're basically using in guest ISCSI (connect from the VMs to the Nutanix cluster ISCSI data services IP) and use Nutanix volume groups for the shared disks - Which is supported as far as I know and the only way to do it. We're running ESXi.
   
   There's around 15 databases at the moment, all relatively busy I'd say. We're be moving a lot of them from various existing physical servers that have local disks only.
   Unfortunately we won't be going AHV, not yet anyway - We've only just installed this new environment with ESXI .
   
   I've covered of the usual basics I think:
   Format drives at 64K
   Lock pages in memory
   Presize DBs where possible and set Auto growth settings appropriately
   etc etc etc
   
   I'd be interested to know if there are any ISCSI queue depth limits to be concerned about as I know that the preferred option when using normal VM SCSI controllers is to use Para Virtual controllers due to the performance benifits. Are there any tweaks to be made here that you know about?
   
   Cheers<\/p>

   \u00a0<\/p>

   \u00a0<\/p>","quoteUsername":"AlPM","translations":{"Common":{"like":"Like","unlike":"Unlike"},"Forum":{"Quote":"Quote","Share":"Share"}}}">

   • 喜欢
   • 引用