Still, however, you're dealing with 3 year old installs. In 3 years, Server.Net V2 will be current, and Win2k will be reaching end of support.
I guess I wouldn't consider that a viable option because I don't do inplace OS upgrades - we, as a company, only do fresh installs of OS's. We'll service pack, but going say NT to Win2k, or Win2k to .Net, it will always be a bare metal install. I've also received significant buy in that the life span of production hardware, with few exceptions, equals the lifespan of the support contract - 3 years. Beyond that, its relegated to test and QA work[1]. On the flip side, we don't lease servers, so there isn't a hard and fast 3 year limit. I've got some just out of warranty hardware to replace in the coming year, but not too much. ------------------------------------------------------ Roger D. Seielstad - MCSE Sr. Systems Administrator Inovis - Formerly Harbinger and Extricity Atlanta, GA [1] We're a software development company, so it pays to have some old hardware around > -----Original Message----- > From: Wes Owen [mailto:[EMAIL PROTECTED]] > Sent: Monday, October 07, 2002 4:37 PM > To: NT 2000 Discussions > Subject: RE: Basic SAN question > > > Completely understand the question. I struggled with this myself. > > So long as you keep the SAN/HBA cards the same you should be > able to replace > servers easily. > > Many times when servers come off lease we are not looking to > rebuild an OS. > If the timing works out we do use that as an opportunity. > But in most cases > we would like to simply be able to swap out the hardware. > OS's are replaced > such as NT to W2K or W2K to .NET as a separate project. > > In the old days of NT we had very poor control over what was > installed on > servers and looked forward to the replacements as an > opportunity to clean > things up. We have much better control over things now and > do not see that > being quite the issue it once was. > > -----Original Message----- > From: Roger Seielstad [mailto:[EMAIL PROTECTED]] > Sent: Monday, October 07, 2002 3:29 PM > To: NT 2000 Discussions > Subject: RE: Basic SAN question > > > That really makes sense - servers don't like when their > direct attached > storage drops access to the pagefile, either. Trust me. > > One question I have is that you've stated that you're looking > to be able to > swap the front end off when the lease expires, so you can > ship the hardware > back. So you're planning on forklift upgrading your servers? Are you > planning on inplace upgrades for OS's, since in 3 years, > Win2k probably > won't be supported anymore? > > Not trying to bait or anything - as I said - I've got really > big issues with > the lines that SAN vendors use to hook companies in. If they > are accurate, > that's great, but I'm not willing to risk my environment on > it until someone > else who *isn't* a SAN vendor proves it works day in, day out. > > Roger > ------------------------------------------------------ > Roger D. Seielstad - MCSE > Sr. Systems Administrator > Inovis - Formerly Harbinger and Extricity > Atlanta, GA > > > > -----Original Message----- > > From: Wes Owen [mailto:[EMAIL PROTECTED]] > > Sent: Monday, October 07, 2002 4:15 PM > > To: NT 2000 Discussions > > Subject: RE: Basic SAN question > > > > > > We are completely diskless. Not doing so would have made > > the need for an > > array card and a pair of drives in the server, which is the > > costs we were > > trying to avoid. As I could not say removing the redundancy > > for the drives > > so long as the page file was still there as then a single > > drive failure > > would have brought the server down. > > > > Yes, there are some possible issues with the boot from SAN > > and the paging > > file if connectivity is interrupted. While I have had a > > number of persons > > tell me this is an issue, I have not had anyone that could > > tell me what > > actually happens if the problem occurs. > > > > After talking with my EMC engineers and talking to customers, > > some that are > > and some that are not, no one that I spoke to has ever > actually had a > > problem with the page file being on the SAN. The only caveat > > EMC would give > > me is that you may want to shut servers down that have page > > files on the SAN > > during microcode upgrades. > > > > -----Original Message----- > > From: Shea, Linchi [mailto:[EMAIL PROTECTED]] > > Sent: Monday, October 07, 2002 3:06 PM > > To: NT 2000 Discussions > > Subject: RE: Basic SAN question > > > > > > Owen, as I understand there are still issues with boot from > the SAN, > > particularly with paging. IN your configuration, do you > place the page > > files on the SAN or on the locally attached drives? > > > > Linchi > > > > > -----Original Message----- > > > From: Wes Owen [mailto:[EMAIL PROTECTED]] > > > 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. > > > > > > > > > > > > ------ > > > > > > 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.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]
