Este artigo foi traduzido por máquina.

Previsão: Nublado

Cache na função do Windows Azure

Joseph Fultz

 

Destina-se a noção antiga que a sorte favorece o preparado para transmitir a idéia de que não importa como a sorte que você é, você precisa estar preparado para capitalizar sobre a ocorrência de sorte. Muitas vezes eu pensei que esta declaração descreve a cache com bastante precisão. Se você tiver sorte o suficiente para o universo alinhar uma forma a alta utilização de unidade de seu site e os serviços, você estaria melhor preparada para servir o conteúdo rapidamente.

Em Janeiro, abordei alguns conceitos relacionados ao armazenamento em cache que focou bastante taticamente algumas abordagens de codificação (msdn.microsoft.com/magazine/hh708748). Com a adição das funções dedicadas e co-localizado para cache do cache Windows Azure (Preview), que vou me referir aqui como simplesmente cache Preview, senti que seria útil considerar como usar essas funções como parte da arquitetura de solução global. Esta não será uma cobertura exaustiva dos recursos de cache; em vez disso, é destinado a ser um designer do que fazer com os blocos grandes.

Um Cache por qualquer outro nome...

... não é o mesmo. Com certeza, a implementação do back-end é muito semelhante e, como seu antecessor compartilhado de cache do Windows Azure, cache Preview moverá os dados que você busca no cliente do cache local. Mais importante, porém, cache Preview apresenta alguns recursos faltando do Cache compartilhado, então mudar para o cache baseado em papel não só expande o conjunto de recursos disponíveis, ela também lhe dá melhor controle sobre a arquitetura de implantação. Para começar, vamos esclarecer a diferença primária entre as funções dedicadas e co-localizado: configuração.

Ao configurar os nós de cache, você tem a opção de dedicar o papel todo o cache ou anulação apenas uma porcentagem do papel. Apenas como uma forma de rapidamente considerar as implicações da reserva memória RAM para o cache co-localizado, dê uma olhada no Figura 1, que mostra o restante RAM utilizável após a reserva de cache. (Observe que a opção co-localizado não está disponível na instância do X-pequeno).

Figura 1 restantes RAM

Muitas vezes o primeiro pensamento é simplesmente escolher alguns tamanho médio ou pequeno e alocar certa quantidade de memória. Como a quantidade de memória alocada é suficiente para seu uso pretendido e dentro do limite da RAM disponível, esta é uma abordagem muito bem. No entanto, se o número de objetos é alto e há uma expectativa razoável de que o cliente de cache em cada máquina pode estar segurando seu número máximo de objetos, o resultado poderia ser pressão de memória inesperado. Além disso, muito pouco cache RAM poderia levar a despejos de cache indesejados, reduzindo a eficácia global do cache.

Figura 2 mostra o percentual de uso de RAM com base no tamanho da máquina virtual (VM). O gráfico baseia-se no msdn.microsoft.com/­biblioteca/hh914152, que mostra a quantidade de RAM disponível para o cache em modo dedicado.

Figura 2 Cache usar papel dedicado

Tamanho da máquina virtual	Memória disponível para armazenamento em cache	% de uso de memória RAM com base no tamanho da máquina Virtual
Pequeno	Cerca de 1 GB	57%
Média	Cerca de 2,5GB	57%
Large	Cerca de 5,5GB	79%
X-grande	Cerca de 11GB	79%

Na minha grade co-localizados (Figura 1), não ultrapassam 40 por cento de alocação para o tipo co-localizado porque eu supus que eu precisaria de uma maioria da RAM para o aplicativo. Em comparação, a versão dedicada geralmente fornece mais memória RAM, mas parece atingir a máxima eficiência de alocação de memória RAM no tamanho grande VM. Nesse sentido, duas VMs médios são menos útil do que um grande. Naturalmente, uma grande instância não pode ajudar com opções de alta disponibilidade (HA), que duplica seus dados, que você pode querer em sua infra-estrutura de armazenamento em cache. Ainda assim, vale a pena as necessidades de espaço contra a necessidade de redundância de pesagem e escolhendo uma configuração que não só atende necessidades técnicas, mas também otimiza o custo.

Em cache é feito propositadamente, uma seca de RAM normalmente não é um problema. No entanto, em casos onde o cache compartilhado é usado para fazer objetos de sessão e/ou o cache de saída, a situação é um pouco mais desafiadora devido a tendência de usar a sessão para tudo e a dificuldade na previsão de carga exata. Por exemplo, se você estiver executando um app de Model-View-Controller que tem modelos profundos estiver colocando na sessão e você aumenta o número máximo de objetos para o cliente de cache, você pode encontrar resultados indesejados sob uma carga de médio ou grande. Isso seria de superfície como mais lento desempenho do site causado por despejo de cache compartilhado, de pressão de memória, que você não esperava; não se esqueça, o cliente de cache é provavelmente segurando mais RAM do que o esperado devido à combinação de uma contagem de objeto máximo aumentado e um gráfico profundo. O framework ajuda você um pouco comprimindo objetos serializados, mas para um recurso precioso e finito como RAM, diligência na contabilidade é a melhor prática, especialmente quando tentando compartilhar a memória RAM entre aplicativo, cache de saída, objetos de sessão, cache de dados e cliente de cache. Para ajudar você em seu cache de dimensionamento, a Microsoft publicou a planilha de guia de planejamento de capacidade, o que você pode encontrar em msdn.microsoft.com/library/hh914129.

Regiões

Regiões adicionam alguma funcionalidade agradável, mas a um custo. O custo é que a região é fixada em um único servidor, forçando todas as solicitações para objetos na região para ser um gargalo através desse host de cache quando ele não é armazenado no cliente do cache. A vantagem é que usando regiões fornece capacidade de marcação. Meu favorito uso das regiões é armazenar dados de referência pre-fetched. Isso pode parecer loucura no início, por causa do problema de gargalo, mas vamos ver.

Considerar o uso de cache, vamos postular que tenho um catálogo de 10.000 produtos com até oito variantes para cada produto, ou seja, um catálogo de itens potencialmente 80.000. Se cada objeto representa um item de médias 1 K, que é cerca de 82 MB shuffle em torno de cada pedido, como também ocupam espaço no cliente de cache. Além disso, haverá algum número de catálogos virtuais que são uma completa cópia ou subconjunto do original, isso pode acabar com uma explosão de dados de referência a ser baralhadas, tudo servido pelo host única região (ver Figura 3).

Figura 3 disposição de Cache com uma única região

No entanto, com um pouco de trabalho posso criar mais regiões para conter subseções dos dados. Por exemplo, eu poderia quebrar meu catálogo em departamentos ou segmentos. Poderia, por exemplo, criar uma região para produtos de consumo e outra para produtos profissionais, resultando em algo como o que é mostrado no Figura 4.

Figura 4 Cache Layout com duas regiões

Isso fornece um pouco mais granularidade no cache, permitindo o uso de pequenos papéis para manter todos os meus objetos de cache, facilitar atualizações do cache e diminuir o tráfego, reduzindo as consultas a cada função e filtrando através do uso de consultas de marca.

A capacidade de conteúdo da marca é a principal função de condução o uso de regiões. Assim, pode marcar o conteúdo no meus catálogos; para computadores, por exemplo, eu poderia ter etiquetas tais como: "laptop," "4 GB", "8 GB", "15 pol," "HD Audio", "Desktop" e assim por diante. Dessa forma eu posso permitir que tais elementos de interface do usuário como uma pesquisa de produto facetada para navegação usando uma chamada para um dos métodos de GetObjectsByTag. Isso também significa que o acesso a dados de reengenharia da camada e, em algum aspecto, tratando o cache mais como dados primários de origem pelo qual as consultas sobre as facetas (tags) de dados são satisfeitas.

Uma forma interessante de aproveitar este recurso é usar tabelas de armazenamento do Windows Azure como armazenamento de dados back-end, mas pré-buscar os dados, marcá-lo e colocá-lo em cache. Isso fornece alguns da filtragem ausente da Encarnação atual de armazenamento tabelas, mantendo os custos ao mínimo.

Usar regiões oferece muita flexibilidade na recuperação de dados em cache, mas observe o tipo específico de estirpe coloca sobre a infra-estrutura de implantação. Ainda, as regiões são úteis como um meio de pré-buscar e acessar dados de referência.

Alta disponibilidade

Há uma coisa engraçada a considerar com caches HA — você usar um cache HA que para ter cuidado, mas você precisa ser cuidadoso ao usar HA. Pelo menos, você precisa ser apropriadamente pensativo sobre o que realmente precisa ser altamente disponível.

Porque cada função habilitada para duplicação duplica a quantidade de espaço necessário para os objetos reais, você correr para fora de RAM muito mais rápido. Assim, por uma questão de design, é melhor usar HA apenas para aqueles recursos que necessita ou que iria melhorar muito UX modo drive não arbitrariamente os custos ou provocar artificialmente desalojamento cache devido à fome de memória resultantes do consumo excessivo de caches duplicados.

Eu vi algumas orientações que sugere colocar objetos de sessão em cache HA assim você pode consultar todos usuários em sessões ativas, com base em certos valores de marca. Na maioria dos casos, esta não seria uma abordagem útil como injustamente distribui a carga ao recuperar objetos de sessão do cache; Esse padrão de carga deve seguir mais de perto o balanceamento de carga do site. Além disso, porque você também pode ter um monte de perfis anônimos vazios além de utilizadores registados sob identificado, procura de entidades, como perfis de usuário baseado em marcas são realmente mais limitante do que útil.

Eu sugiro que você coloque objetos de usuário, sessões, cache de saída e similares em seus próprios caches nomeados, mas não ativá-los para a duplicação. Em casos onde editar dados são vinculados a uma sessão, você pode considerar o backup da sessão com um cache HA dependendo de onde você está no ciclo de vida do aplicativo. Se o aplicativo ainda está sendo projetado e criado, é melhor separar os objetos de estado in situ e colocá-los em um cache HA fora da sessão. Isso permite que você gerencie os editar dados relacionados a um usuário além do escopo da sessão e manter a sessão em um muito mais uniformemente distribuídos cache. No entanto, se seu aplicativo é mais ao longo e você tem dados que não deseja perder por razões de facilidade de uso apenas que estão ligados ao objeto de sessão ou jurídicos, financeiros, é aceitável para apenas uma sessão de fio para o cache HA-apenas certifique-se especificamente de salientar que em seus testes de carga e saber os limites da execução. Além de dados que é importantes devido ao seu conteúdo ou seu ponto em um processo de­— tais como interface de dados fazendo uma edição — os tipos de dados que são alvos de imediatos para HA são conjuntos de grande referência, pre-fetched de dados e dados pré-calculados.

O ponto comum entre todos estes é o custo para pré-buscar que os dados novamente. No caso de dados pré-calculados ou pre-fetched referência, o start-up custo para prime o cache pode ser bastante significativo e perder os dados durante a execução pode ter um impacto grave e até mesmo catastrófico sobre a execução do site. Figura 5retrata como o cache de objetos pode ser repartido com HA ligado. Porque as duplicatas devem ser em um domínio diferente de falha, você pode ver como as duplicatas reduzem a RAM total disponível para o cache. Este não é dizer sempre é ruim, tanto quanto é para dizer que é o que é necessário. Eu simplesmente estou sugerindo uma consciência do impacto potencial de HA.

Figura 5 alta disponibilidade e domínios de falha

Casa de Lego

Os desenvolvedores muitas vezes gostam de pensar o desenvolvimento como construção com blocos de Lego; Crie os blocos básicos e snap-los juntos em uma aplicação útil. Esta idéia permanece verdadeira mesmo quando passamos mais acima da pilha do aplicativo de funções para objetos para componentes de infra-estrutura. Para o efeito, quero deixá-lo com alguma orientação de design.

Primeiro, use todas as ferramentas para sua vantagem. Não estabeleça apenas HA ou não HA porque uma forma é mais fácil. Não use apenas baseada em região caches porque você pode pesquisá-los; ou renunciá-los porque eles ficar preso a uma instância. Em vez disso, Construa sua infra-estrutura de armazenamento em cache para atender às suas necessidades.

Figura 6 mostra as funções dedicadas eu uso para abrigar meus caches duplicadas e as regiões que eu uso para caches mais ricamente pesquisáveis. Como regra geral, sou a favor da funções de cache dedicado para regiões de moradia, porque eu não quero carregar um papel que está servindo de tráfego do usuário com todo o tráfego para buscas de cache relacionados a uma determinada região. A linha inferior na Figura 6 retrata usando o estilo co-localizado de cache para armazenar sessão, saída e vários outros dados que pode armazenar em cache durante a execução do meu pedido. Isto não é para dizer que estou preso com dedicado ou co-localizados papéis como retratado, como que depende na maior parte dos requisitos de RAM dos itens que pretendo cache nos papéis. Na verdade, para muitas implementações, a linha de fundo só irá fazer o truque sem necessidade de HA, regiões ou a grande quantidade de RAM pelo papel dedicado.

Figura 6 possibilidades de implantação de Cache

Finalmente, Figura 7 é uma grade que identifica meu Iniciar aponte para diferentes tipos de dados quando estou pensando em como projetar meu implantação de cache.

Figura 7 preferências de configuração

Tipo de dados	Usar HA	Região de uso	Dedicado	No mesmo local
Sessão				X
Saída				X
Dados gerais			X	X
Fetch	X		X
Pré-calc	X		X
Dados importantes	X
Filtráveis		X	X

Isso é em nenhuma maneira pretende ditar o uso ou sugerir um papel ou característica é útil somente para o slot que eu identifiquei. É apenas meu ponto de partida. Se eu tivesse um grande conjunto de dados pre-fetched que eu queria ser capaz de Pesquisar por marca, eu seria combinar os itens que eu marquei, terminando com um papel de cache dedicado que usa regiões e HA. Como um exemplo de quando pode desviar do meu ponto de partida, se tiver um aplicativo implantado que usa a sessão para seus modelos de cache, enquanto o usuário edita dados, eu provavelmente iria atirar minha tendência para colocar a sessão em cache co-localizado e não apenas colocá-lo em um papel dedicado, mas permitir HA também.

Então, se você tiver sorte o suficiente para ter um site ocupado, certifique-se de sua sorte vai continuar preparando corretamente sua infra-estrutura de armazenamento em cache.

Joseph Fultz é arquiteto de software da Hewlett-Packard Co. e trabalha no grupo de TI global do HP.com. Anteriormente, era arquiteto de software na Microsoft, trabalhando com seus clientes empresariais e ISV de camada superior, para definir soluções de arquitetura e design.

Agradecemos aos seguintes especialistas técnicos pela revisão deste artigo: Rohit Sharma e Hanz Zhang