Как потратить почти полмиллиона долларов, чтобы собрать в центре Сан-Франциско хранилище данных объёмом 30 петабайт

Мы собрали в центре Сан-Франциско центр для хранения данных с общим дисковым пространством, где хранятся видеоданные общей длительностью 90 миллионов часов. Зачем? Мы предобучаем модели, чтобы разобраться с использованием компьютеров. Дело в том, что видео гораздо крупнее, чем текстовые данные. Например, на обучение такой текстовой БЯМ как LLaMa-405B требуется ~60 ТБ текстовых данных, а на хранение видео нужно в 500 раз больше дискового пространства. За хранение всей этой информации на серверах AWS пришлось бы выложить 12 миллионов долларов в год, поэтому мы пошли другим путём и арендовали пространство в колокационном центре в Сан-Франциско. Так нам удалось снизить эти расходы примерно в 40 раз (до $354 тысяч в год, считая издержки на устаревание).

Зачем

Наш подход к использованию данных уникален. Как правило, облачные провайдеры больше всего внимания уделяют избыточности, доступности и целостности данных, и именно для учебных датасетов в области ML эти факторы несущественны. Поскольку данные для предобучения — это расходный материал, и мы вполне можем потерять любые 5% любого датасета с минимальными последствиями, мы можем работать в условиях довольно обширного повреждения данных. Этим мы отличаемся от корпораций, в которых требуется гарантировать, что никакая, даже самая малая часть пользовательских данных никуда не денется. Иными словами, нам не требуется предлагаемый в AWS уровень надёжности в 13 девяток после запятой; двух девяток более чем достаточно.

Кроме того, дисковое пространство обычно существенно переоценено. Большинство компаний использует сравнительно небольшие хранилища данных (даже такие сервисы как Discord до сих пор отводят под сообщения менее одного петабайта), а если компания оперирует петабайтами данных — то это такой рыночный гигант, что затраты на хранение данных всё равно составляют малую толику от их бюджета на вычислительные ресурсы.

В нашем случае данные — один из крупнейших ограничительных факторов, и при другой расстановке они обходились бы нам непозволительно дорого. До тех пор, пока прогноз расходов складывается скорее в пользу локального ЦОД, обслуживание которого не отбирало бы слишком много рабочего времени у основной команды, целесообразно устанавливать стойки с жёсткими дисками прямо на предприятии. Мы поговорили об этом с некоторыми инженерами с сайта Internet Archive, столкнувшимися примерно с такими же проблемами, как и мы; даже после применения серьёзных скидок «для членов семьи и друзей», действующих в AWS, оказалось вдесятеро выгоднее самостоятельно закупить стойки и хранить на них данные самостоятельно!

Разбор издержек: облачные варианты и хранение данных на предприятии

Наши текущие расходы составляют $17,5 тысяч и включают лишь оплату электроэнергии и Интернета (стоимость пространства в колокационном центре, охлаждения и пр. включена в тариф за электричество). Самой серьёзной статьёй единовременных расходов были инвестиции в закупку жёстких дисков. Подыскивая подходящий ЦОД, мы рассмотрели множество предложений в районе бухты Сан-Франциско, в том числе, вариант во Фремонте от Харрикейн Электрик, который обошёлся бы примерно в $ 10 000 затрат на установку и настройку и далее в $12 800 ежемесячно. Так мы сэкономили бы $38 500 первичных расходов и далее $4 700 ежемесячно. Но в итоге мы остановились на ЦОД, расположенном всего в паре кварталов от нашего офиса в Сан-Франциско. Пусть и пришлось немного переплатить, нам очень помогло, что первичную настройку узлов выполнили за нас, а также обеспечили нам текущую поддержку. У нас в команде всего 5 человек, поэтому любая возня с ЦОД серьёзно ударила бы по нашей продуктивности.

Таблица 1: Сравнение стоимости различных облачных альтернатив и хранения данных на предприятии. Исходя из ожидаемого исходящего трафика, за AWS придётся выложить $1 130 000 ежемесячно, за Cloudflare — $270 000 ежемесячно (с учётом скидки за высокие объёмы). Наш же ЦОД обходится нам в $29 500 ежемесячно (включая текущие расходы и расходы на устаревание).

Ежемесячные текущие расходы

Единовременные расходы

Мы закладывали в цену устаревание за три года (в том числе, единовременные выплаты за установку), и у нас получилось, что фиксированные ежемесячные расходы составят $17 500 (Интернет, электроэнергия) плюс $12 000 на устаревание, всего $29 500.

Мы сравнили наши расходы с расценками двух основных источников. За основу взяли имеющиеся в открытом доступе тарифы AWS, а также цена от  Cloudflare (со скидкой) за 30 ПБ дискового пространства. Здесь отмечу, что входящий трафик на AWS был бы гораздо ниже, если бы мы пользовались GPU от AWS. На нашем графике это не отражено, поскольку GPU от AWS продаются по ценам существенно выше рыночных, а приобретать большие кластеры таких устройств сложно и при интересующих нас масштабах вычислений — нерационально.

Вот разбор цен:

Прайс AWS

Расценки на Cloudflare R2

Cloudflare выставляет более разумный тариф за 30 ПБ, в результате общие ежемесячные издержки составляют $270 000 без цены входящего трафика. Также, выяснив ценовые квоты, мы в общем виде оценили скидки за большой объём. Именно этот показатель мы выбрали основным при сравнении ЦОД.

В результате получаем ежемесячные расходы в размере $38/ТБ/месяц для AWS, $10/ТБ/месяц для Cloudflare и $1/ТБ/месяц в нашем «датацентре» — экономия соответственно в 38 раз и в 10 раз. (Нижний край этого ценового спектра занимает Backblaze, у которого есть предложение $6/ТБ, но этот вариант не подходит для обучения модели, поскольку предусматривает ограничение входящего трафика. Ещё у них есть продукт Overdrive по $15/ТБ, ориентированный именно на работу с ИИ, и он сближается с предложением от Cloudflare как по цене, так и по производительности).

Ранее мы использовали Cloudflare в качестве аналога для сравнения, и бывало так, что наша нагрузка оказывалась чрезмерной для их серверов R2. В частности, ранее при крупных прогонах по обучению модели мы так нагружали их сервера, что они ограничивали нам скорость. Позже они подтвердили, что мы действительно слишком сильно насыщали их уровень метаданных, и ограничение скорости было не синтетическим. Учитывая, насколько просты наши метаданные, хранящиеся в куче, а у нас к тому же выделенное соединение на скорости 100 Гбит/с, на нашем оборудовании мы с такими проблемами не сталкивались. Вообще, нам нравится Cloudflare, и мы часто пользуемся их продуктами. Но эту байку мы здесь рассказали не чтобы их подколоть, а чтобы проиллюстрировать, насколько сложно обрабатывать данные в нужных нам масштабах!

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

Настройка/процесс

Для нас было очень важно, чтобы всё это можно было собрать быстро, поскольку без должного внимания такой процесс может тянуться месяцами. Так что мы устроили «субботнюю жёсткую дискотеку» — Storage Stacking Saturday или просто S3. Мероприятие для ценителей жёстких дисков мы устроили в центре Сан-Франциско, пригласили друзей, угощали их и дарили винчестеры с именными гравировками всем, кто нам помогал. Мы взялись за дело в шесть утра и трудились около полутора суток (с перерывами на сон). Тем временем мы успели расположить на стойках и подключить рабочие винчестеры на 30 петабайт данных. Чтобы дело шло быстрее, мы привлекли и наёмных рабочих, а ближе к концу мероприятия подтянулись профессиональные установщики.

Наш софт состоит из 200 строк кода на Rust, нужных для записи данных (этот код определяет, на какой именно диск будут записываться данные) и веб‑сервера nginx для чтения данных. Также у нас настроена простая база данных SQLite, в которой отслеживаются метаданные — например, на каком узле кучи находится каждый файл, и к какому сегменту данных он относится. Мы стремились держать всю систему умопомрачительно простой, а не прибегать к MinIO или Ceph, поскольку нам не требовались никакие возможности, предоставляемые в этих инструментах. Отлаживать программу из 200 строк гораздо, гораздо проще, чем отлаживать Ceph, а нас при этом не интересует ни избыточность, ни шардирование. Все наши жёсткие диски отформатированы под файловую систему XFS.

Ландшафт доступного софта для этих целей очень разнообразен, но у каждого доступного варианта есть свои недостатки. Те, кто обладает опытом работы с Ceph, решительно не рекомендовали нам пользоваться этим инструментом, если только не собираемся брать в команду специалистов по Ceph. Исследовав эту проблему, мы убедились, что этот совет верный. Оказывается, Ceph в большинстве практических случаев неоправданно сложен. Этот инструмент требуется только компаниям, в которых абсолютно необходимо добиться максимальной производительности и кастомизации, причём компания должна быть готова серьёзно инвестировать в настройку. Если требуется обеспечить совместимость с S3, то интересный вариант предлагает Minio. Но в остальном это решение остаётся слишком вычурным как для нашего, так и для других схожих прикладных случаев. Weka и Vast абсурдно дорого стоят — примерно по 2000 / ТБ /год. Они рассчитаны в основном на работу с интерфейсами NVME, а не на поднятие дисков.

Разбор полётов

Соорудить собственный ЦОД — серьёзный проект, и за его реализацией мы определённо узнали много нового, как хорошего, так и плохого.

Что мы сделали правильно

• Думаем, что при актуальных для нас скоростях дисков мы очень взвешенно сбалансировали избыточность и мощность. Мы смогли почти полностью насытить нашу 100G‑сеть как на чтение, так и на запись.

• Хорошо, что мы обустроили ЦОД всего в паре кварталов от офиса, так как требовалось много заниматься отладкой и просто работать вручную.

• На Ebay удобно находить производителей, а вот покупать сами товары — не очень. Когда мы подобрали производителей, оказалось, что почти каждый из них может самостоятельно не только прислать нам всё, что нам требуется, но и предоставить гарантии. Это исключительно ценно.

• Очень важно обзавестись выделенным интернетом на 100G. В таком случае всё гораздо, гораздо проще отлаживать, чем при использовании облачных продуктов.

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

• У нас в очень высоком приоритете было стараться не усложнять систему, и благодаря этому мы тоже сэкономили массу сил. Мы очень рады, что не стали пользоваться Ceph или Minio. В отличие, например, от Nginx, они не работают прямо из коробки. Мы были готовы лишь написать простой скрипт на Rust, и нам этого хватило, чтобы насытить сеть данными как на чтение, так и на запись на скорости 100 Гбит/с. Никакого мудрёного кода нам не потребовалось.

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

Сложные моменты

Конечно, на карте реальная местность всегда изображается не во всей полноте. Так и мы, настраивая наш ЦОД, столкнулись с некоторыми проблемами и неожиданными сложностями. Из них можно составить такой список:

• Мы загружали жёсткие диски в нашу серверную стойку спереди, а не сверху. Таким образом, нам требовалось отдельно прикрутить каждый винчестер — а это утомительно, когда их у вас 2400.

• Наше хранилище получилось неплотным — мы могли бы обойтись впятеро меньшим куском работы, если бы разместили жёсткие диски теснее друг к другу.

• Попытки облегчить себе жизнь, например, при помощи последовательных подключений (daisy chaining) обычно себя не оправдывают. Мы могли бы добиться гораздо более высокой скорости как при чтении, так и при записи, не прибегая к последовательному соединению сетевых узлов, а присвоив каждому корпусу собственный HBA (хост-адаптер шины, не так и дорого он стоит).

• Ключ к успеху — в совместимости. Если говорить о функциональности сетей, здесь буквально всё завязано на конкретные бренды. Здесь у нас было много болевых точек. Оптоволоконные трансиверы не работают примерно никогда, если не сочетать их с техникой нужной марки, а с медными кабелями всё гораздо проще. На FS.com достаточно хорошая подборка и приятные цены (хотя, приводимые у них оценки скорости часто не согласуются друг с другом). На Amazon также очень быстро находятся нужные комплектующие.

• Прокладка сетей обошлась нам достаточно дорого, и здесь обязательно требовалось экспериментировать. В целом данные из нашего учебного множества — не самые конфиденциальные, мы оптимизировали весь процесс в сторону удобства и лёгкости использования. Мы не применяли DHCP, так как приобретённые нами подержанные заводские коммутаторы не поддерживают этот функционал из коробки. Кроме того, мы не использовали трансляцию сетевых адресов, так как хотели, чтобы у наших узлов были публичные IP. Это обеспечивает быстрый и высокопроизводительный доступ с наших серверов. (Неиспользуемые порты мы заслонили брандмауэрами, а элементарную безопасность обеспечили при помощи nginx secure_link; мы не могли бы себе такого позволить, если бы работали с пользовательскими данными — но в нашем случае это было вполне нормально.) Притом, что именно в этой сфере мы сэкономили бы время, если бы предпочли облачное решение, нашу сеть мы подняли за считанные дни, а все огрехи подправили не более чем за 3 недели.

• Часто у нас возникали узкие места при обращении на сервер через монитор и клавиатуру, поэтому при настройке нам пригодились стоявшие без дела реанимационные загрузочные тележки.

Что стоило бы попробовать

• Рабочие KVM исключительно полезны, и не стоит приступать к работе без них или хорошего интеллектуального интерфейса управления платформой (IPMI). Самому заходить в ЦОД очень неудобно, даже если он расположен в квартале от вас. IPMI в данном случае хорош, но только если ваши машины сконфигурированы максимально единообразно.

• Относитесь к вашей Ethernet-сети для управления ЦОД со всей серьёзностью. Действительно удобно бывает при конфигурировании сети зайти на сервер через SSH, и интерфейс IPMI для этого подходит отлично!

• С избытком обеспечивайте вашу сеть — например, если это возможно, то запасите 400 гигабит для внутреннего пользования (для этой цели подойдут карты 100G и т.д!)

• Можно было бы существенно повысить плотность дисков, если заранее потратиться на 90-местные модели SuperMicro SuperServer и заполнить их 20-терабайтными винчестерами. В результате мы бы могли обойтись 2 стойками вместо 10, а по общей мощности ЦП сравниться с 20 AMD 9654s. При этом нам понадобилось бы даже меньше электричества.

Как собрать такое самостоятельно

Если вы хотите воспроизвести нашу конфигурацию — вот что нужно сделать.

Хранилище данных

• 10 ЦП для головных узлов.

  • Мы пользовались Intel Rr2000 с Dual Intel Gold 6148 и 128 ГБ оперативной памяти DDR4 ECC RAM на сервер (они просто копеечные, а применительно к нашим задачам вполне работают), но вообще здесь к вашим услугам большое поле выбора, и можно проявить гибкость.

  • Если применить вышеописанную конфигурацию, то, скорее всего, на серверах не получится выполнять вообще никаких задач, требующих высокой вычислительной интенсивности (речь об обработке данных на устройстве, сжатии данных в формате ZFS / дедупликации / т.д., что бывает ценно, если вы храните не видео, а другие данные.

  • Наши узлы ЦП обошлись нам по $600 каждый — но кажется вполне рациональным потратить до $3 000 на каждый, если вам требуется ZFS / сжатие или возможность обрабатывать данные на процессоре.

• 100 корпусов DS4246 — в каждом умещается по 24 жёстких диска.

• 2 400 3,5-дюймовых HDD — в каждом корпусе должны находиться только SATA или только SAS.

  • Если возможно, то советуем пользоваться именно жёсткими дисками SAS. При работе с дисками SAS придётся иметь дело с многопутевым подключением, либо отключить эту возможность, что достаточно просто. Диски SAS примерно вдвое превосходят по скорости аналогичные диски SATA.

  • Мы сочетали винчестеры по 12 ТБ и 14 ТБ — в принципе, подойдут диски любого размера, но вообще чем больше диски, тем лучше, если удерживать цену постоянной (чем выше плотность, тем проще укладка дисков + как правило возрастает стоимость при перепродаже).

• Детали для монтирования корпусов — вам понадобятся салазки или l-образные кронштейны. Мы воспользовались l-образными кронштейнами и были правы, так как в таком случае удалось вставлять жёсткие диски, не вынимая корпусов. Если собираетесь загружать винчестеры сверху, то понадобится использовать салазки.

• Множество «реанимационных тележек» с мониторами и клавиатурами, через которые вы сможете физически подключаться к головным узлам ЦП и конфигурировать их. Эта возможность просто неоценима, когда приходится разбираться с сетевыми проблемами.

Сеть

• Коммутатор 100 GbE

  • Подержанная Arista вполне подойдёт, должна быть QSFP28, стоить будет примерно $1000-2000.

• HBA (Хост-адаптеры шины), через которые головные узлы подключаются к корпусам DS4246.

  • Лучшая конфигурация из испробованных нами включала хост-адаптеры 9305-16E, по три адаптера на сервер (убедитесь, что в вашем сервере они поместятся по габаритам!) с мини-кабелями SFF-8644 к QSFP для работы с разъёмами SAS.

  • Предусмотрено 4 слота для хост‑адаптеров, поэтому каждый корпус DS4246 можно подключить напрямую к хост‑адаптеру. Мы для удобства в итоге решили поставить хост‑адаптеры LSI SAS9207-8e, в каждом из которых по два порта. Соединили их с головными узлами ЦП, а затем по принципу ромашки подключили DS4246s к QSFP+ to QSFP+ DAC. Всё это мы развернули в ходе нашей жёсткой субботней дискотеки. Затем, когда требовалось быстро провести отладку, обкатали вышеописанный метод на одном из серверов и вышли на уровень ~4 Гбит/с на корпус. Но в итоге сочли нецелесообразным перестраивать по такому принципу просто из соображений трудозатрат — некоторые из головных узлов мы установили так, что их было сложно вынуть. По опыту, достаточно дёшево будет выполнить то, что описано выше, а поскольку мы такую конфигурацию уже протестировали — вам следует действовать так, как описано здесь, не повторяя наших ошибок.

• Сетевые карты

  • Мы пользовались Mellanox ConnectX-4 100GbE. Убедитесь, что они настроены в режиме для Ethernet, а не для Infiniband, чтобы не было сложностей с конфигурацией.

• Кабели DAC (медный кабель прямого подключения) или AOC (активный оптический кабель) удобны для подключения сетевых карт из ваших головных узлов к коммутатору и, следовательно, к Интернету. DAC-кабели практически наверняка понадобятся вам в ваших стойках, если они расставлены тесно, поскольку DAC отличаются гораздо лучшей совместимостью с каким угодно сетевым оборудованием, нежели AOC.

Рекомендуем найти поставщика, который будет обеспечивать вас готовыми головными узлами ЦП, где уже установлены как хост-адаптеры, так и сетевые карты. На рынке есть поставщики подержанных комплектующих из ЦОД/с предприятий, они готовы вам помочь. Существенное достоинство такого варианта в том, что вам не потребуется самим тратить многие часы на установку хост-адаптеров и сетевых карт, а также будете гораздо более уверены, что ваше оборудование будет работать правильно. 

• Последовательные кабели — они понадобятся вам для подключения к коммутатору!

• Необязательно, но рекомендуется: какая-либо сеть для управления Ethernet. Если вам не так легко обзавестись ethernet, рекомендуем приобрести подобный wifi-адаптер, а затем подобный Ethernet-коммутатор. Настраивать их существенно легче, чем 100GbE, и это будет отличный резервный вариант на случай, если что-то не сработает. Также в такой конфигурации вы сможете примерно всё делать по SSH прямо из уютного офиса, а не ходить в ЦОД.

Технические требования к ЦОД

• 3,5 кВт полезной мощности на шкаф с 10 корпусами по 4U + 1 2U (высота шкафа — 42U)

• 1 запасной шкаф для коммутатора 100GbE 1U или 2U (разумеется, можно просто освободить место под коммутатор в корпусе на 4U в другом шкафу).

• 1 шкаф 42U на каждые 3 петабайта хранимых данных.

• Выделенное соединение 100G (будет выполняться в виде оптоволоконной пары, например через QSFP28 LR4, но для начала согласуйте это с провайдером, предоставляющим вам место в ЦОД!

• В идеале ЦОД должен физически находиться неподалёку от вашего офиса — бывает неоценимо иногда самому сходить к серверам и исправить проблему, вместо того, чтобы возиться с удалёнными сервисами, только чтобы подать интернет на узлы.

Некоторые советы по настройке:

• Для начала убедитесь, что правильно сконфигурировали ваш коммутатор. От модели к модели есть отличия, но обычно всё достаточно просто — необходимо всего лишь физически подключиться к коммутатору, а затем сконфигурировать именно тот его порт, в который выведено ваше соединение 100GbE. У вас в ЦОД вам предоставят FXC (оптоволоконную перекрёстную коммутацию), и этот кабель нужно подключить к трансиверу QSFP28. Обязательно убедитесь, что ваш трансивер совместим по форме с требованиями интернет‑провайдера, вероятно, потребуется LR4. Также убедитесь, что он поставляется для работы с коммутаторами именно вашей марки, иначе с большой вероятностью ничего работать не будет). Зависит от провайдера, но, в любом случае, объясните им, что вам обязательно нужно пускать «свет» по оптоволоконным кабелям в обе стороны. Для этого, возможно, потребуется сделать вот так или каким‑то другим способом удостовериться, что всё работает правильно.

  • Если ваш коммутатор не работает или вам ранее не приходилось конфигурировать такие приборы, можно попытаться напрямую подключить оптоволоконный кабель, предоставленный интернет-провайдером, к одному из серверов вашей кучи. При этом вам нужен трансивер, совместимый с сетевой картой той марки, что вы используете (напр., Mellanox). Как только удастся запустить систему с этого конца — возвращайтесь к коммутатору и налаживайте его.

• Когда вам удастся подключиться к Интернету через ваш коммутатор (чтобы это проверить, просто пинганите 1.1.1.1) — можно переходить к настройке сетевых планов для отдельных узлов. Проще всего это сделать в процессе настройки Ubuntu, на одном из этапов которой вы сможете настроить интернет для головных узлов ваших ЦП, но вообще это осуществимо и вне Ubuntu.

Проведя интернет на ваши узлы и правильно подключив по 1 кабелю к каждому DS4246, отформатируйте и смонтируйте диски на каждом узле, протестируйте их, убедитесь, что они правильно работают, а затем можете развёртывать на них любой софт, какой хотите.