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