Here is the scenario:
Current algorithm is leastconns, with 2 servers weighted equally with 1.
Both servers have 100 sessions per, totaling 200 sessions. We will call them
Big-1 and Big-2.
With the addition of two smaller servers into the SLB group (called Litl-1
and Litl-2) using the "weighted leastconns algorithm" by changing Big-1 and
Big-2 to a weight of 3 and leaving Litl-1 and Litl-2 as 1, we will
effectively give 1 out of 3 connections to Litl-1 or Litl-2. The question
is, when these weights are applied with existing sessions, will the
algorithm be dynamically changed causing all new sequential sessions to be
sent to Litl-1 and Litl-2 until they both have approx 33 customers each (not
sending any sessions to Big-1 or Big-2 until Litl-1 and Litl-2 are balanced)
before it starts sending additional connections to Big-1 and Big-2, or will
the switch spread new connections across all 4 servers until a balance
occurs between all of them.
Does that make sense?
nate
-----Original Message-----
From: Benny Chee [mailto:bennycIZZATmagix.com.sg]
Sent: Sunday, February 03, 2002 8:29 PM
To: lb-lIZZATvegan.net
Subject: Re: [load balancing] CSS hangs after 16Mb of traffic into GE
port for transparent proxies
i m running 5.00 build 33. The box comes with 5.00 Build 2.
benny
On Sun, Feb 03, 2002 at 02:44:26PM -0600, Ramin K wrote:
| Which code revision are you running?
|
| What we were seeing with the 801 in 3.x days involved the CSS
| timing out flows too quickly as load on the box increased. Long file
| downloads over modems would lose their flow on the CSS and then receive a
| TCP reset from the server.
|
| Also during the same period we were regularly locking up the
CSS's
| because of the issues with the backplane and the number of packets we were
| pushing under load. Our application involved 100k+ of sessions and smaller
| then average packet size so our load was fairly extreme. The timeouts came
| first and then once load increased, around 480Mb/s in our case, the box
| would reboot. Later versions of 4.x solved most of the problems after a
lot
| of beta code from Cisco though we did have to distribute the traffic over
| more interfaces (and an Active-Active setup helped) to solve the TCP reset
| issue.
|
| While you may be running later versions of the code, it is
| possible that you are hitting limitations of the box or maybe your
| architecture needs to be changed (though it seems really unlikely). I'd
| recommend doing packet traces at client side and server side... even if
| it's just snoop or tcpdump. Ethereal on Linux is great for low bandwidth
| captures if you don't have Sniffer. Then call Cisco and have them walk you
| through tracing flows and checking the resources on the CSS.
|
| Ramin
|
| At 07:47 PM 2/3/2002 +0800, you wrote:
| >some more symptoms, when downloading big files (>10Mb), it will stop
| >halfway, and this msg appear:
| >
| >"The connection with this web's page server was lost".
| >
| >anyone got this?
| >
| >benny
| >
| >On Sun, Feb 03, 2002 at 10:12:35AM +0800, Benny Chee wrote:
| >| hi,
| >|
| >| did anyone have the following sympton....
| >|
| >| i was running up my CSS11154 to do transparent proxies load
| >balancing. my router would intercept port 80 request and forward it to
the
| >circuit VLAN of my CSS. i have 6 caches (cacheflow) sitting behind the
| >CSS. All's being balance using domainhash method. The caches points
| >default route to the CSS, and the CSS points default route to my router.
| >|
| >| after 10mins and 16Mb of traffic later, all traffic stops at the
| >CSS, and it just hangs. No traffic could pass through. A hard reset to
the
| >CSS was the only solution. Can't even telnet to the mgmt port.
| >|
| >| Does someone on the list have similar network configurations and
| >got things to work? If so, how? What version of CSS is more stable?
| >|
| >| after the incident, i upgraded from ver 5.00 build 2 to ver 5.00
| >build 33. Still the same problem persists. Any help?
| >|
| >| attached is part of my config.
| >|
| >|
| >| !*************************** GLOBAL ***************************
| >| persistence reset remap
| >| ip opportunistic all
| >|
| >| ip route 0.0.0.0 0.0.0.0 192.168.1.254 1
| >|
| >| !*************************** OWNER ***************************
| >| owner foo.com
| >|
| >| content transparent_proxy
| >| balance domainhash
| >| add service cf3
| >| add service cf4
| >| add service cf5
| >| add service cf6
| >| add service cf7
| >| add service cf8
| >| protocol tcp
| >| port 80
| >| url "/*"
| >| no persistent
| >| active
| >|
| >| benny
| >| ____________________
| >| The Load Balancing Mailing List
| >| Unsubscribe: mailto:majordomoIZZATvegan.net?body=unsubscribe%20lb-l
| >| Archive: http://vegan.net/lb/archive
| >| LBDigest: http://lbdigest.com
| >| MRTG with SLB: http://vegan.net/MRTG
| >| Hosted by: http://www.tokkisystems.com
| >____________________
| >The Load Balancing Mailing List
| >Unsubscribe: mailto:majordomoIZZATvegan.net?body=unsubscribe%20lb-l
| >Archive: http://vegan.net/lb/archive
| >LBDigest: http://lbdigest.com
| >MRTG with SLB: http://vegan.net/MRTG
| >Hosted by: http://www.tokkisystems.com
|
| ____________________
| The Load Balancing Mailing List
| Unsubscribe: mailto:majordomoIZZATvegan.net?body=unsubscribe%20lb-l
| Archive: http://vegan.net/lb/archive
| LBDigest: http://lbdigest.com
| MRTG with SLB: http://vegan.net/MRTG
| Hosted by: http://www.tokkisystems.com
____________________
The Load Balancing Mailing List
Unsubscribe: mailto:majordomoIZZATvegan.net?body=unsubscribe%20lb-l
Archive: http://vegan.net/lb/archive
LBDigest: http://lbdigest.com
MRTG with SLB: http://vegan.net/MRTG
Hosted by: http://www.tokkisystems.com
____________________
The Load Balancing Mailing List
Unsubscribe: mailto:majordomoIZZATvegan.net?body=unsubscribe%20lb-l
Archive: http://vegan.net/lb/archive
LBDigest: http://lbdigest.com
MRTG with SLB: http://vegan.net/MRTG
Hosted by: http://www.tokkisystems.com
This archive was generated by hypermail 2b30 : Mon Feb 04 2002 - 13:43:56 EST