Deploying SQL Server 2005 with SAN #1
Prem Mehra and Mike Ruthruff
An often asked question is how to design and deploy SAN with SQL Server 2005. The question is frequently raised by installations that are either deploying SQL Server for the first time or are upgrading to SAN from direct attach storage.
This topic covers a wide area that includes several important considerations, such as:
virtualization of physical disks, RAID groups, creation and sizing of LUNs, alignment of sectors, NTFS format size, base lining of SAN throughput, dynamic and basic disks, sizing and allocation of Windows files, isolation of data, index and log objects, performance monitoring, etc.
We want to address most of these considerations starting with this blog and hopefully add to these recommendations in future. So far, we have not found any reason to alter our recommendations for SQL Server 2005 SAN configuration from those we have made for SQL Server 2000.
Three of the key things to think about before deploying SQL Server on SAN are 1) the core SQL Server requirements with respect to IO subsystem, 2) the complexity introduced by virtualization of the IO subsystem and 3) the type of RAID level to choose.
This abstraction can introduce challenges when troubleshooting a poorly performing IO environment, even more difficult when multiple servers share access to the same set of underlying physical disks. For this reason it is critical to understanding the underlying physical characteristics of your SAN before and during deployment of SQL Server. Some of the key ones include the following:
In the next blog we will address a few additional topics on SAN and SQL server deployment and focus on how best to assign SQL Server objects to LUNs to achieve good performance while keeping design simple.
Best practices say to have a separate drive for OS, log files, data files, and full text indexes. So, if you have a SAN does it make this practice mute?
In theory you can have multiple LUNs sharing the same physical drive, right, which would violate best practices?
We dont have space in one SAN.
We bought another SAN toget more space.
Is it a bad or unsupported practice to use that new SAN?
Should we move the data from one database to the other SAN so that we have all its data ina single SAN?
Whatis this is not possible?
Jadeflon: For SQL Server data integrity, it is essential that all basic IO tenets are honoured - including the one about log write ahead. Please discuss with your SAN vendor if splitting the data on two SANs still meets all the tentes. You can read more about these on the website http://www.microsoft.com/sql/alwayson/default.mspx
Till you get a confirmation from your SAN vendor, it may be safer to keep all the data on the same SAN.
There are quite a few places to find information about improving the performance of your SQL Server machines
Scott Cadillac said:
What is a SAN? Or a LUN or HBA for that matter?
Duh, what does SQL mean? Try Googling if you don't know widely used terminology. ;)
PingBack from http://www.hilpers-esp.com/648317-sql-server-2005-sql-server
PingBack from http://paidsurveyshub.info/story.php?id=76010
PingBack from http://thestoragebench.info/story.php?id=9349