QoS-Netzwerk
geschrieben am 24.04.2006 um 09:04 von DarkGuardian (Gast)
Hallo zusammen
Ich bin dabei, mich für ein spezielleres Netzwerk zu informieren. Daher hoffe ich, dass mir hier entsprechende Informationen geschrieben werden können.
Es soll sich dabei um ein IP-basiertes Netzwerk handeln, welches live-Streams an Clients sendet. Dafür benötige ich QoS. Zudem sollen auch normale PCs an das Netzwerk angeschlossen werden können, damit die Infrastruktur des Netzes (Kabel, Switches usw.) nicht doppelt verlegt werden muss.
Nun habe ich inzwischen erfahren, dass QoS nur über entsprechende
Hardware realisierbar ist (also nicht auf reiner Protokollebene). Daher stellt sich mir die Frage, ob es reicht, dass alle Switches und Router sowie die Server dieses bieten. Kann ich dann allen "normalen" IP-Paketen die übrige Bandbreite zur Verfügung stellen? Können die PCs normale Netzwerkkarten nutzen oder müssen diese speziell für QoS sein?
Ich hoffe, dass ihr mir dazu Tipps und Erfahrungen posten könnt.
geschrieben am 27.04.2006 um 21:42 von Mirko
Hallo,
schön Dich hier zu sehen. Wir hatten das Thema ja bei spotlight schon mal angeschnitten.
So richtig verstehe ich noch nicht, was Du möchtest. Du hast eine Anwendung die Daten streamt. Über welches Protokoll? Ist das Multicast?
Sollen die Empfänger des Stream auch andere Anwendungen im Netz nutzen oder nur den Stream empfangen?
Wie ist das Netz aufgebaut? Über wieviele Hops soll QoS realisiert werden?
Gruß
Mirko
geschrieben am 03.05.2006 um 11:13 von (Gast)
Hallo
Leider komme ich erst jetzt wieder dazu, mich mit diesem Projekt zu befassen, da ein anderes zum Monatswechsel fertig werden musste.
In diesem Projekt will ich ein Netzwerk in einer Heimanwendung (also eher Privatanwender) nutzen, welches QoS bietet. Dabei werden Streams von verschiedenen Servern an Clients geschickt. Dieses kann sowohl uni- als auch multicast geschehen. Zudem können diese Clients keine anderen Anwendungen nutzen.
Als Einschränkung soll das Netzwerk aber auch den normalen IP-Verkehr für PCs zur Verfügung stellen, damit das Netzwerk nicht doppelt verlegt werden muss.
Dabei soll nur die nicht genutzte Bandbreite für diesen normalen IP-Verkehr genutzt werden können. Die Streams haben dabei absoluten Vorrang.
Nun weiß ich noch nicht, welches Protokoll dafür am sinnvollsten ist. Zudem bin ich mir nicht sicher, ob es überhaupt realisierbar ist, wenn die PCs normale Netzwerkkarten nutzen.
Der Aufbau des Netzwerks steht noch nicht endgültig fest. Es gibt halt Server (1 bis x) und Clients. In meinen Augen ist aber der größte Knackpunkt die PCs, die TCP/IP im gleichen Netzwerk nutzen können sollen.
Ich hoffe, dass du nun eher verstehst, was ich meine.
geschrieben am 03.05.2006 um 11:50 von DarkGuardian (Gast)
Natürlich ist der Beitrag oben von mir.
geschrieben am 07.05.2006 um 16:44 von Mirko
Wenn es sich um ein kleines Netzwerk handelt, sollte die Realisierung kein Problem darstellen. Für die von Dir beschriebene Anwendung, reicht ein Switch der QoS unterstützt.
Da es ja lediglich um Streams geht, die vom Server zu den Clients übertragen werden sollen, muss der Switch nur diesen Traffic priorisieren. Der Traffic von den PCs ins Netz stört die Streams ja nicht.
Als Kriterium für die Klassifizierung am Switch kannst Du die Absender-MAC-Adresse, Absender-IP-Adresse oder die Portnummer nutzen.
Mirko
geschrieben am 08.05.2006 um 08:21 von DarkGuardian (Gast)
Danke erst einmal für den Hinweis. Dann steht ja der Umsetzung anscheinend nichts Großes im Wege zu stehen.
Kannst du mir denn ein Protokoll empfehlen, welches ich in diesem Netzwerk nutzen kann? Oder reicht dafür TCP/IP aus, da die Switches nur nach MAC, IP oder Port priorisieren?
geschrieben am 11.05.2006 um 19:50 von Mirko
Für Dein Vorhaben bietet sich IP/UPD eigentlich an.
Die Untertsützung von QoS für nicht-TCP/IP-Protokolle ist auch nicht so verbreitet.
Mirko
geschrieben am 15.05.2006 um 08:36 von DarkGuardian
Danke für den Tipp. Ich werde mir das mal ansehen.
>>> Die Untertsützung von QoS für nicht-TCP/IP-Protokolle ist auch nicht so verbreitet.
Aber der Rest soll im Netzwerk schon über das normale TCP/IP laufen. Oder habe ich dich falsch verstanden? Denn wenn es geht, würde ich auch nur TCP/IP nutzen und die QoS-Bandbreiten über die Switches und den Server regeln.
geschrieben am 17.05.2006 um 17:12 von Mirko
Schon richtig. Für alles TCP/IP nutzen.
Mirko
geschrieben am 01.06.2006 um 16:00 von derPENGUIN
QoS mit Linux
Hi, wenn Du Dich entschliessen kannst, den Traffic ueber einen Linuxrechner zu routen, ist QoS kein Problem, guckst Du hier: http://www.little-idiot.de/linuxsolutionguide/firewall-qos.htm. Als Streamserver fuer Deine Mediadaten wirst ja wohl ohnehin einen Linuxrechner hinstellen, denke ich, der koennte das gleich mit erledigen.
geschrieben am 17.06.2006 um 19:09 von bewa
Re: QoS mit Linux
Moin.
Hi, wenn Du Dich entschliessen kannst, den Traffic ueber einen Linuxrechner zu routen, ist QoS kein Problem, guckst Du hier: http://www.little-idiot.de/linuxsolutionguide/firewall-qos.htm.
Das ist der "sportliche" Ansatz. Auf jeden Fall zu empfehlen wenn man in diese Richtung dazu lernen möchte!
Eine andere Variante aus der Praxis sollte man aber auf jeden Fall auch betrachten - sie wird anfangs belächelt, ist aber oft ein durchaus betrachtenswerter Ansatz der auch in großen Netzen gut funktionieren kann, wie ich selbst schon bewundern konnte: Das sogenannte Overprovisioning. Auf gut deutsch: Schmeiss' deutlich mehr Bandbreite in den Ring als normalerweise gebraucht wird und du brauchst sehr oft auch kein spezielles QoS.
Beispiel: 100 MBit Access, Gigabit-Uplinks und Gigabit-Anbindung der Server - Bandbreite genug in einer mittleren Installation (dreistellige Clientanzahl) um neben normalen Büro-Applikationen (File-Server, Notes!) auch noch VoIP-en zu können, ohne die (Sprach-)Qualität zu beeinträchtigen.
Auf ein Heimnetz übertragen: Gigabit Switch, mindestens der Server mit Gigabit angebunden und auch in der Lage deutlich mehr als 100 MBit zu liefern (das wird oft unterschätzt!) und die Chancen stehen relativ gut, ohne QoS ein völlig ausreichendes Ergebnis zu erzielen. Wenn es der Geldbeutel erlaubt, kann man natürlich auch eine Nummer größer wählen und z.B. den Server mit 10GE anbinden. Spätestens dann braucht man aber auch einen Server, der viele Heimbudgets sprengen wird.
Unprofessionell? Nicht, wenn das Ganze wirklich durchdacht angegangen wird. Gibt es z.B. Clients die häufig untereinander oder mit einem Fileserver Daten kopieren, kann man diese (den Server ggf. mit einer dedizierten Karte) an einen Switch packen, damit der Rest des Netzes davon gar nicht gestört wird, usw. die eingesparte Komplexität vieler QoS-Lösungen ist dabei ein nicht zu unterschätzender Vorteil - nur weil es neu ist, muss man das nicht unbedingt einsetzen. Ganz abgesehen davon, gibt es durchaus Szenarien in denen das Sinn machen kann.
Als Streamserver fuer Deine Mediadaten wirst ja wohl ohnehin einen Linuxrechner hinstellen, denke ich, der koennte das gleich mit erledigen.
Vorsicht, das ist dann aber wirklich stark experimentell. Bei dieser Lösung müsste ja sämtlicher LAN-Verkehr über diesen Server, der dann neben Streaming auch noch QoS am Hals bzw. genauer gesagt an der CPU hat.
Erfahrung aus der Praxis: Sowas geht selten gut, wenn mit nennenswerter Last zu rechnen ist. Irgendwann braucht entweder in diesem Fall QoS soviel CPU, das es das Streaming beeinträchtigt, oder umgekehrt.
Ein anderer Punkt: Was für Server willst du einsetzen? Wenn das typisches Heimanwender-Zeug ist, bei dem z.B. Plattencontroller und Netzwerkkarten am gleichen PCI-Bus hängen, kann schon viel eher Schicht sein, je nachdem welche Art von Speicherzugriffen wo erfolgt.
Wenn du deine Anwendung genauer spezifizierst, (Clientanzahl, wieviel CPU-Last und Netzverkehr kostet ein Stream) kann man schon mehr sagen als nur durch die Glaskugel zu erraten, was du vorhast.
[ Dieses Thema im Live-Forum aufrufen ]
|
