Dimensioni e prestazioni del database

Data di pubblicazione: marzo 2016

Si applica a: System Center 2012 SP1 - Orchestrator, System Center 2012 - Orchestrator, System Center 2012 R2 Orchestrator

Le dimensioni del database sono la chiave per comprendere le prestazioni di System Center 2012 - Orchestrator. I server Runbook, i server management e i componenti Web dipendono dal database di Orchestrator per le operazioni. Una comprensione incompleta dei tipi di dati nel database e delle relative modalità di gestione può creare potenziali problemi durante le distribuzioni di Orchestrator.

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 di Orchestrator si basa su due componenti: la console Orchestration 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. Di conseguenza, sia il servizio Web che la console Orchestration dipendono 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 un livello elevato, il database di Orchestrator contiene due tipi di dati:

• Dati di configurazione

  L'infrastruttura Orchestrator contiene i dati di configurazione. Questi dati non rappresentano un problema in termini di aumento delle dimensioni del database poiché la loro archiviazione non richiede molto spazio.

• Dati del registro

  Orchestrator crea diversi tipi di dati del registro, che possono essere visualizzati e gestiti in Runbook Designer. I requisiti di archiviazione per questi dati possono essere molto variabili e raggiungere 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 gli audit trail e la traccia. Per ulteriori informazioni su tutti i tipi di dati del registro, vedere Registri Orchestrator.

  Tipo di dati del registro	Posizione in Runbook Designer	Gestito da Eliminazione registro?
  Registri Runbook	Schede Registro e Cronologia registro	Sì
  Eventi attività (piattaforma)	Scheda Eventi	No
  Cronologia controlli	Scheda Cronologia controlli	No

Codice di piattaforma e codice di dominio

Le attività del Runbook Orchestrator contengono due diversi tipi di codice:

• Codice di piattaforma

  Si tratta di un codice comune condiviso dalla maggior parte delle attività, utilizzato per eseguire attività frequenti mediante Orchestrator. Il codice di piattaforma genera i dati pubblicati comuni.

• Codice di dominio

  Esegue diverse operazioni specifiche per le azioni di ciascuna attività, generalmente non associate alla piattaforma Orchestrator. Le diversità tra codice di piattaforma e codice di dominio sono potenzialmente notevoli.

  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 viene richiamato per la prima volta, un Runbook è formato 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 la sezione Opzioni della registrazione Runbook in Registri Runbook.

  Questa opzione di registrazione genera 6082 byte per ogni attività.

• Dati pubblicati per attività specifiche

  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.

Eliminazione dei registri

Le opzioni predefinite specificate per la funzionalità Eliminazione registro in Runbook Designer vengono configurate per offrire la migliore esperienza utente durante una distribuzione guidata di Orchestrator. La modifica di questi valori influisce sulle caratteristiche relative alle prestazioni dell'ambiente, pertanto è necessario implementarla gradualmente e con un limite massimo, in modo da valutarne l'impatto.

Per ulteriori informazioni sull'eliminazione dei registri automatica o manuale, vedere la sezione Eliminazione dei registri dei Runbook di Registri Runbook.

Per creare un Runbook semplice che consenta di verificare l'aumento delle dimensioni della registrazione, è possibile utilizzare Confronta valori dell'attività standard che permette la creazione di benchmark di un ambiente Orchestrator.

Con la procedura riportata di seguito viene creato un Runbook semplice in grado di eseguire un'attività Confronta valori per 10.000 volte.Confronta valori è un'attività molto semplice, con un codice di dominio di dimensioni ridotte. È possibile richiamare questo Runbook in diverse situazioni per caratterizzare le prestazioni complessive di un determinato ambiente di runtime Orchestrator.

Per creare un Runbook da utilizzare per il benchmark dell'ambiente Orchestrator

1. Creare un nuovo Runbook.

2. Aggiungere un'attività Compare Values dalla tavolozza delle attività standard. Fare doppio clic sull'attività per configurarla.

3. Scegliere la scheda Generale e configurare l'attività per confrontare le stringhe (valore predefinito).

4. Fare clic sulla scheda Dettagli, digitare il valore STRING nella casella Verifica e selezionare è vuoto.

5. Fare clic su Fine per salvare gli aggiornamenti dell'attività.

6. Fare clic con il pulsante destro del mouse sull'attività e selezionare Ciclo.

7. Selezionare la casella di controllo Abilita e inserire il numero 0 (zero) per Ritardo tra i tentativi.

8. Fare clic sulla scheda Esci.

9. Modificare la condizione di uscita predefinita. Fare clic su Confronta valori, selezionare la casella di controllo Visualizza dati pubblicati comuni, quindi selezionare Ciclo: Numero di tentativi. Fare clic su OK per salvare questa modifica.

10. Selezionare valore dalla condizione di uscita aggiornata e digitare il numero 10000 (diecimila). Fare clic su OK per salvare questa modifica.

11. Fare clic su Fine per salvare gli aggiornamenti.

12. Fare clic su Archivia per salvare le modifiche 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.

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 notevolmente 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. Proseguendo con l'esempio precedente, si considerino i costi del codice di piattaforma per un'attività del Runbook la cui esecuzione richiede un minuto (1 minuto = 60.000 millisecondi) indipendentemente dalla posizione.

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. Sotto questo punto di vista, se si potessero eliminare completamente i costi del codice di piattaforma, i miglioramenti in termini di prestazioni del Runbook ricadrebbero in un intervallo compreso tra l'1,4 e il 7,4%.

Naturalmente la maggior parte degli scenari reali è diversa. Il comportamento dell’attività può variare in base alle istruzioni date al codice di dominio. Ad esempio, un'attività Clona macchina virtuale da modello può richiedere un minuto per la clonazione di una macchina virtuale dal modello server A e cinque minuti dal modello server B. Inoltre, i server Runbook possono trovarsi in reti diverse con caratteristiche di prestazioni differenti, il che può influire sulle prestazioni del codice di dominio e della registrazione dei dati Orchestrator.

L'amministratore del database di Orchestrator può utilizzare le seguenti linee guida per determinare la strategia di crescita del file di database:

• In generale, le dimensioni dei file di database non aumentano a 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 esecuzione di un'attività del Runbook deve essere conteggiata individualmente. Questa considerazione deve essere tenuta presente quando le funzionalità di ciclo causano più esecuzioni di un'unica attività.

• Per determinare le dimensioni per l'archiviazione necessarie per ciascuna chiamata del Runbook, moltiplicare il numero delle attività nel Runbook per il numero di byte aggiunto 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.

Esempio 1

Nella seguente tabella vengono descritte le considerazioni relative alle dimensioni del database per una distribuzione di Orchestrator.

Utilizzando le dimensioni del database descritte in precedenza, è possibile stimare i requisiti per l'archiviazione dei Runbook.

Questo esempio illustra chiaramente quanto sia importante prendere decisioni ottimali per la registrazione dei dati. Runbook 4 contiene solo otto attività, tuttavia, quando viene configurato al livello di registrazione dei dati pubblicati comuni, consuma la maggior parte dello spazio di archiviazione del database a causa dell'alta frequenza delle chiamate. In base a tali risultati, potrebbe essere opportuno ridurre il livello di registrazione del Runbook 4 alla configurazione della registrazione predefinita.

Esempio 2

Nella seguente tabella vengono descritte le considerazioni relative alle dimensioni del database per un'altra distribuzione di Orchestrator.

Il ricalcolo dello spazio di archiviazione per la configurazione aggiornata produce risultati significativamente diversi.

Sebbene vi sia qualche lieve cambiamento nella configurazione della registrazione predefinita (500 voci di registro per runbook), i requisiti di archiviazione di 30 giorni sono cambiati notevolmente. Chiaramente è necessario considerare attentamente i costi di archiviazione dell'utilizzo della registrazione dei dati pubblicati comuni per Runbook 4, poiché questo cambiamento produce una riduzione del 76% nei requisiti di archiviazione del database per 30 giorni di dati.

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 poche attività eseguito numerose volte può comportare un volume di dati registrati superiore a quello di un Runbook più esteso eseguito meno frequentemente.

• Non attivare la registrazione delle attività specifiche dei dati pubblicati in ambienti di produzione e utilizzare 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.

Registri Orchestrator
Registri Runbook
Architettura di Orchestrator