Dimensionamento e prestazioni del database
Il dimensionamento del database è la chiave per comprendere le prestazioni di System Center - Orchestrator. I server Runbook, i server management e i componenti Web dipendono dal database di Orchestrator per le operazioni. I problemi relativi alle distribuzioni di Orchestrator possono derivare da una conoscenza incompleta dei tipi di dati nel database e di come gestirli.
Poiché Runbook Designer comunica con il database di Orchestrator (tramite il server management), le prestazioni non ottimali del database possono impedire tale comunicazione.
L'esperienza dell'operatore Orchestrator si basa su due componenti: La console di orchestrazione e il servizio Web. La console Orchestration è un'applicazione basata su Silverlight che dipende dal servizio Web per la connessione al database di Orchestrator. Il servizio Web è un'applicazione IIS che si connette al database. Pertanto, il servizio Web e la console di orchestrazione dipendono entrambe dalle prestazioni del database di Orchestrator.
Inoltre, sebbene la console Orchestration dipenda dal servizio Web, dispone anche di una logica univoca per la propria funzione di interfaccia utente e specifiche caratteristiche in termini di prestazioni.
Dati di configurazione e dati del registro
A livello generale, il database di Orchestrator contiene due tipi di dati:
Dati di configurazione
L'infrastruttura di Orchestrator contiene i dati di configurazione. Questi dati non rappresentano un problema nel contesto dell'aumento del database perché i requisiti di archiviazione per questo tipo di dati sono di piccole dimensioni.
Dati del registro
Orchestrator crea diversi tipi di dati di log, tutti visualizzabili e gestiti in Runbook Designer. I requisiti di archiviazione per questi dati possono variare in base alle dimensioni e possono essere di grandi dimensioni.
La seguente tabella elenca i tipi di dati di log che è possibile archiviare nel database Orchestrator. Orchestrator archivia anche i dati in file di log separati (all'esterno del database) per i audit trail e la traccia. Per ulteriori informazioni su tutti i tipi di dati del registro, vedere Orchestrator Logs.
| Tipo di dati del registro | Posizione in Runbook Designer | Gestito da Eliminazione registro? |
|---|---|---|
| Registri Runbook | SchedeRegistro e Registro History | Sì |
| Eventi attività (piattaforma) | SchedaEventi | No |
| Cronologia controllo | SchedaCronologia controlli | No |
Codice di piattaforma e codice di dominio
Le attività del runbook di Orchestrator contengono due tipi distinti di codice:
Codice della piattaforma
Si tratta del codice comune condiviso dalla maggior parte delle attività e viene usato per eseguire attività comuni eseguite dalle attività di Orchestrator. Il codice di piattaforma genera i dati pubblicati comuni.
Codice di dominio
Esegue varie attività specifiche per le azioni per ogni attività, che in genere non sono associate alla piattaforma Orchestrator stessa. Potenzialmente, può esserci una grande variazione tra il codice della piattaforma e il codice di dominio.
I dati di registrazione generati per una determinata attività possono contenere elementi di dati singoli o multivalore. Ogni attività produce un unico record di dati con valore singolo. Il codice di dominio può produrre più record di dati multivalore ed è pertanto responsabile dell'utilizzo che l'attività fa dei dati pubblicati comuni provenienti da attività precedenti.
I Runbook Orchestrator sono progettati sostanzialmente per passare i dati tra gli elementi discreti del codice di dominio. Inoltre, il codice di dominio può generare facoltativamente dei dati pubblicati per attività specifiche.
I Runbook condividono diverse funzionalità, ad esempio eseguono attività che comprendono il codice di dominio e il codice di piattaforma, eseguono cicli dei flussi di lavoro e creano diramazioni. Un Runbook esegue una diramazione quando chiama altri Runbook per completare un'attività specifica. Quando un runbook viene richiamato per la prima volta, è costituito da un singolo thread. Quando il thread rileva un'attività del Runbook i cui collegamenti richiedono una diramazione, vengono creati dei thread aggiuntivi, uno per ogni diramazione. Ogni thread accetta come input i dati pubblicati comuni dell'attività che ha creato la diramazione. Questi dati vengono nuovamente correlati alle attività precedenti nel Runbook per aggiornare i dati pubblicati comuni ai quali le attività effettuano la sottoscrizione.
Il codice di dominio ha, potenzialmente, un effetto maggiore sulle prestazioni del database rispetto al multithreading generato dalla diramazione. Infatti, il codice di dominio può potenzialmente generare grandi quantità di dati pubblicati per attività specifiche.
Opzioni di registrazione
La scheda Registrazione nelle Proprietà di un Runbook consente, se si desidera, di archiviare le voci di registrazione. Il termine registrazione predefinita indica che nessuna delle due opzioni relative ai dati pubblicati è selezionata, il che significa 524 byte generati per ciascuna attività. Le opzioni di registrazione forniscono due categorie di dati pubblicati comuni:
Dati pubblicati comuni
L'insieme di elementi di dati comuni a tutte le attività. Per un elenco, vedere Le opzioni di log del runbook.
Questa opzione di registrazione genera 6082 byte per ogni attività.
Dati pubblicati specifici dell'attività
L'insieme di dati specifici per l'attività, creato facoltativamente dal codice di dominio.
Questa opzione di registrazione genera 6082 byte oltre ai byte registrati da attività specifiche.
Suggerimento
Questa opzione è selezionata principalmente a scopo di debug. Lasciare deselezionata questa opzione per limitare l'aumento delle dimensioni della registrazione.
L'impostazione delle opzioni di registrazione può influire notevolmente sulle prestazioni e aumentare le dimensioni del database. Prendere in considerazione uno scenario in cui la stessa attività del Runbook viene eseguita due volte: la prima con la registrazione dei dati al livello predefinito (senza alcuna opzione relativa ai dati pubblicati selezionata) e la seconda con l'opzione relativa ai dati pubblicati comuni selezionata. Il tempo necessario per il completamento del codice di dominio deve essere lo stesso. Tuttavia, l'esecuzione del codice di piattaforma richiede più tempo perché deve supportare la registrazione di una quantità di dati pubblicati comuni 12 volte maggiore rispetto alla registrazione predefinita.
Ripulire i log
Le opzioni predefinite specificate per la funzionalità Di eliminazione log in Runbook Designer sono configurate per offrire la migliore esperienza utente per una distribuzione predefinita di Orchestrator. La modifica di questi valori può modificare le caratteristiche delle prestazioni dell'ambiente e deve essere implementata gradualmente e con filigrana elevata in modo che l'effetto della modifica possa essere valutato.
Per altre informazioni sull'eliminazione automatica e manuale dei log, vedere Eliminazione dei log dei runbook.
Creare benchmark delle prestazioni
Per creare un runbook semplice per testare la crescita della registrazione, è possibile usare i valori standard di confronto attività per creare benchmark di un ambiente Orchestrator.
La procedura seguente crea un runbook che esegue un'attività Confronta valori 10.000 volte. Compare Values è una semplice attività il cui codice di dominio è minimo. Questo runbook può essere richiamato in varie circostanze per caratterizzare le prestazioni complessive di un determinato ambiente di runtime di Orchestrator.
Creare un runbook che può essere usato per eseguire il benchmark dell'ambiente di Orchestrator
Creare un nuovo Runbook.
Aggiungere un'attività Compare Values dalla tavolozza delle attività standard. Fare doppio clic sull'attività per configurarla.
Selezionare la scheda Generale e configurare questa attività per confrontare le stringhe (il valore predefinito).
Selezionare la scheda Dettagli, immettere il valore STRING nella casella Test e selezionare vuoto.
Selezionare Fine per salvare gli aggiornamenti dell'attività.
Fare clic con il pulsante destro del mouse sull'attività e selezionare Ciclo.
Selezionare la casella di controllo Abilita e immettere il numero 0 (zero) per Ritardo tra i tentativi.
Selezionare la scheda Esci .
Modificare la condizione di uscita predefinita. Selezionare Confronta valori, selezionare la casella di controllo Mostra dati pubblicati comuni e selezionare Ciclo: Numero di tentativi. Selezionare OK per salvare questa modifica.
Selezionare il valore dalla condizione di uscita aggiornata e immettere il numero 10000 (diecimila). Selezionare OK per salvare questa modifica.
Selezionare Fine per salvare questi aggiornamenti.
Selezionare Archiviazione per salvare le modifiche apportate al database di Orchestrator.
Questo Runbook consente di sperimentare diverse configurazioni di Orchestrator. Ad esempio, è possibile creare Runbook benchmark per determinare le prestazioni di quattro server Runbook distribuiti in diversi data center.
| Centro dati | Configurazione della registrazione | Runtime del codice di piattaforma (millisecondi) | Millisecondi per attività | Fattore di scala |
|---|---|---|---|---|
| Posizione 1 | registrazione predefinita | 819 | 82 | 1.0 (riferimento) |
| Posizione 1 | Registrazione dei dati pubblicati comuni | 2012 | 201 | 2.5 |
| Posizione 2 | registrazione predefinita | 1229 | 123 | 1,5 |
| Posizione 2 | Registrazione dei dati pubblicati comuni | 3686 | 369 | 4.5 |
| Posizione 3 | registrazione predefinita | 2457 | 426 | 3.0 |
| Posizione 3 | Registrazione dei dati pubblicati comuni | 4422 | 442 | 5.4 |
| Posizione 4 | registrazione predefinita | 1474 | 147 | 1.8 |
| Posizione 4 | Registrazione dei dati pubblicati comuni | 2654 | 265 | 3.2 |
Si noti la diminuzione significativa delle prestazioni della piattaforma, dovuta alla registrazione dei dati pubblicati comuni. Lo scenario peggiore sembra essere la registrazione dei dati pubblicati comuni in Posizione 2. Apparentemente, questa sembra essere una conclusione chiara e rilevante.
Tuttavia, va evidenziato che questi dati riflettono l'overhead del codice di piattaforma e non riguardano il codice di dominio. I runtime del codice di dominio possono essere più lunghi. Ad esempio, l'attività Crea macchina virtuale da modello nell'Integration Pack di Virtual Machine Manager può restare in esecuzione per diversi minuti durante la creazione della macchina virtuale. Espandendo l'esempio precedente, considerare i costi del codice della piattaforma in un'attività del runbook che richiede 1 minuto per l'esecuzione (1 minuto = 60.000 millisecondi) indipendentemente dalla posizione.
| Centro dati | Configurazione della registrazione | Runtime del codice di piattaforma (millisecondi) | Percentuale codice di dominio | Percentuale codice di piattaforma |
|---|---|---|---|---|
| Posizione 1 | registrazione predefinita | 819 | 9,6% | 1,4% |
| Posizione 1 | Registrazione dei dati pubblicati comuni | 2012 | 96,7% | 3,3% |
| Posizione 2 | registrazione predefinita | 1229 | 98% | 2% |
| Posizione 2 | Registrazione dei dati pubblicati comuni | 3686 | 93.9% | 6,1% |
| Posizione 3 | registrazione predefinita | 2457 | 95,9% | 4l,1% |
| Posizione 3 | Registrazione dei dati pubblicati comuni | 4422 | 9,.6% | 7,4% |
| Posizione 4 | registrazione predefinita | 1474 | 97,5% | 2,5% |
| Posizione 4 | Registrazione dei dati pubblicati comuni | 2654 | 95,6% | 4,4% |
Un'immagine più chiara inizia a emergere dai dati. Lo scenario in cui è attivata la registrazione dei dati pubblicati comuni in posizione 2 continua a essere quello con le prestazioni peggiori. Tuttavia, il codice di piattaforma e la registrazione corrispondono solo al 6% del runtime totale. Benché questo sia un valore significativo, lo scenario migliore è di 1,4%. In pratica, il tempo impiegato nel codice di dominio dell'esempio supera di molto il tempo dedicato all'esecuzione del codice di piattaforma. Per mettere questo punto in prospettiva, se si fosse in grado di eliminare completamente i costi del codice della piattaforma, si vedranno solo miglioramenti delle prestazioni del runbook nell'intervallo da 1,4% a 7,4%.
La maggior parte degli scenari reali sarà diversa. Il comportamento dell’attività può variare in base alle istruzioni date al codice di dominio. Ad esempio, un'attività Clone VM from Template può richiedere un minuto per clonare una macchina virtuale dal modello di server A, ma richiedere 5 minuti per clonare una macchina virtuale dal modello di server B. Inoltre, i server Runbook possono risiedere in reti diverse con caratteristiche di prestazioni diverse, che possono influire potenzialmente sulle prestazioni del codice di dominio e sulle prestazioni di registrazione dei dati di Orchestrator.
Determinare l'aumento del database
L'amministratore del database di Orchestrator può utilizzare le seguenti linee guida per determinare la strategia di crescita del file di database:
In generale, i file di database non aumentano di dimensioni con ogni chiamata di un runbook. Tali dimensioni crescono quando i dati contenuti raggiungono uno specifico limite massimo configurato dall'amministratore del database, raggiunto il quale il file viene generalmente espanso.
Ogni volta che viene eseguita un'attività del runbook, deve essere conteggiata singolarmente, che deve essere considerata quando le funzionalità di ciclo possono causare l'esecuzione di una singola attività più volte.
Per determinare lo spazio di archiviazione necessario per ogni chiamata del runbook, moltiplicare il numero di attività nel runbook in base al numero di byte aggiunti al database in base al livello di registrazione selezionato. I valori sono i seguenti:
524 byte
Configurazione della registrazione predefinita.
6082 byte
Livello di registrazione dei dati pubblicati comuni.
6082 byte + dati registrati per attività
Livello di registrazione dei dati pubblicati per attività specifiche.
Per impostazione predefinita, Orchestrator elimina tutto tranne i 500 log più recenti per ogni Runbook ogni notte alle 2:00. Per determinare lo spazio di archiviazione necessario per ogni chiamata del Runbook, moltiplicare l'archiviazione necessaria per ciascuna chiamata del Runbook per 500. Se si modifica l'impostazione Eliminazione registro, moltiplicare ciascuna chiamata per il numero stimato di chiamate al giorno, settimana o mese in base alle esigenze.
Nella seguente tabella sono visualizzate le stime relative a crescita e prestazioni per le configurazioni del livello di registrazione.
| Livello di registrazione | Fattore di crescita DB | Fattore di prestazioni | Consigliato per la produzione |
|---|---|---|---|
| Predefiniti | 1 | 1 | Sì |
| Dati pubblicati comuni | 11.6x | 2.5x | Utilizzo limitato con pianificazione |
| Dati pubblicati per attività specifiche | Maggiore di 11.6x | Maggiore di 2.5x | No |
Esempi
Esempio 1
Nella tabella seguente vengono descritte le considerazioni sul ridimensionamento del database per una distribuzione di Orchestrator.
| Nome Runbook | Numero di attività | Livello di registrazione | Chiamate al giorno |
|---|---|---|---|
| Runbook 1 | 50 | Predefiniti | 100 |
| Runbook 2 | 25 | Predefiniti | 50 |
| Runbook 3 | 12 | Dati pubblicati comuni | 24 |
| Runbook 4 | 8 | Dati pubblicati comuni | 500 |
Utilizzando le dimensioni del database descritte in precedenza, è possibile stimare i requisiti per l'archiviazione dei Runbook.
| Nome Runbook | Byte per chiamata | Archiviazione in MB Eliminazione registro predefinito (500 chiamate) |
Chiamate al mese | Archiviazione in MB Un mese (Eliminazione registro non predefinito) |
Percentuale archiviazione DB dopo 30 giorni |
|---|---|---|---|---|---|
| Runbook 1 | 26.200 | 12.5 | 3,000 | 74,5 | %9 |
| Runbook 2 | 13.100 | 6.2 | 1.500 | 18.7 | 2% |
| Runbook 3 | 72.984 | 34,8 | 720 | 50,1 | %6 |
| Runbook 4 | 48.656 | 23.2 | 15.000 | 696 | 83% |
| Totale: 76,7 MB | Totale: 839,3 MB |
Questo esempio illustra chiaramente quanto sia importante prendere decisioni ottimali per la registrazione dei dati. Il runbook 4 contiene solo otto attività, ma se configurate a livello di registrazione dei dati pubblicati comune, utilizza la maggior parte dello spazio di archiviazione nel database a causa dell'elevata frequenza di chiamata. In base a questi risultati, è preferibile ridurre il livello di registrazione di Runbook 4 alla configurazione di registrazione predefinita.
Esempio 2
Nella tabella seguente vengono descritte le considerazioni sul ridimensionamento del database per un'altra distribuzione di Orchestrator.
| Nome Runbook | Numero di attività | Livello di registrazione | Chiamate al giorno |
|---|---|---|---|
| Runbook 1 | 50 | Predefiniti | 100 |
| Runbook 2 | 25 | Predefiniti | 50 |
| Runbook 3 | 12 | Dati pubblicati comuni | 24 |
| Runbook 4 | 8 | Predefiniti | 500 |
Il ricalcolo dello spazio di archiviazione per la configurazione aggiornata produce risultati significativamente diversi.
| Nome Runbook | Byte per chiamata | Archiviazione in MB Eliminazione registro predefinito (500 chiamate) |
Chiamate al mese | Archiviazione in MB Un mese (Eliminazione registro non predefinito) |
Percentuale archiviazione DB dopo 30 giorni |
|---|---|---|---|---|---|
| Runbook 1 | 26.200 | 12.5 | 3,000 | 74,5 | 37% |
| Runbook 2 | 13.100 | 6.2 | 1.500 | 18.7 | %9 |
| Runbook 3 | 72.984 | 34,8 | 720 | 50,1 | 25% |
| Runbook 4 | 4.192 | 2.0 | 15.000 | 60 | 29% |
| Totale: 55,5 MB | Totale: 203,3 MB |
Sebbene la configurazione di registrazione predefinita (500 voci di log per runbook) abbia subito modifiche minime, i requisiti di archiviazione di 30 giorni sono cambiati notevolmente. Chiaramente, il costo di archiviazione dell'uso della registrazione dei dati pubblicati comuni per Runbook 4 deve essere considerato attentamente poiché questa modifica comporta una riduzione del 76% dei requisiti di archiviazione del database per 30 giorni di dati.
Riepilogo
Per gestire le prestazioni e le dimensioni del database, attenersi alle seguenti indicazioni:
Attivare la registrazione dei dati pubblicati comuni solo se necessario.
Tenere presente che il numero di esecuzioni delle attività determina il volume dei dati registrati. Un runbook di piccole dimensioni con alcune attività eseguite più volte può comportare più registrazione dei dati rispetto a un runbook più grande che eseguire un numero inferiore di volte.
Non abilitare la registrazione dei dati pubblicati specifici dell'attività negli ambienti di produzione e devono essere usati solo a scopo di debug.
Acquisire consapevolezza del tempo che viene impiegato dai Runbook per eseguire il codice di dominio rispetto al codice di piattaforma.
Effettuare una stima dei costi del codice di piattaforma utilizzando le tecniche descritte nel presente documento e farvi riferimento nel valutare l'eventuale necessità di migliorare le prestazioni dei Runbook.
Identificare le opportunità di miglioramento effettuando un confronto normalizzato delle misurazioni.
Vedi anche
- Log dell'agente di orchestrazione.
- Architettura dell'agente di orchestrazione.