Personally, I like to boot from local mirrored disks so that I can break
the mirror before installing OS patches. I realize that most (all?) SAN
vendors have some sort of snapshot utility, but this way I can control
the break without having to coordinate with the SAN guy.

-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jon
Hill
Sent: Tuesday, April 20, 2004 1:09 PM
To: Exchange Discussions
Subject: RE: Exchange 2k3 & SANs


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.



_________________________________________________________________
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.

Reply via email to