Технические особенности суперкомпьютера JURECA производства «Т-Платформы»

Это шестой материал из цикла, посвященного суперкомпьютерам и работе на этом рынке российской компании «Т-Платформы». Материалы созданы на основании интервью с Александром Голубом, директором департамента разработки «Т-Платформы», и Сергеем Клейменовым, главным специалистом по интеграции и внедрению, который занимал пост технического руководителя (так называемый «technical lead») проекта по строительству суперкомпьютера JURECA.

Оглавление

Стандартные серверы

Как уже говорилось, JURECA планировалась как простая рабочая система, поэтому для нее были выбраны серверы «Т-Платформы» серии - V-Class. Это стандартизированная пятиюнитовая блейд-система под стандартную серверную стойку. Использование стандартных решений позволяет упростить обслуживание и снизить цену решения.

Для крупных проектов это дает дополнительную экономию. Например, JURECA состоит из почти 2000 систем, и экономия в пять долларов на одной машине (например, за счет использования более дешевых HDD) в масштабах системы дает экономию в 10 000 долларов.

Благодаря грамотному проектированию и использованию качественных компонентов производительность серверов «Т-Платформы» немного выше, чем у решений от других производителей с идентичной конфигурацией. Сергей Клейменов объясняет это в частности эффективной системой питания процессоров (VRM). Сейчас процессор сам устанавливает для себя частоту работы в зависимости от потребляемой мощности. Часть потребляемой энергии тратится на саму подсистему питания. Если потери там меньше, то процессор получает более качественное и стабильное питание, что позволяет ему работать на чуть более высокой частоте.

В кластере есть выделенные узлы (технически это такие же сервера V-Class), которые занимаются тем, что раскидывают задачи, управляют работой других узлов, принимают задания от пользователей и т.д. В интернет можно выходить только с тех узлов, на которые могут заходить пользователи, остальные системы не имеют доступа вовне.

Вот краткая спецификация системы JURECA.

Рабочие узлы бывают трех типов: обычные вычислительные системы, которых в JURECA подавляющее большинство, и два вида систем под специализированные требования: одни с установленными графическими ускорителями, вторые – с большим объемом RAM.

Специализированные очереди задач и «чужие» машины в кластере

Очередь задач в Исследовательском центре Юлиха разделена на три потока:

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

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

Количество выделенных под специализированные задачи систем в кластере было установлено немецкими заказчиками на основе данных своей аналитики. Из общего количества в 1872 узла в кластере под задачи, требующие участия графического ускорителя, выделено 128, а под задачи, требующие большого объема оперативной памяти – 64 узла.

GPU акселератор (в JURECA использовали GPU Nvidia Tesla K80) устанавливается в сервер в виде обычной платы расширения MXM, поэтому с выделенными под GPU узлами проблем не возникло. А вот с тем, чтобы обеспечить некоторые узлы нестандартно большим объемом RAM, возникли проблемы. Дело в том, что из-за унифицированного дизайна плат, на них установлено небольшое количество слотов для модулей DIMM. В сервер ставится обычно 128-256 ГБ памяти, для такого объема разъемов на плате достаточно. Вообще, плата позволяет установить и терабайт, но модули памяти для серверов начиная с определенных объемов начинают стоить непропорционально дорого, т.е. технически задача решаема, но сервер будет стоить очень дорого.

В результате более выгодно оказалось включить в кластер системы на платформах Supermicro – они проигрывают по производительности, но зато их материнские платы имеют вдвое больше слотов под память, что позволяет обеспечить нужный объем оперативной памяти и не переплачивать за дорогие модули с большим объемом.

Проблема отсутствия выбора

В предыдущем материале мы уже говорили о том, что в некоторых случаях у производителей серверов и решений особо нет выбора. На многих рынках есть технический и технологический лидер, адекватной альтернативы которому просто нет. Так, архитектура х86 на сегодня не имеет альтернативы по совокупности технических и технологических параметров, и к тому же имеет огромное активное сообщество разработчиков как аппаратных решений, так и ПО. У выбравших архитектуру х86 выбора тоже нет: придется использовать процессоры Intel Xeon последнего поколения. Потому что Intel на сегодня – единственный производитель процессоров и платформ для серверов х86.

Другой пример – интерконнект, т.е. шина для обмена данными между серверами в кластере. На сегодня лидером и практически единственным поставщиком является израильская компания Mellanox со своей технологией Infiniband. Если нужна действительно высокая пропускная способность с низкими задержками – то альтернатив на сегодня нет. Infiniband последнего поколения имеет пропускную способность порядка 100 Гбит/с – а это уже все 16 линий PCI Express третьего поколения, то есть при дальнейшем росте сдерживающим фактором станет уже PCI Express.

Как построить интерконнект на еще не вышедшем на рынок решении

В свое время центр Юлиха был первым, кто построил кластер на Infiniband QDR (предыдущее поколение) со скоростью 40 Гбит/с. Поэтому в конкурсе на строительство JURECA использование Infiniband стало одним из ключевых требований.

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

У большинства конкурентов чип интерконнекта был интегрирован в материнские платы, и для них переход на новое поколение Infiniband означал замену платы или решения целиком. А в последнем поколении серверных материнских плат «Т-Платформы» все вспомогательные подсистемы, включая интерконнект, вынесены на платы расширения, т.е. можно легко заменить только вспомогательную плату. Во многом именно эта особенность предопределила победу «Т-Платформы» в конкурсе.

В JURECA интерконнект имеет топологию «толстое дерево» (Fat Tree). В каждой стойке установлены свои коммутаторы, которые соединены с четырьмя большими коммутаторами, осуществляющими обмен данных во всем кластере. Для сети Ethernet, которая используется для вспомогательных целей (передачи данных на СХД, администрирования и т.д.), в стойке установлен отдельный большой коммутатор.

На момент написания статьи в ТОП500 суперкомпьютеров есть всего две машины, в которых используется последнее поколение Infiniband – EDR. JURECA – одна из них, и она же является крупнейшим проектом с новой технологией.

Выделенная СХД

Интересной особенностью проекта стало то, что в JURECA нет своей выделенной СХД (системы хранения данных). Стратегия центра Юлиха предусматривает максимальную централизацию всех вспомогательных подсистем суперкомпьютерного центра – питания, охлаждения и т.д. Поскольку в центре работает несколько суперкомпьютеров, которые к тому же время от времени меняются, было принято решение построить отдельную СХД, с которой смогут работать все суперкомпьютеры центра. Она функционирует как отдельная система, ее обслуживанием и развитием занимаются специалисты самого центра Юлиха.

Наличие в центре собственной отдельной СХД сильно упростило задачу для специалистов «Т-Платформы»: не нужно было строить эту систему в рамках JURECA. Особых технических проблем внешняя СХД не несет – ну разве что роутинг мог бы быть попроще, но это непринципиально.

Единственное, что требовалось – организовать канал для обмена данными с СХД. От 10-гигабитных решений пришлось отказаться, т.к. они выходили за рамки бюджета. Впрочем, и обычного канала Ethernet 1 Гбит/с вполне хватает, так как сеть используется только для передачи результатов на внешнюю СХД, а также для вспомогательных задач типа администрирования, обновления ПО и т.д. Внутри кластера сделали инкапсуляцию сетевого трафика внутрь Infiniband – получилось и быстро, и дешево.

Дисковая подсистема сервера

Суперкомпьютер хранит все необходимые для работы данные и результаты в оперативной памяти, а используемая файловая система GPFS позволяет выделить под файловый кэш достаточный объем оперативной памяти. В результате, локальный накопитель сервера фактически нужен только для загрузки системы и загрузки сервисного ПО, а если использовать загрузку с флеш-накопителя или по сети, то от него можно вообще отказаться. Тестовый кластер в Юлихе был построен именно по такому принципу. Однако для рабочей системы заказчик настоял на использовании локального накопителя, причем выбрал именно жесткие диски, а не SSD. Возможно, такое решение было принято в интересах надежности, но обоснования немецкие заказчики не дали.

Бустер из «числодробилок» как отдельный компонент

Впрочем, СХД стала на единственной выделенной подсистемой. Еще в суперкомпьютерном центре планируют построить отдельный «бустер». Если кластер – это вычислительная система общего назначения, где вычисления осуществляют центральные процессоры, то бустер вообще не имеет центральных процессоров и построен исключительно на ускорителях – либо NVIDIA, либо Intel Xeon Phi. Если для решения задачи нужен GPU, то управляющее ПО должно выделять для этой задачи ресурсы бустера на программном уровне. На сегодня бустер еще не построен, для него должен проводиться отдельный конкурс.

От «Т-Платформы» требовалось предусмотреть возможность взаимодействия JURECA с будущим бустером – при том, что пока не очень понятно, каким он вообще будет. Пока специалисты «Т-Платформы» зарезервировали часть портов в интерконнекте, через которые можно будет быстро организовать подключение. Кроме того, в некоторые сервера можно установить платы расширения с шиной интерконнекта и использовать их в качестве шлюзов.

Плюсы и минусы охлаждения водой

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

Для охлаждения суперкомпьютера «Ломоносов-2» в МГУ используется экспериментальная система прямого охлаждения теплой водой, о которой мы говорили в одном из предыдущих материалов. Если кратко, то жидкостные радиаторы надеваются прямо на серверную плату, и вода с температурой 45 градусов забирает тепло, а потом охлаждается в сухой градирне – фактически, большом радиаторе. Это позволяет полностью отказаться от использования активного охлаждения кондиционерами.

Главный плюс такого решения – существенная экономия за счет отказа от мощных кондиционеров, которые составляют приличную часть как стоимости решения, так и стоимости обслуживания. А учитывая дефицит электрической мощности в Москве, сэкономленную из-за отказа от чиллера энергию можно направить на работу самого суперкомпьютера. В некоторых проектах в Европе теплая вода используется даже для обогрева помещений, прилегающих к дата-центру. Это тоже экономия, и к тому же хорошо выглядит с точки зрения энергоэффективности и экологии – модных на Западе тем.

К сожалению, у прямого водяного охлаждения есть не только плюсы, но и минусы. Возникает больше проблем с обслуживанием: снимая сервер, нужно вылить из радиаторов всю воду, а вставляя обратно – залить воду и выгнать воздух. При рассоединении подводящих трубок вода может пролиться внутрь стойки или сервера. Возможны утечки и при работе. Например, в одной из экспериментальных стоек в центре Юлиха подкапывало соединение. Объем утечки был слишком мал, чтобы его заметили приборы, но вода капала очень неудачно – в высоковольтную часть БП, что привело к короткому замыканию и вывело систему из строя. Так что от прямого водяного охлаждения в JURECA немецкие заказчики отказались.

Впрочем, есть у такого решения и концептуальные минусы. Теплая вода представляет собой оптимальную среду для развития микроорганизмов, которые ухитряются размножаться даже несмотря на то, что в такой воде мало кислорода, и она не контактирует со светом и воздухом. Например, в одном ЦОД такие микроорганизмы создали внутри трубопроводов пористые структуры, из-за которых пропускная способность упала в 10 раз, и центр пришлось останавливать на месяц для чистки трубопроводов.

В общем, воду нужно специальным образом готовить, используя химикаты. А при использовании химикатов в Европе возникают проблемы – в частности, такую воду просто некуда девать, т.к. немедленно появятся экологи и потребуют оштрафовать за нарушение экобаланса. В США и России ситуация с этим попроще.

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

Итоговая схема работы

Поэтому для JURECA сделано гибридное охлаждение. Сервера внутри стойки охлаждаются воздухом, но воздух охлаждается не кондиционером, а за счет большого, размером с дверь стойки, встроенного в шкаф радиатора. В этом радиаторе циркулирует холодная вода, которая подается централизовано. Да, охлаждение в центре Юлиха тоже централизованное: большие холодильники охлаждают воду до 6 градусов, а дальше она распределяется по подразделениям, компьютерным системам и другим потребителям.

Такая схема, кстати говоря, сняла со специалистов «Т-Платформы» еще и заботы по созданию и обслуживанию системы охлаждения для этого проекта.