Every critical server except Exchange boots from SAN in our environment. When we upgrade to E2003 the new servers will boot to SAN as well.
The only reason we didn't is that we have an overly complex HA solution that at the time of implementation did not support SAN boot. I'm bringing in some consultants soon to determine whether this software is even necessary. Maybe I should post the question. We've had much success with Emulex LP8000s and with W2K3 are moving to LP952s. We tried QLogic HBAs but they ultimately refused to boot. Pity - they had some nifty features. I seem to remember that Win2003 needs to see a LUN 0 but will boot from any LUN you want. With the XP-512 (and I assume the equivalent HDS), you need a command device available. -----Original Message----- From: Anthony Sollars [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 20, 2004 12:59 PM To: Exchange Discussions Subject: RE: Exchange 2k3 & SANs Oh I wasn't trying to argue, only excite some conversation from those individuals who have real world experience and willing to share personal stories of there environment, which I know you have tons of. I got some great responses since my post and now have definitive reasons to pursue the time it will take to test our configuration at length. I have the SAN admins setting up our LUNs now. Anyone have comments on doing Boot-to-SAN. Every server we build is B00t-to-SAN nowadays and they run perfectly. Just not sure if Exchange should be. -Tony P.S very = every -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ed Crowley [MVP] Sent: Tuesday, April 20, 2004 8:13 AM To: Exchange Discussions Subject: RE: Exchange 2k3 & SANs If you're going to argue with me, then please argue what I am posting, not some bizarre interpretation thereof. I just don't see how your response argues anything I actually wrote. Besides, down the thread, I posted: "You should determine the I/O rate you need the SAN to sustain and let the SAN engineer figure out how to lay out the data." That's what SANs are best at. They're a ridiculous waste of money when you try to configure them like you would direct-attached storage. As to what you call "very Exchange documentation", kindly cite the references that say this. I don't claim that some articles might say what you claim, after all it is the most risk-averse--and most costly--approach, but I don't recall ever reading a reputable article that says this. Ed Crowley MCSE+Internet MVP Freelance E-Mail Philosopher Protecting the world from PSTs and Bricked Backups!T -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Anthony Sollars Sent: Monday, April 19, 2004 9:01 PM To: Exchange Discussions Subject: RE: Exchange 2k3 & SANs Then why oh why does very Exchange documentation out there and every Vendor we have spoke with support the idea that you need to design design design your disk subsystem for exchange. This goes as far to say they highly recommend dedicating spindles only to exchange. We are planning on running 5000 users off this SAN across 2-3 Exchange servers, we just don't buy the idea of let it ride across and disks and it will be fine. We have started to develop some jet stress testing, I will let you know how it goes. If anyone has real world experiences to share please I would love to hear them, theories are welcome but may be sent to /dev/null :P. -Tony -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ed Crowley [MVP] Sent: Sunday, April 18, 2004 11:02 AM To: Exchange Discussions Subject: RE: Exchange 2k3 & SANs The RAID type you use for a single set of logs is unimportant because the log volume is almost entirely a sequential write, so there is very little seek time. A RAID-1 pair for a single set of logs should be sufficient for any number of Exchange users. Again, separating SAN drives into physical groups just to support Exchange is overly costly. If you configure the SAN as it should be configured, i.e., a "sea of drives", then you will want to work with your SAN engineer to ensure that the the SAN will be able to sustain the necessary data rates of your particular Exchange infrastructure. Ed Crowley MCSE+Internet MVP Freelance E-Mail Philosopher Protecting the world from PSTs and Bricked Backups!T -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jon Hill Sent: Sunday, April 18, 2004 8:58 AM To: Exchange Discussions Subject: RE: Exchange 2k3 & SANs Let's say you have 200GB of database and 75GB of daily logs. You will get better performance if you stripe both "disks" across five RAID groups than if you put the db on one and the logs on another. We have an HP XP-512, a storage frame comparable to (and IMHO better than) whatever model of Symmetrix was being sold in the last months of 2001. Our initial disk layout for Exchange 2000 was very badly designed (gotta love VARs), with the db and logs sharing a single RAID group. I recently took it upon myself to mitigate the design problem by moving the logs to another part of the frame but I did not detect any improvement in performance. Of course, it could be that we're just not hitting the server hard enough for disk I/O to be a problem. In certain limited situations, yes it's better to separate the db LUNs from the log LUNs, but to optimize performance you need to consider what else is on these spindles, disk controllers, ports and port controllers (in XP terms, the parity groups, ACPs, ports and CHIPs), not to mention cache. For example, if you have an I/O-intensive Oracle app on the same ports as Exchange, you may find that the port becomes a bottleneck regardless of where the Oracle data is stored. These are the kinds of things your SAN administrators will consider when allocating disk space. Unless you have reason to doubt them, trust the SAN admins to know what they're doing. -----Original Message----- From: Anthony Sollars [mailto:[EMAIL PROTECTED] Sent: Friday, April 16, 2004 2:00 PM To: Exchange Discussions Subject: Exchange 2k3 & SANs Does anyone on the list have Exchange 2k3/2k running on an EMC SAN or other comparable SAN product. We are getting a lot of push back from the SAN group because we want to design our disk layout for optimum I/O performance and have dedicated spindles for Exchange, and they don't feel it is necessary. Do any of you have any real world experience with the pains of not designing your SAN I/O properly and not following Vendor/MS best practices with disk configuration? Thanks for the input, we are planning on engaging EMC and performing some tests like these in there labs, but would like to get some real world experiences from all of you. Anthony Sollars Sr. Technology Consultant PACCAR Inc _________________________________________________________________ List posting FAQ: http://www.swinc.com/resource/exch_faq.htm Web Interface: http://intm-dl.sparklist.com/cgi-bin/lyris.pl?enter=exchange&text_mode=&lang =english To unsubscribe: mailto:[EMAIL PROTECTED] Exchange List admin: [EMAIL PROTECTED] To unsubscribe via postal mail, please contact us at: Jupitermedia Corp. Attn: Discussion List Management 475 Park Avenue South New York, NY 10016 Please include the email address which you have been contacted with. _________________________________________________________________ List posting FAQ: http://www.swinc.com/resource/exch_faq.htm Web Interface: http://intm-dl.sparklist.com/cgi-bin/lyris.pl?enter=exchange&text_mode=&lang =english To unsubscribe: mailto:[EMAIL PROTECTED] Exchange List admin: [EMAIL PROTECTED] To unsubscribe via postal mail, please contact us at: Jupitermedia Corp. Attn: Discussion List Management 475 Park Avenue South New York, NY 10016 Please include the email address which you have been contacted with. _________________________________________________________________ List posting FAQ: http://www.swinc.com/resource/exch_faq.htm Web Interface: http://intm-dl.sparklist.com/cgi-bin/lyris.pl?enter=exchange&text_mode=&lang =english To unsubscribe: mailto:[EMAIL PROTECTED] Exchange List admin: [EMAIL PROTECTED] To unsubscribe via postal mail, please contact us at: Jupitermedia Corp. Attn: Discussion List Management 475 Park Avenue South New York, NY 10016 Please include the email address which you have been contacted with. _________________________________________________________________ List posting FAQ: http://www.swinc.com/resource/exch_faq.htm Web Interface: http://intm-dl.sparklist.com/cgi-bin/lyris.pl?enter=exchange&text_mode=&lang =english To unsubscribe: mailto:[EMAIL PROTECTED] Exchange List admin: [EMAIL PROTECTED] To unsubscribe via postal mail, please contact us at: Jupitermedia Corp. Attn: Discussion List Management 475 Park Avenue South New York, NY 10016 Please include the email address which you have been contacted with. _________________________________________________________________ List posting FAQ: http://www.swinc.com/resource/exch_faq.htm Web Interface: http://intm-dl.sparklist.com/cgi-bin/lyris.pl?enter=exchange&text_mode=&lang =english To unsubscribe: mailto:[EMAIL PROTECTED] Exchange List admin: [EMAIL PROTECTED] To unsubscribe via postal mail, please contact us at: Jupitermedia Corp. Attn: Discussion List Management 475 Park Avenue South New York, NY 10016 Please include the email address which you have been contacted with. _________________________________________________________________ List posting FAQ: http://www.swinc.com/resource/exch_faq.htm Web Interface: http://intm-dl.sparklist.com/cgi-bin/lyris.pl?enter=exchange&text_mode=&lang=english To unsubscribe: mailto:[EMAIL PROTECTED] Exchange List admin: [EMAIL PROTECTED] To unsubscribe via postal mail, please contact us at: Jupitermedia Corp. Attn: Discussion List Management 475 Park Avenue South New York, NY 10016 Please include the email address which you have been contacted with. _________________________________________________________________ List posting FAQ: http://www.swinc.com/resource/exch_faq.htm Web Interface: http://intm-dl.sparklist.com/cgi-bin/lyris.pl?enter=exchange&text_mode=&lang=english To unsubscribe: mailto:[EMAIL PROTECTED] Exchange List admin: [EMAIL PROTECTED] To unsubscribe via postal mail, please contact us at: Jupitermedia Corp. Attn: Discussion List Management 475 Park Avenue South New York, NY 10016 Please include the email address which you have been contacted with.
