Introduction to Windows Server AppFabric. Caching Services

One of the fundamental rules for building applications is that developers should not waste their time building infrastructure. Even though each application requires some support in the form of services, people who develop these applications should focus only on creating functionality that is meaningful to their users. Whatever infrastructure is required, it should be offered by the platform for which the application is being built.

Taking this into account, one of the ways to improve the platform is to offer a better application infrastructure on it. And that is precisely the goal of the Windows Server AppFabric. By offering a set of extensions for Windows Server, Microsoft seeks to make it easier for developers to create faster, more scalable, and more manageable applications.

The first release of Windows Server AppFabric contains two parts (today version 1.1 is available with many innovations. - Note. Lane ):

• AppFabric Caching Services that speeds up access to frequently used application data
• AppFabric Hosting Services service, which allows you to simplify the launch and management of services created on the basis of WCF and especially created on the basis of Windows Workflow Foundation

Windows Server AppFabric offers extensions for the Application Server role and these extensions are free to use together or separately. This introduction covers both parts of AppFabric.

AppFabric Caching Services

One way to improve the performance and scalability of multiple applications is to speed up their access to data. For example, for ASP.NET applications it is easy to create a scaling of business logic: simply place several copies of the logic on different servers, and then distribute the load between them. Improving this aspect of application performance can easily be achieved with more servers.
')
But if all these servers depend on a single database server, access to data can quickly become a bottleneck of your architecture. Adding new servers will not help when the ASP.NET page has to wait for the data it needs. One solution is to run the database server on a more powerful machine. This may work, but there are limitations here too: you will have to scale up by replacing the server with more and more powerful machines, and such a replacement may become too expensive. What we really need is a scaling method in which frequently requested data was available on several servers, which will allow us to avoid a bottleneck in the form of a single server.

An effective way to achieve this is to create a distributed cache that distributes data to multiple computers. Instead of sending each request to a single database server, an ASP.NET application can retrieve the necessary data from one of the neighboring machines. The load will be distributed and the application will start running faster. This is exactly the functionality that AppFabric Caching Services offers.

How AppFabric Caching Services Works

The main component of the AppFabric Caching Services is a cache client, such as an ASP.NET page, which accesses a cache cluster containing a number of cache servers. Each cache server runs an instance of the AppFabric Caching Services service and supports access to some set of cached data. Each cache client can also maintain its local data cache using special components supplied with AppFabric Caching Services. Figure 1 shows a diagram of all components:


Fig.1. AppFabric Caching Services Organization Diagram

When a cache client first receives a piece of data, for example, information passed by the user to an ASP.NET application or values ​​read from the database, the client can save this information with a unique name in the AppFabric Cache Services cache cluster (or, as will be described later, ASP.NET applications can store information transparently through the Session object, so it does not even need to rewrite the code in an existing application For the client, all other cache servers in the cluster look like one large storage — the client never knows and does not need to know on which of the physical servers its cached data is stored. Optionally, the client can save the data in his local cache.

When the client needs to access the same data again, he requests them through the specified unique name. This request checks the local cache (if any). If data is found, the client uses it from the local cache. If there is no data in the local cache, the request is sent to the cache cluster. If the data is in a cluster, the client uses it. This whole process is transparent to the client, it just sends the request and AppFabric Caching Services takes care of the rest. In case the data were not found in the cache cluster, the client will have to request data in the database.

At the design stage, AppFabric Caching Services bore the code name "Velocity", a name that exactly defines what this server does: it allows you to make repeated requests to data faster. Instead of making many similar queries to the database, this service allows you to get data directly from local or distributed memory. For applications that often request the same data, and there is a lot of such data, caching significantly improves performance and scalability.

AppFabric Caching Services is designed for use with .NET applications, so that cached data can be serialized into a .NET object. Once the object is cached, the client can then update or delete it from the cache. Cached items can also be removed from the cache by the service itself due to expiration of the retention period or due to the need to place more relevant data in the cache. The data in the local cache can also become outdated; in addition, local data can be synchronized with the same data from the distributed cache for modification and synchronous deletion.

Multiple cache clients can use the same cache cluster. This makes sense, since a scalable application is likely to duplicate its business logic on multiple machines, each of which requires access to a cache cluster. However, accessing multiple machines to the same cache cluster can result in security problems. To make sharing a single cache cluster between several clients more secure, all data transferred between the cache client and the cluster can be digitally signed or encrypted. In addition, the administrator has mechanisms to restrict the list of accounts that have access to the cache. The organization must be firmly convinced that all clients using the same cache are trusted, since they can potentially access each other’s data.

Caching is useful when working with different data types. For example, caching is very useful when working with data that cannot be changed over time, which are requested by different clients (information about the online supplier catalog). Another good example of using caching is storing mutable data, which, however, is consumed by only one client, for example, information about an ASP.NET session. Again, this example describes a case in which the problem of managing simultaneous access to cached data does not occur.

But what about when data that is constantly changing should simultaneously be consumed by a large number of customers? Caching can also be used in this case, but with one reservation: control of simultaneous access is necessary. To address this problem, AppFabric Caching Services supports both optimistic concurrent access control based on version number assignment and pessimistic concurrent access control using explicit locks.

Scenario: Using caching in an ASP.NET application

ASP.NET applications are the most important clients for AppFabric Caching Services. As mentioned earlier, the data stored in the ASP.NET session object is the most obvious candidate for caching. In fact, the service offers built-in support for this — the developer only needs to specify configuration options and the session object will be transparently stored in the cache cluster. Note: this means that ASP.NET developers can take advantage of distributed caching without modifying their application code. This allows you to use multiple copies of web servers running ASP.NET application instances without using SQL Server to store session data. Figure 2 shows how this mechanism works:


Fig.2. How ASP.NET applications work with AppFabric Caching Services

This simple scenario starts with the user sending some information that ASP.NET stores to the user session object (step 1). The web server that processes the request is configured to cache session objects in the AppFabric Caching Services cluster and therefore user data is written to one or more cache servers (step 2). The next request from the user is based on the data saved in step 1, but this request is already being processed by another server (step 3). ASP.NET code on this server refers to the same session object, which in effect means transparent access to the cache cluster for data access (step 4). This allows the information obtained in step 1 to be accessible to the application. Please note that we did not have to operate from the database to store information, and we also do not need the same server to process user requests. The result of this infrastructure is improved performance and improved scalability of an ASP.NET application.

Scenario: Using High Availability

The AppFabric Caching Services service keeps all the data in memory - it is not written to disk. By default, each cached object is stored only on one machine in the cache cluster. In order to increase reliability in cases where the server becomes unavailable, AppFabric Caching Services offers support for a high availability mechanism. This mechanism allows you to create duplicate copies of cached data on other machines in the cache cluster. If the cache server that stores the primary copy of the data becomes inaccessible, then the data will be obtained from the secondary storage. Figure 3 demonstrates the whole idea:


Fig.3. High Availability AppFabric Caching Services

In this example, the high availability mechanism is turned off, so that each item of cached data is stored in two different cache servers. The primary copy, shown in the figure as a filled figure, accepts all changes with the data. These changes are automatically replicated to the secondary copy, represented as a blank figure. Here, the cache server containing the primary copy of X data becomes inaccessible (scheduled or random, step 1). When the cache client requests X data (step 2), the cache cluster covertly redirects the request to the secondary copy and returns the value (step 3).

This example shows the reading of the data, but the update request will be processed in the same way when the cache server with the primary data is unavailable. As soon as AppFabric Caching Services determines that the server with the primary data is unavailable, the existing server with the secondary data becomes the primary, and a new secondary copy is created on one of the available servers. All this is transparent to the client, it just works as if nothing happened to the servers.

Regardless of whether or not a high availability mechanism is used, AppFabric Caching Services allows you to speed up access to frequently requested data. This is a very useful feature that extends the existing infrastructure of Windows Server.

Suggestions for improved support for business logic are also helpful and what Windows Server AppFabric has to offer in this plan are covered in the next section.

Start, to be continued.