Problem mit on_demand Event

[ueluekmen]

Hallo,

maxConnections reicht im Regelfall eigentlich aus, das beeinflusst nur, wieviele das hostControl gleichzeitig beschiesst. Ich verstehe das Problem hier ander:

Das Event scheint ja durch zu gehen. Das sieht gar nicht problematisch aus. Das Problem scheint zu sein, was im Event selbst passiert. Bedeutet, der Client wird aktiv und nimmt dann Connect mit dem Service auf. Und dort findet dann ein Timeout statt?! Das sollte man genauer untersuchen. Man kann sollte sich mal von diesen Clients die info-Page anschauen, vielleicht läuft auch was anderes schief. Man sollte auch zur gleichen Zeit die info-Page vom Server sich mal anschauen, ob es Lastspitzen oder nicht.

Mit dem mysql-Backend sollte der diese Clientanzahl verkraften, vielleicht ist da auf dem Weg noch was anderes schief. Netzwerk, Festplattenperformance, etc...

Aber ohne genauere Analyse, schwer zu sagen.

[damien.leviet]

Hallo ueluekmen,

also ich bin mir auch ziemlich sicher, dass der erste Kontakt zu den Clients durchgeht, da ich auch z.b. über iftop auf dem Server die einzelnen Verbindungen sehen kann.

Schaue ich auf meinen Testclient (der zusammen mit 50 anderen Maschinen gleichzeitig ein on_demand erhalten soll) sehe ich ebenfalls das OPSI Fenster und den Versuch, eine Verbindung mit dem Server aufzubauen.

Jetzt fängt der Timer an abzulaufen (momentan sind es 20 Sekunden) und das tut er leider auch bis er 0 erreicht hat.

In der Zwischenzeit bemerke ich auf dem opsi server via top, dass der Prozess opsiconfd eine ungewöhnlich hohe CPU Last aufweist:

Code: Alles auswählen

PID       USER      PR  NI  VIRT  RES     SHR  S %CPU %MEM  TIME+    COMMAND
10622  opsiconf  20  0  642m  328m  4884  S  105  16.3  48:13.94  opsiconfd

Anbei auch noch die Ausgabe von der opsiconfd info Seite. Um ca 13:42 habe ich ein on_demand Event an 50 Clients verschickt:



EDIT: Auf einem fehlgeschlagenen Client habe ich die daemon info Seite mit der Timeline geöffnet. Hier fand ich folgendes:

Code: Alles auswählen

Failed to process event on_demand
Failed to process event : Failed to connect to config service 'https://<server-ip>:4447/rpc': timed out after 20 seconds

Gruß
Damien

[ueluekmen]

Dann setz doch mal die connection_timeout auf 30 Sekunden. Wir haben das schon mal erlebt, dass er genau ein oder zwei Sekunden mehr benötigt als normal.

Die Frage ist auch, wie gut deine Maschine performed und wie dein Netzwerkdurchsatz ist, wie schnell die Clients an den Server angebunden sind, etc.

Im Regelfall reichen so 10-20 Sekunden für ein normales internes LAN, wenn du aber mehrere Hops zwischen Server und Clients hast, dann musst du das schon mit einkalkulieren.

Wie sieht deine dispatch.conf aus?

[damien.leviet]

Dann setz doch mal die connection_timeout auf 30 Sekunden. Wir haben das schon mal erlebt, dass er genau ein oder zwei Sekunden mehr benötigt als normal.

Das war die Einstellung vor wenigen Monaten - damals war das Problem aber auch schon präsent.
Ich habe auf 20 Sekunden reduziert, um gerade die Laptopnutzer zu entlasten, wenn sie sich mit den Geräten außerhalb des Firmennetzes befinden.

Die Frage ist auch, wie gut deine Maschine performed und wie dein Netzwerkdurchsatz ist, wie schnell die Clients an den Server angebunden sind, etc.

Der Server befindet sich als virtuelle Maschine auf unseren vCenter Clustersystem, welcher mit Gigabit angebunden ist.
Im Haus selber sind unsere Switche mit Gigabit untereinander angebunden; die Clients an den Switchports jeweils mit 100 Mbit

Im Regelfall reichen so 10-20 Sekunden für ein normales internes LAN, wenn du aber mehrere Hops zwischen Server und Clients hast, dann musst du das schon mit einkalkulieren.

All unsere Clients sind direkt über unseren Coreswitch (maximal einen Hop) verbunden. Ich glaube kaum dass der Durchsatz ein Problem darstellen sollte

Wie sieht deine dispatch.conf aus?

Bitte

Code: Alles auswählen

backend_.*         : mysql, opsipxeconfd, dhcpd, mysql
host_.*            : mysql, opsipxeconfd, dhcpd
productOnClient_.* : mysql, opsipxeconfd
configState_.*     : mysql, opsipxeconfd
license.*          : mysql
softwareLicense.*  : mysql
audit.*            : mysql
.*                 : file

[ueluekmen]

Hallo Damien,

aaallssooo... ich fang mal von unten an

Code: Alles auswählen

backend_.*         : mysql, opsipxeconfd, dhcpd, mysql
host_.*            : mysql, opsipxeconfd, dhcpd
productOnClient_.* : mysql, opsipxeconfd
configState_.*     : mysql, opsipxeconfd
license.*          : mysql
softwareLicense.*  : mysql
audit.*            : mysql
.*                 : file

Das ist quatsch... die sollte so aussehen:

Code: Alles auswählen

backend_.*         : mysql, opsipxeconfd, dhcpd
host_.*            : mysql, opsipxeconfd, dhcpd
productOnClient_.* : mysql, opsipxeconfd
configState_.*     : mysql, opsipxeconfd
license.*          : mysql
softwareLicense.*  : mysql
audit.*            : mysql
.*                 : mysql

Danach schon mal ein:

Code: Alles auswählen

opsi-setup --init-current-config

und die Dienste neustarten.

Da jetzt aber einige Methoden ins falsche Backend gegangen sind, könnte es sein, dass dir Informationen verloren gehen. Zwar nicht sehr warhscheinlich, aber ich will es trotzdem mal erwähnen.

Wenn du deine Notebooknutzer entlasten willst, dann solltest du nicht den Timeout runtersetzen, sondern diesen Clients zusätzlich zu dem normalen Timeout noch die Option:

opsiclientd.config_service.user_cancelable_after, so auf 10 setzen. Dann können die User, die Wissen, dass Sie nicht im Firmennetz sind, den Connect nach 10 Sekunden selber abbrechen. Dieser Wert muss halt kleiner sein als der normale Timeout, dann wird der "ausgegraute" Button beim Connect nach 10 Sekunden aktiv und kann zum abbrechen vom Benutzer betätigt werden.

Und mit einer opsi-Schulung, bekommst du noch viel mehr Informationen, die dir einige graue Haare ersparen würden.

[damien.leviet]

Morgen,

Setze ich aber .* auf mysql, dann sind im Config Editor der Inhalt von den Spalten Produktkonfiguration und Netboot Produkte nicht mehr vorhanden - ich weiß klingt komisch aber das ist wirklich so!

Die Produktzustände holt sich OPSI aber definitiv aus der MySQL Datenbank, da er dort die Zustände ändert, wenn ich im Config Editor was verändere - hast du eine Idee was da los sein könnte?

Da jetzt aber einige Methoden ins falsche Backend gegangen sind, könnte es sein, dass dir Informationen verloren gehen. Zwar nicht sehr warhscheinlich, aber ich will es trotzdem mal erwähnen.

Würde aber wenig Sinn machen, da sämtliche Kommunikation mit dem Server letztenendes über dem Dienst opsiconfd abgewickelt wird und eben jener Dienst mit dem ersten Handshake bei mehrere Clients Probleme zu haben scheint - afaik wird doch erst danach auf die Backends zugegriffen, oder nicht?

Wenn du deine Notebooknutzer entlasten willst, dann solltest du nicht den Timeout runtersetzen, sondern diesen Clients zusätzlich zu dem normalen Timeout noch die Option:

opsiclientd.config_service.user_cancelable_after, so auf 10 setzen. Dann können die User, die Wissen, dass Sie nicht im Firmennetz sind, den Connect nach 10 Sekunden selber abbrechen. Dieser Wert muss halt kleiner sein als der normale Timeout, dann wird der "ausgegraute" Button beim Connect nach 10 Sekunden aktiv und kann zum abbrechen vom Benutzer betätigt werden.

Ok das klingt gut, werde ich mal ausprobieren

Und mit einer opsi-Schulung, bekommst du noch viel mehr Informationen, die dir einige graue Haare ersparen würden.

OPSI erspart mir jetzt schon so einige graue Haare


MfG
Damien

[ueluekmen]

Hallo Damien,

ich wollte es eigentlich nicht erklären, um die Antwort nicht unnötig auf zu blähen. Ich versuchs mal in kürze zu erklären:

Die Dispatch.conf wird, wie der Name schon sagt, zum dispatchen der Backends verwendet. Dies findet zum einen Sequentiell statt und zum anderen mit Regular Expressions. Wenn eine Methode aufgerufen wird, sagt der dispatcher, welche Backends diesen Aufruf bekommen. Bei host_getObjects zieht die Regel: host_.*, wenn keine Regel passt, zieht immer die Regel .*.

dann sind im Config Editor der Inhalt von den Spalten Produktkonfiguration und Netboot Produkte nicht mehr vorhanden

Das ist einfach zu erklären, bei dir gehen zum Beispiel productOnDepot oder productProperty oder productPropertyState Methoden ins File-Backend. Deshalb ist dein Backend momentan in zwei Teile geteilt. Das kostet natürlich auch performance.

Jetzt ist es vielleicht klarer.

[damien.leviet]

Hallo Damien,

ich wollte es eigentlich nicht erklären, um die Antwort nicht unnötig auf zu blähen. Ich versuchs mal in kürze zu erklären:

Die Dispatch.conf wird, wie der Name schon sagt, zum dispatchen der Backends verwendet. Dies findet zum einen Sequentiell statt und zum anderen mit Regular Expressions. Wenn eine Methode aufgerufen wird, sagt der dispatcher, welche Backends diesen Aufruf bekommen. Bei host_getObjects zieht die Regel: host_.*, wenn keine Regel passt, zieht immer die Regel .*.

Das war mir vollkommen klar, aber ...

dann sind im Config Editor der Inhalt von den Spalten Produktkonfiguration und Netboot Produkte nicht mehr vorhanden

Das ist einfach zu erklären, bei dir gehen zum Beispiel productOnDepot oder productProperty oder productPropertyState Methoden ins File-Backend. Deshalb ist dein Backend momentan in zwei Teile geteilt. Das kostet natürlich auch performance.

Jetzt ist es vielleicht klarer.

... dann verstehe ich nicht, warum er mir gar nichts mehr anzeigt

Wie kann ich das denn lösen? Das war ja die eigentliche Frage

EDIT: Offenbar ist bei der Migration von file nach mysql was schief gegangen - Die Tabellen
PRODUCT
PRODUCT_DEPENDENCY
PRODUCT_ON_DEPOT
PRODUCT_PROPERTY
PRODUCT_PROPERTY_VALUE

sind leer - gibt es eine einfache Lösung, diese Daten alleine nochmal zu migrieren?

EDIT2: Hat sich erledigt. Hab nochmal opsi-convert ausgeführt


MfG
Damien