Технология Клиент-Сервер 2005'2

Home Поиск Издания Контакты k-press.ru


Продолжается подписка на наши издания! Вы не забыли подписаться?

Системы кластерных высокопроизводительных вычислений на базе Windows Server 2003

Авторы: Кирилл Фаенов
презентация на .Net User Group
Москва
декабрь 2004
Опубликовано: 28.02.2006

В 2004 году в Microsoft была создана группа для разработки систем кластерных высокопроизводительных вычислений на базе Windows Server 2003. Здесь я постараюсь рассказать, почему мы серьезно занялись этим направлением, и как мы собираемся его развивать, а также показать технические детали первой версии и технологий, на которых будет основана эта версия.

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

Что заставило Microsoft заняться этой, не слишком характерной для нее, областью? Традиционно эта область всегда называлась "рынком размером 0 миллиардов долларов" – несмотря на размах проблем, эти решения поддерживаются только ограниченным количеством лабораторий, в основном финансируемых государственными учреждениями. Большого рынка, нужного для того, чтобы окупить гигантские вложения, необходимые для развития этих компьютеров, до сих пор не было.

В конце 90-х годов произошло нечто, казалось бы, довольно страшное, но в конце концов оказавшееся очень полезным. После окончания холодной войны в Америке упало финансирование государственных проектов разработки суперкомпьютеров, поскольку существенно снизилась потребность в моделировании ядерного оружия. Это вымело с рынка практически все компании суперкомпьютеров. Осталась единственная компания – это Terra, в которую переименовал себя Cray, и она сейчас находится в маленьком здании в Сиэтле... Но вот что интересно – в 95-м году начались разработки замены суперкомпьютеров сетями обыкновенных серверов – так называемая программа Beowolf, которая была крайне популяризирована группой из НАСА и Калтека. С начала 2000 года количество кластеров росло экспоненциально. Сейчас в списке самых быстрых суперкомпьютеров в мире уже больше кластеров, чем собственно суперкомпьютеров – их уже более 300. Возможно, через пару лет не останется ни одного (или может быть, один-два) специально созданного суперкомпьютера - все они будут кластерами из обычных серверов.

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

Таким образом, скорость высокопроизводительных систем постоянно увеличивается, причем быстрее, чем скорость одиночных процессоров, потому что здесь речь идет о стыковке многопроцессорных систем. Развитие скорости этих систем происходит гораздо быстрее, чем по закону Мура. Сейчас отчетливо прослеживаются три тенденции, благодаря которым высокопроизводительные системы начинают влиять на промышленность. Три тенденции – это:

В конце концов, стало довольно понятно, как правильно собирать такие системы.

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

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

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

Эти соображения приводят к изменению представлений о том, как производятся высокопроизводительные вычисления. Чего ждать в будущем? Раньше под суперкомпьютером в основном имелись в виду мэйнфреймы, синхронизированные системы. Время доступа к этим системам было разделено. Если потребители посылали задачи на эти суперкомпьютеры, обратно они их получали через неделю, в лучшем случае – через несколько дней. Теперь же, вследствие снижения цен на суперкомпьютеры и облегчения возможности их устройства, становится возможным выделить персональный суперкомпьютер каждому испытателю. Это изменяет способ работы. Работа становится не просто отсылкой информации с последующим получением результатов, а постоянным, в реальном времени, взаимодействием с моделью или с данными. Обработка, визуализация, изменение данных могут проводиться теперь пакетом, который исполняется на настольном компьютере. Представьте себе, что у вас имеется довольно сложная модель в Excel, и эту модель вы хотите или увеличить в 10 раз, или рассчитать гораздо быстрее. Это удастся, если этот Excel, работающий на вашем экране, сможет найти и задействовать кластер, принадлежащий либо вам, либо вашей организации. При этом способ взаимодействия с системой не изменяется. Сегодня существует ряд таких пакетов: Excel, MathLab и т.д.

И третий интересный момент – становится интересным связывать программы и модели в более сложные системы. Например, по двумерным сканам человеческого тела определяется трехмерная модель, например, сердца. Хирург может в реальном времени симулировать хирургию, изменяющую ткани сердца, и просчитать, как эти изменения будет воздействовать на течение крови. Чтобы сделать это, нужно в реальном времени состыковать несколько моделей. Для этого нужны не только возможность состыковать эти модели и их одновременное наличие на разных системах, но и обмен данными. Именно обмен данными становится одной из самых важных задач. Сегодня все программы, которые используются в высокопроизводительных вычислениях, используют собственные форматы хранения данных. Это делает стыковку программ невозможной. Большую пользу в этой сфере могут принести и принесут технологии Web-сервисов и XML, которые сегодня используются для стыковки бизнес-программ.

Что мы строим и что существует сегодня

Чтобы построить компьютерный кластер, нужно состыковать несколько узлов. Каждый из узлов состоит обычно из пары процессоров, на сегодняшний день – 32-битных (появляются уже и 64-битные), которые связаны между собой довольно быстрыми сетями, 100 Мбит, 1 Гбит или еще более быстрыми, как например, InfiniBand. Кроме высокой (до 10 Гбит) скорости передачи данных, для них характерна возможность передачи информации прямо от программы, исполняющейся на одном из узлов, в память программы, исполняющейся на другом узле, без передачи данных в ядро ОС. Эта технология прямого доступа в память другого компьютера называется Remote Direct Memory Access (RDMA). Реально это позволяет в десятки или сотни раз снизить время пересылки маленького количества информации на другой компьютер – а это важно для синхронизации программ. Например, если программа разбивается на несколько кусков, они, каждый сам по себе, начинают обрабатывать данные. В какой-то момент их нужно синхронизировать. Исключительно важно, чтобы это происходило как можно быстрее. Тут важен не объем информации, которую можно передать, не гигабиты и мегабиты, а скорость, с которой происходит эта синхронизация.

До настоящего времени созданием кластеров на платформе Windows занимались компании-партнеры. Существовали системы, обеспечивающие распараллеливание вычислений и обмен информацией между параллельными процессами. Одним из самых популярных пакетов оказался MPI, причем существовало несколько версий MPI для Windows. Кроме того, существовали системы распределения ресурсов в кластере и системы для установки и эксплуатации этих кластеров. Однако поддержка этих систем оставляла желать лучшего. Мы постоянно слышали от своих клиентов, что Microsoft пора заняться этим делом и создать унифицированную систему. И мы этим действительно занялись.

Сегодня наши технологии используются практически во всех областях, включая финансы и нефтяную промышленность, где создан один из самых больших Windows-кластеров, включающий более 17000 узлов. Можно привести примеры использования Windows-кластеров в кинематографии и анимации. Малоизвестный факт – спецэффекты фильма «Матрица» просчитывались на кластере из 2000 Windows-серверов.

К концу 2005 года мы планируем выпустить первую версию разрабатываемой нами системы. Она должна позволить уже существующим приложениям использовать кластеры. Вторая версия должна выйти в начале 2007 года. В ней должны появиться средства, облегчающие разработку параллельных программ с использованием .NET. Эта версия будет включать новую систему компиляторов, предоставляющую возможность построения параллельных программ с помощью managed-кода, а также использования MPI для managed-кода. Новые компиляторы (они войдут в версию Visual Studio, которая выйдет вслед за VS 2005) позволят оптимизировать программу под процессор, на котором она будет исполняться. Это становится возможным потому, что managed-код может содержать дополнительную информацию, которая будет использована при JIT-компиляции.

Другая разработка нашей группы – использование кластером ресурсов рабочих станций, которые по ночам бездействуют. Кроме того, ведутся работы по автоматическому конфигурированию больших баз данных, и программам, которые будут производить расчеты над этими БД в кластерах, или используя вычислительные ресурсы, расположенные как можно ближе к этим данным. В сегодняшних разговорах о grid в основном не принимается во внимание то, что самый главный ресурс – это не процессор. Самый главный ресурс – это данные и скорость их передачи. Например, если ваша компания находится в Нью-Йорке, станции, расположенные в Лондоне, ничем не смогут помочь в обработке данных - ведь при этом придется перекачивать по сети терабайты информации. Гораздо дешевле купить и установить системы рядом с собой.

В третьей версии основной упор будет сделан на новые языки программирования. Это очень перспективная область, поскольку сейчас все языки программирования в основном сфокусированы на облегчении работы с большими объектами в памяти. В них нет средств, реально облегчающих координацию работы различных частей программы, исполняющихся на разных процессорах.

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

Еще одно направление наших усилий – это SDM, модель описания программ. В перспективе эта модель позволит описывать параллельные программы, автоматически их устанавливать и главное, изменять количество ресурсов, выделенных этим программам, уже после того, как они запущены. Допустим, что выполнение некоторой задачи занимает неделю. Если в это время потребуется запустить еще одну задачу, придется отнять часть ресурсов у программы, запущенной ранее. Для этого нужна возможность динамического управления ресурсами, выделяемыми задачам.

Более спекулятивной областью является использование специализированных процессоров, существующих в системе – например, графических процессоров, которые способны выполнять огромные объемы параллельных вычислений. Эти процессоры обычно просчитывают довольно сложную комбинацию плавающих чисел для каждого из пикселов на экране. Многим задачам достаточно было бы этих возможностей для параллельной обработки большого количества информации. Этот ресурс сегодня не задействован.

Несколько слов об архитектуре кластеров. Кластер состоит из основного узла, занимающегося распределением ресурсов кластера, и некоторого количества вычислительных узлов. Мы ориентируемся на размер кластера, не превышающий 64 узлов. Практика показывает, что чаще всего создаются кластеры именно такого размера. Конечно, такой кластер не будет одним из самых быстрых в мире, но реально сегодня покупаются именно такие кластеры – от 8-16 до 64 узлов. На узлах и на центральном сервере будет использоваться обычная версия Windows Server 2003, рассчитанная на работу с 64-битными процессорами (она должна выйти в 2005 году). Мы рассчитываем, что при создании кластеров будут использоваться процессоры Intel Xeon, Opteron или, в случае больших кластеров, Itanium.

Более подробного разговора заслуживает MPI. Это система, позволяющая запускать части параллельных программ на выделенных для них узлах, и обмениваться информацией в ходе расчетов. Одной из его частей является сервис Load Manager, чья задача – информировать центральный узел о ресурсах, которые узел может предоставлять кластеру: количестве процессоров, их скорости, количество памяти. Кроме того, этот сервис принимает от центрального распределителя команды запуска параллельных программ. На центральном узле кластера будет находиться версия SQL Server под названием MFD, которая будет хранить информацию о ресурсах кластера и поступающих задачах. Это позволит использовать Cluster Server (это другая технология, которая в случае потери одного из узлов может перекинуть операцию на другой узел).

Эксплуатация такого кластера зависит от наличия центрального узла – если он выходит из строя, теряется доступ ко всему кластеру. Для повышения надежности можно дублировать центральный узел кластера. Благодаря использованию SQL Server и технологии копирования информации, имеющимся уже сегодня, можно автоматически переключаться на резервную копию при отказе центрального узла. Для определения доступа к ресурсам кластера планируется использовать технологию Active Directory. Для авторизации доступа к данным будет использоваться система Cerberos, используемая в Active Directory.

Рассмотрим порядок исполнения задачи на кластере. Сначала резервируются ресурсы. Клиент сообщает, сколько ресурсов нужно для исполнения задачи, и на какое время. Например: "Мне нужно 64 процессора с одинаковой скоростью, потому что моя программа не может поддерживать процессоры с разной скоростью. Они нужны на пару дней." Будем полагать, что они есть в наличии, не использованы. Задача клиента передается на исполнение одному из узлов. Данные могут поступать либо по сети, либо генерироваться в процессе исполнения задачи - местоположение и источник данных описывает пользователь. Когда исполнение задачи заканчивается, об этом информируется центральный узел. После этого центральный узел знает, что ресурсы, использовавшиеся задачей, освобождены и могут быть использованы для чего-нибудь другого, а пользователь и его программа уведомлены об окончании операции.

Другой вариант – это когда программа должна параллельно исполняться на нескольких узлах. Происходит примерно то же самое, что и в предыдущем примере. Единственное, что изменяется – вместо самой программы исполняется команда MPI Startup (MPI уже присутствует на этих узлах), которая потом информирует SMPD (это другой сервис или часть этого же node manage, в зависимости от того, как это установлено) о том, что нужно начать исполнение программы.

Теперь о том, как таким образом можно задавать эти задачи. Тут есть три варианта. Первый вариант – делать это программно, например, на C++ или Fortran. Это делается с помощью создаваемых на .NET Framework Web-сервисов (далее я покажу, как это делается) или созданием скрипта или файла пакетной обработки, делающего то же самое. Это позволяет исполнить программу на кластере в пакетном режиме. Второй вариант – пишется WUI, который позволит просматривать, какие программы в данный момент запущены на кластере, и какие ресурсы используются.

Взаимодействие с кластерами осуществляется с помощью довольно простого API, образующего некую объектную модель, специфичную для разных рантаймов. Например, при использовании C++ необходимо создать объект JobSesion, который инициализируется двумя параметрами. Первый параметр – имя самого узла, а второй – XML, содержащий описание ресурсов кластера. Используя XML, можно задавать параметры постепенно. Сначала задать часть параметров, например, указать, что первая версия программы нуждается в таком-то количестве процессоров на такое-то время. А в дальнейшем развивать это описание, включая туда все новые и новые требования (ресурсов кластера).

Этот объект содержит ряд дополнительных методов, позволяющих запустить задачу на исполнение, остановить задачу и получить информацию о статусе задачи (находится ли она в очереди, исполняется ли она или уже выполнилась).

Среди параметров, которые можно задать через XML-описание, можно выделить:

Таким образом можно взять обыкновенное настольное приложение, или приложение командной строки, и расширить его возможностями предоставляемыми кластерами.

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

Интерфейс передачи сообщений (Message Passing Interface, MPI)

Создание параллельных программ требуется там, где ресурсов обычного компьютера явно недостаточно для решения поставленной задачи. Распараллеливать можно данные или инструкции процессора. В основном сегодня распараллеливаются данные. Например, если необходимо рассчитать прогноз погоды на пять дней вперед, можно разбить площадь, для которой необходимо рассчитать погоду, на несколько частей. Каждый из параллельно работающих узлов сможет независимо обсчитывать свою часть задачи. После окончания параллельных расчетов для продолжения работы узлы обмениваются полученной информацией между собой. Для обмена информацией между узлами используется либо общая память, либо механизм обмена сообщениями.

В последние годы шла борьба между API передачи сообщений, используемых при построении кластерных решений, и в итоге MPI одержал победу над другими интерфейсами. Если углубиться в историю, то можно сказать, что ранее каждый производитель суперкомпьютеров разрабатывал собственный API, не совместимый с API других производителей. Попытки унифицировать API обмена сообщениями впервые были предприняты в исследовательской среде. К сожалению, они не увенчались успехом. Проблема была решена только в 1992 году, когда по инициативе Аргонской лаборатории в Чикаго был собран MPI-форум, утвердивший Message Passing Interface в качестве стандарта. В этом форуме приняли участие множество независимых компаний и лабораторий.

Этот API был реализован в течении следующих полутора лет. Это была C++-библиотека, позволявшая копировать задачу по узлам кластера, запускать все копии задачи на исполнение, осуществлять синхронизацию задач, и предоставляющая механизм обмена данными между отдельными копиями задач (используя в качестве протокола взаимодействия TCP/IP). К сожалению, TCP/IP оказался не лучшим решением. Во-первых, не все кластерные решения поддерживали этот протокол. Во-вторых, использование TCP/IP вносит ряд дополнительных проблем, как-то жесткая привязка к именам хостов и отсутствие возможности широковещательной рассылки сообщений.

Аргонской лабораторией была разработана свободно доступная реализация этого стандарта, названная MPICH («CH» в MPICH означает Chameleon – символ редкостной приспособляемости и гибкости – прим. ред.). Microsoft проанализировала ситуацию на рынке и приняла решение не создавать собственную реализацию MPI, а воспользоваться MPICH. Мы реализуем поддержку протоколов и устройств, необходимую для работы библиотеки под Windows. Результаты работы мы вернем Аргонской лаборатории (таким образом, как мы понимаем, исходный код будет доступен публично, поскольку MPICH – это свободно распространяемая библиотека – прим. ред.).

Для ускорения общения узлов кластера используется специальный расширенный вариант WinSock. Дело в том, что обычный WinSock, прежде чем начать передавать данные по сети, вынужден передать их в нулевое кольцо защиты. При этом возникают большие накладные расходы. Для обычных приложений, использующих относительно медленные сетевые устройства, это не критично, так как время, затрачиваемое на передачу по сети, несравненно больше чем эти накладные расходы. Но для кластеров с их высокопроизводительными подсистемами связи это недопустимо. Чтобы устранить эти накладные расходы, была придумана новая версия WinSock, называемая Direct WinSock. Она использует протокол RDMA, позволяющий создать «окна» памяти в разных узлах кластера. Если поместить данные в такое окно и оповестить Direct WinSock о том, что данные изменились, то произойдет быстрое переключение в нулевое кольцо защиты, и информация с максимально возможной скоростью будет передана на другие узлы кластера, в которых открыты окна, проецируемые на данное окно. Это позволяет существенно повысить скорость передачи информации, а также упростить эту процедуру. Другими словами, подобные подсистемы позволяют копировать память между процессами, расположенными на разных узлах кластера максимально эффективно.

Мы работаем с фирмами, производящими аппаратные реализации этого подхода. Эти фирмы будут создавать расширения MPI, которые позволят задачам воспользоваться этой технологией.

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

Copyright © 1994-2016 ООО "К-Пресс"