Решено: Хитрая настройка ntp

[noize]

Добрый день, уважаемые. Возникла необходимость на сервере настроить синхронизацию времени при загрузке системы. Аппаратные часы работают из рук вон плохо и постоянно сбиваются. Системное время синхронизируется с локальным ntp-сервером. Если сервер перезапускается в штатном режиме, то всё ок, система сохраняет системное время в аппаратные часы и при загрузке мы получаем корректное время, но если сервант погасили аварийно, то при загрузке получается отставание от нескольких минут до нескольких дней(в зависимости от предыдущего аптайма). Через какое то время ntpd скачком синхронизирует время и вроде бы всё ок, но вот загвоздка - на сервере запущен CARP, который жёстко привязан к системному времени и если оно скачком меняется, то сервер начинает сходить с ума. Я добавил в крон сохранение текущего системного времени в отдельный файл и установку даты при загрузке системы из этого файла. Но опять же, дата из файла отличается от той, которая будет выставлена демоном ntpd. Разница в минуту уже критична. Поэтому хочу спросить, можно ли настроить ntp таким образом, чтобы он, скажем синхронизировался раз в секунду и если есть отставание от времени на ntp-сервере, постепенно, при каждой синхронизации, увеличивал время, скажем, опять же на секунду?

[IMB]

Для начала замените батарейку на материнке.

[noize]

Это не решение. Очень многие материнки страдают этим недугом.

[rm_]

Да уж, знатный мазохизм, крутить критичные ко времени сервисы на железе с глючными часами.
Батарейку заменить попробуйте, действительно. Если не поможет, пробуйте добавить в крон, раз в минуту:

Код: Выделить всё

hwclock --systohc

[noize]

Да дело то не в батарейке. Я ж написал, что при загрузке, сервер берёт время из файла, в который это же самое время по крону пишется раз в минуту. Т.е. при загрузке время выставляется с ~ 2-х минутной задержкой, а потом через ntpd скачком синхронизируется с сервером. Так вот, это скачок всё и портит. Необходимо настроить синхронизацию так, чтобы он плавно нарастала.

[danger08]

Дело может быть не только в батарейке.
Видел убегание времени вперед на сервере с 2.6.9 (RHEL4), в логах сообщения вида "unstable time source".
В свое время на тех.форумах попадались такие вопросы.

Кстати, аналогичная железка на CentOS 5 (2.6.18) работает без проблем.

[noize]

Да нет, вы меня не поняли. Неважно, убегает время или стоит на месте. При перезагрузке время по-любому будет отставать от текущего на какую то величину. ntpd эту разницу сократит, но сделает это скачкообразно, что неприемлимо для CARP, там разница в 2 секунды с предыдущим временем - и всё, он начинает сходить с ума. Необходимо, чтобы время плавно выравнивалось.

[rm_]

Необходимо настроить синхронизацию так, чтобы он плавно нарастала.

ntpdate с ключом -B (см. man ntpdate).

При перезагрузке время по-любому будет отставать от текущего на какую то величину. ntpd эту разницу сократит, но сделает это скачкообразно, что неприемлимо для CARP, там разница в 2 секунды с предыдущим временем - и всё, он начинает сходить с ума.

Ну так сначала исправьте время, а уже потом запускайте CARP. В чём проблема?

[noize]

Ну так сначала исправьте время, а уже потом запускайте CARP. В чём проблема?

а если вдруг по каким то причинам ntp-сервер недоступен или сеть не поднялась, тогда что делать? Ждать, пока произойдёт чудо? ))
Необходимо продумать возможные аварийные ситуации.

ntpdate с ключом -B

Сейчас смотрю в сторону adjtimex - его применение рекомендуют как замену ntpdate -B, но всё-равно, за подсказку спасибо

[Bizdelnick]

ntpdate до старта ntpd и CARP не выход?

Upd: А, ну вон это же выше советовали.

[noize]

Ну так сначала исправьте время, а уже потом запускайте CARP. В чём проблема?

а если вдруг по каким то причинам ntp-сервер недоступен или сеть не поднялась, тогда что делать? Ждать, пока произойдёт чудо? ))
Необходимо продумать возможные аварийные ситуации.

[SSDD]

а откуда взять время если его нет? %)

1. писать каждую минуту в фаил пока жив серв, после перезагрузки воостанавливать из файла(возможно с внесением поправок) если не доступен ntp
2. спаять переходник от внешних часов через com/USB получит время :-DDDDDDDDDDDDD

[Bizdelnick]

Ступил и написал всё с точностью до наоборот :-)

Under ordinary conditions, adjusts the clock in small steps so that the timescale is effectively continuous and without discontinuities. Under conditions of extreme network congestion, the roundtrip delay jitter can exceed three seconds and the synchronization distance, which is equal to one-half the roundtrip delay plus error budget terms, can become very large. The algorithms discard sample offsets exceeding 128 ms, unless the interval during which no sample offset is less than 128 ms exceeds 900s. The first sample after that, no matter what the offset, steps the clock to the indicated time. In practice this reduces the false alarm rate where the clock is stepped in error to a vanishingly low incidence.

As the result of this behavior, once the clock has been set, it very rarely strays more than 128 ms, even under extreme cases of network path congestion and jitter. Sometimes, in particular when is first started, the error might exceed 128 ms. This may on occasion cause the clock to be set backwards if the local clock time is more than 128 s in the future relative to the server. In some applications, this behavior may be unacceptable. If the -x option is included on the command line, the clock will never be stepped and only slew corrections will be used.

The issues should be carefully explored before deciding to use the -x option. The maximum slew rate possible is limited to 500 parts-per-million (PPM) as a consequence of the correctness principles on which the NTP protocol and algorithm design are based. As a result, the local clock can take a long time to converge to an acceptable offset, about 2,000 s for each second the clock is outside the acceptable range. During this interval the local clock will not be consistent with any other network clock and the system cannot be used for distributed applications that require correctly synchronized network time.

© man ntpd

Апдейт: И ещё неплохо при запуске системы перед hwclock --hctosys делать hwclock --adjust.

[IMB]

ntpd эту разницу сократит, но сделает это скачкообразно, что неприемлимо для CARP, там разница в 2 секунды с предыдущим временем - и всё, он начинает сходить с ума. Необходимо, чтобы время плавно выравнивалось.

Ну так замените ntpdate на ntp.

[noize]

Спасибо всем, кто отозвался. Bizdelnick, ваше предложение оказалось тем, чем нужно, за что вам отдельное спасибо. Всё заработало как надо при запуске ntpd -x -g