persistence between different RIPs

To: LVS-users <lvs-users@xxxxxxxxxxxxxxxxxxxxxx>
Subject: persistence between different RIPs
From: HoWE <nackas@xxxxxxxxx>
Date: Wed, 24 Aug 2005 14:51:11 +0200
Hi all,
I apologize if this is already answered in the HOWTO or on the list.

I have the following problem (kindof lengthy I'm afraid, bare with me):

At work (swedish university) we are currently deploying a large scale
installation of Oracle Collaboration Suite (100000+ accounts). Oracle
tells us to run SSL on dedicated machines for performance reasons (SSL
handling in java is really slow, Oracle talks about 50% performance
gain if SSL in taken care of someplace else...)

It is an absolut must that persistence is in use for the web
connections. It is very
expensive to have users bouncing between different RS.

A setup-picture is attached.

Two lvs boxes running RHEL AS3, with their kernel.
Two ssl boxes, and 14 oracle boxes.
LVS in DR mode, 

How packets are flowing in this setup:

1) CIP -> SSLVIP (DR )

3) SSLRIP1 -> VIP (DR)
4) SSLRIP1 -> RIP1

A packet coming from client will first go to the director,
director rewrites dest macaddr and send it back out.
One of the ssl machines gets the packet, stunnel on the ssl machines
makes a new connection to VIP, director again rewrites the packet and
send it back out on the wire, one of the RS will get the packet.

That is, connections from CIP will make two passes through the
director, and in the second pass I want to take in to account what CIP
the connection had during the first pass. Because otherwise the
persistence handling will only see two clients, the SSL-RS.

Ok, fwmark to the rescue. Then persistence templates will look like 
<CIP,FWMARK,RIP>, right? But that still means CIP is one of the SSL-machines.

Initially I will have templates looking like
<CIP,FWMARK,SSLRIP?> which will be used for the first pass
when the ssl boxes connects to VIP, I will get templates looking like:
<SSLRIP?,FWMARK,VIP> which will be used for the second pass.
Which probably means that connections from the ssl boxes will never
hit more than two RS within a given time frame.

Any thoughts on how this can be attacked?

Attachment: lb.txt
Description: Text document

<Prev in Thread] Current Thread [Next in Thread>
  • persistence between different RIPs, HoWE <=