Web-server networks and their associated demilitarized zones (DMZs) differ from server networks and access networks in that horizontal scalability is generally possible. This means that the servers can be made more available by simply adding extra components of similar design. Therefore, design of web-server networks is aimed at ensuring sufficient capacity rather than at securing single servers.
With load balancing, requests to a single server are distributed across similar servers, using the following mechanisms:
· Web switches
· Windows load-balancing server
· Round-robin Domain Name Service (DNS)
These basic mechanisms are described below.
A problem here is session persistence. This means that, for “stateful” applications, the session is stored on the application server. Therefore, all subsequent requests relating to a specific session must be routed to the same server. There are the following solutions to this problem:
· Session cookie
This ensures that all requests for a specific session are correctly assigned to the same session. However, this method does not work with end-to-end Secure Sockets Layer (SSL) encryption.
· Client IP addresses
A specific client IP address is associated with a specific session. This method also functions with SSL and can be used for the Internet Transaction Server (ITS). However, with a large number of users connected using the same proxy server, this method is not sufficiently scalable. With proxy load balancing, this method only functions when specific portions of the IP address are evaluated.
· Direct connection to a special server
Since the same server is always addressed, the contexts are always available. A direct server connection is effectively achieved using round-robin DNS and redirection.
Using SSL session ID to solve the problem of persistence is not a viable solution, because the SSL session is generally shorter than the user session. Therefore, it cannot be used for this purpose.
Intelligent load balancing ensures that requests are distributed to the available servers according to their availability and other defined criteria. In effect a virtual server is created:
In the event of failure, the load balancer notes which server is unavailable and sends it no more requests. This mechanism also enables planned downtime for individual servers without impacting the availability of the virtual server as a whole.
You can increase availability still further by using redundant load balancers with switchover.
In general, load balancers also offer the possibility of network address translation (NAT), so that the transparently connected servers can use a completely different address area of the virtual server.
The SAP Web dispatcher enables load balancing of requests to several SAP Web Application Servers, in a similar way to web switches (as described above). The configuration and the load balancing are based on information regularly received by the SAP Web dispatcher from the message server.
SAP Web Dispatcher
To avoid a single point of failure in the SAP Web dispatcher, you can implement a failover cluster.
SAP Web Dispatcher can be configured to terminate SSL sessions directly (and forward HTTP or re-encrypt and forward HTTPS), so that session cookies can be used to assign a session to an application server. Therefore, the SAP Web dispatcher is “state-independent,” enabling failover without data loss.
In addition, the SAP Web Dispatcher can be configured for End-to-End SSL (see graphic above).
For more information, see SAP Web Dispatcher.
With SAP Web Dispatcher there are several load balancing methods available. For more information, see SAP Web Dispatcher.
This method uses a separate web server to distribute requests between web servers. In fact, a Universal Resource Locator (URL) is called not from the actual web server but from the redirector. The redirector runs a Common Gateway Interface (CGI) program that returns the URL of the required web server and initiates an automatic redirect, as shown in the following graphic:
Session persistence is guaranteed from the start. This is because, after redirection (which occurs at the start), the client is connected to a single server for the entire session. If a web server fails, there is no automatic redirection to an available web server. The address, which points to a redirector, must be called again.
The disadvantage of redirection is that, when used in the internet, each server requires an official IP address and server certificates. Since each server is addressed using its own URL, bookmarks only point to a single server.
The message server offers a load balancing service based on redirection. For more information see HTTP Load Distribution Using SAP Message Server.
Firewalls, used to secure demilitarized zones (DMZs), should also be set up in a redundant way, so that there is no single point of failure. With support of the Virtual Router Redundancy Protocol (VRRP), the firewalls appear transparent. It is possible to switch quickly and balance the load.
For more information, see Using Firewall Systems for Access Control. You can also find this information on SAP Service Marketplace at:
service.sap.com/securityguide ® Network and Communication Security