Load balancing Canon Medical Systems — Vitrea and DelftDI
Updated on November 19, 2025
•
Published on August 12, 2019
Benefits of load balancing Canon Medical Systems
Load balancing Canon Medical Systems provides the following benefits:
- High Availability (HA): High Availability is arguably the most critical benefit in a 24/7 patient care environment. Load balancing ensures that vital imaging data is continuously accessible, minimizing the risk of downtime, which could be life-threatening. Load balancers constantly monitor the “health” of all image servers (like PACS and VNA servers). If a server fails or needs maintenance, the load balancer automatically and seamlessly redirects all incoming traffic and existing connections to the remaining healthy servers. This prevents any single point of failure from causing an outage.
- Enhanced performance: Medical imaging files (from modalities like CT, MRI, and 3D mammography) are very large. Load balancing prevents system slowdowns by efficiently managing the heavy workload. It intelligently distributes the processing load and incoming requests across multiple servers. This prevents any one server from becoming overloaded or a bottleneck. By routing requests to the least busy server or the one with the most available resources, it ensures the rapid processing and retrieval of large studies. This leads to faster response times for clinicians, improving workflow efficiency and reducing turnaround times for reports.
- Scalability for future growth: Load balancing provides the necessary flexibility to handle the constantly increasing volume of medical data and growing user demands without service interruption. As a healthcare organization grows or acquires new, high-volume imaging equipment, new servers can be easily added to the PACS or VNA cluster. The load balancer automatically incorporates these new servers into the distribution pool, allowing the system to scale out its capacity and handle the increased workload without taking the entire system offline or degrading performance.
About Canon Medical Systems
Canon Medical offers a suite of enterprise imaging systems, encompassing applications by DelftDI and Vitrea VNA. Delft DI provides scalable PACS and RIS enterprise imaging systems, while Vitrea provides a next generation VNA, offering a flexible, service-oriented architecture.
For caregivers to work effectively, peak performance of these applications is crucial. Doctors demand instant image and data retrieval, zero downtime, and systems which are easy to maintain with simple security updates.
Why Loadbalancer.org for Canon Medical Systems?
This deployment guide isn’t theoretical; it has been field tested and rigorously validated by Philips Healthcare experts. This means you can be completely confident that the solution described is robust, reliable, and backed by the real-world operational experience of a global leader in healthcare technology.
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 Canon Medical Systems
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 Canon Medical Systems, both Layer 4 DR mode and Layer 7 Reverse Proxy (Layer 7 SNAT mode) are used.
Virtual service (VIP) requirements
To provide load balancing and HA for Canon Enterprise Imaging Suite, the following VIPs are required:
| Ref. | VIP Name | Mode | Port(s) | Persistence Mode | Health Check |
|---|---|---|---|---|---|
| VIP 1 | DicomRouting | Layer 4 DR | TCP/11112 | Source IP | Connect to Port |
| VIP 2 | DicomInternal | Layer 4 DR | TCP/11112 | Source IP | Connect to Port |
| VIP 3 | HL7Live | Layer 4 DR | TCP/2398 | Source IP | Connect to Port |
| VIP 4 | HL7Migrate | Layer 4 DR | TCP/2988 | Source IP | Connect to Port |
| VIP 5 | MWL | Layer 4 DR | TCP/4106 | Source IP | Connect to Port |
| VIP 6 | VPWorklistHL7Live | Layer 4 DR | TCP/19001 | Source IP | Connect to Port |
| VIP 7 | VPWorklistHL7Migrate | Layer 4 DR | TCP/19002 | Source IP | Connect to Port |
| VIP 8 | MINT | Layer 4 DR | TCP/8080 | Source IP | Connect to Port |
| VIP 9 | WorklistHL7Draft | Layer 4 DR | TCP/19011 | Source IP | Connect to Port |
| VIP 10 | WorklistHL7Prelim | Layer 4 DR | TCP/19012 | Source IP | Connect to Port |
| VIP 11 | WorklistHL7Signed | Layer 4 DR | TCP/19013 | Source IP | Connect to Port |
| VIP 12 | VC_AdminTools | Layer 7 Reverse Proxy | TCP/8238 | HTTP Cookie | Connect to Port |
| VIP 13 | AuthM | Layer 7 Reverse Proxy | TCP/8236 | HTTP Cookie | Connect to Port |
| VIP 14 | VitreaRead | Layer 7 Reverse Proxy | TCP/8237 | HTTP Cookie | Connect to Port |
| VIP 15 | Worklist | Layer 7 Reverse Proxy | TCP/8089 | HTTP Cookie | Connect to Port |
| VIP 16 | VPSmartReporting | Layer 7 Reverse Proxy | TCP/8994 | HTTP Cookie | Connect to Port |
Load balancing deployment concept
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.
About Layer 7 Reverse Proxy load balancing
Layer 7 Reverse Proxy uses a proxy (HAProxy) at the application layer. Inbound requests are terminated on the load balancer and HAProxy generates a new corresponding request to the chosen Real Server. As a result, Layer 7 is typically not as fast as the Layer 4 methods.
Layer 7 is typically chosen when enhanced options such as SSL termination, cookie based persistence, URL rewriting, header insertion/deletion etc. are required, or when the network topology prohibits the use of the Layer 4 methods.
Because Layer 7 Reverse Proxy is a full proxy, any server in the cluster can be on any accessible subnet, including across the Internet or WAN.
Layer 7 Reverse Proxy is not transparent by default i.e. the Real Servers will not see the source IP address of the client, they will see the load balancer’s own IP address by default, or any other local appliance IP address if preferred (e.g. the VIP address). This can be configured per Layer 7 VIP.
If required, the load balancer can be configured to provide the actual client IP address to the Real Servers in two ways:
- Either by inserting a header that contains the client’s source IP address, or
- By modifying the Source Address field of the IP packets and replacing the IP address of the load balancer with the IP address of the client.
Layer 7 Reverse Proxy mode can be deployed using either a one-arm or two-arm configuration. For two-arm deployments, eth0 is normally used for the internal network and eth1 is used for the external network, although this is not mandatory.
No mode-specific configuration changes to the load balanced Real Servers are required.
Port translation is possible with Layer 7 Reverse Proxy e.g. VIP:80 → RIP:8080 is supported. You should not use the same RIP:PORT combination for Layer 7 Reverse Proxy VIPs and Layer 4 SNAT mode VIPs because the required firewall rules conflict.
