Wie man den WAN-Modus beschleunigen könnte

Antworten
Benutzeravatar
skranz1982
Beiträge: 80
Registriert: 09 Okt 2014, 08:01

Wie man den WAN-Modus beschleunigen könnte

Beitrag von skranz1982 »

Hallo allerseits,

mir ist gerade durch den Kopf gegangen, dass der Caching Prozess des WAN-Modus' nicht besonders optimal läuft: Jede Datei wird einzeln vom Depot an den Client übertragen, was auch bedeutet, dass jedes Mal Overhead durch Header/Footer etc. entsteht, richtig? Wäre es da nicht sinnvoller, ein Archiv zu übertragen, wie zB die .opsi-Dateien aus dem Repository? So hätten man nur einmal den Overhead für den Dateitransfer anstelle von vielen Dateien (zB 37 Stück beim Paket "firefox" oder 61 Stück beim Paket "acrobat reader dc classic" aus dem StdAbo ). Lässt sich das vielleicht jetzt schon konfigurieren und ich weiß es bloß noch nicht?

Verregnete Grüße aus dem Bergischen Land,
Sebastian
Sebastian Kranz,
regio iT gesellschaft für informationstechnologie mbh
www.regioit.de
Benutzeravatar
ueluekmen
uib-Team
Beiträge: 1939
Registriert: 28 Mai 2008, 10:53

Re: Wie man den WAN-Modus beschleunigen könnte

Beitrag von ueluekmen »

Hallo Sebastian,

ich versuche mal darauf zu antworten. Ja, es stimmt wohl, dass man das WAN-Modul hier optimieren kann. Uns ist auch bewusst, dass man dadurch vielleicht mehr Geschwindigkeit rauskitzeln kann. Aber der Aufwand, den man dafür betreiben muss steht im Moment in keinem Verhältnis. Man müsste die Pakete als Archiv auf dem Server liegen haben. Das widerspricht komplett der Depot-Logik, wie Sie im Moment implementiert ist. Ein weiteres Problem wäre die Post- und Pre-inst Sektionen der Pakete. Beim installieren der Pakete läuft in der Regel ja auch noch anderer Kram durch. Das betrifft im übrigen nicht nur die netboot-Pakete sondern auch viele localboot-Pakete. So einfach, wie sich das in der Idee anhört ist es leider dann doch nicht.

Ich kann dich aber beruhigen, du hast nicht etwas verpasst, weil es so eine Möglichkeit im Moment nicht gibt.

Wir haben dazu ein Diskussionsticket, aber das ist nicht so hoch priorisiert. Weil der Nutzen nur gering ist. Wenn das Paket initial gecashed wird hast du absolut Recht, aber bei einer Änderung vom setup-Skript und einer neuen setup.exe (das ist ja normalerweise der Update-Prozess eines Pakets) ist das verfahren so wie es jetzt ist in vielen Teilen schneller, als ein Paket zu übertragen. Rsync über http(s) haben wir ja jetzt auch schon implementiert und das birgt auch die Gefahr von overhead, der vielleicht nicht gebraucht wird. Aber vielleicht haben ja noch andere User hier eine Meinung zu. Wir sind wie immer gerne bereit zu diskutieren.
opsi support - uib gmbh
For productive opsi installations we recommend support contracts.
http://www.uib.de
Benutzeravatar
skranz1982
Beiträge: 80
Registriert: 09 Okt 2014, 08:01

Re: Wie man den WAN-Modus beschleunigen könnte

Beitrag von skranz1982 »

ueluekmen hat geschrieben:Hallo Sebastian,

ich versuche mal darauf zu antworten. Ja, es stimmt wohl, dass man das WAN-Modul hier optimieren kann. Uns ist auch bewusst, dass man dadurch vielleicht mehr Geschwindigkeit rauskitzeln kann. Aber der Aufwand, den man dafür betreiben muss steht im Moment in keinem Verhältnis. Man müsste die Pakete als Archiv auf dem Server liegen haben. Das widerspricht komplett der Depot-Logik, wie Sie im Moment implementiert ist. Ein weiteres Problem wäre die Post- und Pre-inst Sektionen der Pakete. Beim installieren der Pakete läuft in der Regel ja auch noch anderer Kram durch. Das betrifft im übrigen nicht nur die netboot-Pakete sondern auch viele localboot-Pakete. So einfach, wie sich das in der Idee anhört ist es leider dann doch nicht.
Einfach wäre ja auch langweilig ;-) Ich hab mich aber nur auf den Caching-Prozess beziehen wollen - also auf die reine Übertragung der Dateien vom Management Server zum Client. Wieso ist mir das so wichtig? Weil viele unserer WAN-Clients hinter 2-6MBit-Leitungen (in Worten: zwei bis sechs) hängen und mir da jede Optimierung willkommen ist.
ueluekmen hat geschrieben:Ich kann dich aber beruhigen, du hast nicht etwas verpasst, weil es so eine Möglichkeit im Moment nicht gibt.
Fein.
ueluekmen hat geschrieben:Wir haben dazu ein Diskussionsticket, aber das ist nicht so hoch priorisiert. Weil der Nutzen nur gering ist. Wenn das Paket initial gecashed wird hast du absolut Recht, aber bei einer Änderung vom setup-Skript und einer neuen setup.exe (das ist ja normalerweise der Update-Prozess eines Pakets) ist das verfahren so wie es jetzt ist in vielen Teilen schneller, als ein Paket zu übertragen.
Jau, gutes Argument. Daran hatte ich nicht gedacht. Lässt sich das vielleicht splitten? Wie du (quasi) vorschlägst: Bei der Erstübertragung archiviert und danach nur noch einzelne Dateien bei Bedarf austauschen? Bleibt natürlich die Frage, welcher Aufwand hier welchem Nutzen gegenüber steht.
ueluekmen hat geschrieben:Rsync über http(s) haben wir ja jetzt auch schon implementiert und das birgt auch die Gefahr von overhead, der vielleicht nicht gebraucht wird. Aber vielleicht haben ja noch andere User hier eine Meinung zu. Wir sind wie immer gerne bereit zu diskutieren.
Und dat find ich super!
Sebastian Kranz,
regio iT gesellschaft für informationstechnologie mbh
www.regioit.de
Benutzeravatar
n.wenselowski
Ex-uib-Team
Beiträge: 3194
Registriert: 04 Apr 2013, 12:15

Re: Wie man den WAN-Modus beschleunigen könnte

Beitrag von n.wenselowski »

Hi,

eine Sache die aktuell noch gegen das Verteilen kompletter .opsi-Files spricht will ich nicht unerwähnt lassen: manche von ihnen enthalten Links, die wiederum auf andere Pakete verweisen. Für so etwas müsste sich dann auch ein entsprechender Umgang überlegt werden.

Je nachdem was übertragen wird wäre Kompression noch ein Ansatz, aber meiner Erfahrung nach sind oftmals gerade die großen Teile von Installationen nach schlecht komprimierbar (bspw. bereits kompilierte Daten) oder der Aufwand für eine geringere Dateigröße steht in keinem guten Verhältnis.



Viele Grüße

Niko

Code: Alles auswählen

import OPSI
Antworten