Totally agreed. Linchi
> -----Original Message----- > From: Schwartz, Jim [mailto:[EMAIL PROTECTED]] > Sent: Friday, October 04, 2002 5:00 PM > To: NT 2000 Discussions > Subject: RE: Basic SAN question > > > You can take what ever Roger says in this thread and add my complete > agreement with his opinions and conclusions. > > Quack. > > -----Original Message----- > From: Roger Seielstad [mailto:[EMAIL PROTECTED]] > Sent: Friday, October 04, 2002 3:17 PM > To: NT 2000 Discussions > Subject: RE: Basic SAN question > > > That's interesting. Almost everyone else I know that's run > the numbers has > shown a considerably higher cost per mb for SAN over DAS, and > have had to > use the "soft" cost justifications to get them back in line. > > Granted, you were buying 5-20 times the required storage per > machine, we > usually shoot for 2-3 times. > > For grins, what's the total capacity of your SAN, and what's > the current > utilization at? > ------------------------------------------------------ > Roger D. Seielstad - MCSE > Sr. Systems Administrator > Inovis - Formerly Harbinger and Extricity > Atlanta, GA > > > > -----Original Message----- > > From: Wes Owen [mailto:[EMAIL PROTECTED]] > > Sent: Friday, October 04, 2002 2:00 PM > > To: NT 2000 Discussions > > Subject: RE: Basic SAN question > > > > > > Disagree. We are moving all of our servers to the SAN, > > including booting > > the OS from the SAN. We were able to show a break even > > scenario in hard > > costs, and then the "soft cost" were able to push things > over the top. > > > > Largely because of our purchasing habits, I admit. We would > > buy servers > > with 100 to 400 GB's of drive space because they (developers > > and DBA's, not > > me!) might need it within the three year lease cycle. Then > > when it came off > > lease they may have used 15 or 20 GB's. Also, booting from > > SAN I lose the > > array card along with all the hard drives. > > > > Again just one man's opinion. > > > > -----Original Message----- > > From: Roger Seielstad [mailto:[EMAIL PROTECTED]] > > Sent: Friday, October 04, 2002 11:15 AM > > To: NT 2000 Discussions > > Subject: RE: Basic SAN question > > > > > > IMO, the *right* answer is to not buy a SAN for generalized > > storage. At the > > current price-per-mb rates of SAN solutions vs. Direct Attached > > Storage(DAS), I can waste a LOT of locally attached storage > > before I break > > even moving to a SAN. > > > > Don't get me wrong - SAN's have their place. I just don't > think most > > companies need them. And don't even get me started on NAS boxes, > > either. > > > > ------------------------------------------------------ > > Roger D. Seielstad - MCSE > > Sr. Systems Administrator > > Inovis - Formerly Harbinger and Extricity > > Atlanta, GA > > > > > > > -----Original Message----- > > > From: Chris Levis [mailto:[EMAIL PROTECTED]] > > > Sent: Friday, October 04, 2002 11:27 AM > > > To: NT 2000 Discussions > > > Subject: RE: Basic SAN question > > > > > > > > > Thanks for the warning. > > > > > > I do plan on minimizing the number of LUNs, but my boss asked the > > > question and I wanted to be sure to have the /right/ > answer instead > > > of the /right-now/ answer. > > > > > > > -----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%% > > > > > > 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.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]
