Мы должны усовершенствовать архитектуру высокопроизводительных вычислений (HPC), чтобы снизить барьеры для доступа к ресурсам, расширить возможности и стимулировать научные и корпоративные вычисления, пишет на портале The New Stack Грегори М. Куртцер, генеральный директор Linux-компании Ctrl IQ (CIQ).
В далеком 1994 г. — да, почти 30 лет назад! — Томас Стерлинг и Дональд Беккер построили в NASA компьютер под названием Beowulf.
Архитектура этого компьютера (он же кластер Beowulf) представляла собой совокупность недорогих персональных компьютеров, объединенных в локальную вычислительную сеть так, что вычислительная мощность могла распределяться между ними. Это был новаторский пример компьютера, специально разработанного для HPC и состоящего исключительно из стандартных комплектующих и свободно распространяемого ПО.
Кластер Beowulf можно было использовать для параллельных вычислений, в которых многие вычисления или процессы выполняются одновременно на многих компьютерах и координируются с помощью ПО для передачи сообщений. Это было началом Linux и открытого исходного кода для HPC, что сделало Beowulf поистине революционным. В течение следующих десяти с лишним лет все больше и больше людей следовали модели Beowulf. В 2005 г. Linux занял позицию № 1 в суперкомпьютерном рейтинге top500.org, и с тех пор является доминирующей ОС для HPC.
Базовая архитектура кластера Beowulf начинается с интерактивного узла (узлов) управления, где пользователи входят в систему и взаимодействуют с ней. Вычислительные мощности, хранилища и другие ресурсы подключены к частной сети (или сетям). Программный стек включает Linux, управление/эксплуатационную поддержку ОС (например, Warewulf), передачу сообщений (MPI), другое научное ПО и оптимизированные библиотеки, а также пакетный планировщик для управления заданиями пользователей.
Со временем эти системы стали более сложными с несколькими уровнями хранения данных и группами вычислительных ресурсов, но базовая структура Beowulf остается неизменной на протяжении тридцати лет. Так же, как и рабочий процесс HPC; с точки зрения потребителей HPC, за три десятилетия мы так и не облегчили им жизнь! В целом, каждый пользователь должен следовать одним и тем же общим шагам для всех систем HPC:
- Зайти по SSH на интерактивный узел (узлы).
- Изучить и понять конфигурацию системы хранения данных и точки монтирования.
- Загрузить исходный код в нужное хранилище.
- Скомпилировать исходный код с учетом системного или оптимизированного компилятора, математических библиотек (и их расположения), MPI и, возможно, архитектуры системы хранения и сети.
- Загрузить данные для вычислений на нужный путь хранения (который может отличаться от вышеуказанного пути исходного кода).
- Изучить очереди, учетные записи и политики менеджера ресурсов.
- Протестировать и проверить скомпилированное ПО на тестовых данных.
- Отследить выполнение заданий и проверить их работоспособность.
- Проверить выходные данные задания.
- Повторить при необходимости.
- Выгрузить полученные данные для последующей обработки или дальнейшего исследования.
Постоянно растущие издержки использования архитектуры HPC 30-летней давности
Продолжающееся использование устаревшей архитектуры HPC дорого обходится научному сообществу в виде упущенных возможностей, невостребованного эффекта масштаба и теневых затрат на ИТ.
К упущенным возможностям относится то, что многие исследователи и организации не могут использовать устаревшую вычислительную архитектуру HPC и вместо этого вынуждены применять неподдерживаемые, немасштабируемые и непрофессионально обслуживаемые архитектуры. Например, множество исследователей используют в качестве вычислительной инфраструктуры свои ноутбуки.
Другие упущенные возможности включают неспособность приспособиться к современным рабочим нагрузкам, многие из которых недостаточно поддерживаются устаревшей архитектурой HPC. Например, практически невозможно надежно интегрировать традиционную архитектуру системы HPC в конвейеры CI/CD для автоматизированного обучения и аналитики, более простые фронтенды разработки и ресурсов, такие как Jupyter (об этом позже), рабочие места с постоянно растущим разнообразием и мультипремисные, офпремисные и даже облачные ресурсы.
Кроме того, многие предприятия демонстрируют сопротивление унаследованным системным архитектурам типа Beowulf: «Мы больше не хотим, чтобы наши системные администраторы использовали Secure Shell (SSH), а Beowulf требует, чтобы все пользователи использовали SSH для взаимодействия с системой!».
Когда ИТ-командам приходится создавать индивидуальные системы для конкретных нужд и использования (а именно это происходит сейчас во многих научных центрах), они не могут эффективно использовать инвестиции в оборудование, поскольку каждая «система» существует как изолированный пул ресурсов. Мы видим это сейчас, когда центры создают совершенно отдельные системы для вычислительных сервисов и Jupyter с Kubernetes. Невостребованным оказывается эффект масштаба, которого можно было бы достичь, если бы ресурсы HPC должным образом поддерживали все эти сценарии использования.
Более того, в слишком многих случаях исследовательские группы пытаются создавать собственные системы или использовать облачные экземпляры самостоятельно, без привлечения ИТ-служб, поскольку считают, что те не предоставляют им инструменты, необходимые для проведения исследований. Хотя облако упростило некоторые виды вычислений, оно не всегда имеет смысл по сравнению с локальными онпремисными ресурсами или если вы привязаны к одному облачному поставщику.
Эти печальные истины тормозят исследования и научный прогресс.
Намеки на прогресс?
Конечно, появилось несколько вещей, которые немного облегчили работу пользователей HPC. Например, Open OnDemand — это фантастический способ инкапсулировать всю архитектуру Beowulf и предоставить ее пользователю в виде графического интерфейса на основе http (т. е. веб-интерфейса). OnDemand предлагает большую ценность, предоставляя более современный пользовательский интерфейс, чем SSH, но многие пользователи обнаружили, что он не значительно снизил барьер входа, поскольку все равно приходится проделывать все те же шаги, о которых говорилось выше.
Еще одно усовершенствование — блокноты Jupyter Notebooks, которые стали огромным скачком в плане улучшения жизни исследователей и разработчиков. Часто используемый в академических кругах в учебных целях, Jupyter помогает исследователям вести разработку в режиме реального времени и запускать блокноты с помощью более современного интерактивного веб-интерфейса. Благодаря Jupyter мы наконец-то видим, что пользовательский опыт меняется — список шагов упрощается.
Однако Jupyter в целом не совместим с традиционной архитектурой HPC, и, как следствие, его не удалось интегрировать в существующие архитектуры HPC. В реальности ряд традиционных центров HPC с одной стороны запускают свои традиционные системы HPC, а с другой — используют систему Jupyter для работы поверх Kubernetes и инфраструктур, ориентированных на предприятия. Правда, для объединения этих подходов можно использовать Open OnDemand плюс Jupyter, но это усложняет процесс для пользователей — добавляются дополнительные и различные шаги.
Контейнеры ведут к более современному миру HPC
Контейнеры послужили «ящиком Пандоры» (в хорошем смысле!) для мира HPC, продемонстрировав, что существует множество инноваций, появившихся в областях, не связанных с HPC, которые могут быть весьма полезны для сообщества HPC.
Появление контейнеров на предприятиях произошло благодаря Docker и подобным программам, но эти контейнерные реализации требовали привилегированного root-доступа для работы и, таким образом, создавали риски безопасности для систем HPC, позволяя непривилегированным пользователям запускать контейнеры. Именно поэтому была создана первая контейнерная система общего назначения для HPC — Singularity, которая сразу же была принята центрами HPC по всему миру из-за огромного ранее неудовлетворенного спроса. Впоследствии Singularity была передана в Linux Foundation, чтобы гарантировать, что проект всегда будет предназначен для сообщества, развиваться сообществом и свободен от любого корпоративного контроля. В рамках этого перехода проект был переименован в Apptainer.
Apptainer изменил представление людей о воспроизводимых вычислениях. Теперь приложения стали гораздо более переносимыми и многократно используемыми системами, исследователями и инфраструктурами. Контейнеры упростили процесс создания пользовательских приложений для HPC-систем, поскольку теперь их можно легко заключить в контейнер, включающий все зависимости. Контейнеры сыграли важную роль в начале процесса модернизации HPC, но это только первый шаг к тому, чтобы сделать жизнь пользователей HPC лучше. Представьте себе, что будет дальше, когда мы приступим к трансформации HPC и создадим среды HPC следующего поколения.
Что нас ждет?
Пришло время для трансформации вычислений: общая архитектура HPC должна быть модернизирована, чтобы иметь возможность лучше обеспечивать более широкий спектр приложений, рабочих процессов и сценариев использования. Используя преимущества современных инфраструктурных инноваций (облачная архитектура, аппаратные средства, такие как GPU, и т. д.), мы должны создавать системы HPC, поддерживающие не только исторические/унаследованные сценарии использования, но и следующее поколение рабочих нагрузок HPC.
Концепция заключается в том, чтобы предоставить современную гибридную, федеративную инфраструктуру, основанную на облаке, которая позволит запускать кластеры онпремис и мультитмпремис, в облаке и мультиоблаке, даже в нескольких регионах доступности в мультиоблаке.
Гигантская архитектура распределенных вычислений будет сшита вместе единым API, предлагая исследователям полную гибкость в локальности, мобильности, гравитации и безопасности данных. Кроме того, концепция предполагает абстрагирование от всех сложностей работы и минимизацию шагов, связанных с выполнением рабочих процессов HPC.
Цель состоит в том, чтобы обеспечить науке новые возможности благодаря модернизации архитектуры HPC — как для поддержки большего разнообразия задач, так и для снижения барьера входа в HPC для большего числа исследователей, оптимизируя опыт для всех.
