Shared Tape Configuration Basics

[Ralph Grothe]

Hello,

I configured an MC/SG cluster last Friday and ran today into troubles regarding differing tape device names because of OmniBack.
I've been told by our SAN guru that OmniBack requires identical device names on every cluster node.
The most I could accomplish was to generate identical ext_busses by instance No. changes.
But I cannot influence the target No.
From anothe HP guy who implemented Omniback here I got the hint towards ats.
Since I've never come accross shared tape services in an MC/SG cluster before I digged throup a couple of related manpages and came accross the stquerycl command, which obviously is closely modelled to the well-known cmquerycl command, and whose end seems to be to gather a basic configuration.
Now when I ran stquerycl it aborted with this error:

# stquerycl
Kernel tuneable st_ats_enabled disabled on node warnow. May not do shared tape configurat
ion. (ATS 7.17)
Kernel tuneable st_ats_enabled disabled on node alster. May not do shared tape configurat
ion. (ATS 7.17)
Failed while gathering ATS information. (ATS 4.201)

Hm, looks as if yet another kernel tunable needs alignment:

# kmtune -q st_ats_enabled
Parameter Current Dyn Planned Module Version
===============================================================================
st_ats_enabled 0 - 0

I assume this needs to be set to 1 on all cluster nodes (I really hoped to get by without another reboot, but it's static :-(

Unfortunately, th manpages of atsconf and stquerycl are a bit sloppy, because they don't even mention this kernel tunable as a prerequisite.

Can anyone confirm my assumption?

Will stquerycl produce an ascii config file similarly well commented like the notorious clusterconfig.ascii (or whatever else named) from cmquerycl?

Is there any sample configuration available?

Rgds.
Ralph

[melvyn burnard]

firstly, which OS version are you using, and which Sg version and which Sg patch?
Second, you may want to take a look at the Using Advanced Tape Servies manual at:
http://docs.hp.com/hpux/onlinedocs/B3936-90032/B3936-90032.html

Be aware, ATS requires VERY specific hardware and SAN's have taken over, may soon be obsoleted.

[A. Clay Stephenson]

Nonsense. OB2 does not require identical device names. For years I've used drives attached to multiple hosts and had no problems and the device names were frequently different. In fact, they were only the same by accident. Consider this problem (even on the same node). /dev/rmt/0m and /dev/rmt/0mnb - the same physical device but these could be different OB2 logical devices. I typically have something like "STK9714_D1_Prissy" and "STK9714_D1_Marvin". These are the same physical device, the device nodes are usually different. The only thing that prevent OB2 from using these devices simultaneously is the OB2 "Lock Name". Make sure that the Lock Name is trhe same for all logical devices that share a common physical device.

[melvyn burnard]

The attached White Paper may help you here.
It discusses San configurations wiht ServiceGuard and OmniBack

[Ralph Grothe]

Melvyn,

many thanks for the link to the ATS Users' Manual.
Meanwhile I had received the very document as a PDF attachment from the HP support engineer who is currently servicing my support call.
I'd also be very keen on the whitepaper attached to your second reply.
Unfortunately I could neither open it in my AcroReader nor save it to a file since it seems corrupt somehow.
Would you mind reposting the URL from where I could download it?

Clay,

that's interesting to here that OmniBack by far doesn't impose a unique device naming scheme.
I only reported (possibly imprecisely) what I'd been told by our SAN "guru".
The whole OmniBack stuff totally passed me unnoticed, and so far I haven't been given even a short introduction on our SAN infrastructure nor OmniBack implementation nor been forwarded any documentation.
I was only the guy who was responsible for setting up this cluster with no feed-in about possible caveats or implications with regard to our SAN/OB layout.

[melvyn burnard]

ah, the attachment seems to have failed then
I have requested tat the docment be made available on docs.hp.com, but do not know when this will happen.
Please post an email addres I can send it to,

[Stephen Doud]

Hi Ralph,

I advise against considering implementation of ATS (Advanced Tape Services) as it will be phased out due to lack of popularity. As Melvyn indicated, it has particular hardware requirements which are difficult to satisfy lately. New customers cannot purchase the only supported Fibre Channel SCSI bridge certified with SG; Fibre Channel SCSI Multiplexing 4/2.
This means only existing customers that already have the supported ATS hardware can continue to use this feature until HP-UX 11.0 or HP-UX 11i are obsolete. Currently ATS is only supported in MC/ServiceGuard clusters of four nodes or less; meaning 2, 3, and 4 node clusters.
New customers are advised to use alternative shared tape solutions like HP's Omniback or VERITAS's Netbackup.
-S.