Load balancing GE Healthcare Datalogue (DL)
Useful resources
GE HealthCare Datalogue (DL)
GE HealthCare Datalogue (DL) is a multi-ology, vendor neutral enterprise archive (VNA) and workflow management solution.
It helps lower costs by providing a consolidated view of medical imaging and clincial IT infrastructure, improve clinical workflow operational efficiency, improve the patient experience, foster more informed decision making, and improve productivity with more streamlined information sharing.
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 Datalogue (DL)
For GE HealthCare DL, Layer 4 DR mode and Layer 7 SNAT mode are used.
Layer 4 DR mode
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.
Layer 7 SNAT Mode
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:
- 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 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.
No mode-specific configuration changes to the load balanced Real Servers are required.
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.
deployment guide
GE HealthCare Datalogue
Read deployment guidemanual
Read Manual
Read manualblogs
One medical imaging vendor's journey from 'it's not my problem' to a strategic load balancing partnership
Read blogHow Loadbalancer.org helped this medical imaging vendor centrally manage their load balancing estate
Read blogHow Loadbalancer.org provided this medical imaging vendor with more technical and commercial flexibility in AWS
Read blogOne medical imaging vendor's journey from 'it's not my problem' to a strategic load balancing partnership
Read blogother
Load balancing for highly available medical imaging applications
Read otherGE HealthCare’s Centricity Cardio Workflow
Read other