Назад | Перейти на главную страницу

Невозможно переместить основной ресурс кластера

Я пытаюсь переместить основные ресурсы кластера с 1 узла на другой в 4-узловом WSFC (это все виртуальные машины, работающие на Compute Engine в Google Cloud, Windows Server 2012 R2, каждая в другой подсети). я бегу

Move-ClusterGroup -Name "Cluster Group" -Node mynode

И получаю ошибку:

Move-ClusterGroup: произошла ошибка при перемещении кластерной роли «Группа кластеров». Операция завершилась неудачно, потому что либо указанный узел кластера не является владельцем группы, либо узел не является возможным владельцем группы.

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

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

Ресурс кластера «IP-адрес кластера [IP-адрес текущего хоста]» типа «IP-адрес» в кластерной роли «Группа кластера» завершился неудачно.

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

Поэтому я проверил ресурсы ip для ресурсов ядра кластера и увидел, что у каждого из них есть возможный владелец всех 4 узлов, несмотря на то, что они находятся в неправильных подсетях. Похоже, он пытался поднять текущий IP-адрес на целевом хосте, что, конечно, не сработало. Я удалил 3 ips в "неправильной" подсети из каждого ресурса кластера и с тех пор получаю первое сообщение об ошибке, которое я здесь включил.

Я побежалGet-ClusterGroup -Name "Cluster Group" | Get-ClusterOwnerNode который изначально возвращал {} для OwnerNodes. С тех пор я попытался добавить текущего владельца + узел, на который я пытаюсь перейти, используя Set-ClusterOwnerNode и теперь я вижу двух, которых я ожидал бы, как возможных владельцев, но это не имело значения для переезда.

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

Я провел проверку кластера, и она не дает ничего, что я мог бы считать причиной для этого. Есть предупреждения против: различных ресурсов ядра IP-кластера, потому что они больше не могут принадлежать каждому узлу, настроек HostRecordTTL и RegisterAllIP, неподписанных драйверов, некоторых различий в программном обеспечении на 2 узлах (только обновления, которые были применены к одному I ' м пытаюсь переехать).

Ну вроде исправил:

Я добавил все узлы обратно к возможному владельцу всех IP-адресов на основе ошибки из Move-ClusterGroup командлет. Пытаясь переместиться снова, я получил начальную ошибку, пытаясь поднять IP-адрес подсети1 на узле в другой подсети. На этот раз я повторил аварийное переключение и превысил «максимальное количество перезапусков за указанный период», поэтому вместо того, чтобы просто вернуться в режим онлайн на узле подсети1, группа кластеров перешла в автономный режим. Как только это произошло, я вручную подключил IP-адрес подсети 2 через графический интерфейс. Это сработало и вывело кластерную группу на предполагаемый узел.

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

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