Многие годы суперкомпьютеры использовались лишь для решения задач численного моделирования, однако сегодня стали актуальны другие задачи — например, обработка огромных объемов накопленных экспериментальных данных, требующая новых методов анализа. Могут ли при анализе Больших Данных соответствующим образом организованные облачные ресурсы составить конкуренцию традиционным суперкомпьютерам? Применимы ли вообще облака длявысокопроизводительных вычислений (High Performance Computing, HPC)? Сегодня часто можно встретить такую постановку вопроса [1], однако простое «лобовое» противопоставление одного другому, вызванное желанием получить побольше и подешевле, лишено смысла. Для целого ряда приложений нельзя заменить специализированные машины сборками из универсальных облачных модулей, объединенных универсальным интерконнектом, однако есть немало приложений, для которых использование облаков оправданно. Как следствие, появились специализированные облака, рассчитанные на высокопроизводительные вычисления.

Cycle Computing

Теме «Облака и HPC» сегодня посвящен целый ряд конференций. В частности, ISC Cloud, прошедшая под девизом «Высокопроизводительные вычисления и производство встречают облака», включала, например, выступление Джейсона Стоува, основателя небольшой компании Cycle Computing, которая удивила специалистов показателями своих облачных решений, обошла конкурентов (включая Microsoft) и всколыхнула рынок, объявив в 2010 году инициативу Big Compute on Windows Azure. Компания Cycle Computing не строит собственных ЦОД, ограничиваясь разработкой ПО и методов управления и обеспечения безопасности для создания рекордных по своим параметрам кластерных конфигураций в облаке Amazon EC2. Еще в 2011 году компания собрала кластер из 10 тыс. ядер, затем — из 30 472, а в 2012 году была достигнута конфигурация в 50 000 ядер. Все эти системы просуществовали несколько часов — ровно то время, которое было необходимо для решения конкретной задачи, однако по своим показателям они вполне могут претендовать не на последние места в Top500.

Идеология Cycle Computing не нова и берет начало от системы гридов Condor [2], которая cейчас входит в дистрибутив Red Hat Enterprise Linux 6 под именем HTCondor, а также является компонентом Globus Toolkit, используемого для построения инфраструктур гридов. Гриды как средство использования «спящих» компьютеров были предложены в середине 90-х годов, существуют они и поныне, причем вычислительная мощность некоторых из них уже перевалила за петафлопсный рубеж, но тем не менее они по-прежнему имеют ограниченное применение. В осознании этого факта Джейсон Стоув сделал вполне логичный шаг, отказавшись от географически распределенных компьютеров, образующих грид, в пользу облачной среды, где есть те же неограниченные процессорные ресурсы, но связь между ними более эффективна и, следовательно, область применения намного шире. С этой идеей он в 2005 году создал компанию, первый продукт которой — CycleServe — обеспечивал криптозащиту в гриде, а в следующем — CycleCloud — был сделан логичный шаг по переносу вычислительной нагрузки в облака EC2 от Amazon и Rackspace Cloud от Rackspace. Таким образом трансформировалась первоначальная идея гридов — так называть временный ресурс, собранный в облаке, гораздо логичнее, чем тем же словом называть обычные кластеры, как это продолжает делать Oracle.

Успеху Cycle Computing поспособствовала удачная встреча Стоува с биотехнологической компанией Genentech, которой требовалось решить всего одну задачу моделирования белков. Ясно, что ради этой временной цели не стоило приобретать собственный компьютер — лучше использовать облако, однако специалисты этой компании не хотели прибегать к готовым возможностям инфраструктуры Amazon Virtual Private Cloud и поручили организацию вычислений Cycle Computing, с тем чтобы она использовала стандартные возможности Amazon EC2. Временная конфигурация, получившая название Tanuki, состояла из 1254 физических серверов, установленных в одном из ЦОД Amazon, каждый поддерживал работу восьми ядер, то есть всего было задействовано 10 014 ядер, 8,6 Тбайт суммарной памяти и 2 Пбайт дискового пространства. Tanuki работала под управлением CentOS 5.4, версии Red Hat Enterprise Linux. На загрузку CycleCloud и CycleServer ушло около часа, сама задача решалась 8 часов, а общая стоимость аренды оборудования не превысила 9 тыс. долл. Производительность Tanuki была оценена примерно в 80 TFLOPS, что ставило ее примерно на 114-е место в актуальном на тот момент Top500. Следующая попытка была названа Nekomata — конфигурация состояла из 3809 восьмиядерных серверов, расположенных в трех географически удаленных ЦОД (Калифорния, Северная Вирджиния и Ирландия), а коммуникации были защищены по AES-256. Производительность Nekomata составила 200 TFLOPS — начало третьего десятка Top500. Последняя, третья конфигурация — Naga, созданная в июне 2012 года для биологических исследований, стала сенсацией и оказалась в центре внимания всей деловой и компьютерной прессы. В этот раз 6742 сервера Amazon EC2 с 51 132 ядрами и 29 Тбайт памяти были размещены в семи ЦОД Америки, Европы, Сингапура и Японии. На решение задачи молекулярного моделирования ушло три часа при стоимости около 5 тыс. долл. за час. Годом позже Cycle Computing дополнила продуктовую линейку средством для управления данными DataManager, призванным компенсировать врожденные недостатки кластеров по обеспечению эластичности данных, готовности, безопасности и (что, возможно, самое главное) уменьшению задержек.

Облака и нагрузки

С ростом популярности облаков и появлением примеров HPC-конфигураций возникает оправданное желание понять, насколько облачные подходы применимы к решению научных задач и могут ли облака составить конкуренцию суперкомьютерам. К основным свойствам, которые стремятся придать облакам, относятся: мгновенная готовность, неограниченная емкость ресурсов, большой выбор ПО и, главное, виртуализация. Основные свойства суперкомпьютеров иные: минимум виртуализации, максимальное использование возможностей оборудования, которое настроено на скорость счета. Общим качеством является высокая способность к масштабированию: задача может получить столько мощности, сколько ей требуется — но технологии обеспечения масштабирования принципиально разные. Однако самое главное различие — интерконнект: по определению скорость обмена между узлами суперкомпьютера будет всегда выше, чем между узлами облака. По этой причине работе в последних будет соответствовать нагрузка с естественным параллелизмом, составляющая сейчас от 5 до 10% всего объема задач, решаемых на суперкомпьютерах, но в будущем этот показатель будет расти за счет увеличения доли слабосвязанных приложений.

Все приложения научного характера можно условно разделить на две категории: сильно- и слабосвязанные. Большая часть научных задач относится к сильносвязанным приложениям, требующим интенсивного обмена данными между узлами. Эффективность суперкомпьютеров определяется величиной задержки, отсюда и стремление их разработчиков к совершенствованию межсоединения, а также появление разных архитектур от простых кластеров до высокопродуктивных систем с общей памятью. Но есть и другие задачи, в которых потребность в обменах между узлами существенно меньше, — это задачи категории High Throughput Computing. Для них характерна большая нагрузка, а время решения не является значимым фактором. Для HTC достаточно слабосвязанных гридов. Термин High Throughput Computing был предложен в 1997 году Мироном Ливни в рамках программы Condor для выделения класса задач, где количество агрегированных ресурсов важнее времени решения.

Отец гридов Ян Фостер [3] предложил собственную классификацию нагрузок (см. рисунок), которая на первый взгляд очевидна, но авторы шли к ней, анализируя разного рода приложения из астрофизики, биоинформатики, разработки данных и других областей науки. Этот анализ показал, что двумя классами, HPC и HTC, все многообразие научных задач не исчерпывается, поэтому была предложена еще одна категория — многозадачные вычислительные системы (Many Tasks Computing, MTC), занимающая промежуточное положение между HPC и HTC. Таким образом Фостер поместил в самостоятельную категорию тип вычислений, которые строятся из множества отдельных действий, связанных по данным посредством файловой системы или системы обмена сообщениями. Действия могут быть разными — большими или небольшими, использующими ресурсы одного или многих процессоров, ориентированными на данные (data-intensive) или на счет (compute-intensive).

 

Задачи и данные мира высокопроизводительных вычислений
Задачи и данные мира высокопроизводительных вычислений

 

MTC отличается от HTC количеством времени, требуемого для выполнения задач, и интенсивностью потоков данных, поэтому здесь используются показатели из HPC, такие как FLOPS, скорости передачи данных и т. п., а не количество задач, которое можно решить за месяц. В этом смысле MTC ближе к HPC, но отличается слабой связанностью и, следовательно, может работать на гридоподобных конфигурациях, в том числе и на облачных. Такого рода задач в науке немало, и для них облака вполне могут оказаться достойной альтернативой кластерам, что, собственно, успешно доказала Cycle Computing.

***

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

 

Провайдеры научных облаков

Сегодня ряд компаний — в первую очередь Penguin, R-HPC, Amazon, Univa, SGI, Sabalcore и Gompute — предоставляют технологии и сервисы высокопроизводительных вычислений в облаке.

Компания Penguin Computing одной из первых предложила специализированное HPC-облако Penguin On-Demand HPC Cloud Service (POD), вычислительные узлы которого строятся на сдвоенных четырех или шестиядерных процессорах Xeon или на двенадцатиядерном процессоре AMD, работающих на частотах от 2,2 ГГц до 2,9 ГГц, оснащаются памятью от 24 Гбайт до128 Гбайт и локальной системой хранения до 1 Тбайт. Из узлов может набираться требуемая конфигурация с возможностью подключения двух графических процессоров Nvidia Tesla C2075 с 448 ядрами при скорости обмена по шине 144 Гбайт/с. Для управления служит сдвоенный четырехъядерный процессор Xeon Nehalem. В сеть POD процессоры объединены по 10-Gigabit Ethernet или Infiniband. Облако POD поддерживает более 150 готовых к использованию приложений (коммерческих или открытых), таких как ANSYS, Matlab, BLAS, компилятор Nvidia CUDA, а если их недостаточно, то можно воспользоваться инструментарием PODTools, включающим набор утилит для доступа в HPC-облако.

Компания R-HPC предлагает в аренду свое облако R-Cloud в двух версиях. Shared Cluster, как следует из названия, это классический кластер с распределяемыми ресурсами и оплатой услуг HPC по принципу pay-as-you go, без каких-либо дополнительных услуг по развертыванию и администрированию со стороны провайдера. Вторая версия представляет собой виртуализированный кластер с доступом по виртуальной локальной сети (VLAN). R-HPC использует серверы на четырехъядерных процессорах Sandy Bridge c памятью 4 Гбайт на узел, межсоединением InfiniBand и терабайтным локальным диском. Как опция могут быть использованы восьмиядерные процессоры с удвоенным объемом памяти на ядро и более быстрым QDR Infiniband. Графические процессоры пока используются в режиме бета-тестирования. По утверждению компании, для настройки и запуска приложений обычно хватает одного дня. Дополнительно можно задействовать файловую систему Lustre и скоростную систему хранения Kove XPD.

Облако Amazon EC2 известно давно, но изначально оно не было адаптировано к высокопроизводительным вычислениям, поэтому первые попытки использовать его в этом качестве давали негативный результат, что в известной мере определило общее прохладное отношения к облакам в роли платформы для HPC. Однако появление двух типов узлов Cluster Compute, имевших более мощный процессор и сеть 10 Гбит Ethernet, изменило положение. Такие узлы различаются по используемым в них процессорам; в варианте Quadruple Extra Large Instance есть процессор Nehalem с восемью ядрами, 23 Гбайт памяти и локальный диск на 1,7 Тбайт, а в Eight Extra Large Instance — процессор Sandy Bridge с шестнадцатью ядрами, 5 Гбайт памяти и 3,4-терабайтный локальный диск. Плюс к этому имеется Cluster GPU с двумя процессорами NVidia Tesla Fermi M2050.

Компанию Univa образовали Карл Кессельман и Ян Фостер, а в 2011 году в команду вошли бывшие сотрудники Sun Microsystems, участвовавшие в известном проекте Sun Grid Engine. Продукт компании — UniCloud — относится к классу IaaS и служит для создания локальной инфраструктуры облака с применением гипервизоров VMware, KVM или Xen, а в некоторых случаях и OpenStack или VMware vSphere. В UniCloud используется уровень IaaS для создания необходимых конфигураций «на лету».

Облако Cyclone, созданное в SGI, возможно, наиболее производительное, поскольку помимо межсоединения Infiniband в нем используется межсоединение SGI NUMAlink, что позволяет собирать не только традиционные кластерные архитектуры, но и многомерные торы, толстые деревья и другие. Облако Cyclone ориентировано на задачи вычислительной биологии, вычислительной химии, материаловедения, вычислительной газовой динамики и др. В связи с этим в нем реализованы оба метода масштабирования — и вертикальное, и горизонтальное. При использовании NUMAlink общая разделяемая оперативная память узлов варьируется в пределах 0,5–2 Тбайт. Близкие по смыслу сервисы предоставляет также компания Bull.

 

Литература

  1. Леонид Черняк. HPC в облаках // Открытые системы.СУБД. — 2011. — № 7. — С. 48–50. URL: http://www.osp.ru/os/2011/07/13010494 (дата обращения 20.10.2014).
  2. Дмитрий Владимиров. Кластерная система Condor // Открытые системы.СУБД. — 2000. — № 7–8. — С. 20–26. URL: http://www.osp.ru/os/2000/07-08/178077 (дата обращения 20.10.2014).
  3. Ян Фостер, Карл Кессельман, Джеффри Ник, Стивен Тьюке. Grid-службы для интеграции распределенных систем // Открытые системы.СУБД. — 2003. — № 1. — С. 20–26. URL: http://www.osp.ru/os/2003/01/182393 (дата обращения 20.10.2014).

Леонид Черняк (osmag@osp.ru) — независимый автор (Москва).

Поделитесь материалом с коллегами и друзьями

Купить номер с этой статьей в PDF