HPE GreenLake Administration
- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - HP-UX
- >
- Managing lp in a DRP environment
Operating System - HP-UX
1834150
Members
2481
Online
110064
Solutions
Forums
Categories
Company
Local Language
back
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
back
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
Blogs
Information
Community
Resources
Community Language
Language
Forums
Blogs
Go to solution
Topic Options
- 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
11-16-2001 06:04 AM
11-16-2001 06:04 AM
Hi
If 2 nodes are clustered (using SG).
Each node runs own apps. For failover of a node
what is the best way to manage lp stuff such as remote print queues?
Should all printers be configured on both nodes for both nodes (ie for all apps), and if so how should they be synchronized?
Any tips/insight would be valued.
The same approach may also need to be applied for our 3rd party job scheduler and home grown infrastructure components.
Regards
Graham
If 2 nodes are clustered (using SG).
Each node runs own apps. For failover of a node
what is the best way to manage lp stuff such as remote print queues?
Should all printers be configured on both nodes for both nodes (ie for all apps), and if so how should they be synchronized?
Any tips/insight would be valued.
The same approach may also need to be applied for our 3rd party job scheduler and home grown infrastructure components.
Regards
Graham
Solved! Go to Solution.
2 REPLIES 2
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-16-2001 06:16 AM
11-16-2001 06:16 AM
Solution
<>
Yes, both nodes should be able to see all print queues. We do this using third party print software , the now-defunct openspool.
But, i don't think this takes care of failing over pending print requests.
<>
Yes, the job scheduler should be set up in such a way that the job schedule also gets failed over. The third party application should have that provision. I use controlM and it is setup accordingly. It also depends on the criticality of the jobs running on the system.
<>
If there are data, then you can simply fail over the filesystems alone. It all depends on what sort of applications are running on the system.
-raj
Yes, both nodes should be able to see all print queues. We do this using third party print software , the now-defunct openspool.
But, i don't think this takes care of failing over pending print requests.
<
Yes, the job scheduler should be set up in such a way that the job schedule also gets failed over. The third party application should have that provision. I use controlM and it is setup accordingly. It also depends on the criticality of the jobs running on the system.
<
If there are data, then you can simply fail over the filesystems alone. It all depends on what sort of applications are running on the system.
-raj
Take it easy.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-16-2001 06:36 AM
11-16-2001 06:36 AM
Re: Managing lp in a DRP environment
Hi Graham,
If you want to have identical print queue definitions, use SAM to save LP spooler configuration on one server, copy it to the other server, then use SAM to restore the copied configuration. By default it is saved in /var/sam/lp. Unless you add printers often you should get able to get by fine with this method. That's for the config only, not the jobs in the queues.
If you list the printers in /etc/hosts you'll have to make coresponding changes on both servers. Same for any static routes if you use them for printers on other nets.
Unfortunately, the printer queues on each server are independent of the other server unless you use 3rd part software as Raj suggests.
You'll need to check with the job scheduler vendor to see how and if it works in HA environments. I'd think any good scheduler would handle HA clusters.
Darrell
If you want to have identical print queue definitions, use SAM to save LP spooler configuration on one server, copy it to the other server, then use SAM to restore the copied configuration. By default it is saved in /var/sam/lp. Unless you add printers often you should get able to get by fine with this method. That's for the config only, not the jobs in the queues.
If you list the printers in /etc/hosts you'll have to make coresponding changes on both servers. Same for any static routes if you use them for printers on other nets.
Unfortunately, the printer queues on each server are independent of the other server unless you use 3rd part software as Raj suggests.
You'll need to check with the job scheduler vendor to see how and if it works in HA environments. I'd think any good scheduler would handle HA clusters.
Darrell
"What, Me Worry?" - Alfred E. Neuman (Mad Magazine)
The opinions expressed above are the personal opinions of the authors, not of Hewlett Packard Enterprise. By using this site, you accept the Terms of Use and Rules of Participation.
Company
Events and news
Customer resources
© Copyright 2025 Hewlett Packard Enterprise Development LP