Настройка кластера hyper v windows server 2012 - Доктор Windows

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

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.

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

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

В данном материале мы будем рассматривать наиболее простую конфигурацию отказоустойчивого кластера, состоящего из двух узлов (нод) SRV12R2-NODE1 и SRV12R2-NODE2, каждый из которых работает под управлением Windows Server 2012 R2. Обязательным условием для этих серверов является применение процессоров одного производителя, только Intel или только AMD, в противном случае миграция виртуальных машин между узлами будет невозможна. Каждый узел должен быть подключен к двум сетям: сети предприятия LAN и сети хранения данных SAN.

Вторым обязательным условием для создания кластера является наличие развернутой Active Directory, в нашей схеме она представлена контроллером домена SRV12R2-DC1.

Хранилище выполнено по технологии iSCSI и может быть реализовано на любой подходящей платформе, в данном случае это еще один сервер на Windows Server 2012 R2 — SRV12R2-STOR. Сервер хранилища может быть подключен к сети предприятия и являться членом домена, но это необязательное условие. Пропускная способность сети хранения данных должна быть не ниже 1 Гбит/с.

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

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

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

Миграцию виртуальных машин оставляем выключенной.

Остальные параметры оставляем без изменения. Установка роли Hyper-V потребует перезагрузку, после чего аналогичным образом настраиваем второй узел.

Затем перейдем к серверу хранилища, как настроить iSCSI-хранилище на базе Windows Server 2012 мы рассказывали в данной статье, но это непринципиально, вы можете использовать любой сервер цели iSCSI. Для нормальной работы кластера нам потребуется создать минимум два виртуальных диска: диск свидетеля кворума и диск для хранения виртуальных машин. Диск-свидетель — это служебный ресурс кластера, в рамках данной статьи мы не будем касаться его роли и механизма работы, для него достаточно выделить минимальный размер, в нашем случае 1ГБ.

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

И сопоставьте данной цели созданные виртуальные диски.

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

Подключенные диски инициализируем и форматируем.

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

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

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

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

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

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

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

При создании кластера для него создается виртуальный объект, обладающий сетевым именем и адресом. Укажем их в открывшемся Мастере создания кластеров.

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

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

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

Затем щелкнем правой кнопкой мыши на объекте кластера в дереве слева и выберем Дополнительные действия — Настроить параметры кворума в кластере.

Далее последовательно выбираем: Выбрать свидетель кворума — Настроить диск-свидетель и указываем созданный для этих целей диск.

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

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

Общие хранилища становятся доступны на всех узлах кластера в расположении C:ClusterStorageVolumeN. Обратите внимание, что это не просто папки на системном диске, а точки монтирования общих томов кластера.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник

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

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

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

Примечание

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

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

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

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

Примечание

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

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

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

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

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

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

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

Примечание

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

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

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

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

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

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

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

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

Примечание

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Важно

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Примечание

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

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

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

Примечание

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

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

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

Примечание

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

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

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

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

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

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

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

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

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

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

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

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

Примечание

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

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

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

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

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

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

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

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

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

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

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

Примечание

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Примечание

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Примечание

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Важно

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

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

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

Примечание

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

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

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

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

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

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

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

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

Примечание

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

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

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

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

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

Примечание

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

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

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

Примечание

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

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

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

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

Примечание

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

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

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

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

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

Примечание

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

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

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

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

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

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

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

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

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

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

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

Примечание

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

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

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

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

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

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

Примечание

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

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

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

Примечание

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Примечание

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

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

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

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

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

Примечание

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

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

Примечание

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

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

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. В поле Имя компьютера введите имя, которое будет использоваться для кластерной роли, и нажмите кнопку ОК.

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

Шаг 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.

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

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

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

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

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

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

Move-ClusterVirtualMachineRole -Name “FailoverTest” –Node ContosoFCNode2

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Stop-ClusterNode –Name ContosoFCNode2

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

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

Примечание

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

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

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

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

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

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

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

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

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

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?

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

Да. Обновления выпуска для ограниченного распространения (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 можно указать несколько аргументов следующим образом.

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

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.

· Ознакомьтесь с разделом Рекомендации по использованию подключаемого модуля Microsoft.HotfixPlugin.

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

Примечание

По умолчанию этот подключаемый модуль устанавливает только исправления со следующими расширениями имени файла: MSU, MSI и MSP

· Скопируйте файл DefaultHotfixConfig.xml (который находится в папке %systemroot%System32WindowsPowerShellv1.0ModulesClusterAwareUpdating на компьютере, где установлены средства CAU) в корневую папку для исправлений, которую вы создали и в которую извлекли исправления. Например, скопируйте файл конфигурации в папку \MyFileServerHotfixesRoot.

Примечание

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

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

· Путь к общей корневой папке с исправлениями, которая содержит применяемые обновления и файл конфигурации исправлений. Вы можете ввести этот путь в пользовательском интерфейсе CAU или настроить аргумент подключаемого модуля HotfixRootFolderPath=<Path> Windows PowerShell.

Примечание

Корневую папку с исправлениями можно задать в виде пути к локальной папке или в виде UNC-пути в формате \Имя_сервераОбщий ресурсИмя_корневой_папки. Можно использовать путь к доменному или автономному пространству имен DFS. Однако функции подключаемого модуля, которые проверяют разрешения доступа в файле конфигурации исправлений, несовместимы с путем к пространству имен DFS. Поэтому, если вы настроили такой путь, необходимо отключить проверку разрешений доступа в пользовательском интерфейсе CAU или задав аргумент подключаемого модуля DisableAclChecks=’True’.

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

· Дополнительно можно настроить подключаемый модуль на принудительное использование шифрования SMB при доступе к данным из общей папки с исправлениями. В пользовательском интерфейсе CAU на странице Дополнительные параметры выберите параметр Требовать шифрования SMB при доступе к корневой папке исправлений или задайте аргумент подключаемого модуля RequireSMBEncryption=’True’ Windows PowerShell.

Важно

o Чтобы включить проверку целостности данных SMB с использованием подписания или шифрования SMB, необходимо выполнить дополнительные действия по настройке на SMB-сервере. Дополнительные сведения см. в шаге 4 раздела Ограничение доступа к корневой папке с исправлениями.

o Если выбран вариант принудительного использования шифрования SMB, а корневая папка исправлений не настроена для доступа с применением шифрования SMB, обновление не будет выполнено.

· Вы можете отключить выполняющиеся по умолчанию проверки достаточности разрешений на доступ к корневой папке исправлений и файлу конфигурации исправлений. В пользовательском интерфейсе CAU выберите параметр Отключить проверку административного доступа к корневой папке и файлу конфигурации исправлений или задайте аргумент подключаемого модуля DisableAclChecks=’True’.

· Вы также можете настроить аргумент HotfixInstallerTimeoutMinutes=<Integer>, чтобы указать, как долго подключаемый модуль должен ожидать завершения процесса установки исправления (значение по умолчанию составляет 30 минут). Например, чтобы задать период ожидания равным двум часам, укажите аргумент HotfixInstallerTimeoutMinutes=120.

· Вы также можете настроить аргумент подключаемого модуля HotfixConfigFileName = <name>, чтобы указать имя файла конфигурации исправлений, который находится в корневой папке исправлений. Если он не указан, используется имя по умолчанию DefaultHotfixConfig.xml.

Настройка структуры корневой папки с исправлениями

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

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

Чтобы применить исправления ко всем узлам кластера, скопируйте их в папку с именем CAUHotfix_All в корневой папке исправлений. В этом примере аргументу подключаемого модуля HotfixRootFolderPath присваивается значение \MyFileServerHotfixesRoot. Папка CAUHotfix_All содержит три обновления с расширениями MSU, MSI и MSP, которые будут применены ко всем узлам кластера. Имена файлов обновлений приведены только для иллюстрации.

Примечание

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

\MyFileServerHotfixesRoot DefaultHotfixConfig.xml CAUHotfix_All Update1.msu Update2.msi Update3.msp …

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

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

\MyFileServerHotfixesRoot DefaultHotfixConfig.xml CAUHotfix_All Update1.msu Update2.msi Update3.msp … ContosoNode1 Node1_Specific_Update.msu …

Пример 3. Структура папок, используемая для применения обновлений, которые имеют расширения, отличные от MSU, MSI и MSP

По умолчанию подключаемый модуль Microsoft.HotfixPlugin применяет обновления только с расширениями MSU, MSI и MSP. Однако некоторые обновления могут иметь другие расширения и требовать других команд для установки. Например, может потребоваться применить обновление встроенного ПО с расширением EXE к узлу кластера. В корневой папке исправлений можно создать вложенную папку для установки обновления конкретного нестандартного типа. Также необходимо настроить соответствующее правило установки для папки, которое определяет команду установки в элементе <FolderRules> XML-файла конфигурации исправлений.

В следующем примере аргументу подключаемого модуля HotfixRootFolderPath присваивается значение \MyFileServerHotfixesRoot. Несколько обновлений будут применены ко всем узлам кластера, а обновление встроенного ПО SpecialHotfix1.exe будет применено к узлу ContosoNode1 с помощью правила FolderRule1. Подробнее о настройке правила FolderRule1 в файле конфигурации исправлений см. в подразделе Настройка файла конфигурации исправлений далее в этом разделе.

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

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

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

%systemroot%System32WindowsPowerShellv1.0ModulesClusterAwareUpdating folder

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

Важно

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

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

· Файлы исправлений с расширениями, которые подключаемый модуль может устанавливать по умолчанию (файлы MSU, MSI и MSP).

Они определяются как элементы <ExtensionRules> в элементе <DefaultRules>. Для каждого поддерживаемого по умолчанию типа файлов имеется один элемент <Extension>. Общая структура XML имеет следующий вид.

XML

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

· Исправления и другие файлы обновлений, отличные от MSI, MSU или MSP, например обновления для сторонних драйверов, встроенного ПО и BIOS.

Каждый нестандартный тип файлов настраивается как элемент <Folder> в элементе <FolderRules>. Атрибут имени элемента <Folder> должен совпадать с именем вложенной папки в корневой папке исправлений, в которой будут содержаться обновления соответствующего типа. Эта вложенная папка может находиться в папке CAUHotfix_All или в папке для определенного узла. Например, если в корневой папке исправлений настроено правило FolderRule1, то, чтобы определить шаблон установки и условия выхода для обновлений в этой папке, настройте следующий элемент в XML-файле:

XML

В таблице ниже описываются атрибуты <Template> и возможные дочерние элементы <ExitConditions>.

Атрибут <Template>

path

parameters

Описание

Полный путь к программе установки для типа файлов, определенного в атрибуте <Extension name>.

Чтобы указать путь к файлу обновления в структуре корневой папки исправлений, используйте элемент $update$.

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

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

Дочерний элемент <ExitConditions>

<Success_RebootRequired>

<Fail_RebootRequired>

Описание

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

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

Примечание

Элемент <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

Значение по умолчанию

Неограниченное время

По умолчанию предупреждение не выводится

Для большинства кластеров — целое число, примерно равное трети от количества узлов кластера

NONE

Данный параметр действует только при выполнении сценариев.

Если указывается сценарий, выполняемый перед обновлением или после него, но не задается параметр ConfigurationName, то используется конфигурация сеанса по умолчанию для Windows PowerShell (Microsoft.PowerShell).

Microsoft.WindowsUpdatePlugin

NONE

Подробности

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

Примечание

Если указан сценарий Windows PowerShell, выполняемый перед обновлением или после него, то весь процесс запуска сценариев и выполнения обновлений должен завершиться за время, указанное в параметре StopAfter.

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

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

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

Диапазон допустимых значений: от 0 до числа узлов кластеров, уменьшенного на 1.

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

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

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

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

Путь и имя файла для сценария Windows PowerShell, выполняемого после завершения обновления (после выхода узла из режима обслуживания). Имя файла должно иметь расширение .ps1, а общая длина пути и имени файла не должна превышать 260 символов. Чтобы сценарий был всегда доступен для всех узлов кластера, рекомендуется размещать его на диске в системе хранения данных кластера или в сетевой папке высокой доступности. Если сценарий находится в сетевой папке, убедитесь, что группа “Все” имеет для нее разрешение “Чтение”, и запретите доступ к папке, чтобы исключить несанкционированное изменение файлов.

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

Указывает конфигурацию сеанса Windows PowerShell, которая определяет сеанс, в котором выполняются сценарии (заданные параметрами PreUpdateScript и PostUpdateScript). Этот параметр также может ограничивать число запускаемых команд.

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

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

Domain=Domain.local

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

Чтобы задать аргумент в пользовательском интерфейсе CAU, введите имя, нажмите клавишу TAB, а затем введите соответствующее значение. Чтобы задать следующий аргумент, снова нажмите клавишу TAB. Каждое имя и значение автоматически отделяются друг от друга знаком равенства (=). Пары автоматически отделяются друг от друга точкой с запятой.

Для подключаемого модуля Microsoft.WindowsUpdatePlugin по умолчанию не требуются аргументы. При этом можно задать необязательный аргумент, например чтобы указать стандартную строку запроса для агента Центра обновления Windows, фильтрующую набор обновлений, которые применяются подключаемым модулем. В качестве имени укажите QueryString, а в качестве значения — весь запрос, заключенный в кавычки.

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

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

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

ВАРИАНТ

ClusterName

Учетные данные

NodeOrder

Значение по умолчанию

NONE

Подробности

NetBIOS-имя кластера, на котором следует выполнить прогон обновления.

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

Имена узлов кластера в том порядке, в каком их следует обновить (если возможно).

Примечание

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

Учетные данные текущей учетной записи

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

Использование профилей прогона обновления

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

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

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

Параметры можно импортировать из профиля прогона обновления при выполнении командлета Invoke-CauRun, Add-CauClusterRole или Set-CauClusterRole.

В следующем примере выполняется проверка и полный прогон обновления в кластере с именем CONTOSO-FC1 с использованием параметров прогона обновления, заданных в файле C:WindowsClusterDefaultParameters.xml. Для остальных параметров командлета используются значения по умолчанию.

Windows PowerShell

$MyRunProfile = Import-Clixml C:WindowsClusterDefaultParameters.xml Invoke-CauRun –ClusterName CONTOSO-FC1 @MyRunProfile

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

Примечание

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

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

Источник

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

Пример настройки хранилища iSCSI

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

Сначала в сети iSCSI SAN были созданы три логических устройства LUN. Один LUN был создан для диска кворума кластера (520 Мбайт). Другой LUN предназначен для 10 виртуальных машин и имеет размер 375 Гбайт. Третий LUN выделен для небольшой тестовой виртуальной машины. Все три LUN представлены в формате NTFS.

После того, как были созданы LUN, была выполнена настройка iSCSI Initiator на обоих узлах Server 2012. Чтобы добавить цели iSCSI, был выбран iSCSI Initiator в меню Tools в диспетчере сервера. На вкладке Discovery я нажал кнопку Discover Portal. В результате появилось диалоговое окно Discover Portal, куда были введены IP-адрес (192.168.0.1) и порт iSCSI (3260) сети SAN.

Затем я перешел на вкладку Targets и нажал кнопку Connect. В диалоговом окне Connect To Target («Подключение к целевому серверу») я ввел целевое имя iSCSI SAN. Оно было получено из свойств SAN. Имя зависит от поставщика SAN, имени домена и имен созданных LUN. Помимо целевого имени я установил режим Add this connection to the list of Favorite Targets.

По завершении настройки iSCSI эти LUN появились на вкладке Targets iSCSI Initiator. Чтобы автоматически подключать LUN при запуске Server 2012, я убедился, что они перечислены на вкладке Favorite Targets, как показано на экране A.

Экран A. Настройка iSCSI Initiator

Наконец, были назначены буквенные обозначения устройствам LUN с помощью оснастки Disk Management консоли управления Microsoft (MMC). Я выбрал Q для диска кворума и W для диска, используемого для виртуальных машин и общих томов кластера (CSV). При назначении буквенных обозначений необходимо сначала назначить их на одном узле. Затем нужно перевести диски в автономный режим и сделать аналогичные назначения на втором узле. Результаты назначения букв дискам для одного узла приведены на экране B. При создании кластера диски будут показаны как доступное хранилище.

Экран B. Буквенные обозначения, назначенные дискам iSCSI узла

Источник

Virtualization isn’t famous just because of the easier management of backup and restore procedures compared to those for physical systems. It has other advantages, and one of them is definitely VM’s High Availability (HA). The term means that VMs should be available, regardless of the availability of the physical host it is running at. There are some specific methods for ensuring HA of the VMs. Specifically, I’d like to talk about failover clustering, which is Microsoft’s native feature for Windows Server with a Hyper-V role enabled.

Failover cluster is a set of several similar Hyper-V servers (called nodes), which can be specifically configured to work together, so that one node can take the load (VMs, services, processes) if another one goes down or if there is a disaster. Sounds cool, right?

Moreover, the process of migration from one node to another can be done manually by a system admin when he wants to test a planned failover or automatically by a failover cluster service if there is an unexpected disaster (unplanned failover).

However, admins should know that unplanned failover doesn’t provide the VM with zero downtime: VMs will be unavailable for a few seconds, which is necessary so the failover service realizes the case of disaster and is able to maintain the failover itself. This is still considered as High Availability option because it takes less time to be executed compared to a physical server environment, where you would need to wait until the whole server is repaired.

Last but not least, Hyper-V failover clustering has perfect scalability. Once you have another server that you’re willing to add to the system, it won’t require difficult reconfigurations or any downtime, and it will be added to the cluster easily on the fly with the help of a system wizard.

If you’re interested in the technology, don’t forget to check a list of requirements and limitations before you go ahead and attempt to deploy it.

Requirements

Hardware

Shared storage: The most important thing here is to have shared storage as a starting point. Since VM disks will not be moved to different storage, your storage should be able to work simultaneously with multiple hosts and provide them with read and write access. Examples of this idea are a low-cost NAS device, an expensive Storage Area Network (SAN) or even a Windows Server with an iSCSI target. For Windows Server 2012 and later, you can also use SMB 3.0 file shares as shared storage. To learn more about this option, use the Deploy Hyper-V over SMB guide.

Note: Shared storage is, in this case, still a single point of failure. Because you don’t have a redundant spare storage, you’re still vulnerable when something happens to your storage. So, don’t consider failover cluster as a panacea for all disasters.

CPU with native virtualization support: Yes, in 2014 it’s rare to find business CPU without this support. However, it’s still wise to double-check that. You should check the following features: VT for Intel CPUs and AMD-V for AMD ones. Please note, there is no reason to attempt building failover cluster in a mixed environment. Either Intel or AMD. Period.

Using chips from different CPU families, even from the same company, will also end up decreasing your chances to make the technology work. The best practice is to use identical chips.

Networking: Besides connection to the shared storage, nodes should be interconnected with each other by some network. Regardless of whether you use a TCP/IP or iSCSI connection, the best practice is to separate this traffic from your production site.

See a full list of hardware requirements for Windows Server 2008 R2, for Windows Server 2012 and Windows Server 2012 R2.

Software

OS versions: If you’re using Windows Server 2008 R2, you’re eligible to try failover cluster when you have either an Enterprise or a Datacenter license. In Windows Server 2012 and Windows Server 2012 R2 the feature is available with Standard and Datacenter licenses. Besides that, those servers must have either a full installation or a Server Core one.

OS settings: From the settings point of view, servers should be joined to the same domain. In addition, they should have activated and installed Hyper-V and Failover Cluster roles with all dependences required within the installation.

Figure 1. Adding the Failover Clustering feature to Windows Server 2012 R2

How to set Hyper-V Failover Cluster

So, you’ve checked every point above and made sure your environment is suitable for Hyper-V Failover Cluster, and you’re ready to try it out.

For the purpose of demonstration, I’ve set up a test lab of 2 Windows Server 2012 R2 servers with Hyper-V and Failover Cluster features installed. I joined them to the same domain and created a shared 10GB disk to use as the cluster shared volume (CSV). Then, I put a disk online on both nodes, initialized with GPT partitioning, created a simple NTFS partition for all 10GB and quick formatted it.

Note: Disk letter doesn’t have to be assigned and the ReFS file system can be used if both nodes are running on Windows Server 2012 R2.

As a starting point for any operation with your clusters, use the Failover Cluster Manager (FCM), which can be found easily via tools in Windows Server Manager.

Figure 2. Failover Cluster Manager in Windows Server 2012 R2

The first thing you should do in FCM is running a cluster configuration validation. A simple wizard asks you to select servers (nodes) and testing options, and then it validates the configuration and gives you a detailed report of this validation.

Figure 3. Validation of cluster configuration
If you got a green light from the validation wizard, you can proceed with cluster setup, selecting the appropriate wizard. The Create Cluster wizard is rather simple, and I doubt you will have any issue with its settings.

Figure 4,5. Create Failover Cluster wizard
It shouldn’t take long to create a cluster, and you’ll be presented shortly with the brand new failover cluster you’ve created. Click Connect to Cluster if it doesn’t happen automatically.

Figure 6. Failover Cluster Manager, connected to a cluster

At the same time, you can see a new object in your Active Directory, created for your failover cluster.

Figure 7. New object for Failover Cluster in AD

Going back to FCM, I’ve navigated to the storage – disks node and added a prepared-in-advance cluster disk to the cluster shared volumes. This changed the disk file system from NFS to CSVFS, so every node will be aware that a shared cluster is using this disk. At the same time, this disk was mounted to C:ClusterStorageVolume1 and showed up on both nodes in my cluster.

Figure 8. Failover Cluster manager – Add disk to CSV

Now, I can utilize the disk as a storage for my Hyper-V environment and create a VM on it. I believe I can omit describing this process and come back to the created VM.

Now, I have to make this VM highly available, which means that VM gets a configured “HA” role. You can easily do this via Roles – Configure role – Virtual Machine.

I’ll implement the settings, and the HA VM will appear in the Roles tab.

Figure 9. FCM, HA role is applied for “WinXP” VM

If everything went smoothly, congratulations! Your VM is now highly available and will be up and running, regardless of the server condition.

To prove it, you can test the VM migration. According to the terms, there are two types of live migration: The first one is when you do it by purpose — planned failover. The second one is when it happens accidentally — unplanned failover.

Planned failover is a piece of cake. Right-click on a VM, select Move – Live Migration – Select Node… The cluster migrates your VM to the selected node and changes the owner node value, so you understand what the current situation is and which node owns the VM at the moment.

Figure 10. Failover Cluster, planned failover

From the VM point of view, there will no disruption in the working scenario. All processes remain to work and the users working with them shouldn’t notice anything.

You can test unplanned failover by simply rebooting the owning node. Connect to FCM on a remaining node and see the migration process.

Additional information

Don’t forget to check the VM properties right from Failover Cluster Manager, because they contain some very important options you might want to adjust in advance, including options like preferred owning node, VM priority and ability to get failback once the broken node is restored.

Figure 11. VM properties by FCM

That should be it, folks! Explore the power of High Availability and Hyper-V Failover Cluster. Let me know about your experience in the comments below.

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

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

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

Сервер HP ProLiant DL 560 Gen8 4x Xeon 8 core 64 GB RAM 2 шт.
SAS Хранилище HP P2000 на 24 2,5» дисков 1 шт.
Диски для хранилища 300 Gb 24 шт. //С объемом не густо, но к сожалению бюджеты такие бюджеты…
Контроллер для подключения SAS производства HP 2 шт.
Сетевой адаптер на 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 подключенный хост — дайте ему имя. Советую называть так: имясервера_номер контроллера (A или B)
И так, пока не подключите оба сервера к обоим контроллерам.

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

ClusterNetwork — здесь ходит служебная информаци кластера (хэртбит, регулирование записи на хранилище)
LiveMigration — тут думаю все ясно
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 Полное руководство. Рэнд Моримото, Майкл Ноэл, Гай Ярдени, Омар Драуби, Эндрю Аббейт, Крис Амарис.

Автор: UrbanRider

Источник

Источник

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ограничения

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Требования

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

Поддержка NPIV

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

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

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

Функции MPIO

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

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

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

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

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

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

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

См. также:

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

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

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

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

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