Gostaria de executar um grande cluster de nós na nuvem (AWS, Heroku ou talvez VMS auto-gerenciado), cujos relógios devem ser sincronizados com uma tolerância predefinida em mente. Estou procurando uma tolerância de talvez 200 ms. Isso significa que, se eu tiver 250 nós, a maior diferença de relógio entre os 250 nós nunca deverá exceder 200 ms. Eu realmente não me importo com a data / hora real com relação ao mundo. A solução deve ser tolerante a falhas e não deve depender da precisão do relógio de nenhum sistema - de fato, é provável que nenhum dos relógios seja terrivelmente precis

O requisito é suficientemente forte, se, por algum motivo, a sincronização do relógio for considerada não confiável para qualquer nó em particular, eu preferiria descartar um nó do cluster devido à dessincronização do relógio - assim, em qualquer falha suspeita, gostaria de poder executar algum tipo de desligamento controlado desse n

Eu adoraria usar algo como NTP, mas de acordo com o NTPuestões conhecidas twiki:

@NTP não foi projetado para ser executado dentro de uma máquina virtual. Requer um relógio do sistema de alta resolução, com tempos de resposta para interrupções do relógio que são atendidas com um alto nível de precisão. Nenhuma máquina virtual conhecida é capaz de atender a esses requisitos.

E embora o mesmo twiki descreva várias maneiras de lidar com a situação (como executar o ntp no sistema operacional host), não acredito que tenha a capacidade de modificar o ambiente o suficiente usando a AWS ou o horoku para cumprir com as soluções alternativa

Mesmo que eu não estivesse executando em VMs, um gerente de operações confiável com anos de experiência executando o ntp me diz que o ntp pode e irá interromper a sincronização (ou simplesmente errar o horário) devido ao desvio do relógio local de vez em quando. Isso não acontece frequentemente, mas acontece, e à medida que você aumenta as máquinas, aumenta suas chances de isso acontecer. Para detectar o quão longe você está, é necessário parar o ntpd, executar um comando no modo de consulta e reiniciá-lo novamente, e pode demorar muito tempo para obter uma respost

Para resumir - preciso de uma sincronização de relógio cujo objetivo principal seja o seguinte:

xecuta bem em VMs onde o controle operacional é limitado (por exemplo: "provedores de serviços em nuvem" Tolerâncias de tempo no cluster em cerca de 200 ms entre todos os participantes Capacidade de detectar nó ruim e reagir a ele de maneira ativaolerante a falhas (sem ponto único de falh Escalável (a coisa não pode cair quando você adiciona mais nós - definitivamente evite n ^ 2) Poderia suportar centenas de nósenhum dos nós deve ser considerado com noção de tempo superior a qualquer outro n Não há problema em todo o cluster desviar (dentro do motivo) - desde que ele seja desviado em uníssono

Da descrição, parece que oBerkeley Algorithm pode ser a escolha certa aqui, mas já está implementada?

Nice to haves:

onfiguração mínima (registro automático de nós para participar) - importante para gerar novos nainel @HTML ou API (REST?) Que relata os nós que estão participando da sincronização do relógio e quais são as compensações de tempo relativoGráficos bonitos?