1748139 Members
3982 Online
108758 Solutions
New Discussion юеВ

Re: LUN presentation

 
Domen Setar
Advisor

LUN presentation

Hi,

I have a standalone OpenVMS server A with a LUN presented and an application which writes data on that LUN. I want to present the same LUN to another standalone OpenVMS server B only to read the data from it. Would it be enough to present LUN to server A in read/write mode and to server B in read only mode? I don't want to put the servers into cluster.

Regards

Domen
8 REPLIES 8
abrsvc
Respected Contributor

Re: LUN presentation

Additional details are required here. LUN usually refers to Logical Unit Numbers which are I/O channels associated with either Fortran or Basic and have no meaning outside of the specific process involved. It seems like you are looking for a communications pathway between 2 separate VMS systems where the first feeds the second. Can you please further describe what you'd like to do as well as the system types and VMS versions involved?

Thanks,
Dan
Robert Gezelter
Honored Contributor

Re: LUN presentation

Domen,

Such a configuration has problems with consistency of file structures. System B will not have knowledge of changes that System A made to the on disk structures.

Mounting a disk from two non-clustered nodes simultaneously (even with one node restricted to read-only) is not a reliable technique.

This type of functionality can easily be created using DECnet over an Ethernet between the two systems using DECnet transparent file access.

- Bob Gezelter, http://www.rlgsc.com
Hoff
Honored Contributor

Re: LUN presentation

The use of LUN here is a Fibre Channel Storage Area Network (FC SAN) disk storage reference, and the goal is likely operating and accessing one disk LUN across two or more disparate OpenVMS configurations (some combination of standalone hosts and/or clusters) and this requires all but one of the configurations involved must mount the disks involved as MOUNT /NOWRITE.

This is analogous to VMS V3 CI configurations.

You'll likely need to have the current patches loaded for whatever VMS version is involved.

Mistakes here will corrupt the disks. (Any lurking VMS bugs, too, for that matter.)

Off-hand, I don't know if this configuration would be considered as supported by HP (I'd assume "not"), and I'd definitely work this question through HP support.
Mike Kier
Valued Contributor

Re: LUN presentation

If DECnet (native or over IP) is available, then DECdfs might be a viable option.
Practice Random Acts of VMS Marketing
Robert Gezelter
Honored Contributor

Re: LUN presentation

Domen,

A clarification on my earlier post.

I was not referring to DECdfs. I was referring to a logical name translating to a value that included a DECnet path, to wit:

$ ASSIGN "nodename""user pass""::device:[directory]" OTHER_SYSTEM
$ DIRECTORY OTHER_SYSTEM:

(Apologies if typo, do not have access to my systems from where I am at the moment).

One can also suppress the need to specify username and password by using entries in the proxy file(s).

- Bob Gezelter, http://www.rlgsc.com
abrsvc
Respected Contributor

Re: LUN presentation

Hoff,

Thanks for the update. I'm in the middel of a Fortran system at the moment and had a brain freeze. Funny thing is that I'm trying to resolve a LUN problem with files being written to the wrong files... (Programming error not yet found)
Hoff
Honored Contributor

Re: LUN presentation

ps: You might want to elaborate on exactly what you mean by this:

"I want to present the same LUN to another standalone OpenVMS server B only to read the data from it."

Why do I ask?

There are potentially mechanisms and protocols and alternatives available here.

These can range from NFS and DECdfs along to DECnet FAL and RMS to ODBC/JDBC to... that can allow remote data access, to remote logs from more modern distributed file systems or logs or journals from databases, and that won't require cross-mounting disks across DLM domains.

If you're making a backup here, then running that out at the controller (which is dumb as a post, but fast) might be an option. This particularly if you can temporarily quiesce your application and flush to disk.

SAN-level stuff is just an incredibly nasty layer for this sort of stuff, too, and as every generation of storage engineer seemingly eventually realizes. The usual SAN-level stuff is always mostly functional, but it's not coordinated with the host in any fashion. (I first encountered these implementations back in the 1980s, and (without some sort of host coordination) the design works now about as well as it did then. The implications around how applications and host caches and multi-block writes can lead to some nasty problems for online and near-line archiving, and particularly for distributed shared write. (This general host-coordination problem also analogous to what TRIM tries to address, for those looking at SSDs, but I digress.)

Most anybody designing an application or an OS is usually trying to avoid hitting the disks, except for transactional logging, and then only when you're running replicated and non-grid, or when some design requires fully disk-synchronous. (And even then, the performance of those rotating rust widgets is just glacial.)
EdgarZamora_1
Respected Contributor

Re: LUN presentation

If you have a SAN and if your SAN technology is able to create a "snapshot" of the data (disk/lun/volume etc... terminology changes depending on the SAN), you'd be better off presenting that snapshot lun to the other server.