Como configurar o Unison para real peer-to-peer?

Question

Eu tenho um punhado de dispositivos e estou pensando em mantê-los em sincronia com Unison .

Os dispositivos não estão funcionando o tempo todo, eles são desligados algumas horas por dia, não necessariamente ao mesmo tempo. Nenhum dos dispositivos está funcionando 24 horas por dia. Então eu preciso de real peer-to-peer , por exemplo, ver como uma mudança (marcada como * ) se propaga de A para B, C, D mesmo que nenhuma tenha sido executada durante todas as sincronizações: / p>

A-on*   B-on    C-off   D-off
A-on*   B-on*   C-off   D-off
A-off*  B-on*   C-off   D-off
A-off*  B-on*   C-on    D-off
A-off*  B-on*   C-on*   D-off
A-off*  B-off*  C-on*   D-off
A-off*  B-off*  C-on*   D-on
A-off*  B-off*  C-on*   D-on*

Infelizmente, o manual do usuário do Unison recomenda uma topologia em estrela para mais de duas máquinas:

Using Unison to Synchronize More Than Two Machines

Unison is designed for synchronizing pairs of replicas. However, it is possible to use it to keep larger groups of machines in sync by performing multiple pairwise synchronizations.

If you need to do this, the most reliable way to set things up is to organize the machines into a “star topology,” with one machine designated as the “hub” and the rest as “spokes,” and with each spoke machine synchronizing only with the hub. The big advantage of the star topology is that it eliminates the possibility of confusing “spurious conflicts” arising from the fact that a separate archive is maintained by Unison for every pair of hosts that it synchronizes.

Apesar disso, existe alguma maneira de conseguir um real peer-to-peer com o Unison?

    

Answer 1

Eu sempre usei o Unison em uma topologia em estrela para sincronizar minhas quatro máquinas. A razão para isso é que não é um sistema de arquivos de versão (como o git, por exemplo), mas sim uma ferramenta de sincronização.

Se você optar por uma topologia distribuída (que terá que configurar criando um arquivo de configuração para cada dispositivo e sincronizando todos), você, sem dúvida, acabará fazendo uma grande quantidade de resolução manual de conflitos, o que será sombrio. Esse certamente será o caso, a menos que você faça apenas alterações extremamente básicas nos arquivos do sistema e apenas em um dispositivo por vez.

Então, sugestões:

1. Alugue um servidor virtual barato com espaço de armazenamento suficiente para os dados que você deseja sincronizar.
2. Experimente a topologia distribuída e veja se isso causa muitos problemas a serem usados.

Answer 2

O uníssono é intrinsecamente ponto-a-ponto. É precisamente por isso que uma topologia em estrela é recomendada: a ferramenta não possui nenhuma noção de servidor central, então cabe ao usuário impor uma.

Você certamente pode usar o Unison de maneira peer-to-peer, mas não há milagre: para cada par de máquinas (A, B), você precisa escolher uma das máquinas (digamos A) e criar um perfil para sincronização com B. Então, se você tem n máquinas, você precisará de n * (n-1) / 2 perfis.

Além de exigir muitos perfis, é provável que você acabe com alterações conflitantes. Este é um problema intrínseco com seus requisitos. Em particular, sua rede pode se tornar particionada: se você acabar com D1 = D2 ≠ D3 = D4, você tem um conflito entre {D1, D2} e {D3, D4}; se você reconciliar esse conflito sincronizando D1 com D3, você terminará com uma nova versão em D1 e D3 e diferentes versões antigas em D2 e D4: a confusão tende a se espalhar.

Se você realmente quiser ir apenas de peer-to-peer, recomendo usar uma ferramenta que mantenha histórico e seja boa para mesclar, como o git. Mesmo lá, uma topologia em estrela (ou seja, um repositório central) é melhor, porque fornece um local que tem a versão mais recente autoritativa. Mas se você não tem um repositório central e, portanto, sua história é propensa a gerar conflitos, pelo menos o git lhe dará melhores ferramentas para gravar históricos de mesclagem para que você possa ver quais partes estão conflitando (o que ajuda muito quando você está tentando resolver os conflitos).