Jaa

Disaster Recovery Considerations for the AppFabric Environment

  • Artikkeli

Installing Microsoft AppFabric 1.1 for Windows Server does not change how an administrator should plan for disaster recovery. Planning and restoring an AppFabric installation is based primarily upon following normal disaster recovery for Windows, Internet Information Service (IIS), and SQL Server. The following AppFabric artifacts should be backed up through these three products.

  • Configuration settings and files

  • Windows service settings for Event Collection, Workflow Management, and Caching Service

  • Windows security settings for modifications to AppFabric -specific user groups

  • Registry settings

  • Web application files

  • Databases used by AppFabric

SQL Server Databases

Use normal SQL procedures for backing up and restoring the monitoring and persistence databases, and the caching configuration database if using AppFabric Caching. The purpose of creating SQL Server backups is to enable you to recover a damaged database. However, backing up and restoring data must be customized to a particular environment and must work with the available resources. Therefore, a reliable use of backup and restore for recovery requires a backup and restore strategy. A well-designed backup and restore strategy maximizes data availability and minimizes data loss, while considering your particular business requirements.

Microsoft AppFabric 1.1 for Windows Server produces application state data. Workflow persistence stores the state of workflow service instances. In the event that a computer running a workflow crashes, another computer running the service can restart the workflow instance from the last persistence point. Persistence data is critical to the workflow application and should have its real-time availability guaranteed. When the SQL Server instance store provider is used for workflow persistence, one of the SQL Server high-availability features should be used. These include failover clustering, database mirroring, transactional replication, or log shipping. In cases where the workflow service writes to another application database, the persistence schema can be added to the existing database instead of to a separate persistence database. This will simplify the enforcement of data consistency when restoring data after a disaster.

In some cases, the data that populates the distributed cache originates from a source, like a database, that can be backed up. In other scenarios, for example when the cache is used to store ASP.NET session state, the data is never written to permanent storage. The cache provides a high-availability mode that ensures that each piece of cached data is written to at least two hosts. In the event that one computer crashes, applications can continue to use the data from the cache on the other computers.

Microsoft AppFabric 1.1 for Windows Server monitoring databases contain the events that were emitted by the WCF and WF runtimes over a period of time. This data can be used to gauge service load and to troubleshoot application errors; this data feeds the AppFabric Dashboard, for example. While it is possible to extract business-related data from workflows, Microsoft AppFabric 1.1 for Windows Server does not guarantee the reliability of the monitoring data and does not ensure that the monitoring data is consistent with the state of the workflow. The events are collected for operational, not business-decision, purposes. As a result, it is not crucial that the monitoring data be synchronized with other application data. In most cases, monitoring data should be kept in dedicated databases, separate from persistence and other application data.

As a part of a disaster recovery plan for the AppFabric installation, you may need to move a Microsoft AppFabric 1.1 for Windows Server database to another server. Before a database is moved, ensure you run a successful backup and restore of the database. The connection strings must then be modified to point to the updated database location. You can update the connection string to point to the new database location using the Configure Hosting Services Page. For more information on moving AppFabric databases, see Moving User Databases.

For more information on SQL Server disaster recovery, see Introduction to Backup and Restore Strategies for SQL Server, How-To-Topics for Backing Up and Restoring SQL Server, and Planning for Disaster Recovery.

Note

In this document we will refer to SQL Server databases. However, you would have to do the same for Windows Server AppFabric databases implemented by other vendors.

Windows Configuration

When performing server backups, the administrator must ensure that the following configuration data related to AppFabric is included. Backup agents that leverage the Windows Volume Shadow Copy Service (VSS), such as Microsoft System Center Data Production Manager, will automatically include the files below. The System Writer covers the root web.config file and files under %SystemRoot%\System32. The IIS Configuration Writer covers the MWA schema files. No VSS writer automatically covers the cache configuration.

  • Configuration for the Event Collection Service, the nameless service behavior configuration (behavior name=""), and the monitoring and persistence providers is stored in the root web.config file (%SystemRoot%\Microsoft.NET\Framework {Framework64}\v4.x\Config\web.config).

  • Configuration for the Workflow Management Service is stored in the Workflowmanagementservice.exe.config file under %SystemRoot%\System32\AppFabric.

  • Custom MWA schemas (to allow the tooling of custom behaviors, for example) are stored in %SystemRoot%\System32\inetsrv\config\schema.

  • Microsoft AppFabric 1.1 for Windows Server provides two providers for storing distributed cache configuration. The XML provider stores the cache configuration as an XML file in a shared directory that the user specifies during configuration. The SQL Server provider stores the cache configuration in a SQL Server database. This configuration needs to be backed up.

Alternatively, the administrator may choose to schedule regular Web Deployment Tool (“MSDeploy”) commands that will synchronize the contents of the entire Web server to a package stored on a remote computer. This package will by default cover item 1 above and will include all applications (configuration and binaries) deployed on the Web server. The package could be customized to explicitly include the configuration files listed previously. In the event of a disaster, the administrator could restore the base server image and simply deploy the Web Deployment Tool package to the server. Typically, a base server configuration will be created and later copied to other computers. The base server includes the Windows operating system, Windows server roles, Windows updates, and customized user accounts. The administrator should install Microsoft AppFabric 1.1 for Windows Server on the base server, but should typically not configure AppFabric on the base server image so that databases and user accounts for AppFabric ’s services can be set after applying the image to the new computer. This base server image can be backed up by using Sysprep or Windows Server Backup.

Internet Information Services (IIS)

Use WebDeploy and export applications from the IIS Manager console to create backup versions. You can also export all the file system content for the application. Using the Advanced Settings dialog with the Deploy functionality of AppFabric, you can export ACLs and add specific custom parameters. Once exported, you can store the exported zip file in a safe place. Later when restoring a system after a disaster, you can import an application back into AppFabric using IIS Manager to rebuild the applications and their associated configuration and registry settings. For more information on how to properly export and import AppFabric applications to ensure that you preserve all necessary configuration settings, see Import and Export an Application in AppFabric.

From a pure IIS standpoint, you will want to make a backup the IIS metabase using the AppCmd utility. If you are using IIS shared configuration on a common UNC share, you will need to manually manage backing up a shared configuration file, because AppCmd will not back up data on a share. Protecting IIS7 configuration data at the Windows file system level is as simple as copying the \windows\system32\inetsrv\config directory (and subdirectories) into a backup directory. Just include this directory in your current Windows OS backup plan (say using the BACKUP utility), or write a custom script to do it. For information on using the AppCmd utility for backing up IIS, see How to create and manage configuration backups in Internet Information Services 7.and How to Back Up an IIS 7 Configuration.

Summary

Preparing for disaster recovery is an important task in the production environment. This is done at the SQL Server, Windows, and IIS levels. Some data (like computer and software configuration) does not change frequently and can be safely guarded by regularly scheduled backups. Other data, such as workflow persistence, is critical to the application and needs to be safeguarded as it is written. Microsoft AppFabric 1.1 for Windows Server configuration data should be included in regular backups. Administrators should also ensure the high availability of persistence, and in some scenarios, cache data.

  2012-09-12