Replicação de WAN para implantação de vários datacenters de NCache

Webinar gravado
Por Ron Hussain e Zack Khan

Este webinar mostrará tudo o que você precisa saber sobre o NCache Recurso de ponte para replicação de cache de WAN entre data centers.

Aqui está o que este webinar aborda:

NCacheRecurso Bridge do WAN para Replicação WAN
NCache Topologia de ponte (ativo-ativo, ativo-passivo, 3+ data centers ativo-ativo)
Recursos avançados de ponte:
- Alta disponibilidade e failover de ponte
- Resolvedor dinâmico de conflitos
- Replicação assíncrona paralela e em massa
- Otimização de fila
Recurso de sessões de vários sites de fila
Opções de monitoramento de desempenho/depuração da ponte

O tópico do webinar de hoje será Replicação de WAN para uma implantação de vários datacenters usando NCache. No webinar de hoje, abordaremos NCacherecurso de ponte do . Que também inclui NCachetopologia de ponte do , os recursos avançados de ponte NCache tem, enfileiramento de sessões multi-site, bem como desempenho de ponte e opções de monitoramento de depuração.

Hoje temos alinhado um tema muito importante. Especificamente, para aplicativos implantados em vários datacenters. Estes podem ser por vários motivos. Por exemplo, você precisa de um site de DR, precisa de implantação de vários data centers ativo-ativo ou pode ser a migração de dados de leste para oeste de que você precisa.

Então, temos um Recurso de replicação WAN disponível, com a ajuda de nossa topologia de ponte e cobrirei todos os detalhes. Como usar o cache de objetos enquanto a replicação de WAN está ativada. Use-o para implantações de ativo-passivo, ativo-ativo e vários ativos-ativos, você sabe, datacenter. Então, temos muito a cobrir. Acredito que todos podem ver minha tela e me ouvir bem. Se eu puder obter confirmações rápidas por meio da guia de perguntas e respostas do GoTo Meeting, isso seria muito bom e, em seguida, iniciaremos rapidamente a apresentação. Então, por favor, confirme, se todos puderem ver nossa tela e aqui está tudo bem sem problemas.

Introduction to NCache

Então, vou começar com as informações básicas sobre por que você precisa de um sistema de cache distribuído como NCache? Portanto, normalmente, é o gargalo de desempenho e escalabilidade do aplicativo que permite o problema, que limita o desempenho de seus aplicativos de maneira mais rápida e confiável.

Sua camada de aplicativo é muito escalável. Você pode ter um aplicativo da Web ou um aplicativo de back-end. Você sempre pode criar um web farm ou um farm de servidores de aplicativos, onde seu aplicativo pode ser implantado em vários servidores. Sua carga pode ser distribuída. Vários servidores ajudam a atender todas essas solicitações de aplicativos em paralelo, em combinação entre si, mas todos esses aplicativos precisam se comunicar com um banco de dados de back-end e isso geralmente é uma fonte de contenção. O banco de dados se torna um gargalo de desempenho, bem como de escalabilidade para seu aplicativo, porque você não pode escalar servidores de banco de dados e seu recurso muito caro também. Então, você sempre pode escalar, mas há um limite de quanto você pode escalar um servidor de banco de dados? NoSQL geralmente não é a resposta para isso porque você precisa re-arquitetar seu aplicativo. Você precisa parar de usar nosso banco de dados relacional e começar a usar um NoSQL fonte de dados para usar isso e também temos um produto chamado NosDB que é um NoSQL database mas estamos projetando uma maneira diferente de lidar com isso e que é através do sistema de cache distribuído.

Então, em primeiro lugar, a solução para este problema de escalabilidade é muito simples, você começa a usar um sistema de cache distribuído na memória. É super rápido porque está na memória, em comparação com o disco. Portanto, o desempenho do seu aplicativo será melhorado imediatamente assim que você plugar NCache.

Em segundo lugar, é uma equipe de servidores. É um cluster de cache. Não é apenas uma única fonte como banco de dados. Você tem vários servidores unidos em um cluster de cache. Então, é um armazenamento lógico, você sabe, que é agrupado por muitos servidores que você pode optar por adicionar. Isso o torna muito escalável em comparação com seus bancos de dados relacionais. Você pode começar com 2 servidores e adicionar mais servidores em tempo de execução. Assim, torna-o cada vez mais escalável e, de fato, linearmente escalável, onde você pode adicionar mais servidores e, como resultado, continua aumentando sua capacidade de tratamento de solicitações NCache. Coisa legal sobre NCache é que você o usa além de um banco de dados back-end, um banco de dados relacional. Existem muitos recursos que complementam o uso de dados provenientes de um banco de dados de back-end. Então, você sempre pode usar NCache em conjunto com seu banco de dados relacional. Não é uma substituição de suas fontes de dados relacionais. Alguns números de escalabilidade.

NCache é muito escalável, à medida que você adiciona mais servidores NCache permite que você lide com mais e mais solicitações de NCache conjunto. Recentemente, realizamos esses testes em nosso ambiente de controle de qualidade. Usamos nosso laboratório da AWS, onde continuamos aumentando a carga e adicionando mais servidores e até 5 NCache servidores, que é uma configuração muito regular para nosso cache distribuído. Conseguimos atingir 2 milhões de solicitações por segundo e essa foi uma tendência de aumento crescente, onde, sempre que adicionamos mais servidores, adicionamos mais capacidade ao cluster de cache. Com um tamanho médio de objeto de 1 Kilobyte, esse é o tipo de desempenho que você também pode esperar de NCache e com um hardware melhor você pode até esticar esses números e obter um rendimento de desempenho melhor NCache. A propósito, esses benchmarks, há um whitepaper e de um vídeo demonstração publicada em nosso site também. Então, você também pode dar uma olhada nisso também.

Alguns detalhes de implantação. Como seria uma implantação típica de NCache vai se parecer.

Aqui está uma implantação de site único de NCache. Como você pode ver, nós temos um single-site e no seu caso, o que falamos sobre o aspecto de replicação WAN dele, obviamente teríamos mais de uma implantação, teríamos um datacenter separado, onde também teríamos NCache e aplicativos implantados.

Portanto, com nossa implantação de cache distribuído, conforme mostrado no diagrama, vamos falar sobre como é uma implantação típica. Então, temos uma equipe de servidores novamente. Temos de 4 a 5 servidores mostrados no diagrama, é onde seu cluster de cache está hospedado e, como você pode ver, ele fica entre seu aplicativo e o banco de dados. A ideia aqui é que você use essas fontes em combinação umas com as outras, para cache de objetos, mas para cache de sessão, o cache se torna sua principal fonte de dados. Assim, todas as suas sessões podem ser armazenadas em NCache e você não precisa ir a nenhum outro lugar. Um modelo de implantação muito flexível está disponível. NCache pode ser hospedado no local. Podem ser caixas físicas ou virtuais. Também pode estar na nuvem. Pode ser nuvem pública ou privada. Também pode ser no Azure AWS, porque temos imagens de mercado disponíveis para esses dois fornecedores de nuvem. Mas, em geral, qualquer servidor que possua Windows ou Linux e apenas pré-requisito para NCache é .NET ou .NET Core Estrutura. Então, esses são pré-requisitos. É apenas .NET e .NET Core qual NCache necessidades como pré-requisito. Se isso estiver disponível, NCache é muito flexível para ser implantado em ambientes Windows e Linux e, como eu disse, pode ser qualquer ambiente também, pode ser, você pode usar o Docker e também hospedar NCache no cluster Kubernetes e isso abre muitas outras plataformas. Você pode usá-lo no OpenShift. Você pode usá-lo no serviço Azure Kubernetes. Você sabe, o serviço Elastic Kubernetes também. Então, todas essas plataformas estão equipadas e NCache está equipado para ser implantado em todas essas plataformas.

Existem duas opções de implantação. Uma é que você vai com a camada de cache dedicada, conforme mostrado no diagrama e a segunda é, e em dedicada seus aplicativos são executados em caixas separadas e NCache é executado em uma camada dedicada separada. Também temos uma camada compartilhada, abordagem disponível também, onde você também pode executar NCache ao lado de suas caixas de aplicação. Então, onde quer que seus aplicativos estejam hospedados NCache pode ser hospedado em cima dele. Então, eu acredito que isso é bastante simples. Em uma implantação de vários datacenters, você teria mais de um datacenter e teria a mesma implantação para NCache no outro datacenter também, que abordaremos nos próximos slides e, a propósito, se houver alguma dúvida, você sempre pode postar essa pergunta em nossa guia de perguntas e respostas e Zack e eu manteremos, você sabe, manteremos um fique de olho em todas as perguntas que serão postadas e ficaremos muito felizes em responder a todas essas perguntas para você. Falando em perguntas, já que você mencionou isso agora, eu tenho uma que eu gostaria de trazer é, bem, foi muito simples você estar mencionando o Kubernetes agora. Então, a pergunta era, vamos falar sobre pontes e isso em geral, existem requisitos de sistema operacional para tudo isso? Você consegue rodar isso no Linux? Absolutamente. NCache é muito flexível. Como você pode ver, mesmo em nosso diagrama de implantação. Você pode ver NCache é suportado em servidores Windows e Linux. Então, em servidores Linux, você só precisa .NET Core lançamento de NCache e temos um servidor, bem como um cliente para estes. Então, se você quer correr NCache servidores em .NET no Linux usando .NET Core isso é possível e seus aplicativos sempre podem usar nosso .NET Core lançar e ser implantado no Windows, bem como no Linux, então, sim. Incrível. Eu vou deixar você realmente passar pelo resto e eu vou trazer as perguntas mais tarde.

Implantação de vários datacenters de NCache

Então, a seguir falaremos sobre a implantação de Multi-Datacenter de NCache. Agora, se seu aplicativo for implantado em vários datacenters, ou pode ser que você tenha um site ativo e, em seguida, tenhamos um site passivo para cenários de DR. Por exemplo, o site ativo fica inativo e seu aplicativo exige que você esteja sempre em funcionamento, se for um aplicativo de missão crítica, é importante para seus negócios. Ter um tempo de inatividade no nível do site é algo que afetaria seus negócios.

NCache cluster é projetado de tal forma que já está equipado com recursos de alta disponibilidade e confiabilidade de dados. Assim, em um único nível de site, se um ou dois servidores ficarem inativos, por exemplo, se você perder um servidor, NCache está equipado para lidar com essa interrupção sem problemas. Mas hoje estamos falando sobre se nós, o que acontece se tivermos uma interrupção no nível do site? Ou, precisamos derrubar o site para manutenção, com o site inteiro fora do ar. Então, todos os servidores estão inativos. NCache está equipado para lidar com esse cenário e é isso que estamos planejando cobrir hoje. Então, vamos falar sobre por que precisamos de Replicação de WAN?

Normalmente, quando seus aplicativos precisam de alta disponibilidade, um único site pode se tornar um ponto único de falha. Se o seu site ficar inativo, você perderá todos os dados e poderá causar tempo de inatividade nos usuários de seu aplicativo, o que pode afetar seus negócios, já estabelecemos isso. Os aplicativos multirregionais são lentos, se tiverem que conversar entre si pela WAN. Por exemplo, você tem um datacenter implantado, seu aplicativo implantado em um datacenter que está na região dos EUA e, em seguida, você tem outro aplicativo implantado na Europa ou em qualquer outro, por exemplo, na região asiática. Portanto, nesse caso, se seus bancos de dados de aplicativos estiverem localizados em um dos datacenters, o site remoto precisará passar pela rede. Portanto, a velocidade da sua rede afetaria a latência desse outro site. Você sabe, para lidar com esse cenário, você geralmente replica suas fontes de dados na WAN e é isso que recomendamos NCache também, que NCache deve ser replicado. Mas, considerando que você tem uma fonte de dados comum, o site remoto precisa passar pela WAN e isso pode causar um impacto no desempenho porque os dados não são locais para esse site, a distância entre os data centers também afetaria sua taxa de transferência . Há uma quantidade limitada de dados que você pode transmitir entre sites. Portanto, isso pode limitar sua capacidade de tratamento de solicitações.

Portanto, esses são dois problemas se você tiver aplicativos multirregionais e se ambos estiverem ativos. A replicação de dados no nível de solicitação também é cara. Por exemplo, você não replica o banco de dados inteiro e tem uma fonte de dados em um datacenter. Agora, uma requisição que vai em nossa localização remota, uma localização geográfica que é remota, para seu banco de dados. Uma replicação de nível de solicitação para todos os dados, você sabe, unidade de solicitação que chega à nossa fonte de dados, isso será extremamente caro e consumiria muita largura de banda e recursos. Então, você precisa de um mecanismo ativo, onde você tenha dados disponíveis localmente e é por isso que você precisa de WAN Replicação de cache necessária como uma obrigação. Assim, seus dados de um datacenter são replicados pela rede para o outro site.

Alguns casos de uso. Por que, você sabe, onde exatamente você pode usar a Replicação WAN?

O mais comum, que encontramos, é o site de recuperação de desastres. Você tem um site ativo, que atende ao seu caso de uso de negócios principal. É aí que seu tráfego está sendo gerado e tratado. E se o site inteiro cair? Você precisa de uma opção de fallback, certo. Então, esse site de DR já deve ter dados disponibilizados. Caso contrário, ele não teria esses requisitos de dados tratados se tivesse que voltar para o site que já está fora do ar, certo. Então, você precisa que os dados sejam disponibilizados no site de DR, para que já esteja funcionando. Você só precisa mudar seu tráfego para esse site de DR. Você não deve fazer mais nada, apenas rotear seu tráfego para o site de recuperação de desastres e ele deve funcionar com o mesmo valor de desempenho, as mesmas matrizes de desempenho que você tinha com o site ativo. Assim, é possível recuperar 100% dos dados em caso de falha, com a ajuda de NCache Replicação WAN.

Os aplicativos multirregionais podem compartilhar dados e carregar. Agora, com sites Ativos-Ativos, se você tiver uma região nos EUA e outra em outra parte do mundo, por exemplo, Europa ou Ásia. Se você quiser isso, você sabe, solicitação de, você sabe, um datacenter deve ser tratado com base na afinidade de local, você pode conseguir isso. Agora, o usuário da Ásia pode se conectar a um site dentro dessa região, mais próximo dessa região e pode usar o cache de lá também e esse cache está em sincronia com o outro cache que está na região dos EUA. Então, qualquer usuário que rebate. Por exemplo, você precisa gerenciar o estouro ou distribuir a capacidade. Alguns dos usuários precisam, agora precisam saltar para a região dos EUA porque a região da Ásia está totalmente bloqueada, então você sempre pode fazer isso. Assim, no nível do site, você pode balancear a carga de sua solicitação, com base na capacidade que o site está processando naquele momento e naquele momento. Como os dados de cache já são replicados nos datacenters e falaremos sobre como conseguir isso, seus aplicativos multirregionais são capazes de compartilhar com eficiência seus dados de aplicativos e também compartilhar a carga de solicitação e também podem ter compartilhamento de carga igual . Nenhuma migração de dados redundante é feita. É apenas baseado na solicitação saltando de um datacenter para outro e você sempre pode obter esses dados do cache que já está conectado lá.

A migração de dados de aplicativos de leste para oeste é outro caso de uso. Por exemplo, os mercados asiáticos começam mais cedo, você sabe, os mercados ocidentais, certo. Portanto, sua tendência de dados geralmente segue de leste a oeste. Assim, seu site do leste pode ter nosso cache configurado e com fuso horário, os dados se movem entre o datacenter para a região oeste e chegam ao oeste. Portanto, se você tiver dados replicados em datacenters, os dados de cache da região oeste poderão aproveitar todos os dados disponibilizados na região leste. Assim, você pode disponibilizar a migração de dados de Leste para Oeste e o caso de uso de manutenção é o terceiro.

Quarto, onde podemos implantar atualização e manutenção sem qualquer tempo de inatividade. Isso está se tornando um caso de uso muito urgente, com NCache também. Que, se você estiver planejando fazer upgrade, poderá fazer upgrades entre versões mais antigas e mais recentes, usando nossa topologia de ponte. Onde os dados mais antigos, os dados da versão podem ser transmitidos para a versão mais recente com o recurso de atualizações ao vivo. Pode ser entre sites, por exemplo, você pode usar um site e replicar dados ativamente para o site passivo e você pode atualizar, implantar um novo código, manter desempenho, manutenção no site ativo e você tem todos os dados disponibilizados e seu o tráfego pode ser roteado para o site passivo para esse assunto. Assim, ambos os sites podem estar sempre funcionando sem tempo de inatividade zero e qualquer perda de dados do aplicativo.

NCache Ponte para replicação WAN

Então, vamos falar sobre como lidar com isso? O nome do recurso é NCache ponte. Faz parte do mesmo produto. Você não precisa de nenhuma instalação separada para isso. NCache Enterprise está equipado com NCache topologia de ponte e vamos falar sobre isso.

Então, nosso cache, NCache recurso de ponte permite replicar o cache entre datacenters.

É baseado no modelo de replicação assíncrona. Não incorre em nenhuma degradação de desempenho no lado do aplicativo. Seus aplicativos de cache estão conectados ativos ao cache em um datacenter. Por exemplo, você tem clientes aqui e pode criar uma ponte que também seja uma fila ativa-passiva e que transmitiria dados para os outros sites de forma assíncrona.

Portanto, é baseado em replicação assíncrona, portanto, não há degradação de desempenho na replicação de dados. É muito confiável. É tolerante a falhas. Ele detecta automaticamente falhas de conexão. Ele se reconecta automaticamente. Há opções de repetição automática disponíveis, portanto, a ponte também é copiada na fila ativa-passiva.

Portanto, há um servidor Active Bridge e também um servidor Passive Bridge. Se o servidor Active Bridge ficar inativo, o Passivo pegará e iniciará todas as operações de replicação sem atrasos. É muito fácil de configurar, você não precisa de nenhuma alteração de código, você não precisa de nenhuma instalação extra. Faz parte do mesmo produto, o Enterprise e dá suporte próprio de monitoramento e gerenciamento, que está integrado no mesmo NCache Enterprise produto e suporta várias topologias que vou abordar a seguir.

Assim, temos três topologias principais.

Temos Ativo-Passivo. Onde temos um site ativo e depois temos um site passivo. O site passivo também está recebendo solicitações de clientes, mas o fluxo de dados é de ativo para passivo. Portanto, se você tiver requisitos de site de DR, poderá usar um site para ser ativo, conectado à ponte e, em seguida, poderá ter outro site passivo. O site ativo transmite dados para o site passivo. Então, é uma transmissão de mão única. O termo passivo significa essencialmente que o site passivo não está transmitindo dados de volta ao ativo. Ele ainda está em execução e você tem aplicativos cliente para tirar proveito dele. Então, não é algo que está parado por qualquer meio. A migração de leste para oeste pode ser alcançada com a passiva ativa. Seu caso de uso de manutenção e atualização pode ser tratado com a ajuda de ativo-passivo.

A topologia ativa-ativa é quando você tem um aplicativo implantado em duas localizações geográficas diferentes e deseja que os dados do site 1 sejam disponibilizados no site 2 e os dados do site 2 sejam disponibilizados no site 1. Se seu aplicativo precisar de requisitos de compartilhamento de dados entre sites geográficos, você pode segmentar ativo-ativo onde tiver usuários ativos em ambos os datacenters. Os clientes estão conectados aos dois datacenters e há uma replicação bidirecional acontecendo entre dois sites diferentes e então temos 3, 2+ ou 3+ topologia ativa-ativa, onde temos um servidor de lances primário, mas está transmitindo dados para todos sites e esses sites também estão transmitindo dados de volta para todos os outros sites. Assim, uma atualização deve ser aplicada em todos os datacenters e vice-versa.

Então, aqui está o nosso ativo-passivo.

Neste, temos bridge, que é uma fila, que também é ativa-passiva. Temos cluster de cache no site 1, que é apenas, você sabe, lidar com solicitações de clientes. Temos 3 servidores aqui. Está conectado à ponte. Bridge também reside em um dos sites. Ou, em alguns casos, você pode ter uma ponte ativa no site 1 e um servidor de ponte passiva no site 2. Isso também é possível, mas normalmente recomendamos que você mova a ponte em um dos sites em sua arquitetura de implantação. O segundo site é um site passivo e novamente por passivo ainda está em execução. É só que o site passivo não replica os dados de volta para o ativo. É uma transmissão de dados de sentido único e isso é tudo o que significa quando dizemos que este é um site passivo. Você pode essencialmente executar aplicativos cliente aqui e é totalmente funcional mesmo nesse estado. Então, é uma replicação de dados, passivo ativo, então, se esse servidor cair, o passivo fica ativado e é automático. Nenhuma alteração de código é necessária. Mostrarei como configurar a ponte, assim que avançarmos para nossa parte prática. Então, é bem simples.

Veio uma pergunta e tem a ver com esse ativo-passivo, é, principalmente se você tem um site ativo e um passivo como você ativa o site passivo? É um processo manual? O site está parado? Como você faz isso? Ok, então, se eu entendi esta pergunta corretamente, o site passivo em termos de como ativá-lo? Já está ativado. Ele está em execução e, se derrubarmos este site ou quisermos mover o tráfego para cá, é a carga de tráfego do seu aplicativo que você precisa mover para este site. Então, você tem servidores de aplicação aqui, você tem servidores de aplicação aqui, qualquer dado que você tenha vai ser transmitido aqui e os usuários deste site podem ter os dados disponibilizados a partir do próprio cache. Agora, você sempre pode direcionar seu tráfego para o site passivo e obter todos os dados disponibilizados. Portanto, não há etapas necessárias para ativá-lo. No entanto, se você quiser que este site comece a transmitir dados de volta para o site ativo também, você pode ativá-lo usando nossas ferramentas GUI. Então, em termos de replicação, se você quiser que isso seja replicando dados de volta para o ativo, você sempre pode tornar isso ativo e esse é um processo de tempo de execução. Então, você pode apenas com uma linha de, com um clique na ferramenta GUI, você pode conseguir isso ou pode usar nossa ferramenta PowerShell para fazer isso acontecer. Mas se sua pergunta é em relação a tornar o nó passivo ativo. Se houver uma etapa manual para que os aplicativos cliente se conectem a ela e possam usar os dados, ela já está em execução. Seus aplicativos começam a usá-lo se você começar a rotear o tráfego para esse cluster de cache. Então, dentro do seu balanceador de carga. Você desliga este site e direciona todo o seu tráfego para o site disponível, que já está em funcionamento e pode obter/aproveitar todos os dados que estão sendo replicados.

Então, ativo-ativo, é novamente baseado no mesmo princípio. Onde temos pontes funcionando em um dos sites.

Temos cache 1, cache 2. Ambos os sites estão ativos e até a topologia passiva pode ser ativada, clicando com o botão direito e ativando-a e neste caso os dados do cache do site 1 são transmitidos para o site 2, de forma assíncrona do cache para a bridge e da ponte para o cache e, da mesma forma, o site 2 também está transferindo dados de volta para o site 1.

3+ datacenters ativos-ativos, onde temos três ou mais ativos-ativos, onde temos um dos sites como servidor de ponte. Também podemos ter um site de fallback para bridge. Podemos ter um site de ponte de backup também. Mas, em geral, teríamos um dos sites que hospedaria, que estaria hospedando bridge e então esse site estaria transmitindo dados para outros sites e da mesma forma o site 2 estaria transferindo dados para o site 1 através do bridge e para o site 3. E para ativos -ativo, temos a resolução de conflitos baseada no tempo, portanto, a última atualização vence. Todas as estruturas de dados que usamos são livres de conflitos. Esses são tipos de dados sem conflitos. Não há condições de corrida ou problemas de consistência de dados que você conhece, porque a última atualização será aplicada no cluster de cache em toda a placa. Então, NCache gerencia se houver duas atualizações para a mesma chave, NCache avaliaria isso e também permitiria que você construísse sua própria resolução de conflitos, se isso for um requisito. Então, é gerenciado como parte de NCache topologias.

Então, aqui está uma rápida olhada em nossas configurações de ponte.

Nós temos NCache configuração da ponte. NCache Bridge é o nome e então temos LondonCache ambiente 1, portanto, você também pode ter vários caches com o mesmo nome. NewYorkCache e estes estão conectados.

Demonstração prática NCache

Então, deixe-me mostrar tudo isso em ação, como configurar uma ponte? Como começar com ele e, em seguida, mostraremos os aplicativos de cache de objeto e cache de sessão. Antes de você entrar nisso Ron, eu tive uma pergunta no slide anterior com o código e a pergunta é quais são as mudanças de código que estão envolvidas para configurar a ponte? Eles precisam escrever algum código para que os dados sejam replicados pela ponte? De jeito nenhum. Não precisamos de nenhum código. É apenas uma configuração. Então, você tem o cache 1 no datacenter 1 e o cache 2 no datacenter 2. Você simplesmente configura a bridge e quaisquer dados que já estejam sendo adicionados por seus aplicativos no NCache, será replicado por meio da ponte automaticamente. Portanto, é responsabilidade da bridge se encarregar de toda a replicação. Você não precisa escrever nenhum código explicitamente para ter dados replicados nos datacenters e quando dizemos os tipos de dados, a resolução de conflitos, isso é algo que também é implementado por padrão, que é baseado em tempo, mas se você quiser implementar seu próprio resolução de conflitos, se seus requisitos de negócios são que você avalie objetos, caso várias atualizações cheguem, nesse caso você pode implementar essa interface. Mas no que diz respeito à replicação de dados, é responsabilidade da bridge. Você não precisa escrever nenhum código para isso.

Criar caches

Então, deixe-me começar rapidamente, eu vou criar um cache.

Digamos que vou nomear site1cache ou deixe-me usar isso aqui SiteOneCache. Isto é apenas para lhe dar uma ideia de como começar rapidamente e ser capaz de criar a ponte. Vou manter tudo padrão, porque NCache arquitetura cobre todos esses detalhes.

Então, eu vou passar rapidamente por eles. Partição do cache de réplica, qualquer cluster. Replicação assíncrona de topologia. Vou escolher 101 e vamos ver se consigo escolher 102, se estiver disponível. Esses são meus dois servidores, para hospedar a ponte. Vou manter tudo isso padrão. Inicie isso e o início automático também. Terminar. Então, meu cache está em 101 e 102, que vai ser criado. Vamos ver como vai ser e então eu vou em frente e crio outro cache que estaria em um conjunto separado de servidores e então eu hospedarei a ponte e mostrarei como tudo isso funcionaria. Certo. Portanto, temos o SiteOneCache totalmente configurado. Como você pode ver, começou também.

Agora, vou em frente e criar, na verdade, vou criar outro cache, que é o SiteTwoCache. Acho que posso usar isso. Eu estava brincando com isso antes. Mantenha tudo simples e desta vez vou dar um conjunto separado de servidores, para que representemos isso como um site separado. Mantenha tudo padrão e, a propósito, nossa ponte permite que você tenha gerenciamento remoto de todos os sites, desde as ferramentas de gerenciamento e monetárias, permitindo que você gerencie todos os sites junto com a ponte, a partir de um local central. Então, se você tiver acesso à rede. Se houver um link WAN disponível entre o SiteOne e o SiteTwo, você poderá gerenciar basicamente tudo. Então, temos o SiteTwoCache aqui. SiteOneCache aqui. 101 102 representando SiteOneCache. 107 e 108 representando SiteTwoCache. Agora, e estes são iniciados também.

Se eu clicar em estatísticas, você verá que ainda não há objetos adicionados aqui. Os dados não são adicionados no SiteOneCache ou SiteTwoCache, então tudo bem. Eu simplesmente executaria isso. Acho que tenho um problema de permissão para revisar este contador. Eu acho, eu posso, ok. Então, você pode ver que ainda não há itens disponíveis. Agora vou vincular esses dois caches com a ajuda de uma bridge, que configurarei a seguir.