Windows Server 2008 R2: Cenários de solução de problemas dos clusters de failover
A configuração de clusters de failover no Windows Server pode ajudar a garantir uma disponibilidade quase que totalmente consistente. Apresentamos aqui diversos cenários potenciais de solução de problemas.
John Marlin
No mês passado, eu olhei alguns dos problemas mais comuns com o cluster de Failover do Windows Server 2008 R2 e analisou como com precisão solucionar esses problemas.
Lembre-se a política de suporte atual é que, para uma solução Windows Server 2008 ou o cluster de Failover do Windows Server 2008 R2 ser considerado uma solução oficialmente suportada pelo Microsoft cliente suporte serviços (CSS), ele deve atender a seguintes critérios:
- Todos os componentes de hardware e software devem satisfazer as qualificações para receber um logotipo "Certified for Windows Server 2008 r2".
- A solução totalmente configurada deve passar no teste de validação no gerenciamento de Cluster de Failover.
Aqui estão vários cenários que podem ajudar a acelerar ou informar seus próximos esforços de solução de problemas. Estas representam alguns dos problemas mais comuns em Clusters de Failover com suporte do Windows 2008 R2, bem como as etapas que você precisará fazer para resolvê-los.
Cenário 1: Nós estávamos fazendo nosso scrubbing mensal, objetos do Active Directory e excluída inadvertidamente o objeto de nome de Cluster. Tentamos criar um novo, mas ele não fica online.
O objeto de nome de Cluster (CNO) é muito importante, porque é a identidade comum do Cluster.
Ele é criado automaticamente pelo Assistente para criação de clusters e tem o mesmo nome como o Cluster. Através desta conta, ele cria outros objetos de computador Virtual do Cluster (VCOs) como você configurar novos serviços e aplicativos no Cluster. Se você excluir o CNO ou ter permissões afastado, ele não é possível criar outros objetos conforme exigido pelo Cluster até que ele for restaurado ou as permissões corretas forem repostas.
Tal como acontece com todos os outros objetos no Active Directory, há uma objectGUID associado. Isto é como o Cluster de Failover sabe que você está lidando com o objeto correto. Se você simplesmente criar um novo objeto, um novo objectGUID será criado também. O que precisamos fazer é restaurar o objeto correto para que o Cluster de Failover possa continuar com suas operações normais.
Na solução de problemas, precisamos saber duas coisas do recurso de Cluster. A partir do Windows PowerShell, execute o comando:
Get-ClusterResource "Nome do Cluster" | Get-ClusterParameterCreatingDC, objectGUID
Isso irá recuperar os valores necessários. O primeiro parâmetro que nós queremos é o CreatingDC. Quando o Cluster de Failover cria o CNO, verificamos o controlador de domínio (DC) no qual ele foi criado. Para qualquer atividade que precisamos fazer com o Cluster (criar VCOs, trazem nomes on-line e assim por diante), nós sabemos que para ir a este controlador de domínio para obter o objeto e a segurança. Se não for encontrado em que DC ou que a DC não estiver disponível, nós vai procurar outras que responder, mas sabemos ir aqui pela primeira vez.
O segundo parâmetro é o objectGUID para garantir que estamos falando de objeto correto. Para nosso exemplo, o nome do Cluster é CLUSTER1, o DC criando é DC1 e o objectGUID é 1a3cf049cf79614ebd94670560da6f04, da seguinte forma:
Objeto nome valor
------ ---- -----
Cluster de nome CreatingDC \\DC1.domain.com
Cluster nome ObjectGUID1a3cf049cf79614ebd94670560da6f04
Precisamos efetuar logon no computador DC1 e executar o Active Directory usuários e computadores. Se não houver um objeto atual CLUSTER1, nós pode verificar para ver se ele tem os atributos apropriados. Uma nota sobre o assunto é a tela que você verá. Editor de atributo de diretório ativo inicialmente não vai mostrar-lhe o GUID mostrado aqui, como ele não é exibi-lo em formato hexadecimal.
O que você inicialmente vamos ver é 49f03c1a-79cf-4e61-bd94-670560da6f04. O formato hexadecimal faz um switch e funciona em pares, que é um pouco confuso. Se você tomar os primeiro oito pares de números e fazer o switch, 49f03c1a torna-se 1a3cf049. Alternando os próximos dois pares, 79cf torna-se cf79 e, em seguida, 4e61 torna-se 614e. Os pares restantes permanecem o mesmo.
Você deve trazer as propriedades objectGUID no editor de atributos para vê-lo no formato hexadecimal que vê o cluster de Failover. Porque não é o objeto apropriado, nós deve primeiro excluir o objeto para levá-la fora da imagem para restaurar um bom.
Há várias maneiras de restaurar o objeto. Poderíamos utilizar um Active Directory restaurar, um utilitário como o ADRESTORE ou o novo Active Directory Lixeira (executando um controlador de domínio do Windows 2008 R2 com um esquema atualizado). Usar o novo Active Directory Lixeira facilita muito as coisas e é o processo mais perfeito para a restauração de objetos excluídos do Active Directory.
Com a Active Directory Lixeira, nós pode Pesquisar para localizar o objeto para restaurar com o comando do Windows PowerShell:
Get-ADObject –filter 'isdeleted –eq $true –and samAccountName –eq "CLUSTER1$"' –includeDelectedObjects –property * | FormatListsamAccountName,objectGUID
Esse comando irá procurar qualquer objeto excluído com o nome CLUSTER1 da Lixeira do Active Directory. Ele nos dará o nome da conta e objectGUID. Se houver vários itens, ele irá mostrar todos eles. Quando vamos ver o que nós queremos, nós seria exibi-lo como este:
samAccountName : CLUSTER1$
objectGUID:49f03c1a-79cf-4e61-bd94-670560da6f04
Agora precisamos restaurá-lo. Depois podemos excluir um incorreto, o comando do Windows PowerShell para restaurá-lo seria:
Restauração-ADObject –identity 49f03c1a-79cf-4e61-bd94-670560da6f04
Isto irá restaurar o objeto no mesmo local (unidade organizacional ou unidade organizacional) e manter as mesmas permissões e senha da conta de computador conhecido pelo Active Directory.
Este é um dos benefícios do Active Directory Lixeira quando comparado a algo como um utilitário como o ADRESTORE. Usando o ADRESTORE, você teria que redefinir a senha, movê-lo para a UO apropriada, reparar o objeto no cluster de Failover e assim por diante.
Com o Active Directory Lixeira, nós simplesmente colocar online o recurso de nome de Cluster. Isso também é uma opção melhor do que fazer uma restauração do Active Directory, especialmente se houve novos objetos de usuário do computador criados, se não houver antigos que já não existem e teriam de ser eliminado novamente, e assim por diante.
Cenário 2: Meu Volumes Compartilhados do Cluster Mostrar "Redirecionado acesso" no gerenciamento de Cluster de Failover. Como podemos corrigir isso?
Em primeiro lugar, vamos recapitular rapidamente a definição de Volumes Compartilhados do Cluster (CSVs). CSVs simplificam a configuração e o gerenciamento do Hyper-V virtual machines (VMs) em Clusters de Failover. Com CSV em um Cluster de Failover que executa o Hyper-V, várias VMs podem usar o mesmo LUN (disco), ainda failover (ou mover de um nó para o nó) independentemente umas das outras. O CSV fornece maior flexibilidade para os volumes de armazenamento em cluster. Por exemplo, você pode manter arquivos de sistema separados dos dados para otimizar o desempenho do disco, mesmo se os arquivos de sistema e os dados estão contidos dentro de arquivos de disco rígido virtual (VHD).
Nas propriedades para todos os adaptadores de rede que carregam a comunicação com o cluster, certifique-se de "Cliente para redes Microsoft" e "Arquivo e impressora compartilhamento para redes Microsoft" estão habilitados para oferecer suporte a Server Message Block (SMB). Isso é necessário para CSV. O servidor está executando o Windows Server 2008 R2, portanto, ele fornece automaticamente a versão do SMB que é exigido pela CSV, que é SMB2. Haverá apenas uma rede de comunicação CSV preferencial, mas permitindo que essas configurações em várias redes ajuda o Cluster têm flexibilidade para responder a falhas.
Redirecionado meios de acesso, todas as operações de e/S estão indo para ser "redirecionado" através da rede para outro nó que tenha acesso à unidade. Existem basicamente três razões pelas quais um disco está no modo de acesso Redirecionado:
- Você colocou manualmente no modo redirecionar
- Há um backup em andamento
- Existem problemas de hardware, e o nó não pode acessar diretamente a unidade
No nosso cenário, nós já descartou opção 1 e 2 de opção. Isso nos deixa com opção 3. Se pensarmos no Log de eventos do sistema, queremos ver o evento "ID do evento: 5121" de cluster de Failover.
Aqui é a definição dessa entrada de registro: VolumeCSV compartilhado do Cluster ' disco de Cluster x' já não é acessível directamente a partir deste nó de cluster. Acesso i/O será redirecionado para o dispositivo de armazenamento na rede através do nó que possui o volume. Isso pode resultar em degradação do desempenho. Se redirecionada acesso está ativado para este volume, por favor, desative-o. Se acesso redirecionado estiver desligado, por favor, solucionar problemas de conectividade do nó para o dispositivo de armazenamento e I/O irá retomar a um estado saudável depois de conectividade para o dispositivo de armazenamento é restabelecida.
Tendo essa postura, nós também ficaria direito antes deste evento para qualquer evento relacionado com o hardware. Assim nós olharia para eventos como 9, 11 ou 15 que aponte para um problema de hardware ou comunicação. Nós ficaria no gerenciamento de disco para ver se poderia ver fisicamente no disco. Na maioria dos casos, vamos ver alguns outros erros. Uma vez que podemos corrigir o problema com o back-end, trazemos o disco deste modo.
Tenha em mente que o CSV permanecerão em execução, desde que pelo menos um nó pode se comunicar com a armazenamento conectado à rede. É por isso que seria em um modo "redirecionado". Todas as gravações na unidade são enviadas para o nó que pode se comunicar e o Hyper-V VMs vai continuar em execução. Pode haver um impacto sobre as VMs de desempenho, mas eles vão continuar a executar. Assim nós nunca realmente vai ser de produção, que é uma coisa boa.
Cenário 3: Eu criei apenas um novo Windows 2008 R2 Failover Cluster para uso com VMs altamente disponíveis. Eu configurei as unidades para CSV, mas quando eu tentar acessá-los, penduram o Explorer e o gerenciamento de disco. Não consigo copiar minhas VHDs na unidade para obter este curso.
Há apenas um "verdadeiro" dono da unidade e é chamado o nó do coordenador. Qualquer tipo de gravações de metadados para a unidade seria feito por este nó somente.
Quando você abre o Explorer ou gerenciamento de disco, ele vai querer abrir a unidade para que ele possa fazer qualquer gravações de metadados (se é essa a intenção). Por causa disto, qualquer unidade não possui será redirecionada na rede para o nó de coordenador. Isso é diferente do que a unidade está sendo em "Redirecionado acesso".
Na solução de problemas, gerenciamento de Cluster de Failover irá mostrar a unidade como on-line. Então, primeiro que você deve olhar para ver quais eventos são registrados. No Log de eventos do sistema, você pode ver esses eventos de cluster de Failover:
Identificação do evento: 5120
Volume compartilhado do cluster ' disco de Cluster x' já não está disponível neste nó por causa de 'STATUS_BAD_NETWORK_PATH(c00000be)'. Toda i/O será temporariamente na fila até que um caminho para o volume é restabelecido.
Identificação do evento: 5142
Volume compartilhado do cluster ' disco de Cluster x' já não é acessível a partir deste nó de cluster por causa de erro 'ERROR_TIMEOUT(1460)'. Por favor, solucionar problemas de conectividade de rede e conectividade do nó para o dispositivo de armazenamento.
Os logs de eventos estão expirando tentando obter através da rede para o nó de coordenador. Então, você iria olhar para ver se há outros erros no Log de eventos sistema que apontaria para conectividade de rede entre os nós. Se não houver, você precisa para resolvê-los. Coisas como uma placa de rede com defeito ou com deficiência podem causar isso.
Em seguida, você iria querer verificar a conectividade de rede básica entre os nós. O que você precisa primeiro verifique se está a rede através da qual o tráfego CSV está viajando. A forma como o cluster de Failover escolhe a rede para usar para CSV é pelo valor mais alto de métrica. Isso é diferente de como o Windows identifica a rede.
O adaptador de tolerância de falhas de rede de Cluster de Failover (NETFT) tem seu próprio sistema métrico usa internamente. Todas as redes que detecta ter um gateway padrão e será dado a métrica de 10000, 10100, como ele vai junto. Todas as redes que não têm um começo de gateway padrão em 1000, 1100 e assim por diante. Usando o Windows PowerShell, você pode usar o comando Get-ClusterNetwork | Nome do FT, métrica, papel para ver como o adaptador NETFT definiu-los. Você iria ver algo semelhante a:
Métrica de nome
-------------------
Gestão 10100
CSV tráfego 1000
LAN-WAN 10000
Particular 1100
Com estes quatro redes, a rede eu identifiquei como o CSV é chamado tráfego CSV. O endereço IP que estou usando para ele 1.1.1.1 Node1 e 1.1.1.2 para Nó2, assim que eu tentaria conectividade de rede básica com PING entre os endereços de IP.
A próxima etapa é tentar uma conexão SMB usando os endereços de IP. Este é apenas o que o cluster de Failover está indo fazer. Um simples \\1.1.1.1 NET VIEW será suficiente para ver se há uma resposta. O que você deve receber de volta é uma lista de ações ou uma mensagem: "Não há nenhum entradas na lista".
Isso indica que você poderia fazer uma ligação a essa parte. No entanto, se você receber a mensagem "erro de 53 do sistema. O caminho de rede não foi encontrado,"Isso indica um problema de configuração de TCP/IP com a placa de rede.
Tendo "Cliente para redes Microsoft" e "Arquivo e impressora compartilhamento para redes Microsoft" ativada na placa de rede são obrigados a usar CSV. Se não forem, você terá esse problema de pendurar Explorer. Selecione esses e você está pronto para ir.
No Windows 2003 Server Cluster e abaixo, desmarcar estas opções foi o procedimento recomendado. Isso já não é o caso de seguir em frente e você pode ver como ele pode quebrar.
Outros fatores
Existem alguns outros fatores que você precisará considerar. Se os nós de Cluster está apresentando falhas de recurso Host subsistema (RHS), primeiro você deve pensar sobre a natureza da RHS e o que está fazendo. RHS é o componente de Cluster de Failover que faz um monte de saúde recurso verificação para garantir que tudo está funcionando. Para um endereço de IP, ele irá garantir é na pilha de rede e que responde. Para discos, ele tentará se conectar à unidade e fazer um comando DIR.
Se você tiver uma falha RHS, você verá 1230 de IDs de Log de eventos do sistema e 1146. No caso de 1230, ele realmente irá identificar os recursos e o recurso DLL usa. Se deixa de funcionar, isso significa que o recurso não está respondendo que deve e pode ser bloqueado. Se isso falhar em um recurso de disco, você iria querer olhar para erros relacionados ao disco ou latências de disco. Executar um Monitor de desempenho seria um bom lugar para começar. Atualizar drivers/firmware de cartões ou back-end pode ser algo a considerar também.
Você também vai estar fazendo algum usuário detecções de modo. O cluster de failover realiza monitoramento da integridade do modo kernel para um processo de modo de usuário para detectar quando o modo de usuário torna-se não responder ou congelado. Para recuperar essa condição, cluster será bug-seleção caixa. Em caso afirmativo, você veria uma parada 0x0000009E. Solucionando problemas isso implicaria a revisar o arquivo de despejo cria para procurar trava. Você também deseja ter executando o Monitor de desempenho e olhar para qualquer coisa que aparecem como pendente, vazamentos de memória e assim por diante.
O cluster de failover é dependente no Windows Management Instrumentation (WMI). Se você está tendo problemas com o WMI, você vai ter problemas com o cluster de Failover (Criando e adicionando nós, migração e assim por diante). Executar verificações de WMI, tais como o WBEMTEST.EXE, ou até mesmo remotos scripts WMI.
Um script, que você pode tentar do Windows PowerShell é (onde Nó1 é o nome do nó real):
Get-wmiobjectmscluster_resourcegroup-computador NODE1 - namespace "root\mscluster"
Isso vai fazer uma conexão WMI para o Cluster e dar-lhe informações sobre os grupos.
Se isso falhar, você tem alguns problemas WMI. Os serviços de WMI pode ser interrompidos, assim você pode precisar para reiniciá-los. O repositório WMI também pode ser corrompido (uso do Windows PowerShell comando winmgmt /salvagerepository para ver se é consistente), e assim por diante.
Aqui estão alguns pontos de solução de problemas para lembrar:
- Validar, validar, validar. Use validação de Cluster para solução de problemas. Usá-lo para as práticas recomendadas. Usá-lo quando são feitas alterações em seu sistema.
- Tudo é dirigido para o Windows PowerShell. Se você não sabe ainda, começar a brincar com ele.
- Porque nós somos dependentes de objetos do Active Directory, proteja-se. Habilitar a Lixeira do Active Directory e proteger objetos contra exclusão acidental.
- Ao solucionar problemas de CSVs, não assuma sempre é um problema de hardware.
- Na solução de problemas, dar um passo para trás e olhar para tudo o que pode ser afetado. Inicie seu foco a diminuir.
O cluster de failover é projetado para detectar, recuperar e relatar problemas. O fato de que o Cluster está lhe dizendo que é ou foi que um problema não significa que o Cluster deixá-lo. Como algumas pessoas dizem: "Não atire o mensageiro".
.jpg)
**John Marlin**é um engenheiro de escalonamento de suporte sênior no grupo de suporte técnico comercial. Ele está na Microsoft há mais de 19 anos, com os últimos 14 anos com foco em servidores de Cluster.