Hi,

we want to connect different servers (HP, AIX, Windows, Solaris) with
different (!) HBA Ports to different (!) SANs - one port goes to a
CISCO SAN another port goes to a Brocade SAN.
(so we are not talking about mixing switches from different vendor in
the same fabric which of course would be a nightmare).

the question that raised up was about the support and certificiation of
the different server vendors. Will they support connecting their
servers to different san switch vendors?

Do you see issues in doing this? It comes into my mind, that some san
vendors require e.g. specific hba firmware that others wont support. Do
you see such issues too?

Thanx in advance for your help

Martin

P.S: The reason for connecting to different SANs is breaking up our
existing Brocade SAN which was too large with its 1800 ports with a
second cisco SAN. This second SAN is used for backup purpose only.

[ Post a follow-up to this message ]

I'd like to know a little bit more about the specifics of the switch
types you are using.  I guess I've never heard of a Brocade with that
many ports.  Another concern I have is whether or not you will have any
path redundancy.  Running a single path to each storage will work, but
if this is critical production data I would not recommend your current
proposal.  If you are going to present two types of storage to your
server, that should not be a problem.  You will want to look at each
storage vendor's support matrix to make your decision on how you mix
the HBA's.  Your best bet is going to be having one brand such as
QLogic for the first type of storage and Emulex for another.

Can provide model numbers I can start to more accurately understand
what you are trying to do?

mrs wrote:
> Hi,
>
> we want to connect different servers (HP, AIX, Windows, Solaris) with
> different (!) HBA Ports to different (!) SANs - one port goes to a
> cisco SAN another port goes to a Brocade SAN.
> (so we are not talking about mixing switches from different vendor in
> the same fabric which of course would be a nightmare).
>
> the question that raised up was about the support and certificiation of
> the different server vendors. Will they support connecting their
> servers to different san switch vendors?
>
> Do you see issues in doing this? It comes into my mind, that some san
> vendors require e.g. specific hba firmware that others wont support. Do
> you see such issues too?
>
> Thanx in advance for your help
>
> Martin
>
> P.S: The reason for connecting to different SANs is breaking up our
> existing Brocade SAN which was too large with its 1800 ports with a
> second cisco SAN. This second SAN is used for backup purpose only.

[ Post a follow-up to this message ]

"Gunhaver05" <jeff.abbott01@gmail.com> wrote in message
news:1163959462.052051.261160@h48g2000cwc.googlegroups.com...
> I'd like to know a little bit more about the specifics of the switch
> types you are using.  I guess I've never heard of a Brocade with that
> many ports.

Core-edge design will give you this amount of ports in no time. Put a nice
fat Director-class switch in the middle and fan each port out through
smaller edge switches. Brocade SilkWorm 48000 core with SW4100 or SW4900
edge for instance..

Rob

[ Post a follow-up to this message ]

On 18 Nov 2006 16:10:02 -0800, "mrs" <martin.schimmer@gmx.net> wrote:

>Hi,
>
>we want to connect different servers (HP, AIX, Windows, Solaris) with
>different (!) HBA Ports to different (!) SANs - one port goes to a
>CISCO SAN another port goes to a Brocade SAN.
>(so we are not talking about mixing switches from different vendor in
>the same fabric which of course would be a nightmare).
>
>the question that raised up was about the support and certificiation of
>the different server vendors. Will they support connecting their
>servers to different san switch vendors?
>
>Do you see issues in doing this? It comes into my mind, that some san
>vendors require e.g. specific hba firmware that others wont support. Do
>you see such issues too?
>
>Thanx in advance for your help
>
>Martin
>
>P.S: The reason for connecting to different SANs is breaking up our
>existing Brocade SAN which was too large with its 1800 ports with a
>second cisco SAN. This second SAN is used for backup purpose only.

Well, I question the motivation that starts with the presumption that
a SAN is "too large".  But anyway...

You'd probably need to have different HBA models to be supported for
the two different switches.  When you say "with different HBA ports to
different SANs", do you mean that it is a dual-port HBA, and each port
is connected to a separate SAN?  Or do you actually have multiple
HBAs?

It is important to make sure that each HBA is at the correct/supported
firmware versions and driver versions for the switch with which it
will be communicating.  If you are using a single, dual-ported HBA,
this might be difficult/impossible to meet the requirements of both
switch vendors, let alone the complexity of support from the
platform/OS vendors, and you could be in for some "interesting" times.

It may not be an impossible task to get all this right, but it is
complex, and you'll have to have some seriously good configuration
documentation, including the hows/whys, keep these updated/accurate
constantly, and have the infrastructure processes in place to prevent
incorrect configuration.

I don't mean to scare anyone off from this - IMHO, you should pretty
much have all this anyway - but if you don't have it all in place now,
it can get pretty nasty pretty fast.

Another potential implication of this request is that you are
describing a configuration with one single connection for each server
to the "data SAN", and one connection to the "backup SAN".  If this is
the case, you are introducing potential single-points-of-failure
(SPOF) into the overall SAN design.  That alone would keep me awake at
night.

What I would do is start with the business level, understand their
drivers and goals for the servers/applications.  Define the business
value of these as well - and use this to help them make the optimal
decisions for their IT investment strategy.  Then use this in the
technical architecture & design of the SAN environment(s) to insure
that you do not implement a design which can't meet their
expectations.

[ Post a follow-up to this message ]