Freigeben über

Erro "The node failed to join failover cluster due to error code '2'" ao tentar ingressar node no cluster

  • Artikel

Por: Rafael Oliveira

 

Recentemente, trabalhamos em um caso o qual ocorria falha ao tentar ingressar um novo node a um cluster Hyper-V com Windows Server 2012 R2. Basicamente, o erro obtido no wizard de adição do novo node era o seguinte:

 

Cluster service on node NODE02 did not reach the running state. The error code is 0x5b4. For more information check the cluster log and the system event log from node NODE02. This operation returned because the timeout period expired.

The server 'NODE02.domain.com' could not be added to the cluster.

An error occurred while adding node 'NODE02.domain.com' to cluster 'CLUHYPERV2012'.

This operation returned because the timeout period expired

 

No log de eventos do node que sofreu falha durante a operação de join no cluster tínhamos o seguinte evento:

 

Log Name:     System

Source:       Microsoft-Windows-FailoverClustering

Date:         03/01/2017 17:58:15

Event ID:     1070

Task Category: Startup/Shutdown

Level:         Critical

Keywords:     

User:         SYSTEM

Computer:     NODE02.domain.com

Description:

The node failed to join failover cluster 'CLUHYPERV2012' due to error code '2'.

Event Xml:

<Event xmlns="https://schemas.microsoft.com/win/2004/08/events/event">

<System>

   <Provider Name="Microsoft-Windows-FailoverClustering" Guid="{BAF908EA-3421-4CA9-9B84-6689B8C6F85F}" />

   <EventID>1070</EventID>

   <Version>0</Version>

   <Level>1</Level>

   <Task>8</Task>

   <Opcode>0</Opcode>

   <Keywords>0x8000000000000000</Keywords>

   <TimeCreated SystemTime="2017-01-03T19:58:15.497629200Z" />

   <EventRecordID>5217543</EventRecordID>

   <Correlation />

   <Execution ProcessID="4868" ThreadID="3164" />

   <Channel>System</Channel>

   <Computer> NODE02.domain.com</Computer>

   <Security UserID="S-1-5-18" />

</System>

<EventData>

   <Data Name="ClusterName">CLUHYPERV2012</Data>

   <Data Name="Status">2</Data>

   <Data Name="NodeName">NODE02</Data>

</EventData>

</Event>

 

A fim de obter mais detalhes, foi gerado o cluster log. Aqui fica um adendo sobre este assunto: em cenários onde temos falha para adicionar o node no cluster, é necessário que o comando para criação do cluster log seja executado diretamente no nó que falha ao ser adicionado. Mais informações sobre como gerar o cluster log podem ser encontradas no link https://technet.microsoft.com/pt-br/library/ee461045.aspx.

No log do cluster, tínhamos, basicamente, o seguinte:

 

00001304.00000c5c::2017/01/03-19:58:15.497 ERR   [CORE] Node 1: exception caught (2)' because of 'Failed to read value 'Name''

00001304.00000c5c::2017/01/03-19:58:15.497 ERR   Exception in the InstallState is fatal (status = 2)

00001304.00000c5c::2017/01/03-19:58:15.497 DBG   [NETFT] Disabling heartbeats

00001304.00000c5c::2017/01/03-19:58:15.498 DBG   [NETFT] Enabling heartbeats

00001304.00000c5c::2017/01/03-19:58:15.498 DBG   Exception in the InstallState is fatal: set netft heartbeat interval to 900 seconds

00001304.00000c5c::2017/01/03-19:58:15.498 ERR   Exception in the InstallState is fatal (status = 2), executing OnStop

 

O error code da falha era 2 ("The system cannot find the file specified") e, pela mensagem obtida acima no cluster.log, vimos que o mesmo estava associado a leitura do parâmetro 'Name'. Como conclusão, o parâmetro 'Name' não foi encontrado.

Infelizmente, não tínhamos mais detalhes acerca deste parâmetro e a qual recurso ele pertencia, por exemplo. Com isso, simulamos novamente o problema coletando um trace com o process monitor (https://technet.microsoft.com/en-US/sysinternals/processmonitor.aspx) da Sysinternals.

Analisando o cluster.log em conjunto ao trace do procmon (Process Monitor), a fim de obter os eventos no mesmo período, foi detectado o seguinte:

 

Cluster.log:

 

000018e0.00001a18::2017/01/04-19:15:46.297 ERR   [CORE] Node 1: exception caught (2)' because of 'Failed to read value 'Name''

000018e0.00001a18::2017/01/04-19:15:46.297 ERR   Exception in the InstallState is fatal (status = 2)

000018e0.00001a18::2017/01/04-19:15:46.297 DBG   [NETFT] Disabling heartbeats

000018e0.00001a18::2017/01/04-19:15:46.297 DBG   [NETFT] Enabling heartbeats

000018e0.00001a18::2017/01/04-19:15:46.297 DBG   Exception in the InstallState is fatal: set netft heartbeat interval to 900 seconds

000018e0.00001a18::2017/01/04-19:15:46.297 ERR   Exception in the InstallState is fatal (status = 2), executing OnStop

 

Procmon:

 

17:15:46,3230508 clussvc.exe 6368 6680 RegQueryValue HKLM\CLUSTER\Groups\54230fb4-d525-46b4-987e-7fc8f4b2e74f\Name NAME NOT FOUND Length: 144

 

Ou seja, o resource group do cluster com ID 54230fb4-d525-46b4-987e-7fc8f4b2e74f estava sem o parâmetro 'Name'. Através do cmdlet PowerShell Get-ClusterGroup | fl * confirmamos que tínhamos este grupo sem nome:

 

Cluster               : CLUHYPERV2012

IsCoreGroup           : False

OwnerNode             : NODE01

State                 : Online

Name                   :

Description           :

PersistentState       : 1

FailoverThreshold     : 4294967295

FailoverPeriod         : 6

AutoFailbackType       : 0

FailbackWindowStart   : 4294967295

FailbackWindowEnd     : 4294967295

GroupType             : VirtualMachine

Priority               : 2000

DefaultOwner           : 1

AntiAffinityClassNames : {}

StatusInformation     : 0

Id                     : 54230fb4-d525-46b4-987e-7fc8f4b2e74f

 

Como consequência, executamos o cmdlet abaixo no powershell para adicionar um node ao grupo:

 

(Get-ClusterGroup | where {$_.Id -eq "54230fb4-d525-46b4-987e-7fc8f4b2e74f"}).Name = "VM01"

 

Entretanto, ao tentarmos adicionar novamente o node no cluster, a operação falhou com o mesmo erro descrito no início do artigo. Sendo assim, fizemos uma nova coleta do process monitor simulando o problema e obtivemos o seguinte:

 

Cluster.log:

 

00001db0.00001424::2017/01/05-10:11:17.779 ERR   [CORE] Node 1: exception caught (2)' because of 'Failed to read value 'Name''

00001db0.00001424::2017/01/05-10:11:17.779 ERR   Exception in the InstallState is fatal (status = 2)

00001db0.00001424::2017/01/05-10:11:17.779 DBG   [NETFT] Disabling heartbeats

00001db0.00001424::2017/01/05-10:11:17.779 DBG   [NETFT] Enabling heartbeats

00001db0.00001424::2017/01/05-10:11:17.779 DBG   Exception in the InstallState is fatal: set netft heartbeat interval to 900 seconds

00001db0.00001424::2017/01/05-10:11:17.779 ERR   Exception in the InstallState is fatal (status = 2), executing OnStop

 

Procmon:

 

10:22:30.8541374 AM clussvc.exe 7056 RegQueryValue HKLM\CLUSTER\Resources\5584f195-1a5e-4e6d-a15a-e7939cd27bc3\Name NAME NOT FOUND Length: 144

 

Agora, tínhamos um recurso que estava sem o parâmetro 'Name' na hive do cluster. No entanto, ao executar Get-ClusterResource | where {$_.Id -eq "5584f195-1a5e-4e6d-a15a-e7939cd27bc3"} a fim de obter mais detalhes do mesmo, identificamos que o parâmetro 'Name' estava preenchido, porém no registro isto não se refletia, conforme mostrado abaixo:

 

PowerShell:

 

Cluster                 : CLUHYPERV2012

IsCoreResource         : False

IsNetworkClassResource : False

IsStorageClassResource : False

OwnerNode               : NODE01

ResourceType           : Virtual Machine Configuration

State                   : Online

OwnerGroup             : VM01

Name                   : Virtual Machine Configuration VM01

MaintenanceMode         : False

MonitorProcessId       : 2620

Characteristics         : BroadcastDelete, MonitorDetach, MonitorReattach, NotPreempta

Description             :

SeparateMonitor         : False

StatusInformation       : 0

PersistentState         : 1

LastOperationStatusCode : 0

LooksAlivePollInterval : 4294967295

IsAlivePollInterval     : 4294967295

RestartAction           : 2

RestartThreshold       : 1

EmbeddedFailureAction   : 2

RestartDelay           : 500

RestartPeriod           : 900000

RetryPeriodOnFailure   : 3600000

PendingTimeout         : 180000

DeadlockTimeout         : 300000

ResourceSpecificData1   : 0

ResourceSpecificData2   : 0

ResourceSpecificStatus :

Id                     : 5584f195-1a5e-4e6d-a15a-e7939cd27bc3

 

Registro:

 

[HKEY_LOCAL_MACHINE\Cluster\Resources\5584f195-1a5e-4e6d-a15a-e7939cd27bc3]

"Type"="Virtual Machine Configuration"

"SeparateMonitor"=dword:00000000

"RestartAction"=dword:00000002

"PersistentState"=dword:00000001

 

(Vemos acima que o parâmetro 'Name' não estava disponível)

 

A fim de popular novamente o registro, forçamos uma alteração da database renomeando o recurso para um nome temporário e, em seguida, de volta para o nome padrão a fim de permitir que o parâmetro 'Name' fosse criado no registro:

 

(Get-ClusterResource | where {$_.Id -eq "5584f195-1a5e-4e6d-a15a-e7939cd27bc3"}).Name = 'Virtual Machine Configuration VM01_Temp'

(Get-ClusterResource | where {$_.Id -eq "5584f195-1a5e-4e6d-a15a-e7939cd27bc3"}).Name = 'Virtual Machine Configuration VM01'

 

Após isso, foi possível ingressar o node com sucesso no cluster.