Le applicazioni odierne sono altamente transazionali e possono scalare per transazioni elevate eseguendo un'implementazione multi-server con bilanciamento del carico. Allo stesso tempo, molte di queste applicazioni devono essere eseguite in più data center. Questo potrebbe essere fatto per il ripristino di emergenza, in cui un data center attivo ha il ripristino di emergenza come data center passivo che di solito si trova in una posizione geografica diversa. Un altro motivo è che se gli utenti di questa applicazione sono distribuiti geograficamente, otterranno tempi di risposta più rapidi in quanto accedono contemporaneamente al proprio data center nella loro regione.
NCache Dettagli Bridge per la replica WAN NCache Docs
La cache richiede la replica WAN proprio come il database
Quando si hanno applicazioni in esecuzione in più data center, la cache deve essere replicata. Questo perché la cache conserva i dati temporanei e, se la cache si interrompe, i dati vengono persi. I dati transitori possono essere sessioni ASP.NET, dati arbitrari generati dall'applicazione o dati aggregati. Tuttavia, i dati temporanei non sono permanenti, quindi non vengono mai archiviati nel database, vengono solo memorizzati nella cache.
Gli altri dati NCache conserva per motivi di prestazioni sono i dati dell'applicazione. Se perdi questi dati, si ricarica dal database, il che danneggia le prestazioni. Molte aziende non vogliono occuparsene a causa dell'elevato traffico di applicazioni. Questo è il motivo per cui anche i dati dell'applicazione devono essere replicati attraverso la WAN se si dispone di una distribuzione multi-datacenter.
NCache Dettagli Replica WAN NCache Docs
Soluzione: NCache Replica WAN tramite Bridge
Per far fronte alla situazione di cui sopra, NCache fornisce una funzionalità di replica WAN tramite un bridge. Questo ti permette di distribuire NCache su più data center in configurazioni attivo-passivo, attivo-attivo, 3+ data center attivo-attivo.
2-Sito Attivo-Passivo
In una configurazione attiva-passiva, NCache viene implementato su entrambi i siti attivi e passivi, creando una topologia bridge sul sito attivo. La Figura 1 mostra come questo è strutturato in una configurazione attivo-passivo. Tutti gli aggiornamenti dell'applicazione vengono inviati dalla cache del sito attivo al bridge, che li invia in modo asincrono al sito passivo entro millisecondi. L'unico ritardo qui è la latenza tra data center se sono molto distanti. Quindi, una topologia bridge con un meccanismo di accodamento asincrono consente a tutti questi aggiornamenti di avvenire senza traboccare nulla.
NCache Dettagli Modalità di sincronizzazione della cache NCache Docs
2-Sito Attivo-Attivo
Un'altra configurazione che NCache supporti è attivo-attivo, dove entrambi i siti sono attivi. Uno contiene la topologia della cache e del bridge e l'altro contiene solo la cache. La figura 2 mostra come questo è fatto. Simile all'attivo-passivo, in attivo-attivo, una cache invia i suoi aggiornamenti al bridge, che a sua volta li invia ad altre cache. Tuttavia, ora c'è una differenza. Possono verificarsi conflitti quando lo stesso elemento viene aggiornato su entrambi i lati contemporaneamente. Ciò significa che il bridge deve coordinare gli aggiornamenti da entrambi i siti e risolvere i conflitti in modo asincrono per evitare di influire negativamente sulle prestazioni della cache su ciascun sito attivo.
NCache Dettagli Replica WAN multi-datacenter NCache Docs
3+ Sito attivo-attivo
Nella terza situazione, ci sono 3 o più data center attivi. Qui uno dei siti attivi ha cache e bridge, tutti gli altri siti hanno solo cache. In altre parole, il bridge è locale rispetto a uno dei siti, ma gli altri due siti accedono al bridge in remoto. Analogamente allo scenario attivo-attivo, in questo scenario attivo-attivo 3+ tutte le cache inviano aggiornamenti al bridge e il bridge propaga gli aggiornamenti a tutte le cache connesse. Allo stesso tempo, esegue la risoluzione dei conflitti per garantire che gli stessi dati aggiornati dalla cache non causino violazioni dell'integrità dei dati.
NCache Dettagli Topologia a ponte NCache Docs
La Figura 3 mostra tre data center attivo-attivo. NCache consente una replica della cache molto fluida e asincrona. Nessuna modifica al codice dell'applicazione. Le applicazioni non sanno nemmeno che la cache viene replicata, ma viene replicata in modo asincrono sulla WAN del data center.
Replica WAN parallela e di massa asincrona
Tutti gli aggiornamenti alla cache sono asincroni. Il motivo per cui sono asincroni è la distanza tra più data center. Questa distanza può portare a scarse prestazioni a causa della latenza. I tempi di accesso tra i server sono molto rapidi quando le applicazioni sono memorizzate nella cache nello stesso data center. Ma su una WAN, di solito è molto lento. Quindi, se non si eseguono aggiornamenti asincroni, chiunque effettui la richiesta di aggiornamento deve attendere il completamento dell'aggiornamento: aggiornamenti sincroni, che rallentano l'applicazione.
Tuttavia, la replica asincrona significa che le applicazioni e le cache in ogni sito non attendono che i propri dati vengano replicati in altri data center. I dati vengono accodati al Ponte dei lucchetti . Il bridge stesso è un cluster a due nodi, che accoda tutte le richieste di aggiornamento da tutte le cache. Per attivo-passivo, le richieste sono in coda solo dalla cache attiva e applicato in modo asincrono alla cache passiva. Se disponi di tre o più data center, il bridge applica gli aggiornamenti a più siti attivi in parallelo.
Inoltre, il bridge esegue aggiornamenti in blocco. Ciò significa che puoi combinare più elementi di dati in un'unica richiesta e inviarli ad altri siti come un'unica richiesta in blocco, riducendo notevolmente i viaggi di rete. Questa potente combinazione di replica parallela, bulk e asincrona migliora quindi le prestazioni durante la replica delle cache su più data center.
NCache Dettagli Topologia di replica WAN NCache Docs
Risoluzione del conflitto
Se disponi di più siti attivi, ognuno di questi siti può aggiornare gli stessi dati contemporaneamente. Assicurati che il tuo computer locale sia sincronizzato con il fuso orario locale. Naturalmente, non ci sono problemi se non viene aggiornato contemporaneamente. Supponiamo di aggiornare l'elemento 1 all'istante T1 e di aggiornare l'elemento 2 all'istante T2. L'aggiornamento all'ora T2 è l'ultimo aggiornamento applicato. Tuttavia, se entrambi gli aggiornamenti si verificano contemporaneamente, il file Ponte dei lucchetti deve risolvere il conflitto in uno dei due modi.
-
Logica predefinita "Last Update Wins": Il bridge recupera automaticamente il timestamp da ciascuna cache e tutte le cache hanno i loro orologi sincronizzati in modo che abbiano la stessa ora. Il bridge riceve i tempi di aggiornamento da ciascuna cache e gli ultimi aggiornamenti vengono applicati a tutte le cache. Anche in questo caso, lo scopo della risoluzione dei conflitti è applicare lo stesso aggiornamento di versione a tutte le cache per evitare problemi di integrità dei dati.
-
Gestore della risoluzione dei conflitti: Un altro modo in cui il bridge risolve i conflitti è che può fornire un gestore di risoluzione dei conflitti in base alla sua logica per l'analisi degli aggiornamenti. Poiché questo resolver è configurato con NCache, il bridge fornirà entrambe le copie dell'oggetto e il resolver analizzerà quale versione è migliore secondo la logica fornita. Ciò restituirà la versione finale al bridge e applicherà questo aggiornamento a tutte le cache.
Il seguente frammento di codice fornisce un esempio dell'implementazione del sistema di risoluzione dei conflitti distribuita nella cache:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
public class Resolver : IBridgeConflictResolver { public void Init(System.Collections.IDictionary parameters) {. . .} public ConflictResolution Resolve(ProviderBridgeItem oldEntry, ProviderBridgeItem newEntry) { var conflictResolution = new ConflictResolution(); switch (oldEntry.BridgeItemVersion) { case BridgeItemVersion.OLD: { /* Replace item with new entry */ } break; case BridgeItemVersion.LATEST: { /* Keep old entry */ } break; case BridgeItemVersion.SAME: { /* Your logic to replace entry if needed */ } break; } return conflictResolution; // Configure this implementation on cache } public void Dispose() {. . .} } |
Quindi, disponendo di un meccanismo di risoluzione dei conflitti in NCache, hai la certezza che la tua cache non perderà mai la sincronizzazione. Non avrà mai due versioni diverse degli aggiornamenti dei dati e sarà sempre coerente tra più data center.
NCache Dettagli Configura ponte Configura la risoluzione dei conflitti
Gestione del disastro in fase di esecuzione
Ora parliamo di cosa succede in caso di una situazione di disastro in cui un sito va in crash.
Attivo passivo
Caso 1: il sito passivo va giù
Una configurazione attivo-passivo funge da sito di ripristino di emergenza. Quindi, se il lato passivo si interrompe, il lato attivo continuerà a funzionare e l'applicazione continuerà a funzionare. Il bridge non può replicare i dati sul sito passivo fino a quando non si interviene per ripristinare il sito passivo. Quando si ripristina il sito passivo, si riconnette al bridge e si risincronizza, eliminando così la cache esistente e ottenendo in modo efficace una copia completa della cache del sito attivo attraverso il bridge. Al termine della sincronizzazione, passa alla normale modalità di replica WAN.
NCache Dettagli Sincronizza le cache del bridge Cache attivo-passivo
Caso 2: Il sito attivo va giù
Se il sito attivo non funziona, significa che c'è una sorta di disastro, perché il bridge è inattivo e l'applicazione è probabilmente inattiva. Devi inviare tutto il traffico ora al sito passivo che ora diventa attivo. Tutti i dati vengono replicati dal sito attivo originale al sito passivo originale, senza interruzioni per gli utenti. Il sito passivo originale è ora attivo, quindi tutti gli aggiornamenti avvengono qui, ma gli utenti non vedono interruzioni.
Tuttavia, una volta che il sito attivo originale è di nuovo attivo, si connette al nuovo sito attivo (il sito passivo originale) e si sincronizza stesso completamente. Al termine della sincronizzazione, entrambi sono attivo-attivo anche se tutto il traffico va al sito passivo originale. Hai la flessibilità di scaricare tutto il traffico sul sito attivo originale e modificare lo stato del sito attivo-attivo in passivo sul ponte. NCache ti consente di fare tutto questo in fase di esecuzione senza alcuna interruzione in caso di disastro attivo-passivo.
Attivo-attivo
Quando il sito attivo con il bridge diventa inattivo, la replica WAN si interrompe perché il bridge è inattivo. Tuttavia, altri siti attivi continueranno a funzionare e tutto il traffico verrà indirizzato a loro. Dopo aver attivato il sito inattivo, puoi avviare il bridge e connettere il sito attivo al bridge, in modo che entrambi i siti siano sincronizzati. Tutto questo viene fatto in fase di esecuzione, quindi non è necessario alcun tempo di inattività. Una volta sincronizzati i bridge, entrambi i siti saranno in grado di scambiarsi gli aggiornamenti. NCache fornisce quindi tolleranza ai guasti.
NCache Dettagli Modalità di sincronizzazione della cache NCache Docs
3+ siti attivi
La terza situazione è quando si hanno 3 o più siti attivi in cui un sito ha il bridge e gli altri no. In questo caso possono verificarsi due scenari, come accennato.
Caso 1: il sito attivo non bridge si interrompe
In questo caso, altri siti continueranno a replicarsi a vicenda e il traffico di questo sito verrà reindirizzato agli altri siti collegati senza interrompere gli utenti. Una volta che il sito è attivo, si riconnette al bridge e si risincronizza per ottenere l'ultima copia della cache. Questo è il segnale per rimettere in carreggiata il traffico.
NCache Dettagli Cambia le modalità di sincronizzazione della cache Topologia a ponte
Caso 2: Il sito attivo con il ponte crolla
Nel caso in cui il bridge si interrompa, gli altri due siti attivi continuano a funzionare, ma non sono in grado di replicare reciprocamente i propri aggiornamenti perché non c'è il bridge. Quindi, quello che puoi fare in questo momento è avviare un ponte in uno degli altri due siti attivi.
Per avviare il bridge, sono necessari due nodi come a gruppo. Idealmente, dovresti avere un set dedicato di server per il topologia del ponte su quel sito, ma puoi anche utilizzare due cache server come cluster poiché molto probabilmente è temporaneo. Tuttavia, potrebbe avere un certo impatto sulle prestazioni su quei server cache perché ora il bridge consuma anche risorse come CPU e memoria.
Devi effettuare l' iniziare il ponte su uno dei siti attivi in cui entrambi i siti attivi sono già in esecuzione. La cache in esecuzione può ora connettersi a un bridge. Quindi, entrambi si connettono a un bridge e si sincronizzano replicando tutti gli aggiornamenti tra loro. Gli utenti non subiscono alcuna interruzione poiché i due siti sono sincronizzati e si propagano reciprocamente gli aggiornamenti. Quindi, se un sito non funziona, non perdi alcun dato.
NCache Dettagli Aggiungi cache in cluster Gestione del ponte
Ora, una volta ripristinato il sito originale con il bridge, puoi semplicemente:
- Prendi il ponte sul sito temporaneo.
- Rimuovere il ponte dalla cache esistente.
- Porta il ponte sul sito originale.
- Collega tutte le cache a questo nuovo bridge.
Poiché puoi connettere la cache al bridge in fase di esecuzione, NCache ti consente di automatizzare tutto questo lavoro attraverso lo scripting in modo da poter gestire senza problemi la situazione in cui un sito bridge si interrompe e devi ripristinarlo.
Conclusione
NCache ti offre un potente meccanismo di replica WAN che ti consente di gestire molti scenari avanzati diversi. Inoltre, esegue la replica WAN in modo rapido ed efficiente e gestisce data center attivo-passivo, attivo-attivo o tre o più attivi-attivi.