Best Practise on Datastore Configuration
Which is the best way, and why?
1. A seperate target > datastore for each disk required
2. A single large target with multiple VM's residing inside it.
Basically my SAN has 2 arrays - standard 7.2k SATA drives and some ast 15k SAS drives.
For things like fileshare and OS, I am using the 7.2k array. For things like SQL Databases I am using the 15k drives.
So my current config shows like this:
SQL VM
Disk 1 - OS
Disk 2 - SQL Databases
Disk 1 is a target on the 7.2k drives, presented to VMWare as a single Datastore.
Disk 2 is a target on the 15k drives, presented to VMWare as another Datastore.
This makes sense to me.
Then:
Domain Controller
Disk 1 - OS
Disk 2 - FileShare
These are both on the 7.2k drives, but are presented as seperate Datastores.
Am I complicating things by keeping all of these disks seperate? Should I in fact create 1 single target for all 7.2k disks, and 1 single target for all 15k disks?
1. A seperate target > datastore for each disk required
2. A single large target with multiple VM's residing inside it.
Basically my SAN has 2 arrays - standard 7.2k SATA drives and some ast 15k SAS drives.
For things like fileshare and OS, I am using the 7.2k array. For things like SQL Databases I am using the 15k drives.
So my current config shows like this:
SQL VM
Disk 1 - OS
Disk 2 - SQL Databases
Disk 1 is a target on the 7.2k drives, presented to VMWare as a single Datastore.
Disk 2 is a target on the 15k drives, presented to VMWare as another Datastore.
This makes sense to me.
Then:
Domain Controller
Disk 1 - OS
Disk 2 - FileShare
These are both on the 7.2k drives, but are presented as seperate Datastores.
Am I complicating things by keeping all of these disks seperate? Should I in fact create 1 single target for all 7.2k disks, and 1 single target for all 15k disks?
We've found if you do patch management, Anti-Virus scans, of backups of VMs, on 7.2k disks SATA disks, you've got to limit the number of machines that you can concurrently run Anti-Virus Scans, Patch Management, Snapshots, Backups, because you'll flatline the datastore. What's called storming the datastore. Which results in non-responsive VMs (and with vDR, you cannot tell it only to backup 1 machine on LUN).
So be careful here and test it.
So be careful here and test it.
It's a personal opinion, I think SATA 7.2k disks should be used for archive and backup only, and not production VMs. The are slow. Now if you've got 14 SATA 7.2k disks in a chassis, that's a little different you've got some more performance. But SATA disks are a different class to SAS, and as long as you understand that - thats okay.
ASKER
Hmm, interesting.
I may move the VM's to the 15k SAS drives then. There is space, but this obviously cuts down on the amount of available space for expansion in the future. However, with Thin Provisioning this maybe becomes less of an immediate issue.
What do you think about the original question re: 1 datatsire per disk vs 1 datastore for multiple disks?
I may move the VM's to the 15k SAS drives then. There is space, but this obviously cuts down on the amount of available space for expansion in the future. However, with Thin Provisioning this maybe becomes less of an immediate issue.
What do you think about the original question re: 1 datatsire per disk vs 1 datastore for multiple disks?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Thanks - as long as I know there is nothing inhernently "wrong" with doing it like this I'm happy.
Budget is certainly key, going from a £5k SBS system to a £25k virtual system is a big jump for a small company!
Budget is certainly key, going from a £5k SBS system to a £25k virtual system is a big jump for a small company!
But have you worked out the Cost Savings in Electricity alone?
No, every company has different scenario, and nobody should tell you it's wrong for your company! If it meets your requirements against your budget.
ASKER
Appreciate the thoughts :)
No problems, always around here somewhere.
The larger the number of spindles, spinny disk, the faster the datastore, and the VM benefits, OS benefits, and SQL DB and Logs benefit.
We've tried to get away, with RAID 1 for OS, and RAID 5 for db, or whatever, constraints dbas used to tell us.
But everybodys scenario is different, the reason we do this, is because we run DeDuplication on the SAN across all the Volumes. (which the LUNs are based on). So we get better storage utilization.
All infrastructure are different, different SANs, workloads.
Some clients, like to cut a LUN per VM. (all OS and Data, and Logs) on a single LUN for easier management, but lots of LUNs. So they have 100+ datastores.
Test you plan for performance, and see if it makes a difference, using IO Meter, DiskTT or CrystalMark Disk Benchmarks.