Windows server failover cluster windows server 2012

В 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. Выбор виртуальных машин, которым необходимо обеспечить высокую надежность

Время на прочтение
5 мин

Количество просмотров 71K

Здравствуй, %username%!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Set-VMSwitch “VSwitch” -DefaultFlowMinimumBandwidthWeight 15

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

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

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

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

Для Live Migration.

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

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

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

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

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

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

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

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

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

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

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

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

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

Failover cluster в Windows Server 2012 R2 — это высокодоступная группа серверов, которая обеспечивает непрерывность работы приложений и сервисов. Она обеспечивает автоматический перенос нагрузки с одного сервера на другой в случае сбоя или обслуживания. Настройка failover cluster Windows Server 2012 R2 может быть сложной задачей, но с помощью этого подробного руководства вы сможете освоить основные шаги для успешной настройки.

Первым шагом является установка роли Failover Cluster на все серверы в группе. Для этого откройте Server Manager, выберите «Manage» в правом верхнем углу экрана и выберите «Add Roles and Features». В мастере установки выберите серверы, на которых вы хотите установить роль Failover Cluster, затем выберите «Failover Clustering» в списке ролей. Пройдите по всем шагам мастера и установите роль на всех выбранных серверах.

После установки роли Failover Cluster на серверах, откройте Failover Cluster Manager на одном из серверов. Выберите «Create Cluster» в панели действий, затем введите имена всех серверов, которые вы хотите включить в группу. Убедитесь, что все серверы находятся в одной доменной сети и Windows Firewall на всех серверах настроен правильно.

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

Поздравляем! Вы успешно настроили failover cluster в Windows Server 2012 R2. Теперь вы можете добавлять ресурсы (такие как диски и сети) в группу и настраивать резервные копии. Управление группой осуществляется через Failover Cluster Manager, где вы можете просматривать статусы ресурсов и управлять их состоянием.

Failover cluster

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

Настройка failover cluster в Windows Server 2012 R2 включает несколько шагов:

1. Установка необходимого оборудования и настройка сети.
2. Установка операционной системы (Windows Server 2012 R2) на каждый сервер в кластере.
3. Настройка сети и сетевых адаптеров на каждом сервере.
4. Установка роли «Failover Clustering» на каждый сервер в кластере.
5. Создание нового кластера и добавление в него серверов.
6. Настройка хранилища для кластера (например, файловый ресурс для общего использования).
7. Настройка приложений и служб для работы с кластером.

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

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

Основные шаги

Настройка failover cluster в Windows Server 2012 R2 включает в себя несколько основных шагов:

1. Установка роли Failover Cluster

Сначала необходимо установить роль Failover Cluster на каждом сервере, который будет входить в кластер. Для этого откройте «Server Manager» и выберите «Add Roles and Features». В появившемся окне выберите «Role-based or feature-based installation», затем выберите сервер, на котором хотите установить роль. В списке ролей найдите «Failover Clustering» и установите его.

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

После установки роли на каждом сервере, нужно создать и настроить кластер. В Server Manager выберите «Tools», затем «Failover Cluster Manager». В менеджере кластера нажмите «Create Cluster», выберите сервера, которые вы хотите включить в кластер, и следуйте инструкциям мастера.

3. Добавление ресурсов кластера

После создания кластера вы можете добавить ресурсы, такие как диски или сетевые адаптеры, которые будут доступны во время работы кластера. Для этого в менеджере кластера выберите «More Actions» и «Configure Cluster Quorum Settings». В дополнительных настройках добавьте необходимые ресурсы.

4. Настройка на выделенные IP-адреса

Вы также можете настроить выделенные IP-адреса для узлов кластера. В менеджере кластера выберите «More Actions», затем «Properties» и перейдите на вкладку «Address». Нажмите «Add» и введите IP-адреса для каждого узла кластера.

5. Тестирование и проверка работоспособности

После завершения настройки кластера, рекомендуется провести тесты и проверить работоспособность. С помощью инструментов, таких как «Cluster Validation Wizard», вы можете проверить правильность настройки и выявить возможные проблемы.

Следуя этим основным шагам, вы можете настроить failover cluster в Windows Server 2012 R2 и обеспечить высокую доступность и отказоустойчивость серверов в вашем окружении.

Установка failover cluster

Перед установкой failover cluster на сервере Windows Server 2012 R2 необходимо убедиться, что выполнены следующие условия:

1.	Все серверы, которые будут входить в кластер, должны иметь одинаковую версию и редакцию Windows Server 2012 R2.
2.	Все серверы должны быть добавлены в домен Active Directory.
3.	Создайте специальную служебную учетную запись в Active Directory, которая будет использоваться для работы кластера. Учетная запись должна иметь права администратора на всех серверах кластера, а также права на создание компьютерных объектов в домене.

После выполнения указанных условий можно приступать к установке failover cluster:

1.	Откройте Server Manager и выберите пункт «Управление» в заголовке окна.
2.	Выберите «Добавить роли и компоненты».
3.	В мастере установки выберите «Службы фаилового кластера» в разделе «Роли службы» и перейдите к следующему шагу.
4.	Подтвердите установку дополнительных компонентов, если они требуются, и установите галочку напротив требуемых серверов, которые будут входить в кластер.
5.	Продолжайте мастер установки, выбрав дополнительные компоненты, если это необходимо, и указав сетевые адреса, которые будут использоваться для работы кластера.
6.	Настройте дополнительные параметры, такие как идентификаторы кластера и имена сетей.
7.	Подтвердите установку и дождитесь завершения процесса.

Настройка failover cluster

Failover cluster (кластер с аварийным восстановлением) в Windows Server 2012 R2 позволяет создавать высокодоступные и отказоустойчивые приложения и службы. Для настройки failover cluster необходимо выполнить следующие шаги:

Шаг	Описание
1	Установите Windows Server 2012 R2 на каждый сервер, который вы хотите включить в кластер. Убедитесь, что все серверы находятся в одной доменной сети.
2	Установите роль Failover Cluster на каждый сервер, используя Server Manager. Выберите опцию «Установка средство для высокой доступности и кластеризации».
3	Перед выполнением конфигурации кластера, убедитесь, что на каждом сервере настроены сетевые интерфейсы и привязки, и что серверы имеют доступ друг к другу.
4	Запустите мастер создания кластера, выбрав сервер-управляющий. Введите имена серверов, которые вы хотите добавить в кластер.
5	Выберите сетевые адаптеры, которые будут использоваться для взаимодействия узлов кластера. При необходимости, настройте другие параметры кластера.
6	Выполните проверку валидности кластера, чтобы убедиться, что все настройки правильные.
7	Завершите мастер создания кластера, присвоив ему имя и IP-адрес. После завершения настройки, будет создано новое хранилище для файлов кластера.

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

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

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

• Убедитесь в том, что все серверы, которые нужно добавить в качестве узлов кластера, работают под управлением одной и той же версии 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. Нажмите кнопку Далее. На открывшейся странице подтвердите выбранные параметры и нажмите кнопку Далее.

После выполнения мастера и отображения страницы Сводка щелкните пункт Просмотр отчета, чтобы посмотреть отчет о выполненных мастером задачах. Последний отчет находится в папке systemroot\Cluster\Reports под именем 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%\System32\WindowsPowerShell\v1.0\Modules\ClusterAwareUpdating на компьютере, где установлены средства CAU) в корневую папку для исправлений, которую вы создали и в которую извлекли исправления. Например, скопируйте файл конфигурации в папку \\MyFileServer\Hotfixes\Root\.

Примечание

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

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

· Путь к общей корневой папке с исправлениями, которая содержит применяемые обновления и файл конфигурации исправлений. Вы можете ввести этот путь в пользовательском интерфейсе 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 присваивается значение \\MyFileServer\Hotfixes\Root\. Папка CAUHotfix_All содержит три обновления с расширениями MSU, MSI и MSP, которые будут применены ко всем узлам кластера. Имена файлов обновлений приведены только для иллюстрации.

Примечание

В этом и последующих примерах файл конфигурации исправлений с именем по умолчанию DefaultHotfixConfig.xml находится в требуемом месте в корневой папке исправлений.

\\MyFileServer\Hotfixes\Root\ DefaultHotfixConfig.xml CAUHotfix_All\ Update1.msu Update2.msi Update3.msp …

Пример 2. Структура папок, используемая для применения определенных обновлений только к конкретному узлу

Чтобы применить обновления только к определенному узлу, используйте вложенную папку с именем узла в корневой папке исправлений. Используйте NetBIOS-имя узла кластера, например ContosoNode1. Затем переместите в эту вложенную папку обновления, которые необходимо применить только к этому узлу. В следующем примере аргументу подключаемого модуля HotfixRootFolderPath присваивается значение \\MyFileServer\Hotfixes\Root\. Обновления в папке CAUHotfix_All будут применены ко всем узлам кластера, а обновление Node1_Specific_Update.msu — только к узлу ContosoNode1.

\\MyFileServer\Hotfixes\Root\ 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 присваивается значение \\MyFileServer\Hotfixes\Root\. Несколько обновлений будут применены ко всем узлам кластера, а обновление встроенного ПО SpecialHotfix1.exe будет применено к узлу ContosoNode1 с помощью правила FolderRule1. Подробнее о настройке правила FolderRule1 в файле конфигурации исправлений см. в подразделе Настройка файла конфигурации исправлений далее в этом разделе.

\\MyFileServer\Hotfixes\Root\ DefaultHotfixConfig.xml CAUHotfix_All\ Update1.msu Update2.msi Update3.msp … ContosoNode1\ FolderRule1\ SpecialHotfix1.exe …

Настройка файла конфигурации исправлений

Файл конфигурации исправлений управляет тем, как подключаемый модуль Microsoft.HotfixPlugin устанавливает определенные типы исправлений в отказоустойчивом кластере. Схема XML файла конфигурации определяется в файле HotfixConfigSchema.xsd, который находится на компьютере с установленными средствами CAU в следующей папке:

%systemroot%\System32\WindowsPowerShell\v1.0\Modules\ClusterAwareUpdating 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:\Windows\Cluster\DefaultParameters.xml. Для остальных параметров командлета используются значения по умолчанию.

Windows PowerShell

$MyRunProfile = Import-Clixml C:\Windows\Cluster\DefaultParameters.xml Invoke-CauRun –ClusterName CONTOSO-FC1 @MyRunProfile

С помощью профиля прогона обновления можно повторять операции обновления отказоустойчивого кластера с одинаковыми параметрами для обработки исключений, ограничений по времени и других рабочих показателей. Поскольку такие параметры обычно связаны с некоторым классом отказоустойчивых кластеров, например “Все кластеры Microsoft SQL Server” или “Важнейшие кластеры организации”, можно задать для каждого профиля прогона обновления имя, соответствующее классу отказоустойчивых кластеров, с которым он будет использоваться. Кроме того, можно организовать профиль прогона обновления для сетевой папки, которая доступна всем отказоустойчивым кластерам определенного класса в ИТ-организации.

Примечание

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

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

Failover clusters in Windows Server 2012 provide a high-availability solution for many server roles and applications.

By implementing failover clusters, you can maintain application or service availability if one or more computers in the failover cluster fails.

There are a lot of information that you can digest on the Failover Clustering, for more information please log in to :

http://technet.microsoft.com/en-us/library/hh831579.aspx

For this Failover Clustering demo, i will be using 4 VM’s, which is domain controller and 3 member server. Please refer to the screenshot :

1st : our 1st step is to configure a Failover Cluster, which is in this step i will connect a cluster nodes to the iSCSI targets…

Scenario for this demo is very simple :

“Your organization has important applications and services that the company wants to make highly available.

Some of these services cannot be made redundant by using NLB, so you decide to implement failover clustering.

Because iSCSI storage is already in-place, you decide to use the iSCSI storage for failover clustering.

First, you will implement the core components for failover clustering and validate the cluster, and then you will
create the failover cluster.”

1 – For this configuration i will be using my OSI-SVR3 member server, on OSI-SVR3, open Server Manager, click Tools, and then click the iSCSI Initiator…

2 – In the Microsoft iSCSI interface, just click Yes…

3 – on the iSCSI initiator Properties interface, click the Discovery tab and then click Discover Portal…

** Internet SCSI (iSCSI) initiator –> to established a connection with an iSCSI target

4 – In the IP address or DNS name box, type 172.16.0.21, and then click OK…

172.16.0.21 – OSi-SVR1 server

5 – Next, click the Targets tab, and click Refresh…

** In the Targets list, select iqn.1991-05…., and then click Connect…

6 – then cllick Add this connection to the list of Favorite Targets, and then click OK two times…

** Please repeat the step 1 – 6 on your SVR4 server…

7 – Switch to SVR3 and open Computer Management and make sure that you have few disk already attach to your Server to stimulate this demo, for this demo i have 3 VHD that i attach previously on the SVr3 server, all 3 disk having 30GB space each, you may choose your own space.

8 – Switch to SVR4 and please make sure also that you have the same disk configuration…

** make sure that all the disk is online (Right-click Disk 1, and then click Online)….

2nd : Let install the failover clustering feature on our SVR3 server….

1 – Open Server Manager and continue with add roles & feature until you reach Select features interface, then click Failover Clustering and continue with installation…

2 – next on the Confirm installation selections interface, click Install…

3 – Once installation complete, click Close…

** Repeat steps 1 – 3 on SVR4 server…

4 – Now we need to validate the both servers for failover clustering, on the SVR3 server open Failover Cluster Manager…

5 – On the right pane of Failover Cluster Manager, click Validate Configuration…

6 – In the Validate a Configuration Wizard interface, click Next…

7 – On the Select Servers or a cluster interface, please add our SVR3 & SVR4 and then click Next…

8 – On the Testing options interface, click Run all tests (recommended) and then click Next…

9 – On the Confirmation interface, click Next…

10 – This process might take up to 5 – 10 minutes…

11 – Once the validation tests to finish, on the Summary page, click View Report…

12 – Just verify that all tests completed…

3rd : Our next step is to create the failover cluster…

1 – in the Failover Cluster Manager, click Create Cluster….

2 – then click Next…

3 – On the Select Servers interface, make sure you add SVR3 & SVR4 in the selected servers and then click Next…

4 – In Access Point for Administering the Cluster interface, in the Cluster Name box, type OSICluster1.

** Under Address, type 172.16.0.125, and then click Next.

5 – In the Confirmation box, verify the information, and then click Next…

6 – On the Summary interface, click Finish…

4th : Configuring CSV

” Cluster Shared Volumes (CSV) enable multiple nodes in a failover cluster to simultaneously have read-write access to the same LUN (disk) that is provisioned as an NTFS volume.

With CSV, clustered roles can fail over quickly from one node to another node without requiring a change in drive ownership, or dismounting and remounting a volume.

CSV also help simplify the management of a potentially large number of LUNs in a failover cluster.”

1 – On SVR3 server, in the Failover Cluster Manager console, expand cluster1.Adatum.com, expand Storage, and then click Disks.

** locate a disk that is assigned to Available Storage. You can see this in the Assigned To column.

** Right-click that disk, and then click Add to Cluster Shared Volumes.

** Verify that the disk is assigned to Cluster Shared Volume…

5th : Our next step is to deploy and configure Highly Available File Server…

1 – On the SVR4 server, open Server Manager, click add roles & features and continue to Select server roles and then select File Server,  then click Next 2 times…

2 – On the Confirmation interface, click Install…

3 – Next, switch back to SVR3 server, in the Failover Cluster Manager, expand Cluster1.adatum.com, right-click Roles, and then select Configure Role…

4 – click Next…

5 – On the Select Role interface, select File Server, and then click Next….

6 – On the File Server Type interface, click File Server for general use, and then click Next…

7 – On the Client Access Point interface, in the Name box, type OSI-FS, in the Address box, type 172.16.0.130, and then click Next…

8 – On the Select Storage interface, select the Cluster Disk 3 check box, and then click Next…

9 – On the Confirmation interface, click Next…

10 – click Finish…

6th : Next we going to add a shared folder to a highly available File Server…

1 – Switch to SVR4 server and open Failover Cluster Manager…

** Expand Cluster1.Adatum.com, and then click Roles.

** Right-click OSI-FS, and then select Add File Share…

2 – In the Select the profile for this share interface, click SMB Share – Quick, and then click Next…

3 – On the Select the server and the path for this share interface, verify the server & Volume to share and then click Next…

4 – On the Specify share name interface, in the Share name box, type OSI-Docs, and then click Next…

5 – On the Configure share settings interface, do not make any changes, and then click Next…

6 – On the Specify permissions to control access interface, click Next…

7 – On the Confirm selections interface, click Create…

8 – On the View results interface, click Close…

9 – Next we need to configure failover and failback settings, on the Failover Cluster Manager, click Roles, right-click OSI-FS, and then click Properties…

“** Failover transfers the responsibility of providing access to resources in a cluster from one node to another. Failover can occur when an administrator intentionally moves resources to another node for maintenance, or when unplanned downtime of one node happens because of hardware failure or other reasons. In addition, service failure on an active node can initiate failover to another node.”

“** The Cluster service can failback instances that were originally hosted on the offline node after the offline node becomes active again. When the Cluster service fails back an instance, it follows the same procedures that it performs during failover. That is, the Cluster service takes all the resources in the instance offline, moves the instance, and then brings all the resources in the instance back online.”

10 – Click the Failover tab and then click Allow failback…

** Click Failback between, and set values to 3 and 4 hours.

11 – Next, click the General tab, then select SVR3 and SVR4 as preferred owners and make sure you move SVR4 up, then click OK…

7th : Now we have to validate / verify the Deployment of our High Availability File Server

1 – Switch to DC01 server (Domain Server), try access to \\osi-fs\osi-docs…

** Verify that you can access the location and that you can open the osi-docs folder…

2 – To verify you can create a any text document inside this folder…

3 – Next, switch back to SVR3 server and open the Failover Cluster Manager.

** Expand Cluster1.adatum.com, and then click Roles. Note the current owner of OSI-FS (SVR3)

** Right-click OSI-FS, click Move, and then click Select Node…

4 – In the Move Clustered Role box, select the cluster node (it will be either SVR3 or SVR4), and then click OK…

5 – Verify that SVR4 has moved to a new owner…

** I do recommend that you switch back to DC1 server and verify that you can still access the \\osi-fs\osi-docs…

6 – Next, in the Failover Cluster Manager, right-click the node (I choose SVR4) , select More Actions, and then click Stop Cluster Service…

7 – Verify that SVR4 now is down…

8 – Verify also OSI-FS has moved to another node which is SVR3…

** ** I do recommend that you switch back to DC1 server again and verify that you can still access the \\osi-fs\osi-docs…

9 – switch back to SVR3 server and on the Failover Cluster Manager, click Nodes. Right-click the stopped node which the SVR4, select More Actions, and then click Start Cluster Service…

10 – Verify all nodes status now up…

11 – Next, expand Storage, and then click Disks.

In the center pane, right-click the disk that is assigned to Disk Witness in Quorum then click Take Offline…

“** Quorum is the number of elements that must be online for a cluster to continue running. In effect, each element can cast one vote to determine whether the cluster continues to run. Each cluster node is an element that has one vote. In case there is an even number of nodes, then an additional element, which is known as a witness, is
assigned to the cluster. The witness element can be either a disk or a file share. Each voting element contains a copy of the cluster configuration; and the Cluster service works to keep all copies synchronized at all times.”

12 – then click Yes…

13 – Switch to DC1 server and verify that you can still access the \\osi-fs\osi-docs location. By doing this, you
verified that the cluster is still running, even if the witness disk is offline…

14 – Now switch back to SVr3 server, in Failover Cluster Manager, expand Storage, click Disks, right-click the disk that is in Offline status, and then click Bring Online…

15 – Next, right-click Cluster1.Adatum.com, select More Actions, and then click Configure Cluster Quorum Settings…

16 – click Next…

17 – On the Select Quorum Configuration Option interface, click Advanced quorum configuration, and then click Next…

18 – On the Select Voting Configuration interface,Do not make any changes, and then click Next…

19 – On the Select Quorum Witness interface, select Configure a disk witness and then click Next…

20 – On the Configure Storage Witness interface, select Cluster Disk 3, and then click Next…

21 – click Next…

22 – click Finish…

** we have succesfully tested the failover scenarios and next we going to configure CAU

8th : Configure CAU – Cluster-Aware Updating

** Cluster-Aware Updating (CAU) is a technology in Windows Server 2012 that automatically updates cluster nodes with Windows Update hotfix, by keeping the cluster online, and minimizing downtime.

** During an update procedure, CAU transparently takes each cluster node offline, installs the updates and any dependent updates, and then performs a restart if necessary. CAU then brings the node back online, and moves to update the next node in a cluster.

1 – Before we proceed, please make sure that you have install Failover Clustering feature in DC1 Domain Server…

2 – Switch back to SVR3 & SVR4 server, and please verify also that Inbound Rule for Remote Shutdown (RPC-EP-In) & Inbound Rule for Remote Shutdown (TCP-In) rule is enabled…

3 – let’s return to DC1 domain server and open Cluster-Aware Updating console…

4 – In the Cluster-Aware Updating interface, in the Connect to a failover cluster drop-down list box, select OSICLUSTER1, and then click Connect…

5 – In the Cluster Actions pane, click Preview updates for this cluster…

6 – In the OSICluster1-Preview Updates interface, click Generate Update Preview List…

7 – After few minutes, updates will display in the list and then click Close…

8 – still on the DC1 server, now we need to update the failover cluster and configure the self-updating…

** in the Cluster-Aware Updating console, click Apply updates to this cluster…

9 – On the Getting Started interface, click Next…

10 – On the Advanced options interface, review the options for updating, and then click Next…

11 – On the Additional Update Options interface, click Next…

12 – On the Confirmation interface, click Update, and then click Close…

13 – In the Cluster nodes pane, you can review the progress of the updating process…

** Please take note that 1 node of the cluster is in a waiting state, and the other node is restarting after it is updated.

** Wait until the process is finished and both nodes will restarted automatically.

14 – The process is finished when both nodes show Succeeded…

15 – Once the SVR3 restarted, log in as administrator and open Cluster-Aware Updating…

** In the Cluster-Aware Updating box, in the Connect to a failover cluster drop-down list box, select OSICLUSTER1. Click Connect….

16 – Click the Configure cluster self-updating options in the Cluster Actions pane…

17 – On the Getting Started interface, click Next…

18 – On the Add CAU Clustered Role with Self-Updating Enabled interface, click Add the CAU clustered role, with self-updating mode enabled, to this cluster, and then click Next…

19 – On the Specify self-updating schedule page,configure your own schedule and then click Next…

20 – On the Advanced Options interface, click Next…

21 – On the Additional Update Options interface, click Next….

22 – On the Confirmation interface, click Apply…

23 – After the clustered role is added successfully, click Close and we have successfully configured CAU.

That’s all for now.. i know its a long step, but i hope for those who taking MCSA exam code 70-412, you should do a lot of exercises on the Failover Cluster.

Wait for my Failover Clustering with Hyper-V post in next few week… 🙂