Typical Deployments

The requirements of your Windows Server AppFabric server deployment topology are highly dependent on your business needs and the requirements of the applications you will be hosting. While it is difficult to consider any single deployment as typical and provide prescriptive guidance for it, this section provides guidance and recommendations for deploying AppFabric in your environment.

The following deployment topics are discussed:

• AppFabric Single Server Deployment

• AppFabric Server Farm Deployment

• AppFabric Caching Features Deployment Security Considerations

• AppFabric Caching Features Deployment Scenarios

AppFabric Single Server Deployment

A single server deployment takes place when you install AppFabric on a single computer. This deployment is often used in a development environment where all application development takes place on a single computer.

SQL Server

Because scale-out is not a concern for a development environment, this deployment of AppFabric can be configured to use a local installation of SQL Server Express for the monitoring and persistence database.

Application Deployment

While application deployment can be accomplished by packaging applications and deploying to AppFabric by using MSDeploy, it is more likely that developers will instead configure their project to directly use the local server running IIS as a means of hosting applications, because this involves the minimal amount of steps to host an application in a test environment. However, we recommend that developers test packaging and deployment of applications before migration to the staging or production environment to ensure that the packaged application deploys correctly.

For more information about deploying an application, see Deploying an Application.

AppFabric Server Farm Deployment

While one computer with both AppFabric and SQL Server installed is sufficient for a development environment, a production environment often consists of multiple computers in a server farm, and one or more dedicated SQL Server servers. Such an environment may also use load balancers and queues to manage incoming messages destined for your application, and clustering of the SQL Server for high availability.

A small-scale deployment of AppFabric may start with AppFabric installed on a single computer, but may grow to a server farm where your applications are deployed across multiple servers to create a highly distributed application. Scaling out allows you to implement load balancing solutions so that the processing of incoming messages is spread across multiple servers, as well as providing increased fault tolerance for workflows that use persistence.

SQL Server Clustering

Although not described in detail in this section, we strongly recommend clustering your databases for failover protection. For more information about SQL Server failover clustering, see Planning for Disaster Recovery (https://go.microsoft.com/fwlink/?LinkId=131016).

Durable Application Scale-Out

When dealing with a long-running process it is vital that your application is able to survive system restarts, hardware failures, or other unforeseen server outages. AppFabric provides a default persistence provider that your workflow applications can take advantage of to provide persistence for long-running applications.

In a single server deployment, persistence provides the ability for a workflow instance to resume execution when the server it is hosted on returns to a healthy state; however, in a server farm deployment the application can be resumed on any eligible computer in the server farm. Additionally, if a workflow instance is executing on one server and a message destined for that instance arrives on another server, persistence can move the executing instance to the computer that has the pending message so that it can be processed by the workflow.

For more information, see Configuring Workflow Persistence.

Data Isolation

The default configuration for AppFabric is to store both persistence and monitoring information in one database. While this is sufficient for a development environment, a production environment usually requires a more robust set of resources for data storage.AppFabric allows you to create multiple, separate, persistence and monitoring databases to support data isolation over multiple computers running SQL Server.

Because AppFabric supports the creation of multiple databases, you can separate data not only by function (persistence and monitoring), but also by application. If you have an application that has robust data storage requirements, you can create persistence and monitoring databases that are specifically associated with only this application or service.

For more information about creating additional databases, see Database Administration.

Application Deployment

When deploying an application to multiple computers, it is important that the deployment can be accomplished in a consistent, repeatable manner. In order to achieve this goal, AppFabric uses MSDeploy to package and deploy Web applications, Web sites, or Web server content and configuration. MSDeploy can also be used to synchronize data between Web site or Web server to either the local computer or remote computers within your server farm.

For more information about deploying an application, see Deploying an Application. For more information about MSDeploy, see Web Deployment Tool (https://go.microsoft.com/fwlink/?LinkId=151481).

AppFabric Caching Features Deployment Security Considerations

The AppFabric distributed cache system is designed to be operated in a datacenter within the perimeter of a firewall. The servers described in this section are the server hosting the cache configuration storage location, the cache servers, the cache-enabled application servers, the development servers, and the primary data source server. All servers should be collocated on the same domain.

Because cached data and the TCP/IP communications between the cache servers are not encrypted, the distributed cache system is vulnerable to malicious attacks that log or modify network traffic.

When decommissioning a cache server, the AppFabric installation program may not remove all firewall port exceptions. After AppFabric has been uninstalled, we recommend that you reapply your standard firewall configuration.

AppFabric Caching Features Deployment Scenarios

To simplify the discussion of deployment options, this section focuses on three distinct examples:

• Developer deployment. A single-computer deployment used to develop cache-enabled applications.

• Mid-sized deployment. A multicomputer installation that does not use SQL Server, with lead hosts performing the cluster management role.

• Enterprise deployment. A multicomputer installation that uses SQL Server for storing cluster configuration settings and performing the cluster management role.

The following table summarizes where the AppFabric caching features are installed, and how the cluster management role is performed.

The cache cluster configuration settings can be stored in a shared network folder or a SQL Server database. For more information about each of these options, see Cluster Configuration Storage Options (Windows Server AppFabric Caching).

The cluster management role can be performed by lead hosts or SQL Server. From a cache cluster availability standpoint, using SQL Server is the best option. For more information, see Lead Hosts and Cluster Management (Windows Server AppFabric Caching).

Developer Deployment

With the developer deployment, all components required to create a cache-enabled application—including the cache cluster itself—are contained within the developer's workstation. This deployment is the most convenient option when getting started with AppFabric caching features.

Mid-Sized Deployment

With the mid-sized deployment, your application can yield the benefits of a distributed cache cluster. You can easily scale your application to meet the growing demands of your application tier.

Because this deployment scenario does not use SQL Server to store cluster configuration settings, there are some drawbacks. Some operating systems are limited in the number of concurrent connections to shared folders they can support, directly impacting the maximum number of cache hosts you can have in the distributed cache cluster. Windows XP, Windows Server 2003, and the 32-bit version of Windows Vista do not allow more than 10 concurrent connections to a shared network folder. We recommend that you not use these operating systems to store the cache configuration settings for large clusters.

If you automate or otherwise attempt to perform parallel cache server installations, there is likely to be contention on the cluster configuration files. The most reliable cache server installation strategy in this scenario is to perform only one cache server installation at a time.

Because this scenario does not employ SQL Server, the installation does not require that you procure and install SQL Server and create a cluster configuration database for your application. In terms of time and money, this may or may not be a cost savings depending on what you already have available to your application. When using the shared folder cluster configuration storage option, all cache servers in the cache cluster must have continuous network connectivity to the shared network folder.

Without SQL Server, only lead hosts can perform the cluster management role. Because a majority of lead hosts must always be running in order for the cache cluster to be available, the cache cluster in this scenario is more vulnerable to server failures. This scenario also complicates server maintenance regarding the availability of your application. For more information, see Lead Hosts and Cluster Management (Windows Server AppFabric Caching).

Enterprise Deployment

Compared to the other deployment scenarios, the enterprise deployment offers the best availability and supportability experience. It requires a SQL Server database, which may not be an option for some applications.

When SQL Server performs the cluster management role, the cluster can withstand losing all but one cache server in the cluster and remain running. Just as when using the shared folder cluster configuration storage option, the cache servers must have continuous network connectivity to the SQL Server database.

Because none of the cache servers in this scenario are performing the cluster management role, server maintenance for highly available applications is greatly simplified. No complex sequencing of server restarts is required. For more information, see Lead Hosts and Cluster Management (Windows Server AppFabric Caching).

Using SQL Server is advantageous in situations that require concurrent connections. This allows parallel automated cache server installations to go smoothly without the cluster size limitations of the mid-sized deployment. For more information, see Installing Application Server Extensions for .NET 4 (https://go.microsoft.com/fwlink/?LinkId=169172).

See Also

Concepts

Architectural Overview
Cluster Configuration Storage Options (Windows Server AppFabric Caching)
Shared Folder-Based Cluster Configuration (Windows Server AppFabric Caching)
SQL Server-Based Cluster Configuration (Windows Server AppFabric Caching)
Using Windows PowerShell to Manage Windows Server AppFabric Caching Features
Lead Hosts and Cluster Management (Windows Server AppFabric Caching)