Module 1–Windows AppFabric Cache Introduction and Architecture

Outline Why caching? Introduction to Windows Server AppFabric Cache Overview of Cache features

Typical Web Architecture Need to route users to same machine (i.e. sticky sessions) Users Each machine round trips for data Some data might be expensive to retrieve Cached data is typically stored in the memory of one (each) server Web Tier CPU and disk can get saturated due with an increase traffic Database

Why use caching? Most applications end up needing Robustness Speed Scalability This is especially true in the web world Need to scale can sneak up quickly Almost any web application can benefit from caching Services can benefit as well

Core caching concepts Caching Distributed Caching Expiration Eviction Storing a copy of data closer to application logic, away from its source Distributed Caching A set of nodes in a farm that coordinate to create a unified view of a cache to a caching client Expiration When an object is removed from the cache because of staleness Eviction When an object is removed from the cache due to low memory conditions

What is the AppFabric Cache? A Distributed cache for “data” In-memory cache Uses an explicit API The “Data” can be CLR Object XML Binary data Optimized for the cache-aside pattern in this version Programming against the cache is explicit Changing the cache doesn’t update the original data store

What is Windows Server AppFabric? A set of technologies and capabilities integrated into Windows Server and IIIS Designed to make building, managing, and scaling IIS applications easier Ships as part of Windows Server AppFabric 2010 Wave 1 Part of Windows Server HA requires Windows Server 2008 Enterprise or DataCenter Editions. Requires .NET 4.0 WORKFLOW HOSTING MONITORING CACHING SERVICE HOSTING ACCESS CONTROL High Availability Scale Out Multi-Tenant Management

AppFabric architecture Cache runs on N nodes Nodes that share configuration are part of a single Cache Cluster Runs as a Windows Service (one service per server node) Typically not the same servers as the client (web) tier More memory is better In-memory copy cache is optional setting (“Local Cache”) All the cache nodes in a cluster are part of a fabric Share configuration Communicate Cooperate Same algorithms that support Windows Azure’s fabric

Stripped memory across server nodes CacheServer#1 CacheServer#2 CacheServer#3 Cache Cluster obj#4 obj#3 obj#2 obj#1 Objects in memory

AppFabric Cache Users Web Tier Caching Tier Database No stick load balancing needed – all servers have copy of cached data Users Easy access to cache cluster Web Tier Multiple machines means scale and potential for high-availability More machines == more memory for cache objects Caching Tier Reduces load on database Database

AppFabric Cache advantages Native .NET API Scalability Performance Typically linear as more nodes are added LocalCache increases raw performance High Availability Distributed nature safe guards against cache client and server failures

Installation and configuration Installs as part of Windows Server AppFabric Not dependent on other AppFabric features (e.g. service and workflow management) First node creates cluster configuration Other nodes are configured to just join existing cluster Nodes can be added to or removed from the cluster at any time – cluster automatically reconfigures itself

Cache Cluster configuration Configuration abstracted behind a provider model OOB providers SQL Server Database Network share (XML file) Configuration Provider model open

Cache size configuration You must configure “projected” size 1-5 nodes (small) 6-15 nodes (medium) > 15 nodes (large) Cache optimizes itself based on this setting Setting not affected by actual number of nodes added to cluster You can change this (and other) configuration settings on a stopped cluster

Remember – PowerShell can also be called from .NET Code! Administration PowerShell cmdlets are used to administer the cache cluster Remember – PowerShell can also be called from .NET Code!

Cache creation Caches are named constructs Partition design based on Multiple items can live in one named cache Key for each item must be unique Partition design based on High availability requirements Grouping based on logic New-Cache cmdlet Each named Cache can have its own settings for Availability Expiration Eviction

Cache Clients Rich API Can be .NET 4.0 or .NET 3.5 SP1 Centers around the DataCache type Can be .NET 4.0 or .NET 3.5 SP1 WCF NetTcpBinding used under client API Can be configured in code or config Simple configuration – server name and port Can configure N servers Configuring max N is recommended Client is “smart” Requests routes to cache node where data lives automatically Routing table updated on a constant basis by cache cluster Client essentially becomes part of the cluster fabric Local cache configured at client Local cache automatically updated (no guaranteed speed)

Programming the cache //create DataCacheFactory based on config file var dcf = new DataCacheFactory(); //get the cache named "TestCache" var cache = dcf.GetCache("TestCache"); //Add an item called "Test" - throws if exists cache.Add("Test", new Data { TheData = "Test" }); //Put an item called "Test2" - overwrites if exists cache.Add("Test2", new Data {TheData = "Test2" }); //Get "Test3" - add if not in cache (cache-aside) var test3 = cache.Get("Test3") as Data; if (test3 == null) { test3 = new Data {TheData = "Test3" }; cache.Add("Test3", test3); }

Client API Clients can specific named Regions for items Regions are stored on one cache host only Created implicitly if not specified Cache Items can be tagged Tagging enables items to be retrieved without specific knowledge of the item Client can register for notification of cache events Bulk API available as well

Security Domain Based Security Option On by default Domain Account / Local Account based Authentication Only authorized servers can join the cluster Only authorized clients can connect to the cluster Transport Level Security Turn on/off Signing or Encryption Can turn off Cache Security Security always has a performance implication Use Firewalls, IPSec, VLANs to protect cache grant-cacheallowedclientaccount  MyDomain\Machine1$ grant-cacheallowedclientaccount  MyDomain\Jon

Management PowerShell enables configuration and some monitoring Logging Cache participates in ETW tracing Logging available on both client and server Rich set of performance monitor counters for monitoring both cache and host performance

ASP.NET Session Provider Custom Session Provider included with Cache Just a configuration change enables session state to be cached across a cluster You may want to enable HA on the cache used <sessionState mode="Custom" customProvider="SessionStoreProvider"> <providers> <add name="SessionStoreProvider" type="Microsoft.ApplicationServer.Caching.DataCacheSessionStoreProvider, Microsoft.ApplicationServer.Caching.Client, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" cacheName="BlueYonderSession"/> </providers> </sessionState>

Caching Patterns It is extremely useful to classify the type of data you are going to cache as either: Resource, Activity, or Reference Data Classification will inform what features to use Use the correct feature for the correct type of data Will help you to design the property number of caches i.e. No need for HA for Reference data More on this later

Summary Windows Server AppFabric Cache is a distributed application cache Caching is important to application scalability Explicit caching API available to .NET 3.5 SP1 and .NET 4.0 ASP.NET Session provider an implicit way to take advantage of the Cache’s capabilities

Questions?