Scale-Out Configurations
You can scale out an instance of Microsoft SQL Server Notification Services across multiple servers. You can locate the generator, the event providers, and the distributors on separate servers. You can also locate non-hosted event providers and subscription management applications on separate servers. This topic illustrates three common scale-out scenarios: an application that needs greater distribution throughput, an application that uses a non-hosted (independent) event provider, and an application that has a subscription management application on a Web server.
Distributor Scale-Out
For high-volume applications, the distributor can fall behind because formatting notifications can be processor intensive, and notification distribution requires adequate bandwidth to the systems that deliver the notifications. To minimize distribution bottlenecks, you can scale the distributor across multiple servers by defining multiple distributors in the application definition. The distributors pick up distribution work items as they become available.
The following illustration shows a system that uses three servers for Notification Services: one server runs the generator and the hosted event providers, and two other servers run distributors.
.gif "Scale-out configuration")
Note that the generator is located with the hosted event providers. This is because generator process does not entail significant CPU or disk overhead; most of the generator work is performed on the database server.
Note
You can host the generator for each application on its own server, but each application uses only a single generator.
The recommended number of CPUs for formatting and distribution depends on the complexity of the formatting algorithm and of the distribution logging settings. If formatting is complex, a server that hosts a distributor needs more processing power. If you log notification text ), your application databases must have enough disk space to store the logged information. For more information, see Configuring Distributor Logging.
The general recommendations are that each Notification Services server and the database server should have from two to four CPUs. The database server should have enough disk space to store event, notification, subscription, and subscriber data until the data removal process removes the data. Additionally, you should place the database files, log files, and the tempdb database on separate physical disks.
Non-hosted Event Providers
The Notification Services engine can run the event provider host, which supports the standard event providers supplied with Notification Services and custom hosted event providers developed by you or a third party. However, there are cases when it is better or easier to use a non-hosted, or independent, event provider. It is common for these non-hosted event providers to run on separate servers, such as Web servers.
Non-hosted event providers use the Notification Services API to connect to databases and to submit events, but do not require the Notification Services engine. Using a non-hosted event provider on a separate server requires that you install the Notification Services client components and register the instance on that server, but you do not need to create the Windows service that runs the Notification Services engine.
The following diagram shows a system with a remote, non-hosted event provider.
.gif "Server configuration with remote event provider")
For deployment information, see Deploying a Non-Hosted Event Provider.
Subscription Management Interfaces
Like non-hosted event providers, subscription management interfaces use the Notification Services API to connect to databases and to submit events, but do not require the Notification Services engine. On a server, such as a Web server, that hosts a subscription management interfaces, you must install the Notification Services client components and register the instance on the server that hosts a subscription management application, but you do not need to create the Windows service.
The following diagram shows a system with a remote subscription management application.
.gif "Configuration for remote subscription applications")
For deployment information, see Deploying a Subscription Management Interface.
See Also
Tasks
Walkthrough: Scale-Out Deployment
Concepts
Hardware Configurations
Notification Services Considerations
Database Considerations
Database Resource Planning