Os aplicativos de hoje são altamente transacionais e podem ser dimensionados para altas transações executando em uma implantação de vários servidores com balanceamento de carga. Ao mesmo tempo, muitos desses aplicativos precisam ser executados em vários datacenters. Isso pode ser feito para recuperação de desastres, onde um datacenter ativo tem recuperação de desastres como um datacenter passivo que geralmente está em uma localização geográfica diferente. Outro motivo é que, se os usuários desse aplicativo estiverem distribuídos geograficamente, eles obterão tempos de resposta mais rápidos, pois acessarão simultaneamente seu próprio data center em sua região.
NCache Adicionar ao carrinho Ponte para replicação WAN NCache Docs
Cache precisa de replicação de WAN assim como banco de dados
Quando você tem aplicativos em execução em vários datacenters, o cache precisa ser replicado. Isso ocorre porque o cache mantém dados transitórios e, se o cache ficar inativo, os dados serão perdidos. Dados transitórios podem ser sessões ASP.NET, dados arbitrários gerados por seu aplicativo ou dados agregados. No entanto, os dados temporários não são permanentes, portanto, nunca são armazenados no banco de dados - são apenas armazenados em cache.
Os outros dados NCache mantém por motivos de desempenho são os dados do aplicativo. Se você perder esses dados, eles serão recarregados do banco de dados, o que prejudica o desempenho. Muitas empresas não querem lidar com isso devido ao alto tráfego de aplicativos. É por isso que mesmo os dados do aplicativo precisam ser replicados na WAN se você tiver uma implantação de vários centros de dados.
NCache Adicionar ao carrinho Replicação de WAN NCache Docs
Alternativa? NCache Replicação de WAN através de Bridge
Para lidar com a situação acima, NCache fornece um recurso de replicação de WAN por meio de uma ponte. Isso permite que você implante NCache em vários datacenters em configurações ativo-passivo, ativo-ativo, 3+ datacenter ativo-ativo.
2 sites ativo-passivo
Em uma configuração ativa-passiva, NCache é implantado em sites ativos e passivos, criando uma topologia de ponte no site ativo. A Figura 1 mostra como isso é apresentado em uma configuração ativa-passiva. Todas as atualizações de aplicativos são enviadas do cache do site ativo para a ponte, que as envia de forma assíncrona para o site passivo em milissegundos. O único atraso aqui é a latência entre os datacenters se eles estiverem distantes. Portanto, uma topologia de ponte com um mecanismo de enfileiramento assíncrono permite que todas essas atualizações ocorram sem estourar nada.
NCache Adicionar ao carrinho Modos de sincronização de cache NCache Docs
2 sites ativo-ativo
Outra configuração que NCache suporta é ativo-ativo, onde ambos os sites estão ativos. Um mantém o cache e a topologia da ponte e o outro contém apenas o cache. A Figura 2 mostra como isso é feito. Semelhante ao ativo-passivo, no ativo-ativo, um cache envia suas atualizações para a ponte, que por sua vez as envia para outros caches. No entanto, agora há uma diferença. Podem ocorrer conflitos quando o mesmo item é atualizado em ambos os lados ao mesmo tempo. Isso significa que a ponte deve coordenar atualizações de ambos os sites e resolver conflitos de forma assíncrona para evitar um impacto negativo no desempenho do cache em cada site ativo.
NCache Adicionar ao carrinho Replicação WAN Multi-Datacenter NCache Docs
3+ Site Ativo-Ativo
Na terceira situação, existem 3 ou mais centros de dados ativos. Aqui um dos sites ativos possui cache e bridge, todos os outros sites possuem apenas cache. Ou seja, a ponte é local para um dos sites, mas os outros dois sites acessam a ponte remotamente. Semelhante ao cenário ativo-ativo, neste cenário 3+ ativo-ativo todos os caches enviam atualizações para a ponte, e a ponte propaga atualizações para todos os caches conectados. Ao mesmo tempo, ele executa a resolução de conflitos para garantir que os mesmos dados atualizados do cache não causem violações de integridade de dados.
NCache Adicionar ao carrinho Topologia da ponte NCache Docs
A Figura 3 mostra três centros de dados ativos-ativos. NCache permite uma replicação de cache muito contínua e assíncrona. Nenhuma alteração no código do aplicativo. Os aplicativos nem sabem que o cache está sendo replicado, mas ele é replicado de forma assíncrona pela WAN do datacenter.
Replicação de WAN paralela e assíncrona em massa
Todas as atualizações no cache são assíncronas. A razão pela qual eles são assíncronos é a distância entre vários centros de dados. Essa distância pode levar a um desempenho ruim devido à latência. Os tempos de acesso entre os servidores são muito rápidos quando os aplicativos são armazenados em cache no mesmo datacenter. Mas em uma WAN, geralmente é muito lento. Portanto, se você não fizer atualizações assíncronas, quem estiver fazendo a solicitação de atualização terá que aguardar a conclusão da atualização – atualizações síncronas, que tornam seu aplicativo mais lento.
No entanto, a replicação assíncrona significa que os aplicativos e caches em cada site não estão esperando que seus dados sejam replicados para outros datacenters. Os dados são enfileirados no ponte. A ponte em si é um cluster de dois nós, enfileirando todas as solicitações de atualização de todos os caches. Para ativo-passivo, as solicitações são enfileiradas somente do cache ativo e aplicado de forma assíncrona ao cache passivo. Se você tiver três ou mais datacenters, a ponte aplicará atualizações a vários sites ativos em paralelo.
Além disso, a ponte executa atualizações em massa. Isso significa que você pode combinar vários itens de dados em uma única solicitação e enviá-los para outros sites como uma única solicitação em massa, reduzindo consideravelmente as viagens de rede. Essa poderosa combinação de replicação paralela, em massa e assíncrona, portanto, melhora o desempenho durante a replicação de caches em vários datacenters.
NCache Adicionar ao carrinho Topologia de Replicação WAN NCache Docs
Resolução de Conflitos
Se você tiver vários sites ativos, cada um desses sites poderá atualizar os mesmos dados ao mesmo tempo. Certifique-se de que seu computador local esteja sincronizado com o fuso horário local. Claro, não há problema se não for atualizado ao mesmo tempo. Suponha que você atualize o item 1 no tempo T1 e atualize o item 2 no tempo T2. A atualização no tempo T2 é a última atualização aplicada. No entanto, se ambas as atualizações ocorrerem ao mesmo tempo, o ponte deve resolver o conflito de duas maneiras.
-
Lógica padrão “Última atualização vence”: A ponte recupera automaticamente o timestamp de cada cache, e todos os caches têm seus relógios sincronizados para que tenham o mesmo horário. A ponte recebe os tempos de atualização de cada cache e as atualizações mais recentes são aplicadas a todos os caches. Novamente, o objetivo da resolução de conflitos é aplicar a mesma atualização de versão a todos os caches para evitar problemas de integridade de dados.
-
Manipulador de Resolução de Conflitos: Outra maneira pela qual a ponte resolve conflitos é que ela pode fornecer um manipulador de resolução de conflitos de acordo com sua lógica para analisar atualizações. Como esse resolvedor está configurado com NCache, a ponte fornecerá as duas cópias do objeto e o resolvedor analisará qual versão é melhor de acordo com a lógica fornecida. Isso retornará a versão final para a ponte e aplicará essa atualização a todos os caches.
O snippet de código a seguir fornece uma amostra da implementação do resolvedor de conflitos que é implantada no 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() {. . .} } |
Assim, por ter um mecanismo de resolução de conflitos em NCache, você pode ter certeza de que seu cache nunca ficará fora de sincronia. Ele nunca terá duas versões diferentes das atualizações de dados e sempre será consistente em vários datacenters.
NCache Adicionar ao carrinho Configurar ponte Configurar o Resolvedor de Conflitos
Lidando com desastres em tempo de execução
Agora vamos falar sobre o que acontece no caso de uma situação de desastre em que um site cai.
Passivo ativo
Caso 1: O site passivo cai
Uma configuração ativa-passiva atua como um local de recuperação de desastres. Portanto, se o lado passivo cair, o lado ativo ainda funcionará e seu aplicativo continuará em execução. A ponte não pode replicar dados para o site passivo até que você intervenha para restaurar o site passivo. Quando você reverte o site passivo, ele se reconecta à ponte e sincroniza novamente, descartando o cache existente e obtendo efetivamente uma cópia completa do cache do site ativo na ponte. Após a conclusão da sincronização, ele alterna para o modo de replicação WAN normal.
NCache Adicionar ao carrinho Sincronizar caches de ponte Cache Ativo-Passivo
Caso 2: O site ativo cai
Se o site ativo cair, isso significa que houve algum tipo de desastre, porque a ponte caiu e o aplicativo provavelmente caiu. Você tem que enviar todo o tráfego agora para o local passivo que agora se torna ativo. Todos os dados são replicados do site ativo original para o site passivo original, sem interrupção para os usuários. O site passivo original agora está ativo, então todas as atualizações acontecem aqui, mas os usuários não veem interrupções.
No entanto, assim que o site ativo original estiver ativo novamente, ele se conectará ao novo site ativo (o site passivo original) e sincroniza em si completamente. Depois que a sincronização é concluída, ambos são ativo-ativo, embora todo o tráfego vá para o site passivo original. Você tem a flexibilidade de descarregar todo o tráfego para o site ativo original e alterar o status do site ativo-ativo de volta para passivo na ponte. NCache permite que você faça tudo isso em tempo de execução sem qualquer interrupção no caso de um desastre ativo-passivo.
Ativo-Ativo
Quando o site ativo com a ponte fica inativo, a replicação WAN é interrompida porque a ponte está inativa. No entanto, outros sites ativos continuarão funcionando e todo o tráfego será roteado para eles. Depois de ativar o site desativado, você pode iniciar a ponte e conectar o site ativo à ponte, para que ambos os sites estejam sincronizados. Tudo isso é feito em tempo de execução, portanto, nenhum tempo de inatividade é necessário. Depois que as pontes estiverem sincronizadas, os dois sites poderão enviar atualizações um para o outro. NCache assim fornece tolerância a falhas.
NCache Adicionar ao carrinho Modos de sincronização de cache NCache Docs
3+ Sites ativos
A terceira situação é quando você tem 3 ou mais sites ativos onde um site tem a ponte e os outros não. Dois cenários podem ocorrer neste caso, conforme mencionado.
Caso 1: O site ativo não-ponte desce
Nesse caso, outros sites continuarão se replicando e o tráfego deste site será redirecionado para os outros sites conectados sem interromper os usuários. Assim que o site estiver ativo, ele se reconecta à ponte e sincroniza novamente para obter a cópia mais recente do cache. Este é o sinal para colocar o tráfego de volta nos trilhos.
NCache Adicionar ao carrinho Alterar modos de sincronização de cache Topologia da ponte
Caso 2: O site ativo com a ponte desce
No caso em que a ponte cai, os outros dois sites ativos continuam funcionando, mas não conseguem replicar suas atualizações entre si porque não há ponte. Então, o que você pode fazer neste momento é iniciar uma ponte em um dos outros dois sites ativos.
Para iniciar a ponte, você precisa de dois nós como um cacho. Idealmente, você deve ter um conjunto dedicado de servidores para o topologia de ponte nesse site, mas você também pode usar dois servidores de cache como um cluster, pois provavelmente é temporário. No entanto, pode ter algum impacto no desempenho desses servidores de cache, porque agora a ponte também consome recursos como CPU e memória.
Você precisa comece a ponte em um dos sites ativos onde ambos os sites ativos já estão em execução. O cache em execução agora pode se conectar a uma ponte. Então, ambos se conectam a uma ponte e sincronizam replicando todas as atualizações entre si. Os usuários não sofrem nenhuma interrupção, pois os dois sites são sincronizados e propagam atualizações entre si. Portanto, se algum site cair, você não perderá nenhum dado.
NCache Adicionar ao carrinho Adicionar caches agrupados Gerenciamento de Ponte
Agora, quando o local original com a ponte voltar, você pode simplesmente:
- Desça a ponte no local temporário.
- Remova a ponte do cache existente.
- Traga a ponte para o local original.
- Conecte todos os caches a esta nova ponte.
Como você pode conectar o cache à ponte em tempo de execução, NCache permite que você automatize todo esse trabalho por meio de scripts para que você possa lidar perfeitamente com a situação em que um site de ponte fica inativo e você precisa trazê-lo de volta.
Conclusão
NCache oferece um poderoso mecanismo de replicação de WAN que permite lidar com vários cenários avançados diferentes. Além disso, ele executa a replicação de WAN de maneira rápida e eficiente e lida com data centers ativo-passivo, ativo-ativo ou três ou mais ativos-ativos.
NCache Adicionar ao carrinho Baixar NCache Comparação de edições