Como configurar o Windows clustering grupos para suporte de reserva quente

Este artigo descreve a capacidade do Windows Server 2003 e Windows Server 2008 de configurar o clustering do Windows para suporte de reserva quente.

Com a chegada de tamanhos maiores de cluster (quatro e oito nós), a topologias "A + Hs" tornam-se importante quando o cluster tem um conjunto de "A" nós que estão activas e um conjunto de nós "Hs" passivos actualmente ou no modo de espera activo. Conjuntos de sectores maiores melhoram as configurações de (e / activo ou passivo) de suporte, tais como a configuração anterior porque as configurações podem reduzir o custo de um ou mais nós em modo de suspensão através de um maior conjunto de nós activos.

Por exemplo, com um cluster de dois nós, o custo de uma configuração activo e/ou passivo requer duas vezes o hardware para a mesma capacidade, com oito nós em execução como sete activo e um passivo. O hardware adicional aumenta o custo apenas de quinze por cento.

Clustering do Windows faz com que não distinção entre os nós durante uma activação pós-falha. Clustering do Windows não altera a política de activação pós-falha, que se baseia a carga ou os programas que estejam a utilizar (e onde estes programas estão em execução). Este comportamento pode tornar muito difíceis de gerir um nó de reserva quente pode demorar a carregar quando ocorre uma falha. A única forma de influenciar a política de activação pós-falha consiste em alterar as listas de nó possíveis. Uma vez que este comportamento é executado fora do serviço de cluster de forma assíncrona para outros eventos de cluster (por exemplo, falhas de nó), não é garantido que um programa com êxito pode garantir que o nó de reserva pode ser seleccionado em caso de uma activação pós-falha.

Existem programas em que este comportamento é essencial, por exemplo, o Microsoft Exchange 2000, onde a base de dados back-end do Exchange pode ser dividido em partições e espalhado por um número de nós de cluster. No entanto, o Exchange pode colocar tal uma carga na rede que no caso de uma falha do nó, não se recomenda a falhar durante uma partição para um nó que já está a hospedar uma partição diferente da base de dados. O objectivo desta melhoria do é para se certificar de que o serviço de cluster pode modificar a política de activação pós-falha para se certificar de que se existir um nó que não tenha uma partição actualmente hospedada no mesmo, o nó passivo pode ser considerado antes de quaisquer nós activos que já estão a hospedar uma partição. Para assegurar a elevada disponibilidade do serviço, se existirem não reserva ou se por alguma razão (por exemplo, várias falhas) existem nós não reserva, a política de activação pós-falha pode reverter para a predefinição. Por outras palavras, a política de activação pós-falha não falha serviços se não existir nenhum nó de reserva está disponível.

A propriedade AntiAffinityClassNames

O grupo de clustering do Windows tem uma nova propriedade pública: AntiAffinityClassNames . Esta propriedade pode conter uma cadeia arbitrária de caracteres. No caso de uma activação pós-falha, se um grupo que está a ser pós-falha tem uma cadeia que não esteja vazia na propriedade AntiAffinityClassNames , o Gestor de activação pós-falha pode verificar todos os outros nós. Se existirem quaisquer nós (que são na lista de possíveis proprietários para o recurso) que não estão a hospedar um grupo com o mesmo valor AntiAffinityClassNames , os nós são considerados um alvo preferencial para activação pós-falha. Este valor pode assumir prioridade mais alta na lista de proprietários preferenciais.

Os dois cenários seguintes demonstram como esta propriedade pode ser utilizada:

• Num cluster "A + Hs" com um único programa. Por exemplo, um cluster com o Exchange. Neste caso, Exchange deverá configurar cada grupo que está a suportar uma partição com a propriedade AntiAffinityClassNames definida para algumas valor específicas (o mesmo valor para cada grupo), por exemplo, "Exchange". No caso de falha, o Gestor de activação pós-falha pode tentar manter as partições afastados seleccionando nós que não estão a hospedar grupos com o mesmo valor AntiAffinityClassNames de "Exchange".
• Consolidação de servidor em que existem vários programas que devem ser mantidos separadamente, se possível. Nestes casos, os grupos são que representa os vários programas devem de ser modificados manualmente com o mesmo valor na propriedade AntiAffinityClassNames .

Afinidade de grupo só pode ser configurada utilizando a ferramenta da linha de comandos, o cluster.exe. Um exemplo da sintaxe correcta para o exemplo listados a partir do primeiro cenário anterior é: Esta sintaxe pode crie a seguinte chave de registo de REG_MULTI_SZ : Nota Pode utilizar o seguinte exemplo comandos cluster.exe para limpar o valor de AntiAffinityClassNames e recorrem ao comportamento predefinido: Para obter informações adicionais, clique no número de artigo que se segue para visualizar o artigo na Microsoft Knowledge Base: Ou, procure "Cluster de servidor" no ficheiro de ajuda do Windows.