Отказоустойчивый iscsi кластер на windows server 2012 r2

Дата: 19.05.2015 Автор Admin

В данной статье мы рассмотрим как настроить Отказоустойчивый ISCSI кластер на Windows Server 2012 R2.Для настройки нам понадобятся 2 сервера.

Кластер в данной статье будет настраиваться по следующей схеме:

Соответственно у вас должна быть сеть хранения данных, подключенная по FC, SAS или ISCSI (необходим ISCSI протокол версии не ниже iSCSI-3)

Должна быть настроена LAN сеть на каждом узле кластера, и отдельная сеть между кластерами.

На первом сервере включаем компонент «отказоустойчивая кластеризация»

Нажимаем далее, и выбираем установить.

По аналогии устанавливаем компонент на втором сервере.

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

Открываем Диспетчер отказоустойчивости кластеров.

Выбираем создать кластер

Добавляем сервера (узлы кластера)

Далее по желанию запускаем проверочные тесты.

Вводим имя кластера и адреса.

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

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

Далее в консоли должен появится созданный кластер.

Добавляем роль ISCSI target на каждый узел кластера.

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

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

Выбираем «Настроить роль»

Выбираем роль ISCSI сервера

Указываем название кластера и сетевые адреса.

Выбираем диск кластера.

Подтверждаем создание роли.

Дожидаемся установки роли.

Теперь перейдем к настройке ISCSI сервера.

На одном из узлов кластера открываем диспетчер сервера, в нем открываем файловые службы и выбираем ISCSI.

Запускаем мастер создания ISCSI диска.

Выбираем кластер и общий кластерный диск.

Вводим название диска.

Указываем размер диска и его тип.

Далее выбираем пункт — «Новая цель ISCSI»

Далее вводим название цели ISCSI.

Указываем каким серверам можно подключаться к ISCSI цели.

Указываем учетные данные для подключения.

Далее нажимаем «Создать» и ожидаем окончания работы мастера.

Готово! Теперь указанные клиенты могут подключаться к кластеру ISCSI. Для подключения нужно использовать DNS имя кластера.

Удачной установки!

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

.

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

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

Рисунок. Просмотр компонентов кластера

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

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

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

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

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

Экран 1. Запуск мастера добавления ролей и компонентов

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

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

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

Экран 2. Добавление средства отказоустойчивого кластера и инструментов

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

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

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

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

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

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

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

Экран 4. Просмотр отчета о проверке

Создание отказоустойчивого кластера

На данном этапе можно создать кластер, начиная с любого узла кластера. Я организовал кластер, начав на первом узле (WS2012-N1).

Чтобы создать новый кластер, выберите ссылку Create Cluster на панели Management или панели Actions, как показано на экране 5.

Экран 5. Запуск мастера создания кластера

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

Экран 6. Выбор серверов для кластера

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

Экран 7. Настройка точки доступа кластера

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

Экран 8. Подтверждение параметров, выбранных при создании кластера

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

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

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

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

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

Экран 9. Добавление CSV

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

* C:ClusterStorageVolume1
* C:ClusterStorageVolume2

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

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

Экран 10. Добавление роли виртуальной машины

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

Экран 11. Выбор виртуальных машин, которым необходимо обеспечить высокую надежность

Internet Small Computer System Interface (iSCSI) — это протокол передачи данных, предназначенный для обмена данными между серверами и системами хранения данных (Storage Area Network, SAN). iSCSI представляет из себя комбинацию протокола SCSI и стека протоколов TCP/IP и предназначен для передачи блоков данных через сети Ethernet. Управляющие команды SCSI передаются внутри IP-пакетов, а протокол TCP обеспечивает управление потоком и надежность передачи данных.

При использовании iSCSI данные между сервером и системой хранения передаются блоками, в необработанном виде. Это позволяет использовать SAN практически так же, как если бы они были подключены к серверу напрямую, а не по сети. Хост-система может создавать на SAN логические разделы, форматировать их и использовать как обычные локальные жесткие  диски. В этом заключается основное отличие SAN от сетевых хранилищ (Network Area Storage, NAS), которые работают на уровне файловой системы и используют протоколы передачи файлов, такие как SMB или CIFS.

Технология iSCSI была разработана как более дешевая альтернатива Fibre Channel (FC). Системы на базе iSCSI поддерживают стандартные протоколы и могут быть построены на базе любой существующей сетевой инфраструктуры, поддерживающей протокол IP. Для работы iSCSI может использовать самые обычные сетевые устройства (коммутаторы, маршрутизаторы, сетевые адаптеры и т.п), тогда как для FC требуются специальные HBA-адаптеры, оптические кабеля и прочее дорогостоящее оборудование.

Архитектура iSCSI является клиент-серверной и включает в себя следующие компоненты:

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

iSCSI Target — серверный компонент, слушающий клиентские запросы и обеспечивающий установку соединения между клиентом и сервером iSCSI. Кроме того, таргет связан с виртуальными дисками iSCSI, и после установки соединения все виртуальные диски, связанные с этим таргетом, становятся доступны через инициатор. В качестве iSCSI Target может выступать как специализированная СХД, так и обычный Windows сервер с установленной ролью iSCSI Target.

Виртуальные диски iSCSI — используются для разбиения дискового пространства на логические разделы (Logical Unit Number, LUN). В Windows Server 2012 iSCSI LUN представляют из себя обычные виртуальные диски формата VHDVHDX. Кстати, в Windows Server 2012 для iSCSI поддерживался только формат VHD, что ставило ограничение в 2ТБ на максимальный размер LUN. В Windows Server 2012 R2 используется формат VHDX, что позволяет создавать LUN-ы размером до 64ТБ.

А теперь остановимся и уточним некоторые моменты:

• На каждом iSCSI сервере может быть один или несколько iSCSI Target;
• Каждый iSCSI Target может быть подключен к одному или нескольким виртуальным дискам;
• Каждый iSCSI Target может обслуживать одно или несколько подключений от iSCSI Initiator;
• В свою очередь, каждый iSCSI Initiator может подключаться к одному или нескольким iSCSI Target и, следовательно, к одному или нескольким виртуальным дискам.

Кроме того, в Windows Server 2012 поддерживается loopback-конфигурация, в которой и Target и Initiator могут находиться на одном и том же сервере.

В операционных системах Microsoft поддержка iSCSI появилась довольно давно. Первая версия Microsoft iSCSI Initiator устанавливалась в качестве отдельного компонента в Windows 2000, Windows XP SP2 и Windows Server 2003 SP1, а начиная с Windows Server 2008 и Vista iSCSI Initiator был встроен в операционную систему.

Что касается iSCSI Target, то изначально он входил в специальную версию серверной ОС Windows Data Storage Server 2003, которая была предназначена для построения систем хранения и поставлялась только в предустановленом виде. Однако с 2011 года компонент Microsoft iSCSI Software Target 3.3 стал доступен для загрузки и установки на Windows Server 2008R2, а в Windows Server 2012 он полностью интегрирован в систему и устанавливается в качестве роли сервера.

На этом закончим теоретическую часть и приступим к практике. Для настройки возьмем самый простой вариант, в качестве подопытных используем два сервера с установленной Windows Server 2012 R2: SRV2 для роли iSCSI Target и SRV3 для iSCSI Initiator.

Запуск службы iSCSI Initiator

Для начала проверим состояние службы инициатора на SRV3. Для этого открываем Server Manager и в меню «Tools» выбираем пункт «iSCSI Initiator».

Как видите, по умолчанию служба не запущена. Нажав на «Yes» в диалоговом окне, мы стартуем службу iSCSI Initiator и поставим ее в режим автоматического запуска.

Затем в окне свойств переходим на вкладку «Configuration» и запоминаем значение IQN, оно пригодится нам при настройке сервера.

IQN (iSCSI qualified name) — это уникальный идентификатор, назначаемый для каждого iSCSI Target и Initiator. IQN формируется из даты (месяц и год) регистрации домена, официального имени домена, написанного в обратном порядке и любого произвольного имени, например имени сервера. Получается примерно так: iqn:1991-05.com.microsoft:srv3.contoso.com

Стартовать сервис iSCSI Initiator и установить режим его запуска можно и из консоли PowerShell, следующими командами:

Start-Service msiscsi
Set-Service msiscsi -StartupType automatic

Установка роли iSCSI Target Server

Теперь перейдем на SRV2 и приступим к настройке серверной части. Первое, что нам надо сделать — это установить на сервер роль iSCSI Target. Открываем Server Manager, переходим по ссылке «Add roles and features»

И выбираем роль «iSCSI Target Server», которая находится в разделе File and Storage ServicesFile and iSCSI Services.

Либо воспользуемся командой PowerShell:

Install-WindowsFeature -Name FS-iSCSITarget-Server

Подготовка диска

Теперь подготовим физический диск, который будет использоваться для хранения виртуальных iSCSI дисков. Специально для этой цели к серверу подключен новый жесткий диск размером 120Гб.  На данный момент диск неактивен (Offline). Для его активации в Server Manager переходим в раздел File and Storage Services -> Disks, кликаем на диске и переводим его в Online.

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

Выбираем физический диск, на котором будет создаваться том

указываем размер тома

и выбираем букву диска.

Затем выбираем для диска файловую систему, размер сектора и указываем метку тома. Здесь напомню, что виртуальные диски iSCSI можно создавать только на томах NTFS, новая файловая система ReFS (Resilient File System) не поддерживается.

Смотрим суммарную информацию, и если все правильно, то жмем «Create», запуская создание тома.

Те же действия можно проделать с помощью PowerShell. Находим нужный диск:

Get-Disk | where {$_.OperationalStatus -eq ″Offline″}

Переводим его в online:

Set-Disk -Number 1 -IsOffline $false

Инициализируем:

Initialize-Disk -Number 1

Создаем раздел:

New-Partition -DiskNumber 1 -UseMaximumSize -DriveLetter D

И форматируем его в NTFS:

Format-Volume -DriveLetter D -FileSystem NTFS -NewFileSystemLabel ″iSCSI Storage″

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

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

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

Даем диску имя и описание.

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

• Fixed size (фиксированного размера) — создаваемый диск сразу занимает весь выделенный объем. Это наиболее производительный, но наименее экономичный вариант;
• Dynamically expanding (динамически расширяемый) — изначально создается диск минимального размера, который затем динамически изменяется в зависимости от количества записанных на него данных. Наилучший вариант в плане использования дискового пространства;
• Differencing (разностный) — в этом варианте нужно указать расположение родительского диска, с которым будет связан создаваемый диск. Разностный диск может быть как фиксированным, так и динамическим, в зависимости от типа родителя.  У этого типа дисков есть свои преимущества, но использовать их для iSCSI лично я особого смысла не вижу.

Теперь нужно указать iSCSI Target, к которому будет подключен данный диск. Поскольку на сервере не создано ни одного таргета, выбираем «New iSCSI target».

Даем таргету имя и описание.

И указываем сервера, которые могут получить к нему доступ.

При выборе серверов можно воспользоваться двумя способами. Если инициатор находится на Windows Server 2012 или Windows 8, то можно просто нажать «Browse» и выбрать нужный сервер из списка. Для более старых систем надо вручную ввести идентификатор сервера. В качестве идентификатора можно указать IQN инициатора, DNS имя или IP-адрес сервера, либо MAC-адрес сетевого адаптера.

Идем дальше. На следующей странице можно настроить аутентификацию по протоколу CHAP между серверами. CHAP (Challenge Handshake Authentication Protocol) — это протокол для проверки подлинности партнера по подключению, основанный на использовании общего пароля или секрета. Для iSCSI можно задействовать как одностороннюю, так и двухстороннюю (reverse) проверку подлинности CHAP.

Проверяем правильность настроек и запускаем создание диска.

Попробуем сделать все то же с помощью PowerShell. Создадим еще один виртуальный iSCSI диск на 20ГБ командой:

New-IscsiVirtualDisk -Path D:iSCSIVirtualDisksiSCSI2.vhdx

Обратите внимание, что по умолчанию создается динамический диск, для создания VHD фиксированного размера надо воспользоваться ключом -UseFixed.

Теперь создаем второй iSCSI Target c именем iscsi-target-2 и в качестве сервера доступа укажем IQN SRV3:

New-IscsiServerTarget -TargetName iscsi-target-2 -InitiatorIds ″IQN:iqn.1991-05.com.microsoft:srv3.contoso.com″

И проверим результат командой:

Get-IscsiServerTarget | fl TargetName, LunMappings

Подключение

Возвращаемся на SRV3, открываем окно свойств инициатора, переходим на вкладку Discovery и жмем кнопку Discover Portal.

Вводим имя или IP-адрес портала и жмем ОК.

По умолчанию iSCSI использует все доступные IP-адреса, и если вы хотите, чтобы трафик iSCSI шел только через определенный сетевой интерфейс, то надо перейти в расширенные настройки и в поле «Connect using» указать нужный IP.

Теперь переходим на вкладку Targets, где должны отобразиться все доступные для подключения iSCSI Target. Выбираем нужный таргет и жмем «Connect».

Не забудьте отметить чекбокс «Add this connection to the list of Favorite Targets», который обеспечивает автоматическое подключение к таргету при выключении или перезагрузке машины.

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

То же самое можно выполнить с помощью PowerShell. Выводим список доступных таргетов:

Get-IscsiTarget | fl

И подключаемся к нужному:

Connect-IscsiTarget -NodeAddress ″iqn.1995-05.com.microsoft:srv2-iscsi-target-2-target″ -IsPersistent $true

Ключ -IsPersistent $true обеспечивает автоматическое подключение при выключении или перезагрузке.

Ну и для отключения можно воспользоваться командой Disconnect-IscsiTarge, вот так:

Disconnect-IscsiTarget -NodeAddress ″iqn.1995-05.com.microsoft:srv2-iscsi-target-2-target″ -Confirm:$false

Заключение

На этом настройка завершена. Как я говорил, это самый простой, базовый вариант настройки хранилища. В iSCSI имеется еще много интересных возможностей. Например, можно использовать службу имен iSCSI (iSNS) для простоты управления, многопутевой ввод-вывод (MPIO) для обеспечения отказоустойчивости, а для безопасности настроить аутентификацию по протоколу CHAP и шифрование трафика с помощью IPSec. О некоторых из этих фич я планирую написать в следующих статьях.

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

• Развертывать iSCSI желательно в быстрой сети, не ниже Gigabit Ethernet;
• Сетевой трафик iSCSI рекомендуется отделить от остального трафика и вынести в отдельную сеть, например с помощью VLAN или физического разделения на подсети;
• Для обеспечения высокой доступности на сетевом уровне необходимо использовать технологию MPIO, либо сеансы с несколькими подключениями (MCS). Объединение сетевых адаптеров (NIC Teaming) для подключения к устройствам хранения iSCSI не поддерживается;
• При использовании технологии Storage Spaces можно хранить виртуальные диски iSCSI на Storage Spaces, но нельзя использовать LUN-ы iSCSI для создания Storage Spaces;
• Для хранения виртуальных дисков iSCSI нельзя использовать общие кластерные тома CSV (Cluster Shared Volume).

Проверка предварительных требований.

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

• Убедитесь в том, что все серверы, которые нужно добавить в качестве узлов кластера, работают под управлением одной и той же версии Windows Server.

Примечание

Средство отказоустойчивости кластеров можно использовать во всех выпусках Windows Server 2012 R2 и Windows Server 2012. Это касается и установок основных серверных компонентов.

• Изучите требования к оборудованию, чтобы убедиться в том, что ваша конфигурация поддерживается. Дополнительные сведения см. в разделе Требования к оборудованию для отказоустойчивой кластеризации и варианты хранилища.
• Если в процессе создания кластера необходимо добавить кластерное хранилище, убедитесь в том, что оно доступно всем серверам. (Кластерное хранилище можно добавить и после создания кластера.)
• Убедитесь в том, что все серверы, которые нужно добавить в качестве узлов кластера, присоединены к одному и тому же домену Active Directory.
• (Необязательно.) Создайте подразделение и переместите в него учетные записи компьютеров для серверов, которые нужно добавить в качестве узлов кластера. Мы рекомендуем размещать отказоустойчивые кластеры в собственном подразделении в AD DS. Это позволит лучше контролировать параметры групповой политики и шаблона безопасности, применяемые к узлам кластера. Изоляция кластеров в собственном подразделении также помогает предотвратить случайное удаление объектов-компьютеров кластера.

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

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

Примечание

Это требование не действует, если вы хотите создать отсоединенный от Active Directory кластер в Windows Server 2012 R2. Дополнительные сведения см. в разделе Развертывание отсоединенного от Active Directory кластера.

Требования к оборудованию для отказоустойчивой кластеризации и варианты хранилища

Применимо к:Windows Server 2012 R2, Windows Server 2012

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

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

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

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

Примечание

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

· Контроллеры устройств или соответствующие адаптеры для хранилища.

o Serial Attached SCSI или Fibre Channel. Если используется Serial Attached SCSI или Fibre Channel во всех кластерных серверах, то все элементы стека хранилища должны быть идентичными. Необходимо, чтобы ПО многоканального ввода-вывода (MPIO) было идентичным. Также идентичным должно быть ПО модуля для конкретного устройства (DSM). Рекомендуется, чтобы контроллеры запоминающих устройств, то есть адаптер шины (HBA), драйверы HBA и встроенное ПО HBA, присоединенные к хранилищу кластера, были идентичными. При использовании различных HBA следует уточнить у поставщика хранилища, обеспечиваются ли при этом поддерживаемые или рекомендуемые конфигурации.

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

· Хранилище. Необходимо использовать хранилище общего доступа, совместимое с Windows Server 2012 R2 или Windows Server 2012. Можно использовать подключенное хранилище общего доступа или файловые ресурсы общего доступа SMB 3.0 в качестве хранилища общего доступа для серверов в отказоустойчивом кластере, на которых выполняется Hyper-V. Дополнительные сведения см. в разделе Развертывание Hyper-V через SMB.

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

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

o Мы рекомендуем форматировать разделы с использованием файловой системой NTFS. Если вы используете общие тома кластера (CSV), их разделы должны иметь формат NTFS.

Примечание

Если в конфигурации кворума используется диск-свидетель, его можно отформатировать в NTFS или в Resilient File System (ReFS).

o Для разделения диска на разделы можно использовать основную загрузочную запись (MBR) или таблицу разделов GPT.

Диск-свидетель — это диск в системе хранения данных кластера, который предназначен для хранения копии базы данных конфигурации кластера. Отказоустойчивый кластер имеет диск-свидетель, только если он настроен в конфигурации кворума. Дополнительные сведения см. в разделе Настройка и управление кворумом на отказоустойчивом кластере Windows Server 2012.

Требования к оборудованию для Hyper-V

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

· Виртуализация с использованием оборудования. Это возможно на процессорах, допускающих виртуализацию, а именно на процессорах с технологией Intel Virtualization Technology (Intel VT) или AMD Virtualization (AMD-V).

· Должна быть доступна и включена технология аппаратного предотвращения выполнения данных (DEP). То есть необходимо включить атрибут Intel XD (атрибут отключения выполнения) или AMD NX (атрибут запрета выполнения).

Дополнительные сведения о роли Hyper-V см. в статье Обзор Hyper-V.

Развертывание сетей хранения данных с отказоустойчивыми кластерами

При развертывании сети хранения данных (SAN) с отказоустойчивым кластером руководствуйтесь следующими рекомендациями.

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

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

· Рассмотрите использование ПО многоканального ввода-вывода или объединенных сетевых адаптеров. В архитектуре хранилищ с высокой доступностью можно развернуть отказоустойчивые кластеры с несколькими адаптерами шины, используя ПО многоканального ввода-вывода или объединенных сетевых адаптеров (что также называется отказоустойчивой балансировкой нагрузки — LBFO). Это обеспечивает максимальный уровень резервирования и доступности. Для Windows Server 2012 R2 или Windows Server 2012 многоканальное решение должно быть основано на MPIO (Microsoft Multipath I/O). Поставщики оборудования обычно предоставляют модуль MPIO для конкретного устройства (DSM), но в комплект поставки операционной системы Windows Server также входят один или несколько модулей DSM.

Подробнее о LBFO см. раздел Отказоустойчивая балансировка нагрузки в технической библиотеке Windows Server.

Важно

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

· Рассмотрите использование дисковых пространств. Если планируется развертывание кластерного хранилища Serial Attached SCSI (SAS), настроенного с помощью дисковых пространств, см. требования в разделе Развертывание кластерных дисковых пространств.

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

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

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

1. Запустите диспетчер сервера.

2. В меню Управление выберите команду Добавить роли и компоненты.

3. На странице Перед работой нажмите кнопку Далее.

4. На странице Выбор типа установки щелкните Установка ролей или компонентов, а затем нажмите кнопку Далее.

5. На странице Выбор целевого сервера щелкните сервер, на котором следует установить средство, и нажмите кнопку Далее.

6. На странице Выбор ролей сервера нажмите кнопку Далее.

7. На странице Выбор компонентов установите флажок Отказоустойчивая кластеризация.

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

9. На странице Подтверждение выбранных элементов для установки нажмите кнопку Установить.

Примечание

После установки средства отказоустойчивости кластеров не нужно перезапускать сервер.

10. По завершении установки нажмите кнопку Закрыть.

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

Примечание

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

Проверка конфигурации

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

Примечание

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

Выполнение проверочных тестов кластера

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

2. Введите Bank в поле Имя

3. На странице Прежде чем приступить к работе нажмите кнопку Далее.

4. На странице Выбор серверов или кластера в поле Введите имя введите имя NetBIOS или полное доменное имя сервера, который планируется добавить как узел отказоустойчивого кластера, а затем нажмите кнопку Добавить. Повторите этот шаг для каждого сервера, который нужно добавить. Чтобы добавить несколько серверов одновременно, разделяйте их имена запятой или точкой с запятой. Например, введите имена в формате server1.contoso.com, server2.contoso.com. Завершив настройку, нажмите кнопку Далее.

5. На странице Параметры тестирования щелкните Выполнить все тесты (рекомендуется), а затем нажмите кнопку Далее.

6. На странице Подтверждение нажмите кнопку Далее.

На странице “Проверка” показано состояние выполняющихся тестов.

7. На странице Сводка выполните одно из указанных ниже действий.

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

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

Примечание

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

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

Создание отказоустойчивого кластера

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

Создание отказоустойчивого кластера

1. Запустите диспетчер сервера.

2. В меню Инструменты выберите пункт Диспетчер отказоустойчивости кластеров.

3. Введите Bank в поле Имя

Откроется мастер создания кластеров.

4. На странице Прежде чем приступить к работе нажмите кнопку Далее.

5. Если откроется страница Выбор серверов, в поле Введите имя введите имя NetBIOS или полное доменное имя сервера, который планируется добавить как узел отказоустойчивого кластера, а затем нажмите кнопку Добавить. Повторите этот шаг для каждого сервера, который нужно добавить. Чтобы добавить несколько серверов одновременно, разделяйте их имена запятой или точкой с запятой. Например, введите имена в формате server1.contoso.com; server2.contoso.com. Завершив настройку, нажмите кнопку Далее.

Примечание

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

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

7. На странице Точка доступа для администрирования кластера выполните указанные ниже действия.

1. Введите Bank в поле Имя Перед этим изучите приведенную ниже информацию.

§ В процессе создания кластера это имя регистрируется в качестве объекта-компьютера кластера (также известного как объект имени кластера или CNO) в доменных службах Active Directory. Если для кластера указано имя NetBIOS, объект CNO создается в том же расположении, в котором находятся объекты-компьютеры узлов кластера. Это может быть контейнер “Компьютеры” (по умолчанию) или подразделение.

§ Чтобы указать другое расположение для CNO, можно ввести различающееся имя подразделения в поле Имя кластера. Например: CN=ClusterName, OU=Clusters, DC=Contoso, DC=com.

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

2. Если на сервере нет сетевого адаптера, настроенного на использование DHCP, для отказоустойчивого кластера необходимо настроить один или несколько статических IP-адресов. Установите флажок напротив каждой сети, которую необходимо использовать для управления кластером. Щелкните поле Адрес рядом с выбранной сетью, а затем введите IP-адрес, который нужно назначить кластеру. Этот IP-адрес (или адреса) будет связан с именем кластера в службе доменных имен (DNS).

3. Завершив настройку, нажмите кнопку Далее.

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

o Хранилище следует настроить позднее.

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

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

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

11. Чтобы убедиться в том, что кластер создан, проверьте, указано ли его имя в разделе Диспетчер отказоустойчивости кластеров в дереве навигации. Можно развернуть имя кластера, а затем щелкнуть элементы в разделах Узлы, Хранилище или Сети, чтобы просмотреть связанные ресурсы.

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

После создания кластера можно выполнить такие действия, как проверка конфигурации кворума кластера и создание общих томов кластера — CSV (необязательно). Дополнительные сведения см. в разделах Настройка и управление кворумом на отказоустойчивом кластере Windows Server 2012 и Использование общих томов кластера в отказоустойчивом кластере.

Создание кластерных ролей

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

Примечание

Для кластерных ролей, требующих точки доступа клиента, в доменных службах Active Directory создается виртуальный объект-компьютер (VCO). По умолчанию все объекты VCO для кластера создаются в том же контейнере или подразделении, что и объект CNO. Имейте в виду, что после создания кластера объект CNO можно переместить в любое подразделение.

Создание кластерной роли

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

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

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

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

4. Чтобы проверить, создана ли кластерная роль, на панели Роли убедитесь в том, что роль имеет состояние Выполняется. На панели “Роли” также указан узел владельца. Чтобы проверить отработку отказа, щелкните правой кнопкой мыши роль, наведите указатель на пункт Переместить, а затем щелкните Выбрать узел. В диалоговом окне Переместить кластерную роль щелкните необходимый узел кластера и нажмите кнопку ОК. В столбце Узел владельца убедитесь в том, что узел владельца изменился.

Применимо к:Windows Server 2012

Раздел содержит базовые сведения и инструкции для настройки и управления кворумом в отказоустойчивом кластере Windows Server 2012.

В этом разделе

Общие сведения о кворуме в отказоустойчивом кластере

Обзор параметров настройки кворума

· Настройка свидетеля

· Назначение голосов узлов

· Динамическое управление кворумом

Общие рекомендации по настройке кворума

Настройка кворума кластера

Восстановление кластера путем запуска без кворума

Рекомендации касательно кворума для конфигураций аварийного восстановления

Общие сведения о кворуме в отказоустойчивом кластере

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

Зачем настраивать кворум?

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

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

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

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

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

Имейте в виду, что функционирование кластера зависит не только от кворума, но еще и от следующих факторов:

· сетевые соединения между узлами кластера;

· емкость узла, достаточная для размещения назначаемых ему кластерных ролей;

· параметры приоритета, настраиваемые для кластерных ролей.

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

Обзор параметров настройки кворума

Модель кворума в Windows Server 2012 является гибкой. Если необходимо изменить конфигурацию кворума для кластера, воспользуйтесь мастером настройки кворума кластера или командлетами отказоустойчивых кластеров Windows PowerShell. Параметры конфигурации кворума по сравнению с параметрами в Windows Server 2008 R2 стали проще. Инструкции и рекомендации по настройке кворума см. в подразделе Настройка кворума кластера далее в этом разделе.

В таблице ниже перечислены три параметра конфигурации кворума, доступные в мастере настройки кворума кластера.

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

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

· Настройка свидетеля

· Назначение голосов узлов

· Динамическое управление кворумом

Настройка свидетеля

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

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

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

Назначение голосов узлов

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

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

Узнать, назначен ли узлу голос, можно путем проверки значения общего свойства NodeWeight для узла кластера с помощью командлета Get-ClusterNode Windows PowerShell. Значение 0 указывает на то, что для узла не настроен голос кворума. Значение 1 указывает на то, что узлу назначен голос кворума и управление им осуществляется кластером. Дополнительные сведения об управлении голосами узлов см. в подразделе Динамическое управление кворумом далее в этом разделе.

Назначение голосов всем узлам кластера можно проверить с помощью теста Проверка кворума кластера.

Дополнительные сведения

· Не рекомендуется назначать голоса нечетному числу узлов. Вместо этого следует настроить диск-свидетель или файловый ресурс-свидетель. Дополнительные сведения см. в разделе Настройка свидетеля этой статьи.

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

Динамическое управление кворумом

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

Примечание

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

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

Узнать, назначил ли кластер узлу голос в динамическом режиме, можно путем проверки значения общего свойства DynamicWeight для узла кластера с помощью командлета Get-ClusterNode Windows PowerShell. Значение 0 указывает на то, что у узла нет голоса кворума. Значение 1 указывает на то, что у узла есть голос кворума.

Назначение голосов всем узлам кластера можно проверить с помощью теста Проверка кворума кластера.

Дополнительные сведения

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

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

Общие рекомендации по настройке кворума

Программное обеспечение кластера автоматически настраивает кворум для нового кластера в соответствии с числом настроенных узлов и доступностью общего хранилища. Обычно это оптимальная конфигурация кворума для данного кластера. Однако рекомендуется проверить конфигурацию кворума после создания кластера и перед его запуском. Чтобы просмотреть подробную информацию о конфигурации кворума кластера, можно воспользоваться мастером проверки конфигурации или командлетом Test-Cluster Windows PowerShell для запуска теста Проверка конфигурации кворума. В диспетчере отказоустойчивости кластеров базовая конфигурация кворума содержится в сводной информации о выбранном кластере. Вы также можете просмотреть информацию о ресурсах кворума, которая выводится при запуске командлета Get-ClusterQuorum Windows PowerShell.

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

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

· добавление или исключение узлов;

· добавление или удаление хранилища;

· длительный сбой узла или свидетеля;

· восстановление кластера в сценарии аварийного восстановления на основе нескольких сайтов.

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

Настройка кворума кластера

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

Важно

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

Настройка параметров кворума кластера

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

Примечание

Изменять конфигурацию кворума кластера можно без остановки кластера и без отключения его ресурсов.

Изменение конфигурации кворума в отказоустойчивом кластере с помощью диспетчера отказоустойчивости кластеров

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

2. Выбрав кластер, на панели Действия выберите пункт Дополнительные действия и щелкните Настроить параметры кворума кластера. Появится мастер настройки кворума кластера. Нажмите кнопку Далее.

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

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

o Чтобы добавить или изменить свидетель кворума, выберите параметр Добавить или изменить свидетель кворума, а затем выполните описанные ниже действия. Информацию и рекомендации по настройке свидетеля кворума см. в подразделе Настройка свидетеля ранее в этом разделе.

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

Примечание

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

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

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

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

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

Примечание

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

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

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

Примечание

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

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

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

4. Нажмите кнопку Далее. На открывшейся странице подтвердите выбранные параметры и нажмите кнопку Далее.

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

Примечание

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

Подготовка кластерных объектов-компьютеров в доменных службах Active Directory

Применимо к:Windows Server 2012 R2, Windows Server 2012

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

Когда вы создаете отказоустойчивый кластер с помощью мастера создания кластеров или Windows PowerShell, необходимо указать имя кластера. Если при создании кластера у вас достаточно разрешений, процесс создания кластера автоматически создает объект-компьютер в AD DS с соответствующим именем кластера. Этот объект называется объектом имени кластера или CNO. Посредством CNO при настройке кластерных ролей, использующих точки доступа клиентов, автоматически создаются виртуальные объекты-компьютеры (VCO). Например, если вы создали файловый сервер высокой надежности с точкой доступа клиента с именем FileServer1, CNO создаст соответствующий VCO в AD DS.

Примечание

В Windows Server 2012 R2 есть возможность создать отсоединенный от Active Directory кластер. При этом ни CNO, ни VCO в AD DS не создается. Эта возможность предназначена для определенных типов развертывания кластера. Дополнительные сведения см. в разделе Развертывание отсоединенного от Active Directory кластера.

Для автоматического создания CNO у пользователя, создающего отказоустойчивый кластер, должно быть разрешение на создание объектов-компьютеров для подразделения или контейнера, в которых размещаются серверы, которые войдут в кластер. Чтобы позволить пользователям и группам, не имеющим разрешения, создавать кластеры, пользователь с соответствующими разрешениями в AD DS (обычно администратор домена) может подготовить CNO в AD DS. Это также обеспечивает администратору домена больший контроль над именами, используемыми для кластера, и над тем, в каких подразделениях можно создавать кластерные объекты.

С помощью описанных в этом разделе процедур вы сможете сделать следующее.

· Шаг 1. Подготовка CNO в AD DS

· Шаг 2. Предоставление пользователю разрешений на создание кластера

· Шаг 3. Предоставление разрешений CNO подразделению или подготовка VCO для кластерных ролей

Шаг 1. Подготовка CNO в AD DS

Перед началом работы убедитесь, что знаете следующее:

· имя, которое следует присвоить кластеру;

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

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

Примечание

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

Подготовка CNO в AD DS

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

2. Чтобы создать подразделение для кластерных объектов-компьютеров, щелкните правой кнопкой мыши имя домена или существующее подразделение, наведите указатель на пункт Создать и щелкните Подразделение. В поле Имя введите имя подразделения и нажмите кнопку ОК.

3. В дереве консоли щелкните правой кнопкой мыши подразделение, в котором следует создать CNO, наведите указатель на пункт Создать и щелкните Компьютер.

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

Примечание

Это имя кластера, которое пользователь, создающий кластер, укажет в мастере создания кластеров на странице Точка доступа для администрирования кластера или укажет как значение параметра –Name для командлета New-Cluster Windows PowerShell.

5. Рекомендуется сделать следующее: щелкните правой кнопкой мыши учетную запись компьютера, которую вы только что создали, выберите Свойства и откройте вкладку Объект. На вкладке Объект установите флажок Защитить объект от случайного удаления и нажмите кнопку ОК.

6. Щелкните правой кнопкой мыши только что созданную учетную запись компьютера и выберите команду Отключить учетную запись. Нажмите кнопку Да для подтверждения, а затем нажмите кнопку ОК.

Примечание

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

8. Рисунок 1. Отключенный CNO в примере подразделения кластеров

Шаг 2. Предоставление пользователю разрешений на создание кластера

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

Минимальное требование для выполнения этого шага — членство в группе Операторы учета.

Предоставление пользователю разрешений на создание кластера

1. На странице “Пользователи и компьютеры Active Directory” в меню Вид убедитесь, что выбран пункт Дополнительные параметры.

2. Найдите и щелкните правой кнопкой мыши CNO и выберите Свойства.

3. На вкладке Безопасность нажмите кнопку Добавить.

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

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

Рисунок 2. Предоставление полного доступа пользователю или группе, которые будут создавать кластер

6. Нажмите кнопку ОК.

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

Примечание

Если CNO находится в контейнере компьютеров по умолчанию, администратор кластера может создать до 10 VCO без какой-либо дополнительной настройки. Чтобы добавить более 10 VCO, необходимо явно предоставить разрешение на создание объектов-компьютеров объекту имени кластера для контейнера компьютеров.

Шаг 3. Предоставление разрешений CNO подразделению или подготовка VCO для кластерных ролей

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

Если вы подготовили CNO в AD DS, для создания VCO можно сделать следующее.

· Вариант 1: Предоставление разрешений CNO подразделению. Если вы воспользуетесь этим вариантом, кластер сможет автоматически создавать VCO в AD DS. Таким образом, администратор отказоустойчивого кластера сможет создавать кластерные роли, не отправляя вам запрос на подготовку VCO в AD DS.

Примечание

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

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

Примечание

Необходимым минимумом для выполнения шагов этого варианта является членство в группе Операторы учета.

Предоставление разрешений CNO подразделению

1. На странице “Пользователи и компьютеры Active Directory” в меню Вид убедитесь, что выбран пункт Дополнительные параметры.

2. Щелкните правой кнопкой мыши подразделение, в котором вы создали CNO в разделе Шаг 1. Подготовка CNO в AD DS, а затем выберите пункт Свойства.

3. На вкладке Безопасность нажмите кнопку Дополнительно.

4. В диалоговом окне Дополнительные параметры безопасности нажмите кнопку Добавить.

5. Рядом с пунктом Субъект щелкните Выбрать субъект.

6. В диалоговом окне Выбор пользователей, компьютеров, учетной записи службы или групп щелкните Типы объектов, установите флажок Компьютеры и нажмите кнопку ОК.

7. В поле Введите имена выбираемых объектов введите имя CNO, щелкните Проверить имена и нажмите кнопку ОК. В ответ на предупреждающее сообщение о попытке добавить отключенный объект нажмите кнопку ОК.

8. В диалоговом окне Запись разрешения убедитесь, что для списка Тип установлено значение Разрешить, а для списка Применяется к — значение Этот объект и все дочерние объекты.

9. В разделе Разрешения установите флажок Создание объектов-компьютеров.

Рисунок 3. Предоставление CNO разрешения на создание объектов-компьютеров

10. Нажимайте кнопку ОК, пока не вернетесь на страницу “Пользователи и компьютеры Active Directory”.

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

Подготовка VCO для кластерной роли

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

2. На странице “Пользователи и компьютеры Active Directory” в меню Вид убедитесь, что выбран пункт Дополнительные параметры.

3. На странице “Пользователи и компьютеры Active Directory” щелкните правой кнопкой мыши подразделение, в котором находится CNO, наведите указатель на пункт Создать и выберите Компьютер.

4. В поле Имя компьютера введите имя, которое будет использоваться для кластерной роли, и нажмите кнопку ОК.

5. Рекомендуется сделать следующее: щелкните правой кнопкой мыши учетную запись компьютера, которую вы только что создали, выберите Свойства и откройте вкладку Объект. На вкладке Объект установите флажок Защитить объект от случайного удаления и нажмите кнопку ОК.

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

7. На вкладке Безопасность нажмите кнопку Добавить.

8. В диалоговом окне Выбор пользователей, компьютеров, учетной записи службы или групп щелкните Типы объектов, установите флажок Компьютеры и нажмите кнопку ОК.

9. В поле Введите имена выбираемых объектов введите имя CNO, щелкните Проверить имена и нажмите кнопку ОК. Если появится предупреждающее сообщение о попытке добавить отключенный объект, нажмите кнопку ОК.

10. Убедитесь, что CNO выделен, после чего рядом с полем Полный доступ установите флажок Разрешить.

11. Нажмите кнопку ОК.

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

Развертывание кластера Hyper-V

Применимо к:Windows Server 2012 R2, Windows Server 2012

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

Общие сведения о роли Hyper-V и компоненте “Отказоустойчивая кластеризация” см. в разделе Обзор Hyper-V и Обзор отказоустойчивой кластеризации.

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

В этом разделе

· Предварительные условия

· Ограничения

· Шаг 1. Подключите оба физических компьютера к сетям и хранилищу

· Шаг 2. Установите Hyper-V и средство отказоустойчивости кластеров на обоих физических компьютерах

· Шаг 3. Создайте виртуальный коммутатор

· Шаг 4. Проверьте конфигурацию кластера

· Шаг 5. Создайте кластер

· Шаг 6. Добавьте диск в качестве общего тома кластера для хранения данных виртуальной машины

· Шаг 7. Создайте высокодоступную виртуальную машину

· Шаг 8. Установите гостевую операционную систему на виртуальной машине

· Шаг 9. Протестируйте плановую отработку отказа

· Шаг 10. Протестируйте внеплановую отработку отказа

· Шаг 11. Измените параметры виртуальной машины

· Шаг 12. Удалите виртуальную машину из кластера

Примечание

В этом разделе содержатся примеры командлетов Windows PowerShell, которые можно использовать для автоматизации некоторых описанных процедур. Дополнительные сведения см. в статье Запуск Windows PowerShell.

Обязательные компоненты

Предварительные условия

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

Требования к оборудованию

Общие требования к серверам, сетям, сетевым адаптерам, хранилищу и контроллерам устройств хранения для Hyper-V и отказоустойчивых кластеров см. в подразделе “Требования к оборудованию” статей Обзор Hyper-V и Требования к оборудованию для отказоустойчивой кластеризации и варианты хранилища.

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

Сведения о требованиях к программному обеспечению для использования роли Hyper-V и компонента “Отказоустойчивая кластеризация” см. в разделе Обзор Hyper-V и Обзор отказоустойчивой кластеризации.

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

Требования к сетевой инфраструктуре и учетным записям домена

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

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

· Сетевые параметры и IP-адреса. Если для сети используются одинаковые сетевые адаптеры, настройте на них одинаковые параметры обмена данными (такие как скорость, дуплексный режим, управление потоком и тип мультимедиа). Кроме того, сравните параметры на сетевом адаптере и коммутаторе, к которому он подключается, и убедитесь в том, что они не конфликтуют.

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

· DNS. Серверы в кластере должны использовать службу доменных имен (DNS) для разрешения имен. Можно использовать протокол динамического обновления DNS.

· Роль домена. Все серверы в кластере должны входить в один домен Active Directory. Мы рекомендуем, чтобы все кластерные серверы имели одинаковую роль домена (рядовой сервер или контроллер домена). Рекомендованная роль — рядовой сервер. Если кластерные серверы являются рядовыми серверами, то необходим дополнительный сервер, выступающий в роли контроллера домена в содержащем кластер домене.

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

Чтобы создать кластер или добавить узлы, необходимо войти в домен с учетной записью, которая имеет права и разрешения администратора на всех серверах в кластере. Она не обязательно должна входить в группу “Администраторы домена”. Например, это может быть учетная запись пользователя домена, входящая в группу “Администраторы” на каждом кластерном сервере. Кроме того, если учетная запись не входит в группу “Администраторы домена”, ей (или группе, членом которой она является) необходимо предоставить разрешения на создание объектов-компьютеров и чтение всех свойств в домене.

Ограничения

В отношении Hyper-V и отказоустойчивых кластеров действуют указанные ниже общие ограничения.

· Отказоустойчивый кластер может иметь не более 64 узлов.

· При использовании виртуализации серверов в кластере может быть до 8000 виртуальных машин, а в одном узле можно разместить до 1024 виртуальных машин, если аппаратных ресурсов сервера достаточно для их поддержки. Например, если технология Hyper-V используется вместе с инфраструктурой виртуальных рабочих столов (VDI) для виртуализации клиентских компьютеров, в кластере может быть до 8000 виртуальных машин VDI (Windows 8.1, Windows 8 или Windows 7), а на одном узле можно разместить до 1024 виртуальных машин.

Подробнее об ограничениях масштабируемости для Hyper-V см. в разделе Масштабируемость Hyper-V в Windows Server 2012 и Windows Server 2012 R2.

Шаг 1. Подключите оба физических компьютера к сетям и хранилищу

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

Подключение серверов к сетям и хранилищу

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

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

Примечание

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

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

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

o интерфейс, предоставленный изготовителем хранилища;

o соответствующий интерфейс iSCSI.

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

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

7. Если требуется объем хранилища более 2 терабайт, а для управления форматом диска используется интерфейс Windows, преобразуйте тип разделов диска в таблицу разделов GPT. Для этого выполните резервное копирование всех данных на диске и удалите все тома на нем. Затем в оснастке управления дисками щелкните правой кнопкой мыши диск (не раздел) и выберите пункт Преобразовать в GPT-диск.

Если объем меньше 2 терабайт, то вместо таблицы разделов GPT можно использовать тип разделов, называемый основной загрузочной записью (MBR).

Важно

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

8. Проверьте форматы всех предоставленных томов или LUN. Мы рекомендуем использовать формат NTFS (для диска-свидетеля кворума можно использовать NTFS или ReFS).

Шаг 2. Установите Hyper-V и средство отказоустойчивости кластеров на обоих физических компьютерах

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

· Добавление роли Hyper-V в разделе “Установка роли Hyper-V и настройка виртуальной машины”.

· Установка компонентов и инструментов для отказоустойчивых кластеров в Windows Server 2012

Шаг 3. Создайте виртуальный коммутатор

Выполните это действие на обоих физических компьютерах, если вы не создали виртуальный коммутатор при установке роли Hyper-V. Этот виртуальный коммутатор предоставляет виртуальную машину высокой доступности с доступом к физической сети.

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

1. Откройте диспетчер Hyper-V.

2. В меню Действия выберите пункт Диспетчер виртуальных коммутаторов.

3. В разделе Создать виртуальный коммутатор выберите пункт Внешний.

4. Щелкните Создать виртуальный коммутатор. Появится страница Создать виртуальный коммутатор.

5. Введите имя нового коммутатора. На обоих серверах с Hyper-V должно использоваться одно и то же имя.

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

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

Эквивалентные команды Windows PowerShell

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

В приведенном ниже примере создается внешний коммутатор VMExternalSwitch, который связан с сетевым адаптером Wired Ethernet Connection 3 и позволяет операционной системе управления совместно использовать сетевой адаптер.

New-VMSwitch “VMExternalSwitch” –NetAdapterName “Wired Ethernet Connection 3” –AllowManagementOS

Шаг 4. Проверьте конфигурацию кластера

Перед созданием кластера настоятельно рекомендуется выполнить полный набор проверочных тестов конфигурации кластера, запустив мастер проверки конфигурации в диспетчере отказоустойчивости кластеров или командлет Test-Cluster Windows PowerShell. В набор тестов включены специальные проверочные тесты для конфигурации роли Hyper-V в отказоустойчивом кластере.

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

Шаг 5. Создайте кластер

Сведения о создании отказоустойчивого кластера с помощью диспетчера отказоустойчивости кластеров или командлета New-Cluster Windows PowerShell см. в разделе Создание отказоустойчивого кластера Windows Server 2012.

Шаг 6. Добавьте диск в качестве общего тома кластера для хранения данных виртуальной машины

Для реализации некоторых сценариев использования кластерных виртуальных машин хранилище виртуальной машины и файл виртуального жесткого диска должны быть настроены как общие тома кластера (CSV). Чтобы настроить диск в кластерном хранилище как общий том кластера, можно воспользоваться диспетчером отказоустойчивости кластеров или командлетом Add-ClusterSharedVolume Windows PowerShell. Подробные рекомендации по планированию и инструкции по созданию общего тома кластера см. в разделе Использование общих томов кластера в отказоустойчивом кластере Windows Server 2012.

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

Шаг 7. Создайте высокодоступную виртуальную машину

На этом этапе создается виртуальная машина, и для нее настраивается высокая доступность.

Примечание

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

Рекомендации по созданию виртуальной машины с высокой доступностью

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

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

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

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

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

1. В диспетчере отказоустойчивости кластеров выберите или укажите нужный кластер. Дерево консоли под кластером должно быть развернуто.

2. Щелкните Роли.

3. На панели Действия выберите пункт Виртуальные машины, а затем щелкните Создать виртуальную машину. Откроется мастер создания виртуальной машины. Нажмите кнопку Далее.

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

5. На странице Выделить память укажите количество памяти, необходимое операционной системе, которая будет выполняться на этой виртуальной машине. Например, для Windows Server 2012 R2 укажите значение 1024 МБ.

6. На странице Настройка параметров сети подключите сетевой адаптер к виртуальному коммутатору, связанному с физическим сетевым адаптером. Необходимо указать виртуальный коммутатор, настроенный в процедуре Шаг 3. Создайте виртуальный коммутатор.

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

8. На странице Параметры установки выберите пункт Установить операционную систему с загрузочного CD или DVD-диска. В поле Носитель укажите расположение носителя, а затем нажмите кнопку Готово.

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

Эквивалентные команды Windows PowerShell

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

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

New-VHD -Path <PathToVHDXFile> -Dynamic -SizeBytes 127GB

New-VM -Name FailoverTest -Path <PathToVMFolder> -Memory 1GB –SwitchName “VMExternalSwitch” –BootDevice CD -VHDPath <PathToVHDXFile>

Add-VMDvdDrive -VMName FailoverTest –Path <PathtoISOFile>

Set-VM –Name FailoverTest –AutomaticStartAction Nothing

Add-ClusterVirtualMachineRole -VirtualMachine FailoverTest

Шаг 8. Установите гостевую операционную систему на виртуальной машине

Затем необходимо запустить кластеризованную виртуальную машину, настроенную в процедуре Шаг 7. Создайте высокодоступную виртуальную машину. При этом будет установлена гостевая операционная система (в этом разделе предполагается, что это Windows Server 2012 R2). Сведения о том, как это сделать, см. в разделе Шаг 3. Установка гостевой операционной системы раздела “Установка роли Hyper-V и настройка виртуальной машины”.

Примечание

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

Шаг 9. Протестируйте плановую отработку отказа

Чтобы протестировать запланированную отработку отказа, можно перенести кластеризованную виртуальную машину, созданную в процедуре Шаг 7. Создайте высокодоступную виртуальную машину, на другой узел.

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

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

· Быстрая миграция. Приостановите виртуальную машину, сохраните состояние, перенесите роль на другой узел и запустите на нем виртуальную машину.

· Миграция хранилища. Перенесите в другое кластерное хранилище только данные виртуальной машины.

Например, чтобы протестировать запланированную отработку отказа путем динамической миграции, можно воспользоваться диспетчером отказоустойчивости кластеров или командлетом Move-ClusterVirtualMachineRole Windows PowerShell.

Тестирование запланированной отработки отказа

1. В диспетчере отказоустойчивости кластеров выберите или укажите нужный кластер. Дерево консоли под кластером должно быть развернуто.

2. Чтобы выбрать конечный узел для динамической миграции кластеризованной виртуальной машины, щелкните правой кнопкой мыши кластеризованную виртуальную машину FailoverTest (которая была настроена в процедуре Шаг 7. Создайте высокодоступную виртуальную машину), наведите указатель на пункт Переместить, затем на пункт Динамическая миграция и щелкните пункт Выбрать узел.

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

3. Проверьте успешность переноса, изучив информацию о каждом узле.

Эквивалентные команды Windows PowerShell

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

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

Move-ClusterVirtualMachineRole -Name “FailoverTest” –Node ContosoFCNode2

Шаг 10. Протестируйте внеплановую отработку отказа

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

Тестирование незапланированной отработки отказа

1. В диспетчере отказоустойчивости кластеров выберите или укажите нужный кластер. Дерево консоли под кластером должно быть развернуто.

2. Чтобы свести к минимуму время простоя для клиентов, перед остановкой службы кластеров на узле перенесите кластерные роли, которые в настоящее время принадлежат узлу (кроме FailoverTest), на другой узел, выполнив указанные ниже действия.

1. Разверните дерево консоли под кластером, которым необходимо управлять, а затем разверните элемент Узлы.

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

3. Выберите все кластерные роли на узле, кроме FailoverTest.

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

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

3. Разверните дерево консоли под элементом Узлы.

4. Щелкните правой кнопкой мыши узел, которому принадлежит виртуальная машина FailoverTest, наведите указатель на пункт Дополнительные действия, а затем выберите пункт Остановить службу кластеров.

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

Эквивалентные команды Windows PowerShell

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

В приведенном ниже примере служба кластеров останавливается на узле ContosoFCNode2, которому принадлежит кластерная виртуальная машина FailoverTest.

Stop-ClusterNode –Name ContosoFCNode2

Шаг 11. Измените параметры виртуальной машины

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

Примечание

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

Изменение параметров виртуальной машины

1. В диспетчере отказоустойчивости кластеров выберите или укажите нужный кластер. Дерево консоли под кластером должно быть развернуто.

2. Если необходимо завершить работу виртуальной машины перед изменением параметров, разверните элемент Роли, щелкните правой кнопкой мыши кластеризованную виртуальную машину FailoverTest (настроенную в процедуре Шаг 7. Создайте высокодоступную виртуальную машину), а затем выберите пункт Завершение работы.

3. Щелкните правой кнопкой мыши виртуальную машину FailoverTest и выберите пункт Параметры. Появится страница параметров виртуальной машины.

4. Настройте параметры виртуальной машины и нажмите кнопку ОК.

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

5. Если вы завершили работу кластеризованной виртуальной машины ранее, щелкните виртуальную машину FailoverTest правой кнопкой мыши, наведите указатель на пункт Дополнительные действия и выберите пункт Запустить роль.

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

Обновление конфигурации виртуальной машины в отказоустойчивом кластере вручную

1. В диспетчере отказоустойчивости кластеров выберите или укажите нужный кластер. Дерево консоли под кластером должно быть развернуто.

2. Щелкните правой кнопкой мыши кластеризованную виртуальную машину FailoverTest (настроенную в процедуре Шаг 7. Создайте высокодоступную виртуальную машину), наведите указатель на пункт Дополнительные действия, а затем щелкните пункт Обновить конфигурацию виртуальной машины.

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

Применимо к:Windows Server 2012 R2, Windows Server 2012

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

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

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

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

Примечание

Начиная с Windows Server 2012 можно использовать компонент “Кластерное обновление” для автоматического обновления узлов гостевого кластера. Дополнительные сведения см. в разделе Общие сведения о кластерном обновлении.

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

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

Аспекты, связанные с физическими узлами

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

Развертывание гостевого кластера на кластере физических узлов

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

Рассмотрим следующий сценарий.

1. Гостевой кластер с двумя узлами (Гость1 и Гость2) работает на кластере физических узлов с тремя узлами (Узел1, Узел2 и Узел3). Гость1 работает на Узле1. Гость2 работает на Узле2.

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

3. Поскольку Гость1 работает на кластере физических узлов, виртуальная машина на узле Гость1 автоматически перемещается и запускается на другом узле. В случае неполадок узла Гость2 роли снова можно будет переключить на узел Гость1.

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

Размещение виртуальных машин на разных физических узлах

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

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

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

· Если вы используете System Center Virtual Machine Manager (VMM), то можете настроить удаление сходства при помощи наборов доступности. Дополнительные сведения см. в статье о настройке наборов доступности в VMM для виртуальных машин на кластере узлов.

Примечание

Эта функция доступна начиная с System Center 2012 с пакетом обновления 1.

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

Пример настройки удаления сходства

Следующий пример Windows PowerShell показывает, как посмотреть значение свойства AntiAffinityClassNames для кластерной виртуальной машины с именем “VM1” и как задать для значения свойства строку “GuestCluster1“. Необходимо настроить одну и ту же строку для этого свойства на всех виртуальных машинах, входящих в один гостевой кластер.

Для просмотра текущего значения свойства AntiAffinityClassNames для узла гостевого кластера с именем “VM1” введите следующую команду:

Get-ClusterGroup VM1 | fl anti*

Чтобы задать в качестве значения свойства AntiAffinityClassNames строку “GuestCluster1“, введите следующую команду:

(Get-ClusterGroup VM1).AntiAffinityClassNames = “GuestCluster1”

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

Get-ClusterGroup VM1 | fl anti*

Особенности развертывания гостевого кластера и управления им

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

Если вы используете System Center 2012 R2 Virtual Machine Manager, учтите, что он включает новый компонент для развертывания гостевых кластеров. При помощи шаблонов служб можно создать виртуальные машины и гостевой кластер Windows Server 2012 R2, использующий общие файлы виртуального жесткого диска (VHDX) в качестве хранилища. Дополнительные сведения см. в статье о создании гостевого кластера при помощи шаблона службы в VMM.

Требования поддержки

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

Чтобы получить поддержку операционной системы Windows Server или серверных компонентов, работающих на виртуальной машине, необходимо использовать поддерживаемую низкоуровневую оболочку. (Обратите внимание, что политика поддержки Майкрософт на протяжении жизненного цикла по-прежнему распространяется на операционную систему на виртуальной машине.) Если вы не используете Hyper-V, то, согласно требованию Майкрософт, низкоуровневая оболочка должна быть проверена и указана в каталоге Microsoft Windows Server в разделе программы проверки виртуализации серверов (SVVP). Дополнительные сведения см. в статье о программе проверки виртуализации серверов и в статье, содержащей вопросы и ответы по программе проверки виртуализации серверов.

Предельное число узлов

Одно и то же ограничение на число узлов (64) распространяется на кластеры физических узлов и гостевые кластеры, работающие под управлением Windows Server 2012 R2 или Windows Server 2012. Число развертываемых узлов зависит от кластерной роли. Например, если роль базы данных на физических серверах развернута более чем на двух узлах для распределения экземпляров, можно эмулировать эту среду, используя более двух узлов гостевого кластера для размещения экземпляров.

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

Требования домена Active Directory

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

Варианты хранилищ

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

Требования к хранилищу зависят от кластерных ролей, выполняющихся на кластере. Большинство кластерных ролей используют кластерное хранилище, доступное на любом узле кластера, на котором выполняется кластерная роль. Примеры кластерного хранилища — физические диски и общие тома кластера (CSV). Для некоторых ролей не требуется хранилище под управлением кластера. Например, можно настроить Microsoft SQL Server для использования групп доступности, реплицирующих данные между узлами. Другие кластерные роли могут использовать общие ресурсы SMB или NFS в качестве хранилищ данных, доступных любому узлу кластера.

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

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

Избыточность сети

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

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

· Объединение сетевых карт на физическом узле. В этом сценарии узел использует несколько сетевых адаптеров в объединенной конфигурации. Настройте Hyper-V с одним виртуальным коммутатором, использующим группу.

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

Важно

Для использования объединения сетевых карт в виртуальной машине также необходимо настроить каждый порт коммутатора Hyper-V, связанный с виртуальной машиной, для разрешения объединения. Для этого откройте параметры виртуальной машины в диспетчере Hyper-V. В разделе Дополнительные параметры каждого сетевого адаптера, в группе Объединение сетевых карт, установите флажок Разрешить этому сетевому адаптеру быть частью группы в операционной системе на виртуальной машине. Либо используйте следующую команду Windows PowerShell:

Set-VMNetworkAdapter –VMName VMName –AllowTeaming On

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

Количество сетей

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

Есть разные способы выполнить эти требования, , включая следующие основные параметры:

· Отдельные сети для каждой категории. В некоторых сценариях развертывания гостевых кластеров для каждого типа сетевого трафика может применяться одна или несколько виртуальных сетей. Это эмулирует типовую конфигурацию физической сети для отказоустойчивых кластеров. Такая конфигурация включает сеть для клиентского доступа (предпочтительно с объединением), которая имеет шлюз по умолчанию и поддерживает маршрутизацию; сеть, расположенную в немаршрутизируемой подсети, для обмена данными между узлами кластеров; а также — если хранилище использует сеть — один или несколько сетевых адаптеров, использующих объединение сетевых карт или технологию Multipath I/O (MPIO) для обеспечения устойчивости.

· Конвергентная сеть. В этом сценарии используется одна виртуальная сеть для всех операций сетевого ввода-вывода на виртуальных машинах гостевого кластера. Поскольку все типы трафика используют одну и ту же сеть, следует настроить политики QoS на физическом узле, чтобы зарезервировать полосу пропускания для трафика кластера и CSV. Это позволит адаптироваться к потребностям ввода-вывода. Дополнительные сведения см. в разделе “QoS Hyper-V” статьи QoS на основе политики и QoS Hyper-V и в примере четырех сетевых плат в двух группах в статье с описанием типовых конфигураций QoS.

Примечание

При выполнении проверочных тестов на кластере с одним сетевым адаптером появляется предупреждение об отсутствии избыточности. Это предупреждение не препятствует развертыванию кластера и получению поддержки. Цель предупреждения — напомнить вам о важности избыточности.

Защита от кратковременных перебоев сети

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

Обычно во время динамической миграции виртуальной машины имеет место быстрый заключительный этап, когда виртуальная машина останавливается на узле источника и запускается на узле назначения. Но если по какой-либо причине заключительный этап займет больше времени, чем установлено пороговыми параметрами пульса, то гостевой кластер будет считать узел неисправным, даже если в итоге динамическая миграция завершится успешно. Если заключительный этап динамической миграции завершится в течение времени ожидания TCP (обычно он составляет около 20 секунд), подключение клиентов к виртуальной машине по сети будет незаметно восстановлено.

Чтобы привести время ожидания пульса кластера в более точное соответствие со временем ожидания TCP, можно установить для свойств кластера SameSubnetThreshold и CrossSubnetThreshold значение 20 секунд вместо значения по умолчанию (5 секунд). По умолчанию кластер отправляет пакет пульса каждую секунду. Порог определяет количество пропущенных подряд пакетов пульса, после которого кластер считает узел неисправным.

Важно

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

В следующем примере показано, как при помощи Windows PowerShell посмотреть свойства кластера CrossSubnetThreshold и SameSubnetThreshold и как изменить значение каждого из них на 20.

Для просмотра текущих значений свойств введите следующую команду:

Get-Cluster | fl *subnet*

Чтобы задать для свойств CrossSubnetThreshold и SameSubnetThreshold значение 20, введите следующие команды:

(Get-Cluster).CrossSubnetThreshold = 20

(Get-Cluster).SameSubnetThreshold = 20

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

Get-Cluster | fl *subnet*

Обзор виртуального подключения Fibre Channel для Hyper-V

Применимо к:Windows Server 2012 R2, Windows Server 2012

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

Основные преимущества

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

Требования

Для виртуального адаптера Fibre Channel в Hyper-V требуются следующие ресурсы.

· Один или несколько экземпляров Windows Server 2012 с установленной ролью Hyper-V. Для Hyper-V необходим компьютер, процессор которого поддерживает аппаратную виртуализацию.

· Компьютер с одним или несколькими адаптерами шины Fibre Channel с обновленным драйвером, поддерживающим виртуальный адаптер Fibre Channel. Обновленные драйверы адаптера шины входят в комплект поставки некоторых моделей. Порты адаптера шины, которые используются с виртуальным адаптером Fibre Channel, должны быть настроены в топологии Fibre Channel, которая поддерживает NPIV, максимальный размер передачи данных не менее 0,5 МБ и передачу не менее 128 физических страниц. Чтобы определить, поддерживается ли виртуальный адаптер Fibre Channel имеющимся оборудованием, обратитесь к поставщику оборудования.

· Сеть SAN с поддержкой NPIV.

· Виртуальные машины, настроенные для использования виртуального адаптера Fibre Channel. Операционной системой на виртуальной машине должна быть Windows Server 2008, Windows Server 2008 R2 или Windows Server 2012.

· Хранилище, доступ к которому выполняется через виртуальный адаптер Fibre Channel, поддерживает устройства, предоставляющие логические устройства. Логические блоки виртуального адаптера Fibre Channel не могут служить загрузочным носителем.

Технический обзор

Виртуальный адаптер Fibre Channel для Hyper-V предоставляет операционную систему на виртуальной машине с непосредственным доступом к сети SAN с использованием стандартного WWN-имени, связанного с виртуальной машиной. Теперь пользователи Hyper-V могут использовать сети SAN на основе Fibre Channel для виртуализации рабочих нагрузок, которым требуется непосредственный доступ к номерам LUN сети SAN. Сети SAN Fibre Channel также позволяют работать в новых сценариях, например применять отказоустойчивую кластеризацию в операционной системе на виртуальной машине, подключенной к общему хранилищу Fibre Channel.

Массивы хранения данных среднего и высшего класса обладают расширенными функциями, которые помогают переложить некоторые задачи управления с серверов на сеть SAN. Виртуальный адаптер Fibre Channel представляет альтернативный аппаратный маршрут ввода-вывода для программного стека виртуального жесткого диска Windows. Это позволяет использовать современные возможности, предоставляемые сетями SAN, непосредственно на виртуальных машинах Hyper-V. Например, с помощью Hyper-V можно перенести некоторые функции хранилища (например, создание снимка LUN) в оборудование SAN, используя аппаратную службу теневого копирования томов (VSS) на виртуальной машине Hyper-V.

Поддержка NPIV

Виртуальный адаптер Fibre Channel для гостевых систем Hyper-V использует существующий стандарт виртуализации NPIV T11 для сопоставления нескольких виртуальных идентификаторов N_Port с одним физическим портом N_port Fibre Channel. Новый порт NPIV создается на сервере каждый раз, когда запускается виртуальная машина, настроенная с виртуальным адаптером шины. Когда виртуальная машина прекращает работу на сервере, этот порт NPIV удаляется. Из-за применения NPIV порты адаптера шины, используемые для виртуального адаптера Fibre Channel, следует настраивать в топологии Fibre Channel, которая поддерживает NPIV, а сеть SAN должна поддерживать порты NPIV.

Поддержка виртуальных сетей SAN

Hyper-V позволяет определять на сервере виртуальные сети SAN для поддержки сценариев, в которых один сервер Hyper-V подключается к различным сетям SAN через несколько портов Fibre Channel. В виртуальной сети SAN определяется именованная группа физических портов Fibre Channel, которые подключены к одной физической сети SAN. Например, пусть узел Hyper-V подключен к двум сетям SAN — рабочей и тестовой. Подключение сервера к каждой сети SAN выполняется через два физических порта Fibre Channel. В этом примере можно настроить две виртуальные сети SAN. Одна будет называться “Производственная SAN” и подключаться к реальной производственной сети через два физических порта Fibre Channel, а другая будет называться “Тестовая SAN” и подключаться через два физических порта Fibre Channel к реальной тестовой сети. Два отдельных маршрута к одной системе хранения можно называть по тому же принципу.

На виртуальной машине можно настроить до четырех виртуальных адаптеров Fibre Channel и связать с каждым из них виртуальную сеть SAN. Каждый виртуальный адаптер Fibre Channel соединяется с одним WWN-адресом или двумя WWN-адресами для поддержки динамической миграции. Каждый WWN-адрес можно настраивать автоматически или вручную.

Поддержка ленточных библиотек

Виртуальные ленточные библиотеки, настроенные с помощью виртуального адаптера Fibre Channel, поддерживаются только при использовании System Center Data Protection Manager 2012 R2 U3 или более поздней версии с сертифицированным оборудованием. Чтобы определить, поддерживает ли ленточную библиотеку виртуальный адаптер Fibre Channel, обратитесь к поставщику оборудования ленточных библиотек или запустите средство проверки совместимости ленточных библиотек DPM в гостевой ВМ с установленной в качестве цели виртуальной ленточной библиотекой. Дополнительные сведения о средстве проверки совместимости ленточных библиотек DPM см. в разделе Проверка совместимости ленточных библиотек.

Динамическая миграция

Для поддержки динамической миграции виртуальных машин между серверами Hyper-V при сохранении подключения Fibre Channel настраиваются два WWN для каждого виртуального адаптера Fibre Channel, как показано на рис. 1 (набор А и набор Б). Hyper-V автоматически переключается между WWN-адресами из набора А и набора Б во время динамической миграции. Это гарантирует доступность всех LUN на конечном сервере перед миграцией и отсутствие простоев в ходе миграции.

Рис 1. Переключение WWN-адресов в ходе динамической миграции

Функции MPIO

Hyper-V в Windows Server 2012 может использовать многопутевой ввод-вывод (MPIO), чтобы обеспечить постоянное подключение к хранилищу Fibre Channel с виртуальной машины. Функция MPIO используется с Fibre Channel следующими способами.

· Доступ к серверу с помощью MPIO. Установите на сервер несколько портов Fibre Channel и реализуйте посредством MPIO высокий уровень доступности подключения к LUN, доступным для сервера.

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

· Использование различных модулей устройств (DSM) для сервера и каждой виртуальной машины. Такой подход делает возможной динамическую миграцию конфигурации виртуальной машины, включая конфигурацию DSM, а также подключение между серверами и совместимость с существующими конфигурациями серверов и модулями устройств.

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

Применимо к:Windows Server 2012 R2, Windows Server 2012

В этом разделе приводится обзор кластерного обновления (CAU), функции для отказоустойчивых кластеров, появившейся в Windows Server 2012. Кластерное обновление автоматизирует процесс обновления программного обеспечения на кластерных серверах с сохранением доступности. В этом разделе описываются сценарии и области применения кластерного обновления и приведены ссылки на разделы, в которых описаны способы интеграции кластерного обновления с другими процессами автоматизации ИТ-среды и управления ей.

Возможно, вы имели в виду…

Кластерное обновление связано со следующими базовыми технологиями, но отличается от них:

· Обзор отказоустойчивой кластеризации

· Центр обновления Windows и Центр обновления Майкрософт

· Службы Windows Server Update Services

· Инструментарий управления Windows (WMI)

· Удаленное управление Windows

Описание компонента

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

· Переводит каждый узел кластера в режим обслуживания узла.

· Удаляет кластерные роли с узла.

· Устанавливает обновления и все зависимые обновления.

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

· Выводит узел из режима обслуживания.

· Восстанавливает кластерные роли на узле.

· Переходит к обновлению следующего узла.

Для большинства кластерных ролей (ранее называемых кластерными приложениями и службами) процесс автоматического обновления запускает плановую отработку отказа, что может привести к временному прерыванию в работе службы для подключенных клиентов. Однако для рабочих нагрузок с непрерывной доступностью, таких как Hyper-V с динамической миграцией или файловый сервер с прозрачной отработкой отказа SMB, CAU позволяет управлять обновлениями кластера, не влияя при этом на доступность службы.

Примечание

Компонент CAU совместим только с отказоустойчивыми кластерами Windows Server 2012 R2 и Windows Server 2012 и кластерными ролями, которые поддерживаются в этих версиях.

Практическое применение

· Кластерное обновление позволяет сократить простои служб, минимизировать потребности в ручном обновлении и повысить надежность процесса обновления кластера. Если функция CAU используется вместе с непрерывно доступными рабочими нагрузками кластера, такими как непрерывно доступные файловые серверы (рабочая нагрузка файлового сервера с прозрачной отработкой отказа SMB) или Hyper-V, кластер можно обновлять незаметно для клиентов.

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

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

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

· Режим самообновления CAU позволяет реализовать “готовое решение кластера” (набор кластерных физических компьютеров с Windows Server 2012, обычно объединенных в одном корпусе) для самообновления. Как правило, такие решения развертываются в филиалах с минимальной локальной поддержкой. В этих сценариях развертывания режим самостоятельного обновления предоставляет существенные преимущества.

Важные функции

Ниже описаны важные функции CAU.

· Пользовательский интерфейс и набор командлетов Windows PowerShell, которые можно использовать для предварительного просмотра, применения и отслеживания обновлений, а также для создания отчетов по обновлениям

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

· Стандартный подключаемый модуль, который интегрируется с существующим агентом Центра обновления Windows (WUA) и инфраструктурой служб Windows Server Update Services (WSUS) в Windows Server 2012 R2 или Windows Server 2012 для применения важных обновлений Майкрософт.

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

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

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

CAU координирует полное обновление кластеров в двух режимах:

· Режим самостоятельного обновления. Для этого режима кластерная роль компонента кластерного обновления настраивается в качестве рабочей нагрузки на отказоустойчивом кластере, который необходимо обновить, и составляется расписание обновления. Затем кластер самостоятельно обновляется в запланированное время с использованием профиля по умолчанию или пользовательского профиля прогона обновления. В ходе прогона обновления на узле, который в этот момент является владельцем кластерной роли CAU, запускается процесс координатора обновлений, последовательно обновляющий каждый узел кластера. Чтобы обновить текущий узел кластера, кластерная роль CAU переводится на другой узел кластера, а новый процесс координатора обновлений на этом узле берет на себя управление прогоном обновления. В режиме самостоятельного обновления компонент кластерного обновления может полностью обновить отказоустойчивый кластер с помощью автоматизированного процесса обновления. В этом режиме администратор также может запустить обновление по требованию или использовать метод удаленного обновления. Чтобы получить сводные данные о прогоне обновления в режиме самообновления, администратору необходимо подключиться к кластеру и выполнить командлет Get-CauRun Windows PowerShell.

· Режим удаленного обновления. Для этого режима удаленный компьютер с Windows Server 2012 R2, Windows Server 2012, Windows 8.1 или Windows 8, называемый координатором обновлений, настраивается с помощью средств CAU. Координатор обновлений не является членом кластера, обновление которого проводится во время прогона обновления. Администратор запускает обновление по требованию с удаленного компьютера с помощью профиля по умолчанию или пользовательского профиля выполнения обновления. Режим удаленного обновления удобен для мониторинга процесса обновления в режиме реального времени, а также для кластеров, которые запущены на компьютерах с основными серверными компонентами Windows Server 2012 R2 или Windows Server 2012.

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

Кластерное обновление доступно во всех выпусках Windows Server 2012 R2 и Windows Server 2012, включая компьютеры с основными серверными компонентами. Подробную информацию о требованиях см. в разделе Требования и рекомендации для кластерного обновления.

Прежде чем использовать кластерное обновление, установите компонент “Средство отказоустойчивости кластеров” в ОС Windows Server 2012 R2 или Windows Server 2012 и создайте отказоустойчивый кластер. Компоненты, поддерживающие кластерное обновление, автоматически устанавливаются на каждом узле кластера.

Для установки компонента “Средство отказоустойчивости кластеров” можно использовать следующие средства:

· Мастер добавления ролей и компонентов в диспетчере сервера

· Командлет Add-WindowsFeature Windows PowerShell

· Программа командной строки “Система обслуживания образов развертывания и управления ими” (DISM)

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

Кроме того, вам потребуется установить средства кластерного обновления, входящие в состав средств отказоустойчивой кластеризации, которые, в свою очередь, являются частью средств удаленного администрирования сервера (RSAT). Средства кластерного обновления состоят из пользовательского интерфейса и командлетов Windows PowerShell. Для поддержки различных режимов обновления CAU необходимо установить средства отказоустойчивости кластеров, как указано ниже.

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

· Чтобы включить режим удаленного обновления, необходимо установить средства отказоустойчивости кластеров из RSAT на локальном или удаленном компьютере, работающем под управлением Windows Server 2012 R2, Windows Server 2012, Windows 8.1 или Windows 8 и подключенном по сети к отказоустойчивому кластеру.

Примечание

o Чтобы удаленно управлять обновлениями для отказоустойчивого кластера Windows Server 2012 R2, используйте средства отказоустойчивой кластеризации из RSAT Windows Server 2012 R2. При помощи RSAT Windows Server 2012 R2 можно также удаленно управлять обновлениями для отказоустойчивого кластера Windows Server 2012.

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

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

Подробнее об установке средства отказоустойчивости кластеров см. в разделе Установка средства отказоустойчивости кластеров и инструментов для него.

Подробнее о развертывании RSAT см. в разделе Развертывание средств администрирования удаленного сервера.

Чтобы включить режим самостоятельного обновления, необходимо также добавить кластерную роль на отказоустойчивый кластер. Если вы используете пользовательский интерфейс кластерного обновления, воспользуйтесь командой Настройка параметров самообновления в разделе Действия для кластера. Либо выполните командлет Add-CauClusterRole Windows PowerShell.

Чтобы удалить CAU, удалите компонент “Отказоустойчивая кластеризация” или средства отказоустойчивой кластеризации при помощи диспетчера сервера, командлетов Windows PowerShell или программ командной строки DISM.

Дополнительные требования и рекомендации

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

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

Запуск кластерного обновления

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

· Диспетчер серверов

· Файл ClusterUpdateUI.exe, расположенный в папке %systemroot%system32

· Диспетчер отказоустойчивости кластеров.

Запуск пользовательского интерфейса CAU из диспетчера сервера

1. Запустите диспетчер сервера.

2. Выполните одно из следующих действий:

o В меню Сервис выберите пункт Кластерное обновление.

o Если один или несколько узлов кластера или сам кластер добавлены в диспетчер сервера, на странице Все серверы щелкните правой кнопкой мыши имя узла (или имя кластера) и выберите команду Обновить кластер.

Подробнее об управлении серверами с помощью диспетчера сервера см. в разделе Управление несколькими удаленными серверами с помощью диспетчера серверов.

См. также:

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

Кластерное обновление: вопросы и ответы

Применимо к:Windows Server 2012 R2, Windows Server 2012

Что такое кластерное обновление?

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

Работает ли кластерное обновление с Windows Server 2008 R2 или Windows 7?

Нет. Кластерное обновление управляет обновлением кластера только с компьютеров, работающих под управлением операционной системы Windows Server 2012 R2, Windows Server 2012, Windows 8.1 или Windows 8.

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

Нет. Для кластерного обновления не важен тип кластерного приложения. CAU является внешним решением по обновлению кластера, которое занимает уровень над API кластеризации и командлетами Windows PowerShell. Таким образом, CAU может управлять обновлением любого кластерного приложения, настроенного в отказоустойчивом кластере Windows Server 2012 R2 или Windows Server 2012.

Примечание

В данный момент для кластерного обновления проверены и сертифицированы следующие механизмы кластеризации Windows Server 2012: SMB, Hyper-V, репликация DFS, пространства имен DFS, iSCSI и NFS.

Поддерживает ли кластерное обновление обновление из Центра обновления Майкрософт и Центра обновления Windows?

Да. По умолчанию кластерное обновление настраивается с подключаемым модулем, который использует API служебной программы агента обновления Windows в узлах кластера. В параметрах инфраструктуры агента обновления Windows можно указать в качестве источника обновления Центр обновления Майкрософт и Центр обновления Windows или службы Windows Server Update Services (WSUS).

Поддерживает ли кластерное обновление обновления WSUS?

Да. По умолчанию кластерное обновление настраивается с подключаемым модулем, который использует API служебной программы агента обновления Windows в узлах кластера. В параметрах инфраструктуры агента обновления Windows можно указать в качестве источника обновления Центр обновления Майкрософт и Центр обновления Windows или службы Windows Server Update Services (WSUS).

Способно ли кластерное обновление применять выпуски обновлений для ограниченного распространения?

Да. Обновления выпуска для ограниченного распространения (LDR), также называемые исправлениями, не публикуются в Центре обновления Майкрософт или Центре обновления Windows, поэтому их невозможно загрузить через подключаемый модуль агента обновления Windows (WUA), который используется CAU по умолчанию.

Тем не менее, CAU включает второй подключаемый модуль, который можно выбрать для применения исправлений. Этот подключаемый модуль исправлений также можно настроить для применения обновлений сторонних драйверов, встроенного ПО и BIOS.

Можно ли использовать CAU для применения накопительных пакетов обновлений?

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

Могу ли я назначить для кластерного обновления расписание установки обновлений?

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

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

Удаленное обновление позволяет запускать выполнение обновления в любое время с компьютера, на котором работает Windows Server 2012 R2, Windows Server 2012, Windows 8.1 или Windows 8. Можно запустить выполнение обновления через пользовательский интерфейс или с помощью командлета Windows PowerShellInvoke-CauRun. Удаленное обновление является режимом кластерного обновления по умолчанию. Можно запускать командлет Invoke-CauRun по расписанию с удаленного компьютера, который не является одним из узлов кластера, с помощью планировщика заданий.

Можно ли назначить расписание для кластерного обновления, когда выполняется архивация?

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

Способно ли кластерное обновление бесперебойно работать с диспетчером конфигураций System Center?

Рекомендуется не использовать одновременно кластерное обновление и System Center Configuration Manager для обновления узлов кластера. Кластерное обновление координирует обновления программного обеспечения на каждом узле кластера в рамках более широкого взаимодействия с целью сохранения работоспособности службы в ходе циклов обновления. Configuration Manager также технически может использоваться для обновления узлов кластера. Вы можете использовать любое из этих средств по своему усмотрению. Тем не менее будьте внимательны, чтобы избежать перекрытия, которое может повлиять на доступность кластеризованных служб в результате того, что каждое средство управления обновлением работает независимо от другого.

Нужны ли мне учетные записи администратора, чтобы запустить кластерное обновление?

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

Могу ли я написать скрипт, чтобы еще больше автоматизировать функции кластерного обновления?

Да. CAU поставляется с командлетами Windows PowerShell, которые предоставляют широкий набор параметров скриптов Это те же командлеты, которые пользовательский интерфейс кластерного обновления вызывает, чтобы выполнять действия кластерного обновления.

Что происходит с кластерными ролями, активными в каждом узле кластера, когда CAU координирует обновления?

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

Каким образом кластерное обновление выбирает целевые узлы для перемещения при сбое той или иной кластерной роли?

Для координации отработки отказа CAU использует API кластеризации. При реализации API кластеризации выбор целевых узлов происходит сообразно с внутренними метриками и эвристикой интеллектуального размещения (например, уровни механизмов кластеризации).

Распределяет ли кластерное обновление нагрузку между кластерными ролями после обновления?

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

Каким образом кластерное обновление выбирает порядок обновления узлов?

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

Что произойдет при запуске выполнения кластерного обновления, если все узлы кластера отключены от сети?

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

Могу ли я использовать кластерное обновление, чтобы выбрать и обновить только один узел?

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

Может ли кластерное обновление сообщать об обновлении узла кластера, запущенном вне кластерного обновления?

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

Обладает ли кластерное обновление достаточной гибкостью для поддержки моих индивидуальных потребностей в ИТ-обеспечении?

Да. Кластерное обновление предлагает следующие возможности адаптации к индивидуальным потребностям клиента в ИТ-обеспечении:

Скрипты Для выполнения обновления можно указать скрипт Windows PowerShell перед обновлением и скрипт Windows PowerShell после обновления. Скрипт перед обновлением запускается на каждом узле кластера перед приостановкой его работы. Скрипт после обновления запускается на каждом узле кластера после обновления узла.

Примечание

На каждом узле кластера, на котором вы собираетесь запустить скрипты перед обновлением и после обновления, должны быть установлены .NET Framework 4.5 и Windows PowerShell. Вы также должны включить в узлах кластера удаленное взаимодействие Windows PowerShell. Подробные требования к системе см. в разделе Требования и рекомендации для кластерного обновления.

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

Архитектура общедоступных подключаемых модулей. В CAU имеются функции для регистрации, отмены регистрации и выбора подключаемых модулей. CAU поставляется с двумя подключаемыми модулями по умолчанию: один координирует API агента обновления Windows (WUA) в каждом узле кластера; второй применяет исправления, вручную скопированные в файловый ресурс, доступный узлам кластера. Если потребности предприятия не удовлетворяют эти два подключаемых модуля по умолчанию, можно построить новый подключаемый модуль CAU в соответствии со спецификацией для общедоступных API. Дополнительные сведения см. в справочнике по подключаемым модулям для кластерного обновления.

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

Как можно экспортировать из кластерного обновления результаты просмотра и обновления?

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

Возможности экспорта через интерфейс командной строки:

· Просмотр результатов при помощи командлета Windows PowerShellcmdlet Invoke-CauScan | ConvertTo-Xml. Вывод: XML-файл

· Получение отчета о результатах при помощи командлета Windows PowerShell cmdlet Invoke-CauRun | ConvertTo-Xml. Вывод: XML-файл

· Получение отчета о результатах при помощи командлета Windows PowerShell cmdlet Get-CauReport | Export-CauReport. Вывод: HTML-файл, CSV-файл

Возможности экспорта через пользовательский интерфейс:

· Копирование результатов отчета из экрана Просмотр обновлений. Вывод: CSV-файл

· Копирование результатов отчета из экрана Создать отчет. Вывод: CSV-файл

· Экспорт результатов отчета из экрана Создать отчет. Вывод: HTML-файл

Как установить кластерное обновление?

CAU входит в состав всех выпусков Windows Server 2012 R2 и Windows Server 2012. Установка CAU легко интегрируется в компонент отказоустойчивой кластеризации. Установка кластерного обновления выполняется следующим образом:

· При установке отказоустойчивой кластеризации в узле кластера поставщик WMI CAU устанавливается автоматически.

· При установке средств отказоустойчивой кластеризации на сервер или клиентский компьютер командлеты Windows PowerShell кластерного обновления устанавливаются автоматически.

· При установке на сервер или клиентский компьютер пользовательского интерфейса отказоустойчивой кластеризации командлеты Windows PowerShell и пользовательский интерфейс кластерного обновления устанавливаются автоматически.

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

Для кластерного обновления не требуется, чтобы на узлах кластера работала какая-либо служба. Тем не менее для CAU необходимо, чтобы в узлах кластера был установлен программный компонент (поставщик WMI). Этот компонент устанавливается вместе с компонентом отказоустойчивой кластеризации.

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

Какова разница между использованием кластерного обновления и диспетчера виртуальных машин System Center 2012 для обновления кластеров Hyper-V?

· Диспетчер виртуальных машин System Center 2012 предназначен для обновления только кластеров Hyper-V, тогда как кластерное обновление может обновлять поддерживаемые отказоустойчивые кластеры любого типа, включая кластеры Hyper-V.

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

· Если у вас уже есть лицензия System Center, вы можете продолжать использовать диспетчер виртуальных машин для обновления кластеров Hyper-V, потому что эта лицензия дает возможность интегрированного управления и обновления программного обеспечения.

· CAU поддерживается только в кластерах, которые работают под управлением Windows Server 2012 R2 и Windows Server 2012. Диспетчер виртуальных машин также поддерживает кластеры Hyper-V на компьютерах, работающих под управлением Windows Server 2008 и Windows Server 2008 R2.

Могу ли я использовать удаленное обновление для кластера, настроенного на самообновление?

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

Могу ли я применить свои параметры обновления кластера ко всем кластерам?

Да. Кластерное обновление поддерживает разные параметры выполнения обновления, определяющие, как ведет себя выполнение обновления, обновляя кластер. Эти параметры можно сохранить в качестве профиля выполнения обновления, и тогда их можно применять к любому кластеру. Рекомендуется сохранять и повторно использовать настройки для отказоустойчивых кластеров со сходными потребностями обновления. Например, можно создать “Профиль выполнения обновления для кластера SQL-серверов, критически важных для предприятия” для всех кластеров SQL-серверов Майкрософт, поддерживающих службы, критически важные для предприятия.

Где можно получить дополнительные сведения о спецификации для открытого подключаемого модуля кластерного обновления?

· Справочник по подключаемым модулям для кластерного обновления

· Образец подключаемого модуля для кластерного обновления

Требования и рекомендации для кластерного обновления

Применимо к:Windows Server 2012 R2, Windows Server 2012

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

· Рекомендации по использованию CAU

· Проверка готовности к обновлению кластера

Примечание

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

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

Установка компонента отказоустойчивости кластеров и средств отказоустойчивости кластеров

Для использования CAU необходимо установить компонент отказоустойчивости кластеров и средства отказоустойчивости кластеров. Средства отказоустойчивости кластеров включают в себя средства CAU (clusterawareupdating.dll), командлеты Windows PowerShell для работы с отказоустойчивыми кластерами и другие компоненты, необходимые для операций CAU. Инструкции по установке компонента отказоустойчивости кластеров см. в записи блога Установка компонента отказоустойчивости кластеров и средств отказоустойчивости кластеров.

Требования для установки средств отказоустойчивости кластеров зависят от того, координирует ли компонент CAU обновления как кластерная роль в отказоустойчивом кластере (в режиме самообновления) или с удаленного компьютера с ОС Windows Server 2012 R2, Windows Server 2012, Windows 8.1 или Windows 8 (в режиме удаленного обновления). Для режима самообновления CAU необходимо дополнительно установить кластерную роль CAU в отказоустойчивом кластере с помощью средств CAU.

Примечание

Чтобы удаленно управлять обновлениями для отказоустойчивого кластера Windows Server 2012 R2, используйте средства отказоустойчивой кластеризации из RSAT Windows Server 2012 R2. При помощи RSAT Windows Server 2012 R2 можно также удаленно управлять обновлениями для отказоустойчивого кластера Windows Server 2012.

В таблице ниже кратко описываются требования для установки компонента CAU в двух режимах обновления CAU.

Получение учетной записи администратора

Для использования компонентов CAU требуются указанные ниже разрешения администратора.

· Для просмотра и применения обновлений с помощью пользовательского интерфейса CAU или командлетов Windows PowerShell CAU нужна учетная запись домена с правами и разрешениями локального администратора на всех узлах кластера. Если у учетной записи нет достаточных прав в каждом узле, при выполнении этих действий в пользовательском интерфейсе CAU будет выводиться запрос на ввод необходимых учетных данных. Для использования командлетов CAU в Windows PowerShell можно предоставить необходимые учетные данные в виде параметра командлета.

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

· Для запуска анализатора соответствия рекомендациям CAU необходимо использовать учетную запись с правами администратора в узлах кластера и правами локального администратора на компьютере, который используется для выполнения командлета Test-CauSetup или анализа готовности к обновлению кластера с помощью пользовательского интерфейса CAU. Дополнительные сведения см. в разделе Проверка готовности к обновлению кластера.

Проверка конфигурации кластера

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

· Должно быть доступно достаточное число узлов кластера, чтобы в кластере был кворум.

· Все узлы кластера должны быть в одном домене Active Directory.

· Имя кластера должно разрешаться в сети с помощью DNS.

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

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

· Для использования сценариев Windows PowerShell, запускаемых перед обновлением или после него, во время обновления CAU убедитесь в том, что они установлены на всех узлах кластера или доступны для них. Например, они могут находиться в сетевой папке высокой доступности. Если сценарии сохранены в сетевой папке, настройте для нее разрешение на чтение для группы “Все”.

Настройка узлов для удаленного управления

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

Включение инструментария управления Windows (WMI)

Для всех узлов кластера должно быть настроено удаленное управление с помощью инструментария управления Windows (WMI). Она включена по умолчанию.

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

1. В консоли “Службы” запустите службу Удаленное управление Windows и задайте для нее тип запуска Автоматически.

2. Выполните командлет Set-WSManQuickConfigWindows PowerShell или следующую команду из командной строки с повышенными привилегиями.

3. winrm quickconfig -q

Если в узлах кластера используется брандмауэр Windows, то для поддержки удаленного взаимодействия WMI в каждом узле необходимо включить правило брандмауэра Удаленное управление Windows (HTTP). По умолчанию это правило включено.

Включение Windows PowerShell и удаленного взаимодействия Windows PowerShell

Для обеспечения режима самообновления и некоторых функций CAU в режиме удаленного обновления необходимо установить Windows PowerShell 3.0 или 4.0 и включить выполнение удаленных команд на всех узлах кластера. Среда Windows PowerShell устанавливается по умолчанию, и в ней включается удаленное взаимодействие.

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

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

· Запустите командлет Enable-PSRemotingWindows PowerShell.

· Настройте параметр групповой политики на уровне домена для удаленного управления Windows (WinRM).

Дополнительные сведения о включении Windows PowerShell см. в разделе about_Remote_Requirements.

Установка .NET Framework 4.5

Для обеспечения режима самообновления и некоторых функций CAU в режиме удаленного обновления необходимо установить платформу .NET Framework 4.5 во всех узлах кластера. Платформа NET Framework 4.5 устанавливается по умолчанию.

Чтобы установить компоненты .NET Framework 4.5, используйте мастер добавления ролей и компонентов в диспетчере сервера. Дополнительные сведения см. в разделе Установка и удаление ролей, служб ролей и компонентов.

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

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

· Протокол: TCP

· Направление: входящий

· Программа: wininit.exe

· Порты: динамические RPC-порты

· Профиль: домен

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

Примечание

Группу правил брандмауэра Windows Remote Shutdown нельзя включить, если она вступит в конфликт с параметрами групповой политики, настроенными для брандмауэра Windows.

Эквивалентные команды Windows PowerShell

Группу правил брандмауэра Удаленное завершение работы также можно включить путем указания параметра –EnableFirewallRules при выполнении следующих командлетов Windows PowerShell CAU: Add-CauClusterRole, Invoke-CauRun и SetCauClusterRole.

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

Set-NetFirewallRule -Group “@firewallapi.dll,-36751” -Profile Domain -Enabled true

Рекомендации по использованию CAU

Рекомендации по применению обновлений Майкрософт

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

Внимание

Одновременное использование CAU и методов, выполняющих автоматическое обновление отдельных узлов (по расписанию в заданное время), может привести к непредсказуемым результатам — вплоть до прерывания обслуживания и незапланированных простоев.

Рекомендуется придерживаться следующего плана действий.

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

Внимание

Автоматическая установка обновлений в узлах кластера может помешать установке обновлений с помощью CAU и привести к сбоям CAU.

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

o параметры, в соответствии с которыми перед загрузкой и установкой обновлений выводятся уведомления;

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

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

· Не настраивайте систему обновления, такую как службы Windows Server Update Services (WSUS), для автоматического применения обновлений (по расписанию в заданное время) на узлах кластера.

· Во всех узлах кластера должно быть настроено использование одного и того же источника обновлений, например сервера служб WSUS, Центра обновления Windows или Центра обновления Майкрософт.

· При использовании системы управления конфигурацией для обновления программного обеспечения на компьютерах в сети отмените все обязательные и автоматические обновления для узлов кластера. Примеры систем управления конфигурацией включают Microsoft System Center Configuration Manager 2007 и Microsoft System Center Virtual Machine Manager 2008.

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

Применение обновлений Майкрософт в филиалах

Для загрузки обновлений Майкрософт из Центра обновления Майкрософт или Центра обновления Windows на узлы кластера в филиале в некоторых случаях может потребоваться настроить параметры прокси-сервера для учетной записи Local System в каждом узле. Например, это может быть необходимо сделать в случае, если кластеры в филиалах получают доступ к Центру обновления Майкрософт или Центру обновления Windows для загрузки обновлений через локальный прокси-сервер.

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

netsh winhttp set proxy <ProxyServerFQDN >:<port> “<local>”

Здесь <ProxyServerFQDN> — это полное доменное имя прокси-сервера.

Например, чтобы настроить параметры прокси-сервера WinHTTP для учетной записи Local System, указав прокси-сервер MyProxy.CONTOSO.com и исключения локальных адресов, введите следующую команду.

netsh winhttp set proxy MyProxy.CONTOSO.com:443 “<local>”

Рекомендации по использованию подключаемого модуля Microsoft.HotfixPlugin

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

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

Примечание

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

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

Дополнительные рекомендации

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

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

· Чтобы настроить CAU в режиме самообновления, необходимо создать в Active Directory виртуальный объект-компьютер для кластерной роли CAU. Компонент CAU может создать этот объект автоматически при добавлении кластерной роли CAU, если у отказоустойчивого кластера достаточно разрешений. Однако из-за политик безопасности в некоторых организациях может быть необходимо предварительно подготовить этот объект в Active Directory. Описание этой процедуры см. в разделе Действия по предварительной настройке учетной записи для кластерной роли.

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

Проверка готовности к обновлению кластера

Чтобы проверить, соответствуют ли определенный отказоустойчивый кластер и сетевая среда многим из требований для применения обновлений ПО с помощью кластерного обновления, можно запустить анализатор соответствия рекомендациям CAU. Многие из тестов проверяют среду на готовность к применению обновлений Майкрософт с помощью подключаемого модуля по умолчанию Microsoft.WindowsUpdatePlugin.

Примечание

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

Анализатор соответствия рекомендациям можно запустить двумя способами.

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

2. Выполните командлет Test-CauSetupWindows PowerShell. Дополнительные сведения см. в разделе Test-CauSetup. Командлет можно выполнить на локальном или удаленном компьютере, на котором установлены командлеты Windows PowerShell CAU. Его также можно выполнить в узле отказоустойчивого кластера.

Тесты готовности к обновлению кластера

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

Общие сведения о подключаемых модулях CAU

Применимо к:Windows Server 2012 R2, Windows Server 2012

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

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

· Использование подключаемого модуля Microsoft.WindowsUpdatePlugin

· Использование подключаемого модуля Microsoft.HotfixPlugin

Установка подключаемого модуля

Подключаемые модули, не являющиеся подключаемыми модулями CAU по умолчанию (Microsoft.WindowsUpdatePlugin и Microsoft.HotfixPlugin), необходимо устанавливать отдельно. Если кластерное обновление используется в режиме самообновления, подключаемый модуль нужно установить на всех узлах кластера. Если кластерное обновление используется в режиме удаленного обновления, подключаемый модуль нужно установить на удаленном компьютере координатора обновлений. Для установки подключаемого модуля на каждом узле могут предъявляться дополнительные требования.

Чтобы установить подключаемый модуль, выполните инструкции, предоставленные его издателем. Чтобы вручную зарегистрировать подключаемый модуль в CAU, выполните командлет Register-CauPlugin на каждом компьютере, на котором установлен подключаемый модуль.

Указание подключаемого модуля и его аргументов

Указание подключаемого модуля CAU

Совет

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

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

· применение обновлений к кластеру;

· просмотр обновлений для кластера;

· настройка параметров самообновления кластера.

По умолчанию CAU выбирает подключаемый модуль Microsoft.WindowsUpdatePlugin. Однако вы можете указать любой подключаемый модуль, установленный и зарегистрированный в CAU.

С помощью командлетов CAU Windows PowerShell, перечисленных в приведенной ниже таблице, можно указать один или несколько подключаемых модулей для прогона обновления или проверки, передав их в параметре –CauPluginName. Чтобы указать несколько имен подключаемых модулей, разделите их запятыми. Если вы указываете несколько подключаемых модулей, то вы также можете контролировать то, как они влияют друг на друга во время прогона обновления, с помощью параметров -RunPluginsSerially, -StopOnPluginFailure и –SeparateReboots. Чтобы получить дополнительную информацию об использовании нескольких подключаемых модулей, используйте ссылки на документацию по командлетам в приведенной ниже таблице.

Если параметр подключаемого модуля CAU не указан с помощью этих командлетов, по умолчанию используется подключаемый модуль Microsoft.WindowsUpdatePlugin.

Указание параметров подключаемого модуля CAU

При настройке параметров прогона обновления можно указать одну или несколько пар (аргументов) имя=значение для подключаемого модуля, выбранного для использования. Например, в пользовательском интерфейсе CAU можно указать несколько аргументов следующим образом.

Name1=Value1;Name2=Value2;Name3=Value3

Пары имя=значение должны быть понятны указанному подключаемому модулю. Для некоторых подключаемых модулей аргументы необязательны.

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

· Несколько пар имя=значение разделяются точкой с запятой.

· Значение, содержащее пробелы, заключается в кавычки, например: Name1=”Value with Spaces”.

· Точный синтаксис значения зависит от подключаемого модуля.

Чтобы указать аргументы подключаемого модуля с помощью командлетов CAU Windows PowerShell, которые поддерживают параметр –CauPluginParameters, передайте этот параметр в следующем формате:

-CauPluginArguments @{Name1=Value1;Name2=Value2;Name3=Value3}

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

Указание дополнительных аргументов подключаемого модуля

Подключаемые модули, устанавливаемые CAU (Microsoft.WindowsUpdatePlugin и Microsoft.HotfixPlugin), предоставляют дополнительные возможности, доступные для выбора. В пользовательском интерфейсе CAU они отображаются на странице Дополнительные параметры после настройки параметров прогона обновления для подключаемого модуля. Если вы используете командлеты CAU Windows PowerShell, эти параметры настраиваются в качестве дополнительных аргументов подключаемого модуля. Дополнительные сведения см. в разделах Использование подключаемого модуля Microsoft.WindowsUpdatePlugin и Использование подключаемого модуля Microsoft.HotfixPlugin далее в этой статье.

Управление подключаемыми модулями с помощью командлетов Windows PowerShell

Командлет

Get-CauPlugin

Register-CauPlugin

Unregister-CauPlugin

Описание

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

Регистрирует подключаемый модуль обновления ПО CAU на локальном компьютере.

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

Примечание

Отменить регистрацию подключаемых модулей, устанавливаемых с помощью CAU (Microsoft.WindowsUpdatePlugin и Microsoft.HotfixPlugin), нельзя.

Использование подключаемого модуля Microsoft.WindowsUpdatePlugin

В таблице ниже приводится сводная информация о подключаемом модуле по умолчанию для CAU: Microsoft.WindowsUpdatePlugin.

Item

Описание

Требования

configuration

Дополнительные параметры

Подробности

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

· Устанавливает кластерные обновления непосредственно из Центра обновления Windows, из Центра обновления Майкрософт или с сервера служб Windows Server Update Services (WSUS).

· Устанавливает только выбранные обновления выпуска для общего распространения (GDR). По умолчанию подключаемый модуль применяет только важные обновления ПО.

Примечание

Чтобы применить обновления, не относящиеся к важным обновлениям ПО, выбранным по умолчанию (например обновления драйверов), можно настроить дополнительный параметр подключаемого модуля. Дополнительные сведения см. в разделе Настройка строки запроса агента обновления Windows.

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

· Изучите Рекомендации по применению обновлений Майкрософт, а затем внесите все необходимые изменения в конфигурацию Центра обновления Майкрософт для узлов отказоустойчивого кластера.

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

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

Примечание

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

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

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

Кроме того, можно настроить аргумент подключаемого модуля ‘IncludeRecommendedUpdates’=’True’.

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

Настройка строки запроса агента обновления Windows

Вы можете настроить аргумент для подключаемого модуля по умолчанию (Microsoft.WindowsUpdatePlugin), содержащий строку запроса агента обновления Windows (WUA). В этой инструкции используется API WUA для определения одной или нескольких групп обновлений Майкрософт, которые должны быть применены к каждому узлу, на основе критериев выбора. Вы можете объединить несколько критериев с помощью логического И или логического ИЛИ. Строка запроса агента обновления Windows указывается в аргументе подключаемого модуля следующим образом.

QueryString=”Criterion1=Value1 and/or Criterion2=Value2 and/or…”

Например, Microsoft.WindowsUpdatePlugin автоматически выбирает важные обновления, используя аргумент по умолчанию QueryString, который создается с помощью условий IsInstalled, Type, IsHidden и IsAssigned:

QueryString=”IsInstalled=0 and Type=’Software’ and IsHidden=0 and IsAssigned=1″

При указании аргумента QueryString он используется вместо аргумента по умолчанию QueryString, настроенного для подключаемого модуля.

Пример 1

Чтобы настроить аргумент QueryString, устанавливающий определенное обновление с идентификатором f6ce46c1-971c-43f9-a2aa-783df125f003, укажите следующую строку:

QueryString=”UpdateID=’f6ce46c1-971c-43f9-a2aa-783df125f003′ and IsInstalled=0″

Примечание

Предыдущий пример можно использовать для применения обновлений с помощью мастера кластерного обновления. Чтобы установить определенное обновление путем настройки параметров самообновления с помощью пользовательского интерфейса CAU либо командлета Add-CauClusterRole или Set-CauClusterRole Windows PowerShell, значение UpdateID необходимо заключить в две одинарные кавычки:

QueryString=”UpdateID=”f6ce46c1-971c-43f9-a2aa-783df125f003” and IsInstalled=0″

Пример 2.

Чтобы настроить аргумент QueryString, устанавливающий только драйверы, укажите следующую строку:

QueryString=”IsInstalled=0 and Type=’Driver’ and IsHidden=0″

Дополнительные сведения о синтаксисе, строках запроса для подключаемого модуля по умолчанию Microsoft.WindowsUpdatePlugin, условиях поиска (например, IsInstalled), которые можно включить в строки запроса, см. в разделе об условиях поиска в статье Справочник по API агента обновления Windows (WUA).

Использование подключаемого модуля Microsoft.HotfixPlugin

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

Item

Описание

Требования

configuration

Дополнительные параметры

Подробности

· Устанавливает выпуски обновлений Майкрософт для ограниченного распространения (исправления) из корневой папки файлового ресурса общего доступа SMB.

Примечание

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

· Также можно настроить для применения обновлений для сторонних драйверов, встроенного ПО и BIOS.

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

· Ознакомьтесь с разделом Рекомендации по использованию подключаемого модуля Microsoft.HotfixPlugin.

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

· Получите обновления от издателя и скопируйте или извлеките их в файловый ресурс общего доступа SMB (корневую папку с исправлениями), который поддерживает по крайней мере SMB 2.0 и доступен всем узлам кластера и удаленному компьютеру координатора обновлений (если используется режим удаленного обновления CAU). Дополнительные сведения см. ниже в разделе Настройка структуры корневой папки с исправлениями.

Примечание

По умолчанию этот подключаемый модуль устанавливает только исправления со следующими расширениями имени файла: MSU, MSI и MSP

· Скопируйте файл DefaultHotfixConfig.xml (который находится в папке %systemroot%System32WindowsPowerShellv1.0ModulesClusterAwareUpdating на компьютере, где установлены средства CAU) в корневую папку для исправлений, которую вы создали и в которую извлекли исправления. Например, скопируйте файл конфигурации в папку \MyFileServerHotfixesRoot.

Примечание

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

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

· Путь к общей корневой папке с исправлениями, которая содержит применяемые обновления и файл конфигурации исправлений. Вы можете ввести этот путь в пользовательском интерфейсе CAU или настроить аргумент подключаемого модуля HotfixRootFolderPath=<Path> Windows PowerShell.

Примечание

Корневую папку с исправлениями можно задать в виде пути к локальной папке или в виде UNC-пути в формате \Имя_сервераОбщий ресурсИмя_корневой_папки. Можно использовать путь к доменному или автономному пространству имен DFS. Однако функции подключаемого модуля, которые проверяют разрешения доступа в файле конфигурации исправлений, несовместимы с путем к пространству имен DFS. Поэтому, если вы настроили такой путь, необходимо отключить проверку разрешений доступа в пользовательском интерфейсе CAU или задав аргумент подключаемого модуля DisableAclChecks=’True’.

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

· Дополнительно можно настроить подключаемый модуль на принудительное использование шифрования SMB при доступе к данным из общей папки с исправлениями. В пользовательском интерфейсе CAU на странице Дополнительные параметры выберите параметр Требовать шифрования SMB при доступе к корневой папке исправлений или задайте аргумент подключаемого модуля RequireSMBEncryption=’True’ Windows PowerShell.

Важно

o Чтобы включить проверку целостности данных SMB с использованием подписания или шифрования SMB, необходимо выполнить дополнительные действия по настройке на SMB-сервере. Дополнительные сведения см. в шаге 4 раздела Ограничение доступа к корневой папке с исправлениями.

o Если выбран вариант принудительного использования шифрования SMB, а корневая папка исправлений не настроена для доступа с применением шифрования SMB, обновление не будет выполнено.

· Вы можете отключить выполняющиеся по умолчанию проверки достаточности разрешений на доступ к корневой папке исправлений и файлу конфигурации исправлений. В пользовательском интерфейсе CAU выберите параметр Отключить проверку административного доступа к корневой папке и файлу конфигурации исправлений или задайте аргумент подключаемого модуля DisableAclChecks=’True’.

· Вы также можете настроить аргумент HotfixInstallerTimeoutMinutes=<Integer>, чтобы указать, как долго подключаемый модуль должен ожидать завершения процесса установки исправления (значение по умолчанию составляет 30 минут). Например, чтобы задать период ожидания равным двум часам, укажите аргумент HotfixInstallerTimeoutMinutes=120.

· Вы также можете настроить аргумент подключаемого модуля HotfixConfigFileName = <name>, чтобы указать имя файла конфигурации исправлений, который находится в корневой папке исправлений. Если он не указан, используется имя по умолчанию DefaultHotfixConfig.xml.

Настройка структуры корневой папки с исправлениями

Чтобы подключаемый модуль исправлений работал, исправления должны иметь четко определенную структуру в общей папке SMB (корневой папке исправлений). Кроме того, необходимо настроить в подключаемом модуле исправлений путь к корневой папке исправлений с помощью пользовательского интерфейса CAU или командлетов CAU Windows PowerShell. Этот путь передается в подключаемый модуль в виде аргумента HotfixRootFolderPath. Для корневой папки исправлений можно выбрать одну из нескольких структур в соответствии с потребностями в обновлении, как показано в примерах ниже. Файлы и папки, которые не соответствуют структуре, игнорируются.

Пример 1. Структура папок, используемая для применения исправлений ко всем узлам кластера

Чтобы применить исправления ко всем узлам кластера, скопируйте их в папку с именем CAUHotfix_All в корневой папке исправлений. В этом примере аргументу подключаемого модуля HotfixRootFolderPath присваивается значение \MyFileServerHotfixesRoot. Папка CAUHotfix_All содержит три обновления с расширениями MSU, MSI и MSP, которые будут применены ко всем узлам кластера. Имена файлов обновлений приведены только для иллюстрации.

Примечание

В этом и последующих примерах файл конфигурации исправлений с именем по умолчанию DefaultHotfixConfig.xml находится в требуемом месте в корневой папке исправлений.

\MyFileServerHotfixesRoot DefaultHotfixConfig.xml CAUHotfix_All Update1.msu Update2.msi Update3.msp …

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

Чтобы применить обновления только к определенному узлу, используйте вложенную папку с именем узла в корневой папке исправлений. Используйте NetBIOS-имя узла кластера, например ContosoNode1. Затем переместите в эту вложенную папку обновления, которые необходимо применить только к этому узлу. В следующем примере аргументу подключаемого модуля HotfixRootFolderPath присваивается значение \MyFileServerHotfixesRoot. Обновления в папке CAUHotfix_All будут применены ко всем узлам кластера, а обновление Node1_Specific_Update.msu — только к узлу ContosoNode1.

\MyFileServerHotfixesRoot DefaultHotfixConfig.xml CAUHotfix_All Update1.msu Update2.msi Update3.msp … ContosoNode1 Node1_Specific_Update.msu …

Пример 3. Структура папок, используемая для применения обновлений, которые имеют расширения, отличные от MSU, MSI и MSP

По умолчанию подключаемый модуль Microsoft.HotfixPlugin применяет обновления только с расширениями MSU, MSI и MSP. Однако некоторые обновления могут иметь другие расширения и требовать других команд для установки. Например, может потребоваться применить обновление встроенного ПО с расширением EXE к узлу кластера. В корневой папке исправлений можно создать вложенную папку для установки обновления конкретного нестандартного типа. Также необходимо настроить соответствующее правило установки для папки, которое определяет команду установки в элементе <FolderRules> XML-файла конфигурации исправлений.

В следующем примере аргументу подключаемого модуля HotfixRootFolderPath присваивается значение \MyFileServerHotfixesRoot. Несколько обновлений будут применены ко всем узлам кластера, а обновление встроенного ПО SpecialHotfix1.exe будет применено к узлу ContosoNode1 с помощью правила FolderRule1. Подробнее о настройке правила FolderRule1 в файле конфигурации исправлений см. в подразделе Настройка файла конфигурации исправлений далее в этом разделе.

\MyFileServerHotfixesRoot DefaultHotfixConfig.xml CAUHotfix_All Update1.msu Update2.msi Update3.msp … ContosoNode1 FolderRule1 SpecialHotfix1.exe …

Настройка файла конфигурации исправлений

Файл конфигурации исправлений управляет тем, как подключаемый модуль Microsoft.HotfixPlugin устанавливает определенные типы исправлений в отказоустойчивом кластере. Схема XML файла конфигурации определяется в файле HotfixConfigSchema.xsd, который находится на компьютере с установленными средствами CAU в следующей папке:

%systemroot%System32WindowsPowerShellv1.0ModulesClusterAwareUpdating folder

Чтобы настроить файл конфигурации исправлений, скопируйте образец файла конфигурации DefaultHotfixConfig.xml из этого расположения в корневую папку исправлений и внесите в него изменения в соответствии со своим сценарием.

Важно

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

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

· Файлы исправлений с расширениями, которые подключаемый модуль может устанавливать по умолчанию (файлы MSU, MSI и MSP).

Они определяются как элементы <ExtensionRules> в элементе <DefaultRules>. Для каждого поддерживаемого по умолчанию типа файлов имеется один элемент <Extension>. Общая структура XML имеет следующий вид.

XML

<DefaultRules> <ExtensionRules> <Extension name=”MSI”> <!– Template and ExitConditions elements for installation of .msi files follow –> … </Extension> <Extension name=”MSU”> <!– Template and ExitConditions elements for installation of .msu files follow –> … </Extension> <Extension name=”MSP”> <!– Template and ExitConditions elements for installation of .msp files follow –> … </Extension> … </ExtensionRules> </DefaultRules>

Если необходимо применять обновления определенных типов ко всем узлам кластера в среде, можно определить дополнительные элементы <Extension>.

· Исправления и другие файлы обновлений, отличные от MSI, MSU или MSP, например обновления для сторонних драйверов, встроенного ПО и BIOS.

Каждый нестандартный тип файлов настраивается как элемент <Folder> в элементе <FolderRules>. Атрибут имени элемента <Folder> должен совпадать с именем вложенной папки в корневой папке исправлений, в которой будут содержаться обновления соответствующего типа. Эта вложенная папка может находиться в папке CAUHotfix_All или в папке для определенного узла. Например, если в корневой папке исправлений настроено правило FolderRule1, то, чтобы определить шаблон установки и условия выхода для обновлений в этой папке, настройте следующий элемент в XML-файле:

XML

<FolderRules> <Folder name=”FolderRule1″> <!– Template and ExitConditions elements for installation of updates in FolderRule1 follow –> … </Folder> … </FolderRules>

В таблице ниже описываются атрибуты <Template> и возможные дочерние элементы <ExitConditions>.

Атрибут <Template>

path

parameters

Описание

Полный путь к программе установки для типа файлов, определенного в атрибуте <Extension name>.

Чтобы указать путь к файлу обновления в структуре корневой папки исправлений, используйте элемент $update$.

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

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

Дочерний элемент <ExitConditions>

<Success>

<Success_RebootRequired>

<Fail_RebootRequired>

<AlreadyInstalled>

<NotApplicable>

Описание

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

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

Примечание

Элемент <Folder> может содержать атрибут alwaysReboot. Если этот атрибут задан, он указывает на то, что при возвращении исправлением, устанавливаемым этим правилом, одного из кодов выхода, которые определены в дочернем элементе <Success>, он интерпретируется как условие выхода <Success_RebootRequired>.

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

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

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

Важно

Все коды выхода, которые не определены явным образом в элементе <ExitConditions>, интерпретируются как коды сбоя обновления, и узел не перезапускается.

Ограничение доступа к корневой папке с исправлениями

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

Общий порядок действий.

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

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

3. Настройка разрешений на доступ к корневой папке исправлений

4. Настройка параметров для обеспечения целостности данных SMB

5. Включение правила брандмауэра Windows на сервере SMB

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

Учетная запись, которая используется в CAU для проверки параметров безопасности при выполнении прогона обновления с помощью подключаемого модуля Microsoft.HotfixPlugin, зависит от режима кластерного обновления (удаленное обновление или самообновление).

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

· Режим самообновления — имя виртуального объекта-компьютера, настроенного в Active Directory для кластерной роли CAU. Это либо имя виртуального объекта-компьютера, предварительно подготовленного в Active Directory для кластерной роли CAU, либо имя, созданное компонентом CAU для кластерной роли. Чтобы узнать имя, созданное компонентом CAU, выполните командлет CAU Get-CauClusterRole Windows PowerShell. В выходных данных ResourceGroupName — это имя созданной учетной записи виртуального объекта-компьютера.

Шаг 2. Настройка учетной записи пользователя в необходимых группах на файловом сервере SMB

Важно

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

Настройка учетной записи пользователя на SMB-сервере

1. Добавьте учетную запись, которая используется для выполнения прогонов обновления, в группу “Пользователи DCOM” и одну из следующих групп: “Опытные пользователи”, “Операторы сервера” или “Операторы печати”.

2. Чтобы предоставить учетной записи необходимые разрешения WMI, запустите на SMB-сервере консоль управления WMI. Запустите Windows PowerShell и введите следующую команду.

3. wmimgmt.msc

4. В дереве консоли правой кнопкой мыши щелкните Элемент управления WMI (локальный), а затем выберите пункт Свойства.

5. Щелкните Безопасность и разверните элемент Корень.

6. Щелкните CIMV2, а затем выберите Безопасность.

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

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

Шаг 3. Настройка разрешений на доступ к корневой папке исправлений

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

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

· Группа “Пользователи” имеет разрешение на чтение.

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

· Только некоторые субъекты безопасности могут (но необязательно) иметь разрешение на запись или изменение. К таким субъектам относятся группа локальных администраторов, СИСТЕМА, СОЗДАТЕЛЬ-ВЛАДЕЛЕЦ и TrustedInstaller. Остальные учетные записи и группы не могут иметь разрешения на запись и изменение для корневой папки исправлений.

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

· При использовании командлетов CAU Windows PowerShell настройте аргумент DisableAclChecks=’True’ в параметре CauPluginArguments для подключаемого модуля исправлений.

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

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

Шаг 4. Настройка параметров для обеспечения целостности данных SMB

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

· Сведения о включении подписания SMB см. в процедуре, описанной в статье 887429 базы знаний Майкрософт.

· Чтобы включить шифрование SMB для общей папки SMB, выполните на SMB-сервере следующий командлет Windows PowerShell:

· Set-SmbShare <ShareName> -EncryptData $true

·

Где <ShareName> — это имя общей папки SMB.

Чтобы включить принудительное шифрование SMB для подключений к SMB-серверу, можно также выбрать параметр Требовать шифрования SMB при доступе к корневой папке исправлений в пользовательском интерфейсе CAU или задать аргумент подключаемого модуля RequireSMBEncryption=’True’ с помощью командлетов CAU Windows PowerShell.

Важно

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

Шаг 5. Включение правила брандмауэра Windows на сервере SMB

В брандмауэре Windows на файловом сервере SMB необходимо включить правило Удаленное управление файловым сервером (SMB — входящий трафик). Оно включено по умолчанию в Windows Server 2012 R2 и Windows Server 2012.

Дополнительные параметры и профили прогона обновления для CAU

Применимо к:Windows Server 2012 R2, Windows Server 2012

В этом разделе описываются параметры прогона обновления, которые можно настроить для прогона обновления CAU. Эти дополнительные параметры можно настроить, если для применения обновлений или настройки параметров самообновления используется пользовательский интерфейс CAU или командлеты Windows PowerShell для CAU.

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

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

· Параметры, указываемые при запросе прогона обновления

· Использование профилей прогона обновления

Параметры, задаваемые в профиле прогона обновления

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

Важно

Чтобы задатьPreUpdateScriptилиPostUpdateScriptубедитесь, чтоWindows PowerShell3.0 или 4.0 и .NET Framework 4.5 устанавливаются и чтоWindows PowerShellна каждом узле кластера включено удаленное взаимодействие. Дополнительные сведения см. в разделеНастройка узлов для удаленного управлениявТребования и рекомендации для кластерного обновления.

ВАРИАНТ

StopAfter

WarnAfter

MaxRetriesPerNode

MaxFailedNodes

RequireAllNodesOnline

RebootTimeoutMinutes

PreUpdateScript

PostUpdateScript

ConfigurationName

CauPluginName

CauPluginArguments

Значение по умолчанию

Неограниченное время

По умолчанию предупреждение не выводится

3

Для большинства кластеров — целое число, примерно равное трети от количества узлов кластера

NONE

15

NONE

NONE

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

Если указывается сценарий, выполняемый перед обновлением или после него, но не задается параметр ConfigurationName, то используется конфигурация сеанса по умолчанию для Windows PowerShell (Microsoft.PowerShell).

Microsoft.WindowsUpdatePlugin

NONE

Подробности

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

Примечание

Если указан сценарий Windows PowerShell, выполняемый перед обновлением или после него, то весь процесс запуска сценариев и выполнения обновлений должен завершиться за время, указанное в параметре StopAfter.

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

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

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

Диапазон допустимых значений: от 0 до числа узлов кластеров, уменьшенного на 1.

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

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

Путь и имя файла сценария Windows PowerShell, выполняемого на каждом узле перед началом обновления и перед тем, как узел переводится в режим обслуживания. Имя файла должно иметь расширение .ps1, а общая длина пути и имени файла не должна превышать 260 символов. Чтобы сценарий был всегда доступен для всех узлов кластера, рекомендуется размещать его на диске в системе хранения данных кластера или в сетевой папке высокой доступности. Если сценарий находится в сетевой папке, убедитесь, что группа “Все” имеет для нее разрешение “Чтение”, и запретите доступ к папке, чтобы исключить несанкционированное изменение файлов.

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

Путь и имя файла для сценария Windows PowerShell, выполняемого после завершения обновления (после выхода узла из режима обслуживания). Имя файла должно иметь расширение .ps1, а общая длина пути и имени файла не должна превышать 260 символов. Чтобы сценарий был всегда доступен для всех узлов кластера, рекомендуется размещать его на диске в системе хранения данных кластера или в сетевой папке высокой доступности. Если сценарий находится в сетевой папке, убедитесь, что группа “Все” имеет для нее разрешение “Чтение”, и запретите доступ к папке, чтобы исключить несанкционированное изменение файлов.

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

Указывает конфигурацию сеанса Windows PowerShell, которая определяет сеанс, в котором выполняются сценарии (заданные параметрами PreUpdateScript и PostUpdateScript). Этот параметр также может ограничивать число запускаемых команд.

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

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

Domain=Domain.local

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

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

Для подключаемого модуля Microsoft.WindowsUpdatePlugin по умолчанию не требуются аргументы. При этом можно задать необязательный аргумент, например чтобы указать стандартную строку запроса для агента Центра обновления Windows, фильтрующую набор обновлений, которые применяются подключаемым модулем. В качестве имени укажите QueryString, а в качестве значения — весь запрос, заключенный в кавычки.

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

Параметры, указываемые при запросе прогона обновления

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

ВАРИАНТ

ClusterName

Учетные данные

NodeOrder

Значение по умолчанию

NONE

Подробности

NetBIOS-имя кластера, на котором следует выполнить прогон обновления.

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

Имена узлов кластера в том порядке, в каком их следует обновить (если возможно).

Примечание

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

Учетные данные текущей учетной записи

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

Использование профилей прогона обновления

Каждый прогон обновления можно связать с особым профилем прогона обновления. Профиль прогона обновления по умолчанию хранится в папке %windir%cluster. Если пользовательский интерфейс CAU используется в режиме удаленного обновления, то можно указать профиль прогона обновления во время применения обновлений или использовать профиль прогона обновления по умолчанию. Если CAU используется в режиме самообновления, то можно импортировать параметры из указанного профиля прогона обновления при настройке параметров самообновления. В обоих случаях можно переопределить значения, отображаемые для параметров прогона обновления, в соответствии с актуальными потребностями. Параметры прогона обновления можно сохранить в виде профиля прогона обновления с тем же или с другим именем файла. В следующий раз при применении обновлений или настройке параметров самообновления CAU автоматически выберет ранее выбранный профиль прогона обновления.

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

Эквивалентные команды Windows PowerShell

Параметры можно импортировать из профиля прогона обновления при выполнении командлета Invoke-CauRun, Add-CauClusterRole или Set-CauClusterRole.

В следующем примере выполняется проверка и полный прогон обновления в кластере с именем CONTOSO-FC1 с использованием параметров прогона обновления, заданных в файле C:WindowsClusterDefaultParameters.xml. Для остальных параметров командлета используются значения по умолчанию.

Windows PowerShell

$MyRunProfile = Import-Clixml C:WindowsClusterDefaultParameters.xml Invoke-CauRun –ClusterName CONTOSO-FC1 @MyRunProfile

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

Примечание

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

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

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

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

Широкое распространение виртуализации и потребности в создании отказоустойчивых систем даже при небольших внедрениях заставили компанию Microsoft пересмотреть свое отношение к доступным из коробки ролям Windows Server и политике лицензирования. Если раньше iSCSI Target предлагался только в редакции Windows Storage Server, то начиная с Server 2008 R2 он стал доступен в виде отдельно устанавливаемого компонента, а с выходом Windows Server 2012 закономерно стал частью ОС.

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

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

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

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

Следующим шагом укажите имя и размер создаваемого диска. Windows Server 2012 поддерживает новый формат виртуальных дисков — VHDX, а также динамически расширяемые диски. Если доступные ранее диски фиксированного размера резервировали дисковое пространство хранилища сразу при создании, то динамически расширяемые диски увеличивают размер согласно реально записанным в них данным. Это позволяет существенно экономить дисковое пространство хранилища, нарезая виртуальные диски с запасом.

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

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

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

Затем потребуется указать инициаторы, которым будет разрешен доступ к этой цели. IQN инициатора можно посмотреть на клиенте, для этого откройте Панель управления — Администрирование — Инициатор iSCSI, на вопрос об автоматическом запуске службы ответьте утвердительно.

IQN ткущего инициатора можно посмотреть на закладке Конфигурация:

Но можно поступить проще, перейдите на закладку Конечные объекты и выполните Быстрое подключение к Cерверу цели, подключиться по понятным причинам не получится, но IQN инициализатора останется в кэше сервера.

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

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

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

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

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

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

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

В данном материале мы будем рассматривать наиболее простую конфигурацию отказоустойчивого кластера, состоящего из двух узлов (нод) 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:ClusterStorageVolumeN. Обратите внимание, что это не просто папки на системном диске, а точки монтирования общих томов кластера.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Материал сайта pyatilistnik.org

Кластеры от компании Microsoft.

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

Далее на пулах можно создавать виртуальные диски следующих типов (не путать с VHD/VHDX):

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

Современные конвергентные системы для виртуализации от компании HP.

Решения виртуализации VMware.