Temos uma instância do Amazon EC2 CentOS 7.5 cujo relógio, na inicialização, está sempre 35 dias atrasado. Sim, você leu corretamente. Isso é uma baita deriva.
[root@myec2 ~]# ntpd -gqn
ntpd: time set +2937270.012860s
De onde a máquina busca a data atual (falsa)? Talvez em algum lugar do URI de metadados da instância http://169.254.169.254/latest/meta-data/ ?
Em um cluster Elasticsearch, todos os nós devem ser idênticos, ou seja, ter o mesmo:
ou é permitido que os nós sejam diferentes? (Além do fato óbvio de que um cluster homogêneo seria muito mais fácil de configurar, gerenciar e monitorar do que um heterogêneo.)
Estou trabalhando em várias VMs Linux cujas partições são montadas em um NetApp NAS. Este NAS experimenta periodicamente um iowait muito alto, o que faz com que os discos da VM mudem para o modo somente leitura, travem ou sejam corrompidos.
No VMware KB sugere-se aumentar o valor do timeout como uma cura paliativa:
echo 180 > /sys/block/sda/device/timeout
Quais poderiam ser os efeitos negativos de definir um tempo limite muito alto (1800 ou mais)? A meu ver, o risco é que as gravações atrasadas se acumulem e preencham o buffer de gravação de E/S, travando o sistema. Portanto, esta solução pode ser pior do que o problema.