Hosts principais e gerenciamento de cluster (Cache do AppFabric 1.1)

Um cluster de cache do Microsoft AppFabric 1.1 para Windows Server é 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.

Há duas opções principais para como gerenciamento de cluster de cache é executado. A primeira opção é esta função ser executada pelos hosts de cache especiais, denominados hosts principais. Isso é conhecido como "onloading". A segunda opção é essa função ser executada pelo SQL Server. Isso também é chamado de "offloading", porque a responsabilidade é transferida para o SQL Server em vez do cluster de cache em si.

Se você armazenar os dados de configuração do cluster de cache em uma pasta compartilhada na rede (XML), use o onloading com o gerenciamento de host principal. Observe que os hosts principais executam as mesmas tarefas de cache que outros hosts de cache não designados como principais, mas eles têm a responsabilidade adicional de trabalhar com outros hosts principais para realizar a função de gerenciamento de cluster.

No Windows Server AppFabric 1.0, o padrão para um cluster de cache que armazenava os dados de configuração no SQL Server era descarregar a função de gerenciamento do cluster de cache no SQL Server. Isso mudou no AppFabric 1.1. O padrão para novos clusters de cache é usar sempre onloading em locais em que os hosts principais gerenciam o cluster de cache. Isso melhora a disponibilidade do cluster de cache, porque o cluster de cache pode se tornar parcialmente funcional se o arquivo de configuração ficar indisponível, seja esse armazenamento em um arquivo XML ou em um banco de dados SQL Server. Observe que as operações que inspecionam ou alteram a configuração do cluster de cache não estarão disponíveis durante essa situação.

Ainda é possível descarregar todas as responsabilidades de gerenciamento do cluster de cache no SQL Server. Em primeiro lugar, é preciso criar manualmente o cluster de cache com o comando New-CacheCluster e definir o parâmetro Offloading como "true". O outro requisito é que o Provider deve ser o SQL Server (System.Data.SqlClient).

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.

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 mudar essas configurações, consulte Definir a função de gerenciamento de cluster e as designações do host principal (AppFabric 1.1).

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

Você pode designar hosts principais adicionais após a instalação. 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 mudar essas designações de host principal, consulte Definir a função de gerenciamento de cluster e as designações do host principal (AppFabric 1.1).

Mudanças no Microsoft AppFabric 1.1 para Windows Server

Para aumentar a disponibilidade do cluster de cache, o AppFabric 1.1 mudou o processo usado para designar hosts principais padrão. O AppFabric 1.1 ajustará automaticamente cada host do cache adicionado ao cluster de cache como um host principal até um máximo de sete hosts principais. Você ainda poderá designar outros hosts principais usando o comando Set-CacheHostConfig com o parâmetro IsLeadHost definido como "true". Também é possível remover um host de cache da função de host principal definindo o IsLeadHost como "false".

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

Quando o cluster de cache é criado com a função de offloading habilitada, a configuração leadHostManagement é false. Nesse cenário, independentemente da configuração do leadHost, cada host de cache só exerce suas responsabilidades normais de host não-principal relacionadas ao armazenamento de dados em cache. A instância do SQL Server usada para armazenar as definições 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 (offloading), 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 AppFabric (Cache do AppFabric 1.1)
Diagrama de arquitetura lógica de cache do AppFabric (Cache do AppFabric 1.1)

  2012-03-05