Host principali e gestione cluster (Memorizzazione nella cache di AppFabric 1.1)

Un cluster di cache Microsoft AppFabric 1.1 per Windows Server è un gruppo dinamico di server che interagiscono per fornire una cache logica unificata per i dati dell'applicazione. A tale scopo, per gestire le operazioni del cluster tra gli host della cache è necessario un overhead aggiuntivo. Il ruolo di gestione cluster è responsabile della gestione degli host della cache e di conseguenza del cluster di cache.

Esistono due opzioni principali per l'esecuzione del ruolo di gestione del cluster di cache. La prima opzione prevede che questo ruolo venga eseguito da speciali host della cache denominati host principali. Tale opzione viene anche definita "onload". Le seconda opzione prevede invece che il ruolo di gestione venga eseguito da SQL Server. Tale opzione viene anche definita "offload" poiché la responsabilità viene trasferita dal cluster di cache a SQL Server.

Se i dati di configurazione del cluster di cache vengono archiviati in una cartella di rete condivisa (XML), è necessario utilizzare l'opzione di onload con gestione da parte degli host principali. Tali host eseguono le stesse attività di memorizzazione nella cache degli altri host non designati come principali, ma hanno in aggiunta le responsabilità di collaborare con altri host principali per l'esecuzione del ruolo di gestione del cluster.

In Windows Server AppFabric 1.0, per impostazione predefinita un cluster di cache che archivia i dati di configurazione in SQL Server esegue l'offload del ruolo di gestione del cluster su SQL Server. In AppFabric 1.1 sono state apportate alcune modifiche. Per impostazione predefinita, nei nuovi cluster di cache viene sempre utilizzata l'opzione di onload in cui il cluster viene gestito dagli host principali. La disponibilità del cluster di cache risulta pertanto migliorata. Il cluster può infatti rimanere parzialmente in funzione se l'archivio di configurazione, costituito da un file XML o da un database di SQL Server, non è disponibile. In una situazione di questo tipo le operazioni di ispezione o modifica della configurazione del cluster di cache non saranno disponibili.

È comunque possibile eseguire l'offload di tutte le responsabilità di gestione del cluster di cache su SQL Server. È innanzitutto necessario creare manualmente il cluster di cache con il comando New-CacheCluster e impostare il parametro Offloading su "true". L'altro requisito è costituito dal parametro Provider che deve essere impostato su SQL Server (System.Data.SqlClient).

Nella seguente tabella viene mostrato in che modo la scelta effettuata durante l'installazione è correlata alle opzioni prescelte per la gestione del cluster. Per ulteriori informazioni sulla scelta delle opzioni di configurazione appropriate, vedere Opzioni di archiviazione della configurazione del cluster.

Attività del ruolo di gestione cluster

Esistono due impostazioni principali per stabilire il funzionamento del cluster in termini di gestione:

• leadHostManagement: con questa impostazione a livello di cluster si stabilisce quale sistema eseguirà il ruolo di gestione del cluster. Se impostata su true, gli host principali eseguono il ruolo di gestione del cluster Se si è scelto di archiviare le impostazioni di configurazione del cluster in una cartella di rete condivisa, l'impostazione true rappresenta l'unico valore valido. Se impostata su false, SQL Server o un provider personalizzato eseguirà il ruolo di gestione del cluster. Se si utilizza SQL Server o un provider personalizzato per archiviare le impostazioni di configurazione del cluster, sarà possibile impostare il valore su true per consentire agli host principali di eseguire il ruolo di gestione del cluster.

• leadHost: con questa impostazione a livello di host della cache si stabiliscono gli host della cache che verranno considerati host principali in situazioni in cui questi ultimi eseguono il ruolo di gestione Anche se SQL Server dovesse eseguire il ruolo di gestione del cluster, durante l'installazione verranno designati gli host principali, qualora si modificasse in seguito l'impostazione leadHostManagement.

Per ulteriori informazioni sulla modifica di queste impostazioni, vedere Impostare il ruolo di gestione dei cluster e le designazioni degli host principali (AppFabric 1.1).

Gli host principali eseguono il ruolo di gestione del cluster

Quando le impostazioni leadHostManagement e leadHost sono su true, l'host della cache viene elevato a un livello di responsabilità maggiore nel cluster ed è designato come host principale. Oltre alle operazioni normali dell'host della cache relative alla memorizzazione dei dati della cache, l'host principale funziona anche con altri host principali per la gestione delle operazioni del cluster.

In caso di guasti all'host principale

Per garantire la disponibilità del cluster di cache, è necessario che la maggior parte degli host principali sia disponibile. Tale condizione è più rischiosa per cluster di dimensioni ridotte rispetto a quelli di grosse dimensioni perché sarà necessario un minor numero di guasti del server affinché quest'ultimo si arresti.

Ad esempio, considerare il cluster di cache con sei server mostrato nel seguente diagramma. In questo esempio, gli host principali eseguono il ruolo di gestione del cluster e due host della cache sono stati designati host principali.

Anche se uno degli host della cache normali inclusi nel cluster dovesse guastarsi, il cluster può continuare a funzionare. I dati sugli host principali andranno persi (presumendo che la funzionalità di disponibilità elevata non fosse abilitata), ma il resto del cluster potrebbe continuare a funzionare e ad archiviare i dati. In effetti, il cluster può continuare a funzionare anche nel caso avesse perso i quattro host della cache non designati come host principali.

Se solo su uno degli host principali si sono verificati errori, l'intero cluster di cache si arresta perché non sarebbero in esecuzione la maggior parte degli host principali. Per limitare il problema, è possibile designare altri host principali.

Designazione di altri host principali

È possibile designare altri host principali dopo l'installazione. Tuttavia, è importante considerare che anche l'assegnazione di troppi host principali può comportare problemi:

• Per garantire la disponibilità del cluster di cache, è necessario che la maggior parte degli host principali sia disponibile. Maggiore sarà il numero di host designati come principali, minore sarà il numero di errori server che il cluster potrà sostenere e rimanere funzionante.

• In cluster di ridotte dimensioni dove uno o due errori degli host principali potrebbero provocare l'arresto del cluster, è consigliabile designare un maggior numero di host principali.

• In cluster di grosse dimensioni, un numero compreso tra cinque e sette di host principali dovrebbe essere sufficiente per garantire il funzionamento di un cluster che includa circa 50 server cache.

Per ulteriori informazioni sulla modifica delle designazioni degli host principali, vedere Impostare il ruolo di gestione dei cluster e le designazioni degli host principali (AppFabric 1.1).

Modifiche in Microsoft AppFabric 1.1 per Windows Server

Per aumentare la disponibilità del cluster di cache, in AppFabric 1.1 è stata modificata la procedura per la designazione degli host principali predefiniti. Ciascun host della cache aggiunto al cluster verrà impostato automaticamente come host principale fino a un massimo di sette host principali. Sarà comunque possibile designare altri host principali utilizzando il comando Set-CacheHostConfig con il parametro IsLeadHost impostato su "true". È anche possibile rimuovere il ruolo di host principale per un host della cache impostando IsLeadHost su "false".

SQL Server esegue il ruolo di gestione del cluster

Se il cluster della cache è stato creato con l'opzione di offload abilitata, l'impostazione leadHostManagement è false. In questo scenario, a prescindere dall'impostazione leadHost, ciascun host della cache esegue esclusivamente le normali responsabilità di host non principale correlate alla memorizzazione dei dati nella cache. L'istanza di SQL Server utilizzata per archiviare le impostazioni di configurazione del cluster viene inoltre utilizzata per eseguire il ruolo di gestione del cluster.

In caso di errore di un server

Per consentire al cluster di rimanere disponibile quando SQL Server esegue il ruolo di gestione del cluster (offload), è necessario che uno o più host della cache siano in grado di accedere al database di SQL Server.

Ad esempio, considerare il cluster di cache con sei server mostrato nel seguente diagramma.

In questo esempio, SQL Server esegue il ruolo di gestione del cluster e tutti i sei host della cache possono dedicare le proprie risorse all'accesso dati per i client della cache.

Se si verificano errori su uno degli host della cache nel cluster, i dati presenti su tali server andranno persi (presumendo che la funzionalità di disponibilità elevata non sia abilitata) ma il cluster continuerà a funzionare. I dati presenti negli altri host della cache continueranno a essere disponibili per gli altri client della cache. In effetti in questo scenario, il cluster potrebbe continuare a funzionare anche se perdesse cinque dei sei host della cache.

Se si verificano errori su SQL Server, l'intero cluster viene arrestato in pochi minuti. Per limitare il problema, è consigliabile utilizzare la funzionalità clustering di failover di Microsoft Windows Server 2008 all'indirizzo (https://go.microsoft.com/fwlink/?LinkId=130692 - Informazioni in lingua inglese) per l'hosting di una risorsa di un database incluso "nel cluster" per il percorso di archiviazione della configurazione cluster di cache e per il ruolo di gestione del cluster.

Vedere anche

Concetti

Diagramma dell'architettura fisica della memorizzazione nella cache di AppFabric (Memorizzazione nella cache di AppFabric 1.1)
Diagramma dell'architettura logica della memorizzazione nella cache di AppFabric (Memorizzazione nella cache di AppFabric 1.1)

  2012-03-05