- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- Two Queuemanagers without shared db on cluster.
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
Forums
Discussions
Discussions
Discussions
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
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
07-22-2007 08:25 PM
07-22-2007 08:25 PM
Re: Two Queuemanagers without shared db on cluster.
I killed it one time more, the queue manager process came back, and then immediately again, but then the queue manager process did not come back, stating in operator.log INTERNALERROR, internal error caused loss of process status. A start/que/manager got it up again, the jobs were still running.
Killing the queue manager on the production nodes showed comparable behaviour ( I also stop/id'd the process 3 times) , also here the queuemanager did not come back after the third stop/id. Furthermore it favored the node it had been running on before, I didn't see a switch to another node.
I could reproduce the behaviour of the queuemanager process, i.e. usually coming back by itself, sometimes refusing to, on a standalone machine, so there seems to be no link between this behaviour and the two queuemanager scenario.
So, even after a heavy beating, the queuemanagers do not seem to be affected by each other. I don't feel a crash on a node would introduce a lot more stress than a stop/id of the queuemanager process would.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-22-2007 09:03 PM
07-22-2007 09:03 PM
Re: Two Queuemanagers without shared db on cluster.
Purely Personal Opinion
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-22-2007 09:31 PM
07-22-2007 09:31 PM
Re: Two Queuemanagers without shared db on cluster.
I really can't see a problem with this configuration - although it may be 'unsupported' by HP.
Volker.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-22-2007 11:19 PM
07-22-2007 11:19 PM
Re: Two Queuemanagers without shared db on cluster.
No signs of the queuemanager wanting to start on other nodes.
I also crashed node A that was running the queuemanager for the production machines. The queuemanager failed over to node B. No signs of the queuemanager trying to start on PDCC0E.
No jobs missing, apart from the ones executing at the time of the crash without restart and/or retain options.
It all looks pretty robust. The technical merits are clear, if it is wisdom to implement such a configuration depends not only on technical merits but also on other more arbitrary considerations, like personal preference, operational skills in an organisation and, if you're really unlucky, existing policies and prejudice.
I'm waiting for HP to give an answer on the question if this configuration is officially considered to be supported, which in my case is one of those arbitrary considerations.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-23-2007 12:26 PM
07-23-2007 12:26 PM
Re: Two Queuemanagers without shared db on cluster.
If we ran separate queue managers, we would lose a lot of the flexibility we currently rely on.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-23-2007 06:08 PM
07-23-2007 06:08 PM
Re: Two Queuemanagers without shared db on cluster.
What are you using for a quorum tie breaker?
While I understand your concerns about the lock manager in general, I don't think it will ever be an issue on a node used just as a tie breaker.
Jose (sdi-1) is configuring a quorum node, and I don't think he wants production jobs running there.
----------------------------
Jose,
Volker's response from Jul 19, 2007 13:13:47 GMT list the limitations of running separate queue managers, specifically the invisibility of the queues on the other nodes. What type of batch job were you planning to run on the quorun node? You've stated that you don't plan to mount the drives from the production servers, so that's going to limit what you can do.
If you want to be able to print files from the production nodes, you can telnet to one of the other nodes and do the work there. And you can create print queue using TCPIP$TELNETSYM that autostart on more than a single node, but that would require a printer with raw tcpip capability (like a jetdirect print server) at the quorum site.
I think what I would do is MSCP serve the quorum node's system disk (so it would be possible to print files from it) and just run the queue manager on the production nodes, not even starting it on the quorum node. Then if I was at the quorum site, I would telnet to one of the production nodes, and do my work using one of those servers.
In summary: I don't see any technical reason that what is being discussed here wouldn't work within the limitations discussed. However, my preference would be to have a single queue manager database, just like rest of the cluster common files (e.g. SYSUAF, RIGHTSLIST, etc.)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-23-2007 11:05 PM
07-23-2007 11:05 PM
Re: Two Queuemanagers without shared db on cluster.
What's more, we don't use any of the cluster-wide databases on the quorum node, as only system managers would need to log in to this node, if ever.
As said before, the disadvantage of using MSCP is that you create dependencies between the quorum node and the rest of the cluster, that could bite you if real trouble arrives, possibly preventing the quorum node from doing it's main job : act as a tie-breaker for the production nodes.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-23-2007 11:26 PM
07-23-2007 11:26 PM
Re: Two Queuemanagers without shared db on cluster.
A quorum node does not need access to ANY disk to perform its function: being a quorum node. Not even its own system disk!
I do not think that using MSCP served disks on the quorum node (for whatever purpose) will interfere with the proper operation of tie-breaking for the production nodes.
After all, the quorum node is just another cluster member. The same rules for cluster connectivity apply to all cluster members. Unless you have a quorum disk (which is unlikely if you have a quorum member), accessibility of disks does not influence cluster connectivity.
Regards,
Bart Zorn
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-23-2007 11:52 PM
07-23-2007 11:52 PM
Re: Two Queuemanagers without shared db on cluster.
losing it's system disk might be alive enough to cast it's vote in the cluster, it wouldn't be an overly reliable system would it?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-24-2007 05:57 PM
07-24-2007 05:57 PM
Re: Two Queuemanagers without shared db on cluster.
What are you using for a quorum tie breaker?
We use a HP windows based system called DTCS. One is located at each site. Uses the same quorum adjust mechanism as AMDS. Connect via RDP from the WAN. Very useful.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-24-2007 06:50 PM
07-24-2007 06:50 PM
Re: Two Queuemanagers without shared db on cluster.
it depends on what you expect from a reliable system!
If a quorum systems is up and running, and you do not expect it to do anything else, it is very reliable, with or without access to its system disk.
During cluster state transitions, there is nothing that OpenVMS needs to fetch from the system disk. Once the transitions are over, not having access to the system disk may be a problem for other things running on the quorum node.
Regards,
Bart
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-24-2007 09:36 PM
07-24-2007 09:36 PM
Re: Two Queuemanagers without shared db on cluster.
Purely Personal Opinion
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-24-2007 11:16 PM
07-24-2007 11:16 PM
Re: Two Queuemanagers without shared db on cluster.
You can discard these options in favour of easier maintenance of the cluster as a whole, but then you definitely stray from the disaster tolerant path.
Depending on your design goals, operational requirements and the time you're allotted to recover from failures and disasters you may choose to tilt the balance toward easy management versus robust recovery possibilities. In my case, the cluster is supposed to be designed with disaster not as a possibility in the sideline, but as a certainty that has to be addressed with every means available.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-25-2007 02:50 AM
07-25-2007 02:50 AM
Re: Two Queuemanagers without shared db on cluster.
I don't have to have an old VAX or Alpha (ie. VMS system) as a quorum node? This could be quite useful to me!
Cheers,
Art
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
07-31-2007 07:39 AM
07-31-2007 07:39 AM
Re: Two Queuemanagers without shared db on cluster.
- « Previous
-
- 1
- 2
- Next »