Привет, Богдан на связи. Это второй по счёту пост про энергетику AI-центров.
В предыдущем посте мы посмотрели на то что из себя представляет вычислительная GPU-стойка (NVIDIA GB300 NVL72), какие модели в теории на ней могут запуститься. Строили модель, в которой энергия берётся из сети, прогоняется через сервер и отводится системой охлаждения. В этой части мы уберём некоторые допущения и будем симулировать все компоненты, по которым энергия поступает из сети до серверной стойки и по которым отводится от серверной стойки в виде тепла. Ну или по крайнер мере очень постараемся это сделать.
Вот такую схему мы будем строить в этой статье:
Что будет в этой части
Мы вместе с вами:
- посмотрим на 3 куска нашей симуляции
- разберём все компоненты, по которым энергия течёт от сети до серверной стойки (с картинками шкафов!)
- потом посмотрим через что отводится тепло
- быстренько поймём как устроена симуляция
- будем запускать симуляцию и анализировать разные сценарии: когда всё хорошо, когда сеть отключилась но дизель-генератор смог взять на себя удар, когда система охлаждения вышла из строя и многое другое
Дисклеймер
Дежурная оговорка #1: я не строил датацентры, но мне интересно разобраться как они работают и обеспечиваются энергией. Я стараюсь делать факт-чекинг, но в материале могут быть неточности. Приглашаю экспертов в комментарии.
Дежурная оговорка #2: пост написан мною, ИИ-шка помогала собирать факты и картинки. И код для симуляций тоже она писала под моим чутким руководством.
Какие компоненты есть в дата-центре
Прежде чем смотреть на нашу диаграмму, давайте посмотрим на схематичную картинку из этой научной статьи:
На ней видно, что энергия поступает от двух подстанций (желательно независимых, если вдруг какой-то экскаватор решит покопать рядом с датацентром и перерезать кабель). Далее она проходит через системы по распределению энергии (1), источник бесперебойного питания (3), который подключён в свою очередь к батареям (7). Параллельно с основной веткой стоит дизель-генератор (2), который может на время обеспечить питание датацентра если обе подстанции не дают энергии.
Так или иначе, электроэнергия доходит до серверных стоек, которые принимают эту энергию, берут запросы от пользователей и с помощью GPU и других чипов перерабатывают электроэнергию в тепло. На это схемке за отвод тепла отвечают куллер (5), чиллер (4) и блок по климат-контролю (6).
Это была обзорная картинка для того, чтобы понять как в целом устроен датацентр и его энергетические компоненты. А теперь к нашим баранам.
А что будет в нашей симуляции?
Вооруживщись знанием о том, что нам нужно как-то довести электроэнергию до серверов и потом отвести её в виде тепла, нарисуем соответствующие прямоугольники поверх нашей схемы. И про запросы пользователей тоже не забудем:
В жёлтом квадратике все компоненты, по которым течёт электроэнергия. В синем - по которым отводится тепло. Красные - наши сервера. Зелёный - запросы от пользователей.
Так, со схемой на верхнем уровне вроде разобрались. Дальше мы погрузимся во все компоненты более детально. Если не хотите деталей, то можете пролистать ниже и посмотреть на красивые анимации для разных сценариев. А для тех кому детали интересны, мы начнём с описания серверов и запросов от пользователей.
Вычислительные сервера и запросы от пользователей
Как и в предыдущей статье, мы будем иметь дело всего-лишь с четырьмя вычислительными стойками NVIDIA GB300 NVL72. В реальном датацентре их сотни и тысячи, но мы строим мини-датацентр и нам так легче будет посмотреть на числа буквально для каждого компонента.
Эти 4 сервера будут обсуживать пользователей и приносить нам деньги! Этих монстров нужно охлаждать. Если температура начинает расти, сервер сначала переходит в решим пониженной производительности, а потом отключается к херам.
Как и раньше, сервера будут работать либо на инференс (генерация ответов по запросы пользователей, на схеме обозначено через INTER), либо на обучение моделей (на схеме обозначено как BATCH). Обучение моделей более менее прогнозируемое и с постоянной высокой нагрузкой. Инференс скачет и сильно зависит от того, сколько запросов пришло от пользователей.
Запросы от пользователей будем измерять в rps (requests per second). Все запросы попадают в общую очередь (QUEUE). Если запрос не обрабатывается за 8 секунд, мы считаем что мы облажались и он попадает в корзино ПОТРАЧЕНО (DROPPED).
Задача нашего дата-центра - обработать как можно больше запросов. Желательно, с минимальными затратами и авариями.
Компоненты для передачи электроэнергии
Подстанция (UTILITY)
Итак, всё начинается с подстанций (UTILITY). Их у нас будет как минимум две, они будут желательно независимы. Про экскаватор, который любит что-то покопать и перерезать один из кабелей -- не шутка. Такое случается с завидной периодичностью. Про подстанцию мы знаем то, что она может нам дать столько энергии, сколько нам нужно (допущение, которое мы будем снимать в следующих частях).
В нашей симуляции к нам приходит 20 kV, 1500 kW на каждый ввод. На всякий случай, нужно поставить распределительное устройство с релейной защитой и учётом. Всё прям как в обычной квартире, только предохранители побольше и на много порядков дороже. Например, под наши параметры подойдёт КРУ ABB UniGear.
В симуляции подстанция умеет три состояния: работает, просаживается мощность и всё отвалилось к чёртовой матери.
Трансформатор (TRANSFORMER)
Если подать 20 kV на стойки, всё сгорит ярким пламенем. А поэтому напряжение нужно понизить до 400 V. Для этого нужен трансформатор. У него есть обмотки и они греются. На нём впервые в нашей цепочке энергия превращается в тепло. В нашей модели это примерно 1%.
Для наших целей подойдёт трансформатор с сухой изоляцией, например Siemens GEAFOL. Сухой, потому что внутри ЦОДа масло никто держать не хочет – вдруг протечёт и загорится?
Автоматический ввод резерва (ATS)
ATS = Automatic Transfer Switch (bitch!). Его задача – твёрдо и чётко выбирать откуда брать питание: из сети или от дизель-генератора. Делать это быстро и автоматически.
А ещё он должен работать по принципу break-before-make. Сначала отключает один источник, только потом подключает другой. Если вдруг вы подключите дизель-генератор прежде чем отключите линию от сети, то где-то в трёх километрах поджарится электрик.
В модели переключение занимает 1 секунду, и обратно на сеть он возвращается только после 60 секунд стабильной сети (чтобы не скакать туда-сюда, если сеть мигает). Запомните эти секунды, мы с ними ещё встретимся.
В качестве ATS можно купить ASCO 7000 series.
Источник бесперебойного питания (UPS)
У ИБП две работы.
Работа №1 - продержать нагрузку на батарее ровно столько,чтобы успел завестись дизель и ATS переключился. Это ровно те секунды, про которые мы говорили в предыдущей части.
Работа №2 - подчищать все просадки, скачки и гармоники из сети. Чтобы до IT-железа дошла идеальная синусоида без всякого дерьма.
Цена этой страховки: 3.5% от каждого киловатт-часа уйдёт в тепло.
У ИБП есть ещё один прикол - байпас. Когда ИБП понимает, что нагрузку он не тянет, он не роняет её. Он пробрасывает сеть напрямую через себя. И теперь до стоек доезжает не чистая синусоида, а синусаида с неприятным привкусом.
Для нашей симуляции будет использовать Schneider Galaxy VX: модульный трёхфазный ИБП на 750-800 kW, с модулями N+1, чтобы один можно было менять на живой системе.
В нормальном режиме он загружен процентов на 40, из проходящих через него ~334 kW превращается в тепло ~11.5 kW.
Батареи (BATTERY)
Вы покупаете батарею. А батарея покупает вам время. Время, чтобы продержаться до того как запустится генератор. Современная норма – пять минут, потому что дизель заводится за 10-30 секунд. А там уж если дизель не заведётся, то на батарее всё равно долго не проедешь.
В нашей симуляции будет 60 kWh на сторону (это 60.000.000 mAh, сравни со своим повербанком в тумбочке). Для наших четырёх стоек этого хватит примерно на 5 минут в полной нагрузке. Но так как у нас две стороны, то суммарно этого хватить минут на 10.
Батареи можно купить литиевые. Дороже, но занимают меньше места. Либо свинцовые, подешевле, но занимают больше места. Мы будет использовать литий-ионный шкаф Vertiv HPL.
Дизель-генератор (GENERATOR)
Вы покупаете дизель-генератор. А он покупает вам часы, а не минуты. Сколько именно часов – зависит сколько солярки у вас стоит в загашнике.
Основной риск генератора - эта падла может не завестись. У нас в симуляции он будет один. А поэтому нашу схему нельзя назвать честной 2N (когда дублируется каждый компонент).
В нашей симулации генератор Caterpillar C32 будет выдавать 800 kW, запускаться за 30 секунд с вероятностью 98%. Выходить на мощность он будет 10 секунд, охлаждаться после остановки 5 минут. Расход топлива у этого монстра ~200 л/ч на полной нагрузке (0.25 л на kWh). Поэтому если хотите чтобы у вас датацентр автономно проработал сутки - придётся купить 4800 литров соляры. Можете прикинуть сколько это будет по цене с соседней заправки ради интереса.
Забегая наперёд, мы будем моделировать и когда генератор запустится в штатном режиме, и когда он не сможет.
Распределение по стойкам (PDU / шинопровод)
Так, мы пости добрались до стойки. Нам нужно взять один большой ввод и разделись на много маленьких, каждый со своим автоматом – чтобы косяк в одной стойке не утащил весь зал в вальгаллу.
Для этого будем использовать шинопровод (busway). Например от Starline.
Подзравляю, мы закончили с тем как довести электроэнергию до стойки.
Компоненты охлаждения
А теперь как всё это охладить. Напомню главную мысль из предыдущей части: энергия никуда не исчезает. И каждый ватт, который зашёл в стойку и пошёл на генерацию токена, выходит из неё теплом.
Это тепло мы будем выводить из серверной стойки через воздух и через воду. Сначала про контур с водой.
CDU и насосы (CDU / PUMPS)
CDU (Coolant Distribution Unit) стоит между двумя контурами: чистым контуром, который идёт в водоблоки стоек, и контуром площадки, который идёт на улицу. Прям как на ядерном реакторе! Разделяем это ради изоляции. Протечка в контуре площадки никогда не должна доехать до трёх миллионов долларов GPU.
Занятная вещь: в блоке охлаждения насосы потребляют около 20 kW, при этом могут переносить тепла на на 2000 kW. 20 kW - ощутимо для жилого дома, но в числах датацентра это просто копейки.
Но! Если этот "маленький" насос отхлебнёт, то вся система охлаждения встанет, даже если все остальные компоненты будут работать нормально. Ну а отсутствие охлаждения приводит к сгоранию чипов и ремонту датацентра. В нашей симуляции будем использовать CoolIT CHx2000.
Контур охлаждения (COOLANT LOOP)
Контур переносит тепло от водоблока туда, где его можно выкинуть или растворить во внешний контур. Но у него есть вторая неочевидная функция. Объём воды в контуре – это тепловой маховик. А-ля "холодная" батарейка.
Вспоминаем формулу Q = m * c * dT. с - константа и равна 4.184 джоуль на градус цельсия. А поэтому если у нас есть, к примеру, 5000 литров воды в контуре, то это соответствует 5000 * 4.184 = 20920 kW·с на градус.
То есть если наши стойки выдают 540 kW тепла в секунду, то за минуту это будет 32400 kW тепла и наш контур нагреется примерно на 1.55 °C. Именно этот запас нам даёт время переключить компоненты охлаждения, если у нас есть резерв. Ну а если нет, то примерно за 20 минут всё нагреется, потом перегреется и вырубится к чертям. Это тоже мы будем симулировать.
Купить всё необходимое для этого компонента можно всё в строительном магазине: трубы (нержавейка или HDPE), буферный бак (побольше)расширительный бак. Ну и датчиков протечек раскидать на всякий случай. Картинки не будет, сорян.
Чиллер (CHILLER)
Самый расслабленный компонент в датацентре. И он один из немногих, кто реально выкидывает тепло наружу. Предыдущие компоненты его только перекладывали из одного место в другое.
По сути чиллер — это огромный холодильник: тёплая вода из контура проходит через компрессор с хладагентом, отдаёт тепло наружу через уличный радиатор, а обратно в контур уходит уже холодная вода.
Чиллеры по вечерам мерюются между собой числами COP (coefficient of performance): сколько киловатт тепла чиллер выкидывает на каждый киловатт своего собственного электричества. COP 6.0 значит: потратил 1 kW — выкинул 6 kW тепла. Чем выше COP, тем дешевле охлаждение.
Мы будем испоьзовать Carrier AquaForce 30HX, который в нормальном режиме потребляет ~76 kW электричества, чтобы выкинуть ~457 kW тепла.
Про чиллеры есть ещё много интересных нюансов, но пока остановимся чтобы не усложнять.
Воздух (CRAH)
Водой можно охладить многое, но не всё. Оптика, DPU, диски, потери блоков питания – это примерно 10% мощности стойки, которое уходит в воздух. За воздух отвечают CRAH (Computer Room Air Handler).
Воздухом мы будет отводить около 100 kW. COP у него будет 3.0. И это в 2 раза меньше чем у водного чиллера.
И второй воздушный прикол: у него почти нет тепловой массы. Если контур с 5000 литрами воды греется минут двадцать, то зал нагреется и перегреется буквально за минуты.
Мы будем использовать Vertiv Liebert CRV, который в нормальном режиме тратит ~18 kW, чтобы вывезти ~52 kW воздушного тепла, и держит зал около 24 °C.
Поздравляю, мы закончили с тем как отвести тепло от стоек!
А какой у нас PUE?
В прошлой статье мы бегло упоминали PUE (Power Usage Effectiveness) – это полное потребление площадки, делённое на потребление IT. Этим числом меряются датацентры между собой. Вот теперь можем попробовать честно это прикинуть на реальных компонентах.
Собираем по нашей сборке: 4 стойки × 135 kW = 540 kW IT. Это будет стоять в знаметателе.
А потребление площадки будет складываться из IT и расходов на охлаждение.
Из охлаждения:
- жидкостное тепло 486 kW (90%) при COP 6 даёт 81 kW электричества на чиллер
- воздушное тепло 54 kW (10%) при COP 3 даёт 18 kW на CRAH
- насосы 20 kW
Итого охлаждение тратим 119 kW. Добавляем 540 kW от IT и получаем 659 kW (что по факту забирает ИБП без учёта его потерь). Вспоминаем, что ИБП сам теряет ещё 3.5% (23 kW), трансформатор тоже теряет по пути ~5 kW и в итоге набегает ~688 kW с нашей площадки.
Делим 688 на 540 и получаем PUE = 1.27. Как его читать по-другому: на каждый доллар электричества, который делает полезную работу, вы платите 27 центов за то, чтобы это электричество доехало и чтобы получившееся тепло уехало.
Быстренько про то, как устроена симуляция
Ну во-первых, ты герой что дочитал до сюда. Моё почтение.
Постараюсь быстро описать как устроена симуляция, чтобы разглядывать ещё было веселее и понятнее. Если хочется погрузиться поглубже - приглашаю заглянуть в код (туть).
Две разные породы величин
В модели есть два принципиально разных типа чисел, и они ведут себя по-разному. Это числа состояний и числа потоков.
Состояние – заряд батареи, топливо, температуры, таймеры, очередь запросов. Это симулируется как ты и ожидаешь: каждый компонент владеет своим состоянием и двигает его каждый тик, из своих входов, не лазая в чужое состояние. Это большая часть модели.
Потоки – киловатты прямо сейчас. У них нет памяти, поэтому их нельзя интегрировать вперёд, их нужно решать внутри тика. А всё потому, что электричество реагирует мгновенно: когда стойки берут 500 kW, трансформатор в тот же момент несёт 500 kW. Если будем передавать поток по одному компоненту за тик, то будем моделировать задержку, которой на самом деле не сушествует и получим расхождение между источниками и потребителями.
Как тогда быть?
Один тик в четыре шага
Грубо говоря, будет смотреть на 2 числа: сколько оборудование может дать прямо сейчас и сколько нагрузка хочет прямо сейчас. И каждый тик симуляции мы будем делать 4 шага.
Шаг 1. Спрашиваем оборудование, сколько оно могло бы дать. Вопрос идёт вниз по каждой стороне: подстанция, трансформатор, ATS, ИБП, PDU – каждый накладывает свой лимит.
Шаг 2. Считаем, сколько хочет нагрузка. Трафик пользователей превращается в токены работы, токены – в запрос мощности на стойку. Охлаждение тоже просит, потому что насосы и компрессоры – это электрическая нагрузка.
Шаг 3. Выдаём мощность. Единственный шаг, который меняет состояние: батареи, топливо, таймеры, температуры обмоток.
Шаг 4. Потребляем. Стойки берут, тепло интегрируется, пропускная способность считается от реально взятой мощности, очередь запросов протухает.
Красиво же! Мы таким изящным решением покрыли 2 штуки одновременно: мгновенное потребление электроэнергии и постепенное перераспределение тепла. Я очень доволен собой.
И ещё нюансы
Раз. Чтобы симуляция и анимация была интереснее, мы будем дробить и делать шаг вокруз запланированных событий (поломок) меньше.Иначе 30-секундный запуск дизеля просто не попадёт на график с шагом в минуту.
Два. Охлаждение приоритетнее серверов. В глубоком провале по питанию насосы продолжают крутиться, а IT падает в ноль. Потому что потеря GPU-секунд стоит денег (обидно), а потеря чиллеров – сварит зал и GPU (очень, очень обидно!).
Проверка симуляции на адекватность
Единственная реально важная проверка на дурачка – закон сохранения энергии. В углу визуализации каждый тик печатается in − out. Он держится в нуле, потому что модель энергию сохраняет.
Это единственное, что помогает (и реально помогло) словить ошибку типа "забыли, что чиллер тоже потребляет от PDU".
С чем мы пойдём в симулицию
Вот что мы будем симулировать и ломать:
- IT 4 × GB300 NVL72, 540 kW в номинале и 620 kW на пике (точёной)
- Охлаждение (электрика) потребряет ~119 kW на номинале
- На одну сторону электроэнергии у нас трансформатор 1000 kW, ИБП 750 kW, батарея на 60 kWh, PDU 800 kW
- Генератор один (бедолага) на 800 kW, пуск за 30 с, бак 4000 л
- Трафик 76 rps на интерактивную стойку в пике, 420 токенов на запрос, через 8 секунд запрос выкидывается и считается потерянным
- Пропускная способность стойки 40 000 токенов/с на пиковой мощности
Сценарии (и весёлые картинки!)
Наконец-то мы дошли до симуляций. Правила в моей голове были такие: во всех сценариях сборка выше фиксирована, меняется ровно одна вещь – что ломается, когда ломается и сколько трафика на площадке в этот момент. Поэтому совсем упоротые ребята могут посравнивать замеры между сценариями.
Ну и чтобы не ждать аварии долго, я специально подогнал время начала модели так, чтобы мы стартовали в дневную пиковую нагрузку и авария случалась близко к началу.
Про весёлые картинки: я буду вставлять ссылки на youtube-ролики. Но в коде вы можете найти инструкцию чтобы сгенерировать эти видео самостоятельно, а также интерактивные html-страницы с большим количеством дополнительных графиков.
Сценарий 1: normal (контрольный, в голову)
Симулируем неделю, с равным тиком в минуту, ничего не ломается.
Что получилось:
- PUE в среднем 1.29, ни один запрос не потерян
- батарейки полностью заряжены
- стойки максимум догрелись до 48°C
- обслужили 62 миллиона запросов
- за неделю с площадки ушло 97 441 kWh, из них 75 515 полезного IT, 17 370 на охлаждение и 4 555 в потери преобразования.
По тарифу это (вот сейчас будет ооооочень условно) $14 097 за неделю. В России это было бы с разбросом от 400000 до 900000 рублей в зависимости от региона и типа потребителя.
! Я очень рекомендую развернуть на полный экран. Там много нюансов на которые можно позалипать.
Сценарий 2: grid_outage_gen_ok (сеть отвалилась, дизель молодец)
На десятой минуте отваливаются ОБА ввода. Видимо, экскаваторщиков тоже было два.
Последовательность:
- оба ввода в ноль
- ИБП обеих сторон подхватывают нагрузку с батарей и держат 40 секунд
- дизель крутит стартером 30 секунд и заводится
- каждый ATS переключается на генератор
- дизель работает, сжигает 41.9 литра
- на 25-й минуте сеть возвращается, ATS через 60 секунд стабильной сети возвращается обратно, батареи начинают заряжаться
Итог: uptime 100%, дропнутых запросов нет, батарея просела с 100% до 94.6%, PUE 1.28. Полное отключение внешнего питания – и пользователи не заметили ничего.
Сценарий 3: grid_outage_gen_fail (а если дизель не молодец)
Та же авария на пятой минуте, только вероятность успешного пуска выставлена в ноль.
Три попытки пуска, каждая проваливается - больше попыток не будет. Дальше площадка живёт на батареях 575 секунд (9.6 минуты), батареи доходят до отсечки 5%, оба ИБП уходят в offline. Зал темнеет. Занавес.
Итог: uptime 41.6%, обслужено 40.1% энергии, дропнуто 56.2% запросов. А всего-то решили немного съэкономить на запасном дизеле. Эх!
Сценарий 4: cooling_failure (сломалось охлаждение)
На 15-й минуте отваливается чиллер, восстанавливается на 105-й. Восстанавливается только по расписанию, потому что больше ничто в модели тепло из контура вытащить не может. Это самая моя любимая симуляция из всех!
Происходит следующий замес:
- чиллер отвалился
- контур греется на ~1.5 °C в минуту (в пике доехал до 87.5 °C)
- разница температур между стойкой и её теплоносителем сжимается
- а значит стойка может отдать меньше тепла
- а значит стойка греется ещё быстрее
- когда стойка нагревается до 85 °C, она переходит в троттлинг до 60% потребления, пропускная способность падает вместе с ним
- предложенная работа теперь больше способности её обработать, очередь растёт
- 8 секунд на запрос начинает не хватать, запросы начинают выбрасываться
- при достижении 95 °C: аварийное отключение, дропается всё
- и даже когда чиллер вернётся обратно, потребуется ещё много времени чтобы остудить всю систему
Итог: 10 троттлингов, 4 отключения, стойки догрелись до 95.0 °C, uptime 77.6%, обслужено 71.2% энергии, дропнуто 25.9% запросов. Запас чиллера ушёл в минус 463 kW.
Фан факт: одновременно с обнулением теплоотвода с площадки исчезли ~80 kW потребления чиллера. Если у дежурного на дашборде только киловатты, он видит, что потребление площадки снизилось (что вроде как хорошо. Да?)
Сценарий 5: side_a_lost (потеряли сторону A)
На 15-й минуте трипует трансформатор A на занятой площадке.
Что происходит: генератор НЕ запускается. И это правильная политика – у второй стороны полная ёмкость, зачем гонять дизель за зря. Но у ИБП A теперь нет входа, поэтому он тихо тянет свою долю нагрузки с батареи, пока не доходит до отсечки (~10 минут), и только после этого сторона B забирает на себя всё.
Итог: uptime 100%, дропов ноль, пользователи не увидели ничего. Сторона B выходит на 92.1% от своего паспорта. Батарея A ушла в 5%.
Формально всё хорошо. Но ИБП один кончился вместе с батареей и площадка полностью зависит от одной стороны. Ни о какой схеме 2N теперь говорить не приходится. Хоть и на пользовательских графиках всё чики-пуки.
Сценарий 6: side_a_lost_at_peak (то же самое, но в пик)
Тот же трип. Но допустим, что мы отдали наши стойки все на обучение новой модели от OpenAI и они жарят наши сервера на полную катушку.
Итог: ИБП B выходит на 101.3% паспорта. Держит перегруз 60 секунд и ИБП уходит в static bypass (помните, это когда он перестаёт выдавать идеальную синусоиду и пускает всякие шумы дальше по линии). Нагрузка выживает: uptime 100%, обслужено 100%, дропов ноль. Все графики зелёные.
Только теперь площадка сидит на сырой сети, без батареи между ней и стойками. Отказ здесь – это защита, которая молча (но красиво) ушла. И следующее моргание сети может прибить наш датацентр.
Сценарий 7: undersized_cords (2N только на бумаге)
Тот же трип в вальгаллу трансформатора A на 15-й минуте. Вся цепочка целая и правильно зарезервированная, но кабели одной стороны рассчитаны максимум на 474 kW, это 60% от пика площадки. Грубо говоря - кто-то решил отмыть деньжат.
И вот тут связывающим ограничением становятся не ИБП, а именно кабели. У стороны B есть ёмкость, но стойки её физически не могут получить. Поэтому IT режется и мы не можем обработать запросы пользователей.
Ещё раз цимес: uptime 100% при 20.9% дропнутых запросов. Показатели в киловаттах и показатели доступности одновременно выглядят прилично, а пользователи в это время в пятой части случаев не получают ответа.
Сценарий 8: user_surge (наплыв пользователей)
Все четыре стойки обслуживают пользователей, трафик с 15-й по 75-ю минуту растёт с плавным разгоном за 5 минут.
Питание и охлаждение не шевельнулись вообще: каждый ИБП около 50.7%, PUE 1.28, температуры в норме. Упёрлись тупо в пропускную способность стоек: предложенная нагрузка дошла до 145.7% от способности обработать, очередь набралась до 3918 запросов и до 8 секунд бюджета, 9.3% запросов выброшено.
Ограничение – компьют, а не киловатты.
Сценарий 9: load_spike (тот же вопрос, но без пользователей)
Четыре батч-стойки (обучают очередную модель OpenAI) прибиты к пику на час, трафика нет вообще, поэтому остаётся только электрический и тепловой вопрос.
Питание живёт комфортно. А вот у чиллера от 600 kW остаётся всего 42.8 kW запаса. То есть при полностью пиковой нагрузке узкое место – охлаждение, а не электрика.
Короче, нужно прям балансировать. Один и тот же вопрос "а если нагрузки больше?" имеет разный ответ в зависимости от того, нагрузка это пользователи или обучение моделей.
Вторая пачка открытий
Пока я собирал всю эту статью, вот что я для себя открыл. Я их так или иначе упоминал выше, соберу здесь ещё раз.
Самые важные 20 киловатт во всём датацентре – это насосы CDU. Потому что теплопередача идёт пока вода течёт (рифма, ёпта), и потеря насосов не ухудшает охлаждение, а тупо выключает его. И это даже при том, что чиллер продолжает исправно работать.
Объём воды – это время на реакцию. 5000 литров при 540 kW тепла дают 1.55 °C в минуту и примерно двадцать минут до того, как нашим серверам станет плохо. Буферный бак – это купленные минуты на починку системы.
Отказ охлаждения выглядит как экономия электричества (кек). Чиллер потребляет от тех же PDU. Он отвалился – потребление площадки упало на 80 kW. Если смотреть на график потребления энергии - всё красиво. А по факту жопа.
Байпас ИБП – самый незаметный отказ на мой вкус. Нагрузка выживает, все показатели зелёные, защита от шумов отхлебнула.
Конечно, мы с клодом делали так, чтобы даже в нормальном сценарии мы были на грани. Трафик в дневном пике достаёт 101.8% пропускной способности. Ничего не сломалось, никто не заметил, но запаса там нет. А потому любой даже небольшой отказ какого-нибудь компонента приводит к проблемкам.
2N не про схему в целом, а про самое узкое звено в ней. В сценарии undersized_cords: всё зарезервировано дважды (кроме генератора). Но отстойных кабелей достаточно, чтобы потерять пятую часть запросов при аптайме 100%. Не экономьте на кабелях! И на выдвыгающихся штуках для серверов (отсылка к самому богатому человеку Тайваня).
Финалочка
Весь код по-прежнему лежит тут: https://github.com/ozzzzz/energy_simulations. Там же все девять сценариев, которые можно запустить одной командой и потыкать в интерактивной визуализации (независимая html-ка).
Как обычно: если было интересно – плюсик. Если у вас есть релевантный опыт и вы видите, где я наврал – комментарии особенно приветствуются.