- Community Home
- >
- Servers and Operating Systems
- >
- Legacy
- >
- Operating System - Tru64 Unix
- >
- Re: CA recovery of a TRUcluster environment.
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
тАО01-23-2006 12:04 PM
тАО01-23-2006 12:04 PM
I have read documentation around member boot disk and the shared cluster file system recovery that have generated many questions.
When CA replicates all the Trucluster disk, "member boot disks, quorum, cluster...", I am expecting to use new dsk devices. Is this correct?
Recovering the cluster with these device changes is the challenge. My current understanding tells me each replicated member boot disk's cnx partition would need updating. Is it possible to boot to the shell from the OS CD and mount the one of the replicated member boot disk, edit the sysconfigtab to show changes to clubase and vm?
Also is it possible to edit clu_bdmgr.conf and pass this to the new member boot disk using #clu_bdmgr -h dskx clu_bdmgr.conf?
Hopefully this isn't to confusing.
Any insight into this is much appreciated.
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-23-2006 09:44 PM
тАО01-23-2006 09:44 PM
SolutionWhen you replicate the cluster file sytems and the members boot devices, when you failover to the destination storage, the device names does not change, because the WWN is also replicated.
The failover process is very simple, just do the failover at the continuous access management console, then, boot the servers again. You don't have to do any other configuration changes.
As a procedure, after a failover, we run the wwidmgr -clear all and wwidmgr -quickset again. Sometimes, the member does not boot if these commands are not run.
Currently, I can say (by now) that the EVA is not very reliable (comparing with an older storage), maybe because of the FC technology. We had severals extrange incidents.
We had a disk group with protection double, we turned off the storage, and after turning on, disks started to fail, when the 3 disk failed, the disk group failed. What I can say is that the continuous access works good because we was able to boot everything and start working without problem from the destination eva.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-24-2006 03:37 AM
тАО01-24-2006 03:37 AM
Re: CA recovery of a TRUcluster environment.
Thanks for your response and sharing your experience. In our lab we replicated the storage and noticed the vdisk wwn were the same between the two storage arrays. We also noticed the UUID's of the vdisk were different. Our observation would have us guess that TRU64 would use the UUID to create new device files and as new files were created, we would have to manage these changes to get the cluster back up. From your feedback the device files are unchanged and bringing the cluster up is a matter of using wwidmgr and rebooting.
I would have to wonder if the reason a wwidmgr quickset needs to be rerun is the difference in the UUID's.
Thanks again.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-24-2006 05:08 AM
тАО01-24-2006 05:08 AM
Re: CA recovery of a TRUcluster environment.
We will be doing a failover this weekend. I will check that information.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-24-2006 07:53 AM
тАО01-24-2006 07:53 AM
Re: CA recovery of a TRUcluster environment.
The world wide lun number and the uuid are seen at the vdisk level. Another setting at the vdisk presentation level is the os unit id.
It is the os unit id that wwidmgr see as udid.
From the SRM prompt using wwidmgr, I would wonder if the changed uuid is picked up.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-06-2006 11:34 PM
тАО02-06-2006 11:34 PM
Re: CA recovery of a TRUcluster environment.
Last weekend we did a failover, after the failover, your HBA won't see the devices, and that's why you have to run the init, wwidmgr -clear all and wwidmgr -quickset -udid commands. But the device name at console level or operating system level won't change. For example, you won't have to run set bootdef_dev.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-13-2006 04:48 AM
тАО02-13-2006 04:48 AM
Re: CA recovery of a TRUcluster environment.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-13-2006 04:49 AM
тАО02-13-2006 04:49 AM