Локальный компьютер не является частью отказоустойчивого кластера Windows

Обновлено: 21.11.2024

При использовании мастера «Добавить среду» для добавления источника кластера SQL Server или целевой среды может появиться следующая ошибка:

Эта ошибка возникает, когда сценарий PowerShell «обнаружения», предназначенный для получения информации о кластере Windows, получает неожиданный результат. Обычно это происходит из-за проблем с разрешением DNS.

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

Устранение неполадок

Подтвердите, следует ли добавить среду в качестве кластера

Выбирать параметр «Кластер» при добавлении среды необходимо только в следующих случаях:

Среда – это dSource, использующий группы доступности AlwaysOn; или
Среда представляет собой целевой отказоустойчивый кластер SQL Server, который будет использоваться для размещения (виртуальных баз данных) VDB.

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

Проверьте согласованную конфигурацию DNS-сервера

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

Все узлы кластера
Прокси-сервер/сервер соединителя при добавлении исходной среды; и
Ядро Delphix

Вы можете проверить текущую конфигурацию DNS каждого сервера Windows через панель управления «Сетевые подключения» или из командной строки с помощью «ipconfig»:

DNS-сервер Delphix Engine можно проверить через интерфейс настройки Engine или через интерфейс командной строки.

Если серверы настроены на использование разных контроллеров домена, разных доменов или DNS-серверов, отличных от Windows, важно, чтобы ваши администраторы DNS или Active Directory вручную поддерживали соответствующие записи DNS.

Проверьте прямое и обратное разрешение DNS

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

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

Все узлы кластера
Прокси-сервер/сервер соединителя при добавлении исходной среды; и
The Delphix Engine (только прямой DNS)

Вы можете проверить разрешение DNS в Windows с помощью команды nslookup. В следующем примере мы используем DNS-сервер по умолчанию (dc.testing.local) для проверки прямого и обратного поиска DNS для кластера (mycluster.testing.local).

Если вы получаете сообщение об ошибке при поиске IP-адреса (например, "Несуществующий домен"), возможно, неправильно настроено обратное разрешение DNS:

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

Проверка наличия ресурса "IP-адрес кластера"

Delphix ищет IP-адрес кластера, используя имя по умолчанию для ресурса IP-адреса — «IP-адрес кластера».

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

Вы можете проверить IP-адрес кластера с помощью PowerShell или диспетчера отказоустойчивого кластера.

В графическом интерфейсе диспетчера кластера на любом узле кластера выберите ресурс кластера на левой панели и разверните основные ресурсы кластера:

Щелкните правой кнопкой мыши ресурс IP-адреса и выберите "Свойства".

В этом случае IP-адрес кластера имеет имя по умолчанию.

В PowerShell вы можете использовать команду Get-ClusterResource для получения той же информации:

Разрешение

Устранение ошибок DNS

Все изменения в конфигурации DNS в целевых средах и прокси-средах должны вноситься после консультации с вашей Active Directory или системными администраторами.

Попросите администратора домена убедиться, что:

Все узлы кластера и прокси-среда настроены на использование одного и того же DNS-сервера
Обратный DNS настроен для IP-адреса кластера

Изменение конфигурации кластера

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

В графическом интерфейсе диспетчера отказоустойчивого кластера на любом узле кластера разверните объект "Имя сервера" в кластере "Ресурсы ядра кластера":

Щелкните правой кнопкой мыши ресурс "IP-адрес" и выберите "Свойства":

Переименуйте этот объект обратно в значение по умолчанию ("IP-адрес кластера", как показано выше) и нажмите кнопку "ОК".

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

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

Дополнительная информация

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

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

В предыдущем совете по реализации зеркального отображения базы данных в SQL Server 2005 между доменами мы рассмотрели, как можно настроить зеркальное отображение базы данных для достижения локальной высокой доступности для баз данных SQL Server, которые не присоединены к домену Active Directory. Нам нужно обновить наши базы данных SQL Server 2008 R2 до окончания расширенной поддержки. Однако в нашей среде нет домена Active Directory. Как нам это сделать?

Решение

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

Несмотря на то, что группа доступности была жизнеспособной заменой зеркального отображения базы данных, было несколько блокирующих проблем, из-за которых клиенты не могли выполнить обновление. Первым было лицензирование. Группа доступности была доступна только в Enterprise Edition до SQL Server 2016. Если клиент использовал зеркальное отображение базы данных в Standard Edition, невозможно было выполнить обновление, не заплатив за дорогостоящие лицензии. Однако на самом деле это не имеет большого значения для крупных организаций, которые уже используют Enterprise Edition или на которые распространяется программа Software Assurance.

Вторым требованием было запуск отказоустойчивого кластера Windows Server (WSFC). Зеркальное отображение базы данных не требует внешних зависимостей, кроме службы DNS. Для группы доступности требуется WSFC. Это означает, что вам нужна команда высококвалифицированных инженеров и администраторов баз данных, ответственных за проектирование, внедрение и управление WSFC вне SQL Server.

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

Первоначальные попытки удалить зависимость WSFC от Active Directory

Предыдущие версии операционной системы Windows Server требовали Active Directory при развертывании WSFC: рядовые серверы/узлы должны быть присоединены к домену Active Directory — тому же домену Active Directory. Объект имени кластера (CNO) создается в Active Directory при создании WSFC. При создании отказоустойчивого кластерного экземпляра SQL Server (FCI) или имени прослушивателя группы доступности соответствующий объект виртуального компьютера (VCO) также создается в Active Directory.Для CNO и VCO также будут созданы соответствующие записи DNS. Это описано в этой статье Microsoft TechNet: Обзор учетных записей Active Directory, необходимых для отказоустойчивого кластера. Однако эта тесная интеграция между WSFC и Active Directory является основной причиной проблем при развертывании и управлении отказоустойчивым кластерным экземпляром (FCI) SQL Server или группой доступности.

В Windows Server 2012 R2 была предпринята попытка удалить зависимость WSFC от Active Directory, когда была введена функция, называемая кластером, отсоединенным от Active Directory. Это позволило администраторам развернуть WSFC без соответствующего CNO и, следовательно, без соответствующего VCO в Active Directory. Будут созданы только соответствующие записи DNS. Однако существует предостережение относительно реализации WSFC, отсоединенного от Active Directory: для этого по-прежнему требуется, чтобы рядовые серверы/узлы WSFC были присоединены к домену Active Directory.

Развертывание независимого от домена Active Directory WSFC

Предыдущий совет по пошаговой установке SQL Server 2016 на отказоустойчивый кластер Windows Server 2016. Часть 1 представил новую функцию в Windows Server 2016: отказоустойчивые кластеры Active Directory, независимые от домена. Это позволяет администраторам развертывать WSFC без домена Active Directory. Рядовые серверы/узлы WSFC могут быть частью рабочей группы, и эта конфигурация является жизнеспособным путем перехода от зеркального отображения базы данных к группе доступности.

Хотя вы также можете создать WSFC с рядовыми серверами/узлами в разных доменах или лесах Active Directory, целью этого совета является создание WSFC с рядовыми серверами/узлами, которые не присоединены к домену Active Directory, в рамках подготовки к развертывание группы доступности SQL Server.

Предпосылки

Оборудование

Требования к оборудованию для развертывания WSFC — независимо от того, присоединены ли рядовые серверы/узлы к домену Active Directory или нет — остаются прежними. Все серверы должны работать под управлением Windows Server 2016 и иметь логотип Windows Server 2016 Certified на базовом оборудовании. А поскольку WSFC будет использоваться специально для группы доступности SQL Server 2016, использование общего хранилища не требуется.

Аккаунты

Учетная запись, которую вы будете использовать для создания WSFC, должна быть членом локальной группы администраторов. То же самое было и в предыдущих версиях операционной системы Windows Server. Это позволяет выполнять установку и настройку WSFC. Хотя вы можете использовать встроенную локальную учетную запись администратора, для этой цели рекомендуется иметь выделенную локальную учетную запись пользователя. Однако, поскольку централизованной службы каталогов, такой как Active Directory, для управления учетными записями не существует, вы будете нести ответственность за ручное управление учетной записью на всех рядовых серверах/узлах в вашем WSFC.

Несколько вещей, которые вам нужно сделать:

Создайте локальную учетную запись пользователя на всех рядовых серверах/узлах в WSFC
Имя пользователя и пароль локальной учетной записи пользователя должны быть одинаковыми на всех рядовых серверах/узлах.
Добавьте локальную учетную запись пользователя в качестве члена локальной группы администраторов. В этом примере была создана локальная учетная запись пользователя clussvc. Это будет использоваться для создания и управления WSFC

Измените параметр реестра LocalAccountTokenFilterPolicy удаленного управления учетными записями пользователей (UAC). Этот параметр реестра влияет на то, как учетные данные администратора применяются для удаленного администрирования сервера. Поскольку вы используете локальную учетную запись пользователя, вы будете передавать учетные данные с одного из рядовых серверов/узлов в WSFC на другой для выполнения административных задач. Это необходимо сделать на всех рядовых серверах/узлах WSFC.

Откройте командную строку PowerShell с повышенными привилегиями и выполните приведенную ниже команду.

Поскольку WSFC будет развернут без CNO Active Directory, ему придется полагаться на DNS как для административных, так и для клиентских точек доступа. Это означает, что DNS потенциально может стать единой точкой отказа. Поговорите со своими администраторами DNS о надежности и отказоустойчивости вашей инфраструктуры DNS. В приведенном ниже примере сетевой адаптер, который будет использоваться для подключения клиентов, настроен на наличие как предпочтительного, так и альтернативного DNS-сервера. Это необходимо сделать на всех рядовых серверах/узлах WSFC.

Вам также необходимо настроить основной DNS-суффикс для всех рядовых серверов/узлов в WSFC. Основной DNS-суффикс используется при регистрации DNS-имен и разрешении DNS-имен.Это необходимо для того, чтобы все рядовые серверы/узлы в WSFC могли обращаться друг к другу через полное доменное имя (FQDN).

Чтобы настроить основной DNS-суффикс для сервера,

Откройте системные свойства сервера
На вкладке "Имя компьютера" нажмите кнопку "Изменить".

В диалоговом окне «Изменение имени компьютера/домена» проверьте принадлежность сервера к сети. В приведенном ниже примере сервер не является членом какого-либо домена Active Directory.

Нажимайте кнопку "ОК", пока все диалоговые окна не будут закрыты. Вам будет предложено перезагрузить сервер.

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

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

Выполните это для всех рядовых серверов/узлов в WSFC. В этом примере будут использоваться серверы WSFC2016-WG1, WSFC2016-WG2 и WSFC2016-WG3.

После добавления записей DNS выполните простой тест разрешения DNS с помощью команды PING.

В качестве альтернативы, если вы делаете это в целях тестирования, вы можете использовать локальный файл HOSTS для сопоставления IP-адреса с именем хоста.

Динамические обновления DNS

В зависимости от того, как настроены ваши DNS-серверы, вам необходимо поговорить со своими администраторами DNS о динамических обновлениях DNS. Клиентские компьютеры DNS могут использовать динамическое обновление для регистрации и динамического обновления своих записей ресурсов на DNS-сервере всякий раз, когда происходят изменения. Обычно это используется в сочетании с DHCP-сервером, поскольку IP-адреса компьютеров регулярно меняются.

Динамические обновления выполняются безопасным образом в зонах DNS, настроенных для интеграции с Active Directory. Это обычная конфигурация. Однако если у вас нет инфраструктуры Active Directory, конфигурация может немного отличаться. Ниже показан снимок экрана, на котором показано, как DNS-сервер Microsoft настроен для динамических обновлений.

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

ПРИМЕЧАНИЕ. Описанные выше задачи, связанные с DNS, относятся к DNS-серверам Microsoft. Процесс будет другим, если в вашей сети работает DNS-сервер BIND.

В следующем совете из этой серии вы пройдете процесс создания WSFC и настроите параметры кворума кластера.

Это десятая статья в серии, посвященной группам доступности Always On SQL Server.

Введение

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

В Windows Server 2016 представлена новая концепция, известная как независимые от домена отказоустойчивые кластеры Windows.В этой статье мы рассмотрим эту новую концепцию и посмотрим, как мы можем использовать ее для настройки группы Always On Availability SQL Server.

Предпосылки

Вы должны понимать концепцию традиционной группы доступности Always On SQL Server. Вы можете использовать статьи (см. ToC внизу), чтобы подготовить свою AG без предварительных знаний.
У вас должен быть контроллер DNS для предоставления статических IP-адресов участвующим узлам.
Создайте две виртуальные машины с помощью Oracle VirtualBox и установите на них Windows Server 2016

Обзор независимых от домена отказоустойчивых кластеров Windows для SQL Server Always On Availability Groups

Как объяснялось выше, в традиционном отказоустойчивом кластере для SQL Server Always On все участвующие узлы должны быть членами домена.

В Windows Server 2016 мы также можем создавать независимые от домена отказоустойчивые кластеры. Давайте создадим кластер в следующем разделе.

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

Этапы по настройке независимого от домена отказоустойчивого кластера для групп доступности SQL Server Always On

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

Шаг 1. Включите функцию отказоустойчивого кластера в SQLAG1

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

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

Шаг 2. Включите функцию отказоустойчивого кластера в SQLAG2

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

Шаг 3. Назначьте основной DNS-суффикс для узла SQLAG1

Традиционный отказоустойчивый кластер создает объект имени кластера (CNO) в активном каталоге после создания кластера. Точно так же он также создает объект виртуального компьютера (VCO) для прослушивателя в SQL Server Always On.

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

Чтобы настроить DNS-суффикс, откройте свойства системы и нажмите кнопку Изменить на странице компьютера.

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

Нажмите "ОК" и перезапустите систему, чтобы изменения вступили в силу.

Шаг 4. Назначьте основной DNS-суффикс для узла SQLAG2

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

Шаг 5. Назначьте статический IP-адрес узлам SQLAG1 и SQLAG2

Откройте свойства версии интернет-протокола ( TCP IPv4) и назначьте статический IP-адрес вместе с . IP-адрес DNS в узлах SQLAG1 и SQLAG2 в группах доступности Always On SQL Server.

Вы можете проверить IP-адрес с помощью команды IPCONFIG в командной строке Windows.

Аналогичным образом проверьте IP-адрес узла SQLAG2. Он должен отражать статический IP-адрес, который мы настроили выше.

Шаг 6. Обновите файл хоста на узлах SQLAG1 и SQLAG2

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

Откройте файл хоста, перейдя в папку C:\Windows\System32\Drives\etc\hosts.

Введите полное доменное имя сервера с его IP-адресом, как показано ниже.

Вы получаете ответ ping, используя полное доменное имя сервера.

Шаг 7. Создайте локального пользователя на обоих узлах для управления отказоустойчивым кластером в группах доступности SQL Server Always On

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

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

Добавьте эту учетную запись в группу администраторов на узлах SQLAG1 и SQLAG2.

Шаг 8. Настройте параметр реестра LocalAccountTokenFilterPolicy

Нам нужно изменить параметр реестра LocalAccountTokenFilterPolicy для удаленного управления учетными записями пользователей (UAC). Этот параметр реестра управляет учетными данными администратора для удаленного администрирования сервера. Этот параметр является обязательным, поскольку мы используем локальную учетную запись пользователя в отказоустойчивом кластере.

Откройте Windows PowerShell администратора и выполните следующую команду как для SQLAG1, так и для SQLAG2.

> New-ItemProperty -Path HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System -Name LocalAccountTokenFilterPolicy -Value 1

После выполнения этой команды PowerShell вы получите следующий вывод.

Шаг 9. Настройте независимый от домена отказоустойчивый кластер Windows

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

Нажмите «Создать кластер» и добавьте оба узла SQLAG1 и SQLAG2 в список серверов.

Нажмите "Далее" и нажмите "Да", чтобы настроить тесты проверки кластера.

Нажмите «Выполнить все тесты» (рекомендуется).

Показывает список проверочных тестов кластера.

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

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

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

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

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

Откройте диспетчер отказоустойчивого кластера и запишите хост-сервер, сеть, субъекты.

Нажмите на узлы. Вы должны увидеть в списке узлы SQLAG1 и SQLAG2.

Заключение

В этой статье мы рассмотрим концепцию отказоустойчивого кластера Windows, независимого от домена. Позже мы настроили отказоустойчивый кластер, используя основной DNS-суффикс. В следующей статье мы настроим группу доступности SQL Server Always On поверх этого независимого от домена отказоустойчивого кластера Windows.

В этой статье представлен краткий обзор того, как создать отказоустойчивый кластер Microsoft Windows (WFC) с Windows Server 2019 или 2016. В результате получится двухузловой кластер с одним общим диском и вычислительным ресурсом кластера (компьютерный объект в Активный каталог).

Подготовка

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

Два компьютера с Windows 2019 с установленными последними обновлениями. Машины имеют как минимум два сетевых интерфейса: один для рабочего трафика, другой для трафика кластера. В моем примере есть три сетевых интерфейса (один дополнительный для трафика iSCSI). Я предпочитаю статические IP-адреса, но вы также можете использовать DHCP.

Присоедините оба сервера к своему домену Microsoft Active Directory и убедитесь, что оба сервера видят общее устройство хранения, доступное в управлении дисками. Пока не подключайте диск к сети.

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

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

После успешной установки диспетчер отказоустойчивого кластера появится в меню "Пуск" в инструментах администрирования Windows.

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

После обновления управления дисками вы увидите что-то похожее на это:

Управление дисками сервера 1 (статус диска в сети)

Управление дисками сервера 2 (статус диска отключен)

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

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

Выберите два сервера для проверки.

Выполнить все тесты. Также есть описание решений, которые поддерживает Microsoft.

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

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

Если вы решите создать кластер, нажав «Создать кластер» в диспетчере отказоустойчивого кластера, вам снова будет предложено выбрать узлы кластера. Если вы используете флажок Создать кластер сейчас, используя проверенные узлы в мастере проверки кластера, вы пропустите этот шаг. Следующим важным шагом является создание точки доступа для администрирования кластера. Это будет виртуальный объект, с которым клиенты будут взаимодействовать позже. Это объект компьютера в Active Directory.

Мастер запрашивает конфигурацию имени кластера и IP-адреса.

В качестве последнего шага подтвердите все и дождитесь создания кластера.

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

В результате вы увидите новый объект компьютера Active Directory с именем WFC2019.

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

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

Вы можете увидеть результат в Диспетчере отказоустойчивого кластера в разделах Узлы и хранилище > Диски.

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

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

В настоящее время кластер использует диск, настроенный ранее в качестве диска-свидетеля. Альтернативными вариантами являются файловый ресурс-свидетель или учетная запись хранения Azure в качестве свидетеля. В этом примере мы будем использовать файловый ресурс-свидетель. На веб-сайте Microsoft есть пошаговое руководство для облачного свидетеля. Я всегда рекомендую настроить свидетеля кворума для правильной работы. Таким образом, последний вариант не подходит для производства.

Просто укажите путь и завершите работу мастера.

После этого общий диск доступен для хранения данных.

Поздравляем, вы настроили отказоустойчивый кластер Microsoft с одним общим диском.

Дальнейшие шаги и резервное копирование

Одним из следующих шагов будет добавление роли в кластер, что выходит за рамки этой статьи. Как только кластер содержит данные, также пора подумать о резервном копировании кластера. Veeam Agent для Microsoft Windows может создавать резервные копии отказоустойчивых кластеров Windows с общими дисками. Мы также рекомендуем делать резервные копии «всей системы» кластера. Это также создает резервные копии операционных систем членов кластера. Это помогает ускорить восстановление вышедшего из строя узла кластера, так как вам не нужно искать драйверы и т. д. в случае восстановления.

Ханнес Каспарик
Ханнес Каспарик работает в ИТ-бизнесе с 2004 года. Он управлял Windows, Linux, системами хранения, брандмауэрами и консультировал по решениям для центров обработки данных. Сегодня Ханнес является членом группы управления продуктами Veeam.

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