Блог

Sep 29, 2023

Как протокол точного времени развертывается в Meta

Реализация протокола точного времени (PTP) в Meta позволяет нам синхронизировать

Внедрение протокола точного времени (PTP) в Meta позволяет нам синхронизировать системы, которые управляют нашими продуктами и услугами, с точностью до наносекунд. Предшественник PTP, Network Time Protocol (NTP), обеспечивал нам точность до миллисекунды, но по мере того, как мы переходим к более совершенным системам на пути к созданию следующей вычислительной платформы, метавселенной и искусственного интеллекта, нам необходимо гарантировать, что наши серверы сохраняют время как можно точнее. максимально точно и точно. Благодаря PTP мы сможем улучшить технологии и программы Meta — от коммуникаций и производительности до развлечений, конфиденциальности и безопасности — для всех, независимо от часовых поясов и по всему миру.

Путь к PTP длился годы, поскольку нам пришлось переосмыслить, как аппаратное и программное обеспечение для хронометража работает на наших серверах и в центрах обработки данных.

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

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

Представьте себе ситуацию, когда клиент записывает данные и тут же пытается их прочитать. В больших распределенных системах высока вероятность того, что операции записи и чтения будут осуществляться на разных внутренних узлах.

Если чтение попадает на удаленную реплику, на которой еще нет последнего обновления, есть вероятность, что пользователь не увидит свою собственную запись:

Это как минимум раздражает, но важнее то, что это нарушает гарантию линеаризуемости, позволяющую взаимодействовать с распределенной системой так же, как и с одним сервером.

Типичный способ решения этой проблемы — выполнить несколько операций чтения для разных реплик и дождаться решения кворума. Это не только потребляет дополнительные ресурсы, но и значительно задерживает чтение из-за длительной сетевой задержки.

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

Это не только ускоряет чтение, но и экономит массу вычислительной мощности.

Очень важным условием для работы этой конструкции является то, что все часы должны быть синхронизированы или известно смещение между часами и источником времени. Однако смещение меняется из-за постоянной коррекции, дрейфа или простых изменений температуры. Для этой цели мы используем понятие «окна неопределенности» (WOU), где мы можем с высокой вероятностью сказать, где находится смещение. В этом конкретном примере чтение должно быть заблокировано до тех пор, пока не будет достигнута временная метка чтения плюс WOU.

Можно возразить, что для этого нам действительно не нужен PTP. NTP подойдет. Ну мы тоже так подумали. Но эксперименты, которые мы провели, сравнивая нашу современную реализацию NTP и раннюю версию PTP, показали разницу в производительности примерно в 100 раз:

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

Теперь, когда мы находимся на одной странице, давайте посмотрим, как мы развернули PTP в мета-масштабе.

После нескольких проверок надежности и эксплуатации мы остановились на конструкции, которую можно разделить на три основных компонента: стойку PTP, сеть и клиент.

Пристегнитесь — мы собираемся совершить глубокое погружение.

Здесь находится аппаратное и программное обеспечение, которое отдает время клиентам; стойка состоит из нескольких важных компонентов, каждый из которых был тщательно выбран и протестирован.

Антенна GNSS — один из наименее оцененных компонентов. Но это место, где зарождается время, по крайней мере на Земле.

Мы стремимся к наносекундной точности. А если приемник ГНСС не сможет точно определить положение, он не сможет рассчитать время. Мы должны внимательно учитывать соотношение сигнал/шум (SNR). Антенна низкого качества или препятствие открытому небу могут привести к высокой ошибке стандартного отклонения 3D-локации. Чтобы время определялось максимально точно, приемники GNSS должны перейти в так называемый временной режим, который обычно требует трехмерной ошибки <10 м.