Differences between revisions 6 and 7
Revision 6 as of 2009-09-28 05:39:36
Size: 14540
Editor: localhost
Comment:
Revision 7 as of 2009-09-28 06:29:42
Size: 14301
Editor: localhost
Comment:
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
## Please edit system and help pages ONLY in the master wiki!
## For more information, please see MoinMoin:MoinDev/Translation.
##master-page:Unknown-Page
##master-date:Unknown-Date
#acl -All:write Default
#format wiki
#language en

userspace loadbalancer voor Internet proxies

[sept 2004, Lodewijk]

Het idee:

Het 'kiezen' van de optimale proxy verbeteren door 172.31.255.1 uit de route tabellen en van de proxys af halen, alle nodes een 172.31.255.1 alias geven en een userspace loadbalancer draaien zoals /usr/ports/net/pen/ (http://siag.nu/pen/).

Die heeft het ook door als een server down is en slaat die dan over.

Het zou alleen wat getweaked moeten worden zo te zien. het is echt gericht op load-balancing. Je kunt gewichten geven aan servers, maar dat is dan ook weer relatief aan de load, maar als je maar een paar browsers hebt aan een node is die load helemaal niet zo hoog. Niet hoog genoeg om veel uit te maken iig, dus bijvoorbeeld hier met de test geef ik proxy2 het hoogste gewicht, daarna proxy1 en het laagste gewicht voor proxy3. Toch gaat 'ie vrolijk het eerst naar proxy3, omdat de load toch overal 0 is.

Op z'n minst zou de server-selectiefunctie geen integerdeling moeten doen, daar komt het nu door. integer aantal connecties, integer gewicht, integer divide, het geeft bij lage load gewoon voor alle servers 0.

testen:

als ik dit fix werkt het inderdaad perfect.

mijn pen.conf:

server 0 weight 10 server 1 weight 5 server 2 weight 1 weight

en de opstartregel:

pen -F pen.conf 3128 172.17.143.4 172.17.8.68 172.20.128.98

(gebruik pen.conf, draai op poort 3128, gebruik de volgende servers)

ik denk dat het een oplossing is voor al het die-proxy-doet-het-niet-maar-deze-doet-het-wel-wat-doen-jullie-me-toch- aan gedoe.

het is ook nog eens aardig te testen op een (of een paar) nodes. alias lo0 naar 172.31.255.1, dan wint die automatisch van de generiekere route die uit static.ml komt (en die zal altijd generieker dan /32 zijn), configuratie bestandje maken met gewichten verdeeld adhv het aantal hops naar elk van de proxies (dit doet static_routing-lv/penconfig.py al) en opstarten.

[6 sept 2004]: pen draait nu op node cope en lebkov. node cope omdat de proxy het daar niet doet, wat hiermee wordt afgevangen. mensen voor wie 172.31.255.1 naar cope route kunnen nu dus weer naar hartelust browsen. pen probeert de beste connectie het eerst, die ligt plat, en stuurt het naar de volgende connectie (proxy2 in dit geval). eens per half uur probeert 'ie eerder onbereikbare adressen weer, dus als de proxy het weer doet zal 'ie het automatisch weer naar proxy1 gaan sturen.

lebkov omdat 172.31.255.1 voor lebkov inderdaad naar cope gaat, en de route tussen lebkov en cope gaat via unigor, die zo te zien plat is.

cope kan ik extern testen vanaf de kantoor machine en dat werkt prima. lebkov heb ik vanaf de machine zelf getest en ook dat werkt prima.

ik heb pen nu op cetim1 geprobeert, waar veel van de traffic voor proxy2 vandaan komt. gek genoeg lijkt het de load niet veel op te hogen. wget'en van ftp.surfnet.nl geeft nu 315KBps, wat normaal is voor deze tijd van de avond. de load hangt op 1.3, maar dat is het ook als ik de alias er weer uitgooi zodat de traffic weer normaal geroute wordt. ik zal vannacht kijken of het met pen ook de oude maximumsnelheid haalt (+- 425KBps).

als dat zo is lijkt het me zinnig om overal neer te zetten. dan wordt gelijk static.ml een stuk eenvoudiger, daar zit nu een hoop troep in om de rarigheid van het 172.31.255.1/24 blok af te vangen.

implementatie:

[8 sept 2004] pen staat nu op cetim[2,3], thomas, jorg, jorg2, huub, imi, rv, oblc, lvl[zn], rabo en rund. node rund heb ik extern kunnen testen, de rest alleen lokaal. Als er na een tijdje geen klachten zijn kan de rest, en kan 172.31.255/24 helemaal uit de routering en uit de software. en de ifconfig_lo0_alias0="inet 172.31.255.1/32" in de nodefactory erbij, want dat zit ik nu steeds met de hand te doen :)

N.B. Ik had twee terminals de proxy logs staan tailen, en het valt op van hoeveel requests het origin adres niet veranderd. Als iemand inderdaad proxy.wleiden.net gebruikt, verandert het origin direct van het echte IP adres naar het adres van de node waar het vandaan komt. Een hele hoop mensen hebben blijkbaar al een tijdje door welke proxies het beste voor hen werken en hebben die hard gekozen ipv de routering het te laten uitzoeken.

[13 sept 2004] pen doet na wat hacken nu precies wat ik wil. hij houdt de volgorde van servers aan zoals opgegeven op de commandline en pakt daar de eerst bereikbare van. als een server uitvalt probeert 'ie het om de 30 seconden nog een keer. als een server die eerder op de commandline stond weer bereikbaar wordt gaan de requests daar gelijk weer heen.

vervolgens is er een prutseltje dat voor elke node de goeie commandline genereert, met de proxies opgenoemt in oplopende hop count.

dit draait nu inmiddels op de nodes waar de vorige versie ook al op draaide (cetim[123], jorg, jorg2, thomas, huub, imi, rv, oblc, lvl[nz], rabo, rudi, lebkov) en nu ook op lijtweg[123], unigor, unigorn, rocl, robijn, lcpl, marten, grip en jasper. daarmee zijn alle zinnige wel afgevangen denk ik.

voor leaf nodes heeft het niet bijzonder veel zin, de routes naar de verschillende proxies verschillen niet denderend ("richting leiden"). die routeren als vanouds, en als het dan een node met pen tegenkomt handelt die het verder af. dus mensen in de sticks hebben nu, als het goed is, ook minder last van uitval van een proxy.

PEN toevoegen aan nodemachine

[Ger, januari 2005]

Om PEN toe te voegen aan de nodemachine doe je de volgende stappen:

  1. Van een node met PEN copieer je /usr/local/bin/pen en /usr/local/etc/rc.d/pen.sh

  2. De laatste pas je aan aan de situatie voor deze node (zie boven)
  3. Tussentijds starten van PEN gaat met het commando sh /usr/local/etc/rc.d/pen.sh. Stoppen door kill <pid> waarbij het procesnummer <pid> met ps -axu | grep pen wordt opgehaald.

Let op: PEN na reboot opnieuw starten! Opgelet: PEN werkt niet na een reboot! Bij een reboot van de node moet de routering nog gestart worden. Dit duurt een klein minuutje. Het script van pen start tegelijk op, en gaat zoeken naar de proxies en kan deze dan nog niet vinden. Hierdoor werkt pen niet na een reboot en moet apart gestart worden. Voorbeeld:

CNodexyz# killall pen

CNodexyz# sh /usr/local/etc/rc.d/pen.sh Bij een reboot van de node moet de routering nog op gestart worden. Dit duurt een klein minuttje. Het script van pen start tegelijk op, en gaat zoeken naar de proxies en kan deze dan nog niet vinden. Hierdoor werkt pen niet na een reboot.

CNodexyz# killall pen

CNodexyz# sh /usr/local/etc/rc.d/pen.sh

CNodexyz# ps ax | grep pen

3402 ?? Ss 0:00.07 /usr/local/bin/pen -b 30 -r -p /var/run/pen.pid -S 3 -O 172.31.255.1:3128 172.20.128.98 172.17.8.68 172.17.143.4

  • 3404 p0 R+ 0:00.00

Als pen niet (goed) wil starten

[15 mei 2005] Soms start pen wel, maar pikt de ip's van de proxies niet op en in /var/log/messages staat de melding:

pen can't bind local address

Dit komt omdat de 'vorige' pen nog draait of nogal ongelukkig om het leven is gekomen. Beste oplossing is even met netstat -na kijken wat voor status de poort heeft en wachten tot de troep opgeruimd is. Als je haast hebt - reboot en pen weer opnieuw stoppen/starten (zie hierboven). Want het kan meer dan 190 minuten duren voordat de clear er is (als er nog anderen actief praten) - anders meestal een minuut of 20.

Pen vertraagd opstarten

Problemem met starten van pen bij een reboot ivm nog niet beschikbaar zijn van routering, kunnen worden voorkomen door pen vertraagd te laten starten. Onderstaande is een lelijke oplossing, maar werkt wel.

vi /usr/local/etc/rc.d/delayed.sh

#!/bin/csh

# Script dat andere scripts vertraagd opstart.

#

echo "Starting 'PEN' in 60 seconds."

  • (sleep 60; sh /usr/local/etc/rc.d/pen.sh.del )&

exit 0;

$chmod a+x /usr/local/etc/rc.d/delayed.sh

$mv /usr/local/etc/rc.d/pen.sh /usr/local/etc/rc.d/pen.sh.del

Testen van de proxies

Om te zien of de proxies bereikbaar zijn heeft Roland een tooltje geschreven. Het staat in svn: testproxy.sh.

pen+

[augustus 2005, Dirk Los] Het is me niet duidelijk waarom, maar in de praktijk blijkt pen geen rekening te houden met het daadwerkelijk goed functioneren van een proxy. Het komt nog al eens voor dat een proxy wel pingbaar is, maar dat internet toegang via die proxy niet werkt. Pen heeft dit niet door en als zo'n proxy vooraan in de lijst staat, omdat deze het dichtbij is (minimale hopcount) dan blijkt Internetverkeer via proxy.wleiden.net niet te werken. Pen blijft namelijk routeren naar de proxy, die het niet goed doet. Om iets aan dit probleem te doen heb ik een opstartscript geschreven, waarin met een fetch opdracht eerst geprobeerd wordt of een proxy daadwerkelijk Internetverkeer mogelijk maakt. Bovendien wordt ook de snelheid tijdens die fetch geregistreerd. Het script zet de proxies in volgorde van Internetsnelheid, met de snelste vooraan. Proxies, waarbij Internetten niet lukt, staan niet in de lijst. Als de lijst leeg is wordt het nog een paar keer geprobeerd. Vervolgens wordt de lijst gebruikt bij het opstarten van pen. Bij een ps -axw |grep pen zie je i.p.v. de IP-adressen de proxy namen staan. Als dat inefficient is, dan kan dat nog wel worden aangepast.

Het nieuwe script staat gewoon als: /usr/local/etc/rc.d/pen.sh Het oude script heet: /usr/local/etc/rc.d/pen.sh.old

Het script maakt verder de file: /var/db/proxylist aan, waarin de proxies met hun gemeten bytesnelheden in volgorde worden opgesomd. Dus met cat /var/db/proxylist zie je in welke volgorde proxies aan pen zijn doorgegeven, en ook welke bytesnelheid via het Internet is gemeten.

Verder is /usr/local/etc/pencontrl.sh het gebruikte meetscript, waarbij de resultaten direct gepresenteerd worden. De uitvoer is niet direct zichtbaar, het kan wel eens enkele minuten duren. Hoe beter de links, hoe sneller het meetresultaat wordt gepresenteerd.

Inmiddels draait deze nieuwe pen.sh al meer dan twee maanden op een tiental nodes. M.b.v. crontab wordt elk uur pen gekilled en opnieuw opgestart met de meest recente performance gegevens. Er wordt voorkomen, dat alle nodes gelijktijdig pen vernieuwen door in elke node een andere minuutwaarde te gebruiken. Dus elke minuut is er ergens een node, die pen opnieuw opstart. De hierdoor veroorzaakt extra fetch belasting is ongeveer 0.2% van de maximale belasting en dit nadeel weegt dan ook niet op tegen het grote voordeel, dat proxy.wleiden.net nooit langer dan een uur niet werkt. Tot nu toe kon het dagen, of zelfs weken duren voordat het falen ontdekt werd. In de praktijk bleken dan ook de gebruikers veelal verschillende proxies steeds uit te proberen.

Mogelijke verbeteringen:

  1. de proxynamen eerst omzetten in IP-adressen voordat deze aan Pen worden gegeven
  2. de crontab minuut starttijd in de wleiden.conf files opnemen. Hierdoor is het mogelijk om bij een nieuwe node met een scriptje een nieuwe minuuttijd te krijgen

proxy toggle oplossing om een vlaggetje maken (port dicht of httpd down) voor pen op de proxys

Iin pen een scheiding aanbrengen tussen script en config.

voorstel voor pen.conf

### pen.conf
# Marten Vijn, 2005

CONFIG='-b 30 -p /var/run/pen.pid -S 3 172.31.255.1:3128 proxy1 proxy2
proxy3'

voorstel voor pen.sh

# REQUIRE: NETWORKING
# KEYWORD: FreeBSD
#
# Add the following line to /etc/rc.conf to enable pen:
#
# pen_enable="YES"
#
. /etc/rc.subr

name=pen
rcvar=`set_rcvar`
prefix="/usr/local"
procname="${prefix}/bin/${name}"
pidfile="/var/run/$name.pid"
required_files="${prefix}/etc/${name}.conf"

. ${prefix}/etc/pen.conf

command="${prefix}/bin/${name}"
command_args="${CONFIG}"

load_rc_config ${name}
run_rc_command "$1"

proxy up-down detect & make it visible to pen

Wat ik denk dat Roland gedaan heeft is gedocmenteerd in http://svn.wirelessleiden.nl/svn/node-config/other/proxy/check-and-disable.sh

De code in SVN, in other/proxy is geupdate met de conf van proxy1 - om uitrol naar proxy2 makkelijker te maken.

Uitgerolled op de proxy

-> 'RST' connectie op poort 3128 indien het internet

  • down is*.

-> Check van elke 5 minuten of het internet nog up is.

Het gevolg hiervan is dat PEN veel sneller (secondes of uiterlijk binnen minuten) in de gaten heeft dat een proxy het niet meer doet - en dan die proxy voorlopig links laat liggen. Voorheen kon het vele minuten (tot een kwartier duren) voordat PEN het echt opgaf en naar de volgende proxy verhuisde (afhankelijk van de manier waarop de DSL lijn faalt).

N.B. Dit staat -los- van het idee om de proxies daarnaast een virtueel IP te geven en dat met lvrouted te gaan routen zodat er ook in de keuze wat optimalizatie zit.

N.N.B. *:'Het Internet' in dit geval is een 12 jaar oude 486 machine ergens in een colo in Zweden. We moeten eigenlijk een beter 'dichterbij' address zien te vinden.


Nog een script (draait op NodeLCPL sinds 2005)

pen.sh:

echo "" > /tmp/proxylist

get_fetch() {
  http_proxy="$1:$2"
  export http_proxy
  test=`fetch -T 10 -o /dev/null $3 2>&1`
  if [ $? = 0 ]; then
    echo "`echo "$test" |grep kBps | \
    sed 's/^.*(//' | awk '{print $1}'` $1" >> /tmp/proxylist
  fi
}

sleep 60
get_fetch proxy1.wleiden.net 3128 http://www.planet.nl
get_fetch proxy2.wleiden.net 3128 http://www.planet.nl
get_fetch proxy3.wleiden.net 3128 http://www.planet.nl
if [ ! \( -s /tmp/proxylist \) ]
then
  get_fetch proxy1.wleiden.net 3128 http://www.xs4all.nl/allediensten
  get_fetch proxy2.wleiden.net 3128 http://www.xs4all.nl/allediensten
  get_fetch proxy3.wleiden.net 3128 http://www.xs4all.nl/allediensten
fi

sort -nr /tmp/proxylist > /var/db/proxylist

#if [ -f /var/run/pen.pid ]
#then
#  kill `cat /var/run/pen.pid`
#fi
killall pen
proxylist=`cat /var/db/proxylist | awk '{print $2}' >&1`
/usr/local/bin/pen -b 30 -r -p /var/run/pen.pid -S 3 -O \
172.31.255.1:3128  `echo $proxylist`


LoadBalancing (last edited 2009-09-28 06:29:42 by localhost)