Building a Fault-Tolerant Print Spooler


In this case study, we'll build a central print spooler that allows all of the cluster nodes to send their print jobs through a central print spooler on the cluster node manager. As with the preceding case study, the "right" choice for the printing software package you choose and for the architecture of your printing system will depend upon your situation. The hypothetical organization that we will use in this case study has a very heavy volume of print jobs that are sent to laser printers located on the internal company LAN.

Let's look at how to install a printing system that will meet the needs of this organization and provide a single point of control for print jobs sent from the cluster nodes without creating a single point of failure.

Cluster Nodes and Job Ordering

For proper job ordering, print jobs should be sent to this central print server as quickly as possible. If, for example, user A on node 1 sends 100 print jobs to a printer, then shortly thereafter user B on node 2 sends another 100 print jobs to the same printer, we want user A's jobs to finish printing before B's jobs start. This is normally not a problem with a monolithic server because it takes only a few seconds for user A's application to finish sending the jobs to the local print queue. However, in a cluster environment, as with any distributed printing environment with a central print spooler, the jobs may take more time to travel from the cluster node to the central print server. This introduces the possibility that another application on another cluster node printing to the same printer will begin interleaving print jobs. Due to the large number of print jobs used by our hypothetical organization, we'll need to take care when configuring a printing system for the cluster so that print jobs do not sit for very long in the queue or spool directory on the cluster nodes.

LPRng: A Linux Enterprise Cluster Printing System

While LPRng can be difficult to install and complex to use, it is quite powerful and a great choice for use as an enterprise cluster printing system.

Note 

This section provides a sample printer configuration and a few sample printer commands. It is not meant to replace the extensive documentation written by Dr. Patrick Powell and available online in the LPRng-HOWTO and the IFHP-HOWTO.

Cluster Nodes and Print Jobs

As Figure 19-1 shows, applications running on cluster nodes create print jobs and send them to the locally running lpd daemon on the cluster node. The lpd daemon places each print job onto the local hard drive of the cluster node.[3] While the lpd daemon on the cluster node could send the jobs directly to the printers, for better administration of the print queues and printer configurations, all print jobs will be sent to a central print server— the highly available cluster node manager. The central print server will then save, or spool, the print jobs again onto its local hard drive before sending them on to the printer.

image from book
Figure 19-1: LPRng in a cluster environment

As you can see in Figure 19-1, each cluster node is storing print jobs locally before passing them on to the central print server. As previously mentioned, the cluster nodes should hold their print jobs in the local spooler on each cluster node and then send them to the central print spooler as quickly as possible to avoid job interleaving problems when multiple cluster nodes print to the same printer at the same time. Also, as you can see in the figure, the central print spooler is where the connection is made to the actual print device—the laser printer in this case. If this central print spooler fails (though it shouldn't, because it will be built as a resource under Heartbeat's control), the print jobs will wait in the print spooler on each cluster node until the central print spooler returns to normal operation.

Building the Cluster Printing System Based on LPRng

Now that you know which printer software package you want to use (LPRng) and how you would like to configure it, you are ready to install the software on each cluster node and on the central print spooler (the cluster node manager).

To build the configuration shown in Figure 19-1, first download and install the "stock" version of the LPRng package (version 3.8.20 or later) on the cluster node manager and on all of your cluster nodes.

Install LPRng on the Central Print Server

Once you've done that, you can modify the standard /etc/init.d/lpd initialization script on the central print server so that it no longer runs the printconf-backend program from Red Hat and instead just starts up the "stock" LPRng lpd daemon. The start section of the /etc/init.d/lpd init script need only contain the following:

     Start () {         /usr/sbin/checkpc -f         daemon /usr/sbin/lpd     } 

The checkpc program is part of the LPRng package and checks the printer configuration. If any small problems are found, such as directory permissions not set correctly on the spool directories, the checkpc program attempts to fix them automatically if you pass it the -f argument. Normally, you use this command after making a change to the printing system.

Install LPRng on the Cluster Nodes

On the cluster nodes, however, you do not need to modify the /etc/init.d/ lpd script. You can use the standard version supplied by Red Hat or your distribution. When the printconf-backend script runs (each time the script is called with the start argument), the /etc/printcap file is overwritten on the cluster node. Thus, you never modify the /etc/printcap file on the cluster nodes. Instead, each cluster node knows what printers are available on the central print server because the printers are listed in the /etc/printcap.local file on each cluster node (of course, this can be a symbolic link to a single file stored on an NFS-mounted drive, so you only need to make changes to one file for all cluster nodes to see the change). Each time you modify the /etc/ printcap.local file, you must restart the lpd daemon on all cluster nodes for the change to take effect.

Note 

On the central printer server (with the modified /etc/init.d/lpd init script), you always modify the /etc/printcap file, because the /etc/printcap.local file is not used on the central print server.

To summarize the configuration we've just built: the /etc/printcap file on the central print server contains the actual printer definitions (what interface script to use for a particular printer, what IP address location the printer has, and so on), and the /etc/printcap.local file on the cluster nodes contains only enough information for the cluster nodes to be able to send the print jobs to the central print server (how long the network timeouts should last when communicating with the central print server, the host name of the central print server, and so forth).

Modify the /etc/printcap.local File on the Cluster Nodes

An entry in the /etc/printcap.local file on each of the cluster nodes looks like this:

 # All printers on the cluster nodes can use these same default values: .default: :fifo :sd=/var/spool/lpd/%P :lp=%P@centralprintserver :connect_interval=60 :connect_grace=3 :reuse_addr=true :send_job_rw_timeout=0 :send_query_rw_timeout=0 :send_try=0 :retry_econnrefused=true :retry_nolink=true :wait_for_eof=true :connect_timeout=600 :force_localhost # Then place each printer after the default values in the # file (/etc/printcap.local) with entries like this: printer1:tc=.default printer2:tc=.default printer3:tc=.default 

where centralprintserver in this example is the host name of the central print server (and is resolved using DNS/LDAP/NIS or the local /etc/hosts file on each cluster node).

Modify the /etc/printcap File on the Central Print Server

On the LPRng central print server an /etc/printcap entry looks like this:

 # A list of definitions for laserjet style printers that will use the # "ifhp" print filter. .laserjet :fifo :filter=/usr/libexec/filters/ifhp :ifhp=waitend@ :af=acct :lf=log :mx=0 :sd=/var/spool/lpd/%P :sh # The following printers use the "laserjet" definition # above. Here are their IP addresses. printer1 :tc=.laserjet :lp=192.160.0.201%9100 printer2 :tc=.laserjet :lp=192.160.0.202%9100 printer3 :tc=.laserjet :lp=192.160.0.203%9100 

Of course, you can have more than one type of printer—a printer type other than laserjet—defined at the top of the /etc/printcap file on the central print server.

Note 

Because the standard Red Hat distribution uses a slightly modified version of the LPRng system, you may see references to the "printconf-tui" (tui stands for text user interface) and "printconf-gui" (the graphical user interface version of printconf available under an X Windows display) tools. Do not use either of these printconf utilities on the central print server.

This case study will conclude with a look at the day-to-day activities the system administrator will use to administer print jobs on the cluster using the LPRng printing system.

Managing Print Jobs on the Central Print Server

Print queues and print jobs can then be managed with the lpc command, as follows, on the central print server.

List all printers and their current status:

 #lpc status all 

Hold all jobs currently waiting to print on printer1:

 #lpc hold printer1 all 

Release jobs waiting to print on printer1:

 #lpc release printer1 all 

Place the printer in a hold state so new jobs can still be sent from the cluster nodes, but the central print server will not send them on to the printer:

 #lpc holdall printer1 

Take the printer out of the "hold" state:

 #lpc noholdall printer1 

When a printer hangs, use the following command (print jobs are not removed or lost, but the subserver process started by the main lpd daemon to process the jobs within the print queue will be killed and a new one restarted):

 #lpc kill printer1 

Managing Print Jobs From the Cluster Nodes

The same commands can be used by users[4] on the cluster nodes with the added -S option:

 #lpc -Scentralprinterserver hold printer1 all #lpc -Scentralprinterserver holdall printer1 #lpc -Scentralprinterserver release printer1 all #lpc -Scentralprinterserver noholdall printer1 

When the lpc command is used from a cluster node without the -S argument, the command only affects the print queue on the cluster node (the local print queue on the cluster node). Forgetting to use the -S argument to the lpc command when you issue the holdall command for one of the printers on a cluster node can lead to the situation where a printer stops working for some users but not for all of the users. When this happens, the print jobs are not lost, however, and the cluster administrator need only log on to the cluster node and release the print jobs.

image from book
CREATE CUSTOM SCRIPTS ON THE CENTRAL PRINT SERVER

One of the useful features of the LPRng printing system is that you can write your own scripts to handle print jobs. The script can contain a line as simple as this:

    cat > /tmp/job.$$ 

This line will take the input stream of characters (normally PostScript) and send them to the file /tmp/job.pid, where pid is the process ID of your custom script when it is launched by the lpd daemon on the central print server. You can then manipulate the file (/tmp/job.$$) within your script to do things like send the job as a fax (using the Hylafax program[5]) or convert the file into PDF using the ps2pdf utility and store the file in an SQL database as a binary large object (blob).[6]

Note 

Windows PC users can print to the LPRng printers using the Samba package. See http://www.samba.org. (Samba is probably already included with your distribution.)

image from book

[3]LPRng clients need not run the lpd daemon. For example, if you need to print very large GIS files, you do not need to spool them to the local hard drive on the cluster node before sending them to the central print spooler.

[4]The LPRng system has a security system to control which commands a user can apply to a printer queue. See the LPRng documentation for details.

[5]See the smbfax project.

[6]You can then later retrieve the blob using a variety of methods such as the Perl DBI package or a Python script in conjunction with the Zope or Plone packages for display on a web server.



The Linux Enterprise Cluster. Build a Highly Available Cluster with Commodity Hardware and Free Software
Linux Enterprise Cluster: Build a Highly Available Cluster with Commodity Hardware and Free Software
ISBN: 1593270364
EAN: 2147483647
Year: 2003
Pages: 219
Authors: Karl Kopper

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net