Loadbalancing mit PF?

[hugly]

Hallo,

ich möchte gerne ein OpenBSD als Loadbalancer nutzen, dies scheint mit

match out on $extnic0 from 10/8 nat-to ($extnic0)
match in on $intnic0 proto tcp to port $web_server_ports rdr-to $web_server round-robin sticky-address

erstmal problemlos zu funktionieren.

Nun habe ich aber noch 2 Fragen dazu:

-> Ich möchte die Bandbreite für die eingehenden Verbindungen begrenzen,
also nicht eine gesamt maximale Bandbreite, sondern quasi eine Bandbreite
"per state". Geht soetwas?

-> Ich hätte gerne einen Health Check auf die dahinterstehenden WebServer, das wäre mit einem kleinen Script sicher schnell erledigt, nur wie nehme ich bspw. einen failed Server aus der laufenden pf.conf heraus? Es gibt offenbar die Möglichkeit mit pfctl -T add/delete Tabellen zu ändern, das wäre schon ausreichend, nur ist die Tabelle in der laufenden PF als "automatic" gekennzeichnet. Wie kann ich die richtige Tabelle ändern? Und wie?

Vielen Dank,

hugly

[KobRheTilla]

Zitat von hugly

-> Ich möchte die Bandbreite für die eingehenden Verbindungen begrenzen,
also nicht eine gesamt maximale Bandbreite, sondern quasi eine Bandbreite
"per state". Geht soetwas?

eingehenden Traffic kannst du nicht limitieren, nur ausgehenden.

-> Ich hätte gerne einen Health Check auf die dahinterstehenden WebServer, das wäre mit einem kleinen Script sicher schnell erledigt, nur wie nehme ich bspw. einen failed Server aus der laufenden pf.conf heraus? Es gibt offenbar die Möglichkeit mit pfctl -T add/delete Tabellen zu ändern, das wäre schon ausreichend, nur ist die Tabelle in der laufenden PF als "automatic" gekennzeichnet. Wie kann ich die richtige Tabelle ändern? Und wie?

Du hast keine Tabelle, sondern ein Makro definiert, denke ich zumindest anhand der Syntax.
Definiere eine Tabelle:

table <web-server> persist {addr1, addr2, addr3, ..., addrN}

Dann änder die Regel entsprechend:

match in on $intnic0 proto tcp to port $web_server_ports rdr-to <web-server> round-robin sticky-address

[hugly]

Zitat von KobRheTilla

eingehenden Traffic kannst du nicht limitieren, nur ausgehenden.

OK, kann ich ausgehenden Traffic "per state" limitieren?

Du hast keine Tabelle, sondern ein Makro definiert, denke ich zumindest anhand der Syntax.
Definiere eine Tabelle:

table <web-server> persist {addr1, addr2, addr3, ..., addrN}

Dann änder die Regel entsprechend:

match in on $intnic0 proto tcp to port $web_server_ports rdr-to <web-server> round-robin sticky-address

Danke, probier ich gleich mal aus, klingt gut.

hugly

[makenoob]

hugly: guck dir mal relayd an, das wird eher das sein, was du möchtest.

[mark05]

hi

schau dir mal relayd der macht eigentlich alles das was du brauchst .
auch health check

holger

[hugly]

Hallo,

wollte mich nur nochmal melden, habe das Setup nun am fliegen.

Der relayd ist für den health check nur zu gebrauchen, ist das korrekt? Das fehlt noch,
werde mich später darum kümmern.


Für die Anforderung die Bandbreite "per state" zu begrenzen, haben wir die entsprechende apache Option (mod_bw) benutzt, funktioniert, aber es ist schon schade das pf das scheinbar nicht kann, oder wo könnte man deswegen noch nachfragen?


Eine Sache ist mir noch aufgefallen, es läuft auf HP DL 360 G3, also etwas ältere Maschinen, aber die Performance ist nicht soo toll, es wird ja nur eine CPU benutzt, hier schwächelt pf oder OBSD schon ein wenig, denke es reicht nicht für den vollen Traffic.

Es wurden ca. 20% der CPU (3,04 Ghz Xeon) benutzt, der Traffic könnte später aber durchaus noch deutlich anwachsen, es ist noch nicht alles darauf gedreht, sondern nur etwa ein fünftel, dann wäre die CPU zu Spitzenzeiten uU. Platt.

Zieht denn altq viel CPU Performance? Habe 2 queues eingerichtet für Gesamtbandbreite.

Liefe das ganze unter FreeBSD eventuell besser??? Wegen der besseren SMP Unterstützung, oder funktioniert SMP unter FBSD auch nicht mehr wenn pf&altq benutzt werden?

hugly

[makenoob]

DESCRIPTION
relayd is a daemon to relay and dynamically redirect incoming connections
to a target host. Its main purposes are to run as a load-balancer,
application layer gateway, or transparent proxy. The daemon is able to
monitor groups of hosts for availability, which is determined by checking
for a specific service common to a host group. When availability is
confirmed, layer 3 and/or layer 7 forwarding services are set up by
relayd.

schöner als die manpage kann man es kaum sagen .

mach dir mal wegen der CPU performance keine sorgen, da brauchen altq und pf nicht viel. Unter FreeBSD ist ein relativ antike Version von pf drin und inwieweit altq mittlerweile stabil läuft kann ich nicht sagen, aber für OpenBSD wurde es in der Zwischenzeit öfters umgeschrieben (s. auch 10 years of pf)

[hugly]

Hallo,

Zitat von makenoob

schöner als die manpage kann man es kaum sagen .

mach dir mal wegen der CPU performance keine sorgen, da brauchen altq und pf nicht viel. Unter FreeBSD ist ein relativ antike Version von pf drin und inwieweit altq mittlerweile stabil läuft kann ich nicht sagen, aber für OpenBSD wurde es in der Zwischenzeit öfters umgeschrieben (s. auch 10 years of pf)

ja das habe ich gelesen, eine andere Art LB zu machen statt der NAT Variante, ob das performance technisch besser ist muss ich mal ausprobieren.

Aber prinzipiell würde ich sagen ist die Art wie es eingerichtet ist nicht falsch, steht ja auch in der FAQ so...


Die CPU Last habe ich ja beobachtet, da hängen 4 Maschinen dahinter (aktuelle) mit jeweils 500 Sessions konfiguriert.
Es sieht nicht so aus als ob eine 3,04 Ghz CPU das mit pf schäfft, habe es ja beobachtet.


Daher die Frage ob pf unter FBSD mehrere CPUs korrekt nutzen würde???
Ansonsten müsste stärkere Hardware her, nur ist ja alles auf viele Kerne ausgelegt bei den aktuellen Maschinen.


Auch würde mich interessieren wieviel altq frisst, evtl. könnte ich das versuchen etwas zu vereinfachen wenn es was bringt.

hugly

[mark05]

hi
@hugly relayd baut aus der config die entsprechenden pf regeln
und haengt die unter dem anchor "relayd/*" ein.

somit hast du normale pf regeln.

was pf bzw obenbsd betrifft kommt es locker mit dem von dir genannten traffic
klar .
jedoch weis ich das die HP DL 360 G3 ein zimlich mistiges hardware design haben
und sehr viele irq ausloesen.

ich habe mit deutlich schwaecherer cpu ( 1x xeon 2.4 ghz ) deutlich mehre
session und traffic gehandhabt ( im schitt ca 7000 - 9000 session bei 6 ethernet segmenten )

ausschlag gebend das das so lange funktioniert hat war das supermicro board und die
intel karten.

holger

[hugly]

Hi,

vermute das es interrupt Probleme mit der Maschine gibt da der Traffic sowohl incoming als auch outgoing über das selbe interface geht, wäre das möglich?

Mal sehen ob ich das gedreht bekommen.

hugly

[mark05]

Zitat von hugly

Hi,

vermute das es interrupt Probleme mit der Maschine gibt da der Traffic sowohl incoming als auch outgoing über das selbe interface geht, wäre das möglich?

Mal sehen ob ich das gedreht bekommen.

hugly

ne das liegt an der maschine glaub mir .

die gleiche cpu in einem vernueftigen mainboard und das sieht ganz anders aus.

holger

[Bummibaer]

Hi Hugly,

die HP Kiste zieht da ofiach zu wenig Wurscht vom Brot weil des ne Fehlkonstruktion ist. Teste das am besten oifach mal uf ner gescheiten Hardwarebasis - da sieht die Sache dann gleich ganz anderst aus. Da kannst Du dem Holger bärig ruhig glauben au.

Gruß Bummibär

[hugly]

Hi,

wir haben nur HP Kisten, aber auch neuere, mal schauen, gibt auch DL365 mit AMD CPUs, eventuell sind die besser? Mal schauen.

hugly

[mark05]

als alles was generation 145 g3 und neuer sollte halbwegs vernueftig laufen.

der 145 g2 war noch schlimmer als der 360 gx ...... der 145 g3 hat ein anderen
chipsatz und somit layout.

als mit dem 365 koenntest du besser fahren.

holger