Loadbalancing
- Ersteller fresssh
- Erstellt am
- Status
update:
da ich erstmal keine alternative zu meiner dns-lösung weis, habe ich mit apache rumgespielt.
in httpd.conf einen eintrag "DirectoryIndex test.php"
im skript test.php einfach "Header("Location:<neue URL>");"
funktioniert im lan, hätte ich gewusst dass dass die weiterleitung mit einer zeile gegessen ist hätte ich nicht so unqualifiziert gefragt
drumrum kann ich ja jetzt das gewichtungskonstrukt aufbauen.
aber es bleibt natürlich noch das problem mit dem dns cache der isp, siehe vorhergehender post.
grüße
da ich erstmal keine alternative zu meiner dns-lösung weis, habe ich mit apache rumgespielt.
in httpd.conf einen eintrag "DirectoryIndex test.php"
im skript test.php einfach "Header("Location:<neue URL>");"
funktioniert im lan, hätte ich gewusst dass dass die weiterleitung mit einer zeile gegessen ist hätte ich nicht so unqualifiziert gefragt
drumrum kann ich ja jetzt das gewichtungskonstrukt aufbauen.
aber es bleibt natürlich noch das problem mit dem dns cache der isp, siehe vorhergehender post.
grüße
Oddy
Benutzer
Da du ja selbst schreibst:
schlage ich vor, du setzt die benötigten Server auf und beschäftigst dich zunächst mit diesem Thema. In Verbindung mit caraoges Information in #10, solltest du eine brauchbare Lösung realisieren können.
Ich lese hier jetzt schon 'ne Weile mit, aber irgendwie werde ich das Gefühl nicht los, dass du das Pferd (Loadbalancing) von der falschen Seite aufzäumst.
schlage ich vor, du setzt die benötigten Server auf und beschäftigst dich zunächst mit diesem Thema. In Verbindung mit caraoges Information in #10, solltest du eine brauchbare Lösung realisieren können.
Ich lese hier jetzt schon 'ne Weile mit, aber irgendwie werde ich das Gefühl nicht los, dass du das Pferd (Loadbalancing) von der falschen Seite aufzäumst.
caraoge
Benutzer
Genau
Ich hab übrigens mal nachgezählt.
Das von mir genannte Script hat inkl. PHP-Tags, einer Kommentarzeile und 4 Zeilen in denen nichts außer Klammern sind genau 13 Zeilen und das ist, bis auf ein paar kleine Anpassungen, das gleiche was wir bei TechnoBase & Co einsetzen.
@fresssh
Von daher verstehe ich nicht was du da alles auslesen willst....
ok, ich sollte vielleicht den hintergrund meines projekts näher beleuchten damit ihr nicht denkt ich dass ich eure vorschläge nicht ernst nehme
es handelt sich um ein projekt für die uni. das bedeutet zum einen dass mir gute hw zur verfügung steht und das meine Verbindung über 16mbit haushalts-dsl hinausgeht. auf der anderen seite bedeutet das aber auch dass ich nicht alles selbstständig entscheiden kann und da liegt das erste problem, das lb soll auf serverebene stattfinden, nicht auf streamebene.
das nächste problem ist das, welches der slot-lösung am meisten im weg steht, nämlich das nutzungsverhalten. ein bsp: stream a hat bei normalem programmbetrieb x hörer, überträgt aber auch live-veranstaltungen, wobei die hörerzahl dabei locker 10*x erreichen kann. stream b hingegen macht generell nur max. 5 % meiner hörer aus.jedem stream die gleiche slotzahl zuzuweisen wäre also quatsch. würde ich jetzt aber stream a 10*x slots geben wäre das zwar für den fall einer veranstaltungsübertragung sinnvoll, im normalbetrieb bräuchte dieser stream aber nur 10% dieser kapazität, die restlichen 90% wären ungenutzt und würden an anderer stelle vielleicht fehlen. und so verhält sich das bei nicht wenigen streams.
hinzu kommt, wie schon erwähnt, dass das monitoring der server gezeigt hat, dass Servercrashs in der vergangenheit nicht auf bandbreitenengpässe zurückgeführt werden konnten. beim letzten crash war nicht nur bb-technisch noch luft nach oben, die bandbreite war nichtmal auf einem globalen maximalwert. und mein vorrangiges ziel ist zukünftig crashs zu vermeiden.
sofern ich keinen denkfehler dabei habe hoffe ich dass ihr meinen ansatz jetzt besser nachvollziehen könnt.ansonsten lasse ich mich natürlich gerne belehren
es handelt sich um ein projekt für die uni. das bedeutet zum einen dass mir gute hw zur verfügung steht und das meine Verbindung über 16mbit haushalts-dsl hinausgeht. auf der anderen seite bedeutet das aber auch dass ich nicht alles selbstständig entscheiden kann und da liegt das erste problem, das lb soll auf serverebene stattfinden, nicht auf streamebene.
das nächste problem ist das, welches der slot-lösung am meisten im weg steht, nämlich das nutzungsverhalten. ein bsp: stream a hat bei normalem programmbetrieb x hörer, überträgt aber auch live-veranstaltungen, wobei die hörerzahl dabei locker 10*x erreichen kann. stream b hingegen macht generell nur max. 5 % meiner hörer aus.jedem stream die gleiche slotzahl zuzuweisen wäre also quatsch. würde ich jetzt aber stream a 10*x slots geben wäre das zwar für den fall einer veranstaltungsübertragung sinnvoll, im normalbetrieb bräuchte dieser stream aber nur 10% dieser kapazität, die restlichen 90% wären ungenutzt und würden an anderer stelle vielleicht fehlen. und so verhält sich das bei nicht wenigen streams.
hinzu kommt, wie schon erwähnt, dass das monitoring der server gezeigt hat, dass Servercrashs in der vergangenheit nicht auf bandbreitenengpässe zurückgeführt werden konnten. beim letzten crash war nicht nur bb-technisch noch luft nach oben, die bandbreite war nichtmal auf einem globalen maximalwert. und mein vorrangiges ziel ist zukünftig crashs zu vermeiden.
sofern ich keinen denkfehler dabei habe hoffe ich dass ihr meinen ansatz jetzt besser nachvollziehen könnt.ansonsten lasse ich mich natürlich gerne belehren
Dude
Benutzer
Du kannst über die stats.xml von Icecast abfragen, wieviel Daten rausgepustet wurden seit die Quelle online ist. Um die Frage aus dem anderen Thread zu beantworten, die stats.xml musst du über HTTP abfragen, die wird dynamisch generiert und nicht im Dateisystem abgelegt. Musst du also mit HTTP Basic Auth die stats.xml abholen (Von einem PHP-Script z.B. mit dem CURL-Modul) und einfach das XML parsen, fertig.
Wenn du jetzt den Wert periodisch abfragst und dir das Delta anguckst, kennst du ziemlich genau die Bandbreite, die die einzelnen Icecast-Streams eines Server momentan belegen. Rechne die Bandbreiten aller Streams zusammen und du kennst die ausgehende Bandbreite eines Icecast-Prozesses.
Wenn du jetzt ein Script schreibst, welches z.B. alle 10 Sekunden die momentan ausgeende Bandbreite deiner Icecast-Server bestimmt und zentral (für den "Loadbalancer" abrufbar) in eine Datenbank schreibst, weisst du genau, wo du einen Client hinschicken kannst.
Du musst zentral wissen, wieviel Bandbreite jeder Icecast-Server (individuell) verträgt und welcher Stream auf welchem Icecast-Server anliegt (im einfachsten Fall jeder Stream auf jedem Server). Bei einem eingehenden HTTP-Request auf dem Loadbalancer suchst du einfach den am wenigsten belasteten Server raus und schickst den Client per 302 Redirect dort hin ("Location:"-Header in PHP setzen reicht). Wenn alle Server maximal ausgelastet sind, schickst du ein "503 Service Unavailable" an den Client.
Diese Lösung hat ein paar Fallstricke:
* Wenn innerhalb von wenigen Sekunden hunderte Clients ankommen, wirst du diese falsch verteilen, da die Entscheidungsgrundlage ja nur alle X (z.B. 10) Sekunden erneut ermittelt wird.
* Die Clients müssen alle Icecast-Server direkt erreichen können. Es ist also technisch möglich, dass ein Client den Loadbalancer missachtet und sich direkt auf einen der Streaming-Server verbindet. Das sollte vernachlässigbar sein, die von solchen Clients verbrauchte Bandbreite wird ja beim Loadbalancing mit eingerechnet. Es sollte aber deshalb ein harter Limit am jeweiligen Icecast-Server eingestellt sein, um Missbrauch/DDOS zu vermeiden.
Nebenbei: Klassischerweise versteht man in der HTTP-Welt (Icecast ist HTTP) unter einem Loadbalancer ein System, welches in der Kommunikation zwischen dem Client und dem Server steht und den Server "maskiert", d.h. für den Client sieht der Loadbalancer wie der Server aus. Das hiesse auch, dass alle Daten durch den Loadbalancer fließen, was man in diesem Fall ja nicht möchte. Demnach solltest du hier deutlich von einem "Redirector" o.Ä. gesprochen werden, der die Clients lediglich einem Server zuweist.
Ich habe vor einiger Zeit mal ein Icecast-Plugin für das Monitoring-Tool Munin geschrieben, welches die Auswertung der stats.xml (Abholen, Parsen, Weitergeben) genau so vornimmt um den ausgehenden Traffic zu bestimmen:
https://github.com/munin-monitoring/contrib/blob/master/plugins/icecast/icecast_
Es gab mal schöne Screenshots auf der Munin-Webseite, die sind leider weg, aber diverse Leute haben netterweise ihre Munin-Instanzen öffentlich erreichbar gemacht, deshalb findet man sie mit Google:
http://www.google.de/search?q="Icecast+outgoing+traffic"
Da einfach eine der Ergebnisse anklicken und auf "Icecast" klicken, dann siehst du den Traffic-Graphen.
Das umrechnen von absoluten Werten in die ausgehende Bandbreite übernimmt in diesem Fall Munin mit seinem "DERIVE"-Messwerttypen. Dies entspricht der überall angewandten Methode, um an solche Werte zu kommen. Wenn du z.B. auf einem Server "ifconfig" aufrufst, bekommst du irgendwo eine Zeile wie "RX bytes:7474889706 (7.4 GB) TX bytes:5209122532 (5.2 GB)". Monitoring-System wie Cacti und Munin gucken sich diese absoluten Werte periodisch an und ermitteln ie Bandbreite.
Gruß, Markus
PS: Dass deine Server "crashen" wenn die Anbindung ausgelastet ist glaube ich nicht, lass das mal von jemandem mit Ahnung von Linux analysieren, dann kannst du auch realistische Grenzwerte für's Loadbalancing aufstellen.
Wenn du jetzt den Wert periodisch abfragst und dir das Delta anguckst, kennst du ziemlich genau die Bandbreite, die die einzelnen Icecast-Streams eines Server momentan belegen. Rechne die Bandbreiten aller Streams zusammen und du kennst die ausgehende Bandbreite eines Icecast-Prozesses.
Wenn du jetzt ein Script schreibst, welches z.B. alle 10 Sekunden die momentan ausgeende Bandbreite deiner Icecast-Server bestimmt und zentral (für den "Loadbalancer" abrufbar) in eine Datenbank schreibst, weisst du genau, wo du einen Client hinschicken kannst.
Du musst zentral wissen, wieviel Bandbreite jeder Icecast-Server (individuell) verträgt und welcher Stream auf welchem Icecast-Server anliegt (im einfachsten Fall jeder Stream auf jedem Server). Bei einem eingehenden HTTP-Request auf dem Loadbalancer suchst du einfach den am wenigsten belasteten Server raus und schickst den Client per 302 Redirect dort hin ("Location:"-Header in PHP setzen reicht). Wenn alle Server maximal ausgelastet sind, schickst du ein "503 Service Unavailable" an den Client.
Diese Lösung hat ein paar Fallstricke:
* Wenn innerhalb von wenigen Sekunden hunderte Clients ankommen, wirst du diese falsch verteilen, da die Entscheidungsgrundlage ja nur alle X (z.B. 10) Sekunden erneut ermittelt wird.
* Die Clients müssen alle Icecast-Server direkt erreichen können. Es ist also technisch möglich, dass ein Client den Loadbalancer missachtet und sich direkt auf einen der Streaming-Server verbindet. Das sollte vernachlässigbar sein, die von solchen Clients verbrauchte Bandbreite wird ja beim Loadbalancing mit eingerechnet. Es sollte aber deshalb ein harter Limit am jeweiligen Icecast-Server eingestellt sein, um Missbrauch/DDOS zu vermeiden.
Nebenbei: Klassischerweise versteht man in der HTTP-Welt (Icecast ist HTTP) unter einem Loadbalancer ein System, welches in der Kommunikation zwischen dem Client und dem Server steht und den Server "maskiert", d.h. für den Client sieht der Loadbalancer wie der Server aus. Das hiesse auch, dass alle Daten durch den Loadbalancer fließen, was man in diesem Fall ja nicht möchte. Demnach solltest du hier deutlich von einem "Redirector" o.Ä. gesprochen werden, der die Clients lediglich einem Server zuweist.
Ich habe vor einiger Zeit mal ein Icecast-Plugin für das Monitoring-Tool Munin geschrieben, welches die Auswertung der stats.xml (Abholen, Parsen, Weitergeben) genau so vornimmt um den ausgehenden Traffic zu bestimmen:
https://github.com/munin-monitoring/contrib/blob/master/plugins/icecast/icecast_
Es gab mal schöne Screenshots auf der Munin-Webseite, die sind leider weg, aber diverse Leute haben netterweise ihre Munin-Instanzen öffentlich erreichbar gemacht, deshalb findet man sie mit Google:
http://www.google.de/search?q="Icecast+outgoing+traffic"
Da einfach eine der Ergebnisse anklicken und auf "Icecast" klicken, dann siehst du den Traffic-Graphen.
Das umrechnen von absoluten Werten in die ausgehende Bandbreite übernimmt in diesem Fall Munin mit seinem "DERIVE"-Messwerttypen. Dies entspricht der überall angewandten Methode, um an solche Werte zu kommen. Wenn du z.B. auf einem Server "ifconfig" aufrufst, bekommst du irgendwo eine Zeile wie "RX bytes:7474889706 (7.4 GB) TX bytes:5209122532 (5.2 GB)". Monitoring-System wie Cacti und Munin gucken sich diese absoluten Werte periodisch an und ermitteln ie Bandbreite.
Gruß, Markus
PS: Dass deine Server "crashen" wenn die Anbindung ausgelastet ist glaube ich nicht, lass das mal von jemandem mit Ahnung von Linux analysieren, dann kannst du auch realistische Grenzwerte für's Loadbalancing aufstellen.
@dude, vorweg: ich bin natürlich dankbar wenn jemand mir hier versucht zu helfen.
loadbalancing ist in dem zusammenhang nicht 100%ig korrekt, das ist mir klar. aber erstens war mir beim erstellen des thread noch nicht klar wie ich das problem lösen werde (is ja klar) und zweitens halte ich es für wahrscheinlicher dass aus "loadbalancing" als titel eher hervorgeht um was es geht als wenn dieser thread "redirecting" heißen würde. aber das ist sicher ansichtsache.
ich bin mit der stats.xml (abgesehen von der erzeugung der enthaltenen werte ) sowie deren abfrage mit skripten und skriptprogrammierung generell hinreichend vertraut. auch die ermittlung des server traffic hab ich im laufe dieses thread erlernt ^^. die methode mit der Header(location:"") funktion ist die, die bei meinem "prototypen" zZ läuft.
mein hauptproblem ist aktuell eigentlich nur noch einen guten algorithmus für die auswahl des servers zu finden.
dass für die meisten anwender, die privat einen streamingserver betreiben, die bandbreite ausschlaggebend ist, ist mir natürlich bewusst. das ist aber bei mir definitiv nicht der flaschenhals. in letzter zeit kam es mal wieder zu einem "crash" (ich weis nicht wie man in kennerkreisen dazu sagt).und aus den entsprechenden cacti daten geht hervor dass nur knapp ein fünftel der verfügbaren bb dabei genutzt wurde.
wenn zbsp 100 leute einen 256 kbps stream abrufen verursachen die doch genausoviel traffic wie 800 hörer auf einem 32 kbps stream, oder irre ich mich da? das bedeutet in dem fall bei gleichem traffic 700 anfragen mehr an den server und damit doch auch eine größere belastung..? ich hatte vermutet, die last die durch den icecast prozess verursacht wird lässt sich direkt anhand von systemwerten ablesen, bspw cpu-last durch icecast unter top (das untersuche ich gerade).
das ps verstehe ich nicht, ich hab nie gesagt dass meine anbindung ausgelastet ist
gruß
loadbalancing ist in dem zusammenhang nicht 100%ig korrekt, das ist mir klar. aber erstens war mir beim erstellen des thread noch nicht klar wie ich das problem lösen werde (is ja klar) und zweitens halte ich es für wahrscheinlicher dass aus "loadbalancing" als titel eher hervorgeht um was es geht als wenn dieser thread "redirecting" heißen würde. aber das ist sicher ansichtsache.
ich bin mit der stats.xml (abgesehen von der erzeugung der enthaltenen werte
) sowie deren abfrage mit skripten und skriptprogrammierung generell hinreichend vertraut. auch die ermittlung des server traffic hab ich im laufe dieses thread erlernt ^^. die methode mit der Header(location:"") funktion ist die, die bei meinem "prototypen" zZ läuft.mein hauptproblem ist aktuell eigentlich nur noch einen guten algorithmus für die auswahl des servers zu finden.
dass für die meisten anwender, die privat einen streamingserver betreiben, die bandbreite ausschlaggebend ist, ist mir natürlich bewusst. das ist aber bei mir definitiv nicht der flaschenhals. in letzter zeit kam es mal wieder zu einem "crash" (ich weis nicht wie man in kennerkreisen dazu sagt).und aus den entsprechenden cacti daten geht hervor dass nur knapp ein fünftel der verfügbaren bb dabei genutzt wurde.
wenn zbsp 100 leute einen 256 kbps stream abrufen verursachen die doch genausoviel traffic wie 800 hörer auf einem 32 kbps stream, oder irre ich mich da? das bedeutet in dem fall bei gleichem traffic 700 anfragen mehr an den server und damit doch auch eine größere belastung..? ich hatte vermutet, die last die durch den icecast prozess verursacht wird lässt sich direkt anhand von systemwerten ablesen, bspw cpu-last durch icecast unter top (das untersuche ich gerade).
das ps verstehe ich nicht, ich hab nie gesagt dass meine anbindung ausgelastet ist
gruß
Dude
Benutzer
Okay, Begrifflichkeiten. Sorry, das sollte nicht so von oben herab klingen wie es vielleicht angekommen ist. Als Crash habe ich jetzt angenommen der Server (ganze Kiste) stürzt ab, hat z.B. Kernel Panic oder ist unwiederbringlich weg auch wenn die Last weggeht. Was passiert denn genau?
Sehe ich auch so. Die 800 Hörer müssten wesentlich viel mehr Last (mehr Pakete) erzeugen. Guck dir mal die Interrupts/Kontextswitche in Cacti unter Last an. Wenn die Werte hochschnellen und die in "top" angezeigte CPU-Last eher im System (%sy) als im Userspace (%us) versenkt wird, ist das System ggf. mit der Menge der durchzuschiebenden Pakete überfordert. Wenn eher der Icecast-Prozess die CPU wegfrisst musste evtl. CPU nachlegen.
Bei 800 Clients kommst du schon in Regionen, wo das ulimit (Anzahl der gleichzeitig geöffneten Files incl. Sockets) reingrätschen und weiter Verbindungen verhindern kann. Dann müsste im Logfile irgendwas mit "Too many open files" auftauchen.
Sorry, das sollte nicht so von oben herab klingen wie es vielleicht angekommen ist. Als Crash habe ich jetzt angenommen der Server (ganze Kiste) stürzt ab, hat z.B. Kernel Panic oder ist unwiederbringlich weg auch wenn die Last weggeht. Was passiert denn genau?Sehe ich auch so. Die 800 Hörer müssten wesentlich viel mehr Last (mehr Pakete) erzeugen. Guck dir mal die Interrupts/Kontextswitche in Cacti unter Last an. Wenn die Werte hochschnellen und die in "top" angezeigte CPU-Last eher im System (%sy) als im Userspace (%us) versenkt wird, ist das System ggf. mit der Menge der durchzuschiebenden Pakete überfordert. Wenn eher der Icecast-Prozess die CPU wegfrisst musste evtl. CPU nachlegen.
Bei 800 Clients kommst du schon in Regionen, wo das ulimit (Anzahl der gleichzeitig geöffneten Files incl. Sockets) reingrätschen und weiter Verbindungen verhindern kann. Dann müsste im Logfile irgendwas mit "Too many open files" auftauchen.
solang es nicht so gemeint war..
das sind auf jeden fall erstmal nützliche denkanstöße.
bei so einem crash stürzt in der regel nicht die komplette kiste ab, sondern nur der icecastserver (icecast prozess muss dann neu gestartet werden).
zur cpu last in cacti hab ich erstmal ein generelles problem, und zwar ist da 100% nicht die maximale auslastung. mit anderen worten, es können auch locker mal 200% werden. ist das bei einem multicore-system abhängig von der zahl der rechenkerne? also ähnlich wie beim load average, 5 kerne bedeutet maximale_cpu-last=500% ?das konnte ich aber nur im cacti beobachte, ich loge über ein skript die top-werte mit => cpu_max~30%. ich beobachte auch die durch den icecast-prozess verursachte prozessorlast, das selbe bild: %cpu > 100%, das aber wiederum in top!
die verteilung der cpu-last ist unterschiedlich. bei den meisten servern steigt bei hohen hörerzahlen zwar auch %sys, liegt aber dabei im maximum um die 50% von %us. bei einer kiste ist aber %sys_max=%us_max wie ich gerade sehe, ist da das system mit der anzahl der pakete überfordert? ich frag mich woran das liegt, die vorausetzungen sind bei allen rechnern gleich, sowohl hw als auch sw (inkl. kernel).
was ich außerdem nicht nachvollziehen kann ist, dass zum zeitpunkt höchster nutzer-zahlen plötzlich %ni steigt. liegt das daran, dass der prozessor eh schon stark belastet ist und die prozesse mit niedriger priorität dann mehr ins gewicht fallen?
was ich außerdem beobachtet habe, der load average steigt bei hohen nutzerzahlen stark an. der load ist ja nun ein maß für die anzahl der prozesse im running queue, icecast ist doch aber quasi nur ein prozess..? verursachen die geöffneten verbindungen noch weitere prozesse?
grüße
das sind auf jeden fall erstmal nützliche denkanstöße.
bei so einem crash stürzt in der regel nicht die komplette kiste ab, sondern nur der icecastserver (icecast prozess muss dann neu gestartet werden).
zur cpu last in cacti hab ich erstmal ein generelles problem, und zwar ist da 100% nicht die maximale auslastung. mit anderen worten, es können auch locker mal 200% werden. ist das bei einem multicore-system abhängig von der zahl der rechenkerne? also ähnlich wie beim load average, 5 kerne bedeutet maximale_cpu-last=500% ?das konnte ich aber nur im cacti beobachte, ich loge über ein skript die top-werte mit => cpu_max~30%. ich beobachte auch die durch den icecast-prozess verursachte prozessorlast, das selbe bild: %cpu > 100%, das aber wiederum in top!
die verteilung der cpu-last ist unterschiedlich. bei den meisten servern steigt bei hohen hörerzahlen zwar auch %sys, liegt aber dabei im maximum um die 50% von %us. bei einer kiste ist aber %sys_max=%us_max wie ich gerade sehe, ist da das system mit der anzahl der pakete überfordert? ich frag mich woran das liegt, die vorausetzungen sind bei allen rechnern gleich, sowohl hw als auch sw (inkl. kernel).
was ich außerdem nicht nachvollziehen kann ist, dass zum zeitpunkt höchster nutzer-zahlen plötzlich %ni steigt. liegt das daran, dass der prozessor eh schon stark belastet ist und die prozesse mit niedriger priorität dann mehr ins gewicht fallen?
was ich außerdem beobachtet habe, der load average steigt bei hohen nutzerzahlen stark an. der load ist ja nun ein maß für die anzahl der prozesse im running queue, icecast ist doch aber quasi nur ein prozess..? verursachen die geöffneten verbindungen noch weitere prozesse?
grüße
McCavity
Benutzer
Wurde Load nicht mit der Anzahl der Kernelthreads berechnet? Ich würde stark vermuten, daß Icecast Multithreaded ist, also jeder Hörer einen eigenen Thread (auch: LWP (Light Weight Process) bekommt - prstat (nur in Solaris verfügbar) oder sonst top sollte auch aufschlüsseln, wieviele Threads ein einzelner Proßeß hat...
LG
McCavity
LG
McCavity
ahoi, eine kurze aktualisierung zum thema:
die lösung, user anhand einer dynamisch durch den gewichtungsprozess ermittelten ip mittels http-header-manipulation weiterzuleiten habe ich verworfen. hat zwar alles ganz gut funktioniert (apache benchmark 3500 requests/s), aber so ist es nicht möglich die ip für den user zu maskieren.
deßhalb versuche ich es jetzt mal per dns mit sql-backend (powerdns). da ja sowieso schon eine sql-db im spiel ist um die daten auf dem loadbalancer zu sammeln scheint mir das ganz günstig zu sein. die ermittelte ip würde ich dann dynamisch in die entsprechenden a-records schieben.
das hat zwar jetzt nicht mehr viel mit radiostreaming zu tun aber vielleicht ist das ganze irgendwann für jemand anderen hilfreich.
die lösung, user anhand einer dynamisch durch den gewichtungsprozess ermittelten ip mittels http-header-manipulation weiterzuleiten habe ich verworfen. hat zwar alles ganz gut funktioniert (apache benchmark 3500 requests/s), aber so ist es nicht möglich die ip für den user zu maskieren.
deßhalb versuche ich es jetzt mal per dns mit sql-backend (powerdns). da ja sowieso schon eine sql-db im spiel ist um die daten auf dem loadbalancer zu sammeln scheint mir das ganz günstig zu sein. die ermittelte ip würde ich dann dynamisch in die entsprechenden a-records schieben.
das hat zwar jetzt nicht mehr viel mit radiostreaming zu tun aber vielleicht ist das ganze irgendwann für jemand anderen hilfreich.
- Status