Benefits of load balancing Fujifilm SYNAPSE
The benefits of load balancing the entire Fujifilm SYNAPSE suite (which includes Synapse PACS, Synapse VNA, Synapse Pathology, Synapse 3D, etc.) are crucial for maintaining a high-performance, ultra-reliable Enterprise Imaging environment. The core benefits can be broken down into three critical areas:
- High availability (HA): This is perhaps the most critical benefit in a life-saving clinical environment. By clustering multiple Synapse servers (for PACS, VNA, etc.), the load balancer acts as a virtual traffic cop, eliminating the single point of failure. If one server fails, the load balancer instantly detects the outage and redirects all user traffic to the remaining healthy servers. This seamless failover ensures zero downtime for clinicians, allowing radiologists, pathologists, and other specialists to access diagnostic images and patient data without interruption, which is vital for timely patient care. IT teams can also take individual servers offline for scheduled maintenance, patches, or upgrades without impacting the user experience, as the load balancer handles the workload shift transparently.
- Enhanced performance and throughput: Medical images (CT, MRI, whole-slide pathology images) are massive, requiring huge bandwidth and processing power. The load balancer intelligently distributes incoming client requests (DICOM traffic, image viewing requests, data storage, etc.) across the entire server cluster. This prevents any single server from becoming a bottleneck, ensuring optimal use of all available CPU, RAM, and network resources. By balancing the load, the system avoids lag and slowdowns during peak hours, delivering instant image and data retrieval and maintaining high-speed performance for demanding applications like Synapse 3D and Synapse Pathology. Clinicians experience faster, more responsive applications, leading to streamlined workflows and reduced diagnostic turnaround times.
- Scalability: As the hospital or health system grows (acquiring new facilities, increasing patient volume, or adopting new imaging modalities like digital pathology), the load-balanced architecture allows IT to simply add new Synapse servers to the cluster to handle the increased load. This elastic, scalable architecture ensures the Synapse system can meet the demands of continually increasing study volumes without the need for costly, disruptive forklift upgrades. Load balancing can also be extended to balance traffic across multiple physical data centers or hybrid cloud environments, enabling robust disaster recovery and geographically distributed image sharing for large enterprise deployments.
In this way, load balancing forms the foundation a resilient, high-performance architecture that meets the non-negotiable requirements of a modern, mission-critical Enterprise Imaging platform like the Fujifilm Synapse suite.
About Fujifilm SYNAPSE
Fujifilm SYNAPSE is a suite of enterprise imaging applications by Fujifilm. This includes Synapse PACS, Synapse VNA and Synapse PACS Mobility, which allow the archiving and distribution of image information from all modalities.
SYNAPSE has revolutionized the management of radiology imaging services, supporting image diagnosis with high-quality images, numerous image-processing features and easy operation. All of this affords exciting new possibilities in this rapidly evolving medical field.
For caregivers to work effectively, peak performance of SYNAPSE 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 Fujifilm SYNAPSE?
This deployment guide isn’t theoretical; it has been field tested and rigorously validated by Fujifilm 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 Fujifilm SYNAPSE
The load balancer can be deployed in four fundamental ways: Layer 4 DR mode, Layer 4 NAT mode, Layer 4 SNAT mode, and Layer 7 Reverse Proxy (Layer 7 SNAT mode).
For Fujifilm SYNAPSE, Layer 4 DR and Layer 7 Reverse Proxy is recommended.
Virtual service (VIP) requirements
To provide load balancing and HA for Fujifilm SYNAPSE, the following VIPs are required:
SYNAPSE PACS
| Ref. | VIP Name | Operating Mode | Protocol | Port(s) | Persistence | Health Check |
|---|---|---|---|---|---|---|
| VIP 1 | SynapsePacsHTTP | Layer 7 Reverse Proxy | TCP | 80 | Source IP | Connect to Port |
| VIP 2 | SynapsePacsDICOM | Layer 4 DR mode | TCP | 104 | Source IP | External Script DICOM-C-ECHO |
SYNAPSE VNA
| Ref. | VIP Name | Operating Mode | Protocol | Port(s) | Persistence | Health Check |
|---|---|---|---|---|---|---|
| VIP 1 | SynapseVnaHTTP | Layer 7 Reverse Proxy | TCP | 80 | Source IP | Connect to Port |
| VIP 2 | SynapseVnaDICOM | Layer 4 DR mode | TCP | 104 | Source IP | External Script DICOM-C-ECHO |
SYNAPSE MOBILITY
| Ref. | VIP Name | Operating Mode | Protocol | Port(s) | Persistence | Health Check |
|---|---|---|---|---|---|---|
| VIP 1 | SynapseMobility | Layer 7 Reverse Proxy | TCP | 8080, 8443 | Source IP | Negotiate HTTP (GET) |
SYNAPSE CWM
| Ref. | VIP Name | Operating Mode | Protocol | Port(s) | Persistence | Health Check |
|---|---|---|---|---|---|---|
| VIP 1 | SynapseCwm | Layer 7 Reverse Proxy | HTTP | 80 | HTTP Cookie | Connect to Port |
Persistence
It is necessary to use persistence when load balancing connections to Fujifilm Synapse. This is true for all three of the virtual services that are involved. Source IP persistence is recommended and is used by default.
Load balancing deployment concept
When Fujifilm systems are deployed with the load balancer, clients connect to the Virtual Service (VIP) on the load balancer rather than connecting directly to one of the Fujifilm servers. The load balancer then distributes these connection to the load balanced servers according to the algorithm selected.
Note
The load balancer can be deployed as a single unit, although Loadbalancer.org recommends a clustered pair for resilience & high availability.
Data encryption
External connections are secured using TLS/SSL (HTTPS). This ensures that data is encrypted as it passes between an external client and a back-end server. TLS/SSL connections can either be terminated on the load balancer (aka SSL offloading) or on the real servers (aka SSL pass-through). When terminating on the load balancer, it’s also possible to enable re-encryption so that the connection from the load balancer to the real servers is protected (aka SSL bridging).
About Layer 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 either 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.
The image below shows an example Layer 7 Reverse Proxy network diagram:
Because Layer 7 Reverse Proxy is a full proxy, Real Servers in the cluster can be on any accessible network 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 2 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. For more information on these methods, please refer to Transparency at Layer 7 in the Enterprise Admin Manual.
