CLUSTER NODE JOIN ERROR 0x80041013
O procedimento de agregar um nó no cluster é normalmente simples e sem percalços. Todavia esse se tornou interessante pois revela um pouco da complexidade agregada a operações rotineiras. Apenas quando enfrentamos um problema que percebemos o quanto devemos estudar para compreender o produto que trabalhamos.
Esse incidente em particular , envolveu a adição de um quinto nó em um cluster já em produção há meses.
Vamos iniciar por coletar o cluster log. Também podemos coletar o report do wizard do cluadmin , pois esse irá também mostrar o erro no procedimento de juntar o nó no cluster.
CLUSTER.LOG
****************************************************
2007-08-01 13:01:57.713 [ERR ] node101: The query for information about the network connection "Broadcom NetXtreme Gigabit Ethernet Adapter - Onboard - Link A" failed. (hr=0x80041013, {B64DC7A2-444D-422D-BF6A-5C9162B45C50}, {088D6F8B-CCD4-4D0C-9BBD-9C2C730B00FB}, 1, 1, 1), Cluster configuration cannot continue. The Windows Management Instrumentation (WMI) query (to locate the network connection on this node) has failed. Stop and restart the Windows Management Instrumentation (winmgmt) service on this node and try again. If the problem persists, reboot this node and try again.
2007-08-01 13:01:57.916 [INFO] FVDAT100: (null) (hr=00000000, {FDC75680-7DBB-42CA-8003-E4CDB01FF062}, {B8453B8F-92FD-4350-A6D9-551FD018B791}, 0, 90, 5), (null
Ao analisar o log do cluster percebemos que a falha ocorre ao pesquisar a interface de rede no WMI .
2007-08-01 13:01:58.728 [ERR ] FVDAT100: Could not contact the cluster. (hr=0x80041013, {B8453B8F-92FD-4350-A6D9-551FD018B791}, {2E305DD0-9DCA-47FE-8CF6-4306CA72C4A2}, 1, 1, 1), (null)
*****************************************************
O interessante que a pesquisa está sendo feita contra o servidor 101 (que é o primeiro nó do cluster).
Para descobrir mais sobre o erro 0x80041013 , utilizo sempre a ferramenta Error Lookup Tool e ela nos traz:
# for hex 0x80041013 / decimal -2147217389 :
WBEM_E_PROVIDER_LOAD_FAILURE wbemcli.h
# 1 matches found for "0x80041013"
O erro deixa claro que não conseguimos carregar um provider .
Um comportamento que normalmente verifico quando temos esse erro com as NIC é que as mesmas não se registram no MSINFO32 , ou seja abaixo de Hardware \ Components \ Network \ Adapter não há nenhuma informação das placas de rede , indicando um problema com a WMI deste componente.
Ao rodar o msinfo32 em todos os nós do cluster , verifiquei que nenhum apresentava informações da NIC .
Para confirmar o problema com o provider e também investigar que não existe nenhum mais alguma coisa com o WMI, utilizo o WMIDiag que além de informar também aponta alternativas para consertar problemas.
Aqui está o report gerado pelo WMIDiag:
*****************************************************
37997 12:28:03 (0) ** - ROOT/CIMV2, BRCMGroup ({3D888674-29E1-4C0A-BB3D-7F3DD69F71CB})
37998 12:28:04 (0) ** Provider DLL: `WMI information not available (This could be the case for an external application or a third party WMI provider)`
37999 12:28:04 (0) ** => This is an issue because there are still some WMI classes referencing this list of providers
38000 12:28:04 (0) ** while the DCOM registration is wrong or missing. This can be due to:
38001 12:28:04 (0) ** - a de-installation of the software.
38002 12:28:04 (0) ** - a deletion of some registry key data.
38003 12:28:04 (0) ** - a registry corruption.
38004 12:28:04 (0) ** => You can correct the DCOM configuration by:
38005 12:28:04 (0) ** - Executing the `REGSVR32.EXE ` command.
38006 12:28:04 (0) ** Note: You can build a list of classes in relation with their WMI provider and MOF file with WMIDiag.
38007 12:28:04 (0) ** (This list can be built on a similar and working WMI Windows installation)
38008 12:28:04 (0) ** The following command line must be used:
38009 12:28:04 (0) ** i.e. `WMIDiag CorrelateClassAndProvider`
38010 12:28:04 (2) !! WARNING: Re-registering with REGSVR32.EXE all DLL from `C:\WINDOWS\SYSTEM32\WBEM\`
38011 12:28:04 (0) ** may not solve the problem as the DLL supporting the WMI class(es)
38012 12:28:04 (0) ** can be located in a different folder.
38013 12:28:04 (0) ** You must refer to the class name to determine the software delivering the related DLL.
38014 12:28:04 (0) ** => If the software has been de-installed intentionally, then this information must be
38015 12:28:04 (0) ** removed from the WMI repository. You can use the `WMIC.EXE` command to remove
38016 12:28:04 (0) ** the provider registration data.
38017 12:28:04 (0) ** i.e. `WMIC.EXE /NAMESPACE:\\ROOT\CIMV2 path __Win32Provider Where Name=`BRCMGroup` DELETE`
38018 12:28:04 (0) ** => If the namespace was ENTIRELY dedicated to the intentionally de-installed software,
38019 12:28:04 (0) ** the namespace and ALL its content can be ENTIRELY deleted.
38020 12:28:04 (0) ** i.e. `WMIC.EXE /NAMESPACE:\\ROOT path __NAMESPACE Where Name=`CIMV2` DELETE`
38021 12:28:04 (0) ** - Re-installing the software.
**************************************************************
A partir do report ficou claro que teríamos que registrar o WMI provider de alguma maneira.
Comecei por reinstalar os drivers e utilitários do fabricante , o que não surtiu nenhum efeito.
Nesse ponto extrai os drivers para um diretório ; normalmente setup.exe /a ; verifiquei que existia uma pasta chamada \WMI , com os arquivos MOF e DLL utilizados para o registrar os providers WMI.
Nesse ponto , necessitamos registrar os providers.
Abra a linha de comando e certifique que o caminho está no diretório WMI que contém os arquivos e executei os comandos.
for %i in (*.dll) do RegSvr32 - s %i
for %i in (*.exe) do RegSvr32 - s %i
Após um reinício nos servidores as propriedades da NIC estavam apresentadas no system information e a operação de agregar o nó do cluster foi completada com sucesso.
Isso mostra que existe vários aspectos "under the hood" e qualquer operação , por mais trivial que ela seja. Mas com princípios básicos de resolução de problemas a nossa possibilidade de sucesso aumenta consideravelmente.