You are currently browsing the tag archive for the ‘AppFabric Caching’ tag.

Olá pessoal.

Segue uma lista das apresentações relacionadas ao Windows Server AppFabric e Windows Azure AppFabric que aconteceram no Teched Americano.

 

 

Abraços,

@daibert

Anúncios

Olá pessoal.

O Windows Server AppFabric Caching 1.0 (no Windows AZURE AppFabric Caching 1.0, não existe esta funcionalidade) permite que sejam utilizados chamadas de CallBack para notificação de eventos assíncronos, assim como no WCF.

Desta forma, qualquer alteração nas regiões do Cache ou nos itens armazenados, irão disparar as notificações assíncronas para o cliente.

O cliente receberá as notíficações no caso de uma alteração no nível de Região do Cache:

  • CreateRegion: Quando uma Região é criada no Cache.
  • ClearRegion: Quando os itens de uma Região são limpas do Cache.
  • RemoveRegion: QUando uma Região é removida do Cache.

O cliente receberá as notificações no caso de uma alteração em um dos objetos, ou Itens armazenado no Cache:

 

Cache Notification Scopeorem

Criação do Cache

 

Deve-se ficar atento na hora da criação do Cache para cria-lo com a opção de notificação de eventos habilitado. O padrão da criação de um novo Cache é com a notificação de eventos desabilitada e isto ocasionará um erro quando tentarmos registrar o CallBack para o nosso Cache como abaixo:

 

image

 

image

 

Criar o Cache já com o CallBack habilitado:

[PowerShell] New-Cache Lab5Cache -NotificationsEnabled true

Desta forma, o Cache será criado com a opção de notificações habilitada.

Neste exemplo, eu criei dois Caches. O Lab06Cache com a notificação desabilidata e o Lab5Cache com a notificação habilitada.

Podemos ver as configurações de um Cache utilizando o comando Get-CacheConfig.

image

image

 

Vale lembrar novamente que as notificações de evento NÃO SÃO suportadas no Windows Azure AppFabric Caching 1.0, somente são suportadas no Windows Server AppFabric Caching 1.0.

Abraços,

@daibert

Olá pessoal. Finalmente tive tempo de ler a versão atualizada do benchmark do Windows AppFabric Caching feita pela empresa GridDynamics. Ela havia feito este teste ano passado com o ctp3 do ainda então “velocity”. Esta é a versão do teste feita com o produto final. Algumas diferenças significativas são apresentadas. Vale a pena a leitura e o estudo do código fonte.

 

http://www.griddynamics.com/images/files/af_cache_benchmarking_1.4.pdf

tp://www.griddynamics.com/images/files/AppFabricCacheBenchmarkingSource.zip

Abs,

Daibert

clip_image001

Olá pessoal. No Keynote do Bob Muglia no PDC 09  foi apresentado uma Demo (cruz credo! rs) que cobre as tecnologias ASP.NET MVC 2 beta, Windows Identity Foundation RTM,  e o beta do Windows Server AppFabric.

Esta Demo é o Tailspin Travel application, que já está disponível no codeplex neste endereço: http://tailspintravel.codeplex.com/ .

A aplicação é um marcador de viagens. A idéia é bem simples, mas a aplicação é muito bem feita. Ele cobre praticamente todas as novas funcionalidades das tecnologias e permite que você mude o comportamento da aplicação em Runtime  para poder testa-las.

Essa é a relação de funcionalidades cobertas pela Demo:

Visual Studio 2010

  1. Assembly Dependency Graph
  2. Multi-monitor Tailspin Travel
  3. Navigate To dialogue
  4. IntelliTrace
  5. New WF designer
  6. MSDeploy
  7. Coded-UI tests

.NET Framework 4

  1. ASP.NET MVC 2
  2. Windows Identity Foundation
  3. Windows Workflow Foundation
  4. Windows Communication Foundation
  5. Entity Framework

Server Platform

  1. Windows Server AppFabric
    1. Service Hosting
    2. Workflow Hosting
    3. Caching
    4. Monitoring
  2. SQL Server 2008 R2
    1. DAC – Data-Tier Application

 

Você precisa do Visual Studio 2010 Beta 2 Ultimate para abrir e compilar o código. O SQL Server 2008 R2 só é obrigatório para o deploy do Data-Tier Application. Baixei e rodei nas minhas VMs com SQL 2008 sem problema.

Ufá, muita coisa pra estudar e, instalar tudo isso leva um bom tempo. Vou tentar fazer ainda esta semana um post explicando com o instalar e configurar o AppFabric + Tailspin Demo.

Para preparar o ambiente, além do Visual Studio 2010 Beta 2 Ultimate você precisará dos seguintes produtos:

Por enquanto é só.

 

Atualizado em 25 de novembro de 2009:

Algumas pessoas me falaram que durante a verificação de dependência apareceu o erro: "AuthorizationManager check failed.". A solução é bem simples e está descrita aqui: http://tailspintravel.codeplex.com/Thread/View.aspx?ThreadId=76189

Abraços,

Daibert

Olá pessoal. Aqui em Seattle as semanas tem sido bem puxadas, mas hoje eu consegui um tempo para um pequeno post com os principais comandos para administração do AppFabric Caching.

Vale a pena destacar que o AppFAbric, em verdade, são dois produtos que AINDA estão se integrando. O AppFabric (“Dublin”)  possúi uma interface de administração integrada ao IIS, assim como o WAS. Já o AppFabric Caching (“Velocity”) não possúi interface gráfica para administração e não se integra a console do IIS. Desta forma, é necessário que a administração do Cluster do cache distribuído seja feita via linha de comando PowerShell.

Administrando o CacheCluster:

  1. Start-CacheCluster
  2. Stop-CacheCluster
  3. Restart-CacheCluster

Administrando o CacheHost:

  1. Start-CacheHost [-HostName] <HostName> [-CachePort] <CachePort>
  2. Stop-CacheHost [-HostName] <HostName> [-CachePort] <CachePort>
  3. Restart-CacheHost [-HostName] <HostName> [-CachePort] <CachePort>
  4. Get-CacheHost
    a.Apresenta os “cache host servers” no cluster ativo e seus status

Administrando o Cache:

  1. New-Cache –CacheName <cacheName>
  2. Remove-Cache –CacheName <cacheName>
  3. Get-Cache [-HostName] <HostName> [-CachePort] <CachePort>
    a.Apresenta a lista de caches e regions em um cache host específico
    b.Se nenhum HostName e CachePort for passado como parâmetro, será apresentado a lista de todos os hostnames no cluster
  4. Get-CacheStatistics –cacheName <cacheName>
    a.Apresenta os status do cache como tamanho, número de itens

Se você quiser ter mais informações sobre o comandos possíveis via PowerShell, digite Get-CacheHelp na linha de comando.

Para conhecer melhor a administração do AppFabric via PowerShell, acesse este link: Cache Administration with Windows PowerShell http://msdn.microsoft.com/en-us/library/ee790886.aspx

Abraços,

Daibert

Olá pessoal. Ainda estou migrando o conteúdo do blog antigo para cá. Este post foi feito em 2008 e mostra dois ArqCasts que fiz junto com o pessoal do time de Arquitetos da Microsoft Brasil sobre o AppFabric Caching, na época ainda chamado de “Velocity”. Vale conferir.

 

image

image

 

Abraços,
Daibert

Boa noite pessoal. As coisas andaram meio corridas por aqui, mas agora ja’ estao normalizando (tirando o meu teclado rs). No dia 26 de Janeiro passado eu fiz um Webcast para a comunidade do MSDN Brasil que contou com a presenca de cerca de 41 pessoas.  Este Webcast foi focado em conceitos e na arquitetura do produto. Ja estou preparando o segundo Webcast que sera focado em desenvolvimento para o "Velocity". Estou colocando o link da gravacao dessa apresentacao aqui e em breve vou disponibilizar o pptx tambem.

Abracos,

Daibert

Complementando o post anterior, vou falar sobre os componentes lógicos do "Velocity" CTP2.

Como vimos anteriormente, o Core do "Velocity" é um Windows Service instalado em uma ou mais máquinas. Esse Windows Service lê as informações do Cluster Configuration Storage Location e inicia a comunicação entre os nós do Cache Cluster. Antes de começarmos a codificar precisamos entender alguns conceitos sobre Caches distribuídos. Os componentes lógicos do "Velocity" serão listados a seguir.

Componentes Lógicos

Named Cache: É a unidade lógica que armazena os objetos na memória e que se espalha por todos os nós do cluster. Fazendo uma grosseira analogia com os bancos de dados relacionais, o Named Cache seria o Database em nossa estrutura física do SQL Server. Assim como no SQL Server, podemos ter vários Named Cache em um cache cluster. Cada Named Cache é independente, isto é, pode ser configurado separadamente.
Logo após a instalação do "Velocity" um Named Cache padrão chamado "Default" é criado. Para criar novos Named Cache pode-se utilizar o ambiente de administração do "Velocity" via Power Shell, ou, se um Named Cache além do "Default" for sempre utilizado, pode-se inserir esse parâmetro no arquivo de configuração do "Velocity", caso tenha sido escolhido o XML-based cluster configuration storage.

Criando um Named Cache via Power Shell: 

PS> New-Cache -CacheName <CacheName>

Configurando um Named Cache via XML-based cluster configuration storage:

Quando utiliza-se o XML-based cluster configuration storage são criados 2 arquivos na pasta compartilhada. São eles:

  • ClusterConfig.xml: Arquivo texto baseado em XML com as configurações do cache cluster que é lido durante a inicialização do serviço do "Velocity".

  • ConfigStore.sdf: Arquivo baseado em SQL Server Compact data file utilizado para armazenar informações de operação como a lista dos nós do cluster que estão no ar. Note que em nenhum momento os dados dos objetos colocados no cache do "Velocity" são persistidos em disco.

Essa sessão configura o nome do cache cluster:  

<

dcache cluster="ClusterName1" size="Small">

Quando o cache cluster é criado, logo em seguida o "Velocity" lê a sessão <cache> e configura os Named Cache para aquele cluster.

<

caches>
<!–
Specifies the default cache –>
<!–
(High Availablity disabled)–>
<
cache type="partitioned" consistency="strong" name="default" replicas="1"
minWriteQuorum="1">
   <
policy>
      <
eviction type="lru" />
      <
expiration defaultTTL="10" isExpirable="true" />
   </
policy>
</
cache>

Acima é o Named Cache default, que vem pré-configurado com a instalação do "Velocity".

Para criar um novo Named Cache basta adicionar uma nova sub-sessão <cache> dentro da sessão <caches> conforme abaixo:

<!–

Specifies the new cache –>
<!–
(High Availablity enabled)–>
<
cache type="partitioned" consistency="strong" name="MEU-NAMED-CACHE" replicas="2"
minWriteQuorum="2">
   <policy>
      <
eviction type="lru" />
      <
expiration defaultTTL="10" isExpirable="true" />
   </
policy>
</
cache>

Pronto, dessa maneira toda vez que o "Velocity" iniciar o primeiro nó do cluster cache ele criara além do Named Cache default o Named Cache configurado. Em outro post falarei com mais detalhes do arquivo de configuração e suas sessões.

Regions: Voltando a fazer uma grosseira analogia com os banco de dados, assim como os Named Cache podem ser comparados com databases dentro do SQL Server, as Regions podem ser comparadas com as tabelas dentro dos databases do SQL Server. A diferença aqui é que a utilização de uma Region não é obrigatória. Podemos ter Cached Objects no nível dos Named Cache ou no nível das Regions como pode-se ver na figura acima. 
A escolha por utilizar ou não Regions afeta diretamente a performance e escalabilidade da solução. Quando utiliza-se Regions temos um resultado na busca dos Cached Objects muito mais rápido do que sem Regions, porém perdemos a alta disponibilidade, pois uma Region só fica hospedada em uma única máquina do cache cluster. Já quando não utilizamos Region, os Cached Objects são distribuídos por todos os hosts do cache cluster permitindo a alta disponibilidade porém com uma performance de busca um pouco pior.
O projeto de arquitetura deve levar em conta uma série de fatores para decidir o modelo de persistência em memória dos Cached Objects. Por esse motivo esse assunto será abordado em um post exclusivo.

Cached Objects: Na mesma linha das analogias grosseiras, os Cached Objects seriam as linhas das tabelas. O "Velocity" permite armazenar qualquer CLR Object. Todos os objetos quando são recuperados retornam como System.Object o que obriga o type cast para o tipo original como no exemplo abaixo:

//Create the cache object
Cache Cache1 = CacheFactory1.GetCache(strCacheName);

//Call the Get method
string strCacheItemValue = (string)Cache1.Get(strKey);

Bom, falarei mais sobre arquitetura do "Velocity" em outros posts. Especificamente o próximo post sobre arquitetura será sobre o modelo de comunicação interno do cache cluster.

Abraços a todos.

Daibert

Com o lançamento em outubro do CTP2 do "Velocity" algumas novidades foram inseridas como a interface de administração baseada em Power Shell 1.0. Este post visa apresentar os principais componentes físicos do projeto e suas terminologias.

O "Velocity" é uma série de componentes interligados que podem ser instalados em um ou mais servidores e que são enxergados pela aplicação cliente como um único repositório de dados em memória

O core do "Velocity" é um serviço Windows instalado em cada um dos nós do cluster. Outros componentes são os scripts Power Shell para administração do cluster e o repositório de configuração do cluster.

Componentes Físicos

Cache Hosts: O "Velocity" roda em uma ou mais máquinas físicas, ou Hosts, como um Windows Service.

Cache Cluster: É o conjunto de instâncias, nós ou Hosts que se comunicam e são enxergados como um único repositório de dados em memória.

Cluster Configuration Storage Location: Local aonde as informações como tamanho de memória por nó do cluster, endereço dos nós do cluster na rede estão armazenadas. No CTP1 somente era possível utilizar o XML configuration file. Já no CTP2 pode-se utilizar o SQL Server database, SQL Server Compact data file, ou o próprio XML configuration file.

PowerShell-Based Cache Administration Tool: No CTP1 a administração do "Velocity" era feita via uma aplicação console que não suportava scripts, o que limitava algumas tarefas administrativas. Já no CTP2 o Power Shell 1.0 ou o 2.0 (beta) são o ambiente de administação do "Velocity" com uma série de scripts para iniciar e parar o cluster, adicionar novas máquinas no cluster entre outros.

O próximo post será sobre os componentes lógicos do Serviço de Cache do "Velocity".

Abraços,

Daibert

Olá pessoal. Este post apresentará os tipos de cache que podemos ter no “Velocity. É muito importante conhecer e entender como funcionam cada tipo de Cache para definir a melhor arquitetura de Cache para sua solução.

Cada aplicação trabalha com um tipo específico de dados. Eles podem ser dados de consulta, dados transacionais ou dados distribuídos. O tipo de dado que sua aplicação acessará afetará diretamente na arquitetura de Cache que se deve propor.

Por isso vamos conhecer um pouco sobre esses tipos de dados.

DADOS DE CONSULTA

São dados agregados ou trasformados e tem a caracteristica de cada versão do dado ser única.

Dados pouco atualizados ou atualizados com baixa frequência

EXEMPLOS:

  • Alicações Web e Coorporativas como catalogos de produtos
  • Usuários, Dados de Funcionários

TIPO DE ACESSO:

  • Maior quantidade de leitura
  • Acesso concorrente e compartilhado

ESCALABILIDADE:

  • Maior número de acessos

FUNCONALIDADE:

  • Acesso baseado em chaves
  • Buscas e filtro
  • Carregamento local (Servidor Web)

image

DADOS TRANSACIONAIS

São dados gerados a partir de atividade transacionais nas aplicações.

EXEMPLOS:

  • Carrinho de compras
  • Session State
  • Aplicações coorporativas B2B

TIPO DE ACESSO:

  • Leitura e gravação
  • Acesso exclusivo

ESCALABILIDADE:

  • Muitos dados e acessos simultâneos

FUNCAIONALIDADES:

  • Acesso baseado em chaves
  • Transações

 

image

 

DADOS DISTRIBUÍDOS

São dados existentes em mais de uma fonte de dados.

EXEMPLOS:

  • Dados alterados por transações
  • Transações “distribuídas”
  • Inventário de venda de passagens

TIPO DE ACESSO:

  • Leitura e gravação
  • Acesso compartilhado aos dados

FUNCAIONALIDADES:

  • Acesso baseado em chaves
  • Transações
  • Escalabilidade
  • Grande número de acessos simultâneos

image

Agora que já conhecemos os tipo de dados que podemos trabalhar, ver os tipos de Cache que podemos utilizar com o “Velocity”.

CACHES DISTRIBUÍDOS

Os Caches do tipo distribuídos podem ser classificados em particionados e replicado.

PARTICIONADO

  • Dados divididos por todos os nós no mesmo named cache
  • Usado para escalabilidade e disponibilidade

Exemplo:

  1. Put (K2, V2) executado na aplicação do Cliente1
  2. Camada de roteamento envia o item V2 para o Cache2
  3. Get (K2) executado na aplicação do Cliente2
  4. Cliente 2 roteia para o Cache 2 para pegar o item V2

image

REPLICADO

  • Dados replicados (copiados) para todos os nós no mesmo named cache
  • Usado para escalabilidade (Performance / Leitura)

Exemplo:

  1. Put (K2, V2) no Cache1
  2. Cache2 é atualizado e notifica o Cache1 e o Cache3
  3. Cache2 replica de forma assíncrona os dados para o Cache1 e Cache2
  4. Get(K2) no cache3
  5. O Cache 3 lê do seu repositório local os dados e retorna o valor do Item

image

CACHE LOCAL

O Cache local pode acelerar acesso aos dados no cliente pois ele mantém o Cache no processo da aplicação para dados privados utilizados com frequência e com isso a carga dos dados fica no cliente.

Exemplo utilizando Cache Particionado com Cache Local.

  • Put (K2, V2) executado na aplicação do Cliente1
  • Camada de roteamento envia o item V2 para o Cache2
  • Get (K2) executado na aplicação do Cliente2
  • Cliente 2 identifica que o dado solicitado existe no Cache Local da aplicação e busca este dado localmente, evitando a “viagem” até o nó do Cache aumentando consideravelmente a performance de leitura aos dados.

     

    image

     

    No próximo post vou falar sobre arquitetura de Cache em Alta Disponibilidade.

    Por enquanto é só.

     

    Abraços,

    Daibert

  • Atualizações Twitter