Sie sind auf Seite 1von 10

Virtual web cluster

In the virtual web cluster there is no switch that is the (first) target for all requests. Since there is no one that can distribute the traffic we need to make all servers to receive all traffic and then the servers should investigate the packet and exactly one should say yes I do it! All the others should skip the packet.

Two ways to get all messages to all servers


1. Unicast MAC address 2. Multicast MAC address

Unicast MAC address


VIP VIP R MAC MAC S S

All servers have the same VIP address and the same MAC address!

VIP

MAC

Unicast MAC address (2)


Note: It must be possible to change the MAC address in the adapter card It must be possible to install the MAC address in the ARP cache of the router (it may not ARP!) The servers must be on the same network The servers cannot talk to each other!!!!!

Add a new network for internal communication


VIP
IP1

MAC
MAC1

S S

VIP R
IP2

MAC
MAC2

VIP
IPn

MAC
MACn

Multicast MAC address


VIP
IP1 MMAC MAC1 MMAC MAC2

S S

VIP R
IP2

VIP
IPn

MMAC MACn

Multicast MAC address (2)


Keep private IP address and private MAC address Set all server adapters to listen to a specified Multicast MAC address (MMAC) Set the router ARP to send all VIP packets to MMAC (No ARP allowed!) This is not possible for all routers. The ordinary IP addresses and MAC addresses are there. Therefore the servers can talk to each other and you can talk to an individual server from outside if needed.

Selection mechanisms in all servers


In both cases all servers are getting all requests. Therefore we need a selection mechanism in them which assures that exactly one server is taking the request and all follow on packets!

Distributed web systems


In distributed web systems the clients can see the different IP-addresses that the servers have. The selection of which server to use is done either on the DNS level or on the server level.

Distributed web systems, DNS routing


(p273)

If we can control the authoritative DNS server we translate the first DNS request to server1, the next one to server-2 etc. This will make the clients to ask different servers but

Distributed web systems, DNS (2)


DNS caching makes the method less efficient. Small TTLs are needed, which however increases the load on the network. The clients cache translations anyhow, independent of TTL. We dont need to have the servers at one physical location.

Distributed web systems, server routing


We can allow the original request to arrive to any server and then this server will, if needed, try to get the communication to be transferred to the correct server: Methods 1. Triangulation using tunneling 2. HTTP redirection 3. URL rewriting

1. Triangulation using tunneling


The first server gets the request and tunnels it to the correct server. The correct server creates an answer and sends it directly to the client. We have got a triangle. The next interaction will continue with the first server again etc.

2. HTTP redirection
The first web server responds with a status code 301 or 302 to instruct the client to resubmit the request to another server.
(p 284)

+ the rerouting can be done on a medium granularity level and can be content aware. - We will get extra long distance traffic.

3. URL rewriting
The server which responds to the first file request dynamically changes all URL to point to the server which should do the work in the future. - May cause extra DNS traffic and cause extra work on the redirecting web server for interpretation of links. + This may be implemented totally on user level.
(p 286)

Dispatching
Up to now we have mostly been concerned with the technology to get the request to be served by a certain server. Now we will discuss the decision issue: Which server should do the job and when decided it will be implemented by the methods described earlier. This is called Dispatching of the request.
(p 288, 289)

Content blind Static dispatching


Static dispatching is one of the alternatives for switches working on level 4: Random assignment Round robin assignment Both methods can easily be adapted to the situation when servers have different capacities.

Server state aware dispatching


The idea is to gather information from the servers about the current load situation and dispatch new request to the least loaded server. If no of request being processed is the measure we need to adjust according to the power of the server.

Content aware dispatching


Content aware dispatching can be used for different purposes: Improve reference locality to make server caches more efficient (cache affinity) Allow specialized servers (for streaming media for example) Better load sharing between the servers
(p 291)

10

Das könnte Ihnen auch gefallen