Comportamento de failover em clusters de três ou mais nós

O suporte para o Windows Server 2003 termina em 14 de julho de 2015.

A Microsoft terminou o suporte para o Windows Server 2003 em 14 de julho de 2015. Esta alteração afetou as suas atualizações de software e opções de segurança. Saiba o que isto significa para você e como permanecer protegido.

IMPORTANTE: Este artigo foi traduzido por um sistema de tradução automática (também designado por Machine Translation ou MT), não tendo sido portanto traduzido ou revisto por pessoas. A Microsoft possui artigos traduzidos por aplicações (MT) e artigos traduzidos por tradutores profissionais, com o objetivo de oferecer em português a totalidade dos artigos existentes na base de dados de suporte. No entanto, a tradução automática não é sempre perfeita, podendo conter erros de vocabulário, sintaxe ou gramática. A Microsoft não é responsável por incoerências, erros ou prejuízos ocorridos em decorrência da utilização dos artigos MT por parte dos nossos clientes. A Microsoft realiza atualizações freqüentes ao software de tradução automática (MT). Obrigado.

Clique aqui para ver a versão em Inglês deste artigo: 299631
Sumário
Este artigo documenta a lógica por meio do qual grupos falham de um nó para outro quando há 3 ou mais membros de nó de cluster. O movimento de um grupo pode ser causado por um administrador que move um grupo manualmente ou por uma falha de nó ou recurso. Onde o grupo move depende de como a movimentação é iniciada e se a lista de proprietário preferencial é definida.
Mais Informações
Informações sobre a lista de proprietário preferencial são abordadas no arquivo de Ajuda em "Clusters de servidor," incluindo informações sobre planejamento e otimizando os clusters de servidor. Este artigo documenta os quatro cenários possíveis a seguir:
  1. Há uma falha de nó ou recurso e o proprietário preferencial lista está definida.
  2. Há uma falha de nó ou recurso e o proprietário preferencial lista não está definida.
  3. Administrador move manualmente o grupo para "Melhor possível" e a lista de proprietário preferencial é definido.
  4. Administrador manualmente move grupo para "Melhor possível" e a lista de proprietário preferido não está definido.

Cenário 1

Se um nó ou recurso falhar e a lista de proprietário preferenciais tiver sido definida, o serviço de cluster falhará o grupo para o próximo nó disponível na lista de nós. A lista de nós é composta de lista de proprietários preferenciais seguido os nós restantes organizados por sua identificação de nó. A identificação de nó é definida quando um nó ingressa em um cluster ou se um nó é removido ou e adicionado novamente.

Você pode exibir a ordem de identificação de nó examinando o registro na chave \HKEY_LOCAL_MACHINE\Cluster\Nodes.

Por exemplo, suponha que temos um cluster de nó seis e que os nós foram instalados e associados o cluster na seguinte ordem: NodeA, NodeB, NodeC, NodeD NodeE e NodeF. Suponha que um grupo possui NodeA, NodeC e NodeE listados como proprietários preferenciais.

Ter essas informações, a lista de nó para o grupo, em seguida, seria o seguinte:
  1. NodeA - proprietário preferencial número um
  2. NodeC - proprietário preferencial número dois
  3. Proprietário preferencial de nodeE - número três
  4. NodeB - instalado segundo nó
  5. NodeD - instalado quarto nó
  6. NodeF - instalado sexto nó
Nesse cenário, se fosse uma falha de nó ou uma falha de um recurso ocorrer e foram atingido o limite de reinício, todo o grupo falhará para o próximo nó para baixo na lista de nós. Por exemplo, se NodeC contido no recurso que falha, o grupo inteiro falhará para NodeE. Ele não falhará para NodeA mesmo que ele é listado primeiro na lista de proprietário preferencial. Se NodeE falhar, o grupo seria tolerância a falhas para NodeB e não para NodeA.

Cenário 2A

Se um recurso falhar e a lista de proprietário preferido não estiver definida, o grupo de segue uma lista de nós muito aspecto que tinha no cenário 1. A lista de nós é criada somente de identificação do nó. Após uma falha de nó ou recurso, recursos, siga um caminho para baixo, não o nó subseqüente na lista de nós. Quando ela atinge o último nó listado na lista de nós, ele começa com o primeiro nó na lista de nós.
  1. NodeA - instalado primeiro nó
  2. NodeC - instalado segundo nó
  3. NodeE - instalado terceiro nó
  4. NodeB - instalado quarto nó
  5. NodeD - instalado quinto nó
  6. NodeF - instalado sexto nó
Por exemplo, essa lista tem a ordem de instalação de diferentes nós de cluster. Se NodeE falhar, todos os grupos que ele possuía seriam tolerância a falhas para NodeB e não para NodeF.

Cenário 2B

Se um nó falha e a lista de proprietário preferencial não está definida para um grupo no nó, em seguida, um nó disponível será selecionado aleatoriamente para o grupo a ser movida para. Isso distribuirá os grupos entre nós disponíveis.

Cenário 3

Se um administrador de cluster seleciona Melhor possível e opta por Move grupo manualmente e a lista de proprietário preferencial estiver configurada, o grupo será sempre iniciado na parte superior da lista de nós. Como no cenário 1, a lista de nós é composta de lista de proprietário preferencial e a ordem de instalação.
  1. NodeA - proprietário preferencial número um
  2. NodeC - proprietário preferencial número dois
  3. Proprietário preferencial de nodeE - número três
  4. NodeB - instalado segundo nó
  5. NodeD - instalado quarto nó
  6. NodeF - instalado sexto nó
Neste exemplo, quando Melhor possível é selecionada, o grupo sempre tentará mover para NodeA. Se o grupo já estiver em NodeA ou NodeA não está disponível, o grupo tenta mover para NodeC. Se um grupo estiver em NodeD e o administrador decide movê-lo para Melhor possível , o grupo vai para NodeA. Se NodeA, NodeC ou NodeE não está ativo, ou NodeB NodeF será escolhido aleatoriamente.

Cenário 4

Se, como administrador de cluster, você escolher manualmente Move grupo e você selecionar o Melhor possível e a lista de proprietário preferido não está configurada, um nó ativo é escolhido aleatoriamente para hospedar o grupo. Sem a lista de proprietário preferencial configurado, é possível que um grupo pode mover para um nó que já está executando vários outros grupos.

É recomendável que você configure a lista de proprietário preferencial em um cluster de nó grande se a carga entre os nós é significativamente diferente ou se os nós não homogêneos.

Observação A exceção para o comportamento de failover é mencionado aqui é com o grupo que contém o recurso de quorum é chamado de grupo de clusters padrão. O grupo de clusters não segue o comportamento típico de lista do proprietário preferencial. Em vez disso, se o proprietário do recurso de quorum falhar, o novo proprietário será o grupo anterior que possuía o recurso de quorum com êxito.

A propriedade pública AntiAffinityClassNames também pode afetar onde um grupo será failover. Para obter mais informações sobre AntiAffinityClassNames, clique no número abaixo para ler o artigo na Base de dados de Conhecimento da Microsoft:
296799Como configurar o Windows cluster grupos para suporte sobressalente quente
2002 mscs w2kmscs padrão failover

Aviso: este artigo foi traduzido automaticamente

Propriedades

ID do Artigo: 299631 - Última Revisão: 02/10/2009 21:57:32 - Revisão: 8.0

Microsoft Windows Server 2003, Enterprise Edition (32-bit x86), Microsoft Windows Server 2003, Enterprise x64 Edition, Microsoft Windows Server 2003, Datacenter Edition (32-bit x86), Microsoft Windows Server 2003, 64-Bit Datacenter Edition, """Microsoft Windows Advanced Server, Limited Edition"""

  • kbmt kbenv kbinfo KB299631 KbMtpt
Comentários