Убедитесь что для объекта имени кластера cno установлены разрешения на доступ к безопасной зоне dns

Обновлено: 30.06.2024

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

На самом деле установка WSFC не требует таких больших полномочий. В этой статье Лао Ван поделится планом полномочий WSFC AD для всех. Мы будем использовать принцип минимизации полномочий в максимально возможной степени при разработке.

В основном около двух сценариев

1. Сверните разрешения

2. Предварительное обеспечение CNO

Я упомянул процесс создания кластера в предыдущем блоге. Взяв в качестве примера эру WSFC 2012, когда мы вводим имя кластера, кластер будет использовать нашу текущую учетную запись выполнения для создания объекта CNO в AD и создания CNO в DNS. Записи DNS. Обычные пользователи в AD также могут регистрировать записи в DNS по умолчанию, поэтому нам не нужно заботиться о записях DNS CNO. Нам нужно заботиться о полномочиях CNO и полномочиях VCO.

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

Распространите учетную запись через групповую политику или вручную добавьте ее на каждый узел кластераГруппа локальных администраторов

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

После того, как первый шаг будет выполнен, давайте снова подумаем об этом. Поскольку вы создаете мастер кластеров для подключения к AD и создания CNO, у вас должен быть доступ на запись в AD. Этот доступ на запись не нужно напрямую назначать администраторам домена или С полномочиями администраторов предприятия учетная запись управления кластером или группа учетных записей управления кластером должны иметь только OU.Создание компьютерных объектовА такжеПрочитать все атрибутыАвторизация может создавать объекты CNO для выполнения необходимой работы.

CNO, созданный в эпоху 2008 года, по умолчанию будет создаваться только в подразделении компьютера по умолчанию. Начиная с эпохи WSFC 2012, CNO будет по умолчанию создаваться в подразделении, в котором расположен объект компьютера узла кластера. Мы также можем указать, что CNO создается для определенного Под каким OU Лао Ван продемонстрирует всем желающим.

Откройте ADUC -> выберите OU, в котором должен быть сгенерирован CNO -> Свойства -> Безопасность

Добавить грант cluadminСоздание компьютерных объектовА такжеПрочитать все атрибутыОрган власти

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

Вы можете видеть, что после WSFC 2012 CNO кластера поддерживается в указанном OU

После создания вы можете нормально видеть записи CNO и DNS.

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

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

Итак, на следующем шаге нам нужно запустить приложение для создания VCO на WSFC. Прежде чем мы сказали, что создание и управление VCO осуществляется CNO, нам также необходимо предоставить учетной записи компьютера CNO полномочия на создание VCO в OU.

Точно так же CNO нужно толькоСоздание компьютерных объектовА такжеПрочитать все атрибутыРазрешение, поскольку VCO и CNO по умолчанию создаются в одном подразделении с 2012 года, поэтому нам нужно предоставить разрешения CNO только тому подразделению, в котором находится CNO.

Помимо AD, VCO также нужны записи DNS. Записи DNS VCO также создаются и обслуживаются CNO. Поэтому необходимо убедиться, что учетная запись компьютера CNO имеет зону DNS.разрешение на редактированиеСоздать разрешения,Разрешение на удаление не является обязательным. Если вы его не выберете, возможно, вам придется вручную очистить записи CNO DNS.

После предоставления полномочий OU и DNS CNO ниже создается VCO, и обнаруживается, что AD и DNS могут быть записаны как обычно.

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

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

Создавайте компьютерные объекты иПрочитать все атрибутыОрган власти

В кластере CNO естьСоздание компьютерных объектовА такжеПрочитать все атрибутыОрган власти

CNO кластера имеет право создавать записи и изменять записи для зоны DNS.

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

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

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

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

Дайте разрешение CNO после создания кластера

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

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

Традиционно администратор AD дает разрешение, а затем позволяет администратору кластера подключиться к AD для создания

С помощью предустановок мы можем заранее создавать объекты CNO в AD.

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

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

Администратор AD также может заранее назначить разрешение OU для CNO на создание VCO, потому что CNO уже был предварительно установлен, поэтому его нужно предоставить только один раз, что более беспроблемно.

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

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

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

Шаги по предустановке объектов CNO

Администратор AD создает объект-компьютер в соответствии с именем, указанным администратором кластера, и отключает его.

Щелкните Объект компьютера-> Свойства-> Безопасность, чтобы предоставить учетной записи cluadmin право полного контроля над объектом CNO.

Если кластеру затем необходимо создать объекты VCO, у вас есть два варианта на выбор.

Вручную назначьте объект CNO тому подразделению, в котором он расположенСоздание компьютерных объектовА такжеПрочитать все атрибутыРазрешения, примененные к областиЭтот объект "и" все потомки "

Предустановленные объекты VCO

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

Шаги работы предустановленных объектов VCO

Создать компьютерный объект VCO и отключить

Предоставление компьютерных объектов CNO объектам компьютеров VCOполностью контролироватьОрган власти

Передайте объект CNO в зону DNSИзменить и создатьОрган власти

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

Обнаружено, что используемая учетная запись cluadmin была назначена целевому объекту CNO.полностью контролироватьРазрешение, автоматическая онлайн-активация была создана перед отключенной учетной записью компьютера CNO

Создать объекты DTC VCO согласно заранее запланированному имени

Кластер обнаруживает, что текущий объект VCO существует, и объект CNO имеет разрешение на объект VCO. Предустановленный объект VCO будет автоматически запущен онлайн.

Записи VCO DNS также создаются правильно

Ознакомьтесь с требованиями разрешений традиционной модели AD WSFC.

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

Учетная запись для создания кластера должна иметь целевое подразделение.Создание компьютерных объектовА такжеПрочитать все атрибутыРазрешение

Объект CNO, который создает VCO, должен иметь OU, в котором он расположен.Создание компьютерных объектовА такжеПрочитать все атрибутыОрган власти

Объект CNO, который создает VCO, должен иметь разрешения на создание и изменение зоны DNS.

Убедитесь, что объект CNO имеет право сбросить пароль для объекта VCO. По умолчанию VCO, созданный CNO, имеет

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

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

Вышеупомянутое является фактической проверкой Pharaoh на соответствие требованиям традиционных разрешений AD кластера WSFC и того, как использовать минимизированные разрешения для выполнения требований разрешений WSFC, надеясь принести пользу заинтересованным друзьям.

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

2 - узлы - оба Windows Server 2012 - третий блок 2012 года, действующий как iSCSI SAN - все машины находятся на одном хосте Hyper-V - домен - Windows Server 2003

2 сети - 10.xxx для внешней и 192.168.154.x для внутренней и iSCSI - брандмауэр Windows отключен

Я не могу заставить DTC или SQL работать в кластере - оба, похоже, имеют одну и ту же проблему - они, кажется, устанавливают ОК, но связанные объекты компьютера не создаются в AD, как и записи DNS, а затем ресурсы сетевого имени. ошибка со следующими ошибками:

1196 - Ресурсу сетевого имени кластера "Имя кластера" не удалось зарегистрировать одно или несколько связанных DNS-имен по следующей причине: дескриптор недействителен

(Я создал записи DNS вручную, но это не помогло)

1069 - Кластерный ресурс "MGCLSQLDEVDTC" типа "Сетевое имя" в кластерной роли "MGCLSQLDEVDTC" не выполнен.
1205. - Служба кластеров не смогла полностью перевести кластерную службу или приложение "MGCLSQLDEVDTC" в оперативный или автономный режим. Один или несколько ресурсов могут находиться в состоянии сбоя. Это может повлиять на доступность кластерной службы или приложения.
1254 - Кластерная роль 'MGCLSQLDEVDTC' превысила порог отработки отказа. Он исчерпал сконфигурированное количество попыток аварийного переключения в течение выделенного ему периода аварийного переключения и будет оставлен в аварийном состоянии. Не будет предпринято никаких дополнительных попыток перевести роль в оперативный режим или перенести ее на другой узел в кластере. Пожалуйста, проверьте события, связанные с ошибкой. После устранения проблем, вызывающих сбой, роль можно перевести в оперативный режим вручную или кластер может попытаться перевести его в оперативный режим после периода задержки перезапуска.
1228 - Ресурс сетевого имени кластера "Имя кластера" обнаружил ошибку, включив сетевое имя на этом узле. Причина ошибки: "Невозможно получить токен входа".
Код ошибки был "1326".

4625 - Учетная запись не смогла войти в систему Тема: Узел сервер, Учетная запись, для которой не удалось войти в систему: CNO

Некоторые ошибки из журнала кластера:

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

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

Проблема 1

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

Предположим, что администратор настроил узел с двумя сетевыми адаптерами для одной сети:

Сетевой драйвер кластера (Netft.sys) для каждой сети будет использовать только один сетевой адаптер (или группу). Поэтому при данной конфигурации сеть кластера Cluster Network 1 (10.10.10.0/16) будет задействовать только сетевой адаптер Card1, тогда как сетевой адаптер Card2 будет игнорироваться, то есть не будет применяться для связи между узлами. Поскольку работает только одна сеть, при выходе Card1 из строя или утрате сетевого соединения узел не сможет взаимодействовать с другими узлами. Это единственная точка отказа. Чтобы избежать подобной ситуации, кластер следует настраивать так, чтобы между узлами существовало, как минимум, два сетевых пути. В этом случае при отказе одного из сетевых адаптеров связь между узлами будет осуществляться через другой сетевой адаптер.

Проблема 2

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

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

Кроме того, администратор поменял IP-адреса узла Node2 (192.168.0.2 и 10.10.10.2). При этом на узле Node1 в кластере он добавил группу файлового сервера, назначив ей IP-адрес 192.168.0.15.

Затем администратор протестировал кластер, чтобы убедиться в успешном переходе группы файлового сервера на узел Node2 при отработке отказа. Однако IP-адрес группы файлового сервера не виден в сети, то есть группа находится в автономном состоянии. В журнале событий системы регистрируется событие 1069, описание которого указывает на отказ ресурса с этим IP-адресом.

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

Команда инициирует создание журнала кластера на каждом узле. Для построения журнала кластера только на одном узле можно добавить параметр -Node и указать имя узла. Можно также добавить параметр -TimeSpan для создания журнала только за последние x минут. Например, приведенная ниже команда предписывает построить журнал кластера на узле Node2 за последние 15 минут:

В результатах, представленных на экране 1, указано состояние «status 5035.».

Экран 1. Информация о состоянии 5035 в файле журнала кластера

Создавая ресурс с IP-адресом, можно указать сеть, которая будет использоваться для него. Если эта сеть не будет существовать на узле, куда данный ресурс перейдет при отработке отказа, то WSFC не поменяет сеть, используемую ресурсом. В данном примере, при том IP-адресе, который указал администратор, и маске подсети, применяемой этим IP-адресом, группа файлового сервера сможет работать только по сети Cluster Network 1 (192.168.0.0/24).

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

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

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

Проблема 3

Для формирования кластера необязательно быть администратором домена, но создание объектов в Active Directory (AD) требует наличия соответствующих прав. Как минимум, необходимо обладать правами на просмотр и создание объектов (Read and Create) в том подразделении (OU), где создается данный объект имени кластера (CNO). CNO – это объект-компьютер, связанный с ресурсом-кластером «Имя кластера». При создании кластера служба WSFC использует учетную запись, с которой вы регистрировались в системе, чтобы создать объект CNO в том же OU, которому принадлежат узлы. Если вы не обладаете достаточными правами в отношении данного OU, кластер не будет создан, и система выдаст ошибку, как показано на экране 3.

Экран 3. Ошибка процесса создания кластера

В статье «Диагностика проблем отказоустойчивых кластеров Windows Server 2012» (№ 10 за 2013 г.) я рассказывал об использовании мастера проверки конфигурации в диспетчере отказоустойчивости кластеров для выявления причин возникающих проблем. Мастер позволяет выполнять различные тесты, включая проверку настроек Active Directory. В ответ на попытку запуска этого теста без достаточных прав в отношении данного OU будет выдана ошибка, как показано на экране 4. Соответствующая настройка прав позволит вам создать кластер.

Экран 4. Ошибка проверки настроек Active Directory

Все другие ресурсы с сетевыми именами в кластере ассоциированы с объектами виртуальных компьютеров (VCO), создаваемыми в том же OU, что и CNO. Следовательно, при назначении ролей в кластере необходимо указать CNO с соответствующими правами (просмотр и создание) в отношении OU, поскольку CNO формирует все VCO в кластере. В противном случае новая роль будет находиться в состоянии сбоя. Тогда в журнале появится событие 1194 (см. экран 5).

Экран 5. Событие 1194 в журнале событий системы

Есть и другие установки локального компьютера, способные вызвать ошибки (включая ошибки отказа в доступе) при создании VCO в AD.

1. В составе локальной группы «Пользователи» больше нет группы «Прошедшие проверку пользователи». Обычно она удаляется объектами групповой политики (GPO) или шаблонами безопасности.

2. В локальной политике безопасности разрешение Access this computer from the network («Доступ к этому компьютеру по сети») или Add workstations to the domain («Добавление рабочих станций к домену») больше не включает группу «Прошедшие проверку пользователи». Обычно она удаляется объектами групповой политики (GPO) или шаблонами безопасности.

3. Включены следующие права доступа:

сетевой доступ (не разрешать перечисление учетных записей SAM анонимными пользователями);
сетевой доступ (не разрешать перечисление учетных записей SAM и общих ресурсов анонимными пользователями).

4. Ресурс имени кластера в состоянии сбоя.

Проблема 4

CNO и VCO – учетные записи компьютера и, подобно учетным записям пользователей, они имеют пароли, генерируемые AD случайным образом. По умолчанию политика домена предусматривает сброс пароля учетной записи компьютера каждые 60 дней.

СNO используется для таких операций, как добавление новых узлов к кластеру, создание новых объектов в домене и выполнение динамической миграции виртуальных машин с узла на узел. Для выполнения этих операций пароль CNO в домене должен быть актуальным. Для верности служба кластера делает попытку сброса паролей этих объектов по истечении половины срока (через 30 дней). Если пароль не сброшен на 60-дневной отметке, имя кластера не видно в сети.

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

Экран 6. Сброс пароля вручную в диспетчере отказоустойчивости кластеров

При обращении к AD для сброса пароля диспетчер отказоустойчивости кластеров задействует учетную запись пользователя, под которой вы зарегистрировались в системе, поэтому вашей учетной записи должно быть предоставлено право на изменение пароля CNO; в противном случае восстановление не будет выполнено. Необходимо также убедиться, что включено разрешение на сброс пароля CNO и VCO, чтобы служба WSFC могла выполнять сброс при необходимости.

Проблема 5

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

Каждый пакет включает регистрационный номер, по которому отслеживается факт приема пакета. Это работает следующим образом: узел Node1, отправляющий регистрационный номер 1111, ожидает ответного пакета, включающего 1111. Эти действия совершаются между всеми узлами каждую секунду. Если узел Node1 не получает ответного пакета, он отправляет следующий по порядку регистрационный номер (1112), и т.д.

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

Экран 7. Событие 1135 в журнале событий системы

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

1. Отказ сетевого оборудования.

2. Устаревший драйвер или устаревшая прошивка сетевого адаптера.

3. Сетевая задержка.

4. Протокол IPv6 разрешен на серверах, но параметры брандмауэра Windows выключают следующие разрешения для входящего и исходящего трафика:

основы сетей – объявление поиска соседей;
основы сетей – запрос поиска соседей.

5. Настройка коммутаторов, брандмауэров или маршрутизаторов не допускает прохождения трафика данных UDP-датаграмм.

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

7. Неправильно настроенные параметры буфера приема у драйвера сетевого адаптера.

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

Для добавления счетчика отброшенных принятых пакетов в окне системного монитора щелкните правой кнопкой на дисплее и выберите «Добавить счетчики». В открывшемся окне добавления счетчиков укажите нужный компьютер, выполните прокрутку и выберите счетчик «Отброшено принятых пакетов». В выпадающем списке «Экземпляры выбранного объекта» выберите нужный сетевой адаптер и нажмите «Добавить» (см. экран 8).

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

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

Проблема 6

В листинге приведен сценарий Windows PowerShell, позволяющий выявить узел, утративший экземпляр Cluster WMI.

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

Наиболее распространенной причиной утраты Cluswmi.mof узлом является устаревший способ решения проблем WMI. Для устранения неполадок WMI администраторы обычно используют команду Mofcomp.exe *.mof, позволяющую скомпилировать все файлы Managed Object Format (MOF) в репозиторий WMI. Однако дело в том, что существует довольно много файлов удаления для различных ролей и компонентов Windows, включая Cluster WMI. Поэтому файл Cluswmi.mof, устанавливаемый с помощью этой команды, впоследствии удаляется. Правильный способ восстановления репозитория WMI – с использованием команды Winmgmt.exe.

Ошибку легче предупредить

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

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

Листинг. Сценарий PowerShell для определения узлов с отсутствующим экземпляром Cluster WMI

Что такое AlwaysOn в SQL Server 2016

Группы доступности AlwaysOn - это мощнейшее средство в составе дистрибутива SQL, дающее возможность для администраторов баз данных, реализовать очень высокий уровень доступности (HA, high availability) с помощью кластерных технологий и не обязательно иметь общую файловую область (Shared Storage), уменьшить время восстановления (disaster recovery, DR) после аварии или сбоя оборудования. Данная технология, является в моем понимании заменой предыдущей технологии по зеркалированию базы данных (Database Mirroring). Если вы ее уже пробовали на практике, то знаете, что это не синхронная репликация логов транзакций и базы данных.

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

Модель защиты AlwaysOn

Для того, чтобы что-то развернуть и управлять этим, необходимо разобраться в функциональных возможностях и тонкостях технологии, давай посмотрим за счет чего обеспечивается высокая доступность и отказоустойчивость БД в SQL Server 2016:

Первое на что следует обратить внимание, это на уровень серверов (физическое железо + операционная система Windows Server 2012 R2), тут отказоустойчивость реализована, с помощью кластера WSFC (Windows Server Failover Cluster - отказоустойчивый кластер Windows). Именно данная технология мониторит состояние членов кластера и принимает решение о координации при отказе.
Далее следует уровень SQL Server 2016, тут отказоустойчивость реализовывается возможностями отказоустойчивых кластерных экземпляров AlwaysOn (их еще называют инстансами). Он разворачивается на нужном количестве узлов кластера Windows Server, и в случае недоступности одного из узлов, будет производится переключение.
Технология групп доступности AlwaysOn - реализуется на уровне баз данных, состоит из одной и более БД, которые будут переведены на дублирующий SQL Server в случае отказа.
Еще хочу отметить уровень, на котором подключаются клиенты, тут соединение возможно, как напрямую к экземпляру SQL Server, либо же используя virtual network name (VNN, виртуального сетевого имени), оно служит для скрытия уровней отказоустойчивого кластера Windows Server и групп доступности AlwaysOn, так же делает перенаправление запросов клиентов на нужные экземпляры SQL Server 2016 и реплику БД

Что входит в группы доступности AlwaysOn

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

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

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

Как я и писал выше, вам потребуется развернуть отказоустойчивый кластер Windows Server Failover Cluster на Windows Server 2012 R2 и выше. Ваши реплики будут располагаться на разных его узлах, но в рамках одного Windows Server Failover Cluster, в группах доступности отсутствует роль следящего.

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

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

Для выполнения нашей задачи вам потребуется редакция SQL Server 2016 Enterprise (подойдет и 2012, но так как он уже более старый, я использую следующие версии)
Наличие WSFC (Windows Server Failover Cluster), так как без отказоустойчивых хостов, вам делать нечего
Одинаковый SPN (кодировка на уровне SQL сервера)
Созданные отдельные записи для запуска служб SQL сервера

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

В моей реализации нет общих дисков для кворума и для сиквела, я буду использовать файловую шару для Quorum, а базы данных будут локальные. Давайте посмотрим основные требования к созданию кластера WSFC (Windows Server Failover Cluster):

Хостов нужно как минимум два, думаю это понятно
Если ваши хосты являются частью Active Directory, то создавать WSFC, необходимо из-под доменной учетной записи, в противном случае вы получите ошибку:

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

Все узлы кластеризации, должны иметь одинаковые операционные системы, в моем случае, это самая стабильная на текущий момент Windows Server 2012 R2.
Если вы используете общие диски с системы хранения данных или ISCSI диски с обычных серверов, то вам необходимо их подключить и разметить заранее.
Из необязательных рекомендаций Microsoft, для лучшего управления и применения групповой политики, требуется создать отдельное организационное подразделение (OU)
Убедитесь, что та учетная запись от имени которой вы будите создавать кластер, имеет права администратора на всех серверах, входящих в него.
Убедитесь, что у данной учетной записи, есть права на создание объектов компьютеров в Active Directory, если их нет, то либо нужно получить права, либо попросить системного администратора создать их заранее, об этом я расскажу ниже.

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

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

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

На окне "Выбор серверов или кластера" указываем DNS имена ваших серверов (если хотите, то можете и ip адреса добавить)

На следующем шаге будет два пункта:

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

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

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

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

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

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

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

Все я добился того, что остались не значительные предписания, щелкаем правым кликом по значку диспетчера и из контекстного меню выбираем пункт "Создать кластер"

Добавляем нужные узлы.

Задаем имя кластера в виде 15 символьного имени NETBIOS и статический Ip адрес и нажимаем далее

На данном шаге вы можете увидеть ошибку:

Найдена включенная учетная запись компьютера (объект-компьютера) для "имя кластера". Как правило, это означает, что указанное имя используется другим компьютером или является сетевым именем кластера. Если это не так, отключите или удалите учетную запись

Произошла ошибка при создании кластера. Узлы будут очищены. Пожалуйста подождите

Чаще всего это бывает из-за нехватки прав.

Развертывание отсоединенного от Active Directory кластера, не требующего создания объекта компьютер в домене
Либо при необходимости его внесения в домен, вам нужно создать требуемые условия, а именно подготовить объект имени кластера или CNO, чем мы и займемся ниже, это маленькое лирическое отступление, для тех людей у кого не хватает прав в AD, не выделенное заказчиком.

Подготовка объекта имени кластера или CNO

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

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

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

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

В Windows Server 2012 R2 есть возможность создать отсоединенный от Active Directory кластер. При этом ни CNO, ни VCO в AD DS не создается. Эта возможность предназначена для определенных типов развертывания кластера. Об этом ниже
Если планируется при собирании кластера, автоматическое создание объектов компьютера, то у пользователя выполняющего данную задачу, должны быть права на контейнер или OU в которой расположены участники будущего кластера. Эти права назначаются на этапе подготовки CNO.

Откройте оснастку Active Directory - пользователи и компьютеры. У вас в компании должна быть система именования учетных записей, и руководствуясь ей, вам необходимо заранее выбрать имя для кластера и имени учетно записи пользователя, от имени которого он будет создан, ей бы дадим сейчас права. Из рекомендаций Microsoft есть пожелание для кластерных объектов делать отдельную OU. Такие подразделения удобны для администрирования.

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

Создаем нужную OU, правым кликом по нужному месту в вашей иерархии AD.

Теперь создадим новый объект компьютера, это у нас будет (точка административного доступа CNO)

Указываем имя нашего кластера.

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

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

Теперь необходимо дать нужному пользователю права на организационную единицу. Щелкаем правым кликом по OU и выбираем свойства. Переходим на вкладку "Безопасность" и добавляем нужную группу безопасности или учетную запись пользователя.

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

Теперь, когда подготовительные требования выполнены, вы спокойно соберете кластер.

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

Далее выбираем свидетель кворума.

Говорим, что настройки будут лежать в общей сетевой папке "Настроить файловый ресурс-свидетель"

Задаем путь до сетевой папки.

Проверяем все настройки и подтверждаем их.

Если учетной записи не хватит прав на сетевую шару, то вы увидите ошибку:

Читайте также: