Please start any new threads on our new site at https://forums.sqlteam.com. We've got lots of great SQL Server experts to answer whatever question you can come up with.

 All Forums
 SQL Server 2000 Forums
 SQL Server Administration (2000)
 Translate SCSI Internal Drive Config to SAN?

Author  Topic 

DBADave
Constraint Violating Yak Guru

366 Posts

Posted - 2007-03-05 : 14:40:23
We need to price hardware for three new systems. One system is an Accounting package, another is a compliance package and a third is a trading system. The trade system in particular needs to be high-performance. Being new to the SAN world I don't know if RAID configurations used for non-SAN configurations apply to SANs.

For the trade system if we did not go with a SAN my configuration would be as follows:
NOTE: The smallest drives we can purchase are 72GB and the total database size will probably be under 20GB after a year or so. Data retrieval speed is key with this system.

OS - RAID 1
Data - RAID 10 (15k rpm drives) (4 72GB for approximately 144GB usable space).
Logs - RAID 10 (15k)
Tempdb - RAID 1 (15k)
Backup - RAID 1 or 5

Data on a dedicated controller
OS & Logs share a controller
Tempdb and Backups share a controller

The same configuration would be used for the accounting system, although system performance, while important, is not a critical.

Our SAN is EMC. How would the above configuration translate to a SAN and what are the performance differences in terms of read/write speed on a SAN vs. internal SCSI drives?

Thanks, Dave

Michael Valentine Jones
Yak DBA Kernel (pronounced Colonel)

7020 Posts

Posted - 2007-03-05 : 15:32:00
The RAID configuration is not as important for SAN, unless you have very high continuous writes, but I believe that EMC really recommends RAID 10. Since you are spending a lot for EMC, there is really no point in getting cheap by using RAID 5. The most important thing is to make sure that the SAN is configured with plenty of cache, since the data is written to cache first. The other thing is to make sure that you have the systems configured correctly so that all LUNs are dual-pathed. This means dual HBAs in each server connected to dual switches. This gives both redundancy and higher performance.

Have you actually verified that your application is limited by IO? It would likely be much cheaper to configure your system with a lot of CPU power and a lot of memory running 64-bit SQL Server 2005 for a database that is 20 GB or less. Most applications are much more read-intensive than write-intensive, so having enough memory to keep most of the database cached and enough CPU to process it quickly will do more for performance than spending that amount of money for EMC. No matter how fast your disk it, it is no where near as fast as data that is already in cache.





CODO ERGO SUM
Go to Top of Page

DBADave
Constraint Violating Yak Guru

366 Posts

Posted - 2007-03-05 : 15:51:11
The accounting application will have an estimated 500GB of data after one year. The trading system is difficult to project, but I would say 20GB is a good start. I've been told to consider a SAN for the trading system. Unfortunately I don't have enought SAN knowledge to argue against it at this point. Can you explain the advantage of dual-pathed LUNs?

Thanks, Dave
Go to Top of Page

Michael Valentine Jones
Yak DBA Kernel (pronounced Colonel)

7020 Posts

Posted - 2007-03-05 : 15:53:55
quote:
Originally posted by DBADave
...Can you explain the advantage of dual-pathed LUNs?...


I thought I did.



CODO ERGO SUM
Go to Top of Page

DBADave
Constraint Violating Yak Guru

366 Posts

Posted - 2007-03-05 : 16:04:20
You mentioned redundancy and high-performance, but I need to explain, or at least understand, how this equates to high-performance. It is my understanding an HBA has 4 channels, so dual HBAs give me a total of 8 channels, however since I am not familiar with a SAN I don't know how to dedicate these channels. Since you mentioned redundancy I can assume I would dedicate one channel per HBA to SQL data, one channel per HBA to SQL logs, etc. and if one HBA dies I'm still ok. I don't know if this is what you are indicating. If it is, wouldn't there be drawbacks to having data, log and tempdb sharing the same HBA or is this not an issue with SANs? I know when using internal SCSI drives sharing controllers is not the best practice from a performance perspective.

Thanks, Dave
Go to Top of Page

Michael Valentine Jones
Yak DBA Kernel (pronounced Colonel)

7020 Posts

Posted - 2007-03-05 : 16:42:02
quote:
Originally posted by DBADave

You mentioned redundancy and high-performance, but I need to explain, or at least understand, how this equates to high-performance. It is my understanding an HBA has 4 channels, so dual HBAs give me a total of 8 channels, however since I am not familiar with a SAN I don't know how to dedicate these channels. Since you mentioned redundancy I can assume I would dedicate one channel per HBA to SQL data, one channel per HBA to SQL logs, etc. and if one HBA dies I'm still ok. I don't know if this is what you are indicating. If it is, wouldn't there be drawbacks to having data, log and tempdb sharing the same HBA or is this not an issue with SANs? I know when using internal SCSI drives sharing controllers is not the best practice from a performance perspective.

Thanks, Dave




I have never seen a HBA with more than two channels. Are you sure you know what an HBA (Host Bus Adapter) is? Since you may be using EMC, you should ask their people for detailed info on their products. At the prices they charge, they should be glad to.

Channels are not dedicated to specific disks. The higher performance comes from being able to service multiple IO requests at the same time, since you have two available paths to the data. Redundancy means that you can still operate if one path fails.




CODO ERGO SUM
Go to Top of Page

DBADave
Constraint Violating Yak Guru

366 Posts

Posted - 2007-03-05 : 16:57:05
I'm just going by what the manager of our SAN told me, but he could be mistaken. He said an HBA is essentially a controller and that our HBA has 4 channels. I'll check with one of his server guys to confirm this statement.

Thanks, Dave
Go to Top of Page

TonyTheDBA
Posting Yak Master

121 Posts

Posted - 2007-03-06 : 04:57:08
In the simplest terms A HBA is a network card for the san. Having two in the server, means that you attach each HBA to a different switch in the SAN. This gives redundancy in that should a HBA/fibre cable/ SAN Switch fail, the other continues. With Multipath IO (I'm using HP's EVA SANS here) both HBA's are used to read/write data to the SAn so you get faster throughput.

INTERNALLY each HBA may very well have multiple channels . .. but you don't get access to those (at least not in HP EVA's )

--
Regards
Tony The DBA
Go to Top of Page

DBADave
Constraint Violating Yak Guru

366 Posts

Posted - 2007-03-06 : 09:40:14
Thanks Tony. I'll try to locate an EMC whitepaper on SAN configurations to get a better understanding of its various hardware components and see how IO performance compares with a typical internal SCSI drive.

Dave
Go to Top of Page
   

- Advertisement -