HPC в Windows Azure

Принцип, провозглашаемый для облачной платформы Windows Azure, гласит – "ресурсы и масштабирование для каждого". Этот же самый принцип можно перефразировать, сузив область до специфичной, но, тем не менее, очень необходимой отрасли – "HPC для каждого". Если раньше сборка и развертывание суперкомпьютерных кластеров занимала часто долгое время, большую часть которого занимало планирование, закупка, установка и согласование на различных уровнях, и стоила (и сейчас стоит, если говорить о развертывании локального суперкомпьютерного кластера) больших капитальных расходов, то с приходом концепции облачных вычислений и реализации этой концепции в виде облачных платформ построить свой собственный кластер может практически любой пользователь, имеющий опыт разработки параллельных программ и соответствующие задачи. Стоимость развертывания локального суперкомпьютерного кластера может исчисляться в тысячах долларов только капитальных расходов, потраченных на первичную закупку аппаратных ресурсов и лицензий, в Windows Azure же можно просто включить несколько виртуальных машин и платить несколько сотен долларов в месяц в зависимости от количества и характеристик виртуальных машин. Хотелось бы также заметить, что определенная часть задач, вычисляющихся на суперкомпьютерных кластерах, не считается непрерывно месяцами, что еще более повышает привлекательность облаков для научно-исследовательских задач. У Microsoft существуют программы поддержки научных исследований, в которые входит пакет использования Windows Azure в течение 5 месяцев (https://www.windowsazurepass.com/?campid=8265E8BF-4D2A-E011-BC7C-001F29C6FB82).

Вспомним – в первой части данного курса были приведены основные типы нагрузок, которые могут быть перенесены в облако. Первым из них был сценарий, называвшийся "вкл/выкл", для которого характерна ситуация, в которой в один момент времени необходимо обсчитать какую-либо задачу, будь она научная, технологическая или бизнес.

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

Однако, говоря о том, каким образом платформа Windows Azure помогает в развертывании суперкомпьютерных кластеров, необходимо учитывать, что встроенного в платформу компонента нет. С помощью базовых сервисов платформы (Virtual Machines, Virtual Networks, Cloud Services) любой пользователь может быстро развернуть необходимое количество ресурсов и объединить их в кластер.

Цель этого –обеспечение масштабирования от нуля до виртуально бесконечности. Разумеется, что для максимальной производительности вычислений необходимо, чтобы ресурсы располагались как можно географически ближе, но бесконечных ресурсов в одном месте не бывает, по этому причине бесконечность можно назвать виртуальной – в любом случае, если даже ресурсы в одном месте кончатся, можно объединить развертывание с другим и расширить доступную емкость ресурсов. В этом контексте очевидно преимущество облака над локальными инфраструктурами – если имеется задача, для которой необходимо большое количество ресурсов, то в случае локальной инфраструктуры возникает очень простая проблема, в своей серьезности, тем не менее, обычно занимающая очень важное место - нехватка этих вычислительных ресурсов – и разработчик может либо дождаться, пока пул доступных ресурсов расширится (чего может не произойти по ряду причин), либо ограничиться доступными мощностями, что может разительно повлиять на скорость того, с какой будут получены, возможно, очень важные данные. С облаком исследователь не зависит от человеческого и организационного факторов – в любой момент он может добавить вычислительные узлы к своему личному суперкомпьютерному кластеру, и, произведя необходимые вычисления, отказаться от лишних ресурсов и перестать их оплачивать. Но при этом необходимо четко понимать, что Windows Azure – платформа, предоставляющая высокую гранулярность модели оплаты, и учитывать, что пользователи, во-первых, оплачивают часы вычислений для экземпляра почасово, при этом цена зависит от размера экземпляров – от одного до восьми ядер и других характеристик, например, оперативной памяти.

Рассмотрим сценарии, в которых облако не может являться полной заменой локальной инфраструктуры. Например, в организации уже есть локальный суперкомпьютерный кластер, у которого просто не хватает небольшого количества ресурсов. В этом случае развертывание суперкомпьютерного кластера аналогичной мощности (с недостающими ресурсами) в облаке ради разницы в один-два вычислительных узла – это, конечно же, неэффективный способ использования уже существующих закупленных и поддерживаемых вычислительных ресурсов. Microsoft в рамках платформы Windows Azure предлагает возможность создания гибридной инфраструктуры, когда пользователь может подсоединить на головном узле своего локального кластера вычислительные узлы, находящиеся в облаке.

Здесь могут возникнуть вопросы о производительности подобного рода решений, прежде всего в вопросах сетевого подключения – есть проблема задержек (latency), типичная для географически удаленных решений. В этом случае можно использовать, например, кэширование либо разделение данных для обработки между локальной и облачной инфраструктурами таким образом, чтобы облачные узлы не обращались к данным, расположенным локально, и наоборот. Пользователь же отправляет задачу также, как он отправлял и раньше, но вычислительные узлы, например, на половину своей общей емкости располагаются в Azure. В этом случае инфраструктура включает в себя вычислительные узлы и головной узел, расположенные локально, и узлы в Azure, осуществляющие дополнительную помощь в расчетах. При этом для пользователя нет никакой разницы в расчетах – от него скрыта реализация, что узлы, вычисляющие его задачу, могут быть расположены в географически очень удаленном месте. Для инфраструктурного специалиста же есть некоторые особенности реализации – если строится гибридная инфраструктура, то администратору необходимо иметь подписку Windows Azure и базовые навыки управления облачной инфраструктурой. Весь остальной опыт остается тем же самым, что и при использовании локального кластера. Надо сказать, однако, что узлы в Azure не создаются по требованию, когда посылается задача – администратор явным образом выделяет ресурсы для них, затем выключает тогда, когда они более не нужны. Он может это делать как вручную, например, в HPC Cluster Manager, либо с помощью скрипта Powershell, автоматизируя эти задачи. Аналогичным образом происходит создание, расширение и управление кластером на основе Linux – в этом случае опыт администратора и пользователя аналогичен тому, который они имеют с локальным развертыванием.

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

Но, если имеет смысл размещать несколько узлов в Windows Azure, имеет ли смысл размещать суперкомпьютерный кластер в облаке целиком? Windows HPC Server поддерживает подобный тип развертывания, который может предполагать, что головной узел кластера, с которого производится управление и использование кластера, расположен в облаке либо локально. Выбор между двумя типами развертывания (головной узел локально и головной узел в облаке) может производиться согласно исходной задаче – например, в проекте кластера есть условие, что головной узел должен быть расположен в локальной инфраструктуре и, таким образом, опыт конечных пользователей по его использованию должен быть аналогичным тому, как если бы они использовали полностью локальный кластер.

Подобное развертывание, вне зависимости от того, где расположен головной узел (так как чаще всего он всё-таки не принимает участия в непосредственных расчётах), нивелирует один из серьезных недостатков гибридной инфраструктуры, значительно упрощая доступ к данным, так как в этом случае общий массив данных не должен быть разделен на две части, будучи полностью хранимым в хранилище Windows Azure. При этом, если в гибридной инфраструктуре могут возникать вопросы, связанные с организационной частью, например, соглашений об уровне обслуживания для гибридной инфраструктуры, то в случае облачного развертывания имеет место быть описание только тех соглашений, которые предоставляется Microsoft.

Таким образом, на сегодняшний момент Windows HPC Server поддерживает три типа вычислительных узлов:

Инструментарий Windows (Azure) HPC Server

Одной из особенностей высокопроизводительных вычислений является то, что приложение должно быть разбито на несколько частей, после чего эти части должны быть маршрутизированы на обработку на несколько обработчиков согласно какой-то логике, часто задаваемой разработчиком или пользователем. Для того, чтобы упростить этот процесс, в Windows HPC Server существует специальный компонент, называемый HPC Job Scheduler. HPC Job Scheduler работает на головном узле и служит тем инструментом, который осуществляет планирование, управление состоянием, отправку и распределение задач по доступным и/или выделенным вычислительным узлам.

Используя собственную программную инфраструктуру, Windows HPC Server может выполнять несколько типов приложений – приложения, которые запускаются на нескольких узлах кластера и выполняются, общаясь по возможности между собой – так называемые MPI-приложения, Message Passing Interface, сценарии использования которых типичны для науки – например, моделирование физических процессов или ядерных реакций, приложения, которые выполняются в параллели, но не общаются между собой – так называемые embarrassingly parallel applications, типичные сценарии которых включают, например, финансовые расчеты, и Excel-приложения, которые могут служить для задачи выгрузки задачи по расчетам в кластер, таким образом значительно ускоряя вычисления, которые могли бы выполняться гораздо дольше на одном компьютере (подробнее о том, что такое MPI и как разрабатывать параллельные приложения, можно прочитать на сайте Parallel.ru: http://parallel.ru/tech)

Что касается управления приложениями на кластере, то это зачастую непростая задача – например, администратор должен создать кластер, после чего определить множество настроек, например, самой простой из которых является то, какие вычислительные узлы выделены под расчеты, то есть находятся в статусе онлайн. Кроме этого, есть более сложные с позиции планирования настройки – например, управление так называемыми сетами и ассоциированными с ними вычислительными узлами. Для упрощения этих задач в Windows Azure HPC Server внедрен HPC Cluster Manager, который можно использовать для различных задач – управления состоянием узлов кластера, задач, запущенных на кластере, запуском диагностических тестов, созданием графиков и отчетов о кластере, отчетов о загрузке каждого из узлов. При этом, учитывая упомянутую ранее возможность использовать десктопные станции, локальные сервера и узлы в облаке, HPC Cluster Manager предоставляет ко всей развернутой инфраструктуре единый унифицированный интерфейс управления.

Перед тем, как начнется процесс развертывания вычислительных узлов в облако Windows Azure, разработчик должен настроить облачный сервис (Cloud Service), в котором будут храниться узлы, путем создания сервисной модели (подробнее сервисная модель описывается в соответствующем модуле). Важным компонентом, используемым в разработке и развертывании суперкомпьютерных кластеров в облаке Windows Azure, является Windows Azure HPC Scheduler SDK, который включает в себя инструменты разработки и набор плагинов, которые могут быть импортированы в конфигурационном файле ServiceDefinition.csdef. На основе этих плагинов строится такая функциональность кластера, как планировка задач, поддержка параллельных задач и т.д. Например, в типичном проекте развертывания могут быть импортированы следующие плагины:

Плагин головного узла (Head Node): этот плагин является отображением Worker-роли облачного сервиса с добавленным плагином HpcHeadNode. Предоставляет планировку и управление состоянием задач.

Плагин вычислительного узла (Compute node): этот плагин является отображением Worker-роли облачного сервиса с добавленным плагином HpcComputeNode. Предоставляет поддержку MPI и SOA, а также связь со средствами управления, предоставляемыми плагином HpcHeadNode.

Плагин веб-интерфейса (Front end): плагин используется как Web-роль облачного сервиса с добавленным плагином HpcWebFrontEnd. Предоставляет веб-портал в качестве веб-сервиса для прямого управления состоянием задач пользователями.

Справочник:

Embarrassingly Parallel Applications – логика подобных приложений выполняется в нескольких экземплярах на нескольких серверах в изолированном режиме – для экземпляров, несмотря на то, что они выполняются параллельно, нет необходимости взаимодействовать после запуска задачи. Типов подобных задач в Windows HPC Server два: приложения, использующие сервисо-ориентированную архитектуру (SOA) и приложения, работающие в режиме Parametric sweep (то есть одно запускаемое много раз приложение с различным набором данных и/или аргументов). Приложения SOA реализуются с помощью Windows Communication Foundation (WCF), что позволяет пользователю взаимодействовать с этими сервисами с помощью SOAP или REST. Разработка приложений SOA часто требует глубоких соответствующих знаний, разработка же приложений parametric sweep может быть более доступна исследователям и разработчикам, не владеющим навыками создания веб-сервисов.

MPI – если в случае embarrassingly parallel applications каждый выполняющийся экземпляр приложения работает изолированно от других, то написание приложений с использованием парадигмы MPI (Message Passing Interface) подразумевает часто глубокую интеграцию и взаимодействие между выполняющимися экземплярами. MPI-приложения могут использовать в качестве коммуникационной инфраструктуры высокоскоростную сеть Infiniband.

Excel – начиная с 2010 версии, Excel поддерживает запуск workbooks на суперкомпьютерном кластере под управлением Windows HPC Server. Использование Excel может быть в режиме клиента для задачи SOA – с использованием Visual Studio Tools for Office, разработчик может реализовать подобный сценарий; и с использованием Excel UDF, которые позволяют создать собственный код, который может быть вызван из ячеек рабочего листа. Кроме этих двух подходов может быть использован еще один, когда на нескольких вычислительных узлах кластера разворачивается соответствующее количество экземпляров Excel, и все развернутые экземпляры параллельно просчитывают различные данные из одного workbook.

Говоря о развертывании суперкомпьютерных кластеров в облаке Windows Azure, нельзя обойти вниманием важное событие, произошедшее в 2012 году – корпорация Microsoft развернула кластер под названием Faenov полностью в облаке Windows Azure, который затем занял 165 место в ТОР500 мощнейших суперкомпьютеров в мире. Это, а также возможность в любой момент дополнить вычислительную емкость суперкомпьютерного кластера любым количеством вычислительных узлов, делает Windows Azure потенциально важным игроком на рынке суперкомпьютерных вычислений.

К ресурсам, доступным для исследователей, преподавателей и учёных, следует отнести бесплатный академический доступ – после заполнения специальной заявки пользователь может получить полугодовой доступ к большому количеству вычислительных ресурсов, которых при правильном планировании может хватить как на тестовые развертывания, так и на некоторые небольшие исследовательские проекты.

Заключение

Как и в случае с Hadoop и Big Data, High Performance Computing получает при переходе в облако большие преимущества практически неограниченных ресурсов, удобной управляемости и оплаты по факту использования и ухода от капитальных затрат. Однако переход в облако может означать также загрузку больших массивов данных в облако или, если речь идет о гибридной инфраструктуре, размещении части данных в облаке, части локально, что может привести к высоким показателям латентности при работе. Поэтому необходимо четко планировать, какая из опций может быть наиболее эффективна в случае с переходом в облако.