Como configurar o Windows cluster grupos para suporte sobressalente quente

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

Com a chegada de tamanhos maiores de cluster (quatro e oito nós), as topologias de "A + Hs" se tornar importantes quando o cluster tem um conjunto de "A" nós atualmente ativos e um conjunto de nós "Hs" que são atualmente passivos ou no modo de espera ativo. Os clusters maiores aprimoram as configurações de suporte (e/ativo ou passivo), como a configuração anterior porque as configurações podem reduzir o custo de um ou mais nós espera em um conjunto maior de nós ativos.

Por exemplo, com um cluster de dois nós, o custo de uma configuração ativa e/ou passivo requer duas vezes o hardware para a mesma capacidade, com oito nós executando como um passivo e ativo sete. Hardware adicional aumenta o custo por apenas fifteen por cento.

Clusters do Windows não faz distinção entre os nós durante um failover. Clusters do Windows não altera a diretiva de failover, que se baseia a carga ou os programas que estão executando (e onde esses programas estão sendo executados). Esse comportamento pode dificultar muito gerenciar um nó sobressalente interessante que pode levar a carga quando ocorre uma falha. A única maneira para influenciar a diretiva de failover é alterando as listas de nó possíveis. Como esse comportamento é realizado fora do serviço de cluster de forma assíncrona a outros eventos de cluster (por exemplo, falhas de nó), não há nenhuma garantia de que um programa com êxito pode garantir que o nó sobressalente pode ser escolhido no caso de um failover.

Há programas onde esse comportamento é essencial, por exemplo, Microsoft Exchange 2000, onde o banco de dados back-end do Exchange pode ser particionado e espalhado por um número de nós de cluster. No entanto, Exchange pode colocar como uma carga de rede que no caso de uma falha de nó, não é recomendável para falhar em uma partição para um nó que já está hospedando uma partição diferente do banco de dados. O objetivo dessa melhoria é garantir que o serviço de cluster pode modificar sua diretiva de failover para garantir que, se houver um nó que não tem uma partição atualmente hospedada em-lo, o nó passivo pode ser considerado antes de quaisquer nós ativos que já estiverem hospedando uma partição. Para garantir alta disponibilidade do serviço, se não houver nenhum sobressalentes, ou se por algum outro motivo (como várias falhas) não houver nenhum nó sobressalente, a diretiva de failover pode reverter para o padrão. Em outras palavras, a diretiva de failover não falha serviços se não houver nenhum nó sobressalente está disponível.

A propriedade AntiAffinityClassNames

O grupo de clusters do Windows tem uma propriedade pública nova: AntiAffinityClassNames . Essa propriedade pode conter uma seqüência arbitrária de caracteres. No caso de um failover, se um grupo que está sendo failover tiver uma seqüência que não está vazia na propriedade AntiAffinityClassNames , o Gerenciador de failover pode verificar todos os outros nós. Se houver qualquer nós (que estão na lista possíveis proprietários do recurso) que não hospedam um grupo com o mesmo valor em AntiAffinityClassNames , esses nós são considerados um alvo preferencial para failover. Esse valor pode têm prioridade maior sobre a lista de proprietários preferenciais.

Os dois cenários a seguir demonstram como essa propriedade pode ser usada:

• Em um cluster "A + Hs" que está executando um único programa. Por exemplo, um cluster que está executando o Exchange. Nesse caso, Exchange deve configurar cada grupo que é oferecer suporte a uma partição com a propriedade AntiAffinityClassNames definida para algum valor específicas do Exchange (o mesmo valor para cada grupo), por exemplo, "Exchange". No caso de falha, o Gerenciador de failover pode tentar manter as partições separadas selecionando nós que não hospedam grupos com o mesmo valor AntiAffinityClassNames de "Exchange".
• Em uma consolidação de servidor em que há vários programas que devem ser mantidos separados, se possível. Nesses casos, os grupos que estão representando os vários programas devem ser modificados manualmente com o mesmo valor na propriedade AntiAffinityClassNames .

Afinidade de grupo só pode ser configurada usando a ferramenta de linha de comando, cluster.exe. Um exemplo da sintaxe adequada para o exemplo que consta do primeiro cenário anterior é: Essa sintaxe pode crie a seguinte chave do Registro Reg_Multi_SZ : Observação Você pode usar o exemplo a seguir comando cluster.exe para limpar o valor AntiAffinityClassNames e recorrer ao comportamento padrão: Para obter informações adicionais, clique no número abaixo para ler o artigo na Base de dados de Conhecimento da Microsoft: Ou, procurar por "Server cluster" em arquivo de Ajuda do Windows.