Load balancing GE HealthCare Centricity Cardio Workflow

Updated on March 19, 2025
Published on April 5, 2024

About GE HealthCare’s Centricity Cardio Workflow

GE HealthCare’s Centricity Cardio Workflow is a cardiovascular information system (CVIS) and PACS that provides a single point of access for cardiologists. Configurable end-to-end workflows provide clinicians with seamless access to patient data, cardiovascular imaging, and reports. These powerful features improve staff productivity and accelerate patient diagnosis and treatment.

Centricity Cardio Workflow offers numerous advanced interfaces and solutions for a variety of different use cases, which means individual workflows can be optimized for maximum efficiency. 

Together with the Centricity Universal Viewer, the Centricity Cardio Workflow forms part of Centricity Cardio Enterprise

Key benefits of load balancing

Here are a few key benefits:

  • Ensures the application is always available
  • Provides stable, optimal performance
  • Ability to isolate servers which reduces risk when performing upgrades/maintenance
  • Scalability

How to load balance GE HealthCare’s Centricity Cardio Workflow

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 SNAT mode.

For Centricity Cardio Workflow, Layer 4 DR mode and Layer 7 SNAT mode are recommended.

Layer 4 DR mode

One-arm direct routing (DR) mode is a very high performance solution that requires little change to your existing infrastructure. 

Network diagram. Layer 7 SNAT mode 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 SNAT mode is a full proxy, any server in the cluster can be on any accessible subnet including across the Internet or WAN. 

Layer 7 SNAT mode 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 SNAT 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. It does not require any mode-specific configuration changes to the load balanced Real Servers. 

Port translation is possible with Layer 7 SNAT mode e.g. VIP:80 → RIP:8080 is supported. You should not use the same RIP:PORT combination for Layer 7 SNAT mode VIPs and Layer 4 SNAT mode VIPs because the required firewall rules conflict.