Ошибка 81 failoverclustering client

Error 81 failoverclustering client

Вопрос

Running Windows 10 Pro v1809. Enabling Hyper-V produces a nonstop (at least once per minute) flow of Error «FailoverClustering-Client Event 81». As an experiment, stopping the Hyper-V Virtual Machine Management service stops said nonstop flow.

‘K, I’ll get into the Failover Management Console and disable the root of the problem. Except I cannot enable _any_ of the RSAT elements, as _none_ of them are present under Turn Windows Features On and Off.

So it appears that Hyper-V produces the Error because it cannot find failover clustering … which is not installed under Windows 10 Pro v1809 … and the management tools needed to «turn the stuff off» are _also_ not available. Hahaha.

Log Name: System
Source: Microsoft-Windows-FailoverClustering-Client
Date: 2/28/2019 7:53:41 AM
Event ID: 81
Task Category: None
Level: Error
Keywords: (1024)
User: SYSTEM
Computer: xxxxxxxxxx
Description:
LogExtendedErrorInformation (974): Extended RPC error information:
ProcessID is 2524
System time is: 50903/468/31223 490:0:1408:13807
Generating component is 2
Status is 1753
Detection location is 501
Flags is 0
NumberOfParameters is 4
Unicode string: ncacn_ip_tcp
Unicode string: localhost
Long val: -1182943054
Long val: 382312662

Все ответы

Thanks for posting in our forum!

1. Your description is not clear. Have you installed a virtual machine in Hyper-V? If so, what is your VM version?

2. “ Failover cluster management Console ” What does this mean?

3. As I understand, your current situation is that your Hyper-V report failover cluster Event id 81, buy you did not install Failover Cluster role, if I misunderstood, please let me know.

4. Whether try to reinstall Hyper-V?

5. Has the failover cluster role been installed before?

Please remember to mark the replies as answers if they help.
If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

Just want to confirm the current situations.

Please feel free to let us know if you need further assistance.

Please remember to mark the replies as answers if they help.
If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

Thanks for the reply. I am running Windows 10 _PRO_ v1809. I am _not_ running Windows Server, which makes the error message about FailoverClustering that much more out of place.

As noted, in Event Viewer I see » Error «FailoverClustering-Client Event 81» at least once per minute. And these errors appear even when I am _not_ running a Hyper-V client.

I know that Hyper-V as implemented in Windows 10 _PRO_ shares a great deal with Hyper-V as implemented in Windows Server . but there are fundamental differences as well. I believe what I am seeing here is a bug caused by the different implementation of Hyper-V in Windows 10 _PRO_.

I doubt that they would do anything if you target a Windows 10 host.

Have you ever used this machine to remotely access a node in a cluster?

Please remember to mark the replies as answers if they help.
If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

Thanks for your reply!

Can you try to reinstall Hyper-V, and can you upload the logs as pictures?

Did the machine make any changes before this problem occurred?

Please remember to mark the replies as answers if they help.
If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

— Uninstalled Hyper-V, rebooted
— Re-installed Hyper-V, rebooted
[note that this is done via the Control Panel, Turn Windows Features On and Off]

Errors occur nonstop, as before. Here’s a screen capture of Event Viewer. Worth noting that at this point, there are _NO_ Hyper-V clients running. The screen capture reflects activity immediately after the reboot.

Oops, I cannot upload an image because my account is not yet verified?

As described at the top of this thread, 3-6 times per minute I get an Error » FailoverClustering-Client Event ID 81″. Event description is below .

LogExtendedErrorInformation (974): Extended RPC error information:
ProcessID is 7348
System time is: 45687/468/23422 361:0:4880:5586
Generating component is 2
Status is 1753
Detection location is 501
Flags is 0
NumberOfParameters is 4
Unicode string: ncacn_ip_tcp
Unicode string: localhost
Long val: -1182943054
Long val: 382312662

Thanks for your reply!

Does Win10 join the domain? If so, please try to exit to see if the problem still exists.

To be honest, your question is strange. I haven’t found any information about Failover Clustering-Client Event ID 81.

Please remember to mark the replies as answers if they help.
If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

No, this system does not join a domain. And yes, this is mighty MIGHTY strange.

Another (not too surprising) finding: if I STOP the «Hyper-V Virtual Machine Management» service, the nonstop errors halt. That disables Hyper-V, of course, so it isn’t much of help.

Thanks for your quick reply!

I just discussed it with my colleagues. We wonder if you installed Failover Cluster manager feature?

And maybe you can see it:

If you checked this feature, try to unchecked and see if the problem still exists.

No, I’ve never installed anything to do with Failover Cluster Manager. Indeed, it is not even an option … as I am running Windows 10 _PRO_ and not Windows Server.

Thanks for the continued help on this strange situation. I sincerely believe this is a _bug_ that was introduced in one of the bi-annual Windows updates. Hyper-V running with Windows 10 _PRO_ is an unusual ‘hybrid’ and something about its unusual nature has gone awry.

You are welcome!

Have you seen the link I gave you?

Maybe I made a mistake just now. I suspect that your problem is caused by RSAT.

Please try to disable this feature if you install it

I always hope to do my best to solve every problem and help those who encounter problems.

Thanks again for your quickly reply!

Please try to disable this feature.

Please remember to mark the replies as answers if they help.
If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

Ah, sorry for the mixup: _no_ I do not have RSAT installed.

Under Windows 10 Pro v1809, by the way, RSAT is no longer installed via Control Panel > Programs > Turn Windows Features On and Off. It is now available via Windows Settings > Apps > Manage Optional Features: there I _could_ install «RSAT: Failover Clustering Tools» … but I do _not_ have any of the RSAT tools installed.

It seems really strange. I will continue to look for some possible causes of this problem.

I will contact you as soon as possible.

Please remember to mark the replies as answers if they help.
If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

I have the same issue, my started in february. I have also Windows 10 pro, I’m using hyper-v, nothing like FailoverClustering is not installed. This is my personal PC, nothing with domain etc.

We had the same issue on a Hyper-V virtual Exchange 2019 Server. The problem started after a Microsoft update (sorry, I don’t remember which one). Anyhow, it turns out that the update seems to have installed a new feature to the server tools.

Go to your Server Manager for the exchange server —> choose to manage —> Remove roles.

Look for: Remote Server Administration Tools —> Feature Administration Tools —> Failover clustering Tools

In our situation, three of the for boxes in the feature were checked (we didn’t do it). Unchecking and restarting eliminated the errors, which were filling up our event logs. Did this three days ago and no problems since.

I am Daniel and wish you all the best!

I just saw a link saying that if you install Acronis Backup Cloud backup software, you may have Event 81 error, so please check whether you have installed this backup software or some other three-party backup software.

Please remember to mark the replies as answers if they help.
If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

• Предложено в качестве ответа Danie1zhou Microsoft contingent staff 24 апреля 2019 г. 7:23

I am Daniel and wish you all the best!

I just saw a link saying that if you install Acronis Backup Cloud backup software, you may have Event 81 error, so please check whether you have installed this backup software or some other three-party backup software.

Please remember to mark the replies as answers if they help.
If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

This worked for me. I uninstalled the Acronis agent and the error stopped.

My Windows is 1903, recently upgraded from 1803.

Please help me mark the useful reply as an answer, thank you in advance!

Please remember to mark the replies as answers if they help.
If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

NUMTO talked about checking into to see if you have ACRONIS backup software. I am having similar issues with Server 2019 with all the latest updates. I am using Backup Exec, there is an option to check the cloud services. I unchecked it. It seems to have calmed the server down form those cluster errors. Also, I verified this by removing (uninstalling) Backup Exec. When I had it uninstalled from the server, I didn’t get any of those Cluster errors. The minute I reinstalled, a short time later I kept getting those, so perhaps you may have some piece or a backup software (Other software) that may have a feature that involves the cloud, or clustering.

Thanks for the info!

I have Backup Exec on Server 2019 also and this save me a bunch of time tracking down the error. Could you point me to where the option to check the cloud services is?

We are having a few other confirmed Backup Exec issues with 2019 including a BSOD that they are not willing to own yet. Don’t update any tape drive firmware with BE installed on 2019 at this time Uninstall BE first.

I’m not sure how they say it is 2019 compatible at this time?

I have the latest Backup Exec 20.5 running on Server 2012 R2 backing up a Server 2019 box using an agent. The 2019 server doesn’t have the Failover Clustering role or any tools installed but does have the Hyper-V role installed. I get these errors every week on the 2019 server event logs during the backup window. I opened a ticket with Veritas who remotely connected and viewed the issue but basically ignored the problem saying it was a Microsoft issue and told me to contact Microsoft. I mentioned Acronis had a similar problem and they fixed it. I also mentioned this thread and the cloud option mentioned but was told that since we are not using cloud storage then no cloud options are available to configure.

If I don’t run the backup, then I don’t get those errors. If I uninstall the agent I also don’t get those errors but of course can’t backup the server. I am backing up another Server 2019 box with Backup Exec that doesn’t have the Hyper-V role on it and it is fine. The Software Compatibility List for BE shows Server 2019 is supported since version 20.3. I have 2016 boxes with Hyper-V installed that don’t have an issue. I may need to build another 2019 server with the Hyper-V role on it to see if that’s the cause. Not sure what else to check or where to go from here besides ignoring the errors.

Did you by any chance find a solution to your problem? I have the same error on my server 2019 that have BE 20.5 installed on it. My BE 20.5 server dont have the Hyper-v role on it but each time a backup job runs the event 81 get logged. I have different server 2019 with Hyper-v role on it and we installed the BE agent on it and each time we backup the VM on this machine the even 81 get logged.

Источник

В статье «Диагностика проблем кластеров Windows Server 2008 R2», опубликованной в Windows IT Pro/RE № 10 за 2012 год, говорилось об устранении неполадок кластеров с обходом отказов. В частности, приводились рекомендации по извлечению информации, необходимой для диагностики проблем. На этот раз я хочу рассказать о расширенных средствах поиска и устранения неисправностей кластеров с обходом отказов в Windows Server 2012 и об их наиболее эффективном применении.

Знакомство с новыми каналами событий

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

Экран 1. Каналы событий кластеров с?обходом отказов в?Server 2012

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

* FailoverClustering

— Diagnostic. Это главный журнал, генерируемый всякий раз при запуске службы кластеров. Если функция ведения журнала выклю-чена, события могут выводиться в окно программы просмотра со-бытий Event Viewer. Данные журнала можно преобразовать в тек-стовый файл.

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

— Performance-CSV. Этот канал используется для сбора информа-ции, касающейся функционирования общих томов кластера (CSV).

* FailoverClustering-Client

— Diagnostic. Этот канал используется для сбора данных журнала трассировки API Cluster. Данные журнала могут быть полезны для выявления причин ошибок при выполнении действий по созданию кластера (Create Cluster) и добавления узла в кластер (Add Node Cluster).

* FailoverClustering-CsvFlt (новый канал в Server 2012)

— Diagnostic. По этому каналу осуществляется сбор данных жур-нала трассировки драйвера фильтра CSV (CsvFlt.sys), установ-ленного только на узле координатора для CSV. Данные журнала позволяют выявить причины сбоев операций с метаданными и пе-ренаправленных операций ввода/вывода.

* FailoverClustering-CsvFs (новый канал в Server 2012)

— Diagnostic. Этот канал используется для сбора данных журнала трассировки драйвера файловой системы CSV (CsvFs.sys), ус-тановленного на всех узлах кластера. Данные журнала позволяют диагностировать проблемы прямых операций ввода/вывода.

* FailoverClustering-Manager

— Admin. На этом канале регистрируются ошибки, связанные с диалоговыми окнами и всплывающими предупреждениями, отобра-жаемыми в окне диспетчера кластеров.

* FailoverClustering-WMIProvider

— Admin. Этот канал используется для регистрации событий, связанных с поставщиком WMI кластеров с обходом отказов.

— Diagnostic. Журнал трассировки, связанный с поставщиком WMI кластера, который можно использовать для диагностики ошибок сценариев инструментария управления Windows (WMI) или прило-жений Microsoft System Center.

Использование канала FailoverClustering-Client/Diagnostic

При создании кластеров и присоединении узлов к кластеру нередко возникают проблемы, поэтому важно знать, как применять журнал FailoverClustering-Client/Diagnostic. По умолчанию этот канал выключен, и данные не регистрируются. Для включения канала щелкните на нем правой кнопкой и выберите Enable Log. После этого начинается сбор информации, относящейся к операциям присоединения и создания.

Предположим, что при включенном канале Diagnostic возникла проблема при создании кластера. Для просмотра собранных данных щелкните на канале правой кнопкой и выберите Disable Log. В журнале FailoverClustering-Client/Diagnostic можно увидеть следующее:

Event ID: 2
Level: Error
Description: CreateCluster (1883): Create cluster failed
with exception. Error = 8202, msg: Failed to create
cluster name CLUSTER on DC \DC.CONTOSO.COM. Error 8202.
Event ID: 2
Level: Error
Description: CreateClusterNameCOIfNotExists (6879): Failed
to create computer object CLUSTER on DC \DC.CONTOSO.COM
with OU ou=Clusters,dc=contoso,dc=com. Error 8202.

Для просмотра значения кода состояния ошибки (8202) восполь-зуемся командой Net.exe:

NET HELPMSG 8202

Команда возвращает сообщение The specified directory service attribute or value does not exist («Указанное значение или атрибут службы каталогов не существует»). Новые возможности кластеров с обходом отказов Server 2012 предполагают, что кластер создается в том же подразделении (OU), что и узлы. Для создания имени кластера активный пользователь должен иметь, как минимум, разрешения Read и Create Computer Objects. Если пользователь не обладает такими правами, имя кластера не соз-дается, и выдается ошибка такого типа.

Теперь предположим, что ошибка возникает при добавлении узла в существующий кластер. При просмотре журнала FailoverClustering-Client/Diagnostic видим следующее:

Event ID: 56
Level: Warning
Description: AsyncNotificationCallback (1463): ApiGetNotify
on hNotify=0x0000000021EBCDC0 returns 1 with rpc_error 0
Event ID: 2
Level: Error
Description: SCMStateNotify (837): Repost of
NotifyServiceStatusChange failed for node
'NodeX': status = 1168

Описание первого события указывает на ошибку вызова удаленной процедуры (RPC). В описании второго события содержится код состояния 1168. Чтобы узнать значение кода, снова воспользуемся командой Net.exe:

NET HELPMSG 1168

На этот раз команда возвращает сообщение Element not found («Элемент не найден»). При попытке присоединения узла кластеру необходимо установить соединение RPC с присоединяемым узлом. В данном случае кластер не находит узел.

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

Новые тесты мастера проверки настроек

Полезным инструментом диагностики ошибок является мастер про-верки настроек Validate a Configuration Wizard, который в Server 2012 дополнен новыми тестами кластеризации. В приведенном ниже списке новые тесты выделены жирным шрифтом.

* Hyper-V (только если установлена роль Hyper-V):

— List Hyper-V Virtual Machine Information;

— List Information About Servers Running Hyper-V;

— Validate Compatibility of Virtual Fibre Channel SANs for Hyper-V;

— Validate Firewall Rules for Hyper-V Replica Are Enabled;

— Validate Hyper-V Integration Services Version;

— Validate Hyper-V Memory Resource Pool Compatibility;

— Validate Hyper-V Network Resource Pool and Virtual Switch Compatibility;

— Validate Hyper-V Processor Pool Compatibility;

— Validate Hyper-V Role Installed;

— Validate Hyper-V Storage Resource Pool Compatibility;

— Validate Hyper-V Virtual Machine Network Configuration;

— Validate Hyper-V Virtual Machine Storage Configuration;

— Validate Matching Processor Manufacturers;

— Validate Network Listeners Are Running;

— Validate Replica Server Settings.

* Cluster Configuration (только для рабочего кластера):

— List Cluster Core Groups;

— List Cluster Network Information;

— List Cluster Resources;

— List Cluster Volumes;

— List Clustered Roles;

— Validate Quorum Configuration;

— Validate Resource Status;

— Validate Service Principal Name;

— Validate Volume Consistency;

* Inventory:

— Storage

—List Fibre Channel Host Bus Adapters

—List iSCSI Host Bus Adapters

—List SAS Host Bus Adapters

— System

—List BIOS Information

—List Environment Variables

—List Memory Information

—List Operating System Information

—List Plug and Play Devices

—List Running Processes

—List Services Information

—List Software Updates

—List System Drivers

—List System Information

—List Unsigned Drivers

* Network:

— List Network Binding Order;

— Validate Cluster Network Configuration;

— Validate IP Configuration;

— Validate Network Communications;

— Validate Windows Firewall Configuration.

* Storage:

— List Disks

— List Potential Cluster Disks

— Validate CSV Network Bindings

— Validate CSV Settings

— Validate Disk Access Latency

— Validate Disk Arbitration

— Validate Disk Failover

— Validate File System

— Validate Microsoft MPIO-Based Disks

— Validate Multiple Arbitration

— Validate SCSI device Vital Product Data (VPD)

— Validate SCSI-3 Persistent Reservation

— Validate Simultaneous Failover

— Validate Storage Spaces Persistent Reservation

* System Configuration:

— Validate Active Directory Configuration

— Validate All Drivers Signed

— Validate Memory Dump Settings

— Validate Operating System Edition

— Validate Operating System Installation Option

— Validate Operating System Version

— Validate Required Services

— Validate Same Processor Architecture

— Validate Service Pack Levels

— Validate Software Update Levels

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

Использование мастера проверки настроек

Рассмотрим применение мастера проверки настроек Validate a Configuration Wizard. Для предыдущего примера с проблемой при добавлении узла предположим, что IP-адрес на DNS правильный, и соединение между узлами за пределами кластера может быть установлено. В этом случае можно запустить мастер проверки настроек.

При работе мастера возникает ошибка выполнения теста Net-work/Validate Windows Firewall Configuration. В ходе этого теста при анализе параметров брандмауэра Windows выясняется, что порт 3343, используемый кластером, не включен. Если порт отключен, вся идущая через него связь блокируется, и канал Diagnostic выдает ошибки.

Новый параметр команды Get-ClusterLog

Команда Get-ClusterLog из инструментария PowerShell позволяет преобразовать регистрируемые в журнале (например, Failover-Clustering/Diagnostics) события в текстовый файл. Текстовый файл именуется Cluster.log и помещается в папку C:WindowsClusterReports. По умолчанию, при выполнении команды для каждого узла создается свой файл Cluster.log. Изменить это можно с помощью перечисленных ниже параметров, например, UseLocalTime.

• -Cluster – имя кластера, к которому применяется команда. Этот параметр позволяет указать удаленный кластер. Если параметр опущен, то команда применяется к текущему кластеру.
• -Node – имя узла, к которому применяется команда. Эта команда используется, если файл Cluster.log генерируется только для конкретного узла.
• * -Destination – папка, в которую копируются файлы Cluster.log. При использовании этого параметра PowerShell не только создает файл Cluster.log в папке C:WindowsClusterReports для каждого узла, но и копирует все файлы журнала в заданную папку. Имя узла составляет часть имени файла, копируемого в целевую папку (например, Node1_Cluster.log, Node2_Cluster.log), что позволяет легко идентифицировать журналы.
• -TimeSpan. Этот параметр используется для создания журнала за заданный интервал времени в минутах (например, 5), что по-зволяет значительно уменьшить анализируемый файл. Этот параметр можно использовать при воспроизведении ошибки, то есть воспроизвести предполагаемую ошибку и сгенерировать журнал за последние 5 минут, чтобы проверить предположение.
• -UseLocalTime. Как уже говорилось, это новый параметр в Server 2012. Вся информация в кластере регистрируется во вре-менной зоне GMT. Например, в часовом поясе GMT-5, когда местное время составит 13:00 (1:00 p.m.), в журнале Cluster.log по умолчанию будет указано время 18:00 (6:00 p.m.). Это облегчает сопоставление времени, возвращаемого командой Get-ClusterLog, со временем в журнале Event Log.

Освоив создание журналов Cluster.log, следует научиться из-влекать из них нужную информацию.

Анализ файлов Cluster.log

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

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

00000bb8.000001d4::2013/05/15-01:13:24.852
INFO [RES] IP Address:
Online: Opened object handle for netinterface
353c85ee-7ea7-4b2a-927d-1538dffcdecd

Разобьем запись на отдельные фрагменты и поясним их смысл.

00000bb8 – шестнадцатеричное представление идентификатора процесса. Обычно процессом является Resource Host System (RHS). Сортируя или применяя поиск строк, включающих этот ID, можно узнать, какие ресурсы использует процесс. Это удобно в случае отладки дампа RHS при наличии нескольких файлов. Каждый дамп идентифицируется по ID, поэтому знание идентификатора гарантирует работу именно с нужным дампом процесса. Если есть полный дамп памяти, то в нем представлены несколько процессов RHS, каждый из которых идентифицируется по ID.

000001d4 – идентификатор цепочки в шестнадцатеричном пред-ставлении. Сортируя или применяя поиск строк, включающих этот ID, можно отследить действия цепочки. Используя этот ID для поиска, можно перейти прямо к нужной цепочке – например, при отладке процесса RHS, имеющего 100 цепочек.

2013/05/15-01:13:24.852 – дата и время в зоне GMT (если журнал генерируется без использования параметра UseLocalTime). В часовом поясе GMT-5 данное время соответствует местному времени 14 мая 2013 г., 8:13 p.m. Время детализируется с точностью до миллисекунд.

INFO – уровень записи: INFO (информация), WARN (предупреждение), ERR (ошибка) или DBG (отладка). Есть и другие, но в большинстве случаев используются именно эти уровни. Строка с ERR обычно означает проблему с ресурсом. Открыв файл Cluster.log, можно выполнить поиск по конкретному уровню, чтобы быстрее локализовать проблемный участок.

[RES] IP Address – тип ресурса. В журнале каждый ресурс иден-тифицируется по типу. Располагая этой информацией, можно быстро отследить проблемный подключающийся ресурс, если в одно и то же время подключаются ресурсы разных типов.

. Это – фактический ресурс, отображаемый в диспетчере кластеров.

Online: Opened object handle for netinterface 353c85ee-7ea7-4b2a-927d-1538dffcdecd – описание того, что происходит с ре-сурсом. В данном случае ресурс открывает дескриптор доступа к драйверу сетевого адаптера для привязки к нему IP-адреса. Если здесь возникает сбой, то это может указывать на проблему с драйвером сетевого адаптера, либо на неисправность самого се-тевого адаптера. Следующим шагом будет анализ записей в журнале системных событий и поиск событий, относящихся к сети (сбой сети или сетевого адаптера). Выявить причину проблемы помогают описания. Особенно полезны описания последних действий перед наступлением отказа.

Поиск в файлах Cluster.log

Анализируя файлы Cluster.log, стоит задействовать поиск по ключевым словам. В таблице приведен список ключевых слов, ко-торые я использую для поиска ресурсов.

Ключевые слова следует вводить в точности так, как они ото-бражены, то есть с двумя дефисами и знаком «больше» (—>) и без пробелов.

Ключевые слова также позволяют быстро определить, сколько времени требуется ресурсу для отключения или подключения. Предположим, например, что подключение некоторой группы занимает больше времени, чем обычно. В этом случае сначала можно применить поиск по —>OfflinePending, а затем по —>Offline для всех ресурсов группы. Другой вариант: сначала поиск по —>OnlinePending, а затем по —>Online. Для каждого ресурса суммируем значения времени, чтобы узнать, сколько времени ему требуется на подключение. Проделав это для каждого ресурса, сравним суммарные значения, чтобы узнать, какому ресурсу тре-буется наибольшее время. Затем можно проанализировать записи в журнале Cluster.log, чтобы определить причину. Например, если подключение группы занимает в целом 30 секунд на одном узле и три минуты на другом, то следует сгенерировать файлы Cluster.log для обоих узлов и сравнить их.

Для групп можно использовать те же ключевые слова, но за сим-волом «больше» должен следовать пробел. Например, при анализе отключения сначала используется —> OfflinePending, а затем —> Offline. Различается еще лишь запись при анализе отказа: для группы используется —> Failed, а для отказа —>ProcessingFailure.

Сведение информации воедино

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

• Cluster Network 1 = IP scheme 192.168.0.0/24
• Cluster Network 2 = IP scheme 1.0.0.0/8
• Cluster Network 3 = IP scheme 172.168.0.0/16

В сетевых подключениях узлов сетевые адаптеры идентифицируются следующим образом:

• CORPNET = IP scheme 192.168.0.0/24
• MGMT = IP scheme 1.0.0.0/8
• BACKUP = IP scheme 172.168.0.0/16

Сервер FILESERVER1 использует сеть Cluster Network 1, функ-ционирующую на узле NODE1, а сервер FILESERVER2 – сеть Cluster Network 2 на узле NODE2.

Предположим, ночью произошел сбой, и группа файлового сервера FILESERVER2 переместилась с узла NODE2 на узел NODE1. Требуется выяснить причину отказа.

В диспетчере кластеров щелкаем правой кнопкой на группе FI-LESERVER2 и выбираем Show Critical Events («Показать критические события»). На экран выдаются следующие события:

Event ID: 1069

Description: Cluster Resource ‘IP Address 1.1.1.1’ of

type ‘IP Address’ in Clustered Role ‘FILESERVER’ failed.

Event ID: 1205

Description: The Cluster service failed to bring clustered

service or application ‘FILESERVER2’ completely online or

offline. One or more resources may be in a failed state.

Первое событие указывает на сбой ресурса с IP-адресом 1.1.1.1. Щелкаем правой кнопкой на этом ресурсе в диспетчере кластеров и выбираем Show Critical Events («Показать критические события»). На экран выдаются следующие события:

Event ID: 1077

Description: Health check for IP Interface

‘IP Address 1.1.1.1’ (address 1.1.1.1) failed (status is

1168). Run the Validate a Configuration wizard to ensure

that the network adapter is functioning properly.

Event ID: 1069

Description: Cluster Resource ‘IP Address 1.1.1.1’ of

type ‘IP Address’ in Clustered Role ‘FILESERVER’ failed.

На основании описания первого события (1077) воспользуемся мастером проверки настроек Validate a Configuration Wizard. Запускаем только тест Network/Validate Network Communication для проверки всех адаптеров и сетевых путей между узлами.

После выполнения теста Network/Validate Network Communication анализируем отчет. В отчете нет ни ошибок, ни предупреждений, поэтому откладываем его в сторону.

Есть каналы событий, которые можно проанализировать, поэтому обращаемся к каналу FailoverClustering/Operational, где имеется следующее событие:

Event ID: 1153

Description: The Cluster service is attempting to failover

the clustered service or application ‘FILESERVER2’ from

node ‘NODE2’ to node ‘NODE1’

На основании этого описания переходим к каналу FailoverClus-tering/Diagnostics, где имеются следующие события:

Event ID: 2051

Description: [RCM] rcm::RcmResource::HandleFailure:

(IP Address 1.1.1.1)

Event ID: 2051

Description: [RES] IP Address:

Failed to query properties of adapter id

F3EDD1C8-6984-82BC-498806B841CA, status 87.

Генерируем файл Cluster.log для этого узла, в журнале выполняем поиск >ProcessingFailure и находим следующие записи:

[RES] IP Address: IP Interface

3600A8C0 failed LooksAlive check, status 1168.

[RES] IP Address: IP Interface

3600A8C0 failed IsAlive check, status 1168.

[RHS] Resource IP Address 1.1.1.1 has indicated failure.

[RCM] Res IP Address 1.1.1.1: Online -> ProcessingFailure

( State Unknown )

[RCM] TransitionToState( IP Address 1.1.1.1)

Online—>ProcessingFailure.

Далее в Cluster.log находим записи, в которых говорится о том, что группа была перемещена. Это указывает на то, что записи, найденные в результате поиска —>ProcessingFailure, имеют отношение к проблеме, обусловившей перемещение группы. По ошибкам, обозначенным в этих записях, мы точно знаем, что произошел сбой ресурса с данным IP-адресом. Чтобы выяснить значение кода статуса ошибки, воспользуемся командой Net.exe:

NET HELPMSG 1168

Команда возвращает сообщение Element not found («Элемент не найден»). После более тщательного изучения записей видим, что проблема может быть связана с сетевым адаптером. Несколько аппаратных тестов применительно к адаптерам выявляют неисправный адаптер, который даже не виден в Windows. Проблему решает замена неисправного адаптера.

Однако остается вопрос, почему в результатах теста Net-work/Validate Network Communication отсутствуют ошибки. Этот тест предусматривает проверку всех сетевых адаптеров, от одного узла к другому, независимо от их местонахождения (в одной или в разных сетях). Переходы между узлами осуществляются по всевозможным известным маршрутам. Поэтому существуют ожидаемые отказы, обусловленные особенностями организации кабельных соединений в сетях между узлами или разбиения сетей на сегменты.

При более тщательном изучении результатов теста обращаем вни-мание на информацию, представленную на экране 2.

Экран 2. Результаты теста Network/Validate Network Communication

Мы видим, что узел NODE1 не имеет сетевого адаптера, опреде-ляемого как MGMT. По сути, это означает то же, что и события, то есть что у NODE1 – две сети, а у NODE2 – три. Следовательно, недостаточно просто просматривать ошибки и предупреждения в верхней части отчета. Необходимо также изучать результаты теста.

Существуют разные способы диагностики неполадок кластера и множество путей анализа информации, позволяющей проникнуть в суть проблемы. Здесь представлен лишь один из способов выявления причин проблем, возникающих в кластерах. Дополнительную информацию можно найти в блогах Ask the Core Team (blogs.technet.com/b/askcore) и Clustering and High Availability (blogs.msdn.com/b/clustering).

Таблица. Ключевые слова, используемые для поиска ресурсов

Ключевое слово Описание

—>OnlinePending Это ключевое слово появляется в журнале, когда в диспетчере кластеров отображается состояние «Ожидание подключения» (Online Pending) для ресурса. Именно здесь должен начинаться поиск, если требуется отследить подключение ресурса

—>OfflinePending Это ключевое слово появляется в журнале, когда в диспетчере кластеров отображается состояние «Ожидание отключения» (Offline Pending) для ресурса. Именно здесь должен начинаться поиск, если требуется отследить отключение ресурса

—>Offline Это ключевое слово появляется в журнале, когда в диспетчере кластеров отображается состояние «Автономная работа» (Offline) для ресурса. Если отслеживается ресурс, то смотреть дальше необходимости нет. Если этот ресурс зависит от другого ресурса, то тот другой ресурс мог начать процесс отключения первым

—>Online Это ключевое слово появляется в журнале, когда в диспетчере кластеров отображается состояние «В сети» (Online) для ресурса. Если отслеживается ресурс, то смотреть дальше нет необходимости. Если от этого ресурса зависит другой ресурс, то тот другой ресурс не начнет свой процесс подключения к сети, пока не завершен этот процесс

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

I just had the same problem with a Windows Server 2019 Failover Cluster (for Hyper-V 2019).
I usually also disable IPv6 on my Servers and that caused the problems.
The cluster threw lots of Critical Errors and sometimes did a hard failover, even though a file share witness was also in place and working(?!).

Errors and Warnings I observed in the eventlog were:

FailoverClustering Event IDs:

• 1135 (Cluster node ‘….’ was removed from the active failover cluster membership)
• 1146 (The cluster Resource Hosting Subsystem (RHS) process was terminated and will be restarted)
• 1673 (Cluster node ‘….’ has entered the isolated state.)
• 1681 (Virtual machines on node ‘….’ have entered an unmonitored state.)

Service Control Manager Event IDs:

• 7024 (A quorum of cluster nodes was not present to form a cluster.)
• 7031 (The Cluster Service service terminated unexpectedly.)

FailoverClustering-Client

• 81 (Extended RPC error information)

Thanks to your research I got an important clue: The hidden adapter still uses IPv6.
Since the article you had linked to said that it was not recommended or mainstream to disable IPv6 on the hidden adapter, but disabling it on all other adapters was supported and tested, i was wondering what stopped him from working.

Using the following Command I pulled the cluster logs (also thanks for the hint! I was not aware of this useful command):

# -Destination (Folder) in my case changed to be not on the "C:" SATADOM (this thing is slow and has few write cycles)
# -TimeSpan (in minutes) limited to one of the Failovers because these logs get HUGE otherwise.
Get-ClusterLog -Destination "E:" -TimeSpan 5

Unfortunately I had the same log entries you already have posted.

I re-enabled IPv6 on all adapters and reverted my tunnel related adapters/configs with:

Set-Net6to4Configuration -State Default
Set-NetTeredoConfiguration -Type Default
Set-NetIsatapConfiguration -State Default

That did not do the trick…
Looking further I noticed that I also always disable «those unneeded» IPv6 related Firewall Rules… And that seemed to be the actually important Change! Those rules seem to affect the invisible adapter too.

The thing seems to be: IPv6 does not use ARP for finding the MAC addresses of its communication partners. It uses the Neighbor Discovery Protocol. And this protocol does not work, if you disable the associated Firewall Rules. While you can check the IPv4 ARP entries with:

arp -a

This won’t show you the MAC addresses for IPv6 addresses. For those you can use:

netsh interface ipv6 show neighbors level=verbose

If you want, you can filter the output to your IPv6 adapter addresses like this:

netsh interface ipv6 show neighbors level=verbose | sls ".*fe80::1337:1337:1234:4321.*" -Context 4 |%{$_.Line,$_.Context.PostContext,""}

Doing that I found out, that those entries seem to be very short lived. The state of the entry for the Microsoft «Failover Cluster Virtual Adapter» link local address of the cluster partner was always toggling between «Reachable» and «Probe». I did not get the moment in which it was «Unreachable» though, but after re-enabling the IPv6 rules, the problem went away:

Get-NetFirewallRule -ID "CoreNet-ICMP6-*" | Enable-NetFirewallRule

Somehow this MAC address seems to be exchanged on another way between the cluster partners (probably because it is the «virtual Remote» address and not a real one?). So it keeps reappearing, leading to those wild Failover / Quarantine / Isolated states.

Probably disabling IPv6 on the invisible adapter would have helped too, but since this is not recommended, I now have decided to stop disabling IPv6 related things altogether. It’s the future anyway

Hope this helps another fellow IPv6-disabler!

Главное, что следует искать

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

Первое, с чем предстоит работать, —диспетчер отказоустойчивости кластеров. Этот новый инструмент управления кластером позволяет руководить группами и ресурсами и выполнять диагностику неполадок. Диспетчер отказоустойчивости кластеров открывается из пункта «Администрирование» в меню «Пуск».

Каналы событий

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

• FailoverClustering:

— Operational;

— Diagnostic (если выбран пункт Show Analytic and Debug Logs («отобразить журналы анализа и отладки»));

— Performance-CSV (если выбран пункт Show Analytic and Debug Logs).

• FailoverClustering-Client:

— Diagnostic (если выбран пункт Show Analytic and Debug Logs).

• FailoverClustering-Manager:

— Admin;

— Diagnostic (если выбран пункт Show Analytic and Debug Logs).

• FailoverClustering-WMIProvider:

— Admin;

— Diagnostic (если выбран пункт Show Analytic and Debug Logs).

События запуска/остановки службы кластеров, перемещения групп, перевода групп в онлайн/автономный режим и т. д. регистрируются в журнале FailoverClusteringOperational. Например:

Идентификатор события: 1061 Описание: служба кластеров успешно настроила отказоустойчивый кластер JohnsCluster.

Неудачные попытки установления соединения с другими узлами при открытии диспетчера отказоустойчивости кластеров регистрируются в журнале FailoverClustering-ManagerAdmin. Например: Идентификатор события: 4684 Описание: диспетчеру отказоустойчивости кластеров не удалось связаться с серверами DNS для разрешения имени W2K8-R2-NODE2.contoso.com. Дополнительные сведения можно найти в канале диагностики диспетчера отказоустойчивости кластеров.

В журнале FailoverClustering-Manager Diagnostic можно увидеть следующее:

Идентификатор события: 4609

Описание: ошибка при попытке проверки связи с W2K8-R2-NODE2.contoso.com. System.ApplicationException: не удалось связаться с одним или несколькими DNS-серверами. Убедитесь в правильности настройки DNS и полном подключении компьютера к сети.

Идентификатор события: 4612 Описание: проверка связи с W2K8-R2-NODE2.contoso.com завершилась сбоем.

Именно по этим событиям можно установить проблему подключения узла к серверу DNS и затем приступить к ее устранению. Не просматривая указанные журналы, о наличии неполадок можно будет судить по тому, что в диспетчере отказоустойчивости кластеров узел W2K8-R2-NODE2 будет отображен как неисправный. Еще один журнал в числе упомянутых выше, Failover-ClusteringDiagnostic, мы обсудим несколько позже.