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 PROTECTED]
