Considerações de Design para Replicação Multimestre

Ao implementar da replicação multimestre, você deve considerar aspectos de design, como arbitragem, vinculação e desempenho.

Considerações sobre Arbitragem no Design de Topologia

Poderão ocorrer colisões de mudanças se os mesmos registros puderem ser alterados simultaneamente em dois locais. Configure cada domínio de serviço de catálogo para ter aproximadamente a mesma quantia de processador, memória e recursos de rede. Observe que os domínios de serviço de catálogo que executam a manipulação da colisão de mudanças (arbitragem) usam mais recursos que outros domínios de serviço de catálogo. As colisões são detectadas automaticamente. Elas são manipuladas com um desses dois mecanismo:
  • Árbitro de conflito padrão: O protocolo padrão deve usar as mudanças a partir do domínio de serviço de catálogo mais baixo denominado de maneira lexical. Por exemplo, se os domínios de serviço de catálogo A e B gerarem um conflito para um registro, a mudança no domínio de serviço de catálogo B será ignorada. O domínio de serviço de catálogo A mantém sua versão e o registro no domínio de serviço de catálogo B é alterado para corresponder ao registro do domínio de serviço de catálogo A. Esse comportamento também se aplica aos aplicativos nos quais os usuários ou as sessões são normalmente ligados ou têm afinidade com uma das grades de dados.
  • Árbitro de colisão customizado: Os aplicativos podem fornecer um árbitro customizado. Quando um domínio do serviço de catálogo detecta uma colisão, ele inicia o árbitro. Para obter informações sobre como desenvolver um árbitro útil customizado, consulte Desenvolvendo Árbitros Customizados para a Replicação Multimestre.
Para topologias nas quais as colisões são possíveis, considere implementar uma topologia hub-and-spoke ou uma topologia em árvore. Essas duas topologias tendem a evitar colisões constantes, o que pode acontecer nos seguintes cenários:
  1. Diversos domínios de serviço de catálogo experimentam uma colisão.
  2. Cada domínio de serviço de catálogo manipula a colisão localmente, produzindo revisões.
  3. As revisões colidem, resultando em revisões de revisões

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.

A tabela a seguir resume as abordagens de arbitragem que são mais compatíveis com várias topologias.
Tabela 1. Abordagens de Arbitragem. Esta tabela define se a arbitragem de aplicativo é compatível com várias tecnologias.
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.

Considerações sobre Links no Design de Topologia

De forma ideal, uma topologia inclui um número mínimo de links enquanto otimiza trade-offs entre latência de mudança, tolerância a falhas e características de desempenho.
  • Latência de mudança

    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 velocidade com que uma mudança é copiada para outros domínios do serviço de catálogo depende de fatores adicionais, como:
    • Processador e largura da banda da rede no domínio de serviço de catálogo de origem
    • O número de domínios de serviço de catálogo intermediários e de links entre o domínio de serviço de catálogo de origem e de destino
    • Os recursos de processador e de rede disponíveis para os domínios de serviço de catálogo de origem, de destino e intermediários
  • Tolerância a falhas

    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:

    Topologia em linha

    Se qualquer uma dessas condições for mantida, o Domínio D não verá nenhuma mudança a partir do A:
    • O Domínio A está ativo e o B está inativo
    • Os Domínios A e B estão ativos e C está inativo
    • O link entre A e B está inativo
    • O link entre B e C está inativo
    • O link entre C e D está inativo
    Em contraste, com uma topologia em anel, cada domínio de serviço de catálogo pode receber mudanças a partir de qualquer direção.

    Topologia em Anel

    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.

    Topologia Hub-and-spoke

    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.

  • Vínculo e desempenho

    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.

    Um domínio de serviço de catálogo pode recuperar as mudanças indiretamente por meio de outros domínios de serviço de catálogo. Considere uma topologia em linha com cinco domínios de serviço de catálogo.
    A <=> B <=> C <=> D <=> E
    • A pega mudanças de B, C, D e E por meio de B
    • B pega mudanças de A e C diretamente e mudanças de D e E por meio de C
    • C pega mudanças de B e D diretamente e mudanças de A por meio de B e E por meio de D
    • D pega mudanças de C e E diretamente e mudanças de A e B por meio de C
    • E pega mudanças de D diretamente e mudanças de A, B e C por meio de D

    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.

Considerações de Desempenho de Replicação Multimestre

Leve em consideração as seguintes limitações quando usar topologias de replicação multimestre: