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.