Wir DDOSen uns selber - Keine Installation möglich bei running tasks--> Loadbalancing?

[Alukartfahren]

Hallo,

Frage: Gibt es irgendeine Form von Loadbalancing für den Opsi Server bzw kann man einen zweiten dabei packen?

Umfeld: ca 600 clients, SQL backend aktiv

Wir haben folgendes Problem:
Immer tagsüber um die gleiche Zeit lassen wir silent runs auf allen clients laufen, dabei macht er hard-software invent, wir verteilen unser CI, prüfen, ob lokale Admins auf den clients existieren und passen falls nötig die lokale opsiclientconfig an. Die Pakete hierzu sind okay, auf einem Einzelclient geht alles super durch und ist zügig fertig, was schon mal länger dauert ist hardware software audit.
Grundsätzlich sind wir nicht mit den Ergebnissen zufrieden, die die dailytasks liefern, in masse über mehrere Tage kriegen wir einen großteil, aber da müsste mehr zurück kommen, so dass wir denken, dass wir uns durch die Vielzahl von Rückmeldungen an den opsiserver hier selber lahmlegen. Was diese Vermutung stützt: In der Zeit der Tasks ist die Serverlast hoch (aber nicht kritisch hoch) und es können keine anderen anderen Tasks ausgeführt werden. Wenn ich also einem Client, der bereits fertig ist ein Paket on demand zuweise, dann läuft er sehr häufig in einen Timeout. Also nach 30 Sekunden geht das Popup weg, er schafft es nicht, den Opsi Server zu erreichen. Unser Netzwerk ist gut, größtenteils besteht gigabit anbindung, performance vom Server sollte doch auch reichen, oder? 12 GB RAM, 6 Intel(R) Xeon(R) CPU E5-2640 0 @ 2.50GHz (vmware).
Ähnliche Probleme haben wir auch bei nächtlichen patchaktionen.
Opsi-Version: 4.0.7.45
Danke für Info und Denkanstöße.

[uncle_scrooge]

Zur Frage:
Da es prinzipbedingt nur einen Config-Server gibt/geben kann, wird load balancing, bzw., beistellen eines weiteren Config-Servers schwierig.
Aber uib wird mich vielleicht korrigieren.

Bis dahin würde ich mir mal den Server genauer ansehen.
Wird MySQL wirklich genutzt? Sprich, sehe ich Aktivität in der DB?
Wie sieht die Performance der Platte aus?
Entweder über vSphere nachsehen (Performance -> Disk/Datastore/Virtual Disk). Wenn Du da hohe Latenzwerte hast, ist Dein Plattensubsystem zu langsam.
Und/oder auf der Maschine selber mit sar (aus SYSSTAT-Tools). Wenn Du da hohe IOWait-Werte hast, bremst Dich auch die Platte aus.

..ist die Serverlast hoch (aber nicht kritisch hoch)..
Definiere hoch. Besser noch, teile uns mal die load-Werte mit.
Und welcher Prozess genau treibt die Last hoch?

[pandel]

Da du 600 Clients hast, hast du ja auch mehrere Subnetze. Wenn du jetzt in jedes Subnetz einen opsi Server stellst und diese zu reinen Softwaredepots machst, dann kannst du mittels dynamischer Depotauswahl dafür sorgen, dass sich die Clients nach Möglichkeit immer das Depot aus ihrem Subnetz holen. Dazu musst du am Client in den Host-Parametern den Wert clientconfig.depot.dynamic auf True setzen. Das sollte zumindest eine gewisse Lastverteilung bewirken, wenn sie loslaufen...

Mit "opsi-setup --register-depot" bekommst du den Slave am Master registriert...

Wir haben beispielsweise 19 Filialen. In jeder steht ein BananaPi als Softwaredepot, die Clients hängen konfigurationsseitig alle am zentralen Konfigserver. So können wir Aufträge zentral über einen Server anstoßen, die Clients nutzen aber ihr jeweils lokales Depot und schonen so die Leitung und die Serverauslastung. Vielleicht hilft dir das was...

siehe auch: http://download.uib.de/opsi4.0/doc/html ... l-dyndepot

[uncle_scrooge]

Ahem?

..dabei macht er hard-software invent..

Ich dachte immer, swaudit/hwaudit gehen direkt an den Config-Server.
Werden die Daten wirklich auf den Depots zwischengespeichert und dann en bloc an den Config-Server geschickt?

Ich schätze, gerade hwaudit/swaudit bricht ihm irgendwie das Genick.

[pandel]

Das ist eben die große Frage, denke ich, was ihm da GENAU das Genick bricht! 600 Rechner, die auf eine Maschine einen CIFS Connect machen, um sich das hwinvent/swinvent Scriptzeugs zu holen, etc. ist auch nicht ohne! Ich denke durchaus, dass eine Verteilung beim Skriptanlauf schon eine Lastverbesserung bringt...

Die rückgelieferten Daten werden per opsiServiceCall an den Konfigserver geschickt, soweit ich weiß. Das erfolgt logischerweise nicht erst auf die Depots und dann en bloc weiter, aber das ist via JSON und auch da rechne ich dem Konfigserver mehr Leistungschancen aus, als bei CIFS. Meiner Meinung nach ist und bleibt das ein Nadelöhr mit dem ganze Overhead im SMB Protokoll...

Ist aber natürlich, ohne es genauer zu beleuchten, alles nur mein Bauchgefühl

[feltel]

Bei 600 Clients, die an einem Server hängen würde ich auch vom Bauchgefühl sagen, das da das eine oder andere Nadelöhr existiert. Ich würde hier auch mehrere Depots empfehlen; es kann ja bei einem Configserver bleiben, das ist ja davon unabhängig. Man könnte die Situation sicher auch etwas entzerren, wenn man die Clients irgendwie gruppiert und dann nicht alle auf einmal loslegen lässt, sondern vielleicht in Tranchen zu 100 Clients o.ä. Und wenn dann so eine Gruppe zehn Minuten nach der anderen mit den Audits loslegt, dann dürfte die vorherige i.d.R. schon durch sein.

[n.wenselowski]

Hi,

Frage: Gibt es irgendeine Form von Loadbalancing für den Opsi Server bzw kann man einen zweiten dabei packen?

Ja, wir bieten sowas als Scalability an.
Wenn ich allerdings lese, dass ihr nur 600 Clients habt, sieht es für mich aus als würde man mit Kanonen auf Spatzen schießen. Es wird sicher helfen, aber die Frage ist, ob das eine dauerhafte Lösung sein wird. Ich würde anders vorgehen... (s.u.)

Umfeld: ca 600 clients, SQL backend aktiv

Wir haben folgendes Problem:
Immer tagsüber um die gleiche Zeit lassen wir silent runs auf allen clients laufen, dabei macht er hard-software invent, wir verteilen unser CI, prüfen, ob lokale Admins auf den clients existieren und passen falls nötig die lokale opsiclientconfig an. Die Pakete hierzu sind okay, auf einem Einzelclient geht alles super durch und ist zügig fertig, was schon mal länger dauert ist hardware software audit.
Grundsätzlich sind wir nicht mit den Ergebnissen zufrieden, die die dailytasks liefern, in masse über mehrere Tage kriegen wir einen großteil, aber da müsste mehr zurück kommen, so dass wir denken, dass wir uns durch die Vielzahl von Rückmeldungen an den opsiserver hier selber lahmlegen. Was diese Vermutung stützt: In der Zeit der Tasks ist die Serverlast hoch (aber nicht kritisch hoch) und es können keine anderen anderen Tasks ausgeführt werden. Wenn ich also einem Client, der bereits fertig ist ein Paket on demand zuweise, dann läuft er sehr häufig in einen Timeout. Also nach 30 Sekunden geht das Popup weg, er schafft es nicht, den Opsi Server zu erreichen. Unser Netzwerk ist gut, größtenteils besteht gigabit anbindung, performance vom Server sollte doch auch reichen, oder? 12 GB RAM, 6 Intel(R) Xeon(R) CPU E5-2640 0 @ 2.50GHz (vmware).
Ähnliche Probleme haben wir auch bei nächtlichen patchaktionen.

Der Titel fasst es vermutlich gut zusammen: wenn ihr alle Clients auf einmal auf den opsi-Server loslasst, dann hat der eine Menge zu tun.
Das einfachste ist vermutlich den DDoS-Effekt zu minimieren und dafür zu sorgen, dass nicht alle Clients auf einmal anfragen. Ist das nicht möglich, dann wird Scalability schon wieder interessant.

Man könnte die Timeouts für Verbindungen drastisch erhöhen, aber in vielen Fällen halte ich das auch nur für eine Problemvermeidung und keine Behebung der Ursache.
Das wichtigste ist raus zu finden was genau so lange blockiert! Wenn man das weiß, kann man gezielt diese Probleme angehen. Für den opsiconfd liefert die Info-Page oftmals gute Ansätze, aber ich würde dennoch andere Teile des Servers (bspw. IO, Datenbank, ...) nicht außen vor lassen.
Hier sei mir der Hinweis auf unseren Support gestattet, der bei Performance-Problemen gerne und unkompliziert weiterhilft.


Viele Grüße

Niko

[Alukartfahren]

Danke an alle, wir versuchen das Ganze zunächst etwas zu verteilen.