August 20, 2012 at 12:01 pm
I'm looking to setup a new sql2012 environment where several dbservers will be consolidated. I wondering what the best setup will be when i got two physical ervers available (both with good spec), i can also add virtual servers. Storage will be SAN storage.
Requirements is performance and reliability.
Is mirroring still the best option for this? Or should i go for clustered always on capabilites?
August 20, 2012 at 1:38 pm
anders 54226 (8/20/2012)
I'm looking to setup a new sql2012 environment where several dbservers will be consolidated. I wondering what the best setup will be when i got two physical ervers available (both with good spec), i can also add virtual servers. Storage will be SAN storage.Requirements is performance and reliability.
Is mirroring still the best option for this? Or should i go for clustered always on capabilites?
Clustering is done for redundancy primarily not performance.
If you think you need mirroring the you actually need AlwaysOn as it takes the mirroring topology to a whole new level.
If you want performance primarily then dump the SAN storage and get some fast disks, this coupled with well specced servers should provide some good performance whilst AO provies the redundancy.
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
August 21, 2012 at 12:29 am
Thanks for reply.
Since this sql will probably host some large dbs, we would probably need to use SAN disk, we can always configure vraid to 1+0 on the SAN to gain performance. However i think i read someting about locating the tempdb on fast local disks, that might be a viable option.
August 21, 2012 at 5:04 am
anders 54226 (8/21/2012)
Since this sql will probably host some large dbs, we would probably need to use SAN disk
Has absolutely nothing to do with using a SAN, you can still attach enough local storage if you wanted to service a large db and you wouldn't have the overhead of the SAN
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
August 21, 2012 at 5:17 am
I really cant see how san will give me overhead compared to Local attached disk with 15 K RPM. With SAN with autotiering i can get alot more spindels, and alot more IO, and SAN is more robust and reliable than local disk.
August 21, 2012 at 6:35 am
anders 54226 (8/21/2012)
I really cant see how san will give me overhead compared to Local attached disk with 15 K RPM. With SAN with autotiering i can get alot more spindels, and alot more IO, and SAN is more robust and reliable than local disk.
Oh dear someone's been listening to the SAN salesman again and fallen for it hook line and sinker.
A SANs primary purpose is consolidation of storage not performance, when well specced and configured they can provide good performance, but ultimately the controllers are shared amongst many different I\O patterns.
Local storage will always perform better, more and more organisations are moving back to local storage for critical enterprise apps, SQL server being one of them. AlwaysOn removes the shared storage requirement, why do you think that is?
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
August 21, 2012 at 6:42 am
Not listening to any sales guys, this is from experience, we have one SQL server with both local disk and SAN attached disk, and the DBs on SAN disk outperforms local disk. Same raid config, this is math not about what is best etc.
Viewing 7 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic. Login to reply