Современные кластерные системы и их использование. Кластер (группа компьютеров)

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

Кластер - это модульная многопроцессорная система, созданная на базе стандартных вычислительных узлов, соединенных высокоскоростной коммуникационной средой. Сейчас слова «кластер» и «суперкомпьютер» в значительной степени синонимы, но прежде чем об этом стало можно с уверенностью говорить, аппаратные средства прошли длительный цикл эволюции. В течение первых 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%), но российские изготовители лишь немного уступают ей.

Кластер (компьютеры)

Классификация кластеров

Кластеры высокой доступности

Обозначаются аббревиатурой HA (англ. High Availability - высокая доступность). Создаются для обеспечения высокой доступности сервиса, предоставляемого кластером. Избыточное число узлов, входящих в кластер, гарантирует предоставление сервиса в случае отказа одного или нескольких серверов. Типичное число узлов - два, это минимальное количество, приводящее к повышению доступности. Создано множество программных решений для построения такого рода кластеров. В частности, для GNU/Linux , Solaris существует проект бесплатного ПО Linux-HA .

Кластеры распределения нагрузки

Принцип их действия строится на распределении запросов через один или несколько входных узлов, которые перенаправляют их на обработку в остальные, вычислительные узлы. Первоначальная цель такого кластера - производительность, однако, в них часто используются также и методы, повышающие надёжность. Подобные конструкции называются серверными фермами . Программное обеспечение (ПО) может быть как коммерческим (OpenVMS Cluster, Platform LSF HPC, Sun Grid Engine, Moab Cluster Suite, Maui Cluster Scheduler), так и бесплатным (Linux Virtual Server, Mosix).

Вычислительные кластеры

Кластеры используются в вычислительных целях, в частности в научных исследованиях. Для вычислительных кластеров существенными показателями являются высокая производительность процессора на операциях над числами с плавающей точкой (Flops) и низкая латентность объединяющей сети, и менее существенными - скорость операций ввода-вывода, которая в большей степени важна для баз данных и web-сервисов . Вычислительные кластеры позволяют уменьшить время расчетов, по сравнению с одиночным компьютером, разбивая задание на параллельно выполняющиеся ветки, которые обмениваются данными по связывающей сети. Одна из типичных конфигураций - набор компьютеров, собранных из общедоступных компонентов, с установленной на них операционной системой Linux, и связанных сетью Myrinet, Beowulf. Специально выделяют высокопроизводительные кластеры (Обозначаются англ. аббревиатурой HPC Cluster - High-performance computing cluster ). Список самых мощных высокопроизводительных компьютеров (также может обозначаться англ. аббревиатурой HPC ) можно найти в мировом рейтинге TOP500 . В России ведется рейтинг самых мощных компьютеров СНГ TOP50 Суперкомпьютеры .

Системы распределенных вычислений (grid)

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

Самые производительные

Дважды в год организацией IBM Roadrunner (Лос-Аламосская национальная лаборатория , США , созданный в ), его максимальная производительность (на июль 2008) составляет 1,026 2008) - суперкомпьютер, BlueGene /P находится в Федеративной Республике Германия , в исследовательском центре города Юлих, земля Северный Рейн-Вестфалия, максимально достигнутая производительность 167,3 Висконсин, США).

Сравнительно дешёвую альтернативу суперкомпьютерам представляют кластеры, основанные на концепции Beowulf , которые строятся из обыкновенных недорогих компьютеров на основе бесплатного программного обеспечения. Один из практических примеров такой системы - Stone Soupercomputer (Оак Ридж, шт. Теннесси , США, ).

Крупнейший кластер, принадлежащий частному лицу (из 1000 процессоров), был построен Джоном Козой (John Koza).

История

История создания кластеров неразрывно связана с ранними разработками в области компьютерных сетей. Одной из причин для появления скоростной связи между компьютерами стали надежды на объединение вычислительных ресурсов. В начале 1970-х гг. группой разработчиков протокола TCP/IP и лабораторией Xerox PARC были закреплены стандарты сетевого взаимодействия. Появилась и операционная система Hydra («Гидра») для компьютеров DEC, созданный на этой основе кластер был назван C.mpp (Питтсбург , шт. Пенсильвания , США, ). Тем не менее, только около г. были созданы механизмы, позволяющие с лёгкостью пользоваться распределением задач и файлов через сеть, по большей части это были разработки на основе Sun Microsystems.

Первым коммерческим проектом кластера стал ARCNet, созданный компанией Datapoint в г. Прибыльным он не стал, и поэтому строительство кластеров не развивалось до г., когда DEC построила свой VAXcluster на основе операционной системы HP Alpha и 1994, класс HA) и г. это ПО для объединения компьютеров в виртуальный суперкомпьютер открыло возможность мгновенного создания кластеров. В результате суммарная производительность всех созданных тогда дешёвых кластеров обогнала по производительности сумму мощностей «серьёзных» коммерческих систем.

Создание кластеров на основе дешёвых персональных компьютеров, объединённых сетью передачи данных, продолжилось в г. силами Американского аэрокосмического агентства (NASA), затем в г. получили развитие кластеры Beowulf , специально разработанные на основе этого принципа. Успехи таких систем подтолкнули развитие grid-сетей , которые существовали ещё с момента создания

Программные средства

Широко распространённым средством для организации межсерверного взаимодействия является библиотека MPI , поддерживающая языки и Fortran . Она используется, например, в программе моделирования погоды MM5 .

Компанией Windows. Он создан на основе технологии, выкупленной у Digital Equipment Corporation , поддерживает до 8 узлов в кластере, а также работу в сети SAN . Набор API-интерфейсов служит для поддержки распределяемых приложений, есть заготовки для работы с программами, не предусматривающими работы в кластере.

См. также

Ссылки

Вычислительный кластер Киевского национального университета им. Т. Г. Шевченка
Высокопроизводительные вычисления на Nvidia GPU, проект Tesla

Wikimedia Foundation . 2010 .

Вершина современной инженерной мысли - сервер 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 позволяет организовать кластерный рендеринг даже без привлечения каких-либо сторонних пакетов и библиотек. Достаточно установить его на несколько компьютеров локальной сети и настроить сервер и несколько клиентов].

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

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

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

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

По разным оценкам, 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, который позволит на ПК проверить стратегию миграции приложений между узлами.

Заключение

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

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

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

Что такое вычислительный кластер?

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

Подробнее о том, как устроен и работает вычислительный кластер можно почитать в книге А.Лациса "Как построить и использовать суперкомпьютер" .

Как запускаются программы на кластере?

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

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

Какая установлена операционная система?

Вычислительный кластер, как правило, работает под управлением одной из разновидностей ОС Unix - многопользовательской многозадачной сетевой операционной системы. В частности, в НИВЦ МГУ кластеры работают под управлением ОС Linux - свободно распространяемого варианта Unix. Unix имеет ряд отличий от Windows, которая обычно работает на персональных компьютерах, в частности эти отличие касаются интерфейса с пользователем, работы с процессами и файловой системы.

Более подробно об особенностях и командах ОС UNIX можно почитать здесь:

Инсталляция Linux и первые шаги (книга Matt Welsh, перевод на русский язык А.Соловьева).
Операционная система UNIX (информационно-аналитические материалы на сервере CIT-Forum).

Как хранятся данные пользователей?

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

Какие используются компиляторы?

Никаких специализированных параллельных компиляторов для кластеров не существует. Используются обычные оптимизирующие компиляторы с языков Си и Фортран - GNU, Intel или другие, умеющие создавать исполняемые программы ОС Linux. Как правило, для компиляции параллельных MPI-программ используются специальные скрипты (mpicc, mpif77, mpif90 и др.), которые являются надстройками над имеющимися компиляторами и позволяют подключать необходимые библиотеки.

Как использовать возможности кластера?

Существует несколько способов задействовать вычислительные мощности кластера.

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

2. Запускать готовые параллельные программы. Для некоторых задач доступны бесплатные или коммерческие параллельные программы, которые при необходимости Вы можете использовать на кластере. Как правило, для этого достаточно, чтобы программа была доступна в исходных текстах, реализована с использованием интерфейса MPI на языках С/C++ или Фортран. Примеры свободно распространяемых параллельных программ, реализованных с помощью MPI: GAMESS-US (квантовая химия), POVRay-MPI (трассировка лучей).

3. Вызывать в своих программах параллельные библиотеки. Также для некоторых областей, таких как линейная алгебра, доступны библиотеки, которые позволяют решать широкий круг стандартных подзадач с использованием возможностей параллельной обработки. Если обращение к таким подзадачам составляет большую часть вычислительных операций программы, то использование такой параллельной библиотеки позволит получить параллельную программу практически без написания собственного параллельного кода. Примером такой библиотеки является SCALAPACK. Русскоязычное руководство по использованию этой библиотеки и примеры можно найти на сервере по численному анализу НИВЦ МГУ. Также доступна параллельная библиотека FFTW для вычисления быстрых преобразований Фурье (БПФ). Информацию о других параллельных библиотеках и программах, реализованных с помощью MPI, можно найти по адресу http://www-unix.mcs.anl.gov/mpi/libraries.html .

4. Создавать собственные параллельные программы. Это наиболее трудоемкий, но и наиболее универсальный способ. Существует два основных варианта. 1) Вставлять параллельные конструкции в имеющиеся параллельные программы. 2) Создавать "с нуля" параллельную программу.

Как работают параллельные программы на кластере?

Параллельные программы на вычислительном кластере работают в модели передачи сообщений (message passing). Это значит, что программа состоит из множества процессов, каждый из которых работает на своем процессоре и имеет свое адресное пространство. Причем непосредственный доступ к памяти другого процесса невозможен, а обмен данными между процессами происходит с помощью операций приема и посылки сообщений. То есть процесс, который должен получить данные, вызывает операцию Receive (принять сообщение), и указывает, от какого именно процесса он должен получить данные, а процесс, который должен передать данные другому, вызывает операцию Send (послать сообщение) и указывает, какому именно процессу нужно передать эти данные. Эта модель реализована с помощью стандартного интерфейса MPI. Существует несколько реализаций MPI, в том числе бесплатные и коммерческие, переносимые и ориентированные на конкретную коммуникационную сеть.

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

Лекция 5. Технологии параллельного программирования. Message Passing Interface .
Вычислительный практикум по технологии MPI (А.С.Антонов).
А.С.Антонов .
MPI: The Complete Reference (на англ.яз.).
Глава 8: Message Passing Interface в книге Яна Фостера "Designing and Building Parallel Programs" (на англ.яз.).

Где можно посмотреть примеры параллельных программ?

Схематичные примеры MPI-программ можно посмотреть здесь:

Курс Вл.В.Воеводина "Параллельная обработка данных". Приложение к лекции 5 .
Примеры из пособия А.С.Антонова "Параллельное программирование с использованием технологии MPI" .

Можно ли отлаживать параллельные программы на персональном компьютере?

Разработка MPI-программ и проверка функциональности возможна на обычном ПК. Можно запускать несколько MPI-процессов на однопроцессорном компьютере и таким образом проверять работоспособность программы. Желательно, чтобы это был ПК с ОС Linux, где можно установить пакет MPICH . Это возможно и на компьютере с Windows, но более затруднительно.

Насколько трудоемко программировать вычислительные алгоритмы c помощью MPI и есть ли альтернативы?

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

Как ускорить проведение вычислений на кластере?

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

1. Подбор опций оптимизации компилятора. Подробнее об опциях компиляторов можно почитать здесь:

Компиляторы Intel C++ и Fortran (русскоязычная страница на нашем сайте).

2. Использование оптимизированных библиотек. Если некоторые стандартные действия, такие как умножение матриц, занимают значительную долю времени работы программы, то имеет смысл использовать готовые оптимизированные процедуры, выполняющие эти действия, а не программировать их самостоятельно. Для выполнения операций линейной алгебры над матричными и векторными величинами была разработана библиотека BLAS ("базовые процедуры линейной алгебры"). Интерфейс вызова этих процедур стал уже фактически стандартом и сейчас существуют несколько хорошо оптимизированных и адаптированных к процессорным архитектурам реализаций этой библиотеки. Одной из таких реализаций является свободно распространяемая библиотека , которая при установке настраивается с учетом особенностей процессора. Компания Интел предлагает библиотеку MKL - оптимизированную реализацию BLAS для процессоров Intel и SMP-компьютеров на их основе. статья про подбор опций MKL.

Подробнее о библиотеках линейной алгебры (BLAS) можно почитать здесь:

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

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

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

6. Использование наиболее подходящих типов данных. Например, в некоторых случаях вместо 64-разрядных чисел с плавающей точкой двойной точности (double) может быть целесообразным использовать 32-разрядные числа одинарной точности (float) или даже целые числа (int).

Более подробно о тонкой оптимизации программ можно почитать в руководстве по оптимизации для процессоров Intel и в других материалах по этой теме на веб-сайте Intel.

Как оценить и улучшить качество распараллеливания?

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

Важным показателем, который говорит о том, эффективно ли в программе реализован параллелизм, является загрузка вычислительных узлов, на которых работает программа. Если загрузка на всех или на части узлов далека от 100% - значит, программа неэффективно использует вычислительные ресурсы, т.е. создает большие накладные расходы на обмены данными или неравномерно распределяет вычисления между процессами. Пользователи НИВЦ МГУ могут посмотреть загрузку через веб-интерфейс для просмотра состояния узлов.

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

Подробнее об улучшении производительности параллельных программ можно почитать в книге В.В.Воеводина и Вл.В.Воеводина