Topologias para Diversos Coletivos

[Version 2.0.0.3 and later] Você tem várias opções diferentes ao escolher a topologia para sua implementação que incorpora diversos coletivos.

Links Conectando coletivos

Uma infraestrutura de grade de dados de replicação é um gráfico conectado de coletivos com links bidirecionais entre eles. Com um link, dois coletivos podem comunicar as mudanças de dados. Por exemplo, a topologia mais simples é um par de coletivos com um único link entre eles. Os coletivos são nomeados em ordem alfabética: A, B, C e assim por diante, a partir da esquerda. Um link pode cruzar uma rede de longa distância (WAN), expandindo-se para grandes distâncias. Mesmo se o link for interrompido, os dados ainda poderão ser alterados em qualquer coletivo. A topologia reconcilia as mudanças quando o link reconecta os coletivos. Os links tentarão automaticamente reconectar se a conexão com a rede for interrompida.

Link

Depois que você configura os links, o produto tenta primeiro tornar cada coletivo idêntico. Em seguida, o eXtreme Scale tenta manter as condições idênticas conforme as mudanças ocorrem em qualquer coletivo. O objetivo é que cada coletivo seja um espelho exato de qualquer outro coletivo conectado pelos links. Os links de replicação entre os coletivos ajudam a assegurar que as mudanças feitas em um coletivo sejam copiadas para os outros coletivos.

Topologias em Linha

Embora esta seja uma implementação muito simples, uma topologia em linha demonstra algumas qualidades dos links. Primeiro, não é necessário que um coletivo esteja conectado diretamente a outro coletivo para receber as mudanças. O coletivo B extrai as mudanças do coletivo A. O coletivo C recebe mudanças do coletivo A por meio do coletivo B, que conecta os coletivos A e C. De modo semelhante, o coletivo D recebe mudanças dos outros coletivos por meio do coletivo C. Essa capacidade difunde o carregamento de distribuição de mudanças para fora da origem das mudanças.

Topologia em linha

Observe que, se o coletivo C falhar, as ações a seguir ocorrerão:
  1. O coletivo D ficará órfão até o coletivo C ser reiniciado
  2. O coletivo C se sincronizará com o coletivo B, que é uma cópia do coletivo A
  3. O coletivo D usará o coletivo C para se sincronizar com as mudanças no coletivo A e B. Essas mudanças ocorreram inicialmente enquanto o coletivo D estava órfão (enquanto o coletivo C estava inativo).
Por fim, os coletivos A, B, C e D se tornarão todos idênticos entre si novamente.

Topologias em Anel

As topologias em anel são um exemplo de uma topologia mais resiliente. Quando um coletivo ou um único link falha, os coletivos sobreviventes ainda podem obter as mudanças. Os coletivos se deslocam ao redor do anel, longe da falha. Cada coletivo tem no máximo dois links para outros coletivos, não importa o tamanho da topologia em anel. A latência para propagar as mudanças pode ser grande. As mudanças a partir de um coletivo particular podem precisar percorrer vários links antes que todos os coletivos possuam as mudanças. Uma topologia em linha tem a mesma característica.

Topologia em Anel

Também é possível implementar uma topologia em anel mais sofisticada, com um coletivo raiz no centro do anel. O coletivo raiz funciona como o ponto central da reconciliação. Os outros coletivos agem como pontos remotos de reconciliação para mudanças que ocorrem no coletivo raiz. O coletivo raiz pode arbitrar mudanças entre os coletivos. Se uma topologia em anel contiver mais de um anel ao redor de um coletivo raiz, o coletivo poderá arbitrar apenas as mudanças entre o anel mais interno. No entanto, os resultados da arbitragem se difundem por todos os coletivos nos outros anéis.

Topologias Hub-and-Spoke

Com uma topologia hub-and-spoke, as mudanças percorrem um coletivo hub. Como o hub é apenas o coletivo intermediário especificado, as topologias hub-and-spoke possuem latência inferior. O coletivo hub é conectado a cada coletivo spoke por meio de um link. O hub distribui as mudanças entre os coletivos. O hub atua como um ponto de reconciliação de colisões. Em um ambiente com uma alta taxa de atualização, o hub pode precisar executar em mais hardware do que os spokes devem permanecer sincronizados. O WebSphere DataPower XC10 Appliance é projetado para escalar linearmente, o que significa que é possível aumentar o hub, conforme necessário, sem dificuldade. No entanto, se o hub falhar, as mudanças não são distribuídas até ele ser reiniciado. Quaisquer mudanças nos coletivos spoke serão distribuídas depois que o hub for reconectado.

Topologia Hub-and-spoke

Também é possível usar uma estratégia com clientes totalmente replicados, uma variação de topologia que usa um par de servidores sendo executados como um hub. Cada cliente cria uma grade de dados autocontida de contêiner único com um catálogo na JVM do cliente. Um cliente usa a grade de dados para se conectar com o catálogo do hub. Esta conexão faz com que o cliente seja sincronizado com o hub assim que o cliente estabelecer uma conexão com o hub.

Todas as mudanças feitas pelo cliente são locais para o cliente e são replicadas de forma assíncrona para o hub. O hub age como um coletivo de arbitragem, distribuindo mudanças para todos os clientes conectados. A topologia de clientes totalmente replicados fornece um cache L2 confiável para um mapeador relacional de objeto, como OpenJPA. As mudanças serão distribuídas rapidamente entre as JVMs de cliente por meio do hub. Se o tamanho do cache puder estar contido no espaço de heap disponível, a topologia será uma arquitetura confiável para este estilo de L2.

Use diversas partições para escalar o coletivo hub em diversas JVMs, se necessário. Como todos os dados ainda devem se ajustar em uma única JVM de cliente, diversas partições aumentam a capacidade do hub para distribuir e arbitrar as mudanças. No entanto, ter diversas partições não altera a capacidade de um único coletivo.

Topologias em Árvore

Também é possível usar uma árvore direcionada acíclica. Uma árvore acíclica não tem ciclos ou loops e uma configuração direcionada limita a criação de links apenas entre pais e filhos. Essa configuração é útil para topologias que possuem vários coletivos. Nestas topologias, não é viável ter um hub central conectado a cada spoke possível. Esse tipo de topologia também pode ser útil quando você deve incluir coletivos filhos sem atualizar o coletivo raiz.

Topologia em Árvore

Uma topologia em árvore ainda pode ter um ponto central de reconciliação no coletivo raiz. O segundo nível pode ainda funcionar como um ponto de reconciliação remoto para mudanças que ocorrem no coletivo abaixo dele. O coletivo raiz pode arbitrar as mudanças entre os coletivos apenas no segundo nível. Também é possível usar N árvores, cada uma delas possuindo N filhos em cada nível. Cada coletivo se conecta com n links.

Clientes Totalmente Replicados

Essa variação de topologia envolve um par de servidores sendo executados como um hub. Cada cliente cria uma grade de dados autocontida de contêiner único com um catálogo na JVM do cliente. Um cliente usa a grade de dados para se conectar com o catálogo do hub, fazendo com que o cliente seja sincronizado com o hub assim que estabelecer uma conexão com o hub.

Todas as mudanças feitas pelo cliente são locais para o cliente e são replicadas de forma assíncrona para o hub. O hub age como um coletivo de arbitragem, distribuindo mudanças para todos os clientes conectados. A topologia de clientes totalmente replicada fornece um bom cache L2 para um mapeador relacional de objeto, como OpenJPA. As mudanças serão distribuídas rapidamente entre as JVMs de cliente por meio do hub. Contanto que o tamanho do cache possa estar contido no espaço de heap disponível dos clientes, esta topologia será uma boa arquitetura para este estilo de L2.

Use diversas partições para escalar o coletivo hub em diversas JVMs, se necessário. Como todos os dados ainda devem se ajustar a uma única JVM de cliente, usar diversas partições aumenta a capacidade do hub para distribuir e arbitrar mudanças, mas não altera a capacidade de um único coletivo.