- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Re: A Cluster that isn't?
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
тАО05-09-2005 06:08 PM
тАО05-09-2005 06:08 PM
A Cluster that isn't?
Until such time as we get production to DR Site replication of the HDS Storage (don't hold breath). I need to use Legato Networker for backup and restore (another strategic decision) from production to DR (via an intervening tape robot (STK L700) As such, I really need a barebones VMS 7.3-2, with appropriate IP Setup, SAN bits, and Legato bits) in order to be able to trigger the restores.
Data Disks are not an issue, the challenge comes when restoring the system disk, as "Networker" does file backups only, not impage, and as such will not create a bootable disk.
What is mulling in my mind, is that we set up the above as one cluster system root(say sys0.) and then restore the production system disk (Legato) backup to (sys1.)
Then Reboot from sys1 instead of sys0. meaning that we are booting from the restored (non image) copy of the production system, rather than the minimum OS.
Questions.
1. Do I then need to writeboot to allow booting from sys1? My gut feel is no, as writeboot deals with vms$common.sysexe] apb.exe
2. Do I need to turn on Clustering to do this?
3. TCPIP files are all over the place between Sys$sysroot: and sys$common: - I guess I can work that out (THis place also insists on hard-coded Ip's rather than DNS's for failover... )
What I plan to end up with is a single node cluster, where one machine can boot off more than one root. Does this make sense?
Q
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-09-2005 07:17 PM
тАО05-09-2005 07:17 PM
Re: A Cluster that isn't?
1. No need indeed for your intented configuration.
2. Probably, to be able to create [SYS1] (using Cluster_Config.com) but it might be you can do without. However, I think it's a better idea to create a one-node cluster. Startup may be slower (since it won't find another member within timeout).
3. Most Services have their own directory, located in either SYS$SYSDEVICE or SYS$SYSROOT. I expect they all have the ability to define a logical TCPIP$
For the TCPIP*.DAT files - I founds some in [SYS0.SYS$STARTUP] and [SYS0.SYSCOMMON.SYSEXE], making them node-specific (that makes sense). In a non-clustered system, I found the latter ones in [VMS$COMMON] as well but I expect that in a clustered systm it may be a different case (I have no access to a clusteerd machine at the moment).
Using hard-coded IP's isn't a bad idea, you could think of sharing TCPIP$HOSTS.DAT (on the VMS boxes).
If you succeeed in setting up this one-node cluster, it indeed would make sense.
Just another consideration: Is it possible to add a second (smaller) disk in that node and shadow this to the normnal system disk? Just boot from another disk.
(Weird. can't you create an image backup using Legato?)
OpenVMS Developer & System Manager
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-09-2005 07:53 PM
тАО05-09-2005 07:53 PM
Re: A Cluster that isn't?
I would expect most problems in this approach to come from the OpenVMS system disk structure (rooted directories). A file backup probably does not understand this and will get confused when restoring the directory trees.
Answers:
1. My gut feel is the same as yours ;-)
2. no, you can boot a standalone system from any valid root on the system disk. Does not need VAXCLUSTER .ne. 0
3. The problems may start with TCPIP files in SYS$COMMON. The configuration file is in SYS$COMMON:[SYSEXE] - valid for all roots on that disk - SCSNODE is the key (e.g. if you change SCSNODE of your root, you loose most of your TCPIP config information). Would the restore of the backup then overwrite that file (with the version of your production node) or skip that file, as it already exists ? In either case, your TCPIP config is not consistent anymore.
Volker.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-09-2005 08:52 PM
тАО05-09-2005 08:52 PM
Re: A Cluster that isn't?
An OpenVMS system disk, clustered or standalone, contains a several directories which are aliased (they appear at multiple points in the directory structure).
Booting off of an alternate system root does not exclude the use of this structure, so booting from the same system device with a different root does not get very much in terms of not using the other root's files, since the vast majority of files are shared between the roots. The exception is the classic standalone backup. Files which are indexed by nodename, such as the previously mentioned TCPIP configuration files, are another problem.
Restoring these files out from under a running system can produce unpredicatable results.
However, you do have the germ of a useable idea here. You can accomplish what you want to do by using an alternate system disk, doing the base restores, and then rebooting from the restored system disk. There are also other alternatives, some of which I have implemented for clients.
I hope that the above is helpful.
- Bob Gezelter, http://www.rlgsc.com
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-09-2005 09:01 PM
тАО05-09-2005 09:01 PM
Re: A Cluster that isn't?
well, in my view your problem still raises more questions than answers.
Let me start with summing my _ASSUMPTIONS_ from your text.
Firstly, since you ARE building a DR site, my guess is that cost may be an interesting aspect, but not the biggest bottleneck, right?
Then, you have ANOTHER, equivalent system at your DR site, do you?
Your users can access your DR location as well as your production location from their work location? Or do you have a DR site for 'vital' workers as well?
Quite important: what is the distance between your Production site and your DR site? What connection do you have / can you get between those sites?
What is your exact method of replication? Lagato backup to an intervening robot, and then? Does the same robot also access your DR site, (how), or are the tapes carried there?
If any of these answers are not yet fully fixed (which I hope for some!), then indicate the 'room to move', please.
From these answers, I will know if we it can be bent in a direction that we can export our expiriences to you.
Proost.
Have one on me.
jpe
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-09-2005 10:20 PM
тАО05-09-2005 10:20 PM
Re: A Cluster that isn't?
Willem
OpenVMS Developer & System Manager
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-09-2005 10:50 PM
тАО05-09-2005 10:50 PM
Re: A Cluster that isn't?
2. Startup shouldn't be slower, because of timeout - expected votes should be one, so it won't be looking for other nodes.
re having second smaller disk. Ultimately the system disk is a hbs pair of 73 GB disks (on a DS25) We could boot from disk A, restore to disk B, writeboot, boot from disk b, and then mount disk a as a shadow to disk b, but that seems less elegant.
RE legato and immage backups - yup according to our legato team, and everything ( have been able to find in the documentation.
re Volker
.3 Yup, anticipate some research needed on IP settings.
re Gezelter - would be interested on your other alternatives. VMS Development, as you may know, has used an extra layer of rooted logicals (known as the folk disk, or CLU$common) in many of their internal configs to easy the pain of OS Changes - that is what triggered this line of thought.
Re Jan van ...
Production is a Dual 533 4100, with KZPAC and 3 9GB's mirrored, and a 3x2x18.2Gb 0+1 as the "data" disk. DR is a dual CPU 1 Ghz DS25, with two 73Gb's direct attached, and Fibre channel to connect to a HDS SAN (still unproven...) Backup and restore is via a STK L700, with LTO-2's.
Generally you are preaching to the converted - I regard the constraints on this as making it an absolute dogs breakfast. We actually have the potential to acquire a pair of ES40's and HSG80 based storage. I regard dual siting that, with a split cluster, as making much more sense. But, the planners of this appear to come from PC/Unix worlds, and have been swayed by the likes of the storage vendors...
q
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-10-2005 12:03 AM
тАО05-10-2005 12:03 AM
Re: A Cluster that isn't?
so, your PRD and DR sites are connected (by a connection that supports/can be made to support SCS)?
Your disks are 'mirrored'? As in, controller based mirrored, or, Host based 'shadowed'?
Well, what better arguments to give them then to lead them to our 'Uptime' story.
http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=855602
Some of the technical details will require following some links, but that should pose no problems.
If you have them follow those links, they also contain some real-life reports of actual critical situations.
Of course I do not know your management, but ours was actually most sensitive for the slogan:
"We do NOT want Disaster Recovery, because we can offer Disaster Resilience."
The easiest way to recover from disaster after a crisis is to prevent the crisis from turning into a disaster!
My advise in short:
ONE multisite cluster, with multisite HostBasedShadowing. (and definitely NO replication!)
Ask those storage vendors some details about the failover. Probably goes rather smooth.
Then, ask them about failBACK. Let them guarantee in writing that THAT goes equally smooth, and equally fast!
I have SEEN (luckily not for VMS!) that the failover took 2 minutes, and everything was running again. Then the failback took 18 (eightteen!) HOURS, during which the applications couls NOT be used. And after that about three quart of the applications functioned correctly, and it still took several hours to get the remainder available.
At the very least, EXCERSIZE before going life!
My offer stands: if you are doing a 'decent' VMS-style solution, I will be available for a lot of advise from experience.
Then again: there are more ways to skin a cat, and if you (have to) choose another way, I still wish you success, and I will help as much as I can (which will of course be less).
I think my first wish will have to be for success in the fight about the choice!
Permission to use anything I have put into ITRC explicitly granted.
Proost.
Have one on me.
jpe
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-10-2005 04:14 AM
тАО05-10-2005 04:14 AM
Re: A Cluster that isn't?
1st off: I agree with the preference of a multi-site cluster/storage architecture -- it's just so much cleaner -- and if lost time is lost money, then it makes perfect sense.
If however you are forced to live with the current scenario of the Legato backups, you might save yourself some major headaches by doing this:
Create a place on your disk environment to make a saveset file of an image backup of your system disk and let Legato back it up from there. Then when you are doing your restore, you can unpack the saveset and do an image restore from it. This may seem convoluted, but the benefit of this approach would be that you don't have to worry about the directory structure being handled correctly.
Aside/Rant: What good is a backup product that won't restore the source disk to the exact state it was in when the backup was made? Yes you can restore individual files -- and this is goodness. In the *n*x environments they have to deal with links -- so why not in OpenVMS?
Robert
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-10-2005 05:44 AM
тАО05-10-2005 05:44 AM
Re: A Cluster that isn't?
it would really be nice to have a bootable CD with a valid IP config and a networker client. This should then allow you to restore your system disk, boot from it and do the rest of the restores.
Volker.