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