March 4, 2010 at 10:04 am
We are moving away from physical servers to Virtuals and SANS.
How does this affect the best practise of Data and Logs to separate arrays and so forth? Carry on but based on Virtual disks? Or should the SAN contain separate arrays to cater for it? (my support guys will NEVER budge on that)
March 4, 2010 at 10:08 am
I'd like to get some feedback regarding this question, also. In two different jobs, my storage admins have said that the SAN/NetApp would handle the disparate I/O, so it's not needed to separate out the data, log and indexes into separate filegroups.
----------------------------------------------------------------------------
Sacramento SQL Server users group - http://sac.sqlpass.org
Follow me on Twitter - @SQLDCH
----------------------------------------------------------------------------
March 4, 2010 at 11:24 am
I'm not a SAN expert, but even if the SAN can keep up with your I/O needs when you put the data/log files on the same disk, I would argue that it would still be better to put it on 2 separate disks just to reduce the chance of large amounts of data loss should one of them fail.
The Redneck DBA
March 4, 2010 at 5:09 pm
As in all things, it depends 😉
Using Netapp as an example, you can present storage from different aggregates to your server and direct access to those different aggregates through different heads. You would do this to isolate log traffic (sequential writes) with data traffic (random read/write).
Depending upon your utilization and how the aggregate is setup - it might not matter. For example, if the aggregate you are using has 64 spindles and you are not pumping 1000's of transactions per second at the storage it doesn't really matter whether you split it out or not.
With an HP EVA - it depends on how the disk group is defined. If your disk group has 80 spindles it probably wouldn't matter. If the disk group only has 8 spindles - it's going to make a difference.
And finally, if you have just a couple of systems accessing the shared storage - and those systems are not heavy hitters it probably won't matter. However, if you have 100's of systems on that shared storage it will make a difference.
Again - it all depends...
Jeffrey Williams
“We are all faced with a series of great opportunities brilliantly disguised as impossible situations.”
― Charles R. Swindoll
How to post questions to get better answers faster
Managing Transaction Logs
March 4, 2010 at 5:47 pm
Thanks for the feedback. Our current server is a strange fish. Keeps up to date with replication every 30 minutes but only has a big transaction hit once a month for 2 hours. The heavily tuned query that runs for the 2 hours locks the entire san test virtual.
March 4, 2010 at 7:41 pm
Shark Energy (3/4/2010)
Thanks for the feedback. Our current server is a strange fish. Keeps up to date with replication every 30 minutes but only has a big transaction hit once a month for 2 hours. The heavily tuned query that runs for the 2 hours locks the entire san test virtual.
Now, that is mixing things up a bit. Using a virtual machine is different than virtualization on the SAN. Whether or not your VM has enough resources available (e.g. CPU/MEM) is going to determine how well it performs. How the storage is presented to the VM from the SAN is going to determine what kind of throughput you can get, and finally - how the SAN storage is configured is going to affect your IO.
In that kind of environment, my guess is that the VM does not have the resources it needs to process that query. I would hazard a guess that the VM was configured with only 1 or 2 CPU's and a couple GB's of memory.
Jeffrey Williams
“We are all faced with a series of great opportunities brilliantly disguised as impossible situations.”
― Charles R. Swindoll
How to post questions to get better answers faster
Managing Transaction Logs
March 6, 2010 at 11:20 am
One quad core cpu and 8gb ram...
March 7, 2010 at 7:32 am
It also depends how the LUNs on your SAN are configured. In my previous job, our LUNs could configured across specific spindles, so that LUN_1 was made up of spindles 1-5; LUN_2 was spindles 6-10 etc. That gave us great flexibility in partioning our database files onto specific spindle groups based on usage and spearating MDF from LDF.
Now, at my current location, each LUN is spread across all the spindles, so LUN_1 uses part of spindles 1-20, and LUN_2 also uses part of spindles 1-20. I don't like this setup as much and there's not really any benefit to logically separating the files since they're all spread across the same spindles anyway.
Viewing 8 posts - 1 through 7 (of 7 total)
You must be logged in to reply to this topic. Login to reply