Loadbalancer.org facilitates the deployment of Insignia Medical Systems servers in a cluster, ensuring zero downtime and greatest resource efficiency. This provides a cost-effective, highly available, and scalable Insignia Medical solution for environments where study volume is ever increasing.
By clustering servers behind a load balancer product managers can guarantee zero downtime and greatest resource efficiency. This provides a cost-effective, highly available, and scalable Insignia Medical Systems solution.
Loadbalancer.org are specialists in delivering ultra-reliable, scalable medical imaging applications. In an industry where uptime saves lives, our extensive experience means we can design unbreakable solutions to enterprise imaging’s unique challenges.
To provide resilience and high availability, multiple Virtual Services (VIPs) are configured for the various protocols and
systems. Clients and systems then connect to these VIPs rather than directly to the application servers. Each VIP can
be configured in one of the following ways:
• Load balanced mode
Load is distributed across all configured servers/endpoints
• Failover mode
The second server is used only when the first server/endpoint fails
Load Balancer Deployment
The following diagram shows a simplified view of Insignia Medical System in load balancing mode:
The following diagram shows a simplified view of Insignia Medical System in failover mode:
• VIP (Virtual IP) – This is IP address presented by the load balancer. Clients and other systems connect to this
rather than directly to the back end servers/endpoints
• A single load balancer appliance can be used to load balance all services. More that one load balancer
appliance may be required depending on throughput and physical network topology
• All Loadbalancer.org models support unlimited VIPs except the Enterprise R20 which supports up to 5 VIPs,
each with up to 4 load balanced servers
Load Balancing Deployment Modes
The load balancer supports the following deployment modes:
Layer 4 DR Mode – this mode offers the best performance and requires limited physical Real Server changes. The load
balanced application must be able to bind to the Real Servers own IP address and the VIP at the same time. This mode
requires the “ARP Problem” to be solved as described in our deployment guide. This mode is transparent, i.e. the Real Servers will see
the source IP address of the client.
Layer 4 NAT Mode – this mode is also a high performance solution but not as fast as DR mode. It requires the
implementation of a two-arm infrastructure with an internal and external subnet to carry out the translation (the same
way a firewall works). Also each Real Server must use the load balancer as the default gateway. This mode is
transparent, i.e. the Real Servers will see the source IP address of the client.
Layer 4 SNAT Mode – this mode is also a high performance solution but not as fast as the other layer 4 modes. It does
not require any changes to the Real Servers and can be deployed in one-arm or two-arm mode. This mode is ideal for
example when you want to load balance both TCP and UDP but you’re unable to use DR mode or NAT mode due to
network topology or Real Server related reasons. This mode is non-transparent, i.e. the Real Servers will see the source
IP address of the load balancer.
Layer 7 SNAT Mode – this mode offers greater flexibility but at lower performance levels. It supports HTTP cookie
insertion, RDP cookies, Connection Broker integration and works very well with either Pound or STunnel when SSL
termination is required. It does not require any changes to the Real Servers and can be deployed in one-arm or two-arm
mode and. HAProxy is a high performance solution, but since it operates as a full proxy, it cannot perform as fast as the
layer 4 solutions. This mode is non-transparent, i.e. the Real Servers will see the source IP address of the load balancer.
Where possible we recommend that Layer 4 Direct Routing (DR) mode is used. This mode offers the best possible
performance since replies go directly from the Real Servers to the client, not via the load balancer. It’s also relatively
simple to implement. Ultimately, the final choice does depend on your specific requirements and infrastructure.
Note: If you are using Microsoft Windows Real Servers (i.e. the backend servers) make sure that
Windows NLB (Network Load Balancing) is completely disabled to ensure that this does not interfere
with the operation of the load balancer.
Load Balanced Ports & Services
The following tables shows the typical ports/services that are load balanced.
|104||TCP/DICOM||Exchange of images and related information|
|2575||TCP/HL7||Communication between health-care IT systems|
Persistence (Server Affinity)
Source IP address persistence is used for all protocols. This ensures that a particular client will connect to the same
load balanced server/endpoint for the duration of the session.
Server Health Checking
The default health-check used for new VIPs is a TCP port connect. This verifies that the port is open and accepting
connections. However, it does not necessarily guarantee that the associated service is fully operational. Also, repeated
ongoing connections to the service port may cause multiple log entries reporting incomplete connections or other
More robust service oriented health-checks can be configured for both layer 4 and layer 7 services using the negotiate
option. This effectively tests and verifies the running service.
For example, the load balancer can be configured to look for specific content on an HTTP web page on the load
balanced Real Server. If the page can be opened and the content can be found, the check will have passed. If not, the
check will fail and the server/endpoint will be marked as down.
If the service running is not HTTP based, a custom page could be setup on the load balanced servers that simply
indicates service status. The load balancer can then use this for health checking.
The page to check and the content to be verified can easily be configured for layer 4 and layer 7 VIPs using the WebUI.
Select the required negotiate option and configure the required settings. For more details on configuring health-checks
please refer to Chapter 8 in the Administration Manual.
Note: The configuration examples in this guide use a TCP port connect (the default) to check the
health of load balanced servers.
Medical Information System Standards & Protocols
The Digital Imaging and Communications in Medicine (DICOM) Standard describes the means of formatting, storing
and exchanging medical images and image related information to facilitate the connectivity of medical devices and
systems. The DICOM Standard endorsed by the National Electrical Manufacturers Association (NEMA) is a result of
joint efforts of users and manufacturers of medical imaging and health-care information technology.
Today, virtually all imaging devices (Modalities) that are used in radiology, such as CT, MRI, Ultrasound, RF, and other
digital rooms, supports the DICOM standard for the exchange of images and related information.
Health Level Seven (HL7) is an American National Standards Institute accredited Standards Developing Organization
(SDO) operating in the health-care arena. Since its inception, HL7 has specified standards for a large number of
application areas. HL7 standards cover generic application fields such as patient administration, patient care, order
entry, results reporting, document and financial management. In addition to that, HL7 addresses the departmental
information system communication needs of clinical specialties like laboratory medicine and diagnostic imaging. HL7 is
the language used for communication between health-care IT systems.