Disponibilità elevata (Memorizzazione nella cache di Windows Server AppFabric)

Quando è attivata la disponibilità elevata, una copia di ciascun oggetto o area della cache viene mantenuta su un host della cache distinto. Tali copie vengono gestite dal cluster di cache che le invia all'applicazione nel caso in cui le copie principali non siano disponibili. Per attivare la disponibilità elevata per le applicazioni abilitate alla cache non sono necessarie modifiche al codice. Nella figura seguente viene illustrato il modo in cui le copie di oggetti e le aree vengono memorizzate su host distinti quando è attivata la funzionalità di disponibilità elevata.

Panoramica disponibilità elevata "Velocity"

Configurazione della disponibilità elevata

La disponibilità elevata viene configurata a livello di cache nelle impostazioni di configurazione del cluster. Trattandosi di una proprietà della cache, può essere attivata al momento della creazione della cache utilizzando il comando New-Cache con il parametro Secondaries uguale a 1. Tale parametro indica ai cmdlet di Windows PowerShell di amministrazione della cache che si desidera una copia di ciascun oggetto o area della cache. Se si imposta il parametro Secondaries su 0, la funzione di disponibilità elevata viene disattivata. Per impostazione predefinita, l'opzione di disponibilità elevata viene disattivata quando si crea una nuova cache. Per ulteriori informazioni sulla modifica delle impostazioni di configurazione della cache, vedere Modificare le impostazioni di configurazione della cache con Windows PowerShell (Memorizzazione nella cache di Windows Server AppFabric).

La funzione di disponibilità elevata delle funzionalità di memorizzazione nella cache di Windows Server AppFabric richiede che in tutti i nodi del cluster di cache sia in esecuzione Enterprise Edition (o versione successiva) di Windows Server 2008 o Windows Server 2008 R2. Confermare che tutti i nodi cache a disponibilità elevata siano in esecuzione su un sistema operativo supportato. Per ulteriori informazioni sui sistemi operativi supportati, vedere la sezione relativa ai requisiti software della AppFabric Installation Guide (Guida all'installazione di AppFabric) (https://go.microsoft.com/fwlink/?LinkId=169172) (informazioni in lingua inglese).

Archiviazione delle copie secondarie

La posizione in cui vengono archiviate le copie secondarie degli oggetti e delle aree viene scelta dal cluster di cache. In AppFabric gli oggetti della cache vengono distribuiti tra tutti gli host della cache del cluster. Lo stesso accade anche per le copie secondarie di tali oggetti.

Modalità di gestione della coerenza

A prescindere dal fatto che sia attivata la disponibilità elevata, le applicazioni abilitate alla cache funzionano come se esistesse solo la copia primaria degli oggetti della cache. Tutte le chiamate di metodo Add, Put e Remove vengono iniziate dapprima sull'oggetto principale sull'host della cache nel quale risiedono. Una volta avviata la chiamata all'host della cache in cui risiede la regione o l'oggetto primario, l'azione risultante varia a seconda che la disponibilità elevata sia abilitata o meno.

Se è attivata la disponibilità elevata, esiste un passaggio aggiuntivo che consiste nell'inviare una notifica all'host che gestisce la copia secondaria relativa al fatto che sta per verificarsi una modifica. Quindi, l'host della cache con la copia principale dell'oggetto attende di essere riconosciuto dall'altro host prima di informare il client che l'operazione è completa.

Per un esempio, vedere gli host della cache A e B della figura seguente. Non appena l'host della cache A riceve una richiesta, ne avvia l'elaborazione e notifica l'host della cache B della modifica. Quindi l'host della cache B invia un riconoscimento all'host della cache A. Quando l'host della cache A riceve il riconoscimento, completa la modifica e reinvia un riconoscimento all'applicazione abilitata alla cache. Grazie a questo processo è possibile assicurare che la copia secondaria dell'oggetto o dell'area si trovi sempre nello stesso stato della COPIA principale. Il processo viene denominato coerenza affidabile.

Coerenza disponibilità elevata "Velocity"

Considerazioni sulle prestazioni

Poiché l'host della cache che gestisce la copia secondaria dell'oggetto o dell'area deve riconoscere tutte le modifiche relative alla copia principale, i tempi di risposta delle scritture dall'applicazione abilitata alla cache incidono negativamente sulle prestazioni. Tuttavia, l'impatto sulle prestazioni non influisce sulle letture delle voci già presenti nella cache. È necessario inoltre considerare il tempo necessario per ricaricare la cache con gli oggetti se l'host della cache che gestisce le copie principali di tali oggetti viene perso.

Conseguenze in caso di errore di un host della cache

In caso di errore di un host della cache (presumendo che il numero di host della cache disponibili sia comunque sufficiente a mantenere in esecuzione il cluster) non si verificano cambiamenti per l'applicazione abilitata alla cache. Il cluster di cache reindirizza le richieste per l'oggetto all'host della cache nel quale viene mantenuta la copia secondaria dell'oggetto. All'interno del cluster, le copie secondarie di tutti gli oggetti principali vengono elevate in modo da diventare i nuovi oggetti principali. Quindi, le copie secondarie di tali nuovi oggetti principali vengono distribuite ad altri host della cache nel cluster. Gli oggetti secondari nell'host della cache nel quale si è verificato l'errore vengono sostituiti dai nuovi oggetti secondari e distribuiti nel cluster. Tale processo si applica anche alle aree.

Per fare in modo che la funzionalità di disponibilità elevata consenta di isolare l'applicazione dall'errore di un host della cache, è necessario che almeno tre host della cache siano membri del cluster di cache. Ciò è dovuto a un requisito di coerenza affidabile in base al quale devono esistere due copie di un oggetto o di un'area della cache in una cache abilitata alla disponibilità elevata. Per mantenere due copie di una cache o di un'area, una cache abilitata alla disponibilità elevata deve disporre di almeno due host della cache funzionanti.

Si supponga, ad esempio, che sia stata creata una cache abilitata alla disponibilità elevata denominata HACache in un cluster di cache a tre server come mostrato nella tabella seguente. Si supponga che SQL Server sia stato configurato per svolgere il ruolo di gestione del cluster (per cui in questo esempio non è necessario considerare la perdita potenziale di host principali).

Data e ora 1 host cache 2 host cache 3 host cache HACache (cache specifica abilitata alla disponibilità elevata)

T1

in esecuzione

in esecuzione

in esecuzione

disponibile

T2

in esecuzione

in esecuzione

arrestato

disponibile

T3

in esecuzione

arrestato

arrestato

non disponibile

In T1, quando sono disponibili tre host della cache, due copie degli oggetti o delle aree della cache possono essere archiviate su uno dei tre server disponibili. In T2, in caso di errore di un server di cache, HACache continua a essere disponibile in quanto sono disponibili altri due host della cache per archiviare le due copie di oggetti della cache o aree. In T3, al momento dell'errore del secondo host della cache, HACache diventa indisponibile. Infatti, non è più disponibile un altro host della cache per archiviare la seconda copia degli oggetti o delle aree della cache.

Altri suggerimenti relativi alla disponibilità elevata

Per ottimizzare la disponibilità dei dati della cache, prendere in considerazione i suggerimenti seguenti:

  • Utilizzare un numero elevato di host della cache.

  • Distribuire il sistema di cache distribuita all'interno del perimetro di un firewall, con tutti i server membri dello stesso dominio, inclusi i client cache, gli host della cache, il server di origine dati principale e il server in cui è ospitato il percorso di archiviazione della configurazione del cluster.

  • Utilizzare SQL Server o un provider personalizzato per memorizzare le impostazioni di configurazione del cluster di cache.

  • Ridurre al minimo eventuali modifiche costose della configurazione che richiedono l'arresto del cluster. Se possibile, ricreare determinate cache invece di arrestare l'intero cluster di cache per apportare modifiche alla configurazione della cache nelle impostazioni di configurazione del cluster.

  • Utilizzare sempre il comando Stop-CacheHost per arrestare il servizio cache prima di riavviare un server. Quando gli host principali svolgono il ruolo di gestione del cluster, il cmdlet Stop-CacheHost avrà esito negativo se l'azione di arresto del servizio cache causa l'arresto completo dell'intero cluster di cache (se non è presente una maggioranza di host principali in esecuzione).

Vedere anche

Concetti

Diagramma dell'architettura fisica della memorizzazione nella cache di Windows Server AppFabric
Diagramma dell'architettura logica della memorizzazione nella cache di Windows Server AppFabric

  2011-12-05