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

Сложилось так, что кластеризация, будучи неотъемлемой частью мэйнфреймовских систем, очень долго искала свой путь к платформе Intel. Корпоративные серверы, изначально предназначенные для работы в одиночестве, а также главные Intel-ориентированные серверные операционные системы Windows NT и Linux оказались не приспособленными к поддержке совместной работы серверов. А между тем надежности отдельно стоящих машин сегодня недостаточно для поддержки работы таких приложений, как системы онлайновой обработки транзакций, электронной коммерции, СУБД, хранилища данных и системы документооборота.

Рис. 1. Стандартный кластер с двумя узлами

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

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

Дорогие высоконадежные вычислительные системы - кластеры - обеспечивают надежность 99,999%. Этого уже вполне достаточно, так как простои здесь составляют не более 5 минут в год. Данный тип систем характеризуется повышенными, хотя и оправданными, расходами на поддержку и установку и требует специально обученного персонала. Их нельзя приобрести в готовом исполнении, и предлагаются они как индивидуально настраиваемые решения.

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

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

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

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

Рис. 2. Схема “активный - резервный”

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

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

Рис. 3. Схема “активный - активный”

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

Рис. 4. Схема SMP

Оптимальными сетевыми технологиями соединения серверов и подсистем хранения в кластер считаются интерфейс SCSI и оптоволоконные линии. Сейчас в высокопроизводительных кластерах все большее применение находит Fibre Channel как наиболее производительная и функциональная технология коммуникации.

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

В последнее время наибольшее распространение получила конфигурация “активный - активный”. Два кластера на ее базе были реализованы компанией Trans-Ameritech по заказу МПС. Один из них, установленный в Главном вычислительном центре (ГВЦ), составлен их двух серверов IBM PC Server 325R, соединенных по интерфейсу SCSI и использующих в качестве подсистемы хранения данных RAID-контроллер LynxArray фирмы Artecon.

Второй кластер работает в управлении Белорусского вокзала и состоит из двух IBM Netfinity 5500R и RAID-контроллера Z-9250 производства Digi-Data Corporation.

Оба кластерных решения построены на основе Windows NT с использованием внутренних средств кластеризации Enterprise Edition.

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

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

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

Примером кластерного ПО для Intel-архитектуры является Novell High Availability Server (NHAS) для серверов NetWare. Пожалуй, это одно из самых потенциально широко применимых и дешевых решений для сетей на базе Novell NetWare. NHAS на основе NDS позволяет соединить несколько файл-серверов NetWare в кластер с функциями автоматической реакции на сбои и работы с разделяемыми подсистемами хранения.

Другие известные кластерные продукты для архитектуры Intel выпускают компании Veritas и Compaq; кластерная служба включена и в Windows 2000.

В декабре 1997 г. Compaq, Intel и Microsoft объявили о начале разработки стандарта кластерной архитектуры, основной идеей которого стала возможность объединения в кластеры недорогих массовых серверов. Получивший название Virtual Interface Architecture 1.0, стандарт не зависит от аппаратной, программной и сетевой архитектуры и реализует принцип предоставления пользовательским процессам виртуальных интерфейсов с сетевой средой в кластерной системе. К проекту уже присоединились более ста фирм, в том числе все основные поставщики аппаратных и программных компонентов корпоративных информационных систем, такие, как 3Com, Hewlett-Packard, Oracle и др.

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

Быстрое внедрение ERP Комплексные услуги от 1С:Центр ERP!

Управление доставкой Для торговых и курьерских компаний!

1C:ЭДО Узнайте о всех преимуществах электронного документооборота!

Переход на «1С:ЗУП ред. 3» Фирма «1С» прекращает поддержку «1С:ЗУП 2.5»!

Аренда сервера 1С в облаке Работайте в 1С удаленно с экономией до 70%!

Кластер серверов 1С - построение высоконагруженных систем

Заказать демонстрацию Заказать

В данной статье будут рассмотрены несколько вариантов структуры 1С для высоконагруженных систем (от 200 активных пользователей), построенных на базе клиент-серверной архитектуры – их преимущества и недостатки, стоимость инсталляции и сравнительные тесты производительности каждого варианта.

Мы не будем проводить описание, оценку и сравнение общепринятых и всем давно известных классических схем построения серверной структуры 1С, таких как отдельный сервер 1С и отдельный сервер СУБД, либо кластер Microsoft SQL с кластером 1С. Таких обзоров великое множество, в том числе и проведенных самими производителями программных продуктов. Мы предложим обзор схем построения структуры 1С, которые встречались за последние несколько лет в наших ИТ-проектах для среднего и крупного бизнеса.

Требования к высоконагруженным системам 1С

Высоконагруженные системы 1С, работающие с крупными массивами данных в режиме 24/7/365 подвержены факторам риска, которые в стандартных ситуациях обычно не наблюдаются. Как следствие, для их устранения и упреждения требуется применение особенных схем архитектуры 1С и новых технологий.

Катастрофоустойчивость СУБД. В процессе проектирования архитектуры 1С делается упор на вычислительные мощности и высокую доступность сервисов, выраженную в их кластеризации. Серверы 1С:Предприятие по умолчанию способны работать в дублирующем кластере, а для кластера СУБД обычно применяется промышленная система хранения данных (СХД) и технология кластеризации (к примеру, Microsoft SQL Cluster). Однако, ситуация становится плачевной, когда проблемы случаются с самой СХД (зачастую, по нашему опыту последних лет – это проблемы программного характера). Тогда у ИТ-инженера резко возникают две проблемы – где взять актуальные данные и куда их развернуть в кратчайшие сроки, поскольку система хранения данных с нужным объемом быстрого массива дисков недоступна.

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

При разработке схемы высоконагруженных систем 1С обычно обращают внимание в первую очередь на параметры дисковой системы ввода\вывода, на которой расположены базы данных. Но помимо этого, еще существует активная утилизация ресурсов ЦПУ и потребление ОЗУ сервером 1С. Зачастую именно этого типа ресурсов и не хватает, возможности аппаратной модернизации текущего сервера 1С исчерпываются и требуется добавление новых серверов 1С, работающих с единым сервером СУБД.

Схемы организации кластеров серверов 1С

Схема с кластером 1С-серверов, подсоединенным к кластеру с синхронной репликацией SQL AlwaysOn по протоколу IP. Данная схема является одним из качественных вариантов решения проблемы катастрофоустойчивости базы данных 1С (см. Рисунок 1). Технология кластеризации баз SQL AlwaysOn основана на принципе онлайн-синхронизации таблиц SQL между основным и резервным серверами без вмешательства конечного пользователя. С помощью SQL Listener есть возможность переключиться на резервный сервер SQL в случае выхода из строя основного, что позволяет назвать данную систему полноценным катастрофоустойчивым кластером SQL, благодаря использованию двух независимых серверов SQL. Технология SQL Always On доступна только в версии Microsoft SQL Enterprise.

Рисунок 1 - схема кластера серверов 1С + SQL AlwaysOn

Вторая схема идентична первой, добавлено только шифрование баз SQL на основном и резервном сервере. Мы уже упоминали о том, что работа с последними ИТ-проектами показала, что компании начали гораздо больше внимания уделять вопросу безопасности данных, по различным причинам – требования ФЗ-152, рейдерские захваты серверов, утечка данных в облаке и тому подобное. Так что считаем данный вариант схемы 1С довольно актуальным (см. Рисунок 2).

Рисунок 2 - схема кластера серверов 1С + SQL AlwaysOn с шифрованием

Кластер серверов 1С "active-active", подсоединенный к единственному серверу СУБД по протоколу IP. В противовес потребностям в отказоустойчивости и безопасности – некоторым структурам в первую очередь требуется повышенная производительность, так сказать «вся вычислительная мощь». Поэтому максимальный приоритет отдается увеличению количества вычислительных кластеров сервера 1С, на которые современная платформа 1С позволяет дифференцировать различные типы вычислений и фоновые задания (см. Рисунок 3). Конечно же, комплектация основных ресурсов сервера SQL тоже должна быть на уровне, однако сам сервер баз данных представлен в единственном числе (видимо, расчет идет на своевременное резервное копирование баз).

Рисунок 3 - схема кластера серверов 1С с одним сервером СУБД

Сервер 1С и СУБД на одном аппаратном сервере с SharedMemory. Поскольку наши практические тесты ориентированы на сравнение производительности разных схем, то обязательно требуется некий эталон для сравнения нескольких вариантов (см. Рисунок 4). В качестве эталона, по нашему мнению, нужно взять схему расположения сервера 1С и СУБД на одном аппаратном сервере без виртуализации с взаимодействием по SharedMemory.

Рисунок 4 - схема сервера 1С и СУБД на одном аппаратном сервере с SharedMemory

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

Критерии оценки архитектур 1С	Кластер 1С + SQL AlwaysOn	Кластер 1С + SQL AlwaysOn с шифрованием	Кластер 1С с одним сервером СУБД	Классический 1С+СУБД SharedMemory
Легкость инсталляции и обслуживания	Удовл.	Удовл.	Хорошо	Отлично
Отказоустойчивость	Отлично	Отлично	Удовл.	Не применимо
Безопасность	Удовл.	Отлично	Удовл.	Удовл.
Бюджетность	Удовл.	Удовл.	Хорошо	Отлично

Таблица 1 - сравнение вариантов построения систем 1С

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

Описание методики тестирования

Этап тестирования состоит из двух ключевых инструментов синтетической генерации нагрузки и имитации работы пользователей в 1С. Это тест Гилева (TPC-1C) и «Тест центр» из инструментария 1С: КИП.

Тест Гилева. Тест относится к разделу универсальных интегральных кроссплатформенных тестов. Он может применяться как для файлового, так и для клиент-серверного вариантов 1С:Предприятие. Тест оценивает количество работы в единицу времени в одном потоке и подходит для оценки скорости работы однопоточных нагрузок, включая скорость отрисовки интерфейса, влияния ресурсных затрат на обслуживание виртуальной среды, перепроведения документов, закрытия месяца, расчета зарплаты и т.п. Универсальность позволяет делать обобщенную оценку производительности не привязываясь к конкретной типовой конфигурации платформы. Результатом теста является сводная оценка измеряемой системы 1С, выраженная в условных единицах.

Специализированный «Тест центр» из инструментария 1С: КИП. Тест-центр – инструмент автоматизации многопользовательских нагрузочных испытаний информационных систем на платформе 1С:Предприятие 8. С его помощью можно моделировать работу предприятия без участия реальных пользователей, что позволяет оценивать применимость, производительность и масштабируемость информационной системы в реальных условиях. Используя инструментарий 1С: КИП, на основании процессов и контрольных примеров формируется матрица «Список Объектов макета базы ERP 2.2» для сценария тестирования производительности. В макете базы 1С: ERP 2.2 генерируются обработкой данные по Нормативно-справочной информации (НСИ):

• Несколько тысяч номенклатурных позиций;
• Несколько организаций;
• Несколько тысяч контрагентов.

Тест осуществляется в рамках нескольких групп пользователей. Группа состоит из 4 пользователей, у каждого из которых есть своя роль и перечень последовательных операций. Благодаря гибкому механизму задания параметров для тестирования, можно запускать тест на разное количество пользователей, что позволит оценить поведение системы при различных нагрузках и определить параметры, которые могут привести к снижению показателей производительности. Проводится 3 теста по 3 итерации в которых разработчик 1С запускает тест с эмуляцией работы пользователей и замеряет время выполнения каждой операции. Выполняются замеры всех трех итераций для каждой из схем структуры 1С. Результатом теста является получение среднего времени выполнения операции для каждого документа матрицы.

Показатели «Тест центра» и теста Гилева будут отражены в сводной таблице 2.

Тестовый стенд

Сервер терминального доступа – виртуальная машина, использовалась для управления инструментами тестирования:

• vCPU - 16 ядер 2.6GHz
• RAM - 32 ГБ
• I\o: Intel Sata SSD Raid1

• RAM - 96 ГБ
• I\o: Intel Sata SSD Raid1

Сервер 1С и СУБД - физический сервер

• CPU - Intel Xeon Processor E5-2670 8C 2.6GHz – 2 шт
• RAM - 96 ГБ
• I\o: Intel Sata SSD Raid1
• Роли: Сервер 1С 8.3.8.2137, Сервер MS SQL 2014 SP 2

Выводы

Можем сделать вывод, что по среднему времени выполнения операции наиболее оптимальной является схема №3 «Кластер серверов 1С "active-active", подсоединенный к единственному серверу СУБД по протоколу IP» (см. Таблица 2). Для обеспечения отказоустойчивости такой архитектуры мы рекомендуем строить классический отказоустойчивый кластер MSSQL с размещением базы данных на отдельной СХД.

Важно отметить, что наиболее оптимальное соотношение факторов минимизации простоя, отказоустойчивости и сохранности данных - у схемы №1 «Кластер 1С-серверов, подсоединенный к кластеру с синхронной репликацией SQL AlwaysOn по протоколу IP», при этом падение производительности по отношению к самому производительному варианту составляет примерно 10%.

Как мы видим по результатам тестов, синхронная репликация базы SQL AlwaysOn достаточно негативно влияет на производительность. Объясняется это тем, что система SQL ждет окончания репликации каждой транзакции на резервный сервер, не позволяя работать с базой в это время. Этого можно избежать если настроить асинхронную репликацию между MSSQL серверами, но при таких настройках мы не получим автоматического переключения приложений на резервную ноду в случае сбоя. Переключение придется выполнять вручную.

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

Схема архитектуры 1С

Среднее время выполнения операции, сек

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

В Windows Server 2012 появилось так много новшеств, что за всеми уследить трудно. Часть наиболее важных строительных блоков новой ИТ-инфраструктуры связана с улучшениями в отказоустойчивой кластеризации. Отказоустойчивая кластеризация зародилась как технология для защиты важнейших приложений, необходимых для производственной деятельности, таких как Microsoft SQL Server и Microsoft Exchange. Но впоследствии отказоустойчивая кластеризация превратилась в платформу высокой доступности для ряда служб и приложений Windows. Отказоустойчивая кластеризация - часть фундамента Dynamic Datacenter и таких технологий, как динамическая миграция. Благодаря Server 2012 и усовершенствованиям нового протокола Server Message Block (SMB) 3.0 область действия отказоустойчивой кластеризации стала увеличиваться, обеспечивая непрерывно доступные файловые ресурсы с общим доступом. Обзор функциональности отказоустойчивой кластеризации в Server 2012 приведен в опубликованной в этом же номере журнала статье «Новые возможности отказоустойчивой кластеризации Windows Server 2012».

Обязательные условия отказоустойчивой кластеризации

Для построения двухузлового отказоустойчивого кластера Server 2012 необходимы два компьютера, работающие с версиями Server 2012 Datacenter или Standard. Это могут быть физические компьютеры или виртуальные машины. Кластеры с виртуальными узлами можно построить с помощью Microsoft Hyper-V или VMware vSphere. В данной статье используются два физических сервера, но этапы настройки кластера для физических и виртуальных узлов одни и те же. Ключевая особенность заключается в том, что узлы должны быть настроены одинаково, чтобы резервный узел мог выполнять рабочие нагрузки в случае аварийного переключения или динамической миграции. Компоненты, использованные в тестовом отказоустойчивом кластере Server 2012 представлены на рисунке.

Для отказоустойчивого кластера Server 2012 необходимо общее хранилище данных типа iSCSI, Serially Attached SCSI или Fibre Channel SAN. В нашем примере используется iSCSI SAN. Следует помнить о следующих особенностях хранилищ этого типа.

• Каждый сервер должен располагать по крайней мере тремя сетевыми адаптерами: одним для подключения хранилища iSCSI, одним для связи с узлом кластера и одним для связи с внешней сетью. Если предполагается задействовать кластер для динамической миграции, то полезно иметь четвертый сетевой адаптер. Однако динамическую миграцию можно выполнить и через внешнее сетевое соединение - она просто будет выполняться медленнее. Если серверы используются для виртуализации на основе Hyper-V и консолидации серверов, то нужны дополнительные сетевые адаптеры для передачи сетевого трафика виртуальных машин.
• В быстрых сетях работать всегда лучше, поэтому быстродействие канала связи iSCSI должно быть не менее 1 ГГц.
• Цель iSCSI должна соответствовать спецификации iSCSI-3, в частности обеспечивать постоянное резервирование. Это обязательное требование динамической миграции. Оборудование почти всех поставщиков систем хранения данных соответствует стандарту iSCSI 3. Если нужно организовать кластер в лабораторной среде с небольшими затратами, обязательно убедитесь, что программное обеспечение цели iSCSI соответствует iSCSI 3 и требованиям постоянного резервирования. Старые версии Openfiler не поддерживают этот стандарт, в отличие от новой версии Openfiler с модулем Advanced iSCSI Target Plugin (http://www.openfiler.com/products/advanced-iscsi-plugin). Кроме того, бесплатная версия StarWind iSCSI SAN Free Edition компании StarWind Software (http://www.starwindsoftware.com/starwind-free) полностью совместима с Hyper-V и динамической миграцией. Некоторые версии Microsoft Windows Server также могут функционировать в качестве цели iSCSI, совместимой со стандартами iSCSI 3. В состав Server 2012 входит цель iSCSI. Windows Storage Server 2008 R2 поддерживает программное обеспечение цели iSCSI. Кроме того, можно загрузить программу Microsoft iSCSI Software Target 3.3 (http://www.microsoft.com/en-us/download/details.aspx?id=19867), которая работает с Windows Server 2008 R2.

Дополнительные сведения о настройке хранилища iSCSI для отказоустойчивого кластера приведены во врезке «Пример настройки хранилища iSCSI». Более подробно о требованиях к отказоустойчивой кластеризации рассказано в статье «Failover Clustering Hardware Requirements and Storage Options» (http://technet.microsoft.com/en-us/library/jj612869.aspx).

Добавление функций отказоустойчивой кластеризации

Первый шаг к созданию двухузлового отказоустойчивого кластера Server 2012 - добавление компонента отказоустойчивого кластера с использованием диспетчера сервера. Диспетчер сервера автоматически открывается при регистрации в Server 2012. Чтобы добавить компонент отказоустойчивого кластера, выберите Local Server («Локальный сервер») и прокрутите список вниз до раздела ROLES AND FEATURES. Из раскрывающегося списка TASKS выберите Add Roles and Features, как показано на экране 1. В результате будет запущен мастер добавления ролей и компонентов.

Первой после запуска мастера откроется страница приветствия Before you begin. Нажмите кнопку Next для перехода к странице выбора типа установки, на которой задается вопрос, нужно ли установить компонент на локальном компьютере или в службе Remote Desktop. Для данного примера выберите вариант Role-based or feature-based installation и нажмите кнопку Next.

На странице Select destination server выберите сервер, на котором следует установить функции отказоустойчивого кластера. В моем случае это локальный сервер с именем WS2012-N1. Выбрав локальный сервер, нажмите кнопку Next, чтобы перейти к странице Select server roles. В данном примере роль сервера не устанавливается, поэтому нажмите кнопку Next. Или можно щелкнуть ссылку Features в левом меню.

На странице Select features прокрутите список компонентов до пункта Failover Clustering. Щелкните в поле перед Failover Clustering и увидите диалоговое окно со списком различных компонентов, которые будут установлены как части этого компонента. Как показано на экране 2, по умолчанию мастер установит средства управления отказоустойчивыми кластерами и модуль отказоустойчивого кластера для Windows PowerShell. Нажмите кнопку Add Features, чтобы вернуться на страницу выбора компонентов. Щелкните Next.

На странице Confirm installation selections будет показана функция отказоустойчивого кластера наряду с инструментами управления и модулем PowerShell. С этой страницы можно вернуться и внести любые изменения. При нажатии кнопки Install начнется собственно установка компонентов. После завершения установки работа мастера будет завершена и функция отказоустойчивого кластера появится в разделе ROLES AND FEATURES диспетчера сервера. Этот процесс необходимо выполнить на обоих узлах.

Проверка отказоустойчивого кластера

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

Чтобы открыть диспетчер отказоустойчивого кластера, выберите параметр Failover Cluster Manager в меню Tools в диспетчере сервера. В области Management щелкните ссылку Validate Configuration, как показано на экране 3, чтобы запустить мастер проверки настроек.

Экран 3. Запуск мастера проверки конфигурации

Сначала выводится страница приветствия мастера. Нажмите кнопку Next, чтобы перейти к выбору серверов или странице Cluster. На этой странице введите имена узлов кластера, который необходимо проверить. Я указал WS2012-N1 и WS2012-N2. Нажмите кнопку Next, чтобы показать страницу Testing Options, на которой можно выбрать конкретные наборы тестов или запустить все тесты. По крайней мере в первый раз я рекомендую запустить все тесты. Нажмите кнопку Next, чтобы перейти на страницу подтверждения, на которой показаны выполняемые тесты. Нажмите кнопку Next, чтобы начать процесс тестирования кластера. В ходе тестирования проверяется версия операционной системы, настройки сети и хранилища всех узлов кластера. Сводка результатов отображается после завершения теста.

Если тесты проверки выполнены успешно, можно создать кластер. На экране 4 показан экран сводки для успешно проверенного кластера. Если при проверке обнаружены ошибки, то отчет будет отмечен желтым треугольником (предупреждения) или красным значком "X" в случае серьезных ошибок. С предупреждениями следует ознакомиться, но их можно игнорировать. Серьезные ошибки необходимо исправить перед созданием кластера.

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

На странице Access Point for Administering the Cluster следует указать имя и IP-адрес кластера, которые должны быть уникальными в сети. На экране 7 видно, что имя моего кластера WS2012-CL01, а IP-адрес - 192.168.100.200. При использовании Server 2012 IP-адрес кластера может быть назначен через DHCP, но я предпочитаю для своих серверов статически назначаемый IP-адрес.

После ввода имени и IP-адреса нажмите кнопку Next, чтобы увидеть страницу подтверждения (экран 8). На этой странице можно проверить настройки, сделанные при создании кластера. При необходимости можно вернуться и внести изменения.

После нажатия кнопки Next на странице подтверждения формируется кластер на всех выбранных узлах. На странице хода выполнения показаны шаги мастера в процессе создания нового кластера. По завершении мастер покажет страницу сводки с настройками нового кластера.

Мастер создания кластера автоматически выбирает хранилище для кворума, но часто он выбирает не тот диск кворума, который хотелось бы администратору. Чтобы проверить, какой диск используется для кворума, откройте диспетчер отказоустойчивого кластера и разверните кластер. Затем откройте узел Storage и щелкните узел Disks. Диски, доступные в кластере, будут показаны на панели Disks. Диск, выбранный мастером для кворума кластера, будет указан в разделе Disk Witness in Quorum.

В данном примере для кворума был использован Cluster Disk 4. Его размер 520 Мбайт, чуть больше минимального значения для кворума 512 Мбайт. Если нужно использовать другой диск для кворума кластера, можно изменить настройки кластера, щелкнув правой кнопкой мыши имя кластера в диспетчере отказоустойчивого кластера, выбрав пункт More Actions и Configure Cluster Quorum Settings. В результате появится мастер выбора конфигурации кворума, с помощью которого можно изменить параметры кворума кластера.

Настройка общих томов кластера и роли виртуальных машин

Оба узла в моем кластере имеют роль Hyper-V, так как кластер предназначен для виртуальных машин с высокой доступностью, обеспечивающих динамическую миграцию. Чтобы упростить динамическую миграцию, далее требуется настроить общие тома кластера Cluster Shared Volumes (CSV). В отличие от Server 2008 R2, в Server 2012 общие тома кластера включены по умолчанию. Однако все же требуется указать, какое хранилище следует использовать для общих томов кластера. Чтобы включить CSV на доступном диске, разверните узел Storage и выберите узел Disks. Затем выберите диск кластера, который нужно использовать как CSV, и щелкните ссылку Add to Cluster Shared Volumes на панели Actions диспетчера отказоустойчивого кластера (экран 9). Поле Assigned To этого диска кластера изменится с Available Storage на Cluster Shared Volume (общий том кластера), как показано на экране 9.

В это время диспетчер отказоустойчивого кластера настраивает хранилище диска кластера для CSV, в частности добавляет точку подключения в системном диске. В данном примере общие тома кластера включаются как на Cluster Disk 1, так и на Cluster Disk 3 с добавлением следующих точек подключения:

* C:ClusterStorageVolume1 * C:ClusterStorageVolume2

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

Чтобы добавить новую роль, выберите имя кластера на панели навигации диспетчера отказоустойчивого кластера и щелкните ссылку Configure Roles на панели Actions, чтобы запустить мастер высокой готовности. Нажмите кнопку Next на странице приветствия, чтобы перейти на страницу выбора роли. Прокрутите список ролей, пока не увидите роль виртуальной машины, как показано на экране 10. Выберите роль и нажмите кнопку Next.

На странице выбора виртуальной машины будут перечислены все VM на всех узлах кластера, как показано на экране 11. Прокрутите список и выберите виртуальные машины, которым необходимо обеспечить высокую готовность. Нажмите кнопку Next. Подтвердив свой выбор, нажмите Next, чтобы добавить роли виртуальной машины в диспетчер отказоустойчивого кластера.

Пример настройки хранилища iSCSI

Для отказоустойчивого кластера Windows Server 2012 требуется общее хранилище, которое может быть типа iSCSI, Serially Attached SCSI или Fibre Channel SAN. В данном отказоустойчивом кластере используется Channel SAN.

Сначала в сети iSCSI SAN были созданы три логических устройства LUN. Один LUN был создан для диска кворума кластера (520 Мбайт). Другой LUN предназначен для 10 виртуальных машин и имеет размер 375 Гбайт. Третий LUN выделен для небольшой тестовой виртуальной машины. Все три LUN представлены в формате NTFS.

После того, как были созданы LUN, была выполнена настройка iSCSI Initiator на обоих узлах Server 2012. Чтобы добавить цели iSCSI, был выбран iSCSI Initiator в меню Tools в диспетчере сервера. На вкладке Discovery я нажал кнопку Discover Portal. В результате появилось диалоговое окно Discover Portal, куда были введены IP-адрес (192.168.0.1) и порт iSCSI (3260) сети SAN.

Затем я перешел на вкладку Targets и нажал кнопку Connect. В диалоговом окне Connect To Target («Подключение к целевому серверу») я ввел целевое имя iSCSI SAN. Оно было получено из свойств SAN. Имя зависит от поставщика SAN, имени домена и имен созданных LUN. Помимо целевого имени я установил режим Add this connection to the list of Favorite Targets.

По завершении настройки iSCSI эти LUN появились на вкладке Targets iSCSI Initiator. Чтобы автоматически подключать LUN при запуске Server 2012, я убедился, что они перечислены на вкладке Favorite Targets, как показано на экране A.

Экран A. Настройка iSCSI Initiator

Наконец, были назначены буквенные обозначения устройствам LUN с помощью оснастки Disk Management консоли управления Microsoft (MMC). Я выбрал Q для диска кворума и W для диска, используемого для виртуальных машин и общих томов кластера (CSV). При назначении буквенных обозначений необходимо сначала назначить их на одном узле. Затем нужно перевести диски в автономный режим и сделать аналогичные назначения на втором узле. Результаты назначения букв дискам для одного узла приведены на экране B. При создании кластера диски будут показаны как доступное хранилище.

17.06.1997 Элизабет Кларк

Кто сказал, что меньше - лучше? Когда речь идет об объединении серверов, цифры говорят сами за себя. ТЬМА - ЗНАЧИТ МНОГО ПЛОТНОСТЬ НАСЕЛЕНИЯ НОВОЕ ПЛЕМЯ РАСЧИЩАЯ ПУТЬ ВЫЖИВАНИЕ НАИБОЛЕЕ ПРИСПОСОБЛЕННЫХ СЕКРЕТНОЕ ОРУЖИЕ

Кто сказал, что меньше - лучше? Когда речь идет об объединении серверов, цифры говорят сами за себя.

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

ТЬМА - ЗНАЧИТ МНОГО

Сначала в кластеры объединяли мэйнфреймы, затем мини-компьютеры, а теперь серверы на базе операционной системы Unix и процессоров Intel. Компания Tandem была среди первых, кто занялся кластеризацией: она начала выпускать серверы NonStop Himalaya еще двадцать лет назад. За это время Digital Equipment изобрела кластеризацию систем VAX под ОС VMS. IBM была также в числе первопроходцев со своим кластерным оборудованием для систем AIX и мэйнфреймов.

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

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

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

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

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

Несмотря на то что каждая из этих архитектур имеет свои достоинства, настоящая кластеризация существует только в средах с разделяемыми дисками и без разделения ресурсов (см. Рисунок 1).

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

Тенденция к кластеризации обусловлена целым рядом причин. Одна из них в том, что старое правило 80/20, утверждающее, что 80% сетевого трафика является локальным и лишь 20% передается по магистрали, больше не действует. С увеличением объемов трафика, передаваемого все дальше и дальше от места его возникновения, серверные фермы, или группы кластеризованных серверов, подключенных к высокоскоростным магистралям, становятся все более искусными в обслуживании этих изменившихся схем трафика.

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

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

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

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

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

ТАБЛИЦА 1 - ПРОЦЕНТ СИСТЕМ ВЫСОКОЙ ГОТОВНОСТИ В СЕВЕРНОЙ АМЕРИКЕ

Источник: Dataquest

ПЛОТНОСТЬ НАСЕЛЕНИЯ

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

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

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

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

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

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

"Кластеризация - пока еще недостаточно зрелая технология, - говорит Джо Баркан, директор по исследованиям в Gartner Group. - Если целью является масштабируемость, то сначала лучше попробовать масштабировать систему с помощью SMP. К следующему году NT должна стать гораздо более надежной по части постоянно доступных приложений и сервисов. В отношении масштабируемости картина отличается радикальным образом, причем изменится она не так скоро. Даже если говорить о масштабируемости Unix, сегодня в первую очередь я бы все же порекомендовал именно крупные системы SMP".

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

Кроме того, своего разрешения требуют и некоторые вопросы управления кластером. Вот что говорит по этому поводу Стив Трамак, менеджер по продуктам в отделе персональных компьютеров Digital Equipment, отвечающий за кластеризацию Windows NT: "Когда организация решает создать кластер, она ожидает, что он будет управляемым - не только в смысле определения групп взаимозаменяемых серверов и специфичных для кластера событий, но также, например, в смысле оповещения в случае сбоя". А значит, управление на базе SNMP просто необходимо.

Еще одно препятствие на пути кластеризации - управление одновременным доступом к файлам. Эта проблема может быть разрешена с помощью распределенного блокиратора (Distributed Lock Manager, DLM) для координации доступа различных приложений к файлам. Сервис DLM выполняет свою задачу посредством отслеживания ссылок на ресурсы в кластере. Если две или более системы пытаются получить доступ к одному и тому же ресурсу одновременно, DLM разрешает конфликт между ними.

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

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

НОВОЕ ПЛЕМЯ

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

Наиболее известный кластерный продукт - Wolfpack for Windows NT компании Microsoft с его комплектом программ и API для кластеризации серверов Windows NT. Microsoft планирует представить Wolfpack в два этапа. Первый этап должен был завершиться летом этого года; он состоит в реализации кластеризации двух серверов с возможностями подмены одного сервера другим. Второй этап, реализовать который Microsoft намеревается в 1998 году, должен воплотить в жизнь распределение нагрузки и кластеризацию до 16 узлов.

Такие поставщики, как Compaq, Digital Equipment, Hewlett-Packard, IBM, Tandem и NCR, разрабатывают совместимые с Wolfpack кластерные продукты самостоятельно. Amdahl, Siemens, Fujitsu и Stratus собираются взяться за свои планы разработки уже в этом году. При такой поддержке Wolfpack наверняка станет стандартом де факто.

Несмотря на то что на первом этапе Wolfpack будет обеспечивать кластеризацию только двух серверов, по глубокому убеждению Баркана из Gartner Group, Microsoft уже смотрит вперед, отчасти по практическим соображениям: "Мы обратили внимание на то, что Microsoft начинает позиционировать Wolfpack как решение старшего класса, - говорит он. - Они не готовы поддерживать сотни тысяч крошечных кластеров Wolfpack по всему миру".

Wolfpack имеет уже значительное влияние на рынок постоянно доступных серверов, в том числе и в области цен. "До недавнего времени, если вам нужна была постоянная доступность вашего кластера, то надо было тратить огромные деньги, - замечает Баркан. - По нашим оценкам, в случае кластеров Unix заказчик тратит в среднем около 50 000 долларов за профессиональные услуги по запуску, эксплуатации и тестированию системы. NT снижает стоимость кластера, по крайней мере потенциально, до приемлемого уровня. И это сделала Microsoft со своим Wolfpack".

Как же на это реагируют другие игроки на рынке кластеризации? Digital Clusters for Windows NT появились на сцене в 1996 году, и, кроме того, Digital представила свои Unix TruCluster Solutions. Последний продукт позволяет осуществлять кластеризацию как серверов AlphaServer самой компании, так и других серверов разных размеров.

Другая заметная фигура в истории кластеризации, Tandem, внесла свою лепту в виде серверов NonStop Himalaya на базе массовых параллельных систем. Некоторые части технологии Wolfpack компании Microsoft базируются на коде, который Tandem использовала в своих системах Himalaya.

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

Тим Кифавр, менеджер по кластерным продуктам в подразделении систем для Windows NT компании Tandem, говорит, что, когда начнутся поставки Wolfpack, Tandem будет предлагать активную/активную динамическую библиотеку SQL Server 6.5. (В данном контексте "активная/активная" означает систему, в которой оба узла в кластере могут выполнять транзакции SQL Server одновременно.)

Технология кластеризации компании Sun Microsystems под названием Full Moon станет отличным дополнением к таким продуктам Sun Clusters, как Solstice HA и Ultra Enterprise PDB (Parallel Database). Этот подход предполагается реализовать в четыре этапа. Первый этап, начало которому положено весной 1997 года, состоял во включении кластерных API, функций восстановления после аварий и усовершенствованного доступа в Internet посредством Solstice HA 1.3.

Технология NetWare SFT (System Fault Tolerance) компании Novell появилась достаточно давно. С помощью SFT пользователи могут зеркально копировать содержимое основного системного диска на запасной. Относительно новая версия SFT III позволяет дуплексировать целые серверы, обеспечивая подмену без перерыва в работе. По заявлениям компании, она собирается добавить новые возможности в SFT III в этом году.

"Мы не называем SFT III технологией кластеризации, хотя, по моему мнению, у нас есть на это все основания, - говорит Майкл Брайант, директор по маркетингу Wolf Mountain, инициативы Novell в области кластеризации. - Novell не собирается придавать новый смысл кластеризации. Мы придерживаемся классического определения и переносим его на серверы на базе ПК". Во время написания статьи Novell еще не объявила о дате выхода Wolf Mountain.

Подходя к кластеризации с разных сторон, IBM представила в прошлом году свое решение Cluster Internet PowerSolution for AIX. Весьма любопытно, что компания объявила также о

планах переноса своей технологии кластеризации Phoenix на платформу Windows NT. Ожидаемый продукт IBM под названием HACMP (High-Availability Cluster Multiprocessing) Geo должен позволить создавать постоянно готовые кластеры из удаленных мест.

NetServer представляет базовую кластерную платформу Hewlett-Packard. Компания может извлечь значительную выгоду из своих усилий по интеграции Wolfpack с системой управления OpenView.

Среди других компаний, которые имеют (или разрабатывают в настоящее время) решения по кластеризации, - NCR, Compaq, SCO, Data General и Stratus.

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

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

Примерами кластерного промежуточного программного обеспечения могут служить Parallel Server компании Oracle и ServerWare компании Tandem. Microsoft объявила, что она собирает-ся предложить кластерную версию SQL Server и других приложений BackOffice; независимые поставщики также намереваются предложить кластерные приложения.

РАСЧИЩАЯ ПУТЬ

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

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

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

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

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

Использование нескольких хост-адаптеров SCSI часто способствует значительному повышению производительности. Быстрые диски также способны помочь ускорить работу сервера, однако здесь, с точки зрения цена/производительность, отдача весьма невелика. Кроме того, обычный интерфейс SCSI может поддерживать только определенное число дисков. Современные интерфейсы, такие как SCSI-3, Ultra SCSI и Fibre Channel, имеют более высокую пропускную способность, чем SCSI-2.

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

На примере серверов Web прекрасно видно, какую нагрузку современные приложения возлагают на ЦПУ. Хотя простое обслуживание страниц Web не сопряжено само по себе с интенсивными операциями ввода/вывода, другие функции, такие как шифрование и дешифрование, могут потребовать всех ресурсов ЦПУ.

Архитектура интеллектуального ввода/вывода (Intelligent I/O) призвана разрешить проблему истощения вычислительной мощности ЦПУ. В модели I2O драйверы разделены на две группы: одна - для обслуживания операционной системы, а другая - для обслуживания аппаратных устройств. I2O освобождает ЦПУ, память и системную шину от большей части операций по обслуживанию ввода/вывода и возлагает их на саму подсистему ввода/вывода. Целый ряд компаний объединили свои усилия по стандартизации архитектуры I2O. (Дополнительную информацию см. во врезке , а также на узле www.I2O.org .)

Компания Wind River Systems разработала операционную систему реального времени IxWorks на базе модели с раздельными драйверами. ОС, являющаяся частью среды разработки I2O под названием Tornado, предполагает написание только одного драйвера для каждого аппаратного устройства, при этом один и тот же драйвер пригоден для всех сетевых ОС.

Особого внимания заслуживают усилия по стандартизации архитектуры виртуального интерфейса Virtual Interface Architecture. Участниками данной инициативы являются Compaq, HP, Intel, Microsoft, Novell, Santa Cruz Operation и Tandem. Целью этой инициативы является определение стандартов на аппаратные и программные интерфейсы для кластеров. Данные интерфейсы разрабатываются для упрощения процесса синхронизации, поддержки коммуникаций с разделяемыми массивами дисков и коммуникаций между серверами. Спецификация будет независима от среды передачи, процессоров и сетевой операционной системы.

"Архитектура VI описывает, как этот [аппаратный и программный] коммуникационный канал будет работать, - говорит Марк Вуд, менеджер по продуктам в команде Windows NT Server компании Microsoft. - Как только все согласятся на бумаге, как она должна работать, любой поставщик сможет проектировать совместимое аппаратное и программное обеспечение".

Генри из Tandem также полагает, что архитектура VI будет немало способствовать развитию кластеризации. Эта инициатива громогласно призывает: "Давайте облегчим программистам разработку программного обеспечения для кластеров", - говорит Генри.

Однако далеко не все относятся с тем же энтузиазмом к архитектуре VI. "Мы ничего хорошего от нее не ждем, - заявляет Ричардсон из Meta Group. - Microsoft просто собирается придать статус стандарта своим, ею же выбранным для среды NT, API, а другие поставщики систем будут вынуждены подстраиваться под них или идти на риск выпуска нестандартных расширений".

ВЫЖИВАНИЕ НАИБОЛЕЕ ПРИСПОСОБЛЕННЫХ

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

"Дайте срок, и кластеризация станет базовой составляющей операционной системы, - полагает Баркан из Gartner Group. - Через пять лет любая операционная система на рынке будет иметь базовые кластерные сервисы".

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

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

Однако Баркан предостерегает от поспешных действий: "Главное - не следует торопиться. Кластеризация постепенно становится фактом нашей жизни, но параметры масштабируемости, по сути, неизвестны и непроверены".

Ричардсон из Meta Group согласен с этим мнением. "Мы приветствуем кластеры как средство повышения доступности приложений, - говорит он. - Но, думается, как решение проблемы масштабируемости приложений кластеры чересчур сложны и неэффективны".

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

Элизабет Кларк - старший редактор Network Magazine. С ней можно связаться по адресу: [email protected] .

СЕКРЕТНОЕ ОРУЖИЕ КЛАСТЕРНЫХ ТЕХНОЛОГИЙ

Переход к коммутации

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

Одной из разработок в этой области - ServerNet компании Tandem. Продукт имеет коммутирующую структуру на базе интегральных схем ASIC: она-то и позволяет создавать масштабируемую архитектуру кластерной среды. "Интегральная схема ASIC не только является многонаправленным коммутатором, но и содержит всю логику маршрутизации, логику проверки ошибок, логику сообщений об ошибках и логику обеспечения правильной последовательности пакетов", - говорит Джим Генри, директор по разработкам для бизнеса в подразделении ServerNet компании Tandem. По мнению Джима, несколько коммутаторов ServerNet могут составлять каскад, в результате чего заказчик получит очень крупную коммутирующую сеть или структуру, к которой он может подключить и серверы Windows NT, и массивы RAID.

Однако это далеко не единственная технология коммутации для кластеризации серверов. Например, SilkWorm компании Brocade Communications Systems представляет собой гигабитный коммутатор Fibre Channel с числом портов от 2 до 16 со встроенным программным обеспечением для создания структуры Fibre Channel (архитектуры межсоединения узлов в кластере). Система эта создавалась для ликвидации узких мест в каналах к дисковым подсистемам серверов. SilkWorm имеет сервис для идентификации подключенных к структуре узлов, причем он распространяет информацию об их местоположении и характеристиках другим коммутаторам в структуре.

Постоянно доступная система PowerSwitch/NT компании Apcon базируется на SCSI Switch. До 16 серверов может быть объединено в одну группу и подключено к общему дисковому массиву и другой периферии. При обнаружении сбоя сервера другой сервер автоматически подключается через SCSI Switch к внутренним дисководам и периферии вышедшего из строя сервера.

ДВУСТУПЕНЧАТЫЕ ДРАЙВЕРЫ УСТРОЙСТВ ОБЛЕГЧАЮТ ВВОД/ВЫВОД

Разделение ради объединения

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

"Требования к вводу/выводу многократно возросли, в частности, в связи с появлением Internet, - объясняет Паулин Шульман, менеджер по продуктам в Wind River Systems. Эта компания разработала операционную систему на базе архитектуры интеллектуального ввода/вывода (Intelligent I/O, I2O) с раздельными драйверами. - Но возможности ввода/вывода значительно отстают от этих требований".

Если Intelligent I/O Special Interest Group претворит в жизнь свои усилия, то разрыв между требованиями и возможностями будет ликвидирован уже в ближайшем будущем. Данная организация предложила недавно спецификацию на базе архитектуры I2O. В принятой модели с разделением драйверов ЦПУ память и системная шина освобождены от выполнения некоторых функций.

Формально группа приняла версию 1.5 спецификации в марте 1997 года. Эта версия поддерживает одноранговую технологию, с помощью которой устройства ввода/вывода могут общаться друг с другом непосредственно без участия ЦПУ и независимо от сетевой операционной системы.

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

Microsoft объявила о своих планах включения I2O в Windows NT 5.0, а Novell также заявила о намерении реализовать эту технологию в своих продуктах.

В настоящее время о совместимости своих продуктов с I2O заявляют такие компании, как Xpoint Technologies, разработавшая решение на базе I2O для ускорения обмена данными между дисковой и локально-сетевой подсистемами, а также NetFrame, чей постоянно доступный сервер ClusterSystem 9000 (NF9000) на базе Pentium Pro совместим с Windows NT и IntranetWare. Кроме того, в этот список может быть включена и компания American Megatrends, создатель предназначенных для кластеров комплектов RAID на материнской плате для производителей серверов.

MTBF (Mean Time Between Failure) — среднее время наработки на отказ.
MTTR (Mean Time To Repair) — среднее время восстановления работоспособности.

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

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

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

Принципиальная схема кластера высокой готовности приведена на рисунке:

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

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

На обоих узлах кластера устанавливается операционная система Microsoft Windows Server 2003 Enterprise, которая поддерживает технологию Microsoft Windows Cluster Service (MSCS).

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

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

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

Если приложения работают только на одном узле, а другой узел используется в качестве резерва, то при отказе "рабочего" узла производительность кластера не изменится (при условии, что запасной узел не "слабее").

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

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

Сравнение кластера высокой готовности с обычным сервером

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

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

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

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

Производители компьютерных компонентов, как правило, определяют их надежность на основании испытаний партии изделий по следующей формуле:

Например, если тестировалось 100 изделий в течение года и 10 из них вышло из строя, то MTBF, вычисленное по этой формуле, будет равно 10 годам. Т.е. предполагается, что через 10 лет все изделия выйдут из строя.

Отсюда можно сделать следующие важные выводы. Во-первых, такая методика расчета MTBF предполагает, что число отказов в единицу времени постоянно на протяжении всего срока эксплуатации. В "реальной" жизни это, конечно, не так. На самом деле, из теории надежности известно, что кривая отказов имеет следующий вид:

В зоне I проявляются отказы изделий, имеющие дефекты изготовления. В III зоне начинают сказываться усталостные изменения. В зоне II отказы вызываются случайными факторами и их число постоянно в единицу времени. Изготовители компонентов, "распространяют" эту зону на весь срок эксплуатации. Реальная статистика отказов на протяжение всего срока эксплуатации подтверждает, что эта теоретическая модель вполне близка к действительности.

Второй интересный вывод заключается в том, что понятие MTBF отражает совсем не то, что очевидно следует из его названия. "Среднее время наработки на отказ" в буквальном смысле означает время, составляющее только половину MTBF. Так, в нашем примере это "среднее время" будет не 10 лет, а пять, поскольку в среднем все экземпляры изделия проработают не 10 лет, а вполовину меньше. Т.е. MTBF, заявляемый производителем - это время, в течение которого изделие выйдет из строя с вероятностью 100%.

Итак, поскольку вероятность выхода компонента из строя на протяжении MTBF равна 1, и если MTBF измерять в годах, то вероятность выхода компонента из строя в течение одного года составит:

P =	1
	MTBF

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

Отказ дублированного компонента приведет к отказу сервера только при условии, что компонент-дублер тоже выйдет из строя в течение времени, необходимого для "горячей" замены компонента, отказавшего первым. Если гарантированное время замены компонента составляет 24 часа (1/365 года) (что соответствует сложившейся практике обслуживания серверного оборудования), то вероятность такого события в течение года:

Pd =	P x P	x 2
	365

Пояснения к формуле.

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

Случай (1)

1. Выход из строя компонента №1 в любой момент времени в течение года (вероятность P)
2. Выход из строя компонента №2 в течение 24 часов после выхода компонента №1 (вероятность P/365)

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

Для случая (2), когда сначала откажет компонент №2, а затем компонент №1, вероятность будет такой же.

Поскольку случаи (1) и (2) не могут произойти одновременно, вероятность наступления того или другого случая равна сумме их вероятностей.

Теперь, зная вероятность Pi отказа каждого из N компонентов (дублированных и недублированных) сервера, можно рассчитать вероятность отказа сервера в течение одного года.

Выполним расчет следующим образом.

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

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

Pi" = 1 - Pi

Вероятность безотказной работы всех компонентов в течение года равна произведению вероятностей этих независимых событий:

Ps’ = ∏ Pi"

Тогда вероятность выхода сервера из строя в течение года

Теперь можно определить коэффициент готовности:

Ks =	MTBFs
	MTBFs + MTTRs

Перейдем к расчету. Пусть наш сервер состоит из следующих компонентов:

Рисунок 1. Состав сервера

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

Компоненты сервера	Заявленная надежность			Количество компонентов в сервере	Вероятность отказа с учетом дублирования
	MTBF (часов)	MTBF (лет)	Вероятность отказа в те- чение года
Блок питания	90 000	10,27	0,09733	2	0,0000519
Системная плата	300 000	34,25	0,02920	1	0,0292000
Процессор №1	1 000 000	114,16	0,00876	1	0,0087600
Процессор №2	1 000 000	114,16	0,00876	1	0,0087600
RAM, модуль №1	1 000 000	114,16	0,00876	1	0,0087600
RAM, модуль №2	1 000 000	114,16	0,00876	1	0,0087600
Жесткий диск	400 000	45,66	0,02190	2	0,0000026
Вентилятор №1	100 000	11,42	0,08760	2	0,0000420
Вентилятор №2	100 000	11,42	0,08760	2	0,0000420
Контроллер HDD	300 000	34,25	0,02920	1	0,0292000
Плата сопряжения	300 000	34,25	0,02920	1	0,0292000
Ленточный накопитель	220 000	25,11	0,03982	1	0,0398182
Для сервера в целом:			0,37664		0,1519961

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

Выполним аналогичный расчет для кластера.

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

Предположим, что в качестве узла кластера используется рассмотренный нами сервер с коэффициентом готовности K = 99,958%, а время восстановления работоспособности узла - 24 часа.

Рассчитаем параметры надежности внешнего дискового массива:

Компоненты массива	Заявленная надежность			Кол-во компо- нентов в массиве	Вероятность отказа с учетом дублирования
	MTBF (часов)	MTBF (лет)	Вероятность отказа в те- чение года
Блок питания	90 000	10,27	0,09733	2	0,0000519
Жесткий диск	400 000	45,66	0,02190	2	0,0000026
Вентилятор	100 000	11,42	0,08760	2	0,0000420
Контроллер HDD	300 000	34,25	0,02920	2	0,0000047
Для массива в целом:			0,21797		0,0001013

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