- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Re: New clustered shadowset
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
тАО04-17-2007 03:15 AM
тАО04-17-2007 03:15 AM
Re: New clustered shadowset
Jack, et. al. -- yes, the disks are MSCP served to the cluster members; there is no shared storage.
John, you talk about using /Policy=Require_Members. The downside that I see to that is that if our cluster boots and 2 members of the 3 are available, quorum is reached, but we still would not see the volume mounted until the 3rd system booted, right? That's not our goal -- we're happy with 2 members of the cluster. It's a development & QA cluster, so there's a good chance that we'll have at least one system down or rebooting for any variety of reasons. And because of that, I'm loath to do anything that's going to require massive amounts of hand-waving and magical incantations to get the system up and running after just one host reboots.
Martin and Jan -- about dismounting DSA vs. DKB during shutdown. I'm trying to figure out if the best bet would be to first dismount the local drive DKB200 so that it's removed cluster-wide and then dismount the DSA shadowset on the local host, OR should I just dismount the DSA volume on the local host? If I dismount the drive, it doesn't remove it from the permanent definition of the shadowset, it just tells the other hosts that this drive is unavailable until it's mounted again, right? With the common system files on the shadowset, will I even be able to dismount the DSA volume on the local host during SyShutdwn? Is there anything special that I should do (or even could do) to facilitate the clean removal of the local drive with these shared files?
And, yes, the common drive is to be used for the standard complement of shared files: SysUAF, RightsDB, TCPIP$Hosts, Qman, LPD spool directory, etc.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-17-2007 03:44 AM
тАО04-17-2007 03:44 AM
Re: New clustered shadowset
Just dismount the DSA. Although there will always be files open (UAF, queue files etc) and therefore I think it unlikely you can avoid the resulting shadowset merge.
Purely Personal Opinion
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-17-2007 03:48 AM
тАО04-17-2007 03:48 AM
Re: New clustered shadowset
@xx single_disk dsa1 disk1 $45$dka401,$45$dka301
Note that some parts may require our context.
Wim
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-17-2007 07:03 AM
тАО04-17-2007 07:03 AM
Re: New clustered shadowset
Thanks to all for your input -- I'm going over the info you've provided to see if I can come up with any more questions.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-18-2007 01:26 AM
тАО04-18-2007 01:26 AM
Re: New clustered shadowset
It depends on how you do the DISMOUNT of the local drive -- from the HELP DISMOUNT /POLICY text:
/POLICY=[NO]MINICOPY[=(OPTIONAL)] (Alpha/I64 only)
Controls the setup and use of the shadowing minicopy function.
Requires LOG_IO (logical I/O) privilege to create bitmaps.
The exact meaning of the MINICOPY keyword depends on the context
of the DISMOUNT command, as follows:
1. If this is a dismount of a single member from a multi-member
shadow set, a write bitmap is created to track all writes
to the shadow set. This write bitmap may be used at a later
time to return the removed member to the shadow set with a
minicopy.
If the write bitmap cannot be initiated and the keyword
OPTIONAL is not specified, the dismount will fail and the
member will not be removed.
If you omit the /POLICY qualifier or if you specify
/POLICY=NOMINICOPY, no bitmap will be created.
Cheers,
Robert
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-18-2007 07:15 AM
тАО04-18-2007 07:15 AM
Re: New clustered shadowset
So, going over the stuff about HBMM, the one thing that has me concerned is this one statement in the OVMS FAQ:
"In a regular Merge operation, Shadowing uses an algorithm similar to the Full Copy algorithm (except that it can choose either of the members' contents as the source data, since both are considered equally valid)"
Ref:
http://hoffmanlabs.org/vmsfaq/vmsfaq_011.html#mgmt63_mm
Okay, so in my 3 host scenario, where I hope to have at least 2 hosts up at any time (quorum = 2), do I even need to use HBMM? Will MiniCopy handle both the expected departure of a host via shutdown, and the unexpected crash?
Or do I want to setup HBMM to handle the case when 2 of my hosts die, then at least one comes back? Will enabling HBMM in any way negatively affect the benefits of MiniCopy?
Oh, and I'm still wrestling with doing a "Dismount DSA10:" or "Dismount $10$DKB200:" in my shutdown. Or both. At the present time, I think the correct scenario would be to dismount the shadow set, then if the local drive is still mounted on any of the other hosts, dismount it (remembering to include the MiniCopy policy request). Is that legit, or is there a better/easier way to do it?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-18-2007 07:51 AM
тАО04-18-2007 07:51 AM
Re: New clustered shadowset
"merge" kicks in when two or 3 members of a shadowset stay on line, but one node that has the set mounted leaves unexpectedly ("crashes").
Now, if any writes to that VOLUME are in progress (remember I empasised the distinction between drive and volume?) there is NO way for the other nodes to know how far each of the parallel writes to each of the drives has progressed.
In other words, the members are NOT guaranteed to be identical, and that MUST be corrected. A "merge" is needed. As there was no way of knowing WHERE the writes-in-progress are, the WHOLE drive had to be checked. A VERY lengthy process! In HBMM Engeneering has found ways of keeping track of where any write is to occur, and when it has completely finished. And that, in such a way, that the surviving cluster members have access to this info. Now, ONLY those disk blocks that might be affected need re-synching. A matter of seconds (or fractions thereoff).
COPY (and MINICOPY) occurs, when a DRIVE is (re-)added to the volume. (following a MOUNT Of course, MINIcopy is only possible if the drives once WERE identical (ie, they formed a shadowset, and one drive was DISMOUNTed), AND all changes since the separation have been kept track of.
Completely different scenarios, and rather different objects, with different algorithms. Although, of course the global object is to reach the goal where all drives contain reliably the same info in the same location, ie, the Volume is consistent.
hth
Proost.
Have one on me.
jpe
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-18-2007 08:54 AM
тАО04-18-2007 08:54 AM
Re: New clustered shadowset
Super -- that made things clear.
I've also just found this thread in Italy:
http://www.eleuteron.it/mess_160141_3319014.html
Where the same thing is said, down towards the bottom. There's also an unanswered question in that thread about whether you should only use /Policy=MiniCopy in the dismount command. If I understand it correctly, it would only slow down your shutdown if you had to create the bitmap from scratch on all the nodes when you dismount the volume. It would make more sense to create it during the mount, but still verify that it's there during the dismount. Is that a valid statement?
I'm getting close -- thanks for everyone's help!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-18-2007 09:43 AM
тАО04-18-2007 09:43 AM
Re: New clustered shadowset
You definitely want to enable HBMM by using the /POLICY=MINICOPY on the mount.
If you want to speed up shutdown a bit, you can dismount the local member of a shadowset first with /Policy=Minicopy, then dismount the DSA device. Removing the member first will save the other cluster members from having to go through shadow member timeouts after the node leaves.
Robert
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО04-18-2007 12:39 PM
тАО04-18-2007 12:39 PM
Re: New clustered shadowset
<
If your aim here is to achieve a MINICOPY then you need to dismount the member (DKBnnn) not the volume (DSAnnn).
Unless I am mistaken, if you dismount the DKB member using /POLICY=MINICOPY in SYSHUTDWN, this will create the master write bitmap on the system that is shutting down. This master write bitmap will be deleted when the node shuts down, and therefore a full copy will be required to add the member back into the shadowset.
What I would do is dismount the DKB member using /POLICY=MINICOPY from one of the other cluster members, so that the master write bitmap can be created and maintained there. And I would do it manually rather than trying to automate this process.