We have an Amazon EC2 CentOS 7.5 instance whose clock, at boot, is always 35 days late. Yes, you read it correctly. That's a hell of a drift.
[root@myec2 ~]# ntpd -gqn
ntpd: time set +2937270.012860s
Where does the machine fetches the current (bogus) date from? Perhaps somewhere from the instance metadata URI http://169.254.169.254/latest/meta-data/ ?
In an Elasticsearch cluster, must all nodes be identical i.e. having the same:
or is it allowed for the nodes to be different? (Apart from the obvious fact that an homogeneous cluster would be much easier to configure, manage, and monitor than an heterogeneous one.)
I'm working on several Linux VMs whose partitions are mounted on a NetApp NAS. This NAS periodically experiences a very high iowait which causes the VM disks to switch to read-only mode, crash, or be corrupted.
On the VMware KB it is suggested to increase the timeout value as a palliative cure:
echo 180 > /sys/block/sda/device/timeout
What could be the negative effects of setting a very high timeout (1800 or more)? The way I see it, the risk is that the delayed writes accumulate and fill up the I/O write buffer, crashing the system. Therefore this solution might be worse than the issue.