Windows | Suporte & Troubleshooting

FailoverClustering EventID 1196 | Network Name Resource

diegoalb — Wed, 10 Feb 2016 20:15:58 GMT

Nesse post iremos abordar um evento relativamente comum que é logado no System EventLog de nós do Cluster que estejam enfrentando problemas relacionados a registros DNS.

O EventID 1196 (Source: FailoverClustering) indica que a atualização do registro DNS de um determinado Cluster Network Name falhou. E, no caso desse cliente, a mensagem de erro trazida foi "DNS operation refused". Esse erro é logado de forma consistente a cada 15 minutos, a cada tentativa de registro DNS em que ocorre falha:

No cluster.log o que vemos é a sequência de eventos a seguir:

d54:274.01/12[13:00:31.698](000000) INFO [RES] Network Name <<-ResourceName->>: Dns: Registering into DNS Name: <-ResourceName-> (Type: Singleton)... d54:274.01/12[13:00:31.698](000000) INFO [RES] Network Name: Agent: Sending request Netname/GetToken to NN:2265e20f-56e3-40a4-bea6-9e9052c7d61e:Identity d54:274.01/12[13:00:31.699](000000) INFO [RES] Network Name: [NN] IdentityLocal Begin Impersonating d54:274.01/12[13:00:31.699](000000) INFO [RES] Network Name: [NNLIB] Registering name <-ResourceName-> on DNS Network: contoso.com, with 3 DNS Servers, 1 Virtual Addresses, 1 Domain Names d54:274.01/12[13:00:31.699](000000) INFO [RES] Network Name: [NNLIB] DNS.S: 172.16.100.xx d54:274.01/12[13:00:31.699](000000) INFO [RES] Network Name: [NNLIB] DNS.S: 172.16.200.xx d54:274.01/12[13:00:31.699](000000) INFO [RES] Network Name: [NNLIB] DNS.S: 172.16.100.xx d54:274.01/12[13:00:31.699](000000) INFO [RES] Network Name: [NNLIB] V.Addr: 172.31.10.xx d54:274.01/12[13:00:31.699](000000) INFO [RES] Network Name: [NNLIB] Registering: <-ResourceName->.corp.contoso.com d54:274.01/12[13:00:32.710](000000) INFO [RES] Network Name: [NNLIB] DNS Record there for <-ResourceName->.corp.contoso.com, proceeding d54:274.01/12[13:00:34.750](000000) ERR [RES] Network Name: [NNLIB] Error 9005 on DNS DnsReplaceRecordSetW for A records, name <-ResourceName->.corp.contoso.com (ipv4Count 1, ipv6Count 0) d54:274.01/12[13:00:34.750](000000) INFO [RES] Network Name: [NNLIB] Second Phase for DNS Network: corp.ihf (3 DNS Servers) d54:274.01/12[13:00:34.750](000000) INFO [RES] Network Name: [NN] IdentityLocal End Impersonating d54:274.01/12[13:00:34.750](000000) ERR [RES] Network Name <<-ResourceName->>: Dns: Failed DNS registration with error 9005 for Name: <-ResourceName-> (Type: Singleton)

O código de erro "9005" traduz exatamente para DNS_ERROR_RCODE_REFUSED:

C:\Users\diegoalb>err 9005 # for decimal 9005 / hex 0x232d : SQL_9005_severity_16 sql_err # Either start LSN or end LSN specified in OpenRowset(DBLog, # ...) is invalid. DNS_ERROR_RCODE_REFUSED winerror.h # DNS operation refused. # for hex 0x9005 / decimal 36869 : SSLEVENT_NO_PRIVATE_KEY lsapmsgs.mc # The SSL %1 credential's private key has the following # 3 matches found for "9005"

Observe que todos os endereços IP associados a um recurso Network Name são registrados dinamicamente no DNS (se estiver configurado para dynamic updates) quando eles são trazidos online - Esse é o comportamento padrão do Cluster. Para determinar a solução para esse evento teremos de investigar os vários aspectos que envolvem DNS, sobretudo:

Se os Servidores DNS estão plenamente operacionais e acessíveis;
Se as zonas e configuração de registro dinâmico estão configuradas de forma apropriada;
Se a ACL do registro daquele recurso está correta: Na console do DNS clique com o botão direito no registro e em seguida na aba Security - Confirme que o objeto do CNO (Cluster Name Object, tipicamente seguido de "$" como na imagem-exemplo abaixo) tem Full Control;

Se o registro NÂO está estático (foi criado de forma manual), dessa forma a ACL dele possivelmente estaria errada e incorreríamos no bullet anterior.

Especificamente nesse cliente encontramos que durante o setup do ambiente os administradores tinham um procedimento que envolvia criar o registro de forma manual no Console do DNS para fins de testes (!). Na medida em que o registro era estático, evidentemente o Cluster não tinha permissões suficientes para atualizá-lo. A solução foi simplesmente apagar o registro estático e forçar novo registro do recurso através do comando Powershell : Get-ClusterResource | Update-ClusterNetworkNameResource Referências: https://blogs.msdn.microsoft.com/clustering/2009/07/17/dns-registration-with-the-network-name-resource/ https://technet.microsoft.com/en-us/library/hh847276.aspx

O caso do Cluster que travou e o Failover não acontecia!

diegoalb — Wed, 03 Feb 2016 23:18:55 GMT

Failover Cluster é um grupo de servidores conectados com objetivo de proporcionar alta disponibilidade e escalabilidade para as Aplicações e Serviços. Se qualquer componente de hardware ou software falha, outro nó do Cluster começa a prover aquele Serviço (processo conhecido como Failover) com vistas a garantir a disponibilidade para os usuários e clientes.

Idealmente os clientes haveriam de perceber apenas minimamente quaisquer ocasiões de falhas, no entanto em raras oportunidades pode ocorrer um evento que impede que o Failover aconteça plenamente - Esse post descreve exatamente uma situação real em que um serviço parou de responder e o Failover não aconteceu conforme o esperado.

O ambiente é composto por um Cluster Geográfico, com 4 nós Windows Server 2008 R2 SP1 com a role de File Server e File Server Resource Manager, cada um em um site diferente e virtualizados sob VMware.

Sintomas

Os usuários e clientes perceberam uma degradação da performance e no acesso aos arquivos de uma maneira geral e desde várias horas, ao ponto que os administradores sequer conseguiam conectar na console do nó que era dono dos recursos, nem tampouco os usuários eram capazes de acessar aos seus arquivos. Eventualmente tentou-se mover os recursos de File Server para o outro nó, porém os discos permaneceram com o status ONLINE PENDING por várias horas.

Com o objetivo de restabelecer os Serviços daquela máquina e posteriormente diagnosticar o causador do problema o cliente decidiu capturar um Kernel Memory Dump de forma manual. O nosso escopo a partir daqui é determinar a causa raiz desse problema a partir da análise dos dados capturados, sobretudo os logs do Cluster, Perfmon (que já estava previamente configurado nesse sistema) e o dump.

Análise da Causa Raiz

Na perspectiva do Cluster o problema começou por volta das 19:45hs, quando o health check de alguns recursos começaram a falhar (timed out) de forma inesperada. A consequência disso é que o RHS é terminado:

818:700.07/26[20:38:02.204](000000) WARN [RES] File Server >)(Disk D:)>: Failed in NetShareGetInfo(<>, BA2), status 53. Tolerating... 818:bac.07/26[20:45:02.346](000000) ERR [RHS] RhsCall::DeadlockMonitor: Call ISALIVE timed out for resource 'FileServer-(<>)(Disk D:)'. 818:bac.07/26[20:45:02.361](000000) INFO [RHS] Enabling RHS termination watchdog with timeout 1200000 and recovery action 3. 818:bac.07/26[20:45:02.361](000000) ERR [RHS] Resource FileServer-(<>)(Disk D:) handling deadlock. Cleaning current operation and terminating RHS process. 818:bac.07/26[20:45:02.361](000000) ERR [RHS] About to send WER report. 814:1c0.07/26[20:45:02.361](000000) WARN [RCM] HandleMonitorReply: FAILURENOTIFICATION for 'FileServer-(<>)(Disk D:)', gen(0) result 4. 814:1c0.07/26[20:45:02.361](000000) INFO [RCM] rcm::RcmResource::HandleMonitorReply: Resource 'FileServer-(<>)(Disk D:)' consecutive failure count 1.

Quando o >)(Disk D:)> tentou vir online novamente, percebe-se que o Resource Control Manager acusa somente o status 'WaitingToComeOnline' por um período longo, apesar das diversas tentativas de movimentação entre os nós feita pelos administradores enquanto o problema acontecia:

814:1c0.07/26[19:46:16.058](000000) DBG [RCM] FileServer-(<>)(Disk D:): WaitingToComeOnline, 814:1c0.07/26[19:46:19.179](000000) DBG [RCM] FileServer-(<>)(Disk D:): WaitingToComeOnline, 814:1c0.07/26[19:46:22.299](000000) DBG [RCM] FileServer-(<>)(Disk D:): WaitingToComeOnline, . . . 814:1c0.07/26[20:30:53.221](000000) DBG [RCM] FileServer-(<>)(Disk D:): WaitingToComeOnline, 814:1c0.07/26[20:30:56.341](000000) DBG [RCM] FileServer-(<>)(Disk D:): WaitingToComeOnline, 814:1c0.07/26[20:30:59.461](000000) DBG [RCM] FileServer-(<>)(Disk D:): WaitingToComeOnline, . . . 814:1c0.07/26[22:57:51.989](000000) DBG [RCM] FileServer-(<>)(Disk D:): WaitingToComeOnline, 814:1c0.07/26[22:57:55.109](000000) DBG [RCM] FileServer-(<>)(Disk D:): WaitingToComeOnline, 814:1c0.07/26[22:57:58.229](000000) DBG [RCM] FileServer-(<>)(Disk D:): WaitingToComeOnline,

Esses comportamentos se repetiram algumas vezes até o momento que a máquina foi reiniciada. Do ponto de vista de performance observe que o nó estava desde às 15:30hs com uma pressão considerável sobre CPU: E a maior parte dessa utilização estava relacionado a componentes executando em modo privilegiado (Kernel Mode, sobretudo drivers): Os principais ofensores em termos de CPU parecem ser uma instância do SVCHOST e o SYSTEM (este, bem menos quando comparado à primeira).

A análise do dump (que será assunto para um futuro post =) indicou que essa instância do SVCHOST (svchost#9) estava possivelmente hospedando o serviço File Server Resource Manager. Além disso o dump também evidenciava algumas stacks como a abaixo:

... nt!KiSwapContext+0x8a nt!ExAcquireResourceExclusiveLite+0x14f quota!QuotaPrePnp+0x184 fltmgr!FltpPerformPreCallbacks+0x2f8 fltmgr!FltpPassThrough+0x2d9 fltmgr!FltpDispatch+0xb8 nt!IopSynchronousCall+0xb5 nt!IopRemoveDevice+0x101 nt!PnpSurpriseRemoveLockedDeviceNode+0x128 nt!PnpDeleteLockedDeviceNode+0x38 nt!PnpDeleteLockedDeviceNodes+0xa0 nt!PnpProcessQueryRemoveAndEject+0x6bf nt!PnpProcessTargetDeviceEvent+0x4c nt!PnpDeviceEventWorker+0xf99b6 ...

Trata-se de um problema conhecido e já endereçado pelo hotfix https://support.microsoft.com/en-us/kb/2848443: O driver de quota e File Server Resource Manager (quota.sys) em uma situação muito específica entrava em deadlock (note que esse deadlock não tem nada a ver com o do RHS) e causava os sintomas que variam de alto consumo de CPU até os discos com o status "Online pending".

Depois que o hotfix foi instalado o problema foi resolvido em definitivo.

Ainda que seja relativamente raro lidar exatamente com essa mesma causa raiz em seu ambiente de produção, observe que de posse dos dados certos, capturados no momento apropriado e com seus servidores devidamente instrumentados, as chances de um diagnóstico preciso aumentam de forma considerável. Pretendo publicar novos posts em breve sobre algumas práticas simples que podem ajudar bastante em análises como essa.

Um abraço. Diego

Hello World!

diegoalb — Wed, 03 Feb 2016 01:52:07 GMT

Olá Pessoal, Eu me chamo Diego Albuquerque e sou Premier Field Engineer na Microsoft com foco em Plataformas - Trabalho sobretudo com suporte e troubleshooting de Windows Server nos seus aspectos de Core, Performance e Failover Cluster. O objetivo desse blog é compartilhar conhecimento e experiências de campo nas tecnologias e serviços relacionados a Windows Server, troubleshooting, novidades e melhores práticas, assim como Microsoft Azure. Interessado em conhecer mais sobre os PFEs no Brasil e quem sabe fazer parte do time!? Esse post de um antigo Mestre é um excelente ponto de partida: https://blogs.technet.com/b/pfelatam/archive/2010/09/23/quempremierfieldengineers.aspx Até breve, diegoalb