Во время тестирования нашей конфигурации Red Hat Cluster System NTP увеличил время на 16 секунд, и вскоре после этого программное обеспечение кластера зависло.
ntpd[30917]: time reset -16.332117 s
Я должен повторить неудачу, чтобы убедиться, что это не просто совпадение. Я намерен заставить NTP постоянно сдвигать время назад, пока либо а) я не сдамся, либо б) кластер снова не зависнет.
Если ntpd использует тот же механизм, что и / bin / date, для установки времени, это легко. Если он использует другой механизм и мне нужно обмануть ntpd, чтобы настроить часы, то я застрял.
Как проще всего провести это тестирование?
Если вы хотите проверить, как система реагирует на изменение времени, используйте date возиться с часами (этого, вероятно, достаточно для вашего случая: мой инстинкт подсказывает, что программному обеспечению кластера не нравится time() назад ...).
Если вы хотите проверить, как система реагирует на изменение времени инициирован ntpd настройте сервер NTP, выполните синхронизацию с ним, затем измените время на сервере NTP (и позвольте демонам клиента делать правильные вещи).
Это не требует больших усилий, так что, вероятно, все равно стоит.
Обратные прыжки обычно вызывают проблемы с большей вероятностью, чем прямые, но оба должны быть проверены на полноту.