Restituisci
-
Titolo
Considerazioni e guida sulla massimizzazione delle prestazioni del KACE SMA -
Descrizione
Considerazioni e guida sulla massimizzazione delle prestazioni del KACE SMA
Questo documento fa riferimento a "Admin UI" e "System UI" dell'Appliance Management Systems. Per accedere all'interfaccia utente di amministrazione o di sistema per poter aggiungere un file finale / adminui o / systemui all'URL di KACE Systems Management Appliance (SMA), inserire i seguenti indirizzi nel browser:
Admin UI: https://kacesma.domain.loc/adminui
System UI: https://kacesma.domain.loc/systemui
Nota: il tentativo di accedere all'interfaccia utente di sistema su un SMA a singola organizzazione verrà semplicemente reindirizzato all'interfaccia utente di amministrazione. Per i sistemi multi-org, le impostazioni sono presenti sia in Admin UI (per Org) che in System UI (globalmente).
-
Risoluzione
Per maggiori approfondimenti sulla'argomento, vi consigliamo di consultare il KACE-SMA Course 2 Installing the KACE SMA Agent-Web-based Training
Inoltre, il 27 ottobre 2017 è stato presentato un webinar di supporto KACE che copre i dettagli discussi in questo articolo. La il video è disponibile all'indirizzo: https://support.quest.com/kb/234300Gli argomenti elencati in questo articolo riguardano considerazioni sulle prestazioni e migliori impostazioni per l'appliance di gestione dei sistemi KACE. È un documento in costante aggiornamento, vi consigliamo di mantenerlo tra i segnalibri e di verificare spesso per eventuali aggiornamenti.Requisiti di Sistema:
E’ essenziale assicurarsi assicurarsi che siano soddisfatti i requisiti minimi di sistema per le appliance virtuali e assicurarsi che l'hardware fisico sia supportato.
Macchine Virtuali:
https://www.quest.com/products/kace-systems-management-appliance
Specifications | Virtual Appliance Technical Specifications | Virtual machine system requirements
Macchine fisiche:
https://www.quest.com/products/kace-systems-management-appliance
Specifications | Physical Appliance Technical Specifications | Hardware Specifications
Connessioni Agente
Multi-org: System UI | Organizations | [ORG Name]Single-org: Admin UI | Settings > Provisioning | Communication Settings- Le connessioni massime raccomandate all'ora sono 500 (inclusi gli agenti di ALL Orgs)
- Idealmente, imposta ogni intervallo nel modo più conservativo possibile. Esempio: se non è necessario aggiornare i risultati dell'inventario più di una volta al giorno, impostare Inventario agente su 1 giorno. L'impostazione di questo valore su 4 ore, in questo caso, metterebbe un ulteriore stress non necessario sul server, con un impatto negativo sulle prestazioni.
Limitazioni Apache
SMA utilizza Apache per tutte le attività dell'interfaccia utente Web e di agente e Apache ha un limite hard-coded di 800 connessioni simultanee. Le connessioni Apache sono in genere molto veloci e temporanee. Ad esempio, la pubblicazione di una pagina nell'interfaccia utente utilizza solo una connessione mentre vengono offerti i dati. Le connessioni più lunghe tendono ad essere download di file / carico utile da parte degli agenti. La seguente funzionalità è influenzata dall'overloading di Apache:
- Accesso all'interfaccia - utente: gli utenti e gli amministratori dell'help desk hanno un impatto su questa soglia mediante l'utilizzo costante dell'interfaccia utente Web.
- Intervalli agente - se le impostazioni degli intervalli agente sono troppo frequenti, Apache può raggiungere il limite massimo di connessioni.
- Scripting - gli script online e i relativi payload vengono estratti dagli agenti in fase di esecuzione pianificata. Avere troppi script online programmati troppo frequentemente può avere un impatto negativo sulle prestazioni dell'interfaccia utente, interrompere o ritardare l'attività degli agenti e in generale avere un impatto sulle prestazioni complessive del server.
- Pianificazioni delle patch - Le pianificazioni delle patch vengono eseguite in modo simile agli script online, quindi le informazioni su Scripting precedentemente menzionate si applicano qui.
Rimedi e prevenzione
- Replication Shares - Le Replication Shares sono l'opzione migliore per ridurre il traffico degli agenti da / verso SMA. Scaricando il lavoro di servire i file agli agenti per le Replication Shares, tutto il traffico che sarebbe andato a SMA per download di script, payload, file di patch, ecc. Verranno tutti estratti dalla Replication Shares per ciascun agente configurato per l'uso.
- Agent Intervals (connessioni agente) - Intervalli di allungamento agente possono ridurre le connessioni all'ora per ridurre l'impatto sul server Apache per SMA.
Discovery SchedulesLe Discovery Schedules non influiscono direttamente sulla comunicazione degli agenti o sulle prestazioni dell'interfaccia utente Web, poiché non implicano l'utilizzo di Apache. Tuttavia, avere Discovery Schedules aggressive può avere un impatto notevole sulle prestazioni generali del server.Script Schedules / Patch SchedulesLe Script Schedules e le Patch Schedules possono influire direttamente sulla comunicazione degli agenti e sulle prestazioni dell'interfaccia utente Web, poiché coinvolgono Apache. Avere Script Schedules e le Patch Schedules aggressive può dare impatto notevole sulle prestazioni generali del server e causare problemi con la comunicazione degli agenti e l'accesso all'interfaccia utente. L'opzione migliore per rimuovere la maggior parte di questo impatto è l'utilizzo delle replica Shares. La pianificazione aggressiva può ancora causare problemi con le condivisioni di replica, ma la soglia è molto più alta. Quando si utilizzano le condivisioni di replica, il colpevole più probabile di qualsiasi problema di throughput (ad esempio, le pianificazioni non completate) sarà l'impostazione del throughput delle attività.Gli script offline hanno una presenza meno visibile sul server, per loro natura. Tenete presente che gli script offline possono influire sulle prestazioni a causa del caricamento dei risultati (ad esempio, se uno script offline viene eseguito molto frequentemente, i caricamenti di risultati complessi in ambienti di grandi dimensioni possono effettivamente ridurre al massimo i thread di Apache).Task Throughput / Load AverageMulti-org: System UI | Settings | General SettingsSingle-org: Admin UI | Settings | Provisioning | Communication SettingsTask Throughput è un moltiplicatore utilizzato dal servizio Konductor (il 'cervello' per le attività degli agenti) su SMA. Il valore predefinito di 3 può essere incrementato di 1 livello ogni 15 minuti, ma dovrebbe essere aumentato solo se il carico medio sul server rimane inferiore a 10 e non è possibile mantenere la quantità di attività "pronte per l'esecuzione". Se il server sta inviando attività abbastanza veloci da mantenere una coda vuota, questo valore non dovrebbe essere aumentato. Dovrebbe essere utilizzata l'impostazione più bassa che funziona nell'ambiente.Il numero di attività totali è influenzato dalla quantità di programmi e script di patch in base al numero di agenti in produzione. L'intervallo dell'agente influenza anche la frequenza con cui molte di queste attività sono pianificate e inviate a tutti gli agenti, il che influirà nuovamente sul numero totale di attività che il server deve inviare agli agenti e sulla quantità di throughput richiesta per completarle.Task Throughput non dovrebbe essere aumentato oltre 5 senza consultare il supporto di KACE.Troubleshooting Agent TasksKonductor LogMulti-org: System UI | Settings | LogsSingle-org: Admin UI | Settings | Logs[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 = secondi conduttore è stato attivo
- t = tasks launched - attività avviate
- tc = tasks completed - tasks completed -attività completate
- c = tasks completed - attività completate (come per tc)
- cc = calls completed - chiamate completate (konductor aggiorna l'elenco delle attività)
- sl = leep interval in seconds - intervallo di sonno in secondi (ritardo tra i loop)
- tpl = tasks distributed by konductor per loop - compiti distribuiti da konductor per loop
- at = active threads - thread attivi (400 max, il numero diminuisce quando vengono utilizzati i thread)
- rt = reserved threads - thread riservati (400 max, il numero diminuisce quando si usano i thread)
- lt = target load - carico di destinazione (questo corrisponderà all'impostazione del throughput dell'attività corrente)
- lv = actual load for past 1 minute - carico effettivo per 1 minuto passato (non dovrebbe mai superare 10, minore è meglio)
Agent Tasks StatusInnanzitutto, assicurarsi che siano soddisfatti i requisiti minimi per le appliance virtuali e assicurarsi che l'hardware fisico sia attualmente supportato.- All Tasks – visualizza tutte le attività nella coda delle attività agente
- In Progress – visualizza tutte le attività inviate agli agenti che non sono stati completati
- Ready to Run (connected) – visualizza le attività pronte per l'esecuzione con agenti attivi connessi e in attesa
- Ready to Run – isualizza le attività pronte per l'esecuzione ma gli agenti non connessi
- Longer than 10 minutes – mostra le attività che sono state eseguite più di 10 minuti
- Task Type – consente il filtraggio in base al tipo di attività (ad es. Inventario, script specifico, ecc.)
- Organization – consente il filtraggio per organizzazione
Esempio 1:
Problema: gli agenti non ricevono attività, gli inventari impiegano molto tempo, ecc. Le attività avviate (t) e le attività completate (tc e / o c) sono uguali o quasi uguali, ma i thread attivi (at) e / oi thread riservati (rt) sono molto inferiori al livello di inattività standard di 400 ciascuno.
Causa: gli script offline sono in esecuzione troppo spesso e i thread attivi vengono utilizzati dagli agenti che caricano i risultati degli script offline.
Esempio 2:
Problema: le attività dell'agente non vengono inviate abbastanza velocemente e stanno eseguendo il backup nell'elenco delle attività dell'agente. Molte attività sono in stato "Ready to Run (connesso)" e i thread attivi / riservati (at / rt) sembrano avere molti thread disponibili.Causa: potrebbe essere necessario aumentare il throughput delle attività, poiché il server è al passo con il carico, ma non è in grado di distribuire le attività in modo sufficientemente veloce per tenere il passo con la domanda.Scheduled Reports
L'impatto dei Scheduled Reports sulle prestazioni del server dipenderà dal numero e dalla frequenza dei report pianificati insieme alla dimensione del set di dati interrogato.Suggerimenti:- La creazione guidata di report dovrebbe generare query efficienti, ma è possibile che venga creato un set di dati molto grande che può richiedere diversi minuti per essere eseguito.
- Segnala il set di dati più piccolo necessario. Esempio: è necessario vedere le macchine Windows prive di un titolo software che esegue una versione specifica di Windows? Filtra il report per mostrare solo i sistemi Windows che eseguono quella specifica versione di Windows che soddisfa i criteri.
- Pianificare i report in modo simile agli intervalli di attività dell'agente. Pianificarli solo in base alle esigenze richieste. Esempio: se un rapporto giornaliero è sufficiente, non pianificarlo ogni ora.
Smart LabelsL'impatto delle Smart Labels sulle prestazioni del server può essere abbastanza consistente. Le Smart Labels di dispositivi e utenti (comprese le etichette LDAP) vengono elaborate quando un dispositivo carica i dati di inventario o un utente accede, rispettivamente. Ciò significa che ogni Smart Labels del dispositivo abilitata sul server viene eseguita su ogni caricamento di inventario. Ad esempio, 100 Smart Labels abilitate in un ambiente con 15.000 dispositivi causerebbero 150.000 query per le Smart Labels in ogni ciclo di inventario. Allo stesso modo, 100 Smart Labels utente verranno valutate ad ogni accesso di un utente.Suggerimenti:- Le Smart Label (comprese le etichette LDAP) dovrebbero essere il più precise possibile.
- Ogni Smart Label deve essere testata per assicurarsi che non causi lag sul server. È del tutto possibile che una singola etichetta inefficiente esegua il backup di query sul server causando un ritardo o, in alcuni casi, addirittura interrompa il flusso dei dati di inventario nel database.
- Le Label LDAP dovrebbero essere il più restrittive in LDAP possibile. Il DN di base dovrebbe essere il più profondo possibile nella struttura e il filtro di ricerca avanzato dovrebbe essere molto preciso per restituire solo i dati richiesti.
Ticket Rules
Anche se le regole del ticket tendono ad essere applicate all'helpdesk, è possibile accedere ai dati in altre aree del database, che possono influire sulle prestazioni in altre aree.Suggerimenti:- Le regole dei ticket dovrebbero sempre essere testate prima della piena implementazione.
- Le regole del ticket vengono eseguite su ogni ticket in coda quando il ticket viene salvato o modificato tramite e-mail.
- Ogni regola mostrerà l'ultima esecuzione nella parte inferiore della pagina e quanto tempo è occorso per l'esecuzione. Tieni presente quanto tempo impiega a eseguire, poiché il tempo totale di tutte le regole insieme per una coda determinerà quanto tempo impiega un ticket per il salvataggio.
Personalizzazione SQL (Ticket Rules, Reports, Smart Labels)
Quando possibile, dovrebbero essere utilizzate le procedure guidate nell'interfaccia utente. SQL personalizzato è un'opzione di livello esperto che forniamo al cliente ed è estremamente potente ma anche molto pericoloso.
- Tutti gli SQL personalizzati devono essere testati prima dell'implementazione (MySQL Workbench, ecc.).
- Selezionare solo i campi richiesti, poiché l'uso di select * causerà il ritorno di un set di dati più grande.
- A causa della natura dell'SQL personalizzato, è possibile scrivere una query che ha un impatto significativo sulle prestazioni del server.
- Il supporto non offre assistenza con SQL personalizzato, ma i servizi professionali KACE sono disponibili come offerta a pagamento per qualsiasi esigenza SQL personalizzata.
Contattare il Supporto Kace
Quando si contatta il supporto KACE, è importante identificare i sintomi del problema di prestazioni nel modo più preciso possibile. Il tempo può anche essere salvato estraendo preventivamente i log del server dall'appliance, in quanto questi sono in genere necessari per diagnosticare il problema. Per estrarre i log del server:multi-org appliance:
System UI | Settings | Support | Retrieve appliance activity logs
single-org appliance:
Admin UI | Settings | Support | Retrieve appliance activity logs
Questo scaricherà un pacchetto di log del server in formato .tgz che il supporto KACE potrebbe richiedere per assistere nella diagnosi del problema.Oltre a generare i registri, è importante garantire un backup valido (sia i file di base che i file differenziali, etichettati come "base" e "incr") sono stati trasferiti dall'appliance a una condivisione locale o di rete nel proprio ambiente.