SQL Server Performance Forum – Threads Archive
HP SAN and SQL Server
Hello. My company is thinking of investing in a HP 1510i iSCSI SAN as part of a consolidation exercise. It will contain up to 56 x 300GB disks. I have no experience if SAN’s so I suppose what I’m after really is some guidance on what and how I should ask for from the SAN to ensure that the SQL Server databases perform adequately. I have around 30 SQLServer 2000 databases that will have to go on it. None of the databases are above 10Gb in size and are unlikely to grow beyond that size for some considerable time. 20 of the databases are OLTP, the other 10 are used for reporting purposes only. My initial thought is to put the data files on one controller and the log files on to another and configure them as RAID 1, as availability is the key. Would you agree that this is the best cousre of action or would there be any benefit from splitting thetables and indexes onto separate controllers, and what about tempdb? I also have concerns that the disks in the SAN are too big and it would be better for me if it had lots of smaller disks instead of a few big ones. All thought would be much appreciated. Thanks.
i would be more concerned about sequential bandwidth for Direct Attach storage, i would like to get 50MB/sec per disk capped the number of PCI-x/e slots, for 56 disks, that would be 2.5GB/sec, even 1.3GB/sec would be acceptable is this for multiple servers? if not, why go with SAN?, with its seriouslt poor sequential performance.
depending on what each controller can do, i would have 4 controllers for the OLTP and 4 for the reporting DBs 112 146GB drives would provide more random IO
but the DB you are describing does not need this much capacity
is this SAN for other purposes? if so, do not let any tell it is ok to mix important db with other applications on one SAN, this is vendor BS to justify the fat margins they get on their SAN products.
also, keep the OLTP and Reporting DB on separate SANs
Thanks for your input. The SAN would be for multiple servers and it would used be for other purposes, such as file servers, not just SQL Server. I’d need dedicated connections for the SQL Servers, if this is possible? But given sequential performance is poor and given the fact that I don’t have a huge amount of data to deal, I’m wondering if I would be better off saying no thanks to the SAN and consolidating my SQL Servers onto a two node cluster or something.
too many people seem to think the idea is to put everything into 1 SAN,
it makes no difference from the management perspective whether you consolidate from 50+ pools into 1 SAN or 3 SANs, hence, keep other traffic off of your important databases, how about a 2-3 node cluster, one or two instances for the otlp dbs, and one instance for the reporting db’s.
i still prefer SCSI or even SAS storage, but for a 3-node cluster, perhaps the MSA storage system instad of iSCSI, i am not convince iSCSI can handle high sequential transfers.
if some one is pushing iSCSI hard, ask to see a demo, SQL Server doing a table scan to disk at 700MB/sec, if the vendor can setup an iSCSI to do that at a reasonable price relative to 2 SA6402 controllers and 16 disks in 2 dual channel storage units, say you will buy in
They’re not pushing iSCSI hard yet, it’s just with my lack of experience with SAN’s I’m weary of buying into a set up that will cost a fair amount, and therefore carry the perception that it will be fast, but not deliver on performance in the end. If you were my position, what would you recommend I ask for? given that money isn’t really concern and the 30 databases I have at the moment are split across 8 standalone SQL Servers and I need to mirror the data on them. Thanks very much
personally, i am serious disappointed at mid-range SAN on sequential performance, and that vendors sat on 2Gbit/sec FC for so long, and the high price per FC port, given the inadequate bandwidth, and the high cost per disk that said, most US companies don’t seem to blink at SAN prices, especially if they believe the Sales & marketing bs,
however, it is still possible to configure the mid-range for adequate performance, the flip side is, if you get the SAN training and manage the SAN, this should increase your own market value, with no other real benefit to your company
however, if the SAN is turned over to someone else, ie, the network engineer, i think there will be many fingerpointing exercises between the two of you. hence if you get a SAN, insist that DB be on a separate SAN than other apps, and that you (if you are the DBA) control it, ie, dictate the disposition of physical drives,
and provide a set of SQL test scripts for the SAN vendor to prove that their configuration can hit reasonable numbers for important SQL Server operations otherwise the consultant that comes to configure the SAN (always included with the purchase) will do the standard SAN vendor proposed config that fits their model of the storage world, and most likely will really seriously suck at handling SQL ops
]]>