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

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

По прогнозам аналитиков 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 и др.

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

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

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

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

В данном материале мы будем рассматривать наиболее простую конфигурацию отказоустойчивого кластера, состоящего из двух узлов (нод) SRV12R2-NODE1 и SRV12R2-NODE2, каждый из которых работает под управлением Windows Server 2012 R2. Обязательным условием для этих серверов является применение процессоров одного производителя, только Intel или только AMD, в противном случае миграция виртуальных машин между узлами будет невозможна. Каждый узел должен быть подключен к двум сетям: сети предприятия LAN и сети хранения данных SAN.

Вторым обязательным условием для создания кластера является наличие развернутой Active Directory, в нашей схеме она представлена контроллером домена SRV12R2-DC1.

Хранилище выполнено по технологии iSCSI и может быть реализовано на любой подходящей платформе, в данном случае это еще один сервер на Windows Server 2012 R2 - SRV12R2-STOR. Сервер хранилища может быть подключен к сети предприятия и являться членом домена, но это необязательное условие. Пропускная способность сети хранения данных должна быть не ниже 1 Гбит/с.

Будем считать, что на оба узла уже установлена операционная система, они введены в домен и сетевые подключения настроены. Откроем Мастер добавления ролей и компонентов и добавим роль Hyper-V .

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

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

Миграцию виртуальных машин оставляем выключенной .

Остальные параметры оставляем без изменения. Установка роли Hyper-V потребует перезагрузку, после чего аналогичным образом настраиваем второй узел.

Затем перейдем к серверу хранилища, как настроить iSCSI-хранилище на базе Windows Server 2012 мы рассказывали в , но это непринципиально, вы можете использовать любой сервер цели iSCSI. Для нормальной работы кластера нам потребуется создать минимум два виртуальных диска: диск свидетеля кворума и диск для хранения виртуальных машин. Диск-свидетель - это служебный ресурс кластера, в рамках данной статьи мы не будем касаться его роли и механизма работы, для него достаточно выделить минимальный размер, в нашем случае 1ГБ.

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

И сопоставьте данной цели созданные виртуальные диски.

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

Подключенные диски инициализируем и форматируем.

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

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

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

В настройках мастера добавим настроенные нами узлы и выберем выполнение всех тестов.

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

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

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

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

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

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

Затем щелкнем правой кнопкой мыши на объекте кластера в дереве слева и выберем Дополнительные действия - Настроить параметры кворума в кластере .

Далее последовательно выбираем: Выбрать свидетель кворума - Настроить диск-свидетель и указываем созданный для этих целей диск.

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

Для того, чтобы диск мог использоваться сразу несколькими участниками кластера на нем создается CSVFS - реализуемая поверх NTFS кластерная файловая система, впервые появившаяся в Windows Server 2008 R2 и позволяющая использовать такие функции как Динамическая (Живая) миграция, т.е. передачу виртуальной машины между узлами кластера без остановки ее работы.

Общие хранилища становятся доступны на всех узлах кластера в расположении C:\ClusterStorage\VolumeN . Обратите внимание, что это не просто папки на системном диске, а точки монтирования общих томов кластера.

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

На этом настройка кластера закончена. Для работы с кластеризованными виртуальными машинами следует использовать Диспетчер отказоустойчивости кластеров , а не Диспетчер Hyper-V , который предназначен для управления виртуалками расположенными локально.

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

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

После выбора узла откроется стандартный Мастер создания виртуальной машины, работа с ним не представляет сложности, поэтому остановимся только на значимых моментах. В качестве расположения виртуальной машины обязательно укажите один из общих томов кластера C:\ClusterStorage\VolumeN .

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Теги:

Please enable JavaScript to view the

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

Для чего нужен кластер

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

Возможности Win2k3

Вообще говоря, одни кластеры предназначены для повышения доступности данных,
другие — для обеспечения максимальной производительности. В контексте статьи нас
будут интересовать MPP (Massive Parallel Processing) — кластеры, в
которых однотипные приложения выполняются на нескольких компьютерах, обеспечивая
масштабируемость сервисов. Существует несколько технологий, позволяющих
распределять нагрузку между несколькими серверами: перенаправление трафика ,
трансляция адресов , DNS Round Robin , использование специальных
программ , работающих на прикладном уровне, вроде веб-акселераторов. В
Win2k3, в отличие от Win2k, поддержка кластеризации заложена изначально и
поддерживается два типа кластеров, отличающихся приложениями и спецификой
данных:

1. Кластеры NLB (Network Load Balancing) — обеспечивают
масштабируемость и высокую доступность служб и приложений на базе протоколов TCP
и UDP, объединяя в один кластер до 32 серверов с одинаковым набором данных, на
которых выполняются одни и те же приложения. Каждый запрос выполняется как
отдельная транзакция. Применяются для работы с наборами редко изменяющихся
данных, вроде WWW, ISA, службами терминалов и другими подобными сервисами.

2. Кластеры серверов – могут объединять до восьми узлов, их главная
задача — обеспечение доступности приложений при сбое. Состоят из активных и
пассивных узлов. Пассивный узел большую часть времени простаивает, играя роль
резерва основного узла. Для отдельных приложений есть возможность настроить
несколько активных серверов, распределяя нагрузку между ними. Оба узла
подключены к единому хранилищу данных. Кластер серверов используется для работы
с большими объемами часто изменяющихся данных (почтовые, файловые и
SQL-серверы). Причем такой кластер не может состоять из узлов, работающих под
управлением различных вариантов Win2k3: Enterprise или Datacenter (версии Web и
Standart кластеры серверов не поддерживают).

В Microsoft Application Center 2000 (и только) имелся еще один вид
кластера — CLB (Component Load Balancing) , предоставляющий возможность
распределения приложений COM+ между несколькими серверами.

NLB-кластеры

При использовании балансировки нагрузки на каждом из хостов создается
виртуальный сетевой адаптер со своим независимым от реального IP и МАС-адресом.
Этот виртуальный интерфейс представляет кластер как единый узел, клиенты
обращаются к нему именно по виртуальному адресу. Все запросы получаются каждым
узлом кластера, но обрабатываются только одним. На всех узлах запускается
служба балансировки сетевой нагрузки (Network Load Balancing Service) ,
которая, используя специальный алгоритм, не требующий обмена данными между
узлами, принимает решение, нужно ли тому или иному узлу обрабатывать запрос или
нет. Узлы обмениваются heartbeat-сообщениями , показывающими их
доступность. Если хост прекращает выдачу heartbeat или появляется новый узел,
остальные узлы начинают процесс схождения (convergence) , заново
перераспределяя нагрузку. Балансировка может быть реализована в одном из двух
режимов:

1) unicast – одноадресная рассылка, когда вместо физического МАС
используется МАС виртуального адаптера кластера. В этом случае узлы кластера не
могут обмениваться между собой данными, используя МАС-адреса, только через IP
(или второй адаптер, не связанный с кластером);

В пределах одного кластера следует использовать только один из этих режимов.

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

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

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

Настройка NLB-кластера

Для организации NLB-кластеров дополнительное ПО не требуется, все
производится имеющимися средствами Win2k3. Для создания, поддержки и мониторинга
NLB-кластеров используют компонент «Диспетчер балансировки сетевой нагрузки»
(Network Load Balancing Manager) , который находится во вкладке
«Администрирование» «Панели управления» (команда NLBMgr). Так как компонент
«Балансировка нагрузки сети» ставится как стандартный сетевой драйвер Windows,
установку NLB можно выполнять и при помощи компонента «Сетевые подключения», в
котором доступен соответствующий пункт. Но лучше использовать только первый
вариант, одновременное задействование диспетчера NLB и «Сетевых подключений»
может привести к непредсказуемым результатам.

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

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

Теперь вызываем диспетчер NLB. Кластеров у нас пока нет, поэтому появившееся
окно не содержит никакой информации. Выбираем в меню «Кластер» пункт «Новый» и
начинаем заполнять поля в окне «Параметры кластера». В поле «Настройка
IP-параметров кластера» вводим значение виртуального IP-адреса кластера, маску
подсети и полное имя. Значение виртуального МАС-адреса устанавливается
автоматически. Чуть ниже выбираем режим работы кластера: одноадресный или
многоадресный. Обрати внимание на флажок «Разрешить удаленное управление» — во
всех документах Microsoft настоятельно рекомендует его не использовать во
избежание проблем, связанных с безопасностью. Вместо этого следует применять
диспетчер или другие средства удаленного управления, например инструментарий
управления Windows (WMI). Если же решение об его использовании принято, следует
выполнить все надлежащие мероприятия по защите сети, прикрыв дополнительно
брандмауэром UDP-порты 1717 и 2504.

После заполнения всех полей нажимаем «Далее». В окне «IP-адреса кластера» при
необходимости добавляем дополнительные виртуальные IP-адреса, которые будут
использоваться этим кластером. В следующем окне «Правила для портов» можно
задать балансировку нагрузки для одного или для группы портов всех или
выбранного IP по протоколам UDP или TCP, а также блокировать доступ к кластеру
определенным портам (что межсетевой экран не заменяет). По умолчанию кластер
обрабатывает запросы для всех портов (0–65365); лучше этот список ограничить,
внеся в него только действительно необходимые. Хотя, если нет желания возиться,
можно оставить все, как есть. Кстати, в Win2k по умолчанию весь трафик,
направленный к кластеру, обрабатывал только узел, имевший наивысший приоритет,
остальные узлы подключались только при выходе из строя основного.

Например, для IIS потребуется включить только порты 80 (http) и 443 (https).
Причем можно сделать так, чтобы, например, защищенные соединения обрабатывали
только определенные серверы, на которых установлен сертификат. Для добавления
нового правила нажимаем «Добавить», в появившемся диалоговом окне вводим
IP-адрес узла, или если правило распространяется на всех, то оставляем флажок
«Все». В полях «С» и «По» диапазона портов устанавливаем одно и то же значение –
80. Ключевым полем является «Режим фильтрации» (Filtering Mode) — здесь
задается, кем будет обработан этот запрос. Доступно три поля, определяющие режим
фильтрации: «Несколько узлов», «Один узел» и «Отключить этот диапазон портов».
Выбор «Один узел» означает, что трафик, направленный на выбранный IP (компьютера
или кластера) с указанным номером порта, будет обрабатываться активным узлом,
имеющим наименьший показатель приоритета (о нем чуть ниже). Выбор «Отключить…»
значит, что такой трафик будет отбрасываться всеми участниками кластера.

В режиме фильтрации «Несколько узлов» можно дополнительно указать вариант
определения сходства клиентов, чтобы направлять трафик от заданного клиента к
одному и тому же узлу кластера. Возможны три варианта: «Нет», «Одно» или «Класс
C». Выбор первого означает, что на любой запрос будет отвечать произвольный
узел. Но не следует его использовать, если в правиле выбран протокол UDP или
«Оба». При избрании остальных пунктов сходство клиентов будет определяться по
конкретному IP или диапазону сети класса С.

Итак, для нашего правила с 80-м портом остановим свой выбор на варианте
«Несколько узлов — класс C». Правило для 443 заполняем аналогично, но используем
«Один узел», чтобы клиенту всегда отвечал основной узел с наименьшим
приоритетом. Если диспетчер обнаружит несовместимое правило, будет выведено
предупреждающее сообщение, дополнительно в журнал событий Windows будет внесена
соответствующая запись.

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

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

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

После установки NLB-кластера не забудь изменить DNS-запись, чтобы
разрешение имени теперь показывало на IP-кластера.

Изменение загрузки сервера

В такой конфигурации все серверы будут загружены равномерно (за исключением
варианта «Один узел»). В некоторых случаях необходимо перераспределить нагрузку,
большую часть работы возложив на один из узлов (например, самый мощный).
Применительно к кластеру правила после их создания можно изменить, выбрав в
контекстном меню, появляющемся при щелчке на имени, пункт «Свойства кластера».
Здесь доступны все те настройки, о которых мы говорили выше. Пункт меню
«Свойства узла» предоставляет несколько больше возможностей. В «Параметрах узла»
можно изменить значение приоритета для конкретно выбранного узла. В «Правилах
для портов» добавить или удалить правило нельзя, это доступно только на уровне
кластера. Но, выбрав редактирование конкретного правила, мы получаем возможность
скорректировать некоторые настройки. Так, при установленном режиме фильтрации
«Несколько узлов» становится доступным пункт «Оценка нагрузки», позволяющий
перераспределить нагрузку на конкретный узел. По умолчанию установлен флажок
«Равная», но в «Оценке нагрузки» можно указать другое значение нагрузки на
конкретный узел, в процентах от общей загрузки кластера. Если активирован режим
фильтрации «Один узел», в этом окне появляется новый параметр «Приоритет
обработки». Используя его, можно сделать так, что трафик к определенному порту
будет в первую очередь обрабатываться одним узлом кластера, а к другому – другим
узлом.

Журналирование событий

Как уже говорилось, компонент «Балансировка нагрузки сети» записывает все
действия и изменения кластера в журнал событий Windows. Чтобы их увидеть,
выбираем «Просмотр событий – Система», к NLB относятся сообщения WLBS (от
Windows Load Balancing Service, как эта служба называлась в NT). Кроме того, в
окне диспетчера выводятся последние сообщения, содержащие информацию об ошибках
и обо всех изменениях в конфигурации. По умолчанию эта информация не
сохраняется. Чтобы она записывалась в файл, следует выбрать «Параметры –>
Параметры журнала», установить флажок «Включить ведение журнала» и указать имя
файла. Новый файл будет создан в подкаталоге твоей учетной записи в Documents
and Settings.

Настраиваем IIS с репликацией

Кластер кластером, но без службы он смысла не имеет. Поэтому добавим IIS (Internet
Information Services) . Сервер IIS входит в состав Win2k3, но, чтобы свести к
минимуму возможность атак на сервер, он по умолчанию не устанавливается.

Инсталлировать IIS можно двумя способами: посредством «Панели управления» или
мастером управления ролями данного сервера. Рассмотрим первый. Переходим в
«Панель управления – Установка и удаление программ» (Control Panel — Add or
Remove Programs), выбираем «Установку компонентов Windows» (Add/Remove Windows
Components). Теперь переходим в пункт «Сервер приложений» и отмечаем в «Службах
IIS» все, что необходимо. По умолчанию рабочим каталогом сервера является \Inetpub\wwwroot.
После установки IIS может выводить статические документы.

Введение

Кластер серверов – это группа независимых серверов под управлением службы кластеров, работающих совместно как единая система. Кластеры серверов создаются путем объединения нескольких серверов на базе Windows® 2000 Advanced Server и Windows 2000 Datacenter Server для совместной работы, обеспечивая тем самым высокий уровень доступности, масштабируемости и управляемости для ресурсов и приложений.

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

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

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

Основные преимущества, получаемые при использовании службы кластеров:

• Высокая доступность. В случае отказа какого-либо узла служба кластеров передает управление ресурсами, такими как, например, жесткие диски и сетевые адреса, действующему узлу кластера. Когда происходит программный или аппаратный сбой, программное обеспечение кластера перезапускает завершившееся с ошибкой приложение на действующем узле, или перемещает всю нагрузку отказавшего узла на оставшиеся действующие узлы. При этом пользователи могут заметить лишь кратковременную задержку в обслуживании.
• Возврат после отказа. Служба кластеров автоматически перераспределяет рабочую нагрузку в кластере, когда отказавший узел вновь становится доступным.
• Управляемость. Администратор кластера – это оснастка, которую Вы можете использовать для управления кластером как единой системой, а также для управления приложениями. Администратор кластера обеспечивает прозрачное представление работы приложений так, как если бы они выполнялись на одном сервере. Вы можете перемещать приложения на различные серверы в пределах кластера, перетаскивая объекты кластера мышью. Таким же образом можно перемещать данные. Этот способ может использоваться для ручного распределения рабочей нагрузки серверов, а также для разгрузки сервера и его последующей остановки с целью проведения планового технического обслуживания. Кроме того, Администратор кластера позволяет удаленно производить наблюдение за состоянием кластера, всех его узлов и ресурсов.
• Масштабируемость. Для того чтобы производительность кластера всегда могла соответствовать возрастающим требованиям, служба кластеров располагает возможностями масштабирования. Если общая производительность кластера становится недостаточной для обработки нагрузки, создаваемой кластерными приложениями, в кластер могут быть добавлены дополнительные узлы.

Этот документ содержит инструкции по установке службы кластеров на серверах, работающих под управлением Windows 2000 Advanced Server и Windows 2000 Datacenter Server, и описывает процесс установки службы кластеров на серверы кластерных узлов. Данное руководство не описывает установку и настройку кластерных приложений, а лишь помогает Вам пройти через весь процесс установки простого двухузлового кластера.

Системные требования для создания кластера серверов

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

Требования к программному обеспечению

• Операционная система Microsoft Windows 2000 Advanced Server или Windows 2000 Datacenter Server, установленная на всех серверах кластера.
• Установленная служба разрешения имен, такая как Domain Naming System (DNS), Windows Internet Naming System (WINS), HOSTS и т. д.
• Сервер терминалов для удаленного администрирования кластера. Данное требование не является обязательным, а рекомендуется лишь для обеспечения удобства управления кластером.

Требования к аппаратному обеспечению

• Требования, предъявляемые к аппаратному обеспечению узла кластера, аналогичны требованиям для установки операционных систем Windows 2000 Advanced Server или Windows 2000 Datacenter Server. Эти требования можно найти на странице поиска каталога Microsoft.
• Оборудование кластера должно быть сертифицировано и указано в списке совместимого аппаратного обеспечения (HCL) каталога Microsoft для службы кластеров. Последнюю версию этого списка можно на странице поиска Windows 2000 Hardware Compatibility List каталога Microsoft, выбрав категорию поиска «Cluster».

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

• Жесткий диск с загрузочным системным разделом и установленной операционной системой Windows 2000 Advanced Server или Windows 2000 Datacenter Server. Этот диск не должен быть подключен к шине общего запоминающего устройства, рассмотренного ниже.
• Отдельный PCI-контроллер устройств оптического канала (Fibre Channel) или SCSI для подключения внешнего общего запоминающего устройства. Этот контроллер должен присутствовать в дополнение к контроллеру загрузочного диска.
• Два сетевых PCI адаптера, установленных на каждом компьютере кластера.
• Перечисленное в списке HCL внешнее дисковое запоминающее устройство, подключенное ко всем узлам кластера. Оно будет выступать в качестве диска кластера. Рекомендуется конфигурация с использованием аппаратных RAID-массивов.
• Кабели для подключения общего запоминающего устройства ко всем компьютерам. Для получения инструкций по конфигурированию запоминающих устройств обратитесь к документации производителя. Если подключение производится к шине SCSI, Вы можете обратиться к приложению А для дополнительной информации.
• Все оборудование на компьютерах кластера должно быть полностью идентичным. Это упростит процесс конфигурирования и избавит Вас от потенциальных проблем с совместимостью.

Требования к настройке сетевой конфигурации

• Уникальное NetBIOS имя для кластера.
• Пять уникальных статических IP-адресов: два адреса для сетевых адаптеров частной сети, два – для сетевых адаптеров публичной сети, и один адрес для кластера.
• Доменная учетная запись для службы кластеров (все узлы кластера должны быть членами одного домена)
• Каждый узел должен иметь два сетевых адаптера – один для подключения к публичной сети, один – для внутрикластерного взаимодействия узлов. Конфигурация с использованием одного сетевого адаптера для одновременного подключения к публичной и частной сети не поддерживается. Наличие отдельного сетевого адаптера для частной сети необходимо для соответствия требованиям HCL.

Требования к дискам общего запоминающего устройства

• Все диски общего запоминающего устройства, включая диск кворума, должны быть физически подключены к общей шине.
• Все диски, подключенные к общей шине, должны быть доступны для каждого узла. Это можно проверить на этапе установки и конфигурирования хост-адаптера. Для подробных инструкций обратитесь к документации производителя адаптера.
• Устройствам SCSI должны быть назначены целевые уникальные номера SCSI ID, кроме этого на шине SCSI должны быть правильно установлены терминаторы, в соответствии с инструкциями производителя. 1
• Все диски общего запоминающего устройства должны быть настроены как базовые диски (не динамические)
• Все разделы дисков общего запоминающего устройства должны быть отформатированы в файловой системе NTFS.

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

Установка кластера

Общий обзор установки

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

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

Это руководство описывает создание двухузлового кластера. Тем не менее, если Вы устанавливаете кластер с более чем двумя узлами, Вы можете использовать значение столбца «Узел 2» для определения состояния остальных узлов.

Таблица 1. Последовательность включения устройств при установке кластера

Шаг	Узел 1	Узел 2	Устройство хранения	Комментарий
Установка параметров сети	Вкл.	Вкл.	Выкл.	Убедитесь, что все устройства хранения, подключенные к общей шине, выключены. Включите все узлы.
Настройка общих дисков	Вкл.	Выкл.	Вкл.	Выключите все узлы. Включите общее запоминающее устройство, затем включите первый узел.
Проверка конфигурации общих дисков	Выкл.	Вкл.	Вкл.	Выключите первый узел, включите второй узел. При необходимости повторите для узлов 3 и 4.
Конфигурирование первого узла	Вкл.	Выкл.	Вкл.	Выключите все узлы; включите первый узел.
Конфигурирование второго узла	Вкл.	Вкл.	Вкл.	После успешной конфигурации первого узла включите второй узел. При необходимости повторите для узлов 3 и 4.
Завершение установки	Вкл.	Вкл.	Вкл.	К этому моменту все узлы должны быть включены.

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

• Установить на каждый компьютер кластера операционную систему Windows 2000 Advanced Server или Windows 2000 Datacenter Server.
• Настроить сетевые параметры.
• Настроить диски общего запоминающего устройства.

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

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

Установка операционной системы Windows 2000

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

В этом документе используется структура имен из руководства "Step-by-Step Guide to a Common Infrastructure for Windows 2000 Server Deployment" . Однако, Вы можете использовать любые имена.

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

Настройка сетевых параметров

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

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

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

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

Рисунок 1: Пример двухузлового кластера

Конфигурирование сетевого адаптера частной сети

Выполните эти шаги на первом узле Вашего кластера.

1. Мое сетевое окружение и выберите команду Свойства .
2. Щелкните правой кнопкой мыши на значке .

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

1. Состояние. Окно Состояние Подключение по локальной сети 2 показывает состояние подключения и его скорость. Если подключение находится в отключенном состоянии, проверьте кабели и правильность соединения. Устраните проблему, прежде чем продолжить. Нажмите кнопку Закрыть .
2. Снова щелкните правой кнопкой мыши на значке Подключение по локальной сети 2 , выберите команду Свойства и нажмите кнопку Настроить .
3. Выберите вкладку Дополнительно. Появится окно, изображенное на Рисунке 2.
4. Для сетевых адаптеров частной сети скорость работы должна быть выставлена вручную вместо значения, используемого по умолчанию. Укажите скорость Вашей сети в раскрывающемся списке. Не используйте значения «Auto Sense» или «Auto Select» для выбора скорости, поскольку некоторые сетевые адаптеры могут сбрасывать пакеты во время определения скорости соединения. Для задания скорости сетевого адаптера укажите фактическое значение для параметра Тип подключения или Скорость .

Рисунок 2: Дополнительные настройки сетевого адаптера

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

1. Выберите Протокол Интернета (TCP/IP) в списке компонентов, используемых подключением.
2. Нажмите кнопку Свойства .
3. Установите переключатель в положение Использовать следующий IP-адрес и введите адрес 10.1.1.1 . (Для второго узла используйте адрес 10.1.1.2 ).
4. Задайте маску подсети: 255.0.0.0 .
5. Нажмите кнопку Дополнительно и выберите вкладку WINS. Установите значение переключателя в положение Отключить NetBIOS через TCP/IP . Нажмите OK для возврата в предыдущее меню. Выполняйте этот шаг только для адаптера частной сети.

Ваше диалоговое окно должно выглядеть, как изображено на Рисунке 3.

Рисунок 3: IP-адрес подключения к частной сети

Конфигурирование сетевого адаптера публичной сети

Примечание: Если в публичной сети работает DHCP-сервер, IP-адрес для сетевого адаптера публичной сети может назначаться автоматически. Однако для адаптеров узлов кластера этот способ использовать не рекомендуется. Мы настоятельно рекомендуем назначать постоянные IP-адреса для всех публичных и частных сетевых адаптеров узлов. В противном случае при отказе DHCP-сервера доступ к узлам кластера может оказаться невозможным. Если же Вы вынуждены использовать DHCP для сетевых адаптеров публичной сети, используйте длительные сроки аренды адресов – это даст гарантию того, что динамически назначенный адрес останется действительным, даже если DHCP-сервер окажется временно недоступным. Адаптерам частной сети всегда назначайте постоянные IP-адреса. Помните, что служба кластеров может распознавать только один сетевой интерфейс в каждой подсети. Если Вам нужна помощь в вопросах назначения сетевых адресов в Windows 2000, обратитесь к встроенной справке операционной системы.

Переименование сетевых подключений

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

1. Щелкните правой кнопкой мыши на значке 2.
2. В контекстном меню выберите команду Переименовать .
3. Введите Подключение к частной сети кластера в текстовом поле и нажмите клавишу ВВОД .
4. Повторите шаги 1-3 и измените название подключения Подключение по локальной сети на Подключение к публичной сети.

Рисунок 4: Переименованные сетевые подключения

1. Переименованные сетевые подключения должны выглядеть, как показано на Рисунке 4. Закройте окно Сеть и удаленный доступ к сети . Новые названия сетевых подключений автоматически реплицируются на другие узлы кластера при их включении.

Проверка сетевых соединений и разрешений имен

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

1. Нажмите кнопку Пуск, выберите команду Выполнить и наберите команду cmd в текстовом окне. Нажмите OK .
2. Наберите команду ipconfig /all и нажмите клавишу ВВОД . Вы увидите информацию о настройке IP-протокола для каждого сетевого адаптера на локальной машине.
3. В случае, если у Вас еще не открыто окно командной строки, выполните шаг 1.
4. Наберите команду ping ipaddress где ipaddress – это IP-адрес соответствующего сетевого адаптера на другом узле. Предположим для примера, что сетевые адаптеры имеют следующие IP-адреса:

Номер узла	Имя сетевого подключения	IP-адрес сетевого адаптера
1	Подключение к публичной сети	172.16.12.12
1	Подключение к частной сети кластера	10.1.1.1
2	Подключение к публичной сети	172.16.12.14
2	Подключение к частной сети кластера	10.1.1.2

В этом примере Вам нужно выполнить команды ping 172.16.12.14 и ping 10.1.1.2 с узла 1, и выполнить команды ping 172.16.12.12 и ping 10.1.1.1 с узла 2.

Чтобы проверить разрешение имен, выполните команду ping , используя в качестве аргумента имя компьютера вместо его IP-адреса. Например, чтобы проверить разрешение имени для первого узла кластера с именем hq-res-dc01, выполните команду ping hq-res-dc01 с любого клиентского компьютера.

Проверка принадлежности к домену

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

Примечание: Для получения ссылок на дополнительную документацию по настройке доменов, служб DNS и DHCP в Windows 2000 смотрите раздел Связанные ресурсы в конце этого документа.

1. Щелкните правой кнопкой мыши Мой компьютер и выберите команду Свойства .
2. Выберите вкладку Сетевая идентификация . В диалоговом окне Свойства системы Вы увидите полное имя компьютера и домена. В нашем примере домен называется reskit.com .
3. Если Вы сконфигурировали узел в качестве рядового сервера, то на этом этапе Вы можете присоединить его к домену. Нажмите кнопку Свойства и следуйте инструкциям для присоединения компьютера к домену.
4. Закройте окна Свойства системы и Мой компьютер .

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

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

1. Нажмите кнопку Пуск , выберите команду Программы / Администрирование , запустите оснастку .
2. Разверните категорию reskit.com , если она еще не развернута
3. В списке выберите Users .
4. Щелкните правой кнопкой мыши на Users , выберите в контекстном меню Создать , выберите Пользователь .
5. Введите имя для учетной записи службы кластера, как показано на Рисунке 5, и нажмите кнопку Далее.

Рисунок 5: Добавление пользователя Cluster

1. Установите флажки Запретить смену пароля пользователем и Срок действия пароля не ограничен . Нажмите кнопку Далее и кнопку Готово , чтобы создать пользователя.

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

1. Щелкните правой клавишей мыши на пользователе Cluster в правой панели оснастки Active Directory – пользователи и компьютеры .
2. В контекстном меню выберите команду Добавить участников в группу .
3. Выберите группу Администраторы и нажмите OK . Теперь новая учетная запись имеет привилегии администратора на локальном компьютере.
4. Закройте оснастку Active Directory – пользователи и компьютеры .

Настройка дисков общего запоминающего устройства

Предупреждение: Убедитесь, что, по крайней мере, на одном из узлов кластера установлена операционная система Windows 2000 Advanced Server или Windows 2000 Datacenter Server, а также настроена и работает служба кластеров. Только после этого можно загружать операционную систему Windows 2000 на остальных узлах. Если эти условия не будут выполнены, диски кластера могут быть повреждены.

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

Диск кворума

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

• Создайте небольшой раздел (размером как минимум 50 Мб), чтобы использовать его в качестве диска кворума. Обычно мы рекомендуем создавать диск кворума размером в 500 Мб.
• Выделите отдельный диск для ресурса кворума. Поскольку в случае выхода из строя диска кворума произойдет сбой работы всего кластера, мы настоятельно рекомендуем использовать аппаратный дисковый RAID-массив.

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

Конфигурирование дисков общего запоминающего устройства

1. Щелкните правой кнопкой мыши Мой компьютер , выберите команду Управление . В открывшемся окне раскройте категорию Запоминающие устройства .
2. Выберите команду Управление дисками .
3. Убедитесь, что все диски общего запоминающего устройства отформатированы в системе NTFS и имеют статус Основной . Если Вы подключите новый диск, автоматически запустится Мастер подписывания и обновления дисков . Когда мастер запустится, нажмите кнопку Обновить, чтобы продолжить его работу, после этого диск будет определен как Динамический . Чтобы преобразовать диск в базовый, щелкните правой кнопкой мыши на Диск # (где # – номер диска, с которым Вы работаете) и выберите команду Возвратить к базовому диску .

Щелкните правой кнопкой мыши область Не распределен рядом с соответствующим диском.

1. Выберите команду Создать раздел
2. Запустится Мастер создания раздела . Дважды нажмите кнопку Далее .
3. Введите желаемый размер раздела в мегабайтах и нажмите кнопку Далее .
4. Нажмите кнопку Далее , приняв предложенную по умолчанию букву диска
5. Нажмите кнопку Далее для форматирования и создания раздела.

Назначение букв дискам

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

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

1. Щелкните правой кнопкой мыши требуемый раздел и выберите команду Изменение буквы диска и пути диска .
2. Выберите новую букву диска.
3. Повторите шаги 1 и 2 для всех дисков общего запоминающего устройства.

Рисунок 6: Разделы дисков с назначенными буквами

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

1. Нажмите кнопку Пуск , выберите Программы / Стандартные , и запустите программу «Блокнот» .
2. Наберите несколько слов и сохраните файл под именем test.txt , выбрав команду Сохранить как из меню Файл . Закройте Блокнот .
3. Дважды щелкните мышью на значке Мои документы .
4. Щелкните правой кнопкой мыши на файле test.txt и в контекстном меню выберите команду Копировать .
5. Закройте окно.
6. Откройте Мой компьютер .
7. Дважды щелкните мышью на разделе диска общего запоминающего устройства.
8. Щелкните правой кнопкой мыши и выберите команду Вставить .
9. На диске общего запоминающего устройства должна появиться копия файла test.txt .
10. Дважды щелкните мышью на файле test.txt , чтобы открыть его с диска общего запоминающего устройства. Закройте файл.
11. Выделите файл и нажмите клавишу Del , чтобы удалить файл с диска кластера.

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

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