Сравнение кластера надежности и "обычного" сервера. Серверные кластеры

Кластер серверов 1С:Предприятия 8 (1C:Enterprise 8 Server Cluster)

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

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

Можно выделить следующие возможности кластера серверов, как основные:

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

Клиент-серверный вариант. Схема работы

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

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

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

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

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

Кластер серверов

Элементарный кластер серверов может представлять собой единственный компьютер и содержать только один рабочий процесс.

На рисунке можно наблюдать все элементы, которые, так или иначе, принимают участие в работе кластера серверов. Это следующие элементы:

• процессы кластера серверов:
  o ragent.exe;
  o rmngr.exe;
  o rphost.exe;
• хранилища данных:
  o список кластеров;
  o реестр кластера.

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

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

Сам кластер серверов состоит из таких элементов:

• один или несколько процессов rmngr.exe
• реестр кластера
• один или несколько процессов rphost.exe.

Менеджер кластера (процесс rmngr.exe). Он служит для управления функционирования всего кластера. В состав кластера может входить несколько процессов rmngr.exe, один их которых всегда будет главным менеджером данного кластера, а остальные процессы – дополнительными менеджерами. Центральным сервером кластера следует называть рабочий сервер, на котором действует главный менеджер кластера, и который содержит список кластера. Именно ведение реестра кластера является одной из функций главного менеджера кластера.

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

Масштабируемость 1С версии 8.3

Масштабируемость кластера серверов осуществляется следующими способами:

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

Использование одновременно нескольких менеджеров.

Функции, которые исполняет менеджер кластера, разделяются на несколько сервисов. Данные сервисы можно назначить разным менеджерам кластера. Это дает возможность равномерно распределить нагрузку по нескольким процессам.

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

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

Для прочих сервисов допустимы в назначение произвольные менеджеры кластера:

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

Использование одновременно нескольких рабочих процессов.

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

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

Отказоустойчивость 1С версии 8.3

Устойчивость к отказам в работе кластера обеспечивается тремя направлениями:

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

Резервирование кластера 1С версии 8.3

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

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

Резервирование рабочих процессов 1С версии 8.3

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

• использовать
• не использовать
• использовать как резервный.

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

Устойчивость 1С версии 8.3 к обрыву канала связи

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

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

Сеансы работы в 1С версии 8.3

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

• Тонкий клиент, Веб-клиент, Толстый клиент – эти сеансы возникают при обращении соответствующих клиентов к информационной базе
• Соединение типа «Конфигуратор» — оно возникает при обращении к информационной базе конфигуратора
• СОМ-соединение – образовывается при использовании внешнего соединения для обращения к информационной базе
• WS-соединение – возникает в случае обращения к информационной базе веб-сервера, как следствие обращения к опубликованному на веб-сервере Web-сервису
• Фоновое задание – образовывается, когда рабочий процесс кластера обращается к информационной базе. Служит такой сеанс для исполнения кода процедуры фонового задания,
  Консоль кластера – создается, когда утилита администрирования клиент-серверного варианта обращается к рабочему процессу
• СОМ-администратор – возникает в случае обращения к рабочему процессу с использованием внешнего соединения.
• Работа при использовании различных операционных систем

Любые процессы кластера серверов могут функционировать как под операционной системы Linux, так и под операционной системы Windows. Это достигается тем, что взаимодействие кластеров происходит под управлением протокола TCP/IP. Также в состав кластера могут входить рабочие серверы под управлением любой из этих операционных систем.

Утилита администрирования кластера серверов 8.3

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

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

Суть вкратце

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

Пример схемы кластера серверов

В качестве примера возьмём весьма популярный софт «1С:Предприятие 8». Упрощённая схема функционирования кластера серверов выглядит примерно следующим образом.

Клиентское приложение (в смысле, приложение на компьютере пользователя) осуществляет запрос по протоколу TCP/IP. Этот запрос приходит на центральный сервер в кластере, где действует программа-менеджер (Cluster Manager) и располагается реестр кластера.

Центральный сервер на лету анализирует обстановку с загруженностью и перенаправляет запрос (тоже по TCP/IP) на тот компьютер в кластере, у которого в этот момент есть возможность наиболее быстро и эффективно обработать обращение пользователя. После чего за обслуживание запроса берётся конкретный рабочий процесс на конкретной машине.

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

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

Microsoft

Для организации кластера серверов на основе софта от корпорации Microsoft требуется операционная система «Microsoft® Windows Server™ 2008», причём, «Enterprise Edition» или «Datacenter Edition». Там есть софт «Windows Server Failover Clustering». (Ранее, в релизе ОС за 2003-й год, программное изделие называлось «Microsoft Cluster Server», сокращённо MSCS.)

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

Кластер в Windows Server создаётся с помощью графического интерфейса «Cluster Control Panel». Десяток диалоговых окошек - и готово.

Oracle

Компания Oracle для создания кластеров производит продукт «WebLogic». Есть версии и для Windows , и для GNU/Linux .

Велосипед изобретать не стали: работой и балансировкой нагрузки руководит сервер-администратор (Admin Server), к которому подключены узлы (Managed Servers). Всё вместе объединяется в единый домен.

Причём, с помощью «WebLogic» в домен можно сгруппировать даже не один, а несколько кластеров. Кроме того, доступны: 1) репликация пользовательских сессий в серверах кластера; 2) балансировка нагрузки (с помощью компонента HttpClusterServlet).

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

Кроме того, имеется продукт «Oracle Real Application Clusters» (сокращённо «Oracle RAC») для синхронизированной работы «Oracle Database» на нескольких узлах, что тоже по своей сути является кластером.

Заключение

Благодаря умному софту кластер выглядит «со стороны», с точки зрения клиента, как один единственный компьютер, к которому осуществляется запрос. В этом отличие кластера от Grid-систем распределённых вычислений, где компьютеры вовсе необязательно объединены в домен, вполне могут быть удалёнными.

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

Предыдущие публикации:

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

• Служба Network Load Balancing (NLB) .В основном, предназначена для балансирования входящего трафика TCP/IP. NLB обычно используется для веб-серверов.
• Кластеры серверов .Реализуются для обеспечения переходов по отказу ( failover ) среди кластеризованных компьютеров. Служба Cluster обычно используется для приложений, работающих с базами данных.

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

Примечание . Microsoft также предлагает третью кластерную технологию - кластеры Component Load Balancing (CLB). Эта технология входит в состав Microsoft Application Center 2000 и не включается ни в одну из версий Windows Server 2003. CLB-кластеры позволяют распространять приложения COM+ среди нескольких серверов, что гарантирует масштабируемость и высокую готовность приложений.

Кластеры Network Load Balancing

Network Load Balancing (NLB) - это программная разработка, используемая в кластеризации Microsoft Windows для масштабирования работы IP-программ путем распределения клиентских запросов среди нескольких серверов в кластере. NLB используется чаще всего для повышения производительности и уровня готовности веб-приложений, но может также использоваться для повышения производительности множества IP-приложений внутри вашего предприятия.

Примечание . Служба Network Load Balancing в ее текущей форме появилась как переработанная замена службы Windows Load Balancing Service (WLBS), используемой в Windows NT 4. Однако вы увидите, что до сих пор имеются компоненты исходной WLBS, например, запускаемая из командной строки программа управления, wlbs.exe, все еще используется для обратной совместимости.

NLB входит в следующие версии Windows Server 2003:

• Standard Edition;
• Enterprise Edition;
• Datacenter Edition;
• Web Edition.

Преимущества Network Load Balancing

С помощью Network Load Balancing можно создавать кластеры, содержащие до 32 хостов, среди которых могут распределяться запросы клиентов. Служба NLB расширена в Windows Server 2003, позволяя вам создавать несколько виртуальных NLB-кластеров на одном сервере путем задания NLB для нескольких сетевых адаптеров и путем задания нескольких IP-адресов кластера со сбалансированной нагрузкой для одного сетевого адаптера. Два главных достоинства NLB для приложений - это готовность и масштабируемость.

Готовность

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

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

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

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

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

NLB обеспечивает два уровня масштабируемости.

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

Управляемость

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

Архитектура NLB

Network Load Balancing запускается как драйвер сетевого обмена Windows, и операции этого драйвера прозрачны для стека TCP/IP. Все компьютеры в кластере можно указывать с помощью IP-адреса данного кластера. Однако каждый компьютер поддерживает также свой собственный уникальный выделенный IP-адрес. Компания Microsoft реализовала NLB как драйвер сетевого обмена, который действует между драйвером сетевого адаптера (сетевой карты) и стеком IP. Все члены NLB-кластера должны находиться в одной подсети IP, чтобы запросы клиентов, направляемые по IP-адресу кластера, могли обрабатываться всеми членами кластера.

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

NLB перехватывает только пакеты TCP и UDP. Пакеты других протоколов IP передаются в стек протоколов и обрабатываются всеми узлами NLB-кластера.

Оборудование и протоколы

Служба NLB разработана таким образом, чтобы обеспечивать кластерную поддержку для серверных программ на основе TCP/IP. Для этого, конечно, требуется, чтобы TCP/IP был протоколом по умолчанию для системы. Версия NLB в Windows Server 2003 действует в локальных сетях на основе FDDI или Ethernet внутри кластера.

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

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

NLB управляет распределением по соединениям для TCP и по дейтаграммам для UDP, применяя фильтрацию входного трафика, прежде чем происходит обращение к программам протокола TCP/IP. В TCP/IP обрабатываются только протоколы TCP и UDP, и все управление применяется на уровне портов.

Примечание .Некоторые программы двухточечных соединений TCP/IP, в особенности ping , будут давать дублированные ответы при указании IP-адреса кластера. Чтобы избежать этого, используйте выделенный IP-адрес хоста, которому вы передаете ping .

NLB можно сконфигурировать для обработки трафика кластера более детально путем использования таких средств, как правила для портов или родственность ( affinity ). Более подробную информацию см. ниже в разделе "Установка и конфигурирование Network Load Balancing ".

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

Служба Network Load Balancing в Windows Server 2003 расширена за счет поддержки виртуальных кластеров со сбалансированной нагрузкой. Для создания виртуального кластера нужно активизировать NLB для нескольких сетевых адаптеров на одном сервере или назначить несколько IP-адресов одному сетевому адаптеру, для которого активизирована NLB. Поскольку различные IP-адреса могут соответствовать различным веб-сайтам или приложениям, разумное использование виртуальных кластеров и соответствующих правил для портов позволяет вам управлять тем, как различные веб-приложения распределяются между физическими серверами со сбалансированной нагрузкой.

Виртуальные серверы обладают следующими свойствами.

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

Конфигурирование приложений

Имеется несколько способов конфигурирования приложений в NLB-кластере. Кластер можно сконфигурировать таким образом, чтобы копия серверной программы выполнялась на каждом хосте; или приложение может выполняться на одном хосте, когда все запросы отправляются на этот хост вместо равномерного распределения нагрузки по всему кластеру. Принимаемое решение зависит от типа приложения. Например, приложения, которым требуется централизация, такие как Microsoft Exchange Server, принадлежат какому-либо одному хосту. Кроме того, запросы записи в базу данных могут отправляться на выделенный сервер базы данных в системе. Если нагрузка по базе данных сбалансирована в кластере, то каждый узел кластера может иметь свою собственную копию этих данных. Обновления в содержимом таблицы базы данных должны синхронизироваться путем регулярного слияния в режиме offline. Однако в большинстве случаев критически важные базы данных развертываются в среде кластера серверов, позволяющего выполнять переходы по отказам ( failover ), а не в среде NLB (см. ниже раздел "Кластеры серверов").

NLB в чистом виде наиболее подходит для нецентрализованного хранения данных или для приложений, которые не принимают данных от клиентов, выполняющих доступ к серверу (то есть для доступных только по чтению приложений на основе протокола TCP или UDP). Веб-сайты являются идеальными "кандидатами" для использования с NLB, поскольку это позволяет легко снабжать каждый хост текущей копией страниц (которые обычно являются статическими), обеспечивая простоту и скорость обработки больших объемов трафика. Для веб-клиентов, которым требуется доступ к базе данных, веб-серверы могут направлять запросы на сервер базы данных. Имеются также следующие кандидаты, для которых подходит NLB:

• HTTP, HTTPS, FTP, TFTP и SMTP поверх TCP/IP
• HTTP через SSL - порт 443
• FTP - порт 21, порт 20, порты 1024.65 и порт 535
• SMTP - порт 25
• Terminal Services - порт 3389
• Веб-серверы (такие как Microsoft Internet Information Services) - порт 80
• Веб-серверы, использующие круговую DNS
• Серверы виртуальных частных сетей (VPN)
• Серверы потокового медиа.

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

Серверы приложений и соединения с изменяемым состоянием

Имеется два вида соединений между клиентами и хостами для серверов приложений, и они обычно описываются термином stateful-соединение (соединение с изменяемым состоянием).

• Interclient-состояние (состояние с учетом всех клиентов). Обновления синхронизируются с транзакциями, выполняемыми для других клиентов. Примером является обновление базы данных запасов на сайте e-commerce после продажи товаров через соединение с клиентом.
• Intraclient-состояние (состояние на уровне одного клиента). Состояние, поддерживаемое для конкретного клиента в течение одного сеанса, включающего, например, продажу продуктов (обычно с помощью процесса обработки "торговой тележки") на сайте e-commerce. На самом деле для большинства сайтов e-commerce процесс обработки "торговой тележки" может охватывать несколько отдельных соединений с одним клиентом.

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

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

NLB можно использовать для масштабируемости приложений с intraclient-состояниями, даже в рамках сеанса, охватывающего несколько соединений. При включении одной из опций родственности ( affinity ) для клиентов NLB направляет все TCP-соединения на один и тот же хост кластера, что позволяет поддерживать состояние сеанса в памяти этого хоста. (Для клиент/серверных приложений, которые встраивают состояние в cookie-файлы или отправляют его в прикладную базу данных, не требуется родственность для клиентов.)

Уже на этапе планирования будущей виртуальной инфраструктуры следует задуматься об обеспечении высокой доступности ваших виртуальных машин. Если в обычной ситуации временная недоступность одного из серверов еще может быть приемлема, то в случае остановки хоста 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

Пресс-центр

Создание кластера на базе Windows 2000/2003. Шаг за шагом

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

Microsoft Windows 2000/2003 поддерживает две технологии кластеризации: кластеры с балансировкой нагрузки (Network Load Balancing) и кластеры серверов.

В первом случае (кластеры с балансировкой нагрузки) служба Network Load Balancing придает службам и приложениям свойства высокого уровня надежности и масштабируемости за счет объединения до 32 серверов в единый кластер. Запросы от клиентов в данном случае распределяются среди узлов кластера прозрачным образом. При отказе узла кластер автоматически изменяет свою конфигурацию и переключает клиента на любой из доступных узлов. Этот режим конфигурации кластера также называется active-active режимом, когда одно приложение работает на нескольких узлах.

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

Кластерный подход к организации внутренней сети дает следующие преимущества:

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

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

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

• Microsoft Windows 2000 Advanced (Datacenter) Server или Microsoft Windows 2003 Server Enterprise Edition, установленные на всех серверах кластера.
• Установленная служба DNS. Немного поясню. Если вы строите кластер на основе двух контроллеров домена, то намного удобнее использовать службу DNS, которую вы в любом случае устанавливаете при создании Active Directory. Если вы создаете кластер на основе двух серверов, членов Windows NT домена, то вам придется использовать либо службу WINS, либо заносить соответствие имен и адресов машин в файл hosts.
• Terminal Services для удаленного управления серверами. Не обязательно, но при наличии Terminal Services удобно управлять серверами со своего рабочего места.

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

• Аппаратное обеспечение для узла кластера лучше подбирать, основываясь на Cluster Service Hardware Compatible List (HCL). По рекомендациям Microsoft аппаратное обеспечение должно быть протестировано на совместимость с Cluster Services.
• Соответственно вам понадобятся два сервера, имеющих по два сетевых адаптера; SCSI-адаптер, имеющий внешний интерфейс для подключения внешнего массива данных.
• Внешний массив, имеющий два внешних интерфейса. Каждый из узлов кластера подключается к одному из интерфейсов.

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

Требования к сетевым настройкам

• Уникальное NetBIOS имя для кластера.
• Пять уникальных статических IP-адресов. Два для сетевых адаптеров на кластерную сеть, два для сетевых адаптеров на общую сеть и один для кластера.
• Доменная учетная запись для кластерного сервиса (Cluster service).
• Все узлы кластера должны быть либо member server в домене, либо контроллерами домена.
• Каждый сервер должен иметь два сетевых адаптера. Один для подключения в общую сеть (Public Network), второй для обмена данными между узлами кластера (Private Network).

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

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

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

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

Установка двухузлового кластера может быть разделена на 5 шагов

• Установка и настройка узлов в кластере.
• Установка и настройка разделяемого ресурса.
• Проверка дисковой конфигурации.
• Конфигурирование первого узла кластера.
• Конфигурирование второго узла в кластере.

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

Установка и настройка узлов

Мы немного упростим задачу. Поскольку все узлы кластера должны быть либо участниками домена, либо контроллерами домена, то корневым держателем каталога AD (Active Directory) сделаем 1-й узел кластера, на нем же будет работать DNS-служба. 2-й узел кластера будет полноправным контроллером домена.

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

Сетевые настройки

Перед началом установки кластера и Active Directory необходимо выполнить сетевые настройки. Все сетевые настройки хочется разделить на 4 этапа. Для распознавания имен в сети желательно иметь DNS-сервер с уже существующими записями о серверах кластера.

Каждый сервер имеет по две сетевые карты. Одна сетевая карта будет служить для обмена данными между узлами кластера, вторая будет работать на клиентов в нашей сети. Соответственно первый назовем Private Cluster Connection, второй назовем Public Cluster Connection.

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

• My Network Places → Properties

Private Cluster Connection → Properties → Configure → Advanced

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

• Internet Protocol (TCP/IP) → Properties → Use the following IP: 192.168.30.1

  (Для второго узла используйте адрес 192.168.30.2). Введите маску подсети 255.255.255.252 . В качестве адреса DNS-сервера для обоих узлов используйте адрес 192.168.100.1 .

• Дополнительно на вкладке Advanced → WINS выберите пункт Disabled NetBIOS over TCP/IP . Для настроек сетевых адаптеров общей (Public) сети этот пункт опустите.
• Проделайте то же самое с сетевой картой для локальной сети Public Cluster Connection. Используйте адреса, приведенные в таблице. Единственная разница в конфигурации двух сетевых плат состоит в том, что для Public Cluster Connection не требуется выключения режима WINS - NetBIOS over TCP/IP .

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

Узел	Сетевое имя	IP address	MASK	DNS Server
1	Public Cluster Connection	192.168.100.1	255.255.255.0	192.168.100.1
1	Private Cluster Connection	192.168.30.1	255.255.255.252	192.168.100.1
2	Public Cluster Connection	192.168.100.2	255.255.255.0	192.168.100.1
3	Private Cluster Connection	192.168.30.2	255.255.255.252	192.168.100.1

Установка Active Directory

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

Установка Cluster User Account

• Start → Programs → Administrative Tools → Active Directory Users and Computers
• Добавьте нового пользователя, например, ClusterService.
• Установите флажки на: User Cannot Change Password и Password Never Expires .
• Также добавьте этого пользователя в группу администраторов и дайте ему права Log on as a service (права назначаются в Local Security Policy и Domain Controller Security Policy ).

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

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

1. Оба сервера должны быть выключены, внешний массив включен, подсоединен к обоим серверам.
2. Включаем первый сервер. Получаем доступ к дисковому массиву.
3. Проверяем, чтобы внешний дисковый массив был создан как Basic. Если это не так, то переведем диск с помощью опции Revert to Basic Disk .
4. Создаем на внешнем диске через Computer Manage-ment → Disk Management небольшой раздел. По рекомендациям Microsoft он должен быть не менее 50 Мб. Я рекомендую создать раздел в 500 Мб. или чуть больше. Для размещения кластерных данных этого вполне достаточно. Раздел должен быть отформатирован в NTFS.
5. На обоих узлах кластера этот раздел будет назван одной буквой, например, Q. Соответственно при создании раздела на первом сервере выберем пункт Assign the following drive letter - Q .
6. Оставшуюся часть диска вы можете разметить по своему желанию. Конечно, крайне желательно использовать файловую систему NTFS. Например, при настройке служб DNS, WINS основные базы служб будут перенесены на общий диск (не системный том Q, а второй, созданный вами). И по соображению безопасности вам будет удобнее использовать именно NTFS-тома.
7. Закрываем Disk Management и проверяем доступ к вновь созданному разделу. Например, можно создать на нем текстовый файл test.txt , записать и удалить. Если все прошло нормально, то с конфигурацией внешнего массива на первом узле мы закончили.
8. Теперь выключаем первый сервер. Внешний массив должен быть включен. Включаем второй сервер и проверяем доступ к созданному разделу. Также проверим, чтобы буква, назначенная первому разделу, была идентична выбранной нами, то есть Q.

На этом конфигурация внешнего массива завершена.

Установка Cluster Service Software

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

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

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

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

1. В диалоговом окне Create or Join a Cluster выберите The second or next node in the cluster и нажмите далее.
2. Введите имя кластера, которое мы задали ранее (в примере это MyCluster), и нажмите далее.
3. После подключения второго узла к кластеру Cluster Service Configuration Wizard автоматически заберет все установки с основного узла. Для запуска службы Cluster Service используйте имя, которые мы создавали ранее.
4. Введите пароль вашей учетной записи и нажмите далее.
5. В следующем диалоговом окне нажмите Finish для завершения установки.
6. Cluster service будет запушен на втором узле.
7. Закройте окно Add/Remove Programs .

Для установки дополнительных узлов кластера используйте эту же инструкцию.

Постскриптум, благодарности

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

Шаг	Узел 1	Узел 2	Внешний массив