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

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

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

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

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

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

Разработка вычислительных кластеров не является сильной стороной Microsoft. Об этом свидетельствует, в том числе, тот факт, что разработки компании не попали в список Top-500 суперкомпьютеров. Поэтому совершенно логично, что в линейке Windows Server 2012 отсутствует редакция HPC (High-performance computing -высокопроизводительные вычисления).

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

Кластеры в Windows.

Впервые поддержка кластеров была реализована компанией Microsoft еще в операционной системе в Windows NT 4 Server Enterprise Edition в виде технологии Microsoft Cluster Service (MSCS). В операционной системе Windows Server 2008 она превратилась в компонент Failover Clustering. По сути это кластеры с обработкой отказа или высокодоступные кластеры, хотя иногда их не вполне корректно называют отказоустойчивыми.

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

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

С момента первой реализации, поддержка кластеров в Windows существенно изменилась. Была реализована поддержка файловых и сетевых служб, позже SQL Server (в операционной системе Windows Server 2000), Exchange Server (в Windows Server 2003), и другие стандартные службы и роли, включая Hyper-V (в операционной системе Windows Server 2008). Была улучшена масштабируемость (до 64 узлов в Windows Server 2012), список кластеризуемых сервисов был расширен.

Поддержка виртуализации, а также позиционирование Windows Server как облачной операционной системы, стали поводом для дальнейшего развития поддержки кластеров, поскольку высокая плотность вычислений предъявляет высокие требования к надежности и доступности инфраструктуры. Поэтому, начиная с операционной системы Windows Server 2008, именно в этой области сосредоточена основная масса усовершенствований.

В операционной системе Windows Server 2008 R2 реализованы общие тома кластера Hyper-V (CSV), позволяющие узлам одновременно обращаться к одной файловой системе NTFS. В результате несколько кластерных виртуальных машин могут использовать один адрес LUN и мигрировать с узла на узел независимо.

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

Кластеры в Windows Server 2012.

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

SMB 3.0

Новая версия протокола SMB 3.0 используется для сетевого обмена данными. Этот протокол востребован при выполнении чтения, записи и других файловых операций на удаленных ресурсах. В новой версии реализовано большое количество усовершенствований, которые позволяют оптимизировать работу SQL Server, Hyper-V и файловых кластеров. Обратим внимание на следующие обновления:

• прозрачная отказоустойчивость . Это новшество обеспечивает непрерывность выполнения операций. При сбое одного из узлов файлового кластера текущие операции автоматически передаются другому узлу. Благодаря этому нововведению стала возможной реализация схемы Active-Active с поддержкой до 8 узлов.
• масштабирование. Благодаря новой реализации общих томов кластера (версия 2.0) существует возможность одновременного доступа к файлам через все узлы кластера, за счет чего достигается агрегация пропускной способности и осуществляется балансировка нагрузки.
• SMB Direct. Реализована поддержка сетевых адаптеров с технологией RDMA. Технология RDMA (удаленный прямой доступ к памяти) позволяет передавать данные непосредственно в память приложения, существенно освобождая центральный процессор.
• SMB Multichannel. Позволяет агрегировать пропускную способность и повышает отказоустойчивость при наличии нескольких сетевых путей между сервером с поддержкой SMB 3.0 и клиентом.

Необходимо сказать, что для использования этих возможностей поддержка SMB 3.0 должна присутствовать на обоих концах соединения. Компания Microsoft рекомендует использование серверов и клиентов одного поколения (в случае с Windows Server 2012 такой клиентской платформой является Windows 8). К сожалению, на сегодня Windows 7 поддерживает только SMB версии 2.1.

Storage Spaces.

Технология Storage Spaces реализована впервые в операционных системах Windows Server 2012 и Windows 8. Реализована поддержка новой файловой системы ReFS, которая обеспечивает функции повышения отказоустойчивости. Есть возможность назначения дисков в пуле для горячей замены (в случае отказа других носителей или для быстрой замены исчерпавшего свой ресурс SSD). Кроме того, расширены возможности тонкой настройки с использованием PowerShell.

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

• простой (является аналогом RAID 0);
• зеркало (двухстороннее зеркало является аналогом RAID1, трехстороннее зеркало представляет собой более сложную схему наподобие RAID 1E)
• с контролем четности (является аналогом RAID 5. Данный вариант обеспечивает минимальный перерасход пространства при минимальной отказоустойчивости).

Технология Storage Spaces не является абсолютным новшеством. Похожие возможности были давно реализованы в Windows Server, например в форме динамических дисков. Технология Storage Spaces позволяет сделать использование всех этих возможностей более удобными и обеспечить новый уровень использования. Среди прочих преимуществ Storage Spaces необходимо отметить тонкую инициализацию (thin provisioning), которая дает возможность назначать виртуальным дискам размеры сверх доступных в реальности из расчета на добавление в соответствующий пул новых накопителей впоследствии.

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

Технология Storage Spaces предлагает отказ от RAID-контроллеров и дорогих систем хранения, перенеся из логику на уровень операционной системы. Эта идея раскрывает все свои достоинства и оказывается достаточно привлекательной вместе с еще одним новшеством.

Scale-Out File Server (SOFS).

Еще одним новшеством является режим кластеризуемой роли File Server в Windows Server 2012, который получил название Scale-Out File Server. Теперь реализована поддержка двух типов кластеризации, названия которых полностью звучат как File Sever for General Use и Scale-Out File Server (SOFS) for application data. Каждая из технологий имеет свои сферы применения, а также свои достоинства и недостатки.

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

Помимо отличных характеристик отказоустойчивости это обеспечивает повышение пропускной способности при условии рационального проектирования сетевой архитектуры. Проксирующая файловая система CSV 2.0 (CSVFS) позволяет уменьшить влияние CHKDSK, позволяя утилите выполнять необходимые операции, сохраняя при этом возможность работы с томом активных приложений. Реализовано кэширование чтения с CSV. Использование CSV обеспечивает простоту и удобство развертывания и управления. Пользователю нужно создать обычный кластер, настроить том CSV и активировать роль файлового сервера в режиме Scale-Out File Server for application data.

Благодаря простоте и функциональности предложенного решения сформировался новый класс оборудования «кластер-в-коробке» (Сluster-in-a-Box, CiB). Как правило, это шасси с двумя блейд-серверами и дисковым массивом SAS JBOD с поддержкой Storage Spaces. Здесь важно, чтобы SAS JBOD были двухпортовыми, и имелся SAS HBA для реализации перекрестного подключения.

Такая организация системы ориентирована именно на поддержку SOFS. Учитывая, что iSCSI target стандартно интегрирован в Windows Server 2012 и также может быть кластеризована, таким образом может реализовать «самодельную» систему хранения данных на базе всецелевой операционной системы.

Однако следует иметь ввиду, что владельцем CSV по-прежнему является один из узлов, который отвечает за все операции с метаданными. При большом количестве метаданных может наблюдаться снижение производительности, поэтому для SOFS не рекомендуется использовать сценарий Information Worker, тогда как Hyper-V и SQL Server идеально подходят для этого, в том числе благодаря функциям агрегации пропускной способности.

Другие новшества технологий кластеризации Windows.

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

Была расширена поддержка виртуализации за счет существенного упрощения создания гостевых кластеров (из виртуальных машин). В отличие от Windows Server 2008 R2, где для этого нужно было предоставить iSCSI Target в общее пользование виртуальных машин, в операционной системе Windows Server 2012 появилась функция, позволяющая виртуализировать FC-контроллер (по аналогии с сетевыми адаптерами), за счет чего виртуальные машины получают возможность непосредственного доступ к LUN. Реализован и более простой вариант с использованием общей сетевой папки SMB 3.0 для гостевых Windows Server 2012.

Одной из важных, но нетривиальных задач является установка программных обновлений в кластере. При этом может потребоваться перезагрузка узлов, поэтому процедура должна контролироваться. В операционной системе Windows Server 2012 предлагается инструмент Cluster-Aware Updating, который работает следующим образом: один из узлов назначается координатором и следит за наличием обновлений, загружает их на остальные узлы и выполняет поочередное обновление узлов, начиная с тех, которые загружены меньше всего. Благодаря этому доступность кластера сохраняется на максимально возможном уровне в течение всего процесса обновления.

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

Новшества в Windows Server 2012 R2.

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

Высокодоступные виртуальные машины.

Упрощена процедура создания гостевых кластеров, поскольку теперь появилась возможность использовать в качестве общего хранилища обычные VHDX, которые внутри виртуальной машины будут представлены как Shared SAS-диски. При этом сами VHDX должны быть размещены на CSV или в общих папках SMB 3.0. При этом в виртуальных машинах могут использоваться как Windows Server 2012 R2, так и Windows Server 2012 (с обновленными интеграционными компонентами).

Опция DrainOnShutdown призвана избавить системных администраторов от ошибок и лишней работы. Функция активирована по умолчанию и при плановых перезагрузках или выключениях заранее переводит узел в такой режим обслуживания при котором эвакуируются все кластеризованные роли. При этом происходит миграция активных виртуальных машин на другие узлы кластера Hyper-V.

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

Кворум.

Кроме динамического кворума в Windows Server 2012 R2 реализован еще и динамический диск-свидетель (witness). При изменении числа узлов его голос может быть автоматически учтен, так, чтобы общее число голосов оставалось нечетным. В случае, если сам диск окажется недоступным, его голос будет просто обнулен. Такая схема позволяет полностью положиться на автоматические механизмы, отказавшись от моделей кворума.

Увеличена надежность работы кластеров, размещенных на двух площадках. Часто при такой реализации на каждой площадке находится ровно половина узлов, поэтому нарушения коммуникации между площадками может возникнуть проблема с формированием кворума. Хотя с большинством подобных ситуаций успешно справляется механизм динамического кворума, в Windows Server 2012 R2 существует возможность назначить одной из площадок низкий приоритет, для того, чтобы в случае сбоя кластер всегда функционировал на основной площадке. В случае, если кластер был запущен с принудительным кворумом, то при восстановлении связи с удаленной площадкой службы кластера будут перезапущены в автоматическом режиме и весь кластер будет вновь объединен.

CSV 2.1

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

Целый ряд новшеств в CSV обеспечивает более эффективное использование SOFC и Storage Spaces. Добавлена поддержка файловой системы ReFS, которая обладает более совершенной, чем NTFS внутренней организацией. Скорее всего постепенно эта файловая система займет ведущее положение в продуктах компании Microsoft. Также в Windows Server 2012 R2 реализован механизм дедупликации, который ранее был прерогативой всецелевого файлового сервера. Активация дедупликации приводит к отключению CSV Block Cache, однако в некоторых случаях она может быть достаточно эффективной. Тома CSV могут создаваться на дисковых пространствах с контролем четности.

В Windows Server 2012 R2 возможность комбинировать накопители различных типов приобрела особый смысл с многоуровневыми пространствами. Появилась возможность формировать два уровня быстрый (на основе SSD) и емкий (на основе жестких дисках) и при создании виртуального диска выделять определенный объем из каждого из них. Далее в соответствии с некоторым расписанием содержимое виртуального диска будет анализироваться и размещаться блоками по 1 МБ на более быстрых или медленных носителях в зависимости от востребованности. Другим применением многоуровневых пространств является реализация кэша с обратной записью на SSD. В моменты пиковых нагрузок запись осуществляется на быстрые твердотельные накопители, а позже холодные данные перемещаются на более медленные жесткие диски.

Новшества, касающиеся CSV и Storage Spaces, являются наиболее существенными в Windows Server 2012 R2. На их основе можно разворачивать не просто надежные файловые серверы, а мощные и гибкие системы хранения данных с прекрасными возможностями масштабирования и отличной отказоустойчивостью, предоставляющие в распоряжение пользователя широкий спектр современных инструментов.

После нескольких лет молчания, решил поделиться опытом по развертыванию отказоустойчивого кластера на основе Windows Server 2012.
Постановка задачи: Развернуть отказоустойчивый кластер для размещения на нем виртуальных машин, с возможностью выделения виртуальных машин в отдельные виртуальные подсети (VLAN), обеспечить высокую надежность, возможность попеременного обслуживания серверов, обеспечить доступность сервисов. Обеспечить спокойный сон отделу ИТ.

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

1. Сервер HP ProLiant DL 560 Gen8 4x Xeon 8 core 64 GB RAM 2 шт.
2. SAS Хранилище HP P2000 на 24 2,5» дисков 1 шт.
3. Диски для хранилища 300 Gb 24 шт. //С объемом не густо, но к сожалению бюджеты такие бюджеты…
4. Контроллер для подключения SAS производства HP 2 шт.
5. Сетевой адаптер на 4 1Gb порта 2 шт. //Можно было взять модуль под 4 SFP, но у нас нет оборудования с поддержкой 10 Gb, гигабитного соединения вполне достаточно.

Естественно обновляем BIOS и Firmware с официального сайта.
Организация подключений:


У нас на самом деле подключено в 2 разных коммутатора. Можно подключить в 4 разных. Я считаю, что достаточно 2х.
На портах коммутаторов, куда подключены сервера необходимо сменить режим интерфейса с access на trunk, для возможности разнесения по виртуальным подсетям.

Пока качаются обновления на свежеустановленную Windows Server 2012, настроим дисковое хранилище. Мы планируем развернуть сервер баз данных, посему решили 600 Гб использовать под базы данных, остальное под остальные виртуальные машины, такая вот тавтология.

Создаем виртуальные диски:

• Диск raid10 на основе Raid 1+0 из 4 дисков +1 spare
• Диск raid5 на основе Raid 5 из 16 дисков +1 spare
• 2 диска - ЗИП

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

Теперь необходимо создать разделы.

• raid5_quorum - Так называемый диск-свидетель (witness). Необходим для организации кластера из 2 нод.
• raid5_store - Здесь мы будем хранить виртуальные машины и их жесткие диски
• raid10_db - Здесь будет хранится жесткий диск виртуальной машины MS SQL сервера

Назначаем (map) наши разделы на порты sas контроллеров хранилища.
Обязательно необходимо включить feature Microsoft Multipath IO, иначе при сервера к обоим контроллерам хранилища в системе будет 6 дисков, вместо 3х, и кластер не соберется, выдавая ошибку, мол у вас присутствуют диски с одинаковыми серийными номерами, и этот визард будет прав, хочу я вам сказать.

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

1. Подключили 1 сервер к 1 контроллеру хранилища
2. В хранилище появится 1 подключенный хост - дайте ему имя. Советую называть так: имясервера_номер контроллера (A или B)
3. И так, пока не подключите оба сервера к обоим контроллерам.

На коммутаторах, к которым подключены сервера необходимо создать 3 виртуальных подсети (VLAN):

1. ClusterNetwork - здесь ходит служебная информаци кластера (хэртбит, регулирование записи на хранилище)
2. LiveMigration - тут думаю все ясно
3. Management - сеть для управления

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

Заводим сервера в домен. Устанавливаем роль Hyper-V, Failover Cluster.
В настройках Multipath IO включаем поддержку SAS устройств.
Обязательно перезагружаем.

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

Переименуйте все 4 сетевых интерфейса в соответствии их физическим портам (у нас это 1,2,3,4).
Настраиваем NIC Teaming - Добавляем все 4 адаптера в команду, Режим (Teaming-Mode) - Switch Independent, Балансировка нагрузки (Load Balancing) - Hyper-V Port. Даем имя команде, я так и назвал Team.
Теперь необходимо поднять виртуальный коммутатор.
Открываем powershell и пишем:

New-VMSwitch "VSwitch" -MinimumBandwidthMode Weight -NetAdapterName "Team" -AllowManagementOS 0

Создаем 3 виртуальных сетевых адаптера.
В том же powershell:

Add-VMNetworkAdapter –ManagementOS –Name "Management" Add-VMNetworkAdapter –ManagementOS –Name "ClusterNetwork"Add-VMNetworkAdapter –ManagementOS –Name "Live Migration"

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

Настройте адресацию в соответствии с вашими планами.

Переводим наши адапетры в соответствующие VLAN’ы.
В любимом powershell:

Set-VMNetworkAdapterVlan -ManagementOS -Access -VlanId 2 -VMNetworkAdapterName "Management" -Confirm Set-VMNetworkAdapterVlan -ManagementOS -Access -VlanId 3 -VMNetworkAdapterName "ClusterNetwork" -Confirm Set-VMNetworkAdapterVlan -ManagementOS -Access -VlanId 4 -VMNetworkAdapterName "Live Migration" -Confirm

Теперь нужно настроить QoS.

При настройке QoS by weight (по весу), что является best practice, по заявлению Microsoft, советую расставить вес так, чтобы в общей сумме получилось 100, тогда можно считать, что значение указанное в настройке есть гарантированный процент полосы пропускания. В любом случае считается процент по формуле:

Процент полосы пропускания = установленный вес * 100 / сумма всех установленных значений веса

Set-VMSwitch “VSwitch” -DefaultFlowMinimumBandwidthWeight 15

Для служебной информации кластера.

Set-VMNetworkAdapter -ManagementOS -Name “Cluster” -MinimumBandwidthWeight 30

Для управления.

Set-VMNetworkAdapter -ManagementOS -Name "Management" -MinimumBandwidthWeight 5

Для Live Migration.

Set-VMNetworkAdapter -ManagementOS -Name “Live Migration” -MinimumBandwidthWeight 50

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

Давайте так и сделаем.
В нашем ненаглядном:

$n = Get-ClusterNetwork “ClusterNetwork” $n.Metric = 1000 $n = Get-ClusterNetwork “LiveMigration” $n.Metric = 1050$n = Get-ClusterNetwork “Management” $n.Metric = 1100

Монтируем наш диск-свидетель на ноде, с которой будем собирать кластер, форматируем в ntfs.

В оснастке Failover Clustering в разделе Networks переименуйте сети в соответствии с нашими адаптерами.

Все готово к сбору кластера.

В оснастке Failover Clustering жмем validate. Проходим проверку. После чего создаем кластер (create cluster) и выбираем конфигурацию кворума (quorum configuration) Node and Disk majority, что также считается лучшим выбором для кластеров с четным количеством нод, а учитывая, что у нас их всего две - это единственный выбор.

В разделе Storage оснастки Failover Clustering, добавьте ваши диски. А затем по очереди добавляйте их как Cluster Shared Volume (правый клик по диску). После добавления в папке C:\ClusterStorage появится символическая ссылка на диск, переименуйте ее в соответствии с названием диска, добавленного как Cluster Shared Volume.

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

Прошу сообщать об ошибках в ПМ.

Советую к прочтению: Microsoft Windows Server 2012 Полное руководство. Рэнд Моримото, Майкл Ноэл, Гай Ярдени, Омар Драуби, Эндрю Аббейт, Крис Амарис.

P.S.: Отдельное спасибо господину Салахову, Загорскому и Разборнову, которые постыдно были забыты мною при написании данного поста. Каюсь >_< XD

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

Общие файлы.vhdx

Большой интерес специалистов вызвала возможность использования общих файлов VHD (.vhdx) для кластеров Hyper-V на базе гостевых систем, что означает устранение необходимости в присоединении фактического хранилища к гостевым виртуальным машинам. Общие файлы.vhdx должны находиться на локальных общих томах кластера (CSV) или на удаленном масштабируемом файловом сервере.

Создаваемый файл.vhdx для виртуальной машины теперь можно маркировать как общий. Для этого в диспетчере Hyper-V поставьте флажок Enable virtual hard disk sharing в разделе установки дополнительных функций (Advanced Features) окна настройки параметров виртуальной машины.

Если используется диспетчер виртуальных машин VMM Microsoft System Center, то на странице настройки оборудования установите параметр Share the disk across the service tie. Затем этот же файл.vhdx добавьте к каждой виртуальной машине и установите тот же флажок. Общие VHD, прикрепляемые к гостевым виртуальным машинам, выглядят как диски Serial Attached SCSI (SAS). При необходимости для выполнения настройки файлов, vhdx можно воспользоваться средствами Windows PowerShell. В качестве примера предположим, что нам требуется создать файл.vhdx размером 30 Гбайт и назначить его общим VHD для двух виртуальных машин. Сначала создадим файл.vhdx с помощью следующей команды:

New-VHD -Path C:\ClusterStorage\Volume1\ Shared.VHDX"

Fixed -SizeBytes 30 GB

Затем назначим его общим файлом.vhdx для каждой из двух виртуальных машин:

Add-VMHardDiskDrive -VMName Nodel" -Path C:\ClusterStorage\Volume1\ Shared.VHDX"

ShareVirtualDisk Add-VMHardDiskDrive -VMName Node2" -Path C:\ClusterStorageWolume1\Shared. VHDX4-ShareVirtualDisk

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

Более подробную информацию о настройках общих файлов.vhdx можно найти на веб-странице Virtual Hard Disk Sharing Overview (http://technet.Microsoft. com/en-us/library/dn281956.aspx).

Новый процесс выключения узла

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

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

В Server 2012 R2 процесс выключения узла дополнен новой функцией - очисткой при выключении и размещением на наиболее доступном узле.

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

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

Новый процесс включен по умолчанию. При необходимости администратор может его включать и выключать вручную с помощью общего свойства кластера DrainOnShutdown. Для включения введите следующую команду PowerShell:

(Get-Cluster).DrainOnShutdown = 1 Для выключения: (Get-Cluster).DrainOnShutdown = О

Определение состояния работоспособности для сетей виртуальных машин

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

Эта функция включена по умолчанию для всех сетей, доступных для виртуальных машин. При необходимости ее можно выключить для некоторых сетей с помощью диспетчера Hyper-V. Для этого достаточно снять флажок Protected network в разделе установки дополнительных функций Advanced Features окна настройки параметров виртуальных машин.

Новая панель мониторинга кластеров

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

Новая панель облегчает управление средами с большим количеством кластеров, позволяя быстро проверять состояние ролей и узлов (включен, выключен, вышел из строя) и отслеживать события, требующие анализа. Все отображаемые элементы представляют собой гиперссылки, позволяющие щелчком открывать нужную информацию. Например, щелчком на Critical: 3, Error: 1, Warning: 2 открывается список отфильтрованных событий, которые можно проанализировать для выявления проблемы.

Усовершенствования для CSV

В Server 2012 R2 реализован ряд усовершенствований для общих томов кластера cluster shared volume (CSV), которые включают оптимизацию политики размещения CSV и добавление проверки зависимостей. Политика размещения CSV теперь предусматривает равномерное распределение принадлежности дисков CSV между узлами. Для примера предположим, что в системе функционируют три узла и четыре диска CSV, каждый из которых используется пятью виртуальными машинами. Когда все узлы функционируют, два из них имеют один диск CSV и пять виртуальных машин. На третьем узле располагаются два диска CSV, каждый из которых используется пятью виртуальными машинами. В случае добавления четвертого узла кластер сразу же автоматически передает ему один из дисков CSV. При этом все виртуальные машины, использующие этот диск CSV, переносятся на новый узел в режиме динамической миграции. Таким образом, кластер реализует более равномерное распределение нагрузки между узлами.

Еще одним новшеством является добавление проверки зависимостей. Узел, не являющийся владельцем (или координатором) диска CSV, должен подключаться к координатору по протоколу Server Message Block (SMB) для пересылки обновлений метаданных, необходимых для данного диска. Для этой цели узел-координатор имеет внутренний общий ресурс, к которому подключаются другие узлы. Однако для работы такой модели нужно, чтобы функционировала служба сервера. Если служба по какой-либо причине не работает, узлы не могут устанавливать SMB-соединение с узлом-координатором. При этом все обновления метаданных кэшируются, но не отсылаются из-за отсутствия способа их передачи. Чтобы разрешить эту ситуацию, приходится вручную передавать владение диском CSV другому узлу.

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

Усовершенствование тестов для проверки сетевых настроек

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

В Server 2012 R2 тест проверки работоспособности сетевых подключений предусматривает контроль возможности установления соединения через порт 3343. Ранее в ходе диагностики проблем связи проверка этого порта не всегда выполнялась первой. С появлением нового теста такая проверка может осуществляться в первую очередь. Если этот порт является источником проблемы, вы сэкономите массу времени, затрачиваемого на поиск причин возникновения ошибок.

Усовершенствование динамического кворума

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

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

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

В Server 2012 R2 добавление ресурса-свидетеля предпочтительно в любом случае. Благодаря новой функции динамического свидетеля кластер дает ресурсу-свидетелю голос или лишает его голоса в зависимости от конкретной ситуации. Кластер также по мере необходимости динамически изменяет веса узлов при выходе их из строя или при добавлении в кластер. Диспетчер отказоустойчивого кластера позволяет сразу видеть эти изменения без необходимости выполнять специальные запросы к узлам. Чтобы увидеть веса, в диспетчере отказоустойчивости кластеров выберите элемент Nodes, как показано на экране 5. Заметим, что в настройках кворума по-прежнему существует возможность при желании лишить узел голоса.

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

В Server 2012 R2 введено общее свойство кластера, позволяющее определить, какой из сайтов продолжит работу. С помощью свойства LowerQuorumPriorityNodelD можно указать узел, который утратит голос в случае раскладки «50 на 50».

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

(Get-ClusterNode -Name "Имя узла“).И Предположим, что в результате выполнения этих запросов выяснилось, что внешние узлы имеют идентификаторы 4, 5 и 6. Чтобы вывести эти узлы из работы при раскладе «50 на 50», введем следующие команды:

(Get-Cluster).LowerQuorumPriorityNodelD = 4

(Get-Cluster).LowerQuorumPriorityNodelD = 5

(Get-Cluster).LowerQuorumPriorityNodelD = 6

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

Другие изменения

Кластеризация с обходом отказа в Server 2012 R2 пополнилась многими полезными новшествами. В этой статье мы рассказали лишь о некоторых из них.