Benefits of load balancing GE HealthCare Centricity PACS

Load balancing GE Healthcare Centricity PACS provides a number of benefits that collectively contribute to enhanced workflow efficiency for radiologists and caregivers by ensuring timely and reliable access to imaging data:

• High Availability (HA): Load balancing ensures that the Centricity PACS system remains continuously available, which is vital in a healthcare setting where downtime can directly impact patient care and diagnosis. By distributing incoming traffic (like DICOM studies and retrieval requests) across multiple servers, the system avoids having a single point of failure. If one server experiences a failure or becomes unresponsive, the load balancer automatically and seamlessly redirects all traffic to the remaining healthy servers (a process called failover). This redundancy means physicians and radiologists maintain uninterrupted access to critical patient images and clinical records at all times, supporting timely diagnosis and treatment.
• Optimal performance: Load balancing distributes the workload to prevent any single PACS server from becoming overwhelmed, leading to faster service and the ability to grow the system easily. Requests are intelligently routed to the server with the least current load or best performance, which reduces latency and ensures rapid access to large medical images and records. This is especially important for high-volume environments or during peak hours (e.g., in the Emergency Department).
• Scalability for growth: As a healthcare organization grows—acquiring more imaging equipment, adding departments, or managing increasing patient volumes—load balancing allows the IT team to easily add new servers to the PACS cluster without disrupting existing services, accommodating the massive growth of medical imaging data.

About GE HealthCare Centricity PACS

The GE Centricity suite of products for Enterprise Imaging provides a common viewing, workflow and archiving medical imaging solution which integrates PACS, RIS, CVIT, VNA and cloud-based sharing solutions.

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.

Clustering multiple load balanced GE Centricity PACS servers provides product managers with a fast cost-effective, highly available and scalable solution, in an environment where study volume is ever increasing.

Why Loadbalancer.org for GE HealthCare Centricity PACS

This deployment guide isn’t theoretical; it has been field tested and rigorously validated by GE 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 GE HealthCare Centricity PACS

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 GE HealthCare Centricity PACS, both Layer 4 DR mode and Layer 7 Reverse Proxy mode are recommended.

Virtual service (VIP) requirements

To provide load balancing and HA for CPACS, the following VIPs are required:

Ref.	VIP Name	Mode	Port(s)	Persistence Mode	Health Check
VIP 1	EA_XDS_Service	Layer 4 DR	80	None	HTTP (GET)
VIP 2	EA_Dicom_Service	Layer 4 DR	104	None	HTTP (GET)
VIP 3	EA_Secure_Dicom_Service	Layer 4 DR	2762	None	HTTP (GET)
VIP 4	EA_HL7_Service	Layer 4 DR	2575	None	HTTP (GET)
VIP 5	EA_Secure_HL7_Service	Layer 4 DR	2576	None	HTTP (GET)
VIP 6	EA_Study_Management_Service	Layer 4 DR	443	Source IP	HTTP (GET)
VIP 7	DB_MT	Layer 4 SNAT	All ports except 20000	Source IP	Connect to Port
VIP 8	DB_DBVIP	Layer 4 SNAT	20000	None	ICMP Ping
VIP 9	DAS_Pool	Layer 4 DR	4100,8080,104	Source IP	HTTP (GET)
VIP 10	ZFP	Layer 7 Reverse Proxy	443	Source IP	HTTPS (GET)
VIP 11	UV	Layer 7 Reverse Proxy	443	Source IP	HTTPS (GET)
VIP 12	Dakota	Layer 7 Reverse Proxy	SP1: 8080, SP2: 8443	Source IP	SP1: Connect to port, SP2: HTTPS (GET)
VIP 13	WFM_Play_Group	Layer 7 Reverse Proxy	SP1: 8080, SP2: 9443	Source IP	HTTPS (GET)
VIP 14	WFM_tomcat_Group	Layer 7 Reverse Proxy	SP1: 9096, SP2: 9096,3443	Source IP	HTTPS (GET)
VIP 15	XE_Standalone	Layer 7 Reverse Proxy	8443,9449	Source IP	HTTPS (GET)
VIP 16	CCG_IB_2101	Layer 7 Reverse Proxy	2101	Last successful	Connect to Port
VIP 17	CCG_IB_2102	Layer 7 Reverse Proxy	2102	Last successful	Connect to Port
VIP 18	PORT_CCG_IB_2103	Layer 7 Reverse Proxy	2103	Last successful	Connect to Port
VIP 19	PORT_CCG_IB_2104	Layer 7 Reverse Proxy	2104	Last successful	Connect to Port

Load balancing deployment concept

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 SNAT mode. For GE Centricity PACS, a combination of layer 4 SNAT mode and layer 7 SNAT mode is recommended.

By utilizing Layer 4 DR mode, our entry-level Enterprise Prime easily handles environments of up to 500k studies/year. For anything larger, our Enterprise Flex offers an infinitely scalable solution at an unbelievable price-point.

Having partnered with top-tier healthcare vendors, Loadbalancer.org brings expert consultancy and support to all of our deployments. Our extensive experience in Enterprise Imaging means that we understand the challenges you face, and are ready to meet them with tried-and-tested solutions.

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

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:

1. Either by inserting a header that contains the client’s source IP address, or 
2. 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.

Related Resources