Atualizando servidores de cache

Um cluster de cache do Microsoft AppFabric 1.1 para Windows Server é constituído de um ou mais servidores que trabalham juntos para fornecer um cache em memória unificado. Há ocasiões em que você deve atualizar um ou mais dos servidores em um cluster de cache e essas atualizações podem exibir uma reinicialização. Esta seção apresenta orientações do cluster de cache para este cenário de aplicação de patch.

Manutenção agendada

A solução mais fácil para este problema é agendar uma janela de manutenção para executar atualizações em todos os servidores de cache. Neste cenário, você interrompe o cluster de cache com o comando Stop-CacheCluster, atualiza os computadores e, em seguida, inicia o cluster de cache com o comando Start-CacheCluster. Isso funciona melhor com caches que têm períodos de tempo de menor demanda. Se os aplicativos clientes tiverem uma demanda contínua para o cluster de cache, você poderá considerar outras opções em que o cluster de cache permanecerá ativo durante as atualizações.

Atualizações sequenciais do servidor de cache

É possível atualizar servidores de cache individuais enquanto o cluster de cache permanece em execução. Isso exige que o cluster de cache contenha, no mínimo, dois hosts de cache. O processo básico consiste nas seguintes etapas:

  1. Interrompa um dos servidores no cluster com o comando Stop-CacheHost. Se possível, use a opção Graceful para mover os dados em cache para fora do host de cache antes de pará-lo.

  2. Atualize e reinicialize esse servidor.

  3. Inicie o servidor usando o comando Start-CacheHost.

  4. Repita as etapas em cada servidor de cache sequencialmente.

Embora essas etapas sejam diretas, existem várias considerações abordadas nas seções a seguir.

Atualizando hosts principais

A função de gerenciamento de clusters existe para gerenciar com êxito os hosts de cache em um cluster de cache. Se você usar o provedor XML para armazenar as definições de configuração do cluster de cache, essa função será executada designando alguns dos hosts de cache como hosts principais. Para que o cluster de cache permaneça funcionando, a maioria dos hosts principais deve estar em execução. Isso afeta sequencialmente a atualização dos servidores de cache. Considere o cluster de cache dos dois servidores a seguir.

Nome do Host É Host Principal?

CacheServer1

Sim

CacheServer2

Não

Neste exemplo, CacheServer1 é o host principal no cluster de cache de dois nós. Como a maioria dos hosts principais deve permanecer em execução, você não pode interromper o CacheServer1 sem interromper o cluster de cache. Neste exemplo, não ajuda tornar os dois servidores os hosts principais, pois desativar um dos servidores não deixará a maioria dos hosts principais em execução. Para solucionar este problema, você pode adicionar outro servidor de host de cache e tornar todos eles hosts principais com os comandos Export-CacheClusterConfig e Import-CacheClusterConfig. Para obter mais informações sobre como alterar os hosts principais designados, consulte Definir a função de gerenciamento de cluster e as designações do host principal. Considere o cluster de cache após essas alterações.

Nome do Host É Host Principal?

CacheServer1

Sim

CacheServer2

Sim

CacheServer3

Sim

Nesta nova configuração, os três servidores são hosts principais. Agora é possível desativar um servidor de cache de cada vez para executar as atualizações.

Observe que o provedor System.Data.SqlClient não se depara com este problema, pois o SQL Server executa a função de gerenciamento de cluster, em vez dos hosts principais. Para obter mais informações sobre hosts principais, consulte Hosts principais e gerenciamento de cluster.

Atualizando hosts de cache com caches que usam alta disponibilidade

A alta disponibilidade cria cópias secundárias de itens armazenados em cache em outro host de cache. Se o host de cache primário ficar indisponível, o item armazenamento em cache será fornecido pelo host de cache secundário. Portanto, os dados armazenados em cache não são perdidos. Para obter mais informações sobre este recurso, consulte Alta disponibilidade. Por definição, a alta disponibilidade exige que, pelo menos, três servidores estejam presentes no cluster de cache. O item armazenado em cache pode existir em um servidor, ter uma cópia secundária em outro servidor e usar o terceiro servidor para cumprir com os requisitos de alta disponibilidade se o servidor primário ou secundário estiver inativo. Se tiver apenas dois hosts de cache funcionando, você não conseguirá interromper nenhum deles individualmente, pois o terceiro servidor não estará presente para manter a alta disponibilidade.

Você pode usar um script do Windows PowerShell para determinar se um ou mais dos caches usam o recurso de alta disponibilidade. O script do PowerShell a seguir fornece um exemplo que alterna entre cada cache e verifica o Secondaries de forma adequada.

Import-Module DistributedCacheAdministration

Use-CacheCluster

$Caches = Get-Cache -MaxRegions 0
$HighAvailability = $false

foreach ($Cache in $Caches)
{
   $CacheConfig = Get-CacheConfig $Cache.CacheName
   if ($CacheConfig.Secondaries -eq 1)
   {
      Write-Host $CacheConfig.CacheName
      $HighAvailability = $true
   }
}

if ($HighAvailability -eq $true)
{
   Write-Host "One or more caches use high availability (Secondaries = 1)"
}
else
{
   Write-Host "No caches use high availability (Secondaries = 1)"
}

Mesmo se tiver mais de dois servidores no seu cluster de cache, você deverá verificar o status de execução deles no Get-CacheHost antes de começar atualizá-lo sequencialmente.

Considerações sobre o aplicativo cliente

Ao atualizar sequencialmente os hosts de cache sem interromper o cluster de cache, há várias considerações importantes a serem feitas para os aplicativos clientes que acessam o uso do cluster de cache.

  1. Os aplicativos fazem referência a um ou mais hosts de cache por nome para conectar inicialmente ao cluster de cache. Isso é realizado no arquivo de configuração do aplicativo ou por programação. Se o aplicativo cliente apontar apenas para um host de cache, ele não conseguirá estabelecer novas conexões com o cluster de cache enquanto esse host estiver inativo. Os aplicativos clientes devem fazer referência a mais de um host de cache quando for possível. Observe que os aplicativos clientes não precisam fazer referência a todos os hosts de cache. Os hosts de cache referenciados funcionam como um gateway para o cluster inteiro.

  2. Quando um host de cache é interrompido, os aplicativos podem não encontrar itens que foram localizados anteriormente no host de cache interrompido. O aqplicativo é responsável pelo novo preenchimento desses itens.

  3. Quando um host de cache é interrompido, os aplicativos podem receber temporariamente várias exceções DataCacheException. Elas devem ser resolvidas automaticamente à medida que o cluster de cache se adapta à perda de um host de cache. Os aplicativos devem estar preparados para esperar exceções comuns. Os clientes podem decidir implementar a lógica de repetição ou podem usar dados de origem até as exceções serem resolvidas. Para obter mais informações, consulte Tratamento de erros.

  4. Quando um host de cache for interrompido, os aplicativos poderão não conseguir gravar temporariamente em um cache que usa alta disponibilidade. Depois que o host de cache é interrompido, as novas cópias de itens armazenados em cache (secundários) são criadas em outro host de cache.

Consulte também

Conceitos

Tarefas comuns de gerenciamento de cluster de cache (Cache do Windows Server AppFabric)

  2012-03-05