Load balancing Konica Minolta Dispatcher Phoenix
Benefits of load balancing Konica Minolta Dispatcher Phoenix
Load balancing Konica Minolta Dispatcher Phoenix affords the following benefits:
- Enhanced performance: Load balancing intelligently distributes the document processing tasks and workflow load from multiple multifunction printers (MFPs) and users across a cluster of Dispatcher Phoenix servers. This prevents any single server from becoming a bottleneck, allowing the system to handle a higher volume of documents and labor-intensive tasks (like conversions and OCR) simultaneously. Work is distributed to the least busy servers, maintaining consistent response times. The collective processing power of all servers is utilized, speeding up overall document processing.
- High Availability (HA): Load balancing is a key component of a High Availability (HA) setup. If one Dispatcher Phoenix server fails, the load balancer automatically detects the issue and redirects all incoming workload to the remaining healthy servers. Automatic failover ensures that business processes do not come to a stop due to a single server failure. Administrators can take one server offline for maintenance, updates, or upgrades without interrupting critical workflow processing, as the remaining servers pick up the entire load.
- Scalability: By using a load balancer, organizations can easily scale their document processing capacity to meet growing business needs without overhauling their existing infrastructure. New Dispatcher Phoenix servers can be seamlessly added to the server cluster (or farm) to instantly increase processing power. The load balancer automatically incorporates the new server and distributes the work among all available resources. The system can efficiently manage sudden spikes in document traffic from hundreds of MFPs or heavy-use periods, ensuring that performance remains stable.
About Konica Minolta Dispatcher Phoenix
Dispatcher Phoenix is Konica Minolta’s solution for helping businesses save time by automating document image processing, printing, and routing tasks via customisable workflows. It provides busy offices with the convenience and flexibility they need helping increase productivity.
Why Loadbalancer.org for Konica Minolta Dispatcher Phoenix?
Loadbalancer’s intuitive Enterprise Application Delivery Controller (ADC) is designed to save time and money with a clever, not complex, WebUI.
Easily configure, deploy, manage, and maintain our Enterprise load balancer, reducing complexity and the risk of human error. For a difference you can see in just minutes.
And with WAF and GSLB included straight out-of-the-box, there’s no hidden costs, so the prices you see on our website are fully transparent.
More on what’s possible with Loadbalancer.org.
How to load balance Konica Minolta Dispatcher Phoenix
The load balancer can be deployed in 4 fundamental ways: Layer 4 DR mode, Layer 4 NAT mode, Layer 4 SNAT mode, and Layer 7 Reverse Proxy (Layer 7 SNAT mode).
For Dispatcher Phoenix, Layer 4 DR mode is recommended. This mode offers the best possible performance since replies go directly from the Real Servers to the client, not via the load balancer. It’s also relatively simple to implement. If DR mode cannot be used, for example if the Real Servers are located in remote routed networks, then Layer 7 Reverse Proxy is recommended.
Virtual service (VIP) requirements
To provide load balancing and HA for Dispatcher Phoenix, 2 VIPs are required.
VIP 1 is for the underlying Microsoft print services on ports 445 (SMB print queues), 515 (LPD print queues) & 9100 (RAW print queues) and VIP 2 is for the Konica Minolta Dispatcher Phoenix service being load balanced.
Load balancing deployment concept
The following diagram illustrates how the load balancer is deployed with multiple Dispatcher Phoenix servers.

For a Dispatcher Phoenix deployment, the preferred and default load balancer configuration uses Layer 4 DR Mode (Direct Routing, aka DSR / Direct Server Return). This is a very high performance solution that requires little change to your existing infrastructure. It is necessary to solve “the ARP problem” on the real print servers. This is a straightforward process, and is detailed in our deployment guide, below.
It is also possible to load balance a Dispatcher Phoenix deployment using Layer 7 SNAT Mode. This mode might be preferable if making changes to the real print servers is not possible, although some Windows Registry keys need to be added. Due to the increased amount of information at layer 7, performance is not as fast as at layer 4. Also note that load balanced connections at layer 7 are not source IP transparent, which is not usually an issue when load balancing print servers but should still be considered.
About Layer 4 DR mode load balancing
One-arm direct routing (DR) mode is a very high performance solution that requires little change to your existing infrastructure.

DR mode works by changing the destination MAC address of the incoming packet to match the selected Real Server on the fly which is very fast.
When the packet reaches the Real Server it expects the Real Server to own the Virtual Services IP address (VIP). This means that you need to ensure that the Real Server (and the load balanced application) respond to both the Real Server’s own IP address and the VIP.
The Real Servers should not respond to ARP requests for the VIP. Only the load balancer should do this. Configuring the Real Servers in this way is referred to as Solving the ARP problem.
On average, DR mode is 8 times quicker than NAT for HTTP, 50 times quicker for Terminal Services and much, much faster for streaming media or FTP.
The load balancer must have an Interface in the same subnet as the Real Servers to ensure Layer 2 connectivity required for DR mode to work.
The VIP can be brought up on the same subnet as the Real Servers, or on a different subnet provided that the load balancer has an interface in that subnet.
Port translation is not possible with DR mode, e.g. VIP:80 → RIP:8080 is not supported. DR mode is transparent, i.e. the Real Server will see the source IP address of the client.

