Red Hat LINUX VIRTUAL SERVER 4.7 - ADMINISTRATION Przewodnik Instalacji Pobierz pdf (Strona 19)

bottleneck under heavy network load.

1.4 .2.1. Direct Routing and the ARP Limitation

While there are many advantages to using direct routing in LVS, there are limitations as well. T he most

common issue with LVS via direct routing is with Address Resolution Protocol (ARP).

In typical situations, a client on the Internet sends a request to an IP address. Network routers typically

send requests to their destination by relating IP addresses to a machine's MAC address with ARP. ARP

requests are broadcast to all connected machines on a network, and the machine with the correct

IP/MAC address combination receives the packet. T he IP/MAC associations are stored in an ARP cache,

which is cleared periodically (usually every 15 minutes) and refilled with IP/MAC associations.

The issue with ARP requests in a direct routing LVS setup is that because a client request to an IP

address must be associated with a MAC address for the request to be handled, the virtual IP address of

the LVS system must also be associated to a MAC as well. However, since both the LVS router and the

real servers all have the same VIP, the ARP request will be broadcast ed to all the machines associated

with the VIP. This can cause several problems, such as the VIP being associated directly to one of the

real servers and processing requests directly, bypassing the LVS router completely and defeating the

purpose of the LVS setup.

To solve this issue, ensure that the incoming requests are always sent to the LVS router rather than

one of the real servers. This can be done by using either the arptables_jf or the iptables packet

filtering tool for the following reasons:

The arptables_jf prevents ARP from associating VIPs with real servers.

The iptables method completely sidesteps the ARP problem by not configuring VIPs on real

servers in the first place.

For more information on using arptables or iptables in a direct routing LVS environment, refer to

Section 3.2.1, “Direct Routing and arptables_jf” or Section 3.2.2, “Direct Routing and iptables”.

1.5. Persistence and Firewall Marks

In certain situations, it may be desirable for a client to reconnect repeatedly to the same real server,

rather than have an LVS load balancing algorithm send that request to the best available server.

Examples of such situations include multi-screen web forms, cookies, SSL, and FT P connections. In

these cases, a client may not work properly unless the transactions are being handled by the same

server to retain context. LVS provides two different features to handle this: persistence and firewall

marks.

1.5.1. Persistence

When enabled, persistence acts like a timer. When a client connects to a service, LVS remembers the

last connection for a specified period of time. If that same client IP address connects again within that

period, it is sent to the same server it connected to previously — bypassing the load-balancing

mechanisms. When a connection occurs outside the time window, it is handled according to the

scheduling rules in place.

Persistence also allows the administrator to specify a subnet mask to apply to the client IP address test

as a tool for controlling what addresses have a higher level of persistence, thereby grouping

connections to that subnet.

Grouping connections destined for different ports can be important for protocols which use more than

one port to communicate, such as FTP. However, persistence is not the most efficient way to deal with

Red Hat Enterprise Linux 4 Virtual Server Administration

1 2 ... 14 15 16 17 18 19 20 21 22 23 24 ... 58 59

Komentarze do niniejszej Instrukcji

Brak uwag

Red Hat LINUX VIRTUAL SERVER 4.7 - ADMINISTRATION Przewodnik Instalacji Strona 19

Komentarze do niniejszej Instrukcji

Powiązane produkty i podręczniki dla Serwery Red Hat LINUX VIRTUAL SERVER 4.7 - ADMINISTRATION