- PVSM.RU - https://www.pvsm.ru -

Понятие дополнительной (високосной) секунды (leap second) было введено в 1972 году International Earth Rotation and Reference Systems Service [1] (IERS) для периодического обновления Coordinated Universal Time [2] (UTC) из-за неточности наблюдаемого солнечного времени [3] (UT1) и долгосрочного замедления вращения Земли [4]. Эта периодическая поправка в основном помогает учёным и астрономам, поскольку позволяет им наблюдать за небесными телами, для большинства задач используя UTC. Если бы коррекция UTC отсутствовала, то необходимо было бы внести изменения в старое оборудование и ПО, синхронизируемое для астрономических наблюдений с UTC.
На сегодняшний день с момента введения високосной секунды UTC обновляли 27 раз.
Возможно, високосная секунда была приемлемым решением в 1972 году, когда она удовлетворяла и научное сообщество, и отрасль телекоммуникаций, однако сегодня UTC одинаково мешает и цифровым приложениям, и учёным, которые часто используют вместо него TAI или UT1.
Наша компания Meta* поддерживает стремление отрасли к отказу от дальнейшего использования високосных секунд и желание остановиться на текущем уровне (27). Добавление новых високосных секунд — это рискованная практика, от которой вреда больше, чем пользы, и мы считаем, что настало время внедрять новые технологии, которые её заменят.

Одним из важных факторов, влияющих на неравномерность вращения Земли, является постоянное таяние и затвердевание ледников на вершинах самых высоких гор мира. Это явление можно легко визуализировать, представив вращающуюся фигуристку, поддерживающую свою угловую скорость руками и ладонями. Когда она раздвигает руки, угловая скорость уменьшается, сохраняя импульс фигуристки. Когда она прижимает руки к телу, угловая скорость увеличивается.

До текущего момента добавлялись только положительные високосные секунды. Поначалу для этого просто прибавляли ещё одну секунду, что приводило к необычной временной метке:
23:59:59 -> 23:59:60 -> 00:00:00
В лучшем случае, такой скачок времени приводил к сбою программ или даже повреждению данных из-за странных временных меток в хранилище данных.
Поскольку паттерн вращения Земли меняется, с большой вероятностью в будущем мы получим отрицательную високосную секунду. Временная метка будет выглядеть так:
23:59:58 -> 00:00:00
Влияние отрицательной високосной секунды в больших масштабах никогда не тестировалось; оно может оказать разрушительный эффект на ПО, зависящее от таймеров или планировщиков.
Как бы то ни было, каждая високосная секунда представляет собой серьёзный источник проблем для людей, обслуживающих аппаратные инфраструктуры.
В последнее время стандартной практикой стало «размазывание» високосной секунды простым замедлением или ускорением часов. Универсальный способ реализации такого способа отсутствует; Meta* размазывает високосную секунду на 17 часов, начиная с 00:00:00 UTC, на основании содержимого пакета данных часовых поясов (tzdata) [5].

Размазывание високосной секунды в Meta*.
Давайте разберём это чуть подробнее.
Мы выбрали интервал в 17 часов в первую очередь потому, что размазывание происходит в Stratum 2, где сотни NTP [5]-серверов выполняют размазывание одновременно. Чтобы разница между ними была допустимой, шаг должен быть минимальным. Если шаг размазывания слишком велик, NTP-клиенты могут посчитать, что некоторые устройства неисправны и исключить их из кворума, что может привести к перебоям в работе.
Момент начала в 00:00:00 UTC тоже не стандартизирован и существует множество возможных вариантов. Например, некоторые компании начинают размазывание в 12:00:00 UTC днём ранее и растягивают его на 24 часа; некоторые начинают за два часа до события, другие начинают прямо в его момент.
Кроме того, существует множество различных алгоритмов размазывания. Есть коррекция високосной секунды ядра, линейное размазывание (когда применяются равные шаги), косинусоидальное и квадратичное (которое использует Meta*). Алгоритмы основаны на разных математических моделях и создают разные графики смещений:

Размазывание високосной секунды ядра при помощи NTPD
Источник показателя перехода для спутниковых систем навигации (т. е. GPS, ГЛОНАСС, Галилео и Бэйдоу) различается. В некоторых случаях он транслируется спутниками за несколько часов до события. В других случаях время распространяется в UTC с уже добавленной високосной секундой. В разных системах навигации значение високосной секунды различается в зависимости от времени запуска системы.

Разница значений високосной секунды между разными спутниковыми системами навигации.
Для всего этого требуется нетривиальная логика преобразований внутри источников времени, в том числе и нашего собственного Time Appliance [6]. Утеря сигнала спутниковой системы в такое важное время может привести к утере показателя перехода и конфликту, что может вызывать перебои в работе.
Также событие перехода распространяется за месяцы до события в пакете tzdata, а для фанатов ntpd — в файле високосной секунды [7], распространяемом через веб-сайт Internet Engineering Taskforce (IETF). Отсутствие свежей копии файла может привести к пропуску високосной секунды и тоже вызвать перебои в работе.
Как уже говорилось, размазывание — очень важный момент. Если в этом интервале NTP-сервер перезагрузится, то с большой вероятностью на нём будет «старое» или «новое» время, которое распространится на клиентов и приведёт к перебоям в работе.
Из-за такой неопределённости публичные NTP-пулы не выполняют размазывание, иногда для решения этой проблемы передавая клиентам показатель перехода. SNTP-обычно пошагово изменяют значения часов и имеют дело с описанными выше последствиями. Более умные клиенты могут выбрать стандартную стратегию для локального размазывания перехода. В конечном итоге это означает, что крупные игроки наподобие Meta*, выполняющие размазывание в публичных сервисах, не могут присоединиться к публичным пулам.
И даже после перехода ситуация остаётся рискованной. ПО NTP должно постоянно применять смещение относительно используемого им источника времени (спутниковой системы навигации, TAI или атомных часов), а ПО PTP должно распространять в оповещениях так называемый флаг смещения UTC.
Високосная секунда и создаваемое ею смещение вызывает проблемы во всей отрасли. Один из простейших способов вызвать перебой в работе — внедрить допущение о том, что время всегда движется вперёд. Допустим, у нас есть такой код:
start := time.Now()
// выполняем какие-то действия
spent := time.Now().Sub(start)
В некоторых случаях использования spent мы можем оказаться в ситуации, когда во время события применения високосной секунды значение должно быть отрицательным. Такие допущения приводили ко множеству перебоев в работе, и они описаны во многих статьях.
В 2012 году у сайта Reddit происходили [8] серьёзные перебои в работе из-за високосной секунды; сайт был недоступен 30-40 минут. Это произошло, когда смена времени запутала таймер высокого разрешения (hrtimer), вызвав гиперактивность на серверах, приведшую к блокировке ЦП машин.
В 2017 году Cloudflare опубликовала очень подробную статью [9] о влиянии високосной секунды на публичный DNS компании. Первопричиной бага, повлиявшего на её DNS-сервис, стало допущение о том, что время не может двигаться вспять. Код брал значения времени из апстрима и передавал их функции rand.Int63n() языка Go. Функция rand.Int63n() справедливо запаниковала, поскольку аргумент был отрицательным, что привело к отказу DNS-сервера.
Процесс применения високосных секунд вызывал множество проблем в нашей отрасли и продолжает представлять множество угроз. Вся отрасль в целом сталкивается с проблемами, когда дело касается високосной секунды. А поскольку это такое редкое событие, оно каждый раз разрушительным образом влияет на общество. Требования к точности таймеров становятся всё выше во всех отраслях, и високосная секунда вызывает больше проблем, чем создаёт пользы, приводя к беспорядку и перебоям в работе.
Мы, инженеры Meta*, поддерживаем стремление сообщества к отказу от дальнейшего использования високосных секунд и желание остановиться на текущем уровне (27), которого, как мы считаем, хватит на следующее тысячелетие.
* — признана экстремистской организацией, ее деятельность в России запрещена.
Автор:
PatientZero
Источник [10]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/facebook/377401
Ссылки в тексте:
[1] International Earth Rotation and Reference Systems Service: https://en.wikipedia.org/wiki/International_Earth_Rotation_and_Reference_Systems_Service
[2] Coordinated Universal Time: https://en.wikipedia.org/wiki/Coordinated_Universal_Time
[3] наблюдаемого солнечного времени: https://en.wikipedia.org/wiki/Solar_time#Mean_solar_time
[4] замедления вращения Земли: https://en.wikipedia.org/wiki/%CE%94T_(timekeeping)
[5] на основании содержимого пакета данных часовых поясов (tzdata): https://engineering.fb.com/2020/03/18/production-engineering/ntp-service/
[6] Time Appliance: https://engineering.fb.com/2021/08/11/open-source/time-appliance/
[7] файле високосной секунды: https://www.ietf.org/timezones/data/leap-seconds.list
[8] происходили: https://www.wired.com/2012/07/leap-second-glitch-explained/
[9] подробную статью: https://blog.cloudflare.com/how-and-why-the-leap-second-affected-cloudflare-dns/
[10] Источник: https://habr.com/ru/post/679370/?utm_source=habrahabr&utm_medium=rss&utm_campaign=679370
Нажмите здесь для печати.