|
Home > Archive > Data Storage > September 2004 > Help newbie with understanding SAN configuration
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Help newbie with understanding SAN configuration
|
|
|
| Hi,
I have the opportunity to do some "on the job learning" during the next
week or so with some SAN equipment, and I was hoping that you all here
could help me get through some of the initial rough spots.
The SAN is an almost fully loaded EMC (CX700, I think). From what I've
been told, it has two "service processors" (SP), with 4 fibre channel
ports each, and a bunch of drives. I also have use of an EMC FC switch
(a DSM-32, I think).
Ok.
I've been able to muddle through most of the initial configuration of
the SAN itself, and the FC switch.
To keep things simple, I installed an Emulex LP8000 (2 ports) HBA into a
Windows 2000 PC, just for starters, and I've been able to get the SAN to
"see" the PC's HBA ports (in the switches web configurator) and, I think
vice-versa.
Again, just for starters, and to keep thing simple, I made the following
physical connections so far:
HBA port1 ---> FC Switch port 27
HBA port2 ---> FC Switch port 28
SAN SPA port 0 --> FC Switch port 30
SAN SPB port 0 --> FC Switch port 31
And now, I'm trying to figure out what I should be doing for the next
steps, so I have some questions:
1) A kind of basic question, but with a SAN like the EMC CX series, can
I "get to" or access all of the drives in the SAN from any/all of the
ports on the SPs? In other words, are all of the ports of each of the
SAN's SPs essentially the same?
2) I have the impression that I needed to "create some zones", and so in
the FC switch configurator, I did that (or tried). I initially created
one zone, and put the WWNs for HBA port1, HBA port2, SAN SPA port 0, and
SAN SPB port 0 into a single zone that I named "Win2K".
Like I said, I'm still kind of struggling through all of this, but is
the above a good way to do the zoning (both HBA ports and each of the
SPA/B ports in one single zone)?
- I guess I don't quite understand the purpose or reason for the zones,
but I have the impression from things that I've read that having all of
those 4 ports in one zone will allow them all to "talk" to each other?
- Or, should I put, say, HBA port1 and SAN SPA port 0 in one zone, and
HBA port 2 and SAN SPB port 0 in a separate zone?
- Of the two approaches above, why would I do one vs. the other?
- Actually, I'm wondering if, with the former zone config (all ports in
one zone), when I get further along and start trying to make the storage
on the SAN visible to the PC, I might end up with the PC "seeing" the
same storage twice?
I know that these are probably really elementary questions, but I'm also
hoping that this can be a good opportunity to learn something.
Unfortunately, I don't have anyone (yet) who's readily available to help
me along  .
Thanks in advance,
Jim
| |
|
| On Mon, 13 Sep 2004 21:18:58 -0400, ohaya wrote:
> Hi,
>
> I have the opportunity to do some "on the job learning" during the next
> week or so with some SAN equipment, and I was hoping that you all here
> could help me get through some of the initial rough spots.
>
> The SAN is an almost fully loaded EMC (CX700, I think). From what I've
> been told, it has two "service processors" (SP), with 4 fibre channel
> ports each, and a bunch of drives. I also have use of an EMC FC switch
> (a DSM-32, I think).
>
> Ok.
>
> I've been able to muddle through most of the initial configuration of
> the SAN itself, and the FC switch.
>
> To keep things simple, I installed an Emulex LP8000 (2 ports) HBA into a
> Windows 2000 PC, just for starters, and I've been able to get the SAN to
> "see" the PC's HBA ports (in the switches web configurator) and, I think
> vice-versa.
>
> Again, just for starters, and to keep thing simple, I made the following
> physical connections so far:
>
> HBA port1 ---> FC Switch port 27
> HBA port2 ---> FC Switch port 28
>
> SAN SPA port 0 --> FC Switch port 30
> SAN SPB port 0 --> FC Switch port 31
>
> And now, I'm trying to figure out what I should be doing for the next
> steps, so I have some questions:
>
> 1) A kind of basic question, but with a SAN like the EMC CX series, can
> I "get to" or access all of the drives in the SAN from any/all of the
> ports on the SPs? In other words, are all of the ports of each of the
> SAN's SPs essentially the same?
Each SP can have control of any drive in the CX700 only. SP A usually has
a half and SPB has the other half. Your mailage may very. SPA abd B will
"tresspass" over drives in case of failure of either SP.
SP's can see some other specail drive in other array but that is not a
standard config.
>
> 2) I have the impression that I needed to "create some zones", and so in
> the FC switch configurator, I did that (or tried). I initially created
> one zone, and put the WWNs for HBA port1, HBA port2, SAN SPA port 0, and
> SAN SPB port 0 into a single zone that I named "Win2K".
zone WWNN of SPA to WWNN HBA1
zone WWNN of SPB to WWNN HBA2
haveing 2 pouts on one HBA is still a single point of failure.
>
> Like I said, I'm still kind of struggling through all of this, but is
> the above a good way to do the zoning (both HBA ports and each of the
> SPA/B ports in one single zone)?
>
> - I guess I don't quite understand the purpose or reason for the zones,
> but I have the impression from things that I've read that having all of
> those 4 ports in one zone will allow them all to "talk" to each other?
>
roughly the same reson host have /etc/host
> - Or, should I put, say, HBA port1 and SAN SPA port 0 in one zone, and
> HBA port 2 and SAN SPB port 0 in a separate zone?
>
> - Of the two approaches above, why would I do one vs. the other?
> - Actually, I'm wondering if, with the former zone config (all ports in
> one zone), when I get further along and start trying to make the storage
> on the SAN visible to the PC, I might end up with the PC "seeing" the
> same storage twice?
Maybe depending on other issues EMC power path and Access Logix
>
> I know that these are probably really elementary questions, but I'm also
> hoping that this can be a good opportunity to learn something.
> Unfortunately, I don't have anyone (yet) who's readily available to help
> me along .
>
> Thanks in advance,
> Jim
NP Guy
| |
| ahedge 2004-09-15, 9:54 am |
|
"ohaya" <ohaya@cox.net> wrote in message news:41464702.BD254E40@cox.net...
> Hi,
>
>snip
> Again, just for starters, and to keep thing simple, I made the following
> physical connections so far:
>
> HBA port1 ---> FC Switch port 27
> HBA port2 ---> FC Switch port 28
>
> SAN SPA port 0 --> FC Switch port 30
> SAN SPB port 0 --> FC Switch port 31
>
> And now, I'm trying to figure out what I should be doing for the next
> steps, so I have some questions:
>
> 1) A kind of basic question, but with a SAN like the EMC CX series, can
> I "get to" or access all of the drives in the SAN from any/all of the
> ports on the SPs? In other words, are all of the ports of each of the
> SAN's SPs essentially the same?
yes all those ports are the same. Each should give access to all drives, but
please see below
>
> 2) I have the impression that I needed to "create some zones", and so in
> the FC switch configurator, I did that (or tried).
> snip>
> - I guess I don't quite understand the purpose or reason for the zones,
You should use zones to prevent multiple host from landing on, and possibly
destroying the content of, the same LUN/volume.
A general comment if I may: practising is good, but if you lack the basic
theory your efforts could be fruitless. Remember the million monkeys banging
on keyboards?
I say: "Get the concepts straight first "
Also, you should have plenty of software loaded on those SP: start
NaviSphere and it should open the array for you
Have fun
| |
| Arne Joris 2004-09-15, 9:54 am |
| ohaya wrote:
....
> HBA port1 ---> FC Switch port 27
> HBA port2 ---> FC Switch port 28
>
> SAN SPA port 0 --> FC Switch port 30
> SAN SPB port 0 --> FC Switch port 31
....
> - I guess I don't quite understand the purpose or reason for the zones,
> but I have the impression from things that I've read that having all of
> those 4 ports in one zone will allow them all to "talk" to each other?
>
> - Or, should I put, say, HBA port1 and SAN SPA port 0 in one zone, and
> HBA port 2 and SAN SPB port 0 in a separate zone?
>
> - Of the two approaches above, why would I do one vs. the other?
If you just want to make the host see the storage, both methodes of zoning will
work. With separate zones however, pulling a cable or disabling a port in zone1
will have no effect on traffic in zone2, so that is a clear advantage if you
care about failover (I assume you do since you have everyting dual-ported).
You can think of zones as collections of ports that can see each other and are
notified of each other's status. So if you really want a highly redundant
configuration, you would create two separate zones (on two separate frontend
switches in order to survice switch failure).
> - Actually, I'm wondering if, with the former zone config (all ports in
> one zone), when I get further along and start trying to make the storage
> on the SAN visible to the PC, I might end up with the PC "seeing" the
> same storage twice?
The HBA driver should be able to recognize that it can see the same device
through two ports, and present only a single device to you.
Actually with the one big zone, there will be 4 paths from the HBA to the volume :
HBA port 1 to SAN SPA port 0
HBA port 1 to SAN SPB port 0
HBA port 2 to SAN SPA port 0
HBA port 2 to SAN SPB port 0
Your HBA driver should be able to handle this. I don't know if the driver for
your particular HBA and platform allows you to do active/active I/O (ie. use all
paths to a volume simultaneously to send SCSI requests), or just picks one and
uses the other ones in case of failover.
Arne Joris
| |
|
|
> You should use zones to prevent multiple host from landing on, and possibly
> destroying the content of, the same LUN/volume.
With the above, you've touched upon the thing that is puzzling me about
zones/zoning. I've often seen the example (in reading) of using zones
to prevent a Windows server from seeing say, a Solaris LUN, and
vice-versa, to keep the servers from damaging the storage of each other.
But, I have the impression that both SPs can "get to" all of the drives
in the SAN. Now, let's say instead of having only one PC with a dual
HBA, I had a Windows server with a single-channel HBA, and a separate
Solaris server also with a single-channel HBA.
Now, even if I create zones such that Windows HBA port can only see SPA
port 0 and Solaris port can only see SPB port 0, and since both SPA and
SPB can see all drives in the SAN, how do the zones stop the Windows
server from seeing the LUNs for the Solaris server and vice-versa?
I guess what I'm saying is that because zones/zoning only control the
path from the server port to the SP port, and since each SP can see all
drives in the SAN, it seems like JUST ZONING BY ITSELF doesn't seem to
be able to accomplish the protection (Windows can't see Solaris LUNs,
Solaris can't see Windows LUNs)?
> A general comment if I may: practising is good, but if you lack the basic
> theory your efforts could be fruitless. Remember the million monkeys banging
> on keyboards?
>
> I say: "Get the concepts straight first "
I kind of knew that I would be having the chance to do what I'm doing,
awhile ago (weeks ago), and have been reading and reading a lot of books
etc. in preparation, but reading it in books and actually doing it is a
little different. So, I appreciate all of your patience with my
questions...
Jim
| |
|
|
>
> The HBA driver should be able to recognize that it can see the same device
> through two ports, and present only a single device to you.
> Actually with the one big zone, there will be 4 paths from the HBA to the volume :
>
> HBA port 1 to SAN SPA port 0
> HBA port 1 to SAN SPB port 0
> HBA port 2 to SAN SPA port 0
> HBA port 2 to SAN SPB port 0
>
> Your HBA driver should be able to handle this. I don't know if the driver for
> your particular HBA and platform allows you to do active/active I/O (ie. use all
> paths to a volume simultaneously to send SCSI requests), or just picks one and
> uses the other ones in case of failover.
Arne,
Thanks for your clear explanations!!
Some initial testing that I was doing, with a situation akin to what you
described above is kind of what triggered my original post.
I had put both PC/HBA ports and the one port from each of the CX700 SPs
into a single zone, and I had created two LUNs.
When I went to the Windows PC, instead of just seeing two new "drives",
I saw four. Also, although Windows seemed to see four drives, two of
the four drives acted a little strange. For example, when I tried to do
check disk, I'd get an error saying that the drive was corrupted or
something like that.
I was kind of guessing that for some reason, Windows was getting
confused, and was seeing the two drives twice (once via each HBA
channel).
I got another fellow at work to step me through some stuff, and we
deleted the zone and rebuilt it the same way again, and guess what?
After we had done all that, this time Windows only saw 2 new drives.
I really don't know why the above happened. I've gone over and over
what I did the first time, but it was the same as when I did it the
second time.
Puzzling...
Jim
| |
|
| On Tue, 14 Sep 2004 15:52:40 -0400, ohaya <ohaya@cox.net> wrote:
>
>
>
>With the above, you've touched upon the thing that is puzzling me about
>zones/zoning. ...
>I guess what I'm saying is that because zones/zoning only control the
>path from the server port to the SP port, and since each SP can see all
>drives in the SAN, it seems like JUST ZONING BY ITSELF doesn't seem to
>be able to accomplish the protection (Windows can't see Solaris LUNs,
>Solaris can't see Windows LUNs)?
>
This is correct. I can't speak for EMC storage, but on HP storage there is
Selective Presentation in addition to port zoning. This means that the
storage controller only presents the LUN to the server(s)' HBAs with
specific WWN or connection names. SAN's couldn't exist without this, so it
would surprise me if EMC didn't provide this capability as well.
--- 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)
| |
|
| On Tue, 14 Sep 2004 15:52:40 -0400, ohaya wrote:
>
>
>
> With the above, you've touched upon the thing that is puzzling me about
> zones/zoning. I've often seen the example (in reading) of using zones
> to prevent a Windows server from seeing say, a Solaris LUN, and
> vice-versa, to keep the servers from damaging the storage of each other.
>
> But, I have the impression that both SPs can "get to" all of the drives
> in the SAN. Now, let's say instead of having only one PC with a dual
> HBA, I had a Windows server with a single-channel HBA, and a separate
> Solaris server also with a single-channel HBA.
>
> Now, even if I create zones such that Windows HBA port can only see SPA
> port 0 and Solaris port can only see SPB port 0, and since both SPA and
> SPB can see all drives in the SAN, how do the zones stop the Windows
> server from seeing the LUNs for the Solaris server and vice-versa?
>
> I guess what I'm saying is that because zones/zoning only control the
> path from the server port to the SP port, and since each SP can see all
> drives in the SAN, it seems like JUST ZONING BY ITSELF doesn't seem to
> be able to accomplish the protection (Windows can't see Solaris LUNs,
> Solaris can't see Windows LUNs)?
>
>
>
>
>
> I kind of knew that I would be having the chance to do what I'm doing,
> awhile ago (weeks ago), and have been reading and reading a lot of books
> etc. in preparation, but reading it in books and actually doing it is a
> little different. So, I appreciate all of your patience with my
> questions...
>
> Jim
Zoneing is a method of mapping the host to the array.
In order to prevent 2 host from seeing the same device in your caes a LUN
in the CX you use Access Logix the is know as LUN masking.
Guy
| |
| ahedge 2004-09-15, 5:45 pm |
|
"ohaya" <ohaya@cox.net> wrote in message news:41474C08.B0885C7E@cox.net...
>
>
>
> With the above, you've touched upon the thing that is puzzling me about
> zones/zoning. I've often seen the example (in reading) of using zones
> to prevent a Windows server from seeing say, a Solaris LUN, and
> vice-versa, to keep the servers from damaging the storage of each other.
>
> But, I have the impression that both SPs can "get to" all of the drives
> in the SAN. Now, let's say instead of having only one PC with a dual
> HBA, I had a Windows server with a single-channel HBA, and a separate
> Solaris server also with a single-channel HBA.
>
> Now, even if I create zones such that Windows HBA port can only see SPA
> port 0 and Solaris port can only see SPB port 0, and since both SPA and
> SPB can see all drives in the SAN, how do the zones stop the Windows
> server from seeing the LUNs for the Solaris server and vice-versa?
>
> I guess what I'm saying is that because zones/zoning only control the
> path from the server port to the SP port, and since each SP can see all
> drives in the SAN, it seems like JUST ZONING BY ITSELF doesn't seem to
> be able to accomplish the protection (Windows can't see Solaris LUNs,
> Solaris can't see Windows LUNs)?
>
You're right, my answer was inaccurate. This paper
http://www.qlogic.com/documents/dat....lunmasking.pdf
should do a better job than I did explaining that .
| |
|
| jlsue, st0ut, ahedge, and everyone else who's replied to this thread:
Thanks for the responses, I really appreciated it, and your comments
have greatly helped me understand.
jlsue,
It looks like on the CX700, in their Navisphere tool, you create
"Storage Groups", and then you move "hosts" and "LUNs" into the Storage
Groups, and this seems to determine which LUNs can be seen by which
hosts.
So, I'm still kind of wondering about what I asked in my original post.
I've seen that statement or something similar, about using zones to
prevent access, in several places, including books. At least with the
CX700, it looks like the only thing that controls this is the Storage
Groups, and it looks like the Storage Groups don't have anything to do
with zones (which I guess are a "switch thing", not a CX700 thing).
Jim
ahedge wrote:
>
> "ohaya" <ohaya@cox.net> wrote in message news:41474C08.B0885C7E@cox.net...
> You're right, my answer was inaccurate. This paper
> http://www.qlogic.com/documents/dat....lunmasking.pdf
>
> should do a better job than I did explaining that .
| |
|
|
>
> I don't claim to know anything about how Windows handles multi-ported devices,
> but did you try to format one of the 4 drives the first time you did it ?
> If so, perhaps you caused the label to be written to the disk. Even if you tear
> down everything and re-build it, that label is still there and will be used the
> 2nd time !
>
> Arne
Arne,
HAH!
Yes, I did create a partition and format it under Windows, and that's
probably what's going on...
Thanks!!!
Jim
| |
| st0ut 2004-09-22, 10:29 pm |
| On Wed, 15 Sep 2004 17:10:50 -0400, ohaya wrote:
<snip>
> It looks like on the CX700, in their Navisphere tool, you create
> "Storage Groups", and then you move "hosts" and "LUNs" into the Storage
> Groups, and this seems to determine which LUNs can be seen by which
> hosts.
>
>
> So, I'm still kind of wondering about what I asked in my original post.
> I've seen that statement or something similar, about using zones to
> prevent access, in several places, including books. At least with the
> CX700, it looks like the only thing that controls this is the Storage
> Groups, and it looks like the Storage Groups don't have anything to do
> with zones (which I guess are a "switch thing", not a CX700 thing).
>
> Jim
>
</SNIP>
You are coorect storage groups have nothing to due with zoneing. Storage
groups are simpley methods manageing LUNS in the CX and are not in any
other type of array.
Howerver zoning is a prerequsitate to assinging a host tot a storage
group.
| |
| st0ut 2004-09-22, 10:29 pm |
| On Wed, 15 Sep 2004 21:21:42 +0000, Arne Joris wrote:
<snip>
>
> There are two ways of handling multi-ported devices :
>
> 1) the driver recognizes that several port World Wide Names access the same node
> World Wide Name and concludes it's dealing with ports on a multi-ported node
>
> 2) something above the driver (ie. the filesystem) tries to read a label from a
> reserved location on the disk.
>
> Method 1 works for most multi-ported disks, but some "virtualization devices"
> (such as EMC boxes) don't use the node and port WWN in which case this clearly
> fails.
which HBA driver does?
>
> With method 2, initially you will see 4 devices since nobody has written the
> volume label onto the reserved location yet. Then, when you write that label to
> one of the devices, suddenly the filesystem realizes it can read that same label
> from the other three devices, and concludes it must be dealing with 4 paths to
> the same device.
Using EMC powerpath would resolve this issue. Other venders such as
veritas offer multiple path resolution as well. The main limitation with
this is Windows does poorly at volume management.
>
>
> I don't claim to know anything about how Windows handles multi-ported devices,
> but did you try to format one of the 4 drives the first time you did it ?
> If so, perhaps you caused the label to be written to the disk. Even if you tear
> down everything and re-build it, that label is still there and will be used the
> 2nd time !
what you are seeing is:
\\physicaldriveX = g:\ = CX device Y
\\physicaldriveY = h:\ = CX devive Y
Not a good thing at all
Guy
</snip>
| |
| jlsue 2004-09-22, 10:29 pm |
| On Wed, 15 Sep 2004 17:10:50 -0400, ohaya <ohaya@cox.net> wrote:
>So, I'm still kind of wondering about what I asked in my original post.
>I've seen that statement or something similar, about using zones to
>prevent access, in several places, including books. At least with the
>CX700, it looks like the only thing that controls this is the Storage
>Groups, and it looks like the Storage Groups don't have anything to do
>with zones (which I guess are a "switch thing", not a CX700 thing).
>
Here's how I try to get customers to visualize zones vs lun presentation:
Zoning sorta allows you to setup a "virtual SAN" at the switch level so
that a particular (set of ) host(s) can only see themself and the storage
array(s). It prevents the "packets" of the individual hosts from being
seen by other hosts.
The storage array port must be part of each zone that needs to access it,
but the host is not in any zone that allows it to see other hosts with
which it is incompatible. I've actually seen sites that create a separate
zone for each and every host to isolate the SAN traffic for hosts. Imho,
this makes a lot of extra work whenever even moderately significant SAN
configuration changes are made, but some customers are willing to live with
that additional work/effort/time delay in implementing SAN changes.
Anyway, so now you've got your hosts isolated via zoning. Now the issue is
with individual LUNs. Here you setup the LUN to only be seen by (presented
to) specific host. Now, in some cases of clustering, you can present a LUN
to multiple hosts simultaneously, and the clustering software will be the
traffic cop for who does what, and when to that LUN. Otherwise, most LUNs
are only presented to a single host.
Does this explain a little better? Or did I miss the mark on your
question?
--- 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)
| |
| Jesper Monsted 2004-09-22, 10:29 pm |
| jlsue <jefflsxxxz@sbcglobal.net> wrote in
news:uebjk0t30bohmhdh4b8v9rntcnkf023egs@
4ax.com:
[snip]
> The storage array port must be part of each zone that needs to access
> it, but the host is not in any zone that allows it to see other hosts
> with which it is incompatible. I've actually seen sites that create a
> separate zone for each and every host to isolate the SAN traffic for
> hosts. Imho, this makes a lot of extra work whenever even moderately
> significant SAN configuration changes are made, but some customers are
> willing to live with that additional work/effort/time delay in
> implementing SAN changes.
I should certainly hope you've seen SANs with a zone for every single host
on the SAN, as this is pretty much the only Best Practice anybody
recommends. When zoning, you always want to do single-initiator zones - one
zone per HBA port (or, if you're lazy, one zone per host, but go for one
for each HBA, please). This prevents hosts from seeing each other which has
a very bad influence on some HBAs. It also prevents fabric changes (like a
host rebooting and logging out and back into the fabric) from disrupting
service to all of the hosts. Every time something logs out or in, an RSCN
is sent to all members of the zones that device is in and depending on the
HBA and driver might make it log out and in to get an updated view of the
SAN from the name server. For most HBAs, it'll only trigger a reconfigure,
which is less harmful, but still something you'll want to avoid.
Once you're done zoning, you'll want to set up LUN masking (accesslogix for
the clariion - storagegroups with luns and hosts) to present the LUNs to
the different hosts. You can have several hosts per SP port and accesslogix
should sort the rest out.
I'd recommend connecting two ports on each SP to the SAN and making zones
like this:
HBA1 to SPA port0
HBA1 to SPB port0
HBA2 to SPA port1
HBA2 to SPB port1
This will minimize the amount of outage in case of a SP, port or cable
fault.
Also, use powerpath, veritas DMP or similar multipathing software to do
failover in case one path fails.
--
/Jesper Monsted
| |
| ohaya 2004-09-22, 10:29 pm |
|
>
> I'd recommend connecting two ports on each SP to the SAN and making zones
> like this:
>
> HBA1 to SPA port0
> HBA1 to SPB port0
> HBA2 to SPA port1
> HBA2 to SPB port1
>
> This will minimize the amount of outage in case of a SP, port or cable
> fault.
>
> Also, use powerpath, veritas DMP or similar multipathing software to do
> failover in case one path fails.
Jesper,
I was taking this slowly, first working with the FC switch+CX700 without
Powerpath, but we finally installed Powerpath on Friday.
But, I'm confused about what you said above.
Did you mean to setup a total of 4 zones:
zone1: HBA1 to SPA port0
zone2: HBA1 to SPB port0
zone3: HBA2 to SPA port1
zone4: HBA2 to SPB port1
From talking to an EMC guy when we were installing Powerpath, he said
that Powerpath would only failover to ports within the same zone.
If what he said was true, and if we configured the zones as you
suggested, and if say, SPB went down, it seems like Powerpath wouldn't
be able to failover anywhere, since there's only one SP port in each
zone.
Jim
| |
| Jesper Monsted 2004-09-22, 10:29 pm |
| ohaya <ohaya@cox.net> wrote in news:414DF013.3746FD1A@cox.net:
> I was taking this slowly, first working with the FC switch+CX700
> without Powerpath, but we finally installed Powerpath on Friday.
Even without powerpath and using "manual" failover, i'd configure it the
same way.
> But, I'm confused about what you said above.
Hey, everybody's new at some point 
> Did you mean to setup a total of 4 zones:
>
> zone1: HBA1 to SPA port0
> zone2: HBA1 to SPB port0
> zone3: HBA2 to SPA port1
> zone4: HBA2 to SPB port1
That would be the ultimate way, but FC targets (storage systems, tapes etc)
usually don't mind seeing each other. Also, HBAs on the same system
shouldn't mind, but that a grey area.
We do it as follows (although zone1 and zone2 are on two different fabrics
to avoid single fabric faults):
Zone1: HBA1 to SPA/B port 0
Zone2: HBA2 to SPA/B port 1
Dual fabric is your next assignment ;)
> From talking to an EMC guy when we were installing Powerpath, he said
> that Powerpath would only failover to ports within the same zone.
Well, he was talking bullshit
Powerpath will do failover between all the instances of a LUN that the host
can see, no matter how they're zoned. Zoning it the way i've told you will
give you four paths to the LUN (assuming access logix is configured
correctly) and powerpath will do failover between all of them. This way of
configuring it allows multiple failures in your SAN at one time without
loss of productivity.
> If what he said was true, and if we configured the zones as you
> suggested, and if say, SPB went down, it seems like Powerpath wouldn't
> be able to failover anywhere, since there's only one SP port in each
> zone.
My configuration will allow failover in case of SP, sp port, switchport,
cable or HBA port failures. Since you're using a dual-port HBA, it'll die
if the entire HBA dies (well, duh ) - i always recommend multiple
singleport HBAs instead, if possible.
--
/Jesper Monsted
| |
| ohaya 2004-09-22, 10:29 pm |
| Jesper,
Thanks for all your comments and responses. Comments below,
interspersed...
Jim
> 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 ...
>
>
> Well, he was talking bullshit
>
> Powerpath will do failover between all the instances of a LUN that the host
> can see, no matter how they're zoned. Zoning it the way i've told you will
> give you four paths to the LUN (assuming access logix is configured
> correctly) and powerpath will do failover between all of them. This way of
> configuring it allows multiple failures in your SAN at one time without
> loss of productivity.
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.
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.
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
- Zones don't control the failover mechanism in Powerpath
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?
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?
Jim
| |
| jlsue 2004-09-22, 10:29 pm |
| On 19 Sep 2004 16:19:58 GMT, Jesper Monsted
<newsspam@rootweiler.dk.invalid> wrote:
>
>I should certainly hope you've seen SANs with a zone for every single host
>on the SAN, as this is pretty much the only Best Practice anybody
>recommends.
>When zoning, you always want to do single-initiator zones - one
>zone per HBA port (or, if you're lazy, one zone per host, but go for one
>for each HBA, please). This prevents hosts from seeing each other which has
>a very bad influence on some HBAs. It also prevents fabric changes (like a
>host rebooting and logging out and back into the fabric) from disrupting
>service to all of the hosts.
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.
>
>Once you're done zoning, you'll want to set up LUN masking (accesslogix for
>the clariion - storagegroups with luns and hosts) to present the LUNs to
>the different hosts. You can have several hosts per SP port and accesslogix
>should sort the rest out.
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.
>
>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.
--- 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)
| |
| George Orwell 2004-09-22, 10:29 pm |
| ohaya wrote:
...
> 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?
>
> 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?
It might not be obvious when the only things on your fabric are one host and
one storage controller.
What zoning allows you to do is to make little "islands" of hosts and storage
that can see each other, instead of just having one big fabric where everything
can see everything else. The advantage is :
1) Security : usually the R&D hosts shouldn't be allowed to do I/O to the HR
storage controler :-)
2) RSCNs spread is limited : if you powercycle a JBOD, or you unplug the cable
from an HBA, or do anything else that disrupts connectivity, the switches in
the fabric will send Registered Statce Change Notifications (RSCN) to everyone
in the same zone as the disruptor, to let them know something has changed and
some action might be required. Usually an RSCNs will at least cayse traffic
to be interrupted for a couple of seconds while everyone is figuring out what
happened.
So if R&D has a driver lockup and decides to reset their server, HR's traffic
to their storage shouldn't be interupted.
For your configuration, you might not need zoning at all, since you pretty
much have the fabric all to yourself.
Arne
| |
| Jesper Monsted 2004-09-22, 10:29 pm |
| ohaya <ohaya@cox.net> wrote in news:414F8483.2CE0657F@cox.net:
> Thanks for all your comments and responses. Comments below,
> interspersed...
No problem.
>
> 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
| |
| Jesper Monsted 2004-09-22, 10:29 pm |
| jlsue <jefflsxxxz@sbcglobal.net> wrote in
news:g3f0l057cc31ihkhh9dkf7ar7e230jro5f@
4ax.com:
> 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.
>
> 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
| |
| ohaya 2004-09-22, 10:29 pm |
| Jesper and jlsue (et al),
Thanks for all the helpful info. It has clarifed things a lot for me!!
Jim
| |
| jlsue 2004-09-22, 10:29 pm |
| On 21 Sep 2004 17:29:37 GMT, Jesper Monsted
<newsspam@rootweiler.dk.invalid> wrote:
>jlsue <jefflsxxxz@sbcglobal.net> wrote in
> news:g3f0l057cc31ihkhh9dkf7ar7e230jro5f@
4ax.com:
>
>
>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)
| |
| Jesper Monsted 2004-09-24, 5:45 pm |
| jlsue <jefflsxxxz@sbcglobal.net> wrote in
news:q1q3l0hddn5c8qknlt1kh9pk3tnh3ram3s@
4ax.com:
> 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
|
|
|
|
|