Archivi dati di AppFabric

Il programma di installazione e configurazione predefinito di Microsoft AppFabric 1.1 per Windows Server fornisce un database di salvataggio permanente e un database di monitoraggio. In un ambiente ad alta velocità effettiva entrambi gli archivi possono generare colli di bottiglia nelle prestazioni dovuti a errori di I/O su disco, blocchi SQL e così via. Grazie all'utilizzo di più database di monitoraggio e salvataggio permanente, AppFabric offre alla topologia dei dati un'elevata flessibilità che, se sfruttata in modo adeguato, è in grado di assicurare buoni livelli di prestazioni.

Archivi salvataggi permanenti multipli

È importante comprendere perché un archivio salvataggi permanenti nell'ambiente AppFabric può trasformarsi in un collo di bottiglia. Lo stato dei servizi WF durevoli viene memorizzato nell'archivio salvataggi permanenti AppFabric. La maggior parte dei dettagli relativi a ciascuna istanza permanente viene memorizzata nelle tabelle Istanze e Chiavi. Negli scenari ad alta velocità effettiva, in un intervallo di tempo breve, vengono create (inserimenti di database), salvate in modo permanente (aggiornamenti di database), correlate (letture/inserimenti/eliminazioni di database) e completate (eliminazioni di database) numerose istanze del flusso di lavoro. Queste tabelle danno quindi origine a conflitti di I/O su disco e blocchi del database. Nella figura riportata di seguito viene illustrato il collo di bottiglia generato.

Archivio dati salvataggi permanenti unico


Tenendo presenti le informazioni fornite in precedenza, negli scenari in cui il database di salvataggio permanente può trasformarsi in un collo di bottiglia è consigliabile creare più archivi salvataggi permanenti. Ogni archivio può essere dedicato a un determinato servizio o gruppo di servizi logicamente correlati. Per informazioni sul processo di creazione di un nuovo archivio dati salvataggi permanenti, vedere Creare e inizializzare un database tramite i cmdlet di Windows Server AppFabric. Nella figura riportata di seguito viene fornita una rappresentazione grafica del processo dal punto di vista concettuale.

Archivi salvataggi permanenti di AppFabric


È possibile configurare la posizione fisica di ciascun database aggiuntivo come indicato di seguito, in ordine crescente di scalabilità:

  1. Istanza di SQL Server e set di unità (volumi di dati e di file di registro) uguali a quelli degli archivi dati AppFabric iniziali

  2. Stessa istanza di SQL Server con un set di unità diverso rispetto agli archivi dati AppFabric iniziali

  3. Istanza di SQL Server diversa in esecuzione nello stesso cluster di SQL Server

  4. Installazioni e/o cluster di SQL Server diversi

La scelta tra le opzioni indicate in precedenza dipende dall'ambiente specifico e dalle risorse hardware disponibili. Per individuare con esattezza la posizione del collo di bottiglia, è necessario utilizzare i contatori delle prestazioni relativi alla CPU, alla memoria, all'I/O su disco e ai blocchi SQL. I valori forniti sono inoltre utili per scegliere l'opzione migliore per risolvere il problema.

noteNota
Non è attualmente disponibile alcun contatore delle prestazioni specifico di Microsoft AppFabric 1.1 per Windows Server.

Archivi di monitoraggio multipli

Le opzioni di topologia e di configurazione degli archivi dati di monitoraggio AppFabric sono simili a quelle precedentemente illustrate per il database di salvataggio permanente. Prima di proseguire l'analisi delle opzioni di topologia per consentire all'utente di effettuare la scelta corretta, verrà esaminato il flusso di dati attraverso l'archivio di monitoraggio e verranno indicati i principali punti di origine dei colli di bottiglia. I dati acquisiti tramite il Servizio di raccolta eventi vengono elaborati in base alla seguente sequenza semplificata:

  1. I dati eventi WCF e WF acquisiti vengono scritti in un'unica tabella di gestione temporanea del database di monitoraggio.

  2. Viene eseguito di frequente un processo di SQL Agent per verificare se sono presenti nuovi eventi, analizzare i dati eventi e spostarli nelle tabelle eventi WCF e WF normalizzate. Queste tabelle vengono utilizzate dalle viste di database che forniscono dati al Dashboard AppFabric o alle tecnologie di query o di report personalizzate. La logica di gestione temporanea utilizzata per gli eventi WCF è diversa da quella utilizzata per gli eventi WF. Gli eventi WCF si verificano infatti in momenti casuali, mentre gli eventi WF fanno generalmente parte di una catena di eventi di lunga durata potenziale relativi all'istanza del flusso di lavoro. In questo caso sono importanti anche la correlazione, lo stato temporale e la coerenza degli eventi.

    1. Per gli eventi dei servizi WCF puri, il processo di SQL Agent elabora i record di gestione temporanea in blocco, trasferendoli dalla tabella di gestione temporanea alla tabella eventi WCF normalizzata. Si tratta di un'operazione di elaborazione batch relativamente veloce.

    2. Al contrario, per gli eventi WF è possibile che il processo di SQL Agent, prima di spostare i dati nella tabella eventi WF normalizzata, debba eseguire la logica per ciascun record di gestione temporanea (evento). In questo caso, i tempi di elaborazione risultano più lunghi.

  3. I dati vengono inseriti nelle tabelle eventi WCF e WF normalizzate.

Il processo descritto è illustrato nella figura riportata di seguito.

Tabella di gestione temporanea


Dai test delle prestazioni risulta che il processo di SQL Agent è in grado di elaborare dai 3500 ai 4500 record di gestione temporanea (eventi) al secondo su un server BL680c dotato di CPU 4 quad-core con 32 GB di RAM e una configurazione di archiviazione disco analoga a quella di esempio già illustrata nella sezione Ottimizzazioni della piattaforma SQL Server della documentazione.

Come riferimento, utilizzando il livello Monitoraggio dello stato un servizio di flusso di lavoro senza stato e di breve durata con sei attività genera circa 13-14 eventi di registrazione (che determinano un numero identico di record di gestione temporanea). Questo significa che la velocità dei record in ingresso nella tabella di gestione temporanea raggiungerà la velocità di elaborazione (svuotamento) del processo di gestione temporanea di SQL Agent pari a 285 chiamate di servizio al secondo circa (velocità di svuotamento 4000 / 14 eventi per istanza del flusso di lavoro = 285 istanze del flusso di lavoro circa). Con una velocità effettiva più elevata verrà avviata la generazione di un backlog nella tabella di gestione temporanea.

noteNota
Per i servizi WCF puri basati su codice, l'utilizzo del livello Monitoraggio dello stato AppFabric consente, per impostazione predefinita, di aggregare le statistiche relative alle chiamate di operazioni prima di inviare le informazioni rilevate all'archivio di monitoraggio. La velocità di campionamento/aggregazione predefinita, pari a cinque secondi, determina l'emissione di un singolo evento all'archivio di monitoraggio per ogni operazione di servizio chiamata durante questo intervallo di tempo.

Se un singolo servizio WF attivo nell'ambiente riceve un carico costante pari a 280-300 chiamate al secondo, l'utilizzo di un livello di monitoraggio superiore al valore Solo errori determinerà la generazione di un backlog di record di gestione temporanea. In questo caso, saranno disponibili solo le seguenti opzioni:

  • Disattivazione del monitoraggio del servizio. Questa operazione può essere effettuata tramite l'interfaccia utente di gestione di AppFabric o tramite il cmdlet Set-ASAppMonitoring di Windows PowerShell con il parametro MonitoringLevel impostato su "Off".

  • Riduzione del livello di monitoraggio del servizio al valore Solo errori. Questa operazione può essere effettuata tramite l'interfaccia utente di gestione di AppFabric o tramite il cmdlet Set-ASAppMonitoring di Windows PowerShell con il parametro MonitoringLevel impostato su "Off".

  • Definizione di un profilo di rilevamento personalizzato a partire dal profilo di rilevamento dello stato predefinito, includendo solo gli eventi rilevanti e senza acquisire quelli derivanti da tutte le attività del flusso di lavoro. Per informazioni sulla creazione di un profilo di rilevamento personalizzato, visitare il sito Web alla pagina Configurare il rilevamento.

Se alcuni servizi congiuntamente determinano una velocità dei record di gestione temporanea in ingresso superiore alla soglia del backlog, è opportuno effettuare il provisioning di più archivi di monitoraggio e configurare i servizi per l'acquisizione dei dati di rilevamento in archivi di monitoraggio diversi, come illustrato nella figura riportata di seguito.

Server singolo


Anche in questo caso la posizione fisica degli archivi dati aggiuntivi può variare a seconda che la configurazione preveda la stessa istanza di SQL Server e volumi di disco diversi, un'istanza di SQL Server diversa sullo stesso server o un'installazione di SQL Server completamente diversa. Poiché a ciascun database di monitoraggio corrisponde un processo di SQL Server Agent, è possibile aumentare la velocità effettiva del processo di gestione temporanea in modo da soddisfare i requisiti di velocità richiesti dai servizi supportati.

A fronte della struttura illustrata, è importante tenere presente che il livello di monitoraggio End-to-End AppFabric funziona solo per i servizi che utilizzano lo stesso archivio di monitoraggio, ovvero in casi diversi da quelli descritti in questa sezione. È possibile adottare una topologia ibrida per consentire il rilevamento di attività end-to-end nei casi in cui un gruppo logico di servizi esegue la registrazione dei dati di rilevamento in un singolo archivio, mentre altri servizi non correlati appartenenti allo stesso ambiente eseguono la registrazione dei dati in archivi di monitoraggio diversi o aggiuntivi.

  2012-03-05
Mostra: