Я хочу запустить автоматизированную задачу (скрипт оболочки) одновременно на нескольких серверах Ubuntu с максимально возможной точностью синхронизации. В идеале я хотел бы, чтобы расхождение во времени между началом выполнения сценария было менее секунды на всех серверах. Все серверы находятся в разных местах, и большинство из них находятся в разных часовых поясах. Однако задачи, которые я собираюсь выполнить, будут выполняться через регулярные промежутки времени, поэтому часовые пояса не должны быть проблемой.

В настоящее время я рассматриваю возможность использования cron для планирования повторяющихся задач на каждом сервере, но я обеспокоен тем, что он сам по себе может быть недостаточно точным. Чтобы компенсировать это, я подумывал об использовании сетевого протокола времени, чтобы гарантировать, что на всех серверах синхронизируются часы (плюс или минус часовые пояса).

Итак, мой вопрос состоит из двух частей:

  1. Будет ли использование cron и ntp достаточно точным для удовлетворения моих потребностей?
  2. Есть ли лучший способ сделать это?

2 ответа2

1

Трудно ответить точно, поскольку существуют разные версии cron с потенциально различной точностью.

NTP, безусловно, будет обязательным для решения, подобного этому, и будет использовать ntpd вместо ntpdate, так как ntpd будет постоянно корректировать "длину секунды" в соответствии с правильной длиной секунды, в отличие от ntpdate, который просто устанавливает время и позволяет ему снова дрейфовать. После того, как система загрузилась, она больше не использует часы RTC с резервным питанием от батареи, но вместо этого будет использовать сгенерированные ЦП прерывания, которые гораздо более точны, но, возможно, их придется немного отрегулировать.

На cron:

Из справочной страницы cron:

Затем cron просыпается каждую минуту, просматривая все сохраненные crontabs, проверяя каждую команду, чтобы увидеть, должна ли она быть запущена в текущую минуту. При выполнении команд любой вывод отправляется по почте владельцу crontab (или пользователю, указанному в переменной окружения MAILTO в crontab, если таковой существует). Дочерние копии cron-ов, запускающих эти процессы, имеют свое имя в верхнем регистре, что будет видно из вывода syslog и ps.

Если cron не просыпается каждую минуту в минуту, у вас нет гарантии второй точности, но я бы рекомендовал не принимать это как должное и подвергать его проверке. Синхронизируйте серверы, используя NTP, запланируйте задание cron для работы с файлами за определенный период времени и оцените их.

После того, как вы прикоснулись к достаточному количеству файлов, вы сможете понять, какую точность имеет ваш cron.

Если ваше приложение должно синхронизироваться в течение секунды, или если ваш cron слишком неточен, будет лучше запустить сценарии на несколько секунд раньше и использовать синхронизированные часы NTP, пусть сценарии ждут нужного момента времени для продолжения с вашей просьбой.

Редактировать: быстрый сценарий bash для сна до указанной минуты:

#!/bin/bash
minute_to_start=$1
minute_now=`date +%M`
minutes_to_wait=`echo $minute_to_start - $minute_now -1 | bc -l`
now=`date +%S.%N`
to_sleep=`echo 60 - $now + \( $minutes_to_wait \* 60 \) | bc -l`
sleep $to_sleep
$2

Вы можете запустить его в cron, например:

29 7 * * * /path/to/above/script.sh 30 'the real script'

И работа начнется в 07:30:00

В моем тестировании он дрейфовал в течение 10-20 миллисекунд, и он не работает, если вы хотите начать с X:00:00.00 (в час), так что я бы не использовал его на производстве.

0

NTP способен синхронизировать время ваших серверов в течение нескольких микросекунд. Если аппаратные часы действительно плохие, вы можете переключать их ежечасно, чтобы предотвратить больший разрыв. cron берет только часы и минуты в качестве времени запуска, но запускает задания в формате чч: мм: 00, поэтому, с моей точки зрения, вы экономите на своем решении.

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .