Benefits of load balancing EMIS Health Symphony

Load balancing EMIS Symphony offers a number of important benefits:

• High Availability (HA): Load balancing ensures the application remains continuously accessible to clinicians and staff. By monitoring the health of all application servers and automatically redirecting traffic away from a failing or offline server, it prevents service interruptions. This is critical for 24/7 healthcare operations, such as Emergency Departments.
• Optimal performance: Load balancers efficiently distribute user requests across multiple servers, preventing any single server from becoming overloaded. This minimizes response times and throughput, ensuring the system runs at stable, optimal performance even during periods of high demand (e.g., peak operational hours or patient surges).
• Enhanced scalability: The architecture allows for adding or removing servers (scaling out or in) without disrupting service, meaning the system can easily handle growth in user numbers or system usage over time. It provides the ability to isolate servers for routine maintenance, upgrades, or patching (e.g., of the underlying operating system or application) without taking the entire application offline. This significantly reduces the risk associated with critical system maintenance.

About EMIS Health Symphony

EMIS Symphony is the market leading clinical system for urgent and emergency care, supporting patient management, tracking and clinical workflows. With Symphony, busy teams can access information at the point of care, enabling them to work more efficiently, safely, and effectively.

The 111 service can book directly into multiple departments using electronic appointment booking, and GP Connect Viewer provides access to comprehensive patient records. All of these work together to flow patients quickly through the urgent care footprint, and avoid funnelling all pathways through the emergency department.

Why Loadbalancer.org for EMIS Health Symphony?

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 EMIS Health Symphony

The load balancer can be deployed in 4 fundamental ways: 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 EMIS Symphony, Layer 4 DR mode and Layer 7 Reverse Proxy mode are recommended.

Virtual service (VIP) requirements

To provide load balancing and HA for EMIS Symphony, a single VIP is required:

• Symphony (for HTTPS-based client access)

Load balancing deployment concept

About Layer 4 DR mode

Layer 4 DR (Direct Routing) mode is a very high performance solution that requires little change to your existing infrastructure. The image below shows an example Layer 4 DR mode network diagram:

• 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 Servers own IP address and the VIP
• The Real Server 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 in DR mode i.e. having a different RIP port than the VIP port
• 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 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. 

Related Resources