I wish our management would let us do the same. Just like we wish we could keep them from installing non-licensed software, keep them from changing their machines around so that their virus signatures get updated, so that SMS can inventory their systems, or that they would not have admin rights on their machines.
Sorry, but we simply do not get the backing to say no, as long as they say "We need it for XXXXX." -----Original Message----- From: Andrew S. Baker [mailto:[EMAIL PROTECTED]] Sent: Friday, October 04, 2002 9:43 PM To: NT 2000 Discussions Subject: RE: Basic SAN question ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ We had a huge problem with our DBA's and developers insisting they might need 100 to 400 GB's of drive space over the course of a server lease and then when it came off lease they actually only had 20 or 30 GB's of data on the system. This allows me to only give them what they need at first and then scale it up as needed with minimal disruption. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ We make our developers provide stats which would validate their claims for space... ============================================================== ASB - http://www.ultratech-llc.com/KB/?File=~MoreInfo.TXT ============================================================== -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Wes Owen Sent: Friday, October 04, 2002 2:51 PM To: NT 2000 Discussions Subject: RE: Basic SAN question I would have to offer up a differing opinion. I did a pretty extensive cost analysis and was able to show a break even point by using SAN. Two factors entered in. Better utilization of disk capacity and the boot from SAN capability eliminated not only the drives, but also the cost of the array controller. The other soft costs of backup and manageability provided the ROI. We had a huge problem with our DBA's and developers insisting they might need 100 to 400 GB's of drive space over the course of a server lease and then when it came off lease they actually only had 20 or 30 GB's of data on the system. This allows me to only give them what they need at first and then scale it up as needed with minimal disruption. -----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. > > > --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.393 / Virus Database: 223 - Release Date: 9/30/2002 ------ 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]
