Ao implementar da replicação multimestre, você deve considerar aspectos de design, como arbitragem, vinculação e desempenho.
Para evitar colisões, escolha um domínio de serviço de catálogo específico, chamado de domínio de serviço de catálogo de arbitragem como o árbitro de colisão para um subconjunto de domínios de serviço de catálogo. Por exemplo, uma topologia hub-and-spoke pode usar o hub como o manipulador de colisão. O manipulador de colisão spoke ignora quaisquer colisões que forem detectadas pelos domínios de serviço de catálogo spoke. O domínio de serviço de catálogo do hub cria revisões, evitando revisões de colisão inesperadas. O domínio de serviço de catálogo designado para manipular colisões deve ser vinculado a todos os domínios os quais ele é responsável por manipular as colisões. Em uma topologia em árvore, os domínios pais internos manipulam colisões para seus filhos imediatos. Em contraste, se usar uma topologia em anel, não será possível designar um domínio de serviço de catálogo no anel como o árbitro.
Topologia | Arbitragem do Aplicativo? | Notas |
---|---|---|
Uma linha de dois domínios de serviço de catálogo | Sim | Escolha um domínio do serviço de catálogo como o árbitro. |
Uma linha de três domínios de serviço de catálogo | Sim | O domínio de serviço de catálogo médio deve ser o árbitro. Considere o domínio de serviço de catálogo médio como sendo o hub em uma topologia hub-and-spoke simples. |
Uma linha de mais de três domínios de serviço de catálogo | Não | A arbitragem de aplicativo não é suportada. |
Um hub com N spokes | Sim | O hub com links para todos os spokes deve ser o domínio de serviço de catálogo de arbitragem. |
Um anel de N domínios de serviço de catálogo | Não | A arbitragem de aplicativo não é suportada. |
Uma árvore acíclica, direcionada (árvore n-ary) | Sim | Todos os nós-raiz devem classificar apenas seus descendentes diretos. |
A latência de mudança é determinada pelo número de domínios de serviço de catálogo intermediários onde uma mudança deve passar antes de chegar a um domínio do serviço de catálogo específico.
Uma topologia tem a melhor latência de mudança quando ele elimina os domínios de serviço de catálogo intermediários ao vincular cada domínio de serviço de catálogo a outro domínio. No entanto, um domínio de serviço de catálogo deve executar o trabalho de replicação proporcionalmente ao seu número de links. Para topologias grandes, o número de links absoluto a ser definido pode causar uma carga administrativa.
A tolerância a falhas é determinada pela quantia de caminhos que existem entre dois domínios de serviço de catálogo para a replicação de mudança.
Se houver apenas um link entre um determinado par de domínios de serviço de catálogo, uma falha de link não permitirá a propagação das mudanças. Da mesma forma, as mudanças não serão propagadas entre os domínios de serviço de catálogo se ocorrer uma falha de link em qualquer um dos domínios intermediários. Sua topologia pode ter um único link a partir de um domínio de serviço de catálogo para outro, de modo que o link passe pelos domínios intermediários. Caso positivo, as mudanças não serão propagadas se qualquer um dos domínios de serviço de catálogo intermediários estiver inativo.
Considere a topologia em linha com quatro domínios de serviço de catálogo, A, B, C e D:
Por exemplo, se um determinado serviço de catálogo em sua topologia em anel estiver inativo, os dois domínios adjacentes ainda poderão obter as mudanças diretamente entre si.
Todas as mudanças são propagadas por meio do hub. Assim, em oposição às topologia de linha e em anel, o design hub-and-spoke será suscetível à interrupção se o hub falhar.
Um domínio de serviço de catálogo único é resiliente a uma determinada perda de quantidade de serviço. No entanto, falhas maiores, como interrupções ou perda de links em uma rede maior entre os datacenters físicos pode interromper qualquer um dos domínios de serviço de catálogo.
O número de links definido em um domínio de serviço de catálogo afeta o desempenho. Mais links usam mais recursos e o desempenho de replicação pode diminuir como resultado. A capacidade de recuperar mudanças para um domínio A por meio de outros domínios isenta efetivamente o domínio A da replicação de suas transações em todo lugar. O carregamento de distribuição de mudança em um domínio é limitado pelo número de links que ele usa, e não pela quantia de domínios presentes na topologia. Esta propriedade carregamento fornece escalabilidade, de modo que os domínios na topologia possam compartilhar a carga de distribuição de mudança.
A <=> B <=> C <=> D <=> E
O carregamento de distribuição nos domínios de serviço de catálogo A e E é o mais baixo, porque cada um deles possui um link apenas para um domínio de serviço de catálogo único. Cada um dos domínios B, C e D possui um link para dois domínios. Assim, o carregamento de distribuição nos domínios B, C e D é o dobro do carregamento nos domínios A e E. A carga de trabalho depende do número de links em cada domínio, e não do número geral de domínios na topologia. Assim, a distribuição dos carregamentos descrita permaneceria constante, mesmo se a linha contivesse 1.000 domínios.
Leve em consideração as seguintes limitações quando usar topologias de replicação multimestre:
A rechamada desses soquetes TCP usa um mecanismo de janela deslizante para controlar o fluxo de dados em massa. Este mecanismo geralmente limita o soquete para 64 KB para um intervalo de roundtrip. Se o intervalo de roundtrip for de 100 ms, a largura de banda será limitada a 640 KB/segundo sem ajuste adicional. Usar totalmente a largura de banda disponível em um link pode exigir um ajuste específico para um sistema operacional. A maioria dos sistemas operacionais inclui parâmetros de ajuste, inclusive opções RFC 1323, para aprimorar o rendimento por meio dos links de alta latência.
A replicação multimaster inclui uma quantidade fixa de processamento por entrada de Mapa para manipular a versão. Cada contêiner também controla uma quantia fixa de dados em cada domínio de serviço de catálogo na topologia. Uma topologia com dois domínios de serviço de catálogo usa aproximadamente a mesma memória que uma topologia com 50 domínios de serviço de catálogo. O WebSphere eXtreme Scale não usa logs de reprodução ou filas semelhantes em sua implementação. Assim, não há nenhuma estrutura de recuperação pronta caso um link de replicação esteja indisponível por um período prolongado e reinícios posteriores.