Hosts principais e gerenciamento de cluster (cache do Windows Server AppFabric)

Um cluster de cache do Windows Server AppFabric é um grupo dinâmico de servidores que trabalham juntos para fornecer uma cache unificada lógica para os dados do seu aplicativo. Para que isso aconteça, é necessário algum esforço para organizar as operações de cluster entre os hosts de cache. A função de gerenciamento de clusters é responsável por gerenciar os hosts de cache e, finalmente, o cluster de cache.

Dependendo de como você implantar o seu sistema de cache distribuído, há duas opções para o que desempenha a função de gerenciamento de cluster. Se você armazenar seus parâmetros de configuração de cluster em um banco de dados SQL Server, essa instância do SQL Server também poderá ser usada para executar a função de gerenciamento de cluster.

Se você optar por armazenar seus parâmetros de configuração de cluster em uma pasta compartilhada da rede, a função de gerenciamento de cluster será sempre executada por hosts de cache especiais, denominados "hosts principais". Os hosts principais executam as mesmas tarefas que outros hosts de cache não designadas como principais, mas eles têm a responsabilidade adicional de trabalhar com outros hosts principais para realizar a função de gerenciamento de cluster.

A tabela a seguir mostra como sua escolha no momento da instalação afeta suas opções de gerenciamento de cluster. Para obter mais informações sobre como escolher qual dessas opções de configuração é a correta para você, consulte Opções de armazenamento de configuração de cluster (Cache do Windows Server AppFabric).

Deveres da Função de Gerenciamento de Clusters

Há dois parâmetros de configuração principais que determinam o funcionamento do cluster no que diz respeito ao gerenciamento do cluster:

• leadHostManagement: Esta configuração em nível de cluster determina o que desempenhará a função de gerenciamento de cluster. Quando for "verdadeiro", os hosts principais desempenharão a função de gerenciamento de cluster. Se você optou por armazenar seus parâmetros de configuração de cluster em uma pasta compartilhada na rede, "verdadeiro" será o único valor válido para esta configuração. "Falso" indica que o SQL Server ou um provedor personalizado desempenhará a função de gerenciamento de cluster. Ao usar o SQL Server ou um provedor personalizado para armazenar os parâmetros de configuração de cluster, você pode definir essa configuração como "verdadeiro" e deixar que os hosts principais desempenhem a função de gerenciamento de cluster.

• leadHost: Esta configuração de cache em nível host determina quais hosts de cache serão os principais quando os hosts principais desempenharem a função de gerenciamento de cluster. Mesmo que o SQL Server desempenhe a função de gerenciamento de cluster, o programa de instalação designará os hosts principais, caso você altere posteriormente a configuração leadHostManagement.

Para obter mais informações sobre como alterar essas configurações, consulte Definir a função de gerenciamento de cluster e as designações do host principal (cache do Windows Server AppFabric).

Com essas duas propriedades, existem quatro casos possíveis para saber como um host de cache se comportará. Esses casos são descritos na tabela a seguir.

Quando hosts principais desempenham a função de gerenciamento de clusters

Quando as configurações leadHostManagement e leadHost forem true, o host de cache é elevado a um nível de maior responsabilidade no cluster e designado como um host principal. Além das operações normais de host de cache relacionadas à cache de dados, o host principal também trabalha com outros hosts principais para gerenciar as operações de cluster.

Quando um host principal falha

Para o cluster de cache permanecer disponível, a maioria dos hosts principais devem permanecer disponíveis. Esse risco é maior nos clusters pequenos do que nos grandes, pois são necessárias menos falhas do servidor para fazer com que o cluster se desligue.

Por exemplo, considere o cluster de cache de seis servidores, indicado no diagrama a seguir. Neste exemplo, os hosts principais desempenham a função de gerenciamento de cluster e dois hosts de cache foram designados como hosts principais.

Se algum dos hosts de cache normais do cluster falhar, o cluster pode continuar funcionando. Os dados sobre os hosts que não são principais seriam perdidos (supondo que a alta disponibilidade não estava ativada), mas o restante do cluster poderia continuar funcionando e armazenando dados. Na verdade, o cluster pode manter-se em funcionamento se perder os quatro hosts de cache que não foram designados como hosts principais.

Se apenas um desses hosts principais falhar, todo o cluster de cache se desligará porque a maioria dos hosts principais não estaria mais em execução. Para atenuar esse problema, você tem a opção de designar mais hosts principais.

Designando mais hosts principais

O Assistente de Configuração do AppFabric usa a lista suspensa Cluster Size para ajudar a determinar o número adequado de hosts principais que deve haver no cluster. Se você quiser de designar mais hosts principais após a instalação, isso também é possível. No entanto, é importante considerar que a atribuição de muitos hosts principais também pode ser um problema:

• Deve sempre haver uma maioria de hosts principais disponíveis para que o cluster de cache permaneça funcionando. Quanto mais hosts forem designados principais, menos falhas de servidor o cluster será capaz de suportar e manter-se em operação.

• Em clusters pequenos, onde uma ou duas falhas do host principal podem fazer com que o cluster falhe, recomendamos que você designe mais hosts principais.

• Em clusters grandes, de cinco a sete hosts principais devem bastar para garantir que um cluster na faixa de 50 servidores de cache continue respondendo.

Para obter mais informações sobre como alterar designações de hosts principais, consulte Definir a função de gerenciamento de cluster e as designações do host principal (cache do Windows Server AppFabric).

Quando o SQL Server executa a função de gerenciamento de clusters

Quando a configuração leadHostManagement do cluster for false, independentemente da configuração leadHost, cada host de cache só exerce suas responsabilidades normais de host não-principal relacionadas ao armazenamento de dados em cache. Neste cenário, a instância do SQL Server usada para armazenar os parâmetros de configuração de cluster também é usada para executar a função de gerenciamento de cluster.

Quando ocorre uma falha no servidor

Para o cluster permanecer disponível quando o SQL Server executa a função de gerenciamento de cluster, um ou mais hosts de cache devem ser capazes de acessar o banco de dados SQL Server.

Por exemplo, considere o cluster de cache de seis servidores, indicado no diagrama a seguir.

Neste exemplo, o SQL Server está executando a função de gerenciamento de cluster, e os seis hosts de cache pode dedicar seus recursos ao acesso dos clientes de cache aos dados.

Se qualquer um dos hosts de cache do cluster falhar, os dados nesses servidores se perderão (supondo que a alta disponibilidade não esteja ativada), mas o cluster continua a funcionar. Os dados nos outros hosts de cache continuam disponíveis para os clientes de cache. Na verdade, o cluster pode continuar a funcionar se perder cinco dos seis hosts de cache.

Se o SQL Server falhar, todo o cluster se desligará em alguns minutos. Para atenuar esse problema, recomendamos enfaticamente que você use o O Cluster de Failover do Microsoft Windows Server 2008 (https://go.microsoft.com/fwlink/?LinkId=130692) para hospedar um recurso "agrupado" de banco de dados para o local de armazenamento do cluster de cache e para a função de gerenciamento de cluster.

Consulte também

Conceitos

Diagrama de arquitetura física de cache do Windows Server AppFabric
Diagrama de arquitetura lógica de cache do Windows Server AppFabric
Definições de configuração de cluster (Cache do Windows Server AppFabric)
Definir a função de gerenciamento de cluster e as designações do host principal (cache do Windows Server AppFabric)

  2011-12-05