The PaperCut NG/MF solution is designed with distribution in mind. The solution is built using Service Oriented Architecture, which allows its components to be installed on different machines of varying OS’. This allows PaperCut NG/MF to be installed in a variety of configurations, adapting to your network design as no two sites are the same.
The simplest and most common installation is to install PaperCut NG/MF onto a site’s print server (where the site has only one). For a school or a small organization the implementation doesn’t need to be any more complex than this. This is a single Application Server, single print server deployment and suits the majority of deployments.
Some more complex implementation examples exist below, as a way of showing what’s possible. You can extend or merge some of these concepts to suit your network and create your ideal PaperCut NG/MF deployment.
PaperCut NG/MF operates at a layer above your network print services. For this reason, design your solution to provide your printing services first, then integrate the PaperCut NG/MF application into your network second. i.e. if you want a print server per site to stop large jobs traversing network links, do so. You can also use clustering to provide high up time to printing services.
PaperCut Site Server
All of the solution designs in the next section can be complemented with the PaperCut Site Server.
The PaperCut Site Server gives the risk averse customer peace of mind that access to printing resources won’t be interrupted by unexpected network dropouts. Deploying the PaperCut Site Server ensures the critical services of the PaperCut primary server are supported locally during a disaster. Site Servers are simple to install and hide the complexity of database replication from Administrators.
Whilst initially designed for usage in multi site solutions, this isn’t the only usage of the Site Server. Think of the Site Server as a proxy to the Application Server that can also perform a set of the Application Server tasks with the last known set of data during an outage.
Deployment examples
Scenario A - Single site, multiple print servers
It is quite common for sites to have multiple print servers, even if they are a customer at a single physical location.
-
iOS printing—Deploy supporting printing from iOS devices using a Mac server to compliment a Windows print server.
-
Admin / Curriculum—A number of schools separate printing in the Administration section of the school from general staff/student printing.
-
Clustering—Each node of a clustered resource is installed as a print server.
Each of the print servers in this scenario must be installed and configured to communicate with the Application Server. For more information, see Configuring secondary print servers and locally attached printers .
The PaperCut Site Server could add benefit in this deployment scenario if your Application Server were deployed within the private cloud. The Site Server would offer a local level of redundancy in the event the connection to the cloud resources were to drop. One of the print servers could play this role in addition to being a PaperCut Print Provider host.
Figure 4: Multiple site / multiple print server deployment
Scenario B - Multiple site, single server
Not all multi-site installations rely on a print server on each site. This might be because the sites are small and don’t warrant the resources, or because they are quite large and have resources centralized in a data center or on the private cloud.
In either case, if all printing is centralized through a single Application Server, single print server installation, the installation is the same as if it were a single site with a single server.
The PaperCut Site Server could add benefit in this deployment if each of the sites wanted to ensure key business services of MFD usage and Print Release were supported during a network outage between a site and Application Server.
Figure 5: Multiple site / single server deployment
Scenario C - Multiple site, multiple print server
The deployment of print servers into remote sites allows for print jobs to be spooled within the local site, alleviating the need for these jobs to be sent to a centralized print server to only be sent back again to the remote site where the destination printer is located. This might be the choice of design for customers with
-
Low bandwidth between sites
-
Large print jobs generated on sites (architects, design firms, etc)
-
Historical infrastructure that supports this
The PaperCut solution supports this design though the deployment of Configuring secondary print servers and locally attached printers on each of the print servers. This allows the print jobs to remain locally spooled, with only light-weight transactional data and control information being transmitted between sites.
The PaperCut Site Server would add significant benefit in this design, possibly being installed onto one of the existing print servers. This would provide local support for Application Server functions should the link between primary and secondary sites be unavailable.
Figure 6: Multiple site / multiple print server deployment
Scenario D - Multiple site, multiple print server, multiple Application Servers
It is also possible to install PaperCut into each site of a multiple site organization as if each site itself were a separate installation of PaperCut. PaperCut has the ability to link separate Application Servers together for reporting purposes. Each individual site then has the ability to function and be administered autonomously, relying only on the links between the sites when there is a need to run a report from the Central Reports
Each of the individual autonomous sites would use one of the previous installation options. The PaperCut Site Server could then be considered for deployment to offer the same benefits listed above within these installations.
Figure 7: Multi Site/Multi Server deployment
Scenario variations
All of these scenarios can be complemented with other approaches to address high availability, resilience and scalability, including:
-
Clustered print server.
-
Clustered Application Server.
-
Clustered Database Server.
-
Off-premises (Private cloud hosted server backed by infrastructure provider).
Comparison table
The following table should assist with comparing deployment architectures. Different models offer different benefits and challenges. The key is to select the model that addresses your primary requirements, and to understand any constraints that need to be managed in your environment.
Deployment model comparisons
| Deployment type | Benefits | Considerations |
|---|---|---|
| 1 site, multi server |
|
|
| Multi site, single server |
|
|
| Multi site, multi print servers |
|
|
| Multi site, multi Application Servers |
|
|
Further resources
For further details of setup for each scenario, refer to the following resources. and .
Comments