Configurazione di nodi host

Ad eccezione dei database condivisi di Microsoft AppFabric 1.1 per Windows Server, ciascun nodo host di una Web farm AppFabric costituisce un server host autonomo con funzionalità complete. In ultima analisi, il livello complessivo di prestazioni e gestibilità di una Web farm AppFabric è determinato dalla configurazione e dalle prestazioni di ogni singolo nodo.

Configurazione di Distributed Transaction Coordinator (DTC)

Quando si utilizza DTC per il supporto delle transazioni, le impostazioni predefinite della relativa funzionalità di registrazione potrebbero non essere adeguate a supportare una determinata soglia della velocità effettiva e delle prestazioni richieste. Per impostazione predefinita, le attività di DTC vengono registrate in un file di registro da 4 MB contenuto nella cartella C:\Windows\system32\MSDtc. In casi di carico di lavoro eccessivo, le dimensioni e la posizione del file di registro possono trasformarsi in colli di bottiglia. È quindi consigliabile effettuare le seguenti operazioni:

• Regolare le dimensioni del file di registro, assegnando 1 MB di spazio di registrazione ogni 1000 transazioni DTC simultanee. È possibile stimare la frequenza delle transazioni e, a partire da questo valore, calcolare le dimensioni del file di registro. In alternativa, è possibile eseguire il monitoraggio della velocità effettiva utilizzando la console Servizi componenti e regolare le dimensioni del file di registro nel modo appropriato.

• Ancora più importante delle dimensioni del file di registro è la posizione in cui questo viene memorizzato. È preferibile inserire il file di registro in un'unità fisica separata da quella contenente il sistema operativo.

Le impostazioni descritte vengono gestite tramite la console Servizi componenti illustrata nella figura riportata di seguito.

Per ulteriori informazioni sulle dimensioni e sulla posizione del file di registro DTC, vedere la sezione relativa alla gestione dei file di registro per le transazioni distribuite.

Servizi di Windows per AppFabric

Nei casi in cui ciascun nodo della Web farm AppFabric emetta un elevato numero di eventi rilevati (oltre 10.000-15.000 al secondo), è consigliabile registrare e configurare più istanze del Servizio di raccolta eventi. Mentre, dal punto di vista dell'architettura, la distribuzione del Servizio Gestione flussi di lavoro è limitata alla configurazione predefinita di una singola istanza per ciascun nodo AppFabric, il Servizio di raccolta eventi può essere configurato per l'utilizzo di più istanze. Per una descrizione delle operazioni necessarie per configurare più istanze del Servizio di raccolta eventi, vedere Creare più servizi di raccolta eventi. Inoltre, per aumentare la velocità effettiva del servizio di raccolta eventi, è necessario utilizzare più istanze del servizio insieme a vari archivi di monitoraggio, come descritto più avanti nella documentazione.

Pool di applicazioni IIS

La corretta configurazione di pool di applicazioni IIS consente di ottimizzare le prestazioni di AppFabric. Poiché AppFabric utilizza le funzionalità di WAS per eseguire l'hosting effettivo dei servizi, il processo eseguibile e le relative impostazioni di runtime vengono determinati dalla configurazione dei pool di applicazioni IIS. Per impostazione predefinita, quando si installa AppFabric e successivamente si distribuiscono i servizi e le applicazioni Web, per l'hosting di tutti gli elementi viene utilizzato DefaultAppPool. La condivisione di un pool tra più applicazioni implica quanto segue:

• Tutte le applicazioni condividono la stessa identità.

• Il limite delle richieste in coda è condiviso tra le applicazioni.

Il riciclo di un pool di applicazioni per un qualsiasi motivo, ad esempio per modificare la configurazione di un servizio in esecuzione nel pool, avrà effetto su tutte le applicazioni Web ospitate dal pool. Durante la pianificazione del numero di pool di applicazioni da includere nell'ambiente in uso, è opportuno prendere in considerazione anche i seguenti aspetti:

• Utilizzo della memoria – Un pool di applicazioni appena inizializzato può occupare fino a 25 MB di RAM per l'hosting di servizi WCF basati su codice e fino a 50-60 MB per l'hosting di servizi WF. È consigliabile verificare in modo empirico che l'hardware sia in grado di supportare la struttura progettata del pool di applicazioni distribuendo la soluzione in un ambiente di prova e monitorando l'utilizzo della memoria sotto carico. Se la memoria si trasforma in un collo di bottiglia, è possibile aggiungere memoria fisica o raggruppare ulteriormente i servizi e le applicazioni Web in pool condivisi.

• Gestibilità – Se l'ambiente in uso include un numero elevato (nell'ordine delle centinaia) di servizi e applicazioni Web, la gestione di numerosi pool di applicazioni dedicati può costituire un carico di lavoro eccessivo per l'amministratore di sistema. Anche in questo caso, la soluzione consiste nel ridurre il numero di pool dedicati mediante il raggruppamento logico di servizi e applicazioni Web in pool condivisi.

In generale, in un ambiente di grandi dimensioni è consigliabile utilizzare un pool di applicazioni dedicato per l'hosting di un gruppo logicamente correlato di servizi e applicazioni Web. È ad esempio accettabile che tutti i servizi di elaborazione degli ordini di acquisto siano ospitati in un unico pool di applicazioni, mentre i servizi di gestione delle retribuzioni siano inclusi in un pool di applicazioni dedicato. Il raggruppamento di servizi e applicazioni Web consente di ottenere un buon bilanciamento tra i livelli di gestibilità, isolamento in fase di esecuzione e prestazioni. A causa dei numerosi fattori e delle considerazioni relative all'ambiente in uso che influiscono sulla scelta tra pool di applicazioni condivisi e dedicati, non è opportuno fornire istruzioni specifiche a riguardo. È tuttavia necessario valutare la possibilità di raggruppare le applicazioni in pool condivisi.

Opzioni e considerazioni relative alla distribuzione dei servizi

Un altro aspetto da valutare durante l'operazione di distribuzione è la possibilità di raggruppare i servizi in applicazioni Web. Se ad esempio la soluzione utilizzata richiede l'attivazione di 50 servizi, è necessario scegliere se creare 50 applicazioni Web con un unico servizio ciascuna o se raggruppare diversi o tutti i servizi in una o più applicazioni Web. Di seguito sono illustrate le principali conseguenze di un approccio eccessivamente granulare in cui ciascun servizio venga incluso in una specifica applicazione Web:

• Gestibilità – In presenza di un numero eccessivo di applicazioni da gestire, la manutenzione dei file e delle impostazioni di configurazione è molto dispendiosa in termini di tempo. Individuare un servizio specifico tra le numerose applicazioni visualizzate nella console MMC Gestione IIS può risultare molto impegnativo.

• Prestazioni – Il Servizio di raccolta eventi e il Servizio Gestione flussi di lavoro effettuano la sottoscrizione alle notifiche di modifica del file Web.config per aggiornare i servizi di runtime in base alle modifiche apportate alla configurazione. Poiché AppFabric si basa su un'infrastruttura di configurazione dell'ereditarietà ASP.NET a più livelli, in caso di modifica di un file è spesso necessario eseguire l'analisi dell'intera gerarchia di nodi delle applicazioni. Più grande è la gerarchia, maggiore è l'impatto dell'aggiornamento della configurazione di runtime sul Servizio di raccolta eventi e sul Servizio Gestione flussi di lavoro. Questo determina anche livelli più elevati di utilizzo della CPU e della memoria.

Analogamente a quanto affermato per la pianificazione dei pool di applicazioni, negli ambienti appropriati è consigliabile raggruppare in modo logico più servizi in un'applicazione Web. AppFabric è stato progettato per la gestione di un numero di applicazioni Web molto elevato. Tuttavia, per ottenere livelli ottimali di prestazioni e gestibilità, è necessario limitare più possibile il numero di tali applicazioni. Tenendo presenti i punti esaminati in precedenza e le considerazioni elaborate nella sezione "Pool di applicazioni IIS", nella figura riportata di seguito viene illustrata una topologia di distribuzione comune contenente diversi servizi all'interno di un'applicazione Web e più applicazioni che condividono un pool di applicazioni comune.

La topologia illustrata presenta le seguenti caratteristiche principali:

• I servizi che possono essere supportati da una configurazione comune di monitoraggio e salvataggio permanente e che sono logicamente correlati vengono distribuiti in un'unica applicazione Web. Nella figura precedente questi servizi sono raggruppati nelle applicazioni Web 1 e 4, che ospitano diverse istanze.

• Le applicazioni Web che possono utilizzare la stessa identità ed essere riavviate insieme dopo una modifica della configurazione condividono lo stesso pool. Nella figura precedente le applicazioni Web 1 e 2 vengono eseguite nel pool di applicazioni 1. Viene invece effettuato il provisioning di pool diversi nei casi in cui per i servizi sia richiesto l'isolamento in relazione all'identità e/o alla disponibilità in fase di esecuzione.

• Grazie all'inclusione di un mix di pool condivisi e dedicati, la topologia tiene conto del sovraccarico di memoria dei pool di applicazioni. In tal modo, vengono ridotti il numero totale di pool e l'utilizzo della memoria nell'ambiente IIS. Con il contenimento del numero totale delle principali applicazioni Web viene inoltre migliorato il livello di gestibilità.

  2012-03-05