A load balancer, also referred to as an IP sprayer, enables horizontal scalability by dispatching TCP/IP traffic among several identically configured servers. Depending on the product used for load balancing, different protocols are supported.
Load balancer is implemented using the Load Balancer Edge component provided with the Network Deployment package, which provides load balancing capabilities for HTTP, FTP, SSL, SMTP, NNTP, IMAP, POP3, Telnet, SIP, and any other TCP based application.
Horizontal scaling topology with an IP sprayer
Load balancing products can be used to distribute HTTP requests among Web servers running on multiple physical machines. The Load Balancer component of Network Dispatcher, for example, is an IP sprayer that performs intelligent load balancing among Web servers based on server availability and workload.
Figure below illustrates a horizontal scaling configuration that uses an IP sprayer to redistribute requests between Web servers on multiple machines.
The active Load Balancer hosts the highly available TCP/IP address, the cluster address of your service and sprays requests to the Web servers. At the same time, the Load Balancer keeps track of the Web servers health and routes requests around Web servers that are not available. To avoid having the Load Balancer be a single point of failure, the Load Balancer is set up in a hot-standby cluster. The primary Load Balancer communicates its state and routing table to the secondary Load Balancer. The secondary Load Balancer monitors the primary Load Balancer through heartbeat and takes over when it detects a problem with the primary Load Balancer. Only one Load Balancer is active at a time.
Both Web servers are active at the same time and perform load balancing and failover between the application servers in the cluster through the Web server plug-in. If any component on System C or System D fails, this should be detected by the plug-in and the other server can continue to receive requests.
Using Web servers
In WebSphere Application Server, a Web server can be administratively defined to the cell. This allows the association of applications to one or more Web servers and custom plug-in configuration files to be generated for each Web server.
Managed and unmanaged nodes: When you define a Web server to WebSphere Application Server, it is associated with a node. The node is either a managed or an unmanaged. When we refer to managed Web servers, we are referring to a Web server defined on a managed node. An unmanaged Web server resides on an unmanaged node. In a stand-alone server environment, you can define one unmanaged Web server. In a distributed environment, you define multiple managed or unmanaged Web servers.
Managed Web servers
Defining a managed Web server allows you to start and stop the Web server from the Integrated Solutions Console and push the plug-in configuration file to the Web server. A node agent must be installed on the Web server machine. An exception is if the Web server is the IBM HTTP Server. Figure below illustrates a Web server managed node:
Unmanaged Web servers
Unmanaged Web servers reside on a system without a node agent. This is the only option in a stand-alone server environment and is a common option for Web servers installed outside a firewall. The use of this topology requires that each time the plug-in configuration file is regenerated, it is copied from the machine where WebSphere Application Server is installed to the machine where the Web server is running. Figure below illustrates a Web server unmanaged node:
IBM HTTP Server as an unmanaged Web server (special case)
If the Web server is IBM HTTP Server, it can be installed on a remote machine without installing a node agent. You can administer IBM HTTP Server through the deployment manager using the IBM HTTP Server Admin Process for tasks such as starting, stopping, or automatically pushing the plug-in configuration file. Figure below illustrates an IBM HTTP Server unmanaged node:
Although you can install the Web server on the same system as WebSphere Application Server, and you can even direct HTTP requests directly to the application server, you should have a Web server in a DMZ as a front-end to receive requests. The Web server is located in a DMZ to provide security, performance, throughput, availability, and maintainability, while the application server containing business logic is located securely in a separate network: