Pitfalls of AppFabric Cache
As part of its web development platform, Microsoft also provides NoSQL caching solution - AppFabric Cache. One of the interesting modes of AppFabric Cache is High Availability - the ability to create a cluster of cache servers where, in the event of any failure, your service does not interrupt and all data remains available to the application. When you create a .NET web application without a single point of failure, using such a cache server seems like an easy and natural solution. Especially here, the price can please, since AppFabric is provided by Microsoft for free as part of its operating system. However, choosing a solution for caching is useful to see not only what is on the surface.
When you turn on High Availability mode to any object in the cache, there are two copies on different servers in the cluster, so that the loss of a single server will not cause data loss:
(from the documentation msdn.microsoft.com/en-us/library/ee790974.aspx )
This the configuration does not require anything from the application, the API is exactly the same as if the cache works without High Availability. Thus, you can store session data in such a cache using the built-in provider and get the ability to scale the application and resistance to failures without writing a single line of code.
And although this looks pretty interesting, there are a number of points that you should know before deploying the finished application, which was developed under AppFabric on production servers:
AppFabric cluster in High Availability mode will work with two computers, but will not work with one. Therefore, if you get rid of a single point of failure, you need at least 3 computers, so that in the event of the loss of one of them, the work of your service would not stop.
See if your hosting provider Enterprise Edition is in the list of images or you can use special Microsoft programs for obtaining startup licenses (http://www.microsoft.com/bizspark/).
You can decide that since you have copies of objects on other computers, the service will work without interruption, right? No, not at all. The rule of service indicates that copies of objects must be at least on two nodes of the cluster. When one of the nodes becomes unavailable, objects of a copy which exist in a single copy will be copied to other nodes of the cluster until all objects are presented in duplicate. While objects will be copied, your service will not be available.
In particular, this means that you cannot safely restart one of the computers in the AppFabric cluster since there will be some interruption in the service.
This will be a bigger problem if your nodes contain a lot of RAM because then copying will be longer. To minimize this problem, it is better to keep more servers with less RAM.
All cluster nodes use a common configuration, which can be contained either on a file share or on an MSSQL server. If you deploy the service in High Availability mode to get rid of a single point of failure, then using a file share is pretty stupid; inaccessibility of a computer with a configuration will stop the cache. But here is a surprise - when you configure the configuration on the SQL server, the configuration utilities do not let you do this, requiring your server to be part of the Windows domain.
What to do?
All of this is rather sad and could be the # 1 file for High Availablity, but fortunately you can find a simpler solution if you have a Windows account with the same name and password (account mirroring) on all computers in the cluster. This configuration can be done using the AppFabric Powershell Console, a standard GUI program for configuring the cluster will not allow you to do this.
How it works
When you turn on High Availability mode to any object in the cache, there are two copies on different servers in the cluster, so that the loss of a single server will not cause data loss:
(from the documentation msdn.microsoft.com/en-us/library/ee790974.aspx )
This the configuration does not require anything from the application, the API is exactly the same as if the cache works without High Availability. Thus, you can store session data in such a cache using the built-in provider and get the ability to scale the application and resistance to failures without writing a single line of code.
And although this looks pretty interesting, there are a number of points that you should know before deploying the finished application, which was developed under AppFabric on production servers:
High Availability requires a minimum of 3 servers
AppFabric cluster in High Availability mode will work with two computers, but will not work with one. Therefore, if you get rid of a single point of failure, you need at least 3 computers, so that in the event of the loss of one of them, the work of your service would not stop.
High Availability requires all computers to be running Windows 2008 / 2008R2 Enterprise Edition (or higher)
See if your hosting provider Enterprise Edition is in the list of images or you can use special Microsoft programs for obtaining startup licenses (http://www.microsoft.com/bizspark/).
Suppose you have a cache cluster of 3 computers, what happens when one of these computers suddenly crashes?
You can decide that since you have copies of objects on other computers, the service will work without interruption, right? No, not at all. The rule of service indicates that copies of objects must be at least on two nodes of the cluster. When one of the nodes becomes unavailable, objects of a copy which exist in a single copy will be copied to other nodes of the cluster until all objects are presented in duplicate. While objects will be copied, your service will not be available.
In particular, this means that you cannot safely restart one of the computers in the AppFabric cluster since there will be some interruption in the service.
This will be a bigger problem if your nodes contain a lot of RAM because then copying will be longer. To minimize this problem, it is better to keep more servers with less RAM.
Configuration
All cluster nodes use a common configuration, which can be contained either on a file share or on an MSSQL server. If you deploy the service in High Availability mode to get rid of a single point of failure, then using a file share is pretty stupid; inaccessibility of a computer with a configuration will stop the cache. But here is a surprise - when you configure the configuration on the SQL server, the configuration utilities do not let you do this, requiring your server to be part of the Windows domain.
What to do?
- Ensure the smooth operation of the file ball using the capabilities of Windows 2008R2 Cluster
- Deploy a domain controller in your server environment. Note that you cannot install AppFabric Cache on the domain controller itself. In addition, your domain controller will be a potential new point of failure.
- Write your own provider to store the configuration.
All of this is rather sad and could be the # 1 file for High Availablity, but fortunately you can find a simpler solution if you have a Windows account with the same name and password (account mirroring) on all computers in the cluster. This configuration can be done using the AppFabric Powershell Console, a standard GUI program for configuring the cluster will not allow you to do this.
Throttling
AppFabric Cache uses RAM for caching. When the Memory \ Available MBytes counter has less than 15% of the physical memory of the computer, the node goes into the Throttled state. In this state, writing new data to this host is not possible. Keep in mind when planning your resources.conclusions
- Although the AppFabric Cache service itself is free, High Availability requires a server operating system with an Enterprise Edition or higher, and at least 3 computers.
- High Availability in practice is not so High times the loss of one node leads to temporary unavailability of the entire cache and possibly your application, unless you specifically envisaged a script for the application to work when the cache is inaccessible. Nevertheless, the service will recover itself without data loss after some time. Whether this is permissible in your application is up to you to decide, but it is better to know about it before you tightly contact us to use this product.