We are in the process of upgrading to 2013 R2, and I've been speccing out the hardware needed. The server we have for this purpose is a dual processor box, 6 cores per processor if I'm not mistaken, 64 GB of RAM, and 12 fast hard drives of equal size. Windows 2012 R2 and SQL 2012 will be running. It will also run with a Vmware vSphere base. I plan on separating the workloads between two virtual machines, allocating 16 GB to the service tier and 48 GB to the database. Max of about 80 concurrent users.
The question is on the RAID setup. Typically for a SQL installation, I'd set up two RAID 1 arrays for the DB and log, and one RAID 1 for the OS. In the Vmware world, they suggest building out one big RAID 10 array, and allocating the drives through the software. In the past, this would be a big no-no for a SQL install, but I also know that much has changed. Any recommendations here?
Also, with the two tiers, install on the same server, or separate?
There is no data, only bool!
0
Comments
Depends on the hardware you have.
If you have a nice SAN with a nice big WRITE-cache, the write-cache should be able to handle the peeks in writing (SAN read-cache is completely useless for SQL server: if you have a page in your SAN read-cache, you will also have it in the SQL Server cache because the SQL Server cache is generally a lot bigger than the SAN read-cache and this last one is also divided with other VM's that use the SAN).
Even if you don't have much memory for SQL, but have some SSD's, than it shouldn't be a problem.
I also have had a lot of virtualized installations and cannot have dedicated disks because even more than before I hear this: "I have a RAID1 with 2 times 300 GB and only use 50 GB for the transaction log ????? And I cannot use the other 250GB".
And they won't dedicate physical disks to SQL.
So in that case, it is best to spread out the random read/write as much as possible between SQL server and other servers (with completely different read/write patterns) and hope for the best.
One thing you need to do is to make sure that the disks you carve for SQL Server are not fragmented on the SAN.
For SQL and servicetier: if you have small installations and performance is not that much of an issue, you might put them together in 1 machine.
But generally it is best to separate them because otherwise you will see them draw swords (or worse) to battle over the resources (especially memory and CPU) of your VM. And if you have SQL2012, you need probably more than 4 cores to support both and that makes your SQL Server license more expensive. So best 1 SQL server with 4 cores for SQL and another server for the servicetier (especially with 80 concurrent users).
No PM,please use the forum. || May the <SOLVED>-attribute be in your title!
To clarify some specs, this is actually not a SAN. It's all direct attached storage in the server, with 2 GB hard drive controller cache, and at least 12 15K SAS disks. There is room for 25 disks in which I can add more spindles as necessary. I also purchased the SQL license for 12 cores, the max available on the server.
Since it doesn't sound like the middle tier needs to access too much disk, but is more memory dependent, I can set up a VM with only a standard mirrored set of 2 disks, give it 8-16 GB of RAM, and the rest of the server resources will be dedicated to the SQL side of things. In reality, I can then allocate the "standard" SQL/NAV recommended disk configuration. Even though both will be VMs, they will only end up sharing the OS drives.
Don't forget the resource needs of the host system. You don't have the full 64 GB for use by the VMs
Actually they'd share the entire physical server.
What advantages/benefits are you looking to get with virtualization?