ILB supports stateless DSR and NAT modes of operation for IPv4 and IPv6 in single-legged and dual-legged topologies.
In DSR mode, ILB balances the incoming requests to the back-end servers but allows the return traffic from the servers to the clients to bypass it. However, if you set up ILB to be used as a router for a back-end server, the response from the back-end server to the client is routed through the system that is running ILB. ILB's current implementation of DSR does not provide TCP connection tracking, making it stateless. With stateless DSR, ILB does not save any state information of the processed packets except for basic statistics. Being stateless, the performance is comparable to the normal IP forwarding performance. The DSR mode is best suited for connectionless protocols.
DSR provides better performance than NAT because only the destination MAC address of packets is changed and servers respond directly to clients.
There is full transparency between the server and the client. The servers see a connection directly from the client IP address and reply to the client through the default gateway.
The back-end server must respond to both its own IP address (for health checks) and the virtual IP address (for load-balanced traffic).
Being stateless, adding or removing servers causes connection disruption.
The following figure shows the implementation of ILB in the DSR mode.
Figure 4 Direct Server Return Topology
In this figure, both back-end servers are in the same subnet (192.0.2.0/27) as the ILB box. The servers are also connected to the router so that they can reply directly to clients after receiving a request forwarded by the ILB box.
ILB uses NAT in stand-alone mode strictly for load-balancing functionality. In this mode, ILB rewrites the header information and handles the incoming as well as the outgoing traffic. ILB operates in both the half-NAT and full-NAT modes. However, full-NAT also rewrites the source IP address, making it appear to the server that all connections are originating from the load balancer. NAT does provide TCP connection tracking (meaning that it is stateful). The NAT mode provides additional security and is best suited for Hypertext Transfer Protocol (HTTP) or Secure Sockets Layer (SSL) traffic.
Works with all back-end servers by changing the default gateway to point to the load balancer
Adding or removing servers without connection disruption is possible because the load balancer maintains the connection state
Slower performance than DSR because processing involves manipulation of the IP header and servers send responses to the load balancer
All the back-end servers must use the load balancer as a default gateway
The general implementation of the NAT mode is as shown in the following figure.
Figure 5 Network Address Translation Topology
In this case, all requests to the VIP go through the ILB and are forwarded to the back-end servers. All the replies from the back-end servers pass through the ILB for NAT.
Caution - The NAT code path that is implemented in ILB differs from the code path that is implemented in the IP Filter feature of Oracle Solaris. Do not use both these code paths simultaneously. |
In the half-NAT mode of the ILB operation, ILB rewrites only the destination IP address in the header of the packets. If you are using the half-NAT implementation, you cannot connect to a VIP address of the service from the same subnet on which the server resides. The following table shows the IP addresses of the packets flowing between the client and ILB, and between ILB and back-end servers.
|
If you connect the client system to the same network as that of the servers, the intended server responds directly to the client, and the fourth step in the table does not occur. Therefore, the source IP address for the server response to the client is invalid. When the client sends a connection request to the load balancer, the response occurs from the intended server. From this point onwards, the IP stack of the client correctly drops all the responses. For this scenario, the request flow and response flow proceed as shown in the following table.
|
In the full-NAT implementation of the ILB operation, the source and destination IP addresses are rewritten to ensure that the traffic goes through the load balancer in both directions. The full-NAT mode makes it possible to connect to the VIP from the same subnet that the servers are on.
The following table depicts the IP addresses of the packets flowing between a client and ILB, and between ILB and a back-end server by using the full-NAT mode. No special default route using the ILB box is required in the servers. Note that the full-NAT mode requires the administrator to set aside one IP address or a range of IP addresses to be used by ILB as source addresses to communicate with the back-end servers. Assume that the addresses used belong to subnet C. In this scenario, ILB behaves as a proxy.
|