-
Titel
KACE SMA Überlegungen zur Performance und Best Practices -
Beschreibung
KACE SMA Überlegungen zu Performance und Best Practices
Dieses Dokument erwähnt das AdminUI und das SystemUI der Systems Managemen Appliance (SMA) in Bezug auf den Aufgabendurchsatz. Um diese UI zu erreichen, wird einfach ein /adminui oder /systemui an die URL der SMA angehängt.
- AdminUI: https://SMA/adminui
- SystemUI: https://SMA/systemui
Hinweis: Wenn das SystemUI einer SMA mit nur einer einzigen Org erreicht werden soll, wird es einfach auf das AdminUI weitergeleitet. Dies ist geplant, da nur Multi-Org-Appliances einen Unterschied zwischen Einstellungen, die für die Org und Einstellungen, die global gelten, machen. In Multi-Org-Appliances existieren die Einstellungen sowohl global (in der SystemUI) als auch für die Organisationen einzeln (in der AdminUI der jeweiligen Org)Werden Performanceprobleme analysiert, ist es extrem wichtig die Symptome zu verstehen. Je besser das Problem beschrieben werden kann je besser und schneller ist der Support auch in der Lage hier zu helfen und sinnvolle Hinweise zu geben.
-
Lösung
Weitere Informationen zu diesem Thema sind hier zu finden: KACE-SMA Course 2 Installing the KACE SMA Agent-Web-based Training
Ebenso wurde ein Webinar mit dem KACE Support am 27. Oktober 2017 gehalten, wo Details dieses Artikels durchgesprochen wurden.
Ein Mitschnitt ist hier zu finden: https://support.quest.com/kb/234300Systemvoraussetzungen:
Zuerst ist sicherzustellen, dass die virtuelle Appliance die Minimalvoraussetzungen erfüllt bzw die Hardware aktuell supported ist.Virtuelle Appliance
https://www.quest.com/products/kace-systems-management-appliance
Specifications | Virtual Appliance Technical Specifications | Virtual machine system requirements
Hardware Appliance
https://www.quest.com/products/kace-systems-management-appliance
Specifications | Physical Appliance Technical Specifications | Hardware Specifications
Agentenintervalle
Multi-Org: SystemUI | Organisationen |Single-Org: AdminUI | Einstellungen | Provisionierung | Kommunikationseinstellungen
- empfohlene Maximalverbindungen pro Stunde ist 500 (über alle Agenten in ALLEN Organisationen)
- Idealerweise sollten alle Intervalle so konservativ wie möglich gesetzt werden. Beispiel: Wenn es nicht nötig ist, die Informationen häufiger als täglich zu aktualisieren, dann sollte die Inventarisierung nur einmal am Tag durchgeführt werden. Wird es in diesem Fall alle 4 Stunden durchgeführt, muss der Server mehr leisten, was sich negativ auf die Performance auswirken kann.
Einschränkungen des Apache-Webservers
Die SMA benutzt Apache für alle Agentenverbindungen und Webkonsolenaktivitäten. Apache hat ein fest eingebautes Limit von 800 aktiven Verbindungen. Diese Verbindungen sind typischerweise sehr schnell und nur temporär. Eine Webseite in der Webkonsole anzuzeigen kostet beispielsweise nur eine Verbindung, wenn die Seite angezeigt wird. Die längsten Verbindungen sind üblicherweise die Downloads von Dateien oder Nutzdaten durch die Agenten. Wird Apache überstrapaziert, hat dies üblicherweise diese Ursachen:- Zugriff auf die Benutzeroberfläche - Helpdesk-Benutzer und Administratoren haben Einfluss auf diesen Schwellenwert, indem sie die Web-Benutzeroberfläche ständig verwenden.
- Agentenintervalle - Zu häufige Einstellungen für Agentenintervalle können dazu führen, dass Apache sein Verbindungslimit maximal ausnutzt.
- Skripterstellung - Onlineskripte und ihre Nutzdaten werden von Agenten zur geplanten Laufzeit abgerufen. Wenn zu viele Onlineskripts zu häufig geplant werden, kann dies die Leistung der Benutzeroberfläche beeinträchtigen, die Aktivität des Agenten stoppen oder verzögern und im Allgemeinen die Serverleistung insgesamt beeinträchtigen.
- Patch-Zeitpläne - Patch-Zeitpläne werden ähnlich wie Online-Skripte ausgeführt, daher gelten hier die oben genannten Informationen zu Skripten.
Abhilfe und Prävention- Replikationsfreigaben - Replikationsfreigaben sind die beste Option zum Reduzieren des Agentenverkehrs zur und von der SMA. Durch das Auslagern der Arbeit beim Bereitstellen von Dateien an Agenten auf die Replikationsfreigaben wird der gesamte Datenverkehr, der für Skriptdownloads, Payloads, Patchdateien usw. an SMA gegangen wäre, für jeden für die Verwendung konfigurierten Agenten von der Replikationsfreigabe abgerufen.
- Agentenintervalle - Durch eine Verlängerung der Agentenintervalle können die Verbindungen pro Stunde verringert werden, um die Auswirkungen auf den Apache-Server für den SMA zu verringern.
ErkennungszeitpläneErkennungszeitpläne wirken sich nicht direkt auf die Agentenkommunikation oder die Leistung der Webbenutzeroberfläche aus, da sie Apache nicht einbeziehen. Aggressive Erkennungszeitpläne können sich jedoch spürbar auf die Gesamtleistung des Servers auswirken.Skript-Zeitpläne / Patch-ZeitpläneSkript- und Patch-Zeitpläne können sich direkt auf die Agentenkommunikation und die Leistung der Web-Benutzeroberfläche auswirken, da sie Apache betreffen. Aggressive Skript- oder Patch-Zeitpläne können sich spürbar auf die Gesamtleistung des Servers auswirken und Probleme bei der Agentenkommunikation und beim Zugriff auf die Benutzeroberfläche verursachen. Die beste Option zum Entfernen des größten Teils dieser Auswirkungen ist die Verwendung von Replikationsfreigaben. Aggressive Planung kann weiterhin Probleme mit Replikationsfreigaben verursachen, der Schwellenwert ist jedoch viel höher. Bei der Verwendung von Replikationsfreigaben liegt der wahrscheinlichste Grund für Durchsatzprobleme (z. B. nicht abgeschlossene Zeitpläne) in der Einstellung des Aufgabendurchsatzes.Offlineskripte sind auf dem Server von Natur aus weniger präsent. Beachten Sie, dass Offlineskripte die Leistung aufgrund des Hochladens von Ergebnissen beeinträchtigen können (wenn ein Offlineskript beispielsweise sehr häufig ausgeführt wird, können zusammengesetzte Uploads von Ergebnissen in großen Umgebungen die Apache-Threads tatsächlich maximal auslasten).Aufgabendurchsatz / Lastdurchschnitt- Multi-Org: SystemUI | Organisationen |
- Single-Org: AdminUI | Einstellungen | Provisionierung | Kommunikationseinstellungen
Der Aufgabendurchsatz ist ein Multiplikator, der vom Konductor-Dienst (dem "Gehirn" für Agentenaufgaben) auf der SMA verwendet wird. Der Standardwert 3 kann alle 15 Minuten um 1 Stufe erhöht werden. Er sollte jedoch nur erhöht werden, wenn der Lastdurchschnitt auf dem Server unter 10 bleibt und die Anzahl der "Ready to Run" -Tasks nicht eingehalten werden kann. Wenn der Server Tasks schnell genug sendet, um eine leere Warteschlange aufrechtzuerhalten, sollte dieser Wert nicht erhöht werden. Die niedrigste Einstellung, die in der Umgebung funktioniert, sollte verwendet werden.Die Anzahl der Gesamtaufgaben hängt von der Anzahl der Patch-Zeitpläne und Skripts ab, die auf der Anzahl der Agenten in der Produktion basieren. Das Agentenintervall wirkt sich auch darauf aus, wie oft mehrere dieser Aufgaben geplant und an alle Agenten gesendet werden. Dies wirkt sich wiederum auf die Gesamtanzahl der Aufgaben aus, die der Server an Agenten senden muss, und auf den für deren Ausführung erforderlichen Durchsatz.Der Aufgabendurchsatz sollte nicht über 5 erhöht werden, ohne den KACE Support zu konsultieren.Fehlerbehebung bei Agent-AufgabenKonductor Log- Multi-org: System-UI | Einstellungen | Protokolle
- Single-org: Admin UI | Einstellungen | Protokolle
[2017-10-23 17:21:57 -0500] Konductor [1384] [main] stats [s: 21874 t: 8 tc: 8 c: 8 cc: 738 sl: 30 tpl: 40 at: 399 rt: 400 lt: 3 lv: 0,31]- s = konductor war s Sekunden aktiv
- t = gestartete Aufgaben
- tc = erledigte Aufgaben
- c = erledigte aufgaben (wie tc)
- cc = Anrufe abgeschlossen (konductor aktualisiert die Aufgabenliste)
- sl = Schlafintervall in Sekunden (Verzögerung zwischen den Schleifen)
- tpl = Aufgaben, die von konductor pro Schleife verteilt werden
- at = aktive Threads (max. 400, Anzahl nimmt ab, wenn Threads verwendet werden)
- rt = reservierte Threads (max. 400, Anzahl verringert sich, wenn Threads verwendet werden)
- lt = Solllast (entspricht der aktuellen Taskdurchsatz-Einstellung)
- lv = tatsächliche Belastung der letzten 1 Minute (sollte niemals 10 überschreiten, je niedriger desto besser)
Status der Agentenaufgaben- Multi-Org: SystemUI | Einstellungen | Support | Aufgabenstatus des Agenten anzeigen
- Single-Org: AdminUI | Einstellungen | Support | Aufgabenstatus des Agenten anzeigen
- Alle Aufgaben - Zeigt alle Aufgaben in der Aufgabenwarteschlange des Agenten an
- In Bearbeitung - Zeigt alle Aufgaben an, die an nicht abgeschlossenen sind
- Bereit zur Ausführung (verbunden) - Zeigt Aufgaben an, die zur Ausführung bereit sind, wenn aktive Agenten verbunden sind und warten
- Bereit zur Ausführung - Zeigt Aufgaben an, die zur Ausführung bereit sind, die Agenten jedoch nicht verbunden sind
- Länger als 10 Minuten - Zeigt Aufgaben an, die länger als 10 Minuten ausgeführt wurden
- Aufgabentyp - Ermöglicht das Filtern basierend auf dem Aufgabentyp (z. B. Inventar, spezifisches Skript usw.).
- Organisation - Ermöglicht das Filtern nach Organisation
Beispiel 1:
Problem: Agenten erhalten keine Aufgaben, Inventare dauern sehr lange usw. Gestartete Aufgaben (t) und erledigte Aufgaben (tc und / oder c) sind gleich oder nahezu gleich, aber aktive Threads (at) und / oder reservierte Threads (rt) sind viel niedriger als der Standardleerlaufpegel von jeweils 400.Ursache: Offlineskripte werden zu häufig ausgeführt und aktive Threads werden von Agenten verwendet, die Offlineskriptergebnisse hochladen.
Beispiel 2:
Problem: Agentenaufgaben werden nicht schnell genug gesendet und in der Agentenaufgabenliste gesichert. Viele Tasks befinden sich im Status "Bereit zur Ausführung (verbunden)" und aktive / reservierte Threads (at / rt) scheinen über viele verfügbare Threads zu verfügen.
Ursache: Möglicherweise muss der Taskdurchsatz erhöht werden, da der Server zwar mit der Last Schritt hält, die Aufgaben jedoch nicht schnell genug ausführen kann, um mit der Nachfrage Schritt zu halten.Geplante Berichte
Die Auswirkungen geplanter Berichte auf die Serverleistung hängen von der Anzahl und Häufigkeit geplanter Berichte sowie von der Größe des abgefragten Datensatzes ab.Tip:
- Der Berichtsassistent sollte effiziente Abfragen erstellen, es ist jedoch möglich, ein sehr großes Dataset zu erstellen, dessen Ausführung mehrere Minuten dauern kann.
- Geben Sie den kleinsten benötigten Datensatz an.
Beispiel: Muss herausgefunden werden, ob Windows-Computern Softwaretitel fehlen, auf denen eine bestimmte Windows-Version ausgeführt wird? Filtern Sie den Bericht so, dass nur Windows-Systeme angezeigt werden, auf denen diese bestimmte Windows-Version ausgeführt wird und die die Kriterien erfüllen.
- Planen Sie Berichte, die den Intervallen für Agentenaufgaben ähneln. Planen Sie die Ausführung nur so oft ein, wie es der Bedarf erfordert.
Beispiel: Wenn ein Tagesbericht ausreicht, planen Sie ihn nicht stündlich ein.
Smart Labels
Die Auswirkungen von Smart Labels auf die Serverleistung können beträchtlich sein. Smart Labels für Geräte und Benutzer (einschließlich LDAP-Labels) werden verarbeitet, wenn ein Gerät Inventardaten hochlädt oder sich ein Benutzer anmeldet. Dies bedeutet, dass jedes auf dem Server aktivierte Smart Label für Geräte für jeden Inventar-Upload ausgeführt wird. Beispielsweise würden 100 Smart Labels, die in einer Umgebung mit 15.000 Geräten aktiviert sind, während jedes Inventurzyklus 150.000 Abfragen nach Smart Labels verursachen. In ähnlicher Weise würden 100 Benutzer-Smart-Labels bei jeder Anmeldung eines Benutzers ausgewertet.Tip:
- Smart Labels (einschließlich LDAP-Labels) sollten so präzise wie möglich sein.
- Jedes Label sollte getestet werden, um sicherzustellen, dass es keine Verzögerung auf dem Server verursacht. Es ist durchaus möglich, dass ein einzelnes ineffizientes Label Abfragen auf dem Server blockiert, was zu Verzögerungen führt - oder in einigen Fällen sogar den Fluss von Inventardaten in die Datenbank stoppt.
- LDAP-Labels sollten in LDAP so restriktiv wie möglich sein. Der Basis-DN sollte so tief wie möglich in der Struktur sein, und der erweiterte Suchfilter sollte sehr genau sein, um nur die erforderlichen Daten zurückzugeben.
Ticketregeln
Obwohl Ticketregeln in der Regel für den Helpdesk gelten, ist es möglich, auf Daten in anderen Bereichen der Datenbank zuzugreifen - was sich auf die Leistung in anderen Bereichen auswirken kann.
Tip:
- Ticketregeln sollten immer vor der vollständigen Implementierung getestet werden.
- Ticketregeln werden für jedes Ticket in einer Warteschlange ausgeführt, wenn das Ticket per E-Mail gespeichert oder geändert wird.
- Jede Regel zeigt den letzten Lauf am Ende der Seite und wie lange es gedauert hat. Beachten Sie, wie lange die Ausführung der einzelnen Regeln dauert, da die Gesamtzeit aller Regeln für eine Warteschlange bestimmt, wie lange die Verarbeitung einer Ticketspeicherung dauert.
Benutzerdefiniertes SQL (Ticketregeln, Berichte, Smart Labels)
Wenn möglich, sollten die Assistenten in der Benutzeroberfläche verwendet werden. Benutzerdefiniertes SQL ist eine Option auf Expertenebene, die wir dem Kunden anbieten. Sie ist extrem leistungsfähig, aber auch sehr gefährlich.- Alle benutzerdefinierten SQL-Anweisungen sollten vor der Implementierung getestet werden (MySQL Workbench usw.).
- Wählen Sie nur die erforderlichen Felder aus, da bei Verwendung von select * ein größerer Datensatz zurückgegeben wird.
- Aufgrund der Art von benutzerdefiniertem SQL ist es möglich, eine Abfrage zu schreiben, die sich erheblich auf die Serverleistung auswirkt.
- Der Support bietet keine Unterstützung für benutzerdefiniertes SQL, KACE Professional Services ist jedoch als kostenpflichtiges Angebot für alle benutzerdefinierten SQL-Anforderungen verfügbar.
Kontaktaufnahme mit dem KACE-Support
Wenn Sie sich an den KACE Support wenden, ist es wichtig, die Symptome des Leistungsproblems so genau wie möglich zu identifizieren. Sie können auch Zeit sparen, indem Sie Serverprotokolle vorab von der Appliance abrufen, da diese normalerweise zur Diagnose des Problems erforderlich sind. So rufen Sie Serverprotokolle ab:Multi-Org: SystemUI | Einstellungen | Support | Appliance-Aktivitätsprotokolle abrufen
Single-Org: AdminUI | Einstellungen | Support | Appliance-Aktivitätsprotokolle abrufenDadurch wird ein Serverprotokollpaket im TGZ-Format heruntergeladen, das der KACE Support möglicherweise anfordert, um bei der Diagnose des Problems behilflich zu sein.
Neben dem Abrufen von Protokollen ist es wichtig, sicherzustellen, dass eine gültige Sicherung (sowohl Basis- als auch Differenzdateien - gekennzeichnet als "Basis" und "Incr") von der Appliance auf eine lokale oder Netzwerkfreigabe in Ihrer Umgebung ausgelagert wurde.