Compartilhar via

Alta disponibilidade (Cache do Windows Server AppFabric)

  • Artigo

Quando a alta disponibilidade estiver habilitada, uma cópia de cada objeto ou região em cache será mantida em um host de cache separado. O cluster do cache gerenciará a manutenção dessas cópias e as fornecerá ao seu aplicativo caso as cópias principais não estejam disponíveis. Não é necessária nenhuma alteração de código para tornar seus aplicativos habilitados por cache altamente disponíveis. A figura a seguir ilustra como as cópias de objetos e regiões são armazenadas em hosts separados quando o recurso de alta disponibilidade está habilitado.

Visão geral de alta disponibilidade de "velocidade"

Configuração de alta disponibilidade

A alta disponibilidade é configurada no nível do cache, nas definições de configuração do cluster. Como propriedade do cache, é possível habilitá-lo ao criar o cache pela primeira vez, usando o comando New-Cache com o parâmetro Secondaries igual a 1. Isso informa aos cmdlets administração de cache do Windows PowerShell que você deseja uma cópia de cada objeto ou região armazenado(a) em cache. Se você definir o parâmetro Secondaries como 0, o recurso de alta disponibilidade será desabilitado. Por padrão, a opção de alta disponibilidade é desabilitada quando um novo cache é criado. Para obter mais informações sobre edição de definições de configuração de cache, consulte Editar definições de configuração de cache com o Windows PowerShell (cache do Windows Server AppFabric).

O recurso de alta disponibilidade dos recursos de cache do Windows Server AppFabric exige que todos os nós no cluster de cache executem a Enterprise Edition (ou posterior) do Windows Server 2008 ou Windows Server 2008 R2. Verifique se todos os nós de cache de alta disponibilidade estão sendo executados em um sistema operacional compatível. Para obter mais informações sobre sistemas operacionais compatíveis, consulte a seção “Requisitos de software" do Guia de instalação do AppFabric (https://go.microsoft.com/fwlink/?LinkId=169172).

Armazenamento de cópia secundária

O cluster do cache escolhe onde as cópias secundárias dos objetos e regiões são armazenadas. Assim como o AppFabric distribui os objetos armazenados em cache entre todos os hosts de cache no cluster, ele também distribui as cópias secundárias desses objetos em todos os hosts de cache no cluster.

Como é mantida a coerência

Independentemente de a alta disponibilidade estar habilitada ou não, os aplicativos habilitados por cache funcionam como se apenas a cópia primária do objeto armazenado em cache existisse. Todos as chamadas de métodos Add, Put e Remove são iniciadas primeiro no objeto primário, no host de cache em que elas residem. Depois que a chamada é iniciada no host de cache que mantém o objeto ou a região principal, a ação resultante difere, dependendo da habilitação ou desabilitação da alta disponibilidade.

Se a alta disponibilidade estiver habilitada, haverá uma etapa adicional que notifica ao host que mantém a cópia secundária de que uma alteração está prestes a ocorrer. Depois, o host do cache com a cópia primária do objeto aguarda um reconhecimento do outro host antes de responder ao cliente que a operação está concluída.

Por exemplo, consulte os hosts de cache A e B no diagrama a seguir. Assim que o host de cache A recebe uma solicitação, ele começa a processar a solicitação e notifica o host de cache B da alteração. Então, o host de cache B envia um reconhecimento de volta ao host de cache A. Quando o host de cache A recebe o reconhecimento, ele conclui a alteração e envia uma resposta ao aplicativo habilitado pelo cache. Esse processo garante que a cópia secundária do objeto ou região esteja sempre no mesmo estado que a CÓPIA primária. Esse processo é chamado de coerência forte.

Consistência de alta disponibilidade de "velocidade"

Considerações de desempenho

Como o host de cache que mantém a cópia secundária do objeto ou região deve reconhecer todas as alterações que pertencem à cópia primária, há um pequeno custo de desempenho no tempo de resposta das gravações do aplicativo habilitado por cache. Observe que esse impacto no desempenho não afeta a leitura de itens já armazenados em cache. Também será necessário considerar o tempo exigido para recarregar o cache com objetos se o host de cache que mantém as cópias primárias desse objeto estiver perdido.

O que acontece quando um host de cache falha

Se um host de cache falhar (presumindo que haja um número suficiente de hosts de cache disponível para manter o cluster em execução), nada será alterado no aplicativo habilitado por cache. O cluster de cache encaminha novamente as solicitações para o objeto ao cache que mantém a cópia secundária do objeto. Dentro do cluster, as cópias secundárias de todos os objetos primários são elevadas para se tornarem novos objetos primários. Depois, as cópias secundárias desses novos objetos primários são distribuídas a outros hosts de cache pelo cluster. Os objetos secundários no host de cache que falharam são substituídos por novos objetos secundários e distribuídos pelo cluster. Esse processo também se aplica a regiões.

Para que o recurso de alta disponibilidade ajude a separar o aplicativo da falha de um host de cache, pelo menos três hosts de cache devem ser membros do cluster de cache. Isso ocorre devido a uma exigência de coerência forte, que diz que deve sempre haver duas cópias de cada objeto ou região em um cache habilitado pela alta disponibilidade. Para manter duas cópias de um cache ou região,um cache de alta disponibilidade exige pelo menos dois hosts de cache para funcionar.

Por exemplo, é possível que você tenha criado um cache de alta disponibilidade chamado HACache em um cluster de cache de três servidores, conforme mostrado na tabela a seguir. Considere que o SQL Server tenha sido configurado para realizar a função de gerenciamento de cluster (de forma que esse exemplo não precise considerar a perda potencial dos principais hosts).

Hora Host de cache 1 Host de cache 2 Host de cache 3 HACache (cache nomeado habilitado pela alta disponibilidade)

T1

em execução

em execução

em execução

disponível

T2

em execução

em execução

parado

disponível

T3

em execução

parado

parado

não disponível

Em T1, quando houver três hosts de cache disponíveis, duas cópias de objetos ou regiões armazenados em cache poderão ser armazenadas em um de três servidores disponíveis. Em T2, quando um servidor de cache falha, HACache continua disponível porque ainda há dois hosts de cache disponíveis para armazenar as duas cópias dos objetos ou regiões armazenados em cache. Em T3, quando o segundo cache falha, HACache fica indisponível. Isso ocorre porque não existe outro host de cache disponível para armazenar a segunda cópia dos objetos ou regiões armazenados em cache.

Outras recomendações da alta disponibilidade

Para otimizar a disponibilidade de seus dados armazenados em cache, considere as seguintes recomendações:

  • Empregue um grande número de hosts de cache.

  • Implante seu sistema de cache distribuído no perímetro de um firewall, com todos os membros do servidor do mesmo domínio, incluindo os clientes de cache, os hosts de cache, o servidor de origem dos dados primários e o servidor que hospeda o local de armazenamento da configuração do cluster.

  • Use o SQL Server ou um provedor personalizado para armazenar as definições de configuração do cluster de cache.

  • Minimize as alterações de configuração dispendiosas que exigem a interrupção do cluster. Quando possível, crie novamente caches nomeados em vez de interromper todo o cluster de cache, a fim de realizar alterações de configuração de cache nas definições de configuração de cluster.

  • Sempre use o comando Stop-CacheHost para interromper o serviço de cache antes de reinicializar um servidor. Quando os hosts principais realizam a função de gerenciamento de cluster, o cmdlet Stop-CacheHost não obterá êxito se a interrupção do serviço de cache causar o desligamento de todo o cluster de cache (devido à minoria de hosts principais em execução).

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

  2011-12-05