Replica WAN per la distribuzione multi-datacenter di NCache
Webinar registrato
Di Ron Hussain e Zack Khan
Questo webinar ti mostrerà tutto ciò che devi sapere sul NCache Funzionalità bridge per la replica WAN della cache tra i data center.
Ecco di cosa tratta questo webinar:
- NCacheFunzionalità Bridge per la replica WAN
- NCache Topologia Bridge (Attivo-Attivo, Attivo-Passivo, 3+ Data Center Attivo-Attivo)
- Funzionalità avanzate del ponte:
- Collega l'alta disponibilità e il failover
- Risolutore di conflitti dinamico
- Replica parallela e asincrona in blocco
- Ottimizzazione della coda
- Funzione di coda per sessioni multisito
- Opzioni di monitoraggio delle prestazioni/debug del bridge
L'argomento del webinar di oggi sarà la replica WAN per una distribuzione multi-datacenter utilizzando NCache. Nel webinar di oggi parleremo NCachefunzione di bridge. Che include anche NCachela topologia del bridge, le funzionalità avanzate del bridge NCache ha, accodamento di sessioni multisito, nonché opzioni di monitoraggio delle prestazioni del bridge e del debug.
Oggi abbiamo affrontato un argomento molto importante. In particolare, per le applicazioni distribuite in più data center. Questi potrebbero essere per vari motivi. Ad esempio, è necessario un sito di ripristino di emergenza, è necessaria l'implementazione di più data center attivo-attivo o potrebbe essere la migrazione da est a ovest dei dati di cui hai bisogno.
Quindi, abbiamo un Funzionalità di replica WAN disponibile, con l'aiuto della nostra topologia bridge e tratterò tutti i dettagli. Come utilizzare la memorizzazione nella cache degli oggetti mentre è attiva la replica WAN. Usalo per implementazioni di datacenter attivo-passivo, attivo-attivo e più attivo-attivo. Quindi, abbiamo molto da coprire. Credo che tutti possano vedere il mio schermo e sentirmi bene. Se riuscissi a ottenere conferme rapide tramite la scheda Domande e risposte di GoTo Meeting, sarebbe davvero utile e quindi inizieremo rapidamente con la presentazione. Quindi, per favore conferma, se tutti possono vedere il nostro schermo e qui va bene senza problemi.
Introduzione alla NCache
Quindi, inizierò con le informazioni di base sul motivo per cui hai bisogno di un sistema di memorizzazione nella cache distribuito come NCache? Quindi, in genere, sono le prestazioni dell'applicazione e il collo di bottiglia della scalabilità che consente il problema, che limita le prestazioni delle applicazioni in modo più veloce e quindi più affidabile.
Il livello dell'applicazione è molto scalabile. Puoi avere un'applicazione web o un'applicazione back-end. È sempre possibile creare una Web farm o una server farm di applicazioni, in cui l'applicazione può essere distribuita su più server. Il tuo carico può essere distribuito. Più server aiutano a soddisfare tutte quelle richieste di applicazioni in parallelo, in combinazione l'una con l'altra, ma tutte queste applicazioni devono comunicare con un database back-end e questo di solito è fonte di contesa. Il database diventa un collo di bottiglia in termini di prestazioni, oltre che di scalabilità, per la tua applicazione perché non puoi scalare i server di database e la sua risorsa molto costosa. Quindi, puoi sempre aumentare la scalabilità, ma c'è un limite a quanto puoi aumentare la scalabilità di un server di database? NoSQL di solito non è la risposta perché è necessario riprogettare l'applicazione. Devi smettere di usare il nostro database relazionale e iniziare a usare a NoSQL fonte di dati per utilizzarla e abbiamo anche un prodotto chiamato NosDB il quale è un NoSQL database ma stiamo progettando un modo diverso per gestirlo e quello è attraverso il sistema di memorizzazione nella cache distribuito.
Quindi, prima di tutto, la soluzione a questo problema di scalabilità è molto semplice, iniziare a utilizzare un sistema di cache distribuita in memoria. È super veloce perché è in memoria, rispetto al disco. Quindi, le prestazioni della tua applicazione miglioreranno immediatamente non appena esegui il plug-in NCache.
In secondo luogo, è un team di server. È un cluster di cache. Non è solo una singola fonte come il database. Hai più server uniti in un cluster di cache. Quindi, è uno spazio di archiviazione logico che è raggruppato in molti server che puoi scegliere di aggiungere. Ciò lo rende molto scalabile rispetto ai tuoi database relazionali. Puoi iniziare con 2 server e puoi aggiungere più server in fase di esecuzione. Quindi, lo rende sempre più scalabile e di fatto linearmente scalabile, dove puoi aggiungere più server e di conseguenza continuare ad aumentare la tua capacità di gestione delle richieste NCache. Bella cosa NCache è che lo usi in aggiunta a un database di back-end, un database relazionale. Ci sono molte funzionalità che completano l'utilizzo dei dati provenienti da un database back-end. Quindi, puoi sempre usare NCache insieme al tuo database relazionale. Non è una sostituzione delle tue origini dati relazionali. Alcuni numeri di scalabilità.
NCache è molto scalabile, poiché aggiungi più server NCache permette di gestire sempre più richieste in uscita NCache grappolo. Di recente abbiamo condotto questi test nel nostro ambiente di controllo qualità. Utilizziamo il nostro laboratorio AWS, dove abbiamo continuato ad aumentare il carico e abbiamo anche continuato ad aggiungere più server e fino a 5 NCache server, che è una configurazione molto regolare per la nostra cache distribuita. Siamo stati in grado di raggiungere 2 milioni di richieste al secondo e questa è stata una tendenza in aumento in cui, ogni volta che abbiamo aggiunto più server, abbiamo aggiunto più capacità al cluster di cache. Con una dimensione media dell'oggetto di 1 Kilobyte, questo è il tipo di prestazioni da cui puoi aspettarti NCache e con un hardware migliore puoi persino allungare questi numeri e ottenere una migliore resa delle prestazioni NCache. A proposito di questi benchmark, c'è un whitepaper e video dimostrazione pubblicata anche sul nostro sito web. Quindi, puoi anche dare un'occhiata anche a quello.
Alcuni dettagli sulla distribuzione. Come sarebbe una distribuzione tipica di NCache sembrerà.
Ecco una distribuzione su un unico sito di NCache. Come puoi vedere, abbiamo un unico sito e nel tuo caso, di cosa parliamo dell'aspetto della replica WAN, ovviamente avremmo più di una distribuzione avremmo un datacenter separato, dove avremmo anche NCache e le applicazioni distribuite.
Quindi, con la nostra distribuzione della cache distribuita, come mostrato nel diagramma, parliamo di come appare una distribuzione tipica. Quindi, abbiamo di nuovo un team di server. Abbiamo da 4 a 5 server mostrati nel diagramma, che è dove è ospitato il tuo cluster di cache e, come puoi vedere, si trova tra la tua applicazione e il database. L'idea qui è di utilizzare queste origini in combinazione l'una con l'altra, per la memorizzazione nella cache degli oggetti, ma per la memorizzazione nella cache della sessione, la cache diventa la principale fonte di dati. Quindi, tutte le tue sessioni possono essere archiviate NCache e non devi andare da nessun'altra parte. È disponibile un modello di distribuzione molto flessibile. NCache può essere ospitato in sede. Potrebbero essere scatole fisiche o virtuali. Potrebbe anche essere in cloud. Potrebbe essere cloud pubblico o privato. Potrebbe anche essere su Azure AWS, perché abbiamo immagini del mercato disponibili per entrambi questi fornitori di cloud. Ma, in generale, qualsiasi server che abbia Windows o Linux e unico prerequisito per NCache è .NET o .NET Core Struttura. Quindi, questi sono prerequisiti. È solo .NET e .NET Core quale NCache esigenze come prereq. Se è disponibile, NCache è molto flessibile per essere distribuito su Windows così come su ambienti Linux e come ho detto potrebbe essere anche qualsiasi ambiente, potrebbe essere, puoi usare Docker e puoi anche ospitare NCache nel cluster Kubernetes e questo apre molte altre piattaforme. Puoi usarlo in OpenShift. Puoi usarlo nel servizio Azure Kubernetes. Sai, anche il servizio Elastic Kubernetes. Quindi, tutte quelle piattaforme sono attrezzate e NCache è attrezzato per essere distribuito su tutte quelle piattaforme.
Sono disponibili due opzioni di distribuzione. Uno è che vai con il livello di cache dedicato, come mostrato nel diagramma e il secondo è, e in dedicato le tue applicazioni funzionano su scatole separate e NCache viene eseguito su un livello dedicato separato. Abbiamo anche un livello condiviso, disponibile anche un approccio, dove puoi anche correre NCache accanto alle caselle delle applicazioni. Quindi, ovunque siano ospitate le tue applicazioni NCache può essere ospitato su di esso. Quindi, credo che questo sia abbastanza semplice. In una distribuzione multi data center avresti più di un data center e avresti la stessa distribuzione per NCache anche sull'altro datacenter, che tratteremo nelle prossime diapositive e, a proposito, se ci sono domande, puoi sempre pubblicare quella domanda nella nostra scheda Domande e risposte e io e Zack terremo, sai, manterremo un fai attenzione a tutte quelle domande che verranno pubblicate e saremo molto felici di rispondere a tutte quelle domande per te. A proposito di domande, dal momento che l'hai menzionato proprio ora, ne ho una che vorrei sottolineare è, beh, è stato molto semplice che stavi menzionando Kubernetes ora. Quindi, la domanda era: parleremo di bridge e questo in generale, ci sono requisiti di sistema operativo per tutto questo? Riesci a eseguirlo su Linux? Assolutamente. NCache è molto flessibile. Come puoi vedere, anche sul nostro diagramma di distribuzione. Puoi vedere NCache è supportato su server Windows e Linux. Quindi, sui server Linux, hai solo bisogno .NET Core rilascio di NCache e abbiamo un server e un client per questi. Quindi, se vuoi correre NCache server su .NET su Linux utilizzando .NET Core questo è possibile e quindi le tue applicazioni possono sempre utilizzare il nostro .NET Core rilasciare ed essere distribuito su Windows e Linux, quindi sì. Stupendo. Ti lascerò effettivamente passare attraverso il resto e solleverò le domande più tardi.
Distribuzione multi-datacenter di NCache
Quindi, dopo parleremo della distribuzione di Multi-Datacenter di NCache. Ora, se la tua applicazione è distribuita su più data center, oppure potresti avere un sito attivo e quindi abbiamo un sito passivo per scenari di ripristino di emergenza. Ad esempio, il sito Active non funziona e la tua applicazione richiede che tu sia sempre attivo e funzionante, se si tratta di un'applicazione mission-critical, è importante per la tua azienda. Avere un tempo di inattività a livello di sito è qualcosa che avrebbe un impatto sulla tua attività.
NCache cluster è progettato in modo tale da essere già dotato di funzionalità di alta disponibilità e affidabilità dei dati. Quindi, a livello di un singolo sito, se uno o due server si interrompono, ad esempio se perdi un server, NCache è attrezzato per gestire tale interruzione senza problemi. Ma oggi parliamo di se noi, cosa succede se otteniamo un'interruzione a livello di sito? Oppure, dobbiamo chiudere il sito per manutenzione, poiché l'intero sito è inattivo. Quindi, tutti i server sono inattivi. NCache è persino attrezzato per gestire quello scenario e quindi è quello che stiamo pianificando di coprire oggi. Quindi, parliamo del perché abbiamo bisogno della replica WAN?
In genere, quando le applicazioni richiedono disponibilità elevata, un singolo sito può diventare un singolo punto di errore. Se il tuo sito non funziona, perdi tutti i dati e potresti potenzialmente avere tempi di inattività per gli utenti delle tue applicazioni e ciò potrebbe avere un impatto sulla tua attività, lo abbiamo già stabilito. Le app multiregione sono lente se devono comunicare tra loro attraverso la WAN. Ad esempio, hai un data center distribuito, la tua applicazione distribuita in un data center che si trova nella regione degli Stati Uniti e poi hai un'altra applicazione che è distribuita in Europa o in qualsiasi altra regione, ad esempio la regione asiatica. Quindi, in tal caso, se i database dell'applicazione si trovano in uno dei data center, il sito remoto deve passare attraverso la rete. Quindi, la velocità della tua rete influenzerebbe la latenza per quell'altro sito. Sai, per gestire questo scenario, di solito replichi le tue origini dati anche su WAN ed è quello che ti consigliamo per NCache anche quello NCache dovrebbe essere replicato. Ma, considerando che hai un'origine dati comune, il sito remoto deve passare attraverso WAN e ciò potrebbe potenzialmente avere un impatto sulle prestazioni poiché i dati non sono locali per quel sito, anche la distanza tra i data center inciderebbe sul tuo throughput . C'è solo una piccola quantità di dati che puoi trasmettere tra i siti. Quindi, ciò può limitare la tua capacità di gestione delle richieste.
Quindi, questi sono due problemi se hai app multiregionali e se entrambe le app sono attive. Anche la replica dei dati a livello di richiesta è costosa. Ad esempio, non si replica l'intero database e si dispone di un'origine dati che si trova su un data center. Ora, una richiesta che va dalla nostra posizione remota, una posizione geografica remota, al tuo database. Una replica a livello di richiesta per ogni dato, sai, unità di richiesta che arriva alla nostra fonte di dati, sarà estremamente costoso e consumerebbe molta larghezza di banda e risorse. Quindi, è necessario un meccanismo attivo, in cui i dati siano disponibili localmente ed è per questo che è necessaria la replica WAN della cache necessaria. In questo modo, i tuoi dati da un data center vengono replicati attraverso la rete all'altro sito.
Alcuni casi d'uso. Perché, sai, dove esattamente puoi utilizzare la replica WAN?
Il più comune, che incontriamo, è il sito di ripristino di emergenza. Hai un sito attivo, che serve il tuo caso d'uso aziendale principale. È lì che il tuo traffico viene generato e gestito. E se l'intero sito non funzionasse? Hai bisogno di un'opzione di riserva, giusto. Quindi, quel sito DR dovrebbe avere già i dati resi disponibili. In caso contrario, non verrebbero gestiti i requisiti relativi ai dati se dovesse tornare al sito che è già inattivo, giusto. Quindi, è necessario che i dati siano resi disponibili sul sito DR, in modo che siano già attivi e funzionanti. Devi solo spostare il tuo traffico su quel sito DR. Non dovresti fare nient'altro, devi solo indirizzare il tuo traffico al sito di ripristino di emergenza e dovrebbe funzionare con lo stesso valore di prestazioni, le stesse matrici di prestazioni che avevi con il sito attivo. Quindi, è possibile il recupero dei dati al 100% in caso di guasto, con l'aiuto di NCache Replica WAN.
Le applicazioni multiregionali possono condividere dati e caricare. Ora, con i siti Active-Active, se hai una regione negli Stati Uniti e una in un'altra parte del mondo, ad esempio Europa o Asia. Se lo vuoi, sai, la richiesta da, sai, un datacenter dovrebbe essere gestito in base all'affinità di posizione, puoi ottenerlo. Ora, l'utente dall'Asia può connettersi a un sito all'interno di quella regione, più vicino a quella regione e possono utilizzare la cache anche lì e quella cache è sincronizzata con l'altra cache che si trova nella regione degli Stati Uniti. Quindi, qualsiasi utente che rimbalza. Ad esempio, è necessario gestire l'overflow o è necessario distribuire la capacità. Alcuni degli utenti hanno bisogno, ora devono rimbalzare nella regione degli Stati Uniti perché la regione asiatica è completamente soffocata, quindi puoi sempre farlo. Quindi, a livello di sito, puoi bilanciare il carico della tua richiesta, in base alla capacità che il sito sta gestendo in quel momento e in quel momento. Poiché i dati della cache sono già replicati tra i data center e parleremo di come raggiungerli, le tue applicazioni multiregionali sono in grado di condividere in modo efficiente i dati delle loro applicazioni e anche di condividere il carico delle richieste e possono anche avere la stessa condivisione del carico . Non viene eseguita alcuna migrazione dei dati ridondante. Si basa solo sulla richiesta che rimbalza da un datacenter all'altro e puoi sempre ottenere quei dati dalla cache che è già collegata lì.
La migrazione dei dati dell'applicazione da est a ovest è un altro caso d'uso. Ad esempio, i mercati asiatici iniziano prima rispetto, sai, ai mercati occidentali, giusto. Quindi, la tendenza dei tuoi dati, di solito segue da est a ovest. Quindi, il tuo sito orientale può avere la nostra cache impostata e con il fuso orario, i dati si spostano dal datacenter alla regione occidentale e raggiungono l'ovest. Pertanto, se si dispone di dati replicati tra i data center, i dati della cache, la regione occidentale sarebbe in grado di sfruttare tutti i dati resi disponibili dalla regione orientale. Quindi, puoi rendere disponibile la migrazione dei dati da est a ovest e il caso d'uso della manutenzione è il terzo.
Quarto, in cui possiamo implementare l'aggiornamento e la manutenzione senza tempi di inattività. Sta diventando un caso d'uso molto urgente, con NCache anche. Che, se hai intenzione di eseguire l'aggiornamento, puoi avere aggiornamenti tra versioni precedenti e nuove, utilizzando la nostra topologia bridge. Laddove i dati più vecchi, i dati della versione possono essere trasmessi alla versione più recente con la funzione di aggiornamenti in tempo reale. Potrebbe essere tra siti, ad esempio, puoi utilizzare un sito e replicare attivamente i dati sul sito passivo e puoi aggiornare, distribuire un nuovo codice, mantenere le prestazioni, la manutenzione sul sito attivo e avere tutti i dati resi disponibili e il tuo il traffico può essere instradato al sito passivo per quella materia. Quindi, entrambi i siti possono essere sempre attivi e funzionanti senza zero tempi di inattività e perdita di dati dell'applicazione.
NCache Bridge per la replica WAN
Quindi, parliamo di come gestirlo? Il nome della funzione è NCache ponte. Fa parte dello stesso prodotto. Non è necessaria alcuna installazione separata per questo. NCache Enterprise è dotato di NCache topologia del ponte e parliamone.
Quindi, la nostra cache, NCache La funzione bridge consente di replicare la cache tra i datacenter.
Si basa sul modello di replica asincrono. Non incorre in alcun degrado delle prestazioni sul lato dell'applicazione. Le tue applicazioni cache sono connesse in modo attivo alla cache su un datacenter. Ad esempio, hai dei client qui e quindi puoi creare un bridge che è anche una coda attiva-passiva e che trasmetterebbe i dati agli altri siti in modo asincrono.
Quindi, si basa sulla replica asincrona, quindi non c'è alcun degrado delle prestazioni nella replica dei dati. È molto affidabile. È tollerante agli errori. Rileva automaticamente gli errori di connessione. Si riconnette automaticamente. Sono disponibili opzioni di ripetizione automatica, quindi viene eseguito il backup anche del bridge su una coda attiva-passiva.
Quindi, c'è un server Active Bridge e poi c'è anche un server Passive Bridge. Se il server Active Bridge si interrompe, il Passivo riprenderà e avvierà tutte le operazioni di replica senza alcun ritardo. È molto facile da configurare, non sono necessarie modifiche al codice, non sono necessarie installazioni aggiuntive. Fa parte dello stesso prodotto, l'Enterprise e fornisce un proprio supporto di monitoraggio e gestione, che è integrato nello stesso NCache Enterprise prodotto e supporta più topologie che tratterò in seguito.
Quindi, abbiamo tre topologie principali.
Abbiamo Attivo-Passivo. Dove abbiamo un sito attivo e poi abbiamo un sito passivo. Anche il sito passivo accetta le richieste dei clienti, ma il flusso di dati passa da attivo a passivo. Quindi, se hai requisiti per il sito DR, puoi utilizzare un sito per essere attivo, connesso al bridge e quindi puoi avere un altro sito passivo. Il sito attivo trasmette i dati al sito passivo. Quindi, è una trasmissione unidirezionale. Il termine passivo significa essenzialmente che il sito passivo non sta trasmettendo i dati ad attivo. È ancora in esecuzione e le applicazioni client ne traggono vantaggio. Quindi, non è qualcosa che viene fermato in alcun modo. La migrazione da est a ovest può essere raggiunta con il passivo attivo. La manutenzione e un caso d'uso di aggiornamento possono essere gestiti con l'aiuto di attivo-passivo.
La topologia attivo-attivo è, quando si dispone di un'applicazione distribuita in due diverse posizioni geografiche e si desidera che i dati del sito 1 siano resi disponibili nel sito 2 e i dati del sito 2 resi disponibili nel sito 1. Se l'applicazione necessita di requisiti di condivisione dei dati tra siti geografici, puoi scegliere come target attivo-attivo dove hai utenti attivi su entrambi i datacenter. I client sono collegati a entrambi i datacenter e c'è una replica bidirezionale in corso tra due siti diversi e quindi abbiamo 3, 2+ o 3+ topologia attivo-attivo, in cui abbiamo un server di offerta principale, ma sta trasmettendo i dati a tutti siti e quei siti stanno anche trasmettendo i dati a ogni altro sito. Quindi, un aggiornamento deve essere applicato a tutti i datacenter e viceversa.
Quindi, ecco il nostro attivo-passivo.
In questo abbiamo bridge, che è una coda, che è anche attiva-passiva. Abbiamo un cluster di cache sul sito 1, che è solo, sai, la gestione delle richieste dei clienti. Abbiamo 3 server qui. È collegato al ponte. Il ponte risiede anche su uno dei siti. Oppure, in alcuni casi, puoi avere un bridge attivo nel sito 1 e un server bridge passivo nel sito 2. È anche possibile, ma in genere ti consigliamo di spostare il bridge su uno dei siti nell'architettura di distribuzione. Il secondo sito è un sito passivo e di nuovo passivo è ancora in esecuzione. È solo che il sito passivo non replica i dati su quello attivo. È una trasmissione di dati a senso unico ed è tutto ciò che significa quando diciamo che questo è un sito passivo. Puoi essenzialmente eseguire applicazioni client qui ed è completamente funzionante anche in questo stato. Quindi, è una replica di dati, attivo passivo, quindi, se questo server si interrompe, il passivo viene attivato ed è automatico. Non sono necessarie modifiche al codice. Ti mostrerò come configurare il bridge, una volta che passiamo alla nostra parte pratica. Quindi, è piuttosto semplice.
È arrivata una domanda e ha a che fare con questo attivo-passivo, principalmente se hai un sito attivo e uno passivo come fai a attivare il sito passivo? È un processo manuale? Il sito è fermo? Come si fa a farlo? Ok, quindi, se ho capito bene questa domanda, il sito passivo in termini di come lo attiviamo? È già attivato. È in esecuzione e se abbassiamo questo sito o vogliamo spostare il traffico qui, è il carico di traffico dell'applicazione che devi spostare su questo sito. Quindi, hai i server delle applicazioni qui, hai i server delle applicazioni qui, tutti i dati che hai verranno trasmessi qui e gli utenti di questo sito possono avere i dati resi disponibili dalla cache stessa. Ora puoi sempre indirizzare il tuo traffico verso il sito passivo e puoi ottenere tutti i dati resi disponibili. Quindi, non sono necessari passaggi per attivarlo. Tuttavia, se desideri che questo sito inizi a trasmettere i dati anche al sito attivo, puoi renderlo attivo utilizzando i nostri strumenti GUI. Quindi, in termini di replica, se vuoi che i dati vengano replicati nell'attivo, puoi sempre renderlo attivo e questo è un processo di runtime. Quindi, puoi solo con una riga di, con un clic nello strumento GUI puoi ottenerlo oppure puoi utilizzare il nostro strumento PowerShell per farlo accadere. Ma se la tua domanda riguarda l'attivazione del nodo passivo. Se è presente un passaggio manuale per consentire alle applicazioni client di connettersi ad esso e poter utilizzare i dati, è già in esecuzione. Le tue applicazioni iniziano a usarlo se inizi a instradare il traffico a questo cluster di cache. Quindi, all'interno del tuo sistema di bilanciamento del carico. Spegni questo sito e indirizzi tutto il tuo traffico al sito disponibile, che è già attivo e funzionante e puoi ottenere/trarre vantaggio da tutti i dati che vengono replicati.
Quindi, attivo-attivo, è di nuovo basato sullo stesso principio. Dove abbiamo ponti in esecuzione su uno dei siti.
Abbiamo cache 1, cache 2. Entrambi i siti sono attivi e anche la topologia passiva può essere resa attiva, facendo clic con il tasto destro e rendendola attiva e in questo caso i dati dalla cache del sito 1 vengono trasmessi al sito 2, in modo asincrono dalla cache al bridge e dal bridge alla cache e quindi, allo stesso modo, anche il sito 2 sta trasferendo i dati al sito 1.
3+ datacenter attivi-attivi, dove abbiamo tre o più attivo-attivo, dove abbiamo uno dei siti come server bridge. Possiamo anche avere un sito di fallback per il bridge. Possiamo anche avere un sito bridge di backup. Ma, in generale, avremmo uno dei siti che ospiterebbe, che sarebbe l'hosting del bridge e quindi quel sito sta trasmettendo dati ad altri siti e allo stesso modo il sito 2 sta trasferendo i dati al sito 1 tramite il bridge e al sito 3. E per attivo -attivo, abbiamo una risoluzione dei conflitti basata sul tempo, quindi l'ultimo aggiornamento vince. Tutte le strutture dati che utilizziamo sono prive di conflitti. Questi sono tipi di dati privi di conflitti. Non ci sono condizioni di gara o problemi di coerenza dei dati che conosci perché l'ultimo aggiornamento sarà applicato al cluster di cache su tutta la linea. Così, NCache gestisce se ci sono due aggiornamenti per la stessa chiave entra, NCache lo valuterebbe e ti permetterebbe anche di costruire la tua risoluzione dei conflitti, se questo è un requisito. Quindi, è gestito come parte di NCache topologie.
Quindi, ecco una rapida occhiata alle nostre configurazioni di bridge.
Abbiamo NCache configurazione ponte NCache Bridge è il nome e poi abbiamo LondonCache ambiente 1, in modo da poter avere anche più cache con lo stesso nome. NewYorkCache e questi sono collegati.
Demo pratica NCache
Quindi, lascia che ti mostri tutto questo in azione, come configurare un bridge? Come iniziare con esso e poi ti mostreremo effettivamente le applicazioni di cache degli oggetti e cache di sessione. Prima di entrare in quel Ron, mi è venuta una domanda proprio nella diapositiva precedente con il codice e la domanda è: quali sono le modifiche al codice coinvolte per impostare il bridge? Devono scrivere del codice per replicare i dati attraverso il bridge? Affatto. Non abbiamo bisogno di alcun codice. È solo una configurazione. Quindi, hai la cache 1 sul datacenter 1 e la cache 2 sul datacenter 2. Devi semplicemente configurare il bridge e tutti i dati che sono già stati aggiunti dalle tue applicazioni in NCache, verrà replicato automaticamente tramite bridge. Quindi, è responsabilità del bridge farsi carico di tutta la replica. Non è necessario scrivere alcun codice in modo esplicito per replicare i dati nei datacenter e quando diciamo i tipi di dati, la risoluzione dei conflitti, è qualcosa che è anche implementato per impostazione predefinita, che è basato sul tempo ma se si desidera implementare il proprio risoluzione dei conflitti, se i requisiti aziendali sono la valutazione degli oggetti, nel caso in cui vengano apportati più aggiornamenti, in tal caso è possibile implementare quell'interfaccia. Ma per quanto riguarda la replica dei dati, è responsabilità del bridge. Non devi scrivere alcun codice per quello.
Crea cache
Quindi, fammi iniziare rapidamente, lo farò creare una cache.
Diciamo che chiamerò site1cache o mi lascerò effettivamente usarlo proprio qui SiteOneCache. Questo è solo per darti un'idea di come iniziare rapidamente ed essere in grado di creare il ponte. Manterrò tutto predefinito, perché NCache l'architettura copre tutti questi dettagli.
Quindi, li esaminerò rapidamente. Partizione della cache di replica, qualsiasi cluster. Replicazione asincrona della topologia. Sceglierò 101 e vediamo se riesco a scegliere 102, se è disponibile. Questi sono i miei due server, per ospitare il bridge. Manterrò tutto questo predefinito. Avvia questo e anche l'avvio automatico. Fine. Quindi, la mia cache uno è su 101 e 102, che verrà creata. Vediamo come va e poi andrò avanti e creerò un'altra cache che sarebbe su un set separato di server e poi ospiterò il bridge e ti mostrerò come funzionerebbe tutto. Destra. Quindi, abbiamo SiteOneCache completamente configurato. Come puoi vedere, anche questo è iniziato.
Ora andrò avanti e creerò in realtà, creerò un'altra cache, che è SiteTwoCache. Penso di poterlo usare. Ci stavo giocando un po' prima. Mantieni tutto semplice e questa volta fornirò un set separato di server, in modo da rappresentare questo come un sito completamente separato. Mantieni tutto predefinito e, tra l'altro, il nostro bridge ti consente di avere la gestione remota di tutti i siti, dagli strumenti di gestione e moneta ti consentono di gestire effettivamente tutti i siti insieme al bridge, da un'unica posizione centrale. Quindi, se hai accesso alla rete. Se è disponibile un collegamento WAN tra SiteOne e SiteTwo, puoi essenzialmente gestire tutto. Quindi, abbiamo SiteTwoCache proprio qui. SiteOneCache proprio qui. 101 102 che rappresentano SiteOneCache. 107 e 108 che rappresentano SiteTwoCache. Ora, e anche questi sono iniziati.
Se clicco su statistiche puoi vedere che non ci sono ancora oggetti aggiunti qui. I dati non vengono aggiunti in SiteOneCache o SiteTwoCache, quindi siamo a posto. Vorrei semplicemente eseguire questo. Penso di avere problemi con le autorizzazioni per rivedere questo contatore. Penso di poterlo fare, ok. Quindi, puoi vedere che non ci sono ancora articoli disponibili. Ora collegherò queste due cache con l'aiuto di un bridge, che configurerò in seguito.
Crea un ponte
Quindi, qui creeremo un ponte.
Quindi, mi limiterò a dire NCacheDemoBridge.
Puoi trovare qualsiasi nome e il bridge può essere su qualsiasi server. Ad esempio, su 107. Fammi solo dare la mia scatola, ecco fatto. Quindi, lasciami creare un bridge su 101 e 102. Ho problemi con le autorizzazioni. Quindi, fammi vedere se posso aggiungere 107, altrimenti userò solo un server per il bridge. Ciò richiede l'apertura di alcune porte. Quindi, penso che la mia macchina abbia tutte quelle porte aperte. Quindi, lasciami usare 101 per ora. Un server è abbastanza buono. Il server di backup non è presente ma possiamo sempre aggiungerlo e manterrò tutto predefinito e sceglierò Fine. Avvia automaticamente il bridge, quando si avvia, anche questa è una possibilità e quindi se faccio clic su Visualizza dettagli sul bridge, ad esempio, se clicco proprio qui, si aprirebbero tutte le impostazioni del bridge che abbiamo. Qui puoi specificare, puoi aggiungere più nodi al bridge, se necessario, e puoi anche aggiungere più cache, che agiranno come attive o passive. Quindi, se faccio clic su Aggiungi, per qualche motivo non mi consente effettivamente di aggiungere. Per favore, abbi pazienza con me. Posso intrufolarmi in una domanda mentre aspettiamo. Certo, per favore vai avanti. Certo, sì, ne è appena uscito uno. È piuttosto semplice, ha a che fare con il modo in cui garantisci una trasmissione sicura dei dati? Abbiamo funzionalità di crittografia disponibili. Quindi, se hai attivato la crittografia o la sicurezza a livello di cache, il bridge lo obbedirà. Quindi, qualsiasi trasmissione trasmessa tra CacheOne e CacheTwo verrà crittografata, se la crittografia e la sicurezza sono disattivate, attivate. Quindi, abbiamo anche fornitori di crittografia conformi a AES, DES e FIPS. Abbiamo anche TLS 1.2 supportato. Quindi, abbiamo Transport Level Security, così come le funzionalità di crittografia Payload Level Security. Quindi, puoi sfruttare queste funzionalità.
Aggiungi cache al ponte
Va bene, quindi selezionerò una delle cache, SiteOneCache proprio qui, giusto. Quindi, posso scegliere se essere Attivo o Passivo. Vado con Active e scelgo Finish.
Quindi, SiteOneCache viene aggiunto sotto il ponte. Ora aggiungerò la seconda cache, che è da 107 box. Spero di essere in grado di aprire il gestore del controllo del servizio. Sono. Selezionalo, SiteTwoCache. Facciamolo di nuovo Attivo. Se si sceglie Passivo, sarà la cache dal sito uno al sito due, ma se si sceglie attivo, sarà tra il sito uno e il sito due e il sito due al sito uno per la replica dei dati. Scegliamo la finitura.
Monitora le statistiche del ponte
Quindi, puoi anche rivedere i contatori bridge. Ad esempio, se vengo proprio qui e apro le statistiche del bridge da qui, posso sempre vedere anche i contatori del bridge. Permettimi di iniziare prima questo. Per qualche ragione, il sistema non è molto reattivo, quindi per favore abbi pazienza e fammi aprire la finestra delle statistiche. Quindi, ecco il nostro ponte. Non viene ancora replicato nulla perché non abbiamo alcun carico.
Quindi, mi limiterò a simulare un po' di carico eseguendo uno strumento di stress test, siteonecache.
Dal momento che abbiamo contatori disponibili, avremmo un client connesso e inizieremmo a simulare. Sebbene l'abbiamo eseguito solo per SiteOneCache, non appena si connette. Quindi, per favore abbiate pazienza con me. Quindi, fammi aprire effettivamente il monitor per verificare se è effettivamente collegato alla cache o meno. Io penso che sia. Quindi, il bridge ha delle attività, quindi, il che suggerisce che il bridge ora sta accettando le richieste. L'ambiente è un po' fiacco oggi. Mi scuso per questo, ma esaminiamo come va. Ok, quindi, dal momento che il bridge mostra attività. La dimensione della cache del bridge sta crescendo, le operazioni ricevute e poi ricevute al secondo mostrano attività. Quindi, ciò significa essenzialmente che sta replicando i dati tra i siti. Ecco qua. Quindi, abbiamo SiteOneCache proprio qui.
Se apriamo il, fammi effettivamente accedere al nostro ambiente demo, in modo da vedere la corretta visualizzazione dei contatori da lì. Penso che ciò dovrebbe aiutarci a esaminare anche eventuali problemi relativi alle autorizzazioni perché ci vuole molto tempo per caricare effettivamente questo e non sono in grado di vedere anche l'attività di contrasto. Tutto bene. Quindi, permettetemi di avviare questo web manager qui. Ecco qua. Quindi, anche se in precedenza non mostrava i contatori, sullo schermo locale, ma quando ho effettuato l'accesso a SiteTwoCache da quel server, il web manager è completamente in grado di vedere tutti i contatori. Quindi, abbiamo contato attivamente replicato. Non ho mai eseguito alcuno strumento di stress all'interno di due cache, ma sta attivamente ricevendo dati qui. Ora, se lo interrompo o anche se lo tengo in esecuzione, ora posso eseguire uno strumento di stress anche per SiteTwoCache e che replicherebbe anche i dati sul mio SiteOneCache. Quindi, questo completa i nostri test. Penso che dovrei limitarmi ad avere accesso remoto anche in questo ambiente, in modo che possiamo vedere l'attività separatamente su entrambi gli ambienti. Quindi, userò semplicemente siteonecache da qui, bridge da qui e sitetwocache da lì.
Successivamente tratterò alcuni casi d'uso relativi alle applicazioni. Quindi, per favore fatemi sapere se ci sono domande? È solo una domanda piuttosto semplice, ma riguardava principalmente quali ambienti supportiamo? Ancora una volta, so che ne hai menzionato un paio prima, ma ho pensato che potresti semplicemente elencarli tutti in basso. Come ho detto, l'unico prerequisito per NCache è .NET o .NET Core. È possibile utilizzare NCache su ambienti Windows e Linux, ovunque siano disponibili. Potrebbe essere on-premise, potrebbe essere un ambiente cloud, potrebbe essere Azure, AWS, Google Cloud o qualsiasi altro. Potrebbe essere anche un ambiente ospitato. È disponibile in Docker, tramite Docker Container e puoi utilizzare Docker Images per ospitare la tua cache e le tue applicazioni. Sono supportati anche Kubernetes. OpenShift, Servizio Kubernetes, menzionato Servizio Azure Kubernetes, Servizio Kubernetes elastico. Quindi, ovunque tu possa usare Docker, puoi usarlo NCache laggiù e si riduce a un semplice fatto che se hai .NET Core o .NET installato, questo è l'unico prerequisito per NCache ed NCache può essenzialmente funzionare su tutte quelle piattaforme, su tutti quei server.
Eseguire un'applicazione di esempio
Quindi, fammi davvero correre, anche se sto usando questo bridge proprio qui, ho un altro bridge che è disponibile. Quindi, fammi eseguire un'altra applicazione, che è proprio qui. È un'applicazione web con bilanciamento del carico. L'abbiamo progettato in modo tale da poter instradare una richiesta su un datacenter e se tale datacenter è inattivo, la richiesta successiva andrebbe all'altro datacenter. Quindi, ciò essenzialmente ti darebbe una visione di come gestire il ripristino di emergenza, se lo hai NCache bridge attivato e avrai tutti i tuoi dati resi disponibili.
Quindi, prima di tutto, lo eseguirei da qui, dove abbiamo, lasciami aprire questo da questa finestra, proprio qui. Quindi, vorrei iniziare con l'esempio di memorizzazione nella cache degli oggetti. Bene, allora lasciami gestire questo LondonCache campione e poi fammi aprire anche l'altro campione disponibile. Quindi, inizierò con Visual Studio. Esecuzione dei campioni. Quindi, non appena questi esempi vengono eseguiti, ti mostrerei che puoi essenzialmente utilizzare la memorizzazione nella cache degli oggetti e instradare la richiesta tra i data center secondo necessità.
Quindi, ciò ti darebbe una rappresentazione visiva dei dati aggiunti da un datacenter e recuperati da un altro e viceversa attraverso il nostro bridge. Va bene, quindi, questo sta usando un LondonCache che ho configurato proprio qui. Se te lo mostro velocemente. Quindi, abbiamo un LondonCache e abbiamo NewYorkCache. Quindi, due cache che rappresentano due datacenter e poi abbiamo un bridge che è NCache ponte. Ha LondranCache come CacheOne attivo e NYCache come secondo. Quindi, per ora fermerò il ponte. Ti mostro queste due cache separatamente e poi simulerò alcuni dati e ti mostrerò come funziona nella cache. Quindi, lascialo funzionare e non appena si carica e questo sta usando NYKCache, quindi lasciami girare anche questo. Ora che sai come configurare il bridge, quindi, è molto semplice collegare queste due cache insieme eseguendo lo strumento di gestione su qualsiasi box ed essere in grado di configurare quel bridge. Quindi, per favore abbiate pazienza con me. Farebbe girare alcuni casi. Oggi è terribilmente lento, me ne scuso. Quindi, il suo evento costruito è stato completato, quindi lo simulerà a breve. Bene, quindi, questo è il nostro Main.aspx e all'interno di questo sto solo caricando alcuni oggetti nella cache. Questo è tutto ciò che sto facendo. Ad esempio, all'interno di, a destra, quindi, se ti mostro Main.aspx sta effettivamente caricando alcuni degli oggetti nella cache. Quindi, l'idea qui è che avremmo colpito il sito della regione di Londra e poi avremmo colpito la regione di New York e poi ti mostrerò come sincronizzare i dati aggiunti dalla regione di Londra a New York e viceversa e una rappresentazione visiva renderebbe tutto molto più chiaro in confronto. Quindi, abbiamo entrambe le parti in gioco. Lascia che ne apra uno proprio qui e l'altro proprio qui. Ora, se aggiungo diciamo 10 elementi, cosa che consente. Vengono aggiunti 10 articoli. Se recupero dalla stessa cache, viene visualizzato che questi dati vengono aggiunti dalla regione del Regno Unito e i clienti del Regno Unito vengono visualizzati proprio qui.
Allo stesso modo, se aggiungo dati dal portale di Londra, Stati Uniti, vengono aggiunti 10 elementi e quindi vengono visualizzati tutti quei 10 elementi, ma cosa succede se, se l'utente rimbalza e ha bisogno dei dati di entrambe le regioni per essere resi disponibili, contemporaneamente? Quindi, non è ancora possibile. Permettetemi di aggiungere altri 5 elementi qui, in modo che questo sia diverso in termini di numeri. Quindi, abbiamo circa 15 articoli qui e 10 articoli qui. Quindi, con un solo clic di distanza, se accendo questo bridge, a destra, e apro le statistiche, la prima cosa che il bridge, sai, fa è in realtà replicare tutti i dati che sono già nelle cache.
Quindi, le cache sono già collegate, non appena abbiamo avviato il bridge. Abbiamo replicato il bridge, replicando 25 elementi. Quindi, questo è esattamente ciò che abbiamo aggiunto. Quindi, se apro i contatori di, fammi aprire il LondonCache, nonché NewYorkCache e statistiche aperte. Per qualche motivo ci vuole tempo, ma alla fine si aprirà. Ora, abbiamo le statistiche proprio qui.
Abbiamo clienti collegati e abbiamo il valore di conteggio mostrato proprio qui. Quindi, mostra circa 25 elementi ed è quello che vedi anche su NewYorkCache. Ora tornando alla mia applicazione, manterrei la stessa applicazione in esecuzione, ma questa volta preleverò semplicemente i dati da qui e mi aspetto di vedere tutti gli elementi nella cache. Quindi, tutti i 25 articoli, Londra e gli articoli statunitensi sono stati recuperati qui perché i dati replicati in bridge da CacheOne a CacheTwo e CacheTwo a CacheOne. Quindi, 15 elementi qui vengono ora aggiunti con altri 10 elementi a 25 elementi insieme e se recupero i dati dalla cache, l'USCache, vedo anche tutti gli elementi nella regione degli Stati Uniti. Quindi, ancora una volta è una trasmissione a due vie. Potrebbero essere più di due. Potrebbe essere attivo-passivo. Dove la trasmissione unidirezionale può essere eseguita o attiva-attiva come mostrato nell'applicazione di esempio.
Ora, qualsiasi nuovo oggetto viene aggiunto, diciamo, altri 20 oggetti aggiunti, diciamo e prendi da qui, ottieni 45 oggetti e se prendo quegli oggetti da qui vedresti 45 oggetti qui. Quindi, è istantaneo. Qualsiasi elemento qui aggiunto qui, diciamo, aggiunge dati su, ciò aumenterebbe il conteggio da 45 a 68 ma se recupero i dati da qui, ottengo gli stessi elementi resi disponibili da qui. Quindi, guarda quanto è veloce replicare i dati tra siti diversi. Quindi, queste due cache lo sono e queste cache sono anche in esecuzione su più server mentre parliamo. Quindi, questo completa la nostra dimostrazione di memorizzazione nella cache degli oggetti.
Replica delle sessioni ASP.NET nei data center
Lascia che ti mostri anche come gestirlo se stai utilizzando sessioni ASP.NET. In più siti, sai, puoi anche avere sessioni ASP.NET. Quindi, ad esempio, se questo avviene tramite un sistema di bilanciamento del carico, aggiungerei solo alcuni elementi, è un'applicazione separata. Abbiamo due server Web, un server Web del sito e un server Web del sito due, che ospitano la stessa applicazione in tutti i data center. Quindi, aggiungerò solo alcuni elementi. Quindi, non appena aggiunge e lasciami fermare il ponte ancora una volta. Se visualizzo il carrello. Quindi, abbiamo un elemento aggiunto. Diciamo di aggiungere altri elementi. Quindi, abbiamo alcuni articoli messi a disposizione. Ora, se vado su IIS, sai, il sito di Londra. Lasciami iniziare anche questo, giusto. Riporta qui, hai, spero davvero che colpisca il sito di Londra come priorità. Non abbiamo elementi laggiù, quindi vediamo dove finisce e poi collegheremo il bridge e ti mostreremo che tutti i dati che aggiungi dal sito uno sono resi disponibili sul sito due e viceversa. La prima richiesta è solitamente lenta. Ho appena avviato l'applicazione, ecco qua. Quindi, se arriviamo qui, riceviamo 0 articoli restituiti. Quindi, questi due siti non sono sincronizzati, anche se la tua sessione utente rimbalza da un sito all'altro, ogni volta che avviiamo o arrestiamo il sito.
Ora, accenderei semplicemente il ponte, sulla stessa linea, come abbiamo fatto prima. Destra. Quindi, funzionerebbe e inizierà. Ancora una volta, vedrò le statistiche. Quindi, ci sono 69 articoli, sai, questi provengono dal test precedente. Ma ora, se torno al mio sito proprio qui. Destra. Ricominciamo. Abbiamo aggiunto alcuni elementi. Continuiamo a farlo. Per coincidenza, se questo o se si interrompe a causa di un'interruzione di corrente o se lo interrompi, se spengo il sito di Londra, l'unico sito è, sai, il sito di New York è ancora attivo e funzionante, quindi, se basta premere Visualizza carrello, gli stessi elementi di dati sono resi disponibili dal portale degli Stati Uniti e sono stati aggiunti i dati dal sito del Regno Unito. Quindi, puoi vedere i dati rimbalzati da un sito all'altro e il tuo utente continua a recuperare i dati. Ora, se anche il sito tornasse, sai, tornasse online, sarebbe di nuovo in grado di recuperare tutti i dati della sessione dalla cache.
Sessioni ASP.NET multisito
Allo stesso modo, abbiamo sessioni ASP.NET multisito. Questa è una caratteristica separata. Quindi, consigliamo il bridge per i tuoi scenari di memorizzazione nella cache degli oggetti, in cui abbiamo molta trasmissione di dati che avviene dietro le quinte tra due cache e l'abbiamo visto per la memorizzazione nella cache degli oggetti e per la memorizzazione nella cache della sessione.
Ma per la memorizzazione nella cache della sessione, abbiamo anche il caso d'uso della memorizzazione nella cache della sessione ASP.NET multisito. Quindi, se non uso il bridge. Posso ancora collegare questi due siti insieme e questo è attraverso una funzione separata che è disponibile e per questo interromperò semplicemente il bridge. Non appena si fermerà, tornerò qui. Fammi solo cancellare i contenuti, in modo da ricominciare da capo e questo è in realtà un modo migliore per sincronizzare la tua cache per la cache della sessione. Motivi per ciò, la sessione è un dato molto transazionale. Quindi, non vuoi che i dati della tua sessione vengano replicati, anche se il tuo utente non rimbalza da un sito all'altro, giusto. Quindi, se il tuo utente si trova principalmente su un sito e perché è un utente umano con sessioni ASP.NET. Quindi, in tal caso si tratta di un dato transazionale di natura transitoria, non sarebbe necessario sull'altro sito. Si basa solo sull'utente presente e se finisci per cambiare utente da un sito all'altro, ciò potrebbe essere gestito con la replica su richiesta dei dati. Non è necessario replicare tutti i dati della sessione. Ad esempio, l'overflow si verifica dove un sito è più grande, raggiungendo più capacità di un altro e si desidera che gli utenti in overflow vadano all'altro sito e hanno già creato un oggetto sessione qui. Quindi, non hai bisogno di tutte le sessioni lì. Hai solo bisogno di sessioni di quel particolare utente. Quindi, per far fronte a quello scenario, non ti consigliamo di accendere il bridge.
Quindi, per questo abbiamo un'altra funzione chiamata NCache Sessione multisito. Quindi il provider di stato delle sessioni ASP.NET multi-regione ti consente di ottenere effettivamente tutto ciò, senza utilizzare il bridge.
Quindi, hai la cache del sito uno, che ha sessioni e abbiamo la cache del sito due e il sito uno ha l'indirizzo della cache principale e quindi l'indirizzo della cache di backup in tutta la regione e allo stesso modo la cache del sito due ha un concetto primario e di backup. Quindi, se un utente rimbalza da un sito all'altro, i tuoi client cache, che sono i tuoi server delle applicazioni, andrebbero all'altro sito su richiesta e otterrebbero i dati della sessione resi disponibili da lì e tutto ciò di cui hanno bisogno sono le informazioni nella cache dell'altro sito , ad esempio, abbiamo cache primaria e cache secondaria, Londra, New York e puoi avere più cache di backup. Quindi, nel caso in cui l'utente di Londra rimbalzi sul sito di New York, tornerebbe a LondonCache e prenderebbe i dati e li manterrebbe lì e per dimostrare che avrei ricominciato con un'applicazione cache. Ad esempio, aggiungo alcuni dati qui, anche in questo caso sta usando LondonCache. Aggiungi elementi qui. Ricorda che ho cancellato il contenuto nella cache, quindi non abbiamo elementi qui e allo stesso modo lasciami aprire LondonCache statistiche. Quindi, non abbiamo elementi qui, fino a quando non arriva la prima richiesta. Diciamo, aggiungi. Quindi, abbiamo due elementi, con lo stesso nome ovviamente. Quindi, una sessione viene creata qui. Non è stato ancora replicato sul sito di New York, ma abbiamo abilitato la funzione di sessione multisito. Non abbiamo bisogno di bridge per questo, perché vogliamo che venga eseguita la replica della sessione su richiesta. Abbiamo eseguito queste configurazioni, in cui abbiamo cache primaria e cache secondaria e quindi abbiamo collegato il provider dello stato della sessione.
Quindi, si basa solo sulle impostazioni del provider dello stato della sessione, NCache è in grado di gestire casi d'uso di sessioni multisito senza utilizzare il bridge ed è su richiesta, quindi è molto più efficiente per quanto riguarda i dati di sessione. Quindi, quello che farei ora è rimbalzare la richiesta di sessione su un altro sito andando su IIS e interromperei completamente il sito di Londra. Ovviamente manterrei la cache attiva e funzionante e se ora lo recupero. Prima di tutto, otterrebbe i dati dal sito statunitense. Gli stessi oggetti sarebbero stati resi disponibili da lì e non appena completato, aggiungerei qualche altro oggetto e porterei il LondonCache eseguire il backup in linea. Quindi, è una replica su richiesta, che sto cercando di dimostrare. Allora, vediamo come va. Diciamo che aggiungo alcuni elementi. Quindi, permettetemi di riportare questo sito online. Dal momento che è appiccicoso al sito di Londra. Quindi, ora che ho riportato l'utente statunitense sul sito di Londra, vediamo come va. Pertanto, gli stessi elementi sono resi disponibili anche dal sito di Londra e gli elementi di dati sono stati aggiunti dalla regione degli Stati Uniti. Se aggiungo qualche altro elemento qui, sarei in grado di aggiungere anche quegli elementi qui. Permettetemi di simulare questo errore ancora una volta fermando questo sito e vediamo se rimbalza anche dall'altra parte. Penso che in precedenza ci siano alcuni problemi relativi alla configurazione, ma ora che questo sito è stato interrotto. Fammi solo vedere il carrello. Mi aspetto, ecco qua. Quindi, la stessa sessione è ora resa disponibile dal sito statunitense e ricorda che non ho alcun bridge configurato qui per questa funzione, è solo la sessione multisito. Il ponte è fermo. Sta ancora replicando i dati ma è su richiesta. Quindi, questo in realtà lo completa.
Per la memorizzazione nella cache degli oggetti e dati meno transazionali, dati di riferimento e dati statici, ti consigliamo di attivare il bridge e sfruttare la replica attiva tra i data center, ma la sessione è un caso d'uso transazionale che ha una richiesta di lettura e scrittura, sai, una combinazione. Quindi, è molto pesante mentre aggiorni i dati da un data center all'altro, i dati sono già cambiati nel data center principale e l'utente della sessione non rimbalza da un data center all'altro. Sarebbe solo su un sito in un dato momento. Quindi, non è necessaria la replica dei dati attiva. Puoi avere la replica su richiesta. Quando rimbalza dalla regione uno alla regione due, dovresti essere in grado di ottenere i dati della sessione da lì e se ritorna alla regione uno, dovresti essere nuovamente in grado di ottenere i dati della sessione resi disponibili e per questo ti consigliamo di utilizzare la nostra funzione di sessione multisito senza bridge.
Ci sono alcune funzionalità avanzate di cui discuterei rapidamente.
Il ponte è altamente disponibile. Il supporto per il failover è integrato, qualsiasi server bridge che si interrompe non comporterà alcun tempo di inattività. La coda del bridge è molto ottimizzata. È veloce. Inoltre, puoi abilitare alcune funzioni di ottimizzazione della coda, che lo renderebbero ulteriormente ottimale.
La risoluzione dei conflitti è incorporata in esso. L'ultimo aggiornamento vince, ma se vuoi implementare la tua risoluzione dei conflitti, puoi utilizzare un gestore e registrarti NCache. Quindi, questa interfaccia può essere chiamata, nel caso in cui ci sia un conflitto di due chiavi, in cui si verificano due aggiornamenti contemporaneamente. Così, NCache ti darebbe il controllo e puoi verificare la versione di quell'elemento e decidere quale vince.
Gestione del disastro in runtime. Zack inizialmente ha chiesto come rendere Attivo il sito Passivo, devi solo instradare il traffico verso il Passivo.
Se il sito attivo si interrompe e non ci sono tempi di inattività e la risincronizzazione automatica si verifica se l'attivo torna a funzionare. In Active-Active il traffico viene instradato verso entrambi i siti. Qualsiasi sito che non funziona non avrebbe alcun impatto, devi solo reindirizzare il traffico all'attivo e se l'attivo l'altro attivo torna online, la risincronizzazione viene eseguita automaticamente. Non ci sono ritardi, nessun intervento manuale necessario. In due più o tre o più casi Attivo-Attivo, se il sito attivo non bridge si interrompe, è sufficiente utilizzare il traffico verso qualsiasi altro sito e non ci sarebbero tempi di inattività o perdita di dati. Nel caso, il sito attivo del bridge non funziona, ad esempio, se abbiamo un sito bridge proprio qui.
Se questo non funziona, abbiamo anche un'opzione per il backup del sito del bridge. Quindi, puoi abilitare quel sito bridge e per questo puoi specificare il bridge di backup per raccogliere la replica. Pertanto, la replica si interromperebbe se l'intero sito bridge si interrompe, ma abbiamo anche l'opzione di backup del sito bridge.
Quindi, voglio coprire questi aspetti molto velocemente. Penso che per ora dovrebbe essere sufficiente. Qualche domanda finora? Zack puoi prenderlo da qui. Certo, lo so, stiamo correndo all'ultimo minuto o due qui, quindi inserirò solo una domanda che è arrivata su ciò che hai rivisto proprio ora. Aveva a che fare con la risoluzione dei conflitti e credo che la domanda sia: quali sono gli esempi di risoluzione dei conflitti in cui avremmo bisogno di implementarla? Bene. In genere, la maggior parte della risoluzione dei conflitti viene gestita per impostazione predefinita, dove non è necessario implementare nulla. La risoluzione dei conflitti basata sul tempo è tutto ciò di cui hai bisogno. Con l'aspettativa che tu stia eseguendo siti attivi e attivi e hai bisogno di dati da un data center all'altro, hai bisogno di aggiornamenti da un data center all'altro. Quindi, l'ultimo aggiornamento vince. Ma, nel caso in cui i dati siano più specifici e desideri avere un valore dei dati e ciò determinerebbe quale oggetto dovrebbe essere mantenuto nel bridge. Ad esempio, nella definizione dell'oggetto è presente una determinata versione o determinate informazioni o un determinato numero di sequenza, ad esempio esiste un attributo di versione di un oggetto. Quindi, se c'è un conflitto, non vuoi che quell'oggetto venga perso. Quindi, controlli quell'oggetto attraverso il codice, verifichi la versione, quale è necessario conservare, quindi, in base all'ultima versione o all'ultima versione rispetto al tempo, potrebbe essere basata sulla versione. Potrebbe anche essere basato sul valore dell'oggetto. Ad esempio, c'è un record di database e hai un oggetto che rappresenta quel database e che ha un'ora modificata. Quindi, quello non è l'aggiornamento sulla cache, è un aggiornamento sul database ma quel tempo di aggiornamento fa parte di quell'oggetto e se quell'oggetto è stato aggiunto prima e poi un altro oggetto viene sovrascritto, non vuoi che l'ultimo aggiornamento su il database da perdere, giusto? Quindi, se c'è qualcosa all'interno dell'oggetto e devi prendere una decisione in base ai valori degli attributi, devi implementare tu stesso la risoluzione dei conflitti per questo. Ma come ho detto, la maggior parte della risoluzione dei conflitti verrà gestita per impostazione predefinita tramite l'opzione predefinita della base dei tempi. Quindi, qualunque aggiornamento arrivi per ultimo, verrà applicato come l'ultimo aggiornamento sull'elemento e questo accade solo ricorda che questa logica di risoluzione dei conflitti entrerebbe in gioco solo se ci sono due aggiornamenti aggiunti contemporaneamente nella coda sul bridge. Giusto, quindi, bridge riceve due aggiornamenti contemporaneamente. Allora, quale scegliere? Il sito uno ha aggiunto o aggiornato un elemento e anche il sito due ha aggiunto o aggiornato lo stesso elemento. Quindi, il bridge ora deve decidere quale tenere nella cache o in coda e questo è ciò che viene replicato anche nel sito uno e nel sito due. Perché uno deve vincere sull'altro. Quindi, la risoluzione dei conflitti basata sul tempo è implementata per impostazione predefinita e ciò ti farebbe superare la maggior parte dei tuoi casi.
Vi lascio a voi, c'è qualcos'altro che stiamo esaminando? Penso che stiamo bene. Per quanto riguarda i contenuti. Bene. La dimostrazione è completata. Va bene, stiamo correndo proprio all'ultimo minuto qui, quindi grazie a tutti quelli che sono venuti fuori. In caso di domande relative a questo specifico webinar, non esitare a inviarci un'e-mail all'indirizzo support@alachisoft.com Sicuramente, vai sul nostro sito Web e scarica una prova gratuita di 2 mesi NCache Enterprise e usalo nel tuo ambiente. Se desideri assistenza per l'onboarding, puoi contattare support@alachisoft.com e se hai altre domande su se vuoi acquistare NCache o per ottenere informazioni sulla licenza, non esitare a contattarci sales@alachisoft.com.