Современные кластерные системы и их использование. Средства реализации High Availability кластеров. Кластерные проекты в России

Высокопроизводительный кластер (группа компьютеров)

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

Главные свойства кластеров

Кластеры состоят из нескольких компьютерных систем;

Они работают как одна вычислительная система (не все);

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

Зачем нужны кластеры

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

Какие бывают кластеры

Отказоустойчивые кластеры

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

Данные кластера могут быть построены по трём основным принципам

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

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

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

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

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

Не забываем оставлять

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

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

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

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

Несомненно, основной характеристикой в кластере является отказоустойчивость. Это подтверждает и опрос пользователей: 95% опрошенных ответили, что в кластерах им необходимы надежность и отказоустойчивость. Однако не следует смешивать эти два понятия. Под отказоустойчивостью понимается доступность тех или иных функций в случае сбоя, другими словами, это резервирование функций и распределение нагрузки. А под надежностью понимается набор средств обеспечения защиты от сбоев. Такие требования к надежности и отказоустойчивости кластерных систем обусловлены спецификой их использования. Приведем небольшой пример. Кластер обслуживает систему электронных платежей, поэтому если клиент в какой-то момент останется без обслуживания для компании-оператора, это ему будет дорого стоить. Другими словами, система должна работать в непрерывном режиме 24 часа в сутки и семь дней в неделю (7Ѕ24). При этом отказоустойчивости в 99% явно не достаточно, так как это означает, что почти четыре дня в году информационная система предприятия или оператора будет неработоспособной. Это может показаться не таким уж и большим сроком, учитывая профилактические работы и техническое обслуживание системы. Но сегодняшнему клиенту абсолютно безразличны причины, по которым система не работает. Ему нужны услуги. Итак, приемлемой цифрой для отказоустойчивости становится 99,999%, что эквивалентно 5 минутам в год. Таких показателей позволяет достичь сама архитектура кластера. Приведем пример серверного кластера: каждый сервер в кластере остается относительно независимым, то есть его можно остановить и выключить (например, для проведения профилактических работ или установки дополнительного оборудования), не нарушая работоспособность кластера в целом. Тесное взаимодействие серверов, образующих кластер (узлов кластера), гарантирует максимальную производительность и минимальное время простоя приложений за счет того, что:l в случае сбоя программного обеспечения на одном узле приложение продолжает функционировать (либо автоматически перезапускается) на других узлах кластера;l сбой или отказ узла (или узлов) кластера по любой причине (включая ошибки персонала) не означает выхода из строя кластера в целом;l профилактические и ремонтные работы, реконфигурацию и смену версий программного обеспечения в большинстве случаев можно осуществлять на узлах кластера поочередно, не прерывая работу приложений на других узлах кластера.Возможные простои, которые не в состоянии предотвратить обычные системы, в кластере оборачиваются либо некоторым снижением производительности (если узлы выключаются из работы), либо существенным сокращением (приложения недоступны только на короткий промежуток времени, необходимый для переключения на другой узел), что позволяет обеспечить уровень готовности в 99,99%.

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

Высокая стоимость кластерных систем обусловлена их сложностью. Поэтому масштабируемость кластера довольно актуальна. Ведь компьютеры, производительность которых удовлетворяет сегодняшние требования, не обязательно будет удовлетворять их и в будущем. Практически при любом ресурсе в системе рано или поздно приходится сталкиваться с проблемой производительности. В этом случае возможно два варианта масштабирования: горизонтальное и вертикальное. Большинство компьютерных систем допускают несколько способов повышения их производительности: добавление памяти, увеличение числа процессоров в многопроцессорных системах или добавление новых адаптеров или дисков. Такое масштабирование называется вертикальным и позволяет временно улучшить производительность системы. Однако в системе будет установлено максимальное поддерживаемое количество памяти, процессоров или дисков, системные ресурсы будут исчерпаны. И пользователь столкнется с той же проблемой улучшения характеристик компьютерной системы, что и ранее.Горизонтальное масштабирование предоставляет возможность добавлять в систему дополнительные компьютеры и распределять работу между ними. Таким образом, производительность новой системы в целом выходит за пределы предыдущей. Естественным ограничением такой системы будет программное обеспечение, которые вы решите на ней запускать. Самым простым примером использования такой системы является распределение различных приложений между разными компонентами системы. Например, вы можете переместить ваши офисные приложения на один кластерный узел приложения для Web на другой, корпоративные базы данных - на третий. Однако здесь возникает вопрос взаимодействия этих приложений между собой. И в этом случае масштабируемость обычно ограничивается данными, используемыми в приложениях. Различным приложениям, требующим доступ к одним и тем же данным, необходим способ, обеспечивающий доступ к данным с различных узлов такой системы. Решением в этом случае становятся технологии, которые, собственно, и делают кластер кластером, а не системой соединенных вместе машин. При этом, естественно, остается возможность вертикального масштабирования кластерной системы. Таким образом, за счет вертикального и горизонтального масштабирования кластерная модель обеспечивает серьезную защиту инвестиций потребителей.В качестве варианта горизонтального масштабирования стоит также отметить использование группы компьютеров, соединенных через коммутатор, распределяющий нагрузку (технология Load Balancing). Об этом довольно популярном варианте мы подробно расскажем в следующей статье. Здесь мы лишь отметим невысокую стоимость такого решения, в основном слагаемую из цены коммутатора (6 тыс. долл. и выше - в зависимости от функционального оснащения) и хост-адаптер (порядка нескольких сот долларов за каждый; хотя, конечно, можно использовать и обыкновенные сетевые карты). Такие решения находят основное применение на Web-узлах с высоким трафиком, где один сервер не справляется с обработкой всех поступающих запросов. Возможность распределения нагрузки между серверными узлами такой системы позволяет создавать на многих серверах единый Web-узел.

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

Часто решения, похожие на вышеописанные, носят названия Beowulf-кластера. Такие системы прежде всего рассчитаны на максимальную вычислительную мощность. Поэтому дополнительные системы повышения надежности и отказоустойчивости просто не предусматриваются. Такое решение отличается чрезвычайно привлекательной ценой, и, наверное, поэтому наибольшую популярность приобрело во многих образовательных и научно-исследовательских организациях. Проект Beowulf появился в 1994 году - возникла идея создавать параллельные вычислительные системы (кластеры) из общедоступных компьютеров на базе Intel и недорогих Ethernet-сетей, устанавливая на эти компьютеры Linux и одну из бесплатно распространяемых коммуникационных библиотек (PVM, а затем MPI). Оказалось, что на многих классах задач и при достаточном числе узлов такие системы дают производительность, сравнимую с суперкомпьютерной. Как показывает практика, построить такую систему довольно просто. Все, что для этого нужно, это высокопроизводительный коммутатор и несколько подсоединенных к нему рабочих станций (серверов) с установленной операционной системой Linux. Однако этого недостаточно. Для того чтобы эта груда железа ожила, необходимо специальное программное обеспечение для параллельных вычислений.Наиболее распространенным интерфейсом параллельного программирования в модели передачи сообщений является MPI (Message Passing Interface). Название «Интерфейс передачи сообщений» говорит само за себя. Это хорошо стандартизованный механизм для построения параллельных программ в модели обмена сообщениями. Существуют бесплатные (!) и коммерческие реализации почти для всех суперкомпьютерных платформ, а также для сетей рабочих станций UNIX и Windows NT. В настоящее время MPI - наиболее широко используемый и динамично развивающийся интерфейс своего класса. Рекомендуемая бесплатная реализация MPI - пакет MPICH, разработанный в Аргоннской Национальной Лаборатории. Стандартизацией MPI занимается MPI Forum. Последняя версия стандарта - 2.0. В этой версии к MPI добавлены такие важные функции, как динамическое управление процессами, односторонние коммуникации (Put/Get), параллельный ввод-вывод.Постоянный спрос на высокие вычислительные мощности обусловил появление привлекательного для многих производителей рынка. Некоторые из них разработали собственные технологии соединения компьютеров в кластер. Наиболее известные из них - Myrinet производства MyriCom и cLAN фирмы Giganet. Myrinet является открытым стандартом. Для его реализации MyriCom предлагает широкий выбор сетевого оборудования по сравнительно невысоким ценам. На физическом уровне поддерживаются сетевые среды SAN (System Area Network), LAN (CL-2) и оптоволокно. Технология Myrinet дает высокие возможности масштабирования сети и в настоящее время очень широко используется при построении высокопроизводительных кластеров. Giganet занимается разработкой программных и аппаратных средств для непосредственного взаимодействия центральных процессорных устройств серверов кластера на гигабитных скоростях, минуя функции ОС. Стоимость решения составляет: около 2500 долл. - за 8-портовый коммутатор, 150 долл. - за адаптер для Myrinet, около 6250 долл. - за 8-портовый коммутатор и 800 долл. - за адаптер для Giganet. Последняя, кстати, получила на выставке Microsoft Tech Ed 2000 премию «Best of Show». В качестве примера приведем реализацию Beowulf-кластера в Институте высокопроизводительных вычислений и баз данных Министерства науки и технической политики РФ. Кластер, получивший название «ПАРИТЕТ», создан на базе общедоступных комплектующих для персональных компьютеров и рабочих станций и обеспечивает суммарную пиковую производительность 3,2 GFLOP/sec. Кластер состоит из четырех двухпроцессорных вычислительных узлов, на базе процессоров Intel Pentium II/450MHz. На каждом узле установлена оперативная память объемом 512 Мбайт и 10-гигабайтный жесткий диск на интерфейсе Ultra Wide SCSI. Вычислительные узлы кластера объединены высокопроизводительным коммутатором Myrinet (каналы с пропускной способностью 1,28 Гбайт/с, полный дуплекс). Имеется также резервная сеть, используемая для управления и конфигурирования (100 Mbit Fast Ethernet). На узлах вычислительного кластера установлена операционная система Linux (дистрибутив Red Hat 5,2). Для программирования параллельных приложений используются интерфейсы передачи сообщений MPI/PVM.

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

Помимо коммутаторного решения для построения кластера существует еще целый ряд решений - как аппаратных, так и программных. Некоторые решения являются комплексными и поставляются «As is» - «все в одной коробке». Последний вариант - назовем его «кластер в коробке» - также является довольно популярным решением, поскольку рассчитан на массовый рынок и является кластером начального уровня (по производительности и параметрам масштабирования). Однако построение таких систем, взаимосвязь внутренних компонентов, надежность и отказоустойчивость полностью соответствуют «большим» системам. Для того чтобы разобраться, как устроен кластер, рассмотрим две похожие системы производства - Compaq и Dell. Кластеры от этих известных игроков компьютерного рынка построены из двух серверов DELL - PowerEdge 6100 либо PowerEdge 4200 и, в свою очередь, Compaq - Proliant 1850R. В качестве программного обеспечения используется Microsoft Cluster Server (Compaq, Dell) или Novell High-Availability Services for NetWare 4.0 / Clustering Services for NetWare 5.0 (Compaq). Программное обеспечение позволяет сконфигурировать два сервера таким образом, что, если в одном из серверов кластера происходит сбой, выполняемая им работа и приложения будут сразу же автоматически перенесены на другой сервер, что позволяет устранить простои. Оба сервера кластера предоставляют свои ресурсы для выполнения производственной работы, поэтому ни один из них не простаивает зря в ожидании, пока другой не выйдет из строя.Представленная на рисунке конфигурация является типичным кластером с реализацией принципа безотказности, обеспечивающим высокую степень работоспособности и дублирования компонентов на системном уровне. Связь между двумя серверами осуществляется по так называемому пульсирующему соединению (Heartbeat) выделенного участка локальной сети. При возникновении сбоя на основном сервере второй сервер, следящий за поступающими по пульсирующему соединению сообщениями, узнает об отключении основного сервера и перекладывает на себя рабочую нагрузку, выполнявшуюся вышедшей из строя машиной. В число выполняемых функций входит запуск прикладных программ, процессов и обслуживания, требуемых для ответа на запросы клиентов на предоставление доступа к вышедшему из строя серверу. Хотя каждый из серверов кластера должен иметь все ресурсы, требуемые для возложения на себя функций другого сервера, основные выполняемые обязанности могут быть абсолютно разными. Вторичный сервер, входящий в кластер с реализацией принципа безотказности, отвечает требованию предоставления возможности «горячего» резервирования, но помимо этого он может выполнять и свои собственные приложения. Однако, несмотря на массовое дублирование ресурсов, у такого кластера есть «узкое» место (bottle neck) - интерфейс шины SCSI и разделяемой системы внешней памяти, выход которых из строя влечет за собой сбой кластера. Хотя, по утверждениям производителей, вероятность этого ничтожно мала.Такие мини-кластеры прежде всего рассчитаны на автономную работу без постоянного контроля и администрирования. В качестве примера использования можно привести решение для удаленных офисов больших компаний для обеспечения высокой готовности (7Ѕ24) наиболее ответственных приложений (баз данных, почтовых систем и т.д.). С учетом повышения спроса на мощные и в то же время отказоустойчивые системы начального уровня рынок для этих кластеров выглядит довольно благоприятным. Единственное «но» в том, что не каждый потенциальный потребитель кластерных систем готов выложить за двухсерверную систему около 20 тыс. долл.

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

В качестве резюме следует отметить, что у кластеров наконец-то появился массовый рынок. Такой вывод легко можно сделать исходя из прогнозов аналитиков Standish Group International, которые утверждают, что в следующие два года общемировой рост количества установленных кластерных систем составит 160%. Кроме того, аналитики из IDC подсчитали, что объем рынка кластеров в 1997 году составлял всего 85 млн. долл., а в прошлом году этот рынок «стоил» уже 367,7 млн. долл. Тенденция роста налицо. И действительно, потребность в кластерных решениях сегодня возникает не только в крупных центрах обработки данных, но и в небольших компаниях, которые не хотят жить по принципу «скупой платит дважды» и вкладывают свои деньги в высоконадежные и легкомасштабируемые кластерные системы. Благо, что вариантов реализации кластера более чем достаточно. Однако при выборе какого-либо решения не следует забывать, что все параметры кластера взаимозависимы. Другими словами, нужно четко определить приоритеты на необходимые функциональные возможности кластера, поскольку при увеличении производительности уменьшается степень готовности (доступность). Увеличение производительности и обеспечение требуемого уровня готовности неизбежно ведет к росту стоимости решения. Таким образом, пользователю необходимо сделать самое важное - найти золотую середину возможностей кластера на текущий момент. Это сделать тем труднее, чем больше разнообразных решений предлагается сегодня на рынке кластеров.При подготовке статьи использованы материалы WWW-серверов: http://www.dell.ru/ , http://www.compaq.ru/ , http://www.ibm.ru/ , http://www.parallel.ru/ , http://www.giganet.com/ , http://www.myri.com/

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

Blue Gene /L и семейства SGI Altix.

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

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

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

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

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

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

Рис. 1.1.

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

Рис. 1.2.

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

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

Рис. 1.3.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Что лучше

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

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

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

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

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

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

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

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

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

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

Заключение

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

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

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

Потребность в написании этой статьи возникла после прочитанного семинара на выставке ENTEREX’2002 в городе Киеве. Именно тогда, в начале 2002-го я увидел, что интерес к теме кластерных систем значительно возрос по сравнению с тем, что наблюдалось всего пару лет назад.

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

Концепция кластерных систем

Рисунок 1. Кластерная система

• LAN - Local Area Network, локальная сеть
• SAN - Storage Area Network, сеть хранения данных

Впервые в классификации вычислительных систем термин "кластер" определила компания Digital Equipment Corporation (DEC).

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

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

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

К общим требованиям, предъявляемым к кластерным системам, относятся:

1. Высокая готовность
2. Высокое быстродействие
3. Масштабирование
4. Общий доступ к ресурсам
5. Удобство обслуживания

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

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

Рисунок 2. Тесно связанная мультипроцессорная система

Рисунок 3. Умеренно связанная мультипроцессорная система

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

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

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

В функциональной классификации кластеры можно разделить на "Высокоскоростные" (High Performance, HP), "Системы Высокой Готовности" (High Availability, HA), а также "Смешанные Системы".

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

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

и много других…

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

• биллинговые системы
• банковские операции
• электронная коммерция
• управление предприятием, и т.п….

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

Проблематика High Performance кластеров

Рисунок 5. Высокоскоростной кластер

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

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

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

Быстродействие интерфейсов характеризуется двумя параметрами: пропускной способностью непрерывного потока даных и максимальным количеством самых маленьких пакетов, которые можно передать за единицу времени. Варианты реализаций коммуникационных интерфейсов мы рассмотрим в разделе «Средства реализации High Performance кластеров».

Проблематика High Availability кластерных систем

Сегодня в мире распространены несколько типов систем высокой готовности. Среди них кластерная система является воплощением технологий, которые обеспечивают высокий уровень отказоустойчивости при самой низкой стоимости. Отказоустойчивость кластера обеспечивается дублированием всех жизненно важных компонент. Максимально отказоустойчивая система должна не иметь ни единой точки, то есть активного элемента, отказ которого может привести к потере функциональности системы. Такую характеристику как правило называют - NSPF (No Single Point of Failure, - англ., отсутствие единой точки отказа).

Рисунок 6. Кластерная система с отсутствием точек отказов

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

Для того, чтобы система обладала высокими показатели готовности, необходимо:

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

Пренебрежение любым из указанных параметров, может привести к потере функциональности системы.

Давайте коротко пройдемся по всем трём пунктам.

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

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

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

Смешанные архитектуры

Рисунок 7. Высокоскоростной отказоустойчивый кластер

Сегодня часто можно встретить смешанные кластерные архитектуры, которые одновременно являются как системами высокой готовности, так и высокоскоростными кластерными архитектурами, в которых прикладные задачи распределяются по узлам системы. Наличие отказоустойчивого комплекса, увеличение быстродействия которого осуществляется путем добавления нового узла, считается самым оптимальным решением при построении вычислительной системы. Но сама схема построения таких смешанных кластерных архитектур приводит к необходимости объединения большого количества дорогих компонент для обеспечения высокого быстродействия и резервирования одновременно. И так как в High Performance кластерной системе наиболее дорогим компонентом является система высокоскоростных коммуникаций, ее дублирование приведет к значительным финансовым затратам. Следует отметить, что системы высокой готовности часто используются для OLTP задач, которые оптимально функционируют на симметричных мультипроцессорных системах. Реализации таких кластерных систем часто ограничиваются 2-х узловыми вариантами, ориентированными в первую очередь на обеспечение высокой готовности. Но в последнее время использование недорогих систем количеством более двух в качестве компонент для построения смешанных HA/HP кластерных систем становится популярным решением.

Что подтверждает, в частности, информация агентства The Register, опубликованная на его страничке:

"Председатель корпорации Oracle объявил о том, что в ближайшее время три Unіх сервера, на которых работает основная масса бизнес-приложений компании, будут заменены на блок серверов на базе процессоров Іntеl под управлением ОС Lіnuх. Ларри Эллисон настаивает на том, что введение поддержки кластеров при работе с приложениями и базами данных снижает затраты и повышает отказоустойчивость."

Средства реализации High Performance кластеров

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

Myrinet, Virtual Interface Architecture (cLAN компании Giganet - одна из первых коммерческих аппаратных реализаций), SCI (Scalable Coherent Interface), QsNet (Quadrics Supercomputers World), Memory Channel (разработка Compaq Computer и Encore Computer Corp), а также хорошо всем известные Fast Ethertnet и Gigabit Ethernet.

Рисунок 8. Скорость передачи непрерывного потока данных

Рисунок 9. Время передачи пакета нулевой длинны

Эти диаграммы (Рис. 8 и 9) дают возможность увидеть быстродействие аппаратных реализаций разных технологий, но следует помнить, что на реальных задачах и при использовании разнообразных аппаратных платформ параметры задержки и скорости передачи данных получаются на 20-40%, а иногда на все 100% хуже, чем максимально возможные.

Например, при использовании библиотек MPI для коммуникационных карточек cLAN и Intel Based серверов с шиной PCI, реальная пропускная способность канала составляет 80-100 MByte/sec, задержка - около 20 мксек.

Одной из проблем, которые возникают при использовании скоростных интерфейсов, например, таких как SCI является то, что архитектура PCI не подходит для работы с высокоскоростными устройствами такого типа. Но если перепроектировать PCI Bridge с ориентацией на одно устройство передачи данных, то эта проблема решается. Такие реализации имеют место в решениях некоторых производителей, например, компании SUN Microsystems.

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

Таблица 1. Сравнение высокоскоростных коммуникационных интерфейсов

Технология	Пропускная способность MByte/s	Задержка мксек/пакет	Стоимость карточки/свича на 8 портов	Поддержка платформ	Комментарий
Fast Ethertnet	12.5	158	50/200	Linux, UNIX, Windows	Низкие цены, популярная
Gigabit Ethernet	125	33	150/3500	Linux, UNIX, Windows	Удобство модернизации
Myrinet	245	6	1500/5000	Linux, UNIX, Windows	Открытый стандарт, популярная
VI (сLAN от Giganet)	150	8	800/6500	Linux, Windows	Первая аппаратная промышленная реализация VI
SCI	400	1.5	1200/5000 *	Linux, UNIX, Windows	Стандартизирована, широко используется
QsNet	340	2	N/A **	True64 UNIX	AlphaServer SC и системы Quadrics
Memory Channel	100	3	N/A	True64 UNIX	Используется в Compaq AlphaServer

* аппаратура SCI (и программное обеспечение поддержки) допускает построение так называемых MASH топологий без использования коммутаторов

** нет данных

Рисунок 10. Тесно связанная мультипроцессорная система с несимметричным доступом к памяти

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

Средства распараллеливания

Существует несколько разных подходов к программированию параллельных вычислительных систем:

• на стандартных широко распространенных языках программирования с использованием коммуникационных библиотек и интерфейсов для организации межпроцессорного взаимодействия (PVM, MPI, HPVM, MPL, OpenMP, ShMem)
• использование специализированных языков параллельного программирования и параллельных расширений (параллельные реализации Fortran и C/C++, ADA, Modula-3)
• использование средств автоматического и полуавтоматического распараллеливания последовательных программ (BERT 77, FORGE, KAP, PIPS, VAST)
• программирование на стандартных языках с использованием параллельных процедур из специализированных библиотек, которые ориентированы на решение задач в конкретных областях, например: линейной алгебры, методов Монте-Карло, генетических алгоритмов, обработки изображений, молекулярной химии, и т.п. (ATLAS, DOUG, GALOPPS, NAMD, ScaLAPACK).

Существует также немало инструментальных средств, которые упрощают проектирование параллельных программ. Например:

• CODE - Графическая система для создания параллельных программ. Параллельная программа изображается в виде графа, вершины которого есть последовательные части программы. Для передачи сообщений используются PVM и MPI библиотеки.
• TRAPPER - Коммерческий продукт немецкой компании Genias. Графическая среда программирования, которая содержит компоненты построения параллельного программного обеспечения.

По опыту пользователей высокоскоростных кластерных систем, наиболее эффективно работают программы, специально написанные с учетом необходимости межпроцессорного взаимодействия. И даже несмотря на то, что программировать на пакетах, которые используют shared memory interface или средства автоматического распараллеливания, значительно удобней, больше всего распространены сегодня библиотеки MPI и PVM.

Учитывая массовою популярность MPI (The Message Passing Interface), хочется немного о нём рассказать.

"Интерфейс передачи сообщений" - это стандарт, который используется для построения параллельных программ и использует модель обмена сообщениями. Существуют реализации MPI для языка C/C++ и Fortran как в бесплатных, так и коммерческих вариантах для большинства распространенных суперкомпьютерных платформ, в том числе High Performance кластерных систем, построенных на узлах с ОС Unix, Linux и Windows. За стандартизацию MPI отвечает MPI Forum (). В новой версии стандарта 2.0 описано большое число новых интересных механизмов и процедур для организации функционирования параллельных программ: динамическое управление процессами, односторонние коммуникации (Put/Get), параллельные I/O. Но к сожалению, пока нет полных готовых реализаций этой версии стандарта, хотя часть из нововведений уже активно используется.

Для оценки функциональности MPI, хочу представить вашему вниманию график зависимости времени вычисления задачи решения систем линейных уравнений в зависимости от количества задействованных процессоров в кластере. Кластер построен на процессорах Intel и системе межузловых соединений SCI (Scalable Coherent Interface). Естественно, задача частная, и не надо понимать полученные результаты как общую модель прогнозирования быстродействия желаемой системы.

Рисунок 11. Зависимость времени вычисления задачи решения систем линейных уравнений в зависимости от количества задействованных процессоров в кластере

На графике отображены две кривые, синяя - линейное ускорение и красная - полученное в результате эксперимента. То есть, в результате использования каждой новой ноды мы получаем ускорение выше, чем линейное. Автор эксперимента утверждает, что такие результаты получаются из-за более эффективного использования кэш памяти, что вполне логично и объяснимо. Если у кого возникнут мысли и идеи по этому поводу, буду благодарен, если вы ими поделитесь (мой e-mail: [email protected]).

Средства реализации High Availability кластеров

High Availability кластеры можно распределить на:

• Shared Nothing Architecture (архитектура без разделения ресурсов)
• Shared Disk Architecture (архитектура с общими дисками)

Рисунок 12. Архитектура без разделения ресурсов

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

Рисунок 13. Архитектура с общими дисками

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

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

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

Рисунок 14. Гетерогенная кластерная система

Самыми популярными коммерческими системами сегодня являются двухузловые отказоустойчивые кластеры. Различают Активный-Активный (Active-Active) и Активный-Пассивный (Active-Passive) модели реализации отказоустойчивых кластерных систем в отношении распределения програмных ресурсов.

Рисунок 15. Модель Активный-Активный

В модели Активный-Активный мы практически получаем вместе с отказоустойчивым решением - решение высокоскоростное, так как одна задача работает на нескольких серверах одновременно. Такой вариант реализован, например, в Oracle Prallel Server, MS SQL 2000, IBM DB2. То есть, реализация такой модели возможна лишь в случае написания прикладного программного обеспечения с ориентацией на функционирование в кластерном режиме (исключение составляют кластерные системы с разделением оперативной памяти). В модели Активный-Активный возможно масштабирование скорости работы задачи путем добавления нового узла, если конечно программным обеспечением поддерживается необходимое количество нод. Например, Oracle Parallel Server 8.0.5 поддерживает работу на кластере от 2-х до 6-ти узлов.

Рисунок 16. Активный-Активный кластер на 3-х узлах

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

Рисунок 17. Модель Активный-Пассивный

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

Рисунок 18. Псевдо Активный-Активный кластер на 3-х узлах

Если вам нужно обеспечить отказоустойчивую работу нескольких программных ресурсов, то достаточно добавить в систему новый узел и запустить на кластере нужные вам задачи, которые в случае отказа этого узла перейдут на выполнение на другом узле. Такая модель реализована в программном обеспечении ReliantHA для ОС Caldera OpenUnix и Unixware, которое поддерживает кластеризацию от 2-х к 4-х узлам, в MSCS (Microsoft Cluster Service) и Linux Failover Cluster модели.

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

Если используется простейшая 2-х узловая модель, то доступ к дискам может быть построен через их прямое подключение к общей SCSI шине,

Рисунок 19. Архитектура с общей SCSI шиной

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

Рисунок 20. Вариант с использованием SCSI to SCSI дисковой подсистемы

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

В последнее время начинает приобретать популярность новый последовательный интерфейс для протокола SCSI - FC (Fibre Channel). На базе FC строятся так называемые сети хранения данных - SAN (Storage Area Network).

Рисунок 21. Кластерная система с использованием SAN на базе Fibre Channel

К основным преимуществам Fibre Channel можно отнести практически все его особенности.

• Высокие скорости передачи данных
• Протоколо-независимость (0-3 уровни)
• Большие расстояния между точками
• Низкие задержки при передаче коротких пакетов
• Высокая надежность передачи данных
• Практически неограниченное масштабирование
• Многоточечные топологии

Эти замечательные особенности Fibre Channel получил благодоря тому, что в его проектировании принимали участие специалисты в областях как канальных, так и сетевых интерфейсов, причем им удалось объединить в одном FC интерфейсе положительные черты обоих.

Для понимания значимости FC я приведу сравнительную табличку FC и параллельного SCSI интерфейса.

Таблица 2. Таблица сравнительных характеристик FC и параллельного SCSI интерфейса

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

Существует еще один очень интересный вариант реализации кластерной архитектуры - кластерная система с разделяемой памятью (в т.ч. оперативной) Shared Memory Cluster. Фактически этот кластер может функционировать как в модели умеренно связанной многопроцессорной системы, так и тесно связанной. Такая система, как уже говорилось в начале статьи, называется NUMA.

Рисунок 22. Модель кластера с разделяемой памятью

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

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

Рисунок 23. Сравнение среднего времени простоя различных систем

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

Как видим, кластерные системы высокой готовности не являются панацеей при минимизации простоев. Если простой системы является чрезвычайно критичным, тогда следует использовать системы класса Fault Tolerant или Continuous Availability, системы такого класса имеют коэффициент готовности на порядок выше, чем системы класса High Availability.

Примеры проверенных решений

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

Сперва о высокоскоростных кластерах.

Одним из наиболее полезных, на мой взгляд, примеров является то, что первые места, да и вообще большинство мест 18-й редакции списка самых мощных суперкомпьютеров мира занимают системы IBM SP2 и Compaq AlphaServer SC. Обе системы являются массивно-параллельными вычислительными системами (MPP), которые структурно аналогичны High Performance кластерным решениям.

В IBM SP2 в качестве узлов используются машины RS/6000, соединенные коммутатором SP Switch2. Пропускная способность коммутатора - 500MB/s в одном направлении, величина задержки - 2.5 мксек.

Compaq AlphaServer SC. Узлы - 4-х процессорные системы типа Compaq AlphaServer ES45, соединенные с помощью коммуникационного интерфейса QsNet, параметры которого упоминались выше.

В том же суперкомпьютерном списке находятся машины, построенные на обычных Intel платформах и коммутаторах SCI и Myrinet и даже обычном Fast и Gigabit Ethernet. Причем как в первых двух вариантах, так и на высокоскоростных кластерных системах, построенных на рядовом оборудовании, для програмирования используются пакеты MPI.

Ну и напоследок хочется привести красивый пример масштабируемой кластерной системы высокой готовности. Аппаратная модель кластерного решения для отказоустойчивой высокоскоростной обработки базы данных IBM DB/2.

Рисунок 24. Кластер IBM DB2

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

Литература

• "Sizing Up Parallel Architectures", - Greg Pfister, старший технический специалист компании IBM.
• "Возможна ли отказоустойчивость для Windows?", - Наталья Пирогова, материалы издательства «Открытые системы».
• "Использование систем распараллеливания задач в слабосвязанном кластере", - М.Н.Иванов.
• "Отказоустойчивые компьютеры компании Stratus", - Виктор Шнитман, материалы издательства «Открытые системы».
• "Современные высокопроизводительные компьютеры", - В. Шнитман, информационно-аналитические материалы Центра Информационных Технологий.
• "Шаг к сетям хранения данных", информационно-аналитические материалы компании ЮСТАР.
• "Эволюция архитектуры виртуального интерфейса", - Торстен фон Айкен, Вернер Фогельс, материалы издательства «Открытые системы».
• Материалы Лаборатории Параллельных Информационных Технологий "НИВЦ МГУ".
• Материалы Cluster Computing Info Centre.
• Материалы SCI Europe.
• Материалы VI Forum (Virtual Architecture Developers Forum).
• Материалы компании Caldera.
• Материалы компании Dolphinics.
• Материалы компании Emulex.
• Материалы компании KAI Software, a Division of Intel Americas, Inc. (KAI).
• Материалы компании Myricom, Inc.
• Материалы компании Oracle.
• Рекомендации технической поддержки корпорации Intel.