Considerações sobre manutenção do servidor de cache (cache do Windows Server AppFabric)

Os recursos de cache do Windows Server AppFabric dependem de servidores físicos para oferecer suporte ao cluster de cache. Todos os servidores exigem manutenção em algum momento e quantas vezes essa manutenção exigir reinicialização do servidor. Este tópico descreve as considerações importantes para minimizar ou evitar o tempo de inatividade do cluster de cache quando as reinicializações do servidor forem necessárias para manutenção.

Reinicializando servidores

Quando implantado em um único servidor, o local de armazenamento de configuração do cluster será um único ponto de falha para o cluster de cache. Se os hosts principais desempenharem a função de gerenciamento de cluster, reinicializar muitos dos servidores de cache errados também desativará o cluster de cache.

Local de armazenamento de configuração do cluster

O local de armazenamento de configuração do cluster pode ser um banco de dados do SQL Server ou uma pasta de rede compartilhada. Sem acesso a ele, o cluster de cache não pode ser executado por mais de alguns minutos. Antes de reinicializar o servidor que hospeda o SQL Server ou servidor de arquivos, desligue o cluster de cache com o comando Stop-CacheCluster. Esse comando interromperá os serviços de host de cache do Windows em todos os servidores de cache na ordem adequada. Para obter mais informações sobre o local de armazenamento de configuração de cluster, consulte Opções de armazenamento de configuração de cluster (Cache do Windows Server AppFabric).

Servidor de cache

Como regra geral, é recomendável reinicializar apenas um servidor de cache por vez. Nenhum procedimento especial será necessário quando você desligar um servidor para uma reinicialização. Se você deseja interromper somente o serviço de hospedagem de cache do Windows, use o comando Stop-CacheHost. Não há suporte para a interrupção do serviço com o console de serviços do Windows. Após uma reinicialização, use o comando Start-CacheHost para permitir que os servidores de host de cache do Windows reingressem no cluster. Para obter mais informações, consulte Usando o Windows PowerShell para gerenciar os recursos de cache do Windows Server AppFabric.

Quando os hosts principais estão desempenhando a função de gerenciamento de cluster, para que o cluster de cache continue disponível, a maioria dos hosts principais deverá continuar disponível. Se esse for o caso no seu cluster, reinicialize somente uma pequena minoria de hosts principais por vez para evitar o desligamento do cluster de cache. Os hosts secundários podem ser reinicializados a qualquer momento sem afetar o estado de execução do cluster de cache. Para obter mais informações sobre hosts principais, consulte Hosts principais e gerenciamento de cluster (cache do Windows Server AppFabric).

Observação

O comando Stop-CacheHost não interromperá um serviço de host de cache do Windows se estiver desempenhando a função de gerenciamento de cluster e interromper o host de cache a função desligará todo o cluster.

Se o SQL Server desempenhar a função de gerenciamento de cluster, você não precisará considerar se o host de cache é um host principal ou não. O cluster pode continuar a executar somente com um host de cache.

Quando o serviço de host de cache do Windows em um servidor de cache for interrompido, todos os dados na memória do computador serão liberados. Para ajudar a separar aplicativos dessa perda de dados devido às reinicializações do servidor, habilite o recurso de alta disponibilidade nos caches nomeados. Isso tem algum impacto no desempenho, mas a sobrecarga adicional pode superar os custos de recarregar o cache.

Para que o recurso de alta disponibilidade ajude a afastar seu aplicativo da falha (ou interrupção) de um host de cache, pelo menos três hosts de cache devem ser membros do cluster de cache. Isso se deve a um forte requisito de consistência informando que sempre deve haver duas cópias de um objeto em cache ou região em um cache habilitado para alta disponibilidade. Para manter duas cópias de um cache ou região, um cache habilitado para alta disponibilidade requer pelo menos dois hosts de cache para funcionar. Para obter mais informações, consulte Alta disponibilidade (Cache do Windows Server AppFabric).

Além do número mínimo de servidores necessários para manter o cluster em execução, também é importante considerar que a memória precisa de seu aplicativo. As necessidades de cache do aplicativo provavelmente não são alteradas somente porque um servidor de cache é reinicializado. É importante que servidores de cache suficientes continuem em execução para oferecer suporte às necessidades de cache do aplicativo.

Recomendações de administração

Para simplificar a sequência de reinicialização, é recomendável usar um banco de dados do SQL Server para armazenar suas definições de configuração e fazer com que essa instância do SQL Server desempenhe a função de gerenciamento do cluster. Dessa forma, não importa qual dos servidores de cache será reinicializado durante a manutenção.

Para otimizar a disponibilidade do cluster de cache, é recomendável usar o Cluster de Failover do Windows Server 2008 para hospedar um banco de dados "clusterizado" ou recurso de pasta no local de armazenamento de configuração do cluster de cache. Com um local de armazenamento clusterizado, você pode usar mais de um servidor do Windows Server 2008 para hospedar o local de armazenamento de configuração "clusterizado", que permite a você reinicializar um nó de Cluster de Failover em um momento sem afetar a disponibilidade do local de armazenamento de configuração do cluster de cache.

Quando possível, aumente seu cluster de cache adicionando mais servidores de cache do que seu aplicativo precisa nesse momento. Isso permitirá que você reinicialize um número pequeno de servidores de cache sem qualquer impacto material ao desempenho do cluster de cache.

Ações que requerem tempo de inatividade

Várias ações requerem tempo de inatividade do cluster de cache. O tema comum para todas as ações listadas abaixo é que elas requerem alterações na configuração de cluster do cache.

  2011-12-05