HPC в Windows Azure

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

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

увеличить изображение
Рис. 17.1. Сценарии использования облака

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

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

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

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

Рис. 17.2. Гибридная инфраструктура

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

увеличить изображение
Рис. 17.3. Интерфейс HPC Pack 2012 Cluster Manager

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

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

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

Рис. 17.4. Миграция вычислительного кластера в Windows Azure

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

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

• Рабочие пользовательские станции под управлением Windows 7.
• Локальные серверные станции под управлением Windows HPC Server 2008 и Windows HPC Server 2008 R2.
• Вычислительные узлы (виртуальные машины), расположенные в Windows Azure (выступающие в виде ролей в Cloud Service).