Help newbie with understanding SAN configuration

ohaya wrote in :
Thanks for all your comments and responses. Comments below,
interspersed...

No problem.

Dual fabric is your next assignment

Unfortunately, for this configuration that I'm getting to work with, I
only have one FC switch, a 32-port DSM something or other, so I can't
configure a mesh ...

DS-32M2, most likely. It's a McData Sphereon 3232 in disguise

That (the "bull...." part) was kind of what I figured.

I don't think he meant to deceive, I think he just doesn't quite
understand his product , as during my conversations with him, where
I've asked him some other pretty basic questions, I got answers that
didn't "quite" make sense.

Or he just explained it wrong, assuming that you had no idea what he was
talking about.

That's when I decided to post my questions here , as I've noted that
you all seem to have a lot of experience with SANs.

Well, a few of us do this stuff for a living

*mutters about roughly 1200 ports and 300 TB of disk*

Having said that, ok, from this thread, it seems like:

- Zones by themselves can't prevent the situation I mentioned earlier
(Windows server not seeing Solaris LUN and Solaris server not seeing
Windows LUN), and

Correct - LUN masking does that.

- Zones don't control the failover mechanism in Powerpath

Correct - as long as a host sees the disk, powerpath is happy.

So, getting back to one of the questions in my first couple of posts,
what ARE zones good for? Why do I even need them?

It keeps different hosts on the SAN from interfering with each other,
disallows hosts from accessing storage systems that they're not supposed
to and keeps RSCN broadcasts to a minimum (think windows file server
broadcast storms).

I think I'm having a really hard time expressing the above question
....

Let me put it another way: If there was no such concept as zones in
the FC switch, what (functionality) COULDN'T I do that I can do with
having the zones capability in the FC switch?

You could do everything without zones, it just wouldn't be as safe and as
stable.

--
/Jesper Monsted

jlsue wrote in
:

Not sure what SAN products you use. For the ones I deal with
regularly, this is not a requirement, and it works reliably without
all these zones. You can do it, but it is certainly NOT a best
practice recommendation. The key is choosing your SAN products
carefully and, in my case, only supported configurations are serviced
by us.

McData. It is by no means a requirement, but if you want a little security
on your san (I don't trust Windows's and Tru64's FC capabilities not
fscking up everybody else) and keep the confusion to a minimum, i'd
certainly recommend any doing a san with more than one logical host (could
be a cluster) to use it.

We don't need LUN masking for all storage products. Selective
Presentation is done at the controller level and basically selects the
paths that it will serve the lun over - the GUI simplifies this by
allowing you to select a host (or more hosts, depending on your OS and
configuration) who can access the LUN.

Selective presentation *IS* LUN masking. Whether or not that is done in a
GUI or from a command line like NaviCLI (Clariion) or symcli (Symmetrix)
doesn't really matter. Either way, a storage system with more than one host
connected to a single port will definately need it.

Also, use powerpath, veritas DMP or similar multipathing software to
do failover in case one path fails.

In our case, it's SecurePath, and it is required for almost all SAN
configurations.

Unless you only have a single path to your storage, but that wouldn't be
too great. We do have a few test systems on the production SAN running that
way, though.


--
/Jesper Monsted

Jesper and jlsue (et al),

Thanks for all the helpful info. It has clarifed things a lot for me!!

Jim

On 21 Sep 2004 17:29:37 GMT, Jesper Monsted
wrote:

jlsue wrote in
:


In our case, it's SecurePath, and it is required for almost all SAN
configurations.

Unless you only have a single path to your storage, but that wouldn't be
too great. We do have a few test systems on the production SAN running that
way, though.

Well, what I've found is that with single-attached hosts, and a storage
array with two connections to the same switch (normally 4 connections
total, two to each switch), unless you zone out one of the ports you need
SecurePath-like functionality because the LUN will be presented over both
paths.

And if you zone out one of the two ports, then you don't have fail-over.

So, in theory, I might find a case where a server doesn't need
multi-pathing software. But in practice it only occurs rarely. And then I
might question the business reasons for putting such a server on the SAN
anyway. It seems that there would be some kind of disconnect in strategy.

--- jls
The preceding message was personal opinion only.
I do not speak in any authorized capacity for anyone,
and certainly not my employer.
(get rid of the xxxz in my address to e-mail)

jlsue wrote in
:

Well, what I've found is that with single-attached hosts, and a
storage array with two connections to the same switch (normally 4
connections total, two to each switch), unless you zone out one of the
ports you need SecurePath-like functionality because the LUN will be
presented over both paths.

And if you zone out one of the two ports, then you don't have
fail-over.

Nope, and that's what they've paid for. It's "good enough" for most of the
development and test crap, but i do try to avoid getting anything on the
san with only one HBA, no matter what they're going to be doing.

So, in theory, I might find a case where a server doesn't need
multi-pathing software. But in practice it only occurs rarely. And
then I might question the business reasons for putting such a server
on the SAN anyway. It seems that there would be some kind of
disconnect in strategy.

Usually price - they need the storage, but don't want to pay for it. Since
both powerpath and extra hbas costs money, they're one a single path.

--
/Jesper Monsted