Обзор отказоустойчивой кластеризации. Создание отказоустойчивого кластера высокой доступности на Windows

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

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

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

Возможности 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 может выводить статические документы.

Всем привет сегодня расскажу как настроить отказоустойчивый кластер Hyper-V в Windows Server 2012 R2. Напомню, что тоже саое мы с вами уже рассматривали для Hyper-V в Windows Server 2012 R2 .

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

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

Статья для тех, кто никогда не работал с кластеризацией, имеет слабое представление о том «Что же это такое?» Но имеет практический опыт работы с Windows Server 200x

За красивым названием «Кластер (Cluster)» таится множество полезного и интересного с точки зрения системного администрирования.

В этой статье рассматриваться будет встроенное решение в ЛЮБОЙ операционной системе win server начинает от server 2003 а именно Network Load Balancing. (например отказоустойчивые кластеры возможны только в enterprise и datacenter edition).

Для чего же это нужно?! Конкретно NLB как понятно из названия для балансировки нагрузки между нодами кластера. Данный кластер служит для объединения любых TCP/IP сервисов, таких как: сервер печати, терминальные сервер, Web сервер и так далее, что бы снизить нагрузку на конкретный сервер, распределить ресурсы между нодами, в таком кластере может быть до 32 нод (Нода/node кластера - это один из включённых в него серверов.)

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

Для начала нам нужно 3 ноды в данном кластере, проще всего это сделать на системе виртуализации, но и физ серверах отличия нет.в 1. Устанавливаем ОС (в нашем случае Windows Server 2008r2

(процесс установка Win2008R2 –это уже совсем другая история=)

Начать стоит с настройки сетевых карта, может быть и 1 и 2 карты в каждом сервере, отличие будет только в режиме работы. Допустим у нас две, первую настраиваем так, как будто это простой сервер т.е настройки TCP/IP как у любого сервера в вашей сети, вторая будет для кластера она настраивается точно так же как и первая но имеет другой ip адрес и в ней НЕ ПРОПИСЫВАЕТСЯ основной шлюз!

Пример: имеем 3 сервера по 2 сетевые карты, назначаем адреса как показано на рисунке 1

(1-7 это ip адреса)

Для удобства переименуем сетевые карты в LAN и NLB соответственно.

2. На NLB картах нужно выключить регистрацию адреса в DNS (свойства TCP/ipv4>дополнительно>вкладка DNS> галочка в низу «зарегистрировать адрес этого подключения в DNS « СНИМАЕМ!

В отличии от win2003 и Win2008 у Win2008R2 есть маленькое отличии, которое долго не давало заставить работать кластер. Но проблема была решена, делюсь:

3. В Win2008R2 стандартно выключен форвардин пакетов между сетевыми соединениями! Включаем: netsh interface ipv4 set interface “ LAN” forwarding=enabled

Либо правим ключ реестра:

a. Запустите редактор реестра (Regedit.exe) .

b. Найдите и выделите следующий раздел реестра:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

c. Задайте следующие параметры реестра:

Имя параметра: IPEnableRouter

Тип значения: REG_DWORD

Значение: 1

ПРИМЕЧАНИЕ: Значение 1 включает пересылку TCP/IP (Включение) для всех Сетевые подключения установленных и используемых на данном компьютере.

d. Закройте редактор реестра.

Перед сборкой кластера, на всех нодах нужно поднять роли которые они будут поддерживать, в нашем случае это Remote Desktop.

4. На всех машинах будущего кластера поднимаем роль Remote Desktop Services и настраиваем её так, как вам необходимо.

Теперь собираем NLB кластер:

5. На всех машинах поднимаем службу NLB и в настройках каждой NLB сетевой карты СНИМАЕМ галочку с протокола NETWORK LOAD BALANCING, да, именно СНИМАЕМ!

6. На любой ноде после добавления роли заходи в administrative tools, запускаем консоль NLB, жмём на вкладку Cluster>new

В поле Host вводим доменное имя компютера на котором на котором вы сейчас находитесь и жмёте connect.

В низу появляются два интерфейса готовых для кластеризации, нам нужен NLB интерфейс выбираем его и жмём Next, в следующем окне оставляем всё без изменений и опять идём Next, а вот тут нажимаем кнопку Add… и вводим ip адрес будущего кластера на рисунке 1 это адрес номер 7 (это будет виртуальный адрес принадлежащий каждой сетевой карте (NLB) нового кластера) и маску подсети, далее нажимаем ок и видим новый кластер, жмём next. В поле Full internet name вводим DNS имя будущего кластера и выбираем режим Multicast. (оба режима имеют и плюсы и минусы, мной был выбран мультикаст. В следующем окне жмём edit и настраиваем открытые в кластере порты (в случае с RDP выставляем «From: 3389 To: 3389» если порт один и стандартный. Все настройки зависят от требований к серверу.

7. Cluster>add host вводим имя следующей ноды и выбираем сетевую NLB потом далее… далее… далее… и в кластере появляется новая нода, так же и с остальными (До 32х нод). Проверьте что бы все ноды видные в консоли и горят зелёным цветом.

Всё, кластер готов

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

Эта статья написана после перебора множества мануалов и статей, освещены только ключевые моменты настройка (не рассчитано на людей с отсутствием опыта по WinServer).

Множество мелких настроек это исключительно best practices, правильно установив и настроив такой кластер вы получите очень гибкое высоконагружаемое решение.

Applies To: Windows Server 2012 R2

This guide provides step-by-step instructions for migrating clustered services and applications to a failover cluster running Windows Server 2012 R2 by using the Copy Cluster Roles Wizard. Not all clustered services and applications can be migrated using this method. This guide describes supported migration paths and provides instructions for migrating between two multi-node clusters or performing an in-place migration with only two servers. Instructions for migrating a highly available virtual machine to a new failover cluster, and for updating mount points after a clustered service migration, also are provided.

Operating system requirements for clustered roles and feature migrations

The Copy Cluster Roles Wizard supports migration to a cluster running Windows Server 2012 R2 from a cluster running any of the following operating systems:

Windows Server 2008 R2 with Service Pack 1 (SP1)

Windows Server 2012

Windows Server 2012 R2

Migrations are supported between different editions of the operating system (for example, from Windows Server Enterprise to Windows Server Datacenter), between x86 and x64 processor architectures, and from a cluster running Windows Server Core or the Microsoft Hyper-V Server R2 operating system to a cluster running a full version of Windows Server.

The following migrations scenarios are not supported:

Migrations from Windows Server 2003, Windows Server 2003 R2, or Windows Server 2008 to Windows Server 2012 R2 are not supported. You should first upgrade to Windows Server 2008 R2 SP1 or Windows Server 2012, and then migrate the resources to Windows Server 2012 R2 using the steps in this guide. For information about migrating to a Windows Server 2012 failover cluster, see Migrating Clustered Services and Applications to Windows Server 2012 . For information about migrating to a Windows Server 2008 R2 failover cluster, see .

The Copy Cluster Roles Wizard does not support migrations from a Windows Server 2012 R2 failover cluster to a cluster with an earlier version of Windows Server.

Before you perform a migration, you should install the latest updates for the operating systems on both the old failover cluster and the new failover cluster.

Target audience

This migration guide is designed for cluster administrators who want to migrate their existing clustered roles, on a failover cluster running an earlier version of Windows Server, to a Windows Server 2012 R2 failover cluster. The focus of the guide is the steps required to successfully migrate the clustered roles and resources from one cluster to another by using the Copy Cluster Roles Wizard in Failover Cluster Manager.

General knowledge of how to create a failover cluster, configure storage and networking, and deploy and manage the clustered roles and features is assumed.

It is also assumed that customers who will use the Copy Cluster Roles Wizard to migrate highly available virtual machines have a basic knowledge of how to create, configure, and manage highly available Hyper-V virtual machines.

What this guide does not provide

This guide does not provide instructions for migrating clustered roles by methods other than using the Copy Cluster Roles Wizard.

This guide identifies clustered roles that require special handling before and after a wizard-based migration, but it does not provide detailed instructions for migrating any specific role or feature. To find out requirements and dependencies for migrating a specific Windows Server role or feature, see Migrate Roles and Features to Windows Server 2012 R2 .

This guide does not provide detailed instructions for migrating a highly available virtual machine (HAVM) by using the Copy Cluster Roles Wizard. For a full discussion of migration options and requirements for migrating HAVMs to a Windows Server 2012 R2 failover cluster, and step-by-step instructions for performing a migration by using the Copy Cluster Roles Wizard, see Hyper-V: Hyper-V Cluster Migration .

Planning considerations for migrations between failover clusters

As you plan a migration to a failover cluster running Windows Server 2012 R2, consider the following:

For your cluster to be supported by Microsoft, the cluster configuration must pass cluster validation. All hardware used by the cluster should be Windows logo certified. If any of your hardware does not appear in the Windows Server Catalog in hardware certified for Windows Server 2012 R2, contact your hardware vendor to find out their certification timeline.

In addition, the complete configuration (servers, network, and storage) must pass all tests in the Validate a Configuration Wizard, which is included in the Failover Cluster Manager snap-in. For more information, see Validate Hardware for a Failover Cluster .

Hardware requirements are especially important if you plan to continue to use the same servers or storage for the new cluster that the old cluster used. When you plan the migration, you should check with your hardware vendor to ensure that the existing storage meets certification requirements for use with Windows Server 2012 R2. For more information about hardware requirements, see Failover Clustering Hardware Requirements and Storage Options .

The Copy Cluster Roles Wizard assumes that the migrated role or feature will use the same storage that it used on the old cluster. If you plan to migrate to new storage, you must copy or move of data or folders (including shared folder settings) manually. The wizard also does not copy any mount point information used in the old cluster. For information about handling mount points during a migration, see Cluster Migrations Involving New Storage: Mount Points .

Migration scenarios that use the Copy Cluster Roles Wizard

When you use the Copy Cluster Roles Wizard for your migration, you can choose from a variety of methods to perform the overall migration. This guide provides step-by-step instructions for the following two methods:

Create a separate failover cluster running Windows Server 2012 and then migrate to that cluster . In this scenario, you migrate from a multi-node cluster running Windows Server 2008 R2, Windows Server 2012, or Windows Server 2012 R2. For more information, see Migrate Between Two Multi-Node Clusters: Migration to Windows Server 2012 R2 .

Perform an in-place migration involving only two servers . In this scenario, you start with a two-node cluster that is running Windows Server 2008 R2 SP1 or Windows Server 2012, remove a server from the cluster, and perform a clean installation (not an upgrade) of Windows Server 2012 R2 on that server. You use that server to create a new one-node failover cluster running Windows Server 2012 R2. Then you migrate the clustered services and applications from the old cluster node to the new cluster. Finally, you evict the remaining node from the old cluster, perform a clean installation of Windows Server 2012 R2 and add the Failover Clustering feature to that server, and then add the server to the new failover cluster. For more information, see

Основная задача статьи наглядно показать, как развернуть отказоустойчивый кластер MS SQL Server 2012 . Материал написан и будет интересен для новичков. Бывалые гуру и все, кто уже знаком с этим вопросом, вряд ли найдут что-то новое и полезное для себя лично.

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

Этап 1 - Подготовка

Основные требования к аппаратному и программному обеспечению:

• Наличие минимум 2-х узлов(физических/виртуальных), СХД
• MS Windows Server, MS SQL ServerСХД
• СХД
  1. Доступный iSCSI диск для баз данных
  2. Доступный iSCSI диск для MSDTC
  3. Quorum диск

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

• Windows Server 2012R2 с ролями AD DS, DNS, DHCP(WS2012R2AD)
• Хранилище iSCSI*
• 2xWindows Server 2012R2(для кластера WS2012R2C1 и WS2012R2C2)
• Windows Server 2012R2 с поднятой службой сервера 1С (WS2012R2AC)

*как вариант можно использовать Роль хранилища на Windows Server 2012R2 , софтверное решение от StarWind или реальное сетевое устройство iSCSI

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

Вначале вводим в домен сервера WS2012R2C1 и WS2012R2C2 на каждом из них устанавливаем роль "Отказоустойчивая кластеризация"
После установки роли запускаем оснастку "Диспетчер отказоустойчивости кластеров" и переходим в Мастер создания кластеров где конфигурируем наш отказоустойчивый кластер: создаем Quorum (общий ресурс) и MSDTC(iSCSI).

Этап 2 - Установка MS SQL Server

Для установки нам понадобится установочный дистрибутив MS SQL Server. Запустим мастер установки и выберем вариант установки нового экземпляра кластера:

Внимательно читаем и принимаем лицензионное соглашение:

Получаем доступные обновления:

Проходим проверку конфигурации (Warning MSCS пропускаем):

Выбираем вариант целевого назначения установки:

Выбираем компоненты которые нам необходимы (для поставленной задачи достаточно основных):

Еще одна проверка установочной конфигурации:

Проверка доступного пространства:

Выбираем диск для расположения баз данных кластера:

Конфигурация сетевого интерфейса кластера (рекомендуется указать адрес вручную):

Указываем данные администратора (можно завести отдельного пользователя для MSSQL):

Один из важных этапов - эта выбор порядка сортировки (Collation) после инсталляции изменить крайне проблематично:

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

Выбор директорий хранения общих файлов кластера (в версиях MS SQL Server 2012 и старше TempDB можно хранить на каждой ноде и не выносить в общее хранилище):

Еще пару проверок:

Наконец приступаем к установке (процесс может занять длительное время):

Настройка и установка базовой ноды закончена, о чем нам сообщает "зеленый" рапорт

Этап 3 - добавление второй ноды в кластер MSSQL

Дальше необходимо добавить в кластер вторую ноду, т.к. без нее об отказоустойчивости говорить не приходится.
Настройка и установка в разы проще. На втором сервере (ВМ) запускаем мастер установки MS SQL Server:

• Проходим стартовый тест
• Вводим лицензионный ключ:
• Читаем и принимаем лицензионное соглашение:
• Получаем обновления:
• Проходим тесты по выполнению требований для установки ноды (MSCS warning - пропускаем):

Выбираем в какой кластер добавлять ноду:

Просматриваем и принимаем сетевые настройки экземпляра кластера:

Указываем пользователя и пароль (тоже что и на первом этапе):

Опять тесты и процесс установки:

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

Поздравляю установка закончена.

Этап 4 - проверка работоспособности

Удостоверимся, что все работает как надо. Для этого перейдем в оснастку "Диспетчер отказоустойчивого кластера":

На данный момент у нас используется вторая нода(WS2012R2C2) в случае сбоя произойдет переключение на первую ноду(WS2012R2C1).
Попробуем подключиться непосредственно к кластеру сервера MSSQL, для этого нам понадобится любой компьютер в доменной сети с установленной Management Studio MSSQL. При запуске указываем имя нашего кластера и пользователя (либо оставляем доменную авторизацию).