Link to home
Start Free TrialLog in
Avatar of jsctechy
jsctechyFlag for United States of America

asked on

what are the best practices for disk configuration/data directories for a sql server 2012 failover cluster?

hello all
im looking to setup a new sql server 2012 failover cluster (1 active, 1 passive node for the time being)
im wondering what the best practices are for the data directories, and which disks i should place them on
i originally setup 3 shared disks, 1 for DB, 1 for logs, and 1 for quorum
i believe in sql server 2012 i might need to specify locations for 3 other database locations which are TEMP DB, TEMP LOGS and BACKUP
can the TEMP DB go on the DB disk? and can the TEMP LOGS go on the original LOGS disk?
i assume im going to need to setup another disk for the BACKUP location
also, we are starting this cluster from scratch, and im not 100% sure how big to make each drive- is there a best practice for disk sizes? my department agreed internally that we would create a database drive which is 40gb in size, for the time being- this is being done so we can add more storage later on via our SAN administration console. what should the other sizes of the drives be if this database drive is going to be 80gb?

also, is the MSDTC drive now the QUORUM drive in sql server 2012?
ASKER CERTIFIED SOLUTION
Avatar of Carl Tawn
Carl Tawn
Flag of United Kingdom of Great Britain and Northern Ireland image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of jsctechy

ASKER

thanks Carl-
what about the Temp Logs directory? can that go with the other Logs directory?
also- on my SAN, im able to increase the size of the volumes that are presented to the servers - how plausible and easy is it to increase the size of the drive(s) when its in a production environment? can i just rescan the iscsi target, and then increase the volume size via server management console?
Again, it's one of those "It depends...." questions :)

On a SAN where all of the LUNs are striping across the same spindles then it doesn't really matter. Logs write sequentially, so logically should sit with the other log files. On the flipside tempdb usage tends to be more erratic than for user database logs, so can impact the log writing on other databases.

Performance wise you should also consider creating multiple files for tempdb to aid performance.

You can check up on Microsofts best practice guide for tempdb here: http://msdn.microsoft.com/en-us/library/ms175527%28v=sql.105%29.aspx
With regard to resizing the LUNs; that's a bit outside my area of knowledge i'm afraid.  

At the data centre I worked at the storage team were loath to dynamically resize the LUNs (mainly because if something went wrong it would be their responsibility!), so we were always presented with new LUNs and had to switch over.