Sigcomm 2024 Google раскрыла технические подробности своего внутреннего инструмента передачи данных под названием Effingo и похвасталась, что использует этот проект для перемещения в среднем 1,2 эксабайта каждый день.
Как объясняется в статье [PDF] и видео, которые будут представлены в четверг на конференции SIGCOMM 2024 в Сиднее, ограничения полосы пропускания и упрямо неизменная скорость света означают, что даже Google не застрахован от необходимости реплицировать данные, чтобы они находились близко к месту их обработки или обслуживания.
Действительно, в статье управляемая передача данных описывается как «невоспетый герой крупномасштабных, глобально распределенных систем», поскольку она «сокращает задержку сети с сотен миллисекунд по всему миру до десятков миллисекунд на континенте».
В статье также указывается, что инструменты для передачи данных найти несложно, и задается вопрос, зачем нужен такой уровень управления, как Effingo.
Ответ заключается в том, что инструменты, которые Google смогла найти, либо оптимизированы для времени передачи, либо обрабатывают потоки данных «точка-точка» — и не справляются с обработкой 1,2 эксабайт, которые Effingo перемещает в среднем за день, со скоростью 14 терабайт в секунду.
Чтобы переместить все эти биты, Effingo «балансирует между эффективностью инфраструктуры и потребностями пользователей» и признает, что «некоторые пользователи и некоторые передачи важнее других: например, аварийное восстановление для обслуживающей базы данных по сравнению с переносом данных из кластера с запланированным на неделю обслуживанием».
Инструмент должен гарантировать, что задания получат необходимую им производительность, и гарантировать, что если задания имеют одинаковый приоритет, они оба получат нужный уровень ресурсов, а не будут бороться за IOPS, полосу пропускания или вычислительные ресурсы.
В то время как остальная часть Google продолжает работать в гипермасштабном режиме.
Глубоко в G-стеке
Как Google это делает?
В статье объясняется, что Effingo оптимизирован для файловой системы Colossus, разработанной и используемой Google внутри компании, которая обычно развертывается в кластерах, состоящих из тысяч машин.
Effingo развернут в каждом кластере. Его программный стек включает в себя плоскость управления для управления жизненным циклом копии и плоскость данных, которая передает байты и сообщает о состоянии. «Потребление кода и ресурсов неравномерно: плоскость данных использует 99 процентов ЦП, но составляет менее семи процентов строк кода», — говорится в документе.
Каждый кластер подключен к каждому другому — некоторые в центре обработки данных в сети CLOS с «низкой задержкой и высокой пропускной способностью». Другие полагаются на WAN-соединения, которые используют смесь инфраструктуры Google и сторонних поставщиков.
Какая бы технология ни лежала в основе WAN, присутствует инструмент под названием Bandwidth Enforcer (BWe).
BWe — еще один проект Google, предназначенный для распределения пропускной способности на основе приоритета обслуживания и стоимости, полученной за счет добавления дополнительной пропускной способности. BWe определяет «классы сетевых услуг» (NSC), и все потоки трафика в Google «отмечаются одним из предопределенных NSC».
Когда пользователь инициирует сдвиг данных, Effingo запрашивает распределение трафика у BWe. , и приступает к работе по перемещению данных как можно быстрее.
Это распределение трафика может исходить из предопределенных квот, которые Google определяет с использованием метрик для входящей и исходящей пропускной способности на кластер, IOPS и доступных рабочих Effingo — кода, который обрабатывает перемещения данных и который работает как задания «Borg». Напоминание: Borg — это контейнеризированная платформа, которую Google выделила как Kubernetes.
Effingo может делать ставки на использование квотируемых ресурсов для рабочих нагрузок, которым требуется определенная производительность сети. Инструмент также может полагаться на ресурсы best-effort для менее критических потоков.
В документе раскрывается, что квоты «бюджетируются заранее (обычно на месяцы) в централизованной системе планирования, в которой Effingo является лишь одним из многих ресурсов».
Ресурсы с наилучшими усилиями «обычно извлекаются из недоиспользованных квот и распределяются поровну». Но если пользователю квоты нужна мощность, он может потребовать ее «в очень короткие сроки».
Даже со всей этой работой по распределению ресурсов средний размер глобального бэклога Effingo составляет 12 миллионов — обычно около восьми петабайт. Даже в лучший день в очереди находится около двух миллионов файлов. Задержки резко возрастают примерно на 12 петабайт и девять миллионов файлов, когда десять крупнейших пользователей сервиса инициируют новые передачи.
В документе приводится множество подробностей о том, как Effingo допускает параллельные операции, обрабатывает 4,2 процента передач, которые заканчиваются ошибкой, и иногда замедляет задания копирования для экономии ресурсов.
Также показано, что Effingo находится в стадии разработки: Google планирует улучшить интеграцию с системами управления ресурсами и загрузку ЦП во время передачи между центрами обработки данных. Улучшения в контуре управления для более быстрого масштабирования передач также находятся на повестке дня. ®
