Guia de planejamento de capacidade de cache do Windows Server AppFabric

Jason Roth, Rama Ramani, Jaime Alva Bravo

Março de 2011

Este whitepaper fornece orientação para o planejamento de capacidade do Cache do Windows Server AppFabric.

1. Introdução

2. Avaliando o desempenho de cache do AppFabric

3. Metodologia de planejamento de capacidade

   1. Etapa um: Entenda os gargalos e identifique os candidatos ao cache

   2. Etapa dois: Avalie os padrões atuais da carga de trabalho

   3. Etapa três: Entenda a infraestrutura física e os recursos de hardware

   4. Etapa quatro: Finalize o SLA de desempenho exigido para todos os aplicativos

   5. Etapa cinco: Identifique os recursos apropriados e configuração do AppFabric

4. Ferramenta de planejamento de capacidade

5. Próximas etapas do planejamento de capacidade

6. Monitorando os requisitos contínuos de capacidade de cache

Introdução

O cache do Windows Server AppFabric fornece um cluster de cache distribuído, integrado à memória. Este documento fornece orientação para o planejamento de capacidade para a implantação local do cache do Windows Server AppFabric.

A arquitetura de cache do Windows Server AppFabric é descrita em detalhes na documentação. Para obter mais informações, consulte Recursos de cache do Windows Server AppFabric. Em resumo, um cluster de cache do AppFabric é composto de um ou mais servidores de cache (também chamados de hosts de cache). Os caches são distribuídos pelos hosts de cache e armazenados na memória.

Observação

Observe que também existe uma versão de Cache do Windows Azure AppFabric para usar o cache na nuvem. Algumas das etapas neste documento se referem a estimar os requisitos de memória que se aplicam a uma solução baseada em nuvem, mas este documento se concentra especificamente no cenário de cluster do cache local. Par obter mais informações sobre como usar o recurso de cache do Azure AppFabric, consulte Cache do Windows Azure AppFabric.

As informações deste documento estão baseadas em um trabalho de planejamento que a Microsoft fez com os clientes. Todos os clientes de cache do AppFabric fazem uma pergunta comum: "Quantos servidores são exigidos para o meu cenário?" Em muitas dessas discussões, começamos com uma resposta típica: "Depende". Em seguida, fazemos uma análise de vários detalhes e no final chegamos a um bom ponto de partida. Durante esse processo, surgem outras perguntas mais específicas:

• Quanta memória de cache os meus aplicativos exigem?

• Quantas máquinas devo usar em um cluster de cache?

• Quanta memória deve haver em cada máquina e como devem ser configuradas?

• Como a largura de banda da rede afeta o desempenho do cluster de cache?

A meta deste whitepaper é capturar as lições aprendidas com este tipo de discussão com o cliente, com o objetivo de fornecer uma metodologia que possa ser usada para o planejamento de capacidade.

Se você está lendo este documento, pode estar em uma de várias fases de desenvolvimento:

1. Você está somente começando a olhar o cache distribuído e não tem dados detalhados sobre o mix da carga de trabalho, requisitos de desempenho ou topologia da implantação do servidor. Neste momento, você pode começar examinando alguns dados de desempenho do cache do AppFabric.

2. Ou então você já investigou os recursos e o desempenho do cache do AppFabric. Agora, você precisa de ajuda para olhar detalhadamente seu cenário específico e seus requisitos de alto nível. É aqui que você entra nos detalhes do planejamento de capacidade.

3. Finalmente, você já pode estar na produção. Nessa fase, você deseja entender como analisar os dados de desempenho para garantir a capacidade suficiente. Além disso, também deseja planejar os futuros aumentos na carga de trabalho, sabendo os indicadores-chave e as melhores práticas com base no comportamento do tempo de execução do cache do AppFabric.

Este whitepaper foi estruturado para tratar essas fases de maneira sequencial. Se você está somente avaliando o desempenho do AppFabric, apontamos um abrangente whitepaper escrito pelo nosso parceiro Grid Dynamics. Aqui, vamos agrupar os dados desse whitepaper de uma maneira imples, que facilita a sua avaliação e informa o processo de planejamento de capacidade.

Se você estiver pronto para o processo do planejamento de capacidade, fornecemos um conjunto de etapas para formalizar uma metodologia que você pode aplicar ao seu cenário.

Se você está usando ou testando um cluster de cache, pode validar o processo do planejamento de capacidade examinando um conjunto de indicadores-chave de desempenho a fim de garantir que possui a capacidade certa. E além disso, discutiremos algumas melhores práticas.

Avaliando o desempenho de cache do AppFabric

O nosso parceiro Grid Dynamics concluiu recentemente uma série de testes sobre o desempenho do cache do AppFabric. Eles publicaram seus resultados no seguinte whitepaper: Cache do Windows Server AppFabric: Uma folha de dados detalhada & da escalabilidade do desempenho.

Cada teste focou uma variável específica, como o tamanho do cache ou o número de servidores no cluster de cache. O estudo da Grid Dynamics pode ser usado para avaliar o desempenho e a escalabilidade do cache do AppFabric. Você pode comparar os números de produtividade e latência de uma ampla variedade de cenários de teste e topologias, com seus requisitos de aplicativo. Normalmente, em cada teste apenas um ou dois parâmetros foram variados, a fim de se concentrar no seu impacto no desempenho. O conjunto inteiro de parâmetros inclui:

Padrão de carga	Padrão de uso do cache, i.e. porcentagem das operações 'Get', 'Put', 'BulkGet', 'GetAndLock', 'PutAndUnlock'
Tamanho dos dados no cache	Quantidade de dados armazenados no cache durante o teste
Tamanho do cluster	Número de servidores no cluster de cache
Tamanho do objeto	Tamanho dos objetos depois da serialização, que são armazenados no cache
Complexidade do tipo	Diferentes tipos de objetos .NET como byte, string[], etc. armazenados no cache
Security	Configurações de segurança do cluster de cache

Além de verificar o desempenho e a escalabilidade do cache do AppFabric, a Grid Dynamics forneceu o uso do teste para permitir que você repita os testes com os seus próprios dados e cargas de trabalho. Esta é outra opção para avaliar o desempenho do cache para o seu cenário específico.

Embora seja altamente recomendável ver o estudo inteiro e suas conclusões, aqui está um resumo de alguns dos achados que informam as melhores práticas discutidas no restante do documento:

• Cache do AppFabric escala linearmente à medida que mais máquinas são adicionadas a um cluster de cache.

• O tamanho do cache tem um baixo impacto, exceto nos caches grandes com alta porcentagem de gravações. Entre outros fatores, a alta carga de trabalho de gravação exerce maior pressão na coleta de lixo do .NET quando o tamanho da pilha gerenciada é grande.

• A complexidade de tipo alto afeta somente o desempenho no lado do cliente devido à serialização.

• As chamadas de obtenção de massa resultam em uma utilização melhor da rede. O acesso direto ao cache é muito mais rápido que os proxies (ASP.NET, WCF), mas isso ocorre devido ao desempenho da camada intermediária e não do cache.

• Os bloqueios pessimista e otimista têm desempenhos semelhantes, portanto você deve usar a melhor técnica para o design do seu aplicativo. A latência e a produtividade aumentam quando a taxa de conflitos diminui.

• A segurança do cluster de cache diminui o desempenho e é ativada por padrão. A produtividade mais alta e a latência mais baixa são adquiridas quando a segurança é desativada, mas isso pode ser inaceitável devido à sensibilidade dos dados e e aos requisitos do negócio.

• Os gargalos da rede são reduzidos usando uma rede dedicada entre os servidores de aplicativos e cache.

Observe que o documento da Grid Dynamics é um bom lugar para iniciar a uma avaliação do cache do AppFabric e, além disso, também contém dados brutos e padrões observados que podem ser usados para informar o processo de planejamento de capacidade.

Metodologia de planejamento de capacidade

Uma vez que você decide que se o aplicativo pode se beneficiar com um cache de memória distribuído, como o cache do AppFabric, você entra na fase de planejamento de capacidade. Embora seja possível realizar algumas etapas de planejamento de capacidade através de um teste direto contra um cluster de cache do AppFabric, pode ser necessário criar uma estimativa sem esse tipo de teste. Esse é o enfoque desta seção. As etapas a seguir formam uma maneira sistemática de pensar nos seus requisitos de teste do AppFabric:

1. Entenda os gargalos e identifique os candidatos ao cache

2. Avalie os padrões atuais da carga de trabalho

3. Entenda a infraestrutura física e os recursos de hardware

4. Finalize o SLA de desempenho exigido para todos os aplicativos

5. Identifique os recursos apropriados e configuração do AppFabric

Este documento fornece exemplos dessas etapas, examinando as necessidades de uma amostra de um aplicativo de loja online. No entanto, o cache pode ser usado por qualquer tipo de aplicativo .NET e você pode ter mais de um aplicativo acessando o mesmo cluster de cache. Nesse cenário, você deve realizar as etapas abaixo para cada aplicativo e agregar os resultados para obter uma estimativa precisa da capacidade.

Etapa um: Entenda os gargalos e identifique os candidatos ao cache

Primeiro, identifique os dados que deseja incluir no cache. Isso é realizado usando ferramentas de análise de desempenho como SQL Server Profiler, Performance Monitor, teste do Visual Studio e muitos outros. Essas ferramentas podem identificar objetos de bancos de dados frequentemente acessados ou reduzir a velocidade das chamadas para os serviços da web. Os conjuntos de dados retornado desses armazenamentos de backend são possíveis candidatos para o cache. O armazenamento temporário desses dados no cache pode melhorar o desempenho e aliviar a pressão dos armazenamentos de dados backend.

Depois de identificar os possíveis candidatos ao cache, um exercício útil é classificar esses objetos em uma de três categorias principais: dados de Atividade, de Referência e de Recurso. É melhor explicar com exemplos.

• Os dados de Atividade contêm dados de leitura/gravação relacionados a um usuário individual. Por exemplo, em um uma loja online, o carrinho de compras do usuário representa os dados de atividade. Ele se aplica à sessão atual do usuário e pode mudar frequentemente. Embora seja importante manter uma alta disponibilidade para o carrinho, são dados que não exigem necessariamente um armazenamento permanente em um banco de dados backend. Devido às suas características temporárias, os dados de atividade são candidatos lógicos para o cache.

• Os dados de Referência são dados somente leitura, compartilhados por diversos usuários ou diversas instâncias do aplicativo. O acesso é frequente, mas as alterações não são. Por exemplo, na loja online, o catálogo de produtos representa os dados de referência. O catálogo seria válido por um ou mais dias, mas pode ser acessado milhares de vezes por usuários diferentes. Esse tipo de dados também é um ótimo candidato para o cache. Sem algum tipo de cache, cada usuário que visualiza o catálogo precisa acessar os dados a partir do banco de dados. O uso do cache pode aliviar a pressão sobre o banco de dados backend para solicitações repetidas de dados semiestáticos. Devido às suas características permanentes, também são candidatos lógicos para o cache.

• Os dados de Recurso são dados de leitura/gravação compartilhados pelos usuários. Por exemplo, um fórum de suporte contém esse tipo de dados. Todos os usuários podem ler uma resposta a uma publicação no fórum.

Uma vez que diferentes tipos de dados de cache terão diferentes padrões de uso, a classificação dos dados nessas categorias pode ser útil. Por exemplo, identificar um objeto como um dado de referência sugere automaticamente que ele é mais semelhante a uma carga de trabalho somente leitura. Também pode ajudar a determinar as políticas de expiração, que tendem a ser mais curtas para os dados que mudam com mais frequência. Para o desenvolvimento, essas divisões lógicas podem sugerir áreas encapsuladas no código.

É recomendado criar estimativas para objetos individuais e depois agregar esses dados. A tabela a seguir mostra um exemplo das informações coletadas nessa fase:

Objeto para cache	Categorização do cache	Local de armazenamento permanente
Objeto de carrinho de compras	Dados de atividade	Nenhum
Objeto de preferências do usuário	Dados de atividade	Banco de dados backend
Catálogo do produto	Dados de referência	Banco de dados backend
Thread do fórum do usuário	Dados de recurso	Banco de dados backend

Ao identificar dados candidatos para o cache, você não precisa encontrar dados para o cache em cada categoria. Você pode observar que o desempenho e a escalabilidade podem ser melhorados simplesmente pelo cache do carrinho de compras do seu aplicativo. O ponto mais importante desta etapa é usar as informações disponíveis para identificar os melhores itens para o cache.

Etapa dois: Avalie os padrões atuais da carga de trabalho

Depois de determinar os dados apropriados para o cache, você deve entender como o aplicativo acessa os dados atualmente e quais são os padrões de carga de trabalho associados. No final da etapa, você poderá chegar a uma estimativa bruta dos seus requisitos de memória de cache. Também deve entender melhor como os dados são associados e usados, o que será importante nas etapas finais.

Por exemplo, se você identificar o seu catálogo de produtos como um candidato para o cache, deve explorar quando o aplicativo recupera os dados do catálogo e com que frequência essas solicitações são efetuadas. Com base na etapa prévia, você sabe que estes são dados de referência e, portanto, uma carga de trabalho principalmente somente leitura. Um entendimento profundo dos padrões da carga de trabalho de diferentes objetos irá orientar as futuras decisões sobre a capacidade. Vamos olhar mais de perto o que está envolvido nessa etapa.

Existem várias maneiras de entender melhor os seus padrões atuais de acesso aos dados:

1. Faça uma revisão profunda dos códigos para ver onde os dados são acessados e a frequência do acesso.

2. Utilize um profiler de código que possa fornecer a frequência de chamadas do método e os dados de desempenho associados.

3. Crie a instrumentação no código ao redor de seções de acesso a dados específicos. Registre a tentativa de acesso aos dados e o desempenho associado da operação de dados.

4. Utilize um profiler do banco de dados como o SQL Server Profiler para observar o número e a duração das operações do banco de dados.

Observe que muitas dessas técnicas poderiam ter sido usadas na etapa anterior para determinar quais dados identificar para o cache. No entanto, nesta fase você está interessado em números mais detalhados, que podem ser usados nos futuros cálculos do planejamento de capacidade.

Parte dessa avaliação envolve a compreensão da relação de leituras/gravações. A carga de trabalho de leitura/gravação pode influenciar as futuras decisões sobre a capacidade. Por exemplo, uma carga de trabalho com uma alta porcentagem de gravações desencadeia mais coleta de lixo do .NET. Isso é discutido em uma etapa futura.

Outro fator é a frequência de leituras e gravações durante a carga de pico. A tabela a seguir mostra exemplos de dados coletados nesta fase para o exemplo do objeto do carrinho de compras.

Objeto para analisar	Carrinho de compras
% de leituras	50%
% de gravações	50%
Operações de leitura por segundo (máximo)	250
Operações de gravação por segundo (máximo)	250

Novamente, essa mesma análise deve ser feita para cada tipo de objeto. Os diferentes tipos de objetos possuem diferentes padrões de acesso e máximos diferentes de leituras e gravações por segundo sob a sobrecarga.

Para entender os requisitos do cache, você deve ter uma estimativa do número máximo de objetos ativos para cada tipo no cache em um determinado momento. Essa estimativa envolve o equilíbrio entre a frequência das inserções de objeto e a expectativa de vida desses objetos. Para entender isso, é melhor usar um exemplo.

No exemplo do aplicativo da web ASP.NET, os dados operacionais podem mostrar que existem momentos de pico de 25.000 usuários simultâneos. Cada usuário exige informações do estado da sessão e, portanto existem 25.000 objetos no cache. Porém, a expiração desses objetos pode estar definida como 30 minutos. Durante os momentos de pico, os dados operacionais podem mostrar que existem novos 5.000 usuários por hora, significando que 2.500 novos funcionários podem chegar durante o período de expiração de 30 minutos. Além disso, alguns usuários podem fechar o navegador e iniciar uma nova sessão. Embora seja o mesmo usuário, agora ele está usando uma sessão diferente. Portanto, o preenchimento adicional deve contabilizar esse fato. Por fim, qualquer crescimento previsto nos próximos 6-12 meses deve ser planejado. No final, o cálculo do número máximo de objetos ativos no cache pode ser o seguinte:

Objeto para analisar:	Carrinho de compras
Usuários simultâneos em pico	25000
Novos usuários durante o período de expiração (30 minutos)	2500
Usuários existentes iniciando novas sessões do navegador	250
Estimativa do futuro crescimento (25%)	6940
Total de objetos ativos (máximo)	~35000 objetos ativos no máximo

Se houver alterações nas entradas, como o período de expiração, então isso altera quantos objetos não vencidos residem no cache durante a carga de pico. Isso é somente um exemplo do processo de pensamento. Outros tipos de objeto podem ter diferentes padrões e variáveis que entram no cálculo. Por exemplo, se um catálogo de produto compartilhado for válido durante um dia inteiro, o número máximo de objetos do catálogo de produto no cache durante o dia deve ser um.

No entanto, saber o número máximo de objetos no cache ajuda apenas se você também souber o tamanho médio do objeto. Inerentemente, esse é um problema difícil. No exemplo do carrinho de compras, um usuário pode colocar um único item no carrinho, enquanto outro coloca dez ou vinte. O objetivo é entender a média. Como a maioria dos números desse processo, ele não seria perfeito, mas o resultado final é um ponto de partida bem pensado para o seu um cluster de cache e não uma mera adivinhação.

Os objetos são armazenados no cache em uma forma serializada. Portanto, para entender o tamanho médio do objeto, você precisará calcular o tamanho médio do objeto serializado. O AppFabric usa a classe NetDataContractSerializer para a serialização antes de armazenar os itens no cache. Para determinar o tamanho médio do objetos, adicione o código de instrumentação ao seu aplicativo que serializa os seus objetos e registra o seu tamanho serializado.

O seguinte exemplo de código tenta calcular o tamanho médio de um único objeto. O objeto que está sendo serializado é nomeado como obj. A variável length é usada para registrar o comprimento. Se houver problemas para obter o tamanho com NetDataContractSerializer, o BinaryFormatter é usado. Você pode transformar isso em um método para facilitar o uso. Nesse caso obj seria transferido como um parâmetro e length seria retornado do método.

// requires following assembly references:
//
//using System.Xml;
//using System.IO;
//using System.Runtime.Serialization;
//using System.Runtime.Serialization.Formatters.Binary;
//
// Target object “obj”
//
long length = 0;

MemoryStream stream1 = new MemoryStream();
using (XmlDictionaryWriter writer = 
    XmlDictionaryWriter.CreateBinaryWriter(stream1))
{
    NetDataContractSerializer serializer = new NetDataContractSerializer();
    serializer.WriteObject(writer, obj);
    length = stream1.Length; 
}

if (length == 0)
{
    MemoryStream stream2 = new MemoryStream();
    BinaryFormatter bf = new BinaryFormatter();
    bf.Serialize(stream2, obj);
    length = stream2.Length;
}

Observação

Observe que se você tivesse uma configuração de teste do cluster de cache, poderia adicionar itens ao cache e usar o comando Windows PowerShell, Get-CacheStatistics, para encontrar o tamanho de um ou mais objetos adicionados ao cache. Ou então, poderia dividir o tamanho de vários objetos no cache pela contagem de objetos no cache. Você pode optar pela coleta de estimativas através do código ou do teste.

Se você planeja usar o cache do AppFabric para o estado da sessão, é importante entender que o fornecedor do SQL Server para o estado da sessão ASP.NET sempre usa o BinaryFormatter em vez do NetDataContractSerializer. Às vezes, objetos serializados pela classe NetDataContractSerializer podem ser várias vezes maiores que o tamanho serializado de objetos que usam o BinaryFormatter. Isso é importante se você está analisando o tamanho de objetos do estado de sessão no SQL Server, porque não poderá usar esse tamanho e presumir que ele será o mesmo no cache. Você pode multiplicar esse tamanho por seis, para obter uma estimativa rudimentar. Para uma estimativa melhor, use o código acima dos objetos armazenados no estado da sessão. Com os dados coletados até esse ponto, você pode começar a formular os requisitos totais da memória. Esta etapa envolve as seguintes subtarefas:

1. Enfoque em um tipo de objeto (por exemplo, o objeto Carrinho de compra).

2. Para esse objeto, pegue primeiro o tamanho médio do objeto serializado.

3. Depois, adicione 500 bytes ao tamanho médio para contabilizar o excedente do cache.

4. Multiplique esse tamanho pelo número máximo de objetos ativos. Isso fornece os requisitos totais da memória de cache para esse tipo de objeto.

5. Adicione um excedente da estimativa para as estruturas do cache interno (5%).

6. Repita essas etapas para cada tipo de objeto identificado.

7. Agregue os resultados para os requisitos totais da memória de cache.

Neste processo, observe que há aproximadamente .5 KB de excedente por objeto, que você deve adicionar às estimativas de tamanho. Além disso, há outras estruturas de dados internos que exigem memória no cache. Regiões, marcações e notificações exigem uma memória adicional para o gerenciamento. Nos nossos exemplos de cálculos, adicionamos 5% do total para contabilizar essas estruturas internas, mas pode ser menos ou mais, dependendo de até que ponto você usa esses recursos de cache.

Neste momento, você deve considerar o impacto de um recurso específico do cache do AppFabric, a alta disponibilidade. Esse recurso cria cópias dos itens do cache nos servidores secundários. Isso significa que se um servidor único de cache travar, o servidor secundário assume e os dados não serão perdidos. Se você optar por usar a alta disponibilidade, deve dobrar as estimativas de memória. Você também deve usar o Windows Server 2008 Enterprise Edition ou superior. Observe que o recurso de alta disponibilidade é efetuado no nível do cache nomeado. Isso significa que se você deseja criar dois caches nomeados no mesmo cluster, não precisa necessariamente usar a alta disponibilidade para cada cache. O aplicativo pode colocar alguns itens no cache nomeado com alta disponibilidade e outros no cache sem alta disponibilidade. Isso pode ajudá-lo a obter o máximo dos seus recursos de memória. Assim, é importante conhecer a decisão sobre a alta disponibilidade, porque ela dobra os requisitos de memória para o cache que a utiliza.

Por exemplo, aqui está uma tabela onde avaliamos os requisitos dos dados de Atividade e de Referência no mesmo aplicativo. Dependendo do seu cenário, você pode optar por fazer essa estimativa no nível do objeto ou do aplicativo. Basta adicionar mais colunas a esse exemplo e nomeá-las corretamente.

Objeto para analisar:	Dados de atividade	Dados de referência
Tamanho médio do objeto serializado:	250 KB	60 KB
Excedente do cluster de cache por objeto:	0,5 KB	0,5 KB
Tamanho médio ajustado do objeto serializado:	250,5 KB	60,5 KB
Objetos ativos no máximo:	~35000	~68000
Requisitos de memória do cache:	8.4 GB	3,9 GB
Alta disponibilidade ativada?	16,8 GB	Não
Excedente das estruturas de dados internos (5%):	0,8 GB	0,2 GB
Requisitos totais de memória:	17,6 GB	4,1 GB

A agregação dessas estimativas forma os requisitos de memória iniciais para o cluster de cache. Nesse exemplo, o total é 21.7 GB. Com essa estimativa, você pode agora começar a olhar outras considerações, incluindo infraestrutura física, requisitos de SLA e configurações do cache do AppFabric.

Etapa três: Entenda a infraestrutura física e os recursos de hardware

É importante entender sua infraestrutura física e a disponibilidade de recursos. A seguir estão algumas perguntas comuns:

1. Você poderá provisionar máquinas físicas ou virtuais?

2. Se você tem um hardware existente, quais são as configurações da máquina (por exemplo, 8 GB de RAM, Quad-Core)?

3. O cluster de cache ficará localizado no mesmo datacenter que os servidores de aplicativo?

4. Quais são as capacidades de rede?

Se você estiver pensando em usando máquinas virtuais para os servidores de cache, há várias considerações. Por exemplo, você deve considerar o impacto de ter diversas máquinas virtuais na mesma máquina física. Diversas máquinas virtuais podem compartilhar a mesma placa de rede, aumentando a possibilidade de gargalos. Além disso, a alta disponibilidade pode ser configurada entre um host de cache primário e secundário que sejam máquinas virtuais da mesma máquina física. Se essa máquina física travar, nenhuma cópia dos dados sobrará. Para obter mais informações, consulte Orientação sobre a execução do cache do AppFabric em uma máquina virtual.

Para as máquinas existentes, não há nenhuma especificação recomendada. No entanto, para clusters de cache grandes, vimos que as máquinas de 16GB de RAM e Quad-Core funcionam bem. Em geral, o planejamento da quantidade correta de memória física e carga da rede é a consideração mais importante.

Para as máquinas físicas e virtuais, você deve observar a localização do cluster de cache nos servidores de aplicativo ou web que utilizam o cache. Se estiverem em datacenters separados, certifique-se de que a latência entre eles não irá afetar o seu desempenho negativamente. Nessa fase, pode ser tentador usar seus servidores de aplicativos ou da web para os seus servidores de cache. Embora seja possível, isso não é suportado. Em primeiro lugar, qualquer pico de uso de recursos pelos serviços como o IIS nessas máquinas pode afetar o cluster de cache. Além disso, o serviço de cache presume que ele está em um servidor dedicado e pode possivelmente usar muito mais memória que a especificada.

Para as capacidades de rede, você deve avaliar a carga esperada da rede e comparar com a sua infraestrutura. Primeiro, é necessário saber a quantidade esperada de dados que cada servidor de cache deve manipular e se as capacidades da placa de rede são suficientes. Do contrário, você pode precisar de mais servidores de cache. Por exemplo, considere um cenário em que o tamanho médio dos objetos no cache é 500.5 KB e que existem 240 operações por segundo no cluster de cache. Se um único host de cache fosse usado, os resultados seriam os seguintes:

Número de leituras/gravações de objeto por segundo:	240
Número de máquinas no cluster de cache:	1
Número de operações de cache por máquina por segundo:	240
Tamanho médio do objeto:	500,5 KB
Tamanho dos dados transmitidos por segundo:	240 * 500.5 = 117.3 MBps

Se cada máquina tem uma placa de rede de 1Gbps, então a produtividade máxima é de aproximadamente 119 MBps. O valor calculado de 117.3 MBps provavelmente seria uma sobrecarga para o servidor. Isso aumenta muito a probabilidade de que a rede se torne um gargalo. No entanto, se três máquinas fossem usadas no cluster de cache, a distribuição uniforme das solicitações de cache resultaria em cada servidor assumindo 1/3 dessa carga.

Considere também a utilização da rede dos servidores de aplicativos que acessam o cluster de cache. Se eles trocarem um grande volume de dados com outros sistemas, você deve pensar em criar uma rede dedicada entre os servidores de aplicativos e o cluster de cache. Isso requer a instalação de uma placa de rede adicional em cada servidor de aplicativo, para essa finalidade.

A consideração final é se a rede pode ou não lidar com a carga exigida ao longo de todo o caminho. Não é suficiente apenas ter uma placa de rede de 1Gbps em cada servidor de cache. O switch e os outros pontos ao longo da rede também devem ser capazes de lidar com a carga. Trabalhe com as operações para cumprir esse requisito.

Etapa quatro: Finalize o SLA de desempenho exigido para todos os aplicativos

Antes de decidir qual é a configuração final, você também deve entender os requisitos de negócios, incluindo os acordos de nível de serviço (SLAs) de desempenho e confiabilidade. Em um sentido prático, essa etapa influencia a decisão sobre o número de clusters de cache e de hosts de cache em cada cluster.

Por exemplo, se você tem um aplicativo crítico de missão usando um cluster de cache, é possível que queira isolar esse cluster de outros aplicativos de prioridade inferior. Tais aplicativos poderiam usar mais recursos de memória, rede e CPU, afetando negativamente o aplicativo de crítico de missão.

Aqui estão os fatores específicos que influenciam essa decisão:

• A segurança é mantida no nível do cluster de cache. Se um usuário tem acesso ao cluster de cache, ele pode acessar qualquer dado no cluster (desde que ele saiba o nome do cache e a chave da solicitação). Se você exigir configurações de segurança diferentes para cada tipo de dados, a separação dos clusters de cache pode fazer sentido. Para obter mais informações, consulte Gerenciando a segurança.

• A remoção de itens não expirados ocorre quando a memória atinge o nível da marca d'água alta. Subestimar a quantidade de memória necessária para um cache pode afetar todos os caches do cluster. Quando a remoção ocorre devido à pressão da memória, ela acontece em todos os caches, mesmo que apenas um seja responsável pela pressão da memória. Isso pode ser aliviado pela criação de caches não removíveis, mas deve ser feito com cuidado. Para obter mais informações, consulte Expiração e remoção.

• A capacidade de gerenciamento pode ser mais fácil, até certo ponto, com clusters de cache separados. Você pode não querer gerenciar clusters separados para 100 caches diferentes. Porém, pode ser útil ter clusters separados para dois caches grandes, porque eles podem ser gerenciados, escalados e monitorados separadamente.

Por fim, alguns requisitos podem envolver considerações de latência e produtividade. Para informar essa decisão, consulte o whitepaper da Grid Dynamics sobre a orientação e os resultados do teste. Por exemplo, você pode comparar os seus requisitos de produtividade para o cluster de cache com os resultados do teste publicado no documento da Grid Dynamics. O estudo pode indicar que você tem poucos servidores para os seus objetivos de produtividade. É importante reconhecer que esse estudo pode não se equiparar exatamente aos seus tipos e tamanhos de objeto, e à sua infraestrutura física e lógica; no entanto, ele ainda fornece resultados de testes comprovados que podem ajudá-lo a tomar uma decisão informada.

Etapa cinco: Identifique os recursos apropriados e configuração do AppFabric

Essa parte do processo considera as configurações específicas do cache do AppFabric, bem como a arquitetura to cluster de cache do AppFabric. Mesmo com a coleta de todos os dados empíricos e de negócios certos, você ainda pode planejar incorretamente se ignorar essas configurações do cache e do AppFabric.

A tabela a seguir lista uma variedade de recursos de cache do AppFabric e considerações associadas para o planejamento de capacidade.

Regiões	Você pode criar múltiplas regiões, mas cada região existe em um único host de cache. Para aproveitar a vantagem do cache distribuído, os aplicativos devem usar várias regiões. Observe que todas as chamadas que não especificam as regiões automaticamente utilizam as regiões padrão internamente. Cada host no cluster de cache deve ser capaz de hospedar o tamanho máximo da região maior.
Notificações	Os caches e pode permitir notificações e os clientes de cache podem recebê-las. Isso aumenta o tráfego na rede e a utilização do processador no lado do servidor. O efeito varia conforme o intervalo de notificação e o número de notificações enviadas. Os altos números de notificações em intervalos curtos podem causar um impacto no desempenho e na escalabilidade. Não existem diretrizes rígidas para estimar este impacto, portanto ele terá que ser observado durante o teste.
Cache local	O cache local melhora o desempenho porque o cache dos objetos é efetuado nos clientes e no servidor. Considere o impacto da memória nas máquinas clientes ao usar o cache local. Esse recurso não tem efeito no planejamento de capacidade no lado do servidor para a memória, porque todos os itens do cache local também existem no servidor. No entanto, se as notificações forem usadas para a invalidação do cache local, o lado do servidor poderia ser afetado pelo procedimento de notificação.
Configuração do design do aplicativo & no lado do cliente	O design do aplicativo no lado do cliente pode afetar o seu desempenho geral. Por exemplo, você deve armazenar qualquer objeto DataCacheFactory que criar para reutilização, em vez de recriá-los para cada chamada. Você também pode se beneficiar criando um objeto DataCacheFactory por thread. Ou então, se você compartilhar um único objeto DataCacheFactory para múltiplos threads, pense em aumentar a configuração MaxConnectionsToServer. Isso aumenta o número de conexões para os servidores de cache por DataCacheFactory.
Alta disponibilidade	Como já foi afirmado, os caches que usam a Alta disponibilidade exigem o dobro do requisito calculado de memória. Porém, esse recurso também exige um mínimo de três servidores. Se um servidor travar, deve haver dois servidores restantes para suportar as cópias primária e secundária de cada item depois de uma falha. Observe que esse recurso também exige o Windows Server 2008 Enterprise edition ou superior em todos os servidores.
Caches nomeados	No momento, há um limite de 128 caches nomeados. Isso se torna uma decisão de planejamento de capacidade quando você tem aplicativos que exigem mais do que esse número definido. Nesse momento, você precisa de mais de um cluster de cache ou seus aplicativos devem ser projetados para usar menos caches. Outra estratégia é criar as regiões programaticamente dentro dos caches nomeados.
Armazenamento de configuração do XML	Quando você usa um local de rede compartilhado para o seu armazenamento de configuração do cluster de cache, deve ter pelo menos três servidores no cluster – todos projetados como Hosts principais. Para obter mais informações sobre os motivos, consulte Atualizando servidores de cache.

Não é surpresa que uma das configurações mais importantes para entender é a da memória em cada host de cache. Você pode exibir as configurações de memória padrão em cada host de cache usando o comando Windows PowerShell, Get-CacheHostConfig.

Observação

Para obter informações sobre como usar os comandos Windows PowerShell do cache, consulte Tarefas comuns de gerenciamento do cluster de cache.

Os instantâneos de tela a seguir mostram a saída do Get-CacheHostConfig em uma máquina com 4 GB de RAM.

Por padrão, a quantidade de memória reservada para o cache em um determinado servidor é 50% do RAM total. Neste exemplo, a metade do RAM é 2 GB. Então, a memória restante está disponível para o sistema operacional e os serviços. Mesmo em máquinas com muito mais memória, é recomendado manter essa configuração padrão. Como já foi mencionado, o serviço de cache presume que está executando em uma máquina dedicada e pode usar muito mais memória que a alocada para o cache. Embora parte do uso da memória seja decorrente do design interno do serviço de cache, outra parte também é relacionada com o gerenciamento da memória do .NET e a coleta de lixo. Mesmo quando a memória é liberada em um aplicativo .NET, ele deve esperar que a coleta do lixo seja liberada da memória do processo. O processo exige um buffer de memória física para representar a natureza não determinista da coleta de lixo.

Quando você entender o impacto da coleta de lixo, verá que as cargas de trabalho com alta porcentagem e frequência de gravações exige um buffer de memória maior para reservar para o ciclo de coleta de lixo. Cargas de trabalho que são principalmente somente leitura não terão esta consideração. Nesse caso, você pode pensar em aumentar a quantidade de memória reservada para o cache. Por exemplo, em uma máquina de 16 GB, você pode reservar 12 GB para a configuração do Tamanho do cache (em vez do padrão de 8 GB), que fornece 4 GB de excedente para o sistema operacional e os serviços. Isso presume que a máquina é dedicada ao serviço de cache, que é atualmente a única configuração suportada. Nesse exemplo, você deve testar a configuração da memória com a sua carga prevista. Se a alocação da memória for muito agressiva, o teste irá revelar esse erro através de problemas relacionados à memória, como a remoção ou a limitação. Para obter mais informações, consulte Solução de problemas do servidor (Cache do Windows Server AppFabric). O exemplo a seguir usa o comando Set-CacheHostConfig para configurar o tamanho do cache para 12 GB em um servidor nomeado como Server1:

Set-CacheHostConfig -HostName Server1 -CachePort 22233 -CacheSize 12288

O outro item para observar na saída do Get-CacheHostConfig são os valores da marca d'água. O valor LowWatermark tem um padrão de 70% da configuração do Tamanho do cache. Quando a memória do cache alcança o LowWatermark, o serviço de Cache começa a remover objetos que já expiraram. Isso está certo, porque esses objetos são inacessíveis mesmo.

O valor HighWatermark tem um padrão de 90% da configuração do Tamanho do cache. No nível HighWatermark, os objetos são removidos independente de terem ou não expirado, até que a memória volte ao nível LowWatermark. Obviamente, isso tem o potencial de prejudicar o desempenho e de resultar em uma experiência ruim para o usuário.

Recomendamos que você planeje o seu uso do cache para o nível LowWatermark, a fim de evitar a possibilidade de atingir o HighWatermark. Para obter uma descrição mais detalhada, consulte Expiração e remoção.

Dica

Os ciclos completos de coleta de lixo podem causar um curto atraso, que frequentemente é observado nos erros de novas tentativas. Por esse motivo, recomendamos que cada host de cache tenha 16 GB ou menos de memória. Máquinas com mais de 16 GB de RAM podem sofrer pausas mais longas durante os ciclos completos de coleta de lixo. Tendo dito isso, não existem restrições contra o uso de mais memória por host de cache. Uma carga de trabalho que seja mais somente leitura pode não sofrer os ciclos completos de coleta de lixo com tanta frequência. A melhor maneira de determinar esse fato é através do teste da carga.

Em um exemplo prévio, calculamos uma estimativa de 21.7 GB para nosso requisito total de memória do cache. Como queremos a alta disponibilidade, deve haver no mínimo três servidores. Presuma que cada servidor tem 16 GB de RAM. Nesse exemplo, manteremos a configuração padrão do tamanho do cache como 8 GB em cada servidor. Como já foi mencionado, o valor LowWatermark (70%) deve ser a memória-alvo disponível em cada servidor. Isso significa que cada servidor de cache tem uma estimativa de 5.6 GB de memória. Com esses fatores, a tabela a seguir mostra que os quatro servidores forneceriam 22.4 GB de memória de cache e cumpririam o requisito de 21.7 GB.

Requisito total de memória	21,7 GB
Memória inicial (host de cache)	16 GB
Configuração do tamanho do cache (host de cache)	8 GB
Marca d'água baixa (host de cache)	70%
Memória-alvo ajustada por host de cache	5,6 GB
Memória total no cluster de cache (3 máquinas)	5.6 GB x 4 servidores = 22.4

Mais uma vez, lembre-se de que você pode usar os resultados publicados do whitepaper da Grid Dynamics para verificar essa estimativa em relação aos objetivos de produtividade e latência. Os resultados desse teste podem levar a uma leve modificação nessa estimativa inicial, como a adição de outro servidor de cache. O ponto importante é usar os recursos disponíveis como esse para tomar uma decisão informada.

Ferramenta de planejamento de capacidade

Uma planilha é uma ferramenta lógica para as etapas de planejamento de capacidade nas seções prévias. Montamos um exemplo de uma planilha que você pode baixar aqui. As entradas com um asterisco são itens que você deve modificar com base em seu planejamento e recursos. Os cálculos restantes são executados pela planilha.

A primeira parte da planilha especifica a configuração do servidor para cada host de cache. Observe que você pode alterar esse fator como parte do processo de planejamento e observar as diferenças nos cálculos finais. O instantâneo de tela a seguir mostra essa primeira seção.

Importante

A menos que você esteja usando os valores padrão da instalação, é responsável por usar o comando Set-CacheHostConfig em cada host de cache para aplicar as configurações de CacheSize e LowWatermark.

A segunda seção permite preencher as estimativas para os diferentes tipos de objetos. Na planilha de exemplo, somente duas seções são usadas para "Dados de atividade" e "Dados de referência". Em seguida, é fornecida uma série de colunas vazias. Você pode renomear essas colunas dependendo do nível de granularidade que está usando no seu planejamento (objeto, categoria, aplicativo, etc.). O instantâneo de tela a seguir mostra essa segunda seção.

A terceira seção calcula os requisitos da rede. Você preenche os tamanhos médios dos objetos de leitura/gravação e o máximo de operações de leitura/gravação por segundo. A seção calcula seus requisitos máximos da largura de banda da rede para esse tipo de objeto. Isso pode ser o usado para obter uma ideia rudimentar de o agrupamento de máquinas e placas de rede poder ou não lidar com a carga. Como discutido nas seções prévias, você também deseja examinar a largura de banda em todo o caminho da rede. O instantâneo de tela a seguir mostra essa terceira seção.

A seção final agrega os requisitos nas seções de memória e rede. Em seguida, ela usa a configuração da máquina especificada na primeira seção para fazer o cálculo do número de servidores. O campo "Servidores adicionais" permite aumentar esse total calculado, se necessário. Por exemplo, se os cálculos especificaram que apenas dois servidores são necessários, você pode adicionar outro ao total final para suportar corretamente a alta disponibilidade. O instantâneo de tela a seguir mostra essa seção final.

Observação

Os instantâneos de tela acima utilizam números semelhantes ao do exemplo deste documento, mas os servidores estimados são três e não quatro. O motivo é que a planilha define o valor Cache Size Setting(Set-CacheHostConfig) como 12 GB para demonstrar a configuração personalizada. Alterar esse valor para 8 GB produziria resultados semelhantes aos observados nas seções anteriores deste documento.

Próximas etapas do planejamento de capacidade

Na seção prévia, foi apresentada uma metodologia para determinar uma estimativa inicial do número de clusters de cache, o número de hosts em cada cluster e a configuração desses hosts de cache. Porém, você deve reconhecer que esta é uma estimativa que pode mudar dependendo dos testes e também da monitoração contínua.

Se você decidir avançar em seus planos de usar o cache do AppFabric, pode criar uma prova de conceito para saber como ele funcionaria em sua solução. Depois disso, você pode configurar um cluster de cache de teste para realizar testes no seu ambiente. Dependendo dos resultados, faça alterações na configuração para cumprir os requisitos de capacidade, desempenho e escalabilidade. A seção a seguir cobre métricas contínuas específicas, que você pode analisar durante o teste e a produção.

Monitorando os requisitos contínuos de capacidade de cache

O planejamento de capacidade do cache nunca é uma ciência exata. Muitos dos números que entram nas conclusões são estimativas. Além disso, o uso e os padrões do aplicativo podem mudar com o tempo. Por esse motivo, você deve monitorar os indicadores de desempenho para certificar-se de que o cluster de cache está cumprindo os requisitos de capacidade. O sucesso no planejamento de capacidade é um processo contínuo, que se estende para os ambientes de teste e produção.

A ferramenta Monitor de Desempenho é a melhor maneira de monitorar a capacidade de uma maneira contínua. Em cada host de cache, recomendamos que você monitore os seguintes contadores:

Categoria de monitoração	Contadores do Monitor de Desempenho
Memória	Cache do AppFabric:Host\Total de Bytes do Tamanho dos Dados Cache do AppFabric:Host\Total de Objetos Removidos Cache do AppFabric:Host\Total de Execuções de Remoção Cache do AppFabric:Host\Total de Memória Removida Cache do AppFabric:Host\Número Total de Objetos Memória CLR do .NET(DistributedCacheService)\No. Gen 0 Coletas Memória CLR do .NET(DistributedCacheService)\No. Gen 1 Coletas Memória CLR do .NET(DistributedCacheService)\No. Gen 2 Coletas Memória CLR do .NET(DistributedCacheService)\No. de Objetos Fixados Memória CLR do .NET(DistributedCacheService)\% do Tempo em GC Memória CLR do .NET(DistributedCacheService)\Tamanho da Pilha do Objeto Grande Memória CLR do .NET(DistributedCacheService)\Tamanho da Pilha Gen 0 Memória CLR do .NET(DistributedCacheService)\Tamanho da Pilha Gen 1 Memória CLR do .NET(DistributedCacheService)\Tamanho da Pilha Gen 2 Memória\MBytes disponíveis
Rede	Interface de Rede(*)\Bytes Recebidos/s Interface de Rede(*)\Bytes Enviados/s Interface de Rede (*)\Largura de Banda Atual
CPU	Process(DistributedCacheService)\% Tempo do Processador Process(DistributedCacheService)\Número de Thread Process(DistributedCacheService)\Configuração Operacional Processor(_Total)\% Tempo do Processador
Produtividade	Cache do AppFabric:Host\Total de Solicitações do Cliente Cache do AppFabric:Host\Total de Solicitações do Cliente/s Cache do AppFabric:Host\Total de Solicitações Get Cache do AppFabric:Host\Total de Solicitações Get/s Cache do AppFabric:Host\Total de Solicitações Get Cache do AppFabric:Host\Total de Solicitações Get/s Cache do AppFabric:Host\Total de Solicitações GetAndLock Cache do AppFabric:Host\Total de Solicitações GetAndLock/s Cache do AppFabric:Host\Total de Solicitações Read Cache do AppFabric:Host\Total de Solicitações Read/s Cache do AppFabric:Host\Total de Solicitações Write Cache do AppFabric:Host\Total de Operações Write
Diversos	Cache do AppFabric:Host\Porcentagem de Erro de Cache Cache do AppFabric:Host\Total de Objetos Expirados Cache do AppFabric:Host\Total de Notificações Entregues

Muitos dos contadores listados aqui se referem diretamente ao processo do planejamento de capacidade. Por exemplo, há vários contadores de memória. "Memória\MBytes disponíveis" mostra a memória física disponível que permanece na máquina em megabytes. Se esse contador ficar abaixo de 10% da memória física total, há uma chance significativa de limitação. Para obter mais informações, consulte Solucionando problemas de limitação. Outros contadores são específicos do reursos de cache. "Cache do AppFabric:Host\Total de Execuções de Remoção" indica a frequência de remoção da memória. À medida que os níveis de memória passam da marca d'água alta, esse contador aponta para as execuções de remoção quando a memória é trazida de volta para a marca d´água baixa. Da mesma forma, outros contadores são associados ao processo de pensamento do planejamento de capacidade, encontrado nas seções prévias deste documento.

Observe que os contadores de processo para o serviço, DistributedCacheService e o contador Processador para a máquina, também são capturados. A alta utilização do processador pode afetar negativamente o desempenho do cluster de cache. Se você detectar períodos de alta utilização do processador, é importante identificar se ela é relacionada ao serviço de cache (DistributedCacheService.exe) ou outro processo na máquina.

Além da ferramenta Monitor de Desempenho, você pode usar os comandos Windows PowerShell que são instalados com o AppFabric. Muitos desses comandos podem ser usados para monitorar a saúde e o estado do cluster de cache. Para obter mais informações, consulte Ferramentas de monitoração da saúde e Registros e contadores no cache do AppFabric.

Consulte também

Outros recursos

Instalando o Windows Server AppFabric
Documentação de cache do MSDN Windows Server AppFabric
Guia de programação do cache do AppFabric
Configurando um provedor de estado da sessão ASP.NET
Opções de armazenamento da configuração do cluster de cache
Guia de gerenciamento e implantação de cache do Windows Server AppFabric
Links e recursos do Windows Server AppFabric e Windows Azure AppFabric

  2011-12-05