You know I use to be wary of hot plug drives, RAID parity, and working on files off a remote file server too.
-----Original Message----- From: Ken Coughlin [mailto:ken@;Xcitek.com] Sent: Tuesday, October 08, 2002 7:34 AM To: NT 2000 Discussions Subject: RE: Basic SAN question If you think about how much data and how often data is moved into and out of a paging file, I would be wary of putting any paging file on a network too. Always opt to put you paging file on a local drive. Ken -----Original Message----- From: Shea, Linchi [mailto:LShea@;exchange.ml.com] Sent: Monday, October 07, 2002 5:36 PM To: NT 2000 Discussions Subject: RE: Basic SAN question The EMC engineers on site here seem to be very wary of going totally diskless, and the answer to why is because the paging files when you have a few hundreds of hosts hooking to the same EMC SAN (Symmetrix 3830 or better). I don't totally understand the issue yet. But they told me it's mostly to do with performance. Linchi > -----Original Message----- > From: Wes Owen [mailto:WOwen@;HNTB.com] > 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:LShea@;exchange.ml.com] > 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:WOwen@;HNTB.com] > > 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:roger.seielstad@;inovis.com] > > 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:clevis@;appgeo.com] > > > 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:roger.seielstad@;inovis.com] > > > > 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:clevis@;appgeo.com] > > > > > 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]
