Nlb кластер ошибка - Не ошибается лишь тот, кто ничего не делает!

Здравствуйте!

Есть 3 терминальных сервера. Все они собраны в NLB Cluster, в режиме Unicast. Используется 1 сетевой интерфейс на каждом из серверов. В качестве коммутационного оборудования используется Cisco Catalist 2960. Так же на одном из серверов поднят TS Session
Broker. Все работает пока нормально, нагрузка на сервера минимальная, т.к. работает по 6-9 пользователей на каждом (в дальнейщем планируется по 30), но смущают логи, очень часто в лог попадают следующие предупреждения:

Код события 105

Источник события Microsoft-Windows-NLB

NLB-кластер []: обнаружена перегрузка таймера. Она может быть результатом атаки типа «отказ в обслуживании» или очень высокой нагрузки на сервер. В это время некоторые подключения могут выйти из строя. Если проблема часто повторяется, проанализируйте угрозу
и примите соответствующие меры или добавьте серверы к кластеру. Когда атака прекратится, будет сделана информационная запись в журнале событий.

Код события 18

Источник события Microsoft-Windows-NLB

NLB-кластер [172.16….]: службой NLB обнаружены повторяющиеся подсети кластера. Возможно, разбиение сети на части препятствует прохождению периодических сигналов NLB от одних узлов кластера к другим. Хотя правильное выполнение операций NLB возобновилось,
следует изучить влияние разбиения сети.

Из-за чего это может быть? И не будет ли при большой нагрузке из-за этого проблем?

Спасибо!

Источник

Обновлено 26.12.2022

Добрый день! Уважаемые читатели и гости IT блога Pyatilistnik.org. В минувший раз я вам подробно описал, как я смог сохранить свои данные на IPad при неудачной попытке обновить его и ошибках 4013, 2009 и 5. Сегодня я хочу вам показать интересную ошибку которую вы можете встретить на NLB участнике при попытке обратиться к его партнеру, ошибка звучит так «Access denied. Error connecting to server». Давайте смотреть в чем дело и как поправить.

Описание ошибки доступа на NLB

И так у меня есть кластер NLB на базе Windows Server 2016. Мне потребовалось провести обслуживание данных хостов, я по очереди перевел их в состояние «Suspend» и перезагрузил. После перезагрузки первого он получил статус «Enable» и вступил в работу, далее я провел то же самое и со вторым участником. Зайдя на первой ноде NLB кластера в оснастку «Network Load Balancing Cluster» я обнаружил ошибку:

Access denied. Error connecting to «FQDN имя сервера» при загрузке информации о конфигурации с 2 хоста

Сразу хочу отметить, что я запускал оснастку Network Load Balancing Cluster от имени доменной учетной записи администратора домена, у которого есть все права на оба сервера NLB

Если локально на данном сервере запустить оболочку PowerShell в режиме администратора и выполнить команду:

То у меня выскочила ошибка:

Get-NlbClusterNode : Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))
At line:1 char:1
+ Get-NlbClusterNode
+ ~~~~~~~~~~~~~~~~~~
+ CategoryInfo : PermissionDenied: (Microsoft.Netwo…tNlbClusterNode:GetNlbClusterNode) [Get-NlbClusterN
ode], UnauthorizedAccessException
+ FullyQualifiedErrorId : Access denied.,Microsoft.NetworkLoadBalancingClusters.PowerShell.GetNlbClusterNode

Как устранить ошибку Access denied на NLB

1️⃣Первое, что вы должны сделать, это посмотреть журналы безопасности на обоих нодах NLB. На сервере, где я получал ошибку доступа, я в журнале безопасности (security) нашел событие ID4648:

A logon was attempted using explicit credentials.

Subject:
Security ID: PYATILISTNIKsema
Account Name: sema
Account Domain: PYATILISTNIK
Logon ID: 0xCE7A8A
Logon GUID: {bbaa4115-406b-fc70-ba47-010254f7ad10}

Account Whose Credentials Were Used:
Account Name: test_nlb
Account Domain: PYATILISTNIK
Logon GUID: {00000000-0000-0000-0000-000000000000}

Target Server:
Target Server Name: app2.PYATILISTNIK.org
Additional Information: app2.PYATILISTNIK.org

Process Information:
Process ID: 0x308
Process Name: C:WindowsSystem32svchost.exe

Network Information:
Network Address: 10.xx.xxx.28
Port: 135

This event is generated when a process attempts to log on an account by explicitly specifying that account’s credentials. This most commonly occurs in batch-type configurations such as scheduled tasks, or when using the RUNAS command.

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

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

Перейдем на сервер, к которому не удается получить доступ и посмотрим логи журнала безопасности там, единственное сделайте фильтр по «audit failure«

В результате чего я отфильтровал события, среди которых я обнаружил ID 4625:

An account failed to log on.

Subject:
Security ID: NULL SID
Account Name: —
Account Domain: —
Logon ID: 0x0

Logon Type: 3

Account For Which Logon Failed:
Security ID: NULL SID
Account Name: test_nlb
Account Domain: PYATILISTNIK

Failure Information:
Failure Reason: Unknown user name or bad password.
Status: 0xC000006D
Sub Status: 0xC0000064

Detailed Authentication Information:
Logon Process: NtLmSsp
Authentication Package: NTLM
Transited Services: —
Package Name (NTLM only): —
Key Length: 0

Из полезного тут:

Logon Type: 3 — Тип входа сетевой (Пользователь или компьютер вошли в систему на данном компьютере через сеть.)
Account Name: test_nlb — Учетная запись от которой была попытка входа
Status: 0xC000006D — Статус, что не так (Причиной является неправильное имя пользователя или сведения о проверке подлинности.) Учетку я не нашел в домене, вот и причина.
Authentication Package: NTLM

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

2️⃣Найдя виновника, вам нужно указать актуальные данные для доступа к другому участнику NLB, это должна быть учетная запись обладающая административными правами на всех участниках NLB кластера. Запустите оснастку «Network Load Balancing Cluster» и найдите меню «Options — Credentials«.

Указываем тут учетную запись имеющую доступ.

С высокой долей вероятности вам придется перезагрузить данную ноду NLB

Независимо от инструмента, который вы будете использовать для управления кластером, вам необходимо запускать его в контексте безопасности учетной записи с правами администратора на каждый узел кластера. Это можно сделать, войдя в систему с этой учетной записью, запустив утилиту вторичного входа в систему (RunAs) или, в случае диспетчера NLB, установив учетные данные по умолчанию (из пункта меню «Параметры — Учетные данные»). NLB Manager попытается подключиться к удаленным узлам, используя эти учетные данные.

Так же вы можете добавить нужный хост через контекстное меню, выбрав пункт «Add Host to Cluster«

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

3️⃣Попробуйте отключить на недоступном Windows Server функцию UAC. Для этого вызовите в пуске «UserAccountControlSettings.exe»

4️⃣На время выключите антивирусные решения и брандмауэр, если соединения до сих пор нет.
5️⃣Убедитесь, что есть сетевая связанность. например через утилиту PING и то, что DNS имя разрешается.

Как посмотреть статус NLB службы

NLB — это драйвер, поэтому вы не увидите его с помощью оснастки службы mmc. Вы можете использовать командную строку «sc query wlbs» для проверки состояния драйвера. Я
считаю, что служба должна иметь возможность зависеть от драйвера. Вы можете попробовать

Куст реестра NLB

Когда вы включаете NLB на сервере, записи реестра по умолчанию создаются в разделе:

HKLMSystemCurrentControlSetServicesWLBS

На этом у меня все, с вами был Иван Сёмин, автор и создатель IT портала Pyatilistnik.org.

Дополнительные ссылки

https://learn.microsoft.com/ru-ru/windows/security/threat-protection/auditing/event-4625
https://www.serverbrain.org/administration-practice-2003/nlb-cluster-management.html
https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/network-load-balancing-concept-notes

Источник

Windows Server 2008 Datacenter Windows Server 2008 Enterprise Windows Server 2008 Standard Windows Server 2008 Datacenter without Hyper-V Windows Server 2008 Enterprise without Hyper-V Windows Server 2008 Standard without Hyper-V Windows Server 2008 for Itanium-Based Systems More…Less

Symptoms

Consider the following scenario:

The Network Load Balancing (NLB) feature is enabled on a Windows Server 2008-based computer.
NLB is configured to run in multicast mode.
There is a router between the NLB cluster nodes and the client devices.
The NLB cluster nodes have not recently communicated with any device on the client’s subnet.

In this scenario, clients may experience intermittent connectivity failures when they try to communicate with a server that is part of this NLB cluster. Attempts to connect to the node-specific IP are successful. Outbound connection attempts from any NLB server nodes that use a node-specific IP are also successful.

Cause

When you try to respond to a client on a different subnet, the server must first send an ARP request for its default gateway. In multicast mode, this ARP request contains a combination of the unicast Virtual IP of the cluster and the multicast MAC address of the interface. Because some routers are designed or configured not to reply to packets with this mix of unicast and multicast, the server cannot discover the address of the default gateway. Therefore, the server cannot respond to the client’s request.

Resolution

Hotfix information

A supported hotfix is available from Microsoft. However, this hotfix is intended to correct only the problem that is described in this article. Apply this hotfix only to systems that are experiencing the problem described in this article. This hotfix might receive additional testing. Therefore, if you are not severely affected by this problem, we recommend that you wait for the next software update that contains this hotfix.

If the hotfix is available for download, there is a «Hotfix download available» section at the top of this Knowledge Base article. If this section does not appear, contact Microsoft Customer Service and Support to obtain the hotfix.

Note If additional issues occur or if any troubleshooting is required, you might have to create a separate service request. The usual support costs will apply to additional support questions and issues that do not qualify for this specific hotfix. For a complete list of Microsoft Customer Service and Support telephone numbers or to create a separate service request, visit the following Microsoft Web site:

http://support.microsoft.com/contactus/?ws=supportNote The «Hotfix download available» form displays the languages for which the hotfix is available. If you do not see your language, it is because a hotfix is not available for that language.

Important Windows Vista and Windows Server 2008 hotfixes are included in the same packages. However, only one of these products may be listed on the “Hotfix Request” page. To request the hotfix package that applies to both Windows Vista and Windows Server 2008, just select the product that is listed on the page.

Prerequisites

To apply this hotfix, the Network Load Balancing feature must be installed on the Windows Server 2008-based computer.

Restart requirement

You do not have to restart the computer after you apply this hotfix.

Hotfix replacement information

This hotfix does not replace a previously released hotfix.

File information

The English version of this hotfix has the file attributes (or later file attributes) that are listed in the following table. The dates and times for these files are listed in Coordinated Universal Time (UTC). When you view the file information, it is converted to local time. To find the difference between UTC and local time, use the Time Zone tab in the Date and Time item in Control Panel.

Windows Vista and Windows Server 2008 file information notes

The .manifest files and the .mum files that are installed in each environment are listed separately in the «Additional file information for Windows Server 2008 and for Windows Vista» section. These files and their associated .cat (security catalog) files are critical to maintaining the state of the updated component. The .cat files are signed with a Microsoft digital signature. The attributes of these security files are not listed.

For all supported x86-based versions of Windows Server 2008

File name	File version	File size	Date	Time	Platform
Nlb.sys	6.0.6001.22374	197,632	11-Feb-2009	03:29	x86

For all supported x64-based versions of Windows Server 2008

File name	File version	File size	Date	Time	Platform
Nlb.sys	6.0.6001.22374	243,712	11-Feb-2009	03:59	x64

For all supported IA-64-based versions of Windows Server 2008

File name	File version	File size	Date	Time	Platform
Nlb.sys	6.0.6001.22374	570,880	11-Feb-2009	02:54	IA-64

Workaround

To work around this problem, create a static ARP entry on each NLB node for the gateway. If you cannot do this, use some method for creating an outbound connection to a non-local device from the NLB node to populate the ARP cache. This method must support continuous communication between the devices to prevent the ARP cache entry from timing out.

Status

Microsoft has confirmed that this is a problem in the Microsoft products that are listed in the «Applies to» section.

More Information

The specific symptoms that you experience depend on the switch or the router and how it reacts to ARP when ARP is using both unicast IP and multicast MAC.

Additionally, a network sniff might be required to confirm the presence of the problem that is described in the «Cause» section. If the sender MAC address starts with «03-BF,» this means that NLB is using the following multicast MAC address:

SendersMacAddress: 03-BF-0A-1E-04-06

Additional file information for Windows Server 2008

Additional files for all supported x86-based versions of Windows Server 2008

File name	File version	File size	Date	Time	Platform
Package_for_kb960916_sc_0~31bf3856ad364e35~x86~~6.0.1.0.mum	Not Applicable	1,423	11-Feb-2009	16:35	Not Applicable
Package_for_kb960916_sc~31bf3856ad364e35~x86~~6.0.1.0.mum	Not Applicable	1,422	11-Feb-2009	16:35	Not Applicable
Package_for_kb960916_server_0~31bf3856ad364e35~x86~~6.0.1.0.mum	Not Applicable	1,423	11-Feb-2009	16:35	Not Applicable
Package_for_kb960916_server~31bf3856ad364e35~x86~~6.0.1.0.mum	Not Applicable	1,430	11-Feb-2009	16:35	Not Applicable
X86_microsoft-windows-n..ncing-networkdriver_31bf3856ad364e35_6.0.6001.22374_none_ae4bea2531bcbaab.manifest	Not Applicable	4,343	11-Feb-2009	05:54	Not Applicable

Additional files for all supported IA-64-based versions of Windows Server 2008

File name	File version	File size	Date	Time	Platform
Ia64_microsoft-windows-n..ncing-networkdriver_31bf3856ad364e35_6.0.6001.22374_none_ae4d8e1b31bac3a7.manifest	Not Applicable	4,349	11-Feb-2009	05:06	Not Applicable
Package_for_kb960916_server_0~31bf3856ad364e35~ia64~~6.0.1.0.mum	Not Applicable	1,427	11-Feb-2009	16:35	Not Applicable
Package_for_kb960916_server~31bf3856ad364e35~ia64~~6.0.1.0.mum	Not Applicable	1,434	11-Feb-2009	16:35	Not Applicable

Additional files for all supported x64-based versions of Windows Server 2008

File name	File version	File size	Date	Time	Platform
Amd64_microsoft-windows-n..ncing-networkdriver_31bf3856ad364e35_6.0.6001.22374_none_0a6a85a8ea1a2be1.manifest	Not Applicable	4,355	11-Feb-2009	06:22	Not Applicable
Package_for_kb960916_sc_0~31bf3856ad364e35~amd64~~6.0.1.0.mum	Not Applicable	1,431	11-Feb-2009	16:35	Not Applicable
Package_for_kb960916_sc~31bf3856ad364e35~amd64~~6.0.1.0.mum	Not Applicable	1,430	11-Feb-2009	16:35	Not Applicable
Package_for_kb960916_server_0~31bf3856ad364e35~amd64~~6.0.1.0.mum	Not Applicable	1,431	11-Feb-2009	16:35	Not Applicable
Package_for_kb960916_server~31bf3856ad364e35~amd64~~6.0.1.0.mum	Not Applicable	1,438	11-Feb-2009	16:35	Not Applicable

For more information about software update terminology, click the following article number to view the article in the Microsoft Knowledge Base:

824684 Description of the standard terminology that is used to describe Microsoft software updates

Need more help?

Want more options?

Explore subscription benefits, browse training courses, learn how to secure your device, and more.

Communities help you ask and answer questions, give feedback, and hear from experts with rich knowledge.

Источник

While working in security zones like DMZ, you might come across the need to configure a Windows Network Load Balancing (WNLB) cluster across two servers. Servers in DMZ are usually in a Workgroup mode unless you have a seperate active directory domain for centrally managing the DMZ Servers.

The NLB Clusters can be accessed by navigating to the Windows Network Load Balancing Manager (Start -> Administrative Tools -> Network Load Balancing Manager) of any Server participating in the NLB Cluster.

If the NLB Cluster is accessed using the local “Administrator” account then we have the following two scenarios:

Local “Administrator” account on both Servers have the same Password: In this case the NLB Manager can access both the Servers participating in the NLB Cluster without any issues.
Local “Administrator” account on both Servers have the different Passwords: In this case the NLB Manager can access only the local Server. But to access the Second Server, you will be prompted to enter the credentials. You can alternatively save these Credentials by navigating to NLB Manager -> Options -> Credentials.

If the NLB Cluster is accessed using any other user which is a part of the local “Administrators” group then only the local server will be accessible. But you will get an “Access Denied” message while accesing the second host in the NLB Cluster.

The Second host can be accessed by saving the Administrator account credetails by navigating to NLB Manager -> Options -> Credentials.

When a local administrator account is used, everything works fine as expected. This is because the Security Identifier (SID) of the local “Administrator” account is identical on all Servers. When you manually create an account on each Server and add it to the local “Administrators” Group then eventhough you might use the same username, its Security Identifier (SID) differs from Server to Server. SID which is a part of the “Administrators” Group on one Server is non existent on the other Server and hence the message “Access Denied“.

There are ways to clone a user SID and make it identical on both Servers, but these ways are not recommended by Microsoft. So the best option is to use the local “Administrator” account while in Workgroup mode.

Источник

Проблема:

При создании или добавлении узла к кластеру NLB,
процесс конфигурации заканчивается ошибкой, а в журнале системы
появляется ошибка с кодом события 53 и источником NLB:
«NLB-кластер
[]: служба NLB не подключится к адаптеру «{}», поскольку он не
поддерживает динамическую смену своих MAC-адресов. Используйте сетевой
адаптер, поддерживающий эту возможность.»

Причина:

Дело оказалось в драйверах от сетевого адаптера. В обоих серверах установлен сетевой адаптер от Intel. И на обоих серверах стояли самые свежие драйвера, на тот момент, с официального сайта Intel «intel networks connections 17.4.95.0». До конца появление ошибки выяснить так и не удалось.

Решение:

В данном случае все решилось удалением драйверов от Intel и установкой драйверов от операционной системы Windows Server 2008, и заново настроенным кластером.

Источник