Terry, the information you provided in this email is really useful.
Can I ask one further question? In Chris's environment he has mentioned
that he has a range of Operatring Systems.
What would your opinion be on the use of FC-HBA cards that are different
models within the SAN.
I.E. Emulex in Solaris, Qlogic in Windows
All cards are going to a Brocade Switch.
Regards, Mark
----- Original Message -----
From: "Terry Lemons" <lemons_terry AT EMC DOT COM>
To: <NETWORKER AT LISTMAIL.TEMPLE DOT EDU>
Sent: Tuesday, April 08, 2003 7:57 PM
Subject: Re: [Networker] SAN Tape Drive / Storage / Host Connectivity
> Hi Chris
>
> Comments below.
>
> tl
>
> -----Original Message-----
> From: Chris Madden [mailto:maddenca AT MYREALBOX DOT COM]
> Sent: Tuesday, April 08, 2003 12:18 PM
> To: NETWORKER AT LISTMAIL.TEMPLE DOT EDU
> Subject: [Networker] SAN Tape Drive / Storage / Host Connectivity
>
>
> I have a SAN in production for disk access and we are looking at adding
> fibre tape drives to the setup, initially driving these devices from a
> single storage node and thereafter doing LAN-free backups (i.e. installing
> additional storage nodes) on some larger hosts over time. Today I have 2
> distinct SANs which are mirror copies of each other for availability, and
> have zoning implemented so that only hosts of a given OS type can see each
> other and their storage ports. Tech environment includes: IBM ESSs, AIX,
> Solaris, Win2k, Netware, and coming soon 6 x IBM 3590H and 6 x IBM LTO-2
> drives.
>
> In order to add tape devices to the SAN I have some questions:
>
> 1) Is it wise to mix disk and tape on the same SAN? My initial reaction
is
> why not if you zone correctly, but perhaps there are other issues?
>
> tl> In general, we have found that this works fine, especially if you are
> using Fibre Channel switches (instead of hubs), so each connection has its
> own dedicated bandwidth through the switch (instead of all connections
> sharing the bandwidth through a hub).
>
> 2) Can the HBAs in our hosts be used for both disk and tape access?
Again,
> my initial reaction is why not but perhaps there are other issues? Is the
> answer different for each OS and if so which are OK and which not?
>
> tl> Again, in general, we have found that this works just fine. When
SANs
> were first being deployed, there was concern about mixing tape and disk
> traffic, and there was some folklore about problems seen when you did.
> Personally, I've never seen this myself, and have been doing SAN backups
> involving tape and disk on the same SAN for several years.
>
> I would prefer to share as much infrastructure between disk and tape as
> possible and I suspect with proper zoning the same fabric can be used for
> tape and disk. If the case is however that I can't share the existing
HBAs
> and need to add a 3rd HBA for tape use I have to pick which SAN (A or B)
to
> plug it into, or I have to add a 4th HBA to get visibility to all the
> drives. At that point the complexity (i.e some drives/hosts on one SAN
and
> some on the other) suggests leaving SAN A and SAN B in place for disk, and
> creating a SAN C for tapes. Creating SAN C however has significant costs
> (more switches, more HBAs) and would need good justification.
>
> tl> Yes, adding an additional adapter and/or SAN for tape makes things
> complex very fast. And VERY expensive, too. I would anticipate having no
> problems with attaching tape drives to one of your existing SANs, IF IF IF
> you follow the recommended SAN interoperability matrix of your vendors.
EMC
> spends A LOT of time and money in these kinds of tests, and you see the
> result in the 700+ page EMC Support Matrix
>
(http://www.emc.com/horizontal/interoperability/interop_support_matrices.jsp
> ). Look for an equivalent document from your vendors, and follow it
> closely. NOTE, this is NOT a plug for EMC, but rather the Voice of
> Experience saying that, if you don't follow SAN interoperability testing
and
> configuration very closely, it will not work.
>
> tl> That said, here's another item to chew on. Disk storage arrays are
> commonly built with redundant connections, allow them to connect to
multiple
> SANs. In addition, software has been written to take advantage of these
> multiple connections for redundancy/fail over, load balancing, etc. EMC
> PowerPath is an example of this genre. One of its features is that it
> recognizes multiple connections to the same disk, but shows the operating
> system only a single device; PowerPath manages the multiple connections,
> fail over, load balancing, etc., and the operating system never sees this
> occurring.
>
> tl> BUT, the same software and features commonly don't exist for tape
> drives. So, many FC tape drives, FC tape libraries and FC bridges do not
> support multiple connections. Even if they did, I'm not aware of any
> software that can take advantage of these multiple connections; instead,
> current software (like NetWorker) would see all of the drives appearing
ONCE
> FOR EACH connection. So, if you had 5 drives with two connections to the
> SANs, NetWorker would see 10 drives. This would confuse NetWorker.
>
> tl> So, plan on being able to access your tape resources through a single
> connection, and just live with the lack of redundancy. Given that
> businesses can survive minutes without tape access (IMO), this give time
to
> manually move cables, if this is ever needed.
>
> Fellow NetWorkers, what would you do in my shoes?
> tl> I would add tape resources to one of your existing SANs, make use of
> the NetWorker SAN-based storage node licenses (formerly, "SAN Storage
Node",
> now called "Dedicated Storage Node"), use dynamic drive sharing (to share
> some/all of your tape drives - DDS is licensed per tape drive). I'd also
> have as few tape drive types as possible in my environment (why get both
> 3590 and LTO2?).
>
> tl> Hope this helps!
> tl
>
>
> Kind Regards,
> Chris
>
> --
> Note: To sign off this list, send a "signoff networker" command via email
> to listserv AT listmail.temple DOT edu or visit the list's Web site at
> http://listmail.temple.edu/archives/networker.html where you can
> also view and post messages to the list.
> =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
>
> --
> Note: To sign off this list, send a "signoff networker" command via email
> to listserv AT listmail.temple DOT edu or visit the list's Web site at
> http://listmail.temple.edu/archives/networker.html where you can
> also view and post messages to the list.
> =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
>
--
Note: To sign off this list, send a "signoff networker" command via email
to listserv AT listmail.temple DOT edu or visit the list's Web site at
http://listmail.temple.edu/archives/networker.html where you can
also view and post messages to the list.
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
|
