Кластеры и кластеризация. Программное обеспечение для кластеров

Вершина современной инженерной мысли - сервер Hewlett-Packard Integrity Model SD64A. Огромная SMP-система, объединяющая в себе 64 процессора Intel Itanium 2 с частотой 1,6 ГГц и 256 Гбайт оперативной памяти, колоссальная производительность, внушительная цена - 6,5 млн. долларов…

Вершина современной инженерной мысли - сервер Hewlett-Packard Integrity Model SD64A. Огромная SMP-система, объединяющая в себе 64 процессора Intel Itanium 2 с частотой 1,6 ГГц и 256 Гбайт оперативной памяти, колоссальная производительность, внушительная цена - 6,5 млн. долларов…

Нижняя строчка свежего рейтинга пятисот самых быстрых компьютеров мира: принадлежащий группе компаний SunTrust Banks Florida кластер на основе блейд-серверов HP ProLiant BL-25p. 480 процессоров Intel Xeon 3,2 ГГц; 240 Гбайт оперативной памяти. Цена - меньше миллиона долларов.

Как-то странно получается, согласитесь: шесть с половиной миллионов долларов за 64-процессорный сервер и вдесятеро меньше - за примерно аналогичный по объему памяти и дисковой подсистеме, но уже 480-процессорный суперкомпьютер, причем от того же самого производителя. Впрочем, странно это только на первый взгляд: общего у двух компьютеров совсем немного. SD64A - представитель "классического" направления симметричной многопроцессорности (SMP), хорошо знакомого нам по обычным серверам и многоядерным системам, позволяющий использовать "традиционное" параллельное ПО. Это кучка процессоров, много оперативной памяти и очень сложная система, сводящая их (и периферию сервера) в единое целое; причем даже весьма недешевые процессоры (по четыре тысячи долларов за каждый) и огромный объем оперативной памяти (по двести долларов за каждый гигабайт) - лишь малая часть стоимости этой "объединяющей" части сервера. Машина же SunTrust Bank Florida - представитель современного "кластерного" направления и по сути - просто набор соединенных в Ethernet-сеть обычных "недорогих" (по паре тысяч долларов за штуку) компьютеров. Серверная стойка, набор кабелей, система питания и охлаждения - вот и все, что эти компьютеры объединяет.

Что такое кластер?

Стандартное определение таково: кластер - это набор вычислительных узлов (вполне самостоятельных компьютеров), связанных высокоскоростной сетью (интерконнектом) и объединенных в логическое целое специальным программным обеспечением. Фактически простейший кластер можно собрать из нескольких персоналок, находящихся в одной локальной сети, просто установив на них соответствующее ПО[Всех желающих сделать это самостоятельно отсылаем к статье Михаила Попова "Еда и кластеры на скорую руку" (offline.computerra.ru/2002/430/15844), которая до сих пор актуальна]. Однако подобные схемы - скорее редкость, нежели правило: обычно кластеры (даже недорогие) собираются из специально выделенных для этой цели компьютеров и связываются друг с другом отдельной локальной сетью.

В чем идея подобного объединения? Кластеры ассоциируются у нас с суперкомпьютерами, круглые сутки решающими на десятках, сотнях и тысячах вычислительных узлов какую-нибудь сверхбольшую задачу, но на практике существует и множество куда более "приземленных" кластерных применений. Часто встречаются кластеры, в которых одни узлы, дублируя другие, готовы в любой момент перехватить управление, или, например, одни узлы, проверяя получаемые с другого узла результаты, радикально повышают надежность системы. Еще одно популярное применение кластеров - решение задачи массового обслуживания, когда серверу приходится отвечать на большое количество независимых запросов, которые можно легко раскидать по разным вычислительным узлам[Обычно эту штуку называют серверной фермой, именно по такому принципу работает Google]. Однако рассказывать об этих двух, если угодно, "вырожденных" случаях кластерных систем практически нечего - из их краткого описания и так ясно, как они работают; поэтому разговор наш пойдет именно о суперкомпьютерах.
Итак, суперкомпьютер-кластер. Он состоит из трех основных компонентов: собственно "вычислялок" - компьютеров, образующих узлы кластера; интерконнекта, соединяющего эти узлы в сеть, и программного обеспечения, заставляющего всю конструкцию "почувствовать" себя единым компьютером. В роли вычислительных узлов может выступать что угодно - от старой никому не нужной персоналки до современного четырехпроцессорного сервера, причем их количество ничем не ограниченно (ну разве что площадью помещения да здравым смыслом). Чем быстрее и чем больше - тем лучше; и как эти узлы устроены, тоже неважно[Обычно для упрощения решения и непростой задачи балансировки нагрузки на разные узлы кластера все узлы в кластере делают одинаковыми, но даже это требование не абсолютно]. Гораздо интереснее обстоят дела с интерконнектом и программным обеспечением.

Как устроен кластер?

История развития кластерных систем неразрывно связана с развитием сетевых технологий. Дело в том, что, чем больше элементов в кластере и чем они быстрее, (и, соответственно, чем выше быстродействие всего кластера), тем более жесткие требования предъявляются к скорости интерконнекта. Можно собрать кластерную систему хоть из 10 тысяч узлов, но если вы не обеспечите достаточной скорости обмена данными, то производительность компьютера по-прежнему оставит желать лучшего. А поскольку кластеры в высокопроизводительных вычислениях - это практически всегда суперкомпьютеры[Программирование для кластеров - весьма трудоемкая задача, и если есть возможность обойтись обычным сервером SMP-архитектуры с эквивалентной производительностью, то так и предпочитают делать. Поэтому кластеры используются только там, где SMP обходится слишком дорого, а со всех практических точек зрения требующие такого количества ресурсов машины - это уже суперкомпьютеры], то и интерконнект для них просто обязан быть очень быстрым, иначе полностью раскрыть свои возможности кластер не сможет. В результате практически все известные сетевые технологии хотя бы раз использовались для создания кластеров[Я даже слышал о попытках использования в качестве интерконнекта стандартных портов USB], причем разработчики зачастую не ограничивались стандартом и изобретали "фирменные" кластерные решения, как, например, интерконнект, основанный на нескольких линиях Ethernet, включаемых между парой компьютеров в параллель. К счастью, с повсеместным распространением гигабитных сетевых карт, ситуация в этой области становится проще[Почти половину списка суперкомпьютеров Top 500 составляют кластеры, построенные на основе Gigabit Ethernet], - они довольно дешевы, и в большинстве случаев предоставляемых ими скоростей вполне достаточно.

Вообще, по пропускной способности интерконнект почти дошел до разумного предела: так, постепенно появляющиеся на рынке 10-гигабитные адаптеры Ethernet вплотную подобрались к скоростям внутренних шин компьютера, и если создать некий гипотетический 100-гигабитный Ethernet, то не найдется ни одного компьютера, способного пропустить через себя такой огромный поток данных. Но на практике десятигигабитная локальная сеть, несмотря на всю свою перспективность, встречается редко - технология Ethernet допускает использование только топологии "звезда", а в подобной системе центральный коммутатор, к которому подключаются все остальные элементы, обязательно будет узким местом. Кроме того, у Ethernet-сетей довольно большая латентность[Время между отправкой запроса одним узлом и получением этого запроса другим узлом], что тоже затрудняет их использование в "тесно связанных" задачах, где отдельные вычислительные узлы должны активно обмениваться информацией. Поэтому несмотря на почти предельную пропускную способность Ethernet-решений в кластерах широко используются сети со специфической топологией - старая добрая Myrinet, дорогая элитная Quadrics, новенькая InfiniBand и др. Все эти технологии "заточены" под распределенные приложения и обеспечивают минимальную латентность исполнения команд и максимальную производительность. Вместо традиционной "звезды" здесь из вычислительных элементов строятся плоские и пространственные решетки, многомерные гиперкубы, поверхности трехмерного тора и другие "топологически хитрые" объекты. Такой подход позволяет одновременно передавать множество данных по сети, гарантируя отсутствие узких мест и увеличивая суммарную пропускную способность.

Как развитие идей быстрого интерконнекта отметим, например, адаптеры сети InfiniBand, подключающиеся через специальный слот HTX к процессорной шине HyperTransport. Фактически адаптер напрямую подключается к процессору[Напомним, что в многопроцессорных системах на базе AMD Opteron межпроцессорное взаимодействие происходит именно по этой шине]! Лучшие образцы подобных решений обеспечивают столь высокую производительность, что построенные на их основе кластеры вплотную приближаются по характеристикам к классическим SMP-системам, а то и превосходят их. Так, в ближайшие несколько месяцев на рынке должен появиться интереснейший чип под названием Chorus, который по четырем шинам HyperTransport подключается к четырем или двум процессорам AMD Opteron, расположенным на одной с ним материнской плате, и с помощью трех линков InfiniBand может подключаться еще к трем другим "Хорусам", контролирующим другие четверки (или пары) процессоров. Один Chorus - это одна материнская плата и один сравнительно независимый узел с несколькими процессорами, подключаемый стандартными кабелями InfiniBand к остальным узлам. Внешне вроде бы получается кластер, но - только внешне: оперативная память у всех материнских плат общая. Всего в текущем варианте может объединяться до восьми "Хорусов" (и соответственно до 32 процессоров), причем все процессоры будут работать уже не как кластер, а как единая SUMA-система, сохраняя, однако, главное достоинство кластеров - невысокую стоимость и возможность наращивания мощности. Такой вот получается "суперкластеринг", стирающий границы между кластерами и SMP.

Впрочем, все эти новомодные решения совсем не дешевы, - а ведь начинали мы с невысокой себестоимости кластера. Поэтому "Хорусы" да "Инфинибенды", стоящие солидных денег (несколько тысяч долларов на каждый узел кластера, что хоть и гораздо меньше, чем у аналогичных SMP-систем, но все равно дорого), встречаются нечасто. В секторе "академических" суперкомпьютеров, принадлежащих университетам, обычно используются самые дешевые решения, так называемые Beowulf–кластеры, состоящие из набора персоналок, соединенных гигабитной или даже стомегабитной Ethеrnet-сетью и работающих под управлением бесплатных операционных систем типа Linux. Несмотря на то что собираются такие системы буквально "на коленке", иногда из них все равно вырастают сенсации: к примеру, "биг-мак" - собранный из 1100 обычных "макинтошей" самодельный кластер, обошедшийся организаторам всего в 5,2 млн. долларов и умудрившийся занять в 2003 году третье место в рейтинге Top 500.

GRID-сети

Можно ли "продолжить" кластеры в сторону меньшей связанности точно так же, как, "продолжив" их в другом направлении, мы пришли к чипу Chorus и "почти SMP"? Можно! При этом мы отказываемся от построения специальной кластерной сети, а пытаемся использовать уже имеющиеся ресурсы - локальные сети и образующие их компьютеры. Общее название подобного рода решений - GRID-технологии, или технологии распределенных вычислений (вы наверняка с ними хорошо знакомы по таким проектам, как Distributed.Net или SETI@Home; машины добровольцев, участвующих в этих проектах, загружены разнообразными расчетами, ведущимися в то время, когда ПК хозяину не нужен). Ограничиваться достигнутым создатели GRID-систем не собираются и ставят перед собой амбициозную цель - сделать вычислительные мощности таким же доступным ресурсом, как электричество или газ в квартире. В идеале все компьютеры, подключенные к Интернету в рамках GRID, должны быть объединены в некое подобие кластера, и в то время, когда ваша машина простаивает, ее ресурсы будут доступны другим пользователям, а когда у вас возникает необходимость в больших мощностях, вам помогают "чужие" свободные компьютеры, которых в Сети предостаточно (кто-то отошел попить кофе, кто-то занимается серфингом или другими не загружающими процессор делами). Приоритетный доступ к ресурсам GRID будут иметь ученые, которые получат в распоряжение в буквальном смысле всемирный суперкомпьютер; но и обычные пользователи тоже внакладе не останутся.

Впрочем, если на словах все выглядит так замечательно, то почему это светлое будущее до сих пор не настало? Все дело в том, что при создании GRID возникают нетривиальные проблемы, решать которые пока никто толком не научился. В отличие от простого кластера при создании подобной системы приходится учитывать такие факторы, как неоднородность вычислительных узлов, низкая пропускная способность и нестабильность каналов, куда большее количество одновременно выполняемых задач, непредсказуемое поведение элементов системы, ну и, конечно, недоброжелательность некоторых пользователей. Судите сами: неоднородность нашей сети (причем очень сильная) возникает оттого, что к Интернету подключены самые разные компьютеры; у них разные возможности, разные линии связи и разные хозяева (режим работы у каждого свой). К примеру, где-то в школе есть гигабитная сеть из трех десятков почти всегда доступных, но не очень быстрых компьютеров, выключающихся на ночь в строго определенное время; а где-то стоит одинокий компьютер с завидной производительностью, непредсказуемо подключаемый к Сети по слабенькому дайлапу: так вот, в первом случае будут очень хорошо выполняться одни задачи, а во втором - совершенно другие. И для обеспечения высокой производительности системы в целом все это надо как-то анализировать и прогнозировать, чтобы оптимальным образом спланировать выполнение различных операций.

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

К сожалению, большое количество одновременно выполняемых задач существенно увеличивает нагрузку на управляющие элементы GRID-сети и осложняет задачу эффективного планирования, поскольку уже сами "управленцы", контролирующие эту сеть, зачастую начинают требовать для себя отдельный суперкомпьютер, ссылаясь на необходимость сложного контроля и планирования. А планировать и осуществлять контроль им действительно нелегко, и не только из-за неоднородности планируемых ресурсов, но и по причине их "ненадежности". Вот, к примеру, непредсказуемое поведение хозяина компьютера - это отдельная песня. В обычном кластере выход элемента из строя - нештатная ситуация, которая влечет за собой остановку вычислений и ремонтные работы, в GRID же отказ одного элемента - нормальная ситуация (почему бы не выключить компьютер, когда вам это надо?), ее нужно корректно обработать и передать невыполненное задание на другой узел или же заранее назначать одно и то же задание нескольким узлам.

И наконец, никуда не деться в GRID-сетях от недоброжелательных пользователей (не зря же сейчас очень много делается для защиты информации). Ведь нам нужно как-то распределять и планировать во всей сети задания от всех ее пользователей, - и мало ли чего какой-нибудь Василий Пупкин мог туда запустить? Сегодня и без того вирусы, заражающие подключенные к Интернету компьютеры специальными троянами ("зомбирование") и создающие целые "зомби-сети" из зараженных машин, готовых делать все, что заблагорассудится автору вируса (проводить ли распределенные DDoS-атаки или рассылать спам - неважно), представляют собой серьезнейшую угрозу, а тут - у любого человека появляется возможность посредством штатной системы рассылки распространить любой код на сотни и тысячи персоналок. И хотя эта проблема в принципе решаема (например, путем создания для выполняемых задач виртуальных машин - благо вскоре технологии аппаратной виртуализации , которые позволят это сделать без особого труда, станут штатной принадлежностью большинства новых компьютеров), то как защититься от банальной "шалости" в виде запуска бессмысленного кода (скажем, бесконечного цикла) и замусоривания им GRID-сети?

На самом деле все не так грустно, и многое в GRID-направлении уже сделано. Запущены и функционируют десятки проектов, использующих распределенные вычисления для научных и околонаучных целей; запущены и GRID-сети для "внутриуниверситетского" научного использования - в частности, CrossGrid, DataGrid и EUROGRID.

Программное обеспечение для кластеров

А вот здесь все очевидно и просто: фактически на протяжении последних пяти лет для кластерных вычислений существует один-единственный стандарт - MPI (Message Passing Interface). Программы, написанные с использованием MPI, абсолютно переносимы - их можно запускать и на SMP-машине, и на NUMA, и на любой разновидности кластера, и на GRID-сети, причем из любой операционной системы. Конкретных реализаций MPI довольно много (к примеру, каждый поставщик "фирменного" быстрого интерконнекта может предлагать свой вариант MPI-библиотеки для его решения), однако благодаря совместимости выбирать из них можно любой, какой вам приглянется (например, быстродействием или удобством настройки). Очень часто используется такой OpenSource-проект, как MPICH, обеспечивающий работу на более чем двух десятках различных платформ, включая самые популярные - SMP (межпроцессное взаимодействие через разделяемую память) и кластеры с интерконнектом Ethernet (межпроцессное взаимодействие поверх протокола TCP/IP), - если доведется когда-нибудь настраивать кластер, то начать советую именно с него.

На "классических" SMP-системах и некоторых NUMA’х реализация параллельных вычислений с использованием MPI заметно уступает по производительности более "аппаратно ориентированным" многопоточным приложениям, поэтому наряду с "чистыми" MPI-решениями встречаются "гибриды", в которых на кластере "в целом" программа работает с использованием MPI, но на каждом конкретном узле сети (а каждый узел кластера - это зачастую SMP-система) работает MPI-процесс, распараллеленный вручную на несколько потоков. Как правило, это гораздо эффективнее, но и гораздо труднее в реализации, а потому на практике встречается нечасто.

Как уже говорилось, можно выбрать практически любую операционную систему. Традиционно для создания кластеров используется Linux (более 70% систем Top 500) или другие разновидности Unix (оставшиеся 30%), однако последнее время к этому престижному рынку HPC (High Perfomance Computing) присматривается и Microsoft, выпустившая бета-версию Windows Compute Claster Server 2003[Бесплатно скачать эту бету можно ], в состав которой включена микрософтовская версия библиотеки MPI - MSMPI. Так что организация "кластера своими руками" вскоре может стать уделом не только юниксоидов, но и их менее знающих собратьев-администраторов, да и вообще - значительно упроститься.

Напоследок скажем, что кластерные вычисления годятся далеко не для всяких задач. Во-первых, программы под кластерные вычисления нужно "затачивать" вручную, самостоятельно планируя и маршрутизируя потоки данных между отдельными узлами. MPI, правда, сильно упрощает разработку параллельных приложений в том плане, что в нем при понимании сути происходящего соответствующий код очень нагляден и очевиден, и традиционные глюки параллельных программ типа дедлоков или параллельного использования ресурсов практически не возникают. Но вот заставить получающийся код быстро работать на MPI бывает довольно трудно - зачастую для этого приходится серьезно модифицировать сам программируемый алгоритм. В целом нераспараллеливающиеся и труднораспараллеливающиеся программы на MPI реализуются плохо; а все остальные - более или менее хорошо (в смысле - масштабируются до десятков, а в "хорошем" случае - и до тысяч процессоров). И чем больше степень связанности кластера, тем проще извлекать из него выгоду от параллельной обработки данных: на кластере, связанном сетью Myrinet, программа может работать быстро, а на аналогичном кластере, где интерконнектом выступает Fast Ethernet, - попросту не масштабироваться (не получать дополнительного прироста производительности) сверх десяти процессоров. Особенно трудно получить какой-либо выигрыш в GRID-сетях: там вообще, по большому счету, подходят только слабо связанные задачи с минимумом начальных данных и сильным параллелизмом - например, те, в которых приходится перебирать значительное количество вариантов.

Вот такие они - доступные всем суперкомпьютеры сегодняшнего дня. И не только доступные, но и более чем востребованные повсюду, где требуются высокопроизводительные вычисления за умеренные деньги. Даже простой пользователь, увлекающийся рендерингом, может собрать дома из своих машин небольшой кластер (рендеринг параллелится практически идеально, так что никаких ухищрений здесь не понадобится) и резко увеличить производительность труда[К примеру, пакет Maya позволяет организовать кластерный рендеринг даже без привлечения каких-либо сторонних пакетов и библиотек. Достаточно установить его на несколько компьютеров локальной сети и настроить сервер и несколько клиентов].

В качестве базового программного обеспечения для организации вычислений на кластерных системах рассматривается Windows Compute Cluster Server ( CCS ) 2003. Дается его общая характеристика и состав сервисов, работающих на узлах кластеров.

В заключение данного раздела, приводятся правила работы с консолью запуска и управления заданиями CCS . Описываются подробности работы планировщика CCS при исполнении последовательностей заданий на кластере.

1.1. Архитектура высокопроизводительных процессоров и кластерных систем

В истории развития архитектуры компьютерных процессоров можно выделить два крупных этапа:

• 1-й этап - увеличение тактовой частоты работы процессоров (до 2000 г.),
• 2-й этап - появление многоядерных процессоров (после 2000) г.

Таким образом, подход на основе SMP ( Symmetrical MultiProcessing ), который развивался при построении высокопроизводительных серверов, в которых несколько процессоров разделяют ресурс системы, и, в первую очередь , оперативную память (см. Рис 1.1), сместился "вниз" на уровень ядер внутри процессора.

Рис. 1.1.

На пути к многоядерным процессорам, первой появилась технология Hyper-Threading , впервые примененная в 2002 г. в процессорах Intel Pentium 4:

В этой технологии два виртуальных процессора разделяют между собой все ресурсы одного физического процессора, а именно, кэши, конвейер исполнения и отдельные исполнительные устройства. При этом, если один виртуальный процессор занял общий ресурс , то второй будет ожидать его освобождения. Тем самым, процессор с Hyper-Threading можно сравнить с многозадачной операционной системой, обеспечивающей каждому работающему в ней процессу свой виртуальный компьютер с полным набором средств и занимающейся планированием порядка и времени работы этих процессов на физическом оборудовании. Только в случае с Hyper-Threading , все это происходит на значительно более низком аппаратном уровне. Тем не менее, два потока команд позволяют более эффективно загрузить исполнительные устройства процессора. Реальный прирост производительности процессора от применения технологии Hyper-Threading оценивается от 10 до 20 процентов.

Полноценный двухъядерный процессор (см. Рис 1.3), на отдельных задачах демонстрирует прирост производительности от 80 до 100 процентов.

Таким образом, двухъядерный и, в общем случае, многоядерный процессор , можно рассматривать как SMP -систему в миниатюре, в которой отсутствует необходимость использования сложных и дорогих многопроцессорных материнских плат.

Более того, каждое ядро может (как, например, в процессоре Intel Pentium Extreme Edition 840) поддерживать технологию Hyper-Threading , а потому такого рода двухъядерный процессор может выполнять четыре программных потока одновременно.

В начале 2007 г., корпорация Intel представила 80-ядерный однокристальный процессор , получивший название Teraflops Research Chip (http://www.intel.com/research/platform/terascale/teraflops.htm). Этот процессор может достигать производительности 1,01 терафлопс при минимальной тактовой частоте ядра 3,16 ГГц и напряжении 0,95 В. При этом общее энергопотребление чипа составляет всего 62 Вт.

По прогнозам Intel, коммерческие варианты процессоров с большим числом ядер появятся в ближайшие 5 лет, а к 2010 г. четверть объема всех поставляемых серверов будут иметь терафлопную производительность .

Кластерные вычислительные системы и их архитектура

Кластер - это локальная (расположенная территориально в одном месте) вычислительная система, состоящая из множества независимых компьютеров и сети, связывающей их. Кроме того, кластер является локальной системой потому, что он управляется в рамках отдельного административного домена как единая компьютерная система.

Компьютерные узлы из которых он состоит, являются стандартными, универсальными (персональными) компьютерами, используемыми в различных областях и для разнообразных приложений. Вычислительный узел может содержать либо один микропроцессор, либо несколько, образуя, в последнем случае, симметричную (SMP-) конфигурацию.

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

Программное обеспечение кластеров состоит из двух компонент:

• средств разработки/программирования и
• средств управления ресурсами.

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

К программному обеспечению управления ресурсами относятся средства инсталляции, администрирования и планирования потоков работ.

Хотя для параллельной обработки существует очень много моделей программирования, но, на настоящий момент, доминирующим подходом является модель на основе "передачи сообщений" ( message passing ), реализованная в виде стандарта MPI ( Message Passing Interface). MPI - это библиотека функций, с помощью которых в программах на языках C или Фортран можно передавать сообщения между параллельными процессами, а также управлять этими процессами.

Альтернативами такому подходу являются языки на основе так называемого "глобального распределенного адресного пространства" (GPAS - global partitioned address space), типичными представителями которых являются языки HPF (High Performance Fortran) и UPC (Unified Parallel C).

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

Одна из основных задач при эксплуатации ИТ-системы в каком-либо бизнесе состоит в том, чтобы обеспечить непрерывность предоставляемого сервиса. Однако очень часто и инженеры, и руководители ИТ-служб не совсем четко представляют себе, в чем же выражается «непрерывность» конкретно в их бизнесе. На взгляд автора, это связано с неоднозначностью и расплывчатостью самого понятия непрерывности, из-за чего не всегда можно четко сказать, какой период дискретизации считать непрерывным и какой интервал будет промежутком недоступности. Усугубляет ситуацию и множество технологий, призванных в конечном счете решать одну общую задачу, но разными способами.

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

Что угрожает приложениям...

По разным оценкам, 55-60% приложений критичны для бизнеса компании - это означает, что отсутствие сервиса, который предоставляют данные приложения, серьезно отразится на финансовом благополучии фирмы. В связи с этим понятие доступности становится фундаментальным аспектом в деятельности вычислительного центра. Давайте посмотрим, откуда же исходят угрозы доступности приложений.

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

Аппаратная неисправность. Производители аппаратных комплексов (серверов, дисковых хранилищ) выпускают решения с избыточностью компонентов - процессорных плат, системных контроллеров, блоков питания и т. п. Тем не менее в отдельных случаях аппаратная неисправность может привести к недоступности приложений.

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

Человеческая ошибка. Простой пример: администратор вносит изменения в настройку конфигурационных файлов, к примеру, DNS. Когда он тестирует изменения, сервис DNS работает, а вот сервис, который использует DNS, например, электронная почта, начинает испытывать проблемы, которые выявляются не сразу.

Плановое обслуживание. Обслуживание системы - замена компонентов, установка пакетов обновлений, перезагрузка - составляет основную причину недоступности. По оценке Gartner, 80% времени, в течение которого система недоступна, - это плановые простои.

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

...и как с этим бороться

В зависимости от критичности задачи можно использовать следующие механизмы восстановления работоспособности вычислительной системы.

Резервное копирование данных на ленточный или дисковый носитель. Это базовый уровень обеспечения доступности - самый простой, дешевый, но и самый медленный.

Локальное зеркалирование. Предоставляет доступность данных в реальном времени, данные защищены от разрушения.

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

Удаленная репликация. Здесь предполагается разнесение вычислительных площадок с целью создания копии данных в разнесенных ЦОД.

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

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

На взгляд автора, для понимания стратегии восстановления сервиса весьма удачен подход компании Symantec (рис. 1). Здесь есть два ключевых момента - точка, в которую система восстанавливается (recovery point objective, RPO), и время, требуемое на восстановление сервиса (recovery time objective, RTO).

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

Для самых критичных систем RTO и RPO не должны превышать 1 ч. Системы на основе ленточного резервного копирования предоставляют точку восстановления в два или более дней. Кроме того, восстановление с ленты не автоматизировано, администратор должен постоянно помнить, все ли он должным образом восстановил и запустил.

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

Если требуется предоставить RTO и RTS, измеряемое минутами, т. е. задача требует минимизации простоев (как плановых, так и незапланированных), то единственно верное решение - кластер высокой готовности. В настоящей статье рассматриваются именно такие системы.

Ввиду того, что понятие «вычислительный кластер» с некоторых пор перегружено из-за большого их разнообразия, вначале скажем немного о том, какие бывают кластеры.

Типы кластеров

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

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

Кластеры могут существовать в различных формах. К наиболее общим типам кластеров относятся системы повышенной производительности (high performance computing, HPC) и системы высокой доступности (high availability, HA).

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

Однако тема данной статьи - системы высокой доступности. Поэтому далее, говоря о кластерах, мы будем иметь в виду именно такие системы.

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

В простейшем случае это два идентично сконфигурированных сервера с доступом к разделяемой системе хранения данных (рис. 2). В процессе нормального функционирования прикладное ПО выполняется на одной системе, в то время как вторая система находится в ожидании запуска приложений при выходе из строя первой системы. При обнаружении сбоя вторая система переключает на себя соответствующие ресурсы (файловую систему, сетевые адреса и т. д.). Этот процесс обычно называется восстановлением после отказа (failover). Вторая система полностью заменяет собой отказавшую, и пользователю совершенно необязательно знать, что его приложения выполняются на различных физических машинах. Это и есть наиболее распространенная двухузловая ассиметричная конфигурация, где один сервер активен, другой пассивен, т. е. находится в состоянии ожидания на случай неисправности основного. На практике именно эта схема работает в большинстве компаний.

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

Конфигурации кластеров

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

Симметричный кластер

Симметричный кластер также выполнен на двух узлах, но на каждом их них работает активное приложение (рис. 3). Кластерное ПО обеспечивает корректный автоматический переход приложения с сервера на сервер при отказе одного из узлов. В этом случае загрузка оборудования оказывается более эффективной, но при возникновении неисправности получается, что на одном сервере работают приложения всей системы, что может иметь нежелательные последствия в плане производительности. Кроме того, необходимо учитывать, возможна ли работа нескольких приложений на одном сервере.

Конфигурация N+1

В эту конфигурацию уже входит более двух узлов, и среди них имеется один выделенный, резервный (рис. 4). Иначе говоря, на N работающих серверов приходится один, находящийся в горячем резерве. В случае неисправности приложение с проблемного узла «переедет» на выделенный свободный узел. В дальнейшем администратор кластера сможет заменить неисправный узел и назначить его резервным.

Разновидность N+1 - менее гибкая конфигурация N к 1, когда резервный узел всегда остается постоянным для всех рабочих узлов. В случае выхода из работы активного сервера сервис переключается на резервный, и система остается без резерва до тех пор, пока не будет активирован вышедший из строя узел.

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

Конфигурация N к N

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

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

Оценка кластерных конфигураций

В табл. 1 суммируется сказанное выше о различных конфигурациях кластеров. Оценка дается по четырехбалльной шкале (4 - высший балл, 1 – низший).

Из табл. 1 видно, что наиболее проста в плане проектирования и эксплуатации классическая ассиметричная система. И если ее заказчик может эксплуатировать самостоятельно, то остальные было бы правильно передать на внешнее обслуживание.

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

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

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

Основные компоненты кластера

Как любой сложный комплекс, кластер независимо от конкретной реализации состоит из аппаратной и программной составляющих.

Что касается аппаратуры, на которой собирается кластер, основная составляющая здесь - межузловое соединение или внутренний кластерный интерконнект, обеспечивающий физическую и логическую связь серверов. На практике это внутренняя сеть Ethernet с продублированными соединениями. Ее назначение - во первых, передача пакетов, подтверждающих целостность системы (так называемых heartbeat), а во-вторых, при определенном дизайне или схеме, возникшей после возникновения неисправности, - обмен между узлами информационным трафиком, предназначенным для передачи вовне. Другие компоненты очевидны: узлы, на которых запущена ОС с кластерным ПО, дисковые хранилища, к которым имеют доступ узлы кластера. И наконец, общая сеть, через которую идет взаимодействие кластера с внешним миром.

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

Реализации кластеров

На рынке ПО существует много реализаций описанных выше кластерных конфигураций. Практически все крупнейшие производители серверов и ПО - например, Microsoft, HP, IBM, Sun, Symantec - предлагают свои продукты в этой области. Компания «Микротест» имеет опыт работы с решениями Sun Cluster Server (SC) от Sun Microsystems (www.sun.com) и Veritas Cluster Server (VCS) от Symantec (www.symantec.com). С точки зрения администратора по функционалу эти продукты очень похожи - предоставляют одинаковые возможности настройки и реакций на события. Однако по своей внутренней организации это совершенно разные продукты.

SC разработан Sun для собственной ОС Solaris и потому работает только в среде этой ОС (как на платформе SPARC, так и на x86). Как следствие SC при инсталляции глубоко интегрируется с ОС и становится ее частью, частью ядра Solaris.

VCS - продукт многоплатформенный, работает практически со всеми популярными ныне ОС - AIX, HP-UX, Solaris, Windows, Linux, и представляет собой надстройку - приложение, которое управляет работой других приложений, подлежащих кластеризации.

Мы рассмотрим внутреннюю реализацию этих двух систем - SC и VCS. Но еще раз подчеркнем, что несмотря на различие в терминологии и совершенно разное внутреннее устройство основные компоненты обеих систем, с которыми взаимодействует администратор, по сути своей одинаковы.

Программные компоненты Sun Cluster Server

В качестве ядра SC (рис. 6) выступает ОС Solaris 10 (или 9) с надстроенной оболочкой, обеспечивающей функцию высокой доступности (ядро выделено зеленым цветом). Далее идут глобальные компоненты (светло-зеленого цвета), которые предоставляют свои службы, полученные от кластерного ядра. И наконец, на самом верху - пользовательские компоненты.

HA framework - это компонент, расширяющий ядро Solaris для предоставления кластерных служб. Задача framework начинается с инициализации кода, загружающего узел в кластерный режим. Основные задачи framework - межузловое взаимодействие, управление состоянием кластера и членством в нем.

Модуль межузлового взаимодействия передает сообщения heartbeating между узлами. Это короткие сообщения, подтверждающие отклик соседнего узла. Взаимодействием данных и приложений также управляет HA framework как частью межузлового взаимодействия. Кроме того, framework управляет целостностью кластерной конфигурации и при необходимости выполняет задачи восстановления и обновления. Целостность поддерживается через кворум-устройство; при необходимости выполняется реконфигурация. Кворум-устройство - это дополнительный механизм проверки целостности узлов кластера через небольшие участки общей файловой системы. В последней версии кластера SC 3.2 появилась возможность назначать кворум-устройство вне кластерной системы, т. е. использовать дополнительный сервер на платформе Solaris, доступный по TCP/IP. Неисправные члены кластера выводятся из конфигурации. Элемент, который вновь оказывается работоспособен, автоматически включается в конфигурацию.

Функции глобальных компонентов вытекают из HA framework. Сюда относятся:

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

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

Программные компоненты Veritas Cluster Server

Схематически двухузловой VCS-кластер представлен на рис. 7. Межузловое взаимодействие в VCS основано на двух протоколах - LLT и GAB. Для поддержки целостности кластера VCS использует внутреннюю сеть.

LLT (Low Latency Transport) - это разработанный Veritas протокол, функционирующий поверх Ethernet как высокоэффективная замена IP-стека и используемый узлами во всех внутренних взаимодействиях. Для требуемой избыточности в межузловых коммуникациях требуется как минимум две полностью независимые внутренние сети. Это необходимо, чтобы VSC мог различить сетевую и системную неисправность.

Протокол LLT выполняет две основные функции: распределение трафика и отправку heartbeating. LLT распределяет (балансирует) межузловое взаимодействие между всеми доступными внутренними связями. Такая схема гарантирует, что весь внутренний трафик случайно распределен между внутренними сетями (их может быть максимум восемь), что повышает производительность и устойчивость к отказу. В случае неисправности одного линка данные будут перенаправлены на оставшиеся другие. Кроме того, LLT отвечает за отправку через сеть heartbeat-трафика, который используется GAB.

GAB (Group Membership Services/Atomic Broadcast) - это второй протокол, используемый в VCS для внутреннего взаимодействия. Он, как и LLT, ответственен за две задачи. Первая - это членство узлов в кластере. GAB получает через LLT heartbeat от каждого узла. Если система долго не получает отклика от узла, то она маркирует его состояние как DOWN - нерабочий.

Вторая функция GAB - обеспечение надежного межкластерного взаимодействия. GAB предоставляет гарантированную доставку бродкастов и сообщений «точка-точка» между всеми узлами.

Управляющая составляющая VCS - VCS engine, или HAD (High Availability daemon), работающая на каждой системе. Она отвечает за:

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

HAD использует агенты для мониторинга и управления ресурсами. Информация о состоянии ресурсов собирается от агентов на локальных системах и передается всем членам кластера. HAD каждого узла получает информацию от других узлов, обновляя свою собственную картину всей системы. HAD действует как машина репликации состояния (replicated state machine RSM), т. е. ядро на каждом узле имеет полностью синхронизированную со всеми остальными узлами картину состояния ресурсов.

Кластер VSC управляется либо через Java-консоль, либо через Web.

Что лучше

Вопрос о том, когда какой кластер лучше использовать, мы уже обсуждали выше. Еще раз подчеркнем, что продукт SC написан Sun под собственную ОС и глубоко с ней интегрирован. VCS - продукт многоплатформенный, а следовательно, более гибкий. В табл. 2 сопоставлены некоторые возможности этих двух решений.

В заключение хотелось бы привести еще один аргумент в пользу применения SC в среде Solaris. Используя и оборудование, и ПО от единого производителя - Sun Microsystems, заказчик получает сервис в «едином окне» на все решение. Несмотря на то что вендоры сейчас создают общие центры компетенции, время на трансляцию запросов между производителями ПО и оборудования снизит скорость отклика на инцидент, что не всегда устраивает пользователя системы.

Территориально распределенный кластер

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

Репликация данных с основной площадки на резервную чаще всего выполняется при помощи одного из популярных пакетов: Veritas Volume Replicator, EMC SRDF, Hitachi TrueCopy, Sun StorageTek Availability Suite.

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

Недостаток такого подхода - огромная стоимость развертывания дополнительной «горячей» площадки с оборудованием и сетевой инфраструктурой. Однако преимущество полной защиты может перевесить эти дополнительные расходы. Если центральный узел в течение длительного времени не в состоянии предоставлять сервис, это может привести к крупным потерям и даже к гибели бизнеса.

Испытание системы до катастрофы

Согласно результатам проведенного компанией Symantec исследования, испытание плана аварийного восстановления проводит только 28% компаний. К сожалению, большинство заказчиков, с которыми автору приходилось беседовать по этому вопросу, вообще не имели такого плана. Причины, по которым не проводится тестирование, - отсутствие времени у администраторов, нежелание делать это на «живой» системе и отсутствие тестового оборудования.

Для испытаний можно привлечь симулятор, входящий в пакет VSC. Пользователи, выбравшие в качестве кластерного ПО VCS, могут провести испытания своих настроек на Cluster Server Simulator, который позволит на ПК проверить стратегию миграции приложений между узлами.

Заключение

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

Кластеры обычно строятся для задач, критичных для бизнеса, где единица простоя выливается в большие потери, например, для биллинговых систем. Можно было бы рекомендовать следующее правило, определяющее, где разумно использовать кластеры: там, где время простоя сервиса не должно превышать полутора часов, кластер - подходящее решение. В остальных случаях можно рассмотреть менее дорогие варианты.

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

Аналитики из IDC подсчитали, что объем рынка кластеров в 1997 году составлял всего 85 млн. долл., тогда как в прошлом году этот рынок «стоил» уже 367,7 млн. долл. Тенденция роста налицо.

Итак, попробуем расставить все точки над «i». На сегодняшний день не существует какого-либо четкого определения кластера. Более того, нет ни одного стандарта, четко регламентирующего кластер. Однако не стоит отчаиваться, ведь сама суть кластеризации не подразумевает соответствие какому-либо стандарту. Единственное, что определяет, что кластер - это кластер, так это набор требований, предъявляемых к таким системам. Перечислим эти требования (четыре правила):l надежность;l доступность функции (готовность);l масштабируемость;l вычислительная мощность. Исходя из этого сформулируем определение кластера. Кластер - это система произвольных устройств (серверы, дисковые накопители, системы хранения и пр.), обеспечивающих отказоустойчивость на уровне 99,999%, а также удовлетворяющая «четырем правилам». Для примера: серверный кластер - это группа серверов (обычно называемых узлами кластера), соединенных и сконфигурированных таким образом, чтобы предоставлять пользователю доступ к кластеру как к единому целостному ресурсу.

Отказоустойчивость

Масштабируемость

Beowulf, или Вычислительная мощность

Мини-кластер от Dell и Compaq

Сухой остаток

КомпьютерПресс 10"2000

Развитие кластерных систем (КС) в России

Кластер - это модульная многопроцессорная система, созданная на базе стандартных вычислительных узлов, соединенных высокоскоростной коммуникационной средой. Сейчас слова «кластер» и «суперкомпьютер» в значительной степени синонимы, но прежде чем об этом стало можно с уверенностью говорить, аппаратные средства прошли длительный цикл эволюции. В течение первых 30 лет с момента появления компьютеров, вплоть до середины 1980-х гг., под «суперкомпьютерными» технологиями понимали исключительно производство специализированных особо мощных процессоров. Однако появление однокристального микропроцессора практически стерло разницу между «массовыми» и «особо мощными» процессорами, и с этого момента единственным способом создания суперкомпьютера стал путь объединения процессоров для параллельного решения одной задачи. Алексей Лацис, один из создателей российского суперкомпьютера МВС-1000М, в своей книге «Как построить и использовать суперкомпьютер» называет это «первой суперкомпьютерной революцией».

Примерно до середины 1990-х гг. основное направление развития суперкомпьютерных технологий было связано с построением специализированных многопроцессорных систем из массовых микросхем. Один из сформировавшихся подходов - SMP (Symmetric Multi Processing), подразумевал объединение многих процессоров с использованием общей памяти, что сильно облегчало программирование, но предъявляло высокие требования к самой памяти. Сохранить быстродействие таких систем при увеличении количества узлов до десятков было практически невозможно. Кроме того, этот подход оказался самым дорогим в аппаратной реализации. На порядок более дешевым и практически бесконечно масштабируемым оказался способ МРР (Massively Parallel Processing), при котором независимые специализированные вычислительные модули объединялись специализированными каналами связи, причем и те и другие создавались под конкретный суперкомпьютер и ни в каких других целях не применялись.

Идея создания так называемого кластера рабочих станций фактически явилась развитием метода МРР, ведь логически МРР-система не сильно отличалась от обычной локальной сети. Локальная сеть стандартных персональных компьютеров, при соответствующем ПО использовавшаяся как многопроцессорный суперкомпьютер, и стала прародительницей современного кластера. Эта идея получила более совершенное воплощение в середине 1990-х гг., когда благодаря повсеместному оснащению ПК высокоскоростной шиной PCI и появлению дешевой, но быстрой сети. Fast Ethernet кластеры стали догонять специализированные МРР-системы по коммуникационным возможностям. Это означало, что полноценную МРР-систему можно было создать из стандартных серийных компьютеров при помощи серийных коммуникационных технологий, причем такая система обходилась дешевле в среднем на два порядка.

Вот самые знаменитые суперкомпьютеры с кластерной архитектурой «первого поколения»: Beowulf (1994, NASA Goddard Space Flight Center) - 16-процессор-ный кластер на процессорах Intel 486DX4/100 МГц; Avalon (1998, Лос-Аламосская национальная лаборатория) - Linux-кластер на базе процессоров Alpha 21164А/533 МГц. Первоначально Avalon состоял из 68 процессоров, затем их число увеличилось до 140; его производительность на тесте LINPACK 48,6 GFlops* позволила ему занять 113-е место в 12-й редакции рейтинга самых мощных компьютеров мира Тор500 рядом со 152-процессорной SMP-системой IBM RS/6000 SP. Первой отечественной системой, вошедшей в ТорбОО, стал кластер МВС-1000М, изготовленный НИИ «КВАНТ» и Институтом прикладной математики Российской академии наук. Он состоял из 384 узлов на базе процессоров Alpha 21164 компании DEC-Compaq.

* Flops (floating point operations per second) - количество операций с плавающей точкой в секунду, единица измерения производительности суперкомпьютеров. GFlops (гигафлопс) - миллиард операций с плавающей точкой в секунду; TFlops (терафлопс) - триллион операций с плавающей точкой в секунду. Реальная производительность самого мощного на сегодня суперкомпьютера превышает 136 TFlops; всего год назад этот показатель составлял 35 TFlops.

Различают пиковую и реальную производительность суперкомпьютеров. Пиковая производительность многопроцессорной системы (кластера, SMP-системы и т. д.) - теоретическое значение, недостижимое на практике. Оно получается умножением пиковой производительности процессора на число процессоров в системе. Пиковая производительность ЦП в общем случае получается путем умножения его тактовой частоты на максимальное число операций, выполняемых за один такт. Реальная производительность кластера - это производительность, полученная при решении реальной задачи (академической или промышленной). Например, системы в рейтинге Тор500 ранжируются по результатам теста LINPACK - реальной академической задачи на решение системы линейных уравнений.

Новый мощный толчок развитию кластерных технологий, помимо появления более совершенных коммуникационных сетей, дал быстрый рост производительности вновь выпускаемых массовых процессоров, что сделало высокопроизводительные решения доступными как никогда. Например, «СКИФ К-500», второй отечественный кластер, вошедший в ТорбОО, построен на базе 128 процессоров Intel Xeon и системной сети SCI. Построенный осенью 2003 г. для российско-белорусской государственной суперкомпьютерной программы «СКИФ», этот кластер занял в рейтинге 407-е место с реальной производительностью в 423,6 GFlops. Второй «топовый» кластер государственной программы, «СКИФ К-1000» на базе 576 процессоров AMD Opteron и системной сети InfiniBand, появился в октябре 2004 г. и вошел в первую сотню Тор500 с реальной производительностью 2,032 TFlops. Оба кластера «СКИФ», установленных в Белоруссии, построены компанией «Т-Платформы» с участием ИПС РАН и белорусских партнеров и используют российские суперкомпьютерные технологии. Самый мощный на данный момент кластер на территории России - МВС 15000БМ с реальной производительностью более 5,3 Tflops, он занимает 56-е место в Тор500 и установлен в Межведомственном суперкомпьютерном центре (МСЦ РАН). Кластер построен из вычислительных узлов компании IBM на базе процессоров PowerPC и системной сети Myrinet.

Бурное развитие кластерных технологий за последние годы хорошо видно из анализа списка Тор500: с 2000 по 2004 г. доля кластеров в списке увеличилась с 2,2 до 60,8%. Если в 2000 г. в числе 40 самых мощных установок присутствовало лишь два кластера (самый мощный - 31-е место), то к 2004 г. их число среди первых 40 машин составило 24). При этом, по данным последней редакции Тор500, более 71,5% процессоров, использованных для ерздания суперкомпьютеров, - это массово выпускаемые процессоры компаниями Intel и AMD.

Кластерные технологии применяются и в новейших суперкомпьютерных разработках ведущих изготовителей: например, в самом мощном на сегодня суперкомпьютере IBM BlueGene/L с производительностью более 136 TFlops использованы многие элементы кластерной архитектуры.

Сфера применения кластерных систем сейчас нисколько не уже, чем суперкомпьютеров с другой архитектурой: они не менее успешно справляются с задачей моделирования самых разных процессов и явлений. Суперкомпьютерное моделирование может во много раз удешевить и ускорить вывод на рынок новых продуктов, а также улучшить их качество. Например, вместо того чтобы строить дорогостоящие тестовые модели новых автомобилей, чтобы затем разбить их об стенку ради проведения инженерных расчетов, можно быстрее и точнее все посчитать на компьютерных моделях. Благодаря этому многим западным автомобильным концернам удалось сократить срок разработки новой модели автомобиля в пять раз - с 10 до 2 лет. Компьютерная обработка геофизических данных позволяет создавать высокодетализированные модели нефтяных и газовых месторождений, обеспечивая более эффективную, безопасную и дешевую разработку скважин.

Именно развитие кластерных технологий сделало высокопроизводительные вычисления широко доступными и позволило самым разным предприятиям воспользоваться их преимуществами. Вот как распределяются области применения 500 самых мощных компьютеров мира: 44,3% - добывающая, электронная, автомобильная, авиационная и др. отрасли тяжелой промышленности и машиностроения, чуть более 20% - наука и образование, суперкомпьютерные центры. Более 18% приходится на погодные и климатические исследования, 7% - ядерные, космические, энергетические и военные государственные программы, 3,5% - финансовые компании и банки. Кроме того, в списке есть компании и организации, занимающиеся медициной и разработкой новых лекарств, компьютерной графикой, перевозками, торговлей, производством продуктов питания, консалтингом и государственным управлением.

Что касается использования суперкомпьютеров в России, то в текущем рейтинге суперкомпьютеров СНГ Тор50, впервые изданном в декабре 2004 г., представлены только три класса пользователей: научные институты и университеты, предприятия, занятые в тяжелой и нефтедобывающей промышленности, а также финансовые структуры.

В среднем отечественные суперкомпьютеры пока еще сильно уступают западным по производительности: машины, используемые для научных исследований, в 15 раз, вычислительные ресурсы финансовых компаний - в 10 раз, промышленные суперкомпьютеры - в 9 раз. Однако уже вторая редакция списка Тор50, опубликованная в апреле 2005 г., демонстрирует быстрое развитие отрасли. Так, количество систем, работающих в промышленной сфере, увеличилось с 2 до 16%, причем их средняя производительность выросла сразу на 135%. Число суперкомпьютеров финансовых компаний и банков также возросло с 2 до 18%. Доля суперкомпьютеров, используемых для научных исследований, сократилась с 96 до 66%, а их средняя производительность выросла на 70%. В целом вторая редакция отечественного суперкомпьютерного рейтинга демонстрирует существенный рост доли систем коммерческого использования. Самое большое количество отечественных суперкомпьютеров поставлено фирмой IBM (26%), но российские изготовители лишь немного уступают ей.