1. Diese Seite verwendet Cookies. Wenn du dich weiterhin auf dieser Seite aufhältst, akzeptierst du unseren Einsatz von Cookies. Weitere Informationen

Loadbalancing

Dieses Thema im Forum "Internetradio- und Heimstudio-Software" wurde erstellt von fresssh, 23. Februar 2012.

Status des Themas:
Es sind keine weiteren Antworten möglich.
  1. fresssh

    fresssh Benutzer

    hallo,
    ich möchte mich mit dem Thema Loadbalancing beschäftigen und wollte mal fragen ob ihr mir gute Informationsquellen (auch literatur) empfehlen könnt, mit denen ich mich ins thema einarbeiten kann. wikipedia ect. hab ich selbstverständlich schon versucht und google spuckt iwie auch nichts brauchbares aus..
    hat jemand von euch schonmal selber einen loadbalancer programmiert?
     
  2. fresssh

    fresssh Benutzer

    mich würde auch interessieren welche (freien) softwarelösungen sich fürs streaming eignen. die, die ich bis jetzt gefunden habe basieren alle mehr oder weniger auf dem reverse proxy prinzip, wobei der rückkanal über den loadbalancer geht, was ja mehr als ungeeignet ist.
     
  3. caraoge

    caraoge Benutzer

    SHOUTcast?
     
  4. caraoge

    caraoge Benutzer

    Ich denke mal es geht um das Thema "Streams"...
     
  5. fresssh

    fresssh Benutzer

    genau, es geht um das thema streams. icecast...
     
  6. caraoge

    caraoge Benutzer

    Eine Lastverteilung kann das System von sich aus nicht.
    Du kannst dir aber ein Script basteln dass du deinen Hörern als Stream Adresse gibts und dass dir je nach Auslastung einen anderen Stream ausgibt.
    Das haben wir bei TechnoBase & Co auch so im Einsatz.
     
  7. fresssh

    fresssh Benutzer

    danke für deine antwort, genau sowas habe ich vor! welche sprachen eignen sich dafür? meine programmierkenntnisse beschränken sich leider (noch) auf perl,php und shell. Im Prinzip ist das doch dann weighted dns roundrobin, oder?
     
  8. McCavity

    McCavity Benutzer

    "Weighted DNS Round Robin" habe ich noch nicht gehört (gibt es sowas?) und ich denke, das wäre hier auch die falsche Bezeichnung. Unter "DNS Round Robin" versteht man einfach nur mehrere IP-Adressen für denselben CNAME oder A-Record im DNS. Der DNS Server liefert dann bei jeder Anfrage eine der gelisteten IP-Adressen reihum zurück, ohne Rücksicht auf die Auslastung oder ob die IP-Adresse überhaupt erreichbar ist.

    Was Du meinst, ist ein Algorithmus, der die auszuliefernde Verbindung aufgrund vorbestimmter Kriterien (Hörerzahlen) vornimmt. Dazu eignen sich im Prinzip alle Sprachen, auch die von Dir genannten Perl, PHP und sogar Shellscripte - das eine besser, das andere weniger gut.

    Wenn ich mich richtig erinnere (ich habe mich bisher nur rudimentär mit den tatsächlichen Streams auseinandergesetzt), dann läuft die Kommunikation zwischen Server und Client über HTTP in dem Sinne, daß der Client zum Beispiel auch HTTP-Redirects versteht. In dem Fall könntest Du Deinen Loadbalancer wie folgt aufbauen: In bestimmten Intervallen fragt der Loadbalancer von allen konfigurierten Streams die aktuellen Hörerzahlen ab (z.B. per wget oder curl). Dabe kann festgestellt werden ob a) der Stream über haupt antwortet und falls ja, wieviele Slots von wievielen Slots pro Stream verfügbar sind. Aus den Vorhandenen Daten läßt sich dann der nächste Kandidat für eine eingehende Verbindung bestimmen.

    Verbindet sich ein Client mit dem Loadbalancer, bekommt dieser einen HTTP-Redirect mit der Adresse des zuvor ausgewählten Kandidaten zurück. Entweder kann man das als Trigger nutzen, um eine neue Bewertungsrunde auszulösen, oder man vertraut einfach dem Intervall - hat alles Vor- und Nachteile und ist im Prinzip mehr von der eigenen Präferenz abhängig...

    LG

    McCavity
     
  9. fresssh

    fresssh Benutzer

  10. caraoge

    caraoge Benutzer

    DNS RR eignet sich für Stream eher schlecht als recht.
    Die Streams werden trotzdem ungleichmäßig ausgelastet.
    Wenn ein Stream voll ist oder nicht erreichbar ist wird er jedoch einigen Hörern trotzdem vorgeschlagen.

    Daher die Empfehlung dies mit einem Script zu realisieren.
    Die Scriptsprache ist egal. Es muss über einen Webserver ausgegeben werden.

    Funktionsweise:
    - Hörer ruft Script auf z.b. http://listen.technobase.fm/tunein-aacplus-pls
    - Das Script erkennt ob es sich um einen Player handelt oder nicht.
    -- Wenn ein Player erkannt wird, gib den Stream aus
    -- Prüfe vorher ob der auszugebende Stream genügen Ressourcen frei hat und erreichbar ist
    --- Wenn nicht versuche es mit einem anderen Stream
    -- Andernfalls gib wieder das Script aus
     
  11. fresssh

    fresssh Benutzer

    also ich möchte mich jetzt erstmal dem skript zur gewichtung der einzelnen ausspielserver widmen. ich hab mir überlegt dazu im skript eine berechnung laufen zu lassen, welche anhand von diversen performancewerten und anzahl(+taktung ?) der cpu´s einen index ermittelt ( zbsp von 0 bis n-1, wobei n= anzahl der server). anhand der indize entscheidet das loadbalancing skript, welcher server verhältnismäßig am unbelastetsten ist. meine frage ist nun, welche performancewerte sind dabei sinnvoll? die hörerzahl würde ich aus diversen gründen außenvor lassen wollen. bisher habe ich ins auge gefasst: cpu-last durch den icecast prozess, cpu last allgemein und traffic. was würdet ihr da noch ergänzen? und habt ihr evtl erfahrungen gemacht in bezug auf das verhältnis von cpu-last-icecast-prozess und performance/erreichbarkeit/auslastung des servers?
     
  12. caraoge

    caraoge Benutzer

    Die CPU Last des Server interessiert bei sowas nicht.
    Man rechnet im vorraus aus welcher Server wie viele Slots maximal hosten kann!
    Einfach zu sagen Server X hostet 1000 User und hat aber nicht die entsprechende Anbindung um 1000 User zu hosten ist schwachsinnig.
    Damit vertreibt man nur die Hörer wenn ständig buffer zu höhren sind.

    Du liest dann einfach nur noch aus die viele Slots sind belegt und wie viele sind maximal möglich.
    Daran kannst du dann bestimmen wie viele Ressourcen auf einem Stream noch frei sind.
     
  13. fresssh

    fresssh Benutzer

    ok, ich muss sagen der begriff slots ist mir relativ neu. wie kriege ich die zahl der slots raus, uplinkbandbreite durch streambandbreite? das wäre ungünstig für meinen fall, da ich viele streams mit verschiedenen bandbreiten hab. ich möchte aber auch nicht die hörerzahl pro stream limitieren.
     
  14. McCavity

    McCavity Benutzer

    Doch, das möchtest Du. Du möchtest das sogar ganz dringend. Du wirst auch gleich sehen, warum:

    Radio Eriwan sagt: im Prinzip ja. Die Bandbreite des Uplink ist eine feste Größe, über die Du rein physikalisch nicht hinauskannst. Insofern ist, zumindest in der Theorie, Uplinkbandbreite / Streambandbreite die *maximale* physisch unterstützte Anzahl Slots. Wenn Du mehrere Streams auf demselben Server hast, so teilen sich diese die Bandbreite natürlich. Das verkompliziert zwar die Rechnung ein bißchen, aber nicht wesentlich: Uplinkbandbreite / (Slots(Stream1) * Bandbreite(Stream1) + Slots(Stream2) * Bandbreite(Stream2) + ...). Andersherum, und damit komme ich wieder auf das, was ich Eingangs sagte, solltest Du die Slots sämtlicher Streams auf dem Server so limitieren, daß die Uplinkbandbreite nicht überschritten wird.

    Jetzt kommt noch ein sehr wichtiger Punkt: ich schrieb oben etwas von "theoretischer" Maximalzahl. Die Netzwerkanbindung Deines Servers wird i.d.R. nicht ausschließlich von Streams genutzt. Da sind gewöhnlich immer einige kleinere Dienste, die die ebenfalls Bandbreite brauchen. Zusätzlich kann - je nach Betriebssystem - der Kernel Schwierigkeiten (im Sinne von Ressourcenprobleme) bekommen, wenn die Netzwerkverbindung im Vollastbetrieb arbeiten muß. Drittens, und das ist vielleicht das entscheidende Problem, ist der "Uplink" Deines Servers *nur* das Stückchen Kabel zwischen Deinem Server und dem nächsten Router. Solange Du das RZ nicht selbst betreibst (und auch dann nur bis zum Übergabepunkt), weißt Du nicht, wie "dick" die Routen von dort bis zum Kunden (Hörer) sind - es können überall Flaschenhälse auftreten. Last not least hast Du auch noch "unbekannte" Konkurrenz: andere Server, die im selben Netzwerksegment liegen, auf den Routen "draußen" Konkurrenzverkehr aus anderen RZ - im Prinzip niemals vorhersehbar.

    Wie weit Du tatsächlich technisch gehen kannst, läßt sich vermutlich nicht einmal empirisch eindeutig belegen, da ja die Hörer zu allem Unglück auch noch verschiedensten Parametern unterworfen sind. Selbst wenn nur ein einzige Slot belegt ist, kann es immer noch passieren, daß der buffert, wenn es irgendwo auf dem Weg einen Engpaß gibt. Eine letzte Sicherheit gibt es also nicht. Ich empfehle - auch aus eigener Erfahrung - daß man zur Berechnung der maximalen Streamanzahl nicht 100% Uplinkbandbreite heranziehen sollte, sondern eher ca. 80% - das hat sich als grobe Faustformel ganz gut bewährt.

    Das sollte an sich kein größeres Problem darstellen. Der Loadbalancer sollte ja generell nur über Streams derselben Bandbreite balancieren, d.h., daß Du im Prinzip für jede angebotene Bandbreite eine eigene Loadbalancer-Instanz laufen läßt. Jede dieser Loadbalancer-Instanzen kennt dann halt n Streams, von denen jeder m Slots hat. Das wiederum heißt, daß Du für jeden Stream sein "Gewicht" ausrechnen kannst (als Anteil seiner Slots an der Gesamtanzahl verfügbarer Slots). Zusammen mit der momentanen Auslastung läßt sich so recht leicht der nächste Kandidat für einen neuen Request ermitteln. Voraussetzung dafür ist natürlich, daß der Load Balancer permanent (mindestens in bestimmten Intervallen) über die aktuelle Auslastung bescheid weiß. Sollte ein Stream komplett wegfallen (zum Beispiel wegen Neustart), dann sollte der Loadbalancer die Gewichte neu berechnen - das gleiche gilt natürlich, wenn ein vorher ausgefallener Stream wieder- oder ein neuer dazu kommt.

    Ist alles keine Hexerei, aber hinreichend komplex :)

    LG

    McCavity
     
  15. fresssh

    fresssh Benutzer

    nochmal danke für die ausführlichen Antworten. :)
    sagen wir mal so, die bandbreite ist bei mir nicht primär der flaschenhals.daher würde ich innerhalb des loadbalancers anhand mehrerer instanzen auswählen, also zbsp. server 1,2 und 3 hinsichtlich cpu last vergleichen ->der mit der höchsten last scheidet aus; die beiden verbleibenden server auf verfügbare bandbreite prüfen -> wähle den server mit der größten bandbreite. meine frage dabei ist, welche größen stehen primär in verbindung mit der last beim streaming? die cpu last scheint es ja nicht unbedingt zu sein (wie caraoge schon sagte)..ich überwache meine server per cacti und am wochenende ist zum beispiel einer davon gecrashed. ich habe mir den zustand den das system unmittelbar vor dem crash hatte im cacti angeschaut und mit alten werten verglichen: weder die hörerzahl war maximal zum zeitpunkt des crashes noch die belegte bandbreite oder cpu last. der einzige wert der global maximal war, war der load average (also es geht um linux-kisten ;) ).
    eine essentielle frage hab ich noch, wie richte ich es ein dass das LB-Skript ausgeführt wird wenn eine anfrage beim LB-Server ankommt?
    und nochmal zum thema bandbreite, ich habe mir überlegt die slots nicht im sinne einer festen hörerzahl zu limitieren sondern dynamisch, abhängig von der verfügbaren bandbreite. also zbsp. für 50 Bps streams 5% der verfügbaren bandbreite reservieren, für 120 Bps streams 60% usw. ..die verhältnisse habe ich über einen gewissen zeitraum ermittelt und sie sind relativ konstant. wäre das praktikabel?
     
  16. fresssh

    fresssh Benutzer

    würde mich freuen wenn ihr mir weiterhelfen könntet :)
     
  17. McCavity

    McCavity Benutzer

    Servus,

    ich habe bis jetzt vor allem deshalb nicht mehr geantwortet, weil ich jetzt das sichere Terrain verlasse - ich kann nur noch mutmaßen, da ich keine aktuellen Vergleichswerte zur Hand habe. Hard- und Software Tuning sind leider keine exakte Wissenschaft, sondern basieren auch auf sehr viel Erfahrung und einem ordentlichen Schuß Voodoo - da Ferndiagnosen zu stellen ist leider ziemlich utopisch. Ein hoher Load Average (Durchschnittslast) deutet darauf hin, daß kurz vor dem Crash die CPU Last sehr hoch gewesen sein muß - was das aber verursacht hat, läßt sich nur in dem System selbst ermitteln und auch da im Prinzip nur iterativ (oder eben mit viel Erfahrung). Auf meinen Systemen kenne ich zum Beispiel meine Pappenheimer, die ich in solchen Situationen zuerst untersuche.

    Cacti ist ein solider Monitor, aber dessen Werte zu interpretieren ist nicht trivial. Wenn Du Glück hast, tritt der Crash halbwegs regelmäßig auf, dann hast Du eine Chance, dem Übeltäter auf die Schliche zu kommen - bei einmaligen Events ist das fast aussichtslos (Stichwort: Reproduzierbarkeit).

    Die Frage, wie ein LB ausgeführt wird, hängt im Prinzip von der eingesetzten Software selbst ab. Es sind unzählige Varianten denkbar, daher ist auch hier eine allgemeingültige Antwort nicht möglich. Generell wird es vermutlich darauf hinauslaufen, daß Du einen - wie auch immer gearteten - Webserver laufen läßt (Apache zum Beispiel). Diesen konfigurierst Du so, daß er Deine LB-Software laufen läßt - zum Beispiel in Perl oder PHP geschrieben. Die LB Software wird - vermute ich - zweiteilig werden: ein Teil läuft "im" Webserver, das ist der Teil, den die Clients "zu sehen" bekommen, d.h. wenn jemand den Stream hören will, nimmt er den URI, unter dem der LB erreichbar ist, verbindet sich mit dem, das Script läuft los und liefert - wie auch immer - einen neuen URI, der zum tatsächlichen Stream zeigt, zurück. Der zweite Teil läuft vermutlich unabhängig vom Webserver und ist dafür zuständig, in regelmäßigen Abständen sämtliche ihm bekannten Streams abzufragen (könnte man zum Beispiel auch per Script & Cron machen, oder etwas fortgeschritten als daemon). Die Ergebnisse dieses Scripts liefer die Grundlage für die LB-Entscheidungen des "vorderen" Teils.

    Wenn ich mich richtig erinnere, stellt man die Slotanzahl der Streams über ein Configfile ein, das nur bei Neustart, bzw. kill -HUP neu gelesen wird - insofern würde ich es nicht für praktikabel halten, die Slotanzahl dynamisch anpassen zu wollen. Lasse ausreichend Headroom und ansonsten die Streams in Ruhe - mach's nicht komplizierter als unbedingt nötig (unter der Prämisse würde ich auch das ganze CPU, Bandbreite, etc. pp. zum LB Messerei sehen - dimensioniere lieber die Kiste ordentlich und laß den Loadbalancer nur über die vorhandenen Slots balancieren - das KISS Prinzip läßt grüßen. Cacti solltest Du trotzdem im Blick halten, um Deine Annahmen über den Ressourcenverbrauch zu überprüfen (und ggf. nachjustieren) ;))

    LG

    McCavity
     
  18. fresssh

    fresssh Benutzer

    mmh im großen und ganzen war das auch mein plan, mit der aufsplittung in mehrere parallele prozesse.
    mein hauptproblem zur zeit ist eigentlich, wie ich den loadbalancer auf eingehende anfragen anworten lasse. erst hatte ich die idee mir ein dns nameserver skript zu schnappen und anzupassen, aber das ist mir ehrlich gesagt ein bisschen zu hoch ^^ . daher meine zweite idee: mit php und einer funktion wie etwa "socket_create_listen()" (oder so :p ) auf port80 lauschen und auf anfragen reagieren, dabei aber wieder das problem, dass das skript ja quasi dauerhaft laufen müsste...kann man den apache so einfach anpassen? oder läuft dann nur das skript als anwendung auf dem server? auf die idee bin ich noch gar nicht gekommen, die frage ist nur ob dabei die reaktionszeit akzeptabel ist.
    danke erstmal!
    gruß
     
  19. McCavity

    McCavity Benutzer

    Puuuuh, da fragste mich jetzt was... da geht's schon mitten in's Protokoll rein. Im Prinzip müßten, denke ich, die Streaming Clients einen 403 HTTP Redirect verstehen, denke ich. Dein Script müßte also im Prinzip nicht mehr tun, als den Header bauen, HTTP Status 403 setzen und im Body (glaube ich) den URI des neuen Streams, wo hinverbunden werden soll. Der Client wertet das dann aus und verbindet sich mit dem übermittelten Stream... Das hätte den Charme, daß Du das wirklich mit einem Standard-Apache erschlagen kannst - der "imitiert" aus Sicht der Clients einen Stream, allerdings liefert er halt selbst nie einen zurück sondern nur einen neuen URI, wo dann tatsächlich ein Stream anliegt.

    Aber wie gesagt, da ist jetzt viel Vermutung meinerseits drin, ich hab sowas selber auch noch nie gebaut, ich weiß nur in etwa, wie's funktioniert ;)

    LG

    McCavity
     
  20. MADxHAWK

    MADxHAWK Benutzer

  21. McCavity

    McCavity Benutzer

    Hi, MAD,

    Ich habe mir das auch mal angeschaut, bin mir aber nicht sicher, ob das die optimale Lösung für diese spezielle Anwendung sein könnte. Wenn ich mir Grafik bei UltraMonkey anschaue (und die Notwendigkeit, auf den Loadbalancern IP Forwarding zu aktivieren), dann geht sämtlicher IP-Verkehr durch den Loadbalancer. Damit wird, gerade beim Streaming, dieser zum Flaschenhals in puncto Bandbreite und ich denke, daß das Loadbalancing explizit dazu gedacht, eben den Flaschenhals "Bandbreite" zu umgehen. Insofern wäre die Lösung, einen HTTP Redirect zu senden, vorzuziehen. Diese kann zwar nicht so schön automatisch reagieren, wenn ein Server wegbricht und sie verschleiert auch nicht die IP-Adressen der tatsächlichen Streamserver (mit etwas Aufwand kann man die immer noch ermitteln und sich direkt, unter Umgehung des Loadbalancers, mit einem Stream verbinden), dennoch denke ich, daß es für Streaming die nützlichere Variante wäre - aber entscheiden darf das der TO, selbstverständliche ;)

    LG

    McCavity
     
  22. fresssh

    fresssh Benutzer

    @McCavity zum thema client-status (in dem fall:hörerzahl) vom loadbalancer aus abfragen: prinzipiell seh ich das auch so, also die clients möglichst unangetastet vom gewichtungsprozess zu lassen. es müssen aber ebend auch andere werte abgefragt werden (cpu last, etc.). dafür habe ich im rahmen älterer projekte bereits skripte gebastelt, die die werte per snmp auf den cacti server holen. das problem dabei ist die bearbeitungszeit, vor allem wieder durch die authentifizierung (in dem fall durch snmp). da ist die bandbreite noch nicht mal dabei. diese lässt sich nur als counter wert abrufen, wenn man also einen zeitbezogenen wert wünscht ( x Bit/s) muss man mit mindestens einer sekunde abstand nochmal messen und sich daraus die datenrate errechnen lassen => nochmal 2 sekunden mehr abarbeitungszeit pro server!

    deshalb ist mein genereller ansatz zur zeit:
    -client-server sammeln lokal ihre daten und pushen diese an eine sql datenbank auf dem loadbalancing server
    -ein skript auf dem lb server errechnet anhand dieser daten die geeignetste kiste für den nächsten request (und gibt das ergebnis zum beispiel wieder an eine datenbank weiter)
    -der loadbalancer greift im fall eines request auf diese datenbank zurück und gibt die ip des ausgewählten client zurück
    der loadbalancer an sich soll also im grunde wie ein dns nameserver fungieren. was haltet ihr von dem ansatz? mein problem würde sich damit auf das aufsetzen des nameservers beschränken und die integration der gewichtungslogik dahinein.
    ist es vielleicht möglich zum beispiel apache als nameserver laufen zu lassen (die frage hab ich glaube schonmal gestellt aber ich bin noch nicht viel weiter bei dem thema ;) ) ? ich werd mich auf jeden fall mal intensiver mit http und apache auseinandersetzen.
    was den vorschlag von MADxHAWK angeht, ich habe deinen link ehrlich gesagt nur überflogen da ich a) nicht soooo viel davon verstanden habe ;) und ich b) McCavity´s antwort gelesen hatte, nachdem es sich bei ultra monkey scheinbar um sowas wie einen reverse proxy handelt. das ist ungeeignet in meinem fall, da ich auf dem rückkanal viel bandbreite brauche und daher um einen direct return nicht drumrumkomme. aber danke für den einwurf :)
     
  23. fresssh

    fresssh Benutzer

    update:
    bin im zuge meiner recherche auf den BIND server gestoßen, der wohl der verbreitetste dns server im netz ist. zum thema weighted dns rr habe ich dann folgendes gefunden:
    https://lists.isc.org/pipermail/bind-users/2007-April/066195.html
    nun hab ich mir die doku zu bind noch nicht zu gemüte geführt und bin außerdem was dns angeht nicht sehr tiefgreifend informiert, wie ihr vielleicht schon gemerkt habt ;) . meine idee ist jetzt folgende: ich könnte doch die ip´s dynamisch von meinem gewichtungs-skript in die tabelle eintragen lassen, sagen wir in einem intervall von maximal 5 minuten. klingt das vernünftigund vor allem machbar? :)
    grüße
     
  24. caraoge

    caraoge Benutzer

    Mit DNS bringt dir gar nix.
    Wenn der ISP deiner Hörer trotz gesetzem TTL einfach einen anderen TTL auf sein Cache setzt haut das nicht hin.

    Die einzige Möglichkeit ist die die ich genannt habe mit einem Script.
    Dann hast du immer die gleiche URL und bestimmst einfach mittels Script die Auslastung und gibts je nachdem den entsprechenden Stream aus.

    Vergiss DNS Loadbalancing, Hardwareauslastung, etc. Es zählt ausschließlich die Bandbreite der Server. (1 Gbit/s Netzwerkanschluss heisst nicht dass diese auch verfügbar sind. Meist ist bei 100Mbit/s Schluss. Gute Server mit 1 Gbit/s bekommste für 200-400 Euro/Monat).
     
  25. fresssh

    fresssh Benutzer

    hey
    also das mit dem cache ttl seitens der isp ist natürlich ungünstig..aber hätte ich das problem dann nicht generell bei einer zentralen loadbalancing lösung? die einzige alternative die ich mir vorstellen könnte wäre dann bei request an server a: auslastung des servers prüfen, wenn ausgelastet -> weiterleitung des request an den nächsten server, wenn nicht ausgelastet -> stream zurückgeben... oder wie könnte man das sonst umgehen?
    außerdem wäre meine frage da noch: wie könnte ich so ein skript in mein system einbinden? ich hab noch keinen server aufgesetzt, deßhalb kenn ich mich nicht so aus was das angeht.
    zum thema bandbreite kann ich dir sagen das ist wirklich nicht der schwachpunkt in meinem system. weder verbindung noch if-dimensionierung der server sind auf "haushaltsgebrauch" ausgelegt. auch der letzte crash hat gezeigt dass dort nicht der flaschenhals liegt, in sachen bandbreite war noch luft nach oben.
     

Status des Themas:
Es sind keine weiteren Antworten möglich.

Diese Seite empfehlen