- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Re: LUN presentation
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО03-11-2011 05:04 AM
тАО03-11-2011 05:04 AM
LUN presentation
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО03-11-2011 05:12 AM
тАО03-11-2011 05:12 AM
Re: LUN presentation
Thanks,
Dan
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО03-11-2011 06:31 AM
тАО03-11-2011 06:31 AM
Re: LUN presentation
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО03-11-2011 06:35 AM
тАО03-11-2011 06:35 AM
Re: LUN presentation
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО03-11-2011 07:28 AM
тАО03-11-2011 07:28 AM
Re: LUN presentation
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО03-11-2011 07:40 AM
тАО03-11-2011 07:40 AM
Re: LUN presentation
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО03-11-2011 07:45 AM
тАО03-11-2011 07:45 AM
Re: LUN presentation
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)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО03-11-2011 09:10 AM
тАО03-11-2011 09:10 AM
Re: LUN presentation
"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.)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО03-11-2011 12:41 PM
тАО03-11-2011 12:41 PM