Do you wonder if your IT business is truly profitable or if you should raise your prices? Learn how to calculate your overhead burden using our free interactive tool and use it to determine the right price for your IT services. Start calculating Now!
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?
Do more with
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
I think this is an okay approach if you are on a budget, but personally, we like to create large LUNs of between 500 - 800GB on fast disk systems, 15k FC disks. RAID 10.
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.
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.
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.
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?
I think this is an okay approach if you are on a budget.
But I think it's a little old fasioned for me, and I like to think virtual, rather than thinking physical. Becuase that was the physical philosphy. OS on RAID1, DB on RAID 5 etc
What does help, if you don't have all your like (e.g.SQL) servers together on the same datastore, and balance them out, across datastores.
But I think it's a little old fasioned for me, and I like to think virtual, rather than thinking physical. Becuase that was the physical philosphy. OS on RAID1, DB on RAID 5 etc
What does help, if you don't have all your like (e.g.SQL) servers together on the same datastore, and balance them out, across datastores.
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!
Premium Content
You need an Expert Office subscription to comment.Start Free Trial