You have to also consider the caching available on these SAN boxes. Our's has 6 GB of cache on it. Writes may not cause any contention as you have GB's of cache to write to first and if the box is configured with the proper algorithms it would hold it in cache while the reads are completed. Reads are also improved as it will Read ahead.
We have seen much improved performance as we move to the SAN any bottlenecks we have been able to demonstrate have been in the HBA's not in the SAN itself. Multiple HBA's may be used for increased performance and redundancy if needed. Although we found the HBA's were faster the array cards we were using. -----Original Message----- From: Roger Seielstad [mailto:[EMAIL PROTECTED]] Sent: Friday, October 04, 2002 1:34 PM To: NT 2000 Discussions Subject: RE: Basic SAN question That's only true when you're not partitioning one large RAID set. If you put every drive in the database into 1 RAID10, then carve LUNs from that, its nearly impossible to control where that data gets written, and therefore to reduce contention. As I said - SANs are appropriate for certain situations. Very specialized situations, and at that, only if properly managed. But the way that SAN vendors (pretty much all of them) are selling the products aren't the right situations. Roger ------------------------------------------------------ Roger D. Seielstad - MCSE Sr. Systems Administrator Inovis - Formerly Harbinger and Extricity Atlanta, GA > -----Original Message----- > From: Chinnery Paul [mailto:[EMAIL PROTECTED]] > Sent: Friday, October 04, 2002 1:20 PM > To: NT 2000 Discussions > Subject: RE: Basic SAN question > > > Before making such a generalized statement, Roger, you have > to take into > account what it's being used for and the type of software > that's accessing > it. > > I agree with you that buying a SAN just for general storage would be a > waste, though. > > Our hospital software is made up of different modules such as ADM for > admitting, Lab, OE for Order Entry, etc. By utilizing the SAN > properly, users won't see a hit because ADM would be hitting one set > of disks while OE > might hit another (although their is a lot of access from one > module to > another). > > > Paul Chinnery > Network Administrator > Mem Med Ctr > > > -----Original Message----- > From: Roger Seielstad [mailto:[EMAIL PROTECTED]] > Sent: Friday, October 04, 2002 12:19 PM > To: NT 2000 Discussions > Subject: RE: Basic SAN question > > > 3 LUNS still means that you're going to see contention on > about 1/3rd of all > operations. Granted, caching will cover some of that, but not > all of it. Add > a 4th lUN and you're pretty much guaranteed contention on 50% > of all disk > ops. This is the 'scalability' side of SANs that's never > discussed, because > SAN vendors don't want you to know the dirty little secrets > of their trade. > > I think you're correct in not expecting the users to see a > performance hit, > and it also seems that you're already aware that the SAN > isn't going to buy > you a big performance gain, either. > > Roger > ------------------------------------------------------ > Roger D. Seielstad - MCSE > Sr. Systems Administrator > Inovis - Formerly Harbinger and Extricity > Atlanta, GA > > > > -----Original Message----- > > From: Chinnery Paul [mailto:[EMAIL PROTECTED]] > > Sent: Friday, October 04, 2002 11:38 AM > > To: NT 2000 Discussions > > Subject: RE: Basic SAN question > > > > > > I agree but, realistically, one of the nice things of a SAN > > is the ability > > to create separate LUN's off of the same disks. > > Also, as was explained to me by an EMC engineer, if you have > > a RAID 1/0, > > you can be writing to one set and reading off the other. > > Now for us, our users wouldn't even notice the performance > > hit. We're going > > from direct-attached, 7500 rpm to a SAN with 15000 rpm > > drives. Add to that, > > we're putting in a gigabyte backbone and brand-new servers > > (upgrading from > > Pro200 duals to 1.3 duals) attached to a Cisco 4006 swtich. > > Of course, we're not slicing it up with a half-dozen > > different luns either. > > Maximum we've got is 3. > > > > Paul Chinnery > > Network Administrator > > Mem Med Ctr > > > > > > -----Original Message----- > > From: Roger Seielstad [mailto:[EMAIL PROTECTED]] > > Sent: Friday, October 04, 2002 7:51 AM > > To: NT 2000 Discussions > > Subject: RE: Basic SAN question > > > > > > Chris, > > > > Most vendors will allow you to slice and dice a SAN array > > into as many LUNs > > of whatever size you want. Its absolutely the wrong thing to > > do, but it > > certainly can be done. > > > > Any time a phisical platter is partitioned, you're going to take a > > performance hit - simply put, the heads can't be in two places at > > once, so if two systems are trying to access data which is > > physically on the same > > platter, but logically on different LUNs, there is head > > contention, and one > > of the two must wait for the other to finish "using" the > > heads, and then pay > > the additional price of a head seek across the platter to its > > assigned set > > of cylinders. > > > > In the case of your single 500GB RAID5 set in your SAN being > > split into > > 300/100/50/50, you have in reality created 4 partitions on > > each spindle, > > with 60%/20%/10%/10% split on each spindle. With a large > > number of platters, > > and larger stripe sizes, its theoretically possible to reduce > > the chances of > > contention within the SAN, but realistically speaking, > > chances are there is > > going to be some contention, and therefore some performance > > hits associated > > with managing your disks this way. > > > > Its one of the lies^H^H^H^H omissions commonly done in the > > sales pitches of > > the big storage vendors. > > > > ------------------------------------------------------ > > Roger D. Seielstad - MCSE > > Sr. Systems Administrator > > Inovis - Formerly Harbinger and Extricity > > Atlanta, GA > > > > > > > -----Original Message----- > > > From: Chris Levis [mailto:[EMAIL PROTECTED]] > > > Sent: Thursday, October 03, 2002 2:07 PM > > > To: NT 2000 Discussions > > > Subject: Basic SAN question > > > > > > > > > If you have a RAID-5 array of (let's say) 500GB, can you > > > create LUNs of an > > > arbitrary size to be presented to the servers? E.g, a 300GB, > > > a 100GB, and > > > two 50GB? Or is there a convention that all LUNs have to be > > > a uniform > > > size? > > > > > > Thanks! > > > > > > > > > > > > > > > > > > ___________________________ > > > Chris Levis > > > Applied Geographics, Inc. > > > > > > ------ > > > You are subscribed as [EMAIL PROTECTED] > > > Archives: http://www.swynk.com/sitesearch/search.asp > > > To unsubscribe send a blank email to %%email.unsub%% > > > > > > > ------ > > You are subscribed as [EMAIL PROTECTED] > > Archives: http://www.swynk.com/sitesearch/search.asp > > To unsubscribe send a blank email to %%email.unsub%% > > > > ------ > > You are subscribed as [EMAIL PROTECTED] > > Archives: http://www.swynk.com/sitesearch/search.asp > > To unsubscribe send a blank email to %%email.unsub%% > > > > ------ > You are subscribed as [EMAIL PROTECTED] > Archives: http://www.swynk.com/sitesearch/search.asp > To unsubscribe send a blank email to %%email.unsub%% > > ------ > You are subscribed as [EMAIL PROTECTED] > Archives: http://www.swynk.com/sitesearch/search.asp > To unsubscribe send a blank email to %%email.unsub%% > ------ You are subscribed as [EMAIL PROTECTED] Archives: http://www.swynk.com/sitesearch/search.asp To unsubscribe send a blank email to %%email.unsub%% This e-mail and any files transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. If you are NOT the intended recipient or the person responsible for delivering the e-mail to the intended recipient, be advised that you have received this e-mail in error and that any use, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. ------ You are subscribed as [email protected] Archives: http://www.swynk.com/sitesearch/search.asp To unsubscribe send a blank email to [EMAIL PROTECTED]
