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

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

В качестве узла кластера может выступать как однопроцессорная ВМ, так и ВС типа SMP или МРР. Каждый узел в состоянии функционировать самостоятельно и отдельно от кластера.

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

Архитектура кластерных вычислений сводится к объединению нескольких узлов высокоскоростной сетью. Наряду с термином «кластерные вычисления», часто применяются такие названия, как кластер рабочих станций (workstation cluster), гипервычисления (hypercomputing), параллельные вычисления на базе сети (network-based concurrent computing).

Перед кластерами ставятся две задачи:

  • достичь большой вычислительной мощности;
  • обеспечить повышенную надежность ВС.

Первый коммерческий кластер создан корпорацией «DEC» в начале 80-х гг. прошлого века. В качестве узлов кластеров могут использоваться как одинаковые ВС (гомогенные кластеры), так и разные (гетерогенные кластеры). По своей архитектуре кластерная ВС является слабосвязанной системой.

Преимущества, достигаемые с помощью кластеризации:

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

ВМ, при этом его стоимость будет ниже, чем у одиночной ВМ

с эквивалентной вычислительной мощностью.

На уровне аппаратного обеспечения кластер - это просто совокупность независимых вычислительных систем, объединенных сетью. При соединении машин в кластер почти всегда поддерживаются прямые межмашинные связи. Решения могут быть простыми, основывающимися на аппаратуре Ethernet, или сложными с высокоскоростными сетями с пропускной способностью в сотни мегабайт в секунду (система /?5/6000 SP компании «1ВМ», системы фирмы «Digital» на основе Memory Channel, ServerNet корпорации «Compaq»).

Узлы кластера контролируют работоспособность друг друга и обмениваются специфической информацией. Контроль работоспособности осуществляется с помощью специального сигнала, называемого heartbeat («сердцебиение»). Этот сигнал передается узлами кластера друг другу, чтобы подтвердить их нормальное функционирование.

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

Узлы вычислительного кластера могут функционировать под управлением разных операционных систем. Однако чаще всего используются стандартные UNIX-подобные системы. Заметим, что с точки зрения разработки прикладных параллельных программ нет каких-либо принципиальных различий между однородными вычислительными кластерами и МРР- системами.

Классификация вычислительных кластеров по типу

узловых процессоров

Вычислительные кластеры классифицируются прежде всего по характеру узловых процессоров (рис. 9.10).

В качестве узлов вычислительного кластера обычно используют персональные компьютеры, рабочие станции и ^МР-серверы. Если в качестве узла кластера используется SMP- система, то такой вычислительный кластер называется *5ЖР-кластером.

Если в качестве узлов вычислительного кластера используются персональные ЭВМ или рабочие станции, то обычной является си-

Рис. 9.10.

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

Классификация вычислительных кластеров по однородности узлов

Как и всякие А//А//)-системы, вычислительные кластеры разделяются на однородные кластерные системы (однородные вычислительные кластеры) и разнородные кластерные системы (гетерогенные вычислительные кластеры).

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

Классификация вычислительных кластеров по функциональности узлов

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

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

При классификации кластеров используется и ряд других классификационных признаков (рис. 9.11).


Рис. 9.11.

  • классификация по стандартности комплектующих;
  • классификация по функциональной направленности. Классификация вычислительных кластеров по стандартности комплектующих. С точки зрения стандартности комплектующих можно выделить два класса кластерных систем:
    • 1) вычислительный кластер строится целиком из стандартных комплектующих;
    • 2) при построении кластера используются эксклюзивные или нешироко распространенные комплектующие.

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

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

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

На высокоскоростные кластерные системы (High Performance) -

ЯР-кластеры;

Кластерные системы высокой готовности (High Availability) - НА-

кластеры.

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

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

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

Разработано множество технологий соединения компьютеров в кластер.

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

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

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

Эффективная производительность кластерных вычислительных систем (real applications performance, RAP) оценивается как 5-15% от их пиковой производительности (Peak Advertised Performance, PAP). Для сравнения: у лучших малопроцессорных систем из векторных процессоров это соотношение оценивается как 30-50%.

Кластерная система

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

Кластер - это совокупность серверов, накопителей и рабочих станций, которые:
· Действуют как одна система;
· Представляются пользователям как одна система;
· Управляются как одна система;
Кластер - это также возможность использовать вычислительные ресурсы Вашей системы так, что полученная система превосходит по своим возможностям суммарные возможности ее частей.

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

Разделение на High Avalibility и High Performance системы

В функциональной классификации кластеры можно разделить на "Высокоскоростные" (High Performance, HP), "Системы Высокой Готовности" (High Availability, HA), а также "Смешанные Системы".
Высокоскоростные кластеры используются для задач, которые требуют значительной вычислительной мощности. Классическими областями, в которых используются подобные системы, являются:
· обработка изображений: рендеринг, распознавание образов
· научные исследования: физика, биоинформатика, биохимия, биофизика
· промышленность (геоинформационные задачи, математическое моделирование)
и много других…
Кластеры, которые относятся к системам высокой готовности, используются везде, где стоимость возможного простоя превышает стоимость затрат, необходимых для построения кластерной системы, например:
· биллинговые системы
· банковские операции
· электронная коммерция
· управление предприятием, и т.п....
Смешанные системы объединяют в себе особенности как первых, так и вторых. Позиционируя их, следует отметить, что кластер, который обладает параметрами как High Performance, так и High Availability, обязательно проиграет в быстродействии системе, ориентированной на высокоскоростные вычисления, и в возможном времени простоя системе, ориентированной на работу в режиме высокой готовности.

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

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

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

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

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

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

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

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

Заключение

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

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

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

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

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

Обозначаются аббревиатурой 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 .