[Printing-architecture] CUPS: fail-over without load-balancing

[Printing-architecture] CUPS: fail-over without load-balancing

[Tim Waugh]

[-- Attachment #1: Type: text/plain, Size: 1192 bytes --]

Hello!

I'm investigating how to implement fail-over for CUPS, but without
having load-balancing as a side effect.

The usual way of implementing fail-over is simply to use classes, so
that printers are used round-robin fashion.

However, I'd like to implement fail-over as follows:

Each class will have one active printer accepting jobs, and a fail-over
printer not accepting jobs. When all is well, only the active printer
will be in use.

When the active printer fails, a daemon will spot this and start the
fail-over printer accepting jobs.

This is planned to be accomplished by having the daemon subscribe to
notifications. When it sees a notification that a printer has been
disabled due to a job failure, it will look for classes containing that
printer but no other accepting printers.

For each of these classes, it will look for a printer with a 'failover'
attribute and set it to accept queues. It will also move any jobs queued
for the failed printer over to the newly-accepting printer.

Does this sound like the best approach? Is it something that would be
best implemented as part of CUPS, or cups-filters, or a standalone
project?

Tim.
*/


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 465 bytes --]

Re: [Printing-architecture] CUPS: fail-over without load-balancing

[Michael Sweet]

[-- Attachment #1: Type: text/plain, Size: 2451 bytes --]

Tim,

We've had a few requests for this functionality over the years.  The current bug tracking it is:

   http://www.cups.org/str.php?L1240

Right now the simplest thing to do is add a backend that implements the required functionality.  Longer term we'll address STR #1240 as a manual operation that (temporarily) redirects jobs queued on one queue to another.

More comments inline...

On Jul 16, 2014, at 6:32 AM, Tim Waugh <twaugh@redhat.com> wrote:
> Hello!
> 
> I'm investigating how to implement fail-over for CUPS, but without
> having load-balancing as a side effect.
> 
> The usual way of implementing fail-over is simply to use classes, so
> that printers are used round-robin fashion.
> 
> However, I'd like to implement fail-over as follows:
> 
> Each class will have one active printer accepting jobs, and a fail-over
> printer not accepting jobs. When all is well, only the active printer
> will be in use.
> 
> When the active printer fails, a daemon will spot this and start the
> fail-over printer accepting jobs.

This was basically the point of another feature request (STR #2878), however after we looked at implementing such a scheme it didn't seem workable - right now the class accepts the job and any printer in the class will process the job, regardless of the state of its "printer-is-accepting-jobs" attribute.  And if you use change the class code to honor "printer-is-accepting-jobs", or use "printer-state" instead, you'll basically need printers that are dedicated to a particular class since most of the time they will be disabled/not accepting jobs.

In the end we decided the only thing that made sense was to track a selected/primary printer for the class, and have the admin change this when needed.  And that is what STR #1240 is tracking, for any queue (even a class).

> ...
> Does this sound like the best approach? Is it something that would be
> best implemented as part of CUPS, or cups-filters, or a standalone
> project?

Long term this should be part of CUPS.  Short term it can be implemented as a backend.  I would hesitate to patch cupsd for this since you will introduce long-term support issues when we finally do add the functionality ourselves.  At least with a backend the migration path is clear and can be staged over many releases.

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair


[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 4881 bytes --]

Re: [Printing-architecture] CUPS: fail-over without load-balancing

[Clark Hale]

On 07/16/2014 11:07 AM, Michael Sweet wrote:
> Tim,
>
> We've had a few requests for this functionality over the years.  The current bug tracking it is:
>
>     http://www.cups.org/str.php?L1240
>
> Right now the simplest thing to do is add a backend that implements the required functionality.  Longer term we'll address STR #1240 as a manual operation that (temporarily) redirects jobs queued on one queue to another.
>
> More comments inline...
>
> On Jul 16, 2014, at 6:32 AM, Tim Waugh <twaugh at redhat.com> wrote:
>> Hello!
>>
>> I'm investigating how to implement fail-over for CUPS, but without
>> having load-balancing as a side effect.
>>
>> The usual way of implementing fail-over is simply to use classes, so
>> that printers are used round-robin fashion.
>>
>> However, I'd like to implement fail-over as follows:
>>
>> Each class will have one active printer accepting jobs, and a fail-over
>> printer not accepting jobs. When all is well, only the active printer
>> will be in use.
>>
>> When the active printer fails, a daemon will spot this and start the
>> fail-over printer accepting jobs.
> This was basically the point of another feature request (STR #2878), however after we looked at implementing such a scheme it didn't seem workable - right now the class accepts the job and any printer in the class will process the job, regardless of the state of its "printer-is-accepting-jobs" attribute.  And if you use change the class code to honor "printer-is-accepting-jobs", or use "printer-state" instead, you'll basically need printers that are dedicated to a particular class since most of the time they will be disabled/not accepting jobs.
>
> In the end we decided the only thing that made sense was to track a selected/primary printer for the class, and have the admin change this when needed.  And that is what STR #1240 is tracking, for any queue (even a class).
>
>> ...
>> Does this sound like the best approach? Is it something that would be
>> best implemented as part of CUPS, or cups-filters, or a standalone
>> project?
> Long term this should be part of CUPS.  Short term it can be implemented as a backend.  I would hesitate to patch cupsd for this since you will introduce long-term support issues when we finally do add the functionality ourselves.  At least with a backend the migration path is clear and can be staged over many releases.
Hi Michael,

Sorry for reviving an old thread, but I've been working with Tim on 
this, and we're looking for some feedback on our solution.

What we've come up with is as follows:

The "failover" backend, as we've been calling it, is configured with a 
list of IPP URI.  The first URI in the list is the de facto "primary" 
printer.

When a job is sent to the backend, it will loop through the list. For 
the first one found that's not stopped and is accepting jobs, the 
backend will exec the regular ipp backend to send the job to that queue.

This seems to work fairly well from our tests.  Does this seem like a 
reasonable way to go about implementing this?

Thanks,

-Clark Hale

Re: [Printing-architecture] CUPS: fail-over without load-balancing

[Michael Sweet]

Clark,

Apologies for the delay in responding...

> On Sep 18, 2014, at 4:07 PM, Clark Hale <chale@redhat.com> wrote:
> ...
> Sorry for reviving an old thread, but I've been working with Tim on this, and we're looking for some feedback on our solution.
> 
> What we've come up with is as follows:
> 
> The "failover" backend, as we've been calling it, is configured with a list of IPP URI.  The first URI in the list is the de facto "primary" printer.

How do you separate/encode the other URIs?

> When a job is sent to the backend, it will loop through the list. For the first one found that's not stopped and is accepting jobs, the backend will exec the regular ipp backend to send the job to that queue.

As long as your backend runs as root, this will work.

> This seems to work fairly well from our tests.  Does this seem like a reasonable way to go about implementing this?

Yes, provided you have addressed the URI encoding/separation issues.

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair