Суперкомпьютер из облака

Многие годы суперкомпьютеры использовались лишь для решения задач численного моделирования, однако сегодня стали актуальны другие задачи — например, обработка огромных объемов накопленных экспериментальных данных, требующая новых методов анализа. Могут ли при анализе Больших Данных соответствующим образом организованные облачные ресурсы составить конкуренцию традиционным суперкомпьютерам? Применимы ли вообще облака длявысокопроизводительных вычислений (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, основная часть приложений которого относится к категории слабосвязанных — они вполне могут выполняться в облачных средах, причем с большей экономической эффективностью, чем при использовании суперкомпьютеров.

Литература

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) — независимый автор (Москва).